JP4934650B2 - 瞬時のメディア・オン・デマンド - Google Patents

Description

本発明は、一般にインターネットを介したマルチメディア配信に関する。特に、本発明は、適切に組み合わされるとき、サービスを含む瞬時のメディア・オン・デマンド（ＭＯＤ）を提供するための技術、システム及び方法に関する。さらに、本発明は、ユーザが選択し、瞬時に再生可能な多数のタイトルのダイナミックライブラリを提供する技術に関する。

［関連技術の説明］
年長者が火の近くで物語を話し、又は夕食時に家族がテレビの前に座ったりするが、人間は生来的に物語を聞き、楽しむという欲求を有している。各家庭がどれほど多くのテレビ及び／又はラジオを有しているか信じることはできない。実際、すべての家庭は２．３台のテレビを所有し、人々は１日に平均して５時間もテレビを視聴していると推定されている。これらの統計や人々の傾向は、ケーブルプロバイダ、衛星プロバイダ、ビデオレンタル企業、Ｂｌｏｃｋｂｕｓｔｅｒ Ｉｎｃ．、ＮｅｔＦｌｉｘ．ｃｏｍなどが、映像、テレビ及び映画配信、プレミアム映画チャンネル、ペイ・パー・ビューなどを顧客に提供するため数百万ドルを投資する動機付けを提供する。

従来、各テレビ視聴者は、いくつかの番組を提供する４つ又は５つのテレビチャンネルを有し、よりエキサイティングな映画コンテンツを観るため映画館に行くことで満足していた。しかしながら、現在の視聴者は、より高い要求をするようになり、多様なより洗練されたドラマ、コメディ、アドベンチャー、ホラーなどを含むより多くのものを自宅のテレビから期待するようになってきている。この要求を満足させるため、テレビ視聴者の大多数はケーブル若しくは衛星サービスに加入している。この基本サービスは、通常のテレビよりかなり多数のチャンネルとプレミアム放送を提供するだけである。

依然として顧客は不満足なままである。このため、ケーブル及び衛星サービスは映画チャンネル契約を提供している。各映画チャンネルは、予め選択された時間に限られた数の比較的新しい映画配信のリリースを提供する。視聴者は、映画リストと映画スケジュールとを確認し、それらが提供されるときに選択された映画を視聴することを計画することができる。視聴者がその時間にテレビをオンすると、視聴者は始めからその映画を視聴することができる。そうでない場合、視聴者は途中から開始される映画を視聴しなければならないかもしれない。あるいは、視聴者は自らに都合のよい時間に視聴するため映画を記録することができる（ＴｉＶｏ Ｉｎｃ．によって提供されるものや従来のＶＣＲなどのデジタルビデオレコーダを利用して）。これらの映画チャンネルによって提供される映画の本数は限られているため、より厳格な視聴者は現在提供されているすべての所望される映画を記録するかもしれず、さらなるタイトルが利用可能になるまで待機しなければならいかもしれない。映画チャンネルにより提供される映画数は限られており、これらの映画は不定期的な時間に開始されるため、映画チャンネルは現在の顧客の要求を効果的に充足するものでない。

“ビデオ・オン・デマンド”の顧客アピールは周知である。一般に、真のビデオ・オン・デマンドは、利用可能な所望されるすべての映画のリストから選択可能な映画（又は他のコンテンツ）の瞬時の視聴として特徴付けすることが可能である。理想的には、サーバ若しくはサーバ群がすべての映画を格納し、顧客が映画を選択することを可能にし、顧客がネットワークの中断なく映画を視聴する間に、映画を顧客にストリーミングする。しかしながら、現在の技術及びネットワーク関連インフラストラクチャの多くの問題点によって、真のビデオ・オン・デマンドは公衆には現在利用可能でない。衛星、ケーブル及びＤＳＬネットワークにおける通信容量及び速度は、不十分なものであり、信頼性が低く、予測不能で整合性を有していない。この不十分で不整合な通信容量及び速度のため、真のビデオ・オン・デマンドが利用可能になった場合、現在のシステムの視聴者は、所望しない中断や他のエラー動作を解決する必要が生じるであろう。真のビデオ・オン・デマンドは、おそらく数年間は公衆には利用可能とはならず、より高速ではるかに高い信頼性と予測可能性を備えた通信チャネル（光ファイバなど）が使用され、より速い計算が確立された後になって始めて利用可能となるであろう。

限定的な環境では、真のＶＯＤは、大容量及び高速性を維持及び配信可能な特化した信頼性の高いネットワークを利用して現在提供される。ケーブルの“オン・デマンド”は、このようなサービスの１つである。ユーザが高速のデジタルネットワークに接続される場合に限って、またサービスプロバイダがＶＯＤをサポート可能である場合に限って、オン・デマンドは再生のため映画を瞬時にダウンロードすることが可能である。このサービスは、従来のブロードバンド接続を介しては利用可能でない。

ここで図１を参照すると、ネットワークを介しビデオサービスを配信するのに利用されるビデオ配信システム１００が示される。ビデオ配信システム１００は、ときどきヘッドエンドと呼ばれるビデオサーバ１０２を有する。データネットワーク１０４を介し、ビデオサーバ１０２は、各クライアントマシーン１０６−１，１０６−２，．．．，１０６−ｎ（すなわち、それの加入者）に連続するスケジューリングされたビデオ・オン・デマンド（ＶＯＤ）サービスを提供することができる。なお、システム１００は、１つのサーバ１０２が複数のクライアントマシーン１０６−１，１０６−２，．．．，１０６−ｎにサービスを提供するという典型的なクライアント・サーバアーキテクチャとなっている。サーバ１０２はさらに、各種メディアファイル（映画やニュース映像など）を格納するよう構成可能なメディアストレージ装置に接続される。メディアストレージ装置１１２は、オンラインであることが求められ、クライアントマシーン１０６−１，１０６−２，．．．，１０６−ｎの何れかへの配信がスケジューリング又は要求されるタイトルを格納及び供給しなければならない。

ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を保証するため、各クライアントマシーン１０６−１，１０６−２，．．．，１０６−ｎとのネットワークパス（１０８−１，１０８−２，．．．，１０８−ｎなど）のバンド幅要求は十分なものでなければならない。しかしながら、加入者数が増加し続けるに従って、バックボーンネットワークパス１１０のバンド幅に対する要求は線形に増大し、システム１００の全体的なコストもそれと同時に大きく増大する。サーバが固定されたバンド幅制限を有し、システムが能力をサポートする場合、ある閾値を超えた加入者数の増大は、クライアントへのデータ転送を低速化する。すなわち、ネットワーク１０４上でのビデオデータのクライアントマシーン１０６−１，１０６−２，．．．，１０６−ｎを介した加入者への送信は、もはや保証されない。ビデオデータが時間通りにクライアントマシーンに受信されないとき、ビデオデータの表示は不可となるか、少なくとも苛つかせるものとなるかもしれない。

ビデオサーバ１０２へのこのようなロード問題を軽減するため、ビデオ配信システムはしばしば、おそらく複数の場所にある複数のビデオサーバを利用する。各ビデオサーバは、ビデオサーバ１０２と同様に、限定数の加入者をサポートするよう構成される。加入者数がビデオサーバの容量又はそれのバンド幅を超えるとは常に、追加的なビデオサーバが配備されるか、又は追加的なバンド幅が割り当てられる必要がある。このため、より多くの加入者がビデオ配信システム１００にサインアップすると、全体的なコストは大きく増大する。

ビデオ・オン・デマンドの制約に対するシンプルな解決策として、ケーブル及び衛星プロバイダは、ペイ・パー・ビュー、すなわち、ビデオレンタルの価格とほぼ同額で平均して３０分毎に開始される限定数のより新たなリリースを提供する。ペイ・パー・ビューによってでさえ、顧客は限定されたセットから映画を選択しなければならず、依然として配信開始まで待機しなければならい。さらに、セットトップボックスがサービスプロバイダとの双方向通信をサポートしていない場合には、顧客は選択された映画を発注するため、不便なことにサービスを電話連絡しなければならい。ペイ・パー・ビューは、真のビデオ・オン・デマンドに対するあまり効果的でない解決策である。

いくつかのケーブル及びインターネット企業は、真のビデオ・オン・デマンドに対する他の代替策を検討している。現在のより良い代替的なシステムの１つは、視聴者が映画を選択、発注、ダウンロード及び視聴することを可能にする。しかしながら、低速のダウンロードスピードとかなりの映画サイズのため、視聴者は映画をダウンロードするため、例えば、１〜２時間などかなりの時間待機しなければならい。ペイ・パー・ビューより良好な多数の方法においてでさえ、この選択肢は理想とはほど遠いものである。この解決策は、映画の受信前に長時間顧客を待機させ、顧客に即座の満足感を提供することができず、多くの購入者の衝動性を利用することができない。

衛星プロバイダは、特に真のビデオ・オン・デマンド若しくは現在の代替策を提供することが困難であろう。なぜなら、衛星通信はリターンパスを提供せず、すなわち、衛星プロバイダから顧客への一方向のみの通信しか提供しないため、また配信（すなわち、ポイント・ツー・マルチポイント）に十分な衛星バンド幅はポイント・ツーポイント通信には不十分であるためである。このとき、顧客は、ある双方向通信モードなしに映画の選択肢を熟読し、映画をリクエスト等することができない。衛星ネットワークの限定的な能力のため、衛星プロバイダは、ケーブル、インターネットブロードバンド、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）及び他のネットワークサービスを提供することが可能なケーブルプロバイダに対してかなり不利である。

Ｂｌｏｃｋｂｕｓｔｅｒ Ｉｎｃ．やＮｅｔｆｌｉｘ，Ｉｎｃ．などの各企業は、より多くの映画選択肢を顧客に提供しようとするビジネスモデルを構築してきた。しかしながら、Ｂｌｏｃｋｂｕｓｔｅｒは、顧客がソファから離れ、支度をし、望ましくは地域の事業所に行き、映画（しばしば利用可能でない）を選択し、映画を開始することが可能になる前に自宅に戻ることを要求する。Ｎｅｔｆｌｉｘは、顧客が多くのリストから映画を発注することを要求するが、要求された映画を従来のポストを用いて郵送する。顧客は、リクエストした映画を受け取るまで少なくとも数日待つ必要がある。これら２つのモデルは、“オン・デマンド”を提供するものでない。

従って、ユーザが大きなライブラリから所望のタイトルを選択し、発注したタイトルを瞬時に視聴することを可能にする瞬時のＶＯＤシステムが要求される。

［概要］
本セクションは、本発明の実施例のいくつかの特徴を要約し、好適な実施例を簡単に紹介する。本セクション並びに本開示のタイトル及び要約の簡単化及び省略は、本セクション、タイトル及び要約の目的を不明りょうにすることを回避するため行われるかもしれない。このような簡単化又は省略は、本発の範囲を限定するものでない。

概略すると、本発明の実施例は、データネットワークを介しメディアサービスを提供するための技術に関する。ここに記載される技術は、互いに関連するものであり、それぞれは当該技術において独立に新規なものであると思料する。開示された技術は、新規かつ非自明なシステム若しくはシステムの一部を提供するため、単独で若しくは何れかの組み合わせにより実行されるかもしれない。それらの最も広範な意味で組み合わされた場合でさえ、すなわち、各技術が実践のため減縮された具体的方法未満によって、組み合わせた技術が等しく独立な新規な組み合わせをもたらすことが理解されるべきである。

本発明の実施例は、データネットワークを介しメディアサービスを提供するための各種技術に関する。一特徴によると、適切に組み合わされると、当該技術の一部は瞬時のメディア・オン・デマンドシステム、それと等価なプロセス及びメソッドを提供することが可能である。メディアサービスが中央サーバにおいてレンダリングされる従来のシステムとは大きく異なって、本発明の実施例はネットワーク上の各装置を利用して、要求されるサービスを提供するため、必要とされるサービスを細分化して互いに供給する。この結果、サーバに対するロード要求が、ネットワークに分散化される。

本発明の他の特徴によると、システムは、ユーザが所望するときは常にタイトルを選択及び発注可能な多数のタイトルを有するライブラリを提供し、タイトルに係るファイルの始めの部分にアクセスすることによってタイトルをほぼ瞬時に再生する。データの始めの部分はローカルにキャッシュされ、データの残りの部分は他の指定された装置によって供給される。ライブラリは、リリース（新たな又は人気のあるタイトルなど）により動的に更新される。

本発明のさらなる他の特徴によると、タイトルに係るファイルが、ヘッダと複数のテール若しくはセグメントに細分化される。ヘッダは、ファイルの連続部分であり、セグメントは、ファイルの残りの各部分である。ヘッダは、実質的にすべてのボックスに提供され、セグメントは、サービス提供中の各ボックスにその少なくとも１つしか又は全く配信されない。タイトルが発注されると、ヘッダが瞬時に再生され、その間にローカルに利用可能でない場合には、セグメントがストリーミングされるか、若しくはセグメントを有する他のボックスからそれぞれ連続的にフェッチされる。ファイルの残りの部分を復元し、タイトルの再生を継続するため、同時にフェッチされたセグメントからのデータが、存在する場合にはローカルにキャッシュされているセグメントからのデータと共に多重化される。

本発明のさらなる他の特徴によると、ネットワーク帯域幅を最大限活用し、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を最大化するため、大きなファイルがインテリジェントに細分化され、これらのセグメントが分散化される。ヘッダサイズとセグメント数は、要求されるタイトルの転送レート、利用可能な最小のネットワークスピードなどに従って定期的に計算又は決定される。

本発明のさらなる他の特徴によると、サービス提供中の各ボックスのライブラリが、同期的に又は非同期的に更新される。ライブラリを更新するためのリリースは、サービス提供中のすべてのボックスにｇｏｓｓｉｐプロトコルによりデータチャンクを伝搬することによって実行される。その後、適切なリリースパッケージが、ライブラリを更新するため、受信したデータチャンクから各ボックスにおいて復元される。サービスプロバイダに高帯域幅ブロードキャスト若しくはマルチキャスト機能が備えられているケースでは、ヘッダと複数のセグメントに細分化されるリリースは、ライブラリを更新するため適切なリリースパッケージを受信するようそれぞれ構成されるすべてのボックスに送信される。

本発明のさらなる他の特徴によると、新たにインストールされ、又はある期間後にネットワークに戻されたボックスは、例えば、サービス提供を開始するため可能な最短時間などにより効率的に更新される。このようなボックスのもとのライブラリは、最も需要のあるタイトルによって、最初の若しくは可能な少なくともデータ量により更新され、これにより、ボックスは、最も需要のあるタイトルに対する注文を実現するためだけでなく、必要なデータを他のボックスに提供するための状態にすぐになるかもしれない。実現形態に応じて、ボックスのもとのライブラリの更新は、最新のタイトルをまとめて有する他のボックスからｇｏｓｓｉｐプロトコルによってデータチャンクを受信することによって、又はブロードキャスト若しくはマルチキャストインフラストラクチャを介しサービスプロバイダから適切なリリースパッケージを受信することによって実行されてもよい。

本発明のさらなる他の特徴によると、ボックス間に転送されるすべてのデータが遅延若しくは中断しないように、データを発注元のボックスに提供するよう指定されたボックスをサポートするため、バックアップボックスが設けられる。ボックスの１つが低パフォーマンスによりデータを発注元のボックスに提供する場合（例えば、ボックスの動作上の問題又は所望されないネットワークパフォーマンスにより）、低パフォーマンスのボックスを置換若しくは支援し、発注元のボックスへのデータの供給を継続するため、バックアップボックスが起動されるかもしれない。本発明の他の特徴は、ここでの詳細な説明から当業者により理解されるであろう。

本発明の実施例は、方法、システム、装置若しくはコンピュータ可読媒体を含む各種方法により実現されるかもしれない。本発明のいくつかの実施例が以下に説明される。一実施例では、本発明は、ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、発注元のボックスからライブラリのタイトルの注文を含むリクエストを受信するステップと、前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する１以上のボックスを特定するステップとを有し、前記発注元のボックスは、前記１以上のボックスから前記タイトルに係る分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生することによって前記タイトルの再生を進行する方法を提供する。

他の実施例では、本発明は、ボックスのライブラリのすべてのタイトルの視聴機構を提供する方法を提供する。本方法は、ボックスのタイトルのライブラリからタイトルの選択を可能にするステップと、前記タイトルの１つが選択されると、タイトル情報を含むリクエストを生成するステップと、前記発注されたタイトルに係る１以上の分散オブジェクトを提供する１以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するステップと、前記発注されたタイトルに係る前記ボックス内の常駐オブジェクトの再生を開始するステップと、前記常駐オブジェクトの再生中に一部が受信される１以上のデータストリームとして、前記１以上のボックスから前記１以上の分散オブジェクトを受信するステップと、前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記１以上のデータストリームの再生を開始するステップとを有する。

さらなる他の実施例では、本発明は、ネットワークを介しメディア・オン・デマンドサービスを提供するシステムを提供する。本システムは、各ボックスがネットワークに接続され、ユーザに関連付けされ、タイトルのライブラリを提供し、複数のヘッダと複数のセグメントが常駐することを可能にする格納スペースを有し、タイトル選択情報を有するリクエストを提供するよう構成される複数のボックスと、前記ネットワークに接続され、前記ボックスの１つである発注元のボックスからのリクエストに対するレスポンスを提供するよう構成されるサーバとを有し、前記レスポンスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう構成されるボックス群を特定するソース情報を含み、前記レスポンスに応答して、前記発注元のボックスは、前記ボックス群から１以上の分散セグメントをダウンロードしながら、前記選択されたタイトルに係るヘッダの再生を開始する。

さらなる他の実施例では、本発明は、ネットワークに分散されるオブジェクトを管理するシステムを提供する。本システムは、各ボックスが、ネットワークに接続され、ユーザに関連付けされ、それぞれがヘッダといくつかのセグメントとにより表されるタイトルのライブラリを提供し、各タイトルについてヘッダと０以上のセグメントとをローカルにキャッシュするための格納スペースを有する複数のボックスと、タイトルの１つの注文を含むリクエストをボックスの１つ（発注元のボックス）から受信した後、レスポンスを提供するよう構成される計算装置とを有し、当該レスポンスは、セグメントのすべてが発注元のボックスにローカルにキャッシュされていない場合、タイトルに係る欠落しているセグメントを提供するよう指定された供給元のボックス群を特定するソース情報を有する。一般に、ライブラリは、いくつかのグループ若しくはバンドに分割され、バンドの１つ（上位バンド）は、最も需要のなるタイトルのいくつかを有し、他のバンド（低バンド）は、最も需要の低いタイトルのいくつかを有する、１つのケースでは、上位バンドのタイトルのセグメント数は、低バンドのタイトルのセグメント数より多く、これは、上位バンドの各タイトルに対して低バンドのタイトルに対するよりも多くの分散コピーをもたらす。

さらなる他の実施例では、本発明は、タイトルに係るファイルを細分化する方法であって、ファイルを第１部分と第２部分に分割されたデータブロックシーケンスに分割するステップと、ヘッダのデータブロックが連続的なものとなるように、第１部分のデータブロックからヘッダを形成するステップと、各セグメントのデータブロックが不連続なものとなるように、各セグメントが第２部分のデータブロックの一部を有するＮ個のセグメントを形成するステップとを有する（ただし、Ｎは１より大きな有限の整数である）。ファイルは、存在する場合には、補助データを伴うデータのコレクションである。ヘッダは、常駐オブジェクトとしてサービス提供中の各ボックスにローカルにキャッシュされ、Ｎ個のセグメントのうちのＭ個のセグメントがボックスに格納される。ここで、Ｍの値は、タイトル毎及びボックス毎に異なり、０≦Ｍ≦Ｎである。

