JP2010537588A - プラットホームに依存しない通信プロトコル - Google Patents

Abstract

特に、通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間で、プラットホームに依存しない双方向通信を実現するための技術を開示する。通信を実現することは、モバイルコントローラデバイスからホストデバイスにバイトの列を供給することを含む。バイトの列は、モバイルコントローラデバイスの１つ以上のデータパケットを記述する。ホストデバイスがネイティブデバイスドライバを有することが検出された場合、ネイティブデバイスドライバを用いて、供給されたバイトの列を解析する。一方、ホストデバイスがネイティブデバイスドライバを含んでいないことが検出された場合、供給されたバイトの列を解析するためのデバイスドライバを提供する。
【選択図】 図１

Description

関連出願への相互参照
本出願は、２００７年８月２４日に出願された、米国特許出願第１１／８４４，９９９号の優先権を主張し、この出願の内容は、引用によって本願に援用される。

技術分野
本発明は、通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を実現する技術に関する。

携帯電話機等のモバイル機器は、単に音声通話機能を提供するだけの通信機器ではなくなっている。モバイル機器は、テキストメッセージング、アドレス帳、カレンダ、他の生産性アプリケーション、マッピングアプリケーション、ゲームアプリケーション及び他の多くのアプリケーションを含む様々なアプリケーションを実行するために用いることができる演算プラットホームとして構成することができる。

ブルートゥース２．０規格では、マウス、キーボード、ワイヤレスヘッドセット、及び自動車用のハンドフリーキット等の限られた数のデバイスが携帯電話機と通信できるように設計される様々な「プロファイル」を指定できる。これらのプロファイルは、通常、携帯電話機のファームウェア内に実装され、例えば、ヒューマンインタフェースデバイス（Human Interface Device：「ＨＩＤ」）プロファイルをサポートする携帯電話機には、ファームウェア内にＨＩＤプロトコルが埋め込まれている。更に、ブルートゥース２．０プロファイルを利用するためには、携帯電話機と、携帯電話機と通信することが望まれる出力デバイス、入力デバイス又は入出力デバイスとの両方が、ファームウェア又はソフトウェアによってサポートされた同じプロファイルを有する必要がある。

本明細書が開示するモバイルコントローラデバイス及びホストデバイスとの間で、プラットホームに依存しない通信を実現するヒューマンインタフェース及び入力システムと技術の実装は、以下の特徴の様々な組合せを含むことができる。

一側面においては、通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間にプラットホームに依存しない双方向通信を提供するステップは、モバイルコントローラデバイスからホストデバイスにバイトの列を供給するステップを含む。提供されるバイトの列は、モバイルコントローラデバイスの１つ以上のデータパケットを記述する。ホストデバイスがネイティブデバイスドライバ（native device driver）を有することが検出された場合、ネイティブデバイスドライバを用いて、供給されたバイトの列を解析する。一方、ホストデバイスがネイティブデバイスドライバを含んでいないことが検出された場合、供給されたバイトの列を解析するためのデバイスドライバを提供する。

実装は、オプションとして、以下の特徴の１つ以上を含んでいてもよい。デバイスドライバを提供するステップは、供給されたバイトの列に基づいて、カスタマイズされたヒューマンインタフェースデバイスドライバ（customized human interface device driver）を提供するステップを含んでいてもよい。また、プラットホームに依存しない双方向通信を提供するために、Ｊａｖａ（登録商標）プラットホームと互換性がある双方向通信を提供してもよい。バイトの列を供給するために、バイトの列からの固定数のバイトを用いて、ネイティブヒューマンインタフェースデバイスデスクリプタ（native human interface device descriptor）がサポートしていない１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成してもよい。更に、１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成するステップは、ジョイスティック、リニアポテンショメータ、トラックボール、エンコーダ、フォースセンシティブレジスタ、歪みゲージ、一連のデジタルスイッチ、加速度計、ジャイロ、慣性センサ及び電磁センサからなるグループから選択される少なくとも１つをサポートする１つ以上のデバイス固有のデスクリプタを生成するステップを含んでいてもよい。また、プラットホームに依存しない双方向通信を提供するステップは、Ｊａｖａ（登録商標）プラットホームドライバがアクセスできる少なくとも２つの通信チャンネルを提供するステップを含んでいてもよい。バイトの列を供給するステップは、モバイルコントローラデバイスのためにカスタマイズされたバイトの可変シーケンスを供給するステップを含んでいてもよい。バイトの可変シーケンスを供給するステップは、バイトのシーケンス内の各バイトを、モバイルコントローラデバイス上の１つ以上の入力要素にマッピングするステップと、入力要素の状態に基づいて、各バイトに割り当てられている値を変更するステップとを有していてもよい。

他の側面として、本発明に開示する技術は、コンピュータが読取可能な媒体上で実現され、データ処理装置に動作を実行させるコンピュータプログラム製品として実現することもできる。例えば、コンピュータプログラム製品は、通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を提供するように設計される。プラットホームに依存しない双方向通信の提供は、モバイルコントローラデバイスの１つ以上のデータパケットを記述するバイトの列を、モバイルコントローラデバイスからホストデバイスに供給することを含む。ホストデバイスがネイティブデバイスドライバを有することが検出された場合、コンピュータプログラム製品は、ネイティブデバイスドライバを用いて、供給されたバイトの列を解析するように設計されている。一方、ホストデバイスがネイティブデバイスドライバを含んでいないことが検出された場合、コンピュータプログラム製品は、供給されたバイトの列を解析するためのデバイスドライバを提供するように設計されている。

実装は、オプションとして、以下の特徴の１つ以上を含むことができる。コンピュータプログラム製品は、供給されたバイトの列に基づいて、カスタマイズされたヒューマンインタフェースデバイスドライバを提供することを更に含む動作をデータ処理装置に実行させるように設計してもよい。コンピュータプログラム製品は、少なくとも、Ｊａｖａ（登録商標）プラットホームと互換性がある双方向通信を提供することによって、プラットホームに依存しない双方向通信を提供することを更に含む動作をデータ処理装置に実行させるように設計してもよい。コンピュータプログラム製品は、少なくとも、バイトの列からの固定数のバイトを用いて、ネイティブヒューマンインタフェースデバイスデスクリプタがサポートしていない１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成することによって、バイトの列を供給することを更に含む動作をデータ処理装置に実行させるように設計してもよい。また、コンピュータプログラム製品は、少なくとも、ジョイスティック、リニアポテンショメータ、トラックボール、エンコーダ、フォースセンシティブレジスタ、歪みゲージ、一連のデジタルスイッチ、加速度計、ジャイロ、慣性センサ及び電磁センサからなるグループから選択される少なくとも１つをサポートする１つ以上のデバイス固有のデスクリプタを生成することによって、１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成することを更に含む動作をデータ処理装置に実行させるように設計してもよい。コンピュータプログラム製品は、Ｊａｖａ（登録商標）プラットホームドライバがアクセスできる少なくとも２つの通信チャンネルを有するプラットホームに依存しない双方向通信を提供することを更に含む動作をデータ処理装置に実行させるように設計してもよい。コンピュータプログラム製品は、モバイルコントローラデバイスのためにカスタマイズされたバイトの可変シーケンスを有するバイトの列を供給することを更に含む動作をデータ処理装置に実行させる。更に、コンピュータプログラム製品は、バイトの可変シーケンスを供給することを更に含む動作をデータ処理装置に実行させるように設計してもよく、バイトの可変シーケンスを供給することは、バイトのシーケンス内の各バイトを、モバイルコントローラデバイス上の１つ以上の入力要素にマッピングすることと、入力要素の状態に基づいて、各バイトに割り当てられている値を変更することとを含んでいてもよい。

更に他の側面として、本発明に開示する技術は、モバイルコントローラデバイスをホストデバイスに接続するように設計されたベースバンドプロトコルを含む通信スタックを動作させるように設計された通信メカニズムを含むモバイルコントローラデバイスとして実現することもできる。また、モバイルコントローラデバイスは、ベースバンドプロトコル上で動作し、１つ以上のメッセージをホストデバイスに送信するように構成された双方向シリアル通信プロトコルを含む。送信される各メッセージは、バイトのシーケンスを含む。また、コントローラデバイスデバイスは、モバイルコントローラデバイスが使用可能な様々な入力メカニズムが提供する入力信号を監視し、１つ以上のメッセージを生成するように構成されたコントローラファームウェアを備える。双方向シリアル通信プロトコルは、ベースバンドプロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を実現する。

実装は、オプションとして、以下の特徴の１つ以上を含むことができる。プラットホームに依存しない双方向通信を実現する双方向シリアル通信プロトコルは、Ｊａｖａ（登録商標）プラットホームと互換性がある双方向通信を含んでいてもよい。コントローラファームウェアは、バイトのシーケンスからの固定数のバイトを用いて、ネイティブヒューマンインタフェースデバイスデスクリプタがサポートしていない１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成するように設計してもよい。また、コントローラファームウェアは、ジョイスティック、リニアポテンショメータ、トラックボール、エンコーダ、フォースセンシティブレジスタ、歪みゲージ、一連のデジタルスイッチ、加速度計、ジャイロ、慣性センサ及び電磁センサからなるグループから選択される少なくとも１つをサポートする１つ以上のデバイス固有のデスクリプタを生成するように設計してもよい。コントローラファームウェアは、それぞれがモバイルコントローラデバイスのためにカスタマイズされたバイトの可変シーケンスを含む１つ以上のメッセージを生成するように設計してもよい。コントローラファームウェアは、バイトのシーケンス内の各バイトを、モバイルコントローラデバイスが使用可能な様々な入力メカニズムの１つ以上の入力要素にマッピングし、マッピングされた１つ以上の入力要素の状態に基づいて、各バイトに割り当てられている値を変更するように設計してもよい。

ここに説明する通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を実現するための技術は、潜在的に、以下の利点の１つ以上を提供できる。本明細書に開示するシステム及び技術は、モバイルコントローラデバイス及びホストデバイスが、センサデータ、状態情報、及びシリアル化可能且つ小さいフットプリントで送信可能なあらゆる種類のデータを交換するための効率的で、軽量のメカニズムを提供できる。このメカニズムは、高速で効率的であり、ファームウェア及び／又はソフトウェアにおけるフットプリントが小さく、関連するデータの送信及び受信の処理におけるタイミングオーバヘッドを最小化することができる。このメカニズムは、ゲームにおいて一般的に用いられている様々なセンサをサポートするように明示的に定義することができ、これらには、ポテンショメータ又は多自由度アナログジョイスティックからのアナログ信号、例えば、光学マウス又はよりハイエンドのロボットデバイス内に配設されているデジタルエンコーダ、加えられる圧力の変化に比例する信号を提供するフォースセンシティブレジスタ、加速度計及びジャイロスコープ信号、トラックボールからの信号、例えば、歪みゲージベースのナビゲーションスティック等の力検出デバイスからの信号、光センサからの比例する又はデジタル信号、電磁センサからの信号等が含まれる。このメカニズムは、モバイルコントローラデバイス及びホストデバイスが、シリアル化可能な他のタイプのデータ、例えば、ゲーム状態情報、自動車診断情報、ＧＰＳフィックス（GPS fix）等を交換できるように拡張できる通信プロトコルとして実装することもできる。

本明細書に開示するシステム及び技術は、様々なトランスポートプロトコルに亘って動作でき、例えば、ブルートゥース論理リンク制御及び適応化プロトコル（Bluetooth logical link control and adaptation protocol：Ｌ２ＣＡＰ）、ブルートゥースシリアルポートプロファイル（Bluetooth serial port profile：ＳＰＰ）、若しくは他の有線又は無線トランスポートプロトコルを介して動作できるアプリケーションプログラムインタフェース（ＡＰＩ）として実装することができる。例えば、このＡＰＩは、ＵＳＢ、ファイヤワイヤ、ＩｒＤＡ、若しくは他の有線及び無線通信プロトコルを介する通信をサポートするように設計してもよい。

