JP5473941B2 - 電子デバイス接続用コントロールバス - Google Patents

Description

本発明の実施形態は一般に電子デバイスの分野に関し、より詳しくは、電子デバイス接続用コントロールバスに関する方法と装置に関する。

通信データのために複数の電子機器同士を接続することがますます多くなっている。たとえば、エンターテイメントデバイスとマルチメディアデバイスを相互接続して、デジタル情報の転送や共有が行われるようにしてもよい。このようなデバイスを接続するには一般に、デバイスの相互接続・相互通信が容易にできるようにするための、ある形態の標準バスまたはインタフェースが必要となる。

一例として、ＨＤＭＩ（商標）（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）は、非圧縮の高解像度のデジタル映像および音声信号を、関連するコントロール信号とともに転送できるインタフェースとなる。（ＨＤＭＩはＨＤＭＩライセンシングＬＬＣ（ＨＤＭＩ ＬＩｃｅｎｓｉｎｇ，ＬＬＣ）の商標である）。ＨＤＭＩには、Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｓｐｅｃｉｆｉｃａｔｉｏｎ １．３（株式会社日立製作所、松下電器産業株式会社、フィリップス・コンシューマ・エレクトロニクス・インターナショナルＢ．Ｖ．（Ｐｈｉｌｉｐｓ Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ， Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂ．Ｖ．）、シリコン・イメージ・インコーポレーテッド（Ｓｉｌｉｃｏｎ Ｉｍａｇｅ，Ｉｎｃ．）、ソニー株式会社、トムソン・インコーポレーテッド（Ｔｈｏｍｓｏｎ Ｉｎｃ．）および株式会社東芝）（２００６年６月２２日）とそれ以前のバージョンのＨＤＭＩがある。マルチメディアデバイスとはマルチメディアデータを供給、保存または表示できるあらゆるデバイスを指し、その例としては、テレビモニタ、ケーブルおよび衛星セットトップボックス、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＨＤ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ）ＤＶＤおよびブルーレイプレイヤ等のビデオプレイヤ、オーディオプレイヤ、デジタルビデオレコーダその他、これに類するデバイスがある。

しかしながら、どのインタフェースにせよ、その使用はデバイスの物理的大きさによって影響を受けることがある。たとえば、メディアデバイスは携帯型またはハンドヘルド型であってもよい。標準デバイス用として設計されたインタフェースを、より小型のデバイスに使用するのは難しいかもしれない。そのうえ、より小型のデバイスに無理せず追加できる接続の数は物理的に制約される。あるデバイスに対して、たとえばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）接続のほかにもインタフェースを追加すれば、そのデバイスに過剰な接続が行われることになるため、メーカが自社で製造したデバイスにこのようなインタフェースを取り入れることはあまりないであろう。

電子デバイスを接続するためのコントロールバスに関する方法と装置が提供される。

本発明の第一の態様において、方法は、送信デバイスを受信デバイスに連結するステップを含む。デバイスを連結するステップは、送信デバイスと受信デバイスの間にコントロールバスを接続するステップを含み、このコントロールバスは双方向のシングルラインバスである。コントロールバスの使用権は、送信デバイスまたは受信デバイスのどちらかのために獲得され、その使用権を獲得したデバイスがイニシエータ（ｉｎｉｔｉａｔｏｒ）となり、もう一方のデバイスがフォロワ（ｆｏｌｌｏｗｅｒ）となる。１つまたは複数のコントロール信号が１つまたは複数のデータパケットに変換されるのであるが、この１つまたは複数のコントロール信号の各々は、複数の異なる種類のコントロール信号のうちの１つを表す。生成されたデータパケットは、コントロールバスを通じてイニシエータからフォロワに送信される。

本発明の実施形態を限定のためではなく、例として添付の図面に示すが、図中、同様の要素には同様の参照番号が付与されている。

受信デバイスに連結された送信デバイスのある実施形態を示す図である。 送信テバイスと受信デバイスの間のコントロール信号の供給工程のある実施形態を示すフローチャートである。 双方向１ビットコントロールバスに関する調停工程を示す図である。 コントロールバスを通じて標準デバイスに連結されたモバイルデバイスのある実施形態を示す図である。 ２つのモバイルデバイス間の接続のある実施形態を示す図である。 送信機と受信機の接続に利用できるケーブルのある実施形態を示す図である。 送信機と受信機のケーブル信号割当のある実施形態を示す図である。 コントロールデータ転送のためのデータパケットのある実施形態を示す図である。 コントロールデータパケットのある実施形態において使用されるヘッダとコントロールフィールドを示す図である。

本発明の実施形態は一般に電子デバイス接続用コントロールバスに関する。

本明細書において、
「モバイルデバイス」とは、あらゆるモバイル電子デバイスを意味する。用語「モバイルデバイス」としては、これらに限定されないが、セルラーフォン、スマートフォン、ＰＤＡ（携帯情報端末）、ＭＰ３またはその他の形式のミュージックプレイヤ、デジタルカメラ、ビデオレコーダ、デジタル記憶デバイスおよびその他同様のデバイスがある。

