JP2006500826A - ブロードキャスト・カルーセルによってｈｔｔｐサーバをエミュレーションする方法とシステム - Google Patents

Abstract

対話型テレビジョン・システムでは、対話型テレビジョン受信機はブロードキャスト・パスを介してカルーセルを受信する。ブロードキャスト・サーバはカルーセル・マネージャを実行でき、カルーセル・マネージャはカルーセルを構築する際に使用するブロードキャスト・ポリシーを策定する。対話型テレビジョン受信機はアプリケーション・プログラムからのリソース要求を処理するインターフェース・モジュールを実行する。インターフェース・モジュールは要求されたリソースをブロードキャスト・パスまたはポイントツーポイント・パスから取得する。

Description

本発明は、一般に対話型テレビジョン分野に関する。より詳細には、本発明は、対話型テレビジョン・システム内でリソースを送受信する方法とシステムに関する。

対話型テレビジョンなどのブロードキャスト環境では、一般にブロードキャスト・サーバがブロードキャスト・パスで同報通信する１組のリソースを決める。ブロードキャスト・パスは通常片方向性で、リソースが１つまたは複数の受信機に同報通信される。対話型テレビジョン受信機は普通、最終的にリソースをユーザに対して表示できるテレビジョンまたはその他のディスプレイ・デバイスに接続される。受信機はポイントツーポイント・パスを用いてブロードキャスト・サーバとも通信でき、高速のブロードキャスト・パスでは利用できないリソースを検索するためにポイントツーポイント・パスを用いることができる。

対話型テレビジョン環境で使用可能な１つのタイプのリソースはハイパーテキスト・マークアップ言語（「ＨＴＭＬ」）リソースである。ＨＴＭＬアプリケーションは、ユニフォーム・リソース・ロケータ（「ＵＲＬ」）またはユニフォーム・リソース識別子（「ＵＲＩ」）などの一意的な識別子によって参照されるいくつかのリソースから構成できる。これらの識別子は、ＨＴＭＬアプリケーションを記憶できるサーバまたはその他のコンピュータなどのリソースをポイントする。

アプリケーションは、例えば、ＨＴＭＬやＪａｖａｓｃｒｉｐｔなどのスクリプト言語で記述し、ハイパーテキスト転送プロトコル（「ＨＴＴＰ」）サーバを用いて受信者に発行される。ブラウザなどのソフトウェア・コンポーネントは、アプリケーションを受信し、アプリケーションのリソースを表示できる。ＨＴＭＬリソースを供給するために、ＨＴＭＬブラウザは通常、ＵＲＬ（例えば）などの識別子によって指定されたサーバとの接続を確立し、リソースをフェッチする。ＨＴＭＬブラウザとアプリケーション・サーバ間の通信方式は、一般に、ポイントツーポイント方式であり、ＨＴＭＬブラウザがサーバとの双方向通信を確立する。この方式は対話型テレビジョン環境の片方向ブロードキャスト・パスとは対照的である。

デジタルＴＶが可能にしたアプリケーションの一例は、対話型テレビジョンである。対話型テレビジョン・サービスでは、ＨＴＭＬブラウザはデジタルＴＶデバイス上で動作する。アプリケーションは、当該アプリケーションを発行するサーバとの接続を確立することでデジタルＴＶデバイスに接続されたディスプレイ上に表示される。テレビジョン専用ではあるが、ＨＴＭＬブラウザに基づくデジタルＴＶ環境はブロードキャスト環境の多くの利点を有しない。

ブロードキャスト環境でＨＴＴＰリソースを実現する１つの方法は、片方向ハイパーテキスト転送プロトコル（「ＵＨＴＴＰ」）の使用である。ＵＨＴＴＰはリソースを同報通信し、ローカルに記憶する方法を可能にする。ＵＨＴＴＰでは、ＵＨＴＴＰサーバが受信者のローカル・キャッシュが満杯になるかすべてのデータを送信するまで受信者のローカル・キャッシュを送信する。ＵＨＴＴＰの欠点は、受信者に送信できるデータ量が受信者のローカル記憶容量に制限されるということである。現在使用されている多くの対話型テレビジョン受信機は、メモリ容量が制限されている。したがって、ＨＴＴＰリソースを処理するためにＵＨＴＴＰが使用するローカル・キャッシング戦略はメモリが小さい対話型テレビジョン受信機の効率を制限するので不利である。

さらに、対話型テレビジョン受信機は、ポイントツーポイントまたはブロードキャスト・パスを介してリソースを要求することができる。ただし、ＵＨＴＴＰシステムでは、アプリケーションがブロードキャスト・パスにリソースを要求する場合に特定の文法を用いることが必要である。ブロードキャスト・パス上の要求に使用される文法はポイントツーポイント・パス上のリソースの要求の文法とは異なる。この文法の相違の結果、対話型テレビジョン受信機がブロードキャスト・パスを介して利用できないリソースをブロードキャスト・パスを介して要求することがある。

したがって、対話型テレビジョン環境でリソースを送受信する新しい改良型システムの方法が必要である。

本発明の一実施態様では、対話型テレビジョン・システム内のリソース要求を処理する方法が実現される。インターフェース・モジュールが対話型テレビジョン受信機上で走る。インターフェース・モジュールはアプリケーション・プログラムからリソース要求を受信する。インターフェース・モジュールは、リソースがブロードキャスト・パスとポイントツーポイント・パスのどちらで利用可能かを決定し、アプリケーション・プログラムから受信した要求をブロードキャスト・パスまたはポイントツーポイント・パスが使用するフォーマットに変換する。インターフェース・モジュールはブロードキャスト・パスとポイントツーポイント・パスからリソースを得て、リソースをアプリケーション・プログラムに供給する。

本発明の上記およびその他の態様と利点とは、添付図面を参照しながら以下の詳細な説明を読むことで当業者には明らかになろう。

本明細書で本発明の実施形態について図面を参照しながら説明する。

対話型テレビジョンのアーキテクチャ
対話型テレビジョンは、テレビジョンに対話型コンテンツを送信する方法を実現する。対話型テレビジョン・システムは、テレビジョンにテキスト、音声、映像、ハイパーテキスト転送プロトコル（「ＨＴＴＰ」）リソース、またはその他のコンテンツを供給でき、テレビジョン・ユーザからの入力を受信することもできる。

図１は対話型テレビジョン・システム６２のアーキテクチャの例を示す図である。ブロードキャスト・サーバ５０はブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に情報を送信する。ブロードキャスト・サーバ５０はデータ・リンクに沿って情報を送信できる任意のコンピュータまたはその他のタイプのサーバである。ブロードキャスト・サーバ５０は好ましくはプロセッサとメモリとを含む。プロセッサはメモリ内に記憶できるプログラムを実行する。さらに、メモリは、ブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に同報通信するコンテンツを含む。

ブロードキャスト・パス５２は任意のタイプのデータ・リンクで、様々な異なるフォーマットでデータを搬送する。好ましい実施形態では、ブロードキャスト・パス５２はケーブル・テレビジョン・プロバイダからテレビジョン５６にケーブル・テレビジョン信号を送信するためのケーブル・テレビジョン伝送パスである。ブロードキャスト・パス５２を介して送信されるデータはパスに沿ってケーブル・テレビジョン信号を送信するための信号プロトコルを使用することができる。

別の実施形態では、ブロードキャスト・パス５２は、無線直接衛星伝送システムを含む。衛星からテレビジョン５６にリンクした衛星用アンテナまたはその他の受信機まで無線で信号が送信される。衛星用アンテナによって受信された信号はデータ・リンクを介してテレビジョン５６または対話型テレビジョン受信機５４に搬送される。さらに別の実施形態では、ブロードキャスト・パス５２は無線通信ネットワークの一部である。例えば、１つまたは複数の地上アンテナを用いてブロードキャスト・パスを介して信号をテレビジョンに送信できる。ブロードキャスト・パス５２上でデータを送信する無線および有線の伝送方法の組み合わせを使用することも当然可能である。

対話型テレビジョン受信機５４は、対話型テレビジョン・システムのブロードキャスト・パス５２に接続され、ブロードキャスト・パス５２を介して送信される対話型テレビジョン信号を受信する。対話型テレビジョン受信機５４は普通、プロセッサとメモリとを含む。対話型テレビジョン受信機５４はそのメモリに記憶されたプログラムを実行し、ブロードキャスト・パス５２を介してブロードキャスト・サーバ５０から受信するプログラムを実行する。好ましい実施形態では、対話型テレビジョン受信機５４はテレビジョン５６に接続された当技術分野でよく知られているタイプのセットトップ・ボックスを含む。ただし、コンピュータ、ゲーム・コンソール、またはべつのプログラマブル・デバイスなどの、テレビジョン５６に接続された別のデバイスも対話型テレビジョン受信機５４として動作することができる。対話型テレビジョン受信機５４はテレビジョン５６とは別のコンポーネントとして図示されているが、代替形態では、対話型テレビジョン受信機５４のすべてまたは一部の機能をテレビジョン５６に組み込むことができる。さらに別の実施形態では、対話型テレビジョン受信機５４の機能をテレビジョン５６に接続された複数のコンポーネントに分散することができる。

