(57)【特許請求の範囲】
【請求項１】
１または複数のコンピューティングデバイスを用いて、拡張可能コンテンツ配信プラットフォームを提供する方法であって、
コンテンツ配信ネットワークのコンテンツ配信プロセスの複数の離散イベントを識別する段階と、
コンピュータシステムを用いて、前記コンテンツ配信ネットワークの前記コンテンツ配信プロセスの前記複数の離散イベントのうちの少なくとも１つが生じると、複数のオブジェクトに適用する論理アクションフローを提供するプログラムデータを提供する段階と
を備え、
前記方法は、
コンピュータシステムを用いて、前記コンテンツ配信ネットワークのコアエンジンにおける前記複数の離散イベントの受信を識別する段階であって、前記コアエンジンは、複数のイベントの種類の処理のためにインスタンス化され利用可能な前記複数のオブジェクトを含む構造化されたオブジェクトモデルを有する段階と、
前記複数のイベントの種類を識別する規則セットに含まれる規則を、前記離散イベントのために用いる段階と、
用いた前記規則とユーザが要求する前記離散イベントの処理とに基づいて、前記離散イベントを処理するカスタマイズ可能なモジュールを選択する段階と、
を有し、
前記選択されたモジュールは、前記コアエンジンの前記複数のオブジェクトのうちの少なくとも１つを用いて、前記離散イベントを実行し、
前記複数のオブジェクトは、前記複数の離散イベントの処理のためにインスタンス化され利用可能であり、
前記複数の離散イベントを識別する段階は、前記複数の離散イベントを識別するために、構造化されたイベントモデルを利用する段階を有し、
前記識別する段階、および、前記プログラムデータを提供する段階は、コンテンツ配信ネットワークのキャッシュサーバ内で実行され、
前記構造化されたイベントモデルは、複数のイベントの順序を定め、前記複数のイベントは、
接続構築と、
要求受信と、
キャッシュ内にリソースが見つかることと、キャッシュ内にリソースが見つからないことと、
キャッシュ充填要求準備と、キャッシュ充填要求送信と、キャッシュ充填完了と、
応答送信準備と、応答開始と、応答完了と、応答失敗と、
接続することと、接続成功と、接続失敗と、
を含む、方法。
【請求項２】
前記複数の離散イベントを識別する段階は、
前記複数の離散イベントを識別するために、少なくとも１つの規則を利用する段階を有する請求項１に記載の方法。
【請求項３】
前記プログラムデータは、前記複数の離散イベントで実行する基礎関数セットを有する請求項１または２に記載の方法。
【請求項４】
前記コアエンジンは、前記複数のオブジェクトに対する基礎関数セットを実行する請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記論理アクションフローは、ユーザが定義することが可能なモジュールの実行を含む請求項１から４のいずれか一項に記載の方法。
【請求項６】
キャッシュサーバであって、
キャッシュサーバのプロセッサで実行を行うコアエンジンを備え、
前記コアエンジンは、
コンテンツ配信ネットワークのコンテンツ配信プロセスの複数の離散イベントのうちの少なくとも１つが生じると、複数のオブジェクトに適用する論理アクションフローを提供するプログラムデータを有し、
前記キャッシュサーバは、
複数のイベントの種類の処理のためにインスタンス化され利用可能な前記複数のオブジェクトを含む構造化されたオブジェクトモデルを含む、前記コンテンツ配信ネットワークのコアエンジンを含み、
前記コアエンジンは、
コンテンツ配信プロセスにおける前記離散イベントの受信を識別し、
複数のイベントの種類を識別する規則セットに含まれる規則を、識別した前記離散イベントのために用い、
用いた前記規則とユーザが要求する前記離散イベントの処理とに基づいて、前記離散イベントを処理するカスタマイズ可能なモジュールを選択し、
前記選択されたモジュールは、前記コアエンジンの前記複数のオブジェクトのうちの少なくとも１つを用いて、前記離散イベントを実行し、
前記複数の離散イベントは、構造化されたオブジェクトモデルによって識別され、
前記複数のオブジェクトは、前記複数の離散イベントの処理のためにインスタンス化され利用可能であり、
前記キャッシュサーバは、コンテンツ配信ネットワークのキャッシュサーバであり、識別することと、前記プログラムデータを提供することのオペレーションを実行し、
前記構造化されたイベントモデルは、複数のイベントの順序を定め、前記複数のイベントは、
接続構築と、
要求受信と、
キャッシュ内にリソースが見つかることと、キャッシュ内にリソースが見つからないことと、
キャッシュ充填要求準備と、キャッシュ充填要求送信と、キャッシュ充填完了と、
応答送信準備と、応答開始と、応答完了と、応答失敗と、
接続することと、接続成功と、接続失敗と、
を含む、キャッシュサーバ。
【請求項７】
前記論理アクションフローは、ユーザが定義することが可能なモジュールの実行を含む請求項６に記載のキャッシュサーバ。
【請求項８】
前記コアエンジンは、前記複数の離散イベントにおける基礎関数セットを実行する請求項６または７に記載のキャッシュサーバ。
【請求項９】
前記コアエンジンは、前記複数のオブジェクトに対する基礎関数セットを実行する請求項６から８のいずれか一項に記載のキャッシュサーバ。
【請求項１０】
前記コアエンジンは、イベントベースのアプリケーションプログラミングインタフェースを有する請求項６から９のいずれか一項に記載のキャッシュサーバ。
【請求項１１】
前記イベントベースのアプリケーションプログラミングインタフェースは、既存の規則ベースの周りに構築されるラッパーアプリケーションプログラミングインタフェースを含む請求項１０に記載のキャッシュサーバ。
【請求項１２】
キャッシュサーバであって、
キャッシュサーバのプロセッサで実行を行うコアエンジンを備え、
前記コアエンジンは、
コンテンツ配信ネットワークのコンテンツ配信プロセスの複数の離散イベントを識別する規則セットと、
前記コンテンツ配信ネットワークの前記コンテンツ配信プロセスの前記複数の離散イベントのうちの少なくとも１つが生じると、複数のオブジェクトに適用する論理アクションフローを提供するプログラムデータと
を有し、
前記キャッシュサーバは、
複数のイベントの種類の処理のためにインスタンス化され利用可能な前記複数のオブジェクトを含む構造化されたオブジェクトモデルを含む、前記コンテンツ配信ネットワークのコアエンジンを含み、
前記コアエンジンは、
コンテンツ配信プロセスにおける前記離散イベントの受信を識別し、
複数のイベントの種類を識別する前記規則セットに含まれる規則を、識別した前記離散イベントのために用い、
用いた前記規則とユーザが要求する前記離散イベントの処理とに基づいて、前記離散イベントを処理するカスタマイズ可能なモジュールを選択し、
前記選択されたモジュールは、前記コアエンジンの前記複数のオブジェクトのうちの少なくとも１つを用いて、前記離散イベントを実行し、
前記複数のオブジェクトは、前記複数の離散イベントの処理のためにインスタンス化され利用可能であり、
前記複数の離散イベントは、構造化されたイベントモデルによって識別され、
前記キャッシュサーバは、コンテンツ配信ネットワークのキャッシュサーバであり、識別することと、前記プログラムデータを提供することのオペレーションを実行し、
前記構造化されたイベントモデルは、複数のイベントの順序を定め、前記複数のイベントは、
接続構築と、
要求受信と、
キャッシュ内にリソースが見つかることと、キャッシュ内にリソースが見つからないことと、
キャッシュ充填要求準備と、キャッシュ充填要求送信と、キャッシュ充填完了と、
応答送信準備と、応答開始と、応答完了と、応答失敗と、
接続することと、接続成功と、接続失敗と、
を含む、キャッシュサーバ。
【請求項１３】
前記論理アクションフローは、ユーザが定義することが可能なモジュールの実行を含む請求項１２に記載のキャッシュサーバ。
【請求項１４】
前記コアエンジンは、前記複数の離散イベントにおける基礎関数セットを実行する請求項１２または１３に記載のキャッシュサーバ。
【請求項１５】
前記コアエンジンは、前記複数のオブジェクトに対する基礎関数セットを実行する請求項１２から１４のいずれか一項に記載のキャッシュサーバ。
【請求項１６】
前記コアエンジンは、イベントベースのアプリケーションプログラミングインタフェースを有する請求項１２から１５のいずれか一項に記載のキャッシュサーバ。
【請求項１７】
前記イベントベースのアプリケーションプログラミングインタフェースは、既存の規則ベースの周りに構築されるラッパーアプリケーションプログラミングインタフェースを含む請求項１６に記載のキャッシュサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、「拡張可能プログラミングフレームワークを有するキャッシュサーバ」なる名称で２００９年９月１０日に提出された米国仮特許出願第６１／２４１，３０６号明細書、および、「拡張可能プログラミングフレームワークを有するキャッシュサーバ」なる名称で２０１０年７月１４日に提出された米国特許出願第１２／８３６，４１８号明細書の優先権を主張しており、各々をここに全ての目的で参照により組み込む。
【０００２】
ここに開示する実施形態は、コンテンツ配信ネットワーク用の拡張可能コンテンツ配信プラットフォームに関する。
【背景技術】
【０００３】
近年のインターネットの成長は目覚しいものがある。インターネットにおけるコンテンツの種類およびソースもまた成長している。例えば、コンピュータユーザは、仕事、娯楽、教育その他の目的で、ビデオ、オーディオ、マルチメディア、その他の種類のコンテンツのダウンロードのためにインターネットにアクセスすることも多い。今日では、ユーザは、スポーツイベント等のイベントをライブで見ることができ、ビデオおよび画像といった格納されているコンテンツを見ることもできる。このようなコンテンツのプロバイダは通常の場合、コンテンツの視聴方法および視聴者について一定のレベルの制御権を有したいと思うものである。例えば、ビデオプロバイダは、あるビデオ（例えば選択されたビデオ、またはある種類またはクラスのビデオ）を配信する際に暗号化しようとすることがある。通常、ユーザはコンテンツをオンデマンドで欲しがり、ダウンロードに時間をかけずに早くコンテンツを見たいと思うものである。コンテンツの種類によっては、他よりもダウンロードに時間がかかるものがある。例えば映画のなかには、利用されるダウンロード技術および映画ファイルのサイズによって、ダウンロードに数分から数時間を要するものがある。
【０００４】
通常、インターネットコンテンツのプロバイダは、コンテンツを配信するインフラストラクチャを提供するネットワークプロバイダとは別の実体であることが多い。非常に多い顧客にサービス提供するためにコンテンツプロバイダは、通常はコンテンツを配信するための大きなネットワークインフラストラクチャを所有するコンテンツ配信ネットワークプロバイダのサービスを購入する必要がある。しかし、コンテンツプロバイダは配信についての制御権を持たないことが多いために、彼らのコンテンツの配信方法および配信先に対する制御は限られたものとなる。
【０００５】
キャッシュサーバは、コンテンツ配信ネットワーク内で、ユーザアクセス用のコンテンツを一時保存するサーバとして機能する、専用のネットワークサーバまたはサービスである。キャッシュサーバは、データへのアクセスを高速化し、同時に、企業の帯域幅に対する負荷を軽減する。さらにキャッシュサーバは、コンテンツサーバがオフラインであったり利用不可能であったりする場合にも、コンテンツ（リッチ・メディアファイルまたはその他のドキュメント等）へのユーザのアクセスを可能とする。
【０００６】
キャッシュサーバはフィーチャ・リッチな場合がある。フィーチャが複雑であり、ときとして互いに依存しあっていたり、スタイルおよび構成が、まちまちであったりする場合もある。従来のキャッシュサーバのフィーチャは、ユーザを記述したり、文書化したり、トレーニングしたり、と難しかった。新しいフィーチャについては、コードを大幅に変更する必要があり、これにより、リードタイムが延びたり、コードが複雑化したり、サイクルをテストしたりバグを修正したりする必要が出てきた。新しいフィーチャは柔軟に実装されることも多く（そのほうが、複数のユーザ、設定シナリオが考えられる場合には合理的である）、これによりさらに解決法の複雑性が増す。
【発明の概要】
【０００７】
アプリケーションおよびサービスを、基礎サービスコンテンツの周りに構築（built around）することのできる拡張可能コンテンツ配信プラットフォームが提供される。適格なリッチ・メタデータおよび「メタコード」を、一貫した、プログラミングによる方法で、コンテンツおよび／または要求と関連付けることができる。例示的な実施形態では、アプリケーションおよびサービス（例えばモジュールおよび／またはスクリプト）を、生じるイベント（例えば、コンテンツの要求処理中に生じるイベント）に基づいて実行する。イベントは、複数の異なる方法で特定することができる。例えば一実装例では、一式の規則を利用して、アプリケーションおよび／またはサービスを特定して実行する１以上のイベントを特定する。別の実装例では、システムが、構造化された「イベント」モデル、プリミティブ関数、および、言語構造を提供することで、コアコードに対する変更を必要とせずに柔軟な方法で活用可能なサービス層を生成することができる。
【０００８】
このようなシステムの１つの具体的な実装例では、「ラッパー」が、既存の規則に基づく他の設定テーブルの周りに、既存の技術を大規模に置き換える必要なく、構築される。この実装例では、「ラッパー」によって、システムは、既存のキャッシュサーバの基礎機能に、論理的に表すことができる方法でアクセスすることのできる一貫した、単一のインタフェースとして提示される。
【０００９】
本発明の拡張可能コンテンツ配信プラットフォームは、コードの複雑性が低く保守がより容易である。コアコードは、コアコードを変更することによるのではなく、コアの基礎オペレーティングサービスを利用することにより構築可能な既存および将来のフィーチャをサポートする、基礎オペレーティングサービスセットを提供する。これらの一実装例では、コアの基礎オペレーティングサービスは、オブジェクトキャッシング、命令解釈、命令実行等を含む。
【００１０】
一実施形態では、拡張可能コンテンツ配信プラットフォームはさらに、コアコードを変更せずに、柔軟な実装が可能となる（例えば、高度な（enriched）拡張性、カスタマイズ、アプリケーション集積の可能性の面で）。このような拡張可能コンテンツ配信プラットフォームを利用することで、開発者は、プラットフォーム上に実質的に無制限にアプリケーションを生成することができるようになる。
【００１１】
一実装例では、拡張可能コンテンツ配信プラットフォームは、（１）構造化されたイベントモデル、（２）構造化されたオブジェクトモデル、（３）一式の基礎機能またはアクション、および、（４）基礎プログラミング文法を含む。この実装例では、構造化されたイベントモデルは、コンテンツの受信、処理、およびサービス提供要求のための一貫した記述ドキュメントプロセスを含む。ある処理パイプラインにおける離散した複数の（discrete number）「イベント」は、様々なアクションをとる可能性のあるコンテンツ配信プロセスにおける「アクションポイント」を提供している（例えばカスタムされた論理により）。従ってイベントモデルは、固定化した規則に基づくシステムではなくて、より流動性のあるイベントによる枠組みを提供する。
【００１２】
構造化されたオブジェクトモデルは、一連のオブジェクトをインスタンス化する。一実施形態では、例えば、様々な一貫した特性および／または属性を取得および／または操作するために定義された、要求、リソース、応答、その他の「オブジェクト」を定義している。
【００１３】
基礎機能またはアクションは、離散したイベントにおいて、または様々なオブジェクトに対して実行される機能またはアクションを提供する。例えば一実施形態では、機能またはアクションは、ストリングのパースおよび／または操作、ハイパーテキスト転送プロトコル（ＨＴＴＰ）メッセージ構築および／または分解、リソース操作等の処理を含む。
【００１４】
一実施形態では、イベントが生じると、基礎プログラミング文法を利用してオブジェクトに対して論理アクションフローを生成する。プログラミング文法の例としては、ウェブ開発言語（ＰＨＰ、Ｐｙｔｈｏｎ、Ｊａｖａｓｃｒｉｐｔ、Ｐｅｒｌ等）、または、「ｓａｆｅ」の制限セットその他の制限された機能を提供する特別なサブセットのいずれかといった、リッチなものも含まれる。
【００１５】
他の実装例も記載され請求されている。
【図面の簡単な説明】
【００１６】
【図１】様々な実施形態における拡張可能コンテンツ配信プラットフォーム内にコンテンツを配信するのに適したネットワーク環境の一例を示す。
【００１７】
【図２】様々な実施形態における拡張可能コンテンツ配信プラットフォーム内にコンテンツを配信するための機能モジュールの形態でシステムを示す。
【００１８】
【図３】様々な実施形態におけるストリーミングキャッシュモジュールの可能性のある実装例を示す機能モジュール図である。
【００１９】
【図４】様々な実施形態における、ストリーミングキャッシュモジュールが入る可能性のある状態のセットを示す状態図である。
【００２０】
【図５】ストリーミングコンテンツのプロセスの例を示すフローチャートである。
【図６】ストリーミングコンテンツのプロセスの例を示すフローチャートである。
【図７】ストリーミングコンテンツのプロセスの例を示すフローチャートである。
【００２１】
【図８】様々な実施形態における拡張可能コンテンツ配信プラットフォーム内にコンテンツを配信するのに適したネットワーク環境の別の一例を示す。
【００２２】
【図９】様々な実施形態における拡張可能コンテンツ配信プラットフォーム内にコンテンツを配信するのに適したネットワーク環境のまた別の一例を示す。
【００２３】
【図１０】コンテンツ配信ネットワークのキャッシュサーバ内に実装される拡張可能プログラミングフレームワークの一例を示す。
【００２４】
【図１１】構造化されたコンテンツ配信イベントモデルの一例のブロック図を示す。
【００２５】
【図１２】ここに記載する実施形態におけるコンテンツストリーミングアプリケーションおよびプロセスとともに構成されるコンピュータシステムのブロック図の一例を示す。
【発明を実施するための形態】
【００２６】
ここに開示する実施形態は、コンテンツ配信ネットワーク用の、拡張可能コンテンツ配信プラットフォームに関する。
【００２７】
図１は、様々な実施形態における拡張可能コンテンツ配信プラットフォームをサポートする、コンテンツを配信するのに適したネットワーク環境１００の一例を示す。コンピュータユーザは、コンピューティングデバイス（例えばデスクトップコンピュータ１０４）を利用して、コンテンツ配信ネットワーク（ＣＤＮ）１０２にアクセスすることができる。ＣＤＮ１０２は、図面の都合上単一のネットワークとして示されているが、以下で詳述するような実際の処理においては、ＣＤＮ１０２は通常は１以上のネットワークを含んでよい。
【００２８】
例えばネットワーク１０２は、サービスプロバイダネットワーク、大規模プロバイダネットワーク、および中間ネットワークのうちの１以上を表している。ユーザコンピュータ１０２は、デスクトップコンピュータとして示されているが、ユーザは、ネットワーク１０２にアクセスするために、数多くの異なる種類のコンピューティングデバイスのうちの任意のものを利用することができる（これらに限定はされないが、ラップトップコンピュータ、ハンドヘルドコンピュータ、携帯情報端末（ＰＤＡ）、または携帯電話等）。
【００２９】
ネットワーク１０２は、コンピュータ１０４にコンテンツを提供し、ネットワーク環境１００の拡張可能コンテンツ配信プラットフォームをサポートする機能を有する。コンテンツは、ビデオ、オーディオ、画像、テキスト、マルチメディアといった任意の数多くの種類のコンテンツ、または、その他の任意の種類の媒体であってよい。コンピュータ１０４は、コンピュータ１０４にダウンロードされたコンテンツを受信、処理、および提示するアプリケーションを含む。例えばコンピュータ１０４は、インターネット閲覧アプリケーション（例えばＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）またはＦｉｒｅｆｏｘ（登録商標））およびストリーミングメディアプレーヤ（例えばＦｌａｓｈ  Ｍｅｄｉａ  Ｐｌａｙｅｒ（登録商標）またはＱｕｉｃｋｔｉｍｅ（登録商標））を含んでよい。コンピュータ１０４のユーザが、特定のコンテンツアイテムへのリンク（例えばハイパーリンク）を選択する場合、該ユーザのウェブ閲覧アプリケーションは、該リンクに関連付けられたコンテンツを取得できるネットワークアドレス（例えばインターネットプロトコル（ＩＰ）アドレス）を送るようディレクトリサーバに依頼する要求を、ディレクトリサーバ１０６へと送信する。
【００３０】
一部の実施形態では、ディレクトリサーバ１０６は、ＩＰアドレスに対して、英数字のドメインネームを決定するドメインネームシステム（ＤＮＳ）である。ディレクトリサーバ１０６は、関連するネットワークアドレスに対してリンク名（例えばユニバーサルリソースロケータ（ＵＲＬ））を決定してから、コンピュータ１０４に対して、該コンピュータ１０４が、選択されたコンテンツアイテムを取得することができるネットワークアドレスを通知する。コンピュータ１０４がネットワークアドレスを受信すると、コンピュータ１０４は、ディレクトリサーバ１０６が供給するネットワークアドレスに関連付けられているコンピュータ（例えばストリーミングサーバコンピュータ１０８）等に、選択されたコンテンツアイテムの要求を送信する。
【００３１】
示されている特定の実施形態では、ストリーミングサーバコンピュータ１０８は、ＣＤＮ１０２のエッジサーバ（またはキャッシュサーバ）である。エッジサーバコンピュータ１０８は、ネットワーク１０２に多かれ少なかれ戦略的に配置されて、１以上のパフォーマンス関連の目的（例えば、相互接続ネットワーク上の負荷を低減する、キャパシティ、スケーラビリティの制限を解く、配信コストを下げる）を達成することができる。例えばエッジサーバ１０８は、別のサーバから生じるコンテンツをキャッシングして、キャッシングされたコンテンツを、エンドユーザにとって地理的または論理的により近接した位置で利用可能にすることができる。このようなエッジサーバ１０８の戦略的配置により、ユーザコンピュータ１０４ではコンテンツのダウンロードが短時間ですむようになる。
【００３２】
エッジサーバコンピュータ１０８は、要求者に対して、要求されたコンテンツを提供するよう構成されている。ここで利用する「要求者」という用語は、コンテンツを要求する可能性のある任意の種類の実体を含むことができ、エンドユーザコンピュータであっても中間デバイスであってもよい。従って要求者は、ユーザコンピュータ１０４であってもよいし、エッジサーバコンピュータ１０８に対してコンテンツを要求する、別のコンピュータ、ルータ、ゲートウェイ、または、スイッチ（不図示）であってもよい。容易に理解されるだろうが、コンピュータ１０４が生成する要求は、通常は、ルータまたはその他のデバイス間の複数の「ホッピング」によるルーティングを経て、エッジサーバコンピュータ１０８に到達する。従って、コンテンツの要求者とは、エッジサーバコンピュータ１０８に通信可能に連結された任意の複数のデバイスであってよい。
【００３３】
要求されているコンテンツを提供する機能の一環として、エッジサーバコンピュータ１０８は、要求者が要求しているコンテンツが、エッジサーバコンピュータ１０８自身内でローカルに入手可能であるかを判断することができる。一実施形態では、要求されているコンテンツがキャッシュ内にローカルに格納されており陳腐ではない場合に、入手可能である、とする。特定の実装例では、陳腐である状態とは、通常は「生存期間（time-to-live）」値が指定する所定の期間をコンテンツが過ぎた状態のことであるが、他の測定値を利用することもできる。エッジコンピュータサーバ１０８は、Ｆｌａｓｈ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ（登録商標）（ＦＭＳ）またはＷｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ  Ｓｅｒｖｅｒ（登録商標）（ＷＭＳ）等のメディアストリーミングサーバソフトウェアで構成される。従って、要求されているコンテンツがエッジコンピュータサーバ１０８にローカルに格納されており、キャッシュされているコンテンツが陳腐ではない場合、メディアストリーミングソフトウェアは、要求されているコンテンツを要求者（この場合にはコンピュータ１０４）にストリーミングすることができる。
【００３４】
エッジサーバコンピュータ１０８が、要求されているコンテンツが入手可能ではないと判断する場合には（例えば、ローカルに格納されていない、または陳腐である場合）、エッジサーバコンピュータ１０８は、要求を叶えるための救済策をとる。コンテンツがローカルに格納はされているものの陳腐である場合には、救済策としては、コンテンツを有効にし直すことが考えられる。コンテンツがローカルに格納されていない場合、または、有効にし直すことができなかった場合（陳腐であるコンテンツの場合）には、エッジサーバコンピュータ１０８は、要求されているコンテンツを別のソース（メディアアクセスサーバ等）から取得するよう試みる。メディアアクセスサーバ（ＭＡＳ）は、要求されているコンテンツを提供することができるサーバコンピュータである。
【００３５】
エッジサーバ１０８は、拡張可能コンテンツ配信プラットフォームを提供する拡張可能コンテンツ配信プラットフォーム（例えばイベントベースのアプリケーションプログラミングインタフェース（ＡＰＩ））を含む。拡張可能コンテンツ配信プラットフォームは、サービス提供される基礎コンテンツの周りに構築されるアプリケーションおよびサービスを提供する。適格なリッチ・メタデータおよび「メタコード」を、一貫した、プログラミングによる方法で、コンテンツおよび／または要求と関連付けることができる。一実装例では、システムが、構造化された「イベント」モデル、構造化されたオブジェクトモデル、プリミティブ関数、および、言語構造を提供することで、コアコードに対する変更を必要とせずに柔軟な方法で活用可能なサービス層を生成することができる。
【００３６】
このようなシステムの１つの具体的な実装例では、ＡＰＩ「ラッパー」が、既存の規則ベースおよび他の設定テーブルの周りに、既存の技術を大規模に置き換える必要なく構築される。この実装例では、「ラッパー」によって、システムは、既存のエッジ／キャッシュサーバの基礎機能に、論理的に表すことができる方法でアクセスすることのできる一貫した、単一のインタフェースとして提示される。
【００３７】
本発明の拡張可能コンテンツ配信プラットフォームは、コードの複雑性が低く保守がより容易である。コアコードは、コアコードを変更することによるのではなく、コアの基礎オペレーティングサービスを利用することにより構築可能な既存および将来のフィーチャをサポートする、基礎オペレーティングサービスセットを提供する。これらの一実装例では、コアの基礎オペレーティングサービスは、オブジェクトキャッシング、命令解釈、命令実行等を含む。
【００３８】
例えば特定の実装例では、ジオＩＰサービスがプラットフォーム内にプリミティブ関数としてインスタンス化される。この実装例では、入ってくるＩＰアドレスを、そのＩＰアドレスに関する様々な地理的その他のコードのデータベースへの鍵として利用することができる。データベースまたはルックアップテーブルは、導出するコードをより高いレベルのプログラムモジュールに曝して、コンテンツへのアクセスの制限または許可、コンテンツの代替例としてのサービス提供（serving alternate variants of content）等の他の機能で利用することのできるシステム「プリミティブ」関数として機能することができる。
【００３９】
一実施形態では、拡張可能コンテンツ配信プラットフォームはさらに、コアコードを変更せずに、柔軟な実装が可能となる（例えば、高度な（enriched）拡張性、カスタマイズ、アプリケーション集積の可能性の面で）。この実施形態では、開発者は、プラットフォーム上に実質的に無制限にアプリケーションを生成することができるようになる。
【００４０】
例示されている実施形態では、コンテンツ配信サーバコンピュータ１１０とコンテンツ配信元サーバ１１２という２つの可能性のあるメディアアクセスサーバが示されている。コンテンツ配信元サーバ１１２は、コンテンツプロバイダのサーバコンピュータである。コンテンツプロバイダは、ネットワーク１０２を運営するコンテンツ配信サービスプロバイダの顧客であってよい。配信元サーバ１１２は、コンテンツプロバイダネットワーク１１４に常駐していてよい。
【００４１】
一部の実施形態では、コンテンツ配信元サーバ１１２は、仮想ホスティングをサポートするＨＴＴＰサーバである。このように、コンテンツサーバは、様々な媒体およびコンテンツリソースのための複数のドメインをホスティングするよう構成することができる。処理の一例においては、ＨＴＴＰ  ＨＯＳＴヘッダが、送信元サーバ１１２に、ＨＴＴＰ  ＧＥＴ要求の一環として送られてよい。ＨＯＳＴヘッダは、発信元サーバ１１２がホスティングする、要求されたコンテンツのホストに対応している特定のドメインを特定することができる。
【００４２】
コンテンツ配信サーバ１１０は、通常は、コンテンツ配信ネットワーク１０２内のサーバコンピュータである。コンテンツ配信サーバ１１０は、コンテンツ配信元サーバ１１２との間に論理上介在して、コンテンツがコンテンツサーバ１１０を経由してエッジサーバコンピュータ１０８に配信されるようにしてよい。コンテンツ配信サーバ１１０はさらに、コンテンツキャッシングを利用することができる。
【００４３】
一部の実施形態では、エッジサーバコンピュータ１０８は、ディレクトリサーバ１０６、または、その他の、コンテンツを提供することができるメディアアクセスサーバのネットワークアドレスを決定する機能を有するデバイスに対して、ネットワークアドレスを送信するように要求することで、メディアアクセスサーバを発見する。エッジサーバコンピュータ１０８は次に、発見されたメディアアクセスサーバに対して、コンテンツ要求を送信する。契約されているメディアアクセスサーバは、いずれであっても、特定されたコンテンツの要求に対する応答方法を幾つか持っている。応答方法は、要求の種類および要求に関連付けられているコンテンツに応じて決定されてよい。
【００４４】
例えばメディアアクセスサーバは、エッジコンピュータサーバ１０８上のコンテンツのローカルにキャッシングされているバージョンが陳腐ではないことを示す情報をエッジコンピュータサーバ１０８に提供してよい。また、メディアアクセスサーバは、自分が、特定されたコンテンツの陳腐ではないコピーを有している場合に、エッジコンピュータサーバ１０８には、特定されたコンテンツを送信してよい。一実施形態では、メディアアクセスサーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバまたはウェブサーバ等のデータ転送サーバソフトウェアを含む。この場合には、エッジサーバコンピュータ１０８は、メディアアクセスサーバが利用するデータ転送プロトコルを利用してメディアアクセスサーバと相互作用する。
【００４５】
さらに、エッジサーバコンピュータ１０８とメディアアクセスサーバコンピュータ（例えばコンテンツ配信元サーバ１１２またはコンテンツ配信サーバ１１０）との間の通信に関しては、この２つのサーバがチャネルを介して通信することができる。２つのチャネルは、エッジサーバコンピュータ１０８とコンテンツ配信サーバ１１０との間のチャネル１１６ａと、エッジサーバコンピュータ１０８とコンテンツ配信元サーバ１１２との間のチャネル１１６ｂとして示されている。ここに記載されている様々な実施形態では、チャネル１１６がデータ転送である（つまり、チャネル１１６がＨＴＴＰ等のデータ転送プロトコルを利用してデータを搬送する、という意味である）。
【００４６】
エッジサーバ１０８は、データ転送プロトコルを利用してコンテンツを取得しながら、同時に、コンテンツ要求者に対してコンテンツをストリーミングするよう構成されている。例えば、エッジサーバコンピュータ１０８は、データ転送プロトコルチャネル１１６ｂを介して配信元サーバコンピュータ１１２からコンテンツを受信しつつ、同時に要求者（例えばコンピュータ１０４）に対して、要求されているコンテンツをストリーミングすることができる。エッジサーバコンピュータ１０８、および、エッジサーバコンピュータ１０８が利用するモジュールが実行する処理によって、ストリーミングおよびコンテンツ取得を同時に実行することができる。
【００４７】
図２は、エッジサーバコンピュータ２０２とメディアアクセスサーバコンピュータ２０４とを含む拡張可能コンテンツ配信プラットフォームをサポートするよう適合されているストリーミングコンテンツ配信フレームワーク２００を示す。エッジサーバコンピュータ２０２は、適宜、ＭＡＳ２０４からコンテンツを取得して、同時に、そのコンテンツを要求してきた実体にそのコンテンツをストリーミングする機能を有するモジュールで構成されている。一部の実施形態では、要求されたコンテンツをＭＡＳ２０４から取得する処理が、そのコンテンツを要求者にストリーミングする処理と同時に行われる。
【００４８】
図２に示す実施形態では、エッジサーバコンピュータ２０２がメディアストリーミングサーバ２０６、メディアストリーミング仲介器２０８、ストリームキャッシングモジュール２１０、および、コンテンツキャッシュ２１２を含む。図示されているシナリオでは、コンテンツ要求２１４が要求者から受信される。コンテンツ要求は、これらに限定されないが、要求されているコンテンツの識別子等の様々な情報を有する。要求２１４は、要求されているコンテンツの特定の部分を識別することができる。
【００４９】
要求２１４は先ず、メディアストリーミングサーバが受信する。メディアストリーミングサーバ２０６は、Ｆｌａｓｈ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ（登録商標）（ＦＭＳ）、Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａ  Ｓｅｒｖｅｒ（登録商標）（ＷＭＳ）またはその他のストリーミングメディアサービスであってよい。メディアストリーミングサーバ２０６は、コンテンツ要求に応えて、データストリーミングプロトコル（例えばリアルタイムメッセージングプロトコル（ＲＴＭＰ））を利用してコンテンツ要求者とデータを通信するよう構成されている。要求２１４を受信すると、メディアストリーミングサーバ２０６は、この要求２１４をメディアストリーミング仲介器２０８に渡し、仲介器２０８からの応答を待つ。このようにして、メディアストリーミング仲介器２０８は、メディアストリーミングサーバ２０６の状態を維持する。
【００５０】
メディアストリーミング仲介器２０８は、メディアストリーミングサーバ２０６およびストリームキャッシングモジュール２１０の間の橋渡し役として機能する。つまり、メディアストリーミング仲介器２０８は、メディアストリーミングサーバ２０６とストリームキャッシングモジュール２１０との間の通信を促すことで、コンテンツストリーミングをサポートする。一実施形態では、メディアストリーミング仲介器２０８は、メディアストリーミングサーバ２０６と通信するために、メディアストリーミングサーバ２０６のアプリケーションプログラミングインタフェース（ＡＰＩ）を利用するソフトウェアプラグインである。メディアストリーミング仲介器２０８は、メディアストリーミングサーバ２０６からの要求を処理して、メディアストリーミングサーバ２０６のある状態を維持して、コンテンツがキャッシュ２１２に存在しているときは、その旨をメディアストリーミングサーバに通知する。メディアストリーミング仲介器２０８は、コンテンツ要求を受信すると、ストリームキャッシングモジュール２１０に対するコンテンツ要求を生成する。
【００５１】
ストリームキャッシングモジュール（ＳＣＭ）２１０は、仲介器２０８からのコンテンツ要求に応答する機能を含む。一実施形態では、図２との関連で記載した図３に示すように、ＳＣＭ２１０は、ストリーミング要求ハンドラ３０２、キャッシュマネージャ３０４、および、データ転送インタフェース３０６を含む。ストリーミング要求ハンドラ３０２は、仲介器２０８からの要求を受信して、キャッシュマネージャ３０４に、要求されているコンテンツがキャッシュ２１２内にあるかをクエリする。キャッシュマネージャ３０４は、要求されているコンテンツがキャッシュ２１２にあるかを判断する。
【００５２】
要求されているコンテンツがキャッシュ２１２にある場合には、ＳＣＭ２１０のキャッシュマネージャ３０４は、条件が陳腐であるかを判断するべく、コンテンツの古さをチェックする。一般的に、各コンテンツアイテムには、生存期間（ＴＴＬ）値が関連付けられている。キャッシュマネージャ３０４は、要求ハンドラ３０２に対して、要求されているコンテンツに対するチェック（つまり、コンテンツが存在するか、および、存在する場合には、そのコンテンツが陳腐かどうか）の結果を通知する。
【００５３】
コンテンツがキャッシュ２１２に存在しており陳腐ではない場合には、要求ハンドラ３０２は、コンテンツのストリーミング準備が整った旨を、メディアストリーミング仲介器を介してメディアストリーミングサーバ２０６に通知して、コンテンツを読み出せるキャッシュ２１２の位置を提供する。コンテンツがキャッシュ２１２にない場合、または、コンテンツが陳腐である場合には、要求ハンドラ３０２は、データ転送インタフェース３０６に通知する。データ転送インタフェース３０６は、データ転送チャネル（例えばＨＴＴＰチャネル２１６）を介してＭＡＳ２０４に通信するよう構成されている。
【００５４】
データ転送インタフェース３０６は、要求されたコンテンツの識別要求２１８を、ＭＡＳ２０４に送信する。要求２１８は、状況に応じて、幾つかの異なる種類の要求のいずれか１つであってよい。例えば、要求されているコンテンツはキャッシュ２１２にあるが陳腐であると判断した場合には、データ転送インタフェース３０６は、ＨＥＡＤ要求（ＨＴＴＰの場合）をＭＡＳ２０４に送り、ローカルキャッシュにある要求されているコンテンツの現在の状態が陳腐であることを示す。要求されているコンテンツがキャッシュ２１２にない場合には、データ転送インタフェース３０６は、ＧＥＴ要求（ＨＴＴＰの場合）をＭＡＳ２０４に送信して、ＭＡＳ２０４からコンテンツの少なくとも一部を取得する。ＭＡＳ２０４は、要求２１８を受信して処理するデータ転送サーバ２２０を含む。
【００５５】
データ転送サーバ２２０は、データ転送プロトコル（例えばＨＴＴＰ）により、データ転送チャネル２１６を介して通信するよう構成されている。先ずは、データ転送サーバ２２０は、要求２１８で識別されたコンテンツが、ＭＡＳ２０４がアクセス可能なコンテンツデータベース２２２内にあるかを判断する。データ転送サーバ２２０は、コンテンツデータベース２２２に対して、要求されているコンテンツについてクエリする。データ転送サーバ２２０は、コンテンツデータベース２２２の応答に基づいて、要求されているコンテンツがデータベース２２２にあるかに応じた内容の応答２２４を生成する。
【００５６】
一般的には、応答２２４は、要求２１８に受信、理解、および受諾に成功したか否かを示す有効性インジケータを含む。データ転送プロトコルがＨＴＴＰである場合、応答２２４インジケータは数値コードである。要求されているコンテンツがデータベース２２２にない場合には、コードは、コンテンツがデータベース２２２に発見されなかった旨を示す無効を示す（例えばＨＴＴＰ４０４コード）。
【００５７】
要求されているコンテンツ（例えばファイル２２６）がデータベース２２２にある場合には、応答２２４コードは有効なインジケータである（例えばＨＴＴＰ  ２ＸＸであり、ＸはＨＴＴＰの定義に応じて異なる値をとってよい）。ＭＡＳ２０４に対する要求２１８がＨＥＡＤ要求であり、コンテンツがデータベース２２２にある場合には、通常の場合、応答２２４はＨＴＴＰ２００コードを含む。ＨＥＡＤ要求に対する応答２２４は、さらに、キャッシュ２１２内のコンテンツのＴＴＬが有効にし直されたか否かを示す情報も含む。ＧＥＴ要求であって、要求されているコンテンツ（ファイル２２６）がデータベース２２２にある場合には、応答２２４は、コンテンツ２２６の一部とともにＨＴＴＰコードを含む。
【００５８】
ストリームキャッシュモジュール２１０のデータ転送インタフェース３０６は、応答２２４を受信して、とるべき適切なアクションを決定する。概して、データ転送インタフェース３０６が、ＭＡＳ２０４が、要求されているコンテンツを発見しなかったか否かを、ストリーミング要求ハンドラ３０２に通知する。ＭＡＳ２０４がコンテンツを発見しなかった場合には、キャッシュマネージャ３０４がキャッシュ２１２にコンテンツを見つけられなかったことが想定され、ストリーミング要求ハンドラ３０２は、要求されたコンテンツが発見されない旨を、メディアストリーミング仲介器２０８を介してメディアストリーミングサーバ２０６に通知する。
【００５９】
応答２２４がＨＥＡＤ要求に対する有効応答である場合には、応答２２４は、キャッシュ２１２の陳腐なコンテンツのＴＴＬを有効にし直したかを示すものとなる。ＴＴＬが有効にしなおされた場合には、キャッシュマネージャ３０４は、有効にされたコンテンツのＴＴＬを更新して、ストリーミング要求ハンドラ３０２に、コンテンツが陳腐ではない状態でキャッシュ２１２内に入手可能に存在している旨を通知する。応答２２４が、キャッシュ２１２内の陳腐なコンテンツを有効にし直していない旨を示している場合には、キャッシュマネージャ３０４は、この陳腐なコンテンツを削除して、コンテンツがキャッシュ２１２内にない旨を示す。ストリーミング要求ハンドラ３０２は、次いで、データ転送インタフェース３０６に対してコンテンツ要求を行う。
【００６０】
ＧＥＴ要求は、取得すべきコンテンツの部分を特定することができ、ＧＥＴ要求が有効な場合には、通常、応答２２４は、識別されたコンテンツの特定された部分を含んでいる。要求２１８は、データ転送サーバ２２０が送信すべきファイル２２６のデータの範囲を特定する、部分的なファイル要求または範囲要求でありうる。範囲は、開始位置と量（例えばバイトカウント）とにより特定されてよい。範囲要求は、コンテンツの種類に対して、および、一定の要求に応じる際に、またはその他の状況において特に有用である。
【００６１】
例えば、要求されているファイル２２６がＦｌａｓｈ（登録商標）ファイルである場合には、第１の１以上のＧＥＴ要求が、メディアストリーミングサーバ２０６が要求者に対してすぐにファイル２２６のストリーミングを開始するために必要なファイル２２６の部分を特定する。メディアストリーミングサーバ２０６がファイル２２６を要求者に対してストリーミングを開始する目的にファイル２２６全体は必要がない。一部のケースでは、コンテンツの特定の一部が、メディアストリーミングサーバ２０６がストリーミングを開始するために必要となるコンテンツについてのメタデータを含む。メタデータには、ファイルサイズ、ファイルフォーマット、フレームカウント、フレームサイズ、ファイルタイプ、その他の情報が含まれてよい。
【００６２】
Ｆｌａｓｈ（登録商標）ファイル（例えばファイル２２６）では、ファイル２２６のストリーミングの開始には、ファイル２２６の先頭部分２２８またはファイル２２６の最終部分２３０のみが必要となるが、これは、先頭部分２２８および最終部分２３０に、ファイル２２６を記述するメタデータが含まれているからである。ファイル２２６の残りの部分２３２は、後で取得することができる。一実施形態では、先頭部分２２８は、ファイル２２６の最初の２メガバイト（ＭＢ）分であり、最終部分２３０が、最後の１ＭＢ分であるが、この特定のバイトの範囲は、様々な要因に応じて変化してよい。
【００６３】
Ｆｌａｓｈ（登録商標）ファイル２２６の場合には、ファイル２２６の先頭部分２２８および最終部分２３０をデータ転送インタフェース３０６により受信した後で、データ転送インタフェース３０６は、これらの部分をキャッシュ２１２に格納して、ストリーミング要求ハンドラ３０２が、要求されているコンテンツの最初の部分がキャッシュ２１２内に利用可能に存在している旨を通知される。要求ハンドラ３０２は次に、キャッシュ２１２内のコンテンツの最初の部分の位置をストリーミングメディアサーバ２０６に通知する。次に、ストリーミングメディアサーバ２０６は、キャッシュ２１２からのコンテンツの読み出しおよび要求者へのストリーミングコンテンツ送信２３４を開始する。
【００６４】
メディアストリーミングサーバ２０６が要求者にコンテンツをストリーミングしている間、ＳＣＭ２１０は、残りのもの２３２が取得されるまで、ＭＡＳ２０４からファイル２２６のコンテンツを取得し続ける。ＳＣＭ２１０のデータ転送インタフェース３０６は、ＭＡＳ２０４のデータ転送サーバ２２０に１以上のさらなるＧＥＴ要求を送信して、取得すべきコンテンツの範囲を指定する。一部の実施形態では、データ転送インタフェース３０６は、ファイル２２６全体が取得されるまで、設定されたバイトサイズで（例えば２ＭＢまたは５ＭＢをまとめて）ファイル２２６の連続部分を要求する。各要求で要求される量は、様々なパラメータ（ＭＡＳ２０４に出入りする通信の待ち時間等のリアルタイムパラメータを含む）に応じて調節可能である。
【００６５】
要求されているコンテンツのストリーミング中に、要求者は、コンテンツ内の特定の位置からデータをストリーミングするよう要求する位置特定要求を発行することができる。特定の位置は、コンテンツキャッシュ２１２内に格納されていても、まだ格納されていなくてもよい。この位置特定要求は、ストリーミングメディアサーバ２０６が受信して、メディアストリーミング仲介器２０８に渡す。ストリーミングメディア仲介器２０８は、ＳＣＭ２１０の要求ハンドラ３０２に要求を送信する。要求ハンドラ３０２は、キャッシュマネージャ３０４に、特定の位置からデータを提供するように要求する。キャッシュマネージャ３０４は、キャッシュ２１２から、ファイルの特定の位置のデータの取得を試みる。
【００６６】
特定の位置がキャッシュ２１２内にない場合には、キャッシュマネージャ３０４は、要求ハンドラ３０２にその旨を通知する。すると要求ハンドラ３０２は、データ転送インタフェース３０６に、特定の位置のコンテンツを取得するよう要求する。これに応じて、データ転送インタフェース３０６は、ＧＥＴ応答を送信して、データ転送インタフェース３０６がファイル２２６のダウンロード中であろうとなかろうと、ダウンロードのどの段階であろうと、特定の位置から始まるデータの範囲を指定する。
【００６７】
例えば、要求者が指定する位置がファイル２２６の最後であり、データ転送インタフェース３０６がファイル２２６の連続ダウンロード処理中、および、ファイル２２６の開始部である場合には、データ転送インタフェース３０６は、連続ダウンロードを中断して、特定の位置から始まるデータの範囲要求を送信する。特定の位置からコンテンツが取得されると、データ転送インタフェース３０６は、位置特定要求を受信する前に止めておいた箇所から連続ダウンロードを再開する。
【００６８】
エッジサーバ２０２、ＭＡＳ２０４、および、図３のストリームキャッシュモジュールといったコンポーネントは、実装例に応じて、任意の方法で組み合わせたり、編成し直したりすることができる。例えば、データ格納器（例えばコンテンツキャッシュ２１２およびコンテンツデータベース２２２）は、それぞれに関連付けられているサーバと切り離されて存在していてもよい。データ格納器は、任意の種類のメモリまたは格納器であってよく、任意の種類のコンテンツ格納方法を採用することができる。データ格納器（例えばコンテンツキャッシュ２１２およびデータベース２２２）は、データ格納器との相互作用を可能とするデータベースサーバソフトウェアを含むことができる。
【００６９】
図４は、ストリーミングキャッシュモジュール（図２のストリーミングキャッシングモジュール２１０等）または類似したコンポーネントが入ることのできる状態を示し、さらに、これら状態への出入りを生じさせる条件を示す状態ダイアグラム４００である。先ず、このシナリオ例では、ＳＣＭ２１０は、ＳＣＭ２１０が、特定されたコンテンツ要求を受信するときに、状態Ａ４０２に入ることができる。ＳＣＭ２１０は、最初に別の状態に入ってもよいが、図示の便宜上、要求で特定されたコンテンツがローカルキャッシュ内にない場合を想定する。状態Ａ４０２で、ＳＣＭは、特定されたコンテンツがローカルキャッシュにないと判断する。特定されたコンテンツがローカルキャッシュにはないと判断すると、ＳＣＭは状態Ｂ４０４に入る。
【００７０】
状態Ｂ４０４に入ると、ＳＣＭは、１以上の範囲要求をメディアアクセスサーバに出力して、メディアアクセスサーバ（ＭＡＳ）からコンテンツおよび／またはメタデータの受信を開始する。この場合には、ＭＡＳが、要求されたファイルの陳腐になっていないコピーを有している、または取得することができると仮定する。
【００７１】
ＳＣＭ２１０が生成する範囲要求に関して、１以上の範囲要求のそれぞれが、取得するデータの開始位置および該データの範囲を特定する。範囲要求は、ＨＴＴＰ等のデータ転送プロトコルがサポートする種類の要求であり、ＭＡＳが認識でき、これはＨＴＴＰまたはウェブサーバ等のデータ転送サーバを含む。従ってＭＡＳは、範囲要求（１または複数）を読み取り、範囲要求で識別される要求されているコンテンツの部分で応答することができる。
【００７２】
最初の範囲要求は、ストリーミングメディアサーバに迅速に要求されているコンテンツのストリーミングを開始させることのできる、ファイルのメタデータを含むファイルの位置を特定することができる。このメタデータは、ストリーミングメディアサーバが、コンテンツをストリーミングするために利用する制御データまたは定義を含みうる。
【００７３】
例えば、Ｆｌａｓｈ（登録商標）ファイルの場合には、最初の範囲要求は、ファイルの配置情報（例えば全ファイルサイズ、フレームサイズ、フレームの総数等）を示すＦｌａｓｈ（登録商標）ファイルの先頭を特定する。Ｆｌａｓｈ（登録商標）ファイルの場合には、最初の範囲要求、または第１の範囲要求の１つが、通常は、ファイルの終了部分も特定するが、これは、終了部分が、ストリーミングメディアサーバがファイルのコンテンツのストリーミングを開始する際に利用する情報を含んでいるからである。例えば一部の実施形態では、ＳＣＭが、特定されたＦｌａｓｈ（登録商標）ファイルの最初の２メガバイトおよびＦｌａｓｈ（登録商標）ファイルの最後の１ＭＢという範囲要求を生成する。
【００７４】
状態Ｂ４０４で、ＳＣＭは、ファイル全体が取得されるまで、コンテンツデータの要求・受信を続ける。コンテンツは、コンテンツファイルの開始部分から終了部分まで連続した順序で取得してもよいし、別の順序で取得されてもよい。例えば、連続順序外の取得（out of sequential order retrieval）は、コンテンツを見るユーザからの、ファイルの別の指定位置への移動を要求する位置特定要求によって生じる。例えば、ユーザは、ユーザのストリーミングメディアプレーヤによってストリーミングコンテンツファイルの特定の場所へと早送り（または「巻き戻し」）することができる。
【００７５】
ユーザがストリーミングファイルの特定の位置に移動する場合、ファイル内の移動先である特定の位置を指定する要求をＳＣＭに送信する。これに応じて、状態Ｂ４０４で、ＳＣＭは、ファイル内の要求されている位置を指定する範囲要求を生成する。ＳＣＭはさらに、コンテンツの１つまたは複数の部分がローカルキャッシュに格納されるとその旨をストリーミングメディアサーバに（例えばメディアストリーミング仲介器２０８を介して）通知して、ストリーミングメディアサーバがこれらの部分（１つまたは複数の部分）のストリーミングを開始できるようにしてよい。
【００７６】
要求されているコンテンツファイルのダウンロードが完了すると、ＳＣＭは、ファイルがダウンロードされた旨を示す出力を生成してよい。そしてＳＣＭは状態Ｃ４０６に入る。状態Ｃ４０６で、ＳＣＭは、コンテンツが陳腐になるまで待つ。状態Ｃ４０６で、ＳＣＭは、コンテンツファイルの古さをチェックして、古さを、「生存期間（ＴＴＬ）」値と比較するが、これはＭＡＳから受けるメッセージに提供されていてもよい。コンテンツファイルが陳腐になると、ＳＣＭは状態Ｄ４０８に入る。
【００７７】
状態Ｄ４０８で、ＳＣＭは、コンテンツファイルを有効にし直す要求をＭＡＳに送信する。ＭＡＳは、有効にし直す処理に成功した旨と新たなＴＴＬ値とを示すメッセージを送信してよい。そうする場合には、ＳＣＭは状態Ｃ４０６に戻り、ここでＳＣＭは再度ＴＴＬが期限切れになるのを待つ。他方で、状態Ｄ４０８にある間に、ＭＡＳがコンテンツを有効にし直さない場合、または、有効にし直す処理に失敗した旨を示すメッセージを生成する場合には、ＳＣＭは状態Ａ４０２に戻る。状態Ｄに状態Ａから入る前に、ＳＣＭは陳腐なコンテンツを削除する。
【００７８】
コンテンツを有効にし直す処理をさらに言及すると、一実施形態では、ＨＴＴＰヘッダを利用する。この実施形態では、ＳＣＭがＨＥＡＤ要求を送信して、ＨＴＴＰヘッダ：キャッシュ制御または期限切れ（Cache-Control or Expires）のいずれかを予期する。これらヘッダはＴＴＬ情報を提供する。あるコンテンツファイルが完全にダウンロードされると、ＳＣＭは、任意のコンテンツファイルについて受け取る各要求に応じて該ファイルのＴＴＬをチェックする。コンテンツファイルの有効期限がＴＴＬを過ぎている場合には、ＳＣＭは、別のＨＥＡＤ要求を送信して、コンテンツを有効にし直す。応答は、メディアアクセスサーバに応じて決定される。一例として、Ａｐａｃｈｅ  ＨＴＴＰサーバであれば、「２００」応答で応答する。「２００」応答を受信すると、ＳＣＭは、修正時間とファイルサイズとを両方ともチェックして、キャッシュのコンテンツがまだ有効であることを確かめる。別の例として、Ｍｉｃｒｏｓｏｆｔ社のＩＩＳ（登録商標）ＨＴＴＰサーバであれば、コンテンツが修正されており陳腐である場合には、ＨＥＡＤ要求に「２００」で応答し、コンテンツがまだ有効である場合には「３０４」で応答する。
【００７９】
図５から図７は、コンテンツの配信要求を取り扱う処理を示すフローチャートである。後述するように、この処理は拡張可能コンテンツ配信プラットフォームをサポートしている。概して、処理には、ローカルキャッシュのコンテンツがストリーミングに利用可能であるかを判断することと、利用可能であると判断される場合、ローカルキャッシュから要求者に要求されているコンテンツをストリーミングすることと、利用不可能であると判断される場合、コンテンツを有効にし直して、および／または、メディアアクセスサーバから取得して、要求者に同時にストリーミングすることとが含まれる。処理は、示されている特定の順序で実行される必要はない。処理は、機能モジュール（例えばメディアストリーミングサーバ２０６、ストリーミングメディア仲介器２０８、および、ストリームキャッシングモジュール２１０（図２）またはその他のモジュールの１以上等）により実行することができる。
【００８０】
図５を参照すると、コンテンツ要求処理５００においては、先ず、受信処理５０２で、特定のコンテンツ要求が受信される。要求されているコンテンツは要求により特定される。クエリ処理５０４では、要求されているコンテンツがローカルキャッシュに存在するかが判断される。要求されているコンテンツがローカルキャッシュに存在すると判断されると、別のクエリ処理５０６で、ローカルキャッシュ内のこのコンテンツが陳腐ではないかを判断する。一実施形態では、クエリ処理５０６で、ローカルキャッシュに保存されているコンテンツの古さを、このコンテンツに関連するＴＴＬ値と比較して、ＴＴＬ値よりも古い場合には、コンテンツを陳腐であるとして、ＴＴＬ値より古くない場合には、コンテンツは陳腐ではないとする。
【００８１】
ローカルキャッシュに保存されているコンテンツが陳腐ではないと判断された場合には、処理５０６は「ＮＯ」へと分岐して、ストリーミング処理５０８に進む。ストリームライニング処理５０８では、ローカルキャッシュに保存されているコンテンツを要求者へとストリーミングする。他方で、もしもローカルキャッシュに保存されているコンテンツが陳腐であると判断された場合には、処理５０６は「ＹＥＳ」に分岐して、送信処理５１０に進む。
【００８２】
送信処理５１０では、ローカルキャッシュに保存されているコンテンツを有効にし直するためのＨＥＡＤ要求を、メディアアクセスサーバ（ＭＡＳ）に送信する。別のクエリ処理５１２では、ＭＡＳからの応答をチェックして、ローカルキャッシュに保存されているコンテンツが有効にし直されたかを判断する。コンテンツが有効にし直された場合には、処理５１２は「ＹＥＳ」に分岐して更新処理５１４に進む。更新処理５１４では、ローカルキャッシュに保存されているコンテンツに関するＴＴＬ値を更新して、ローカルキャッシュに保存されているコンテンツが陳腐ではないようにする。ローカルキャッシュに保存されているコンテンツはその後ストリーミング処理５０８でストリーミングされる。
【００８３】
クエリ処理５１２に戻り、ＭＡＳからの応答が、ローカルキャッシュに保存されているコンテンツが有効にし直されなかったことを示している場合には、処理５１２は「ＮＯ」に分岐して削除処理５１６に進む。削除処理５１６では、ローカルキャッシュに保存されているコンテンツを削除する。削除処理５１６が終わり、クエリ処理５０４で、要求されているコンテンツがローカルキャッシュにないと判断された場合には、処理５０４は取得処理５１８に分岐する。取得処理５１８では、要求されているコンテンツをＭＡＳから取得しながら、そのコンテンツの要求者へのストリーミングも同時に行う。
【００８４】
一実施形態では、取得処理５１８で、データ転送プロトコル（ＨＴＴＰ）を利用してコンテンツを取得して、同時にそのコンテンツを、ストリーミングメディアプロトコルを利用して配信する処理も行う。取得処理５１８の例は、図６から図７を参照して後述する。
【００８５】
図６は、取得・ストリーミング同時処理５１８を示すフローチャートである。図６から図７に示す処理は、通常はストリームキャッシングモジュール（例えばＳＣＭ２１０（図２））または類似したコンポーネントにより行われる。図６から図７を参照して記載するシナリオおよび記載では、メディアアクセスサーバ（ＭＡＳ）が、要求されているコンテンツの陳腐ではないコピーを所持していると想定する。
【００８６】
ＨＴＴＰの場合には、送信処理６０２で、ＧＥＴ要求をＭＡＳに送信する。最初の１以上のＧＥＴは、コンテンツのストリーミングが始められるように、コンテンツの配置を記述するメタデータを含むコンテンツの要求部分（１または複数）を要求する。例えば一実施形態では、取得するコンテンツがＦｌａｓｈ（登録商標）メディアである場合、最初の１つまたは２つのＧＥＴ要求が、このコンテンツの最前部および最後部の範囲要求であり、これには、ストリーミングを開始する際に利用するメタデータが含まれている。
【００８７】
格納処理６０４で、コンテンツの取得された部分をキャッシュに格納する。通知処理６０６では、ストリ−ミングメディアサーバに、要求されているコンテンツの最初の部分がキャッシュにあり、ストリーミングを待っている段階であることを通知する。ストリーミングメディアサーバは、これに応じて、要求されているコンテンツのストリーミングを開始する。一方で、ＳＣＭは、取得処理６０８で、要求されているコンテンツの部分を取得し続ける。
【００８８】
取得処理６０８は、要求されているコンテンツのデータの範囲についての１以上のさらなるＧＥＴ要求をＭＡＳに送信する処理を含む。ＭＡＳから受信するコンテンツデータはキャッシュに格納され、ストリーミングメディアサーバはこのキャッシュにアクセスしてストリーミングを続ける。一実施形態では、取得処理６０８で、コンテンツの複数の部分が連続取得されてもよい。コンテンツの複数の部分は、範囲要求で指定されるサイズを有する。この部分のサイズは、様々な設定またはリアルタイムパラメータに応じて設定または適合されてよい。一部の実施形態では、この部分のサイズを５ＭＢに設定するが、実装例によっては他のサイズにすることもできる。取得処理６０８は、コンテンツファイル全体が取得されキャッシュに格納されるまで続けられる。
【００８９】
取得処理６０８中に、受信処理６１０で位置特定要求を受信することができる。位置特定要求を受信すると、通常のコンテンツ（連続）取得順序を一時中断して、この位置特定要求が特定する特定の位置からのコンテンツデータ取得を優先させる。位置特定要求処理の具体的な実施形態については図７を参照して後述する。
【００９０】
位置特定要求を処理し終わると、取得処理６０８を再開させる。取得処理６０８では、位置特定要求が特定した位置の後に、データの連続取得を続けることができ、または、取得処理６０８で、位置特定要求を受信したところから連続取得を再開することもできる。
【００９１】
図７は、コンテンツを要求者にストリーミングするときに位置特定要求に応答するために利用することのできる位置特定要求処理７００を示すフローチャートである。上述したように、位置特定要求とは、現在ストリーミング中のコンテンツ内の特定の位置のデータ提供要求のことである。ストリーミングメディアプロトコルは、コンテンツファイル内の要求されている位置に迅速に移動するよう適合されている。
【００９２】
しかし進行性ダウンロードプロトコル（例えばＨＴＴＰで利用されることの多い進行性ダウンロードスキーム）では、所望の位置の前の全てのデータが先ずダウンロードされねばならないために、コンテンツのダウンロード中にそのコンテンツの特定の位置に移動すると、遅延が生じやすい。図６から図７のスキームを利用すると、さもなくば進行性ダウンロードでデータ転送チャネルで配信するしかないコンテンツのストリーミングが可能となり、これにより、コンテンツ内の特定の位置への移動に伴う遅延を低減させたり、なくしたりすることができる。
【００９３】
移動処理７００では、先ずクエリ処理７０２で、位置特定要求で特定される特定の位置におけるデータがローカルキャッシュに格納されているかを判断する。クエリ処理７０２では、ローカルキャッシュ内に、特定の位置の後の少なくとも一定の最小データ量が格納されていることをチェックするという、公差（tolerance）を利用することができる。例えば、クエリ処理７０２で、ローカルキャッシュ内に、特定の位置の後の少なくとも１ＭＢ（またはその他の量）のデータが格納されていることをチェックすることができる。公差を利用することにより、特定の位置において少なくとも最小データ量をストリーミング用に確実に確保することにより、移動処理７００における遅延を避けることができるようになる。
【００９４】
少なくとも最小データ量がローカルキャッシュに格納されていると判断した場合には、クエリ処理７０２から「ＹＥＳ」に分岐して通知処理７０４へ進む。通知処理７０４は、要求されているデータが配信用に待機しているキャッシュ内の位置を、メディアストリーミングサーバに通知する。通知処理７０４の後で、処理７００は取得処理６０８に戻る（図６）。上述したように、取得処理６０８では、位置特定要求で特定された位置の後のコンテンツの部分の取得を続けていてもよいし、または、位置特定要求を受信する前の位置から取得を再開してもよい。
【００９５】
クエリ処理７０２に再度戻り、特定された位置の最小データ量がキャッシュに格納されていないと判断した場合には、クエリ処理７０２から「ＮＯ」に分岐して送信処理７０６に進む。送信処理７０６では、ＧＥＴ要求を生成して、特定された位置の後のデータの範囲を特定する。範囲要求で特定されるデータ量は、処理６０２（図６）で生成されるＧＥＴ要求で取得されるバイトカウントであってもよいし、他のバイトカウントであってもよい。格納処理７０８では、要求されているデータを受信して、ローカルキャッシュに格納する。格納処理７０８の後で、移動処理７００は通知処理７０４へと分岐して、ここではメディアストリーミングサーバに、要求されているデータのキャッシュ内の位置を通知する。
【００９６】
図８は、配信元サーバ８１０、キャッシュサーバ８２０−１、キャッシュサーバ８２０−２、およびキャッシュサーバ８２０−３（以後、まとめてキャッシュサーバ８２０と称する）を含むコンテンツ配信ネットワーク８０５を有する別のネットワーク環境８００の一例を示すブロック図である。各キャッシュサーバ８２０は、キャッシュメモリ８２２−１、８２２−２、および、８２２−３、並びに、各格納システム８２４−１、８２４−２、および、８２４−３（例えばディスクベースの、または他の永久ストレージ）を有する。キャッシュサーバ８２０−１は、要求を処理（service）して、インターネットサービスプロバイダ８（ＩＳＰ１）に関連付けられているエンドユーザ８３２、８３４、および８３６（例えばクライアントコンピュータ）にコンテンツを提供する。キャッシュサーバ８２０−２は、要求を処理（service）して、ＩＳＰ２に関連付けられているエンドユーザ８４２、８４４、および８４６にコンテンツを提供する。キャッシュサーバ８２０−３は、要求を処理（service）して、ＩＳＰ３に関連付けられているエンドユーザ８５２、８５４、および８５６にコンテンツを提供する。図８では簡略化して、各ＩＳＰについて１つの専用キャッシュサーバが設けられる、と示している。いかし数多くの他の実装例も可能である。例えば様々な実施形態では、１以上のＩＳＰが専用のキャッシュサーバを有さなくてもよいし、１以上のＩＳＰが複数のキャッシュサーバを有してもよいし、キャッシュサーバにＩＳＰが全く関連付けられていなくてもよい。例えば一実施形態では、１以上のキャッシュサーバが遠隔に位置して（例えばＩＳＰのインフラストラクチャ内に、または、エンドユーザのサイトに（例えばローカルエリアネットワーク（ＬＡＮ）内に）、遠隔の配信元サーバ（例えば図８の配信元サーバ８１０）と相互作用する。
【００９７】
図８のネットワーク環境８００は、ここに記載する様々な実施形態の機能を実装および促進するのに適したコンテンツ配信ネットワーク８０５の高レベル実装表現である。コンテンツ配信ネットワーク８０５は、コンテンツ配信ネットワークの実装の一例を表しているに過ぎず、従って、ここに記載する実施形態は、当技術分野で通常実施されているいずれのコンテンツ配信ネットワーク構成にも同様に実装可能であることに留意されたい。コンテンツ配信ネットワークの一例は、２００２年９月３０日提出のポール  Ｅ．ストローズ（Paul E. Stolorz）氏等による「設定可能なアダプティブグローバルトラフィック制御および管理：Configurable adaptive global traffic control and management」なる名称の米国特許出願公開第２００３／００６５７６２号明細書に記載されており、この文献全体を参照としてここに組み込む。
【００９８】
一般的な処理中に、配信元サーバ８１０は、ライン８６０が示すように、キャッシュサーバ８２０に様々なコンテンツを配信する（例えば地理、人口等に応じて）。一例として、エンドユーザ８３６が、配信元サーバ８１０に格納されているあるコンテンツ（例えば音楽、ビデオ、ソフトウェア等）を要求する場合を想定する。この実施形態では、配信元サーバ８１０は、コンテンツ配信ネットワーク８０５を利用して、自身が含むコンテンツを提供（serve）してよく、場合によっては、既に要求されているコンテンツをキャッシュサーバ８２０−１に配信済みであってもよい。エンドユーザ８３６は、任意の数の公知の方法を利用してリダイレクトされて、キャッシュサーバ８２０−１にコンテンツを要求する。図８の実施形態の例に示すように、キャッシュサーバ８２０−１は、ＩＳＰ１のエンドユーザにコンテンツを配信するよう構成／配置されている。キャッシュサーバ８２０−１は、任意の数のポリシー（例えば負荷バランス、位置、ネットワーク配置、ネットワークパフォーマンス等）を利用して、キャッシュサーバ８２０群から選択することができる。こうして、エンドユーザ８３６は、ライン８８０が示すように、キャッシュサーバ８２０−１に対してコンテンツ要求を送る。次に、キャッシュサーバ８２０−１は、キャッシュ８２２−１からエンドユーザ８３６にコンテンツを（ライン８９０）提供（serve）する。コンテンツがキャッシュにない場合には、キャッシュサーバ８２０−１は、コンテンツを配信元サーバ８１０から取得する。
【００９９】
図８は配信元サーバ８１０がコンテンツ配信ネットワーク８０５内に位置している実施形態を示しているが、配信元サーバ８１０は、コンテンツ配信ネットワークから遠隔に位置していてもよい（例えばコンテンツプロバイダのサイトにあってもよい）。図９にこのような実施形態が示されており、ここではコンテンツ配信ネットワーク９０５が様々なコンテンツプロバイダのサイト９０８に位置している１以上の配信元サーバ９１０と相互作用する。この実施形態では、コンテンツ配信ネットワーク９０５は、複数のキャッシュサーバ９２０を含む。キャッシュサーバ９２０は、要求を処理（service）して、コンテンツをエンドユーザ９３２、９４２、および９５２（例えばクライアントコンピュータ）に提供する。配信元サーバ９１０は、図８を参照して上述したようにして、キャッシュサーバ９２０に様々なコンテンツを配信する。
【０１００】
キャッシュサーバ８２０（または９２０）は、拡張可能コンテンツ配信プラットフォームを提供する拡張可能コンテンツ配信プラットフォーム（例えばイベントベースのアプリケーションプログラミングインタフェース（ＡＰＩ））を含む。拡張可能コンテンツ配信プラットフォームは、サービス提供する基礎コンテンツの周りに構築されるアプリケーションおよびサービスを提供する。適格なリッチ・メタデータおよび「メタコード」を、一貫した、プログラミングによる方法で、コンテンツおよび／または要求と関連付けることができる。一実装例では、システムが、構造化された「イベント」モデル、構造化されたオブジェクトモデル、プリミティブ関数、および、言語構造を提供することで、コアコードに対する変更を必要とせずに柔軟な方法で活用可能なサービス層を生成することができる。
【０１０１】
このようなシステムの１つの具体的な実装例では、ＡＰＩ「ラッパー」が、既存の規則ベースおよび他の設定テーブルの周りに、既存の技術を大規模に置き換える必要なく、構築される。この実装例では、「ラッパー」によって、システムは、既存のキャッシュサーバの基礎機能に、論理的に表すことができる方法でアクセスすることのできる一貫した、単一のインタフェースとして提示される。
【０１０２】
本発明の拡張可能コンテンツ配信プラットフォームは、コードの複雑性が低く保守がより容易である。コアコードは、コアコードを変更することによるのではなく、コアの基礎オペレーティングサービスを利用することにより構築可能な既存および将来のフィーチャをサポートする、基礎オペレーティングサービスセットを提供する。これらの一実装例では、コアの基礎オペレーティングサービスは、オブジェクトキャッシング、命令解釈、命令実行等を含む。
【０１０３】
例えば特定の実装例では、ジオＩＰサービスがプラットフォーム内にプリミティブ関数としてインスタンス化される。この実装例では、入ってくるＩＰアドレスを、そのＩＰアドレスに関する様々な地理的その他のコードのデータベースへの鍵として利用することができる。データベースまたはルックアップテーブルは、導出するコードをより高いレベルのプログラムモジュールに曝して、コンテンツへのアクセスの制限または許可、コンテンツの代替例としてのサービス提供（serving alternate variants of content）等の他の機能で利用することのできるシステム「プリミティブ」関数として機能することができる。
【０１０４】
一実施形態では、拡張可能コンテンツ配信プラットフォームはさらに、コアコードを変更せずに、柔軟な実装が可能となる（例えば、高度な（enriched）拡張性、カスタマイズ、アプリケーション集積の可能性の面で）。この実施形態では、開発者は、プラットフォーム上に実質的に無制限にアプリケーションを生成することができるようになる。
【０１０５】
図１０は、キャッシュサーバ（例えば図８に示すキャッシュサーバ１２０−１）に組み込まれる拡張可能プログラミングフレームワーク１０００（例えばイベントベースの拡張可能プログラミングフレームワーク）の一実施形態を示す。フレームワーク１０００は、コアエンジン１００２、設定ファイル１００４、および、モジュール１００６、１００８、および１０１０を含む。コアエンジン１００２は、コアコードを変更するのではなく、コアの基礎オペレーティングサービスを利用することにより構築可能な既存および将来のフィーチャをサポートする基礎オペレーティングサービスセットを提供するコアコードを提供される。一実施形態では、基礎オペレーティングサービスは、コアエンジン１００２が実行することのできる基礎機能またはアクションを含む。コアエンジン１００２を複雑にすることで様々な機能またはサービスを提供する方法をとるのではなく、拡張プログラミングフレームワーク１０００のコアエンジン１００２は、スクリプトまたはモジュールに様々なフィーチャまたはサービスを関連付ける手法をとる。例えば図１０では、モジュール１００６、１００８、および１０１０が、様々にカスタマイズ可能なフィーチャまたはサービスを提供しており、一方でコアエンジン１００２はなんら複雑になっていない。
【０１０６】
一例における実施形態では、コアエンジン１００２の基礎オペレーティングサービスは、離散したイベントにおいて、または様々なオブジェクトに対して実行される構造化されたイベントモデル、構造化されたオブジェクトモデル、プリミティブ関数またはアクション、並びに、アプリケーションおよび／またはサービスをコアエンジン１００２の周りに構築することのできるプログラミング文法を含む。構造化されたイベントモデルは、様々なアクションがとられうるコンテンツ配信ネットワーク処理パイプラインで離散した複数のイベントを提供する。構造化されたオブジェクトモデルは、様々な一貫した特性および属性を取得可能、および／または、操作可能なように定義される一連のオブジェクト（例えば要求、リソース、応答、その他のオブジェクト）をインスタンス化する。プリミティブ関数またはアクションのセットを、離散したイベントにおいて、または様々なオブジェクトに対して実行することができる。これらアクションの例には、様々な処理（例えばストリングのパース、操作、ＨＴＴＰメッセージ構築、および分解、リソース操作等）が含まれる。
【０１０７】
モジュール１００６、１００８、および１０１０は、定義されたプログラミング文法を利用して、スクリプト、命令、その他のコードを提供する。例えば一実施形態では、モジュール１００６、１００８、および１０１０は、コアエンジン１００２に実装される機能を実行するように開発される特定のインスタンス化を含む。モジュール１００６、１００８、および１０１０は、コンテンツ配信ネットワークの所有者またはオペレータにより制御することができ、あるいは、多くの異なる人がシステムを設定することができるように文書化することができる。顧客、再販業者、コンテンツパートナー、その他の個人は、拡張可能プログラミングフレームワーク１０００で利用されるモジュールまたはスクリプトを提供することで、コンテンツ配信ネットワークのフィーチャまたはサービスをカスタマイズすることができる。
【０１０８】
１つの実装例では、（１）特性にわたるベース（例えば、全ての要求／コンテンツが同じように影響されうる）、（２）リソースまたはリソースグループ（例えば、処理は、要求されているリソースが条件セットに合致するかに基づいていてよい）、（３）要求メタデータ（例えば、要求が、実行される１以上の処理を決定するために利用されうる情報を含む）、（４）応答メタデータ（要求されているリソースを取得する処理中に、配信元または仲介コンテンツ配信ネットワークノードから伝達される情報）、および、（５）上述した条件と、キャッシュサーバ内または外部アプリケーション／サービスからインスタンス化されたメタデータとの組み合わせのうちの１以上に作用するようにフィーチャを提供する。
【０１０９】
コアエンジン１００２は、モジュール１００６、１００８、および１０１０内のスクリプト、命令、その他のコードを解釈して、スクリプト、命令、その他のコードを実行して、コンテンツ配信ネットワーク内にカスタマイズされたフィーチャまたはサービスを提供する。モジュール１００６、１００８、および１０１０は、コアエンジンから直接類似したフィーチャおよびサービスを提供するためにコアエンジン内に詳しい設定ファイルを置く必要性を軽減する。モジュール１００６、１００８、および１０１０は、コンテンツ配信ネットワーク内にフィーチャおよびサービスのカスタム論理を書き込む拡張可能プラットフォームを提供する。ある特定の実施形態では、モジュール１００６、１００８、１０１０内のスクリプトが、コンテンツ配信ネットワークを介して利用可能な特定のコンテンツと関連付けられている。これらのスクリプトは、ユーザがこのコンテンツのコンテンツにアクセスを試みるたびに実行される。
【０１１０】
一実施形態では、モジュール１００６、１００８、および１０１０は、様々な異なる顧客に対して認証サービスを提供する。一例では、モジュール１００６、１００８、および１０１０は、特定のコンテンツセットへのアクセスをブロックしたり、および／または、許可したりすることのできる（例えば地理的領域、許可（permission）により）命令を提供する。例えば第１のモジュール１００６は、ある特定の領域セットのユーザのアクセスをブロックする命令を提供し、第２のモジュール１００８が、異なるコンテンツセットについて異なる領域セットのユーザのアクセスをブロックする命令を提供する、といったことができる。これらのモジュールは、設定ファイル１００４の特定の組み合わせ、コアモジュール１００２に常駐している規則、メタデータその他の情報、および／または、コンテンツ要求内のメタデータ（図１に示す要求１８０等）に応じて異なる時点で異なるユーザおよび／または要求について呼び出される。このような例では、第１のモジュール１００６を、あるプロフィールを持つ（（例えばディレクトリ、名称、ファイルタイプ等））コンテンツを要求する全てのユーザについて実行する。一方で、第２のモジュール１００８は、異なるコンテンツセット（および／または異なる特性またはプロフィールを有するコンテンツ）の要求について適用される。モジュール１００６、１００８、および１０１０は、例えばコンテンツ配信ネットワーク（例えば図１に示すコンテンツ配信ネットワーク１０５）内に作成および／または格納されている。そして、これらのモジュールは、特定の規則および／またはイベントに基づいてコンテンツのトランザクションおよび／または要求に利用される。
【０１１１】
一実施形態では、規則、モジュール、手順、プラグイン等の定義のためにテーブルのセットを利用する。例えばモジュールは、オプションとして引数を入力として、および、戻り値を出力として有する指定される手順（named procedures）として格納されてよい。モジュールはまた、規則エンジンを利用して、または、要求／応答ヘッダその他のＨＴＴＰ構成（例えばクエリ・ストリング・エレメント等）による明示的呼び出しにより指定（name）されてもよい。一実施形態では、指定されるモジュールと規則ベースまたはスクリプトを切り離すことにより、単一のモジュールを一度コンテンツ配信ネットワークに生成（author）または格納でき、しかも、様々な基準／規則を利用して呼び出すことができるようになる（例えばオプションである、異なる振る舞いをトリガする引数の利用により）。
【０１１２】
図１１は、構造化されたコンテンツ配信イベントモデル１１００の一例である実施形態を示すブロック図である。図１１の実施形態では、イベントモデル１１００が、拡張可能コンテンツ配信プラットフォーム内の、カスタマイズ可能なモジュールまたはスクリプトによって、様々なアクションをとりうる１以上のコンテンツ配信プロセスにおける離散したイベントを識別している。しかしイベントモデル１１００は、コンテンツ配信ネットワーク内の離散したイベントを識別するために利用可能なイベントモデルの一例に過ぎない。処理パイプライン内の様々な点において１以上のモジュールを呼び出すイベントを識別するためには数多くの異なる方法が可能である。別の実装例では、拡張可能コンテンツ配信プラットフォームにおけるカスタマイズ可能なモジュールまたはスクリプトによって様々なアクションをとることのできる複数のイベントから、特定の離散したイベントを検知するために、規則セットを利用することもできる。
【０１１３】
図１１に示すイベントモデル１１００では、ユーザとの接続が構築されると、コンテンツ配信プロセスが開始される（処理１１０２）。コンテンツリソース要求が接続を介して受信される（処理１１０４）。コンテンツリソースがキャッシュサーバのキャッシュに見つかる場合には、「キャッシュヒット」として特定する（処理１１０６）。コンテンツリソースがキャッシュに見つからない場合には、「キャッシュミス」として特定する（処理１１０８）。
【０１１４】
キャッシュヒットにより、要求されているコンテンツリソースがキャッシュにあることが示されている場合には、イベントモデルは処理１１１０に進み、ここで、要求に対する応答をユーザに送信する準備が整う。
【０１１５】
キャッシュミスにより、要求されているコンテンツリソースがキャッシュにないことが示されている場合には、イベントモデルは処理１１１２に進み、ここで、別のソース（例えば図１に示す配信元サーバ１１０または図１のＡに示す遠隔のコンテンツプロバイダの配信サーバ１１０Ａ）に対してこのコンテンツリソースを要求するためのキャッシュ充填要求を準備する。イベントモデルはさらに、処理１１１４でこの別のコンテンツソースへの接続を構築して、接続に成功したか否かを判断する。この別のコンテンツソースへの接続に成功したと判断される場合（処理１１１６で）、イベントモデル１１００は、処理１１１８でキャッシュ充填要求を準備して、処理１１２０でキャッシュ充填要求を、この別のコンテンツソースに送信する。キャッシュ充填が完了すると（処理１１２２）、イベントモデル１１００は処理１１１０に進むが、これは、ユーザのコンテンツ要求に対する応答をユーザに送信する準備ができたことを示す。
【０１１６】
処理１１１０で、応答をユーザに送信する準備が整うと（処理１１０６のキャッシュヒットからであっても、処理１１１２から１１２２のキャッシュ充填からであってもよい）、イベントモデル１１００は処理１１２４に進み、ユーザに対して、要求されているコンテンツを提供するための（serve）応答を開始する。この、ユーザに対して、要求されているコンテンツを提供するための応答が成功裏に終了すると、イベントモデル１１００は、処理１１２６で成功した旨を示す。応答に失敗した場合には、イベントモデルは処理１１２８で失敗した旨を示す。
【０１１７】
この、キャッシュを充填するための、別のコンテンツソースへの接続が失敗したと示される場合（処理１１３０）には、イベントモデル１１００は処理１１２８に進み、コンテンツを提供する（serve）試みが失敗した旨を示す。
【０１１８】
イベントモデル１１００から、カスタマイズ可能なモジュールまたはスクリプトを実装してカスタムフィーチャまたはサービスを提供することのできる離散したイベントを特定される。ＨＴＴＰ／Ｓ要求を処理する（service）コンテンツ配信ネットワークの一実施形態では、プロセス内のイベント、要求受信（例えば、コンテンツ配信ネットワークが受信するＨＴＴＰ要求）、リソース発見（例えば、リソースがキャッシュサーバのキャッシュに存在するか、または、リソースがコンテンツ配信ネットワークに発見されるかを判断するためのサービスの調査（consultation））、キャッシュヒット（例えば、リソースがキャッシュに見つかったことを示すこと）、キャッシュミス（例えば、リソースがキャッシュに見つからないことを示すこと）キャッシュ充填（例えば、コンテンツ配信ネットワーク内のソースからリソースが取得された旨を示すこと）、認証要求（例えば、要求を認証する旨を示すこと）、構成応答（例えば、関連ヘッダ、応答本体、および／または、その他を含むコンテンツ配信ネットワークキャッシュサーバが構築する応答）、および、応答発行（例えば、要求を発しているユーザに応答を送信した旨の示唆）を含む。これらのイベントは、コンテンツ配信ネットワークのキャッシュサーバでコンテンツ配信要求を提供（serve）するプロセス内で特定されうる離散したイベントの数例に過ぎない。他の離散したイベントを特定することもある。
【０１１９】
一実施形態では、キャッシュサーバの拡張可能プログラミングフレームワークは、さらに、図１１に関して上述したもののような要求の処理中に動作しうる数種類のオブジェクトを提供する。このオブジェクトの種類には、接続（例えばＴＣＰ層情報、クライアント特性等）、要求（例えば要求ヘッダおよび要求本体）、リソース（例えば、リソース本体、および、オブジェクトの属性およびキャッシュ制御設定等のリソースメタデータ）、応答（例えば応答ヘッダおよび応答本体）、および、サーバ（例えばコンテンツ配信ネットワークサーバ、ノード、またはクラスタに関する属性）が含まれる。これらのオブジェクトの種類は、コンテンツ要求処理中に作動可能なオブジェクトの種類のほんの数例に過ぎない。他の種類のオブジェクトも作動させることもできる。
【０１２０】
オブジェクトおよびその属性は、インスタンス化して、イベントパイプラインの適切な点について利用することができる一実施形態では、属性（地理的コード、サーバ領域等）が関数呼び出しによって利用可能である。例えば一実施形態では、呼び出しは、カスタマイズされたフィーチャまたはサービスを作成するために利用されるプログラミング文法の一部またはイベントである。
【０１２１】
コンテンツ要求処理中には、さらに、様々なアクションをとることができる。例えば一実施形態では、この様々なアクションに、トランザクションの各側面を操作すること、さらなるトランザクションを発生させること、等が含まれる。実行可能なアクションの例には、応答のためにカスタムヘッダおよび／または本体（例えばコンテンツに透かしを埋め込む（content watermarking）、セキュリティチェックの合計適用（application of security check summing）、ファイルの大量切断、切断解除（file chunking/unchunking）、単一の応答からの、連続するバイトストリームのストリーミング）、新たな要求の作成（例えば、認証要求、別のまたは関連するリソースの要求等に基づいて）、応答ヘッダの削除、応答ヘッダの新たな値の設定、および、ある位置（任意の位置等）への構築された要求の送信、応答を待つこと、および、応答の１以上の属性に対するアクションが含まれてよい。また、多くのプログラミング言語に共通な処理等の他のアクションを、プログラミング文法言語の関数またはプリミティブ（primitives）として（例えばストリング関数または数学的関数として）捉えることもできる。また別のアクションは、コンテンツ配信ネットワーク側で分かっているメタデータを取得する特別なオペレーションであってもよい。例えば一実施形態では、クライアントの地理（ＣｌｉｅｎｔＧｅｏｇｒａｐｈｙ）（「国」）のオペレーションにより、要求を出しているクライアントの国コードが戻される（例えばクライアントまたは接続オブジェクトのＩＰアドレスを見つけることで、または、オブジェクトからコードを抽出して、ＧｅｔＧｅｏｇｒａｐｈｙ（＜ｌｅｖｅｌ＞、＜ａｄｄｒｅｓｓ＞関数）等のより一般的な種類の関数として渡すことにより）。同様に一実施形態では、ＧｅｔＳｅｒｖｅｒＩＰ（）関数またはＧｅｔＨｅａｄｅｒ（「名称」）処理を利用してメタデータを取得する。
【０１２２】
一実施形態では、スクリプトその他のカスタマイズ可能なコードを利用して、コンテンツ配信ネットワークのキャッシュサーバを、フィーチャまたはサービスに提供する。一実装例では、スクリプトをコンテンツ配信ネットワーク上で利用可能なリソースに関連付けて、予め設定しておき（例えばテーブルに格納しておく）、リソースに添付して（例えば応答ヘッダまたは本体に添付する）、あるいは、リソースと関連付けておく、といったことができる。スクリプトまたはモジュールを要求と関連付けるためには数多くのメカニズムを利用することができる。一実装例では、スクリプト（関連する関数、引数等とともに）を、システム内の指定されたリソースとして格納する。指定されたリソースは、（１）コアエンジン内に登録されているイベントを介して、（２）整合規則セットを介して（例えば、特定のコンテンツセット要求を受信したら、モジュール「Ｘ」を実行する等）、（３）要求を、クエリストリングパラメータ、カスタムヘッダおよび／または本体等として実装可能なモジュールと、コンテンツ発行者が明示的に関連付けることにより、または、（４）別のスクリプトまたはモジュールからの呼び出しにより、後に実行される。
【０１２３】
図１２は、本発明の実施形態を実装、実行することができるコンピュータシステム１２００の概略図である。例えば、１以上のコンピューティングデバイス１２００を利用して、拡張可能コンテンツ配信プラットフォームをサポートことができる（例えばコンテンツ配信ネットワーク内でストリーミングされるコンテンツについて）。一般的に、コンピュータシステム１２００の例としては、汎用コンピュータ（デスクトップ、ラップトップ、またはサーバコンピュータ等）または専用コンピュータ（エンベデッドシステム等）を含む任意の数のコンピュータデバイスが挙げられる。
【０１２４】
図の例では、コンピュータシステム１２００は、バス１２０１（つまりインターコネクト）、少なくとも１つのプロセッサ１２０２、少なくとも１つの通信ポート１２０３、メインメモリ１２０４、取り外し可能格納媒体１２０５、読み取り専用メモリ１２０６、および大容量格納装置１２０７を含む。プロセッサ（１または複数）１２０２は、Ｉｎｔｅｌ（登録商標）Ｉｔａｎｉｕｍ（登録商標）またはＩｔａｎｉｕｍ２（登録商標）プロセッサ（１または複数）、ＡＭＤ（登録商標）Ｏｐｔｅｒｏｎ（登録商標）、またはＡｔｈｌｏｎ  ＭＰ（登録商標）プロセッサ（１または複数）、または、Ｍｏｔｏｒｏｌａ（登録商標）ラインのプロセッサ等を含むが、これらに限定はされない任意の公知のプロセッサであってよい。通信ポート１２０３は、モデムを利用するダイアルアップ接続で利用されるＲＳ−２３２ポート、１０／１００Ｅｔｈｅｒｎｅｔ（登録商標）ポート、銅または繊維を利用するギガビットポート、またはＵＳＢポート等のうちの任意のものであってよい。通信ポート（１または複数）１２０３は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、または、コンピュータシステム１２００が接続する任意のネットワーク等のネットワークに応じて選択することができる。コンピュータシステム１２００は、周辺デバイス（例えば表示スクリーン１２３０、入力デバイス１２１６）と、入出力（Ｉ／Ｏ）ポート１２０９を通じて通信することができる。
【０１２５】
メインメモリ１２０４は、ランダムアクセスメモリ（ＲＡＭ）であってもよいし、当技術分野で公知の任意の他のダイナミック格納デバイスであってよい。読み取り専用メモリ１２０６は、スタティック情報（例えばプロセッサ１２０２のための命令）のためのプログラマブル読み取り専用メモリ（ＰＲＯＭ）チップ等の任意のスタティック格納デバイスであってよい。大容量格納デバイス１２０７は、情報および命令を格納するために利用することができる。例えば、Ａｄａｐｔｅｃ（登録商標）ファミリーのＳＣＳＩ（small computer serial interface）ドライブ、光ディスク、ＲＡＩＤ（redundant array of independent disks）等のディスクのアレイ（例えば、Ａｄａｐｔｅｃ（登録商標）ファミリーのＲＡＩＤドライブ）、または任意の他の大容量格納デバイスを利用することができる。
【０１２６】
バス１２０１は、プロセッサ１２０２（１または複数）を他のメモリ、ストレージおよび通信ブロックと通信可能に連結する。バス１２０１は、利用される格納デバイスに応じて、ＰＣＩ／ＰＣＩ−Ｘ、ＳＣＳＩ、またはユニバーサルシリアルバス（ＵＳＢ）ベースのシステムバス（またはその他）であってよい。取り外し可能格納媒体１２０５は、任意の種類の外付けハードドライブ、ｆｌｏｐｐｙ（登録商標）ドライブ、ＩＯＭＥＧＡ（登録商標）、Ｚｉｐドライブ、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ等であってよい。
【０１２７】
ここに記載する実施形態は、コンピュータ（またはその他の電子デバイス）にあるプロセスを実行させるようプログラミングするために利用されてよい命令を格納する機械可読媒体を含んでよいコンピュータプログラムプロダクトとして提供されてよい。機械可読媒体には、これらに限定はされないが、ｆｌｏｐｐｙ（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、フラッシュメモリ、または、電子命令を格納するのに適したその他の種類の媒体／機械可読媒体が含まれてよい。さらにここに記載する実施形態は、さらに、コンピュータプログラムプロダクトとしてダウンロードされてもよい（ダウンロードにより、プログラムが遠隔のコンピュータから、要求を発しているコンピュータへと、搬送波その他の伝播媒体で具現化されるデータ信号によって通信リンク（モデルまたはネットワーク接続等）を介して伝達される）。
【０１２８】
示されているように、メインメモリ１２０４は、ここで説明した機能をサポートする拡張可能コンテンツ配信アプリケーション１２５０−１で符号化される。拡張可能コンテンツ配信アプリケーション１２５０−１（および／またはここで記載するその他のリソース）は、データおよび／または論理命令（例えばメモリ、または、ディスク等の別のコンピュータ可読媒体に格納されているコード）等の、ここで記載した様々な実施形態における処理機能をサポートするソフトウェアコードとして具現化することができる。
【０１２９】
ある実施形態の処理中に、プロセッサ（１または複数）１２０２は、メインメモリ１２０４に、バス１２０１経由でアクセスして、拡張可能コンテンツ配信アプリケーション１２５０−１の論理命令に対する起動、走らせる処理、実行、解釈、または行う処理（launch, run, execute, interpret, or otherwise perform）等の動作を行うことができる。拡張可能コンテンツ配信アプリケーション１２５０−１の実行により、拡張可能コンテンツ配信プロセス１２５０−２中に処理機能が生成される。つまり、拡張可能コンテンツ配信プロセス１２５０−２は、コンピュータシステム１２００内のプロセッサ１２０２（１または複数）内で、またはこれに対して実行される拡張可能コンテンツ配信アプリケーション１２５０−１の１以上の部分を表している。
【０１３０】
ここで、ここで説明した処理を実行する拡張可能コンテンツ配信プロセス１２５０−２に加えて、他の実施形態として、拡張可能コンテンツ配信アプリケーション１２５０−１自体（つまり、実行されない、または、実行しない論理命令および／またはデータ）が含まれてもよい点に留意されたい。拡張可能コンテンツ配信アプリケーション１２５０−１は、ｆｌｏｐｐｙ（登録商標）ディスク、ハードディスク、または光媒体等のコンピュータ可読媒体（例えばレポジトリ）上に格納することができる。他の実施形態では、拡張可能コンテンツ配信アプリケーション１２５０−１を、ファームウェア、読み取り専用メモリ（ＲＯＭ）等のメモリの種類のシステムに格納することもでき、さらに本例のように、メインメモリ１２０４内の（例えばランダムアクセスメモリまたはＲＡＭ内の）実行可能コードとして格納することもできる。例えば拡張可能コンテンツ配信アプリケーション１２５０−１は、取り外し可能格納媒体１２０５、読み取り専用メモリ１２０６、および／または、大容量格納デバイス１２０７に格納することもできる。
【０１３１】
コンピュータシステム１２００がサポートする機能の例、より具体的には、拡張可能コンテンツ配信アプリケーション１２５０−１および拡張可能コンテンツ配信プロセス１２５０−２に関連する機能は、図１−図１１を参照して上述した通りである。
【０１３２】
これらの実施形態に加えて、他の実施形態として、プロセッサ１２０２（１または複数）内の拡張可能コンテンツ配信アプリケーション１２５０−１を、拡張可能コンテンツ配信プロセス１２５０−２として実行することを含んでもよい。従って当業者であれば、コンピュータシステム１２００が、他のプロセスおよび／またはソフトウェアおよびハードウェアコンポーネント（例えば、ハードウェアリソースの割り当ておよび利用を制御するオペレーティングシステム等）を含むことができる旨を理解するだろう。
【０１３３】
記載してきたように、本発明の実施形態は、様々な段階および処理を含む。これら様々な段階は、ハードウェアコンポーネントにより実行されてもよいし、機械実行可能命令に具現化されていてもよく、これを利用して、命令をプログラミングされた汎用または専用プロセッサがこれら処理を行うことができるようになる。また、段階は、ハードウェア、ソフトウェア、および／または、ファームウェアの組み合わせにより実行されてもよい。「モジュール」という用語は、内蔵型の機能コンポーネントのことであり、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組み合わせを含んでよい。
【０１３４】
ここに記載した実施形態は、１以上のコンピュータシステム内で論理上の段階として実装される。論理上の処理は、（１）１以上のコンピュータシステム内で実行される一連のプロセッサ実装段階として、および、（２）１以上のコンピュータシステム内の相互接続された機械または回路モジュールとして、実装される。実装形態は、本発明を実装するコンピュータシステムのパフォーマンス要件に応じて選択される事項である。従って、ここで記載する本発明の実施形態を構成する論理上の処理は、処理、段階、オブジェクト、またはモジュールとして様々に呼称される。さらに、これら論理上の処理は、そうではないと明示されていたり、請求項の文言から必然的にそうでなければならなかったりする場合を除いて、任意の順序で実行されてよい旨を理解されたい。
【０１３５】
ここに記載した実施形態には、本発明の範囲を逸脱しない範囲で様々な変形例および追加が可能である。例えば、上述した実施形態では特定のフィーチャが言及されているが、本発明の範囲はさらに、フィーチャ同士が異なる組み合わせをされた実施形態、および、上述したフィーチャを全く含まない実施形態も含みうる。このように、本発明の範囲は、これら全ての変形例、変更例、および修正例を全て、均等物である実施形態として含むことが意図されている。
【図１】
0005842816.tif 000002
【図２】
0005842816.tif 000003
【図３】
0005842816.tif 000004
【図４】
0005842816.tif 000005
【図５】
0005842816.tif 000006
【図６】
0005842816.tif 000007
【図７】
0005842816.tif 000008
【図８】
0005842816.tif 000009
【図９】
0005842816.tif 000010
【図１０】
0005842816.tif 000011
【図１１】
0005842816.tif 000012
【図１２】
0005842816.tif 000013