(57)【特許請求の範囲】
【請求項１】
ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定する段階と、
前記ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して前記遠隔バスノードから接続情報を取得する段階であって、前記接続情報は前記遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報であり、前記第2電力レベルの通信プロトコルは前記第1電力レベルの通信プロトコルよりも多量の電力を使用する、取得する段階と、
各々のローカル仮想エンドポイントが前記1つまたは複数の遠隔エンドポイントの各々に対応し、前記遠隔エンドポイントが、既知の、前記遠隔エンドポイントに固有の名前を参照しながら記述される、1つまたは複数のローカル仮想エンドポイントを生成する段階と
を備えるエンドポイント通信を促進するための方法。
【請求項２】
前記既知の名前は、前記遠隔バスノードを記述する前記既知の名前の第1部分と、前記遠隔エンドポイントを記述する前記既知の名前の第2部分とをさらに備える請求項1に記載の方法。
【請求項３】
前記既知の名前は、トランスポート型と、1つまたは複数の接続パラメータとをさらに備える請求項1に記載の方法。
【請求項４】
前記トランスポート型は、
Bluetoothベースのトランスポートプロトコルと、
UNIXベースのトランスポートプロトコルと、
TCPベースのトランスポートプロトコルと、
ユニバーサルシリアルバスベースのトランスポートプロトコル
のうちの少なくとも1つをさらに備える請求項3に記載の方法。
【請求項５】
前記トランスポート型はBluetoothベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは単一のピコネット構造のための最適化された接続情報を備える請求項3に記載の方法。
【請求項６】
前記トランスポート型はTCPベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは、前記遠隔エンドポイントに関連した前記遠隔バスノードへの最適化されたワンホップルーティングを備える請求項3に記載の方法。
【請求項７】
前記取得する段階は、
前記遠隔バスノードが利用可能であることを判定する段階に応じて、自動的に接続要求を送信する段階と、
前記送信された要求に応じて、前記接続情報を受信する段階とをさらに備える請求項1に記載の方法。
【請求項８】
前記ローカルバスノードによって、前記1つまたは複数のローカル仮想エンドポイントのうちの少なくとも1つと通信するためにローカルエンドポイントから要求を受信する段階と、
前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つに、前記要求を送信する段階と、
前記ローカルエンドポイントが前記遠隔エンドポイントへアクセスすることを認める前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つから、アクセスメッセージを受信する段階と、
前記アクセスメッセージに応じて、前記ローカルエンドポイントと前記遠隔エンドポイントの間に通信セッションを確立する段階と
をさらに備える請求項1に記載の方法。
【請求項９】
前記確立する段階は、前記第1電力レベルの通信プロトコルよりも多量の電力を使用する前記第2電力レベルの通信プロトコルを使用することを備える請求項8に記載の方法。
【請求項１０】
コンピュータにより実行可能な命令を備えたコンピュータプログラムであって、
ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることをコンピュータに判定させるための命令の第1セットと、
前記ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して前記遠隔バスノードから接続情報を前記コンピュータに取得させるための命令の第2セットあって、前記接続情報は前記遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報であり、前記第2電力レベルの通信プロトコルは前記第1電力レベルの通信プロトコルよりも多量の電力を使用する、命令の第2セットと、
各々のローカル仮想エンドポイントが前記1つまたは複数の遠隔エンドポイントの各々に対応し、前記遠隔エンドポイントが、既知の、前記遠隔エンドポイントに固有の名前を参照しながら記述される、1つまたは複数のローカル仮想エンドポイントを前記コンピュータに生成させるための命令の第3セットと
を備えるコンピュータプログラム。
【請求項１１】
前記既知の名前は、前記遠隔バスノードを記述する前記既知の名前の第1部分と、前記遠隔エンドポイントを記述する前記既知の名前の第2部分とをさらに備える請求項10に記載のコンピュータプログラム。
【請求項１２】
前記既知の名前は、トランスポート型と、1つまたは複数の接続パラメータとをさらに備える請求項10に記載のコンピュータプログラム。
【請求項１３】
前記トランスポート型は、
Bluetoothベースのトランスポートプロトコルと、
UNIXベースのトランスポートプロトコルと、
TCPベースのトランスポートプロトコルと、
ユニバーサルシリアルバスベースのトランスポートプロトコル
のうちの少なくとも1つをさらに備える請求項12に記載のコンピュータプログラム。
【請求項１４】
前記トランスポート型はBluetoothベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは単一のピコネット構造のための最適化された接続情報を備える請求項12に記載のコンピュータプログラム。
【請求項１５】
前記トランスポート型はTCPベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは、前記遠隔エンドポイントに関連した前記遠隔バスノードへの最適化されたワンホップルーティングを備える請求項12に記載のコンピュータプログラム。
【請求項１６】
前記取得するための命令は、
前記遠隔バスノードが利用可能であることを判定する段階に応じて、自動的に接続要求を送信するための命令と、
前記送信された要求に応じて、前記接続情報を受信するための命令とをさらに備える請求項10に記載のコンピュータプログラム。
【請求項１７】
前記ローカルバスノードによって、前記1つまたは複数のローカル仮想エンドポイントのうちの少なくとも1つと通信するためにローカルエンドポイントから要求を受信するための命令と、
前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つに、前記要求を送信するための命令と、
前記ローカルエンドポイントが前記遠隔エンドポイントへアクセスすることを認める前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つから、アクセスメッセージを受信するための命令と、
前記アクセスメッセージに応じて、前記ローカルエンドポイントと前記遠隔エンドポイントの間に通信セッションを確立するための命令とをさらに備える請求項10に記載のコンピュータプログラム。
【請求項１８】
前記確立するための命令は、前記第1電力レベルの通信プロトコルよりも多量の電力を使用する前記第2電力レベルの通信プロトコルを使用するための命令を備える請求項17に記載のコンピュータプログラム。
【請求項１９】
ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定するための手段と、
前記ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して前記遠隔バスノードから接続情報を取得するための手段であって、前記接続情報は前記遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報であり、前記第2電力レベルの通信プロトコルは前記第1電力レベルの通信プロトコルよりも多量の電力を使用する、取得するための手段と、
各々のローカル仮想エンドポイントが前記1つまたは複数の遠隔エンドポイントの各々に対応し、前記遠隔エンドポイントが、既知の、前記遠隔エンドポイントに固有の名前を参照しながら記述される、1つまたは複数のローカル仮想エンドポイントを生成するための手段と
を備えるエンドポイント通信を促進するための装置。
【請求項２０】
前記既知の名前は、前記遠隔バスノードを記述する前記既知の名前の第1部分と、前記遠隔エンドポイントを記述する前記既知の名前の第2部分とをさらに備える請求項19に記載の装置。
【請求項２１】
前記既知の名前は、トランスポート型と、1つまたは複数の接続パラメータとをさらに備える請求項19に記載の装置。
【請求項２２】
前記トランスポート型は、
Bluetoothベースのトランスポートプロトコルと、
UNIXベースのトランスポートプロトコルと、
TCPベースのトランスポートプロトコルと、
ユニバーサルシリアルバスベースのトランスポートプロトコル
のうちの少なくとも1つをさらに備える請求項21に記載の装置。
【請求項２３】
前記トランスポート型はBluetoothベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは単一のピコネット構造のための最適化された接続情報を備える請求項21に記載の装置。
【請求項２４】
前記トランスポート型はTCPベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは、前記遠隔エンドポイントに関連した前記遠隔バスノードへの最適化されたワンホップルーティングを備える請求項21に記載の装置。
【請求項２５】
前記取得するための手段は、
前記遠隔バスノードが利用可能であることを判定する段階に応じて、自動的に接続要求を送信するための手段と、
前記送信された要求に応じて、前記接続情報を受信するための手段とをさらに備える請求項19に記載の装置。
【請求項２６】
前記ローカルバスノードによって、前記1つまたは複数のローカル仮想エンドポイントのうちの少なくとも1つと通信するためにローカルエンドポイントから要求を受信するための手段と、
前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つに、前記要求を送信するための手段と、
前記ローカルエンドポイントが前記遠隔エンドポイントへアクセスすることを認める前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つから、アクセスメッセージを受信するための手段と、
前記アクセスメッセージに応じて、前記ローカルエンドポイントと前記遠隔エンドポイントの間に通信セッションを確立するための手段と
をさらに備える請求項19に記載の装置。
【請求項２７】
前記確立する段階は、前記第1電力レベルの通信プロトコルよりも多量の電力を使用する前記第2電力レベルの通信プロトコルを使用することを備える請求項26に記載の装置。
【請求項２８】
ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定する段階と、
前記ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して前記遠隔バスノードから接続情報を取得する段階であって、前記接続情報は前記遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報であり、前記第2電力レベルの通信プロトコルは前記第1電力レベルの通信プロトコルよりも多量の電力を使用する、取得する段階と、
各々のローカル仮想エンドポイントが前記1つまたは複数の遠隔エンドポイントの各々に対応し、前記遠隔エンドポイントが、既知の、前記遠隔エンドポイントに固有の名前を参照しながら記述される、1つまたは複数のローカル仮想エンドポイントを生成する段階と
のために動作可能な通信モジュール
を備えるエンドポイント通信を促進するための装置。
【請求項２９】
前記既知の名前は、前記遠隔バスノードを記述する前記既知の名前の第1部分と、前記遠隔エンドポイントを記述する前記既知の名前の第2部分とをさらに備える請求項28に記載の装置。
【請求項３０】
前記既知の名前は、トランスポート型と、1つまたは複数の接続パラメータとを備える請求項28に記載の装置。
【請求項３１】
前記トランスポート型は、
Bluetoothベースのトランスポートプロトコルと、
UNIXベースのトランスポートプロトコルと、
TCPベースのトランスポートプロトコルと、
ユニバーサルシリアルバスベースのトランスポートプロトコル
のうちの少なくとも1つをさらに備える請求項30に記載の方法。
【請求項３２】
前記トランスポート型はBluetoothベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは単一のピコネット構造のための最適化された接続情報を備える請求項30に記載の装置。
【請求項３３】
前記トランスポート型はTCPベースのトランスポートプロトコルであり、前記1つまたは複数の接続パラメータは、前記遠隔エンドポイントに関連した前記遠隔バスノードへの最適化されたワンホップルーティングを備える請求項30に記載の装置。
【請求項３４】
前記遠隔バスノードが利用可能であることを判定する段階に応じて、自動的に接続要求を送信する段階と、
前記送信された要求に応じて、前記接続情報を受信する段階と
のために動作可能なトランシーバをさらに備える請求項28に記載の装置。
【請求項３５】
前記ローカルバスノードによって、前記1つまたは複数のローカル仮想エンドポイントのうちの少なくとも1つと通信するためにローカルエンドポイントから要求を受信する段階と、
前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つに、前記要求を送信する段階と、
前記ローカルエンドポイントが前記遠隔エンドポイントへアクセスすることを認める前記1つまたは複数の対応する遠隔エンドポイントのうちの前記少なくとも1つから、アクセスメッセージを受信する段階と
のために動作可能なトランシーバをさらに備え、
前記通信モジュールは、前記アクセスメッセージに応じて、前記ローカルエンドポイントと前記遠隔エンドポイントの間に通信セッションを確立するためにさらに動作可能な請求項28に記載の装置。
【請求項３６】
前記通信モジュールは、前記第1電力レベルの通信プロトコルよりも多量の電力を使用する前記第2電力レベルの通信プロトコルを使用するためにさらに動作可能な請求項35に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、その内容が明示的に参照により本明細書に組み込まれる、2009年12月15日に出願した仮出願第61/286,585号「METHODS AND APPARATUS FOR USING A DISTRIBUTED MESSAGE BUS FOR AD HOC PEER-TO-PEER CONNECTIVITY」の優先権を主張するものである。
【０００２】
本開示は一般に、多数のデバイス間の通信に関し、より詳細には、様々なデバイスで実行中のアプリケーション等が、場所、動作、接続状態、バッテリーレベル、無線信号強度、入力されるイベント等の前後関係や、アプリケーション特有の、および、一般的なシステムに関する情報を共有することができるようにするために、単独の、または組み合わせた無線またはワイヤードプロトコルを通じて確立された接続を使用するアドホックピアトゥピアの分散メッセージバスを使用することに関する。
【背景技術】
【０００３】
技術の進歩の結果、パーソナルコンピュータはより小さく、より強力になった。例えば現在、各々が小さく軽量で、ユーザによって簡単に持ち運ばれることが可能な携帯無線電話、携帯情報端末(PDA)およびページングデバイスなどの無線コンピューティングデバイスを含めて、様々な形態パーソナルコンピューティングデバイスが存在する。より具体的には、携帯無線電話は、例えば、無線ネットワーク上で音声およびデータパケットを通信する携帯電話をさらに含む。さらに、多くのそのような携帯電話は比較的大きなコンピューティング能力とともに製造されており、したがって小型のパーソナルコンピュータおよびハンドヘルドPDAと同等のものになっている。
【０００４】
さらに、そのようなデバイスのユーザは、その他のデバイス、ウェブベースのコンテンツ、サービス等にアクセスするためにデバイスを使用することに関心がある。現在、デバイスは限定されたピアトゥピア接続を通じて通信してもよく、その場合そうした接続は接続技術およびリジッド接続(rigid connection)プロトコルによって限定される。例えば、Bluetooth(登録商標)、WiFi等の現在の技術は、(例えばハンドセット、ラップトップ、デスクトップ等の)異なるデバイスおよび/または異なるオペレーティングシステム上で動作するアプリケーション間でのピアトゥピア(P2P)通信を可能にしようとするアプリケーション開発者にあまり支援を与えない。さらに、現在モバイルプラットフォームは、アプリケーション開発者に上述のP2Pアプリケーションを開発するための支援を与えるAPIを公開することはできず、またしばしばAPIを公開する一部のプラットフォームは、根底にあるネットワークおよびプロトコルについての豊富な専門技術や知識を持つ開発者にだけ利用可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、根底にあるネットワークおよびプロトコルについての豊富な専門技術や知識を持たずに、アプリケーション間のアドホックP2P通信を可能にするためのプラットフォーム間共通の、言語に依存しない解決策を提供するための改良された装置および方法が望ましい。
【課題を解決するための手段】
【０００６】
以下では、そのような態様の基本的理解を提供する目的で、1つまたは複数の態様の簡略化された概要を示す。この概要は、すべての企図する態様の広範な概要ではなく、また、すべての態様の主要または重要な要素を特定すること、または任意もしくはすべての態様の範囲を定めることを意図しない。その唯一の目的は、後に示される、より詳細な記述への前置きとして、1つまたは複数の態様のいくつかの概念を簡略化された形で示すことである。
【０００７】
1つまたは複数の態様およびその対応する開示によって、アドホックピアトゥピアの分散メッセージバスを使用して、様々な態様が記述される。1つの態様によって、アドホックピアトゥピアの分散メッセージバスを使用するための方法が提供される。この方法は、ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定する段階を備えることができる。さらにこの方法は、ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して遠隔バスノードから、遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報を備える接続情報を取得する段階を備えることができる。さらにこの方法は、各々が1つまたは複数の遠隔エンドポイントの各々に対応し、遠隔エンドポイントが、遠隔エンドポイントに固有の、既知の名前を参照しながら記述される1つまたは複数のローカル仮想エンドポイントを生成する段階を備えることができる。
【０００８】
その他の態様は、コンピュータ可読媒体を備えるコンピュータプログラム製品に関する。このコンピュータ可読媒体は、ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定するために実行可能な命令を備える。さらに、このコンピュータ可読媒体は、ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して遠隔バスノードから、遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報を備える接続情報を取得するために実行可能な命令を備える。さらに、このコンピュータ可読媒体は、各々が1つまたは複数の遠隔エンドポイントの各々に対応し、遠隔エンドポイントが、遠隔エンドポイントに固有の、既知の名前を参照しながら記述される1つまたは複数のローカル仮想エンドポイントを生成するために実行可能な命令を備える。
【０００９】
さらに別の態様は、装置に関する。この装置は、ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定するための手段を備えることができる。さらに、この装置は、ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して遠隔バスノードから、遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報を備える接続情報を取得するための手段を備えることができる。さらに、この装置は、各々が1つまたは複数の遠隔エンドポイントの各々に対応し、遠隔エンドポイントが、遠隔エンドポイントに固有の、既知の名前を参照しながら記述される1つまたは複数のローカル仮想エンドポイントを生成するための手段を備えることができる。
【００１０】
他の態様は、装置に関する、この装置は、ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定するため、ローカルバスノードによって、第2電力レベル通信プロトコルを使用する遠隔バスノードから、遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報を備える接続情報を取得するため、および各々が1つまたは複数の遠隔エンドポイントの各々に対応し、遠隔エンドポイントが、遠隔エンドポイントに固有の、既知の名前を参照しながら記述される1つまたは複数のローカル仮想エンドポイントを生成するために動作可能な通信モジュールを含むことができる。
【００１１】
上記および関連の目標を達成するために、1つまたは複数の態様は、以下で完全に記述され、特許請求の範囲の中で具体的に指摘される特徴を備える。以下の記述および付属の図面は、1つまたは複数の態様の特定の例示的特徴について詳細に記述する。しかしながら、これらの特徴は様々な態様の原理が用いられてもよい様々な方法のうちのほんの一部を示すものであり、この記述は、すべてのそうした態様およびそれらの均等物を含むことを意図する。
【００１２】
以下で、開示される態様は、開示される態様を限定するのではなく、説明するために示される添付の図面と合わせて記述され、図中同じ記号表示は同じ要素を示す。
【図面の簡単な説明】
【００１３】
【図１】1つの態様による通信ネットワークのブロック図である。
【図２】図1に示された態様のオペレーションのメッセージシーケンスチャートを示す図である。
【図３】図2に示されたメッセージシーケンスチャートによる1つの態様で使用するための高レベルオブジェクトモデルを示す図である。
【図４】図2に示されたメッセージシーケンスチャートによる1つの態様で使用するための他の高レベルオブジェクトモデルを示す図である。
【図５】1つの態様による通信ネットワークの態様の流れ図である。
【図６】通信デバイスのアーキテクチャ例のブロック図である。
【図７】さらに別の態様による、アドホックピアトゥピアの分散メッセージバスを使用することができる例示的通信システムのブロック図である。
【発明を実施するための形態】
【００１４】
ここで、図面を参照して様々な態様が説明される。以下の記述の中では、説明を目的として、1つまたは複数の態様の完全な理解を提供するために、多数の特定の詳細が言及される。しかしながら、そのような態様がこれらの特定の詳細を伴わずに実行されてもよいことは明らかであろう。
【００１５】
一般に、単一のプラットフォーム上でのアプリケーションとそれと同種のものとの間の通信は、Linux(登録商標)およびその他のオペレーティングシステムで見られるDBusなどのプロセス間通信プロトコル(IPC)フレームワークを使用して促進されてもよい。DBusは、アプリケーションが他のアプリケーションにサービスを提供するためにバスに登録しており、他のアプリケーションが登録されたアプリケーションについての情報をバスに問い合わせるデスクトップ環境で、アプリケーション対アプリケーションの通信を有効にするために使用されるソフトウェアバスを含む。そのようなプロトコルは、非同期の通知および遠隔手続き呼び出しを提供してもよい。すなわち、(例えば通知等の)信号メッセージは、ポイントトゥポイントまたはブロードキャストであってよく、(例えばRPC等の)メソッド呼び出しメッセージは同期または非同期であってよく、(例えば「デーモン」バス等の)バスプロセスは、メッセージのルーティングを処理してもよい。さらにDBusフレームワークは、(例えばAPIではなくワイヤプロトコルとして指定される等)言語中立的である。さらに、一般にはDBusプロトコルで使用されるバスデーモンには、HALとの通信のためのシステムバスおよびシステム構成要素と、ログインセッションの間のデスクトップアプリケーション間の通信のためのセッションバスとの2つの型がある。このシステムバスは、デバイスのブート時に起動され、アプリケーションを(例えばUNIX(登録商標)ソケット等の)ソケットに接続し、認証情報を使用してソケットレベルでのセキュリティを提供し、接続されている、および/または接続されていないハードウェアの通知を提供し、ハードウェアの機能および/またはステートについてのサポートクエリを提供してもよい。セッションバスは、ユーザのためにログイン時間に起動されることが可能であり、TCP/IPまたはUNIX(登録商標)ソケットを介してアプリケーションを接続することができ、アプリケーションがバスに接続する場合にセキュリティメカニズムを提供することができる。さらに、名前および識別子は、様々な命名規則を使用して定義されるASCII文字列であり、各バスには固有の名前が割り当てられ、アプリケーションはそれら自体の既知の名前を登録している。またさらに、
アプリケーション機能は、オブジェクト名に基づいた接頭辞（prefix）を使用して命名されているオブジェクトパスを備えた1つまたは複数のオブジェクトを介して公開されてもよい。
【００１６】
本明細書で使用する際、オブジェクトは1つまたは複数のインターフェースを実装してもよく、その場合インターフェースは、関連した方法および信号メッセージをカプセル化してもよく、オブジェクトは実装してもよいインターフェースの名前を取得するために問い合わせを受けることができる。さらに、インターフェース名はオブジェクトパスと同様に、「get」、「ping」等、特殊な、および/一般的な機能を記述してもよい。さらに、本明細書で使用する際、メンバー名は方法および/または信号メッセージのための単純な名前を記述してもよい。1つの態様では、インターフェースは1つまたは複数のメンバーを含んでもよい。またさらに、本明細書で使用する際、エラー名はエラーのために名前スペースを与えてもよく、またインターフェース名に類似している。
【００１７】
ここでDBusメッセージについて見ると、そのようなメッセージは強く型付けされ、ヘッダおよびボディを備えてもよく、その場合ヘッダについての型シグネチャは事前定義されてもよい。ヘッダは、(例えばメソッド呼び出し、メソッド返送、信号またはエラー等の)メッセージ型、(例えばメッセージバスによって割り当てられる固有の名前等の)発信者、宛先、オブジェクトパスおよびシグネチャ等の多数のフィールドを含んでもよい。ボディはメッセージ引数を含んでもよい。さらに、シグネチャASCII文字列は、メッセージデータのためのデータ型を定義してもよい。例えば、型は整数等の基本型であるか、または構造、配列およびディクショナリ等の複合型であることが可能である。またさらに、データ整理の使い易さと速度のために、整列される型の自然境界に合わせるためにゼロが付加される。基本シグネチャ型は8、16、32および64ビットの符号付きまたは符号なし整数、(例えば64ビットの浮動小数点等の)ダブル、文字列等を含んでもよい。さらに、複合型は基本型から、およびその他の複合型から構築されてもよい。またさらに、変形型のシグネチャは実行時の型付を可能にしてもよい。Table1(表1)は、様々なシグネチャの例を示す。
【００１８】
【表１】
0005392873.tif 000002
【００１９】
さらに、アプリケーションまたはそれと同種のものは、単一のデバイス内で、または多数のデバイス間で互いに通信しようしてもよい。単一デバイス内では、アプリケーションは、通信を促進するためにメッセージバス(MBus)プロトコルを使用してもよい。そのようなMBusプロトコルは、DBusベースのプロトコルを介して、拡張機能および改良されたパフォーマンスを提供してもよい。例えば、MBusプロトコルベースの通信は、(例えばDBusスタートポロジだけではない)柔軟なバストポロジ、バストゥバス機能、およびポイントトゥポイントの認証および/または暗号化を可能にしてもよい。さらに、MBusプロトコルベースの通信は、(例えばローカルUNIX(登録商標)ソケット、共有メモリ、Bluetooth(登録商標)、TCP/IP等の)無線およびオンプロセッサの接続を可能にしてもよく、ユーザはデバイス110から、ウェブサーバ140からアクセス可能なコンテンツの検索を試みてもよい。1つの態様では、デバイス110は無線通信デバイス(WCD)、有線と無線の両方の多数のデバイスを含んでもよい。例えば、多数のデバイスは、ネットワーク等としてタンデムで機能してもよい。そのような例では、デバイス110はユーザによるアクセスのために、例えばメインウェブページ等、要求された第1コンテンツアイテムを取得してもよい。さらにデバイス110は、第1コンテンツアイテムにリンクされた、例えばウェブページ、オブジェクト等の第1コンテンツアイテムに関連した第2コンテンツアイテムを、ユーザがそのような第2コンテンツアイテムを要求する前に取得するために、プロキシサーバ130と通信してもよい。これらの第2コンテンツアイテムの検索は、特定のプロトコルを使用して実行されてもよい。以下第2プロトコルと呼ばれるこの特定のプロトコルは、要求が前の要求の任意の関連した確認応答から分離されるようにすることによって、一連のコンテンツアイテム要求と対応する確認応答の往復時間を減少させる。このように第2プロトコルを使用して、前の要求からの受信確認応答を待つことに関連した、いかなる遅延によっても邪魔されることのない単一の接続バスを介して、複数の要求が送信されてもよい。
【００２０】
図1を参照すると、1つの態様による通信ネットワーク100のブロック図が示されている。通信ネットワーク100は、分散バス125を介して接続された通信デバイス110、130、140を含んでもよい。1つの態様では、分散バス125は、例えばBluetooth(登録商標)、TCP/IP、WiFi、CDMAネットワーク、GPRSネットワーク、UMTSネットワークおよびその他の型の通信プロトコル等の様々なトランスポートプロトコルによって支援されてよい。他の態様では、通信デバイス110は分散バスノード112、および1つまたは複数のローカルエンドポイント114を含んでもよい。分散バスノードは、通信デバイス110に関連したローカルエンドポイント114と、分散バス125を介してアクセス可能なその他の通信デバイス130、140に関連したその他のローカルエンドポイント(134,144)の間の通信を促進してもよい。本明細書で使用する際、分散バスは、対称型のマルチデバイスネットワークトポロジを支援してもよく、デバイスのドロップアウトが存在する中で安定したオペレーションを提供してもよい。分散バス125に関連した接続および通信プロセスのさらなる記述は、図2を参照して示される。
【００２１】
このように、(例えばBluetooth(登録商標)、TCP/IP、WiFi等の)根底にあるトランスポートプロトコルに依存しない仮想分散バス125は、デバイスが互いの範囲に入る場合に、任意の介入を使用することなく、デバイスとの自発的接続を促進しながら、開放的なものから認証および暗号化されたものまで、様々なセキュリティオプションが使用されることを可能にしてもよい。
【００２２】
図2を参照すると、メッセージシーケンス図の形式で図1に描かれた主題のオペレーションが図示されている。一般に、デバイス(A)202は、デバイス(B)208から通信することを要求してもよい。1つの態様では、デバイス(A)202は、通信のための要求を行ってもよいローカルアプリケーション等のローカルエンドポイント(A)204、およびそのような通信を促進することを支援してもよいバスノード(A)206を含んでもよい。さらに、デバイス(B)208は、ローカルエンドポイント(A)が通信しようとしてもよいローカルエンドポイント(B)210、およびローカルエンドポイント(A)204とローカルエンドポイント(B)212の間の通信を促進することを支援してもよいバスノード(B)210を含んでもよい。
【００２３】
1つの態様では、バスノード(A)および(B)は、ステップ番号214で、検出メカニズムを実行してもよい。例えば、Bluetooth(登録商標)、TCP/IP、UNIX(登録商標)またはその他によって支援される接続を検出するためのメカニズムが使用されてよい。ステップ番号216で、ローカルエンドポイント(A)204は、バスノード(A)206を介して利用可能なエンティティ、サービス、エンドポイント等に接続することを要求してもよい。1つの態様では、そのような要求は、ローカルエンドポイント(A)204とバスノード(A)206の間の要求と応答プロセスを含んでもよい。ステップ番号218で、(例えばバスノード(A)206等の)MBusサーバは、1つまたは複数の(例えばバスノード(B)210等の)他のMBusサーバに接続してもよい。1つの態様では、通信は、MBus、DBus、ワイヤプロトコル、またはその他のIPCメカニズム等のプロトコルを使用して促進されてもよい。例えば、MBusベースのエンドポイントは、DBusベースのプロトコルを介して他のサーバに接続してもよい。他の態様では、バスノード(A)206は、DBusベースのエンドポイントおよびサーバで利用できるような(例えばSASL等の)メカニズムを使用して、他のMBusサーバとの接続を認証してもよい。SASL認証では、クライアントは認証コマンドを送信して、認証対話を開始してもよい。認証コマンドは、クライアントの認証メカニズムを一覧表示してもよい。サーバは認証コマンドを拒否してもよく、自身の認証メカニズムを一覧表示してもよい。クライアントは、対話の始めに認証メカニズムを選択してもよい。さらに、認証プロセスは、申し入れと応答の連続であってよい。認証が失敗する場合、クライアントは他のメカニズムを試すか、または接続を切ってもよい。認証が成功した後、クライアントはHello  メソッド呼び出しメッセージを送信してもよい。その後、メソッドメッセージはサーバから返送されてもよく、固有のidをクライアントに発行する。このように、クライアントは送信者idを持ってもよく、その他のメソッドメッセージの呼び出しを実行してもよい。
【００２４】
本明細書で使用する際、MBusは、ばらばらのマルチエンドポイントのMBusインスタンスが一緒になって単一のインスタンスを形成することができるようにするDBusプロトコルの拡張子であってもよい。1つの態様では、そのようなインスタンスは、非スターベースのトポロジを使用して支援されてもよい。さらに、MBusサーバ(バスノード)は、根底にあるトランスポートメカニズムに関連した制限を受けずに、中央ルータに転送されることなく、他の宛先に直接流れるようにすることができる。さらに、MBus対応デバイスは、MBusに対応していないデバイス間の通信を促進してもよい。
【００２５】
さらに、そのような接続は両方向で認証されてもよい。すなわち、認証コマンドと応答は、両方向で交換されてもよい。さらにまた、ステップ番号218の間、バスノード(A)と(B)は、他の利用可能なエンドポイントについて情報を交換してもよい。そのような態様では、バスノードによって維持される各エンドポイントは、他のバスノードに対して記述されてよく、その場合そうした記述は固有のエンドポイント名、トランスポートの型、接続パラメータ等を含んでもよい。
【００２６】
さらにまた、バスノードは、様々なセキュリティメカニズムを促進してもよい。例えば、アプリケーションはバスノードで認証してもよく、認証は接続時に交渉されてもよく、また認証は、上述のSASLモデルに従うものでもよい。さらに、バスノードは、認証なしのための「匿名」フィールド、ファイルシステムのアクセス権に基づくユーザ認証のための「クッキー」フィールド、カーネルソケットセキュリティを使用するユーザ認証のための「外部」フィールド等、組み込みの認証メカニズムを提供してもよい。
【００２７】
ステップ番号220で、(例えばバスノード(A)206およびバスノード(B)210等の)各バスノードは、様々なバスノードを介して利用可能な実在の取得されたエンドポイントを表してもよい仮想エンドポイントを作成するために、取得されたエンドポイントの情報を使用してもよい。1つの態様では、バスノード(A)206でルーティングされるメッセージは、メッセージを届けるために実在および仮想のエンドポイントを使用してもよい。さらに、(例えばデバイス(B)208等の)遠隔デバイス上に存在する各エンドポイントのために1つのローカルの仮想エンドポイントが存在してもよい。さらにまた、そのような仮想エンドポイントは、(例えばバスノード(A)206とバスノード(B)210との間の接続等の)MBus接続を介して送信される多重化および/または逆多重化メッセージであってもよい。1つの態様では、仮想エンドポイントは実在エンドポイントのようにローカルのバスノードからメッセージを受信してもよく、エンドポイントに関連したMBus接続にメッセージを転送してもよい。そのような態様では、仮想エンドポイントは、多重化されたMBus接続のエンドポイントからローカルのバスノードへメッセージを転送してもよい。さらにまた他の態様では、遠隔デバイス上の仮想エンドポイントに対応する仮想エンドポイントは、特定のトランスポート型の所望のトポロジに対応するために、いつでも再接続されてもよい。そのような態様では、UNIX(登録商標)ベースの仮想エンドポイントはローカルとみなされなくてもよく、したがって再接続のための候補とみなされなくてもよい。さらに、TCPベースの仮想エンドポイントは、所望のMBusサーバへのワンホップルーティングのために最適化されてもよい(例えば、各MBusノードは互いにMBusバスノードに直接接続されてもよい)。さらにまたBluetooth(登録商標)ベースの仮想エンドポイントは、(例えば1つのマスターとn個のスレーブ等)単一のピコネットのために最適化されてもよい。そのような態様では、Bluetooth(登録商標)ベースのマスターは、ローカルのMBusマスターノードと同じバスノードであってもよい。
【００２８】
ステップ番号222で、(例えばバスノード(A)206およびバスノード(B)210等の)MBusベースのサーバは、バスインスタンスを結合するためにバスステート情報を交換してもよい。1つの態様では、ステート情報は既知の固有のエンドポイント名マップ、マッチ規則およびルーティンググループから構成されてもよい。1つの態様では、ステート情報は、DBusベースのローカル名を使用して通信されるローカルエンドポイントを備えたMBusベースのインターフェースを使用して、MBusサーバインスタンス間で通信されてもよい。他の態様では、(例えばバスノード(A)206等の)各MBusサーバは、DBusベースのフィードバックに関与する独自のバスコントローラを維持してもよい。そのような態様では、バスコントローラは、グローバルなMBusメソッドおよび信号を標準のローカルDBusメソッドおよび信号に変換してもよい。
【００２９】
ステップ番号224で、(例えばバスノード(A)206およびバスノード(B)210等の)Mbusベースのサーバは、上述のように、バスノード接続の間に導入された変更を(例えばローカルエンドポイント(A)204、ローカルエンドポイント(B)212等の)ローカルエンドポイントに知らせるために、信号を通信(例えばブロードキャスト等)してもよい。1つの態様では、新しい、および/または削除されたグローバルな、および/または変換された名前は、名前の所有者変更信号とともに示されてもよい。さらに、名前の衝突のために(局所的に)消失しているかもしれないグローバル名は、名前消失信号とともに示されてもよい。さらにまた、名前の衝突のために転送されるグローバル名は、名前の所有者変更信号とともに示されてもよい。その上さらに、2つのバスが切断になったときに消えた固有名は、名前の所有者変更信号とともに示されてもよい。
【００３０】
上で使用されるように、ローカルエンドポイントを固有に記述するために、既知の名前が使用されてもよい。1つの態様では、多数のデバイスの間で通信が生じる場合、異なるタイプの既知の名前が使用されてもよい。例えば、デバイスのローカル名は、それが直接帰属する特定のデバイスのバスノード上にのみ存在してもよい。他の例では、グローバル名は、すべての知られたバスノード上に存在してもよく、その場合名前の唯一の所有者がすべてのバスセグメント上に存在してもよい。すなわち、バスが加わり、衝突が生じる場合、所有者のうちの1人はグローバル名を失う場合がある。さらに他の例では、クライアントが仮想バスに関連した他のバスノードに接続される場合、変換名が使用されてもよい。そのような態様では、変換名は付加エンドを含んでもよい(例えば、既知の名前org.fooを持つローカルエンドポイント(A)は、GUID=1234以外のMBusサーバに接続されたクライアントによって、GUID=1234が"G1234.org.foo"となっているMBusサーバに接続されてもよい。
【００３１】
ステップ番号226で、(例えばバスノード(A)206およびバスノード(B)210等の)MBusベースのサーバは、エンドポイントのバストポロジに対する変更を他のバスノードに知らせるために信号を通信(例えばブロードキャスト)してもよい。その後、(例えばローカルエンドポイント(A)204等の)エンドポイントからのトラフィックは、(例えばデバイス(B)208等の)遠隔デバイス上の対象とする(例えばローカルエンドポイント(B)212等の)削除エンドポイントに達するために、仮想エンドポイントの中を動いてもよい。
【００３２】
さらに、オペレーションの中で、(例えばローカルエンドポイント(A)204、ローカルエンドポイント(B)212等の)エンドポイント間の通信は、ルーティンググループを使用してもよい。1つの態様では、ルーティンググループは、エンドポイントがエンドポイントのサブセットから信号、メソッド呼び出し等を受信することができるようにしてもよい。そのような態様では、ルーティング名は、バスノードに接続されたアプリケーションによって判定されてもよい。例えば、p2pは、アプリケーションに組み込まれた固有の、既知のルーティンググループ名を使用してもよい。さらに、バスノードは、ルーティンググループへのエンドポイントの登録および/または登録取り消しを支援してもよい。1つの態様では、ルーティンググループは現在のバスインスタンスを越えて持続性を持たなくてもよい。他の態様では、アプリケーションは、バスに接続するたびにそれらの優先ルーティンググループのために登録してもよい。さらにまた、グループはオープンであってもよく(例えば任意のエンドポイントが参加することができる)、またはクローズドであってもよい(例えばグループの作成者だけがグループを変更することができる)。さらにまた、バスノードは他の遠隔バスノードに通知するために、またはルーティンググループへの、および/またはそこからの追加、削除等を通知するために信号を送信してもよい。そのような態様では、バスノードは、メンバーが追加および/またはグループから削除されるたびに、ルーティンググループ変更信号を他のグループメンバーに送信してもよい。さらに、バスノードは最初にそれら自体をルーティンググループから削除することなく、バスから切断するエンドポイントにルーティンググループ変更信号を自動的に送信してもよい。
【００３３】
図3を参照すると、例示的な高レベルオブジェクトモデル300が描かれている。1つの態様では、高レベルオブジェクトモデルは、メッセージバス(MBus)302を含んでもよい。描かれているように、MBus302はMBusオブジェクト304、MBusトランスポート306およびMBusルータ308に関連付けられてもよい。1つの態様では、MBusトランスポートは、ローカルトランスポート、UNIX(登録商標)トランスポート、Bluetooth(登録商標)トランスポート、TCP/IPトランスポート等の様々なトランスポートを含んでもよく、各トランスポートは少なくとも1つの関連したエンドポイントのために利用可能である。
【００３４】
1つの態様では、MBusオブジェクト302は、所定の名前、オブジェクトパス、インターフェース名およびメンバー名を介して、組み込み機能を提供してもよい。そのような機能を判定することは、イントロスペクションとして記述されてもよく、その場合イントロスペクションは、オブジェクトのインターフェースおよび/またはネスト化されたオブジェクトの(例えばXML記述等の)記述を提供する。1つの態様では、インターフェースは(例えばRequestName、ReleaseName、HasOwner等の)名前管理、および/または(AddMatch、RemoveMatch等の)ルート管理のためのメソッドを提供してもよい。
【００３５】
図4を参照すると、他の例示的高レベルオブジェクトモデル400が描かれている。1つの態様では、高レベルオブジェクトモデル400はMBusオブジェクト402を含んでもよい。MBusオブジェクト402はMBusインターフェース404、MBusローカルエンドポイント406に関連付けられてもよく、それらはMBusルータ408、MBus信号メッセージハンドラ410およびMBusメソッドメッセージハンドラ412に関連付けられてもよい。
【００３６】
図5は、特許請求される主題による様々な手順を示す。説明を簡単にするために、手順は一連の行為として示され、記述されるが、いくつかの行為は、本明細書で示され、記述されたもののうちの他の行為と異なる順序で、および/またはそれと同時に生じてもよいので、特許請求される主題は行為の順序によって限定されないということを理解および認識されたい。例えば、当業者であれば、手順は代わりに、ステート図等において、一連の相互に関連したステートまたはイベントとして表されることが可能なことを理解および認識するであろう。さらに、特許請求される手段によって手順を実施するために、すべての描かれた行為が必要でなくてもよい。さらに以下で、および本明細書を通して開示される手順は、そのような手順をコンピュータにトランスポートおよび転送することを促進するために製造品に格納されることが可能であることをさらに認識されたい。本明細書で使用する際、製造品という用語は、任意のコンピュータ可読デバイス、キャリアまたは媒体からアクセス可能なコンピュータプログラムを包含することが意図される。
【００３７】
ここで図5を参照すると、アドホックピアトゥピアの分散メッセージバスを使用するための方法例500が描かれている。参照番号502で、遠隔ノードが利用可能であることが判定される。1つの態様では、判定はローカルバスノードによって実行されてもよい。他の態様では、判定は、(例えばBluetooth(登録商標)、TCP/IP、WiFi等の)任意の根底にあるトランスポートプロトコルに依存しなくてもよく、デバイスが互いの範囲に入る場合に、任意の介入を使用することなく、デバイスとの自発的接続を促進しながら、開放的なものから認証および暗号化されたものまで、様々なセキュリティオプションが使用されることを可能にしてもよい。
【００３８】
参照番号504で、遠隔バスノードに関連した遠隔エンドポイントのための接続情報を含めて、接続情報が遠隔バスノードから取得されてもよい。1つの態様では、接続情報の取得を支援するために、検出メカニズムが使用されてもよい。例えば、Bluetooth(登録商標)、TCP/IP、UNIX(登録商標)ドメインソケットまたはその他のものによって支援される接続を検出するためのメカニズムが使用されてもよい。
【００３９】
参照番号506で、各々の取得された遠隔エンドポイントのために、ローカル仮想エンドポイントが生成されてもよい。このように、ローカル仮想エンドポイントの使用を通じて、非スターベースのネットワークトポロジが達成されてもよい。オペレーションの中で、仮想エンドポイントは、ちょうど実在のエンドポイントのように、ローカルバスノードからメッセージを受信し、メッセージをエンドポイントに関連したMBus接続に転送してもよい。そのような態様では、仮想エンドポイントは多重化されたMBus接続のエンドポイントからローカルバスノードへメッセージを転送してもよい。さらにまた、他の態様では、遠隔デバイス上の仮想エンドポイントに対応する仮想エンドポイントは、特定のトランスポート型の所望のトポロジに対応するために、いつでも再接続されてよい。そのような態様では、UNIX(登録商標)ベースの仮想エンドポイントはローカルとみなされなくてもよく、したがって再接続のための候補とみなされなくてもよい。さらに、TCPベースの仮想エンドポイントは、所望のMBusサーバへのワンホップルーティングのために最適化されてもよい。(例えば、各MBusノードは互いにMBusバスノードに直接接続されてもよい)。さらにまた、Bluetooth(登録商標)ベースの仮想エンドポイントは、(例えば1つのマスターとn個のスレーブ等)単一のピコネットのために最適化されてもよい。そのような態様では、Bluetooth(登録商標)ベースのマスターは、ローカルのMBusマスターノードと同じバスノードであってもよい。
【００４０】
さらにまた、1つの態様では、バスノード間の通信を促進するために、様々な定義されたメッセージ型が使用されてもよい。そのようなメッセージは、信号、メソッド等の様々な型に分類されてもよい。例えば、あるメソッド型メッセージは次のものを含む:「AddToGroup」は、エンドポイントによって、名づけられたグループに自身を追加するために送信されてもよい;「RemoveFromGroup」は、エンドポイントによって、名づけられたグループから自身を削除させるために送信されてもよい;「ConnectToBus」は、エンドポイントによって、他のバスノードへ接続し、参加しようとするために送信されてもよい;「RequestName」は、エンドポイントによって、(例えばローカル、グローバル、変換等の)特定の型の既知の名前を要求するために送信されてもよい;「GetTranslatedNames」は、エンドポイントが、特定のベース名のための変換された既知の名前を受信することができるようにしてもよい。さらに、いくつかの信号型メッセージの例は以下のものを含んでもよい:「GroupChanged」は、すべてのグループメンバーに、エンドポイントが名づけられたグループに参加する、および/またはそこから離れることを知らせるために送信されてもよい;「ConnectionChanged」は、バスノード接続が追加および/またはドロップしていることをエンドポイントに知らせるために送信されてもよい。
【００４１】
ここでは図1を依然として参照しながら、図6も見るが、通信デバイス110のアーキテクチャ例が描かれている。図6に示されているように、デバイス600は、例えば受信アンテナ(不図示)から信号を受信して、受信された信号上で(例えばフィルタリング、増幅、ダウンコンバート等の)典型的な行為を実行し、調整された信号をデジタル化してサンプルを取得するレシーバ602を備える。レシーバ602は、受信されたシンボルを復調して、それらをチャネル推定のためにプロセッサ606に与えることができる復調器604を備えることができる。プロセッサ606は、レシーバ602によって受信される情報の分析、および/またはトランスミッタ620による送信のための情報の生成に専用のプロセッサであることが可能であり、モバイルデバイス600の1つまたは複数のコンポーネントを制御するプロセッサ、および/またはレシーバ602によって受信される情報の分析と、トランスミッタ620による送信のための情報の生成の両方を行い、モバイルデバイス600の1つまたは複数のコンポーネントを制御するプロセッサであることが可能である。
【００４２】
モバイルデバイス600は、プロセッサ606に動作可能に接続され、送信されるべきデータ、受信されたデータ、利用可能なチャネルに関連した情報、分析された信号および/または干渉の強度に関連したデータ、割り当てられたチャネル、電力、速度またはその他に関連した情報、およびチャネルを推定し、チャネルを介して通信するための任意の適切なその他情報を格納することができるメモリ608をさらに備えることができる。1つの態様では、メモリ608は、デバイス600および/または分散バスモジュール630を介して関連付けられたその他デバイス上で、エンドポイントのアプリケーション、サービス等と通信することを求めてもよいローカルエンドポイントアプリケーション610を含むことができる。メモリ608はさらに、(例えばパフォーマンスベース、容量ベース等の)チャネルの推定および/または利用に関連したプロトコルおよび/またはアルゴリズムを格納することができる。
【００４３】
さらに、プロセッサ606は、ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定するための手段、ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して遠隔バスノードから遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報を備える接続情報を取得するための手段、および各々が1つまたは複数の遠隔エンドポイントの各々に対応し、遠隔エンドポイントが、遠隔エンドポイントに固有の既知の名前を参照しながら記述される1つまたは複数のローカル仮想エンドポイントを生成するための手段を備えることができる。
【００４４】
本明細書で述べられる(例えばメモリ608等の)データストアは、揮発性メモリまたは不揮発性メモリのいずれかであることが可能であり、または揮発性メモリと不揮発性メモリの両方を含むことができる。限定ではなく、例示として、不揮発性メモリは読み出し専用メモリ(ROM)、プログラム可能ROM(PROM)、電気的にプログラム可能なROM(EPROM)、電気的に消去可能なPROM(EEPROM)、またはフラッシュメモリを含むことができる。揮発性メモリは、外部キャッシュメモリとして機能するランダムアクセスメモリ(RAM)を含むことができる。限定ではなく例示として、RAMはシンクロナスRAM(SRAM)、ダイナミックRAM(DRAM)、シンクロナスDRAM(SDRAM)、ダブルデータレートSDRAM(DDR SDRAM)、強化型SDRAM(ESDRAM)、Synchlink DRAM(SLDRAM)およびダイレクトRambus RAM(DRRAM)等の多くの形式で利用可能である。主題のシステムおよび方法のメモリ608は、限定されることなく、これらのメモリおよび任意のその他の適切な型のメモリを備えてもよい。
【００４５】
モバイルデバイス600は、デバイス600等の他のデバイスとの接続を確立することを促進するために、分散バスノード630をさらに含むことができる。分散バスモジュール630は、多数のデバイス間の通信を管理する分散バスモジュール630を支援するために、バスノードモジュール632をさらに備えてもよい。1つの態様では、バスノードモジュール632は、他のデバイスに関連したエンドポイントアプリケーション610との命名の衝突を回避するバスノードモジュール632を支援するために、オブジェクト命名モジュール634をさらに含んでもよい。さらにまた、分散モジュール630は、他のローカルエンドポイントおよび/または確立された分散バスを介して他のデバイスにアクセス可能なエンドポイントと通信するローカルエンドポイントを支援するために、エンドポイントモジュール636を含んでもよい。他の態様では、分散バスモジュール630は、(例えばBluetooth(登録商標)、UNIX(登録商標)、ドメインソケット、TCP/IP、WiFi等の)多数の利用可能なトランスポートを介して、デバイス内および/またはデバイス間通信を促進してもよい。
【００４６】
さらに、モバイルデバイス600は、ユーザインターフェース640を含んでもよい。ユーザインターフェース640は、通信デバイス600への入力を生成するための入力メカニズム642、および通信デバイス600のユーザによる消費のために情報を生成するための出力メカニズム642を含んでもよい。例えば、入力メカニズム642はキーまたはキーボード、マウス、タッチスクリーンディスプレイ、マイク等のメカニズムを含んでもよい。さらに、例えば、出力メカニズム644はディスプレイ、オーディオスピーカ、触覚フィードバックメカニズム、パーソナルエリアネットワーク(PAN)トランシーバ等を含んでもよい。描かれている態様では、出力メカニズム644は、画像またはビデオ形式のメディアコンテンツを示すために動作可能なディスプレイ、またはオーディ形式のメディアコンテンツを示すためのオーディオスピーカを含んでもよい。
【００４７】
図7を参照すると、1つの態様による、アドホックピアトゥピアの分散メッセージバスを使用するためのシステム700が描かれている。例えば、システム700はWCD、UE等の内部に少なくとも部分的に存在してもよい。他の例示的態様によって、システム700は、アクセス端末の内部に少なくとも部分的に存在してもよい。システム700は、プロセッサ、ソフトウェアまたは(例えばファームウェア等の)それらの組み合わせによって実施される機能を表すものであることが可能な機能ブロックを含むものとして表されていることを認識されたい。
【００４８】
システム700は、ともに機能することが可能な手段の論理グループ702を含む。例えば、論理グループ702は、ローカルバスノードによって、第1電力レベルの通信プロトコルを使用して、遠隔バスノードが利用可能であることを判定するための手段704を含むことができる。1つの態様では、第2電力レベルの通信プロトコルは、第1電力レベルの通信プロトコルよりも、より多くの電力を使用する場合がある。したがって、第2電力レベルの通信プロトコルは、第1電力レベルの通信プロトコルよりも、より高速のデータ速度が使用されることを可能にしてもよい。さらに、論理グループ702は、ローカルバスノードによって、第2電力レベルの通信プロトコルを使用して遠隔バスノードから、遠隔バスノードに関連した1つまたは複数の遠隔エンドポイントのための接続情報を備える接続情報を取得する手段706を含むことができる。1つの態様では、この取得するための手段は、遠隔バスノードが利用可能であるという判定に応じて、接続要求を自動的に送信するための手段、および送信された要求に応答して、接続情報を受信するための手段を含んでもよい。
【００４９】
さらに、論理グループ702は、各々が1つまたは複数の遠隔エンドポイントの各々に対応し、遠隔エンドポイントが、既知の、遠隔エンドポイントに固有の名前を参照しながら記述される1つまたは複数のローカル仮想エンドポイントを生成するための手段708を備えることができる。1つの態様では、既知の名前はさらに、遠隔バスノードを記述する既知の名前の第1部分および遠隔エンドポイントを記述する既知の名前の第2部分を含んでもよい。他の態様では、既知の名前はトランスポート型および1つまたは複数の接続パラメータを含んでもよい。1つのそのような態様では、トランスポート型はBluetooth(登録商標)ベースのトランスポートプロトコル、UNIX(登録商標)ベースのトランスポートプロトコル、TCPベースのトランスポートプロトコル、ユニバーサルシリアルバスベースのトランスポートプロトコル等のうちの少なくとも1つを含んでもよい。例えば、トランスポート型がTCPベースのトランスポートプロトコルである場合、1つまたは複数の接続パラメータは、遠隔エンドポイントに関連した遠隔バスノードへの最適化されたワンホップトランスポートプロトコルを含んでもよい。他の例として、トランスポート型がBluetooth(登録商標)ベースのトランスポートプロトコルである場合、1つまたは複数の接続パラメータは、単一のピコネット構造のための最適化された接続情報を含んでもよい。
【００５０】
さらに、システム700は、手段704、706および708に関連した機能を実行するための命令を保持するメモリ710を含むことができる。手段704、706および708のうちの1つまたは複数は、メモリ710の外部にあるものとして示されているが、それらはメモリ710の内部に存在してもよいということを理解されたい。
【００５１】
本出願の中で使用される際、「コンポーネント」、「モジュール」、「システム」およびその他は、限定されないがハードウェア、ファームウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェアまたは実行中ソフトウェア等のコンピュータ関連エンティティを含むことが意図されている。例えば、コンポーネントは限定されないが、プロセッサ上で動作中のプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラムおよび/またはコンピュータであってもよい。例示として、コンピュータデバイス上で動作中のアプリケーションとコンピューティングデバイスの両方は、コンポーネントでありうる。1つまたは複数のコンポーネントは、プロセスおよび/または実行のスレッドの内部に存在することが可能であり、コンポーネントは1つのコンピュータ上でローカライズされてもよい、および/または2つ以上のコンピュータの間で分散されてもよい。さらに、これらのコンポーネントは、格納された様々なデータ構造を持つ様々なコンピュータ可読媒体から実行することができる。コンポーネントは、例えば1つまたは複数のデータパケットを備えた信号によって、ローカルシステム、分散システムの中で、および/または他のシステムを備えたインターネット等のネットワークの間で、信号によって他のコンポーネントと交流する1つのコンポーネントからのデータとして、ローカルおよび/または遠隔のプロセスによって通信してもよい。
【００５２】
さらに、本明細書では、ワイヤード端末またはワイヤレス端末であることが可能な端末と関連して様々な態様が述べられている。端末はまたシステム、デバイス、加入者ユニット、加入者局、モバイル局、モバイル、モバイルデバイス、遠隔局、遠隔端末、アクセス端末、ユーザ端末、端末、通信デバイス、ユーザエージェント、ユーザデバイスまたはユーザ機器(UE)と呼ばれることも可能である。ワイヤレス端末は携帯電話、衛星電話、コードレス電話、セッション開始プロトコル(SIP)電話、ワイヤレスローカルループ(WLL)局、携帯情報端末(PDA)、ワイヤレス接続機能を有するハンドヘルドデバイス、コンピューティングデバイス、またはワイヤレスモデムに接続されたその他の処理デバイスであってよい。さらに、本明細書では基地局と関連して様々な態様が述べられている。基地局は、ワイヤレス端末と通信するために利用されてよく、またアクセスポイント、aNode B、または何らかのその他の用語で呼ばれてもよい。
【００５３】
さらに、「または」という表現は、排他的な「または」ではなく包含的な「または」を意味することが意図されている。すなわち別途指定がない限り、または文脈から明らかではない限り、「XはAまたはBを採用する」という言い回しは、自然な包含的置換のうちの任意のもの意味することが意図されている。すなわち、「XはAまたはBを採用する」という言い回しは、以下の文章のうちの任意のものによって満たされる:XはAを採用する;XはBを採用する;XはAとBの両方を採用する。さらに、「a」および「an」という冠詞は、本出願および添付の特許請求の範囲の中で使用される際、別途指定されない限り、または単数形とされることが文脈から明らかでない限り、一般に「1つまたは複数」を意味するように解釈されるべきである。
【００５４】
本明細書で述べられる技術は、CDMA、TDMA、FDMA、OFDMA、SC-FDMAおよびその他のシステム等の様々なワイヤレス通信システムのために使用されてもよい。「システム」と「ネットワーク」という用語は、しばしば同じ意味で使用される。CDMAシステムは、ユニバーサル地上無線アクセス(UTRA)、cdma2000等の無線技術を実装してもよい。UTRAは、ワイドバンドCDMA(W-CDMA)およびその他のCDMAの変形を含んでもよい。さらに、cdma2000はIS-2000、IS-95およびIS-856規格に対応する。TDMAシステムは、モバイル通信のためのグローバルシステム(GSM(登録商標))等の無線技術を実装してもよい。OFDMAシステムは、次世代UTRA(E-UTRA)、ウルトラモバイルブロードバンド(UMB)、IEEE802.11(WiFi)、IEEE802.16(WiMAX)、IEEE802.20、Flash-OFDM(商標)等の無線技術を実装してもよい。UTRAおよびE-UTRAは、ユニバーサルモバイルテレコミュニケーションシステム(UMTS)の一部である。3GPP長期エボリューション(LTE)は、ダウンリンクではOFDMAを採用し、アップリンクではSC-FDMAを採用するE-UTRAを使用するUMTSのリリースである。UTRA、E-UTRA、UMTS、LTEおよびGSM(登録商標)については、「第3世代パートナーシッププロジェクト(3GPP)」という機関の文書の中で述べられている。さらに、cdma2000およびUMBについては、「第3世代パートナーシッププロジェクト2(3GPP2)」という機関の文書の中で述べられている。さらに、そのような無線通信システムは、しばしば対になっていない無認可のスペクトルを使用する(例えばモバイル対モバイル等の)ピアトゥピアのアドホックネットワークシステム、802.xxワイヤレスLAN、Bluetooth(登録商標)、および任意のその他の長期または短期のワイヤレス通信技術をさらに含んでもよい。
【００５５】
様々な態様または機能は、複数のデバイス、コンポーネント、モジュール等を含んでもよいシステムに関して提示される。様々なシステムはさらなるデバイス、コンポーネント、モジュール等を含んでもよい、および/またはデバイス、コンポーネント、モジュール等のすべてを含まなくてもよいということを理解し、認識されたい。これらのアプローチの組み合わせもまた、使用されてよい。
【００５６】
本明細書で開示される態様に関して述べられた様々な例示的な論理、論理ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、またはその他のプログラム可能な論理デバイス、離散ゲートまたはトランジスタ論理、離散ハードウェアコンポーネント、または本明細書で述べられた機能を実行するように設計された任意のそれらの組み合わせとともに実施され、実行されてもよい。汎用プロセッサはマイクロプロセッサであってよいが、代替としてプロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラまたはステートマシンであってもよい。プロセッサはまた、例えばDSPとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、DSPコアと関連した1つまたは複数のマイクロプロセッサ、または任意のその他のそのような構成等、コンピューティングデバイスの組み合わせとして実装されてもよい。さらに、少なくとも1つのプロセッサは、上述のステップおよび/または行為のうちの1つまたは複数を実行するために動作可能な1つまたは複数のモジュールを備えてもよい。
【００５７】
さらに、本明細書で開示される態様に関して述べられた方法またはアルゴリズムのステップおよび/または行為は、直接ハードウェアの中で、プロセッサによって実行されるソフトウェアモジュールの中で、または2つの組み合わせの中で具体化されてもよい。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROMまたは当技術分野で知られている任意のその他形式のストレージ媒体の中に存在してもよい。例示的ストレージ媒体はプロセッサに結合されてもよいので、プロセッサはストレージ媒体から情報を読み出し、ストレージ媒体へ情報を書き込むことができる。代替として、ストレージ媒体はプロセッサに不可欠であってもよい。さらに、いくつかの態様では、プロセッサおよびストレージ媒体はASICの中に存在してもよい。さらに、ASICはユーザ端末の中に存在してもよい。代替として、プロセッサおよびストレージ媒体は、ユーザ端末の中に個別のコンポーネントとして存在してもよい。さらに、いくつかの態様では、方法またはアルゴリズムのステップおよび/または行為は、コンピュータプログラム製品に組み込まれてもよい機械可読媒体および/またはコンピュータ可読媒体上の符号および/または命令のうちの1つまたは任意の組み合わせまたはセットとして存在してもよい。
【００５８】
1つまたは複数の態様では、記述される機能はハードウェア、ソフトウェア、ファームウェアまたは任意のそれらの組み合わせの中で実装されてもよい。ソフトウェアの中で実装される場合、機能はコンピュータ可読媒体上の1つまたは複数の命令または符号として格納されるか、または送信されてもよい。コンピュータ可読媒体は、コンピュータストレージ媒体と、1つの場所から他の場所へのコンピュータプログラムの転送を促進する任意の媒体を含む通信媒体の両方を含む。ストレージ媒体は、コンピュータによってアクセスされることが可能な任意の利用可能媒体であってよい。限定ではなく、例として、そのようなコンピュータ可読媒体はRAM、ROM、EEPROM、CD-ROMまたはその他の光ディスクストレージ、磁気ディスクストレージもしくはその他の磁気ストレージデバイス、または命令もしくはデータ構造の形式で所望のプログラム符号を運搬または格納するために使用されることが可能であり、コンピュータによってアクセスされることが可能な任意のその他媒体を備えることができる。また、任意の接続はコンピュータ可読媒体と呼ばれてもよい。例えば、ソフトウェアがウェブサイト、サーバまたはその他の遠隔ソースから、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線およびマイクロ波等のワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線およびマイクロ波等のワイヤレス技術は媒体の定義の中に含まれる。本明細書で使用される際、ディスク(Disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フレキシブルディスクおよびブルーレイディスクを含み、この場合ディスク(disk)は通常データを磁気的に再生し、ディスク(disc)は通常データを光学的にレーザを用いて再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
【００５９】
上記の開示は例示的態様および/または態様について論じているが、添付の特許請求の範囲によって定義されるように、述べられた態様および/または態様の範囲から逸脱することなく、ここで様々な変更および修正がなされうることに留意されたい。さらに、述べられた態様および/または態様の要素は単数形で記述または特許請求されてもよいが、単数形に対する限定が明示的に述べられていない限り、複数形が考慮されている。さらに、任意の態様および/または態様のすべてまたは一部は、別途記載がない限り、任意のその他の態様および/または態様のすべてまたは一部とともに利用されてもよい。
【符号の説明】
【００６０】
100  通信ネットワーク
110  デバイス
112  分散バスノード
114  ローカルエンドポイント
125  分散バス
130  プロキシサーバ
134  ローカルエンドポイント
140  ウェブサーバ
144  ローカルエンドポイント
202  デバイス(A)
204  ローカルエンドポイント(A)
206  バスノード(A)
208  デバイス(B)
210  ローカルエンドポイント(B)
212  ローカルエンドポイント(B)
300  高レベルオブジェクトモデル
302  メッセージバス
304  MBusオブジェクト
306  MBusトランスポート
308  MBusルータ
400  高レベルオブジェクトモデル
402  MBusオブジェクト
404  MBusインターフェース
406  MBusローカルエンドポイント
408  MBusルータ
410  MBus信号メッセージハンドラ
412  MBusメソッドメッセージハンドラ
500  方法例
600  デバイス
602  レシーバ
604  復調器
606  プロセッサ
608  メモリ
610  ローカルエンドポイントアプリケーション
620  トランスミッタ
630  分散バスモジュール
632  バスノードモジュール
636  エンドポイントモジュール
640  ユーザインターフェース
642  入力メカニズム
644  出力メカニズム
700  システム
702  論理グループ
710  メモリ
【図１】
0005392873.tif 000003
【図２】
0005392873.tif 000004
【図３】
0005392873.tif 000005
【図４】
0005392873.tif 000006
【図５】
0005392873.tif 000007
【図６】
0005392873.tif 000008
【図７】
0005392873.tif 000009