更に、通信プロトコルは、ＨＩＤベースのメカニズム、モバイルコントローラデバイスからホストデバイスに送信される、予め定義されたシンタクスを有する固定数のバイトを含む固定長シリアルメカニズム、並びにモバイルコントローラデバイスからホストデバイス、及びホストデバイスからモバイルコントローラデバイスにクエリ及びデータを送信することができる双方向通信システムプロトコルメカニズムを含む様々なメカニズム内で実装することができる。

ＨＩＤベースのメカニズムは、ホストデバイス上にＨＩＤプロファイルのサブセットの軽量Ｊａｖａ（登録商標）実装を提供でき、オプションとして、モバイルコントローラデバイスに適する一般的なセンサをサポートするカスタムＨＩＤデスクリプタを含む。固定長シリアルメカニズムは、モバイルコントローラデバイスに適するセンサについて概ね汎用性がある固定数のバイトを有するバイト構造を反映できる。双方向シリアル通信プロトコルメカニズムは、モバイルコントローラデバイスに適する一般的なセンサをサポートするように実装することができるカスタムバイトシーケンス構造を含むことができる。

ＨＩＤベースのメカニズムを実装するか、シリアル通信プロトコルを実装するかにかかわらず、本明細書に開示するシステム及び技術は、Ｊａｖａ（登録商標）等の、ホストデバイス上で実行されるプログラミングプラットホーム上で実装されたＡＰＩ内に組み込んでもよい。このようなＡＰＩは、ホストデバイス上で実行されるアプリケーションに組み込んでもよい。

本明細書に開示する本発明の主題は、方法、システム、又はＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ又はハードディスク等の情報担体内にアクセス可能に具現化されたコンピュータプログラム製品として実現することができる。このようなコンピュータプログラム製品は、本明細書に開示する１つ以上の動作をデータ処理装置に実行させてもよい。

更に、本明細書に開示する本発明の主題は、プロセッサと、プロセッサに接続されたメモリとを含むシステムとして実現してもよい。メモリ内には、本明細書に開示する１つ以上の方法の動作をプロセッサに実行させる１つ以上のプログラムをエンコードしてもよい。更に、本明細書に開示する本発明の主題は、様々なデータ処理マシンを用いて実現してもよい。

１つ以上の実装の詳細は、添付の図面及び以下の説明に開示されている。他の特徴及び利点は、以下の説明、図面及び特許請求の範囲から、自明となる。

１ａ及び１ｂは、コントローラデバイスとホストデバイスとの間の通信を実現するシステムを示すブロック図である。 ＨＩＤベースのメカニズムのＨＩＤジョイスティックデバイスのために設計された例示的なレポートデスクリプタ３００を示す図である。 ＨＩＤベースのメカニズムの様々なセンサのための通信を実現するために設計された例示的なカスタムレポートデスクリプタを示す図である。 ＨＩＤベースのメカニズムの様々なセンサのための通信を実現するために設計された例示的なカスタムレポートデスクリプタを示す図である。 ＨＩＤベースのメカニズムの様々なセンサのための通信を実現するために設計された例示的なカスタムレポートデスクリプタを示す図である。 ＨＩＤクラスデバイスとＨＩＤに対応するホストデバイスとの間の通信を実現するシステムを説明するＨＩＤベースのメカニズムの具体例を示すブロック図である。 固定長バイトシーケンスを用いた通信を実現する固定長シリアル法の実装のためのブルートゥーススタックを示すブロック図である。 終端バイトを有する４バイトシーケンスの例示的なバイトシーケンスを示す図である。 終端バイトを有する５バイトシーケンスの例示的なバイトシーケンスを示す図である。 ブルートゥースシリアルポートプロファイル（ＳＰＰ）上に双方向シリアル通信プロトコルベースのメカニズムを実装する例示的な通信スタックを示す図である。 双方向シリアル通信プロトコルメカニズムのための例示的なバイトシーケンス又はレポートフォーマットを示す図である。 ＳＥＴ＿ＩＤＬＥの例示的なメッセージフォーマットを示す図である。 アイドルレートを示す例示的なバイトシーケンスを示す図である。 バージョンレポートの例示的なバイトシーケンスを示す図である。 コンフィグレーションデータ入力レポートの例示的なバイトシーケンスを示す図である。 ボタンメタデータレポートの例示的なバイトシーケンスを示す図である。 イネーブル／ディスエーブルレポートタイプの例示的なバイトシーケンスを示す図である。 ボタンレポートのための例示的なバイトシーケンスを示す図である。 ８ビットアナログ２軸ジョイスティックレポートのための例示的なバイトシーケンスを示す図である。 例示的な１６ビットアナログ２軸ジョイスティックレポートを示す図である。 例示的な３２ビットアナログ２軸ジョイスティックレポートを示す図である。 例示的な８ビットアナログ３軸加速度計レポートを示す図である。 例示的な１６ビットアナログ３軸加速度計レポートを示す図である。 例示的な３２ビットアナログ３軸加速度計レポートを示す図である。 例示的な８ビットアナログパドルレポートを示す図である。 例示的な１６ビットアナログパドルレポートを示す図である。 例示的な３２ビットアナログパドルレポートを示す図である。 例示的な１６ビットバッテリレベルレポートを示す図である。 例示的な８ビットトラックボールレポートを示す図である。 例示的な１６ビットトラックボールレポートを示す図である。 例示的な３２ビットトラックボールレポートを示す図である。 例示的な８ビットスクロールホイールレポートを示す図である。 例示的な１６ビットスクロールホイールレポートを示す図である。 例示的な３２ビットスクロールホイールレポートを示す図である。 生の及び調整された８ビットアナログ２軸ジョイスティックレポートのための例示的なバイトシーケンスを示す図である。 ランループ検査レポートのための例示的なバイトシーケンスを示す図である。 ３２ビットデバイスタイムスタンプ（ミリ秒）レポートのための例示的なバイトシーケンスを示す図である。 モバイルコントローラデバイスとホストデバイスとの間で通信を実現するためのプロセスを示すフローチャートである。 ナビゲーションシステム上のマッピングアプリケーションを制御するＪａｖａ（登録商標）対応リモートコントローラデバイスを実装する例示的なシステムを示す図である。 ＧＰＳ対応デバイス間のデータ交換を提供する例示的なシステムを示す図である。 携帯電話、自動車及びＰＣの間のデータ通信を実現するための例示的なシステムを示す図である。 複数の健康器具及びフィットネス機器の間のデータ通信を実現する例示的なシステムを示す図である。 Ｊａｖａ（登録商標）対応ジョイスティックコントローラと携帯電話との間のデータ通信を実現する例示的なシステムを示す図である。 多人数参加型モバイルゲームのシナリオにおけるＨＩＤ通信を実現するための例示的なシステムを示す図である。

様々な図面において、同様の参照符号は、同様の要素を示している。

概要
図１ａ及び図１ｂは、コントローラデバイス１１０とホストデバイス１２０との間で、プラットホームに依存しない（すなわち、ブルートゥース、ＵＳＢ、ファイヤワイヤ、ＩｒＤＡ等の通信プロトコルの如何にかかわらず）通信を実現するシステム１００を示すブロック図である。コントローラデバイス１１０は、通信プロトコル１３０を用いて、ホストデバイス１２０と通信する。

ホストデバイス１２０には、１つ以上のプロセッサが埋め込まれたデバイス、例えば、携帯電話機、携帯情報端末（personal digital assistant：ＰＤＡ）、スマートフォン、パーソナルナビゲーションシステム、デジタルビデオレコーダ（digital video recorder：ＤＶＲ）デバイス、情報（例えば、ＧＰＳナビゲーション、無線通信）及び／又は娯楽（例えば、デジタルビデオディスクドライブ）を提供するアップグレード技術が搭載された自動車、歩数計、血糖計、血圧計、体重計等が含まれる。入力コントローラデバイス１１０は、ホストデバイス１２０と通信し、ホストデバイス１２０を制御するための直感的なインタフェース要素を提供するように設計されている。直感的なインタフェース要素を提供することによって、コントローラデバイス１１０は、例えば、ゲーム及びマッピングアプリケーション等の複雑なアプリケーションの制御及び実行を容易にすることができる。コントローラデバイス１１０は、様々な直感的な制御インタフェース要素を提供するモバイルアクセサリデバイスを含む。このようなコントローラデバイス１１０の具体例については、同時係属中の米国特許出願、発明の名称、「Human Interface Input Acceleration System」（米国特許公表番号第２００７００８０９３４号）及び米国特許出願、発明の名称、「Human Interface Input Acceleration System」（米国特許公表番号第２００７００８０９３１号）に開示されている。これらの同時係属中の米国特許出願（米国特許公表番号第２００７００８０９３４号及び第２００７００８０９３１号）は、引用によって本願に援用される。

通信プロトコルスタック１３０は、コントローラデバイス１１０とホストデバイス１２０との間で、通信信号の双方向変換を可能にする。通信プロトコルスタック１３０は、トランスポートメカニズム１３２上で動作するプラットホームに依存しないトランスポートプロトコル１３４を含む。トランスポートメカニズム１３２は、例えば、ブルートゥース（Bluetooth）、ユニバーサルシリアルバス（Universal Serial Bus：ＵＳＢ）、ファイヤワイヤ（ＦｉｒｅＷｉｒｅ）、ＩｒＤＡ等の有線又は無線のトランスポート／通信プロトコルを含む。プラットホームに依存しないトランスポートプロトコル１３４は、様々なトランスポートメカニズムの１つ以上を介して動作するように設計されている。プラットホームに依存しないトランスポートプロトコル１３４は、トランスポートメカニズム１３２の上位に常駐するアプリケーションプログラミングインタフェース（application programming interface：ＡＰＩ）を用いて実装することできる。ＡＰＩは、サービスの要求をサポートするためにコンピュータシステム又はプログラムライブラリが提供するソースコードインタフェースである。

ここに開示するプラットホームに依存しないトランスポートプロトコル１３４は、モバイルコントローラデバイスとホストデバイスとの間又は複数のモバイルコントローラデバイスと複数のホストデバイスとの間の通信を可能にする様々なメカニズムの下で実装することができる。例えば、プラットホームに依存しないトランスポートプロトコルは、ＨＩＤベースのメカニズム、固定長シリアルメカニズム又は双方向シリアル通信プロトコルメカニズムの下で実装することができる。

ＨＩＤベースのメカニズム
プラットホームに依存しないトランスポートプロトコル１３４は、モバイルコントローラデバイスとホストデバイスとの間の通信を可能にするために、ＨＩＤベースのメカニズムの下で実装することができる。ＨＩＤのベースの通信プロトコルは、標準のＨＩＤデバイスのための既存のＨＩＤ規格に基づいて構築される（例えば、ヒューマンインタフェースデバイス（ＨＩＤ）のためのユニバーサルシリアルバス（ＵＳＢ）デバイスクラス定義、バージョン１．１１（www.usb.org）及びユニバーサルシリアルバス（ＵＳＢ）ＨＩＤ使用テーブル、バージョン１．１２（www.usb.org）を参照。これらの全体は引用によって本願に援用される）。ＨＩＤプロファイルの軽量Ｊａｖａ（登録商標） ２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ（Java（登録商標） 2 Micro Edition：Ｊ２ＭＥ）の実装例は、例えば、ホストデバイスとして機能する携帯電話機及び他のモバイル機器等のモバイル機器上で動作するように実装することができる。１つ以上のモバイルコントローラデバイス上のファームウェアもまた、ＨＩＤプロファイルの軽量の実装例を含む。１つ以上のモバイルコントローラデバイスでの使用に適する汎用及び専用のセンサをサポートするために、カスタムデスクリプタを実装してもよい。

