JP4236574B2 - 最新のクライアント・デマンド・フィードバックに基づいて配信スケジュールを決定するための方法及び装置 - Google Patents

Description

本発明は、広義には配信システムに関し、より詳細には、本発明は、配信エリアに渡って分布する多くのクライアントによって供給されるデマンド・フィードバック・データに基づいて複数のコンテンツから最も便宜的なコンテンツを連続的にスケジューリングし、および配信する事に関する。

伝統的に、配信システムは、アンテナ、衛星、コンピュータ・サーバ・システムの様な配信ソースから、通常はテレビジョン受信機、ケーブルテレビ・ボックス、セットトップ・ボックスあるいはクライアント・コンピュータを使用して配信データを受信する複数の配信需要家に向けてデータを一方的に配信する。ここにおいて使用される目的のために、配信ソースは「サーバ・システム」または「配信サーバ」と称され、配信需要家（つまりユーザ）は、「クライアント・システム」を経由してコンテンツを受信する「クライアント」と称される。通常、クライアント・システムのユーザは、配信と同時に、サーバ・システムから受信した信号を消費する。例えば、生放送のイベントに対応して配信された信号は、実質的にリアルタイムで受信される。あらかじめ記録されたテレビ番組および映画のような他のタイプの配信コンテンツについても同様である。生放送のイベントと異なり、あらかじめ録画された番組および映画に対応するデータは、配信システムの何処かに予め格納される。尚、対応する米国出願に関連して、以下の文献が発見されている。
米国特許第４６０２２７９号明細書 米国特許第５１５５５９１号明細書 米国特許第５４４４４９９号明細書 米国特許第５４４６９１９号明細書 米国特許第５５５９５４９号明細書 米国特許第５５６４０８８号明細書 米国特許第５６００３６４号明細書 米国特許第５６８６９５４号明細書 米国特許第５７９０９３５号明細書 米国特許第５９４５９８８号明細書 米国特許第５９７７９６４号明細書 米国特許第５９９１８４１号明細書 米国特許第６００２３９３号明細書 国際公開第９９／６５２３７号 Intel Archtecture Labs. Internet and Broadcast: The Key To Digital Convergence. Utilizing Digital Technology to Meet Audience Demand, 2000, pp1-4.

現在、クライアント・エンド・ユーザにコンテンツを供給する公共のコンテンツ配信方法は、同じデータを連続的に、および／または、時間をずらして配信するようなサーバ・システムを含む。従って、ユーザが映画やテレビ番組の様な特定の１つのコンテンツを消費することを望んだ場合、ユーザは、該コンテンツが繰返し配信されている複数の配信のうちの１つに、配信時間中にチャンネルを「チューニング」する。この方法の１つの例として、ケーブルテレビまたは衛星テレビ局で現在利用可能な「ペイ・パー・ビュー方式」の映画が挙げられる。例えば、ケーブルテレビ局は通常、複数のチャンネルにおいて時間をずらして繰り返し同じ映画を配信する。ある特定の映画を観たいユーザは、単に該映画が配信される複数の開始時間のいずれかにおいて、所望する映画が配信されている複数のチャンネルの１つにチャンネルを合わせるだけに過ぎない。同じデータまたは番組を連続的に繰り替えし配信するので、配信帯域幅の使用が非常に非効率的になる。複数チャンネルで繰返し同じデータを配信するために占有される帯域幅は、さもなければ異なるデータを配信するために使用することも出来る。

配信システムにおいてオンデマンドでコンテンツを提供するための別の方法には、ユーザがある特定のデータ・ファイルを記録し、その記録されたデータフィルにその後「オンデマンド」でアクセスする方法がある。上述されたテレビ配信の例に続き、この方法における例は、ユーザが所望のテレビ番組を記録するためにビデオカセットレコーダー（ＶＣＲ）を設定する、というものである。ユーザがテレビ番組を後から「オンデマンド」で視聴する事を欲する場合、ユーザは、前もって記録された番組をＶＣＲから再生するだけである。最近、より高度なデジタル・ビデオ・レコーダが利用可能になって来ており、従来のＶＣＲによって使用されるビデオカセットテープの代わりに内部ハードドライブにテレビ放送を記録する。しかしながら、デジタル・ビデオ・レコーダの使用は、ユーザがどの配信を内部ハードドライブに記録するかを決めるために使用される数値（例えば日付、時間）をきちんと設定する必要があるという点で、従来のＶＣＲと類似している。

現在の配信システムが有する他の制限は、ほとんどのクライアント・システムのユーザにとって、プログラミングと言う観点から、配信元にフィードバックを提供する事が困難であると言う事である。例えば、上述されたテレビ放送の例に続き、現在のテレビ局の多くは、配信番組および／またはスケジュールを決定するために、ニールセン指標に依存している。ニールセン指標は通常、一般市民の代表の小規模なサンプリングのみに基づいており、また、ニールセン指標は通常、視聴率（番組が配信される時点における、全てのテレビ番組に対する該テレビ番組を視聴するユーザの推定百分率）、および視聴者数（該番組の少なくとも一部分を視聴する人数の推定総数）のみを測定する。従って、ほとんどのテレビ視聴者が配信スケジュールおよび／またはコンテンツに及ぼす影響は比較的少ないか、または、全く影響を及ぼさない。

本発明の１つの形態において、クライアント・フィードバック情報に基づいて配信システムによってコンテンツを提供するシグナリング方法および装置が示される。本発明の他の形態において、将来の配信時間枠の枠内に配信される事が考慮される様々なコンテンツの間からコンテンツを格付け、およびランキングするための方法および装置が示される。本発明の更なる他の形態において、配信コンテンツおよび（または）配信オペレーション・センターのスケジュールを動的に決定するための方法および装置が示される。以下の記載において、多数の具体的な詳細が、本発明の完全な理解を提供するために記載される。しかし、記載された具体的な詳細が本発明を実施するために必ずしも使用される必要が無いという事は当業者にとって明白である。また、周知の材料または方法は、本発明を不明瞭にすることを避けるために記載しなかった。

本発明は、添付された図面によって例示されるが、この例に限定されない。

図１ａは、本発明の教示における配信システムの一実施形態を示す図である。記述された実施形態において例示されるように、配信司令センター即ち配信サーバ１０３は、複数のクライアント・システム１０５、１０７および１０９へ情報を配信するために構成される。図１ａに示される実施形態において、クライアント・システム１０５は、配信アンテナ１１１からの配信リンク１１５によって配信サーバ１０３から配信を受信する。同様に、クライアント・システム１０７は配信アンテナ１１１からの配信リンク１１７によって配信サーバ１０３から配信を受信する。また、クライアント・システム１０９は配信アンテナ１１１からの配信リンク１１９によって配信サーバ１０３から配信を受信する。一実施形態において、配信リンク１１５、１１７および１１９は、大気中を伝播する公知の振幅変調（ＡＭ）または周波数変調（ＦＭ）のラジオ信号、テレビ信号、デジタルビデオ放送（ＤＶＢ）信号等の形式で放送アンテナから送信される単方向の無線周波数（ＲＦ）のリンクであり得るが、必ずしもこれに限定されない。

一実施形態において、配信サーバ１０３は複数のデータ・ファイルを配信するために構成され、これらのデータ・ファイルはクライアント・システム１０５、１０７および１０９によって受信され得る。一実施形態において、データ・ファイルは、例えばビデオ、オーディオ、グラフィックス、テキスト、マルチメディア等を含む多くの異なる種類のファイルの任意の組み合わせであって良い。説明のために、本発明の記載を援助するために本開示において提供される実例の多くは、サーバによって配信されるべきデータ・ファイルが、例えば「コンテンツ」とここでは称される動画とサウンドを伴う映画のようなオーディオ／ビデオファイルである、と想定するが、本発明の教示に従って配信されたデータ・ファイルはオーディオ／ビデオファイルのみに限定されていないことが認識されるであろう。

図１ａにおける実施形態において示されるように、配信リンク１１５、１１７および１１９は、配信サーバ１０３とクライアント・システム１０５、１０７および１０９の間に一方通行、即ち単一方向のリンクを備える。しかしながら、他の実施形態において、配信サーバ１０３と各クライアント・システム１０５、１０７および１０９の間に第２通信リンクが存在しても良いという事が認識される。具体的には、図１ｂは、図１ａの配信システムに「バックチャンネル」、即ち、各クライアント・システム１０５、１０７および１０９と配信サーバ１０３間の通信リンクを追加した配信システムを示した図である。具体的に、図１ｂにおいて示される実施形態は通信リンク１２１、１２３および１２５を示し、これらはクライアント・システム１０５、１０７および１０９のそれぞれが配信サーバ１０３に情報を返送するために使用され得る。通信リンク１２１、１２３および１２５は図１ｂにおいてはクライアント・システム１０５、１０７および１０９と配信サーバ１０３間の直接リンクとして示されているが、クライアント・システム１０５、１０７および１０９は、例えば放送無線信号、ネットワークコミュニケーション等のような間接リンクを通して配信サーバ１０３と情報を伝達しても良い、という事が認識される。また、間接リンクの手法は、上記のものに限定されない。

図１ｃは、本発明の教示における、配信システムの更なる他の実施形態の図である。図示されるように、配信サーバ１０３は、ネットワーク１１３を経由して複数のクライアント・システム１０５、１０７および１０９へ情報を配信するために接続される。一実施形態において、ネットワーク１１３は、例えばインターネット、広域ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、イントラネット等のような、複数のデバイスが通信し得る任意の種類の通信ネットワークであって良い。

図１ｃに示された実施形態において、クライアント・システム１０５は配信サーバ１０３から配信される情報を配信リンク１１５を経由して受信するために接続される。同様に、クライアント・システム１０７は配信サーバ１０３から配信される情報を配信リンク１１７を経由して受信するために接続され、クライアント・システム１０９は、配信サーバ１０３から配信される情報を配信リンク１１９を経由して受信するために接続される。図１ｃに示された実施形態において、配信リンク１１５、１１７および１１９は、ネットワーク１１３からネットワーククライアント・システム１０５、１０７および１０９までの双方向リンクとして示され、クライアント・システム１０５、１０７および１０９が配信サーバ１０３に情報を送信する事が可能になる、と言うことが注目される。

図２は、本発明の教示における配信サーバ１０３、またはクライアント・システム１０５、１０７または、１０９に使用され得る機器３０１の一実施形態を示すブロック図である。通常、クライアント・システム１０５、１０７または、１０９は、セットトップ・ボックス１０２、デスクトップ・コンピュータあるいはワークステーション１０４、およびラップトップ・コンピューター１０６を含む様々なタイプの機器を使用し得る。サーバ１０３用に使用される機器は、通常コンピュータ・サーバ１０８、あるいは複数のクライアントにデータを配信するために設計される同様の種類のサーバ・ハードウェアを含む。一実施形態において、機器３０１は、バス３０７に接続されたプロセッサ３０３を備えるコンピュータまたはセットトップ・ボックスである。一実施形態において、メモリ３０５、記憶装置３１１、ディスプレイ制御装置３０９、通信インターフェース３１３、入力／出力コントローラ３１５およびオーディオ・コントローラ３２７が更にバス３０７に接続される。

一実施形態において、機器３０１は通信インターフェース３１３によって外部システムと接続される。通信インターフェース３１３はＡＭ、ＦＭ、テレビ、デジタルテレビ、ＤＶＢ、無線電話信号等と互換性を有する無線送受信機を備えて良い。通信インターフェース３１３はアナログ・モデム、統合サービス・デジタル・ネットワーク（ＩＳＤＮ）用モデム、ケーブル・モデム、デジタル加入者回線（ＤＳＬ）用モデム、Ｔ１回線インターフェース、Ｔ３回線インターフェース、光学キャリアのインターフェース（例えばＯＣ−３）、トークンリング・インタフェース、衛星送信インターフェース、無線インターフェース、またはあるデバイスを他のデバイスに接続するための他のインターフェースを更に備えても良い。

一実施形態において、搬送波信号３２３が、アンテナ１１１と通信するために通信インターフェース３１３によって受信される。一実施形態において、搬送波信号３２５が、通信インターフェース３１３とネットワーク１１３間で送受信される。一実施形態において、通信信号３２５は、他のコンピュータシステム、ネットワーク・ハブ、ルータ等と機器３０１を接続するために使用されてもよい。一実施形態において、搬送波信号３２３および３２５は機械可読メディアであり、ワイヤ、ケーブル、光ファイバを経由して、大気を経由して、またその他の方法で送信され得る。

一実施形態において、プロセッサ３０３は、例えばインテル社のｘ８６系、即ちペンティアム系のマイクロプロセッサ、モトローラー系のマイクロプロセッサ等の従来のマイクロプロセッサであって良いが、それに限定されるものではない。メモリ３０５は、動的ランダムアクセスメモリ（ＤＲＡＭ）のような機械可読メディアであって良く、静的ランダムアクセスメモリ（ＳＲＡＭ）を備えていても良い。ディスプレイ制御装置３０９は従来の方法でディスプレイ３１９を制御する。一実施形態において、ディスプレイ３１９は、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、アクティブマトリクスディスプレイ、テレビジョンモニター等であって良い。入力／出力コントローラ３１５に接続された入出力装置３１７は、テレビのリモコン、マウス、トラックボール、トラックパッド、ジョイスティック等を備えるキーボード、ディスクドライブ、プリンタ、スキャナ等の入出力装置であって良い。一実施形態において、オーディオ・コントローラ３２７は、オーディオ出力３３１を従来の方法で制御する。オーディオ出力３３１は、例えばオーディオ・スピーカ、ヘッドホン、オーディオ・レシーバ、アンプ等を含んで良い。一実施形態において、コントローラは、オーディオ入力３２９を従来の方法で制御する。オーディオ入力３２９は、例えばマイク、オーディオまたは音楽機器等からの入力を含んで良い。

一実施形態における記憶装置３１１は、例えば磁気ハードディスク、フロッピディスク、光ディスク、読み取り専用メモリ（ＲＯＭ）コンポーネント、スマート・カードあるいはデータ用記憶装置の他の形式のような機械可読メディアを備えていて良い。機械可読メディアは、上記の例に限定されない。一実施形態において、記憶装置３１１はリムーバブル・メディア、読取専用メディア、読み書き可能なメディア等を備えていて良い。データの一部はコンピュータシステム３０１中のソフトウェアの実行の間にダイレクトメモリーアクセスプロセスによってメモリ３０５に書き込まれても良い。ソフトウェアが記憶装置３１１、メモリ３０５中に存在するか、もしくはモデムまたは通信インターフェース３１３によって送信または受信されても良いことが認識される。本明細書の目的のために、「機械可読メディア」と言う句は、データ・情報を格納出来る、またはデータプロセッサ３０３に本発明における方法を実行させるためにプロセッサ３０３によって実行される命令のシーケンスをエンコードすることの出来る任意のメディアを含むものと解釈される。「機械可読メディア」と言う句は、ソリッドステートメモリ、光学・磁気ディスク、搬送波信号等を含むものと解釈されるが、これらに限定されない。

