(57)【要約】メタデータイネーブル型プッシュ−プルモデルのための方法、システム、コンピュータプログラム及びコンピュータプログラム製品、並びにネットワークを経て効率的に低レイテンシでビデオコンテンツを配給するための方法。メタデータは、コンテンツディストリビューションシステムのオペレーションにおいてインテリジェントな判断を行えるようにするためのビヒクル及びメカニズムとして使用される。メタデータは、実際のコンテンツに関する情報を含むデータであり、ある場合には、メタデータは、コンテンツの一部分又はコンテンツの低分解能プレビューも含む。本発明の態様は、効率的なシステムオペレーションを容易にすると共に、追跡、報告、パーソナル化等々の１組のサービスを任意であるが効果的に提供するというやり方で、ネットワーク全体にわたりメタデータを配給することに向けられる。
2004533738.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの要求に応答してネットワーク通信リンクを経てユーザにコンテンツオブジェクトを配給するためのメタデータイネーブル型エッジサーバーであって、
コンピュータプログラム命令を実行するためのプロセッサ及び該プロセッサに接続されたメモリと、外部エンティティから通信を受信し及びそれを送信するための少なくとも１つの入力／出力ポートとを有するサーバーコンピュータと、
上記サーバーに接続された記憶装置であって、上記サーバーにアクセスできるコンテンツオブジェクトを記述し、上記コンテンツオブジェクトの特定の１つが記憶されて上記ユーザへ向けられ得るところの少なくとも１つの位置を含むメタデータを記憶する記憶装置と、
上記メタデータを使用して上記ユーザへ上記コンテンツオブジェクトを配給し、そして上記ネットワークを経て上記コンテンツの一部分のアイソクロノス配送を維持するためのコントローラと、
を備えたメタデータイネーブル型エッジサーバー。
【請求項２】
上記コントローラは、上記メタデータイネーブル型エッジサーバーにおいてソフトウェアとして実行される要求応答及び再生手順を含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項３】
上記ネットワークは、インターネットを含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項４】
上記ネットワーク通信リンクは、上記サーバーから上記要求を発しているユーザへ通信するために複数のパケットに分離されたコンテンツアイテムのアイソクロノス配送を維持するための手段をそれ自身もたないパケット交換通信リンクを含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項５】
上記コンテンツアイテムは、上記サーバーコンピュータへ内部からアクセスできる請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項６】
上記コンテンツアイテムは、上記サーバーコンピュータへ外部からアクセスできる請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項７】
上記メタデータデータベースは、コンテンツ物理的特性、コンテンツ記憶位置、コンテンツ使用期間、コンテンツ使用権利、コンテンツ再生時間巾、コンテンツプレフィックスキャッシュ状態、コンテンツネットワークルーティングコスト情報、及びその組み合せのセットから選択されたデータを記憶する請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項８】
上記メタデータは、コンテンツのプレフィックス部分又はコンテンツの低分解能プレビューも含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項９】
上記コントロール手段は、要求応答及び再生手順を含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１０】
上記記憶装置は、所定の時間率でプレゼンテーションするためにレンダリングされるよう意図された少なくとも１つのコンテンツアイテムを記憶する請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１１】
上記少なくとも１つのコンテンツアイテムは、イメージエレメントフレーム及びオーディオエレメントを有するビデオコンテンツアイテムを含み、これは、上記所定の時間率で再生装置にプレゼンテーションするためにレンダリングされるよう意図され、発生時に視聴者に実質的に同じ視覚的及び聴覚的レンダリングを与える請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１２】
上記ビデオコンテンツアイテムを構成するデータの量は、パケット交換インターネットネットワークを経てパケットで通信されるデータの量より多い請求項１１に記載のメタデータイネーブル型エッジサーバー。
【請求項１３】
上記ビデオコンテンツアイテムを構成するデータの量は、意図された再生率でリアルタイムにレンダリングされたときに１０分のブロードキャストクオリティビデオを越えるビデオコンテンツの量である請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１４】
上記ビデオコンテンツアイテムを構成するデータの量は、意図された再生率でリアルタイムにレンダリングされたときに６０分のブロードキャストクオリティビデオを越えるビデオコンテンツの量である請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１５】
上記ビデオコンテンツアイテムは、ビデオフォーマットにおける実質的に全長の特集フィルムを含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１６】
上記ネットワーク通信リンクは、インターネットインフラストラクチャーを含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１７】
上記ネットワーク通信リンクは、インターネットインフラストラクチャー及びインターネット通信プロトコルを含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１８】
上記メタデータは、システムオペレーション及びコンテンツルーティングに対してインテリジェント判断を実行できるようにするために使用される請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項１９】
上記メタデータは、その物理的特性、メタデータにより表わされたコンテンツの考えられる位置、及びその使用期間を含む実際のコンテンツに関する情報を含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項２０】
上記メタデータは、コンテンツオブジェクトを記述するグローバルに独特の識別子と、上記コンテンツオブジェクトが見つかる少なくとも１つの位置とを含む請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項２１】
上記コンテンツオブジェクトは、パケット交換ネットワークを経て通信するために複数のパケットを要求するデータの量を有するビデオコンテンツオブジェクトを含み、そして上記コントローラは、上記識別されたコンテンツ位置から上記要求を発しているユーザの再生装置へアイソクロノス送付を与える請求項１に記載のメタデータイネーブル型エッジサーバー。
【請求項２２】
ユーザの要求に応答してネットワーク通信リンクを経てユーザにコンテンツオブジェクトを配給するためのシステムであって、
原点サーバー（origin server）と、
通信ネットワークを経て上記原点サーバーへ各々接続できる複数のエッジサーバーと、
を備え、各々の上記エッジサーバーは、メタデータイネーブル型のエッジサーバーであって、これは、
コンピュータプログラム命令を実行するためのプロセッサ及び該プロセッサに接続されたメモリと、外部エンティティから通信を受信し及びそれを送信するための少なくとも１つの入力／出力ポートとを有するサーバーコンピュータと、
上記サーバーに接続された記憶装置であって、上記サーバーにアクセスできるコンテンツオブジェクトを記述し、上記コンテンツオブジェクトの特定の１つが記憶されて上記ユーザへ向けられ得るところの少なくとも１つの位置を含むメタデータを記憶する記憶装置と、
上記メタデータを使用して上記ユーザへ上記コンテンツオブジェクトを配給し、そして上記ネットワークを経て上記コンテンツの一部分のアイソクロノス配送を維持するためのコントローラと、
を備えたものであるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータネットワーク、及びコンピュータネットワークを経て配送されるストリーミングメディアオブジェクトに係る。より詳細には、本発明は、コンテンツに関連したメタデータを使用して、多数のコンピュータネットワークの内部の種々の位置にコンテンツのコピーを得られるようにし、ストリーミングメディアオブジェクトを配送するための良好なサービスクオリティを与えるための効率的な技術に係る。
【背景技術】
【０００２】
ブロードバンドインターネットネットワークインフラストラクチャーは、積極的なアナリストの予想を上回る速度で開発されている。消費者市場部門では、テレコミュニケーション、ケーブル及びワイヤレスの会社が、ｘＤＳＬ、ケーブルモデム又はワイヤレス最終マイルロールアウトと共に家庭へのブロードバンド能力の配備を加速している。法人市場部門では、デスクトップコンピュータアプリケーションのためにブロードバンドインフラストラクチャーが既に入手できる。
【０００３】
ブロードバンドは、インターネットアプリケーションにおいて優れたクオリティのＩＰビデオを使用するための基礎を与える。従来はイントラネットやプライベートネットワークに限定されたが、ブロードバンドのインターネット接続は、ビデオを伴うインターネット広告、ウェブページのリッチメディア、ビデオアシスト式電子商取引（ビデオカタログ、旅行等）、イベントウェブキャスティング、パーソナル情報オンデマンド（ニュース、スポーツ、医療、公演、映画等）、パーソナルビデオ交換機、トレーニング、及び法人通信のようなビデオベースアプリケーションのための経路を舗装するものである。
【０００４】
インターネットに従来見られそして狭帯域接続を経て配送される低フレームレート、小サイズのビデオ又は低分解能に比して、圧縮技術の進歩により、３００Ｋビット／秒（Ｋｂｐｓ）以上の接続レートで適度なクオリティのビデオが可能となった。動きやアクションが非常に少ないニュース番組や公演は、約１００Ｋｂｐｓないし２００Ｋｂｐｓの低いビットレートで送信することができる。ファッションショーのような動きの激しいビデオは、その動き及びシーンの細部を捕えるために高いビットレートを必要とする。インターネット配給を考えているコンテンツプロバイダーの場合には、３００Ｋｂｐｓでも受け入れられ、１ないし１．５Ｍｂｐｓであれば良好であると考えられる。ビデオカタログ、広告、及びビデオの他の商取引関連用途は、考えられる最高のクオリティレベルで商品をプレゼンテーションすることを要求する。１．５Ｍｂｐｓ以上のブロードバンドレートは、ＣＤクオリティの音声と共に３０フレーム／秒（ｆｐｓ）の映像を与える。自動車レースのような多量の動きを伴うコンテンツは、３ないし４Ｍｂｐｓのような更に高いビットレートを必要とする。
【０００５】
ブロードバンド接続が増加するにつれて、優れた性能の需要は、インターネットコンテンツの配送をスピードアップすることに向けられた産業を促進した。これら解決策の大半は、テキストやイメージのような小さなオブジェクトを中心とするものである。ビデオデータやオブジェクトは、データのサイズや、リアルタイム又はほぼリアルタイムの再生又はレンダリング要求に関連した特定のレートでそれを供給する要求のために問題を引き起こす。単にそのサイズだけのために、映像は、インターネット又は他のネットワーク環境において管理が最も困難なデータ形式の１つである。１．５Ｍｂｐｓでエンコードされ圧縮される５分のビデオチップは、サイズが５６メガバイトである。これは、典型的なウェブページの場合、数キロバイトのデータサイズに匹敵する。厳密なビデオタイミング要求が付加的な制約を課する。１つのフレーム又は１組のフレームがそれらの意図されたプレゼンテーション時間を越えて到着するときには（例えば、３０ｆｐｓビデオの場合に公称１／３０秒フレーム間隔以上で）、消費者又はユーザは、急激な再生、ビデオのフレーム又はセグメントの落ち、或いはビデオの見易さを低下して商業的設定において本質的に無益にレンダリングする他の欠陥を経験する。これらの厳格な要求が与えられると、ブロードバンドにわたりクオリティの高いビデオを配送することは、困難な問題となる。
【０００６】
ブロードバンドインフラストラクチャーの配備は、インターネットにわたってストリーミングビデオを可能にする際の重要なステップであるが、接続及び帯域巾をアップグレードするだけでは、大勢の聴衆に最低限のスタートアップレイテンシでクオリティの高いビデオを配送するよう確保できない。ビデオがインターネットバックボーンを経てエンドユーザへ流されるときには、ビデオのクオリティがしばしば問題を受ける。ビデオのソースがエンドユーザに充分接近していないときには、パケットロスがビデオのクオリティを甚だ危うくする。パケットロスは、ビデオソースとエンドユーザとの間のネットワークスイッチ及びルーターにより導入される混雑したバッファから生じる。現在の帯域巾コスト（衛星及び地上）は、高クオリティビデオをサーバーからエンドユーザへポイント対ポイントベースで流すのを不可能にする。送信されるビデオが少なくともＴＶ又は放送クオリティのビデオであると意図されるときには、従来の技術に関連した問題が益々過酷なものとなる。
【０００７】
リッチメディアを含む（典型的に静止像を含む）ウェブページにアクセスする性能を改善することに向けられた既存の従来の解決策は、インターネット上のストリーミングビデオに伴う問題に対処するために益々使用されている。現在、インターネットにおけるコンテンツ配給の性能を改善するために使用されている解決策は、次の２つのクラスがある。（ｉ）特定のコンテンツディストリビューションネットワークアーキテクチャー及び操作機構、及び（ii）コンテンツキャッシング機構。
【０００８】
比較のために、先ず、コンテンツソースからコンテンツ要求者への何らかの種類の分散型コンテンツ配送を与えるものでないコンテンツ配送機構について説明する。この形式のシステム及びオペレーションでは、オーディオ又はビデオオブジェクトのようなコンテンツが単一のオブジェクトサーバーのみに記憶される。ユーザ（おそらく同じオブジェクトに対して要求を発する数百万のユーザの一人）がオブジェクトを要求するときには、その要求は、どんな１組のネットワーク、ルーター又は他のネットワークインフラストラクチャー要素がユーザのクライアントコンピュータ又は他の情報機器とコンテンツオブジェクトソースサーバーとの間に介在しようともそれを介して単一のオブジェクトサーバーにルーティングされる。コンテンツオブジェクトソースサーバーは、次いで、要求されたコンテンツを要求者へ返送する。あるコンテンツオブジェクト（テキスト又は小さな圧縮された静止像ファイルのような）の限定された数の行先への小サイズ非リアルタイム配送の場合には、このような直接的な配送解決策は、重要なオペレーションを意味する。しかしながら、このような解決策は、システム又はサーバーの拡張性又は負荷問題に対処するものではない。
【０００９】
一般化されたコンテンツ形式の場合でも、いかなる形態の分散型コンテンツキャッシングも伴わない直接的な配送は、本来的に、２つの問題を示す。第１に、商業的関心事のコンテンツ配送状態に対し、単一の中央コンテンツオブジェクトサーバーに、該サーバーが要求を受信し及び／又はその受信した要求に応答するのを許すに充分なネットワーク帯域巾が単にない。第２に、充分なネットワーク帯域巾があっても、特に、コンテンツが高クオリティビデオを大量に含むときには、要求されたコンテンツを与えるに充分な処理リソースがない。ここで、制限となる処理リソースは、限定された数以上のビデオストリームに同時にサービスするためのサーバーハードウェアの能力、コンテンツ（例えばビデオ）を記憶する取り付けられた記憶装置にアクセスするためのサーバーの制限、或いはサーバーの他のローカルハードウェア、ソフトウェア、インターフェイス又は他の構造上又は動作上の制限である。
【００１０】
コンテンツがビデオであるときには、このような直接配送に伴う第３の主たる問題又は制限が明らかになる。現在のネットワークは、パケット交換式であり、通常、中央オブジェクトサーバーと、要求を発しているユーザとの間には多数のルーター及びスイッチがある。ルーターには、通常、受け取ったデータ（通常、パケットの形態）を、ネットワークの次のノードへ転送できるまでバッファするためのバッファが設けられるが、これらのバッファは、バッファ容量に限度があり、受け取ったデータの量が、転送できる量又は転送が可能になるまで記憶できる量より多い場合には、このようなデータ又はデータのパケットが単に失われるか又は脱落となる。典型的なウェブページの場合、これは、ページが単に再び要求されたときには著しい問題とならない。しかしながら、リアルタイムで連続的に見ることが意図されたビデオストリームの場合には、ビデオのパケットの脱落は、回復メカニズムを与えない。ビデオのそのセグメントは、単に見ることができず、そのビデオセグメントに置き換えるための種々の機構、例えば、最後に得られるフレームの静的なフリーズ、スクリーンのブランキング、又は他の従来のものであるが通常は満足でない技術が与えられる。
【００１１】
この点について、従来のインターネットインフラストラクチャー、特に、ネットワークルーター、或いはこのようなルーター内にあるか又はルーターに関連した入力又は出力バッファは、送付時間要求を有するパケットを確認するか、さもなければ、データ又はパケット時間ベース又はアイソクロノス配送を維持するためのメカニズムを与えない。それ故、この特徴が望ましいか又は必要である場合には、他のメカニズムが要求される。
【００１２】
直接配送に関連した幾つかの問題を軽減する１つの試みは、一般的コンテンツ配給において、ある程度の拡張性を与えると共に、単一の中央サーバーアーキテクチャーに比して負荷問題を軽減する試みである。１つのこのような解決策は、「分散型コンテンツサービス（ＤＣＳ）」と一般に称されるアーキテクチャー及び操作機構を使用するコンテンツ配送ネットワークである。ＤＣＳのもとでは、イメージのような大量のコンテンツを含むウェブページの部分が、例えば、図１に示すように、ネットワークのエッジに接近した最終マイルサービスプロバイダー位置に配備された多数のエッジサーバーに複写（「プッシュ」又は「プッシュ複写」）される。このコンテンツプッシュは、データが使用されるかどうか知る前にデータが全ての又は選択されたエッジサーバーに送信されるという点で従来のものである。これは、コンテンツについて識別されたニーズ又は要求に関わりなくコンテンツがキャッシュされるというエッジサーバーキャッシング戦略の一形式である。（エッジサーバーベースのコンテンツプルキャッシングモデルも、本明細書のどこかで説明する。）
【００１３】
この従来のプッシュは、エッジサーバーにおいて記憶スペース（ハードディスクドライブ記憶装置）を消費し、そしてネットワークにわたりコンテンツオリジナルソースサーバー（原点サーバーとも称される）と（各）エッジサーバーとの間でネットワーク帯域巾を使用するが、これら記憶装置及び帯域巾の負担は、少なくとも受け入れられるものである。というのは、取り扱われる典型的なウェブページが小さくて、キロバイト範囲であり、そして厳格な配送時間要求を課さないためである。比較のために、４メガビット／秒（４Ｍｂｐｓ）のレートの情報を表わす１時間ビデオは、各エッジサーバーに対して１４４００メガビットの記憶容量とそれに対応する量のネットワーク帯域巾とを必要とする。従って、従来のプッシュは、テキスト及び１つ又は若干の静止像より成る選択されたウェブページに対しては受け入れられるが、エッジサーバーにおいて多量の記憶容量を消費し、そしてビデオコンテンツが実際に要求されるか又はユーザへ配送されるかに関わらず、多量のネットワーク帯域巾要領を使用する。未使用の及び浪費されたリソースは、プロバイダーに対する実際の金銭及び機会費用を表わす。
【００１４】
ユーザが、ウェブページ、又はウェブページ内のリンク、或いはコンテンツを組み込むか又はコンテンツを参照する他のコンテンツをアクセスすることにより、明白に（例えば、ビデオ再生リストから選択することにより）又は暗黙にコンテンツを要求するときには、ユーザに接近したエッジサーバーが、複写されたコンテンツをユーザにサービスするように向けられる。エッジサーバーの「接近性」は、多数の方法で定義され、例えば、地理的接近度、使用可能な帯域巾、予想されるコスト、又は他のルールやポリシーに基づいて定義される。
【００１５】
少なくとも頻繁に要求されるコンテンツをネットワーク全体にわたって配給することにより、この「分散型コンテンツサービス（ＤＣＳ）」解決策は、このように頻繁に使用されるコンテンツに対しネットワークバックボーンを経て大きなファイルを移動するのを効果的に回避する。バックボーンの回避は、性能を改善し（戦略的に配置されたエッジサーバーと要求者クライアントとの間に若干のホップがあるために）、そしてコスト効率が良く且つ拡張可能な解決策である。コンテンツ配送ネットワークは、一般に、プライベート衛星及び／又は地上ネットワークを使用して、発信サーバーをエッジサーバーに接続する。この解決策は、ウェブページにおける静止像及びストリーミング音声のような小さなメディア形式の配送を改善するように広く配備されている。不都合なことに、ビデオのリアルタイム配送又は再生に対して最適な解決策を与えるものではなく、リソースの利用性、予約及び管理問題に対処するものでもない。
【００１６】
上記問題を解消するのに使用される別の解決策は、「キャッシング」解決策である。このキャッシング解決策では、キャッシングサーバーへのコンテンツの配給は、第１の要求がなされるまで遅延され、特定のコンテンツ（テキスト、イメージ、オーディオ又はビデオのような）を含むウェブページにユーザが最初にアクセスすると、コンテンツは、原点サーバーから直接サービス（プッシュ）され、そしてその後、キャッシングサーバーによって受け取られてキャッシュ処理される。これは、正確には「プッシュ」と称されるが、原点サーバーからリモートキャッシングサーバーへのコンテンツの配送が、特定のコンテンツに対して受け取られた要求の結果としてキャッシングサーバーにより開始されるので、「プル」と称されてもよい。キャッシングサーバーがエッジサーバーである場合には、キャッシングエッジサーバーは、クライアント／ユーザ／要求者から直接要求を受け取る。キャッシングサーバーがエッジサーバーでない場合には、コンテンツの要求が、ユーザから、エッジサーバー並びに介在するネットワークインフラストラクチャー及び／又はエージェントを経て間接的に受け取られる。キャッシングサーバーは、エンドユーザに接近したネットワーク内の戦略的ポイント（通常はインターネットサービスプロバイダー又はＩＳＰネットワーク）に配置される。（エッジサーバーは、キャッシングサーバーの１つの考えられる形式であるが、一般に、キャッシングサーバーは、ネットワークのエッジには必要とされない。）
【００１７】
同じ又は異なる要求者／ユーザにより同じページがその後にアクセスされると、キャッシュコンテンツは、例えば、図２に示すように、エンドユーザに直接サービスされる。キャッシングシステムは、ウェブオブジェクトに対するＵＲＬ要求を監視するサービスプロバイダー位置における特殊な装置より成る。キャッシュサーバーからのサービングコンテンツは、通常、インターネットバックボーントラフィックを約５０％以上減少し、従って、帯域巾の使用に関連したコストを減少することができる。又、エンドユーザに接近したキャッシュからのサービングコンテンツは、第１の解決策で述べた理由で性能を改善する。
【００１８】
不都合なことに、キャッシングサーバー（例えば、キャッシングエッジサーバー）から原点サーバーへのユーザ要求で開始されたプルと、キャッシングサーバー（例えば、キャッシングエッジサーバー）を経てユーザへ向けられるコンテンツのその後のプッシュとに基づく後者の解決策では、コンテンツの受信及び配送に関連したレイテンシ即ち遅延がある。簡単なウェブページの場合に、この遅延は、たとえ１秒又は数秒であっても受け入れられるが、ユーザへの即座のそして連続的な再生に意図されたリアルタイム映像の連続ストリームの場合には受け入れられない。このような既知の従来の解決策は、ビデオコンテンツのある初期部分が、要求者又は要求者にサービスするエッジサーバーへ送信されたときに、ビデオコンテンツストリームの残りを、受信においてパケットの脱落や認知し得る遅延を伴わずに送信できるように保証するか又は合理的保証を与える任意の形式のネットワークリソース予約又は管理に対して与えられたものではない。このような適時の受信を保証できない場合には、キャッシングエッジサーバーへ送信される部分を、要求を発しているユーザへの送信を開始する前に増加するか、或いは要求者へ送信を開始する前に全ビデオを送信して、中断のないリアルタイム再生を実行することが必要となる。これは、もちろん、要求を発しているユーザによる受信に、相当に大きな、そしておそらくは、受け入れられないほどの遅延を生じさせる。
【００１９】
このモデルに関連した別の問題は、コンテンツ位置問題である。ユーザからの要求を受信する各エッジサーバーは、中央の原点サーバーから要求されたコンテンツを得られることを知り（原点サーバーがコンテンツを有すると仮定すれば）、従って、各エッジサーバーは、その原点サーバーからコンテンツを要求する。この操作モデルのもとでは、エッジサーバーは、エッジサーバーの他のどれがコンテンツを既に得ているかに関する情報をもたず、それ故、別のおそらく良好な（低いレイテンシ、高い帯域巾、少数のホップ、等）又は低コストの別のソースを表わす。
【００２０】
更に、要求がなされた場合及びそのようなときにコンテンツがエッジサーバーに送信されるだけであるから、原点サーバー又はネットワークのいずれかにおいてある筋書きのもとで要求されたコンテンツを受信するための競合のおそれが生じる。例えば、プライムタイムの視聴時間に、人気のある新たなビデオ映画に対して著しく多数の要求が生じ、従って、受け入れられない遅延に遭遇するか、又は再生が開始した後にビデオストリームが途切れることがある。割り込みニュース番組に関連したビデオや、さもなければ、ある事象が高い関心事を招くときにも、同様の問題が発生する。この問題は、本明細書のどこかで述べる従来のプッシュモデルでは必ずしも遭遇しない。というのは、コンテンツに対する需要が低く、ネットワークにおいて過剰な帯域巾を使用できるとき、例えば、地方市場の時間ゾーンにおける夜間に、コンテンツプッシュをスケジュールできるからである。
【００２１】
これらの両方の解決策（分散型コンテンツサービス又はキャッシング）に伴う別の問題は、これら解決策のいずれも、エンドユーザへ要求をサービスする前に行わねばならない又は少なくとも行うべきその他の業務上の判断に適していないことである。例えば、ユーザの要求が自分のエッジサーバーに直接向けられる場合に（今日使用されているシステム及び方法はその大半がそうである）、ユーザがオブジェクトに正当にアクセスできるかどうか指示するための情報がエッジに得られない。更に、このようなシステム及び方法は、使用パターン、レポート等の統計学的情報を保持するのに容易に適さない。
【００２２】
インターネット又はコンピュータネットワークの利益の１つは、「ナローキャスティング(narrowcasting)」を与える能力、例えば、ターゲットを決めたやり方で小さなユーザグループ（及び個々のユーザ）にアドレスする能力である。ナローキャスティングの有望性は、エンドユーザにターゲット情報を与える能力にある。ブロードキャストの世界（例えば、ネットワークテレビジョン）では、特定の番組（例えば、ＮＢＡファイナル）に調整した全てのユーザが、同じ広告を含む同じ番組を受信する。ナローキャスティングの世界では、自動車に関心のあるシンシナティーのユーザがそれらの地域の自動車販売代理店から広告を見ることができねばならない。これは、ユーザに関する情報（「メタデータ」又は「ＭＤ」）１０８が動的コンテンツ挿入のためにエッジサーバー１１０において入手できることを意味する。
【００２３】
これら及び他の事柄に鑑み、当業者であれば、コンテンツ配送及びキャッシングのための現在のシステム及び方法は、ある形式のコンテンツの配送、特に、ブロードキャストクオリティのコンテンツのような高クオリティビデオコンテンツの配送に対して最適なものではないことが明らかであろう。現在のコンテンツ配送ネットワークは、ネットワークのエッジに全ての応答時間感知データを記憶することにより保証された応答時間を確保する。ユーザは、記憶コストを支払うことにより応答時間を確保する。ここでの主たる仮定は、記憶コストが、バックボーンにわたってデータを搬送することに関連した帯域巾コストより著しく低いことである。ブロードバンドネットワークにおける高クオリティ全フレームレートビデオの絶対的サイズは、記憶対帯域巾問題の再検討を必要とする。この問題を説明するために、インターネットにおけるブロードバンドビデオの、例として浮上する２つのアプリケーション、即ちビデオコンテンツを伴うインターネット広告、及び需要時のパーソナル情報の配送について考える。
【００２４】
インターネット広告サービスビジネスは、従来のテキストベース及び／又は静止像ベースのバナー広告に勝るビデオベース広告の潜在的な効果を認識する上でブロードバンドビデオをサポートするための再編成を開始した。ビデオベース広告の場合に、ビデオウインドウのサイズ及びフレームレートの両方に関してクオリティが非常に重要である。高クオリティのビデオ映像及びスムースな再生即ちレンダリングを維持することは、商品のクオリティ及び広告主のサービスの認知に対して重要である。
【００２５】
このようなビデオベース広告に対する潜在的記憶及び帯域巾要求は、甚だしいものである。業界の情報源は、インターネット広告サービスビジネス（ダブルクリック）における１人の特定のマーケットリーダーが２０００年４月に約４８０億の印象にサービスしたことを報告している。完全に配備されたシステムにおいて１００万の個別の広告があり、そしてこれらの広告が１．０Ｍｂｐｓでデジタル化された３０秒長さのビデオクリップであると仮定すれば、これらの広告は、３７５ギガバイトの記憶量を表わす。１０００台のエッジサーバーでは、３７５テラバイトのビデオデータとなる。
【００２６】
需要時におけるパーソナル情報の配送については、ビデオコンテンツに富んだ情報（ニュース、スポーツ、娯楽、個人健康情報及び他の形式のビデオリッチコンテンツ）のパーソナル化又はカスタマイズされた配送は、ブロードバンドインターネットにおいて成長を続けているアプリケーションセグメントである。１．０Ｍｂｐｓにおける５分のビデオセグメントは、３７．５メガバイトに達する。５分のセグメントに分割された２４時間セグメントである１つのこのようなビデオチャンネルは、約１０ギガバイトの記憶量に達する。このようなチャンネルが１００あると、１テラバイトに達する。１０００台のエッジサーバーに記憶されたこのようなメディアは、ビデオ１日分では１ペタバイトの記憶量に達する。
【００２７】
これらアプリケーションのいずれか及び他の数え切れないアプリケーションに対して、少なくともハードウェアの観点から、各エッジサーバーネットワーク内の全データを記憶することは不可能である。更に、フロアスペースは、サーバーや記憶装置を配備する必要のある中央オフィスやケーブルヘッドエンドでは高価である。測定されそして予想される使用量に基づくデータのインテリジェントな配置は、確かに、より実際的である。
【００２８】
記憶装置は、ハードウェアデバイス又はディスク（又は他の記憶媒体）の記憶スペースのみに関するものではない。１８ギガバイトディスクドライブは、エッジサーバーに１つのチャンネルの約２日分を保持するのに充分な大きさである。しかしながら、ディスク帯域巾レート（又は１単位時間でディスクから読み取ることのできるデータの量）は、ディスクから同時にデータを受信するユーザの数を制限する。より多くのユーザにサービスするために、付加的なディスクにおいてデータを複写することが必要であるが、必要なスペースの量を何倍も増大し、記憶コストを著しく追加することになる。
【００２９】
コンテンツ配送ネットワークの解決策にも問題がある。コンテンツ配送システムは、通常、ネットワークにおける負荷の増加に応答してサーバー内に動的複写技術を使用する。高クオリティビデオ媒体の絶対的サイズは、ランタイム複写を不可能なものにする。ローディングは、通常、手に手をとって進行し、ネットワークのデータトラフィックが増加する。ローディングに応答した複写は、ネットワークを更に混雑させる。あるコンテンツ配送ネットワークは、衛星送信を使用して、データソースから、受信者に接続されたエッジサーバーへデータを移動する。衛星送信は、ソースからのデータが多数の受信者に同時にブロードキャストされる場合にはコスト効率が良い。それ故、ライブイベントウェブキャスティングは、当然、この送信モードに適している。上述した記憶装置のサイズ要求のために、データがエッジに均一に記憶されていない場合に、記憶されたデータからオンデマンドストリーミングを要求するアプリケーションは、衛星搬送を利用してコスト効率良く展開することができない。
【００３０】
光ファイバーネットワークの各ファイバーに更にチャンネルを付加する「高密度波長分割多重化（ＤＷＤＭ）」のような光学的ネットワーク技術の進歩に伴い、テラビットのバックボーン容量がおそらく実施に向けて進んでおり、帯域巾コストは、おそらく著しく安くなるであろう。しかしながら、少なくとも一部分は、ビデオデータのアイソクロノス性質により、且つビデオデータがおそらくソースサーバーとユーザコンピュータとの間で遭遇するホップの数により、映像をソースからユーザコンピュータへ直接的に流すことが不可能になった。これと拡張性の理由で、エッジは、おそらく、好ましいオペレーション及びアーキテクチャーモデルを保持するように働くことが保証される。
【００３１】
種々のキャッシング解決策の場合に、多数の問題が依然残される。純粋なキャッシング解決策を使用するネットワークは、キャッシングすることが必要とされるオブジェクトの絶対的サイズによる問題でも悩まされている。適度なサイズのキャッシュの場合に、キャッシュすることのできるオブジェクトの数は、非常に少なく、高キャッシュ攪拌、低ヒット率を招く。媒体のキャッシングは、コンテンツ所有者（又はコンテンツ配給者）がそれらのビデオオブジェクトに対して有しているコントロールのレベルを減少する。コントロールを失うことは、収入発生に直接影響する追跡及び版権の問題を意味する。追跡能力を失うと、ターゲットを決めた広告により収入を生み出す能力も減少する。最後に、ネットワークのサイズが増加するにつれて、キャッシュされた媒体を効率的に探索しそしてそれを適当なエッジサーバーへ向けることが問題となる。
【発明の開示】
【発明が解決しようとする課題】
【００３２】
従って、インターネット又は他のネットワークを経て映像（又は他の大きな時間感知データ形式）をストリーミングする改善されたそして好ましくは最適な解決策が要望される。現在普及した解決策は、インターネットを経て静止映像及びストリーミング音声を配送するように設計されており、リアルタイム又は少なくともアイソクロノスストリーミングビデオ要求を満足することができない。又、一般的に、ビデオコンテンツに対して充分なネットワークリソース予約管理を行うこともできない。
【課題を解決するための手段】
【００３３】
＜関連出願＞
本出願は、各々参考としてここに援用する０３／０２／０１に出願された「Push Pull Model Making Use of Metadata For Efficient Content Distribution」と題する米国プロビジョナル特許出願第６０／２７２，９３９号、及び０３／０２／０１に出願された「Asset Transfer File Format and Extractor/Parser/Installer For Video Content Distribution」と題する米国プロビジョナル特許出願第６０／２７２，９４４号に対する３５ＵＳＣ§１１９（ｅ）及び／又は３５ＵＳＣ§１２０のもとでの利益を請求する。
【００３４】
メタデータイネーブル型プッシュ−プルモデルのための方法、システム、コンピュータプログラム及びコンピュータプログラム製品、並びにネットワークを経て効率的に低レイテンシでビデオコンテンツを配給（ディストリビューション）するための方法が提供される。メタデータは、コンテンツディストリビューションシステムのオペレーションにおいてインテリジェントな判断を行えるようにするためのビヒクル及びメカニズムとして使用される。メタデータは、実際のコンテンツに関する情報を含むデータであり、ある場合には、メタデータは、コンテンツの一部分又はコンテンツの低分解能プレビューも含む。本発明の態様は、効率的なシステムオペレーションを容易にすると共に、追跡、報告、パーソナル化等々の１組のサービスを任意であるが効果的に提供するというやり方で、ネットワーク全体にわたりメタデータを配給することに向けられる。
【００３５】
一実施形態において、本発明は、ユーザ要求に応答してネットワークにわたりユーザにコンテンツオブジェクトを配給するためのメタデータイネーブル型サーバーにおいて、コンピュータプログラム命令を実行するためのプロセッサ及び該プロセッサに接続されたメモリと、外部エンティティから通信を受信し及びそれを送信するための少なくとも１つの入力／出力ポートとを有するサーバーコンピュータと；上記サーバーに接続された記憶装置であって、上記サーバーにアクセスできるコンテンツオブジェクトを記述し、コンテンツオブジェクトが記憶されてユーザへ向けられるところの少なくとも１つの位置を含むメタデータを記憶する記憶装置と；上記メタデータを使用してユーザへ上記コンテンツオブジェクトを配給し、そしてネットワークを経て上記コンテンツの一部分のアイソクロノス配送を維持するためのコントローラとを備えたメタデータイネーブル型サーバーを提供する。コンテンツを配給しそしてコンテンツの配給を制御するための方法及び手順、システム、並びにコンピュータプログラムも提供される。
【発明を実施するための最良の形態】
【００３６】
本発明は、メタデータ（ＭＤ）を効率的なメディアコンテンツ配給に使用するメディアコンテンツディストリビューションシステムを提供することにより上記問題を解決する。
ここに述べる本発明の少なくとも幾つかの実施形態の基本的な主義は、システムのオペレーションにおいてインテリジェントな判断を行えるようにするためのビヒクル及びメカニズムとしてメタデータを使用することである。メタデータは、実際のコンテンツに関する情報、例えば、その物理的特性、メタデータにより表わされるコンテンツの考えられる位置、その使用期間等、及びこの説明のどこかで詳細に述べる他の情報を含む。ある場合には、メタデータは、コンテンツの一部分（コンテンツプレフィックス）又はコンテンツの低分解能プレビューも含む。本発明の態様は、効率的なシステムオペレーションを容易にすると共に、従来の又は公知のシステム及び方法には存在しない１組のサービス（追跡、報告、パーソナル化等々）を任意であるが効果的に提供するというやり方で、ネットワーク全体にわたりメタデータを配給することに向けられる。
【００３７】
図３を参照すれば、グローバルなコンピュータネットワークに配備される本発明のシステム１０２の実施形態がブロック図の形態で示されている。原点サーバー１０４は、多数の形式及び構成がこの技術で知られているサーバーでよい。典型的に、このようなサーバーは、プロセッサと、該プロセッサに接続されたメモリと、入力／出力装置と、通常は回転するメディアハードディスクドライブの形態の大量不揮発性記憶装置と、プロセッサ及びメモリにおいて実行されてサーバーを特定の仕方で動作するように指令するコンピュータ実行可能な命令を与えるコンピュータソフトウェアとを備えている。この実施形態では、原点サーバー１０４は、メタデータのデータベース１０６と、ビデオコンテンツ（又は他の任意コンテンツ）記憶装置１０８とを備えている。又、システム１０２は、少なくとも１つの、そして通常は、複数のエッジサーバー（ＥＳ）１１０−ｎ（例えば、１１０−１、１１０−２、・・１１０−ｎ）も備え、その各々も、典型的に、メタデータのデータベース１０６及び大量記憶装置１１８を備えている。各エッジサーバーの大量記憶装置１１８に記憶されるデータは、通常、本明細書のどこかに詳細に述べる特定の実施形態に基づいている。例えば、一実施形態において、エッジサーバーの記憶装置は、特定のコンテンツに対して少なくとも１つの要求がなされると、全ビデオコンテンツを記憶する。他の実施形態では、記憶装置は、ビデオプレフィックスコンテンツ部分のようなプレフィックスコンテンツを記憶する。他の実施形態では、エッジサーバー記憶装置１１８は、複数のビデオタイトルに対する全ビデオコンテンツ又は実質的に全ビデオコンテンツと、ある１組のビデオコンテンツアイテムに対するプレフィックス部分の両方を記憶する。メタデータデータベース及びコンテンツは、同じ物理的及び／又は論理的装置に記憶されてもよいし、或いは異なる物理的又は論理的大量記憶装置に記憶されてもよい。メタデータデータベースは、比較的小さいので、通常、不揮発性バックアップ記憶装置に代わって又はそれに加えてランダムアクセスメモリに記憶されてもよい。
【００３８】
図４を参照すれば、ＭＰＥＧ−１及びＭＰＥＧ−２ポンプ、カセナ（カリフォルニア州、マウンティン・ビュー）ＯＴ４．０フォーマットポンプ、リアルＧ２サーバーに対するメディアストリーミングサポート１２２と、種々のビデオオブジェクト及び他のコンテンツ形式及びフォーマットをサポートするための他のメディアサービスに対するサポートとを備えたメディア記憶装置の実施形態がブロック図で示されている。メディアマネージメント１２４の機能は、収集、記憶、メタデータデータベース及びデータマネージメントの機能を含む。メディアディストリビューション１２６の機能も設けられ、これは、スケジュール転送、オンデマンド転送、並びにユニキャスト及びマルチキャストオペレーションを含む。接続マネージャー１１６及び記憶マネージャー１１７の機能も設けられる。
【００３９】
図５を参照すれば、コンテンツを受信しそしてその受信したコンテンツをレンダリングするために本発明のシステムに関連して使用されるコンピュータの主たる要素がブロック図形態で示されている。通信接続は、ビデオコンテンツストリームのようなコンテンツをサーバーから受信するための通信リンク又は経路を与える。
【００４０】
トップレベルの説明により、本発明のシステム及び方法の１つの特定実施形態では、コンテンツディストリビューションネットワークのエッジサーバー即ち「ＥＳ」（ネットワークのエッジ付近にあって、主としてエンドユーザへコンテンツをサービスする役割を果たすサーバー）は、個々のコンテンツアイテムに対するメタデータを、通常、そのアイテムに対するユニバーサル基準ロケータ（ＵＲＬ）の形態で編成するディレクトリを維持する。このディレクトリは、メタデータを容易に操作できるファンクションが与えられた関連データベースの一部分であってもよいし、或いはより簡単なフラットファイルデータベース構造体又はリスト又はテーブルが利用されてもよい。
【００４１】
一実施形態において、それが表わすメディアフォーマットの形式に関わらず、ビデオオブジェクト又はアセットの位置を参照するビデオコンテンツＵＲＬは、均質なフォーマットでマップされる。ＵＲＬによるか或いは他の指定子又は識別子による特定のビデオコンテンツのユーザ選択は、ビデオオブジェクトがキャッシュ処理されるかどうかに関わらず、メタデータデータベースに記憶される。追跡、報告、勘定、ターゲットを決めた広告、並びに他のデータ収集及び採取オペレーションは、この解決策を使用して容易に行うことができる。
【００４２】
別の例示的アプリケーションでは、ＵＲＬにより参照されるウェブサイトは、映画を再生するストリーミングビデオを受信する料金を支払うユーザに対して需要時に入手できる多数の特集長さビデオを記憶するサーバーを備えることができる（例えば、５０本の特集長さ映画を記憶できる）。サーバー上の各映画に対し、それに対応するエントリー又は一連のエントリーがメタデータディレクトリに設けられ、これは、ホストサーバー（原点サーバー又はエッジサーバー）がいかに多くの同時再生をサポートできるか、いかに多くのユーザが映画或いは他のビデオ又はコンテンツアイテムのコピーを現在見ているか、いかに多くのコピーが視聴のために入手できるか、帯域巾要求、等々を指示する。このサーバーに対するメタデータ又はメタデータデータベース（ＭＤ）は、サーバー自体に記憶することもできるし、コンテンツディストリビューションネットワークのホストサーバー又は他のエッジサーバーにより開始される周期的又は「オンデマンド（需要時）」更新において他のサーバーへエクスポートすることもできる。
【００４３】
又、メタデータは、ビデオオブジェクト又は他のコンテンツアイテムを探索するのにも使用できる。例えば、ユーザがエッジサーバー（ＥＳ）においてビデオの選択を行う（例えば、ＵＲＬを識別することにより）ときには、その選択されたＵＲＬに対応するメタデータ（ＭＤ）を調べて、それに対応するビデオオブジェクトがキャッシュにあるかどうか判断する。オブジェクトがキャッシュにある場合には、メディアがキャッシュから直接ストリーミングされる。さもなければ、メタデータの位置情報を使用して、ビデオオブジェクトをそのキャッシュに有する使用可能なサーバーを探索する。この探索は、接近度（ホップの数）や、最小トラフィック負荷に基づくか、或いは送信時間を最小にでき且つネットワークリソースを効率的に利用できる他の適当なやり方に基づいて行うことができる。ビデオオブジェクトが見つかると、そのソースから、それを要求したエッジサーバーへ直接移動され、キャッシュハイアラーキーにメディアが浸透して遅延を被ることが回避される。ヒントベースのアルゴリズムを使用してオブジェクトを探索することにより、本発明の実施形態は、従来のマルチレベルハイアラーキーより著しく優れている。
【００４４】
別の態様においては、ビデオプレフィックスキャッシング又はビデオプレフィックスコンテンツディストリビューション（ＶＰＣＤ）を使用して、メタデータ及びビデオオブジェクトの開始部分を、予想需要、測定使用量、及び原点サーバー（ＯＳ）１０４とエッジサーバー（ＥＳ）１１０との間の接続の形式のような特性に基づいてエッジサーバーへ配給するようにしてもよい。例えば、大きな需要が予想されるエッジサーバーには大きなビデオプレフィックスを使用することができ、他のエッジサーバーには小さなプレフィックスが記憶される。エッジサーバーにプレフィックスを有するビデオオブジェクトに対してヒットが生じた場合には、需要時にストリーミングを開始することができるが、ビデオオブジェクトの残りの部分はフェッチされてキャッシュ処理される。通常、原点サーバーは、全てのコンテンツアイテムに対してビデオ又は他のコンテンツを記憶するビデオコンテンツ記憶部（ＶＣＳ）１０８又は他の形式のコンテンツ記憶部を与える。又、各エッジサーバー１１０も、コンテンツアイテムを記憶するためのビデオ又は他のコンテンツの記憶部を与えるが、各エッジサーバーのコンテンツ記憶部は、通常、原点サーバーのコンテンツ記憶部に記憶されたコンテンツアイテムのサブセットのみを記憶する。（バーチャル化に関して以下に説明する本発明のある実施形態は、コンテンツ記憶部１８を必要としないか、或いは使用される相当に小さな記憶部、例えば、到来するビデオを、要求を発しているユーザへ送信する前にバッファするのに使用される小さな記憶部しか必要としないことに注意されたい。）
【００４５】
ビデオプレフィックスコンテンツディストリビューション（ＶＰＣＤ）を使用すると、ソースサーバーからエッジサーバーへビデオデータをコピーするのに含まれる初期のレイテンシを実際上排除できる。ＶＰＣＤの背後にある主たる原理は、メタデータ及びビデオコンテンツの開始部分（プレフィックス）を、予想需要、測定使用量、及び原点サーバーとエッジサーバーとの間の接続の形式のような特性に基づいてエッジサーバーへ配給することである。例えば、ビデオコンテンツの１０、２０、・・１００％が、予想需要及びサービスレベル合意に基づいてエッジサーバーに複写（プッシュ）される。プレフィックスコンテンツを伴うビデオに対してヒットが生じた場合には、ストリーミングが直ちにスタートするが、コンテンツの残りは、並列にフェッチされ（パイプライン処理され）、そしてキャッシュ処理される。これは、初期アクセスのレイテンシを排除しながら従来の記憶スペース要求を軽減する。キャッシュが再利用されるときには、コンテンツの一部分がメタデータと共に保持される。
【００４６】
プレフィックスキャッシング又は記憶を与える本発明の実施形態では、原点サーバーのビデオコンテンツ記憶部に記憶されて、要求に応答してエッジサーバーへ配送（デリバリー）されるビデオコンテンツは、全長のビデオであるか、又は全長のビデオからビデオコンテンツプレフィックス部分に対応する初期部分を差し引いたものである。ビデオコンテンツプレフィックスの量は、時間と共に変化しそしてネットワーク部分ごとにも変化するので、あるエッジサーバーがプレフィックスキャッシングを実施してもしなくても、そしてプレフィックスキャッシングを実施するエッジサーバーが異なる量又は時間長さのコンテンツをキャッシュ処理しても、一般的には、全長ビデオコンテンツを記憶して、いずれのエッジサーバーでも常に適当な部分（おそらく重畳を伴う）を得ることができて、他のエッジサーバーへ送信できるようにするのが望ましい。
【００４７】
要求を発しているユーザにより受信されると、コンテンツは、コンピュータ、テレビジョン、セットトップボックス、或いはコンテンツストリーム（ビデオ）を受信する他の装置又はシステムのようなユーザコンテンツレンダリング又は再生装置１２０においてレンダリング又は再生される。或いは又、コンテンツは、後で再生又はレンダリングするように記憶されてもよい。
【００４８】
本発明のシステム及び方法の要素の幾つかのトップレベル特徴及び効果について以上に述べたが、本発明のシステム、方法、コンピュータプログラム及びコンピュータプログラム製品、並びに操作モデル及び方法の実施形態を以下に詳細に説明する。本発明の態様は、コンテンツオブジェクトの大きなクラスに適用され、そして映像及び音声成分を含むマルチメディアオブジェクトに特に適用することができる。この説明で、ビデオ、ビデオオブジェクト、ビデオコンテンツ及び他の同様の用語を引用するときは、音声成分又はトラックを含むかどうかに関わりなく、全ての形態の従来のビデオ、映画、漫画、アニメーション、全ての形態の時間シーケンス映像、等々を意味するものと解釈されたい。
【００４９】
アプリケーション又は環境内で管理される他のデータに関する情報又は文書を与える定義データ（又はより簡単にいえば、他のデータに関するデータ）であるメタデータは、エッジサーバーからユーザへストリーミングするためにビデオオブジェクトを識別、記述、探索、フェッチ及びキャッシュ処理するのに使用される。メタデータの種々の実施例又はセットは、本発明のシステムの異なる実施形態、並びにシステム及び方法に望まれる特性及び能力に関連して使用される。
【００５０】
例えば、メタデータは、ビデオオブジェクト又はアセット、例えば、その物理的特性（フォーマット、サイズ、ビットレート、或いは同様の物理的又は論理的特性）、並びにアクセスされ、転送され及び／又はサービスされるところのネットワークにおける実際のビデオオブジェクトコンテンツの位置（１つ又は複数）を識別しそして記述することができる。通常、位置の１つは、原点サーバーであり、そして本発明の特定の実施形態によれば、１つ及び通常は複数のエッジサーバーである。（プレフィックスキャッシングを組み込んだ本発明の少なくとも１つの実施形態では、全ビデオの一部分のみがある位置に存在し、そしてこのような実施形態では、メタデータは、全ビデオのプレフィックス部分が記憶され又はキャッシュ処理されたサーバを識別するものであることに注意されたい。）
【００５１】
又、メタデータは、コンテンツに関連した所有権及び／又はアクセス権に関する情報、並びにビデオオブジェクトが限定された時間周期のみにわたって配給のために購入されたとき、例えば、限定期間ライセンスが著作権資料に対して得られたときに必要とされる「存続期間(time-to-live)」又は満期属性に関する情報も与える。権利情報は、例えば、いつ、どこで及び／又はだれにコンテンツを配送できるか（又はいつ、どこで及び／又はだれへの配送が禁止されるか）を識別する指示子を与える。この許可又は禁止は、例えば、エッジサーバーの地理的位置又は国家の州の位置、特定の領土に関連したものか、リスト又はデータベースの形態か、或いは他のルール又はポリシーに基づくものでよい。その一例は、特に性的に露骨なビデオ資料が、このような資料が攻撃を受けるか禁止された国家の州又は国々へ送信されるのを禁止することである。政治的に問題のある資料は、他の領域への送付が禁止される。
【００５２】
又、メタデータは、ネットワーク上の第１（ソース）位置からネットワーク上の別の第２位置へコンテンツを供給することに関連した「コスト」も定義し又は特定する。この第２位置は、通常、要求者へコンテンツをサービスするエッジサーバー又は他のサーバーである。個別のネットワークが含まれる場合には、コストは、あるネットワークから別のネットワークへ横断するコストを含む。コストファクタは、例えば、ネットワーク帯域巾を利用するための１つ以上の料率、特定位置のデータ記憶装置に記憶するコスト、外部エンティティを使用するか又は外部エンティティの使用を回避する要件、並びに搬送及び／又は記憶に関連した他のファクタを含む。コンテンツを検索しそして位置から位置へ搬送することに関連したコストは、ネットワーク条件又は他のファクタに基づいて変化するので、ネットワーク条件、ネットワーク料率、契約情報、現在入札形式、又はコストに影響する他のファクタへアクセスすることができ且つ別の位置及び／又はネットワークルートを示唆する外部エージェントを使用することができる。
【００５３】
又、サービスクオリティ（ＱＯＳ）要件も、メタデータにおいて特定される。このＱＯＳ情報は、例えば、この技術で知られたフレームフォーマット又はビデオクオリティ、許容再生レート偏差、及び他のインターネット型サービスクオリティ基準から選択されたサービスされるべき資料に対して保証されねばならないコンテンツ（例えば、ビデオ）クオリティの特定レベルを識別する。
【００５４】
他の実施形態では、メタデータは、ビデオからの個々のフレーム、ビデオの短い全分解能セグメント、ビデオの低分解能レンダリング、或いはビデオ自体から導出されるかビデオ自体に関連した他の形式のイメージ、例えば、ユーザとって有用であるか又はユーザを楽しませ、全ビデオを楽しむか又はビデオを視聴する選択をさせるものも与える。又、メタデータは、ビデオに関するテキスト情報のようなドキュメント情報も与える。ある場合には、このようなメタデータは、要求がなされたときにビデオ又は他のコンテンツの受信に関連した短い遅延中にユーザにレンダリングされてもよい。
【００５５】
コンテンツプレフィックスキャッシング（以下に詳細に述べる）を行うか又はサポートする本発明の実施形態では、大きなコンテンツの初期の小さな部分又はサブセットであるコンテンツプレフィックス（ビデオプレフィックスのような）がメタデータのエレメント又はコンポーネントとして与えられる。他の実施形態では、このようなコンテンツプレフィックスは、個別に与えられてもよい。
【００５６】
少なくとも１つの実施形態では、メタデータは、（ｉ）メタデータに関連したコンテンツを識別しそして任意であるがそれを記述するグローバルに独特な識別子と、（ii）コンテンツが見つかる位置であって、通常は、少なくとも原点サーバー識別子、及びより一般的にはコンテンツをキャッシュ処理するエッジサーバーの識別子の形態である位置（１つ又は複数）とを含む。任意であるが、他の望ましいコンテンツ配給特徴をサポートするために他のメタデータを設けるのが効果的である。強調及び要約すれば、これらの他の任意のメタデータエレメントは、次のセットから何らかの組合せで選択される。即ち、（iii）各位置からコンテンツを検索するコスト、（iv）ＭＰＥＧバージョン、リアルビデオ、或いは他の既知の又は開発されるべき音声及び／又は映像フォーマットのようなコンテンツフォーマット、（ｖ）権利情報、（vi）存続期間又は満期情報、（vii）サービスクオリティ、（viii）コンテンツサブセット又はプレビュー派生物、例えば、単一フレームビデオ、低分解能ビデオ、限定長さビデオ、テキスト記述等、及び／又は（ix）実際の全ビデオの定義された期間のようなコンテンツプレフィックス。本発明は、更に、コンテンツを記述し、要求者の位置決め又は要求者へのルート決めを助成し、コンテンツへのアクセスを制御し、希望のクオリティレベルを維持するよう助成し、さもなければ、サーバーごと又は全記憶要求を緩和し、又はレイテンシを減少する他のデータ又は情報をメタデータが含むことも意図する。
【００５７】
本発明は、データ経路（データ平面）からメタデータ経路（制御平面）を効果的に分離する。システムオペレーションは、次の２つの主たる態様を含む。（ｉ）コンテンツ再生又はサービス、及び（ii）メタデータ及びコンテンツのロード、生成又は追加、更新又は修正、及び削除の１つ以上を与えるシステムアドミニストレーション。好都合にも、コンテンツ、及びコンテンツに関連したメタデータ（又はメタデータの一部分）は、別々にロード又は更新することができる。例えば、コンテンツの権利の変更は、コンテンツ自体を更新する必要なく行われ、メタデータは、コンテンツに対してこれを識別するグローバルに独特の識別子（又は少なくともシステム内で独特な）を有し、コンテンツも、コンテンツデータ及びメタデータが互いに識別されるように識別子備えている。
【００５８】
メタデータは、ネットワーク全体にわたって配給され、そしてメタデータの一部分が、メタデータの更新を受け取るサーバーに記憶される。特定のビデオに対する典型的なメタデータは、大きさの程度がビデオデータファイル自体より小さいので、ネットワークにおけるメタデータの配給及びエッジサーバー（又は直接的にクライアント）における記憶は、存続可能なオペレーションであり、エッジサーバーの記憶に著しい影響を与えない。
【００５９】
システムが、同じコンテンツの異なるフォーマットを与えるように構成された場合には、このようなフォーマット変更は、メタデータデータベースのデータ構造において識別され、又は個別ディレクトリサーバーのデータ構造において行われる場合には、要求を満足するために最も適当なフォーマットが選択される。データ構造は、単純なリスト、テーブル、ハッシュ、関連データベース、又はこの技術で良く知られた他のデータ構造でよい。
【００６０】
ディレクトリサーバーは、通常、原点サーバー又はエッジサーバーとは異なるマシンであるが、他の実施形態は、原点サーバー又はエッジサーバーと同じマシンにディレクトリを設ける。それらの構成に基づいて１つ又は複数のディレクトリ又はディレクトリサーバーを設けることができる。複数のディレクトリサーバーは、冗長性を与えると共に、ピーク負荷の間に特定サーバーの負荷を減少するために効果的に設けられる。
【００６１】
コンテンツデータ及びコンテンツデータに関連したメタデータをシステム、ネットワーク、及び／又はその要素にインストールするための手順の一実施形態について以下に説明する。この手順は、図６の概略フローチャートを参照して説明する。先ず、コンテンツ（ビデオ）をシステムにインストールし、発生し、さもなければ、配置することが必要であり（ステップ２０１）、最初に原点サーバーにインストールされない場合には、既知の技術を使用して原点サーバーにインストールする。
【００６２】
次いで、コンテンツに対するメタデータを生成する（ステップ２０２）。このメタデータの生成は、コンテンツに対するメタデータの発生を許すようにコンテンツが充分に良好に定義される限り、コンテンツ（ビデオ）が生成される前、その間、又はその後を含んでいつでも行うことができる。この段階のメタデータは、グローバルに独特のＩＤ及び原点サーバー位置識別子のみを含む。原点サーバー位置は、たとえビデオがそのときに実際に原点サーバーにインストールされなくても、メタデータにおいて識別される。というのは、メタデータが実際に使用されるか又は問合せされるときまでにそこにインストールされるからである。メタデータは、その後、コンテンツ記憶位置の変更を反映するように変更又は更新される。
【００６３】
任意であるが、補足的メタデータエレメントを、必要又は希望に応じて追加して、任意の特徴、能力及び性能を与えることもできる（ステップ２０４）。例えば、メタデータは、上述したコンテンツの権利、フォーマット又は他の特性を識別するためにエレメントの最小セット以外のもので増強される。この付加的なメタデータは、任意であるが、コンテンツでパッケージされるか、又はコンテンツにアタッチされてコンテンツから抽出され、これにより、手動又は個別のアップロード／ダウンロードステップを排除することができる。或いは又、メタデータは、テキスト形態から手動で入力され、外部ソースからアップロード又はダウンロードされ、或いはコンテンツデータファイルや他のファイルのようなあるファイルから自動的に抽出されてもよい。例えば、ＭＰＥＧ−７フォーマットのビデオコンテンツの場合に、メタデータがファイルと共に含まれそしてそこから抽出されてもよい。
【００６４】
エッジサーバーへのメタデータのプッシュ、望ましくは「スケジュールされたプッシュ」が実行される（ステップ２０６）。一実施形態では、メタデータが全てのエッジサーバーにプッシュされる。別の実施形態では、メタデータが、エッジサーバーの選択されたサブセットにプッシュされる。全コンテンツ（通常、メガバイト又はギガバイト）がエッジサーバーにプッシュされることはなく、メタデータ（通常、数百又は数千バイト）のみがプッシュされ、ここに取り上げるほとんどのビデオコンテンツに対してコンテンツ自体よりデータの大きさが小さいことを表わす。スケジュールされたプッシュは、特定のスケジュール又はスケジュールポリシーに基づいて実行されるプッシュであり、通常は、コスト及び／又は他のネットワークアクティビティへの障害を最小にするように設計される。便利にも、これは、非ピーク時間中（夜通し）に実行されそしてシステムにわたって時間的に整合され、プッシュが全てのエッジサーバーに同時に試みられることはなく、時間にわたって分散されて、ピーク帯域巾のニーズ及びサーバー又は他のネットワークノードの負荷を減少することができる。
【００６５】
低分解能及び／又は短いビデオチップのようなコンテンツの派生バージョンを与えるか、又はコンテンツプレフィックス部分を与えることが任意であるが望ましい場合には、それらをメタデータの一部分として又は別のやり方でエッジサーバーへプッシュしてもよい。プレフィックスキャッシングを実行するための特定のシステム、方法及びコンピュータプログラムの実施形態を、以下に詳細に説明すると共に、参考としてここに取り上げる本発明の譲受人に譲渡された「Prefix Cashing For Media Objects」と題する０１／２９／０１に出願された出願中の米国特許出願第０９／７７４，２０４号にも説明されている。
【００６６】
別の任意の実施形態では、システム及び方法が、原点サーバー及びエッジサーバー以外の１つ以上のサーバー、例えば、１つ以上のディレクトリサーバーを備え又は使用するときには、コンテンツメタデータがディレクトリサーバーへもプッシュされる（ステップ２１０）。この構成は、基本的なシステム及び方法を最適化するものとして任意に与えられ、コンテンツアイテムが配置された全ての位置を識別するために問合せされる単一位置データ構造を与える。ディレクトリサーバーは、ネットワーク全体にわたり複数の位置で複写することができる。
【００６７】
次いで、メタデータがシステムにインストールされる。（メタデータは、ビデオ又は他のコンテンツを再インストールせずに、システムにインストールされ及び／又は更新されることに注意されたい。）スケジュールされたプッシュが実行されると、メタデータは、付加的なコンテンツ及びメタデータ変更を反映するように更新される（ステップ２１２）。
【００６８】
コンテンツ及びメタデータの両方がシステムに配置された後に、システムは、これらの変更に対して動作する。メタデータが、特定サーバーにおける変更を反映するように更新されるまで、これらのリモート位置は、新たなコンテンツ又は新たなコンテンツの位置或いはその両方に気付かないが、システムは、動作状態に保たれる。
【００６９】
メタデータをベースとする方法及びシステムとのこのハイブリッドな「プッシュ」及び「プル」は、従来のシステム及び技術に勝る多数の効果を有することに注意されたい。従来のプル方法では、メタデータが存在せず、コンテンツに関して追跡能力が得られない。ここに述べるシステムでは、メタデータのデータ記録が、種々の特性及びパラメータを追跡するためのフィールドを含み、例えば、本発明の実施形態は、コンテンツにアクセスしたユーザの数、コンテンツへのアクセスが拒絶されたユーザの数、アクセスの頻度、視聴の長さ等々の１つ又は組合せを追跡するためのフィールドを含むメタデータ記録を与える。このような情報は、次いで、データ採取目的で使用することができ、例えば、特定コンテンツのアクセスの頻度がプリセットスレッシュホールドを越える場合には、システムは、原点サーバー（又は他の何らかのサーバー）から残りのエッジサーバー（又は残りのエッジサーバーのあるサブセット）へのコンテンツの「プッシュ」を最終的に生じるオペレーションをトリガーすることができる。収集されたメタデータは、原点サーバー又は他のサーバーへリアルタイムで返送されるか、又はパッケージされて周期的に又は他の希望のスケジュールで送信される。この任意の追跡能力は、ユーザアクセスデータ（おそらくは個々のユーザデータであるが、より一般的には、ユーザのプライバシーを維持する上で重要な統計学的データ）を、エッジサーバーのメタデータ記録に記憶するか、或いはユーザアクセスデータを収集、集合及び／又は分析するように設計された外部位置に記憶する。通常、ユーザアクセスデータは、各エッジサーバーにおいて収集され、そして例えば、各コンテンツアイテムに対する要求者の数、要求が発せられた日時、要求とその要求が再生で満足されたときとの間の遅延時間、コンテンツプレフィックス情報が充分であるか過剰であるか、コンテンツが配送される前のユーザ切断の頻度、レーティング情報又はレーティング情報が導出されるところの情報、頻繁に要求されるコンテンツアイテム、頻繁に要求されるディレクトリのアイテム、並びにネットワークコンフィギュレーション及びコンテンツ配送を調整し、コンテンツ及びコンテンツフォーマットを選択し、さもなければ、性能を調整又は最適化する上で助けとなる他の情報を含むが、これらに限定されない。この収集されたユーザアクセス及び性能データ（それ自身メタデータの形式）は、記憶され、そして分析及び報告のための処理位置へプッシュされて戻される。この分析は、種々のデータ採取技術、統計学的分析、又は他の調整及び／又は最適化技術を含む。
【００７０】
収集、追跡及び分析の結果として、例えば、キャッシュ処理されたコンテンツプレフィックスの長さを短縮又は増加することによりプレフィックスの長さを変更するための判断がなされる。それとは別に又はそれに加えて、１つ又は選択された複数のコンテンツアイテムに対して全コンテンツアイテム（例えば、完全なビデオ）をプッシュ（即座にプッシュ又はスケジュールされたプッシュ）するための判断がなされる。これは、例えば、同じコンテンツアイテムが特定の時間ゾーン領域又は市場において同じタイムスロット内に要求されるといった他の領域における幾つかのトレンド（例えば、東部時間ゾーン領域又は市場において特定コンテンツアイテムに対して非常に多数の要求がある）をベースとするときに生じ得る。この形式のトレンドベースのプッシュは、ここでは領域プッシュと称され、例えば、帯域巾が非常に高価であるか又は容易に使用できないときに、その領域のエッジサーバーへコンテンツアイテムを後でプルする必要性を軽減する。この解決策を使用すると、サービスクオリティを明らかに高いレベルに維持することができる。
【００７１】
重要なポイントとして、本発明のシステム及び方法は、このユーザ及びシステム性能データを種々のやり方で収集、採取(mine)及び分析し、そして性能を変更し、調整しそして改善又は最適化すると共に運転コストを低減するのに使用することができる。又、これらの同じ技術及び情報エレメントの幾つかは、システムに入力されるか（例えば、ユーザ登録又は質問を経て）又はシステムにより導出されたあるユーザ特性、例えば、ユーザ要求者の時間ゾーン、コンピュータ又はネットワークアクセス特性、以前の選択経歴、ネットワーク識別子、又はエッジサーバーから導出できる他のパラメータに基づいて、コンテンツ及び配送パーソナル化のために使用することもできる。
【００７２】
原点サーバーが大量記憶能力を含み、全ての又は実質的に全てのコンテンツが少なくとも原点サーバーに得られるようにする幾つかの実施形態について説明した。これら及び他の実施形態は、特定のコンテンツに対する第１要求の後にエッジサーバーへコンテンツをキャッシュ処理するようにも構成される。このような場合に、エッジサーバーは、ユーザによりなされた全てのコンテンツダウンロード又は再生要求を取り扱うために比較的高い記憶容量をもつことも必要である。
【００７３】
充分に高い帯域巾及び利用性の通信チャンネルリンク又はパイプを原点サーバーとエッジサーバーとの間に有するネットワークの場合には、更に別の実施形態において、エッジサーバーにおける完全なコンテンツアイテム（例えば、全ビデオ）のローカルコンテンツ記憶又はキャッシングが排除又は実質的に排除される。むしろ、エッジサーバーへユーザ要求がなされると、エッジサーバーは、要求されたコンテンツを原点サーバーからプルし、そして充分な量の要求されたコンテンツが受け取られると、要求を発しているユーザへの再生を開始する。ネットワークは、ある所定の又は指定の確率でこのようなリアルタイム配送に対してリソースが入手できるように構成される。任意であるが、望ましくは、各コンテンツアイテムの初期部分即ちプレフィックス部分をキャッシングし、要求を発しているユーザへの再生を、ほとんど又は全く遅延なく開始することができる。プレフィックスの長さ又は再生巾は、特定のエッジサーバーによるコンテンツソース（例えば、原点サーバー或いはネットワークに分散された他のコンテンツサーバー又はキャッシュサーバー）へのコンテンツ要求に関連した測定及び／又は予想される遅延に基づいて調整される。
【００７４】
本発明の実施形態は、既存のネットワーク及びインターネットインフラストラクチャーに対して上述したように相互に動作して、本発明のシステム、方法又はコンピュータプログラムをサポートするためにこのようなインフラストラクチャーを変更する必要がないように構成されることが明らかである。又、既存のインターネット又はワールドワイドウェブインフラストラクチャーの異なる部分が、異なるデータレートをサポートし、異なる帯域巾、異なる信号特性を有し、そして異なる性能レベルをサポートすることも明らかである。
【００７５】
非常に高い帯域巾及び利用性のネットワーク接続が与えられる場合には、キャッシュ処理されたプレフィックスも排除できるが、他の実施形態では、短いプレフィックスを記憶することができる。
この形式のオペレーションは、一般に、ネットワーク及び記憶装置のバーチャル化と称される。その理由の一部は、ソース原点サーバーに関連した大容量記憶装置が、各エッジサーバーに対してある種のバーチャル記憶装置となるからである。単一ネットワークは、充分に高い帯域巾及び高い利用性のネットワーク接続がサポートされない場合にはエッジサーバーにローカル記憶をサポートし、そしてそれらが使用可能な場合にはバーチャル化をサポートすることが明らかである。
【００７６】
この説明に鑑み、当業者であれば、本発明のシステム及び方法は、メタデータを複数の位置へ配給し（例えば、原点サーバー及びエッジサーバー、或いは原点サーバー、エッジサーバー及びディレクトリサーバーへ：これは制御平面である）、制御平面で実施される情報を使用して複数の位置へコンテンツを配給するが、実際の配給経路は、データ経路とは異なることが明らかであろう。実際のコンテンツとは個別のメタデータを広範囲に使用することは、コスト効率の良いオペレーションを行えるだけでなく、コンテンツの実際の使用に関連したビジネスファンクションも実施できるようにする。これは、単一の非配給ディレクトリしか与えないと共に、メタデータを与えないか又は単一の位置にしかメタデータを与えない基地の従来のシステム及び方法とは異なる。
【００７７】
要求応答及び再生手順３００の実施形態について以下に説明する。ユーザは、コンテンツアイテム（例えばビデオＶ）に対する暗黙の又は明確な要求を、ウェブサイト、ポータル、又は他のネットワークアクセスポイントへ提出する（ステップ３０１）。このユーザは、ユーザ、ユーザ要求者又は単に要求者と称する。ネットワーク内のエンティティは、要求を受け取り、そしてこの受信エンティティがエッジサーバーでない場合には、それをエッジサーバーへ転送する。説明上、エッジサーバーは、ユーザから直接要求を受け取り、そして要求者とエッジサーバーとの間に実際に介在する他の中間物、サービスプロバイダー、ルーター等を無視する。
【００７８】
エッジサーバーは、ビデオＶに対するユーザ要求を受け取り（ステップ３０２）、そしてそのローカルディレクトリがビデオＶに対するディレクトリエントリーを含むかどうか決定する（ステップ３０４）。一実施形態では、ローカルディレクトリは、コンテンツの利用性、コンテンツに対する権利、等を指示するエントリーを記憶する。ユーザは、セットトップボックス或いは他の情報機器又はアクセス方法を経て自分のコンピュータ、ＴＶセットに表示されたビデオタイトルを選択すると、ビデオ（又は他のコンテンツアイテム）に対するＵＲＬ又は他のグローバルに独特の識別をネットワークへ本質的に送信する。ネットワークにおいて実施されるインテリジェンス（例えば、自分の地理的エリアの付近にあるエッジサーバーへのユーザの接近度）は、要求をそのサーバーに向けさせる。要求を受け取るエッジサーバーは、そのディレクトリを調べて、ビデオＶに対するメタデータがそのディレクトリにあるかどうか決定する（ステップ３０４）。メタデータが配置されている場合には、ビデオＶがエッジサーバー記憶装置に完全に記憶されたかどうか、ビデオＶがコンピュータのメインメモリ又は他の記憶装置内に現在キャッシュ処理されているかどうか、ビデオＶが部分的にしか入手できない（例えば、ビデオプレフィックスのみ）かどうか指示する。ビデオＶに対するメタデータしか入手できない場合には、ネットワークのどこで（例えば、ビデオＶの原点サーバー、又はビデオＶをフェッチしてそれを特定のエッジサーバーへサービスしようとする他のエッジサーバーにおいて）ビデオＶのコピーが入手できるか指示する。ビデオＶのメタデータが受信側エッジサーバーのディレクトリにないと決定される場合には、選択されたビデオＶに対して外部ディレクトリ（１つ又は複数）へ任意の問い合わせがなされる（ステップ３１２）。これらの外部ディレクトリは、例えば、１つ以上のエッジサーバー自体から選択されてもよいし、或いはとりわけ、ビデオの探索を容易にするために生成された独立したディレクトリでもよい（例えば、インターネットホストネーム分析を実施するドメインネームサービス）。
【００７９】
ビデオＶの最適位置に対するメタデータ情報がディレクトリの１つのある場合には、ビデオＶのソース位置が、以下に詳細に述べるように識別される（ステップ３２０）。それが入手できない場合には、問合せが失敗に終り（ステップ３１６）、任意であるが、ユーザに通知するのが望ましい。
ビデオＶが受信側エッジサーバーのディレクトリにあると決定された場合には、更に別の任意の決定がなされて、要求を発しているユーザ、又は要求を発しているユーザと共通の１つ以上の特性を有するユーザのグループが、ビデオＶにアクセスするのを許すべきかどうか決定される（ステップ３０６）。この任意のテストは、アクセス料金を支払ったユーザ、ネットワークへのユーザエントリーポイントに関連した特定の地域からアクセスするかしないか、一般的な権利の管理、他のルール、ポリシー、基準、リスト、推進されるイベント又は他のアクセス或いは許可ベースに関するものである。ユーザがアクセスを許可されない場合には、要求が失敗に終り（ステップ３０７）、ユーザには、要求されたビデオが入手できないか、或いはユーザがビデオを受け取る権利許可をもたないことが通知されるのが望ましい。この任意のテスト（ステップ３０６）が特定の実施形態において実行されない場合に、エッジサーバーで実行されるプロセスによりビデオＶが受信側エッジサーバーのディレクトリにあると決定されると、全ビデオＶがエッジサーバーの（自分の）ローカルキャッシュ又は記憶装置にあるかどうかについて更なる決定が行われる（ステップ３０８）。
【００８０】
それがエッジサーバーのローカルキャッシュにある場合には、エッジサーバーは、要求を発しているユーザへの要求されたビデオＶの再生を開始する（ステップ３１０）。システム、又はその要素、例えば、ビデオＶを再生するエッジサーバーは、そのエッジサーバーと、要求を発しているユーザとの間のネットワークリソースの利用性を確認し、及び／又はこのようなネットワークリソースを予約し（ステップ３０９）、ユーザへの配送又は再生が、サービスクオリティ要求の確立された再生最小要求に基づいて実行されるようにするのが効果的であるが、任意である。本発明のシステム及び方法の実施形態は、更に、要求されたサービスクオリティ（ＱＯＳ）要件を、使用可能なネットワークリソースにより（そして更に任意であるがビデオＶ自体のクオリティ及びフォーマットにより）満足できるかどうか決定し、このようなＱＯＳを満足できるときには、再生を許し、そしてこのようなＱＯＳを満足できないときには、再生を許さない（ステップ３１２）。再生におけるこの制約は、例えば、ビデオＶの所有者、Ｖの配給者（例えば、広告主）によって課せられ、ビデオメッセージの意図されたクオリティ及びプレゼンテーション効果が維持される。
【００８１】
一方、ビデオＶがエッジサーバーのキャッシュにあるかどうかの決定（ステップ３０８）が、それがキャッシュにないことを指示する場合には、エッジサーバーにローカル記憶されたメタデータに問合せすることによりビデオＶに対する別のソース位置が決められる（ステップ３２０）。或いは又、要求されたビデオＶを得るところのソース位置のこの識別は、ビデオＶのネットワーク接近性を考慮した最適なソース位置、考えられるソース位置から、問合せを行うエッジサーバーへビデオＶを移動するコスト、使用可能な経路、及びこれらの経路にわたる帯域巾等々のファクタを決定することによりインテリジェントなやり方で行われる。ソース識別及び選択に含まれる分析プロセスは、記憶されたメタデータを使用してエッジサーバーにおいてローカルで実行されてもよいし、或いはローカル記憶されたメタデータを用いる外部プロセス、又はその外部プロセスサーバーへ配給されてそこに記憶されたメタデータを使用するか、或いは記憶されたメタデータを使用する原点サーバー内で行われてもよい。好ましい実施形態では、選択は、記憶された現在メタデータを使用し、そして任意であるが好都合にも、ネットワークリソース利用性及び性能並びに使用コストを表わす他の情報又はデータを使用して、エッジサーバー内でローカルに行われる。
【００８２】
個別のディレクトリサーバー機能を与える本発明の実施形態では、要求されたビデオＶに対する最適なソース位置を探索することは、システムからメタデータ更新を受け取る個別のディレクトリサーバーを使用して行われる。
ビデオＶに対するソース位置（及び任意であるが考えられる位置のセットが与えられた場合には「最適な位置」）が識別されると（ステップ３２０）、識別されたソースサーバー及び要求を発しているエッジサーバーからビデオを配送するためにネットワークリソースが使用できるかどうかの判断が行われる。これらのリソースは、次いで、予約される（ステップ３２６）。充分なリソースが使用できずそして所定の（又は決定された）許容時間周期内に予約できないと決定された場合には、要求が失敗となり（ステップ３２４）、そしてその失敗の通知が要求者へ送られるか、又は新たなソースを識別する付加的な決定がなされる（ステップ３２０）。実際に、リソースが使用できるかどうかの決定（ステップ３２２）は、ソース位置を見つけるステップ（ステップ３２０）の一部分でもよいし、又は個別のステップでもよい。最良の又は最適なソース位置を識別するときに、使用可能なネットワークリソース、及び使用可能なネットワークリソースのサービスクオリティを考慮に入れるように合成される。他の実施形態では、これを個別の又は付加的なチェックとして実行するのが望ましいのは、ネットワークリソースの利用性が迅速に変化して、識別されたソース位置から、要求を発しているエッジサーバーへビデオＶのプルを開始する直前にチェックが行われる場合である（ステップ３２６）。
【００８３】
更に別の実施形態では、ビデオコンテンツに対するソース位置を見つけるためのステップは、複数のソース位置（一次ソースとして優先順に任意にランク付けされた）を見つけるためのもので、好ましい又は最適なソースに対するネットワークリソースが使用できない場合に、１つ以上の別のソースが既に決定され、そして別のソース位置に対するネットワークリソース利用性を、探索段階を繰り返さずに直ちに順次決定することができる。これは、動的なネットワーク条件の下で特に有益である。
【００８４】
ソース位置が識別されそしてネットワークリソース利用性が照合されると、エッジサーバーは、識別されたソース行先からビデオＶコンテンツをプリングし始める（ステップ３２８）。全てのビデオがソースからエッジサーバーへ通信されるのに、ある程度の時間周期を要するので、プロセスが開始されると、要求を発しているユーザへの再生を、受け入れられるやり方で開始して維持することができるに充分な量の要求されたビデオＶがあるかどうか決定される。受け入れられるかどうかの基準は、種々のやり方で確立されるが、例えば、再生が途切れず、所定の再生レートが維持され、設定ＱＯＳを与えるか、さもなければ、希望のビデオクオリティの維持を確立するようにセットされる。一般に、プルされる必要のあるビデオの量は、送信側ソースサーバーと受信側エッジサーバーとの間のネットワークリソースの性質、クオリティ及び利用性に依存する。典型的に、不充分に介在するネットワークリソースに必要とされる受信ビデオの量は、良好に介在するネットワークリソースの場合より多い。
【００８５】
充分なビデオコンテンツが受信されたと決定されると（ステップ３３０）、エッジサーバーから、要求を発しているユーザへの再生が開始される（ステップ３１０）。しかしながら、エッジサーバーは、全てのビデオＶコンテンツが受信されてエッジサーバーに対してローカルに記憶されるまで、識別されたソースからビデオコンテンツをプルし続けるか、さもなければ、収集し続ける。
【００８６】
本発明の一実施形態では、エッジサーバーは、別のソース位置からビデオＶの異なる部分を受信して、それらをエッジサーバーにおいて組み立てて、要求を発しているユーザへ中断なく再生することができる。この任意の特徴は、例えば、ビデオＶが特に長いとき、及びソース又はネットワークリソースのエレメントが送信中に使用できなくなった場合、例えば、故障の場合に、利用することができる。更に別の実施形態では、選択されたビデオＶを要求者へ配送する全コストを減少するように、ソース及びネットワークルートを変更することができる。例えば、この任意の操作手順のもとでは、初期転送を開始する必要があるときに費用の高い又は低速な経路しか使用できないが、送信中のその後の時間に費用の安い又は高速の経路が後で使用できるようになった場合に、ソース及び／又は配送経路を動的に変更し、その変更されたソースサーバー及び／又はネットワークリソース状態の利点を取り入れることができる。
【００８７】
全ビデオＶがエッジサーバーにより受信されると、エッジサーバー内のメタデータは、全ビデオＶが今やエッジサーバー内にキャッシュされたことを識別するように更新される（ステップ３３２）。他のエッジサーバーのメタデータは、同時に更新されるか、又はスケジュール更新の一部分として更新されるのが望ましいが、任意である。又、変更されたメタデータは、原点サーバーへ通信されてそこに記憶されるのが望ましいが、その後に他のエッジサーバーへ通信してそれにより記憶するために、原点サーバーがシステム全体にわたりメタデータを管理する役割を果たす程度までである。ディレクトリサーバーを備えた本発明の実施形態では、変更されたメタデータ（又はメタデータにおける特定の変更の指示）は、ディレクトリサーバーへ通信されて記憶される。
【００８８】
上記手順は、任意のコンテンツプレフィックスキャッシング、例えば、ビデオプレフィックスキャッシングを使用しない本発明のシステム及び方法の実施形態について説明されたことが明らかである。このようなビデオプレフィックスキャッシングが与えられるときには、各エッジサーバーは、ビデオＶの初期再生部分を記憶し、そしてソース位置からプルされるべきビデオコンテンツの充分な部分に対して早い時間に待機せずに再生を開始することができる。これら実施形態では、ビデオＶが識別された直後に、ソースから充分なビデオＶがプルされるのを待機せずに、再生が開始される。正確な時点は、一般に、エッジサーバーにキャッシュされるプレフィックスの量又は長さと、全ビデオに対して使用可能なソースを探索し、その識別されたソース間にネットワークリソースを予約し、そしてビデオＶを行先エッジサーバーへ通信するのに要求される予想時間とに依存する。一実施形態では、目的とするところは、再生を（もしあっても）短時間だけ遅延して、キャッシュ処理されたビデオプレフィックスが完全に再生されるか又は尽きる前に、連続した途切れのない再生をサポートするために充分なビデオがソースから受け取られるようにすることである。決定論的又は統計学的モデルを使用して、この目的を達成するようにシステム、方法及び手順が調整される。
【００８９】
ここに述べる他の実施形態は、ビデオコンテンツがエッジサーバーにローカルで記憶されないモデル、又はビデオコンテンツのプレフィックス部分のみがエッジサーバーに記憶されるモデルに関するものであり、そしてシステム及び方法は、高帯域巾及び高利用性ネットワークリソースを経て行われる後要求通信に依存するものである。これら実施形態では、上述した手順３００は、位置が分かるので特定の位置におけるビデオＶの存在に対して問合せが必要とされないが、ネットワークリソースの識別を大きく強調するある状況においては、大容量接続を経てのリモート記憶装置へのアクセス及びバーチャル化をサポートするように変更されてもよい。
【００９０】
本発明の多数の実施形態を上述したが、多くの説明は、特定形式のコンテンツ、即ちビデオコンテンツ、そしてより詳細には、比較的大きなもので、コンテンツの異なるセグメント間に時間同期又はアイソクロノス配送を維持することが再生に必要とされるビデオ映画又は他のビデオコンテンツに向けられたことに注意されたい。これは、大きくもなくアイソクロノス配送も必要としない従来のウェブページとは異なる形式のコンテンツであることに注意されたい。本発明は、ビデオのみに限定されるものではなく、本発明のシステム及び方法は、アイソクロノス再生又は配送及び大きなファイルサイズが問題となる現存する又は将来開発される他のコンテンツ形式にも適用できることが明らかであろう。
【００９１】
以上、好ましい実施形態及び最良の態様を説明したが、特許請求の範囲に規定された本発明の範囲内で種々の変更や修正がなされ得ることが明らかであろう。
【図面の簡単な説明】
【００９２】
【図１】原点サーバー及びエッジサーバーのネットワークを使用する公知システムのブロック図である。
【図２】キャッシュサーバーのネットワークを使用する公知システムのブロック図である。
【図３】グローバルなコンピュータネットワークに配備される本発明のシステムの実施形態を示すブロック図である。
【図４】本発明のコンテンツ配給方法を実施するためのコンピュータプログラム命令を実行するエッジサーバーの実施形態のブロック図である。
【図５】本発明のシステムに関連して使用されるコンピュータの主たる要素のブロック図である。
【図６】要求を発しているユーザにビデオコンテンツを配送するための手順の実施形態を示すフローチャートである。
【図１】
2004533738.tif 000003
【図２】
2004533738.tif 000004
【図３】
2004533738.tif 000005
【図４】
2004533738.tif 000006
【図５】
2004533738.tif 000007
【図６】
2004533738.tif 000008
【国際公開パンフレット】
2004533738.tif 000009
2004533738.tif 000010
2004533738.tif 000011
2004533738.tif 000012
2004533738.tif 000013
2004533738.tif 000014
2004533738.tif 000015
2004533738.tif 000016
2004533738.tif 000017
2004533738.tif 000018
2004533738.tif 000019
2004533738.tif 000020
2004533738.tif 000021
2004533738.tif 000022
2004533738.tif 000023
2004533738.tif 000024
2004533738.tif 000025
2004533738.tif 000026
2004533738.tif 000027
2004533738.tif 000028
2004533738.tif 000029
2004533738.tif 000030
2004533738.tif 000031
2004533738.tif 000032
2004533738.tif 000033
2004533738.tif 000034
2004533738.tif 000035
2004533738.tif 000036
2004533738.tif 000037
2004533738.tif 000038
2004533738.tif 000039
2004533738.tif 000040
2004533738.tif 000041
2004533738.tif 000042
2004533738.tif 000043
2004533738.tif 000044
2004533738.tif 000045
2004533738.tif 000046
2004533738.tif 000047
2004533738.tif 000048
2004533738.tif 000049
2004533738.tif 000050
2004533738.tif 000051
2004533738.tif 000052
2004533738.tif 000053
2004533738.tif 000054
2004533738.tif 000055
2004533738.tif 000056
2004533738.tif 000057
2004533738.tif 000058
2004533738.tif 000059
2004533738.tif 000060
【国際公開パンフレット（コレクトバージョン）】
2004533738.tif 000061
2004533738.tif 000062
【国際調査報告】
2004533738.tif 000063
2004533738.tif 000064