図２は、ＨＩＤジョイスティックデバイスのために設計された例示的なレポートデスクリプタ（report descriptor）２００を示している。例示的なレポートデスクリプタ２００は、（１）前／後及び右／左に傾けられる２軸ジョイスティック（バイト１、２）、（２）ベース上のアナログスロットルコントロール（バイト０）、（３）スティック上の４位置ハットスイッチ（バイト３のビット０〜３）、（４）スティック上の２つのボタン（バイト３のビット４〜５又は６〜７）及び（５）ベース上の２つのボタン（バイト３のビット４〜５又は６〜７）を含む。このレポートデスクリプタ（descriptor report）は、各ジョイスティックの読取値について、８ビットの分解能を提供する。

また、レポートのバイトレイアウトに加えて、レポートデスクリプタは、様々なフィールドに幾つかのセマンティクスを有することができる。例えば、ジョイスティックのためのＸ軸フィールドは、ジョイスティックのＸ軸に沿った位置を表す−１２７〜＋１２７の範囲の８ビット符号値として定義することができる。幾つかの具体例では、Ｘ軸及びＹ軸の読取値が、第１のデスクリプタにおける８ビット分解能に代えて、１６ビット分解能を提供する第２のデスクリプタを提供できる。

図３、図４及び図５は、様々なセンサとの通信を可能にするように設計された例示的なカスタムレポートデスクリプタを示している。固有のＩＤを有する固定された数のバイトが選択され、これらの選択されたバイトのコンテンツは、使用されるセンサのタイプに応じて、様々に適用される。この結果、例えば、（１）自由度（degrees of freedom：ＤＯＦ）が２又は３の低分解能ジョイスティック（図３）、（２）リニアポテンショメータ、（３）ＤＯＦが２のトラックボール（エンコーダ等）（図４）、（３）エンコーダ、（４）フォースセンシティブレジスタ（force sensitive resistor）、（５）歪みゲージ、（６）光センサ、（７）一連のデジタルスイッチ、（８）加速度計（図５）、（９）ジャイロ、（１０）他の慣性センサ及び（１１）電磁センサを含む様々なセンサをサポートする軽量ではあるが柔軟なプロトコルが得られる。

図６は、ＨＩＤクラスデバイス６１０とＨＩＤホストデバイス６２０との間の通信を可能にするシステム６００を示すブロック図である。ＨＩＤクラスデバイス（例えば、コントローラデバイス６１０）は、ホストデバイス６２０上の制御（デフォルト）パイプ６３０又は割込パイプ６４０を用いて、ＨＩＤクラスドライバ（図示せず）と通信する。制御パイプ６３０は、（１）制御及びクラスデータの要求を受信及び応答し、（２）ホストデバイス６２０からＨＩＤクラスドライバによってポーリングされる場合、コントローラデバイス６１０からホストデバイス６２０にデータを送信し、（３）コントローラデバイス６２０がホストデバイス６２０からデータを受信できるようにすることを含む動作を実行するために使用される。割込パイプ６４０は、（１）コントローラデバイス６１０から非同期（要求されていない）データを受信し、及び（２）ホストデバイス６２０からコントローラデバイス６１０に低遅延データを送信することを含む動作を実行するために使用される。

これらの２つのパイプは、ＨＩＤプロトコルにおいて、チャンネル０ｘ１１及び０ｘ１３上の２つのＬ２ＣＡＰ接続として実装される。ゲーム及びアプリケーション開発プラットホームとしてのＪａｖａ（登録商標）（例えば、Ｊ２ＭＥ）実装をサポートするために、ＨＩＤプロファイルのサブセットである軽量Ｊａｖａ（登録商標）実装が提供されている。したがって、ＨＩＤＰコンプライアンスのための２つのＬ２ＣＡＰチャンネル０ｘ１１、０ｘ１３に加えて、Ｊａｖａ（登録商標）ドライバ（例えば、Ｊ２ＭＥ実装）からのアクセスを提供するために、２つの更なるＬ２ＣＡＰチャンネル０ｘ１０１１、０ｘ１０１３が実装される。

他の具体例では、シリアルポートプロファイル（Serial Port Profile：ＳＰＰ）を介する動作のために、カスタムのシリアルトランスポートプロトコルを実装する。ここでは、ＨＩＤプロトコルの場合のようにＬ２ＣＡＰ実装を用いることに代えて、他のトランスポートメカニズムを採用して、ブルートゥーススタック上にトランスポートチャンネルを設ける。ＳＰＰでは、様々なデバイスが無線周波数通信（Radio Frequency Communication：ＲＦＣＯＭＭ）を用いて、エミュレートされたシリアルケーブル接続をセットアップすることができる（シリアルポートプロファイル仕様、バージョン１．１（www.bluetooth.org）参照。この内容の全体は、引用によって本願に援用される）。ＲＦＣＯＭＭは、Ｌ２ＣＡＰプロトコルを介して、ＲＳ−２３２シリアルポートの９つの回路のエミュレーションを提供する単純なトランスポートプロトコルである（ＲＦＣＯＭＭ仕様、バージョン１．１（www.bluetooth.org）参照。この内容の全体は、引用によって本願に援用される）。この実装は、Ｌ２ＣＡＰを直接使用し、ＳＰＰによって与えられる追加的な機能を使用しないＨＩＤプロトコルとは異なる。

固定長シリアルプロトコルベースのメカニズム
他の実施の形態として、モバイルコントローラデバイスがホストデバイスに情報を渡すために、固定長シリアルシーケンスを採用してもよい。このバイトシーケンスは、トランスポートメカニズムとしてブルートゥースＳＰＰ（シリアルポートプロファイル）を用いて、モバイルコントローラデバイスからホストデバイスに送信することができる。

図７は、ブルートゥースシリアルポートプロファイル、すなわちＳＰＰ７１４、７２５上に実装された固定長シリアルシーケンス通信プロトコル７１３、７２４を示すブロック図である。プロトコルスタック７００は、固定長シリアル通信プロトコルを用いて通信を実現する。プロトコルスタック７００は、プロトコルのスタック内のレイヤとして実装することができる様々なプロトコルモジュールを含む。コントローラデバイス７１０の側では、トランスポートプロトコルスタックのレイヤは、ベースバンドレイヤ７１７、論理リンク制御及び適応化プロトコル（Ｌ２ＣＡＰ）レイヤ７１６、ＲＦＣＯＭＭレイヤ７１５、ＳＰＰレイヤ７１４、固定バイトシリアルシーケンスプロトコルレイヤ７１３及びコントローラファームウェアレイヤ７１２を含む。ホストデバイス７２０の側では、プロトコルスタックのレイヤは、ベースバンドレイヤ７２８、Ｌ２ＣＡＰレイヤ７２７、ＲＦＣＯＭＭレイヤ７２６、ＳＰＰレイヤ７２５、固定長シリアルシーケンスプロトコルレイヤ７２４及びアプリケーションレイヤ７２２を含む。

コントローラファームウェア７１２は、コントローラデバイス７１０が使用可能な様々な入力メカニズム（例えば、ボタン、ジョイスティック、トラックボール）が提供するアナログ及びデジタル信号を監視する。信号イベントが発生した場合（例えば、ボタンが押下された場合、ジョイスティックが動かされた場合）、コントローラファームウェアは、固定長プロトコル７１３を用いて、メッセージを生成し、このメッセージをホストデバイス７２０に送信する。

固定長バイトシーケンスは、所定のバイト数を有する。このシーケンス内の各バイトは、特定の目的を有する。一実施の形態においては、シーケンスの最後のバイトは、「終端バイト（termination byte）」として指定してもよく、常に固定値、例えば、０ｘＦＦを表すようにしてもよく、データは、この値を下回るように制限されている。変形例として、バイトストリーム内のバイト数をシーケンスの最初のバイトに符号化してもよい。

ホストデバイス７２０上で実行され、ホストアプリケーションにリンクされているコントローラドライバ７２３は、固定長シリアルシーケンスプロトコルメッセージを受け取り、このメッセージを、１つ以上のアプリケーションレベルイベントに翻訳する。そして、これらのイベントは、ホストアプリケーションに供給される。

一実装例では、固定長シリアルシーケンスプロトコル７１３は、コントローラデバイス７１０からホストデバイス７２０への単方向７３０である。この場合、コントローラデバイス７１０は、ホストデバイス７２０にメッセージを送信することができるが、ホストデバイスは、コントローラデバイス７３０にメッセージを返信することができない。他の実装例では、固定長プロトコル７１３は、双方向（図示せず）であってもよく、この場合、ホストデバイスは、同様に所定の固定されたバイトシーケンスを用いて、コマンドをモバイルコントローラデバイスに送信することができる。

固定長シリアルシーケンスプロトコル７１３は、（１）ポテンショメータ又は多自由度アナログジョイスティックからのアナログ信号、（２）例えば、光学式マウス又はよりハイエンドのロボットデバイス内にあるデジタルエンコーダ、（３）加えられる圧力の変化に応じて、これに比例する信号を提供するフォースセンシティブレジスタ、（４）加速度計及びジャイロスコープ信号、（５）トラックボールからの信号、（６）例えば、歪みゲージベースのナビゲーションスティック等の力検出デバイスからの信号、（７）光センサからの比例する又はデジタル信号、（８）電磁センサからの信号等を含む、ゲームにおいて一般的に使用されている様々なセンサをサポートするためのカスタムの固定バイトバイトシーケンスを実装することができる例示的なプロトコルである。

図８は、終端バイト（第４バイト又は終端バイトとしての０ｘＦＦ）を有する４バイトシーケンスの例示的なバイトシーケンスを示す図である。この実装例では、第１バイトは、押下されたボタンの状態を表すためのビットマップとして使用される。コントローラデバイス７１０は、ボタン押下が検出されたときにイベントを生成し、ボタン解放が検出されたときに異なるイベントを生成する。また、固定長シリアルシーケンスプロトコルによって、コントローラデバイス７１０は、ボタンが押下された後、ボタンが解放されるまでの一定期間、「繰返し」イベントを生成することができる。これらの繰返しイベントは、周期的に（例えば、５０ｍｓ秒毎に）送信される。例えば、単一のボタン押下のイベントのシーケンスは、以下のように表すことができる。

（１）押下イベント
（２）繰返しイベント
（３）繰返しイベント（５０ｍｓ毎に送り続けられる）
（４）解放イベント
一実施の形態においては、繰返しイベントの周波数は、コントローラのファームウェアにおいて固定されている。この周波数は、クライアントアプリケーションによって構成設定することはできない。他の実施の形態においては、繰返しイベントの周波数は、ホストが、ホストデバイスからモバイルコントローラデバイスへの固定バイトシリアルシーケンスを用いて指定できる。

第２バイト及び第３バイトは、それぞれ（１〜２５４の範囲に正規化/スケーリングされた（truncated））８ビットの符号のない数として表現される、ジョイスティック、トラックボール、加速度計又は他の入力要素のＸ値及びＹ値を表す。最後のバイトは、０ｘＦＦによって表される終端バイトである。データ値は、２５５（１６進法の０ｘＦＦ）に到達しないように制限されているので、０ｘＦＦのフレーミングバイト値によって、データストリームの終了を確実に示すことができる。

図９は、終端バイト（第５バイト又は終端バイトとしての０ｘＦＦ又は２５５）を含む５バイトシーケンスの例示的なバイトシーケンスを示す図である。この実装では、第１バイト及び第２のバイトは、ボタン及びキーパッドイベントを表している。固定長シリアルシーケンスプロトコルの第３バイト及び第４バイトは、Ｘ値及びＹ値を含む。これらの値のそれぞれは、符号なしの８ビット値として表され、データ値が必ず１〜２５４の範囲に収まるように正規化/スケーリング（truncated）されている。第５バイトは、旧型バージョンのファームウェア及びドライバが５バイトパケットの最後を検出することを補助するために使用されるフレーミングバイトである。フレーミングバイトには、実際のデータが取ることができる範囲外の固定値（例えば、０ｘＦＦ又は２５５）が割り当てられている。データ値は、２５５（１６進法の０ｘＦＦ）に到達しないように制限されているので、０ｘＦＦのフレーミングバイト値によって、データストリームの終了を確実に示すことができる。

