JP6266615B2 - データトンネルを用いるインタフェースを介した複数のプロトコルデータ要素の送信 - Google Patents

Description

本発明の実施形態は、データ通信分野全般に係り、特にデータトンネルを用いるインタフェースを介した複数のプロトコルデータ要素の送信に係る。

複数種のデータ搬送に、コネクタ又はその他の物理インタフェースを利用する装置がある。例えば、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）（登録商標）仕様によると、ＭＨＬデータ及びＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）（登録商標）データの双方の送信にコネクタを利用することができ、コネクタがＭＨＬデータの送信に利用されていないときにＵＳＢデータを送信してもよい。

しかしながら、この使用は、いずれの場合であってもこれらプロトコルのうちの１つのみに制限されてしまうことがある。例えば、これらプロトコルが双方ともにコネクタ又はその他の物理インタフェースの帯域幅の全部又はほとんどを利用してしまえば、双方のプロトコルのデータを同時に収容するのに十分な帯域幅はなくなる。

本発明の実施形態は、一例として挙げられるものであって限定を意図するものではなく、添付の図面中において、同一の参照符号は同様の要素を示す。
データトンネルを用いるコネクタを介した複数のプロトコルデータ要素のデータトンネリング送信を提供する装置及びシステムの一実施形態を示している。 メディアデータトンネルを使用せず、コマンドを使用したデータの送信方法の一実施形態を示している。 は、メディアデータトンネルを使用した、データの送信方法の一実施形態を示している。 メディアデータトンネルを用いた通信のためのメッセージ構成の一実施形態を示している。 メディアデータトンネルを用いた通信のためのメッセージ構成の一実施形態を示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。 メディアデータトンネルの実装における拡張ヘッダのパケット構造の一実施形態を示している。 標準ＨＩＤ構造との比較において、一実施形態に係るメディアデータトンネルエンコーダのペイロード構造を示している。 標準ＨＩＤ構造との比較において、一実施形態に係るメディアデータトンネルエンコーダのペイロード構造を示している。 標準ＨＩＤ構造との比較において、一実施形態に係るメディアデータトンネルエンコーダのペイロード構造を示している。 一実施形態に係るメディアデータトンネルの層を示している。 ＨＤＭＩ対応ビデオディスプレイ及びＨＤＭＩ対応ソースデバイス間の接続を示している。 ＨＤＭＩ／ＭＨＬドングル及びＭＨＬ対応ビデオソースデバイス間の接続を示している。 ＭＨＬ対応ビデオシンクデバイス及びＭＨＬ対応ビデオソースデバイス間の接続を示している。 ＨＤＭＩ／ＭＨＬドングル及びＭＨＬ対応ビデオソースデバイス間の接続の一実施形態を示している。 ＭＨＬ対応ビデオシンクデバイス及びＭＨＬ対応ビデオソースデバイス間の接続を示している。 データ周辺機器を備えたモバイルデバイスのＵＳＢリンクを示している。 ヒューマンインタフェースデバイスを備えたモバイルデバイスのリンクの一実施形態を示している。 ヒューマンインタフェースデバイスを備えたモバイルデバイスのリンクの一実施形態を示している。 特定データの送信用データトンネルを備えた一実施形態又はシステムを示している。 メディアデータトンネルを用いた通信プロセスの一実施形態を説明するためのタイミング図である。

本発明の実施形態は、データトンネルを用いるインタフェースを介した複数のプロトコルデータ要素の送信全般に係る。

本発明の第１様態によると、一実施形態に係る装置は、データ送信又はデータ受信を行う送信機又は受信機と、前記装置のデータを取扱う処理要素と、データ転送を行い、データチャンネルとの接続及びコントロールチャンネルとの接続を行うコネクタとを備える。前記処理要素は、前記コントロールチャンネルにおける第１プロトコルのデータの転送を行うものであり、前記コントロールチャンネルを介した前記データの転送には、第２プロトコルのデータの転送を行うための、前記第１プロトコルの１つ又は複数の一般コマンドの使用が含まれる。前記第２プロトコルのデータは、前記第１プロトコルを通じて送信されるのに先立って最適化され、前記データチャンネルにおけるデータ転送及び前記コントロールチャンネルにおけるデータ転送は、少なくとも部分的に同時に行われる。

本発明の第２様態によると、一実施形態に係る方法は、第１の装置において、第１プロトコルの第１データセットを第２の装置から、又は第２の装置へ転送するステップであって、コネクタを介して、前記第１プロトコルのためのデータチャンネルを通じてデータの送信又は受信を行うことを含むステップと、第２プロトコルのデータを前記第１プロトコルを通じて送信するのに先立って最適化するステップと、前記第１の装置において、第２プロトコルの第２データセットを第２装置から、又は、第２装置へ転送するステップであって、前記コネクタを介して、前記第１プロトコルのためのコントロールチャンネルを通じてデータの送信又は受信を行うことを含むステップとを備え、前記第１データセット及び前記第２データセットは、少なくとも部分的に、同時転送され、前記第２データセットは、前記第１プロトコルの１つ又は複数の一般コマンドを使用して転送される。

本発明の実施形態は、データトンネルを用いるインタフェースを介した複数のプロトコルデータ要素の送信全般に係る。

本明細書中の使用において、

「モバイルデバイス」は、電話（スマートフォン等）、ラップトップコンピュータ、ハンドヘルドコンピュータ、タブレットコンピュータ、モバイルインターネットデバイス（ＭＩＤ）、又はその他の電子モバイルデバイスを意味する。

「処理要素」は、データ処理を行うあらゆる電子部品、モジュール、又はその他のユニットであって、汎用プロセッサ又は専用プロセッサ、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）、内蔵プロセッサ、又はビデオプロセッサを含むが、これに限定されるものでない。処理要素は、データ処理に加えてその他の機能を提供する電子部品、モジュール、又はその他のユニットであってもよい。

コネクタ又はその他の物理インタフェースを介して異なるプロトコルのデータを転送するインタフェースがある。例えば、ＭＨＬ仕様によると、オーディオ／ビデオ（Ａ／Ｖ）データ（ＭＨＬデータ）の中継に５ピンコネクタの使用を許容しており、ＭＨＬにコネクタが使用されない場合、この接続はＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）データのサポートに使用されてもよい。しかしながら、ＭＨＬ仕様によると、５ピンコネクタでのＡ／Ｖデータ及びＵＳＢデータの同時搬送はサポートしていない。さらにＭＨＬ仕様は、特定のコマンドを使用したＭＨＬ ＣＢＵＳ（Ｃｏｎｔｒｏｌ Ｂｕｓ）を通じた一般データの転送プロセスを規定しており、このコマンドはＷＲＩＴＥ＿ＢＵＲＳＴコマンド及びＳＥＴ＿ＩＮＴコマンドである。ＭＨＬによるデータ転送の定義は一般的なものであり、特定の使用例に限定されるものでない。本明細書全般において、ＭＨＬ及びＵＳＢを一例として説明するが、本実施形態はこれら特定のプロトコルに限定されるものでない。本明細書中の使用において、一般コマンドとは、特定の送信データ形式に限定されないコマンドであり、従って複数の異なる種別のデータ転送に使用されてもよい。

いくつかの実施形態に係る装置、システム、及び方法によると、データチャンネルの使用を通じて少なくとも部分的に、複数の異なるプロトコルを使用したデータの同時搬送を行うために、インタフェースを使用することができる。特定の実装における装置、システム、又は方法によると、第１プロトコルデータ（Ａ／Ｖ ＭＨＬデータ等）及び特定の第２プロトコルデータ（ＵＳＢ等）の同時サポートを行うため、ＭＨＬ一般ＷＲＩＴＥ＿ＢＵＲＳＴコマンド及びＳＥＴ＿ＩＮコマンドを適用し、第２プロトコルデータは特定のデータ要素に限定されてもよい。例えば、第２プロトコルデータは、ＭＨＬ接続を通じた、ゲームコントロールデータ、カーソルデータ（マウスデータ、タッチパッドデータ、又はタッチスクリーンデータ等）、キーボードデータ等の低速ＵＳＢヒューマンインタフェースデバイス（ＨＩＤ）データであってもよい。しかしながら本実施形態は、プロトコルデータを特定のデータ要素に制限する動作に限定されるものでない。いくつかの実施形態において、モバイルデバイス及びリモートデータコネクタ間にデータトンネル又はブリッジを生成することにより、複数のプロトコルの機能が有効化される。このデータトンネルはＭｅｄｉａ Ｄａｔａ Ｔｕｎｎｅｌ（ＭＤＴ）と称される。いくつかの実施形態において、リモートデータコネクタは、ＭＨＬ対応ディスプレイ又はＭＨＬドングルへのＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）（登録商標）内に物理的に配置され、ローカルデータコネクタは、モバイルデバイス内に配置されてもよい。

いくつかの実施形態における装置は、ＭＨＬ仕様等、プロトコルの下に動作を拡張するメディアデータトンネルに加え、モバイルデバイスを、ＭＨＬ対応ディスプレイ内又はＨＤＭＩ−ＭＨＬドングル内のいかなる低速データコネクタにトンネルしてもよい。一例によると、メディアデータトンネルを通じて端末アクセスのためのシリアル通信が行われてもよい。

いくつかの実施形態における装置、システム、又は方法は、ＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴ等の一般書込コマンドを保証する実装ガイドを提供し、十分な帯域幅を提供し、ＨＩＤ及び同等の低速アプリケーションに適切な低遅延を提供する。ＷＲＩＴＥ＿ＢＵＲＳＴ等のコマンドを利用して、データ送信速度より遅い速度でデータを中継してもよい。しかしながらこの性能は、ＨＩＤ及び同等のアプリケーションにとって十分でないこともある。いくつかの実施形態において、メディアデータトンネルは、ＨＩＤ及びその他のアプリケーションに十分な性能を発揮するためにＷＲＩＴＥ＿ＢＵＲＳＴ制限を低減し、実際の使用例において十分な性能を提供するために利用される。

いくつかの実施形態における装置、システム、または方法は、ＭＨＬ等のプロトコルを多目的バスとすることができる。設計により、ＭＨＬは、モバイル環境におけるオーディオ／ビデオ（Ａ／Ｖ）をサポートすることを目的とする。いくつかの実施形態における装置、システム、又は方法は、ヒューマンインプット及び周辺機器によるデータ転送もサポートすべく、機能を拡張する。いくつかの実施形態によると、ＭＨＬにＭＨＬデータ及び低速ＵＳＢデータを同時に搬送させることにより、機能を拡張する。しかしながら実施形態は、特定のプロトコルに限定されるものでない。例えば、追加的なデータ転送をサポートするのに一般的機構が用いられるため、第１プロトコルのデータはいかなる低速バスからのデータと組み合わせられてもよい。

ＭＨＬ仕様は、実装要件及びタイムアウトを通じて他のプロトコルのデータトンネリングを制限する。この仕様によると、ＧＲＴ＿ＷＲＴメッセージの受信に１０ミリ秒のタイムアウトを課す。ＭＨＬデバイスは、許容されたタイムアウト期間の大部分を消費する場合、ＭＨＬのＷＲＩＴＥ＿ＢＵＲＴコマンドを使用したトンネリングを１００イベント／秒未満まで抑える。ＭＨＬ仕様はまた、同様に帯域幅を低減するＷＲＩＴＥ＿ＢＵＲＳＴコマンドのための３段階調製プロセスも規定している。メディアデータトンネルは、ＷＲＩＴＥ＿ＢＵＲＳＴによってサポートされた帯域幅を向上しつつ、ＭＨＬ仕様に合うディスカバリ及び調整のための追加ガイドラインを通じて、ＭＨＬ仕様における制限に対する相互運用可能なソリューションを示している。

同一のコネクタを通じて、ＵＳＢ及びＭＨＬ等、第１プロトコル及び第２プロトコルの双方について、そのすべての特徴を提供するのは不可能又は実際的でないこともある。ＭＨＬ仕様は、ＵＳＢデータをサポートするいかなる手段も明示していない。いくつかの実施形態における装置、システム、または方法は、各プロトコルが通常ポートの全帯域幅又はその多くを使用する場合、複数種のプロトコルデータの送信を可能とする。例えば、ＭＨＬではＡ／Ｖ又はＵＳＢ周辺機器のための単一の５ピンコネクタの使用を許諾するが、ポートの機能は、随時、互いに排他的にＡ／Ｖサービス及びＵＳＢサービスの提供に限定される。ＭＨＬではＡ／Ｖポート及びＵＳＢポートを単一の５ピンコネクタに結合しているが、従来のポートは、ＵＳＢ仕様及びＭＨＬ仕様が各々、互いに独立した目的のために同一の差動対の全帯域幅を割り当てるため、ＭＨＬサービス及びＵＳＢサービスを同時に提供することができず、並列して使用されると、ＭＨＬ及びＵＳＢが衝突してしまう。

いくつかの実施形態において、コネクタは、例えばＰＣに対するＵＳＢ対応リンクをサポートする帯域幅が不足していたとしても、Ａ／Ｖ周辺機器及び低速ＵＳＢ周辺機器に対して同時にサービスを提供してもよい。いくつかの実施形態において、ＵＳＢ周辺機器データ等の第２プロトコル周辺機器データは、第１プロトコルに準拠したコマンドを用いて、第１プロトコル制御バスを備えたコントロールチャンネルを通じて送信されてもよい。一例によると、ＭＨＬに準拠したコマンドを使用することにより、ＵＳＢデータがＣＢＵＳ上のＭＨＬデータと連動しないように保証する。さらにＣＢＵＳ上のＵＳＢデータを符号化することにより、ＭＨＬ仕様に準じて、Ａ／Ｖデータの搬送を行うために差動対を残しておく。単一配線のコントロールバスは通常、１つの差動対に有効な帯域幅の一部を提供するため、装置またはシステムは低速ＵＳＢデータ等の低速データに限定されることもあり、メディアデータトンネルはモバイル装置及びコンピュータ間のＵＳＢ対応リンクをサポートするのに十分な速度を有さないこともある。

従来のデバイスによると、モバイルデバイス上の５ピンＵＳＢポートは、主に、デバイスをＰＣにリンクさせるサービスを提供し、Ａ／Ｖサービスを提供することは求められない。例えば、ＭＨＬ仕様は、ＵＳＢデータ及びＡ／Ｖサービスの同時提供を行うよう規定されていない。ＭＨＬは代わりに、ＷＲＩＴＥ＿ＢＵＲＳＴコマンド及びＳＥＴ＿ＩＮＴコマンドを備えており、これらは通常のデータ使用のためにＭＨＬ仕様に規定されている。これらのコマンドは、例えば、ファームウェアのアップグレードを提供するため、又は、小さな専有データのチャンクを低頻度で中継するために使用されてもよい。