いくつかの実施形態において、システムは、モバイルデバイスを他のデバイスに接続するためのインタフェースとなる。いくつかの実施形態において、モバイルデバイスは、標準プロトコルを採用しているかもしれない他のデバイスに接続できるように、改変版プロトコルを採用する。いくつかの実施形態において、モバイルデバイスと他のデバイスとの間の接続は、複数のコントロール信号を１つのバス上に結合することを含み、ここで、このようなコントロール信号は、従来は、標準プロトコルにおいて複数のバスを利用していた。いくつかの実施形態において、改変版プロトコルを利用するモバイル送信デバイスはデュアルモード受信デバイスと接続可能であってもよく、この受信デバイスはモバイル送信デバイスまたは標準送信デバイスのどちらからのデータを受信してもよい。

ある具体的な実施形態において、デバイス間で転送されているデータはマルチメディデータと関連コマンド、たとえばＨＤＭＩデータとコマンドであってもよい。たとえば、高解像度映像データと関連コマンドを持つモバイルデバイスは、標準的ＨＤＭＩデバイス（たとえば、テレビモニタ）に接続されてもよい。しかしながら、本発明の実施形態は、いずれかの特定の種類のデータまたはデバイスに限定されるものではない。本明細書において、ＨＤＭＩ−Ｍは改変版プロトコルを採用するモバイルデバイスを示す。ＨＤＭＩ−ＭデバイスはＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）プロトコルデータの使用を含んでいてもよく、これはＵＳＢ−ＯＴＧ（ＵＳＢ Ｏｎ−Ｔｈｅ−Ｇｏ。携帯型デバイスのための標準であり、デバイスがパーソナルコンピュータまたはその他の携帯型デバイスに接続されるかもしれないデュアルモード動作を可能にする）を利用する。ＨＤＭＩ−Ｅは、本明細書で用いられる場合、改変版プロトコルのモバイルデバイスまたは標準プロトコルのデバイスとインタフェースできるデュアルモードデバイスを指す。

いくつかの実施形態において、リンク層には、双方向１ビット（シングワイヤ）データラインを使って２つのデバイス間でデータの送受信を行うための方法とプロトコルが記載されている。いくつかの実施形態において、翻訳層には、標準コントロールプロトコルを１ビットラインにマッピングする方法が定められている。ＨＤＭＩシステムがかかわる特定の実施形態では、翻訳層に、ＣＥＣ（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏｎｔｒｏｌ）、ＤＤＣ Ｉ２Ｃ（Ｄｉｓｐｌａｙ Ｄａｔａ Ｃｈａｎｎｅｌ）およびその他のプロトコルを１ビットデータラインにマッピングする方法が記載されている。ＨＤＭＩにおいて、ＤＤＣは、１つのソース（「ソース」とはＨＤＭＩ出力を供給するデバイスである）と１つの「シンク」（シンクとは、ＨＤＭＩ入力を受信するデバイスである）の間の環境設定と状態情報交換に使用される。さらに、ＣＥＣは、ユーザの環境にあるすべての各種のオーディオビジュアル製品の間で高度なコントロール機能を提供する任意のプロトコルである。ある実施形態において、コントロールバスの「プライベートチャネル」を、送信機と受信機の間の管理維持（ｈｏｕｓｅｋｅｅｐｉｎｇ）作業に使用してもよい。プライベートチャネルはまた、送信用ファームウェアと受信用ファームウェアの間の通信チャネルとして使用してもよい。

いくつかの実施形態において、リンク層は、ビットを送信するために「２位相マーク符号化」を用いるポイント・ツー・ポイントの双方向バスである。２位相マーク符号化では、データの各ビットが２つの論理状態で表される。記号の最初の状態は常に前の記号の最後の状態と異なる。さらに、記号の最後の状態は、送信されるべきビットが論理「０」であれば最初の状態と同じであり、記号の最後の状態は、そのビットが論理「１」であれば最初の状態と異なる。２位相マーク符号の利用により、１チャネル上でデータ１ビットにつき少なくとも１回の遷移が必ず発生するようになる点で、同期が支援される。

いくつかの実施形態において、標準コントロールコマンドとデータは、１ビットコントロールバス上で送信されるようにデータパケットに変換されるが、このデータパケットは送信されているコマンドとデータの種類を特定する。いくつかの実施形態において、コントロールバスのためのプロトコルは、標準プロトコルのコマンドとデータのバイトをアドレス指定するバイト指向である。一例では、バイト指向プロトコルは、同じくバイト指向であるＨＤＭＩのためのＤＤＣとＣＥＣの両方と整列させるのに使用してもよい。いくつかの実施形態において、各データパケットの開始は、クロック（同期）パルスによって知らされ、これに２ビットのヘッダ、１ビットのコントロールビット、８ビットのデータ、１ビットのパリティが続く。さらに、受信したＡＣＫ（確認応答）のための１ビットがある。この例のバイト構造では、１バイトの送信は合計１３ビット時間と１つのＡＣＫとなる。リンク層は翻訳層に接続され、翻訳層は関連するコントロールプロトコル、たとえば、この例ではＨＤＭＩ動作のためのＤＤＣおよびＣＥＣステートマシン等に接続される。