双方向シリアル通信プロトコルベースのメカニズム
プラットホームに依存しない通信プロトコル１３４は、ブルートゥースシリアルポートプロファイル（ＳＰＰ）等のトランスポートメカニズム上で動作する双方向シリアル通信プロトコルとして実装することもできる。バイトシーケンスは、長さが可変であってもよく、設計が柔軟で拡張可能であってもよい。ブルートゥーススペシャルインタレストグループ（Bluetooth Special Interest Group：ＳＩＧ）は、ヒューマンインタフェースデバイスプロファイル（Human Interface Device Profile：ＨＩＤＰ）を指定しているが、ブルートゥースのＪａｖａ（登録商標） ２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）実装（ＪＳＲ−８２）は、必ずしもＨＩＤＰをサポートする必要はない。また、Ｊ２ＭＥは、必ずしもＨＩＤＰが要求する２つの同時のＬ２ＣＡＰ接続をサポートする必要はない。したがって、本明細書が開示する双方向シリアル通信プロトコルは、ＨＩＤＰを模倣し、Ｊ２ＭＥをサポートしながら、ＳＰＰ接続（又はＬ２ＣＡＰ等の他の接続）を介して、ＨＩＤＰに似たデータを提供するように設計される。

図１０は、ブルートゥースシリアルポートプロファイル、すなわちＳＰＰ上に双方向シリアル通信プロトコルベースのメカニズムを実装する例示的な通信スタック１０００を示している。通信スタック１０００は、ＨＩＤプロファイルで使用されているものと同様にモデル化されたメカニズムを用いて、コントローラデバイス１０１０とホストデバイス１０２０との間に双方向通信を提供する。コントローラデバイス１０１０の側は、ベースバンドレイヤ１０１２（例えば、ブルートゥース）、Ｌ２ＣＡＰレイヤ１０１４、ＲＦＣＯＭＭレイヤ１０１５、ＳＰＰレイヤ１０１６、双方向シリアル通信プロトコルレイヤ１０１７及びコントローラファームウェア１０１８を含む。ホストデバイス１０２０の側は、ベースバンドレイヤ１０２２、Ｌ２ＣＡＰレイヤ１０２４、ＲＦＣＯＭＭレイヤ１０２５、ＳＰＰレイヤ１０２６、双方向シリアル通信プロトコルレイヤ１０２７及びホストアプリケーションレイヤ１０２９を含む。

双方向シリアル通信プロトコル７００、１０００の幾つかの実装例では、固定された数の予め定義されたバイトシーケンス又はレポートフォーマットを実装し、これにより、ホストデバイス１０２０及びモバイルコントローラデバイス１０１０は、センサ情報、状態情報及び他のタイプのデータを含む様々なデータを交換することができる。バイトシーケンスの構造は、完全に拡張可能に設計され、これにより、初期的には、一組の標準のセンサタイプをサポートでき、後に、センサの開発に応じて、より多くのセンサをサポートできる。

図１１は、双方向シリアル通信プロトコル７００、１０００のための例示的なバイトシーケンスを示している。バイトシーケンスの所定の構造は、コントローラデバイス１０１０及びホストデバイス１０２０の両方のドライバによって解析される。バイトシーケンスは、特にデータの可変長シリアル化をサポートするように設計されている。バイトシーケンス長は、第１バイト（バイト０）として符号化される。バイト０に符号化される情報は、データパケットのバイトシーケンス長を示す。レポートタイプ識別子（例えば、ＨＩＤＰのものと同様である。）は、バイト１において符号化される。バイト１に符号化される特定のレポートタイプに関連するパラメータは、ｎをバイトシーケンス長として、バイト２からバイトｎにシリアル化される。バイト０は、これに続くデータパケットのバイトシーケンス長を示すので、バイト１から始まるバイト（例えば、バイト１からバイトｎ）は、バイト長及び処理される関連データを反映する。パラメータのタイプ及びセマンティクス、パラメータが並べられる順序、及びパラメータが占めるバイト数は、レポートタイプ毎に異なっていてもよい。パラメータが２つ以上のバイトを占める場合（例えば、タイムスタンプを完全に表すには、４バイトが必要なことがある。）バイトは、好適なネットワーク規則において、最上位バイト（most significant byte：ＭＳＢ）が最初になるようにシリアル化してもよい（これは、ビッグエンディアン規則とも呼ばれる）。他の実装例として、最下位バイト（least significant byte：ＬＳＢ）を最初にしてもよい（これは、リトルエンディアン規則とも呼ばれる）。

フットプリントが合理的にコンパクトで、バイナリフォーマットが２５５バイトエンベロープ内に適合するようにシリアル化可能であれば、如何なるデータも、本明細書に開示する双方向シリアル通信プロトコルを用いて、容易に転送することができる。より大きなデータのパケットは、それぞれが２５５バイトエンベロープ内に適合するように設計された、複数のより小さい連続するパケットにシリアル化及び離散化（discretized）してもよい。より大きいデータパケットを離散的な複数のより小さいパケットに分割することによって、シリアル化可能なあらゆるデータストリームを、双方向シリアル通信プロトコルを用いて送信することができる。

モバイルコントローラデバイス７１０、１０１０の側とホストデバイス７２０、１０２０の側との両方に、これらのレポートを解釈できる一対のパーサ／シリアライザの組を設けることができる。最良の互換性のために、双方向シリアル通信プロトコルのためのパーサ及びシリアライザは、両方の側でバージョンが揃えられる。但し、モバイルコントローラデバイス側７１０、１０１０及びホストデバイス側７２０、１０２０の何れの側の如何なるバージョンのパーサも、第１バイトに符号化されるバイト長に基づいて、新たなシリアル通信を受信し、第２バイトを調べて、パーサがレポートタイプ識別子を認識するかを判定できるように設計することができる。レポートタイプ識別子が認識されるか否かによって、パーサは、レポートタイプ識別子に応じて動作するか、未知のレポートタイプ識別子の検出に基づいて、受信したシリアルレポートを無視するかを選択できる。

以下の段落では、モバイルコントローラデバイスがホストデバイスとデータを送受するための双方向シリアル通信プロトコルの例示的な実装例について詳細に説明する。これらの例は、説明を目的として示しているにすぎず、バイトシーケンスの他の特定の実装例も可能である。更に、サポートされるセンサのタイプ及び転送されるデータのタイプも例示的なものすぎない。実装例は、本明細書に開示する双方向通信プロトコルメカニズムの下で実現されたプラットホームに依存しない通信プロトコル１３４の下で、他のセンサタイプ及びデータタイプのサポートを可能にする。

ホストデバイス１０２０上のＳＰＰデータストリームは、途切れのないデータのストリームとして現れる。本明細書に開示する双方向シリアル通信プロトコルは、パケット指向（packet-oriented）であり、各メッセージがパケット内にカプセル化される。ホストデバイスのＳＰＰ実装では、パケットの概念が見えなくなるので、「エンベロープスキーム（envelope scheme）」を用いる。具体的には、各メッセージの前にバイトカウントを設ける。例えば、ホストデバイス１０２０がコントローラデバイス１０１０に値が１２のＳＥＴ＿ＩＤＬＥメッセージを送信しようとする場合、ＳＥＴ＿ＩＤＬＥメッセージは、図１２に示すようにフォーマットされる（ＳＥＴ＿ＩＤＬＥメッセージの詳細については後述する）。ホストデバイス１０２０は、データストリームに０ｘ０２、０ｘ９０、０ｘ０Ｃのバイトを書き込む。

第１バイト（０ｘ０２）は、次のメッセージ内のバイト数（すなわち、バイトカウント）を表す。次の２つのバイト０ｘ９０（ＳＥＴ＿ＩＤＬＥメッセージヘッダ）及び０ｘ０Ｃ（ＳＥＴ＿ＩＤＬＥ値）は、ＳＥＴ＿ＩＤＬＥメッセージとして解釈される。

幾つかの実装例では、前方互換性（forward compatibility）を維持するために、認識されないＤＡＴＡパケット（すなわち、入力レポート及び出力レポート）は無視される。

全てのＳＥＴ＿ＩＤＬＥ又はＤＡＴＡ＿ＯＵＴＰＵＴメッセージの確認応答として、１バイトのハンドシェイク（Handshake）メッセージが送信される。有効なハンドシェイク値のリストは、以下を含む。

デフォルトでは、コントローラデバイス１０１０は、ボタン状態が変化すると（すなわち、ボタンが押下又は解放されると）、入力（例えば、ボタン）イベントを送信する。コントローラデバイス１０１０は、一定期間のボタン繰返しイベントの送信をサポートしている。この一定期間は、ＳＥＴ＿ＩＤＬＥメッセージ内で、コントローラのアイドルレート（すなわち、繰返しレート）を設定することによって特定される。

ゼロ（０）のアイドルレートは、ボタン繰返しイベントが発生していないと解釈される。これは、新たな接続が確立された時点でのコントローラデバイス１１０、７１０、１０１０のデフォルトの振る舞いである。ホストデバイス１２０、７２０、１０２０は、ＳＥＴ＿ＩＤＬＥメッセージをコントローラデバイス１１０、７１０、１０１０に送信して、新たな繰返しレートを指定することができる。繰返しレートは、ＳＥＴ＿ＩＤＬＥメッセージ内で送信された値に、所定の長さの時間（例えば、４ｍｓ）を乗算した値として設定される。例えば、１２の値を有するＳＥＴ＿ＩＤＬＥメッセージを送信すると、コントローラデバイス１１０、７１０、１０１０は、４８ｍｓ毎にボタン繰返しイベントを送り出す。

ＳＥＴ＿ＩＤＬＥメッセージは、様々な適用可能な値を用いて応答される。例えば、有効なＳＥＴ＿ＩＤＬＥメッセージへの応答は、０ｘ００のＨＡＮＤＳＨＡＫＥ＿ＳＵＣＣＥＳＳＦＵＬ値である。一方、ＳＥＴ＿ＩＤＬＥメッセージの長さが２バイト長でないことが検出された場合、応答として０ｘ０４のＨＡＮＤＳＨＡＫＥ＿ＥＲＲ＿ＩＮＶＡＬＩＤ＿ＰＡＲＡＭＥＴＥＲ値が送信される。また指定されたアイドルレートが接続のレイテンシ（５０ｍｓと想定される。）より短いことが検出された場合、コントローラデバイス１１０、７１０、１０１０は、アイドルレートを、レイテンシに等しくなるように設定する。図１３は、アイドルレートを示す例示的なデータシーケンスを示している。

コントローラデバイス１１０、７１０、１０１０との間に接続が確立すると、様々な標準レポートがホストデバイス１２０、７２０、１０２０に送信される。送信される標準レポートは、（１）バージョンレポート（Version Report）、（２）ボタンカウント（Button Count）を示すコンフィグレーションデータレポート（Configuration Data Report）、（３）ゼロ以上のボタンメタデータレポート（Button Metadata Report）、（４）ゼロ以上のコンフィグレーションデータレポート（Configuration Data Report）、及び（５）０ｘＦＦのタイプの、０ｘ００００００００の値を有するコンフィグレーションデータレポート（Configuration Data Report）を含む。更に、他のカスタムレポートを送信してもよい。

標準レポートは、ＡＰＩ内で使用することができる入力及び出力を表す。例えば、「入力」は、コントローラデバイス１１０、７１０、１０１０からホストデバイス１２０、７２０、１０２０に供給されるデータであるとみなすことができる。「出力」は、ホストデバイス１２０、７２０、１０２０からコントローラデバイス１１０、７１０、１０１０に供給されるデータであるとみなすことができる。全ての複数のバイト値は、ネットワークバイト順（ビッグエンディアン）で送信される。全てのストリングは、ＵＴＦ−８（８ビットＵＣＳ／ユニコード変換フォーマット）で送信される。これは、標準の規則であるが、複数のバイト値及びストリングは、他のバイト順及び他のストリングフォーマットで送信してもよい。

