JP5124375B2 - 情報処理装置 - Google Patents

Description

本発明は、通信機能を有し、相互に信号の送受信を行なう複数の情報処理装置から構成される分散機器相互制御システムに適用される情報処理装置に関する。

近年、携帯電話機の高機能化、大容量化、高速化が進んでいる。その結果、電子メールやスケジュール帳などの基本的なアプリケーションに加え、ＰＣ用ウェブページの閲覧、地デジ（地上デジタル放送）映像の視聴などの高機能なアプリケーションが搭載されるのが一般的になってきている。また、携帯電話機の通信機能は、ウェブ閲覧や電子メールの送受信に利用するソケット通信機能に加え、赤外線通信機能、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信機能、Ｆｅｌｉｃａ（登録商標）通信機能も搭載されるようになってきている。

これにより、携帯電話機とＰＣ、携帯電話機と携帯電話機、または携帯電話と専用小型デバイスなど、携帯電話機と近接する他端末とローカルネットワークを構成して通信することによって、双方向でのデータ通信やユーザインタラクションが可能となる。

特に、携帯電話機とＰＣが連携するシステムの代表的なものとして、ＰＣの液晶画面表示内容を携帯電話の画面に表示するシステムがある。最も有名なシステムは、ＶＮＣ（Virtual Networking Computing）である。このシステムは、サーバ側の端末の画面を画像化し、その画像データをクライアント側の端末に転送するものである。これにより、ユーザは、遠隔地から携帯電話機でＰＣにアクセスし、ＰＣ上で動作するアプリケーションを起動したり、その表示画面を携帯電話機の画面上で確認したり、携帯電話機上のテンキーを利用して入力したテキストデータを、ＰＣ上で動作するアプリケーションのテキストボックス内に入力することができる。例えば、特許文献１（特開２００７−２５１６３０）、または特許文献２（特開２００１−１０３５６８）には、遠隔地からＰＣを動作させる技術が開示されている。

また、携帯電話機の機能を制御するシステムがある。例えば、特許文献３（特開２０００−０４１１０２）に開示されている技術は、遠隔地に存在するＰＣから制御信号を携帯電話に送信することにより、携帯電話機のキー操作の無効化や、電源供給の停止を行なうことができる。さらに、特許文献４（特表２００７−５２２５４６）に開示されているシステムでは、２つの無線携帯端末（例えば、携帯電話とＰＤＡ）間で機能を共有し、双方からのユーザインタラクションを可能にする。このシステムでは、２つの端末がＢｌｕｅｔｏｏｔｈ（登録商標）などの無線通信手段によって接続している状態において、ＰＤＡのタッチパネルで入力することで、携帯電話機の電話呼を発信したり、ＰＤＡ内の写真を携帯電話機のカラーディスプレイ上で携帯電話のスクロールホイールを操作して閲覧したり、携帯電話内の画像をＰＤＡ上で編集したりすることができる。
特開２００７−２５１６３０号公報 特開２００１−１０３５６８号公報 特開２０００−０４１１０２号公報 特表２００７−５２２５４６号公報

しかしながら、特許文献１および特許文献２に記載されているシステムは、携帯電話からＰＣに遠隔アクセスし、ＰＣの液晶画面表示内容を画像化し、その画像データを携帯電話機に転送し、表示するものでしかなく、携帯電話からＰＣへの一方向の制御でしかない。また、特許文献３に記載されているシステムは、ＰＣから携帯電話機に制御信号を送信することで、携帯電話機の機能を制御するものでしかなく、ＰＣ側から一方的に携帯電話機を制御するものでしかない。特許文献４は、２つの携帯端末のうち、一方が持つ表示内容、機能、ユーザインタフェースを他方と共有するシステムについて記述している。しかし、特許文献４には、２つの装置が近接しており、スクリーン共有機能を開始すると１つの装置の機能や動作に関して、他方の装置からの操作が可能であるというシステム構成およびシーケンスチャートしか記載されておらず、具体性に欠ける。２つの装置が有する機能を効果的に活用して、１つの装置のみが有する機能を高める概念は記載しているが、各機能を利用する上で、各装置上での詳細なアルゴリズムは不明である。

また、上記の従来技術では、携帯電話機とＰＣ間で同時に利用可能なアプリケーションは１つしかない。これは、携帯電話機の仕様により、起動できるアプリケーションが１つのみであることが前提となっているためであると考えられる。しかし、将来的に、携帯電話機上で複数のアプリケーションを同時に起動できるようになることが予想される。複数のアプリケーションを起動し、ＰＣと携帯電話機間で複数のアプリケーションでデータを送受信する場合、一つのアプリケーションのデータ伝送が、その他のアプリケーションの影響で遅延しユーザビリティを低下させることが予想される。

本発明は、このような事情に鑑みてなされたものであり、複数の端末装置、例えば、携帯電話機およびＰＣにおいて、複数のアプリケーションを同時に動作したとしても、効率的にデータ通信を行なうことができる情報処理装置を提供することを目的とする。

（１）上記の目的を達成するために、本発明は、以下のような手段を講じた。すなわち、本発明の情報処理装置は、通信機能を有する複数の情報処理装置が相互に信号の送受信を行なう通信システムに適用される情報処理装置であって、予め定められた優先度に対応して設けられた複数の送信側キューと、他の情報処理装置に対してデータを送信する際に、前記優先度に対応するキューを選択し、選択したキューに送信するデータを格納する送信側キュー挿入部と、前記優先度の高いキューから順次データを読み出す送信側キュー読出部と、を備えることを特徴としている。

このように、他の情報処理装置に対してデータを送信する際に、優先度に対応するキューを選択し、選択したキューに送信するデータを格納し、優先度の高いキューから順次データを読み出すので、予め定められた優先度に応じて効率的に送信データの処理を行なうことが可能となる。特に、他の情報処理装置との伝送路が１本しか確立できない場合に複数のアプリケーションを並行して動作させる場合、１つのデータストリームを生成することで、複数のアプリケーションのデータを送受信することが可能となる。

（２）また、本発明の情報処理装置は、通信機能を有する複数の情報処理装置が相互に信号の送受信を行なう通信システムに適用される情報処理装置であって、予め定められた優先度に対応して設けられた複数の受信側キューと、他の情報処理装置からデータを受信した際に、受信したデータに基づいて、前記優先度に対応するキューを選択し、選択したキューに前記受信したデータを格納する受信側キュー挿入部と、前記優先度の高いキューから順次データを読み出す受信側キュー読出部と、を備えることを特徴としている。

このように、他の情報処理装置からデータを受信した際に、受信したデータに基づいて、優先度に対応するキューを選択し、選択したキューに受信したデータを格納し、優先度の高いキューから順次データを読み出すので、予め定められた優先度に応じて効率的に受信データの処理を行なうことが可能となる。特に、他の情報処理装置との伝送路が１本しか確立できない場合に複数のアプリケーションを並行して動作させる場合、１つのデータストリームを生成することで、複数のアプリケーションのデータを送受信することが可能となる。

