(57)【要約】  コンテンツ配信ネットワーク（ＣＤＮ）は典型的な構成としてリクエストをＣＤＮサーバーに差し向けるマッピング・システムを含む。１つまたは２つ以上のピア・マシーンをＣＤＮと連携させた上で、ＣＤＮマッピング・システムを利用して所与のピアがＰ２Ｐネットワーク上の別のピア、および/またはＣＤＮサーバーを位置特定できるようにする。このハイブリッド・アプローチを利用して、ＣＤＮエッジ・ネットワークから、またはＰ２Ｐネットワークから、またはこれら２つのネットワークからカスタマー・コンテンツを配信することができる。１つの実施形態では、カスタマー・コンテンツをＣＤＮへアップロードし、エッジ・ネットワークまたはこれと連携するストレージ・ネットワークに格納する。次いで、ＣＤＮエッジ・ネットワークを利用してＰ２Ｐネットワークを事前準備させ、Ｐ２Ｐネットワークにカスタマー・コンテンツに対するコンテンツ配信需要の一部を引き受けさせることができる。配信にエッジ・ネットワークを利用すべきか、ピア・ネットワーク・リソースを利用すべきかは負荷およびトラフィック条件に基づいて決定すればよい。
2010503901.tif 000002
【特許請求の範囲】
【請求項１】
ＣＤＮサーバーにリクエストを差し向けるマッピング・システムを有するコンテンツ配信ネットワーク（ＣＤＮ）の配信方法であって、
ピアツーピア（Ｐ２Ｐ）ネットワークから成る１つまたは２つ以上のピア・マシーンをＣＤＮと連携可能にし；
ＣＤＮマッピング・システムを利用して所与のピアがＰ２Ｐネットワーク上の他方のピアとＣＤＮサーバーのうちの一方を位置特定できるようにするステップから成る配信方法。
【請求項２】
ＣＤＮマッピング・システムを利用するステップが
ＣＤＮマッピング・システムにおいて所与のピアからのリクエストを受信し；
Ｐ２Ｐネットワーク上の最も近いピアの位置を求め；
情報を所与のピアに返送することによって所与のピアが最も近いピアを位置特定することを可能にするステップを含む請求項１に記載の方法。
【請求項３】
マッピング・システムのコンポーネントをピア・マシーンにオフロードすることによってピア・マシーンがマッピング・システムを使用できるようにするステップをも含む請求項１に記載の方法。
【請求項４】
連携可能にするステップがドメインの順序集合を含むメタファイルを提供するステップを含む請求項１に記載の方法。
【請求項５】
ドメインの順序集合がＣＤＮマッピング・システムによってリゾルブされる１つまたは２つ以上のドメインを含む請求項４に記載の方法。
【請求項６】
１つまたは２つ以上のドメインが順序集合であり、集合の順序によって所与のピアがＰ２Ｐネットワーク上の他方のピアを識別するのか、ＣＤＮサーバーを識別するのかが決定される請求項５に記載の方法。
【請求項７】
ＣＤＮサーバーがＰ２Ｐネットワークによってフェイルオーバーとして利用される請求項１に記載の方法。
【請求項８】
エッジ・ネットワークを有するコンテンツ配信ネットワーク（ＣＤＮ）において、
ＣＤＮにアップロードされたカスタマー・コンテンツを受信し；
カスタマー・コンテンツをエッジ・ネットワークかまたはエッジ・ネットワークと連携するストレージ・ネットワークに格納し；
ピアツーピア（Ｐ２Ｐ）ネットワークを含む１つまたは２つ以上のピア・マシーンをＣＤＮと連携可能にし；
エッジ・ネットワークおよびＰ２Ｐネットワークを利用してカスタマー・コンテンツを配信するステップから成る配信方法。
【請求項９】
先ずエッジ・ネットワークを利用してカスタマー・コンテンツを配信した後は、Ｐ２Ｐネットワークがカスタマー・コンテンツ配信の責務の一義的責任を負う請求項８に記載の方法。
【請求項１０】
Ｐ２Ｐネットワーク上の所与のピア・マシーンがＰ２Ｐクライアント・コンポーネントを含むダウンロード・マネジャーである請求項８に記載の方法。
【請求項１１】
エッジ・ネットワークを有するコンテンツ配信ネットワーク(ＣＤＮ)において、
ＣＤＮサーバーにおいてコンテンツ・リクエストを受信し；
コンテンツ・リクエストが、エッジ・ネットワーク、または１つまたは２つ以上のピア・マシーンを含み且つＣＤＮと連携するピア・ネットワークを利用してコンテンツを配信可能であることを示すシグネチャと関連があるか否かを判断し；
コンテンツ・リクエストがシグネチャと関連があるなら、リクエストをエッジ・ネットワークによって処理すべきか、ピア・ネットワークによって処理すべきかを判断し；
この判断に基づいてリクエストを処理する配信方法。
【請求項１２】
シグネチャはリクエスト・ヘッダーと関連がある請求項１１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は２００６年９月６日付け出願第６０／８４３，１５８号および２００６年１２月１４日付け出願第６０／８７４，７９０号に基づき、これらの出願に関する優先権を主張する。
【０００２】
本発明は分散ネットワークにおけるコンテンツ配信に係わる。
【公知技術の簡単な説明】
【０００３】
分散コンピュータ・システムは公知である。このような分散コンピュータ・システムの１例として、サービス・プロバイダーによって運営・管理される「コンテンツ配信ネットワーク」または「ＣＤＮ」がある。サービス・プロバイダーは一般に第三者のためにサービスを提供する。この種の「分散システム」はコンテンツ配信やアウトソースド・サイト・インフラストラクチャーの支援のような種々のサービスを容易にするようデザインされたソフトウェア、システム、プロトコルおよび技術を含め、単一の、また複数のネットワークによってリンクされた自律的コンピュータの集合を意味する。典型的には、「コンテンツ配信」はコンテンツの蓄積、キャッシング、または転送、コンテンツ・プロバイダーに代わってのメディアおよびアプリケーションのストリーミング、さらには、これと併用される補助的技術、例えば、ＤＮＳリクエスト・ハンドリング、プロビジョニング、データ・モニタリングおよびレポーティング、コンテンツ・ターゲティング、パーソナライゼーション、およびビジネス・インテリジェンス（これらに限定されない）を意味する。「アウトソースド・サイト・インフラストラクチャー」とは、エンティティが第三者のウェブサイト・インフラストラクチャーの全部または一部をその第三者に代わって運営および/管理することを可能にする分散システムおよび関連技術を意味する。
【０００４】
ピアツーピア（Ｐ２Ｐ）ネットワークも公知であり、ファイル・シェアリングなどの目的に利用されている。ピアツーピア（Ｐ２Ｐ）コンピュータ・ネットワークは所与の専用サーバー群に集中するのではなく、主としてネットワーク参加者の演算能力および処理能力に依存する。Ｐ２Ｐネットワークは主としてその場その場の接続を介してノードを接続するのに利用されることが多い。純粋なピアツーピア・ネットワークにはクライアントかサーバーかという概念はなく、対等のピア・ノードがネットワーク上の他のノードに対して「クライアント」および「サーバー」として同時に機能するだけである。エンティティおよびビジネス・モデルによっては、或るタスク（例えば、検索）にはクライアント・サーバー構造として、他のタスクにはピアツーピア構造として機能するというハイブリッド・アプローチを使用するものがある。
【発明の概要】
【０００５】
一般に、コンテンツ配信ネットワーク（ＣＤＮ）はリクエストをＣＤＮサーバーに差し向けるマッピング・システムを含む。1つまたは２つ以上のピア・マシーンをＣＤＮと連携させ、ＣＤＮマッピング・システムを利用することによって、所与のピアがＰ２Ｐネットワーク上の別のピア、および/またはＣＤＮサーバーを位置特定できるようにする。このようなハイブリッド・アプローチを利用することによって、ＣＤＮエッジ・ネットワークまたはＰ２ＰネットワークからＣＤＮカスタマー・コンテンツを配信することができる。１つの実施形態として、カスタマー・コンテンツをＣＤＮにアップロードしてエッジ・ネットワークまたはこれと連携するストレージ・ネットワークに格納する。次いで、ＣＤＮエッジ・ネットワークを利用することによってＰ２Ｐネットワークを事前準備し、このＰ２Ｐネットワークを利用することによってカスタマー・コンテンツに関する配信要求の
一部を負担することができる。配信のためにエッジ・ネットワークを利用すべきか、ピア・ネットワーク・リソースを利用すべきかは負荷およびトラフィック条件に基づいて決定すればよい。
【０００６】
以上に本発明の比較的核心的な構成要件の幾つかを説明した。これらの構成要件は飽くまでも説明のための例であり、本発明を異なる態様で適用するか、または後述するような変更態様で実施することによって、さらに多くの有利な成果を達成することができる。
【０００７】
本発明とその利点の詳細を、添付の図面を参照して以下に説明する。
【図面の簡単な説明】
【０００８】
【図１】図１は本発明を実施する代表的なコンテンツ配信ネットワークを示す。
【図２】図２は図１のコンテンツ配信ネットワークの代表的なエッジ・サーバーを示す。
【図３】図３は代表的なハイブリッドＣＤＮ-Ｐ２Ｐネットワークを示す。
【図４】図４はピア・クライアントとして設定されたダウンロード・マネジャーを含む代表的なピア・インターネット-アクセシブル・マシーンを示す。
【発明を実施するための形態】
【０００９】
本発明は図１および２に示すようなコンテンツ配信ネットワークとして実施することができる。しかし、本発明はその利用がＣＤＮに限られるものではなく、１つのエンティティが分散ネットワークを運営し、このネットワークから第三者コンテンツが分配されるいかなる環境にも実施することができる。
【００１０】
体表的な実施形態においては、分散コンピュータ・システムをＣＤＮとして構成し、インターネットに一連のマシーン１０２ａ-ｎが分散していると想定する。多くの場合、マシーンの多くはインターネットのエッジの近傍に、即ち、エンド・ユーザー・アクセス・ネットワークに、またはその近傍に配置されたサーバーである。ネットワーク・オペレーションズ・コマンド・センター（ＮＯＣＣ）１０４を利用してシステム中の種々のマシーンの動作を管理・運用することができる。第三者、例えば、ウェブ・サイト１０６がコンテンツ（例えば、ＨＴＭＬ、埋め込まれたページ・オブジェクト、ストリーミング・メディア、ソフトウェア・ダウンロード、など）の配信を分散コンピュータ・システム１００に、特に、「エッジ」サーバーにオフロードする。多くの場合、コンテンツ・プロバイダーは所与のコンテンツ・プロバイダー・ドメインまたはサブドメインを（例えば、ＤＮＳ
ＣＮＡＭＥによって）エイリアシング処理することによってそのコンテンツ配信をサービス・プロバイダー自体のドメイン・ネーム・サービスによって管理されるドメインにオフロードする。このようなコンテンツを希望するエンド・ユーザーを分散コンピュータ・システムに差し向けることによってより確実に且つ効率的にコンテンツを得ることができる。詳しくは図示しないが、分散コンピュータ・システムはその他のインフラストラクチャー、例えば、エッジ・サーバーから使用データおよびその他のデータを収集し、１つの領域または一連の領域を通して集約し、これを他のバック-エンド・システム１１０、１１２、１１４および１１６に通すことによって、モニタリング、ロッギング、警告、請求書作成、管理その他の運用・管理機能を容易にすることができる分散データ収集システムをも含むことができる。分散ネットワーク・エージェント１１８はネットワークおよびサーバー負荷をモニターしてネットワーク、トラフィックおよび負荷データを、ＣＤＮによる管理下にあるコンテンツ・ドメインについて回答するＤＮＳ問い合わせ処理機構１１５にデータをロードする。分散データ伝送機構１２０を利用することによって、制御情報（例えば、コンテンツを管理し、負荷平衡を容易にする、などを目的とするメタデータ）をエッジ・サーバーに配分することができる。図２に示すように、所与のマシーン２００は１つまたは２つ以上のアプリケーション２０６ａ-ｎを支援するオペレーティング・シス
テム・カーネル２０４（例えば、リナックスまたはその改良バージョン）を運用するコモディティー・ハードウェア２０２（例えば、インテル ペンティアム・プロセッサ）を含む。コンテンツ配信サービスを容易にするため、所与のマシーンは多くの場合、一連のアプリケーション、例えば、ＨＴＴＰウェブ・プロキシ２０７、ネーム・サーバー２０８、ローカル・モニタリング・プロセス２１０、分散データ収集プロセス２１２、などを運用する。ストリーミング・メディアに関しては、多くの場合、マシーンは支援されるメディア・フォーマットに応じて、１つまたは２つ以上のメディア・サーバー、例えば、ウィンドウズ・メディア・サーバー（ＷＭＳ）またはフラッシュ２．０サーバーなどを含む。
【００１１】
図２に示すＣＤＮエッジ・サーバーは好ましくは構成システムを利用するエッジ・サーバーに配分されている構成ファイルを利用して、好ましくはドメイン特化型、カスタマー特化型の１つまたは２つ以上の広範なコンテンツ配信特性を提供するように構成されている。所与の構成ファイルはＸＭＬをベースとし、１つまたは２つ以上の高度のコンテンツ処理特性を容易にする一連のコンテンツ処理規則および命令を含むことが好ましい。構成ファイルは分散データ伝送機構を介してＣＤＮエッジ・サーバーに配信することができる。米国特許第７，１１１，０５７号明細書はエッジ・サーバー・コンテンツ制御情報を配信・管理するための有用なインフラストラクチャーを開示しており、このようなエッジ・サーバー制御情報はＣＤＮサービス・プロバイダー自体、または(エクストラネットなどを介して）オリジン・サーバーを運用するコンテンツ・プロバイダー・カスタマーによって設定することができる。エッジ・サーバー・マネジャー・プロセスがコンテンツに対するリクエストを受信すると、このリクエストと関連するカスタマー・ホストネームと合致するようにインデックス・ファイルを検索する。合致しなければ、エッジ・サーバー・プロセスはリクエストを拒絶する。合致すれば、エッジ・サーバー・プロセスは構成ファイルからメタデータをロードすることによってこのリクエストをどのように処理すべきかを判断する。この処理プロセスは米国特許第７，２４０，１００号明細書に記述されている。
【００１２】
ＣＤＮ ＤＮＳ問い合わせ処理機構はそれぞれのユーザー・リクエストをコンテンツ配信のための所与のＣＤＮサーバーに差し向ける。この機構を実施する１つのアプローチとして、「トップレベル」マップが特定のリクエストを所与の数のサーバー領域のうちの１つに差し向け、「低レベル」マップがこのリクエストをさらに領域内の所与のサーバーに差し向ける。例えば、トップレベルのマップはそれぞれのインターネットＩＰアドレス・ブロックを、このブロックのうち最速でクライアントにコンテンツを配信できるＣＤＮサーバー領域と連携させることができる。このマップの作成に備えて、マッピング・エージェント（例えば、ＣＤＮサーバー領域に１つずつ）は下記の情報を収集することができる：（ａ）ＩＰブロック（インターネットに現在使用されているＩＰアドレス・ブロック・リスト）、（ｂ）負荷（ＣＤＮによって現在処理中のウェブ負荷量のＩＰブロック毎の測定値）、（ｃ）通信コスト（例えば、それぞれの{ＩＰブロック、ＣＤＮサーバー領域}ペア毎に測定される通信コスト・リスト）、および（ｄ）容量（例えば、それぞれのＣＤＮサーバー領域のサーバー負荷およびネットワーク負荷の総計）。種々の方法を組み合わせることによって（例えば、グローバル・インターネットにおけるエンドポイントＬＡＮのような）すべてのリーフ（葉）ネットワークを表わすＩＰブロックをリストに集約することができる：即ち、ＢＧＰピアリング、ネットワーク登録データベース（例えば、ＲＩＰＥ、ＡＰＮＩＣおよびＡＲＩＮ）からの情報収集、（例えば、ＵＵＮＥＴのような）極めて大きいブロックへのランダムなトレースルート。それぞれのＩＰブロックが発生させるＣＤＮへの負荷はＣＤＮコンテンツ・サーバーから測定値を集め、合計することによって求めることができる。以下に列記する１つまたは２つ以上の異なる通信コストを利用してＩＰブロックとＣＤＮサーバー領域との間の通信コストを求めることができる：サーバー領域のネットワーク健康状態（例えば、領域がアップ状態かダウン状態かを示唆する二進メトリックス）、ブロックとサーバー領域との間のＡＳＰＡＴＨ長さ（例えば、ＢＧＰか
ら供給される）、領域のマッピング・エージェントとＩＰブロック中の所与の点との間の往復時間（ＲＴＴ）、領域のマッピング・エージェントとＩＰブロック中の所与の点との間のパケット損失率、地理的距離など。個々のＩＰブロック/サーバー領域ペア毎に、リストにおける位置に比例するように設定された個々のメトリックを優先して、または加重してこれらのメトリックスを組み合わせ、単一のメトリックを求めることができる。容量測定値には２つのタイプがある：即ち、それぞれの領域における総サーバー容量とそれぞれの領域における物理的ネットワーク容量である。サーバー容量は、例えば、現在領域において作動中のサーバー数から求められる。物理的ネットワーク容量は、例えば、パケット・ペア測定で求められる。領域容量はこれら２つの測定結果の所与の関数（例えば、最小値）として計算することができる。
【００１３】
この実施例では、トップレベルのマップがそれぞれのＩＰブロックを所与のＣＤＮサーバー領域に対してマップする。トップレベル・マップを生成する１つの方法として、（例えば、{ＩＰブロック/サーバー領域}通信コストに基づいて）各ＩＰブロックの多数の候補領域を識別し、測定され、収集されたネットワーク情報のすべてを利用して２部グラフを作成し（例えば、グラフの一方の側にＩＰブロックのそれぞれを示し、他方の側にＣＤＮサーバー領域を示す）、次いで、このグラフに基づいて最小コスト・フロー・アルゴリズムを実行する。それぞれのＩＰブロック・ノードにこのノードから来る「フロー」として扱われる測定負荷値を標識する。アルゴリズムを実行した結果として、サーバー領域に対してＩＰブロック負荷が最適条件で割当てられる。この割当てがトップレベル・マップであり、周期的に生成されて動的ＤＮＳリクエスト処理機構に配信される。
【００１４】
上記のマップ生成プロセスは一例に過ぎず、これが本発明を制限するものではない。即ち、例えば、ＢＧＰまたは地理的情報に基づいてトップレベル・マップが所与のエッジ・サーバー領域を委任されるマップとなることもある。その場合、所与の領域内で１つまたは２つ以上の別の判定がなされることがある。例えば、領域内の低レベル・ネーム・サーバーが第１のマップを利用してどちらの領域がリクエストを受信すべきかを判断することができる（この領域はトップレベル・マップがリクエスト受信領域と判定した領域と一致することもあれば一致しないこともある）：選択された領域におけるこの低レベル・ネーム・サーバーは第２のマップを利用することによって領域内のエッジ・サーバー・ウェブ・プロキシを選択し、リクエストを処理することができる。マップを生成するため、すべてのエッジ・サーバー領域におけるソフトウェア・エージェントは公共インターネット上のデバイスまたはロケーションに対して定期的に（例えば、ピングおよびトレースルートのような）試験を行なう。これらの試験から収集されたデータは種々のマップ・メーキング・プロセスに提供される。
【００１５】
本発明はハイブリッドＣＤＮおよびＰ２Ｐネットワーク（「ハイブリッドＣＤＮ-Ｐ２Ｐ」）に係わる。例えば、Ｐ２Ｐネットワークの１つまたは２つ以上のピアがＣＤＮのエッジ・サーバーまたはエッジ・サーバー領域として利用される：あるいはＰ２Ｐ中の所与のピアがＣＤＮインフラストラクチャーから得られる所与の特性またはデータを活用するという形でＣＤＮを利用する。さらに他の実施形態として、所与のピアが他のピアからのコンテンツを位置特定できない場合、Ｐ２ＰネットワークがＣＤＮを所与のコンテンツのフェイルオーバー・ソースとして利用する。
【００１６】
図３は基本的なハイブリッドＣＤＮ-Ｐ２Ｐネットワークを示す。この実施例の場合、Ｐ２Ｐネットワーク３００はピア・マシーン３０２とピア・マシーン３０４から成り、ピア・マシーン３０２はＣＤＮの一部を形成するか、または所与のＣＤＮインフラストラクチャーまたはコンポーネントまたはデータにアクセスし、利用する能力を有する。ＣＤＮ内にピアを構成する方法の１つが参考のため本願明細書中に引用する米国特許第７，０１０，５７８号明細書に記述されているが、この技術が本発明を制限するものではない。い
うまでもなく、Ｐ２Ｐネットワーク３００のピア・マシーンの数は任意であり、多くの場合、その場の状況に応じてネットワークに採用されるマシーンのタイプに合わせて種々のピア・マシーンが採用される。典型的なピア・マシーンはサーバー、ワークステーション、パーソナルコンピュータ、またはその他のコンピュータ・デバイスまたはエンティティであり、いずれも本来はＣＤＮ自体の一部ではないデバイスまたはエンティティであり、ＣＤＮにおけるエッジ・サーバーの要求される機能の幾つかを実行するか、または所与のＣＤＮインフラストラクチャー、リソースまたはデータを活用するのに充分な計算および帯域幅能力を有するマシーンである。このように、ピアは典型的にはプロセッサから成り、オペレーティング・システム、アプリケーション・プログラム（場合によっては、ウェブ・プロキシおよびメディア・サーバー）、ネットワーク・インターフェース、ユーザー-インターフェースおよびその他のマン-マシーン・インターフェース、などを支援するのに充分なメモリおよびディスク・ストレージを含む。これらのマシーンの特定のハードウェアおよびソフトウェア条件は本発明の対象ではない。
【００１７】
１つの実施形態においては、所与のピアが他のピアから所与のコンテンツを得たい時に所与のピアを（Ｐ２Ｐネットワーク内で）最も近いピアに容易にマップできるように、以上に概説したＣＤＮマッピング・システム（またはそのコンポーネント）を設ける。公知技術では、Ｐ２Ｐネットワークに、ピアが他のピアを位置特定できないという問題があった。本発明では、ピアの位置特定を容易にするため、ＣＤＮマッピング・インフラストラクチャー、コンポーネントまたはデータ（例えば、マップ）にアクセスできる能力を付与する。図３において、ピア３０２にはＣＤＮインフラストラクチャー（例えば、マップ・マシーン、マップ、またはその他の同様のデータ）にアクセスすることによって所与のコンテンツをフェッチしたい場合に近傍のピア（例えば、ピア３０４）の位置を特定できる能力が付与されている。このような場合、ＣＤＮマップ中にＰ２Ｐネットワーク・ノードを含むようにＣＤＮマッピング・アーキテクチャーを増強する。これに代わる構成として、またはＣＤＮマッピング・インフラストラクチャーを増強する上にさらに、所与のピア・ノードにＣＤＮマッピング・プロセスまたはツール（例えば、ソフトウェア・エージェント）を設けることによってピアがマップ・メーキング・プロセスに含まれることを容易にする。こうすることによって、ピアはＣＤＮアークテクチャーにおけるノードに過ぎなくなり、マップ・メーキング・プロセス全体の一部となる。
【００１８】
本発明の１つの観点として、ピア・ノードが所与のコンテンツ・ファイル（例えば、グラフィック、画像、アプリケーション、メディア・ファイル、ソフトウェア・ダウンロード、またはフォーマットとは無関係なその他のディジタル・データ）を得ようとしている、と想定する。ピア・ノードは所与のアクセス・ツール、例えば、ウェブ・ブラウザー、メディア・プレイヤー、またはこれと等価の手段を駆使し、典型的にはＵＲＬを介してコンテンツ・ファイルをリクエストする。リクエスト（またはその一部）がＣＤＮに差し向けられ、ＣＤＮは、１つの実施形態として、メタファイルとも呼称されるファイルをピア・ノードに返送する。１つの実施形態において、このメタファイルは１つまたは２つ以上のＣＤＮまたはハイブリッドＣＤＮ-Ｐ２Ｐドメインまたはサブドメインを含み、ピア・ノードがこれを利用することによって所要のコンテンツを得る。例えば、メタファイルが、すべてのドメインについて権限を有するＣＤＮ ＤＮＳ問い合わせ機構によってそれぞれがリゾルブされるｐｅｅｒ．ａｋａ．ｎｅｔ、ｐｅｅｒ．ｃｄｎ．ｎｅｔ．などのような一連のドメインを含むものとする。この例では、第１のドメインがＰ２Ｐネットワークにおける他のピアに合わせられ、第２のドメインがＣＤＮネットワークにおけるエッジ・サーバー（従って、この例ではフェイルオーバーとして作用する）に合わせられる。このピアがバックアップとなるように順序を切替えることができるから、この順序付けは１例に過ぎない。いずれの場合にも、ピア・ノード・クライアントはリスト中の第１のドメインまたはサブドメインにＤＮＳ問い合わせをし、ＤＮＳは問い合わせはＣＤＮ ＤＮＳ問い合わせ機構を介してリゾルブされ、（この例では）Ｐ２Ｐネットワークにおける近傍の
ピアを識別し、このピアからコンテンツをフェッチする。この動作が失敗に終わるか、識別されたピアにピアが接触できないか、または（一度は接触した）識別されたピアがコンテンツを有していなければ、第２のドメインをトライし、今度はＣＤＮにおけるエッジ・サーバーに戻る。これはコンテンツを有し、オーバーロード状態ではないと考えられる近傍のエッジ・サーバーということになる。
【００１９】
このように、ハイブリッドＣＤＮ-Ｐ２Ｐがピア・ノードを利用するか、またはピア・ノードがＣＤＮインフラストラクチャーを利用することを可能にする。
【００２０】
他の実施形態として、ピア・ノードはソフトウェア・エージェントおよびその他のインテリジェンスを有し、ピア・ノードまたはＣＤＮエッジ・サーバー領域またはこの領域におけるエッジ・サーバーをより知的に選択することができる。この場合、（所与のＣＤＮトラスト・ドメイン内で確定された）所与のピア・ノードが（ＣＤＮインフラストラクチャーを含むことがある）周囲のネットワークを探査し、より知的なマッピング・デシジョンを容易にするのに利用できるローカル・マップを生成することができる。こうしてＣＤＮマッピング・インフラストラクチャーの種々のコンポーネント自体がトラスト・ピアにオフロードされ、Ｐ２Ｐネットワーク・エンティティ内またはこれらにまたがるアクティブなマッピング・デシジョンを可能にする。
【００２１】
上述したように、本発明の特徴は、所与のコンテンツが１つまたは２つ以上のピアから得られない場合にＰ２Ｐネットワーク（またはそれに含まれる所与のノード）がＣＤＮをフェイルオーバーとして利用できることにある。この場合、エンド・ユーザーがコンテンツ・パブリッシャー（典型的にはオリジン・サイト・インフラストラクチャー）に戻らなくても所与のコンテンツが得られるようにＣＤＮがバックストップとして作用する。従って、ＣＤＮは活性ベースではアクセスできそうもない「冷たい」コンテンツのようなある種のコンテンツに対する最終手段の宝庫として作用することができる。
【００２２】
ハイブリッドＣＤＮ-Ｐ２Ｐモデルは種々の利益をもたらす。このアプローチを利用すれば、Ｐ２Ｐモデルは配信コンポーネントに殆どコストをかけることなく優れた性能と有用性を提供することができる。さらに、ＣＤＮサービス・プロバイダーはエッジ・サーバーの配信容量を増大または増強するのに必要なＰ２Ｐリソースを利用することができる。例えば、ＣＤＮエッジ・キャッシュはＰ２Ｐネットワークのためのオリジンとして作用することができ、ＣＤＮを介してコンテンツが得られるとなれば、Ｐ２Ｐへの切換えが行なわれる。従って、ＣＤＮがブートストラップまたは作用することによってＰ２Ｐネットワークを配信できる状態に事前準備し、準備されたＰ２Ｐは最初の配信を引受けることができる。他の実施形態では、ＣＤＮも分散ストレージ容量を有するから、さらに完全なコンテンツ・オフロードが可能である。例えば、コンテンツを（例えば、ＦＴＰなどによって）ＣＤＮ分散ストレージに先ずアップロードすることができ、このストレージがエッジ・キャッシュへのイニシアル・オリジンとして作用し、次いで、ＣＤＮによって配信態勢に準備されたＰ２Ｐが使用される。
【００２３】
ハイブリッドＣＤＮ-Ｐ２Ｐネットワークをディジタル著作権管理下に運用することによって、ピアがコンテンツにアクセスしないか、さもなければ（他のピアに）コンテンツを転送することにより、（オリジナル配信についてもダウンストリーム配信についても）マネタイゼーションを回避することが好ましい。ＤＲＭ-に従って動作するハイブリッドＣＤＮ-Ｐ２Ｐはまた、ＣＤＮサービス・プロバイダーが加入コンテンツ・プロバイダーのためにコンテンツ配信を効率的に管理することを可能にする。ＣＤＮとの関係においてＤＲＭを使用する技術はＡｋａｍａｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ、Ｉｎｃ．が所有する米国特許出願公開第２００５/０２７８２５９号に記載されている。
【００２４】
本発明の他の特徴として、システム内に２つの異なるタイプのクライアント、即ち、クライアント・サーバーとクライアント・プレーヤーを有することが好ましい。公知技術においては、これらのコンポーネントは同じＰ２Ｐ技術の部分である：即ち、１つのエンティティがクライアントからダウンロードしたい時には、他のエンティティもクライアントからダウンロードできる能力を提供しなければならない。この実施形態では、従来のＰ２Ｐクライアントのようにプレーし、フェッチされたコンテンツを提供するクライアント・サーバーを利用することによってＰ２Ｐトランスポートを容易にする。但し、クライアント・プレーヤーはエンド・ユーザー・クライアント・ブラウザーとインターフェースすることによって（またはエンド・ユーザー・クライアント・ブラウザー内で、またはその一部として動作することによって）ファイルを得る（例えば、ＣＤＮではなくＰ２Ｐサーバーから）簡単なプラグ-イン（例えば、必要ではないが、ＡｃｔｉｖｅＸコントロール）であることが好ましい。クライアント・プレーヤーはファイヤーウォールを貫通する能力を有するがＰ２Ｐの役割を果す能力を持たないことが好ましい。即ち、他のピアへのＰ２Ｐによるコンテンツ配信のためにＣＤＮ（など）がクライアントにアクセスしたり利用したりすることはできない。クライアントとサーバーをこのように切り離すことによって、クライアント・プレーヤーの利用が簡単になり、ユビキタスになる。代表的な実施形態では、クライアント・プレーヤーは、例えば、ＣＤＮからの大量のファイルをダウンロードする作業を容易にするために使用されるダウンロード・マネジャーのようなＣＤＮ-関連の、またはその他のソフトウェアの１つのコンポーネントに過ぎない。このような場合、従来型のＣＤＮ大型フアィル・ダウンロード・マネジャーに適当なコード機能性を増補することによって、従来のＣＤＮサーバー（またはカスタマー・オリジン）またはＰ２Ｐネットワーク・サーバーからのダウンロードを協調させる。このように増補された阿吽ロード・マネジャーはインストールし易く、マルウェアの性質を備えることもなく、ファイルを他へ提供するのに如何なるリソースも必要としない。その使用を容易にするため、（Ｐ２Ｐクライアント・プレーヤーを備えるように改良された）ダウンロード・マネジャーは（例えば、１つまたは２つ以上のソフトウェア・ルーチンおよび適当なデータのような）インテリジェンスをも含むことによって、所与のオブジェクトをＣＤＮから得るか、Ｐ２Ｐから得るか、どちらのサーバーから得るかの判断を容易にする。典型的には、この判断は、例えば、性能、場所、コスト、コンテンツの入手可能性、またはこれらの組み合わせのような１つまたは２つ以上のファクタまたはメトリックスに基づいて下される。図４はそのアプローチを示す。図４において、ピアはブラウザー、およびＡｃｔｉｖｅＸコントロールとして作用するダウンロード・マネジャーを有するマシーン（コモディティ・ハードウェを運用するインターネット・アクセス可能なマシーンおよびオペレー-ティング・システム）である。本発明ではダウンロード・マネジャーが増補され、上記のようなＰ２Ｐクライアント・プレーヤーおよびこれに関連する機能性を含む。
【００２５】
上述したように、クライアント・プレーヤーは（例えば、ブラウザー・プラグ-イン、サーブレット、アプレット、ネーティブ・コードなどのような）任意の形態で実施することができる。好ましい実施形態として、ダウンロード・マネジャー（またはその等価物）のコンポーネントとして分散させ、ＣＤＮがこれを利用することによってリクエストするエンド・ユーザーに対する大量のファイル・ダウンロードを容易にする。図４はこの機能性を示す。この実施形態では、ピア・インターネット・アクセシブル・マシーンはメモリ４０２、ウェブ・ブラウザー４０４、ダウンロード・マネジャー４０６、およびＰ２Ｐクライアント・プレーヤー４０８から成る。
【００２６】
エッジ・サーバーはマッピングに関するデータを、所与のコンテンツ・リクエストに答えるべき場所の判断に組み入れることができる（例えば、エッジ・ネットワークおよび/またはピア・ネットワークを利用する）。上記のように、コンテンツ配信ネットワークはネットワーク全体に亘って所与のＣＤＮカスタマーのために負荷情報をトラックし、ＣＤＮマッピング・インフラストラクチャーがこのデータを自動的にエッジ・サーバーに送信
し、エッジ・サーバーがこれを利用することによってこのデータを如何なる形で且つどのようなトラフィック情報をピア・ネットワークに送信すべきかを判断する。同様に、もしピア・ネットワークが負荷情報を収集すれば、ピア・ネットワークもまた負荷およびその他の情報を報告することができる（例えば、ピア・ネットワークにかかっている負荷、余裕のあるピアの数、ピアの位置など）。使用すべきネットワーク（エッジおうおび/またはピア）に関する判断は、エッジ・サーバーが実際にコンテンツ・リクエストを受信する場合にはエッジ・サーバーによって下すことができる(即ち、ＣＤＮ ＤＮＳが上述したようにエッジ・サーバー領域およびエッジ・サーバーを識別し、ブラウザーがエッジ・サーバーから実際にコンテンツをリクエストした後）。このアプローチでは、図４に示すように、クライアントを利用することができる。具体的には、ユーザーのデスクトップにインストールされたクライアントがインストールされたブラウザーのｈｔｔｐまたはその他のリクエスト・ヘッダーにシグネチャを付加できると想定する。このシグネチャはユーザー・エージェント・リクエスト・ヘッダー、アクセプト-ランゲージ・ヘッダなどに加えることができる。典型的な例として、ユーザー・エージェント・ヘッダーまたはその他のリクエスト・ヘッダーは地方登記簿を介してウィンドウズ-ベースのマシーンにおいて修正することができる。（例えばＵＲＬの一部のような形で、シグネチャをエッジ・サーバーにおいて符号化するか、または符号化してエッジ・サーバーに提供することもできる)。ハイブリッドＣＤＮ-Ｐ２Ｐネットワークで配信されるオブジェクトに対するリクエストをエッジ・サーバーが受信すると、クライアントのシグネチャがリクエストと一致するか否かがチェックされる。このチェックは米国特許第７，２４０，１００号に記載されているようなメタデータ処理プロセスの制御下に、またはその他の態様で行なわれる。もしクライアントのリクエストにシグネチャがあれば、エッジ・サーバーはこのリクエストをどのように扱うか、即ち、オブジェクトそのものを配信するか、またはこのリクエストをピア・ネットワーク・リソースへリダイレクトするかを選択することができる。後者の場合には、ピア・ネットワーク・リソースが配信を開始するか、またはリクエストをエッジ・サーバーまたはその他のＣＤＮリソースへリダイレクトすることができる。この際、上述したように、付加およびトラフィックデータを利用してこのような判断の参考にすることができる。
【００２７】
以上に説明した本発明の範囲は別紙に記載の請求項によって定義される。
【図１】
2010503901.tif 000003
【図２】
2010503901.tif 000004
【図３】
2010503901.tif 000005
【図４】
2010503901.tif 000006
【国際調査報告】
2010503901.tif 000007