JP4201897B2 - 信号送信装置、信号受信装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明は、デジタルテレビジョン放送、ネットワーク、ＣＡＴＶシステムなどに有用であって、映像、音声に更にデータを多重して伝送する信号送信装置、信号受信装置に関するものである。
【０００２】
【従来の技術】
近年、半導体技術、通信技術の発達により、より高度な機能をもつテレビジョン（ＴＶ）受像機の開発が行われている。特に従来のＴＶ受像機が単に映像、音声信号を視聴し楽しむという受動的なものであったのに対し、デジタル技術を利用し、映像、音声信号以外にデジタルデータを多重し、映像、音声以外の情報を付加したり、視聴しているＴＶ番組に対してレスポンスをするような高機能のテレビ受像機が望まれ始めている。このような機能を実現するＴＶとして、International Application Published under the patent cooperation treaty （PCT ） International Patent Classification : H04N 1/00, International Publication Number: O 96/34466に記載されているCompact Graphical Interactive Broadcast Information System（文献１）がある。本文献にはＴＶ番組に通常の映像信号だけでなく、新たなデータを多重し、双方向機能を実現する手法が述べられている。
【０００３】
これにより、インターラクティブコンテンツを映像、音声信号と多重して伝送することにより通常のＴＶ放送ではできないインターラクティブ機能を実現している。
【０００４】
一方、双方向機能を実現する方法として、ISO/IEC 13522-5 （文献２）に記載されているＭＨＥＧ−５と呼ばれるものがある。ＭＨＥＧ−５では、文献１と同様にアプリケーションとしてシーンと呼ばれるページに相当するものが定義されており、様々なアプリケーションをオブジェクトにより構成することが可能である。また、オブジェクトはデータコンテンツと呼ばれる文献１のリソースに対応するものを同様に使用することでアプリケーションを構成することができる。ただし、文献２による双方向システムでは詳細なスクリプトの定義はなく、イベントの発生に伴うオブジェクトの動作を記述することでアプリケーションのシナリオを作成している。
【０００５】
以上の様に、文献１に記載されている双方向システムと文献２に記載されている双方向システムとはアプリケーションを構成する際にオブジェクトと呼ばれる構成要素を使用することで非常によく似ている。しかし、実際のアプリケーションを作成する際に使用できるオブジェクトの種類が異なるためそれぞれのアプリケーションに互換がない。また、最終的に伝送する際には双方とも最終形態としてバイナリーレベルで伝送されるため、伝送フォーマットについても互換性が無い。
【０００６】
以上２つの文献に記載された双方向システムについて述べたが、さらには第３、第４の双方向システムも開発されることが予想される。このような状況下においてはそれぞれ個別のシステムとなり、別々のエンコーダが必要となる。
【０００７】
【発明が解決しようとする課題】
以上のように、近年多くの双方向のテレビジョン方式が提案されているが、それぞれのシステムでは、アプリケーションに互換性がなく、それぞれ固有のエンコーダ、デコーダが必要となる問題が生じている。また、これらのフォーマットを強制的に統一してしまうと、自由なオブジェクトの定義あるいはシステムの開発に制約となる。
【０００８】
また近年では、テレビジョン受像機をディスプレイとして使用し、これに家庭内の各種機器（ＶＴＲ，ＤＶＤなど）が複数接続されて使用される。この場合、それぞれの機器がリモコンを有し、その操作が煩雑となっている。
【０００９】
そこでこの発明は、上記課題を解決する双方向機能を有する信号伝送受信装置を提供するものであり、従来の方式に対して大幅な変更、追加を行わずに、それぞれ固有に開発された双方向システムに対し相互に互換性を確保することが可能な装置を提供することを目的とする。
【００１０】
またこの発明は、ネットワークに接続された種々の外部機器についてのガイド（アイコン、制御パネル）を見ることが出来、このガイド表示を通じて遠隔操作および制御を行うことができる信号送信装置、信号受信装置、記録媒体を提供することを目的とする。
【００１１】
【課題を解決するための手段】
この発明は、複数の異なるシステムの各アプリケーションを作成する上で最低限必要となるデータであって各システムに共通な共通データと、異なるシステムの各アプリケーションを前記共通データと共に完成する上で必要となるデータであって、前記共通データを除く各システムの個別の個別データとを分離して伝送する。
【００１２】
各システムの受信装置では、上記分離されて伝送されて来た共通データと、少なくとも自身の個別データを用いて自身に必要なアプリケーションを完成、または他のシステムの個別データを変換して自身に必要なアプリケーションを完成させるように構成される。
【００１３】
このような信号伝送受信方法では、送信側では各システムに互換性のあるアプリケーションを伝送することができる。また受信装置では、各システムの持つコンテンツを相互に利用可能とし、送信受信で閉じていたサービスを拡大することが容易となる。当然、従来例で供給されるアプリケーションについても問題なく動作することができる。それぞれの独自に開発したアプリケーションに対し、他のシステムの持つ機能を利用することも可能となるため、現状のシステムの機能を向上させることもできる。また、強制的にオブジェクトの種類、システム等について強制的な制約を与えることがないため、自在に新たなシステムを開発することができ技術的な進歩を阻害することがない。
【００１４】
またこの発明の方式では、上記の基本的な共通データと、前記異なる方式が各々個別に用いる個別データとに分解して送信する信号送信装置からの信号の他にさらに、自身を操作するために用いるデータを含み、前記インターラクティブ機能を有する異なる方式に変換可能なフォーマットに従ったデータを送信する機能を有する１つ以上の装置からの信号を受信する受信手段を有し、
前記共通データ、前記個別データ、前記変換可能なフォーマットに従ったデータのいずれか１つあるいは、これら受信したデータのうち１つ以上のデータの合成データを用いてアプリケーションを実行する実行手段を有するものである。これにより本体側からアプリケーションを通じて、本体に接続されている機器を操作あるいは集約的に１個所で制御することが可能となる。
【００１５】
【発明の実施の形態】
以下、この発明の実施の形態を図面を参照して説明する。
【００１６】
図１は、この発明に係る第１の実施の基本形態を示す。インターラクティブコンテンツエンコーダ１０１は、作成されたインターラクティブコンテンツをエンコードし、分析器１０２へ出力する。分析器１０２は、入力されたインターラクティブコンテンツを分解し、共通データと個別データとを出力する。
【００１７】
なお、個別データとしては、その呼び名はこれに限るものではなく拡張データ、付加データ、差分データ、補助データなど各種の呼び名が可能である。また共通データについても、主データ、親データ、基幹データなど各種の呼び名が可能である。
【００１８】
共通データおよび個別データはそれぞれ合成器１０３に入力され合成される。合成されたデータはインタラクティブエンジン１０４に入力され、エンジンによりアプリケーションが実行される。
【００１９】
共通データは、例えば下記の要素から構成される。
［１］共通オブジェクト
［２］共通データコンテンツ
個別データは、例えば下記の要素から構成される。
［１］継承差分成分
［２］スクリプト
これらそれぞれの詳細については後述する。
【００２０】
図２には、この発明による第１の実施例を実際の送受信システムに適用した構成を示す。オーディオビデオ（ＡＶ）エンコーダ２０１は、映像・音声信号をエンコードしデジタル信号列に変換する。一方、インタラクティブコンテンツエンコーダ２０２は、インタラクティブコンテンツをエンコードし、分析器２０３へ入力する。分析器２０３は、インタラクティブコンテンツを共通データおよび個別データに分析分離し、フォーマットエンコーダ２０４へ出力する。フォーマットエンコーダ２０４では、共通データと個別データを多重し、多重器２０５へ出力する。多重器２０５は、ＡＶエンコーダの出力とフォーマットエンコーダ２０４の出力を多重し、その多重信号の伝送を行う。
【００２１】
共通データと個別データとを多重する方法としては各種の方法があるが、例えば各データをそれぞれパケット化し、各パケットに識別コードを付加し、各パケットを時間多重する方法が採用される。
【００２２】
受信側では、多重信号を受信し、分離器２０６により映像・音声とインタラクティブコンテンツ用のデータを分離する。
【００２３】
分離器２０６は映像・音声データをＡＶデコーダ２１０へ出力し、インタラクティブコンテンツ用のデータをフォーマットデコーダ２０７へ出力する。フォーマットデコーダ２０７は、入力データを共通データおよび個別データに分離し合成器２０８へそれぞれのデータを入力する。合成器２０８では、共通データと個別データとを合成し、インタラクティブエンジン２０９へデータを出力する。インタラクティブエンジン２０９では、入力されたデータよりアプリケーションを構築して、結果をＡＶデコーダ２１０へ出力する。ＡＶデコーダ２１０では、再生した映像、音声とアプリケーションを実行再生し、映像とグラフィック画像を表示する。
【００２４】
図３は、図１に示した分析器１０２および合成器１０３の詳細を示す。
【００２５】
分析器１０２は、コンテンツ分離器３０２、共通データフィルタ３０３、個別データフィルタ３０４、データ変換器３０５、３０６，３０７，３０８、多重器３０９，３１０より構成される。
【００２６】
コンテンツ分離部３０２は、入力部３０１より入力されるインタラクティブコンテンツをデータコンテンツ、オブジェクト、スクリプトに分解する。データコンテンツは、データ変換器３０５により所定のフォーマットに変換され共通データコンテンツとして多重器３０９へ入力される。同様にスクリプトはデータ変換器３０８により所定のフォーマットに変換され多重器３１０へ入力される。
【００２７】
オブジェクトは、共通データオブジェクトと、継承差分成分とに分離される。即ち、共通データフィルタ３０３は共通データオブジェクトとして定義されている成分を抽出し、個別データフィルタ３０４は共通オブジェクトとして定義されていない成分を継承差分成分として抽出する。共通データフィルタ３０３の出力（共通データオブジェクト）はデータ変換器３０６により所定のデータに変換され共通データコンテンツと共に多重器３０９により多重され出力部３１１より共通データとして出力される。一方、個別データフィルタ３０４の出力（継承差分成分）はデータ変換器３０７により所定のデータフォーマットに変換されスクリプトと共に多重器３１０において多重され、出力部３１２より個別データとして出力される。
【００２８】
合成器１０３は、分離器３２３、３２４、データ変換器３２６、３２７、３２８、３２９、オブジェクト合成器３３０、コンテンツ合成器３３１を有する。入力部３２１より入力される共通データは分離器３２３により共通データコンテンツと共通データオブジェクトに分離される。共通データコンテンツはデータ変換器３２６によりデータコンテンツに変換され、共通データオブジェクトも同様にデータ変換器３２７により所定のフォーマットに変換される。
【００２９】
一方、入力部３２２より入力される個別データは分離器３２４によりスクリプトと継承差分成分に分離される。継承差分成分はデータ変換器３２８により所定のフォーマットに変換され、スクリプトはデータ変換器３２９により所定のフォーマットに変換される。ここで、データ変換器３２７とデータ変換器３２８の出力はオブジェクト合成器３３０により合成され最終オブジェクトとなる。またデータ変換器３２６より出力されるデータコンテンツと、オブジェクト合成器３３０より出力される最終オブジェクトと、データ変換器３２９より出力されるスクリプトとは、再度コンテンツ合成器３３１により最終的なインタラクティブコンテンツとなるよう合成され、出力部３３２より出力される。
【００３０】
以上の様に、本発明における信号送受信装置では、オブジェクトを共通データオブジェクトと継承差分成分とに分割して伝送している。これらの構成について図４を用いて詳しく説明する。通常、オブジェクトを基本とするインタラクティブシステムでは、アプリケーション作成のための基本的なオブジェクトをもっている。本発明ではオブジェクト指向の技術を導入し、基本的なオブジェクトからそれぞれのシステムに固有なオブジェクトを生成する。オブジェクト指向の考え方では、オブジェクトは親となるオブジェクトの機能を継承し、子となるオブジェクトを生成する。いずれの双方向システムにおけるオブジェクトにおいても、基本的オブジェトの機能とその拡張として分解が可能である。文献１および文献２におけるオブジェクトについても例外ではない。
【００３１】
図４に示すように、インタラクティブアプリケーションのための最低限必要機能を持つオブジェクトをオブジェクトコアクラス４０１とすると、いずれのアプリケーションにおいても、アプリケーション全体を表す大局的な性質を持つグローバルクラス４０２、グラフィックとして表示されるビジブルクラス４０３、音等の見えないが再生されるインビジブルクラス４０４、内部的な動作をつかさどインターナルクラス４０５等の抽象的なクラスに分類できる。これら抽象的なクラスから継承してできる具象化クラスの例を４０６から４１４に示す。即ちアプリケーション、フォーム、ビットマップ、テキスト、図形、エントリーフィールド、サウンド、イベント、バイトコードである。これらはいずれのインタラクティブアプリケーションを作成するための最低限必要なオブジェクトの例である。この具象化クラスまでを共通データオブジェクトとし、異なるシステム特有のオブジェクトはこの共通データオブジェクトから継承することで生成することができる。継承差分成分は、共通データオブジェクトから各システムのオブジェクトを継承した時の差を示す成分である。
【００３２】
この実施の形態では、上記の共通データオブジェクトとして下記の９つを示している。
［１］アプリケーション：アプリケーション全体に必要な情報を持つ。
［２］フォーム：１枚のページを構成するための情報をもつ。
［３］ビットマップ：画像を表示する。
［４］テキスト：テキストを表示する。
［５］図形：矩形やラインを表示する。
［６］エントリーフィールド：文字を入力する
［７］サウンド：音を再生する。
［８］イベント：オブジェクトの動きを制御する。
［９］バイトコード：スクリプトおよびバイトコードに関する情報をもつ。
【００３３】
図５には、具体的なオブジェクトの構造例を示す。
【００３４】
オブジェクトコア４０１として、オブジェクトＩＤ５０１およびタイプ５０２が生成される。ビジブルクラスとして、座標情報５０３およびデータコンテンツへのコンテンツポインタ（あるいはＩＤ）５０４が生成され、ビットマップクラス４０８によりスクリプトへのスクリプトポインタ５０５が生成される。共通オブジェクトは以上の構成をとる。
【００３５】
以降は、システム特有の機能としての継承差分成分が配置される。例えばビットマップ１では、色や線に関する情報５０６が設定される。継承差分成分は、この色や線に関する情報５０６である。これら全体はオブジェクトとして定義されている。
【００３６】
コンテンツポインタ５０４で指示されている位置には、データ列がデータコンテンツであることを表すＩＤ５１１を先頭にエンコード情報５１２、データコンテンツ本体５１３が配列されている。またスクリプトポインタ５０５で指示されている位置には、例えばバイトコードであることを表すＩＤ５３１を先頭にエンコード情報５３２、バイトコード本体５３３が配列されている。
【００３７】
データコンテンツに関しては、代表的なものとして、画像があげられるが、これらは通常圧縮されて伝送される。したがって、送信側で圧縮処理が行われエンジン側で伸張が行われている。オブジェクトの場合と異なり、画像圧縮は標準化がなされており、ＪＰＥＧ、ＧＩＦ等のフォーマットで伝送されれる。したがって、データコンテンツに関しては、共通化が比較的容易にできるため、共通データコンテンツとして伝送が可能である。独自の圧縮方式等をとる場合は、共通データコンテンツと別に、個別データとして伝送することも可能である。この場合は、個別データコンテンツとしてスクリプトと多重して伝送される。
【００３８】
図６は、この発明による更に他の実施の形態である。
【００３９】
入力部６０１より入力されたインタラクティブコンテンツは分析器６０２において共通データ、個別データとに分解される。実際の伝送は、第２図に示すように、そのほかのデジタル信号と多重されて伝送される。
【００４０】
共通データは、合成器６０３を介して第１のエンジン６０４に供給される。また、共通データは、合成器６０５を介して第２のエンジン６０６にも供給され、合成器６０７を介して第３のエンジン６０８、合成器６０９を介して第４のエンジン６１０に供給される。
【００４１】
個別データは、第１の個別データとして合成器６０５に入力され、またデータ変換器６１１で変換され第２の個別データとなり合成器６０７に入力される。更にまた第１の個別データは合成器６１３に入力されると共に、データ変換器６１２で変換されて第２の個別データとなり、合成器６１３に入力されている。この結果、合成器６１３からは第１の個別データと第２の個別データを合成した第３の個別データが得られ、この第３の個別データは合成器６０９に入力される。
【００４２】
この実施例では、第１のエンジン６０４は、共通データだけを受信しデコードする。第２のエンジン６０６は、共通データと第１の個別データとを受信しデコードする。また第３のエンジン６０８は、共通データと第１の個別データから変換された第２の個別データとを受信しデコードする。更に第４のエンジン６１０は、第１の個別データを第２の個別データに変換し、この第２の個別データと第１の個別データを合わせることにより得られた第３の個別データと、共通データとを受信してデコードを行なう。
【００４３】
第１のエンジン６０４は、共通データだけを受信するため、機能は限られているが異なるシステムでエンコードされたインタラクティブコンテンツを受信しアプリケーションを実行することが可能である。第２のエンジン６０６は、本来のアプリケーションを再生することができる。第３のエンジン６０８は、本来異なるシステムのエンジンであるが、第１の個別データを第２の個別データへ変換して用いることにより異なるシステムのアプリケーションを実行することが可能となる。データ変換器６１１は、オブジェクトの継承差分成分のみを変更することで、実現が可能であるため、オブジェクト自体（オブジェクトの全体）を変更する変換器に比べて小規模に実現することができる。第４のエンジン６１０の系統についても同様なことが言える。
【００４４】
図７には更に別の実施の形態を示している。
【００４５】
各システムの装置が独立して構成される場合、システム１ではエンコーダ７０２と第２のエンジン７１８が対応関係にあり、システム２ではエンコーダ７０３と第３のエンジン７１９が対応関係にあり、システム３ではエンコーダ７０４と第４のエンジン７２０が対応関係にある。この実施の形態では、異なるシステム間で互換性を持たせた構成を得る。
【００４６】
オーサリングツール７０１により出力されたインタラクティブコンテンツは、エンコーダ７０２、７０３、７０４によりエンコードされる。それぞれのエンコードされたデータは、分析器７０５、７０６、７０７に入力され共通データと、第１、第２、第３の個別データに変換される。共通データはすべで同一であるため、分析器７０６，７０７からは第２、第３の個別データのみを導出する。多重器７０８は、共通データと第１乃至第３の個別データを多重し出力部７０９より出力する。
【００４７】
受信側では、入力部７１１より入力されたデータを分離器７１２により共通データと、第１の個別データと、第２の個別データと、第３の個別データに分離する。
【００４８】
共通データは、合成器７１３、７１４、７１５、７１６、７２３に共通に入力される。ここで、合成器７１３は、共通データのみによりインタラクティブコンテンツを生成し、アプリケーションを実行する第１のエンジン７１７に供給する。合成器７１４は、共通データと第１の個別データによりインタラクティブコンテンツを生成し、アプリケーションを実行する第２のエンジン７１８に供給する。合成器７１５は、共通データと第２の個別データによりインタラクティブコンテンツを生成し、アプリケーションを実行する第３のエンジン７１９に供給する。合成器７１６は、共通データと第３の個別データによりインタラクティブコンテンツを生成し、アプリケーションを実行する第４のエンジン７２０に供給する。
【００４９】
このように、異なるシステムに対応したエンジンにおいても、アプリケーションを実行することが可能となる。
【００５０】
ここで、さらに、合成器７２２により第２、第３の個別データを用いて第４の個別データを生成し、合成器７２３により第４の個別データと共通データを合成することで、新たな第５のエンジン７２４では、エンジン７１９およびエンジン７２０のアプリケーションの機能を兼ね備えたエンジンを構築することが可能となる。
【００５１】
本実施の形態では、個別データが３つに増えているため、より大きな伝送容量が必要に見えるが、通常のアプリケーションでは、画像データ等の共通データコンテンツがインタラクティブコンテンツのほとんどの部分を占めているため、個別データの増加は無視可能できるほど小さい。
【００５２】
図８に、上記した実施の形態で示すシステムのアプリケーション例を示す。第１のエンジン７１７のアプリケーションが実行された場合の画像状態を図８（ａ）に示し、第３のエンジン７１９のアプリケーションが実行された場合の画像状態を図８（ｂ）に示し、第５のエンジン７２４のアプリケーションが実行された場合の画像状態を図８（ｃ）に示している。
【００５３】
図９には、共通データ、第２のエンジン用の第２の個別データ、第３のエンジン用の第３の個別データの例を示している。第１のエンジン７１７は、共通データのみによりアプリケーションを実行する。共通データでは、基本的なパラメータのみが定義されている。第２の個別データにおける継承差分成分には、ボタンおよびビットマップの形状に楕円を指示する属性が含まれるため、第２のエンジン７１９により実行されるアプリケーションでは、図８（ｂ）に示すように、楕円の形状となる。さらに、第３の個別データでは、ビットマップオブジェクトに半透明の属性が含まれているため、第５のエンジン７２４では、第２、第３の個別データの両方の継承差分成分が利用可能となるため、楕円でかつ半透明のビットマップを生成することができる。
【００５４】
第１０図には、共通データと第２と第３の個別データを多重したデータ構造を示す。ヘッダ情報に続けて共通データ部の先頭にインジケータとして“エンジン１”が示されている。さらに、オブジェクト、データコンテンツが挿入されている。続けて、個別データ部分は、第２の個別データを示すインジケータとして“エンジン２”が示され、個別データとしての継承差分成分が挿入される。さらには、第３の個別データを示すインジケータ“エンジン３”がつづき継承差分成分が挿入されている。
【００５５】
図１１を参照しながら、上述のアプリケーション構成要素の伝送方法について説明する。
【００５６】
図１１は、この発明の一実施の形態におけるデータ伝送単位層構造説明の補助図である。図１１（ａ）のアプリケーション要素（application element ）は、１つのアプリケーションの全ての構成要素を含む伝送単位である。その構造は、アプリケーション全体に関係する情報を持つアプリケーション要素ヘッダ（application element header）１１０１と、各エンジン用のデータを含むコンテナ（container ）１１０２，１１０３，１１０４からなる。
【００５７】
第１のエンジン用のコンテナ１１０２は、各エンジンが共通に使うデータ、また、第２のエンジン用のコンテナ１１０３は、コンテナ１１０２に含まれない第２のエンジン専用のデータ、第３のエンジン用のコンテナ１１０４は、コンテナ１１０２に含まれない第３のエンジン専用のデータを伝送するものとなっている。各コンテナが、どのエンジン用のデータであるかは、コンテナヘッダ（container header）１１０５内のブロードキャストアプリケーションタイプ（Broadcast Application type：ＢＡＰタイプ）１１１０で識別する。ひとつのアプリケーション要素には任意の数のコンテナを持つことが出来る。各コンテナは、図１１（ｂ）で示すような共通の構造を持つ。その構造は、そのコンテナ全体に関係する情報を持つコンテナヘッダ１１０５、コンテナ定義付け部（container define record ）１１０６と、アプリケーション本体のデータを伝送するオブジェクト（objects ），コンテンツ（contents），スクリプト（script）の３種のレコードから構成される。
【００５８】
レコードは、上記３種のデータに分けて、その構成要素を書き並べた形態となっている。例えば、オブジェクトレコード（object record ）は図１１（ｃ）に示すように、レコードヘッダ（record header ）１１１１とアプリケーションを構成する全オブジェクトである、オブジェクト１，２，・・，ｎ，・・・，Ｎから構成される。コンテンツレコード（content record）およびスクリプトレコード（script record ）も同様に設定されるが、図１１ではオブジェクトレコードを代表して記載している。図９に示した第１のエンジン用のデータを送る場合であれば、オブジェクトは、シーン（Scene ）, イベント（Event ）, ビットマップ（１）（Bitmap（１）），ボタン（２）（Button（２）），ボタン（３）（Button（３））が構成要素となる。同様にコンテンツレコードでは、ビットマップ（１）（Bitmap（１）），テキスト（２）（Text（２）），テキスト（Text（３））が構成要素となり、スクリプトレコードでは、スクリプトＡ（２）（scriptＡ（２）），スクリプトＡ（３）（script Ａ（３））が構成要素となる。
【００５９】
レコードがどのデータ種別のものかは、レコードヘッダ１１１１中のレコードタイプ１１１６で識別する。もちろん、そのエンジン用に何れかの種類のデータを持たない場合、そのレコードは、伝送されない。例えば、図９で説明したの第３のエンジン用のデータでは、ビットマップオブジェクト（bitmap object ）のみ存在するので、第３のエンジン用のコンテナでは、オブジェクトレコードのみが存在する。オブジェクト，コンテンツ，スクリプトは各々識別情報（ＩＤ）１１１７，１１２０，１１２３とその種別を示す種別情報（ｔｙｐｅ）１１１８，１１２１，１１２４、実際のデータとしてのボディー（body）１１１９、１１２２、１１２５を持つ。ここで種別とは、図９の例をとるとすれば、オブジェクトレコード内ではシーン（Scene ），イベント（Event ），ビットマップ（Bitmap），ボタン（Button）であり、コンテンツレコード内では、ビットマップ（Bitmap），テキスト（Text）であり、スクリプトレコード内では、スクリプトＡ（script Ａ）である。
【００６０】
ＩＤは、コンテナとレコードの種別によりその意味が異なるので、その内容について図４、図１２を参照しながら以下に説明する。
【００６１】
ＩＤは、自身の識別番号を意味するものと、自身の継承元を示す番号である場合とに分ける事が出来る。図１２にコンテナとレコードの種別毎のＩＤの意味を示す。上述して来たとおり、この発明では、任意のエンジンは、各エンジン共通の共通データと、この共通データに無い自身に独自な個別データとを組み合わせて用いる。各々のデータは別のコンテナで伝送されるため、受信後にそれらを足しあわせることになるのでその関係が明示される必要があり、このためにＩＤが用いられる。
【００６２】
図４に示したように、個別エンジン用の個別データであるビットマップオブジェクト４１５，４１６は、共通データであるビットマップオブジェクト４０８と足し合わされる。この時、ビットマップオブジェクト４１５，４１６の持つＩＤは、自身の継承元である共通データのビットマップオブジェクト４０８のＩＤと同じ値を持ち、その継承関係を示している。
【００６３】
このため、図１２に示す通り、第１のエンジン用のコンテナ中のオブジェクトレコード内のオブジェクトは、自身を識別する番号としてＩＤを持ち、他のエンジン用の差分データを送るコンテナ中のオブジェクトレコード内のオブジェクトは、自身の継承元（所属）となる前記第１のエンジン用のオブジェクトのＩＤと同じ値のＩＤ値を持つ。また、これら継承関係を示すためのＩＤ値は全く同じ値を持つ他、例えばＩＤ値の一部（例えば、上位数ビット）で継承関係を示しても良い。
【００６４】
一方、コンテンツやスクリプトは足しあわせて使われることが無いので、全ての場合に自身を識別する番号としてそれぞれ異なるＩＤ値を持ち、オブジェクト内から、そのＩＤ値で参照される。
【００６５】
次に、図１３〜図１８を参照しながら、本発明のデータ伝送の一実施の形態について説明する。
【００６６】
図１３は、"ICAP Specification, Version 1.0, Document Revision 1.2", Apr. 1997 （文献３）に従って構成された第２のエンジン用のボタンオブジェクトの構成であり、図１４は、文献２に従って構成された第３のエンジン用のボタンオブジェクトの構成である。また、図１５はこれらのビットマップオブジェクトを本発明によるデータ伝送方式により構成したものである。
【００６７】
図１３の“object Type ”と図１４の“object-identifier ”は共にオブジェクトの識別子を表すので、図１５の共通要素“Object ID ”としている。同様にオブジェクトの表示位置を表す図１３の“position”, “extent”と、図１４の“x-length”, “y-length”, “x-position”, “y-position”は、図１５の共通要素“UpperLeft Position”と、“LowerRight Position ”とし、共にボタンデータへのポインタを示す図１３の“resource”と図１４の“content-data”は図１５の“Content Reference ”としている。これら以外の部分はそれぞれ図１５の個別データである差分要素２と差分要素３として構成される。ボタンを丸く表示することを示すフラグである“hints:HINT_ROUND_KEYCAP ”は差分要素２の中に挿入して構成される。
【００６８】
図１６は、第２のエンジン用のビットマップオブジェクトの構成であり、図１７は、第３のエンジン用のビットマップオブジェクトの構成である。また、図１８は、これらのビットマップオブジェクトを本発明によるデータ伝送方式により構成したものである。
【００６９】
図１６の“object Type ”と図１７の“object-identifier ”は共にオブジェクトの識別子を表すので、図１８の共通要素“Object ID ”としている。同様にオブジェクトの表示位置を表す図１６の“position”, “extent”と図１７の“x-length”, “y-length”, “x-position”, “y-position”は図１８の共通要素“UpperLeft Position”と“LowerRight Position ”としている。また、共にボタンデータへのポインタを示す図１６の“resource”と図１７の“content-data”は、図１８の“Content Reference ”としている。
【００７０】
これら以外の部分はそれぞれ図１８の差分要素２と差分要素３として構成される。ビットマップを半透明で表示することを指示するフラグである“transparency”は差分要素３として構成される。
【００７１】
さて、上記実施例における共通データの構成は、異なるシステムのすべてに共通なデータ概念（例えば「テキスト」や「ビットマップ」など）が存在することが前提となっているが、そのような場合だけでなく、異なるシステム間においては、あるシステムには存在するデータ概念が、他の一つ以上のシステムには存在しないという場合も考えられる。このような場合には共通データとして構成できるデータが存在しないためにそのままでは上記の手法は適用できないが、ボディーのない空の共通データを定義することによって、先に述べたこの発明のデータ構成法を維持しながら用いることが可能である。
【００７２】
空の共通データは、ボディーがなくＩＤのみを持つ共通データであり、これを用いるとシステム固有のデータはその全体が個別データとして構成される。個別データには、空の共通データのオブジェクトＩＤ（object ID ）が割り当てられ、空の共通データが継承元であることを示す。
【００７３】
例として、第２のエンジンだけに存在し、その他のエンジンには存在しない第２のエンジン固有のオブジェクトを上記手法によって構成する場合について図１９と図２０を用いて説明する。
【００７４】
ここではオブジェクトについて示しているが、コンテンツおよびスクリプトの場合も同様に構成できる。図１９においては、アプリケーション要素３００１（図１９（ｄ）））に含まれる第１のエンジン（共通データ）用のコンテナ３００２（図１９（ｅ））中のオブジェクトレコード３００３にはオブジェクトが並んでおり、このうちの一つオブジェクト３００４はオブジェクトタイプ（object type ）が"NULL （空）" であり、オブジェクトＩＤのＩＤ値＝２である空のオブジェクトが置かれている（図１９（ｆ）、（ｇ））。このオブジェクト３００４にはオブジェクトボディー（object body ）がない（データの中身が空である）。
【００７５】
一方、第２のエンジン固有のオブジェクトの実体は、その全体が、第２のエンジン用のコンテナ３００５（図１９（ｃ））中のオブジェクトレコード３００６にはオブジェクトが並んでいる。この並んでいるうちの一つのオブジェクト３００７はオブジェクトタイプが "第２のエンジン固有" であり、オブジェクトＩＤのＩＤ値＝２となっている（図１９（ａ）、図１９（ｂ））。このように第２のエンジン用のオブジェクトＩＤのＩＤ値は第１のエンジンのものと同じくＩＤ値＝２となっており、空オブジェクト３００４を継承することを示している。
【００７６】
図１９の例では、NULLオブジェクトを各種類のレコード（オブジェクトレコード, コンテンツレコード, スクリプトレコード）の中に置いたが、図２０に示すように、第１のエンジン用のコンテナ３０１１中（図２０（ｄ））のオブジェクトレコード，コンテンツレコード，スクリプトレコード以外に、空の共通オブジェクトだけを集めた第４の種類の空のレコード３０１２を定義し、ここに空の共通データを置く構成としてもよい（図２０（ｅ））。図２０の例では、継承先のオブジェクト（図２０（ａ）、（ｂ）、（ｃ））は、継承元のオブジェクト（図２０（ｇ））を継承するよう、ＩＤ値＝２なっている。
【００７７】
上記のように空のオブジェクトと個別オブジェクトから構成されたデータを第２のエンジンが受け取ると、第２のエンジンは、共通データ（第１のエンジン用のコンテナ）の中の空オブジェクトからオブジェクトＩＤのＩＤ値を取り出し、自身の個別データ（第１のエンジン用のコンテナ）から上記取り出したオブジェクトＩＤのＩＤ値を持つ個別オブジェクトを取り出し、合成する。この合成した結果、空オブジェクトのＩＤを持ち、実際には個別オブジェクトのみのボディーを持った第２のエンジン用のオブジェクトが構成される。第２のエンジン以外のエンジン、例えば第３のエンジンが上記データを受け取ったとしても、共通データの中から空オブジェクトを取り出すものの、自身の個別データ（第３のエンジン用のコンテナ）の中にはこの空オブジェクトが持つＩＤのＩＤ値に対応する個別オブジェクトがないため、この空オブジェクトは何も処理されない。
【００７８】
次に図２１を参照しながら空の共通データを用いる場合に使用する空の共通データの数を減らす方法を説明する。空の共通データは、オブジェクト, コンテンツ，スクリプトといったデータの種類を持っておらず（図２１（ａ））、合成された結果のデータの種類は合成される個別データ（図２１（ｂ））によって決まる。
【００７９】
もしこの空の共通データと関連付けられる個別データが、あるシステムの１つだけに固有であり、また、別の空の共通オブジェクトが、別のシステムの１つだけに固有な個別データに関連付けられている場合は、空の共通オブジェクトを２つ使用しなければならない。しかしこの発明では、これらの空の共通データを共有することができる。すなわち、図２１に示すように、第２のエンジンの中にある個別データ２と、第３のエンジンの中にある個別データ３の両者が、共に同じＩＤ値（例えば５）を持っている。第２のエンジンは空の共通データと個別データ２からＩＤ値が５のデータを生成し、第３のエンジンは空の共通データと個別データ３からＩＤ値が５のデータを生成する。ここで個別データ２は第２のエンジンのみに固有であり、個別データ３は第３のエンジンのみに固有であるため、衝突は生じない。このような手法によって共通データレコードに埋め込む空の共通オブジェクトの数を減らすことができ、すなわち共通データのデータＩＤの発行数を減らすことが可能になる。
【００８０】
以上、システムに固有のデータ概念を空の共通データを用いて構成する方法を示したが、空の共通データのＩＤのＩＤ値が必ず個別データのＩＤのＩＤ値として記されることから、空の共通データを省略する構成としてもよい。
【００８１】
空の共通データを省略すると、省略しない場合には空の共通データへの参照という意味を持っている個別データのＩＤが、その個別データそのものを識別するＩＤとしての意味に変わる。したがって個別データ中の他の通常のデータ単位すなわち継承元となる共通データを参照している補足データとセマンティックスが変化するが、シンタックスそのものは全く同様である。
【００８２】
上記した実施の形態では、共通データと個別データとを伝送装置により伝送し、受信側では共通データと、自身に必要な個別データとを用いて自身のアプリケーションを構築する送受信方式として説明した。しかしこの発明は、このような送受信方式に限定されるものではない。例えば、共通データと個別データが記録された光ディスク、あるいは磁気ディスクなどの記録媒体を構成してもよい。ユーザは、この記録媒体を再生装置で再生して、共通データと個別データとを用いて再生装置側で自身に必要なアプリケーションを構築するようにしてもよい。また別の実施の形態として、共通データと個別データが伝送されて来た場合、一旦このデータを全て記録媒体に格納してもよい。そしてこの記録媒体に格納されている共通データと個別データとを用いて自身に必要なアプリケーションを構築するようにしてもよい。このようにすると、実際にアプリケーションを利用する時間帯と、共通データおよび個別データが伝送されてくる時間帯とが異なってもよい。
【００８３】
上記した実施の形態は、放送センター側から共通データと個別データが伝送されれてくることを主体にして説明したが、これに限るものではない。たとえば、家庭内に設置されている他の機器からも受信側には、データが伝送されきても本発明は適用できるものである。たとえば家庭内の他の機器としては、ビデオテープレコーダ、デジタルビデオディスク再生装置、ディスク再生装置、パーソナルコンピュータ、エアーコンディショナー、冷蔵庫、他のテレビジョン受信機等があり、これら機器からのデータもネットワークを通じて伝送される。
【００８４】
図２２を参照しながら、実施の形態を説明する。ただしネットワークのトポロジに関してはこの限りではない。
【００８５】
図２２において、送信装置８００では、オーサリングツール（Authering Tool）８０１で制作されたアプリケーションは、分離器８０２でアプリケーションの実行方式に依らず共通に用いる共通データと、実行方式により使用の可否が分かれる個別データに分離される。この後、共通データは、変換器８０３で前記実行方式に依らず所定のフォーマットに変換され、個別データと共に多重器８０４に入力されて１つのデータとされる。このデータは、図示しない画像や音声のデータと更に多重され、これも図示しない所定の送信の為の処理を施された後、送信端子８０５から送信される。送信されたデータは、電波による放送などの伝達手段を介して、受信装置９００で受信される。受信装置９００は、グラフィカル・ユーザ・インターフェイスを構築するのに必要な表示画面９０８を常に所有しなければならない。
【００８６】
受信装置９００の入力端子９０１から取り込まれたデータは、図示しない受信後の所定の処理を施された後、これも図示しないが、画像、音声のデータと分離された後、分離器９０２に導かれ、共通データと個別データに分離される。分離された共通データは、変換器９０３で実行方式に準じたフォーマットに変換された後、個別データと共に合成器９０４に入力される。
【００８７】
一方、ネットワーク装置９５１（例えばＶＴＲ）、９５２（例えばＤＶＤ）および９５３（例えば第２ＶＴＲ）は、自身の制御パネルを模したグラフィックスや動作を実現するスクリプト等のオブジェクトを、例えばＩＥＥＥ１３９４の様なネットワーク９６０を介し、受信装置９００の入出力端子９２０に供給する。
【００８８】
受信装置９００では入出力端子９２０からの入力をインターフェース（Ｉ／Ｆ）９０５へ導き、エンジン９０６に直接与えることができると判断されるデータ（共通データに相当）は直接エンジン９０６へ導き、そうでないデータ（個別データに相当）は、変換器９０７で実行方式に則したフォーマットへ変換した後、合成器９０４で前記２つの入力と合わせて合成し、そのデータをエンジン９０６に与える。ここで、実行方式と呼んでいるのは、すなわちエンジンの構成を決めている方式（エンジンが正しく処理可能な方式）のことである。
【００８９】
エンジン９０６では、合成器９０４およびインターフェース９０５の出力であるアプリケーションデータを実行し、送信装置８００からのアプリケーションをネットワーク装置９５１，９５２、…からのオブジェクトを交えて表示器の表示画面９０８に表示する。
【００９０】
ここで図示しないリモートコントローラなどの外部入力装置により、該オブジェクトが選択されると、前記スクリプトがバーチャルマシン（ＶＭ）９０９で実行され、この結果が、エンジン９０６、Ｉ／Ｆ９０５、入出力端子９２０を介してネットワーク上の該スクリプトを受信すべきネットワーク装置へ伝達され、該装置が所定の動作を行う。
【００９１】
図２３を参照しながら、さらに上記アプリケーションの具体的な動作例を説明する。
【００９２】
図２３は、例えば受信装置の電源をオンしたときにアプリケーションが表示画面９０８に表示された例を示している。この実施例では、放送番組マテリアルと、ネットワーク装置が再生可能なマテリアルからユーザが希望のマテリアルを選択するアプリケーションを例に説明する。アプリケーションを表示画面９０８上に表示したときの基本的な画面レイアウトなどは、送信装置８００から受信したデータによって決められている。しかしこれによらずユーザが任意に設定できるようになっていても良い。表示画面９０８の左側にはテレビ放送選択窓２１００、右側にはネットワーク機器選択窓２２００が用意される。
【００９３】
テレビ放送選択窓２１００の中には、放送を受信している各チャンネル（番組）の画像内容が、画面２１０１，２１０２，２１０３，２１０４のように表示される。また、ボタン２１０５，２１０６も表示される。このボタン２１０５，２１０６はスクロールボタンであり、他のチャンネルの画面を窓内に表示させる時に選択されるものである。各画面２１０１〜２１０４も画像表示機能と共にボタン機能を持ち、ユーザーが例えば画面２１０２を選択すれば、図に示すように画面の枠が強調される。また、図示しないが、表示画面９０８全体に画面２１０２（チャンネル３）の画像を表示するなどの機能を持つ。このような操作は、例えばリモートコントロール装置のシフトキーを操作すると、画面枠の強調部が次々と他の画面枠に移動し、希望のチャンネルの画面の枠が濃くなったときに決定キーを操作する。すると選択した画面のチャンネルが表示画面９０８の画面一杯に表示される。
【００９４】
一方、ネットワーク機器選択窓２２００の中にも画面２２０１、画面２２０２が表示されている。この画面はネットワーク装置９５１，９５２が接続され電源オン状態で、かつ再生状態にあり、再生映像信号がネットワークを介して送られているとき、この再生されている映像を表示する。
【００９５】
ネットワーク装置９５１，９５２が接続され、かつ電源オン状態で待機状態にあるときは、ネットワーク装置をエンジン９０６が認識し、表示画面には例えば点線で画面枠、ボタン等による操作するための画像を表示する。
【００９６】
また、画面２２０１が画像表示状態にないとき、すなわち対応するネットワーク装置９５１が再生状態にない時は、対応するボタン２２１１を選択し、次にその内部の再生マークを選択し決定することで、再生を命令し画面２２０１に画像を表示させることができる。ここで、ネットワーク機器選択窓２２００上の画面２２０１、２２０２、また、ボタン２２１１，２２１２の表示位置は、前述の通り、送信装置８００から受信したデータまたは後述する表示位置調整方法等によって決められているが、画面に表示される画像データ、ボタン２２１１，２２１２の機能、形状データ、などは、対応するネットワーク装置から、ネットワークを介して得たオブジェクトを使うことも可能である。もちろんこの場合は、ネットワーク装置にあらかじめ自分の操作用のオブジェクト（操作するための画像を作成するためのビットマップや、操作するための制御コマンド）をデータとして保持させておき、電源がオンされ、かつネットワークに接続されたときは供給できるように設計される。このとき、受信装置９００からのコールは有っても無くてもどちらでも良いように設計されている。
【００９７】
また、電源がオンされていなくても、ネットワークにネットワーク装置９５１が接続されたときは、受信装置９００はネットワーク装置９５１からネットワークを介してオブジェクトを持ってきて使用することが出来るようになっていても良い。
【００９８】
図２４に各ネットワーク装置と、受信装置９００との関係を示している。
【００９９】
オブジェクトはその所有されている装置の一般的な、また固有の制御情報（機器を制御するための情報）とかつそれらを扱うためのＧＵＩ情報から構成される。受信装置９００が立ち上がっている状態で、ネットワーク装置９５１が立ち上がるとネットワーク装置９５１はあらかじめその内部のオブジェクト記憶部９６２に所有しているオブジェクトを外部インタフェース９６１を通して、例えばＩＥＥＥ１３９４等のネットワークを経由し、受信装置９００のエンジン９０６に送出する。同様にネットワーク装置９５２その内部のオブジェクト記憶部９７２にオブジェクトを所有し、外部インタフェース９７１、ネットワークを通しエンジン９０６に送出する。
【０１００】
どちらの場合もエンジン９０６では、認識した各装置のオブジェクトをデコードしてアプリケーションを実行し、必要によりＧＵＩ情報を基に作成したアイコンや操作するための画像を表示画面９０８に表示する。また、逆に既にネットワーク装置９５１が立ち上がっており、後で装置９５２が立ち上がった場合も、ネットワーク装置９５１、９５２からオブジェクトを受けとり、先ほどの場合と同様に、オブジェクトをデコードしアプリケーションを実行する。
【０１０１】
このエンジン９０６は先に述べた通り、伝送されてきた共通データと個別データとを全て図示しない記録媒体に記録する。そしてこの記録媒体に記録されているデータを用いて自身に必要なアプリケーションを構築しても良い。このようにすると、実際にアプリケーションを利用する時間帯と、共通データおよび個別データが伝送されてくる時間帯とが異なっても良いし、各装置が立ち上がる度に毎回同じオブジェクトを送ってもらわずに済む。
【０１０２】
また、電波放送などで送信されたデータは、分離器９０２で共通データと個別データとに分離され、先の実施形態で説明したように、変換器９０３、９０７および合成器９０４から構成される変換合成部に渡されオブジェクトの変換合成が行われた後、このデータ・オブジェクトがエンジン９０６に渡される。このデータ・オブジェクトはエンジン９０６内で前述のオブジェクトと互換性のある形式に変換され、前述のオブジェクトと同様に扱われる。
【０１０３】
図２５には、エンジン９０６の内部において、オブジェクトのＧＵＩ配置を調整する機能を取り出して示している。ネットワーク装置から送られたオブジェクトは、オブジェクト検出器４０１０に渡され、オブジェクト検出器４０１０は入力を受けて、該当するネットワーク装置が立ち上がったことを画面に表示するため、該当するネットワーク装置のアイコンや操作するための画像であるグラフィックスを作成し、オブジェクト配置情報検出器４０１３およびオブジェクト配置調整器４０１４に送出する。
【０１０４】
また、オブジェクトは合成器４０１１にも送られ、電波放送等で送信されたオブジェクトと合成される。この例では電波放送によりオブジェクトが送信され合成されるが、電波放送により送信されるオブジェクトは必ずしも必要ではなく、ネットワーク装置からのみオブジェクトが送られてくるだけであっても特に問題は無い。合成器４０１１は、合成したオブジェクトをエンジンコア４０１２に送出し、ここで、オブジェクトを適切に処理し、ＧＵＩをオブジェクト配置情報検出器４０１３とオブジェクト配置調整器４０１４に送出する。
【０１０５】
オブジェクト配置情報検出器４０１３は、現在扱っているＧＵＩの位置，大きさ，等を検出し、そのデータをオブジェクト配置調整器４０１４に送出する。オブジェクト配置調整器４０１４はオブジェクト配置情報検出器４０１３からのデータとあらかじめ設定した、またはユーザが指定するＧＵＩの配置条件を考慮し、ＧＵＩの位置，大きさ等を調整し、表示画面９０８に送出する。
【０１０６】
以下に上記の実際の例を示す。
【０１０７】
図２６に実際の表示画面でのオブジェクトのＧＵＩの形態の概念を示す。オブジェクトにより作成されたＧＵＩは常時画面に表示されるわけではなく、「表示」と「非表示」という二つの状態をとる。システムが立ち上がった時点の状態は、非表示状態とする。ある時点でのネットワーク上の全ての装置のオブジェクトのＧＵＩはこの二つの状態に関して同一状態をとるものとする。この「表示」と「非表示」という二つの状態は受信装置９００本体の制御パネルや附属のリモート・コントロール・ユニット等のボタンによってトグルとなるようにしても良い。
【０１０８】
表示状態となったＧＵＩの表現は二通りで、「アイコン」の形態か「制御パネル」の形態である。システムが立ち上がった時点の表示形態は、アイコン形態とする。また、非表示状態から表示状態へ移行したときアイコン形態とするようにしても良い。
【０１０９】
各オブジェクトのＧＵＩは、それぞれ独自の表示形態（アイコン／制御パネル）を持つことが可能である。ＧＵＩの表示状態が非表示状態となった場合は、これまで表示されていた各ネットワーク装置のＧＵＩの表示形態（アイコン／制御パネル），表示位置，表示の大きさ等がエンジン９０６に全て記憶され、再び表示状態となった場合にそれらの情報を元に、元通りに表示される。これは受信装置９００の電源が落とされても有効である。再び、受信装置９００が立ち上がると、以前に接続していて、かつ今も立ち上がっている装置については以前の状態で表示する。
【０１１０】
図２７にアイコンの表示例について示す。アイコンは表示画面９０８において、左上隅から左下隅方向へ順番に並ぶ。最下端まで到達したら、一列右にずれて、また上から下に並ぶ。以後はこれを繰り返す。アイコン間のフォーカスの移動にはカーソル５０００を用いる。カーソル５０００は各アイコン間を離散的に移動するものとする。アイコン化のオン／オフは、カーソル５０００を移動し、そのアイコンを選択してから決定ボタンを押す等により決定する。
【０１１１】
このオブジェクトのＧＵＩの配置条件としては、所定の分類（例えば、ＶＴＲ，ディスプレイ，ＤＶＤ等の機器毎の分類や、記録機器、再生機器等の機能的分類等）により分類し、順番に表示するようにしても良い。
【０１１２】
図３７はこのように機器毎に分類して表示した例である。表示画面９０８の左上隅から左下隅方向にかけて該分類毎に順番に並んでいる。この表示するときの分類は、予め設定されている他、ユーザがどのような分類にするのかを設定変更できるようになっていれば更に便利である。このように分類毎に分かれて順番に表示されているので、ユーザはＧＵＩから所望のアイコンの選択がし易くなる。
【０１１３】
また、任意のネットワーク機器については予めＧＵＩを表示することを停止できるよう予め設定しておけるようにすることも可能である。これにより、ユーザは表示画面９０８により制御することのないであろう機器についてはアイコン表示されないので、必要とするアイコンのみ表示させることが出来、アイコンの選択等がし易くなり使い勝手が向上する。この分類毎に順番に表示することについては、以降全ての実施の形態に適用することが出来る。
【０１１４】
受信装置９００自身についてのＧＵＩについては、ネットワーク機器の一つとして他のネットワーク機器と同じくＧＵＩを表示するようにしても良いし、表示しないようにしても良い。自身についてＧＵＩを表示する場合、同じ操作環境を実現することができる。また、自身についてＧＵＩを表示しない場合、リモコン等でいちいちＧＵＩを選択することなく自身を直接制御することができる。
【０１１５】
図２８に制御パネルについて一例を示す。制御パネルは装置の制御を行なうためのＧＵＩを提供する。受信装置９００の表示画面９０８には、ストップボタン５０１０，プレイボタン５０１１等が表示され、これらを例えばカーソルにより選択し決定操作を行うことによって、この決定された制御命令を制御パネルの送出元のネットワーク機器に送出することができる。また、スライド式の音声ボリューム５０１２も表示され、この送出元のネットワーク機器の音声の大きさを調整する機能を提供する。これらのＧＵＩはビットマップ等の画像を用いたり、何らかの図形描画言語を用いたものを利用する。この図形描画言語とは、文字多重放送で用いられているジオメトリック符号や、Ｊａｖａのグラフィックライブラリ等も含む。図示しないが複数の制御パネル間の移動に関してもアイコンの規則と同様にカーソルによる選択／決定の方式が取られ、制御パネル内のボタン等の移動／決定も同様である。
【０１１６】
この制御パネルの表示時、この制御パネルのネットワーク機器が例えばプレイ動作を行っていたときにはプレイボタン５０１１の枠が赤色となり、現在プレイ状態であることが判別可能に表示されている。ここでカーソルをストップボタン５０１０に移動、決定し該機器を停止させたときにはストップボタン５０１０の枠が赤色となり、停止動作となったことが分かる。また、音声の大きさを調整する機能についても同様に、現在の音声の大きさに応じた位置にスライドが存在するように表示されている。これらは、ネットワーク機器が自身の動作をネットワークへ送出することにより実現される。
【０１１７】
また、受信装置９００が２台繋がったネットワークでは、２台の受信装置９００から同じ機器に対して同時に異なる操作がされてしまうと問題がある。このようなことが発生するのを防ぐためには予め２つの受信装置９００に予め優先順位を付けておいたり、あるネットワーク機器に対して同時に複数の受信装置９００に制御パネルを表示できないようにすれば良い。
【０１１８】
また、制御パネルの中に該ネットワーク機器のＧＵＩを入れて表示することにより、どのネットワーク機器のＧＵＩなのか知ることが出来、誤った機器に対して制御することを防ぐことが出来る。このようにすることについては、以降全ての実施の形態にも適用することが出来る。
【０１１９】
図２９〜図３２には制御パネルとアイコンを同時に表示した例を示している。
【０１２０】
図２９の例は、互いの制御パネル５０２１，５０２２，５０２３がお互いに重ならないように、かつアイコンの場所と重ならないよう、その配置、大きさを設定して画面左下から水平方向右に並べられる。また最下段が埋まったら、一段上にずれて並べられる。この図以降、制御パネルを枠としてしか記載していないものについては省略して記載しているだけであり、実際には図２８に示すようなネットワーク機器に応じた制御パネルが表示される。
【０１２１】
制御パネルが表示された後、この制御パネルに対応するアイコンを表示画面９０８に表示し続けるのか、消すようにするのかについては、どちらであっても良い。表示し続ける場合には、アイコン周囲の背景（例えばアイコン周囲を縁取る線）と制御パネルの背景とを同色とすることにより、どのアイコンの制御パネルなのかが判別し易くなる。また、制御パネルを表示させた後にもアイコンを表示し続ける場合には、表示されているアイコンの形を変形させたり、背景色を変える等して、既に制御パネルが表示されていることがアイコンで判断出来るようにすることも出来る。
【０１２２】
逆に、消えるようにした場合、表示画面９０８がアイコンや制御パネルで埋め尽くされにくくなるので、ユーザはアイコン／制御パネルの後ろに表示されている映像を良く見ることが出来、表示画面９０８を有効に利用することが出来る。このように制御パネルが表示されたときに対応するアイコンを表示画面から消す実施の形態は、以降全ての実施の形態にも適用することが出来る。
【０１２３】
図３０の例は、複数の制御パネル５０２１，５０２２，５０２３が重なることを許す例である。制御パネル５０２１，５０２２，５０２３は互いに少しずつずらして画面左下に重ねて表示する。隠れている制御パネル５０２２，５０２３は可視部分をクリックすることによってその制御パネルを最前面表示し、目的とする制御パネルへフォーカスを移すことができる。
【０１２４】
図３１の例は、常に必ず一つだけしか制御パネル５０２４の表示を許さず、他はアイコン化する例である。アイコンの１つを選択すると、画面左下に選択したアイコンに対応する制御パネル５０２４が表示され、これにフォーカスが移り、現在表示されている制御パネルはアイコン化され、入れ替わるようになっている。この制御パネルの状態は、ユーザによる新たな制御が無い時間が所定時間（例えば５分間）続いたとき、自動的にアイコンに変わるようになっている。これにより誤ってリモコン等を押してしまったときの制御パネルの誤制御を防ぐことが出来る。
【０１２５】
図３２の例は、最高ｎ個までの制御パネルの表示を許す例を示している。ｎ個未満の制御パネルが表示されている状態で、あるアイコンを選択しアイコン状態を解除すると、このアイコンに対応する制御パネルが図２９或いは図３０のように新たな制御パネルとなって表示される。また、ｎ個未満の制御パネルが表示されている状態で、ユーザがあるアイコンを選択しアイコン状態を解除すると、図３１の例のように既表示の制御パネルから制御パネルを一つを選んで、当該制御パネルに対応するアイコン化表示を行い、新たに制御パネルとして前面に表示されたものにフォーカスが移る。
【０１２６】
既表示の制御パネルの中からアイコン化する制御パネルを選択する方法としては、図示しない以下のようなものがあげられる。
【０１２７】
１．最も最近制御パネルを表示したｎ−１個の制御パネルと、新たに選択した一つの制御パネルを表示する。
【０１２８】
２．最も最近利用した、つまり制御パネル内部のコマンドを使用した、ｎ−１個の制御パネルと、新たに選択した一つの制御パネルを表示する。
【０１２９】
３．現在制御パネルが表示されているものの中で、最も最近利用していないｎ−１個の制御パネルと、新たに選択した一つの制御パネルを表示する。
【０１３０】
各制御パネルの位置、大きさはユーザのインタラクションにより自由に制御される。また、制御パネルを構成するボタン等のコンポーネントの形状等はビットマップの取り替え等により自由に変更可能である。
【０１３１】
図示しないが、あるネットワーク機器が電源が落されるなどの理由で、利用不可となった場合、対応するＧＵＩ（アイコンもしくは制御パネル）は表示画面から削除され、利用不可となったことを示すメッセージを表示画面９０８に所定の期間表示する。
【０１３２】
図３３を参照してこの発明の他の実施の形態を説明する。
【０１３３】
上記のようにネットワーク装置、例えばＤＶＤプレーヤー９５２とＶＴＲ９５１がＩＥＥＥ１３９４のようなネットワークを通じてエンジン９０６に接続される。この場合、上記の例であると、それぞれのネットワーク機器にアイコンや制御パネルの表示用のオブジェクトが記憶されているとした。しかしこれに限らず各種の方法が可能である。
【０１３４】
例えばＤＶＤ９５２は、その内部にそのＩＤとともに機能一覧６０１０を持ち、この中には例えば４種類の機能 Play （再生），Stop（停止）， Forward Skip （前方へスキップ）， Barckward Skip （後方へスキップ）の４種類の機能が各々００，０１，０４，０５と符号化されて保持されている。同様にＶＣＲ（ビデオ・カセット・レコーダ，或いはＶＴＲ：ビデオ・テープ・レコーダ）９５１は、そのＩＤと共に機能一覧６０１１を持ち、この中には機能 Play （再生）， Stop （停止）， Feed Forward （巻き取り）， Rewind （巻き戻し）が各々００，０１，０２，０３と符号化されて格納されている。
【０１３５】
エンジン９０６にはこれらの機能に対応するＧＵＩオブジェクト６０１３が格納されており、エンジン９０６は機能一覧を参照して知ったＤＶＤとＶＣＲ各々の持つ機能に対応するＧＵＩオブジェクトを表示画面９０８に表示する。
【０１３６】
表示画面９０８上で、例えばＶＣＲ９５１の Play に対応するＧＵＩオブジェクト（ボタン）６０１４がユーザによって押されると、エンジン９０６はＶＣＲ９５１に対してコマンド００（Play）をＩＥＥＥ１３９４のようなネットワークを通じて送信する。
【０１３７】
このような構成をとることによって、ＤＶＤ９５２，ＶＣＲ９５１等各々のネットワーク機器がＧＵＩオブジェクトを保持する場合に比べ、ネットワーク機器上のメモリの節約になると共に、意味的に同じ機能（例えばＶＣＲの Play とＤＶＤの Play 等）が画面上で異なったＧＵＩとなるのを防ぐことが可能になっている。つまりユーザにとって意味する記号（ＧＵＩ）に統一性が取れることになる。
【０１３８】
さらに、図に示した機能を示す番号および参照の方法をすべてのエンジン、ネットワーク機器について共通にすることにより、相互接続性を保証することが可能になっている。
【０１３９】
従来においては、家庭における家電機器の制御操作は本体に装備されている制御ボタン，制御パネル等を用いて行なわれることは稀で、各々を個別のそれ専用の附属のリモート・コントロール・ユニットを用いて制御するのが一般的である。しかし、各々のリモート・コントロール・ユニットはその本体の制御を行なうのに特化されており、他の装置の操作は行なうことができないことが多い。例え一つのリモート・コントロール・ユニットが他の装置の制御を行なえたとしても、実現できる機能は一般的な機能に限定され、その装置固有の制御を行なうことはできない場合が多い。また、各装置がＴＶなどの画面表示装置と映像ケーブル等を用いて接続されることによって、表示装置にその装置のＧＵＩを表示できるようになっている。しかし、各々のＧＵＩは他の装置の表示する同様なＧＵＩとの関連性を考慮していないことが多く、時には両者が表示装置の画面上でオーバーラップして見にくくなってしまう状態が発生する。
【０１４０】
しかしこの発明によると上記のような問題が解消される。
【０１４１】
この発明は、上述した実施の形態に限定されるものではない。
【０１４２】
イベント（Event ）の形式や取り扱い方式が異なる場合も、当該イベントに応答できるようにエンジンが工夫されている。以下、これを実現するためのデータ変換器について説明する。
【０１４３】
まず、データ変換が必要なことを理解するため、実行方式１（第１のエンジン方式）と実行方式２（第２のエンジン方式）のイベントの形式及び取り扱い方式について説明する。
【０１４４】
図３４（Ａ）は第１のエンジンによる実行方式１（第１のエンジン方式という）におけるイベントの取り扱いを示しており、イベントは、プロセデュアル・コード（Procedural Code ）の呼び出しと直接関連づけられている。プロセデュアル・コードは、図２２のバーチャルマシン（ＶＭ）９０９上で実行されるプログラムであり、例えばＢＡＳＩＣやＪａｖａといった計算機言語で記述されたものを用いることができる。
【０１４５】
実行方式１ではイベントの発生とプロセデュアル・コードの呼び出しとは等価である。図では例としてプログラム（Program ）という名称のプロセデュアル・コード７０１１中でＥｖという名称のプロセデュアル・コード７０１２が呼び出される場合を示しているが、このような呼び出しの操作がイベントに相当することになる。呼び出しの際にはデータを引数として渡すことが許されており、図ではｐ１，ｐ２を渡している。この場合、イベントにはイベントデータｐ１，ｐ２が付随していることになる。イベントはアプリケーションの実行においてアプリケーション内部で種々の動作を起動させたり、アプリケーションを構成する各オブジェクトの状態を変化させたりするために用いられる。例えば、ある時刻になったことを示すためにイベントが発生し、これに付随するイベントデータは例えば時刻データであり、呼び出されたプロセデュアル・コードの内部で時刻に応じた処理を行うために渡される。
【０１４６】
図３４（Ｂ）は、第２エンジンによる実行方式２（第２のエンジン方式）におけるイベントの扱いを示している。イベントの役割や用いられ方は、上記した第実行方式１の場合と同様であって、実行方式１のそれと同様にデータを付随させることもできるが、イベントはオブジェクトからオブジェクトへ送信されるメッセージとして扱われることや、イベントが型を持っていることが実行方式１と異なっている。イベントの型は、そのイベントが何故生じたかを示すために用いられ、例えば“ある時刻に到達した”、“あるボタンが押された”、などを識別するために用いられる。
【０１４７】
この実行方式２におけるイベントは、実行方式１のイベントのようにプロセデュアル・コード７０１２を直接呼び出すことはできず、必ずリンクオブジェクト（Link Object ）７０２１へ送られる。リンクオブジェクト７０２１は第２のエンジン方式のアプリケーションを構成するオブジェクトの１種である。
【０１４８】
リンクコンディション（Link Condition）７０２２は受け取ったイベントに対する条件を記述したものでありイベントソース（Event Source）７０２４，イベントタイプ（Event Type）７０２５，イベントデータ（Event Data）７０２６から構成されている。
【０１４９】
リンクオブジェクト７０２１がイベントを受け取ると、イベントの発生源（送信元オブジェクト）とイベントソース７０２４、イベントの型とイベントタイプ７０２５、付属データとイベントデータ７０２６がそれぞれ比較される。これにより、例えばどのアイコン（ソース）のどのボタン（タイプ）がどのように操作される（データ）かを示すことになる。
【０１５０】
比較の結果、一致しないものがあればそのイベントに関する動作は終了する。全てが一致した場合には、リンクエフェクト（Link Effect ）７０２３が起動される。リンクエフェクト７０２３は要素動作（エレメンタリーアクション；Elementary Action ）７０２７の並びである。具体的な要素動作の例には、他のオブジェクトへイベントを送るセンドイベント（Send Event）や、プロセデュアル・コードを呼び出すコール（Call）などがある。
【０１５１】
上記のように実行方式１と実行方式２ではイベントの形式や取り扱い方式が異なるため、実行方式１のアプリケーションを直接的に実行方式２のアプリケーションに変換することはできなかった。
【０１５２】
しかし本発明では図３５に示すようにプロセデュアル・コードの呼び出しである実行方式１のイベントから実行方式２のイベント８０１１とリンクオブジェクト８０１２の組を生成するように工夫している。リンクオブジェクト８０１２のリンクコンディション８０１３にはイベント８０１１によって常に成立する条件を記述する。そしてリンクエフェクト８０１４にはプロセデュアル・コード８０１６を呼び出す要素動作８０１５（Call）を記述することにより、実行方式１のイベントによってプロセデュアル・コードが実行されるのと等価な動作を実行方式２で実現している。
【０１５３】
このような処理を実現することにより、本体が実行方式２のタイプであっても、実行方式１のイベントに対応することができる。
【０１５４】
次に、図３６を参照して、実行方式２のアプリケーションを実行方式１のアプリケーションに変換する場合のイベントの取り扱いを説明する。つまり本体が実行方式１のタイプに対して、実行方式２のイベントが入力された場合、このイベントの扱い方を説明する。
【０１５５】
実行方式２では型と付属データを伴ったイベント８０４１がリンクオブジェクト８０４２へ入力されるが、このイベント８０４１に対応するものとして、実行方式１の、呼び出し用のイベント８０４４を生成する。このイベント８０４４は、引数として、どこで発生したかを示すソース（Source）と、その型（Type）と、付属データ（Data）を持つことになる。このイベント８０４４は、プロセデュアル・コード８０４３の呼び出し用として機能する。つまり、イベント８０４１に対応させて引数を持つイベント８０４４を発生させる。この図の例えば、Source＝１，Type＝０、Data＝２という引数に変換されている。
【０１５６】
次に、プロセデュアル・コード８０４３は、実行方式２のリンクコンディション８０４５に記述された条件を判定する引数比較部８０４６と、第２のエンジンのリンクエフェクト８０４７に記述された動作を実現する動作記述部８０４８として構成する。
【０１５７】
引数比較部８０４６の実現方法としては、図に示す例の場合、図３６の符号８０４９に示すような条件分岐構文による記述がある。例えば、
ＩＦ（Ｓｏｕｒｃｅ！＝１）ｒｅｔｕｒｎ
（もしソースが１でないならば戻りなさい）
ＩＦ（Ｔｙｐｅ！＝０）ｒｅｔｕｒｎ
（もしタイプが０でないならば戻りなさい）
ＩＦ（Ｄａｔａ！＝２）ｒｅｔｕｒｎ
（もしデータが２でないならば戻りなさい）
である。
【０１５８】
このように記述することで条件が一致すれば（Source＝１，Type＝０、Data＝２）、引数比較部８０４６を通過し、動作記述部８０４８に進むことになる。これにより、Source＝１，Type＝０、Data＝２の条件に対応したアクション１、２、３が実行に移される。この実行は、各要素動作（アクション；実行方式２）と等価なコード（実行方式１）を予め作成しておき、これを図３６の符号８０５０のように配列しておくことにより実現できる。
【０１５９】
以上のように本発明ではリンクオブジェクトと等価な動作を行うプロセデュアル・コードを実行方式１用に生成することで等価な動作を実現している。
【０１６０】
以上説明したこの発明によると以下の番号にそれぞれ述べるような各特徴を備えている。
【０１６１】
（１）実行するアプリケーションを、１つあるいは複数の信号伝送システムに対応する、映像、音声、データとして送信する装置において、前記アプリケーションを構成する要素を、インターラクティブ機能を有する異なるテレビジョンシステムで共通に用いる基本的な共通データと、おのおの異なる信号伝送システムが個別に用いる個別データとに分解して送信する。
【０１６２】
（２）また、上記の信号伝送システムから伝送された信号を受信する装置であって、前記共通データのみを用いてアプリケーションを実行するか、または、前記信号送信装置の出力を受信し、前記共通データおよび、自身の方式に対応した前記個別データとを合成してアプリケーションを実行するか、または、前記信号送信装置の出力を受信し、前記共通データおよび、自身の方式に対応した前記個別データ、更に、ひとつ以上の自身の方式と異なる方式に対応した前記個別データとを合成してアプリケーションを実行する。
【０１６３】
（３）前記共通データおよび個別データは、アプリケーションの構成を記述したオブジェクトと、所定の符号化方式に従ってエンコードされたコンテンツと、制御動作を記述したスクリプトのデータの種類を持つ。
【０１６４】
（４）前記個別データは、共通データの性質を基本的に有し、個別のテレビジョンシステムに独自で共通データに不足する詳細な情報である補足データと、共通データの性質を基本的に有しないスクリプト、コンテンツデータである独自データとからなる。
【０１６５】
（５）上記共通データ中の３つのデータの種類に属する各データ単位は、自身を識別するための第１の識別子を持つ。
【０１６６】
（６）また、個別データ中の３つのデータの種類に属する各データ単位は、自身の基本的な性質を持つ共通データを知るための第２の識別子を持つことになる。
【０１６７】
（７）更に独自データであって、そのデータ単位が持つ第２の識別子が、空データのような第４のデータの種類のデータ単位の第１の識別子と関連付けられ、更に異なる方式の伝送受信に対しても拡張性を有するように図られている。つまり共通データがない方式のものも空の共通データを設けるようにし、前記拡張性を持たせている。
【０１６８】
（８）更に共通データは、自身を識別する第１識別子のみを持つ。つまり空の共通データであれば、自身を識別第１の識別子をもてばオブジェクトやスクリプトのための識別子を持たなくてもよい。
【０１６９】
（９）また共通データと個別データを合成するにあたり、個別データの独自データはそのスクリプト、コンテンツを有効成分とし、第４のデータの種類の共通データ（空の共通データ）は、その第１の識別子を有効成分として合成することになる。
【０１７０】
（１０）前記個別データは、共通データの性質を基本的に有し、個別のテレビジョンシステムに独自で共通データに不足する詳細な情報である補足データと、共通データの性質を基本的に有しないスクリプト、コンテンツデータである独自データとからなり、前記個別データ中の前記補足データのデータ単位は、自身の基本的な性質を持つ共通データを知るための第２の識別子を持ち、同独自データのデータ単位は、自身を識別するための第１の識別子を持つ事を特徴とする。
【０１７１】
（１１）第２の識別子は、所属するデータ単位の基本的な性質を持つ共通データのデータ単位の第１の識別子と同じ値を持ち、共通データと個別データの性質の関係を把握できるようにしている。
【０１７２】
（１２）共通データは、複数の異なるテレビシステムにより生成されたアプリケーション群から、いずれのテレビシステムに対しても独立となる規則により生成される。
【０１７３】
（１３）共通データの性質を基本的に有し、個別のテレビジョンシステムに独自で共通データに不足する詳細な情報である補足データの生成および共通データとの合成は、オブジェクト指向技術のクラス継承技術に基づきなされる。
【０１７４】
（１４）前記アプリケーションの基本となる構成を記述したオブジェクトとは、実行時に画面上に表示される可視性オブジェクト、画面上に表示されない非可視性オブジェクト、アプリケーション全体を制御する大局的な性質を持つオブジェクト、オブジェクト間の制御を行う内部的な性質をもつオブジェクトにより構成される。
【０１７５】
（１５）共通データに属するオブジェクトは、オブジェクトを識別する識別子、オブジェクトのタイプを示す識別子、データコンテンツを指定する識別子、スクリプトを指定する識別子をもつ、また、共通データに属するコンテンツは、コンテンツを識別する識別子、コンテンツのタイプを示す識別子をもつ。そしてまた、共通データに属するスクリプトは、スクリプトを識別する識別子、スクリプトのタイプを示す識別子をもつ。
【０１７６】
（１６）第１のテレビシステムに適合するアプリケーションのための第１の個別データと第１の共通データを受信し、前記第１の個別データを変換することにより、第２のテレビシステムのアプリケーションに必要な第２の個別データを生成し、この第２の個別データと前記第１の共通データとを用いて第２のテレビシステムに適合するアプリケーションを実行する手段を有する。
【０１７７】
（１７）第１のテレビシステムに作られたアプリケーションより生成された個別データ１と共通データと、第２のテレビシステムのアプリケーションに必要な個別データ２を前記個別データ１より変換により生成し、前記共通データと個別データ１、個別データ２を送信することができる。
【０１７８】
（１８）個別データの変換は、２つ以上の複数のテレビシステム間により行われる。
【０１７９】
（１９）個別データの変換は、２つ以上の複数のテレビシステム用の個別データから、一つのテレビシステム用の個別データを生成することを特徴とする。また個別データの変換は、１つのテレビシステム用の個別データから、複数のテレビシステム用の個別データを生成することを特徴とする。更にまた個別データの変換は、２つ以上の複数のテレビシステム用の個別データから、一つのテレビシステム用の個別データを生成することを特徴とする。
【０１８０】
（２０）共通データ、および個別データは、複数の異なるテレビシステムにより生成されたアプリケーション群から、いずれのテレビシステムに対しても独立となる規則により生成される。
【０１８１】
（２１）実行するアプリケーションを、１つあるいは複数の方式に対応する、映像・音声・データとして送信する場合、前記アプリケーションを構成する要素を、インターラクティブ機能を有する異なる方式で共通に用いる基本的な共通データと、前記異なる方式で各々個別に用いる個別データとに分解して送信する信号送信装置からの信号と、自身を操作するために用いるデータであって、前記インターラクティブ機能を有する異なる方式に変換可能なフォーマットに従ったデータを送信する機能を有する１つ以上の装置からの信号を受信する受信装置であって、前記共通データ、前記変換可能なフォーマットに従ったデータ、前記個別データ、のいずれか１つあるいは、前記１つ以上のデータの合成データを用いてアプリケーションを実行することを特徴とする信号受信装置。
【０１８２】
（２２）前記変換可能なフォーマットに従ったデータを用いたアプリケーション実行の結果として、該データの送信元である送信機の制御を行うデータを送出することができる。
【０１８３】
（２３）前記共通データは、前記変換可能なフォーマットに従ったデータのフォーマットに従って記述されている。
【０１８４】
（２４）（２１）に記載された装置であって、動作条件と動作記述とから構成されリンクオブジェクトへイベントが入力され、このイベントが動作条件を満たしていた場合にのみ動作記述で示された動作を行う第２のエンジン方式のアプリケーションを、イベントの発生とプロセデュアル・コードの実行とが等価である第１のエンジン方式のアプリケーションへと変換する変換器において、第２のエンジン方式のイベントを、そのイベントに付随するデータを引数とする第１のエンジン方式のプロセデュアル・コードの呼び出しに変換するイベント変換手段と、第２のエンジン方式のリンクオブジェクト中の動作条件を、前記呼び出しの対象となるプロセデュアル・コード中の引数比較部に変換する動作条件変換手段と、前記リンクオブジェクト中の動作記述を前記プロセデュアル・コード中の動作記述部へと変換する動作記述変換手段とを備える。
【０１８５】
（２５）引数比較部は、第２のエンジン方式のリンクオブジェクト中の動作条件を判定の条件とし、この条件と引数として渡されたデータの内容とを比較し条件が成立するかどうかを判定する。
【０１８６】
（２６）プロセデュアル・コード中の動作記述部は、第２のエンジン方式のリンクオブジェクト中の動作記述と等価な動作が第１のエンジン上で行われるように記述されている。
【０１８７】
（２７）動作記述変換手段は、第２のエンジン方式のリンクオブジェクト中の動作記述の構成要素となりうるすべてあるいは一部の記述の各々について、それらと等価なプロセデュアル・コードを予め生成しておき、それらを参照しながら動作記述部を生成する。
【０１８８】
（２８）（２１）記載の装置であって、イベントの発生とプロセデュアル・コードの実行とが等価である第１のエンジン方式のアプリケーションを、イベントは動作条件と動作記述とから構成されるリンクオブジェクトへ入力されイベントが動作条件を満たしていた場合のみ動作記述の動作を行う第２のエンジン方式のアプリケーションへ変換する変換器において、第１のエンジン方式のイベントを、第２のエンジン方式のイベントとリンクオブジェクトの組に変換することを特徴とする。
【０１８９】
（２９）上記（２８）の第２のエンジン方式のイベントとリンクオブジェクトの組の生成にあたっては、そのリンクオブジェクトは、常に成立する動作条件と、プロセデュアル・コードを呼び出す動作記述とから構成される。
【０１９０】
（３０）（２１）の装置において各々のネットワーク機器は自身が備えている機能の一覧を保持し、エンジンはこの一覧データを参照し、各々の機器に対して行うことのできる操作の種類を知る手段を持つ。
【０１９１】
（３１）（３０）において各々のネットワーク機器の保持する機能の一覧のエンジンにる参照は、エンジンの種類に関わらず一定のインタフェースによって行われることを特徴とする。
【０１９２】
（３２）（３０）においてエンジンは、ネットワーク機器が備えている機能のそれぞれに対応するグラフィカル・ユーザ・インタフェイス（ＧＵＩ）オブジェクトを保持し、ネットワーク機器が備えている機能についてこれを表示画面上でユーザに提示し、提示されたＧＵＩオブジェクトに対するユーザの操作をネットワーク機器に対して行うことを特徴とする。
【０１９３】
（３３）（２１）記載の装置は、自身を操作するために用いるデータのグラフィカル・ユーザ・インタフェイス間の相対的配置関係を調整する手段を有することを特徴とする。
【０１９４】
（３４）上記（３３）の装置を実現する手段として、データを新たに受信したことを検知して、検知したことを表すグラフィックスを送出する手段と、合成データのグラフィカル・ユーザ・インタフェイスの位置、大きさを検出する手段と、その情報を元に、グラフィカル・ユーザ・インタフェイスの配置を調整する手段とを有することを特徴とする。
【０１９５】
【発明の効果】
以上説明したようにこの発明によれば、それぞれ固有に開発された双方向システムに対し相互に互換性を確保することが可能な装置を得ることができる。
【０１９６】
また各装置にその固有の制御情報を予め所有させて、それらの情報を集中的に管理し、統一的な制御操作を行なうことができる。また、デジタルテレビジョン放送などの電波放送においてデータの転送が考えられることも踏まえ、それらのＧＵＩオブジェクトと各装置の制御のためのＧＵＩとの統一的な画面表示の調整を行なうこともできる。
【図面の簡単な説明】
【図１】この発明の一実施の形態を示す図。
【図２】この発明の他の実施の形態を示す図。
【図３】図１のブロックの具体的構成例を示す図。
【図４】この発明のデータのクラスの形態例を示す図。
【図５】この発明の装置の動作機能を説明するために示した説明図。
【図６】この発明の更に他の実施の形態を示す図。
【図７】この発明のまた更に他の実施の形態を示す図。
【図８】この発明の装置の表示例を説明するために示した説明図。
【図９】この発明によるデータの伝送形態例を説明するために示した図。
【図１０】この発明によるのデータの他の伝送形態例を説明するために示した図。
【図１１】この発明によるデータの更に他の伝送形態例を説明するために示した図。
【図１２】この発明で用いられるデータ単位の識別信号の例を示す図。
【図１３】従来のボタンオブジェクトの例を示す説明図。
【図１４】従来のボタンオブジェクトの他の例を示す図。
【図１５】この発明のボタンオブジェクトの例を示す図。
【図１６】従来のビットマップの例を示す説明図。
【図１７】従来のビットマップの他の例を示す説明図。
【図１８】この発明のビットマップの例を示す図。
【図１９】この発明によるのデータの更に他の伝送形態例を説明するために示した図。
【図２０】この発明によるのデータの更に他の伝送形態例を説明するために示した図。
【図２１】この発明によるのデータの更にまた他の伝送形態例を説明するために示した図。
【図２２】この発明のさらに他の実施の形態を示す図。
【図２３】図２２の装置の表示画面の例を示す図。
【図２４】この発明に係るネットワーク装置の構成例を示す図。
【図２５】図２４のエンジンにおける画面調整装置の構成例を示す図。
【図２６】画面の表示形態のマップを示す図。
【図２７】表示画面の表示例を示す図。
【図２８】同じく表示画面の表示例を示す図。
【図２９】同じく表示画面の表示例を示す図。
【図３０】同じく表示画面の表示例を示す図。
【図３１】同じく表示画面の表示例を示す図。
【図３２】同じく表示画面の表示例を示す図。
【図３３】ネットワーク装置の制御パネル表示の例を示す図。
【図３４】実行方式の異なるイベントのタイプおよび取り扱いの説明図。
【図３５】実行方式１のイベントを実行方式２で扱うための変換処理の説明図。
【図３６】実行方式２のイベントを実行方式１で扱うための変換処理の説明図。
【図３７】表示画面の表示例を示す図。
【符号の説明】
１０１、２０２…インタラクティブコンテンツエンコーダ、１０２、２０３…分析器、１０３、２０８…合成器、１０４、２０９…インタラクティブエンジン、２０１…ＡＶエンコーダ、２０４…フォーマットエンコーダ、２０５…多重器、２０６…分離器、２０７…フォーマットデコーダ、２１０…ＡＶデコーダ、９０４…合成器、９０５…インターフェイス、９０６…エンジン、９０７…変換器、９０８…表示画面、９０９…バーチャルマシン、９２０…入出力端子、９５１、９５２、９５３…ネットワーク装置、９６０…ネットワーク。