（３）また、本発明の情報処理装置は、オペレーティングシステム上で実行される少なくとも一つの自己アプリケーションを備え、前記自己アプリケーションは、他の情報処理装置に対してデータを送信する際に、キュー種別およびＡＣＫ（Acknowledgement）の要否を示す情報を付加することを特徴としている。

このように、他の情報処理装置に対してデータを送信する際に、キュー種別およびＡＣＫの要否を示す情報を付加するので、データ送信時に上記優先度を指定し、およびＡＣＫの要否を指定することが可能となる。

（４）また、本発明の情報処理装置において、前記送信側キュー挿入部は、前記自己アプリケーションから受信したデータに付加されたキュー種別に対応するキューを選択し、選択したキューに送信するデータを格納することを特徴としている。

このように、自己アプリケーションから受信したデータに付加されたキュー種別に対応するキューを選択し、選択したキューに送信するデータを格納するので、キュー種別によって優先度を指定することが可能となる。

（５）また、本発明の情報処理装置は、前記自己アプリケーションおよび他の情報処理装置で実行される他のアプリケーションの機能を示す情報を取得し、前記自己アプリケーションに実行すべき機能が存在せず、前記他のアプリケーションに実行すべき機能が存在する場合は、前記他の情報処理装置に対して、前記他のアプリケーションを実行する旨の信号を出力する制御部と、前記自己アプリケーションの実行結果を表示し、または前記他の情報処理装置から入力した前記他のアプリケーションの実行結果を表示する表示部と、を更に備えることを特徴としている。

このように、自己アプリケーションに実行すべき機能が存在せず、他のアプリケーションに実行すべき機能が存在する場合は、他の情報処理装置に対して、他のアプリケーションを実行する旨の信号を出力するので、他の情報処理装置が有している機能を利用することが可能となる。また、自己アプリケーションの実行結果を表示し、または他の情報処理装置から入力した他のアプリケーションの実行結果を表示するので、ユーザは、この情報処理装置のみを操作して、この情報処理装置または他の情報処理装置の動作状況を確認することが可能となる。その結果、ユーザは、ＴＰＯに応じて利用する情報処理装置を自由に選択することが可能となる。

（６）また、本発明の情報処理装置において、前記制御部は、前記自己アプリケーションに実行すべき機能が存在すると共に、前記他のアプリケーションにも実行すべき機能が存在する場合、前記自己アプリケーションを実行させ、または、前記他の情報処理装置に対して、前記他のアプリケーションを実行する旨の信号を出力することを特徴としている。

このように、自己アプリケーションに実行すべき機能が存在すると共に、他のアプリケーションにも実行すべき機能が存在する場合、自己アプリケーションを実行させ、または、他の情報処理装置に対して、他のアプリケーションを実行する旨の信号を出力するので、１つのタスクを２つの情報処理装置を用いて処理することが可能となる。これにより、ユーザは、ＴＰＯに応じて利用する情報処理装置を自由に選択することが可能となる。

本発明によれば、他の情報処理装置に対してデータを送信する際に、優先度に対応するキューを選択し、選択したキューに送信するデータを格納し、優先度の高いキューから順次データを読み出すので、予め定められた優先度に応じて効率的に送信データの処理を行なうことが可能となる。特に、他の情報処理装置との伝送路が１本しか確立できない場合に複数のアプリケーションを並行して動作させる場合、１つのデータストリームを生成することで、複数のアプリケーションのデータを送受信することが可能となる。

（第１の実施形態）
次に、本発明に係る実施形態について、図面を参照しながら説明する。図１は、本実施形態に係る分散機器相互制御システムの概念を示す図である。図１に示すように、本実施形態の分散機器相互制御システムは、携帯電話機（ＭＴ）１０とＰＣ２０とが、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信により接続する。ＭＴ１０およびＰＣ２０上では、それぞれソフトウェアが実行される。ＭＴ１０上で行なった操作は、ＭＴ１０上のソフトウェアおよび／またはＰＣ２０上のソフトウェアが動作して処理され、ＭＴ１０上のソフトウェアおよび／またはＰＣ２０上のソフトウェアに処理結果が反映される。

同様に、ＰＣ２０上で行なった操作は、ＰＣ２０上のソフトウェアおよび／またはＭＴ１０上のソフトウェアが動作して処理され、ＰＣ２０上のソフトウェアおよび／またはＭＴ１０上のソフトウェアに処理結果が反映される。このとき、ＭＴ１０および／またはＰＣ２０の画面更新が伴っても、画面更新が伴わなくても良い。ＭＴ１０およびＰＣ２０は、さまざまなアプリケーションが動作するためのプラットフォームを有する。

ここで、本実施形態では、２つの機器として、携帯電話機（ＭＴ）１０およびＰＣ２０を用いて説明するが、その他の機器であっても良い。例えば、家電機器や車載端末などであってもよい。また、２つの機器が相互連携するための通信手段として、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信手段を用いて説明するが、その他通信手段であってもよい。例えば、ＵＳＢ対応有線通信手段などであってもよい。

図２は、本実施形態に係る分散機器相互制御システムの概略構成を示すブロック図である。ＭＴ１０の入力部１１は、テンキーパッドを有し、ユーザがテンキーパッドを操作することにより、信号を入力することができる。一方、ＰＣ２０の入力部２１は、タッチパネル、キーボード、マウスなどの入力デバイスを有し、ユーザがこれらのデバイスを操作することにより、信号を入力することができる。ユーザが入力部１１または２１で入力した操作情報は、管理部１３または２３に転送される。ＭＴ１０の出力部１２およびＰＣ２０の出力部２２は、液晶画面を有し、情報を画面に表示する。管理部１３、２３とアプリ部１５、２５において、アプリケーションの画面表示内容が変更された場合、レンダリング処理結果を受け取って、画像として出力する。

ＭＴ１０の管理部１３およびＰＣ２０の管理部２３は、当該システム上で動作するアプリケーションの全体管理を行なう。入力部１１または２１でユーザが入力した操作情報を、該当するアプリ部１５または２５に転送する。また、アプリ部１５または２５にてレンダリング内容が変更された場合は、レンダリング処理結果を出力部１２または２２に転送する。また、管理部１３または２３は、アプリ部１５または２５から、対向するアプリ部１５または２５への転送データとして、「アプリ内データ」を受信した場合は、通信部１４または２４に転送する。

ＭＴ１０の通信部１４またはＰＣ２０の通信部２４は、管理部１３または２３から受信した「アプリ内データ」を相手端末に伝送する。本実施形態では、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信デバイスを利用したものを示し、かつ、Ｂｌｕｅｔｏｏｔｈ（登録商標）の接続が確立しており、２つの端末でデータ伝送ができる状態にあることを前提とする。また、対向通信部から「アプリ内データ」を受信した場合は、管理部１３または２３に転送する。

ＭＴ１０のアプリ部１５またはＰＣ２０のアプリ部２５は、本システム上で動作する任意のアプリケーションである。本システムでは、１以上のアプリケーションが動作していても良い。ＭＴ１０のインターネット通信部１６は、アプリ部１５がサーバと連携してデータをダウンロードしたり、データをアップロードしたりする。