さらなる他の実施例では、本発明は、ライブラリを動的に更新し続ける方法を提供する。本方法は、サービス提供中の各ボックスのライブラリを更新するためリリースに含まれるタイトルに係るファイルをデータチャンクシーケンスに分割するステップと、各提供ボックスがデータチャンクの少なくとも一部を受信し、データチャンクをまとめて受信する初期的な提供ボックス群を指定するステップと、各提供ボックスに受信したデータチャンクの少なくとも一部若しくはすべてをボックス群に伝搬させるステップとを有し、ボックス群の各ボックスは、サービス提供中の各ボックスがデータチャンクの指定された部分を受信するまで、ボックス間に受信したデータチャンクの一部若しくはすべての拡散を継続するよう選択された他のボックスに受信したデータチャンクを再帰的に伝搬する。実質的に、各ボックスは、受信指定されたものを受信する。本方法はさらに、受信したデータチャンクの一部若しくはすべてからヘッダと０以上のセグメントとを各ボックスに復元させ、その後、それのライブラリを更新する。

さらなる他の実施例では、本発明は、新たにインストールされた装置においてコンテンツを更新する方法であって、メディアサービスを提供するシステムに新たなボックスが検出されると、ライブラリのいくつかの古いタイトルを決定するステップと、ライブラリに追加し、ライブラリから古いタイトルを排除するため、対応する見逃したタイトルを決定するステップと、ボックスが相対的に新たらしいタイトルの１つの注文に対してサービスを提供する準備ができるように、ボックスに見逃したタイトル群の中の相対的に新しいタイトルに係るデータをまず抽出させるステップと、ボックスが完全に更新されるまで、残りの見逃したタイトルに係るデータをボックスに抽出させ続けるステップとを有する方法を提供する。１つのケースでは、ボックスは、相対的に新しい各タイトルのヘッダを抽出し、その後、それぞれに対する複数のセグメントの１つを抽出する。他のケースでは、ボックスは、タイトルの人気の降順により相対的に新しい各タイトルのヘッダと複数のセグメントの１つを抽出する。

さらなる他の実施例では、本発明は、分散環境においてデータを転送する方法を提供する。本方法は、ネットワーク上の計算装置によって提供されるソース情報に従って、要求されるデータセグメントを供給するよう指定された各ボックスとの通信セッションが確立されているか判断するステップと、通信セッションが指定された各ボックスと良好に確立された後に限って、指定されたボックスから必要とされるデータセグメントを同時にダウンロードするステップとを有し、必要とされる各データセグメントは、ファイルを表すデータブロックシーケンスからサンプリングされた複数のデータブロックを有する方法を提供する。

さらなる他の実施例では、本発明は、ライブラリを動的に更新し続ける方法であって、ライブラリを更新するための少なくとも１つのタイトルを含むリリースをデータパッケージにより準備するステップと、サービス提供中のボックスに送信インフラストラクチャを介しデータパッケージを送信するステップとを有し、各ボックスはデータパッケージの少なくとも一部をローカルにキャッシュするよう構成され、ボックスのすべてがデータパッケージの同一部分をキャッシュしていない方法を提供する。実現形態に応じて、送信インフラストラクチャは、ブロードキャスト若しくはマルチキャスト可能であってもよい。データパッケージは、タイトルのヘッダと複数のセグメントを有する。各ボックスにローカルにキャッシュされるデータパッケージの一部は、ヘッダと０以上のセグメントとを有する。あるいは、データパッケージは、各リリースパッケージがヘッダと０以上のセグメントを含む複数のリリースパッケージを有する。

本発明の１つの課題は、適切に組み合わされたとき、瞬時のメディア・オン・デマンドシステムを提供するのに効果的に利用可能な技術を提供することである。

本発明の他の課題、特徴及び効果は、添付した図面と共にそれの実施例の以下の詳細な説明を参照することにより明らかとなるであろう。

［発明の詳細な説明］
本発明の実施例は、データネットワークを介しメディアサービスを提供するための各種技術に関する。これらの技術の一部は、適切に組み合わされるとき、瞬時のメディア・オン・デマンドを提供することが可能である。一実施例は、ユーザがほとんど瞬時に再生のため選択及び発注可能な多数のタイトルを備えたダイナミックライブラリを提供するかもしれない。瞬時の再生を実現するため、タイトルに係るファイルがヘッダと複数のセグメント（又はテール）に細分化されるかもしれない。一実施例では、ヘッダはすべてのボックスに設けられ、各セグメントは、ある方式に従ってネットワーク内でこれらのボックスに配信される。タイトルが発注されると、ヘッダは即座に再生可能となり、セグメントは、それがローカルに利用可能でない場合には、サポートするボックスからストリーミングすることが可能である。同時にフェッチされる各セグメントからのデータは、必要に応じて、ファイルの残りの部分を復元し、発注されたタイトルの再生を継続するため、ローカルにキャッシュされたセグメントに多重化することが可能である。

さらに一実施例では、サービスを提供する各ボックスのライブラリは、例えば、ｇｏｓｓｉｐプロトコルなどを利用して、データチャンクをサービス提供中のすべてのボックスに伝搬することによって、同期的に若しくは非同期的に更新されるようにしてもよい。システムに新たにインストールされた若しくは一定期間後に戻されたボックスは、サービスの提供を開始するためすぐに更新することが可能である。本発明の他の可能な特徴及び効果は、実施例により本発明の原理を示す添付した図面と共になされる以下の詳細な説明から明らかになるであろう。

以下の説明では、本発明の完全なる理解を提供するため、多くの具体的詳細が提供される。本発明は、これらの具体的詳細なしに実現可能である。ここでの記載及び表示は、研究の本質を他の当業者に効果的に伝えるため、当業者によって使用される手段である。他の例では、周知の方法、手順、コンポーネント及び回路は、それらがすでに十分に理解されているため、また本発明の特徴を不要に不明りょうにすることを回避するため、詳細には説明されていない。

ここでの“一実施例”若しくは“ある実施例”という表現は、当該実施例に関して説明される特定の機能、構成若しくは特徴が本発明の少なくとも１つの実現形態に含めることが可能であることを意味する。明細書中の各箇所における“一実施例”という表現は、必ずしもすべてが同一の実施例を参照しているとは限らず、他の実施例の相互に排他的な別個の若しくは他の実施例でもない。さらに、１以上の実施例を表すプロセス、フローチャート若しくは機能図における各ブロックの順序は、本来的に特定の順序を示すものでなく、また本発明の各限定を意味するものでもない。

便宜上、いくつかの用語の定義が以下に与えられる。これらの定義は一実施例による本発明の理解及び記載を容易にするためのものであることに留意すべきである。これらの定義は、実施例に関する各限定を含むように見えるかもしれない。しかしながら、これらの用語の実際の意味は、このような実施例を超えた適用性を有するかもしれない。

メディア又はビデオは、ここでは互換的に使用され、マルチメディアデータを示すものであり、その集合体は、他の可能性のある補助データと一緒になってファイルとして呼ばれる。このようなファイルは典型的にはサイズの大きなものであるため、それはしばしば、一般的に使用される規格（Ｈ．２６４、ＭＰＥＧ−１、ＭＰＥＧ−２若しくはＭＰＥＧ−４など）に従って格納若しくは送信のため圧縮される。ビデオの具体例として、以下に限定されるものではないが、映画、ゲーム、映像場面、ドキュメンタリ若しくはマルチメディアデータコレクションがあげられる。

ローカル装置、コンピュータ、マシーン又は単にボックスは、ここでは互換的に使用され、典型的にはメディアファイルにアクセスするためユーザにより使用される計算装置である。このようなクライアントマシーンは、他の装置とは独立して若しくはそれと共に動作するかもしれない。クライアントマシーンの具体例として、セットトップボックス、計算装置（デスクトップ、ラップトップ、ＰＤＡ、電話、タブレットＰＣなど）、ネットワーク機能を備えたテレビ及びネットワークストレージ装置があげられる。

常駐オブジェクト及び分散オブジェクトは、相対語である。ファイルが複数の部分若しくはセグメントに分割されると、これらのセグメントの一部は他のボックスにリモートに分散されるかもしれない。これら分散されたセグメントは、“分散オブジェクト”と呼ばれる。ローカルにキャッシュされたヘッダ及び他のセグメントは、“常駐オブジェクト”若しくは“レジデンスオブジェクト”と呼ばれる。

サーバ、サーバ装置、サーバコンピュータ又はサーバマシーンは、ここでは互換的に使用され、典型的には、ローカルボックスからリモート配置された計算装置である。実現形態に応じて、ここでのサーバは、ここに記載されるサーバ処理を送出するよう構成されたスタンドアローンコンピュータ若しくは２以上のコンピュータのクラスタを意味するかもしれない。

本発明の実施例が、図２Ａ〜８を参照して説明される。しかしながら、当業者は、本発明はこれらの限定的な実施例の範囲を超えるため、これらの図面に関してここで与えられる詳細な説明が単なる説明のためのものであることを容易に理解するであろう。

本発明の一実施例は、増大するユーザ数によって悪影響を受けないデータネットワークを介しビデオサービスを配信するための技術に関するものである。一実施例では、ユーザが多くなるに従って、システムもしくはプロセスによって提供されるパフォーマンスはより良好となる。

図２Ａは、本発明の実施例による分散ネットワークシステム１００の一例となる構成２００を示す。ネットワーク全体は、例えば、特定のタイプ、サイズ、コンテンツなどの各ボックスに対して１つのこのようなネットワークシステム１００を複数有してもよいということは理解されるであろう。

サービスプロバイダによっておそらく管理及び／又は占有されるサーバ２０２は、ローカルマシーン若しくはボックス２０６−１，２０６−２，．．．，２０６−ｎを介したユーザへのビデオ（若しくはマルチメディア）サービスの配信を処理するよう構成される。加入者からのリクエストにより加入者にビデオデータを配信する図１のビデオサーバ１０２とは異なり、サーバ２０２は、ユーザからのリクエストに応答してコンテンツを配信するものでなく、その代わりに他のボックスからコンテンツの少なくとも一部を抽出すべき場所及びその方法に関するソース情報を提供するよう構成される。すなわち、図１のサーバ１０２は、メディアストレージ装置１１２がクライアントマシーン１０６−１，１０６−２，．．．，１０６−ｎの何れかへのサービス提供時にコンテンツを提供することを要求し、サーバ２０２は、メディアストレージ装置がコンテンツを提供することを要求しない。その代わりに、ボックス２０６−１，２０６−２，．．．，２０６−ｎの一部が、コンテンツの一部若しくはすべてを互いに供給するようそれぞれ構成される。

一実施例によると、ローカルマシーン若しくはボックス（２０６−１など）からのリクエストを実現するとき、サーバ２０２とボックス２０６−１との間のネットワークパス２０８−１及び２１０を介した通信は、小さなスケールのリクエストとレスポンス（小さなサイズ及び大変短いものなど）に限定されるかもしれない。ボックスからのリクエストに対するサーバレスポンスは、ソース情報（識別子など）、認証情報及びセキュリティ情報を含むかもしれない。サーバ２０２からのレスポンスを利用して、ボックスはタイトル（２０７−１など）の再生を開始するよう起動されるかもしれない。実質的に同時に、ボックスは、当該タイトルの移行の部分（２０７−２、２０７−ｎなど）をリクエストするため、ソース識別子に従って他のボックス（２０６−２、２０６−ｎなど）に対する１以上のリクエストを開始するかもしれない。適切な認証を仮定すると、要求元のボックスは、その他のボックスから同時に当該データの以降の部分を受信する。コンテンツのボックス間の通信のため、ネットワークパス２０８−１及び２１０を介したボックスとサーバ間の通信に対するバンド幅要求は低く、典型的には短時間に維持される。実質的に同時に多数のユーザボックスが再生リクエストを発行する場合、バックボーンパス２１０のバンド幅は顕著な又は厄介な遅延を回避するのに十分なものであるべきである。

ボックス２０６−１，２０６−２，．．．，２０６−ｎの何れかにおいて提供されるライブラリにおいて利用可能なコンテンツは、１以上のコンテンツプロバイダによってもともと提供される。コンテンツプロバイダの具体例として、衛星受信機、テレビ中継ステーション、アナログ若しくはデジタル放送ステーション、映画スタジオ及びインターネットサイトがあげられる。実現形態に応じて、コンテンツはまずサーバ２０２において受信若しくは発信されるかもしれない。大規模なストレージ装置にコンテンツを維持及び管理する代わりに、サーバ２０２は、サーバ２０２により登録されている複数のローカルマシーンにコンテンツ若しくはファイルを分散するよう構成される。図２Ａに示されるボックス２０６−１，２０６−１，２０６−２，．．．，２０６−ｎは、サービスを提供するローカルマシーンの具体例である。バックアップコピーが不要である場合、サーバ２０２は、何れの時点においてもコンテンツのコピーを保持する必要はない。他方、極めて要求の高いタイトルの完全なコピーをボックスに保持する特別な要求がなければ、サービスを提供するボックスの何れも発注までタイトルの完全なコピーを有しない。この結果、分散オブジェクトに埋め込まれたセキュリティによって、本発明の一部の実施例は、電子的な著作権侵害及び広範な配布（ハッキング若しくは不法な複製などによる）の懸念を軽減するかもしれない。

便宜上、ここではタイトルに係るファイルが、当該タイトルがユーザにより選択及び発注されると再生されることが仮定される。タイトルが発注されると、対応するファイルが再生のため利用可能でなければならない。実施例は、それのサイズに関係なくファイル又は少なくともその一部に瞬時にアクセスすることを可能にするかもしれない。他の実施例によると、ファイルが平均して８４０メガバイトであり、ボックスが３００ギガバイトの格納容量を有する場合、システムは任意の時点でのアクセスのため、タイトルの大きなライブラリに瞬時に提供するかもしれない。従来、タイトルのファイルが瞬時の再生を提供するため予め格納される必要がある場合、ボックスのローカルストレージは、４０００ギガバイトの容量を有する必要があり、この結果、瞬時のＶＯＳを経済的に非実現的なものにする。

本発明の一実施例によると、ファイルの開始部分（“ヘッダ”と呼ばれる）とおそらく１以上のテールセグメントのみがボックスにローカルにキャッシュされる。このようなローカルにキャッシュされたセグメントは常駐オブジェクト（ｒｅｓｉｄｉｎｇ ｏｂｊｅｃｔ）と呼ばれ、ローカルに常駐しないセグメントは分散オブジェクト（ｄｉｓｔｒｉｂｕｔｅｄ ｏｂｊｅｃｔ）と呼ばれる。あるタイトルが選択されると、対応するファイルのヘッダが即座に再生される。ヘッダ再生中、当該タイトルに対応する分散オブジェクトが他のボックスから同時に抽出される。ヘッダが終了すると、他のボックスからストリーミングされる分散オブジェクトの受信部分が、連続再生を可能にするため、存在する場合にはタイトルの常駐オブジェクトと合成される。あるタイトルの人気と同時になされる要求とに応じて、常駐オブジェクトの個数は、再生のための他のボックスに対する各ボックスの依存性を制御するよう増減されるかもしれない。典型的には、ボックスがタイトルの常駐オブジェクトを多く有するに従って、システム全体における当該タイトルの分散コピーは増加し、これにより、他のボックスに対する発注元のボックスの依存性を低下させる。

一実施例では、ヘッダは瞬時の再生を保証するため常に最初に再生される。しかしながら、ボックスがファイルに対して複数の常駐オブジェクトを有するとき、ヘッダ以外の常駐オブジェクト（すなわち、常駐セグメント）が、他のボックスからダウンロード若しくはフェッチされた分散オブジェクト（すなわち、分散セグメント）と共に再生される。これらの常駐及び分散セグメントは、まとめてファイルの“セグメント”と呼ばれる。

例えば、図２Ａでは、ユーザがボックス２０６−１から再生用のタイトルを選択すると、ボックス２０６−１に常駐する対応するファイルのヘッダ２０７−１が即座にアクセスされる（ユーザが認証されており、及び／又は支払が決済されている場合）。この例では、ビデオファイルには４つのセグメントが存在するかもしれず、そのうちの２つは他のボックス（２０６−２、２０６−ｎなど）に分散されている。ヘッダの再生中、２つの分散セグメントが他方の２つのボックスからダウンロードされ、連続するコンテンツとして常駐セグメントと共にローカルにバッファリングされる。ヘッダが実行されると、連続するコンテンツが再生される。この結果、瞬時のＶＯＤが実現可能となる。

図２Ｂの実施例を参照すると、ファイル２２０は、ヘッダ部分２２２と、４つのセグメント２２４から構成されるテール部分とに関して構成又は細分化されている。一般に、ファイル２２０は、要求される転送レート（良好な再生のための符号化及び復号化レートなどに関する）と、ネットワークの最小アップロード及びダウンロード能力とを考慮して、任意数のヘッダとセグメント部分に分割されるかもしれない。一実施例によると、要求される転送レート（毎秒１メガビット、すなわち、１Ｍｂｐｓなど）が与えられると、ネットワークの最小のアップロード及びダウンロードスピードが、セグメントを規定する数と、特定のタイトルの同時になされる要求に対するサポート及び他のボックスへの依存性とを決定するよう考慮される。最小のアップロードスピードはＵであり、要求される転送レートがＤであり、Ｄ／Ｕ＝Ｋ＜ｋ（ただし、ｋはＫより大きな最小の整数である。）となることが仮定される。一実施例では、ダウンロードスピードがアップロードスピードの少なくともｋ倍の速さであると仮定すると、ファイルは好ましくは、Ｕのアップロードスピードを最適に利用するため、ヘッダとｋ個のセグメントに分割される。例えば、常駐エリアのためのＰＯＴＳベースＤＳＬネットワークでは、要求される転送は約１．０Ｍｂｐｓであり、アップロードスピードは約３２０ｋｂｐｓである。従って、ｋ＝４となる。

図２Ｃに示されるように、ファイル２３０は、１つのヘッダ２３２と４つのセグメント２３４〜２３７から構成される。図２Ｃは、ローカルボックスがヘッダ２３２のみを格納し、４つのセグメント２３４〜２３７を供給するため他の４つのボックスに依存する状況を仮定している。ローカルボックス２３９は、ヘッダ２３２の再生中、その他のボックスのアップロードスピードの４倍のダウンロードスピードを有すると仮定すると、これら４つのセグメントは、ローカルボックス２３９へのストリーミングとほぼ同時にネットワーク２３８を介し同時にダウンロードすることが可能である。

図２Ｂに示されるように、ヘッダ２３２はファイルの開始部分であり、各セグメントはファイルの残りの間引かれた部分である。本実施例では、ヘッダのデータは連続的なものであり、それはヘッダ自体が再生可能であること意味し（例えば、当該タイトルの最初の１５分間など）、セグメント部分２３４〜２３７は、ファイルのテール部分が再生可能となる前に一緒に提供されねばならない。図２Ｄは、ファイルを表すデータストリーム２４０を示す。ファイル２４０の開始部分はヘッダ２４２として割り当てられ、残りの部分は４つの“垂直の（ｖｅｒｔｉｃａｌ）”セグメント２４７〜２５０に分割される。これらのセグメント２４７〜２５０は、ファイルの残りの部分を間引くことによりそれぞれサンプリングすることによって生成又は形成される。