しかしながら、スマートフォンは、新たなモバイル操作の出現で、デスクトップディスプレイを駆動しながら、同時にゲームコントローラー、カーソル（マウス、タッチパッド、又はタッチスクリーン）、又はキーボード入力を受信することができるモバイルコンピュータとして考えられている。いくつかの実施形態において、モバイルデバイスは、このような動作のために、独立したコネクタ及びケーブルを通じて並行してＡ／Ｖサービス及びＵＳＢサービスを提供するために使用されている。

いくつかの実施形態において、メディアデータトンネルは、ＭＨＬ送信機及びＭＨＬ受信機間の多目的バスとしてのＭＨＬの使用を許容するＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴコマンド及びＳＥＴ＿ＩＮＴコマンド等のコマンドのアプリケーションを備える。いくつかの実施形態において、メディアデータトンネルは、ＭＨＬのリンクコントロールバスリンク層及びトランスレーション層を利用した２層トンネルを提供する。メディアデータトンネルは、これらの層の使用を通じて、リンク層及びトランスレーション層におけるＭＨＬのフローコントロールを利用している。同様に、メディアデータトンネルは、リンク層及びトランスレーション層におけるＭＨＬエラー検出を利用してもよい。いくつかの実施形態において、メディアデータトンネルの実装により、ＭＨＬの特徴を選択的に拡張してもよい。いくつかの実施形態において、フローコントロール、エラー検出、及び追加再試行の実装は、トンネルされたバスに期待される性能又は特徴によって決まる。いくつかの実施形態において、ＭＨＬプロトコルで最適化データが転送されるのに先立ち、ＵＳＢデータが最適化される。本明細書中での使用において、最適化データとは、最適化プロセス又は適合プロセスの施されたデータをいい、これらのデータが最適なデータ形式又はソリューションであることを意味するものではない。

図１は、データトンネルを用いるコネクタを介した、複数のプロトコルデータ要素のデータトンネリング送信を提供する装置及びシステムの一実施形態を示している。同図において、ソースデバイス１１０（モバイルデバイス又はその他の装置等）は、シンクデバイス１６０（テレビジョン又はその他のビデオシステム、コンピュータ、ゲーム機、ＭＨＬドングル、又はその他の装置）に連結されている。ソースデバイス１１０及びシンクデバイス１６０は、ケーブル１５０を介して連結されてもよい。ケーブル１５０には、データ送信用の一方向差動対を備えたデータチャンネルと、双方向（単一線）コントロールバス（ＣＢＵＳ）を備えたコントロールチャンネルとを有するＭＨＬ互換性ケーブルが含まれてもよい。１つ又は複数のヒューマンインタフェースデバイスがシンクデバイス１６０に連結される。

ソースデバイス１１０は、ＭＨＬと互換性のあるＵＳＢレセプタクル等、ケーブル１５０の接続を行うコネクタ１４０を備えてもよい。シンクデバイスは、ケーブルの接続を行うコネクタ１９０を備えてもよく、このコネクタは代わりにＵＳＢコネクタであってもよく、ディスプレイのＳＯＣ又は通常ドングルと称される変換要素（ＭＨＬ−ＨＤＭＩドングル）が連結される他のレセプタクル（ＨＤＭＩレセプタクル等）であってもよい。

いくつかの実施形態において、ソースデバイス１１０及びシンクデバイス１６０の双方には、電気回路等、第２プロトコルのための要素が備えられ、第２プロトコルはＵＳＢであってもよい。同図において、ソースデバイス１１０には第２プロトコル要素１２０が備えられ、これがＵＳＢホストとして動作してもよい。またシンクデバイス１６０には第２プロトコル要素１７０が備えられ、これがＵＳＢデバイスとして動作してもよい。

いくつかの実施形態において、ソースデバイス１１０及びシンクデバイス１６０は、第１プロトコルで転送されるデータとともに、第２プロトコルのデータを少なくとも一部、同時に（同じタイミングで、又は、重複した期間内に）転送するためにメディアデータトンネルを利用し、第１プロトコルでの転送に先立って第２プロトコルのデータに最適化又は適合化を行う。いくつかの実施形態において、メディアデータトンネルには、ＵＳＢデータ等、双方向データの転送にケーブル１５０のコントロールバスを使用することが含まれる。いくつかの実施形態において、第１プロトコルの識別フィールドは、コントロールバスを介した受信装置の識別に、データの最適量又は最小量を利用する。例えば、第１プロトコルの識別フィールドは、２バイトのデータと同一のサイズを有する。

いくつかの実施形態において、シンクデバイス１６０及びソースデバイス１１０は、第２プロトコルのデータ転送に第１プロトコルのコントロールバスコマンドを使用する。この第２プロトコルのデータは、第２プロトコルのフルデータセットのサブセットであってもよい。例えば、第２プロトコルのデータサブセットには、ヒューマンインタフェースデバイスデータが含まれてもよい。同図において、１つ又は複数のヒューマンインタフェースデバイス１５５がシンクデバイス１６０に連結されてもよい。１つ又は複数のインタフェースデバイス１５５には、キーボード、マウス、タッチパッド又はタッチスクリーン、ゲームコントローラ、又はユーザの意思が入力できるその他のデバイスが含まれてもよい。ヒューマンインタフェースデバイスのためのサポートが、ソースデバイス１１０のためのヒューマンインタフェースサポート１３０及びシンクデバイス１６０のためのヒューマンインタフェースサポート１８０として示されている。

いくつかの実施形態において、第２プロトコルの１つ又は複数のメッセージが、第１プロトコルの単一データ送信バーストで送信されてもよい。いくつかの実施形態において、各データバーストは、割込メッセージを通じて調整される。いくつかの実施形態において、割込メッセージの一部が統合され、単一のメッセージとして転送される。

いくつかの実施形態において、メディアデータトンネルには、第１プロトコルの特定の一般コマンドを介した第２プロトコルのデータ送信が含まれ、この一般コマンドにはＭＨＬの一般コマンドが含まれてもよい。同図において、ソースデバイス１１０及びシンクデバイス１６０は、ソースデバイスの一般コマンドサポート１２５及びシンクデバイスの一般コマンドサポート１７５として示された一般コマンドサポートを含むものとして描かれており、これらのサポートには、コマンドＷＲＩＴＥ＿ＢＵＲＳＴ及びＳＥＴ＿ＩＮＴのサポートを含むＭＨＬのためのサポートが含まれてもよい。

いくつかの実施形態において、シンクデバイス１６０は、例えば、キーボードのキーストローク、ゲームコントローラの入力又は動き、若しくはカーソル（マウス、タッチパッド、又はタッチスクリーン）の動きを記述したデータ等、ヒューマンインタフェースデバイスからのＨＩＤコマンドデータを受信してもよい。いくつかの実施形態において、シンクデバイス１６０及びソースデバイス１１０は、ＨＩＤデータ等の送信のために１つ又は複数の一般コマンドを利用してもよく、このようなデータの送信は、ソースデバイス１１０及びシンクデバイス１６０間のケーブル１５０によって提供される双方向コントロールバスを利用して達成されてもよい。ＵＳＢは双方向であり、デバイスがＵＳＢミクロＡＢレセプタクル等のレセプタクルを使用する場合、ＵＳＢポートはＵＳＢホスト又はＵＳＢデバイスのように振舞ってもよい。同図において、メディアデータトンネルの目的のため、ソースデバイス１１０は、主にＷＲＩＴＥ＿ＢＵＲＳＴ受信機として振る舞い、Ａ／Ｖソースデバイスは、ヒューマンインタフェースデバイスと連結されて、主にＨＩＤデータ送信のためのＷＲＩＴＥ＿ＢＵＲＳＴ送信機として振舞ってもよい。しかしながら実施形態はこれに限定されるものでなく、デバイスの役割は反対であってもよい。

図２は、メディアデータトンネルを使用せず、ＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴコマンド等のコマンドを使用したデータの送信方法の一実施形態を示している。同図において、モバイルデバイスとの連結を行うクレードル等の要求デバイス２００は、モバイルフォン等の応答装置２０５と連結されている。いくつかの実施形態において、新たなＨＩＤイベントが発生すると、要求デバイス２００は、モバイルフォン等の応答デバイス２０５のスクラッチパッドレジスタに書込許可を要求する（２１０）ため、ＲＥＱ＿ＷＲＴビットセットで中継ＳＥＴ＿ＩＮＴコマンドを提供する（２１２）。応答デバイス２０５は、ＲＥＱ＿ＱＲＴビットを検出し（２１４）、ＧＲＴ＿ＷＲＴビットを含んだＳＥＴ＿ＩＮＴコマンドで、要求デバイスに対して書込要求への許可を与える（２１６）。要求デバイス２００は、ＧＲＴ＿ＷＲＴビットを検出する（２１８）。受容ビットが設定されている場合（２２０）、要求デバイス２００により、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドの開始（２２２）及びＤＣＳＲ＿ＣＨＧビットによるＳＥＴ＿ＩＮＴコマンドの書込（２２４）を行う。応答デバイス２０５は、ＤＳＣＲ＿ＣＨＧ＝１を検出し（２２６）、そのローカルスクラッチパッドレジスタの読取動作を行う（２２８）。

図３は、ＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴコマンド等のメディアデータトンネルを使用した、データの送信方法の一実施形態を示している。同図においても、モバイルデバイスとの接続を行うクレードル等の要求デバイス３００は、モバイルフォン等の応答装置３０５と連結されている。いくつかの実施形態において、システムの準備が整っている場合、要求デバイス３０５はＤＳＣＲ＿ＣＨＧとＲＥＱ＿ＷＲＴのビットセットでＳＥＴ＿ＩＮＴコマンドを書き込む（３１０）。応答デバイス３０５は、ＲＥＱＴ＿ＷＲＩＴビットを検出し（３１５）、ＧＲＴ＿ＷＲＴビットによりＳＥＴ＿ＩＮＴコマンドで応答する（３２０）。要求デバイス３００は、ＧＲＴ＿ＷＲＴビットを検出する（３２５）。受容ビットが設定されている場合（３３０）、送信機は、受信機のスクラッチパッドレジスタへのアクセスを実現し、新たなＨＩＤイベントを待機してもよい（３３５）。新たなＨＩＤイベントが発生すると（３３５）、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドを開始し（３４０）、要求デバイス３００による書込動作を行い（３４５）、ＤＳＣＲ＿ＷＲＴ ＲＥＱ＿ＷＲＴの書込に戻る（３１０）。いくつかの実施形態において、応答デバイスはＷＲＩＴＥ＿ＢＵＲＳＴを検出し（３５０）、スクラッチパッドを読み取る（３５５）。いくつかの実施形態において、応答装置は、そのローカルスクラッチパッドからデータを検索するのに先立ち、ＤＳＣＲ＿ＣＨＧ及びＲＥＱ＿ＷＲＴビットセットを有する次のＳＥＴ＿ＩＮＴコマンドを待機する。

いくつかの実施形態において、ＣＢＵＳデータトンネルの各端部では、データ処理以外にもＭＨＬ送信機又はＭＨＬ受信機のモニタリング及び制御を行う処理要素は、メディアデータトンネルエンコーダ及びデコーダの論理を実装している。動作中、ＭＨＬ送信機又はＭＨＬ受信機には、マイクロコントローラ又はシステムオンチップ（ＳｏＣ）等の処理要素によってサービスが提供される。処理要素によって実行されたドライバは、サービス論理を管理する。ＭＨＬ仕様によると、ＭＨＬ送信機は、電話機、タブレット、又はその他のモバイルデバイス等のソース装置又はソースシステム内に存在してもよい。ＭＨＬ受信機は、ドッキングステーション、モニター、又はテレビディスプレイ等のシンク装置又はシンクシステム内に存在してもよい。ＭＨＬ受信機はまた、ＭＨＬ−ＨＤＭＩドングル内に存在してもよい。いくつかの実施形態において、ＭＨＬ送信機ドライバ又はＭＨＬ受信機ドライバは、以下に述べるブリッジプロセスの一部等、メディアデータトンネルの符号化サポート及び復号化サポートを提供するため、直接拡張されるか、又は、追加のソフトウェア層を通じて拡張される。

ステージ１：トンネルのディスカバリ及び構築。動作中、第１ステージにおいて、ＭＨＬ送信機及びＭＨＬ受信機は、ＭＨＬ仕様ディスカバリを通じてトンネルリンクを構築する。ＭＨＬ送信機及びＭＨＬ受信機は、ＭＨＬ仕様ディスカバリシーケンスのＭＨＬデータ交換ステージに準じて、ＣＢＵＳデータトンネルを構築する。送信機及び受信機は、データ交換の一部として、デバイス機能レジスタを交換する。この交換は、各サイドが、ＷＲＩＴＥ＿ＳＴＡＴコマンドの送信を通じてアサートされたＤＣＡＰ＿ＲＤＹビットの中継を行うことによって開始される。この交換は、各サイドが、任意且つ独立的にＳＥＴ＿ＩＮＴコマンドを用いてＤＣＡＰ＿ＣＨＧを送信することで後続する。これに対して、ＷＲＩＴＥ＿ＳＴＡＴ及びＳＥＴ＿ＩＮＴの受信装置は、ＲＥＡＤ＿ＤＥＶＣＡＰコマンドのシーケンスを使用してＳＥＴ＿ＩＮＴ送信者の機能を検索する。各サイドは、受信データから、そのＭＨＬピアのＳＰ＿ＳＵＰＰＯＲＴ、ＳＣＲＡＴＣＨＰＡＤ＿ＳＩＺＥ及びＡＤＯＰＴＥＲ＿ＩＤを識別する。いくつかの実施形態において、ＳＰ＿ＳＵＰＰＯＲＴは、メディアデータトンネル参加機器に、そのピアのＷＲＩＴＥ＿ＢＵＲＳＴサポート能力を知らせるものである。ＳＣＲＡＴＣＨＰＡＤ＿ＳＩＺＥは、メディアデータトンネル参加機器に、そのピアにおけるバッファリングサポートを査定させるものである。ＡＤＯＰＴＥＲ＿ＩＤは、後続のすべてのＷＲＩＴＥ＿ＢＵＲＳＴコマンドのためのＭＤＴパケットヘッダとして、ＭＤＴ参加機器によってキャッシュに格納され、再使用されるものである。

いくつかの実施形態において、メディアデータトンネルは、パケット構造及びサービス性能に関するメディアデータトンネルの機能についての情報交換を含むべく、ディスカバリを拡張する。メディアデータトンネルを通じたペイロード交換の開始に先立ち、メディアデータトンネルの送信機は、未来のＷＲＩＴＥ＿ＢＵＲＳＴパケットにおいて使用されるヘッダデータ又は完全なパケット構造を識別する。いくつかの実施形態において、送信機の条件を受け入れ、標準ＷＲＩＴＥ＿ＢＵＲＳＴ機構を用いることであらゆる制約を中継することは、メディアデータトンネルの受信機に課せられた義務である。あるいは、受信装置は、送信機をタイムアウトさせることにより、提示されたパケット構造を拒否してもよい。さらに、メディアデータトンネルの送信装置は、メディアデータトンネルの受信装置の制約に応じて、メディアデータトンネル送信に移るか、メディアデータトンネル受信装置の制限に基づき、メディアデータトンネル受信装置を不適格である見做し、ユーザーにエラーメッセージを返してもよい。