図３は、管理部１３または２３の概略構成を示すブロック図である。管理部１３、２３は、通信管理部３０と、アプリ管理部３１０と、主管理部３２０と、から構成される。通信管理部３０は、送信データ制御部３０ａ、受信データ制御部３０ｂおよび通信連携部３０ｃから構成され、アプリ管理部３１０は、アプリ管理テーブル３１０ａを備える。主管理部３２０は、管理部１３、２３の全体を管理する。

アプリ連携部３１０ｂは、上位のアプリ部１５、２５と連携するためのインタフェースの役目を果たす。アプリ部１５、２５からアプリ管理部３１０へ、あるいは、アプリ管理部３１０からアプリ部１５、２５へのデータ転送を行なう。アプリ管理部３１０は、アプリ管理テーブル３１０ａを参照しながら、アプリ部１５、２５から転送要求のあるアプリ内データを、相手端末へデータ転送するよう、送信データ制御部３０ａに通知する。また、受信データ制御部３０ｂから転送要求のあるアプリ内データに関して、アプリ部１５、２５へデータ転送するよう、アプリ連携部３１０ｂに通知する。

通信連携部３０ｃは、通信部１４、２４と連携しながら、相手端末とのデータ送受信を制御する。送信データ制御部３０ａは、アプリ管理部３１０から転送要求のあるアプリ内データに関して、伝送制御しながら、通信連携部３０ｃに伝送データを転送する。伝送制御では、後述するように、２種類の伝送キューを利用する。受信データ制御部３０ｂは、通信連携部３０ｃから転送要求のあるアプリ内データに関して、受信制御しながら、アプリ管理部３１０に伝送データを転送する。

図４は、図３で示したアプリ管理テーブル３１０ａに登録される際のアプリ管理テーブルの構成例を示す図である。図４に示すアプリ管理テーブルは、アプリ識別子、アプリ名、ＭＴアプリの識別子と、ＭＴ１０におけるアプリケーションが動作するＭＴ自体の識別子、ＰＣアプリの識別子と、ＰＣ２０のアプリケーションが動作するＰＣ自体の識別子から構成される。これにより、本管理部１３、２３上で動作するアプリケーションを複数動作させることができる。また、管理部１３、２３は、どのアプリケーションから受信したデータであるか、どのアプリケーションに送信すべきデータであるかを把握することができる。

本システム上で動作する任意のアプリケーションは、インターネット通信部１６から携帯電話通信網を利用して、ウェブサーバ上からダウンロードする。ダウンロードするアプリケーションは、ＭＴ１０用およびＰＣ２０用の両方であり、ダウンロードしたＭＴ１０用アプリは、ＭＴ１０上の管理部１３上に登録される。一方、ＰＣ２０用アプリは、通信部１４、２４を介してＰＣ２０上の管理部２３上に登録される。

また、ＰＣ２０は、携帯電話通信網を経由してダウンロードせず、ＵＳＢメモリなどの外部機器を接続してデータをコピーしたり、ＷｉＦｉ（登録商標）などを利用してサーバからダウンロードしたりしてもよい。アプリ情報の登録時、双方の管理部１３、２３では、登録したアプリの通信相手となるアプリの識別情報とともに、管理しているアプリケーションを「アプリ管理テーブル」に登録する。これにより、相手の管理部１３、２３は、どのアプリケーションから届いたデータであるか、どのアプリケーションに届けるべきデータであるかを把握することができる。また、携帯電話機内蔵のＢｌｕｅｔｏｏｔｈ（登録商標）伝送路は１本しか確立できないため、複数のアプリケーションを並行して動作させる場合、複数のアプリケーションのデータを伝送する必要がある。このとき、双方の管理部にて生成するＢｌｕｅｔｏｏｔｈ（登録商標）伝送データ内に、伝送元と伝送先の情報を埋め込むことによって、１つのデータストリームを生成し、複数アプリの同時起動を可能にする。

次に、アプリ部１５または２５（送信元アプリ部）から、対向のアプリ部１５または２５（送信先アプリ部）へのアプリ内データの伝送において、管理部１３、２３内の各モジュールにおけるデータ処理方法について説明する。図５は、送信元アプリ部が、送信先アプリ部へアプリ内データの送信を要求する時に、送信元アプリ部が管理部（アプリ連携部）に通知するデータ（「第１送信データ」）の構成を示す図である。

「第１送信データ」は、送信元アプリ識別子、送信先アプリ識別子、送信対象となるアプリ内データのデータサイズ、アプリ内データのメモリ上の先頭アドレス、後述する送信キューの識別子および送信完了時通知情報から構成される。ここで、送信元アプリ識別子、および、送信先アプリの識別子は、アプリ管理テーブル３１０ａに記載された情報と同じである。

また、送信完了時通知情報は、アプリ部１５、２５が対向端末に対してアプリ内データを送信完了した際に、アプリ連携部３１０ｂがアプリ部１５、２５に通知するための情報である。送信完了時通知情報に「ｎｕｌｌ」がある場合は、送信完了通知を、アプリ部１５、２５に返信しないようにもできる。つまり、アプリケーションの機能によっては、データの送信が完了した際に、その確認メッセージが必要な場合もあれば、必要でない場合も存在する。このため、「ｎｕｌｌ」と指定することで、確認メッセージが必要でないことを指定できるようにできる。これにより、ＵＤＰ（User Datagram Protocol）のような一方通行のデータ転送を行なうことができる。これは、サンプリング周期が微小なアプリ内データ（例えば１００ｍｓ以内のセンサデータなど）を伝送する際に有効である。

アプリ連携部３１０ｂは、各アプリ部１５、２５から通知される「第１送信データ」を順次、アプリ管理部３１０に転送する。アプリ管理部３１０は、上記「第１送信データ」および「アプリ管理テーブル３１０ａ」に基づいて、送信データ制御部３０ａに転送するデータ「第２送信データ」に変換する。

図６は、アプリ管理部が、送信データ制御部に通知する「第２送信データ」の構成を示す図である。「第２送信データ」は、「第１送信データ」に対して、「送信元端末識別子」、「送信先端末識別子」が追加される。送信データ制御部３０ａは、「第２送信データ」を後述する送信キューに挿入する。また、送信データ制御部３０ａは、送信キューから、伝送対象となったデータを読み込み、「通信データパケット」に変換し、通信連携部３０ｃに転送する。なお、送信キューは、２種類存在する。双方のキューからのデータ読み込み方法は後述する。

図７は、通信連携部に通知する「通信データパケット」の構成を示す図である。「通信データパケット」は、「第２送信データ」に対して、「送信完了時通知情報」の代わりに「パケット識別子」が付与される。通信連携部３０ｃは、「通信データパケット」を順次通信部１４、２４に転送する。これにより、通信部１４、２４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの通信モジュールを利用して、通信データパケットを接続中の送信先端末に伝送する。一方、通信データパケットを受信した送信先端末は、上記と逆方向の処理により、そのデータ本体を、該当するアプリ部１５、２５に転送する。