一実施形態において、例えば図１ａ〜図１ｃに示された中の任意のシステムと同様の配信システムは、配信サーバ１０３が複数のデータを複数のクライアント・システム１０５、１０７、１０９に配信するようになされている。後述するように、本発明の一実施形態の教示において、複数のデータ・ファイルのそれぞれは、メタデータと共に記述されるそれぞれのコンテンツに対応する。通常、メタデータは、コンテンツ即ちデータ・ファイルがサーバ１０３から配信可能である、または配信の可能性がある旨を記述する１組のディスクリプタまたは属性値と見なすことが出来る。本発明におけるメタデータは、クライアント・システム１０５、１０７および１０９が、後に配信サーバ１０３から配信されるデータ・ファイルのコンテンツに関して推論し、情報に基づいた判断をすることを可能にする情報を提供する。後述するように、本発明の様々な実施形態は、クライアント側のフィルタリング、記憶装置の管理、および他のパーソナライズ技術のためにメタデータを用いると同様に、配信スケジュールおよび将来サーバが配信するコンテンツを決定する。

本発明は、クライアント・デマンド・フィードバック情報に基づいたコンテンツを配信する方法およびシステムを提供する事によって、所望されないコンテンツの配信に関する従来技術の多くの不適当な点を取り扱う。本発明は、最適化された配信スケジュールを生成するメカニズムを定義し、これによって、配信司令センターによる配信が考慮される様々なコンテンツ（例えば、映画、あらかじめ録画された、または生放送のテレビ番組など）に対応するコンテンツ記述情報がクライアント・システムに周期的に配信され、クライアント・システムは、ユーザ・フィードバック、ユーザの以前の視聴の習慣および他の考慮に基づいた自動フィードバック、前記の２つの組み合わせを使用して、コンテンツを格付け、および（または）ランキングする。その後、クライアント・システムからのデマンド・フィードバック・データが配信司令センターに返送され、配信司令センターは、クライアント・システムから受信したデマンド・フィードバック情報の少なくとも一部分に基づいて、配信される予定のコンテンツの順序づけられたリストを含む配信スケジュール・キューを生成または更新する。その後、配信スケジュール・キュー中のコンテンツの位置に基づいて、コンテンツがクライアント・システムに配信され、配信される任意のコンテンツを、後続の「オンデマンド」の視聴のためにクライアント・システムによってキャッシュするかどうかを、クライアント・システムが選択的に決定し得る。一実施形態において、このプロセスは連続的に繰り返され、これによって、配信司令センターは、予定された配信スケジュールを使用しなければならない従来の方法とは異なり、クライアント・デマンド・フィードバックに基づいて配信スケジュールを最適化することが可能になる。

本発明の典型的な実施例に対応するフローチャートを図３に示す。前述したように、第１の作業は、配信司令センターによって提供されるコンテンツを視聴することを所望し得るユーザによって操作され得る様々なクライアント・システムにコンテンツ記述情報を供給することである。一実施形態において、コンテンツ記述情報は、配信のスケジューリングに際して考慮されるコンテンツのそれぞれのためのコンテンツ・ディスクリプタを含むメタデータとして送信される。一般に、コンテンツ・ディスクリプタは、コンテンツ記述情報をキャプチャするために、任意の時点においてクライアント・システムが利用することができる連続的なストリームとして送信され得る。必要に応じて、ストリームが何処にあるか（例えば、ストリームが配信されるチャンネル）、およびストリームをどのように配置するかについてのアナウンスが、コンテンツ・ディスクリプタ・ストリームに先行しても良い。また、コンテンツ・ディスクリプタ・メタデータが周期的にファイルとして送信されても良い。一実施形態において、クライアント・システムがコンテンツ・ディスクリプタ・メタデータを受信・格納する事が出来るように、コンテンツ記述ファイルが間も無く送信されるという事をクライアント・システムに通知するトリガが、クライアント・システムに送信されても良い。

ブロック３００によって示されるように、一実施形態において、メタデータ配信スケジュールは、適切な配信リンクに渡ってクライアント・システムに配信される。例えば、図４ａに示されるように、クライアント・システムはセットトップ・ボックスを含み得、また、配信リンクは衛星テレビ配信リンクを含み得る。この例では、配信司令センター１２６Ａによって操作された配信サーバ１０３Ａは、地上局１３２を経由して衛星１３０にアップリンク信号１２８を送信する。その後、衛星１３０は、衛星からそれぞれのアンテナ１３４、１３６および１３８へのデータの無線周波数（ＲＦ）送信によって形作られる無線周波数（ＲＦ）リンク１１５Ａ、１１７Ａおよび１１９Ａによってメタデータ配信スケジュールをクライアント・システム１０３Ａ、１０５Ａおよび１０７Ａに配信する。一般に、衛星１３０は所定の無線周波数帯を使用して、データ・ストリームを送信する多重チャンネルトランスポンダとして機能し、各周波数帯はそれぞれのチャンネルに対応する。一実施形態において、選択されたチャンネルは、該メタデータ配信スケジュールデータを送信するために使用されてもよい。他の実施形態において、以下に詳述されるように、選択されたチャンネルあるいは多重チャンネルの未使用の部分は、スケジュールデータを送信するために使用されてもよい。

上述されたように、衛星ＲＦリンクを経由してコンテンツを配信することに加えて、コンテンツは、ケーブルテレビ・システムおよびコンピュータ・ネットワークのような様々なネットワーク上に配信されても良い。双方向ケーブルテレビ・システムを使用して本発明を実施するためのシステムの一例が、図４ｂに示される。このシステムでは、配信司令センター１２６Ｂによって操作される配信サーバ１０３Ｂが、ケーブルテレビ・システム・ヘッドエンド１４２に、メタデータ配信スケジュールのような配信データを提供する。該ケーブルテレビ・システム・ヘッドエンドによって、ケーブルテレビ・システムのための配信機能が提供され、データがケーブルテレビ・ネットワーク１１３Ｂおよびそれぞれの双方向ケーブルリンク１１５Ｂ、１１７Ｂおよび１１９Ｂを経由して、セットトップボックス・クライアント・システム１０５Ｂ、１０７Ｂおよび１０９Ｂに配信される事が可能になる。

配信およびクライアントのフィードバック・データがコンピュータ・ネットワークを経由して送信することによって発明を実施するためのシステムの一例が、図４ｃに示される。本実施形態において、配信司令センター１２６Ｃによって操作される配信サーバ１０３Ｃは、コンピュータ・ネットワーク１１３ｃ上からネットワークリンク１１５Ｃ、１１７Ｃおよび１１９Ｃを経由してコンピュータ・クライアント・システム１０５Ｃ、１０７Ｃおよび１０９Ｃまで、ＵＤＰまたはＴＣＰ／ＩＰのような共通ネットワークプロトコルあるいは様々な新興のコンピュータ・ネットワーク配信プロトコルの中の１つを使用してデータを配信する。

一実施形態において、本発明の実際のメタデータが配信サーバによって配信される予定の場合、メタデータ配信スケジュールは将来におけるある時点を示す。一実施形態において、クライアント・システムは、配信サーバから間も無く提供されるサービスのアナウンスに対して待機するために、プログラムおよびシステム情報プロトコル（ＰＳＩＰ）、ＤＶＢ、サービス・アドバタイジング・プロトコル（ＳＡＰ）等に使用されるの既知のポートを使用する。

一実施形態において、各クライアント１０５ｘ、１０７ｘおよび１０９ｘ（ここで、例えば１０５ｘは、１０５Ａ、１０５Ｂ、１０５Ｃ等を包含する）は、配信サーバ１０３ｘによって配信される情報を受信するために、特定の時間に起動するリクエストを受け入れるような既知のスケジューリング・サービスを含む。このスケジューリング・サービスによって、クライアント・システムが特定の時間に起動し、特定のサービスを選択することが可能になる。例えば、一実施形態において、この選別プロセスは、ＡＴＳＣまたはＤＶＢトランスポンダ等の様に、特定の周波数にチューニングすることにより達成され得る。一実施形態において、選別プロセスは、例えば、サービスを定義するマルチキャスト・インターネット・プロトコル（ＩＰ）アドレスの様なデータに基づき得る。

一実施形態において、特定のコンテンツ・プロバイダから信号を受信するために、クライアント・アプリケーションはクライアント・シグナリング・システムに登録する。クライアント・シグナリング・システムは、特定のコンテンツ・プロバイダに関連したアプリケーションのテーブルを保持する。一実施形態において、配信サーバからの情報は既知のアドレス上に配信され、各クライアントが該既知のアドレスを使用する事が出来る様になされる。

図３のフローチャートを再び参照し、ブロック３０４において、クライアントは配信サーバからメタデータ配信スケジュールを受信する。一実施形態において、クライアント・システム１０５ｘ、１０７ｘおよび１０９ｘは、何時起動してコンテンツを受信するか、コンテンツを何処に受信するか、およびどのコンテンツを受信するかを決定するために、この配信前の情報をキャプチャし、処理する。一実施形態において、メタデータ配信スケジュールがクライアント・システムによって受信される時、クライアント・システム内に登録されたアプリケーションが、メタデータ配信スケジュールを受信するために通知される。

他の実施形態においては、メタデータそれ自体が、クライアント・システムが任意の時点において利用可能なストリームとして連続的に配信される。従って、これらの実施形態において、ブロック３００および３０２のオペレーションは必ずしも必要では無い（図中において破線で示した輪郭は、任意のオペレーションであるという事を示す）。ストリーミングの実施形態が使用される時、メタデータ・ストリームはストリーミングされているその時点におけるメタデータの開始点を示すためのトレーサ信号を含み、クライアント・システムが２つのトレーサ信号が受信される間にのみメタデータを待機する様になされるのが望ましい。これによって、ストリーミングされているその時点におけるメタデータが完全な形で受信された事が保証される。オプションとして、クライアント・システムは、個々のコンテンツ・ディスクリプタを、ストリームのオカレンスとして記録しても良く、これによって、クライアント・システムが以前に受信したコンテンツ・ディスクリプタと遭遇する時、クライアント・システムは、メタデータを完全な形で受信した事を認識する。

ブロック３０４において、メタデータ配信スケジュールにおいて指定された時間に、または、連続的なストリーミングを用いて、メタデータ１２７（図４ａ〜図４ｃを参照）が配信サーバからクライアント・システムまで配信される。一実施形態において、サーバからメタデータ１２７を受信するために、クライアントは、メタデータ配信スケジュールに示される予め指定された時間に起動する。ブロック３０６において、クライアント・システムは、配信サーバからメタデータの配信を受信する。後述するように、メタデータは、サーバ・システムによってその後配信される、または配信される可能性のある複数のデータ・ファイルの記述を含む。この時点で、図３および図４ａ〜図４ｃ中の丸印で囲まれた数字の１によって示されるように、クライアント・システムにメタデータを供給する第１の作業が完了する。

ブロック３０８によって示される様に、メタデータ１２７を受信した後、どのコンテンツが配信される事をクライアント・システムのユーザが所望するかを示すクライアント・デマンド・フィードバック・データを配信司令センターへ提供するために、クライアント・システムがメタデータに対応するコンテンツを格付けおよび（または）ランキングし、該コンテンツが、クライアント・システムのユーザが「オンデマンド」で視聴するためのクライアント・システムにキャプチャ・キャッシュされ得るようになされる。クライアント・システムがクライアント・デマンド・フィードバック・データを生成し得る３つの方法がある。１番目の実施形態において、クライアント・システムのユーザは、その時点におけるメタデータによって記述されたコンテンツを手動で格付けまたは相対ランキングを提供しても良く、これによって、何を配信される事を所望するかの直接的な指示を提供する。このプロセスはフローチャート中のブロック３１０によって提供され、以下に詳述される。２番目の実施形態において、格付けおよび（または）相対ランキング・データは、ブロック３１２において、ユーザの以前の視聴の嗜好度の少なくとも一部分に基づいて、クライアント・システムによって自動的に生成される。このプロセスも、以下に詳述される。３番目の実施形態において、クライアント・デマンド・フィードバック・データは、ユーザおよびクライアント・システムによって生成された格付けおよび（または）ランキング・データの組み合わせを含む。

ブロック３１４において、クライアント・システムはデマンド・フィードバック・データをサーバに送信し、サーバは、ブロック３１６においてデータを受信する。図４ａ〜図４ｃにおいて、デマンド・フィードバック・データは「クライアント・フィードバック・データ」１２９、即ち「ＣＦＤ」１２９として示され、デマンド・フィードバックを配信司令センターへ返送するプロセスは、図３および図４ａ〜図４ｃ中の丸印で囲まれた数字の２によって示される。一実施形態において、配信ネットワーク中の各クライアントは、配信サーバ１０３ｘから先立って配信されたその時点におけるメタデータ１２７に記載された全てのコンテンツに対応するデマンド・フィードバック・データを送信する。若しくは、以下詳述されるように、各クライアント・システムは、クライアント・システム上に保持されているコンテンツ格付け／ランキングテーブルの全部または一部を送信する。

使用される配信システムに依存して、配信司令センターへクライアント・デマンド・フィードバック・データを返送するために使用され得るいくつかの異なる種類の通信リンクがある。図１ｂに関して上述された様に、クライアント１０５、１０７および１０９のそれぞれは、通信リンク１２１、１２３および１２５によって示される「バックチャンネル」通信リンクを備える。図４に示されるような従来の衛星テレビ配信システムの場合には、衛星と受信アンテナの間に単一方向のリンクのみが存在する。その結果、テレコミュニケーション・ネットワーク１１３Ａおよびネットワークリンク１４４を経由して配信指令センター１２６Ａに配信するために接続されたクライアントからのリンク１２１Ａ、１２３Ａおよび１２５Ａによって示される様に、これらのシステムにおける配信指令システムに戻る通信リンクは、通常何らかの形式のテレコミュニケーション・リンクを含む。将来の衛星放送システムが、トランシーバ・アンテナを使用して、配信司令センターへクライアント・デマンド・フィードバック・データを返信することが出来る双方向通信リンクを提供し得る事が理解されるであろう。この種の通信技術は、ユーザに双方向衛星通信能力を提供する今日のＶＳＡＴ（超小型衛星通信地球局）技術と同様のものであり得る。