いくつかの実施形態において、拡張ディスカバリにおいて使用されるＷＲＩＴＥ＿ＢＵＲＳＴコマンドは、メディアデータトンネル符号化の一部として、以下に述べる要素を伴うことなく、ＭＨＬ仕様を遵守する。

いくつかの実施形態において、決定論的性能を必要とするあらゆるメディアデータトンネルの実装に対して、メディアデータトンネルの受信装置は、拡張ディスカバリにおいてその性能に係る制約を中継する。ＭＨＬのＷＲＩＴＥ＿ＢＵＲＳＴ機構の性能は決定論的であるものの、特定の要件においては非現実的である。ＭＨＬ仕様では、ＷＲＩＴＥ＿ＢＵＲＳＴ受信装置がＲＥＱ＿ＷＲＴの受信から１０ミリ秒以内にＧＲＴ＿ＷＲＴを中継することが必要である。この仕様はまた、パケットが先行のパケットから１００ミリ秒以内に送信されることも要求する。同時に、２つのタイムアウトは、１６バイトのＷＲＩＴＥ＿ＢＵＲＳＴを終了させるのに２秒を見込んでいる。これらの制約によって最悪の場合の性能を提示し、ＭＨＬのＷＲＩＴＥ＿ＢＵＲＳＴを決定論的にする一方で、許容された遅延によって多くのアプリケーションの下でのデータレートを低減し、メディアデータトンネルのディスカバリにおけるさらなる資格条件を課す。

以下に述べるＨＩＤカーソル、ゲームコントローラ、ｍｄｔ＿ｂｕｒｓｔ＿ｔパケット構造を使用したキーボードイベントデータの中継に用いられる実装において、送信機は、選択されたデータ形式を受信機に知らせる。いくつかの実施形態において、ＭＨＬ仕様ではＤＣＡＰ＿ＲＤＹ又はＤＣＡＰ＿ＣＨＧのタイムリーな中継は要求されないため、メディアデータトンネル参加機器はすべて、タイムリーなディスカバリのため、ＰＡＴＨ＿ＥＮの送信から１０秒以内にＷＲＩＴＥ＿ＳＴＡＴＥコマンドを使用してＤＣＡＰ＿ＲＤＹを中継する。さらに、メディアデータトンネル参加機器は、ＰＡＴＨ＿ＥＮの送信から少なくとも２０秒、もしくは、ＭＨＬ仕様によって求められるより短い間隔以内に、そのピアからデバイス機能レジスタ情報を検索する。この交換後、ＨＩＤデータの送信に先立って、メディアデータトンネルの送信機は、「ＭＤＴＲＥＱｘｙ＿ＦＵＬＬ」の１３バイトペイロードでＷＲＩＴＥ＿ＢＵＲＳＴを送信する。この文字列のｘ要素及びｙ要素が「０１」の２バイトＡＳＣＩＩアレイに等しい場合、この文字列はトークンを表している。このトークンにより、メディアデータトンネルの受信機に、ＷＲＩＴＥ＿ＢＵＲＳＴデータが以下に述べるｍｄｔ＿ｂｕｒｓｔ＿０１＿ｔ構造に準拠する旨を知らせる。

メディアデータトンネルの受信装置が、「ＭＤＴＲＥＱｘｙ＿ＦＵＬＬ」で識別されるパケットを受信するよう準備されている場合、受信装置は「ＭＤＴＡＣＫ＿ａｂｃｄ」を含むＷＲＩＴＥ＿ＢＵＲＳＴで応答する。「ＭＤＴＡＣＫ＿」の文字は、トークンとして機能する。このトークンは、ＨＩＤデータの受信準備が整っていることを示す。「ａｂｃｄ」の文字は、プレースホルダーとして機能する。このプレースホルダーには、１６進法の４ニブルを表すＡＳＣＩＩの文字が含まれる。これら４つの文字は、受信装置がイベントを受信し、ＲＥＱ＿ＷＲＴに応答し、ＤＳＣＲ＿ＣＨＧ割込を取扱い、そのスクラッチパッドを読み出すのに必要な、マイクロ秒で表される最長時間を反映している。しかしながら、受信装置が「ＭＤＴＲＥＱｘｙ＿ＦＵＬＬ」で識別されるパケットにサービス提供できない場合、受信装置は、メディアデータトンネルの送信機へのＷＲＩＴＥ＿ＢＵＲＳＴ送信を、メディアデータトンネル送信機が３回試行を行うのに要する最短時間より長い数ミリ秒である４０ミリ秒間避けることにより、送信装置をタイムアウトさせる。

いくつかの実施形態において、メディアデータトンネルの受信機は、ＨＩＤアプリケーションのため、例えば１０ｍｓ等の期間、受信したＷＲＩＴＥ＿ＢＵＲＳＴを取扱うことが要求される。少なくとも、ＵＳＢ対応ＨＩＤデバイスは、ＵＳＢ仕様の低速基準に準拠している。この基準によると、２つのイベントレポート間の最短間隔は、１０ミリ秒以上である。メディアデータトンネルがＵＳＢ低速、ＨＩＤ装置の最速のものに遅れを取らないために、メディアデータトンネルの受信装置は、「ＭＤＴＡＣＫ＿２７１０」又は「ＭＤＴＡＣＫ＿ａｂｃｄ」で「ＭＤＴＲＥＱｘｙ＿ＦＵＬＬ」に応答する。ここでａｂｃｄは、０〜０×２７１０（１０，０００マイクロ秒）の間の１６進値を反映したＡＳＣＩＩ文字の組み合わせである。メディアデータトンネルの送信機が期待されるペイロードを有するＷＲＩＴＥ＿ＢＵＲＳＴを受信しない場合、ユーザに知らせ、同等のメディアデータトンネルサービスを求める未来の要求を拒絶する。

図４Ａ及び４Ｂは、メディアデータトンネルを用いた通信のためのメッセージ構成の一実施形態を示している。同図において、Ｃ構文で設けられたソフトウェアは、カーソルイベント、ゲームコントローライベント、及びキーボードイベントを含むＨＩＤイベントのパケット構造を示している。

図５Ａ、５Ｂ、５Ｃ、５Ｄ、５Ｅ、５Ｆ、及び５Ｇは、メディアデータトンネルを備えた装置又はシステムの実施形態と併せて用いられるデータパケットを示している。同図において、表は、メディアデータトンネルデータのパケットのレジスタ形式図を提供している。いくつかの実施形態において、データパケットには、キーボード、マウス、ゲームコントローラ、及びその他のカーソル駆動装置のＭＤＴイベントが含まれてもよい。

図５Ａ〜図５Ｇにおいて、以下の形式が示されている。

図５Ａは、ＭＤＴ＿ＢＵＲＳＴパケットのための形式である（５０５）。

図５Ｂは、末尾の連続した０を切り詰めたキーボードのためのＭＤＴ＿ＥＶＥＮＴの形式を示す（５１０）。

図５Ｃは、３を超える数のキーコードを有するか、又は、第２イベントでＷＲＩＴＥ＿ＢＵＲＳＴ内にパッケージ化されたキーボードのためのＭＤＴ＿ＥＶＥＮＴの形式を示す（５１５）。

図５Ｄは、ブートプロトコルに準拠するか、又は、４ビットＨＩＤイベントをサポートして相対座標を使用するマウスのためのＭＤＴ＿ＥＶＥＮＴの形式を示す（５２０）。

図５Ｅは、ベンダー特定機能を要求するか、第２イベントでＷＲＩＴＥ＿ＢＵＲＳＴ内にパッケージ化されたマウスのためのＭＤＴ＿ＥＶＥＮＴの形式を示す（５５５）。

図５Ｆは、ゲームコントローラのためのＭＤＴ＿ＥＶＥＮＴの形式を示す（５６０）。

図５Ｇは、相対座標及びマルチタッチをサポートする他のカーソル駆動装置のためのＭＤＴ＿ＥＶＥＮＴの形式を示す（５６５）。

いくつかの実施形態において、メディアデータトンネルの送信機はまた、その未来のＷＲＩＴＥ＿ＢＵＲＳＴが単一カーソル駆動デバイスからのイベントのみ又はキーボードのイベントのみに限定されることを信号送信するため、「ＭＤＴＲＥＱｘｙ＿ＦＵＬＬ」の代わりに、「ＭＤＴＲＥＱｘｙ＿ＣＵＲＳＯＲ」又は「ＭＤＴＲＥＱｘｙ＿ＫＥＹＳ」を送信してもよい。メディアデータトンネルの送信機がＷＲＩＴＥ＿ＢＵＲＳＴにおいて「ＭＤＴＲＥＱｘｙ＿ＣＵＲＳＯＲ」を送信する場合、メディアデータトンネルの受信装置は、ｍｄｔ＿ｃｕｒｓｏｒ＿ｅｖｅｎｔ＿ｔ構造に限定されたｍｄｔ＿ｅｖｅｎｔコンテンツを有するＷＲＩＴＥ＿ＢＵＲＳＴペイロードを予期してもよい。メディアデータトンネルの送信機がＷＲＩＴＥ＿ＢＵＲＳＴにおいて「ＭＤＴＲＥＱｘｙ＿ＫＥＹＳ」を送信する場合、メディアデータトンネルの受信装置は、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔ＿ｔ構造に限定されたｍｄｔ＿ｅｖｅｎｔコンテンツを有するＷＲＩＴＥ＿ＢＵＲＳＴペイロードを予期してもよい。

いくつかの実施形態において、ＭＤＴ送信機は、ゲームコントローラをサポートするために、「ＭＤＴＲＥＱｘｙ＿ＦＵＬＬ」を送信しなければならない。共通ゲームコントローラは、種々の物理インタフェース、すなわち、指向性パッド、２つのアナログスティック、及び４つ以上のボタンからなる。このような物理入力及びＭＤＴイベント間のマッピングはコントローラ固有のものであることが多いが、コントローラは共通して、マウスイベント及びキーボードイベントに対してゲームコントローラをマッピングすることにより、ユーザ入力を中継する。指向性パッドは、イベントがキーボードから入力されたかのように、上下左右キーとＭＤＴキーボードイベントを生成するものである。

ゲームコントローラの実装において、０に設定されたｉｓＭｏｕｓｅＮｏｔを有するカーソルイベントはアナログスティックからデータを搬送し、一方でｍｄｔ＿ｅｖｅｎｔ＿ｈｅａｄｅｒ＿ｔ内のｉｓＰｏｒｔＢは右スティックと左スティックを区別するのに使用される。最後に、ボタンはカーソルイベント及びキー内でボタンフィールドに符号化されるが、各ボタン切替に対して単一の機構を使用してのみ送信される。さらにすべてのボタン切替は、ＵＳＢ ＨＵＴ１．１２及びＬｉｎｕｘ（登録商標）のｉｎｐｕｔ．ｈ．毎のキー切替にマップされてもよい。具体的には、Ｌｉｎｕｘ（登録商標）のｉｎｐｕｔ．ｈにより、０×１００がＢＴＮ＿０イベントを中継し、０×１０９がＢＴＮ＿９イベントを中継するように、０×１００〜０×１０９までの範囲内のキーコードを有する１０のボタンを提供する。同時に、最初の３つのボタンは、０に設定されたｉｓＰｏｒｔＢで送信されるカーソルイベント内の３ビットにマップし、次の３つのボタンは、１に設定されたｉｓＰｏｒｔＢで送信されるカーソルイベント内の３ビットにマップする。いくつかの実施形態において、送信機及び受信機における同時マッピングにより、ボタンイベントを指向性パッド又はアナログスティックからのイベントと対にする柔軟性を送信機に与え、受信機がイベントを適切に復号化するように保証し、システムの平均イベント遅延を短縮するようにしてもよい。

ＵＩシステムは通常、物理ＨＩＤデバイス間を区別せず、特定種別のすべてのイベントを同一キューに統合するため、メディアデータトンネルは、デバイスデータがゲームコントローラパケットの構造を用いて中継されない限り、ＨＩＤデバイス識別を保証しない。単一の周辺機器が同一のｉｓＰｏｒｔＢフィールド値に割り当てられた複数の論理マウスインタフェースを含む場合、メディアデータトンネルの受信機は、すべてのイベントを、ｉｓＰｏｒｔＢフィールドで識別されたソースに帰すると判断する。アプリケーションがソースの区別を必要とする場合、提示された物理周辺機器内の各論理マウスデバイスは、ｉｓＫｅｙｂｏａｒｄ＝０、ｉｓＮｏｔＭｏｕｓｅ＝１、ｉｓＧＡＭＥ＝１、及びデバイスＩＤフィールド内のＩＤを識別する固有のインタフェースを有するゲームコントローラパケット構造を使用して、ＨＩＤイベントを送信する必要がある。キーボード型デバイスと、ＩＤ情報の中継を必要とするかもしれないその他の予期しない周辺機器とに対して、メディアデータトンネルは、定義拡大のため、逆（ＲＳＶＤ）フィールドを提供する。メディアデータトンネルを通じてＨＩＤデータの送信を行う、本明細書に記載のディスカバリ機構は、ＨＩＤデータに限定されるものでない。この機構は、ＲＳ２３２、ＲＳ４８５及びその他の低帯域幅データのメディアデータトンネルを通じた交換を予期するのに使用されてもよい。一例として、メディアデータトンネルがＲＳ２３２データを搬送する場合、最初のディスカバリフェーズは、リンク接続特性、すなわち通信速度、開始ビットの使用、データビット数、パリティビットの使用、及び停止ビット数を識別するのに使用されてもよい。

ステージ２：データの符号化及び復号化。いくつかの実施形態において、メディアデータトンネルのピアは、メディアデータトンネルを介した送信のために、データを符号化及び復号化する。メディアデータトンネルの送信機は、データをスクラッチパッドに書き込むのに先立って符号化する。エンコーダは、任意のチェックサム拡張子を付与し、ヘッダプレフィックスを付与し、データを１４バイトパケットに分割する。受信側では、メディアデータトンネルの受信装置が、データをスクラッチパッドから読み出した後に復号化する。

