(57)【特許請求の範囲】
【請求項１】
ディスプレイと、
デジタルバスを介して周辺デバイスと相互接続され、前記周辺デバイスのオペレーションを制御するためのユーザインターフェースディスプレイを生成するための、第１と第２のユーザインターフェースモードのうちの１つに従ってフォーマットされたＯＳＤ（On Screen Display）信号を前記周辺デバイスから受信する通信インターフェースと、
前記ディスプレイと前記通信インターフェースに結合され、前記受信したＯＳＤ信号に応じて、該ＯＳＤ信号と結びついたそれぞれのプロセッシングモードに従ってＯＳＤ出力信号を生成し、該ＯＳＤ出力信号を前記ディスプレイに提供するプロセッサと
を具備するデジタルテレビジョン装置において、
前記プロセッサは、前記通信インターフェースを介して、デジタルテレビジョン装置に使われるリモートコントロールユニットから送信されたユーザコマンドに応答して、ユーザインターフェースモード選択ディスプレイを生成するためのＯＳＤ出力信号を生成し、該ＯＳＤ出力信号を前記ディスプレイに提供し、該ユーザインターフェースモード選択ディスプレイは前記第１のユーザインターフェースモードと前記第２のユーザインターフェースモードのうちの１つをデフォルトのユーザインターフェースモードとしてユーザが選択することを可能にするものであり、かつ
前記プロセッサは、前記通信インターフェースを介して、前記デフォルトのユーザインターフェースモードのユーザ選択の情報を前記周辺デバイスへ送信し、それにより前記周辺デバイスからの後続の前記ＯＳＤ信号が前記選択されたデフォルトのユーザインターフェースモードに従ってフォーマットされることを求めることを特徴とするデジタルテレビジョン装置。
【請求項２】
請求項１に記載のデジタルテレビジョン装置において、前記第１のユーザインターフェースは、ビットマップＯＳＤを利用していることを特徴とするデジタルテレビジョン装置。
【請求項３】
請求項１に記載のデジタルテレビジョン装置において、前記第２のユーザインターフェースは、記述言語を利用していることを特徴とするデジタルテレビジョン装置。
【請求項４】
請求項３に記載のデジタルテレビジョン装置において、前記記述言語は、ＨＴＭＬ、ＡＶＣパネルサブユニット、およびＨＡＶｉ ＤＤＩコントローラの１つを含むことを特徴とするデジタルテレビジョン装置。
【請求項５】
デジタルテレビジョン装置において、ユーザコマンドに応答してＯＳＤ（On Screen Display）信号を生成する方法であって、該方法は
前記デジタルテレビジョン装置にデジタル的に連結された周辺デバイスから、該周辺デバイスのオペレーションを制御するためのユーザインターフェースディスプレイを生成するための、第１と第２のユーザインターフェースモードのうちの１つに従ってフォーマットされたＯＳＤ信号を受信するステップと、
前記受信したＯＳＤ信号と結びついたそれぞれのプロセッシングモードに従ってＯＳＤ出力信号をディスプレイに提供するステップと、
前記第１ユーザインターフェースモードと前記第２のユーザインターフェースモードを含めて、利用可能なユーザインターフェースモードのタイプを前記ディスプレイに表示して、前記第１と第２のユーザインターフェースモードのうちの１つをデフォルトのインターフェースモードとしてユーザに選択させるユーザインターフェース選択スクリーンをユーザに提供するステップと、
前記ユーザによって選択されたデフォルトのユーザインターフェースモードを受け付けるステップと、
前記デフォルトのユーザインターフェースモードのユーザ選択の情報を前記周辺デバイスへ送信し、それにより前記周辺デバイスからの後続の前記ＯＳＤ信号が前記選択されたデフォルトユーザインターフェースモードに従ってフォーマットされることを要求するステップと
を含むことを特徴とする方法。
【請求項６】
請求項５に記載の方法において、前記第１のユーザインターフェースは、ＥＩＡ−７７５Ａに準拠するビットマップＯＳＤを利用していることを特徴とする方法。
【請求項７】
請求項５に記載の方法において、前記第２のユーザインターフェースは、ユーザが前記周辺デバイスを制御することを可能にする記述言語を利用していることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、前記記述言語は、ＨＴＭＬ、ＡＶＣパネルサブユニット、およびＨＡＶｉ  ＤＤＩコントローラの１つを含むことを特徴とする方法。
【請求項９】
デジタル映像処理装置において、ユーザコマンドに応答してＯＳＤ（On Screen Display）信号を生成する方法であって、該方法は
前記デジタル映像処理装置にデジタル的に連結された周辺デバイスから、該周辺デバイスのオペレーションを制御するためのユーザインターフェースディスプレイを生成するために、第１と第２のユーザインターフェースモードのうちの１つに従ってフォーマットされたＯＳＤ信号を受信するステップと、
前記受信されたＯＳＤ信号と結びついたそれぞれのプロセッシングモードに従ってＯＳＤ出力信号をディスプレイに提供するステップと、
前記第１と前記第２のユーザインターフェースモードと、該第１と該第２のユーザインターフェースモードのうちの１つに相当するデフォルトのインターフェースモードとを含めて、利用可能なユーザインターフェースモードのタイプを前記ディスプレイに表示するユーザインターフェース選択スクリーンをユーザに提供するステップと、
前記ユーザによって選択されたデフォルトのユーザインターフェースモードを受け付けるステップと、
前記デフォルトのユーザインターフェースモードのユーザ選択の情報を前記周辺デバイスへ送信し、それにより前記周辺デバイスからの後続のＯＳＤ信号が前記選択されたデフォルトのユーザインターフェースモードに従ってフォーマットされることを要求するステップと
を含むことを特徴とする方法。
【請求項１０】
請求項９に記載の方法において、前記デフォルトインターフェースモードはインターフェースモードの所定のハイアラキーに基づいて選択されたユーザインターフェースモードに相当することを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、インターフェースモードの前記所定ハイアラキーは、少なくともビットマップベースのＯＳＤと記述言語ベースのＯＳＤとを含んでいることを特徴とする方法。
【請求項１２】
請求項１１に記載の方法において、前記記述言語は、ＨＴＭＬ、ＡＶＣパネルサブユニット、およびＨＡＶｉ  ＤＤＩコントローラの１つを含むことを特徴とする方法。
【請求項１３】
請求項１１に記載の方法において、インターフェースモードの前記所定のハイアラキーを変更するオプションを前記ユーザに提供するステップを更に含むことを特徴とする方法。
【請求項１４】
請求項１３に記載の方法において、前記オプションは、デバイス選択メニューから前記周辺デバイスをユーザが選択する際に提供されることを特徴とする方法。
【請求項１５】
デジタル映像処理装置に使われるリモートコントロールユニットから送信されたユーザコマンドに応答して、ＯＳＤ（On Screen Display）信号を提供するプロセッサと、
前記プロセッサに結合され、前記デジタル映像処理装置とデジタル的に相互接続された周辺デバイスと通信して、前記デジタル映像処理装置のオペレーションを制御するためのユーザインターフェースディスプレイを生成するための、第１と第２のユーザインターフェースモードのうちの１つに従ってフォーマットされたＯＳＤ信号を前記周辺デバイスへ送信する通信インターフェースと
を具備するデジタル映像処理装置であって、
前記通信インターフェースはデフォルトのユーザインターフェースモードのユーザ選択を示すメッセージを前記周辺装置から受信するのに適応しており、前記プロセッサは該メッセージに応答して前記デフォルトのユーザインターフェースモードに従って後続ＯＳＤ信号を発生することを特徴とするデジタル映像処理装置。
【請求項１６】
請求項１５に記載のデジタル映像処理装置において、前記デフォルトインターフェースモードはインターフェースモードの所定のハイアラキーに基づいて選択されたユーザインターフェースモードに相当することを特徴とするデジタル映像処理装置。
【請求項１７】
請求項１６に記載のデジタル映像処理装置において、インターフェースモードの前記所定ハイアラキーは、少なくともビットマップベースのＯＳＤと記述言語ベースのＯＳＤとを含んでいることを特徴とするデジタル映像処理装置。
【請求項１８】
請求項１７に記載のデジタル映像処理装置において、前記記述言語は、ＨＴＭＬ、ＡＶＣパネルサブユニット、およびＨＡＶｉ  ＤＤＩコントローラの１つを含むことを特徴とするデジタル映像処理装置。
【請求項１９】
デジタル映像処理装置において、ユーザコマンドに応答してＯＳＤ（On Screen Display）信号を生成する方法において、該方法は、
前記デジタル映像処理装置に使われるリモートコントロールから送信されたユーザコマンドに応答して、前記周辺デバイスのオペレーションを制御するためのユーザインターフェースディスプレイを生成するための、第１と第２のユーザインターフェースモードのうちの１つに従ってフォーマットされたＯＳＤ信号を生成するステップと、
前記デジタル映像処理装置とデジタル的に連結した周辺装置へ前記ＯＳＤ信号を送信するステップと、
前記第１と第２のユーザインターフェースモードのうちの１つに対応してデフォルトのユーザインターフェースモードのユーザ選択を示すメッセージを前記周辺デバイスから受信するステップと、
前記ユーザ選択を示す前記メッセージに応答して前記デフォルトのユーザインターフェースモードに従って後続のＯＳＤ信号を生成するステップと
を含むことを特徴とする方法。
【請求項２０】
請求項１９に記載の方法において、前記デフォルトインターフェースモードはインターフェースモードの所定のハイアラキーに基づいて選択されたユーザインターフェースモードに相当することを特徴とする方法。
【請求項２１】
請求項２０に記載の方法において、インターフェースモードの前記所定ハイアラキーは、少なくともビットマップベースのＯＳＤと記述言語ベースのＯＳＤとを含んでいることを特徴とする方法。
【請求項２２】
請求項２１に記載の方法において、前記記述言語は、ＨＴＭＬ、ＡＶＣパネルサブユニット、およびＨＡＶｉ  ＤＤＩコントローラの１つを含むことを特徴とする方法。
【発明の詳細な説明】
【０００１】
発明の分野
本発明は、コンシューマエレクトロニックデバイス（家庭用電化製品）などの、複数のエレクトロニックデバイス（電子機器）を、デジタルデータバスなどの相互接続を介して制御するためのシステムに関する。さらに具体的には、本発明は、かかるデバイスの相互運用性 (interoperability) を管理するための構成に関する。
【０００２】
発明の背景
データバスは、テレビジョン受信機、ディスプレイデバイス、ビデオカセットレコーダ (video-cassette recorder  VCR)、直接放送衛星 (direct broadcast satellite  DBS) 受信機、およびホームコントロールデバイス（例えば、セキュリティシステムまたは温度制御デバイス）などの、エレクトロニックデバイスを相互接続するために利用することができる。データバスを使用したコミュニケーション（通信）は、バスプロトコルに従って行われている。バスプロトコルの例としては、コンシューマエレクトロニクスバス (Consumer Electronics Bus  CEBus) およびIEEE 1394ハイパフォーマンスシリアルバス (High Performance Serial Bus) がある。
【０００３】
バスプロトコルは、制御情報とデータの両方を通信できるようにしているのが代表的である。例えば、CEBus制御情報は、米国電子工業会 (Electronics Industries Association  EIA) 規格IS-60に定義されているプロトコルをもつ「制御チャネル (control channel)」上を通信されている。IEEE 1394シリアルバスでは、制御情報は、シリアルバスの非同期サービスを使用して受け渡しされているのが一般的である。特定のアプリケーションのための制御情報は、例えば、共通アプリケーション言語 (Common Application Language  CAL) またはAV/Cを使用して定義することができる。
【０００４】
現在では、大部分のA/Vデバイスは、リモートコントロール (remote control  RC：リモコン) ユニットを使用して制御されている。周辺（peripheral）デバイスとRCユニット間のプロトコルはデバイス固有 (device specific) であるため、各デバイスには、独自のRCユニットが付いている。このような周辺デバイスの各々は、キーが押されたことを、その直接リンクを通して受け取ると、それを解釈し、対応するアクションを実行している。
【０００５】
現在のアナログオーディオ/ビデオ (A/V) 群（クラスタ）では、制御側周辺デバイスが、ディスプレイデバイス（例えば、TV）上でオンスクリーンディスプレイ (On-Screen Display  OSD) メカニズム（機構）を起動（アクチベート）することがあるが、必ずしもそうすることが要件になっていない。この種のA/VデバイスのOSDは、周辺デバイスまたはターゲットデバイス（例えば、デジタルVCR）で生成され、他のビデオ信号と同じようにそのデバイスのNTSC出力から出力されている。従って、周辺デバイスとディスプレイデバイスのどちらにも、追加ハードウェアやソフトウェアは必要とされていない。図１は、VCR１２とディスプレイデバイス１４（例えば、テレビジョン）を備え、この種の制御方法を採用しているA/Vシステム１０を示している。制御側VCR１２に関連するメニューは、VCR１２によって生成され、VCR１２のNTSC出力から複合ビデオ (composite video) としてディスプレイデバイス１４に入力されている。
【０００６】
残念ながら、ディスプレイデバイス１２'と同じアプローチ（図２参照）をデジタルTV (DTV) で使用すると、メニューをMPEG-2トランスポートストリームとしてトランスポート（移送）する必要が起こるので、その使用は実用的でない。この種のストリームを生成するには、MPEG符号器（エンコーダ）１５'をすべての周辺デバイスに組み込む必要があるため、そのようなコンシューマエレクトロニックデバイスはコストが大幅に増加し、複雑化している。さらに、制御側デバイスと周辺デバイスに関連するGUIはそれぞれが異なっているため、ユーザは複数のリモートコントロールデバイス（リモコン装置）を採用する必要があり、そのことは、ユーザにとって不都合の原因になっている。さらに、複数のエレクトロニックデバイスを含むシステムをユーザが制御できるようにするオンスクリーンディスプレイが得られるように、ディスカバリ (discovery) モードを改善することが要望されている。
【０００７】
発明の概要
本発明は、共通コンシューマエレクトロニック (consumer electronic  CE) デバイスの間でオーディオ/ビデオ (A/V) コンテンツとコントロールをやりとりするときの相互運用性 (interoperability) を向上することを目的としている。インタフェースは、物理層とリンク層ではIEEE 1394シリアルバスに準拠しており、AV/CやCALなどの、適当な制御言語を利用してOSDを管理し、デジタルシリアルバスを介して相互接続されたデバイスの接続性 (connectivity) を制御している。
【０００８】
一実施形態では、本発明によれば、プロセッサと、プロセッサに結合されていて、複数のデバイスアイコンに関連するデータがそこに格納されているメモリと、デジタルバスによって相互接続された周辺（peripheral）デバイスと通信する手段とを備えたデジタルテレビジョン装置が提供されており、そこでは、周辺デバイスは、識別データがそこに格納されているメモリを装備し、通信する手段は、セットアップモードにあるとき識別データをプロセッサに転送し、プロセッサは、識別データを複数のデバイスのうちの１つと相関づけ、相関づけたデバイスアイコンがそこに表示されているデバイス選択スクリーンに関連する表示データを生成するようにしている。
【０００９】
別の実施形態では、本発明によれば、プロセッサと、プロセッサに結合されていて、デジタルバスによって相互接続された周辺デバイスと通信する手段とを備えたデジタルテレビジョン装置が提供されており、そこでは、周辺デバイスは、識別データがそこに格納されているメモリを装備し、通信する手段は、周辺デバイスからデジタルテレビジョン装置にプログラムデータを転送するときの必要ビットレートを指定するデータを含めて、識別データをプロセッサに転送し、プロセッサは、識別データに応じて確定されたバンド幅をもつアイソクロナスチャネル (isochronous channel) をデジタルバス上に確立するようにしている。
【００１０】
別の実施形態では、本発明によれば、ディスプレイと、ディスプレイに結合されていて、デジタルテレビジョン装置に関連するリモートコントロールユニットから伝送されたユーザコマンドに応答して、第１ユーザインタフェースモードに従ってOSD信号を生成するプロセッサと、プロセッサに結合されていて、デジタルバスによって相互接続された周辺デバイスと通信する手段とを備えたデジタルテレビジョン装置が提供されており、そこでは、周辺デバイスは、その周辺デバイスに関連する第２リモートコントロールユニットから伝送されたユーザコマンドに応答して、第２ユーザインタフェースモードに従ってOSD信号を生成し、プロセッサは、あらかじめ決められたユーザコマンドに応答して、ユーザインタフェースモード選択ディスプレイを生成するOSD信号を生成し、ユーザインタフェースモード選択ディスプレイは、第１ユーザインタフェースモードと第２ユーザインタフェースモードのうちの１つを、ユーザがデフォルトユーザインタフェースモードとして選択することを可能にし、プロセッサはユーザがデフォルトモードを選択したことに応答して、第１ユーザインタフェースモードと第２ユーザインタフェースモードのうちの１つに従ってOSD信号を生成するようにしている。
【００１１】
以下では、本発明の理解を容易にするために、添付図面を参照して説明することにする。なお、図面において、各図で同一の参照符号は、特徴が同じまたは類似していることを示している。
【００１２】
詳細な説明
IEEE 1394シリアルバスの使用は、ホームネットワーク環境内の多くのアプリケーション用に提案されている。このシリアルバスは、次世代PCに組み込まれつつあり、ディスクドライブを含む、多くのローカル周辺用に使用されようとしている。さらに、デジタルテレビジョン (DTV) やデジタルビデオカセットレコーダ (DVHS) などの、ディジタルオーディオ/ビデオコンシューマエレクトロニックデバイスは、これらのデバイスを相互接続するためにシリアルバスを利用する可能性がある。
【００１３】
IEEE-1394は、周辺またはバックプレーン (back-plane) バスとして使用するために開発された高速で、低コストのデジタルシリアルバスである。このバスの顕著な特徴のいくつかを挙げると、ダイナミックなノードアドレス割り当て、データレートが100、200、および400 Mビット/秒であること、非同期モードとアイソクロナス (isochronous−等時性) モード、公平なバスアービトレーション、およびISO/IEC 13213と整合性があること、などがある。図３は、IEEE-1394シリアルバス１６が３スタック層であるときのシリアルバスプロトコルを示す図である。
【００１４】
物理層１８は、パワーアップ時の初期化、アービトレーション、バスリセット感知、およびデータシグナリングを担当する物理シグナリング回路とロジックから構成されている。２つのシールドされた低電圧差分信号ペア (low-voltage differential signal pairs) は、パワーペア (power pair) と共に、IEEE-1394シリアルケーブル用に定義されている。シグナリングは、ジッタ許容範囲を２倍にするデータストローブビットレベルの符号化（エンコード）を使用して行われている。
【００１５】
データは、リンク層２０でパケット化されている。デバイス相互間のデータ通信は、非同期とアイソクロナスの２クラスがサポートされている。非同期通信は、「肯定応答を許容する(allows acknowledgement)」と特徴づけることができるのに対し、アイソクロナス通信は、「常時オンタイム(always on time)」と特徴づけることができる。非同期サービスは、主にコントロールとステータスメッセージ用に使用されるのに対し、アイソクロナス通信は、MPEGビデオなどのデータストリーム用に使用されている。アイソクロナス通信のタイムリ性は、サイクルを125μ秒ごとにすることによって達成されている。アイソクロナスサイクルは、非同期通信に優先している。
【００１６】
非同期転送は、バスが空きになっているときいつでも行うことができる。125μ秒ごとのサイクルのうちの最低25μ秒は、非同期データ転送用に予約されている。アイソクロナス転送によると、リアルタイムのデータ転送メカニズムが得られる。１つまたは２つ以上のデバイス間の進行中アイソクロナス通信は、チャネルと呼ばれている。このチャネルは最初に確立する必要があり、そうすれば、要求側デバイスは、サイクルごとに要求したバス時間量をもつことが保証される。
【００１７】
トランザクション層２２では、バストランザクションを実行するための、完全な要求−応答プロトコルが定義されている。トランザクション層２２には、アイソクロナスデータ転送のための、どのサービスも追加されていないが、この層が通路 (path) となって、アイソクロナスサービスに必要なリソース管理を行うことを可能にしている。これは、制御ステータスレジストリ (control status registry  CSR) への読み書きを通して行われる。トランザクション層２２には、リソースが使用中のため、応答ができないような事態が起こったとき、それを処理するための再試行 (retry) メカニズムも定義されている。非同期データは、次の３トランザクションの１つを利用して、IEEE-1394ノード相互間で転送される。すなわち、別のノードからデータを取り出すための "read-data"（データ読み取り）、別のノードにデータを転送するための "write-data"（データ書き込み）、および処理のために別のノードにデータを転送するための "lock-data"（データロック）であり、そのあと、データは要求元ノードに送り返される。
【００１８】
シリアルバス管理２４は、プロトコル、サービス、および操作プロシージャを記述している。これらによると、あるノードが選択されると、そのノードは、バス上の残りのノードのオペレーションに対して管理レベルの制御を行えるようにしている。IEEE-1394シリアルバスでは、２つの管理エンティティが定義されている。アイソクロナスリソースマネージャ (isochronous resource manager) ２６とバスマネージャ (bus manager) ２８である。これらの２エンティティは、２つの異なるノードに置いておくことも、同じノードに置いておくこともできる。単独のバスマネージャ２８は、バスから切り離しておくことができる。そのような場合には、そのバスマネージャ２８が通常受け持っている管理責任のサブセットを、アイソクロナスリソースマネージャ２６に任せることができる。バスマネージャ２８は、いくつかのサービスを提供しており、その中には、速度とトポロジカルマップ (topological map) の維持とバス最適化が含まれている。アイソクロナスリソースマネージャ２６は、アイソクロナスバンド幅の割り振り、チャネル番号の割り振り、およびサイクルマスタの選択を行う機能を備えている。
【００１９】
ノードコントロールはすべてのノードで要求されている。そのために、ノードコントローラ３０は、すべてのバスノードが必要とするCSRを実装しており、物理層１８、リンク層２０、およびトランザクション層２２と、さらにデバイスにアプリケーションが存在していれば、そのアプリケーションと通信する。ノードコントローラコンポーネント３０は、CSRと環境設定ROM機能と共に、個別ノードでのアクティビティを構成し、管理するために使用される。
【００２０】
IEEE 1394シリアルバスが正しく機能するためには、アイソクロナスリソースマネージャ (isochronous resource manager  IRM) とバスマネージャ (bus manager  BM) が必要になる。大部分のクラスタ（つまり、デジタルバスを介して相互接続されたデバイス）は、ある種のディスプレイデバイスを装備しているので、アナログディスプレイとDTV付きのセットトップボックス (Set Top Box) は、IRMとBM対応になっていることが要件になっている。オールオーディオクラスタ (all audio cluster) のような、いくつかのケースでは、ディスプレイデバイスが存在していないことがある。このケースでは、デジタルオーディオアンプ (Digital Audio Amp) もIRMとBM対応になっていることが要件になっている。
【００２１】
IRM２６は、秩序正しいアイソクロナスオペレーションに必要である、アイソクロナスリソース（チャネルとバンド幅）を、シリアルバスが協働して割り振り、その割り振りを解除するために必要とされるリソースを備えている。IRM２６は、他のノードがチャネルとバンド幅の利用可能性をチェックし、新しい割り振りを登録するときの共通ロケーションとなっている。IRM２６は、自己識別プロセス (self identify process) が完了すると、そのロケーションが即時に分かるようになっているので、シリアルバスのノードが、もし存在していれば、BM２８のIDを判断するときの共通ロケーションともなっている。
【００２２】
BM２８は、もし存在していれば、シリアルバス上の他のノードに管理サービスを提供する。管理サービスとしては、サイクルマスタのアクチベーション、パフォーマンス最適化、パワー（電源）管理、速度管理、およびトポロジ管理がある。
【００２３】
アプリケーションがコネクションを確立し、コネクションをオーバレーし、コネクションを切り離すことを可能にする、いくつかの管理プロシージャがコネクションタイプごとに用意されている。これらのプロシージャでは、IEEE-1394リソースを割り振ること、該当値をプラグコントロールレジスタにセットすること、起こり得る失敗条件をアプリケーションに報告すること、およびバスリセット後のコネクションを管理すること、などが行われる。この種のCMPの１つについて、以下で説明する。
【００２４】
IEEE 1394シリアルバス上の２つのA/Vデバイス間でアイソクロナスデータをトランスポートするためには、１つのアイソクロナスチャネルを使用して、送信側デバイスの出力プラグを受信側デバイスの入力プラグに接続することが必要である。１つの入力プラグ、１つの出力プラグおよび１つのアイソクロナスチャネル相互間の関係は、ポイントツーポイント (point-to-point) コネクションと呼ばれている。同様に、ブロードキャストアウトコネクション（１つの出力プラグと１つのアイソクロナスチャネル）およびブロードキャストインコネクション（１つの入力プラグと１つのアイソクロナスチャネル）が存在している。
【００２５】
アイソクロナスデータのフローは、送信側に置かれている１つの出力プラグコントロールレジスタ (oPCR) と１つの出力マスタプラグレジスタ (oMPR) によって制御される。oMPRは、対応するA/Vデバイスによって送信されるすべてのアイソクロナスフローに共通している、すべての属性（例えば、データレート能力、ブロードキャストチャネルベースなど）を制御する。
【００２６】
入力プラグを通過するアイソクロナスデータフローの受信は、受信側デバイスに置かれている１つの入力プラグコントロールレジスタ (iPCR) と１つの入力マスタプラグレジスタ (iMPR) によって制御される。iMPRは、対応するデバイスによって受信されるすべてのアイソクロナスデータフローに共通している、すべての属性（例えば、データレート能力など）を制御する。
【００２７】
コネクションを確立する際に係わりをもつ主要ステップは、IEEE 1394リソース（例えば、バンド幅）を割り振り、チャネル、データレート、オーバヘッドIDおよびコネクションカウンタをoPCRとiPCRにセットすることである。
【００２８】
アイソクロナスデータフローは、IEEE 1394シリアルバスに接続されたどのデバイスによっても、対応するプラグコントロールレジスタを変更することによって制御することができる。プラグコントロールレジスタは、IEEEシリアルバス上の非同期トランザクションによっても変更することができるが、コネクション管理は、AV/Cの使用を通して行うことが好ましい。コネクション管理にCALを採用することも、本発明の範囲に属している。
【００２９】
コンシューマエレクトロニックデバイスがIEEE 1394シリアルバスを介して相互接続された他のデバイスとやりとりするためには、共通プロダクトモードと共通コマンドセットが定義されていなければならない。デバイスモデリングとコントロールのための３つの標準的アプローチとしては、CAL、AV/Cおよびユニバーサルシリアルバス (Universal Serial Bus  USB) 用に採用されたアプローチがある。
【００３０】
CALとAV/Cは、論理エンティティと物理エンティティとを区別する制御言語である。例えば、テレビジョン（つまり、物理エンティティ）は、チューナ、オーディオ増幅器などの、いくつかの機能コンポーネント（つまり、論理エンティティ）を装備することが可能になっている。この制御言語は、リソース割り振りとコントロールという、２つの主要機能を備えている。リソース割り振りは、総称ネットワーク (Generic Network) リソースを要求し、使用し、解放することを扱っている。メッセージとコントロールは、IEC-61883に定義されているFCPによって、上述したようにトランスポートされる。例えば、CALは、そのコマンドシンタックスにオブジェクトベースの方法を採用している。オブジェクトは、インスタンス変数 (instance variable  IV) と呼ばれる、一定数の内部値を収めており、これらの内部値への独占的アクセス権を有している。各オブジェクトは、内部メソッドリストを保持している。メソッドは、メッセージを受信すると、その結果としてオブジェクトによって取られるアクションである。あるメソッドが起動 (invoke) されると、１つまたは２つ以上のIVが更新されるのが通常である。メッセージは、メッセージIDと、そのあとに続くゼロ個または１個以上のパラメータとから構成されている。オブジェクトはメソッドを受信すると、そのメソッドリストを調べ、メッセージに示されているメソッドに一致するものを探し出す。見つかると、そのメソッドが実行される。メッセージに付属しているパラメータから、メソッドの正確な実行が判断される。
【００３１】
現在のアナログオーディオ/ビデオデバイス (A/V) でユーザがマシンに入力する主要手段は、リモートコントロール (remote control  RC) ユニットとフロントパネルを使用することである。このやりとりのいくつかは、オンスクリーンディスプレイ (on-screen display  OSD) メカニズムも利用している。この種のやりとりでは、ユーザは、周辺と直接にやりとりしている。現在のリモートコントロールの場合には、使用されるメッセージングプロトコルは、デバイスおよび/またはメーカ固有になっている。周辺デバイスは、受信したコマンドを処理し、要求されたアクションを実行する。OSDが使用される場合は、そこには、処理されたRCキーを記録しておくことと、表示されたOSDをキーが押されるたびに、それに応じて更新することが含まれている。
【００３２】
図４は、IEEE 1394によって相互接続され、本発明による相互運用性に適しているA/Vクラスタを示す図である。図４には、DVCR１２"と相互接続されたDTV１４"が示されているが、当然に理解されるように、本発明の原理は、適当なコントロール・ディスプレイデバイスと周辺デバイス間の相互接続に適用可能であり、周辺デバイスの中には、DVDプレイヤ、PVR、DBS受信機、およびケーブルSTBが含まれているが、それらに限定されない。
【００３３】
図４に示すように、プログラムデータは、MPEG-TSデータとしてバス１６"を通してDTV１４"に転送される。リモートコントロール１３"から送信されたユーザコマンドに応答して生成されるOSDに関連するビットマップ (bitmapped) メニューまたはデバイス１２"によって生成されるステータス情報は、デジタルバス１６"を通して別々に伝送される。種々の制御コマンドを含むオーバレー制御情報も、デジタルバス１６"を介して伝送される。復号化（デコード）されたプログラム情報とメニュー情報は、オーバレー４２によって結合され、ディスプレイユニット４６から表示される。プログラム情報をMPEG-TSデータとしてMPEG復号器（デコーダ）３８に転送し、ビットマップメニュー情報をビットバッファ４４に転送するので、本発明によれば、追加のMPEG復号器と符号器を、周辺デバイス１２"に組み入れる必要がない。以下で述べるように、種々のコントロールとステータス情報も、デジタルバスを介してDTV１４"と周辺デバイス１２"の間で転送することが容易化されている。
【００３４】
ディスカバリプロセス
本発明による相互運用性には、ディスカバリプロセス (discovery process) が含まれている。このディスカバリプロセスによると、制御側デバイスは、ネットワーク内の他のデバイスを見つけることができる。このプロセスはバスリセットによってアクチベートされ、ネットワーク上に存在するデバイスをサーチし、見つけるのに役立っている。バスリセットは、デバイスを接続/切り離すと行われ、ソフトウェアによるリセットなどによっても行われる。このソフトウェアモジュールは、各デバイスの環境設定ROMに格納されている、一部の情報を頼りにしている。この情報は、自己記述デバイステーブル (Self Description Device Table  SDDT) と呼ばれ、モデル番号、メニューのロケーション、URL、EUIベンダIDなどの情報を内容としている。
【００３５】
制御側デバイスまたはディスプレイデバイスのSDDTには、デバイスの表示能力に関する情報を収めている情報ブロックを指すポインタが入っている。情報ブロックの内容としては、ディスプレイのタイプ（インタレースまたはプログレッシブ）、ラインごとの最大バイト数、サポートされる解像度モード（全、1/2、1/3）、サポートされるミックス重み (mix weight)、パレットモードのときサポートされる最大ビット数/ピクセル数 (2、4、8)、およびサポートされる最大ブロックサイズがある。CAL用に定義されたホームプラグアンドプレイ (Home Plug and Play) またはAV/C用に定義されたサブユニット記述子 (subunit descriptor) のように、他のディスカバリ方法を使用してこの情報を取得することも可能である。
【００３６】
バス初期化が完了すると、制御側デバイスのディスカバリマネージャは、接続されている各デバイスのROMに置かれているSDDTを読み取る。この情報は、レジストリテーブルに組み込まれている。IEEE 1394シリアルバス上の各デバイスは、バス上の他のデバイスとその能力を記録しておくために使用されるレジストリテーブルをもっている。バス上のすべてのデバイスについて、このレジストリテーブル（またはレジストリ）は、ディスカバリプロセスの期間に更新される。レジストリは、揮発性の特性（例えば、1394 node_ID、IPアドレスなど）、1394バス上の特定ノードを識別するための不揮発性の64ビットEUI（Extended Unique Identifier−拡張ユニーク識別子）をマッピングするためのサービスをアプリケーションに提供している。
【００３７】
レジストリテーブルは、各デバイス内のレジストリマネージャによって維持され、各ノードが以前に指定されたサービスを提供するための情報を収めている。このレジストリテーブルは、バスリセットが行われると、ディスカバリマネージャによって絶えず更新されている。このレジストリテーブルの構造例は、以下に示すとおりである。
【００３８】
【表１】
0004851675.tif 000002
【００３９】
レジストリテーブルの各フィールドは、次のように定義されている。
・  64ビットEUIは、全世界にわたって製造されたすべてのシリアルバスノード間の特定ノードをユニークに識別する64ビット番号である。
・  1394 node_IDは、IEEE 1394シリアルバスサブネット内の特定シリアルバスノードをユニークに識別する16ビット番号である。最上位10ビットはバスID、最下位ビットは物理IDである。バスIDは、ブリッジされたバスグループ内の特定バスをユニークに識別している。物理IDは、自己識別プロセス期間にダイナミックに割り当てられる。
・  IPアドレスは、ダイナミックに割り当てられる32ビットのプライベートIPアドレスである。
・  メーカ/モデル番号は、デバイスのSDDTから取得され、ソースを選択するときの可能性をカストマに通知するために使用される。
・  デバイスタイプも、デバイスのSDDTから取得され、ソースを選択するときの可能性をカストマに通知するために使用される。このフィールドは、どのストリームフォーマットを使用すべきかを判断するときにも使用すると、便利である。例えば、ゲームマシンは、MPEG 2を出力フォーマットとして使用しないことがある。
【００４０】
レジストリは、ホームネットワーク上の任意ノードのIEEE 1394シリアルバスアドレスを、そのノードの64ビットEUIに基づいて判断するときに使用することができる。EUIのような安定識別子と相関づけることは、ノードアドレスがバスリセット期間に変化することがあるので、重要である。
【００４１】
CEデバイスの各々では、上述したようにインストール時になんらかのセットアップが行われ（デバイスセットアップマネージャの使用を通して）、クラスタ上の他のデバイスがそのデバイスの出力または入力チャネルに対応付けられる（マッピングされる）。このことは、IEEE 1394アイソクロナスチャネルがそのとき割り振られることを、必ずしも意味していない。各デバイスが、SDDTを調べることによってネットワーク上に見つけたデバイスに選択メニューをロードするだけにすることも可能である。やりとりは、最初にディスプレイデバイスにアドレスし（この例では、デジタルであると想定されている）、ユーザが制御することを望んでいるデバイス（例えば、デジタルVCR）を選択することから開始される。これが行われるとき、アイソクロナスチャネルは、DVHSとディスプレイデバイスの間でセットアップされる。
【００４２】
上述したように、環境設定ROMとAV/C Info Blocksを使用すると、バス上の他のデバイスの能力を知ることができる。例えば、EIA 775Aのように、多くの標準で規定されている環境設定ROMの１つのエレメントとして、モデル名記述子 (Model Name Descriptor) フィールドがある。この記述子はASCIIテキストを収めているのが代表的であり、ほかになにが入っているかを知る手がかりがない。ソースデバイスのタイプを知らなくても済むことがあるので、その一部は設計に任されている。この記述子が意図する一般的目的は、ビデオおよび/またはOSDを表示できるデバイスに対して基本的サポートを提供する総称テキスト記述 (generic text descriptor) を組み入れることである。つまり、記述子の意図は、デスティネーションデバイス、例えば、DTVがテキスト記述を使用してソース選択スクリーンを構築できるようにすることである。DTVは出力プラグも見つけることができるので、DVTに可能な限りのソースデバイスを判断させ、選択スクリーンをユーザに提供させることが可能である。記述子に入っているモデル名は、ソース選択スクリーンに基づいて単純なテキストを作るときに使用される。
【００４３】
しかし、ソース選択スクリーンに基づくテキストは、ハイテクノロジでは非常に低度の機能であると示唆されている。むしろ、種々デバイスのピクチャまたはアイコンもそのスクリーンに表示できるようにすることが望まれている。これを解決する１つの方法は、単純なアイコン（ビットマップ(bitmapped) またはその他）を各デバイスから見つける方法を提供することである。これとは別の、異なる解決方法は、標準に基づく変更を特定の標準に加えることなく、モデル名記述子フィールドの中で使用されるキーワード群を標準化することである。これらのキーワードをモデル名ASCIIストリングの中で使用すると、デバイスのタイプを指定することができる。例えば、DVDプレイヤならば、"DVD"というキーワードが組み込まれることになる。DVCRならば、"DVCR"というキーワードを組み込むことができる。制御側デバイスはASCIIストリングをサーチして、これらのキーワードを探し出し、これらを組み込みアイコン群と相関づけることになる。例えば、DTVは、総称DVDプレイヤまたはDVCRのアイコンをストアしておくことができる。DTVはソース選択スクリーンをユーザに表示するとき、DTVは、DTVが認識するデバイスに指定のアイコンを追加する。DTVは、DTVが認識しないデバイスについては、総称アイコンを使用することができる。
【００４４】
EIA-775Aに関して具体的に説明すると、ディスカバリには２レベルがある。相互運用性に関する最高レベルの情報を見つけるために、制御側デバイスは、バスリセットの直後に、IEEE 1394ネットワーク上のすべてのデバイスに置かれているIEEE 1212環境設定ROMを読み取る。この読み取りによって、制御側デバイスは、他の、どのデバイスがAV/Cおよび/またはEIA-775Aをサポートしているかを知ることになる。最高レベルのIEEE 1212 ROMは、バス情報ブロック (Bus Info Block) とルートディレクトリ (Root Directory) である。そのほかのものは、すべて、このディレクトリとサブディレクトリから外に向かうポインタを使用すると、アクセスすることができる。「ベンダディレクトリ(Vendor directory)」を直接に指すポインタは、ルートディレクトリに入っている。IEEE 1394は、論理的にはマイクロプロセッサバス（つまり、メモリロケーション）に似ているので、ディレクトリは、非同期読み取りコマンド (Asynchronous Read Command) を使用して、バス上を通ってそこからローカルメモリに読み込まれる。ベンダディレクトリは表１に示されている。表に示すように、ベンダディレクトリには、Model_name_textual_descriptor（モデル名テキスト記述子）オフセットがある。このオフセットは、プロダクトの名前を表すベンダ選択項目を収めているテキスト記述子をポイントしている。現在では、EIA-775Aによると、この記述子の唯一の制約は、最小限のASCII文字からなることである。
【００４５】
【表２】
0004851675.tif 000003
【００４６】
これらのモデル名は、制御側デバイスまたはディスプレイデバイスによって収集し、ソース選択スクリーンを構築するために使用できる。残念ながら、EIA-775Aでは、グラフィカルアイコンを標準化することが規定されていないので、信頼性のあるソース選択スクリーンには、ソースを特定するためにこのテキストしか組み込むことができない。しかし、プロダクトのタイプ（例えば、VCR、DVDなど）に関連するキーワードを組み込むことを要求する追加の拘束条件を、テキスト記述子に設けることができる。そのようにすると、ディスプレイデバイスは、メモリに格納されているアイコンをもつキーワードに関連するキーワードをテキスト記述子の中から見つけ、関連アイコンをテキスト記述と一緒にソース選択スクリーンから表示することが可能になる。ユーザは、例えば、アイコンをハイライトにし、SELECTキーを押すと、望みのソースデバイスを選択することができる。ディスプレイデバイスがテキスト記述を認識しない場合は、ディスプレイデバイスは、総称アイコンを生成することになる。ここで注目すべきことは、EIA-775AやEIA-799のような、特定の標準は変更を加えなくても、この特徴を実現できることである。これに代わる方法として、キーワードの使用を望ましい仕方としてリストすることもできる。上記に従ってソース選択スクリーンを生成するときのステップは、図８に示されている。
【００４７】
また、特定の標準は、ソースデバイスがアイコンを総称環境設定ROMに入れておくようにするメカニズムを用意している場合がある。そのようなケースでは、ディスプレイデバイスは、環境設定ROMに入っているアイコンを表示するように構成することができる。しかし、この方法には、ソースデバイスを複雑化し、必要メモリ量を増加するという欠点がある。
【００４８】
デジタルバスを介して種々のA/Vデバイスを相互接続するとき、考慮すべきことは、制御側デバイスによってセットアップされる種々のアイソクロナスチャネルに要求されるバンド幅である。この点に関して、考慮されるのがユーザ/マシン間パラダイム (user-machine paradigm) であり、そこでは、現在のA/Vエンターテインメントクラスタで普及化されているものと類似している、ユーザ/マシン間コントロールパラダイムを使用することが、１つのオプションになっている。例えば、EIA-775Aでは、デスティネーションデバイス、つまり、制御側デバイス（通常は、DTV）を、アイソクロナスコネクションをセットアップするデバイスにすることを推奨している。その理由の１つは、ユーザはソースデバイスからデスティネーションデバイスを選択するのが自然であるからである。現行アナログA/Vクラスタの中で使用されている大部分のA/Vコンポーネントは、このコネクションストラテジを使用している。
【００４９】
このような構成では、アイソクロナスチャネルを一定のビットレートを受け入れるようにセットアップすることも要件になっている。このあらかじめ決めたビットレートが必要になるのは、要求される実際のBWを判断し、その情報をデスティネーションデバイスに伝達する方法が標準化されていないからである。例えば、EIA-775Aは40Mbpsを規定している。この数字は、大部分のシチュエーションをカバーするために選択されたものである。例えば、ATSC地上放送は19.39Mbps信号である。16VSBが使用される場合は、ビットレートは38.8Mbpsである。64QAM（ケーブルで使用）は25.6Mbps前後を消費し、256QAM（これもケーブルで使用）は38.8Mbpsを消費している。ビットレートを40Mbpsにすると、これらのレートのすべてが受け入れられるが、これは、バス幅を余り効率的に使用していない。例えば、S200バスでは、同時40Mbpsチャネルが４つに制限されている。
【００５０】
PTS（Partial Transport Stream−部分トランスポートストリーム）が作成されていて、ソースデバイスが平均ビットレートとピークビットレートを判断できる場合には、ビットレート情報は、アイソクロナスチャネルをセットアップする前にデスティネーションデバイスに伝達することが可能になる。現在では、この情報は、新規のSIT/DIT構造に含まれる部分トランスポートストリーム記述子に入れることが可能になっている。しかし、この情報はストリームに埋め込まれているため、デスティネーションデバイスがこれらの構造を受信できるようにするには、その前にチャネルをセットアップしておくことが要求されている。従って、望ましいことは、チャネルがセットアップされる前にこの情報をデスティネーションデバイスに伝達することである。
【００５１】
本発明によれば、このビットレート情報は、チャネルをセットアップする前にデスティネーションデバイスに伝達されるので、制御側デバイスは、その特定ソースデバイスに要求される必要バンド幅だけを割り振ることにより、より効率的にチャネルをセットアップすることが可能になる。
【００５２】
チャネルをセットアップする前に、ソースデバイスがバンド幅要求量を制御側デバイスに通知するようにすると便利であるように、ソースデバイスが、送信しようとするストリームのタイプをデスティネーションデバイスに通知するようにすると便利である。ケースによっては、ソースデバイスはDSSストリームを送信する場合と、MPEG2-TSを送信する場合とがある。
【００５３】
この特徴を実現する１つの方法は、デスティネーションデバイスがディスカバリプロセス期間にアクセスする利用可能情報ブロックを使用することである。例えば、EIA-775では、図５と図６に記載されているEIA-775 Plug Info（プラグ情報）に変更を加えたあとでも、予約バイトのうちの２バイトは、まだInfo Block（情報ブロック）で利用可能になっている。これらの予約バイトが使用された場合でも、Info BlockとUnit Descriptor（ユニット記述子）に用意されている長さフィールドを使用すると、追加フィールドを追加することが容易になっている。
【００５４】
このケースでは、予約バイトの一方は、デスティネーションデバイスが "digital_transport_stream_output_plug"（デジタルトランスポートストリーム出力プラグ）に接続されたあと、デスティネーションデバイスに送信されるストリームの平均ビットレートを指定することができる。平均ビットレートは、ビデオアプリケーションに適している時間期間、例えば、１秒の1/30に相当しているのが一般である１フレーム期間にわたって判断することができる。他方の予約バイトは、デスティネーションデバイスから送信されるピークビットレートを指定することができる。このようにすると、予約バイトまたは他の追加フィールドに指定されたビットレートを読み取ることにより、デスティネーションデバイスは、アイソクロナスチャネルをセットアップする前に種々ソースデバイスのバンド幅要求量を判断できるので、ソースデバイスの要求量に基づいてバンド幅を効率的に割り振ることができる。平均ビットレートとピークビットレートは、適当なバンド幅を判断するために単独で使用することも、組み合わせて使用することもできる。例えば、適当なバンド幅は、２つのビットレートを加重すると求められる中間ビットレートに基づくことができる。さらに、バッファスペースは、望ましくない効果を低減するためにバンド幅を考慮して受信側で割り振ることができるので、バッファスペースは必要時にダイナミックに割り振ることが可能になる。これを実現する方法は図９に示されている。
【００５５】
デジタルバスによって相互接続された種々デバイスを制御するとき、異種のGUIアプローチを使用すると、種々デバイスを制御することが可能になる。例えば、ビットマップOSDデータアプローチを使用することも、Webベースのアプローチを使用することも可能である。ビットマップOSDアプローチでは、ソースデバイスからビットマップデータが転送され、これは、種々の選択アイコンを含めて、ディスプレイを生成するために制御側デバイスによって使用される。Webベースのアプローチでは、HTMLブラウザが制御側デバイスに置かれており、STBやDVCRなどの、ソースデバイスは、基本的には、制御側デバイスから見たとき、GUIに対してWebサーバの働きをしている。OSD Webページは、制御側デバイスによってソースデバイスに要求される。データを受信すると、制御側デバイスはHTMLページをレンダリングする。そのあと、ユーザは、制御側デバイスのリモートコントロールを使用してWebページをナビゲートすることができる。ユーザが選択を行うと、制御側デバイスは、ハイパリンクに入っているファイルを要求する信号をソースデバイスに送信する。ソースデバイスは、ファイル要求を受信したとき新しいHTMLファイルを送信することも、そのファイル要求に基づいてなんらかのアクションを実行することもできる。例えば、表示されるOSDには、PLAYを表すボタンを設けることができる。ユーザがそのボタンを選択すると、制御側デバイスは、ファイル名の要求をハイパリンクに入れて送信する。VCRなどの、ソースデバイスは、PLAYファイルの要求を、プレイバックを開始するコマンドと同じ扱いをするように構成することができる。他のユーザインタフェースモードは、他の適当な記述言語を利用することができる。そのような記述言語としては、AV/CパネルサブユニットやHAVi DDIコントローラがあるが、これらに限定されない。
【００５６】
ビットマップOSDによるコントロール方法を使用するEIA-775Aと、コントロールパラダイムをミックスすることが困難であるWebベースのコントロールの間には、いくつかの相違点がある。EIA-775Aコントロールは、制御されるデバイスのリモートコントロールユニットを使用している。Webベースのコントロールは、制御側デバイスのリモートコントロールユニットだけを使用できる。EIA-775Aでは、制御されるデバイスは、自身のステートだけを受け持っている。Webベースのコントロールでは、JAVA（登録商標） ScriptがHTMLページに許されるので、制御側デバイスはステートが変化することがある。これらの困難性を解消する１つの方法は、ソース選択スクリーンに現れる各デバイスについてユーザが好みのコントロール方法を選択できるようにすることである。デバイスのいくつかでは、EIA-775Aだけが利用可能になっている。しかし、他のデバイスでは、選択が可能になっている。
【００５７】
本発明によれば、ユーザは、セットアッププロシージャを使用して、選択スクリーンから各デバイスについて好みのUIを選択できるようにしている。このセットアッププロシージャは、ディスプレイに接続された各ソースデバイスについて一連のセットアップスクリーンから選択を行えるようにすることができる。この点に関して、ユーザは、EIA-775Aを使用する同じルームに置かれているデバイスとのやりとりを、これらのデバイスに関連するリモートコントロールを使用して行うことを望む場合がある。他方、ユーザは、Webベースのコントロールを使用する別のルームに置かれたデバイスとやりとりすることを望む場合がある。好みがセットされたあと、ユーザがソース選択スクリーンからデバイスを選択すると、制御側デバイスは、そのデバイスの選択されたコントロールモードに入る。また、本発明によれば、ユーザは、ユーザがそれを望むとき、オーバライドモードに入って、プログラムされたデフォルトをオーバライドできるようにもしている。
【００５８】
別の方法として、制御側デバイスでは、使用されるプロトコルに対する好みを階層化することもできる。例えば、制御側デバイスは、好みのプロトコルがソースデバイスによってサポートされていなければ、HAViから始まり、そこからAV/Cパネルに、次にAV/Cサブユニットに、次にEIA-775に、といったようにフォールバック (fall back) していくことができる。しかし、これらのプロトコルの優先順位を、おそらくはグローバルに変更する選択権をユーザに与えることもできる。さらに、上述したように、ユーザは、セットアッププロシージャを使用して各デバイスの好みのUIを選択できるようにすることができる。
【００５９】
デジタルデバイスを介して結合された複数のデバイスを含むシステムでは、望ましいことは、複数のソースから１つまたは２つ以上のディスプレイデバイスへの複数のストリームをもつクラスタをセットアップすることである。例えば、望ましいことは、異なるソースからの複数のプログラムを単一のDTV上に表示するようにすることである。この能力をもつ共通アプリケーションは、PIP（Picture in Picture−ピクチャインピクチャ）として知られている。アナログ世界では、PIPは、複数の入力をTVに与えることによって（このケースでは、ソースは外部に置かれている）、あるいはTVに複数のチューナを設けることによって（メインとPIP）実現されているのが代表的である。これらの特徴を実現する処理サポートの大部分は、TVの能力と特徴に依存している。これは、DTVの場合も同じである。しかし、信号ソースが外部にあり、IEEE 1394などの、デジタルバスを介してDTVに接続されている場合には、外部ソースからDTVへの複数のストリームが必要になる。IEEE 1394は、複数のストリームのトランスポートをサポートしている。しかし、EIA-775Aは、単一の入力プラグと単一の出力プラグのディスカバリだけを規定している。従って、望ましいことは、追加のプラグを含むようにディスカバリ構造を拡張し、MSDとPIPをサポートするようにすることである。
【００６０】
この点に関して、ディスカバリ可能な出力の数を制限するか、あるいはその出力になんらかの意味を持たせる必要がある。現在では、出力は１つに限られている。そのため、外部デバイスが信号ソースとして選択されたときは、DTVがどの出力に接続されるかは明らかである。しかし、15の出力があるときは、DVTは、どの出力をどれに接続すべきかを判断するための手段を備えている必要がある。さらに、重要なことは、複数のOSDプラグを見つけるための方法が用意されていることである。STBからの出力が2つときは、一方を一次チャネルにし、他方を二次チャネルにすることができる。しかし、論理的には、この２出力をユーザ側から見たとき、各々が独自の構成とコントロールをもつかも知れない、2つの異なる信号ソースのように見えることになる。
【００６１】
上述したように、EIA-775Aには、２レベルのディスカバリが記載されている。相互運用性に関する最高レベルの情報を見つけるために、制御側デバイスは、バスリセット直後に、IEEE 1394ネットワーク上の他のすべてのデバイスのIEEE 122コンフィグレーションROMを読み取っている。この読み取りから、制御側デバイスは、他のどのデバイスがAV/Cおよび/またはEIA-775Aをサポートしているかを知ることになる。他のデバイスがEA-775Aをサポートしていれば、ベンダ名、モデル名、およびモデル番号も、環境設定ROMから知ることができる。もっと詳しい情報を知りたいときは、制御側デバイスは、"Open Descriptor"（記述子オープン）コマンドと"Unit Info"（ユニット情報）コマンドの使用を通して、AV/C Unit Info Blockにアクセスする必要がある。EIA-775Aは、ベンダ固有の機能を使用する2つのEIA固有Info Block（つまり、EIA-775 Plug InfoとEIA-775 DTV Info）を定義している。EIA-775 Plug Info Blockのフォーマットは、以下で説明するように、図５と図６に示されている。
【００６２】
図６は、入力プラグと出力プラグの仕様を示している。また、図６には、トランスポートストリームフォーマットを規定しているフィールドも示されている。これらの２テーブルは、この分野の精通者に公知であるように、追加のプラグIDを追加し、それと同時に、EIA-775Aのカレントバージョンとの後方互換性を保つように、変更することも可能である。例えば、テーブル２に「将来の定義用に予約」と名づけたフィールドは、その目的のために使用することができる。オフセット000116からオフセット000E16までに入っている情報と同じものを、オフセット000F16からオフセット001C16までに置いておくことが可能である。その場合、新しい情報には、すでに含まれている一次入力/出力プラグと区別するために、「二次」という追加の修飾子（例えば、Secondary_digital_transport_stream_output_plug_ID）が付けられることになる。EIA_775_info_blockのバージョンは、この新フォーマットを意味するようにインクリメントすることができる。以上説明した方法は、追加のプラグを見つけることにより、複数のストリームを複数のディスプレイ用に使用できるようにするものである。
【００６３】
本発明に従ってデジタルバスを介して相互接続された種々デバイスを含むシステムでは、ユーザは、制御側デバイスを使用して特定のソースデバイスを選択することができる。デバイスを選択する１つ方法は、制御側デバイスに関連するディスプレイにソース選択スクリーンを生成させることである。このスクリーンは、制御側デバイスが、ディスカバリプロセス期間に各デバイスのディスカバリROM（およびAV/Cユニット記述子）から読み取る情報に基づいて構築することができる。このソース選択スクリーンは、ユーザに表示することができ、ユーザは、制御側デバイスのリモートコントロールキーを使用してスクリーンをナビゲートすることができる。あるソースデバイスが選択されると、制御側デバイスはアイソクロナスチャネルをセットアップする。
【００６４】
この方法の１つの欠点は、ソースを選択するためにいくつかのメニューを通り抜けることがユーザに要求されることである。キーを押す回数とメニューの数を減らす１つの方法は、制御側デバイスが、制御側デバイスのリモートコントロールから直接に「ソース選択スクリーン」ボタンを表示するようにすることである。そのようにすると、ユーザは、ソース選択スクリーンを呼び出すために１つのボタンを押すだけで済むことになる。そのあと、ユーザは、制御側デバイスのリモートコントロールを使用してそのスクリーンをナビゲートすることになる。
【００６５】
もう１つの方法は、ソース選択ボタンを用意し、そのボタンが押されたとき、あり得る限りのソースデバイスのリストを制御側デバイスにスクロールさせるようにすることである。現在の選択は、一定の時間の間だけディスプレイから表示させることができる。ボタンが再び押されると、次の選択が表示される。ユーザがそこで止めると、そのデバイスは、新しいソース選択プロセスが開始されるまで選択されたままになっている。
【００６６】
さらに別の方法は、制御側デバイスのリモートコントロールに個別的デバイスボタンを用意することである。例えば、代表的デバイスとして、DVDプレイヤ、ケーブルSTB、DSS STB、DVCRなどがある。ボタンは、これらのデバイスの各々別にDTVのリモートコントロールに設けることができる。現在のリモートコントロールの多くでは、類似のボタンがすでに設けられており、そこでは、ボタンが押されると、RCコマンドがアドレスされる先のデバイスが変わるようになっている。この種のボタンはこの機能を備えているだけでなく、制御側デバイスにそのソースデバイスを選択させるコマンドを制御側デバイスに送信するようにもしている。図７のステート図が示すように、この機能は制御側デバイス、具体的には、DTVに実装させることが可能である。
【００６７】
以上、本発明の多数の実施形態と関連付けて本発明を詳しく説明してきたが、上述した実施形態は、この分野の精通者ならば当然に理解されるように、上述してきた説明を読み、理解することにより、種々態様に変更することが可能であり、かかる変更は、特許請求の範囲に記載の本発明の範囲に属するものである。
【図面の簡単な説明】
【図１】  従来技術のオーディオ/ビデオシステムの相互運用性を、簡略ブロック図の形で示す図である。
【図２】  デジタルVCRとデジタルテレビジョンの間の従来技術の相互運用性の拡張版を、簡略ブロック図の形で示す図である。
【図３】  IEEE 1394シリアルバスプロトコルを示す簡略ブロック概略図である。
【図４】  本発明を採用したデジタルデバイスの相互運用性を、簡略ブロック概略図の形で示す図である。
【図５】  本発明によるEIA unit info block（ユニット情報ブロック）のエレメントを示すテーブルである。
【図６】  本発明によるEIA-775 plug info block（プラグ情報ブロック）のエレメントを示すテーブルである。
【図７】  本発明によるデバイス制御選択を実現するためのステート図を示す図である。
【図８】  本発明に従ってデバイス選択スクリーン (device selector screen) を生成するときのステップを示す図である。
【図９】  周辺デバイスからの識別データに応じて判断されたバンド幅をもつアイソクロナスチャネルを、本発明に従って確立するときのステップを示す図である。
【図１】
0004851675.tif 000004
【図２】
0004851675.tif 000005
【図３】
0004851675.tif 000006
【図４】
0004851675.tif 000007
【図５】
0004851675.tif 000008
【図６】
0004851675.tif 000009
【図７】
0004851675.tif 000010
【図８】
0004851675.tif 000011
【図９】
0004851675.tif 000012