残りの部分の正確なデータ長に応じて、各セグメント２４７〜２５０のｎ番目のデータブロックはファイルの残りの部分の連続する４つのデータブロックとなる。一実施例では、データブロックは、２５６キロバイト若しくは１メガバイトなどのデータのチャンクから構成される。図２Ｄに示されるように、データストリーム２４０の残りの部分は、ｂ１１，ｂ２１，ｂ３１，ｂ４１，ｂ１２，ｂ２２，ｂ３２，ｂ４２，ｂ１３，ｂ２３，ｂ３３，ｂ４３，．．．，ｂ１ｎ，ｂ２ｎ，ｂ３ｎ，ｂ４ｎのようなデータブロックにより表現される。間引きサンプリングによって、残りの部分から取得される４つのセグメント２４７〜２５０は、それぞれ以下のように表現可能である。

セグメント１＝｛ｂ１１，ｂ１２，ｂ１３，ｂ１４，．．．｝
セグメント２＝｛ｂ２１，ｂ２２，ｂ２３，ｂ２４，．．．｝
セグメント３＝｛ｂ３１，ｂ３２，ｂ３３，ｂ３４，．．．｝
セグメント４＝｛ｂ４１，ｂ４２，ｂ４３，ｂ４４，．．．｝
図２Ｄは、ファイルをヘッダ２４２と４つのセグメント２４７〜２５０に細分化する一例となる実施例を示す。ファイルの細分化方法は他にもある。例えば、ファイルをファイルのテール部分を表す複数の“垂直”セグメントに細分化する代わりに、１以上のセグメントが当該ファイルの音声部分を表すよう割り当てられてもよい。典型的には、映画は、その各々がある言語（英語、仏語、スペイン語など）のための複数の音声トラックを含む。この結果、すべてのセグメントは、必ずしも等しい長さとならず、再生をサポートするため同時に利用可能とならなければならない。この具体例は、タイトルのすべてのセグメントが当該タイトルを再生するために必ずしもフェッチされる必要がないことを示している（例えば、ビデオデータのためのすべてのセグメントと、１つの選択された音声トラックのための１つのみのセグメントなど）。他の例では、ファイル２２０は赤色、緑色、青色及び輝度の各値に関してセグメント化することが可能である。このため、セグメントの１つが欠落しても、画像は生成することが可能である。もちろん、赤色、緑色及び輝度のみから画像を形成することは、画質に影響を与えるかもしれない。このような場合、各色は、おそらく以前のフレーム若しくは他の基準に基づき推定される必要があるかもしれない。一般に、各ファイルは異なる個数のセグメントに細分化されるかもしれない。

図２Ｅは、複数のボックスに分散化するためファイルを細分化するためのフローチャート若しくはプロセス２６０を示す。当該プロセス２６０は、メソッド、プロセス及び／若しくはシステムとして、又はソフトウェア、ハードウェア若しくはその両方により実現されてもよい。２６１において、プロセス２６０は、ボックスに分散するためファイルが細分化されるのを待機する。このようなファイルが利用可能になると、２６２において、ネットワークの最小アップロード及びダウンロードスピードと共に、要求される転送レートが取得される。一般に、異なるネットワークは異なるスピードを有する可能性がある。ファイルの細分化数を決定するため、ネットワークアップロード及びダウンロードスピードを有することは要求されていないが、ファイルの要求される転送レートの観点から、このようなスピードを知ることは、ネットワークスピード（又はバンド幅）を効率的利用するため、ファイルを細分化することを可能にする。

２６４において、ファイルに対するセグメント数ｋが、２６２から取得された最小アップロード及びダウンロードスピードを含むいくつかのファクタと、適切な表示のための要求されるデータ転送レート（毎秒１メガビットなど）とを参照して決定される。一実施例では、実際のセグメント数は、ダウンロードバンド幅が十分である場合（要求される転送データレートより高い場合）、ｋ＋１などｋより若干大きなものが選択される。後述されるように、エクストラセグメントがネットワーク若しくはボックスの不安定性を解消若しくは安定化させるための追加的な時間を提供するかもしれない。

ファイルヘッダのサイズが、２６６において決定される。一般に、ヘッダサイズが大きくなると、ライブラリにおける利用可能なタイトルが少なくなる。一実施例では、ヘッダサイズは、連続的に残りの部分（分散オブジェクトにおける）の受信及び再生を保証するのに十分な長さになるよう決定され、あるいはおそらく、各オブジェクトがフェッチされるのを同期させ、不安定性を管理するための追加的な時間を含むようにしてもよい。他の実施例では、ヘッダサイズはサービス提供されるエリアの最小ネットワークスピードや、より高い転送レートに変換可能なシーンなどのいくつかのパラメータの関数として自動的に計算される。さらなる他の実施例では、ヘッダは、セキュリティ情報やコマーシャル情報の短い場面などの他の情報をボックスに転送するためのキャリアとして使用される。

図２Ｅには、ファイルをセキュアにするための選択肢は示されていない。一実施例では、ファイルはコンテンツをプロテクトするための暗号によって、若しくは暗号化方式に従ってスクランブル化される。そこでは、ヘッダは、再生前に独立に解読されるかもしれない。ファイルが暗号化されているか、若しくは平文であるかに関係なく、それは同様に細分化することが可能である。ヘッダサイズが２６６において決定されると、ヘッダ部分が容易に生成される。それと同時に、ファイルの残りの部分はｋ個のセグメントに間引きされる。他の実施例では、ヘッダとこれらｋ個のセグメントの０以上とがサービスを提供する各ボックスに分散される。何れのボックスがセグメントを受信するか決定するための詳細が以下で説明される。何れのケースでも、ヘッダとセグメントは分散前にセキュア化されてもよい。２７０において、あるタイプのセキュリティがヘッダとセグメントに埋め込まれるようにしてもよい。実現形態に応じて、ヘッダとセグメントはそれぞれ、暗号化方式若しくは暗号（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＤＥＳ）アルゴリズム、Ｂｌｏｗｆｉｓｈブロック暗号、Ｔｗｏｆｉｓｈ暗号、ＲＣ−４など）に従ってそれぞれ暗号化されてもよく、及び／又はデジタル著作権管理（ＤＲＭ）によりプロテクトされるようにしてもよい。

２７４において、ヘッダとセグメント（すなわち、各パッケージ）とが、サービスを提供する各ボックスに分散される。本発明の一実施例によると、この分散化は、ボックスからボックスにデータのチャンクとして各パッケージを伝搬させることによって同期的若しくは非同期的に実行される。その詳細が以下に説明される。ボックスは、セグメントの１つ、複数若しくはおそらくすべてを受信するよう選択されてもよい。２７４の後、プロセス２６０は他のファイルに対して２６１に戻る。

一実施例は、ユーザに提供される多数のタイトルを有する動的に更新されるライブラリを可能にする。各タイトルは、瞬時の再生のため選択及び順序付けされるかもしれない。定期的に更新され（毎日など）、任意の時点に瞬時にアクセス可能な５０００タイトルなどを有する大きなライブラリが与えられると、そのうちの一部のタイトルは他のものより人気があり、より多くのユーザによってより頻繁に要求されるかもしれない。人気のあるタイトルを調達するためボックスの可能なバンド幅の問題若しくは利用不可を最小限にするため、常駐オブジェクト及び分散オブジェクトの提供は、例えば、人気、地理、人口及び／又は同様の基準などに従ってインテリジェントに実行されるべきである。

図３Ａは、ボックスの限られた格納スペースへのライブラリのタイトルの一例となる人気による分類を示す。便宜上、格納スペース３００は３００ギガバイトの容量を有し、瞬時の再生のため５０００タイトルが利用可能であることが仮定される。５０００タイトルのうちの何れかは、再生のため選択され、瞬時にアクセスされるかもしれない。ＶＯＤアプリケーションのため、各映画は平均的には約２時間であることが仮定される。大部分のユーザに受入可能な表示品質のためには、２時間の映画のファイルは約８４０メガバイトのサイズとなる。約３０メガバイトのヘッダに対して、４つのセグメントのそれぞれは、各ファイルのサイズが平均に近いものであると仮定すると、約２０３メガバイトとなると推定される（すなわち、（８４０メガバイト−３０メガバイト）×１／４）。従って、格納スペース３００は、図３Ａに示されるような分散化のため５０００タイトルを収容するため、約２４０ギガバイトとなることが推定される（すなわち、５０００タイトル×３０メガバイト＋５０タイトル×２セグメント×２０３メガバイト＋５０タイトル×２セグメント×２０３メガバイト＋４９００タイトル×セグメントの５％×２０３メガバイト＝２４０ギガバイト）。

図３Ａの実施例によると、これら５０００タイトルは２つのバンドに分割され、上位バンド３０２は、新たにリリースされた若しくは人気のあるタイトルのためのものであり、下位（Ｌ）バンド３０４は、比較的に人気がないが、ときどき要求されるタイトルのためのものである（例えば、００７のＪａｍｅｓ Ｂｏｎｄやマイナーなディズニー映画など）。ライブラリが５０００タイトルを有する場合、上位バンド３０２は１００タイトルを収容するよう割り当てられ、低バンド３０４は残りの４９００タイトルを収容するよう割り当てられるようにしてもよい。新たなタイトルがリリースされ、上位バンドに追加される毎に、上位バンド３０２にすでにあるタイトルは破棄若しくは低バンド３０４に移される。他の実施例では、上位バンドはさらに２つのバンドに分割されてもよく、高バンド（Ｈ）は最新の５０タイトルなどのため、中バンド（Ｍ）はやや古い次の５０タイトルのためのものである。

中バンド（Ｍ）の割当ては、上位バンドにおけるタイトルのフレキシブルな管理を実現する。映画レンタルビジネスにおける収入の７０％以上が上位バンドのタイトルからのものであり、その収入の４０％以上が高バンド（Ｈ）のタイトルからのものであることが推定される。さらに後述されるように、より多くのリソースを高バンドのタイトルを迅速に更新するよう割当てるため、又は他のボックスの高バンドのタイトルの依存性を低減するため、中バンド（Ｍ）のタイトルのセグメント数は減少するか、又は中バンド（Ｍ）のタイトルのあるパーセンテージのみが１以上のセグメントによりキャッシュされるかもしれない。

本実施例では、Ｈ、Ｍ及びＬバンドにそれぞれ５０、５０及び４９００タイトルが存在する。一般に、ボックスが十分長い期間サービス提供していたとき、上位バンド３０２の各タイトルは、ヘッダと１つ若しくは２つの対応するセグメントにより提供され、Ｌバンドの各タイトルは、ヘッダとセグメントの一部により提供される。Ｌバンドのタイトル毎のセグメント数に関する限り、そこにおけるタイトルのあるパーセンテージのみが各タイトル毎に１つのセグメントにより提供され、これらのタイトルは、典型的には、ボックス毎に異なっている。上位バンド３０２のタイトルに対する要求がＬバンド３０４のタイトルよりはるかに大きいため、Ｌバンドのタイトルに対するボックスにおけるセグメントのパーセンテージは、５％などの比較的小さな値に設定されてもよい。Ｌバンドのタイトルのセグメントの分散化は、常にシステムにこれらのタイトルの少なくとも１つの分散コピーと、上位バンドのタイトルのより多くの分散セグメントがあるように行われる。他の観点から、上位バンド３０２のタイトルが選択されると、発注元のボックスのタイトルの再生をサポートするため、分散セグメントを供給するよう指定されるより多くのボックスがあり、これにより、他のボックスが欠落したセグメントを供給するのに利用不可となる可能性を低減することができる。低バンドタイトルが選択された場合、相対的に低い人気のため、ネットワークにおいて利用可能な十分な分散コピーが存在する可能性が高く、これにより、他のボックスが再生のための各セグメントを供給するよう指定することが可能である。

動作について、Ｈバンドのタイトルがボックスにおいて選択された場合、そのセグメントの２つが当該ボックスにすでに常駐している。従って、これら２つの欠落したセグメントを供給するため、他に２つのボックスしか必要でない（すなわち、依存性＝２）。Ｌバンドのタイトルが選択されると、多くの場合、４つのセグメントを供給するため、他に４つのボックスが必要とされる（すなわち、依存性＝４）。すなわち、タイトルの人気は、発注元のボックスの他のボックスへの依存性を決定する。あるタイトルの人気が高いほど、発注元のボックスの他のボックスへの依存性は低くなる。

上述されるように、ライブラリは定期的に（毎日、毎週など）更新される。新たなタイトルが受け付けされる毎に、この新たなタイトルは、典型的には、Ｈバンドに追加される。一実施例では、Ｈ、Ｍ及びＬバンドに相対的に固定された個数のタイトルを維持することが所望され、Ｈバンドの相対的に人気の低いタイトルがＭバンドに移され、Ｍバンドの最も古いタイトル若しくは相対的に人気の最も低いタイトルがＬバンドに移される。他方、まれにではあるが、Ｌバンド若しくはＭバンドのタイトルがより上位のバンドに昇格することも可能である。あるタイトルがＭバンドからＬバンドに移されるときは常に、Ｌバンドの最も古い若しくは相対的に最も人気の低いタイトルが破棄されるかもしれない。図３Ａによると、あるタイトルが上位バンド３０２からＬバンド３０４に移されるときは常に、上位バンド３０２の１つ又は両方のセグメントが、当該タイトルが１つのセグメントを維持するため指定されるパーセンテージの範囲内であるか否かに応じて欠落される。

一般に、ライブラリを更新するため、１日に複数のタイトルがリリースされる。しかしながら、これらのタイトルのすべてが必ずしも新たなタイトルではなく（すなわち、上位バンドのための）、その一部は大変人気が高く、他のものはあまり人気がない。例えば、ライブラリが１日に１０タイトルにより更新され、そのうちの１つは、上位バンドにおいて新たにリリースされたタイトルであり、９つはＬバンドにおいて人気の低いタイトルである。当該タイトルが上位バンドに追加されると、対応する２つのセグメントがまた追加され、それと同時に、上位バンド（おそらくＭバンド）の比較的古いタイトルが破棄若しくはＬバンドに移されるかもしれない。Ｍバンドからの比較的古いタイトルは、上記９つのタイトルと組み合わされてもよく、これら１０個のタイトルの何れが、それの１つのセグメントがあるボックスに対してローカルにキャッシュされると仮定されるパーセンテージ（５％など）に属するか決定される。

当該実施例では、各ボックスは、利用可能なタイトル毎に１つである５０００個のヘッダをキャッシュしている（おそらく、サイズについては同じ若しくは異なり、フォーマットについてはおそらく異なり、利用されるセキュリティについてはおそらく異なるなど）。これらの常駐オブジェクトは、ユーザがタイトル発注時に瞬時に再生を開始し、他のボックスからの分散オブジェクトの受信を開始するのに十分な長さの再生を続けることができることを保証する。セグメントの分散化の説明を容易にするため、４つのセグメントはそれぞれ１、２、３及び４とラベル付けされる。上位バンド３０２のタイトルについては、２つのセグメントがローカルに分散され、他のボックスに２つのセグメントが分散されている。この結果、ローカルに格納されているセグメントについて、（セグメント１，セグメント２）、（セグメント１，セグメント３）、（セグメント１，セグメント４）、（セグメント２，セグメント３）、（セグメント２，セグメント４）、（セグメント３，セグメント４）の６つの可能な組み合わせが存在する。これらの組み合わせは、サービスを提供するボックス間に等しく分散されている。発注元のボックスがセグメント１とセグメント２を有する場合、第１の他のボックスと第２の他のボックスが、セグメント３及びセグメント４をそれぞれ発注元のボックスに提供するため呼び出される必要がある。セグメント３又はセグメント４を有するボックスが、第１の他のボックス若しくは第２の他のボックスであるかもしれない。例えば、（セグメント１，セグメント３）を有するボックスと、（セグメント１，セグメント４）を有する他のボックスとが、それぞれ第１の他のボックスと第２の他のボックスであるかもしれない。

一実施例では、各ボックスはいくつかのタイプに分類される。例えば、６つのタイプのボックスが存在し、各タイプは上述した６つの組み合わせの１つを格納するため指定されている。各ボックスの対応するヘッダに加えて、Ｈバンドに５０タイトルがある場合、これら５０タイトルのそれぞれのセグメントは、６つの組み合わせの１つに従って分散される。

Ｌバンドのタイトルに対して、各ボックスは当該タイトルの５％の１つのセグメントを格納する。Ｌバンドのタイトルの１つが発注されると、当該ボックスはローカルにキャッシュされたセグメントを有しているかもしれないし、そうでないかもしれない。従って、Ｌバンドのタイトルのセグメントの分散化は、サービスを提供しているボックスが一緒になってすべてのタイトルのすべてのセグメントを有することを保証する必要がある。すなわち、Ｌバンドの各タイトルの少なくもと１つのコピーがネットワークに存在している必要がある。

サービスを提供しているボックスの間にＬバンドのタイトルのセグメントを分散させる方法がいくつかある。一実施例によると、Ｌバンドのタイトルのセグメントの分散化を管理するため、Ｈバンドのタイトルのセグメントの分散化が参照される。例えば、Ｈバンドのタイトルのセグメント１とセグメント２がローカルに格納されているとき、Ｌバンドのタイトルのセグメント１又はセグメント２がローカルに格納される。（上位バンドから低バンドへのタイトルの移行時に、ボックスはセグメントの１つを破棄すればよいためである。）従って、分散化の以下の管理が成り立つ。

Ｌバンドの何れのタイトルが特定のボックスの選択されたパーセンテージの範囲内に属するかの判断は、いくつかのファクタに基づき決定されるかもしれない。一実施例では、このパーセンテージは、タイトルの経過時間若しくは人気の潜在的にランダム化された関数として決定される。他の実施例では、このパーセンテージは、あるエリアにおける所望される言語及び視聴行動の統計と、他のボックスからの分散オブジェクトの抽出をより効率的に実現することを可能にする他の指標とに基づき決定される。さらなる他の実施例では、当該パーセンテージは、
１．ユーザがボックスからこれまで視聴したプログラム（映画など）のセット
２．ユーザがボックスについて評価した（１〜１０のスケールなどにより）プログラム
３．以降の視聴のためユーザにより作成された選好リストに関するプログラム
４．ブラウジング動作（例えば、ユーザが視聴した予告、タイトルの簡単な紹介を読むのにユーザが費やした時間など）
の一例となるリストの一部若しくはすべてを動的に記録したボックスに埋め込み可能な学習エンジンから決定される。

この学習エンジンは、映画などの何れのプログラムがユーザが視聴したものと類似しているか示すための統計を提供するよう起動されるかもしれない（例えば、俳優、監督、ジャンルなどに関して）。これにより、これらの映画は、対応するセグメントを有するタイトルのパーセンテージの範囲内となるよう選択される。さらに、何れの映画のペアが類似しているかについての判断は、“協調フィルタリング”と呼ばれるものに基づき行われ、すなわち、多数のユーザがある映画ペアを視聴することを好む場合、これら２つの映画は類似しているとみなされるかもしれない。従って、ボックスにおいておそらく選択及び発注されるものと類似したさらなる映画が、当該パーセンテージのタイトルに追加されるかもしれない。何れの場合にも、ボックスは、当該ボックスを介しユーザにより選択及び発注される可能性が高いタイトルに係るセグメントをキャッシュするかもしれない。他の実施例では、各映画は、特定の属性によって規定されるかもしれない。ユーザ行動は、特定の属性のユーザの嗜好を示すかもしれない。選好される属性と映画属性とをマッチングすることによって、学習エンジンは、１つのバンドのタイトルの何れのセグメントが各ボックスに格納すべきか判断するかもしれない。また、類似するが異なるユーザの間で比較をすることが可能である。例えば、第１ユーザがアクションベースの映画を選好し、以前に映画Ｘ、Ｙ及びＺを発注しており、第２ユーザがアクションベースの映画を選好する場合、学習エンジンは、第２ユーザのボックスに映画Ｘ、Ｙ及びＺＸのセグメントを格納しようとするかもしれない。