対話型テレビジョン受信機５４はテレビジョン５６に接続され、ブロードキャスト・サーバ５０とテレビジョン５６との間のインターフェースを用意する。例えば、対話型テレビジョン受信機５４はテレビジョン５６に直接ケーブル・テレビジョン信号を送信することができ、これによってケーブル・テレビジョン信号を通常に視聴できる。ただし、対話型テレビジョン受信機５４はブロードキャスト・サーバ５０から送信される対話型テレビジョン信号を受信して処理することができる。

例えば、対話型テレビジョン受信機５４は、対話型テレビジョン信号をテレビジョン５６が認識するフォーマットに変換できる。例えば、ブロードキャスト・サーバ５０から送信される対話型テレビジョン信号は圧縮解除または復号化することができる。対話型テレビジョン受信機５４は、復号化と圧縮解除を実行して元の信号を復元し、これらの信号についてその他の処理を実行することができる。対話型テレビジョン受信機５４は、表示する適切なフォーマットに変換された対話型テレビジョン・コンテンツを、表示するためにテレビジョン５６に送信する。ユーザは、テレビジョン５６に表示される対話型テレビジョン・コンテンツを視聴できる。

対話型テレビジョン受信機５４はさらに入力デバイスを含むことができる。例えば、対話型テレビジョン受信機５４は、ユーザがテレビジョン５６や対話型テレビジョン受信機５４と対話するためのキーボード、マウスまたはその他のデバイスを含むことができる。入力デバイスを使用することで、ユーザは、例えば、テレビジョン５６に表示されるデータに応答できる。ユーザの選択項目を用いてテレビジョン５６に表示されるコンテンツを対話形式で駆動し、対話型テレビジョン・システムを実現することができる。

一例では、対話型テレビジョン・システムはユーザにウェブ・ブラウジング・セッションを実現する。対話型テレビジョン受信機５４は、ブロードキャスト・サーバ５０を介してインターネット６０に接続し、対話型テレビジョン受信機５４は適切なブラウザを実行する。対話型テレビジョン受信機５４はブロードキャスト・サーバ５０からインターネット６０を介してインターネット・コンテンツを受信する。対話型テレビジョン受信機５４はブラウザを用いてインターネット・コンテンツをテレビジョン５６に表示する。ユーザはキーボード、マウスまたはその他の入力デバイスを用いて異なるウェブ・ページまたはリンクにブラウズし、テレビジョン５６と対話できる。

対話型テレビジョン・システムでは、ブロードキャスト・パス５２は通常片方向であるが、対話型テレビジョン・システムでは双方向ブロードキャスト・パスも使用できる。ブロードキャスト・パス５２はケーブル・テレビジョン・サービスを供給するためのパスと同じでよく、ケーブル・テレビジョン・サービスは一般に片方向である。ケーブル・テレビジョン・システムでは、信号はケーブル・テレビジョン・サーバからテレビジョン５６に送信される。ケーブル・テレビジョン・サーバからテレビジョン５６への送信中に、ケーブル・テレビジョン信号はルータ、リピータまたはその他のネットワーク・デバイスを通過することができる。ケーブル・テレビジョン・システムはテレビジョン５６からの返送情報を必要としないので、ネットワーク要素は普通、片方向通信のみをサポートするように構成されている。したがって、データはケーブル・テレビジョン回線からブロードキャスト・サーバ５０に「返送」されることはない。

直接衛星伝送システムにおける信号は送信塔から衛星に送信され、究極的にテレビジョン５６に接続された衛星用アンテナまたはその他のデバイスによって受信される。衛星用アンテナは一般に衛星からの信号のみを受信し、衛星に信号を送信しない設備を備える。同様に、衛星は様々な加入者から送信される信号を受信するようには構成されていない。

対話型テレビジョン・システム６２内で双方向通信を可能にするために、対話型テレビジョン受信５４は返送パスとも呼ばれるポイントツーポイント・パス５８を使用する。ポイントツーポイント・パス５８は通常ブロードキャスト・パス５２とは異なる。ポイントツーポイント・パス５８は任意の数のデータ・リンクであるが、普通ポイントツーポイント・パス５８は電話回線、ケーブル・モデム、またはその他の双方向リンクである。ポイントツーポイント・パス５８はセルラ・ネットワークなどの無線リンクでもよい。

ポイントツーポイント・パス５８は対話型テレビジョン受信機５４に接続する。図１に示すように、ポイントツーポイント・パス５８はインターネット６０に接続する。この手順は、例えば、電話回線を介してインターネット・サービス・プロバイダ（「ＩＳＰ」）に接続することで実行される。次いでＩＳＰはインターネット６０に接続する。インターネット６０に接続すると、対話型テレビジョン受信機５４はインターネット６０に接続された他のデバイスにアクセスできる。例えば、対話型テレビジョン受信機５４はインターネット６０に接続されたサービス・プロバイダ６４と通信できる。対話型テレビジョン受信機５４はポイントツーポイント・パス５８を介してインターネット６０にメッセージを送信でき、このメッセージは究極的にサービス・プロバイダ６４にルーティングされる。

同様に、対話型テレビジョン受信機５４はインターネット６０または接続先の別のネットワークを介してブロードキャスト・サーバ５０と通信できる。こうして、ブロードキャスト・サーバ５０と対話型テレビジョン受信機５４との間に双方向通信リンクが形成される。ブロードキャスト・サーバ５０は好ましくはブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に情報を送信する。これはブロードキャスト・パスはポイントツーポイント・パス５８よりも一般に高速であることが理由である。対話型テレビジョン受信機５４はポイントツーポイント・パス５８を用いてブロードキャスト・サーバ５０に情報を送信することができる。

図１はインターネット６０に接続するポイントツーポイント・パス５８を示すが、別のネットワークまたはブロードキャスト・サーバ５０に直接接続することもできる。次いで、対話型テレビジョン受信機５４はポイントツーポイント・パス５８を介して対話型テレビジョン受信機５４にリンクされた他のデバイスと通信することができる。別の実施形態では、ポイントツーポイント・パス５８はブロードキャスト・パス５２と同じでよい。

ブロードキャスト・カルーセル
ブロードキャスト・サーバ５０は以下にカルーセルと呼ぶデータ・フロー構造を用いてブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に対話型テレビジョン・コンテンツを送信する。対話型テレビジョン受信機５４はブロードキャスト・サーバ５０から送信された対話型テレビジョン・コンテンツを記憶するためのメモリを含むことができる。ただし、対話型テレビジョン受信機５４内のメモリは限られている場合がある。したがって、対話型テレビジョン受信機５４はそのメモリ内に対話型テレビジョンのアプリケーションの全体または対話型テレビジョン・コンテンツすべてを記憶することはできない。にもかかわらず、ブロードキャスト・サーバ５０はカルーセルを用いて対話型テレビジョン受信機５４内の限られたメモリにもかかわらず対話型テレビジョン・コンテンツを送信することができる。

カルーセルは定期的に対話型テレビジョン受信機５４に送信するために分割されたデータ・ストリームとして実装できる。データの周期的、すなわち、定期的な送信によって、対話型テレビジョン受信機５４はカルーセルの周期にメモリ内にないデータを検索することができる。すなわち、対話型テレビジョン受信機５４は、限られたメモリ内に入らない部分はカルーセルの周期的な送信中に利用できるため、プログラム全体を記憶する必要はない。対話型テレビジョン受信機５４は、カルーセルからデータの一部を引き出すことでテレビジョン・コンテンツを検索し、記憶し、表示することができる。

カルーセルを形成するプロセスの一例では、ブロードキャスト・サーバ５０は対話型テレビジョン受信機５４にどのデータを送信するかを最初に決定する。データは対話型テレビジョン受信機５４上で実行するアプリケーションでもよく、ウェブ・ブラウザ・セッションのためのウェブ・ページでもよく、対話型テレビジョン・システム６２がサポートするその他の多数のタイプのデータであってもよい。次いでブロードキャスト・サーバ５０はデータをモジュールに分割する。モジュールは、一般に、ブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に送信するより小さいデータ部分である。データをモジュールに分割する処理に加えて、ブロードキャスト・サーバ５０はさらにカルーセル・ディレクトリ１１２を形成する。カルーセル・ディレクトリ１１２はカルーセル・モジュールのリストを含む。カルーセル・ディレクトリ１１２を用いて対話型テレビジョン・アプリケーションはリソースを得るためにカルーセルのどの部分にアクセスするかを決定する。カルーセル・アドレスはカルーセル内のリソースのロケーションを識別する。

