JP2004538726A - Ｍｐｅｇ‐４に基づくマルチメディア・システム、そのシステムのためのサービス・プロバイダ、およびコンテンツに基づく遠隔通信装置 - Google Patents

Abstract

サービス・プロバイダ、および遠隔通信装置（リモコン）に関連する、ＭＰＥＧ‐４に基づくマルチメディア・システムを開示する。対話式コンテンツに基づく遠隔通信装置は、符号化されたＭＰＥＧ‐４データを使用して、対話式サービスの受信に必要なステップとボタンの数を減らして簡略化する。加えて、サービス・プロバイダ側でデータを処理する新しい方法を開示する。更に、サービス・プロバイダ（ブロードキャスタ、ケーブル・プロバイダ）と顧客（視聴者）間でデータをやり取りする改良された方法を紹介する。更に、利用可能なチャンネルの帯域幅を制御し、データを表示するためにデータ処理に係わるディジタル装置（サーバ、セットトップ・ボックス、リモコン、ディスプレイ）を最適化する方法を開示する。

Description

【技術分野】
【０００１】
本発明は、マルチメディア・システムに関し、特に、このマルチメディア・システムのためのサービス・プロバイダに関連するＭＰＥＧ‐４に基づくマルチメディア・システム、およびマルチメディア・システムのためのコンテンツに基づく遠隔通信装置に関する。
【背景技術】
【０００２】
マルチメディア装置は、多目的に使用され、種々の形式の情報（オーディオ番組、テレビジョン番組、映画、コンピュータ・ゲーム、インターネット通信など）を処理し、且つ処理された情報をユーザに提供することのできることはよく知られている。しかしながら、その処理された情報は、一人のユーザ（例えば、その番組を選択したユーザ）にのみ興味を持たれ、その情報が提供されている（例えば、画面に表示され、あるいはオーディオ・システムを通して出力されている）とき、そこに居合せている他のユーザたちは、別の番組を見たいと思うかも知れないし、あるいは、現在提供されている番組の或る特定の場面に関してもっと多くの情報を得たいと思うかも知れない。また、マルチメディア装置のコントロールは難しいものであることもよく知られている。現在のリモコン装置は大抵、受動的な役割を演じており、例えば、テレビジョン受信機に一方向のコマンドを伝達しているだけであり、視聴者と装置間の比較的原始的なインタフェースとなっている。マルチメディアの典型的な利用には双方向のサービスも含まれ、これはリモコン上で多数のボタンを必要とする。これは厄介で煩わしいことである。何故なら、特に装置の表面上でボタンやキーパッド用に利用できるスペースが限られているからである。将来、マルチメディア装置の数が増加するにつれて、対応する機能の数も増加するので状況は一層悪くなる。
【０００３】
従って、種々の会社が、最近のマルチメディア装置をコントロールする問題に対応するために新しい解決策を提案している。これらの解決策の１つは、オランダに本部を置くフィリップス（Ｐｈｉｌｉｐｓ（登録商標））社が製作したＰＲＯＮＴＯ（登録商標）インテリジェント・リモートコントロールである。このリモコン装置は万能の学習装置であって、大型のタッチ・スクリーン液晶表示装置（ＬＣＤ）、ＬＣＤ上に表示されるバーチャル・キーボード、および双方向の赤外線（ＩＲ）トランシーバを備えている。ＩＲトランシーバは、他のリモコン装置（ｒｅｍｏｔｅ ｃｏｎｔｒｏｌ ｕｎｉｔ：ＲＣＵ）からのコード（ｃｏｄｅ）を学習する。Ｐｈｉｌｉｐｓ（登録商標）リモコン装置は、そのバーチャル・ボタンの数が適応性のあるものであるから、インテリジェント装置であるものと考えられる。その結果、ユーザは所望の機能を実行するために見る必要のあるものだけを見ることになる。
【０００４】
韓国に本社を置くサムスン（Ｓａｍｓｕｎｇ（登録商標））社は更なるステップに踏み込み、小型の高解像度ＬＣＤ表示を備えるＩＤＥＯ（商標）という名称の双方向リモコン装置を製作している。Ｓａｍｓｕｎｇ（登録商標）のリモコンは、リモコンの通常の機能に加えて、ディスプレイ上でテレビジョン信号を受信し視聴することができる。従って、ユーザは、テレビジョン受信機で１つの番組を見ながら、他の番組（ｐｒｏｇｒａｍ）／チャンネル（ｃｈａｎｎｅｌ）をスキャンし、プレビューし、視聴し、あるいは選択することができる。注目すべきことに、リモコンのディスプレイ上に表示されるビデオの信号源は外部の装置（例えば、テレビジョン受信機内に備えられる送信機）であり、そのような装置は第２のチューナを必要とする。しかしながら、バーチャル・ボタンは、適当なソフトウェアおよび／またはハードウェアによって内部で発生される。
【０００５】
米国特許第６，６７１，２２５号、第５，８６１，９０６号および第５，６５７，０７２号は、テレビジョン受信機に接続されるセットトップ・ボックスとメディア・サーバ間に於けるディジタル情報の双方向送信を開示している。
【０００６】
米国特許第６，００２，４５０号は、選択された情報（広告のような）を視覚的に表示するＬＣＤを備える双方向リモコン装置を開示している。
【０００７】
米国特許第６，０２０，８８１号は、グラフィカルなユーザ・インタフェースを備えるリモコン装置を開示し、これはユーザが選択することができるオブジェクトを有する。
【０００８】
米国特許第６，０７０，１６７号は、とりわけ操作のために、オブジェクトに基づく画像のオーディオ・ビジュアル・タギング（ｔａｇｇｉｎｇ：タグ付け）のための階層制（ｈｉｅｒａｒｃｈｉｃａｌ）システムを開示している。
【０００９】
米国特許第６，０９７，４４１号（オールポート：Ａｌｌｐｏｒｔ氏に付与された）は、協働するが物理的には独立している２個またはそれ以上のディスプレイを使用するシステムを開示している。この特許は、幾つかの点で、上述したＳａｍｓｕｎｇ（登録商標）のリモコン装置に類似しているように思われる。
【００１０】
米国特許第６，１２７，９４１号（ヴァン ライツイン：Ｖａｎ Ｒｙｚｉｎ氏に付与された）は、種々のマルチメディア装置をコントロールするためにグラフィカルなユーザ・インタフェースを備える双方向ワイヤレス・リモコン装置を開示している。これと上述したＰｈｉｌｉｐｓ（登録商標）社の装置は同様なリモコン機能を有するが、信号の送信に関しては同じように動作しない。
【００１１】
米国特許第６，１３０，７２６号は、番組ガイドを表示するディスプレイを備えるリモコン装置を開示している。
【００１２】
米国公開公報ＵＳ２００２／００１６７６６号は、サービス・プロバイダによるディジタルコンテンツの双方向配信を開示している。
【発明の開示】
【００１３】
（発明の概要）
技術が急速に進歩するにつれ、新しい技術を利用することによってマルチメディアのコンテンツにアクセスする能力と上述したリモコンのコンセプトとを更に改善する必要がある。本発明は２つの異なるデータ符号化フォーマット、例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）のＭＰＥＧ‐２およびＭＰＥＧ‐４マルチメディア標準に基づいている。ＭＰＥＧ‐４は、コンテンツに基づく符号化／復号化プロセスであって、ＭＰＥＧ‐２のようなブロック志向（ｂｌｏｃｋ‐ｏｒｉｅｎｔｅｄ）ではない。従って、ＭＰＥＧ‐４では、オーディオ／ビジュアル場面を構成するオブジェクトと対話（ｉｎｔｅｒａｃｔ）する機能が得られる。これらのオブジェクトは、オーディオ、ビジュアル、およびオーディオ／ビジュアルのオブジェクトであって、自然のものまたは合成されたもの、すなわち、カメラやマイクで記録できあるいはコンピュータで発生できるものである。ＭＰＥＧ‐４のデータ・ストリームには、オブジェクトと場面の説明が含まれ、それにより対話式の（ｉｎｔｅｒａｃｔｉｖｅ）オーディオ／ビジュアル・オブジェクトに関連するストリームの構成およびその他の情報が提供される。従って、ＭＰＥＧ‐４の標準でも、改善されたクライアント‐サーバの対話性が得られ、これはダウンストリームとリターン・ストリームの通信経路（チャネル）の形式で実現することができる。これは有益である。何故なら、ダウンストリームのデータ・ストリームは、例えば、ｅ‐コマースまたは対話式（双方向）のテレビジョン放送において、受信者から送信者にアップストリームの情報が伝達されることも必要となるからである。
【００１４】
ＭＰＥＧ‐４のデータ・ストリームは、ＭＰＥＧ‐２のデータ・ストリームの中に埋め込まれて送信することができ、その後、受信側で、ＭＰＥＧ‐２のデータ・ストリームから分離することができる。
【００１５】
本発明は、２つのデータ符号化フォーマットであるＭＰＥＧ‐２とＭＰＥＧ‐４について上述した特徴を利用し、ＭＰＥＧ‐４デコーダを備える対話式の遠隔通信装置を開示するものである。開示している対話式遠隔通信装置は、対話形式のサービスの受信に必要とされるステップの数を減少させて簡略化し、また、遠隔通信のために必要とされるボタンの数を減らす。ボタンの数が多いと、ユーザにとって紛らわしい。また、本発明は、プロバイダ側でのデータ処理のための新しい方法を開示するものである。
【００１６】
対話式のディジタル・テレビジョン・サービスは現在、ディジタル・テレビジョンを導入して新しいディジタル・テレビジョン製品に支出するように顧客を奨励するカギとなる要素であると考えられる。本発明は、サービス・プロバイダ、例えば、ブロードキャスタ、ケーブル会社、インターネットのサービス・プロバイダ、そして顧客（視聴者）間でデータを交換する改善された方法を開示するものである。また、本発明は、利用可能なチャンネル帯域幅の制御とデータ表示の最適化のために、データ処理に係わるディジタル装置：サーバ、セットトップ・ボックス（ＳＴＢ）、遠隔通信装置、ディスプレイ、を変更する方法を開示するものである。
【発明を実施するための最良の形態】
【００１７】
図１で、対話形式のディジタル・テレビジョンのサービス・プロバイダ１０はしばしば、顧客（１〜Ｎ）１２、１４、１６、１８が利用できる少なくとも２種類のデータを有する。主要な番組（例えば、フィルム）のデータは主要なイベントから成る。主要な番組に関連する、追加的な対話型オーディオ／ビジュアル情報（例えば、短いフィルム）は、この明細書に於いて、「付加的オーディオ‐ビジュアル・オブジェクト」または単に「付加的オブジェクト」と称される。チャンネルの帯域幅は限られているので、サービス・プロバイダは、１チャンネルで送信されるデータ量の最適化を強いられる。付加的オブジェクトはオプションの情報を含むので、この付加的オブジェクトの受信に興味を持つのは、顧客（視聴者）１２、１４、１６、１８のうちほんの一部だけかも知れない。従って、もし付加的オブジェクトがいつでも送信されているとしたら、それはチャンネル容量の無駄遣いとなる。
【００１８】
この問題を解決するために、本発明によると、サービス・プロバイダ１０は最初に全ての顧客に付加的オブジェクトのタイトルを送信し、それから実際のオブジェクトを興味のある顧客（視聴者）だけに送信する。この明細書に於いて、タイトルとは、付加的オブジェクトを利用することができることを示すアイコンまたは短いテキストである。サービス・プロバイダ１０は、このタイトルを、それに対応するオブジェクト・コード（顧客１２、１４、１６、１８がダウンロードすることができる付加的オブジェクトのコード）と共に送信する。このタイトル、そしてのちに付加的オブジェクトは、受信装置（一体化された受信機‐デコーダ・セットトップ・ボックス）、または単にＳＴＢ（１）〜ＳＴＢ（Ｎ）２０、２２、２４、２６、で受信され処理される。
【００１９】
別の問題として、顧客は、管理することが困難である大量のデータとオプションに直面していることである。例えば、付加的オブジェクトが主番組と同時に同じテレビジョン画面に表示されるとき、これらの付加的オブジェクトが主画像の一部を覆い隠すことである。また他の問題もあり、それは、より多くの人々が主番組を見ているときに起こり、主画像の上に複数の表示が重なることである。また、通常、視聴者の全てが付加的オブジェクトを見たいと思っているわけではない。
【００２０】
これらの問題を解決するために、とりわけ、それぞれのディスプレイ４４、４６、４８、５８（これらは、例えば、タッチ・スクリーン・ディスプレイである）を有する二（双）方向のＲＣＵ（Ｒｅｍｏｔｅ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：リモコン装置）２８、３０、３２、３４、３６、３８、４０、４２が、ＳＴＢとＲＣＵ間の双方向通信に使用される。セットトップ・ボックス（ＳＴＢ）２０、２２、２４、２６がタイトルを含む番組を受信すると、ＳＴＢ２０、２２、２４，２６はそのタイトルを主番組から分離して、それぞれのリモコン装置（ＲＣＵ）２８、３０、３２、３４、３６、３８、４０、４２に送信する。このタイトルは、ワイヤード接続（例えば、バスまたはネットワーク接続）またはワイヤレス接続（例えば、ＲＦまたは赤外線ワイヤレス接続、ワイヤレス・ネットワークまたはホーム・ネットワーク接続）のような通信手段を介してＲＣＵに送信され、ＲＣＵ内に含まれる信号受信手段（例えば、図３に示すトランシーバ８８内にある）で受信される。次にＲＣＵ２８、３０、３２、３４、３６、３８、４０、４２はそれぞれのディスプレイ４４、４６、４８、５０、５２、５４、５６、５８上にこのタイトルを表示する。タイトルはテレビ受信機の主ディスプレイ上には現れない。タッチ・スクリーン・ディスプレイ上に現れるタイトルにワン・タッチするか、またはＲＣＵ上の関連するボタン／スイッチを起動すると、付加的オブジェクトを注文する目的でそれぞれのＳＴＢにメッセージを送信することができる。これはそれぞれＲＣＵ２８、３０、３２、３４、３６、３８、４０、４２によって行われ、ワイヤードまたはワイヤレスの第２の送信手段（ＳＴＢからタイトルを受信するのに使用された第１の手段と同じものかまたは異なるもの）を介してそれぞれのＳＴＢ２０、２２、２４、２６にメッセージを送る（メッセージは、ワイヤレスのＲＦ通信チャンネルを介して双方向に送られ、タイトルはＲＦ通信チャンネルを介して（またはワイヤード・ホーム・ネットワーク接続を介して）ＲＣＵに送られ、メッセージは、赤外線ワイヤレス・プロトコルによりＲＣＵからＳＴＢに送信することができる。ＲＣＵからＳＴＢへの送信は、図３に示すトランシーバ８８内にある送信手段を介して行われる。この明細書に於いて言及される送信手段は、タッチ・スクリーン・ディスプレイまたはＲＣＵ制御システムの一部を含むものと見做され、これをユーザが起動すると、このようなメッセージが発生されてＲＣＵからＳＴＢに送信される。ＲＣＵからＳＴＢへのこのメッセージは、この明細書に於いて、「タイトル・リクエスト・メッセージ」と称される。ＳＴＢ２０、２２、２４、２６は、この「タイトル・リクエスト・メッセージ」を処理して、所定のオブジェクトのコードを、リターン・チャンネルを介して、サービス・プロバイダ１０に送り返す。リターン・チャンネルは、ダウンストリーム・チャンネルと同じ通信手段であってもよいし、または同じ通信手段でなくてもよい。例えば、ダウンストリーム・チャンネルは衛星チャンネルであり、リターン・チャンネルは、例えば、衛星チャンネル、インターネットのチャンネル、ケーブル・チャンネルなどである。
【００２１】
図１に示すように、顧客はＲＣＵを１個またはそれ以上持っているかも知れない。顧客（１）は、例えば、ＲＣＵを３個、具体的に、ＲＣＵ（１−１）（２８）、ＲＣＵ（１−２）（３０）、およびＲＣＵ（１−３）（３２）を持っている。本発明の実施態様によれば、あとで述べるように、ＲＣＵ２８、３０、３２、３４、３６、３８、４０、４２はどれもそれ自身の識別コードを有しており、それぞれのＳＴＢ２０、２２、２４、２６によって個々にアドレス指定される。その結果、付加的オブジェクトをＲＣＵ（１−１）（２８）に表示することができ、その間、ＲＣＵ（１−２）（３０）はそのオブジェクトを完全に無視する。顧客が１個またはそれ以上のＲＣＵを使用することができると、これらのＲＣＵも互いに通信して、それぞれのＳＴＢ２０、２２、２４、２６に同時にデータが送信されるのを防止する。
【００２２】
図２は、サービス・プロバイダ１０が、タイトル、および異なる番組のオーディオ‐ビジュアル・オブジェクト（付加的でオプションの）を制作する手順を示すブロック図である。現在の主番組、例えば、フィルム（Ａ）およびフィルム（Ｂ）は、ＭＰＥＧ‐２の記憶メディア（手段）６０に記憶され、生の番組（Ｃ）および生の番組（Ｄ）は６２で提供される。分かり易くするために、フィルム（Ａ）と生番組（Ｄ）だけがそれぞれ１個の付加的オブジェクトと共に提供されると仮定するが、全てのアイテムが複数の付加的オブジェクトと共に提供できることは明らかである。
【００２３】
圧縮されてない、生の主番組（Ｄ）のオーディオ‐ビジュアル・ディジタル信号は、データを第１のフォーマットに符号化するエンコーダ（例えば、ＭＰＥＧ‐２エンコーダ６４）に結合され、当技術分野で知られている方法で処理される。ＭＰＥＧ‐２エンコーダ６４の出力における、圧縮され、ＭＰＥＧ‐２パケット化されたストリームは、マルチプレクサ６６に供給される。同様に、フィルム（Ａ）のＭＰＥＧ‐２パケット化されたストリームは、フィルム（Ａ）が、メモリのスペースを減少させるために、ＭＰＥＧ‐２の圧縮され符号化された形式で既に記憶されているので、記憶メディア６０から直接マルチプレクサ６６に転送される。従って、前述したＭＰＥＧ関連の信号処理の特徴は、１つまたはそれ以上のメインイベントまたはメイン・プログラム（主番組）を主データ・ストリームの形式で供給しまたは発生する例示的な一実施例を構成する。
【００２４】
「タイトル・デベロッパ」（ｔｉｔｌｅ ｄｅｖｅｌｏｐｅｒ）６８は、主番組（Ａ）および（Ｄ）と共に提供される付加的オブジェクトのタイトルを制作する。サービス・プロバイダ１０は、発生されたタイトルを、顧客（１）１２から顧客（Ｎ）１８までの全ての顧客に配信する。タイトルは、当業者に知られているソフトウェア・ツールを使用して６８において、第２のフォーマット（例えば、ＭＰＥＧ‐４の符号化された形式）でデータを符号化するエンコーダで制作される。この実施例によれば、タイトルには、ダウンロードされるオブジェクトについての短い説明が含まれているだけでなく、このオブジェクトの識別コードも含まれている。制作されたタイトルは、ＭＰＥＧ‐４のデータ・ストリームとして、マルチプレクサ６６に供給され、該当するフィルム（Ａ）と生番組（Ｄ）のＭＰＥＧ‐２パケット化ストリーム内に埋め込まれる。前述したＭＰＥＧ‐４関連の信号処理の特徴は、主データ・ストリームに加えて、付加的データ・ストリームを発生または供給するための例示的な一実施例を構成する。
【００２５】
最後に、サービス・プロバイダのプライベート・データ（ｐｒｉｖａｔｅ ｄａｔａ）の幾つかも、マルチプレクサ６６に供給される。サービス・プロバイダ１０は、プライベート・データの内容（これには、サーバ７２のアドレスを含む）を決める。このアドレスは、あとで述べるように、メッセージをリターン・チャンネルを介してサーバ７２に送り返すために、ＳＴＢ２０、２２、２４、２６により使用される。その結果、マルチプレクサ６６の出力に生じるデータ・ストリームは、ＭＰＥＧ‐２のトランスポート・ストリームであって、これには、例えば、フィルム（Ａ）、フィルム（Ａ）の埋め込まれた（ｅｍｂｅｄｄｅｄ）ＭＰＥＧ‐４タイトル、生番組（Ｄ）、生番組（Ｄ）の埋め込まれたＭＰＥＧ‐４タイトル、およびサービス・プロバイダ１０からのプライベート・データ等も含まれる。
【００２６】
サービス・プロバイダ１０は、該当するイベントがまだ送信されている間に、例えば、フィルム（Ａ）が送信されている間に、オブジェクトのタイトルだけを送信することが望ましい。何故なら、サービス・プロバイダ１０は、その後のイベントのために、新しいタイトルと新しいオブジェクトを開始するからである。
【００２７】
データ・ストリームは、送信機７４に結合され、ここで変調されて、顧客１２、１４、１６、１８に送信される。データの実際の送信に先立ち、必要とされる変調および信号処理のステップが幾つかあるが、本発明とは関係がないので、これ以上説明しない。送信のための変調処理と信号処理のステップは、信号が、衛星放送で送信されるか、ケーブル送信されるか、あるいは地上放送で送信されるかに依る。最近の技術標準としては、例えば、ＤＶＢ‐Ｓ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ‐Ｓａｔｅｌｌｉｔｅ：ディジタル・ビデオ放送‐衛星）標準、ＤＶＢ‐Ｃ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ‐Ｃａｂｌｅ：ディジタル・ビデオ放送‐ケーブル）標準、ＤＶＢ‐Ｔ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ‐Ｔｅｒｒｅｓｔｒｉａｌ：ディジタル・ビデオ放送‐地上）標準、ＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ：次世代テレビジョン方式委員会）標準、およびＤＡＢ（Ｄｉｇｉｔａｌ Ａｕｄｉｏ Ｂｒｏａｄｃａｓｔｉｎｇ：ディジタル・オーディオ放送）標準等がある。
【００２８】
図３に、図２の顧客側、１２、１４、１６、１８の一例を示す。例えば、顧客（１）１２は、ＳＴＢ（１）２０と３個のＲＣＵ：ＲＣＵ（１−１）（２８）、ＲＣＵ（１−２）（３０）およびＲＣＵ（１−３）（３２）を有する。各ＲＣＵ２８、３０、３２は独自の識別コードを有し、これは対応するＲＣＵ２８、３０、３２内のメモリ内に記憶される。ＳＴＢ（１）２０、ＲＣＵ（１−１）（２８）、および／またはＲＣＵ（１−２）（３０）とＲＣＵ（１−３）（３２）は共に、マルチメディア・システムを構成し、このシステムにおいて、ＲＣＵ２８、３０、３２の３つの識別コードは知られており、ＳＴＢ２０のメモリ８０内に記憶されている。ここで使用される、遠隔通信装置（Ｒｅｍｏｔｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｔ：ＲＣＵ）は、種々の形態と機能を含んでいるものと考えられる。例えば、ＲＣＵは、対話式サービスのために、ＳＴＢを介してサービス・プロバイダと通信し、ＳＴＢはＲＣＵをサービス・プロバイダにリンクさせる。ＲＣＵは、ＳＴＢが受信したＭＰＥＧ‐２／ＭＰＥＧ‐４の合成データ・ストリームからＳＴＢが分離したＭＰＥＧ‐４データの形式で、ＳＴＢから受信されたコンテンツを表示する。ＲＣＵは、例えば、リモコン内に典型的に設けられる制御機能を提供することにより、ＳＴＢを制御する。ＲＣＵは対話性とＳＴＢの制御を行い、あるいは最小限のＳＴＢ制御機能を行うか、または全くＳＴＢ制御機能を行わず、ＳＴＢを介する情報の受信と送信はＲＣＵのユーザにとってトランスペアレント（ｔｒａｎｓｐａｒｅｎｔ：明白）である。ＲＣＵは手で持たれ、例えば、典型的なリモコンまたはパーソナル・ディジタル・アシスタント（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ：ＰＤＡ）と類似しており、あるいはＲＣＵは比較的大きなディスプレイを有する比較的大きな装置であって、ラップトップ・コンピュータに類似している。
【００２９】
再び図３を参照すると、ＳＴＢ（１）２０に於いて、受信され復調された信号は、ＭＰＥＧ‐２のデータ・ストリームであって、デマルチプレクサ７４の入力に供給される。この例示的なデータ・ストリームには、上述のように、例えば、フィルム（Ａ）、フィルム（Ａ）の埋め込まれたＭＰＥＧ‐４タイトル、生番組（Ｄ）、生番組（Ｄ）の埋め込まれたＭＰＥＧ‐４タイトル、およびサービス・プロバイダ１０のプライベート・データ等が含まれる。
【００３０】
以下の説明では、ＳＴＢ（１）１２の視聴者がフィルム（Ａ）を見ることを選択すると仮定する。その結果、デマルチプレクサ７４は、フィルム（Ａ）のパケット化されたオーディオ／ビデオ・ストリームをデマルチプレクスして、生番組（Ｄ）のストリームを無視する。デマルチプレクサ７４の出力はＭＰＥＧ‐２デコーダ７６に供給され、デコーダ７６は、この信号を対応するオーディオ／ビデオ信号に復号化する。従って、フィルム（Ａ）はカラーテレビジョン（ＣＴＶ：図３に示さず）の画面に現れる。また、デマルチプレクサ７４は、ＭＰＥＧ‐２データ・ストリームから、埋め込まれたＭＰＥＧ‐４データ・ストリームを検出して抽出する。特に、このＭＰＥＧ‐４データ・ストリームには、フィルム（Ａ）に関連する付加的オブジェクトのタイトルが含まれている。この時点で、ＭＰＥＧ‐４データをＲＣＵ２８、３０、３２に送信する前に、マイクロコントローラ７８はテーブル（一覧表）を作成する、この明細書中では、これを、「付加的オブジェクト・テーブル」と称す。このテーブルは、リクエストされたオブジェクトを視聴者とサービス・プロバイダ１０との間で適当な対話形式で処理するために必要とされる情報を与えるものである。
【００３１】
「付加的オブジェクト・テーブル」には以下のデータが含まれる。
１．対応するタイトルと共にサービス・プロバイダが送信するオブジェクト識別コード。
２．ＭＰＥＧ‐２トランスポート・ストリーム内に含まれるフィルム（Ａ）またはイベントの識別コード。
３．ＭＰＥＧ‐２トランスポート・ストリーム内に含まれる現在の番組（チャンネル）の識別コード。
４．メッセージをリターン・チャンネルを介してサービス・プロバイダのどこに送り返すべきかについてのアドレス情報。このアドレスはプライベート・データ内に含まれるか、またはサービス・プロバイダが提供するサービス情報内に含まれる。
５．興味のある視聴者のＲＣＵ識別コード。これは現時点では知られていない。
【００３２】
ＲＣＵ識別コード以外の全ての情報は知られており、ＳＴＢ２０のメモリ８０内にある「付加的オブジェクト・テーブル」内に容易に記憶することができる。マイクロコントローラ７８の制御の下で、利用できるＲＣＵの３つの識別コードおよび分離されたＭＰＥＧ‐４のタイトルは、ＲＦトランシーバ８２を介して、遠隔通信装置ＲＣＵ（１−１）（２８）、ＲＣＵ（１−２）（３０）、ＲＣＵ（１−３）（３２）の全てに送信される。それ自身の識別コードを受信して識別するＲＣＵ、ここではＲＣＵ（１−１）（２８）、ＲＣＵ（１−２）（３０）、ＲＣＵ（１−３）（３２）、はそれぞれのマイクロコントローラ（図３に示さず）とそれぞれのＭＰＥＧ‐４デコーダ８４を使用して、メッセージを復号化する。ＲＣＵ２８、また、ＲＣＵ３０、ＲＣＵ３２は、受信したオブジェクト識別コードを記憶し、そのタイトルをそれぞれのタッチ・スクリーン・ディスプレイ８６上に表示する。従って、視聴者はカラーテレビジョン受信機でフィルム（Ａ）を見ることができ、且つタイトル（すなわち、受信されたフィルム（Ａ）の付加的オブジェクトのタイトル）をＲＣＵのディスプレイ８６上で見ることができる。
【００３３】
ＲＣＵ（１−１）（２８）を持っている視聴者だけが、ディスプレイ８６上のタイトルにタッチ・プレスする（触れて押す）ことにより、表示されたタイトルを選択し、その間、他の視聴者たちは興味がないと仮定する。本発明の実施態様により、「タイトル・リクエスト・メッセージ」は、興味のある視聴者のＲＣＵ、ここではＲＣＵ（１−１）（２８）でのみ発生される。「タイトル・リクエスト・メッセージ」には、選択されたタイトルのオブジェクト識別コードとＲＣＵ（１−１）（２８）の識別コードが含まれている。ＲＣＵは、「タイトル・リクエスト・メッセージ」を、それ自身のＲＦトランシーバ８８を介して、ＳＴＢ２０のＲＦトランシーバ８２に送信する。受信されたオブジェクト識別コードの補助により、ＳＴＢ２０のマイクロコントローラ７８は「付加的オブジェクト・テーブル」を識別して、受信されたＲＣＵ識別コードをテーブルに追加する。すなわち、所定のオブジェクトのために同じグループのコードに追加する。
【００３４】
これで「追加オブジェクト・テーブル」は完成する。次に、マイクロコントローラ７８は、ＭＰＥＧ‐２トランスポート・ストリーム内にある受信された現在のイベントのコードを、フィルム（Ａ）と共に、「付加的オブジェクト・テーブル」内のフィルム（Ａ）のコードと比較する。フィルム（Ａ）が受信されたイベントであれば、両コードは同じである。次にマイクロコントローラ７８は、モデム９０を使用して、「オブジェクト・リクエスト・メッセージ」を、インターネットまたは別のリターン・チャンネル（例えば、ダウンストリーム・チャンネルと同じ媒体（ｍｅｄｉｕｍ））を介して、サービス・プロバイダ１０に送る。
【００３５】
サービス・プロバイダ１０のサーバのアドレスは、前述したプライベート・データ内にある。「オブジェクト・リクエスト・メッセージ」には、オブジェクト識別コードと、セットトップ・ボックスのアドレス、例えば、インターネットのアドレス、が含まれている。
【００３６】
ＲＣＵとＳＴＢ間のデータのやり取りは局所的に（すなわち、家庭で）行われるので、送信用のプロトコルは、ＳＴＢ２０のプロデューサが自由に決定することができる。例えば、典型的な遠隔制御（リモコン）プロトコルに類似するプロトコルは、制御情報のために使用され、高速データ・ネットワーク通信プロトコルのような他のプロトコルは、番組のコンテンツおよび／または制御情報のために使用される。この明細書に於いて述べたような、ＲＣＵとＳＴＢ間のワイヤレスＲＦ通信を使用する実施例に加えて、ワイヤレス通信よりもむしろ、あるいはワイヤレス通信に加えて、ワイヤード（ｗｉｒｅｄ：有線）通信も使用することができる。ネットワーク・プロトコルを使用すれば、ＳＴＢとＲＣＵ間の通信に加えて、ＲＣＵとＳＴＢは、他の装置、例えば、オーディオ・システム、ビデオ番組ソース（ＶＣＲ、ＤＶＤなど）のような他のマルチメディア装置、と通信することもできる。他方、ＳＴＢとサービス・プロバイダ１０間で使用される送信用プロトコルは、リターン・チャンネルに使用されるメディア（媒体：ｍｅｄｉａ）に依存し、本発明の一部ではない。
【００３７】
勿論、他の視聴者が同じオブジェクトの受信に興味を持つこともある。例えば、図１において、ＲＣＵ（３−２）（３８）を有する視聴者である顧客（３）、およびＲＣＵ（Ｎ−２）（４２）を有する視聴者である顧客（Ｎ）。サービス・プロバイダ１０（図２参照）において、オブジェクト・コード、および興味のある全ての視聴者のＳＴＢアドレスが収集され、サーバ７２で処理される。サーバ７２は、受信されたオブジェクト・コードによって、必要とされるオブジェクトをＭＰＥＧ‐４記憶メディア７０から取ってくる。記憶メディア７０において、このデータは、スペースを減らすために、ＭＰＥＧ‐４の符号化された形式で記憶される。サーバ７２は、このオブジェクト（その識別コードを含む）を、ダウンストリーム・チャンネルを介して該当する顧客に送信する。
【００３８】
注目すべきことに、種々のＲＣＵ（Ｒｅｍｏｔｅ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のユーザは、オブジェクトを「タイム・シフト・モード」で見ることができる。同一のＳＴＢと通信するＲＣＵが少なくとも２個、ＲＣＵ（Ａ）とＲＣＵ（Ｂ）、あると仮定する。ＳＴＢはタイトルをＲＣＵ（Ａ）と（Ｂ）に送信し、このタイトルは、ＲＣＵ（Ａ）と（Ｂ）のディスプレイ上に同時に表示される。ＲＣＵ（Ａ）を有する視聴者は、そのタイトルを、例えば、１０時に、ＲＣＵ（Ａ）のディスプレイ上で選択（プレス）することができ、オブジェクトを１０時０１分に受信し、そのリクエストされたオブジェクトを見始める。ＲＣＵ（Ｂ）を有する視聴者は、それと同じタイトルを、１０時０５分にＲＣＵ（Ｂ）のディスプレイ上で選択（プレス）し、同じオブジェクトを１０時０６分に受信し、そのリクエストされたオブジェクトを見始める。選択されたオブジェクトの持続期間は、それぞれのＲＣＵで同じオブジェクトを見始めた時間差である５分間よりも長い、と仮定する。このような場合に、ＲＣＵ（Ｂ）を有する視聴者は、そのオブジェクトを、ＲＣＵ（Ａ）を有する視聴者に対してタイム・シフト・モード（ｔｉｍｅ ｓｈｉｆｔ ｍｏｄｅ）で見ていることになる。
【００３９】
図３で、ＳＴＢ２０内にあるマイクロコントローラ７８は、受信されたＭＰＥＧ‐４のオブジェクト・コードを、「付加的オブジェクト・テーブル」内のオブジェクト・コードと比較して、該当する視聴者のＲＣＵ、ここでは、ＲＣＵ（１−１）（２８）、の識別コードを得る。次にマイクロコントローラ７８は、このＲＣＵ識別コードと実際のオブジェクトをＲＦトランシーバ８２によりこのＲＣＵに送信する。ＲＣＵ（１−１）（２８）の識別コードだけが、受信された識別コードと一致するので、ＲＣＵ（１−１）（２８）は、フィルム（Ａ）に関連するオブジェクトを復号化してディスプレイ８６上に表示し、ＲＣＵ（１−２）（３０）とＲＣＵ（１−３）（３２）は、受信されたメッセージを無視する。表示されたオブジェクトは、カラーテレビジョン受信機に表示されるフィルム（Ａ）に関連するものである。
【００４０】
従って、上記より、サービス・プロバイダ１０からの新しいオファー（ｏｆｆｅｒ）の開始で、全ての視聴者が少量の付加的データ（すなわち、タイトル）を受信することは明らかである。あとで、興味のある視聴者だけが、実際のオブジェクトについて比較的多量の付加的データ（音声付きのビデオ信号、例えば、短いサブジェクト・フィルム）を受信する。その間、フィルム（Ａ）はカラーテレビジョン受信機で見られており、ＰＩＰ（Ｐｉｃｔｕｒｅ‐Ｉｎ‐Ｐｉｃｔｕｒｅ）として一般に知られているピクチャ‐イン‐ピクチャ（これには第２のチューナも必要である）の場合のように、主画像を覆い隠す余分なウインドウで起こる混乱もない。図２に示すように、付加的オブジェクトのタイトルは、フィルム（Ａ）のデータ・ストリーム内に埋め込まれ、フィルム（Ａ）が終了すると、それに対応するタイトルの送信も終了する。
【００４１】
フィルム（Ａ）の終了時に、タイトルの送信が停止すると、顧客は以下のような状況の何れかになる。
Ａ）表示されたタイトルを無視したかまたは既にそれを削除した、興味のない視聴者。この視聴者は、そのフィルムの終了時に、イフェクト（ｅｆｆｅｃｔ：影響）されない。
Ｂ）視聴者は既に興味のあるそのオブジェクトをダウンロードした。この視聴者もイフェクト（ｅｆｆｅｃｔ：影響）されない。
Ｃ）視聴者はオブジェクトをダウンロードしている最中である。この視聴者も影響されない。何故なら、この実施例では、サービス・プロバイダ１０のサーバ７２は、その完全なオブジェクトを送信し続けているからである。
Ｄ）そのフィルムの終了後に、視聴者は或るオブジェクトをリクエストした。もしこの視聴者がそのタイトルをプレス（ｐｒｅｓｓ：選択）して、そのオブジェクトのダウンロードを試みるなら、上述したように、「タイトル・リクエスト・メッセージ」が発生されて、ＳＴＢ２０に送信される。マイクロコントローラ７８はフィルム（Ａ）の現在の状態をチェックする。この状態は、「イベントは現在進行中である」か、または「イベントは既に終了している」の何れかである。現在の状態についての情報は、ＭＰＥＧ‐２トランスポート・ストリーム内の該当するデータと「付加的オブジェクト・テーブル」内に記憶されたフィルム（Ａ）のイベント・コードとを比較することにより決定することができる。ＳＴＢ２０が両方のコードを比較すると、そのコードは同じものではなく、現在のイベントの状態は、「イベントは既に終了している」である。この状態は、視聴者がそのフィルムを見ながら番組を変更しなかったなら、事実である。従って、現在の番組の状態をチェックする必要がある。マイクロコントローラ７８は、現在の番組コードを、「付加的オブジェクト・テーブル」内に記憶された番組コードと比較する。視聴者は番組を変更しなかったので、両方のコードは同じである。この比較の結果、フィルムは確かに終了している。
【００４２】
その結果、マイクロコントローラ７８は、メッセージ「ｎｏｔ ａｖａｉｌａｂｌｅ」（利用できない）を該当するＲＣＵに返送し、このメッセージはディスプレイ８６上に表示される。この「利用できない」というメッセージは、表示されたタイトルが余分なもの（もはや必要でなく、削除すべき）であることを視聴者に知らせるのに役立つ。
【００４３】
表示されて残っているタイトルの数は時間と共に増加するので、不要なタイトルの削除がもっと能率的に且つ機械的に行われるならば視聴者に役立つであろう。従って、タイトルの削除は、以下に示す起こり得る状態のうち１つまたはそれ以上によって達成することができることが望ましい。
１）視聴者は、タイトルをハイライトしてメニューからの削除を選択することにより、従来のやり方でいつでもタイトルを削除することができる。
２）視聴者は、上述の「利用できない」メッセージを受信後にタイトルを削除することができる。
３）視聴者は、メニューからオプションの「ディスプレイをリフレッシュする」を選択し、余分なタイトルを全て削除することができる。コマンド「ディスプレイをリフレッシュする」によって、表示された各タイトルについて「タイトル・リクエスト・メッセージ」が自動的に発生される。これらの「タイトル・リクエスト・メッセージ」は全て、ＳＴＢ２０に連続的に送信され、利用できるかチェックされる。その結果に依り、ＳＴＢのマイクロコントローラ７８は、削除コマンドを該当するＲＣＵに送る。そうすることにより、全ての余分で不必要なタイトルは順次に自動的に削除される。
４）ユーザが興味のあるタイトルをプレス（ｐｒｅｓｓ：選択）して、コマンド「ディスプレイをリフレッシュする」が自動的に起動され、不要なタイトルを完全に自動削除することもできる。
視聴者は表示されていたタイトルをプレスする前に、番組を変更した。すなわち、イベント・フィルム（Ａ）がまだ終っていないのに、別の番組が選択された。このような場合、ＲＣＵは「タイトル・リクエスト・メッセージ」を発生し、それをＳＴＢ２０に送る。ＳＴＢ２０は現在のイベント・コード（フィルム（Ａ）ではない）を、「付加的オブジェクト・テーブル」内のフィルム（Ａ）のコードと比較すると、両コードは同じではない。マイクロコントローラ７８は、現在の番組コードを、「付加的オブジェクト・テーブル」内の番組コードと比較する。視聴者は、番組を変更したので両コードは同じでない。この場合、マイクロコントローラ７８は、「所定の番組にスイッチ・バックする（Ｙｅｓ／Ｎｏ？）」というメッセージを送り、このメッセージはＲＣＵのディスプレイ８６上に表示される。視聴者が「Ｙｅｓ」を選択すると、ＳＴＢ２０はフィルム（Ａ）の番組に自動的にスイッチ・バックする。これが行えるのは、上述したように、番組コードが「付加的オブジェクト・テーブル」内に記憶されているからである。次に、マイクロコントローラ７８は、現在のイベントの状態をチェックして、フィルム（Ａ）がまだ進行中であるかを確かめる。もし両コードが同じであれば、マイクロコントローラ７８は、所定のオブジェクトのコードとＳＴＢ２０のアドレスをサービス・プロバイダ１０に送る。もし番組コードが異なれば、「利用できない」メッセージが該当するＲＣＵに送られる。もし視聴者が「Ｎｏ」を選択すれば、ＳＴＢ２０は、その「タイトル・リクエスト・メッセージ」を無視する。
【００４４】
ＳＴＢの処理アルゴリズムを図４にフローチャートで示す。図４のフローチャートには本発明の実施態様を理解するのに必要な、主要なステップのみが含まれている。
【００４５】
ＳＴＢ（Ｓｅｔ‐Ｔｏｐ Ｂｏｘ：セットトップ・ボックス）のブロック４００からスタートする。４０２で、トランシーバのインタラプト（ｉｎｔｅｒｒｕｐｔ：割り込み）があったかどうかが判定される。判定がＮＯであれば、４０４で、デマルチプレクサまたはモデムのインタラプトがあったかどうかが判定される。ＮＯであれば、４０２に戻る。ＹＥＳであれば、４０６で、それがＭＰＥＧ‐４のタイトルか、オブジェクトかが判定される。もしオブジェクトであれば、４０８で、そのオブジェクトが識別される。４１０で、付加的オブジェクト・テーブルからＲＣＵ識別コードが得られる。４１２で、ＲＣＵ識別コードが送られ、４１４で、そのオブジェクト識別コードが送られ、４１６で、そのオブジェクトがＲＣＵに送られ、４０２に戻る。
【００４６】
４０６における判定で、データがＭＰＥＧ‐４のタイトルであれば、４１８で、付加的オブジェクト・テーブルが作成され、４２０で、全てのＲＣＵ識別コードが送られ、４２２で、そのタイトルとオブジェクトのコードが送られ、４０２に戻る。
【００４７】
４０２における判定がＹＥＳであって、それがトランシーバのインタラプトであれば、４２４で、それが内部オブジェクトか外部のオブジェクトかが判定される。そのデータが内部オブジェクトであると判定されると、４２６で、非ＭＰＥＧデータが復号化され、４２８で、内部オブジェクトのサブルーチンが呼び出され、４０２に戻る。
【００４８】
４２４の判定で、データが外部オブジェクトであれば、４３０で、タイトル・リクエスト・メッセージが供給され、４３２で、ＲＣＵ識別コードがオブジェクト・プロパティ・リストに供給され、４３４で、イベント・コードが同じであるかどうかの判定が行われる。判定がＹＥＳであれば、４３６で、オブジェクト・リクエスト・メッセージがサービス・プロバイダに送られ、その後、４０２に戻る。
【００４９】
４３４での判定がＮＯであって、イベント・コードが同じでなければ、４３８で、番組コードが同じであるかどうかの判定が行われる。判定がＹＥＳであれば、４４０で、「利用できない」というメッセージがＲＣＵに送られ、その後、４０２に戻る。
【００５０】
４３８での判定がＮＯであって、番組コードが同じでなければ、４４２で、メッセージ「所定の番組にスイッチ・バックする（ＹＥＳ／ＮＯ）」がＲＣＵに送られる。４４２でのメッセージに対する応答に依り、４４４で判定が行われる。もし応答がＮＯであれば、４４６で、タイトル・リクエスト・メッセージは無視され、４０２に戻る。応答がＹＥＳであれば、４４８で、スイッチ・バックが行われ、４５０で、イベント・コードが同じあるかどうかが判定される。４５０での判定がＹＥＳであれば、４５２で、オブジェクト・リクエスト・メッセージがサービス・プロバイダに送られ、４０２に戻る。判定がＮＯであって、イベント・コードが同じでなければ、４５４で、メッセージ「利用できない」が送られ、４０２に戻る。
【００５１】
図５のシステムには、カラーＴＶ（カラーテレビジョン受像機）セット１００、セットトップ・ボックス（ＳＴＢ）１０２、および双方向ＲＣＵ１０４が含まれ、インターネットはリターン・チャンネルとして使用される。従って、ＳＴＢ１０２はモデム１０６を介してインターネット・サイトに接続される。ＲＣＵ（Ｒｅｍｏｔｅ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）１０４には、アンテナ付きＲＦトランシーバ１０８が含まれ、適当な処理を行い、当技術分野で知られている方法で、無線周波（ＲＦ）信号を、ＳＴＢ１０２に送信し且つＳＴＢ１０２から受信する。ＲＣＵ１０４とＳＴＢ１０２には、このＲＦトランシーバの代りに、赤外線（ＩＲ）トランスミッタ／トランシーバ（図示せず）を備えてもよく、当技術分野で知られている方法で、ＳＴＢとＲＣＵの間でワイヤレスの通信を行う。これに代る別のものとして、ＳＴＢとＲＣＵは、ワイヤードまたはワイヤレスのネットワークで接続され通信する。このネットワークには、他の装置、例えば、ホーム・オーディオ・システム、パーソナル・コンピュータ、ディスプレイ、ＤＶＤプレーヤなども接続される。また、１つのシステムは多数のＲＣＵを備え、これらは１つまたはそれ以上の通信手段を介して、ＳＴＢと、サービス・プロバイダと、且つ互いに、通信することができる。
【００５２】
更にＲＣＵ１０４は、タッチ・スクリーンのグラフィカル・ユーザ・インタフェース、例えば、ＬＣＤ１１０を備え、これもビデオの表示に適している。或る動作モードに於いて、ＲＣＵ１０４は従来の方式で動作する。すなわち、表示されたデータは、ユーザが発するコマンドを表し、内部で発生され、タッチ・スクリーン・ディスプレイに現れるバーチャルのボタン／アイコンを使用して、種々の機能を制御する。ＳＴＢ１０２には、アンテナ付きの第２のＲＦトランシーバ１１２が含まれる。第２のＲＦトランシーバ１１２は、ＲＣＵ１０４の第１のＲＦトランシーバ１０８と実質的に同じであり、情報を伝達する信号を送信／受信するという同じ機能を実行する。
【００５３】
ＲＣＵ１０４のディスプレイ１１０上に見られるように、内部で発生されるアイコンに加え、任意の数のタイトルがあり、これらは、タイトル１、タイトル２、およびタイトル３と称される。これらのタイトルの全てまたは一部は、現在のイベントに関するものであって、それ以外のタイトルは余分で不必要なものである。ユーザは、タッチ・スクリーン・ディスプレイ上のタイトルをプレスする（押す）ことにより、該当するオブジェクトを対話式にダウンロードすることができる。その結果、タイトル１について、図５に示すように、選択されたタイトルがハイライトされる。
【００５４】
図６は、本発明の実施態様によるＲＣＵ１０４における信号処理を表す簡略化されたブロック図である。異なる動作を実行するために、他の種々の構成要素がＲＣＵ内に備えられることが理解される。しかしながら、分かり易くするために、これらの構成要素についての説明は、本発明の理解に必須のものではないので省略する。また、ＲＣＵ内にあるＩＲトランシーバおよびＳＴＢ内のＩＲトランシーバは、オプション（ｏｐｔｉｏｎ：任意選択）のものであり、もしＲＦトランシーバ１０８、１１２が従来の制御コマンドの送信に使用されるなら、取り外すこともできる。あるいは、使用されるＩＲトランシーバが、ＭＰＥＧデータも送信するならば、これらのＲＦトランシーバを取り外すこともできる。
【００５５】
図６で、ＲＦトランシーバの出力における、受信され且つ復調されたＭＰＥＧ‐４データ・ストリームは、マイクロコントローラ１１４とＭＰＥＧ‐４デコーダ１１６に供給される。復号化にはデータ記憶用のメモリを必要とする。復号化されたＭＰＥＧ‐４ディジタル・オーディオ／ディジタル・ビデオ信号は、当技術分野で知られている方法で、音声／映像処理回路１２０で更に処理される。処理回路１２０は更に、リクエストされたビデオ・オブジェクトをディスプレイ１２２が表示するときに使用することができるＬＣＤタッチ・スクリーン・ディスプレイ１２２およびスピーカ１２４へのインタフェースとして機能する。またＲＣＵ１０４は、非ＭＰＥＧデータをＳＴＢ１０２から受信して復号化する。
【００５６】
この箇所に至るまでは、オブジェクト・リクエスト・メッセージと実際の付加的オブジェクトは、主として、例えば、インターネットで送信される。インターネットをリターン・チャンネルとして使用する利点は、主送信チャンネル（例えば衛星チャンネル）におけるデータ・ペイロードの量を減らすことである。この方法の不利な点は、興味のある顧客の数と同じ回数だけ、付加的情報を送らなければならないことである。従って、インターネット以外のリターン・チャンネルを考慮することも本発明の一つの実施態様である。
【００５７】
リターン・チャンネルは、ダウンロード・チャンネルと同じメディア（手段）であり、ケーブル、衛星または地上波放送のチャンネルを使用する。これらのリターン・チャンネルは、上述した標準で規定されている。サービス・プロバイダが、ダウンストリームとリターン・ストリームに同じメディアを使用する場合、主データと付加的データの量を、そのリターン・チャンネルのために最適化すべきである。本発明の実施態様によれば、付加的オブジェクトのタイトルは、リターン・チャンネルのメディアとは無関係に、同じ方法で送信される。すなわち、符号化されたＭＰＥＧ‐４データとして、主番組のパケット化されたＭＰＥＧ‐２データ・ストリーム内に埋め込まれる。しかしながら、種々異なる顧客の所定のオブジェクト・コードは、ダウンストリーム・データと同じメディアにより、あるいは他の適当なリターン・チャンネルにより、サービス・プロバイダに返送することができる。
【００５８】
サービス・プロバイダの側では、受信されたメッセージは絶えずソート（ｓｏｒｔ：分類）され、各オブジェクト・コードについて別個にカウント（ｃｏｕｎｔ：計数）され、顧客リクエストの統計的分布を計算する。その結果は、どのオブジェクトに何人の顧客が興味を持っているかを示す。この結果は次に、図７に示す統計的マルチプレクサ１２６で使用されてから、実際の付加的オブジェクトが送信される。実施例では、統計的マルチプレクサを使用するが、ほかにも統計分布を、例えば、マルチプレクサ６６のソフトウェアまたは他の同等な装置で、展開する同等な方法があり、全て普通に利用することができる。その結果、付加的オーディオ／ビデオ・オブジェクトの１つの受信に興味を持つ顧客が増加すれば、それだけ、その特定のオブジェクトのために利用できるデータ・スペースが増大する。入来するメッセージの統計上の分布は、現在の視聴者の興味に関する貴重な情報でもあり、これはサーバ１２８によって実行される。この情報の補助により、サービス・プロバイダは付加的オブジェクトの質を高め且つ使用される帯域幅を縮小／増加することができる。この実施例では、リターン・チャンネルにダウンストリーム・チャンネルを使用して、双方向通信が送信機／受信機１３０により実行される。図７に示す統計的な集計機能を除き、図７には、図２と同じ構成要素が多数含まれ、このような要素を、図２におけるのと同様な数字で表す。
【００５９】
ＲＣＵの処理アルゴリズムを、図８のフローチャートに示す。このフローチャートには本発明の実施態様を理解するのに必要な機能だけを示す。
【００６０】
マイクロコントローラ１１４（図６）は、タッチ・スクリーン・ディスプレイ１２２（図６）の入力信号をスキャンする。８０２で、視聴者がスクリーン上の或るオブジェクトをプレス（ｐｒｅｓｓ：押す、選択）すると、８０４で、マイクロコントローラ１１４は、そのオブジェクトを探し出して識別する。８０６で、そのオブジェクトが内部のものか外部のものか、２つの可能性がある。内部のオブジェクトは、工場で設定されたオブジェクトであって、サービス・プロバイダ１０により提供されるタイトルとは無関係である。このような内部オブジェクトは、マルチメディア装置の基本的機能、例えば、音量またはチャンネル選択（選局）、を当技術分野で知られている方法で制御するために使用され、この明細書に於いては、これ以上説明しない。このような場合、８０８で、非ＭＰＥＧデータは復号化され、８１０で、内部オブジェクトのサブルーチンにエグジット（ｅｘｉｔ）する。
【００６１】
外部オブジェクトはサービス・プロバイダ１０から受信されるタイトルである。８０２で、画面に表示されているタイトルをタッチ・スクリーン・ディスプレイ上でプレスする（押す）と、８１２で、マイクロコントローラ１１４は、「タイトル・リクエスト・メッセージ」を制作して送信し、８１４で、メッセージがＳＴＢに送られ、８１６で、ＳＴＢは所望のオブジェクトのオブジェクト・コードをメモリ１１８（図６）に記憶する。８１８で、マイクロコントローラ１１４はレジスタ（図示せず）内に１ビットを設定し、これは「オブジェクトを待つ」フラグと称される。このフラグ（ｆｌａｇ）が設定さると、マイクロコントローラ１１４は、視聴者が或るオブジェクトをサービス・プロバイダ１０にリクエストしていることを「知り」、８０２に戻る。
【００６２】
８００で、ＳＴＢ２０がＲＣＵにメッセージを送ると、１２０で、トランシーバ１０８（図６）は、ＲＣＵのマイクロコントローラ１１４にインタラプト（割り込み）信号を送る。８２０で、マイクロコントローラ１１４は、そのメッセージにそれ自身の識別コードが含まれているかどうかをチェックしてから復号化に進む。もし識別コードが異なれば、８２２で、そのメッセージは無視され、８０２に戻る。識別コードが正しければ、８２４で、「利用できない」というメッセージの存在がチェックされる。このようなメッセージが存在すれば、８２６で、「利用できない」というサブルーチンに入る。
【００６３】
もし「利用できない」というメッセージが存在しなければ、８２８で、「スイッチ・バックする」というメッセージの存在がチェックされる。このメッセージがあれば、８３０で、「スイッチ・バックする」ルーチンに入る。このようなメッセージがなければ、８３２で、「オブジェクトを待つ」というフラグがチェックされる。設定される「オブジェクトを待つ」というフラグは、リクエストされたオブジェクトをＲＣＵが待っていることを意味し、このオブジェクトのコードはＲＣＵのメモリ１１８内に記憶される。８３４で、マイクロコントローラ１１４は、受信されたオブジェクト・コードを、記憶されたオブジェクト・コードと比較し、両コードが同じであれば、８３６で、ＭＰＥＧ‐４デコーダ１１６（図６）を使用して、マイクロコントローラ１１４は、受信されたオブジェクト・データを復号化し、８３８で、「オブジェクトを待つ」というフラグをリセットする。８４０で、受信されたオブジェクトはディスプレイ１２２（図６）に表示され、８０２に戻る。
【００６４】
もし受信されたオブジェクト・コードと記憶されたオブジェクト・コードが同じでなければ、８４２で、マイクロコントローラ１１４は、新しいオブジェクト、すなわち、新しいタイトル、を処理する。８３２で、フラグ「オブジェクトを待つ」が設定されなくても、マイクロコントローラ１１４は、新しいタイトルを処理する。８４４で、マイクロコントローラ１１４は、この新しいタイトルを復号化し、８４６で、タイトルを表示用にアレンジ（ａｒｒａｎｇｅ：構成）し、８４８で、ＭＰＥＧ‐４デコーダ１１６を使用してタイトルを表示し、８０２に戻る。
【図面の簡単な説明】
【００６５】
【図１】対話式ディジタル・テレビジョン・サービスのための、サービス・プロバイダと顧客との配置構成を示す。
【図２】サービス・プロバイダが、異なる番組のタイトルおよびオプションの付加的オーディオ‐ビジュアル・オブジェクトの制作手順を示すブロック図である。
【図３】図２の顧客側のブロック図を示す。
【図４】図３のセットトップ・ボックスの処理アルゴリズムの流れ図を示す。
【図５】典型的なマルチメディア・システムを示す。
【図６】図５の遠隔通信装置（ＲＣＵ）のブロック図である。
【図７】情報の統計的収集を使用する図２のサービス・プロバイダのブロック図である。
【図８】図５と図６の遠隔通信装置の動作の流れ図（フローチャート）を示す。