いくつかの実施形態において、電源投入によりバスコントロールロジックは検出および起動イネーブルフェーズに入り、ロジックがその接続性と機能性を検出する。バスコントロールロジックは次に、バスの使用権を獲得するための調停フェーズに移行してもよく、これについては後で詳しく説明する。最後に、アクティブフェーズでデータがイニシエータ（バスの使用権を獲得したデバイス）からフォロワ（トランザクション相手となるデバイス）に書き込まれてもよい。いくつかの実施形態において、イニシエータは、バスの使用権を獲得した後にコントロールバス上で複数のパケットを送信してもよい。一例において、イニシエータが１つのパケットを送信してしまったら、フォロワからＡＣＫを受け取った直後に、同じイニシエータからの次のデータパケットが始まってもよい。

ある実施形態において、既存の接続を１ビットコントロールバスのために利用してもよく、その際、既存の用途のためのパッドはコントロールバスのためのパッドと共有される。一実施形態では、ホットプラグ検出パッドを１ビットコントロールバスパッドと共有してもよい。ある実施形態において、受信機と送信機は、１ビットコントロールバス上で動作しながら、標準プロトコルのパラメータ内でも動作できるように、切り換え可能であってもよい。たとえば、ＨＤＭＩの場合、コントロールバス上には送信機のためのプルアップ回路と受信機のためのプルダウン回路がある。ある実施形態において、プルアップおよびプルダウン回路は切り換え可能で（プルアップ（またはプルダウン）とオフを選択できる）、モバイルデバイスの接続のような、ＨＤＭＩ規格に含まれないアプリケーションをサポートできる。

いくつかの実施形態において、クロック信号の送信を利用するのではなく、局部発振器を利用して、バスのいずれかの側の必要なタイムベースとする。ある実施形態において、コントロールバスの実装は、電子回路のＰＶＴ（プロセス、電圧、および温度）のばらつきに起因するかもしれない局部発振器周波数の大きな時間変動（たとえば、２Ｘの変動）に対応する。複数の種類のコントロール信号が１つのバス上に結合されるため、より速いクロック時間が必要となる。特定の例において、局部発振器は、ＨＤＭＩデータ送信のためのビット時間に１ｕｓ（１ＭＨｚ）のタイムベースを供給するように分周される。ある実施形態において、このタイムベースの精度は、周波数のばらつきを２Ｘの変動範囲内にとどめるために、＋／−４０％以内である。

ある実施形態において、モバイルデバイスを含めることによって２つの動作モードが考えられ、各々が異なるケーブルを使用してもよい。第一のケースでは、モバイル送信デバイスが標準プロトコルのデュアルモード受信デバイスに接続される。したがって、受信デバイスにはモバイルデバイスに使用するようになされた標準ケーブル入力があるであろう。第二のケースでは、モバイル送信デバイスが別のモバイルデバイスに連結されてもよい。

第一の例において、ＨＤＭＩ−Ｍ送信機とＨＤＭＩ−Ｅデュアルモード受信機がタイプＭ−タイプＥケーブル（ＨＤＭＩ−Ｍ送信機からＨＤＭＩ−Ｅ受信機までのケーブルを指す）で接続される場合、ＨＤＭＩとＵＳＢプロトコルはどちらも運用可能である。この例で、コントロールバスは受信機側の検出を開始し、続いて送信機側のホットプラグ検出を行う。コントロールバスは、接続の送信機側でＵＳＢ−ＯＴＧ ＰＨＹ（物理層）にＩＤを割り当てるのに使用される。

２つのＨＤＭＩ−Ｍデバイスを接続する第二の例において、この接続はタイプＭ−タイプＭケーブル（送信デバイスとなる第一のＨＤＭＩ−Ｍデバイスから受信デバイスとなる第二のＨＤＭＩ−Ｍデバイスまでのケーブルを指す）によって行ってもよい。この例では、ＵＳＢ−ＯＴＧ接続だけが運用可能である。コントロールバスはデバイス間で接続されず、接続のいずれかの側のＵＳＢ−ＯＴＧ ＰＨＹにＩＤを割り当てるのにのみ使用される。この例において、タイプＭ−タイプＭケーブルには物理的に、ＴＭＤＳクロック、データ、およびコントロールバスのラインを接続するためのワイヤがない。しかしながら、ケーブルの一端に、ＵＳＢ−ＯＴＧケーブルのように、ＧＮＤに短絡されたコントロールバスピンがある。さらに、この例では、ＨＤＭＩ−Ｍ送信チップがＵＳＢ ＰＨＹにＩＤ出力を供給するべきである。この出力は通常、低電力状態であってもハイに駆動される。ある実施形態において、ＨＤＭＩ−Ｍ受信チップは、受信デバイスが常にホストとして構成されるため、受信機側のＵＳＢ ＰＨＹにＩＤ出力を供給する必要がない。

いくつかの実施形態において、コントロールバスは双方向であり、どちらのデバイスが送信のためのコントロールバスの使用権を獲得してもよい。ある実施形態において、コントロールバスは、どちらのデバイスも、他のデバイスが競合していなければ使用権を得て、また、両方のデバイスが略同時にコントロールバスの使用権を獲得しようとした場合は、一方のデバイス（一般的には送信機）が調停に勝つように実装されていてもよい。