図１４は、バージョンレポートの例示的なバイトシーケンスを示している。バージョンレポートには、０ｘ０３の入力レポートＩＤが割り当てられている。接続が確立された後、バージョンレポートは、最初に送信されるパケットである。ファームウェアメジャーバージョン（Firmware Major Version）（バイト２〜３）は、双方向シリアル通信プロトコルのバージョンを特定する。ファームウェアマイナーバージョン（Firmware Minor Version）（バイト４〜５）は、ファームウェアに特徴が追加される都度、インクリメントされる。ファームウェアリビジョン（Firmware Revision）（バイト６〜７）は、新たなリリースが実行される（例えば、バグが修正される）都度、インクリメントされる。プラットホームＩＤ（Platform ID）（バイト８〜９）は、表１に示すように、現在のプラットホーム（すなわち、ハードウェア又はプロセッサ）を特定する。

モデルＩＤ（Model ID）は、コントローラモデルのレイアウトを特定する。

図１５は、コンフィグレーションデータレポート入力レポート（Configuration Data Report Input Report）の例示的なバイトシーケンスを示す図である。コンフィグレーションデータレポートには、入力レポートＩＤ（例えば、０ｘ０５）が割り当てられている。接続及びバージョンレポートの送信の後に、コントローラデバイス１１０、７１０、１０１０は、ホストデバイス１２０、７２０、１０２０に１つ以上のコンフィグレーションデータレポートを送信する。タイプフィールド（バイト２）は、コンフィグレーションデータレポート内で送信されるコントローラコンフィグレーションデータを特定する。有効なタイプ値のリストを表２に示す。

値（Value）フィールド（バイト３）は、タイプ（Type）フィールド（バイト２）が指定するタイプに対応する値を含む。コントローラデバイス１１０、７１０、１０１０に関連するデータのみがホストデバイス１２０、７２０、１０２０に送信される。換言すれば、コントローラデバイス１１０、７１０、１０１０に加速度計がない場合、加速度計カウントは送信されない。

サンプル毎のビット数ｂは、２より大きく３２以下である。関連するレポート内で許容される値域は、（−２^ｂ−１）から（２^ｂ−１−１）までの範囲として表される。例えば、一実施の形態では、８ビットジョイスティックの値域は、−１２８〜１２７（動作範囲の中心を０として、符号付きの８ビット値で表される。）であってもよい。１２ビットジョイスティックでは、値域は、−２０４８〜２０４７である。幾つかの具体例は、８ビットジョイスティックの値域は、０〜２５５（動作範囲の中心を１２８として、符号なしの８ビット値で表される）であってもよい。１２ビットジョイスティックの値域は、０〜４０９５であってもよく、これは、動作範囲の中心を２０４８として、符号なしの１２ビット数で表される。

様々なアナログ制御（例えば、ジョイスティック、加速度計、パドル）のためのサンプル毎のビット数に基づき、コントローラデバイス１１０、７１０、１０１０は、そのサンプル毎のビット数を含ませることができる最小のサイズの入力レポートを出す。換言すれば、サンプル毎に１０ビットを有する２軸ジョイスティックは、１６ビット２軸ジョイスティックレポートで送られる。

図１６は、ボタンメタデータレポートのための例示的なバイトシーケンスを示している。ボタンメタデータレポートには、０ｘ０４の入力レポートＩＤが割り当てられている。コンフィグレーションデータレポートを送信した後、コントローラデバイス１１０、７１０、１０１０は、コントローラ上の各ボタンについて、最大１つのボタンメタデータ（Button Metadata）レポートを送信する。ボタンメタデータレポートは、ボタンレポートで報告されるボタンＩＤと同じボタンＩＤ（バイト２）を含む。ボタン記述フィールドは、人間が読むことができるボタンの説明（例えば、「トリガ（fire）」又は「上」）である。推奨ゲームアクション（recommended game action）フィールド（バイト−３）は、各ボタンについての推奨されるセマンティクスを提供する。推奨ゲームアクションフィールドの値のリスト表３に示す。この範囲外の推奨ゲームアクション値は、未定義として取り扱われる。

図１７は、イネーブル／ディスエーブルレポートタイプ（Enable/Disable Report Type）の例示的なバイトシーケンスを示している。イネーブル／ディスエーブルレポートには、０ｘ０６の出力レポートＩＤ値が割り当てられている（バイト１）。イネーブル／ディスエーブルレポートのバイト２は、イネーブル又はディスエーブルにすることができるレポートＩＤを含む。（コントローラデバイスからホストデバイスに供給される）如何なる入力レポートもイネーブル又はディスエーブルにすることができる。バイト３のビット０をセットして、指定されたレポートＩＤをイネーブルにすることができ、又はこれをクリアして、指定されたレポートＩＤをディスエーブルにすることができる。

イネーブル／ディスエーブルレポート内のバイト３のビット１は、レポートを調整（condition）するか否かを指定する。バイト３のビット１がセットされていることが検出された場合、指定されたタイプのレポートは、調整されない。ビットがクリアされていることが検出された場合、指定されたタイプのレポートは、オプションとしてコントローラデバイス上の信号調整ソフトウェアアルゴリズム（signal conditioning software algorithm）によって調整される。信号調整は、ジョイスティックの中心の周囲に「デッドゾーン」を設けること、データの範囲の限界の切捨て、生のデータをスケーリングして、この結果、所定の範囲のデータを生成すること、又は他の処理を含んでいてもよい。指定されたレポートＩＤがアナログレポートでないこと、又はスケーリングを用いないアナログレポートであることが検出された場合、（スケーリングは行われないので）バイト３のビット１は無視される。指定されたレポートＩＤをイネーブル又はディスエーブルにすることができないこと、又は指定されたレポートＩＤが認識されていないことが検出された場合、ＨＡＮＤＳＨＡＫＥ＿ＥＲＲ＿ＩＮＶＡＬＩＤ＿ＰＡＲＡＭＥＴＥＲが返される。この他の場合、ＨＡＮＤＳＨＡＫＥ＿ＳＵＣＣＥＳＳＦＵＬが返される。

図１８は、ボタンレポートの例示的なバイトシーケンスを示している。０ｘ０７の入力レポートＩＤ値が割り当てられている（バイト１）。ボタンレポートは、押下されたキーを表すキーコード（バイト２〜７）を示す。如何なる時点においても、６個のキー（例えば、キーコード１〜６）のうちの１つ以上をアクチュエートすることができる。キーコードは、０ｘ００から連続的に割り当てられた値である。これらのキーコードは、ボタン番号を反映している。ボタンは、ハードウェア設計の間に、序列付けされている。最大のキーコード値は、０ｘＦＤである。

キーコードは、レポート内で昇順に示される。第ｎのキーが押下されていない場合、アクチュエートされていないボタンに対応するキーコードは、ＫＥＹＣＯＤＥ＿ＮＯ＿ＥＶＥＮＴ（０ｘＦＥ）としてレポートされる。６個以上のキー（ボタン）が押下されている場合、６個の全てのキーコードがＫＥＹＣＯＤＥ＿ＥＲＲＯＲ＿ＲＯＬＬ＿ＯＶＥＲ（０ｘＦＦ）としてレポートされる。

アイドルレートが指定されていない場合、又はアイドルレートが「０」に設定されている場合、ボタンレポートは、ボタン状態が変化する都度、送信される。一方、ゼロではないアイドルレートが指定されていることが検出された場合、ボタンレポートは、１つ以上のボタンが押下されると、指定されたアイドルレートで繰り返し送信される。ＳＥＴ＿ＩＤＬＥについては、後に更に説明する。

図１９は、８ビットアナログ２軸ジョイスティックレポートの例示的なバイトシーケンスを示している。０ｘ０８の入力レポートＩＤ値が割り当てられている（バイト１）。ジョイスティックＩＤ（バイト２）値は、コンフィグレーションデータ（入力レポート（０ｘ０５）参照）によって報告されたジョイスティックの総数に対して確認され、新たなジョイスティックのそれぞれには、コントローラの現在のジョイスティックの総数をｎとして、０〜ｎ−１の連続的な番号が付される。すなわち、例えば、第１のジョイスティックには、０ｘ００のジョイスティック識別値が割り当てられる。

中心位置は、（０，０）としてレポートされる。ジョイスティックが右に動くと、Ｘ軸読取値が増加する。ジョイスティックが下に動くと、Ｙ軸読取値が増加する。生ビット（raw bit）（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされている場合、読取値は、調整される。

図２０は、例示的な１６ビットアナログ２軸ジョイスティックレポートを示している。０ｘ０９の入力レポートＩＤ値が割り当てられている（バイト１）。ジョイスティックＩＤ値は、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるジョイスティックカウントより小さい値である。すなわち、第１のジョイスティックには、０ｘ００の識別値が割り当てられる。

これは、８ビットレポートと同様に設計されているが、各軸の読取値には、１６ビットが割り当てられている。中心位置は、（０，０）としてレポートされる。ジョイスティックが右に動くと、Ｘ軸読取値が増加する。ジョイスティックが下に動くと、Ｙ軸読取値が増加する。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。

図２１は、例示的な３２ビットアナログ２軸ジョイスティックレポートを示している。０ｘ０Ａの入力レポートＩＤ値が割り当てられている（バイト１）。ジョイスティックＩＤ値は、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるジョイスティックカウントより小さい値である。すなわち、第１のジョイスティックには、０ｘ００の識別値が割り当てられる。

これは、８ビットレポートと同様に設計されているが、各軸の読取値には、３２ビットが割り当てられている。中心位置は、（０，０）としてレポートされる。ジョイスティックが右に動くと、Ｘ軸読取値が増加する。ジョイスティックが下に動くと、Ｙ軸読取値が増加する。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。

図２２は、例示的な８ビットアナログ３軸加速度計レポートを示している。０ｘ０Ｂの入力レポートＩＤ値が割り当てられている（バイト１）。加速度計ＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるジョイスティックカウントより小さい値である。すなわち、第１の加速度計には、０ｘ００の識別値が割り当てられる。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。

図２３は、例示的な１６ビットアナログ３軸加速度計レポートを示している。０ｘ０Ｃの入力レポートＩＤ値が割り当てられている（バイト１）。加速度計ＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるジョイスティックカウントより小さい値である。すなわち、第１の加速度計には、０ｘ００の識別値が割り当てられる。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。

図２４は、例示的な３２ビットアナログ３軸加速度計レポートを示している。０ｘ０Ｄの入力レポートＩＤ値が割り当てられている（バイト１）。加速度計ＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるジョイスティックカウントより小さい値である。すなわち、第１の加速度計には、０ｘ００の識別値が割り当てられる。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。

図２５は、例示的な８ビットアナログパドルレポートを示している。一実施の形態においては、パドルは、動作範囲が固定された回転式のポテンショメータとして、ハードウェア内に実装される。０ｘ０Ｅの入力レポートＩＤ値が割り当てられている（バイト１）。加速度計ＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるパドルカウントより小さい値である。すなわち、第１のパドルには、０ｘ００の識別値が割り当てられる。中心位置は、「０」としてレポートされる。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。

図２６は、例示的な１６ビットアナログパドルレポートを示している。０ｘ０Ｆの入力レポートＩＤ値が割り当てられている（バイト１）。加速度計ＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるパドルカウントより小さい値である。すなわち、第１のパドルには、０ｘ００の識別値が割り当てられる。中心位置は、「０」としてレポートされる。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。各読取値には、１６ビットが割り当てられている。

図２７は、例示的な３２ビットアナログパドルレポートを示している。０ｘ１０の入力レポートＩＤ値が割り当てられている（バイト１）。パドルＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるパドルカウントより小さい値である。すなわち、第１のパドルには、０ｘ００の識別値が割り当てられる。中心位置は、「０」としてレポートされる。生ビット（バイト２、ビット７）がセットされていることが検出された場合、読取値は、調整されない。一方、生ビットがクリアされていることが検出された場合、読取値は、調整される。各読取値には、３２ビットが割り当てられている。