双方向ケーブルテレビ配信システムが使用される例においては、図４ｂに示されるように、所定のクライアント・システムのための同一の通信リンクが、配信データを配信司令センター１２６Ｂから受信するため、およびクライアント・デマンド・フィードバック・データを配信司令センター１２６Ｂに送信するための双方に使用されてもよい。同様に、図４ｃに示されるようにコンピュータ・ネットワーク配信インフラストラクチュアが使用される時、配信司令センター１２６Ｃからの配信データの受信、および配信司令センター１２６Ｃへのクライアント・デマンド・フィードバック・データの送信の際に、同一のリンクを使用する事が出来る。該コンピュータ・ネットワークにおいて、実際の「リンク」が動的であり得、データ・パケットは、クライアント・システムとサーバ間のようなエンドポイント間を動的経路指定を使用して伝送され得る、という事が注目される。しかしながら、説明の便宜上、これらのリンクは図４ｃにおいては実線として描かれる。

クライアント・デマンド・フィードバック・データ１２９を受信した後、配信司令センターは、クライアントデマンドフィードバックデータを集計する事によって、少なくともコンテンツの一部が順序付けられたリストを含む配信スケジュール・キュー１３３を作成または更新し、最も高いデマンドを有するコンテンツはリストの最上部に配置される。このプロセスは、図３および図４ａ〜図４ｃ中の丸印で囲まれた数字の３によって示される。一般に、該リストはクライアント・デマンド・フィードバック・データを集計することにより生成され、更に、コンテンツが最近配信されたかどうか、と言ったようなサーバ側の理由、および配信サービス・プロバイダとの契約上の協定のような様々な商業上の理由が適用されても良い。配信スケジュール・キューがどのように生成されるかについての詳細は、以下に記述される。

一実施形態において、その後、配信司令センターは、クライアント・デマンド・フィードバック・データに基づいて、配信するための複数のコンテンツを選択する。一実施形態において、配信が予定されるコンテンツは、クライアント・システムによって提供される格付け情報に基づいて決定される。その結果、需要家（つまりクライアント・システムのユーザ）にとって最も適切なコンテンツのみが、配信司令センターによって配信される。例えば、一実施形態において、最も高位の集計された格付けを有するコンテンツのみが配信され、一方では、最低の格付けを有するコンテンツは配信されない。一実施形態において、配信スケジュールもランキングに応じて決定される。例えば、一実施形態において、最も高くランキングされたデータ・ファイルが、より低くランキングされたデータ・ファイルの前に配信される。他の実施形態において、最も高くランキングされたコンテンツが、高くランキングされたコンテンツを送信するのに最も適切だと仮定される時間に配信される。例えば、木曜夜のゴールデンアワーが、配信業者にとって、最も高い格付けを配信するための最も重要な時間であると言う一例を仮定する。この例において、本発明の教示における配信司令センターは、木曜夜のゴールデンアワーに最も高いランキングを有するコンテンツに対応するデータ・ファイルを配信する。この実例は説明目的だけのために挙げられたものであり、配信司令センターは、クライアント・システムから受信されたデマンド・フィードバック・データに応じて他の方法で配信スケジュールを決定し得ることが明らかに認識される。

一実施形態において、配信するべきデータ・ファイルおよび（または）配信スケジュールは、本発明の教示において、クライアント・システムから受信されたクライアント・デマンド・フィードバック・データに応じて配信司令センターによって動的に決定される。従って、一実施形態において、配信司令センターからのどのコンテンツが利用可能であるか、および、どのコンテンツまたはデータ・ファイルがクライアントによってアクセス、および（または）分類されるかに依存して、配信スケジュールの時間を変更する事が出来る。

配信されるコンテンツおよび配信スケジュールが配信サーバによって一旦決定されると、その後、ブロック３２０において、配信サーバ１０３はクライアントにコンテンツ配信スケジュールを配信する。その後、ブロック３２２中において、クライアントがコンテンツ配信スケジュールを受信する。他の実施形態において、ブロック３２０および３２２が破線で示されている様に、コンテンツ・スケジュールの配信がなされない場合もある。

次に実行される処理は、（一般に）最も高いレベルのクライアントのデマンドを有するコンテンツをクライアントに配信する事である。これは、図３におけるブロック３２４および３２６によって示され、また、図３および図４ａ〜図４ｃ中の丸印で囲まれた数字の４によって示される。一実施形態において、便宜的なスケジューリングが使用され、２番目に「最も価値のある」コンテンツが連続して配信される。他の実施形態において、コンテンツのバッチが周期的に配信される。典型的なコンテンツＡ、ＢおよびＣに対応する１つ以上のデータ・ファイルの配信が図４ａ〜４ｃに示され、該コンテンツはコンテンツ・データ・ファイル１３５によって集合的に識別される。これらのコンテンツ配信の各実施形態が、以下に詳述される。

コンテンツ配信スケジュールが予め送信された実施形態については、スケジュール中の各コンテンツに対応するデータ・ファイルが、予定された時間に配信司令センターから配信される。一実施形態において、配信サーバからのコンテンツのデータ・ファイルを受信するために、データ・ファイル配信スケジュールに示された予め指定された時間にクライアントが起動する。他の実施形態において、コンテンツは「近リアルタイム」ベースで配信され、該コンテンツのために先立って配信されるスケジュール情報が存在しない。本発明の目的のために、「近リアルイム」とは、コンテンツが最も所望されるコンテンツであると確認された直後（例えば１時間以下）にコンテンツが送信されることを意味する。これらの例において、このようなコンテンツのためのスケジュールは配信されてもされなくても良い。

１つのコンテンツを配信した後、配信スケジュール・キューのために使用された順序付けられたリスト中のコンテンツを再度ランキングするために、該コンテンツに対応する属性値が再計算される。一般に、クライアント・システムによる該コンテンツに対するデマンドは、既に配信されたことによって満足しているはずなので、ブロック３２８によって示されるように、該コンテンツはリストの最下部に戻される。後述するように、該コンテンツに対するクライアント・デマンド・フィードバック・データは「リセット」され、順序付けられたリストが再計算される時、該コンテンツに関する新しい（即ち、後から受信された）クライアント・デマンド・フィードバック・データのみが考慮される。

配信されたコンテンツを受信した後、一実施形態において、ブロック３３０において示されるように、クライアントは、データ・ファイルが配信されるとともに、クライアント・システムに格納されたコンテンツ格付けテーブルに応じてデータ・ファイルを選択的に格納する。特定のコンテンツが所定のクライアント・システム上で何時キャプチャされてキャッシュされる（即ち、格納される）か、また、他の配信コンテンツが何時無視されるかを決定するために使用され得る様々なメカニズムがある。一実施形態において、クライアント・システムに格納されるコンテンツ格付けおよび（または）ランキング・データのようなクライアント・デマンド・フィードバック情報は、特定のコンテンツに対応するデータ・ファイルが何時キャプチャされキャッシュされる予定であるかを決定するために使用される。クライアント・システムの利用可能なスペースが考慮に入れられても良い。例えば、特定の映画が最大の格付けを有する事を示すコンテンツ格付けテーブルをクライアント・システムが有する場合、映画に対応するデータ・ファイルは、通常は配信される時点においてキャプチャされる。

いくつかの例において、新しいコンテンツをキャプチャしてキャッシュするべきかどうかについての決定は、クライアント・システム上に現在格納されているコンテンツをユーザがどのように格付けしたかに依存する。例えば、クライアント・システムが実質的に一杯であり（即ち、完全なデータ・ファイルまたは新しいコンテンツに対応するファイルを格納する事が出来ない状態であり）、クライアント・システム上に格納されている、未だ視聴されていない全てのコンテンツが新しいコンテンツよりも高い格付けを持っている場合、新しいコンテンツは無視される。キャッシュされ、および無視されるコンテンツの例が、図４ａから図４ｃによって示される。クライアント・システム１０５ｘは、選択的に、コンテンツＡおよびＢをキャッシュし、コンテンツＣを無視する。クライアント・システム１０７ｘは、選択的に、コンテンツＡをキャッシュしコンテンツＢおよびＣを無視する。クライアント・システム１０９ｘは、選択的に、コンテンツＣをキャッシュし、コンテンツＡおよびＢを無視する。

所定のクライアント・システム内の特定のコンテンツがアクセスされた場合、一実施形態において、ユーザが該コンテンツに対する格付けを当初行った時にユーザが該コンテンツを所望していた度合と比較すれば、ユーザはもはや該コンテンツにアクセスする事を所望していないと言う事が一般に推定されるであろう。開示のため、ユーザ・アクセスとは、ユーザがデータ・ファイルとインタラクトし、データ・ファイルを眺め、視聴し、聴取し、読み、消費する事等を含んでも良い。例えば、データ・ファイルにアクセスするユーザの１つの例は、クライアント内に格納されたデータ・ファイルのうちの１つによって提供される特定の映画を視聴するユーザや、特定の歌を聴取するユーザであってもよい。従って、ユーザがコンテンツを眺めるためにアクセスする時、コンテンツの該部分に対応するメタデータ・テーブル、およびコンテンツ格付けテーブル・エントリは、ブロック３３２において、クライアント・システムによって更新される。

図５は、本発明の教示における、メタデータ１２７を処理し、メタデータ・テーブルおよびコンテンツ格付けテーブルを更新・維持する際のクライアントのイベントの流れの一実施形態を示すより詳細なフローチャートである。具体的には、本処理は４０３より開始され、サーバから配信されたメタデータに含まれる属性および属性値によってメタデータ・テーブルが更新される。ブロック４０５において、メタデータによって記述されたデータ・ファイルのそれぞれへのエントリによってコンテンツ格付けテーブルがその後更新される。

一実施形態において、メタデータ・テーブル、コンテンツ格付けテーブルおよび複数のデータ・ファイルが既にクライアント・システム中に存在するという事を仮定する。一実施形態において、メタデータ・テーブル、コンテンツ格付けテーブルおよび複数のデータ・ファイルは、図２に示される実施形態中において例証されるように、クライアント・システム中のメモリ３０５、記憶装置３１１に格納・維持されても良いし、もしくは、機器３０１がローカル・ネットワーク等にアクセスすることによって格納・維持されても良い。

４個のコンテンツに対応するメタデータ５０１の一例が図６に示される。説明の目的のために、４個のコンテンツに対応するデータ・ファイルは、映画やテレビ番組の様なオーディオ／ビデオファイルであると仮定される。上述されたように、配信されたデータ・ファイルは、オーディオ、グラフィックス、テキスト、マルチメディア等の様な他の種類のファイルを含んでも良い。

例示された実施形態において、メタデータ５０１は、４個の映画、すなわち、より詳細には４個の映画に対応する４個のデータ・ファイルが、配信指令センターによって配信される事が考慮される事を示す。これらの映画は、「アクション・ジュード」、「ファニー・ショー」、「激写！」および「ハーディー珍道中」を含む。一般に、メタデータは、該メタデータが対応するそれぞれのコンテンツを「記述する」属性および属性値を含んでいる。一実施形態において、メタデータはテーブル状のフォーマットで配信され、属性値は該フォーマットにおけるカラムに対応する。また、属性値はメタデータのために行データを含む。例えば、メタデータ５０１は、「名前」、「俳優」および「ジャンル」とラベルが付された３つの属性カラムを含む。本発明の他の実施形態においては、異なる属性や異なる属性値を含んでいても良いことが認識される。例えば、映画について記述するために使用され得る他の属性の非網羅的なリストは「監督」、「共演俳優」、「年」、「効果」、「エンディング」等を含んでいても良い。一実施形態において、例えば、４０〜５０の異なる属性が、本発明の教示において映画について記述するために提供される。

メタデータ５０１のセットの例において、「アクション・ジュード」は俳優「ジョー・スミス」主演の「アクション」映画である。「ファニー・ショー」は女優「ジェイン・ドウ」主演の「コメディー」映画である。また、「激写！」は俳優「ジェイン・ドウ」主演の「アクション」映画である。「ハーディー珍道中」は「ジョー・スミス」主演の「コメディー」映画である。

本発明のメタデータ・テーブルの様態を例示するのを支援するために、図７はメタデータ・テーブル６０１の一実施形態の例である。メタデータ・テーブル６０１は、各クライアント１０５、１０７および１０９のそれぞれによってローカルで更新・維持される。例示された実施形態において、図６のメタデータ・テーブル６０１は、サーバ１０３から過去に配信されたメタデータ５０１に含まれるデータを含む。一実施形態において、メタデータ・テーブル６０１は、属性、属性値および対応する関連値および信用度のリストを含む。具体的には、メタデータ・テーブル６０１は属性値「ジョー・スミス」、「ジェイン・ドウ」、「アクション」および「コメディー」を含んでいる。この時に、属性値「ジョー・スミス」、「ジェイン・ドウ」、「アクション」および「コメディー」に対する関連値および信用度はすべて０である。後述されるように、一実施形態において、本発明における関連値および信用度は、ユーザがクライアント・システムとインタラクトするのにつれて更新・維持される。

一実施形態において、メタデータ・テーブル６０１中の関連値は、特定のユーザの挙動を予想するための、関連する属性と属性値とがどれくらい関連があるかに関する指標である。例えば、関連値は、ユーザが特定の属性値が付されているという理由により特定の映画を観る可能性がどのくらいあるかを示す。一実施形態において、メタデータ・テーブル６０１中の関連値は、例えば−１０〜１０の範囲内の値を持つ。後述されるように、例えば、ユーザが特定の映画を観るか、少なくとも特定の属性値を有する特定の映画への興味を示せば、関連値が増加しても良い。反対に、ユーザが例えば特定の映画を観なければ、あるいは特定の属性値を有する特定の映画を観たくない事をユーザが直接的に示せば、関連値が減少しても良い。

一実施形態において、メタデータ・テーブル６０１中の信用度は、ユーザが特定の属性値を有する特定のコンテンツに実際にアクセスするかどうかを格付けまたは予想する際に、特定の属性と属性値のペアに適用される重み関数である。一実施形態において、メタデータ・テーブル６０１中の信用度は、−１０〜１０の範囲内の値を持つ。一実施形態において、属性値がユーザの興味を示すコンテンツを正確に予想する場合に信用度が増加させられても良い。反対に、ユーザがコンテンツに興味を持っているのに特定の属性値にそうでないと示されていた場合、信用度が減少しても良い。