モジュールが対話型テレビジョン受信機５４に送信され、対話型テレビジョン受信機５４は対話型テレビジョン・システム６２内で使用するモジュールを記憶する。対話型テレビジョン受信機５４内の利用可能なメモリは限られているので、モジュールは循環式に対話型テレビジョン受信機５４に連続的に送信される。必要に応じて、対話型テレビジョン受信機５４はブロードキャスト・パスからモジュールを検索し、以前に受信した１つまたは複数のモジュールを最近受信したモジュールで書き換えることができる。

このようにモジュールを送信することで、対話型テレビジョン受信機５４は任意の所与の時間にモジュールの一部のみを記憶できる。対話型テレビジョン受信機５４はメモリ内にないモジュールにアクセスする必要がある時には、連続した循環式のカルーセル送信の一部としてモジュールが送信されるまで短時間待つだけでよい。この結果、大容量のアプリケーションを収容する対話型テレビジョン受信機５４内に必要なメモリ量を削減することができる。

図２は対話型テレビジョン・アプリケーションを６つのモジュール１００、１０２、１０４、１０６、１０８、１１０に分割する例を示す。各モジュールはアプリケーションの１つまたは複数の部分を含む。各モジュールは異なる情報量を保持できるので、モジュールのサイズは異なる場合がある。対話型テレビジョン・アプリケーションの部分を保持することに加えて、モジュールは制御情報、ヘッダ情報、またはその他のデータを含むことができる。対話型テレビジョン・アプリケーションを６より少ないモジュール、または多いモジュールに分割でき、対話型テレビジョン・モジュールが１つまたは複数の完全なまたは部分的な対話型テレビジョン・アプリケーションを保持することができることは当然である。６つのデータ・モジュール１００、１０２、１０４、１０６、１０８、１１０に加えて、カルーセル・ディレクトリ１１２も作成される。カルーセル・ディレクトリ１１２は対話型テレビジョン・アプリケーションの６つのデータ・モジュール１００、１０２、１０４、１０６、１０８、１１０への分割の一般リストを含む。

図３はブロードキャスト・パス５２を介したカルーセル内のモジュールの対話型テレビジョン受信機５４への送信順序の例を示す。第１に、カルーセル・ディレクトリ１１２が対話型テレビジョン受信機５４に送信される。次に、ｍｏｄｕｌｅ＿１ １００と、ｍｏｄｕｌｅ＿２ １０２が対話型テレビジョン受信機５４に送信される。次いで、カルーセル・ディレクトリ１１２が再送信され、ｍｏｄｕｌｅ＿３ １０４と、ｍｏｄｕｌｅ＿４ １０６が送信される。さらに、カルーセル・ディレクトリ１１２が再送信され、ｍｏｄｕｌｅ＿５ １０８と、ｍｏｄｕｌｅ＿６ １１０が送信される。ｍｏｄｕｌｅ＿６ １１０の送信に続いて、周期はカルーセル・ディレクトリ１１２とｍｏｄｕｌｅ＿１ １００の送信の繰り返しを開始する。図３に記載する順序は単に例示に過ぎず、他の送信順序も使用できる。

対話型テレビジョン受信機５４は対話型テレビジョン・アプリケーション内のすべてのモジュールを記憶するのに十分なメモリを有する場合があるが、そのメモリは限られている場合が多く、カルーセル・モジュール１００、１０２、１０４、１０６、１０８、１１０の一部しか記憶できないことがある。例えば、対話型テレビジョン受信機５４が図３に記載するカルーセルを受信し、対話型テレビジョン受信機５４は３つのモジュールを同時に実行するだけのメモリしか有していないことがある。

対話型テレビジョン受信機５４の限られたメモリに適応するために、カルーセル・モジュールは対話型テレビジョン受信機５４に連続的に送信する。対話型テレビジョン受信機上で実行されているアプリケーションがモジュールを必要とする時は、カルーセルからモジュールを得ることができる。次いで、モジュールを取得してメモリ内に記憶する。同様に、アプリケーションが別のモジュールを必要とする時は、モジュールを取得してそのメモリ内に記憶することができる。したがって、アプリケーションが要求した順番に対話型テレビジョン受信機５４によってモジュールを取得し、記憶することができる。

最終的に、対話型テレビジョン受信機５４がカルーセルからモジュールを取得するが、新たに取得したモジュールを記憶するのに十分なメモリを有していないｋとおがある。この場合、対話型テレビジョン受信機５４はそのメモリ内の１つまたは複数の他のモジュールを取り除くことができる。例えば、対話型テレビジョン受信機５４はそのメモリ内に記憶された最古のモジュールを取り除く。別の例では、対話型テレビジョン受信機５４はアプリケーション・プログラムがもはや必要としないモジュールを取り除く。さらに別の例では、対話型テレビジョン受信機５４は異なる判定基準を用いてどのモジュールを取り除くか決定する。カルーセル内のモジュールはサイズがまちまちなため、対話型テレビジョン受信機５４は複数のモジュールを取り除いて新たに取得したモジュールの空間を作る。対話型テレビジョン受信機５４が新たに取得したモジュールの空間を作ると、そのモジュールをメモリ内に記憶し、アプリケーション・プログラムからアクセスする。

カルーセル・マネージャ
図４はカルーセル・マネージャを使用するシステムの対話型テレビジョン・システムの一例を示す。カルーセルを使用して、対話型テレビジョン・システム２１２内でサービスを同報通信する。サービスは一般にリソースの集合である。リソースは、ユニフォーム・リソース識別子（「ＵＲＩ」）またはユニフォーム・リソース・ロケータ（「ＵＲＬ」）によって識別できるデータ・オブジェクトなどの任意の数の異なるデータ・オブジェクトでよい。ユニフォーム・リソース・ロケータは、全体が本明細書に組み込まれたＢｅｒｎｅｒｓ−Ｌｅｅ他のＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｎｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ １７３８、「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（「ＵＲＬ」）、１９９４年１２月に詳述されている。ユニフォーム・リソース識別子は全体が本明細書に組み込まれたＩＥＴＦ ＲＦＣ ２３９６に詳述されている。

例えば、サービスはオンライン・マガジンであってもよい。マガジンは複数の記事のような様々な異なるリソースを含む。各記事は音声ファイル、映像ファイルまたはその他のコンテンツをさらに含む。記事は、例えば、ハイパーテキスト・マークアップ言語（「ＨＴＭＬ」）ページとしてオンラインで記憶される。拡張ハイパーテキスト・マークアップ言語（「ＸＨＴＭＬ」）、ウェブサイト・メタ言語（「ＷＭＬ」）などの他のリンク言語も使用できることは当然である。他のリソースも、Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（「ＪＰＥＧ」）、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（「ＭＰＥＧ」）、ＭＰ３または任意の数の他の利用可能なフォーマットを用いて記憶できる。リソースは、対話と表示の単一の収斂する空間を構成するリソースの集合を供給するウェブ・ページなどのページにフォーマットされる。ページそれ自体もリソースであり、サービスは複数のページを含んでもよい。

オンライン・マガジンなどのサービスを、サービス・プロバイダ２０４からアクセスでき、サービス・プロバイダによって記憶されることもある。サービス・プロバイダ２０４は、図５に示すように、インターネット６０を介してブロードキャスト・サーバ５０に接続できる。あるいは、サービス・プロバイダ２０４は、ブロードキャスト・サーバ５０に接続するイントラネットまたはその他のネットワークに接続される。複数のサービス・プロバイダ２０２、２０４、２０６、２０８は１つまたは複数のネットワークを介してブロードキャスト・サーバ５０と対話できる。さらに、各サービス・プロバイダ２０２、２０４、２０６、２０８は複数のサービスを記憶できる。

カルーセル・マネージャ２１０は好ましくはブロードキャスト・サーバ５０上で機能する。カルーセル・マネージャ２１０は、サービス・プロバイダ２０２、２０４、２０６、２０８から入手できるサービスから形成されるカルーセルの生成と同報通信を処理する。カルーセル・マネージャ２１０は様々な異なるフォーマットを用いて記述されたサービスを処理できるが、好ましい実施形態では、カルーセル・マネージャ２１０はＨＴＭＬで記述されたサービスの生成と同報通信を処理する。

図５は、ブロードキャスト・サーバを構成するためのカルーセル・マネージャ２１０の詳しい説明を示す。カルーセル・マネージャ２１０はインターネット６０を介してサービス・プロバイダ２０４とインターフェースを取るが、これは別のタイプのネットワークまたは別のタイプの接続を介して行われる。カルーセル・マネージャ２１０内のフェッチャ２５０はサービス・プロバイダ２０４とインターフェースを取り、サービス・プロバイダからサービスを受ける。例えば、フェッチャ２５０はサービス・プロバイダ２０４からＨＴＴＰサービスを受ける。フェッチャ２５０が他のＨＴＴＰ以外のサービスを受けられることは当然である。例えば、フェッチャ２５０は、ＵＲＩまたはＵＲＬによって識別されるリソースを取得でき、またはファイル転送プロトコル（「ＦＴＰ」）などのアプリケーションを介してリソースを取得する。次いでカルーセル・マネージャ２１０はブロードキャスト・ポリシーを用いてサービスをブロードキャスト・カルーセルに形成する。次いでブロードキャスト・カルーセルは対話型テレビジョン受信機５４に送信する。

