(57)【要約】  モジュールの要求に対する返事を双方向テレビジョンネットワーク上の複数の受信器にマルチキャストすることを可能とする装置および方法である。複数のモジュールの要求は放送サービスプロバイダへ送られるべき単一の要求の中にパッケージ化される。要求が双方向テレビジョンネットワーク上の複数の受信器にマルチキャストされ、そして要求に対する応答が複数の受信器に対してマルチキャストされる。ユーザー装置は、特定の時間内に放送サービスプロバイダによってマルチキャストされるモジュールのリストにアクセスすることによって、モジュールを要求するかどうかを決定する。ユーザー装置は、放送サービスプロバイダのカローセルに存在するディレクトリーリスティングモジュールをアクセスする時に行動をするべきかを決定する。【選択図】図２
2008522490.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一つのモジュールの要求を受信しその要求に対する応答を双方向テレビジョンネットワーク上の複数の受信器システムへマルチキャストするヘッドエンドシステムを含む装置。
【請求項２】
請求項１記載の装置であって、前記要求は前記双方向テレビジョンネットワーク上の前記複数の受信器システムの中の第一の受信器システムから受信される装置。
【請求項３】
請求項１記載の装置であって、前記装置はソースシステムであり、前記双方向ネットワークは、少なくとも一つのモジュールが前記複数の受信器システムへ送信される前方路と、前記少なくとも一つのモジュールの要求が受信器システムから前記ソースシステムへ通信される戻り路とを備える装置。
【請求項４】
請求項１記載の装置であって、複数のモジュールを少なくとも一つの受信器システムへ通信し、前記複数のモジュールは前記受信器システムへ通信される他のモジュールについての情報を有するディレクトリーモジュールを備える装置。
【請求項５】
双方向テレビジョンネットワーク上でのモジュール要求に応答する方法であって、
複数の受信器システムのうちの一つである第一の受信器システムからの少なくとも一つのモジュールの要求を受信することと、
前記少なくとも一つのモジュールを前記複数の受信器システムへマルチキャストすることとを備える方法。
【請求項６】
請求項５記載の方法であって、
前記複数の受信器システムのうちの一つである第二の受信器システムにおいて、前記マルチキャストされたモジュールを受信して記憶することを更に備える方法。
【請求項７】
請求項５記載の方法であって、
単一の通信にパッケージ化された複数の要求を受信することと、
前記複数の要求の各要求に順次対応することとを備える方法。
【請求項８】
請求項５記載の方法であって、
単一の通信にパッケージ化された複数の要求を受信することと、
前記複数の要求に全て同時に対応することとを備える方法。
【請求項９】
請求項５記載の方法であって、
前記要求からタイミング情報を抽出することと、
前記タイミング情報に基づいて前記要求に対応することとを含む方法。
【請求項１０】
請求項９記載の方法であって、前記タイミング情報は前記要求が特定の時刻より早くなくあるいは遅くなく対応されることを示す方法。
【請求項１１】
双方向テレビジョンネットワーク上の受信システムを備えるシステムであって、該受信システムは、必要とされるモジュールと関係する少なくとも一つのモジュールを決定し、該関係するモジュールの要求を生成するシステム。
【請求項１２】
請求１１記載のシステムであって、ソースシステムを更に備え、前記受信器システムは前記要求を前記ソースシステムに送信するシステム。
【請求項１３】
請求項１２記載のシステムであって、前記受信器システムは複数の受信器システムのうちの一つであるシステム。
【請求項１４】
請求項１３記載のシステムであって、前記ソースシステムは、前記要求を受け取り、前記少なくとも一つの関連するモジュールを前記複数の受信器システムへマルチキャストするシステム。
【請求項１５】
双方向テレビジョンネットワーク上で要求をパッケージ化する方法であって、
受信器システムにおいて、単一の検索後モジュールと関係する少なくとも一つのモジュールを決定することと、
ソースシステムへ送信されるべき前記関係するモジュールの要求を生成することとを備える方法。
【請求項１６】
請求項１５記載の方法であって、複数の要求を単一の通信へパッケージ化することを備える方法。
【請求項１７】
請求項１６記載の方法であって、前記要求は、要求がいつ対応されるべきかを特定するタイミング情報を含む方法。
【請求項１８】
請求項１７記載の方法であって、前記タイミング情報は前記要求が特定の時間より早くなくあるいは遅くなく対応されることを示す方法。
【請求項１９】
請求項１５記載の方法であって、
前記ソースシステムにおいて、前記少なくとも一つの関係するモジュールの要求を受信することと、
前記ソースシステムにおいて、前記少なくとも一つの関係するモジュールを複数の受信器システムへマルチキャストすることとを更に備える方法。
【請求項２０】
デジタルテレビジョンネットワークにおいてデジタルデータを通信するシステムであって、
双方向アプリケーションのモジュールからなるデータストリームを提供するソースシステムと、
前記データストリームを受信する複数の受信器システムとを備え、
該複数の受信器は、
少なくとも一つのモジュールの要求を前記複数の受信器システムへマルチキャストする第一の受信器システムと、
前記要求を受け取り、前記少なくとも一つのモジュールを前記複数の受信器システムへマルチキャストする第二の受信器システムとを備えるシステム。
【請求項２１】
請求項２０記載のシステムであって、前記第一の受信器システムと前記第二の受信器システムは、ピアトゥピア双方向テレビジョンネットワークと、クライアント／サーバネットワークと、ピアトゥピアおよびクライアント／サーバの結合されたネットワークのうちの少なくとも一つ上にあるシステム。
【請求項２２】
請求項２０記載のシステムであって、前記第二の受信器システムは、前記少なくとも一つの要求されたモジュールをローカルキャッシュから取得し、該少なくとも一つのモジュールを前記複数の受信器システムへマルチキャストするシステム。
【請求項２３】
複数の受信器システムを備える双方向テレビジョンネットワーク上でモジュールを要求する方法であって、
第一の受信器システムにおいて、少なくとも一つのモジュールの要求を前記複数の受信器へマルチキャストすることと、
第二の受信器システムにおいて、前記少なくとも一つのモジュールの要求を受信することと、
前記第二の受信器システムにおいて、前記要求された少なくとも一つのモジュールを前記複数の受信器システムへマルチキャストすることとを備える方法。
【請求項２４】
請求項２３記載の方法であって、前記第二の受信器システムにおいてローカルキャッシュから前記モジュールを取得することを更に備える方法。
【請求項２５】
請求項２４記載の方法であって、前記双方向テレビジョンネットワークは、ピアトゥピア双方向テレビジョンネットワークと、クライアント／サーバテレビジョンネットワークと、ピアトゥピアおよびクライアントサーバの結合されたネットワークのうちの一つである方法。
【請求項２６】
ソースシステムからモジュールのリストを受信し該モジュールが前記モジュールリストの中に存在するならモジュールを要求すべきかどうかを決定する受信器システムを備えた装置であって、前記モジュールが前記ソースシステムからマルチキャストされる装置。
【請求項２７】
請求項２６記載の装置であって、前記リストは双方向テレビジョンネットワーク上で前記ソースシステムからマルチキャストされないモジュールを備える装置。
【請求項２８】
請求項２６記載の装置であって、前記リストは特定の時間内に双方向テレビジョンネットワーク上で前記ソースシステムからマルチキャストされるモジュールを備える装置。
【請求項２９】
請求項２６記載の装置であって、前記リストは特定の時間内に双方向テレビジョンネットワーク上で前記ソースシステムからマルチキャストされないモジュールを備える装置。
【請求項３０】
受信器システムにおいて、ソースシステムからモジュールのリストを受信することと、
前記モジュールがモジュールのリストの中に存在するならばモジュールを要求すべきかどうかを決定することとを備える方法。
【請求項３１】
請求項３０記載の方法であって、前記リストは双方向テレビジョンネットワーク上で前記ソースシステムからマルチキャストされるモジュールを含む方法。
【請求項３２】
請求項３１記載の方法であって、前記リストは各モジュールがマルチキャストされるべき各チャネルを備える方法。
【請求項３３】
請求項３０記載の方法であって、前記リストは双方向テレビジョンネットワーク上で前記ソースシステムからマルチキャストされないモジュールを含む方法。
【請求項３４】
請求項３０記載の方法であって、前記リストは特定の時間内に双方向テレビジョンネットワー上で前記ソースシステムからマルチキャストされるモジュールを備える方法。
【請求項３５】
請求項３０記載の方法であって、前記リストは特定の時間内に双方向テレビジョンネットワーク上で前記ソースシステムからマルチキャストされないモジュールを備える方法。
【請求項３６】
カローセルと、
ディレクトリーを生成するソースシステムとを備えるシステムであって、
前記ディレクトリーは、前記カローセルに存在するモジュールのリストと、各モジュールが双方向テレビジョンネットワーク上でマルチキャストされる時間とを備え、前記ソースシステムはさらに前記ディレクトリーを複数の受信器システムへマルチキャストするシステム。
【請求項３７】
請求項３６記載のシステムであって、前記複数の受信器システムの中に第一の受信器システムを更に備え、該第一の受信器システムは前記ディレクトリーを受信し該ディレクトリーへのアクセス時に特定の動作を行うかどうかを決定するシステム。
【請求項３８】
請求項３６記載のシステムであって、前記動作は、アプリケーションを開始すること、アプリケーションを開始しないこと、アプリケーションから出ることのうちの一つであるシステム。
【請求項３９】
請求項３６記載のシステムであって、前記決定は、前記ソースシステムから特定のモジュールが送られる時間に基づいて行われるシステム。
【請求項４０】
ソースシステムにおいて、カローセルに存在するモジュールのリストと、双方向テレビジョンネットワーク上で各モジュールがマルチキャストされる時間とを備える、モジュールのディレクトリーを生成することと、
前記ディレクトリーを複数の受信器システムへマルチキャストすることとを備える方法。
【請求項４１】
請求項４０記載の方法であって、
受信器システムにおいて前記ディレクトリーを受信することと、
前記ディレクトリーへのアクセス時に特定の動作を行うかどうかを決定することとを更に備える方法。
【請求項４２】
請求項４０記載の方法であって、前記動作は、アプリケーションを開始すること、アプリケーションを開始しないこと、アプリケーションを出ることのうちの一つである方法。
【請求項４３】
請求項４０記載の方法であって、前記決定は、特定のモジュールが前記ソースシステムから送られる時間に基づいて行われる方法。
【請求項４４】
双方向テレビジョン環境内でデータモジュールを通信するシステムであって、
少なくとも一つのモジュールを含む少なくとも一つのアプリケーションを提供するソースシステムと、
双方向テレビジョンネットワークを介して前記ソースシステムと通信する複数の受信器システムとを備え、
少なくとも一つの受信器システムからの少なくとも一つのモジュールの要求に応答して、前記ソースシステムは前記少なくとも一つのモジュールを前記複数の受信器システムへマルチキャストするシステム。
【請求項４５】
請求項４４記載のシステムであって、前記少なくとも一つの要求する受信器システムは多数のモジュールの要求を前記ソースシステムへの通信に対する単一の要求へとパッケージ化するシステム。
【請求項４６】
請求項４４記載のシステムであって、前記少なくとも一つのモジュールの要求に応答して、前記ソースシステムは前記要求された少なくとも一つのモジュールと関係する一連のモジュールをマルチキャストするシステム。
【請求項４７】
請求項４６記載のシステムであって、前記ソースシステムは送信されるべきモジュールのリストをマルチキャストし、前記受信システムは前記リストの中に含まれるモジュールの要求を提供することを抑制するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
〔関連出願〕
本願は２００４年１１月２９日出願の米国出願番号１０／９９９，２０９の優先権の利益を請求し、この米国出願はそれを参照することにより本願中に含まれるものとする。
【０００２】
〔技術分野〕
この発明の実施例は一般に電子通信の分野にかかり、ことに双方向のテレビジョンネットワークにおけるコンテンツの要求に関する。
【背景技術】
【０００３】
双方向テレビジョンシステムは、多くの方法でコンテンツ消費者の経験を強化するように動作する。コンテンツの製作者および／または配信者は、強化されたサービスと特徴とを消費者に提供することができる。たとえば双方向テレビジョンシステムは双方向テレビジョン（ｉＴＶ）のアプリケーションを実行することができ、このアプリケーションはユーザーの視聴経験を補い且つ強化する。広い範囲の双方向テレビジョンアプリケーションは双方向テレビジョンシステムを介してユーザに与えられ、その範囲は双方向プログラムガイド（ＩＰＧｓ）からゲーム等の範囲に及ぶ。
【０００４】
双方向テレビジョンアプリケーションはコンテンツ消費者にとっても魅力的である。なぜならば、かかるアプリケーションはテレビジョン視聴経験を純粋に受動的な行動から能動的または双方向性の行動へと向上させる。たとえばショッピング用の双方向テレビジョンアプリケーションはテレビジョン放送を介して宣伝される製品に対して双方的にユーザーに総合的に注文させてもよい。
【０００５】
双方向テレビジョンアプリケーションは典型的には放送サービスプロバイダのヘッドエンドから放送通信の一部として消費者のセットトップボックス（ＳＴＢ）へと運ばれる。かかる放送はテレビジョンコンテンツ部分（たとえばオーディオ及びビデオ）および双方向性部分を含む。双方向性部分は双方向テレビジョンアプリケーションに対するアプリケーションコードと制御情報を含む。サービスプロバイダは典型的にはテレビジョンコンテンツと放送の双方向性部分とを組み合わせてユーザー位置への放送である単一信号へと結合する。
【０００６】
使用者側において、使用者装置（たとえばセットトップボックス（ＳＴＢ））は放送を受信しそれの双方向部分を抽出し放送の双方向部分に組み込まれた一またはそれ以上の双方向テレビジョンアプリケーションを作製し実行する。
【０００７】
ユーザー装置は、双方向テレビジョンアプリケーションを抽出し実行することに加えて送信能力もまた与えられ、これによってユーザー装置はユーザー位置から放送サービスプロバイダまたは他のユーザーへ戻って通信でき、たとえば公衆回線（たとえばインターネット）または個人所有ネットワーク（たとえば有料テレビオペレータのイントラネット）を通して通信できる。この構成において、ユーザー装置は放送サービスから送られる特定のアプリケーションを要求してもよい。すると、放送サービスプロバイダは、アプリケーションを各個人のユーザー位置へと送信する。アプリケーションが共有媒体（たとえば放送ネットワーク）で送られるならば、同じネットワークに接続される他のユーザー装置は要求されたアプリケーションを無視するであろう。したがって、他のユーザー装置の各々はそのアプリケーションに対する要求を個別に行い、そして放送サービスプロバイダはこれらの冗長要求の各々対して個別に応答しなければならない。今日の二方向デジタルケーブル上においてネットワークが同じ物理リンク上で異なった周波数を用いる二つのネットワークを実際的な効果として含んでもよい。一つは放送ネットワークであり、他のものはポイントトゥポイントと放送モードとの両方において使われる双方向ネットワークである。いかなるＩＰネットワークにおいてもポイントトゥポイントと放送プロトコルとは同様に共存し得ることを注意すべきである。
【発明の開示】
【０００８】
この発明の一つの側面によれば、モジュールの要求に対する応答を、双方向テレビジョンネットワーク上の複数の受信器にマルチキャスト（多数送信）することを可能とする装置と方法を提供する。この発明の他の側面によれば、多数のモジュールからの要求は、放送サービスプロバイダへ送信されるべき一つの要求へとパッケージ化されてもよい。この発明の他の側面によれば、要求は、双方向テレビジョンネットワーク上の複数のサーバ（要求に応じる少なくとも一つのサーバ）および受信器へマルチキャストされる。そして、その要求に対する応答は複数のサーバと受信器へマルチキャストされる。多数のサーバがある場合に、その要求をマルチキャストすることはサーバ間で負荷のバランスを取る助けとなる。たとえば、それらサーバは全て要求を受信し、そしてどれが答えるべきかを決定する。応答可能な他のサーバは、それらがネットワーク上で同時に応答されるのを検知するやいなや応答しないと決定する。この発明の他の側面によれば、ユーザー装置は、特定の時間内に放送サービスプロバイダによってマルチキャストされるべきモジュールのリストにアクセスすることによって、モジュールを要求すべきか否かを決定する。この発明の他の側面によれば、ユーザー装置は、放送サービスプロバイダのカローセルに存在するディクレトリーリスティングモジュールをアクセスする時に行動を起こすべきかを決定する。
【０００９】
他の特徴は添付図面および以下の詳細な説明から明らかになるであろう。
【発明を実施するための最良の形態】
【００１０】
この発明の典型的実施例は一例として図示されたものであって、添付図面の図に限定されるものではなく、また、同様の参照番号は同じまたは同様の要素を示す。
双方向テレビジョンネットワーク環境においてコンテンツを要求する方法とシステムが述べられる。下記の記述においては、説明のために、多数の特定の細部がこの発明の完全な理解を提供するために提示される。しかしながら、この発明はこれらの特定の細部なしに実施できることは当業者には明らかである。
【００１１】
図１Ａは典型的な双方向テレビジョン環境１０の図示的表示であって、これと関連してこの発明が構成される。双方向テレビジョン環境１０は、データ（たとえばテレビジョンコンテンツおよび双方向アプリケーションデータ）を配信システム１４を介して多数の受信器システム１５、１６、１７へと通信するソースシステム１２を含む。配信システム１４はデータの通信を行うことができる何らかの通信システムであって、たとえば全国的あるいは地方のテルコ（Ｔｅｌｃｏ）ネットワーク等を含むことは理解されるであろう。図１Ｂは、ソースシステム１２と受信器システム１６の典型的な詳細を示す双方向テレビジョン環境１０の図示的表示である。
【００１２】
まずソースシステムに戻ると、ヘッドエンドシステム１８は放送通信としてデータを通信するように動作する。この目的のために、ヘッドエンドシステム１８は一つまたはそれ以上の放送サーバ２０と一つまたはそれ以上のアプリケーションサーバ２２を含むものとして示される。放送サーバ２０の各々は、各種のソースからの各種のタイプのデータを受信し、エンコードし、パケット化し、多重化し、放送するように動作する。各種の実施例において、データはソースシステム１２から受信器システム１６へネットワーク接続を介して送信されてもよい。典型的な放送サーバ２２に関する更なる詳細が図２を参照して以下に説明される。
【００１３】
各アプリケーションサーバ２２は、典型的な実施例において、モジュールをコンパイルし放送サーバ２０へ提供するように動作する。このモジュールは、アプリケーションコード、データ（たとえばスポーツイベントやニュースの提供等に対する交信された戦略およびスコア）、または双方向テレビジョンアプリケーションによって利用される何らかの他のデータ（たとえばモーションピクチャーエクスパートグループ（ＭＰＥＧ）静止画等）等を含む。この発明のモジュールは全ての通信メディアにわたってポータブルであってもよく、したがっていかなる特定の通信チャネルに対しても特殊性を含まない。モジュールは、符号化されてもよく、符号化されなくてもよく、圧縮されてもよく、あるいは圧縮されなくてもよい。アプリケーションサーバ２２は、たとえば双方向テレビジョンアプリケーションや、各種のソースから受信されたオーディオ及びビデオ信号を有する関連するデータを多重化するための多重化機能を有する。アプリケーションサーバ２２は、（たとえばストリームの）多数の双方向テレビジョンアプリケーションを受信器システム１６への配信のために一またはそれ以上の放送サーバ２０へ提供する能力もまた有してもよい。この目的のために、各アプリケーションサーバ２２はいわゆる「カローセル（carousel）」を実行してもよく、これによりコード及びデータモジュールはヘッドエンドシステム１８からの通信内に含まれるように周期的かつ反復的に放送サーバ２２に提供される。
【００１４】
ヘッドエンドシステム１８はまた、一つまたはそれ以上のバックエンドサーバ２４を含むように示されてもよく、これらはアプリケーションサーバ２２に接続されると共に典型的なモデムプール２６のような通信入出力インターフェースに接続される。ことにモデムプール２６はネットワーク２８（たとえばインターネット）を介して受信器システム１６からデータを受信し、このデータをバックエンドサーバ２４に提供するように接続される。それから、バックエンドサーバ２４は、受信器システム１６より受信されたデータをアプリケーションサーバ２２と放送サーバ２０へと提供する。したがって、ネットワーク２８とモデムプール２６は戻りチャネルとして動作し、これにより受信器システム１６はソースシステム１２と双方向性をもって提供される。戻りチャネルを介してヘッドエンドシステム１８へ提供されるデータは、ほんの一例として、受信器システム１６で実行される双方向テレビジョンアプリケーションへのユーザー入力や、受信器システム１６によって生成されてソースシステム１２へ通信されるデータを含む。ネットワーク２８はチャネルを提供してもよく、これによりプログラムとアプリケーションは、それを受信器システム１６へと提供すべきソースシステム１２から要求されるが、これについては図４〜図８に関係して以下に詳細に説明する。
【００１５】
ソースシステム１２内において、ヘッドエンドシステム１８は外部ソースからのデータ（たとえばコンテンツ、コード及びアプリケーションデータ）を任意的に受信するように示される。図１Ｂは、一またはそれ以上のコンテンツソース３２と一またはそれ以上のアプリケーションソース３４にネットワーク３６（たとえばインターネット）を介して接続されたヘッドエンドシステム１８を示している。たとえば、コンテンツソース３２は、エンタテイメントコンテンツ（たとえば映画）のプロバイダ、あるいは実時間動的データ（たとえば天気情報）のプロバイダである。アプリケーションソース３４は、何らかの双方向テレビジョンアプリケーションのプロバイダであってもよい。たとえば一またはそれ以上のアプリケーションソース３４は、電子的プログラムガイド（ＥＰＧ）及びナビゲーションアプリケーション、メッセージング及び通信アプリケーショーン、情報アプリケーション、スポーツアプリケーション、および／またはゲームおよびゲーミングアプリケーションを提供する。
【００１６】
配信システム１４に戻って、この配信システム１４は一実施例においてはソースシステム１２から受信器システム１６へのデータの放送配信を支援する。配信システム１４は、衛星、ケーブル、地上またはデジタル加入者線（ＤＳＬ）ネットワーク、またはかかるネットワークまたは当業者に良く知られている他のネットワークの組み合わせを含む。
【００１７】
受信器システム１６は、一実施例において、配信システム１４を介してデータを受信するセットトップボックス（ＳＴＢ）３８と、ヘッドエンドシステム１８および任意の他の外部システムとの戻りチャネル通信のための典型的なモデム４０のような通信入出力インターフェースと、ユーザー入力装置４３（たとえばキーボード、遠隔制御、マウス等）と、セットトップボックス３８で受信されたコンテンツの表示のためにセットトップボックス３８に接続された表示装置４２とを含んで示されている。一つの典型的な実施例において、表示装置４２はテレビジョンセットであってもよい。通信入出力インターフェースはネットワーク２８の性質に従って選択されることが理解されるであろう。たとえば通信入出力インターフェース２８は、ケーブル戻りモジュール、ＤＳＬ戻りモジュール等を含む。
【００１８】
セットトップボックス３８は、三層のソフトウェア、すなわちオパレーティングシステム４４、ミドルウェア４６、および一またはそれ以上の双方向テレビジョンアプリケーション４８を実行する。ミドルウェア４６は、双方向テレビジョンアプリケーション４８を、各種のオペレーティングシステム４４の違いから、各種のセットトップボックス３８のハードウェアにおいて保護する。この目的のために、ミドルウェア４６は、ドライバーアプリケーションプログラムインタフェース（ＡＰＩｓ）と、双方向テレビジョンアプリケーション４８から受信された命令をセットトップボックスハードウェア（たとえばモデム、インターフェースポート、スマートカードリーダー等）によって理解される低級命令へ翻訳するためのライブラリーとを提供する。
【００１９】
図２は、ヘッドエンドシステム１８とセットトップボックス３８のアーキテクチャについてのより詳細を例示するブロック図であり、これはこの発明の典型的な実施例の一部として構成される。ことに図２は、モジュールのカローセルをサポートする放送サーバ２０を示しており、これは、マルチプレクサ５０へ入力を与える多数の並列路を含み、これら並列路のそれぞれがエンコーダ５２とパケタイザー５４を含んでいる。各エンコーダ５２は、一またはそれ以上のソースから入力を受信するように動作する。たとえばエンコーダ５２ａは、アプリケーションサーバ２２からストリームされたコードモジュールを受信するように示され、このサーバは順に一またはそれ以上のアプリケーションソース３４からアプリケーションデータを受信するように接続される。アプリケーションソース３４はヘッドエンドシステム１８に対して内部または外部であってもよい。同様にエンコーダ５２ｂは、一またはそれ以上のコンテンツソース３２からコンテンツデータを受信するように接続されて示され、このソースはヘッドエンドシステム１８に対して内部または外部であってもよい。
【００２０】
各放送サーバ２０は、入力をマルチプレクサ５０に提供するいかなる数のソース（たとえばアプリケーションおよび／またはコンテンツソース３４および３２）に接続されたいかなる数の並列路をも含むと理解されるであろう。さらに、ヘッドエンドシステム１８はいかなる数の放送サーバ２０を構成してもよい。
【００２１】
各エンコーダ５２は、たとえばモーションピクチャーエクスパートグループ（ＭＰＥＧ）比較アルゴリズムのような多数の圧縮アルゴリズムを利用してデータをエンコードするように動作する。各エンコーダ５２はまた、エンコードされる必要のあるデータに時間スタンプを与えるように動作してもよい。時間スタンプはマルチプレクサによって下流で調整される。あるデータタイプはエンコーディングを行うことができず、したがってエンコーダ５２を通過するかバイパスしてもよく、エンコードされない状態でパケタイザー５４に提供される。一実施例において、コードとほとんどのデータタイプはエンコーダ５２をバイパスしてもよい。
【００２２】
パケタイザー５４は、データを受信しこのデータを配信システム１４（たとえば放送チャネル）を介して最終的な送信を行う前にパケットへフォーマットするように接続されている。
【００２３】
各パケタイザー５４はパケットをマルチプレクサ５０に提供し、このマルチプレクサは配信システム１４を介して配信のための送信信号へパケットを多重化する。
受信器システム１６のセットトップボックス３８は、典型的には、ネットワーク入力（たとえばモデム）、ケーブル入力、衛星パラボラアンテナまたはアンテナへ結合され、送信信号、これは配信システム１４を介してヘッドエンドシステム１８から送られてきたものを受信する。それから送信信号は入力５６（たとえば受信器、ポート等）へ供給される。入力５６が受信器を含む場合には、入力５６はたとえば放送信号が放送される放送チャネルを選択するように動作するチューナ（不図示）を含む。ＤＳＬ環境においてはチューナは設けられないということが理解されるであろう。パケット化された送信信号は、その後、入力５６からデマルチプレクサ５８に供給され、アプリケーションと、送信信号を構成するコンテンツデータとをデマルチプレクスする。ことに、デマルチプレクサ５８は、コンテンツデータをオーディオおよびビデオレコーダ６０へ与え、アプリケーションデータをコンピュータシステム６４に与える。オーディオおよびビデオレコーダ６０はコンテンツデータをたとえばテレビジョン信号へとデコードする。たとえばオーディオおよびビデオでコーダ６０は、受信されたコンテンツデータを、国家テレビジョンシステム委員会（ＮＴＳＣ）、位相反転線（ＰＡＬ）、高精細度テレビジョン（ＨＤＴＶ）信号のような適当なテレビジョン信号へデコードする。テレビジョン信号はそれからオーディオおよびビデオレコーダ６０から表示装置４２へと与えられる。
【００２４】
コンピュータシステム６４は、プロセッサとメモリを含んでおり、デマルチプレクサ５８によってそれに与えられるアプリケーションデータから一またはそれ以上の双方向テレビジョンアプリケーションを再構成する。上述したように、このアプリケーションデータは、双方向テレビジョンアプリケーション４８によって用いられるアプリケーションコードおよび／またはアプリケーション情報の両方を含む。コンピュータシステム６４は、双方向テレビジョンアプリケーション４８を再構成することに加えて、かかるアプリケーション４８を実行してセットトップボックス３８に一またはそれ以上の動作を行わせる。たとえばコンピュータシステム６４は信号を表示装置４２に出力する。たとえばこのコンピュータシステム６４からの信号は、オーディオおよびビデオレコーダ６０から表示装置４２へ与えられた信号の結果として生ずる画像にオーバーレイされるべき画像またはグラフィカルユーザーインタフェース（ＧＵＩ）を構成する。ユーザ入力装置４３（たとえばキーボード、リモコン、マウス、マイクロフォン、カメラ等）が、入力をセットトップボックス３８に与えることをユーザーが可能となるように入力５６に接続されるように示される。かかる入力は、たとえば英数字、オーディオ、ビデオまたは制御（たとえばユーザーインターフェースに表れるオブジェクトの操作）入力である。
【００２５】
コンピュータシステム６４はオーディオおよびビデオデコーダ６０へ接続されて、コンピュータシステム６４がデコーダ６０を制御できるように示されている。コンピュータシステム６４は、デコーダ６０からオーディオまたはビデオ信号を受信し、この信号を生成された信号と結合してコンピュータシステム６４がその結合された信号を表示装置４２に提供できるようにしてもよい。
【００２６】
コンピュータシステム６４は出力６６（たとえば送信器、出力ポート等）へ結合されるように示され、この出力６６を介してセットトップボックス３８は出力データを戻りチャネル２８を介してたとえばヘッドエンドシステム１８のような外部システムへ提供できる。この目的で、出力６６は受信器システム１６のモデム４０へ接続されるように示される。
【００２７】
受信器システム１６が、図１Ａ、図１Ｂおよび図２において、表示装置４２に接続されたセットボックス３８を含むように示されており、受信器システム１６の要素は単一の装置（たとえばコンピュータシステム）に結合されるか、あるいは多数の独立のシステムに分散されるかであることは容易に理解できるであろう。たとえば別の受信器ユニットが、入力をセットトップボックス３８に提供し、これが次に表示装置４２に接続される。
【００２８】
図３は典型的なデータストリーム６８の図形的表示であり、この典型的な実施例によれば、データストリーム６８はヘッドエンドシステム１８において用いられる多数のマルチプレクサ５０の各々から出力されてもよい。典型的な双方向テレビジョン環境１０において、アプリケーションとコンテンツのデータは別のモジュールとして放送サーバ２０へ提供されても良い。たとえば、アプリケーションデータはディレクトリーモジュール７０、コードモジュール７２、データモジュール７４を構成してもよい。コンテンツ情報がコンテンツモジュール７６内に含まれてもよい。一実施例において、コードとデータモジュール間で区別がなく、データとコードは混合されてもよい。他の実施例において、モジュール７０〜７６の各々は特定のモジュールタイプであるとして一意に識別される。ディレクトリーモジュール７０は、それがさらなる情報なしにデータストリーム６８内で識別し得るようにユニークな識別子を有する。ディレクトリーモジュール７０は、さらに、特定の双方向テレビジョンアプリケーションを形成するコードモジュール７２やデータモジュール７４のような一またはそれ以上の他のモジュールのディレクトリを構成する情報を含む。したがって、セットトップボックス３８は、ディレクトリーモジュール７０を使って、双方向テレビジョンアプリケーションを組み立て実行するために必要な全てのコードモジュール７２および／またはデータモジュール７４を識別する。一実施例において、ディレクトリーモジュール７０は他のモジュールよりも前にアクセスされ処理され、これによりセットトップボックス３８がデータストリーム６８内に含まれる他のモジュールを正しく識別し解釈することができる。他の実施例において、ディレクトリーモジュール７０は、たとえばあるモジュールが自動実行または自動負荷モジュールであるかどうかを特定するために、各モジュールに付着されたフラグとモジュールのリストを検索するために用いられる。上述したように、ヘッドエンドシステム１８はカローセルを実行し、これによってモジュール７０〜７６が周期的、反復的な態様で送信される。
【００２９】
しばしば、受信器システム１６は、ネットワーク２８を介して、ソースシステム１２によって送信されるべき一またはそれ以上のモジュールの要求を送信する。一実施例によると、受信器システム１６はたとえば、図４に示されたマルチキャスト応答処理フロー４００に示されているように、要求されたモジュールをマルチキャストする。処理フロー４００は、受信器システム１６側とソースシステム１２側での処理を線４０３によって分離して図示する。
【００３０】
ブロック４１０において、受信器システム１６はソースシステム１２からのモジュールの要求を生成する。たとえば受信器システム１６は、上記の図３を参照して説明されたように、テレビジョンコマーシャルと関係したアプリケーションに関するモジュールを要求する。このコードモジュールは、コマーシャルの間広告される製品に関係した追加情報をユーザーが受け取ることを可能とする。
【００３１】
ブロック４２０において、ソースシステム１２は受信器システム１６からモジュールの要求を受信する。ブロック４３０において、ソースシステム１２は、上記要求を、モジュールを要求した受信器システム１６を含む複数の受信器（１５、１６、１７）へマルチキャストする。ブロック４４０、４５０において、受信器システム１５、１６は要求されたモジュールを受信する。この形態において、冗長的にモジュールの要求を受信しその要求されたモジュールを送信することの代わりに、ソースシステム１２はモジュールを一度にマルチキャストすることができる。さらに、同じマルチキャストを受信する多数の受信器システム（１５、１６、１７）は、同じモジュールを取得することができる。モジュールを要求した受信器システム１６はそれを受信する準備ができているであろうし、また、同じモジュールを要求する他の受信器システム（１５、１７）はそれを同様に取得する。これに加えて、他の受信器システム（１５、１７）は、図７および８に関係して以下に示されるように、必要とされるモジュールが特定の時間内にマルチキャストされることを決定する時に、その必要とされるモジュールを要求することを遅らせてもよい。他の代わりの実施例において、受信器システムは、一またはそれ以上のモジュールの要求をネットワーク上の他の受信器システムへマルチキャストしてもよく、これにより上記他の受信器システムは所定の期間、必要とされるモジュールを要求することを遅らせてもよい。この態様において、他の受信器システムは、必要とされるモジュールを待って、共通するモジュールの冗長な要求を送出しなくてもよい。一実施例において、受信器は所定のアプリケーションについてのモジュールのプレーリスト（play list）を記憶する。たとえば、プレーリストはアプリケーションと同時に送られてもよい。受信器がネットワーク上でモジュールのマルチキャストを検出した時、それらは次にプレーするモジュールをプレーリストから削除してもよい。サーバがプレーリストのどこにあるかを受信器が知るための他の典型的な方法は、タイミング情報（たとえばテレビジョンプログラムまたはアプリケーションがスタートしてからの時間、あるいはこのチャネルで放送された時計）に基づくものであってもよい。受信器は、どのモジュールが次に送信されるかを知るために、プレーリストと結合されたタイミング情報を用いることができる。
【００３２】
典型的な一実施例において、受信システムからの多数の要求は、単一の通信にまとめられあるいはグループ化されてもよい。単一の要求（またはまとめられた要求）は、いつ要求が対応されるべきかを示すタイミング情報を含む。たとえばこのタイミング情報は、要求が特定の時間よりも早く対応されるべきでない、あるいは要求が特定の時間よりも遅くなく対応されるべきでないということ等を示す。したがって、ソースシステム１２は、複数の要求の中の各要求に順次対応し、あるいは複数の要求の全てに一度に対応してもよい。典型的な一実施例において、ソースシステム１２は要求からタイミング情報を抽出し、そのタイミング情報に基づいてその要求に対応する。タイミング情報は、その要求が特定の時間よりも早くなくあるいは遅くなく対応されるべきことを示してもよい。
【００３３】
処理フロー４００は前方路上での帯域幅の利用を減少してもよく、これは要求されたモジュールが同時に多数の受信器システム（１５、１６、１７）によって取得されるからである、ということが理解されるであろう。また、帯域幅の利用は戻り路上で減少されてもよく、これは他の受信器によって要求されたモジュールを受信する受信器システム（１５、１６、１７）が同一モジュールの要求を送る必要がないからである。さらに、十分な記憶領域を有する受信器システムは、それらがモジュールを必要とさえする前に、モジュールをプリフェッチおよびキャッシュすることを決定できる。処理フロー４００は、その受信器によって必要とされないある受信器へ送られたデータの量を減少することによって、受信器システム１６のプロセッサ上での負荷を減少してもよい。これに加えて、処理フローは、サーバ側で要求される処理の量を減少してもよく、これはサーバがより少ない要求を処理し対応しなければならないからであろう。
【００３４】
多数のモジュールは、受信器システム１６で双方向テレビジョンタスクを実行するために必要とされる。たとえば双方向テレビジョンアプリケーションは、多数のアプリケーションコードモジュールへ分割されるか、または特定のデータモジュールに動作することを命じる。したがって、特定のモジュールの要求は、追加の関係するモジュールの追加の要求を開始してもよい。一実施例によると、受信器システム１６は、たとえば、図５に示されたパッケージ要求処理フロー５００に示されるように、複数のモジュールの要求を単一の要求へとパッケージ化する。処理フロー５００は、受信器システム１６側およびソースシステム１２側の処理を線５０３によって分離して示している。
【００３５】
ブロック５１０において、受信器システム１６はモジュールの必要性を決定する。たとえば受信器１６は、放送されているプログラムと関係した特定の双方向機能を行うために、ソースシステム１２からのコードモジュールを要求する必要がある。ブロック５２０において、受信器システム１６は、要求されたモジュールに関係する追加のモジュールを決定する。その例を続けると、受信器システム１６は、要求されたコードモジュールと関係する一つまたはそれ以上のデータモジュールを特定してもよい。典型的な一実施例において、受信器システム１６は、要求される関係するまたは追加のモジュールあるいは一連のモジュールを並べるアプリケーション特定リストを記憶する。一つの典型的な実行において、そのリストは（たとえば特定のモジュール内の）アプリケーションと同時に送られる。そのリストは、たとえばアプリケーションが終わる時に、他のアプリケーションコードおよびデータと同時に受信器メモリから廃棄される。
【００３６】
ブロック５３０において、受信器システム１６は、必要とされるモジュールと関連するモジュールの要求を生成する。ブロック５４０において、受信器システム１６はモジュールの要求をソースシステム１２に送信する。ブロック５５０において、サーバシステム１２はモジュールの要求を受信する。ブロック５６０において、ソースシステム１２は、要求されたモジュールを受信器システム１６を含む複数の受信器（１５、１６、１７）にマルチキャストする。ブロック５７０と５８０において、受信器システム１５、１６は要求されたモジュールを受信する。
【００３７】
処理フロー５００は、戻りチャネル２８上でのソースシステム１２への一連の要求の数を減少すると共に、配信システム１４を介した前方路上での受信器システム１２への一連の要求に対する応答の数を減少する。サーバファームは処理し対応する要求がより少なくなるので、要求を処理するために必要とされるサーバファームのサイズもまた減少してもよい。
【００３８】
受信器システム１２は、ブロック５２０に示されるように、関係するモジュールを必ずしも常に決定する必要はない。一実施例においてはむしろ、ソースシステム１２が、少なくとも一つの受信器から少なくとも一つのモジュールの要求を受信する時、一またはそれ以上の関連するモジュール（たとえば一連のモジュール）をマルチキャストするようにそのソースシステムが決定しても良い。たとえばアプリケーションが順次必要とされる一連のモジュールからなるならば、ソースシステム１２はこの一連のモジュールをマルチキャストするように決定することができる。たとえばソースシステム１２は、モジュールｎの要求が受信された時はいつでも、モジュールｎで開始する一連のモジュールをマルチキャストするように決定することができる。
【００３９】
図７、８を参照して以下にさらに説明されるように、一連の順番においてｐ＞＝ｎの場合、テレビジョン環境１０における他の受信器システムはモジュールｐの要求を送る必要がない。この態様において、もし受信器システム１５が、ネットワーク２８上の受信器システム１６によって送られたモジュールｎの要求を識別するか、あるいは配信システム１４上で送信されたモジュールｎを識別するならば、受信器システム１５はモジュールｐがモジュールｎの後で（必ずしも直後ではない）マルチキャストされることを認知する。したがって、一連の順番において、一つのモジュールをマルチキャストすることは他のモジュールがそれに続くということ（たとえば他のモジュールがその後直後または他のいずれかの時点でその後に続くということ）の告知を与え、したがって、受信器システム１５は、一連の順番においてｐ＞＝ｎの場合には典型的なモジュールｐの要求を必ずしも送る必要はない。他の実施例において、受信器システム（１５、１６、１７）は、他の受信器システム（１５、１６、１７）が共通のモジュールの冗長な要求をする必要がないように、配信システム１４上でモジュールのそれら要求をマルチキャストする。
【００４０】
一実施例において、そのような一連のモジュールは、特定のサービスに対して生成されたカローセルを分析することによって、オフラインまたはリアルタイムに自動的に生成されることができる。この考え方を使って、各モジュールは一度あるいは繰り返し送られることができる。（モジュールを繰り返す）前方路の帯域幅と（要求を送る）戻り路の帯域幅の間のトラフィックの最適化は、オフライン（たとえば送るべきモジュールのプレーリストを生成することあるいはカローセルを分析すること）またはリアルタイム（たとえばトラフィックを分析すること）のいずれかにおいて実行される。この技術は、コスト、飽和、およびパフォーマンスのような基準に基づいて前方および戻り路の帯域幅の使用を最適化することを可能とする。リアルタイム最適化技術の一例は、最も高い優先度が明白な要求に対して与えられるよう、要求されたコンテンツを放送することである。そのカテゴリにおいて、データまたはモジュールがより多く要求されるほど、それが直ちに放送される機会がより高まることとなる。ここで、明白な要求がない時には、帯域幅は、最も要求される可能性のあるデータまたはモジュールをカローセルにおいて送信するために使用されてもよい。これらの場合において、要求の人気度および最後に送信された日付に基づく優先度を用いることもできる。
【００４１】
他の実施例において、受信器システム１６は、ネットワーク（たとえばピアトゥピアネットワーク環境）上の他の受信器システム（１５、１７）からの一またはそれ以上のモジュールを要求し取得してもよい。たとえば図６に、放送要求処理フロー６００の一実施例を示す。処理フロー６００は、受信器システム１６の側と受信器システム１７の側における処理を線６０３によって分離して示す。
【００４２】
ブロック６１０において、受信器システム１６は、モジュールの要求を受信器システム１７を含む複数の受信器へマルチキャストする。ブロック６２０において、受信器システム１６はモジュールの要求を受信する。ブロック６２５において、受信器システム１７はたとえばそのローカルキャッシュ内で、要求されたモジュールを検出してもよい。もしそうであるなら、ブロック６３０において、受信器システム１７が複数の受信器システム（受信器システム１５および１６を含む）へ、要求されたモジュールをマルチキャストする。ブロック６４０と６５０において、受信器システム１５および１６は要求されたモジュールを受信する。典型的な一実施例において、全ての受信器が要求に応答することを禁止するために、他の受信器によってマルチキャストされたモジュールの要求に対して受信器は対応しない。その結果として、全てのモジュールが対応されている時は、全ての受信器が自動的に応答することを停止する。ピアトゥピア／クライアントサーバの結合されたモデルにおいては、サーバはピアと同一の戦略を適応する。
【００４３】
上述したように、ネットワーク上の受信器システム（１５、１６、１７）は、どのモジュールが要求されたかあるいは特定の時間枠内にソースシステム１２によって送信されるように予定されたかを知ることによって利益を得る。図７は、所定期間内にソースシステム１２から送られるべきモジュールのリストを送信するためのマルチキャスト処理フロー７００のためのモジュールスケジュールの一実施例を示す。処理フロー７００は、ソースシステム１２と受信器システム１６の処理を線７０３で分離して図示する。
【００４４】
ブロック７１０において、ソースシステム１２は、複数の受信器システムへマルチキャストされるべく予定されたモジュールのリストを生成する。モジュールのリストは、特定のモジュールがいつ送信されるかについてのタイミング情報を含む。このリストは、たとえば特定のサービスのために生成されたカローセルを分析することによって、オフラインまたはリアルタイムに生成されてもよい。このリストがオフラインで生成される例としては、テレビジョンプログラムが事前に録画されたクイズゲームショーである場合がある。アプリケーションは視聴者がゲームショーと共に遊ぶことを可能とする。各質問および回答の組が、分離されたモジュールで送信されてもよい。そのリストは、特定の質問がまさに答えられようとする時、ショーを見ながらショーの開始からの時間を書き留めることによって生成される。
【００４５】
ブロック７２０において、受信器システム１６はソースシステム１２からのモジュールのリストを受信する。ブロック７３０において、受信器システム１６は、必要とされるモジュールがリストに存在するかどうかを決定する。もし受信器システム１６が、必要とされるモジュールがモジュールのリスト内にあると決定したならば、制御はブロック７４０へ移る。もし受信器システム１６が、必要とされるモジュールがモジュールのリストの中に無いと決定したならば、制御はブロック７５０に移る。
【００４６】
ブロック７４０において、受信器システム１６は、必要とされるモジュールがモジュールのリストの中にありソースシステム１２からモジュールがマルチキャストされるのを待つことを決定する。受信器システム１６は、リストに記憶された情報に基づいて特定の放送チャネル上でおよび／または特定の時間にマルチキャストされるべきモジュールを待つ。一実施例において、受信器システム１６は特定量の時間内に、必要とされるモジュールを受信しないならば、制御はブロック７５０へ移る。ブロック７５０において、受信器システム１６が要求を生成し送信する。ソースシステム１２はそれがマルチキャストする（必要なら、いつ特定のモジュールが送信されるかについてのタイミング情報とともに）モジュールのリストをマルチキャストし、その結果、送信されるいくつかのモジュールを必要とする他の受信器システムはこれらモジュールの要求を送信する必要がない。この態様において、処理フロー７００はネットワーク２８上のトラフィックを減少し、要求を処理するために必要とされるサーバファームの大きさも減少する。
【００４７】
さらに他の実施例において、受信器システム１６は、カローセルに存在する可能性のある全てのモジュールをリストするディレクトリーを受信する。図８は送信ディレクトリー処理フロー８００の一実施例を図示する。処理フロー８００は、ソースシステム１２と受信器システム１６の処理を線８０３によって分離して図示する。
【００４８】
ブロック８１０において、ソースシステム１２はディレクトリーを生成する。そのディレクトリーは、カローセルに現在存在するモジュールのリスト、カローセルによって後に送信されるモジュールのリスト、または特定の時間内に送信されないであろうモジュールのリストを含む。たとえば、いくつかのカローセルのフォーマット（これはＯｐｅｎ  ＴＶ  およびＤＳＭ−ＣＣ（デジタル記憶メディア―命令および制御）を含む）は、カローセルに存在する可能性のある全てのモジュールをリストするディレクトリーを送信する。
【００４９】
ブロック８２０において、ソースシステム１２はディレクトリーを複数の受信器システムへマルチキャストする。ブロック８３０において、受信器システム１６はディレクトリーを受信する。ブロック８４０において、受信器システム１６は、特定の動作を行うかどうかを決定するためにディレクトリーにアクセスする。たとえば３０秒スポットを越えて双方向宣伝を行う場合、受信器システム１６はアプリケーションを送信しないと決定するか、または特定のモジュールが送信されない場合または視聴者がそのスポットの中にあまりにも遅くコマーシャルへ戻った場合に、アプリケーションは終了することを決定する。典型的な一実施例において、処理フロー７００のリストは、必ずしもそのアプリケーションの全時間にわたってカバーする必要はない。モジュールがリストの中に存在しないことは、それが後では決して送れないということを意味するものではない。その結果として、この典型的な実施例において、受信器システムはリスト内に表れないモジュールの要求をサーバへ送出する。しかしながら、典型的な処理フロー８００において、そのリストはアプリケーションの全時間をカバーする。もし、モジュールが再び送られることは決してないものとしてリストの中に記述されるか、そのリストの中に存在しないならば、これはそのアプリケーションがそのモジュールを将来受信すると期待すべきでないことを意味する。この結果として、アプリケーションはそのリストにしたがってモジュールが決して送信されないことを知る必要があるならば、たとえばそのアプリケーションは終了することを決定する。この手法は戻り路に接続されていないまたはサーバへ要求を送っていない受信器システムにもまた適用されることに注意すべきである。
【００５０】
結論として、この発明の上述した実施例は、ソースシステム１２に送られるモジュールの冗長な要求と、モジュールが前方路上で複数の受信器に送信される回数とを減少する。さらにこの発明の一実施例は、モジュールが特定の時間内にソースシステム１２から送られるべきかを受信器が決定できるようにし、これにより受信器はソースシステム１２からのモジュールを待つか要求するかを決定する。
【００５１】
図９は、コンピュータシステムの典型的な形態におけるマシンを示すブロック図であり、その中においてマシンがここで述べられた一またはそれ以上の手法を行うような一連の命令が実行される。
【００５２】
このマシンはスタンドアロンまたは他のマシンに接続（たとえばネットワークを介して）してもよい。ネットワークの構成において、このマシンはサーバクライアントネットワーク環境におけるサーバまたはクライアントマシンの能力内で動作し、あるいはピアトゥピア（または分散）ネットワーク環境におけるピアマシンとして動作してもよい。このマシンは、サーバ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、個人用デジタル補助具（ＰＤＡ）、携帯電話、ウェブ装置、ネットワークルーター、スイッチまたはブリッジ、またはそのマシンによって行われるべき動作を特定する一組の命令（連続的あるいはそうでないもの）を実行することができるいかなるマシンであってもよい。さらに、一つのマシンだけが例示されているが、「マシン」という用語は、ここで議論された一つまたはそれ以上の手法を行うための一組（複数の組）の命令を個別にまたは一緒に実行するいかなるマシンの集合をも含むものとして理解されてもよい。
【００５３】
典型的なコンピュータシステム９００は、プロセッサ９０２（たとえば中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、あるいはその両方）、主メモリ９０４、および静的メモリ９０６を含み、これらは互いにバス９０８を介して通信している。コンピュータシステム９００は、さらにビデオ表示装置９１０（たとえば液晶表示装置（ＬＣＤ）または陰極線管（ＣＲＴ））を含む。コンピュータシステム９００はまた、英数字入力装置９１２（たとえばキーボード）、ユーザーインターフェース（ＵＩ）ナビゲーション装置９１４（たとえばマウス）、ディスク駆動装置９１６、信号生成装置９１８（たとえばスピーカ）、およびネットワークインターフェース装置９２０も含む。
【００５４】
ディスク駆動装置９１６は、ここに述べられた一またはそれ以上の手法または機能を実現する一またはそれ以上の組の命令（たとえばソフトウェア９２４）が記憶されるマシン読み取り可能媒体９２２を含む。ある実施例において、各種の機能を実行するために必要とされるコードは、フラッシュに記憶された内蔵ソフトウェアであってもよく、アプリケーションコードとデータがネットワークからＲＡＭへロードされてもよい。ソフトウェア９２４はまた、完全にまたは少なくとも一部が、主メモリ９０４内に存在してもよく、またはコンピュータシステム９００によって実行される間はプロセッサ９０２内に存在してもよく、この時、主メモリ９０４およびプロセッサ９０２は（マシンによって直接または間接に実行される）マシン読み取り可能媒体を構成する。
【００５５】
ソフトウェア９２４は、さらに、ネットワークインターフェース装置９２０を介してネットワーク９２６上で送受信されてもよい。
マシン読み取り可能媒体９２２は、典型的な実施例では、単一の媒体として示されるが、「マシン読み取り可能媒体」という用語は一またはそれ以上の組の命令を記憶する単一の媒体または複数の媒体（たとえば集中化または分散化されたデータベース、および／またはそれに関連するキャッシュおよびサーバ）を含むものと理解されるべきである。「マシン読み取り可能媒体」という用語はまた、マシンによる実行のための一組の命令を記憶し、エンコードし、実行することが可能な媒体であって、マシンに本発明の一またはそれ以上の手法を実行させる何らかの媒体を含むものと解釈されるべきである。
【００５６】
かくして、双方向テレビジョン環境においてコンテンツを要求する方法および装置が記述された。この発明は特定の典型的な実施例を参照して述べられているが、この発明のより広い権利範囲から逸脱することなく各種の変形および変更がこの実施例に加えられてもよいことは明らかである。したがって、明細書と図面は限定的意味ではなく例示的意味として考えられるべきである。
【図面の簡単な説明】
【００５７】
【図１Ａ】図１Ａは、この発明が構成される典型的な双方向テレビジョン環境を示す図である。
【図１Ｂ】図１Ｂは、ソースシステムと受信器システムの典型的な詳細を表す双方向テレビジョン環境を示す図である。
【図２】図２は、この発明の典型的な実施例による、ヘッドエンドシステムとセットトップボックスに関するアーキテクチャの詳細を提供するブロック図である。
【図３】図３は、この発明の一実施例による、ヘッドエンドシステムのマルチプレクサから出力されるデータストリームを表わす図である。
【図４】図４は、この発明の典型的な実施例による、モジュールの要求に対する応答を双方向テレビジョン環境における複数の受信器システムにマルチキャストするための方法を示すフローチャートである。
【図５】図５は、この発明の典型的な実施例による、多数のモジュールの要求を双方向テレビジョン環境上で送信される単一要求へとパッケージ化するための方法を図示するフローチャートである。
【図６】図６は、この発明の典型的な実施例による、双方向テレビジョン環境におけるモジュールのマルチキャスト要求への応答をマルチキャストする方法を示すフローチャートである。
【図７】図７は、この発明の典型的な実施例による、双方向テレビジョン環境におけるソースシステムからマルチキャストされるべきモジュールのリストをマルチキャストする方法を示すフローチャートである。
【図８】図８は、この発明の典型的な実施例による、双方向テレビジョン環境におけるソースシステムから将来において送信されるあるいはされないモジュールのディクレクトリーをマルチキャストするための方法を例示するフローチャートである。
【図９】図９は、ここに述べられた方法をマシンに行わせる一連の命令を記憶し実行する、コンピュータシステムの典型的な形態におけるマシンを例示するブロック図である。
【図１Ａ】
2008522490.tif 000003
【図１Ｂ】
2008522490.tif 000004
【図２】
2008522490.tif 000005
【図３】
2008522490.tif 000006
【図４】
2008522490.tif 000007
【図５】
2008522490.tif 000008
【図６】
2008522490.tif 000009
【図７】
2008522490.tif 000010
【図８】
2008522490.tif 000011
【図９】
2008522490.tif 000012
【国際調査報告】
2008522490.tif 000013