図３Ｂは、ボックスの限られた格納スペース内のライブラリのタイトルの他の一例となる人気による分類を示す。図３Ａと図３Ｂとの間の主要な相違点の１つは、図３Ａの上位バンド３０２が各タイトルの１つのヘッダと２つのセグメントを保持し、図３Ｂの上位バンド３１０が各タイトルの１つのヘッダと１つのセグメントを保持していることである。

図３Ａ若しくは図３Ｂとは反対に、一実施例によると、サービスを提供するすべてのボックスは、Ｈバンドに１以上のタイトルのための２より多くのセグメントを有するよう構成されるかもしれず、これにより、これらの強く要求されるタイトルの分散コピーの個数を実質的に増加させる。あるタイトルが新たにリリースされ、若しくは統計的に人気があると判断されると、サービスを提供しているボックスは、発注元のボックスの他のボックスへの依存性が大きく低減するように、これらのタイトルのセグメントの個数を増加させるよう動作可能である。

図３Ｃは、ライブラリのタイトルの人気に従う他の一例となるバンド化方式を示す。このバンド化方式は、ライブラリのタイトルを複数のバンド（５バンドなど）に分割する。曲線３２０は、Ａ、Ｂ、Ｃ、Ｄ及びＥの各バンドを示し、Ａバンドは最も人気の高いタイトルを示し、Ｅバンドはライブラリにおいて相対的に最も人気の低いタイトルを表す。各バンドにおいて利用可能なタイトルは、例えば、要求統計、地理的位置、所望される言語、タイトルの古さ、人口統計情報などからの１以上の指標に従って定期的に更新されてもよい。各ボックスは、Ａバンドのタイトル（例えば、１つ又は２つの新たにリリースされたタイトルなど）のヘッダと対応するセグメントのすべてを格納する。各ボックスは、Ｂバンドのタイトルのヘッダと３つのセグメントをローカルに格納する。各ボックスは、Ｃバンドのタイトルのヘッダと２つのセグメントをローカルに格納する。各ボックスは、Ｄバンドのタイトルのヘッダと１つのセグメントとをローカルに格納する。さらに、各ボックスは、Ｅバンドのタイトルのうちの５％などの小さなパーセンテージのヘッダと１つのセグメントとを格納する。この結果、図３Ｄに示されるテーブル３２６にリストされるような連続再生のためのバンドの各タイトルの依存性は、それぞれ０、１、２、３及びおそらく４となる。

完全性のため、テーブル３２６はまた、各バンドのタイトルに対する要求の一例となる統計を示すカラム３２８を有し、すなわち、バンドＡのタイトルに対する要求は、ライブラリに対するリクエスト全体の約６０％となると予想される。バンドＢ、Ｃ、Ｄ及びＥのタイトルに対する逓減する要求は、２０％、１０％、８％及び２％として示される。バンドＡのタイトルに対する要求が大きいかもしれないが、バンドＡのタイトルに対する他のボックスへの発注元のボックスの依存性はゼロとなる。従って、バンドＡのタイトルに対する注文は、ローカルに実現することが可能となる。他方、バンドＢ、Ｃ、Ｄ及びＥのタイトルに対する要求は徐々に低下する。従って、バンドＢ、Ｃ、Ｄ及びＥにおける発注元のボックスの依存性は徐々に増加する。バンドＢ、Ｃ、Ｄ及びＥのタイトルの分散コピーは徐々に減少する。

図３Ｃ及び３Ｄを参照して上述したバンド化方式は、タイトルの人気に従って規定された個数のセグメントに対して任意数のバンドに論理的に拡張されるかもしれない。例えば、各ボックスがバンドのタイトル毎に平均して２．５セグメントを格納する上述の具体例において、バンドＢとバンドＣとの間にあるバンドＢ’を導入してもよい。このような平均セグメント数を生成及び制御する１つの方法は、半数のボックスに２つのセグメントを格納し、半数のノードに３つのセグメントを格納するものである。極端な例では、各タイトルは、異なる個数のセグメントを有するだけでなく、各ボックスはまた、各タイトルに対していくつのセグメントをローカルにキャッシュするか独立に決定するかもしれない。一般に、あるタイトルの人気が高くなるに従って、より多くのセグメントがローカルにキャッシュされ、より多くの分散コピーがネットワークにおいて利用可能になる。何れの場合でも、ライブラリのタイトルが何れのセグメントもローカルにキャッシュされないとき、ネットワークに対応するすべてのセグメントの少なくとも１つのコピーが存在していなければならない。そうでない場合、このようなタイトルに対する注文は提供できなくなる。

図３Ｅは、瞬時のアクセスのためタイトルのライブラリを分類するフローチャート又はプロセス３６０を示す。当該プロセス３６０は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び／若しくはシステムとして実現されるかもしれない。当該プロセス３６０がＶＯＤシステムにおいて使用されるとき、タイトルに係るファイルは、図２Ｅのプロセス２６０に従ってヘッダと１以上のセグメントに細分化されるかもしれない。３６２において、これらのタイトルに係るファイルがいくつ分散化されるべきか決定する必要があり、これにより、各ライブラリに格納されるタイトル数を規定することが可能となる。一般に、ライブラリにおいて利用可能なタイトル数は、ボックス内の格納スペースの容量、ヘッダサイズ、ネットワークスピード、要求、ファイルサイズ、要求されるデータ転送スピード、同時サポートなどを含むいくつかのファクタの関数である。一実施例では、５０００個のタイトルがライブラリにおいて提供可能であると判断され、各タイトルは、平均して２時間であり、８４０メガバイトから１ギガバイトのサイズを有する。図２Ｅのプロセス２６０は、ファイルの細分化を決定するのに利用可能である。バンド数が決定されると、プロセス３６０は３６４に移行する。

３６４において、これらのタイトルが各バンドに分類される。少なくとも２つのバンドが利用され、上位バンドは最も人気のあるタイトル（新たなリリースなど）のためのものであり、低バンドは相対的に人気の低いタイトルのためのものである。実現形態に応じて、上位バンドにも低バンドにも適合しないタイトルを格納し、ライブラリの更新を実現するため、１以上の中間バンドが導入されてもよい。上述されたように、同時発注に適応するため、他のバンドのものより上位バンドのタイトルの分散コピーがより多くされる。動作について、上位バンドのタイトル数は、好ましくは、ボックスの格納スペースの利用を最適化するよう小さく維持される。

３６６において、各バンドのセグメント数が決定される。一実施例によると、上位バンドのタイトルのセグメントがより多くローカルにキャッシュされ、より多くの分散コピーをネットワークにおいて利用可能にする。この結果、より人気のあるタイトルに対して、発注元のボックスは、当該タイトルの連続的な再生に必要とされるセグメントを供給するため、他のボックスにあまり依存しなくなる。他方、低バンドのタイトルのあるパーセンテージのみがローカルにキャッシュされ、ネットワークにおいて利用可能な分散コピーがより少なくされる。システムが中間バンドを有するよう構成される場合、ローカルにキャッシュされるセグメント数は、上位バンドから徐々に減少するかもしれない。

３６８において、プロセス３６０は、セグメントをキャッシュするボックスを決定する。実現形態に応じて、セグメント分散方式は、タイトルの効率的な格納と効果的な調達のためにセグメントキャッシュ処理を最適化するため、異なるファクタに基づくかもしれない。一実施例では、セグメントの分散化は、視聴行動に基づき決定される。ユーザの視聴行動を調べることによって、何れのボックスがあるタイトルを発注する可能性が高いか統計的に決定されるかもしれない。例えば、アクション映画を頻繁に発注するユーザは、他のアクション映画を発注する可能性が高い。アクション映画のタイトルに係るセグメントを分散させるとき、当該分散化は、これらのセグメントがアクション映画を発注する可能性が統計的に高いボックスになされることを保証するよう調整されるかもしれない。他の実施例では、分散化は、所望される言語に基づくかもしれない。スペイン語など所望される言語によるタイトルに係るセグメントの分散化は、このようなセグメントが所望される言語により映画を発注する可能性が統計的に高いボックスになされるように行われるかももしれない。

図３Ｆは、ボックスのライブラリを更新するフローチャート又はプロセス３８０を示す。プロセス３８０は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び／又はシステムとして実現されるかもしれない。プロセス３８０がＶＯＤシステムに使用されるとき、タイトルに係る大きなファイルが、図２Ｅのプロセス２６０に従ってヘッダと複数のセグメントに細分化されるかもしれない。各ボックスのライブラリは、定期的に又は所定の時間に更新される。プロセス３８０は、サービスを提供するすべてのボックスが利用可能なタイトルに関して同期されるように、ライブラリを動的に更新するのに利用されるかもしれない。

３８２において、プロセス３８０は、リリースを待機する。後述されるように、リリース（１以上のタイトルから構成される）は、サーバ（図２Ａのサーバ２０２など）から直接的に提供されてもよく、又は他のボックスから伝搬されてもよい。リリースの各タイトルは、ヘッダといくつかのセグメントに細分化される（例えば、図２Ｅのプロセス２６０などによって）。ヘッダと４つのセグメントとに細分化されたタイトルについて、（ヘッダ，セグメント１，セグメント２）、（ヘッダ，セグメント１，セグメント３）、（ヘッダ，セグメント１，セグメント４）、（ヘッダ，セグメント２，セグメント３）、（ヘッダ，セグメント２，セグメント４）、（ヘッダ，セグメント３，セグメント４）のボックスが所望する（ヘッダと２つのセグメントを要求するタイトルに対して）可能性のある６つのリリースパッケージが存在する。これらのリリースパッケージの少なくとも１つが、ボックスにおいて受信される。

一実施例では、リリースが利用可能であるというメッセージ若しくはデータセットをサーバ若しくはボックスから受信すると、プロセス３８０が開始される。３８４において、リリースパッケージに従って、リリースの各タイトルに適したバンドが決定される。上述されるように、当該タイトルは何れかのタイプに係るものであるかもしれない（高バンド若しくは低バンドなど）。従って、タイトルを収容するのに適したバンドが決定される。バンドに所定数以上のタイトルが収容されることを回避するため、好ましくは、バンド内の既存の相対的に人気の最も低いタイトルがバンドから排除される。３８６において、このようなバンド内の相対的に最も人気の低いタイトルが決定される。一実施例では、リリースに関する受信メッセージは、何れのバンドの何れの既存のタイトルが破棄若しくは低バンドに移されるべきか示す。３８８において、当該タイトルが、それに係るヘッダと対応するセグメント（それはないかもしれない）とをボックスにおいて受信することによって、割り当てられたバンドに追加される。

３９０において、ボックスのライブラリリストが更新される。実現形態に応じて、ライブラリリストは、排除されたタイトルを削除し、新たなタイトルを追加することによってローカルに更新されるかもしれず、又は更新されたライブラリリストが受信されるかもしれない。この結果、排除されたタイトルは、もはや利用可能でなく、新たなタイトルが注文可能となる。

図４Ａを参照すると、サービスを提供するすべてのボックスのライブラリを更新する図４００が示される。サーバ（図２Ａのサーバ２０２など）がライブラリを更新すると、すべてのボックスのライブラリがこれに呼応して更新される。一実施例によると、更新プロセスは同期的に及び／又は非同期的に実行される。

サーバ４０２は、ヘッダとセグメントによりタイトルのリリースに係るファイルを準備するよう構成される。ファイルを準備する一例となる方法は、図２Ｅのプロセス２６０である。便宜上、ヘッダと４つのセグメントが存在することが仮定される。従って、上述されるように、何れのバンドにリリースが配備されるかに応じて、複数のリリースパッケージが存在するかもしれない。動作について、サービスを提供する各ボックスは１つのリリースパッケージを受信するよう構成される。

まず、サーバは、リリースに関するメタデータ、ライブラリから破棄されるべき最も人気の低いタイトル及び／又はタイトル移転を含むリリース命令を準備する。当該命令は、何れのボックスが何れのリリースパッケージを取得し、パッケージが何れの方法により受信されるべきか（すなわち、他の何れのボックスから）を記述するかもしれない。例えば、この命令は、特定の特性を示す識別子によって特定されるボックスがリリースパッケージＸを受信すべきか指定することが可能である。一般にすべてのリリースに適用されるデフォルト命令があり、また特定のリリースに適合された命令があるかもしれない。リリースパッケージをボックスに割り当てる目的の１つは、同一若しくは異なるセグメントを保証するため、サービスを提供するすべてのボックスに等しくパッケージを分散することであるかもしれない。

リリース命令は、サーバによって準備されると、サーバとボックスとの間の直接的な通信を介して、又は後述されるｇｏｓｓｉｐプロトコルを介した命令のボックスからボックスへの伝搬によってサービスを提供するボックスに伝搬される。何れの場合にも、各ボックスが、それがあるリリースパッケージを受信する必要性を認識していることが仮定される。

リリースは、当該リリースに対するヘッダとセグメントとを表すデータチャンク４０３のシーケンスに変換される。データチャンクは、サーバからボックスへの若しくは２つのボックス間のデータ転送の最小単位である。例えば、各データチャンクは、１メガバイトのサイズを有し、一意的に特定されるかもしれない。データチャンク４０３のシーケンスは、ライブラリを更新するためボックスに伝搬される２つの別個のタイトルを表すかもしれない。一般に、各ボックスは、当該ボックスに対応する適切なリリースパッケージを構成するデータチャンクの特定のサブセットを所望する。さらに、リリース命令自体は、すべてのボックスに伝搬される１以上のデータチャンクとして表されてもよい。

動作について、サーバ４０２は、ボックス群４０４−１，４０４−２，．．．，４０４−ｎとの各通信を開始し、各ボックスに当該ボックスによって要求されるデータチャンクのいくつかを提供する。好ましくは、各データチャンクは、サーバ４０２により少なくとも１つのボックスに提供される。データチャンクを最初に受信するボックス４０４−１，４０４−２，．．．，４０４−ｎの正確な個数は、分散化を制限しない。一実施例では、ボックス４０４−１，４０４−２，．．．，４０４−ｎの指定は完全にランダムである。他の実施例では、ボックス４０４−１，４０４−２，．．．，４０４−ｎの指定は、時間帯、地理的位置、利用可能なネットワーク帯域幅及びその遅延、ボックスのインターネットサービスプロバイダなどの１以上に基づく。何れの場合も、サーバがアイドル状態であるときは常に、サーバ４０２は常時データチャンクを受信する異なるボックスを指定することが可能である。

各ボックス４０４−１，４０４−２，．．．，４０４−ｎは、“ｇｏｓｓｉｐプロトコル”と通常呼ばれている、アプリケーションレイヤマルチキャスト形式のプロトコルに基づき、サービスを提供する他のボックスにデータチャンクを拡散するよう構成される。ボックス４０４−１，４０４−２，．．．，４０４−ｎの全てが同一のデータチャンクを受信している必要がないことに留意すべきである。ボックス４０４−１，４０４−２，．．．，４０４−ｎの何れも、それがデータチャンク全体を受信するとすぐに、データチャンクを他のボックスに拡散することを開始するようにしてもよい。動作について、ボックス４０４−１は、それの受信したデータチャンクの少なくとも一部を、同時に互いの通信するボックス４０６−１，４０６−２及び４０６−３に伝搬するよう割り当てられる。ボックス４０４−２は、それの受信したデータチャンクの少なくとも一部をボックス４０６−２及び４０６−３に伝搬するよう割り当てられる。ボックス４０６−２は、データチャンクを自らに供給するよう構成されるボックス４０４−１、４０４−２及び他の何れかのボックスから何れのデータチャンクを取得するかについて正確に知っているよう構成される。さらに、ボックス４０６−２は、それが受信したデータチャンクの少なくとも一部をボックス４０８−１、４０８−２及び４０８−３に伝搬するよう割り当てられる。データの伝搬は必ずしも階層的である必要はないことに留意されたい。例えば、ボックス４０８−１は、図示されるように、データチャンクを後方の４０６−１に送信するようにしてもよい。

一実施例では、データチャンクは、無駄なデータ転送を回避するため、特定のチャンクを実際に所望するボックスのみに伝搬される。さらに、ボックスがすでにデータチャンクを有しておらず、何れかから当該チャンクをダウンロードするプロセスにいない場合に限って、データチャンクがボックスに伝搬されることを保証することによって、無駄なデータ転送が回避されるかもしれない。チャンクの伝搬は、すべてのボックスが協調的に同時に参加する同期プロトコルを通じたものであってもよく、又は各ボックスが参加すべき時とどのくらいの期間参加するかフレキシブルに選択可能な非同期プロトコルを通じたものであってもよい。例えば、ボックスは、それが発注元のボックスに対する映画のサービス提供に忙しいときは常に、又はネットワークがその使用量が大きいと検出されたとき、チャンクのダウンロード及び伝搬への参加を中止するようにすることができる。ボックスは、ネットワーク状態を連続的に監視し、十分な帯域幅が利用可能であるときは、適応的にｇｏｓｓｉｐ伝搬に再参加するようにしてもよい。

動作について、何れかの理由によりボックスの何れか１つがデータチャンクの受入に失敗した場合、供給元若しくは代替ボックスがデータチャンクを送受信するよう構成可能であるときは当該ボックスを外すことができる。リリースを欠いたボックスは、１以上の更新されたボックスから以降に当該データをフェッチするようにしてもよい。ボックス・アフター・ボックス（ｂｏｘｅｓ ａｆｔｅｒ ｂｏｘｅｓ）を介しデータチャンクを繰り返しかつ再帰的に伝搬することによって（すなわち、同期的及び／又は非同期的にプル若しくはプッシュすることによって）、最終的には、サービスを提供するすべてのボックスに各リリースが存在することとなる（追加されるべきすべてのタイトルのヘッダ及び指定されたセグメントと、削除されるべきタイトルの識別）。

更新終了後、何れのボックスが何れのセグメントを有するか示すマップ４０９を構築することができる。マップ４０９によって、発注元のボックスから注文が受信される毎に、サーバは、ローカルにキャッシュされていないセグメントを発注元のボックスに供給するため、適切なボックスを指定することができる。あるいは、マップ４０９は、ボックスが注文を実現するため、必要とされるセグメントをフェッチするためのソース情報を取得することを可能にする。

リリースが上位バンドに対するものでないとき、何れのボックスが何れのセグメントを保持すべきかの判断は、必要に応じてボックス間のセグメントを転送効率を最大化するため、地理的位置、時間帯、視聴行動若しくは選好される言語などの複数のファクタに基づくものであってもよい。

利用可能なタイトルのリストからのタイトルの削除は最初にボックスに配布されるかもしれないということが理解されるべきである。このようにして、何れのボックスももはや利用可能でないタイトルを発注しないようになる。タイトル削除命令の配信は、上述したｇｏｓｓｉｐプロトコルを用いて実現されてもよく、又は直接的なボックスからサーバへの通信によって提供されてもよい。