一実施形態において、メタデータ・テーブル６０１のエントリは、サーバ１０３から配信される潜在的なコンテンツ即ちデータ・ファイルに関連した、全てのメタデータ５０１の集計から形成される。一実施形態において、メタデータ・テーブル６０１のエントリは、直接的なユーザのリクエストに基づいて更新される。さらに、メタデータ・テーブル６０１への更新は、ユーザが直接的に特定の映画を分類するかどうかとは無関係に、ユーザが特定の属性値を有する特定のデータ・ファイルにアクセスするかどうかに間接的に基づいて良い。

本発明のコンテンツ格付けテーブルの様態を例示するのを支援するために、図８は、コンテンツ格付けテーブル７０１の一実施形態の例を示す。一実施形態におけるコンテンツ格付けテーブル７０１は各クライアント１０５ｘ、１０７ｘおよび１０９ｘによってそれぞれローカルに更新・維持される。例示された実施形態において、コンテンツ格付けテーブル７０１は、メタデータ５０１に記述されたデータ・ファイルのリスト、および、クライアント・システムによってローカルに格納またはキャッシュされているすべての追加のデータ・ファイルを含む。

一実施形態において、以前にキャッシュされたコンテンツに対応するデータ・ファイルは、例えば図２に示されるクライアントのメモリ３０５、記憶装置３１１にローカルに格納されてもよいし、機器３０１によってローカルにアクセス可能なネットワーク中に格納されてもよい。本開示の目的のために、クライアントによってローカルに格納されるデータ・ファイルは、サーバ以外の既知のネットワーク記憶装置のクライアントによって「ローカルに」格納されるデータ・ファイルを含むものとして解釈しても良い。本開示の目的のために、クライアントによってローカルに格納またはキャッシュされるデータ・ファイルは、将来のアクセス、読み取り、あるいは消費に備えて格納されているデータ・ファイルとして解釈される。一実施形態において、本発明のローカルキャッシュは一次キャッシュであると見なされる。従って、本発明のローカルキャッシュは、ヒット率を増加させるようにサイジングされる。

オーディオ／ビデオファイルに代表されるデータ・ファイルの複数の例を再び参照して、映画は、クライアントによってローカルに格納される。ユーザが映画を観た後、映画によって占有された格納スペースは、その後配信される別のコンテンツの記憶装置として利用可能であると一般に考えられる。従って、本発明の教示において、クライアント・システムのローカルキャッシュは、例えばファイア・アンド・フォゲットのような一回使用システムとしてモデル化されることが認識される。一実施形態において、ユーザがデータ・ファイルにアクセスする場合、ユーザは再びその同じデータ・ファイルにアクセスすることを欲しないであろうと仮定される。ユーザが特定のコンテンツを観ていなければ、そのコンテンツによって占有された格納スペースが別のコンテンツの記憶装置のために利用可能では無いという事が通常考えられる。しかしながら、余分な利用可能な格納スペースが無く、より高く格付けされたコンテンツが配信されることになっている場合、本発明の教示において、より低く評価された未鑑賞コンテンツはより高く評価されたコンテンツと取り替えられる。例えば、一実施形態において、クライアント・システムのユーザは、より高く格付けされたコンテンツに対応するデータ・ファイルが配信される時に、格納されているデータ・ファイルを、より高く格付けされたコンテンツと対応する１つ以上のデータ・ファイルと自動的に交換する事を可能にするスイッチを選択してもよい。反対に、ユーザは、どのデータ・ファイルがクライアント・システムに格納されるかを手動で管理することを望んでもよい。

図８に示されるコンテンツ格付けテーブル７０１の実施形態を再び参照して、各映画はさらに関連する「格付け」値、「格付けタイプ」指標、「キャッシュ状況」指標、および「次回処理」指標を有する。一実施形態において、格付け値は、関連するコンテンツを受信するための願望レベルを示す。一実施形態中における格付け値は、ユーザによって直接的に入力されても良いし、あるいは、特定のデータ・ファイルに関連するメタデータを処理する事によってクライアント・システムによって間接的に生成されても良い。一実施形態において、格付け値が比較的高い場合、特定のデータ・ファイルに対してユーザが興味を示す可能性があることが予想される。反対に、格付け値が比較的低い場合、特定のデータ・ファイルに対してユーザが恐らく興味がないことが予想される。

一実施形態において、「格付けタイプ」指標は、特定のコンテンツの格付け値が、ユーザからの直接的な入力の結果だったか、それともクライアント・システムによって間接的に生成されたかどうかを示す。従って、一実施形態において、コンテンツ格付けテーブル７０１の「格付けタイプ」指標は「直接的」、「間接的」、または、データ・ファイル即ち映画がまだ評価されていない場合には「Ｎ／Ａ」となり得る。一実施形態において、データ・ファイルがユーザによって直接的に分類された場合、データ・ファイルの属性値の格付け値は以後クライアント・システムによって間接的に更新される事は無い。しかしながら、データ・ファイルがまだ分類されていないか、間接的にクライアント・システムによって評価されているだけの場合、データ・ファイルの属性値の格付けはクライアント・システムによって更に更新・調整されても良い。

一実施形態において、「キャッシュ状況」指標は、特定のデータ・ファイルがクライアントによってローカルに格納またはキャッシュされているかどうかを示す。図８に示された実施形態において、映画「アクション・ジュード」、「ファニー・ショー」および「激写！」は、既にクライアント・システムのローカルの記憶装置に存在する。反対に、映画「ハーディー珍道中」は、クライアント・システムのローカルの記憶装置に格納されていない。

一実施形態において、次回処理指標は、特定のデータ・ファイルに対して講じられる将来の処置を記録するために使用される。例えば、映画がユーザによって既に観られた場合、次回処理指標は、特定の映画によって占有された格納スペースが別の映画の記憶のために利用可能であることを示すために「交換」を示す。一実施形態において、もし映画がユーザによってまだ観られていなければ、次回処理指標は「保持」を示す。一実施形態において、映画がクライアントによってローカルに格納されておらず、かつ特定の映画がユーザにとって興味のある可能性があると格付け値によって予想される場合、次回処理指標は、「キャプチャ」を示す。一実施形態において、映画がサーバによってまだ配信されておらず、格付けが、この映画がユーザにとって恐らく興味がないと予想する場合、次回処理指標は、「無視」を示す。

上述されたように、ユーザはどのコンテンツがキャッシュに入れられるか、また、どのコンテンツを無視するべきかを決定するのに利用される直接的な入力を提供してもよい。これらの入力は「分類」と称される。一実施形態中で、図９に示されるように、ユーザがコンテンツをキャッシュする事を欲するか否かを示すために、「受信」または「拒否」をそれぞれ入力または選択する事により、選択されたコンテンツを直接的に「分類」する事が出来る。図９に示された例において、ユーザは、映画「アクション・ジュード」をキャッシュする事を欲するという事を、該映画を「受信」と分類する事によって示し、映画「ファニー・ショー」に興味を持たないと言う事を、該映画を「拒否」と分類する事によって示した。この例において、ユーザは、残りの全ての映画に関する情報あるいは分類を提供していない。

図５を再び参照して、ユーザがデータ・ファイルのうちの何れかを分類した場合、判断ブロック４０７に対する回答はＹＥＳであり、また、ブロック４０９において、分類されたコンテンツの特定の属性の関連値がメタデータ・テーブル６０１内で更新される。ブロック４１１において、ユーザの分類に応じて調節された関連値と一緒に属性値を有するデータ・ファイルの格付けもまた調節される。ユーザがデータ・ファイルを分類していなければ、処理ブロック４０９および４１１はスキップされる。

ユーザが何時データ・ファイルを分類するかの例を示すために、図１０は、ユーザ分類に応じて更新または調節された後のメタデータ・テーブル６０１を示す。前述されたように、ユーザは、映画「アクション・ジュード」に興味を持っていることを示した。メタデータ５０１によって記述されたように、「アクション・ジュード」は俳優「ジョー・スミス」が主演する「アクション」映画である。従って、図１０のメタデータ・テーブル６０１Ａを参照して、属性値「ジョー・スミス」および「アクション」に対する関連値は、ユーザが「アクション・ジュード」への興味を直接的に示した事を反映させるために調節される。一実施形態において、関連値は、ユーザが興味を持っていた事を反映させるために増加させられる。後述するように、一実施形態において、各属性値に関連した信用度は、特定の属性値を有するコンテンツに対応するデータ・ファイルのユーザ・アクセスがあるまで更新されない。

図９の例を継続して、ユーザは、映画「ファニー・ショー」に興味を持たないことを示した。メタデータ５０１は、「ファニー・ショー」は女優「ジェイン・ドウ」が主演する「コメディー」映画であるという事を示す。従って、メタデータ・テーブル６０１Ａを再び参照して、属性値「ジェイン・ドウ」および「コメディー」に対する関連値は、ユーザが「ファニー・ショー」に興味を持たないことということを直接的に表現した事を反映させるために調節される。一実施形態において、関連値は、ユーザが興味を持たなかった事を反映させるために減少させられる。

図９の例を継続して、ユーザは、映画「激写！」および「ハーディー珍道中」に関する情報を提供しなかった。従って、「激写！」および「ハーディー珍道中」に関連した属性値の関連値は、メタデータ・テーブル６０１Ａの中で更新されない。

後述されるように、一実施形態において、コンテンツ格付けテーブル７０１中の格付けの更新は、ブロック４１１に記述された様に、メタデータ・テーブル６０１にリストアップされた属性値の関連値および信用度と関係する。ブロック４１１に生じる処理の詳細は、ブロック４１７に生じる処理と実質的に同一である。

図５を再び参照して、ユーザがデータ・ファイルのうちの何れかにアクセスする場合（例えば、ユーザが映画を観る場合）、判断ブロック４１３において判断されるように、ブロック４１５において、ユーザのアクセスしたデータ・ファイルの特定の属性値の関連値と信用度がメタデータ・テーブル６０１の中で更新される。その後、ロジックはブロック４１７へと進み、１回以上のユーザ・アクセスに応じて調節された関連値を持つ属性値を有するデータ・ファイルの格付けも調節される。ユーザがデータ・ファイルにアクセスしない場合、ブロック４１５および４１７がスキップされる。

データ・ファイルにアクセスするユーザの例を示すために、ユーザが映画「アクション・ジュード」を観ると仮定する。メタデータ５０１は、「アクション・ジュード」が、俳優「ジョー・スミス」主演の「アクション」映画である事を示す。一実施形態において、ユーザが特定のデータ・ファイルにアクセスまたはインタラクトする毎に、該映画の属性値の信用度が調節または更新される。一実施形態において、０を越える関連値を有する属性値については、その属性値が、ユーザがアクセスするであろうデータ・ファイルの予測値として正確に役立ったので、該属性値の信用度が増加させられる。一実施形態において、０未満の関連値を有する属性値に付いては、その属性値が、ユーザがアクセスするであろうデータ・ファイルの予測値として正確に役立たなかったので、該属性値の信用度が減少させられる。従って、図１１は、「アクション・ジュード」へのユーザのアクセスに応じて「信用度」カラムが更新または調節されたメタデータ・テーブル６０１Ｂを示す。この例において、これらの属性値に対する関連値が０を越えるものであったので、「ジョー・スミス」および「アクション」の信用度は増加させられる。

一実施形態において、間接的に格付けされたデータ・ファイルに関連した関連値も、ユーザ・アクセスに応じてメタデータ・テーブル６０１Ｂの中で増加させられる。しかしながら、図１１に示されたメタデータ・テーブル６０１Ｂの例において、「アクション・ジュード」は、ユーザによって直接的に分類された。一実施形態において、メタデータ・テーブル６０１の中の関連値は、ユーザによって直接的に分類されたデータ・ファイルへのユーザのアクセスに応じては更新されない。

図１２は、コンテンツ格付けテーブル７０１に対応し、ブロック４１７における「アクション・ジュード」へのユーザ・アクセスに応じて更新された後のコンテンツ格付けテーブル７０１Ａを示す。上述されたように、本発明の教示において、コンテンツ格付けテーブル７０１もまたブロック４１１において更新される。コンテンツ格付けテーブル７０１Ａに示されるように、「アクション・ジュード」は格付け値１を有する。図９に関して上述されたように、ユーザが直接的に「アクション・ジュード」を分類したので、「アクション・ジュード」の格付けタイプは「直接的」である。「キャッシュ状況」指標は、「アクション・ジュード」がクライアント・システムによってローカルに格納されていることを示す。ユーザが既に「アクション・ジュード」を観たので、「次回処理」指標は「交換」を示す。

一実施形態において、コンテンツ格付けテーブル７０１中の格付け値は以下のように決定される。メタデータ５０１は、「アクション・ジュード」が属性値「ジョー・スミス」および「アクション」を有することを示す。メタデータ・テーブル６０１Ｂは、「ジョー・スミス」が関連値１および信用度１を有することを示す。メタデータ・テーブル６０１Ｂは、さらに「アクション」が関連値１および信用度１を有することを示す。一実施形態において、特定のデータ・ファイルの格付け値は、データ・ファイルの全ての属性値についてのそれぞれの信用度と結合した全ての関連値を考慮して決定される。例えば、一実施形態において、データ・ファイルに対する格付け値は、データ・ファイルの属性値についての各関連値および対応する信用度の積の全部の平均と等しい。

例証すると、コンテンツ格付けテーブル７０１Ａ中の「アクション・ジュード」を参照して、「ジョー・スミス」の関連値および信用度の積は１×１＝１である。「アクション」の関連値および信用度の積は１×１＝１である。積の平均は、１と１の平均であり、１である。従って、コンテンツ格付けテーブル７０１Ａ中の「アクション・ジュード」の格付けは、１である。

同様に、コンテンツ格付けテーブル７０１中の「激写！」に関して、「激写！」は属性値「ジェイン・ドウ」および「アクション」を有する。メタデータ・テーブル６０１Ｂ中の「ジェイン・ドウ」の関連値および信用度は、それぞれ−１と０である。従って、コンテンツ格付けテーブル７０１Ａ中の「激写！」の格付けは、１×０と１×１の平均値、即ち０．５である。図１２に示される例におけるコンテンツ格付けテーブル７０１Ａ中の「ファニー・ショー」および「ハーディー珍道中」のための格付けは、本発明の一実施形態において同様の方法で決定される。

図９において、ユーザは映画「アクション・ジュード」および「ファニー・ショー」を分類したので、これらの映画は、コンテンツ格付けテーブル７０１Ａの中で示されるように「直接的」な格付けタイプを有している点に注目される。ユーザは映画「激写！」および「ハーディー珍道中」を分類しなかったので、これらの映画はコンテンツ格付けテーブル７０１Ａで「間接的」な格付けタイプを有する。