図８は、送信データ制御部の概略構成を示す図である。本システムにおいて、携帯電話機内蔵のＢｌｕｅｔｏｏｔｈ（登録商標）伝送路は、１本しか確立することができない。そのため、複数のアプリケーションが動作していても、１つのみのデータストリームを生成する必要がある。また、複数のアプリケーションにも、さまざまな特徴があり、アプリケーションに応じて種々の動作態様がある。つまり、画像データなどのある程度大きいデータサイズをもつものを相手端末に伝送する場合、あるいは、文字入力時などのセンサ検出データなどの微小なデータサイズをもつものを相手端末に伝送する場合がある。例えば、画像データを伝送している最中に、文字入力を行なう場合、データストリームの構成次第では、画像データの伝送が終了しなければ、文字入力データが伝送されず、文字入力のレスポンスが遅延する可能性がある。

そこで、本実施形態では、データの伝送を効率化させるため、送信データ制御部には２つのキューで構成する。１つは「高速キュー８１ａ」であり、もう１つは「低速キュー８１ｂ」である。キュー挿入部８２は、双方のキュー８１ａ、８１ｂに対するデータ挿入処理を制御し、キュー読出部８３は、双方のキュー８１ａ、８１ｂからのデータ読出処理を制御する。

低速キュー８１ｂは、データ送受信の前に、データ送受信の確認を双方で行なった上で、データ送信を行なうために利用する。一方、高速キュー８１ａは、低速キュー８１ｂのようにデータ送受信前の確認を行なわず、一方的にデータ送信を行なうために利用する。「アプリ内データ」を伝送するアプリ部１５、２５からの指定情報を参照して、キュー挿入部８２は、受信したデータをどちらのキュー８１ａ、８１ｂに挿入するかを判別し、いずれかのキュー８１ａまたは８１ｂに蓄積する。

図９は、キュー挿入部８２の動作を示すフローチャートである。キュー挿入部８２は、まず、処理が終了しているかどうかを判断し（ステップＳ９０）、処理が終了している場合には終了する。一方、ステップＳ９０において、処理が終了していない場合は、データ挿入要求があるかどうかを判断する（ステップＳ９１）。データ挿入要求がない場合は、ステップＳ９０へ遷移し、データ挿入要求がある場合は、高速キューへの挿入要求があるかどうかを判断する（ステップＳ９２）。高速キューへの挿入要求がある場合は、高速キューへの挿入が可能であるかどうかを判断し（ステップＳ９３）、高速キューへの挿入が可能である場合は、データを高速キューに挿入して（ステップＳ９４）、ステップＳ９０へ遷移する。

一方、ステップＳ９３において、高速キューへの挿入が可能でない場合は、エラー応答を行なって（ステップＳ９５）、ステップＳ９０へ遷移する。また、ステップＳ９２において、高速キューへの挿入要求が無い場合は、低速キューへの挿入要求があるかどうかを判断する（ステップＳ９６）。低速キューへの挿入要求がある場合は、低速キューへの挿入が可能であるかどうかを判断し（ステップＳ９７）、低速キューへの挿入が可能である場合は、データを低速キューに挿入して（ステップＳ９８）、ステップＳ９０へ遷移する。

また、ステップＳ９６において、低速キューへの挿入要求が無い場合、およびステップＳ９７において、低速キューへの挿入が可能でない場合は、エラー応答を行なって（ステップＳ９９）、ステップＳ９０へ遷移する。

図１０は、キュー読出部８３の動作を示すフローチャートである。キュー読出部８３は、キュー挿入とは非同期に、それぞれのキューに蓄積されたデータを読み出す。図１０に示すように、キュー読出部８３は、処理が終了しているかどうかを判断し（ステップＳ１００）、処理が終了している場合には終了する。一方、ステップＳ１００において、処理が終了していない場合は、高速キュー内にデータがあるかどうかを判断し（ステップＳ１０１）、高速キュー内にデータがある場合は、高速キューからデータの読み込みを行なう（ステップＳ１０２）。一方、ステップＳ１０１において、高速キュー内にデータがない場合は、低速キュー内にデータがあるかどうかを判断する（ステップＳ１０３）。低速キュー内にデータがない場合は、ステップＳ１００へ遷移し、低速キュー内にデータがある場合は、低速キューからデータの読み込みを行なう（ステップＳ１０４）。そして、ステップＳ１０２またはステップＳ１０４において読み込んだデータを通信連携部３０ｃに転送して（ステップＳ１０５）、ステップＳ１００へ遷移する。

なお、本実施形態では、データパケット内に、挿入するキューの種別を指定するような構成としたが、伝送データの特徴、あるいはアプリ開発者の意向により、伝送データに優先度をつけるような構成にしてもよい。優先度は、転送データのデータサイズ、アプリケーションの優先度、データ種別などに基づくものとする。

また、ＭＴ１０の通信部１４とＰＣ２０の通信部２４との間では、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信を利用して、一方から他方へデータを転送する。このときのデータ転送制御は、従来のＢｌｕｅｔｏｏｔｈ（登録商標）のＳＰＰ（System Platform Processor）などの規格に従う。

次に、受信したキューの処理について説明する。通信部１４、２４は、対向端末から受信した「通信データパケット」を、以下のような「第１受信データ」に変換する。図１１は、「第１受信データ」の構成を示す図である。図１１に示すように、第１受信データは、図７に示した通信データパケットと同様の構成を採る。通信連携部３０ｃは、この第１受信データを受信データ制御部３０ｂに転送する。

図１２は、受信データ制御部３０ｂの概略構成を示す図である。受信データ制御部３０ｂは、高速キュー１２０ａと低速キュー１２０ｂとを備える。高速キュー１２０ａは、データ送受信前の確認を行なわず、一方的にデータ転送を行なうものである。低速キュー１２０ｂは、データ送受信の前に、データ送受信の確認を双方で行なうための者である。キュー挿入部１２２は、「第１受信データ」を、どちらのキュー１２０ａ、１２０ｂに挿入するかを判別し、いずれかのキューに蓄積する。

図１３は、キュー挿入部１２２の動作を示すフローチャートである。キュー挿入部１２２は、まず、処理が終了したかどうかを判断し（ステップＳ１３０）、処理が終了した場合は、終了する。一方、ステップＳ１３０において、処理が終了していない場合は、データ挿入要求があるかどうかを判断する（ステップＳ１３１）。データ挿入要求がない場合はステップＳ１３０へ遷移し、データ挿入要求がある場合は、高速キューの挿入要求があるかどうかを判断する（ステップＳ１３２）。高速キューの挿入要求がある場合は、高速キューにデータを挿入可能であるかどうかを判断する（ステップＳ１３３）。高速キューにデータの挿入が可能である場合は、高速キューにデータを挿入して（ステップＳ１３４）、ステップＳ１３０へ遷移する。

一方、ステップＳ１３３において、高速キューにデータを挿入可能でない場合は、エラー応答を行なって（ステップＳ１３５）、ステップＳ１３０へ遷移する。また、ステップＳ１３２において、高速キューへデータの挿入要求がない場合は、低速キューへのデータの挿入要求があるかどうかを判断する（ステップＳ１３６）。低速キューへのデータの挿入要求がある場合は、低速キューへデータを挿入可能であるかどうかを判断する（ステップＳ１３７）。低速キューへデータを挿入可能である場合は、低速キューへデータを挿入して（ステップＳ１３８）、ステップＳ１３０へ遷移する。