Claims (16)

1. イベントを表すために第１のフォーマットで符号化されたデータを含むデータ・ストリームより成り且つ前記イベントに関連する付加的情報を表すために第２のフォーマットで符号化されたデータより成るデータ信号を受信する手段であって、付加的情報を表す前記データは前記イベントを表すデータ・ストリーム内に埋め込まれている、前記データ信号受信手段と、
   前記イベントのデータ・ストリームから付加的情報を抽出する手段と、
   少なくとも１つの所定の遠隔通信装置に付加的情報を提供する手段と、から成る装置。
2. 付加的情報が１つまたはそれ以上の遠隔通信装置に提供され、所定の遠隔通信装置のみが前記付加的情報に応答し、且つ更なる付加的情報を求めるリクエストを前記所定の遠隔通信装置から受信する手段を具える、請求項１記載の装置。
3. イベントを表すために第１のフォーマットで符号化されたデータ・ストリーム内に含まれるデータがＭＰＥＧ‐２の符号化されたデータより成り、付加的情報を表すために第２のフォーマットで符号化されたデータがＭＰＥＧ‐４の符号化されたデータより成る、請求項２記載の装置。
4. データ信号受信手段が、イベントを表すデータと付加的情報を表すデータより成るデータ信号を第１の通信チャンネルを介して受信する、請求項３記載の装置。
5. 更なる付加的情報のリクエストを、第１の通信チャンネルまたは、前記第１の通信チャンネル以外の第２の通信チャンネルを介して、サービス・プロバイダに供給する手段を更に備える、請求項４記載の装置。
6. イベントを表すデータ・ストリームを復号化して、復号化されたデータを発生する手段と、前記復号化されたデータに応答してイベントのディスプレイを発生する手段を更に具え、イベントに関連する付加的情報が、前記イベントに関する付加的情報の外部オブジェクトを含み、時間の経過に伴ない前記外部オブジェクトの幾つかは無効となる、請求項１記載の装置。
7. イベントが主ディスプレイ装置に表示されている間、外部オブジェクトは有効である、請求項６記載の装置。
8. データ信号内に含まれ、且つ外部オブジェクトを表すために第２のフォーマットで符号化されたデータが、ＭＰＥＧ‐４の符号化されたデータより成る、請求項７記載の装置。
9. 信号を処理する方法であって、
   イベントを表すために第１のフォーマットで符号化されたデータを含むデータ・ストリームより成り且つ前記イベントに関連する付加的情報を表すために第２のフォーマットで符号化されたデータより成るデータ信号を受信するステップにおいて、付加的情報を表す前記データは前記イベントを表すデータ・ストリーム内に埋め込まれる、前記ステップと、
   イベントのデータ・ストリームから付加的情報を抽出するステップと、
   前記付加的情報を所定の遠隔通信装置に提供するステップと、から成る前記方法。
