(57)【特許請求の範囲】
【請求項１】
コンテンツデリバリネットワークサービスに対応する第１のＤＮＳサーバにて、リクエストされたリソースに対応する、クライアントコンピューティングデバイスからのＤＮＳクエリを取得するステップと、
前記クライアントコンピューティングデバイスに関連付けられたクラスを決定するステップと、
前記クライアントコンピューティングデバイスの前記クラスに基づきルーティング情報を決定するステップと、
前記リクエストされたリソースの配信に関連付けられた性能を監視するステップと、
前記クラスに関する前記ルーティング情報の更新が必要であるか否かを配信能力に基づき決定するステップと、
更新が必要である場合には、前記クラスに関する前記ルーティング情報を変更するステップと、
を有することを特徴とする方法。
【請求項２】
前記クラスに関する前記ルーティング情報を変更するステップは、リソースリクエストを処理するためのコンピューティングデバイスのリストを変更するステップを含む、
請求項１記載の方法。
【請求項３】
前記クラスに関する前記ルーティング情報を変更するステップは、リソースリクエストを処理するために使用される特定のコンピューティングデバイスが選択される確率を変更するステップを含む、
請求項１記載の方法。
【請求項４】
前記クラスは指定された地理的なロケーションに対応する、
請求項１記載の方法。
【請求項５】
前記ルーティング情報を決定するステップは、前記クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するキャッシュコンポーネントを選択するステップを含む、
請求項１記載の方法。
【請求項６】
前記クラスに関する前記ルーティング情報を変更するステップは、前記第１のＤＮＳサーバおよびその他のＤＮＳサーバの選択確率を比較するステップと、低い選択確率を有するＤＮＳサーバがより多く選択されるように選択確率を高めるステップと、を含む、
請求項１記載の方法。
【請求項７】
コンテンツデリバリネットワークサービスに対応する第１のＤＮＳサーバにて、リクエストされたリソースに対応する、クライアントコンピューティングデバイスからのＤＮＳクエリを取得する手段と、
前記クライアントコンピューティングデバイスに関連付けられたクラスを決定する手段と、
前記クライアントコンピューティングデバイスの前記クラスに基づきルーティング情報を決定する手段と、
前記リクエストされたリソースの配信に関連付けられた性能を監視する手段と、
前記クラスに関する前記ルーティング情報の更新が必要であるか否かを配信能力に基づき決定する手段と、
更新が必要である場合には、前記クラスに関する前記ルーティング情報を変更する手段と、
を有することを特徴とするシステム。
【請求項８】
前記クラスに関する前記ルーティング情報を変更する手段は、リソースリクエストを処理するためのコンピューティングデバイスのリストを変更する手段を含む、
請求項７記載のシステム。
【請求項９】
前記クラスに関する前記ルーティング情報を変更する手段は、リソースリクエストを処理するために使用される特定のコンピューティングデバイスが選択される確率を変更する手段を含む、
請求項７記載のシステム。
【請求項１０】
前記クラスは指定された地理的なロケーションに対応する、
請求項７記載のシステム。
【請求項１１】
前記ルーティング情報を決定する手段は、前記クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するキャッシュコンポーネントを選択する手段を含む、
請求項７記載のシステム。
【請求項１２】
前記クラスに関する前記ルーティング情報を変更する手段は、前記第１のＤＮＳサーバおよびその他のＤＮＳサーバの選択確率を比較する手段と、低い選択確率を有するＤＮＳサーバがより多く選択されるように選択確率を高める手段と、を含む、
請求項７記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
一般的に、コンピューティングデバイスおよび通信ネットワークは情報を交換するために利用することができる。通常の用途では、コンピューティングデバイスが通信ネットワークを介して他のコンピューティングデバイスからコンテンツを要求することができる。例えば、パーソナルコンピューティングデバイスのユーザは、インターネットを介してサーバコンピューティングデバイスからウェブページを要求するために、ソフトウェアブラウザアプリケーションを利用することができる。そのような実施形態では、ユーザコンピューティングデバイスはクライアントコンピューティングデバイスと称され、またサーバコンピューティングデバイスはコンテンツプロバイダと称される。
【０００２】
一般的に、コンテンツプロバイダには、リクエストされたコンテンツのクライアントコンピューティングデバイスへの効率的な伝送、および／または、コンテンツの伝送に関するコストを頻繁に考慮しながら、リクエストされたコンテンツをクライアントコンピューティングデバイスに提供することが推奨されている。より広範な規模の実施形態に関しては、コンテンツプロバイダが非常に多くのコンピューティングデバイスからコンテンツリクエストを受信する可能性があり、それによりコンテンツプロバイダのコンピューティングリソースに負担が掛かるおそれがある。さらには、クライアントコンピューティングデバイスによってリクエストされたコンテンツが多数の要素を有していることも考えられ、それによりコンテンツプロバイダのコンピューティングリソースにはさらなる負担がかかるおそれがある。
【０００３】
１つの例を参照すると、リクエストされたウェブページ、またはオリジナルのコンテンツを多数の付加的なリソース、例えばウェブページと共に表示することができる画像、動画などと関連付けることができる。１つの特定の実施形態においては、ウェブページの付加的なリソースが、多数の埋め込みリソース識別子、例えばユニフォーム・リソース・ロケータ（「ＵＲＬ」）によって識別される。次に、クライアントコンピューティングデバイスのソフトウェアは埋め込みリソース識別子を処理し、コンテンツリクエストを生成する。クライアントコンピューティングデバイスは付加的なリソースに関するリクエストを参照先のコンテンツプロバイダコンピューティングデバイスに伝送することが考えられるので、埋め込みリソースに関連付けられたリソース識別子がコンテンツプロバイダに関連付けられたコンピューティングデバイスを参照することが多い。したがってコンテンツリクエストを満たすために、コンテンツプロバイダは、ウェブページに関連付けられたデータ、ならびに、埋め込みリソースに関連付けられたデータをクライアントコンピューティングデバイスに提供する。
【０００４】
コンテンツデリバリネットワーク（「ＣＤＮ」）サービスプロバイダを利用して、ウェブページおよび／またはウェブページ内で識別されるリソース識別子のようなリクエストされたコンテンツの配信を容易にすることを試みるコンテンツプロバイダも存在する。ＣＤＮサービスプロバイダは一般的に、通信ネットワーク内に存在し、種々のコンテンツプロバイダからのコンテンツを管理することができる多数のコンピューティングデバイスを管理する。コンテンツプロバイダは、コンテンツプロバイダのコンテンツのうちの幾つかまたは全てのコンテンツをＣＤＮサービスプロバイダのコンピューティングデバイスからリクエストすることをクライアントコンピューティングデバイスに指示することができるか、さもなければ提案することができる。
【０００５】
コンテンツプロバイダと同様に、一般的にＣＤＮサービスプロバイダにも、リクエストされたコンテンツをクライアントコンピューティングデバイスに効率的に伝送すること、および／または、コンテンツの伝送に関連するコストを頻繁に考慮しながら、リクエストされたコンテンツをクライアントコンピューティングデバイスに提供することが推奨されている。したがって、ＣＤＮサービスプロバイダは、サービスレベルアグリーメント（ＳＬＥ）を満たすため、もしくは一般的に配信サービスの品質を改善するために、リクエストされたコンテンツの配信の待ち時間のような要因を頻繁に考慮している。
【０００６】
上述の種々の態様、またそれに伴う本発明の多くの利点は、添付の図面と関連付けられた以下の発明の詳細な説明を参照することによってより容易に認められ、またより良く理解される。
【図面の簡単な説明】
【０００７】
【図１】多数のクライアントコンピューティングデバイス、コンテンツプロバイダおよびコンテンツデリバリネットワークサービスプロバイダを含む、コンテンツ配信環境の概略的なブロック図を示す。
【図２】コンテンツデリバリネットワークサービスプロバイダを用いたコンテンツプロバイダの登録を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図３】クライアントコンピューティングデバイスからコンテンツプロバイダへのコンテンツリクエストの生成および処理を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図４】クライアントコンピューティングデバイスからコンテンツデリバリネットワークサービスプロバイダへと伝送される、埋め込みリソースに対応するＤＮＳクエリの生成および処理の一実施形態を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図５Ａ】クライアントコンピューティングデバイスからコンテンツデリバリネットワークサービスプロバイダへと伝送される、埋め込みリソースに対応するＤＮＳクエリの生成および処理の別の実施形態を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図５Ｂ】クライアントコンピューティングデバイスからコンテンツデリバリネットワークサービスプロバイダへと伝送される、第１の択一的なリソース識別子に対応するＤＮＳクエリの後続の生成および処理の実施形態を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図５Ｃ】クライアントコンピューティングデバイスからコンテンツデリバリネットワークサービスプロバイダへと伝送される、第２の択一的なリソース識別子に対応するＤＮＳクエリの後続の生成および処理の実施形態を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図６】クライアントコンピューティングデバイスからコンテンツデリバリネットワークサービスプロバイダへと伝送される、埋め込みリソースリクエストの生成および処理を示している、図１のコンテンツ配信環境の概略的なブロック図を示す。
【図７】キャッシュサーバコンポーネントを選択するためにコンテンツデリバリネットワークサービスプロバイダによって実行されるリクエストルーティングルーチンのフローチャートを示す。
【図８】ルーティング情報を更新するためにコンテンツデリバリネットワークサービスプロバイダによって実行されるリクエストルーティングルーチンのフローチャートを示す。
【発明を実施するための形態】
【０００８】
一般的に、本発明は、クライアントコンピューティングデバイスからコンテンツデリバリネットワーク（「ＣＤＮ」）サービスプロバイダに対してなされるリソースリクエストの管理および処理に関する。殊に、本発明の種々の態様を、クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいたリソースリクエストに関連付けられたルーティング情報に関して説明する。本発明の種々の態様を種々の実施例および実施形態に関して説明するが、当業者であれば、本明細書に記載されている実施形態および実施例は限定を意図したものではないことが分かる。
【０００９】
図１は、コンテンツリクエストを管理および処理するためのコンテンツ配信環境１００の概略的なブロック図を示す。図１に示されているように、コンテンツ配信環境１００には、コンテンツプロバイダおよび／またはＣＤＮサービスプロバイダからコンテンツをリクエストする、複数のクライアントコンピューティングデバイス１０２（一般的にクライアントと称される）が含まれる。図示されている実施例において、クライアントコンピューティングデバイス１０２は、パーソナルコンピューティングデバイス、ラップトップコンピューティングデバイス、ハンドヘルドコンピューティングデバイス、ターミナルコンピューティングデバイス、モバイルデバイス、ワイヤレスデバイス、種々の電子装置および電子機器などを含む多種多様なコンピューティングデバイスに対応することができる。図示されている実施例において、クライアントコンピューティングデバイス１０２は、通信ネットワーク１０８、例えばワイドエリアネットワークまたはローカルエリアネットワークを介する通信を確立するために必要なハードウェアコンポーネントおよびソフトウェアコンポーネントを有している。例えば、クライアントコンピューティングデバイス１０２に、インターネットまたはイントラネットを介する通信を容易にするためのネットワーク機器およびブラウザソフトウェアアプリケーションを実装することができる。
【００１０】
図１には図示されていないが、各クライアントコンピューティングデバイス１０２は何らかのタイプのローカルＤＮＳリゾルバコンポーネント、例えばクライアントコンピューティングデバイスに属するＤＮＳクエリを生成するＤＮＳネームサーバを使用する。１つの実施例においては、クライアントコンピューティングデバイス１０２が所属している企業ネットワークによってローカルＤＮＳリゾルバコンポーネントを提供することができる。別の実施例においては、クライアントコンピューティングデバイス１０２との通信ネットワークコネクションを提供するインターネットサービスプロバイダ（ＩＳＰ）によってローカルＤＮＳリゾルバコンポーネントを提供することができる。
【００１１】
コンテンツ配信環境１００には、通信ネットワーク１０８を介して１つまたは複数のクライアントコンピューティングデバイス１０２と通信するコンテンツプロバイダ１０４も含ませることができる。図１に示されているコンテンツプロバイダ１０４はコンテンツプロバイダに関連付けられた１つまたは複数のコンピューティングデバイスの論理関連付けに対応する。殊に、コンテンツプロバイダ１０４は、クライアントコンピューティングデバイス１０２からのコンテンツ（例えばウェブページ）に関するリクエストを取得して処理するための１つまたは複数のサーバコンピューティングデバイスに対応するウェブサーバコンポーネント１１０を有することができる。さらにコンテンツプロバイダ１０４は、ＣＤＮサービスプロバイダからのネットワークリソースに関するリクエストを取得して処理するための１つまたは複数のコンピューティングデバイスに対応する、オリジンサーバコンポーネント１１２および関連するストレージコンポーネント１１４を有することができる。当業者であれば、コンテンツプロバイダ１０４を種々の付加的なコンピューティングリソース、例えば、コンテンツおよびリソースを管理するための付加的なコンピューティングデバイス、ＤＮＳネームサーバなどに関連付けできることが分かる。例えば、図１には図示していないが、コンテンツプロバイダのドメインに対応するクライアントコンピューティングデバイスＤＮＳクエリを解決する権限を有する１つまたは複数のＤＮＳネームサーバコンポーネントにコンテンツプロバイダ１０４を関連付けることができる。
【００１２】
図１の参照を続ける。コンテンツ配信環境１００にはさらに、通信ネットワーク１０８を介して１つまたは複数のクライアントコンピューティングデバイス１０２およびコンテンツプロバイダ１０４と通信するＣＤＮサービスプロバイダ１０６を含ませることができる。図１に示されているＣＤＮサービスプロバイダ１０６はＣＤＮサービスプロバイダに関連付けられた１つまたは複数のコンピューティングデバイスの論理関連付けに対応する。殊に、ＣＤＮサービスプロバイダ１０６は、通信ネットワーク１０８のノードに対応する複数のＰＯＰ（Point of Presence）ロケーション１１６，１２２，１２８を含むことができる。各ＰＯＰ１１６，１２２，１２８は、クライアントコンピュータ１０２からのＤＮＳクエリを解決するための複数のＤＮＳサーバコンピューティングデバイスからなるＤＮＳコンポーネント１１８，１２４，１３０を有する。さらに各ＰＯＰ１１６，１２２，１２８は、コンテンツプロバイダに由来するリソースを記憶し、また、リクエストされた種々のリソースを種々のクライアントコンピュータへと伝送する、複数のキャッシュサーバコンピューティングデバイスからなるリソースキャッシュコンポーネント１２０，１２６，１３２を有する。ＤＮＳコンポーネント１１８，１２４および１３０ならびにリソースキャッシュコンポーネント１２０，１２６，１３２はさらに、通信を容易にする付加的なソフトウェアコンポーネントおよび／またはハードウェアコンポーネントを有することができ、そのようなコンポーネントには負荷分散および負荷共有のためのソフトウェア／ハードウェアコンポーネントが含まれるが、コンポーネントはそれらに限定されるものではない。
【００１３】
図示されている実施例において、ＤＮＳコンポーネント１１８，１２４，１３０およびリソースキャッシュコンポーネント１２０，１２６，１３２は、それらのコンポーネントまたはコンポーネントの一部が物理的に隔てられているか否かにかかわらず、論理的にグループをなすものと見なされる。さらに、ＰＯＰ１１６，１２２，１２８は図１において、ＣＤＮサーバプロバイダ１０６に論理的に関連付けられているものとして示されているが、クライアントコンピューティングデバイス１０２の種々のデモグラフィックが最善に提供されるように、ＰＯＰは通信ネットワーク１０８にわたり地理的に分散されていてもよい。さらには、当業者であれば、ＣＤＮサーバプロバイダ１０６を種々の付加的なコンピューティングリソース、例えば、コンテンツおよびリソースを管理するための付加的なコンピューティングデバイスなどに関連付けできることが分かる。
【００１４】
当業者であれば、図１に示されているコンポーネントおよび構成が単に例示的なものに過ぎないことが分かる。したがって、殊に通信を容易にするための付加的なコンポーネント、システムおよびサブシステムに関して、付加的または代替的なコンポーネントおよび／または構成を使用することができる。
【００１５】
次に図２から図６を参照して、図１のコンテンツ配信環境１００の種々のコンポーネント間のインタラクションを説明する。しかしながらそれらは例示を意図したものなので、図示されている実施例は簡略的なものであり、通信を容易にするために使用される多くのコンポーネントは図示されていない。当業者であれば、本発明の精神および範囲から逸脱することなく、そのようなコンポーネントを使用することができ、したがって付加的なインタラクションを行えることが分かる。
【００１６】
図２を参照して、ＣＤＮサービスプロバイダ１０６によるコンテンツプロバイダ１０４の登録に関する例示的なインタラクションを説明する。図２に示されているように、ＣＤＮコンテンツ登録処理は、コンテンツプロバイダ１０４がＣＤＮサービスプロバイダ１０６に登録されることから始まる。図示されている実施例において、ＣＤＮサービスプロバイダ１０６がコンテンツプロバイダ１０４の代わりにコンテンツを提供できるようになるために、コンテンツプロバイダ１０４は登録アプリケーションプログラムインタフェース（「ＡＰＩ」）を使用してＣＤＮサービスプロバイダ１０６に登録される。登録ＡＰＩは、リクエストされたリソースをＣＤＮサービスプロバイダ１０６に提供することになるコンテンツプロバイダ１０４のオリジンサーバ１１２の識別を含む。
【００１７】
当業者であれば、適切なオリジンサーバ１１２の識別に基づいて、コンテンツプロバイダ１０４はクライアントコンピューティングデバイス１０２からのコンテンツリクエストのＣＤＮサービスプロバイダ１０６への伝送を開始できることが分かる。殊に、ＤＮＳルーティング原理にしたがって、リソース識別子に対応するクライアントコンピューティングデバイスリクエストは最終的に、ＣＤＮサービスプロバイダ１０６に関連付けられたＰＯＰ１１６，１２２，１２８へと伝送される。選択されたＰＯＰのリソースキャッシュコンポーネント１２０，１２６，１３２がクライアントコンピューティングデバイス１０２によってリクエストされたリソースのコピーを有していない場合には、リソースキャッシュコンポーネントはコンテンツプロバイダ１０４によって先行して登録されたオリジンサーバ１１２からリソースをリクエストする。
【００１８】
図２の参照を続ける。登録ＡＰＩの受信に基づいて、ＣＤＮサービスプロバイダ１０６はその登録に関する情報を取得して処理する。図示されている実施例において、ＣＤＮサービスプロバイダ１０６は続いて、コンテンツリクエストの一部としてクライアントコンピューティングデバイス１０２によって使用されることになる付加的な情報を生成することができる。付加的な情報には、クライアント識別子、例えばクライアント識別コード、コンテンツプロバイダ識別子、例えばコンテンツプロバイダ識別コード、リソース識別子を処理するための実行可能なコード、例えばスクリプトベースの命令などが含まれるが、情報はそれらに限定されるものではない。当業者であれば、種々のタイプの付加的な情報をＣＤＮサービスプロバイダ１０６によって生成することができ、また付加的な情報を種々のフォーマットのうちのいずれかによって実施できることが分かる。
【００１９】
ＣＤＮサービスプロバイダ１０６は、ＣＤＮサービスプロバイダに適したドメインの識別子（事前に提供されていない限り）および付加的な何らかの情報をコンテンツプロバイダ１０４に戻す。これにより、コンテンツプロバイダ１０４は記憶しているコンテンツを処理することができ、それらのコンテンツはコンテンツプロバイダ固有の情報を有している。１つの実施例においては、図２に示されているように、コンテンツプロバイダ１０４は、本来はオリジンサーバ１１２のドメインを指しているリソース識別子をＣＤＮサービスプロバイダに対応するドメインに変換する。変換されたＵＲＬは、この変換されたＵＲＬに関するＤＮＳクエリが、コンテンツプロバイダ１０４に対応するＤＮＳサーバではなく、ＣＤＮサービスプロバイダ１０６に対応するＤＮＳサーバに（名前）解決されるように、リクエストされたコンテンツに埋め込まれる。図２には変換処理が示されているが、幾つかの実施形態においては、この変換処理を以下において詳細に説明するよう省略することもできる。
【００２０】
一般的に、本来はコンテンツプロバイダを指しているリソースの識別子は、例えばブラウザソフトウェアアプリケーションを介してクライアントコンピューティングデバイス１０２が処理できるリソース識別子の形態である。図示されている実施例においては、リソース識別子としてユニフォーム・リソース・ロケータ（「ＵＲＬ」）が考えられる。リソース識別子はコンテンツプロバイダを指しているリクエストされたコンテンツに含まれるので、リソース識別子は一般的に「コンテンツプロバイダＵＲＬ」とも称される。例示を意図したものであるが、コンテンツプロバイダＵＲＬではコンテンツプロバイダ１０４のドメイン（例えば、contentprovider.com）、リクエストされるリソースの名前（例えば、「resource.xxx」）およびリソースが発見されるパス（例えば「path」）を識別することができる。この実施例において、コンテンツプロバイダＵＲＬは、
http://www.contentprovider.com/path/resource.xxx
である。
【００２１】
図示されている変換処理の間に、コンテンツプロバイダＵＲＬは、変換されたＵＲＬに関連付けられたリソースに関するリクエストがＣＤＮサービスプロバイダ１０６に関連付けられたＰＯＰに解決されるように変更される。１つの実施例において、変換されたＵＲＬではＣＤＮサービスプロバイダ１０６のドメイン（例えば、cdnprovider.com）、リクエストされるリソースの同一の名前（例えば、「resource.xxx」）およびリソースが発見される同一のパス（例えば「path」）が識別される。変換されたＵＲＬはさらに付加的な処理情報（例えば「additional information」）を含むことができる。変換されたＵＲＬは、
http://additional_information.cdnprovider.com/path/resources.xxx
となる。
【００２２】
別の実施例においては、ＣＤＮサービスプロバイダ１０６に関連付けられた情報が、例えばプリペンディングまたは他の技術によって、変更されたＵＲＬに含まれているので、変換されたＵＲＬはオリジナルのＵＲＬに関連付けられた全ての情報を保持することができる。この実施例において、変換されたＵＲＬは、
http://additional_information.cdnprovider.com/www.contentprovider.com/path/resource.xxx
となる。
【００２３】
ここで図３を参照する。クライアントコンピューティングデバイス１０２は、図２に示した登録処理および変換処理の終了後に、コンテンツリクエストを生成する。このコンテンツリクエストはコンテンツプロバイダ１０４によって、例えばウェブサーバ１１０を介して受信および処理される。図示されている実施例に関して、コンテンツに関するリクエストは一般的なネットワークプロトコル、例えばハイパーテキストトランスファープロトコル（「ＨＴＴＰ」）に従うものでよい。コンテンツリクエストの受信に基づいて、コンテンツプロバイダ１０４は適切な応答コンテンツを識別する。図示されている実施例において、リクエストされたコンテンツを、情報、例えばハイパーテキストマークアップ言語（「ＨＴＭＬ」）、拡張可能マークアップ言語（「ＸＭＬ」）などを処理することによってクライアントコンピューティングデバイス１０２に表示されるウェブページに対応させることができる。上述のように、リクエストされたコンテンツは多数の埋め込みリソース識別子も含むことができ、それらはリクエストされたコンテンツの処理の一部としてクライアントコンピューティングデバイス１０２によって取得されるべきリソースオブジェクトに対応する。埋め込みリソース識別子は一般的にオリジナルリソース識別子またはオリジナルＵＲＬと称される。
【００２４】
リクエストしたコンテンツの受信に基づいて、クライアントコンピューティングデバイス１０２は、例えばブラウザソフトウェアアプリケーションによって、コンテンツに含まれるいずれかのマークアップコードの処理を開始し、埋め込みリソース識別子によって識別されたリソースの取得を試みる。したがって、コンテンツを取得する第１のステップは、クライアントコンピューティングデバイス１０２による（自身のローカルＤＮＳリゾルバを介する）、変換されたＵＲＬの「.」および「com」部分を管轄するＤＮＳサーバを識別できるオリジナルＵＲＬリソース識別子に関するＤＮＳクエリの発行に対応する。埋め込みＵＲＬの「.」および「com」部分を解決した後に、クライアントコンピューティングデバイス１０２は続いて、埋め込みＵＲＬの「.cdnprovider」部分を管轄するＤＮＳサーバを識別できる、リソースＵＲＬに関するＤＮＳクエリを発行する。ＵＲＬの「.」および「com」部分に対応するＤＮＳクエリの発行は周知の事項であるので、ここでは説明しない。
【００２５】
ここで図４を参照する。図示されている実施例においては、オリジナルＵＲＬの「cdnprovider」部分の解決が成功すると、ＣＤＮサービスプロバイダ１０６に関連付けられたＤＮＳサーバのネットワークアドレス、例えばＩＰアドレスが識別される。１つの実施例において、ＩＰアドレスはＰＯＰのＤＮＳサーバコンポーネントにとってユニークな特定のネットワークアドレスでよい。別の実施例においては、ＩＰアドレスを１つまたは複数のＰＯＰによって共有することができる。この実施例においては、共有ＩＰアドレスについての別のＤＮＳクエリが一対多のネットワークルーティングスキーマ、例えばエニーキャストを使用し、特定のＰＯＰがネットワークトポロジに依存してリクエストを受信する。例えば、エニーキャストを実施する場合、共有ＩＰアドレスについてクライアントコンピューティングデバイス１０２によって発行されたＤＮＳクエリがクライアントコンピューティングデバイスから、論理的に最短のネットワークトポロジ距離（頻繁にネットワークホップと称される）を有しているＤＮＳサーバコンポーネントに到達する。ネットワークトポロジ距離は地理的な距離に対応している必要はない。しかしながら、幾つかの実施形態においては、ネットワークトポロジ距離がクライアントコンピューティングデバイス１０２とＰＯＰとの間の最短ネットワーク距離を表すことが考えられる。
【００２６】
図４の参照を続ける。上記のいずれかの実施例（またはいずれかの他の実施例）においては、ＰＯＰ１２８のＤＮＳコンポーネント１３０における特定のＤＮＳサーバがクライアントコンピューティングデバイス１０２からオリジナルＵＲＬに対応するＤＮＳクエリを受信する。ＤＮＳコンポーネント１１８におけるＤＮＳサーバのうちの１つがリクエストを受信すると、特定のＤＮＳサーバはリクエストの解決を試みる。図４に示されているような１つの実施例においては、特定のＤＮＳサーバが、リクエストされたリソースに関するリクエストを処理するキャッシュサーバコンポーネントのＩＰアドレスを識別することによって、ＤＮＳクエリを解決する。上述のように、また下記において図６を参照しながらさらに説明するように、リクエストされたリソースを別のソース、例えばピアキャッシュサーバコンピューティングデバイスまたはコンテンツプロバイダ１０４のオリジンサーバ１１２から取得できる場合、もしくは取得が試みられる場合、選択されたリソースキャッシュコンポーネントは、リクエストされたリソースを提供することによってリクエストを処理することができる。
【００２７】
図４の参照を続ける。特定のＤＮＳサーバはリソースキャッシュコンポーネントの選択に関して種々の情報を使用することができる。図示されている実施例において、また図７および図８を参照しながら下記においてさらに説明するように、ＤＮＳサーバはリクエストを行うクライアントコンピューティングデバイスに関連付けられたクラスを決定する。例えば、クラスを、クライアントコンピューティングデバイスが属する特定の地理的な領域か、クライアントコンピューティングデバイスに関するインターネットプロバイダに対応させることができる。そのようなクラス情報をクライアントから直接的に決定することができる（例えば、クライアントコンピューティングデバイスまたはＩＳＰによって提供された情報）か、間接的に決定することができる（例えば、クライアントコンピューティングデバイスのＩＰアドレスを介して推測された情報）。このクラスに基づいて、ＤＮＳサーバは適切なルーティング情報を決定する。続いて、殊に図４を参照して説明する実施例に関して、ＤＮＳサーバは、クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するために適切なリソースキャッシュコンポーネントを選択する。ＤＮＳサーバによって選択されたＩＰアドレスをリソースキャッシュにおける特定のキャッシュサーバに対応付けることができる。択一的に、ＩＰアドレスを（例えば負荷分散としての）ハードウェア／ソフトウェア選択コンポーネントに対応付けることができる。下記においてさらに説明するように、ＤＮＳサーバは、決定されたクラスに関する特定のリソースキャッシュコンポーネントの選択を支援するために、ネットワーク性能測定を使用することができる。
【００２８】
ここで図５Ａから図５Ｃを参照する。図４を参照して説明したようなＤＮＳクエリの受信に基づいたリソースキャッシュコンポーネントの選択の代わりに、ＣＤＮサービスプロバイダ１０６は代替的な種々のリソース識別子のセットを保守することができる。代替的なリソース識別子をＣＤＮサービスプロバイダ１０６によってクライアントコンピューティングデバイス１０２に提供することができるが、これは、代替的なリソース識別子に対する後続のＤＮＳクエリがＣＤＮサービスプロバイダのネットワーク内の異なるＤＮＳサーバコンポーネントに解決されるように行われる。図示されている実施例においては、代替的なリソース識別子として１つまたは複数の正規名レコード、すなわち「ＣＮＡＭＥ（canonical name）」レコードが考えられる。１つの実施例において、各ＣＮＡＭＥレコードはＣＤＮサービスプロバイダ１０６のドメイン（例えば「cdnprovider.com」または「cdnprovider-1.com」）を識別する。下記においてより詳細に説明するように、ＣＮＡＭＥにおけるドメインはオリジナルＵＲＬまたは先行のＣＮＡＭＥレコードにおいて発見されたドメインと同一である必要はない。付加的に、各ＣＮＡＭＥレコードはルーティング情報のリクエスト（例えば「request routing information」）のような付加的な情報を含む。ＣＮＡＭＥレコードの例として、
http://request_routing_information.cdnprovider.com
が考えられる。
【００２９】
図示されている実施例において、ＣＮＡＭＥレコードは、ＣＤＮサービスプロバイダ１０６のより適切なＤＮＳサーバを識別するためにＤＮＳサーバによって生成および提供される。上記において図４を参照して説明したような適切なリソースキャッシュコンポーネントの選択と同様に、初期ＤＮＳクエリを受信するＤＮＳサーバは、リソースリクエストを解決するために、ＣＤＮサービスプロバイダ１０６のより適切なＤＮＳサーバを選択するための種々の情報を使用することができる。図示されている実施例において、また図７および図８を参照しながら下記においてもさらに説明するように、ＤＮＳサーバはリクエストを行うクライアントコンピューティングデバイスに関連付けられたクラスを決定する。例えば、クラスをここでもまた、クライアントコンピューティングデバイスが属する特定の地理的な領域か、クライアントコンピューティングデバイスに関するインターネットプロバイダに対応させることができる。いずれのケースにおいても、ＤＮＳサーバはクラス情報をクライアントから直接的に取得することができる（例えば、クライアントコンピューティングデバイスまたはＩＳＰによって提供された情報）か、間接的に取得することができる（例えば、クライアントコンピューティングデバイスのＩＰアドレスを介して推測された情報）。このクラスに基づいて、ＤＮＳサーバは適切なルーティング情報を決定する。続いて、殊に図５Ａを参照して説明する実施例に関して、ＤＮＳサーバは、クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストの解決に使用するために適切な代替的なＤＮＳサーバを選択する。下記においてさらに説明するように、ＤＮＳサーバは、決定されたクラスに関する特定の代替的なＤＮＳサーバを選択するために、ネットワーク性能測定を利用することができる。
【００３０】
図示されている実施例によれば、ＤＮＳサーバは種々のオリジナルＵＲＬのためのＣＮＡＭＥレコードを規定するデータ記憶部を保守する。特定のオリジナルＵＲＬに対応するＤＮＳクエリがデータ記憶部内のエントリと合致すると、ＤＮＳサーバはＣＮＡＭＥレコードをデータ記憶部内に記憶されているものとして戻す。図示されている実施例においては、データ記憶部は特定のオリジナルＵＲＬに対応する複数のＣＮＡＭＥレコードを含むことができる。複数のＣＮＡＭＥレコードは、クライアントコンピューティングデバイスに戻すことができる潜在的な候補のセットを規定する。そのような実施例においては、ＤＮＳサーバは直接的に、またはネットワークベースのサービスを介して、リクエストを行うクライアントコンピューティングデバイスに関して決定されたクラスを要因として考慮するロジックに基づいて、より適切なルーティング情報としてデータ記憶部に規定されているＣＮＡＭＥレコードのうちの１つを選択する。当業者には明らかであるように、ＤＮＳサーバは、考えられるＣＮＡＭＥのセットから適切なＣＮＡＭＥを選択する別の付加的なロジックを実施することもできる。図示されている実施例において、各ＤＮＳサーバコンポーネント１１８，１２４，１３０は、ＣＤＮサービスプロバイダ１０６によって中央において管理することができるＣＮＡＭＥレコードを規定する同一のデータ記憶部を保守する。択一的に、各ＤＮＳサーバコンポーネント１１８，１２４，１３０はＣＮＡＭＥレコードを規定するＰＯＰ固有のデータ記憶部を有することができ、このデータ記憶部をＣＤＮサービスプロバイダ１０６によって中央において管理することができるか、ＰＯＰ１１６，１２２，１２８によって局所的に管理することができる。さらに、ＤＮＳサーバコンポーネント１１８，１２４，１３０内の各ＤＮＳサーバコンピューティングデバイスは、個々のＤＮＳサーバコンピューティングデバイスに固有の局所的なデータ記憶部、もしくはそれぞれのＰＯＰによって管理される共有のデータ記憶部を使用することができる。
【００３１】
戻されたＣＮＡＭＥは、現在のＤＮＳクエリのＵＲＬ／ＣＮＡＭＥ内に存在する情報とは異なる、またはその情報に付加的なリクエストルーティング情報を含むことができる。例えば、ＣＮＡＭＥの選択がリクエストを行うクライアントコンピューティングデバイスに関連付けられたクラスを基礎とする場合、特定のクラスを特定のＣＮＡＭＥレコードの「request_routing_information」部分において識別することができる。特定の識別子をＣＮＡＭＥレコードの「request_routing_information」部分に含ませることによって、サービスレベルプランおよびファイル管理を識別するために同様のアプローチを採用することができる。別の実施例においては、リクエストルーティング情報を、現在のＵＲＬ／ＣＮＡＭＥにおいて発見されたドメインとは異なる、ＣＤＮサービスプロバイダ１０６のドメインの識別時に発見することができる。例えば、ＣＮＡＭＥが局所的なプランに基づく場合、特定の局所的なプランのドメイン（例えば「cdnprovder-regionl.com」）を特定のＣＮＡＭＥレコードのドメイン名部分に使用することができる。あらゆる付加的なリクエストルーティング情報を、現在のＵＲＬ／ＣＮＡＭＥにおける既存のリクエストルーティング情報の前に付加することができるので、先行のリクエストルーティング情報が失われることはない（例えばhttp://serviceplan.regionalplan.cdnprovider.com）。当業者には明らかなように、付加的なリクエストルーティング情報をＤＮＳサーバコンポーネント１１８によって選択されているＣＮＡＭＥレコードに含ませるために、付加的な技術または代替的な技術、および／または、それらの技術の組み合わせを使用することができる。
【００３２】
図５Ａの参照を続ける。当業者であれば、ＤＮＳサーバは、ＣＮＤサービスプロバイダ１０６のより適切なＤＮＳサーバに解決することを意図しているＣＮＡＭＥレコードを選択できる（もしくは取得できる）ことが分かる。しかしながら、同一のＤＮＳサーバがクライアントコンピューティングデバイスに提供されるべきＣＮＡＭＥに関する後続のＤＮＳクエリに対しても権限を有するようにしてもよい。例えば、特定のＤＮＳサーバは特定の局所的なプランも、サービスレベルプランも管轄するものであってよい。したがってＣＮＡＭＥが戻されることによって、ＤＮＳクエリの生成と同時に同一のＤＮＳクエリが到来する結果が起こりうる（これは部分的にクライアントコンピューティングデバイスの地理にも起因する）。そのような実施例においては、ＤＮＳサーバ、例えばＤＮＳサーバコンポーネント１１８は、将来のＤＮＳクエリを先行して解決することを選択できる。
【００３３】
ここで図５Ｂを参照する。ＤＮＳサーバコンポーネント１１８からのＣＮＡＭＥの受信に基づき、クライアントコンピューティングデバイス１０２はそのＣＮＡＭＥに対応する後続のＤＮＳクエリを生成する。上記において図４を参照して説明したように、ＤＮＳクエリの処理は先ず、ＣＮＡＭＥの「cdnprovider」部分に関するクエリに続く「.」および「com」部分に関するＤＮＳクエリでもって開始される。しかしながら、先行のＤＮＳクエリの結果がキャッシュされる限り（またその結果が有効で有り続ける限り）、クライアントコンピューティングデバイス１０２はキャッシュされた情報を使用することができるので、全体の処理を繰り返す必要はない。しかしながら、ある時点において、ＤＮＳサーバコンポーネント１１８によって提供されたＣＮＡＭＥ（図５Ａを参照されたい）および先行のＵＲＬ／ＣＮＡＭＥが共通のＣＤＮサービスプロバイダドメインを共有するか否かに依存して、現在のＣＮＡＭＥのＤＮＳクエリはＣＤＮサービスプロバイダ１０６によって提供される異なるＰＯＰに解決される。図５Ｂに示されているように、ＰＯＰ１２２のＤＮＳサーバコンポーネント１２４は、ＤＮＳサーバコンポーネント１１８によって先行して提供された現在のＣＮＡＭＥにおける異なる情報を基礎とする現在のＣＮＡＭＥを受信する。前述のように、ＤＮＳサーバコンポーネント１２４は、コンテンツリクエストを処理するキャッシュコンポーネントのＩＰアドレスを有するＣＮＡＭＥに対するＤＮＳクエリを解決するか否か、または、上述のようにして選択された他の代替的なリソース識別子を提供するか否かを決定することができる。
【００３４】
例示を目的として、（ＤＮＳサーバコンポーネント１１６によって提供された）現在のＣＮＡＭＥに対応するＤＮＳクエリは、ＤＮＳサーバコンポーネント１１８のデータ記憶部におけるＣＮＡＭＥレコードにも対応していることをＤＮＳサーバコンポーネント１１８が特定した場合を想定する。そのような実施例においては、ＤＮＳサーバコンポーネント１２４が上述のように特定のＣＮＡＭＥを選択し、そのＣＮＡＭＥをクライアントコンピューティングデバイスに戻すために必要とされるあらゆる処理を実行する。ここで図５Ｃを参照すると、クライアントコンピューティングデバイス１０２は、ＤＮＳサーバコンポーネント１２４によって提供されたＣＮＡＭＥ（図５Ｂを参照されたい）に対応している、後続の第２のＤＮＳクエリを伝送している。既に説明したＤＮＳクエリの処理に応じて、この実施例ではＤＮＳクエリがＰＯＰ１２８のＤＮＳサーバコンポーネント１３０によって受信される。ここでもまた、ＤＮＳサーバコンポーネント１３０は、コンテンツリクエストを処理するキャッシュコンポーネントのＩＰアドレスを有するＣＮＡＭＥに対するＤＮＳクエリを解決するか否か、または、上述のようなやり方で選択された他の代替的なリソース識別子を提供するか否かを決定することができる。この実施例においては、ＤＮＳサーバコンポーネント１３０がＩＰアドレスを戻す。
【００３５】
図５Ｃの参照を続ける。図示されている実施例においては、ＤＮＳサーバコンポーネント、例えばＤＮＳサーバコンポーネント１３０は、リソースキャッシュコンポーネントの選択に関して種々の情報を使用することができる。１つの実施例において、ＤＮＳサーバコンポーネントは同一のＰＯＰのリソースキャッシュコンポーネントをデフォルトで選択することができる。別の実施例においては、ＤＮＳサーバコンポーネントは、負荷分散アルゴリズムおよび負荷共有アルゴリズムに基づいて、リソースキャッシュコンポーネントを選択することができる。さらにＤＮＳサーバコンポーネントは、特定のリソースキャッシュコンポーネントを割り当てるために、ネットワーク性能メトリクスまたはネットワーク性能測定を利用することができる。またさらに、ＤＮＳサーバコンポーネントは、図４を参照して説明したように、リクエストを行うクライアントコンピューティングデバイスのクラスに関するルーティング情報に基づいて、リソースキャッシュコンポーネントを選択することができる。ここでもまた、ＤＮＳサーバコンポーネントによって選択されたＩＰアドレスをリソースキャッシュにおける特定のキャッシュサーバに対応付けることができる。択一的に、ＩＰアドレスを（例えば負荷分散としての）ハードウェア／ソフトウェア選択コンポーネントに対応付けることができる。
【００３６】
ここで図６を参照する。図示されている実施例においては、ＤＮＳサーバコンポーネント１３０がＰＯＰ１２８のリソースキャッシュコンポーネント１３２を選択した場合が想定されている。リソースキャッシュコンポーネント１３２に関するＩＰアドレスの受信に基づき、クライアントコンピューティングデバイス１０２はリクエストされたコンテンツに関するリクエストをリソースキャッシュコンポーネント１３２に伝送する。リソースキャッシュコンポーネント１３２は上述したやり方でリクエストを処理し、リクエストされたコンテンツをクライアントコンピューティングデバイス１０２に伝送する。
【００３７】
以下では図７を参照しながら、リソースリクエストを処理するためにＣＤＮサービスプロバイダ１０６によって実施されるルーチン７００の一実施例を説明する。当業者であれば、ルーチン７００に関して概略的に表されている動作／ステップを、ＣＤＮサービスプロバイダ１０６に関連付けられている１つまたは複数のコンピューティングデバイス／コンポーネントによって実行できることが分かる。つまり、ルーチン７００はＣＮＤサービスプロバイダ１０６によって一般的に実行できるものとして論理的に関連付けられており、したがって以下において説明する実施例は制限を意図して構成されたものではない。
【００３８】
ルーチン７００を図４および図５Ａ〜５Ｃを参照して説明した実施例に適用することができる。先ず、図４を参照して概説したような、リクエストを行うクライアントコンピューティングデバイスのクラスに関するルーティング情報に基づいたＤＮＳサーバにおけるリソースキャッシュコンポーネントの選択に対応している実施例を参照して、ルーチン７００を説明する。
【００３９】
ブロック７０２においては、ＤＮＳサーバコンポーネント１１８，１２４，１３０のうちの１つがリソース識別子に対応するＤＮＳクエリを受信する。上述したように、リソース識別子としてＵＲＬが考えられ、このＵＲＬはクライアントコンピューティングデバイス１０２によってリクエストされたコンテンツに埋め込まれたものであり、またコンテンツプロバイダ１０４によって先行して提供されたものである。ブロック７０４において、ＤＮＳサーバは、ＤＮＳクエリに関連付けられた、リクエストを行うクライアントのクラスを決定する。上述のように、例えばクラスを、クライアントコンピューティングデバイスが属する特定の地理的な領域か、クライアントコンピューティングデバイスに関するインターネットサービスプロバイダに対応させることができる。そのようなクラス情報をクライアントから直接的に決定することができる（例えば、クライアントコンピューティングデバイスまたはＩＳＰによって提供された情報）か、間接的に決定することができる（例えば、クライアントコンピューティングデバイスのＩＰアドレスを介して推測された情報）。図示されている実施例において、ブロック７０４におけるクラスの決定には、殊に、リクエストを行うクライアントコンピューティングデバイスの他のクライアントコンピューティングデバイスのクラスタへの種々の判定基準に基づいた関連付けが含まれてもよい。そのような判定基準は、上述のように、ルーティングパス情報、ネットワーク機器、クライアントが保証するサービスレベルアグリーメント、コンテンツプロバイダのサービスレベルアグリーメントなどの他に、地理的な領域およびインターネットサービスプロバイダデータを含むことができる。
【００４０】
判定ブロック７０６では、現在のＤＮＳサーバがＤＮＳクエリの解決に権限を有しているか否かを判定するための検査が行われる。図示されている実施例において、ＤＮＳサーバは、受信したリソース識別子に対応するＣＮＡＭＥレコードが存在しない場合にＤＮＳクエリを解決する権限があるか否かを判定することができる。図示されている実施例において、ＣＮＡＭＥレコードは存在していない。したがって、ルーチンはブロック７０８に進み、このブロック７０８においては一般的に、現在のＤＮＳサーバが求められたクラスに関するルーティング情報を決定する。殊に、図示されている実施例においては、ＤＮＳサーバは、クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するために適切なリソースキャッシュコンポーネントを選択する。続いて、ＤＮＳサーバは選択されたリソースキャッシュコンポーネントのＩＰアドレスをクライアントコンピューティングデバイスに提供する。
【００４１】
図示されている実施例においては、ルーティング情報として、クライアントコンピューティングデバイスの特定のクラスに関するコンテンツリクエストを提供できるリソースキャッシュコンポーネントのリストが考えられる。ＤＮＳサーバは、リストからリソースキャッシュコンポーネントを選択するための種々のロジックを使用することができる。１つの実施例において、リスト上の各リソースキャッシュコンポーネントが選択される確率を規定することができ、またＤＮＳサーバはその確率に基づいてリソースキャッシュコンポーネントを選択する。したがって、この図示されている実施例においては、ＤＮＳサーバは求められた確率に対応する頻度に基づいてリソースキャッシュコンポーネントを選択する。例えばＤＮＳサーバは、最も高い選択確率を有するリソースキャッシュコンポーネントを最も多く選択するが、それよりも低い選択確率を有するリソースキャッシュコンポーネントを選択することがあってもよい。その場合、確率は選択されたコンピューティングデバイスの期待される性能に対応する。以下においてさらに詳細に説明するように、ＣＤＮサービスプロバイダ１０６はリクエストされたリソースを特定のクラスにあるクライアントに提供する性能を監視することができ、したがってルーティング情報（例えば確率）を相応に更新することができる。別の実施例においては、確率を負荷軽減または他のネットワークトラフィックの緩和に対応付けることができる。非優先リソースキャッシュコンポーネントを周期的に選択することによって、またクラスに関してその性能を監視することによって、ＣＤＮサービスプロバイダ１０６は、そのクラスに関するルーティング情報についての変更が所望されるか否かを決定することができる。
【００４２】
当業者には明らかであるように、クライアントコンピューティングデバイスの特定のクラスからのリソースリクエストを処理するためのリソースキャッシュコンポーネントの選択に関して、複数のアルゴリズムまたは選択ロジックを使用することができる。例えば、上述のような頻度ベースの強化アルゴリズムに加えて、ＤＮＳサーバは代替的な強化学習アルゴリズムを実施することができる。他の強化アルゴリズムの例として、ＳＡＲＳＡ（State-Action-Reward-State-Action），Ｑ学習、遅延式Ｑ学習などが挙げられるが、アルゴリズムはこれらに制限されるものではない。さらに、他のマシン学習アプローチ、例えばサポートベクターマシン、ニューラルネットワーク、ベイジアンエンジンなどをＤＮＳサーバと関連付けて、適切なリソースキャッシュコンポーネントを選択するために使用することができる。
【００４３】
次に、リクエストを行うクライアントコンピューティングデバイスのクラスに関するルーティング情報がリクエストを処理する適切なＤＮＳサーバの選択に使用される実施例を説明する。そのような実施例においては、ルーチン７００は同様にブロック７０２において開始され、このブロック７０２においては、ＤＮＳサーバコンポーネント１１８，１２４，１３０のうちの１つがリソース識別子に対応するＤＮＳクエリを受信する。上述のように、ブロック７０４においてＤＮＳサーバはさらに、ＤＮＳクエリに関連付けられた、リクエストを行うコンピューティングデバイスのクラスを決定する。
【００４４】
判定ブロック７０６では、現在のＤＮＳサーバがＤＮＳクエリの解決に関して権限を有しているか否かが判定される。図示されている実施例において、ＤＮＳサーバは、受信したリソース識別子に対応するＣＮＡＭＥレコードが存在しない場合にＤＮＳクエリを解決する権限があるか否かを判定することができる。ＤＮＳサーバが権限を有しているか否かを決定するために、択一的または付加的な方法論を実施することができる。
【００４５】
現在のＤＮＳサーバが（同一のＤＮＳサーバが後続のＤＮＳクエリに対して権限を有するかについての決定も含めて）権限を有している場合、現在のＤＮＳサーバはキャッシュサーバコンポーネントのＩＰアドレスを戻すことによってＤＮＳクエリを解決する。適切なリソースキャッシュコンポーネントを選択するための複数の方法論は上記において挙げているが、それらは制限を意図したものではない。さらに上述のように、ＩＰアドレスをリソースキャッシュコンポーネントの特定のキャッシュサーバに対応付けることができるか、一般的にキャッシュサーバのグループに対応付けることができる。
【００４６】
択一的に、判定ブロック７０６において、ＤＮＳサーバが権限を有していない場合、ブロック７１０においてＤＮＳサーバコンポーネントは代替的なリソース識別子を選択して伝送する。上述のように、ＤＮＳサーバコンポーネントは現在のＤＮＳクエリに依存して潜在的な候補ＣＮＡＭＥのセットを識別するためにデータ記憶部を使用することができる。続いて、ＤＮＳサーバは直接的に、またはネットワークベースのサービスを介して、リクエストを行うクライアントコンピューティングデバイスの決定されたクラスを要因として考慮するロジックに基づいて、より適切なルーティング情報としてデータ記憶部に規定されているＣＮＡＭＥレコードのうちの１つを選択する。ブロック７１２においては、種々のＤＮＳサーバコンポーネント１１８，１２４，１３０がＣＮＡＭＥに対応するＤＮＳクエリを受信する。その後ルーチン７００は判定ブロック７０６に戻り、相応に繰り返される。
【００４７】
ＤＮＳサーバが権限を有していない実施例においては、ルーティング情報として、クライアントコンピューティングデバイスの特定のクラスに関するコンテンツリクエストを提供できる１つまたは複数のＤＮＳサーバに対応する、潜在的な候補ＣＮＡＭＥのセットまたはリストが考えられる。上述したようなキャッシュリソースコンポーネントの選択と同様に、ＤＮＳサーバはリストからＣＮＡＭＥまたは他のＤＮＳサーバを選択するための種々のロジックを使用することができる。１つの実施例において、セット内の各ＣＮＡＭＥが選択される確率を最初に種々のやり方で規定することができ、またＤＮＳサーバはその規定された確率に基づいてＣＮＡＭＥを選択する。したがってこの実施例においては、ＤＮＳサーバは、最も高い選択確率を有するＣＮＡＭＥを最も多く選択するが、それよりも低い選択確率を有するＣＮＡＭＥを選択することがあってもよい。その場合、確率は対応するコンピューティングデバイスの期待される性能に対応する。以下においてさらに詳細に説明するように、ＣＤＮサービスプロバイダ１０６はリクエストされたリソースを特定のクラスにあるクライアントに提供する性能を監視することができ、したがって確率を更新することができる。別の実施例においては、確率をやはり負荷軽減または他のネットワークトラフィックの緩和に対応付けることができる。非優先ＣＮＡＭＥを周期的に選択することによって、またクラスに関するその対応するＤＮＳサーバの性能を監視することによって、ＣＤＮサービスプロバイダ１０６は、そのクラスに関するルーティング情報についての変更が所望されるか否かを決定することができる。当業者には明らかであるように、クライアントコンピューティングデバイスの特定のクラスからのリソースリクエストを提供するためのＣＮＡＭＥ／ＤＮＳの選択に関して、複数のアルゴリズムまたは選択ロジックを使用することができる。
【００４８】
以下では図８を参照しながら、ルーティング情報を更新するためのリクエストルーティングルーチン８００の一実施例を説明する。当業者であれば、ルーチン８００に関して概略的に表されている動作／ステップを、ＣＤＮサービスプロバイダ１０６に関連付けられている１つまたは複数のコンピューティングデバイス／コンポーネントによって実行できることが分かる。つまり、ルーチン８００はＣＤＮサービスプロバイダ１０６によって実行できるものとして論理的に関連付けられている。
【００４９】
ブロック８０２において、ＣＤＮサービスプロバイダ１０６の第１のＤＮＳサーバはクライアントコンピューティングデバイスからリクエストされたリソースに対応するＤＮＳクエリを受信する。上記において図７のブロック７０４を参照しながら説明したように、ブロック８０４においてＤＮＳサーバは、リクエスト行うクライアントに対応し、またＤＮＳクエリに関連付けられているクラスを決定する。ブロック８０４においても、ＤＮＳサーバは、上述のようにクライアントコンピューティングデバイスの決定されたクラスに基づいて、ＤＮＳもしくはキャッシュルーティング情報を決定する。ルーチン８００はブロック８０６に進み、このブロック８０６においては、リクエストされたリソースの配信に関連付けられたネットワーク性能判定基準が監視される。ネットワーク性能判定基準は、ＣＤＮサービスプロバイダのＰＯＰからクライアントコンピューティングデバイス１０２へのデータ伝送に関するネットワーク性能の測定に対応するものでよい。１つの実施例においては、リクエストされたリソースの配信に関連付けられたネットワークデータ伝送待ち時間がクライアントコンピューティングデバイス１０２によって測定される。したがってＣＤＮサービスプロバイダ１０６は、例えばリソースキャッシュコンポーネントを介して、クライアントコンピューティングデバイスへのコンテンツの提供の一部としての性能を測定することができる。そのようなネットワーク性能データをＣＤＮサービスプロバイダによって包括的に管理および維持することができ、またＣＤＮのＤＮＳサーバと共有することができるか、ＣＤＮサービスプロバイダのＤＮＳサーバによって別個に管理および維持することができる。さらには、ネットワーク性能判定基準をＰＯＰからのバッチ処理として提供することができるか、一方のＰＯＰから他方のＰＯＰへのリクエストに応答して送信することができる。
【００５０】
図８の参照を続ける。判定ブロック８０８においては、識別されたクラスに関するルーティング情報の更新が必要であるか否かの判定が性能データに基づき行われる。１つの実施例においては、更新の判定をＣＤＮサービスプロバイダによって包括的に行うことができるか、個々のＤＮＳサービスコンポーネントまたはＤＮＳサーバによって行うことができる。個々のＤＮＳサーバが、クラスに関するルーティング情報が更新されるか否かを判定する実施例においては、各ＤＮＳサーバが特定のＤＮＳサーバにユニークな識別されたクラスに関するルーティング情報を管理および維持することができる。この実施例においては、性能データを包括的にＣＤＮサービスプロバイダによって管理し、ＤＮＳコンポーネントおよび／またはＤＮＳサーバと共有することができるか、性能データをどのように使用するかを管理する各ＤＮＳコンポーネントおよび／またはＤＮＳサーバと共有することができる。したがって、クラスに関するルーティング情報を一方のＤＮＳコンポーネント／サーバから他方のＤＮＳコンポーネント／サーバへと変更することができる。
【００５１】
再び図８を参照する。更新が必要とされる場合、ブロック８１０において、識別されたクラスに関するルーティング情報が変更される。１つの実施例において、ＣＤＮサービスプロバイダ１０６は、クライアントコンピューティングデバイス１０２の特定のクラスからのリソースリクエストを処理するために、コンピューティングデバイスのリスト（例えばＤＮＳコンポーネント／サーバおよび／またはリソースキャッシュコンポーネント）を変更する。別の実施例において、ＣＤＮサービスプロバイダおよび／または特定のＤＮＳコンポーネント／サーバは、クライアントコンピューティングデバイスのクラスに関するリソースリクエストを処理するために、特定のコンピューティングデバイスが選択される確率を管理および変更することができる。例えば、比較的低い選択確率を有するＤＮＳサーバおよび／またはリソースキャッシュコンポーネントが良好に機能していることを性能データが示す場合、クライアントコンピューティングデバイスからのリソースリクエストを処理するために、その特定のＤＮＳサーバおよび／またはリソースキャッシュコンポーネントがより多く選択されることになるように選択確率を高めることができる。ブロック８１０において変更が行われた後に、もしくは、ブロック８０８において更新が必要無い場合には、ルーチン８００はブロック８０２に戻り、上述のようにさらなる処理が行われる。
【００５２】
当業者であれば、クライアントコンピューティングデバイスのクラスからのリクエストに関連付けられたルーティング情報を種々のやり方で変更できることが分かる。さらには、性能が監視され、ルーティング情報が更新される時点を変更できることも当業者であれば分かる。
【００５３】
当業者には明らかであるように、本明細書において記載した全ての機能を、本明細書において記載したコンポーネントおよびモバイル通信機器の１つまたは複数のプロセッサによって実行できるソフトウェアとして実現することができる。そのようなソフトウェアをあらゆるタイプの不揮発性の記憶装置に永続的に記憶することができる。
【００５４】
条件を表す記述、例えば、とりわけ「可能」、「可能性がある」、「であろう」または「できる」は、別個の記載が無い限り、もしくは使用されているコンテキスト内で理解される限り、一般的に特定の実施形態は特定の特徴、構成要素および／またはステップを含むが、他の実施形態はそれらの特定の特徴、構成要素および／またはステップを含まないことを意味する。したがってそのような条件を表す言葉は、特徴、構成要素および／またはステップが１つまたは複数の実施形態にいずれにせよ必要とされること、もしくは、１つまたは複数の実施形態が、ユーザ入力またはプロンプトの使用の有無に拘らず、それらの特徴、構成要素および／またはステップがいずれかの特定の実施形態に含まれるか否か、またはいずれかの特定の実施形態において実施されるべきか否かを決定するためのロジックを含んでいなければならないことを意味しているのではない。
【００５５】
本明細書において説明した、および／または、添付の図面に示したフローチャートにおけるあらゆるプロセスの説明、構成要素またはブロックは、プロセスにおける特定の論理的な機能またはステップを実施するための１つまたは複数の実行可能な命令を含むコードモジュール、コードセグメントまたはコード部分を潜在的に表すものと解されるべきである。当業者であれば分かるように、択一的な実施形態は、そこに含まれる機能に依存して構成要素または機能を削除することができるか、（実質的に同時の実行または反対の順序での実行も含めて）図示または説明した順序とは異なる順序で実行することができる、本明細書において説明した実施形態の範囲に含まれる。さらには、上記において説明したデータおよび／またはコンポーネントを、コンピュータ読み取り可能媒体に記憶し、コンピュータが実行可能なコンポーネントを記憶しているコンピュータ読み取り可能記憶媒体、例えばＣＤ−ＲＯＭ，ＤＶＤ−ＲＯＭに関連付けられたドライブ機構を使用して、もしくは、さらにネットワークインタフェースを使用して、コンピューティングデバイスのメモリにロードすることができ、コンポーネントおよび／またはデータを単一の機器に記憶させることができるか、何らかのやり方で分散させて記憶できることも明らかである。
【００５６】
第１項  コンテンツデリバリネットワークサービスに対応する第１のＤＮＳサーバにおいて、リクエストされたリソースに対応する、クライアントコンピューティングデバイスからのＤＮＳクエリを取得するステップを有し、
クライアントコンピューティングデバイスに関連付けられたクラスを決定するステップを有し、
クライアントコンピューティングデバイスのクラスに基づきルーティング情報を決定するステップを有し、
リクエストされたリソースの配信に関連付けられた性能を監視するステップを有し、
クラスに関するルーティング情報の更新が必要であるか否かを配信能力に基づき決定するステップを有し、
更新が必要である場合には、クラスに関するルーティング情報を変更するステップを有する方法。
【００５７】
第２項  クラスに関するルーティング情報を変更するステップは、リソースリクエストを処理するためのコンピューティングデバイスのリストを変更するステップを含む、第１項記載の方法。
【００５８】
第３項  クラスに関するルーティング情報を変更するステップは、リソースリクエストを処理するために使用される特定のコンピューティングデバイスが選択される確率を変更するステップを含む、第１項記載の方法。
【００５９】
第４項  決定されたクラスに関するルーティング情報は第１のＤＮＳサーバに関連付けられている、第１項記載の方法。
【００６０】
第５項  第１のＤＮＳサーバに関して決定されたクラスのルーティング情報は、コンテンツデリバリネットワークサービスプロバイダの第２のＤＮＳサーバに関して決定されたクラスのルーティング情報とは異なる、第４項記載の方法。
【００６１】
第６項  クラスはインターネットサービスプロバイダに対応する、第１項記載の方法。
【００６２】
第７項  クラスは指定された地理的なロケーションに対応する、第１項記載の方法。
【００６３】
第８項  ルーティング情報を決定するステップは、クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するキャッシュコンポーネントを選択するステップを含む、第１項記載の方法。
【００６４】
第９項  ルーティング情報を決定するステップは、
クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、第１のＤＮＳサーバが権限を有しているか否かを決定するステップを有し、
権限を有していない場合には、クライアントコンピューティングデバイスの決定されたクラスに関するルーティング情報に基づいて、リソースリクエストを処理するために第２のＤＮＳサーバを選択するステップを有する、第１項記載の方法。
【００６５】
第１０項  コンテンツデリバリネットワークサービスに対応する第１のＤＮＳサーバにおいて、リクエストされたリソースに対応する、クライアントコンピューティングデバイスからのＤＮＳクエリを取得するステップを有し、
クライアントコンピューティングデバイスを他のクライアントコンピューティングデバイスのクラスタに関連付けるステップを有し、
ＤＮＳクエリをクライアントコンピューティングデバイスの関連付けられたクラスタに関するルーティング情報に基づきルーティングするステップを有する方法。
【００６６】
第１１項  さらに、
リクエストされたリソースの配信に関連付けられた性能を監視するステップを有し、
クラスタに関するルーティング情報の更新が必要であるか否かを配信能力に基づき決定するステップを有し、
更新が必要である場合には、クラスタに関するルーティング情報を変更するステップを有する、第１０項記載の方法。
【００６７】
第１２項  クラスタに関するルーティング情報を変更するステップは、リソースリクエストを処理するためのコンピューティングデバイスのリストを変更するステップを含む、第１１項記載の方法。
【００６８】
第１３項  クラスタに関するルーティング情報を変更するステップは、リソースリクエストを処理するために使用される特定のコンピューティングデバイスが選択される確率を変更するステップを含む、第１１項記載の方法。
【００６９】
第１４項  クラスタに関するルーティング情報は第１のＤＮＳサーバに関連付けられている、第１１項記載の方法。
【００７０】
第１５項  第１のＤＮＳサーバに関するクラスタのルーティング情報は、コンテンツデリバリネットワークサービスプロバイダの第２のＤＮＳサーバに関するクラスタのルーティング情報とは異なる、第１４項記載の方法。
【００７１】
第１６項  ＤＮＳクエリをルーティングするステップは、クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するためのキャッシュコンポーネントを選択するステップを含む、第１０項記載の方法。
【００７２】
第１７項  キャッシュコンポーネントを選択するステップは、選択確率によって規定された頻度に基づいてキャッシュコンポーネントを選択するステップを含む、第１６項記載の方法。
【００７３】
第１８項  さらに、
リクエストされたリソースの比較的低い選択確率を有するキャッシュコンポーネントへの配信に関連付けられた性能を監視するステップを有し、
クラスタに関して比較的低い選択確率を有するキャッシュコンポーネントの選択確率を配信能力に基づき変更するステップを有する、第１７項記載の方法。
【００７４】
第１９項  キャッシュコンポーネントを選択するステップは、クラスタに関するリソースリクエストに関連付けられたコンテンツを提供するために非優先キャッシュコンポーネントを周期的に選択するステップを含む、第１６項記載の方法。
【００７５】
第２０項  さらに、
リクエストされたリソースの非優先キャッシュコンポーネントへの配信に関連付けられた性能を監視するステップを有し、
リクエストされたリソースの非優先キャッシュコンポーネントへの配信能力に基づきクラスタに関するルーティング情報を変更するステップを有する、第２０項記載の方法。
【００７６】
第２１項  ＤＮＳクエリをルーティングするステップは、
クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいて、第１のＤＮＳサーバが権限を有しているか否かを決定するステップを有し、
権限を有していない場合には、クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいて、リソースリクエストを処理するために第２のＤＮＳサーバを選択するステップを有する、第１０項記載の方法。
【００７７】
第２２項  さらに、
リクエストされたリソースの配信に関連付けられた性能を第２のＤＮＳサーバを用いて監視するステップを有し、
リクエストされたリソースの配信能力に基づき、クラスタに関するルーティング情報を第２のＤＮＳサーバを用いて変更するステップを有する、第２２項記載の方法。
【００７８】
第２３項  クラスタに関するルーティング情報を変更するステップは、クラスタに関するリソースリクエストを処理するためのＤＮＳサーバのリストを変更するステップを含む、第２３項記載の方法。
【００７９】
第２４項  クラスタに関するルーティング情報を変更するステップは、クラスタに関するリソースリクエストを処理するために使用される特定のＤＮＳサーバが選択される確率を変更するステップを含む、第２３項記載の方法。
【００８０】
第２５項  コンテンツデリバリネットワークサービスプロバイダに関連付けられたプレゼンスの第１のネットワークポイントを有し、
プレゼンスの第１のネットワークポイントはクライアントコンピューティングデバイスからＤＮＳクエリを受信するＤＮＳサーバコンポーネントを含み、ＤＮＳクエリはリクエストされたリソースに対応し、
プレゼンスの第１のネットワークポイントにおけるＤＮＳサーバは、
クライアントコンピューティングデバイスを他のクライアントコンピューティングデバイスのクラスタに関連付け、
クラスタに関するルーティング情報に基づきＤＮＳクエリをルーティングする、システム。
【００８１】
第２６項  さらに、プレゼンスの第１のネットワークポイントにおけるＤＮＳサーバは、
リクエストされたリソースの配信に関連付けられた性能を監視し、
クラスタに関するルーティング情報の更新が必要であるか否かを配信能力に基づき決定し、
更新が必要である場合には、クラスタに関するルーティング情報を変更する、第２６項記載のシステム。
【００８２】
第２７項  プレゼンスの第１のネットワークポイントにおけるＤＮＳサーバにおいて決定されたクラスタのルーティング情報は、コンテンツデリバリネットワークサービスプロバイダに関連付けられたプレゼンスの第２のネットワークポイントにおける第２のＤＮＳサーバに関するクラスタのルーティング情報とは異なる、第２６項記載のシステム。
【００８３】
第２８項  さらに、プレゼンスの第１のネットワークポイントにおけるＤＮＳサーバは、クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいて、リソースリクエストに関連付けられたコンテンツを提供するためのキャッシュコンポーネントを選択する、第２６項記載のシステム。
【００８４】
第２９項  さらに、プレゼンスの第１のネットワークポイントにおけるＤＮＳサーバは、
クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいて、第１のＤＮＳサーバが権限を有しているか否かを決定し、
権限を有していない場合には、クライアントコンピューティングデバイスのクラスタに関するルーティング情報に基づいて、リソースリクエストを処理するためにプレゼンスの第２のネットワークポイントにおける第２のＤＮＳサーバを選択する、第２６項記載の方法。
【００８５】
第３０項  コンテンツデリバリネットワークサービスプロバイダに関連付けられたプレゼンスの第１のネットワークポイントを有し、プレゼンスの第１のネットワークポイントはクライアントコンピューティングデバイスからＤＮＳクエリを受信するＤＮＳサーバコンポーネントを含み、
ＤＮＳクエリはリクエストされたリソースに対応し、且つ、第１のリソース識別子に関連付けられており、
プレゼンスの第１のネットワークポイントにおけるＤＮＳサーバは、
クライアントコンピューティングデバイスを他のクライアントコンピューティングデバイスのクラスタに関連付け、
第１のリソース識別子はクラスタに関するルーティング情報に基づき代替的なリソース識別子に関連付けられていることを決定し、
代替的なリソース識別子をクライアントコンピューティングデバイスに伝送し、
代替的なリソース識別子は、ＤＮＳクエリをコンテンツデリバリネットワークサービスプロバイダに対応するドメインに解決するための情報を含む、システム。
【００８６】
第３１項  代替的なリソース識別子は正規名レコード識別子に対応する、第３１項記載のシステム。
【００８７】
第３２項  さらに、コンテンツデリバリネットワークサービスプロバイダに関連付けられたプレゼンスの第２のネットワークポイントを有し、プレゼンスの第２のネットワークポイントはクライアントコンピューティングデバイスから後続のＤＮＳクエリを受信するＤＮＳサーバコンポーネントを含み、
後続のＤＮＳクエリはリクエストされたリソースに対応し、且つ、代替的なリソース識別子に関連付けられており、
プレゼンスの第２のネットワークポイントにおけるＤＮＳサーバコンポーネントは、
クライアントコンピューティングデバイスを他のクライアントコンピューティングデバイスのクラスタに関連付け、
クラスタに関するルーティング情報に基づきＤＮＳクエリをルーティングする、第３１項記載のシステム。
【００８８】
第３３項  さらに、
コンテンツデリバリネットワークサービスプロバイダに関連付けられたプレゼンスの第２のネットワークポイントを有し、プレゼンスの第２のネットワークポイントはクライアントコンピューティングデバイスから後続のＤＮＳクエリを受信するＤＮＳサーバコンポーネントを含み、後続のＤＮＳクエリはリクエストされたリソースに対応し、且つ、代替的なリソース識別子に関連付けられており、
プレゼンスの第２のネットワークポイントにおけるＤＮＳサーバコンポーネントは、
オリジナルのリソースリクエストに関連付けられたコンテンツを提供するキャッシュコンポーネントを識別するために後続のＤＮＳクエリを解決し、
識別されたキャッシュコンポーネントを識別する情報をクライアントコンピューティングデバイスに伝送する、第３１項記載のシステム。
【００８９】
したがって、汎用コンピューティングデバイスを、上述の種々のデータおよび／またはコンポーネントの処理および／または実行も含めて、本発明によるプロセス、アルゴリズムおよび方法論を実施するよう構成することができる。
【００９０】
上記の実施形態についての種々のヴァリエーションおよび修正形態が考えられ、それらの構成要素は他の許容される実施例に含まれると解するべきである。そのような全ての修正形態およびヴァリエーションは本発明の範囲に含まれ、添付の特許請求の範囲に記載された発明によって保護されることが意図されている。
【図１】
0005389153.tif 000002
【図２】
0005389153.tif 000003
【図３】
0005389153.tif 000004
【図４】
0005389153.tif 000005
【図５Ａ】
0005389153.tif 000006
【図５Ｂ】
0005389153.tif 000007
【図５Ｃ】
0005389153.tif 000008
【図６】
0005389153.tif 000009
【図７】
0005389153.tif 000010
【図８】
0005389153.tif 000011