図６は、ブロードキャスト・カルーセルを構築するためのプロセスの一例の流れ図である。ステップ３５０で、カルーセル・マネージャはサービス・プロバイダからサービスを取得する。次いで、ステップ３５２で、カルーセル・マネージャはサービス・プロバイダからブロードキャスト・ポリシーを取得する。次に、カルーセル・マネージャは、ステップ３５４に示すように、サービス・プロバイダから取得したブロードキャスト・ポリシーを用いてブロードキャスト・カルーセルを作成する。次いで、カルーセルはステップ３５６に示すように、対話型テレビジョン受信機に同報通信する。

続けて図５を参照すると、フェッチャ２５０はサービスのブロードキャスト・ポリシーを決定できる。ブロードキャスト・ポリシーは一般にブロードキャスト・パスを介してどのリソースを対話型テレビジョン受信機５４に同報通信するかと、ポイントツーポイント・パス５８を介して対話型テレビジョン受信機５４からどのリソースだけが利用可能かを決める。ブロードキャスト・ポリシーを開発する際には様々な異なる因子を考慮することができ、ブロードキャスト・ポリシーは様々な異なる方法で形成できる。

ブロードキャスト・パス５２は一般に高帯域をサポートするので、大容量のデータの送信をサポートできる。ただし、対話型テレビジョン受信機５４のメモリが限られている。対話型テレビジョン受信機５４の限られた記憶容量に対応するために、データはカルーセルに載せて連続的に対話型テレビジョン受信機５４に送信される。現在メモリ内にないデータを取得するために、対話型テレビジョン受信機５４はカルーセルがデータを保持するモジュールを循環させるのを待つ。対話型テレビジョン受信機５４に送信する大量のデータをカルーセル内に配置することで、対話型テレビジョン受信機５４は現在メモリにないモジュールを受信するためにカルーセルがモジュールを循環させるまでより長い時間待たねばならない場合がある。したがって、カルーセル内に配置され、ブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に送信される大量のデータを制限することが望ましい。

ＨＴＴＰフェッチャ２５０はブロードキャスト・ポリシーを様々な方法で使用する。一実施形態では、サービス・プロバイダ２０４はカルーセルを形成するためのブロードキャスト・ポリシーをフェッチャ２５０に送信する。例えば、サービス・プロバイダ２０４は、ブロードキャスト・ポリシーとして使用できるチャネル定義ファイルをフェッチャ２５０に送信する。当技術分野で知られているように、チャネル定義ファイルは、リソースの集合を識別するための特定のフォーマットである。チャネル定義ファイルを、サービス・プロバイダ２０４によって作成でき、サービスに関連付けることができる。チャネル定義ファイルを形成する際に、サービス・プロバイダ２０４は、対話型テレビジョン受信機５４がよりアクセスする可能性が高いリソースを示す。これらのリソースは、チャネル定義ファイルによって定義されているように、カルーセル内に配置してブロードキャスト・パス５２を介して対話型テレビジョン受信機５４に送信する。ただし、アクセスがより少ないリソースはポイントツーポイント・パス５８用にとっておく。チャネル定義ファイルは、本来例示的なものに過ぎず、ブロードキャスト・ポリシーを指定するために他のフォーマットを使用してもよい。

オンライン・マガジンの例に戻ると、サービス・プロバイダ２０４はカルーセル内に配置するある種のリソースを識別するチャネル定義ファイルを指定する。これらは、例えば、オンライン・マガジンの索引、特集記事、目玉記事またはその他の人気のあるリソースである。より閲覧されないリソースはポイントツーポイント・パス５８用にとっておく。一般にアクセスされるリソースを含むカルーセルを形成することで、サービス・プロバイダ２０４はブロードキャスト・カルーセルのサイズを制限できる。これによって、対話型テレビジョン受信機５４がカルーセルのリソースにアクセスする速度が増加する。さらに、カルーセルを小さくすると大量のデータを連続的に送信する場合と比較して対話型テレビジョン・システムにかかる負荷を低減できる。

ブロードキャスト・ポリシーを使用する別の実施形態では、カルーセル・マネージャ２１０はブロードキャスト・ポリシー・ファイル２５４を記憶する。ブロードキャスト・ポリシー・ファイル２５４を、カルーセルを作成するためにサービス・プロバイダ２０４から提供されたブロードキャスト・ポリシーと連係させて使用する。フェッチャ２５０はブロードキャスト・ポリシー・ファイル２５４とサービス・プロバイダのブロードキャスト・ポリシーとを様々な方法で使用できる。

一例では、サービス・プロバイダのブロードキャスト・ポリシーはカルーセル内に配置するリソースのリストを指定する。ただし、ブロードキャスト・ポリシー・ファイル２５４は、カルーセルのサイズの最大限度を設定する。ブロードキャスト・ポリシー・ファイル２５４によって定義されるサイズは、最大リソース数、リソースが使用する最大物理ビット数、または別の尺度である。サービス・プロバイダのブロードキャスト・ポリシー指定がブロードキャスト・ポリシー・ファイル２５４が設定した最大限度を超えない場合、フェッチャ２５０はサービス・プロバイダのブロードキャスト・ポリシーをそのまま使用してカルーセルを作成する。ただし、サービス・プロバイダのブロードキャスト・ポリシーが、フェッチャのブロードキャスト・ポリシー・ファイル２５４が設定したサイズ制限を超える量のリソースを指定した場合、フェッチャ２５０はカルーセルに配置されるリソースをさらに制限することがする。これは多くの異なる方法を用いて実行できる。

一実施形態では、サービス・プロバイダのブロードキャスト・ポリシーはさらにリソースの優先度を定義する。フェッチャ２５０はその優先度を用いてカルーセル内にどのリソースを配置するかを決定する。別の実施形態では、フェッチャ２５０はリソースのタイプについて優先度を決める。例えば、ＨＴＭＬファイルにＪＰＥＧファイルより高い優先度を与える。したがって、カルーセルの最大サイズ限度を強制するために、フェッチャ２５０はサービス・プロバイダのブロードキャスト・ポリシーが定義したリソースからＪＰＥＧファイルを取り除く。さらに別の実施形態では、フェッチャ２５０は最大サイズ限度を満たすまでコンテンツを任意に取り除く。その他の最大サイズ限度を強制する方法も存在し、同様に使用する。

ブロードキャスト・ポリシー２５４は最大サイズ以外の限度または制限を指定することができる。例えば、フェッチャのブロードキャスト・ポリシー・ファイル２５４はファイルなどのある種のタイプのリソースを制限する。例えば、カルーセル内にＭＰＥＧファイルを配置できないと指定する。あるいは、他のタイプのファイルについても同様の制限が可能である。さらに、ブロードキャスト・ポリシー２５４はある種のタイプのファイルのサイズまたは量を制限する。その他の制限も使用する。

別のタイプの優先度では、ブロードキャスト・ポリシーはカルーセル内の周期速度を指定する。例えば、ブロードキャスト・ポリシーはある種のモジュールを他のリソースよりもより頻繁にカルーセル内で循環させるように指定する。これによってこれらのモジュールはより迅速にアクセスすることができる。これらのモジュールは他のモジュールよりも頻繁により頻繁にカルーセル内で循環するので、対話型テレビジョン受信機はカルーセルがモジュールを選択するまで待つ時間が短くなる。したがって、モジュールを取得する待ち時間が低減される。

これらの例は網羅的なものではない。ブロードキャスト・ポリシーの作成にあたっては他の多くの要因を考慮する。さらに、サービス・プロバイダのブロードキャスト・ポリシーとブロードキャスト・ポリシー・ファイル２５４とが対話する他の多くの方法が存在し、これらの方法も使用することができる。

ブロードキャスト・ポリシーの使用に加え、フェッチャ２５０はコンテンツ・ネゴシエーションも実行する。リソースは複数の表現をとることができる。カルーセル・ビルダ２５２はサービス・プロバイダ２０４や対話型テレビジョン受信機５４とコンテンツ・ネゴシエーションを行い、カルーセルを構築する際に使用する適切なリソース表現を決定する。例えば、サービス・プロバイダはＨＴＭＬページを指定する。そのＨＴＭＬページはページを作成するために使用した異なるＨＴＭＬのバージョンに対応する複数の表現を有する。別の例では、音声または映像リソースが異なるフォーマットで利用する。リソースのその他の多くの表現が存在し、コンテンツ・ネゴシエーションにあたってこれらを使用することは言うまでもない。