本発明の教示において、コンテンツ格付けテーブル７０１中の格付け値がどのように決定されるかの一例が、前述の記載によって供される事が認識される。本発明の教示において、格付け値は他の方法によって決定され得、コンテンツの属性値のそれぞれに対する関連値および信用度も考慮される、と言う点に注目される。

一実施形態において、コンテンツ格付けテーブル７０１Ａの「次回処理」カラムへのエントリは、特定のコンテンツに対する格付けとキャッシュ状況の値によって一部決定される。例えば、一実施形態において、０を超える格付けは、ユーザがその特定の映画に少なくとも何らかの興味を持っていると予想されることを示す、と言うことを仮定する。従って、映画「激写！」および「ハーディー珍道中」に対してユーザは興味を有する可能性がある。従って、次回の処理は、映画「激写！」が記憶装置の中で維持され、サーバによってその後配信される時に、映画「ハーディー珍道中」をキャプチャするということを示す。上述されたように、映画「アクション・ジュード」はユーザによって既に観られたので、次回の処理において交換されるようにマークされる。

一実施形態において、ユーザとクライアント・システム間の将来のインタラクションは、前述されたものと同様の処理に帰着する。例えば、ユーザが映画「激写！」を現在観ると仮定する。本例において、ユーザは映画を観る前に映画「激写！」を分類しなかった。一実施形態において、図１３のメタデータ・テーブル６０１Ｃに示されるように、このアクセスされた未分類データ・ファイル属性値の関連値および信用度の双方が、更新される。映画「激写！」は「ジェイン・ドウ」主演の「アクション」映画であることがメタデータ５０１より思い出されよう。図１１に示されるように、「ジェイン・ドウ」の関連値は、ユーザが「激写！」を観る前は０未満、即ち−１であった。しかしながら、この例において、女優「ジェイン・ドウ」が主演しているという事実にもかかわらず、ユーザは「激写！」を観た。従って、ユーザの鑑賞の傾向を予想する際に、該特定の属性値は今となってはあまり適当で無く、信頼性も無いので、属性値「ジェイン・ドウ」の信用度は下方へ調整される。一実施形態において、関連値は既に０未満であるので、信用度はさらに下方には調節されない。しかしながら、ユーザが「激写！」を観る前から「アクション」の関連値は０を超えていたので、属性値「アクション」に対する関連値および信用度が上方に修正される。従って、この例において、関連値は１から２に上げられ、また、信用度も１から２に上げられるように調整される。従って、コンテンツ格付けテーブル６０１Ｃはこの時点で、「アクション」映画がユーザが観る可能性がより高い映画であると予想する。

一実施形態において、ユーザがクライアント・システムとインタラクトする毎に、メタデータ・テーブル６０１およびコンテンツ格付けテーブル７０１が更新される。ユーザが直接的にコンテンツを分類する場合と同様に、ユーザがコンテンツのそれぞれに対応するデータ・ファイルにアクセスする場合に、メタデータ・テーブル６０１およびコンテンツ格付けテーブル７０１の更新が行なわれる。本発明の教示において、メタデータ・テーブル６０１およびコンテンツ格付けテーブル７０１が更新されるために、ユーザが直接的にコンテンツを分類する必要が無いという事が認識される。その結果、コンテンツ格付けテーブルは、ユーザが興味を持っているコンテンツを何時でも正確に予想する。

一実施形態において、ユーザが直接的に興味を分類したコンテンツと同様、ユーザが間接的に最も興味を持っていると予想されるコンテンツは、クライアント・システム上でローカルにキャッシュされるコンテンツとなる。その結果、ユーザが最も観たい可能性があるコンテンツは自動的にローカルに格納され、従って、本発明の教示において、これらのコンテンツは、ユーザが前もってこれらの映画を直接的にリクエストしたり、映画を識別するために用いられる基準を直接的に指定したりする事無く、「オンデマンド」で利用可能である。

以上明らかなように、本発明の教示において、各クライアント上にコンテンツに対応するデータ・ファイルをローカルに格納することによって、配信帯域幅はより効率的に利用される。実際、ユーザがクライアントのローカルの記憶装置から映画を観る場合、配信帯域幅は使用されない。さらに、メタデータ・テーブルおよびコンテンツ格付けテーブルのそれぞれを更新する際、本発明の教示におけるシステムで行なわれる相当量の処理が個々のクライアント・システムで行われる、と言うことが更に認識される。クライアントの数が増加した時のサーバに対する増分費用が最小であるので、本発明における分散処理によって、ここに開示された配信システムが非常に大量のユーザに対して拡張していく事が可能になる。

上述されたように、クライアント・システムは、過去の視聴習慣、コンテンツ格付けおよび分類に基づいて自動的に生成された、または、クライアント・システムのユーザによって手動で生成された、または自動・手動の組み合わせによって生成されたフィードバック情報を送信しても良い。例えば、図１１に関して上述されたように、それぞれのコンテンツに対する格付け値は自動的に生成された。

将来の配信が考慮されているコンテンツを、ユーザが格付けおよび（または）相対ランキングを提供する事を可能にするユーザ・インターフェース８０１の一例が図１４に示される。ユーザ・インターフェース８０１は、格付けタブ８０３およびランキング・タブ８０５、「ランキング更新」ボタン８０７、「ＯＫ」ボタン８０９および「キャンセル」ボタン８１１を備える。ユーザ・インターフェースは、垂直スクロール・バー８１０および水平スクロール・バー８１２を更に備えても良い。通常、格付けタブ８０３は、ユーザがコンテンツの各部分に対する格付け値８１７を入力し得る格付けカラム８１５に加えて、最近に送信されたその時点におけるメタデータに関係するカラムを含む使用中格付けテーブル８１３を含んでいる。図示された実施形態において、格付けテーブル８１３は、メタデータ５０１の全体を含んでいる。格付けテーブルは、監督、共演俳優、ストーリー等の他のメタデータ属性に対応する追加のカラム（図示されない）を含んでいても良い。これらの追加のカラムは水平スクロール・バー８１２を使用する事によりアクセスされて良く、一実施形態において、ユーザ・インターフェースは、どの属性カラムが現在表示されているかに拘わらず、格付けカラム８１５が常にユーザに見える様に設計される。

一実施形態において、ユーザは、選択された複数のコンテンツに対して０〜１００点の格付け値８１７を入力しても良い。低い格付け値は、コンテンツに対応するデータ・ファイルを受信する事にユーザが興味を持っていないという事を示し、高い格付け値は、ユーザがコンテンツに興味を持っているという事を示す。一実施形態において、ユーザは、キーボード、キーパッド等を使用して格付け値８１７を入力し得る。例えば、上述されたように、クライアント・システムは、リモコンや、図４ａおよび図４ｂのリモート・キーボード１３７によって示されたようなリモート・キーボードを経由して通常アクセスし得るセットトップ・ボックスを備えて良い。クライアント・システムがデスクトップ・コンピュータを含む時、図４ｃの中のキーボード１３９によって示されるように、コンピュータのキーボードがデータを入力するために使用されてもよい。オプションとして、ドロップダウン・コントロール８１９が各行に提供されても良く、セットトップ・ボックス・クライアント・システムのセットトップ・ボックスのカーソル装置（図示されず）、または図４ｃのマウス１４１によって示されるようなマウスまたは同様のコンピュータ・クライアント・システムの入力装置を経由して、ユーザがドロップダウン・リスト８２１から格付け値を選択する事が出来る。

ランキング・タブ８０５の様々なユーザ・インターフェースの外観が図１５ａ〜図１５ｃに示される。ランキング・タブ８０５は、ランキングテーブル８２３を備える。ランキングテーブル８２３は、格付けカラム８１５がランキングカラム８２５に変更されているという事を除けば、格付けテーブル８１３のカラムと同様のカラムを有する。クライアント・システムによって受信されたその時点におけるメタデータに対応するコンテンツの全部または一部に対するユーザの相対ランキングを反映させるために、ユーザは、相対ランキング値８２７をランキングカラム８２５に入力しても良い。例えば、図１５ａに示されるように、ユーザは１位、２位、３位等のランキング値を入力してもよい。オプションとして、図１５ａの中のカーソルのドラッグ・アンド・ドロップ動作８２９によって示されるように、ユーザは選択されたコンテンツをテーブル８２３内の新しい場所へドラッグ・アンド・ドロップしても良く、その結果が図１５ｂに反映されている。図１５ｃに示されるように、一実施形態において、ランキングテーブル８０５内のコンテンツがランキングを考慮して再度順序付けられるようにするために、ユーザはランキング更新ボタン８０７を使用しても良く、これによって、最高位にランクされたコンテンツがテーブルの最上段に位置する。

コンテンツの格付けおよび（または）相対的ランキングが手動で入力され、および（または）、自動的に生成された後、その時点におけるメタデータに対応するクライアント・デマンド・フィードバックが、配信司令センターへ返送される。一般に、クライアント・デマンド・フィードバック・データは周期的に、または非同期に返送され得る。例えば、メタデータがスケジュールに従って配信される実施形態においては、メタデータ配信スケジュールからオフセットしている同様のスケジュールが、配信司令センターへクライアント・デマンド・フィードバック・データを実質的に「バッチ」モードで送信させるために使用されてもよい。若しくは、所定の時間が経過した後、またはその時点におけるメタデータに対応するコンテンツをユーザが格付けまたはランキングしたことを検出した後、クライアント・デマンド・フィードバック・データが配信司令センターへ送信されても良い。これは、クライアント・デマンド・フィードバック・データがスケジュールに依存せず、実質的に任意の方式で送信されるので、「非同期」と称される。他の実施形態において、クライアント・システムが該コンテンツ用のコンテンツ・ディスクリプタを処理しつつ、個々のコンテンツのための格付けデータが配信司令センターへ送信される。

一般に、クライアント・デマンド・フィードバック・データは、所定のクライアント・システムのユーザがその時点におけるメタデータに対応するコンテンツの受信を願望する願望レベルを反映する。このフィードバック・デマンド・データは手動格付け、手動ランキング、自動生成格付け、またはこれらのフィードバック・デマンド属性値の組み合わせを含んでも良い。例えば、一実施形態において、クライアント・デマンド・フィードバック・データは、ユーザよって生成された格付けおよび（または）ランキングのみを備えても良く、クライアント・システムのユーザによって格付けおよび（または）ランキングされなかったコンテンツのフィードバック・データは存在しなくても良い。一実施形態において、ユーザによって生成されない全てのコンテンツの格付けは、図５のフローチャートを参照して前述されたプロセスを使用して自動的に生成される。更に他の実施形態において、自動および手動で生成されたフィードバックの組み合わせが使用されるが、フィードバック・データは、その時点におけるメタデータ中のコンテンツの一部分のみに対応する。

手動および自動の組み合わせによって生成されたデマンド・フィードバック・データが使用される例において、ユーザが受信する事を所望するコンテンツを示す願望レベルをより正確に反映する、共通に加重されたデマンド・フィードバック・データを提供するために、スケーリング／オフセット・アルゴリズムが適用されても良い。例えば、先の例において、自動的に生成された格付けは、−１０〜１０のスケール有する。その一方で、ユーザによって生成された格付けは、０〜１００のスケールを有する。共通のスケールを用いた格付け値を生成するために、２つのうちのどちらかのスケールが調整され得る。例えば、０〜１００のスケールに適合する等価な値を生成するために、−１０〜１０のスケールの各値に５を掛け、それに５０を加えても良い。他の例において、自動的に生成された格付けよりも、ユーザの直接的な格付けに高いウェイトを置く事が望まれ得る。従って、先の例において、自動的に生成される値の最大値である１０が、１００未満となるように調整されるために、−１０〜１０のスケールで自動的に生成された値が所定のスケール値を用いてスケーリングされ、その後オフセットされても良い。

手動でランキングされたコンテンツに加えて、他のコンテンツが、第１にこれらのコンテンツの格付け値を自動的に生成する事により、第２にこれらの格付け値を元に相対ランキングを生成する事により自動的にランキングされてもよい。一実施形態において、手動および自動でランキングされた値が組み合わせられる時、自動でランキングされた中で最も高くランキングされたコンテンツは、手動でランキングされた中で最も低くランキングされたコンテンツよりも下位にランキングされる。一実施形態において、自動でランキングされたコンテンツは、クライアント・デマンド・フィードバック・データに含まれる、組み合わせられた相対的なランキング中の任意の位置を占有し得る。更に他の実施形態において、手動でランキングされた中で最も低くランキングされたコンテンツと自動でランキングされた中で最も高くランキングされたコンテンツ間にはギャップが存在する。例えば、特定のメタデータが配信司令センターによって配信される事が考慮される４０個のコンテンツに対応し、ユーザがその中から選択されたコンテンツを１位から９位までランキングすると仮定する。その後、残りの３１個のコンテンツは１０位から４０位まで、または１５位から４５位まで、２０位から５０位まで等にランキングされても良い。これによって、自動的に生成されたランキングよりもユーザ・ランキングにウェイトを置く重み関数が提供されるであろう。

クライアント・デマンド・フィードバック・データを重み付けするのに使用され得る別の考慮は、特定のコンテンツをクライアントがキャッシュすることにより生まれ得る収益可能性である。例えば、ペイ・パー・ビュー方式コンテンツは、クライアント・デマンド・フィードバック・データ中のペイ・パー・ビュー方式コンテンツに対してデマンド「値」を増加させるような重み関数を有しても良い。一実施形態において、収益可能性はランキングが使用される時のタイブレークとして使用されても良い。他の実施形態において、収益可能性が格付け値または相対ランキング値を上昇させても良い。