図４Ｂを参照すると、サービスを提供するボックスにリリースを提供するフローチャート又はプロセス４１０が示される。当該プロセス４１０は、中央サーバを使用することなく複数の一に維持されているディレクトリを更新するのに特に有用である。プロセス４１０の可能な特徴及び効果の１つは、複数の位置におけるディレクトリが、アプリケーションレイヤマルチキャスト系のｇｏｓｓｉｐプロトコルによって、場所から場所を介しデータチャンクの更新を伝搬することによって、同期的に及び／又は非同期的に更新されるということである。プロセス４１０がＶＯＤシステムに使用されるとき、多数のタイトルを有するライブラリが、同時更新をサポートするのに高帯域幅を要求することなく、動的に又は効率的に更新されるかもしれない。

４１２において、プロセスは、データネットワーク上の装置（サーバプロバイダによるサーバなど）において利用可能なるリリースを待機する。リリースが利用可能になると、リリースに係るファイルが、ボックスへの配信のため４１４においてサーバに準備される。図２Ｅのプロセス２６０は、各ファイルに対してヘッダと対応するセグメントへの細分化のための一例となるプロセスであってもよい。

４１６において、ヘッダ及びセグメントはデータチャンクに分割される。４１８において、サーバは、データチャンクの少なくとも一部を受信する初期ボックス群を指定する。一実施例では、これらのボックスは、同一のデータチャンクを受信しなくてもよい。実現形態に応じて、サーバは、各データチャンク群を初期ボックスにプッシュし、又は初期ボックスがサーバから各データチャンク群をプルするようにしてもよい。いくつかの実施例では、すべてのデータチャンクのコピーが初期ボックスに配信され、これにより、初期ボックスはサーバとのさらなるやりとりなくシステムのその他のボックスに提供することが可能となる。

４２０において、プロセス４１０は、何れのボックスが何れかのデータチャンクを受信することができなかったか判断する。データチャンクを受信しないボックスがある場合、プロセスは４２２に移行し、初期ボックス群に属しないボックスが失敗したボックスに置換される。この結果、少なくとも１つの完全なデータチャンク群が、提供するボックス群に同期的又は非同期的に配信されるかもしれない。

その後、プロセス４１０は４２４に移行し、提供する各ボックスは、受信したデータチャンクの少なくとも一部を１以上の他のボックス（物理的に近い他のボックス群など）に拡散するよう構成され、他の各ボックスは、それが受信したデータチャンクの少なくとも一部を他のボックスにさらに拡散するよう構成される。データチャンクをまとめてフェッチするため、何れのボックスも同時に複数のボックスと通信するようにしてもよいということが留意されるべきである。プロセス４１０は、その後に他のリリースを待機する４１２に戻る。

動作について、プロセス４１０は、１回に１つのタイトルによりライブラリを更新することに限定されるものでない。タイトルをデータチャンクに変換することによって、複数のタイトルが、ボックス間でデータチャンクを非同期的に伝搬することによってシステムに拡散されるようにしてもよい。また、プロセス４１０は、他のタイトルが配信可能になるまでに終了している必要はない。１つのリリースがサービスを提供するボックスに完全に提供されるまで、他のリリースが配信可能とされてもよい。動作について、プロセス４１０は、好ましくは、真夜中などのネットワークトラフィックが低いときに開始される。典型的には、プロセス４１０は、終了するのに数時間かかるかもしれない。

図４Ｄは、ブロードキャスト又はマルチキャストのためサービスプロバイダに１以上の高帯域幅チャネルが提供される構成に対してサービスを提供するボックスにリリースを提供するフローチャート又はプロセス４４０を示す。このような構成は、超高速ブロードキャスト又はマルチキャスト能力を享受するケーブル又は衛星インフラストラクチャにおいて、又はマルチキャストサポートを有するデータネットワークにおいて見出されるかもしれない。プロセス４１０は、好ましくは図４Ｃに関して理解され、ボックスには受信機能（チューナなど）が備えられ、放送を受信するための適切なチャネルにチューニングされることが仮定されるボックスのライブラリを１以上のタイトルにより更新するためのインフラストラクチャを利用する。このようなボックスの具体例として、衛星受信ボックスやケーブルセットトップボックスがあげられる。

図４Ｃに示されるように、サーバ４３２が、ケーブルネットワーク（すなわち、媒体としての同軸ケーブルやファイバ）又は衛星ネットワーク（すなわち、伝送媒体としての大気）であるかもしれないネットワークに接続される。図４Ａのサーバ４０２と同様に、サーバ４３２はリリースを配信するためのものである。４４２において、プロセス４４０はリリースを待機する。プロセス４４０は、リリースが利用可能になると開始される。４４２において、リリースに係るタイトルがボックスへの配信のためサーバ４３２において準備される。図２Ｅのプロセス２６０は、各タイトルのヘッダ及び対応するセグメントへの細分化のための一例となるプロセスである。

４４６において、すべてのタイトルに対するヘッダとすべてのセグメントを含むリリースパッケージが、所定の時間に又は定期的にネットワーク４３６にブロードキャストされる。４４８において、サーバ４３２から受信可能な、又はローカルに構成可能な命令に従って、各ボックスは、リリースからのそれの構成に従ってデータをキャプチャ及びキャッシュする。例えば、ヘッダを受信し、セグメントを受信しないと仮定されるボックスは、ヘッダのみをキャプチャ及びキャッシュする。ボックスがヘッダと２つのセグメントを受信すると仮定される場合、当該ボックスは、ヘッダと２つのセグメントのみをキャプチャ及びキャッシュする。

サービスを提供する各ボックスが統合された１つのリリースパッケージから適切なデータを選択するため、各ボックスのライブラリは同期的に更新される。一部のボックスがブロードキャストの際に更新することができなかった場合、これらのボックスは次の簿ロードキャストにおいて更新されるか、又は上述したような図４Ｂのプロセスを利用して他の更新されたボックスにより非同期的に更新することができる。一実施例では、ケーブル又は衛星インフラストラクチャにおける複数のチャネルが、例えば、指定されたチャネルにおける各リリースパッケージなどをブロードキャスト又はマルチキャストすることによって、更新プロセスを円滑化するのに利用されてもよい。上述されるように、１つのシナリオでは、それぞれが１つのタイプのボックスに相当する６つのリリースパッケージが存在するかもしれない。また、ボックスは、それのリリース用の特定のチャネルにチューニングされるように構成されてもよい。

最近サービスを開始した、又は長い期間の後にネットワークに最近再接続された新たなボックスは、ここではまとめて新規ボックスと呼ばれる。これらの新規ボックスは、エンプティであってもよいし、又は出荷のためパッケージ化され、又はネットワークから切断された時点では利用可能であり、さらに一部は現在も利用可能であり、一部は現在は利用不可であるタイトルのヘッダ及びセグメントを含むものであってもよい。これら新規のボックスがネットワークから切断されている間、アクティブなボックスのライブラリは何回も更新されているであろう。この結果、もとのライブラリは古いものとなっている。

サービスプロバイダは毎日１０個のリリースによりライブラリを更新し、ライブラリの合計タイトル数は５０００であることが仮定されている。アイドル時間が１０日間である場合、もとのライブラリは１００個のリリースを欠落している。アイドル時間が約６ヶ月である場合、ボックスのもとのライブラリは約１８００個のリリース分だけ古いものとなっている。図５Ａは、一実施例によるライブラリ５００に対する段階的な更新を示す。新規ボックス（切断又は単に出荷前にライブラリによりコピーされた）になった時点で、ボックスは、上位バンド５０４に１００個のタイトルと、低バンド５０６に４９００個のタイトルを有する。１８０日間サービスを提供していなかったボックスについて、ライブラリ状態５１０は、当該ボックスがどの程度古いものになったか、すなわち、ライブラリ５００が１８００個のリリースを見逃し、そのうちの１００個が上位バンド５０４のリリースであり、１７００個が低バンド５０６のリリースであることを示している。これらのボックスを購入するため店頭に置かれた場合、更新すべき多数のタイトルがないことになる。同様に、これらのボックスを購入するため店頭にない場合、新規ボックスのタイトルは古いものであるかもしれないが、更新すべきボックスは多くはない。

リリースが時間の経過と共に要求又は人気が低下し、最終的に低バンド５０６に置かれることは通常理解される。従って、１８０日後、もとのライブラリ５００には排除されるべき約１８００個のタイトルがあり、もとのライブラリ５００の３２００個のみがライブラリ５１０に維持されるかもしれない。一実施例では、１８００個のタイトルが、ネットワークがもはやそれらをサポートしなくなってからボックスがサービス提供する時点で即座に排除される。

ライブラリ５１０を更新するため、ボックスは、ボックスタイプとバンド情報に対応する１８００個の見逃したヘッダとセグメントを受信しなければならない。１８００個のリリースのヘッダと対応するセグメントのそれぞれをダウンロードするため、ネットワークの帯域幅の制約の下、ボックスがタイトルを注文するのに利用可能となるまでに数日間、数週間又は数ヶ月かかる可能性があり、運用上は所望されるものでない。

一実施例では、ボックスの更新を迅速化するプロセスは、上位バンドをさらなるバンドに分割することによって実現される。例えば、高（Ｈ）バンドと中（Ｍ）バンドとそれぞれ呼ばれる２つのバンドがあるかもしれない。各バンドは、例えば、Ｈバンドには５０タイトルとＭバンドには５０タイトルなどのいくつかのタイトルが割り当てられるかもしれない。便宜上、図３Ａは、Ｈバンド、Ｍバンド及びＬバンドによるタイトルの一例となる人気による分類として使用されるかもしれない。ボックスがライブラリを更新するのに必要な時間を短縮するため、Ｍバンドのための多数のセグメントのフェッチが回避されるかもしれない。このアイデアの背後にある合理性は、Ｍバンドのタイトルは人気が低下しつつあり、同時要求をサポートするため、ネットワークにおいて多くの分散セグメントがまもなく不要になるというものである。従って、例えば、新規ボックスはＬバンドと同様にＭバンドのタイトルを扱い、これらのタイトルの僅かなパーセンテージのみに対して１つのセグメントのみを格納することを選択するかもしれない。

同じ又は他の実施例では、ボックスは、ユーザがライブラリの人気のあるタイトルに迅速にアクセスすることを可能にし、セグメントのフェッチ前に見逃したタイトルのヘッダをフェッチすることによってライブラリ全体にアクセスすることを可能にする。ぼっくにヘッダがローカルに存在する限り、ユーザはタイトルを発注及び再生することが可能であり、ネットワークから分散セグメントをフェッチすることが可能となるため、当該タイトルがＨバンドにたまたま存在したとしても、何れのセグメントも再生を可能にするためローカルにキャッシュされる必要はない。従って、ボックスを更新するための良い戦略は、テールの前にヘッダをフェッチし、タイトルの人気に従ってヘッダがフェッチされるシーケンスを発注することを優先させることである。これにより、大部分の人気のあるタイトルが即座に利用可能となる。

同じ又は他の実施例では、いくつかのテールセグメントは、一部のヘッダより優先され、これにより、一部のセグメントはボックスにより迅速に受信され、セグメントの有用な供給者として機能を開始し、他のボックスからの要求にサービス提供することが可能となる。ライブラリ全体へのアクセスをどの程度の迅速さによりユーザに提供する必要があるかと、ユーザのボックスがシステムのロードの一部を負担する有用な供給者になることがどの程度重要であるとの間の解決される必要があるトレードオフに応じて、何れのセグメントが何れのヘッダに対して優先するか決定するための多数の方法が存在することは理解されるかもしれない。以下において、ヘッダとセグメントに関する優先度の選択の一実施例が説明される。

一実施例によると、新規ボックスは、Ｈバンドの５０タイトルのそれぞれのヘッダと１つの対応するセグメントとをダウンロードすることによって開始する。このデータは、５０タイトルの対応するヘッダと各セグメントを有する他のボックスからフェッチされてもよい。ライブラリ状態５１２は、Ｈバンドの所望の状態が第１日に更新されることを示している（Ｈバンドの更新全体が１日で終了すると仮定する）。Ｈバンドのタイトルを更新する方法はいくつかあるかもしれないということは理解されるかもしれない。一実施例では、最も要求されるタイトルからスタートしてＨバンドの各ヘッダがまず段階的にフェッチされ、その後、Ｈバンドの各タイトルのセグメントがフェッチされる。他の実施例では、最も要求されるタイトルから始めて、Ｈバンドの各タイトルのヘッダと対応するセグメントがまず段階的にフェッチされる。

Ｈバンドの５０タイトルがほぼ更新された後（各Ｈバンドタイトルが２つのローカルセグメントを要求する場合、各タイトルはこの段階で１つの見逃したセグメントを依然として有する）、Ｍバンドの５０タイトルが次に更新される。しかしながら、Ｈバンドの５０タイトルの更新中、他のタイトルが、動的な更新によってライブラリに追加されている。この結果、Ｍバンドには更新すべき５０未満のタイトルが存在するかもしれない。なぜなら、１以上のタイトルがＨバンドからＭバンドに排除されるかもしれないためである（図の矢印により示される）。一実施例では、Ｍバンドの各タイトルのヘッダがサービスを提供する他のボックスからフェッチされ、Ｍバンドのタイトルの５％のみに対する１つのセグメントがフェッチされる。他の実施例では、Ｍバンドタイトルのヘッダのみがフェッチされ、セグメントは以降にフェッチされる。Ｍバンドの中間状態は、Ｍバンドのタイトルに対して０、１及び２セグメントが存在する理由を説明するため、図３Ａにより良好に理解することが可能である。

（１＋Ｘ）日後（ただし、Ｘは、ＨバンドとＭバンドとを更新するのに要する時間を示す）（ライブラリ状態５１４を参照）、ネットワークスピードに応じて、Ｈバンドからある個数のタイトルがＭバンドに排除され、それと同時に、Ｍバンドの対応する個数のタイトルがＬバンドに排除されるかもしれない。ライブラリがその中のタイトルの古さに関して段階的に構成されている場合、ライブラリ状態５０２のもとの１００タイトルはシフトされたものであり、更新されるべきであったＬバンドの１７００タイトルが存在するが、上位バンド５０４からの排除は、実際に更新すべきタイトルの実際の個数を減少させたことは理解されるかもしれない。このとき、すべての見逃したタイトルのヘッダが受信されるまで、Ｌバンドのタイトルのヘッダが継続的にフェッチされる。最後に、Ｈ、Ｍ及びＬバンドのタイトルに対して、すべての見逃したセグメントもまたフェッチされる。ライブラリ状態５１６は、更新プロセスの完了後にライブラリの最終的な状態を示す。

図５Ｂは、３つのボックス５３２〜５３４がシステムに追加された状況５３０を示す。これら３つのボックス５３２〜５３４は各自の識別子及び／又はＩＰアドレス及びライブラリ状態と共にサーバ５３６に登録された後、サーバ５３６は、これらのボックスが以前に見逃したものと、見逃したタイトルをフェッチする場所などの更新方法に関する情報を返す。この状況５３０は、ボックス５３２がまずボックス群５３７〜５４０から見逃したタイトル（ヘッダ又はおそらく対応するセグメントなど）をフェッチし、ボックス５３３及び５３４がまずボックス５４３と５４４のグループから見逃したヘッダをそれぞれフェッチすることを示している。動作について、ボックス（すなわち、５３２）は対応するヘッダ及び／又はセグメントをフェッチするためボックス間を動的にスイッチするよう構成されることに留意される。

これら３つのボックス５３２〜５３４はまず上位バンド（すなわち、Ｈバンド）の各タイトルに対して１つのヘッダと１つのセグメントにより更新される。動作について、これら３つのボックス５３２〜５３４は他のボックスへのサービスの提供を開始する候補とすることが可能である（例えば、Ｈバンドのタイトルなどに対して）。図５Ｂにおいて、発注元のボックス５４２は、上位バンドのタイトルに対する注文を発注している。また、当該タイトルはヘッダと４つのセグメントとを有するファイルに係るものであり、４つのセグメントのうちの２つは発注元のボックス５４２にあることが仮定される。従って、発注元のボックス５４２は、その他の２つの欠落しているセグメントをフェッチする必要がある。当該タイトルのヘッダが再生されている間に、発注元のボックス５４２は、ボックス５３２〜５３４のそれぞれがこれら欠落しているセグメントの１つを有し、それらのすべてが２つの欠落しているセグメントの同じものを有しているとは限らない場合、ボックス５３２〜５３４の何れか２つから欠落しているセグメントを取得するようにしてもよい。ボックス群５３７〜５４０、５４３及び５４４はボックス５３２〜５３４を更新するのにビジー状態であるため、ボックス５３２〜５３４は、Ｈバンドのリリースのセグメントが利用可能になると即座に、他のものにサービスを提供することを開始する。このため、Ｈバンドのタイトルに対する最大の持続可能な同時性は変わらないままとされることが理解されるかもしれない。さらに、新たにリリースされたタイトルに対する再生サポートは、新規ボックスが新たなリリースの再生しかサポートできないため、新規ボックスに転送されるかもしれないことは理解されるであろう。これは、トラフィック問題を大きく抑制し、任意のバンドのタイトルに対して最大の持続可能な同時性を向上させる。

図５Ｃを参照すると、おそらく製造後に長期間店舗の棚に置かれていたため、ある期間オンライン状態でなかったライブラリを更新するためのフローチャート又はプロセス５５０を示す。プロセス５５０は、ハードウェア、ソフトウェア若しくはその両方の組み合わせによりメソッド、プロセス及び／又はシステムとして実現されるかもしれない。プロセス５５０は、５５２においてネットワーク接続される何れかの新規ボックスを待機する。プロセス５５０は、新規ボックスがネットワークにおいて検出され、又はサーバが新規ボックスの存在を通知されると開始される。一実施例では、新規ボックスは、電源オンされ、ネットワークに接続されると、サーバプロバイダに係るサーバに自動的に通知及び／又は登録するよう構成される。当該ボックスは、それの識別子とＩＰアドレスとを含む通知と、おそらくボックスが直近に更新された日時とを送信してもよい。

５５３において、プロセス５５０は、ボックスのライブラリがレコードに従って更新される必要があるか検出する。ボックスのライブラリが更新される必要のないケースがある。例えば、ボックスが短時間の間電源オフされていた場合、それは新たなコンテンツを見逃していないかもしれない。一実施例では、サーバは、ライブラリがボックスの状態に従って更新される必要があるか判断する。ライブラリを更新する必要がない場合、プロセス５５０は５５２に戻り、他の新規ボックスを待機する。ライブラリが更新される必要があると判断された場合、プロセスは５５４に移行する。

５５４において、ボックスがオフラインであったため、又はストレージのエラーのため、ライブラリ内の時間の経過したタイトル群と、過去に見逃したリリース群又はボックスから現在欠落しているリリース群とが、決定される必要がある。他のボックスの更新されたライブラリと同期するため、時間の経過したタイトルはもはやアクセス付加としてフラグ付けされる（当該データがボックスにおいて依然として利用可能であったとしても）。プロセス５５０は、その後に５５６においてライブラリの更新に移行する。上述されるように、ライブラリはまず、Ｈバンドのタイトルのヘッダによって更新され、これにより、ボックスはこれらのタイトルの注文を受け付け、これらのタイトルの他のボックスの注文をサポートするようになるかもしれない。動作について、ヘッダがローカルにキャッシュされると即座に、ボックスは、当該ヘッダに係るタイトルに対する発注を実現する状態にある。Ｈバンドタイトルに対して、ボックスは５５６において、他のボックスからのこれらのタイトルのそれぞれに対して、ヘッダ又はヘッダ及び対応するセグメントをフェッチするよう構成される。ヘッダ又はセグメントをフェッチするための一例となる機構の１つは、上述されるようなアプリケーションレイヤマルチキャストｇｏｓｓｉｐプロトコルによるものである。