対話型テレビジョン受信機５４はこれら複数の表現のいずれもサポートできない。あるいは、対話型テレビジョン受信機５４はこれら複数の表現のうち１つまたは複数をサポートできてもよい。例えば、リソースは画像ファイルである。画像ファイルは、ＪＰＥＧやビットマップなど、複数の表現で記憶する。ただし、対話型テレビジョン受信機５４は、ビットマップ画像だけをサポートしていてもよい。したがって、対話型テレビジョン受信機５４は画像のＪＰＥＧ表現を適切に表示できないことがある。対話型テレビジョン受信機５４とサービス・プロバイダ２０４との間でコンテンツ・ネゴシエーションを実行することで、複数の表現が利用する時にカルーセル・ビルダ２５２は適切な表現を選択することができる。例えば、カルーセル・マネージャ２１０は要求元アプリケーション・プログラムがビットマップ画像しかサポートしないように決定する。これで、カルーセル・マネージャ２１０はカルーセル内で使用するサービス・プロバイダ２０４からのビットマップ画像を取得する。

コンテンツ・ネゴシエーションを実行する１つの方法がＨＴＴＰ １．１標準に指定されている。ＨＴＴＰ １．１は、全体が参照により本明細書に組み込まれたＦｉｅｌｄｉｎｇ他のＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｎｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ ２６１６、「Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１」、１９９９年６月に詳述されている。他の方法を用いてコンテンツ・ネゴシエーションを実行するのは言うまでもない。

カルーセル・ビルダ２５２が、カルーセル内に配置するリソースを、フェッチャ２５０から受け取るといった方法で取得すると、カルーセル・ビルダ２５２がカルーセルを構築する。これは適切にサポートされたカルーセル・フォーマットを用いて実行することができる。例えば、カルーセル・ビルダ２５２によって各リソースをトランスポート・モジュール内に配置し、カルーセル内に挿入する。例えば、ＨＴＴＰリソースの場合、モジュールは好ましくはＨＴＴＰリソースの本文とＨＴＴＰリソースのヘッダとを含む。カルーセルは複数のトラックに分散される。当技術分野で知られているように、構成されたにトラックは基本ブロードキャスト・ストリームである。

カルーセルの構築に加えて、カルーセル・ビルダ２５２はカルーセル・ディレクトリ２５６を作成することもする。カルーセル・ディレクトリ２５６はカルーセルの一部として対話型テレビジョン受信機５４に送信でき、異なるカルーセル・モジュール内で利用可能なリソースを指定する。カルーセル・ディレクトリ２５６は様々な異なる方法を用いてカルーセル内で利用可能なリソースを指定する。一実施形態では、カルーセル・ディレクトリ２５６はカルーセル追加方法を用いてリソースを指定する。したがって、カルーセル・ディレクトリ２５６はリソースのカルーセル・モジュール・アドレスとリソースの物理アドレスとのマッピングを実行する。カルーセル内のリソースを識別し、特定のリソースを保持するモジュールを識別するために他の方法を用いてもよい。

カルーセル・ビルダ２５２はまたＵＲＩインデクス２５８を作成する。ＵＲＩインデクス２５８は、例えば、カルーセル内のリソースに関する情報を保持するデータ構造体である。ＵＲＩインデクス２５８はリソースのカルーセル・アドレスとリソースのＵＲＩまたはその他の一意的な識別子とのマッピングを実行する。例えば、ＵＲＩインデクス２５８はリソースを識別するＵＲＩとカルーセル内のリソースの位置とのマッピングを実行する。別の例では、リソースはＵＲＬを用いて識別し、ＵＲＩインデクス２５８はＵＲＬとリソースのカルーセル・アドレスとのマッピングを実行する。ＵＲＩインデクス２５８を用いてリソースのＵＲＩまたはＵＲＬとリソースのカルーセル・アドレスとのマッピングを実行する。次いで、カルーセル・ディレクトリ２５６を用いてカルーセル・アドレスをカルーセル内のリソースの物理アドレスにさらに分解する。

ＵＲＩインデクス２５８はより直接的なマッピングを実行することももちろん可能である。例えば、ＵＲＩインデクス２５８はリソースのＵＲＩとリソースのカルーセル内の物理アドレスとのマッピングを実行する。同様に、ＵＲＩインデクス２５８はリソースのＵＲＬまたはその他の識別子とリソースのカルーセル内の物理アドレスとのマッピングを実行する。この直接マッピングを用いて、ＵＲＩ、ＵＲＬまたはその他の識別子によって識別されたリソースをＵＲＩインデクス２５８を用いて物理アドレスに分解する。その結果、カルーセル・ディレクトリ２５６を用いてモジュール・アドレスを物理アドレスに分解する中間ステップを省略する。

カルーセルは対話型テレビジョン受信機５４に１組のリソースを供給する。カルーセル内のリソースはカルーセルのブロードキャスト・ポリシーに従って周期的に更新する。カルーセルにリソースを追加され、カルーセルからリソースを取り除くことができ、リソースを更新してより新しいバージョンのリソースを備えた対話型テレビジョン受信機５４を実現する。カルーセル・リソース内の変化によって、カルーセル・ディレクトリ２５６とＵＲＩインデクス２５８のそれに対応する変化が引き起こされる。カルーセル・ディレクトリ２５６とＵＲＩインデクス２５８の両方を更新してカルーセルの変更部分を反映させる。

カルーセル・ディレクトリ２５６とＵＲＩインデクス２５８の両方を更新してカルーセルの変更部分を反映させるが、補足ＵＲＩインデクスまたは補足カルーセル・ディレクトリも使用することができる。補足ＵＲＩインデクスはＵＲＩインデクス２５８の変更しか反映しない。同様に、補足カルーセル・ディレクトリもカルーセル・ディレクトリ２５６の変更しか反映しない。これらの小さい更新をカルーセル・ディレクトリ２５６やＵＲＩインデクス２５８と併用してカルーセルの現在の構成を反映させる。

カルーセル内のリソースを更新する一例では、リソースが満了したらリソースを更新するかまたはカルーセルから取り除く。ＨＴＴＰカルーセル・マネージャ２１０は一般にサービス・プロバイダ２０４またはフェッチャ２５０によって同報通信に割り当てられているリソースを同報通信する。フェッチャ２５０によって、カルーセルが最新のリソースを使用することが保証される。サービス・プロバイダ２０４はリソースの満了情報を指定する。これは、特定のリソースのエントリを作成するなどのブロードキャスト・ポリシーによって実行する。または、満了情報をリソースそれ自体に指定してもよい。例えば、ＨＴＭＬページは満了情報を指定する。

一実施形態では、フェッチャ２５０はＨＴＴＰ １．１「Ｓｅｒｖｅｒ Ｓｐｅｃｉｆｉｅｄ Ｅｘｐｉｒａｔｉｏｎ Ｍｏｄｅｌ」を用いてカルーセル内のリソースが古くなることを防止する。フェッチャ２５０はまたリソースの満了時間を決定する別のモデルを指定する。フェッチャ２５０がリソースが古いと判定すると、リソースをカルーセルから外す。

例えば、対話型テレビジョン受信機５４上で実行されているアプリケーションはカルーセルからリソースを取得するが、リソースの最新バージョンを有しているか否かを判定したい場合がある。アプリケーションはカルーセル・ディレクトリ２５６を用いて有効期限計算ヘッダを演算する。カルーセル・ディレクトリ２５６を用いて、カルーセルが保持するリソースに関するリアルタイムの更新情報を供給するトリガ機構を実現し、カルーセルが保持するリソースの最新バージョンを有するか否かをアプリケーションが判定する。

対話型テレビジョン受信機のアプリケーションにリソースの最新バージョンを供給する処理に加えて、リソース満了を用いてカルーセル内のリソースを維持する。リソースが満了すると、フェッチャ２５０はサービス・プロバイダ２０４からより新しいバージョンを取得する。フェッチャ２５０はカルーセル・ビルダ２５２に更新されたリソースを供給し、カルーセル・ビルダ２５２はカルーセル内の古いリソース・バージョンを更新されたバージョンと差し替える。カルーセルが送信されると、対話型テレビジョン受信機５４は更新されたリソースを受信する。代替形態では、更新されたリソースはカルーセル内に配置されない。対話型テレビジョン受信機５４はポイントツーポイント・パス５８から更新されたリソースを取得することしかできない。

リソースのより新しいバージョンが入手できない場合、フェッチャ２５０はカルーセル・ビルダ２５２にカルーセルからリソースを取り除くように指示する。カルーセル・ビルダ２５２はこれに従ってＵＲＩインデクス２５８を更新する。リソースはブロードキャスト・パス５２上でもはや入手できなくなる。

インターフェース・モジュール
図７は、対話型テレビジョン受信機５４で使用するインターフェース・モジュール３００を示すブロック図である。インターフェース・モジュールは、対話型テレビジョン受信機５４上で走り、対話型テレビジョン・システムにデータを要求するアプリケーション・プログラム３０２のインターフェースとして機能する。インターフェース・モジュール３００はアプリケーション・プログラム３０２からリソース要求を受信する。次いでインターフェース・モジュール３００は、リソースをブロードキャスト・パス５２とポイントツーポイント・パス５８のどちらから取得するかを決定する。要求がサポートされるフォーマットでない場合、インターフェース・モジュール３００はアプリケーション・プログラム３０２からの要求をリソースを取得するためのパスがサポートするフォーマットに変換する。