一方、ステップＳ１３６において、低速キューへのデータの挿入要求がない場合、または、ステップＳ１３７において、低速キューへデータを挿入可能でない場合は、エラー応答を行なって（ステップＳ１３９）、ステップＳ１３０へ遷移する。

一方、キュー読込部１２１は、キュー挿入とは非同期に、それぞれのキューに蓄積されたデータを読み出す。図１４は、キュー読込部１２１の動作を示すフローチャートである。図１４に示すように、キュー読込部１２１は、処理が終了しているかどうかを判断し（ステップＳ１４０）、処理が終了している場合には終了する。一方、ステップＳ１４０において、処理が終了していない場合は、高速キュー内にデータがあるかどうかを判断し（ステップＳ１４１）、高速キュー内にデータがある場合は、高速キューからデータの読み込みを行なう（ステップＳ１４２）。一方、ステップＳ１４１において、高速キュー内にデータがない場合は、低速キュー内にデータがあるかどうかを判断する（ステップＳ１４３）。低速キュー内にデータがない場合は、ステップＳ１４０へ遷移し、低速キュー内にデータがある場合は、低速キューからデータの読み込みを行なう（ステップＳ１４４）。そして、ステップＳ１４２またはステップＳ１４４において読み込んだデータをアプリ管理部３１０に転送して（ステップＳ１４５）、ステップＳ１４０へ遷移する。

アプリ管理部３１０は、受信データ制御部３０ｂから転送された「第１受信データ」および「アプリ管理テーブル」に基づいて、アプリ連携部３１０ｂに転送するデータ「第２受信データ」に変換する。図１５は、アプリ管理部３１０が、アプリ連携部３１０ｂに転送する「第２受信データ」の構成を示す図である。図１５に示すように、第２受信データは、図６に示した第２送信データと同様の構成を採る。アプリ連携部３１０ｂは、順次「第２受信データ」をアプリ部１５、２５に転送する。

次に、以下、送信元アプリ部１５または２５で発生した伝送データを、送信元管理部１３または２３、送信先管理部１３または２３を介して、送信先アプリ部１５または２５に伝送するまでの動作を、データ種別ごとに説明する。図１６は、高速キューを使ってＡＣＫを返すとして送信する場合の動作を示すフローチャートである。ここでは、送信元がＭＴ１０、送信先がＰＣ２０であるとして説明する。

まず、送信元であるＭＴ１０における送信元アプリ部１５が、送信元管理部１３に対して送信要求を行なう（ステップＳ１６０）。送信元管理部１３は、伝送可能判定を行ない（ステップＳ１６１）、この判定結果を送信元アプリ部１５へ送信する（ステップＳ１６２）。送信元アプリ部１５は、送信元管理部１３から判定結果を受信する（ステップＳ１６３）。次に、ステップＳ１６１において、伝送可能である場合は、送信元管理部１３は、送信先管理部２３に対してデータ送信を行なう（ステップＳ１６４）。送信先管理部２３は、送信元管理部１３からデータを受信すると（ステップＳ１６５）、送信先アプリ部２５に対して、受信通知を送信する（ステップＳ１６６）。送信先アプリ部２５は、送信先管理部２３から受信通知を受信し（ステップＳ１６７）、データを受信する（ステップＳ１６８）。

一方、送信元管理部２３は、送信元管理部１３に対して、ステップＳ１６５においてデータ受信が成功したことを通知する受信完了通知を行なう（ステップＳ１６９）。送信元管理部１３は、送信元管理部２３から受信完了通知を受信すると、それを送信元アプリ部１５に送信し（ステップＳ１７０）、送信元アプリ部１５は、受信完了通知を受信する（ステップＳ１７１）。

図１７は、高速キューを使ってＡＣＫを返さないとして送信する場合の動作を示すフローチャートである。ここでは、送信元がＭＴ１０、送信先がＰＣ２０であるとして説明する。まず、送信元であるＭＴ１０における送信元アプリ部１５が、送信元管理部１３に対して送信要求を行なう（ステップＳ１７２）。送信元管理部１３は、伝送可能判定を行ない（ステップＳ１７３）、この判定結果を送信元アプリ部１５へ送信する（ステップＳ１７４）。送信元アプリ部１５は、送信元管理部１３から判定結果を受信する（ステップＳ１７５）。次に、ステップＳ１７３において、伝送可能である場合は、送信元管理部１３は、送信先管理部２３に対してデータ送信を行なう（ステップＳ１７６）。送信先管理部２３は、送信元管理部１３からデータを受信すると（ステップＳ１７７）、送信先アプリ部２５に対して、受信通知を送信する（ステップＳ１７８）。送信先アプリ部２５は、送信先管理部２３から受信通知を受信し（ステップＳ１７９）、データを受信する（ステップＳ１８０）。

図１８は、低速キューを使ってＡＣＫを返すとして送信する場合の動作を示すフローチャートである。ここでは、送信元がＭＴ１０、送信先がＰＣ２０であるとして説明する。

まず、送信元であるＭＴ１０における送信元アプリ部１５が、送信元管理部１３に対して送信要求を行なう（ステップＳ１８１）。送信元管理部１３は、伝送可能判定を行ない（ステップＳ１８２）、この判定結果を送信元アプリ部１５へ送信する（ステップＳ１８３）。送信元アプリ部１５は、送信元管理部１３から判定結果を受信する（ステップＳ１８４）。次に、ステップＳ１８２において、伝送可能である場合は、送信元管理部１３は、送信先管理部２３に対して送信要求通知を行なう（ステップＳ１８５）。送信先管理部２３は、送信元管理部１３から送信要求通知を受信すると、送信先アプリ部２５に対して、送信要求通知を送信する（ステップＳ１８６）。送信先アプリ部２５は、送信先管理部２３から送信要求通知を受信し（ステップＳ１８７）、送信要求応答を返す（ステップＳ１８８）。

送信先管理部２３は、送信先アプリ部２５から送信要求応答を受信すると、それを送信元管理部１３に送信する（ステップＳ１８９）。送信元管理部１３は、送信先管理部２３から送信要求応答を受信すると（ステップＳ１９０）、送信先管理部２３に対して、データの送信を行なう（ステップＳ１９１）。送信先管理部２３は、送信元管理部１３からデータを受信すると（ステップＳ１９２）、送信先アプリ部２５に対して、データの受信通知を送信する（ステップＳ１９３）。送信先アプリ部２５は、送信先管理部２３から受信通知を受信し（ステップＳ１９４）、データを受信する（ステップＳ１９５）。

また、送信先管理部２３は、ステップＳ１９２において、データを受信した場合は、送信元管理部１３に対して、受信完了通知を送信する（ステップＳ１９６）。送信元管理部１３は、送信先管理部２３から受信完了通知を受信すると、その受信完了通知を送信元アプリ部１５に送信する（ステップＳ１９７）。送信元アプリ部１５は、送信元管理部１３から受信完了通知を受信する（ステップＳ１９８）。