本発明の別の形態において、クライアント・システムの分割に関し、異なる（または同一の）メタデータおよび対応するクライアント・デマンド・フィードバック・データが、異なるセグメント化されたクライアントによって送受信されても良い。例えば、クライアント・システムは、５組のクライアント・システム１５１、１５３、１５５、１５７および１５９を含む図１６に示されるように、地域に基づいて分割されて良い。即ち、北西地域ＮＷ、南西地域ＳＷ、中東地域ＭＥ、北東地域ＮＥおよび南東地域ＳＥを含む５つの地域に分割される。一実施形態において、様々なクライアントは地域のケーブルテレビプロバイダによって提供されるケーブルテレビ・システムのような、配信を受信するために使用されるネットワークに対応して分割される。例えば、図１６に示されるように、ＡＴ＆Ｔブロードバンド加入者１５２、南カリフォルニアのメディアワン加入者１５４、シカゴ地域のメディアワン加入者１５６、ニューヨーク地域のタイムワーナー・ケーブル加入者１５８、および南東部のＴＷＥ−ＡＮ加入者１６０に分割される。他の実施形態において、クライアントは、配信ネットワークを運営するＭＳＯ（広域ケーブルテレビ局）に基づいて分割される。例えば、ケーブルテレビＭＳＯの上位７局は、ＡＴ＆Ｔブロードバンド、タイムワーナー・ケーブル、コムキャスト・ケーブル・コミュニケーション、チャーター・コミュニケーション、コックス・コミュニケーション、アデルフィア・コミュニケーション、およびケーブルビジョン・システムズを含み、各ＭＳＯは広い地域を横断して分布する複数の地域ケーブルテレビ・システムを運営する。

図１６に示されるように、一実施形態において、同一の、または異なるメタデータおよび（または）後続のコンテンツの配信は、中央配信司令センター１６１から配信されて良い。中央配信司令センター１６１は、送信アンテナ１６２からアップリンクを経由して１つ以上の衛星１６４にデータを送信する。１つ以上の衛星１６４は、地域のケーブルテレビ局によってそれぞれ運営される受信アンテナ１６３、１６５、１６７、１６９および１７１にデータを配信する。地域のケーブルテレビ局は、その加入者にメタデータおよび（または）配信コンテンツを送信する。いくつかの例において、ケーブルテレビ局は、受信した配信データを「格納」し、ある時点において加入者へデータを「転送」する。この種の配信スキームは、多段階の「ストア・アンド・フォワード」配信として公知であり、データは異なる「段階」間で配信され、ある段階によって格納され、ある段階の配信スケジュールの優先度に対処するために次の段階へ転送される。図１６に示された実施形態において、この３つの段階は、中央の配信司令センター、地域ケーブルテレビ局および地域ケーブルテレビ局の加入者と対応するクライアント・システムである。この例において、ケーブルテレビ局は中間段に相当する。中央からのデータを受信・格納し、１つ以上の傘下の地域ケーブルテレビ局にデータを転送するＭＳＯの様な追加の中間段が存在してもよく、地域ケーブルテレビ局は独自に配信データを格納し、そして加入者に転送できる。一実施形態において、ＭＳＯは、複数の地域ケーブルテレビ局に対して異なる時間に配信データを転送する。

クライアント・システムが、衛星配信システム、またはクライアント・システムと配信指令センターを接続する他の種類の配信リンクから通信を受信するようになされている場合、クライアント・システムが中央指令センター１６１から直接データを受信し得る、と言う事が注目される。一実施形態において、図１６に示されるように、分割されたクライアントのそれぞれは地域のサーバ１７５にクライアント・フィードバック・データを供給する。その後、地域のサーバ１７５は中央の配信司令センター１５１へクライアント・デマンド・フィードバック・データを転送する。オプションとして、分割されたクライアントのそれぞれが配信を受信し、地域の配信司令センターにクライアント・デマンド・フィードバック・データを送信しても良い。

前述されたように、個々のクライアント・デマンド・フィードバック・データは様々なクライアント・システムによって生成されるとともに、それらは、配信司令センターに「バックチャンネル」コミュニケーションによって送り返され、配信スケジュール・キュー１３３を構築するための順序を構築するために集計される。使用される特定の「バックチャンネル」コミュニケーションは、配信およびフィードバック・システム・インフラストラクチュアに依存するであろう。一旦クライアント・デマンド・フィードバック・データがクライアントから送信されると、配信司令センターの「フロント・エンド」によって受信され、クライアント・デマンド・フィードバック・データが格納され処理されるデータベース１４９を操作するデータベース・サーバ１４７へと転送される。典型的なフロント・エンドは１つ以上のネットワークあるいはウェブサーバ１４８（図４ｃを参照）を備え得、クライアント・フィードバック・データを受信し、それをデータベース・サーバ１４７にルーティングするために使用されるアプリケーション・コードを有する。さらに、様々なスイッチおよびファイアウォールが、フロント・エンドとデータベース・サーバの間に設置されても良い（明瞭性を保つため、これらのシステムのフロント・エンドにおいて使用される様々なコンポーネントは図示されない）。他の実施例において、データベース・サーバ１４７は、これらのフロント・エンドのプロセスのために直接使用されてもよい。更に他の実施例において、クライアント・デマンド・フィードバック・データはローカルのサーバへ送信されても良く、続いて、配信司令センターによって操作されるデータベース・サーバにクライアント・デマンド・フィードバック・データを転送する。

上述されたように、自動的に生成された格付けは、ユーザの以前の視聴習慣（つまり、現在キャッシュされているか、または以前にキャッシュされていたコンテンツに対する反応）、ユーザによって提供された、および関連性と信用度の使用を通じた以前の格付けと分類の組み合わせによって導かれる。いくつかの例において、ユーザの以前の視聴習慣に関係するデータは、プライバシーの関係により使用されなくても良い。しかしながら、プライバシーの問題の大半を解決するために、一実施形態において、クライアント・デマンド・フィードバック・データは、クライアント・デマンド・フィードバック・データがどのクライアントから、および（または）どのユーザから送信されたかを識別しないことを保証される機構によって配信センターに返送される。例えば、プロキシーとしてサードパーティーを使用する暗号プロセスを通じて、この「匿名」クライアント・スキームが実施され得、クライアント・デマンド・フィードバック・データはそこで暗号化され、配信司令センターあるいは他のパーティーがアクセス不可能なプライベート・キーを使用するサードパーティーによって操作される解読サービスを経由しなければならない。その後、サードパーティーは配信司令センターへクライアント・デマンド・フィードバック・データを転送する。この方式では、所定のクライアント・デマンド・フィードバック・データがどのクライアント・システムから受信されたのかを、配信司令センターが知る方法が無い。

クライアント・デマンド・フィードバック・データ１７５の一例が、図１７に示される。クライアント・デマンド・フィードバック・データ１７５は、ユーザによって、および（または）自動的に生成された格付けおよび（または）相対的なランキング・デマンド・データが格納されるコンテンツ・フィードバック・デマンド・テーブル１７７を含んでいる。このデマンド・データに加えて、クライアント・デマンド・フィードバック・データのそれぞれは、そのデータを組織して適切なクライアント・デマンド・フィードバック・データ（すなわち、最新のメタデータに対応するクライアント・デマンド・フィードバック・データ）だけが配信スケジュール・キュー１３３を決定するようにするために、データベース１４９によって使用されるメタデータ・セットＩＤを備える事が好ましい。例えば、配信されるメタデータのそれぞれは、該メタデータをユニークに識別するためのタイムスタンプまたは番号を含むメタデータＩＤ１７９を有しても良く、このメタデータＩＤはコンテンツ・フィードバック・デマンド・テーブル１７７中のデータと一緒に送り返される。クライアント・システムが分割されている実施例において、クライアント・フィードバック・データ１７５は地域ＩＤ１８１、地域配信システムＩＤ１８３およびＭＳＯＩＤ１８５によって例示されるような、１以上の対応するセグメントＩＤを備える事が好ましい。

一般的に、コンテンツ・フィードバック・デマンド・テーブル中のカラムは様々なクライアント・システムによって提供されるフィードバック・データの種類に依存して変化し得る。しかしながら、コンテンツ・フィードバック・デマンド・テーブルは、クライアント・デマンド・フィードバック・データが関係するコンテンツを識別するために使用されるカラムを常に備える。図１７に示された実施形態において、このカラムは「コンテンツＩＤ」カラム１８７として示される。「コンテンツＩＤ」カラム１８７は、クライアント・デマンド・フィードバック・データが適用するそれぞれのコンテンツの名前を含むコンテンツＩＤを備える。各コンテンツＩＤは、英数字のユニークな組み合わせを含むことが好ましい。いくつかの例において、該リストは、全てのクライアント・デマンド・フィードバック・データに対応して、その時点におけるメタデータに対応するコンテンツ全てのためのコンテンツＩＤを含む。一方、他の例において、クライアント・デマンド・フィードバック・データの一部のみがクライアント・システムから受信されても良い。

自動的に生成された格付けが自動格付けカラム１９１に含まれている一方で、様々なコンテンツに対応するユーザによって生成された格付けがユーザ格付けカラム１８９に含まれる。他の実施形態において、ユーザおよび自動格付けは一つのカラムへ組み合わせられても良い。そのような実施形態において、他のカラムが、どの格付けが直接的にあるいは間接的に生成されたかを示すために使用されてもよい。この情報を提供することによって、重み値がデータベース・サーバ１４７によって様々な格付けデータに適用され得る。オプションとして、格付けデータは、クライアント・システムによって用いられた１つ以上の重み付けアルゴリズムによって既に重み付けられていても良い。

先述のカラムに加えて、「ユーザ・ランキング」カラム１９３はユーザによって生成された相対ランキングを含む。その一方で「コンビネーション・ランキング」カラム１９５は、ユーザおよび自動的に生成された相対ランキングの組み合わせを含んでいる。上述されたものと同様の方法で、相対的なランキング・データは、単一のカラム（例えば「コンビネーション・ランキング」カラム１９５）の使用を通じて提供され、どのように各コンテンツのランキングがなされたかを示す別のカラムや、ユーザおよび自動的に生成されたランキングのための別のカラムを含んでいても良いし、含んでいなくても良い。

クライアント・デマンド・フィードバック・データが格付けデータのみを有しても良いし、相対ランキング・データのみを有しても良いし、あるいは格付けおよび相対ランキング・データの組み合わせを含んでも良い、ということが注目される。更に、個々のクライアント・デマンド・フィードバック・データは、単一のコンテンツ・ディスクリプタに対応するデータ、その時点におけるメタデータによって提供されるコンテンツ・ディスクリプタの一部、またはその時点におけるメタデータのそれぞれのコンテンツ・ディスクリプタに対応するデータを一般に含んでもよい。格付けフィードバックについては、クライアント・システムが、個々のコンテンツ・ディスクリプタのために格付けフィードバックを供給しても良く、対応するコンテンツ・ディスクリプタの受信に応じて、所定のクライアント・システムがメタデータの配信によって格付けフィードバックを行っても良い。例えば、一実施形態において、クライアント・システムの全部または一部は、コンテンツのためのコンテンツ・ディスクリプタの受信に応じて該コンテンツのそれぞれの格付けフィードバックを自動的に生成する。格付けフィードバックは配信司令センターへ送信され、非同期方式で集計される。相対ランキング・データの場合には、少なくとも２個のコンテンツがランキングされる必要がある。他の実施形態において、クライアント・デマンド・フィードバック・データのそれぞれは、その時点におけるメタデータに対応するそれぞれのコンテンツのフィードバック・データである、「完全な」形のフィードバック・データを含む。

様々なクライアント・フィードバック・デマンド・データが配信司令センターによって受信されるとともに、データベース・サーバ１４７によってデータベース１４９に格納される。一般的に、データベース・サーバ１４７は、オラクル（例えばオラクル８ｉエンタープライズ・エディション）、マイクロソフト（ＳＱＬサーバ７）、インフォミックスおよびサイベースによって製作されたＳＱＬベースのＲＤＢＭＳサーバ製品のようなＲＤＢＭＳサーバ・ソフトウェアパッケージを実行するコンピュータ・サーバを含む。前述のデータベース・サーバ製品は、並列接続を使用して、大量のトランザクション・スループットを扱うように設計されている。他の実施形態において、マイクロソフト・アクセスおよびパラドックスのような、それほど複雑でないデータベース・サーバ製品が使用されてもよい。いくつかのシステム構成において、データベース・サーバおよび配信サーバは単一の機器を備えるだけでも良い。他の構成において、データベース・サーバおよび配信サーバは別個の機器を含んでも良い。

通常は、クライアント・フィードバック・デマンド・データは１つ以上のデータベース・テーブルを使用して、データベース１４９に格納される。１つ以上のデータベース・テーブルは、データベース「スキーマ」を集合的に含む。例えば、クライアント・デマンド・フィードバック・データ１７５に対応するデータは、「デマンド・データ」テーブル１９７に格納され得、「デマンド・データ」テーブル１９７は、メタデータＩＤが格納される「メタＩＤ」カラム１９９、地域ＩＤが格納される「地域ＩＤ」カラム２０１、配信ＩＤが格納さる「配信ＩＤ」カラム２０３、およびコンテンツＩＤが格納される「コンテンツＩＤ」カラム２０５を含む。デマンド・データ・テーブル１９７は、ユーザによる格付けデータが格納される「ユーザ格付け」カラム２０７、自動的に生成された格付けが格納される「自動格付け」カラム２０９、ユーザによる相対ランキングが格納される「ユーザ・ランキング」カラム２１１、およびユーザによる相対ランキングと自動的に生成された相対ランキングの組み合わせが格納される「コンビネーション・ランキング」カラム２１３をさらに含む。

配信スケジュール・キュー１３３は、データベース・サーバ１４７あるいは配信サーバ１０３によって保持され得、通常は、データベース１４９を照会することにより引き出される。通常、スケジュール・キュー１３３は、その時点におけるメタデータに対する、対応するコンテンツのコンテンツＩＤの順序付けられたリストを含み、該リスト上において、コンテンツＩＤはコンテンツに対応する相対的なデマンドに基づいて上から下まで順序付けて整列され、この順序はクライアント・システムによって提供されたクライアント・デマンド・フィードバック・データを集計することにより決定される。オプションとして、順序付けられたリストは、利用可能な配信帯域幅、様々な配信業者との契約上の要求事項等のような他の考慮に基づいて調節されても良い。

一実施形態において、それぞれのクライアント・フィードバック・データがデータベース・サーバ１４７によって受信されると、データが解析され、デマンド・フィードバック・データを有する各コンテンツに対応する個々の記録がデータベース１４９に入力され、そして、順序付けられたリストが、新しいデータに基づいて自動的に記録される。例えば、クライアント・デマンド・フィードバック・データはデータベース・サーバ１４７によって受信され、個々の「行」に変換され、「デマンド・データ」テーブル１９７に挿入される、境界がカンマよって定められたリスト、あるいはＸＭＬデータを含んでも良い。挿入の後、その時点におけるメタデータ用のメタデータＩＤを参照するデマンド・データ・テーブル１９７中の既存のデータに基づいた順序付けられたリストを記録するクエリ２１５を自動的に実行するために、デマンド・データ・テーブル１９７への「挿入後」トリガを使用することが出来る。その結果、配信スケジュール・キュー１３３は、配信司令センターによって受信されるそれぞれのクライアント・デマンド・フィードバック・データに応じて更新される。