アプリケーション・プログラム３０２は対話型テレビジョン受信機５４で走る。対話型テレビジョン受信機５４はインターフェース・モジュールを実行する。インターフェース・モジュールはアプリケーション・プログラム３０２に、アプリケーション・プログラム３０２がカルーセルまたはポイントツーポイント・パス５８からリソースをフェッチするための必要なアプリケーション・プログラム・インターフェース（「ＡＰＩ」）を供給する。当技術分野で知られているように、ＡＰＩはプログラムが別のプログラム、オペレーティング・システムまたはその他のサービスと通信するために使用する１組の機能とする。

アプリケーション・プログラム３０２は、カルーセルからのデータの適切な要求を送信することで、カルーセルから直接データを取得する。これに応答して、アプリケーション・プログラム３０２は、ブロードキャスト・パス５２を介してカルーセルに載せて送信された要求されたデータを受信する。あるいは、アプリケーション・プログラム３０２はポイントツーポイント・パス５８を介してサービス・プロバイダ６４に要求を送信することでデータを取得する。次いで、サービス・プロバイダ６４はポイントツーポイント・パス５８に沿って対話型テレビジョン受信機５４に送信する。ただし、ブロードキャスト・パス５２からデータを要求するためのフォーマットは、ポイントツーポイント・パス５８からデータを要求するためのフォーマットとは異なる場合がある。

インターフェース・モジュール３００は対話型テレビジョン受信機５４で実行され、アプリケーション・プログラム３０２と２つのデータ・パス５２、５８との間のインターフェースとして機能する。インターフェース・モジュール３００は対話型テレビジョン受信機５４上で実行中のアプリケーション・プログラム３０２からデータ要求を受信する。インターフェース・モジュール３００へのデータ要求はブロードキャスト・パス５２またはポイントツーポイント・パス５８からリソースを要求するための均一のフォーマットでよい。インターフェース・モジュール３００はアプリケーション・プログラム３０２からのデータ要求を処理し、データをブロードキャスト・パス５２とポイントツーポイント・パス５８のどちらから取得するかを決定する。次いで、必要に応じて、インターフェース・モジュール３００はデータ要求をブロードキャスト・パス５２またはポイントツーポイント・パス５８に必要な構文に再フォーマットする。

図８はリソースを取得するために使用する例示のプロセスの流れ図である。ステップ４００で、インターフェース・モジュールはアプリケーション・プログラムからリソース要求を受信する。ステップ４０２で、インターフェース・モジュールはインデクス・モジュールを含むブロードキャスト・カルーセルを受信する。次いで、インターフェース・モジュールはインデクス・モジュールをサーチして、ブロードキャスト・カルーセル内でリソースが利用可能か否かを判定する（ステップ４０４）。ブロードキャスト・カルーセル内でリソースが利用可能な場合、アプリケーション・プログラムに供給される。逆に、ブロードキャスト・カルーセル内でリソースが利用可能でない場合、ステップ４０６に示すように、ポイントツーポイント・パスからリソースを取得する。

図９はリソースを取得するために使用する別の例示のプロセスの流れ図である。ステップ４５０で、インターフェース・モジュールはアプリケーション・プログラムからリソース要求を受信する。ステップ４５２で、インターフェース・モジュールはインデクスをサーチして、カルーセル内でリソースが利用可能か否かを判定する。インデクス・モジュールは、カルーセルでインターフェース・モジュールに送信される。次に、ステップ４５４で、インターフェース・モジュールはカルーセル内でリソースが利用可能でないと判定する。ステップ４５６で、インターフェース・モジュールはポイントツーポイント・パスからリソースを要求する。次いで、ステップ４５８で、インターフェース・モジュールはポイントツーポイント・パスからリソースを受信する。最後に、インターフェース・モジュールはリソースを要求元アプリケーション・プログラムに供給する（ステップ４６０）。

さらに図７を参照すると、インターフェース・モジュール３００は、アプリケーション・プログラム３０２からリソース要求を受信する。リソース要求はそのＵＲＩまたは別の識別子によってリソースを識別する。インターフェース・モジュール３００への要求は、リソースの要求元にかかわらず、標準フォーマットでよい。一実施形態では、データ要求はブロードキャスト・パス５２からリソースを取得する構文を用いてフォーマットされる。別の実施形態では、データ要求はポイントツーポイント・パス５８からリソースを取得する構文を用いてフォーマットされる。さらに別の実施形態では、データ要求はインターフェース・モジュール３００が認識する別のフォーマットを用いてフォーマットされる。

インターフェース・モジュール３００はデータ要求を受信し、どのリソースが要求されているかを判定する。次いで、インターフェース・モジュール３００はＵＲＩインデクス２５８を用いてそのリソースがブロードキャスト・パス５２から利用可能か否かを判定する。例えば、インターフェース・モジュール３００は要求されたリソースのＵＲＩに基づいてＵＲＩインデクス２５８をサーチする。リソースがブロードキャスト・パス５２上で利用可能な場合、ＵＲＩインデクス２５８はリソースのＵＲＩとそのカルーセル・アドレスまたは物理ロケーションとのマッピングを実行する。次いで、マッピングを用いて、インターフェース・モジュール３００はカルーセルからリソースを取得し、アプリケーション・プログラム３０２に供給する。

ただし、ＵＲＩインデクス２５８はＵＲＩとカルーセル・アドレスとのマッピングを記憶しない場合、インターフェース・モジュール３００はブロードキャスト・パス５２上でリソースが利用可能であると判定する。次いで、インターフェース・モジュール３００はポイントツーポイント・パス５８からリソースを要求する。リソースをポイントツーポイント・パスから要求するにあたって、インターフェース・モジュール３００はそのパスからリソースを要求するプロトコルを使用する。また、そのプロトコルはブロードキャスト・パス５２からリソースを要求するプロトコルとは異なる。こうして、インターフェース・モジュール３００がリソースを要求する際にどのパスを使用するかを決定すると、インターフェース・モジュール３００はそのパスの適切なプロトコルを使用する。

インターフェース・モジュール３００はブロードキャスト・パス５２またはポイントツーポイント・パス５８からリソースを取得するシームレスな方法を実現する。アプリケーション・プログラム３０２はリソースの送信元にかかわらず、均一の構文を用いてリソースを要求する。リソースの要求に単一の構文を使用することにはいくつかの利点がある。利点の一例は、単一の構文の使用でアプリケーション開発者がリソースが利用可能な場所を決定する必要が解消されるということである。アプリケーション開発者は均一の構文を用いてリソースを要求するので、リソースの可能なソース間の符号を区別する必要はなくなる。アプリケーションの符号化の際に、リソースがブロードキャスト・パス５２とポイントツーポイント・パス５８のどちらから入手するかを知る必要はない。アプリケーション実行時には、インターフェース・モジュール３００はリソース要求を受信する。リソースがブロードキャスト・パス５２上で利用可能な場合、インターフェース・モジュール３００はカルーセルからリソースを検索する。

ただし、リソースがブロードキャスト・パス５２上で利用可能でない場合、インターフェース・モジュール３００はポイントツーポイント・パス５８を介してリソースを取得するためのプロトコルを用いてポイントツーポイント・パス５８を介してリソースを取得する。インターフェース・モジュール３００を用いて、要求されたリソースをブロードキャスト・パス５２またはポイントツーポイント・パス５８から取得するようにすることで、リソースをそれが利用不能なロケーションからのみ要求することが原因で起こるプログラム・エラーを減少させる。また、インターフェース・モジュール３００は不必要にポイントツーポイント・パス５８を使用する状況（例えば、アプリケーション開発者がブロードキャスト・パス５２上でリソースが利用可能か否かの確証がなく、ポイントツーポイント・パス５８からリソースを取得することを選択する場合）を減らして、この間違いがなかったらより高速のブロードキャスト・パス５２上で利用可能であったはずのリソースを取得する。

利点の別の例では、インターフェース・モジュール３００は、アプリケーション・プログラム３０２に悪影響を与えることなく、カルーセルを連続的に更新する。例えば、満了したリソースをカルーセルから取り除く。インターフェース・モジュール３００がなければ、カルーセルからリソースを取り除くとプログラム・エラーが発生する場合がある。これは、アプリケーション・プログラム３０２が要求したリソースはもはやブロードキャスト・パス５２上で利用可能でないためである。ただし、インターフェース・モジュール３００は要求をブロードキャスト構文からポイントツーポイント構文に変換する処理を扱う。取り除かれたリソースの要求はポイントツーポイント・パス５８を介して送信され、リソースの現在のバージョンをポイントツーポイント・パス５８から取得する。その結果、前にカルーセル内にあった満了したバージョンではなく最新バージョンのリソースをアプリケーション・プログラム３０２に供給する。

