(57)【要約】【解決手段】あらかじめ選択されたセットのデジタル制御データおよびデジタルプレゼンテーションデータを通信するための通信プロトコルを形成するために一緒に連結されたパケットを用いて、通信回路を介してホストとクライアントとの間でデジタルデータを転送するためのデータインターフェース。通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットにデジタルデータを形成するように構成され、少なくとも１つはホスト装置内に存在し、通信路を介してクライアントと接続されたリンクコントローラにより信号プロトコルが使用される。このインターフェースは短距離の「シリアル」タイプデータリンクに対して、費用対効果が高く、低電力で、双方向の高速データ転送機構を提供する。このインタフェースは、ウエアラブルマイクロディスプレイのような表示素子乃至ポータブルコンピュータおよび無線通信装置に接続するのに特に有用な小型のコネクタと薄く柔軟なケーブルを用いて実装するのに適する。【選択図】図４
2004531916.tif 000002
【特許請求の範囲】
【請求項１】
下記を具備する、通信路を介してホスト装置とクライアント装置との間で高レートでデジタルプレゼンテーションデータを転送するためのデジタルデータインターフェース：
前記通信路を介して、ホストとクライアントとの間であらかじめ選択されたセットのデジタル制御およびプレゼンテーションデータを通信するための通信プロトコルを形成するために一緒に連結された複数のパケット構造；および
前記通信路を介して前記クライアントに接続され、前記通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成された、前記ホスト装置内に存在する少なくとも１つのリンクコントローラ。
【請求項２】
あらかじめ定義された固定の長さを有する、前記ホストとクライアントとの間で通信される媒体フレーム内で一緒にグループ化される前記パケットをさらに具備し、所定数の前記パケットは異なるかつ可変の長さを有する、請求項１のインターフェース。
【請求項３】
前記ホストからのパケットの転送の最初の部分に位置するサブフレームヘッダーパケットをさらに具備する、請求項１のインターフェース。
【請求項４】
前記通信リンクを介して、前記ホストとクライアントとの間で情報の双方向転送をさらに具備する、請求項１のインターフェース。
【請求項５】
前記リンクコントローラはホストリンクコントローラであり、前記通信路を介して前記ホストに接続された前記クライアント内に存在し、前記通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成された、少なくとも１つのクライアントリンクコントローラをさらに具備する、請求項１のインターフェース。
【請求項６】
前記ホストリンクコントローラは１つ以上の差動ラインドライバを具備し、および前記クライアントリンクコントローラは前記通信路に接続された１つ以上の差動ライン受信器を具備する、請求項５のインターフェース。
【請求項７】
クライアントユーザへのプレゼンテーションのために順方向リンクを介して前記ホストから前記クライアントにデータを転送するために、ビデオタイプデータに対する１つ以上のビデオストリームパケットと、オーディオタイプデータに対する１つ以上のオーディオストリームパケットをさらに具備する、請求項１のインターフェース。
【請求項８】
前記ホストにデータを転送するために、前記クライアントのための１つ以上の逆方向リンクカプセル化パケットをさらに具備する、請求項１のインターフェース。
【請求項９】
前記クライアント装置が前記インターフェースを介してどんなタイプのデータおよびデータレートに適合することができるかを判断するように、前記ホストリンクコントローラは、前記クライアント装置から表示能力情報を要求する、請求項１のインターフェース。
【請求項１０】
クライアントリンクコントローラは、少なくとも１つのディスプレイ能力パケットを用いて前記ホストリンクコントローラにディスプレイ能力またはプレゼンテーション能力を通信する、請求項９のインターフェース。
【請求項１１】
前記通信路は一連の４つ以上の導体と１つのシールドを有するケーブルを具備する、請求項１のインターフェース。
【請求項１２】
前記ホストリンクコントローラは、前記通信路の一部として動作するＵＳＢデータインターフェースを具備する、請求項１のインターフェース。
【請求項１３】
前記ホスト装置は、無線通信装置を具備する、請求項１のインターフェース。
【請求項１４】
前記ホスト装置は、その中に無線モデムが配置されたポータブルコンピュータを具備する、請求項１のインターフェース。
【請求項１５】
前記クライアント装置は、ポータブルビデオディスプレイを具備する、請求項１のインターフェース。
【請求項１６】
前記ポータブルビデオディスプレイはマイクロディスプレイデバイスを具備する、請求項１４のインターフェース。
【請求項１７】
前記クライアント装置は、ポータブルオーディオプレゼンテーションシステムを具備する、請求項１のインターフェース。
【請求項１８】
前記ホストは、前記クライアント装置に転送されるマルチメディアデータを記憶するための手段を具備する、請求項１のインターフェース。
【請求項１９】
前記パケットは各々、パケットレングスフィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを具備する、請求項１のインターフェース。
【請求項２０】
複数の転送モードをさらに具備し、各転送モードは、所定の時間期間にわたって異なる最大数のビットのデータを並列に転送可能であり、各モードは前記ホストとクライアントリンクドライバとの間のネゴシエーションにより選択可能であり、および
前記転送モードは、データの転送中、前記モード間で動的に調節可能である。
【請求項２１】
カラーマップタイプパケット、ビットブロックトランスファータイプパケット、ビットマップエリアフィルタイプパケット、ビットマップパターンフィルタイプパケット、およびトランスペアレントカラーイネーブルタイプパケットのグループから選択されるビデオ情報を転送するために使用可能な複数のパケットをさらに具備する、請求項１のインターフェース。
【請求項２２】
データを有さない順方向リンク送信の期間を占有するために前記ホストにより発生されたフィラータイプパケットをさらに具備する、請求項１のインターフェース。
【請求項２３】
インターフェース−ユーザ定義されたデータを転送するためのユーザ定義されたストリームタイプパケットをさらに具備する、請求項１のインターフェース。
【請求項２４】
前記クライアント装置に関連するユーザ入力装置にまたはユーザ入力装置からデータを転送するためのキーボードデータタイプパケットとポインティングデバイスデータタイプパケットをさらに具備する、請求項１の方法。
【請求項２５】
前記通信路を介していずれかの方向におけるデータの転送を終了するために、前記ホストにより前記クライアントに転送されるリンク停止タイプパケットをさらに具備する、請求項１のインターフェース。
【請求項２６】
下記を具備する、ユーザへのプレゼンテーションのために
通信路を介して、ホスト装置とクライアント装置との間で高レートでデジタルデータを転送する方法：
１つ以上の複数のあらかじめ定義されたパケット構造を発生し、それらを一緒に連結してあらかじめ定義された通信プロトコルを形成する；
前記通信プロトコルを用いて、前記通信路を介して前記ホスト装置と前記クライアント装置との間で、あらかじめ選択されたセットのデジタル制御データおよびデジタルプレゼンテーションデータを通信する；
前記ホスト装置内に存在する少なくとも１つのホストリンクコントローラを前記通信路を介して前記クライアント装置に接続し、前記ホストリンクコントローラは、前記通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される；および
前記リンクコントローラを用いて、前記通信路を介して、パケットの形態でデータを転送する。
【請求項２７】
前記ホストとクライアントとの間の通信のために媒体フレーム内で前記パケットを一緒にグループ化することをさらに具備し、所定数の前記パケットを有するあらかじめ定義された固定の長さを有する媒体フレームは異なるかつ可変の長さを有する、請求項２６の方法。
【請求項２８】
サブフレームヘッダタイプパケットを用いて前記ホストからパケットの転送を開始することをさらに具備する、請求項２６の方法。
【請求項２９】
前記通信リンクを介して双方向に前記ホストとクライアントとの間で情報を転送することをさらに具備する、請求項２６の方法。
【請求項３０】
前記通信路を介して、前記ホスト装置に接続された前記クライアント装置内に存在し、前記通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成された少なくとも１つのクライアントリンクコントローラをさらに具備する、請求項２６の方法。
【請求項３１】
前記ホストリンクコントローラは１つ以上の差動ラインドライバを具備し、前記クライアントリンクコントローラは前記通信路に接続された１つ以上の差動ライン受信器を具備する、請求項３０の方法。
【請求項３２】
ビデオデータタイプに対して１つ以上のビデオストリームタイプパケットを用い、オーディオタイプデータに対して１つ以上のオーディオストリームタイプパケットを用いてクライアントへのプレゼンテーションのために前記ホストから前記クライアントにデータを転送することをさらに具備する、請求項２６の方法。
【請求項３３】
１つ以上の逆方向リンクカプセル化タイプパケットを用いて前記クライアントから前記ホストにデータを転送することをさらに具備する、請求項２６の方法。
【請求項３４】
前記インターフェースを介して前記クライアントがどんなタイプのデータおよびデータレートに適合できるかを判断するために、ホストリンクコントローラによって、前記クライアントからディスプレイ能力情報を要求することをさらに具備する、請求項２６の方法。
【請求項３５】
少なくとも１つのディスプレイ能力タイプパケットを用いて、クライアントリンクコントローラから前記ホストリンクコントローラにディスプレイ能力またはプレゼンテーション能力を通信することをさらに具備する、請求項３４の方法。
【請求項３６】
前記通信路は一連の４つ以上の導体および１つのシールドを持つケーブルを具備する、請求項２６の方法。
【請求項３７】
前記通信路の一部として、前記リンクコントローラの各々によってＵＳＢデータインターフェースを動作させることをさらに具備する、請求項２６の方法。
【請求項３８】
前記ホストは無線通信装置を具備する、請求項２６の方法。
【請求項３９】
前記ホストは、その中に無線モデムを配置したポータブルコンピュータを具備する、請求項２６の方法。
【請求項４０】
前記クライアント装置はポータブルビデオディスプレイを具備する、請求項２６の方法。
【請求項４１】
前記ポータブルビデオディスプレイはマイクロディスプレイデバイスを具備する、請求項４０の方法。
【請求項４２】
前記クライアント装置は、ポータブルオーディオプレゼンテーションシステムを具備する、請求項２６の方法。
【請求項４３】
前記ホストにおいて、前記クライアント装置に転送されるマルチメディアデータを記憶することをさらに具備する、請求項２６の方法。
【請求項４４】
前記パケットは各々が、パケットレングスフィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドを具備する、請求項２６の方法。
【請求項４５】
下記をさらに具備する、請求項２７の方法：
前記ホストと前記クライアントリンクドライバとの間で、各方向において複数の転送モードの１つの使用をネゴシエートし、複数の転送モードの各々は、所定時間期間にわたって異なる最大数のビットデータを並列に転送することを可能にする；および
データの転送中に前記転送モード間を動的に調節する。
【請求項４６】
カラーマップタイプパケット、ビットブロック転送タイプパケット、ビットマップエリアフィルタイプパケット、ビットマップパターンフィルタイプパケット、およびトランスペアレントカラーイネーブルタイプパケットのグループから選択されたビデオ情報を転送するために１つ以上の複数のパケットを使用することをさらに具備する、請求項２６の方法。
【請求項４７】
データを有さない順方向リンク送信の期間を占有するために前記ホストによりフィラータイプパケットを発生することをさらに具備する、請求項２６の方法。
【請求項４８】
ユーザ定義されたストリームタイプパケットを用いて、インターフェースユーザ定義されたデータを転送することをさらに具備する、請求項２６の方法。
【請求項４９】
キーボードデータタイプパケットおよびポインティングデバイスデータタイプパケットを用いて前記クライアント装置に関連したユーザ入力装置へまたはユーザ入力装置からデータを転送することをさらに具備する、請求項２６の方法。
【請求項５０】
前記ホストによる前記クライアントへの送信に対して、リンク中止タイプパケットを用いて、前記通信路を介していずれかの方向におけるデータの転送を終了することをさらに具備する、請求項２６の方法。
【請求項５１】
下記を具備する、ユーザへのプレゼンテーションのために通信路を介してホスト装置とクライアント装置との間で高レートでデジタルデータを転送するための装置：
１つ以上の複数のあらかじめ定義されたパケット構造を発生し、前記パケット構造を一緒に連結し、あらかじめ定義された通信プロトコルを形成し、および前記通信プロトコルを用いて前記通信路を介して、前記ホスト装置と前記クライアント装置との間であらかじめ選択されたセットのデジタル制御データおよびプレゼンテーションデータを通信する、前記ホスト装置内に配置された少なくとも１つのホストリンクコントローラ；
前記通信路を介して前記ホストリンクコントローラに接続され、前記クライアント装置内に配置された少なくとも１つのクライアントコントローラ；および
各リンクコントローラは、前記通信プロトコルを形成するパケットを発生し、送信し、および受信し、１つ以上のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される。
【請求項５２】
前記ホストコントローラはステートマシンを具備する、請求項５１の装置。
【請求項５３】
前記ホストコントローラは汎用シグナルプロセッサを具備する、請求項５１の装置。
【請求項５４】
前記パケットは、前記ホストと前記クライアントとの間の通信のために媒体フレーム内に一緒にグループ化され、所定数の前記パケットを有したあらかじめ定義された固定の長さを有する前記媒体フレームは異なるかつ可変の長さを持つ、請求項５１の装置。
【請求項５５】
前記ホストからパケットの転送の開始時にサブフレームヘッダタイプパケットをさらに具備する、請求項５１の装置。
【請求項５６】
前記リンクコントローラは、前記通信リンクを介して前記ホスト装置と前記クライアント装置との間で双方向に情報を転送するように構成される、請求項５１の装置。
【請求項５７】
前記クライアントコントローラは、前記クライアント装置に接続されるクライアント受信器を具備する、請求項５１の装置。
【請求項５８】
前記ホストコントローラは１つ以上の差動ラインドライバを具備し、前記クライアント受信器は前記通信路に接続された１つ以上の異なるライン受信器を具備する、請求項５７の装置。
【請求項５９】
クライアントユーザへのプレゼンテーションのために前記ホストから前記クライアントにデータを転送するとき、ビデオタイプデータに対してビデオストリームタイプパケットを、およびオーディオタイプに対してオーディオストリームタイプパケットをさらに具備する、請求項５１の装置。
【請求項６０】
前記クライアントから前記ホストにデータを転送するために１つ以上の逆方向リンクカプセル化タイプパケットをさらに具備する、請求項５１の装置。
【請求項６１】
前記インターフェースを介して、どんなタイプのデータおよびデータレートを前記クライアントが適合可能であるかを判断するように、前記ホストリンクコントローラは、前記クライアントからディスプレイ能力情報を要求するように構成される、請求項５１の装置。
【請求項６２】
クライアントリンクコントローラから前記ホストリンクコントローラへディスプレイ能力またはプレゼンテーション能力を通信するための少なくとも１つのディスプレイ能力タイプパケットをさらに具備する、請求項６１の装置。
【請求項６３】
前記通信路は、一連の４つ以上の導体および１つのシールドを持つケーブルを具備する、請求項５１の装置。
【請求項６４】
前記ケーブルは６つの導体と１つのシールドを具備する、請求項６３の装置。
【請求項６５】
前記ケーブルは８つの導体と１つのシールドを具備する、請求項６３の装置。
【請求項６６】
前記通信路は、４つの導体と、ＵＳＢタイプインターフェースと、１つのシールドを具備するケーブルを具備する、請求項６３の装置。
【請求項６７】
前記ケーブル導体は各々、１０００フィートの長さごとに約１１０オームの抵抗を有し、約０．６６ｃの信号伝搬速度を有し、約８．０ナノ秒未満のケーブルを介した最大遅延を有するマルチストランドワイヤと１つのシールドを具備する、請求項６３の装置。
【請求項６８】
前記ホスト装置は無線通信装置を具備する、請求項５１の装置。
【請求項６９】
前記ホスト装置は、その中に無線モデムを配置したポータブルコンピュータを具備する、請求項５１の装置。
【請求項７０】
前記クライアント装置はポータブルビデオディスプレイを具備する、請求項５１の装置。
【請求項７１】
前記ポータブルビデオディスプレイはマイクロディスプレイデバイスを具備する、請求項７０の装置。
【請求項７２】
前記クライアントデバイスはポータブルオーディオプレゼンテーションシステムを具備する、請求項５１の装置。
【請求項７３】
前記ホストにより前記クライアント装置に転送されるマルチメディアデータを保持するためのデータストレージをさらに具備する、請求項５１の装置。
【請求項７４】
前記パケットは各々、パケットレングスフィールド、１つ以上のパケットデータフィル−ド、および巡回冗長検査フィールドを具備する、請求項５１の装置。
【請求項７５】
前記ホストおよび前記クライアントリンクコントローラは、各方向に複数の転送モードの１つを使用するように構成され、各転送モードは、所定の時間期間、異なる最大数のビットのデータを並列に転送することを可能とし、データの転送中、前記転送モード間で動的に調節可能なように構成される、請求項５１の装置。
【請求項７６】
カラーマップタイプパケット、ビットブロックトランスファータイプパケット、ビットマップエリアフィルタイプパケット、ビットマップパターンフィルタイプパケット、およびトランスペアレントカラーイネーブルタイプパケットのグループから選択されたビデオ情報を転送するために１つ以上の複数のパケットをさらに具備する、請求項５１の装置。
【請求項７７】
データを有さない順方向リンク送信の期間を占有するために前記ホストにより転送するためのフィラータイプパケットをさらに具備する、請求項５１の装置。
【請求項７８】
前記クライアント装置に関連したユーザ入力装置へまたはユーザ入力装置からデータを転送するためのキーボードデータタイプパケットおよびポインティングデバイスデータタイプパケットをさらに具備する、請求項５１の装置。
【請求項７９】
前記通信路を介していずれかの方向でのデータの転送を終了するために、前記ホストコントローラは、前記クライアント装置にリンク中止タイプパケットを送信するように構成される、請求項５１の装置。
【請求項８０】
ユーザへのプレゼンテーションのために、通信路を介して、ホスト装置とクライアント装置との間で高レートでデジタルデータを転送するための電子システムに使用するために、下記を具備する、コンピュータプログラムプロダクト：
アプリケーションプログラムをコンピュータシステム上で実行させるために媒体内に具現化されたコンピュータ読取り可能なプログラムコード手段を持つコンピュータ使用可能な媒体、前記コンピュータ読取り可能なプログラムコード手段は下記を具備する：
コンピュータシステムに、１つ以上の複数のあらかじめ定義されたパケット構造を発生させ、それらを一緒に連結してあらかじめ定義された通信プロトコルを形成させる、コンピュータ読取り可能な第１のプログラムコード手段；
前記コンピュータシステムに、前記通信路を介して前記ホスト装置と前記クライアント装置との間であらかじめ選択されたセットのデジタル制御データおよびデジタルプレゼンテーションデータ通信させる、コンピュータ読取り可能な第２のプログラムコード手段；
前記コンピュータシステムに、前記通信路を介して、前記ホスト装置内に配置された少なくとも１つのホストリンクコントローラを、前記クライアント装置内に配置された少なくとも１つのクライアントコントローラと連結させる、コンピュータ読取り可能な第３のプログラムコード手段、前記リンクコントローラは、前記通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットにデジタルプレゼンテーションデータを形成するように構成される；および
前記コンピュータシステムに、前記リンクコントローラを用いて、前記通信路を介して、パケットの形態でデータを転送させる、コンピュータ読取り可能な第４のプログラムコード手段。
【請求項８１】
下記を具備する、ユーザへのプレゼンテーションのために、通信路を介してホスト装置とクライアント装置との間で高レートでデジタルデータを転送するための装置：
１つ以上の複数のあらかじめ定義されたパケット構造を発生し、それらを一緒に連結してあらかじめ定義された通信プロトコルを形成する手段；
前記通信プロトコルを用いて、前記通信路を介して、前記ホスト装置と前記クライアント装置との間あらかじめ選択されたセットのデジタル制御データおよびデジタルプレゼンテーションデータを通信する手段；
前記通信路を介して少なくとも２つのリンクコントローラを一緒に連結する手段、前記ホストとクライアントの各々に１つのりンクコントローラがあり、各リンクコントローラは、前記通信プロトコルを形成するパケットを発生し、送信し、受信し、１つ以上のタイプのデータパケットに、デジタルプレゼンテーションデータを形成するように構成される；および
前記リンクコントローラを用いて前記通信路を介してパケットの形態でデータを転送するための手段。
【請求項８２】
前記ホストとクライアントとの間の通信のために媒体フレーム内で前記パケットを一緒にグループ化するための手段をさらに具備し、所定数の前記パケットを有するあらかじめ定義された固定の長さを持つ媒体フレームは異なるかつ可変の長さを有する、請求項８１の装置。
【請求項８３】
サブフレームヘッダパケットを用いて、前記ホストからパケットの転送を開始する手段をさらに具備する、請求項８１の装置。
【請求項８４】
前記通信リンクを介して、前記ホストとクライアントとの間で双方向に情報を転送するための手段をさらに具備する、請求項８１の装置。
【請求項８５】
第１のリンクコントローラは前記ホスト装置に接続されたホストコントローラを具備し、第２のリンクコントローラは前記クライアント装置に接続されたクライアント受信器を具備する、請求項８１の装置。
【請求項８６】
前記ホストコントローラは１つ以上の異なるラインドライバを具備し、前記クライアント受信器は前記通信路を介して接続された１つ以上の異なるライン受信器を具備する、請求項８５の装置。
【請求項８７】
ビデオタイプデータのための１つ以上のビデオストリームタイプパケットおよびオーディオタイプデータのための１つ以上のオーディオストリームタイプパケットを用いて、クライアントへのプレゼンテーションのために前記ホストから前記クライアントにデータを転送するための手段をさらに具備する、請求項８１の装置。
【請求項８８】
１つ以上の逆方向リンクカプセル化タイプパケットを用いて前記クライアントから前記ホストにデータを転送するための手段をさらに具備する、請求項８１の装置。
【請求項８９】
前記インターフェースを介してどんなタイプのデータおよびデータレートを前記クライアントが適合できるかを判断するためにホストリンクコントローラにより前記クライアントからディスプレイ能力情報を要求する手段をさらに具備する、請求項８１の装置。
【請求項９０】
少なくとも１つのディスプレイ能力タイプパケットを用いてクライアントリンクコントローラからホストリンクコントローラにディスプレイまたはプレゼンテーション能力を通信する手段をさらに具備する、請求項８９の装置。
【請求項９１】
前記通信路は一連の４つ以上の導体と１つのシールドを有するケーブルを具備する、請求項８１の装置。
【請求項９２】
前記通信路の一部として前記リンクコントローラの各々によりＵＳＢデータインターフェースを操作するための手段をさらに具備する、請求項８１の装置。
【請求項９３】
前記ホストは無線通信装置を具備する、請求項８１の装置。
【請求項９４】
前記ホストは、その中に無線モデムを配置したポータブルコンピュータを具備する、請求項８１の装置。
【請求項９５】
前記クライアント装置はポータブルビデオディスプレイを具備する、請求項８１の装置。
【請求項９６】
前記ポータブルビデオディスプレイはマイクロディスプレイデバイスを具備する、請求項９５記載の装置。
【請求項９７】
前記クライアント装置はポータブルオーディオプレゼンテーションシステムを具備する、請求項８１の装置。
【請求項９８】
前記ホストにおいて、前記クライアントに転送されるマルチメディアデータを記憶する手段をさらに具備する、請求項８１の装置。
【請求項９９】
前記パケットは各々、パケットレングスフィールド、１つ以上のパケットデータフィールドとおよび巡回冗長検査フィールドとを具備する、請求項８１の装置。
【請求項１００】
前記ホストと前記クライアントリンクドライバとの間で、各方向において複数の転送モードの１つの使用をネゴシエートし、複数の転送モードの各々は、所定時間期間にわたって異なる最大数のビットデータを並列に転送することを可能にする手段；および
データの転送中に前記転送モード間を動的に調節する手段をさらに具備する、請求項８２の装置。
【請求項１０１】
カラーマップタイプパケット、ビットブロックトランスファータイプパケット、ビットマップエリアフィルタイプパケット、ビットマップパターンフィルタイプパケット、およびトランスペアレントカラーイネーブルタイプパケットのグループから選択されるビデオ情報を転送するために１つ以上の複数のパケットを使用するための手段をさらに具備する、請求項８１の装置。
【請求項１０２】
データを有さない順方向リンク送信の期間を占有するために前記ホストにより発生されたフィラータイプパケットを発生する手段をさらに具備する、請求項８１の装置。
【請求項１０３】
ユーザ定義されたストリームタイプパケットを用いてインターフェース−ユーザ定義されたデータを転送する手段をさらに具備する、請求項８１の装置。
【請求項１０４】
キーボードデータタイプパケットとポインティングデバイスデータタイプパケットを用いて前記クライアント装置に関連するユーザ入力装置にまたはユーザ入力装置からデータを転送するための手段をさらに具備する、請求項８１の装置。
【請求項１０５】
前記ホストにより、前記クライアントに転送するためのリンク停止タイプパケットを用いて、前記通信路を介していずれかの方向にデータの転送を終了する手段をさらに具備する、請求項８１の装置。
【請求項１０６】
通信路を介してホスト装置とクライアント装置との間で高レートでデジタルデータを転送するための電子システムに使用するプロセッサであって、前記プロセッサは、１つ以上の複数のあらかじめ定義されたパケット構造を発生し、それらを一緒に連結しあらかじめ定義された通信プロトコルを形成し；１つ以上のタイプのパケットにデジタルプレゼンテーションデータを形成し；前記通信プロトコルを用いて、前記通信路を介して前記ホストと前記クライアントとの間であらかじめ選択されたセットのデジタル制御データおよびデジタルプレゼンテーションデータを通信し；および前記通信路を介してデータをパケットの形態に転送するように構成される。
【請求項１０７】
通信路を介してホスト装置とクライアント装置との間で高レートでデジタルデータを転送する電子システムにおいて同期を取るために使用するステートマシンであって、前記ステートマシンは少なくとも１つの非同期フレームステート同期状態、少なくとも２つの獲得同期ステート同期状態、および少なくとも３つの同期ステート同期状態を有するように構成される。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
［０００１］この発明は、高いデータレートで、ホスト通信装置とクライアントオーディオ／ビジュアル表示装置との間の通信信号のためのデジタル信号プロトコルおよびプロセスに関する。特に、この発明は、無線装置からマイクロディスプレイユニットまたは低電力高データレート転送機構を用いた他の表示装置に、マルチメディアおよび他の種類のデジタル信号を転送するための技術に関する。
【０００２】
【関連出願の記載】
［０００２］コンピュータ、電子ゲーム関連製品、および種々のビデオ技術（例えばＤＶＤ’ｓおよび高解像度ＶＣＲｓ）はこの数年ますます進化し、ある種のテキストを含むときでさえも、ますますより高い分解能の静止画像、ビデオ画像、ビデオオンデマンド画像およびグラフィック画像をそのような機器のエンドユーザに供給している。これらの進歩は次に、高解像度のビデオモニタ、ＨＤＴＶモニタ、または専門の画像プロジェクションエレメントのようなより高い分解能の電子表示装置の使用を要求した。そのようなビジュアル画像を、ＣＤタイプの音響再生、ＤＶＤｓ、および関連したオーディオ信号出力を有する他の装置のような高解像度または高品質のオーディオデータとの結合は、エンドユーザに対して、より現実的な、内容の豊富な、真のマルチメディア体験を作るために使用される。さらにＭＰ３プレイヤーのような高度に移動性のある、高品質音響システムおよび音楽駆動機構がエンドユーザに対するオーディオのみの提示のために開発された。
【０００３】
［０００３］一般的なビデオ表示シナリオにおいて、ビデオデータは、毎秒１キロビット乃至１０キロビットのオーダである、遅い速度あるいは中間の速度と呼んだほうがよい速度で現在の技術を用いて一般に転送される。次に、このデータは、所望の表示装置上での遅延された（後の）演奏のために、一時的なまたは長期のメモリ装置にバッファリングまたは記憶される。例えば、画像をデジタル的に表すのに有用なデータを送受信するために、モデムまたはインターネット接続装置を有するコンピュータ上に存在するプログラムを用いて、インターネットを通じまたは用いて転送してもよい。同様の転送は、無線モデムを備えたポータブルコンピュータ、無線パーソナルデジタルアシスタンツ（ＰＤＡｓ）、または無線電話のような無線装置を用いて生じることができる。
【０００４】
［０００４］受信すると、データは、再生のために、外部記憶装置を含む、ＲＡＭまたはフラッシュメモリのようなメモリ素子、メモリ回路またはメモリ装置に局所的に記憶される。データ量および画像の分解能に応じて、再生は相対的に早く始まるかもしれないし、またはより長い期間の遅延を有して表示されるかもしれない。すなわち、ある場合に、画像表示は、多くのデータを必要としない、すなわちある種のバッファリングを用いた、非常に小さいまたは低い分解能画像に対してある程度のリアルタイムな再生を可能にさせるので、小さな遅延の後で、より多くの材料を転送しながら、いくらかの材料が表示される。転送リンクに障害が無ければ、一度表示が始まると、その転送は、表示装置のエンドユーザに合理的にトランスペアレントである。
【０００５】
［０００５］静止画または動画ビデオを作るために使用されるデータは、メディア産業、コンピュータ産業、および通信産業が通信リンクを介してデータの転送速度を高めるために、ジョイントフォトグラフィックイクスパーツグループ（ＪＰＥＧ）、モーションピクチャイクスパーツグループ（ＭＰＥＧ）、および他の良く知られた標準組織または会社により仕様が定められた技術のようないくつかの良く知られた技術の１つを用いて、しばしば圧縮される。これは、所定量の情報を転送するために、より小さな数のビットを用いて画像またはデータをより高速に転送することを可能にする。
【０００６】
［０００６］一度データが、コンピュータまたは他の装置のような「ローカル」な装置に転送されると、結果として生じる情報は、非圧縮化（または特殊な復号プレーヤを用いて演奏）され、対応する利用可能な表示分解能と制御エレメントに基づいて適当な表示のために作成される。例えば、Ｘ×Ｙ画素のスクリーン分解能に関して典型的なコンピュータビデオ分解能は、４８０×６４０の低い分解能から、中間値が６００×８００であり、最大１０２４×１０２４までの範囲である。しかしながら、所望に応じてまたは必要に応じて種々の他の分解能が一般的に可能である。
【０００７】
［０００７］画像表示は、画像の内容および、ある所定の色レベルまたは色の深み（色を発生するために使用されるピクセルあたりのビット）および輝度、および採用されるオーバーヘッドビットの観点から画像を操作するための所定のビデオコントローラの能力によっても影響される。例えば、典型的なコンピュータ表示は、他の値の場合もあるけれども、種々の色（陰影および色相）を表すためにピクセルあたり約８ビット乃至３２ビットまたはそれ以上のビット数からどれかの値を予想するであろう。
【０００８】
［０００８］上の値から、所定のスクリーン画像は、それぞれ最も低い典型的な分解能および深さから最も高い典型的な分解能および深さのレンジに対して２．４５メガビット（Ｍｂ）乃至約３３．５５Ｍｂのデータからのいずれかの転送を必要とすることがわかる。毎秒３０フレームのレートでビデオタイプの画像または動画タイプの画像を見ると、必要となるデータ量は毎秒約７３７メガビット乃至１００６メガビットのデータ（Ｍｂｐｓ）、すなわち毎秒約９．２１メガバイト乃至１２５．７５メガバイト（ＭＢｐｓ）である。さらに、人は、マルチメディアプレゼンテーションのような、またはＣＤ品質の音楽のような、別個の高い分解能のオーディオプレゼンテーションのようなオーディオデータを画像とともに提示したいと思うかもしれない。インタラクティブコマンド、制御、または信号を処理するさらなる信号も使用されるかもしれない。これらの選択肢のいずれも、転送すべきより多くのデータを増やす。内容の豊富な体験をさせるために、エンドユーザに高品質または高分解能の画像データおよび高品質のオーディオ情報またはデータ信号を転送したいとき、プレゼンテーションエレメントと、そのようなタイプのデータを提供するように構成されたソースまたはホスト装置との間に高データ転送レートリンクが必要である。
【０００９】
［０００９］毎秒約１１５キロバイト（ＫＢｐｓ）または毎秒９２０キロビット（Ｋｂｐｓ）は通常現代のシリアルインタフェースにより取り扱うことができる。ＵＳＢシリアルインタフェースのような他のインタフェースは、１２ＭＢｐｓのレートでデータ転送に適応させることができ、インスティチュート  オブ  エレクトリカル  アンド  エレクトロニクス  エンジニアズ（ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）（ＩＥＥＥ）１３９４標準を用い構成された転送のような、専門化した高速転送は、５０乃至１００ＭＢｐｓのオーダーのレートで生じることができる。残念ながら、これらのレートは、ポータブルビデオディスプレイまたはオーディオ装置を駆動するための高分解能の、内容が豊富な、出力信号を供給するための将来の無線データ装置およびサービスに使用するものとして考えられる、上述した所望の高データレートには及ばない。さらに、これらのインタフェースは動作すべきかなりの量のホストまたはシステムソフトウエアおよびクライアントソフトウエアの使用が必要となる。それらのソフトウエアプロトコルスタックも望ましくない大量のオーバーヘッドを作る。特に、移動無線装置または移動無線電話のアプリケーションを考える場合にはそうである。さらに、これらのインターフェースのいくつかは、高度に美観が要求されるモバイルアプリケーションに対して、重すぎるかつ不満足なかさばったケーブルを使用するとともに、コストがかさむ複雑なコネクタを使用し、あるいは、単に大量の電力を消費する。
【００１０】
［００１０］アナログビデオグラフィックアレイ（Ａｎａｌｏｇ Ｖｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ）（ＶＧＡ）、デジタルビデオインタラクティブ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｉｎｔｅｒａｃｔｉｖｅ）（ＤＶＩ）、ギガビットビデオインタフェース（Ｇｉｇａｂｉｔ Ｖｉｄｅｏ Ｉｎｔｅｒｆａｃｅ）（ＧＶＩＦ）のような他の知られたインタフェースがある。これらのうちの最初の２つはより高い転送レートでデータを処理する並列タイプのインタフェースであるが、また重いケーブルを使用し、数ワットのオーダーの大量の電力を消費する。これらの特性のいずれも、携帯用の家庭用電子装置に使用するのに従順でない。第三のインタフェースでさえも大量の電力を消費し、高価でかさばったコネクタを使用する。
【００１１】
［００１１］上述したインタフェースのいくつかおよび他の非常に高いレートのデータシステム／プロトコルまたは固定据付されたコンピュータ機器のためのデータ転送に関連した転送機構についてもう一つの主要な欠点がある。所望のデータ転送レートに適応させることはまた相当量の電力を必要とし、および／または高電流レベルでの動作を必要とする。これは、高度に移動性のある家庭用志向の製品に対してそのような技術の有用性を大幅に低減する。
【００１２】
［００１２］一般的に、例えば光ファイバタイプの接続と転送素子のような代替物を用いてそのようなデータ転送レートに適合させることも、多数のさらなる変換器および素子を必要とし、真に商業的な家庭用志向の製品に対して望まれている複雑さと価格よりもさらに高度に複雑で高価となる。光システムの、今のところはまだ一般的に高価な性質は別として、それらの電力要件と複雑さが、軽量、低電力でポータブルなアプリケーションに一般に使用するのを妨げている。
【００１３】
［００１３］ポータブルアプリケーションまたはモバイルアプリケーションのための産業に欠けているものは、それがオーディオであれ、ビデオであれ、またはマルチメディアに基づくものであれ、高度にモバイルなエンドユーザに対して、高品質のプレゼンテーション体験を供給することである。すなわち、ポータブルコンピュータ、無線電話、ＰＤＡｓ、他の高度にモバイルな通信装置または機器を使用するとき、現在使用されているビデオおよびオーディオプレゼンテーションシステムまたは装置は、どうしても所望の高い品質レベルで出力を供給することができない。今不足している品質で感知できる品質は、高品質のプレゼンテーションデータを転送するのに必要な、入手できない高いデータレートの結果である。それゆえ、データを供給するホスト装置と、エンドユーザに出力を提示するクライアント表示装置または表示素子との間のデータスループットを高めるために新しい転送機構が必要である。
【００１４】
【課題を解決するための手段】
［００１４］技術的に実在する上述の欠点および他のものは、高いデータレートで、ホスト装置と受信者のクライアント装置との間でデータを転送するために、新しいプロトコルおよびデータ転送機構が開発されたこの発明の実施の形態により解決される。
【００１５】
［００１５］この発明の実施の形態の利点は、高い柔軟性を維持しながら、複雑さの度合いが低く、廉価で、信頼度が高く、使用環境内で良く適合し、非常に堅固なデータ転送のための技術が供給されることである。
【００１６】
［００１６］この発明の実施の形態は、ホスト装置とクライアント装置との間のあらかじめ選択されたセットのデジタル制御データおよびプレゼンテーションデータを通信するための通信プロトコルを形成するために一緒に接続された複数のまたは一連のパケット構造を採用する通信路を介してホスト装置とクライアント装置との間で、高レートでデジタルデータを転送するための移動デジタルデータインタフェース（ＭＤＤＩ）に向けられている。信号通信プロトコルまたはリンク層は、ホストまたはクライアントのリンクコントローラの物理層により使用される。ホスト装置内に存在する少なくとも１つのリンクコントローラが通信路または通信リンクを介してクライアント装置に接続され、通信プロトコルを形成するパケットを発生し、送信し、受信するように構成され、および１つ以上のタイプのデータパケット内にデジタルプレゼンテーションデータを形成するように構成される。このインタフェースはホストとクライアントの間で情報の双方向の転送を供給する。
【００１７】
［００１７］この発明の実施の形態のさらなる観点において、少なくとも１つのクライアントリンクコントローラ、またはクライアント受信器がクライアント装置に配置され、通信路または通信リンクを介してホスト装置に接続される。クライアントリンクコントローラはまた通信プロトコルを形成するパケットを発生し、送信しおよび受信するように構成され、および１つ以上のタイプのデータパケット内にデジタルプレゼンテーションデータを形成するように構成される。一般に、ホストまたはリンクコントローラはコマンド内で使用されるデータパケットを処理するため、またはあるタイプの信号作成および問合せ処理のためにステートマシンを採用するが、その通信プロトコル内で使用されるデータおよびいくつかのより複雑でないパケットを操作するためにより遅い汎用のプロセッサを用いることができる。ホストコントローラは１つ以上の異なるラインドライバから構成され、クライアント受信器は通信路に接続された１つ以上の異なるライン受信器から構成される。
【００１８】
［００１８］パケットは、異なる可変長を持つ所定数のパケットを有する所定の固定長を持つ、ホスト装置とクライアント装置との間で通信される、メディアフレーム内で一緒にグループ化される。パケットは各々、パケット長フィールド、１つ以上のパケットデータフィールド、および巡回冗長検査フィールドから構成される。サブフレームヘッダーパケットは、ホストリンクコントローラからの他のパケットの転送の開始時に転送されまたは適当な位置に置かれる。クライアント装置のユーザに提示するために、順方向リンクを介してホストからクライアントに、それぞれビデオタイプデータとオーディオタイプデータを転送するための通信プロトコルにより１つ以上のビデオストリームタイプパケットと、オーディオストリームタイプパケットが使用される。クライアント装置からホストリンクコントローラにデータを転送するための通信プロトコルによりカプセル化タイプのパケットが使用される。
【００１９】
［００１９］フィラータイプパケットは、データを持たない順方向リンク送信の期間を占有するためにホストリンクコントローラにより発生される。複数の他のパケットは、ビデオ情報を転送するために通信プロトコルにより使用される。そのようなパケットは、カラーマップ（Ｃｏｌｏｒ Ｍａｐ）タイプパケット、ビットブロックトランスファー（Ｂｉｔ Ｂｌｏｃｋ Ｔｒａｎｓｆｅｒ）タイプパケット、ビットマップエリアフィル（Ｂｉｔｍａｐ Ａｒｅａ Ｆｉｌｌ）タイプパケット、ビットマップパターンフィル（Ｂｉｔｍａｐ Ｐａｔｔｅｒｎ Ｆｉｌｌ）タイプパケットおよびトランスペアレントカラーイネーブル（Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｌｏｒ Ｅｎａｂｌｅ）タイプパケットを含む。ユーザ定義ストリームタイプパケットは、インタフェースユーザにより定義されたデータを転送するために通信プロトコルにより定義される。キーボードデータおよびポインティングデバイスデータタイプパケットは、前記クライアント装置に関連するユーザ入力装置にデータを転送するまたはユーザ入力装置からデータを転送するために通信プロトコルにより使用される。リンクシャットダウンタイプパケットは、前記通信路を介していずれかの方向におけるデータの転送を終了するために通信プロトコルにより使用される。
【００２０】
［００２０］通信路は一般に、一連の４つ以上のコンダクタおよび１つのシールドを有するケーブルから構成されるまたはケーブルを用いる。ある実施の形態において、リンクコントローラはＵＳＢデータインタフェースから構成され、ケーブルは他のコンダクタとともにＵＳＢタイプのインタフェースを使用する。さらに、必要に応じて、印刷配線またはフレキシブルコンダクタを使用することができる。
【００２１】
［００２１］ホストリンクコントローラは、前記クライアントが前記インタフェースを介してどんなタイプのデータおよびどのデータレートに適応することが出来るかを判断するためにクライアント装置から表示能力情報を要求する。クライアントリンクコントローラは、少なくとも１つの表示能力タイプパケットを用いてホストリンクコントローラに表示能力またはプレゼンテーション能力を通信する。複数の転送モードが通信プロトコルにより使用され、各転送モードは、所定の時間期間、異なる最大数のビットのデータを並列に転送することを可能にし、各モードはホストリンクコントローラとクライアントリンクコントローラとの間のネゴシエーションにより選択可能である。これらの転送モードは、データの転送の期間動的に調節可能であり、順方向リンクに使用されているモードと同じモードを逆方向リンクに使用する必要はない。
【００２２】
［００２２］この発明のある実施の形態の他の観点において、ホスト装置は、無線電話、無線ＰＤＡ、またはその中に配置された無線モデムを有するポータブルコンピュータのような無線通信装置から構成される。典型的なクライアント装置は、μディスプレイ装置および／またはポータブルオーディオプレゼンテーションシステムのようなポータブルビデオディスプレイから構成される。さらに、ホストは、クライアント装置のユーザに提示するために転送されるプレゼンテーションデータまたはマルチメディアデータを記憶するための記憶手段または記憶素子を使用してもよい。
【００２３】
【発明の実施の形態】
［００２３］この発明のさらなる特徴および利点並びにこの発明の種々の実施の形態の構造および動作は添付した図面を参照して以下に詳細に記載される。図面において、同じ参照番号は一般に、同一のエレメントまたは処理ステップ、機能的に類似したエレメントまたは処理ステップおよび／または構造的に類似したエレメントまたは処理ステップを示し、エレメントが最初に現われる図面は、参照番号の一番左の桁により示される。
【００２４】
１．概要
［００８１］この発明の一般的な意図は、以下に述べるように、「シリアル」タイプのデータリンクまたはチャネルを用いて、ホスト装置と表示装置との間の短距離通信リンクを介して高速のまたは非常に高速のデータ転送を可能にする、費用対効果の良い、低電力消費の、転送機構を生じるまたは供給する移動表示デジタルインタフェース（ＭＤＤＩ）を供給することである。この機構は、身につけられるマイクロディスプレイ（ゴーグルまたはプロジェクタ）のような表示素子または表示装置を、ポータブルコンピュータ、無線通信装置、または娯楽装置に接続するのに特に有用な小型のコネクタおよび薄い柔軟性のあるケーブルを用いて実現するのに適している。
【００２５】
［００８２］この発明は大量のデータ、一般には、オーディオ、ビデオ、またはマルチメディアアプリケーション用のデータを、そのようなデータが発生されまたは記憶されるホスト装置またはソース装置から、クライアントのディスプレイまたはプレゼンテーション装置に、高速に通信または転送するための種々の状況に使用することができる。以下に述べる典型的なアプリケーションは、ポータブルコンピュータまたは無線電話またはモデムから、ゴーグルの形態、または小型の投影レンズおよびスクリーンを含むヘルメットの形態のような、小型のビデオスクリーンまたは身につけられるマイクロディスプレイ装置のようなビジュアル表示装置にデータを転送することである。
【００２６】
［００８３］ＭＤＤＩの特性または属性は、特定の表示技術に無関係であるということである。これはデータの内部構造に関係なく、かつ機構が実行するデータまたはコマンドの機能的側面に関係無く、データを転送するための高度に柔軟性のある機構である。これは転送されるデータパケットのタイミングを、特殊な表示装置の特異な性格、またはある装置に対する固有の表示願望に適合するように、またはあるＡ−Ｖシステムのための組み合わされたオーディオとビデオの要件に適合するように調節可能にする。このインタフェースは、選択されたプロトコルを遵守する限り、まさに表示素子であり、またはクライアント装置は寛容である。さらに、総計のシリアルリンクデータまたはデータレートは、通信システムまたはホスト装置の設計者が、コスト、電力要件、クライアント装置の複雑性、および表示装置更新レートを最適にすることを可能にするいくつかのオーダーの重要性に対して変化することができる。
【００２７】
［００８４］データインタフェースは、「有線」の信号リンクまたは小型のケーブルを介して大量の高速データを送信するのに主に存在している。しかしながら、いくつかのアプリケーションは、そのインターフェースに対して開発された同じパケットとデータ構造を用いるように構成され、十分に低い電力消費または実用的な複雑さで所望のレベルの転送を支持することができるなら、光学ベースリンクを含む、無線リンクも同様にうまく利用してもよい。
【００２８】
２．環境
［００８５］典型的なアプリケーションを図１ａおよび１ｂに見ることができる。ここでは、ポータブルまたはラップトップコンピュータ１００と無線電話またはＰＤＡ装置１０２が、オーディオ再生システム１０８および１１０と共にそれぞれ、表示装置１０４および１０６とデータを通信しているのが見られる。無線装置は現在データを受信することができる、または、無線装置のエンドユーザが後で見たり聞いたりするために後のプレゼンテーションのためにメモリ素子またはメモリ装置にある量のマルチメディアタイプのデータを前もって記憶させることができる。典型的な無線装置は、大体の場合、音声および簡単なテキスト通信に使用されるので、情報を装置１０２のユーザに通信するためにどちらかというと小型のディスプレイスクリーンと簡単なオーディオシステム（スピーカ）を有する。
【００２９】
［００８６］コンピュータはより大きなスクリーンを有するが、依然として不適当な外部サウンドシステムを有し、高品位テレビジョンまたは映画スクリーンのような他のマルチメディアプレゼンテーション装置には及ばない。コンピュータはイラストレーションのために使用され、他の種類のプロセッサ、インタラクティブビデオゲームまたは、家電電子装置もこの発明とともに使用することができる。コンピュータ１００は、これに限定されるわけではないが、無線通信のために無線モデムまたは他の内蔵装置を採用することができ、または必要に応じて、ケーブルまたは無線リンクを用いてそのような装置と接続することができる。
【００３０】
［００８７］これは、より複雑なまたは「豊富」なデータのプレゼンテーションを、有用なまたは楽しい体験よりも少なくする。それゆえ、業界はその情報をエンドユーザに提示し、最小レベルの所望の楽しみまたは有意義な体験を供給するための他の機構および装置を開発しつつある。
【００３１】
［００８８］上述したように、いくつかのタイプの表示装置は、現在装置１００のエンドユーザに情報を提示するために開発されつつある。例えば１つ以上の会社がビジュアルディスプレイを提示するために装置ユーザの眼の前に画像を投影する身につけるゴーグルのセットを開発した。正しく位置されると、そのような装置は、そのエレメントがビジュアル出力を供給するよりもより大きく、ユーザの眼により知覚されるように効果的に仮想イメージを「投影」する。すなわち非常に小さな投影エレメントは、ユーザの眼が典型的なＬＣＤスクリーン等を用いて可能なより大きな画像で「見る」ことを可能にする。より仮想スクリーン画像の使用は、恐らくより制限されたＬＣＤスクリーンディスプレイを用いて分解能画像よりも非常に高い分解能画像の使用を可能にする。他の表示装置を含めることもできるが、小型のＬＣＤスクリーンまたは種々のフラットパネルディスプレイエレメント、投影レンズ、および表面に画像を投影するための表示ドライバ等に限定されない。
【００３２】
［００８９］また、出力を他のユーザに提示し、または信号をどこかに転送するまたは記憶する他の装置に提示するための無線装置１０２またはコンピュータ１００の使用に接続されたまたは関連したさらなるエレメントがあってもよい。例えば、データは後の使用のために、書き込み可能なＣＤ媒体または磁気テープレコーダまたは同様の装置のような磁気媒体を用いてデータを光学形式でフラッシュメモリに記憶してもよい。
【００３３】
［００９０］さらに、多くの無線装置およびコンピュータは現在内蔵のＭＰ３音楽復号能力並びに他の進歩した音響デコーダおよびシステムを有する。ポータブルコンピュータは一般的な法則として、ＣＤおよびＤＶＤ再生能力を利用し、いくつかは、あらかじめ記憶されたオーディオファイルを受信するための小型の専用フラッシュメモリーダーを有する。そのような能力を有する問題点は、復号処理と再生処理が歩調を合わせることが出来る場合にのみ、デジタルミュージックファイルは高度に増大した特長および豊富な体験を約束するということである。デジタルビデオファイルに対しても同じことが言える。
【００３４】
［００９１］音の再生を補助するために、外部スピーカ１０８が図１ａに示される。このスピーカは、またサブウーファ、または前方および後方の音の投射のために「サラウンドサウンド」スピーカのようなさらなるエレメントを伴っても良い。同時に、図１Ｂのマイクロディスプレイデバイス１０６の支持フレームまたは機構にスピーカまたはイヤホン１１０が内蔵するように示される。知られているように、電力増幅装置またはサウンド整形装置を含む他のオーディオまたはサウンド再生エレメントを使用することができる。
【００３５】
［００９２］いずれにせよ、上述したように、高品質のまたは高分解能の画像データおよび高品質のオーディオ情報またはデータソースからのデータ信号を１つ以上の通信リンク１１２を介して転送することを所望するとき、高データレートが必要である。すなわち、転送リンク１１２は明らかに上述したようにデータの通信において、潜在的なボトルネックであり、システム性能を制限している。これは、現在の転送機構が典型的に所望の高データレートを達成しないからである。例えば、上述したように、１０２４×１０２４ピクセルのようなより高い分解能を有し、ピクセルあたり２４乃至３２ビットの色の深みを有し、３０ｆｐｓのデータレートの場合、データレートは、３３６Ｍｂｐｓ以上のレートに近づくことができる。さらに、そのような画像はマルチメディアプレゼンテーションの一部として提示してもよい。マルチメディアプレゼンテーションは、オーディオデータ、およびインタラクティブゲームまたは通信、または品質、データおよびデータレートをさらに高める種々のコマンド、制御、または信号を処理する潜在的なさらなる信号を含む。
【００３６】
［００９３］また、データリンクを確立するために必要なケーブルまたは相互接続は少ないことはあきらかである。このことは、ディスプレイに関連する装置が使い易いことを意味し、より大きなユーザベースにより採用される可能性が高い。これは、特に、複数の装置がフルオーディオビジュアル体験を確立するために共通に使用される場合にそうであり、特に、ディスプレイとオーディオ出力装置の品質レベルが増大するときにそうである。
【００３７】
［００９４］残念ながら、より高いデータレートは、データを転送するために利用可能な現在の技術を越える。必要なことは、プレゼンテーションエレメントとデータソースとの間のデータ転送リンクまたは通信路に対してより高いレートでデータを転送するための技術である。この技術は常に低電力で、軽量で、できるだけシンプルで経済的なケーブル構造を可能にする。出願人達は、所望の低電力消費および複雑さを維持しながら、非常に高速に、移動装置、ポータブル装置または固定ロケーション装置のアレイが、所望のディスプレイ、マイクロディスプレイ、またはオーディオ転送エレメントにデータを転送可能にするために、これらのおよびその他の目標を達成するために、新しい技術、方法、および装置を開発した。
【００３８】
３．高レートデジタルデータインタフェースシステムアーキテクチャ
［００９５］新しい装置インターフェースを作り、効率的に利用するために、低電力信号を用いて非常に高いデータ転送レートを供給する信号プロトコルおよびシステムアーキテクチャが策定された。このプロトコルは、パケットおよび共通のフレーム構造、または一緒に組み合わされた構造群に基づき、そのインターフェースに課せられたコマンドまたは動作構造と共に、あらかじめ選択されたセットのデータまたはデータタイプを通信するためのプロトコルを形成する。
【００３９】
Ａ．概要
［００９６］ホストによりイネーブルとなるように、ＭＤＤＩリンクにより接続される装置またはＭＤＤＩリンクを介して通信する装置はホストおよびクライアントと呼ばれ、クライアントは典型的にはあるタイプの表示装置である。ホストからディスプレイへのデータは順方向（順方向トラヒックまたは順方向リンクと呼ぶ）に移動し、ディスプレイからホストへのデータは逆方向（逆方向トラヒックまたは逆方向リンクと呼ぶ）に移動する。これは図２にその基本構成が図解される。図２において、ホスト２０２は、順方向リンク２０８および逆方向リンク２１０からなるものとして図解される双方向通信チャネル２０６を用いてクライアント２０４に接続される。しかしながら、これらのチャネルは、データ転送が、順方向リンク動作と逆方向リンク動作との間で効果的に切り替えられる共通のセットのコンダクタにより形成される。
【００４０】
［００９７］他のどこかで記載したように、ホストは、この発明を用いることから恩恵を受けることができるいくつかのタイプの装置の１つから構成される。例えば、ホスト２０２は、ハンドヘルド、ラップトップ、または類似の移動計算装置の形態のポータブルコンピュータであり得る。ホスト２０２はＰＤＡ、ページング装置、または多くの無線電話または無線モデムの１つであり得る。同時に、クライアント２０４は、情報をエンドユーザに提示するために有用な種々の装置から構成可能である。例えば、ゴーグルまたはメガネに組み込まれたマイクロディスプレイ、帽子またはヘルメットに内蔵された投影装置、乗り物の例えば窓、フロントガラス、または種々のスピーカ、ヘッドホンまたは高品質のサウンドまたは音楽を提示するためのサウンドシステムに内蔵された小型のスクリーンまたはホログラフィックエレメントである。しかしながら、この発明は、これらの装置に限定されず、市場には、記憶および転送の観点からまたは再生において提示の観点から、エンドユーザに高品質の画像とサウンドを供給するように意図された、使用のために提案された多くの他の装置があることを当業者は、容易に認識するであろう。この発明は、所望のユーザ体験を実現するために必要な高データレートに適合するように種々の装置間でデータスループットを高めるのに有用である。
【００４１】
Ｂ．インタフェースタイプ
［００９８］ＭＤＤインターフェースは、通信業界およびコンピュータ業界において見出される、アドレス指定の５つ以上の多少識別可能な物理タイプのインターフェースとして検討される。これらは、現時点では、単にタイプ１、タイプ２、タイプ３、タイプ４およびタイプＵとしてラベルが付けられる。
【００４２】
［００９９］タイプ１インタフェースは６ワイヤ（コンダクタ）インターフェースとして構成され、携帯電話または無線電話、ＰＤＡｓ、ｅ−ＢＯＯＫ、電子ゲーム、およびＣＤプレーヤまたはＭＰ３プレーヤのようなポータブルメディアプレーヤおよび類似したタイプの電子家電技術に基づく装置に適している。タイプＵインタフェースは８ワイヤ（コンダクタ）インターェースとして構成され、ラップトップコンピュータ、ノートブックコンピュータ、またはデスクトップコンピュータ、およびディスプレイが急速に更新されることを必要としない類似の装置またはアプリケーションおよび内蔵ＭＤＤＩリンクコントローラを有さない類似の装置またはアプリケーションにより適している。このインターフェースタイプは、また、殆どのパーソナルコンピュータに見出される既存のオペレーティングシステムまたはソフトウエアに適応するのに極めて有用なさらなる２ワイヤユニバーサルシリアルバス（ＵＳＢ）の使用により区別可能である。タイプＵインタフェースはＵＳＢモードのみのモードで使用することもできる。この場合は、例えばディスプレイは、単に、コンピュータまたは同様の装置上の標準のＵＳＢポートに接続するＵＳＢコネクタを有している。
【００４３】
［０１００］タイプ２、タイプ３およびタイプ４インタフェースは高性能なディスプレイまたは装置に適しており、適当なシールディングおよびデータ信号のための低い損失転送を供給するためにさらなるツイストペアタイプコンダクタを有したより大きなより複雑なケーブルを使用する。
【００４４】
［０１０１］タイプ１インタフェースは、ディスプレイ情報、オーディオ情報、制御情報および制限されたシグナリング情報から構成することができ、典型的に高分解能フルレートビデオデータを必要としない装置のために使用される。このタイプのインターフェースは、接続と信号のために装置内でＵＳＢホストが典型的に利用できない、移動無線装置のような装置に対して主に意図されている。この構成において、移動装置は、ＭＤＤＩホスト装置であり、ホストからの通信リンクを制御する「マスタ」として動作し、一般的にディスプレイデータをクライアント（順方向トラヒックまたは順方向リンク）に送信する。
【００４５】
［０１０２］このインターフェースにおいて、ホストは、クライアントが特定の期間、バスの支配権を得ることを可能にし、逆方向パケットとしてデータをホストに送信するクライアントに特定のコマンドまたはパケットタイプを送信することによりクライアント（逆方向トラヒックまたは逆方向リンク）からホストでの通信データの受信をイネーブルにする。これは図３に図解され、カプセル化パケット（以下に記載する）と呼ばれるあるタイプのパケットを用いて、転送リンクを介して逆方向パケットの転送に適合し、逆方向リンクを作る。データのためにディスプレイをポーリングするためにホストに対して割当てられた時間間隔はホストによりあらかじめ決められており、各指定されたアプリケーションの要件に基づく。このタイプの半二重双方向データ転送は、クライアントからの情報またはデータの転送のためにＵＳＢポートが利用できない場合に特に利点がある。
【００４６】
［０１０３］多数の量のマザーボードまたは他のハードウエアにより、そしてオペレーティングシステムソフトウエアによりＵＳＢインターフェースが広範囲にサポートされる場合、タイプＵインターフェースは、ラップトップアプリケーションおよびデスクトップアプリケーションに使用するのによく適した信号を転送する。追加されたＵＳＢインターフェースの使用は、「プラグアンドプレイ」の特徴を有した使用、およびやさしいアプリケーション構成を可能にする。ＵＳＢを含めることはまた、コマンド、ステータス、オーディオデータ等の汎用の双方向の流れも可能とし、クライアント装置に向けられたビデオデータおよびオーディオデータは、低電力かつ高速に、ツイストペアを用いて転送可能である。電力は以下に記載するように他のワイヤを用いて転送可能である。ＵＳＢインタフェースを用いたこの発明の実施の形態は、使用していないときは活動を中断し、ほとんど電力を消費しない、ＵＳＢ接続上に主にシグナリングと制御を実現しながら、１つのセットのコンダクタを介して高速転送を可能にする。
【００４７】
［０１０４］ＵＳＢインターフェースは近代のコンピュータ機器に対して非常に広範囲に使用される標準であり、ＵＳＢインターフェースの詳細およびその動作は技術的に非常に良く知られており、ここでは説明しない。ＵＳＢインターフェースについて、ホストとディスプレイとの間の通信は、ユニバーサルシリアルバス仕様、改訂２．０に準拠する。ＵＳＢが主要なシグナリングチャネルおよび恐らくボイスリターンチャネルであるタイプＵインタフェースを用いたアプリケーションにおいて、ホストがＭＤＤＩシリアルデータ信号を介してクライアントをポーリングすることは任意的である。
【００４８】
［０１０５］ＨＤＴＶタイプまたは類似の高分解能が可能な高性能ディスプレイはフルモーションビデオをサポートするために約１．５Ｇｂｐｓレートデータストリームを必要とする。タイプ２インタフェースは２ビットを並列に送信することにより高データレートをサポートする。タイプ３は４ビットを並列に送信することにより高データレートをサポートする。タイプ４インタフェースは８ビットを並列に送信することにより高データレートをサポートする。ＭＤＤＩにより使用されるプロトコルは、何が最も高い使用できる可能なデータレートであるかをネゴシエートすることにより、タイプ１、タイプ２、タイプ３またはタイプ４のホストがいずれかのタイプ１、タイプ２、タイプ３またはタイプ４のクライアンまたはディスプレイと通信することを可能にする。一番性能が悪い装置と呼ばれるものの能力または利用できる特徴を用いて、リンクの性能が設定される。原則として、ホストとクライアントが両方ともタイプ２、タイプ３またはタイプ４インターフェースを用いて動作できるシステムの場合であっても、両方は、タイプ１インタフェースとして動作を開始する。次に、ホストは目標のクライアントまたはディスプレイの能力を決定し、特定のアプリケーションに対して適当であるタイプ２、タイプ３またはタイプ４のモードへのハンドオフまたは再構成動作をネゴシエートする。
【００４９】
［０１０６］一般にホストが適当なリンクレイヤプロトコル（さらに以下に記載する）を使用することは可能である。そして、いつでも、電力を節約するために、より遅いモードにステップダウンまたは動作を再構成することができ、あるいは、より高い分解能の表示コンテンツのようなより高速な転送をサポートするためにより早いモードにステップアップすることができる。例えば、ディスプレイシステムが、バッテリのような電源からＡＣ電源に切替えた時、またはディスプレイメディアのソースがより低いまたはより高い分解能のフォーマットに切替えた時、あるいは、これらの組合せまたは他の条件またはイベントが、ディスプレイまたはデータ転送モードを変更する基礎として考えることができるとき、ホストはディスプレイモードを変えることができる。
【００５０】
［０１０７］また、一方の方向において、一方のモードを使用し、他方の方向において、他方のモードを使用してデータを通信するシステムにも可能である。例えば、タイプ４インタフェースモードは高速にデータをディスプレイに転送するために使用することができ、一方、タイプ１またはタイプＵモードは、キーボードまたはポインティングデバイスのような周辺装置からホストデバイスにデータを転送するとき使用される。
【００５１】
Ｃ．物理インタフェース構造
［０１０８］ホスト装置とクライアント装置との間に通信を確立するための装置またはリンクコントローラの一般的配置が図４および図５に示される。図４および図５において、ＭＤＤＩリンクコントローラ４０２はホスト装置２０２にインストールされるように示され、ＭＤＤＩリンクコントローラ４０４はクライアント装置２０４にインストールされるように示される。既に述べたように、ホスト２０２は一連のコンダクタからなる双方向通信チャネル４０６を用いてクライアント２０４に接続される。以下に記載するように、ホストリンクコントローラとクライアントリンクコントローラは共に、ホストコントローラ（ドライバ）またはクライアントコントローラ（受信器）として応答するように設定され、調節されまたはプログラム可能である、単一回路設計を用いて集積回路として製造可能である。これは、単一回路装置のより大きなスケールの製造によりより低いコストを供給する。
【００５２】
［０１０９］図４において、ＵＳＢホスト装置４０１およびＵＳＢクライアント装置４１０は、ＭＤＤＩのタイプＵインタフェースバージョンを実現するのに使用するためにも示される。そのような機能を実現するための回路および装置は技術的に知られており、ここではさらに詳細に記載しない。
【００５３】
［０１１０］図５において、ＭＤＤＩリンクコントローラ５０２は、ホスト装置２０２’にインストールされるように示され、ＭＤＤＩリンクコントローラ５０４は、クライアント装置２０４’にインストールされるように示される。既に述べたように、ホスト２０２’は、一連のコンダクタから構成される双方向通信チャネル５０６を用いてクライアント２０４’に接続される。上述したように、ホストリンクコントローラとクライアントリンクコントローラは共に単一の回路設計を用いて製造可能である。
【００５４】
［０１１１］ＭＤＤＩリンクを介して、または使用される物理コンダクタを介して、ホストと、表示装置のようなクライアントとの間でやりとりされる信号も図４および図５に図解される。図４および図５からわかるように、ＭＤＤＩを介してデータを転送するための主な経路または機構は、ＭＤＤＩ＿Ｄａｔａ０＋／−およびＭＤＤＩ＿Ｓｔｂ＋／−としてラベルが付けられたデータ信号を使用する。これらの各々は、ケーブル内の異なるワイヤのペアを介して転送される低電圧データ信号である。インターフェースを介して送信された各ビットに対して、ＭＤＤＩ＿Ｄａｔａ０ペアまたはＭＤＤＩ＿Ｓｔｂペア上に１つだけの遷移がある。これは、電流ベースではなく、電圧ベースの転送機構であり、従って、静止電流消費は殆どゼロである。ホストは、クライアントディスプレイへのＭＤＤＩ＿Ｓｔｂ信号を駆動する。
【００５５】
［０１１２］データは、ＭＤＤＩ＿Ｄａｔａペアを介して順方向または逆方向の両方に流れることができ、すなわち、双方向転送路であるが、ホストはマスタまたはデータリンクのコントローラである。ＭＤＤＩ＿Ｄａｔａ０信号路およびＭＤＤＩ＿Ｓｔｂ信号路は、雑音排除性を最大にするために、差動モードで動作される。これらのライン上の信号に対するデータレートはホストにより送信されたクロックのレートにより決定され、１ｋｂｐｓから４００Ｍｂｐｓまたはそれ以上までの範囲で変化することができる。
【００５６】
［０１１３］タイプ２インターフェースは、ＭＤＤＩ＿Ｄａｔａ１＋／−と呼ばれる、タイプ１のそれを超えるさらなるデータペア、またはコンダクタまたは経路を含む。タイプ３インターフェースは、ＭＤＤＩ＿Ｄａｔａ２＋／−、およびＭＤＤＩ＿Ｄａｔａ３＋／−と呼ばれる、タイプ２インターフェースのそれを超えるさらなる２つのデータペアまたは信号経路を含む。タイプ４インターフェースは、それぞれＭＤＤＩ＿Ｄａｔａ４＋／−、ＭＤＤＩ＿Ｄａｔａ５＋／−、ＭＤＤＩ＿Ｄａｔａ６＋／−およびＭＤＤＩ＿Ｄａｔａ７＋／−と呼ばれるタイプ３インタフェースのそれを超えるさらなる４つのデータペアまたは信号経路を含む。上述のインターフェース構成のいずれにおいても、ホストは、ワイヤペアまたはＭＤＤＩ＿ＰｗｒおよびＭＤＤＩ＿Ｇｎｄとして示される信号を用いて電力をクライアントまたはディスプレイに送信する。
【００５７】
［０１１４］一般にタイプＵ構成に対してのみ利用可能な転送のタイプは、ＭＤＤＩ  ＵＳＢ接続または信号経路である。ＭＤＤＩ  ＵＳＢ接続は、ホストとクライアントディスプレイとの間の通信のための第２経路から構成される。あるアプリケーションにおいて、ホストとクライアントとの間で相対的に低いデータレートである情報を送信することが利点があるかもしれない。ＵＳＢ転送リンクを用いることにより、ＵＳＢホストまたは限定されたホスト能力を持つ、ＭＤＤＩリンクコントローラを持たない装置は、ＭＤＤＩ互換クライアントまたはタイプＵインターフェースを備えた表示機器との通信をすることができる。ＵＳＢインターフェースを介してディスプレイに有効に転送することのできる情報の例は、スタティックビットマップ、デジタルオーディオストリーム、ポインティングデバイスデータ、キーボードデータ、および制御情報およびステータス情報である。ＵＳＢインターフェースを介してサポートされるすべての機能性は、また第１のＭＤＤＩ高速シリアルデータ路を用いて実現することもできる。上で定義したデータ（以下のパケットを参照）はＵＳＢタイプインターフェースを介して送信することができるが、背合わせパケットの形態でデータをチェーニングするための要件は、そのようなＵＳＢインターフェースには適用しないし、ＭＤＤＩタイプハンドオフをサポートするパケットの使用にも適用しない。
【００５８】
［０１１５］ＭＤＤＩリンクを介してホストとクライアント（ディスプレイ）との間で、インタフェースタイプに従って渡される信号の要約を表１に図解する。
【００５９】
【表１】
2004531916.tif 000003
［０１１６］ケーブル布線は一般に上述の構造を実現するために使用され、実施は、公称上長さ１．５メートルのオーダであり、３つのツイストペアのコンダクタを含み、各々複数のより糸３０  ＡＷＧワイヤである。フォイルシールドカバリング（ｆｏｉｌ ｓｈｉｅｌｄ ｃｏｖｅｒｉｎｇ）が、３つのツイストペアの上にさらなるドレインワイヤとして巻かれ、さもなければ形成される。ツイストペアとシールドドレインコンダクタは、ディスプレイ（クライアント）側のシールドに接続されたシールドを用いて表示接続内で終端し、技術的に良く知られているように、ケーブル全体を覆う絶縁層がある。ワイヤは、ＭＤＤＩ＿ＧｎｄとＭＤＤＩ＿Ｐｗｒが対になり、ＭＤＤＩ＿Ｓｔｂ＋とＭＤＤＩ＿Ｓｔｂ−が対となり、ＭＤＤＩ＿Ｄａｔａ０＋とＭＤＤＩ＿Ｄａｔａ０−が対となる等々である。公称ケーブル直径は、３．０ｍｍのオーダーであり、８５オーム±１０％の公称インピーダンスを有し、１０００フィートあたり１１０オームの公称ＤＣ抵抗を有する。信号伝搬速度は、公称０．６６ｃでなければならず、ケーブル全体に渡っての最大遅延は、約８．０ｎｓｅｃ未満である。
【００６０】
Ｄ．データタイプおよびレート
［０１１７］フルレンジのユーザ体験およびアプリケーションのための有効なインターフェースを達成するために、移動デジタルデータインタフェース（ＭＤＤＩ）は、種々のディスプレイおよびディスプレイ情報、オーディオトランスデューサ、キーボード、ポインティングデバイス、および制御情報およびそれらの組合せと共に移動表示装置と集積可能または移動表示装置と協力して仕事をすることができる他の多くの入力装置に対してサポートを供給する。ＭＤＤインターフェースは、最小のケーブルまたはコンダクタを用いて、順方向リンク方向または逆方向リンク方向に、ホストとクライアントとの間でやりとりされる多種の潜在的なタイプのデータストリームに適応することができるように設計される。等時性ストリームと非同期ストリーム（更新）の両方がサポートされる。総計のデータレートが最大の所望のＭＤＤＩリンクレート以下である限り、データタイプの多くの組合せが可能である。これらは、以下に示す表２および表３にリストアップされたアイテムに限定されないが、これらのアイテムを含むことができる。
【００６１】
【表２】
2004531916.tif 000004
【表３】
2004531916.tif 000005
［０１１８］インターフェースは固定ではなく拡張できるので、将来のシステムの柔軟性のためにユーザ定義されたデータを含む種々の情報「タイプ」の転送をサポートすることができる。適応されるデータの特定の例は、フルのまたは部分的なスクリーンビットマップフィールドの形態または圧縮されたビデオの形態のフルモーションビデオ；電力を節約し、実施コストを低減するために低レートでのスタティックビットマップ；いろいろな分解能またはレートのＰＣＭまたは圧縮されたオーディオデータ；ポインティングデバイスの位置と選択；能力に対してユーザ定義可能なデータであって、まだ定義未定のデータである。そのようなデータはまた、装置の能力または集合演算パラメータを検出するために制御情報またはステータス情報とともに転送することができる。
【００６２】
［０１１９］この発明はこれらに限定されるわけではないが、映画（ビデオディスプレイおよびオーディオ）を見ること、限定された個人鑑賞（グラフィクスディスプレイ、ときどきビデオおよびオーディオとともに結合される）を有したパーソナルコンピュータを用いること、ＰＣ、コンソール、またはパーソナルデバイス（動画グラフィックディスプレイ、または合成ビデオおよびオーディオ）上でビデオゲームをプレイすること、インターネットを「サーフィンすること」、ビデオフォーン（双方向低レートビデオおよびオーディオ）の形態で装置を使用すること、静止デジタル画像のためのカメラ、デジタルビデオ画像を撮像するためのカムコーダ、形態電話、高度自動機能電話、またはＰＤＡを用いた生産性強化または娯楽のためを含むデータ転送に使用する技術を進歩させる。
【００６３】
［０１２０］以下に記載する移動データインターフェースは一般にワイヤラインまたはケーブルタイプリンクとして構成される通信または転送リンクを介して大量のＡ−Ｖタイプのデータを供給する観点から提供される。しかしながら、リンクが所望のレベルの転送を持ちこたえることができるなら、光学または無線媒体の形態でリンクを供給するように、信号構造、プロトコル、タイミング、または転送機構を調節することができることは容易に明白であろう。
【００６４】
［０１２１］ＭＤＤインターフェース信号は、基本信号プロトコルまたは構造に対して共通フレーム（ＣＦ）として知られる概念を使用する。共通フレームの使用の背後にある考えは、同期等時性のデータストリームに対して同期パルスを供給することである。表示装置は、この共通フレームレートを時間基準として使用することができる。低いＣＦレートは、サブフレームヘッダを送信するためにオーバヘッドを減少することにより、チャネル効率を増加させる。一方、高いＣＦレートは待ち時間を減少し、オーディオサンプルのためのより小型の弾力性のあるデータバッファを可能にする。この発明の才のあるインターフェースのＣＦレートは動的にプログラマブルであり、特定のアプリケーションにおいて使用される等時性ストリームに対して適当である多くの値の１つにおいて設定することができる。すなわち、ＣＦ値は要望どおり、所定の表示装置およびホスト構成に最も適するように選択される。
【００６５】
［０１２２］ヘッドマウンテッドマイクロディスプレイのようなアプリケーションに使用される可能性が最も高い等時性データストリームのために調節可能でありプログラム可能である共通フレームごとに一般に必要とされるバイト数は表４に示される。
【００６６】
【表４】
2004531916.tif 000006
共通フレームごとのバイトの分数カウントは、簡単なプログラマブルＭ／Ｎカウンタ構造を用いて容易に得られる。例えばＣＦごとに２６−２／３バイトのカウント値は２６バイトの１フレームに引き続いて各々２７バイトの２フレームを転送することにより実施される。ＣＦごとにバイトの整数を生成するためにより小さなＣＦレートを選択するようにしてもよい。しかしながら、一般的に言って、ハードウエアで簡単なＭ／Ｎカウンタを実現することは、より大きなオーディオサンプルＦＩＦＯバッファのために必要な領域よりもこの発明の部分または前部を実現するために必要な集積回路チップ内でより少ない領域を必要としなければならない。
【００６７】
［０１２３］異なるデータ転送レートとデータタイプの影響を図解する例示アプリケーションはカラオケシステムである。カラオケの場合、システムユーザは音楽ビデオプログラムと共に歌う。歌の歌詞はスクリーンの下部に表示され、ユーザは歌うべき言葉を知り、おおよそ歌のタイミングを知る。このアプリケーションはまれなグラフィック更新とともにビデオディスプレイを必要とし、およびステレオーディオストリームとともにユーザの音声のミキシングを必要とする。
【００６８】
［０１２４］３００Ｈｚの共通フレームレートを仮定するなら、各ＣＦは、表示装置に対して順方向リンクを介して９２，１６０バイトのビデオ内容および（ステレオで１４７の１６ビットのサンプルに基づいて）５８８バイトのオーディオ内容を構成するであろう。そして、平均２９．６７（２６−２／３）バイトの音声がマイクロフォンから移動カラオケマシンに送信される。非同期パケットはホストとディスプレイとの間で送信される。これは多くとも７６８バイトのグラフィックスデータ（１／４スクリーン高さ）および約２００バイト未満（いくつかの）の種々雑多な制御コマンドおよびステータスコマンドのためのバイトを含む。
【００６９】
［０１２５］表５はカラオケ例について共通フレーム内でデータがどのように割当てられるかを示す。使用されている合計レートは約２２５Ｍｂｐｓであるように選択される。わずかに高いレートの２２６Ｍｂｐｓは、サブフレームごとに約４００バイトの別のデータを転送可能にし、これは、時々の制御メッセージおよびステータスメッセージの使用を可能にする。
【００７０】
【表５】
2004531916.tif 000007
Ｅ．リンク層
［０１２６］ＭＤＤインターフェース高速シリアルデータ信号を用いて転送されるデータは交互にリンクされる時分割パケットのストリームを構成する。送信装置が送信すべきデータを有していないときでさえも、ＭＤＤＩリンクコントローラは自動的にフィラーパケットを送信し、従って、パケットのストリームを維持する。簡単パケット構造の使用は、ビデオおよびオーディオ信号またはデータストリームのための信頼できる等時性タイミングを保証する。
【００７１】
［０１２７］パケットのグループはサブフレームと呼ばれる信号エレメントまたは構造内に含まれ、サブフレームのグループは、メディアフレームと呼ばれる信号のエレメントまたは構造内に含まれる。サブフレームは、パケットのそれぞれのサイズおよびデータ転送使用に応じて、１つ以上のパケットを含み、メディアフレームは１つ以上のサブフレームを含まなければならない。この発明により採用されるプロトコルにより供給される最大サブフレームは２３２−１または４、２９４、９６７，２９５バイトであり、従って、最大メディアフレームサイズは２１６−１または６５，５３５サブフレームのオーダになる。
【００７２】
［０１２８］以下に述べるように、特別のヘッダパケットは、各サブフレームの始めに現われる固有の識別子を含む。その識別子は、ホストとディスプレイとの間の通信が開始されると、クライアント装置におけるフレームタイミングを獲得するために使用される。リンクタイミングの獲得は、以下に詳細に述べる。
【００７３】
［０１２９］典型的に、フルモーションビデオが表示されているとき、表示スクリーンはメディアフレームごとに１回更新される。表示フレームレートは、メディアフレームレートと同じである。リンクプロトコルは所望のアプリケーションに応じてディスプレイ全体に渡ってフルモーションビデオをサポートするかまたは静止画により囲まれたフルモーションビデオ内容の小さな領域をサポートする。ウエブページまたはｅメールを見るようないくつかの低電力モバイルアプリケーションにおいて、ディスプレイスクリーンはときどき更新する必要しかないかもしれない。これらの状況において、単一のサブフレームを送信し、リンクを中断して、電力消費を最小にすることは利点がある。インターフェースはまたステレオビジョンのような効果をサポートし、図形要素を取り扱う。
【００７４】
［０１３０］サブフレームは周期的ベースで高優先度のパケットの転送をイネーブルにするために存在する。これは、同時の等時性ストリームを最少量のデータバッファリングと共存可能にする。これは、この発明がディスプレイに供給する１つの利点であり、複数のデータストリーム（ビデオ、音声、制御、ステータス、ポインティングデバイス等の高速通信）を共通のチャネルに必須的に共有することを可能にする。この発明は相対的に少ない信号を用いて情報を転送する。また、この発明は、ＣＲＴモニタのための水平同期パルスおよび帰線期間のような表示技術特定活動が存在することを可能にする。
【００７５】
Ｆ．リンクコントローラ
［０１３１］図４および図５に示すＭＤＤＩリンクコントローラは、ＭＤＤＩデータおよびストローブ信号を受信するために使用される差動ライン受信器を除いては、完全にデジタル実装であるように製造または組み立てられる。リンクコントローラのハードウエアを実現するためにアナログ関数または位相ロックループ（ＰＬＬｓ）は必要ない。リンク同期のためのステートマシンを含むディスプレイインターフェースを除いては、ホストリンクコントローラとディスプレイリンクコントローラは非常に類似した機能を含む。それゆえ、この発明は、全体として、リンクコントローラの製造コストを低減することができる、ホストまたはクライアントとして構成可能な単一設計または回路を作ることができる実用的な利点を可能にする。
【００７６】
４．インターフェースリンクプロトコル
Ａ．フレーム構造
［０１３２］パケット転送のための順方向リンク通信を実施するために使用される信号プロトコルまたはフレーム構造は図６に図解される。図６に示すように、情報またはデジタルデータはパケットとして知られるエレメントにグループ分けされる。次に、複数のパケットは一緒にグループ化され、「サブフレーム」と呼ばれるものが形成され、次に、複数のサブフレームが一緒にグループ化されて「メディア」フレームを形成する。フレームの形成を制御するために、そしてサブフレームの転送を制御するために、各サブフレームは、サブフレームヘッダパケット（ＳＨＰ）と呼ばれる特別にあらかじめ定義されたパケットで開始する。
【００７７】
［０１３３］ホスト装置は、所定の転送のために使用されるデータレートを選択する。このレートは、ホストの最大転送能力、またはホストによりソースから検索されるデータ、およびディスプレイの最大能力、またはデータが転送される他の装置に基づいて、ホスト装置により動的に変更可能である。
【００７８】
［０１３４］ＭＤＤＩまたは発明の才のある信号プロトコルとともに動作するように設計されたまたは動作することができる受信者クライアント装置は、クライアント装置が使用することができる最大の、または現在最大の、データ転送レートを決定するためにホストにより問合せされることができる。または、デフォルトのより遅い最小レートを使用してもよい、並びに使用可能なデータタイプおよびサポートされる特徴を使用してもよい。この情報は、以下にさらに述べる、ディスプレイ能力パケット（ＤＣＰ）を用いて転送することができる。クライアント表示装置はあらかじめ選択された最小のデータレートまたは、最小データレートレンジ内でインターフェースを用いてデータを転送することができる、または他の装置と通信することができる、そして、ホスト装置は、クライアント装置の全能力を決定するために、このレンジ内のデータレートを用いて、問合せを行なうであろう。
【００７９】
［０１３５］ディスプレイのビットマップおよびビデオフレームレート能力の性質を定義する他のステータス情報はステータスパケットでホストに転送することができるので、ホストは、実用的なほど、効率的で最適であるように、すなわちシステム制約内で所望であるようなインタフェースを構成することができる。
【００８０】
［０１３６］ホストは、現在のサブフレーム内に転送される（これ以上の）データパケットが無いとき、またはホストが、順方向リンクのために選択されたデータ送信レートと同じペースにするのに十分なレートで転送できないとき、ホストはフィラーパケットを送信する。各サブフレームはサブフレームヘッダパケットで始まるので、以前のサブフレームの終わりは、以前のサブフレームを正確に充填するパケット（多分フィラーパケット）を含む。パケット自体を運ぶデータのための空間の欠如の場合には、フィラーパケットは、たぶんサブフレーム内の、または次の以前のサブフレームの終わりでかつサブフレームヘッダパケットの前において、最後のパケットであろう。サブフレーム内で送信される各パケットのための十分な空間がサブフレーム内に残存することを保証することは、ホスト装置内の制御動作の仕事である。同時に、ホスト装置がデータパケットの送信を開始すると、ホストは、データアンダーラン（ｕｎｄｅｒ−ｒｕｎ）条件を受けることなしにフレーム内のそのサイズのパケットを首尾よく完了させることができなければならない。
【００８１】
「０１３７」この発明の実施の形態の第１の観点において、サブフレーム送信は２つのモードを有する。第１のモードはライブビデオおよびオーディオストリームを送信するために使用される周期的なサブフレームモードである。このモードにおいて、サブフレーム長はノンゼロであるとして定義される。第２のモードは、新しい情報が利用可能になったときのみビットマップデータをディスプレイ装置に供給するためにフレームが使用される非同期または非周期的なモードである。このモードは、サブフレームヘッダパケット内でサブフレーム長をゼロに設定することにより定義される。周期的なモードを使用すると、ディスプレイが順方向リンクフレーム構造に同期したとき、サブフレームパケット受信者は開始することができる。これは、図４９に対して以下に述べる状態図に従って定義された「同期」（”ｉｎ ｓｙｎｃ”）状態に相当する。非同期、非周期サブフレームモードにおいて、受信者は、最初のサブフレームヘッダパケットが受信された後で受信が開始される。
【００８２】
Ｂ．全体のパケット構造
［０１３８］インターフェースは拡張可能であり、さらなるパケット構造が要望通りに追加することができることに留意して、この発明により実施されるシグナリングプロトコルを公式化するために使用されるパケットのフォーマットまたは構造は以下に提示される。パケットは、インタフェース内の機能の観点から、すなわちパケットが転送するコマンドまたはデータの観点から、異なる「パケットタイプ」としてラベルが付されるまたは分割される。それゆえ、各パケットタイプは、パケットおよび転送されるデータを操作する際に使用される所定のパケットのためのあらかじめ定義されたパケット構造を示す。容易に明白であるであろうように、パケットは、それらの機能に応じて、あらかじめ選択された長さを持つことも出来るし、または可変のまたは動的に変更可能な長さを持つことも出来る。種々のパケットにおいて、使用されるバイト群またはバイトの値は複数ビット（８ビットまたは１６ビット）符号なし整数として構成される。タイプの順番にリストされた、「タイプ」指定とともに採用されるパケットの要約を表６に示す。パケットの転送が正しいと考えられる方向も、タイプＵインタフェースに対してタイプ指定が使用されるかどうかとともにわかる。
【００８３】
【表６】
2004531916.tif 000008
［０１３９］パケットは、図７に図解する、パケット長フィールド、パケットタイプフィールド、データバイトフィールド（ｓ）およびＣＲＣフィールドから構成される共通基本構造または全体のセットの最小フィールドを有する。図７に示すように、パケット長フィールドは、パケット内のビットの合計数、またはパケット長フィールドとＣＲＣフィールドとの間の長さを指定するマルチビット値またはマルチバイト値の形態で情報を含む。この例の好適実施の形態において、パケット長フィールドは、パケット長を指定する１６ビットまたは２バイト幅の符号なし整数を含む。パケットタイプフィールドは、パケット内に含まれる情報のタイプを示すもう一つのマルチビットフィールドである。この例の例示実施の形態において、これは８ビットの符号なし整数の形態の８ビットまたは１バイト幅の値であり、ディスプレイ能力、ハンドオフ、ビデオまたはオーディオストリーム、ステータス等のようなデータタイプを指定する。
【００８４】
［０１４０］第３のフィールドは、そのパケットの一部としてホスト装置とクライアント装置との間で転送または送信されるビットまたはデータを含むデータバイトである。データのフォーマットは、転送されるデータの特定のタイプに従って各パケットタイプについて具体的に定義され、各々が固有のフォーマット要件を有する一連のさらなるフィールドに分離してもよい。すなわち、各パケットは、この部分またはフィールドに対して定義されたフォーマットを有するであろう。最後のフィールドは、データバイト、パケットタイプ、およびパケット長フィールドに対して計算された１６ビット巡回冗長検査の結果を含むＣＲＣフィールドであり、パケット内の情報の完全性を確認するために使用される。言い換えれば、ＣＲＣフィールド自体を除くパケット全体に対して計算される。クライアントは一般に検出されたＣＲＣエラーの合計カウント値を維持し、このカウント値をディスプレイリクエストおよびステータスパケット（さらに以下を参照）でホストに報告する。
【００８５】
［０１４１］パケットの転送期間中、フィールドは、最下位ビット（ＬＳＢ）で送信が開始され、最上位ビット（ＭＳＢ）を最後に送信することで終了する。長さが１バイトを越えるパラメータは最下位バイトを最初に用いて送信され、これは、ＬＳＢが最初に送信されるより短いパラメータに対して使用されるように、８ビット長より大きいパラメータに対して同じビット送信パターンが使用される。ＭＤＤＩ＿ＤＤａｔａ０信号経路上のデータは、モードタイプ１、タイプ２、タイプ３またはタイプ４のいずれかのモードでインタフェース上に送信されるバイトのビット０と合わされる。
【００８６】
［０１４２］表示のためのデータを操作するとき、伝統的に電子工学技術においてなされるように、ピクセルのアレイのためのデータは最初に行が、次に列が送信される。言い換えれば、ビットマップ内の同じ行に現われる全てのピクセルは、一番左のピクセルが最初に送信され、一番右のピクセルが最後に送信される順番で送信される。ある行の一番右のピクセルが送信された後、その系列内の次のピクセルは、次の行の一番左のピクセルである。ピクセルの行は、一般に殆どのディスプレイについて上から下の順番で送信されるが、必要に応じて他の構成に適合させることができる。さらに、ビットマップを取り扱う際に、ここでは伝統的なアプローチを採用するが、このアプローチは、ビットマップの左上角にロケーションまたはオフセット「０，０」としてラベルを付けることにより、基準点を定義することである。ビットマップ内のある位置を定義または決定するために使用されるＸ座標およびＹ座標はそれぞれビットマップの右および下部にアプローチするにつれ値が増加する。第１行目および第１列目はゼロのインデックス値で始まる。
【００８７】
Ｃ．パケット定義
１．サブフレームヘッダパケット
［０１４３］サブフレームヘッダパケットはすべてのサブフレームの最初のパケットであり、図８に図解するような基本構造を有する。図８からわかるように、このタイプのパケットは、パケット長、パケットタイプ、固有ワード、サブフレーム長、プロトコルバージョン、サブフレームカウントフィールドおよびメディアフレームカウントフィールドをこの順番で持つように構成されている。このタイプのパケットは一般にタイプ２５５（１６進数で０ｘｆｆ）パケットとして識別され、あらかじめ選択された１７バイトの固定長を使用する。
【００８８】
［０１４４］パケットタイプフィールドは１バイト値を使用するけれども、固有ワードフィールドは３バイト値を使用する。これら２つのフィールドの４バイトの組合せは一緒になって良好な自己相関を有した３２ビットの固有ワードを形成する。実際の固有のワードは０ｘ００５ａ３ｂｆｆであり、この場合下位８ビットがパケットタイプとして最初に送信され、その後で最上位の２４ビットが送信される。
【００８９】
［０１４５］サブフレーム長フィールドはサブフレームごとのバイト数を指定する４バイトの情報を含む。このフィールドの長さは、リンクがアイドル状態に中断される前に１サブフレームのみがホストにより送信されるであろうことを示すために、ゼロに等しく設定することができる。１つのサブフレームから次のサブフレームへ遷移するとき、このフィールドの値は、オンザフライに動的に変化することができる。この能力は、等時性のデータストリームに適応させるために同期パルス内の軽微なタイミング調整を行うために有用である。サブフレームヘッダのＣＲＣが正当でないなら、リンクコントローラは以前の既知の良好なサブフレームヘッダパケットのサブフレーム長を用いて現在のサブフレームの長さを推定しなければならない。
【００９０】
［０１４６］プロトコルバージョンフィールドは、ホストにより使用されるプロトコルバージョンを指定する２バイトを含む。使用されるプロトコルの最初のまたは現在のバージョンを指定するために、プロトコルバージョンフィールドは「０」に設定される。この値は新しいバージョンが作られるときに時間に対して変化するであろう。サブフレームカウントフィールドはメディアフレームの開始以来送信されてきたサブフレームの数を示すシーケンス番号を指定する２バイトを含む。メディアフレームの第１のサブフレームはゼロのサブフレームカウント値を有する。メディアフレームの最後のサブフレームはｎ−１の値を有し、ｎはメディアフレームごとのサブフレームの数である。サブフレーム長が（非周期サブフレームを示す）ゼロに設定されるなら、サブフレームカウント値もまたゼロに設定される必要があることに注意する必要がある。
【００９１】
［０１４７］メディアフレームカウントフィールドは、現在のメディアアイテムまたは送信中のデータの開始以来送信されてきたメディアフレームの数を示すシーケンス番号を指定する３バイトを含む。メディアアイテムの第１のメディアフレームはゼロのメディアフレームカウントを有する。メディアフレームカウントは、各メディアフレームの最初のサブフレームの直前でインクリメントし、最大メディアフレームカウント（メディアフレーム番号２２４−１＝１６，７７７，２１５）が使用されたときゼロに戻る。メディアフレームカウント値は、一般的に、末端アプリケーションの必要性に適応させるために、ホストによりいつでもリセットすることができる。
【００９２】
２．フィラーパケット
［０１４８］フィラーパケットは、順方向リンク上でまたは逆方向リンク上で、送信すべき他の情報が入手できないとき、クライアント装置にまたはクライアント装置から転送されるパケットである。要求されたとき他のパケットを送信する際に最大の柔軟性が可能となるために、フィラーパケットは最小の長さを持つことが推奨される。サブフレームまたは逆方向リンクカプセル化パケット（以下を参照）の終端で、リンクコントローラは、パケットの完全な状態を維持するために、残りのスペースを充填するためにフィラーパケットのサイズを設定する。
【００９３】
［０１４９］フィラーパケットのフォーマットと内容は図９に示される。図９に示すように、このタイプのパケットは、パケット長、パケットタイプ、フィラーバイト、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般にタイプ０として識別される。これは１バイトタイプフィールドにおいて、示される。フィラーバイトフィールドのビットまたはバイトは、フィラーパケットが所望の長さになることができるように可変数のすべてのゼロのビット値から構成される。最も小さいフィラーパケットは、このフィールドにバイトを含まない。すなわち、パケットはパケット長、パケットタイプ、およびＣＲＣから構成され、あらかじめ選択された固定長の３バイトを使用する。
【００９４】
３．ビデオストリームパケット
［０１５０］ビデオストリームパケットは表示装置の非定型的に方形の領域を更新するためにビデオデータを運ぶ。この領域のサイズは、単一のピクセルより小さいかもしれないし、ディスプレイ全体より大きいかもしれない。ストリームを表示するために必要なすべてのコンテクストはビデオストリームパケットの中に含まれているので、同時に表示されるストリームの数はシステムリソースにより制限されるが、実質ほとんど制限を受けない。ビデオストリームパケット（ビデオデータフォーマットディスクリプタ）のフォーマットは図１０に示される。図１０においてわかるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ビデオデータディスクリプタフィールド、表示属性フィールド、Ｘ左エッジフィールド、Ｙ上部エッジフィールド、Ｘ右エッジフィールド、Ｙ下部エッジフィールド、ＸおよびＹ開始フィールド、ピクセルカウントフィールド、パラメータＣＲＣフィールド、ピクセルデータフィールド、およびＣＲＣフィールドを持つように構成されている。このタイプのパケットは、１バイトタイプフィールドで示されるタイプ１として一般に識別される。
【００９５】
［０１５１］上述した共通のフレーム概念は、オーディオバッファサイズを最小化し、待ち時間を減少させる有効な方法である。しかしながら、ビデオデータについては、メディアフレーム内の複数のビデオストリームパケットにまたがって１つのビデオフレームのピクセルを拡散する必要があるかもしれない。また、単一ビデオストリームパケット内のピクセルがディスプレイ上の完全な方形の窓に正確に対応しないということもありうる。毎秒３０フレームの例示ビデオフレームレートの場合、毎秒ごとに３００のサブフレームがあり、メディアフレームごとに１０のサブフレームを生じる。各フレームにおいて、４８０行のピクセルがあるなら、各サブフレーム内の各ビデオストリームパケットは４８行のピクセルを含むであろう。他の状況において、ビデオストリームパケットは、整数の行のピクセルを含まないかもしれない。これは、メディアフレームごとのサブフレームの数が、ビデオフレームごとの行の数（ビデオラインとしても知られている）に均等に分割しない他のビデオフレームサイズに対して真である。例え、各ビデオストリームパケットが整数の行のピクセル含まないとしても、各ビデオストリームパケットは、整数のピクセルを含まなければならない。これは、ピクセルがそれぞれ２バイト以上なら、または図１２に示すパックされたフォーマット内にあるなら、重要である。
【００９６】
［０１５２］上で示したビデオデータディスクリプタフィールドの動作を実現するために採用されるフォーマットと内容は図１１ａ乃至１１ｄに示される。図１１ａ乃至１１ｄにおいて、ビデオデータフォーマットディスクリプタフィールドは、現在のパケット内の現在のストリーム内のピクセルデータ内の各ピクセルのフォーマットを指定する１６ビットの符号なしの整数の形態で２バイトを含む。（ストリームＩＤフィールドにより指定される）異なるストリームは、異なるピクセルデータフォーマット、すなわち、ビデオデータフォーマットディスクリプタ内の異なる値を使用してもよい。そして、同様に、いかなるストリームもオンザフライにそのデータフォーマットを変えても良い。特定のビデオストリームのライフタイムに対して一定のフォーマットが継続的に使用されることを意味しない、現在のパケットのみに対して、ビデオデータフォーマットディスクリプタはピクセルフォーマットを定義する。
【００９７】
［０１５３］図１１ａ乃至１１ｄはどのようにしてビデオデータフォーマットディスクリプタが符号化されるかを図解する。これらの図において使用されるように、図１１ａに示すようにビット［１５：１３］が「０００」に等しければ、ビデオデータは、ピクセルごとのビット数がビデオデータフォーマットディスクリプタワードのビット３乃至ビット０により定義されるモノクロームピクセルのアレイから構成される。この状況において、ビット１１乃至ビット４はゼロに設定される。その代わりに、図１１ｂに示すように、ビット［１５：１３］が「００１」に等しければ、ビデオデータは、各々がカラーマップを介して色を指定するカラーピクセルのアレイから構成される。この状況において、ビデオデータフォーマットディスクリプタワードのビット５乃至ビット０はピクセルごとのビット数を定義し、ビット１１乃至ビット６はゼロに等しく設定される。その代わり図１１ｃに示すように、ビット［１５：１３］が「０１０」に等しければ、赤のピクセルごとのビット数はビット１１乃至ビット８により定義され、緑のピクセルごとのビット数はビット７乃至ビット４により定義され、青のピクセルごとのビット数はビット３乃至ビット０により定義される。この状況において、各ピクセル内の合計ビット数は赤、緑、青について使用されるビット数の加算値である。
【００９８】
［０１５４］しかしながら、その代わりに、図１１ｄに示すようにビット［１５：１３］が「０１１」に等しいなら、ビデオデータは、輝度情報とクロミナンス情報とを有した４：２：２フォーマットでビデオデータのアレイを構成する。この場合、輝度（Ｙ）のピクセルごとのビット数はビット１１乃至ビット８により定義され、Ｃｒ成分のビット数はビット７乃至ビット４により定義され、およびＣｂ成分のビット数はビット３乃至ビット０により定義される。各ピクセルにおけるビットの合計数は赤、緑、青に対して使用されるビット数の加算値である。ＣｒおよびＣｂ成分はＹとして１／２のレートで送信される。さらに、このパケットのピクセルデータ部分内のビデオサンプルは以下のように組織される：Ｙｎ、Ｃｒｎ、Ｃｂｎ、Ｙｎ＋１、Ｙｎ＋２、Ｃｒｎ＋２、Ｃｂｎ＋２、Ｙｎ＋３・・・ただし、ＣｒｎとＣｂｎはＹｂおよびＹｎ＋１と関連し、Ｃｒｎ＋２およびＣｂｎ＋２はＹｎ＋２およびＹｎ＋３と関連する等々である。現在のストリーム内の行（Ｘ右エッジ−Ｘ左エッジ＋１）内に奇数のピクセルがあるなら、各行内の最後のピクセルに対応するＣｂ値の後に、次の行の最初のピクセルのＹ値が続く。
【００９９】
［０１５５］図で示される４つのすべてのフォーマットについて、「Ｐ」として指定されるビット１２は、ピクセルデータサンプルがパックされるかどうか指定する、またはバイト合わせされたピクセルデータを指定する。このフィールドにおける「０」の値は、ピクセルデータフィールド内の各画素と各画素内の各色がＭＤＤＩインタフェースバイト境界とバイト合わせされることを示す。「１」の値はピクセルデータ内の各ピクセルおよび各ピクセル内の各色は、以前のピクセルまたは未使用ビットを残しておかないピクセル内の色に対してパックされる。
【０１００】
［０１５６］特定のディスプレイウインドウに対する最初のビデオストリームパケット内の最初のピクセルはＸオフセットおよびＹオフセットにより定義されるストリームウインドウの左上角に入るであろう、そして、受信した次のピクセルは、同じ行の次のピクセルロケーションに配置される、等々である。この動作を容易にするために、ディスプレイは、各アクティブビデオストリームＩＤに関連する「次のピクセル行および列」カウンタを維持する。
【０１０１】
４．オーディオストリームパケット
［０１５７］オーディオストリームパケットはディスプレイのオーディオシステムを介して演奏されるオーディオデータ、またはスタンドアローンオーディオプレゼンテーション装置のためのオーディオデータを運ぶ。使用されるオーディオシステムのタイプに応じて、例えば、左前部、右前部、センター、左後部、右後部のように異なるオーディオデータストリームをサウンドシステム内の別個のオーディオチャネルに対して割当てることができる。オーディオチャネルのフルコンポーネントは、強化された空間音響信号処理を含むヘッドセットに対して供給される。オーディオストリームパケットのフォーマットは図１３に図解される。図１３に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、オーディオチャネルＩＤフィールド、オーディオサンプルカウントフィールド、サンプルごとのビットおよびパッキングフィールド、オーディオサンプルレートフィールド、パラメータＣＲＣフィールド、デジタルオーディオデータフィールド、およびオーディオデータＣＲＣフィールドを持つように構成されている。このタイプのパケットは一般的にタイプ２パケットとして識別される。
【０１０２】
［０１５８］サンプルごとのビットおよびパッキングフィールドは、オーディオデータのパッキングフォーマットを指定する８ビット符号なし整数の形態で１バイトを含む。一般的に採用されるフォーマットは、ＰＣＭオーディオサンプルごとのビット数を定義するためのビット４乃至ビット０の場合である。次に、ビット５は、デジタルオーディオデータサンプルがパックされるかどうかを指定する。パックされたオーディオサンプルと、バイト合わせされたオーディオサンプルとの間の相違は、図１４に図解される。「０」の値はデジタルオーディオデータフィールド内の各ＰＣＭオーディオサンプルがＭＤＤＩインタフェースバイト境界とバイト合わせされることを示し、「１」の値は、各連続するＰＣＭオーディオサンプルが以前のオーディオサンプルに対してパックされることを示す。このビットは、ビット４乃至ビット０（ＰＣＭオーディオサンプルごとのビット数）で定義される値が８の倍数でないときにのみ有効である。ビット７乃至６は将来の使用のために予約されており、一般的にはゼロの値で設定される。
【０１０３】
５．予約されたストリームパケット
［０１５９］パケットタイプ３乃至５５は、遭遇する種々のアプリケーションに対して要望通りに、将来のバージョンまたはパケットプロトコルの変化に使用するのに定義されるストリームパケットに対して予約される。この場合もやはり、他の技術と比べてこれまでに変化している技術およびシステム設計を考えた場合にＭＤＤインターフェースをより柔軟かつ有用にする一部である。
【０１０４】
６．ユーザ定義されたストリームパケット
［０１６０］タイプ５６乃至６３として知られる８つのデータストリームタイプは、ＭＤＤＩリンクと共に使用するために機器製造業者により定義することができるメーカ独自のアプリケーションに使用するために予約される。これらはユーザ定義ストリームパケットとして知られる。ビデオストリームパケットは、ディスプレイの方形領域を更新する（または更新しない）ためにビデオデータを運ぶ。ストリームパラメータおよびこれらのパケットタイプのためのデータの定義はそれらの使用を追及する特定の機器製造業者に残される。ユーザ定義ストリームパケットのフォーマットは図１５に図解される。図１５に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、ストリームＩＤ番号フィールド、ストリームパラメータフィールド、パラメータＣＲＣフィールド、ストリームデータフィールドおよびストリームデータＣＲＣフィールドを持つように構成される。
【０１０５】
７．カラーマップパケット
［０１６１］カラーマップパケットは、ディスプレイに対して色を提示するために使用されるカラーマップルックアップテーブルの内容を指定する。いくつかのアプリケーションは、単一のパケットで送信できるデータ量より大きなカラーマップを必要とするかもしれない。これらの場合に、各々が、以下に記載するオフセットおよびレングスフィールドを用いることによりカラーマップの異なるサブセットを有した、複数のカラーマップパケットを転送することができる。カラーマップパケットのフォーマットは図１６に図解される。図１６に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、カラーマップデータサイズフィールド、カラーマップオフセットフィールド、パラメータＣＲＣフィールド、カラーマップデータフィールド、およびデータＣＲＣフィールドを持つように構成される。このタイプのパケットは一般にタイプ６４パケットとして識別される。
【０１０６】
８．逆方向リンクカプセル化パケット
［０１６２］データは、逆方向リンクカプセル化パケットを用いて逆方向に転送される。順方向リンクパケットが送信され、ＭＤＤＩリンク動作（転送方向）がパケットの中央で変化または方向転換されるので、パケットは、逆方向に送信することができる。逆方向リンクカプセル化パケットのフォーマットは図１７に図解される。図１７に示すように、このタイプのパケットは、パケット長、パケットタイプ、逆方向リンクフラッグ、方向転換レングス、パラメータＣＲＣ、方向転換１、逆方向データパケット、および方向転換２を持つように構成される。このタイプのパケットは、一般にタイプ６５パケットとして識別される。
【０１０７】
［０１６３］ＭＤＤＩリンクコントローラは、逆方向リンクカプセル化パケットを送信しながら、特別な方法で振舞う。ＭＤＤインターフェースは、常にホストにより駆動されるストローブ信号を有する。ホストは、逆方向リンクカプセル化パケットの方向転換パケットおよび逆方向データパケットの各ビットに対してあたかもゼロを送信するかのように振舞う。ホストは、２回の方向転換の期間および逆方向データパケットに対して割当てられた時間期間に各ビット境界において、ＭＤＤＩ＿Ｓｔｒｏｂｅ信号をトグルする。（これは、ホストがあたかも全てゼロのデータを送信しているのと同じ振る舞いである。）ホストは、方向転換１により指定される時間期間にＭＤＤＩデータ信号ラインドライバをディスエーブルにし、クライアントは、方向転換２フィールドにより指定される時間期間に続くドライバ再イネーブル期間にそのラインドライバを再イネーブルにする。ディスプレイは方向転換レングスパラメータをリードし、方向転換１フィールド内の最後のビットの直後にホストに向けてデータ信号を駆動する。ディスプレイは、パケットレングスパラメータと方向転換レングスパラメータを用いて、ホストにパケットを送信するために利用可能な時間の長さを知る。クライアントは、ホストに送信すべきデータが無いとき、フィラーパケットを送信することができ、またはデータラインをゼロ状態に駆動することができる。データラインがゼロに駆動されると、ホストはこれをゼロの長さ（正しい長さではない）を有するパケットとして解釈し、ホストは、現在の逆方向リンクカプセル化パケットの期間、クライアントからこれ以上のパケットを受付けない。
【０１０８】
［０１６４］ディスプレイは、方向転換２フィールドの開始前の少なくとも１逆方向リンククロック期間、ＭＤＤＩデータラインをゼロレベルに駆動する。これは、方向転換２の時間期間の間、データラインを決定論的状態に維持する。クライアントが送信すべきこれ以上のパケットを有さないとき、クライアントはデータラインをゼロレベルに駆動した後、さらにデータラインをディスエーブルにすることができる。なぜなら、ハイバーネーションバイアス抵抗（他のどこかで述べられる）が、逆方向データパケットフィールドの残りの期間、データラインをゼロレベルに維持するからである。
【０１０９】
［０１６５］ディスプレイリクエストおよびステータスパケットの逆方向リンクリクエストフィールドは、ホストにデータを返送するために逆方向リンクカプセル化パケット内でディスプレイが必要とするバイト数をホストに知らせるために使用することができる。ホストは少なくともそのバイト数を逆方向リンクカプセル化パケットに割当てることによりそのリクエストを許可しようと試みる。ホストは１つのサブフレーム内で２以上の逆方向リンクカプセル化パケットを送るようにしてもよい。ディスプレイはディスプレイリクエストおよびステータスパケットをほとんどいつでも送信してもよく、そしてホストは逆方向リンクリクエストパラメータを、１つのサブフレームで要求された合計バイト数として解釈するであろう。
【０１１０】
９．ディスプレイ能力パケット
［０１６６］一般に最適なまたは所望の方法でホストからディスプレイへのリンクを構成するために、ホストは、通信しているディスプレイ（クライアント）の能力を知る必要がある。順方向リンク同期が獲得された後、ディスプレイは、ディスプレイ能力パケットをホストに送信することが推奨される。そのようなパケットの送信は、逆方向リンクカプセル化パケット内の逆方向リンクフラッグを用いてホストにより要求されるとき、必要であると考えられる。ディスプレイ能力パケットのフォーマットは図１８に図解される。図１８に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、プロトコルバージョンフィールド、Ｍｉｎプロトコルバージョンフィールド、ビットマップ幅フィールド、ビットマップ高さフィールド、モノクローム能力フィールド、カラーマップ能力フィールド、ＲＧＢ能力フィールド、Ｙ  Ｃｒ  Ｃｂ能力フィールド、ディスプレイ特徴能力フィールド、データレート能力フィールド、フレームレート能力フィールド、オーディオバッファ深さ能力フィールド、オーディオストリーム能力フィールド、オーディオレート能力フィールド、Ｍｉｎサブフレームレートフィールド、およびＣＲＣフィールドを持つように構成されている。このタイプのパケットは一般にタイプ６６パケットとして識別される。
【０１１１】
１０．キーボードデータパケット
［０１６７］キーボードデータパケットは、クライアント装置からホストにキーボードデータを送信するために使用される。無線の（または有線の）キーボードは、これに限定されるわけではないが、頭装着型ビデオディスプレイ／オーディオプレゼンテーション装置を含む種々のディスプレイまたはオーディオ装置と共に使用することができる。キーボードデータパケットは、いくつかの周知のキーボードのような装置の１つから受信したキーボードデータをホストに中継する。このパケットはまた、データをキーボードに送信するために順方向リンクを介して使用することもできる。キーボードデータパケットのフォーマットは図１９に示され、キーボードからのまたはキーボードへの可変数のバイトの情報を含む。図１９に示すように、このタイプのパケットはパケット長フィールド、パケットタイプフィールド、キーボードデータフィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットはタイプ６７パケットとして一般に識別される。
【０１１２】
１１．ポインティングデバイスデータパケット
［０１６８］ポインティングデバイスデータパケットは、無線マウスまたは他のポインティングデバイスからの位置情報を、ディスプレイからホストに送信するために使用される。データはまた、このパケットを用いて、順方向リンクを介してポインティングデバイスに送ることもできる。ポインティングデバイスデータパケットのフォーマットは図２０に示され、ポインティングデバイスからのまたはポインティングデバイスへの可変のバイトの情報を含む。図２０に示すように、このタイプのパケットはパケット長フィールド、パケットタイプフィールド、ポインティングデバイスデータフィールドおよびＣＲＣフィールドを持つように構成される。このタイプのパケットは１バイトタイプフィールドでタイプ６８パケットとして識別される。
【０１１３】
１２．リンク停止パケット
［０１６９］リンク停止パケットは、ＭＤＤＩデータおよびストローブが停止し、低電力消費の「ハイバネーション」状態に入るであろうことを示すためにホストからクライアントディスプレイに送信される。このパケットは、静的ビットマップが移動通信装置からディスプレイに送信された後、または当分の間、ホストからクライアントに送信すべきさらなる情報が無いとき、リンクを停止し、電力を節約するために有用である。ホストがパケットを再び送信するとき、通常の動作がリジュームされる。ハイバネーションの後に送られた最初のパケットはサブフレームヘッダパケットである。ディスプレイステータスパケットのフォーマットを図２１に示す。図２１に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般に、１バイトタイプフィールドでタイプ６９パケットとして識別され、あらかじめ選択された固定長の３バイトを使用する。
【０１１４】
［０１７０］低電力ハイバネーション状態において、ＭＤＤＩ＿Ｄａｔａドライバは高インピーダンス状態にディスエーブルされ、ＭＤＤＩ＿Ｄａｔａ信号は、ディスプレイによりオーバードライブすることができる高インピーダンスバイアスネットワークを用いてロジックゼロ状態にプルアップされる。インターフェースにより使用されるストローブ信号は、電力消費を最小にするためにハイバネーション状態でロジックゼロレベルに設定される。他のどこかに記載するように、ホストまたはディスプレイのいずれかがＭＤＤＩリンクをハイバネーション状態から「ウエークアップ」させることができる。これは、この発明のための主要な進歩であり、この発明の利点である。
【０１１５】
１３．ディスプレイリクエストおよびステータスパケット
［０１７１］ホストは、ディスプレイから少量の情報しか必要としないので、ホストは、最適な方法でホストからディスプレイへのリンクを構成することができる。ディスプレイは、サブフレームごとに１つのディスプレイステータスパケットをホストに送信することが推奨される。ディスプレイは、このパケットが確実にホストに配給されることを保証するために、逆方向リンクカプセル化パケット内の最初のパケットとしてこのパケットを送信しなければならない。ディスプレイステータスパケットのフォーマットは図２２に示される。図２２に示されるように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、逆方向リンクリクエストフィールド、ＣＲＣエラーカウントフィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般に１バイトタイプフィールドでタイプ７０パケットとして識別され、７バイトのあらかじめ選択された固定長を使用する。
【０１１６】
［０１７２］逆方向リンクリクエストフィールドは、データをホストに返送するために、逆方向リンクカプセル化パケット内で、ディスプレイが必要とするバイト数をホストに通知するために使用することができる。ホストは、少なくともそのバイト数を逆方向リンクカプセル化パケットに割当てることによりそのリクエストを許可しようと試みなければならない。ホストは、データに適応させるために、１つのサブフレーム内に２以上の逆方向リンクカプセル化パケットを送信することができる。ディスプレイは、ディスプレイリクエストおよびステータスパケットをいつでも送信することができ、ホストは、１つのサブフレーム内で要求される合計バイト数として逆方向リンクリクエストパラメータを解釈する。どのようにして、逆方向リンクデータがホストに返送されるかについてのさらなる詳細と特定の例を以下に示す。
【０１１７】
１４．ビットブロック転送パケット
［０１７３］ビットブロック転送パケットはディスプレイの領域をいかなる方向へもスクロールする手段を提供する。この能力を有するディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット０でこの能力を報告するであろう。ビットブロック転送パケットのフォーマットは図２３に示される。図２３に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウインドウ幅フィールド、ウインドウ高さフィールド、ウインドウＸ移動フィールド、ウインドウＹ移動フィールドおよびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的にタイプ７１パケットとして識別され、１５バイトのあらかじめ選択された固定長を使用する。
【０１１８】
［０１７４］これらのフィールドは、移動されるウインドウの左上角の座標のＸ値およびＹ値、移動されるウインドウの幅および高さ、およびウインドウがそれぞれ水平方向および垂直方向に移動するピクセル数を指定するために使用される。それぞれ、後者の２つのフィールドについての正の値はウインドウを右および下に移動させ、負の値は左および上に移動させる。
【０１１９】
１５．ビットマップエリアフィルパケット
［０１７５］ビットマップエリアフィルパケットは、ディスプレイの１つの領域を単一の色に容易に初期化するための手段を提供する。この能力を持つディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット１でこの能力を報告するであろう。ビットマップエリアフィルパケットのフォーマットは図２４に示される。図２４に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウインドウ幅フィールド、ウインドウ高さフィールド、データフォーマットディスクリプタフィールド、ピクセルエリアフィル値フィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般に１バイトタイプフィールドでタイプ７２パケットとして識別され、１７バイトのあらかじめ選択された固定長を使用する。
【０１２０】
１６．ビットマップパターンフィルパケット
［０１７６］ビットマップパターンフィルパケットは、ディスプレイの１つの領域をあらかじめ選択されたパターンに容易に初期化するための手段を提供する。この能力を持つディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット２でこの能力を報告するであろう。フィルパターンの左上角は、充填されるウインドウの左上角と合わされる。充填されるウインドウがフィルパターンより広いまたは高いなら、ウインドウを充填するために、そのパターンは水平方向または垂直方向に多数の回数反復することができる。最後に反復されたパターンの右または下部は必要に応じて切り捨てられる。ウインドウがフィルパターンより小さければ、そのウインドウに適合させるために、フィルパターンの右側または下部を切り捨ててもよい。
【０１２１】
［０１７７］ビットマップパターンフィルパケットのフォーマットを図２５に示す。図２５に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、左上Ｘ値フィールド、左上Ｙ値フィールド、ウインドウ幅フィールド、ウインドウ高さフィールド、パターン幅フィールド、パターン高さフィールド、データフォーマットディスクリプタフィールド、パラメータＣＲＣフィールド、パターンピクセルデータフィールド、およびピクセルデータＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的に１バイトのタイプフィールドでタイプ７３パケットとして識別される。
【０１２２】
１７．通信リンクデータチャネルパケット
［０１７８］通信リンクデータチャネルパケットは携帯電話または無線データポート装置のような無線トランシーバと通信するために、ＰＤＡのような高レベルの計算能力を有したディスプレイのための手段を提供する。この状況において、ＭＤＤＩリンクは通信装置と、移動ディスプレイを有した計算装置との間の便利な高速インタフェースとして作動している。この場合、このパケットは、その装置のオペレーティングシステムのデータリンク層においてデータを運ぶ。例えば、ウエブブラウザ、ｅメールクライアント、またはＰＤＡ全体が移動ディスプレイに組み込まれるなら、このパケットは使用することができる。この能力を持つディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット３でこの能力を報告するであろう。
【０１２３】
［０１７９］通信リンクデータチャネルパケットのフォーマットは図２６に示される。図２６に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、パラメータＣＲＣフィールド、通信リンクデータフィールド、および通信データＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的に、タイプフィールド内のタイプ７４パケットとして識別される。
【０１２４】
１８．インタフェースタイプハンドオフリクエストパケット
［０１８０］インターフェースタイプハンドオフリクエストパケットは、クライアントまたはディスプレイが、既存のモードまたは現在のモードからタイプ１（シリアル）モード、タイプ２（２ビットパラレル）モード、タイプ３（４ビットパラレル）モードまたはタイプ４（８ビットパラレル）モードに推移することをホストが要求することを可能にする。ホストが特定のモードを要求する前に、ホストは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット６およびビット７を調べることにより、ディスプレイが所望のモードで動作可能であることを確認する必要がある。インタフェースタイプハンドオフリクエストパケットのフォーマットは図２７に示される。図２７に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、インターフェースタイプフィールドおよびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的にタイプ７５パケットとして識別され、４バイトのあらかじめ選択された固定長を使用する。
【０１２５】
１９．インターフェースタイプアクノレジパケット
［０１８１］インターフェースタイプアクノレジパケットは、インターフェースハンドオフパケットの受信を確認するためにディスプレイにより送信される。要求されたモード、すなわち、タイプ１（シリアル）、タイプ２（２ビットパラレル）、タイプ３（４ビットパラレル）またはタイプ４（８ビットパラレル）モードはこのパケット内のパラメータとしてエコーバックされる。インターフェースタイプアクノレジパケットは図２８に示される。図２８に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、インターフェースタイプフィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的にタイプ７６パケットとして識別され、４バイトのあらかじめ選択された固定長を使用する。
【０１２６】
２０．実行タイプハンドオフパケット
［０１８２］実行タイプハンドオフパケットは、ホストがディスプレイに対してこのパケット内で指定されたモードにハンドオフするように命令するための手段である。これは、インターフェースタイプハンドオフリクエストパケットおよびインターフェースタイプアクノレジパケットにより以前に要求されアクノレジされたモードと同じモードである。ホストとディスプレイはこのパケットが送信された後、一致したモードに切り替わらなければならない。ディスプレイは、モード変更の期間にリンクの同期を失い、取り戻すようにしてもよい。実行タイプハンドオフパケットのフォーマットは図２９に示される。図２９に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、およびインターフェースタイプフィールドおよびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的に１バイトタイプフィールド内でタイプ７７パケットとして識別され、４バイトのあらかじめ選択された固定長を使用する。
【０１２７】
２１．順方向オーディオチャネルイネーブルパケット
［０１８３］このパケットは、ホストが、ディスプレイ内のオーディオチャネルをイネーブルまたはディスエーブルすることを可能にする。この能力は有用であり、ホストにより出力されるオーディオが無いとき、ディスプレイ（クライアント）は、電力を節約するためにオーディオ増幅器または類似の回路素子の電源をオフにすることができる。これは、単にインジケータとしてオーディオストリームの存在または欠如を用いて暗黙的に実現することは極めて、より困難である。ディスプレイシステムの電源がオンされたときのデフォルトの状態は、すべてのオーディオチャネルがイネーブルである。順方向オーディオチャネルイネーブルパケットのフォーマットは図３０に示される。図３０に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、オーディオチャネルイネーブルマスクフィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的に１バイトタイプフィールド内でタイプ７８パケットとして識別され、４バイトの予め選択された固定長を使用する。
【０１２８】
２２．逆方向オーディオサンプルレートパケット
［０１８４］このパケットは、ホストが、逆方向リンクオーディオチャネルをイネーブルまたはディスエーブルし、このストリームのオーディオデータサンプルレートを設定することを可能にする。ホストは、ディスプレイ能力パケット内で正当であると定義されるサンプルレートを選択する。ホストが正しくないサンプルレートを選択するなら、ディスプレイはオーディオストリームをホストに送信しないであろう。ホストは、サンプルレートを２５５に設定することにより、逆方向リンクオーディオストリームをディスエーブルしてもよい。ディスプレイシステムが最初に電源がオンされたとき、または接続されたとき想定されるデフォルト状態は、逆方向リンクオーディオストリームがディスエーブルになることである。逆方向オーディオサンプルレートパケットのフォーマットを図３１に示す。図３１に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、オーディオサンプルレートフィールドおよびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的にタイプ７９パケットとして識別され、４バイトの予め選択された固定長を使用する。
【０１２９】
２３．デジタルコンテント保護オーバーヘッドパケット
［０１８５］このパケットは、使用されるデジタルコンテント保護方法に関連したメッセージをホストとディスプレイが交換可能にする。現在、将来の代替的保護スキーム指定の予約のための余裕を残して、２つのタイプのコンテンと保護が検討されている。１つは、デジタル送信コンテント保護（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）（ＤＴＣＰ）であり、もう一つは、高帯域幅デジタルコンテント保護システム（Ｈｉｇｈ−ｂａｎｄｗｉｄｔｈ Ｄｉｇｉｔａｌ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）（ＨＤＣＰ）である。使用される方法は、このパケット内のコンテント保護タイプパラメータにより指定される。デジタルコンテント保護オーバーヘッドパケットのフォーマットは図３２に示される。図３２に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、コンテント保護タイプフィールド、コンテント保護オーバーヘッドメッセージフィールド、およびＣＲＣフィールドを持つように構成される。このタイプのパケットは一般的にタイプ８０パケットとして識別される。
【０１３０】
２４．トランスペアレントカラーイネーブルパケット
［０１８６］トランスペアレントカラーイネーブルパケットは、どの色がディスプレイにおいてトランスペアレントかを指定し、画像を表示するためにトランスペアレントカラーの使用をイネーブルまたはディスエーブルするために使用される。この能力を持つディスプレイは、ディスプレイ能力パケットのディスプレイ特徴能力インジケータフィールドのビット４において、その能力を報告するであろう。トランスペアレントカラーのための値を有したピクセルがビットマップに書かれると、色は以前の値から変化しない。トランスペアレントカラーイネーブルパケットのフォーマットは図３３に示される。図３３に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、トランスペアレントカラーイネーブルフィールド、データフォーマットディスクリプタフィールド、トランスペアレントピクセル値フィールド、およびＣＲＣフィールドを持つように構成されている。このタイプのパケットは一般に１バイトタイプのフィールドにおいて、タイプ８１のパケットとして識別され、１０バイトのあらかじめ選択された固定長を使用する。
【０１３１】
２５．ラウンドトリップ（Ｒｏｕｎｄ Ｔｒｉｐ）遅延測定パケット
［０１８７］ラウンドトリップ遅延測定パケットは、ホストからクライアント（ディスプレイ）への伝搬遅延プラスクライアント（ディスプレイ）からホストへの戻りの遅延を測定するために使用される。この測定値は、ラインドライバ、および受信器および相互接続サブシステムに存在する遅延を本質的に含む。この測定値は、一般に上で記載した、方向転換遅延、および逆方向リンクカプセル化パケット内の逆方向リンクレート除数パラメータを設定するために使用される。このパケットは、ＭＤＤＩリンクが特定のアプリケーションを対象として最大速度で実行しているとき最も有用である。ＭＤＤＩ＿Ｓｔｂ信号は次のフィールドの期間あたかもすべてのゼロデータが送信されているかのように振舞う。すなわちすべてのゼロのフィールド、両方のガードタイムのフィールド、および測定期間のフィールドである。これは、ＭＤＤＩ＿Ｓｔｂを１／２のデータレートでトグルさせるので、ＭＤＤＩ＿Ｓｔｂは測定期間の間に、ディスプレイ内の周期クロックとして使用することができる。
【０１３２】
［０１８８］ラウンドトリップ遅延測定パケットのフォーマットは図３４に示される。図３４に示すように、このタイプのパケットは、パケット長フィールド、パケットタイプフィールド、パラメータＣＲＣフィールド、ストローブアライメントフィールド、オールゼロフィールド、ガードタイム１フィールド、測定期間フィールド、ガードタイム２フィールド、およびドライバ再イネーブルフィールドを持つように構成されている。このタイプのパケットは一般的にタイプ８２パケットとして識別され、５３５ビットのあらかじめ選択された固定長を使用する。
【０１３３】
［０１８９］ラウンドトリップ遅延測定パケットの期間に発生するイベントのタイミングは図３５に図解される。図３５において、ホストは、パラメータＣＲＣフィールドおよびストローブアライメントフィールド、それに引き続きオールゼロフィールドおよびガードタイム１フィールドの存在により示されるラウンドトリップ遅延測定パケットを送信する。遅延３５０２はパケットがクライアントディスプレイ装置または処理回路に到着する前に生じる。ディスプレイはパケットを受信するので、ディスプレイは、ディスプレイにより決定される測定期間の最初の部分で、実用的なほど正確に０ｘｆｆ、０ｘｆｆ、０ｘ０パターンを送信する。ディスプレイがこの系列の送信を開始する実際の時間は、ホストの立場から測定期間の開始から遅延される。この遅延の量は、正確に、パケットが、ラインドライバ、および受信器および相互接続サブシステムを介して伝搬するのにかかる時間である。同様の遅延量３５０４はそのパターンがディスプレイからホストに伝搬する場合にも被る。
【０１３４】
［０１９０］クライアントとの間でやりとりされる信号のラウンドトリップ遅延時間を正確に決定するために、ホストは、０ｘｆｆ、０ｘｆｆ、０ｘ０系列の開始が到着時に検出されるまで、測定期間の開始の後、ビット時間期間の数をカウントする。この情報は、ラウンドトリップ信号がホストからクライアントを通過し、再び戻るための時間量を決定するために使用される。従って、この量の約１／２がクライアントへの信号の一方向の通過のために作られる遅延の結果であると考えられる。
【０１３５】
［０１９１］ディスプレイは、０ｘｆｆ、０ｘｆｆ、０ｘ０パターンの再度のビットを送信した実質的に直後にラインドライバをディスエーブルにする。ガードタイム２は、ホストが次のパケットのパケットレングスを送信する前に、ディスプレイのラインドライバが完全にハイインピーダンス状態になるための時間を与える。ハイバネーションプルアップ抵抗およびプルダウン抵抗（図４２参照）は、ラインドライバがホストとディスプレイの両方においてディスエーブルされるその間にＭＤＤＩ＿Ｄａｔａ信号が正当な低レベルに保持されることを保証する。
【０１３６】
Ｄ．パケットＣＲＣ
［０１９２］ＣＲＣフィールドはパケットの終わりに現われ、時々極めて大きなデータフィールドを持つかもしれないパケット内のあるより重要なパラメータの後に現われ、従って、転送中にエラーの可能性が増大する。２つのＣＲＣフィールドを持つパケットにおいて、１つのみが使用されるとき、最初のＣＲＣの後でＣＲＣ発生器が再初期化されるので、長いデータフィールドに続くＣＲＣ計算はパケットの最初の部分でパラメータにより影響を受けない。
【０１３７】
［０１９３］この発明の例示実施の形態において、ＣＲＣ計算のために使用される多項式はＣＲＣ−１６、すなわちＸ１６＋Ｘ１５＋Ｘ２＋Ｘ０として知られている。ＣＲＣ発生器の例示実施およびこの発明を実施するために有用なチェッカー３６００は図３６に示される。図３６において、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｂｅｆｏｒｅ＿ＣＲＣライン上に入力されるパケットの最初のビットの転送直前にＣＲＣレジスタ３６０２は０ｘ０００１の値に初期化され、次にパケットのバイトが、最初にＬＳＢで始まりレジスタにシフト入力される。
【０１３８】
この図におけるレジスタビット番号は使用される多項式の順番に対応し、ＭＤＤＩにより使用されるビット位置ではないことに注意する必要がある。ＣＲＣレジスタを単一の方向にシフトさせることがより効率的であり、この結果、ＣＲＣビット１５がＭＤＤＩ  ＣＲＣフィールドのビット位置０に現われ、ＣＲＣレジスタのビット１４がＭＤＤＩ  ＣＲＣフィールドのビット位置１に現われ、同様にして、ＭＤＤＩビット位置１４に到達するまで行なわれる。
【０１３９】
［０１９４］一例として、ディスプレイリクエストおよびステータスパケットのパケットコンテントが０ｘ０７、０ｘ４６、０ｘ０００４００、０ｘ００（または０ｘ０７、０ｘ００、０ｘ４６、０ｘ００、０ｘ０４、０ｘ００、０ｘ００としてバイトの系列として表される）であり、マルチプレクサ３６１２、３６０６、およびＮＡＮＤゲート３６０８の入力を用いて提出されるなら、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｗｉｔｈ＿ＣＲＣライン上の結果として得られるＣＲＣ出力は０ｘ０ｅａ１である（または０ｘａ１、０ｘ０ｅとして系列として表される）
［０１９５］ＣＲＣ発生器とチェッカー３６００がＣＲＣチェッカーとして構成されるとき、Ｒｘ＿ＭＤＤＩ＿Ｄａｔａライン上で受信されるＣＲＣはマルチプレクサ３６０６およびＮＡＮＤゲート３６０８に入力され、ＮＯＲゲート３６１０、イクスクルーシブＯＲ（ＸＯＲ）ゲート３６１２、およびＡＮＤゲート３６１４を用いてＣＲＣレジスタ内に見出される値とビットごとに比較される。ＡＮＤゲート３６１４による出力としてエラーがあれば、ゲート３６１４の出力をレジスタ３６０２の入力に接続することによりＣＲＣエラーを含むパケットごとに１回ＣＲＣがインクリメントされる。図３６の図で示した例示回路は、所定のＣＨＣＫ＿ＣＲＣ＿ＮＯＷウインドウ（図３７ｂ参照）内で２以上のＣＲＣエラー信号を出力することができることに注意する必要がある。それゆえ、ＣＲＣエラーカウンタは、ＣＨＥＣＫ＿ＣＲＣ＿ＮＯＷがアクティブな各区間内の最初のＣＲＣエラー事例のみをカウントするであろう。ＣＲＣ発生器として構成されるなら、ＣＲＣは、パケットの終わりで一致する時刻にＣＲＣレジスタからクロック出力される。
【０１４０】
［０１９６］入力および出力信号、およびイネーブリング信号のタイミングは、図３７ａおよび３７ｂにグラフとして図解される。ＣＲＣの発生およびデータのパケットの送信は、Ｔｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｂｅｆｏｒｅ＿ＣＲＣ信号およびＴｘ＿ＭＤＤＩ＿Ｄａｔａ＿Ｗｉｔｈ＿ＣＲＣ信号とともに、Ｇｅｎ＿Ｒｅｓｅｔ信号、Ｃｈｅｃｋ＿ＣＲＣ＿Ｎｏｗ信号、Ｇｅｎｅｒａｔｅ＿ＣＲＣ＿Ｎｏｗ信号、およびＳｅｎｄｉｎｇ＿ＭＤＤＩ＿Ｄａｔａ信号の状態（０または１）とともに図３７ａに示される。データのパケットの受信およびＣＲＣ値のチェックは、Ｒｘ＿ＭＤＤＩ＿Ｄａｔａ信号およびＣＲＣエラー信号とともに、Ｇｅｎ＿Ｒｅｓｅｔ信号、Ｃｈｅｃｋ＿ＣＲＣ＿Ｎｏｗ信号、Ｇｅｎｅｒａｔｅ＿ＣＲＣ＿Ｎｏｗ信号およびＳｅｎｄｉｎｇ＿ＭＤＤＩ＿Ｄａｔａ信号とともに図３７ｂに示される。
【０１４１】
５．ハイバネーションからのリンクリスタート
［０１９７］ホストがハイバネーション状態から順方向リンクを再開させると、ホストは、ＭＤＤＩ＿Ｄａｔａを約１５０μｓｅｃの間ロジック１の状態にドライブし、次に、ＭＤＤＩ＿Ｓｔｂをアクティブにし、同時にＭＤＤＩ＿Ｄａｔａを５０μｓｅｃの間ロジック０にドライブし、次に、サブフレームヘッダパケットを送信することにより順方向リンクトラヒックを開始する。これは、一般的に、信号間に十分なセットリングタイムを供給することによりサブフレームヘッダパケットが送信される前にバス競合が解決されることを可能にする。
【０１４２】
［０１９８］クライアント、ここではディスプレイがホストからのデータまたは通信を必要とするとき、クライアントは、要望通りに他の期間を使用することができるけれども、約７０マイクロｓｅｃ、ＭＤＤＩ＿Ｄａｔａ０ラインをロジック１にドライブし、次にドライバをハイインピーダンス状態にして、ディスエーブルにする。この行為はホストに順方向リンク（２０８）上でのデータトラヒックを開始または再開させ、ステータスについてクライアントをポーリングさせる。ホストは、リクエストパルスの存在を５０μｓｅｃ以内に検出しなければならず、ＭＤＤＩ＿Ｄａｔａ０を１５０マイクロｓｅｃの期間ロジック１にドライブし、５０μｓｅｃの期間ロジック０にドライブするスタートアップシーケンスを始めなければならない。ディスプレイが、５０μｓｅｃを越える期間ロジック１状態にあるＭＤＤＩ＿Ｄａｔａ０を検出するなら、ディスプレイはサービスリクエストパルスを送信する必要はない。時間の選択の性質、およびハイバネーション処理に関連した時間期間の許容値およびスタートアップシーケンスはさらに以下に述べる。
【０１４３】
［０１９９］競合を有しない典型的なサービスリクエストイベント３８００のための処理ステップの例を図３８に図解する。ただし、イベントには、文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、ＦおよびＧを用いて説明図において便宜的にラベルが付けられる。リンクが低電力ハイバネーション状態に遷移することをクライアント装置に知らせるために、ホストがクライアント装置にリンク停止パケットを送信すると、プロセスはポイントＡにおいて開始する。次のステップにおいて、ポイントＢに示すように、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルにし、ＭＤＤＩ＿Ｓｔｂドライバをロジック０に設定することにより低電力ハイバネーション状態に入る。ＭＤＤＩ＿Ｄａｔａ０はハイインピーダンスバイアスネットワークによりゼロレベルにドライブされる。多少の時間期間の後、ポイントＣに見られるように、クライアントは、ＭＤＤＩ＿Ｄａｔａ０をロジック１レベルにドライブすることによりホストにサービスリクエストパルスを送信する。ホストは依然として、ハイインピーダンスバイアスネットワークを用いてゼロレベルをアサートするが、クライアント内のドライバはそのラインを強制的にロジック１レベルに設定する。ポイントＤに見られるように、５０μｓｅｃ以内に、ホストはサービスリクエストパルスを認識し、そのドライバをイネーブルにすることにより、ＭＤＤＩ＿Ｄａｔａ０に対してロジック１レベルをアサートする。次にポイントＥに示されるように、クライアントは、サービスリクエストパルスをアサートすることを試みることを中止し、そしてクライアントはそのドライバをハイインピーダンス状態にする。ポイントＦに示されるように、ホストは、５０μｓｅｃの期間ＭＤＤＩ＿Ｄａｔａ０をロジック０レベルにドライブし、また、ＭＤＤＩ＿Ｄａｔａ０に対してロジックゼロレベルにドライブするのと一致する方法でＭＤＤＩ＿Ｓｔｂを発生し始める。ポイントＧに示されるように、ＭＤＤＩ＿Ｄａｔａ０をゼロレベルにアサートし、５０μｓｅｃの期間、ＭＤＤＩ＿Ｓｔｂをドライブした後、ホストはサブフレームヘッダパケットを送信することにより、順方向リンク上にデータの送信を開始する。
【０１４４】
［０２００］類似の例を図３９に図解する。ここでは、リンクリスタートシーケンスが始まった後に、サービスリクエストがアサートされる。イベントは再び文字Ａ、Ｂ、Ｃ、Ｄ、Ｅ、ＦおよびＧを用いてラベルが付けられる。これは、クライアントからのリクエストパルスが、サブフレームヘッダパケットに悪影響を及ぼすために最も近くにくる最悪のシナリオを表す。リンクが低電力ハイバネーション状態に遷移するであろうことをクライアント装置に知らせるために、ホストは再びリンク停止パケットをクライアント装置に送信すると、プロセスはポイントＡにおいて始まる。次のステップにおいて、ポイントＢで示されるように、ホストは、ＭＤＤＩ＿Ｄａｔａ０ドライバをディスエーブルにし、ＭＤＤＩ＿Ｓｔｂドライバをロジック０に設定することにより、低電力ハイバネーション状態に入る。すでに述べたように、ＭＤＤＩ＿Ｄａｔａ０は、ハイインピーダンスバイアスネットワークによりゼロレベルに駆動される。ある時間期間の後、ポイントＣに見られるように、ホストはＭＤＤＩ＿Ｄａｔａ０を１５０マイクロｓｅｃの期間ロジック１にドライブすることによりリンクリスタートシーケンスを開始する。ポイントＤに見られるように、リンクリスタートシーケンスを開始した後５０μｓｅｃが経過する前に、ディスプレイはまた７０μｓｅｃの期間、ＭＤＤＩ＿Ｄａｔａ０をアサートする。これは、ディスプレイがホストからのサービスを要求する必要性があり、ホストがすでにリンクリスタートシーケンスを開始したことを認識していないために起こる。次に、ポイントＥにおいてわかるように、クライアントは、サービスリクエストパルスをアサートする試みを中止し、クライアントはそのドライバをハイインピーダンス状態にする。ホストは引き続き、ＭＤＤＩ＿Ｄａｔａ０をロジック１レベルにドライブする。ポイントＦにおいて示されるように、ホストは５０μｓｅｃの期間、ＭＤＤＩ＿Ｄａｔａ０をロジック０レベルにドライブし、ＭＤＤＩ＿Ｄａｔａ０についてロジック０レベルでドライブしたのと一致する方法でＭＤＤＩ＿Ｓｔｂの発生を開始する。ポイントＧに示されるように、ＭＤＤＩ＿Ｄａｔａ０をゼロレベルにアサートし、５０μｓｅｃの期間ＭＤＤＩ＿Ｓｔｂをドライブした後、ホストは、サブフレームヘッダパケットを送信することにより、データを順方向リンクに送信し始める。
【０１４５】
６．インターフェースの電気的仕様
［０２０１］この発明の例示実施の形態において、非ゼロ復帰（ＮＲＺ）フォーマットのデータはデータストローブ信号またはＤＡＴＡ−ＳＴＢフォーマットを用いて符号化され、これは、クロック情報をデータ信号およびストローブ信号に埋め込むことを可能にする。クロックは、複雑な位相ロックループ回路を用いることなしにクロックをリカバーすることができる。データは、一般に、ワイヤラインケーブルを用いて実現される双方向差動リンクを介して運ばれる。ただし、上述したように、他の導体、印刷配線、または転送素子を用いることができる。ストローブ信号（ＳＴＢ）はホストによってのみ駆動される単方向性のリンクを介して運ばれる。同じものがデータラインまたは信号上に残存する、背合わせの状態０または１があるときは、ストローブ信号は値（０または１）を切り替える。
【０１４６】
［０２０２］ＤＡＴＡ−ＳＴＢ符号化を用いて、ビット「１１１０００１０１１」のようなデータシーケンスがどのようにして転送できるかの一例を図４０にグラフの形態で示す。図４０において、必要に応じて位置合わせされるたびに（共通の開始点）、ＤＡＴＡ信号４００２はシグナルタイミングチャートの一番上のライン上に示され、ＳＴＢ信号４００４は第２のライン上に示される。時が経つに従って、状態の変化がＤＡＴＡライン４００２（信号）上にあると、ＳＴＢライン４００４（信号）は以前の状態を維持し、従って、その開始値である、ＤＡＴＡ信号の最初の「１」状態がＳＴＢ信号の最初の「０」状態と相関する。しかしながら、ＤＡＴＡ信号の状態、レベルが変わらないなら、または変わらないとき、ＤＡＴＡが別の「１」の値を供給している図４０の場合のように、この例において、ＳＴＢ信号は反対の状態、すなわち「１」に切り替わる。すなわち、ＤＡＴＡとＳＴＢとの間には、ビットサイクルごとに唯一つの遷移が常にある。それゆえ、ＳＴＢ信号は再び遷移する。今回は、ＤＡＴＡ信号が「１」のままでいるので、「０」であり、ＤＡＴＡ信号がレベルを「０」に変更するので、このレベルまたは値を保持する。ＤＡＴＡ信号が「１」のままでいるとき、ＳＴＢ信号は反対の状態またはこの例では「１」に切り替わり、ＤＡＴＡ信号がレベルまたは値を変更または保持するので、以下同様である。
【０１４７】
［０２０３］これらの信号を受信すると、ＤＡＴＡ信号とＳＴＢ信号に対してイクスクルーシブＯＲ（ＸＯＲ）演算が実行され、クロック信号４００６が生成される。これは、データ信号とストローブ信号との相対的な比較のために、タイミングチャートの下部に示される。ホスト側の入力データからＤＡＴＡ出力およびＳＴＢ出力または信号を発生し、クライアント側でＤＡＴＡ信号およびＳＴＢ信号からそのデータをリカバーまたは取り戻すのに有用な回路の一例を図４１に示す。
【０１４８】
［０２０４］図４１において、送信部４１００は中間信号経路４１０２を介してオリジナルのＤＡＴＡ信号およびＳＴＢ信号を発生し、送信するために使用され、受信部４１２０は、信号を受信し、データをリカバーするために使用される。図４１に示すように、ホストからクライアントにデータを転送するために、ＤＡＴＡ信号は、回路をトリガするためのクロック信号とともに、２つのＤタイプフリップフロップ回路素子４１０４および４１０６に入力される。次に、２つのフリップフロップ出力（Ｑ）は、２つの差動ラインドライバ４１０８および４１１０（電圧モード）を用いて、それぞれ差動対の信号、ＭＤＤＩ＿Ｄａｔａ０＋、ＭＤＤＩ＿Ｄａｔａ０−およびＭＤＤＩ＿Ｓｔｂ＋、ＭＤＤＩ＿Ｓｔｂ−に分割される。３入力イクスクルーシブＮＯＲ（ＸＮＯＲ）ゲート、回路または論理素子４１１２がＤＡＴＡおよび両フリップフロップの出力を受信するように接続され、第２のフリップフロップのためのデータ入力を供給する出力を発生し、次に、第２のフリップフロップはＭＤＤＩ＿Ｓｔｂ＋信号、ＭＤＤＩ＿Ｓｔｂ−信号を発生する。便宜的にＸＮＯＲゲートは、ストローブを発生するフリップフロップのＱ出力を有効に反転することを示すために反転バブル（ｂｕｂｂｌｅ）が設置されている。
【０１４９】
［０２０５］図４１の受信部４１２０において、ＭＤＤＩ＿Ｄａｔａ０＋信号、ＭＤＤＩ＿Ｄａｔａ０−信号およびＭＤＤＩ＿Ｓｔｂ＋信号、ＭＤＤＩ＿Ｓｔｂ−信号は２つの差動ライン受信器４１２２および４１２４の各々により受信され、２つの差動ライン受信器は差動信号から単一の出力を発生する。増幅器の出力は次に、クロック信号を出力する２入力イクスクルーシブＯＲ（ＸＯＲ）ゲート、回路、論理素子４１２６の入力の各々に入力される。クロック信号は２つのＤタイプフリップフロップ回路４１２８および４１３０の各々をトリガするために使用され、２つのＤタイプフリップフロップ回路は、遅延素子４１３２を介して遅延されたバージョンのＤＡＴＡ信号を受信し、フリップフロップ回路のうちの一方（４１２８）はデータ「０」の値を発生し、他方（４１３０）は「１」の値を発生する。その上、クロックは、ＸＯＲロジックからの独立した出力を有する。クロック情報は、ＤＡＴＡ信号とＳＴＢ信号との間に配信されるので、状態間の信号遷移は、クロックレートの１／２より高速ではない。クロックは、ＤＡＴＡ信号とＳＴＢ信号のイクスクルーシブＯＲ処理を用いて再生されるので、クロック信号が単一の専用データラインを介して直接送信される状況に比べて、システムは事実上、入力データとクロックとの間のスキュー量の２倍許容する。
【０１５０】
［０２０６］ＭＤＤＩ＿Ｄａｔａ＋信号、ＭＤＤＩ＿Ｄａｔａ−信号、ＭＤＤＩ＿Ｓｔｂ＋信号およびＭＤＤＩ＿Ｓｔｂ−信号は、雑音のマイナスの影響からの免疫性を最大にするために差動モードで動作される。差動信号経路の各部は、信号を転送するために使用されるケーブルまたは導体の特性インピーダンスの１／２を用いてソース終端される。ＭＤＤＩ＿Ｄａｔａ＋およびＭＤＤＩ＿Ｄａｔａ−はホスト側およびクライアント側の両方でソース終端される。一時にこれら２つのドライバのうちの一方のみがアクティブになるので、転送リンクのためのソースにおいて常に終端がある。ＭＤＤＩ＿Ｓｔｂ＋信号およびＭＤＤＩ＿Ｓｔｂ−信号はホストによってのみ駆動される。
【０１５１】
［０２０７］発明の才のあるＭＤＤインタフェースの一部としての信号を転送するためのドライバ、受信器、および終端を得るために有用なエレメントの例示構成が図４２に示され、ＭＤＤＩ＿ＤａｔａおよびＭＤＤＩ＿Ｓｔｂの対応するＤＣ電気仕様は表７に示される。この例示インターフェースは低電圧の検出機能、ここでは２００ｍＶを使用し、１ボルト未満の脱調および低電力ドレインを有する。
【０１５２】
【表７】
2004531916.tif 000009
［０２０８］差動ラインドライバおよびライン受信器の電気的パラメータおよび特性は表７に記載される。機能的にドライバは、入力に関する論理レベルを正の出力に直接転送し、入力の反転を負の出力に転送する。入力から出力までの遅延は、作動的に駆動される差動ラインに良く調和する。殆どの実施において、出力における電圧のスイングは、電力消費および電磁放射を最小にするために、入力におけるスイングよりも小さい。表７は約０．８Ｖの最小電圧スイングを示す。しかしながら、当業者によく知られているように他の値を使用することができ、発明者達は、設計上の制約に応じて、いくつかの実施の形態において、０．５Ｖまたは０．６Ｖのオーダーのより小さな値を考えている。
【０１５３】
差動ライン受信器は高速電圧コンパレータと同じ特性を有する。図４１において、バブルを有さない入力は正の入力であり、バブルを有する入力は負の入力である。（Ｖｉｎｐｕｔ＋）−（Ｖｉｎｐｕｔ−）がゼロより大きければ出力はロジック１である。これを記載する他の方法は、出力がロジック０電圧レベルおよびロジック１電圧レベルでクリップされる非常に大きな（事実上無限）利得を有する差動増幅器である。
【０１５４】
［０２０９］差動対間の遅延スキューは、最も高い潜在的速度で差動送信システムを動作させるために最小でなければならない。
【０１５５】
［０２１０］図４２において、ホストコントローラ４２０２およびクライアントまたはディスプレイコントローラ４２０４は通信リンク４２０６を介してパケットを通信しているように示される。ホストコントローラは一連の３つのドライバ４２１０、４２１２、４２１４を採用し、転送されるＤａｔａ信号およびＳＴＢ信号を受信し、ならびに転送されるクライアントＤａｔａ信号を受信する。ホストＤＡＴＡを通過させるドライバはイネーブル信号入力を可能にし、ホストからクライアントへの転送が望まれる時にのみ通信リンクの活動を可能にする。ＳＴＢ信号は、データの転送の一部として形成されるので、そのドライバ（４２１２）に対してさらなるイネーブル信号は採用されない。ＤＡＴＡドライバおよびＳＴＢドライバの各々の出力は、終端インピーダンスまたは終端抵抗４２１６ａ、４２１６ｂ、４２１６ｃ、および４２１６ｄにそれぞれ接続される。
【０１５６】
［０２１１］終端抵抗４２１６ａおよび４２１６ｂはＳＴＢ信号処理のためのクライアント側受信器４２２０の入力上のインピーダンスとしても動作するであろう、一方さらなる終端抵抗４２１６ｅおよび４２１６ｆはクライアントデータ処理受信器４２２２の入力上でそれぞれ抵抗４２１６ｃおよび４２１６ｄと直列に配列される。クライアントコントローラ内の６番目のドライバ４２２６は、クライアントからホストに転送されるデータ信号を作るために使用され、入力側上の終端抵抗４２１６ｃおよび４２１６ｄを介したドライバ４２１４は処理のためにホストに転送するデータを処理する。
【０１５７】
［０２１２］２つのさらなる抵抗４２１８ａおよび４２１８ｂは、他のどこかで述べるハイバネーション制御の一部として、それぞれ終端抵抗およびグラウンドおよび電圧源４２２０との間に配置される。電圧源はデータのフローを管理するために以前に述べた転送ラインをハイレベルまたはロウレベルに駆動するために使用される。
【０１５８】
［０２１３］上述のドライバおよびインピーダンスはディスクリートコンポーネントとして形成することができ、またはより費用対効果の高いエンコーダまたはデコーダ解決法として動作する特定用途向け集積回路（ＡＳＩＣ）の一部として形成することができる。
【０１５９】
［０２１４］１対の導体を介してＭＤＤＩ＿ＰｗｒおよびＭＤＤＩ＿Ｇｎｄのラベルが付された信号を用いてホスト装置から電力がクライアント装置、すなわちディスプレイに転送されることが容易にわかる。信号のＭＤＤＩ＿Ｇｎｄ部は基準グラウンドおよび電源リターンパスまたは表示装置のための信号として動作する。ＭＤＤＩ＿Ｐｗｒ信号は、ホスト装置により駆動される表示装置電源として動作する。例示構成例において、低電力アプリケーションの場合、表示装置は５００ｍＡに引き上げることが許される。ＭＤＤＩ＿Ｐｗｒ信号は、これに限定されるわけではないが、ホスト装置に存在するリチウム−イオンタイプバッテリまたはバッテリパックのようなポータブル電源から供給することができ、ＭＤＤＩ＿Ｇｎｄに対して３２．ボルト乃至４．３ボルトの値域を定めることができる。
【０１６０】
７．タイミング特性
Ａ．概要
［０２１５］ホストからのサービスを保証するためにクライアントにより採用されるステップおよび信号レベル、およびそのようなサービスを供給するためにホストにより採用されるステップおよび信号レベルが図４３に図解される。図４３において、図示される信号の第１の部分はホストから転送されるリンクシャットダウンパケットを示し、従って、データラインはハイインピーダンスバイアス回路を用いてロジックゼロ状態にドライブされる。そのドライバがディスエーブルされているクライアントディスプレイ、またはホストによりデータは送信されない。リンクシャットダウンパケットの期間、ＭＤＤＩ＿Ｓｔｂはアクティブであるので、ＭＤＤＩ＿Ｓｔｂ信号ラインのための一連のストローブパルスが下部に見ることができる。ホストはバイアス回路をドライブし、ロジックをゼロにドライブするので、このパケットが終了し、論理レベルがゼロに変化すると、ＭＤＤＩ＿Ｓｔｂ信号ラインは同様にゼロレベルに変化する。これは、ホストからの最後の信号の転送またはサービスの終端を表し、過去のいつでも起こることができた、サービスの以前の中止およびサービス開始前の信号の状態を示すために含まれる。所望であれば、そのような信号は、このホスト装置により始められた「周知」の以前の通信なしに通信リンクを適当な状態にリセットするために送信することができる。
【０１６１】
［０２１６］図４３に示すように、クライアントから出力された信号は最初にゼロの論理レベルに設定される。言い換えれば、クライアント出力はハイインピーダンスであり、ドライバはディスエーブルされる。サービスが要求されているとき、クライアントはそのドライバをイネーブルにし、サービスリクエストをホストに送信する。これは、ラインが１レベルに駆動される指定されたｔｓｅｒｖｉｃｅである時間期間である。従って、ｔｈｏｓｔ−ｄｅｔｅｃｔと名前の付けられたある時間量が経過しまたは必要かもしれない。この後、ホストは信号をロジック１レベルにドライブしてリンクスタートアップ信号に応答する。この時点で、クライアントはリクエストをデアサートし、サービスリクエストドライバをディスエーブルにするので、クライアントからの出力ラインは再びゼロロジックレベルになる。この期間、ＭＤＤＩ＿Ｓｔｂ信号はロジックゼロレベルである。
【０１６２】
［０２１７］ホストは、ｔｒｅｓｔａｒｔ−ｈｉｇｈと名前の付けられた期間、ホストデータ出力を「１」レベルにドライブし、その後、ホストはロジックレベルをゼロにドライブし、ｔｒｅｓｔａｒｔ−ｌｏｗと名前の付けられた期間ＭＤＤＩ＿Ｓｔｂをアクティブにし、その後、最初の順方向トラヒックがフレームヘッダパケットで開始し、次に、順方向トラヒックパケットが転送される。ＭＤＤＩ＿Ｓｔｂ信号はｔｒｅｓｔａｒｔ−ｌｏｗ期間およびそれに続くフレームヘッダパケットの期間アクティブである。
【０１６３】
「０２１８」表８は上述した種々の期間のレングスのための代表的時間を示し、例示最小データレートおよび最大データレートに対する関係を示す。ただし、
【数１】
2004531916.tif 000010
【表８】
2004531916.tif 000011
［０２１９］図４１および図４２に示される個々のエレメントの機能は周知であり、図４２のエレメントの機能は図４３のタイミング図により確認されることを当業者は容易に理解するであろう。図４２に示す一連の終端抵抗およびハイバネーション抵抗は図４１から省略された。何故なら、データストローブ符号化をどのように実行するかおよびそれからクロックをどのようにリカバーするかの記述に対して、その情報は不要であるからである。
【０１６４】
Ｂ．データストローブタイミング順方向リンク
［０２２０］ホストドライバ出力からの順方向リンク上のデータの転送のための切り替え特性は表９に示される。表９はある信号遷移が起こるための標準時間に対して、所望の最小および最大時間の表形式を示す。例えば、データ値（「０」または「１」の出力値）の開始から終わりまで、遷移が生じる時間の典型的長さ、すなわちｔｔｄｄ−（ｈｏｓｔ−ｏｕｔｐｕｔ）と名前の付けられたＤａｔａ０からＤａｔａ０の遷移の時間の典型的長さは、ｔｔｂｉｔであり、最小時間は、約ｔｔｂｉｔ−０．５ｎｓｅｃであり、最大時間は約ｔｔｂｉｔ＋０．５ｎｓｅｃである。Ｄａｔａ０、他のデータライン（ＤａｔａＸ）、およびストローブライン（Ｓｔｂ）は図４４に図示され、Ｄａｔａ０からＳｔｒｏｂｅへの遷移、ＳｔｒｏｂｅからＳｔｒｏｂｅへの遷移、ＳｔｒｏｂｅからＤａｔａ０への遷移、Ｄａｔａ０から非Ｄａｔａ０への遷移、非Ｄａｔａ０から非Ｄａｔａ０への遷移、非Ｄａｔａ０からＳｔｒｏｂｅへの遷移およびＳｔｒｏｂｅから非Ｄａｔａ０への遷移が示され、これらは、それぞれｔｔｄｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｓｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｓｄ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｓｄｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、ｔｔｄｘｓ−（ｈｏｓｔ−ｏｕｔｐｕｔ）、およびｔｔｓｄｘ−（ｈｏｓｔ−ｏｕｔｐｕｔ）と呼ばれる。
【０１６５】
【表９】
2004531916.tif 000012
順方向リンク上でデータを転送する同じ信号に対するクライアント受信器の入力に対する典型的ＭＤＤＩタイミング要件は表Ｘに示される。この同じ信号は議論されるが時間遅延されるので、当業者により理解されるように、信号特性または各ラベルの意味を図解するために新しい図は必要ない。
【０１６６】
【表１０】
2004531916.tif 000013
［０２２１］図４５および図４６はホストがそれぞれホストドライバをディスエーブルまたはイネーブルにするとき、起こり得る応答での遅延の存在を図解する。ホストが、逆方向リンクカプセル化パケットまたはラウンドトリップ遅延測定パケットのようなあるパケットを送る場合に、転送された図４５に示すパラメータＣＲＣパケット、ストローブアラインメントパケットおよびオールゼロパケットのように所望のパケットが送られた後、ホストはラインドライバをディスエーブルする。しかしながら、図４５に示すように、ラインの状態は必ずしも「０」から所望の高い値に瞬時に切り替わらない。これは、存在するある制御または回路素子を用いて潜在的に達成できるけれども、応答するために、ホストドライバディスエーブルディレイピリオドと呼ばれる時間期間かかる。この時間期間は０ナノ秒（ｎｓｅｃ）の長さであるように実質的に直ちに発生することができるけれども、ガードタイム１パケット期間または方向転換パケット期間に生じる、所望の最大期間長である１０ｎｓｅｃの場合のように多少長い期間に容易に延長することができる。
【０１６７】
［０２２２］図４６を参照すると、逆方向リンクカプセル化パケットまたはラウンドトリップ遅延測定パケットのようなパケットを転送するためにホストドライバがイネーブルになると、信号レベル変更を被ることがわかる。ここでは、ガードタイム２パケット期間または方向転換２パケット期間の後、ホストドライバはイネーブルとなり、あるレベル、ここでは「０」をドライブする。この値は、最初のパケットが送信開始される前にドライバリイネーブルの期間の間生じる、ホストドライバイネーブルディレイピリオドと呼ばれる時間期間に近づくまたは達する。
【０１６８】
［０２２３］同様のプロセスがクライアント装置のためのドライバおよび信号転送に対して生じる。これらの期間の長さのための一般的なガイドラインおよびそれぞれの関係は以下の表１１に示される。
【０１６９】
【表１１】
2004531916.tif 000014
Ｃ．データストローブタイミング逆方向リンク
［０２２４］クライアントドライバ出力から逆方向リンク上にデータを転送するために使用されるデータ信号およびストローブ信号のためのスイッチング特性およびタイミング関係は図４７および図４８に示される。ある信号遷移のための典型的時間を以下に述べる。図４７は転送されるデータのタイミングと、ストローブパルスの前縁と後縁との間のホスト受信器入力における関係を示す。ストローブ信号の立ち上がりまたは前縁のためのセットアップタイムと呼ばれるものは、ｔｓｕ−ｓｒであり、ストローブ信号の立下りまたは後縁のためのセットアップタイムはｔｓｕ−ｓｆである。これらのセットアップ期間のための時間の典型的な長さは８ナノ秒のオーダー内にある。
【０１７０】
［０２２５］図４８はスイッチング特性および逆方向データタイミングにより作られる対応するクライアント出力遅延を図解する。図４８において、転送されるデータのタイミングと、誘発された遅延の原因となるストローブパルスの前縁と後縁との間の関係を見ることができる。すなわち、ストローブ信号の立ち上がりまたは前縁とデータとの間の伝搬遅延はｔｐｄ−ｓｒと呼ばれ、データとストローブ信号の後縁または立下りとの間の伝搬遅延はｔｐｄ−ｓｆと呼ばれる。これらの伝搬遅延期間のための時間の典型的長さは８ナノ秒のオーダー内にある。
【０１７１】
８．リンクコントロールの実施（リンクコントローラ動作）
Ａ．ステートマシンパケットプロセッサ
［０２２６］より低いレートも要望通り確実に適応されるが、ＭＤＤＩリンクを介して転送されるパケットは非常に迅速に発送され、典型的には、３００Ｍｂｐｓ以上のオーダーのレートである。このタイプのバスまたは転送リンク速度は、現在商業的に入手できる（経済的な）汎用マイクロプロセッサ等にとって大きすぎて、制御できない。それゆえ、この種の信号転送を行うための実用的な実施は、プログラマブルステートマシンを利用して入力パケットストリームを解析し、パケットが向けられる適当なオーディオビジュアルサブシステムに転送されるまたは向け直されるパケットを形成する。
【０１７２】
［０２２７］汎用コントローラ、プロセッサまたは処理素子は、より低い速度要求を有する制御パケットまたはステータスパケットのようなある情報により適切に作用するまたは操作するために使用することができる。これらのパケット（制御、ステータス、または他のあらかじめ定義されたパケット）が受信されると、ステートマシンはそれらを、データバッファまたは類似の処理素子を介して汎用プロセッサに送らなければならない。それにより、パケットは作用されることができ、所望の結果
（効果）を供給し、一方オーディオおよびビジュアルパケットは、実施のために適当なデスティネーションに転送される。
【０１７３】
［０２２８］汎用プロセッサ機能は、いくつかのモデムまたはグラフィックプロセッサがある機能を実行し、ハードウエアの複雑さおよびコストを低減するために、コンピュータ内のＣＰＵの処理能力を利用するのと同じ方法で、処理能力、または利用できる過度のサイクル、コンピュータアプリケーションにおけるマイクロプロセッサ（ＣＰＵ）、デジタルシグナルプロセッサ（ＤＳＰｓ）、または無線装置に見出されるＡＳＩＣｓを利用して、いくつかの実施の形態で実現可能である。しかしながら、これは、そのような素子の処理速度、タイミング、または全体の動作にマイナスの影響を与える。従って、多くのアプリケーションにおいて、専用の回路または素子がこの汎用処理に対して好適である。
【０１７４】
［０２２９］画像データがディスプレイ（マイクロディスプレイ）上で見えるために、またはホストにより送信されたすべてのパケットを確実に受信するために、表示信号処理は、順方向リンクチャネルタイミングと同期を取らなければならない。すなわち、ディスプレイに到着する信号および表示回路は、適切な信号処理を発生するために、時間同期されなければならない。信号処理レベルにより得られる高レベルの状態図またはそのような同期が実施できる方法は図４９の説明図に提示される。図４９において、ステートマシン４９００のための可能な順方向リンク同期「状態」が、１つの非同期フレーム状態４９０４、２つの獲得同期状態４９０２および４９０６、および３つの同期状態４９０８、４９１０、および４９１２として、分類されて示される。
【０１７５】
［０２３０］開始ステップまたは状態４９０２により示されるように、ディスプレイはあらかじめ選択された「同期なし」の状態において開始し、検出される第１のサブフレームヘッダパケット内の固有のワードを探索する。この同期なし状態は、タイプＩインターフェースが選択される最小通信設定または「後退」設定を表すことに注意する必要がある。探索期間中に固有のワードが発見されたとき、ディスプレイはサブフレーム長フィールドを節約する。
【０１７６】
この最初のフレームに関して処理するためのＣＲＣビットのチェックはない、または同期が得られるまで、ＣＲＣビットのチェックはない。サブフレーム長がゼロなら、この方法に従って、同期状態処理はここでは、「非同期フレーム」状態としてラベルが付された状態４９０４に進む。非同期フレーム状態は、同期がまだ得られていなかったことを示す。処理のこのステップは図４９において、ｃｏｎｄ３、すなわち条件３に遭遇したものとしてラベルが付されている。そうでなければ、フレーム長がゼロより大きければ、同期状態処理は状態４９０６に進み、そこで、インターフェース状態は、「１つの同期フレームを発見した」として設定される。処理内のこのステップは、図４９において、遭遇するｃｏｎｄ５、すなわち条件５としてラベルが付される。さらに、ステートマシンがゼロより大きいフレーム長に対してフレームヘッダパケットと良好なＣＲＣ決定を見るなら、処理は「１つの同期フレームを発見した」状態に進む。これは図４９において、満足するｃｏｎｄ６、すなわち条件６としてラベルが付される。
【０１７７】
［０２３１］システムが「同期なし」以外の状態にある各状況において、サブフレームヘッダパケットに対して、固有のワードが検出され、良好なＣＲＣ結果が決定され、サブフレームヘッダ長がゼロより大きければ、インタフェース状態は、「同期状態」４９０８に変更される。処理内のこのステップは図４９において、遭遇したｃｏｎｄ１、すなわち条件１としてラベルが付される。他方、固有ワードまたはサブフレームヘッダパケット内のＣＲＣが正しくなければ、同期状態処理は「同期なしフレーム」状態のインターフェース状態４９０２に進むまたは戻る。処理のこの部分は、図４９において、遭遇するｃｏｎｄ２、すなわち条件２としてラベルが付される。
【０１７８】
Ｂ．同期のための取得時間
［０２３２］同期が失われ、「同期フレームなし」状態に戻ることを決定する前にある数「同期エラー」に適合するように、インターフェースを構成することができる。図４９において、ステートマシンが「同期状態」に到達し、エラーが見つからない場合、連続的にｃｏｎｄ１結果に遭遇しており、「同期状態」に留まる。しかしながら、１つのｃｏｎｄ２結果が検出されるなら、処理は状態を「１つの同期エラー」状態４９１０に変更する。この時点において、処理が別のｃｏｎｄ１結果を検出するなら、ステートマシンは「同期」状態に戻り、そうでなければ、別のｃｏｎｄ２結果に遭遇し、「２つの同期エラー」状態９１２に移動する。この場合も同様に、ｃｏｎｄ１が生じるなら、処理はステートマシンを「同期」状態に戻す。そうでなければ、別のｃｏｎｄ２が遭遇され、ステートマシンは「同期なし」状態に戻る。「リンク停止パケット」に遭遇すると、リンクがデータ転送するのを終了させ、同期するものがないので、「同期フレームなし」状態に戻し、これは図４９の状態図において、満足するｃｏｎｄ４、すなわち条件４として呼ばれる。
【０１７９】
［０２３３］サブフレーム内のいくつかの固定ロケーションにおいて、現われるかもしれない固有ワードの反復する「偽のコピー」が起こり得ることが理解される。その状況において、ステートマシンがサブフレームに同期するであろうことはほとんど起こりそうにない。なぜなら、ＭＤＤインタフェース処理が「同期」状態に進むために処理されるときサブフレームヘッダパケット上のＣＲＣもまた正当でなければならないからである。
【０１８０】
［０２３４］リンクが停止する前に、ホストは１つのサブフレームのみを送信するであろうことを示すために、サブフレームヘッダパケット内のサブフレーム長はゼロに設定することができ、そして、ＭＤＤインターフェースは、アイドルハイバネーション状態にセットされるまたは構成される。この場合、アイドル状態へのリンク遷移の前に唯一のサブフレームが送信されるので、ディスプレイは、サブフレームヘッダパケットを検出した後、順方向リンクを介して迅速にパケットを受信しなければならない。標準的なまたは典型的な動作において、サブフレーム長はノンゼロであり、インターフェースが図４９において、集合的に「同期」状態として示されるこれらの状態にある間、ディスプレイは順方向リンクパケットを処理するだけである。
【０１８１】
［０２３５］ディスプレイが順方向リンク信号に同期するために必要な時間は、サブフレームサイズおよび順方向リンクデータレートに応じて可変である。順方向リンク内のランダムなデータまたはよりランダムなデータの一部として固有ワードの「偽のコピー」を検出する可能性は、サブフレームサイズが大きくなればなるほど大きくなる。同時に、順方向リンクデータレートが遅くなると、偽の検出から回復するための能力は遅くなり、そうすることにより取られる時間は長くなる。
【０１８２】
Ｃ．初期化
［０２３６］上述したように、「開始」の時刻において、ホストは順方向リンクを最低限必要なデータレートまたはそれを下回るデータレート、または所望の１Ｍｂｐｓで動作するように構成し、所定のアプリケーションに対して適切にサブフレーム長およびメディアフレームレートを構成する。すなわち、順方向リンクおよび逆方向リンクはタイプＩインターフェースを用いて動作を開始する。これらのパラメータは一般には、ホストがクライアントディスプレイ（または他の装置）に対して能力または所望の構成を決定する間、一時的に使用されるだけである。ホストは、ディスプレイがディスプレイ能力パケットに応答することを要求するために、要求フラッグのビット「０」が（１）の値に設定された逆方向リンクカプセル化パケットに続いて順方向リンクを介してサブフレームヘッダパケットを送信または転送する。ディスプレイが順方向リンク上で（または順方向リンクを用いて）同期を獲得すると、ディスプレイは、逆方向リンクまたはチャネルを介してディスプレイ能力パケットおよびディスプレイリクエストおよびステータスパケットを送信する。
【０１８３】
［０２３７］ホストは、最適なまたは所望のレベルの性能のためにリンクをどのように再構成するかを決定するためにディスプレイ能力パケットの内容を調べる。ホストは、ホストとディスプレイが互いに互換性のあるプロトコルのバージョンを使用することを確認するために、プロトコルバージョンフィールドおよび最小プロトコルバージョンフィールドを調べる。プロトコルバージョンは、ディスプレイ能力パケットの最初の２つのパラメータとして残るので、プロトコルの他のエレメントが互換性がないかもしれないまたは互換性があると完全に理解されないかもしれないときでも互換性を決定することができる。
【０１８４】
Ｄ．ＣＲＣ処理
［０２３８］すべてのパケットタイプについて、パケットプロセッサステートマシンは、ＣＲＣチェッカーが適切にまたは正当に制御されることを保証する。また、パケットプロセッサはＣＲＣ比較が１つ以上のエラーを検出したとき、ＣＲＣエラーカウンタをインクリメントし、処理される各サブフレームの開始時にＣＲＣカウンタをリセットする。
【０１８５】
９．パケット処理
［０２３９］ステートマシンが受信する上述のパケットの各タイプについて、ステートマシンはインターフェースの動作を実施するために特定の処理ステップまたは一連のステップを始める。順方向リンクパケットは、一般に以下に示す表１２にリストアップされた例示処理に従って処理される。
【０１８６】
【表１２】
2004531916.tif 000015
2004531916.tif 000016
１０．逆方向リンクデータレートを低減する
［０２４０］非常に望ましい、最大のまたはより最適の（スケール）逆方向リンクデータレートを得るために、ホストリンクコントローラのために使用されるあるパラメータがある方法で調節または構成可能であることを発明者達は観察した。例えば、逆方向リンクカプセル化パケットの逆方向データパケットフィールドを転送するために使用される時間の間、ＭＤＤＩ＿Ｓｔｂ信号対はトグルし、順方向リンクデータレートの１／２の周期データクロックを作る。これは、ホストリンクコントローラがあたかも全てゼロを送信しているかのように、ＭＤＤＩ＿Ｄａｔａ０信号に対応するＭＤＤＩ＿Ｓｔｂ信号を発生するために生じる。ＭＤＤＩ＿Ｓｔｂ信号はホストからディスプレイに転送され、そこで、ＭＤＤＩ＿Ｓｔｂ信号は、ディスプレイから逆方向リンクデータを転送するためにクロック信号を発生し、そのクロック信号を用いて、逆方向データがホストに返送される。信号転送のために遭遇する典型的な遅延量およびＭＤＤＩを採用するシステム内の順方向路および逆方向路上の処理の説明図を図５０に示す。図５０において、Ｓｔｂ＋／−発生段、ケーブル転送表示段、ディスプレイ受信器段、クロック発生段、信号クロッキング段、Ｄａｔａ０＋／−発生段、イネーブル転送ホスト段およびホスト受信器段のための一連の遅延値１．５ｎｓｅｃ、８．０ｎｓｅｃ、２．５ｎｓｅｃ、２．０ｎｓｅｃ、１．０ｎｓｅｃ、１．５ｎｓｅｃ、８．０ｎｓｅｃおよび２．５ｎｓｅｃが処理部分付近に示される。
【０１８７】
［０２４１］順方向リンクデータレートおよび遭遇した信号処理遅延に応じて、この「往復」の効果または完了すべきイベントのセットに対してＭＤＤＩ＿Ｓｔｂ信号の１サイクルより多い時間を必要とするかもしれない。これは、望ましくない時間量またはサイクル量の消費を生じる。この問題を回避するために、逆方向レート除数は、複数サイクルのＭＤＤＩ＿Ｓｔｂ信号を測ることを逆方向リンク上の１ビット時間測ることを可能にする。これは、逆方向リンクデータレートが順方向リンクレートより小さいことを意味する。
【０１８８】
［０２４２］インターフェースを介した信号遅延の実際の長さは、各特定のホスト−クライアントシステムまたは使用されるハードウエアに応じて異ならせてもよいことに注意する必要がある。各システムは一般に、システム内の実際の遅延を測定するために往復遅延測定パケットを用いてよりよく実行することができるので、逆方向レート除数は最適な値に設定することができる。
【０１８９】
［０２４３］往復遅延は、ホストに往復遅延測定パケットをディスプレイに送信させることにより測定される。ディスプレイは、測定周期フィールドと呼ばれるそのパケット内のあらかじめ選択されたウインドウ内あるいはその間、ホストに１の系列を返送することによりこのパケットに応答する。この測定の詳細なタイミングは以前に述べた。往復遅延は、逆方向リンクデータが安全にサンプリングすることができるレートを決定するために使用される。
【０１９０】
［０２４４］往復遅延測定は、測定周期フィールドの開始と、０ｘｆｆ、０ｘｆｆ、０ｘ００応答系列がディスプレイからホストに受信される時間期間の開始との間で生じる順方向リンクデータクロック期間の数を決定し、検出し、カウントすることから構成される。ディスプレイからの応答は、測定カウント値をインクリメントする前のほんの少しの順方向リンククロック期間に受信することが可能であることに注意する必要がある。この変更されていない値を用いて逆方向レート除数を計算するなら、信頼できないデータサンプリングにより逆方向リンク上にビットエラーを生じることもあり得る。この状況の一例は図５１に図解される。この場合、ホストのＭＤＤＩ＿Ｄａｔａを表す信号、ホストのＭＤＤＩ＿Ｓｔｂを表す信号、ホスト内部の順方向リンクデータクロックを表す信号、および遅延カウントを表す信号はグラフの形態で図解される。図５１において、応答系列は、遅延カウントが６から７にインクリメントされる前のほんの少しの順方向リンククロック期間、ディスプレイから受信された。遅延が６であると仮定すると、ホストは常に、ビット遷移の直後あるいは恐らくビット遷移の真中で逆方向データをサンプルするであろう。これはホストにおいて、誤ったサンプリングを生じることもあり得る。このため、測定された遅延は、逆方向レート除数を計算するために使用される前に、典型的に１だけインクリメントされなければならない。
【０１９１】
［０２４５］逆方向レート除数は、逆方向リンクデータをサンプリングする前にホストが待たなければならないＭＤＤＩ＿Ｓｔｂの数である。ＭＤＤＩ＿Ｓｔｂは、順方向リンクレートの１／２のレートでサイクルされるので、訂正された往復遅延測定値は２により除算される必要があり、次の整数に端数を切り上げられる。公式として表すとこの関係は以下の通りである。
【０１９２】
【数２】
2004531916.tif 000017
与えられた例の場合、これは以下のようになる。
【０１９３】
【数３】
2004531916.tif 000018
［０４２６］この例において使用される往復遅延測定が６に相反して７であったなら、逆方向レート除数もまた４に等しいであろう。
【０１９４】
［０２４７］逆方向リンクデータは逆方向リンククロックの立ち上がりエッジでホストによりサンプルされる。逆方向リンククロックを発生するために、ホストとクライアント（ディスプレイ）の両方において、カウンタまたは類似の周知の回路または装置がある。カウンタは初期化されるので、逆方向リンククロックの最初の立ち上がりエッジは、逆方向リンクカプセル化パケットの逆方向リンクパケットフィールド内の最初のビットの始めで生じる。これは、図５２において、以下に与えられる例について図解される。カウンタは、ＭＤＤＩ＿Ｓｔｂ信号の各立ち上がりでインクリメントし、カウンタがラップアラウンド（ｗｒａｐ ａｒｏｕｎｄ）するまでに生じるカウント数は逆方向リンクカプセル化パケット内の逆方向レート除数パラメータにより設定される。ＭＤＤＩ＿Ｓｔｂ信号は順方向リンクレートの１／２でトグルするので、逆方向リンクレートは、逆方向レート除数により除算される順方向リンクレートの１／２である。例えば、順方向リンクレートが２００Ｍｂｐｓで逆方向レート除数が４なら、逆方向リンクデータレートは、以下の如くに表される。
【０１９５】
【数４】
2004531916.tif 000019
［０２４８］逆方向リンクカプセルパケット内のＭＤＤＩ＿Ｄａｔａ０信号ラインおよびＭＤＤＩ＿Ｓｔｂ信号ラインのタイミングを示す一例は図５２に示される。ここで、図解のために使用されるパケットパラメータは以下の値を有する：  パケット長＝１０２４（０ｘ０４００）  方向転換１レングス＝１
パケットタイプ＝６５（０ｘ４）        方向転換２レングス＝１
逆方向リンクフラッグ＝０              逆方向レート除数＝２
パラメータＣＲＣ＝０ｘｄｂ４３        オールゼロは０ｘ００である。
【０１９６】
ストローブアラインメントは０ｘ００、０ｘ００、０ｘ６０である。
【０１９７】
パケットレングスとパラメータＣＲＣフィールドとの間のパケットデータは、０ｘ００、０ｘ０４、０ｘ４１、０ｘ００、０ｘ０２、０ｘ０１、０ｘ０１、０ｘ４３、０ｘｄｂ、０ｘ００、０ｘ０００、０ｘ６０、０ｘ００、・・・
「０２４９］ディスプレイから返却された最初の逆方向リンクパケットは、７のパケットレングスと７０のパケットタイプを有するディスプレイリクエストおよびステータスパケットである。このパケットはバイト値０ｘ０７、０ｘ００、０ｘ４６、・・・等で始まる。しかしながら、最初のバイト（０ｘ０７）のみが図５２において見ることができる。この最初の逆方向リンクパケットは、実際の逆方向リンク遅延を図解するために、図においてほぼ１逆方向リンククロック期間だけタイムシフトされる。ゼロのホストからディスプレイへの往復遅延を有した理想的な波形は破線トレースとして示される。
【０１９８】
［０２５０］パラメータＣＲＣフィールドのＭＳバイトに引き続き、ストローブアラインメントバイトが転送され、次に、オールゼロフィールドが転送される。ホストからのストローブは１からゼロに切り替わりつつあり、ホストからのデータが、より広いパルスを形成するレベルを変化させると１に戻る。データがゼロになると、ストローブはより高いレートに切り替わり、データライン上のデータの変化のみが、アラインメントフィールドの終端付近に変化を生じさせる。ストローブは、拡張された時間期間データ信号の固定された０または１レベルにより数字の余りに対してより高速に切り替わる、そして、その遷移はパルスパターン（エッジ）上に位置する。
【０１９９】
［０２５１］クロックが逆方向リンクパケットに適合するために開始されると、ホストのための逆方向リンククロックは方向転換１期間の終わりまでゼロの状態にある。図の下部分の矢印はこの開示の残りの部分から明らかなように、データがサンプルされるときを示している。転送されるパケットフィールドの最初のバイト（ここでは、１１００００００）は、方向転換１およびラインレベルが、ディスエーブルされるホストドライバから安定化された後で開始するように示されている。最初のビットの通過の遅れは、ビット３について見られるように、Ｄａｔａ信号に対して破線で見ることができる。
【０２００】
［０２５２］図５３において、順方向リンクデータレートに基づいて、逆方向レート除数の典型的な値を観察することができる。正しい逆方向リンク動作を保証するために、往復リンク測定の結果として実際の逆方向レート除数が決定される。第１領域５３０２は安全動作の領域に相当し、第２領域５３０４は、限界性能の領域に相当し、第３領域５３０６は、正しく機能しそうにない設定を示す。
【０２０１】
［０２５３］順方向リンクまたは逆方向リンク上の何らかのインターフェースタイプ設定を用いて動作している間は、往復遅延測定および逆方向レート除数設定は同じである。何故なら、それらは、送信または受信されるビットの数よりもむしろ実際のクロック期間の単位の観点に関して表現され、動作されるからである。
【０２０２】
１１．方向転換およびガード時間
［０２５４］上述したように、逆方向リンクカプセル化パケット内の方向転換１フィールドと、往復遅延測定パケット内のガードタイム１フィールドは、ディスプレイインターフェースドライバがイネーブルになる前に、ホストインターフェースドライバがディスエーブルになることを可能にさせる時間の長さに対する値を示す。方向転換２フィールドとガードタイム２フィールドは、ホストドライバがイネーブルになる前にディスプレイドライバをディスエーブル可能にする時間値を供給する。ガードタイム１フィールドとガードタイム２フィールドは一般に、調節されるように意図されていない長さに対してあらかじめ設定されたまたはあらかじめ選択された値を用いて充填される。使用されるインターフェースハードウエアに応じて、これらの値は経験的データを用いて作っても良いし、ある場合には動作を改良するために調節してもよい。
【０２０３】
［０２５５］方向転換１の長さの決定にいくつかのファクタが寄与し、これらは、順方向リンクデータレートおよびホスト内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間である。最大ホストドライバディスエーブル時間は表１１に示され、表１１は、ドライバがディスエーブルするのに最大約１０ｎｓｅｃかかり、イネーブルするのに約２ｎｓｅｃかかることを示す。ホストドライバがディスエーブルされるのに必要な順方向リンククロックの最小数は次の関係に従って表される。
【０２０４】
【数５】
2004531916.tif 000020
［０２５６］方向転換１の許容値レンジは次の関係に従って表現される。
【０２０５】
【数６】
2004531916.tif 000021
但し、インターフェースタイプファクタはタイプ１に対して１、タイプ２に対して２、タイプ３に対して４、およびタイプ４に対して８である。
【０２０６】
［０２５７］上記２つの式を結合すると、インターフェースタイプファクタ項が相殺され、方向転換１は以下のように定義される。
【０２０７】
【数７】
2004531916.tif 000022
［０２５８］例えば、１５００Ｍｂｐｓタイプ３順方向リンクは、以下の方向転換１遅延を使用するであろう。
【０２０８】
【数８】
2004531916.tif 000023
往復遅延が増加するにつれ、ホストがディスエーブルになるときから、ディスプレイがイネーブルになるときまで時間余裕が改良する。
【０２０９】
［０２５９］一般に、方向転換２のために使用されるレングスを決定するファクタは、順方向リンクデータレート、ディスプレイ内のＭＤＤＩ＿Ｄａｔａドライバの最大ディスエーブル時間および通信リンクの往復遅延である。ディスプレイドライバをディスエーブルするために必要な時間の計算は、上述したホストドライバに対するそれと必然的に同じであり、以下の関係式に従って定義される。
【０２１０】
【数９】
2004531916.tif 000024
そして、方向転換２の許容値レンジは以下のように表される。
【０２１１】
【数１０】
2004531916.tif 000025
［０２６０］例えば１０順方向リンククロックの往復遅延を有する１５００Ｍｂｐｓタイプ３順方向リンクは典型的に
【数１１】
2004531916.tif 000026
のオーダーの方向転換遅延２を使用する。
【０２１２】
１２．物理層相互接続記述
［０２６１］この発明に従うインターフェースを実施するために有用な物理接続は、ホスト側において、Ｈｉｒｏｓｅ電気株式会社により製造されたパーツ番号３２６０−８Ｓ２（０１）のような商業的に入手可能なパーツを用いて実現することができ、ディスプレイ側では、Ｈｉｒｏｓｅ電気株式会社により製造されたパーツ番号３２４０−８Ｐ−Ｃを用いて実現可能である。タイプ１インターフェースに使用されるそのような接続のための例示タイプ１インターフェースピンアサインメントまたはピンアウトを表１３にリストアップする。
【０２１３】
【表１３】
2004531916.tif 000027
［０２６２］相対的な装置サイズに比べて、押し付けがましくなく、非審美的でない、ＰＤＡ、無線電話、または形態ゲーム装置のような移動通信および計算装置に使用するのに十分小さくなるように、相互接続エレメントまたは装置は選択されまたは設計される。いかなるコネクタおよびケーブル布線は典型的な消費者環境において使用するために十分耐久力がなければならず、特にケーブル布線に対して小型を考慮しなければならず、および相対的に低コストを考慮しなければならない。転送エレメントは、タイプ１およびタイプ２に対して約４５０Ｍｂｐｓまでの転送レートを有し、８ビット並列タイプ４バージョンに対して３．６Ｇｂｐｓまでの転送レートを有する差動ＮＲＺデータであるデータ信号およびストローブ信号に適合しなければならない。
【０２１４】
１３．動作
［０２６３］図５５にパケットを処理するインターフェース装置の概要と共に、この発明の実施の形態を用いたインターフェースの動作中にデータおよびパケットを処理する際に行なわれる一般的ステップの概要を図５４ａに示す。これらの図において、プロセスは、ステップ５４０２において、クライアントおよびホストが通信路、ここでは、ケーブルを用いて接続されているかどうかを判断することで始まる。これは、ホストによる周期的ポーリングの使用を介して、またコネクタまたはケーブルの存在を検出し、または（ＵＳＢインターフェースに見られるように）ホストへの入力における信号の検出をするソフトウエアまたはハードウエアを介して、または他の周知の技術を介して生じることができる。クライアントがホストに接続されていないなら、クライアントは、アプリケーションに応じて、単にある所定の長さの待ち状態に入ることができ、ハイバネーションモードに入ることができ、あるいは、ホストを再びアクティブにするためにユーザが行動を起こす必要があるかもしれない将来の使用を待つために非アクティブにすることができる。例えば、ホストがコンピュータタイプの装置に存在するとき、ユーザはオンスクリーンアイコンをクリックしたかもしれない、あるいは、クライアントを探索するためにホスト処理をアクティブにするプログラムを要求したかもしれない。この場合も先と同様に、タイプＵインターフェースの使用のように、ＵＳＢタイプの接続の簡単なプラグインによりホスト処理をアクティブにすることができる。
【０２１５】
［０２６４］クライアントがホストに接続されると、または逆の場合も同じであるが、または存在するとして検出されると、クライアントまたはホストは、ステップ５４０４および５４０６において、サービスを要求する適当なパケットを送信する。クライアントはステップ５４０４において、ディスプレイサービスリクエストまたはステータスパケットに送信することができる。上述したように、リンクは以前に停止することができたあるいはハイバネーションモードにいることができたので、これは次に続く通信リンクの完全な初期化でないかもしれない。通信リンクが同期化され、ホストがクライアントと通信しようとすると、クライアントは、ステップ５４０８において、ディスプレイ能力パケットをホストに供給する必要もある。ホストは今、クライアントが適合することができる転送レートを含むサポートのタイプを判定することを開始することができる。
【０２１６】
［０２６５］一般的に、ホストとクライアントはステップ５４１０において、使用されるサービスモードのタイプ（レート／速度）、例えばタイプ１、タイプＵ、タイプ２等をネゴシエートする。サービスタイプが確立されると、ホストは情報の転送を開始することができる。さらに、ステップ５４１１に示すように、他の信号処理と並列に通信リンクのタイミングを最適化するために、ホストは往復遅延測定パケットを使用してもよい。
【０２１７】
［０２６６］上述したように、すべての転送は、サブフレームヘッダパケットがステップ５４１２において転送されるように示されることで始まり、ステップ５４１４において、データのタイプ、ここでは、ビデオおよびオーディオストリームパケット、およびフィラーパケットが転送されるように示される。オーディオデータおよびビデオデータは、以前にパケットに作られまたはマップされていたであろう、そして、フィラーパケットは、媒体フレームに対して必要な数のビットを書き込むために必要に応じて挿入される。ホストは音響装置をアクティブにするために、順方向オーディオチャネルイネーブルパケットのようなパケットを送信することができる。さらに、ステップ５４１６において、上述した他のパケットタイプを用いてコマンドおよび情報を転送することができる。ここでは、カラーマップの転送、ビットブロック転送、または他のパケットの転送として示される。さらに、ホストとクライアントは適当なパケットを用いてキーボードまたはポインティングデバイスに関連するデータを交換することができる。
【０２１８】
［０２６７］動作中に、所望の異なるデータレートまたはタイプのインターフェースモードを所望するホストまたはクライアントに導くいくつかの異なるイベントの１つを生じることができる。例えば、データを通信するコンピュータまたは他の装置は、パケットの製作または提示において減速を生じさせるデータを処理中にローディング条件に遭遇することもありえる。そのデータを受信するディスプレイは、専用のＡＣ電源からより制限されたバッテリー電源に切り替わるということもあり得る。そして、データを迅速に転送することができず、容易にコマンドを処理することができないか、またはより制限された電源設定の下で同じ程度の分解能または色の深さを使用することができない。あるいは、制限条件が低減されあるいは消失され、どちらか一方の装置がより高いレートでデータを転送することを可能にする。これはより高い転送レートモードに変更するための要求を行うことができるので、より望ましい。
【０２１９】
［０２６８］これらのまたは他のタイプの周知の条件が生じるまたは変化するなら、ホストまたはクライアントはそれらを検出し、インターフェースモードを再交渉しようと試みる。これは、ステップ５４２０に示される。ここでは、ホストは、他のモードへのハンドオフを要求しているクライアイントにインターフェースタイプハンドオフリクエストパケットを送信し、クライアントは変更が求められたことを確認するインターフェースアクノレジパケットを送信し、そしてホストは、指定されたモードに変更するために実行タイプハンドオフパケットを送信する。
【０２２０】
［０２６９］特定の順番の処理を必要としないけれども、クライアントとホストは、また、主にクライアントに関連したポインティングデバイス、キーボード、または他のユーザータイプ入力装置に向けられたまたはそれらから受信したデータに関連するパケットを交換することができる。なお、そのようなエレメントはホスト側にあってもよい。これらのパケットは、典型的に、一般的なプロセスまたはタイプのエレメントを用いて処理され、ステートマシン（５５０２）を用いてではない。さらに、上述したコマンドのいくつかも汎用プロセッサ（５５０４、５５０８）により処理される。
【０２２１】
［０２７０］ホストとクライアントとの間でデータおよびコマンドが交換された後、ある時点で、更なるデータが転送されるかどうか、またはホストまたはクライアントがその転送にサービスすることを中止するかどうかの判断がなされる。これはステップ５４２２に示される。リンクがハイバネーション状態に入るか、完全に停止するなら、ホストは、リンク停止パケットをクライアントに送信し、両方の側がデータの転送を終了する。
【０２２２】
［０２７１］上述した動作処理において、転送されるパケットは、ホストコントローラおよびクライアントコントローラに関連して上述したドライバーおよび受信器を用いて転送されるであろう。これらのラインドライバおよび他の論理エレメントは、図５５の概要において、図解するように、上述したステートマシンおよび汎用プロセッサに接続される。図５５において、ステートマシン５５０２および汎用プロセッサ５５０４および５５０８はさらに図示しない他のエレメントに接続するようにしてもよい。例えば、専用のＵＳＢインターフェース、メモリエレメントまたはリンクコントローラ外部に存在する他の部品である。これらを用いて、ステートマシンおよび汎用プロセッサは、これに限定されないが、データ源、視野表示装置のためのビデオ制御チップを含んで、相互作用する。
【０２２３】
［０２７２］プロセッサおよびステートマシンは、通信リンクの効率的な確立と終了およびパケットの転送を保証するために、ガードタイム等に関連して上述したドライバのイネーブルおよびディスエーブルを制御する。
【０２２４】
１４．補遺
［０２７３］この発明の実施の形態のためのアーキテクチャおよびプロトコルを実施するために使用される種々のパケットのための上述したフォーマット、構造および内容に加えて、より詳細な内容または動作がいくつかのパケットタイプに対してここに提示される。これらは、当業者が容易にこの発明を理解し、多くのアプリケーションに対してこの発明を使用することを可能とするために、それぞれの使用または動作をさらに明白にするためにここに提示される。すでに説明していないいくつかのフィールドについてのみここでさらに説明する。
【０２２５】
Ａ．ビデオストリームパケットについて
［０２７４］ディスプレイ属性フィールド（１バイト）は以下のように解釈される一連のビット値を有する。ビット１と０はどのようにディスプレイピクセルデータが経路選択されるかを選択する。「００」または「１１」のビット値の場合、データは両方の目に対して表示される。ビット値が「１０」の場合、データは左目だけに経路選択される。ビット値が「０１」の場合、データは右目だけに経路選択される。ビット２は、ピクセルデータがインターレースフォーマットで存在するかどうかを示す。「０」の値は、ピクセルデータが標準プログレッシブフォーマットであることを示し、行数（ピクセルＹ座標）は１つの行から次の行に進むとき１だけインクリメントされる。このビットが「１」の値を有するとき、ピクセルデータはインターレースモードにあり、行数は、１つの行から次の行に進むとき、２だけインクリメントされる。ビット３は、ピクセルデータがオルタネートピクセルフォーマットにあることを示す。これは、ビット２によりイネーブルにされる標準インターレースモードに類似しているが、インターレースは水平の代わりに垂直である。ビット３が０であるとき、ピクセルデータは標準プログレッシブフォーマットであり、各連続するピクセルが受信されるごとに列数（ピクセルＸ座標）は１だけインクリメントされる。ビット３が１のとき、ピクセルデータはオルタネートピクセルフォーマットであり、各ピクセルが受信されるごとに、列数は２だけインクリメントされる。ビット７乃至４は将来の使用のために予約され、一般的にゼロとして設定される。
【０２２６】
［０２７５］２バイトＸスタートフィールドおよびＹスタートフィールドはピクセルデータフィールド内の最初のピクセルの点（Ｘスタート、Ｙスタート）の絶対値Ｘ座標およびＹ座標を指定する。２バイトＸ左エッジフィールドとトップエッジフィールドは、ピクセルデータフィールドにより充填されるスクリーンウインドウの左エッジのＸ座標とトップエッジのＹ座標を指定し、Ｘ右エッジフィールドとＹボトムエッジフィールドは、更新されるウインドウの右エッジのＸ座標とボトムエッジのＹ座標を指定する。
【０２２７】
［０２７６］ピクセルカウントフィールド（２バイト）は下にあるピクセルデータフィールド内のピクセルの数を指定する。
【０２２８】
［０２７７］パラメータＣＲＣフィールド（２バイト）はパケットレングスからピクセルカウントまでのすべてのバイトのＣＲＣを含む。もしこのＣＲＣがチェックに失敗するなら、全体のパケットが破棄される。
【０２２９】
［０２７８］ピクセルデータフィールドは、表示される生のビデオ情報を含み、ビデオデータフォーマットディスクリプタフィールドにより記載された方法でフォーマットされる。そのデータは、他のどこかで記載した一時に１「行」送信される。
【０２３０】
［０２７９］ピクセルデータＣＲＣフィールド（２バイト）はピクセルデータのみの１６ビットＣＲＣを含む。この値のＣＲＣ検証が失敗するなら、ピクセルデータはまだ使用可能であるが、ＣＲＣエラーカウントはインクリメントされる。
【０２３１】
Ｂ．オーディオストリームパケットについて
［０２８０］オーディオチャネルＩＤフィールド（１バイト）はオーディオデータがクライアント装置により送信される特定のオーディオチャネルを識別する。０、１、２、３、４、４、５、６または７の値はそれぞれ、左前チャネル、右前チャネル、左後チャネル、右後チャネル、フロントセンタチャネル、サブウーファチャネル、サラウンドレフトチャネルおよびサラウンドライトチャネルを示すので、物理オーディオチャネルはこのフィールドで指定されまたはこのフィールドによりマップされる。２５４のオーディオチャネルＩＤ値は、単一ストリームのデジタルオーディオサンプルが左前チャネルおよび右前チャネルの両方に送信されることを示す。これは、ステレオヘッドセットが音声通信のために使用されるアプリケーション、ＰＤＡにおける生産強化アプリケーション、または簡単なユーザインターフェースが警告音を発生するなんらかのアプリケーションを簡単化する。８から２５３の範囲のＩＤフィールドの値および２５５のＩＤフィールドの値は、現在、新しい設計がさらなる指定を所望する場合に使用するために予約される。
【０２３２】
［０２８１］オーディオサンプルカウントフィールド（２バイト）はこのパケット内のオーディオサンプル内の数を指定する。
【０２３３】
［０２８２］ビットパーサンプルおよびパッキングフィールドは、オーディオデータのペースフォーマット（ｐａｃｉｎｇ ｆｏｒｍａｔ）を指定する。一般的に採用されるフォーマットはビット４乃至ビット０であり、ＰＣＭオーディオサンプルごとのビット数を定義する。次に、ビット５はデジタルオーディオデータサンプルがパックされるか否かを指定する。上述したように、図１２は、パックしたオーディオサンプルとバイトアラインされたオーディオサンプルとの間の差異を図解する。ビット５の「０」の値は、デジタルオーディオデータフィールド内の各ＰＣＭオーディオサンプルは、インターフェースバイト境界とバイトアラインされることを示し、「１」の値は、各連続するＰＣＭオーディオサンプルが以前のオーディオサンプルに対してパック化されることを示す。このビットは、ビット４乃至０で定義された値（ＰＣＭオーディオサンプルごとのビット数）が８の倍数でないときのみ有効である。ビット７乃至６はシステム設計がさらなる指定を所望する場合に使用するために予約され、一般的にゼロの値で設定される。
【０２３４】
［０２８３］オーディオサンプルレートフィールド（１バイト）はオーディオＰＣＭサンプルレートを指定する。採用されるフォーマットは、それぞれ０の値が毎秒８，０００サンプル（ｓｐｓ）のレートを示し、１の値が、１６，０００ｓｐｓを示し、２の値が、２４，０００ｓｐｓを示し、３の値が３２，０００ｓｐｓを示し、４の値が、４０，０００ｓｐｓを示し、５の値が４８，０００ｓｐｓを示し、６の値が、１１，０２５ｓｐｓを示し、７の値が、２２，０５０ｓｐｓを示し、８の値が４４，１００ｓｐｓを示し、９乃至１５の値は将来の使用のために予約され、現在はゼロに設定される。
【０２３５】
［０２８４］パラメータＣＲＣフィールド（２バイト）はパケットレングスからオーディオサンプルレートまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣが適切にチェックすることに失敗するなら、全体のパケットが破棄される。デジタルオーディオデータフィールドは演奏される生のオーディオサンプルを含み、通常、符号なし整数として線形フォーマットの形態である。オーディオデータＣＲＣフィールド（２バイト）はオーディオデータのみの１６ビットＣＲＣを含む。このＣＲＣがチェックに失敗するなら、オーディオデータはまだ使用できるが、ＣＲＣエラーカウントはインクリメントされる。
【０２３６】
Ｃ．ユーザー定義ストリームパケットについて
［０２８５］２バイトストリームＩＤ番号フィールドは、特定のビデオストリームを識別するために使用される。ストリームパラメータの内容と、ストリームデータイフィールドの内容はＭＤＤＩ機器製造業者により定義される。２バイトストリームパラメータＣＲＣフィールドはパケットレングスから始まりオーディオ符号化バイトまでのストリームパラメータのすべてのバイトの１６ビットＣＲＣを含む。もしこのＣＲＣがチェックに失敗するなら、全体のパケットが破棄される。２バイトストリームデータＣＲＣフィールドはストリームデータのみのＣＲＣを含む。もしこのＣＲＣが適切にチェックすることに失敗するなら、アプリケーションの要件に応じて、ストリームデータの使用は任意である。ＣＲＣが良好であることを条件とするストリームデータの使用は、一般的にＣＲＣが良好であると確認されるまで、
ストリームデータをバッファリングしておく必要がある。ＣＲＣがチェックしないなら、ＣＲＣエラーカウントがインクリメントされる。
【０２３７】
Ｄ．カラーマップパケットについて
［０２８６］カラーマップデータサイズフィールド（２バイト）は、このパケット内のカラーマップデータ内に存在するカラーマップテーブルエントリの合計数を指定する。カラーマップデータ内のバイト数はカラーマップサイズの３倍である。カラーマップデータを送信しないために、カラーマップサイズはゼロに設定される。カラーマップサイズがゼロなら、カラーマップオフセット値は依然として送信されるが、ディスプレイにより無視される。カラーマップオフセットフィールド（２バイト）は、この表示装置内のカラーマップテーブルの始めからの、このパケット内のカラーマップデータのオフセットを指定する。
【０２３８】
［０２８７］２バイトパラメータＣＲＣフィールドは、パケットレングスからオーディオ符号化バイトまでのすべてのバイトのＣＲＣを含む。ＣＲＣがチェックに失敗すると、全体のパケットが破棄される。
【０２３９】
［０２８８］カラーマップデータフィールドについて、各カラーマップロケーションは３バイトの値であり、最初のバイトは青の大きさを指定し、第２のバイトは、緑の大きさを示し、第３のバイトは赤の大きさを示す。カラーマップサイズフィールドは、カラーマップデータフィールド内に存在する３バイトカラーマップテーブルアイテムの数を指定する。単一のカラーマップが１つのビデオデータフォーマットおよびカラーマップパケットに適合できないなら、各パケット内に異なるカラーマップデータおよびカラーマップオフセットを有する複数のパケットを送信することにより、全体のカラーマップを指定してもよい。
【０２４０】
［０２８９］２バイトカラーマップデータＣＲＣフィールドはカラーマップデータのみのＣＲＣを含む。このＣＲＣがチェックに失敗するなら、カラーマップデータは依然として使用できるが、ＣＲＣエラーカウントはインクリメントされる。
【０２４１】
Ｅ．逆方向リンクカプセル化パケットについて
［０２９０］逆方向リンクフラッグフィールド（１バイト）は、ディスプレイから情報を要求するためのフラッグの設定を含む。ビット（ここでは、ビット０）が１に設定されるなら、ホストは、ディスプレイ能力パケットを用いてディスプレイから指定された情報を要求する。ビットがゼロなら、ホストは、ディスプレイからの情報を必要としない。残りのビット（ここでは、ビット１乃至７）は将来の使用のために予約され、ゼロに設定される。
【０２４２】
［０２９１］逆方向レート除数フィールド（１バイト）は、逆方向リンクデータクロックに関連して生じるＭＤＤＩ＿Ｓｔｂサイクルの数を指定する。逆方向リンクデータクロックは、順方向リンクデータクロックを２で割り算して、逆方向レート除数を乗算したものに等しい。逆方向リンクデータレートは、逆方向リンクデータクロックおよび逆方向リンク上のインターフェースタイプに関連している。タイプ１インターフェースの場合、逆方向データレートは、逆方向リンクデータクロックに等しい。タイプ２、タイプ３およびタイプ４のインターフェースの場合、逆方向データレートは、それぞれ、逆方向リンクデータクロックの２倍、４倍、および８倍に等しい。
【０２４３】
［０２９２］方向転換１レングスフィールド（１バイト）は方向転換１のために割当てられたバイトの合計数を指定する。方向転換１の推奨されるレングスは、ホスト内のＭＤＤＩ＿Ｄａｔａドライバが出力をディスエーブルさせるのに必要なバイトの数である。これは、上述した出力ディスエーブル時間、順方向リンクデータレート、および使用される順方向リンクインターフェースタイプに基づく。方向転換１の設定のより完全な記述は上述される。
【０２４４】
［０２９３］方向転換２レングスフィールド（１バイト）は方向転換のために割当てられるバイトの合計数を指定する。方向転換２の推奨されるレングスは、ディスプレイ内のＭＤＤＩ＿Ｄａｔａドライバがそれらの出力プラス往復遅延をディスエーブルするのに必要なバイトの数である。方向転換２の設定の記述は上述される。
【０２４５】
［０２９４］パラメータＣＲＣフィールド（２バイト）はパケットレングスから方向転換レングスまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックに失敗するなら、全体のパケットが破棄される。
【０２４６】
［０２９５］ストローブアラインメントフィールド（３バイト）は、ＭＤＤＩ＿Ｓｔｂ信号が、すべてのゼロフィールドの最後のビットと、逆方向データパケットフィールドの最初のビットとの間のビット境界において、ロウレベルからハイレベルへの遷移を行なうように、値を含む。これは、逆方向データパケットフィールド内のバイト境界に関して、ＭＤＤＩ＿Ｓｔｂ信号が一貫した方法で振舞う。
【０２４７】
［０２９６］オールゼロフィールド（１バイト）はゼロに等しく設定され、最初のガードタイム期間中にラインドライバをディスエーブルする前にすべてのＭＤＤＩ＿Ｄａｔａ信号がゼロ状態にあることを保証するために使用される。
【０２４８】
［０２９７］方向転換１フィールドは、最初の方向転換期間を確立するために使用される。方向転換レングスパラメータにより指定されたバイトの数はこのフィールドにより割当てられ、クライアント（ディスプレイ）内のラインドライバがイネーブルになる前にホスト内のＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブル可能にする。ホストは、方向転換１のビット０の期間にそのＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブルにし、クライアント（ディスプレイ）は、方向転換１の最後のビットの直後にそのラインドライバをイネーブルにする。ＭＤＤＩ＿Ｓｔｂ信号は、あたかも方向転換期間がすべてゼロであるかのように振舞う。
【０２４９】
［０２９８］逆方向データパケットフィールドは、クライアントからホストへ転送される一連のデータパケットを含む。上述したように、フィラーパケットは、他のパケットにより使用されていない残りのスペースを埋めるために送信される。
【０２５０】
［０２９９］方向転換２フィールドは第２の方向転換期間を確立するために使用される。方向転換レングスパラメータにより指定されるバイトの数はこのフィールドにより割当てられる。
【０２５１】
［０３００］ドライバ再イネーブルフィル−ドは、次のパケットのパケットレングスフィールド前にすべてのＭＤＤＩ＿Ｄａｔａ信号が再イネーブルされることを保証するために、ゼロに等しい１バイトを使用する。
【０２５２】
Ｆ．ディスプレイ能力パケットについて
［０３０１］プロトコルバージョンフィールドはクライアントにより使用されるプロトコルバージョンを指定するために２バイトを使用する。初期のバージョンはゼロに等しく設定され、最小プロトコルバージョンフィールドは２バイトを用いて、クライアントが採用することのできるまたは解釈することができる最小プロトコルバージョンを指定する。ディスプレイデータレート能力フィールド（２バイト）はディスプレイがインタフェースの順方向リンクを介して受信することのできる最大データレートを指定し、毎秒メガビット（Ｍｂｐｓ）の形態で指定される。インターフェースタイプ能力フィールド（１バイト）は順方向リンクおよび逆方向リンク上でサポートされるインターフェースタイプを指定する。これは現在、それぞれ順方向上のタイプ２、タイプ３またはタイプ４の何れかを選択するためにビット０、ビット１、またはビット２を選択することにより示され、それぞれ逆方向リンク上のタイプ２、タイプ３またはタイプ４のいずれかを選択するためにビット３、ビット４またはビット５を選択することにより示され、ビット６およびビット７は予約されゼロに設定される。ビットマップ幅および高さフィールド（２バイト）はピクセルでビットマップの幅と高さを指定する。
【０２５３】
［０３０２］モノクローム能力フィールド（１バイト）はモノクロームフォーマットで表示できる分解能のビット数を指定するために使用される。ディスプレイがモノクロームフォーマットを使用できないなら、この値はゼロに設定される。ビット７乃至４は将来の使用のために予約され、従ってゼロとして設定される。ビット３乃至０は各ピクセルに対して存在することのできるグレイスケールの最大ビット数を定義する。これらの４ビットは各ピクセルに対して１乃至１５の値を指定することを可能とする。この値がゼロなら、モノクロームフォーマットはディスプレイによりサポートされない。
【０２５４】
［０３０３］カラーマップ能力フィールド（３バイト）はディスプレイ内のカラーマップテーブル内に存在するテーブルアイテムの最大数を指定する。ディスプレイがカラーマップフォーマットを使用することができないなら、この値はゼロである。
【０２５５】
［０３０４］ＲＧＢ能力フィールド（２バイト）はＲＧＢフォーマットで指定することのできる分解能のビット数を指定する。ディスプレイがＲＧＢフォーマットを使用することができないなら、この値はゼロである。ＲＧＢ能力ワードは３つの異なる符号なし値から構成される：ビット３乃至０は各ピクセルにおいて青のビットの最大数を定義する、ビット７乃至４は、緑のビットの最大数を定義する、そして、ビット１１乃至８は赤のビットの最大数を定義する。現在ビット１５乃至１２は将来の使用のために予約され、一般的にゼロに設定される。
【０２５６】
［０３０５］Ｙ  Ｃｒ  Ｃｂ能力フィールド（２バイト）は、Ｙ  Ｃｒ  Ｃｂフォーマットで表示できる分解能のビット数を指定する。ディスプレイがＹ  Ｃｒ  Ｃｂフォーマットを使用できないなら、この値はゼロである。Ｙ  Ｃｒ  Ｃｂ能力ワードは３つの異なる符号なし値から構成される：ビット３乃至０はＣｂサンプル内のビットの最大数を定義する。ビット７乃至４はＣｒサンプル内のビットの最大数を定義する。ビット１１乃至８はＹサンプル内のビットの最大数を定義する。およびビット１５乃至１２は現在将来の使用のために予約され、ゼロに設定される。
【０２５７】
［０３０６］ディスプレイ特徴能力インジケータはサポートされるディスプレイ内の特定の特徴を示すフラッグのセットを含む４バイトを使用する。１に設定されたビットは能力がサポートされることを示し、ゼロに設定されたビットは能力がサポートされないことを示す。ビット０に対する値は、ビットマップブロック転送パケット（パケットタイプ７１）がサポートされるか否かを示す。ビット１、２、および３に対する値は、それぞれ、ビットマップエリアフィルパケット（パケットタイプ７２）、ビットパターンフィルパケット（パケットタイプ７３）または通信リンクデータチャネルパケット（パケットタイプ７４）がサポートされているか否かを示す。ビット４に対する値は、ディスプレイがある色をトランスペアレントにする能力を有するか否かを示し、ビット５および６に対する値は、それぞれディスプレイがビデオデータまたはオーディオデータをパックされたフォーマットで受け入れ可能かどうかを示し、ビット７に対する値は、ディスプレイがカメラから逆方向リンクビデオストリームを送信することが出来るかどうかを示す。ビット１１および１２に対する値はクライアントがポインティングデバイスと通信するとき、およびポインティングデバイスデータパケットを送信および受信できることを示すか、またはキーボード装置と通信するときを示し、およびキーボードデータパケットを送信および受信できることを示す。ビット１３乃至ビット３１は将来の使用またはシステム設計者に対して有用な代わりの指定のために予約され、一般的にゼロに等しく設定される。
【０２５８】
［０３０７］ディスプレイビデオフレーム能力フィールド（１バイト）は毎秒ごとのフレーム内のディスプレイの最大ビデオフレーム更新能力を指定する。ホストは、このフィールドで指定された値よりも遅いレートで画像を更新するように選択してもよい。
【０２５９】
［０３０８］オーディオバッファ深さフィールド（２バイト）は各オーディオストリームに専用のディスプレイ内の弾性バッファの深さを指定する。
【０２６０】
［０３０９］オーディオチャネル能力フィールド（２バイト）はどのオーディオチャネルがディスプレイ（クライアント）によりサポートされているかを示すフラッグのグループを含む。１に設定されたビットはチャネルがサポートされていることを示し、ゼロに設定されたビットはチャネルがサポートされていないことを示す。ビット位置は、ビット位置０、１、２、３、４、５、６、および７がそれぞれ左前チャネル、右前チャネル、左後チャネル、右後チャネル、フロントセンタチャネル、サブウーファチャネル、サラウンドレフトチャネル、およびサラウンドライトチャネルを示すように異なるチャネルに割当てられる。ビット８乃至１５は現在将来の使用のために予約され、一般的にゼロに設定される。
【０２６１】
［０３１０］順方向リンクのための２バイトオーディオサンプルレート能力フィールドは、クライアントデバイスのオーディオサンプルレート能力を示すためにフラッグのセットを含む。ビット０、１、２、３、４、５、６、７、および８はそれぞれ、毎秒８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０および４４，１００サンプルに割当てられるので、従ってビット位置は、異なるレートに割当てられる。ビット９乃至１５は要望どおり、将来のまたは代わりのレート使用のために予約され、従ってそれらは現在「０」に設定される。これらのビットの１つのビット値を「１」に設定することは、特定のサンプルレートがサポートされていることを示し、「０」に設定することは、サンプルレートがサポートされていないことを示す。
【０２６２】
［０３１１］最小サブフレームレートフィールド（２バイト）は毎秒ごとのフレーム内の最小サブフレームレートを指定する。最小サブフレームレートは、ディスプレイ内のあるセンサまたはポインティングデバイスをリードするために十分なディスプレイステータス更新レートを維持する。
【０２６３】
［０３１２］逆方向リンクのための２バイトマイクロフォンサンプルレート能力フィールドは、クライアントデバイス内のマイクロフォンのオーディオサンプルレート能力を示すフラッグのセットを含む。ＭＤＤＩのために、クライアント装置マイクロフォンは少なくとも毎秒８，０００サンプルレートを最低限サポートするように構成される。ビット位置０、１、２、３、４、５、６、７および８は、それぞれ毎秒８，０００、１６，０００、２４，０００、３２，０００、４０，０００、４８，０００、１１，０２５、２２，０５０および４４，１００サンプル（ＳＰＳ）を表すために使用されるので、このフィールドのビット位置は、異なるレートに割当てられる。ビット９乃至１５は将来の使用、または要望通り他の使用のために予約されるので、それらは現在「０」に設定される。これらのビットの１つに対してビット値を「１」に設定することは、特定のサンプルレートがサポートされることを示し、そのビットを「０」に設定することは、サンプルレートがサポートされないことを示す。マイクロフォンが接続されないなら、マイクロフォンサンプルレート能力ビットの各々はゼロに等しく設定される。
【０２６４】
［０３１３］コンテント保護タイプフィールド（２バイト）はディスプレイによりサポートされるデジタルコンテント保護のタイプを示すフラッグのセットを含む。現在、ビット位置０はいつＤＴＣＰがサポートされるかを示すために使用され、ビット位置１は、いつＨＤＣＰがサポートされるかを示すために使用され、ビット位置２乃至１５は、要望どおりのまたは利用可能な他の保護スキームと共に使用するために予約され、それらは現在ゼロに設定される。
【０２６５】
Ｇ．ディスプレイリクエストおよびステータスパケットについて
［０３１４］逆方向リンクリクエストフィールド（３バイト）は、情報をホストに送信するために次のサブフレームにおいて、逆方向リンクにおいて、ディスプレイが必要とするバイトの数を指定する。
【０２６６】
［０３１５］ＣＲＣエラーカウントフィールド（１バイト）は、メディアフレームの開始以来いくつのＣＲＣエラーが生じたかを示す。ゼロのサブフレームカウントを有するサブフレームヘッダパケットが送信されたとき、ＣＲＣカウントはリセットされる。ＣＲＣエラーの実際の数が２５５を越えるなら、この値は２５５で飽和する。
【０２６７】
［０３１６］能力変更フィールドは、ディスプレイの能力の変化を示すために１バイトを使用する。これは、ユーザがマイクロフォン、キーボードまたはディスプレイのような周辺装置を接続したとき、またはその他の理由で生じる。ビット［７：０］が０に等しいなら、ディスプレイ能力パケットが送信されてから能力は変わっていない。しかしながら、ビット［７：０］が１乃至２５５に等しいなら、能力は変更された。ディスプレイ能力パケットは新しいディスプレイ特性を決定するために調べられる。
【０２６８】
Ｈ．ビットブロック転送パケットについて
［０３１７］ウインドウ左上座標Ｘ値およびＹ値フィールドは、移動されるウインドウの左上角の座標のＸ値およびＹ値を指定するために各々２バイトを使用する。ウインドウ幅および高さフィールドは、移動されるウインドウの幅と高さを指定するために各々２バイトを使用する。ウインドウＸ移動フィールドおよびＹ移動フィールドは、それぞれウインドウが水平方向および垂直方向に移動しなければならないピクセル数を指定する。Ｘのための正の値は、ウインドウを右に移動させ、負の値は、ウインドウを左に移動させ、Ｙのための正の値はウインドウを下に移動させ、負の値はウインドウを上に移動させる。
【０２６９】
Ｉ．ビットマップエリアフィルパケット
［０３１８］ウインドウ左上座標Ｘ値フィールドおよびＹ値フィールドは、充填されるウインドウの左上角の座標のＸ値およびＹ値を指定するために各々２バイトを使用する。ウインドウ幅フィールドおよび高さフィールド（各々２バイト）は充填されるウインドウの幅と高さを指定する。ビデオデータフォーマットディスクリプタフィールド（２バイト）はピクセルエリア充填値のフォーマットを指定する。このフォーマットは、ビデオストリームパケット内の同じフィールドと同じである。ピクセルエリア充填値フィールド（４バイト）は、上述したフィールドにより指定されるウインドウに充填されるピクセル値を含む。このピクセルのフォーマットはビデオデータフォーマットディスクリプタフィールドにおいて指定される。
【０２７０】
Ｊ．ビットマップパターン充填パケットについて
［０３１９］ウインドウ左上座標Ｘ値フィールドおよびＹ値フィールドは、充填されるウインドウの左上角の座標のＸ値およびＹ値を指定するために各々２バイト使用する。ウインドウ幅フィールドおよび高さフィールド（各々２バイト）は充填されるウインドウの幅と高さを指定する。パターン幅フィールドおよび高さフィールド（各々２バイト）は、それぞれ充填パターンの幅と高さを指定する。２バイトビデオデータフォーマットディスクリプタフィールドはピクセルエリア充填値のフォーマットを指定する。図１１はどのようにして、ビデオデータフォーマットディスクリプタが符号化されるかを図解する。このフォーマットは、ビデオストリームパケット内の同じフィールドと同じである。
【０２７１】
［０３２０］パラメータＣＲＣフィールド（２バイト）はパケットレングスからビデオフォーマットディスクリプタまでのすべてのバイトのＣＲＣを含む。このＣＲＣがチェックに失敗するなら、全体のパケットが破棄される。パターンピクセルデータフィールドは、ビデオデータフォーマットディスクリプタにより指定されるフォーマット内で充填パターンを指定する生のビデオ情報を含む。データはバイトにパックされ、各行の最初のピクセルはバイトアラインされなければならない。充填パターンデータは、一時に１行送信される。パターンピクセルデータＣＲＣフィールド（２バイト）はパターンピクセルデータのみのＣＲＣを含む。このＣＲＣがチェックに失敗するなら、パターンピクセルデータは依然として使用されるが、ＣＲＣエラーカウントはインクリメントされなければならない。
【０２７２】
Ｋ．通信リンクデータチャネルパケット
［０３２１］パラメータＣＲＣフィールド（２バイト）はパケットレングスからパケットタイプまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックに失敗するなら、全体のパケットが破棄される。
【０２７３】
［０３２２］通信リンクデータフィールドは、通信チャネルからの生データを含む。このデータは、単に、ディスプレイ内の計算装置に渡される。
【０２７４】
［０３２３］通信リンクデータＣＲＣフィールド（２バイト）は通信リンクデータのみの１６ビットＣＲＣを含む。このＣＲＣがチェックに失敗するなら、通信リンクデータは依然として使用されまたは有用であるが、ＣＲＣエラーカウントはインクリメントされる。
【０２７５】
Ｉ．インターフェースタイプハンドオフリクエストパケット
［０３２４］インターフェースタイプフィールド（１バイト）は使用すべき新しいインターフェースを指定する。このフィールド内の値は、以下の方法でインターフェースタイプを指定する。ビット７の値が０に等しいなら、タイプハンドオフ要求は、順方向リンクに対してであり、１に等しいなら、タイプハンドオフリクエストは逆方向リンクに対してである。ビット６乃至３は将来の使用のために予約され、一般的にゼロに設定される。ビット２乃至０は使用されるインターフェースタイプを定義するために使用され、１の値はタイプ１モードへのハンドオフを意味し、２の値は、タイプ２モードへのハンドオフを意味し、３の値はタイプ３モードへのハンドオフを意味し、４の値はタイプ４モードへのハンドオフを意味する。０の値乃至５乃至７の値は、代わりのモードまたはモードの組合せの将来の指定のために予約される。
【０２７６】
Ｍ．インターフェースタイプアクノレジパケット
［０３２５］インターフェースタイプフィールド（１バイト）は使用すべき新しいインターフェースタイプを確認する値を有する。このフィールドの値は、以下の方法でインターフェースタイプを指定する。ビット７が０に等しいなら、タイプハンドオフリクエストは順方向リンクに対してであり、あるいは、１に等しいなら、タイプハンドオフリクエストは逆方向リンクに対してである。ビット位置６乃至３は要望どおり、他のハンドオフタイプを指定するのに使用するために現在予約され、一般的にゼロに設定される。しかしながら、ビット２乃至０は、負のアクノレジ、すなわち、要求されたハンドオフは実行できないことを示す０の値を用いて使用されるインターフェースタイプを定義するために使用され、１、２、３、および４の値はそれぞれタイプ１、タイプ２、タイプ３およびタイプ４へのハンドオフを示す。５乃至７の値は、要望どおり、モードの代わりの指定に使用するために予約される。
【０２７７】
Ｎ．実行タイプハンドオフパケットについて
［０３２６］１バイトインターフェースタイプフィールドは使用すべき新しいインターフェースタイプを示す。このフィールドに存在する値は、タイプハンドオフが順方向リンクに対してかまたは逆方向リンクに対してか否かを判断するためにビットの７の値を最初に用いてインターフェースタイプを指定する。「０」の値はタイプハンドオフリクエストが順方向リンクに対してであることを示し、「１」の値は逆方向リンクに対してであることを示す。ビット６乃至３は将来の使用のために予約され、一般的に０の値に設定される。しかしながら、ビット２乃至０は、使用されるインターフェースタイプを定義するために使用され、１，２，３、および４の値は、それぞれタイプ１、タイプ２、タイプ３およびタイプ４モードへのハンドオフの使用を指定する。これらのビットに対する値０および５乃至７の使用は将来の使用のために予約される。
【０２７８】
Ｏ．順方向オーディオチャネルイネーブルパケットについて
［０３２７］オーディオチャネルイネーブルマスクフィールド（１バイト）は、どのオーディオチャネルがクライアントにおいてイネーブルになるかを示すフラッグのグループを含む。１に設定されたビットは対応するチャネルをイネーブルにし、０に設定されたビットは対応するチャネルをディスエーブルにする。ビット０乃至ビット５は、それぞれ左前チャネル、右前チャネル、左後チャネル、右後チャネル、フロントセンタチャネル、およびサブウーファチャネルを指定するチャネル０乃至５を指定する。ビット６および７は将来の使用のために予約され、当分の間ゼロに設定される。
【０２７９】
Ｐ．逆方向オーディオサンプルレートパケットについて
［０３２８］オーディオサンプルレートフィールド（１バイト）はデジタルオーディオサンプルレートを指定する。このフィールドに対する値は、毎秒８，０００サンプル、１６，０００サンプル、２４，０００サンプル、３２，０００サンプル、４０，０００サンプル、４８，０００サンプル、１１，０２５サンプル、２２，０５０サンプル、および４４，１００サンプルを指定するために使用される０、１、２、３、４、５、６、７、および８の値と共に異なるレートに割当てられる。９乃至２５４の値は要望どおり代わりのレートに使用するために予約され、現在「０」に設定される。２５５の値は、逆方向リンクストリームをディスエーブルするために使用される。
【０２８０】
［０３２９］サンプルフォーマットフィールド（１バイト）はデジタルオーディオサンプルのフォーマットを指定する。ビット［１：０］が０に等しいとき、デジタルオーディオサンプルは線形フォーマットであり、ビット［１：０］が１に等しいとき、デジタルーディオサンプルはμ−Ｌａｗフォーマットであり、ビット［１：０］が２に等しい時、デジタルーオーディオサンプルはＡ−Ｌａｗフォーマットである。ビット［７：２］は要望通り、オーディオフォーマットを指定する際に代わりの使用のために予約され、一般的にゼロに等しく設定される。
【０２８１】
Ｑ．デジタルコンテント保護オーバーヘッドパケット
［０３３０］コンテント保護タイプフィールド（１バイト）は使用されるデジタルコンテント保護方法を指定する。０の値は、デジタル送信コンテント保護（ＤＴＣＰ）を指定し、１の値は高帯域デジタルコンテント保護システム（ＨＤＣＰ）を示す。２乃至２５５の値のレンジは現在指定されていないが、要望に応じて代わりの保護スキームと共に使用するために予約される。コンテント保護オーバーヘッドメッセージフィールドはホストとクライアントとの間で送信されるコンテント保護メッセージを含む可変長フィールドである。
【０２８２】
Ｒ．トランスペアレントカラーイネーブルパケットについて
［０３３１］トランスペアレントカラーイネーブルフィールド（１バイト）はいつトランスペアレントカラーモードがイネーブルになるかまたはディスエーブルになるかを指定する。ビット０が０に等しいなら、トランスペアレントカラーモードはディスエーブルされ、１に等しければ、トランスペアレントカラーモードはイネーブルされ、トランスペアレントカラーは以下の２つのパラメータにより指定される。このバイトのビット１乃至７は将来の使用のために予約され、ゼロに設定される。
【０２８３】
ビデオデータフォーマットディスクリプタフィールド（２バイト）はピクセルエリア充填値のフォーマットを指定する。図１１はどのようにビデオデータフォーマットディスクリプらが符号化されるかを図解する。このフォーマットは、一般的には、ビデオストリームパケット内の同じフィールドと同じである。
【０２８４】
［０３３２］ピクセルエリア充填値フィールドは、上で指定したウインドウに充填されるピクセル値に対して割当てられる４バイトを使用する。このピクセルのフォーマットはビデオデータフォーマットディスクリプタフィールドにおいて指定される。
【０２８５】
Ｓ．往復遅延測定パケットについて
［０３３３］パラメータＣＲＣフィールド（２バイト）はパケットレングスからパケットタイプまでのすべてのバイトの１６ビットＣＲＣを含む。このＣＲＣがチェックに失敗するなら、全体のパケットは破棄される。
【０２８６】
［０３３４］ストローブアラインメントフィールド（２バイト）は、このパケットのオールゼロフィールドの最初のビットの直前にビット境界においてＭＤＤＩ＿Ｓｔｂ信号がロウからハイへの遷移を行なうような値を含む。これは、このパケットが送信されるときに、測定期間内のバイト境界に関して一貫した方法でＭＤＤＩ＿Ｓｔｂ信号が振舞うことを保証する。
【０２８７】
［０３３５］オールゼロフィールド（１バイト）は最初のガードタイム期間中にラインドライバをディスエーブルする前にすべてのＭＤＤＩ＿Ｄａｔａ信号がゼロ状態になることを保証するためにゼロを含む。
【０２８８】
［０３３６］ガードタイム１フィールド（８バイト）はクライアント（ディスプレイ）内のラインドライバがイネーブルされる前にホスト内のＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブル可能にするために使用される。ホストは、ガードタイム１のビット０の期間ＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブルにし、ディスプレイは、ガードタイム１の最後のビットの直後にそのラインドライバをイネーブルにする。
【０２８９】
［０３３７］測定期間フィールドは、順方向リンク上で使用される１／２のデータレートで０ｘ００、０ｘ００、０ｘ０にディスプレイを応答可能にさせるために使用される５１２バイトウインドウである。このレートは、１の逆方向リンクレート除数に相当する。ディスプレイは、測定期間の開始時にすぐにこの応答を返す。この応答は、ホストにおいて測定期間の最初のビットの開始の後に、リンクの正確な往復遅延時にホストにおいて受信されるであろう。ディスプレイ内のＭＤＤＩ＿Ｄａｔａラインドライバは、ディスプレイからの０ｘｆｆ，０ｘ００応答の直前および直後にディスエーブルにされる。
【０２９０】
［０３３８］ガードタイム２フィールド（８バイト）の値は、ホスト内のラインドライバがイネーブルになる前にクライアントのＭＤＤＩ＿Ｄａｔａラインドライバをディスエーブル可能にする。ガードタイム２は常に存在するが、往復遅延が、測定期間内で測定できる最大量であるときに必要になるだけである。クライアントは、ガードタイム２のビット０の期間そのラインドライバをディスエーブルにし、ホストは、ガードタイム２の最後のビットの直後にそのラインドライバをイネーブルにする。
【０２９１】
「０３３９」ドライバ再イネーブルフィールド（１バイト）はゼロに等しく設定され、次のパケットのパケットレングスフィールドの前にすべてのＭＤＤＩ＿Ｄａｔａ信号が再イネーブルになることを保証する。
【０２９２】
１５．結論
［０３４０］この発明の種々の実施の形態について上述したけれども、一例としてのみ呈示され限定するためではないことを理解すべきである。従って、この発明の大きさおよび範囲は上述した例示実施の形態のいずれによっても限定されるべきではなく、以下のクレームおよびそれらの均等物に従ってのみ定義されるべきである。
【図面の簡単な説明】
【図１ａ】
［００２４］図１ａはこの発明が、ポータブルコンピュータと共に使用されるマイクロディスプレイ装置を含んで動作してもよい基本環境を図解する。
【図１ｂ】
［００２５］図１ｂは、この発明が、無線トランシーバと共に使用されるマイクロディスプレイ装置およびオーディオプレゼンテーションエレメントの使用を含んで動作してもよい基本環境を図解する。
【図２】
［００２６］図２はホストおよびクライアントの相互接続を有した移動デジタルデータインタフェースの全体の概念を図解する。
【図３】
［００２７］図３はクライアント装置からホスト装置へのデータ転送を実現するのに有用なパケットの構造を図解する。
【図４】
［００２８］図４はＭＤＤＩリンクコントローラの使用と、タイプＩインタフェースおよびタイプＵインタフェースのための物理データリンクコンダクタを介してホストとクライアントとの間で渡される信号のタイプを図解する。
【図５】
［００２９］図５は、ＭＤＤＩリンクコントローラの使用と、タイプＩＩインターフェース、タイプＩＩＩインターフェースおよびタイプＩＶインターフェースのための物理データリンクコンダクタを介してホストとクライアントとの間で渡される信号のタイプを図解する。
【図６】
［００３０］図６はインターフェースプロトコルを実現するために使用されるフレームおよびサブフレームの構造を図解する。
【図７】
［００３１］図７はインターフェースプロトコルを実現するために使用されるパケットの一般的構造を図解する。
【図８】
［００３２］図８はサブフレームヘッダーパケットのフォーマットを図解する。
【図９】
［００３３］図９はフィラーパケットのフォーマットおよび内容を図解する。
【図１０】
［００３４］図１０は、ビデオストリームパケットのフォーマットを図解する。
【図１１】
［００３５］図１１は、図１０のビデオデータフォーマットディスクリプタのフォーマットおよび内容を図解する。
【図１２】
［００３６］図１２はデータに対してパックされたフォーマットおよびパックされないフォーマットの使用を図解する。
【図１３】
［００３７］図１３は、オーディオストリームパケットのフォーマットを図解する。
【図１４】
［００３８］図１４は、データに対してバイト合わせされかつパックされたＰＣＭフォーマットの使用を図解する。
【図１５】
［００３９］図１５はユーザ定義されたストリームパケットのフォーマットを図解する。
【図１６】
［００４０］図１６は、カラーマップパケットのフォーマットを図解する。
【図１７】
［００４１］図１７は逆方向リンクカプセル化パケットのフォーマットを図解する。
【図１８】
［００４２］図１８はディスプレイ能力パケットのフォーマットを図解する。
【図１９】
［００４３］図１９はキーボードデータパケットのフォーマットを図解する。
【図２０】
［００４４］図２０は、ポインティングデバイスデータパケットのフォーマットを図解する。
【図２１】
［００４５］図２１は、リンク停止パケットのフォーマットを図解する。
【図２２】
［００４６］図２２はディスプレイリクエストおよびステータスパケットのフォーマットを図解する。
【図２３】
［００４７］図２３はビットブロック転送パケットのフォーマットを図解する。
【図２４】
［００４８］図２４は、ビットマップエリアフィルパケットのフォーマットを図解する。
【図２５】
［００４９］図２５は、ビットマップパターンフィルパケットのフォーマットを図解する。
【図２６】
［００５０］図２６は、通信リンクデータチャネルパケットのフォーマットを図解する。
【図２７】
［００５１］図２７は、インターフェースタイプハンドオフリクエストパケットのフォーマットを図解する。
【図２８】
［００５２］図２８は、インターフェースタイプアクノレジパケットのフォーマットを図解する。
【図２９】
［００５３］図２９は、パフォームタイプハンドオフパケットのフォーマットを図解する。
【図３０】
［００５４］図３０は順方向オーディオチャネルイネーブルパケットのフォーマットを図解する。
【図３１】
［００５５］図３１は逆方向オーディオサンプルレートパケットのフォーマットを図解する。
【図３２】
［００５６］図３２は、デジタルコンテントプロテクションオーバーヘッドパケットのフォーマットを図解する。
【図３３】
［００５７］図３３は、トランスペアレントカラーイネーブルパケットのフォーマットを図解する。
【図３４】
［００５８］図３４は、ラウンドトリップ（Ｒｏｕｎｄ Ｔｒｉｐ）遅延測定パケットのフォーマットを図解する。
【図３５】
［００５９］図３５は、ラウンドトリップ遅延測定パケットの期間のイベントのタイミングを図解する。
【図３６】
［００６０］図３６はこの発明に対して有用なＣＲＣ発生器およびチェッカのサンプル実現例を図解する。
【図３７ａ】
［００６１］図３７ａはデータパケットを送信するときの図３６の装置のためのＣＲＣ信号のタイミングを図解する。
【図３７ｂ】
［００６２］図３７ｂはデータパケットを受信するときの図３６の装置のためのＣＲＣ信号のタイミングを図解する。
【図３８】
［００６３］図３８は競合が起きない場合の典型的なサービスリクエストのための処理ステップを図解する。
【図３９】
［００６４］図３９は、リンクスタートと競合して、リンクリスタートシーケンスが開始された後でアサートされた典型的なサービスリクエストのための処理ステップを図解する。
【図４０】
［００６５］図４０は、ＤＡＴＡ−ＳＴＢ符号化を用いてどのようにデータシーケンスを送信できるかを図解する。
【図４１】
［００６６］図４１はホストにおいて、入力データからＤＡＴＡ信号およびＳＴＢ信号を発生し、次に、クライアントにおいて、データをリカバーするのに有用な回路を図解する。
【図４２】
［００６７］図４２は、この発明の実施の形態を実現するのに有用なドライバおよび終端抵抗を図解する。
【図４３】
［００６８］図４３は、ホストからのサービスを保証するためにクライアントにより採用され、およびそのようなサービスを供給するためにホストにより採用されるステップおよび信号レベルを図解する。
【図４４】
［００６９］図４４は、Ｄａｔａ０、他のデータライン（ＤａｔａＸ）およびストローブライン（Ｓｔｂ）に関して遷移間の相対的間隔を図解する。
【図４５】
［００７０］図４５は、パケットを送信後、ホストがホストドライバをディスエーブルするときに生じる応答での遅延の存在を図解する。
【図４６】
［００７１］図４６は、ホストがパケットを送信するためにホストドライバをイネーブルにするときに生じる応答での遅延の存在を図解する。
【図４７】
［００７２］図４７は、転送中のデータのタイミングと、ストローブパルスのリーディングエッジおよびトレーリングエッジとの間のホスト受信器の入力における関係を図解する。
【図４８】
［００７３］図４８は切換特性および逆方向データタイミングにより作られた対応するクライアント出力遅延を図解する。
【図４９】
［００７４］図４９は、ステートマシンを用いるこの発明に対して同期を実現することができる信号処理ステップの高レベル図を図解する。
【図５０】
［００７５］図５０は、ＭＤＤＩを採用するシステムにおける順方向路および逆方向路に関する信号処理に対して遭遇する遅延の典型的な量を図解する。
【図５１】
［００７６］図５１は、マージナル（ｍａｒｇｉｎａｌ）ラウンドトリップ遅延測定を図解する。
【図５２】
［００７７］図５２は逆方向リンクデータレートの変化を図解する。
【図５３】
［００７８］図５３は、逆方向レート除数対順方向リンクデータレートの値のグラフ表現を図解する。
【図５４ａ】
［００７９］図５４ａは、インターフェースの動作において実行されるステップを図解する。
【図５４ｂ】
図５４ｂは、インターフェースの動作において実行されるステップを図解する。
【図５５】
［００８０］図５５は、この発明の実施の形態を実現するためのドライバ、受信器、プロセッサおよびステートマシンの全体図を図解する。
【図１ａ】
2004531916.tif 000028
【図１ｂ】
2004531916.tif 000029
【図２】
2004531916.tif 000030
【図３】
2004531916.tif 000031
【図４】
2004531916.tif 000032
【図５】
2004531916.tif 000033
【図６】
2004531916.tif 000034
【図７】
2004531916.tif 000035
【図８】
2004531916.tif 000036
【図９】
2004531916.tif 000037
【図１０】
2004531916.tif 000038
【図１１】
2004531916.tif 000039
【図１２】
2004531916.tif 000040
【図１３】
2004531916.tif 000041
【図１４】
2004531916.tif 000042
【図１５】
2004531916.tif 000043
【図１６】
2004531916.tif 000044
【図１７】
2004531916.tif 000045
【図１８】
2004531916.tif 000046
【図１９】
2004531916.tif 000047
【図２０】
2004531916.tif 000048
【図２１】
2004531916.tif 000049
【図２２】
2004531916.tif 000050
【図２３】
2004531916.tif 000051
【図２４】
2004531916.tif 000052
【図２５】
2004531916.tif 000053
【図２６】
2004531916.tif 000054
【図２７】
2004531916.tif 000055
【図２８】
2004531916.tif 000056
【図２９】
2004531916.tif 000057
【図３０】
2004531916.tif 000058
【図３１】
2004531916.tif 000059
【図３２】
2004531916.tif 000060
【図３３】
2004531916.tif 000061
【図３４】
2004531916.tif 000062
【図３５】
2004531916.tif 000063
【図３６】
2004531916.tif 000064
【図３７ａ】
2004531916.tif 000065
【図３７ｂ】
2004531916.tif 000066
【図３８】
2004531916.tif 000067
【図３９】
2004531916.tif 000068
【図４０】
2004531916.tif 000069
【図４１】
2004531916.tif 000070
【図４２】
2004531916.tif 000071
【図４３】
2004531916.tif 000072
【図４４】
2004531916.tif 000073
【図４５】
2004531916.tif 000074
【図４６】
2004531916.tif 000075
【図４７】
2004531916.tif 000076
【図４８】
2004531916.tif 000077
【図４９】
2004531916.tif 000078
【図５０】
2004531916.tif 000079
【図５１】
2004531916.tif 000080
【図５２】
2004531916.tif 000081
【図５３】
2004531916.tif 000082
【図５４ａ】
2004531916.tif 000083
【図５４ｂ】
2004531916.tif 000084
【図５５】
2004531916.tif 000085
【国際公開パンフレット】
2004531916.tif 000086
2004531916.tif 000087
2004531916.tif 000088
2004531916.tif 000089
2004531916.tif 000090
2004531916.tif 000091
2004531916.tif 000092
2004531916.tif 000093
2004531916.tif 000094
2004531916.tif 000095
2004531916.tif 000096
2004531916.tif 000097
2004531916.tif 000098
2004531916.tif 000099
2004531916.tif 000100
2004531916.tif 000101
2004531916.tif 000102
2004531916.tif 000103
2004531916.tif 000104
2004531916.tif 000105
2004531916.tif 000106
2004531916.tif 000107
2004531916.tif 000108
2004531916.tif 000109
2004531916.tif 000110
2004531916.tif 000111
2004531916.tif 000112
2004531916.tif 000113
2004531916.tif 000114
2004531916.tif 000115
2004531916.tif 000116
2004531916.tif 000117
2004531916.tif 000118
2004531916.tif 000119
2004531916.tif 000120
2004531916.tif 000121
2004531916.tif 000122
2004531916.tif 000123
2004531916.tif 000124
2004531916.tif 000125
2004531916.tif 000126
2004531916.tif 000127
2004531916.tif 000128
2004531916.tif 000129
2004531916.tif 000130
2004531916.tif 000131
2004531916.tif 000132
2004531916.tif 000133
2004531916.tif 000134
2004531916.tif 000135
2004531916.tif 000136
2004531916.tif 000137
2004531916.tif 000138
2004531916.tif 000139
2004531916.tif 000140
2004531916.tif 000141
2004531916.tif 000142
2004531916.tif 000143
2004531916.tif 000144
2004531916.tif 000145
2004531916.tif 000146
2004531916.tif 000147
2004531916.tif 000148
2004531916.tif 000149
2004531916.tif 000150
2004531916.tif 000151
2004531916.tif 000152
2004531916.tif 000153
2004531916.tif 000154
2004531916.tif 000155
2004531916.tif 000156
2004531916.tif 000157
2004531916.tif 000158
2004531916.tif 000159
2004531916.tif 000160
2004531916.tif 000161
2004531916.tif 000162
2004531916.tif 000163
2004531916.tif 000164
2004531916.tif 000165
2004531916.tif 000166
2004531916.tif 000167
2004531916.tif 000168
2004531916.tif 000169
2004531916.tif 000170
2004531916.tif 000171
2004531916.tif 000172
2004531916.tif 000173
2004531916.tif 000174
2004531916.tif 000175
2004531916.tif 000176
2004531916.tif 000177
2004531916.tif 000178
2004531916.tif 000179
2004531916.tif 000180
2004531916.tif 000181
2004531916.tif 000182
2004531916.tif 000183
2004531916.tif 000184
2004531916.tif 000185
2004531916.tif 000186
2004531916.tif 000187
2004531916.tif 000188
2004531916.tif 000189
2004531916.tif 000190
2004531916.tif 000191
2004531916.tif 000192
2004531916.tif 000193
2004531916.tif 000194
2004531916.tif 000195
2004531916.tif 000196
2004531916.tif 000197
2004531916.tif 000198
2004531916.tif 000199
2004531916.tif 000200
2004531916.tif 000201
2004531916.tif 000202
2004531916.tif 000203
2004531916.tif 000204
2004531916.tif 000205
2004531916.tif 000206
2004531916.tif 000207
2004531916.tif 000208
2004531916.tif 000209
2004531916.tif 000210
2004531916.tif 000211
2004531916.tif 000212
2004531916.tif 000213
2004531916.tif 000214
2004531916.tif 000215
2004531916.tif 000216
2004531916.tif 000217
2004531916.tif 000218
2004531916.tif 000219
2004531916.tif 000220
2004531916.tif 000221
2004531916.tif 000222
2004531916.tif 000223
2004531916.tif 000224
2004531916.tif 000225
【国際公開パンフレット（コレクトバージョン）】
2004531916.tif 000226
2004531916.tif 000227
【国際調査報告】
2004531916.tif 000228
2004531916.tif 000229
2004531916.tif 000230
2004531916.tif 000231
2004531916.tif 000232