いくつかの実施形態において、イニシエータ候補はまず、ラインが使用中か否かを確認しなければならない。コントロールバスが特定の期間にわたって空いていれば（一例では、ハイのままである）、このデバイスは調停を開始するかもしれない。ある例において、データ送信は、調停に勝った後に６から９ビット時間で開始する必要があるとしてもよい。イニシエータはデータパケットの送信を開始し、各パケットの後にフォロワから確認応答（ＡＣＫ）が送られる。バスが特定のサイクル数にわたって空いていれば、調停が必要である。

一実装例において、調停を行うために、送信デバイスは４ビット時間にわたり、バスをローに駆動する。これに対して、受信デバイスはバスを第一のビット時間はローに、第二、第三および第四のビット時間はハイに駆動するべきである。一実装例において、２つのデバイスによってコントロールバス上で同時に駆動されるハイとローの間の電気的競合を減らすために、「ハイに駆動」は、ビット時間の開始時に短時間だけ信号をハイに駆動し、その後はバスを解放することを意味する。この実装例では、コントロールバス上のプルアップ抵抗は、他のデバイスによってローに駆動された信号がバス上にないかぎり、信号をハイにプルアップして、ハイに維持する役割を果たす。受信機は、第二、第三、第四のビット時間中にバスの状態をチェックする。受信機は、各ビット時間の開始時にバスを短時間だけハイに駆動し、その後解放するため、バスは、送信機がバスを獲得するためにバスをローに駆動するとローになる。受信機は、これらビット時間のいずれかでバスがローであることを検出すると、それが調停に負けたと結論することができる。受信機と送信機のビット時間には２倍の差があることがあり、そのために、送信機は４ビット時間にわたってバスをローに駆動しなければならない。送信機が受信機より２倍高速であると、受信機は第二のビット時間中にもバスがローであると検出する。

ある実施形態において、イニシエータは、調停に勝った後、特定の期間を上限として（最大９ビット時間）、ＳＹＮＣパルスの送信を待つべきである。フォロワがその期間中（クロック相互の差が最大２倍であるとすると、調停終了後１８ビット時間）にいかなる活動も検出しなければ、フォロワはイニシエータがバスを解放したと推定することができる。

ある実施形態において、送信機と受信機が略同時に調停した場合は、常に送信機が調停に勝つ。しかしながら、反対側がバスの使用権を獲得する前に一方の側が送信できるパケット数が制限されていれば（たとえば、最大パケット数２４）、どちら側も時間が来ればコントロールバスを確実に獲得できる、というようにしてもよい。ある実施形態において、これはリンク層の機能であり、翻訳層に実装されるかもしれないフローコントロールとは独立している。

ある実施形態において、イニシエータがあるトランザクションを完了すると、イニシエータは特定の期間、たとえば６ビット時間は新たなトランザクションを試みない。この期間により、フォロワはそれ自身のトランザクションのためにバスの使用権を要求してイニシエータになるのに十分な時間を得ることができる。この例において、フォロワは最後のＡＣＫの３ビット時間後にトランザクションを開始してもよい。その場合、フォロワはバスの使用権を獲得して、２４パケットまで送信できる。フォロワが最後のＡＣＫから６ビット時間以内にトランザクションを開始しなければ、イニシエータがバスを回復し、第六のビット時間から次の一連の２４のトランザクションを開始することができる。イニシエータとフォロワのどちらも最後のＡＣＫから９ビット時間以内にトランザクションを開始しなければ、バスは非作動となる。バスが非作動であれば、どちら側もその使用権を取得するための調停を必要としない。イニシエータとフォロワのタイムベースには２倍の差がある場合があるため、バス応答待ち時間（ｂｕｓ ｔｕｒｎ−ａｒｏｕｎｄ）中、フォロワは、第三のビット時間中にバスの使用権を取得するまで、またこれを取得しないかぎり、９ビット時間にわたり、その較正内容をイニシエータのタイムベースに保つ必要があるかもしれない。

いくつかの実施形態において、コントロールバスを通じて接続されたデバイスは、そのコントロールバスを用いて較正を行う。いくつかの実施形態において、受信機と送信機の発振クロックの周波数には２倍もの差があるかもしれないため、フォロワのビット時間をイニシエータに基づいて較正する方法を採用してもよい。較正は、フォロワとなるデバイスが、ビット時間中の適当な時点に受信データをサンプリングできるように行われる。

いくつかの実施形態において、イニシエータとなるデバイスからの同期パルス、たとえばデータパケット開始時に供給される同期パルスは、フォロワがそのビット時間をイニシエータに合わせて較正するためにフォロワによって使用される。いくつかの実施形態において、この較正は、コントロールバス上でのその後の毎回の遷移で更新されてもよい。いくつかの実施形態において、同期パルスの時間は、較正の精度を高めるために、１ビット時間より長くてもよい。