図１９は、低速キューを使ってＡＣＫを返さないとして送信する場合の動作を示すフローチャートである。ここでは、送信元がＭＴ１０、送信先がＰＣ２０であるとして説明する。

まず、送信元であるＭＴ１０における送信元アプリ部１５が、送信元管理部１３に対して送信要求を行なう（ステップＳ１９９）。送信元管理部１３は、伝送可能判定を行ない（ステップＳ２００）、この判定結果を送信元アプリ部１５へ送信する（ステップＳ２０１）。送信元アプリ部１５は、送信元管理部１３から判定結果を受信する（ステップＳ２０２）。次に、ステップＳ２００において、伝送可能である場合は、送信元管理部１３は、送信先管理部２３に対して送信要求通知を行なう（ステップＳ２０３）。送信先管理部２３は、送信元管理部１３から送信要求通知を受信すると、送信先アプリ部２５に対して、送信要求通知を送信する（ステップＳ２０４）。送信先アプリ部２５は、送信先管理部２３から送信要求通知を受信し（ステップＳ２０５）、送信要求応答を返す（ステップＳ２０６）。

送信先管理部２３は、送信先アプリ部２５から送信要求応答を受信すると、それを送信元管理部１３に送信する（ステップＳ２０７）。送信元管理部１３は、送信先管理部２３から送信要求応答を受信すると（ステップＳ２０８）、送信先管理部２３に対して、データの送信を行なう（ステップＳ２０９）。送信先管理部２３は、送信元管理部１３からデータを受信すると（ステップＳ２１０）、送信先アプリ部２５に対して、データの受信通知を送信する（ステップＳ２１１）。送信先アプリ部２５は、送信先管理部２３から受信通知を受信し（ステップＳ２１２）、データを受信する（ステップＳ２１３）。

（第２の実施形態）
第２の実施形態に係る分散機器相互制御システムは、自己アプリケーションに実行すべき機能が存在せず、他の情報処理装置が有する他のアプリケーションに実行すべき機能が存在する場合は、他の情報処理装置に対して、他のアプリケーションを実行する旨の信号を出力する。そして、自己アプリケーションの実行結果を表示し、または他の情報処理装置から入力した他のアプリケーションの実行結果を表示する。

図２０は、第２の実施形態に係る管理部１３または２３の概略構成を示すブロック図である。第１の実施形態に係る管理部１３または２３の一部の構成が異なる。このため、共通の構成には同じ番号を付すものとする。第２の実施形態に係る管理部１３、２３は、通信管理部３０と、アプリ制御部３１と、から構成される。通信管理部３０は、送信データ制御部３０ａ、受信データ制御部３０ｂおよび通信連携部３０ｃから構成され、アプリ制御部３１は、アプリ制御用ライブラリ部３１ａおよびアプリ連携部３１ｂから構成される。

アプリ連携部３１ｂは、上位のアプリ部１５、２５と連携するためのインタフェースの役目を果たす。アプリ部１５、２５からアプリ制御部３１へ、あるいは、アプリ制御部３１からアプリ部１５、２５へのデータ転送を行なう。アプリ制御部３１は、アプリ情報３２および機能情報３３を参照しながら、アプリ部１５、２５から転送要求のあるアプリ内データを、相手端末へデータ転送するよう、送信データ制御部３０ａに通知する。また、受信データ制御部３０ｂから転送要求のあるアプリ内データに関して、アプリ部１５、２５へデータ転送するよう、アプリ連携部３１ｂに通知する。

通信連携部３０ｃは、通信部１４、２４と連携しながら、相手端末とのデータ送受信を制御する。送信データ制御部３０ａは、図８に示す第１の実施形態と同様の構成を採り、同様の機能を果たす。そして、アプリ制御部３１から転送要求のあるアプリ内データに関して、伝送制御しながら、通信連携部３０ｃに伝送データを転送する。受信データ制御部３０ｂは、図１２に示す第１の実施形態と同様の構成を採り、同様の機能を果たす。そして、通信連携部３０ｃから転送要求のあるアプリ内データに関して、受信制御しながら、アプリ制御部３１に伝送データを転送する。

アプリ制御用ライブラリ部３１ａは、上位のアプリ部１５、２５に登録されたアプリケーションが、本システム上で他のアプリと連携動作するために必要な機能群である。端末間の無線通信接続機能、通信連携部を介したデータ送受信機能、２つの端末に共通なデータフォルダを利用したファイル操作機能、液晶画面への描画機能などを有する。また、機能情報には、各端末が有する機能に関する情報があり、アプリケーションが動作する際、この情報を利用して、自端末上の機能を利用するか、対向端末上の機能を利用するかを決定する。

図２１は、図２０で示したアプリ情報３２に登録される際のアプリ情報テーブルの構成例を示す図である。本システム上で動作する任意のアプリケーションは、インターネット通信部１６から携帯電話通信網を利用して、ウェブサーバ上からダウンロードする。ダウンロードするアプリケーションは、ＭＴ１０用およびＰＣ２０用の両方であり、ダウンロードしたＭＴ１０用アプリは、ＭＴ１０上の管理部１３上に登録される。一方、ＰＣ２０用アプリは、通信部１４、２４を介してＰＣ２０上の管理部２３上に登録される。

また、ＰＣ２０は、携帯電話通信網を経由してダウンロードせず、ＵＳＢメモリなどの外部機器を接続してデータをコピーしたり、ＷｉＦｉなどを利用してサーバからダウンロードしたりしてもよい。アプリ情報の登録時、双方の管理部１３、２３では、登録したアプリの通信相手となるアプリの識別情報とともに、管理しているアプリを「アプリ情報テーブル」に登録する。

図２１に示すアプリ情報テーブルは、アプリ識別子、アプリ名、ＭＴアプリの識別子と、ＭＴ１０におけるアプリケーションが動作するＭＴ１０自体の識別子、ＰＣ２０アプリケーションの識別子と、ＰＣ２０のアプリケーションが動作するＰＣ２０自体の識別子から構成される。これにより、本管理部１３、２３上で動作するアプリケーションを複数動作させることができる。また、管理部１３、２３は、どのアプリケーションから受信したデータであるか、どのアプリケーションに送信すべきデータであるかを把握することができる。

図２２は、図２０で示した機能情報３３に登録される機能情報テーブルの構成例を示す図である。この機能情報テーブルでは、本システム上で動作させる任意のアプリケーションが動作するのに必要なＭＴ１０およびＰＣ２０が有している機能を、それぞれ管理する。図２２に示すように、機能情報テーブルは、機能識別子、機能名、機能利用に必要なデバイス、機能利用時に必要な入力データ形式、機能利用後の出力データ形式、機能利用にあたっての制約事項（ルール）から構成される。これにより、双方の端末が有する機能情報を参照することができる。アプリ制御用ライブラリ３１ａおよびアプリ制御部３１は、この情報を利用して、上位で動作するアプリケーションが正常に動作するための機能が存在するかどうかを判断する。