ＭＨＬ仕様では、リンク層及びトランスレーション層における基本エラー検出で、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドを使用した送信を、ＷＲＩＴＥ＿ＢＵＲＳＴコマンド毎に１６データバイトに制限する。最大限１６データバイトとは別に、各ＷＲＩＴＥ＿ＢＵＲＳＴコマンドは、ＭＨＬ仕様により、受信装置のＡＤＯＰＴＥＲ＿ＩＤで開始される最小２データバイトを含むことが要求される。しかしながら、ＷＲＩＴＥ＿ＢＵＲＳＴの実際の長さは、コマンドに符号化されることなく、またこのデータバイトで搬送されることはない。ＭＨＬ仕様によると、受信装置は、最終データバイトに続くＥＯＦ（Ｅｎｄ Ｏｆ Ｆｉｌｅ）コントロールパケットを受信するまで、ＷＲＩＴＥ＿ＢＵＲＳＴを受信している間、バイトカウンタをインクリメントする。受信装置は、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドパケット及びＯｆｆｓｅｔデータパケットを受信後、そのカウンタを開始する。カウンタは、一旦開始すると、ＷＲＩＴＥ＿ＢＵＲＳＴデータバイトを搬送する各ＭＨＬデータパケットを追跡する。ＣＢＵＳを渡って送信されたすべてのパケットは、パケットの種別を問わず、２ヘッダビットと、１コントロールビットと、１パリティビットで、基本リンク層エラー検出を提供する。パケットが予期しないパリティデータ、コントロールデータ、又はヘッダデータで受信された場合、パケット受信装置は、そのＭＨＬリンク層論理の一部としてＮＡＣＫで応答する。ＭＨＬ仕様はまた、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドのためのトランスレーション層におけるエラー検出も提供している。受信装置は、そのトランスレーション層の検証、すなわち、ＯｆｆｓｅｔデータパケットにおけるＯｆｆｓｅｔ値の査定、受信したデータバイトのカウント、及び２バイトのＡＤＯＰＴＥＲ＿ＩＤの検査の結果を中継するため、ＡＣＫコントロールパケット又はＡＢＯＲＴコントロールパケットでＷＲＩＴＥ＿ＢＵＲＳＴに応答してもよい。

いくつかの実施形態において、ＭＨＬ仕様が基本エラー検出を提供するため、メディアデータトンネル固有のエラー検出は、１バイトのチェックサム拡張子を使用することによって任意に選択されてもよい。高度のエラー検出又はエラー補正が要求されるアプリケーションの場合、エンコーダは、ＷＲＩＴＥ＿ＢＵＲＳＴデータバイトを通じて適切なバイトのチェックサムを計算してもよい。いくつかの実施形態において、チェックサムアルゴリズムは、パリティ、モジュラーサム、ＣＲＣ（ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）、又はメディアデータトンネルエンコーダ及びメディアデータトンネルデコーダの一部として、トンネルの両側で使用される他のいかなるアルゴリズムであってもよい。いくつかの実施形態において、任意のチェックサムを通じて得られたエラー処理は、アプリケーション固有のものであってもよい。例えば、エラー処理は、チェックサム、事前規定された確認ロジックによって有効とされる再試行機構、又はさらなる消費を伴うことなく誤りデータを単に外すことによって許容される補正からなってもよい。実装に関わらず、メディアデータトンネルの送信機は、メディアデータトンネルディスカバリの間、パケットチェックサム拡張子と、チェックサムの方法とを含んだものを伝達する。

いくつかの実施形態において、メディアデータトンネルを通じてＨＩＤデータを送信する特別な実装には、チェックサムは使用されない。ユーザ入力のＨＩＤリポートがストリームとして見做されてもよい。稀なエラーの場合、ユーザは容易に入力を変更することができる。マウスレポートがメディアデータトンネルの受信機に到達しない場合、ユーザは、意図する情報を中継するためにマウスをさらに移動させる傾向にある。同様に、ユーザは、システムに認識されないキー押下を繰り返すか、又は、まず前回のエントリを消去した後、補正を送信することによって誤認されたキー押下を補正する傾向にある。

いくつかの実装において、メディアデータリンクのエンコーダは、強制的に２バイトからなるヘッダ等のヘッダを付与することが要求される。ＭＨＬ仕様では、ＷＲＩＴＥ＿ＢＵＲＳＴにおいてＯｆｆｓｅｔデータパケットに続く最初の２バイトが受信装置のＡＤＯＰＴＥＲ＿ＩＤを伝達することが要求される。ＡＤＯＰＴＥＲ＿ＩＤはＭＨＬ，ＬＬＣ．（ＭＨＬコンソーシアムの実施、ＭＨＬ仕様の採用、ライセンス供与、及び促進の責を負う組織）により割り当てられるため、ＷＲＩＴＥ＿ＢＵＲＳＴの最初の２バイトで可変の値を使用することはできない。ＭＨＬの要件に見合うようにするため、送信装置は、前述のとおり、ＭＨＬディスカバリの間にＡＤＯＰＴＥＲ＿ＩＤを検索し、続いてスクラッチパッドの最初の２バイトを初期化するためにこの値を使用する。

いくつかの実施形態において、メディアデータトンネルの送信装置は、遅延を短縮するために、一連のＷＲＩＴＥ＿ＢＵＲＳＴのために、スクラッチパッドのＡＤＯＰＴＥＲ＿ＩＤバイトのセットを一度のみ設定する。続く送信において、スクラッチパッドが到来したＷＲＩＴＥ＿ＢＵＲＳＴによって上書きされていなければ、メディアデータトンネルの送信装置がスクラッチパッドに書き込むバイト数は、２バイト少なくなる。

最初の２バイトに続いて、デコーダが同一のヘッダ定義を備えている場合に限り、ヘッダがメディアデータトンネル実装にユニークな方法で選択的に拡張されてもよい。ＭＨＬ採用者がファームウェアのアップグレード等、他の目的でメディアデータトンネルのためにＷＲＩＴＥ＿ＢＵＲＳＴコマンドを使用しようとする場合、ヘッダには、ＷＲＩＴＥ＿ＢＵＲＳＴをメディアデータトンネルと関連づける追加のビットが含まれてもよい。

前述のとおり、ｍｄｔ＿ｂｕｒｓｔ＿ｔを使用してＨＩＤマウスイベントデータ及びキーボードイベントデータを中継するために使用される実装において、ヘッダは、ｍｄｔ＿ｅｖｅｎｔ＿ｈｅａｄｅｒ＿ｔの４ビット構造である。いくつかの実施形態において、ＨＩＤと、その他の規定されていないメディアデータトンネルアプリケーションとのためにＷＲＩＴＥ＿ＢＵＲＳＴの多重を許容する際、ヘッダの最上位ビット（ＭＳｂ）はＨＩＤの使用を示している。ＭＳｂに続く３ビットが、ペイロードにおけるデータを特定する。ｉｓＰｏｒｔＢビットは、イベントの物理的発生源を識別し、ｍｄｔ＿ｅｖｅｎｔ＿ｈｅａｄｅｒ＿ｔは、ユニークなポートによって識別された２ＨＩＤデバイスまでをサポートする。ｉｓＫｅｙｂｏａｒｄビットは、ｍｄｔ＿ｅｖｅｎｔユニオンのコンテンツを識別する。ｉｓＫｅｙｂｏａｒｄが「１」である場合、ｍｄｔ＿ｅｖｅｎｔユニオンは、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔ＿ｔを表す。しかしながらｉｓＫｅｂｏａｒｄが「０」である場合、ｍｄｔ＿ｅｖｅｎｔユニオンは、ｍｄｔ＿ｍｏｕｓｅ＿ｅｖｅｎｔ＿ｔを表す。ｉｓＮｏｔＬａｓｔビットは、マルチタッチアプリケーションや、より高いイベントレートでのサポートを命じるその他のアプリケーションのために、単一のＷＲＩＴＥ＿ＢＵＲＳＴ内において複数のＨＩＤイベントの多重化を許容する。ｉｓＮｏｔＬａｓｔが０に設定された場合、このビットは、トランスレーション又は最適化を通じて適合させられた、遅延最適化キーボードパケット構造及び遅延最適化マウスパケット構造も識別する。ｉｓＮｏｔＬａｓｔが１に設定された場合、受信機は、ＷＲＩＴＥ＿ＢＵＲＳＴ内の第２イベントの存在に関し、スクラッチパッドのオフセットの９バイトを調べるであろう。送信機が２つのイベントを単一のＷＲＩＴＥ＿ＢＵＲＳＴ内に統合することを意図しないものの、その主要イベントのために適合化パケットを使用する代わりに７バイトのフルペイロードを要求する場合、送信機は、ＭＤＴ受信機が確実にスクラッチパッドバイト９〜１６を無視するように、スクラッチパッドのオフセット９〜０においてＭＳｂを設定する。

ＭＨＬ仕様では、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドを使用した送信が１６データバイトに制限されるが、強制的ＡＤＯＰＴＥＲ＿ＩＤにより、許容されるペイロードが低減される。送信機におけるあらゆるＷＲＩＴＥ＿ＢＵＲＳＴのためのエンコーダは、送信するデータを、１４データバイト以下のペイロードに分割する。

いくつかの実施形態において、メディアデータトンネルの送信機におけるエンコーダは、ＡＤＯＰＴＥＲ＿ＩＤのオーバーヘッドに加え、メディアデータトンネルのヘッダを構成するよう要求される。追加のヘッダビット又はヘッダバイトにより、可能なＷＲＩＴＥ＿ＢＵＲＳＴペイロードのサイズをさらに低減する。複数のＷＲＩＴＥ＿ＢＵＲＳＴを使用して伝達されたパケットをサポートすることは可能であるが、低データレートにより、メディアデータトンネルの実装におけるこの特徴の意義をなくしてしまう。

メディアデータトンネルを通じたＨＩＤ送信のため、４ビットのヘッダが各パケットの第１ニブルを多重定義する。前述の構造に示したとおり、４ビットヘッダを許容するため、マウスイベント及びキーボードイベントが変更される。

いくつかの実施形態において、メディアデータトンネルを通じたＨＩＤ送信に加え、次のパケット構造が使用されてもよい。一例として、＿ｉｍｐｌｅｍｅｎｔａｔｉｏｎ＿ｓｐｅｃｉｆｉｃユニオンは、拡張ヘッダ及びデータからなるデータ、チェックサムバイトを有するデータ、拡張ヘッダ及びチェックサムを有するデータのために、ＷＲＩＴＥ＿ＢＵＲＳＴにおける残りのデータバイトすべての１４データバイトを使用する。拡張ヘッダにより、メディアデータトンネル実装のさらなる柔軟性を許容する。図６は、メディアデータトンネルの実装における拡張ヘッダのパケット構造の一実施形態を示している。同図は、拡張ヘッダの３例を示している。

＿ｅｘｈｅａｄｅｒ＿ｗｉｔｈ＿ｃｄｂは、ｉｓＨＩＤ ｍｄｔ＿ｅｖｅｎｔ＿ｈｅａｄｅｒ＿ｔのように、準備の整ったメディアデータトンネルとしてＷＲＩＴＥ＿ＢＵＲＳＴの目的を識別するフィールド備えた拡張ヘッダを示している。

＿ｅｘｈｅａｄｅｒ＿ｗｉｔｈ＿ｃｄｂ＿ｃｈｋｓｍは、チェックサムの選択的使用を許容するものである。

＿ｅｘｈｅａｄｅｒ＿ｗｉｔｈ＿ｃｄｂ＿ｃｈｋｓｍ＿ｌｅｎは、４ビット長のフィールドを使用するＷＲＩＴＥ＿ＢＵＲＳＴにおいてパッケージ化されたバイト数も伝達するために、前述のｅｘｈｅａｄｅｒ＿ｗｉｔｈ＿ｃｄｂ＿ｃｈｋｓｍを拡張したヘッダ拡張子を示している。

いくつかの実施形態において、メディアデータトンネルは、送信前のデータをバッファリングし、消費前の受信データを保持するに際し、ＭＨＬ仕様のスクラッチパッドレジスタに依存している。ＭＨＬ仕様は、シンク、ソース、又はドングル内において、任意のスクラッチパッドを規定している。スクラッチパッドは、１６個以上で１セットの１バイトレジスタである。これらのレジスタは、０×４０のオフセットでアクセス可能である。本セットの最初の２バイトは、デバイスのＡＤＯＰＴＥＲ＿ＩＤを含むことが要求される。送信に先立ち、ＭＨＬ送信機又はＭＨＬ受信機のユーザは、スクラッチパッドにデータを書き込む。データを受信する場合、ＭＨＬ送信機又はＭＨＬ受信機は、後にユーザがデータを検索できるように、データをこの領域に宛てる。

いくつかの実施形態において、スクラッチパッドのアクセスに関して、メディアデータトンネルは、データ転送を促進するために追加のガイダンスを提供するものの、ＭＨＬ仕様に依存する。いくつかの実施形態において、ＭＨＬ送信機又はＭＨＬ受信機が、送信されるスクラッチパッドのバイト数をユーザが特定することを要求する場合、メディアデータトンネルの送信機は、この数が変わるときに限り、送信されるスクラッチパッドのバイト数を示すようにしてもよい。メディアデータトンネルのセッションが７バイト構造を有する複数のＷＲＩＴＥ＿ＢＵＲＳＴからなる場合、メディアデータトンネルの送信機は、遅延をさらに短縮するために、バースト長を一度のみ設定しなければならない。初期化の間、パケット長が分かる前に、メディアデータトンネルの送信機は、長さを、最小の場合のペイロード構造の合計バイト数に設定しなければならない。つまりｍｄｔ＿ｂｕｒｓｔ＿０１＿ｔに関して、この値は、後述のとおり、２バイトのＡＤＯＰＴＥＲ＿ＩＤと、０に切り詰められた４バイトのｍｄｔ＿ｍｏｕｓｅ＿ｅｖｅｍｔ＿ｔ又は４バイトのｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔ＿ｔを許容するべく、６となるであろう。

一方、いくつかの実施形態において、メディアデータトンネルの受信装置は送信機を特定するために、スクラッチパッドの最初の２バイトを読み取らない。メディアデータトンネルは、拡張ディスカバリの間、ハンドシェイクを要求し、各パケットにはｉｓＨＩＤ識別ビットがそのヘッダ内に含まれているため、ＡＤＯＰＴＥＲ＿ＩＤを使用した後続の特定は冗長であり、避けられてもよい。遅延をさらに短縮するために、メディアデータトンネルの受信装置は、受信したＷＲＩＴＥ＿ＢＵＲＳＴデータのヘッダにアクセスするための、最小の場合のペイロード構造の合計バイト数を検索する。ＷＲＩＴＥ＿ＢＵＲＳＴのコンテンツが第１のアクセスの長さを超過する旨をヘッダが示している場合、メディアデータトンネルの受信装置は、個別の第２の試行においてスクラッチパッドから残りのバイトを読み取ってもよい。

いくつかの実施形態において、ＨＩＤデータの中継に使用されるメディアデータトンネルの実装に関して、メディアデータトンネルの送信機は、メディアデータトンネルの受信装置に対してｍｄｔ＿ｂｕｒｓｔ＿０１＿ｔのインスタンスを中継する。拡張ディスカバリに引き続き、第１のＨＩＤイベントに先立って、メディアデータトンネルの送信機は、送信されるスクラッチパッドのバイト数を６に設定するが、この構造はマウスイベントを中継する場合に最小のサイズとなる。この第１送信に先立ち、メディアデータトンネルの送信機は、スクラッチパッドの最初の２バイトをメディアデータトンネル受信装置用のＡＤＯＰＴＥＲ＿ＩＤに設定する。メディアデータトンネルの送信機は、送信対象のＨＩＤイベントデータを一旦保持すると、送信されるスクラッチパッドのバイト数を更新してスクラッチパッドのバイト［２：１５］にイベントデータを投入する必要性について検討する。