図２８は、例示的な１６ビットバッテリレベルレポートを示している。０ｘ１１の入力レポートＩＤ値が割り当てられている（バイト１）。バッテリレベルレポートは、定期的に（例えば、６０秒毎）に送信される。バイト２〜３は、現在のバッテリ読取値を含む。バッテリレベル読取値には、１６ビットが割り当てられている。

図２９は、例示的な８ビットトラックボールレポートを示している。０ｘ１２の入力レポートＩＤ値が割り当てられている（バイト１）。トラックボールＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるトラックボールカウントより小さい値である。すなわち、第１のトラックボールには、０ｘ００の識別値が割り当てられる。トラックボールが右に動くと、Ｘ読取値は、正の値として検出される。トラックボールが下に動くと、Ｙ読取値は、正の値として検出される。Ｘ読取値及びＹ読取値には、それぞれ８ビットが割り当てられている。

図３０は、例示的な１６ビットトラックボールレポートを示している。０ｘ１３の入力レポートＩＤ値が割り当てられている（バイト１）。トラックボールＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるトラックボールカウントより小さい値である。すなわち、第１のトラックボールには、０ｘ００の識別値が割り当てられる。トラックボールが右に動くと、Ｘ読取値は、正の値として検出される。トラックボールが下に動くと、Ｙ読取値は、正の値として検出される。Ｘ読取値及びＹ読取値には、それぞれ１６ビットが割り当てられている。

図３１は、例示的な３２ビットトラックボールレポートを示している。０ｘ１４の入力レポートＩＤ値が割り当てられている（バイト１）。トラックボールＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるトラックボールカウントより小さい値である。すなわち、第１のトラックボールには、０ｘ００の識別値が割り当てられる。トラックボールが右に動くと、Ｘ読取値は、正にとどまる。トラックボールが下に動くと、Ｙ読取値は、正にとどまる。Ｘ読取値及びＹ読取値には、それぞれ３２ビットが割り当てられている。

図３２は、例示的な８ビットスクロールホイールレポートを示している。０ｘ１５の入力レポートＩＤ値が割り当てられている（バイト１）。スクロールホイールＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるスクロールホイールカウントより小さい値である。すなわち、第１のスクロールホイールには、０ｘ００の識別値が割り当てられる。読取値が正の場合、スクロールホイールは、上又は左に動いたと判定される。読取値が負の場合、スクロールホイールは、下又は右に動いたと判定される。

図３３は、例示的な１６ビットスクロールホイールレポートを示している。０ｘ１６の入力レポートＩＤ値が割り当てられている（バイト１）。スクロールホイールＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるスクロールホイールカウントより小さい値である。すなわち、第１のスクロールホイールには、０ｘ００の識別値が割り当てられる。読取値が正であることが検出された場合、スクロールホイールは、上又は左に動いたと判定される。読取値が負であることが検出された場合、スクロールホイールは、下又は右に動いたと判定される。読取値には、１６ビットが割り当てられている。

図３４は、例示的な３２ビットスクロールホイールレポートを示している。０ｘ１７の入力レポートＩＤ値が割り当てられている（バイト１）。スクロールホイールＩＤは、コンフィグレーションデータ（入力レポート（０ｘ０５））によって返されるスクロールホイールカウントより小さい値である。すなわち、第１のスクロールホイールには、０ｘ００の識別値が割り当てられる。検出された読取値が正である場合、スクロールホイールは、上又は左に動いたと判定される。検出された読取値が負である場合、スクロールホイールは、下又は右に動いたと判定される。

上述したように、アナログレポートは、生で（調整なしで）提供してもよい。一般化して言えば、調整されたレポートは、（サンプル毎のビットのコンフィグレーションデータレポートで指定されるように、）所定の範囲を満たすようにスケーリングされた、０を中心とする符号付きの読取値を送信するように設計される。生のレポートは、処理されていない値を有するレポートである。生のレポートは、処理されていないセンサ信号を表す。したがって、生のレポートは、符号がなく、読取値の中心は、上述したコンフィグレーションデータレポートによって特定される。例えば、レポートが生であることが検出された場合、読取値は、符号なしである。一方、レポートが調整されている場合、読取値は、符号ありである。

また、様々な出力レポートを提供できる。図３５は、生の及び調整された８ビットアナログ２軸ジョイスティックレポートの例示的なバイトシーケンスを示している。０ｘＦＤの出力レポートＩＤ値が割り当てられている（バイト１）。スケーリングアルゴリズムの性能を検査するために生の及び調整された８ビットアナログ２軸ジョイスティックレポートが含まれている。生の及び調整された８ビットアナログ２軸ジョイスティックレポートは、検査アプリケーション以外では使用されない。生の及び調整された８ビットアナログ２軸ジョイスティックレポートは、出力レポート０ｘ０６を用いてイネーブルにすることができる。

図３６は、ランループ検査レポートの例示的なバイトシーケンスを示している。０ｘＦＥの出力レポートＩＤ値が割り当てられている。コントローラデバイス１１０、７１０、１０１０は、有効なランループ検査レポートを受信すると、以下の１つ以上を実行する。（１）ＨＡＮＤＳＨＡＫＥ＿ＳＵＣＣＥＳＳＦＵＬによってホストデバイス１２０、７２０、１０２０に応答する。（２）現在イネーブルにされている全てのレポート（バッテリレポートを含む。）をディスエーブルにする。（３）タイムスタンプレポート（入力レポートＩＤ０ｘＦＦ）を送信する。（４）ｎ個レポートを送信する。（ａ）ｎは、指定された繰返しの数（バイト４〜７）に等しい。（ｂ）レポートは、（バイト２で）指定されたタイプのものである。（ｃ）レポートは、アナログレポートタイプである必要がある。（ｄ）生ビットがセットされている場合（バイト３のビット０）、アナログの読取値に対するスケーリングは行われない（一方、生ビットがクリアされている場合は、通常のスケーリングが実行される）。（５）タイムスタンプレポート（入力レポートＩＤ０ｘＦＦ）を送信する。（６）先にイネーブルにされていたレポートを再びイネーブルにする。

更に、所望のレポートＩＤ（バイト２）が、デバイスによってサポートされているレポートであることが検出された場合、ランループ検査レポートが有効になる。例えば、コントローラデバイス１１０、７１０、１０１０が加速度計を有していない場合、所望のレポートＩＤは、加速度計レポートを指定できない。一方、所望のレポートＩＤがアナログレポートタイプを指定していることが検出された場合、ランループ検査レポートは、有効になる。

繰返しがゼロに指定されている（例えば、バイト４〜７が全て０ｘ００である）ランループ検査レポートが受信されると、現在実行中の全てのループ検査が中止される。コントローラデバイスは、現在実行中の検査がない場合であっても、ＨＡＮＤＳＨＡＫＥ＿ＳＵＣＣＥＳＳＦＵＬで応答する。

図３７は、３２ビットデバイスタイムスタンプ（ミリ秒単位）レポートの例示的なバイトシーケンスを示している。０ｘＦＦの入力レポートＩＤ値が割り当てられている（バイト１）。３２ビットデバイスタイムスタンプ（ミリ秒単位）レポートは、コントローラデバイス１１０、７１０、１０１０の内部クロックによってレポートされる時刻を反映している。３２ビットデバイスタイムスタンプ（ミリ秒単位）レポートは、ループ検査に関してのみ使用される。

モバイルコントローラデバイスとホストデバイスとの間のデータの転送
一側面においては、本明細書に開示するプラットホームに依存しない通信プロトコルは、ヒューマンインタフェースデバイス（例えば、コントローラデバイス１０１０）からホストデバイス１０２０に制御データを転送する（通信を可能にする）ように設計される。プラットホームに依存しない通信プロトコル１３４は、様々な入力メカニズム（例えば、ジョイスティック及びボタン状態）を有する様々なコントローラデバイスへのサポートを提供し、様々なコントローラデバイスによって制御できる、ゲーム等のアプリケーションを実行するホストデバイスにデータを転送する。更に、本明細書に開示するプラットホームに依存しない通信プロトコルは、他のタイプのデータの転送をサポートするために更なるレポートを追加できるという点で、拡張可能である。プラットホームに依存しない通信プロトコルは、ブルートゥースヒューマンインタフェースプロファイル（ＨＩＤ）又はブルートゥースシリアルポートプロファイル（ＳＰＰ）接続等に関連して説明できるが、他のベースバンド接続にも同様に適用できる。双方向シリアル通信プロトコル１０１７、１０２７は、接続形態から独立している。但し、他のトランスポートプロトコル（例えば、Ｌ２ＣＡＰ）を使用する場合、バイトシーケンス長が不要になり、又は送信において他の「オーバヘッド」が必要になることもある。

図３８は、モバイルコントローラデバイスとホストデバイスとの間の通信を実現する処理３８００を示すフローチャートである。コントローラデバイス上のファームウェアは、３８１０において、モバイルコントローラデバイス（例えば、ボタン、ジョイスティック、トラックボール等）が利用可能な様々な入力メカニズムが提供する入力信号（例えば、アナログ信号及びデジタル信号）を監視する。各入力メカニズムは、１つ以上の入力要素（例えば、ボタン）を含むことができる。３８２０において、信号イベントが発生すると（例えば、ボタンが押下され、ジョイスティックが操作されると）、コントローラファームウェアは、双方向シリアル通信プロトコル１０１７を用いてメッセージを生成し、このメッセージをホストデバイス１０２０に送信する。

コントローラファームウェアは、３８３０において、検出された信号イベントに基づいて、メッセージを生成する。メッセージは、複数のバイトから構成され、ポテンショメータ又は多自由度アナログジョイスティックからのアナログ信号、例えば、光学マウス又はよりハイエンドのロボットデバイス内に配設されているデジタルエンコーダ、加えられる圧力の変化に比例する信号を提供するフォースセンシティブレジスタ、加速度計及びジャイロスコープ信号、トラックボールからの信号、例えば、歪みゲージベースのナビゲーションスティック等の力検出デバイスからの信号、光センサからの比例する又はデジタル信号、電磁センサからの信号等を含む、ゲームにおいて一般的に使用されている様々なセンサをサポートするように設計されている。ＨＩＤベースの手法の場合、バイトシーケンスは、カスタムデスクリプタ内で定義される。固定長シリアル法の場合、センサからの信号と、プリセットのバイトシンタクスとの間で、最も適合するものが採用される。双方向シリアル通信プロトコルの場合、バイトシーケンスは、可変であり、センサの実際の出力及び／又はモバイルコントローラデバイスから出力される他の何らかのデータに完全に適合する。

バイトシーケンスの少なくとも１つは、モバイルコントローラデバイスが使用可能な入力メカニズム上の１つ以上の入力要素にマッピングされる。例えば、モバイルコントローラデバイスがキーパッドを含む場合、バイトの少なくとも１つをキーパッド上のボタンの１つ以上にマッピングすることができる。同様に、ジョイスティックの場合、バイトの少なくとも１つをジョイスティック及び／又はジョイスティック上のボタンの様々な動きにマッピングすることができる。更に、各センサタイプは、個別のレポートタイプ識別子によって表すことができ、これにより、同じファームウェア及びホストソフトウェアによって様々なセンサをサポートできる。

３８４０では、生成されたメッセージをホストデバイスに送信する。ホストデバイス上で動作し、ホストアプリケーションにリンクされているコントローラドライバは、３８５０において、メッセージを受信し、３８６０において、このメッセージを１つ以上のアプリケーションレベルイベントに翻訳する。そして、３８７０において、これらの翻訳されたイベントをホストアプリケーションに送信する。３８８０において、ホストアプリケーションは、翻訳されたイベントを処理する。例えば、ホストアプリケーションがゲームである場合、翻訳されたイベントは、ボタン押圧、ジョイスティックの動き等に対応するゲーム機能を実行するように処理される。