Claims (2)

1. 実行するアプリケーションを、１つあるいは複数の方式に対応する、映像、音声、データとして送信する場合、前記アプリケーションを構成する要素を、インターラクティブ機能を有する異なる方式で共通に用いる基本的な共通データと、おのおの異なる方式が個別に用いる個別データとに分解して送信する信号送信装置からの信号を受信する受信装置であって、
   前記信号送信装置の出力を受信し、前記共通データのみを用いてアプリケーションを実行するか、
   または、前記信号送信装置の出力を受信し、前記共通データおよび、自身の方式に対応した前記個別データとを合成してアプリケーションを実行するか、
   または、前記信号送信装置の出力を受信し、前記共通データおよび、自身の方式に対応した前記個別データ、更に、ひとつ以上の自身の方式と異なる方式に対応した前記個別データとを合成してアプリケーションを実行するかのいずれかの手段を有し、
   前記個別データは、共通データの性質を基本的に有し、個別のテレビジョンシステムに独自で共通データに不足する詳細な情報である補足データと、共通データの性質を基本的に有しないスクリプト、コンテンツデータである独自データとからなり、
   前記個別データ中の前記補足データのデータ単位は、自身の基本的な性質を持つ共通データを知るための第２の識別子を持ち、同独自データのデータ単位は、自身を識別するための第１の識別子を持つことを特徴とする信号受信装置。
2. 実行するアプリケーションを、１つあるいは複数の方式に対応する、映像、音声、データとして送信する場合、前記アプリケーションを構成する要素を、インターラクティブ機能を有する異なる方式で共通に用いる基本的な共通データと、おのおの異なる方式が個別に用いる個別データとに分解して送信する信号送信装置からの信号を受信する受信装置であって、
   前記信号送信装置の出力を受信し、前記共通データのみを用いてアプリケーションを実行するか、
   または、前記信号送信装置の出力を受信し、前記共通データおよび、自身の方式に対応した前記個別データとを合成してアプリケーションを実行するか、
   または、前記信号送信装置の出力を受信し、前記共通データおよび、自身の方式に対応した前記個別データ、更に、ひとつ以上の自身の方式と異なる方式に対応した前記個別データとを合成してアプリケーションを実行するかのいずれかの手段を有し、
   第１の方式に適合するアプリケーションのための第１の個別データと第１の共通データを受信し、前記第１の個別データを変換することにより、第２の方式のアプリケーションに必要な第２の個別データを生成し、
   この第２の個別データと前記第１の共通データとを用いて前記第２の方式に適合するアプリケーションを実行する手段を有することを特徴とする信号受信装置。

Images