システムは、各ボックスがＨバンドタイトルのヘッダと１つのセグメントのみを格納していることを要求するよう構成されるかもしれない。あるいは、システムは、各ボックスがＨバンドタイトルのヘッダと複数のセグメントを格納していることを要求するよう構成されるかもしれない。何れの場合も、ボックスは、注文の実現又はライブラリの更新のため、他のボックスに対してサービスを提供する準備ができている。さらに、新たなタイトルによって新規ボックスを更新するための責任は、より新規なボックスのみが新たなタイトルを更新することを支援することが可能であるため、新規ボックスに転換される可能性があることは理解されるであろう。

上位バンドのタイトルが更新されている間、プロセス５５０はサーバからのリリースがあるかチェックする。５５８においてリリースがある場合、当該リリースがライブラリに適しているかに応じて、ライブラリの適切なタイトルに影響を与える。一実施例では、ライブラリはいくつかの高、中及び低バンドに実質的に分割される。リリースのタイトルがＨバンドに備えられるべきであるとされる場合、Ｈバンドの相対的に人気の低いタイトルが次の下位のバンドに排除され、５５４において当初決定された実際のタイトル数を実質的に減少させる。リリースがない場合、又はリリースが最も要求されているタイトルを含んでいない場合、プロセス５５０はＨバンドのタイトルが更新されるまで５５６〜５６２を継続する。動作について、各バンドのタイトルが、人気及び／又は経過期間に関してあるバンドから下位のバンドに継続的及び段階的に排除される。便宜上、３つのバンド、すなわち、Ｈ、Ｍ及びＬバンドが使用されると仮定される。

プロセス５５０は、ＭバンドとＬバンドのすべてのタイトルのヘッダと、ＭバンドとＬバンドのタイトルの僅かなパーセンテージの対応するセグメントをさらにフェッチするため５６４に移行する。一実施例では、Ｍバンドのタイトルの５％がセグメントを有し、Ｌバンドのタイトルの５％がセグメントを有している。この結果、ライブラリの更新は、ボックスがサービスを提供することを注視することを回避する。何れの場合も、タイトルがＨバンドからＭバンドに排除される毎に、それの対応するセグメントが単にＭバンドに移される。他の何れのセグメントもシステム構成に従って破棄されるかもしれない。また、タイトルがＬバンドに移されると、当該タイトルのセグメントはＬバンドに保持されているかもしれず、又は当該タイトルが当該ボックスに対して指定されたタイトルのパーセンテージの範囲内に属するか否かに応じて破棄されるようにしてもよい。固定数のタイトルを制御し、ローカルストレージを維持する場合、Ｌバンドの対応するタイトル、典型的には最も人気のないタイトルが、破棄又は上書きされる。セグメントの破棄は、ボックスが格納スペースを使い果たし始めると実行され、より多くの利用可能な格納スペースが存在する場合には回避することが可能である。

５６６において、プロセス５５０は、ボックスがユーザ又は他のボックスにサービスを提供することに影響を与えることなく、Ｈバンド及び／又はＭバンドのタイトルのセグメントをフェッチすることを継続する。Ｈバンドのタイトルに２つのセグメントが存在するケースがあることが説明される。５５６において、ボックスがユーザ又は他のボックスにサービス提供できる準備ができるための時間を最小化するため、セグメントの１つのみがフェッチされたことが思い起こされる。これにより、５６６において他のセグメントがフェッチされるかもしれない。同様に、Ｍバンドのすべてのタイトルが少なくとも１つのセグメントを有すると仮定されるが、そこでのタイトルの５％しかセグメントを有していない。このため、対応する各セグメントは、ボックスがユーザ又は他のボックスにサービスを提供することを禁止することなく、他のボックスからフェッチされてもよい。

図５Ｃには直接的には示されていないが、５５９と同様の処理がそれぞれ５６４と５６６に本来的に含まれている。さらに、プロセス５５０の一部は、好ましくはネットワークのトラフィックが低いとき、１日の任意の時点で実行することが可能である。ライブラリを更新するのに必要なデータを供給するボックスを選択する際、これらのボックスは、ネットワークの状態、地理的局所性、供給元と受信者との間で実現される持続可能な帯域幅などと共に、ボックス自体の状態を利用するため、時間と共に決定又はスイッチされるかもしれない。

また、ケーブル若しくは衛星ネットワークを介し、又はＩＰマルチキャストを介し利用可能なものなど、高帯域幅ブロードキャスト若しくはマルチキャストチャネルの利用性が、新たな映画の提供に関して上述されたように、ボックスを更新するプロセスを迅速化するのに利用可能であることが理解されるかもしれない。ブロードキャストチャネルは、おそらく最も要求の高いタイトルを優先させて、最新のリリースの伝送に利用されてもよい。その後、新規ボックスは、それらが見逃したヘッダとセグメントを迅速に受信するため、適切なチャネルにチューニングするようにしてもよい。

図６Ａを参照すると、サーバ６００の一例となる実現形態が示される。サーバ６００は、図１Ａのサーバ１０２に対応するかもしれないが、単一の計算装置又はコンピュータクラスタであるかもしれない。サーバ６００は、サーバモジュール６０２とインタフェース６０４とを有する。一般に、サーバモジュール６０２は、メモリにロードされ、それの処理を実行するため１以上のプロセッサ（図示せず）により実行される。アプリケーションでは、サーバ６００は、メディアサービスをユーザに提供するため、サービスプロバイダ又は企業によって運用されているかもしれない。

サーバ６００はまた、コンテンツ若しくはソースプロバイダ６０８とサーバ６００との間の通信を実現する配信エージェント６０６を有する。実現形態に応じて、ソースプロバイダ６０８は、以下に限定されるものではないが、コンテンツ受信機、コンテンツ作成者及び映画配給者を含むかもしれない。配信エージェント６０６は、コンテンツがソースプロバイダ６０８から適切に受信されることを保証するため設けられる。コンテンツの受信方法に応じて、配信エージェント６０６は、各種形式により実現されるかもしれない。例えば、映画配給者は、サーバ６００を運用するサービスプロバイダに映画をリリースする。映画はサーバ６００にセキュアに転送され、この場合、配信エージェント６０６はセキュア伝送媒体となる。他の例では、コンテンツは衛星によって転送され、この場合、配信エージェント６０６は衛星受信機であるかもしれない。企業がそれの製品やサービスを複数のユーザにサーバ６００を介し宣伝することを所望するさらなる他の例では、当該企業はインターネットを介しサーバ６００にコマーシャルビデオを配信するかもしれない。従って、配信エージェント６０６は、インターネット若しくはローカルネットワークの一部であり、サーバ６００とインターネットとの間のデータ通信を実現するため、必要なインタフェース（ＴＣＰ／ＩＰなど）を提供する。

効率化のため、サーバ６００は、各種フォーマットによるソースファイルをクライアントボックスにより理解される受付可能なフォーマットに変換するため設けられるトランスデューサ６０９を有するか、又は接続されるようにしてもよい。典型的には、コンテンツプロバイダによって提供されるビデオソースは、高品位映像信号、ＤＶＤ、フィルムなどである可能性がある。当該フォーマットがサーバ６００に所望されるフォーマットでない場合、トランスデューサ６０９は、このようなソースを受付可能なフォーマット（ＭＰＥＧ−２、ＭＰＥＧ−４など）に変換するよう起動される。上述されるように、ソースプロバイダ６０８は、多数のタイプのソースを提供可能である。トランスデューサ６０９又は類似する機能を有する適切な装置によって、サーバ６００は、任意のタイプのソースを受信し、それらをユーザに費用又は情報のため配信することが可能である。

サーバ６００は、データネットワークを介しサービスを提供する複数のボックスとサーバ６００との間のデータ通信を実現する他のインタフェース６０４を有し、そこでは、サーバ６００は、これらのボックスに関してリモートに配置されてもよい。ネットワーク６１１は、インターネット、ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）、プライベートネットワーク、又は無線ネットワークを含む大規模ネットワークの一部とすることが可能である。ネットワーク６１１は、電話線、ケーブル、ファイバ又は大気（無線）などの１以上の伝蔵媒体を利用するかもしれない。サーバ６００とボックスとの間の通信に使用される一例となる通信プロトコルはＴＣＰ／ＩＰである。

図６Ａに示されるように、サーバモジュール６０２は、互いに協調的に動作するよう構成される複数の機能エンジン又はモジュールを有する。図６Ａのサーバモジュール６０２にリストされるすべてのモジュールが、実際に使用される必要があるとは限らない。実際の実現形態又は要求に応じて、これらのモジュールは選択的に配備されるようにしてもよい。

ユーザ管理モジュール６１０は、加入者又はユーザを管理するよう構成される。それは、サービスプロバイダからメディアサービスを受信する契約をしている又は所望しているすべてのユーザに係るアカウントの追加、削除又は更新を実現する。ユーザ管理モジュール６１０はまた、すべてのアカウントに対する支払の決済を管理する。一実施例では、各アカウントは、メディアサービスへの無制限なアクセスを許可する固定の月単位の料金が課金される。他の実施例では、各アカウントは、サービスプロバイダによって提供されるライブラリのタイトルに対する注文が発注される毎に、更新又は課金される。

コンテンツ管理モジュール６１２は、ユーザに提供可能なすべてのコンテンツを管理する。上述されるように、これらのコンテンツは、ヘッダとセグメントの形式により構成される。これらのオブジェクトは、サービスを提供するボックス間に分散される。コンテンツ管理モジュール６１２は、これらのオブジェクトの分散を管理するよう構成される。コンテンツ管理モジュール６１２にアクセスすることによって、オペレータは、ライブラリのタイトルに関するオブジェクトの分散方法を直接的に制御し、利用可能なものと、これらのオブジェクトの分散方法及び場所に関するマッピング情報を取得するようにしてもよい。図６Ｂは、５０００タイトルのライブラリがＮ個のボックスにどのように分散されているか示す一例となるマップ６３０を示す。カラム６３２は、サービスを提供するすべてのボックスをリストしている。各ボックスには、識別用の一意的な識別子が割り当てられている。カラム６３２の情報は、サービスを提供するボックスの識別子としてみなされるかもしれない。例えば、ボックス１には、“ボックス１”の一意的な識別子又は英数字のシーケンスが割り当てられる。

カラム６３４は、カラム６３２にリストされる各ボックスの対応するＩＰアドレスをリストしている。カラム６３６は、ライブラリのすべてのタイトルのヘッダをリストしている。カラム６３８は、タイトル１が２つのセグメントを各ボックスにキャッシュされることが要求されていると仮定すると、タイトル１の何れのセグメントが欠くボックスに常駐しているかリストしている。カラム６４０は、タイトル２が１つのセグメントを各ボックスにキャッシュされることを要求されていると仮定すると、タイトル２の何れのセグメントが欠くボックスに常駐しているかリストする。カラム６４２は、タイトル５０００が選択されたボックスに１つのセグメントを有することが要求されていると仮定すると、タイトル５０００の何れのセグメントが選択されたボックス群にあるかリストしている。この結果、ボックスのすべてのオブジェクト（すなわち、ヘッダ又はセグメント）が、発注されたタイトルのローカルな再生又は他のボックスへのアップロードのため一意的にアドレス指定されるかもしれない。

配信管理モジュール６１４は、発注元のボックスから受信した注文に応答するよう構成される。コンテンツ管理モジュールと共に動作して、配信管理モジュール６１４は、この注文に応答して、ソース情報、認証情報及びセキュリティ情報を含むレスポンスを生成する。ソース情報の一例が、図６Ｃのテーブル６５０又は図６Ｄのテーブル６５２のテーブルとして図示される。テーブル６５０は、注文されたタイトルのセグメントを供給するよう指定された４つのボックスのそれぞれのＩＰアドレス（ＩＰＡ１など）を含む。認証情報は、他のボックスとのセキュア通信のため発注元のボックスを認証する。セキュリティ情報は、タイトルの再生のためのデータの解読を実現する。レスポンスはさらに、他のボックスから抽出されるべきセグメントに関する命令と、発注元のボックスを特定するＩＰアドレスとを有するようにしてもよい。レスポンスを受信すると、発注元のボックスは、選択されたタイトル（Ｌバンドにあると仮定される）に対応するヘッダが再生されることを可能にし、それと同時に若しくはその後まもなくして、発注元のボックスは、サーバから受信したレスポンスに従って４つの各リクエストを発行する。各リクエストがこれら４つのボックスの１つのＩＰアドレスを有していることは理解される。各ボックスがリクエストの１つを受信すると、要求されたセグメントが発注元のボックスにリリース又はアップロードされる。

ネットワーク管理モジュール６１６は、サービスを提供する各ボックスの状態をモニタするため設けられる。１つのアプリケーションでは、ネットワーク管理モジュール６１６は、ボックスのアドレスを受信するよう構成される。多くのケースにおいて、ボックスには経時的に変動する可能性のある動的アドレスがインターネットサービスプロバイダによって割り当てられている。サービスを提供するすべての各ボックスがサーバ６００に接続されることを保証するため、ボックスのＩＰアドレスが何れかの理由により変更されるときは常に、それの新たなＩＰアドレスは時間内にサーバに通知される必要がある。一実施例では、各ボックスは、ネットワーク管理モジュール６１６が必要に応じてそれのＩＰアドレスを変更したボックスのＩＰアドレスを更新するように、サーバとの間でイベントトリガーに若しくは定期的にショートメッセージを送受信するよう構成される。他方、ネットワーク管理モジュール６１６は、ショートレスポンスのため各ボックスにショートメッセージを送信するよう構成される。ボックスが動作していない場合（電源オフ又は不具合など）、ネットワーク管理モジュール６１６は、即座に通知され、発注元のボックスに対してセグメントを提供するための指定から当該ボックスを排除する配信管理モジュール６１４を更新する。同様に、ボックスが映画の注文に対してセグメントをすでに供給している場合、ネットワーク管理モジュールは、配信管理モジュールに他の注文に対するセグメントを供給するためボックスの利用可能性状態が通知され続けるようにしてもよい。

提供管理モジュール６１８は、ライブラリ管理モジュールとも呼ばれるかもしれない。提供管理モジュール６１８は、各ボックスのライブラリを更新するためのものである。リリースがあるときは常に、提供管理モジュール６１８は、ボックスへのリリースの適切な提供を保証する。リリースが新たにリリースされた映画であり、おそらく需要が高い状況では、提供管理モジュール６１８は、当該リリースに係るファイルのヘッダと少なくとも１つのセグメントを各ボックスに常駐させる。リリースが新たにリリースされた映画ではないが、需要が高いような他の状況では、提供管理モジュール６１８は、当該リリースに係るファイルのヘッダとおそらく１つのセグメントを各ボックスに常駐させる。リリースが古典的なタイトルであり、相対的に需要が低いさらなる他の状況では、提供管理モジュール６１８は、ヘッダを各ボックスに常駐させ、セグメントをネットワークの選択されたボックス群に常駐させる。新規ボックスがネットワークに接続されたさらなる他の状況では、ネットワークモニタリング管理６１６が、ボックスの状態を提供管理モジュール６１８に通知するよう構成される。ボックスの既存のライブラリの状態に応じて、提供管理モジュール６１８は、何れがライブラリにおいて欠落しているか判断し、他のボックスからライブラリを更新する方法についての命令をボックスに提供する。

セキュリティ管理モジュール６２０は、サービスを提供するボックスに分散されるオブジェクトをセキュア化するため設けられる。一実施例では、セキュリティ管理モジュール６２０は、発注元のボックスに係るユーザを認証し、ユーザの認証後及び／又は注文に対する支払の決済後、発注元のボックスに１以上のセキュリティキーと認証情報を提供するよう構成される。セキュリティキーは、発注元のボックスにおいてヘッダ及び／又はセグメントの解読を実現するかもしれない。認証情報は、発注元のボックスがタイトルの再生のため必要とされるセグメントをフェッチするため、発注元のボックスが指定されたボックスと通信することを可能にする。他の実施例では、セキュリティ管理モジュール６２０は、サービスを提供するボックスに分散される前に、すべてのオブジェクト（ヘッダ及び／又はセグメント）を暗号化するため、コンテンツ管理モジュール６１２又は提供管理モジュール６１８と共に動作する。さらなる他の実施例では、セキュリティ管理モジュール６２０は、サービスを提供するすべてのボックスにオブジェクトとして分散されるすべてのコンテンツのデジタル著作権管理（ＤＲＭ）を提供する。さらなる他の実施例では、セキュリティ管理モジュール６２０は、それがセグメントに分割され、ボックスに分散される前に、タイトルのファイルから小さな部分を取り除くようにしてもよい。ボックスがタイトルを発注すると、ファイルのこれらの部分が、おそらくサーバレスポンスの一部として、サーバにより直接的に供給され、これにより、タイトルがサーバのアクティブな参加などに完全に構成することができないことを保証することによってセキュリティを向上させる。

コマーシャル情報管理モジュール６２２は、必要に応じてユーザに表示することが意図されるコマーシャル情報を管理するため設けられる。このような情報の具体例として、以下に限定されるものではないが、宣伝、特別提供、映画予告編及び公共放送などがあげられる。このような情報は、映画を表示する画面の一部に重ねられ、２つの映画の間のインターバルの間に若しくは映画の表示開始に表示され、又は単にユーザにより要求されるかもしれない。情報に応じて、このような情報は、ボックスの地理的位置、視聴行動又はユーザの所望する言語を含む１以上のファクタに従って、独立にリリースされるか若しくはリリースに係るヘッダに添付されてもよい。

ソースプロバイダ管理モジュール６２４は、プロバイダからの配信されたコンテンツを利用するため、ユーザにより支払われた料金の配布を管理するため設けられる。実現形態に応じて、ソースプロバイダ管理モジュール６２４は、配信エージェント６０６を介し毎日、毎週又は毎月、各コンテンツプロバイダと支払を共有し、又は提供されるライブラリのタイトルの財務予想又は統計を提供するよう構成されるかもしれない。

図６Ａの配信管理モジュール６１４をさらに参照して、一実施例によると、配信管理モジュール６１４は、指定されたボックスの１以上が突然利用不可となり、又は発注元のボックスへの要求されたセグメントの供給を継続することがスローダウンする状況を回避するよう構成される。発注元のボックスに応答したソース情報は、指定されたボックスのそれぞれに対するバックアップ情報を含む。図６Ｄは、指定された各ボックスのバックアップ識別子（ＩＰアドレスとして示される）を含むテーブルのバックアップボックスによる一例となるソース情報を示す。ボックスの１つが発注元のボックスからのセグメントに対するリクエストに応答しない場合、又はセグメントが正確に受信できない場合、バックアップＩＰアドレスが、当初指定されたボックスが提供できないセグメントを提供するため利用可能な、又は提供し続けるのに利用可能な対応するバックアップボックスにスイッチするため即座に呼び出される。

完全にするため、図６Ｅは、発注元のボックス６５４がボックス６５４において発注されたタイトルに係る３つの各セグメントを受信するため指定された３つのボックス６５５〜６５７によりサポートされている一実施例を示す。各ボックス６５５〜６５７には、対応する同一のセグメントを有するバックアップボックスが設けられる。具体的には、ボックス６５５はバックアップボックス６５８によりサポートされ、ボックス６５６はバックアップボックス６５９によりサポートされ、ボックス６５７がバックアップボックス６６０によりサポートされる。注文されたタイトルのヘッダが発注元のボックスにおいて再生されている間、これら３つの分散されたオブジェクトは、ボックス６５５〜６５７からフェッチされる。ある理由のため、ボックス６５６がセグメントの提供を継続することを拒絶した場合、バックアップボックス６５９は、セグメントの提供を継続するようボックス６５６を置換するため起動される。一実施例では、バックアップボックス６５９は、ボックス６５４にセグメントを共同して供給するためボックス６５６に加わるよう構成される（例えば、それぞれは、同一のセグメントの異なる部分を供給するなど）。