ブルートゥース実装
コントローラデバイスとホストデバイスとの間で接続を確立するために、コントローラデバイス１０１０は、接続の主導権を有する他のデバイスを待機する。ホストデバイス１０２０（例えば、携帯電話機、ＰＣ、モバイル機器等）は、コントローラデバイス１０１０との接続を確立する主導権を有する。コントローラデバイス１０１０は、ホストデバイス１０２０に接続するためのＳＰＰサーバ（又はＬ２ＣＡＰサーバ等）を提供する。サーバは、汎用一意識別子（universally unique identifier：ＵＵＩＤ）を用いて、サービス発見プロファイル（Service Discovery Profile：ＳＤＰ）によって特定できる。一実施の形態においては、このＵＵＩＤは、プラットホームに依存しない通信プロトコルに関連付けて選択することができる。プラットホームに依存しない通信プロトコルの将来の全ての実装は、後方互換性（backwards-compatibility）を保つために、同じＵＵＩＤを用いることができる。異なるＵＵＩＤを使用する場合、後方互換性は、保証されない。コントローラデバイスに接続しようとするホストデバイス１０２０は、ＵＵＩＤを特定できる。変形例として、プラットホームに依存しない通信プロトコルのアップグレードを反映するようにＵＵＩＤを変更してもよい。

例示的なアプリケーション
プラットホームに依存しない通信プロトコルを介して転送されるデータは、センサ出力に直接関連していてもよく、直接は関連していなくてもよい。例えば、タイムスタンプデータを読み出してもよい。他の具体例では、モバイルコントローラデバイスを他のプラットホームのためのデータ転送及びストレージデバイスとして使用してもよい。

図３９〜図４４は、プラットホームに依存しない通信プロトコルを適用できる幾つかの具体例を示している。図３９は、ナビゲーションシステム３９２０上のマッピングアプリケーションを制御するＪａｖａ（登録商標）対応リモートコントローラデバイス３９１０を実装する例示的なシステム３９００を示している。例えば、リモートコントローラデバイス３９１０は、自動車のダッシュボードに取り付けられ又はセンタコンソールに統合されたカーナビゲーションシステム３９２０上のマッピングアプリケーションを制御するために使用することができる。リモートコントローラデバイス３９１０は、手で握持することができ、ハンドル等に固定することもできる。この具体例のベースバンド接続は、ナビゲーションシステムによってサポートされていれば、ブルートゥースであってもよく、又はＵＳＢ等の有線接続であってもよい。コントローラデバイス３９１０により、リモートコントローラ上の固有の設計を用いて、所望の住所及び地点をナビゲーションシステム３９２０に入力することができる。本明細書に開示するプラットホームに依存しない通信プロトコルによって、コントローラ及びナビゲーションシステムの何れの側にも大きな容量のメモリを使用することなく、このような情報を効率的に符号化し、ナビゲーションシステム３９２０に転送することができる。

図４０は、ＧＰＳ対応デバイス間のデータ交換を提供する例示的なシステム４０００を示している。例えば、ＧＰＳ対応の自動車４０２０、リモートコントローラデバイス４０１０及び携帯電話機４０３０上で実行されるマッピングアプリケーション４０３２は、本明細書に開示するプラットホームに依存しない通信プロトコルを介して、互いに通信できる。プラットホームに依存しない通信プロトコルをブルートゥース４０４０上に実装することによって、ＧＰＳ対応の自動車４０２０は、携帯電話機４０３０と通信することができる。自動車４０２０から携帯電話機に送信される特定の情報には、イグニッションを切った時点の自動車４０２０のＧＰＳ位置を記述するデータを含ませてもよい。例えば、本明細書に開示するプラットホームに依存しない通信プロトコルを実装することによって、同時係属中の特許出願、発明の名称、「System and Method for Providing Local Maps Using Wireless Handheld Devices」（米国特許出願番号第１１／６２０，６０４号）に開示されている通信が可能になる。この同時係属中の特許出願（米国特許出願番号１１／６２０，６０４）の内容は、引用によって本願に援用される。

図４１は、携帯電話機４１１０、自動車４１２０及びＰＣ４１３０の間のデータ通信を実現する例示的なシステム４１００を示している。例えば、ブルートゥースを装備する自動車４１２０は、プラットホームに依存しない通信プロトコルを介して、携帯電話機４１１０に、データ（例えば、車の機械的な状態情報）を通信できる。そして、携帯電話機４１１０によって、本明細書に開示するプラットホームに依存しない通信プロトコルを用いて、ブルートゥースに対応するＰＣ４１３０にデータをアップロードすることができる。自動車の走行距離、摩耗及び損傷等の情報をＰＣ上で追跡して、自動車が故障する前に、事前の整備及び修理を適切なタイミングで行うことができる。

同様の具体例（図示せず）において、コントローラは、携帯型の又は自動車に取り付けられたナビゲーションデバイスから、ＧＰＳ情報を検索し、将来、レビューのためにＰＣにアップロードするために、このＧＰＳ情報を保存してもよい。

図４２は、複数の健康器具及びフィットネス機器間でデータ通信を実現するするための例示的なシステム４２００を示している。例えば、本明細書に開示するプラットホームに依存しない通信プロトコルを用いて、携帯電話機４２１０を歩数計４２２０にリンクできる。歩数計４２２０からのデータは、シリアル化することができる。ユーザが運動をすると、歩数計は、シリアル化された歩数計データを携帯電話機４２１０にストリーミングすることができ、これによって歩数計を装着したユーザの運動の状態を追跡することができる。携帯電話機４２１０が受信したデータは、本明細書に開示する同様のプラットホームに依存しない通信プロトコルを用いて、ＰＣに転送できる。

図４３は、Ｊａｖａ（登録商標）対応ジョイスティックコントローラ４３１０と携帯電話機４３２０との間でデータ通信を実現するにする例示的なシステム４３００を示している。例えば、アナログジョイスティックを備えるリモートコントローラ４３１０は、本明細書に開示するプラットホームに依存しない通信プロトコルを介して、携帯電話機４３２０と通信できる。携帯電話機４３２０は、例えば、Ｊ２ＭＥプラットホーム上でゲームを実行できる。このゲームは、プラットホームに依存しない通信プロトコルをサポートし、したがって、このゲームは、ブルートゥースを介してコントローラデバイス４３１０から携帯電話機４３２０に転送されるアナログジョイスティック信号、他のスイッチ信号又は他の何らかのデータを符号化するソフトウェアライブラリを利用できる。例えば、本明細書に開示するプラットホームに依存しない通信プロトコルを実装することによって、同時係属中の特許出願、発明の名称、「Human Input Acceleration System」（米国特許出願番号第１１／５１９，４５５号）に開示されている通信が可能になる。

図４４は、多人数参加型モバイルゲームのシナリオにおいて通信を実現する例示的なシステム４４００を示している。例えば、携帯電話機４４３０上のゲームは、２人のプレイヤが遊戯できる。各プレイヤは、それぞれのコントローラ４４１０、４４２０を有する。携帯電話機４４３０は、Ｊ２ＭＥプラットホーム上のゲームをサポートし、及びＴＶ又は他のディスプレイデバイス４４４０へのビデオ出力をサポートする。携帯電話機４４３０は、本明細書に開示するプラットホームに依存しない通信プロトコルを介して、両方のコントローラ４４１０、４４２０と同時に通信する。２人のゲームプレイヤは、携帯電話機４４３０上で実行されるゲームを遊戯しながら、ゲームコンソールと同様の体験を楽しむことができる。

他の具体例（図示せず）では、コントローラデバイスは、ホストデバイス（例えば、携帯電話機）からゲーム状態情報を読み出し、この情報をＰＣに転送して、バックアップを行い、又はＰＣ上でもサポートされているゲームのためのプラットホームに依存しないゲームプレイを行ってもよい。逆に、コントローラデバイスは、ゲーム状態情報をＰＣから読み出し、これを携帯電話機に転送してもよい。また、他のプラットホームをサポートしてもよい。したがって、モバイルコントローラデバイスは、１つのプラットホームから他のプラットホームにゲーム体験を運ぶ運搬装置（vehicle）となることができる。例えば、本明細書に開示するプラットホームに依存しない通信プロトコルを実装することによって、同時係属中の特許出願、発明の名称、「Universal Controller for Toy and Games」（米国特許出願番号第１１／５１９，４５５号）に開示されている通信が可能になる。

本発明の主題の実施の形態及び本明細書に開示する機能的動作は、デジタル電子回路で実現してもよく、本明細書に開示した構造及びこれらの均等物を含むコンピュータソフトウェア、ファームウェア又はハードウェアで実現してもよく、これらの１つ以上の組合せで実現してもよい。本発明の主題の実施の形態は、１つ以上のコンピュータプログラム製品、すなわち、アクセス可能なプログラム担体内に符号化され、データ処理装置によって実行され、又はデータ処理装置の動作を制御するコンピュータプログラム命令の１つ以上のモジュールとして実現することもできる。アクセス可能なプログラム担体は、伝播信号又はコンピュータにより読取可能な媒体であってもよい。伝播信号は、人工的に生成された信号であり、例えば、コンピュータによる実行のために、適切な受信装置への送信のために情報を符号化するように機械が生成した電気信号、光信号又は電磁波信号である。コンピュータが読取可能な媒体は、機械可読のストレージデバイス、機械可読のストレージ基板、メモリデバイス、機械可読の伝播信号に作用する組成物又はこれらの１つ以上の組合せであってもよい。

用語「データ処理装置」は、データを処理するための全ての装置、デバイス及び機械を包含し、一例としてプログラミング可能なプロセッサ、コンピュータ、複数のプロセッサ又はコンピュータがこれに含まれる。装置は、ハードウェアに加えて、当該コンピュータプログラムの実行環境を作成するコード、例えば、プロセッサファームウェアを構成するコード、プロトコルスタック、データベース管理システム、オペレーティングシステム又はこれらの１つ以上の組合せを含むことができる。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト又はコードとも呼ばれる。）は、コンパイラ言語又はインタープリタ言語を含む如何なる形式のプログラミング言語で書いてもよく、例えば、スタンドアロンプログラムとして、若しくはモジュール、コンポーネント、サブルーチン又は演算環境での使用に適する他のユニットとして、如何なる形式で展開してもよい。コンピュータプログラムは、必ずしもファイルシステム内のファイルに対応していなくてもよい。プログラムは、他のプログラム又はデータを含むファイル（例えば、マークアップ言語文書内に保存された１つ以上のスクリプト）の一部に保存してもよく、当該プログラムに専用の単一のファイルに保存してもよく、連携する複数のファイル（例えば、モジュール、サブプログラム又はコードの一部を保存する１つ以上のファイル）に保存してもよい。コンピュータプログラムは、１つのコンピュータ上で実行されるように展開してもよく、１つの場所に設けられた又は複数の場所に亘って分散され、通信ネットワークによって相互接続された複数のコンピュータ上で実行されるように展開してもよい。

本明細書に開示したプロセス及びロジックフローは、入力データを処理し、出力を生成することによって機能を実現する１つ以上のコンピュータプログラムを実行する１つ以上のプログラミング可能なプロセッサによって実現してもよい。プロセス及びロジックフローは、例えば、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）又は特定用途向け集積回路（application specific integrated circuit：ＡＳＩＣ）等の専用論理回路によって実行してもよく、これらによって装置を実現してもよい。

コンピュータプログラムの実行に適するプロセッサには、一例として、汎用マイクロプロセッサ及び専用マイクロプロセッサの両方、並びにあらゆる種類のデジタルコンピュータの１つ以上のプロセッサの何れも含まれる。プロセッサは、通常、読出専用メモリ又はランダムアクセスメモリ、若しくはこれらの両方から命令及びデータを受け取る。コンピュータの基本的な要素は、命令を実行するためのプロセッサ、並びに命令及びデータを保存する１つ以上の記憶装置である。また、コンピュータは、通常、データを保存するための１つ以上の大容量記憶装置、例えば、磁気ディスク、光磁気ディスク又は光ディスクを含み、若しくは、大容量記憶装置からデータを受信し、大容量記憶装置にデータを送信し、又はこの両方の動作を行うように大容量記憶装置に動作的に接続されている。但し、コンピュータは、必ずしもこのような装置を有する必要はない。更に、コンピュータは、他の装置内に埋め込んでもよい。