次に、図２０で示したアプリ制御用ライブラリ３１ａについて説明する。本システムでは、以下のアプリ制御用ライブラリを想定している。

（１）無線通信接続機能
無線通信接続機能は、双方の端末上で動作するアプリケーション間でデータの送受信を行なうために、近距離無線通信デバイスを利用した接続確立、データ送受信路の確立を行なう。

（２）データ送受信機能
データ送受信機能は、双方の端末上で動作するアプリケーション間で、データの送受信を行なう。

（３）ファイル操作機能
ファイル操作機能は、双方のアプリケーションからアクセス可能なデータフォルダ、およびデータファイルを備え、データファイルに対する編集などのファイル操作を行なう。

（４）描画機能
描画機能は、一方の端末から、自端末の液晶画面への描画だけでなく、対向端末の液晶画面への描画をも行なう。

（５）ＭＴ保有機能
ＭＴ保有機能は、ＭＴが有する機能やデバイスを利用する。例えば、カメラを利用する機能（カメラを起動する、設定する、撮影する、終了する）、ＧＰＳを利用する（ＧＰＳ機能を起動する、ＧＰＳ情報を取得する、終了する）、アドレス帳を参照する（アドレス帳を起動する、アドレス帳を検索する、情報を取得する、終了する）、ネットワーク機能を利用する（Ｗｅｂサーバに接続する、Ｗｅｂサーバから該当情報をダウンロードする、通信接続を切断する）などがある。

（６）ＰＣ保有機能
ＰＣ保有機能は、ＰＣが有する機能やデバイスを利用する。例えば、計算能力を利用する機能（ＣＰＵを利用する、メモリを利用する）、入力インタフェースデバイスを利用する機能（タッチパネル、マウス、キーボードなどからの入力を受信する）などがある。

次に、本実施形態におけるアプリケーションの制御方法について説明する。各アプリケーションは、利用したい機能をアプリ制御部３１に要求する。このとき、アプリ制御部３１は、自端末上に、当該機能を処理できるライブラリを保有しているかどうかをチェックする。自端末上で当該機能を処理できるライブラリを保有している場合、アプリ制御部３１にてライブラリ処理した後、その結果を、アプリ部１５、２５に通知する。

一方、自端末上に当該機能を処理できるライブラリを保有していない場合、対向のアプリ制御部３１に、同じ要求を行なう。対向のアプリ制御部３１は、自端末上に、当該機能を処理できるライブラリを保有しているかどうかをチェックする。アプリ部１５、２５を介して、該当するライブラリ処理した後、その結果を、同アプリ制御部３１を介して、元アプリ制御部３１、および、アプリ部１５、２５に通知する。

図２３は、相手端末上のライブラリを利用する場合のシーケンスチャートである。ここでは、ＭＴ１０が、ＰＣ２０のライブラリを利用する場合について説明する。まず、ＭＴ１０のアプリ部１５が、タスク処理を開始する（ステップＳ７１）。次に、アプリ部１５がアプリ制御部３１（ＭＴ）に対してライブラリの呼び出しを要求する（ステップＳ７２）。アプリ制御部３１（ＭＴ）は、アプリ部１５からのライブラリ呼び出しを受けて、呼び出しについて判定を行なう（ステップＳ７３）。すなわち、呼び出しを受けたライブラリが自端末に存在するかどうかを判定する。アプリ制御部３１（ＭＴ）は、呼び出しを受けたライブラリが自端末に存在しないため、ＰＣ２０に対して呼び出し転送を行なう（ステップＳ７４）。

一方、ＰＣ２０のアプリ制御部３１（ＰＣ）は、ＭＴ１０のアプリ制御部３１（ＭＴ）から呼び出し転送を受信すると、呼び出し判定を行なう（ステップＳ７５）。すなわち、アプリ制御部３１（ＰＣ）は、呼び出しを受けたライブラリが自端末に存在するかどうかを判定する。アプリ制御部３１（ＰＣ）は、呼び出しを受けたライブラリが自端末に存在するため、アプリ部２５に対してライブラリを呼び出し（ステップＳ７６、Ｓ７７）、ライブラリ処理を行なう（ステップＳ７８）。そして、ライブラリ処理結果をアプリ部２５に通知する（ステップＳ７９）。

アプリ部２５は、アプリ制御部３１（ＰＣ）からライブラリ処理結果を受信すると（ステップＳ８０）、結果通知を出力する（ステップＳ８１）。この結果通知は、アプリ制御部３１（ＰＣ）を経由して、ＭＴ１０のアプリ制御部３１（ＭＴ）に送信される（ステップＳ８２）。ＭＴ１０のアプリ制御部３１（ＭＴ）は、ＰＣ２０のアプリ制御部３１（ＰＣ）からライブラリ処理結果通知を受信すると（ステップＳ８３）、アプリ部１５に対して結果通知を行なう。アプリ部１５は、アプリ制御部３１（ＭＴ）から結果通知を受信すると（ステップＳ８４）、タスク処理を終了する（ステップＳ８５）。

なお、以上のように双方で保有するライブラリを利用して処理した結果を、双方の液晶画面に出力表示する場合についても、同様にシーケンスチャートに表すことができる。すなわち、アプリ部１５、２５は、出力内容を作成した後、アプリ制御部３１に表示要求を行なう。このとき、出力する端末が、自端末である場合は、アプリ制御部３１は、自端末上に表示されるようにライブラリ処理を行なう。一方、対向端末に出力する場合は、アプリ制御部３１は、ライブラリ処理を行ないながら、対向端末の液晶画面に出力する。

以上説明したように、本発明は、第１の実施形態のように、データ送信を行なう際に、高速キューと低速キューとを使い分けることができるものであると共に、第２の実施形態のように、ＭＴにはない機能で、ＰＣにある機能を、ＭＴから実行させることができるものである。従って、第１および第２の実施形態を組み合わせて実施することが可能である。すなわち、第２の実施形態のように、ＭＴにはない機能で、ＰＣにある機能を、ＭＴから実行させる際に、高速キューと低速キューとを使い分けることができる。

このような本発明に係る実施形態を用いて、新たなサービスを提供することができる。すなわち、ユーザが、２つの携帯電話機または、一つの携帯電話機と一つのＰＣを持ち歩くシーンが想定される。本実施形態によれば、２つの携帯端末の両方から、ユーザインタラクションを可能とするサービスを提供することが可能となる。すなわち、近時、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信手段を搭載している携帯電話機のニーズが拡大している。このため、携帯電話機が持っている機能で、かつＰＣが持っていない機能を使う場合に、ＰＣから携帯電話機の機能を用いる。一方、ＰＣが持っている機能で、かつ携帯電話機が持っていない機能を使う場合は、携帯電話機からＰＣの機能を用いる。本発明は、このような利用態様を実現するものである。さらに、近距離無線通信手段におけるセキュリティを強化するために、携帯電話機、ＰＣおよびユーザの三者が揃ったときにのみ、携帯電話機およびＰＣが利用可能となる仕組みを提供する。ここでは、例えば、生体認証技術や秘密分散技術を用いる。また、近距離無線通信手段を用いたデータ伝送速度を確保し、特に、データ伝送の遅延を回避する仕組みを提供する。そして、データの優先度に応じて、複数のキュー、例えば、高速キューと低速キューとを使い分けることによって、ユーザインタフェースに関するユーザビリティを向上させる。更に、近距離無線通信手段が常時起動することによる電池の消費量を削減する仕組みを提供する。