受信側において、メディアデータトンネルの受信機は、そのスクラッチパッドのバイト０及び１を無視する。メディアデータトンネルの受信装置は、代わりに、ｍｄｔ＿ｂｕｒｓｔ＿０１＿ｔ内に少なくとも４バイトのマウスイベントを受信するという前提の下で、スクラッチパッドのバイト［２：５］を読み取ることにより、イベントを消費する。読み取ったｉｓＫｅｙｂｏａｒｄビットフィールドが１にアサートされた場合、メディアデータトンネルの送信機は、７バイトのキーボードパケットの残りの３バイトを検索するために、スクラッチパッドのバイト［６：８］へアクセスすべく、２回目の読取を実施する。メディアデータトンネルの送信機もまた、ｉｓＣｏｏｒｄｉｎａｔｅＷｏｒｄＬｅｎｇｔｈがｍｄｔ＿ｍｏｕｓｅ＿ｅｖｅｎｔ＿ｔ内に設定された場合、２回目の読取を実施する。ｉｓＣｏｏｒｄｉｎａｔｅＷｏｒｄＬｅｎｇｔｈが設定されている２番目のケースについて、受信装置は、ＷＲＩＴＥ＿ＢＵＲＳＴの送信機が絶対座標マッピングにおいて可能なワード長の座標を送信しているため、スクラッチパッドデータの検索時に７バイト読取に切り替える。

いくつかの実施形態において、エンコーダは、データの量及び位置の制御に加え、ｍｄｔ＿ｍｏｕｓｅ＿ｅｖｅｎｔ＿ｔ及びｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔ＿ｔのインスタンスを生成することにより、メディアデータトンネル送信のためのＨＩＤコンテンツを最適化する。これらの構造は、ＨＩＤデバイスによって作成されたデータペイロードと合致するように、ヒューマンインタフェースデバイスのためのデバイスクラス規定（ＤＣＤＨＩＤ）仕様バージョン１．１１に準拠していてもよい。メディアデータトンネルのための最適化又は適合化として、ｍｄｔ＿ｍｏｕｓｅ＿ｅｖｅｎｔ＿ｔは、ＨＩＤ仕様ビットからメディアデータトンネルＨＩＤヘッダまでのバイト０において、ビット４〜７を再割当する。また、バイト３は、既存の事実上の標準マウスドライバの実装に基づいてスクロールホイールを搬送するものとする。さらに、より低遅延の送信とのトレードオフとして高解像度ディスプレイ上の絶対座標追跡をサポートするために、ｉｓＣｏｏｒｄｉｎａｔｅＷｏｒｄＬｅｎｇｔｈが設定されている場合、ｍｄｔ＿ｍｏｕｓｅ＿ｅｖｅｎｔ＿ｔはワード長座標を提供する。

いくつかの実施形態において、キーボードイベントもまた最適化される。メディアデータトンネルのための最適化又は適合化として、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔ＿ｔは、ＲＩＧＨＴ ＣＴＲＬビット、ＲＩＧＨＴ ＳＨＩＦＴビット、ＲＩＧＨＴ ＡＬＴビット、＆ＲＩＧＨＴ ＧＵＩビットからメディアデータトンネルのＨＩＤヘッダビットまでのＤＣＤＨＩＤにおいて規定されたキーボードＨＩＤイベントのバイト０に、ビット４〜７を再割当する。これらのビットを落とすのに先立ち、メディアデータトンネルの送信機のメディアデータトンネルエンコーダがバイト０のビット４〜７及びビット０〜３の間にＯＲ動作を実施する。このＯＲ動作は、さもなければバイト０に記憶されていたＬＥＦＴキー及びＲＩＧＨＴキーの双方のアサートを実施するために、ＬＥＦＴ ＣＴＲＬビット、ＬＥＦＴ ＳＨＩＦＴビット、ＬＥＦＴ ＡＬＴビット、＆ＬＥＦＴ ＧＵＩビットを使用するであろう。さらに、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔは、ＤＣＤＨＩＤ仕様によって規定されたブートプロトコル１パケットのＯＥＭ使用を対象としたバイト１を落とす。メディアデータトンネルの送信機内のエンコーダは、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔに８バイト長を強要するためにこのバイトをそのままの位置に残す代わりに、７バイトのｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔを初期化するに際し、反転プレースホルダーを落とすため、バイト［２：７］を１バイト分シフトさせる。メディアデータトンネルの送信機内のエンコーダは、さらなる最適化として、ブートプロトコル１の共用に基づき、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔの最上位バイトによって保持された一連の０のうち１つを除くすべての０を落としてもよい。

キーボード入力レポートの多くについて、キーボード更新は、単一のキーにおける変化を反映させる。この変化は、ブートプロトコル１レポートのバイト２と、ｍｄｔ＿ｋｅｙｂｏａｒｄ＿ｅｖｅｎｔのバイト１において獲得される。このような場合、キーボードは、０でこのイベントの残りのバイトを埋める。エンコーダは、遅延を短縮するために、末尾３つの０を落とし得る。キーボードのＬＥＤ状態の管理は、メディアデータトンネルの受信機から行われることを期待するより、むしろメディアデータトンネルの送信機がこの動作を行う。ヒューマンインタフェースデバイス（ＨＩＤ）のためのデバイスクラス規定仕様１．１１によると、キーボードのＬＥＤ状態は、キーボードよりもむしろホストによって維持されなければならず、キーボードのホストにＬＥＤステータスの管理を行わせると述べている。ＨＩＤのためのメディアデータトンネルの実装において、この機能をメディアデータトンネルの受信機をサポートするホスト内に実装することは可能であるが、ＬＥＤ制御をメディアデータトンネルの送信機に残すことにより、双方向ＷＲＩＴＥ＿ＢＵＲＳＴの必要性を低減する。ＭＨＬ送信機内のメディアデータトンネル受信機は、メディアデータトンネルの送信機においてＬＥＤ制御を行うことにより、いかなる場合もメディアデータトンネルの送信機である必要はなくなり、拡張ディスカバリの間、ＷＲＩＴＥ＿ＢＵＲＳＴ送信をサポートするだけでよい。このようなＨＩＤデータに関し、図７は、標準ＨＩＤ構造との比較において、 一実施形態に係るメディアデータトンネルエンコーダのペイロード構造を示している。

ステージ３：データ中継。いくつかの実施形態において、ＭＨＬ送信機及び送信機は、メディアデータトンネルの送信機からメディアデータトンネルの受信機へとデータを中継するために、ＭＨＬ仕様のＷＲＩＴＥ＿ＢＵＲＳＴコマンド及びＳＥＴ＿ＩＮＴコマンドを実装するよう指示される。前述のスクラッチパッドに加え、メディアデータトンネルは、ＭＨＬ送信機とＭＨＬ受信機との間でデータを中継するに際し、ＭＨＬ仕様割込レジスタ、ＷＲＩＴＥ＿ＢＵＲＳＴコマンド、及びＳＥＴ＿ＩＮＴコマンドに依存している。ＭＨＬ仕様によると、ＭＨＬ送信機及びＭＨＬ受信機は、２つの１バイト割込レジスタを提供する。割込レジスタは、オフセット０×２０にある。これらのレジスタにより、ユーザは、ＳＥＴ＿ＩＮＴコマンドを使用した送信に対する割込を特定することができる。

いくつかの実施形態において、ユーザとＭＨＬ送信機又はＭＨＬ受信機の状態機械との間のスクラッチパッドアクセスの衝突を避けるため、ＭＨＬ仕様では、割込レジスタ及び調整プロセスを提供する。調整プロセスでは、ＳＥＴ＿ＩＮＴコマンドを使用したスクラッチパッドアクセスの管理方法を提供する。この仕様によると、ユーザは、ローカルスクラッチパッドにデータを書き込むのに先立ち、ＷＲＩＴＥ＿ＢＵＲＳＴ送信が未処理でないことを確かめるためにチェックを行う。ＷＲＩＴＥ＿ＢＵＲＳＴ送信機が、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドを送信したのにも関わらず、ＳＥＴ＿ＩＮＴコマンドを用いてＤＳＣＲ＿ＣＨＧ割込まで送信しなければならない場合、ＷＲＩＴＥ＿ＢＵＲＳＴ送信は未処理である。この仕様はまた、スクラッチパッドアクセスにＷＲＩＴＥ＿ＢＵＲＳＴの受信が認められていた場合、ユーザはスクラッチパッドへの書込みを行わないことを示している。ＷＲＩＴＥ＿ＢＵＲＳＴ受信装置がＳＥＴ＿ＩＮＴコマンドを使用してＧＲＴ＿ＷＲＴ割込を送信したものの、応答としてＳＥＴ＿ＩＮＴコマンドを介してＤＳＣＲ＿ＣＨＧ割込を未受信である場合、受信は未解決の状態である。またＭＨＬ仕様によると、ユーザは、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドの送信準備中である場合、又は、先のＷＲＩＴＥ＿ＢＵＲＳＴコマンドの受信を依然として処理中である場合、ＳＥＴ＿ＩＮＴコマンドを用いたＧＲＴ＿ＷＲＴの送信を通じたＷＲＩＴＥ＿ＢＵＲＳＴの受信を許容しない。

いくつかの実施形態において、メディアデータトンネルは、必要な性能にＨＩＤや、これよりやや要求の多いアプリエーションをサポートさせる一方で、ＭＨＬ仕様に全面的に準拠して実装されるものである。メディアデータトンネルの送信機及び受信装置は、ＭＨＬに全面的に準拠して、ＭＨＬ仕様に規定されるようにスクラッチパッド及び割込レジスタにアクセスする。同様に、メディアデータトンネルの送信装置及び受信機は、ＳＥＴ＿ＩＮＴコマンド及びＷＲＩＴＥ＿ＢＵＲＳＴコマンドを使用し、ＭＨＬ使用に準拠してデータの中継を行う。

いくつかの実施形態において、メディアデータトンネルは、追加のメディアデータトンネル仕様ガイダンスを伴う、ＷＲＩＴＥ＿ＢＵＲＳＴコマンドのためのＭＨＬ仕様調整シーケンスに依存している。送信機は、ＷＲＩＴＥ＿ＢＵＲＳＴデータの中継が必要となるのに先立ち、ＲＥＱ＿ＷＲＴ及びＤＳＣＲ＿ＣＨＧを有する単一のＳＥＴ＿ＩＮＴを送信する。この事前要求により、送信機から２つの方法で負荷を低減する。第１に、ＷＲＩＴＥ＿ＢＵＲＳＴ送信機は、データ送信が必要な場合、ＲＥＱ＿ＷＲＴの送信時間の影響を受けない。ＲＥＱ＿ＷＲＴは、事前に送られている。第２に、ＲＥＱ＿ＷＲＴ要求に対するＧＲＴ＿ＷＲＴ応答を待機する必要はない。このトランザクションはＭＨＬ仕様により、１０ミリ秒程度となることもある。実際には、ＳＥＴ＿ＩＮＴの事前送信により、ＷＲＩＴＥ＿ＢＵＲＳＴコマンド内でメディアデータトンネル情報を中継するのに要する時間から、ＷＲＩＴＥ＿ＢＵＲＳＴ調整に消費する時間を分離する。またメディアデータトンネルの送信機は、これらの割込を独立的に、且つ、ＷＲＩＴＥ＿ＢＵＲＳＴトランザクションの異なるステージで送信する代わりに、単一のＳＥＴ＿ＩＮＴを使用してＤＳＣＲ＿ＣＨＧ割込及びＲＥＱ＿ＷＲＴ割込を中継してもよい。単一のＳＥＴ＿ＩＮＴメッセージ内へのＤＳＣＲ＿ＣＨＧ及びＲＥＱ＿ＷＲＴのペア化により、ＷＲＩＴＥ＿ＢＵＲＳＴを使用したデータ中継に要する時間をさらに短縮してもよい。

いくつかの実施形態において、メディアデータトンネルの受信装置は、ＲＥＱ＿ＷＲＴ割込及びＤＳＣＲ＿ＣＨＧ割込を組み合わせた事前送信を担うことにより、未受信の保留中ＷＲＩＴＥ＿ＢＵＲＳＴを途中停止する機会を得る。ＭＨＬ仕様ではＷＲＩＴＥ＿ＢＵＲＳＴの受信者にＷＲＩＴＥ＿ＢＵＲＳＴを受信しない方法を提供しないものの、この仕様は、受信装置によるＡＣＫ又はＡＢＯＲＴの返信を命じることにより、ＳＥＴ＿ＩＮＴコマンドが随時処理されることを黙示的に保証している。メディアデータトンネルの受信装置は、この黙示的な保証を使用し、保留中のＷＲＩＴＥ＿ＢＵＲＳＴを途中停止する必要がある場合には、ＳＥＴ＿ＩＮＴコマンドを使用してＲＥＱ＿ＷＲＴ割込を送信する。ＭＨＬへの準拠を維持するには、メディアデータトンネルの送信機は、ＡＣＫでこのＳＥＴ＿ＩＮＴコマンドに応答し、受容される場合には、ＳＥＴ＿ＩＮＴコマンドを使用して別個にＤＳＣＲ＿ＣＨＧ割込を送信する。メディアデータトンネルの送信機がＤＳＣＲ＿ＣＨＧの送信に失敗した場合、メディアデータトンネルの受信装置は、１０ミリ秒毎にＲＥＱ＿ＷＲＴを繰り返してもよく、ＷＲＩＴＥ＿ＢＵＲＳＴの受信装置がＲＥＱ＿ＷＲＴに対するＧＲＴ＿ＷＲＴ応答を待機するために、タイムアウトがＭＨＬによって特定される。ＷＲＩＴＥ＿ＢＵＲＳＴの受信装置がＷＲＩＴＥ＿ＢＵＲＳＴの受信中、停止を中継する必要がある場合、受信装置は、ＡＣＴでＷＲＩＴＥ＿ＢＵＲＳＴに応答し、続いてＲＥＱ＿ＷＲＴを伝達するためにＳＥＴ＿ＩＮＴを送信する。

いくつかの実施形態において、メディアデータトンネルのＨＩＤ実装に関して、ＷＲＩＴＥ＿ＢＵＲＳＴ及びＳＥＴ＿ＩＮＴを使用したデータ転送は、メディアデータトンネル規定に準拠する。有力なシーケンスは、拡張ディスカバリを反映する。このディスカバリ内において、メディアデータトンネルの送信機は、ＭＤＴＲＥＱ０１＿ＦＵＬＬトークンを送信し、応答としてＭＤＴＡＣＫ＿２０００を受信する。この交換により、メディアデータトンネルの送信機及び受信機間で合意が成立する。またこの交換により、メディアデータトンネルの送信機は、メディアデータトンネルを通じたＨＩＤサービスについてメディアデータトンネルの受信機を認定することができる。いくつかの実施形態において、拡張ディスカバリのためのコマンドは、表１に示すとおりである。