10. 付加的情報を提供するステップが、前記付加的情報を１つまたはそれ以上の遠隔通信装置に提供するステップを含み、所定の遠隔通信装置だけが付加的情報に応答し、且つ更なる付加的情報を求めるリクエストを前記所定の遠隔通信装置から受信するステップを更に含む、請求項９記載の方法。
11. イベントを表すために第１のフォーマットで符号化されたデータ・ストリーム内に含まれるデータが、ＭＰＥＧ‐２の符号化されたデータより成り、付加的情報を表すために第２のフォーマットで符号化されたデータが、ＭＰＥＧ‐４の符号化されたデータより成る
    請求項１０記載の方法。
12. データ信号を受信するステップが、イベントを表すデータおよび付加的情報を表すデータより成るデータ信号を第１の通信チャンネルを介して受信するステップを含む、請求項１１記載の方法。
13. 第１の通信チャンネルか、または前記第１の通信チャンネル以外の第２の通信チャンネルの何れかを介して、更なる付加的情報を求めるリクエストをサービス・プロバイダに供給するステップを更に含む、請求項１２記載の方法。
14. イベントを表すデータ・ストリームを復号化して、復号化されたデータを発生するステップと、前記復号化されたデータに応答して前記イベントのディスプレイを発生するステップとを更に含み、イベントに関連する付加的情報が、前記イベントに関する付加的情報の外部オブジェクトを含み、前記外部オブジェクトの幾つかは時間の経過に伴ない無効となる、請求項９記載の方法。
15. イベントが主ディスプレイ装置に表示されている間、外部オブジェクトは有効である、請求項１４記載の方法。
16. データ信号内に含まれ、且つ外部オブジェクトを表すために第２のフォーマットで符号化されたデータがＭＰＥＧ‐４の符号化されたデータより成る、請求項１５記載の装置。

Images