また、インターフェース・モジュール３００は、ＵＲＩインデクス２５８をモニタして、リソースのカルーセルへの追加／削除などのカルーセル内の変更を検出する。ＵＲＩインデクス２５８のモニタリングに加えて、インターフェース・モジュール３００は補足ＵＲＩインデクス２５８をモニタする。補足ＵＲＩインデクス２５８は元のＵＲＩインデクス２５８の作成後のカルーセルの変更を反映させることができ、カルーセルの変更を検出する簡単で効率的な方法をインターフェース・モジュール３００に与える。同様に、インターフェース・モジュール３００はカルーセル・ディレクトリ２５６をモニタすることでカルーセルの変更を検出する。カルーセルの変更も、補足カルーセル・ディレクトリを用いて迅速かつ効率的に検出する。

リソース要求の扱いに加え、インターフェース・モジュール３００はリソースのプリフェッチもサポートする。１つのタイプのプリフェッチでは、アプリケーション・プログラム３０２はＨＴＭＬページなどのリソースにアクセスする。ＨＴＭＬページは様々な他のサブリソースを含む。アプリケーション・プログラム３０２が現在サブリソースにアクセスしている間、インターフェース・モジュール３００はＨＴＭＬページを形成するサブリソースの残りをプリフェッチする。次いで、アプリケーション・プログラム３０２がその後他のサブリソースにアクセスしようとすると、サブリソースはトランスポート・パスの１つから要求しなくても直ちに利用可能になる。

別のタイプのプリフェッチでは、ＨＴＭＬページは様々な他のリソースへのリンクを含む。インターフェース・モジュール３００はリンクされたリソースをプリフェッチでき、それによってアプリケーション・プログラム３０２によって要求される前にリンクされたリソースを取得する。取得したリソースは対話型テレビジョン受信機のメモリ内に記憶する。次いで、アプリケーション・プログラム３０２がメモリ内のリソースの１つを要求した場合、メモリから取り出してアプリケーション・プログラム３０２に供給する。リソースを伝送パスの１つから取り出す時間をかけずにリソースをアプリケーション・プログラム３０２に供給する。

一実施形態では、インターフェース・モジュール３００はブロードキャスト・パス５２を介して利用可能なリンクされたリソースを事前取り出しするだけである。ブロードキャスト・サーバ５０はカルーセルを周期的に循環させて対話型テレビジョン受信機５４にリソースを送信し、ブロードキャスト・パス５２上ではリソースを取得する追加の帯域幅は使用されないので、インターフェース・モジュール３００はブロードキャスト・パス５２上のデータ転送速度を下げることなくこれらのリソースを取得する。この処理も対話型テレビジョン受信機５４によって最小量の余分な処理のみで取得する。その後、アプリケーション・プログラム３０２がＨＴＭＬページ上のリンクを介してリソースを要求すると、インターフェース・モジュール３００は、カルーセルが要求されたリソースまで循環するのを待たずに事前取り出しされたリソースを迅速に供給する。

アプリケーション・プログラム３０２が事前に取り出されたリソースを要求しない場合、それらはメモリから取り除かれる。例えば、アプリケーション・プログラム３０２が新しいＨＴＭＰページにブラウジングした場合、インターフェース・モジュール３００は旧ページから事前取り出しされたリソースを削除する。次いで、インターフェース・モジュール３００は新しいＨＴＭＬページのリソースを事前取り出しでき、新しく事前に取り出されたリソースは旧ページの事前に取り出されたリソースに上書きする。未使用の事前取り出しされたリソースを取り除くために他のプロセスも使用する。

別の実施形態では、インターフェース・モジュール３００はポイントツーポイント・パス５８上でのみ利用可能なリソースを事前に取り出す。インターフェース・モジュール３００はリソースを要求し、ポイントツーポイント・パス５８を介してそれらを受信する。リソースはインターフェース・モジュール３００によって対話型テレビジョン受信機５４内に記憶され、アプリケーションが現在のＨＴＭＬページを介してリソースを要求した場合、迅速に検索される。リソースは普通、ポイントツーポイント・パス５８を介して送信されないので、ポイントツーポイント・パス５８を介してリソースを取得する際に追加の帯域幅が消費される。その結果、ポイントツーポイント・パス５８上の全体のデータ伝送速度を低下させ、そのパスを使用する他のアプリケーションに悪影響を与えることがある。さらに別の実施形態では、インターフェース・モジュールはブロードキャスト・パス５２とポイントツーポイント・パス５８の両方で利用可能なリソースの事前取り出しを行う。その他の変形形態も可能で、それらを使用することもする。

本明細書に記載するプログラム、プロセス、方法および装置は、特に断りのない限り、いかなる特定のタイプのコンピュータまたはネットワーク装置（ハードウェアまたはソフトウェア）にも関連せずまたは限定されないことを理解されたい。様々なタイプの汎用または専用のコンピュータ装置を本明細書に記載の教示と併用し、また本明細書に記載の教示に従ってオペレーションを実行する。好ましい実施形態の様々な要素をソフトウェアで実施するものとして説明してきたが、他の実施形態では、これに代えてハードウェアまたはファームウェア実施態様を使用でき、その逆も可能である。

本発明の原理を適用する様々な実施形態に関して、図示の実施形態は例示的なものに過ぎず、本発明の範囲を限定するものと解釈すべきではないことを理解されたい。例えば、流れ図の各ステップは記述の順序以外の順序で実行でき、より多い数、より少ない数または他の要素をブロック図で使用する。

特に断りのない限り、請求の範囲は要素の記述順序に限定されるものではない。さらに、請求の範囲の「手段」という用語は、３５ Ｕ．Ｓ．Ｃ．§１１２、パラグラフ６を行使するもので、「手段」という用語がない請求の範囲にはそのような意図はない。したがって、以下の請求の範囲およびその等価物の範囲と精神を逸脱しないすべての実施形態は本発明として請求される。

対話型テレビジョン・システムのアーキテクチャの例を示す図である。 対話型テレビジョン・アプリケーションのモジュールへの分割を示す図である。 ブロードキャスト・パスを介して図２のモジュールを対話型テレビジョン受信機に送信する順序の例を示す図である。 カルーセル・マネージャを使用する対話型テレビジョン・システムの例を示す図である。 図４の対話型テレビジョン・システムで使用されるカルーセル・マネージャを示す図である。 ブロードキャスト・カルーセルを構築する例示のプロセスの流れ図である。 対話型テレビジョン受信機上で実行されるインターフェース・モジュールを示すブロック図である。 図７のインターフェース・モジュールを使用するリソースを得る例示のプロセスの流れ図である。 図７のインターフェース・モジュールを使用するリソースを得る別の例示のプロセスの流れ図である。

Claims (34)

1. ブロードキャスト・ネットワーク内でＨＴＴＰサーバをエミュレーションする方法であって、
   対話型テレビジョン受信機上で実行されるアプリケーション・プログラムからリソースを求める要求を受信するステップと、
   周期的に受信される複数のデータ・モジュールのデータ・ストリームを含むブロードキャスト・カルーセルを受信するステップと、
   ブロードキャスト・カルーセル内で利用可能なリソースを識別するインデクスにアクセスして、ブロードキャスト・カルーセル内でリソースが利用可能か否かを判定するステップとを含む方法。
2. 中央処理装置に請求項１に記載の方法を実行させる命令を内部に記憶したコンピュータ可読媒体。
3. 前記リソースがブロードキャスト・パスから利用可能でない場合にポイントツーポイント・パスから前記リソースを取得するステップを含む請求項１に記載の方法。
4. 前記リソースをＨＴＴＰサーバ、ＦＴＰサーバまたはファイル・サーバから取得するステップをさらに含む請求項１に記載の方法。
5. アプリケーション・プログラムからのリソース要求が第１のプロトコルを使用し、ポイントツーポイント・パスから前記リソースを取得するステップが、
   第２のプロトコルを用いてポイントツーポイント・パスを介して前記リソースを要求するステップと、
   前記ポイントツーポイント・パスから前記リソースを受信するステップとを含む請求項１に記載の方法。
6. 前記第１のプロトコルがＵＲＩまたはＵＲＬを用いて前記リソースを識別する請求項５に記載の方法。
7. 前記第２のプロトコルがＵＲＩまたはＵＲＬを用いて前記リソースを識別する請求項５に記載の方法。
8. 前記要求が前記ＵＲＩを用いて前記リソースを識別し、カルーセル内の前記リソースのロケーションが物理アドレスを用いて識別され、前記インデクスが前記ＵＲＩと前記物理アドレスとのマッピングを実行する請求項１に記載の方法。
9. 前記要求がＵＲＩを用いて前記リソースを識別し、前記リソースが論理カルーセル・アドレスを用いてカルーセルから取得され、前記インデクスが前記ＵＲＩと前記論理カルーセル・アドレスとのマッピングを実行し、前記リソースを取得するステップが、
   前記インデクスをサーチして前記リソースの前記論理カルーセル・アドレスを決定するステップと、
   前記論理カルーセル・アドレスを用いて前記カルーセルから前記リソースを取得するステップとをさらに含む請求項１に記載の方法。
