瞬時のメディア・オン・デマンド
【課題】瞬時のメディアサービスを提供するための各種技術が開示される。
【解決手段】これらの技術の一部は、瞬時のメディア・オン・デマンドシステム、プロセス及び方法を提供する。このようなシステムは、ユーザが選択可能な多数のタイトルを有する動的なライブラリを提供し、所望のタイトルを瞬時の再生を提供する。瞬時の再生を実現するため、タイトルに係るファイルがヘッダとセグメントに細分化される。ヘッダは、サービス提供中のすべてのボックスに提供され、0以上のセグメントがボックスのネットワークに分散される。タイトルが発注されると、ヘッダが瞬時に再生され、その間に、ローカルに利用可能でない場合には、セグメントが発注されたタイトルの連続的な再生を可能にするため、セグメントを有するボックスからそれぞれストリーミングされる。
【解決手段】これらの技術の一部は、瞬時のメディア・オン・デマンドシステム、プロセス及び方法を提供する。このようなシステムは、ユーザが選択可能な多数のタイトルを有する動的なライブラリを提供し、所望のタイトルを瞬時の再生を提供する。瞬時の再生を実現するため、タイトルに係るファイルがヘッダとセグメントに細分化される。ヘッダは、サービス提供中のすべてのボックスに提供され、0以上のセグメントがボックスのネットワークに分散される。タイトルが発注されると、ヘッダが瞬時に再生され、その間に、ローカルに利用可能でない場合には、セグメントが発注されたタイトルの連続的な再生を可能にするため、セグメントを有するボックスからそれぞれストリーミングされる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般にインターネットを介したマルチメディア配信に関する。特に、本発明は、適切に組み合わされるとき、サービスを含む瞬時のメディア・オン・デマンド(MOD)を提供するための技術、システム及び方法に関する。さらに、本発明は、ユーザが選択し、瞬時に再生可能な多数のタイトルのダイナミックライブラリを提供する技術に関する。
【0002】
[関連技術の説明]
年長者が火の近くで物語を話し、又は夕食時に家族がテレビの前に座ったりするが、人間は生来的に物語を聞き、楽しむという欲求を有している。各家庭がどれほど多くのテレビ及び/又はラジオを有しているか信じることはできない。実際、すべての家庭は2.3台のテレビを所有し、人々は1日に平均して5時間もテレビを視聴していると推定されている。これらの統計や人々の傾向は、ケーブルプロバイダ、衛星プロバイダ、ビデオレンタル企業、Blockbuster Inc.、NetFlix.comなどが、映像、テレビ及び映画配信、プレミアム映画チャンネル、ペイ・パー・ビューなどを顧客に提供するため数百万ドルを投資する動機付けを提供する。
【0003】
従来、各テレビ視聴者は、いくつかの番組を提供する4つ又は5つのテレビチャンネルを有し、よりエキサイティングな映画コンテンツを観るため映画館に行くことで満足していた。しかしながら、現在の視聴者は、より高い要求をするようになり、多様なより洗練されたドラマ、コメディ、アドベンチャー、ホラーなどを含むより多くのものを自宅のテレビから期待するようになってきている。この要求を満足させるため、テレビ視聴者の大多数はケーブル若しくは衛星サービスに加入している。この基本サービスは、通常のテレビよりかなり多数のチャンネルとプレミアム放送を提供するだけである。
【0004】
依然として顧客は不満足なままである。このため、ケーブル及び衛星サービスは映画チャンネル契約を提供している。各映画チャンネルは、予め選択された時間に限られた数の比較的新しい映画配信のリリースを提供する。視聴者は、映画リストと映画スケジュールとを確認し、それらが提供されるときに選択された映画を視聴することを計画することができる。視聴者がその時間にテレビをオンすると、視聴者は始めからその映画を視聴することができる。そうでない場合、視聴者は途中から開始される映画を視聴しなければならないかもしれない。あるいは、視聴者は自らに都合のよい時間に視聴するため映画を記録することができる(TiVo Inc.によって提供されるものや従来のVCRなどのデジタルビデオレコーダを利用して)。これらの映画チャンネルによって提供される映画の本数は限られているため、より厳格な視聴者は現在提供されているすべての所望される映画を記録するかもしれず、さらなるタイトルが利用可能になるまで待機しなければならいかもしれない。映画チャンネルにより提供される映画数は限られており、これらの映画は不定期的な時間に開始されるため、映画チャンネルは現在の顧客の要求を効果的に充足するものでない。
【0005】
“ビデオ・オン・デマンド”の顧客アピールは周知である。一般に、真のビデオ・オン・デマンドは、利用可能な所望されるすべての映画のリストから選択可能な映画(又は他のコンテンツ)の瞬時の視聴として特徴付けすることが可能である。理想的には、サーバ若しくはサーバ群がすべての映画を格納し、顧客が映画を選択することを可能にし、顧客がネットワークの中断なく映画を視聴する間に、映画を顧客にストリーミングする。しかしながら、現在の技術及びネットワーク関連インフラストラクチャの多くの問題点によって、真のビデオ・オン・デマンドは公衆には現在利用可能でない。衛星、ケーブル及びDSLネットワークにおける通信容量及び速度は、不十分なものであり、信頼性が低く、予測不能で整合性を有していない。この不十分で不整合な通信容量及び速度のため、真のビデオ・オン・デマンドが利用可能になった場合、現在のシステムの視聴者は、所望しない中断や他のエラー動作を解決する必要が生じるであろう。真のビデオ・オン・デマンドは、おそらく数年間は公衆には利用可能とはならず、より高速ではるかに高い信頼性と予測可能性を備えた通信チャネル(光ファイバなど)が使用され、より速い計算が確立された後になって始めて利用可能となるであろう。
【0006】
限定的な環境では、真のVODは、大容量及び高速性を維持及び配信可能な特化した信頼性の高いネットワークを利用して現在提供される。ケーブルの“オン・デマンド”は、このようなサービスの1つである。ユーザが高速のデジタルネットワークに接続される場合に限って、またサービスプロバイダがVODをサポート可能である場合に限って、オン・デマンドは再生のため映画を瞬時にダウンロードすることが可能である。このサービスは、従来のブロードバンド接続を介しては利用可能でない。
【0007】
ここで図1を参照すると、ネットワークを介しビデオサービスを配信するのに利用されるビデオ配信システム100が示される。ビデオ配信システム100は、ときどきヘッドエンドと呼ばれるビデオサーバ102を有する。データネットワーク104を介し、ビデオサーバ102は、各クライアントマシーン106−1,106−2,...,106−n(すなわち、それの加入者)に連続するスケジューリングされたビデオ・オン・デマンド(VOD)サービスを提供することができる。なお、システム100は、1つのサーバ102が複数のクライアントマシーン106−1,106−2,...,106−nにサービスを提供するという典型的なクライアント・サーバアーキテクチャとなっている。サーバ102はさらに、各種メディアファイル(映画やニュース映像など)を格納するよう構成可能なメディアストレージ装置に接続される。メディアストレージ装置112は、オンラインであることが求められ、クライアントマシーン106−1,106−2,...,106−nの何れかへの配信がスケジューリング又は要求されるタイトルを格納及び供給しなければならない。
【0008】
QoS(Quality of Service)を保証するため、各クライアントマシーン106−1,106−2,...,106−nとのネットワークパス(108−1,108−2,...,108−nなど)のバンド幅要求は十分なものでなければならない。しかしながら、加入者数が増加し続けるに従って、バックボーンネットワークパス110のバンド幅に対する要求は線形に増大し、システム100の全体的なコストもそれと同時に大きく増大する。サーバが固定されたバンド幅制限を有し、システムが能力をサポートする場合、ある閾値を超えた加入者数の増大は、クライアントへのデータ転送を低速化する。すなわち、ネットワーク104上でのビデオデータのクライアントマシーン106−1,106−2,...,106−nを介した加入者への送信は、もはや保証されない。ビデオデータが時間通りにクライアントマシーンに受信されないとき、ビデオデータの表示は不可となるか、少なくとも苛つかせるものとなるかもしれない。
【0009】
ビデオサーバ102へのこのようなロード問題を軽減するため、ビデオ配信システムはしばしば、おそらく複数の場所にある複数のビデオサーバを利用する。各ビデオサーバは、ビデオサーバ102と同様に、限定数の加入者をサポートするよう構成される。加入者数がビデオサーバの容量又はそれのバンド幅を超えるとは常に、追加的なビデオサーバが配備されるか、又は追加的なバンド幅が割り当てられる必要がある。このため、より多くの加入者がビデオ配信システム100にサインアップすると、全体的なコストは大きく増大する。
【0010】
ビデオ・オン・デマンドの制約に対するシンプルな解決策として、ケーブル及び衛星プロバイダは、ペイ・パー・ビュー、すなわち、ビデオレンタルの価格とほぼ同額で平均して30分毎に開始される限定数のより新たなリリースを提供する。ペイ・パー・ビューによってでさえ、顧客は限定されたセットから映画を選択しなければならず、依然として配信開始まで待機しなければならい。さらに、セットトップボックスがサービスプロバイダとの双方向通信をサポートしていない場合には、顧客は選択された映画を発注するため、不便なことにサービスを電話連絡しなければならい。ペイ・パー・ビューは、真のビデオ・オン・デマンドに対するあまり効果的でない解決策である。
【0011】
いくつかのケーブル及びインターネット企業は、真のビデオ・オン・デマンドに対する他の代替策を検討している。現在のより良い代替的なシステムの1つは、視聴者が映画を選択、発注、ダウンロード及び視聴することを可能にする。しかしながら、低速のダウンロードスピードとかなりの映画サイズのため、視聴者は映画をダウンロードするため、例えば、1〜2時間などかなりの時間待機しなければならい。ペイ・パー・ビューより良好な多数の方法においてでさえ、この選択肢は理想とはほど遠いものである。この解決策は、映画の受信前に長時間顧客を待機させ、顧客に即座の満足感を提供することができず、多くの購入者の衝動性を利用することができない。
【0012】
衛星プロバイダは、特に真のビデオ・オン・デマンド若しくは現在の代替策を提供することが困難であろう。なぜなら、衛星通信はリターンパスを提供せず、すなわち、衛星プロバイダから顧客への一方向のみの通信しか提供しないため、また配信(すなわち、ポイント・ツー・マルチポイント)に十分な衛星バンド幅はポイント・ツーポイント通信には不十分であるためである。このとき、顧客は、ある双方向通信モードなしに映画の選択肢を熟読し、映画をリクエスト等することができない。衛星ネットワークの限定的な能力のため、衛星プロバイダは、ケーブル、インターネットブロードバンド、VoIP(Voice over IP)及び他のネットワークサービスを提供することが可能なケーブルプロバイダに対してかなり不利である。
【0013】
Blockbuster Inc.やNetflix,Inc.などの各企業は、より多くの映画選択肢を顧客に提供しようとするビジネスモデルを構築してきた。しかしながら、Blockbusterは、顧客がソファから離れ、支度をし、望ましくは地域の事業所に行き、映画(しばしば利用可能でない)を選択し、映画を開始することが可能になる前に自宅に戻ることを要求する。Netflixは、顧客が多くのリストから映画を発注することを要求するが、要求された映画を従来のポストを用いて郵送する。顧客は、リクエストした映画を受け取るまで少なくとも数日待つ必要がある。これら2つのモデルは、“オン・デマンド”を提供するものでない。
【0014】
従って、ユーザが大きなライブラリから所望のタイトルを選択し、発注したタイトルを瞬時に視聴することを可能にする瞬時のVODシステムが要求される。
【0015】
[概要]
本セクションは、本発明の実施例のいくつかの特徴を要約し、好適な実施例を簡単に紹介する。本セクション並びに本開示のタイトル及び要約の簡単化及び省略は、本セクション、タイトル及び要約の目的を不明りょうにすることを回避するため行われるかもしれない。このような簡単化又は省略は、本発の範囲を限定するものでない。
【0016】
概略すると、本発明の実施例は、データネットワークを介しメディアサービスを提供するための技術に関する。ここに記載される技術は、互いに関連するものであり、それぞれは当該技術において独立に新規なものであると思料する。開示された技術は、新規かつ非自明なシステム若しくはシステムの一部を提供するため、単独で若しくは何れかの組み合わせにより実行されるかもしれない。それらの最も広範な意味で組み合わされた場合でさえ、すなわち、各技術が実践のため減縮された具体的方法未満によって、組み合わせた技術が等しく独立な新規な組み合わせをもたらすことが理解されるべきである。
【0017】
本発明の実施例は、データネットワークを介しメディアサービスを提供するための各種技術に関する。一特徴によると、適切に組み合わされると、当該技術の一部は瞬時のメディア・オン・デマンドシステム、それと等価なプロセス及びメソッドを提供することが可能である。メディアサービスが中央サーバにおいてレンダリングされる従来のシステムとは大きく異なって、本発明の実施例はネットワーク上の各装置を利用して、要求されるサービスを提供するため、必要とされるサービスを細分化して互いに供給する。この結果、サーバに対するロード要求が、ネットワークに分散化される。
【0018】
本発明の他の特徴によると、システムは、ユーザが所望するときは常にタイトルを選択及び発注可能な多数のタイトルを有するライブラリを提供し、タイトルに係るファイルの始めの部分にアクセスすることによってタイトルをほぼ瞬時に再生する。データの始めの部分はローカルにキャッシュされ、データの残りの部分は他の指定された装置によって供給される。ライブラリは、リリース(新たな又は人気のあるタイトルなど)により動的に更新される。
【0019】
本発明のさらなる他の特徴によると、タイトルに係るファイルが、ヘッダと複数のテール若しくはセグメントに細分化される。ヘッダは、ファイルの連続部分であり、セグメントは、ファイルの残りの各部分である。ヘッダは、実質的にすべてのボックスに提供され、セグメントは、サービス提供中の各ボックスにその少なくとも1つしか又は全く配信されない。タイトルが発注されると、ヘッダが瞬時に再生され、その間にローカルに利用可能でない場合には、セグメントがストリーミングされるか、若しくはセグメントを有する他のボックスからそれぞれ連続的にフェッチされる。ファイルの残りの部分を復元し、タイトルの再生を継続するため、同時にフェッチされたセグメントからのデータが、存在する場合にはローカルにキャッシュされているセグメントからのデータと共に多重化される。
【0020】
本発明のさらなる他の特徴によると、ネットワーク帯域幅を最大限活用し、QoS(Quality of Service)を最大化するため、大きなファイルがインテリジェントに細分化され、これらのセグメントが分散化される。ヘッダサイズとセグメント数は、要求されるタイトルの転送レート、利用可能な最小のネットワークスピードなどに従って定期的に計算又は決定される。
【0021】
本発明のさらなる他の特徴によると、サービス提供中の各ボックスのライブラリが、同期的に又は非同期的に更新される。ライブラリを更新するためのリリースは、サービス提供中のすべてのボックスにgossipプロトコルによりデータチャンクを伝搬することによって実行される。その後、適切なリリースパッケージが、ライブラリを更新するため、受信したデータチャンクから各ボックスにおいて復元される。サービスプロバイダに高帯域幅ブロードキャスト若しくはマルチキャスト機能が備えられているケースでは、ヘッダと複数のセグメントに細分化されるリリースは、ライブラリを更新するため適切なリリースパッケージを受信するようそれぞれ構成されるすべてのボックスに送信される。
【0022】
本発明のさらなる他の特徴によると、新たにインストールされ、又はある期間後にネットワークに戻されたボックスは、例えば、サービス提供を開始するため可能な最短時間などにより効率的に更新される。このようなボックスのもとのライブラリは、最も需要のあるタイトルによって、最初の若しくは可能な少なくともデータ量により更新され、これにより、ボックスは、最も需要のあるタイトルに対する注文を実現するためだけでなく、必要なデータを他のボックスに提供するための状態にすぐになるかもしれない。実現形態に応じて、ボックスのもとのライブラリの更新は、最新のタイトルをまとめて有する他のボックスからgossipプロトコルによってデータチャンクを受信することによって、又はブロードキャスト若しくはマルチキャストインフラストラクチャを介しサービスプロバイダから適切なリリースパッケージを受信することによって実行されてもよい。
【0023】
本発明のさらなる他の特徴によると、ボックス間に転送されるすべてのデータが遅延若しくは中断しないように、データを発注元のボックスに提供するよう指定されたボックスをサポートするため、バックアップボックスが設けられる。ボックスの1つが低パフォーマンスによりデータを発注元のボックスに提供する場合(例えば、ボックスの動作上の問題又は所望されないネットワークパフォーマンスにより)、低パフォーマンスのボックスを置換若しくは支援し、発注元のボックスへのデータの供給を継続するため、バックアップボックスが起動されるかもしれない。本発明の他の特徴は、ここでの詳細な説明から当業者により理解されるであろう。
【0024】
本発明の実施例は、方法、システム、装置若しくはコンピュータ可読媒体を含む各種方法により実現されるかもしれない。本発明のいくつかの実施例が以下に説明される。一実施例では、本発明は、ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、発注元のボックスからライブラリのタイトルの注文を含むリクエストを受信するステップと、前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する1以上のボックスを特定するステップとを有し、前記発注元のボックスは、前記1以上のボックスから前記タイトルに係る分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生することによって前記タイトルの再生を進行する方法を提供する。
【0025】
他の実施例では、本発明は、ボックスのライブラリのすべてのタイトルの視聴機構を提供する方法を提供する。本方法は、ボックスのタイトルのライブラリからタイトルの選択を可能にするステップと、前記タイトルの1つが選択されると、タイトル情報を含むリクエストを生成するステップと、前記発注されたタイトルに係る1以上の分散オブジェクトを提供する1以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するステップと、前記発注されたタイトルに係る前記ボックス内の常駐オブジェクトの再生を開始するステップと、前記常駐オブジェクトの再生中に一部が受信される1以上のデータストリームとして、前記1以上のボックスから前記1以上の分散オブジェクトを受信するステップと、前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記1以上のデータストリームの再生を開始するステップとを有する。
【0026】
さらなる他の実施例では、本発明は、ネットワークを介しメディア・オン・デマンドサービスを提供するシステムを提供する。本システムは、各ボックスがネットワークに接続され、ユーザに関連付けされ、タイトルのライブラリを提供し、複数のヘッダと複数のセグメントが常駐することを可能にする格納スペースを有し、タイトル選択情報を有するリクエストを提供するよう構成される複数のボックスと、前記ネットワークに接続され、前記ボックスの1つである発注元のボックスからのリクエストに対するレスポンスを提供するよう構成されるサーバとを有し、前記レスポンスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう構成されるボックス群を特定するソース情報を含み、前記レスポンスに応答して、前記発注元のボックスは、前記ボックス群から1以上の分散セグメントをダウンロードしながら、前記選択されたタイトルに係るヘッダの再生を開始する。
【0027】
さらなる他の実施例では、本発明は、ネットワークに分散されるオブジェクトを管理するシステムを提供する。本システムは、各ボックスが、ネットワークに接続され、ユーザに関連付けされ、それぞれがヘッダといくつかのセグメントとにより表されるタイトルのライブラリを提供し、各タイトルについてヘッダと0以上のセグメントとをローカルにキャッシュするための格納スペースを有する複数のボックスと、タイトルの1つの注文を含むリクエストをボックスの1つ(発注元のボックス)から受信した後、レスポンスを提供するよう構成される計算装置とを有し、当該レスポンスは、セグメントのすべてが発注元のボックスにローカルにキャッシュされていない場合、タイトルに係る欠落しているセグメントを提供するよう指定された供給元のボックス群を特定するソース情報を有する。一般に、ライブラリは、いくつかのグループ若しくはバンドに分割され、バンドの1つ(上位バンド)は、最も需要のなるタイトルのいくつかを有し、他のバンド(低バンド)は、最も需要の低いタイトルのいくつかを有する、1つのケースでは、上位バンドのタイトルのセグメント数は、低バンドのタイトルのセグメント数より多く、これは、上位バンドの各タイトルに対して低バンドのタイトルに対するよりも多くの分散コピーをもたらす。
【0028】
さらなる他の実施例では、本発明は、タイトルに係るファイルを細分化する方法であって、ファイルを第1部分と第2部分に分割されたデータブロックシーケンスに分割するステップと、ヘッダのデータブロックが連続的なものとなるように、第1部分のデータブロックからヘッダを形成するステップと、各セグメントのデータブロックが不連続なものとなるように、各セグメントが第2部分のデータブロックの一部を有するN個のセグメントを形成するステップとを有する(ただし、Nは1より大きな有限の整数である)。ファイルは、存在する場合には、補助データを伴うデータのコレクションである。ヘッダは、常駐オブジェクトとしてサービス提供中の各ボックスにローカルにキャッシュされ、N個のセグメントのうちのM個のセグメントがボックスに格納される。ここで、Mの値は、タイトル毎及びボックス毎に異なり、0≦M≦Nである。
【0029】
さらなる他の実施例では、本発明は、ライブラリを動的に更新し続ける方法を提供する。本方法は、サービス提供中の各ボックスのライブラリを更新するためリリースに含まれるタイトルに係るファイルをデータチャンクシーケンスに分割するステップと、各提供ボックスがデータチャンクの少なくとも一部を受信し、データチャンクをまとめて受信する初期的な提供ボックス群を指定するステップと、各提供ボックスに受信したデータチャンクの少なくとも一部若しくはすべてをボックス群に伝搬させるステップとを有し、ボックス群の各ボックスは、サービス提供中の各ボックスがデータチャンクの指定された部分を受信するまで、ボックス間に受信したデータチャンクの一部若しくはすべての拡散を継続するよう選択された他のボックスに受信したデータチャンクを再帰的に伝搬する。実質的に、各ボックスは、受信指定されたものを受信する。本方法はさらに、受信したデータチャンクの一部若しくはすべてからヘッダと0以上のセグメントとを各ボックスに復元させ、その後、それのライブラリを更新する。
【0030】
さらなる他の実施例では、本発明は、新たにインストールされた装置においてコンテンツを更新する方法であって、メディアサービスを提供するシステムに新たなボックスが検出されると、ライブラリのいくつかの古いタイトルを決定するステップと、ライブラリに追加し、ライブラリから古いタイトルを排除するため、対応する見逃したタイトルを決定するステップと、ボックスが相対的に新たらしいタイトルの1つの注文に対してサービスを提供する準備ができるように、ボックスに見逃したタイトル群の中の相対的に新しいタイトルに係るデータをまず抽出させるステップと、ボックスが完全に更新されるまで、残りの見逃したタイトルに係るデータをボックスに抽出させ続けるステップとを有する方法を提供する。1つのケースでは、ボックスは、相対的に新しい各タイトルのヘッダを抽出し、その後、それぞれに対する複数のセグメントの1つを抽出する。他のケースでは、ボックスは、タイトルの人気の降順により相対的に新しい各タイトルのヘッダと複数のセグメントの1つを抽出する。
【0031】
さらなる他の実施例では、本発明は、分散環境においてデータを転送する方法を提供する。本方法は、ネットワーク上の計算装置によって提供されるソース情報に従って、要求されるデータセグメントを供給するよう指定された各ボックスとの通信セッションが確立されているか判断するステップと、通信セッションが指定された各ボックスと良好に確立された後に限って、指定されたボックスから必要とされるデータセグメントを同時にダウンロードするステップとを有し、必要とされる各データセグメントは、ファイルを表すデータブロックシーケンスからサンプリングされた複数のデータブロックを有する方法を提供する。
【0032】
さらなる他の実施例では、本発明は、ライブラリを動的に更新し続ける方法であって、ライブラリを更新するための少なくとも1つのタイトルを含むリリースをデータパッケージにより準備するステップと、サービス提供中のボックスに送信インフラストラクチャを介しデータパッケージを送信するステップとを有し、各ボックスはデータパッケージの少なくとも一部をローカルにキャッシュするよう構成され、ボックスのすべてがデータパッケージの同一部分をキャッシュしていない方法を提供する。実現形態に応じて、送信インフラストラクチャは、ブロードキャスト若しくはマルチキャスト可能であってもよい。データパッケージは、タイトルのヘッダと複数のセグメントを有する。各ボックスにローカルにキャッシュされるデータパッケージの一部は、ヘッダと0以上のセグメントとを有する。あるいは、データパッケージは、各リリースパッケージがヘッダと0以上のセグメントを含む複数のリリースパッケージを有する。
【0033】
本発明の1つの課題は、適切に組み合わされたとき、瞬時のメディア・オン・デマンドシステムを提供するのに効果的に利用可能な技術を提供することである。
【0034】
本発明の他の課題、特徴及び効果は、添付した図面と共にそれの実施例の以下の詳細な説明を参照することにより明らかとなるであろう。
【0035】
[発明の詳細な説明]
本発明の実施例は、データネットワークを介しメディアサービスを提供するための各種技術に関する。これらの技術の一部は、適切に組み合わされるとき、瞬時のメディア・オン・デマンドを提供することが可能である。一実施例は、ユーザがほとんど瞬時に再生のため選択及び発注可能な多数のタイトルを備えたダイナミックライブラリを提供するかもしれない。瞬時の再生を実現するため、タイトルに係るファイルがヘッダと複数のセグメント(又はテール)に細分化されるかもしれない。一実施例では、ヘッダはすべてのボックスに設けられ、各セグメントは、ある方式に従ってネットワーク内でこれらのボックスに配信される。タイトルが発注されると、ヘッダは即座に再生可能となり、セグメントは、それがローカルに利用可能でない場合には、サポートするボックスからストリーミングすることが可能である。同時にフェッチされる各セグメントからのデータは、必要に応じて、ファイルの残りの部分を復元し、発注されたタイトルの再生を継続するため、ローカルにキャッシュされたセグメントに多重化することが可能である。
【0036】
さらに一実施例では、サービスを提供する各ボックスのライブラリは、例えば、gossipプロトコルなどを利用して、データチャンクをサービス提供中のすべてのボックスに伝搬することによって、同期的に若しくは非同期的に更新されるようにしてもよい。システムに新たにインストールされた若しくは一定期間後に戻されたボックスは、サービスの提供を開始するためすぐに更新することが可能である。本発明の他の可能な特徴及び効果は、実施例により本発明の原理を示す添付した図面と共になされる以下の詳細な説明から明らかになるであろう。
【0037】
以下の説明では、本発明の完全なる理解を提供するため、多くの具体的詳細が提供される。本発明は、これらの具体的詳細なしに実現可能である。ここでの記載及び表示は、研究の本質を他の当業者に効果的に伝えるため、当業者によって使用される手段である。他の例では、周知の方法、手順、コンポーネント及び回路は、それらがすでに十分に理解されているため、また本発明の特徴を不要に不明りょうにすることを回避するため、詳細には説明されていない。
【0038】
ここでの“一実施例”若しくは“ある実施例”という表現は、当該実施例に関して説明される特定の機能、構成若しくは特徴が本発明の少なくとも1つの実現形態に含めることが可能であることを意味する。明細書中の各箇所における“一実施例”という表現は、必ずしもすべてが同一の実施例を参照しているとは限らず、他の実施例の相互に排他的な別個の若しくは他の実施例でもない。さらに、1以上の実施例を表すプロセス、フローチャート若しくは機能図における各ブロックの順序は、本来的に特定の順序を示すものでなく、また本発明の各限定を意味するものでもない。
【0039】
便宜上、いくつかの用語の定義が以下に与えられる。これらの定義は一実施例による本発明の理解及び記載を容易にするためのものであることに留意すべきである。これらの定義は、実施例に関する各限定を含むように見えるかもしれない。しかしながら、これらの用語の実際の意味は、このような実施例を超えた適用性を有するかもしれない。
【0040】
メディア又はビデオは、ここでは互換的に使用され、マルチメディアデータを示すものであり、その集合体は、他の可能性のある補助データと一緒になってファイルとして呼ばれる。このようなファイルは典型的にはサイズの大きなものであるため、それはしばしば、一般的に使用される規格(H.264、MPEG−1、MPEG−2若しくはMPEG−4など)に従って格納若しくは送信のため圧縮される。ビデオの具体例として、以下に限定されるものではないが、映画、ゲーム、映像場面、ドキュメンタリ若しくはマルチメディアデータコレクションがあげられる。
【0041】
ローカル装置、コンピュータ、マシーン又は単にボックスは、ここでは互換的に使用され、典型的にはメディアファイルにアクセスするためユーザにより使用される計算装置である。このようなクライアントマシーンは、他の装置とは独立して若しくはそれと共に動作するかもしれない。クライアントマシーンの具体例として、セットトップボックス、計算装置(デスクトップ、ラップトップ、PDA、電話、タブレットPCなど)、ネットワーク機能を備えたテレビ及びネットワークストレージ装置があげられる。
【0042】
常駐オブジェクト及び分散オブジェクトは、相対語である。ファイルが複数の部分若しくはセグメントに分割されると、これらのセグメントの一部は他のボックスにリモートに分散されるかもしれない。これら分散されたセグメントは、“分散オブジェクト”と呼ばれる。ローカルにキャッシュされたヘッダ及び他のセグメントは、“常駐オブジェクト”若しくは“レジデンスオブジェクト”と呼ばれる。
【0043】
サーバ、サーバ装置、サーバコンピュータ又はサーバマシーンは、ここでは互換的に使用され、典型的には、ローカルボックスからリモート配置された計算装置である。実現形態に応じて、ここでのサーバは、ここに記載されるサーバ処理を送出するよう構成されたスタンドアローンコンピュータ若しくは2以上のコンピュータのクラスタを意味するかもしれない。
【0044】
本発明の実施例が、図2A〜8を参照して説明される。しかしながら、当業者は、本発明はこれらの限定的な実施例の範囲を超えるため、これらの図面に関してここで与えられる詳細な説明が単なる説明のためのものであることを容易に理解するであろう。
【0045】
本発明の一実施例は、増大するユーザ数によって悪影響を受けないデータネットワークを介しビデオサービスを配信するための技術に関するものである。一実施例では、ユーザが多くなるに従って、システムもしくはプロセスによって提供されるパフォーマンスはより良好となる。
【0046】
図2Aは、本発明の実施例による分散ネットワークシステム100の一例となる構成200を示す。ネットワーク全体は、例えば、特定のタイプ、サイズ、コンテンツなどの各ボックスに対して1つのこのようなネットワークシステム100を複数有してもよいということは理解されるであろう。
【0047】
サービスプロバイダによっておそらく管理及び/又は占有されるサーバ202は、ローカルマシーン若しくはボックス206−1,206−2,...,206−nを介したユーザへのビデオ(若しくはマルチメディア)サービスの配信を処理するよう構成される。加入者からのリクエストにより加入者にビデオデータを配信する図1のビデオサーバ102とは異なり、サーバ202は、ユーザからのリクエストに応答してコンテンツを配信するものでなく、その代わりに他のボックスからコンテンツの少なくとも一部を抽出すべき場所及びその方法に関するソース情報を提供するよう構成される。すなわち、図1のサーバ102は、メディアストレージ装置112がクライアントマシーン106−1,106−2,...,106−nの何れかへのサービス提供時にコンテンツを提供することを要求し、サーバ202は、メディアストレージ装置がコンテンツを提供することを要求しない。その代わりに、ボックス206−1,206−2,...,206−nの一部が、コンテンツの一部若しくはすべてを互いに供給するようそれぞれ構成される。
【0048】
一実施例によると、ローカルマシーン若しくはボックス(206−1など)からのリクエストを実現するとき、サーバ202とボックス206−1との間のネットワークパス208−1及び210を介した通信は、小さなスケールのリクエストとレスポンス(小さなサイズ及び大変短いものなど)に限定されるかもしれない。ボックスからのリクエストに対するサーバレスポンスは、ソース情報(識別子など)、認証情報及びセキュリティ情報を含むかもしれない。サーバ202からのレスポンスを利用して、ボックスはタイトル(207−1など)の再生を開始するよう起動されるかもしれない。実質的に同時に、ボックスは、当該タイトルの移行の部分(207−2、207−nなど)をリクエストするため、ソース識別子に従って他のボックス(206−2、206−nなど)に対する1以上のリクエストを開始するかもしれない。適切な認証を仮定すると、要求元のボックスは、その他のボックスから同時に当該データの以降の部分を受信する。コンテンツのボックス間の通信のため、ネットワークパス208−1及び210を介したボックスとサーバ間の通信に対するバンド幅要求は低く、典型的には短時間に維持される。実質的に同時に多数のユーザボックスが再生リクエストを発行する場合、バックボーンパス210のバンド幅は顕著な又は厄介な遅延を回避するのに十分なものであるべきである。
【0049】
ボックス206−1,206−2,...,206−nの何れかにおいて提供されるライブラリにおいて利用可能なコンテンツは、1以上のコンテンツプロバイダによってもともと提供される。コンテンツプロバイダの具体例として、衛星受信機、テレビ中継ステーション、アナログ若しくはデジタル放送ステーション、映画スタジオ及びインターネットサイトがあげられる。実現形態に応じて、コンテンツはまずサーバ202において受信若しくは発信されるかもしれない。大規模なストレージ装置にコンテンツを維持及び管理する代わりに、サーバ202は、サーバ202により登録されている複数のローカルマシーンにコンテンツ若しくはファイルを分散するよう構成される。図2Aに示されるボックス206−1,206−1,206−2,...,206−nは、サービスを提供するローカルマシーンの具体例である。バックアップコピーが不要である場合、サーバ202は、何れの時点においてもコンテンツのコピーを保持する必要はない。他方、極めて要求の高いタイトルの完全なコピーをボックスに保持する特別な要求がなければ、サービスを提供するボックスの何れも発注までタイトルの完全なコピーを有しない。この結果、分散オブジェクトに埋め込まれたセキュリティによって、本発明の一部の実施例は、電子的な著作権侵害及び広範な配布(ハッキング若しくは不法な複製などによる)の懸念を軽減するかもしれない。
【0050】
便宜上、ここではタイトルに係るファイルが、当該タイトルがユーザにより選択及び発注されると再生されることが仮定される。タイトルが発注されると、対応するファイルが再生のため利用可能でなければならない。実施例は、それのサイズに関係なくファイル又は少なくともその一部に瞬時にアクセスすることを可能にするかもしれない。他の実施例によると、ファイルが平均して840メガバイトであり、ボックスが300ギガバイトの格納容量を有する場合、システムは任意の時点でのアクセスのため、タイトルの大きなライブラリに瞬時に提供するかもしれない。従来、タイトルのファイルが瞬時の再生を提供するため予め格納される必要がある場合、ボックスのローカルストレージは、4000ギガバイトの容量を有する必要があり、この結果、瞬時のVOSを経済的に非実現的なものにする。
【0051】
本発明の一実施例によると、ファイルの開始部分(“ヘッダ”と呼ばれる)とおそらく1以上のテールセグメントのみがボックスにローカルにキャッシュされる。このようなローカルにキャッシュされたセグメントは常駐オブジェクト(residing object)と呼ばれ、ローカルに常駐しないセグメントは分散オブジェクト(distributed object)と呼ばれる。あるタイトルが選択されると、対応するファイルのヘッダが即座に再生される。ヘッダ再生中、当該タイトルに対応する分散オブジェクトが他のボックスから同時に抽出される。ヘッダが終了すると、他のボックスからストリーミングされる分散オブジェクトの受信部分が、連続再生を可能にするため、存在する場合にはタイトルの常駐オブジェクトと合成される。あるタイトルの人気と同時になされる要求とに応じて、常駐オブジェクトの個数は、再生のための他のボックスに対する各ボックスの依存性を制御するよう増減されるかもしれない。典型的には、ボックスがタイトルの常駐オブジェクトを多く有するに従って、システム全体における当該タイトルの分散コピーは増加し、これにより、他のボックスに対する発注元のボックスの依存性を低下させる。
【0052】
一実施例では、ヘッダは瞬時の再生を保証するため常に最初に再生される。しかしながら、ボックスがファイルに対して複数の常駐オブジェクトを有するとき、ヘッダ以外の常駐オブジェクト(すなわち、常駐セグメント)が、他のボックスからダウンロード若しくはフェッチされた分散オブジェクト(すなわち、分散セグメント)と共に再生される。これらの常駐及び分散セグメントは、まとめてファイルの“セグメント”と呼ばれる。
【0053】
例えば、図2Aでは、ユーザがボックス206−1から再生用のタイトルを選択すると、ボックス206−1に常駐する対応するファイルのヘッダ207−1が即座にアクセスされる(ユーザが認証されており、及び/又は支払が決済されている場合)。この例では、ビデオファイルには4つのセグメントが存在するかもしれず、そのうちの2つは他のボックス(206−2、206−nなど)に分散されている。ヘッダの再生中、2つの分散セグメントが他方の2つのボックスからダウンロードされ、連続するコンテンツとして常駐セグメントと共にローカルにバッファリングされる。ヘッダが実行されると、連続するコンテンツが再生される。この結果、瞬時のVODが実現可能となる。
【0054】
図2Bの実施例を参照すると、ファイル220は、ヘッダ部分222と、4つのセグメント224から構成されるテール部分とに関して構成又は細分化されている。一般に、ファイル220は、要求される転送レート(良好な再生のための符号化及び復号化レートなどに関する)と、ネットワークの最小アップロード及びダウンロード能力とを考慮して、任意数のヘッダとセグメント部分に分割されるかもしれない。一実施例によると、要求される転送レート(毎秒1メガビット、すなわち、1Mbpsなど)が与えられると、ネットワークの最小のアップロード及びダウンロードスピードが、セグメントを規定する数と、特定のタイトルの同時になされる要求に対するサポート及び他のボックスへの依存性とを決定するよう考慮される。最小のアップロードスピードはUであり、要求される転送レートがDであり、D/U=K<k(ただし、kはKより大きな最小の整数である。)となることが仮定される。一実施例では、ダウンロードスピードがアップロードスピードの少なくともk倍の速さであると仮定すると、ファイルは好ましくは、Uのアップロードスピードを最適に利用するため、ヘッダとk個のセグメントに分割される。例えば、常駐エリアのためのPOTSベースDSLネットワークでは、要求される転送は約1.0Mbpsであり、アップロードスピードは約320kbpsである。従って、k=4となる。
【0055】
図2Cに示されるように、ファイル230は、1つのヘッダ232と4つのセグメント234〜237から構成される。図2Cは、ローカルボックスがヘッダ232のみを格納し、4つのセグメント234〜237を供給するため他の4つのボックスに依存する状況を仮定している。ローカルボックス239は、ヘッダ232の再生中、その他のボックスのアップロードスピードの4倍のダウンロードスピードを有すると仮定すると、これら4つのセグメントは、ローカルボックス239へのストリーミングとほぼ同時にネットワーク238を介し同時にダウンロードすることが可能である。
【0056】
図2Bに示されるように、ヘッダ232はファイルの開始部分であり、各セグメントはファイルの残りの間引かれた部分である。本実施例では、ヘッダのデータは連続的なものであり、それはヘッダ自体が再生可能であること意味し(例えば、当該タイトルの最初の15分間など)、セグメント部分234〜237は、ファイルのテール部分が再生可能となる前に一緒に提供されねばならない。図2Dは、ファイルを表すデータストリーム240を示す。ファイル240の開始部分はヘッダ242として割り当てられ、残りの部分は4つの“垂直の(vertical)”セグメント247〜250に分割される。これらのセグメント247〜250は、ファイルの残りの部分を間引くことによりそれぞれサンプリングすることによって生成又は形成される。
【0057】
残りの部分の正確なデータ長に応じて、各セグメント247〜250のn番目のデータブロックはファイルの残りの部分の連続する4つのデータブロックとなる。一実施例では、データブロックは、256キロバイト若しくは1メガバイトなどのデータのチャンクから構成される。図2Dに示されるように、データストリーム240の残りの部分は、b11,b21,b31,b41,b12,b22,b32,b42,b13,b23,b33,b43,...,b1n,b2n,b3n,b4nのようなデータブロックにより表現される。間引きサンプリングによって、残りの部分から取得される4つのセグメント247〜250は、それぞれ以下のように表現可能である。
【0058】
セグメント1={b11,b12,b13,b14,...}
セグメント2={b21,b22,b23,b24,...}
セグメント3={b31,b32,b33,b34,...}
セグメント4={b41,b42,b43,b44,...}
図2Dは、ファイルをヘッダ242と4つのセグメント247〜250に細分化する一例となる実施例を示す。ファイルの細分化方法は他にもある。例えば、ファイルをファイルのテール部分を表す複数の“垂直”セグメントに細分化する代わりに、1以上のセグメントが当該ファイルの音声部分を表すよう割り当てられてもよい。典型的には、映画は、その各々がある言語(英語、仏語、スペイン語など)のための複数の音声トラックを含む。この結果、すべてのセグメントは、必ずしも等しい長さとならず、再生をサポートするため同時に利用可能とならなければならない。この具体例は、タイトルのすべてのセグメントが当該タイトルを再生するために必ずしもフェッチされる必要がないことを示している(例えば、ビデオデータのためのすべてのセグメントと、1つの選択された音声トラックのための1つのみのセグメントなど)。他の例では、ファイル220は赤色、緑色、青色及び輝度の各値に関してセグメント化することが可能である。このため、セグメントの1つが欠落しても、画像は生成することが可能である。もちろん、赤色、緑色及び輝度のみから画像を形成することは、画質に影響を与えるかもしれない。このような場合、各色は、おそらく以前のフレーム若しくは他の基準に基づき推定される必要があるかもしれない。一般に、各ファイルは異なる個数のセグメントに細分化されるかもしれない。
【0059】
図2Eは、複数のボックスに分散化するためファイルを細分化するためのフローチャート若しくはプロセス260を示す。当該プロセス260は、メソッド、プロセス及び/若しくはシステムとして、又はソフトウェア、ハードウェア若しくはその両方により実現されてもよい。261において、プロセス260は、ボックスに分散するためファイルが細分化されるのを待機する。このようなファイルが利用可能になると、262において、ネットワークの最小アップロード及びダウンロードスピードと共に、要求される転送レートが取得される。一般に、異なるネットワークは異なるスピードを有する可能性がある。ファイルの細分化数を決定するため、ネットワークアップロード及びダウンロードスピードを有することは要求されていないが、ファイルの要求される転送レートの観点から、このようなスピードを知ることは、ネットワークスピード(又はバンド幅)を効率的利用するため、ファイルを細分化することを可能にする。
【0060】
264において、ファイルに対するセグメント数kが、262から取得された最小アップロード及びダウンロードスピードを含むいくつかのファクタと、適切な表示のための要求されるデータ転送レート(毎秒1メガビットなど)とを参照して決定される。一実施例では、実際のセグメント数は、ダウンロードバンド幅が十分である場合(要求される転送データレートより高い場合)、k+1などkより若干大きなものが選択される。後述されるように、エクストラセグメントがネットワーク若しくはボックスの不安定性を解消若しくは安定化させるための追加的な時間を提供するかもしれない。
【0061】
ファイルヘッダのサイズが、266において決定される。一般に、ヘッダサイズが大きくなると、ライブラリにおける利用可能なタイトルが少なくなる。一実施例では、ヘッダサイズは、連続的に残りの部分(分散オブジェクトにおける)の受信及び再生を保証するのに十分な長さになるよう決定され、あるいはおそらく、各オブジェクトがフェッチされるのを同期させ、不安定性を管理するための追加的な時間を含むようにしてもよい。他の実施例では、ヘッダサイズはサービス提供されるエリアの最小ネットワークスピードや、より高い転送レートに変換可能なシーンなどのいくつかのパラメータの関数として自動的に計算される。さらなる他の実施例では、ヘッダは、セキュリティ情報やコマーシャル情報の短い場面などの他の情報をボックスに転送するためのキャリアとして使用される。
【0062】
図2Eには、ファイルをセキュアにするための選択肢は示されていない。一実施例では、ファイルはコンテンツをプロテクトするための暗号によって、若しくは暗号化方式に従ってスクランブル化される。そこでは、ヘッダは、再生前に独立に解読されるかもしれない。ファイルが暗号化されているか、若しくは平文であるかに関係なく、それは同様に細分化することが可能である。ヘッダサイズが266において決定されると、ヘッダ部分が容易に生成される。それと同時に、ファイルの残りの部分はk個のセグメントに間引きされる。他の実施例では、ヘッダとこれらk個のセグメントの0以上とがサービスを提供する各ボックスに分散される。何れのボックスがセグメントを受信するか決定するための詳細が以下で説明される。何れのケースでも、ヘッダとセグメントは分散前にセキュア化されてもよい。270において、あるタイプのセキュリティがヘッダとセグメントに埋め込まれるようにしてもよい。実現形態に応じて、ヘッダとセグメントはそれぞれ、暗号化方式若しくは暗号(Data Encryption Standard(DES)アルゴリズム、Blowfishブロック暗号、Twofish暗号、RC−4など)に従ってそれぞれ暗号化されてもよく、及び/又はデジタル著作権管理(DRM)によりプロテクトされるようにしてもよい。
【0063】
274において、ヘッダとセグメント(すなわち、各パッケージ)とが、サービスを提供する各ボックスに分散される。本発明の一実施例によると、この分散化は、ボックスからボックスにデータのチャンクとして各パッケージを伝搬させることによって同期的若しくは非同期的に実行される。その詳細が以下に説明される。ボックスは、セグメントの1つ、複数若しくはおそらくすべてを受信するよう選択されてもよい。274の後、プロセス260は他のファイルに対して261に戻る。
【0064】
一実施例は、ユーザに提供される多数のタイトルを有する動的に更新されるライブラリを可能にする。各タイトルは、瞬時の再生のため選択及び順序付けされるかもしれない。定期的に更新され(毎日など)、任意の時点に瞬時にアクセス可能な5000タイトルなどを有する大きなライブラリが与えられると、そのうちの一部のタイトルは他のものより人気があり、より多くのユーザによってより頻繁に要求されるかもしれない。人気のあるタイトルを調達するためボックスの可能なバンド幅の問題若しくは利用不可を最小限にするため、常駐オブジェクト及び分散オブジェクトの提供は、例えば、人気、地理、人口及び/又は同様の基準などに従ってインテリジェントに実行されるべきである。
【0065】
図3Aは、ボックスの限られた格納スペースへのライブラリのタイトルの一例となる人気による分類を示す。便宜上、格納スペース300は300ギガバイトの容量を有し、瞬時の再生のため5000タイトルが利用可能であることが仮定される。5000タイトルのうちの何れかは、再生のため選択され、瞬時にアクセスされるかもしれない。VODアプリケーションのため、各映画は平均的には約2時間であることが仮定される。大部分のユーザに受入可能な表示品質のためには、2時間の映画のファイルは約840メガバイトのサイズとなる。約30メガバイトのヘッダに対して、4つのセグメントのそれぞれは、各ファイルのサイズが平均に近いものであると仮定すると、約203メガバイトとなると推定される(すなわち、(840メガバイト−30メガバイト)×1/4)。従って、格納スペース300は、図3Aに示されるような分散化のため5000タイトルを収容するため、約240ギガバイトとなることが推定される(すなわち、5000タイトル×30メガバイト+50タイトル×2セグメント×203メガバイト+50タイトル×2セグメント×203メガバイト+4900タイトル×セグメントの5%×203メガバイト=240ギガバイト)。
【0066】
図3Aの実施例によると、これら5000タイトルは2つのバンドに分割され、上位バンド302は、新たにリリースされた若しくは人気のあるタイトルのためのものであり、下位(L)バンド304は、比較的に人気がないが、ときどき要求されるタイトルのためのものである(例えば、007のJames Bondやマイナーなディズニー映画など)。ライブラリが5000タイトルを有する場合、上位バンド302は100タイトルを収容するよう割り当てられ、低バンド304は残りの4900タイトルを収容するよう割り当てられるようにしてもよい。新たなタイトルがリリースされ、上位バンドに追加される毎に、上位バンド302にすでにあるタイトルは破棄若しくは低バンド304に移される。他の実施例では、上位バンドはさらに2つのバンドに分割されてもよく、高バンド(H)は最新の50タイトルなどのため、中バンド(M)はやや古い次の50タイトルのためのものである。
【0067】
中バンド(M)の割当ては、上位バンドにおけるタイトルのフレキシブルな管理を実現する。映画レンタルビジネスにおける収入の70%以上が上位バンドのタイトルからのものであり、その収入の40%以上が高バンド(H)のタイトルからのものであることが推定される。さらに後述されるように、より多くのリソースを高バンドのタイトルを迅速に更新するよう割当てるため、又は他のボックスの高バンドのタイトルの依存性を低減するため、中バンド(M)のタイトルのセグメント数は減少するか、又は中バンド(M)のタイトルのあるパーセンテージのみが1以上のセグメントによりキャッシュされるかもしれない。
【0068】
本実施例では、H、M及びLバンドにそれぞれ50、50及び4900タイトルが存在する。一般に、ボックスが十分長い期間サービス提供していたとき、上位バンド302の各タイトルは、ヘッダと1つ若しくは2つの対応するセグメントにより提供され、Lバンドの各タイトルは、ヘッダとセグメントの一部により提供される。Lバンドのタイトル毎のセグメント数に関する限り、そこにおけるタイトルのあるパーセンテージのみが各タイトル毎に1つのセグメントにより提供され、これらのタイトルは、典型的には、ボックス毎に異なっている。上位バンド302のタイトルに対する要求がLバンド304のタイトルよりはるかに大きいため、Lバンドのタイトルに対するボックスにおけるセグメントのパーセンテージは、5%などの比較的小さな値に設定されてもよい。Lバンドのタイトルのセグメントの分散化は、常にシステムにこれらのタイトルの少なくとも1つの分散コピーと、上位バンドのタイトルのより多くの分散セグメントがあるように行われる。他の観点から、上位バンド302のタイトルが選択されると、発注元のボックスのタイトルの再生をサポートするため、分散セグメントを供給するよう指定されるより多くのボックスがあり、これにより、他のボックスが欠落したセグメントを供給するのに利用不可となる可能性を低減することができる。低バンドタイトルが選択された場合、相対的に低い人気のため、ネットワークにおいて利用可能な十分な分散コピーが存在する可能性が高く、これにより、他のボックスが再生のための各セグメントを供給するよう指定することが可能である。
【0069】
動作について、Hバンドのタイトルがボックスにおいて選択された場合、そのセグメントの2つが当該ボックスにすでに常駐している。従って、これら2つの欠落したセグメントを供給するため、他に2つのボックスしか必要でない(すなわち、依存性=2)。Lバンドのタイトルが選択されると、多くの場合、4つのセグメントを供給するため、他に4つのボックスが必要とされる(すなわち、依存性=4)。すなわち、タイトルの人気は、発注元のボックスの他のボックスへの依存性を決定する。あるタイトルの人気が高いほど、発注元のボックスの他のボックスへの依存性は低くなる。
【0070】
上述されるように、ライブラリは定期的に(毎日、毎週など)更新される。新たなタイトルが受け付けされる毎に、この新たなタイトルは、典型的には、Hバンドに追加される。一実施例では、H、M及びLバンドに相対的に固定された個数のタイトルを維持することが所望され、Hバンドの相対的に人気の低いタイトルがMバンドに移され、Mバンドの最も古いタイトル若しくは相対的に人気の最も低いタイトルがLバンドに移される。他方、まれにではあるが、Lバンド若しくはMバンドのタイトルがより上位のバンドに昇格することも可能である。あるタイトルがMバンドからLバンドに移されるときは常に、Lバンドの最も古い若しくは相対的に最も人気の低いタイトルが破棄されるかもしれない。図3Aによると、あるタイトルが上位バンド302からLバンド304に移されるときは常に、上位バンド302の1つ又は両方のセグメントが、当該タイトルが1つのセグメントを維持するため指定されるパーセンテージの範囲内であるか否かに応じて欠落される。
【0071】
一般に、ライブラリを更新するため、1日に複数のタイトルがリリースされる。しかしながら、これらのタイトルのすべてが必ずしも新たなタイトルではなく(すなわち、上位バンドのための)、その一部は大変人気が高く、他のものはあまり人気がない。例えば、ライブラリが1日に10タイトルにより更新され、そのうちの1つは、上位バンドにおいて新たにリリースされたタイトルであり、9つはLバンドにおいて人気の低いタイトルである。当該タイトルが上位バンドに追加されると、対応する2つのセグメントがまた追加され、それと同時に、上位バンド(おそらくMバンド)の比較的古いタイトルが破棄若しくはLバンドに移されるかもしれない。Mバンドからの比較的古いタイトルは、上記9つのタイトルと組み合わされてもよく、これら10個のタイトルの何れが、それの1つのセグメントがあるボックスに対してローカルにキャッシュされると仮定されるパーセンテージ(5%など)に属するか決定される。
【0072】
当該実施例では、各ボックスは、利用可能なタイトル毎に1つである5000個のヘッダをキャッシュしている(おそらく、サイズについては同じ若しくは異なり、フォーマットについてはおそらく異なり、利用されるセキュリティについてはおそらく異なるなど)。これらの常駐オブジェクトは、ユーザがタイトル発注時に瞬時に再生を開始し、他のボックスからの分散オブジェクトの受信を開始するのに十分な長さの再生を続けることができることを保証する。セグメントの分散化の説明を容易にするため、4つのセグメントはそれぞれ1、2、3及び4とラベル付けされる。上位バンド302のタイトルについては、2つのセグメントがローカルに分散され、他のボックスに2つのセグメントが分散されている。この結果、ローカルに格納されているセグメントについて、(セグメント1,セグメント2)、(セグメント1,セグメント3)、(セグメント1,セグメント4)、(セグメント2,セグメント3)、(セグメント2,セグメント4)、(セグメント3,セグメント4)の6つの可能な組み合わせが存在する。これらの組み合わせは、サービスを提供するボックス間に等しく分散されている。発注元のボックスがセグメント1とセグメント2を有する場合、第1の他のボックスと第2の他のボックスが、セグメント3及びセグメント4をそれぞれ発注元のボックスに提供するため呼び出される必要がある。セグメント3又はセグメント4を有するボックスが、第1の他のボックス若しくは第2の他のボックスであるかもしれない。例えば、(セグメント1,セグメント3)を有するボックスと、(セグメント1,セグメント4)を有する他のボックスとが、それぞれ第1の他のボックスと第2の他のボックスであるかもしれない。
【0073】
一実施例では、各ボックスはいくつかのタイプに分類される。例えば、6つのタイプのボックスが存在し、各タイプは上述した6つの組み合わせの1つを格納するため指定されている。各ボックスの対応するヘッダに加えて、Hバンドに50タイトルがある場合、これら50タイトルのそれぞれのセグメントは、6つの組み合わせの1つに従って分散される。
【0074】
Lバンドのタイトルに対して、各ボックスは当該タイトルの5%の1つのセグメントを格納する。Lバンドのタイトルの1つが発注されると、当該ボックスはローカルにキャッシュされたセグメントを有しているかもしれないし、そうでないかもしれない。従って、Lバンドのタイトルのセグメントの分散化は、サービスを提供しているボックスが一緒になってすべてのタイトルのすべてのセグメントを有することを保証する必要がある。すなわち、Lバンドの各タイトルの少なくもと1つのコピーがネットワークに存在している必要がある。
【0075】
サービスを提供しているボックスの間にLバンドのタイトルのセグメントを分散させる方法がいくつかある。一実施例によると、Lバンドのタイトルのセグメントの分散化を管理するため、Hバンドのタイトルのセグメントの分散化が参照される。例えば、Hバンドのタイトルのセグメント1とセグメント2がローカルに格納されているとき、Lバンドのタイトルのセグメント1又はセグメント2がローカルに格納される。(上位バンドから低バンドへのタイトルの移行時に、ボックスはセグメントの1つを破棄すればよいためである。)従って、分散化の以下の管理が成り立つ。
【0076】
【表1】
【0077】
Lバンドの何れのタイトルが特定のボックスの選択されたパーセンテージの範囲内に属するかの判断は、いくつかのファクタに基づき決定されるかもしれない。一実施例では、このパーセンテージは、タイトルの経過時間若しくは人気の潜在的にランダム化された関数として決定される。他の実施例では、このパーセンテージは、あるエリアにおける所望される言語及び視聴行動の統計と、他のボックスからの分散オブジェクトの抽出をより効率的に実現することを可能にする他の指標とに基づき決定される。さらなる他の実施例では、当該パーセンテージは、
1.ユーザがボックスからこれまで視聴したプログラム(映画など)のセット
2.ユーザがボックスについて評価した(1〜10のスケールなどにより)プログラム
3.以降の視聴のためユーザにより作成された選好リストに関するプログラム
4.ブラウジング動作(例えば、ユーザが視聴した予告、タイトルの簡単な紹介を読むのにユーザが費やした時間など)
の一例となるリストの一部若しくはすべてを動的に記録したボックスに埋め込み可能な学習エンジンから決定される。
【0078】
この学習エンジンは、映画などの何れのプログラムがユーザが視聴したものと類似しているか示すための統計を提供するよう起動されるかもしれない(例えば、俳優、監督、ジャンルなどに関して)。これにより、これらの映画は、対応するセグメントを有するタイトルのパーセンテージの範囲内となるよう選択される。さらに、何れの映画のペアが類似しているかについての判断は、“協調フィルタリング”と呼ばれるものに基づき行われ、すなわち、多数のユーザがある映画ペアを視聴することを好む場合、これら2つの映画は類似しているとみなされるかもしれない。従って、ボックスにおいておそらく選択及び発注されるものと類似したさらなる映画が、当該パーセンテージのタイトルに追加されるかもしれない。何れの場合にも、ボックスは、当該ボックスを介しユーザにより選択及び発注される可能性が高いタイトルに係るセグメントをキャッシュするかもしれない。他の実施例では、各映画は、特定の属性によって規定されるかもしれない。ユーザ行動は、特定の属性のユーザの嗜好を示すかもしれない。選好される属性と映画属性とをマッチングすることによって、学習エンジンは、1つのバンドのタイトルの何れのセグメントが各ボックスに格納すべきか判断するかもしれない。また、類似するが異なるユーザの間で比較をすることが可能である。例えば、第1ユーザがアクションベースの映画を選好し、以前に映画X、Y及びZを発注しており、第2ユーザがアクションベースの映画を選好する場合、学習エンジンは、第2ユーザのボックスに映画X、Y及びZXのセグメントを格納しようとするかもしれない。
【0079】
図3Bは、ボックスの限られた格納スペース内のライブラリのタイトルの他の一例となる人気による分類を示す。図3Aと図3Bとの間の主要な相違点の1つは、図3Aの上位バンド302が各タイトルの1つのヘッダと2つのセグメントを保持し、図3Bの上位バンド310が各タイトルの1つのヘッダと1つのセグメントを保持していることである。
【0080】
図3A若しくは図3Bとは反対に、一実施例によると、サービスを提供するすべてのボックスは、Hバンドに1以上のタイトルのための2より多くのセグメントを有するよう構成されるかもしれず、これにより、これらの強く要求されるタイトルの分散コピーの個数を実質的に増加させる。あるタイトルが新たにリリースされ、若しくは統計的に人気があると判断されると、サービスを提供しているボックスは、発注元のボックスの他のボックスへの依存性が大きく低減するように、これらのタイトルのセグメントの個数を増加させるよう動作可能である。
【0081】
図3Cは、ライブラリのタイトルの人気に従う他の一例となるバンド化方式を示す。このバンド化方式は、ライブラリのタイトルを複数のバンド(5バンドなど)に分割する。曲線320は、A、B、C、D及びEの各バンドを示し、Aバンドは最も人気の高いタイトルを示し、Eバンドはライブラリにおいて相対的に最も人気の低いタイトルを表す。各バンドにおいて利用可能なタイトルは、例えば、要求統計、地理的位置、所望される言語、タイトルの古さ、人口統計情報などからの1以上の指標に従って定期的に更新されてもよい。各ボックスは、Aバンドのタイトル(例えば、1つ又は2つの新たにリリースされたタイトルなど)のヘッダと対応するセグメントのすべてを格納する。各ボックスは、Bバンドのタイトルのヘッダと3つのセグメントをローカルに格納する。各ボックスは、Cバンドのタイトルのヘッダと2つのセグメントをローカルに格納する。各ボックスは、Dバンドのタイトルのヘッダと1つのセグメントとをローカルに格納する。さらに、各ボックスは、Eバンドのタイトルのうちの5%などの小さなパーセンテージのヘッダと1つのセグメントとを格納する。この結果、図3Dに示されるテーブル326にリストされるような連続再生のためのバンドの各タイトルの依存性は、それぞれ0、1、2、3及びおそらく4となる。
【0082】
完全性のため、テーブル326はまた、各バンドのタイトルに対する要求の一例となる統計を示すカラム328を有し、すなわち、バンドAのタイトルに対する要求は、ライブラリに対するリクエスト全体の約60%となると予想される。バンドB、C、D及びEのタイトルに対する逓減する要求は、20%、10%、8%及び2%として示される。バンドAのタイトルに対する要求が大きいかもしれないが、バンドAのタイトルに対する他のボックスへの発注元のボックスの依存性はゼロとなる。従って、バンドAのタイトルに対する注文は、ローカルに実現することが可能となる。他方、バンドB、C、D及びEのタイトルに対する要求は徐々に低下する。従って、バンドB、C、D及びEにおける発注元のボックスの依存性は徐々に増加する。バンドB、C、D及びEのタイトルの分散コピーは徐々に減少する。
【0083】
図3C及び3Dを参照して上述したバンド化方式は、タイトルの人気に従って規定された個数のセグメントに対して任意数のバンドに論理的に拡張されるかもしれない。例えば、各ボックスがバンドのタイトル毎に平均して2.5セグメントを格納する上述の具体例において、バンドBとバンドCとの間にあるバンドB’を導入してもよい。このような平均セグメント数を生成及び制御する1つの方法は、半数のボックスに2つのセグメントを格納し、半数のノードに3つのセグメントを格納するものである。極端な例では、各タイトルは、異なる個数のセグメントを有するだけでなく、各ボックスはまた、各タイトルに対していくつのセグメントをローカルにキャッシュするか独立に決定するかもしれない。一般に、あるタイトルの人気が高くなるに従って、より多くのセグメントがローカルにキャッシュされ、より多くの分散コピーがネットワークにおいて利用可能になる。何れの場合でも、ライブラリのタイトルが何れのセグメントもローカルにキャッシュされないとき、ネットワークに対応するすべてのセグメントの少なくとも1つのコピーが存在していなければならない。そうでない場合、このようなタイトルに対する注文は提供できなくなる。
【0084】
図3Eは、瞬時のアクセスのためタイトルのライブラリを分類するフローチャート又はプロセス360を示す。当該プロセス360は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/若しくはシステムとして実現されるかもしれない。当該プロセス360がVODシステムにおいて使用されるとき、タイトルに係るファイルは、図2Eのプロセス260に従ってヘッダと1以上のセグメントに細分化されるかもしれない。362において、これらのタイトルに係るファイルがいくつ分散化されるべきか決定する必要があり、これにより、各ライブラリに格納されるタイトル数を規定することが可能となる。一般に、ライブラリにおいて利用可能なタイトル数は、ボックス内の格納スペースの容量、ヘッダサイズ、ネットワークスピード、要求、ファイルサイズ、要求されるデータ転送スピード、同時サポートなどを含むいくつかのファクタの関数である。一実施例では、5000個のタイトルがライブラリにおいて提供可能であると判断され、各タイトルは、平均して2時間であり、840メガバイトから1ギガバイトのサイズを有する。図2Eのプロセス260は、ファイルの細分化を決定するのに利用可能である。バンド数が決定されると、プロセス360は364に移行する。
【0085】
364において、これらのタイトルが各バンドに分類される。少なくとも2つのバンドが利用され、上位バンドは最も人気のあるタイトル(新たなリリースなど)のためのものであり、低バンドは相対的に人気の低いタイトルのためのものである。実現形態に応じて、上位バンドにも低バンドにも適合しないタイトルを格納し、ライブラリの更新を実現するため、1以上の中間バンドが導入されてもよい。上述されたように、同時発注に適応するため、他のバンドのものより上位バンドのタイトルの分散コピーがより多くされる。動作について、上位バンドのタイトル数は、好ましくは、ボックスの格納スペースの利用を最適化するよう小さく維持される。
【0086】
366において、各バンドのセグメント数が決定される。一実施例によると、上位バンドのタイトルのセグメントがより多くローカルにキャッシュされ、より多くの分散コピーをネットワークにおいて利用可能にする。この結果、より人気のあるタイトルに対して、発注元のボックスは、当該タイトルの連続的な再生に必要とされるセグメントを供給するため、他のボックスにあまり依存しなくなる。他方、低バンドのタイトルのあるパーセンテージのみがローカルにキャッシュされ、ネットワークにおいて利用可能な分散コピーがより少なくされる。システムが中間バンドを有するよう構成される場合、ローカルにキャッシュされるセグメント数は、上位バンドから徐々に減少するかもしれない。
【0087】
368において、プロセス360は、セグメントをキャッシュするボックスを決定する。実現形態に応じて、セグメント分散方式は、タイトルの効率的な格納と効果的な調達のためにセグメントキャッシュ処理を最適化するため、異なるファクタに基づくかもしれない。一実施例では、セグメントの分散化は、視聴行動に基づき決定される。ユーザの視聴行動を調べることによって、何れのボックスがあるタイトルを発注する可能性が高いか統計的に決定されるかもしれない。例えば、アクション映画を頻繁に発注するユーザは、他のアクション映画を発注する可能性が高い。アクション映画のタイトルに係るセグメントを分散させるとき、当該分散化は、これらのセグメントがアクション映画を発注する可能性が統計的に高いボックスになされることを保証するよう調整されるかもしれない。他の実施例では、分散化は、所望される言語に基づくかもしれない。スペイン語など所望される言語によるタイトルに係るセグメントの分散化は、このようなセグメントが所望される言語により映画を発注する可能性が統計的に高いボックスになされるように行われるかももしれない。
【0088】
図3Fは、ボックスのライブラリを更新するフローチャート又はプロセス380を示す。プロセス380は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されるかもしれない。プロセス380がVODシステムに使用されるとき、タイトルに係る大きなファイルが、図2Eのプロセス260に従ってヘッダと複数のセグメントに細分化されるかもしれない。各ボックスのライブラリは、定期的に又は所定の時間に更新される。プロセス380は、サービスを提供するすべてのボックスが利用可能なタイトルに関して同期されるように、ライブラリを動的に更新するのに利用されるかもしれない。
【0089】
382において、プロセス380は、リリースを待機する。後述されるように、リリース(1以上のタイトルから構成される)は、サーバ(図2Aのサーバ202など)から直接的に提供されてもよく、又は他のボックスから伝搬されてもよい。リリースの各タイトルは、ヘッダといくつかのセグメントに細分化される(例えば、図2Eのプロセス260などによって)。ヘッダと4つのセグメントとに細分化されたタイトルについて、(ヘッダ,セグメント1,セグメント2)、(ヘッダ,セグメント1,セグメント3)、(ヘッダ,セグメント1,セグメント4)、(ヘッダ,セグメント2,セグメント3)、(ヘッダ,セグメント2,セグメント4)、(ヘッダ,セグメント3,セグメント4)のボックスが所望する(ヘッダと2つのセグメントを要求するタイトルに対して)可能性のある6つのリリースパッケージが存在する。これらのリリースパッケージの少なくとも1つが、ボックスにおいて受信される。
【0090】
一実施例では、リリースが利用可能であるというメッセージ若しくはデータセットをサーバ若しくはボックスから受信すると、プロセス380が開始される。384において、リリースパッケージに従って、リリースの各タイトルに適したバンドが決定される。上述されるように、当該タイトルは何れかのタイプに係るものであるかもしれない(高バンド若しくは低バンドなど)。従って、タイトルを収容するのに適したバンドが決定される。バンドに所定数以上のタイトルが収容されることを回避するため、好ましくは、バンド内の既存の相対的に人気の最も低いタイトルがバンドから排除される。386において、このようなバンド内の相対的に最も人気の低いタイトルが決定される。一実施例では、リリースに関する受信メッセージは、何れのバンドの何れの既存のタイトルが破棄若しくは低バンドに移されるべきか示す。388において、当該タイトルが、それに係るヘッダと対応するセグメント(それはないかもしれない)とをボックスにおいて受信することによって、割り当てられたバンドに追加される。
【0091】
390において、ボックスのライブラリリストが更新される。実現形態に応じて、ライブラリリストは、排除されたタイトルを削除し、新たなタイトルを追加することによってローカルに更新されるかもしれず、又は更新されたライブラリリストが受信されるかもしれない。この結果、排除されたタイトルは、もはや利用可能でなく、新たなタイトルが注文可能となる。
【0092】
図4Aを参照すると、サービスを提供するすべてのボックスのライブラリを更新する図400が示される。サーバ(図2Aのサーバ202など)がライブラリを更新すると、すべてのボックスのライブラリがこれに呼応して更新される。一実施例によると、更新プロセスは同期的に及び/又は非同期的に実行される。
【0093】
サーバ402は、ヘッダとセグメントによりタイトルのリリースに係るファイルを準備するよう構成される。ファイルを準備する一例となる方法は、図2Eのプロセス260である。便宜上、ヘッダと4つのセグメントが存在することが仮定される。従って、上述されるように、何れのバンドにリリースが配備されるかに応じて、複数のリリースパッケージが存在するかもしれない。動作について、サービスを提供する各ボックスは1つのリリースパッケージを受信するよう構成される。
【0094】
まず、サーバは、リリースに関するメタデータ、ライブラリから破棄されるべき最も人気の低いタイトル及び/又はタイトル移転を含むリリース命令を準備する。当該命令は、何れのボックスが何れのリリースパッケージを取得し、パッケージが何れの方法により受信されるべきか(すなわち、他の何れのボックスから)を記述するかもしれない。例えば、この命令は、特定の特性を示す識別子によって特定されるボックスがリリースパッケージXを受信すべきか指定することが可能である。一般にすべてのリリースに適用されるデフォルト命令があり、また特定のリリースに適合された命令があるかもしれない。リリースパッケージをボックスに割り当てる目的の1つは、同一若しくは異なるセグメントを保証するため、サービスを提供するすべてのボックスに等しくパッケージを分散することであるかもしれない。
【0095】
リリース命令は、サーバによって準備されると、サーバとボックスとの間の直接的な通信を介して、又は後述されるgossipプロトコルを介した命令のボックスからボックスへの伝搬によってサービスを提供するボックスに伝搬される。何れの場合にも、各ボックスが、それがあるリリースパッケージを受信する必要性を認識していることが仮定される。
【0096】
リリースは、当該リリースに対するヘッダとセグメントとを表すデータチャンク403のシーケンスに変換される。データチャンクは、サーバからボックスへの若しくは2つのボックス間のデータ転送の最小単位である。例えば、各データチャンクは、1メガバイトのサイズを有し、一意的に特定されるかもしれない。データチャンク403のシーケンスは、ライブラリを更新するためボックスに伝搬される2つの別個のタイトルを表すかもしれない。一般に、各ボックスは、当該ボックスに対応する適切なリリースパッケージを構成するデータチャンクの特定のサブセットを所望する。さらに、リリース命令自体は、すべてのボックスに伝搬される1以上のデータチャンクとして表されてもよい。
【0097】
動作について、サーバ402は、ボックス群404−1,404−2,...,404−nとの各通信を開始し、各ボックスに当該ボックスによって要求されるデータチャンクのいくつかを提供する。好ましくは、各データチャンクは、サーバ402により少なくとも1つのボックスに提供される。データチャンクを最初に受信するボックス404−1,404−2,...,404−nの正確な個数は、分散化を制限しない。一実施例では、ボックス404−1,404−2,...,404−nの指定は完全にランダムである。他の実施例では、ボックス404−1,404−2,...,404−nの指定は、時間帯、地理的位置、利用可能なネットワーク帯域幅及びその遅延、ボックスのインターネットサービスプロバイダなどの1以上に基づく。何れの場合も、サーバがアイドル状態であるときは常に、サーバ402は常時データチャンクを受信する異なるボックスを指定することが可能である。
【0098】
各ボックス404−1,404−2,...,404−nは、“gossipプロトコル”と通常呼ばれている、アプリケーションレイヤマルチキャスト形式のプロトコルに基づき、サービスを提供する他のボックスにデータチャンクを拡散するよう構成される。ボックス404−1,404−2,...,404−nの全てが同一のデータチャンクを受信している必要がないことに留意すべきである。ボックス404−1,404−2,...,404−nの何れも、それがデータチャンク全体を受信するとすぐに、データチャンクを他のボックスに拡散することを開始するようにしてもよい。動作について、ボックス404−1は、それの受信したデータチャンクの少なくとも一部を、同時に互いの通信するボックス406−1,406−2及び406−3に伝搬するよう割り当てられる。ボックス404−2は、それの受信したデータチャンクの少なくとも一部をボックス406−2及び406−3に伝搬するよう割り当てられる。ボックス406−2は、データチャンクを自らに供給するよう構成されるボックス404−1、404−2及び他の何れかのボックスから何れのデータチャンクを取得するかについて正確に知っているよう構成される。さらに、ボックス406−2は、それが受信したデータチャンクの少なくとも一部をボックス408−1、408−2及び408−3に伝搬するよう割り当てられる。データの伝搬は必ずしも階層的である必要はないことに留意されたい。例えば、ボックス408−1は、図示されるように、データチャンクを後方の406−1に送信するようにしてもよい。
【0099】
一実施例では、データチャンクは、無駄なデータ転送を回避するため、特定のチャンクを実際に所望するボックスのみに伝搬される。さらに、ボックスがすでにデータチャンクを有しておらず、何れかから当該チャンクをダウンロードするプロセスにいない場合に限って、データチャンクがボックスに伝搬されることを保証することによって、無駄なデータ転送が回避されるかもしれない。チャンクの伝搬は、すべてのボックスが協調的に同時に参加する同期プロトコルを通じたものであってもよく、又は各ボックスが参加すべき時とどのくらいの期間参加するかフレキシブルに選択可能な非同期プロトコルを通じたものであってもよい。例えば、ボックスは、それが発注元のボックスに対する映画のサービス提供に忙しいときは常に、又はネットワークがその使用量が大きいと検出されたとき、チャンクのダウンロード及び伝搬への参加を中止するようにすることができる。ボックスは、ネットワーク状態を連続的に監視し、十分な帯域幅が利用可能であるときは、適応的にgossip伝搬に再参加するようにしてもよい。
【0100】
動作について、何れかの理由によりボックスの何れか1つがデータチャンクの受入に失敗した場合、供給元若しくは代替ボックスがデータチャンクを送受信するよう構成可能であるときは当該ボックスを外すことができる。リリースを欠いたボックスは、1以上の更新されたボックスから以降に当該データをフェッチするようにしてもよい。ボックス・アフター・ボックス(boxes after boxes)を介しデータチャンクを繰り返しかつ再帰的に伝搬することによって(すなわち、同期的及び/又は非同期的にプル若しくはプッシュすることによって)、最終的には、サービスを提供するすべてのボックスに各リリースが存在することとなる(追加されるべきすべてのタイトルのヘッダ及び指定されたセグメントと、削除されるべきタイトルの識別)。
【0101】
更新終了後、何れのボックスが何れのセグメントを有するか示すマップ409を構築することができる。マップ409によって、発注元のボックスから注文が受信される毎に、サーバは、ローカルにキャッシュされていないセグメントを発注元のボックスに供給するため、適切なボックスを指定することができる。あるいは、マップ409は、ボックスが注文を実現するため、必要とされるセグメントをフェッチするためのソース情報を取得することを可能にする。
【0102】
リリースが上位バンドに対するものでないとき、何れのボックスが何れのセグメントを保持すべきかの判断は、必要に応じてボックス間のセグメントを転送効率を最大化するため、地理的位置、時間帯、視聴行動若しくは選好される言語などの複数のファクタに基づくものであってもよい。
【0103】
利用可能なタイトルのリストからのタイトルの削除は最初にボックスに配布されるかもしれないということが理解されるべきである。このようにして、何れのボックスももはや利用可能でないタイトルを発注しないようになる。タイトル削除命令の配信は、上述したgossipプロトコルを用いて実現されてもよく、又は直接的なボックスからサーバへの通信によって提供されてもよい。
【0104】
図4Bを参照すると、サービスを提供するボックスにリリースを提供するフローチャート又はプロセス410が示される。当該プロセス410は、中央サーバを使用することなく複数の一に維持されているディレクトリを更新するのに特に有用である。プロセス410の可能な特徴及び効果の1つは、複数の位置におけるディレクトリが、アプリケーションレイヤマルチキャスト系のgossipプロトコルによって、場所から場所を介しデータチャンクの更新を伝搬することによって、同期的に及び/又は非同期的に更新されるということである。プロセス410がVODシステムに使用されるとき、多数のタイトルを有するライブラリが、同時更新をサポートするのに高帯域幅を要求することなく、動的に又は効率的に更新されるかもしれない。
【0105】
412において、プロセスは、データネットワーク上の装置(サーバプロバイダによるサーバなど)において利用可能なるリリースを待機する。リリースが利用可能になると、リリースに係るファイルが、ボックスへの配信のため414においてサーバに準備される。図2Eのプロセス260は、各ファイルに対してヘッダと対応するセグメントへの細分化のための一例となるプロセスであってもよい。
【0106】
416において、ヘッダ及びセグメントはデータチャンクに分割される。418において、サーバは、データチャンクの少なくとも一部を受信する初期ボックス群を指定する。一実施例では、これらのボックスは、同一のデータチャンクを受信しなくてもよい。実現形態に応じて、サーバは、各データチャンク群を初期ボックスにプッシュし、又は初期ボックスがサーバから各データチャンク群をプルするようにしてもよい。いくつかの実施例では、すべてのデータチャンクのコピーが初期ボックスに配信され、これにより、初期ボックスはサーバとのさらなるやりとりなくシステムのその他のボックスに提供することが可能となる。
【0107】
420において、プロセス410は、何れのボックスが何れかのデータチャンクを受信することができなかったか判断する。データチャンクを受信しないボックスがある場合、プロセスは422に移行し、初期ボックス群に属しないボックスが失敗したボックスに置換される。この結果、少なくとも1つの完全なデータチャンク群が、提供するボックス群に同期的又は非同期的に配信されるかもしれない。
【0108】
その後、プロセス410は424に移行し、提供する各ボックスは、受信したデータチャンクの少なくとも一部を1以上の他のボックス(物理的に近い他のボックス群など)に拡散するよう構成され、他の各ボックスは、それが受信したデータチャンクの少なくとも一部を他のボックスにさらに拡散するよう構成される。データチャンクをまとめてフェッチするため、何れのボックスも同時に複数のボックスと通信するようにしてもよいということが留意されるべきである。プロセス410は、その後に他のリリースを待機する412に戻る。
【0109】
動作について、プロセス410は、1回に1つのタイトルによりライブラリを更新することに限定されるものでない。タイトルをデータチャンクに変換することによって、複数のタイトルが、ボックス間でデータチャンクを非同期的に伝搬することによってシステムに拡散されるようにしてもよい。また、プロセス410は、他のタイトルが配信可能になるまでに終了している必要はない。1つのリリースがサービスを提供するボックスに完全に提供されるまで、他のリリースが配信可能とされてもよい。動作について、プロセス410は、好ましくは、真夜中などのネットワークトラフィックが低いときに開始される。典型的には、プロセス410は、終了するのに数時間かかるかもしれない。
【0110】
図4Dは、ブロードキャスト又はマルチキャストのためサービスプロバイダに1以上の高帯域幅チャネルが提供される構成に対してサービスを提供するボックスにリリースを提供するフローチャート又はプロセス440を示す。このような構成は、超高速ブロードキャスト又はマルチキャスト能力を享受するケーブル又は衛星インフラストラクチャにおいて、又はマルチキャストサポートを有するデータネットワークにおいて見出されるかもしれない。プロセス410は、好ましくは図4Cに関して理解され、ボックスには受信機能(チューナなど)が備えられ、放送を受信するための適切なチャネルにチューニングされることが仮定されるボックスのライブラリを1以上のタイトルにより更新するためのインフラストラクチャを利用する。このようなボックスの具体例として、衛星受信ボックスやケーブルセットトップボックスがあげられる。
【0111】
図4Cに示されるように、サーバ432が、ケーブルネットワーク(すなわち、媒体としての同軸ケーブルやファイバ)又は衛星ネットワーク(すなわち、伝送媒体としての大気)であるかもしれないネットワークに接続される。図4Aのサーバ402と同様に、サーバ432はリリースを配信するためのものである。442において、プロセス440はリリースを待機する。プロセス440は、リリースが利用可能になると開始される。442において、リリースに係るタイトルがボックスへの配信のためサーバ432において準備される。図2Eのプロセス260は、各タイトルのヘッダ及び対応するセグメントへの細分化のための一例となるプロセスである。
【0112】
446において、すべてのタイトルに対するヘッダとすべてのセグメントを含むリリースパッケージが、所定の時間に又は定期的にネットワーク436にブロードキャストされる。448において、サーバ432から受信可能な、又はローカルに構成可能な命令に従って、各ボックスは、リリースからのそれの構成に従ってデータをキャプチャ及びキャッシュする。例えば、ヘッダを受信し、セグメントを受信しないと仮定されるボックスは、ヘッダのみをキャプチャ及びキャッシュする。ボックスがヘッダと2つのセグメントを受信すると仮定される場合、当該ボックスは、ヘッダと2つのセグメントのみをキャプチャ及びキャッシュする。
【0113】
サービスを提供する各ボックスが統合された1つのリリースパッケージから適切なデータを選択するため、各ボックスのライブラリは同期的に更新される。一部のボックスがブロードキャストの際に更新することができなかった場合、これらのボックスは次の簿ロードキャストにおいて更新されるか、又は上述したような図4Bのプロセスを利用して他の更新されたボックスにより非同期的に更新することができる。一実施例では、ケーブル又は衛星インフラストラクチャにおける複数のチャネルが、例えば、指定されたチャネルにおける各リリースパッケージなどをブロードキャスト又はマルチキャストすることによって、更新プロセスを円滑化するのに利用されてもよい。上述されるように、1つのシナリオでは、それぞれが1つのタイプのボックスに相当する6つのリリースパッケージが存在するかもしれない。また、ボックスは、それのリリース用の特定のチャネルにチューニングされるように構成されてもよい。
【0114】
最近サービスを開始した、又は長い期間の後にネットワークに最近再接続された新たなボックスは、ここではまとめて新規ボックスと呼ばれる。これらの新規ボックスは、エンプティであってもよいし、又は出荷のためパッケージ化され、又はネットワークから切断された時点では利用可能であり、さらに一部は現在も利用可能であり、一部は現在は利用不可であるタイトルのヘッダ及びセグメントを含むものであってもよい。これら新規のボックスがネットワークから切断されている間、アクティブなボックスのライブラリは何回も更新されているであろう。この結果、もとのライブラリは古いものとなっている。
【0115】
サービスプロバイダは毎日10個のリリースによりライブラリを更新し、ライブラリの合計タイトル数は5000であることが仮定されている。アイドル時間が10日間である場合、もとのライブラリは100個のリリースを欠落している。アイドル時間が約6ヶ月である場合、ボックスのもとのライブラリは約1800個のリリース分だけ古いものとなっている。図5Aは、一実施例によるライブラリ500に対する段階的な更新を示す。新規ボックス(切断又は単に出荷前にライブラリによりコピーされた)になった時点で、ボックスは、上位バンド504に100個のタイトルと、低バンド506に4900個のタイトルを有する。180日間サービスを提供していなかったボックスについて、ライブラリ状態510は、当該ボックスがどの程度古いものになったか、すなわち、ライブラリ500が1800個のリリースを見逃し、そのうちの100個が上位バンド504のリリースであり、1700個が低バンド506のリリースであることを示している。これらのボックスを購入するため店頭に置かれた場合、更新すべき多数のタイトルがないことになる。同様に、これらのボックスを購入するため店頭にない場合、新規ボックスのタイトルは古いものであるかもしれないが、更新すべきボックスは多くはない。
【0116】
リリースが時間の経過と共に要求又は人気が低下し、最終的に低バンド506に置かれることは通常理解される。従って、180日後、もとのライブラリ500には排除されるべき約1800個のタイトルがあり、もとのライブラリ500の3200個のみがライブラリ510に維持されるかもしれない。一実施例では、1800個のタイトルが、ネットワークがもはやそれらをサポートしなくなってからボックスがサービス提供する時点で即座に排除される。
【0117】
ライブラリ510を更新するため、ボックスは、ボックスタイプとバンド情報に対応する1800個の見逃したヘッダとセグメントを受信しなければならない。1800個のリリースのヘッダと対応するセグメントのそれぞれをダウンロードするため、ネットワークの帯域幅の制約の下、ボックスがタイトルを注文するのに利用可能となるまでに数日間、数週間又は数ヶ月かかる可能性があり、運用上は所望されるものでない。
【0118】
一実施例では、ボックスの更新を迅速化するプロセスは、上位バンドをさらなるバンドに分割することによって実現される。例えば、高(H)バンドと中(M)バンドとそれぞれ呼ばれる2つのバンドがあるかもしれない。各バンドは、例えば、Hバンドには50タイトルとMバンドには50タイトルなどのいくつかのタイトルが割り当てられるかもしれない。便宜上、図3Aは、Hバンド、Mバンド及びLバンドによるタイトルの一例となる人気による分類として使用されるかもしれない。ボックスがライブラリを更新するのに必要な時間を短縮するため、Mバンドのための多数のセグメントのフェッチが回避されるかもしれない。このアイデアの背後にある合理性は、Mバンドのタイトルは人気が低下しつつあり、同時要求をサポートするため、ネットワークにおいて多くの分散セグメントがまもなく不要になるというものである。従って、例えば、新規ボックスはLバンドと同様にMバンドのタイトルを扱い、これらのタイトルの僅かなパーセンテージのみに対して1つのセグメントのみを格納することを選択するかもしれない。
【0119】
同じ又は他の実施例では、ボックスは、ユーザがライブラリの人気のあるタイトルに迅速にアクセスすることを可能にし、セグメントのフェッチ前に見逃したタイトルのヘッダをフェッチすることによってライブラリ全体にアクセスすることを可能にする。ぼっくにヘッダがローカルに存在する限り、ユーザはタイトルを発注及び再生することが可能であり、ネットワークから分散セグメントをフェッチすることが可能となるため、当該タイトルがHバンドにたまたま存在したとしても、何れのセグメントも再生を可能にするためローカルにキャッシュされる必要はない。従って、ボックスを更新するための良い戦略は、テールの前にヘッダをフェッチし、タイトルの人気に従ってヘッダがフェッチされるシーケンスを発注することを優先させることである。これにより、大部分の人気のあるタイトルが即座に利用可能となる。
【0120】
同じ又は他の実施例では、いくつかのテールセグメントは、一部のヘッダより優先され、これにより、一部のセグメントはボックスにより迅速に受信され、セグメントの有用な供給者として機能を開始し、他のボックスからの要求にサービス提供することが可能となる。ライブラリ全体へのアクセスをどの程度の迅速さによりユーザに提供する必要があるかと、ユーザのボックスがシステムのロードの一部を負担する有用な供給者になることがどの程度重要であるとの間の解決される必要があるトレードオフに応じて、何れのセグメントが何れのヘッダに対して優先するか決定するための多数の方法が存在することは理解されるかもしれない。以下において、ヘッダとセグメントに関する優先度の選択の一実施例が説明される。
【0121】
一実施例によると、新規ボックスは、Hバンドの50タイトルのそれぞれのヘッダと1つの対応するセグメントとをダウンロードすることによって開始する。このデータは、50タイトルの対応するヘッダと各セグメントを有する他のボックスからフェッチされてもよい。ライブラリ状態512は、Hバンドの所望の状態が第1日に更新されることを示している(Hバンドの更新全体が1日で終了すると仮定する)。Hバンドのタイトルを更新する方法はいくつかあるかもしれないということは理解されるかもしれない。一実施例では、最も要求されるタイトルからスタートしてHバンドの各ヘッダがまず段階的にフェッチされ、その後、Hバンドの各タイトルのセグメントがフェッチされる。他の実施例では、最も要求されるタイトルから始めて、Hバンドの各タイトルのヘッダと対応するセグメントがまず段階的にフェッチされる。
【0122】
Hバンドの50タイトルがほぼ更新された後(各Hバンドタイトルが2つのローカルセグメントを要求する場合、各タイトルはこの段階で1つの見逃したセグメントを依然として有する)、Mバンドの50タイトルが次に更新される。しかしながら、Hバンドの50タイトルの更新中、他のタイトルが、動的な更新によってライブラリに追加されている。この結果、Mバンドには更新すべき50未満のタイトルが存在するかもしれない。なぜなら、1以上のタイトルがHバンドからMバンドに排除されるかもしれないためである(図の矢印により示される)。一実施例では、Mバンドの各タイトルのヘッダがサービスを提供する他のボックスからフェッチされ、Mバンドのタイトルの5%のみに対する1つのセグメントがフェッチされる。他の実施例では、Mバンドタイトルのヘッダのみがフェッチされ、セグメントは以降にフェッチされる。Mバンドの中間状態は、Mバンドのタイトルに対して0、1及び2セグメントが存在する理由を説明するため、図3Aにより良好に理解することが可能である。
【0123】
(1+X)日後(ただし、Xは、HバンドとMバンドとを更新するのに要する時間を示す)(ライブラリ状態514を参照)、ネットワークスピードに応じて、Hバンドからある個数のタイトルがMバンドに排除され、それと同時に、Mバンドの対応する個数のタイトルがLバンドに排除されるかもしれない。ライブラリがその中のタイトルの古さに関して段階的に構成されている場合、ライブラリ状態502のもとの100タイトルはシフトされたものであり、更新されるべきであったLバンドの1700タイトルが存在するが、上位バンド504からの排除は、実際に更新すべきタイトルの実際の個数を減少させたことは理解されるかもしれない。このとき、すべての見逃したタイトルのヘッダが受信されるまで、Lバンドのタイトルのヘッダが継続的にフェッチされる。最後に、H、M及びLバンドのタイトルに対して、すべての見逃したセグメントもまたフェッチされる。ライブラリ状態516は、更新プロセスの完了後にライブラリの最終的な状態を示す。
【0124】
図5Bは、3つのボックス532〜534がシステムに追加された状況530を示す。これら3つのボックス532〜534は各自の識別子及び/又はIPアドレス及びライブラリ状態と共にサーバ536に登録された後、サーバ536は、これらのボックスが以前に見逃したものと、見逃したタイトルをフェッチする場所などの更新方法に関する情報を返す。この状況530は、ボックス532がまずボックス群537〜540から見逃したタイトル(ヘッダ又はおそらく対応するセグメントなど)をフェッチし、ボックス533及び534がまずボックス543と544のグループから見逃したヘッダをそれぞれフェッチすることを示している。動作について、ボックス(すなわち、532)は対応するヘッダ及び/又はセグメントをフェッチするためボックス間を動的にスイッチするよう構成されることに留意される。
【0125】
これら3つのボックス532〜534はまず上位バンド(すなわち、Hバンド)の各タイトルに対して1つのヘッダと1つのセグメントにより更新される。動作について、これら3つのボックス532〜534は他のボックスへのサービスの提供を開始する候補とすることが可能である(例えば、Hバンドのタイトルなどに対して)。図5Bにおいて、発注元のボックス542は、上位バンドのタイトルに対する注文を発注している。また、当該タイトルはヘッダと4つのセグメントとを有するファイルに係るものであり、4つのセグメントのうちの2つは発注元のボックス542にあることが仮定される。従って、発注元のボックス542は、その他の2つの欠落しているセグメントをフェッチする必要がある。当該タイトルのヘッダが再生されている間に、発注元のボックス542は、ボックス532〜534のそれぞれがこれら欠落しているセグメントの1つを有し、それらのすべてが2つの欠落しているセグメントの同じものを有しているとは限らない場合、ボックス532〜534の何れか2つから欠落しているセグメントを取得するようにしてもよい。ボックス群537〜540、543及び544はボックス532〜534を更新するのにビジー状態であるため、ボックス532〜534は、Hバンドのリリースのセグメントが利用可能になると即座に、他のものにサービスを提供することを開始する。このため、Hバンドのタイトルに対する最大の持続可能な同時性は変わらないままとされることが理解されるかもしれない。さらに、新たにリリースされたタイトルに対する再生サポートは、新規ボックスが新たなリリースの再生しかサポートできないため、新規ボックスに転送されるかもしれないことは理解されるであろう。これは、トラフィック問題を大きく抑制し、任意のバンドのタイトルに対して最大の持続可能な同時性を向上させる。
【0126】
図5Cを参照すると、おそらく製造後に長期間店舗の棚に置かれていたため、ある期間オンライン状態でなかったライブラリを更新するためのフローチャート又はプロセス550を示す。プロセス550は、ハードウェア、ソフトウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されるかもしれない。プロセス550は、552においてネットワーク接続される何れかの新規ボックスを待機する。プロセス550は、新規ボックスがネットワークにおいて検出され、又はサーバが新規ボックスの存在を通知されると開始される。一実施例では、新規ボックスは、電源オンされ、ネットワークに接続されると、サーバプロバイダに係るサーバに自動的に通知及び/又は登録するよう構成される。当該ボックスは、それの識別子とIPアドレスとを含む通知と、おそらくボックスが直近に更新された日時とを送信してもよい。
【0127】
553において、プロセス550は、ボックスのライブラリがレコードに従って更新される必要があるか検出する。ボックスのライブラリが更新される必要のないケースがある。例えば、ボックスが短時間の間電源オフされていた場合、それは新たなコンテンツを見逃していないかもしれない。一実施例では、サーバは、ライブラリがボックスの状態に従って更新される必要があるか判断する。ライブラリを更新する必要がない場合、プロセス550は552に戻り、他の新規ボックスを待機する。ライブラリが更新される必要があると判断された場合、プロセスは554に移行する。
【0128】
554において、ボックスがオフラインであったため、又はストレージのエラーのため、ライブラリ内の時間の経過したタイトル群と、過去に見逃したリリース群又はボックスから現在欠落しているリリース群とが、決定される必要がある。他のボックスの更新されたライブラリと同期するため、時間の経過したタイトルはもはやアクセス付加としてフラグ付けされる(当該データがボックスにおいて依然として利用可能であったとしても)。プロセス550は、その後に556においてライブラリの更新に移行する。上述されるように、ライブラリはまず、Hバンドのタイトルのヘッダによって更新され、これにより、ボックスはこれらのタイトルの注文を受け付け、これらのタイトルの他のボックスの注文をサポートするようになるかもしれない。動作について、ヘッダがローカルにキャッシュされると即座に、ボックスは、当該ヘッダに係るタイトルに対する発注を実現する状態にある。Hバンドタイトルに対して、ボックスは556において、他のボックスからのこれらのタイトルのそれぞれに対して、ヘッダ又はヘッダ及び対応するセグメントをフェッチするよう構成される。ヘッダ又はセグメントをフェッチするための一例となる機構の1つは、上述されるようなアプリケーションレイヤマルチキャストgossipプロトコルによるものである。
【0129】
システムは、各ボックスがHバンドタイトルのヘッダと1つのセグメントのみを格納していることを要求するよう構成されるかもしれない。あるいは、システムは、各ボックスがHバンドタイトルのヘッダと複数のセグメントを格納していることを要求するよう構成されるかもしれない。何れの場合も、ボックスは、注文の実現又はライブラリの更新のため、他のボックスに対してサービスを提供する準備ができている。さらに、新たなタイトルによって新規ボックスを更新するための責任は、より新規なボックスのみが新たなタイトルを更新することを支援することが可能であるため、新規ボックスに転換される可能性があることは理解されるであろう。
【0130】
上位バンドのタイトルが更新されている間、プロセス550はサーバからのリリースがあるかチェックする。558においてリリースがある場合、当該リリースがライブラリに適しているかに応じて、ライブラリの適切なタイトルに影響を与える。一実施例では、ライブラリはいくつかの高、中及び低バンドに実質的に分割される。リリースのタイトルがHバンドに備えられるべきであるとされる場合、Hバンドの相対的に人気の低いタイトルが次の下位のバンドに排除され、554において当初決定された実際のタイトル数を実質的に減少させる。リリースがない場合、又はリリースが最も要求されているタイトルを含んでいない場合、プロセス550はHバンドのタイトルが更新されるまで556〜562を継続する。動作について、各バンドのタイトルが、人気及び/又は経過期間に関してあるバンドから下位のバンドに継続的及び段階的に排除される。便宜上、3つのバンド、すなわち、H、M及びLバンドが使用されると仮定される。
【0131】
プロセス550は、MバンドとLバンドのすべてのタイトルのヘッダと、MバンドとLバンドのタイトルの僅かなパーセンテージの対応するセグメントをさらにフェッチするため564に移行する。一実施例では、Mバンドのタイトルの5%がセグメントを有し、Lバンドのタイトルの5%がセグメントを有している。この結果、ライブラリの更新は、ボックスがサービスを提供することを注視することを回避する。何れの場合も、タイトルがHバンドからMバンドに排除される毎に、それの対応するセグメントが単にMバンドに移される。他の何れのセグメントもシステム構成に従って破棄されるかもしれない。また、タイトルがLバンドに移されると、当該タイトルのセグメントはLバンドに保持されているかもしれず、又は当該タイトルが当該ボックスに対して指定されたタイトルのパーセンテージの範囲内に属するか否かに応じて破棄されるようにしてもよい。固定数のタイトルを制御し、ローカルストレージを維持する場合、Lバンドの対応するタイトル、典型的には最も人気のないタイトルが、破棄又は上書きされる。セグメントの破棄は、ボックスが格納スペースを使い果たし始めると実行され、より多くの利用可能な格納スペースが存在する場合には回避することが可能である。
【0132】
566において、プロセス550は、ボックスがユーザ又は他のボックスにサービスを提供することに影響を与えることなく、Hバンド及び/又はMバンドのタイトルのセグメントをフェッチすることを継続する。Hバンドのタイトルに2つのセグメントが存在するケースがあることが説明される。556において、ボックスがユーザ又は他のボックスにサービス提供できる準備ができるための時間を最小化するため、セグメントの1つのみがフェッチされたことが思い起こされる。これにより、566において他のセグメントがフェッチされるかもしれない。同様に、Mバンドのすべてのタイトルが少なくとも1つのセグメントを有すると仮定されるが、そこでのタイトルの5%しかセグメントを有していない。このため、対応する各セグメントは、ボックスがユーザ又は他のボックスにサービスを提供することを禁止することなく、他のボックスからフェッチされてもよい。
【0133】
図5Cには直接的には示されていないが、559と同様の処理がそれぞれ564と566に本来的に含まれている。さらに、プロセス550の一部は、好ましくはネットワークのトラフィックが低いとき、1日の任意の時点で実行することが可能である。ライブラリを更新するのに必要なデータを供給するボックスを選択する際、これらのボックスは、ネットワークの状態、地理的局所性、供給元と受信者との間で実現される持続可能な帯域幅などと共に、ボックス自体の状態を利用するため、時間と共に決定又はスイッチされるかもしれない。
【0134】
また、ケーブル若しくは衛星ネットワークを介し、又はIPマルチキャストを介し利用可能なものなど、高帯域幅ブロードキャスト若しくはマルチキャストチャネルの利用性が、新たな映画の提供に関して上述されたように、ボックスを更新するプロセスを迅速化するのに利用可能であることが理解されるかもしれない。ブロードキャストチャネルは、おそらく最も要求の高いタイトルを優先させて、最新のリリースの伝送に利用されてもよい。その後、新規ボックスは、それらが見逃したヘッダとセグメントを迅速に受信するため、適切なチャネルにチューニングするようにしてもよい。
【0135】
図6Aを参照すると、サーバ600の一例となる実現形態が示される。サーバ600は、図1Aのサーバ102に対応するかもしれないが、単一の計算装置又はコンピュータクラスタであるかもしれない。サーバ600は、サーバモジュール602とインタフェース604とを有する。一般に、サーバモジュール602は、メモリにロードされ、それの処理を実行するため1以上のプロセッサ(図示せず)により実行される。アプリケーションでは、サーバ600は、メディアサービスをユーザに提供するため、サービスプロバイダ又は企業によって運用されているかもしれない。
【0136】
サーバ600はまた、コンテンツ若しくはソースプロバイダ608とサーバ600との間の通信を実現する配信エージェント606を有する。実現形態に応じて、ソースプロバイダ608は、以下に限定されるものではないが、コンテンツ受信機、コンテンツ作成者及び映画配給者を含むかもしれない。配信エージェント606は、コンテンツがソースプロバイダ608から適切に受信されることを保証するため設けられる。コンテンツの受信方法に応じて、配信エージェント606は、各種形式により実現されるかもしれない。例えば、映画配給者は、サーバ600を運用するサービスプロバイダに映画をリリースする。映画はサーバ600にセキュアに転送され、この場合、配信エージェント606はセキュア伝送媒体となる。他の例では、コンテンツは衛星によって転送され、この場合、配信エージェント606は衛星受信機であるかもしれない。企業がそれの製品やサービスを複数のユーザにサーバ600を介し宣伝することを所望するさらなる他の例では、当該企業はインターネットを介しサーバ600にコマーシャルビデオを配信するかもしれない。従って、配信エージェント606は、インターネット若しくはローカルネットワークの一部であり、サーバ600とインターネットとの間のデータ通信を実現するため、必要なインタフェース(TCP/IPなど)を提供する。
【0137】
効率化のため、サーバ600は、各種フォーマットによるソースファイルをクライアントボックスにより理解される受付可能なフォーマットに変換するため設けられるトランスデューサ609を有するか、又は接続されるようにしてもよい。典型的には、コンテンツプロバイダによって提供されるビデオソースは、高品位映像信号、DVD、フィルムなどである可能性がある。当該フォーマットがサーバ600に所望されるフォーマットでない場合、トランスデューサ609は、このようなソースを受付可能なフォーマット(MPEG−2、MPEG−4など)に変換するよう起動される。上述されるように、ソースプロバイダ608は、多数のタイプのソースを提供可能である。トランスデューサ609又は類似する機能を有する適切な装置によって、サーバ600は、任意のタイプのソースを受信し、それらをユーザに費用又は情報のため配信することが可能である。
【0138】
サーバ600は、データネットワークを介しサービスを提供する複数のボックスとサーバ600との間のデータ通信を実現する他のインタフェース604を有し、そこでは、サーバ600は、これらのボックスに関してリモートに配置されてもよい。ネットワーク611は、インターネット、PSTN(Public Switch Telephone Network)、プライベートネットワーク、又は無線ネットワークを含む大規模ネットワークの一部とすることが可能である。ネットワーク611は、電話線、ケーブル、ファイバ又は大気(無線)などの1以上の伝蔵媒体を利用するかもしれない。サーバ600とボックスとの間の通信に使用される一例となる通信プロトコルはTCP/IPである。
【0139】
図6Aに示されるように、サーバモジュール602は、互いに協調的に動作するよう構成される複数の機能エンジン又はモジュールを有する。図6Aのサーバモジュール602にリストされるすべてのモジュールが、実際に使用される必要があるとは限らない。実際の実現形態又は要求に応じて、これらのモジュールは選択的に配備されるようにしてもよい。
【0140】
ユーザ管理モジュール610は、加入者又はユーザを管理するよう構成される。それは、サービスプロバイダからメディアサービスを受信する契約をしている又は所望しているすべてのユーザに係るアカウントの追加、削除又は更新を実現する。ユーザ管理モジュール610はまた、すべてのアカウントに対する支払の決済を管理する。一実施例では、各アカウントは、メディアサービスへの無制限なアクセスを許可する固定の月単位の料金が課金される。他の実施例では、各アカウントは、サービスプロバイダによって提供されるライブラリのタイトルに対する注文が発注される毎に、更新又は課金される。
【0141】
コンテンツ管理モジュール612は、ユーザに提供可能なすべてのコンテンツを管理する。上述されるように、これらのコンテンツは、ヘッダとセグメントの形式により構成される。これらのオブジェクトは、サービスを提供するボックス間に分散される。コンテンツ管理モジュール612は、これらのオブジェクトの分散を管理するよう構成される。コンテンツ管理モジュール612にアクセスすることによって、オペレータは、ライブラリのタイトルに関するオブジェクトの分散方法を直接的に制御し、利用可能なものと、これらのオブジェクトの分散方法及び場所に関するマッピング情報を取得するようにしてもよい。図6Bは、5000タイトルのライブラリがN個のボックスにどのように分散されているか示す一例となるマップ630を示す。カラム632は、サービスを提供するすべてのボックスをリストしている。各ボックスには、識別用の一意的な識別子が割り当てられている。カラム632の情報は、サービスを提供するボックスの識別子としてみなされるかもしれない。例えば、ボックス1には、“ボックス1”の一意的な識別子又は英数字のシーケンスが割り当てられる。
【0142】
カラム634は、カラム632にリストされる各ボックスの対応するIPアドレスをリストしている。カラム636は、ライブラリのすべてのタイトルのヘッダをリストしている。カラム638は、タイトル1が2つのセグメントを各ボックスにキャッシュされることが要求されていると仮定すると、タイトル1の何れのセグメントが欠くボックスに常駐しているかリストしている。カラム640は、タイトル2が1つのセグメントを各ボックスにキャッシュされることを要求されていると仮定すると、タイトル2の何れのセグメントが欠くボックスに常駐しているかリストする。カラム642は、タイトル5000が選択されたボックスに1つのセグメントを有することが要求されていると仮定すると、タイトル5000の何れのセグメントが選択されたボックス群にあるかリストしている。この結果、ボックスのすべてのオブジェクト(すなわち、ヘッダ又はセグメント)が、発注されたタイトルのローカルな再生又は他のボックスへのアップロードのため一意的にアドレス指定されるかもしれない。
【0143】
配信管理モジュール614は、発注元のボックスから受信した注文に応答するよう構成される。コンテンツ管理モジュールと共に動作して、配信管理モジュール614は、この注文に応答して、ソース情報、認証情報及びセキュリティ情報を含むレスポンスを生成する。ソース情報の一例が、図6Cのテーブル650又は図6Dのテーブル652のテーブルとして図示される。テーブル650は、注文されたタイトルのセグメントを供給するよう指定された4つのボックスのそれぞれのIPアドレス(IPA1など)を含む。認証情報は、他のボックスとのセキュア通信のため発注元のボックスを認証する。セキュリティ情報は、タイトルの再生のためのデータの解読を実現する。レスポンスはさらに、他のボックスから抽出されるべきセグメントに関する命令と、発注元のボックスを特定するIPアドレスとを有するようにしてもよい。レスポンスを受信すると、発注元のボックスは、選択されたタイトル(Lバンドにあると仮定される)に対応するヘッダが再生されることを可能にし、それと同時に若しくはその後まもなくして、発注元のボックスは、サーバから受信したレスポンスに従って4つの各リクエストを発行する。各リクエストがこれら4つのボックスの1つのIPアドレスを有していることは理解される。各ボックスがリクエストの1つを受信すると、要求されたセグメントが発注元のボックスにリリース又はアップロードされる。
【0144】
ネットワーク管理モジュール616は、サービスを提供する各ボックスの状態をモニタするため設けられる。1つのアプリケーションでは、ネットワーク管理モジュール616は、ボックスのアドレスを受信するよう構成される。多くのケースにおいて、ボックスには経時的に変動する可能性のある動的アドレスがインターネットサービスプロバイダによって割り当てられている。サービスを提供するすべての各ボックスがサーバ600に接続されることを保証するため、ボックスのIPアドレスが何れかの理由により変更されるときは常に、それの新たなIPアドレスは時間内にサーバに通知される必要がある。一実施例では、各ボックスは、ネットワーク管理モジュール616が必要に応じてそれのIPアドレスを変更したボックスのIPアドレスを更新するように、サーバとの間でイベントトリガーに若しくは定期的にショートメッセージを送受信するよう構成される。他方、ネットワーク管理モジュール616は、ショートレスポンスのため各ボックスにショートメッセージを送信するよう構成される。ボックスが動作していない場合(電源オフ又は不具合など)、ネットワーク管理モジュール616は、即座に通知され、発注元のボックスに対してセグメントを提供するための指定から当該ボックスを排除する配信管理モジュール614を更新する。同様に、ボックスが映画の注文に対してセグメントをすでに供給している場合、ネットワーク管理モジュールは、配信管理モジュールに他の注文に対するセグメントを供給するためボックスの利用可能性状態が通知され続けるようにしてもよい。
【0145】
提供管理モジュール618は、ライブラリ管理モジュールとも呼ばれるかもしれない。提供管理モジュール618は、各ボックスのライブラリを更新するためのものである。リリースがあるときは常に、提供管理モジュール618は、ボックスへのリリースの適切な提供を保証する。リリースが新たにリリースされた映画であり、おそらく需要が高い状況では、提供管理モジュール618は、当該リリースに係るファイルのヘッダと少なくとも1つのセグメントを各ボックスに常駐させる。リリースが新たにリリースされた映画ではないが、需要が高いような他の状況では、提供管理モジュール618は、当該リリースに係るファイルのヘッダとおそらく1つのセグメントを各ボックスに常駐させる。リリースが古典的なタイトルであり、相対的に需要が低いさらなる他の状況では、提供管理モジュール618は、ヘッダを各ボックスに常駐させ、セグメントをネットワークの選択されたボックス群に常駐させる。新規ボックスがネットワークに接続されたさらなる他の状況では、ネットワークモニタリング管理616が、ボックスの状態を提供管理モジュール618に通知するよう構成される。ボックスの既存のライブラリの状態に応じて、提供管理モジュール618は、何れがライブラリにおいて欠落しているか判断し、他のボックスからライブラリを更新する方法についての命令をボックスに提供する。
【0146】
セキュリティ管理モジュール620は、サービスを提供するボックスに分散されるオブジェクトをセキュア化するため設けられる。一実施例では、セキュリティ管理モジュール620は、発注元のボックスに係るユーザを認証し、ユーザの認証後及び/又は注文に対する支払の決済後、発注元のボックスに1以上のセキュリティキーと認証情報を提供するよう構成される。セキュリティキーは、発注元のボックスにおいてヘッダ及び/又はセグメントの解読を実現するかもしれない。認証情報は、発注元のボックスがタイトルの再生のため必要とされるセグメントをフェッチするため、発注元のボックスが指定されたボックスと通信することを可能にする。他の実施例では、セキュリティ管理モジュール620は、サービスを提供するボックスに分散される前に、すべてのオブジェクト(ヘッダ及び/又はセグメント)を暗号化するため、コンテンツ管理モジュール612又は提供管理モジュール618と共に動作する。さらなる他の実施例では、セキュリティ管理モジュール620は、サービスを提供するすべてのボックスにオブジェクトとして分散されるすべてのコンテンツのデジタル著作権管理(DRM)を提供する。さらなる他の実施例では、セキュリティ管理モジュール620は、それがセグメントに分割され、ボックスに分散される前に、タイトルのファイルから小さな部分を取り除くようにしてもよい。ボックスがタイトルを発注すると、ファイルのこれらの部分が、おそらくサーバレスポンスの一部として、サーバにより直接的に供給され、これにより、タイトルがサーバのアクティブな参加などに完全に構成することができないことを保証することによってセキュリティを向上させる。
【0147】
コマーシャル情報管理モジュール622は、必要に応じてユーザに表示することが意図されるコマーシャル情報を管理するため設けられる。このような情報の具体例として、以下に限定されるものではないが、宣伝、特別提供、映画予告編及び公共放送などがあげられる。このような情報は、映画を表示する画面の一部に重ねられ、2つの映画の間のインターバルの間に若しくは映画の表示開始に表示され、又は単にユーザにより要求されるかもしれない。情報に応じて、このような情報は、ボックスの地理的位置、視聴行動又はユーザの所望する言語を含む1以上のファクタに従って、独立にリリースされるか若しくはリリースに係るヘッダに添付されてもよい。
【0148】
ソースプロバイダ管理モジュール624は、プロバイダからの配信されたコンテンツを利用するため、ユーザにより支払われた料金の配布を管理するため設けられる。実現形態に応じて、ソースプロバイダ管理モジュール624は、配信エージェント606を介し毎日、毎週又は毎月、各コンテンツプロバイダと支払を共有し、又は提供されるライブラリのタイトルの財務予想又は統計を提供するよう構成されるかもしれない。
【0149】
図6Aの配信管理モジュール614をさらに参照して、一実施例によると、配信管理モジュール614は、指定されたボックスの1以上が突然利用不可となり、又は発注元のボックスへの要求されたセグメントの供給を継続することがスローダウンする状況を回避するよう構成される。発注元のボックスに応答したソース情報は、指定されたボックスのそれぞれに対するバックアップ情報を含む。図6Dは、指定された各ボックスのバックアップ識別子(IPアドレスとして示される)を含むテーブルのバックアップボックスによる一例となるソース情報を示す。ボックスの1つが発注元のボックスからのセグメントに対するリクエストに応答しない場合、又はセグメントが正確に受信できない場合、バックアップIPアドレスが、当初指定されたボックスが提供できないセグメントを提供するため利用可能な、又は提供し続けるのに利用可能な対応するバックアップボックスにスイッチするため即座に呼び出される。
【0150】
完全にするため、図6Eは、発注元のボックス654がボックス654において発注されたタイトルに係る3つの各セグメントを受信するため指定された3つのボックス655〜657によりサポートされている一実施例を示す。各ボックス655〜657には、対応する同一のセグメントを有するバックアップボックスが設けられる。具体的には、ボックス655はバックアップボックス658によりサポートされ、ボックス656はバックアップボックス659によりサポートされ、ボックス657がバックアップボックス660によりサポートされる。注文されたタイトルのヘッダが発注元のボックスにおいて再生されている間、これら3つの分散されたオブジェクトは、ボックス655〜657からフェッチされる。ある理由のため、ボックス656がセグメントの提供を継続することを拒絶した場合、バックアップボックス659は、セグメントの提供を継続するようボックス656を置換するため起動される。一実施例では、バックアップボックス659は、ボックス654にセグメントを共同して供給するためボックス656に加わるよう構成される(例えば、それぞれは、同一のセグメントの異なる部分を供給するなど)。
【0151】
図6Fは、発注元のボックス670がボックス670の発注されたタイトルに係る3つの各セグメントを受信するため、指定された3つのボックス671〜673によりサポートされている他の実施例を示す。動作について、何れかの理由による発注元のボックスの故障はまれであり、全く同時に複数のボックスが故障することはさらにまれである。従って、指定された3つのボックス671〜673に対する3つのバックアップボックス674〜676は、セグメントを供給する他の指定されたボックスに対するバックアップボックスとして構成されるかもしれない。図6Fは、発注元のボックス678が3つの指定されたボックス682〜684により供給を受けながら、2つの指定されたボックス679及び680により供給を受けている発注元のボックス677を示す。各フェッチプロセスが良好に実行されることを保証するため、指定された各ボックスはバックアップボックスによりサポートされ、この場合、指定された2つのボックス679と680がボックス674と675によりバックアップされ、指定された3つのボックス682〜684がボックス674〜676によりバックアップされる。バックアップボックス674〜676の1つがアクティブボックスとなると、サーバ600は、フィールドの他のボックスをバックアップボックスとして即座に指定するようにしてもよい。
【0152】
図6Gを参照すると、ライブラリのあるセレクション(すなわち、タイトル)の瞬時の再生を開始するためのフローチャート又はプロセス686が示される。プロセス686は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されてもよい。好ましくは、プロセス686は、ユーザに係るボックスからの選択されたタイトルの瞬時の再生を実現するサーバとして指定された計算装置において実行される。一実施例では、プロセス686は、メディア・オン・デマンドシステムにおいて利用される。688において、プロセス686は、ユーザに係る発注元のボックスからのリクエストを待機している。典型的には、ユーザはタイトルを選択し、その後に注文を発注する。さらに後述されるように、発注元のボックスはサーバに転送されるリクエストを生成する。プロセス686は、注文を含むこのようなリクエストが発注元のボックスから受信されると起動される。一般に、リクエストは、発注元のボックスの識別子及びIPアドレス、ユーザアカウント情報(ユーザ名など)、並びに注文情報を含む。発注元のボックスにおいて何かが行われる前に、プロセス686は、ユーザの認証に移行する。ユーザが登録されていない場合、プロセス686は691に移行し、エラーメッセージを含むレスポンスが生成され、発注元のボックスに返される。実現形態に応じて、エラーメッセージは、エラーメッセージを表示するため、又はユーザをシステムに登録するよう求めるため、発注元のボックスのローカルモジュールを起動するかもしれない。
【0153】
ユーザが認証された後、プロセス686は692に移行し、当該注文に対する支払が決済されているか判断する。一実施例では、登録プロセスにおいて、ユーザは、システムを用いてユーザが発注した注文に関する課金のためのクレジットカード情報を提供するようにしてもよい。他の実施例では、ユーザは、各課金に対する包括的な決済のための月毎の請求書を受信するようにしてもよい。支払が決済されていない場合(例えば、ユーザが自らの口座に大きな未払いがある)、プロセス686は693に移行し、エラーメッセージを含むレスポンスが生成され、発注元のボックスに返される。エラーメッセージは、支払のためユーザにローカルに表示されてもよい。
【0154】
支払決済後、プロセス686は694に移行し、発注元のボックスにセグメントを供給するのに指定されるいくつかのボックスを決定する。ボックスの正確な個数は、選択されたタイトルの再生を継続するため発注元のボックスが必要とするセグメント数に依存する。696において、受信したリクエストに従ってレスポンスが生成される。一般に、レスポンスは、ソース情報、認証情報及びセキュリティ情報を含む。ソース情報は、発注元のボックスが選択されたタイトルの再生を継続するため必要とされるセグメントをどのようにかつどこで取得できるか指示する。認証情報は、発注元のボックスが必要とされるセグメントを供給するため指定されたボックスとの各自のセキュア化された通信を行うことを可能にする。セキュリティ情報は、発注されたタイトルの再生のためのデータの解読を実現する。他のボックスから必要とされるセグメントを供給するための1以上のボックスを決定する際、1以上のファクタが実現形態に応じて考慮されてもよい。これらのファクタは、以下に限定されるものではないが、各自の利用可能な帯域幅、地理的位置、供給元のボックスの利用可能性の履歴、及び各ボックスのインターネットサービスプロバイダを含む。さらに、発注されたタイトルが人気があるか否か、供給元のボックスが新規であるか否か、及び供給元のボックスがビジー状態であるか否かが考慮されてもよい。何れの場合も、レスポンスは、発注元のボックスに戻されるか、又は発注元のボックスに必要とされるセグメントを受信しながら再生を開始させる。その後、プロセス686は、他のリクエストを待機するため688に戻る。
【0155】
プロセス686は、一実施例では、サーバが発注プロセスのみを取り扱い、実質的に同時に異なるタイトルに対する多数のリクエストを容易に管理することが可能となることを示す。本発明のいくつかの実施例の可能な特徴及び効果の1つは、まとめて利用されていない帯域幅と計算パワーを利用するため、ユーザにデータ供給負担をシフトすることである。
【0156】
図7Aを参照すると、図2Aのボックス(207−1、207−2及び207−nなど)の何れか1つに対応するボックス700の一例となる実現形態が示される。ボックス700は、ローカルモジュール702、インタフェース704及び格納スペース706を有する。ローカルモジュール702は、メモリ708にロードされ、それの処理を実行するためプロセッサ710により実行される。動作について、ボックス700は、サービスプロバイダ若しくはメディアサービスをユーザに提供する企業によって加入者若しくはユーザに提供されるかもしれない。ネットワーク712を介して、ボックス700はサーバ(図6Aのサーバ600など)によって提供されるメディアサービスを受信することが可能である。上述されるように、ボックス700の具体例として、以下に限定されるものではないが、デスクトップコンピュータ、ラップトップ若しくはノートブックコンピュータ、セットトップボックス、電話、タブレットPC若しくはPDAなどの携帯装置などがあげられる。ネットワーク712は、好ましくは、xDSL、ATM、SONET、光ファイバ線、プライベート/パブリック電話網、無線接続、又はCAT−5の1以上を利用するブロードバンドローカルループである。ボックス700は、回線交換若しくはパケット交換接続によりネットワーク712に接続される。
【0157】
図7Aに示されるように、互いに協調して動作するよう構成される複数のモジュールが存在する。図7Aのローカルモジュール702にリストされるすべてのモジュールが必ずしも利用される必要があるとは限らないことは、当業者に理解されるであろう。実際の実現形態若しくは要求に応じて、モジュールは選択的に配置されてもよい。
【0158】
状態通知モジュール714は、ボックス700に影響を与える各種状態をモニタするため設けられる。1つの状況では、ボックス700のIPアドレスが変更されるときは常に、状態通知モジュール714はこの新たなIPアドレスをサーバに即座に通知する。他の状況では、状態通知モジュール714は、ボックスのライブラリがタイムリーに適切に更新可能となるように、ボックスがネットワークからどのくらいの期間切断されていたか検出するよう構成される。さらなる他の状況では、状態通知モジュール714は、利用可能なアップロード帯域幅を検出する。アップロード帯域幅がある数値未満である場合、状態通知モジュール714は、ボックスがセグメントを他のボックスに供給するよう指定されないように、タイムリーにサーバに通知する。さらなる他の状況では、状態通知モジュール714は、供給元のボックスからフェッチされたセグメントがもはや所望されるスピードでないか検出し、当該供給元のボックスとの通信セッションを終了させ、他の供給元のボックスとの通信セッションを起動する。状態通知モジュール714により実行される他の機能は、ここでの詳細な説明により理解されるであろう。
【0159】
ライブラリ管理モジュール716は、格納スペース706の多数のタイトルのヘッダ及びセグメントを管理するため設けられる。ライブラリ管理モジュール716を介して、サーバは、ボックスが何れのオブジェクトを有しているか知る。ライブラリ管理モジュール716はまた、発注されたタイトルを参照して何れの分散オブジェクト(すなわち、欠落したセグメント)がフェッチされるべきか指示する。当該ボックスが新たなタイトルと変更したタイトルのヘッダとセグメントをフェッチ及び受信すると、ライブラリ管理モジュール716がこれらを管理する。ライブラリ管理モジュール716はサーバに発注元のボックスへの供給のための利用可能なセグメントを最新のものに維持させるため、サーバと通信するようにしてもよいことが理解されるであろう。このような通信は、各イベントの後(新たなセグメントの受信など)、所定のインターバルなどにより行われるようにしてもよい。
【0160】
メタデータモジュール718は、ボックス700とそれのユーザとの間の各種のやりとりを実現するため設けられる。メタデータモジュール718は、ユーザがボックス700のライブラリに関するメタデータをブラウズすることを可能にするための各種グラフィックインタフェースを提供するよう実現されてもよい。このメタデータは、以下に限定されるものではないが、ライブラリのタイトルに関する俳優、監督、批評家、推薦広告、評価などに関する関連する情報を含むものであってもよい。一実施例では、メタデータモジュール718は、ユーザからエントリを受け付け、エントリに従って所望の情報を表示する。一例となるアプリケーションでは、ユーザは、1以上のキャラクタを入力する。メタデータモジュール718は、メタデータを検索し、入力されたキャラクタに従ってタイトルのリストを提供する。より多くのキャラクタが入力されると、タイトルの選択がより容易になされるように、リストは段階的に狭められる。他の一例となるアプリケーションでは、メタデータモジュール718は、ユーザがタイトルのタイプ(アクション、ロマンスなど)を指定することを可能にし、当該タイプに関するタイトルのリストが、タイトルの選択が可能となるように表示される。
【0161】
セキュリティモジュール720は、サーバだけでなく他のボックスとのセキュア通信を実現するため設けられる。一実施例では、指定されたボックスの1つがセグメントを供給するため発注元のボックスからのリクエストを受け付けるとすぐに、発注元のボックスと供給元のボックスとの間のセキュアなセッションが確立される。このため、それらの間で伝送されるすべてのデータはセキュア化される。セキュリティモジュール720はまた、発注されたタイトルの再生のためのデータのDRM及びセキュリティを取り扱うため設けられる。
【0162】
学習エンジン722は、ユーザの視聴行動及び/又はユーザに係るボックスのネットワーク動作から、ユーザに最良のサービスを提供するため設けられる。ユーザがブラウズ、選択又は発注したものから、推薦されるタイトルのリストがユーザに対して自動的に生成されるかもしれない。また視聴行動から、学習エンジン722は、何れのセグメントがローカルにキャッシュされるか決定するようボックスを構成することが可能である。ボックスがある期間オフライである状況では、ボックスがオンラインに戻ると、学習エンジン722はフェッチ対象となるタイトルを優先順位付けすることによって、ライブラリを更新するようボックスを構成することができる。ボックスのネットワーク動作を取得することによって、学習エンジン722は、何れの帯域幅が1日の異なる時間において利用可能であるか知っており、他のボックスにセグメントを供給するボックスの指定又はサーバからのリリースのボックスの提供を実現するかもしれない。
【0163】
登録モジュール724は、新たなユーザがシステムに登録することを可能にする。典型的には、ユーザが良好に登録された後、登録モジュール724は、集中管理のため登録情報をサーバに転送するよう構成される。動作について、登録モジュール724は、ユーザ名やパスワードなどを要求するシステムを保護するためのフロントラインとして機能する。ユーザは、注文が受付可能となる前に、登録モジュール724により認証される必要がある。
【0164】
図7B及び7Cを参照すると、2つの図面は一緒になって、あるセレクション(すなわち、タイトル)の瞬時の再生を開始するためのフローチャート又はプロセス730を示す。当該プロセス730は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されるかもしれない。好ましくは、プロセス730は、ここで使用されるようなボックスに対応する計算装置において実行される。図6Gのプロセス686と共に動作することによって、プロセス730は、再生時にはファイルが完全には利用可能でないボックスからの選択されたタイトルに係るファイルの瞬時の再生を可能にする。
【0165】
732において、プロセス730は、ユーザからの選択を待機する。1つのケースでは、ユーザはキー(リモコン、キーボードなどにより)を起動してタイトルの1つを選択可能な複数のタイトルを有するディスプレイを視聴している。プロセス730は、ユーザにより選択がなされると起動する。プロセス730は734に移行し、ユーザ及び/又はボックスが適切に認証されているか判断する。一実施例では、登録されたユーザは、認証のためユーザ名とパスワードを入力するよう要求される。他の実施例では、登録されたユーザは、認証のためコードを入力することを要求される。ユーザを認証する方法は他にもあるかもしれない。何れの場合も、プロセス730は、ユーザ及びボックスが正当なものであることを保証する必要がある。そうでない場合、736において、ユーザがシステムに登録することを推奨するエラーメッセージがユーザに送信される。
【0166】
登録されたユーザが734において認証された後、738において、ボックスはその選択に従ってリクエストを送信する。当該リクエストは、注文及びユーザに関する情報を含む。リクエストは、サービスプロバイダによってサーバに転送される。リクエストを受信すると、サーバは図6Gのプロセス686に移行する。他方、740において、ボックスはサーバからのレスポンスを待機する。レスポンスが所定の時間内(5秒など)に受信されない場合、リクエストが再送信されてもよい。しかしながら、レスポンスがある時間を超えても受信されなかった場合(ネットワークがダウンしているなど)、739において、エラーメッセージが表示される。
【0167】
742において、レスポンスがサーバから受信される。適切な理由のため、レスポンスはユーザがシステムを利用することを制限するかもしれない。ユーザが制限される場合、プロセス730は743に移行し、ユーザにエラーメッセージを表示する。認証されると、プロセス730は744に移行し、選択されたタイトルに係るファイルのヘッダが再生され、表示装置を介し表示されるかもしれない。
【0168】
746において、サーバからのレスポンスに従って、ボックスは欠落しているセグメントに対する各リクエストを他のボックスに行う。上述されるように、当該レスポンスは、ボックスがこれらの欠落しているセグメントをどこからフェッチすることが可能であるか示すソース情報を含む。例えば、あるファイルに対して4つのセグメントが存在し、ボックスはそのうちの2つしかローカルに格納していない場合、2つのセグメントが他のボックスからフェッチされる必要がある。748において、ボックスは、欠落しているセグメントを供給するため要求されるボックスからのレスポンスを待機する。ボックスの1つが当該リクエストに応答することができない場合、バックアップボックスが当該セグメントを供給するため呼び出されるかもしれない。バックアップボックスがまた当該リクエストに応答することができない場合、ボックスは、さらなるバックアップボックスに対するリクエストをサーバに送信する。何れの場合も、指定されたボックスが発注元のボックスからのリクエストに応答した後、750において、発注元のボックスは指定されたボックスと応答したボックスから欠落しているセグメントのフェッチを開始する。
【0169】
上述されるように、欠落しているセグメントは、所定のスピードで到着することが期待される。ある理由により、ネットワークの一部が混雑し、又はボックス自体が不具合であり、フェッチされるセグメントの大きな遅延が生じる場合、プロセス730は754に移行し、バックアップボックスが中断されたセグメントの供給を継続するよう呼び出される。図7Eにおいて、752及び754の詳細がさらに説明される。
【0170】
所定の最小スピードによりすべてのセグメントがストリーミングされる場合、756において、ローカルに格納されているセグメントの一部及びストリーミングされるセグメントの一部が、図7Dに示されるようなバッファに多重化される。バッファ770、好ましくは、図7Aのメモリ708の一部が、ヘッダ772のデータと共にロードされる。図7Dに示されるようにヘッダ772の一部774がバッファ770kぁら再生された。ヘッダ772の残りの部分776はまだ生成される。それと同時、セグメント778及び780のストリーミングがバッファ770に供給されている。セグメント778〜781(ローカルに格納されているセグメントとストリーミングされるセグメントとを含む)が、バッファ770に多重化される。より詳細には、セグメント1からのデータブロック、セグメント2からのデータブロック、セグメント3からのデータブロック及びセグメント4からのデータブロックが、多重化され、バッファ770に連続的に供給される。この結果、データのもとの順序が復元され、当該タイトルに係るファイルの残りの部分が再構成される。
【0171】
図7Cを参照すると、プロセス730は758に移行し、発注されたタイトルに対するファイル全体が再生されるまで、バッファの再構成されたデータの再生を継続する。その後、プロセス730は732に戻り、ユーザからの他の注文を待機する。
【0172】
図7Dを参照すると、2つのポインタ782と784が示される。各ポインタ782と784は、セグメントのデータブロックがバッファ770に供給されており、又は供給されようとしている場所を記憶するのに利用される。ボックスからフェッチされるセグメントが中断され、バックアップボックスが介入する場合、発注元のボックスは、ポインタに従ってそれが中断された場所からセグメントのフェッチを開始すべき正確な場所を知ることができる。同様に、類似したポインタ(図示せず)が、ローカルにキャッシュされたセグメントのデータブロックがバッファ770に供給されている、又は供給されようとする場所を記憶するため設けられてもよい。発注元のボックスがリセットされる必要がある場合、又は突然に電源オフされ、バックオンされる場合、これらのポインタは注文されたタイトルの再生の連続性を実現することを可能にする。
【0173】
ボックスが、ライブラリのすべてのタイトルからの所望のタイトルの検索の実現、ユーザからの注文の実現、1以上のセグメントの他のボックスへの供給、リリースに応答したライブラリの更新、及びそれの状態若しくはネットワーク状態のサーバへの通知などのいくつかのタスクを実行可能であることが説明された。すべてのタスクは等しく重要であるが、一部は他のものより優先されてもよい。
【0174】
図7Eを参照すると、一実施例によるボックスにおけるタスクの優先順位付けを行うフローチャート又はプロセス784が示される。当該プロセス784はシステムをより効率的にするかもしれないことに留意すべきである。インストール持には、ボックスはセグメントを他のボックスに供給又はアップロードすることを要求されない。ボックスは、786において、それの状態をサーバ(図2Aの202など)に定期的に若しくは所定の時間に通知し、それのライブラリへのリリースの更新のため相手のボックスと同期し、又はボックスの全体的なパフォーマンスに影響を与える可能性のある他の処理を実行するよう構成される。サーバへの通知時、ボックスはそれの動作状態を示す状態を送出する。一実施例では、ボックスは公衆ネットワークに接続され、動的なIPアドレスが割り当てられる。ボックスがサーバと他のボックスと通信中であることを保証するため、ボックスは、IPアドレスの変更をサーバに通知するよう構成される。
【0175】
ボックスは、待機モードに入るか、又は786において他の処理を実行する。ボックスが788において1以上のセグメントを発注元のボックスに供給するための候補である可能性がるため、プロセス784は、ボックスが何れかのセグメントを他のボックスに供給するよう要求されたかチェックする。このようなリクエストが受信されていない場合、ボックスは786に戻り、それが実行していたものを実行し続ける。しかしながら、788において発注元のボックスからリクエストを受信すると、プロセス784は790に移行し、ボックスに常駐する多数のセグメントから要求されたセグメントを特定する。792において、ボックスは、アップロード帯域幅が十分なものであるかチェックする。リクエスト時に利用可能なアップロード帯域幅はWであり、セグメントをアップロードするのに要求される帯域幅はRであると仮定される。W>Rである場合、プロセス784は796に移行し、それは存在する場合には、アップロード帯域幅を使用している処理に関係しないことを意味する。W<Rである場合、プロセス784は794に移行し、存在する場合には、アップロード帯域幅を利用している他の何れかの処理が即座に中止される。アップロード帯域幅を利用する処理の具体例として、相手のボックスによって要求されたリリースパッケージのアップロード又は新規ボックスの提供などがあげられる。
【0176】
このような処理が中断された後、プロセス784は796に移行し、要求されたセグメントを発注元のボックスにアップロードする。798において、要求されたセグメントのアップロードが終了したか判断される。終了していない場合、アップロードが継続される。要求されたセグメントがアップロード終了した場合、プロセス784は786に移行し、当該ボックスが実行していたこと又は実行が中断されているものを復元又は継続する。
【0177】
プロセス784は1つのセグメントをアップロードするため説明されることに留意すべきである。当業者は、プロセス784がアップロード帯域幅が許す場合、複数のセグメントのアップロードに適用可能であることを理解するであろう。上位バンドの複数のセグメントが典型的にはボックスに常駐していることが上述された。発注元のボックスへのボックスのアップロード帯域幅が複数のセグメントをアップロードするのに十分であるとき、一実施例では、選択されたタイトルの再生が他のボックスにあまり依存しなくなるように、このようなボックスは複数のセグメントをアップロードするよう指定されるかもしれない。
【0178】
図8は、本発明の多数の特徴が等しく適用されるアーキテクチャ800を示す。アーキテクチャ800は、図2Aのアーキテクチャのすべての機能を含むかもしれない。図2Aのアーキテクチャのエンハンスメントとして、アーキテクチャ800は、すべての分散オブジェクトを格納するサーバデータベースを有する。分散オブジェクトを格納することによって、サーバは、バックアップボックスの故障時、初期的なバックアップボックスとして、帯域幅が利用可能なときは発注元のボックスをサポートするかもしれない。
【0179】
発注元のボックスによるタイトルに対するリクエストに応答して、サーバは発注元のボックスに直接的に応答する必要がないことが理解されるべきである。サーバ202は、分散オブジェクトを発注元のボックスに提供する命令を分散したボックスに提供することによって応答してもよい。サーバ202は、分散したボックスに自らのサービスを自発的に申し出るよう要求することによって応答してもよい。サーバによる他の多くのレスポンスがまた可能である。発注元のボックスによるリクエストがサーバに送られる必要がないことがさらに理解されるべきである。例えば、ボックスにはネットワーク構成マップが与えられ、これにより、ボックスは他のボックスに直接リクエストすることが可能となり、再生リクエストのためのサーバ帯域幅の利用を回避することができる。
【0180】
当業者は、システムの各要素がソフトウェアにより実現されてもよいが、ハードウェア又はハードウェアとソフトウェアとの組み合わせにより実現可能であることを認識するであろう。本発明はまた、コンピュータ可読媒体上のコンピュータ可読コードとして実現可能である。コンピュータ可読媒体は、以降においてコンピュータシステムにより読み取り可能なデータを格納することが可能な任意のデータストレージ装置とすることが可能である。コンピュータ可読媒体の具体例として、以下に限定するものではないが、ROM(Read−Only Memory)、RAM(Random−Access Memory)、CD−ROM、DVD、磁気テープ、ハードディスク、光データストレージ装置又は搬送波を含むかもしれない。コンピュータ可読媒体はまた、コンピュータ可読コードが格納され、分散形式により実行されるように、ネットワークに接続されたコンピュータシステムに分散化することも可能である。
【0181】
本発明の可能な効果は多数ある。異なる実施例又は実現形態は、以下の特徴及び効果の1以上をもたらすかもしれない。それらの1つは、メディア・オン・デマンドシステムにおける瞬時の特徴である。ローカルにキャッシュされたタイトルに係るファイルの小さな部分によって、ファイルの残りの部分が1以上のボックスにセグメントにより分散される。あるタイトルが発注されると、ユーザが認証され、支払が適切に決済されている場合、ローカルにキャッシュされた部分が即座に再生され、このローカルにキャッシュされた部分の再生中に、残りの部分がタイトルの再生を継続させるためにストリームとしてボックスからフェッチされる。それらのうちの他の1つは、ファイルの細分化方法である。タイトルに係るファイルが与えられると、ファイルはヘッダと複数のセグメントに細分化される。ヘッダはファイルの連続的な部分であり、各セグメントは、ファイルの残りの部分の間引きされた部分である。セグメントがフェッチされているとき、セグメントは再生のためもとのデータの順序を復元するため多重化される。さらなる他の可能な特徴及び効果は、ボックスが他のボックスにサービスを提供することを禁止することなく、ボックスのライブラリを同期的に又は非同期的に更新するための基礎となるメカニズムである。リリースが利用可能になると、ローカルにキャッシュされるべきリリースパッケージが、中央サーバから送信される代わりに、他のボックスから当該ボックスに非同期的に伝搬される。他の特徴及び効果もまた可能である。
【0182】
上記実施例の説明は、本発明の各種特徴/実施例の例示である。添付された請求項によって規定されるような本発明の真の趣旨及び範囲から逸脱することなく、本発明に対する様々な変更が当業者により好適な実施例に対して可能である。例えば、一実施例では、ファイルのヘッダのサイズはゼロまで減少してもよく、すなわち、ファイルはボックスに分散可能な複数のセグメントに細分化される。また、タイトルが発注されると、サーバは、当該注文のためのデータを供給するソースを特定し、その後、発注元のボックスがソースとの通信を開始することを要求する代わりに、これらの供給元自体にデータ転送を開始するよう接続する。実際、発注元のボックスは、サーバが供給元のボックスを特定することを要求する代わりに、タイトルの各セグメントをキャッシュするボックスからソース情報を動的に取得することも可能である。従って、本発明の範囲は、上記実施例の説明でなく添付した請求項によって規定される。
【図面の簡単な説明】
【0183】
【図1】図1は、サーバ・アンド・クライアントアーキテクチャとも呼ばれるネットワークを介しビデオサービスを配信するのに通常利用されるビデオ配信システムを示す。
【図2A】図2Aは、本発明の実施例による分散ネットワークシステムを示す。
【図2B】図2Bは、一実施例によるヘッダと4つのセグメントに細分化又は構成されたファイルを示す。
【図2C】図2Cは、タイトルの再生を継続するため、ボックスがローカルにヘッダを格納し、他の4つのボックスから4つのセグメントを受信する状況を仮定する場合に、1つのヘッダと4つのセグメントを有するタイトルに係るファイルを示す。
【図2D】図2Dは、ヘッダとして割り当てられた始めの部分と、4つのセグメントに間引きされる残りの部分とによるファイルを表すデータストリームを示す。
【図2E】図2Eは、一実施例による複数のボックスに分散させるためファイルを細分化するフローチャート又はプロセスを示す。
【図3A】図3Aは、ボックスの限られた格納スペース内のライブラリのタイトルの一例となる人気による分類を示す。
【図3B】図3Bは、ボックスの限られた格納スペース内のライブラリのタイトルの他の例となる人気による分類を示す。
【図3C】図3Cは、ライブラリのタイトルの人気に従う一例となるバンド化方式を示す。
【図3D】図3Dは、図3Cに示されるバンド化に従う連続再生のためのバンドの各タイトルの対応する依存性を示す。
【図3E】図3Eは、一実施例による瞬時のアクセスのための多数のタイトルのライブラリを分類するフローチャート又はプロセスを示す。
【図3F】図3Fは、一実施例によるボックスのライブラリを更新するフローチャート又はプロセスを示す。
【図4A】図4Aは、一実施例によるサービス提供中のすべてのボックスのライブラリを同期的に又は非同期的に更新する図を示す。
【図4B】図4Bは、一実施例によるサービス提供中のボックスにおいてリリースを提供するフローチャート又はプロセスを示す。
【図4C】図4Cは、サービスプロバイダに高帯域幅ブロードキャスト機能のインフラストラクチャが設けられた一例となる状況を示す。
【図4D】図4Dは、ブロードキャスト若しくはマルチキャストのための帯域幅が十分な構成の対するサービス提供中のボックスにおいてリリースを提供する一例となるフローチャート又はプロセスを示す。
【図5A】図5Aは、一実施例による新規ボックスのライブラリに対する段階的な変更を示す。
【図5B】図5Bは、3つの新規ボックスがシステムに追加される一例となる状況を示す。
【図5C】図5Cは、ある期間オンラインでなく、このため古いライブラリを有することとなったボックスのライブラリを更新するフローチャート又はプロセスを示す。
【図6A】図6Aは、本発明によるサーバの一実現形態を示す。
【図6B】図6Bは、5000タイトルのライブラリがN個のボックスにどのように分散されるか示す一例となるマップを示す。
【図6C】図6Cは、発注されたタイトルのセグメントを供給するよう指定された4つのボックスのそれぞれに対するIPアドレス(IPA1など)を含むテーブルとして一例となるソース情報を示す。
【図6D】図6Dは、指定された各ボックスのバックアップ識別子(IPアドレスとして示される)を有するテーブルのバックアップボックスによる一例となるソース情報を示す。
【図6E】図6Eは、指定された3つのボックスが他の3つのボックスによりそれぞれバックアップされ、発注元のタイトルに係る3つのセグメントがそれぞれ発注元のボックスに提供される3つの指定されたボックスにより発注元のボックスがサポートされている一実施例を示す。
【図6F】図6Fは、指定された3つのボックスが他の発注元のボックスをサポートする他の指定されたボックスを同時にバックアップする他の3つのボックスによってそれぞれバックアップされる発注元のボックスが3つの指定されたボックスによりサポートされている他の実施例を示す。
【図6G】図6Gは、ライブラリのセレクション(すなわち、タイトル)の瞬時の再生を開始するフローチャート又はプロセスを示す。
【図7A】図7Aは、図2Aの何れのボックスに対応するボックスの一実現形態を示す。
【図7B】図7Bは、本発明の一実施例によるセレクション(すなわち、タイトル)の瞬時の再生を開始するフローチャート又はプロセスを示す。
【図7C】図7Cは、本発明の一実施例によるセレクション(すなわち、タイトル)の瞬時の再生を開始するフローチャート又はプロセスを示す。
【図7D】図7Dは、本発明の一実施例による再生されている第1部分が終了するとすぐに、再生用のデータストリームを生成するため4つのセグメントのストリームの多重化を示す。
【図7E】図7Eは、本発明の一実施例によるボックスにおけるタスクを優先順位付けするフローチャート又はプロセスを示す。
【図8】図8は、本発明の多くの特徴が等しく適用されるアーキテクチャを示す。
【技術分野】
【0001】
本発明は、一般にインターネットを介したマルチメディア配信に関する。特に、本発明は、適切に組み合わされるとき、サービスを含む瞬時のメディア・オン・デマンド(MOD)を提供するための技術、システム及び方法に関する。さらに、本発明は、ユーザが選択し、瞬時に再生可能な多数のタイトルのダイナミックライブラリを提供する技術に関する。
【0002】
[関連技術の説明]
年長者が火の近くで物語を話し、又は夕食時に家族がテレビの前に座ったりするが、人間は生来的に物語を聞き、楽しむという欲求を有している。各家庭がどれほど多くのテレビ及び/又はラジオを有しているか信じることはできない。実際、すべての家庭は2.3台のテレビを所有し、人々は1日に平均して5時間もテレビを視聴していると推定されている。これらの統計や人々の傾向は、ケーブルプロバイダ、衛星プロバイダ、ビデオレンタル企業、Blockbuster Inc.、NetFlix.comなどが、映像、テレビ及び映画配信、プレミアム映画チャンネル、ペイ・パー・ビューなどを顧客に提供するため数百万ドルを投資する動機付けを提供する。
【0003】
従来、各テレビ視聴者は、いくつかの番組を提供する4つ又は5つのテレビチャンネルを有し、よりエキサイティングな映画コンテンツを観るため映画館に行くことで満足していた。しかしながら、現在の視聴者は、より高い要求をするようになり、多様なより洗練されたドラマ、コメディ、アドベンチャー、ホラーなどを含むより多くのものを自宅のテレビから期待するようになってきている。この要求を満足させるため、テレビ視聴者の大多数はケーブル若しくは衛星サービスに加入している。この基本サービスは、通常のテレビよりかなり多数のチャンネルとプレミアム放送を提供するだけである。
【0004】
依然として顧客は不満足なままである。このため、ケーブル及び衛星サービスは映画チャンネル契約を提供している。各映画チャンネルは、予め選択された時間に限られた数の比較的新しい映画配信のリリースを提供する。視聴者は、映画リストと映画スケジュールとを確認し、それらが提供されるときに選択された映画を視聴することを計画することができる。視聴者がその時間にテレビをオンすると、視聴者は始めからその映画を視聴することができる。そうでない場合、視聴者は途中から開始される映画を視聴しなければならないかもしれない。あるいは、視聴者は自らに都合のよい時間に視聴するため映画を記録することができる(TiVo Inc.によって提供されるものや従来のVCRなどのデジタルビデオレコーダを利用して)。これらの映画チャンネルによって提供される映画の本数は限られているため、より厳格な視聴者は現在提供されているすべての所望される映画を記録するかもしれず、さらなるタイトルが利用可能になるまで待機しなければならいかもしれない。映画チャンネルにより提供される映画数は限られており、これらの映画は不定期的な時間に開始されるため、映画チャンネルは現在の顧客の要求を効果的に充足するものでない。
【0005】
“ビデオ・オン・デマンド”の顧客アピールは周知である。一般に、真のビデオ・オン・デマンドは、利用可能な所望されるすべての映画のリストから選択可能な映画(又は他のコンテンツ)の瞬時の視聴として特徴付けすることが可能である。理想的には、サーバ若しくはサーバ群がすべての映画を格納し、顧客が映画を選択することを可能にし、顧客がネットワークの中断なく映画を視聴する間に、映画を顧客にストリーミングする。しかしながら、現在の技術及びネットワーク関連インフラストラクチャの多くの問題点によって、真のビデオ・オン・デマンドは公衆には現在利用可能でない。衛星、ケーブル及びDSLネットワークにおける通信容量及び速度は、不十分なものであり、信頼性が低く、予測不能で整合性を有していない。この不十分で不整合な通信容量及び速度のため、真のビデオ・オン・デマンドが利用可能になった場合、現在のシステムの視聴者は、所望しない中断や他のエラー動作を解決する必要が生じるであろう。真のビデオ・オン・デマンドは、おそらく数年間は公衆には利用可能とはならず、より高速ではるかに高い信頼性と予測可能性を備えた通信チャネル(光ファイバなど)が使用され、より速い計算が確立された後になって始めて利用可能となるであろう。
【0006】
限定的な環境では、真のVODは、大容量及び高速性を維持及び配信可能な特化した信頼性の高いネットワークを利用して現在提供される。ケーブルの“オン・デマンド”は、このようなサービスの1つである。ユーザが高速のデジタルネットワークに接続される場合に限って、またサービスプロバイダがVODをサポート可能である場合に限って、オン・デマンドは再生のため映画を瞬時にダウンロードすることが可能である。このサービスは、従来のブロードバンド接続を介しては利用可能でない。
【0007】
ここで図1を参照すると、ネットワークを介しビデオサービスを配信するのに利用されるビデオ配信システム100が示される。ビデオ配信システム100は、ときどきヘッドエンドと呼ばれるビデオサーバ102を有する。データネットワーク104を介し、ビデオサーバ102は、各クライアントマシーン106−1,106−2,...,106−n(すなわち、それの加入者)に連続するスケジューリングされたビデオ・オン・デマンド(VOD)サービスを提供することができる。なお、システム100は、1つのサーバ102が複数のクライアントマシーン106−1,106−2,...,106−nにサービスを提供するという典型的なクライアント・サーバアーキテクチャとなっている。サーバ102はさらに、各種メディアファイル(映画やニュース映像など)を格納するよう構成可能なメディアストレージ装置に接続される。メディアストレージ装置112は、オンラインであることが求められ、クライアントマシーン106−1,106−2,...,106−nの何れかへの配信がスケジューリング又は要求されるタイトルを格納及び供給しなければならない。
【0008】
QoS(Quality of Service)を保証するため、各クライアントマシーン106−1,106−2,...,106−nとのネットワークパス(108−1,108−2,...,108−nなど)のバンド幅要求は十分なものでなければならない。しかしながら、加入者数が増加し続けるに従って、バックボーンネットワークパス110のバンド幅に対する要求は線形に増大し、システム100の全体的なコストもそれと同時に大きく増大する。サーバが固定されたバンド幅制限を有し、システムが能力をサポートする場合、ある閾値を超えた加入者数の増大は、クライアントへのデータ転送を低速化する。すなわち、ネットワーク104上でのビデオデータのクライアントマシーン106−1,106−2,...,106−nを介した加入者への送信は、もはや保証されない。ビデオデータが時間通りにクライアントマシーンに受信されないとき、ビデオデータの表示は不可となるか、少なくとも苛つかせるものとなるかもしれない。
【0009】
ビデオサーバ102へのこのようなロード問題を軽減するため、ビデオ配信システムはしばしば、おそらく複数の場所にある複数のビデオサーバを利用する。各ビデオサーバは、ビデオサーバ102と同様に、限定数の加入者をサポートするよう構成される。加入者数がビデオサーバの容量又はそれのバンド幅を超えるとは常に、追加的なビデオサーバが配備されるか、又は追加的なバンド幅が割り当てられる必要がある。このため、より多くの加入者がビデオ配信システム100にサインアップすると、全体的なコストは大きく増大する。
【0010】
ビデオ・オン・デマンドの制約に対するシンプルな解決策として、ケーブル及び衛星プロバイダは、ペイ・パー・ビュー、すなわち、ビデオレンタルの価格とほぼ同額で平均して30分毎に開始される限定数のより新たなリリースを提供する。ペイ・パー・ビューによってでさえ、顧客は限定されたセットから映画を選択しなければならず、依然として配信開始まで待機しなければならい。さらに、セットトップボックスがサービスプロバイダとの双方向通信をサポートしていない場合には、顧客は選択された映画を発注するため、不便なことにサービスを電話連絡しなければならい。ペイ・パー・ビューは、真のビデオ・オン・デマンドに対するあまり効果的でない解決策である。
【0011】
いくつかのケーブル及びインターネット企業は、真のビデオ・オン・デマンドに対する他の代替策を検討している。現在のより良い代替的なシステムの1つは、視聴者が映画を選択、発注、ダウンロード及び視聴することを可能にする。しかしながら、低速のダウンロードスピードとかなりの映画サイズのため、視聴者は映画をダウンロードするため、例えば、1〜2時間などかなりの時間待機しなければならい。ペイ・パー・ビューより良好な多数の方法においてでさえ、この選択肢は理想とはほど遠いものである。この解決策は、映画の受信前に長時間顧客を待機させ、顧客に即座の満足感を提供することができず、多くの購入者の衝動性を利用することができない。
【0012】
衛星プロバイダは、特に真のビデオ・オン・デマンド若しくは現在の代替策を提供することが困難であろう。なぜなら、衛星通信はリターンパスを提供せず、すなわち、衛星プロバイダから顧客への一方向のみの通信しか提供しないため、また配信(すなわち、ポイント・ツー・マルチポイント)に十分な衛星バンド幅はポイント・ツーポイント通信には不十分であるためである。このとき、顧客は、ある双方向通信モードなしに映画の選択肢を熟読し、映画をリクエスト等することができない。衛星ネットワークの限定的な能力のため、衛星プロバイダは、ケーブル、インターネットブロードバンド、VoIP(Voice over IP)及び他のネットワークサービスを提供することが可能なケーブルプロバイダに対してかなり不利である。
【0013】
Blockbuster Inc.やNetflix,Inc.などの各企業は、より多くの映画選択肢を顧客に提供しようとするビジネスモデルを構築してきた。しかしながら、Blockbusterは、顧客がソファから離れ、支度をし、望ましくは地域の事業所に行き、映画(しばしば利用可能でない)を選択し、映画を開始することが可能になる前に自宅に戻ることを要求する。Netflixは、顧客が多くのリストから映画を発注することを要求するが、要求された映画を従来のポストを用いて郵送する。顧客は、リクエストした映画を受け取るまで少なくとも数日待つ必要がある。これら2つのモデルは、“オン・デマンド”を提供するものでない。
【0014】
従って、ユーザが大きなライブラリから所望のタイトルを選択し、発注したタイトルを瞬時に視聴することを可能にする瞬時のVODシステムが要求される。
【0015】
[概要]
本セクションは、本発明の実施例のいくつかの特徴を要約し、好適な実施例を簡単に紹介する。本セクション並びに本開示のタイトル及び要約の簡単化及び省略は、本セクション、タイトル及び要約の目的を不明りょうにすることを回避するため行われるかもしれない。このような簡単化又は省略は、本発の範囲を限定するものでない。
【0016】
概略すると、本発明の実施例は、データネットワークを介しメディアサービスを提供するための技術に関する。ここに記載される技術は、互いに関連するものであり、それぞれは当該技術において独立に新規なものであると思料する。開示された技術は、新規かつ非自明なシステム若しくはシステムの一部を提供するため、単独で若しくは何れかの組み合わせにより実行されるかもしれない。それらの最も広範な意味で組み合わされた場合でさえ、すなわち、各技術が実践のため減縮された具体的方法未満によって、組み合わせた技術が等しく独立な新規な組み合わせをもたらすことが理解されるべきである。
【0017】
本発明の実施例は、データネットワークを介しメディアサービスを提供するための各種技術に関する。一特徴によると、適切に組み合わされると、当該技術の一部は瞬時のメディア・オン・デマンドシステム、それと等価なプロセス及びメソッドを提供することが可能である。メディアサービスが中央サーバにおいてレンダリングされる従来のシステムとは大きく異なって、本発明の実施例はネットワーク上の各装置を利用して、要求されるサービスを提供するため、必要とされるサービスを細分化して互いに供給する。この結果、サーバに対するロード要求が、ネットワークに分散化される。
【0018】
本発明の他の特徴によると、システムは、ユーザが所望するときは常にタイトルを選択及び発注可能な多数のタイトルを有するライブラリを提供し、タイトルに係るファイルの始めの部分にアクセスすることによってタイトルをほぼ瞬時に再生する。データの始めの部分はローカルにキャッシュされ、データの残りの部分は他の指定された装置によって供給される。ライブラリは、リリース(新たな又は人気のあるタイトルなど)により動的に更新される。
【0019】
本発明のさらなる他の特徴によると、タイトルに係るファイルが、ヘッダと複数のテール若しくはセグメントに細分化される。ヘッダは、ファイルの連続部分であり、セグメントは、ファイルの残りの各部分である。ヘッダは、実質的にすべてのボックスに提供され、セグメントは、サービス提供中の各ボックスにその少なくとも1つしか又は全く配信されない。タイトルが発注されると、ヘッダが瞬時に再生され、その間にローカルに利用可能でない場合には、セグメントがストリーミングされるか、若しくはセグメントを有する他のボックスからそれぞれ連続的にフェッチされる。ファイルの残りの部分を復元し、タイトルの再生を継続するため、同時にフェッチされたセグメントからのデータが、存在する場合にはローカルにキャッシュされているセグメントからのデータと共に多重化される。
【0020】
本発明のさらなる他の特徴によると、ネットワーク帯域幅を最大限活用し、QoS(Quality of Service)を最大化するため、大きなファイルがインテリジェントに細分化され、これらのセグメントが分散化される。ヘッダサイズとセグメント数は、要求されるタイトルの転送レート、利用可能な最小のネットワークスピードなどに従って定期的に計算又は決定される。
【0021】
本発明のさらなる他の特徴によると、サービス提供中の各ボックスのライブラリが、同期的に又は非同期的に更新される。ライブラリを更新するためのリリースは、サービス提供中のすべてのボックスにgossipプロトコルによりデータチャンクを伝搬することによって実行される。その後、適切なリリースパッケージが、ライブラリを更新するため、受信したデータチャンクから各ボックスにおいて復元される。サービスプロバイダに高帯域幅ブロードキャスト若しくはマルチキャスト機能が備えられているケースでは、ヘッダと複数のセグメントに細分化されるリリースは、ライブラリを更新するため適切なリリースパッケージを受信するようそれぞれ構成されるすべてのボックスに送信される。
【0022】
本発明のさらなる他の特徴によると、新たにインストールされ、又はある期間後にネットワークに戻されたボックスは、例えば、サービス提供を開始するため可能な最短時間などにより効率的に更新される。このようなボックスのもとのライブラリは、最も需要のあるタイトルによって、最初の若しくは可能な少なくともデータ量により更新され、これにより、ボックスは、最も需要のあるタイトルに対する注文を実現するためだけでなく、必要なデータを他のボックスに提供するための状態にすぐになるかもしれない。実現形態に応じて、ボックスのもとのライブラリの更新は、最新のタイトルをまとめて有する他のボックスからgossipプロトコルによってデータチャンクを受信することによって、又はブロードキャスト若しくはマルチキャストインフラストラクチャを介しサービスプロバイダから適切なリリースパッケージを受信することによって実行されてもよい。
【0023】
本発明のさらなる他の特徴によると、ボックス間に転送されるすべてのデータが遅延若しくは中断しないように、データを発注元のボックスに提供するよう指定されたボックスをサポートするため、バックアップボックスが設けられる。ボックスの1つが低パフォーマンスによりデータを発注元のボックスに提供する場合(例えば、ボックスの動作上の問題又は所望されないネットワークパフォーマンスにより)、低パフォーマンスのボックスを置換若しくは支援し、発注元のボックスへのデータの供給を継続するため、バックアップボックスが起動されるかもしれない。本発明の他の特徴は、ここでの詳細な説明から当業者により理解されるであろう。
【0024】
本発明の実施例は、方法、システム、装置若しくはコンピュータ可読媒体を含む各種方法により実現されるかもしれない。本発明のいくつかの実施例が以下に説明される。一実施例では、本発明は、ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、発注元のボックスからライブラリのタイトルの注文を含むリクエストを受信するステップと、前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する1以上のボックスを特定するステップとを有し、前記発注元のボックスは、前記1以上のボックスから前記タイトルに係る分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生することによって前記タイトルの再生を進行する方法を提供する。
【0025】
他の実施例では、本発明は、ボックスのライブラリのすべてのタイトルの視聴機構を提供する方法を提供する。本方法は、ボックスのタイトルのライブラリからタイトルの選択を可能にするステップと、前記タイトルの1つが選択されると、タイトル情報を含むリクエストを生成するステップと、前記発注されたタイトルに係る1以上の分散オブジェクトを提供する1以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するステップと、前記発注されたタイトルに係る前記ボックス内の常駐オブジェクトの再生を開始するステップと、前記常駐オブジェクトの再生中に一部が受信される1以上のデータストリームとして、前記1以上のボックスから前記1以上の分散オブジェクトを受信するステップと、前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記1以上のデータストリームの再生を開始するステップとを有する。
【0026】
さらなる他の実施例では、本発明は、ネットワークを介しメディア・オン・デマンドサービスを提供するシステムを提供する。本システムは、各ボックスがネットワークに接続され、ユーザに関連付けされ、タイトルのライブラリを提供し、複数のヘッダと複数のセグメントが常駐することを可能にする格納スペースを有し、タイトル選択情報を有するリクエストを提供するよう構成される複数のボックスと、前記ネットワークに接続され、前記ボックスの1つである発注元のボックスからのリクエストに対するレスポンスを提供するよう構成されるサーバとを有し、前記レスポンスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう構成されるボックス群を特定するソース情報を含み、前記レスポンスに応答して、前記発注元のボックスは、前記ボックス群から1以上の分散セグメントをダウンロードしながら、前記選択されたタイトルに係るヘッダの再生を開始する。
【0027】
さらなる他の実施例では、本発明は、ネットワークに分散されるオブジェクトを管理するシステムを提供する。本システムは、各ボックスが、ネットワークに接続され、ユーザに関連付けされ、それぞれがヘッダといくつかのセグメントとにより表されるタイトルのライブラリを提供し、各タイトルについてヘッダと0以上のセグメントとをローカルにキャッシュするための格納スペースを有する複数のボックスと、タイトルの1つの注文を含むリクエストをボックスの1つ(発注元のボックス)から受信した後、レスポンスを提供するよう構成される計算装置とを有し、当該レスポンスは、セグメントのすべてが発注元のボックスにローカルにキャッシュされていない場合、タイトルに係る欠落しているセグメントを提供するよう指定された供給元のボックス群を特定するソース情報を有する。一般に、ライブラリは、いくつかのグループ若しくはバンドに分割され、バンドの1つ(上位バンド)は、最も需要のなるタイトルのいくつかを有し、他のバンド(低バンド)は、最も需要の低いタイトルのいくつかを有する、1つのケースでは、上位バンドのタイトルのセグメント数は、低バンドのタイトルのセグメント数より多く、これは、上位バンドの各タイトルに対して低バンドのタイトルに対するよりも多くの分散コピーをもたらす。
【0028】
さらなる他の実施例では、本発明は、タイトルに係るファイルを細分化する方法であって、ファイルを第1部分と第2部分に分割されたデータブロックシーケンスに分割するステップと、ヘッダのデータブロックが連続的なものとなるように、第1部分のデータブロックからヘッダを形成するステップと、各セグメントのデータブロックが不連続なものとなるように、各セグメントが第2部分のデータブロックの一部を有するN個のセグメントを形成するステップとを有する(ただし、Nは1より大きな有限の整数である)。ファイルは、存在する場合には、補助データを伴うデータのコレクションである。ヘッダは、常駐オブジェクトとしてサービス提供中の各ボックスにローカルにキャッシュされ、N個のセグメントのうちのM個のセグメントがボックスに格納される。ここで、Mの値は、タイトル毎及びボックス毎に異なり、0≦M≦Nである。
【0029】
さらなる他の実施例では、本発明は、ライブラリを動的に更新し続ける方法を提供する。本方法は、サービス提供中の各ボックスのライブラリを更新するためリリースに含まれるタイトルに係るファイルをデータチャンクシーケンスに分割するステップと、各提供ボックスがデータチャンクの少なくとも一部を受信し、データチャンクをまとめて受信する初期的な提供ボックス群を指定するステップと、各提供ボックスに受信したデータチャンクの少なくとも一部若しくはすべてをボックス群に伝搬させるステップとを有し、ボックス群の各ボックスは、サービス提供中の各ボックスがデータチャンクの指定された部分を受信するまで、ボックス間に受信したデータチャンクの一部若しくはすべての拡散を継続するよう選択された他のボックスに受信したデータチャンクを再帰的に伝搬する。実質的に、各ボックスは、受信指定されたものを受信する。本方法はさらに、受信したデータチャンクの一部若しくはすべてからヘッダと0以上のセグメントとを各ボックスに復元させ、その後、それのライブラリを更新する。
【0030】
さらなる他の実施例では、本発明は、新たにインストールされた装置においてコンテンツを更新する方法であって、メディアサービスを提供するシステムに新たなボックスが検出されると、ライブラリのいくつかの古いタイトルを決定するステップと、ライブラリに追加し、ライブラリから古いタイトルを排除するため、対応する見逃したタイトルを決定するステップと、ボックスが相対的に新たらしいタイトルの1つの注文に対してサービスを提供する準備ができるように、ボックスに見逃したタイトル群の中の相対的に新しいタイトルに係るデータをまず抽出させるステップと、ボックスが完全に更新されるまで、残りの見逃したタイトルに係るデータをボックスに抽出させ続けるステップとを有する方法を提供する。1つのケースでは、ボックスは、相対的に新しい各タイトルのヘッダを抽出し、その後、それぞれに対する複数のセグメントの1つを抽出する。他のケースでは、ボックスは、タイトルの人気の降順により相対的に新しい各タイトルのヘッダと複数のセグメントの1つを抽出する。
【0031】
さらなる他の実施例では、本発明は、分散環境においてデータを転送する方法を提供する。本方法は、ネットワーク上の計算装置によって提供されるソース情報に従って、要求されるデータセグメントを供給するよう指定された各ボックスとの通信セッションが確立されているか判断するステップと、通信セッションが指定された各ボックスと良好に確立された後に限って、指定されたボックスから必要とされるデータセグメントを同時にダウンロードするステップとを有し、必要とされる各データセグメントは、ファイルを表すデータブロックシーケンスからサンプリングされた複数のデータブロックを有する方法を提供する。
【0032】
さらなる他の実施例では、本発明は、ライブラリを動的に更新し続ける方法であって、ライブラリを更新するための少なくとも1つのタイトルを含むリリースをデータパッケージにより準備するステップと、サービス提供中のボックスに送信インフラストラクチャを介しデータパッケージを送信するステップとを有し、各ボックスはデータパッケージの少なくとも一部をローカルにキャッシュするよう構成され、ボックスのすべてがデータパッケージの同一部分をキャッシュしていない方法を提供する。実現形態に応じて、送信インフラストラクチャは、ブロードキャスト若しくはマルチキャスト可能であってもよい。データパッケージは、タイトルのヘッダと複数のセグメントを有する。各ボックスにローカルにキャッシュされるデータパッケージの一部は、ヘッダと0以上のセグメントとを有する。あるいは、データパッケージは、各リリースパッケージがヘッダと0以上のセグメントを含む複数のリリースパッケージを有する。
【0033】
本発明の1つの課題は、適切に組み合わされたとき、瞬時のメディア・オン・デマンドシステムを提供するのに効果的に利用可能な技術を提供することである。
【0034】
本発明の他の課題、特徴及び効果は、添付した図面と共にそれの実施例の以下の詳細な説明を参照することにより明らかとなるであろう。
【0035】
[発明の詳細な説明]
本発明の実施例は、データネットワークを介しメディアサービスを提供するための各種技術に関する。これらの技術の一部は、適切に組み合わされるとき、瞬時のメディア・オン・デマンドを提供することが可能である。一実施例は、ユーザがほとんど瞬時に再生のため選択及び発注可能な多数のタイトルを備えたダイナミックライブラリを提供するかもしれない。瞬時の再生を実現するため、タイトルに係るファイルがヘッダと複数のセグメント(又はテール)に細分化されるかもしれない。一実施例では、ヘッダはすべてのボックスに設けられ、各セグメントは、ある方式に従ってネットワーク内でこれらのボックスに配信される。タイトルが発注されると、ヘッダは即座に再生可能となり、セグメントは、それがローカルに利用可能でない場合には、サポートするボックスからストリーミングすることが可能である。同時にフェッチされる各セグメントからのデータは、必要に応じて、ファイルの残りの部分を復元し、発注されたタイトルの再生を継続するため、ローカルにキャッシュされたセグメントに多重化することが可能である。
【0036】
さらに一実施例では、サービスを提供する各ボックスのライブラリは、例えば、gossipプロトコルなどを利用して、データチャンクをサービス提供中のすべてのボックスに伝搬することによって、同期的に若しくは非同期的に更新されるようにしてもよい。システムに新たにインストールされた若しくは一定期間後に戻されたボックスは、サービスの提供を開始するためすぐに更新することが可能である。本発明の他の可能な特徴及び効果は、実施例により本発明の原理を示す添付した図面と共になされる以下の詳細な説明から明らかになるであろう。
【0037】
以下の説明では、本発明の完全なる理解を提供するため、多くの具体的詳細が提供される。本発明は、これらの具体的詳細なしに実現可能である。ここでの記載及び表示は、研究の本質を他の当業者に効果的に伝えるため、当業者によって使用される手段である。他の例では、周知の方法、手順、コンポーネント及び回路は、それらがすでに十分に理解されているため、また本発明の特徴を不要に不明りょうにすることを回避するため、詳細には説明されていない。
【0038】
ここでの“一実施例”若しくは“ある実施例”という表現は、当該実施例に関して説明される特定の機能、構成若しくは特徴が本発明の少なくとも1つの実現形態に含めることが可能であることを意味する。明細書中の各箇所における“一実施例”という表現は、必ずしもすべてが同一の実施例を参照しているとは限らず、他の実施例の相互に排他的な別個の若しくは他の実施例でもない。さらに、1以上の実施例を表すプロセス、フローチャート若しくは機能図における各ブロックの順序は、本来的に特定の順序を示すものでなく、また本発明の各限定を意味するものでもない。
【0039】
便宜上、いくつかの用語の定義が以下に与えられる。これらの定義は一実施例による本発明の理解及び記載を容易にするためのものであることに留意すべきである。これらの定義は、実施例に関する各限定を含むように見えるかもしれない。しかしながら、これらの用語の実際の意味は、このような実施例を超えた適用性を有するかもしれない。
【0040】
メディア又はビデオは、ここでは互換的に使用され、マルチメディアデータを示すものであり、その集合体は、他の可能性のある補助データと一緒になってファイルとして呼ばれる。このようなファイルは典型的にはサイズの大きなものであるため、それはしばしば、一般的に使用される規格(H.264、MPEG−1、MPEG−2若しくはMPEG−4など)に従って格納若しくは送信のため圧縮される。ビデオの具体例として、以下に限定されるものではないが、映画、ゲーム、映像場面、ドキュメンタリ若しくはマルチメディアデータコレクションがあげられる。
【0041】
ローカル装置、コンピュータ、マシーン又は単にボックスは、ここでは互換的に使用され、典型的にはメディアファイルにアクセスするためユーザにより使用される計算装置である。このようなクライアントマシーンは、他の装置とは独立して若しくはそれと共に動作するかもしれない。クライアントマシーンの具体例として、セットトップボックス、計算装置(デスクトップ、ラップトップ、PDA、電話、タブレットPCなど)、ネットワーク機能を備えたテレビ及びネットワークストレージ装置があげられる。
【0042】
常駐オブジェクト及び分散オブジェクトは、相対語である。ファイルが複数の部分若しくはセグメントに分割されると、これらのセグメントの一部は他のボックスにリモートに分散されるかもしれない。これら分散されたセグメントは、“分散オブジェクト”と呼ばれる。ローカルにキャッシュされたヘッダ及び他のセグメントは、“常駐オブジェクト”若しくは“レジデンスオブジェクト”と呼ばれる。
【0043】
サーバ、サーバ装置、サーバコンピュータ又はサーバマシーンは、ここでは互換的に使用され、典型的には、ローカルボックスからリモート配置された計算装置である。実現形態に応じて、ここでのサーバは、ここに記載されるサーバ処理を送出するよう構成されたスタンドアローンコンピュータ若しくは2以上のコンピュータのクラスタを意味するかもしれない。
【0044】
本発明の実施例が、図2A〜8を参照して説明される。しかしながら、当業者は、本発明はこれらの限定的な実施例の範囲を超えるため、これらの図面に関してここで与えられる詳細な説明が単なる説明のためのものであることを容易に理解するであろう。
【0045】
本発明の一実施例は、増大するユーザ数によって悪影響を受けないデータネットワークを介しビデオサービスを配信するための技術に関するものである。一実施例では、ユーザが多くなるに従って、システムもしくはプロセスによって提供されるパフォーマンスはより良好となる。
【0046】
図2Aは、本発明の実施例による分散ネットワークシステム100の一例となる構成200を示す。ネットワーク全体は、例えば、特定のタイプ、サイズ、コンテンツなどの各ボックスに対して1つのこのようなネットワークシステム100を複数有してもよいということは理解されるであろう。
【0047】
サービスプロバイダによっておそらく管理及び/又は占有されるサーバ202は、ローカルマシーン若しくはボックス206−1,206−2,...,206−nを介したユーザへのビデオ(若しくはマルチメディア)サービスの配信を処理するよう構成される。加入者からのリクエストにより加入者にビデオデータを配信する図1のビデオサーバ102とは異なり、サーバ202は、ユーザからのリクエストに応答してコンテンツを配信するものでなく、その代わりに他のボックスからコンテンツの少なくとも一部を抽出すべき場所及びその方法に関するソース情報を提供するよう構成される。すなわち、図1のサーバ102は、メディアストレージ装置112がクライアントマシーン106−1,106−2,...,106−nの何れかへのサービス提供時にコンテンツを提供することを要求し、サーバ202は、メディアストレージ装置がコンテンツを提供することを要求しない。その代わりに、ボックス206−1,206−2,...,206−nの一部が、コンテンツの一部若しくはすべてを互いに供給するようそれぞれ構成される。
【0048】
一実施例によると、ローカルマシーン若しくはボックス(206−1など)からのリクエストを実現するとき、サーバ202とボックス206−1との間のネットワークパス208−1及び210を介した通信は、小さなスケールのリクエストとレスポンス(小さなサイズ及び大変短いものなど)に限定されるかもしれない。ボックスからのリクエストに対するサーバレスポンスは、ソース情報(識別子など)、認証情報及びセキュリティ情報を含むかもしれない。サーバ202からのレスポンスを利用して、ボックスはタイトル(207−1など)の再生を開始するよう起動されるかもしれない。実質的に同時に、ボックスは、当該タイトルの移行の部分(207−2、207−nなど)をリクエストするため、ソース識別子に従って他のボックス(206−2、206−nなど)に対する1以上のリクエストを開始するかもしれない。適切な認証を仮定すると、要求元のボックスは、その他のボックスから同時に当該データの以降の部分を受信する。コンテンツのボックス間の通信のため、ネットワークパス208−1及び210を介したボックスとサーバ間の通信に対するバンド幅要求は低く、典型的には短時間に維持される。実質的に同時に多数のユーザボックスが再生リクエストを発行する場合、バックボーンパス210のバンド幅は顕著な又は厄介な遅延を回避するのに十分なものであるべきである。
【0049】
ボックス206−1,206−2,...,206−nの何れかにおいて提供されるライブラリにおいて利用可能なコンテンツは、1以上のコンテンツプロバイダによってもともと提供される。コンテンツプロバイダの具体例として、衛星受信機、テレビ中継ステーション、アナログ若しくはデジタル放送ステーション、映画スタジオ及びインターネットサイトがあげられる。実現形態に応じて、コンテンツはまずサーバ202において受信若しくは発信されるかもしれない。大規模なストレージ装置にコンテンツを維持及び管理する代わりに、サーバ202は、サーバ202により登録されている複数のローカルマシーンにコンテンツ若しくはファイルを分散するよう構成される。図2Aに示されるボックス206−1,206−1,206−2,...,206−nは、サービスを提供するローカルマシーンの具体例である。バックアップコピーが不要である場合、サーバ202は、何れの時点においてもコンテンツのコピーを保持する必要はない。他方、極めて要求の高いタイトルの完全なコピーをボックスに保持する特別な要求がなければ、サービスを提供するボックスの何れも発注までタイトルの完全なコピーを有しない。この結果、分散オブジェクトに埋め込まれたセキュリティによって、本発明の一部の実施例は、電子的な著作権侵害及び広範な配布(ハッキング若しくは不法な複製などによる)の懸念を軽減するかもしれない。
【0050】
便宜上、ここではタイトルに係るファイルが、当該タイトルがユーザにより選択及び発注されると再生されることが仮定される。タイトルが発注されると、対応するファイルが再生のため利用可能でなければならない。実施例は、それのサイズに関係なくファイル又は少なくともその一部に瞬時にアクセスすることを可能にするかもしれない。他の実施例によると、ファイルが平均して840メガバイトであり、ボックスが300ギガバイトの格納容量を有する場合、システムは任意の時点でのアクセスのため、タイトルの大きなライブラリに瞬時に提供するかもしれない。従来、タイトルのファイルが瞬時の再生を提供するため予め格納される必要がある場合、ボックスのローカルストレージは、4000ギガバイトの容量を有する必要があり、この結果、瞬時のVOSを経済的に非実現的なものにする。
【0051】
本発明の一実施例によると、ファイルの開始部分(“ヘッダ”と呼ばれる)とおそらく1以上のテールセグメントのみがボックスにローカルにキャッシュされる。このようなローカルにキャッシュされたセグメントは常駐オブジェクト(residing object)と呼ばれ、ローカルに常駐しないセグメントは分散オブジェクト(distributed object)と呼ばれる。あるタイトルが選択されると、対応するファイルのヘッダが即座に再生される。ヘッダ再生中、当該タイトルに対応する分散オブジェクトが他のボックスから同時に抽出される。ヘッダが終了すると、他のボックスからストリーミングされる分散オブジェクトの受信部分が、連続再生を可能にするため、存在する場合にはタイトルの常駐オブジェクトと合成される。あるタイトルの人気と同時になされる要求とに応じて、常駐オブジェクトの個数は、再生のための他のボックスに対する各ボックスの依存性を制御するよう増減されるかもしれない。典型的には、ボックスがタイトルの常駐オブジェクトを多く有するに従って、システム全体における当該タイトルの分散コピーは増加し、これにより、他のボックスに対する発注元のボックスの依存性を低下させる。
【0052】
一実施例では、ヘッダは瞬時の再生を保証するため常に最初に再生される。しかしながら、ボックスがファイルに対して複数の常駐オブジェクトを有するとき、ヘッダ以外の常駐オブジェクト(すなわち、常駐セグメント)が、他のボックスからダウンロード若しくはフェッチされた分散オブジェクト(すなわち、分散セグメント)と共に再生される。これらの常駐及び分散セグメントは、まとめてファイルの“セグメント”と呼ばれる。
【0053】
例えば、図2Aでは、ユーザがボックス206−1から再生用のタイトルを選択すると、ボックス206−1に常駐する対応するファイルのヘッダ207−1が即座にアクセスされる(ユーザが認証されており、及び/又は支払が決済されている場合)。この例では、ビデオファイルには4つのセグメントが存在するかもしれず、そのうちの2つは他のボックス(206−2、206−nなど)に分散されている。ヘッダの再生中、2つの分散セグメントが他方の2つのボックスからダウンロードされ、連続するコンテンツとして常駐セグメントと共にローカルにバッファリングされる。ヘッダが実行されると、連続するコンテンツが再生される。この結果、瞬時のVODが実現可能となる。
【0054】
図2Bの実施例を参照すると、ファイル220は、ヘッダ部分222と、4つのセグメント224から構成されるテール部分とに関して構成又は細分化されている。一般に、ファイル220は、要求される転送レート(良好な再生のための符号化及び復号化レートなどに関する)と、ネットワークの最小アップロード及びダウンロード能力とを考慮して、任意数のヘッダとセグメント部分に分割されるかもしれない。一実施例によると、要求される転送レート(毎秒1メガビット、すなわち、1Mbpsなど)が与えられると、ネットワークの最小のアップロード及びダウンロードスピードが、セグメントを規定する数と、特定のタイトルの同時になされる要求に対するサポート及び他のボックスへの依存性とを決定するよう考慮される。最小のアップロードスピードはUであり、要求される転送レートがDであり、D/U=K<k(ただし、kはKより大きな最小の整数である。)となることが仮定される。一実施例では、ダウンロードスピードがアップロードスピードの少なくともk倍の速さであると仮定すると、ファイルは好ましくは、Uのアップロードスピードを最適に利用するため、ヘッダとk個のセグメントに分割される。例えば、常駐エリアのためのPOTSベースDSLネットワークでは、要求される転送は約1.0Mbpsであり、アップロードスピードは約320kbpsである。従って、k=4となる。
【0055】
図2Cに示されるように、ファイル230は、1つのヘッダ232と4つのセグメント234〜237から構成される。図2Cは、ローカルボックスがヘッダ232のみを格納し、4つのセグメント234〜237を供給するため他の4つのボックスに依存する状況を仮定している。ローカルボックス239は、ヘッダ232の再生中、その他のボックスのアップロードスピードの4倍のダウンロードスピードを有すると仮定すると、これら4つのセグメントは、ローカルボックス239へのストリーミングとほぼ同時にネットワーク238を介し同時にダウンロードすることが可能である。
【0056】
図2Bに示されるように、ヘッダ232はファイルの開始部分であり、各セグメントはファイルの残りの間引かれた部分である。本実施例では、ヘッダのデータは連続的なものであり、それはヘッダ自体が再生可能であること意味し(例えば、当該タイトルの最初の15分間など)、セグメント部分234〜237は、ファイルのテール部分が再生可能となる前に一緒に提供されねばならない。図2Dは、ファイルを表すデータストリーム240を示す。ファイル240の開始部分はヘッダ242として割り当てられ、残りの部分は4つの“垂直の(vertical)”セグメント247〜250に分割される。これらのセグメント247〜250は、ファイルの残りの部分を間引くことによりそれぞれサンプリングすることによって生成又は形成される。
【0057】
残りの部分の正確なデータ長に応じて、各セグメント247〜250のn番目のデータブロックはファイルの残りの部分の連続する4つのデータブロックとなる。一実施例では、データブロックは、256キロバイト若しくは1メガバイトなどのデータのチャンクから構成される。図2Dに示されるように、データストリーム240の残りの部分は、b11,b21,b31,b41,b12,b22,b32,b42,b13,b23,b33,b43,...,b1n,b2n,b3n,b4nのようなデータブロックにより表現される。間引きサンプリングによって、残りの部分から取得される4つのセグメント247〜250は、それぞれ以下のように表現可能である。
【0058】
セグメント1={b11,b12,b13,b14,...}
セグメント2={b21,b22,b23,b24,...}
セグメント3={b31,b32,b33,b34,...}
セグメント4={b41,b42,b43,b44,...}
図2Dは、ファイルをヘッダ242と4つのセグメント247〜250に細分化する一例となる実施例を示す。ファイルの細分化方法は他にもある。例えば、ファイルをファイルのテール部分を表す複数の“垂直”セグメントに細分化する代わりに、1以上のセグメントが当該ファイルの音声部分を表すよう割り当てられてもよい。典型的には、映画は、その各々がある言語(英語、仏語、スペイン語など)のための複数の音声トラックを含む。この結果、すべてのセグメントは、必ずしも等しい長さとならず、再生をサポートするため同時に利用可能とならなければならない。この具体例は、タイトルのすべてのセグメントが当該タイトルを再生するために必ずしもフェッチされる必要がないことを示している(例えば、ビデオデータのためのすべてのセグメントと、1つの選択された音声トラックのための1つのみのセグメントなど)。他の例では、ファイル220は赤色、緑色、青色及び輝度の各値に関してセグメント化することが可能である。このため、セグメントの1つが欠落しても、画像は生成することが可能である。もちろん、赤色、緑色及び輝度のみから画像を形成することは、画質に影響を与えるかもしれない。このような場合、各色は、おそらく以前のフレーム若しくは他の基準に基づき推定される必要があるかもしれない。一般に、各ファイルは異なる個数のセグメントに細分化されるかもしれない。
【0059】
図2Eは、複数のボックスに分散化するためファイルを細分化するためのフローチャート若しくはプロセス260を示す。当該プロセス260は、メソッド、プロセス及び/若しくはシステムとして、又はソフトウェア、ハードウェア若しくはその両方により実現されてもよい。261において、プロセス260は、ボックスに分散するためファイルが細分化されるのを待機する。このようなファイルが利用可能になると、262において、ネットワークの最小アップロード及びダウンロードスピードと共に、要求される転送レートが取得される。一般に、異なるネットワークは異なるスピードを有する可能性がある。ファイルの細分化数を決定するため、ネットワークアップロード及びダウンロードスピードを有することは要求されていないが、ファイルの要求される転送レートの観点から、このようなスピードを知ることは、ネットワークスピード(又はバンド幅)を効率的利用するため、ファイルを細分化することを可能にする。
【0060】
264において、ファイルに対するセグメント数kが、262から取得された最小アップロード及びダウンロードスピードを含むいくつかのファクタと、適切な表示のための要求されるデータ転送レート(毎秒1メガビットなど)とを参照して決定される。一実施例では、実際のセグメント数は、ダウンロードバンド幅が十分である場合(要求される転送データレートより高い場合)、k+1などkより若干大きなものが選択される。後述されるように、エクストラセグメントがネットワーク若しくはボックスの不安定性を解消若しくは安定化させるための追加的な時間を提供するかもしれない。
【0061】
ファイルヘッダのサイズが、266において決定される。一般に、ヘッダサイズが大きくなると、ライブラリにおける利用可能なタイトルが少なくなる。一実施例では、ヘッダサイズは、連続的に残りの部分(分散オブジェクトにおける)の受信及び再生を保証するのに十分な長さになるよう決定され、あるいはおそらく、各オブジェクトがフェッチされるのを同期させ、不安定性を管理するための追加的な時間を含むようにしてもよい。他の実施例では、ヘッダサイズはサービス提供されるエリアの最小ネットワークスピードや、より高い転送レートに変換可能なシーンなどのいくつかのパラメータの関数として自動的に計算される。さらなる他の実施例では、ヘッダは、セキュリティ情報やコマーシャル情報の短い場面などの他の情報をボックスに転送するためのキャリアとして使用される。
【0062】
図2Eには、ファイルをセキュアにするための選択肢は示されていない。一実施例では、ファイルはコンテンツをプロテクトするための暗号によって、若しくは暗号化方式に従ってスクランブル化される。そこでは、ヘッダは、再生前に独立に解読されるかもしれない。ファイルが暗号化されているか、若しくは平文であるかに関係なく、それは同様に細分化することが可能である。ヘッダサイズが266において決定されると、ヘッダ部分が容易に生成される。それと同時に、ファイルの残りの部分はk個のセグメントに間引きされる。他の実施例では、ヘッダとこれらk個のセグメントの0以上とがサービスを提供する各ボックスに分散される。何れのボックスがセグメントを受信するか決定するための詳細が以下で説明される。何れのケースでも、ヘッダとセグメントは分散前にセキュア化されてもよい。270において、あるタイプのセキュリティがヘッダとセグメントに埋め込まれるようにしてもよい。実現形態に応じて、ヘッダとセグメントはそれぞれ、暗号化方式若しくは暗号(Data Encryption Standard(DES)アルゴリズム、Blowfishブロック暗号、Twofish暗号、RC−4など)に従ってそれぞれ暗号化されてもよく、及び/又はデジタル著作権管理(DRM)によりプロテクトされるようにしてもよい。
【0063】
274において、ヘッダとセグメント(すなわち、各パッケージ)とが、サービスを提供する各ボックスに分散される。本発明の一実施例によると、この分散化は、ボックスからボックスにデータのチャンクとして各パッケージを伝搬させることによって同期的若しくは非同期的に実行される。その詳細が以下に説明される。ボックスは、セグメントの1つ、複数若しくはおそらくすべてを受信するよう選択されてもよい。274の後、プロセス260は他のファイルに対して261に戻る。
【0064】
一実施例は、ユーザに提供される多数のタイトルを有する動的に更新されるライブラリを可能にする。各タイトルは、瞬時の再生のため選択及び順序付けされるかもしれない。定期的に更新され(毎日など)、任意の時点に瞬時にアクセス可能な5000タイトルなどを有する大きなライブラリが与えられると、そのうちの一部のタイトルは他のものより人気があり、より多くのユーザによってより頻繁に要求されるかもしれない。人気のあるタイトルを調達するためボックスの可能なバンド幅の問題若しくは利用不可を最小限にするため、常駐オブジェクト及び分散オブジェクトの提供は、例えば、人気、地理、人口及び/又は同様の基準などに従ってインテリジェントに実行されるべきである。
【0065】
図3Aは、ボックスの限られた格納スペースへのライブラリのタイトルの一例となる人気による分類を示す。便宜上、格納スペース300は300ギガバイトの容量を有し、瞬時の再生のため5000タイトルが利用可能であることが仮定される。5000タイトルのうちの何れかは、再生のため選択され、瞬時にアクセスされるかもしれない。VODアプリケーションのため、各映画は平均的には約2時間であることが仮定される。大部分のユーザに受入可能な表示品質のためには、2時間の映画のファイルは約840メガバイトのサイズとなる。約30メガバイトのヘッダに対して、4つのセグメントのそれぞれは、各ファイルのサイズが平均に近いものであると仮定すると、約203メガバイトとなると推定される(すなわち、(840メガバイト−30メガバイト)×1/4)。従って、格納スペース300は、図3Aに示されるような分散化のため5000タイトルを収容するため、約240ギガバイトとなることが推定される(すなわち、5000タイトル×30メガバイト+50タイトル×2セグメント×203メガバイト+50タイトル×2セグメント×203メガバイト+4900タイトル×セグメントの5%×203メガバイト=240ギガバイト)。
【0066】
図3Aの実施例によると、これら5000タイトルは2つのバンドに分割され、上位バンド302は、新たにリリースされた若しくは人気のあるタイトルのためのものであり、下位(L)バンド304は、比較的に人気がないが、ときどき要求されるタイトルのためのものである(例えば、007のJames Bondやマイナーなディズニー映画など)。ライブラリが5000タイトルを有する場合、上位バンド302は100タイトルを収容するよう割り当てられ、低バンド304は残りの4900タイトルを収容するよう割り当てられるようにしてもよい。新たなタイトルがリリースされ、上位バンドに追加される毎に、上位バンド302にすでにあるタイトルは破棄若しくは低バンド304に移される。他の実施例では、上位バンドはさらに2つのバンドに分割されてもよく、高バンド(H)は最新の50タイトルなどのため、中バンド(M)はやや古い次の50タイトルのためのものである。
【0067】
中バンド(M)の割当ては、上位バンドにおけるタイトルのフレキシブルな管理を実現する。映画レンタルビジネスにおける収入の70%以上が上位バンドのタイトルからのものであり、その収入の40%以上が高バンド(H)のタイトルからのものであることが推定される。さらに後述されるように、より多くのリソースを高バンドのタイトルを迅速に更新するよう割当てるため、又は他のボックスの高バンドのタイトルの依存性を低減するため、中バンド(M)のタイトルのセグメント数は減少するか、又は中バンド(M)のタイトルのあるパーセンテージのみが1以上のセグメントによりキャッシュされるかもしれない。
【0068】
本実施例では、H、M及びLバンドにそれぞれ50、50及び4900タイトルが存在する。一般に、ボックスが十分長い期間サービス提供していたとき、上位バンド302の各タイトルは、ヘッダと1つ若しくは2つの対応するセグメントにより提供され、Lバンドの各タイトルは、ヘッダとセグメントの一部により提供される。Lバンドのタイトル毎のセグメント数に関する限り、そこにおけるタイトルのあるパーセンテージのみが各タイトル毎に1つのセグメントにより提供され、これらのタイトルは、典型的には、ボックス毎に異なっている。上位バンド302のタイトルに対する要求がLバンド304のタイトルよりはるかに大きいため、Lバンドのタイトルに対するボックスにおけるセグメントのパーセンテージは、5%などの比較的小さな値に設定されてもよい。Lバンドのタイトルのセグメントの分散化は、常にシステムにこれらのタイトルの少なくとも1つの分散コピーと、上位バンドのタイトルのより多くの分散セグメントがあるように行われる。他の観点から、上位バンド302のタイトルが選択されると、発注元のボックスのタイトルの再生をサポートするため、分散セグメントを供給するよう指定されるより多くのボックスがあり、これにより、他のボックスが欠落したセグメントを供給するのに利用不可となる可能性を低減することができる。低バンドタイトルが選択された場合、相対的に低い人気のため、ネットワークにおいて利用可能な十分な分散コピーが存在する可能性が高く、これにより、他のボックスが再生のための各セグメントを供給するよう指定することが可能である。
【0069】
動作について、Hバンドのタイトルがボックスにおいて選択された場合、そのセグメントの2つが当該ボックスにすでに常駐している。従って、これら2つの欠落したセグメントを供給するため、他に2つのボックスしか必要でない(すなわち、依存性=2)。Lバンドのタイトルが選択されると、多くの場合、4つのセグメントを供給するため、他に4つのボックスが必要とされる(すなわち、依存性=4)。すなわち、タイトルの人気は、発注元のボックスの他のボックスへの依存性を決定する。あるタイトルの人気が高いほど、発注元のボックスの他のボックスへの依存性は低くなる。
【0070】
上述されるように、ライブラリは定期的に(毎日、毎週など)更新される。新たなタイトルが受け付けされる毎に、この新たなタイトルは、典型的には、Hバンドに追加される。一実施例では、H、M及びLバンドに相対的に固定された個数のタイトルを維持することが所望され、Hバンドの相対的に人気の低いタイトルがMバンドに移され、Mバンドの最も古いタイトル若しくは相対的に人気の最も低いタイトルがLバンドに移される。他方、まれにではあるが、Lバンド若しくはMバンドのタイトルがより上位のバンドに昇格することも可能である。あるタイトルがMバンドからLバンドに移されるときは常に、Lバンドの最も古い若しくは相対的に最も人気の低いタイトルが破棄されるかもしれない。図3Aによると、あるタイトルが上位バンド302からLバンド304に移されるときは常に、上位バンド302の1つ又は両方のセグメントが、当該タイトルが1つのセグメントを維持するため指定されるパーセンテージの範囲内であるか否かに応じて欠落される。
【0071】
一般に、ライブラリを更新するため、1日に複数のタイトルがリリースされる。しかしながら、これらのタイトルのすべてが必ずしも新たなタイトルではなく(すなわち、上位バンドのための)、その一部は大変人気が高く、他のものはあまり人気がない。例えば、ライブラリが1日に10タイトルにより更新され、そのうちの1つは、上位バンドにおいて新たにリリースされたタイトルであり、9つはLバンドにおいて人気の低いタイトルである。当該タイトルが上位バンドに追加されると、対応する2つのセグメントがまた追加され、それと同時に、上位バンド(おそらくMバンド)の比較的古いタイトルが破棄若しくはLバンドに移されるかもしれない。Mバンドからの比較的古いタイトルは、上記9つのタイトルと組み合わされてもよく、これら10個のタイトルの何れが、それの1つのセグメントがあるボックスに対してローカルにキャッシュされると仮定されるパーセンテージ(5%など)に属するか決定される。
【0072】
当該実施例では、各ボックスは、利用可能なタイトル毎に1つである5000個のヘッダをキャッシュしている(おそらく、サイズについては同じ若しくは異なり、フォーマットについてはおそらく異なり、利用されるセキュリティについてはおそらく異なるなど)。これらの常駐オブジェクトは、ユーザがタイトル発注時に瞬時に再生を開始し、他のボックスからの分散オブジェクトの受信を開始するのに十分な長さの再生を続けることができることを保証する。セグメントの分散化の説明を容易にするため、4つのセグメントはそれぞれ1、2、3及び4とラベル付けされる。上位バンド302のタイトルについては、2つのセグメントがローカルに分散され、他のボックスに2つのセグメントが分散されている。この結果、ローカルに格納されているセグメントについて、(セグメント1,セグメント2)、(セグメント1,セグメント3)、(セグメント1,セグメント4)、(セグメント2,セグメント3)、(セグメント2,セグメント4)、(セグメント3,セグメント4)の6つの可能な組み合わせが存在する。これらの組み合わせは、サービスを提供するボックス間に等しく分散されている。発注元のボックスがセグメント1とセグメント2を有する場合、第1の他のボックスと第2の他のボックスが、セグメント3及びセグメント4をそれぞれ発注元のボックスに提供するため呼び出される必要がある。セグメント3又はセグメント4を有するボックスが、第1の他のボックス若しくは第2の他のボックスであるかもしれない。例えば、(セグメント1,セグメント3)を有するボックスと、(セグメント1,セグメント4)を有する他のボックスとが、それぞれ第1の他のボックスと第2の他のボックスであるかもしれない。
【0073】
一実施例では、各ボックスはいくつかのタイプに分類される。例えば、6つのタイプのボックスが存在し、各タイプは上述した6つの組み合わせの1つを格納するため指定されている。各ボックスの対応するヘッダに加えて、Hバンドに50タイトルがある場合、これら50タイトルのそれぞれのセグメントは、6つの組み合わせの1つに従って分散される。
【0074】
Lバンドのタイトルに対して、各ボックスは当該タイトルの5%の1つのセグメントを格納する。Lバンドのタイトルの1つが発注されると、当該ボックスはローカルにキャッシュされたセグメントを有しているかもしれないし、そうでないかもしれない。従って、Lバンドのタイトルのセグメントの分散化は、サービスを提供しているボックスが一緒になってすべてのタイトルのすべてのセグメントを有することを保証する必要がある。すなわち、Lバンドの各タイトルの少なくもと1つのコピーがネットワークに存在している必要がある。
【0075】
サービスを提供しているボックスの間にLバンドのタイトルのセグメントを分散させる方法がいくつかある。一実施例によると、Lバンドのタイトルのセグメントの分散化を管理するため、Hバンドのタイトルのセグメントの分散化が参照される。例えば、Hバンドのタイトルのセグメント1とセグメント2がローカルに格納されているとき、Lバンドのタイトルのセグメント1又はセグメント2がローカルに格納される。(上位バンドから低バンドへのタイトルの移行時に、ボックスはセグメントの1つを破棄すればよいためである。)従って、分散化の以下の管理が成り立つ。
【0076】
【表1】
【0077】
Lバンドの何れのタイトルが特定のボックスの選択されたパーセンテージの範囲内に属するかの判断は、いくつかのファクタに基づき決定されるかもしれない。一実施例では、このパーセンテージは、タイトルの経過時間若しくは人気の潜在的にランダム化された関数として決定される。他の実施例では、このパーセンテージは、あるエリアにおける所望される言語及び視聴行動の統計と、他のボックスからの分散オブジェクトの抽出をより効率的に実現することを可能にする他の指標とに基づき決定される。さらなる他の実施例では、当該パーセンテージは、
1.ユーザがボックスからこれまで視聴したプログラム(映画など)のセット
2.ユーザがボックスについて評価した(1〜10のスケールなどにより)プログラム
3.以降の視聴のためユーザにより作成された選好リストに関するプログラム
4.ブラウジング動作(例えば、ユーザが視聴した予告、タイトルの簡単な紹介を読むのにユーザが費やした時間など)
の一例となるリストの一部若しくはすべてを動的に記録したボックスに埋め込み可能な学習エンジンから決定される。
【0078】
この学習エンジンは、映画などの何れのプログラムがユーザが視聴したものと類似しているか示すための統計を提供するよう起動されるかもしれない(例えば、俳優、監督、ジャンルなどに関して)。これにより、これらの映画は、対応するセグメントを有するタイトルのパーセンテージの範囲内となるよう選択される。さらに、何れの映画のペアが類似しているかについての判断は、“協調フィルタリング”と呼ばれるものに基づき行われ、すなわち、多数のユーザがある映画ペアを視聴することを好む場合、これら2つの映画は類似しているとみなされるかもしれない。従って、ボックスにおいておそらく選択及び発注されるものと類似したさらなる映画が、当該パーセンテージのタイトルに追加されるかもしれない。何れの場合にも、ボックスは、当該ボックスを介しユーザにより選択及び発注される可能性が高いタイトルに係るセグメントをキャッシュするかもしれない。他の実施例では、各映画は、特定の属性によって規定されるかもしれない。ユーザ行動は、特定の属性のユーザの嗜好を示すかもしれない。選好される属性と映画属性とをマッチングすることによって、学習エンジンは、1つのバンドのタイトルの何れのセグメントが各ボックスに格納すべきか判断するかもしれない。また、類似するが異なるユーザの間で比較をすることが可能である。例えば、第1ユーザがアクションベースの映画を選好し、以前に映画X、Y及びZを発注しており、第2ユーザがアクションベースの映画を選好する場合、学習エンジンは、第2ユーザのボックスに映画X、Y及びZXのセグメントを格納しようとするかもしれない。
【0079】
図3Bは、ボックスの限られた格納スペース内のライブラリのタイトルの他の一例となる人気による分類を示す。図3Aと図3Bとの間の主要な相違点の1つは、図3Aの上位バンド302が各タイトルの1つのヘッダと2つのセグメントを保持し、図3Bの上位バンド310が各タイトルの1つのヘッダと1つのセグメントを保持していることである。
【0080】
図3A若しくは図3Bとは反対に、一実施例によると、サービスを提供するすべてのボックスは、Hバンドに1以上のタイトルのための2より多くのセグメントを有するよう構成されるかもしれず、これにより、これらの強く要求されるタイトルの分散コピーの個数を実質的に増加させる。あるタイトルが新たにリリースされ、若しくは統計的に人気があると判断されると、サービスを提供しているボックスは、発注元のボックスの他のボックスへの依存性が大きく低減するように、これらのタイトルのセグメントの個数を増加させるよう動作可能である。
【0081】
図3Cは、ライブラリのタイトルの人気に従う他の一例となるバンド化方式を示す。このバンド化方式は、ライブラリのタイトルを複数のバンド(5バンドなど)に分割する。曲線320は、A、B、C、D及びEの各バンドを示し、Aバンドは最も人気の高いタイトルを示し、Eバンドはライブラリにおいて相対的に最も人気の低いタイトルを表す。各バンドにおいて利用可能なタイトルは、例えば、要求統計、地理的位置、所望される言語、タイトルの古さ、人口統計情報などからの1以上の指標に従って定期的に更新されてもよい。各ボックスは、Aバンドのタイトル(例えば、1つ又は2つの新たにリリースされたタイトルなど)のヘッダと対応するセグメントのすべてを格納する。各ボックスは、Bバンドのタイトルのヘッダと3つのセグメントをローカルに格納する。各ボックスは、Cバンドのタイトルのヘッダと2つのセグメントをローカルに格納する。各ボックスは、Dバンドのタイトルのヘッダと1つのセグメントとをローカルに格納する。さらに、各ボックスは、Eバンドのタイトルのうちの5%などの小さなパーセンテージのヘッダと1つのセグメントとを格納する。この結果、図3Dに示されるテーブル326にリストされるような連続再生のためのバンドの各タイトルの依存性は、それぞれ0、1、2、3及びおそらく4となる。
【0082】
完全性のため、テーブル326はまた、各バンドのタイトルに対する要求の一例となる統計を示すカラム328を有し、すなわち、バンドAのタイトルに対する要求は、ライブラリに対するリクエスト全体の約60%となると予想される。バンドB、C、D及びEのタイトルに対する逓減する要求は、20%、10%、8%及び2%として示される。バンドAのタイトルに対する要求が大きいかもしれないが、バンドAのタイトルに対する他のボックスへの発注元のボックスの依存性はゼロとなる。従って、バンドAのタイトルに対する注文は、ローカルに実現することが可能となる。他方、バンドB、C、D及びEのタイトルに対する要求は徐々に低下する。従って、バンドB、C、D及びEにおける発注元のボックスの依存性は徐々に増加する。バンドB、C、D及びEのタイトルの分散コピーは徐々に減少する。
【0083】
図3C及び3Dを参照して上述したバンド化方式は、タイトルの人気に従って規定された個数のセグメントに対して任意数のバンドに論理的に拡張されるかもしれない。例えば、各ボックスがバンドのタイトル毎に平均して2.5セグメントを格納する上述の具体例において、バンドBとバンドCとの間にあるバンドB’を導入してもよい。このような平均セグメント数を生成及び制御する1つの方法は、半数のボックスに2つのセグメントを格納し、半数のノードに3つのセグメントを格納するものである。極端な例では、各タイトルは、異なる個数のセグメントを有するだけでなく、各ボックスはまた、各タイトルに対していくつのセグメントをローカルにキャッシュするか独立に決定するかもしれない。一般に、あるタイトルの人気が高くなるに従って、より多くのセグメントがローカルにキャッシュされ、より多くの分散コピーがネットワークにおいて利用可能になる。何れの場合でも、ライブラリのタイトルが何れのセグメントもローカルにキャッシュされないとき、ネットワークに対応するすべてのセグメントの少なくとも1つのコピーが存在していなければならない。そうでない場合、このようなタイトルに対する注文は提供できなくなる。
【0084】
図3Eは、瞬時のアクセスのためタイトルのライブラリを分類するフローチャート又はプロセス360を示す。当該プロセス360は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/若しくはシステムとして実現されるかもしれない。当該プロセス360がVODシステムにおいて使用されるとき、タイトルに係るファイルは、図2Eのプロセス260に従ってヘッダと1以上のセグメントに細分化されるかもしれない。362において、これらのタイトルに係るファイルがいくつ分散化されるべきか決定する必要があり、これにより、各ライブラリに格納されるタイトル数を規定することが可能となる。一般に、ライブラリにおいて利用可能なタイトル数は、ボックス内の格納スペースの容量、ヘッダサイズ、ネットワークスピード、要求、ファイルサイズ、要求されるデータ転送スピード、同時サポートなどを含むいくつかのファクタの関数である。一実施例では、5000個のタイトルがライブラリにおいて提供可能であると判断され、各タイトルは、平均して2時間であり、840メガバイトから1ギガバイトのサイズを有する。図2Eのプロセス260は、ファイルの細分化を決定するのに利用可能である。バンド数が決定されると、プロセス360は364に移行する。
【0085】
364において、これらのタイトルが各バンドに分類される。少なくとも2つのバンドが利用され、上位バンドは最も人気のあるタイトル(新たなリリースなど)のためのものであり、低バンドは相対的に人気の低いタイトルのためのものである。実現形態に応じて、上位バンドにも低バンドにも適合しないタイトルを格納し、ライブラリの更新を実現するため、1以上の中間バンドが導入されてもよい。上述されたように、同時発注に適応するため、他のバンドのものより上位バンドのタイトルの分散コピーがより多くされる。動作について、上位バンドのタイトル数は、好ましくは、ボックスの格納スペースの利用を最適化するよう小さく維持される。
【0086】
366において、各バンドのセグメント数が決定される。一実施例によると、上位バンドのタイトルのセグメントがより多くローカルにキャッシュされ、より多くの分散コピーをネットワークにおいて利用可能にする。この結果、より人気のあるタイトルに対して、発注元のボックスは、当該タイトルの連続的な再生に必要とされるセグメントを供給するため、他のボックスにあまり依存しなくなる。他方、低バンドのタイトルのあるパーセンテージのみがローカルにキャッシュされ、ネットワークにおいて利用可能な分散コピーがより少なくされる。システムが中間バンドを有するよう構成される場合、ローカルにキャッシュされるセグメント数は、上位バンドから徐々に減少するかもしれない。
【0087】
368において、プロセス360は、セグメントをキャッシュするボックスを決定する。実現形態に応じて、セグメント分散方式は、タイトルの効率的な格納と効果的な調達のためにセグメントキャッシュ処理を最適化するため、異なるファクタに基づくかもしれない。一実施例では、セグメントの分散化は、視聴行動に基づき決定される。ユーザの視聴行動を調べることによって、何れのボックスがあるタイトルを発注する可能性が高いか統計的に決定されるかもしれない。例えば、アクション映画を頻繁に発注するユーザは、他のアクション映画を発注する可能性が高い。アクション映画のタイトルに係るセグメントを分散させるとき、当該分散化は、これらのセグメントがアクション映画を発注する可能性が統計的に高いボックスになされることを保証するよう調整されるかもしれない。他の実施例では、分散化は、所望される言語に基づくかもしれない。スペイン語など所望される言語によるタイトルに係るセグメントの分散化は、このようなセグメントが所望される言語により映画を発注する可能性が統計的に高いボックスになされるように行われるかももしれない。
【0088】
図3Fは、ボックスのライブラリを更新するフローチャート又はプロセス380を示す。プロセス380は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されるかもしれない。プロセス380がVODシステムに使用されるとき、タイトルに係る大きなファイルが、図2Eのプロセス260に従ってヘッダと複数のセグメントに細分化されるかもしれない。各ボックスのライブラリは、定期的に又は所定の時間に更新される。プロセス380は、サービスを提供するすべてのボックスが利用可能なタイトルに関して同期されるように、ライブラリを動的に更新するのに利用されるかもしれない。
【0089】
382において、プロセス380は、リリースを待機する。後述されるように、リリース(1以上のタイトルから構成される)は、サーバ(図2Aのサーバ202など)から直接的に提供されてもよく、又は他のボックスから伝搬されてもよい。リリースの各タイトルは、ヘッダといくつかのセグメントに細分化される(例えば、図2Eのプロセス260などによって)。ヘッダと4つのセグメントとに細分化されたタイトルについて、(ヘッダ,セグメント1,セグメント2)、(ヘッダ,セグメント1,セグメント3)、(ヘッダ,セグメント1,セグメント4)、(ヘッダ,セグメント2,セグメント3)、(ヘッダ,セグメント2,セグメント4)、(ヘッダ,セグメント3,セグメント4)のボックスが所望する(ヘッダと2つのセグメントを要求するタイトルに対して)可能性のある6つのリリースパッケージが存在する。これらのリリースパッケージの少なくとも1つが、ボックスにおいて受信される。
【0090】
一実施例では、リリースが利用可能であるというメッセージ若しくはデータセットをサーバ若しくはボックスから受信すると、プロセス380が開始される。384において、リリースパッケージに従って、リリースの各タイトルに適したバンドが決定される。上述されるように、当該タイトルは何れかのタイプに係るものであるかもしれない(高バンド若しくは低バンドなど)。従って、タイトルを収容するのに適したバンドが決定される。バンドに所定数以上のタイトルが収容されることを回避するため、好ましくは、バンド内の既存の相対的に人気の最も低いタイトルがバンドから排除される。386において、このようなバンド内の相対的に最も人気の低いタイトルが決定される。一実施例では、リリースに関する受信メッセージは、何れのバンドの何れの既存のタイトルが破棄若しくは低バンドに移されるべきか示す。388において、当該タイトルが、それに係るヘッダと対応するセグメント(それはないかもしれない)とをボックスにおいて受信することによって、割り当てられたバンドに追加される。
【0091】
390において、ボックスのライブラリリストが更新される。実現形態に応じて、ライブラリリストは、排除されたタイトルを削除し、新たなタイトルを追加することによってローカルに更新されるかもしれず、又は更新されたライブラリリストが受信されるかもしれない。この結果、排除されたタイトルは、もはや利用可能でなく、新たなタイトルが注文可能となる。
【0092】
図4Aを参照すると、サービスを提供するすべてのボックスのライブラリを更新する図400が示される。サーバ(図2Aのサーバ202など)がライブラリを更新すると、すべてのボックスのライブラリがこれに呼応して更新される。一実施例によると、更新プロセスは同期的に及び/又は非同期的に実行される。
【0093】
サーバ402は、ヘッダとセグメントによりタイトルのリリースに係るファイルを準備するよう構成される。ファイルを準備する一例となる方法は、図2Eのプロセス260である。便宜上、ヘッダと4つのセグメントが存在することが仮定される。従って、上述されるように、何れのバンドにリリースが配備されるかに応じて、複数のリリースパッケージが存在するかもしれない。動作について、サービスを提供する各ボックスは1つのリリースパッケージを受信するよう構成される。
【0094】
まず、サーバは、リリースに関するメタデータ、ライブラリから破棄されるべき最も人気の低いタイトル及び/又はタイトル移転を含むリリース命令を準備する。当該命令は、何れのボックスが何れのリリースパッケージを取得し、パッケージが何れの方法により受信されるべきか(すなわち、他の何れのボックスから)を記述するかもしれない。例えば、この命令は、特定の特性を示す識別子によって特定されるボックスがリリースパッケージXを受信すべきか指定することが可能である。一般にすべてのリリースに適用されるデフォルト命令があり、また特定のリリースに適合された命令があるかもしれない。リリースパッケージをボックスに割り当てる目的の1つは、同一若しくは異なるセグメントを保証するため、サービスを提供するすべてのボックスに等しくパッケージを分散することであるかもしれない。
【0095】
リリース命令は、サーバによって準備されると、サーバとボックスとの間の直接的な通信を介して、又は後述されるgossipプロトコルを介した命令のボックスからボックスへの伝搬によってサービスを提供するボックスに伝搬される。何れの場合にも、各ボックスが、それがあるリリースパッケージを受信する必要性を認識していることが仮定される。
【0096】
リリースは、当該リリースに対するヘッダとセグメントとを表すデータチャンク403のシーケンスに変換される。データチャンクは、サーバからボックスへの若しくは2つのボックス間のデータ転送の最小単位である。例えば、各データチャンクは、1メガバイトのサイズを有し、一意的に特定されるかもしれない。データチャンク403のシーケンスは、ライブラリを更新するためボックスに伝搬される2つの別個のタイトルを表すかもしれない。一般に、各ボックスは、当該ボックスに対応する適切なリリースパッケージを構成するデータチャンクの特定のサブセットを所望する。さらに、リリース命令自体は、すべてのボックスに伝搬される1以上のデータチャンクとして表されてもよい。
【0097】
動作について、サーバ402は、ボックス群404−1,404−2,...,404−nとの各通信を開始し、各ボックスに当該ボックスによって要求されるデータチャンクのいくつかを提供する。好ましくは、各データチャンクは、サーバ402により少なくとも1つのボックスに提供される。データチャンクを最初に受信するボックス404−1,404−2,...,404−nの正確な個数は、分散化を制限しない。一実施例では、ボックス404−1,404−2,...,404−nの指定は完全にランダムである。他の実施例では、ボックス404−1,404−2,...,404−nの指定は、時間帯、地理的位置、利用可能なネットワーク帯域幅及びその遅延、ボックスのインターネットサービスプロバイダなどの1以上に基づく。何れの場合も、サーバがアイドル状態であるときは常に、サーバ402は常時データチャンクを受信する異なるボックスを指定することが可能である。
【0098】
各ボックス404−1,404−2,...,404−nは、“gossipプロトコル”と通常呼ばれている、アプリケーションレイヤマルチキャスト形式のプロトコルに基づき、サービスを提供する他のボックスにデータチャンクを拡散するよう構成される。ボックス404−1,404−2,...,404−nの全てが同一のデータチャンクを受信している必要がないことに留意すべきである。ボックス404−1,404−2,...,404−nの何れも、それがデータチャンク全体を受信するとすぐに、データチャンクを他のボックスに拡散することを開始するようにしてもよい。動作について、ボックス404−1は、それの受信したデータチャンクの少なくとも一部を、同時に互いの通信するボックス406−1,406−2及び406−3に伝搬するよう割り当てられる。ボックス404−2は、それの受信したデータチャンクの少なくとも一部をボックス406−2及び406−3に伝搬するよう割り当てられる。ボックス406−2は、データチャンクを自らに供給するよう構成されるボックス404−1、404−2及び他の何れかのボックスから何れのデータチャンクを取得するかについて正確に知っているよう構成される。さらに、ボックス406−2は、それが受信したデータチャンクの少なくとも一部をボックス408−1、408−2及び408−3に伝搬するよう割り当てられる。データの伝搬は必ずしも階層的である必要はないことに留意されたい。例えば、ボックス408−1は、図示されるように、データチャンクを後方の406−1に送信するようにしてもよい。
【0099】
一実施例では、データチャンクは、無駄なデータ転送を回避するため、特定のチャンクを実際に所望するボックスのみに伝搬される。さらに、ボックスがすでにデータチャンクを有しておらず、何れかから当該チャンクをダウンロードするプロセスにいない場合に限って、データチャンクがボックスに伝搬されることを保証することによって、無駄なデータ転送が回避されるかもしれない。チャンクの伝搬は、すべてのボックスが協調的に同時に参加する同期プロトコルを通じたものであってもよく、又は各ボックスが参加すべき時とどのくらいの期間参加するかフレキシブルに選択可能な非同期プロトコルを通じたものであってもよい。例えば、ボックスは、それが発注元のボックスに対する映画のサービス提供に忙しいときは常に、又はネットワークがその使用量が大きいと検出されたとき、チャンクのダウンロード及び伝搬への参加を中止するようにすることができる。ボックスは、ネットワーク状態を連続的に監視し、十分な帯域幅が利用可能であるときは、適応的にgossip伝搬に再参加するようにしてもよい。
【0100】
動作について、何れかの理由によりボックスの何れか1つがデータチャンクの受入に失敗した場合、供給元若しくは代替ボックスがデータチャンクを送受信するよう構成可能であるときは当該ボックスを外すことができる。リリースを欠いたボックスは、1以上の更新されたボックスから以降に当該データをフェッチするようにしてもよい。ボックス・アフター・ボックス(boxes after boxes)を介しデータチャンクを繰り返しかつ再帰的に伝搬することによって(すなわち、同期的及び/又は非同期的にプル若しくはプッシュすることによって)、最終的には、サービスを提供するすべてのボックスに各リリースが存在することとなる(追加されるべきすべてのタイトルのヘッダ及び指定されたセグメントと、削除されるべきタイトルの識別)。
【0101】
更新終了後、何れのボックスが何れのセグメントを有するか示すマップ409を構築することができる。マップ409によって、発注元のボックスから注文が受信される毎に、サーバは、ローカルにキャッシュされていないセグメントを発注元のボックスに供給するため、適切なボックスを指定することができる。あるいは、マップ409は、ボックスが注文を実現するため、必要とされるセグメントをフェッチするためのソース情報を取得することを可能にする。
【0102】
リリースが上位バンドに対するものでないとき、何れのボックスが何れのセグメントを保持すべきかの判断は、必要に応じてボックス間のセグメントを転送効率を最大化するため、地理的位置、時間帯、視聴行動若しくは選好される言語などの複数のファクタに基づくものであってもよい。
【0103】
利用可能なタイトルのリストからのタイトルの削除は最初にボックスに配布されるかもしれないということが理解されるべきである。このようにして、何れのボックスももはや利用可能でないタイトルを発注しないようになる。タイトル削除命令の配信は、上述したgossipプロトコルを用いて実現されてもよく、又は直接的なボックスからサーバへの通信によって提供されてもよい。
【0104】
図4Bを参照すると、サービスを提供するボックスにリリースを提供するフローチャート又はプロセス410が示される。当該プロセス410は、中央サーバを使用することなく複数の一に維持されているディレクトリを更新するのに特に有用である。プロセス410の可能な特徴及び効果の1つは、複数の位置におけるディレクトリが、アプリケーションレイヤマルチキャスト系のgossipプロトコルによって、場所から場所を介しデータチャンクの更新を伝搬することによって、同期的に及び/又は非同期的に更新されるということである。プロセス410がVODシステムに使用されるとき、多数のタイトルを有するライブラリが、同時更新をサポートするのに高帯域幅を要求することなく、動的に又は効率的に更新されるかもしれない。
【0105】
412において、プロセスは、データネットワーク上の装置(サーバプロバイダによるサーバなど)において利用可能なるリリースを待機する。リリースが利用可能になると、リリースに係るファイルが、ボックスへの配信のため414においてサーバに準備される。図2Eのプロセス260は、各ファイルに対してヘッダと対応するセグメントへの細分化のための一例となるプロセスであってもよい。
【0106】
416において、ヘッダ及びセグメントはデータチャンクに分割される。418において、サーバは、データチャンクの少なくとも一部を受信する初期ボックス群を指定する。一実施例では、これらのボックスは、同一のデータチャンクを受信しなくてもよい。実現形態に応じて、サーバは、各データチャンク群を初期ボックスにプッシュし、又は初期ボックスがサーバから各データチャンク群をプルするようにしてもよい。いくつかの実施例では、すべてのデータチャンクのコピーが初期ボックスに配信され、これにより、初期ボックスはサーバとのさらなるやりとりなくシステムのその他のボックスに提供することが可能となる。
【0107】
420において、プロセス410は、何れのボックスが何れかのデータチャンクを受信することができなかったか判断する。データチャンクを受信しないボックスがある場合、プロセスは422に移行し、初期ボックス群に属しないボックスが失敗したボックスに置換される。この結果、少なくとも1つの完全なデータチャンク群が、提供するボックス群に同期的又は非同期的に配信されるかもしれない。
【0108】
その後、プロセス410は424に移行し、提供する各ボックスは、受信したデータチャンクの少なくとも一部を1以上の他のボックス(物理的に近い他のボックス群など)に拡散するよう構成され、他の各ボックスは、それが受信したデータチャンクの少なくとも一部を他のボックスにさらに拡散するよう構成される。データチャンクをまとめてフェッチするため、何れのボックスも同時に複数のボックスと通信するようにしてもよいということが留意されるべきである。プロセス410は、その後に他のリリースを待機する412に戻る。
【0109】
動作について、プロセス410は、1回に1つのタイトルによりライブラリを更新することに限定されるものでない。タイトルをデータチャンクに変換することによって、複数のタイトルが、ボックス間でデータチャンクを非同期的に伝搬することによってシステムに拡散されるようにしてもよい。また、プロセス410は、他のタイトルが配信可能になるまでに終了している必要はない。1つのリリースがサービスを提供するボックスに完全に提供されるまで、他のリリースが配信可能とされてもよい。動作について、プロセス410は、好ましくは、真夜中などのネットワークトラフィックが低いときに開始される。典型的には、プロセス410は、終了するのに数時間かかるかもしれない。
【0110】
図4Dは、ブロードキャスト又はマルチキャストのためサービスプロバイダに1以上の高帯域幅チャネルが提供される構成に対してサービスを提供するボックスにリリースを提供するフローチャート又はプロセス440を示す。このような構成は、超高速ブロードキャスト又はマルチキャスト能力を享受するケーブル又は衛星インフラストラクチャにおいて、又はマルチキャストサポートを有するデータネットワークにおいて見出されるかもしれない。プロセス410は、好ましくは図4Cに関して理解され、ボックスには受信機能(チューナなど)が備えられ、放送を受信するための適切なチャネルにチューニングされることが仮定されるボックスのライブラリを1以上のタイトルにより更新するためのインフラストラクチャを利用する。このようなボックスの具体例として、衛星受信ボックスやケーブルセットトップボックスがあげられる。
【0111】
図4Cに示されるように、サーバ432が、ケーブルネットワーク(すなわち、媒体としての同軸ケーブルやファイバ)又は衛星ネットワーク(すなわち、伝送媒体としての大気)であるかもしれないネットワークに接続される。図4Aのサーバ402と同様に、サーバ432はリリースを配信するためのものである。442において、プロセス440はリリースを待機する。プロセス440は、リリースが利用可能になると開始される。442において、リリースに係るタイトルがボックスへの配信のためサーバ432において準備される。図2Eのプロセス260は、各タイトルのヘッダ及び対応するセグメントへの細分化のための一例となるプロセスである。
【0112】
446において、すべてのタイトルに対するヘッダとすべてのセグメントを含むリリースパッケージが、所定の時間に又は定期的にネットワーク436にブロードキャストされる。448において、サーバ432から受信可能な、又はローカルに構成可能な命令に従って、各ボックスは、リリースからのそれの構成に従ってデータをキャプチャ及びキャッシュする。例えば、ヘッダを受信し、セグメントを受信しないと仮定されるボックスは、ヘッダのみをキャプチャ及びキャッシュする。ボックスがヘッダと2つのセグメントを受信すると仮定される場合、当該ボックスは、ヘッダと2つのセグメントのみをキャプチャ及びキャッシュする。
【0113】
サービスを提供する各ボックスが統合された1つのリリースパッケージから適切なデータを選択するため、各ボックスのライブラリは同期的に更新される。一部のボックスがブロードキャストの際に更新することができなかった場合、これらのボックスは次の簿ロードキャストにおいて更新されるか、又は上述したような図4Bのプロセスを利用して他の更新されたボックスにより非同期的に更新することができる。一実施例では、ケーブル又は衛星インフラストラクチャにおける複数のチャネルが、例えば、指定されたチャネルにおける各リリースパッケージなどをブロードキャスト又はマルチキャストすることによって、更新プロセスを円滑化するのに利用されてもよい。上述されるように、1つのシナリオでは、それぞれが1つのタイプのボックスに相当する6つのリリースパッケージが存在するかもしれない。また、ボックスは、それのリリース用の特定のチャネルにチューニングされるように構成されてもよい。
【0114】
最近サービスを開始した、又は長い期間の後にネットワークに最近再接続された新たなボックスは、ここではまとめて新規ボックスと呼ばれる。これらの新規ボックスは、エンプティであってもよいし、又は出荷のためパッケージ化され、又はネットワークから切断された時点では利用可能であり、さらに一部は現在も利用可能であり、一部は現在は利用不可であるタイトルのヘッダ及びセグメントを含むものであってもよい。これら新規のボックスがネットワークから切断されている間、アクティブなボックスのライブラリは何回も更新されているであろう。この結果、もとのライブラリは古いものとなっている。
【0115】
サービスプロバイダは毎日10個のリリースによりライブラリを更新し、ライブラリの合計タイトル数は5000であることが仮定されている。アイドル時間が10日間である場合、もとのライブラリは100個のリリースを欠落している。アイドル時間が約6ヶ月である場合、ボックスのもとのライブラリは約1800個のリリース分だけ古いものとなっている。図5Aは、一実施例によるライブラリ500に対する段階的な更新を示す。新規ボックス(切断又は単に出荷前にライブラリによりコピーされた)になった時点で、ボックスは、上位バンド504に100個のタイトルと、低バンド506に4900個のタイトルを有する。180日間サービスを提供していなかったボックスについて、ライブラリ状態510は、当該ボックスがどの程度古いものになったか、すなわち、ライブラリ500が1800個のリリースを見逃し、そのうちの100個が上位バンド504のリリースであり、1700個が低バンド506のリリースであることを示している。これらのボックスを購入するため店頭に置かれた場合、更新すべき多数のタイトルがないことになる。同様に、これらのボックスを購入するため店頭にない場合、新規ボックスのタイトルは古いものであるかもしれないが、更新すべきボックスは多くはない。
【0116】
リリースが時間の経過と共に要求又は人気が低下し、最終的に低バンド506に置かれることは通常理解される。従って、180日後、もとのライブラリ500には排除されるべき約1800個のタイトルがあり、もとのライブラリ500の3200個のみがライブラリ510に維持されるかもしれない。一実施例では、1800個のタイトルが、ネットワークがもはやそれらをサポートしなくなってからボックスがサービス提供する時点で即座に排除される。
【0117】
ライブラリ510を更新するため、ボックスは、ボックスタイプとバンド情報に対応する1800個の見逃したヘッダとセグメントを受信しなければならない。1800個のリリースのヘッダと対応するセグメントのそれぞれをダウンロードするため、ネットワークの帯域幅の制約の下、ボックスがタイトルを注文するのに利用可能となるまでに数日間、数週間又は数ヶ月かかる可能性があり、運用上は所望されるものでない。
【0118】
一実施例では、ボックスの更新を迅速化するプロセスは、上位バンドをさらなるバンドに分割することによって実現される。例えば、高(H)バンドと中(M)バンドとそれぞれ呼ばれる2つのバンドがあるかもしれない。各バンドは、例えば、Hバンドには50タイトルとMバンドには50タイトルなどのいくつかのタイトルが割り当てられるかもしれない。便宜上、図3Aは、Hバンド、Mバンド及びLバンドによるタイトルの一例となる人気による分類として使用されるかもしれない。ボックスがライブラリを更新するのに必要な時間を短縮するため、Mバンドのための多数のセグメントのフェッチが回避されるかもしれない。このアイデアの背後にある合理性は、Mバンドのタイトルは人気が低下しつつあり、同時要求をサポートするため、ネットワークにおいて多くの分散セグメントがまもなく不要になるというものである。従って、例えば、新規ボックスはLバンドと同様にMバンドのタイトルを扱い、これらのタイトルの僅かなパーセンテージのみに対して1つのセグメントのみを格納することを選択するかもしれない。
【0119】
同じ又は他の実施例では、ボックスは、ユーザがライブラリの人気のあるタイトルに迅速にアクセスすることを可能にし、セグメントのフェッチ前に見逃したタイトルのヘッダをフェッチすることによってライブラリ全体にアクセスすることを可能にする。ぼっくにヘッダがローカルに存在する限り、ユーザはタイトルを発注及び再生することが可能であり、ネットワークから分散セグメントをフェッチすることが可能となるため、当該タイトルがHバンドにたまたま存在したとしても、何れのセグメントも再生を可能にするためローカルにキャッシュされる必要はない。従って、ボックスを更新するための良い戦略は、テールの前にヘッダをフェッチし、タイトルの人気に従ってヘッダがフェッチされるシーケンスを発注することを優先させることである。これにより、大部分の人気のあるタイトルが即座に利用可能となる。
【0120】
同じ又は他の実施例では、いくつかのテールセグメントは、一部のヘッダより優先され、これにより、一部のセグメントはボックスにより迅速に受信され、セグメントの有用な供給者として機能を開始し、他のボックスからの要求にサービス提供することが可能となる。ライブラリ全体へのアクセスをどの程度の迅速さによりユーザに提供する必要があるかと、ユーザのボックスがシステムのロードの一部を負担する有用な供給者になることがどの程度重要であるとの間の解決される必要があるトレードオフに応じて、何れのセグメントが何れのヘッダに対して優先するか決定するための多数の方法が存在することは理解されるかもしれない。以下において、ヘッダとセグメントに関する優先度の選択の一実施例が説明される。
【0121】
一実施例によると、新規ボックスは、Hバンドの50タイトルのそれぞれのヘッダと1つの対応するセグメントとをダウンロードすることによって開始する。このデータは、50タイトルの対応するヘッダと各セグメントを有する他のボックスからフェッチされてもよい。ライブラリ状態512は、Hバンドの所望の状態が第1日に更新されることを示している(Hバンドの更新全体が1日で終了すると仮定する)。Hバンドのタイトルを更新する方法はいくつかあるかもしれないということは理解されるかもしれない。一実施例では、最も要求されるタイトルからスタートしてHバンドの各ヘッダがまず段階的にフェッチされ、その後、Hバンドの各タイトルのセグメントがフェッチされる。他の実施例では、最も要求されるタイトルから始めて、Hバンドの各タイトルのヘッダと対応するセグメントがまず段階的にフェッチされる。
【0122】
Hバンドの50タイトルがほぼ更新された後(各Hバンドタイトルが2つのローカルセグメントを要求する場合、各タイトルはこの段階で1つの見逃したセグメントを依然として有する)、Mバンドの50タイトルが次に更新される。しかしながら、Hバンドの50タイトルの更新中、他のタイトルが、動的な更新によってライブラリに追加されている。この結果、Mバンドには更新すべき50未満のタイトルが存在するかもしれない。なぜなら、1以上のタイトルがHバンドからMバンドに排除されるかもしれないためである(図の矢印により示される)。一実施例では、Mバンドの各タイトルのヘッダがサービスを提供する他のボックスからフェッチされ、Mバンドのタイトルの5%のみに対する1つのセグメントがフェッチされる。他の実施例では、Mバンドタイトルのヘッダのみがフェッチされ、セグメントは以降にフェッチされる。Mバンドの中間状態は、Mバンドのタイトルに対して0、1及び2セグメントが存在する理由を説明するため、図3Aにより良好に理解することが可能である。
【0123】
(1+X)日後(ただし、Xは、HバンドとMバンドとを更新するのに要する時間を示す)(ライブラリ状態514を参照)、ネットワークスピードに応じて、Hバンドからある個数のタイトルがMバンドに排除され、それと同時に、Mバンドの対応する個数のタイトルがLバンドに排除されるかもしれない。ライブラリがその中のタイトルの古さに関して段階的に構成されている場合、ライブラリ状態502のもとの100タイトルはシフトされたものであり、更新されるべきであったLバンドの1700タイトルが存在するが、上位バンド504からの排除は、実際に更新すべきタイトルの実際の個数を減少させたことは理解されるかもしれない。このとき、すべての見逃したタイトルのヘッダが受信されるまで、Lバンドのタイトルのヘッダが継続的にフェッチされる。最後に、H、M及びLバンドのタイトルに対して、すべての見逃したセグメントもまたフェッチされる。ライブラリ状態516は、更新プロセスの完了後にライブラリの最終的な状態を示す。
【0124】
図5Bは、3つのボックス532〜534がシステムに追加された状況530を示す。これら3つのボックス532〜534は各自の識別子及び/又はIPアドレス及びライブラリ状態と共にサーバ536に登録された後、サーバ536は、これらのボックスが以前に見逃したものと、見逃したタイトルをフェッチする場所などの更新方法に関する情報を返す。この状況530は、ボックス532がまずボックス群537〜540から見逃したタイトル(ヘッダ又はおそらく対応するセグメントなど)をフェッチし、ボックス533及び534がまずボックス543と544のグループから見逃したヘッダをそれぞれフェッチすることを示している。動作について、ボックス(すなわち、532)は対応するヘッダ及び/又はセグメントをフェッチするためボックス間を動的にスイッチするよう構成されることに留意される。
【0125】
これら3つのボックス532〜534はまず上位バンド(すなわち、Hバンド)の各タイトルに対して1つのヘッダと1つのセグメントにより更新される。動作について、これら3つのボックス532〜534は他のボックスへのサービスの提供を開始する候補とすることが可能である(例えば、Hバンドのタイトルなどに対して)。図5Bにおいて、発注元のボックス542は、上位バンドのタイトルに対する注文を発注している。また、当該タイトルはヘッダと4つのセグメントとを有するファイルに係るものであり、4つのセグメントのうちの2つは発注元のボックス542にあることが仮定される。従って、発注元のボックス542は、その他の2つの欠落しているセグメントをフェッチする必要がある。当該タイトルのヘッダが再生されている間に、発注元のボックス542は、ボックス532〜534のそれぞれがこれら欠落しているセグメントの1つを有し、それらのすべてが2つの欠落しているセグメントの同じものを有しているとは限らない場合、ボックス532〜534の何れか2つから欠落しているセグメントを取得するようにしてもよい。ボックス群537〜540、543及び544はボックス532〜534を更新するのにビジー状態であるため、ボックス532〜534は、Hバンドのリリースのセグメントが利用可能になると即座に、他のものにサービスを提供することを開始する。このため、Hバンドのタイトルに対する最大の持続可能な同時性は変わらないままとされることが理解されるかもしれない。さらに、新たにリリースされたタイトルに対する再生サポートは、新規ボックスが新たなリリースの再生しかサポートできないため、新規ボックスに転送されるかもしれないことは理解されるであろう。これは、トラフィック問題を大きく抑制し、任意のバンドのタイトルに対して最大の持続可能な同時性を向上させる。
【0126】
図5Cを参照すると、おそらく製造後に長期間店舗の棚に置かれていたため、ある期間オンライン状態でなかったライブラリを更新するためのフローチャート又はプロセス550を示す。プロセス550は、ハードウェア、ソフトウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されるかもしれない。プロセス550は、552においてネットワーク接続される何れかの新規ボックスを待機する。プロセス550は、新規ボックスがネットワークにおいて検出され、又はサーバが新規ボックスの存在を通知されると開始される。一実施例では、新規ボックスは、電源オンされ、ネットワークに接続されると、サーバプロバイダに係るサーバに自動的に通知及び/又は登録するよう構成される。当該ボックスは、それの識別子とIPアドレスとを含む通知と、おそらくボックスが直近に更新された日時とを送信してもよい。
【0127】
553において、プロセス550は、ボックスのライブラリがレコードに従って更新される必要があるか検出する。ボックスのライブラリが更新される必要のないケースがある。例えば、ボックスが短時間の間電源オフされていた場合、それは新たなコンテンツを見逃していないかもしれない。一実施例では、サーバは、ライブラリがボックスの状態に従って更新される必要があるか判断する。ライブラリを更新する必要がない場合、プロセス550は552に戻り、他の新規ボックスを待機する。ライブラリが更新される必要があると判断された場合、プロセスは554に移行する。
【0128】
554において、ボックスがオフラインであったため、又はストレージのエラーのため、ライブラリ内の時間の経過したタイトル群と、過去に見逃したリリース群又はボックスから現在欠落しているリリース群とが、決定される必要がある。他のボックスの更新されたライブラリと同期するため、時間の経過したタイトルはもはやアクセス付加としてフラグ付けされる(当該データがボックスにおいて依然として利用可能であったとしても)。プロセス550は、その後に556においてライブラリの更新に移行する。上述されるように、ライブラリはまず、Hバンドのタイトルのヘッダによって更新され、これにより、ボックスはこれらのタイトルの注文を受け付け、これらのタイトルの他のボックスの注文をサポートするようになるかもしれない。動作について、ヘッダがローカルにキャッシュされると即座に、ボックスは、当該ヘッダに係るタイトルに対する発注を実現する状態にある。Hバンドタイトルに対して、ボックスは556において、他のボックスからのこれらのタイトルのそれぞれに対して、ヘッダ又はヘッダ及び対応するセグメントをフェッチするよう構成される。ヘッダ又はセグメントをフェッチするための一例となる機構の1つは、上述されるようなアプリケーションレイヤマルチキャストgossipプロトコルによるものである。
【0129】
システムは、各ボックスがHバンドタイトルのヘッダと1つのセグメントのみを格納していることを要求するよう構成されるかもしれない。あるいは、システムは、各ボックスがHバンドタイトルのヘッダと複数のセグメントを格納していることを要求するよう構成されるかもしれない。何れの場合も、ボックスは、注文の実現又はライブラリの更新のため、他のボックスに対してサービスを提供する準備ができている。さらに、新たなタイトルによって新規ボックスを更新するための責任は、より新規なボックスのみが新たなタイトルを更新することを支援することが可能であるため、新規ボックスに転換される可能性があることは理解されるであろう。
【0130】
上位バンドのタイトルが更新されている間、プロセス550はサーバからのリリースがあるかチェックする。558においてリリースがある場合、当該リリースがライブラリに適しているかに応じて、ライブラリの適切なタイトルに影響を与える。一実施例では、ライブラリはいくつかの高、中及び低バンドに実質的に分割される。リリースのタイトルがHバンドに備えられるべきであるとされる場合、Hバンドの相対的に人気の低いタイトルが次の下位のバンドに排除され、554において当初決定された実際のタイトル数を実質的に減少させる。リリースがない場合、又はリリースが最も要求されているタイトルを含んでいない場合、プロセス550はHバンドのタイトルが更新されるまで556〜562を継続する。動作について、各バンドのタイトルが、人気及び/又は経過期間に関してあるバンドから下位のバンドに継続的及び段階的に排除される。便宜上、3つのバンド、すなわち、H、M及びLバンドが使用されると仮定される。
【0131】
プロセス550は、MバンドとLバンドのすべてのタイトルのヘッダと、MバンドとLバンドのタイトルの僅かなパーセンテージの対応するセグメントをさらにフェッチするため564に移行する。一実施例では、Mバンドのタイトルの5%がセグメントを有し、Lバンドのタイトルの5%がセグメントを有している。この結果、ライブラリの更新は、ボックスがサービスを提供することを注視することを回避する。何れの場合も、タイトルがHバンドからMバンドに排除される毎に、それの対応するセグメントが単にMバンドに移される。他の何れのセグメントもシステム構成に従って破棄されるかもしれない。また、タイトルがLバンドに移されると、当該タイトルのセグメントはLバンドに保持されているかもしれず、又は当該タイトルが当該ボックスに対して指定されたタイトルのパーセンテージの範囲内に属するか否かに応じて破棄されるようにしてもよい。固定数のタイトルを制御し、ローカルストレージを維持する場合、Lバンドの対応するタイトル、典型的には最も人気のないタイトルが、破棄又は上書きされる。セグメントの破棄は、ボックスが格納スペースを使い果たし始めると実行され、より多くの利用可能な格納スペースが存在する場合には回避することが可能である。
【0132】
566において、プロセス550は、ボックスがユーザ又は他のボックスにサービスを提供することに影響を与えることなく、Hバンド及び/又はMバンドのタイトルのセグメントをフェッチすることを継続する。Hバンドのタイトルに2つのセグメントが存在するケースがあることが説明される。556において、ボックスがユーザ又は他のボックスにサービス提供できる準備ができるための時間を最小化するため、セグメントの1つのみがフェッチされたことが思い起こされる。これにより、566において他のセグメントがフェッチされるかもしれない。同様に、Mバンドのすべてのタイトルが少なくとも1つのセグメントを有すると仮定されるが、そこでのタイトルの5%しかセグメントを有していない。このため、対応する各セグメントは、ボックスがユーザ又は他のボックスにサービスを提供することを禁止することなく、他のボックスからフェッチされてもよい。
【0133】
図5Cには直接的には示されていないが、559と同様の処理がそれぞれ564と566に本来的に含まれている。さらに、プロセス550の一部は、好ましくはネットワークのトラフィックが低いとき、1日の任意の時点で実行することが可能である。ライブラリを更新するのに必要なデータを供給するボックスを選択する際、これらのボックスは、ネットワークの状態、地理的局所性、供給元と受信者との間で実現される持続可能な帯域幅などと共に、ボックス自体の状態を利用するため、時間と共に決定又はスイッチされるかもしれない。
【0134】
また、ケーブル若しくは衛星ネットワークを介し、又はIPマルチキャストを介し利用可能なものなど、高帯域幅ブロードキャスト若しくはマルチキャストチャネルの利用性が、新たな映画の提供に関して上述されたように、ボックスを更新するプロセスを迅速化するのに利用可能であることが理解されるかもしれない。ブロードキャストチャネルは、おそらく最も要求の高いタイトルを優先させて、最新のリリースの伝送に利用されてもよい。その後、新規ボックスは、それらが見逃したヘッダとセグメントを迅速に受信するため、適切なチャネルにチューニングするようにしてもよい。
【0135】
図6Aを参照すると、サーバ600の一例となる実現形態が示される。サーバ600は、図1Aのサーバ102に対応するかもしれないが、単一の計算装置又はコンピュータクラスタであるかもしれない。サーバ600は、サーバモジュール602とインタフェース604とを有する。一般に、サーバモジュール602は、メモリにロードされ、それの処理を実行するため1以上のプロセッサ(図示せず)により実行される。アプリケーションでは、サーバ600は、メディアサービスをユーザに提供するため、サービスプロバイダ又は企業によって運用されているかもしれない。
【0136】
サーバ600はまた、コンテンツ若しくはソースプロバイダ608とサーバ600との間の通信を実現する配信エージェント606を有する。実現形態に応じて、ソースプロバイダ608は、以下に限定されるものではないが、コンテンツ受信機、コンテンツ作成者及び映画配給者を含むかもしれない。配信エージェント606は、コンテンツがソースプロバイダ608から適切に受信されることを保証するため設けられる。コンテンツの受信方法に応じて、配信エージェント606は、各種形式により実現されるかもしれない。例えば、映画配給者は、サーバ600を運用するサービスプロバイダに映画をリリースする。映画はサーバ600にセキュアに転送され、この場合、配信エージェント606はセキュア伝送媒体となる。他の例では、コンテンツは衛星によって転送され、この場合、配信エージェント606は衛星受信機であるかもしれない。企業がそれの製品やサービスを複数のユーザにサーバ600を介し宣伝することを所望するさらなる他の例では、当該企業はインターネットを介しサーバ600にコマーシャルビデオを配信するかもしれない。従って、配信エージェント606は、インターネット若しくはローカルネットワークの一部であり、サーバ600とインターネットとの間のデータ通信を実現するため、必要なインタフェース(TCP/IPなど)を提供する。
【0137】
効率化のため、サーバ600は、各種フォーマットによるソースファイルをクライアントボックスにより理解される受付可能なフォーマットに変換するため設けられるトランスデューサ609を有するか、又は接続されるようにしてもよい。典型的には、コンテンツプロバイダによって提供されるビデオソースは、高品位映像信号、DVD、フィルムなどである可能性がある。当該フォーマットがサーバ600に所望されるフォーマットでない場合、トランスデューサ609は、このようなソースを受付可能なフォーマット(MPEG−2、MPEG−4など)に変換するよう起動される。上述されるように、ソースプロバイダ608は、多数のタイプのソースを提供可能である。トランスデューサ609又は類似する機能を有する適切な装置によって、サーバ600は、任意のタイプのソースを受信し、それらをユーザに費用又は情報のため配信することが可能である。
【0138】
サーバ600は、データネットワークを介しサービスを提供する複数のボックスとサーバ600との間のデータ通信を実現する他のインタフェース604を有し、そこでは、サーバ600は、これらのボックスに関してリモートに配置されてもよい。ネットワーク611は、インターネット、PSTN(Public Switch Telephone Network)、プライベートネットワーク、又は無線ネットワークを含む大規模ネットワークの一部とすることが可能である。ネットワーク611は、電話線、ケーブル、ファイバ又は大気(無線)などの1以上の伝蔵媒体を利用するかもしれない。サーバ600とボックスとの間の通信に使用される一例となる通信プロトコルはTCP/IPである。
【0139】
図6Aに示されるように、サーバモジュール602は、互いに協調的に動作するよう構成される複数の機能エンジン又はモジュールを有する。図6Aのサーバモジュール602にリストされるすべてのモジュールが、実際に使用される必要があるとは限らない。実際の実現形態又は要求に応じて、これらのモジュールは選択的に配備されるようにしてもよい。
【0140】
ユーザ管理モジュール610は、加入者又はユーザを管理するよう構成される。それは、サービスプロバイダからメディアサービスを受信する契約をしている又は所望しているすべてのユーザに係るアカウントの追加、削除又は更新を実現する。ユーザ管理モジュール610はまた、すべてのアカウントに対する支払の決済を管理する。一実施例では、各アカウントは、メディアサービスへの無制限なアクセスを許可する固定の月単位の料金が課金される。他の実施例では、各アカウントは、サービスプロバイダによって提供されるライブラリのタイトルに対する注文が発注される毎に、更新又は課金される。
【0141】
コンテンツ管理モジュール612は、ユーザに提供可能なすべてのコンテンツを管理する。上述されるように、これらのコンテンツは、ヘッダとセグメントの形式により構成される。これらのオブジェクトは、サービスを提供するボックス間に分散される。コンテンツ管理モジュール612は、これらのオブジェクトの分散を管理するよう構成される。コンテンツ管理モジュール612にアクセスすることによって、オペレータは、ライブラリのタイトルに関するオブジェクトの分散方法を直接的に制御し、利用可能なものと、これらのオブジェクトの分散方法及び場所に関するマッピング情報を取得するようにしてもよい。図6Bは、5000タイトルのライブラリがN個のボックスにどのように分散されているか示す一例となるマップ630を示す。カラム632は、サービスを提供するすべてのボックスをリストしている。各ボックスには、識別用の一意的な識別子が割り当てられている。カラム632の情報は、サービスを提供するボックスの識別子としてみなされるかもしれない。例えば、ボックス1には、“ボックス1”の一意的な識別子又は英数字のシーケンスが割り当てられる。
【0142】
カラム634は、カラム632にリストされる各ボックスの対応するIPアドレスをリストしている。カラム636は、ライブラリのすべてのタイトルのヘッダをリストしている。カラム638は、タイトル1が2つのセグメントを各ボックスにキャッシュされることが要求されていると仮定すると、タイトル1の何れのセグメントが欠くボックスに常駐しているかリストしている。カラム640は、タイトル2が1つのセグメントを各ボックスにキャッシュされることを要求されていると仮定すると、タイトル2の何れのセグメントが欠くボックスに常駐しているかリストする。カラム642は、タイトル5000が選択されたボックスに1つのセグメントを有することが要求されていると仮定すると、タイトル5000の何れのセグメントが選択されたボックス群にあるかリストしている。この結果、ボックスのすべてのオブジェクト(すなわち、ヘッダ又はセグメント)が、発注されたタイトルのローカルな再生又は他のボックスへのアップロードのため一意的にアドレス指定されるかもしれない。
【0143】
配信管理モジュール614は、発注元のボックスから受信した注文に応答するよう構成される。コンテンツ管理モジュールと共に動作して、配信管理モジュール614は、この注文に応答して、ソース情報、認証情報及びセキュリティ情報を含むレスポンスを生成する。ソース情報の一例が、図6Cのテーブル650又は図6Dのテーブル652のテーブルとして図示される。テーブル650は、注文されたタイトルのセグメントを供給するよう指定された4つのボックスのそれぞれのIPアドレス(IPA1など)を含む。認証情報は、他のボックスとのセキュア通信のため発注元のボックスを認証する。セキュリティ情報は、タイトルの再生のためのデータの解読を実現する。レスポンスはさらに、他のボックスから抽出されるべきセグメントに関する命令と、発注元のボックスを特定するIPアドレスとを有するようにしてもよい。レスポンスを受信すると、発注元のボックスは、選択されたタイトル(Lバンドにあると仮定される)に対応するヘッダが再生されることを可能にし、それと同時に若しくはその後まもなくして、発注元のボックスは、サーバから受信したレスポンスに従って4つの各リクエストを発行する。各リクエストがこれら4つのボックスの1つのIPアドレスを有していることは理解される。各ボックスがリクエストの1つを受信すると、要求されたセグメントが発注元のボックスにリリース又はアップロードされる。
【0144】
ネットワーク管理モジュール616は、サービスを提供する各ボックスの状態をモニタするため設けられる。1つのアプリケーションでは、ネットワーク管理モジュール616は、ボックスのアドレスを受信するよう構成される。多くのケースにおいて、ボックスには経時的に変動する可能性のある動的アドレスがインターネットサービスプロバイダによって割り当てられている。サービスを提供するすべての各ボックスがサーバ600に接続されることを保証するため、ボックスのIPアドレスが何れかの理由により変更されるときは常に、それの新たなIPアドレスは時間内にサーバに通知される必要がある。一実施例では、各ボックスは、ネットワーク管理モジュール616が必要に応じてそれのIPアドレスを変更したボックスのIPアドレスを更新するように、サーバとの間でイベントトリガーに若しくは定期的にショートメッセージを送受信するよう構成される。他方、ネットワーク管理モジュール616は、ショートレスポンスのため各ボックスにショートメッセージを送信するよう構成される。ボックスが動作していない場合(電源オフ又は不具合など)、ネットワーク管理モジュール616は、即座に通知され、発注元のボックスに対してセグメントを提供するための指定から当該ボックスを排除する配信管理モジュール614を更新する。同様に、ボックスが映画の注文に対してセグメントをすでに供給している場合、ネットワーク管理モジュールは、配信管理モジュールに他の注文に対するセグメントを供給するためボックスの利用可能性状態が通知され続けるようにしてもよい。
【0145】
提供管理モジュール618は、ライブラリ管理モジュールとも呼ばれるかもしれない。提供管理モジュール618は、各ボックスのライブラリを更新するためのものである。リリースがあるときは常に、提供管理モジュール618は、ボックスへのリリースの適切な提供を保証する。リリースが新たにリリースされた映画であり、おそらく需要が高い状況では、提供管理モジュール618は、当該リリースに係るファイルのヘッダと少なくとも1つのセグメントを各ボックスに常駐させる。リリースが新たにリリースされた映画ではないが、需要が高いような他の状況では、提供管理モジュール618は、当該リリースに係るファイルのヘッダとおそらく1つのセグメントを各ボックスに常駐させる。リリースが古典的なタイトルであり、相対的に需要が低いさらなる他の状況では、提供管理モジュール618は、ヘッダを各ボックスに常駐させ、セグメントをネットワークの選択されたボックス群に常駐させる。新規ボックスがネットワークに接続されたさらなる他の状況では、ネットワークモニタリング管理616が、ボックスの状態を提供管理モジュール618に通知するよう構成される。ボックスの既存のライブラリの状態に応じて、提供管理モジュール618は、何れがライブラリにおいて欠落しているか判断し、他のボックスからライブラリを更新する方法についての命令をボックスに提供する。
【0146】
セキュリティ管理モジュール620は、サービスを提供するボックスに分散されるオブジェクトをセキュア化するため設けられる。一実施例では、セキュリティ管理モジュール620は、発注元のボックスに係るユーザを認証し、ユーザの認証後及び/又は注文に対する支払の決済後、発注元のボックスに1以上のセキュリティキーと認証情報を提供するよう構成される。セキュリティキーは、発注元のボックスにおいてヘッダ及び/又はセグメントの解読を実現するかもしれない。認証情報は、発注元のボックスがタイトルの再生のため必要とされるセグメントをフェッチするため、発注元のボックスが指定されたボックスと通信することを可能にする。他の実施例では、セキュリティ管理モジュール620は、サービスを提供するボックスに分散される前に、すべてのオブジェクト(ヘッダ及び/又はセグメント)を暗号化するため、コンテンツ管理モジュール612又は提供管理モジュール618と共に動作する。さらなる他の実施例では、セキュリティ管理モジュール620は、サービスを提供するすべてのボックスにオブジェクトとして分散されるすべてのコンテンツのデジタル著作権管理(DRM)を提供する。さらなる他の実施例では、セキュリティ管理モジュール620は、それがセグメントに分割され、ボックスに分散される前に、タイトルのファイルから小さな部分を取り除くようにしてもよい。ボックスがタイトルを発注すると、ファイルのこれらの部分が、おそらくサーバレスポンスの一部として、サーバにより直接的に供給され、これにより、タイトルがサーバのアクティブな参加などに完全に構成することができないことを保証することによってセキュリティを向上させる。
【0147】
コマーシャル情報管理モジュール622は、必要に応じてユーザに表示することが意図されるコマーシャル情報を管理するため設けられる。このような情報の具体例として、以下に限定されるものではないが、宣伝、特別提供、映画予告編及び公共放送などがあげられる。このような情報は、映画を表示する画面の一部に重ねられ、2つの映画の間のインターバルの間に若しくは映画の表示開始に表示され、又は単にユーザにより要求されるかもしれない。情報に応じて、このような情報は、ボックスの地理的位置、視聴行動又はユーザの所望する言語を含む1以上のファクタに従って、独立にリリースされるか若しくはリリースに係るヘッダに添付されてもよい。
【0148】
ソースプロバイダ管理モジュール624は、プロバイダからの配信されたコンテンツを利用するため、ユーザにより支払われた料金の配布を管理するため設けられる。実現形態に応じて、ソースプロバイダ管理モジュール624は、配信エージェント606を介し毎日、毎週又は毎月、各コンテンツプロバイダと支払を共有し、又は提供されるライブラリのタイトルの財務予想又は統計を提供するよう構成されるかもしれない。
【0149】
図6Aの配信管理モジュール614をさらに参照して、一実施例によると、配信管理モジュール614は、指定されたボックスの1以上が突然利用不可となり、又は発注元のボックスへの要求されたセグメントの供給を継続することがスローダウンする状況を回避するよう構成される。発注元のボックスに応答したソース情報は、指定されたボックスのそれぞれに対するバックアップ情報を含む。図6Dは、指定された各ボックスのバックアップ識別子(IPアドレスとして示される)を含むテーブルのバックアップボックスによる一例となるソース情報を示す。ボックスの1つが発注元のボックスからのセグメントに対するリクエストに応答しない場合、又はセグメントが正確に受信できない場合、バックアップIPアドレスが、当初指定されたボックスが提供できないセグメントを提供するため利用可能な、又は提供し続けるのに利用可能な対応するバックアップボックスにスイッチするため即座に呼び出される。
【0150】
完全にするため、図6Eは、発注元のボックス654がボックス654において発注されたタイトルに係る3つの各セグメントを受信するため指定された3つのボックス655〜657によりサポートされている一実施例を示す。各ボックス655〜657には、対応する同一のセグメントを有するバックアップボックスが設けられる。具体的には、ボックス655はバックアップボックス658によりサポートされ、ボックス656はバックアップボックス659によりサポートされ、ボックス657がバックアップボックス660によりサポートされる。注文されたタイトルのヘッダが発注元のボックスにおいて再生されている間、これら3つの分散されたオブジェクトは、ボックス655〜657からフェッチされる。ある理由のため、ボックス656がセグメントの提供を継続することを拒絶した場合、バックアップボックス659は、セグメントの提供を継続するようボックス656を置換するため起動される。一実施例では、バックアップボックス659は、ボックス654にセグメントを共同して供給するためボックス656に加わるよう構成される(例えば、それぞれは、同一のセグメントの異なる部分を供給するなど)。
【0151】
図6Fは、発注元のボックス670がボックス670の発注されたタイトルに係る3つの各セグメントを受信するため、指定された3つのボックス671〜673によりサポートされている他の実施例を示す。動作について、何れかの理由による発注元のボックスの故障はまれであり、全く同時に複数のボックスが故障することはさらにまれである。従って、指定された3つのボックス671〜673に対する3つのバックアップボックス674〜676は、セグメントを供給する他の指定されたボックスに対するバックアップボックスとして構成されるかもしれない。図6Fは、発注元のボックス678が3つの指定されたボックス682〜684により供給を受けながら、2つの指定されたボックス679及び680により供給を受けている発注元のボックス677を示す。各フェッチプロセスが良好に実行されることを保証するため、指定された各ボックスはバックアップボックスによりサポートされ、この場合、指定された2つのボックス679と680がボックス674と675によりバックアップされ、指定された3つのボックス682〜684がボックス674〜676によりバックアップされる。バックアップボックス674〜676の1つがアクティブボックスとなると、サーバ600は、フィールドの他のボックスをバックアップボックスとして即座に指定するようにしてもよい。
【0152】
図6Gを参照すると、ライブラリのあるセレクション(すなわち、タイトル)の瞬時の再生を開始するためのフローチャート又はプロセス686が示される。プロセス686は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されてもよい。好ましくは、プロセス686は、ユーザに係るボックスからの選択されたタイトルの瞬時の再生を実現するサーバとして指定された計算装置において実行される。一実施例では、プロセス686は、メディア・オン・デマンドシステムにおいて利用される。688において、プロセス686は、ユーザに係る発注元のボックスからのリクエストを待機している。典型的には、ユーザはタイトルを選択し、その後に注文を発注する。さらに後述されるように、発注元のボックスはサーバに転送されるリクエストを生成する。プロセス686は、注文を含むこのようなリクエストが発注元のボックスから受信されると起動される。一般に、リクエストは、発注元のボックスの識別子及びIPアドレス、ユーザアカウント情報(ユーザ名など)、並びに注文情報を含む。発注元のボックスにおいて何かが行われる前に、プロセス686は、ユーザの認証に移行する。ユーザが登録されていない場合、プロセス686は691に移行し、エラーメッセージを含むレスポンスが生成され、発注元のボックスに返される。実現形態に応じて、エラーメッセージは、エラーメッセージを表示するため、又はユーザをシステムに登録するよう求めるため、発注元のボックスのローカルモジュールを起動するかもしれない。
【0153】
ユーザが認証された後、プロセス686は692に移行し、当該注文に対する支払が決済されているか判断する。一実施例では、登録プロセスにおいて、ユーザは、システムを用いてユーザが発注した注文に関する課金のためのクレジットカード情報を提供するようにしてもよい。他の実施例では、ユーザは、各課金に対する包括的な決済のための月毎の請求書を受信するようにしてもよい。支払が決済されていない場合(例えば、ユーザが自らの口座に大きな未払いがある)、プロセス686は693に移行し、エラーメッセージを含むレスポンスが生成され、発注元のボックスに返される。エラーメッセージは、支払のためユーザにローカルに表示されてもよい。
【0154】
支払決済後、プロセス686は694に移行し、発注元のボックスにセグメントを供給するのに指定されるいくつかのボックスを決定する。ボックスの正確な個数は、選択されたタイトルの再生を継続するため発注元のボックスが必要とするセグメント数に依存する。696において、受信したリクエストに従ってレスポンスが生成される。一般に、レスポンスは、ソース情報、認証情報及びセキュリティ情報を含む。ソース情報は、発注元のボックスが選択されたタイトルの再生を継続するため必要とされるセグメントをどのようにかつどこで取得できるか指示する。認証情報は、発注元のボックスが必要とされるセグメントを供給するため指定されたボックスとの各自のセキュア化された通信を行うことを可能にする。セキュリティ情報は、発注されたタイトルの再生のためのデータの解読を実現する。他のボックスから必要とされるセグメントを供給するための1以上のボックスを決定する際、1以上のファクタが実現形態に応じて考慮されてもよい。これらのファクタは、以下に限定されるものではないが、各自の利用可能な帯域幅、地理的位置、供給元のボックスの利用可能性の履歴、及び各ボックスのインターネットサービスプロバイダを含む。さらに、発注されたタイトルが人気があるか否か、供給元のボックスが新規であるか否か、及び供給元のボックスがビジー状態であるか否かが考慮されてもよい。何れの場合も、レスポンスは、発注元のボックスに戻されるか、又は発注元のボックスに必要とされるセグメントを受信しながら再生を開始させる。その後、プロセス686は、他のリクエストを待機するため688に戻る。
【0155】
プロセス686は、一実施例では、サーバが発注プロセスのみを取り扱い、実質的に同時に異なるタイトルに対する多数のリクエストを容易に管理することが可能となることを示す。本発明のいくつかの実施例の可能な特徴及び効果の1つは、まとめて利用されていない帯域幅と計算パワーを利用するため、ユーザにデータ供給負担をシフトすることである。
【0156】
図7Aを参照すると、図2Aのボックス(207−1、207−2及び207−nなど)の何れか1つに対応するボックス700の一例となる実現形態が示される。ボックス700は、ローカルモジュール702、インタフェース704及び格納スペース706を有する。ローカルモジュール702は、メモリ708にロードされ、それの処理を実行するためプロセッサ710により実行される。動作について、ボックス700は、サービスプロバイダ若しくはメディアサービスをユーザに提供する企業によって加入者若しくはユーザに提供されるかもしれない。ネットワーク712を介して、ボックス700はサーバ(図6Aのサーバ600など)によって提供されるメディアサービスを受信することが可能である。上述されるように、ボックス700の具体例として、以下に限定されるものではないが、デスクトップコンピュータ、ラップトップ若しくはノートブックコンピュータ、セットトップボックス、電話、タブレットPC若しくはPDAなどの携帯装置などがあげられる。ネットワーク712は、好ましくは、xDSL、ATM、SONET、光ファイバ線、プライベート/パブリック電話網、無線接続、又はCAT−5の1以上を利用するブロードバンドローカルループである。ボックス700は、回線交換若しくはパケット交換接続によりネットワーク712に接続される。
【0157】
図7Aに示されるように、互いに協調して動作するよう構成される複数のモジュールが存在する。図7Aのローカルモジュール702にリストされるすべてのモジュールが必ずしも利用される必要があるとは限らないことは、当業者に理解されるであろう。実際の実現形態若しくは要求に応じて、モジュールは選択的に配置されてもよい。
【0158】
状態通知モジュール714は、ボックス700に影響を与える各種状態をモニタするため設けられる。1つの状況では、ボックス700のIPアドレスが変更されるときは常に、状態通知モジュール714はこの新たなIPアドレスをサーバに即座に通知する。他の状況では、状態通知モジュール714は、ボックスのライブラリがタイムリーに適切に更新可能となるように、ボックスがネットワークからどのくらいの期間切断されていたか検出するよう構成される。さらなる他の状況では、状態通知モジュール714は、利用可能なアップロード帯域幅を検出する。アップロード帯域幅がある数値未満である場合、状態通知モジュール714は、ボックスがセグメントを他のボックスに供給するよう指定されないように、タイムリーにサーバに通知する。さらなる他の状況では、状態通知モジュール714は、供給元のボックスからフェッチされたセグメントがもはや所望されるスピードでないか検出し、当該供給元のボックスとの通信セッションを終了させ、他の供給元のボックスとの通信セッションを起動する。状態通知モジュール714により実行される他の機能は、ここでの詳細な説明により理解されるであろう。
【0159】
ライブラリ管理モジュール716は、格納スペース706の多数のタイトルのヘッダ及びセグメントを管理するため設けられる。ライブラリ管理モジュール716を介して、サーバは、ボックスが何れのオブジェクトを有しているか知る。ライブラリ管理モジュール716はまた、発注されたタイトルを参照して何れの分散オブジェクト(すなわち、欠落したセグメント)がフェッチされるべきか指示する。当該ボックスが新たなタイトルと変更したタイトルのヘッダとセグメントをフェッチ及び受信すると、ライブラリ管理モジュール716がこれらを管理する。ライブラリ管理モジュール716はサーバに発注元のボックスへの供給のための利用可能なセグメントを最新のものに維持させるため、サーバと通信するようにしてもよいことが理解されるであろう。このような通信は、各イベントの後(新たなセグメントの受信など)、所定のインターバルなどにより行われるようにしてもよい。
【0160】
メタデータモジュール718は、ボックス700とそれのユーザとの間の各種のやりとりを実現するため設けられる。メタデータモジュール718は、ユーザがボックス700のライブラリに関するメタデータをブラウズすることを可能にするための各種グラフィックインタフェースを提供するよう実現されてもよい。このメタデータは、以下に限定されるものではないが、ライブラリのタイトルに関する俳優、監督、批評家、推薦広告、評価などに関する関連する情報を含むものであってもよい。一実施例では、メタデータモジュール718は、ユーザからエントリを受け付け、エントリに従って所望の情報を表示する。一例となるアプリケーションでは、ユーザは、1以上のキャラクタを入力する。メタデータモジュール718は、メタデータを検索し、入力されたキャラクタに従ってタイトルのリストを提供する。より多くのキャラクタが入力されると、タイトルの選択がより容易になされるように、リストは段階的に狭められる。他の一例となるアプリケーションでは、メタデータモジュール718は、ユーザがタイトルのタイプ(アクション、ロマンスなど)を指定することを可能にし、当該タイプに関するタイトルのリストが、タイトルの選択が可能となるように表示される。
【0161】
セキュリティモジュール720は、サーバだけでなく他のボックスとのセキュア通信を実現するため設けられる。一実施例では、指定されたボックスの1つがセグメントを供給するため発注元のボックスからのリクエストを受け付けるとすぐに、発注元のボックスと供給元のボックスとの間のセキュアなセッションが確立される。このため、それらの間で伝送されるすべてのデータはセキュア化される。セキュリティモジュール720はまた、発注されたタイトルの再生のためのデータのDRM及びセキュリティを取り扱うため設けられる。
【0162】
学習エンジン722は、ユーザの視聴行動及び/又はユーザに係るボックスのネットワーク動作から、ユーザに最良のサービスを提供するため設けられる。ユーザがブラウズ、選択又は発注したものから、推薦されるタイトルのリストがユーザに対して自動的に生成されるかもしれない。また視聴行動から、学習エンジン722は、何れのセグメントがローカルにキャッシュされるか決定するようボックスを構成することが可能である。ボックスがある期間オフライである状況では、ボックスがオンラインに戻ると、学習エンジン722はフェッチ対象となるタイトルを優先順位付けすることによって、ライブラリを更新するようボックスを構成することができる。ボックスのネットワーク動作を取得することによって、学習エンジン722は、何れの帯域幅が1日の異なる時間において利用可能であるか知っており、他のボックスにセグメントを供給するボックスの指定又はサーバからのリリースのボックスの提供を実現するかもしれない。
【0163】
登録モジュール724は、新たなユーザがシステムに登録することを可能にする。典型的には、ユーザが良好に登録された後、登録モジュール724は、集中管理のため登録情報をサーバに転送するよう構成される。動作について、登録モジュール724は、ユーザ名やパスワードなどを要求するシステムを保護するためのフロントラインとして機能する。ユーザは、注文が受付可能となる前に、登録モジュール724により認証される必要がある。
【0164】
図7B及び7Cを参照すると、2つの図面は一緒になって、あるセレクション(すなわち、タイトル)の瞬時の再生を開始するためのフローチャート又はプロセス730を示す。当該プロセス730は、ソフトウェア、ハードウェア若しくはその両方の組み合わせによりメソッド、プロセス及び/又はシステムとして実現されるかもしれない。好ましくは、プロセス730は、ここで使用されるようなボックスに対応する計算装置において実行される。図6Gのプロセス686と共に動作することによって、プロセス730は、再生時にはファイルが完全には利用可能でないボックスからの選択されたタイトルに係るファイルの瞬時の再生を可能にする。
【0165】
732において、プロセス730は、ユーザからの選択を待機する。1つのケースでは、ユーザはキー(リモコン、キーボードなどにより)を起動してタイトルの1つを選択可能な複数のタイトルを有するディスプレイを視聴している。プロセス730は、ユーザにより選択がなされると起動する。プロセス730は734に移行し、ユーザ及び/又はボックスが適切に認証されているか判断する。一実施例では、登録されたユーザは、認証のためユーザ名とパスワードを入力するよう要求される。他の実施例では、登録されたユーザは、認証のためコードを入力することを要求される。ユーザを認証する方法は他にもあるかもしれない。何れの場合も、プロセス730は、ユーザ及びボックスが正当なものであることを保証する必要がある。そうでない場合、736において、ユーザがシステムに登録することを推奨するエラーメッセージがユーザに送信される。
【0166】
登録されたユーザが734において認証された後、738において、ボックスはその選択に従ってリクエストを送信する。当該リクエストは、注文及びユーザに関する情報を含む。リクエストは、サービスプロバイダによってサーバに転送される。リクエストを受信すると、サーバは図6Gのプロセス686に移行する。他方、740において、ボックスはサーバからのレスポンスを待機する。レスポンスが所定の時間内(5秒など)に受信されない場合、リクエストが再送信されてもよい。しかしながら、レスポンスがある時間を超えても受信されなかった場合(ネットワークがダウンしているなど)、739において、エラーメッセージが表示される。
【0167】
742において、レスポンスがサーバから受信される。適切な理由のため、レスポンスはユーザがシステムを利用することを制限するかもしれない。ユーザが制限される場合、プロセス730は743に移行し、ユーザにエラーメッセージを表示する。認証されると、プロセス730は744に移行し、選択されたタイトルに係るファイルのヘッダが再生され、表示装置を介し表示されるかもしれない。
【0168】
746において、サーバからのレスポンスに従って、ボックスは欠落しているセグメントに対する各リクエストを他のボックスに行う。上述されるように、当該レスポンスは、ボックスがこれらの欠落しているセグメントをどこからフェッチすることが可能であるか示すソース情報を含む。例えば、あるファイルに対して4つのセグメントが存在し、ボックスはそのうちの2つしかローカルに格納していない場合、2つのセグメントが他のボックスからフェッチされる必要がある。748において、ボックスは、欠落しているセグメントを供給するため要求されるボックスからのレスポンスを待機する。ボックスの1つが当該リクエストに応答することができない場合、バックアップボックスが当該セグメントを供給するため呼び出されるかもしれない。バックアップボックスがまた当該リクエストに応答することができない場合、ボックスは、さらなるバックアップボックスに対するリクエストをサーバに送信する。何れの場合も、指定されたボックスが発注元のボックスからのリクエストに応答した後、750において、発注元のボックスは指定されたボックスと応答したボックスから欠落しているセグメントのフェッチを開始する。
【0169】
上述されるように、欠落しているセグメントは、所定のスピードで到着することが期待される。ある理由により、ネットワークの一部が混雑し、又はボックス自体が不具合であり、フェッチされるセグメントの大きな遅延が生じる場合、プロセス730は754に移行し、バックアップボックスが中断されたセグメントの供給を継続するよう呼び出される。図7Eにおいて、752及び754の詳細がさらに説明される。
【0170】
所定の最小スピードによりすべてのセグメントがストリーミングされる場合、756において、ローカルに格納されているセグメントの一部及びストリーミングされるセグメントの一部が、図7Dに示されるようなバッファに多重化される。バッファ770、好ましくは、図7Aのメモリ708の一部が、ヘッダ772のデータと共にロードされる。図7Dに示されるようにヘッダ772の一部774がバッファ770kぁら再生された。ヘッダ772の残りの部分776はまだ生成される。それと同時、セグメント778及び780のストリーミングがバッファ770に供給されている。セグメント778〜781(ローカルに格納されているセグメントとストリーミングされるセグメントとを含む)が、バッファ770に多重化される。より詳細には、セグメント1からのデータブロック、セグメント2からのデータブロック、セグメント3からのデータブロック及びセグメント4からのデータブロックが、多重化され、バッファ770に連続的に供給される。この結果、データのもとの順序が復元され、当該タイトルに係るファイルの残りの部分が再構成される。
【0171】
図7Cを参照すると、プロセス730は758に移行し、発注されたタイトルに対するファイル全体が再生されるまで、バッファの再構成されたデータの再生を継続する。その後、プロセス730は732に戻り、ユーザからの他の注文を待機する。
【0172】
図7Dを参照すると、2つのポインタ782と784が示される。各ポインタ782と784は、セグメントのデータブロックがバッファ770に供給されており、又は供給されようとしている場所を記憶するのに利用される。ボックスからフェッチされるセグメントが中断され、バックアップボックスが介入する場合、発注元のボックスは、ポインタに従ってそれが中断された場所からセグメントのフェッチを開始すべき正確な場所を知ることができる。同様に、類似したポインタ(図示せず)が、ローカルにキャッシュされたセグメントのデータブロックがバッファ770に供給されている、又は供給されようとする場所を記憶するため設けられてもよい。発注元のボックスがリセットされる必要がある場合、又は突然に電源オフされ、バックオンされる場合、これらのポインタは注文されたタイトルの再生の連続性を実現することを可能にする。
【0173】
ボックスが、ライブラリのすべてのタイトルからの所望のタイトルの検索の実現、ユーザからの注文の実現、1以上のセグメントの他のボックスへの供給、リリースに応答したライブラリの更新、及びそれの状態若しくはネットワーク状態のサーバへの通知などのいくつかのタスクを実行可能であることが説明された。すべてのタスクは等しく重要であるが、一部は他のものより優先されてもよい。
【0174】
図7Eを参照すると、一実施例によるボックスにおけるタスクの優先順位付けを行うフローチャート又はプロセス784が示される。当該プロセス784はシステムをより効率的にするかもしれないことに留意すべきである。インストール持には、ボックスはセグメントを他のボックスに供給又はアップロードすることを要求されない。ボックスは、786において、それの状態をサーバ(図2Aの202など)に定期的に若しくは所定の時間に通知し、それのライブラリへのリリースの更新のため相手のボックスと同期し、又はボックスの全体的なパフォーマンスに影響を与える可能性のある他の処理を実行するよう構成される。サーバへの通知時、ボックスはそれの動作状態を示す状態を送出する。一実施例では、ボックスは公衆ネットワークに接続され、動的なIPアドレスが割り当てられる。ボックスがサーバと他のボックスと通信中であることを保証するため、ボックスは、IPアドレスの変更をサーバに通知するよう構成される。
【0175】
ボックスは、待機モードに入るか、又は786において他の処理を実行する。ボックスが788において1以上のセグメントを発注元のボックスに供給するための候補である可能性がるため、プロセス784は、ボックスが何れかのセグメントを他のボックスに供給するよう要求されたかチェックする。このようなリクエストが受信されていない場合、ボックスは786に戻り、それが実行していたものを実行し続ける。しかしながら、788において発注元のボックスからリクエストを受信すると、プロセス784は790に移行し、ボックスに常駐する多数のセグメントから要求されたセグメントを特定する。792において、ボックスは、アップロード帯域幅が十分なものであるかチェックする。リクエスト時に利用可能なアップロード帯域幅はWであり、セグメントをアップロードするのに要求される帯域幅はRであると仮定される。W>Rである場合、プロセス784は796に移行し、それは存在する場合には、アップロード帯域幅を使用している処理に関係しないことを意味する。W<Rである場合、プロセス784は794に移行し、存在する場合には、アップロード帯域幅を利用している他の何れかの処理が即座に中止される。アップロード帯域幅を利用する処理の具体例として、相手のボックスによって要求されたリリースパッケージのアップロード又は新規ボックスの提供などがあげられる。
【0176】
このような処理が中断された後、プロセス784は796に移行し、要求されたセグメントを発注元のボックスにアップロードする。798において、要求されたセグメントのアップロードが終了したか判断される。終了していない場合、アップロードが継続される。要求されたセグメントがアップロード終了した場合、プロセス784は786に移行し、当該ボックスが実行していたこと又は実行が中断されているものを復元又は継続する。
【0177】
プロセス784は1つのセグメントをアップロードするため説明されることに留意すべきである。当業者は、プロセス784がアップロード帯域幅が許す場合、複数のセグメントのアップロードに適用可能であることを理解するであろう。上位バンドの複数のセグメントが典型的にはボックスに常駐していることが上述された。発注元のボックスへのボックスのアップロード帯域幅が複数のセグメントをアップロードするのに十分であるとき、一実施例では、選択されたタイトルの再生が他のボックスにあまり依存しなくなるように、このようなボックスは複数のセグメントをアップロードするよう指定されるかもしれない。
【0178】
図8は、本発明の多数の特徴が等しく適用されるアーキテクチャ800を示す。アーキテクチャ800は、図2Aのアーキテクチャのすべての機能を含むかもしれない。図2Aのアーキテクチャのエンハンスメントとして、アーキテクチャ800は、すべての分散オブジェクトを格納するサーバデータベースを有する。分散オブジェクトを格納することによって、サーバは、バックアップボックスの故障時、初期的なバックアップボックスとして、帯域幅が利用可能なときは発注元のボックスをサポートするかもしれない。
【0179】
発注元のボックスによるタイトルに対するリクエストに応答して、サーバは発注元のボックスに直接的に応答する必要がないことが理解されるべきである。サーバ202は、分散オブジェクトを発注元のボックスに提供する命令を分散したボックスに提供することによって応答してもよい。サーバ202は、分散したボックスに自らのサービスを自発的に申し出るよう要求することによって応答してもよい。サーバによる他の多くのレスポンスがまた可能である。発注元のボックスによるリクエストがサーバに送られる必要がないことがさらに理解されるべきである。例えば、ボックスにはネットワーク構成マップが与えられ、これにより、ボックスは他のボックスに直接リクエストすることが可能となり、再生リクエストのためのサーバ帯域幅の利用を回避することができる。
【0180】
当業者は、システムの各要素がソフトウェアにより実現されてもよいが、ハードウェア又はハードウェアとソフトウェアとの組み合わせにより実現可能であることを認識するであろう。本発明はまた、コンピュータ可読媒体上のコンピュータ可読コードとして実現可能である。コンピュータ可読媒体は、以降においてコンピュータシステムにより読み取り可能なデータを格納することが可能な任意のデータストレージ装置とすることが可能である。コンピュータ可読媒体の具体例として、以下に限定するものではないが、ROM(Read−Only Memory)、RAM(Random−Access Memory)、CD−ROM、DVD、磁気テープ、ハードディスク、光データストレージ装置又は搬送波を含むかもしれない。コンピュータ可読媒体はまた、コンピュータ可読コードが格納され、分散形式により実行されるように、ネットワークに接続されたコンピュータシステムに分散化することも可能である。
【0181】
本発明の可能な効果は多数ある。異なる実施例又は実現形態は、以下の特徴及び効果の1以上をもたらすかもしれない。それらの1つは、メディア・オン・デマンドシステムにおける瞬時の特徴である。ローカルにキャッシュされたタイトルに係るファイルの小さな部分によって、ファイルの残りの部分が1以上のボックスにセグメントにより分散される。あるタイトルが発注されると、ユーザが認証され、支払が適切に決済されている場合、ローカルにキャッシュされた部分が即座に再生され、このローカルにキャッシュされた部分の再生中に、残りの部分がタイトルの再生を継続させるためにストリームとしてボックスからフェッチされる。それらのうちの他の1つは、ファイルの細分化方法である。タイトルに係るファイルが与えられると、ファイルはヘッダと複数のセグメントに細分化される。ヘッダはファイルの連続的な部分であり、各セグメントは、ファイルの残りの部分の間引きされた部分である。セグメントがフェッチされているとき、セグメントは再生のためもとのデータの順序を復元するため多重化される。さらなる他の可能な特徴及び効果は、ボックスが他のボックスにサービスを提供することを禁止することなく、ボックスのライブラリを同期的に又は非同期的に更新するための基礎となるメカニズムである。リリースが利用可能になると、ローカルにキャッシュされるべきリリースパッケージが、中央サーバから送信される代わりに、他のボックスから当該ボックスに非同期的に伝搬される。他の特徴及び効果もまた可能である。
【0182】
上記実施例の説明は、本発明の各種特徴/実施例の例示である。添付された請求項によって規定されるような本発明の真の趣旨及び範囲から逸脱することなく、本発明に対する様々な変更が当業者により好適な実施例に対して可能である。例えば、一実施例では、ファイルのヘッダのサイズはゼロまで減少してもよく、すなわち、ファイルはボックスに分散可能な複数のセグメントに細分化される。また、タイトルが発注されると、サーバは、当該注文のためのデータを供給するソースを特定し、その後、発注元のボックスがソースとの通信を開始することを要求する代わりに、これらの供給元自体にデータ転送を開始するよう接続する。実際、発注元のボックスは、サーバが供給元のボックスを特定することを要求する代わりに、タイトルの各セグメントをキャッシュするボックスからソース情報を動的に取得することも可能である。従って、本発明の範囲は、上記実施例の説明でなく添付した請求項によって規定される。
【図面の簡単な説明】
【0183】
【図1】図1は、サーバ・アンド・クライアントアーキテクチャとも呼ばれるネットワークを介しビデオサービスを配信するのに通常利用されるビデオ配信システムを示す。
【図2A】図2Aは、本発明の実施例による分散ネットワークシステムを示す。
【図2B】図2Bは、一実施例によるヘッダと4つのセグメントに細分化又は構成されたファイルを示す。
【図2C】図2Cは、タイトルの再生を継続するため、ボックスがローカルにヘッダを格納し、他の4つのボックスから4つのセグメントを受信する状況を仮定する場合に、1つのヘッダと4つのセグメントを有するタイトルに係るファイルを示す。
【図2D】図2Dは、ヘッダとして割り当てられた始めの部分と、4つのセグメントに間引きされる残りの部分とによるファイルを表すデータストリームを示す。
【図2E】図2Eは、一実施例による複数のボックスに分散させるためファイルを細分化するフローチャート又はプロセスを示す。
【図3A】図3Aは、ボックスの限られた格納スペース内のライブラリのタイトルの一例となる人気による分類を示す。
【図3B】図3Bは、ボックスの限られた格納スペース内のライブラリのタイトルの他の例となる人気による分類を示す。
【図3C】図3Cは、ライブラリのタイトルの人気に従う一例となるバンド化方式を示す。
【図3D】図3Dは、図3Cに示されるバンド化に従う連続再生のためのバンドの各タイトルの対応する依存性を示す。
【図3E】図3Eは、一実施例による瞬時のアクセスのための多数のタイトルのライブラリを分類するフローチャート又はプロセスを示す。
【図3F】図3Fは、一実施例によるボックスのライブラリを更新するフローチャート又はプロセスを示す。
【図4A】図4Aは、一実施例によるサービス提供中のすべてのボックスのライブラリを同期的に又は非同期的に更新する図を示す。
【図4B】図4Bは、一実施例によるサービス提供中のボックスにおいてリリースを提供するフローチャート又はプロセスを示す。
【図4C】図4Cは、サービスプロバイダに高帯域幅ブロードキャスト機能のインフラストラクチャが設けられた一例となる状況を示す。
【図4D】図4Dは、ブロードキャスト若しくはマルチキャストのための帯域幅が十分な構成の対するサービス提供中のボックスにおいてリリースを提供する一例となるフローチャート又はプロセスを示す。
【図5A】図5Aは、一実施例による新規ボックスのライブラリに対する段階的な変更を示す。
【図5B】図5Bは、3つの新規ボックスがシステムに追加される一例となる状況を示す。
【図5C】図5Cは、ある期間オンラインでなく、このため古いライブラリを有することとなったボックスのライブラリを更新するフローチャート又はプロセスを示す。
【図6A】図6Aは、本発明によるサーバの一実現形態を示す。
【図6B】図6Bは、5000タイトルのライブラリがN個のボックスにどのように分散されるか示す一例となるマップを示す。
【図6C】図6Cは、発注されたタイトルのセグメントを供給するよう指定された4つのボックスのそれぞれに対するIPアドレス(IPA1など)を含むテーブルとして一例となるソース情報を示す。
【図6D】図6Dは、指定された各ボックスのバックアップ識別子(IPアドレスとして示される)を有するテーブルのバックアップボックスによる一例となるソース情報を示す。
【図6E】図6Eは、指定された3つのボックスが他の3つのボックスによりそれぞれバックアップされ、発注元のタイトルに係る3つのセグメントがそれぞれ発注元のボックスに提供される3つの指定されたボックスにより発注元のボックスがサポートされている一実施例を示す。
【図6F】図6Fは、指定された3つのボックスが他の発注元のボックスをサポートする他の指定されたボックスを同時にバックアップする他の3つのボックスによってそれぞれバックアップされる発注元のボックスが3つの指定されたボックスによりサポートされている他の実施例を示す。
【図6G】図6Gは、ライブラリのセレクション(すなわち、タイトル)の瞬時の再生を開始するフローチャート又はプロセスを示す。
【図7A】図7Aは、図2Aの何れのボックスに対応するボックスの一実現形態を示す。
【図7B】図7Bは、本発明の一実施例によるセレクション(すなわち、タイトル)の瞬時の再生を開始するフローチャート又はプロセスを示す。
【図7C】図7Cは、本発明の一実施例によるセレクション(すなわち、タイトル)の瞬時の再生を開始するフローチャート又はプロセスを示す。
【図7D】図7Dは、本発明の一実施例による再生されている第1部分が終了するとすぐに、再生用のデータストリームを生成するため4つのセグメントのストリームの多重化を示す。
【図7E】図7Eは、本発明の一実施例によるボックスにおけるタスクを優先順位付けするフローチャート又はプロセスを示す。
【図8】図8は、本発明の多くの特徴が等しく適用されるアーキテクチャを示す。
【特許請求の範囲】
【請求項1】
ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、
発注元のボックスからライブラリのタイトルの注文を含むリクエストを受信するステップと、
前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する1以上のボックスを特定するステップと、
を有し、
前記発注元のボックスは、前記1以上のボックスから前記タイトルに係る分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生することによって前記タイトルの再生を進行し、
前記常駐オブジェクトのデータブロックは連続的なものであり、前記分散オブジェクトのデータブロックは不連続なものであり、前記タイトルの再生をサポートするため多重化されて同時に受信される必要がある方法。
【請求項2】
前記リクエストを受信すると、前記注文が認証されているか検証するステップと、
前記注文の認証後、ある方式に従って前記分散オブジェクトを前記発注元のボックスに供給するよう指定された1以上のボックスを決定するステップと、
をさらに有する、請求項1記載の方法。
【請求項3】
前記方式は、前記1以上のボックスの選択が前記1以上のボックスから前記発注元のボックスへの前記分散オブジェクトの少なくとも一部の各自のダウンロードを保証するように、前記1以上のボックスの地理的位置、時間帯及び作業状態の1以上に基づく、請求項2記載の方法。
【請求項4】
前記1以上のボックスの少なくとも1つが前記分散オブジェクトの1つを十分に供給できない場合、前記少なくとも1つのボックスをサポートするよう各バックアップボックスが指定されるバックアップボックス群を特定するステップをさらに有する、請求項1乃至3何れか一項記載の方法。
【請求項5】
前記発注元のボックスと前記1以上のボックスとの間のセキュアな通信を実現するため、認証情報を提供するステップをさらに有する、請求項1乃至3何れか一項記載の方法。
【請求項6】
前記認証情報はさらに、前記常駐オブジェクトと前記分散オブジェクトをそれぞれ解読するためセキュリティ情報を有する、請求項5記載の方法。
【請求項7】
前記タイトルに係るファイルは、前記常駐オブジェクトと前記分散オブジェクトとを有し、
前記常駐オブジェクトはヘッダであり、
前記分散オブジェクトのそれぞれは、前記ファイルの残りの各間引きされた部分である、請求項1乃至3何れか一項記載の方法。
【請求項8】
前記分散オブジェクトは、前記1以上のボックスから前記発注元のボックスに同時にフェッチされる、請求項7記載の方法。
【請求項9】
前記1以上のボックスから同時にフェッチされる前記分散オブジェクトからのデータは、前記ファイルの残りの部分を復元し、前記タイトルの再生を継続するため、存在する場合には、前記常駐オブジェクトからのデータと多重化される、請求項7記載の方法。
【請求項10】
前記常駐オブジェクトの長さは、前記常駐オブジェクトの再生が前記タイトル全体の連続的な再生を保証し、可能性のある何れの不安定性も解消するのに十分な長さとなるように決定される、請求項7記載の方法。
【請求項11】
前記分散オブジェクトの何れも、再生順序を実現するようサーバにより提供されない、請求項1乃至3何れか一項記載の方法。
【請求項12】
前記ボックスのライブラリは、ユーザによる選択及び即座の再生のため利用可能な個数のタイトルを有し、
各ボックスは、前記タイトルのそれぞれの完全なファイル未満しか格納しない、請求項1乃至3何れか一項記載の方法。
【請求項13】
1以上のタイトルのヘッダと複数のセグメントとを表すデータチャンクのシーケンスにリリースを変換するステップと、
前記ボックスの一部に前記データチャンクの一部を他のボックスに再帰的に伝搬させることによって、前記データチャンクをすべてのボックスに同期的に又は非同期的に拡散するステップと、
をさらに有する、請求項1乃至3何れか一項記載の方法。
【請求項14】
ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、
ボックスのタイトルのライブラリからタイトルの選択を可能にするステップと、
前記タイトルの1つが選択されると、タイトル情報を含むリクエストを生成するステップと、
前記発注されたタイトルに係る1以上の分散オブジェクトを提供する1以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するステップと、
前記発注されたタイトルに係る前記ボックス内の常駐オブジェクトの再生を開始するステップと、
前記常駐オブジェクトの再生中に一部が受信される1以上のデータストリームとして、前記1以上のボックスから前記1以上の分散オブジェクトを受信するステップと、
前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記1以上のデータストリームの再生を開始するステップと、
を有する方法。
【請求項15】
前記リクエスト生成前に、ユーザが前記発注されたタイトルの処理を進行するため認証されているかローカルに判断するステップと、
ユーザが前記発注されたタイトルの再生の処理を進行することが許可されたかリモートに判断するステップと、
をさらに有する、請求項14記載の方法。
【請求項16】
前記常駐オブジェクトと前記分散オブジェクトとをそれぞれ解読するステップをさらに有する、請求項15記載の方法。
【請求項17】
前記サーバからのソース情報に従って、前記1以上のボックスに各リクエストを発信するステップと、
前記1以上のボックスのそれぞれが前記リクエストに応答する場合、前記1以上のボックスから前記分散オブジェクトを同時に受信するステップと、
をさらに有する、請求項14又は15記載の方法。
【請求項18】
前記分散オブジェクトを同時に受信するステップは、
前記分散オブジェクトのそれぞれに対してダウンロードスピードを調べるステップと、
前記分散オブジェクトの1つが所望のスピードにより到着できない場合、バックアップボックスにスイッチするステップと、
を有する、請求項17記載の方法。
【請求項19】
前記1以上のボックスのそれぞれが利用可能である場合、前記1以上のボックスから前記分散オブジェクトを同時に受信するステップをさらに有する、請求項14又は15記載の方法。
【請求項20】
前記分散オブジェクトを同時に受信するステップは、
前記分散オブジェクトのそれぞれに対してダウンロードスピードを調べるステップと、
前記分散オブジェクトの1つが所望のスピードにより到着できない場合、バックアップボックスにスイッチするステップと、
を有する、請求項19記載の方法。
【請求項21】
前記分散オブジェクトの何れも、再生のため前記サーバにより提供されない、請求項14又は15記載の方法。
【請求項22】
前記ボックスのライブラリは、選択及び即座の再生のため利用可能な個数のタイトルを有し、
各ボックスは、前記タイトルのそれぞれの完全なファイル未満しか格納しない、請求項14又は15記載の方法。
【請求項23】
前記ライブラリを更新するため、リリースに関する命令を受信するステップと、
前記命令に従って、前記リリースに係る複数のデータチャンクをサービスを提供する1以上のボックスから受信しようとするステップと、
前記リリースの一部を表し、前記リリースの各タイトルのヘッダを少なくとも有するリリースパッケージを前記データチャンクから復元するステップと、
をさらに有する、請求項22記載の方法。
【請求項24】
前記受信したデータチャンクの少なくとも一部を他のボックス群に伝搬するステップをさらに有する、請求項23記載の方法。
【請求項25】
前記リリースパッケージにおいて利用可能なタイトルは、前記ライブラリに追加され、選択可能とされる、請求項24記載の方法。
【請求項26】
ネットワークを介しメディア・オン・デマンドサービスを提供するシステムであって、
各ボックスがネットワークに接続され、ユーザに関連付けされ、タイトルのライブラリを提供し、複数のヘッダと複数のセグメントが常駐することを可能にする格納スペースを有し、タイトル選択情報を有するリクエストを提供するよう構成される複数のボックスと、
前記ネットワークに接続され、前記ボックスの1つである発注元のボックスからのリクエストに対するレスポンスを提供するよう構成されるサーバと、
を有し、
前記レスポンスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう構成されるボックス群を特定するソース情報を含み、
前記レスポンスに応答して、前記発注元のボックスは、前記ボックス群から1以上の分散セグメントをダウンロードしながら、前記選択されたタイトルに係るヘッダの再生を開始するシステム。
【請求項27】
前記サーバは、前記選択に応答して、前記選択されたタイトルに係る完全なファイル又は前記分散セグメントの何れかを提供しないよう構成される、請求項26記載のシステム。
【請求項28】
前記レスポンスは、バックアップボックス群を特定する識別子を有し、
各バックアップボックスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう指定される前記ボックスの少なくとも1つをバックアップする、請求項26記載のシステム。
【請求項29】
前記レスポンスは、前記発注元のボックスと前記ボックス群との間のセキュアな通信を実現するための認証情報をさらに有する、請求項28記載のシステム。
【請求項30】
前記ソース情報はさらに、前記注文されたタイトルに係るすべてのデータを解読するためのセキュリティ情報を有する、請求項29記載のシステム。
【請求項31】
前記ソース情報のボックス群は、前記ボックス群の選択が前記ボックス群から前記発注元のボックスへの前記分散セグメントの各ダウンロードを保証するように、前記ボックス群の各地理的位置、時間帯及び作業状態の1以上に基づき選択される、請求項26又は27記載のシステム。
【請求項32】
前記サーバは、前記ボックスのそれぞれのライブラリを更新するため、リリースを表すデータチャンクシーケンスを受信する提供ボックス群を割り当てるよう構成され、
前記提供ボックスのそれぞれは、受信したデータチャンクの一部が提供されている間、受信したデータチャンクのコピーの少なくとも一部を前記ボックスの1以上に伝搬するよう構成され、
前記1以上のボックスはそれぞれ、前記データチャンクの一部を受信完了するまで、受信したデータチャンクのコピーの少なくとも一部を他のボックスに連続的に伝搬するよう構成される、請求項26又は27記載のシステム。
【請求項33】
ネットワークを介しメディア・オン・デマンドサービスを提供する計算装置において実行可能なソフトウェアプロダクトであって、
ライブラリのタイトルの注文を含むリクエストを発注元のボックスから受信するためのプログラムコードと、
前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する1以上のボックスを特定するためのプログラムコードと、
を有し、
前記発注元のボックスは、前記1以上のボックスから前記分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生を進行するソフトウェアプロダクト。
【請求項34】
前記リクエストを受信すると、前記注文が認証されているか検証するためのプログラムコードと、
前記注文の認証後、ある方式に従って前記分散オブジェクトを前記発注元のボックスに供給するよう指定された1以上のボックスを決定するためのプログラムコードと、
さらに有する、請求項33記載のソフトウェアプロダクト。
【請求項35】
バックアップボックス群を特定するためのプログラムコードをさらに有し、
各バックアップボックスは、前記1以上のボックスの1つが前記分散オブジェクトの1つの十分に供給することができない場合、前記1以上のボックスの1つをサポートするため指定される、請求項34記載のソフトウェアプロダクト。
【請求項36】
ネットワークを介しメディア・オン・デマンドサービスを提供する計算装置において実行可能なソフトウェアプロダクトであって、
タイトルのライブラリにおけるタイトルの選択を可能にするためのプログラムコードと、
前記タイトルの1つが選択されると、タイトル情報を含むリクエストを生成するためのプログラムコードと、
前記発注されたタイトルに係る1以上の分散オブジェクトを提供する1以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するためのプログラムコードと、
前記発注されたタイトルに係る常駐オブジェクトの再生を開始するためのプログラムコードと、
前記常駐オブジェクトの再生中に一部が受信される1以上のデータストリームとして、前記1以上のボックスから前記1以上の分散オブジェクトを受信するためのプログラムコードと、
前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記1以上のデータストリームの再生を開始するためのプログラムコードと、
を有するソフトウェアプロダクト。
【請求項37】
前記リクエスト生成前に、ユーザが前記発注されたタイトルの処理を進行するため認証されているかローカルに判断するためのプログラムコードと、
ユーザが前記発注されたタイトルの再生の処理を進行することが許可されたかリモートに判断するためのプログラムコードと、
をさらに有する、請求項36記載のソフトウェアプロダクト。
【請求項38】
前記常駐オブジェクトと前記分散オブジェクトとをそれぞれ解読するためのプログラムコードをさらに有する、請求項37記載のソフトウェアプロダクト。
【請求項39】
前記サーバからのソース情報に従って、前記1以上のボックスに各リクエストを発信するためのプログラムコードと、
前記1以上のボックスのそれぞれが前記リクエストに応答する場合、前記1以上のボックスから前記分散オブジェクトを同時に受信するためのプログラムコードと、
をさらに有する、請求項36記載のソフトウェアプロダクト。
【請求項40】
前記ボックスのライブラリは、選択及び即座の再生のため利用可能な個数のタイトルを有し、
各ボックスは、前記タイトルのそれぞれの完全なファイル未満しか格納しない、請求項36記載の方法。
【請求項1】
ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、
発注元のボックスからライブラリのタイトルの注文を含むリクエストを受信するステップと、
前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する1以上のボックスを特定するステップと、
を有し、
前記発注元のボックスは、前記1以上のボックスから前記タイトルに係る分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生することによって前記タイトルの再生を進行し、
前記常駐オブジェクトのデータブロックは連続的なものであり、前記分散オブジェクトのデータブロックは不連続なものであり、前記タイトルの再生をサポートするため多重化されて同時に受信される必要がある方法。
【請求項2】
前記リクエストを受信すると、前記注文が認証されているか検証するステップと、
前記注文の認証後、ある方式に従って前記分散オブジェクトを前記発注元のボックスに供給するよう指定された1以上のボックスを決定するステップと、
をさらに有する、請求項1記載の方法。
【請求項3】
前記方式は、前記1以上のボックスの選択が前記1以上のボックスから前記発注元のボックスへの前記分散オブジェクトの少なくとも一部の各自のダウンロードを保証するように、前記1以上のボックスの地理的位置、時間帯及び作業状態の1以上に基づく、請求項2記載の方法。
【請求項4】
前記1以上のボックスの少なくとも1つが前記分散オブジェクトの1つを十分に供給できない場合、前記少なくとも1つのボックスをサポートするよう各バックアップボックスが指定されるバックアップボックス群を特定するステップをさらに有する、請求項1乃至3何れか一項記載の方法。
【請求項5】
前記発注元のボックスと前記1以上のボックスとの間のセキュアな通信を実現するため、認証情報を提供するステップをさらに有する、請求項1乃至3何れか一項記載の方法。
【請求項6】
前記認証情報はさらに、前記常駐オブジェクトと前記分散オブジェクトをそれぞれ解読するためセキュリティ情報を有する、請求項5記載の方法。
【請求項7】
前記タイトルに係るファイルは、前記常駐オブジェクトと前記分散オブジェクトとを有し、
前記常駐オブジェクトはヘッダであり、
前記分散オブジェクトのそれぞれは、前記ファイルの残りの各間引きされた部分である、請求項1乃至3何れか一項記載の方法。
【請求項8】
前記分散オブジェクトは、前記1以上のボックスから前記発注元のボックスに同時にフェッチされる、請求項7記載の方法。
【請求項9】
前記1以上のボックスから同時にフェッチされる前記分散オブジェクトからのデータは、前記ファイルの残りの部分を復元し、前記タイトルの再生を継続するため、存在する場合には、前記常駐オブジェクトからのデータと多重化される、請求項7記載の方法。
【請求項10】
前記常駐オブジェクトの長さは、前記常駐オブジェクトの再生が前記タイトル全体の連続的な再生を保証し、可能性のある何れの不安定性も解消するのに十分な長さとなるように決定される、請求項7記載の方法。
【請求項11】
前記分散オブジェクトの何れも、再生順序を実現するようサーバにより提供されない、請求項1乃至3何れか一項記載の方法。
【請求項12】
前記ボックスのライブラリは、ユーザによる選択及び即座の再生のため利用可能な個数のタイトルを有し、
各ボックスは、前記タイトルのそれぞれの完全なファイル未満しか格納しない、請求項1乃至3何れか一項記載の方法。
【請求項13】
1以上のタイトルのヘッダと複数のセグメントとを表すデータチャンクのシーケンスにリリースを変換するステップと、
前記ボックスの一部に前記データチャンクの一部を他のボックスに再帰的に伝搬させることによって、前記データチャンクをすべてのボックスに同期的に又は非同期的に拡散するステップと、
をさらに有する、請求項1乃至3何れか一項記載の方法。
【請求項14】
ネットワークを介しメディア・オン・デマンドサービスを提供する方法であって、
ボックスのタイトルのライブラリからタイトルの選択を可能にするステップと、
前記タイトルの1つが選択されると、タイトル情報を含むリクエストを生成するステップと、
前記発注されたタイトルに係る1以上の分散オブジェクトを提供する1以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するステップと、
前記発注されたタイトルに係る前記ボックス内の常駐オブジェクトの再生を開始するステップと、
前記常駐オブジェクトの再生中に一部が受信される1以上のデータストリームとして、前記1以上のボックスから前記1以上の分散オブジェクトを受信するステップと、
前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記1以上のデータストリームの再生を開始するステップと、
を有する方法。
【請求項15】
前記リクエスト生成前に、ユーザが前記発注されたタイトルの処理を進行するため認証されているかローカルに判断するステップと、
ユーザが前記発注されたタイトルの再生の処理を進行することが許可されたかリモートに判断するステップと、
をさらに有する、請求項14記載の方法。
【請求項16】
前記常駐オブジェクトと前記分散オブジェクトとをそれぞれ解読するステップをさらに有する、請求項15記載の方法。
【請求項17】
前記サーバからのソース情報に従って、前記1以上のボックスに各リクエストを発信するステップと、
前記1以上のボックスのそれぞれが前記リクエストに応答する場合、前記1以上のボックスから前記分散オブジェクトを同時に受信するステップと、
をさらに有する、請求項14又は15記載の方法。
【請求項18】
前記分散オブジェクトを同時に受信するステップは、
前記分散オブジェクトのそれぞれに対してダウンロードスピードを調べるステップと、
前記分散オブジェクトの1つが所望のスピードにより到着できない場合、バックアップボックスにスイッチするステップと、
を有する、請求項17記載の方法。
【請求項19】
前記1以上のボックスのそれぞれが利用可能である場合、前記1以上のボックスから前記分散オブジェクトを同時に受信するステップをさらに有する、請求項14又は15記載の方法。
【請求項20】
前記分散オブジェクトを同時に受信するステップは、
前記分散オブジェクトのそれぞれに対してダウンロードスピードを調べるステップと、
前記分散オブジェクトの1つが所望のスピードにより到着できない場合、バックアップボックスにスイッチするステップと、
を有する、請求項19記載の方法。
【請求項21】
前記分散オブジェクトの何れも、再生のため前記サーバにより提供されない、請求項14又は15記載の方法。
【請求項22】
前記ボックスのライブラリは、選択及び即座の再生のため利用可能な個数のタイトルを有し、
各ボックスは、前記タイトルのそれぞれの完全なファイル未満しか格納しない、請求項14又は15記載の方法。
【請求項23】
前記ライブラリを更新するため、リリースに関する命令を受信するステップと、
前記命令に従って、前記リリースに係る複数のデータチャンクをサービスを提供する1以上のボックスから受信しようとするステップと、
前記リリースの一部を表し、前記リリースの各タイトルのヘッダを少なくとも有するリリースパッケージを前記データチャンクから復元するステップと、
をさらに有する、請求項22記載の方法。
【請求項24】
前記受信したデータチャンクの少なくとも一部を他のボックス群に伝搬するステップをさらに有する、請求項23記載の方法。
【請求項25】
前記リリースパッケージにおいて利用可能なタイトルは、前記ライブラリに追加され、選択可能とされる、請求項24記載の方法。
【請求項26】
ネットワークを介しメディア・オン・デマンドサービスを提供するシステムであって、
各ボックスがネットワークに接続され、ユーザに関連付けされ、タイトルのライブラリを提供し、複数のヘッダと複数のセグメントが常駐することを可能にする格納スペースを有し、タイトル選択情報を有するリクエストを提供するよう構成される複数のボックスと、
前記ネットワークに接続され、前記ボックスの1つである発注元のボックスからのリクエストに対するレスポンスを提供するよう構成されるサーバと、
を有し、
前記レスポンスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう構成されるボックス群を特定するソース情報を含み、
前記レスポンスに応答して、前記発注元のボックスは、前記ボックス群から1以上の分散セグメントをダウンロードしながら、前記選択されたタイトルに係るヘッダの再生を開始するシステム。
【請求項27】
前記サーバは、前記選択に応答して、前記選択されたタイトルに係る完全なファイル又は前記分散セグメントの何れかを提供しないよう構成される、請求項26記載のシステム。
【請求項28】
前記レスポンスは、バックアップボックス群を特定する識別子を有し、
各バックアップボックスは、前記タイトルに係る各分散セグメントを前記発注元のボックスに提供するよう指定される前記ボックスの少なくとも1つをバックアップする、請求項26記載のシステム。
【請求項29】
前記レスポンスは、前記発注元のボックスと前記ボックス群との間のセキュアな通信を実現するための認証情報をさらに有する、請求項28記載のシステム。
【請求項30】
前記ソース情報はさらに、前記注文されたタイトルに係るすべてのデータを解読するためのセキュリティ情報を有する、請求項29記載のシステム。
【請求項31】
前記ソース情報のボックス群は、前記ボックス群の選択が前記ボックス群から前記発注元のボックスへの前記分散セグメントの各ダウンロードを保証するように、前記ボックス群の各地理的位置、時間帯及び作業状態の1以上に基づき選択される、請求項26又は27記載のシステム。
【請求項32】
前記サーバは、前記ボックスのそれぞれのライブラリを更新するため、リリースを表すデータチャンクシーケンスを受信する提供ボックス群を割り当てるよう構成され、
前記提供ボックスのそれぞれは、受信したデータチャンクの一部が提供されている間、受信したデータチャンクのコピーの少なくとも一部を前記ボックスの1以上に伝搬するよう構成され、
前記1以上のボックスはそれぞれ、前記データチャンクの一部を受信完了するまで、受信したデータチャンクのコピーの少なくとも一部を他のボックスに連続的に伝搬するよう構成される、請求項26又は27記載のシステム。
【請求項33】
ネットワークを介しメディア・オン・デマンドサービスを提供する計算装置において実行可能なソフトウェアプロダクトであって、
ライブラリのタイトルの注文を含むリクエストを発注元のボックスから受信するためのプログラムコードと、
前記タイトルに係る分散オブジェクトを前記発注元のボックスに提供する1以上のボックスを特定するためのプログラムコードと、
を有し、
前記発注元のボックスは、前記1以上のボックスから前記分散オブジェクトをダウンロードしながら、前記タイトルに係る常駐オブジェクトを再生を進行するソフトウェアプロダクト。
【請求項34】
前記リクエストを受信すると、前記注文が認証されているか検証するためのプログラムコードと、
前記注文の認証後、ある方式に従って前記分散オブジェクトを前記発注元のボックスに供給するよう指定された1以上のボックスを決定するためのプログラムコードと、
さらに有する、請求項33記載のソフトウェアプロダクト。
【請求項35】
バックアップボックス群を特定するためのプログラムコードをさらに有し、
各バックアップボックスは、前記1以上のボックスの1つが前記分散オブジェクトの1つの十分に供給することができない場合、前記1以上のボックスの1つをサポートするため指定される、請求項34記載のソフトウェアプロダクト。
【請求項36】
ネットワークを介しメディア・オン・デマンドサービスを提供する計算装置において実行可能なソフトウェアプロダクトであって、
タイトルのライブラリにおけるタイトルの選択を可能にするためのプログラムコードと、
前記タイトルの1つが選択されると、タイトル情報を含むリクエストを生成するためのプログラムコードと、
前記発注されたタイトルに係る1以上の分散オブジェクトを提供する1以上のボックスを特定するソース情報を含むレスポンスを形成するよう構成されるサーバにネットワークを介し前記リクエストを送信するためのプログラムコードと、
前記発注されたタイトルに係る常駐オブジェクトの再生を開始するためのプログラムコードと、
前記常駐オブジェクトの再生中に一部が受信される1以上のデータストリームとして、前記1以上のボックスから前記1以上の分散オブジェクトを受信するためのプログラムコードと、
前記常駐オブジェクトの再生が終了するとすぐに、存在する場合には、前記発注されたタイトルに係る常駐オブジェクトと共に前記1以上のデータストリームの再生を開始するためのプログラムコードと、
を有するソフトウェアプロダクト。
【請求項37】
前記リクエスト生成前に、ユーザが前記発注されたタイトルの処理を進行するため認証されているかローカルに判断するためのプログラムコードと、
ユーザが前記発注されたタイトルの再生の処理を進行することが許可されたかリモートに判断するためのプログラムコードと、
をさらに有する、請求項36記載のソフトウェアプロダクト。
【請求項38】
前記常駐オブジェクトと前記分散オブジェクトとをそれぞれ解読するためのプログラムコードをさらに有する、請求項37記載のソフトウェアプロダクト。
【請求項39】
前記サーバからのソース情報に従って、前記1以上のボックスに各リクエストを発信するためのプログラムコードと、
前記1以上のボックスのそれぞれが前記リクエストに応答する場合、前記1以上のボックスから前記分散オブジェクトを同時に受信するためのプログラムコードと、
をさらに有する、請求項36記載のソフトウェアプロダクト。
【請求項40】
前記ボックスのライブラリは、選択及び即座の再生のため利用可能な個数のタイトルを有し、
各ボックスは、前記タイトルのそれぞれの完全なファイル未満しか格納しない、請求項36記載の方法。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図3A】
【図3B】
【図3C】
【図3D】
【図3E】
【図3F】
【図4A】
【図4B】
【図4C】
【図4D】
【図5A】
【図5B】
【図5C】
【図6A】
【図6B】
【図6C】
【図6D】
【図6E】
【図6F】
【図6G】
【図7A】
【図7B】
【図7C】
【図7D】
【図7E】
【図8】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図3A】
【図3B】
【図3C】
【図3D】
【図3E】
【図3F】
【図4A】
【図4B】
【図4C】
【図4D】
【図5A】
【図5B】
【図5C】
【図6A】
【図6B】
【図6C】
【図6D】
【図6E】
【図6F】
【図6G】
【図7A】
【図7B】
【図7C】
【図7D】
【図7E】
【図8】
【公開番号】特開2009−33760(P2009−33760A)
【公開日】平成21年2月12日(2009.2.12)
【国際特許分類】
【出願番号】特願2008−225947(P2008−225947)
【出願日】平成20年9月3日(2008.9.3)
【分割の表示】特願2008−500752(P2008−500752)の分割
【原出願日】平成18年2月27日(2006.2.27)
【出願人】(507303103)ヴドゥ,インコーポレイテッド (2)
【Fターム(参考)】
【公開日】平成21年2月12日(2009.2.12)
【国際特許分類】
【出願日】平成20年9月3日(2008.9.3)
【分割の表示】特願2008−500752(P2008−500752)の分割
【原出願日】平成18年2月27日(2006.2.27)
【出願人】(507303103)ヴドゥ,インコーポレイテッド (2)
【Fターム(参考)】
[ Back to top ]