図６Ｆは、発注元のボックス６７０がボックス６７０の発注されたタイトルに係る３つの各セグメントを受信するため、指定された３つのボックス６７１〜６７３によりサポートされている他の実施例を示す。動作について、何れかの理由による発注元のボックスの故障はまれであり、全く同時に複数のボックスが故障することはさらにまれである。従って、指定された３つのボックス６７１〜６７３に対する３つのバックアップボックス６７４〜６７６は、セグメントを供給する他の指定されたボックスに対するバックアップボックスとして構成されるかもしれない。図６Ｆは、発注元のボックス６７８が３つの指定されたボックス６８２〜６８４により供給を受けながら、２つの指定されたボックス６７９及び６８０により供給を受けている発注元のボックス６７７を示す。各フェッチプロセスが良好に実行されることを保証するため、指定された各ボックスはバックアップボックスによりサポートされ、この場合、指定された２つのボックス６７９と６８０がボックス６７４と６７５によりバックアップされ、指定された３つのボックス６８２〜６８４がボックス６７４〜６７６によりバックアップされる。バックアップボックス６７４〜６７６の１つがアクティブボックスとなると、サーバ６００は、フィールドの他のボックスをバックアップボックスとして即座に指定するようにしてもよい。

図６Ｇを参照すると、ライブラリのあるセレクション（すなわち、タイトル）の瞬時の再生を開始するためのフローチャート又はプロセス６８６が示される。プロセス６８６は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び／又はシステムとして実現されてもよい。好ましくは、プロセス６８６は、ユーザに係るボックスからの選択されたタイトルの瞬時の再生を実現するサーバとして指定された計算装置において実行される。一実施例では、プロセス６８６は、メディア・オン・デマンドシステムにおいて利用される。６８８において、プロセス６８６は、ユーザに係る発注元のボックスからのリクエストを待機している。典型的には、ユーザはタイトルを選択し、その後に注文を発注する。さらに後述されるように、発注元のボックスはサーバに転送されるリクエストを生成する。プロセス６８６は、注文を含むこのようなリクエストが発注元のボックスから受信されると起動される。一般に、リクエストは、発注元のボックスの識別子及びＩＰアドレス、ユーザアカウント情報（ユーザ名など）、並びに注文情報を含む。発注元のボックスにおいて何かが行われる前に、プロセス６８６は、ユーザの認証に移行する。ユーザが登録されていない場合、プロセス６８６は６９１に移行し、エラーメッセージを含むレスポンスが生成され、発注元のボックスに返される。実現形態に応じて、エラーメッセージは、エラーメッセージを表示するため、又はユーザをシステムに登録するよう求めるため、発注元のボックスのローカルモジュールを起動するかもしれない。

ユーザが認証された後、プロセス６８６は６９２に移行し、当該注文に対する支払が決済されているか判断する。一実施例では、登録プロセスにおいて、ユーザは、システムを用いてユーザが発注した注文に関する課金のためのクレジットカード情報を提供するようにしてもよい。他の実施例では、ユーザは、各課金に対する包括的な決済のための月毎の請求書を受信するようにしてもよい。支払が決済されていない場合（例えば、ユーザが自らの口座に大きな未払いがある）、プロセス６８６は６９３に移行し、エラーメッセージを含むレスポンスが生成され、発注元のボックスに返される。エラーメッセージは、支払のためユーザにローカルに表示されてもよい。

支払決済後、プロセス６８６は６９４に移行し、発注元のボックスにセグメントを供給するのに指定されるいくつかのボックスを決定する。ボックスの正確な個数は、選択されたタイトルの再生を継続するため発注元のボックスが必要とするセグメント数に依存する。６９６において、受信したリクエストに従ってレスポンスが生成される。一般に、レスポンスは、ソース情報、認証情報及びセキュリティ情報を含む。ソース情報は、発注元のボックスが選択されたタイトルの再生を継続するため必要とされるセグメントをどのようにかつどこで取得できるか指示する。認証情報は、発注元のボックスが必要とされるセグメントを供給するため指定されたボックスとの各自のセキュア化された通信を行うことを可能にする。セキュリティ情報は、発注されたタイトルの再生のためのデータの解読を実現する。他のボックスから必要とされるセグメントを供給するための１以上のボックスを決定する際、１以上のファクタが実現形態に応じて考慮されてもよい。これらのファクタは、以下に限定されるものではないが、各自の利用可能な帯域幅、地理的位置、供給元のボックスの利用可能性の履歴、及び各ボックスのインターネットサービスプロバイダを含む。さらに、発注されたタイトルが人気があるか否か、供給元のボックスが新規であるか否か、及び供給元のボックスがビジー状態であるか否かが考慮されてもよい。何れの場合も、レスポンスは、発注元のボックスに戻されるか、又は発注元のボックスに必要とされるセグメントを受信しながら再生を開始させる。その後、プロセス６８６は、他のリクエストを待機するため６８８に戻る。

プロセス６８６は、一実施例では、サーバが発注プロセスのみを取り扱い、実質的に同時に異なるタイトルに対する多数のリクエストを容易に管理することが可能となることを示す。本発明のいくつかの実施例の可能な特徴及び効果の１つは、まとめて利用されていない帯域幅と計算パワーを利用するため、ユーザにデータ供給負担をシフトすることである。

図７Ａを参照すると、図２Ａのボックス（２０７−１、２０７−２及び２０７−ｎなど）の何れか１つに対応するボックス７００の一例となる実現形態が示される。ボックス７００は、ローカルモジュール７０２、インタフェース７０４及び格納スペース７０６を有する。ローカルモジュール７０２は、メモリ７０８にロードされ、それの処理を実行するためプロセッサ７１０により実行される。動作について、ボックス７００は、サービスプロバイダ若しくはメディアサービスをユーザに提供する企業によって加入者若しくはユーザに提供されるかもしれない。ネットワーク７１２を介して、ボックス７００はサーバ（図６Ａのサーバ６００など）によって提供されるメディアサービスを受信することが可能である。上述されるように、ボックス７００の具体例として、以下に限定されるものではないが、デスクトップコンピュータ、ラップトップ若しくはノートブックコンピュータ、セットトップボックス、電話、タブレットＰＣ若しくはＰＤＡなどの携帯装置などがあげられる。ネットワーク７１２は、好ましくは、ｘＤＳＬ、ＡＴＭ、ＳＯＮＥＴ、光ファイバ線、プライベート／パブリック電話網、無線接続、又はＣＡＴ−５の１以上を利用するブロードバンドローカルループである。ボックス７００は、回線交換若しくはパケット交換接続によりネットワーク７１２に接続される。

図７Ａに示されるように、互いに協調して動作するよう構成される複数のモジュールが存在する。図７Ａのローカルモジュール７０２にリストされるすべてのモジュールが必ずしも利用される必要があるとは限らないことは、当業者に理解されるであろう。実際の実現形態若しくは要求に応じて、モジュールは選択的に配置されてもよい。

状態通知モジュール７１４は、ボックス７００に影響を与える各種状態をモニタするため設けられる。１つの状況では、ボックス７００のＩＰアドレスが変更されるときは常に、状態通知モジュール７１４はこの新たなＩＰアドレスをサーバに即座に通知する。他の状況では、状態通知モジュール７１４は、ボックスのライブラリがタイムリーに適切に更新可能となるように、ボックスがネットワークからどのくらいの期間切断されていたか検出するよう構成される。さらなる他の状況では、状態通知モジュール７１４は、利用可能なアップロード帯域幅を検出する。アップロード帯域幅がある数値未満である場合、状態通知モジュール７１４は、ボックスがセグメントを他のボックスに供給するよう指定されないように、タイムリーにサーバに通知する。さらなる他の状況では、状態通知モジュール７１４は、供給元のボックスからフェッチされたセグメントがもはや所望されるスピードでないか検出し、当該供給元のボックスとの通信セッションを終了させ、他の供給元のボックスとの通信セッションを起動する。状態通知モジュール７１４により実行される他の機能は、ここでの詳細な説明により理解されるであろう。

ライブラリ管理モジュール７１６は、格納スペース７０６の多数のタイトルのヘッダ及びセグメントを管理するため設けられる。ライブラリ管理モジュール７１６を介して、サーバは、ボックスが何れのオブジェクトを有しているか知る。ライブラリ管理モジュール７１６はまた、発注されたタイトルを参照して何れの分散オブジェクト（すなわち、欠落したセグメント）がフェッチされるべきか指示する。当該ボックスが新たなタイトルと変更したタイトルのヘッダとセグメントをフェッチ及び受信すると、ライブラリ管理モジュール７１６がこれらを管理する。ライブラリ管理モジュール７１６はサーバに発注元のボックスへの供給のための利用可能なセグメントを最新のものに維持させるため、サーバと通信するようにしてもよいことが理解されるであろう。このような通信は、各イベントの後（新たなセグメントの受信など）、所定のインターバルなどにより行われるようにしてもよい。

メタデータモジュール７１８は、ボックス７００とそれのユーザとの間の各種のやりとりを実現するため設けられる。メタデータモジュール７１８は、ユーザがボックス７００のライブラリに関するメタデータをブラウズすることを可能にするための各種グラフィックインタフェースを提供するよう実現されてもよい。このメタデータは、以下に限定されるものではないが、ライブラリのタイトルに関する俳優、監督、批評家、推薦広告、評価などに関する関連する情報を含むものであってもよい。一実施例では、メタデータモジュール７１８は、ユーザからエントリを受け付け、エントリに従って所望の情報を表示する。一例となるアプリケーションでは、ユーザは、１以上のキャラクタを入力する。メタデータモジュール７１８は、メタデータを検索し、入力されたキャラクタに従ってタイトルのリストを提供する。より多くのキャラクタが入力されると、タイトルの選択がより容易になされるように、リストは段階的に狭められる。他の一例となるアプリケーションでは、メタデータモジュール７１８は、ユーザがタイトルのタイプ（アクション、ロマンスなど）を指定することを可能にし、当該タイプに関するタイトルのリストが、タイトルの選択が可能となるように表示される。

セキュリティモジュール７２０は、サーバだけでなく他のボックスとのセキュア通信を実現するため設けられる。一実施例では、指定されたボックスの１つがセグメントを供給するため発注元のボックスからのリクエストを受け付けるとすぐに、発注元のボックスと供給元のボックスとの間のセキュアなセッションが確立される。このため、それらの間で伝送されるすべてのデータはセキュア化される。セキュリティモジュール７２０はまた、発注されたタイトルの再生のためのデータのＤＲＭ及びセキュリティを取り扱うため設けられる。

学習エンジン７２２は、ユーザの視聴行動及び／又はユーザに係るボックスのネットワーク動作から、ユーザに最良のサービスを提供するため設けられる。ユーザがブラウズ、選択又は発注したものから、推薦されるタイトルのリストがユーザに対して自動的に生成されるかもしれない。また視聴行動から、学習エンジン７２２は、何れのセグメントがローカルにキャッシュされるか決定するようボックスを構成することが可能である。ボックスがある期間オフライである状況では、ボックスがオンラインに戻ると、学習エンジン７２２はフェッチ対象となるタイトルを優先順位付けすることによって、ライブラリを更新するようボックスを構成することができる。ボックスのネットワーク動作を取得することによって、学習エンジン７２２は、何れの帯域幅が１日の異なる時間において利用可能であるか知っており、他のボックスにセグメントを供給するボックスの指定又はサーバからのリリースのボックスの提供を実現するかもしれない。

登録モジュール７２４は、新たなユーザがシステムに登録することを可能にする。典型的には、ユーザが良好に登録された後、登録モジュール７２４は、集中管理のため登録情報をサーバに転送するよう構成される。動作について、登録モジュール７２４は、ユーザ名やパスワードなどを要求するシステムを保護するためのフロントラインとして機能する。ユーザは、注文が受付可能となる前に、登録モジュール７２４により認証される必要がある。

図７Ｂ及び７Ｃを参照すると、２つの図面は一緒になって、あるセレクション（すなわち、タイトル）の瞬時の再生を開始するためのフローチャート又はプロセス７３０を示す。当該プロセス７３０は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び／又はシステムとして実現されるかもしれない。好ましくは、プロセス７３０は、ここで使用されるようなボックスに対応する計算装置において実行される。図６Ｇのプロセス６８６と共に動作することによって、プロセス７３０は、再生時にはファイルが完全には利用可能でないボックスからの選択されたタイトルに係るファイルの瞬時の再生を可能にする。

７３２において、プロセス７３０は、ユーザからの選択を待機する。１つのケースでは、ユーザはキー（リモコン、キーボードなどにより）を起動してタイトルの１つを選択可能な複数のタイトルを有するディスプレイを視聴している。プロセス７３０は、ユーザにより選択がなされると起動する。プロセス７３０は７３４に移行し、ユーザ及び／又はボックスが適切に認証されているか判断する。一実施例では、登録されたユーザは、認証のためユーザ名とパスワードを入力するよう要求される。他の実施例では、登録されたユーザは、認証のためコードを入力することを要求される。ユーザを認証する方法は他にもあるかもしれない。何れの場合も、プロセス７３０は、ユーザ及びボックスが正当なものであることを保証する必要がある。そうでない場合、７３６において、ユーザがシステムに登録することを推奨するエラーメッセージがユーザに送信される。

登録されたユーザが７３４において認証された後、７３８において、ボックスはその選択に従ってリクエストを送信する。当該リクエストは、注文及びユーザに関する情報を含む。リクエストは、サービスプロバイダによってサーバに転送される。リクエストを受信すると、サーバは図６Ｇのプロセス６８６に移行する。他方、７４０において、ボックスはサーバからのレスポンスを待機する。レスポンスが所定の時間内（５秒など）に受信されない場合、リクエストが再送信されてもよい。しかしながら、レスポンスがある時間を超えても受信されなかった場合（ネットワークがダウンしているなど）、７３９において、エラーメッセージが表示される。

７４２において、レスポンスがサーバから受信される。適切な理由のため、レスポンスはユーザがシステムを利用することを制限するかもしれない。ユーザが制限される場合、プロセス７３０は７４３に移行し、ユーザにエラーメッセージを表示する。認証されると、プロセス７３０は７４４に移行し、選択されたタイトルに係るファイルのヘッダが再生され、表示装置を介し表示されるかもしれない。

７４６において、サーバからのレスポンスに従って、ボックスは欠落しているセグメントに対する各リクエストを他のボックスに行う。上述されるように、当該レスポンスは、ボックスがこれらの欠落しているセグメントをどこからフェッチすることが可能であるか示すソース情報を含む。例えば、あるファイルに対して４つのセグメントが存在し、ボックスはそのうちの２つしかローカルに格納していない場合、２つのセグメントが他のボックスからフェッチされる必要がある。７４８において、ボックスは、欠落しているセグメントを供給するため要求されるボックスからのレスポンスを待機する。ボックスの１つが当該リクエストに応答することができない場合、バックアップボックスが当該セグメントを供給するため呼び出されるかもしれない。バックアップボックスがまた当該リクエストに応答することができない場合、ボックスは、さらなるバックアップボックスに対するリクエストをサーバに送信する。何れの場合も、指定されたボックスが発注元のボックスからのリクエストに応答した後、７５０において、発注元のボックスは指定されたボックスと応答したボックスから欠落しているセグメントのフェッチを開始する。

上述されるように、欠落しているセグメントは、所定のスピードで到着することが期待される。ある理由により、ネットワークの一部が混雑し、又はボックス自体が不具合であり、フェッチされるセグメントの大きな遅延が生じる場合、プロセス７３０は７５４に移行し、バックアップボックスが中断されたセグメントの供給を継続するよう呼び出される。図７Ｅにおいて、７５２及び７５４の詳細がさらに説明される。

所定の最小スピードによりすべてのセグメントがストリーミングされる場合、７５６において、ローカルに格納されているセグメントの一部及びストリーミングされるセグメントの一部が、図７Ｄに示されるようなバッファに多重化される。バッファ７７０、好ましくは、図７Ａのメモリ７０８の一部が、ヘッダ７７２のデータと共にロードされる。図７Ｄに示されるようにヘッダ７７２の一部７７４がバッファ７７０ｋぁら再生された。ヘッダ７７２の残りの部分７７６はまだ生成される。それと同時、セグメント７７８及び７８０のストリーミングがバッファ７７０に供給されている。セグメント７７８〜７８１（ローカルに格納されているセグメントとストリーミングされるセグメントとを含む）が、バッファ７７０に多重化される。より詳細には、セグメント１からのデータブロック、セグメント２からのデータブロック、セグメント３からのデータブロック及びセグメント４からのデータブロックが、多重化され、バッファ７７０に連続的に供給される。この結果、データのもとの順序が復元され、当該タイトルに係るファイルの残りの部分が再構成される。

図７Ｃを参照すると、プロセス７３０は７５８に移行し、発注されたタイトルに対するファイル全体が再生されるまで、バッファの再構成されたデータの再生を継続する。その後、プロセス７３０は７３２に戻り、ユーザからの他の注文を待機する。

図７Ｄを参照すると、２つのポインタ７８２と７８４が示される。各ポインタ７８２と７８４は、セグメントのデータブロックがバッファ７７０に供給されており、又は供給されようとしている場所を記憶するのに利用される。ボックスからフェッチされるセグメントが中断され、バックアップボックスが介入する場合、発注元のボックスは、ポインタに従ってそれが中断された場所からセグメントのフェッチを開始すべき正確な場所を知ることができる。同様に、類似したポインタ（図示せず）が、ローカルにキャッシュされたセグメントのデータブロックがバッファ７７０に供給されている、又は供給されようとする場所を記憶するため設けられてもよい。発注元のボックスがリセットされる必要がある場合、又は突然に電源オフされ、バックオンされる場合、これらのポインタは注文されたタイトルの再生の連続性を実現することを可能にする。

ボックスが、ライブラリのすべてのタイトルからの所望のタイトルの検索の実現、ユーザからの注文の実現、１以上のセグメントの他のボックスへの供給、リリースに応答したライブラリの更新、及びそれの状態若しくはネットワーク状態のサーバへの通知などのいくつかのタスクを実行可能であることが説明された。すべてのタスクは等しく重要であるが、一部は他のものより優先されてもよい。

図７Ｅを参照すると、一実施例によるボックスにおけるタスクの優先順位付けを行うフローチャート又はプロセス７８４が示される。当該プロセス７８４はシステムをより効率的にするかもしれないことに留意すべきである。インストール持には、ボックスはセグメントを他のボックスに供給又はアップロードすることを要求されない。ボックスは、７８６において、それの状態をサーバ（図２Ａの２０２など）に定期的に若しくは所定の時間に通知し、それのライブラリへのリリースの更新のため相手のボックスと同期し、又はボックスの全体的なパフォーマンスに影響を与える可能性のある他の処理を実行するよう構成される。サーバへの通知時、ボックスはそれの動作状態を示す状態を送出する。一実施例では、ボックスは公衆ネットワークに接続され、動的なＩＰアドレスが割り当てられる。ボックスがサーバと他のボックスと通信中であることを保証するため、ボックスは、ＩＰアドレスの変更をサーバに通知するよう構成される。