いくつかの実施形態において、コントロールバス（２位相マーク符号化を実行中であってもよい）上のデューティサイクルは５０％からずれる傾向があるため、フォロワは、同期パルスのハイの時間とローの時間について別の較正内容を維持してもよい。立ち上がりのタイミングはスペクトル拡散による変動によって移動することがあるため、フォロワはハイとローの別々の信号を使ってこれらの変動を平均化する必要があるかもしれない。

図１は、受信デバイスに連結された送信デバイスのある実施形態を示す図である。この図において、送信機１０２はケーブル１２０で受信機１１０に連結されている。この図において、受信機１１０は標準プロトコルデバイス１１２であってもよく、これはデュアルモードＨＤＭＩ受信デバイスを備えていてもよい。いくつかの実施形態において、デュアルモードＨＤＭＩ受信デバイスは、ＨＤＭＩ送信機とＨＤＭＩ−Ｍ送信機の両方と通信できる。いくつかの実施形態において、送信機１０２は各種のデバイスの中の１つであってよい。この図において、送信機は第一の種類の送信デバイスであってもよく、図では標準プロトコルデバイス１０４、たとえばＨＤＭＩ送信デバイスとして描かれ、または第二の種類のデバイスであってもよく、図ではモバイルプロトコルデバイス１０６として描かれている。モバイルプロトコルデバイス１０６はＨＤＭＩ−Ｍ送信デバイス、たとえばハンドヘルド型またはその他のモバイルメディアデバイスであってもよい。いくつかの実施形態において、ケーブル１２０は、プロトコルデバイス接続用の標準プロトコルケーブル１２２（ＨＤＭＩ適合ケーブル等）または、単一コントロールケーブルと電源ケーブルを含むモバイルプロトコルケーブル１２４（ＨＤＭＩ−Ｍ適合ケーブル等）のいずれであってもよい。いくつかの実施形態において、受信機１１０はケーブル１２０上で受け取った信号を利用して、送信機１０２との接続を検出し、送信機はケーブル１２０上の信号を利用して、受信機１１０との接続、たとえばホットプラグ接続の確立を支援する。

特定の実装例において、コントロールバスは、複数のＨＤＭＩプロトコルの送信ができるように、動作周波数が１ＭＨｚであってもよい。この実装例において、コントロールバスは内部レジスタの制御を行い、読取と書込みを可能にしてもよい。ＨＤＭＩに関して、コントロールバスは、ＤＤＣ Ｉ２Ｃインタフェースへの橋渡しと、ＣＥＣインタフェースへの橋渡しの役割を果たし、他の将来のプロトコルにも拡張可能である。ある実施形態において、コントロールバスは、システムの残りの部分がパワーダウンモードである間も動作可能であってもよい。送信機と受信機との協働により、システムは較正や外部のマイクロコントローラの介入を必要とせず、タイミングにはリング発振器や外部クロックを利用する。このシステムは、ＤＤＣまたはＣＥＣプロトコルのいずれについても、ビット単位の精度のタイミングを保つ必要がない。

図２は、送信デバイスと受信デバイスの間のコントロール信号供給のための工程のある実施形態を示すフローチャートである。この図において、送信機と受信機が相互に接続される（２０２）。いくつかの実施形態において、送信機はモバイルプロトコルデバイスであり、受信機は標準プロトコルデバイスである。受信機は標準プロトコルデバイスとモバイルプロトコルデバイスの両方と通信できるデュアルモードデバイスであってもよい。特定の実施形態において、送信機はＨＤＭＩ−Ｍプロトコルデバイスであり、受信機はＨＤＭＩプロトコルデバイスである。送信機と受信機は、モバイルプロトコルケーブル、たとえばＨＤＭＩ−Ｍ適合ケーブルで接続される。ある実施形態において、送信機と受信機は双方向１ビットコントロールバスを利用する。ある実施形態において、コントロールバスは、２位相マーク符号化を利用したバスである。

ある実施形態において、送信機と受信機は互いを特定するための検出／ホットプラグ工程を実行し、通信を開始する（２０４）。この例において、受信デバイスはモバイルデバイスに接続され、したがって、双方向１ビットコントロールバスを使用していると判断される。ある実施形態において、送信機と受信機は、バスの所有権を決定するための調停工程を実行する。調停工程は、図３に示すような調停工程であってもよい。この例では、送信機が調停に勝ち、そのトランザクションのイニシエータとなる。ある実施形態において、送信機はイニシエータとして、受信機に対し、送信機と受信機のクロックを較正するための信号を供給する（２０８）。

いくつかの実施形態において、複数のコントロール信号がコントロールバス上で多重化される（２１０）。ある実施形態において、複数のコントロール信号が調停工程にかけられ、どのコントロール信号をコントロールバスで伝送するかが判断される。いくつかの実施形態において、コントロール信号は、データのバイトから各パケットの中のデータの種類を特定するデータパケットに変換される。ある特定の例において、ＨＤＭＩコントロール信号は、コントロールバス上でバイトごとに多重化される。たえば、ＣＥＣ、ＤＤＣおよびプライベートチャネルの命令がコントロールバス上で多重化される。コントロール信号が送信されると（２１２）、この信号は送信用のデータパケットに変換される。ある実施形態において、データパケットは、図８に示されるようなデータパケットであってもよい。すると、データパケットは１ビットコントロールバス上で送信機から受信機に送信される（２１６）。この工程は、送信機に送信すべきコントロール信号があるかぎり継続してもよく、その後工程は停止する（２１８）。