10. 前記論理カルーセル・アドレスを用いて前記カルーセルからリソースを取得するステップが、
    前記第２のインデクスをサーチして前記リソースの物理アドレスを決定するステップであって前記第２のインデクスが前記論理カルーセル・アドレスと前記物理アドレスとのマッピングを実行するステップと、
    前記物理アドレスを用いて前記カルーセルから前記リソースを取得するステップとをさらに含む請求項９に記載の方法。
11. 前記リソースがハイパーリンク言語を用いて作成される請求項１に記載の方法。
12. 前記ハイパーリンク言語がＨＴＭＬ．ＸＨＴＭＬまたはＷＭＬである請求項１１に記載の方法。
13. 前記リソースが第２のリソースを識別する少なくとも１つのリンクを含み、前記方法が、
    前記第２のリソースをプリフェッチする請求項１１に記載の方法。
14. 前記ブロードキャスト・ネットワークがケーブル・ネットワーク、衛星ネットワークまたは対話型テレビジョン・ネットワークである請求項１に記載の方法。
15. 前記アプリケーション・プログラムがセットトップ・ボックス、ゲーム・コンソールまたは対話型テレビジョン受信機上で実行される請求項１に記載の方法。
16. 対話型テレビジョン・システム内でリソース要求を処理する方法であって、
    アプリケーション・プログラムからリソース要求を受信するステップであって、前記要求が第１のプロトコルを使用し、前記アプリケーション・プログラムが対話型テレビジョン受信機上で実行されるステップと、
    インデクスをサーチして前記リソースがブロードキャスト・カルーセルから利用可能か否かを決定するステップであって、前記インデクスが前記ブロードキャスト・カルーセルから利用可能なリソースを示し、前記ブロードキャスト・カルーセルがブロードキャスト・パスを介して前記対話型テレビジョン受信機に周期的に送信されるステップと、
    前記リソースがブロードキャスト・カルーセル内で利用可能でないと判定するステップと、
    コンテンツ・ホストにポイントツーポイント・パスを介して前記リソースを要求するステップと、
    前記コンテンツ・ホストから前記ポイントツーポイント・パスを介して前記リソースを受信するステップと、
    前記リソースを前記アプリケーション・プログラムに供給するステップとを含む方法。
17. 中央処理装置に請求項１６に記載の方法を実行させる命令を内部に記憶したコンピュータ可読媒体。
18. 前記ポイントツーポイント・パスを介して前記リソースを取得するステップが、
    第２のプロトコルを用いて前記ポイントツーポイント・パスを介して前記リソースを要求するステップを含む請求項１６に記載の方法。
19. 前記第１のプロトコルがＵＲＩまたはＵＲＬを用いて前記リソースを識別する請求項１６に記載の方法。
20. 前記第２のプロトコルがＵＲＩまたはＵＲＬを用いて前記リソースを識別する請求項１８に記載の方法。
21. コンテンツ・ホストがリソースの複数の異なる表現を記憶し、前記ポイントツーポイント・パスを介して前記コンテンツ・ホストから前記リソースを要求するステップが、
    前記コンテンツ・ホストとコンテンツ・ネゴシエーションを実行して前記複数の表現の１つを選択するステップを含む請求項１６に記載の方法。
22. 前記対話型テレビジョン受信機がセットトップ・ボックスまたはゲーム・コンソールである請求項１６に記載の方法。
23. プロセッサと、
    データ記憶媒体と、
    前記データ記憶媒体に記憶され、前記プロセッサによって実行可能なアプリケーション・プログラムと、
    前記データ記憶媒体に記憶され、前記プロセッサによって実行可能なカルーセル・インターフェース論理と、ブロードキャスト・パスを介して送信されたブロードキャスト・サーバからのカルーセルと、
    （ｉ）前記アプリケーション・プログラムからの第１のプロトコルを使用するリソース要求を受信し、（ii）前記リソースが前記カルーセル内で利用可能か否かを判定し、（iii）前記リソースが前記カルーセル内で利用可能な場合に前記カルーセルから前記リソースを取得し、（iv）前記リソースが前記カルーセル内で利用可能でない場合に第２のフォーマットを用いてポイントツーポイント・パスから前記リソースを取得し、（ｖ）前記リソースを前記アプリケーション・プログラムに供給するために、前記データ記憶媒体に記憶され、前記プロセッサによって実行可能なインターフェース・モジュール論理とを含む対話型テレビジョン受信機。
24. （ｉ）前記リソース内に少なくとも１つのリンクを決定し、（ii）前記少なくとも１つのリンクが示すデータを検索し、（iii）前記データを前記データ記憶媒体に記憶するために、前記データ記憶媒体に記憶され、かつ前記プロセッサによって実行可能なプリフェッチする論理をさらに含む請求項２３に記載の対話型テレビジョン受信機。
25. 対話型テレビジョン受信機にリソースを同報通信する方法であって、
    サービス・プロバイダから複数のリソースを含むサービスを取得するステップと、
    ブロードキャスト・パスを介して前記対話型テレビジョン受信機に送信する前記複数のリソースの少なくとも１つを示すブロードキャスト・ポリシーを前記サービス・プロバイダから取得するステップと、
    前記複数のリソースの少なくとも１つを含み、かつ前記カルーセルに含まれるリソースを識別するカルーセル・ディレクトリを含むカルーセルを作成するステップと、
    前記ブロードキャスト・パスを介して前記対話型テレビジョン受信機に前記カルーセルを同報通信するステップとを含む方法。
26. 中央処理装置に請求項２５に記載の方法を実行させる命令を内部に記憶したコンピュータ可読媒体。
27. カルーセルを作成するステップが、
    前記サービス・プロバイダと前記対話型テレビジョン受信機との間でコンテンツ・ネゴシエーションを実行するステップを含む請求項２５に記載の方法。
28. コンテンツ・ネゴシエーションを実行するステップが、
    前記サービス内の前記リソースの少なくとも１つについて利用可能なフォーマットを決定するステップと、
    前記対話型テレビジョン受信機内の少なくとも１つのアプリケーション・プログラムによってサポートされるフォーマットを決定するステップと、
    前記カルーセル内で使用する前記少なくとも１つのリソースについて利用可能なフォーマットの１つを選択するステップとを含む請求項２５に記載の方法。
29. ブロードキャスト・ポリシーを取得するステップが、
    前記サービス・プロバイダからチャネル定義ファイルを受信するステップを含む請求項２５に記載の方法。
30. 前記カルーセル内のリソースが満了したことを判定するステップと、
    前記満了したリソースを前記カルーセルから取り除くステップと、
    前記カルーセル・ディレクトリを更新するステップとをさらに含む請求項２５に記載の方法。
31. 前記カルーセル・ディレクトリを更新するステップが、
    前記カルーセル・ディレクトリの作成後の前記カルーセルの変更を示す補足カルーセル・ディレクトリを作成するステップを含む請求項３０に記載の方法。
32. 前記対話型テレビジョン受信機がセットトップ・ボックスまたはゲーム・コンソールである請求項２５に記載の方法。
33. プロセッサと、
    データ記憶媒体と、
    （ｉ）サービス・プロバイダからサービスを受信し、（ii）前記サービス・プロバイダからリソースを受信するために、前記データ記憶媒体に記憶され、前記プロセッサによって実行可能なサービス・プロバイダ・インターフェース論理と、
    （ｉ）前記サービス・プロバイダからブロードキャスト・ポリシー情報を受信し、（ii）前記データ記憶媒体に記憶されたブロードキャスト・ポリシー情報を取り出し、（iii）ブロードキャスト・ポリシーを決定するために、前記データ記憶媒体に記憶され、前記プロセッサによって実行可能なブロードキャスト・ポリシー決定論理と、
    （ｉ）前記ブロードキャスト・ポリシーに基づいてカルーセル内に配置するリソースを決定し、（ii）前記カルーセル内に配置するリソースを取得し、（iii）前記カルーセル内の各リソースについてカルーセル・アドレスとＵＲＩ識別子とのマッピングを実行するインデクスを作成し、（iv）前記カルーセルを構築するために、前記データ記憶媒体に記憶され、前記プロセッサによって実行可能なカルーセル構築論理と、
    前記データ記憶媒体に記憶され、前記プロセッサによって実行可能な、前記カルーセルを対話型テレビジョン受信機に同報通信するカルーセル・ブロードキャスト論理とを含む対話型テレビジョン・ブロードキャスト・サーバ。
34. （ｉ）前記カルーセル内に含まれるリソースの満了を判定し、（ii）前記カルーセルから前記リソースを取り除き、（iii）前記インデクスを更新するために、前記データ記憶媒体に記憶され、前記プロセッサによって実行可能な満了論理をさらに有する請求項３０に記載の対話型テレビジョン・ブロードキャスト・サーバ。

Images