これにより、ユーザのいわゆる“２台持ち”の状況となった場合に、ユーザのニーズに十分に応え得るサービスの提供が可能となる。

以上説明したように、本実施形態によれば、他の情報処理装置に対してデータを送信する際に、優先度に対応するキューを選択し、選択したキューに送信するデータを格納し、優先度の高いキューから順次データを読み出すので、予め定められた優先度に応じて効率的に送信データの処理を行なうことが可能となる。特に、他の情報処理装置との伝送路が１本しか確立できない場合に複数のアプリケーションを並行して動作させる場合、１つのデータストリームを生成することで、複数のアプリケーションのデータを送受信することが可能となる。また、ＭＴ１０またはＰＣ２０のいずれか一方は、いずれか他方が有している機能を利用することが可能となる。また、１つのタスクを２つの携帯端末を用いて処理することが可能となる。ユーザは、ＴＰＯに応じて利用する携帯端末を自由に選択することが可能となる。

本実施形態に係る分散機器相互制御システムの概念を示す図である。 本実施形態に係る分散機器相互制御システムの概略構成を示すブロック図である。 管理部の概略構成を示すブロック図である。 図３で示したアプリ管理テーブル３１０ａに登録される際のアプリ管理テーブルの構成例を示す図である。 送信元アプリ部が、送信先アプリ部へアプリ内データの送信を要求する時に、送信元アプリ部が管理部（アプリ連携部）に通知するデータ（「第１送信データ」）の構成を示す図である。 アプリ管理部が、送信データ制御部に通知する「第２送信データ」の構成を示す図である。 通信連携部に通知する「通信データパケット」の構成を示す図である。 送信データ制御部の概略構成を示す図である。 キュー挿入部８２の動作を示すフローチャートである。 キュー読出部８３の動作を示すフローチャートである。 第１受信データの構成を示す図である。 受信データ制御部３０ｂの概略構成を示す図である。 キュー挿入部１２２の動作を示すフローチャートである。 キュー読込部１２１の動作を示すフローチャートである。 アプリ管理部３１０が、アプリ連携部３１０ｂに転送する「第２受信データ」の構成を示す図である。 高速キューを使ってＡＣＫを返すとして送信する場合の動作を示すフローチャートである。 高速キューを使ってＡＣＫを返さないとして送信する場合の動作を示すフローチャートである。 低速キューを使ってＡＣＫを返すとして送信する場合の動作を示すフローチャートである。 低速キューを使ってＡＣＫを返さないとして送信する場合の動作を示すフローチャートである。 第２の実施形態に係る管理部１３または２３の概略構成を示すブロック図である。 図２０で示したアプリ情報３２に登録される際のアプリ情報テーブルの構成例を示す図である。 図２０で示した機能情報３３に登録される機能情報テーブルの構成例を示す図である。 相手端末上のライブラリを利用する場合のシーケンスチャートである。

符号の説明

１０ ＭＴ
１１、２１ 入力部
１２、２２ 出力部
１３、２３ 管理部
１４、２４ 通信部
１５、２５ アプリ部
１６ インターネット通信部
３０ 通信管理部
３０ａ 送信データ制御部
３０ｂ 受信データ制御部
３０ｃ 通信連携部
８１ａ、１２０ａ 高速キュー
８１ｂ、１２０ｂ 低速キュー
８２、１２１ キュー挿入部
８３、１２２ キュー読出部
３１０ アプリ管理部
３１０ａ アプリ管理テーブル
３１０ｂ アプリ連携部
３２０ 主管理部

Claims (6)

1. 情報処理装置同士が近距離無線通信により接続が確立された１本の伝送路で相互に信号の送受信を行なう通信システムに適用される情報処理装置であって、
   予め優先度を高く設定された高速キューと、
   予め優先度を低く設定された低速キューと、
   他の情報処理装置に対してデータを送信する際に、前記高速キューおよび前記低速キューのうちから前記優先度に対応するキューを選択し、選択したキューに送信するデータを格納する送信側キュー挿入部と、
   前記高速キューから順次データを読み出す送信側キュー読出部と、
   前記高速キューに格納されたデータを送信する際には、データ送受信前の確認を行なわず、一方的にデータ送信を行ない、前記低速キューに格納されたデータを送信する際には、データ送受信の前に、データ送受信の確認を双方で行なった上で、データ送信を行なう通信部と、を備えることを特徴とする情報処理装置。
2. 情報処理装置同士が近距離無線通信により接続が確立された１本の伝送路で相互に信号の送受信を行なう通信システムに適用される情報処理装置であって、
   予め優先度を高く設定された高速キューと、
   予め優先度を低く設定された低速キューと、
   前記高速キューに格納されるデータを受信する際には、データ送受信前の確認を行なわず、一方的にデータ転送を行ない、前記低速キューに格納されるデータを受信する際には、
   データ送受信の前に、データ送受信の確認を双方で行なう通信部と、
   他の情報処理装置からデータを受信した際に、受信したデータに基づいて、前記高速キューおよび前記低速キューのうちから前記優先度に対応するキューを選択し、選択したキューに前記受信したデータを格納する受信側キュー挿入部と、
   前記高速キューから順次データを読み出す受信側キュー読出部と、を備えることを特徴とする情報処理装置。
3. オペレーティングシステム上で実行される少なくとも一つの自己アプリケーションを備え、
   前記自己アプリケーションは、他の情報処理装置に対してデータを送信する際に、キュー種別およびＡＣＫ（Acknowledgement）の要否を示す情報を付加することを特徴とする請求項１記載の情報処理装置。
4. 前記送信側キュー挿入部は、前記自己アプリケーションから受信したデータに付加されたキュー種別に対応するキューを選択し、選択したキューに送信するデータを格納することを特徴とする請求項３記載の情報処理装置。
5. 前記自己アプリケーションおよび他の情報処理装置で実行される他のアプリケーションの機能を示す情報を取得し、前記自己アプリケーションに実行すべき機能が存在せず、前記他のアプリケーションに実行すべき機能が存在する場合は、前記他の情報処理装置に対して、前記他のアプリケーションを実行する旨の信号を出力する制御部と、
   前記自己アプリケーションの実行結果を表示し、または前記他の情報処理装置から入力した前記他のアプリケーションの実行結果を表示する表示部と、を更に備えることを特徴とする請求項３または請求項４記載の情報処理装置。
6. 前記制御部は、前記自己アプリケーションに実行すべき機能が存在すると共に、前記他のアプリケーションにも実行すべき機能が存在する場合、前記自己アプリケーションを実行させ、または、前記他の情報処理装置に対して、前記他のアプリケーションを実行する旨の信号を出力することを特徴とする請求項５記載の情報処理装置。

Images