ボックスは、待機モードに入るか、又は７８６において他の処理を実行する。ボックスが７８８において１以上のセグメントを発注元のボックスに供給するための候補である可能性がるため、プロセス７８４は、ボックスが何れかのセグメントを他のボックスに供給するよう要求されたかチェックする。このようなリクエストが受信されていない場合、ボックスは７８６に戻り、それが実行していたものを実行し続ける。しかしながら、７８８において発注元のボックスからリクエストを受信すると、プロセス７８４は７９０に移行し、ボックスに常駐する多数のセグメントから要求されたセグメントを特定する。７９２において、ボックスは、アップロード帯域幅が十分なものであるかチェックする。リクエスト時に利用可能なアップロード帯域幅はＷであり、セグメントをアップロードするのに要求される帯域幅はＲであると仮定される。Ｗ＞Ｒである場合、プロセス７８４は７９６に移行し、それは存在する場合には、アップロード帯域幅を使用している処理に関係しないことを意味する。Ｗ＜Ｒである場合、プロセス７８４は７９４に移行し、存在する場合には、アップロード帯域幅を利用している他の何れかの処理が即座に中止される。アップロード帯域幅を利用する処理の具体例として、相手のボックスによって要求されたリリースパッケージのアップロード又は新規ボックスの提供などがあげられる。

このような処理が中断された後、プロセス７８４は７９６に移行し、要求されたセグメントを発注元のボックスにアップロードする。７９８において、要求されたセグメントのアップロードが終了したか判断される。終了していない場合、アップロードが継続される。要求されたセグメントがアップロード終了した場合、プロセス７８４は７８６に移行し、当該ボックスが実行していたこと又は実行が中断されているものを復元又は継続する。

プロセス７８４は１つのセグメントをアップロードするため説明されることに留意すべきである。当業者は、プロセス７８４がアップロード帯域幅が許す場合、複数のセグメントのアップロードに適用可能であることを理解するであろう。上位バンドの複数のセグメントが典型的にはボックスに常駐していることが上述された。発注元のボックスへのボックスのアップロード帯域幅が複数のセグメントをアップロードするのに十分であるとき、一実施例では、選択されたタイトルの再生が他のボックスにあまり依存しなくなるように、このようなボックスは複数のセグメントをアップロードするよう指定されるかもしれない。

図８は、本発明の多数の特徴が等しく適用されるアーキテクチャ８００を示す。アーキテクチャ８００は、図２Ａのアーキテクチャのすべての機能を含むかもしれない。図２Ａのアーキテクチャのエンハンスメントとして、アーキテクチャ８００は、すべての分散オブジェクトを格納するサーバデータベースを有する。分散オブジェクトを格納することによって、サーバは、バックアップボックスの故障時、初期的なバックアップボックスとして、帯域幅が利用可能なときは発注元のボックスをサポートするかもしれない。

発注元のボックスによるタイトルに対するリクエストに応答して、サーバは発注元のボックスに直接的に応答する必要がないことが理解されるべきである。サーバ２０２は、分散オブジェクトを発注元のボックスに提供する命令を分散したボックスに提供することによって応答してもよい。サーバ２０２は、分散したボックスに自らのサービスを自発的に申し出るよう要求することによって応答してもよい。サーバによる他の多くのレスポンスがまた可能である。発注元のボックスによるリクエストがサーバに送られる必要がないことがさらに理解されるべきである。例えば、ボックスにはネットワーク構成マップが与えられ、これにより、ボックスは他のボックスに直接リクエストすることが可能となり、再生リクエストのためのサーバ帯域幅の利用を回避することができる。

当業者は、システムの各要素がソフトウェアにより実現されてもよいが、ハードウェア又はハードウェアとソフトウェアとの組み合わせにより実現可能であることを認識するであろう。本発明はまた、コンピュータ可読媒体上のコンピュータ可読コードとして実現可能である。コンピュータ可読媒体は、以降においてコンピュータシステムにより読み取り可能なデータを格納することが可能な任意のデータストレージ装置とすることが可能である。コンピュータ可読媒体の具体例として、以下に限定するものではないが、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ−Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ、ＤＶＤ、磁気テープ、ハードディスク、光データストレージ装置又は搬送波を含むかもしれない。コンピュータ可読媒体はまた、コンピュータ可読コードが格納され、分散形式により実行されるように、ネットワークに接続されたコンピュータシステムに分散化することも可能である。

本発明の可能な効果は多数ある。異なる実施例又は実現形態は、以下の特徴及び効果の１以上をもたらすかもしれない。それらの１つは、メディア・オン・デマンドシステムにおける瞬時の特徴である。ローカルにキャッシュされたタイトルに係るファイルの小さな部分によって、ファイルの残りの部分が１以上のボックスにセグメントにより分散される。あるタイトルが発注されると、ユーザが認証され、支払が適切に決済されている場合、ローカルにキャッシュされた部分が即座に再生され、このローカルにキャッシュされた部分の再生中に、残りの部分がタイトルの再生を継続させるためにストリームとしてボックスからフェッチされる。それらのうちの他の１つは、ファイルの細分化方法である。タイトルに係るファイルが与えられると、ファイルはヘッダと複数のセグメントに細分化される。ヘッダはファイルの連続的な部分であり、各セグメントは、ファイルの残りの部分の間引きされた部分である。セグメントがフェッチされているとき、セグメントは再生のためもとのデータの順序を復元するため多重化される。さらなる他の可能な特徴及び効果は、ボックスが他のボックスにサービスを提供することを禁止することなく、ボックスのライブラリを同期的に又は非同期的に更新するための基礎となるメカニズムである。リリースが利用可能になると、ローカルにキャッシュされるべきリリースパッケージが、中央サーバから送信される代わりに、他のボックスから当該ボックスに非同期的に伝搬される。他の特徴及び効果もまた可能である。

上記実施例の説明は、本発明の各種特徴／実施例の例示である。添付された請求項によって規定されるような本発明の真の趣旨及び範囲から逸脱することなく、本発明に対する様々な変更が当業者により好適な実施例に対して可能である。例えば、一実施例では、ファイルのヘッダのサイズはゼロまで減少してもよく、すなわち、ファイルはボックスに分散可能な複数のセグメントに細分化される。また、タイトルが発注されると、サーバは、当該注文のためのデータを供給するソースを特定し、その後、発注元のボックスがソースとの通信を開始することを要求する代わりに、これらの供給元自体にデータ転送を開始するよう接続する。実際、発注元のボックスは、サーバが供給元のボックスを特定することを要求する代わりに、タイトルの各セグメントをキャッシュするボックスからソース情報を動的に取得することも可能である。従って、本発明の範囲は、上記実施例の説明でなく添付した請求項によって規定される。

図１は、サーバ・アンド・クライアントアーキテクチャとも呼ばれるネットワークを介しビデオサービスを配信するのに通常利用されるビデオ配信システムを示す。 図２Ａは、本発明の実施例による分散ネットワークシステムを示す。 図２Ｂは、一実施例によるヘッダと４つのセグメントに細分化又は構成されたファイルを示す。 図２Ｃは、タイトルの再生を継続するため、ボックスがローカルにヘッダを格納し、他の４つのボックスから４つのセグメントを受信する状況を仮定する場合に、１つのヘッダと４つのセグメントを有するタイトルに係るファイルを示す。 図２Ｄは、ヘッダとして割り当てられた始めの部分と、４つのセグメントに間引きされる残りの部分とによるファイルを表すデータストリームを示す。 図２Ｅは、一実施例による複数のボックスに分散させるためファイルを細分化するフローチャート又はプロセスを示す。 図３Ａは、ボックスの限られた格納スペース内のライブラリのタイトルの一例となる人気による分類を示す。 図３Ｂは、ボックスの限られた格納スペース内のライブラリのタイトルの他の例となる人気による分類を示す。 図３Ｃは、ライブラリのタイトルの人気に従う一例となるバンド化方式を示す。 図３Ｄは、図３Ｃに示されるバンド化に従う連続再生のためのバンドの各タイトルの対応する依存性を示す。 図３Ｅは、一実施例による瞬時のアクセスのための多数のタイトルのライブラリを分類するフローチャート又はプロセスを示す。 図３Ｆは、一実施例によるボックスのライブラリを更新するフローチャート又はプロセスを示す。 図４Ａは、一実施例によるサービス提供中のすべてのボックスのライブラリを同期的に又は非同期的に更新する図を示す。 図４Ｂは、一実施例によるサービス提供中のボックスにおいてリリースを提供するフローチャート又はプロセスを示す。 図４Ｃは、サービスプロバイダに高帯域幅ブロードキャスト機能のインフラストラクチャが設けられた一例となる状況を示す。 図４Ｄは、ブロードキャスト若しくはマルチキャストのための帯域幅が十分な構成の対するサービス提供中のボックスにおいてリリースを提供する一例となるフローチャート又はプロセスを示す。 図５Ａは、一実施例による新規ボックスのライブラリに対する段階的な変更を示す。 図５Ｂは、３つの新規ボックスがシステムに追加される一例となる状況を示す。 図５Ｃは、ある期間オンラインでなく、このため古いライブラリを有することとなったボックスのライブラリを更新するフローチャート又はプロセスを示す。 図６Ａは、本発明によるサーバの一実現形態を示す。 図６Ｂは、５０００タイトルのライブラリがＮ個のボックスにどのように分散されるか示す一例となるマップを示す。 図６Ｃは、発注されたタイトルのセグメントを供給するよう指定された４つのボックスのそれぞれに対するＩＰアドレス（ＩＰＡ１など）を含むテーブルとして一例となるソース情報を示す。 図６Ｄは、指定された各ボックスのバックアップ識別子（ＩＰアドレスとして示される）を有するテーブルのバックアップボックスによる一例となるソース情報を示す。 図６Ｅは、指定された３つのボックスが他の３つのボックスによりそれぞれバックアップされ、発注元のタイトルに係る３つのセグメントがそれぞれ発注元のボックスに提供される３つの指定されたボックスにより発注元のボックスがサポートされている一実施例を示す。 図６Ｆは、指定された３つのボックスが他の発注元のボックスをサポートする他の指定されたボックスを同時にバックアップする他の３つのボックスによってそれぞれバックアップされる発注元のボックスが３つの指定されたボックスによりサポートされている他の実施例を示す。 図６Ｇは、ライブラリのセレクション（すなわち、タイトル）の瞬時の再生を開始するフローチャート又はプロセスを示す。 図７Ａは、図２Ａの何れのボックスに対応するボックスの一実現形態を示す。 図７Ｂは、本発明の一実施例によるセレクション（すなわち、タイトル）の瞬時の再生を開始するフローチャート又はプロセスを示す。 図７Ｃは、本発明の一実施例によるセレクション（すなわち、タイトル）の瞬時の再生を開始するフローチャート又はプロセスを示す。 図７Ｄは、本発明の一実施例による再生されている第１部分が終了するとすぐに、再生用のデータストリームを生成するため４つのセグメントのストリームの多重化を示す。 図７Ｅは、本発明の一実施例によるボックスにおけるタスクを優先順位付けするフローチャート又はプロセスを示す。 図８は、本発明の多くの特徴が等しく適用されるアーキテクチャを示す。

Claims (26)

1. ネットワークに分散されるオブジェクトを管理するシステムであって、
   複数のボックスであって、それぞれが前記ネットワークに接続され、ヘッダといくつかのセグメントとにより表されるタイトルのライブラリを提供し、少なくとも前記タイトルの各々についての前記ヘッダと、前記タイトルの各々についての０以上の前記セグメントとをローカルにキャッシュするための格納スペースを有する、複数のボックスと、
   前記タイトルの１つの注文を含むリクエストを前記ボックスの１つである発注元のボックスから受信した後、レスポンスを提供するよう構成される計算装置と、
   を有し、
   前記レスポンスは、前記セグメントのすべてが前記発注元のボックスにローカルにキャッシュされていない場合、前記タイトルに係る欠落しているセグメントを提供するよう指定された供給元のボックス群を特定するソース情報を含む、システム。
2. 前記発注されたタイトルに係るファイルはデータブロックのシーケンスに分割され、該シーケンスがさらに前記ヘッダと残りの部分とに分割される、請求項１記載のシステム。
3. 前記ヘッダのデータブロックは時間的に連続的であり、前記残りの部分は前記セグメントに細分化され、前記セグメントのそれぞれのデータブロックは時間的に不連続なものである、請求項２記載のシステム。
4. 前記ライブラリはいくつかのバンドに分割され、各バンドはいくつかのタイトルにそのタイトルの人気度に基づいて対応しており、前記バンドの１つである上位バンドは最も需要のあるタイトルのいくつかを有し、前記バンドの他の１つである低バンドは最も需要の低いタイトルのいくつかを有する、請求項３記載のシステム。
5. 前記上位バンドのタイトルのセグメント数は、前記低バンドのタイトルのセグメント数より多く、それにより前記上位バンドの各タイトルに対して前記低バンドの各タイトルに対するよりも多くの分散コピーがもたらされることとなる、請求項４記載のシステム。
6. 各ボックスは、前記低バンドのタイトルのあるパーセンテージのみについて１つのセグメントを格納する、請求項４記載のシステム。
7. あるボックスにおける前記タイトルのパーセンテージは、当該ボックスに関する視聴行動の統計又はユーザからの入力に基づいて決定される、請求項６記載のシステム。
8. あるボックスにおける前記タイトルのパーセンテージは、学習エンジンに基づいて決定され、当該学習エンジンは、
   １．ユーザがこれまで当該ボックスから視聴したプログラムのセット
   ２．前記ユーザが当該ボックスについて評価したプログラム
   ３．前記ユーザが以降の視聴のために作成した選考リストの各項目
   ４．ブラウジング動作
   のうちのいくつか又は全てを動的に記録するものである、請求項６記載のシステム。
9. 前記低バンドのタイトル前記パーセンテージは、前記ボックスの各々に対して異なることが可能である、請求項６記載のシステム。
10. 前記上位バンドのタイトルの１つが再生される場合、前記ソース情報は、前記低バンドのタイトルの１つが再生される場合よりも少ない数の前記供給元のボックスを特定する、請求項４記載のシステム。
11. 前記タイトルのセグメント数は、前記バンドの１つから別の１つへと減少する、請求項４記載のシステム。
12. 前記上位バンド以外のバンドのタイトルのあるパーセンテージのみが、１以上のセグメントを有する、請求項１１記載のシステム。
13. より高位のバンドのタイトルが排除される場合は常に、当該タイトルはより低位のバンドに移され、当該タイトルのセグメント数が増加又は減少する、請求項４記載のシステム。
14. より高位のバンドにあるタイトルが追加されると、別のタイトルが当該高位のバンドからより低位のバンドへ移され、続いて、最も低位のバンドのタイトルが前記ライブラリから破棄されるまで、低位のバンドの別の１つのタイトルがさらに低位のバンドへ移される、請求項４記載のシステム。
15. 各ボックスは、前記ライブラリの各タイトルのどのセグメントを前記計算装置に従ってローカルにキャッシュするかをコントロールするよう構成されたライブラリ管理モジュールを含む、請求項１記載のシステム。
16. 前記計算装置は、時間帯、地理的位置、利用可能なネットワーク帯域幅、ユーザ層、遅延情報からなる群から選ばれる１以上の要素に基づいて、どのボックスがどのセグメントをキャッシュするかを決定するよう構成される、請求項１５記載のシステム。
17. ネットワークに分散されるオブジェクトを管理する方法であって、
    ライブラリ内の複数のタイトルをどのように複数のバンドに編成するかを、前記タイトルの人気に少なくとも部分的に従って決定するステップと、
    前記バンドの１つに含まれる各タイトルについて各ボックスに格納するセグメント数を、前記人気に少なくとも部分的に従って決定するステップと、
    を有し、
    前記タイトルの各々に係るファイルはヘッダといくつかのセグメントを含み、前記バンドの１つである上位バンドは最も需要のあるタイトルのいくつかを含み、前記バンドの他の１つである低バンドは最も需要の低いタイトルのいくつかを含む、方法。
18. 前記複数のタイトルのヘッダは、当該複数のタイトルの各々がどのバンドに属しているかにかかわらず、各ボックスに格納される、請求項１７記載の方法。
19. 前記上位バンドのタイトルのセグメント数は、前記低バンドのタイトルのセグメント数より多く、それにより前記上位バンドの各タイトルに対して前記低バンドの各タイトルに対するよりも多くの分散コピーがもたらされることとなる、請求項１８記載の方法。
20. 各ボックスは、前記低バンドのタイトルのあるパーセンテージのみについて所定数のセグメントを格納する、請求項１９記載の方法。
    
21. ライブラリを動的に更新し続ける方法であって、
    サービス提供中の各ボックス内のライブラリを更新するためリリースに含まれるタイトルに係るファイルをデータチャンクのシーケンスに分割するステップと、
    前記データチャンクをまとめて受信するよう、前記データチャンクの少なくとも一部を受信する各提供ボックスからなる初期的な提供ボックス群を指定するステップと、
    前記提供ボックスのそれぞれに、前記受信したデータチャンクの少なくとも一部又は全部を前記ボックスからなるボックス群に対して伝搬させるステップと、
    を有し、
    前記ボックス群の各ボックスは、サービス提供中の前記ボックスのそれぞれが前記データチャンクの指定された部分を受信するまで、自らが受信したデータチャンクの一部又は全部を前記ボックス間に拡散し続けるよう選択された他のボックスに対して当該受信したデータチャンクを再帰的に伝搬する、方法。
22. 前記ファイルは、存在する場合には、補助データを伴うデータのコレクションであり、該ファイルはヘッダといくつかのセグメントで表され、
    各ボックスに、前記ヘッダと０以上の前記セグメントとを前記受信したデータチャンクの一部又は全部から復元させるステップと、
    続いて各ボックス内のライブラリを更新するステップと、
    をさらに有する、請求項２１記載の方法。
23. 新たにインストールされた装置においてコンテンツを更新する方法であって、
    メディアサービスを提供するシステムに新たなボックスが検出されると、ライブラリ内のいくつかの古いタイトルを決定するステップと、
    前記古いタイトルを前記ライブラリから排除するため、前記ライブラリに追加する対応する数の更新されたタイトルを決定するステップと、
    前記ボックスに、前記更新されたタイトルの中で相対的に新しいタイトルに係るデータをまず抽出させて、前記ボックスが当該相対的に新しいタイトルの１つの注文に対してサービスを提供する準備ができるようにするステップと、
    前記ボックスが完全に更新されるまで、前記ボックスに、前記更新されたタイトルの中の残りのタイトルに係るデータを抽出させるステップと、
    を有する方法。
24. 前記いくつかの古いタイトルを決定するステップは、当該古いタイトルに係るデータがいまだ利用可能であっても、当該古いタイトルを前記ライブラリにおいて利用不可能とするステップを有する、請求項２３記載の方法。
25. 前記ボックスにデータを抽出させるステップは、
    前記相対的に新しいタイトルのそれぞれについてのヘッダを抽出するステップと、
    前記相対的に新しいタイトルのそれぞれについての複数のセグメントの１つを抽出するステップと、
    を有する、請求項２４記載の方法。
26. 前記ボックスにデータを抽出させるステップは、前記相対的に新しいタイトルの人気度の降順により、前記相対的に新しいタイトルのそれぞれについてのヘッダ及び複数のセグメントの１つを抽出するステップを有する、請求項２３記載の方法。

Images