クエリ２１５の更なる詳細が図１８に示される。一般的に、クエリ２１５は、クライアント・システム１０５、１０７および１０９から受信された様々なクライアント・フィードバック・データ１２９を集計することにより、配信スケジュール・キュー１３３のために使用される順序づけられたリストを生成する。上述されたように、これらのクライアント・デマンド・フィードバック・データはデータベース１４９中の１つ以上のテーブルに格納される。これらのテーブルに加えて、データベース１４９は、収益性の関数、メタデータ、重み関数、コンテンツ属性テーブル、分割テーブル等の様な、クエリ２１５によって使用される情報を含む他のテーブルを含んでも良い。一般的に、クエリ２１５はデータベース・サーバ１４７または配信サーバ１０３上で実行されるアプリケーションによって供給される様々な入力によって構築される。これらは、その時点におけるメタデータに対応するメタデータＩＤ２１７、分割が使用される場合に用いられる様々な分割ＩＤ２１９、格付け重み関数２２１、ランキング重み関数２２３、集計に関する関数２２５（例えば、合計、平均、最大等）、商業上の考慮２２７、また統計上の考慮２２９のうち１つ以上を含む。

配信スケジュール・キュー１３３を生成するために使用される特定のクエリは、配信司令センターによって提供される特定の入力に依存する。例えば、一実施形態において、格付けは順序付けられたリストを決定するために使用され、コンテンツは、平均による格付けあるいは統計の中間値による格付けのような、格付けの集計に基づいて順序付けられる。他の実施形態においては相対ランキングが使用され、順序付けられたリストは所定のランキングの関数に基づいて決定される。例えば、上位２５の大学のスポーツ・チームのランキングのような多くのランキングに使用されるランキングの関数が使用される。
その時点におけるメタデータについて、ランキングの範囲が決定される。例えば、その時点におけるメタデータが５０個のコンテンツに関するコンテンツ・ディスクリプタを含んでいる場合、かつ自動生成ランキングに対する手動生成ランキングのオフセットが使用されない場合、これらのコンテンツに関するクライアントのデマンド・フィードバック・データは１位から５０位までのランキングを有する（ここで、いくつかのコンテンツが該クライアント・システムの一部によってランキングされないかもしれないが、少なくともいくつかのクライアント・システムによって全てのコンテンツがランキングされる事が注目される）。その後、個々のランキング値が、最下位ランキング値に１を加えたものからの偏差に基づいて再計算される。例えば、現在の例においては、５１からの偏差が計算される。つまり、当初１位であったものは５０の値を取り、当初５０位であったものは１の値を取る。再計算された値は単に合計され、最大の合計値を有するコンテンツが順序付けられたリストの最上位に置かれる。

先述のスキームによって、ランキングの低いコンテンツよりも、ランキングの高いコンテンツに対して、より多くのウェイトを加えることができる。例えば、いくつかの例において、ユーザは、ユーザが興味を持たないコンテンツをランキングするよりも、ユーザが興味を持っているコンテンツをランキングすることにより興味を有しているであろう。従って、任意のランキング順位を有するコンテンツは、ウェイトを置かれていないコンテンツよりもデマンドが高いと考えられる。一方で、他の例においては、ユーザは特定のコンテンツをランク付ける傾向があるものの、それが配信される時にユーザが該コンテンツを通常キャッシュせず、ユーザが直接的にランキングしていなかったコンテンツをむしろキャッシュする事を決定する傾向にある場合がある。この場合は、コンテンツの自動的にランキングされた部分により多くにのウェイトが置かれても良い。他の実施形態において、格付けおよびランキング・データの組み合わせが、配信スケジュール・キュー１３３用に使用される順序付けられたリストを決定するために使用されても良い。

上述されるように、格付けデータのリスケーリングやオフセット、データの重み付け等の様々なデータ処理機能がクライアント・システム上で実行された。他の実施形態において、これらの機能はデータベース・サーバ１４７によって実行されても良い。例えば、クライアント・フィードバック・データは、表形式のフォーマットに対応するように送信され、追加のカラムが、データ値がどのように生成されたかを識別するために用いられ、格付けデータをリスケーリング及びオフセットするために１つ以上のインサート・クエリがデータベース１４７によって実行され、ユーザが生成したクライアント・デマンド・フィードバック・データと自動的に生成されたクライアント・デマンド・フィードバック・データに異なる重み関数を適用しても良い。

図１８の下の部分に向かって示されるように、および上述したように、各コンテンツが配信された後、ブロック２３１において、コンテンツのためのクライアント・デマンド・データがリセットされる。一実施形態において、その時点におけるメタデータおよびコンテンツに対応するレコードがすべて削除される。他の実施形態において、その時点におけるメタデータおよびコンテンツに対するデータ値はすべてヌルとされる。さらに他の実施形態において、その時点におけるメタデータ及びコンテンツに対応するすべての行のメタデータＩＤが変更される。これらのそれぞれのリセット処理の結果、該コンテンツが配信スケジュール・キュー１３３の最下部に位置され、新たなクライアント・フィードバック・デマンド・データに応じてのみ、新しいキューの最上部へと再び上昇し得る。

その時点におけるメタデータに対応するコンテンツの全部または一部のためのクライアント・デマンド・フィードバック・データが有限個存在する例において、統計上の考慮２２９が使用されてもよい。例えば、上述されたように、所定のコンテンツのためのクライアント・デマンド・フィードバック・データは、該コンテンツが配信された直後にリセットされる。これは、該コンテンツのための新たなクライアント・デマンド・フィードバック・データが受信されるまで、コンテンツが順序付けられたリストの最上部に上昇しないようにする事を保証するためである。クエリ２１５が平均の格付けデータを有する場合、十分な数のクライアント・システムが該コンテンツ用のデマンド・フィードバック・データを供給するまで、該コンテンツが順序付けられたリストの最上部へ上昇することを排除することは一般に望ましいであろう。例えば、最近配信された特定のコンテンツが、高いデマンドのあるメジャーな超大作映画の新作であると仮定する。該コンテンツに関するクライアント・フィードバック・デマンド・データの最初の１０個が該映画を１００点（または最大値）と格付けした場合、通常は順序付けられたリストの最上部に移動するであろう。しかしながら、ある最低限の数のクライアント・フィードバック・デマンド・データを要求するような統計上の考慮２２９を使用する事によって、コンテンツは該最低限の基準が満たされるまで考慮されないようになされる。

他のクエリの考慮は、順序付けられたリストを構築するために、１個以上のメタデータに対応するクライアント・デマンド・フィードバック・データが使用される例を含む。
この場合、複数のコンテンツのリストは、複数のメタデータに記述されている異なるコンテンツを全て含む。通常、様々なコンテンツは人気を失うので、新しい複数のコンテンツと取り替えられ、続いてメタデータが変更される。一般に、配信のために考慮された複数のコンテンツに対応するリストの変更は、リストに全体に加えられるような大規模の変化ではなく、むしろ比較的ゆっくりと変更されるであろう。例えば通常、メタデータが１００個のコンテンツに対応する場合、新たなメタデータは、２０個以下という小さな数字では無く、以前のメタデータの少なくとも８０個あるいは９０個のコンテンツを含んでいるであろう。順序付けられたリストが単一の（例えばその時点における）メタデータによるコンテンツのみを有する時、順序づけられたリストの最上部の付近で順位が下がるコンテンツが存在し、それらは最上部に達さないので二度と配信されないということが有り得る。複数のメタデータのクライアント・デマンド・フィードバック・データを集計することによって、そのようなコンテンツが順序付けられたリストの最上部に上昇し得、それらが配信され得る。一実施形態において、配信スケジュール・キュー１３３が、クエリ２１５によって最も便宜的であると判断された単一のコンテンツを含み、新たな配信スケジュールが生成される必要がある毎に該クエリが繰り返される、という事がさらに注目される。

メタデータと同様に、コンテンツもまたいくつかの異なる配信機構を使用して配信されても良い。一実施形態では、コンテンツは、専用配信チャンネルまたは複数のチャンネルを使用して配信されて良い。他の実施形態において、多重化された後にヌル・データ・パケットを挿入する事を使用してコンテンツを配信しても良い。図１９に示されるように、従来の配信技術では、帯域幅の一部分が未使用である。図示された例において、プログラム１は、帯域幅に１０メガビット毎秒（Ｍｂｐｓ）を割り当てられる可変ビットレートのＭＰＥＧ２データ・ストリーム２３３を含み、一方でプログラム２は、帯域幅に９．２Ｍｂｐｓを割り当てられる可変ビットレートＭＰＥＧ２データ・ストリーム２３５を含む。データ・ストリーム２３３および２３５はマルチプレクサー（ＭＵＸ）２３７に供給される。マルチプレクサー２３７は、２つのストリームを帯域幅１９．２Ｍｂｐｓの単一の結合したデータ・ストリーム２３９へと多重化する。その後、結合したデータ・ストリーム２３９は、モジュレータ２４１で変調されてアップリンクされる（例えば、衛星に送信される）。

図１９に示されるように、データ・ストリーム２３３および２３５の帯域幅に対する未使用の部分（スペクトル）があり、結合したストリーム２３９における未使用部分はさらに大きい。これは、可変ビットレートＭＰＥＧ２エンコーディング（あるいは他のタイプの可変ビットレート・エンコーディング）を使用してコンテンツが送られる場合、コンテンツの異なる部分に対応するデータの量が、時間とともに変わるという事実による。例えば、映画中のアクション・シーンにおいて、登場人物および（または）背景が静止のシーンよりも多くのデータを必要とする。通常、この事を考慮に入れて、データ・ストリーム用の帯域幅はより高いデータレートのシーンを適切に扱うために予想される最大の帯域幅を扱うために選択されており、これは、データ・ストリームの一部分にデータが含まれていないということの原因となる。パケット通信が使用される場合、帯域幅のこれらの未使用の部分には通常「ヌル」パケットが含まれる。

本発明は、以前は未使用であった帯域幅の部分に配信データを送る事を可能にする配信機構を提供する。図２０における一実施形態よって示されるように、ヌルパケット・インサーター２４３は、結合したデータ・ストリーム２３７中のヌル・パケットの代わりに、現在配信中のコンテンツに対応するデータ・パケットを挿入するために使用され、これによって、完全に使用されている帯域幅データ・ストリーム２４５を生成する。完全に使用されている帯域幅データ・ストリーム２４５はモジュレータ２４１へ転送され、モジュレータ２４１はデータ・ストリームを変調し、図１９に関して上述された方法と同様の方法でアップリンクされる。

ほとんどの例において、１個のコンテンツの配信に対応するデータレートが、該コンテンツが再生されるデータレートと一致する必要がないことに注目される。例えば、コンテンツが映画であると仮定する。従来の配信において、映画に対応するデータは、従来のテレビジョン受信機により受信・再生するのに適応する一定のレートで配信される。これは、受信するコンテンツは、受信されると同時に、即ち、リアルタイムで「再生」されるからである。対照的に、本発明の教示において配信されるコンテンツの多くは、その配信がクライアント・システムによって受信され、キャッシュされる時点よりも後の時点において「オンデマンド」で視聴することになる。その結果、様々なコンテンツを配信するのに利用されるデータレートは時間と共に変わってもよく、該コンテンツは、リアルタイムの配信データと比較して著しく速いレートで、または著しく遅いレートで送られても良い。

前述の考慮に従って、コンテンツを送信する別の方法は、「バッチ」配信によってであり、この方法において、コンテンツのバッチが送信される。これはすべてのデジタル配信システムにとって有利であり、図１６に関して上述されたようなストア・アンド・フォワード機構が異なるステージ間で使用され得る場合の多段階配信ネットワークと共に使用された時に、特に有用である。

本発明の教示において、コンテンツのバッチを配信するための一実施形態が、図２１に示される。このプロセスは、スケジュール・キュー１３３の配信に対応する順序づけられたリストから始まる。次の配信時間枠に配信されることが予定されている１つ以上のコンテンツを決定するために、第２クエリ２４７が順序付けられたリスト上で実行される。所定のコンテンツのバッチとして選択されるコンテンツは、各コンテンツのコンテンツサイズ２４９、配信時間枠の長さ２５１および配信帯域幅２５３に基づく。配信時間枠の長さと配信帯域幅の積によって決定されるコンテンツの相対的なサイズとバッチの記憶容量の残された利用可能なスペースに基づいて、順序づけられたリスト１３３Ａの上部に配置された複数のコンテンツが上から順番に選択される。サイズがバッチ中の残存スペース以下である限り、順序付けられたリスト１３３Ａの中のコンテンツが次々と加えられる。次のコンテンツのサイズが残存スペースを超過する場合、更にその次のコンテンツが配信されるコンテンツのバッチとして考慮される。選択されたコンテンツのサイズの総計がバッチの上限を（おおよそ）満たすまで、このプロセスが繰り返される。バッチのためのコンテンツが一旦選択されると、これらのコンテンツは次の予定された配信時間枠にバッチ配信される。前述の例と同様に、コンテンツのバッチ配信が終了すると、バッチ中の各コンテンツ用のクライアント・デマンド・フィードバック・データが、ブロック２３１においてリセットされる。

図２２を参照して、どのコンテンツが所定のコンテンツのバッチを形成するかを決定するプロセスの一実施形態がブロック５０１より開始され、図２１の順序付けられたリスト１３３Ａに示されるように、各コンテンツのサイズを含んだコンテンツの順序付けられたリストが生成される。上述されたように、順序付けられたリスト１３３Ａはクエリ２４７を使用して、順序付けられた配信スケジュール・キュー１３３から導出され得る。しかしながら、データベース技術に精通している当業者によって認識されるように、順序付けられたリスト１３３Ａを生成するために、クエリ２１５および２４７は、単一のクエリへ組み合わせることが出来る。

次に、ブロック５０３において、バッチ・サイズの上限が決定される。これは、配信時間枠２５１と配信時間枠のための配信帯域幅２５３との積によって計算される。その後、ブロック５０５において、残存スペースがバッチ・サイズ上限と等しくされる。スタートブロック５０７とエンドブロック５０９に囲まれたループによってそれぞれ示されるように、以下のオペレーションは、順序付けられたリスト１３３Ａの中の１以上個のコンテンツを順序どおり並べるために行なわれる。最初に、判断ブロック５１１において、コンテンツのサイズが残存スペース以下であるかどうかについての判断がなされる。結果がＹＥＳである場合、ロジックはブロック５１３、続いてブロック５１５へと進み、ブロック５１３においてコンテンツがバッチに加えられ、ブロック５１５においては、最近加えられたコンテンツのサイズによって残存スペースが減らされる。その後、ロジックは、判断ブロック５１７に進み、判断ブロック５１７において、残存スペースがまだ残っているかどうかについて判断がなされる。答えがＮＯの場合、バッチに加えられたコンテンツのリストが、リターン・ブロック５１９に戻る。判断ブロック５１１においてなされた決定がＮＯの場合、ブロック５１３、５１５および５１７がスキップされる。