コンピュータプログラム命令及びデータの格納に適するデバイスには、一例として挙げれば、半導体記憶デバイス、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びフラッシュメモリデバイスを含む全ての形式の不揮発性メモリ、媒体及びメモリデバイス、磁気ディスク、例えば、内蔵ハードディスク又はリムーバブルディスク、光磁気ディスク、並びにＣＤ−ＲＯＭディスク及びＤＶＤ−ＲＯＭディスク等が含まれる。プロセッサ及びメモリは、専用論理回路によって補ってもよく、専用論理回路に組み込んでもよい。

ユーザとのインタラクションを提供するために、本明細書に開示する発明の主題の実施の形態は、コンピュータ上で実現してもよく、コンピュータは、ユーザに情報を表示するためのディスプレイ装置、例えば、陰極線管（cathode ray tube：ＣＲＴ）又は液晶ディスプレイ（liquid crystal display：ＬＣＤ）モニタと、ユーザがコンピュータに入力を行うためのキーボード及びポインティング装置、例えば、マウス又はトラックボールとを備えていてもよい。他の種類のデバイスを用いて、ユーザとのインタラクションを提供してもよく、例えば、ユーザからの入力は、音響入力、音声入力又は触覚入力を含む如何なる形式で受け付けてもよい。

本明細書に開示する発明の主題の実施の形態は、コンピュータシステムにおいて実現してもよく、コンピュータシステムは、例えば、データサーバとしてのバックエンドコンポーネント、例えば、アプリケーションサーバであるミドルウェアコンポーネント、又は例えば、ユーザが本明細書に開示する発明の主題の実装例とインタラクトすることができるグラフィカルユーザインタフェース又はウェブブラウザを有するクライアントコンピュータであるフロントエンドコンポーネントを含んでいてもよく、若しくは、これらのバックエンドコンポーネント、ミドルウェアコンポーネント及びフロントエンドコンポーネントの１つ以上の如何なる組合せを含んでいてもよい。システムのコンポーネントは、デジタルデータ通信の如何なる形式又は媒体によって、例えば、通信ネットワークによって相互接続してもよい。通信ネットワークの具体例には、ローカルエリアネットワーク（local area network：ＬＡＮ）と、例えば、インターネット等のワイドエリアネットワーク（wide area network：ＷＡＮ）とが含まれる。

コンピュータシステムは、クライアント及びサーバを含むことができる。クライアント及びサーバは、通常、互いに遠隔にあり、典型的には、通信ネットワークを介して互いにインタラクトする。クライアント及びサーバの関係は、各コンピュータ上で実行され、互いにクライアント−サーバ関係を有するコンピュータプログラムによって生じる。

本明細書は、多くの詳細事項を含んでいるが、これらの詳細事項は、任意の発明の範囲又は特許請求可能な範囲を限定するものとは解釈されず、特定の実施の形態の特定の特徴の記述として解釈される。本明細書おいて、別個の実施の形態の文脈で開示した幾つかの特徴を組み合わせて、単一の実施の形態として実現してもよい。逆に、単一の実施の形態の文脈で開示した様々な特徴は、複数の実施の形態に別個に具現化してもよく、適切な如何なる部分的組合せとして具現化してもよい。更に、以上では、幾つかの特徴を、ある組合せで機能するものと説明しているが、初期的には、そのように特許請求している場合であっても、特許請求された組合せからの１つ以上の特徴は、幾つかの場合、組合せから除外でき、特許請求された組合せは、部分的組合せ又は部分的な組合せの変形に変更してもよい。

同様に、図面では、動作を特定の順序で示しているが、このような動作は、所望の結果を達成するために、図示した特定の順序又は順次的な順序で行う必要はなく、また、図示した全ての動作を行う必要もない。

幾つかの実施の形態及び具体例について説明したが、本明細書の記述及び説明に基づき、他の実施の形態、拡張例、変形例を想到することができる。

更に、データ入力、デバイス制御又はゲーム制御を提供する方法は、異なる順序で実行しても、望ましい結果を達成できることがある。したがって、他の実施の形態も、特許請求の範囲に含まれる。

Claims (22)

1. 通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を提供するステップを有し、前記提供するステップは、
   前記モバイルコントローラデバイスの１つ以上のデータパケットを記述するバイトの列を、前記モバイルコントローラデバイスから前記ホストデバイスに供給するステップと、
   前記ホストデバイスがネイティブデバイスドライバを有することが検出された場合、前記ネイティブデバイスドライバを用いて、前記供給されたバイトの列を解析するステップと、
   前記ホストデバイスがネイティブデバイスドライバを含んでいないことが検出された場合、前記供給されたバイトの列を解析するためのデバイスドライバを提供するステップとを有する方法。
2. 前記デバイスドライバを提供するステップは、前記供給されたバイトの列に基づいて、カスタマイズされたヒューマンインタフェースデバイスドライバを提供するステップを有する請求項１記載の方法。
3. 前記プラットホームに依存しない双方向通信を提供するステップは、Ｊａｖａ（登録商標）プラットホームと互換性がある双方向通信を提供するステップを有する請求項１記載の方法。
4. 前記バイトの列を供給するステップは、前記バイトの列からの固定数のバイトを用いて、ネイティブヒューマンインタフェースデバイスデスクリプタがサポートしていない１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成するステップを有する請求項１記載の方法。
5. 前記１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成するステップは、ジョイスティック、リニアポテンショメータ、トラックボール、エンコーダ、フォースセンシティブレジスタ、歪みゲージ、一連のデジタルスイッチ、加速度計、ジャイロ、慣性センサ及び電磁センサからなるグループから選択される少なくとも１つをサポートする１つ以上のデバイス固有のデスクリプタを生成するステップを有する請求項４記載の方法。
6. 前記プラットホームに依存しない双方向通信を提供するステップは、Ｊａｖａ（登録商標）プラットホームドライバがアクセスできる少なくとも２つの通信チャンネルを提供するステップを有する請求項１記載の方法。
7. 前記バイトの列を供給するステップは、前記モバイルコントローラデバイスのためにカスタマイズされたバイトの可変シーケンスを供給するステップを有する請求項１記載の方法。
8. 前記バイトの可変シーケンスを供給するステップは、
   前記バイトのシーケンス内の各バイトを、前記モバイルコントローラデバイス上の１つ以上の入力要素にマッピングするステップと、
   前記入力要素の状態に基づいて、各バイトに割り当てられている値を変更するステップとを有する請求項７記載の方法。
9. コンピュータが読取可能な媒体上で実現され、データ処理装置に動作を実行させるコンピュータプログラム製品において、前記動作は、
   通信プロトコルを介して、モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を提供することを含み、前記提供は、
   前記モバイルコントローラデバイスの１つ以上のデータパケットを記述するバイトの列を、前記モバイルコントローラデバイスから前記ホストデバイスに供給することと、
   前記ホストデバイスがネイティブデバイスドライバを有することが検出された場合、前記ネイティブデバイスドライバを用いて、前記供給されたバイトの列を解析することと、
   前記ホストデバイスがネイティブデバイスドライバを含んでいないことが検出された場合、前記供給されたバイトの列を解析するためのデバイスドライバを提供することとを含むコンピュータプログラム製品。
10. 前記供給されたバイトの列に基づいて、カスタマイズされたヒューマンインタフェースデバイスドライバを提供することを更に含む動作を前記データ処理装置に実行させる請求項９記載のコンピュータプログラム製品。
11. 少なくとも、Ｊａｖａ（登録商標）プラットホームと互換性がある双方向通信を提供することによって、プラットホームに依存しない双方向通信を提供することを更に含む動作を前記データ処理装置に実行させる請求項９記載のコンピュータプログラム製品。
12. 少なくとも、前記バイトの列からの固定数のバイトを用いて、ネイティブヒューマンインタフェースデバイスデスクリプタがサポートしていない１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成することによって、バイトの列を供給することを更に含む動作を前記データ処理装置に実行させる請求項９記載のコンピュータプログラム製品。
13. 少なくとも、ジョイスティック、リニアポテンショメータ、トラックボール、エンコーダ、フォースセンシティブレジスタ、歪みゲージ、一連のデジタルスイッチ、加速度計、ジャイロ、慣性センサ及び電磁センサからなるグループから選択される少なくとも１つをサポートする１つ以上のデバイス固有のデスクリプタを生成することによって、１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成することを更に含む動作を前記データ処理装置に実行させる請求項１２記載のコンピュータプログラム製品。
14. Ｊａｖａ（登録商標）プラットホームドライバがアクセスできる少なくとも２つの通信チャンネルを有するプラットホームに依存しない双方向通信を提供することを更に含む動作を前記データ処理装置に実行させる請求項９記載のコンピュータプログラム製品。
15. 前記モバイルコントローラデバイスのためにカスタマイズされたバイトの可変シーケンスを有するバイトの列を供給することを更に含む動作を前記データ処理装置に実行させる請求項９記載のコンピュータプログラム製品。
16. バイトの可変シーケンスを供給することを更に含む動作を前記データ処理装置に実行させ、前記バイトの可変シーケンスを供給することは、
    前記バイトのシーケンス内の各バイトを、前記モバイルコントローラデバイス上の１つ以上の入力要素にマッピングすることと、
    前記入力要素の状態に基づいて、各バイトに割り当てられている値を変更することとを含む請求項１５記載のコンピュータプログラム製品。
17. 通信スタックを動作させるように構成された通信メカニズムを備え、前記通信メカニズムは、
    モバイルコントローラデバイスをホストデバイスに接続するように構成されたベースバンドプロトコルと、
    前記ベースバンドプロトコル上で動作し、それぞれがバイトのシーケンスを含む１つ以上のメッセージを前記ホストデバイスに送信するように構成された双方向シリアル通信プロトコルと、
    前記モバイルコントローラデバイスが使用可能な様々な入力メカニズムが提供する入力信号を監視し、前記１つ以上のメッセージを生成するように構成されたコントローラファームウェアとを備え、
    前記双方向シリアル通信プロトコルは、前記ベースバンドプロトコルを介して、前記モバイルコントローラデバイスとホストデバイスとの間でプラットホームに依存しない双方向通信を実現するモバイルコントローラデバイス。
18. 前記双方向シリアル通信プロトコルは、Ｊａｖａ（登録商標）プラットホームと互換性がある双方向通信を含むプラットホームに依存しない双方向通信を実現する請求項１７記載のシステム。
19. 前記コントローラファームウェアは、前記バイトのシーケンスからの固定数のバイトを用いて、ネイティブヒューマンインタフェースデバイスデスクリプタがサポートしていない１つ以上のセンサをサポートする１つ以上のデバイス固有のデスクリプタを生成するように更に構成されている請求項１７記載のシステム。
20. 前記コントローラファームウェアは、ジョイスティック、リニアポテンショメータ、トラックボール、エンコーダ、フォースセンシティブレジスタ、歪みゲージ、一連のデジタルスイッチ、加速度計、ジャイロ、慣性センサ及び電磁センサからなるグループから選択される少なくとも１つをサポートする１つ以上のデバイス固有のデスクリプタを生成するように更に構成されている請求項１９記載のシステム。
21. 前記コントローラファームウェアは、それぞれがモバイルコントローラデバイスのためにカスタマイズされたバイトの可変シーケンスを含む１つ以上のメッセージを生成するように更に構成されている請求項１７記載のシステム。
22. 前記コントローラファームウェアは、前記バイトのシーケンス内の各バイトを、前記モバイルコントローラデバイスが使用可能な様々な入力メカニズムの１つ以上の入力要素にマッピングし、前記マッピングされた１つ以上の入力要素の状態に基づいて、各バイトに割り当てられている値を変更するように更に構成されている請求項２２記載のシステム。

Images