受信機については、コマンドデータを含む１つまたは複数のデータパケットを１ビットコントロールバスで受信してもよい（２２０）。受信機は、受け取ったデータパケットの各々のヘッダを読み取り、コントロールタイプを判断し（２２２）、たとえばＨＤＭＩ等の標準プロトコルにしたがって必要とされるように各コマンドを取り扱う（２２４）。

図３は、双方向１ビットコントロールバスの調停工程を示す。送信機と受信機が、双方向１ビットバスを含む接続手段で接続される（３０２）。動作中のある時点で、デバイスの一方または両方がバスの使用権を獲得したいと希望するかもしれない。この工程では、コントロールバスの状態が判断される（３０４）。ＣＢＵＳが空いている（特定のサイクル数にわたり使用されていない）、または特定のサイクル数にわたり相手デバイスによって使用されていなかった（そのデバイスがコントロールバスを利用する番であることを示す）と判断された場合（３０６）、相手デバイスがまだバスを使用中であると判断され（３０８）、バスの使用についての調停が行われてもよい（３１０）。それ以外の場合、デバイスは、コントロールバスが相手デバイスによって使用中であると判断してもよい。ある実施形態において、送信機と受信機が略同時にバスの使用権を求めた場合、送信機が調停に勝つ。送信機がバスの使用権を求めた場合、送信機はバスを特定のサイクル数にわたり（この例では４サイクル）ローに駆動し（３１２）、これによって、送信機がバスの使用権を求めていることを受信機に通知する。すると、送信機がバスの使用権を獲得する（３１４）。受信機がバスの使用権を求めた場合、受信機は１サイクルだけバスをローに駆動し、次に短パルスの間はバスをハイに駆動する（３１６）。送信機がバスを駆動していないと信号はハイのままであり、送信機がバスをローに駆動すると、信号はローになる。この動作に基づき、受信機は特定の期間中（一例として、第二から第四サイクル中）にＣＢＵＳ上の信号をチェックする（３１８）。信号がハイのままであると、これは、送信機がバスの使用権を求めていないことを意味し、受信機が使用権を獲得する（３２２）。信号がハイのままでないと、これは送信機が信号をローに駆動していて、バスの使用権を求めていることを示し、送信機が再び使用権を獲得する（３１４）。

図４は、コントロールバスにより標準デバイスに連結されたモバイルデバイスのある実施形態を示す。この図において、モバイルＨＤＭＩ送信デバイス（ＨＤＭＩ−Ｍ送信ボード４１０）は、デュアルモードＨＤＭＩ受信デバイス（ＨＤＭＩ−Ｅ受信ボード４３０）に連結される。これらのデバイスはコントロールバス／ホットプラグ４２０（本明細書ではＣＢＵＳと呼ぶ）、受信機４３０から送信機４１０に供給される５ボルト電源ＶＢＵＳ、およびＵＳＢ接続４０６によって連結される。いくつかの実施形態において、送信機は切り換え可能なプルアップ回路４１４（ＨＤＭＩ−Ｍ送信チップ４１２の一部として描かれている）を有し、受信機はＣＢＵＳ上にプルダウン回路４３６（ＨＤＭＩ−Ｅ受信チップ４３２の一部として描かれている）を有する。また、図には、受信機４３０の直列インピーダンス４３４も描かれている。ＶＢＵＳ ４０４は送信機４１０の電源／起動イネーブルノード４１６と受信機４３０の電源スイッチ４３８の間に接続されている。ＵＳＢバス４０６は、送信機４１０のＵＳＢ ＰＨＹ（物理層）４１８と受信機４３０のＵＳＢ ＰＨＹ ４４０の間に接続されている。

本発明のある実施形態において、ＣＢＵＳ ４０２は双方向１ビットコントロールバスである。ある実施形態において、ＣＢＵＳは２位相マーク符号化を利用して動作する。ＣＢＵＳは、複数の異なる種類のコントロール信号を送信機４１０と受信機４３０の間で伝送するのに使用され、コントロール信号は送信のために多重化される。ある実施形態において、送信機４１０または受信機４３０のいずれかがＣＢＵＳ ４０２の使用権を獲得してもよく、ＣＢＵＳの使用権は調停工程によって確立される。

図５は、２つのモバイルデバイス間の接続のある実施形態を示す。この図において、第一のモバイルデバイス５１０（第一のＨＤＭＩ−Ｍ側）は第二のモバイルデバイス５３０（第二のＨＤＭＩ−Ｍ側）に接続されていてもよい。これらはモバイルデバイスであるため、両デバイスともそれぞれプルアップ回路５１４と５３４を有する。これらのデバイスは、電源供給されていないＶＢＵＳ ５０４と、ＵＳＢ接続５０６によって接続されている。デバイスはさらにＴＭＤＳ（Ｔｒａｎｓｉｔｉｏｎ Ｍｉｎｉｍｉｚｅｄ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｓｉｇｎａｌｉｎｇ）バス５０８を備えていてもよい。ＵＳＢバス５０６は、第一のＵＳＢ ＰＨＹ ５１８を第二のＵＳＢ ＰＨＹ ５４０に接続する。しかしながら、２つのモバイルデバイスを接続すると、コントロールバスが切断される。