次に、判断ブロック５２１において、考慮されるべきコンテンツがリスト中に残っているかどうかについての判断がなされる。答えがＮＯの場合、ロジックはリターン・ブロック５１９へ進む。考慮するべき残りのコンテンツが存在する場合、ロジックのループはスタートブロック５０７まで戻り、次のコンテンツの評価を開始する。ロジックがリターン・ブロック５１９に進むまで、該処理ループは連続的に行なわれる。

バッチ選別過程の結果の例が図２１および図２３に示される。例えば、図２１に示されるように、配信時間枠の長さが１０００秒で、配信帯域幅が３Ｍｂｐｓと仮定する。バッチの上限は３ギガビットであり、システムは、順序付けられたリスト１３３Ａの上の方から３ギガビット相当のコンテンツを選択する。この例において、コンテンツＦ、ＢおよびＤが送信される。これは、以下の方法で決定される。コンテンツＦは、順序付けられたリスト１３３Ａの最上部にあるので、最初に考慮される。コンテンツＦのサイズは１．０ギガビットであり、これは残存スペース（最初は３ギガビット）未満である。その後、残存スペースは１．０ギガビットにより減らされて２ギガビットとなり、次に、順序付けられたリスト１３３Ａの２番目に記されているコンテンツＢが考慮される。コンテンツＢのサイズは、０．８ギガビットであり、２ギガビットの残存のスペースよりも少ないので、したがって、コンテンツＢがバッチに加えられる。残存スペースは．８ギガビットにより減らされ、１．２ギガビットとなる。次に、サイズ１．１ギガビットのコンテンツＤが考慮され、これも残存スペース以下なので、バッチに加えられる。この結果、残存スペースは１．１ギガビットにより減らされて、０．１ギガビットとなる。その後、残りのコンテンツのうちで．１ギガビット以下のコンテンツが存在するかどうかをチェックするために上から順番に考慮される。どのコンテンツも．１ギガビットを超えているので、コンテンツＦ、ＢおよびＤを含むコンテンツのバッチが次の配信枠において配信されるようにスケジューリングされる。

図２３において、バッチ上限は２．５ギガビットに減らされた。コンテンツＦおよびＢが上記のようにバッチに加えられ、残存スペースが．７ギガビットとなる。次に、コンテンツＤが考慮される。しかしながら、ブロック５１１において、コンテンツＤのサイズが残存スペースより大きいと判断される。したがって、ロジック・ループはコンテンツＡを評価するために後退する。この場合、ブロック５１１における回答はＹＥＳであり、コンテンツＡはコンテンツのバッチに加えられる。その後、判断ブロック５１７は、残存スペースが全て使用されたと判断する。また、リターン・ブロック５１９において、ロジックはコンテンツＦ、ＢおよびＡを、バッチ配信のために戻す。

一実施形態において、クエリは順序付けられたリスト１３３Ａを構築するために用いられ、該クエリはカーソル・ループに組み入れられ、該カーソル・ループは、バッチのための複数のコンテンツを適切に選択するためのクエリの結果を得るために循環する。他の実施例において、より複雑なクエリが、バッチのためのコンテンツ群を適切に選択するために用いられても良い。

以上の詳細な説明において、本発明の方法および装置は特定の典型的な実施形態に関して記載された。しかしながら、様々な変更および改変が、本発明のより広範な趣旨および範囲から逸脱する事無くなされ得るということは明白である。従って、本願の明細書及び図面は、限定的であるというよりむしろ実例として顧慮される。

単一の配信サーバが様々なデータを複数のクライアント・システムに配信する、本発明の教示における配信システムの一実施形態を示すブロック略図である。 バックチャンネル・コミュニケーションによって、クライアント・システムが配信サーバにデータを送信し得る、本発明の教示における配信システムの他の実施形態を示すブロック略図である。 配信サーバおよび様々なクライアント・システムがコンピュータ・ネットワークを経由して通信し得る、本発明の教示における配信システムの更に他の実施形態を示すブロック略図である。 本発明の教示における、クライアント・システムまたはサーバの典型例であるコンピュータシステムの一実施形態を示すブロック略図である。 本発明の教示における、メタデータおよびデータ・ファイルを配信・処理する時の、配信サーバおよびクライアント・システムにおけるイベントの流れの一実施形態を示すフローチャートである。 メタデータおよびコンテンツが複数のクライアントに衛星ネットワークを経由して配信され、クライアント・デマンド・フィードバックが、クライアント・システムよりテレコミュニケーション・リンクによって送り返される、本発明における配信システムの第１実施例を示す概略図である。 メタデータおよびコンテンツの複数のクライアント・システムへの配信およびクライアント・システムからのクライアント・デマンド・フィードバック・データの返信が、双方向ケーブルテレビ・ネットワークによって行われる、本発明における配信システムの第２実施例を示す概略図である。 メタデータおよびコンテンツの複数のクライアント・システムへの配信およびクライアント・システムからのクライアント・デマンド・フィードバック・データの返信が、コンピュータ・ネットワークによって行われる、本発明における配信システムの第３実施例を示す概略図である。 本発明の教示における、メタデータ・テーブルおよびコンテンツ格付けテーブルを保持するために、サーバから配信されたメタデータを処理する際のクライアント・システムにおけるイベントの流れの一実施形態を示すフローチャートである。 本発明の教示における、サーバから配信される記述用メタデータの一例を示す図である。 本発明の教示における、クライアントによって更新・維持されたメタデータ・テーブルの一例である。 本発明の教示における、クライアントによって更新・維持されたコンテンツ格付けテーブルの一例を示す図である。 本発明の教示における、ユーザによって分類されるデータ・ファイルの一実施形態を示す図である。 本発明の教示における、ユーザの分類に応じて更新されるメタデータ・テーブルの一実施形態を示す図である。 本発明の教示における、ユーザ・アクセスの後に更新されるメタデータ・テーブルの一実施形態を示す図である。 本発明の教示における、ユーザ・アクセスの後に更新されるコンテンツ格付けテーブルの一実施形態を示す図である。 本発明の教示における、更なるユーザ・アクセスの後に更新されるメタデータ・テーブルの他の実施形態を示す図である。 格付けタブによるユーザインタラクションによって、クライアント・システムのユーザが格付けおよびランキング・データを入力し得るユーザ・インターフェースを示す図である。 相対ランキングの順序を付け直すために、ランキング・データの数値入力およびコンテンツＩＤのドラッグ・ドロップをサポートするランキング・タブによって相対ランキング情報をユーザが入力し得る、図１４に示されたユーザ・インターフェースを示す図である。 図１５ａのコンテンツに対応するコンテンツＩＤをドラッグ・ドロップした結果を示す、図１４に示されたユーザ・インターフェースを示す図である。 更新ランク・ボタンの使用により、相対ランキングがどのように更新され得るかを示す、図１４に示されたユーザ・インターフェースを示す図である。 様々なクライアント・システムが地勢および配信ネットワークに基づいて、どのように分割され得るかを示す概略図である。 クライアント・システムから受信したままの、および、データベースに入力された後のクライアント・デマンド・フィードバック・データの構成の一例を示す概略図である。 配信スケジュール・キューに対応して順序づけられたリストを構築するために使用されるクエリ・プロセスを示す概略図である。 可変レートのデータ・ストリームを配信するための従来の方法を示す概略図である。 本発明の教示における、可変レート・データ・ストリームを配信する従来の方法においては使用されていなかった帯域幅を全て利用するために、データへのヌル・パケット・インサーションを使用する事を示す概略図である。 本発明の教示における、バッチ処理の実施形態中に複数のコンテンツがどのように選択されるかを示すブロック略図である。 バッチ・コンテンツ選別プロセスの一実施形態を実行する時に本発明によって使用されるロジックを示すフローチャートである。 コンテンツのサイズが、所定のコンテンツのバッチのための残存スペースよりも大きいという理由でコンテンツがスキップされる例を示す概略図である。

Claims (11)

1. 配信サーバと、
   前記配信サーバと通信によってリンクしたデータベース・サーバと、
   第１通信リンクを経由して前記配信サーバと通信によってリンクし、第２通信リンクを経由して前記データベース・サーバと通信によってリンクした複数のクライアント・システムと
   を備え、
   前記配信サーバが、前記第１通信リンクを経由して前記複数のクライアント・システムへメタデータを配信するようにプログラムされ、前記メタデータが将来の配信が考慮される複数のコンテンツの記述を備え、
   前記複数のクライアント・システムのそれぞれが、前記メタデータによって提供される前記記述の一部に基づいて、前記複数のコンテンツの少なくとも一部に対するクライアントの興味レベルを示すデータである格付けデータをそれぞれ有する個々のクライアント・デマンド・フィードバック・データを生成するようにプログラムされ、
   前記複数のクライアント・システムの少なくとも一部が、前記第２通信リンクを経由して前記データベース・サーバへ前記個々のクライアント・デマンド・フィードバック・データを送信し、
   前記データベース・サーバが、前記個々のクライアント・デマンド・フィードバック・データを集計する事により、前記複数のコンテンツから、次回に配信すべき１個のコンテンツを決定するようにプログラムされ、
   前記配信サーバおよび前記データベース・サーバの少なくとも１つが、次回の配信が決定された前記コンテンツをスケジューリングするようにプログラムされ、
   前記配信サーバが、第１通信リンクの帯域幅が利用可能になった時、次回の配信が決定された前記コンテンツを配信するようにさらにプログラムされ、
   前記クライアント・システムから受信した前記個々のクライアント・デマンド・フィードバック・データの少なくとも一部に対して、前記格付けデータは、前記個々のクライアント・デマンド・フィードバック・データを送信した前記クライアント・システムの１以上のユーザによって提供された直接的な格付けと、前記クライアント・システムに格納される前記クライアント・システムの前記１以上のユーザによる以前の視聴に基づくコンテンツ嗜好度を示すデータに基づいて前記クライアント・システムによって自動的に生成される格付けと、を含み、
   当該格付けにおいて、前記自動的に生成される格付けよりも前記直接的な格付けに高いウェイトを置き、
   配信が決定された前記コンテンツが、前記格付けデータの集計から導出される最も高位に格付けされたコンテンツを備え、
   前記クライアント・システムのそれぞれにおいて余分な利用可能な格納スペースが無く、格納されている未視聴のコンテンツが次回の配信が決定された前記コンテンツよりも高い格付けを有する場合には、次回の配信が決定された当該コンテンツは無視され、前記未視聴のコンテンツよりも高く格付けされたコンテンツが次回の配信が決定された前記コンテンツとして配信されることになっている場合に、より低い格付けを有する前記未視聴のコンテンツが前記高く格付けされたコンテンツと自動的に取り替えられる
   システム。
2. 前記データベース・サーバおよび前記配信サーバのうちの１つが、
   各コンテンツに対するクライアントの相対的な興味レベルに基づいた前記クライアント・デマンド・フィードバック・データの集計に依存して順番に配信される様にスケジューリングされているコンテンツの順序付けられたリストを備える配信スケジュール・キューを維持するステップと、
   次回の配信が決定された前記コンテンツが、次回に配信されるように前記配信スケジュール・キューの最上部に配置するステップと
   を実行する事によって、前記配信が決定された前記コンテンツを次回の配信において配信するようにスケジューリングし、
   前記次回に配信すべき前記コンテンツの決定が連続的になされる、請求項１に記載のシステム。
3. 前記個々のクライアント・デマンド・フィードバック・データが非同期方式でそれぞれのクライアント・システムから受信され、前記配信スケジュール・キューが個々のクライアント・デマンド・フィードバック・データのそれぞれを受信した後に前記データベース・サーバによって再計算される、請求項２に記載のシステム。
4. 前記メタデータが、連続的なストリームとして配信され、前記コンテンツを記述するために使用される属性及び属性値を備える各コンテンツについてのコンテンツ・ディスクリプタを備え、前記クライアント・システムの少なくとも一部が、前記コンテンツの前記コンテンツ・ディスクリプタの受信に応答して個々のコンテンツに対応する格付けデータを提供する、請求項１に記載のシステム。
5. 前記個々のクライアント・デマンド・フィードバック・データの少なくとも一部が、少なくとも２個のコンテンツの相対的な興味レベルに関する相対ランキング・データを備え、配信が決定された前記コンテンツの少なくとも一部が、前記相対ランキングを集計することによって決定される、請求項１に記載のシステム。
6. 相対ランキング・データを備える前記個々のクライアント・デマンド・フィードバック・データの少なくとも一部におけるそれぞれのクライアント・デマンド・フィードバック・データに対して、前記相対ランキング・データは、前記個々のクライアント・フィードバックの送信元である前記クライアント・システムの１以上のユーザによって提供された直接的な相対ランキングと、前記クライアント・システムに格納される前記コンテンツ嗜好度を示すデータに基づいて前記クライアント・システムによって自動的に生成される相対ランキングと、を含む請求項５に記載のシステム。
7. 将来配信する事が考慮される複数のコンテンツに対応するその時点におけるメタデータが、前記複数のコンテンツに含まれるそれぞれのコンテンツのコンテンツ・ディスクリプタをそれぞれ含み、繰り返し配信される連続的なストリームとして配信され、前記個々のクライアント・デマンド・フィードバック・データの少なくとも一部が、前記複数のコンテンツの全てに関する相対的な興味を表すランキングされたリストを有する、請求項５に記載のシステム。
8. 前記第１通信リンクが衛星配信リンクを含み、前記第２通信リンクがテレコミュニケーション・リンクを含む、請求項１に記載のシステム。
9. 前記第１通信リンクおよび前記第２通信リンクが双方向ケーブルテレビ・システム・リンクを含む、請求項１に記載のシステム。
10. 前記第１通信リンクが衛星配信リンクを含み、前記第２通信リンクがコンピュータ・ネットワーク通信リンクを含む、請求項１に記載のシステム。
11. 前記第１通信リンクおよび前記第２通信リンクが、コンピュータ・ネットワーク通信リンクを含む、請求項１に記載のシステム。

Images