いくつかの実施形態において、メディアデータトンネルの送信機は、拡張ディスカバリに引き続き、スクラッチパッドにＡＤＰＯＴＥＲ＿ＩＤを設定する。例示のため、メディアデータトンネルの受信装置のＡＤＯＰＴＥＲ＿ＩＤを０×００００とする。次に、メディアデータトンネルの送信機は、マウスイベントのインスタンスとして最小の場合のｍｄｔ＿ｂｕｒｓｔ＿ｔパケット構造をサポートするために、バースト長を６に設定する。その後、ＨＩＤイベントは、関連の割込とＳＥＴ＿ＩＮＴコマンドの送信とともに、別個のＷＲＩＴＥ＿ＢＵＲＳＴコマンドとして送信されてもよい。各イベントが同一のパケット構造を有しているため、バースト長は再度設定されることはない。いくつかの実施形態において、ＭＤＴ送信装置のＨＩＤイベント送信は、以下の表２に示すとおりであってもよい。

ステージ４及び５：データ復号化及びデータ消費。いくつかの実施形態において、メディアデータトンネル送信は、メディアデータトンネルの受信機が、受信したデータを符号化して消費することにより、完結される。復号化の定義は、ステージ２に提供した。消費はアプリケーションに依存するものであり、以下の定義が最適であり、一例として述べる。

図８は、一実施形態に係るメディアデータトンネルの層を示している。図示の積層は、ＨＩＤイベントの受信を目的とするＭＨＬ送信機の実現可能な実装を、Ｌｉｎｕｘ（登録商標）システム又はＡｎｄｒｏｉｄシステム内のＵＳＢドライバ層と比較している。いくつかの実施形態において、図８の要素は、モバイルデバイス内のＭＨＬ送信機のためのソフトウェア実装を示している。メディアデータトンネル実装のＭＤＴ ＨＩＤ層、ＨＩＤ／ＭＤＴドライバ層、Ｓｉｌ９２３４ドライバ層、及びＳＭＢＵＳ層又はＩ２Ｃドライバ層は、ＵＳＢドライバ層、ＵＳＢ ＨＩＤ層、ＵＳＢ Ｃｏｒｅ層、ＯＨＣＩ／ＥＨＣＩ層に直接位置している。ＷＲＩＴＥ＿ＢＵＲＳＴを担うＭＨＬ送信機要素は、ＨＵＢサポート及びデバイスディスカバリを担うＵＳＢ ＣＯＲＥ層に比して非常に薄い。同様に、ＨＩＤ／ＭＤＴデコーダも極めて薄い層である。しかしながら、メディアデータトンネルのＨＩＤドライバは、主な違いとしてエントリポイントを備えているＵＳＢドライバに互換性がある。ＵＳＢドライバは、ＵＳＢパケットからペイロードを受信するためにＵＳＢスタックに登録する一方、メディアデータトンネルのＨＩＤドライバは、ＨＩＤ／ＭＤＴデコーダによって直接呼び出すことができ、ペイロードを受信する際、グローバルバッファに依存することができる。この差異にも関わらず、ＵＳＢドライバ及びメディアデータトンネルのＨＩＤドライバは双方ともに、イベントをユーザスペースまで中継するため、ｉｎｐｕｔ＿ｒｅｐｏｒｔ型機能を使用してＨＩＤ ＥＶＥＮＴ ＧＥＮＥＲＡＴＯＲを呼び出す。この実装におけるデコーダによって提供されるトランスレーションにより、標準ＨＩＤイベント消費者は、イベントがＵＳＢデバイスから到来するかのようにイベントをメディアデータトンネルから受信することができるようになる。

メディアデータトンネルは、ＭＨＬによって提供される値及び特徴を拡張する手段を提供する。図９は、ＨＤＭＩ対応ビデオディスプレイ及びＨＤＭＩ対応ソースデバイス間の接続を示している。同図において、ＨＤＭＩシンク９１０（テレビジョン又はその他のビデオディスプレイ等）は、ＨＤＭＩインタフェース接続９５０を介してビデオソース９６０に連結されている。図９に示すとおり、ＨＭＩシンク９１０は、ＨＤＭＩ受信機９１２を備えており、これは処理要素９２０（ＣＰＵ、マイクロプロセッサ、又はＳｏＣ等）に連結されてもよい。ビデオソース９６０は、処理要素９６５に連結されたＨＤＭＩ送信機９６２を備えている。

この状況において、データバスは、個別に動作する。Ａ／Ｖ以外の周辺機機器のデータを中継するため、ビデオソース９１０は、データバス９５５を介してＵＳＢ要素９１５に連結されてもよい。ここでＵＳＢ要素は、パーソナルコンピュータ（ＵＳＢホストとして振舞う）又はデータ周辺機器（ＵＳＢデバイスとして振舞う）であってもよい。したがって、ソースデバイス９６０は、第１プロトコル（ＨＤＭＩ）のデータ送信と、第２プロトコル（ＵＳＢ）のデータ送信とを双方ともに備えており、このような送信では、２つのプロトコルの帯域幅の取扱いに、別個のデータチャンネル９５０及び９５５を利用する。

ＨＤＭＩとは異なり、ＭＨＬ仕様は、複数のプロトコル間の物理コネクタを共有するアプリケーションを対象としているが、これらのプロトコルは、同時というよりむしろ、互いに対して排他的にサポートされる。図１０は、ＨＤＭＩ／ＭＨＬドングル及びＭＨＬ対応ビデオソースデバイス間の接続を示している。図１０及び１１は、互いに排他的に送信されるＨＩＤデータ及びＭＨＬデータ間で、モバイルデバイスの５ピンコネクタを共有する実装を示している。図１０において、ＨＤＭＩ形式１００５とＭＨＬ形式との間でデータを変換するＭＨＬドングル１０１０が、ＭＨＬ／ＵＳＢインタフェース接続１０５０を介して、ビデオソース１０６０に連結されている。ビデオソース１０６０には、モバイルデバイスが含まれてもよい。図１０に示すとおり、ＭＨＬドングル１０１０は、ＣＰＵ、マイクロプロセッサ、ＳｏＣ等の処理要素１０２０を備えてもよい。ビデオソース１０６０は、処理要素１０６５に連結されたＭＨＬ送信機１０６２を備える。

ビデオソースは、５ピンコネクタ１０７０と、ＭＨＬ及びＵＳＢのインタフェース１０５０のためのスイッチ１０７２を備える。スイッチは、ＭＨＬデータのためのコネクタからＭＨＬ受信機１０６２への経路と、ＵＳＢデータのためのコネクタからＵＳＢリンク１０５５を介してビデオソースの処理要素１０６５までの経路とを提供する。ＭＨＬ ＵＳＢは、ＵＳＢデータの転送を行うため、個別のデータ周辺機器１０１５に接続されてもよい。したがって、この場合、ソースデバイス１０６０は、単一の５ピンコネクタを利用した第１プロトコル（ＭＨＬ）のデータ送信と第２プロトコル（ＵＳＢ）のデータ送信との双方を含むが、このようなコネクタは、ＭＨＬ及びＵＳＢの双方がインタフェースの全帯域幅を利用するため、一度に転送できるのはこのようなプロトコルのうちの１つのみとなる。２つのプロトコル間の排他性は、ＭＨＬ受信機がＭＨＬドングル又はＭＨＬシンクである場合、ＭＨＬ仕様に適用する。図１１は、ＭＨＬ対応ビデオシンクデバイス及びＭＨＬ対応ビデオソースデバイス間の接続を示している。同図において、ＭＨＬ対応ビデオシンク１１１０は、ＭＨＬ／ＵＳＢインタフェース接続１１５０を介してビデオソース１１６０に連結される。ビデオソース１１６０には、モバイルデバイスが含まれてもよい。図１１に示すとおり、ＭＨＬシンク１１１０は、ＭＨＬ送信機１１１２と、処理要素１１２０とを備えてもよい。ビデオソース１１６０は、処理要素１１６５に連結されたＭＨＬ送信機１１６２を備えてもよい。

図１１において、ビデオソース１１６０は、５ピンコネクタ１１７０と、ＭＨＬ及びＵＳＢのインタフェース１１５０のためのスイッチ１１７２とを備える。スイッチは、ＭＨＬ受信機１１６２までのＭＨＬデータの経路と、ＵＳＢリンク１１５５を介してビデオソースの処理要素１１６５までのＵＳＢデータの経路とを提供する。ＭＨＬ ＵＳＢは、ＵＳＢデータの転送を行うため、データ周辺機器１１１５と接続されてもよい。図１０と同様に、この場合、ソースデバイス１１６０は、単一の５ピンコネクタを使用する第１プロトコル（ＭＨＬ）のデータ送信及び第２プロトコル（ＵＳＢ）のデータ送信との双方を含むが、このようなコネクタは、ＭＨＬとＵＳＢとの双方がインタフェースの全帯域幅を利用するため、一度に転送できるのはこのようなプロトコルのうちの１つのみとなる。

メディアデータトンネルによってＭＨＬを強化し、Ａ／Ｖデータ送信及び周辺機器データ送信を同時に行うためのデータトンネリングを行わせる。図１２は、ＨＤＭＩ／ＭＨＬドングル及びＭＨＬ対応ビデオソースデバイス間の接続の一実施形態を示している。図１０及び図１１とは対照的に、図１２及び図１３は、２つのピア間でＨＩＤデータ及びＭＨＬデータを同時に交換するメディアデータトンネル対応システムを示している。図１２において、ＨＤＭＩ形式１２０５とＭＨＬ形式との間のデータ変換を行うＭＨＬドングル１２１０が、ＭＨＬインタフェース接続１２５０を介してビデオソース１２６０に連結されている。ここでビデオソース１２６０には、モバイルデバイスが含まれてもよい。図１２に示すとおり、ＭＨＬドングル１２１０は、処理要素１２２０を備えてもよい。ビデオソース１２６０は、処理要素１２６５に連結されたＭＨＬ送信機１２６２を備える。

いくつかの実施形態において、ＭＨＬドングル１２１０及びビデオソース１２６０間のインタフェース１２５０は、データトンネル１２５２を備え、このデータトンネルは上述のとおり、メディアデータトンネルであってもよい。いくつかの実施形態において、データトンネル１２５２は、第１プロトコル（ＭＨＬ）の一般コマンドを介して、第２プロトコル（ＵＳＢ）のデータを送信するのに利用されてもよい。図示のとおり、ＭＨＬドングル１２１０の処理要素１２２０は、データバス１２５５を介して、ＵＳＢデータ転送用のデータ周辺機器１２０７に連結されもよい。したがって、この実装においてビデオソース１２６０はＵＳＢホスト要素として動作してもよく、いくつかの実施形態において、ＵＳＢデータは、データトンネル１２５２を介して、このようなＵＳＢホストと、データ周辺機器１２０７等のＵＳＢデバイス要素との間で転送されることで、ＭＨＬデータとＵＳＢデータとの同時転送を可能とする。

ＭＨＬ受信機がＭＨＬドングル又はＭＨＬシンクである場合、メディアデータトンネルの恩恵が同等に得られる。図１３は、ＭＨＬ対応ビデオシンクデバイス及びＭＨＬ対応ビデオソースデバイス間の接続を示している。同図において、ＭＨＬ対応ビデオシンクデバイス１３１０は、ＭＨＬインタフェース接続１３５０を介してビデオソース１３６０に連結されている。ビデオソース１３６０には、モバイルデバイスが含まれてもよい。図１３に示すとおり、ＭＨＬシンク１３１０は、処理要素１３２０を備えてもよい。ビデオソース１３６０は、処理要素１３６５に連結されたＭＨＬ送信機１３６２を備える。

いくつかの実施形態において、ＭＨＬシンクデバイス１３１０及びビデオソース１３６０間のインタフェース１３５０は、データトンネル１３５２を備え、このデータトンネルは上述のとおり、メディアデータトンネルであってもよい。いくつかの実施形態において、データトンネル１３５２は、第１プロトコル（ＭＨＬ）の一般コマンドを介して、第２プロトコル（ＵＳＢ）データの送信を行うために利用されてもよい。図示のとおり、ＭＨＬシンクデバイス１３１０の処理要素１３２０は、データバス１３５５を介してＵＳＢデータ転送用のデータ周辺機器１３０７に連結されてもよい。したがって、いくつかの実施形態において、ビデオソース１３６０は、ＵＳＢホスト要素として動作してもよく、ＵＳＢデータは、データトンネル１３５２を介して、このようなＵＳＢホストと、データ周辺機器１３０７等のＵＳＢデバイス要素との間で転送されることにより、ＭＨＬデータとＵＳＢデータとの同時転送を可能とする。

メディアデータトンネルにより、ＭＨＬ対応モバイルデバイスに、演算の使用例においてより高度にサービスを提供させる。メディアデータトンネル対応ＭＨＬがない場合、モバイルデバイスは、データ周辺機器のホストとなってもよいが、通常、Ａ／Ｖデータの送信に別のポートを必要とする。図１４は、マウス等のデータ周辺機器を備えたモバイルデバイスのＵＳＢリンクを示している。同図において、ビデオソース１４１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、マイクロプロセッサ、又はＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）として示された処理要素１４１５を備える。ここで処理要素は、データバス１４５５を介して、マウス１４２０等のデータ周辺機器に連結される。いくつかの実施形態において、データ周辺機器１４２０の動作には、データ周辺機器のサポート及びオーディオ／ビデオデータ転送のサポートを同時に可能にする一般コマンドの使用が含まれてもよい。

メディアデータトンネルを備えたＭＨＬ対応モバイルデバイスは、単一のコネクタを介して、ディスプレイ及びデータ周辺機器に同時に接続されてもよい。図１５は、ヒューマンインタフェースデバイスを備えたモバイルデバイスのリンクの一実施形態を示している。図１５は、データ周辺機器（ＵＳＢマウス及びＵＳＢキーボード）の具体例と、データバス（ＵＳＢ）の具体例とを提供している。同図において、ＨＤＭＩ形式１５０５とＭＨＬ形式との間でデータを変換するＭＨＬドングル１５１０が、ＭＨＬインタフェース接続１５５０を介して、ビデオソース１５６０に連結されており、ここでビデオソース１５６０には、モバイルデバイスが含まれてもよい。図１５に示すとおり、ＭＨＬドングルは、処理要素１５２０を備えてもよい。ビデオソース１５６０は、処理要素１５６５に連結されたＭＨＬ送信機１５６２を備える。