図６は、送信機と受信機の接続に使用できるケーブルのある実施形態を示す。この例において、ＨＤＭＩケーブル６１０には、クロックチャネルと、３つのデータチャネル（青６１６、緑６１８、赤６１４）と、ＤＤＣチャネル６２２（ＤＤＣチャネルは２本のワイヤを有する）とＣＥＣチャネル６２０（ＣＥＣチャネルは１本のワイヤ）が含まれていてもよい。（ケーブルには、図に示されたもの以外のライン、たとえば＋５Ｖ電源信号ライン、ホットプラグ検出、およびＵＳＢデータチャネル等が含まれていてもよい）。しかしながら、ある実施形態において、ＨＤＭＩ−Ｍケーブルには、デバイスがより小型であるため、少ないラインが用いられていてもよく、たとえば、クロックチャネル６３２、結合データチャネル６３２、１ビットコントロールチャネル６４０が用いられる。いくつかの実施形態において、１ビットコントロールチャネルは双方向チャネルであり、送信機と受信機の両方からの結合されたコントロールデータを含めるように高速で動作される。

図７は、送信機と受信機のケーブル信号割当のある実施形態を示す。図７は、ケーブル接続の具体的な実装例である。ある実施形態において、割当は、ＨＤＭＩデバイス７３０に接続されるＨＤＭＩ−Ｍデバイス７２０のためのピン７１０を示している。ある実施形態において、ＨＤＭＩデバイスは、標準ＨＤＭＩデバイスとＨＤＭＩ−Ｍデバイスの両方と通信可能なデュアルモードデバイスである。この例において、ＨＤＭＩデバイス７３０のデータチャネルのうちの２つはＨＤＭＩ−Ｍデバイスに接続されず（ピン１−６）、したがって、データは１つのデータチャネル（ピン７−９）で送られる。さらに、ＤＤＣ（ピン１５−１７。このラインはＵＳＢデータのために使用される）によって搬送されるコントロールデータと、ＣＥＣデータは、コントロールバス（ピン１９。これはＨＤＭＩデバイスのホットプラグ検出と使用される）の上で送られる。

図８は、コントロールデータ転送のためのデータパケットのある実施形態を示す。ある実施形態において、複数のソースからのコントロールデータは結合または多重化されて、１ビットコントロールバスで送られる。ある実施形態において、コントロールデータバイトは、コントロールバス上で転送されるように、データパケットとされる。ある例において、データパケットはデータパケット８００であってもよい。データパケット８００に含まれるフィールドは、実施形態ごとに異なっていてもよい。この例では、データパケット８０２には、１ビット同期信号８０２に続き、データパケット８００に含まれるデータパケットの種類を示す２ビットのヘッダ８０４と、そのデータパケットにデータまたはコマンドが含まれか否かを示す１ビットのコントロールフィールド８０６が含まれる。各フィールドに含まれるビット数は、実装状況によって異なっていてもよい。ある例において、同期信号８０２は、較正の精度を高めるために、複数ビットを含んでいてもよい。

ヘッダ８０４とコントロールフィールド８０６は、たとえば図９に示されるように符号化されてもよい。コントロールフィールドに続き、８ビットの翻訳層のデータまたはコマンド８０８がある。データ８０８の次に１パリティビット８１０がある。このパリティはヘッダとデータの両方をカバーし、偶数パリティが使用される。偶数パリティの使用により、バスは確認応答ＡＣＫ ８１２の開始前に確実にハイレベルに遷移する。

以上のように、ある実施形態において、パケットは同期パルスによってコントロールバスでハイの状態（バスが空いていることを示す）から始まり、終了時のコントロールバスはＡＣＫによりハイの状態となる。これら２つのビット以外に、パケット内には、バスが終了時にハイの状態となるために、偶数の０があるべきである。（２位相マーク符号化方式では、本明細書においては、終了時のバスレベル「１」は開始時と同じであり、終了時のバスレベル「０」は、開始時と逆である）。偶数のビットがあるため、「１」が偶数でなければならず、したがって偶数パリティである。

図９は、コントロールデータパケットのある実施形態で使用されるヘッダとコントロールフィールドを示す。図８のデータパケット８００のような、コントロールデータを送るデータパケットの中で、ヘッダ９１０の２ビットは、データパケットにＤＤＣパケット（ヘッダフィールド「００」）、ＣＥＣパケット（ヘッダフィールド「０１」）、またはコントロールバス用プライベートチャネルデータ（ヘッドフィールド「１０」）が含まれるか否かを示すために使用される。この例では、ヘッダフィールド「１１」は将来の使用のために保留される。さらに、コントロールフィールド９２０のうちの１ビットは、データビット（図８に示されるデータ８０８等）が翻訳層のデータ（コントロールフィールド「０」）または翻訳層のコマンド（コントロールフィールド「１」）のどちらを表すかを示すために使用されてもよい。

