(57)【要約】【課題】ホームネットワークでデバイスの動的中央制御及び命令を提供する。【解決手段】ネットワークを介した複数のデバイス間での命令及び制御のための方法は、第１デバイスを前記ネットワークに接続するステップと、第２デバイスを前記ネットワークに接続するステップとを含み、前記ネットワークに接続された少なくとも一つの他のデバイスによる前記第２デバイスの命令及び制御のために前記第２デバイスは構造化されたフォーマットでアプリケーションインタフェース記述データを記憶し、前記第２デバイスが前記ネットワークを通じて前記第１デバイスに前記アプリケーションインタフェース記述データを提供するステップと、前記アプリケーションインタフェース記述データを使用して前記第２デバイスの動作を制御するために前記第２デバイスが前記ネットワークを通じて前記第１デバイスから制御及び命令データを受信するステップとをさらに含む。【選択図】図７
2008269655.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介した複数のデバイス間での命令及び制御のための方法であって、
(a) 第１デバイスを前記ネットワークに接続するステップと、
(b) 第２デバイスを前記ネットワークに接続するステップと、を含み、前記ネットワークに接続された少なくとも一つの他のデバイスによる前記第２デバイスの命令及び制御のために、前記第２デバイスは構造化されたフォーマットでアプリケーションインタフェース記述データを記憶し、
(c) 前記第２デバイスが前記ネットワークを通じて前記第１デバイスに前記アプリケーションインタフェース記述データを提供するステップと、
(d) 前記アプリケーションインタフェース記述データを使用して前記第２デバイスの動作を制御するために、前記第２デバイスが前記ネットワークを通じて前記第１デバイスから制御及び命令データを受信するステップと、をさらに含む方法。
【請求項２】
ステップ(c)は、前記ネットワークを介して前記アプリケーションインタフェース記述データを位置指定するステップと、前記ネットワークを介して前記第１デバイスに前記アプリケーションインタフェース記述データを提供するステップと、をさらに含む請求項１に記載の方法。
【請求項３】
(i) ステップ(b)は、２つ以上のデバイスを前記ネットワークに接続するステップを含み、各デバイスは、前記ネットワークに接続された１つまたはそれ以上の他のデバイスによる前記各デバイスの命令及び制御のために、前記構造化されたフォーマットでアプリケーションインタフェース記述データを記憶し、
(ii) ステップ(c)は、前記複数のデバイスが前記ネットワークを介して前記第１デバイスに前記複数のデバイスのアプリケーションインタフェース記述データを提供するステップを含み、
(iii) ステップ(d)は、前記複数のデバイスの各々に対応するアプリケーションインタフェース記述データを使用して前記複数のデバイスの動作を制御するために、前記複数のデバイスが前記ネットワークを通じて前記第１デバイスから制御及び命令データを受信するステップを含む請求項１に記載の方法。
【請求項４】
ステップ(ii)は、前記ネットワークを介して前記アプリケーションインタフェース記述データを位置指定するステップと、前記ネットワークを介して前記第１デバイスに前記アプリケーションインタフェース記述データを提供するステップと、をさらに含む請求項３に記載の方法。
【請求項５】
ステップ(ii)は、少なくとも前記第１デバイスに前記複数のデバイスのアプリケーションインタフェース記述データを提供するステップをさらに含み、ステップ(iii)は、前記複数のデバイスの各々に対応するアプリケーションインタフェース記述データを使用して前記複数のデバイスのうち少なくとも１つの動作を制御するために、前記ネットワークに接続された前記複数のデバイスが少なくとも前記第１デバイスから制御及び命令データを受信するステップを含む請求項３に記載の方法。
【請求項６】
ステップ(c)は、前記第２デバイスが前記ネットワークを介して前記第１デバイスに前記アプリケーションインタフェース記述データの少なくとも一部を送信するステップを含む請求項１に記載の方法。
【請求項７】
ステップ(c)は、前記第１デバイスが前記ネットワークを介して前記第２デバイス内のアプリケーションインタフェース記述データを問合せるステップを含む請求項１に記載の方法。
【請求項８】
ステップ(c)は、前記第１デバイスが前記ネットワークに接続されたデータベースデバイスから前記アプリケーションインタフェース記述データを問合せるステップを含む請求項１に記載の方法。
【請求項９】
前記アプリケーションインタフェース記述データは、前記第１デバイスが前記第２デバイスの動作を制御するための遠隔手続き呼び出し情報を含む請求項１に記載の方法。
【請求項１０】
前記アプリケーションインタフェース記述データは、前記第２デバイスの性能を識別するための性能データを含む請求項１に記載の方法。
【請求項１１】
前記デバイスはユーザインタフェースを表示することができない請求項１に記載の方法。
【請求項１２】
前記構造化されたフォーマットはXMLフォーマットを含む請求項１に記載の方法。
【請求項１３】
ホームネットワークを介してサービスを実行するための方法であって、
(a) クライアントデバイスを前記ホームネットワークに接続するステップを含み、前記クライアントデバイスはユーザインタフェースデータを表示することができ、
(b) 第１ホームデバイスを前記ホームネットワークに接続するステップをさらに含み、前記第１ホームデバイスは、前記ホームネットワークを介したユーザによる少なくとも前記第１ホームデバイスのユーザ命令及び制御のためのユーザインタフェースを定義する選択されたフォーマットでのユーザインタフェースデータを記憶し、
(c) 第２ホームデバイスを前記ホームネットワークに接続するステップをさらに含み、前記第２ホームデバイスは、前記ホームネットワークに接続された１つまたはそれ以上の他のホームデバイスによる前記第２ホームデバイスのデバイス命令及び制御のための構造化されたフォーマットでのアプリケーションインタフェース記述データを記憶し、
(d) 前記第１ホームデバイスが前記ホームネットワークを介して前記クライアントデバイスに前記ユーザインタフェースデータを提供するステップと、
(e) ユーザ入力に基づいて前記第１及び第２ホームデバイスを相互通信させ、前記アプリケーションインタフェース記述データを使用して前記サービスを実行するために、前記第１ホームデバイスが前記クライアントデバイスから制御及び命令データを受信するステップと、をさらに含む方法。
【請求項１４】
前記アプリケーションインタフェース記述データは前記第２ホームデバイスについての性能データを含み、(i) 前記第２ホームデバイスのアプリケーションインタフェース記述データ内の性能データを問合せるステップと、(ii) 前記クライアントデバイスに表示される前記第１ホームデバイスのユーザインタフェースを介してユーザによる前記第２ホームデバイスの命令及び制御を可能とするために、前記性能データを使用して前記第１ホームデバイス内のユーザインタフェースデータを更新するステップと、をさらに含む請求項１３に記載の方法。
【請求項１５】
２つまたはそれ以上のホームデバイスを前記ホームネットワークに接続するステップをさらに含み、各ホームデバイスは、前記ホームネットワークに接続された１つまたはそれ以上の他のホームデバイスによる前記各ホームデバイスの命令及び制御のために、構造化されたフォーマットでアプリケーションインタフェース記述データを記憶する請求項１３に記載の方法。
【請求項１６】
前記２つまたはそれ以上のホームデバイスの各々のアプリケーションインタフェース記述データは各ホームデバイスについての性能データを含み、(i) 前記２つまたはそれ以上のホームデバイスのアプリケーションインタフェース記述データ内の性能データを問合せるステップと、(ii) 前記クライアントデバイスに表示される前記第１ホームデバイスのユーザインタフェースを介してユーザによる前記２つまたはそれ以上のホームデバイスの命令及び制御を可能とするために、前記性能データを使用して前記第１ホームデバイス内のユーザインタフェースデータを更新するステップと、をさらに含む請求項１５に記載の方法。
【請求項１７】
前記第１ホームデバイスが前記ホームネットワークを介して前記２つまたはそれ以上のホームデバイスのうち複数のアプリケーションインタフェース記述データを提供するステップをさらに含む請求項１５に記載の方法。
【請求項１８】
前記複数のホームデバイスの各々に対応するアプリケーションインタフェース記述データを使用して前記複数のホームデバイスの動作を制御するために、前記複数のホームデバイスが前記ホームネットワークを介して前記第１ホームデバイスから制御及び命令データを受信するステップをさらに含む請求項１７に記載の方法。
【請求項１９】
前記ホームネットワークを介して前記アプリケーションインタフェース記述データを位置指定するステップと、前記ホームネットワークを介して前記第１ホームデバイスに前記アプリケーションインタフェース記述データを提供するステップと、をさらに含む請求項１７に記載の方法。
【請求項２０】
前記複数のホームデバイスうち１つのホームデバイスのアプリケーションインタフェース記述データを前記複数のホームデバイスのうち他のホームデバイスに提供するステップをさらに含む請求項１７に記載の方法。
【請求項２１】
前記他のホームデバイスに対応するアプリケーションインタフェース記述データを使用して前記他のホームデバイスの動作を制御するために、前記ホームネットワークを介して前記１つのホームデバイスから前記他のホームデバイスに制御及び命令データを伝送するステップをさらに含む請求項２０に記載の方法。
【請求項２２】
前記アプリケーションインタフェース記述データは、前記第１ホームデバイスが前記第２ホームデバイスの動作を制御するための遠隔手続き呼び出し情報を含む請求項１３に記載の方法。
【請求項２３】
前記アプリケーションインタフェース記述データは前記第２ホームデバイスの性能を識別するための性能データを含む請求項２２に記載の方法。
【請求項２４】
前記選択されたフォーマットはHTMLフォーマットを含む請求項１３に記載の方法。
【請求項２５】
前記構造化されたフォーマットはXMLフォーマットを含む請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークシステムに係り、より詳細にはそれに連結された複数のデバイスを具備したホームネットワークに関する。
【背景技術】
【０００２】
一般的にネットワークは、通信リンクと通信リンクと接続された通信能力を有する多様なデバイスを含む。前記デバイスは、コンピュータ、周辺装置、ルータ、貯蔵装置、そしてプロセッサーと通信インタフェースを具備した製品を含む。ネットワークの一実施形態として多様なデバイスが相互接続された家庭用ホームネットワークを挙げられる。普通の家庭はパソコン及び家庭内で典型的に見つけられるホームデバイスを含むいろいろなデバイスを含むことができる。用語としての”デバイス”は、典型的に論理デバイスまたは機能性及びデータを交換する能力を備える他の装置を含み、全てのホームデバイスだけでなく汎用コンピュータも含むことができる。ホームデバイスは保安システム、映画館装備、TV、VCR、ステレオ装備、デジタル衛星サービス(DSS: Digital Satellite Services)とも知られた衛星放送サービス(DBSS: Direct Broadcast Satellite Services)、散水システム、照明システム、電子レンジ、食器洗い器、オーブン/ストーブ、洗濯機/乾燥器及び自動車内の処理システムのような電子デバイスを含む。
【０００３】
一般的にホームデバイスは家主のライフスタイルと生活水準を向上させるために使われる。例えば、食器洗い器で汚い食器を洗浄することによって、家主が手で直接食器を洗わなくて済む。VCRでは後で家主が特定のプログラムを見るようにTVプログラムを録画できる。保安システムは家主の貴重品を保護し、願わない侵入者による家主の恐怖を縮められる。
【０００４】
家庭用映画館装備のようなホームデバイスは、よく単一の共通制御ユニット、即ち遠隔制御装置を使用して制御される。前記単一の共通制御ユニットは家主が単一のインタフェースを使用していろいろ相異なるホームデバイスを制御し命令できるようにする。従って、製造者は単一インタフェースからそのホームデバイスを制御し命令するための制御ユニットを発展させてきた。ホームデバイスを制御し命令する遠隔制御ユニットの使用に関する短所は各ホームデバイスを制御し命令するための静的な命令ロジックを提供するということである。従って、特定の遠隔制御ユニットは必要な制御及び命令ロジックを含むホームデバイスをただ制御し命令できる。
なお、以下の先行技術文献が知られている。
【特許文献１】特開平０７−０４４２９０号公報
【特許文献２】欧州特許出願公開第８３８７６８号明細書
【特許文献３】国際公開第９７／１８６３６号
【特許文献４】特開平０９−３２５９２５号公報
【非特許文献１】ROHIT KHARE , ADAM RIFKIN, 「XML:A Door to Automated Web Application」IEEE Internet Computing Vol.1, No.4, 07.1997, p78-87
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のネットワークシステムで使用者は遠隔制御ユニットまたはデバイス制御パネルを使用して命令を提供する。一応使用者が中止すれば、ネットワークで自動操作のための命令を提供する制御ユニットとデバイスがなくなる。例えば、ホームネットワークはチューナユニット及びチューナのないVCRを含むことができる。使用者が時間遅延録画のためにVCRにプログラムした後、メカニズムはVCRのために以後に自動でチューナをネットワーク上に配置し、VCRが録画できるようにビデオ情報を提供するようにチューナを制御しなければならない。このように最初に使用者が第１デバイスセットを制御し命令した後、従来のシステムは、第２デバイスセットの直接的な使用者制御及び命令なしに作業を行うために必要なことであって、第１デバイスセットがネットワークで第２デバイスセットと自動で通信するメカニズムを提供しない。
【０００６】
従って、ホームネットワークでデバイスの動的中央制御及び命令を提供する方法とシステムが必要である。また使用者が最初に相互間に通信する第１デバイスセットを制御し命令し、第２デバイスセットに対する直接的な使用者制御及び命令なしに作業を行うために必要なことであって、ネットワークで第１デバイスセットが第２デバイスセットと自動で通信する能力を提供するための方法及びシステムが必要である。また多様なネットワークデバイスがまた他の多様なネットワークデバイスを自動で制御し命令する能力を提供するための方法及びシステムが必要である。
【課題を解決するための手段】
【０００７】
本発明は前記必要性を満たす。一実施形態で本発明は、ネットワークを介した複数のデバイス間での命令及び制御のための方法であって、第１デバイスを前記ネットワークに接続するステップと、第２デバイスを前記ネットワークに接続するステップと、を含み、前記ネットワークに接続された少なくとも一つの他のデバイスによる前記第２デバイスの命令及び制御のために、前記第２デバイスは構造化されたフォーマットでアプリケーションインタフェース記述データを記憶し、前記第２デバイスが前記ネットワークを通じて前記第１デバイスに前記アプリケーションインタフェース記述データを提供するステップと、前記アプリケーションインタフェース記述データを使用して前記第２デバイスの動作を制御するために、前記第２デバイスが前記ネットワークを通じて前記第１デバイスから制御及び命令データを受信するステップと、をさらに含む方法を提供する。
【０００８】
また、一実施形態で本発明は、ホームネットワークを介してサービスを実行するための方法であって、クライアントデバイスを前記ホームネットワークに接続するステップを含み、前記クライアントデバイスはユーザインタフェースデータを表示することができ、第１ホームデバイスを前記ホームネットワークに接続するステップをさらに含み、前記第１ホームデバイスは、前記ホームネットワークを介したユーザによる少なくとも前記第１ホームデバイスのユーザ命令及び制御のためのユーザインタフェースを定義する選択されたフォーマットでのユーザインタフェースデータを記憶し、第２ホームデバイスを前記ホームネットワークに接続するステップをさらに含み、前記第２ホームデバイスは、前記ホームネットワークに接続された１つまたはそれ以上の他のホームデバイスによる前記第２ホームデバイスのデバイス命令及び制御のための構造化されたフォーマットでのアプリケーションインタフェース記述データを記憶し、前記第１ホームデバイスが前記ホームネットワークを介して前記クライアントデバイスに前記ユーザインタフェースデータを提供するステップと、ユーザ入力に基づいて前記第１及び第２ホームデバイスを相互通信させ、前記アプリケーションインタフェース記述データを使用して前記サービスを実行するために、前記第１ホームデバイスが前記クライアントデバイスから制御及び命令データを受信するステップと、をさらに含む方法を提供する。
【０００９】
このような本発明の特徴、観点及び利点は次の詳細な説明、付加した請求項、及び添付した図面によりさらによく理解されるはずである。
【発明を実施するための最良の形態】
【００１０】
一観点で、本発明はホームネットワークのようなネットワークでデバイス間通信を提供する。ホームデバイスがより知能的になって情報を共有できるようになれば、デバイス間通信は使用者が前記デバイスの情報共有性能を用いられるようにネットワーク内のデバイスを相互接続するように許す。同じように、デバイス間通信は使用者にネットワークに連結されたデバイスを充分で柔らかく使用する能力を与えることにおいて決定的な役割をする。
【００１１】
図１を参照すれば、本発明の一実施形態で、ネットワーク１０は通信リンク１６を通じて相互連結された少なくとも一つのクライアントデバイス１２及び少なくとも一つのサーバデバイス１４を含む。通信リンク１６は、多様に連結されたホームデバイス間でデータを伝送し受信するために物理的階層(媒体)を提供する１３９４シリアルバスを含むことができる。前記１３９４シリアルバスは、時間-多重化オーディオ/ビデオ(A/V)ストリーム及び標準IP(Internet Protocol)通信を両方とも支援する。実施形態で、ホームネットワークはホームネットワークのための通信階層としてIPネットワーク階層を使用する。しかし他の通信プロトコルがホームネットワークに通信を提供するために使われる場合もある。
【００１２】
各クライアントデバイス１２は、ネットワーク１０内の一つまたはそれ以上のサーバデバイス１４と通信できる。さらに、各サーバデバイス１４は、ネットワーク１０で一つまたはそれ以上の他のサーバデバイス１４、そして一つまたはそれ以上のクライアントデバイス１２と通信できる。各クライアントデバイス１２は、使用者入力を受信するためのマウスとキーボードのような入力装置を使用者がネットワークに連結されたデバイスと相互作用するように制御使用者インタフェースを提供するディスプレイを含む使用者通信インタフェースを含むことができる。使用者インタフェースは、使用者に情報を提供するためのGUI(Graphical User Interface)ディスプレイ１８を含むことができる。図２を参照すれば、ここに定義されたように、各サーバデバイス１４は使用者に制御使用者インタフェースを除外したサービスを提供し、各クライアントデバイス１２はネットワーク１０と相互作用する使用者のために制御使用者インタフェースを提供する。このようにしてクライアントデバイス１２だけが使用者と直接相互作用し、サーバデバイス１４はクライアントデバイス１２及びサーバデバイス１４とのみ相互作用する。例えば、サービスはMPEGソーシング/シンキング及びディスプレイサービスを含むことができる。
【００１３】
図３は、多数のクライアントデバイス１２及び多数のサーバデバイス１４を含むホームネットワーク１０の例を示すブロック図である。各サーバデバイス１４は、ネットワークで使用者にサービスを提供するための資源としてハードウェアを含むことができる。さらに各サーバデバイス１４はサーバハードウェアを制御するためのサーバまたはサービス制御プログラム２０を貯蔵することができ、図４に示したようにサーバ制御プログラム２０と共に使用者インタフェースのためのグラフィック制御対象(GCO: Graphical Control Object)使用者インタフェース説明書２２を含むことができる。
【００１４】
制御クライアントデバイス１２と制御されたサーバデバイス１４との間の制御のために、クライアントデバイス１２は、例えばネットワークを通じてサーバデバイス１４からクライアントデバイス１２にGCO ２２を伝送することによってサーバデバイス１４のGCO ２２をアクセスする。その後、クライアントデバイス１２は、ネットワークを通じてクライアントデバイス１２からサーバデバイス１４の制御プログラム２０と通信を行う使用者のための制御使用者インタフェースGUI １８を創出するために伝送されたGCO ２２を使用する。使用者は少なくともクライアントデバイス１２からサーバデバイス１４の制御プログラム２０に制御と命令を提供する。
【００１５】
サーバデバイス自体で各サーバデバイス１４のGCO ２２貯蔵は、いくつかのサーバデバイス１４と共にネットワークでクライアントデバイス１２のプロセシングと貯蔵要求を縮められる。さらに、サーバデバイス１４でGCO ２２を貯蔵することは、各サーバデバイス１４が使用者にその自体のGUI形態と感じを提供するように許し、クライアントデバイス１２で修正なしにGCO ２２の修正または更新を許す。
【００１６】
実施形態でクライアントデバイス１２とサーバデバイス１４との間の命令及び制御を提供する図４を参照すれば、前記クライアントデバイス１２は、クライアントデバイス１２に貯蔵されたり希望のサーバデバイス１４からネットワークを通じてクライアントデバイス１２に伝送されたGCO ２２を使用してGUI １８をディスプレイするためのレンダラ(Renderer)２４を含むことができる。例えば、初期のデバイス選択状態で、前記クライアントサーバ１２はネットワークを通じて少なくとも一つのサーバデバイス１４のGCO ２２をフェッチでき、前記レンダラ２４は前記サーバデバイス１４を制御するためにGCO ２２を使用してGUI １８をディスプレイする。望ましくは、前記GUI １８はサーバデバイス１４でカスタム化され、サーバデバイス１４を制御するために作られた内蔵命令セットを含むことができる。
【００１７】
また、多様なサーバデバイス１４のGUI １８は、例えば: (１) GUI １８をディスプレイするクライアントデバイスレンダラ２４のための共通GCOモデルタイプ、(２) 多様なサーバデバイス１４からクライアントデバイス１２にGCO ２２を伝送するための共通通信プロトコル、(３) 制御される特定サーバデバイス１４の対応するサーバデバイス１４の制御プログラムで作られた知識を求めないクライアントデバイス１２から対応するサーバデバイス１４の制御プログラム２０にGUI相互作用のための共通通信プロトコルのような共同体を含むことができる。
【００１８】
再び図４を参照すれば、サーバデバイス１４は、サービスを提供するためにサーバハードウェアを制御する一つまたはそれ以上のサーバ制御プログラム２０を含むことができる。前記サーバデバイス１４のGCO ２２からGUIインタフェース１８はサーバデバイス制御プログラム２０にインタフェースを提供する。前記サーバデバイス１４は、求められたサービスを提供することにおいてサーバデバイス１４及びサーバデバイスハードウェアの制御状態を指摘する制御状態データ２６を含むことができる。
【００１９】
例えば、制御状態データ２６は、VCRサーバデバイスで録画動作を行うために設定されるタイマー設定のように、サーバデバイス１４のためにGUI １８で制御情報の状態を含むことができる。制御状態データ２６は制御されたサーバデバイス１４に貯蔵され、サーバデバイス１４の使用者制御のために制御クライアントデバイス１２でサーバデバイス１４のGUI １８を通じて使用者にディスプレイされる。望ましくは、前記サーバデバイス１４のGUI １８をディスプレイするための制御クライアントデバイス１２は、制御されたサーバデバイス１４のための制御状態データ２６の知識を維持しない。
【００２０】
各サーバデバイス１４は一つまたはそれ以上のクライアントデバイス１２により制御される。従って、前記サーバデバイス１４に貯蔵された制御状態データ２６は、各制御クライアントデバイス１２でサーバデバイス１４のGUI １８内の情報状態を含む。例えば、使用者が第１クライアントデバイス１２を使用してサーバデバイス１４を制御する時、使用者制御が完成されれば、第１クライアントデバイス１２でサーバデバイス１４のGUI １８内の情報はサーバデバイス１４によりサーバデバイス１４の制御状態データ２６に貯蔵される。
【００２１】
一方では、使用者が第１クライアントデバイス１２でサーバデバイス１４のGUI １８と相互作用する間、前記サーバデバイス１４の制御状態データ２６は第１クライアントデバイス１２でサーバデバイス１４のGUI １８内の情報に更新され、使用者制御が完成されれば、前記制御状態データ２６はサーバデバイス１４で維持される。使用者が第２クライアントデバイス１２を使用してサーバデバイス１４を制御する時、前記制御状態データ２６は後続する制御のために第２クライアントデバイス１２でサーバデバイス１４のGUI １８を通じて使用者が用いられるように作られる。使用者はまた以後にサーバデバイス１４を制御するために第１クライアントデバイス１２を使用でき、ここで前記制御状態データ２６は後続する制御のために第１クライアントデバイス１２でサーバデバイス１４のGUI １８を通じて使用者が用いられるように作られる。前記サーバデバイス１４はまたクロック２８を含んだり、後述されるように使用者から入力された時間またはクロックに基づいた時間遅延作用を許すために現在時間を維持できる。
【００２２】
クライアントデバイス１２とサーバデバイス１４は、例えばDTVのように一つのユニットで物理的に一緒に縛られることができる。その場合に、前記サーバデバイス１４はサーバハードウェアを制御するための制御プログラム２０を含み、前記クライアントデバイス１２は少なくともサーバハードウェアの制御及び命令のためにサーバ制御プログラム２０に制御使用者インタフェースを提供する。図５はクライアントデバイス１２の例を示す図面であって、(１) GUIディスプレイのためのPDA(RemoteC)、(２) GUIをディスプレイし、オーディオ及び/またはビデオプログラムストリーム目的地サーバで構成された受信側サーバを含むDTV(STB)、(３) GUIをディスプレイし、多重のサービスを提供するために少なくとも一つのサーバデバイスを含むPCを含むことができる。DTVまたはPCクライアントデバイス内のハードウェアあるいは実行できるものは他のクライアントデバイスによっても制御される。図６はサーバデバイス１４の例を示す図面であって、(１) 送信側のサーバデバイスとしてのDVDP SmartCard、(２) 受信側のサーバデバイスとしてのオーディオ増幅器、(３) 送信側または受信側のサーバデバイスとしてのDVCR、(４) 遠隔サーバデバイスを管理するための管理サーバを含む。前記管理サーバは例えばDSB-STB、ケーブルTV-STB、またはATSC-STBを含むことができる。このようなデバイスはSTB内部作業のローカル制御または管理のための管理サーバを含む。さらに、外部ネットワークを通じてアクセスされた外部サーバは、例えばVideo-on-Demand、Enhanced-TV及びインターネット商取引のようなサービスのためにローカルクライアントデバイスにより使われる場合がある。
【００２３】
図７を参照すれば、二つのサーバデバイス１４間の通信及び制御は、それら間の命令語及び制御データを通信するサーバデバイス１４の制御プログラム２０により行われる。サーバデバイス１４はネットワークを通じて一つまたはそれ以上の他のサーバデバイス１４を制御できる。そして、サーバデバイス１４は一つまたはそれ以上のサーバデバイス１４、そして一つまたはそれ以上のクライアントデバイス１２により制御されられる。さらに、使用者はサーバデバイス１４の第１セットを制御及び命令するためにクライアントデバイス１２を使用でき、前記サーバデバイス１４の第１セットは、使用者にサービスを行うために必須的なものであって、使用者を惑わせずにサーバデバイス１４の第２セットを自動で命令し制御できる。
【００２４】
例えば、自動時間-遅延動作を行うために、使用者はサーバデバイス１４の第１セットを制御するクライアントデバイス１２に“ログオン”し、希望のサービスを指定できる。それから使用者は前記クライアントデバイス１２から“ログオフ”する。サーバデバイス１４の第１セットはそれら自体間で通信及び制御を行い、その後に第１セットで一つまたはそれ以上のサーバデバイスが使用者の介入なしに希望のサービスを総括的に提供するために必須的なものであって、サーバデバイス１４の第２セットを自動で制御する。
【００２５】
図７は、二つのサーバデバイス１４が相互通信し制御する実施形態を示す図面である。各サーバデバイス１４は前述された制御プログラム２０、クロック２８及び前述した制御状態データ２６を含む。各サーバデバイス１４はまたサーバデバイス１４がクライアントデバイス１２により直接制御されるようにするGCO ２２を含むことができる。しかし、GCO ２２はクライアントデバイス１２により直接制御されなく、ただ他のサーバデバイス１４と通信するサーバデバイス１４には含まれる必要がない。各サーバデバイス１４はまた命令語(CL: Command Language)インタフェース３０及び命令語ライブラリーを含む。前記命令語ライブラリーは、前記サーバデバイス１４がそのサービスを提供するために情報を送信及び受信するのに使用する命令を含む。しかし、図４及び前述されたように命令語は使用者制御のために必ず必要なものではない。
【００２６】
図８は、ネットワークで送信側のサーバデバイス１４、受信側のサーバデバイス１４、そしてクライアントデバイス１２を含むオーディオ/ビデオ(A/V)モデルの例を示す。前記送信側のサーバデバイス１４は送信側のサーバデバイス１４のデータストリーム送信側ハードウェア３２を制御するための制御プログラム２０を含み、前記受信側のサーバデバイス１４は受信側のサーバデバイス１４のデータストリーム受信側ハードウェア３４を制御するための制御プログラム２０を含む。例示的な動作で、使用者はデータストリーム送信側ハードウェア３２を稼動させるために送信側のサーバデバイス１４を制御し、データストリーム受信側ハードウェア３４を稼動させるために受信側のサーバデバイス１４を制御するクライアントデバイス１２を使用する。データストリーム送信側ハードウェア３２からデータストリーム受信側ハードウェア３４へのデータ伝送を初期化することにおいて、使用者はこれ以上前記クライアントデバイス１２を操作する必要がない。他の一方では、使用者は将来の初期データ伝送をプログラムでき、これ以上クライアントデバイス１２を操作する必要がない。以後で送信側のサーバデバイス１４のデータストリーム送信側ハードウェア３２と受信側のサーバデバイス１４のデータストリーム受信側ハードウェア３４は使用者によりプログラムされた時間に自動でデータ伝送を初期化する。
【００２７】
例えば、前記データストリーム送信側ハードウェア３２は、衛星放送(DBS: Direct Broadcast Satellite)のようなチューナ-アクセスデバイスを含むことができる。DBSはケーブルテレビに代える多重-チャンネルであって、衛星から直接的に小さな衛星アンテナ(直径３フィート１８インチ)にケーブルのようなテレビプログラミングを提供する。DBSと共に、いくつかの標準アナログテレビ信号は単一衛星トランスポンダでデジタル的に圧縮され、空中の指定された場所に位置した衛星アンテナも２００つ以上のチャンネルが受信するように許す。前記データストリーム受信側ハードウェア３４は、再生時に圧縮されたデジタルビデオ信号をデコーディングできる命令及びデジタルビデオカセットレコーダ(DVCR)を含むことができる。使用者はDVCRのための”時間-遅延録画”イベントデータとチューナ-アクセスデバイスのための”時間-遅延選択プログラム”イベントデータを含む命令及び制御データを提供する。時間遅延後に前記チューナ-アクセスデバイスは希望のプログラムを選択し、使用者から追加的な制御操作なしでもプログラムデータを受信及び録画するDVCRにソースプログラムデータを提供する。
【００２８】
図９は、少なくともネットワークで送信側のサーバデバイス１４ SERVER１、受信側のサーバデバイス１４ SERVER２とクライアントデバイス１２を含むさらに他のA/Vモデルを示す図面である。前記クライアントデバイス１２は、サーバデバイス１４ SERVER１及びSERVER２と他のサーバデバイス１４、例えばSERVER３及びSERVER４(図示せず)を選択し制御するために、使用者のための選択情報をディスプレイする使用者インタフェースのあるセッションマネージャ３６を含む。選択情報はサーバデバイス１４ SERVER１、SERVER２、SERVER３及びSERVER４を各々選択する使用者のためにセッションマネージャ３６でServ１、Serv２、Serv３及びServ４に割当てられたアイコンシンボルを含む。前記送信側のサーバデバイス１４ SERVER１はDVCRを含むことができ、前記受信側のサーバデバイス１４ SERVER２は１/２DTVを含むことができる。
【００２９】
動作の一例として、サーバデバイス１４ SERVER１とSERVER２の選択において、前記クライアントデバイス１２は各サーバデバイス１４のGCO ２２をクライアントデバイスに伝送し各サーバデバイス１４ SERVER１及びSERVER２に対応するGUI １８をディスプレイする。使用者は、サービスのために対応するサーバデバイス１４に制御と命令を提供する各サーバデバイス１４のGUI １８と相互作用できる。各サーバデバイス１４は単独または他のサーバデバイス１４と組合してサービスを提供できる。さらに、前記セッションマネージャ３６は、サービスを行うために対応するサーバデバイス１４が必要とするものであって、前記クライアントデバイス１２で前記サーバデバイス１４のGUI １８間に制御状態データ２６を伝送する。使用者制御と命令情報に基づいて、二つ以上のサーバデバイス１４は使用者が求めるサービスを提供するためにそれら間で命令及び制御情報を通信できる。
【００３０】
前記セッションマネージャ３６は、ネットワーク１０で多様なサーバデバイス１４により提供される有用なホームネットワークサービスをアクセスしディスプレイする機能を有するソフトウェアエイジェントを含むことができる。前記ソフトウェアエイジェントは付加的にネットワーク１０で多様なサーバデバイス１４の性能を整合させ、互換性能を有する前記サーバデバイス１４だけのための選択情報をディスプレイする。さらに、セッションマネージャ３６は、使用者がサーバデバイス１４に意味のある命令及び制御情報を提供するように一つのサーバデバイス１４のGUI １８で作られた選択と、他のサーバデバイス１８のGUI １８で作られた選択を整合させられる。
【００３１】
動作のさらに他の例で、セッションマネージャ３６はネットワークを検索し、ネットワークに接続されたサーバデバイス１４を見つけるソフトウェアエイジェントを実行する。前記ソフトウェアエイジェントは、またサーバデバイス１４の性能を決定するために各サーバデバイス１４に貯蔵された性能データをアクセスし、使用者にその性能に対する情報を提供する。それから前記セッションマネージャ３６は、図９に示したようにサーバデバイスSERVER１、SERVER２、SERVER３及びSERVER４のための選択アイコンServ１、Serv２、Serv３及びServ４をディスプレイする。
【００３２】
前記セッションマネージャ３６は、使用者が４個の全てのアイコン中で選択できるように初期に全ての選択アイコンServ１、Serv２、Serv３及びServ４をイネーブルさせる。使用者がServ１選択アイコン上でクリックしてサーバデバイスSERVER１を選択した後に、前記セッションマネージャ３６はサーバデバイスSERVER３及びSERVER４がサーバデバイスSERVER１と性能上互換できないと決定する。従って、前記セッションマネージャ３６はサーバデバイスSERVER３及びSERVER４のために選択アイコンServ３及びServ４を各々ディスエーブルさせる。それから使用者はサーバデバイスSERVER２を命令及び制御するためにアイコンServ２上でクリックできる。
【００３３】
使用者が選択されたサーバデバイス１４のGUI １８と相互作用することのように、使用者により各GUI １８に入力された制御及び命令情報は使用者により後続するサーバデバイス選択に影響を及ぼす付加的な性能情報を提供する。例えば、もしVCRサーバデバイス１４が選択されれば、他のサーバデバイス１４のための選択アイコンをイネーブルまたはディスエーブルさせることにおいて、セッションマネージャ３６による後続の操作が再生または録画する使用者の決定により影響される。
【００３４】
ネットワークで各サーバデバイス１４は、図９に示したサーバデバイスに関した例を通じて前述されたように一つまたはそれ以上のサービス性能を有する。各サービス性能は情報のソーシングまたはシンキングを含む。例えば、TVはビデオ及びオーディオストリームを受信するシンキング性能を有し、VCRはビデオ及びオーディオ信号をソース(伝送)及びシンク(受信)でき、PCはビデオ、オーディオそしてデータを伝送及び受信できる。各ソーシング性能は相補的で互換的なシンキング性能を有する。これと類似に、各シンキング性能は相補的で互換的なソーシング性能を有する。例えば一つのデバイスでビデオ出力性能はさらに他のデバイスのビデオ入力性能により補完される。
【００３５】
各サーバデバイス１４はネットワーク上でいろいろな他のサービスのために送信または受信するので、図１０に示したように各サーバデバイス１４は性能データテーブル(性能テーブル１)を貯蔵する。テーブル１の第１列はサーバデバイス１４のサービス性能を確認し、第２列は第１列に対応するサービスのために前記サーバデバイス１４が送信側か受信側かを確認する。新たなサービスはさらに古いデバイスと互換性を維持する間に性能データテーブル１を使用して実行される。例えば、もしさらに古いサービスと互換される新たなサービスが開発されるならば、新たなサービス及び古いサービス両方とも実行デバイスは古いサービスを使用する古いデバイスと互換性を維持するにつれて、前記新たなサービスを行うデバイスのための性能データテーブル１に書込まれることができる。
【００３６】
第１実施形態で、デバイスマネージャは送信側及び受信側のサービスデバイスのマッチングまたは比較を行う。例えば、前記デバイスマネージャは互換性マッチングと共に多様なサーバデバイス１４及び指定されたサーバデバイス１４の性能及び特性を比較するソフトウェアエイジェントの役割も行える。例えば、サービスがネットワークにわたって第１サーバデバイス１４から第２サーバデバイス１４までのメディアストリームの場合、前記デバイスマネージャは使用者が第１サーバデバイス１４の性能と互換される第２サーバデバイス１４を分別力あるように選択できるように第１及び第２サーバデバイス１４の性能を比較する。次はサーバデバイス１４の実施形態のためのサービス性能リストの例を示す。
Stream_format_video_dv
Stream_format_video_mpeg2tpt
Stream_format_video_dsstpt
Stream_format_video_mpeg2pes
Stream_format_video_mpeg210901-tpt
【００３７】
図１１に示したように、各サーバデバイス１４はデバイスに関した特性を含む特性データテーブル(特性テーブル２)をさらに貯蔵する。名称と値はテーブル２で各特性を定義する。文字長さがテーブル２に示されているが、必要ではない。前記特性データはネットワーク１０上で情報処理相互運用を容易にしデバイス情報を貯蔵する他のサーバデバイス１４に有用である。例えば、後述されるようにデバイスページはデバイス名称を貯蔵する特性テーブル２を使用する。他のフィールドは必要な時特性データテーブル２に追加されることができる。
【００３８】
前述された使用者-クライアントデバイス制御モデルで、特性データはクライアントデバイス１２でサーバデバイス１４のGUIページ上にディスプレイされる。他には、前記特性データをディスプレイするために第２レベルデバイス情報ホームページが使われる場合がある。さらに、テキストまたはXML(Extensible Markup Language)ファイルの形態の特性データがソフトウェアエイジェントによりアクセスされる場合がある。デバイス-デバイス制御モデルのために、制御されたデバイスのための特性データはデバイスインタフェース及びアプリケーションインタフェースに貯蔵される。
【００３９】
特性テーブル２で前記デバイス位置特性フィールドは各サーバデバイス１４のための位置またはグループを貯蔵するために使われる。デバイスタイプ特性フィールドはVCR、DVD、DTV、カムコーダ、PC、保安システムのような特定のサーバデバイス１４のためのデバイスタイプを書込む。前記デバイスタイプ特性フィールドは、もしデバイス自体がデバイスアイコンを供給しないならば、デバイスページでデバイスを表現するデフォルトデバイスアイコンを選択するために使われる。特性テーブル２はデフォルトの送信側及びデフォルトの受信側の特性フィールドのための多重の書込みを含むことができる。そのようなそれぞれの書込みは、サーバデバイス１４により処理される各データタイプのための他のデフォルトの送信側または受信側のサーバデバイス１４を表現する。
【００４０】
望ましくは、性能及び特性データは階層言語を使用して構造化されたデータでパッケージされる。これはGCO伝送及びサーバデバイス-サーバデバイス制御のような他の目的で使われた性能と特性を回復させる共通方法を提供する。例えば、特性データは次の構造化されたデータフォーマットを含むことができる。
＜DEVICEATTRIBUTES＞
＜ATTRIBUTE name＝DeviceManufacturer value＝"Samsung Inc."＞
＜ATTRIBUTE name＝ManufacturerURL value＝www.Samsung.com＞
＜ATTRIBUTE name＝ManufacturerIcon value＝"logo.gif"＞
＜ATTRIBUTE name＝DeviceName value＝"Samsung DSS"＞
＜ATTRIBUTE name＝DeviceModel value＝"SCH1900"＞
＜ATTRIBUTE name＝DeviceType value＝DDS＞
＜ATTRIBUTE name＝DeviceLocation value＝"Livingroom"＞
＜ATTRIBUTE name＝DeviceIcon value＝"device.gif"＞
＜ATTRIBUTE name＝DeviceAddress value＝105.144.30.17＞
＜/DEVICEATTRIBUTES＞
【００４１】
一例として、性能データは次の構造化されたフォーマットを含むことができる。
＜DEVICECAPABILITIES＞
＜CAPABILITY type＝MPEG2 value＝Source＞
＜CAPABILITY type＝MPEG2 value＝Sink＞
＜CAPABILITY type＝MPEG3 value＝Source＞
＜CAPABILITY type＝MPEG3 value＝Sink＞
＜/DEVICECAPABILITIES＞
【００４２】
アプリケーションインタフェース言語は、他のサーバデバイス１３がサーバデバイス-サーバデバイスを含んでデバイス-デバイス制御を行うように使われる。前記アプリケーションインタフェース言語は命令語を含み、後述されたようにXMLを使用して記述されることができる。一つのサーバデバイス１４の制御プログラム２０は、GUI １８を使用しないとかまたは使用者の介入なしにネットワークを通じてさらに他のサーバデバイス１４の制御プログラム２０を遠隔で制御する。デバイス-デバイスの制御の例は自動操作である。使用者は初期に希望のサービスのためにクライアントデバイス１２を通した制御を提供し、次いで二つ以上のサーバデバイス１４がサービスを提供するために使用者の相互作用なしでもお互い自動で通信し制御する。
【００４３】
図１４を説明すれば、クライアントデバイス１２とサーバデバイス１４との間の三つの相互作用の三つの実施形態を示す。第１実施形態“A”で、使用者は遠隔サービスアプリケーション"S"と通信する。前記使用者は使用者インタフェースとしてクライアントデバイスでブラウザーを使用するが、ここで前記ブラウザーはサービスアプリケーション"S"でサービスプログラム２０を制御しHTML(Hyper Text Markup Language)またはXMLフォーマットで応答を受信する.XML基盤の非同期命令メッセージポスティングを受け入れるブラウザーを備えた第二サーバが含まれる。例えば、DVCRにおいて第二サーバ１４は“VCR FAILED:TAPE BROKE”のような命令メッセージを受け入れる。ブラウザーを含むソフトウェアエイジェントは使用者による後続アテンションとDVCRの制御のためにブラウザーのGUI内で使用者のための命令メッセージがディスプレイするために用いられる。望ましくは、XML基盤のクライアントデバイス１２は、サーバデバイス対サーバデバイス制御と命令のために他所で初期化された命令に応答するHTTP１.１サーバ性能を含む。
【００４４】
第２実施形態”B”で、使用者はソフトウェアクライアント制御プログラム５０により置き換えられる。前記ソフトウェアクライアント制御プログラム５０はXML基盤のサービスアプリケーション”S”への命令ポスティングを生成し、返信されるXML命令ポスティングを受信する。そして、第３実施形態”C”で、前記ソフトウェアクライアント制御プログラム５０は、命令と応答が二つのサービスアプリケーション２０間で交換されるサーバデバイス制御プログラム２０のようなアプリケーションにより置き換えられる。この点において、実施形態”B”はナル(Null)サービスを有する実施形態”C”の特別な場合である。
【００４５】
XMLに基づいたアプリケーションインタフェース言語は、ワールドワイドウェブあるいはインターネットによりイネーブルされるデバイスまたはサービスのために第１サーバデバイス１４と第２サーバデバイス１４(デバイス-対-デバイスまたはサービス-対-サービス)間を制御するために使われる。アプリケーションインタフェース言語はウェブ標準、ミドルウェア階層に基づく。一実施形態で、デバイス-デバイス制御はネットワーク１０でさらに他のサーバデバイス１４から一つのサーバデバイス１４で制御プログラム２０またはアプリケーションを遠隔で制御することを含む。従って、アプリケーション２０に対するインタフェース(API)はAPI拡張を使用するネットワークを通じて利用できる。望ましくは、前記API拡張は全体の情報処理相互運用を提供するためにXMLに基づいたインタフェースのような標準フォーマットを使用する。
【００４６】
なお、図１５は、ネットワーク内で通信するサービスAとしてデザインされた第１アプリケーションAとBとしてデザインされた第２アプリケーションBのためのAPI拡張を示すブロック図である。例えばサービスAはネットワークで第１サーバデバイスAのための制御プログラムであり、サービスBはネットワークで第２サーバデバイスBのための制御プログラムでありうる。サーバデバイスBはサーバデバイスAに命令を伝送する。例えば、第１及び第２サービスデバイスA及びBはCEデバイスを含む。
【００４７】
サービスAのためのAPI拡張を参照すれば、第１最上位ブロック５２は、CEデバイスを説明する英語単語を使用してCE対象及び方法の総合的な定義またはデータベースを提供する。前記総合的な定義またはデータベースはC、XMLまたは対象及びそれら各自の方法を表現できる他のフォーマットでも存在できる.XMLを使用する総合的な定義またはデータベースはXCE定義と呼ばれる。第２ブロック５４は、インタフェースデータタイプ定義INTERFACE.DTDでデザインされた全てのサーバデバイス１４のためにXML形式でAPIを表現するフォーマットを提供する。
【００４８】
手段AでデザインされたソフトウェアエイジェントはサービスAのためのXCE定義のサブセットを使用し、XML形態文書を生成するサービスAのためのインタフェースデータタイプINTERFACE.DTD、INTERFACE-A.XMLを使用する。前記文書INTERFACE-A.XMLはサービスAのための文書タイプ定義INTERFACE.DTDに従ってサービスAにより支援される対象及び方法を説明する。他のデータタイプ定義はまたINTERFACE-A.XML文書を作成するために使われる。
【００４９】
ソフトウェア手段Aはまたネットワークインタフェース上で、サービスBから例えばCでプログラムされたサービスAまでXMLメッセージから変換されたルック-アップテーブル５６及び実行できる２進数にコンパイルされたルック-アップテーブル５６を生成する。望ましくは、ルック-アップテーブル５６はコンパイル時に作成され、ここでラン-タイムの間、サービスBから入力されるXML形態の方法(Method)メッセージ(命令)がサービスAのためにコンパイルされたアプリケーションCコードにより作成されたAPI形式に変換される。前記ルック-アップテーブル５６はXML対象方法要請サービスとしてAのための装置固有の要請に変換するラン-タイム翻訳を提供する。ルック-アップテーブル５６はサービスAのためにサーバデバイスA上で局部的な実行のためのデバイス制御プログラム２０と共にコンパイルされる。
【００５０】
INTERFACE-A.XMLは受信されたメッセージでエラーが発生した時正当性チェックのためにサービスAにより使われたりする。INTERFACE-A.XMLはまたサービスAと通信する前にサービスAのためのメッセージフォーマットを決定するサービスBのような外部アプリケーションにより使われたりする。さらに、もしサービスBからサービスAへのメッセージがエラーを発生させれば、サービスBはエラーを診断するためにINTERFACE-A.XML文書をアクセスできる。
【００５１】
サービスBに対するAPI拡張を参照すれば、前記第１ブロック５８は前記のサービスAのためにXCE定義のようなCE対象の総合的な定義またはデータベースを提供する。次のブロック６０はサービスAのためのAPIのような遠隔のAPIサービスまたはデバイスにXML形態方法(命令)呼び出しのための言語定義を提供する。前記言語定義はネットワーク上で対象との相互作用を説明する文書タイプ定義方法要請CALL.DTDである。
【００５２】
手段Bでデザインされたソフトウェアエイジェントは、命令をサービスBのためにコンパイルされたCプログラムコードをXML形式の方法要請に変換するルックアップテーブルを作成するために、少なくともサービスBのためのXCE規定内の対象及び方法のサブセットを用いる。従って、例えばルック-アップテーブル６２はサービスB(例えば、“再生”)により引き起こされた方法とサービスAでネットワークインタフェースを横切って方法呼び出しを行うXML文書またはメッセージ間で変換を提供する。ソフトウェア手段Bにより用いられるXCE定義のサブセットはネットワークの使用拡張及び本質に依存する。例えば、前記サブセットは、ホームネットワーク上で全ての可能なサービスの包括的あるいは制限された使用を提供するために選択されることができる。
【００５３】
従って、前記API拡張はXMLを使用するネットワーク上で多様なデバイス間で通信を提供する。前記の例で、サービスBのためのプログラムコード２０はAPIで方法呼び出しを生成し、API呼び出しは内部-デバイス通信のためのウェブ/インターネット標準XMLに適合にXML形態に変換される.XML方法呼び出し(メッセージ)はネットワークを通じてサービスAに伝送され、サービスAはネットワークインタフェースからのXML方法呼び出しをサービスAのためのプログラムコードAPI定義に再変換する。前記変換及び再変換は、他のデバイス間で２進互換性を異に要求するプログラムコードAPIを有するネットワーク内の多様なデバイスのためのウェブ/インターネット互換性を提供する。図１５でのブロック図を使用するXMLインタフェースブロックの実施形態が下に示される。
----------------------------------------------------------------------
interface.dtd
rules for describing an object interface in xml
----------------------------------------------------------------------
＜!ELEMENT parameter #PCDATA＞
＜!ATTLIST parameter valueCDATA #REQUIRED＞
＜!ELEMENT method        (#PCDATA,(parameter)＋)＞
＜!ELEMENT object        (#PCDATA)
＜!ELEMENT call      (object,(method)＋)＞
----------------------------------------------------------------------
interface.h
example object interface in c
----------------------------------------------------------------------
/* object */
typedef struct stream{
int id;
};
/* method */
void StreamPlay(int id,intspeed);
void StreamStop(int id);
----------------------------------------------------------------------
interface.xml
the same object in xml using ruels of interface.dtd
----------------------------------------------------------------------
＜object＞Stream
＜method＞Play
＜parameter type＝"int"＞id＜/parameter＞
＜parametert ype＝"int"＞speed＜/parameter＞
＜/method＞
＜method＞Stop
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜object＞
----------------------------------------------------------------------
call.dtd
rules for describing a c function call in xml
----------------------------------------------------------------------
＜!ELEMENT parameter #PCDATA＞
＜!ATTLIST parameter TypeCDATA #REQUIRED＞
＜!ELEMENT method        (#PCDATA,(parameter)＋)＞
＜!ELEMENT method        (#PCDATA,(method)＋)＞
----------------------------------------------------------------------
controller.c
example controller command in c
----------------------------------------------------------------------
.
.
.
StreamPlay(0x1ae,500);
.
.
.
----------------------------------------------------------------------
call.xml
the same command in xml using call.dtd
----------------------------------------------------------------------
＜!example to play a stream--＞
＜call＞
＜object＞stream＜/object＞
＜method＞Play＜/method＞
＜parameter value＝"500"＞speed＜/parameter＞
＜/call＞
【００５４】
さらに、上記では、前述された利用可能なサービスの説明文書のINTERFACE.XMLの説明文書を作成するように使われたインタフェース定義INTERFACE.DTD及びCALL.DTDの例を示す。前記CALL.DTD定義は、XMLRPC(Remote Procedure Call)またはXMLRPCメッセージのような方法呼び出しまたは関数呼び出しメッセージを生成するための規定セットを含む。前記CALL.DTD定義は制御器サービス１４の出力インタフェースを説明する。ホームネットワークで、例えばINTERFACE.XMLはホームネットワーク上に利用可能なサービスを表現する。利用可能なサービスはCE領域で全体サービスのサブセットである。
【００５５】
OTR(One-Touch-Record)概要で、使用者は衛星STBのようなチューナ-アクセス-デバイスの制御を行う。使用者はプログラムリストを示すグラフィック的な使用者インタフェース表現のようなEPG(Electronic Program Guide)を使用してチューニングを制御する。OTR録画は、使用者が時間遅延された録画のためにVCRをプログラムするためにVCRグラフィック使用者インタフェースをアクセスせずに録画できるようにEPGから将来のプログラムの選択を含むサービスを提供する。OTRはVCRの制御を自動化する。下記はOPR.XMLの例示的な動作制御リストである：(１) StreamOpen＝衛星STBからネットワークに出力された選択されたプログラムストリームを再生;OTRのためにこの制御はSTBデバイスに局部的である;(２) StorageOpen＝貯蔵サービスオープン;及び(３) StorageRecord＝ネットワークを通じてVCRに録画命令伝送。
----------------------------------------------------------------------
call.dtd
rules for describing a c function call in xml
----------------------------------------------------------------------
＜!ELEMENT parameter #PCDATA＞
＜!ATTLIST parameter valueCDATA #REQUIRED＞
＜!ELEMENT method           (#PCDATA,(parameter)＋)＞
＜!ELEMENT object           (#PCDATA)＞
＜!ELEMENT call                  (object,method)＞
----------------------------------------------------------------------
interface.dtd
example for describing an object interface in xml
----------------------------------------------------------------------
＜!ELEMENT parameter #PCDATA＞
＜!ATTLIST parameter valueCDATA #REQUIRED＞
＜!ELEMENT method          (#PCDATA,(parameter)＋)＞
＜!ELEMENT object          (#PCDATA,method＋)＞
----------------------------------------------------------------------
interface.xml
this document describes various CE services offered-a subset of the whole CE space.
----------------------------------------------------------------------
＜?xml version＝"1.0"?＞
＜!DOCTYPE interface SYSTEM "interface.dtd"＞
＜object＞Stream
＜method＞Open
＜parameter type＝"int"＞id＜/parameter＞
＜parameter type＝"int"＞channel＜/parameter＞
＜/method＞
＜method＞Close
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜/object＞
＜object＞Control
＜method＞Set
＜parameter type＝"int"＞id＜/parameter＞
＜parameter type＝"int"＞level＜/parameter＞
＜/method＞
＜/object＞
＜object＞Storage
＜method＞Open
＜parameter type＝"int"＞id＜/parameter＞
＜parameter type＝"int"＞channel＜/parameter＞
＜/method＞
＜method＞Record
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜method＞Play
＜parameter type＝"int"＞id＜/parameter＞
＜parameter type＝"int"＞speed＜/parameter＞
＜/method＞
＜method＞Stop
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜method＞Close
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜/object＞
＜object＞Display
＜method＞Open
＜parameter type＝"int"＞id＜/parameter＞
＜parameter type＝"int"＞channel＜/parameter＞
＜/method＞
＜method＞Render
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜method＞Blank
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜method＞Control
＜parameter type＝"int"＞id＜/parameter＞
＜parameter type＝"int"＞cid＜/parameter＞
＜parameter type＝"int"＞level＜/parameter＞
＜/method＞
＜method＞Close
＜parameter type＝"int"＞id＜/parameter＞
＜/method＞
＜/object＞
＜!-------------------------------------------------------------------
otr.xml
an xml representation of one touch record
c representation:
StreamOpen(100,2);/*play a stream(pushed by satellite feed*/
StorageOpen(24,2);/*open a storage service*/
StorageRecord(24);/*record the stream*/
----------------------------------------------------------------------
＜?xml version＝"1.0"?＞
＜!DOCTYPE interface SYSTEM"call.dtd"＞
＜call＞
＜object＞stream＜/object＞
＜method＞open＜/method＞
＜parameter value＝"100"＞id＜/parameter＞
＜parameter value＝"2"＞channel＜/parameter＞
＜/call＞
＜call＞
＜object＞storage＜/object＞
＜method＞open＜/method＞
＜parameter value＝"100"＞id＜/parameter＞
＜parameter value＝"2"＞channel＜/parameter＞
＜/call＞
＜call＞
＜object＞storage＜/object＞
＜method＞Record＜/method＞
＜parameter value＝"100"＞id＜/parameter＞
＜/call＞
【００５６】
図１５に関して上で議論されたように、第１デバイスBはAのデバイス性能とAPIインタフェースの細部事項を調べるために第２デバイスAのINTERFACE.XML文書をアクセスし、第２デバイスAの支持された機能及び命令項目を決定できる。特別に、前記第１デバイスBは第１デバイスBと第２デバイスAにより支援されたオーバーラッピング、そして従って利用できる方法を決定できる。図１６は、アプリケーションBを含む第１サーバデバイスBがアプリケーションAを含む第２サーバデバイスAのINTERFACE-A.XML文書をアクセスする例を示す。前記第１サーバデバイスBは、第２サーバデバイスAでINTERFACE-A.XML文書と比較するためのINTERFACE-B.XMLを含む。
【００５７】
一つのシナリオで、前記第１サーバデバイスBはネットワークで第２サーバデバイスAを制御しようとする。前記第２デバイスAのINTERFACE-A.XML文書は第２サーバデバイスAから第１サーバデバイスBに伝送され、第２サーバデバイスAの性能及びAPIインタフェース方法を質問するアプリケーションBにより使われる。これは第１サーバデバイスBがXML遠隔手順呼び出しXMLRPCを使用して第２サーバデバイスAを制御することを許す。他のシナリオで、前記第１サーバデバイスBは少なくとも一回第２サーバデバイスAと通信を試みて通信確認が失敗した後、上記の段階を行う。また他のシナリオで、前記第１サーバデバイスBは第１サーバデバイスBにINTERFACE-A.XML文書を伝送せずに遠隔で第２サーバデバイスA内のINTERFACE-A.XMLに問合せる。
【００５８】
INTERFACE-A.XML文書の項目を調べることにおいて、前記第１サーバデバイスBは、前述されたようにXMLフォーマットで第２サーバデバイスAに伝送するための命令を創出できる。一般に前記第１サーバデバイスBは、前述されたように第１及び第２サーバデバイスB及びAにより使われたXCE定義サブセットでオーバーラップするINTERFACE-A.XMLの少なくとも一部項目を解釈できる。もし前記第１サーバデバイスBがINTERFACE-A.XML文書の一部項目を解釈できないならば、第１サーバデバイスBはその部分を無視したり、後述されるように翻訳によりその部分を説明するようにアシストするアプリケーションをフェッチできる。
【００５９】
図１７を参照すれば、制御器サーバデバイス１４及び制御されたサーバデバイス１４間のデバイス-デバイスまたは内部デバイスを制御する他の例が示される。前記制御器サーバデバイス１４は制御器アプリケーションを含み、制御されたサーバデバイス１４は実行可能なアプリケーションCを含む。制御されたサーバデバイス１４はINTERFACE-A.XML、アプリケーションCのアプリケーションインタフェース説明Aをさらに含む。アプリケーションEは、制御されたサーバデバイス１４の性能及び制御されたサーバデバイス１４のAPIインタフェース方法を問合せるために制御されたサーバデバイス１４内のアプリケーションインタフェース説明Aをアクセスする。次に、アプリケーションEは、制御されたサーバデバイス１４のハードウェアまたはサービスDを制御するためにXML遠隔手順呼び出しを使用してアプリケーションCを命令し制御する。スケジューラデバイスはVCRの時間-遅延-録画制御器のように定まった日になれば駆動する制御器サーバデバイス１４の一場合でありうる。
【００６０】
第１例で、前記アプリケーションEは、ネットワークを通じた遠隔照会によりアプリケーションインタフェース説明Aをアクセスする。第２例で、前記アプリケーションEは、制御されたサーバデバイス１４から制御器サーバデバイス１４にアプリケーションインタフェース説明Aのコピーを伝送することによってアプリケーションインタフェース説明Aをアクセスする。次に、アプリケーションEは局部的にインタフェース説明Aに問合せる。第３例で、アプリケーションインタフェース説明Aはインタフェース説明のためにライブラリー空間を提供するライブラリーデバイス６４に伝送され、アプリケーションEはライブラリーでインタフェース説明Aを遠隔で問合せる。前記ライブラリーデバイス６４は直接的な制御動作及び応答を使用できる関連したアプリケーションのアドレス(URL)を貯蔵する。
【００６１】
図１８を参照すれば、XMLプロトコルはネットワークで多様なサーバデバイス１４のアプリケーション２０間のAPIレベルで通信スタック６６においてウェブ標準共通ミドルウェア階層を提供する。各サーバデバイス１４で通信スタックの最上部アプリケーションはネットワークを通じて通信メッセージを送受信し、デバイスのためのデバイスハードウェアまたはサービスソフトウェアを局部的に制御するデバイススタックでソフトウェア階層と通信する。
【００６２】
XML層OUT ６８でデザインされた第１XML層APIはメッセージを送信するために使われ、XML層IN ７０でデザインされた第２XML層APIはメッセージを受信するために使われる。XCE定義と方法呼び出しのXML定義、即ち前述された文書タイプ定CALL.DTDは、XML層OUT ６８を生成するように使われる。さらにXCE定義及び方法呼び出しのためのXML定義、即ち前述された文書タイプ定義INTERFACE.DTDは、XML層IN ７０を生成するように使われる。例えば制御器アプリケーションはXML層OUT ６８を使用し、制御されたアプリケーションENXML層IN ７０を使用する。
【００６３】
図１９を参照すれば、サーバデバイス-サーバデバイス命令及び制御構造のさらに他の実施形態を示す。XML-基盤制御構造は、ウェブとインターネットにより駆動されるデバイスまたはサービスのためのデバイス-デバイス(サービス-対-サービス)のために使われる。第１デバイスAは、XML命令メッセージを使用するネットワークを通じて第２デバイスBでアプリケーション２０を遠隔で制御できる。各デバイスに対するインタフェースは前記デバイス内でアプリケーションに対するインタフェースを含みXMLフォーマットで述べられる。後述されるように、前記インタフェースはネットワークを通じて他のデバイスによる訂正及び説明のためにミドルウェア階層上で拡張され使用可能になりうる。
【００６４】
それぞれのサーバデバイスA及びBはネットワークを通じて他のサーバデバイスを制御し、ネットワークを通じて他のサーバデバイスにより制御されるためのハードウェアとソフトウェアを含む。図１９で、ホームネットワークデバイスAは制御器デバイスまたはモジュールであり、ホームネットワークデバイスBは制御されたデバイスまたはモジュールである。それぞれのデバイスA及びBは、インタフェース文書INTERFACE.XML及び文書タイプ定義INTERFACE.DTDで構成された局部的なデバイスXMLインタフェース７２を含む。INTERFACE.XML文書は対応するサーバデバイス１４により支援される対象、方法及びパラメータの説明を含む。前記INTERFACE.DTD文書は、前述されたようにデバイスのXMLインタフェースで具体的な正当性チェックのために使われたりする。
【００６５】
それぞれのデバイスA及びBはまたXMLインタフェース及びXMLRPC命令のようなXMLメッセージをパーシングし確認するためのプログラムコードで構成されたXMLパーサ(Parser)７４を含む。前記XMLパーサ７４は図１８に関して前述された前記XML階層IN ７０と類似である。さらに、それぞれのデバイスA及びBは、XMLRPCの方法名とパラメータを再生するためにXMLRPCメッセージから送出する方法名とパラメータをエンコーディングするためのXMLRPCエンコーダ及び入力されるXMLRPCメッセージをデコーディングするためのXMLRPCデコーダを含む。XMLRPCコデック７６はデバイスXMLインタフェース７２及びデバイス-デバイス制御構造から独立され、それよりデバイス-デバイス制御構造の他の特徴を変化させずに他のXMLRPCフォーマットの使用を許す。
【００６６】
プログラムコードで構成されたインタフェースフェッチャー(Fetcher)は、さらに他のデバイスまたはホームネットワークインタフェースライブラリー８０から直接的にさらに他のデバイスのデバイスインタフェースをフェッチするためにそれぞれのデバイスA及びBにより使われる。サーバデバイス１４が制御器デバイスであれば、制御器サーバデバイス１４内の制御器アプリケーションプログラムコード８２は、XMLパーサ７４、インタフェースフェッチャー７８及びXMLRPCコデック７６のような制御器サーバデバイス１４内のソフトウェア及びハードウェアを統制することによって、ネットワークを通じて他のサーバデバイス１４の命令及び制御に影響を与える。サーバデバイス１４が制御されたデバイスであれば、制御されたサーバデバイス１４内の制御されたアプリケーションプログラムコード８４は他のサーバデバイス１４により制御されるサーバデバイス１４のためにサーバデバイス１４内のソフトウェア及びハードウェアを統制する。それぞれのデバイスA及びB内のホームネットワークデバイスウェブサーバ８６はネットワーク上のデバイス間の通信を管理する。各デバイスA及びB内の固有ルックアップテーブル８８に対するXMLはX、MLRPCメッセージ(例えば方法名称、構成要素名称及びタイプ)をデバイスの固有インタフェース(例えば固有方法名称、構成要素及びタイプ)に変換する制御されたアプリケーション８４により使われる。前記テーブル８８は、XMLメッセージ内で方法及びパラメータの名称とデバイスの固有インタフェースが同じ場合には使われない。
【００６７】
それぞれのデバイスA及びBは一つ以上のハンドラ(Handler)９０をさらに含み、各ハンドラ９０は制御されたアプリケーション８４内部から特定デバイス機能の固有具現へのポインタを含む。大部分のデバイスでデバイス機能の固有具現は実行時間での２進コードを含む。２進コードは例えばC及びジャワを含んで、コンパイル時間に高水準の言語から生成されられる。従って、電化製品製造者は存在するハンドラ及び機能具現に影響を及ぼさずに新たな機能のためのより優れたハンドラ９０を追加できる。それぞれのデバイスA及びBでハードウェアサービス９２はデバイス機能の固有具現を含む。それぞれのデバイスA及びBはまたデバイス機能の固有具現でAPIを具備する固有インタフェース９４を含む。
【００６８】
さらに、ホームネットワーク対象要請ブローカー(HNORB: Home Network Object Request Broker)７９及びインタフェースライブラリー(IL: Interface Library)のようなネットワーク対象要請ブローカーはホームネットワーク１０のためのミドルウェア階層９８を提供する。図１９に示したように、前記ミドルウェア階層９８は第３デバイス９６または分離された制御ハブに位置できる。前記HNORB７９は、ネットワーク１０に接続された他のサーバデバイス１４の存在を見つける一つのサーバデバイス１４により使われるためのソフトウェアエイジェントを含む。前記HNORBソフトウェアエイジェントはデバイス名称を名称の階層的なツリー構造で組織し、デバイスインタフェースを前記検索できるインタフェースライブラリーで組織し、そしてインタフェース情報を要請するデバイスにデバイスインタフェースを提供する。
【００６９】
HNORB ７９及びIL ８０で構成されたミドルウェア階層は、指定された局部的なホームネットワーク１０の外部からアクセスされる選択されたホームデバイスのようにインターネットに直接連結されられる。一つの局部的なホームネットワーク内のミドルウェア階層９８は、二つのホームネットワーク１０を備える統合されたネットワークを提供するためにインターネットを通じて他の局部的なホームネットワークでミドルウェア階層９８に接続される。このような場合に、適当なストリーム符号化を有する認証された使用者はビデオを再生しTVでそれを見るために使用者の第２家庭内のTVから使用者の第１家庭内のDVDチェンジャ(Changer)をアクセスできる。
【００７０】
前記インタフェースライブラリー８０を使用するために、少なくとも一つのHNORB&ILは局部的なホームネットワーク１０上で動作中であるべきだ。一つ以上のHNORB&ILがまた利用される。例えば、ケーブルモデム、いくつかのDTV、そして中央家庭ハブは全てそれら自体のHNORB&ILソフトウェアエイジェントを有することができる。HNORB&ILの位置を定めるためにサーバデバイス１４は局部的なホームネットワークを通じて放送メッセージを伝送する。サーバデバイス１４で応答した第１HNORB&ILはサーバデバイス１４により使われる。一応HNORB&ILが位置すれば、サーバデバイス１４及びHNORB&ILは登録、インタフェース要請及びフェッチのための地点間TCP(Transmission Control Protocol)またはUDP(User Datagram Protocol)とデバイスルックアップサービスを確認できる。もしUDPプロトコルを利用できなければ、TCPプロトコルがIEEE１３９４のような高帯域幅接続のために使われる。HTTP-基盤のXMLRPCはHNORB&IL通信のためのデバイスのために使われる。例えば、サーバデバイス１４は一つ以上の構成要素としてデバイスインタフェースをパスするためにHNORBの”レジスター”方法を遠隔で呼び出せ、またはXMLRPC呼び出しはXMLRPC応答または戻る値としてILから部分的または全体的なデバイスインタフェースを再生できる。
【００７１】
前述したように、一つ以上のHNORB&ILは同時に局部的なホームネットワーク１０で動作でき、ここで各HNORB&ILは使用可能なデバイスのサブセットを認識でき、一つのHNORB&ILは見つけられないサーバデバイス１４を位置させるために他のHNORB&ILと通信できる。一つの局部的なホームネットワーク１０上の多重HNORB&ILは、UDP及びTCPのような放送メッセージを使用することによって自動で相互間に位置できる。このような場合に、多重HNORB&ILは多数のインタフェースライブラリー８０が分散インタフェースライブラリーを構成する間分散対象要請ブローカーを構成する。故障許容誤差を提供するために、もし一つのHNORB&ILが突然終らなければならないならば、このHNORB&ILと共に登録された全てのデバイスは通知され、前記デバイスは他の有用なHNORB&ILと共に自動で登録される。
【００７２】
各デバイスインタフェースは組合された一貫的で単一の論理的な名称を有している。他のデバイスは、前記デバイスの位置または実際ネットワークアドレスが変わった後にもデバイスを認識しアクセスする前記一貫的で単一の論理的な名称を使用できる。論理的な名称のマッピングと実際デバイスアドレスのマッピングはHNORBで命名サービスのためのソフトウェアエイジェントにより扱われる。望ましくは、標準化された命名方法が使われる。より望ましくは、デバイス名称を階層的ツリー構造で操作するために階層的な命名構造が使われる。この階層的な構造はファイルシステムと類似に”/”を使用して表現できる。その構造は、家庭/MPEG２/TVのような他のサービスタイプにより、または家庭/居間/VCRのような他の位置によるもののように、他の方法で生成される。いろいろな命名ツリーは実行と能率のために共存できる。
【００７３】
図１９での制御器サーバデバイスA及び制御器サーバデバイスB間の命令及び制御例で、前記ミドルウェア階層９８は第３デバイス９６にあったり、または分離された中心ハブにありうる。暗いブロックは、図１９に示した特殊な命令及び制御プロセッサーのために使われたデバイス構成要素を示す。動作シナリオで、デバイスA及びBがネットワークを通じて使用可能になりアクセス可能になった後、各デバイスは中央HNORB及びILミドルウェア層９８にそれ自体及びそれのXMLインタフェースを書込み/提出する。もし中央HNORB及びILミドルウェア階層が使用できなければ、各デバイスはそれ自体を知らせるために局部的なホームネットワークを通じてメッセージを放送する。
【００７４】
前記デバイスAの制御器アプリケーション８２は制御されたデバイスBの全体または部分のデバイスインタフェースに問合せを試みる。もしインタフェースライブラリー８０が有用でなければ、制御器デバイスAはネットワークを通じてデバイスBに要請を最初に伝送し、それからデバイスBからデバイスBのXMLインタフェースを受信することによって、制御器デバイスBから直接的に制御されたデバイスBのデバイスインタフェースを求めフェッチできる。しかし、もしインタフェースライブラリー８０が使用できれば、制御器デバイスAはインタフェースライブラリー８０から制御されたデバイスBの全体または部分のデバイスインタフェースを求められる。HNORBのソフトウェアエイジェントはインタフェースライブラリー８０から前記デバイスBのXMLデバイスインタフェースを得、制御器デバイスAにそれを回送する。
【００７５】
一応制御器デバイスAが制御されたデバイスBのXMLデバイスインタフェースを受信すれば、デバイスAの制御器アプリケーションはデバイスBのデバイスインタフェースを分析し翻訳するためにデバイスAのXMLパーサ７４を使用する。それからデバイスAのXMLRPCコデック７６はパーシング結果を使用して望ましいXMLRPC命令メッセージを生成する。前記XMLRPC命令メッセージはネットワークを通じて制御されたデバイスBに伝送される。前記XMLRPC命令メッセージを受信すれば、デバイスBの制御されたアプリケーション８４は受信されたXML命令メッセージを分析し翻訳するためにデバイスBのXMLパーサ７４を用いる。それからデバイスBのXMLRPCコデック７６は、求められたサービスを行うためにデバイスB機能のための方法名称及びパラメータを含む命令メッセージから方法呼び出し情報を得るためにパーシング結果をデコーディングする。
【００７６】
デバイスBの制御されたアプリケーション８４は、次にデバイスBの固有インタフェースを通じてデバイスBの固有機能実行をアクセスし送出するためにデバイスBで固有ルックアップテーブル８８及びハンドラ９０に対してXMLを使用する。もし関数がある応答または戻る値を生成すれば、前記応答または戻る値はXMLまたはXMLRPCメッセージにエンコーディングされ、制御器デバイスAに伝送される。さらに、ミドルウェア階層HNORB及びILは制御されたデバイスBに対する参照を制御されたデバイスAに提供し、ここでデバイスAは局部的なデバイスA固有機能に対する呼び出しと同じようにデバイスB固有機能に対する遠隔呼び出しを発生させる。
【００７７】
望ましくは、全てのデバイスがネットワークを通じてRPC呼び出しを説明しデコーディングできるように、標準XMLRPCフォーマットが使われる。制御されたサーバデバイス１４のデバイスインタフェースが制御器サーバデバイス１４により問合せられ調査されるために、望ましくは能率を向上させるために充分なデバイスインタフェース情報を有する単純化されたXMLRPCフォーマットが使われる。次の例はOTR(One Touch Record)及びTDR(Time Delayed Record)動作のためにXMLRPCを呼び出す二つの可能なフォーマットを示す。
例Ｉ:
XMLRPC呼び出し、詳細タグ及びインタフェース情報を含むフォーマット例:
１．OTR呼び出し例:
＜?xml version＝”1.0”?＞
＜call＞
＜object＞DVCR1.record＜/object＞
＜method＞timeDelayedRecord＜/method＞
＜parameter＞
＜parameter＞
＜name＞channel＜/name＞
＜value＞＜int＞4＜/int＞＜/value＞
＜/parameter＞
＜parameter＞
＜name＞recordTime＜/name＞
＜value＞＜time＞2:10:30＜/time＞＜/value＞
＜/parameter＞
＜/parameters＞
＜/call＞
２．TDR呼び出し例:
＜?xmlversion＝”1.0”?＞
＜call＞
＜object＞DVCR1.record＜/object＞
＜method＞timeDelayedRecord＜/method＞
＜parameter＞
＜name＞channel＜/name＞
＜value＞＜channelName＞NBC＜/channelName＞＜/value＞
＜/parameter＞
＜parameter＞
＜name＞startTime＜/name＞
＜value＞＜datetime.iso8601＞19990401T19:05:35＜
/datetime.iso8601＞＜/value＞
＜/parameter＞
＜parameter＞
＜name＞recordTime＜/name＞
＜value＞＜time＞2:00:00＜/time＞＜/value＞
＜/parameter＞
＜/parameters＞
＜/call＞
例II:
XMLRPC呼び出し、減ったタグ及びインタフェース情報を有するフォーマット例:
１．OTR呼び出し例:
＜?xml version＝”1.0”?＞
＜call＞
＜object＞DVCR1.record＜/object＞
＜method＞timeDelayedRecord＜/method＞
＜parameter value＝”4”＞channel＜/parameter＞
＜parameter value＝”2:10:30”＞recordTime＜/parameter＞
＜/call＞
２．TDR呼び出し例:
＜?xml version＝”1.0”?＞
＜call＞
＜object＞DVCR1.record＜/object＞
＜method＞oneTouchRecord＜/method＞
＜parameter value＝”NBC”＞channel＜/parameter＞
＜prameter
value＝”1990401T19:05:35”＞startTime＜/parameter＞
＜parameter value＝”2:00:00”＞recordTime＜/parameter＞
＜/call＞
【００７８】
図２０を参照すれば、ホームデバイスであるサーバデバイス１４のためのデバイスインタフェースは、標準化された用語を使用する産業標準の構造化されたデータベース１００に基づく。新たなインタフェースのためのインタフェースデータ及び用語はデータベース１００に追加される。CE対象を説明するために英語単語を使用する包括的な定義あるいはデータベース、方法そしてパラメータはCEデータベース１０２に規定される。包括的な定義またはデータベースは対象及びそれらそれぞれの方法及び構成要素を示すC、XMLまたは他のフォーマットになりうる。標準化されたXML用語を使用する包括的な定義またはデータベースはXCE定義またはデータベース１０４と呼ばれる。
【００７９】
制御器及び制御されたアプリケーション８２、８４は、XCEデータベース１０４に基づいたXMLの標準インタフェースサブセットを使用してプログラムされる。各デバイスインタフェースはXML形態で前記アプリケーション８２、８４と共に貯蔵される。たとえ前記XCEデータベース１０４がXMLにある必要がないとしても、図１５に関して前述されたように、本発明の実施形態でコンパイル時に作成された前記サブセットインタフェースはXML内にある。
【００８０】
図２０で、埋め込まれた装置１４のために’製造会社’情報としてデザインされた情報は製造時装置１４に内蔵されたものであり、’ホームネットワーク’としてデザインされた情報はネットワークで装置の動作的実行時間特徴の一部であるNデバイスのための１....NとしてデザインされたデバイスXMLインタフェース７２は、標準化されたXCEデータベース１０４でデータの一部分である。ホームネットワークインタフェースライブラリー(HNIL: Home Network Interface Library)１０６はホームネットワークに接続された使用可能なサーバデバイス１４のデバイスインタフェース集合を提供する。HNIL １０６は全体XCEデータベース１０４のサブセットである。
【００８１】
図１６で、デバイスインタフェースはデバイスAのためのインタフェースの内容を調べるデバイスB内のアプリケーションBのためにデバイスAからデバイスBに伝送される。前述されたように、デバイスインタフェースはデバイスにより維持される対象、方法パラメータの説明を含み、例えばデバイスAに対するINTERFACE-A.XMLとして言及される。デバイスXMLインタフェース７２はXMLフォーマットのデバイスインタフェースである。XCEデータベース１０４の内容はデバイスインタフェースを提供するサービス基盤の構造である。
【００８２】
図２０を参照すれば、前記XCEデータベース１０４は、またCEサーバデバイス１４を表現するXMLを使用するために標準化された規定セットを提供するCEデバイスのための標準化されたXCEインタフェース文書タイプ定義(DTD: Document Type Definition)を提供する。前記DTDまたはそのサブセットは正当性チェックのために使われる。製造会社手段１０８としてデザインされたソフトウェアエイジェントは、規定されたCEデバイスのための標準化されたXCE定義のサブセットをフィルタリングして使用するが、例えばINTERFACE.XML及びINTERFACE.DTDのようなCEデバイスのXMLデバイスインタフェース７２を生成する標準化されたXCEインタフェースDTDを使用する。前記文書INTERFACE.XMLは標準化されたXCEインタフェースDTDに従って特殊なデバイスにより支援される対象、方法及びパラメータの説明を含む。前記文書INTERFACE.DTDは標準化されたXCEインタフェースDTDのサブセットであって、デバイスのXMLインタフェースのための正当性チェックのために使われる。他の文書タイプ定義もINTERFACE.XML文書を生成するために使われたりする。
【００８３】
前記XMLインタフェース文書及び前記DTD文書を含むCEデバイスのXMLインタフェース７２は、ホームネットワークインタフェースライブラリー１０６のような一般的にアクセスできるライブラリーに貯蔵される。ソフトウェアエイジェント１１０はネットワーク上の全てのアクセスできるサーバデバイス１４のデバイスインタフェース７２を収集し、デバイス名称/アドレス情報と共に検索できる構造化されたインタフェースライブラリー１０６にそれらを配置する。前記インタフェースライブラリー１０６はXCEデータベース１０４のサブセットであって、インタフェースライブラリー１０６を作る過程は部分または全てのXCEデータベース１０４を再構成することと類似である。前記インタフェースライブラリー１０６は、ホームネットワーク内の全てのデバイスのデバイスインタフェースの集合または最も最近に使われたデバイスインタフェース７２が貯蔵されるホームネットワークで全てのサーバデバイス１４の有用性に依存するキャッシュ(Cache)として機能できる。サーバデバイス１４が、DVD再生器でディスクを変えることのようなイベントに起因してそのデバイスインタフェース７２を更新した場合には、デバイスインタフェース７２の一部がイベントサービスに基づいて更新される。
【００８４】
図２１を参照すれば、望ましくは各サーバデバイス１４のデバイスインタフェース定義７２は階層的な形態を有する。なぜならこれはホームデバイスにおいて、デバイスインタフェース定義７２が長くなる可能性があるからである。典型的に、時間遅延された録画のための単一機能のような一つまたは少数の機能は同時にアクセスされ、従って前記デバイスインタフェース７２の唯一に小さな部分が使われる。全体デバイスインタフェース７２を作成することよりはデバイスインタフェース７２の一部分だけを作成することがより効果的である。階層的なデバイスXMLインタフェースを使用することによって、制御器サーバデバイス１４は、制御器サーバデバイス１４またはHNORB及びILミドルウェア階層９８からXMLデバイスインタフェースのための要求において望ましい機能カテゴリーまたは機能を特定することによって、制御されたサーバデバイス１４の部分的なデバイスインタフェース７２を求められる。後者の場合に、HNORB及びILミドルウェア階層９８はデバイスインタフェース７２の望ましい部分を回送する。
【００８５】
図２１を参照すれば、前記階層的なデバイスインタフェース構造は、(１) 現在有用なデバイスを書込んだ各ホームネットワークのXMLインタフェースのための第１階層１１２、(２) 機能カテゴリーを書込んだ各デバイスの一般的なXMLインタフェースのための第２階層１１４、(３) デバイスのための各機能カテゴリーのXMLインタフェースを規定するための第３階層１１６、(４) 機能カテゴリー内の各機能のXMLインタフェースを規格化するための第４階層１１８を含む４個の層を含む。ホームネットワーク内部で、ただ三つの下位層１１４、１１６及び１１８が使われ、ホームネットワーク外部で第１層１１２が使われる。
【００８６】
図２２は、前記層１１２、１１４、１１６、１１８及び対応するインタフェース例を示す。各階層内のインタフェースは(できれば)両方向リンクを提供するXリンクまたはXポインタのようなリンクを通じて上位または下位層にリンクされる。Xリンクは(１) XML文書内のリンクをリンクとして認識させるXリンク成分、(２) リンクをXML文書の正確なサブパートにアドレッシングさせるXポインタ成分の二つのパートを有するハイパーリンキング機能性のパッケージを含む。従って、XリンクはどのようにリンクがXML文書に挿入されるかを管理するが、ここで前記リンクはGIFファイルのようなデータを示す。さらにXポインタは、どこからでも(例えばHTMLファイルから)、XML文書にリンクする時URLに行ける断片識別子(Fragment Identifier)を決定する。
【００８７】
本発明に係る他のサーバデバイス１４を制御するサーバデバイス１４のための典型的な命令及び制御モデルで、第１サーバデバイス１４は第２インタフェース階層１１４で第２サーバデバイス１４のデバイスインタフェースを問合せるように試みる。機能カテゴリー(FC: Function Category)を選択した後、前記第１サーバデバイス１４は、録画カテゴリーのような第２サーバデバイス１４で特定の機能カテゴリーのインタフェース階層１１６を問合せる。さらに、前記第１サーバデバイス１４は前記機能に対する呼び出しを作るためにOTRまたはTDRのように特定の機能をインタフェース階層１１８に問合せる。階層的またはツリー構造はより効果的なインタフェース機能を探すようにしてネットワーク帯域幅を縮める。インタフェースファイル構造及び層の例が下記の通りである。
第１層１１２-HN1.xmlXML
第２層１１４-VCR1.xml
第３層１１６-VCR1_RecordCategory.xml
第４層１１８-VCR1_RecordCategory_OTR.xml
【００８８】
類似に、ホームネットワークインタフェースライブラリー１０６は階層的であり、デバイスの他のサービスタイプまたはルームのような他の位置により多様な方法で構造化できる。前記階層的な構造は他のホームネットワークまたはインターネットに対する局部的なホームネットワーク１０のインタフェースである。
【００８９】
XMLシンタックス(Syntax)で具現される例示的で階層的なデバイスインタフェース定義７２が下に示される（記載中のEthernetは登録商標）。
consumer(document_file,doc)
＋----document_file＜server_home.dtd,server_auto.dtd＞
＋----doc(services_home,server_auto,server_samsung_web_site,avc_commands,cal_commands,,)
＋----services_home(xml_utility,client,server_av,lighting,comms,hvac,utility,security,appliances,convenience,,)
＋----xml_utility(download_DTD_file,,)
＋----client(acknowledge,attention,error,post_message,sound,stop_schedule,stop_all,,)
＋----sound(alarm,ring,buzz,,)
＋----server_av(controls_gen,source,sink)
＋----controls_gen(ping,process_infor,setup,,)
＋----process_info(s/w_id,h/w_id)
＋----h/w_id(ser_no,manuf,model,class,,)
＋----s/w_id(ser_no,exe_name,version,,)
＋----setup(clock,,)
＋----clock(hours,minutes,seconds)
＋----source(service_id,media,rate,protocol,stream_format,controls_av,,)
＋----sink(service_id,media,rate,protocol,stream_format,controls_av,,)
＋----service_id(url,,)
＋----media(tpt_stream,ram,disk,tape,,)
＋----disk(name,number,,)
＋----rate＜value＞
＋----protocol(61883/1394,UDP/IP/Ethernet,,)
＋----61883/1394(isoch_ch_no)
＋----stream_format(video、audio,,)
＋----video(dv,mpeg2tpt,dsstpt,mpeg2pes,mpeg10801-tpt,)
＋----audio(mpeg3,ac-3,midi,,)
＋controls_av(flow_control,tune,timer_record,ui_control,,)
＋----timer_record(tune,flow_control)
＋----flow control(play,stop,goto,record,,)
＋----play(time_params)
＋----record(time_params)
＋----time_params(now,start,duration,end,,)
＋----tune(send_epg,channel,,)
＋----channel(number,id,time_params,,)
＋----ui_control(display,acoustic)
＋----display(brightness,contrast,color/tint,horiz_size,vert_size,,)
＋----acoustic(volumn,base,treble,balance,fade,)
＋----lighting(sensors,lights,send_epg)
＋----sensors(living_room,sky,,)
＋----lights(rooms_up,rooms_down,yard,,)
＋----rooms_up(bed1,bed2,bed3,bed4,,)
＋----bed1(lamp,dimmer,,)
＋---dimmer＜value＞
＋----rooms_down(family,kitchen,living,dining,soho,garage,,)
＋-----yard(front,back)
＋----comms(homehub,intercom,telco,)
＋----homehub(send_device_list,send_configuration,sene_snmp_mib,,)
＋----intercom()
＋----telco()
＋----hvac(controls_gen,controls_havc,,)
＋----controls_hvac(a/c,heat,temp,humidity,)
＋----temp(low,high,hysteresis,,)
＋----utility(meters,energy_mgmt,,)
＋----meters(water,gas,electric,,)
＋----water＜value＞,gas＜value＞,electric＜value＞
＋----security(sensors,send_epg,alarm,,)
＋----sensors(peripheral,motion,,)
＋----peripheral(rooms_up,rooms_down,,)
＋----motion(room_down,yard,,)
＋----appliances(microwave,range,oven,fridge,freezer,coffee,toaster,washer,dryer,water_heater,,)
＋----microwave(send_epg,controls,,)
＋----fridge(temp,)
＋----water_heater(temp,)
＋----convenience(window,curtain_open,door/gate,pool/spa,bath,fountain,lift,jacuzzi,,)
＋----curtain_open＜value＞
＋----server_auto(message,server_auto_ford_explorer_98,,)
＋----server_auto_ford_explorer_98(mileage,maintenance,,)
＋----mileage＜data＞
＋----maintenance＜data＞
＋----server_samsung_web_site(message,service,help,,,)
＋----avc_commands＜,,,command_string,,,＞
＋----service_id(url,,)
＋cal_commands＜,,,command_string,,,＞
＋----service_id(url,,)
【００９０】
前記階層的なデバイスインタフェース定義７２は次のような分野を含む。
‘document file’、これはXCEデータベース１０４またはXCEデータベース１０４のバージョン部分の正当性及び訂正の検証のためにXMLパーサにより使われる文書タイプの規定(DTD)ファイルの名称を提供する。前記XCE構造の相異なる部分のためのいろいろなDTDファイルがありえ、ここで前記DTDはRPC.CALLのための文書タイプ定義及び通信のためのINTERFACE.DTDとは違う。
‘doc’、これは互換性、特性、通信及び制御インタフェースの領域の最上位レベル名称を提供する。
‘Services_home’、これは家庭自動化、電化製品、効用性のための領域を提供する。
‘Server_auto’、これは車庫内にある自動車に対して、一台またはそれ以上の自動車タイプに対する有用なメッセージインタフェースを示す。例えば、‘server_auto_ford_explorer_98’は特定自動車に対するインタフェースである。これは自動車のマイレージ及び保守インタフェースをアクセスできるようにし、直接チェックする自動車製造会社または車庫が直接チェックまたは遠隔診断する遠隔アクセスで使われる。
‘server_samsung_web_site’、これは家庭外部の製造会社ウェブサイトと通信し、メッセージ、サービス、アシストなどのためのインタフェースを含む。
‘AVC_commands’及び‘CAL_commands’、これは例えばAV/C及びCAL言語を解釈できるレガシーデバイスを提供する。この構造部分は前記言語で命令を確認し、命令はXMLで付加されたり行われる。従って、前記項目はXCE(Web)対象ではなく、プロトコル変換器アプリケーションは元のCALまたはAV/Cアプリケーションソフトウェアへのインタフェースとして使われる。
【００９１】
前述したように、‘Services_home’はA/V電化製品を含むメーン構造を提供する。前記構造の一部分は特定な例としてビデオサービスシンク及びストリーム目的地(例えば、DVCR)制御インタフェースに対し詳細に拡張される。典型的なホームネットワークで制御インタフェースは次を含む：
‘xml_utility’、これは更新されたDTDファイル、インタフェースファイル、プログラムファイルをダウンローディングすることのように支援ユーティリティネットワーク機能を支援するための細部事項を提供する。
‘client’、これはウェブブラウザーを含むクライアントデバイス１２のインタフェース細部事項を説明する。例えば、‘acknowledgment’は発送されたメッセージまたは命令で制御器の認証承知を表示する。
‘server_av’、これはSTB、DVCR、DTV、DVD、AUDIOなどを含む有用な全てのオーディオ及びビデオサービスに対して制御及び容量インタフェースを提供する。
‘lighting’、これは家庭自動化照明制御器にインタフェースを提供し、センサー及び照明などを含む。
‘comms’、これは典型的に使用目的またはデバイスのセット-アップまたは構成要素の遠隔管理または構成を復旧するために通信デバイスに制御インタフェースを提供する。
‘hvac’、これはHVACシステムの遠隔制御のためのインタフェースを提供し、例えばその日のピーク負荷期間中に家庭のHVACシステムを消すために公益設備会社(Utility company)により家庭外部から前記システムを制御するために使われる。さらに、前記インタフェースは、自動温度調節装置制御よりさらに複雑な制御メカニズムを提供する制御器に基づいたデバイスのための装置により、家庭内部からHVACシステムを制御するために使われる場合もある。
‘utility’、これは例えば、家庭のための計量器を読取るためのインタフェースを提供する。
‘security’、これは保安センサー及びアラームセッティングのためのインタフェースを提供する。従って、ホームネットワークデバイス上でインタフェース使用、アプリケーション進行はそのデバイスの監視及び制御のための家庭周辺のセンサー及び感知器をアクセスできる。
‘appliances’、これは例えば、遠隔制御または温度設定感知または制御器デバイスから他の制御及び構成要素を含む台所、有用で一般の家庭装置のためのインタフェースを提供する。一シナリオで、電子レンジは料理アイテムパッケージ上のバーコード情報をスキャンでき、与えられた電子レンジシステムタイプに対して料理の調理時間を分かるために製造業者データベースをアクセスできる。デバイス-デバイス命令及び制御を使用する装置の統合は、台所または居間で電話を受けた時自動で食器洗い器を止めテレビをミュート(Muting)させることのようなサービスを提供するために多くの制御シナリオを提供する。
‘convenience’、これは例えばカーテン、窓、ブラインドまたは洗濯制御器に対するインタフェースのように便宜サービスを提供するために装置に対するインタフェースを提供する。
【００９２】
前記の説明で、‘server_av’はA/Vサービスを提供するA/V装置に対して制御インタフェースのための構造の一部分であって、‘controls-gen’、‘source’、‘sink’性能にまた分けられる。
‘controls-gen’は、デバイス製造者属性及びデバイス存在をテストするピング(Ping)テストのような一般のユーティリティインターフェーシングのためのインタフェースを提供する。さらに、ソフトウェア及びハードウェア確認及びバージョン情報のような製造特性が含まれる。前記インタフェースを提供するデバイスはどんな制御動作ももたらさずに前記ソフトウェアに対する名称または確認を提供するデータを返す。またデイクロックの時間をセットするインタフェースが含まれる。
‘sink’は、メディアストリームサービスデバイスのためのインタフェースを提供する。その構造はVCRのような特別のデバイス名称というよりは提供されたサービス(例えば、ビデオストリーム録画及び再生)に基づいた構成である。例えば、チューナとDVDプレーヤーは二つともネットワークに対してビデオプログラムフォーマットを有するビデオプログラムストリームソースであって、開始及び停止のように制御される。特定のデバイス制御での差異点は構造化定義の下部階層によりアドレスされる。
‘source’は‘sink’インタフェースと類似のインタフェースを提供する。
【００９３】
前述した内容を参照すれば、‘service_id’または‘application_interface_id’は名称、アドレスまたはウェブアドレス、または一つ以上のデバイスのURL位置を含む。XCEデータベース１０４はインタフェースに対して合意された全体を構成するために、通常DHCP(Dynamic Host Configuration Protocol)ソフトウェアエイジェントは各デバイスにアドレス及びデフォルト名称を割り当て、前記アドレス及びデフォルト名称はサービスまたはデバイスのインタフェースに追加される。それから、ソフトウェアエイジェント１１０は‘部分的なXCEネットワーク(Network partial XCE)’を生成するために、ホームネットワークに局部的に接続された全てのデバイスからサブセットまたは’部分的なXCEデバイス(Device partial XCE)’を含むデバイスインタフェース７２を集める。付加的な関連外部インタフェースが外部制御のための構造に追加される。例えば、‘service_id’は、ネットワークに接続されたデバイスのデバイスインタフェースによってソフトウェアエイジェントから加入を含む受信された構造またはネットワークインタフェースライブラリー１０６内の名称/アドレスでありうる。その後、使用者はデータベースでサービスを検索でき、前記名称/アドレスを使用してライブラリーの特定のデータ部分を含むアプリケーションをアクセスできる。従って、ネットワークは前記名称/アドレス情報により識別された多重の同じサービスを含むことができる。
【００９４】
‘media’、これは例えば、チューナからの伝送ストリーム、PC DRAMからRAM、DCまたはDVDのためのディスク及びテープを含むメディアタイプのためのインタフェースを提供する。前記メディアは命名され確認され、制御器デバイスはネットワーク上で提供される一般のメディアを確認するXCEデータベースを検索できる。DVDディスクのような新たなメディアがネットワーク上で提供される時、ディスク上でプログラム資料を確認するデバイスインタフェース７２の一部が適合に変換される。従って、全体デバイスインタフェース７２が伝送される必要はなく、ただ適した部分がXCEデータベースに伝送される。アテンション信号の受信でライブラリーソフトウェアエイジェント１１０は新たな更新をフェッチでき、適した場所にそれを位置させられる。ディスクメディアの付加は、前記ネットワークにサービスを追加したりまたは前記ネットワークに他の装置を接続することと類似である。
‘rate’、これは例えば、６Mbits/Secまたは１９.２Mbits/Secのようにデバイスインタフェースのためのデータストリームレートに対する値を提供する。
‘protocol’、これは前記データストリームのために使われたプロトコルを確認する。例えば、６１８８３/１３９４またはUに/IPのように、一つ以上のプロトコルが提供されれば、望ましいプロトコルが選択される。
‘stream_format’、これはデジタルストリームオーディオ及びビデオ分割のためのパケットフォーマット及び/または圧縮標準を提供する。もし一つ以上のフォーマットが提供されれば、望ましいフォーマットがインタフェースメッセージを通じて選択される。制御器アプリケーション８２は互換的なフォーマットがあるかどうかを決定できるフォーマットを調べられる。
‘controls_av’、これはA/Vメディア装置のためのメーン制御インタフェースを提供する。
‘Flow_control’、これは特定のデバイスのための方法であってPLAY、STOP、GOTO、RECORDのようなデータストリーム制御を提供する。その方法は、例えばPCソフトウェアを除いては埋め込まれた(Embedded)装置に対して変わらない。tkdrl制御は遅延された動作のために時間構成要素を含むことができる。
‘Tuning’、これはチューニング制御のためのインタフェースを提供する。制御器サーバデバイス１４は、制御されたサーバデバイス１４のインタフェースに前述された電子プログラムガイド(EPG: Electronic Program Guide)データ構造の返信を求められる。
‘UIcontrol’、これはディスプレイに対する輝度及びコントラスト、オーディオに対するボリューム及びベースのような修正を制御するために制御されたアプリケーション８４に制御インタフェースを提供する。
‘Timer_record’、これは遅延された時間記録を具現するために制御器アプリケーション８２に対してセット-アップデータのためのインタフェースを提供する。直接的なチャンネル同調情報及びフロー制御(time_aparams)情報が使われたりする。
【００９５】
前記の説明はクライアントデバイス１２に同一に適用できる。CE領域のための他のシンタックスXCE定義またはデータベースが使われたりする。代案的なシンタックスXCEデータベースは、例えば家庭自動化、装置及び自動車を含む全てのサービス説明を含む。サービス対象が制御のために適応性及びパラメータを提供する場合、制御方法は希望の通りに前記対象を制御するために使われる。２進数または１６進数データ列を含むAV/C及びCAL命令語で命令例が下に示される（記載中のEthernetは登録商標）。
consumer(document_file,doc)
＋----document_file＜server_home.dtd,server_auto.dtd＞
＋----doc(avec_commands,cal_commands,services_home,server_auto,)
server_auto,
server_samsung_web_site,server_auto_ford_explorer_98,,)
＋----avc_commands＜...command_string...＞
＋----call_commands＜...command_string...＞
＋----services_home(client,av,lighting,comms,hvac,utility,security,appliance,convenience,,)
＋----xml_utility(download_DTD_files,,)
＋----client(acknowledge,attention,error,post_schedule,soundstop_schedule,stop_all,,)
＋----sound(alarm,ring,buzz,,)
＋----server_av(source,sink)
＋----soruce(service_id,media,rate,protocol,stream_format,controls_gen,controls_av,,)
＋----sink(service_id,media,rate,protocol,stream_format,controls,,)
＋----service_id(url,,)
＋----media(tpt_stream,ram,disk,tape,,)
＋----disk(name,number,,)
＋----rate＜value＞
＋----protocol(61883/1394,UDP/IP/Ethernet,,)
＋----61883/1394(isoch_ch_no)
＋----stream_format(video,audio,,)
＋----video(dv,mpeg2tpt,dsstpt,mpeg2pes,mepeg1080i-tpt,)
＋----audio(mpeg3,ac-3,midi,,)
＋----control_gen(ping,process_info,setup,,)
＋----controls_av(flow_control,tune,timer_record,ui_control,,)
＋----process_info(s/w_id,h/w_id)
＋----h/w_id(ser_no,manuf,model,class,,
)
＋----s/w_id(ser_no,exe_name,version,,)
＋----setup(clock,,)
＋----clock(hours,minutes,seconds)
＋----time_record(tune,flow_control)
＋----flow_control(play,stop,goto,record,,)
＋----play(time_params)
＋----record(time_params)
＋----tune(send_epg,channel,,)
＋----channel(number,id,time_params,,)
＋----time_params(now,start,duration,end,,)
＋----ui_control(display,acoustic)
＋----display(brightness,contrast,color/tint,horiz_size,vert_size,,)
＋----acoustic(volume,bass,treble,balance,fade,)
＋----lighting(screen,light、send_epg)
＋----sensors(living_room,sky,,)
＋----lights(rooms_up,rooms_down,yard,,)
＋----rooms_up(bed1,bed2,bed3,bed4,,)
＋----rooms_down(family,kitchen,living,dining,soho,garage,,)
＋----yard(front,back)
＋----bed1(lamp,dimmer,,)
＋----dimmer＜value＞
＋----comms(netman,intercom,telco,)
＋----netman(send_device_list,send_configuration,send_snmp_mib,,)
＋----intercom()
＋----telco()
＋----havc(controls_gen,controls_hvac,,)
＋----controls_hvac(a/c,heat,temp,humidity,)
＋----temp(low,high,hysteresis,,)
＋----utility(meters,energy_mgmt,,)
＋----meters(water,gas,electric,,)
＋----water＜value＞,gas＜value＞,electric＜value＞
＋----security(sensors,send_epg,alram,,)
＋----sensors(peripheral,motion,,)
＋----peripheral(rooms_up,rooms_down,,)
＋----motion(rooms_up,yard,,)
＋----appliances(microwave,range,over,fridge,freezer,coffee,toaster,washer,dryer,water-heater,,)
＋----microwave(send_epg,controls,,)
＋----fridge(temp,,)
＋----water_heater(temp)
＋----convenience(window,curtain_open,door/gate,pool/spa,bath,fountain,lift,,)
＋----curtain_open＜value＞
＋----server_auto(message,mileage,maintenance,,)
＋----mileage＜data＞
＋----maintenance＜data＞
【００９６】
他の観点で、本発明はネットワークでデバイス-デバイス命令及び制御のために存在する命令語具現の使用を提供する。デバイスは、内部対象及び存在する伝送メカニズムによって、実行時に２進数列を生成するAPIを含める。このような場合、ネットワークで一つのサーバデバイス１４からさらに他のサーバデバイス１４にXML遠隔手順呼び出し(XMLRPC: XML Remote Procedure Calls)を提供するために、存在するアプリケーションインタフェース具現はXMLサービスAPIに対する呼び出しに取り替えられる。従って、本来の具現はXMLサービスAPIのためのラッパ(Wrapper)と同等である。図１８は、またXCE/XMLサービスAPIでラッパに取り替えられたインタフェース具現として、点線内のCALまたはAV/Cのような他の命令語を使用して生成されたアプリケーションを示す。CAL命令語からXMLRPCフォーマットを変える例が下に示されている。
----------------------------------------------------------------------
existing implementation:
void DeviceCALCommand(int command){
・
・
/*
create CAL formatted byte string to represent this
object/method and output to the wire
*/
CreateCALFormattedByteString(command);/* different for
every protocol */
SendCALByteString(); /* different for every protocol */
}
----------------------------------------------------------------------
wrapping the XML Service API call:
void DeviceCALCommand(int command){
{
/*
replace CAL implementation with calls to the XML ServiceAPI
*/
CreateXMLMessage(command); /* always the same */
sendXMLMessage(); /* always the same */
}
【００９７】
さらに他の観点で、図２３を参照すれば、本発明はネットワーク内の他のデバイス間のデバイス間通信のための標準命令プロトコル及び制御言語翻訳を提供する。情報を共有する他のデバイスのために、前記情報は要請デバイスが解釈できるフォーマットであるべきだ。そして、一つのデバイス１２０が他のデバイス２２を制御するために、前記二つのデバイスはお互いの命令を解釈するために共通の言語を使用すべきだ。本発明はデータのための共通識別フォーマット及び命令プロトコルを提供する。
【００９８】
一実施形態で、共通表示またはデータ及び命令プロトコルパッケージする方法が提供され、それにより受信デバイス１２２は伝送されたデータの本来のフォーマットを決定できる。もし受信デバイスが本来のフォーマットを解釈できるならば、その時にデータを直接受信できる。そうでなければ、受信デバイス１２２は翻訳デバイス１２４または要請デバイス１２２が解釈できる望ましいフォーマットにデータを変形するアプリケーションを求められる。前記翻訳デバイス１２４またはアプリケーションは元のデータの本来のフォーマットを決定し、前記データを前記求められるフォーマットで翻訳し、要請デバイス１２２に翻訳したデータを送信する。
【００９９】
次に、前記要請デバイス１２２は、まるで前記データが元々送信デバイス１２０により要請デバイスの本来の言語フォーマットで提供されたようにデータを処理する。前記要請デバイス１２２は、また要請デバイスの本来のフォーマットで送信デバイス１２０に返信を送ったり翻訳デバイス１２４または送信デバイス１２０の本来のフォーマットで翻訳するアプリケーションを通じてプロッキシにより応答を伝送できる。前記翻訳方法は、命令プロトコル、データファイル及びオーディオ/ビデオストリームを含む情報のために使われる。
【０１００】
前述された共通フォーマットを使用しないデバイスのために、本発明は固い(Non-compliant)デバイスへ/からの命令プロトコルを含むデータの翻訳を提供する。例えば、固いデバイス１２０が柔軟なデバイス１２２にデータを送信する時、前記柔軟なデバイス１２２は前記データの本来のフォーマットの決定に基づいてデータを翻訳できる。例えば、前記柔軟なデバイス１２２はデータ内部の特定のビットパターンのためのデータを調査できる。柔軟なデバイスが既知の固いデバイスにデータを伝送する時、前記柔軟なデバイスは固いデバイスの本来のフォーマットの決定に基づいて伝送する前に前記データを翻訳できる。
【０１０１】
例示的な具現はIP及びHTTPプロトコルを支援するホームネットワークのためのことでありうる。前記ホームネットワークは望ましい機能のためのアプリケーション及び多様なタイプのサービスを得るためにインターネットに接続されたりする。従って、共通フォーマット方法は、インターネット及びホームネットワーク上の動作に対するインターネットプロトコル及び手順と互換性を有するように作られる。
【０１０２】
共通データフォーマットを提供する一例は、ホームネットワークを通じて伝送のためのデータパッケージを生成するXMLを使用している。前記データは命令プロトコル、オーディオまたはビデオストリーム、グラフィックまたはアプリケーションを含む。前記データはXML形態でデータの本来のフォーマット及びパッケージの項目を確認する標準ヘッダでラッピングされる。前記ヘッダは唯一にデータタイプとXMLコードのデータ部分を確認するようにし、それによって前記データは必要に応じて翻訳され、受信後に適当なアプリケーションに提供される。
【０１０３】
ウェブ標準下で、前記確認作業はファイル伝送のタイプ及び項目を確認するためにファイル名拡張を使用するブラウザーにより行われる。次に、ブラウザーはそのファイルを処理する適当なプラグ-のモジュールを移す。ホームネットワークでXMLは、前述された共通確認方法でIP上の全てのホームネットワーク伝送を提供するデータ伝送を確認するために使われる。
【０１０４】
一方、ホームネットワークを通した全てのデータ伝送の項目を唯一に確認するソフトウェア階層がホームネットワークプロトコルスタックで提供される。前記ソフトウェア層はXMLの代りに使われる。本発明の共通フォーマット及び確認原理は、XMLを使用する実施形態または確認方法としての前記ソフトウェア階層に同一に適用される。
【０１０５】
図２３でデータパッケージ伝送を受信すれば、受信デバイス１２２はその中のデータのフォーマットを決定するデータパッケージのXML確認ヘッダを調べる。もし前記データがデバイス１２２により認識できるフォーマットであれば、XML確認ヘッダ情報は捨てられ、前記デバイスはデータを直接処理する。そうでなければ、前記デバイス１２２は受信されたXMLパッケージをXML翻訳要請パッケージに変換し、翻訳サーバデバイス１２４に要請パッケージ及び前記データを送信する。
【０１０６】
前記翻訳サーバデバイス１２４は前記データを翻訳し、前記翻訳したデータをXML翻訳応答パッケージに変換する。次に、前記翻訳サーバ１２４は要請デバイス１２２に応答パッケージを回送する。翻訳エラーの場合に、前記翻訳サーバ１２４は要請デバイス１２２に翻訳応答エラー状態を提供できる。翻訳されたデータを受信すれば、前記要請デバイス１２２は翻訳されたデータを応答パッケージで処理する。
【０１０７】
XMLデータパッケージまたはパケットの例は次の通りである:
＜IDENTITY type＝format＝AV/c＞...packet data...＜/IDENTITY＞
翻訳要請パッケージまたはパケットの例は次の通りである:
＜TRANSLATION REQUEST type＝Command format＝CAL＞
＜IDENTITY type＝Command format＝AV/C＞...packet data
＜/IDENTITY＞
＜/TRANSLATION REQUEST＞
翻訳要請パッケージまたはパケット例は次の通りである:
＜TRANSLATION RESPONSE type＝Command format＝CAL＞...packet data
＜/TRANSLATION RESPONSE＞
伝送応答エラー状態パッケージまたはパケットの例は次の通りである:
＜TRANSLATION RESPONSE type＝Command format＝CAL＞...packet data...
＜ERROR condition＝Unrecognized command＞Translation could not be performed＜/ERROR＞
＜/TRANSLATION RESPONXE＞
【０１０８】
さらに、図２４でテーブル３は、パッケージまたはパケットタイプ及びフォーマットの部分的なリストを含む。翻訳サービスを提供するために、翻訳サーバ１２４はDHCPサーバの方法と類似な方法でネットワーク構成の間にネットワークで確認される。前記翻訳サーバ１２４は、ネットワークが構成された後一定期間ネットワーク内の全てのデバイスにそのIPアドレスを放送する。翻訳サービスと互換できる全てのデバイス１２０、１２２は、ネットワークをブーティングする間にネットワークを通じて放送する翻訳サーバ１２４のIPアドレスを貯蔵する。
【０１０９】
一方、要請デバイス１２２はホームネットワークを通じて翻訳要請を放送できる。ネットワークで翻訳要請を受信する全ての翻訳サーバ１２４は要請デバイス１２２に翻訳応答を送信することによって翻訳要請に応答できる。次に、要請デバイス１２２は応答翻訳サーバ中で一つの翻訳サーバ１２４を選択する。一例として、要請デバイス１２２は翻訳要請に応答する最初の翻訳サーバ１２４を選択する。また他の例で翻訳サーバ１２４は、翻訳要請を満たす翻訳サーバ１２４の選択のためにかれら自体間でそして/または要請デバイス１２２と交渉できる。
【０１１０】
本発明のさらに他の実施形態で、多重の翻訳サーバ１２４が全ての翻訳要請を行うために使われる。例えば、単一の翻訳サーバ１２４が全ての要請を翻訳する性能を有しない場合もありうる。この場合、各翻訳サーバのアドレス及び各翻訳サーバが提供できる翻訳サービスのタイプを確認する必要がある。各デバイス１２０、１２２は、全ての翻訳サーバIPアドレスリストと各翻訳サーバ１２４が提供する翻訳サービスタイプに相応するリスト、そして選択的に関連された翻訳アプリケーションを貯蔵できる。
【０１１１】
効率のために、もし送信デバイス１２０が送信デバイス１２０フォーマットと違う本来フォーマットを使用することと知られた受信デバイス１２２にデータを伝送することを希望するならば、前記送信デバイス１２０は翻訳サーバ１２４を通じたプロッキシにより受信デバイス１２２にデータを伝送できる。前記送信デバイス１２０は、翻訳サーバ１２４に伝送要請命令と類似に翻訳サーバ１２４に命令を伝送し、翻訳されたデータに対する目的地として受信デバイス１２２のアドレスを含む。
【０１１２】
受信デバイス１２２がデータストリームの翻訳を要求する場合には、送信デバイス１２０は直接翻訳サーバ１２４にデータストリームをルーチングでき、前記翻訳サーバ１２４は前述されたように受信デバイス１２２に翻訳されたデータを順次に伝送する。他の一方では、前記送信デバイス１２０は前記受信デバイス１２２にデータストリームを伝送でき、次に受信デバイス１２２は翻訳及び前記受信デバイス１２２に翻訳されたデータを回送するために翻訳サーバ１２４にデータストリームをルーチングする。
【０１１３】
説明中で、制御メカニズムは分配され、協調的なハイパーメディア情報システムのためのアプリケーション-レベルプロトコルを提供するHTTP１.１に基づく。HTTPは多くのタスクのための幅広い使用で一般的で無状態(stateless)で対象向きのプロトコルである。HTTPの特徴は、伝送されたデータと独立的にシステムが構成されるようにするデータ表現の分類及び交渉である。望ましくは、ホームネットワーク上でデバイス及びアプリケーションにより使われたネットワークプロトコルはIP(Internet Protocol)である。しかし他のプロトコルも使われる。
【０１１４】
本発明は望ましい実施の形態で詳細に説明されたが、他の変形も可能である。従って、特許請求の範囲は本発明の望ましい実施の形態により限定されてはいけない。
【図面の簡単な説明】
【０１１５】
【図１】本発明の第１観点に係るネットワークの具現のためのブロック図である。
【図２】デバイス制御及び通信概要の第１実施形態に係る図１のブロック図である。
【図３】多数のクライアントとサーバデバイスを含む本発明に係るホームネットワークシステムに対する第１実施形態を示すブロック図である。
【図４】図３のクライアントデバイス及びサーバデバイス具現の第１実施形態を示すブロック図である。
【図５】クライアントデバイス具現の第１実施形態を示す図面である。
【図６】サーバデバイス具現の第１実施形態を示す図面である。
【図７】相互間に通信及び制御を可能にするネットワークサーバデバイスの第２実施形態を示すブロック図である。
【図８】ネットワークで送信側のサーバデバイス、受信側のサーバデバイス及びクライアントデバイスを含むオーディオ/ビデオモデルの構造に対する第１実施形態を示すブロック図である。
【図９】オーディオ/ビデオモデルの他の実施形態を示す図面である。
【図１０】ネットワークデバイスのための性能データテーブルの実施形態を示す図面である。
【図１１】ネットワークデバイスのための特性データテーブルの実施形態を示す図面である。
【図１２】ネットワークデバイス間で命令メッセージを発生させるビルディングブロックに対する第１実施形態の構成を示す図面である。
【図１３】命令メッセージを発生させる図１２に係るビルディングブロックの他の実施形態の構成を示す図面である。
【図１４】ネットワーククライアント及びサーバデバイス間で相互作用の第３実施形態を示す図面である。
【図１５】ネットワークデバイスインタフェースのAPI拡張を定義する第１実施形態のブロック図である。
【図１６】他のサーバデバイスのインタフェース説明文書をアクセスするサーバデバイスアプリケーションのための第１実施形態の構造を示す図面である。
【図１７】制御器サーバデバイスと制御されたサーバデバイスとの間の内部-デバイス制御構造の他の実施形態を示す図面である。
【図１８】ネットワークデバイス間のAPIレベルで通信スタックでウェブ標準共通ミドルウェア階層を提供するXMLプロトコルの具現を示す図面である。
【図１９】サーバデバイス間命令制御構造のまた他の具現を示す図面である。
【図２０】デバイスインタフェースライブラリーとホームデバイスのための電化製品データベースとの関係を示す図面である。
【図２１】デバイスインタフェース定義に対する階層的形態の具現を示す図面である。
【図２２】図２１のデバイスインタフェース定義で階層の第１実施形態を示す図面である。
【図２３】伝送器及び受信器デバイス間で共通伝送及び解釈手順を示す図面である。
【図２４】本発明の第１観点に係る翻訳サービスを提供するためのパケットタイプとフォーマットの部分的なリストテーブルの第１実施形態を示す図面である。
【符号の説明】
【０１１６】
１２  クライアントデバイス
１４  サーバデバイス
１６  通信リンク
【図１】
2008269655.tif 000003
【図２】
2008269655.tif 000004
【図３】
2008269655.tif 000005
【図４】
2008269655.tif 000006
【図５】
2008269655.tif 000007
【図６】
2008269655.tif 000008
【図７】
2008269655.tif 000009
【図８】
2008269655.tif 000010
【図９】
2008269655.tif 000011
【図１０】
2008269655.tif 000012
【図１１】
2008269655.tif 000013
【図１２】
2008269655.tif 000014
【図１３】
2008269655.tif 000015
【図１４】
2008269655.tif 000016
【図１５】
2008269655.tif 000017
【図１６】
2008269655.tif 000018
【図１７】
2008269655.tif 000019
【図１８】
2008269655.tif 000020
【図１９】
2008269655.tif 000021
【図２０】
2008269655.tif 000022
【図２１】
2008269655.tif 000023
【図２２】
2008269655.tif 000024
【図２３】
2008269655.tif 000025
【図２４】
2008269655.tif 000026