いくつかの実施形態において、ＭＨＬドングル１５１０とビデオソース１５６０との間のインタフェース１５５０は、データトンネル１５５２を備え、このデータトンネルは上述のとおりメディアデータトンネルであってもよく、このデータトンネル１５５２は、第１プロトコル（ＭＨＬ）の一般コマンドを介して、第２プロトコル（ＵＳＢ）のデータの送信を可能とする。図示のとおり、ドングル１５１０の処理要素１５２０は、１つ又は複数のＵＳＢ接続１５５７を介して、ＵＳＢ ＨＩＤデータ転送用の１つ又は複数のヒューマンインタフェースデバイスに連結されてもよい。同図において、ヒューマンインタフェースデバイスは、マウス１５２２とキーボード１５２４である。そこで本実装において、ビデオソース１５６０は、ＵＳＢホスト要素として動作してもよく、ＭＨＬドングルはＵＳＢデバイスとして動作してもよい。いくつかの実施形態において、ビューマンインタフェースデバイスによって生成されたＵＳＢデータは、データトンネル１５５２を介してこのようなＵＳＢホスト及びＵＳＢデバイス要素間を転送されるため、ＭＨＬデータ及びＵＳＢ ＨＩＤデータの同時送信を可能にする。

メディアデータトンネルは、モバイルデバイスのユーザに多大な利益をもたらすものの、この技術は低帯域幅のデータ周辺機器にのみサービスを提供してもよい。図１６は、ヒューマンインタフェースデバイスを備えたモバイルデバイスのリンクの一実施形態を示している。特定の実装において、高速周辺機器は、既存の帯域幅にかかる制約のため、モバイルデバイスに直接接続されることが要求されることもある。しかしながら、実施形態は、この構成に限定されるものでない。同図において、ＨＤＭＩ形式１６０５とＭＨＬ形式との間でデータを変換するＭＨＬドングル１６１０は、ＭＨＬインタフェース接続１６５０を介してビデオソース１６６０に連結されており、ここでビデオソース１５６０にはモバイルデバイスが含まれてもよい。図１６に示すとおり、ＭＨＬドングル１６１０は、処理要素１６２０を備えてもよい。ビデオソース１６６０は、処理要素１５６５に連結されたＭＨＬ送信機１６６２を備える。いくつかの実施形態において、ビデオソース１６６０はさらに、高速周辺機器又はパーソナルコンピュータ１６８０へのリンクへのＵＳＢ接続１６５５を備えてもよい。

いくつかの実施形態において、ＭＨＬドングル１６１０とビデオソース１６６０との間のインタフェース１６５０は、データトンネル１６５２を備え、このデータトンネルは上述のとおりメディアデータトンネルであってもよく、このデータトンネル１６５２は、第１プロトコル（ＭＨＬ）の一般コマンドを介して、第２プロトコル（ＵＳＢ）データの送信を可能にする。図示のとおり、ドングル１６１０の処理要素１６２０は、１つ又は複数のＵＳＢ接続１６５７を介して、ＵＳＢ ＨＩＤデータ転送用の１つ又は複数のヒューマンインタフェースデバイスに連結されてもよい。同図において、ヒューマンインタフェースデバイスは、マウス１６２２及びキーボード１６２４である。そこで本実装において、ビデオソース１６６０は、ＵＳＢホスト要素として動作してもよく、ＭＨＬドングルはＵＳＢデバイスとして動作してもよい。いくつかの実施形態において、ヒューマンインタフェースデバイスによって生成されるＵＳＢデータは、データトンネル１６５２を介して、このようなＵＳＢホスト及びＵＳＢデバイス要素間を転送されることにより、ＭＨＬデータ及びＵＳＢ ＨＩＤデータの同時転送を可能とする。いくつかの実施形態において、ビデオソース１６６０もまた、ＵＳＢ接続を介して、高速周辺機器又はパーソナルコンピュータ１６８０へ接続される。したがって、いくつかの実施形態において、ＭＨＬデータ及び低速ＵＳＢデータは、第２インタフェースを介して転送される高速ＵＳＢデータと同時に、第１インタフェースを介して転送されてもよい。

図１７は、特定データの送信用データトンネルを備えた一実施形態又はシステムを示している。この装置又はシステム（ここでは装置と総称する）は、 第２プロトコルのデータを第１プロトコルの一般コマンドを使用して転送させるデータトンネルを備えてもよい。一例において、第１プロトコルはＭＨＬであり、第２プロトコルはＵＳＢである。しかしながら、実施形態は、特定のプロトコルに何ら限定されるものでない。同図において、本説明と密接な関係のない、標準的且つ周知の構成要素は省略してある。いくつかの実施形態において、装置１７００は、ビデオソースデバイス、ビデオシンクデバイス、又はデータプロトコルを変換するドングル、又は複数のプロトコルでデータを転送するその他のデバイスを備えてもよい。

いくつかの実施形態において、装置１７００は、相互接続又はクロスバー１７０５、又はデータ送信を行うその他の通信手段を備える。装置１７００は、情報処理のために相互接続１７０５に連結された、１つ又は複数のプロセッサ等の処理手段又はその他の処理要素１７１０を備えてもよい。プロセッサ１７１０は、１つ又は複数の物理プロセッサと、１つ又は複数の論理プロセッサとを備えてもよい。相互接続１７０５は、図面を単純化するために単一の相互接続として描いたが、複数の異なる相互接続又はバスを表してもよく、このような相互接続への要素の接続は変化してもよい。図１７に示す相互接続１７０５は、いずれか１つ又は複数の個別の物理バス、ポイント間接続、若しくはこれらが適切なブリッジ、アダプタ、又はコントローラで連結されたものを示す抽象概念である。

いくつかの実施形態において、装置１７００はさらに、情報やプロセッサ１７１０によって実行される指示を記憶するメインメモリ１７１５として、ランダムアクセスメモリ（ＲＡＭ）、若しくはその他の動的記憶デバイス又は要素を備える。ＲＡＭメモリには、メモリのコンテンツをリフレッシュすることが必要な動的ランダムアクセスメモリ（ＤＲＡＭ）と、コンテンツのリフレッシュは必要ないものの、コストが高い静的ランダムアクセスメモリ（ＳＲＡＭ）とが含まれる。いくつかの実施形態において、メインメモリには、装置１７００のユーザにより、ネットワークブラジングアクティビティにおいて使用されるブラウザアプリケーションを含む、アプリケーションのアクティブストレージが含まれてもよい。ＤＲＡＭメモリには、クロック信号から制御信号までを含む、同期型動的ランダムアクセスメモリ（ＳＤＲＡＭ）と、拡張データアウト型動的ランダムアクセスメモリ（ＥＤＯ ＤＲＡＭ）が含まれてもよい。いくつかの実施形態において、装置のメモリには、特定のレジスタ、又はその他の専用メモリが含まれてもよい。

装置１７００は、ハードディスクドライブ又はソリッドステートドライブを含むデータストレージ１７２０を備えてもよい。装置１７００はまた、プロセッサ１７１０のための静的情報及び指示を記憶するため、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）１７２５又はその他の静的記憶デバイスを備えてもよい。装置１７００は、例えばフラッシュメモリ等、特定の要素を記憶するための１つ又は複数の不揮発性メモリ要素１７３０を備えてもよい。

装置１７００はまた、相互接続１７０５を介して、出力ディスプレイ１７４０に連結されてもよい。いくつかの実施形態において、ディスプレイ１７４０には、ユーザに情報やコンテンツを表示するための液晶ディスプレイ（ＬＣＤ）又はその他の表示技術が含まれてもよい。ディスプレイ１７４０が、少なくともインプットデバイスの一部として使用されるタッチクリーンを備えるような環境も考えられる。またディスプレイ１７４０がオーディオ情報を提供するスピーカー等のオーディオデバイスであるか、又は、オーディオデバイスを備えてもよい環境も考えられる。

１つ又は複数の送信機又は受信機１７４５もまた、相互接続１７０５に連結されてもよい。いくつかの実施形態において、受信機又は送信機１７４５は、複数のプロトコルのデータをデータトンネル１７７０を有するデータリンクを介して他の装置又はシステム１７７５に送信するため、コネクタ１７５０に連結されてもよく、ここでデータリンクは例えば、図１に示すケーブル１５０であってもよい。装置１７００はさらに、電波信号を介してデータを受信するため、１つ又は複数の全方向性又は双方向性のアンテナ１７５５を備えてもよい。

装置１７００はまた、電源デバイス又は装置１７６０を備えてもよく、これは、電源供給、バッテリ、太陽電池、燃料電池、若しくは電力を提供又は生成するその他のシステム又はデバイスを備えてもよい。電源デバイス又はシステム１７６０によって提供される電力は、装置１７００の要素の必要に応じて分配されてもよい。

図１８は、メディアデータトンネルを用いた通信プロセスの一実施形態を説明するためのタイミング図である。同図において、ＵＳＢ接続を介したＨＩＤ１８１０及びＵＳＢホスト１８３０間の通信、及びＭＨＬ接続１８５０を介した、クレードル要素との関連で説明したＭＨＬ受信機１８４０及びＭＨＬ送信機１８６０間の通信が提供される。図示のとおり、ＷＲＩＴＥ＿ＢＵＲＳＴコマンド１８００を利用した通信、及び、メディアデータトンネル１８０５を備えたＷＲＩＴＥ＿ＢＵＲＳＴコマンドを利用した通信が示されている。図示のとおり、メディアデータトンネルは、動作中のオーバーヘッドを低減してもよく、データ受信の遅延を短縮してもよい。

以上、説明の目的で、本発明の完全な理解を図るため、数多くの特定の詳細を記した。しかしながら、本発明はこれら特定の詳細のいくつかを備えることがなくても実施されるということは、当業者にとって明らかであろう。他の例において、既知の構造及び装置がブロック図の形式で示されている。図示の構成要素間には中間構造があってもよい。本明細書において説明又は図示した構成要素は、図示又は説明しなかった追加的な入力又は出力を有してもよい。図示の要素又は構成要素はまた、異なる配置又は順序で配置されてもよく、それにはあらゆるフィールドの順序入替え又はフィールドサイズの変更が含まれる。

本発明には、種々のプロセスが含まれてもよい。本発明のプロセスは、ハードウェア要素で実施されてもよく、指示によってプログラムされた汎用プロセッサ、特殊目的プロセッサ、又はロジック回路にこれらプロセスを実施させるのに用いられるコンピューター読取可能な指示によって具現化されてもよい。あるいは、これらのプロセスは、ハードウェア及びソフトウェアの組み合わせによって実施されてもよい。

本発明の種々の実施形態は、部分的に、コンピュータプログラムの指示を記憶したコンピュータ読取可能な媒体を備えてもよく、コンピュータ（又はその他の電子機器）を、本発明の実施形態に係るプロセスを実施させるようプログラムするために用いられるコンピュータプログラム製品として提供されてもよい。コンピュータ読取可能な媒体として、フロッピー（登録商標）ディスケット、光ディスク、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、光磁気ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能で、且つ、プログラム可能なリードオンリーメモリ（ＥＰＲＯＭ）、電気的に削除可能で、且つ、プログラム可能なリードオンリーメモリ（ＥＥＰＲＯＭ）、磁気カード又は光カード、フラッシュメモリ、又は電子指示を記憶するのに好適なその他の種別の媒体／コンピュータ読取可能な媒体が挙げられるが、これに限定されるものでない。さらに本発明はまた、コンピュータプログラム製品としてダウンロードされてもよく、このプログラムは遠隔地のコンピュータからリクエストを送ったコンピュータへと転送されてもよい。

多くの方法を最も基本的な形式で説明したが、本発明の基本的な範囲から逸脱することなく、これらの方法に対してプロセスを加えたり削除したりしてもよく、また上述のメッセージのいずれかに対して情報を加えたり差し引くこともできる。さらに多くの変更及び適応が可能であることは、当業者にとって明らかであろう。本発明を限定する目的でなく、それを説明する目的で特定の実施形態を説明した。

要素「Ａ」が要素「Ｂ」と連結されていると表現した場合、要素Ａは要素Ｂに直接連結されていてもよく、また例えば要素Ｃを介して間接的に連結されていてもよい。明細書又は請求書中で構成要素、特徴、構造、処理、又は特性Ａが、構成要素、特徴、構造、処理、又は特徴Ｂを「促す」と述べた場合、「Ａ」は少なくとも「Ｂ」の部分的要因であり、「Ｂ」の促進を補助する少なくとも１つの他の構成要素、特徴、構造、処理、又は特性も存在してもよい。明細書中で構成要素、特徴、構造、処理、又は特性が含まれ「てもよい」「ることがある」又は「うる」と記した場合、これら特定の構成要素、特徴、構造、処理、又は特性が含まれなくてもよい。明細書又は請求書中で数に言及しない場合、説明の要素が１つのみ存在することを意味するものでない。

実施形態は、本発明を実装したもの、すなわち例である。明細書中の「実施形態」「一実施形態」「いくつかの実施形態」あるいは「他の実施形態」といった表現は、これらの実施形態に関連して説明した特定の特徴、構造、又は特性が少なくともいくつかの実施形態に含まれるものであり、必ずしもすべての実施形態に含まれる必要がないことを意味する。「実施形態」「一実施形態」又は「いくつかの実施形態」の種々の外観が、必ずしもすべて同一の実施形態について言及しているものである必要はない。本発明の一例としての実施形態に係る以上の説明において、種々の特徴は、開示を簡潔にし、種々の発明的側面のうちの１つ又は複数の側面の理解を助けるために、単一の実施形態、図面、又は説明にまとめられている場合がある。

いくつかの実施形態において、装置は、データ送信又はデータ受信を行う送信機又は受信機と、装置のデータを取扱う処理要素と、データ転送を行い、データチャンネルとの接続及びコントロールチャンネルとの接続を行うコネクタとを備える。前記処理要素は、前記コントロールチャンネルにおける第１プロトコルのデータの転送を行うものであり、前記コントロールチャンネルを介した前記データの転送には、第２プロトコルのデータの転送を行うための、第１プロトコルの１つ又は複数の一般コマンドの使用が含まれ、前記第２プロトコルのデータは、前記第２プロトコルのデータが前記第１プロトコルを通じて送信されるのに先立って最適化され、前記データチャンネルにおけるデータ転送及び前記コントロールチャンネルにおけるデータ転送は、少なくとも部分的に同時に行われる。

いくつかの実施形態において、前記装置の前記データチャンネルは、１つ又は複数のデータ送信線を備える。いくつかの実施形態において、 前記コントロールチャンネルは、コントロールバスを備える。

いくつかの実施形態において、前記コントロールチャンネルを介したデータ送信には、前記第１プロトコルの他のコマンドも含まれ、前記１つ又は複数の一般コマンドは、前記第１プロトコルの他のコマンドと混合されてもよい。いくつかの実施形態において、前記第２プロトコルの使用は、パケット構造及びサービス性能に関する機能のディスカバリを含む拡張ディスカバリを通じて権限が与えられる。