上述のように、説明のために、本発明を十分に理解できるように数多くの具体的な詳細事項が示されている。しかしながら、当業者であれば、本発明はこのような具体的詳細事項のいくつかがなくても実践可能であることがわかるであろう。別の場合では、周知の構造やデバイスがブロック図の形で示される。図に示されている構成要素と構成要素の間には、介在する構造があってもよい。本願の説明文や図に示された構成要素には、図や説明にはない入力や出力があってもよい。

本発明の各種の実施形態は、各種のプロセスを含んでいてもよい。これらのプロセスは、ハードウェア構成要素によって遂行されるようにしても、あるいはコンピュータプログラムや機械実行可能な命令の中に具現化し、これを用いて、その命令を含めてプログラムされた汎用または特定用途プロセッサまたはロジック回路にプロセスを実行させるようにしてもよい。あるいは、プロセスは、ハードウェアとソフトウェアの組み合わせによって遂行されてもよい。

本発明の各種の実施形態の一部をコンピュータプログラム製品として提供してもよく、これにはコンピュータプログラム命令が記録されたコンピュータ読取可能媒体も含まれ、このような製品は、コンピュータ（またはその他の電子デバイス）を、本発明の実施形態によるプロセスを実行するようにプログラムするのに用いられる。機械読取可能媒体としては、これらに限定されないが、フロッピー（登録商標）ディスケット、光ディスク、ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ ｄｉｓｋ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、光磁気ディスク、ＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｙ−ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）磁気もしくは光カード、フラッシュメモリまたは、電子命令の保存に適した上記以外の種類の媒体／機械読取可能媒体がある。さらに、本発明はまた、コンピュータプログラム製品としてダウンロードされてもよく、この場合、プログラムは、リモートコンピュータからこれを要求したコンピュータへと転送される。

さまざまな方法を、その最も基本的な形態で説明したが、本発明の基本的範囲から逸脱することなく、これらの方法にプロセスを追加し、またそこから削ったり、上の記述内容に情報を追加し、またそこから削除したりすることができる。当業者であれば、さらにまた数多くの改変や適応化が可能であることが明らかであろう。個々の実施形態は、本発明を限定するためではなく、説明のために提供したものである。本発明の実施形態の範囲は、上述の具体例ではなく、以下の特許請求の範囲によってのみ決定されるものとする。

要素Ａが要素Ｂに、または要素Ｂと連結されている、との記述がある場合、要素Ａは直接Ｂに結合されていても、あるいはたとえば要素Ｃを通じて間接的に接続されていてもよい。明細書または特許請求範囲に、構成要素、特徴、構造、プロセスまたは特性Ａが構成要素、特徴、構造、プロセスまたは特性Ｂの「基因となる」と記載されている場合、これは、ＡはＢの少なくとも部分的基因であるが、Ｂの誘引を助ける構成要素、特徴、構造、プロセスまたは特性がその他に少なくとも１つあってもよいことを意味する。明細書に、ある構成要素、特徴、構造、プロセスまたは特性が「含まれていてもよい（ｍａｙ）」、「含まれるかもしれない（ｍｉｇｈｔ）」または「含まれうる（ｃｏｕｌｄ）」と記されている場合、この特定の構成要素、特徴、構造、プロセスまたは特性が含まれている必要はない。明細書または特許請求の範囲に、「１つの（ａ，ａｎ）」要素への言及がある場合、言及された当該の要素が１つしかないことを意味しない。

ある実施形態は、本発明の実現態様または例である。明細書における「ある実施形態」、「一実施形態」、「いくつかの実施形態」または「他の実施形態」という表現は、その実施形態に関連して説明された特定の特徴、構造または特性が少なくともいくつかの実施形態に含まれるが、必ずしもすべての実施形態に含まれるとは限らないことを意味する。「ある実施形態」、「一実施形態」または「いくつかの実施形態」の用語がさまざまな箇所で使用されていても、必ずしもすべてが同じ実施形態を指すというわけではない。本発明の例示的な実施形態に関する上記の説明においては、開示を簡素化し、本発明の多様な態様の１つまたは複数を理解しやすくするために、各種の特徴が１つの実施形態、図面またはこれに関する説明の中にまとめられている場合があることがわかるであろう。しかしながら、このような説明方法は、特許請求されている発明には各請求項に明記されているもの以外の特徴が必要となるという意図を反映したものと解釈すべきではない。むしろ、以下の特許請求の範囲に反映されているように、本発明の態様は、上述のある１つの実施形態に含まれる全特徴の中の一部を備える形態にある。したがって、特許請求の範囲をこの説明の中に明確に取り入れるものとし、各請求項は、それ自体が本発明の異なる実施形態として独立しているものとする。

Claims (30)

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. 前記受信デバイスは、前記標準プロトコルを利用するデバイスまたは前記改変版プロトコルを利用するデバイスと通信可能なデュアルモードデバイスである請求項２８に記載の受信デバイス。

Images