いくつかの実施形態において、前記第２プロトコルの１つ又は複数のメッセージは、第１プロトコルの単一のデータバーストにおいて送信可能である。いくつかの実施形態において、各データバーストは、割込メッセージを通じて調整され、複数の割込メッセージが統合されて単一のメッセージとして送出される。

いくつかの実施形態において、前記コントロールチャンネルを通じた前記第１プロトコルの識別フィールドは、２バイト以下のサイズを有する。

いくつかの実施形態において、前記第２プロトコルのデータは、少なくとも部分的に、ＨＩＤからの入力からなる。

いくつかの実施形態において、前記第２プロトコルの使用は、割込コマンドの送信を含む拡張中断プロセスを通じて終了される。いくつかの実施形態において、前記割込は、ＭＨＬプロトコルに準拠したＳＥＴ−ＩＮＴコマンドである。

いくつかの実施形態において、前記装置は、ビデオデータソース又はビデオデータシンクである。いくつかの実施形態において、前記第１プロトコルは、ＭＨＬである。いくつかの実施形態において、前記第２プロトコルは、ＵＳＢである。

いくつかの実施形態において、前記装置は、前記第１プロトコルのデータ及び第３プロトコルのデータ間の変換を行うモジュールを備える。いくつかの実施形態において、前記第１プロトコルは、ＭＨＬであり、前記第３プロトコルは、ＨＤＭＩである。いくつかの実施形態において、前記第２プロトコルは、ＵＳＢである。

いくつかの実施形態において、方法は、第１の装置において、第１プロトコルの第１データセットを第２装置から転送するか、又は、第２装置へ転送するステップであって、コネクタを介して、前記第１プロトコルのためのデータチャンネルを通じてデータの送信又は受信を行うことを含むステップと、第１の装置において、第２プロトコルの第２データセット第２装置から転送するか、又は第２装置へ転送するステップであって、前記第２プロトコルのデータを前記コントロールチャンネルを通じて送信するのに先立ち、前記第２プロトコルのデータを最適化するステップとを備える。前記第２データセットを転送するステップには、コネクタを介して、前記第１プロトコルのためのコントロールチャンネルを通じてデータの送信又は受信を行うことを含む。前記第１データセット及び前記第２データセットは、少なくとも部分的に、同時転送され、前記第２データセットは、前記第１プロトコルの１つ又は複数の一般コマンドを使用して転送される。

いくつかの実施形態において、前記方法の前記１つ又は複数の一般コマンドには、一般書込コマンドが含まれる。いくつかの実施形態において、前記データチャンネルは、１つ又は複数のデータ送信線を備え、前記第１プロトコルのデータは、前記１つ又は複数のデータ送信線を介して送信される。いくつかの実施形態において、前記コントロールチャンネルは、コントロールバスを備える。

いくつかの実施形態において、前記方法は、拡張ディスカバリを通じて前記第２プロトコルの使用権限を与えるステップをさらに備え、前記拡張ディスカバリには、パケット構造及びサービス性能の機能に関する情報の交換を含む。

いくつかの実施形態において、前記方法は、第１プロトコルのデータ送信の単一のデータバーストにおいて、前記第２プロトコルの１つ又は複数のメッセージを送信するステップをさらに備える。

いくつかの実施形態において、前記方法は、割込メッセージを通じて各データバーストを調整するステップと、複数の割込メッセージを統合し、前記統合した割込メッセージを単一のメッセージとして送出するステップとをさらに備える。

いくつかの実施形態において、前記コントロールチャンネルを通じた前記第１プロトコルの識別フィールドは、２バイト以下のサイズを有する。

いくつかの実施形態において、前記方法は、前記コントロールチャンネルを介して前記第１プロトコルの他のコマンドを転送するステップをさらに備え、前記１つ又は複数の一般コマンドは、前記第１プロトコルの他のコマンドと混合されてもよい。いくつかの実施形態において、前記第２データセットは、少なくとも部分的に、ＨＩＤからの入力からなる。

いくつかの実施形態において、前記方法は、割込コマンドの送信を含む拡張中断プロセスを通じて、前記第２プロトコルの使用を終了するステップをさらに備える。

いくつかの実施形態において、前記方法において、前記第１プロトコルは、ＭＨＬである。いくつかの実施形態において、前記第２プロトコルは、ＵＳＢである。いくつかの実施形態において、前記１つ又は複数の一般コマンドには、ＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴが含まれる。いくつかの実施形態において、前記１つ又は複数の一般コマンドは、複数の個別の一般イベントを伝達する単一のＳＥＴ＿ＩＮＴメッセージによって有効化される。

いくつかの実施形態において、プロセッサにより実行されると、前記プロセッサに動作を実施させる指示シーケンスのデータを記憶したコンピュータ読取可能な非一時的記憶媒体であって、前記動作は、第１の装置において、第１プロトコルの第１データセットを第２装置から転送するか、又は、前記第２装置へ転送するステップであって、コネクタを介して、前記第１プロトコルのためのデータチャンネルを通じてデータの送信又は受信を行うことを含むステップと、第１の装置において、第２プロトコルの第２データセットを前記第２装置から転送するか、又は前記第２装置へ転送するステップとを備える。前記第２データセットの転送には、コネクタを介して、前記第１プロトコルのためのコントロールチャンネルを通じてデータの送信又は受信を行うステップと、前記第２プロトコルのデータを前記第１プロトコルのための前記コントロールチャンネルを通じて送信するのに先立ち、前記第２プロトコルのデータを最適化するステップとを含む。前記第１データセット及び前記第２データセットは、少なくとも部分的に、同時転送され、前記第２データセットは、前記第１プロトコルの１つ又は複数の一般コマンドを使用して転送される。

いくつかの実施形態において、前記１つ又は複数の一般コマンドには、一般書込コマンドが含まれる。いくつかの実施形態において、前記データチャンネルは、１つ又は複数のデータ送信線を備え、前記第１プロトコルのデータは、前記１つ又は複数のデータ送信線を介して送信される。いくつかの実施形態において、前記コントロールチャンネルは、コントロールバスを備え、前記第２プロトコルのデータは、前記コントロールバスを介して転送される。

いくつかの実施形態において、前記媒体は、拡張ディスカバリを通じて前記第２プロトコルの使用権限を与える指示をさらに備え、前記拡張ディスカバリには、パケット構造及びサービス性能の機能に関する情報の交換を含む。

いくつかの実施形態において、前記媒体は、第１プロトコルのデータ送信の単一のデータバーストにおいて、前記第２プロトコルの１つ又は複数のメッセージを送信する指示を備える。いくつかの実施形態において、前記媒体は、割込みメッセージを通じて各データバーストを調整し、複数の割込メッセージを統合し、前記統合した割込メッセージを単一のメッセージとして送出する指示をさらに備える。

いくつかの実施形態において、前記コントロールチャンネルを通じた前記第１プロトコルの識別フィールドは、２バイト以下のサイズを有する。

いくつかの実施形態において、前記媒体は、前記コントロールチャンネルを介して前記第１プロトコルの他のコマンドを転送する指示をさらに備え、前記１つ又は複数の一般コマンドは、前記第１プロトコルの他のコマンドと混合されてもよい。いくつかの実施形態において、前記第２データセットは、少なくとも部分的に、ＨＩＤからの入力からなる。

いくつかの実施形態において、前記媒体は、割込コマンドの送信を含む拡張中断プロセスを通じて、前記第２プロトコルの使用を終了する指示をさらに備える。いくつかの実施形態において、前記第１プロトコルは、ＭＨＬである。いくつかの実施形態において、前記第２プロトコルは、ＵＳＢである。いくつかの実施形態において、前記１つ又は複数の一般コマンドには、ＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴが含まれる。

Claims (31)

1. データ送信又はデータ受信を行う送信機又は受信機と、
   装置のデータを取扱う処理要素と、
   データ転送を行い、データチャンネルとの接続及びコントロールチャンネルとの接続を行うコネクタとを備え、
   前記処理要素は、前記コントロールチャンネルにおける第１プロトコルのデータの転送を行うものであり、前記コントロールチャンネルを介した前記データの転送には、第２プロトコルのデータの転送を行うための、前記第１プロトコルの１つ又は複数の一般コマンドの使用が含まれ、
   前記第２プロトコルのデータは、前記第２プロトコルのデータが前記第１プロトコルを通じて送信されるのに先立って最適化され、
   前記データチャンネルにおけるデータ転送及び前記コントロールチャンネルにおけるデータ転送は、少なくとも部分的に同時に行われ、
   パケット構造及びサービス性能に関する機能のディスカバリを含む拡張ディスカバリを通じて、前記送信機又は前記受信機に、前記第２プロトコルの使用能力が与えられる、
   装置。
2. 前記データチャンネルは、１つ又は複数のデータ送信線を備える請求項１に記載の装置。
3. 前記コントロールチャンネルは、コントロールバスを備える請求項１に記載の装置。
4. 前記コントロールチャンネルを介したデータ送信には、前記第１プロトコルの他のコマンドも含まれ、前記１つ又は複数の一般コマンドは、前記第１プロトコルの他のコマンドと混合されてもよい請求項１に記載の装置。
5. 前記第２プロトコルの１つ又は複数のメッセージは、第１プロトコルの単一のデータバーストにおいて送信可能である請求項１に記載の装置。
6. 各データバーストは、割込メッセージを通じて調整され、複数の割込メッセージが統合されて単一のメッセージとして送出される請求項５に記載の装置。
7. 前記コントロールチャンネルを通じた前記第１プロトコルの識別フィールドは、２バイト以下のサイズを有する請求項１に記載の装置。
8. 前記第２プロトコルのデータは、少なくとも部分的に、ヒューマンインタフェースデバイス（ＨＩＤ）からの入力からなる請求項１に記載の装置。
9. 前記第２プロトコルの使用は、割込コマンドの送信を含む拡張中断プロセスを通じて終了される請求項１に記載の装置。
10. 前記割込コマンドは、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）（登録商標）プロトコルに準拠したＳＥＴ−ＩＮＴコマンドである請求項９に記載の装置。
11. 前記装置は、ビデオデータソース又はビデオデータシンクである請求項１に記載の装置。
12. 前記第１プロトコルは、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）である請求項１１に記載の装置。
13. 前記第２プロトコルは、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）（登録商標）である請求項１２に記載の装置。
14. 前記装置は、前記第１プロトコルのデータ及び第３プロトコルのデータ間の変換を行うモジュールを備える請求項１に記載の装置。
15. 前記第１プロトコルは、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）であり、前記第３プロトコルは、ＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）（登録商標）である請求項１４に記載の装置。
16. 前記第２プロトコルは、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）である請求項１５に記載の装置。
17. 第１の装置において、第１プロトコルの第１データセットを転送するステップであって、コネクタを介して、前記第１プロトコルのためのデータチャンネルを通じてデータの送信又は受信を行うことを含むステップと、
    前記第１の装置において、第２プロトコルの第２データセットを転送するステップであって、前記コネクタを介して、前記第１プロトコルのためのコントロールチャンネルを通じてデータの送信又は受信を行うことを含み、前記第２プロトコルのデータを前記第１プロトコルのための前記コントロールチャンネルを通じて送信するのに先立ち、前記第２プロトコルのデータを最適化するステップと、
    拡張ディスカバリを通じて、前記第１の装置に、前記第２プロトコルの使用能力を与えるステップと、
    を備え、
    前記第１データセット及び前記第２データセットは、少なくとも部分的に、同時転送され、
    前記第２データセットは、前記第１プロトコルの１つ又は複数の一般コマンドを使用して転送され、
    前記拡張ディスカバリには、パケット構造及びサービス性能の機能に関する情報の交換を含む、
    方法。
18. 前記１つ又は複数の一般コマンドには、一般書込コマンドが含まれる請求項１７に記載の方法。
19. 前記データチャンネルは、１つ又は複数のデータ送信線を備える請求項１７に記載の方法。
20. 前記コントロールチャンネルは、コントロールバスを備える請求項１７に記載の方法。
21. 前記第１プロトコルのデータ送信の単一のデータバーストにおいて、前記第２プロトコルの１つ又は複数のメッセージを送信するステップをさらに備える請求項１７に記載の方法。
22. 割込メッセージを通じて各データバーストを調整するステップと、複数の割込メッセージを統合し、前記統合した割込メッセージを単一のメッセージとして送出するステップとをさらに備える請求項２１に記載の方法。
23. 前記コントロールチャンネルを通じた前記第１プロトコルの識別フィールドは、２バイト以下のサイズを有する請求項１７に記載の方法。
24. 前記コントロールチャンネルを介して前記第１プロトコルの他のコマンドを転送するステップをさらに備え、前記１つ又は複数の一般コマンドは、前記第１プロトコルの他のコマンドと混合されてもよい請求項１７に記載の方法。
25. 前記第２データセットは、少なくとも部分的に、ヒューマンインタフェースデバイス（ＨＩＤ）からの入力からなる請求項１７に記載の方法。
26. 割込コマンドの送信を含む拡張中断プロセスを通じて、前記第２プロトコルの使用を終了するステップをさらに備える請求項１７に記載の方法。
27. 前記第１プロトコルは、ＭＨＬ（Ｍｏｂｉｌｅ Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｌｉｎｋ）である請求項１７に記載の方法。
28. 前記第２プロトコルは、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）である請求項２７に記載の方法。
29. 前記１つ又は複数の一般コマンドには、ＭＨＬ ＷＲＩＴＥ＿ＢＵＲＳＴが含まれる請求項２７に記載の方法。
30. 前記１つ又は複数の一般コマンドは、複数の個別の一般イベントを伝達する単一のＳＥＴ＿ＩＮＴメッセージによって有効化される請求項２９に記載の方法。
31. プロセッサにより実行されると、前記プロセッサに動作を実施させる指示シーケンスのデータを記憶したコンピュータ読取可能な非一時的記憶媒体であって、前記動作は、
    第１の装置において、第１プロトコルの第１データセットを第２装置から転送するか、又は、前記第２装置へ転送するステップであって、コネクタを介して、前記第１プロトコルのためのデータチャンネルを通じてデータの送信又は受信を行うことを含むステップと、
    前記第１の装置において、第２プロトコルの第２データセットを前記第２装置から転送するか、又は、前記第２装置へ転送するステップであって、前記コネクタを介して、前記第１プロトコルのためのコントロールチャンネルを通じてデータの送信又は受信を行うことを含み、前記第２プロトコルのデータを前記第１プロトコルのための前記コントロールチャンネルを通じて送信するのに先立ち、前記第２プロトコルのデータを最適化するステップと、
    拡張ディスカバリを通じて、前記第１の装置に、前記第２プロトコルの使用能力を与えるステップと、を備え、
    前記第１データセット及び前記第２データセットは、少なくとも部分的に、同時転送され、
    前記第２データセットは、前記第１プロトコルの１つ又は複数の一般コマンドを使用して転送され、
    前記拡張ディスカバリには、パケット構造及びサービス性能に関する機能の情報の交換が含まれる、
    記憶媒体。

Images