JP5150769B2 - 要求ルーティングおよびクライアントロケーション情報を利用したルーティング情報の更新 - Google Patents

Description

本発明は、要求ルーティングおよびクライアントロケーション情報を利用してルーティング情報を更新することに関する。

背景技術
一般的に述べると、コンピューティングデバイスおよび通信ネットワークは、情報を交換するために利用できる。通常の適用例では、コンピューティングデバイスは、通信ネットワークを介して別のコンピューティングデバイスにコンテンツを要求することができる。たとえば、パーソナルコンピューティングデバイスにおけるユーザは、インターネットを介してサーバコンピューティングデバイスにウェブページを要求するために、ソフトウェアブラウザアプリケーションを利用することができる。そのような実施形態では、ユーザコンピューティングデバイスをクライアントコンピューティングデバイスと呼ぶことができ、サーバコンピューティングデバイスをコンテンツプロバイダと呼ぶことができる。

コンテンツプロバイダは一般に、しばしばクライアントコンピューティングデバイスへの要求されたコンテンツの効率的な送信を考慮して、および／またはコンテンツの送信に関連付けられたコストを考慮して、クライアントコンピューティングデバイスに要求されたコンテンツを提供するように動機づけされる。より大規模な実装形態の場合、コンテンツプロバイダは、高ボリュームのクライアントコンピューティングデバイスからコンテンツ要求を受信し得、コンテンツプロバイダのコンピューティングリソースに負荷をかけ得る。さらに、クライアントコンピューティングデバイスにより要求されたコンテンツは、複数の構成部分を有することがあり、これは、コンテンツプロバイダのコンピューティングリソースにさらなる負荷をかけ得る。

例示的な例を参照すると、要求されたウェブページまたはオリジナルコンテンツは、イメージまたはビデオなどの、ウェブページで表示されるべき複数のさらなるリソースを伴う場合がある。１つの特定の実施形態では、ウェブページのさらなるリソースは、ユニフォームリソースロケータ（「ＵＲＬ」）などの複数の埋込みリソース識別子により特定される。次に、クライアントコンピューティングデバイス上のソフトウェアは、典型的には、コンテンツに対する要求を生成するために埋込みリソース識別子を処理する。しばしば、埋込みリソースに関連付けられたリソース識別子は、コンテンツプロバイダに関連付けられたコンピューティングデバイスを参照し、それにより、クライアントコンピューティングデバイスは、さらなるリソースに対する要求を参照されたコンテンツプロバイダのコンピューティングデバイスに送信する。したがって、コンテンツ要求を満たすために、コンテンツプロバイダは、ウェブページに関連付けられたクライアントコンピューティングデバイスデータならびに埋込みリソースに関連付けられたデータを提供することとなる。

いくつかのコンテンツプロバイダは、コンテンツ配信ネットワーク（「ＣＤＮ」）サービスプロバイダを利用して、ウェブページおよび／またはウェブページ中で識別されるリソースなどの要求されたコンテンツの配信を可能にしようと試みる。ＣＤＮサーバプロバイダは、典型的には、様々なコンテンツプロバイダからのコンテンツを維持することできる通信ネットワーク中に、複数のコンピューティングデバイスを維持する。次に、コンテンツプロバイダは、ＣＤＮサービスプロバイダのコンピューティングデバイスからコンテンツプロバイダのコンテンツの一部またはすべてを要求するように、要求クライアントコンピューティングデバイスに命令する、または場合によっては、示唆することができる。

コンテンツプロバイダの場合と同様に、ＣＤＮサービスプロバイダも一般に、しばしばクライアントコンピューティングデバイスへの要求されたコンテンツの効率的な送信を考慮して、および／またはコンテンツの送信に関連付けられたコストを考慮して、クライアントコンピューティングデバイスに要求されたコンテンツを提供するように動機づけられる。したがって、ＣＤＮサービスプロバイダはしばしば、サービスレベルの契約を満たす、または配信サービスの質を全体的に改善するために、要求されたコンテンツの配信の待ち時間などの要因を考慮する。

複数のクライアントコンピューティングデバイスと、コンテンツプロバイダと、コンテンツ配信ネットワークサービスプロバイダとを含むコンテンツ配信環境を示すブロック図である。 図１のコンテンツ配信環境のブロック図であり、コンテンツプロバイダのコンテンツ配信サービスプロバイダへの登録を示す。 図１のコンテンツ配信環境のブロック図であり、クライアントコンピューティングデバイスからコンテンツプロバイダへのコンテンツ要求の生成および処理を示す。 図１のコンテンツ配信環境のブロック図であり、クライアントコンピューティングデバイスからコンテンツ配信ネットワークサービスプロバイダへの埋込みリソースに対応するＤＮＳクエリの生成および処理、ならびに後続の、クライアントコンピューティングデバイスからコンテンツ配信ネットワークへの第１の代替リソース識別子に対応するＤＮＳクエリの生成および処理の一実施形態を示す。 図１のコンテンツ配信環境のブロック図であり、クライアントコンピューティングデバイスからコンテンツ配信ネットワークサービスプロバイダへの埋込みリソースに対応するＤＮＳクエリの生成および処理、ならびに後続の、クライアントコンピューティングデバイスからコンテンツ配信ネットワークへの第１の代替リソース識別子に対応するＤＮＳクエリの生成および処理の一実施形態を示す。 図１のコンテンツ配信環境のブロック図であり、クライアントコンピューティングデバイスからコンテンツ配信ネットワークサービスプロバイダへの埋込みリソースに対応するＤＮＳクエリの生成および処理の別の実施形態を示す。 図１のコンテンツ配信環境のブロック図であり、クライアントコンピューティングデバイスからコンテンツ配信ネットワークサービスプロバイダへの埋込みリソース要求の生成および処理を示す。 リソース要求を処理するためにクエリＩＰアドレスのロケーションベース識別子へのマッピングを利用するコンテンツ配信ネットワークサービスプロバイダにより実装される要求ルーティングルーチンを示す流れ図である。 取得されたロケーションベース識別子に基づいてリソース要求をサービスするためのネットワークのポイントオブプレゼンスを決定するために、図７の例示的な流れ図のコンテンツ配信ネットワークサービスプロバイダにより実装される要求ルーティングサブルーチンを示す流れ図である。

発明の詳細な説明
本発明の上記の態様および付随する利点の多くは、以下の詳細な説明を添付の図面とともに参照することにより、より良く理解されることが容易に諒解されよう。

一般的に述べると、本開示は、コンテンツ要求に対応するクライアントコンピューティングデバイスからのＤＮＳクエリの、コンテンツ配信ネットワーク（「ＣＤＮ」）サービスプロバイダなどの、ネットワークリソースによるルーティングを対象とする。ＣＤＮサービスプロバイダによるＤＮＳクエリの処理は、一般に要求ルーティングと呼ばれる。具体的には、本開示の態様は、クライアントコンピューティングデバイスに関連付けられたクライアントロケーション情報に応じたＣＤＮサービスプロバイダドメイン内のクライアントコンピューティングデバイスのＤＮＳクエリのルーティングに関して説明される。一実施形態では、ＣＤＮサービスプロバイダは、要求されたリソースを提供するようにＣＤＮネットワークの構成部分を選択するために、クエリＩＰアドレスのロケーションベース識別子へのマッピングを利用する。クライアントコンピューティングデバイスのロケーションを特定することと、クライアントのロケーションに関連付けられた宛先中のＣＤＮネットワークの構成部分から要求されたリソースを送信することによって要求ルーティングに関連するパフォーマンスを改善しようと試みることとによって、ＣＤＮネットワーク構成部分を選択することができる。本開示の他の態様は、ＤＮＳクエリを解決することに関するパフォーマンスデータを収集することと、そのパフォーマンスデータに基づいてクライアントロケーション情報に関連するルーティング情報を更新することを対象とする。例示的な例および実施形態に関して、本開示の様々な態様について以下に説明するが、当業者には、開示する実施形態および例を限定的に解釈すべきではないことが諒解されよう。

図１は、コンテンツ要求の管理および処理のためのコンテンツ配信環境１００の例を示すブロック図である。図１に示すように、コンテンツ配信環境１００は、コンテンツプロバイダおよび／またはＣＤＮサービスプロバイダにコンテンツを要求するための複数のクライアントコンピューティングデバイス１０２（一般にクライアントと呼ばれる）を含む。例示的な実施形態では、クライアントコンピューティングデバイス１０２は、パーソナルコンピューティングデバイス、ラップトップコンピューティングデバイス、ハンドヘルドコンピューティングデバイス、ターミナルコンピューティングデバイス、モバイルデバイス、ワイヤレスデバイス、様々な電子デバイスおよび電子アプライアンスなどを含む多種多様なコンピューティングデバイスに対応することができる。例示的な実施形態では、クライアントコンピューティングデバイス１０２は、ワイドエリアネットワークまたはローカルエリアネットワークなどの通信ネットワーク１０８を介する通信を確立するために、必要なハードウェア構成部分およびソフトウェア構成部分を含む。たとえば、クライアントコンピューティングデバイス１０２は、インターネットまたはイントラネットを介する通信を可能にするネットワーキング機器およびブラウザソフトウェアアプリケーションを備えることができる。

図１には示されていないが、各クライアントコンピューティングデバイス１０２は、ＤＮＳネームサーバなど、そのクライアントコンピューティングデバイスに起因してＤＮＳクエリを生成する、ある種のローカルＤＮＳ解決構成部分を利用する。一実施形態では、クライアントコンピューティングデバイス１０２が属する企業ネットワークによってローカルＤＮＳ解決構成部分を提供することができる。別の実施形態では、通信ネットワーク接続をクライアントコンピューティングデバイス１０２に提供するインターネットサービスプロバイダ（ＩＳＰ）によって、ローカルＤＮＳ解決構成部分を提供することができる。

コンテンツ配信環境１００はまた、通信ネットワーク１０８を介して１つまたは複数のクライアントコンピューティングデバイス１０２と通信しているコンテンツプロバイダ１０４をも含むことができる。図１に示すコンテンツプロバイダ１０４は、コンテンツプロバイダに関連付けられた１つまたは複数のコンピューティングデバイスの論理的関連性に対応する。具体的には、コンテンツプロバイダ１０４は、クライアントコンピューティングデバイス１０２から（ウェブページなどの）コンテンツに関する要求を取得および処理するために、１つまたは複数のサーバコンピューティングデバイスに対応するウェブサーバ構成部分１１０を含むことができる。コンテンツプロバイダ１０４は、ＣＤＮサービスプロバイダからネットワークリソースに関する要求を取得および処理するために、１つまたは複数のコンピューティングデバイスに対応する起点サーバ構成部分１１２と関連付けられたストレージ構成部分１１４とをさらに含むことができる。当業者には、コンテンツプロバイダ１０４は、コンテンツおよびリソース、ＤＮＳネームサーバなどの管理のためのさらなるコンピューティングデバイスなどの様々なさらなるコンピューティングリソースに関連付けられ得ることが諒解されるであろう。たとえば、図１には示されていないが、コンテンツプロバイダ１０４は、コンテンツプロバイダに関連付けられた登録ドメインネームに関係するＤＮＳクエリを受信するように動作可能である、１つまたは複数のＤＮＳネームサーバ構成部分に関連付けられ得る。１つまたは複数のＤＮＳネームサーバは、コンテンツプロバイダ１０４の登録ドメインネームに対応するクライアントコンピューティングデバイスのＤＮＳクエリを解決するための権限を有することができる。ＤＮＳネームサーバが応答ＩＰアドレスを提供することによってクエリを解決することができる場合、ＤＮＳネームサーバ構成部分はＤＮＳクエリに対して権限を有すると見なされる。

図１を引き続き参照すると、コンテンツ配信環境１００は、通信ネットワーク１０８を介して１つまたは複数のクライアントコンピューティングデバイス１０２およびコンテンツプロバイダ１０４と通信しているＣＤＮサービスプロバイダ１０６をさらに含むことができる。図１に示すＣＤＮサービスプロバイダ１０６は、ＣＤＮサービスプロバイダに関連付けられた１つまたは複数のコンピューティングデバイスの論理的関連性に対応する。具体的には、ＣＤＮサービスプロバイダ１０６は、通信ネットワーク１０８上のノードに対応する複数のポイントオブプレゼンス（「ＰＯＰ」）ロケーション１１６、１２２、１２８を含むことができる。各ＰＯＰ１１６、１２２、１２８は、クライアントコンピュータ１０２からのＤＮＳクエリを解決するために、複数のＤＮＳサーバコンピューティングデバイスから構成されたＤＮＳ構成部分１１８、１２４、１３０を含む。各ＰＯＰ１１６、１２２、１２８はまた、コンテンツプロバイダからのリソースを記憶し、様々な要求されたリソースを様々なクライアントコンピュータに送信するために、複数のキャッシュサーバコンピューティングデバイスから構成されたリソースキャッシュ構成部分１２０、１２６、１３２を含む。

さらに、ＣＤＮサービスプロバイダ１０６は、参照により本明細書に組み込まれる２００７年６月２９日付けで出願された「Ｍａｐｐｉｎｇ Ａｔｔｒｉｂｕｔｅｓ ｔｏ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓｅｓ」と題する米国特許出願第１１／７７１，６７９号に開示されるような、クエリＩＰアドレスとロケーションベース識別子とのマッピングに関する情報、ならびにそれらのマッピングに関連付けられた確信度を維持するためのルーティングデータストア１３４を含む。いくつかの実施形態では、ロケーションベース識別子は、ＤＮＳクエリの起点に関連付けられた物理ロケーションまたは論理ロケーションに基づいて直接決定されたロケーションに対応することができる。それに加えて、またはそれに替えて、ロケーションベース識別子は、相対ロケーションを既知のロケーションに関連付けることに基づいて推測できる。たとえば、ロケーションベース識別子は、クライアントコンピューティングデバイスまたはそのローカルＤＮＳ解決手段とこれらＰＯＰとの間の要求ルーティングに関連付けられた測定された待ち時間情報に基づく（ＣＤＮサービスプロバイダに対応する）ＰＯＰの既知のロケーションに起因し得る。テスト手順または以前に観察された要求ルーティング挙動などによって測定された待ち時間情報を予め測定することができる。代替的には、リアルタイムベースまたは半リアルタイムベースで、測定された待ち時間情報を動的に測定することができる。

また、ルーティングデータストア１３４は、領域ＣＤＮ宛先識別子に対するロケーションベース識別子のマッピングなど、さらなるロケーションマッピング情報を維持することができる。さらに、ロケーションマッピングデータストア１３４は、各ＣＤＮ宛先識別子に関連付けられたＰＯＰのセットを識別する情報を含むことができる。さらに、ルーティングデータストア１３４はユーザプロファイル情報を含むことができ、そこから代替ユーザロケーション情報を取得することができる。さらに、ルーティングデータストア１３４は、コンテンツ要求をルーティングするためにＣＤＮサービスプロバイダ１０６により利用される、地域サービスプラン情報または他のルーティング基準などのコンテンツプロバイダ識別子（または起点識別子）に関連付けられたコンテンツプロバイダルーティング基準を含むことができる。さらに、ルーティングデータストア１３４は、処理要求に関連するパフォーマンスデータを維持することもできる。

例示的な実施形態では、ルーティングデータストア１３４は、ＰＯＰ１１６、１２２、１２８によってウェブサービスなどを介してアクセス可能な中央データストアに対応する。別の実施形態では、各ＰＯＰ１１６、１２２、１２８は、より詳細に後で説明するように要求ルーティングにおける利用のために、ルーティングデータストア１３４のローカル版を維持することができる。さらに、ルーティングデータストア１３４を単一のデータストアとして示しているが、当業者には、ルーティングデータストア１３４は１つまたは複数のデータストアに対応することができ、分散的な方法で実装できることが諒解されよう。

ＤＮＳ構成部分１１８、１２４、１３０と、リソースキャッシュ構成部分１２０、１２６、１３２とは、負荷バランシングソフトウェア／ハードウェア構成部分または負荷分散ソフトウェア／ハードウェア構成部分を含むが、それらに限定されない、通信を容易にするさらなるソフトウェアおよび／またはハードウェア構成部分をさらに含むことができる。

例示的な実施形態では、ＤＮＳ構成部分１１８、１２４、１３０およびリソースキャッシュ構成部分１２０、１２６、１３２は、構成部分または構成部分の一部分が物理的に別個であるかどうかにかかわらず、論理的にグループ化されていると考えられる。さらに、図１にはＰＯＰ１１６、１２２、１２８がＣＤＮサービスプロバイダ１０６に論理的に関連付けられているものとして示されているが、ＰＯＰは、様々な構成属性のクライアントコンピューティングデバイス１０２に最も良好にサービスを提供する方法で、通信ネットワーク１０８全体にわたって地理的に分散される。さらに、当業者には、ＣＤＮサービスプロバイダ１０６が、コンテンツおよびリソースなどの管理のためのさらなるコンピューティングデバイスなどの様々なさらなるコンピューティングリソースに関連付けられ得ることが諒解されよう。

当業者には、図１で提供された構成部分および構成が本質的に例示的なものであることが諒解されよう。したがって、特に、通信を容易にするためのさらなる構成部分、システムおよびサブシステムに関して、さらなる構成部分および／または構成あるいは代替的な構成部分および／または構成を利用してもよい。

次に図２〜図６を参照して、図１のコンテンツ配信環境１００の様々な構成部分間の相互動作を示す。しかしながら、例のために、図は単純化されており、通信を容易にするために利用される構成部分のうちの多くが示されていない。当業者には、本開示の趣旨および範囲から逸脱することなく、そのような構成部分を利用することができ、それに応じて、さらなる相互動作が生じるであろうことが諒解されよう。

図２を参照して、コンテンツプロバイダ１０４のＣＤＮサービスプロバイダ１０６への登録のための例示的な相互作用について説明する。図２に示すように、ＣＤＮコンテンツ登録プロセスは、コンテンツプロバイダ１０４のＣＤＮサービスプロバイダ１０６への登録で開始する。例示的な実施形態では、コンテンツプロバイダ１０４は、ＣＤＮサービスプロバイダ１０６がコンテンツプロバイダ１０４に代わってコンテンツを提供できるように、ＣＤＮサービスプロバイダ１０６に登録するために登録アプリケーションプログラムインターフェース（「ＡＰＩ」）を利用する。登録ＡＰＩは、要求されたリソースをＣＤＮサービスプロバイダ１０６に提供するコンテンツプロバイダ１０４の起点サーバ１１２の識別情報を含む。さらに、後で詳しく述べるように、コンテンツプロバイダ１０４は、コンテンツ要求をルーティングするためにＣＤＮサービスプロバイダ１０６により利用される、地域サービスプランの情報または他のルーティング基準などの追加情報をも提供することができる。一実施形態では、ルーティング基準は、特定の地域サービスプランの仕様を含むことができ、その仕様は、コンテンツ要求がＣＤＮサービスプロバイダ１０６によって解決され得る地域を限定し得る。別の実施形態では、ルーティング基準は、ＣＤＮサービスプロバイダ１０６が特定の地域宛先またはＰＯＰから、あるいは地域宛先またはＰＯＰの特定の分布から特定のリソース要求をサービスしようと試みなければならないという、コンテンツプロバイダ１０４による選択を含むことができる。

当業者には、妥当性のある起点サーバ１１２が識別されると、コンテンツプロバイダ１０４は、コンテンツに関する要求をクライアントコンピューティングデバイス１０２からＣＤＮサービスプロバイダ１０６に向け始めることができることが諒解されよう。具体的には、ＤＮＳルーティング原理に従って、リソース識別子に対応するクライアントコンピューティングデバイス要求は最終的に、ＣＤＮサービスプロバイダ１０６に関連付けられたＰＯＰ１１６、１２２、１２８に向かって送られる。選択されたＰＯＰのリソースキャッシュ構成部分１２０、１２６、１３２が、クライアントコンピューティングデバイス１０２により要求されたリソースの複製を有しない場合、リソースキャッシュ構成部分は、コンテンツプロバイダ１０４によって以前に登録されている起点サーバ１１２にリソースを要求する。

図２を引き続き参照すると、ＣＤＮサービスプロバイダ１０６は、登録ＡＰＩを受信すると、登録情報を取得し、処理する。例示的な実施形態では、ＣＤＮサービスプロバイダ１０６は次いで、クライアントコンピューティングデバイス１０２によりコンテンツ要求の一部として使用される追加情報を生成することができる。追加情報は、コンテンツプロバイダ識別コードまたは起点サーバ識別子などのコンテンツプロバイダ識別子、スクリプトベースの命令などのリソース識別子を処理するための実行可能コードなどを含むことができるが、これらに限定されるものではない。当業者には、ＣＤＮサービスプロバイダ１０６によって、様々なタイプの追加情報を生成することができ、追加情報を様々なフォーマットのいずれか１つで実施できることが諒解されよう。

ＣＤＮサービスプロバイダ１０６は、（以前に提供されたものでない限り）ＣＤＮサービスプロバイダのための適用可能なドメインの識別情報と、任意の追加情報とをコンテンツプロバイダ１０４に戻す。次に、コンテンツプロバイダ１０４は、記憶されたコンテンツをコンテンツプロバイダ固有の情報を用いて処理することができる。一例では、図２に示すように、コンテンツプロバイダ１０４は、当初起点サーバ１１２のドメインに向けられたリソース識別子をＣＤＮサービスプロバイダに対応するドメインに変換する。変換されたＵＲＬは、変換されたＵＲＬに対するＤＮＳクエリは、ＣＤＮサービスプロバイダ１０６に対応するＤＮＳサーバ対して解決し、コンテンツプロバイダ１０４に対応するＤＮＳサーバに対しては解決されない方法で、要求されたコンテンツに埋め込まれる。変換プロセスを図２に示すが、いくつかの実施形態では、より詳細に後で説明する方法で変換プロセスを省略することができる。

一般に、当初コンテンツプロバイダ１０４に向けられたリソースの識別情報は、ブラウザソフトウェアアプリケーションなどを通じて、クライアントコンピューティングデバイス１０２によって処理できるソース識別子の形態とすることができる。例示的な実施形態では、リソース識別子は、ユニフォームリソースロケータ（「ＵＲＬ」）の形態とすることができる。リソース識別子がコンテンツプロバイダに向けられた要求されたコンテンツ中に含まれるので、一般に、リソース識別子を「コンテンツプロバイダＵＲＬ」と呼ぶことができる。説明的な例では、コンテンツプロバイダＵＲＬは、コンテンツプロバイダ１０４のドメイン（たとえば、ｃｏｎｔｅｎｔｐｒｏｖｉｄｅｒ．ｃｏｍ）と、要求されるべきリソース名（たとえば、「ｒｅｓｏｕｒｃｅ．ｘｘｘ」）と、リソースが発見される経路（たとえば、「ｐａｔｈ」）とを特定することができる。この説明的な例では、コンテンツプロバイダＵＲＬは、
http://www.contentprovider.com/path/resource.xxx
の形態を有する。

例示的な変換プロセス中に、コンテンツプロバイダＵＲＬが変更され、変換されたＵＲＬに関連付けられたリソースに関する要求がＣＤＮサービスプロバイダ１０６に関連付けられたＰＯＰに対して解決するようになる。一実施形態では、変換されたＵＲＬは、ＣＤＮサービスプロバイダ１０６のドメイン（たとえば、「ｃｄｎｐｒｏｖｉｄｅｒ．ｃｏｍ」）と、要求されるべきリソースの同じ名前（たとえば、「ｒｅｓｏｕｒｃｅ．ｘｘｘ」）と、リソースが発見される同じ経路（たとえば、「ｐａｔｈ」）とを特定する。さらに、変換されたＵＲＬは、さらなる処理情報（たとえば、「追加情報」）を含むことができる。具体的には、前述のように、１つの例示的な実施形態では、追加情報は、コンテンツプロバイダの識別子を含むことができる。さらに、変換されたＵＲＬは、限定されないが、サービスプラン情報、ファイル識別子などを含む、要求ルーティング中にＣＤＮサービスプロバイダにより利用される任意の追加情報を含むことができる。そのような情報は、変更されたＵＲＬ中に含まれ得、あるいは、変換されたＵＲＬから除外され、コンテンツプロバイダ識別子によるルックアップなどによって要求ルーティングプロセス中にＣＤＮサービスプロバイダ１０６によって取得され得る。変換されたＵＲＬは、以下の形態を有することとなる。
http://additional_information.cdnprovider.com/path/resource.xxx
別の実施形態では、ＣＤＮサービスプロバイダ１０６に関連する情報は、プリペンディングまたは他の技法などによって変更ＵＲＬ中に含まれ、それにより、変換されたＵＲＬは、元のＵＲＬに伴う情報のすべてを維持することができる。この実施形態では、変換されたＵＲＬは、以下の形態を有することとなる。
http://additional_information.cdnprovider.com/www.contentprovider.com/path/resource.xxx

次に図３を参照すると、図２に示された登録処理および変換処理の完了後に、クライアントコンピューティングデバイス１０２は、続いて、ウェブサーバ１１０などを介して、コンテンツプロバイダ１０４によって受信および処理されるコンテンツ要求を生成する。例示的な実施形態によると、コンテンツの要求は、ハイパーテキスト転送プロトコル（「ＨＴＴＰ」）などの通常のネットワークプロトコルに従うことができる。コンテンツ要求を受信すると、コンテンツプロバイダ１０４は、妥当性のある応答コンテンツを識別する。例示的な実施形態では、要求されたコンテンツは、ハイパーテキストマークアップ言語（「ＨＴＭＬ」）、拡張可能マークアップ言語（「ＸＭＬ」）などのような、情報の処理を介してクライアントコンピューティングデバイス１０２上に表示されるウェブページに対応できる。要求されたコンテンツはまた、要求されたコンテンツの処理の一部としてクライアントコンピューティングデバイス１０２により取得されなければならないリソースオブジェクトに対応する、上述の複数の埋込みリソース識別子を含むことができる。埋込みリソース識別子は一般に、元のリソース識別子または元のＵＲＬと呼ぶことができる。

要求されたコンテンツを受信すると、クライアントコンピューティングデバイス１０２は、ブラウザソフトウェアアプリケーションなどを介して、コンテンツ中に含まれるマークアップコードのうちのいずれかの処理を開始し、埋込みリソース識別子により特定されるリソースを獲得しようと試みる。したがって、コンテンツを獲得する第１のステップは、クライアントコンピューティングデバイス１０２による（そのローカルＤＮＳ解決手段を介した）、変換されたＵＲＬの「．」部分および「ｃｏｍ」部分に対して権限を有するＤＮＳサーバの識別情報を生じる元のＵＲＬリソース識別子に関するＤＮＳクエリの発行に対応する。埋込みＵＲＬの「．」部分および「ｃｏｍ」部分を処理した後、クライアントコンピューティングデバイス１０２は次いで、埋込みＵＲＬの「．ｃｄｎｐｒｏｖｉｄｅｒ」部分に対して権限を有するＤＮＳサーバの識別情報を生じるリソースＵＲＬに関するＤＮＳクエリを発行する。ＵＲＬの「．」部分および「ｃｏｍ」部分に対応するＤＮＳクエリの発行はよく知られており、図示してはいない。

次に図４Ａを参照すると、例示的な実施形態では、元のＵＲＬの「ｃｄｎｐｒｏｖｉｄｅｒ」部分の正常な解決は、ＩＰアドレスなど、ＣＤＮサービスプロバイダ１０６に関連付けられたＤＮＳサーバのネットワークアドレスを特定する。一実施形態では、ＩＰアドレスは、ＰＯＰのＤＮＳサーバ構成部分に固有の特定のネットワークアドレスとすることができる。別の実施形態では、１つまたは複数のＰＯＰによって、ＩＰアドレスを共有することができる。この実施形態では、共有ＩＰアドレスに対するさらなるＤＮＳクエリは、特定のＰＯＰがネットワークトポロジに応じて要求を受信するように、エニーキャストなどの１対多数のネットワークルーティングスキームを利用する。たとえば、エニーキャスト実装形態では、共有ＩＰアドレスに対してクライアントコンピューティングデバイス１０２により発行されたＤＮＳクエリは、クライアントコンピューティングデバイスからのネットワークトポロジ距離が論理的には最も短いＤＮＳサーバ構成部分に到着し、この構成部分は、しばしばネットワークホップと呼ばれる。ネットワークトポロジ距離は、地理的距離に必ずしも対応するものではない。しかしながら、いくつかの実施形態では、ネットワークトポロジ距離は、クライアントコンピューティングデバイス１０２とＰＯＰとの間の最短のネットワーク距離であると推測できる。

図４Ａを引き続き参照すると、上記の特定された実施形態（または任意の他の実施形態）のいずれにおいても、ＰＯＰ１１６のＤＮＳ構成部分１１８中の特定のＤＮＳサーバは、元のＵＲＬに対応するＤＮＳクエリをクライアントコンピューティングデバイス１０２から受信する。ＤＮＳ構成部分１１８中のＤＮＳサーバのうちの１つが要求を受信すると、その特定のＤＮＳサーバは要求を解決しようと試みる。１つの例示的な実施形態では、図５を参照して示すように、特定のＤＮＳサーバは、要求されたリソースに関する要求を処理するキャッシュサーバ構成部分のＩＰアドレスを特定することによって、ＤＮＳクエリを解決する。上述のように、また図６を参照してさらに後述するように、選択されたリソースキャッシュ構成部分は、利用可能な場合には要求されたリソースを提供し、あるいは、要求されたリソースをピアキャッシュサーバコンピューティングデバイスまたはコンテンツプロバイダ１０４の起点サーバ１１２などの別のソースから取得しようとすることによって、要求を処理できる。

図４Ａに戻ると、図５を参照して説明するようにＤＮＳクエリを受信したときにリソースキャッシュ構成部分を選択することに替わる方法として、ＣＤＮサービスプロバイダ１０６は、様々な代替リソース識別子のセットを維持することができる。代替リソース識別子は、ＣＤＮサービスプロバイダ１０６によって、クライアントコンピューティングデバイス１０２に提供でき、それにより、代替リソース識別子に関する後続のＤＮＳクエリが、ＣＤＮサービスプロバイダのネットワーク内の異なるＤＮＳサーバ構成部分によって、処理される。例示的な実施形態では、代替リソース識別子は、１つまたは複数の正規名（「ＣＮＡＭＥ」）レコードの形態である。一実施形態では、各ＣＮＡＭＥレコードは、ＣＤＮサービスプロバイダ１０６のドメイン（たとえば、「ｃｄｎｐｒｏｖｉｄｅｒ．ｃｏｍまたはｃｄｎｐｒｏｖｉｄｅｒ−ｌ．ｃｏｍ）を特定する。後でさらに詳しく述べるように、ＣＮＡＭＥ中にドメインは、元のＵＲＬ中で、または、以前のＣＮＡＭＥレコード中で見出されるのと同じドメインである必要はない。さらに、各ＣＮＡＭＥレコードは、要求ルーティング情報などの追加情報を含む（たとえば、「ｒｅｑｕｅｓｔ ｒｏｕｔｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ」）。例示的なＣＮＡＭＥレコードは、以下の形態を有することができる。
http://request_routing_information.cdnprovider.com/path/resource.xxx CNAME request routing_information_cdnprovider.com

例示的な実施形態では、ＣＮＡＭＥレコードは、ＣＤＮサービスプロバイダ１０６のより妥当性のあるＤＮＳサーバを識別するために、ＤＮＳサーバにより生成され、提供される。本開示に従って使用される場合、妥当性は、様々な目的のためにＣＤＮサービスプロバイダ１０６によって定義することができる。例示的な実施形態では、図７および図８を参照して後でさらに詳しく述べるように、ＣＤＮサービスプロバイダ１０６は、少なくとも部分的には、ＣＤＮサービスプロバイダ１０６のより妥当性のあるＤＮＳサーバを特定するために、クライアントコンピューティングデバイス１０２またはそのローカルＤＮＳ解決手段に関連付けられたクライアントロケーション情報を利用する。具体的には、ＣＤＮサービスプロバイダ１０６は、クライアントコンピューティングデバイスのＤＮＳクエリに関連付けられたＩＰアドレスを利用して、クライアントコンピューティングデバイスの可能なロケーションを表す対応するロケーションベースの識別子を特定することができる。ＣＤＮサービスプロバイダ１０６は、次に、リソース要求が解決されなければならないＣＤＮサービスプロバイダ１０６に関連付けられた地域を表す宛先識別子を特定するために、ロケーションベース識別子を利用できる。次いで、宛先識別子に基づいて、ＣＤＮサービスプロバイダ１０６は、宛先識別子に対応する宛先に対してリソース要求に対応してサービスを提供することが可能なＰＯＰのセットからＰＯＰ１１６、１２２、１２８を選択することができる。一例では、２つ以上のＰＯＰがセット中で特定される場合、ＣＤＮサービスプロバイダ１０６は特定された宛先に関連付けられた特定のＰＯＰを選択するために配信割振りを利用することができる。別の例では、ＰＯＰが選択されると、ＣＤＮサービスプロバイダ１０６はさらに健康情報を使用して、選択されたＰＯＰに対応するＣＮＡＭＥをクライアントコンピューティングデバイスに提供する前に、選択されたＰＯＰがサービス要求に対して利用可能であるかどうかを判断することができる。当業者には、上記の機能が本質的に例にすぎず、したがって、限定として解釈されるべきではないことが諒解されよう。

上述のように、クライアントロケーション情報（エンドクライアントまたはその関連付けられたローカルＤＮＳ解決構成部分のいずれか）を考慮するだけでなく、ＣＤＮサービスプロバイダ１０６は、変換されたＵＲＬ中に含まれるさらなる情報（たとえば、追加情報）を利用して、より妥当性のあるＤＮＳサーバを選択することができる。一態様では、ＣＤＮサービスプロバイダ１０６は、クライアントロケーション情報に関連する基準を満していると識別されるＤＮＳサーバのセットから選択するために、追加情報を利用できる。別の態様では、ＣＤＮサービスプロバイダ１０６は、追加情報を利用して、クライアントロケーション情報に従って選択されたＤＮＳサーバを有効にする、またはクライアントロケーション情報に従って以前に選択された代替ＤＮＳサーバを選択することができる。一例では、ＣＤＮサービスプロバイダ１０６は、追加の地理的基準に従って、ＤＮＳクエリをＤＮＳサーバに向けることを試みることができる。追加の地理的基準は、ＣＤＮサービスプロバイダ１０６とコンテンツプロバイダ１０４との間に結ばれた地理ベースの地域サービスプランに対応することができ、様々なＣＤＮサービスプロバイダ１０６のＰＯＰが地域へとグループ化される。したがって、コンテンツプロバイダの地域プランに対応しない地域で受信されたクライアントコンピューティングデバイス１０２のＤＮＳクエリは、コンテンツプロバイダの地域プランに対応する地域のＤＮＳサーバによって、より良好に処理できる。

別の例では、ＣＤＮサービスプロバイダ１０６は、サービスレベル基準に従ってＤＮＳクエリをＤＮＳサーバに向けることを試みることができる。サービスレベル基準は、ＣＤＮサービスプロバイダ１０６とコンテンツプロバイダ１０４との間に結ばれるサービスメトリックまたはパフォーマンスメトリックに対応することができる。パフォーマンスメトリックの例として、ＣＤＮサービスプロバイダのＰＯＰとクライアントコンピューティングデバイス１０２との間のデータ送信の待ち時間、コンテンツプロバイダ１０４に代わってＣＤＮサービスプロバイダのＰＯＰにより提供される全データ、データ送信のためのエラーレートなどを含むことができる。

さらなる一例では、ＣＤＮサービスプロバイダ１０６は、ネットワークパフォーマンス基準に従って、ＤＮＳクエリをＤＮＳサーバに向けることを試みることができる。ネットワークパフォーマンス基準は、ＣＤＮサービスプロバイダのＰＯＰからクライアントコンピューティングデバイス１０２にデータを送信することについてのネットワークパフォーマンスの測定に対応することができる。ネットワークパフォーマンスメトリックの例として、（クライアントコンピューティングデバイスまたはＣＤＮサービスプロバイダ１０６により測定された）ネットワークデータ転送待ち時間、ネットワークデータエラーレートなどを含むことができる。

例示的な実施形態によると、ＤＮＳサーバは、様々な元のＵＲＬに対するＣＮＡＭＥレコードを定義するデータストアを維持する。特定の元のＵＲＬに対応するＤＮＳクエリがデータストア中のエントリに一致する場合、ＤＮＳサーバはデータストアにおいて定義されるようにＣＮＡＭＥレコードを戻す。例示的な実施形態では、データストアは、特定の元のＵＲＬに対応する複数のＣＮＡＭＥレコードを含むことができる。複数のＣＮＡＭＥレコードは、クライアントコンピューティングデバイスに戻すことができる潜在的な候補のセットを定義する。このような実施形態では、ＤＮＳサーバは、直接、またはネットワークベースサービスを介してのいずれかにより、ＣＮＡＭＥの可能なセットから妥当性のあるＣＮＡＭＥを選択することにおいてさらなる論理を実施できる。例示的な実施形態では、各ＤＮＳサーバ構成部分１１８、１２４、１３０は、ＣＮＡＭＥレコードを定義する同じデータストアを維持し、それらは、ＣＤＮサービスプロバイダ１０６によって集中的に管理できる。代替的には、各ＤＮＳサーバ構成部分１１８、１２４、１３０は、ＣＮＡＭＥレコードを定義する、ＰＯＰに限定されたデータストアを有することができ、それらは、ＣＤＮサービスプロバイダ１０６によって集中的に、または、ＰＯＰ１１６、１２２、１２８においてローカルで管理できる。さらに、ＤＮＳサーバ構成部分１１８、１２４、１３０内の各ＤＮＳサーバコンピューティングデバイスは、それぞれに対応するＰＯＰにより管理された共有データストア、または個々のＤＮＳサーバコンピューティングデバイスに固有のローカルデータストアを利用することができる。

また、戻されたＣＮＡＭＥは、現在のＤＮＳクエリのＵＲＬ／ＣＮＡＭＥ中で提供される情報とは異なる要求ルーティング情報を含むことができ、または、現在のＤＮＳクエリのＵＲＬ／ＣＮＡＭＥ中で提供される情報に加えて要求ルーティング情報を含むことができる。たとえば、特定の地域プランは、特定のＣＮＡＭＥレコードの「ｒｅｑｕｅｓｔ＿ｒｏｕｔｉｎｇ＿ｉｎｆｏｒｍａｔｉｏｎ」部分で特定できる。ＣＮＡＭＥレコードの「ｒｅｑｕｅｓｔ＿ｒｏｕｔｉｎｇ＿ｉｎｆｏｒｍａｔｉｏｎ」部分に特定の識別子を含むことによって、サービスレベルプランおよびファイル管理を特定するために、同様の手法をとることができる。別の実施形態では、要求ルーティング情報は、現在のＵＲＬ／ＣＮＡＭＥ中で見出されるドメインとは異なるＣＤＮサービスプロバイダ１０６のドメインの識別情報中で見出すことができる。たとえば、特定の地域プランドメイン（たとえば、「ｃｄｎｐｒｏｖｄｅｒ−ｒｅｇｉｏｎ１．ｃｏｍ」）は、特定のＣＮＡＭＥレコードのドメイン名部分において使用され得る。任意のさらなる要求ルーティング情報を、以前の要求ルーティング情報が失われないように、現在のＵＲＬ／ＣＮＡＭＥ中の既存の要求ルーティング情報にプリペンディングできる（たとえば、serviceplan.regionalplan.cdnprovider.com）。当業者には、追加の技法もしくは代替技法および／または技法の組合せを使用して、ＤＮＳサーバ構成部分１１８により選択されるＣＮＡＭＥレコード中にさらなる要求ルーティング情報を含めることができる。

図４Ａを引き続き参照すると、当業者には、ＤＮＳサーバが、ＣＤＮサービスプロバイダ１０６のより妥当性のあるＤＮＳサーバに対して解決することを意図するＣＮＡＭＥレコードを選択する（または場合によっては、取得する）ことができることが諒解されよう。しかしながら、同じＤＮＳサーバが、クライアントコンピューティングデバイスに提供されるべきＣＮＡＭＥに関する後続のＤＮＳクエリに対しても権限を有することが可能であり得る。たとえば、特定のＤＮＳサーバは、クライアントコンピュータデバイスに関連付けられた特定の地理的ロケーションと、クライアントロケーション情報に基づいてコンテンツプロバイダプランにより特定される特定の地域プランとに基づいて権限を有することができる。したがって、ＣＮＡＭＥを戻した結果、依然として、ＤＮＳクエリは、（同じくクライアントコンピューティングデバイスの地理にも部分的に起因し得る）同じＤＮＳサーバに到着することになる。このような実施形態では、ＤＮＳサーバ構成部分１１８などのＤＮＳサーバは、事前に将来のＤＮＳクエリを解決するように選択することができる。

次に図４Ｂに参照すると、クライアントコンピューティングデバイス１０２は、ＤＮＳサーバ構成部分１１８からＣＮＡＭＥを受信すると、ＣＮＡＭＥに対応する後続のＤＮＳクエリを生成する。図４Ａに関して前述したように、ＤＮＳクエリ処理はまず、「．」部分および「ｃｏｍ」部分に関するＤＮＳクエリで開始することができ、ＣＮＡＭＥの「ｃｄｎｐｒｏｖｉｄｅｒ」部分に関するクエリがその後に続く。しかしながら、以前のＤＮＳクエリの結果をキャッシュすることができる（およびそれが有効なままである）限り、クライアントコンピューティングデバイス１０２は、キャッシュされた情報を利用することができ、プロセス全体を反復する必要はない。しかしながら、ある時点で、ＤＮＳサーバ構成部分１１８により提供されたＣＮＡＭＥ（図４Ａ）と以前のＵＲＬ／ＣＮＡＭＥとが、共通するＣＤＮサービスプロバイダドメインを共有するかどうかに応じて、現在のＣＮＡＭＥＤＮＳクエリは、ＣＤＮサービスプロバイダ１０６により提供される異なるＰＯＰにより処理される。図４Ｂに示すように、ＰＯＰ１２２のＤＮＳサーバ構成部分１２４は、ＤＮＳサーバ構成部分１１８によって、以前に提供された現在のＣＮＡＭＥ中の異なる情報に基づいて、現在のＣＮＡＭＥを受信する。前述のように、ＤＮＳサーバ構成部分１２４は、次いで、コンテンツ要求を処理するキャッシュ構成部分のＩＰアドレスを用いてＣＮＡＭＥに関するＤＮＳクエリを解決するべきかどうか、または上述の方法で選択された別の代替リソース識別子を提供すべきかどうかを決定できる。

例示のために、リソースキャッシュ構成部分のＩＰアドレスを戻すことによって、ＤＮＳサーバ構成部分１２４がコンテンツ要求を処理すると仮定する。例示的な実施形態では、ＤＮＳサーバ構成部分１２４は、リソースキャッシュ構成部分を選択する際に様々な情報を利用できる。一例では、ＤＮＳサーバ構成部分１２４は、同じＰＯＰのリソースキャッシュ構成部分を選択するようにデフォルト設定できる。別の例では、ＤＮＳサーバ構成部分は、様々な負荷バランシングアルゴリズムまたは負荷分散アルゴリズムに基づいてリソースキャッシュ構成部分を選択できる。さらに、ＤＮＳサーバ構成部分は、ネットワークパフォーマンスメトリックまたは測定を利用して、特定のリソースキャッシュ構成部分を割り当てることができる。ＤＮＳサーバ構成部分により選択されるＩＰアドレスは、リソースキャッシュ中の特定のキャッシングサーバに対応し得る。代替的には、ＩＰアドレスは、（ロードバランサなどの）ハードウェア／ソフトウェア選択構成部分に対応することができる。

図４Ｂを引き続き参照すると、ＣＤＮサービスプロバイダ１０６は、コンテンツ要求の解決に関連するパフォーマンスデータを収集し、そのパフォーマンスデータを利用して、ルーティング情報に対して何か更新が行われなければならないかどうかを決定する。ＣＤＮサービスプロバイダ１０６は、プロセス中の任意の時間に、またはコンテンツ要求の解決後に、パフォーマンスデータを収集することができる。そのようなパフォーマンスデータは、ＣＤＮサービスプロバイダのＰＯＰからクライアントコンピューティングデバイス１０２へのデータ送信についての、ネットワークパフォーマンスの測定を含むことができる。一実施形態では、要求されたリソースの配信に伴うネットワークデータ転送待ち時間が、クライアントコンピューティングデバイス１０２により測定される。代替的には、ＣＤＮサービスプロバイダ１０６は、リソースキャッシュ構成部分などを介して、クライアントコンピューティングデバイスにコンテンツを提供することの一部としての、パフォーマンスを測定することができる。そのようなネットワークパフォーマンスデータは、ＣＤＮサービスプロバイダによって包括的に管理および維持でき、ＣＤＮのＤＮＳサーバと、または、個別にＣＤＮサービスプロバイダのＤＮＳサーバによって共有できる。さらに、ネットワークパフォーマンス基準は、ＰＯＰからのバッチプロセスとして提供できるか、または１つのＰＯＰから別のＰＯＰへの要求に応答して送られる。

さらに、一実施形態では、エンドクライアントの経験と関係するパフォーマンスデータを収集することができるが、このデータ収集は、どのようにクライアント要求がルーティングされるかと無関係とすることができる。たとえば、クライアント要求のためのルーティング選択は、クライアントのＤＮＳ解決手段に関連付けられたＩＰアドレスに基づくことができるが、その要求の解決に関連するパフォーマンスデータは、エンドクライアントデバイスの経験に基づくことができる。

次いで、収集されたパフォーマンスデータに基づいて、ＣＤＮサービスプロバイダは、クライアントロケーション情報に関連するルーティング情報の更新が必要かどうかを決定することができる。ルーティング情報の更新は、既存のルーティング情報を修正および／または削除すること、新しいルーティング情報を追加することなどによって複数の方法で実現できる。一実施形態では、更新の決定は、ＣＤＮサービスプロバイダによって包括的に、あるいは個々のＤＮＳサービス構成部分またはＤＮＳサーバにより行うことができる。個々のＤＮＳサーバがルーティング情報を更新すべきかどうかを決定する例示的な実施形態では、各ＤＮＳサーバは、特定のＤＮＳサーバに固有のルーティング情報を管理および維持することができる。この例示的な実施形態では、パフォーマンスデータを、ＣＤＮサービスプロバイダによって包括的に維持し、ＤＮＳ構成部分および／またはＤＮＳサーバと共有することができ、各ＤＮＳ構成部分および／またはＤＮＳサーバは、どのようにパフォーマンスデータが使用されるかを管理する。したがって、ルーティング情報は、ＤＮＳ構成部分／サーバごとに異なり得る。

次に図６を参照すると、例示的な例において、ＤＮＳサーバ構成部分１２４がＰＯＰ１２２のリソースキャッシュ構成部分１２６を選択したと仮定する。リソースキャッシュ構成部分１２６のＩＰアドレスを受信すると、クライアントコンピューティングデバイス１０２は、要求されるコンテンツへの要求をリソースキャッシュ構成部分１２６に送信する。リソースキャッシュ構成部分１２６は、上述の方法で要求を処理し、要求されたコンテンツは、クライアントコンピューティングデバイス１０２に送信される。

次に図７を参照すると、リソース要求ならびにリソース要求の解決に関連するパフォーマンスデータを処理するためにＣＤＮサービスプロバイダ１０６により実装される要求ルーチン７００の一実施形態を説明する。当業者には、ルーチン７００について概説される動作／ステップが、ＣＤＮサービスプロバイダ１０６に関連付けられた１つまたは複数のコンピューティングデバイス／構成部分によって実装できることが諒解されよう。したがって、ルーチン７００は、一般に、ＣＤＮサービスプロバイダ１０６により実行されるように論理的に関連付けられ、したがって、以下の例示的な実施形態は限定的なものと解釈されるべきではない。

ブロック７０２において、ＤＮＳサーバ構成部分１１８、１２４、１３０のうちの１つが、リソース識別子に対応するＤＮＳクエリを受信する。前述のように、リソース識別子は、クライアントコンピューティングデバイス１０２により要求され、コンテンツプロバイダ１０４によって以前に提供されたコンテンツ中に埋め込まれたＵＲＬとすることができる。代替的には、リソース識別子はまた、クライアントコンピューティングデバイス１０２から以前に受信されたＤＮＳクエリに応答して、コンテンツプロバイダのＤＮＳサーバにより提供されたＣＮＡＭＥに対応できる。また、ブロック７０２において、受信側ＤＮＳサーバは、要求側クライアントコンピューティングデバイス１０２（「クエリＩＰアドレス」）からＤＮＳクエリに関連付けられたＩＰアドレスを取得する。クエリＩＰアドレスは、クライアントコンピューティングデバイスまたはクライアントコンピューティングデバイスに関連付けられた任意のローカルＤＮＳ解決構成部分のＩＰアドレスに対応することができる。

次に、ブロック７０４において、受信側ＤＮＳサーバは、クエリＩＰアドレスに関連付けられたロケーションベース識別子を取得する。各ＤＮＳサーバは、ロケーションベース識別子のセットを既知のＩＰアドレスの少なくとも一部分にマッピングする（たとえば、特定のロケーションベース識別子を特定のＩＰアドレスまたは特定の部分ＩＰアドレスとマッピングする）データストア１３４を維持する（または場合によっては、データストア１３４アクセスする）。データストア１３４を利用して、受信側ＤＮＳサーバは、（ローカルＤＮＳレゾルバ構成部分を介して送信されるような）クライアントコンピューティングデバイス１０２のＤＮＳクエリに関連付けられたＩＰアドレスをデータストア１３４中のＩＰアドレスと照合することを試みる。クエリＩＰアドレスがデータストア１３４中のＩＰアドレスと部分的に照合できる場合、ＤＮＳサーバは対応するロケーションベース識別子を特定する。このようにして、受信側ＤＮＳサーバが以前に評価しなかったクエリＩＰアドレスを、既存のデータに基づいて、およびさらに後で説明するようにルーティングすることができ、その後、クエリに関係するパフォーマンスデータに基づいて、ルーティング情報に対して更新を行うことができる。たとえば、受信側ＤＮＳサーバは、ＣＤＮサービスプロバイダ１０６が、クエリＩＰアドレスを別様に扱われなければならないと決定するまで、ＩＰアドレス（たとえば、１２８．１．ｘ．ｘ）の特定のグループに入るクエリＩＰアドレス（たとえば、１２８．１．３．１２）が同様に扱われることを決定することができる。

上で同様に示されるように、ロケーションベース識別子は、ＤＮＳクエリの起点に関連付けられた物理ロケーションまたは論理ロケーションに基づいて直接決定されたロケーションに対応することができる。さらに、ロケーションベース識別子は、相対ロケーションを既知のロケーションに関連付けることに基づいて推測できる。たとえば、ロケーションベース識別子は、クライアントコンピューティングデバイスまたはそのローカルＤＮＳ解決手段とこれらのＰＯＰとの間の要求ルーティングに関連する待ち時間の測定情報に基づいて、（ＣＤＮサービスプロバイダに対応する）ＰＯＰの既知のロケーションに帰属させることができる。テスト手順または以前に観察された要求ルーティング挙動などによって、待ち時間測定情報を事前に測定することができる。代替的には、待ち時間測定情報は、リアルタイムベースまたは半リアルタイムベースで動的に測定することができる。

例示的な実施形態では、ＤＮＳサーバはまた、ブロック７０４において、データストア１３４からロケーションベース識別子に関連付けられた確信度を任意選択で取得する。確信度は、クエリＩＰアドレスへの関連付けられたロケーションベース識別子の精度における信頼度に対応する。任意選択の確信度については、図８を参照してさらに説明する。

次に、ブロック７０６において、受信側ＤＮＳサーバは、リソース要求を解決するために、取得されたロケーションベース識別子に関連付けられた１つまたは複数のＰＯＰのセットから１つのＰＯＰを決定する。一般に、１つまたは複数のＰＯＰのセットは、要求側クライアントコンピューティングデバイス１０２の識別されたロケーションに関連付けられた地域からのリソース要求に対応してサービスを提供することが可能である。さらに後で説明するように、図８は、ブロック７０６に関連する機能を実行するための要求ルーティングサブルーチンの一実施形態を示す。

決定ブロック７０８において、現在のＤＮＳサーバがＤＮＳクエリを解決する権限を有するかどうかを決定するために、テストが行われる。１つの例示的な実施形態では、ＤＮＳサーバは、リソース要求を解決するために決定されたＰＯＰが受信側ＤＮＳサーバに関連付けられた同じＰＯＰに対応する場合、ＤＮＳクエリを解決する権限を有するかどうかを決定できる。決定されたＰＯＰが受信側ＤＮＳサーバに関連付けられた同じＰＯＰに実際に対応する場合、受信側ＤＮＳサーバは権限を有すると見なされ、受信側ＤＮＳサーバは、ブロック７１０において後続のクライアントリソース要求（たとえば、埋込みリソースに関する要求）を処理するために、同じＰＯＰからのリソースキャッシュ構成部分に関連付けられたキャッシュサーバを特定する。受信側ＤＮＳサーバは、たとえば、同じＰＯＰからのリソースキャッシュ構成部分に関連付けられたデフォルトのキャッシュサーバもしくは特定のキャッシュサーバ、または（適切であれば）負荷バランシング構成部分のＩＰアドレスを戻すことによって、ＤＮＳクエリを解決する。ＰＯＰにおいて、妥当性のあるリソースキャッシュ構成部分を選択するための複数の方法を実装することができる。

代替的には、決定ブロック７０８で、決定されたＰＯＰがＣＤＮサービスプロバイダ１０６の別のＰＯＰに対応し、したがって受信側ＤＮＳサーバが権限を有しない場合、受信側ＤＮＳサーバはブロック７１２において、代替リソース識別子を選択し、送信する。具体的には、一実施形態では、受信側ＤＮＳサーバは、選択されたＰＯＰに対応する妥当性のあるＣＮＡＭＥを特定し、ＣＮＡＭＥをクライアントコンピューティングデバイス１０２に送信する。次いで、ブロック７１４において、異なるＤＮＳサーバ構成部分１１８、１２４、１３０は、ＣＮＡＭＥに対応するクライアントコンピューティングデバイス１０２からＤＮＳクエリを受信する。次いで、ルーチン７００は、決定ブロック７０８に戻り、適宜、反復し続ける。

ＤＮＳサーバが権限を有するどうかを判断するために、代替的な方法またはさらなる方法を実行してもよい。一実施形態では、受信側ＤＮＳサーバは、ＣＤＮサービスプロバイダ１０６の地域に基づいて要求ルーティング処理の様々な代替形態を定義する１つまたは複数のＣＮＡＭＥを維持することができる。実施形態では、取得されたロケーションベース識別子に関連付けられたＰＯＰをブロック７０６において決定する代わりに、受信側ＤＮＳサーバは、図８を参照して同様に後述するように、ブロック８０６において、クライアントコンピューティングデバイスの得られたロケーションに関連付けられた宛先識別子を決定することができる。この代替実施形態におけるＤＮＳサーバは次いで、決定された宛先識別子のみに基づいて、または、他の要求ルーティング基準と組み合わせて、代替ＰＯＰの妥当性のあるＣＮＡＭＥを選択できる。

次に、ブロック７１６において、ＣＤＮサービスプロバイダ１０６は、コンテンツ要求の解決に関連するパフォーマンスデータを収集し、パフォーマンスデータを利用して、クライアントロケーション情報に関するルーティング情報に対して任意の更新を行わなければならないかどうかを決定する。上述のように、ＣＤＮサービスプロバイダ１０６は、上記のプロセス中の任意の時間に、またはコンテンツ要求の解決後に、パフォーマンスデータを収集することができる。次いで、ＣＤＮサービスプロバイダ１０６は、ルーティングデータストア１３４に対して任意の更新を行わなければならないかどうかを決定するために、ブロック７１６において収集されたパフォーマンスデータを処理することができる。さらに以下で説明されるように、クライアントロケーション情報に関連するルーティング更新は、たとえば、クエリＩＰアドレスのロケーションベース識別子へのマッピング、ロケーションベース識別子の宛先識別子へのマッピング、ＰＯＰ配信割振り、フェールオーバーリストエントリ、配信割振りなどに対する更新を含む。

１つの例示的な実施形態では、ＣＤＮサービスプロバイダ１０６は、ルーティングデータストア１３４中のクエリＩＰアドレスのロケーションベース識別子へのマッピングに対して、任意の修正を行わなければならないかどうかを決定するために、パフォーマンスデータを収集することができる。たとえば、特定のロケーションベース識別子に関連付けられた第１のリソース要求が、不良なルーティングパフォーマンスを生じ、同じロケーションからのさらに他のリソース要求が、良好なルーティングパフォーマンスを生じる場合、ＣＤＮサービスプロバイダは、第１のリソース要求に関連付けられたロケーションベース識別子が不正確であると決定することができる。この例では、ＣＤＮサービスプロバイダ１０６は、クエリＩＰアドレスにマッピングするための代替ロケーションを決定するために、要求側クライアントコンピューティングデバイスに関連付けられたクライアントプロファイルデータを利用することができる。たとえば、ＣＤＮサービスプロバイダ１０６は、クライアントのための代替的な請求アドレスまたは配達アドレスを決定するために、ルーティングデータストア１３４中のクライアントのユーザプロファイルデータを参照することができる。ＣＤＮサービスプロバイダ１０６は、クエリＩＰアドレスに関連付けられた新しいロケーションベース識別子を指定するために、この新たに決定されたロケーションを使用することができる。具体的には、一実施形態では、ＣＤＮサービスプロバイダ１０６は、ルーティングデータストア１３４に、クエリＩＰアドレスを新しいロケーションベース識別子にマッピングする、新しいエントリを追加することができる。代替的には、別の実施形態では、ＣＤＮサービスプロバイダ１０６は、新しいロケーションベース識別子を既存のロケーションベース識別子と置き換えることによって、クエリＩＰアドレスに関連付けられた、既存のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリを修正できる。特定の例示的な実施形態では、ＣＤＮサービスプロバイダ１０６は、パフォーマンスデータを使用して、２つ以上の、ロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリを新しい単一のマッピングエントリへと圧縮することを決定することができる。それに加えて、またはそれに替えて、ＣＤＮサービスプロバイダ１０６は、現在のマッピングエントリを２つ以上のマッピングエントリへと分離するために、パフォーマンスデータを使用できる。

別の実施形態では、特定のロケーションベース識別子に関連するすべてのリソース要求が不良ルーティングパフォーマンスを生じる場合、ＣＤＮサービスプロバイダ１０６はクエリＩＰアドレスのロケーションベース識別子へのマッピングが正確であるが、（図８を参照してブロック８０６において、さらに説明するような）関連付けられた宛先識別子、または関連付けられたＰＯＰ（もしくは対応するＣＮＡＭＥ）は修正を必要とすることを決定し得る。この例では、ＣＤＮサービスプロバイダは、ロケーションベース識別子の宛先識別子へのマッピング、あるいはロケーション識別子および／または宛先識別子に関連付けられた利用可能なＰＯＰ選択を修正し得る。

さらに別の例示的な実施形態では、（ブロック７０６、またはさらに以下で説明するブロック８０８などにおいて、）セット中の各ＰＯＰ（または対応するＣＮＡＭＥ）を選択する可能性は、複数の方法で最初に定義でき、受信側ＤＮＳサーバは、定義された可能性に基づいてＰＯＰ／ＣＮＡＭＥを選択する。たとえば、ＰＯＰのセットは、図８を参照してさらに後で説明するように、特定の宛先識別子に対応するものとして特定できる。セットからの特定のＰＯＰの選択は、配信割振りに基づくことができる。たとえば、ＣＤＮサービスプロバイダ１０６は、米国の西海岸地方に、シアトルＰＯＰ、サンフランシスコＰＯＰ、およびロサンゼルスＰＯＰなどの３つのＰＯＰを提供し得る。この例では、配信割振りは、シアトルＰＯＰが時間の６０％使用され、サンフランシスコＰＯＰとロサンゼルスＰＯＰとが各々、時間の２０％使用されるものとし得る。したがって、この例示的な実施形態において、ＤＮＳサーバは、選択の可能性が最も高いＰＯＰ／ＣＮＡＭＥを最も頻繁に選択するが、対応する可能性に基づいて、時折、選択の可能性がより低いＣＮＡＭＥを選択することがある。この場合、可能性は、対応するコンピューティングデバイスの予期されたパフォーマンスに対応する。ＣＤＮサービスプロバイダ１０６は、要求されたリソースをこれらのＰＯＰに配信するパフォーマンスを監視することができ、その後、可能性を更新することができる。さらなる実施形態では、可能性は、負荷制限または他のネットワークトラフィック緩和に対応することができる。さらに、他の実施形態では、特定の地域に設置されたＰＯＰのうちいくつかは、初期配信割振りから除外することができ、代わりに、フェールオーバーリスト中で特定し、最初に選択されたＰＯＰのうちの１つが利用不可能な場合、使用することができる。フェールオーバーリストはまた、リスト中のＰＯＰのセットに割り当てられた配信割振りを有することができ、パフォーマンスデータに基づいて更新することもできる。

次に図８を参照して、要求側クライアントコンピューティングデバイスのロケーションに関連付けられたＰＯＰを選択するための要求ルーティングサブルーチン８００の一実施形態について説明する。当業者には、ルーチン８００について概説される動作／ステップは、ＣＤＮサービスプロバイダ１０６に関連付けられた１つまたは複数のコンピューティングデバイス／構成部分によって実装できることが諒解されよう。したがって、ルーチン８００は、ＣＤＮサービスプロバイダ１０６により実行されるものとして論理的に関連付けられていた。

決定ブロック８０２において、この時点でＣＤＮサービスプロバイダ１０６の受信側ＤＮＳサーバが（図７のブロック７０４から）ロケーションベース識別子に関連付けられた確信度を取得しているが、確信度が最小しきい値を超えるかどうかを決定する判断が行われる。確信度が最小しきい値を超えない場合、ＤＮＳサーバは、ブロック８０４において、デフォルトのロケーションベース識別子を割り当てる。一実施形態では、デフォルトのロケーションベース識別子は、受信側ＤＮＳサーバのロケーションに対応し得る。ブロック８０２において、取得されたロケーションベース識別子に関連付けられた確信度が最小しきい値を超えた場合、またはブロック８０４において、デフォルトのロケーションベース識別子が割り当てられた後に、ブロック８０６において、受信側ＤＮＳサーバがＤＮＳクエリのための宛先識別子を決定する。

しかしながら、代替実施形態では、確信度を取得し、分析することに関する上記の機能を省くことができる。一実施形態では、この機能は代替的には、データストア１３４に提供されるクエリＩＰアドレスのロケーションベース識別子へのマッピングを、信頼度評価を既に考慮にいれるように、前処理ステップとして実装できる。たとえば、クエリＩＰアドレスのロケーションベース識別子へのマッピングを生成する前に、確信度が低いいかなるデータマッピングエントリも、データマッピングからフィルタ除去できる。次いで、ブロック８０６において、宛先識別子を決定するために、フィルタされたクエリＩＰアドレスのロケーションベース識別子へのマッピングをＣＤＮサービスプロバイダ１０６によって使用することができる。

図８のブロック８０６に戻ると、一実施形態では、受信側ＤＮＳサーバは、データストア１３４から手作業で生成されたテーブルに従って、宛先識別子を決定するが、宛先識別子はロケーションベース識別子に応じて決定される。ただし、受信側ＤＮＳサーバは、手動で開始された管理プロセスに従って、代替の宛先識別子を提供することもできる。初期宛先識別子の選択と手作業で開始された管理プロセスの一実施形態は以下の通りである。

例示的な実施形態では、受信側ＤＮＳサーバは、ベクトルマッピングおよびさらなるＣＤＮ管理者操作に基づいて、ロケーションベース識別子を宛先識別子にマッピングする手作業で生成されたテーブルを利用する。宛先識別子は、１つまたは複数のロケーションを含んでいる地域の定義（たとえば、ワシントン州、オレゴン州、およびカリフォルニア州を含んでいる西海岸宛先）に対応する。しかしながら、ＤＮＳサーバは、（ＤＮＳクエリ中に含まれるコンテンツプロバイダ識別子により取得されるような）コンテンツプロバイダが何であるかに応じて決定された、手作業で設定された例外プロセスに従って、デフォルト宛先識別子をオーバーライドするように構成できる。

一実施形態では、ＣＤＮの管理者は、特定のコンテンツプロバイダ識別子に対する宛先識別子の割振りをオーバーライドすることができる。たとえば、ＤＮＳサーバはコンテンツプロバイダ識別子を利用して、ＣＤＮサービスプロバイダ１０６とのコンテンツのプロバイダ契約が、マッピングテーブルにおける特定された宛先からコンテンツを提供することを認めていることを確実する。別の例として、（たとえば、異なる宛先にオフロードすることによって、単一の宛先を介して単一のウェブページに関するコンテンツ要求をサービスすることを回避するために）いくつかのＰＯＰのうち特定のコンテンツプロバイダのための着信リソース要求の少なくとも一部分を再分配するために、コンテンツプロバイダ識別子を、代替の宛先識別子に関連付けるように手作業で指定できる。

次に、ブロック８０８において、選択された宛先識別子に基づいて、受信側ＤＮＳサーバは、特定された宛先のために、リソース要求に対応してサービスを提供することができるように、ＣＤＮの管理者によって手作業で決定された１つまたは複数のＰＯＰのリストから１つのＰＯＰを選択する。２つ以上のＰＯＰがＰＯＰのリスト中で特定される場合、受信側ＤＮＳサーバは、対応する宛先のための特定された配信割振り（たとえば、ＰＯＰ Ａ（７５％）、ＰＯＰ Ｂ（２５％））に従って、特定のＰＯＰを選択できる。定義された配信割振りは、特定のロケーションベース識別子または宛先識別子に基づいて特定的に定義できる。そのような配信割振りは、上記で説明したように処理されたパフォーマンスデータに基づいて修正できる。

次いで、受信側ＤＮＳサーバは、決定ブロック８１０において、選択されたＰＯＰが利用可能であるかどうかを判定する。一実施形態では、ＤＮＳサーバは、着信リソース要求を処理するために選択されたＰＯＰの可用度を示すＰＯＰ健康情報を使用して、選択されたＰＯＰの可用度を評価する。選択されたＰＯＰが（ＰＯＰ健康情報を介して示されるように）利用可能である場合、受信側ＤＮＳサーバはブロック８０８からのＰＯＰ選択を維持する。それに応じて、プロセスは図７の決定ブロック７０８に戻り、受信側ＤＮＳサーバが権限を有しない場合、受信側ＤＮＳサーバは選択されたＰＯＰ（または識別されたＰＯＰのセットのうちの１つ）によってＤＮＳクエリの受信を生じるＣＮＡＭＥを戻す。しかしながら、選択されたＰＯＰが受信側ＤＮＳサーバの現在のＰＯＰに対応する（すなわち、受信側ＤＮＳサーバが権限を有する）場合、（さらなる要求ルーティング処理が実装されない限り）ＣＮＡＭＥを必ずしも提供する必要がないので、受信側ＤＮＳサーバはＰＯＰにおけるデフォルトのリソースキャッシュ構成部分のＩＰアドレスを戻すことによって、ＤＮＳクエリを解決する。

選択されたＰＯＰが（ＰＯＰ健康情報を介して示されるように）利用可能でない場合、受信側ＤＮＳサーバは、ＤＮＳクエリを処理するために、ブロック８１４において代替のＰＯＰを選択できる。一実施形態では、代替ＰＯＰは、ＣＤＮの管理者によって手作業で設定された代替ＰＯＰのフェールオーバーリストを介して選択できる。具体的には、受信側ＤＮＳサーバは、特定された配信に従って、フェールオーバーリストから特定の代替ＰＯＰを選択することができる。同様に上述したように、処理は次いで、図７の決定ブロック７０８に戻り、受信側ＤＮＳサーバが代替ＰＯＰに対して権限を有しない場合、受信側ＤＮＳサーバは、選択された代替ＰＯＰ（またはＰＯＰのセットのうちの１つ）によってＤＮＳクエリの受信を生じるＣＮＡＭＥを戻す。しかしながら、選択された代替ＰＯＰが受信側ＤＮＳサーバの現在のＰＯＰに対応する（すなわち、受信側ＤＮＳサーバが権限を有する）場合、（さらなる要求ルーティング処理が実装されない限り）ＣＮＡＭＥを必ずしも提供する必要がないので、受信側ＤＮＳサーバは代替ＰＯＰにおけるデフォルトのリソースキャッシュ構成部分のＩＰアドレスを戻すことによって、ＤＮＳクエリを解決する。

当業者には、本開示で説明する機能のすべてが、開示された構成部分および移動通信デバイスの１つまたは複数のプロセッサにより実行されるソフトウェアで実施できることが諒解されよう。ソフトウェアは、任意のタイプの不揮発性ストレージ中に永続的に記憶できる。

仮定的な言語、とりわけ、「ｃａｎ」、「ｃｏｕｌｄ」、「ｍｉｇｈｔ」、または「ｍａｙ」などは、別段に明記されていない限り、または使用される文脈から明らかでない限り、一般には、ある特定の実施形態がある特定の特徴、要素および／またはステップを含むが、他の実施形態はそれらを含まないことを表すことを意図するものである。したがって、そのような仮定的な言語は一般に、フィーチャ、要素および／またはステップがいかなる方法でも１つまたは複数の実施形態のために必要とされること、あるいは、１つまたは複数の実施形態が、ユーザ入力またはユーザプロンプトを用いて、またはそれらを用いずに、これらの特徴、要素および／またはステップが任意の特定の実施形態に含まれるか、または任意の特定の実施形態において実行されるべきかどうかを決定するための論理を必ず含むことを意図するものではない。

本明細書で説明した、および／または添付の各図に示した流れ図中の任意のプロセス説明、要素、またはブロックは、プロセス中の特定の論理関数またはステップを実現するための１つまたは複数の実行可能な命令を含むモジュール、セグメント、またはコードの一部分を潜在的に表すものであることを理解されたい。当業者には理解されるように、代替実装形態は、本明細書で説明した実施形態の範囲内に含まれ、関与する機能に応じて要素または関数を削除したり、実質的に同時にまたは逆の順番も含めて図示され説明された順番ではない順番で実行したりすることができる。さらに、上述したデータおよび／または構成部分は、コンピュータ可読媒体に記憶でき、ＣＤ−ＲＯＭ、ＤＶＤーＲＯＭ、またはネットワークインターフェースなどのコンピュータ実行可能構成部分を記憶する読取り可能なコンピュータと関連付けられたドライブ機構を使用して、コンピューティングデバイスのメモリにロードでき、さらに、構成部分および／またはデータを単一のデバイス中に含んでも、任意の方法で分散してもよいことが諒解されよう。したがって、汎用コンピューティングデバイスは、上述した様々なデータおよび／または構成部分の処理および／または実行とともに、本開示のプロセス、アルゴリズムおよび方法を実現するように構成ができる。

第１節 方法において、
第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスからＤＮＳクエリを取得し、そのＤＮＳクエリが、コンテンツプロバイダによって提供された元のリソース識別子に関連付けられた要求されたリソースに対応し、第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
第１のＤＮＳサーバにおいてそのＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
クエリＩＰアドレスに関連付けられたロケーションベース識別子と確信度とを取得することであって、確信度が、クエリＩＰアドレスの関連付けに対するロケーションベース識別子の精度に関連付けられた確信度に対応することと、
確信度がしきい値を超えるかどうかを判断することと、
確信度がしきい値を超える場合、
ＤＮＳクエリに関連付けられた宛先識別子を判断することと含み、その宛先識別子が、ロケーションベース識別子に基づいて判断され、
その宛先識別子に基づいて、コンテンツ配信ネットワークサービスプロバイダに関連付けられたネットワークポイントオブプレゼンスを選択することと、
選択されたネットワークポイントオブプレゼンスに基づいて、第１のＤＮＳサーバがそのＤＮＳクエリに対して権限を有するかどうかを判断することと、
第１のＤＮＳサーバが権限を有しない場合、
選択されたネットワークポイントオブプレゼンスに基づいて代替リソース識別子を取得し、その代替リソース識別子が、ＤＮＳクエリに選択されたネットワークポイントオブプレゼンスに対応するドメインを解決させるための情報を含むことと、
その代替リソース識別子をクライアントコンピューティングデバイスに送信することと、
第２のＤＮＳサーバでクライアントコンピューティングデバイスから後続のＤＮＳクエリを取得することであって、その後続のＤＮＳクエリが、コンテンツ配信ネットワークサービスプロバイダによって提供される代替リソース識別子に対応することと、
第２のＤＮＳサーバがその後続のＤＮＳクエリに対して権限を有するかどうかを判定することと、
第２のＤＮＳサーバが第２のＤＮＳクエリに対して権限を有する場合に、第２のＤＮＳサーバが第２のＤＮＳクエリと関連付けられたコンテンツを提供するためのキャッシュ構成要素を選択することと、
第２のＤＮＳサーバが権限を有すると判断された場合に、選択されたキャッシュ構成部品を特定する情報を送信することとを含む、方法。

第２節 確信度がしきい値を越えない場合に、第１のＤＮＳサーバに関連付けられたロケーションベース識別子を割り当てることをさらに含む、第１節に記載の方法。

第３節 宛先識別子が、ロケーションベース識別子に関連付けられたロケーションを含んでいる地域に対応する、第１節に記載の方法。

第４節 元のリソース識別子に基づいて、判断された宛先識別子をオーバーライドすることをさらに含み、元のリソース識別子が、代替宛先識別子に関連する情報を提供する、第１節に記載の方法。

第５節 ネットワークポイントオブプレゼンスを選択することが、判断された宛先識別子に関連付けられたリソース要求に対応してサービスを提供することができるネットワークポイントオブプレゼンスの組から１つのネットワークポイントオブプレゼンスを選択することを含む、第１節に記載の方法。

第６節 ネットワークポイントオブプレゼンスが、配信割り振りに基づいてネットワークポイントオブプレゼンスの組から選択される、第５節に記載の方法。

第７節 選択されたネットワークポイントオブプレゼンスに基づいて、第１のＤＮＳサーバがＤＮＳクエリに対して権限を有するかどうかを判定する前に、選択されたネットワークポイントオブプレゼンスが利用可能であるかどうかを判定することと、
選択されたネットワークポイントオブプレゼンスが利用可能である場合、選択されたネットワークポイントオブプレゼンスを維持することと、
選択されたネットワークポイントオブプレゼンスが利用可能でない場合、代替ネットワークポイントオブプレゼンスを選択することと
をさらに含む、第１節に記載の方法。

第８節 選択されたネットワークポイントオブプレゼンスの可用性が、選択されたネットワークポイントオブプレゼンスの可用性を示す健康情報に基づいて着信リソース要求を処理する、第７節に記載の方法。

第９節 代替ネットワークポイントオブプレゼンスを選択することが、代替ネットワークポイントオブプレゼンスのフェールオーバーリストから代替ネットワークポイントオブプレゼンスを選択することを含む、第７節に記載の方法。

第１０節 ネットワークポイントオブプレゼンスが、配信割り振りに基づいてフェールオーバーリストから選択される、第９節に記載の方法。

第１１節 第１のＤＮＳサーバが権限を有すると判定される場合、
元のリソース要求に関連付けられたコンテンツを提供するためにキャッシュ構成部分を選択することと、
選択されたキャッシュ構成部分を特定する情報を送信することと、
をさらに含む、第１節に記載の方法。

第１２節 コンテンツプロバイダがアイデンティティに基づいて、決定された宛先識別子をオーバーライドすることさらに含む、第１節に記載の方法。

第１３節 コンテンツ配信ネットワークサービスプロバイダとのコンテンツプロバイダのサブスクリプションが、宛先識別子に対応する宛先から提供されるコンテンツを提供しない場合に、決定された宛先識別子がオーバーライドされる、第１２節に記載の方法。

第１４節 コンテンツ配信ネットワークサービスプロバイダとのコンテンツプロバイダのサブスクリプションが、代替宛先識別子の使用を提供する場合に、決定された宛先識別子がオーバーライドされる、第１２節に記載の方法。

第１５節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられている、第１５節に記載の方法。

第１６節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられたＤＮＳ解決構成部分に関連付けられている、第１５節に記載の方法。

第１７節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた物理ロケーションに対応する、第１節に記載の方法。

第１８節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた論理ロケーションに対応する、第１節に記載の方法。

第１９節 ロケーションベース識別子が相対ロケーションに対応する、第１節に記載の方法。

第２０節 相対ロケーションが、既知のロケーションに対する相対ロケーションの関連付けることに基づいて推測される、第１９節に記載の方法。

第２１節 相対ロケーションが待ち時間情報に基づいて推測される、第２０節に記載の方法。

第２２節 方法において、
第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスからＤＮＳクエリを取得し、ＤＮＳクエリが、コンテンツプロバイダによって提供された元のリソース識別子に関連付けられた要求されたリソースに対応し、第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
第１のＤＮＳサーバにおいてＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
クエリＩＰアドレスに関連付けられたロケーションベース識別子と確信度とを取得することと、
ロケーションベース識別子に基づいて、コンテンツ配信ネットワークサービスプロバイダに関連付けられたネットワークポイントオブプレゼンスを選択することと、
選択されたネットワークポイントオブプレゼンスに基づいて、第１のＤＮＳサーバがＤＮＳクエリに対して権限を有するかどうかを判断することと、第１のＤＮＳサーバが権限を有しない場合、
選択されたネットワークポイントオブプレゼンスに基づいて代替リソース識別子を取得し、代替リソース識別子が、ＤＮＳクエリに選択されたネットワークポイントオブプレゼンスに対応するドメインを解決させるための情報を含むことと、
代替リソース識別子をクライアントコンピューティングデバイスに送信することとを含む、方法。

第２３節 ＤＮＳクエリに関連付けられた宛先識別子を決定することをさらに含み、ネットワークポイントオブプレゼンスを選択することがさらに、宛先識別子に基づく、第２２節に記載の方法。

第２４節 宛先識別子が、ロケーションベース識別子の機能として判断される、第２３節に記載の方法。

第２５節 宛先識別子が、ロケーションベース識別子に関連付けられたロケーションを含んでいる地域に対応する、第２４節に記載の方法。

第２６節 コンテンツプロバイダがアイデンティティに基づいて、判断された宛先識別子をオーバーライドすることさらに含む、第２３節に記載の方法。

第２７節 コンテンツプロバイダの前記アイデンティティが、元のリソース識別子に基づいて獲得される、第２６節に記載の方法。

第２８節 コンテンツ配信ネットワークサービスプロバイダを伴うコンテンツプロバイダの分配が、宛先から対応する宛先識別子へ提供されるコンテンツを提供しない場合、判断された宛先識別子をオーバーライドする、第２６節に記載の方法。

第２９節 コンテンツ配信ネットワークサービスプロバイダを伴うコンテンツプロバイダの分配が、代替宛先識別子の使用を提供する場合、判断された宛先識別子をオーバーライドする、第２６節に記載の方法。

第３０節 元のリソース識別子に基づいて、判断された宛先識別子をオーバーライドすることをさらに含み、元のリソース識別子が、代替宛先識別子に関連する情報を提供する、第２３節に記載の方法。

第３１節 宛先識別子が、コンテンツプロバイダがアイデンティティに基づいて判断される、第２３節に記載の方法。

第３２節 宛先識別子が、獲得されたロケーションベース識別子に基づいてさらに判断される、第３１節に記載の方法。

第３３節 ネットワークポイントオブプレゼンスを選択することが、判断された宛先識別子に関連付けられたリソース要求に対応してサービスを提供することができるネットワークポイントオブプレゼンスの組から１つのネットワークポイントオブプレゼンスを選択することを含む、第２３節に記載の方法。

第３４節 ネットワークポイントオブプレゼンスが、配信割振りに基づいてネットワークポイントオブプレゼンスの組から選択される、第３３節に記載の方法。

第３５節 選択されたネットワークポイントオブプレゼンスに基づいて、第１のＤＮＳサーバがＤＮＳクエリに対して権限を有するかどうかを判定する前に、選択されたネットワークポイントオブプレゼンスが利用可能であるかどうかを判定することと、
選択されたネットワークポイントオブプレゼンスが利用可能である場合、選択されたネットワークポイントオブプレゼンスを維持することと、
選択されたネットワークポイントオブプレゼンスが利用可能でない場合、代替ネットワークポイントオブプレゼンスを選択することさらに含む、第２２節に記載の方法。

第３６節 選択されたネットワークポイントオブプレゼンスの利用可能性が、着信リソース要求を処理するために、選択されたネットワークポイントオブプレゼンスの利用可能性の健康情報の表示に基づく、第３５節に記載の方法。

第３７節 代替ネットワークポイントオブプレゼンスを選択することが、代替ネットワークポイントオブプレゼンスのフェールオーバーリストから代替ネットワークポイントオブプレゼンスを選択することを含む、第３５節に記載の方法。

第３８節 代替ネットワークポイントオブプレゼンスが、配信割振りに基づいてフェールオーバーリストから選択される、第３７節に記載の方法。

第３９節 第１のＤＮＳサーバが権限を有すると判定される場合、
元のリソース要求に関連付けられたコンテンツを提供するためにキャッシュ構成部分を選択することと、
選択されたキャッシュ構成部分を特定する情報を送信することとをさらに含む、第２２節に記載の方法。

第４０節 クエリＩＰアドレスへのロケーションベース識別子の精度に関連付けられた信頼度に対応する確信度を取得することをさらに含む、第２２節に記載の方法。

第４１節 確信度が閾値を超える場合、ネットワークポイントオブプレゼンスが、ロケーションベース識別子に基づいて選択される、第４０節に記載の方法。

第４２節 ロケーションベース識別子が、クエリＩＰアドレスを含むデータストアからロケーションベース識別子マッピングエントリへ獲得される、第２２節に記載の方法。

第４３節 クエリＩＰアドレスへのロケーションベース識別子の精度に関連付けられた信頼度に対応する、確信度の最小しきい値を超えた場合のみ、データストアが、クエリＩＰアドレスのロケーションベース識別子へのマッピングを含む、第４２節に記載の方法。

第４４節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられている、第２２節に記載の方法。

第４５節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられたＤＮＳレゾルバ構成部分に関連付けられている、第４４節に記載の方法。

第４６節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた物理ロケーションに対応する、第２２節に記載の方法。

第４７節 ロケーションベース識別子は、クライアントコンピューティングデバイスに関連した論理ロケーションに対応する、第２２節に記載の方法。

第４８節 ロケーションベース識別子は、相対ロケーションに対応する、第２２節に記載の方法。

第４９節 相対ロケーションは、既知のロケーションに対する相対ロケーションの関連付けに基づいて推測される、第４８節に記載の方法。

第５０節 相対ロケーションは、待ち時間情報に基づいて推測される、第４９節に記載の方法。

第５１節 要求ルーティングのためのシステムであって、
コンテンツ配信ネットワークサービスプロバイダに関連づけた第１のネットワークポイントオブプレゼンスであって、第１のネットワークポイントオブプレゼンスは、クライアントコンピューティングデバイスからＤＮＳクエリを受信するＤＮＳサーバコンポーネントを含み、ＤＮＳクエリは、第１のリソース識別子に関連づけた、要求されたリソースに対応し、第１のネットワークポイントオブプレゼンス内のＤＮＳサーバは、
第１のＤＮＳサーバにてＤＮＳクエリに関連づけたクエリＩＰアドレスを取得し、
クエリＩＰアドレスに関連づけたロケーションベース識別子を取得し、
ロケーションベース識別子に基づいてコンテンツ配信ネットワークサービスプロバイダに関連づけたネットワークポイントオブプレゼンスを選択し、
第１のＤＮＳサーバが、選択されたネットワークポイントオブプレゼンスに基づいてＤＮＳクエリに対して権限を有するか否かを判定し、
第１のＤＮＳサーバが権限を有しないのであれば、
選択されたネットワークポイントオブプレゼンスに基づいて代替リソース識別子を取得し、代替リソース識別子は、選択されたネットワークポイントオブプレゼンスに対応するドメインにＤＮＳクエリを解決させるための情報を含み、
クライアントコンピューティングデバイスに代替リソース識別子を伝送することに使用可能である第１のネットワークポイントオブプレゼンス
を含むシステム。

第５２節 第１のネットワークポイントオブプレゼンス内のＤＮＳサーバは、ＤＮＳクエリに関連づけた宛先識別子を決定することにさらに使用可能であり、ネットワークポイントオブプレゼンスを選択することは、さらに宛先識別子に基づく、第５１節に記載のシステム。

第５３節 宛先識別子は、ロケーションベース識別子の機能として決定される、第５２節に記載のシステム。

第５４節 第１のネットワークポイントオブプレゼンス内のＤＮＳサーバは、コンテンツプロバイダのアイデンティティに基づいて、決定された宛先識別子を無効にすることにさらに使用可能である、第５２節に記載のシステム。

第５５節 コンテンツプロバイダのアイデンティティは、オリジナルのリソース識別子に基づいて取得される、第５４節に記載のシステム。

第５６節 ネットワークポイントオブプレゼンスを選択することは、決定された宛先識別子に関連づけたリソース要求を提供することができるネットワークポイントオブプレゼンスの集合からネットワークポイントオブプレゼンスを選択することを含む、第５１節に記載のシステム。

第５７節 配信割振りに基づいてネットワークポイントオブプレゼンスの集合からネットワークポイントオブプレゼンスが選択される、第５６節に記載のシステム。

第５８節 第１のネットワークポイントオブプレゼンス内のＤＮＳサーバは、
第１のＤＮＳサーバが選択されたネットワークポイントオブプレゼンスに基づいてＤＮＳクエリに対して権限を有するか否かを判定することに先立って、選択されたネットワークポイントオブプレゼンスが使用可能であるか否かを判定し、
選択されたネットワークポイントオブプレゼンスが使用可能であれば、選択されたネットワークポイントオブプレゼンスを維持し、
選択されたネットワークポイントオブプレゼンスが使用可能でない場合は、代替ネットワークポイントオブプレゼンスを選択すること
にさらに使用可能である、第５１節に記載のシステム。

第５９節 選択されたネットワークポイントオブプレゼンスの使用可能性は、着信リソース要求を処理するために選択されたネットワークポイントオブプレゼンスの使用可能性を示す健康情報に基づく、第５８節に記載のシステム。

第６０節 代替ネットワークポイントオブプレゼンスを選択することは、代替ネットワークポイントオブプレゼンスのフェールオーバーリストから代替ネットワークポイントオブプレゼンスを選択することを含む、第５８節に記載のシステム。

第６１節 代替ネットワークポイントオブプレゼンスは、配信割振りに基づいてフェールオーバーリストから選択される、第６０節に記載のシステム。

第６２節 コンテンツ配信ネットワークサービスプロバイダに関連づけた第２のネットワークポイントオブプレゼンスであって、第２のネットワークポイントオブプレゼンスは、クライアントコンピューティングデバイスから後続のＤＮＳクエリを受信するＤＮＳサーバコンポーネントを含み、後続のＤＮＳクエリは、代替リソース識別子に関連づけた、要求されたリソースに対応し、第２のネットワークポイントオブプレゼンス内のＤＮＳサーバは、
オリジナルのリソース要求に関連づけたコンテンツを提供するためのキャッシュコンポーネントを識別するために後続のＤＮＳクエリを解決し、
クライアントコンピューティングデバイスに対して識別されたキャッシュコンポーネントを識別する情報を送信することに使用可能である第２のネットワークポイントオブプレゼンス
をさらに含む、第５１節に記載のシステム。

第６３節 第１のＤＮＳサーバにてクライアントコンピューティングデバイスからＤＮＳクエリを取得するステップであって、ＤＮＳクエリは、コンテンツプロバイダによって提供されるオリジナルのリソース識別子に関連づけた、要求されたリソースに対応し、第１のＤＮＳサーバは、コンテンツ配信ネットワークサービスに対応するステップと、
第１のＤＮＳサーバにてＤＮＳクエリに関連づけたクエリＩＰアドレスを取得するステップと、
クエリＩＰアドレスに関連づけたロケーションベース識別子を取得するステップと、
取得されたロケーションベース識別子に基づいて宛先識別子を取得するステップと、
第１のＤＮＳサーバが宛先識別子に基づいてＤＮＳクエリに対して権限を有するか否かを判定するステップと、
第１のＤＮＳサーバが権限を有しないのであれば、
選択されたネットワークポイントオブプレゼンスに基づいて代替リソース識別子を取得するステップであって、代替リソース識別子は、選択されたネットワークポイントオブプレゼンスに対応するドメインにＤＮＳクエリを解決させるための情報を含むステップと、
クライアントコンピューティングデバイスに対して代替リソース識別子を送信するステップと
を含む方法。

第６４節 要求ルーティングのための方法であって、
第１のＤＮＳサーバでクライアントコンピューティングデバイスからＤＮＳクエリを取得するステップであって、ＤＮＳクエリは、リソース識別子に関連づけた、要求されたリソースに対応し、第１のＤＮＳサーバは、コンテンツ配信ネットワークサービスプロバイダに対応するステップと、
第１のリソース識別子がクライアントコンピューティングデバイスに関連づけたロケーション情報に基づいて代替リソース識別子を関連づけられていることを判定するステップであって、ロケーション情報は、既知のロケーションに対する少なくとも部分的なＩＰアドレスのマッピングに対応する情報から取得されるステップと、
クライアントコンピューティングデバイスに代替リソース識別子を送信するステップであって、代替リソース識別子は、第１のリソース識別子に含まれないコンテンツ配信サービスプロバイダと追加の要求ルーティング情報とに対応するドメインにＤＮＳクエリを解決させるための情報を含むステップと、
第２のＤＮＳサーバにてクライアントコンピューティングデバイスからの後続のＤＮＳクエリを取得するステップであって、後続のＤＮＳクエリは、コンテンツ配信ネットワークサービスプロバイダによって提供される代替リソース識別子に対応し、第２のＤＮＳサーバは、コンテンツ配信ネットワークサービスプロバイダに対応するステップと、
第２のＤＮＳサーバにて、オリジナルのリソース要求に関連づけたコンテンツを提供するためのキャッシュコンポーネントを識別するために後続のＤＮＳクエリを解決するステップと、
クライアントコンピューティングデバイスに対して識別されたキャッシュコンポーネントを識別する情報を送信するステップと
を含む方法。

第６５節 コンピュータで実行される方法であって、
第１のＤＮＳサーバにてクライアントコンピューティングデバイスからの第１のＤＮＳクエリを取得するステップであって、第１のＤＮＳクエリは、第１の要求されたリソースに対応し、第１のＤＮＳサーバは、コンテンツ配信ネットワークサービスに対応するステップと、
第１のＤＮＳサーバにて第１のＤＮＳクエリに関連づけたクエリＩＰアドレスを取得するステップと、
ルーティングデータストアからのクエリＩＰアドレスに対応する少なくとも部分的なＩＰアドレスに関連づけたロケーションベース識別子を取得するステップであって、ルーティングデータストアは、ロケーションベース識別子マッピングに対する少なくとも部分的なＩＰアドレスを含むステップと、
ロケーションベース識別子に基づいて第１のＤＮＳクエリを解決するステップと、
第１の要求されたリソースを送信することに関連づけたパフォーマンスデータを収集するステップと、
クエリＩＰアドレスに関連づけた更新されたロケーションベース識別子を備えたパフォーマンスデータに基づいてルーティングデータストアを変更するステップと、
第２のＤＮＳサーバにてクライアントコンピューティングデバイスから第２のＤＮＳクエリを取得するステップであって、第２のＤＮＳクエリは、第２の要求されたリソースに対応するステップと、
クライアントコンピューティングデバイスのクエリＩＰアドレスに関連づけた更新されたロケーションベース識別子に基づいて第２のＤＮＳクエリを解決するステップと
を含む方法。

第６６節 更新されたロケーションベース識別子は、クライアントコンピューティングデバイスに関連づけたユーザプロフィール情報に基づいて判定される、第６５節に記載の方法。

第６７節 更新されたロケーションベース識別子は、クライアントコンピューティングデバイスに関連づけた代替請求アドレスに対応する、第６６節に記載の方法。

第６８節 更新されるロケーションベース識別子は、クライアントコンピューティングデバイスに関連づけた配達アドレスに対応する、第６６節に記載の方法。

第６９節 ルーティングデータストアを変更するステップは、更新されたロケーションベース識別子に対してクエリＩＰアドレスをマップするルーティングデータストアに新たなエントリを追加するステップを含む、第６５節に記載の方法。

第７０節 ルーティングデータストアを修正することが、更新されたロケーションベース識別子を用いて、既存のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリに修正することを含む、第６５節に記載の方法。

第７１節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられている、第６５節に記載の方法。

第７２節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられたＤＮＳ解決構成部分に関連付けられている、第７１節に記載の方法。

第７３節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた物理ロケーションに対応する、第６５節に記載の方法。

第７４節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた論理ロケーションに対応する、第６５節に記載の方法。

第７５節 ロケーションベース識別子が、相対ロケーションに対応する、第６５節に記載の方法。

第７６節 相対ロケーションが、既知のロケーションへの相対ロケーションの関連付けに基づいて推測される、第７５節に記載の方法。

第７７節 相対ロケーションが、待ち時間情報に基づいて推測される、第７６節に記載の方法。

第７８節 コンピュータで実行された方法において、
第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスから第１のＤＮＳクエリを取得し、第１のＤＮＳクエリが、第１の要求されたリソースに対応し、第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
第１のＤＮＳサーバにおいて第１のＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
クエリＩＰアドレスに対応する少なくとも部分的なＩＰアドレスに関連付けられたロケーションベース識別子を、ルーティングデータストアから取得することと、
ロケーションベース識別子に基づいて、第１のＤＮＳクエリを解決することと、
第１の要求されたリソースの送信に関連するパフォーマンスデータを収集することと、
パフォーマンスデータに基づいて、クライアントコンピューティングデバイスのクエリＩＰアドレスに関連付けられたルーティングデータストア中のルーティング情報を更新することと、
第２のＤＮＳサーバにおいてクライアントコンピューティングデバイスから第２のＤＮＳクエリを取得し、第２のＤＮＳクエリが、第２の要求されたリソースに対応することと、
クライアントコンピューティングデバイスのクエリＩＰアドレスに関連付けられた更新されたルーティング情報に基づいて、第２のＤＮＳクエリを解決することとを含む、方法。

第７９節 ルーティングデータストアが、少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングを含む、第７８節に記載の方法。

第８０節 ルーティング情報を更新することが、クエリＩＰアドレスに関連付けられた更新されたロケーションベース識別子での、パフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第７９節に記載の方法。

第８１節 ルーティングデータストアを修正することが、クエリＩＰアドレスを更新されたロケーションベース識別子にマッピングする新しいエントリをルーティングデータストアに追加することを含む、第８０節に記載の方法。

第８２節 ルーティングデータストアを修正することが、更新されたロケーションベース識別子を用いて、既存のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリを修正することを含む、第８０節に記載の方法。

第８３節 ルーティング情報を更新することが、パフォーマンスデータに基づいて、２つ以上のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリを、単一のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのデータエントリへと圧縮することを含む、第７８節に記載の方法。

第８４節 少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングが各々、対応する確信度を有する、第７９節に記載の方法。

第８５節 ルーティング情報を更新することが、クライアントコンピューティングデバイスのクエリＩＰアドレスに関連付けられた少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングに対応する確信度を更新することによって、パフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第８４節に記載の方法。

第８６節 ルーティングデータストアが、ロケーションベース識別子の宛先識別子へのマッピングをさら含む、第７９節に記載の方法。

第８７節 ルーティング情報を修正することが、クエリＩＰアドレスに関連付けられたロケーションベース識別子に対応する更新された宛先識別子でのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第８６節に記載の方法。

第８８節 ルーティングデータストアが、ロケーションベース識別子および宛先識別子のうちの少なくとも１つに対するネットワークポイントオブプレゼンスマッピングをさらに含む、第８６節に記載の方法。

第８９節 ルーティング情報を修正することが、更新されたネットワークポイントオブプレゼンスマッピングでのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第８８節に記載の方法。

第９０節 ネットワークポイントオブプレゼンスマッピングが配信割振りを含む、第８８節に記載の方法。

第９１節 ルーティング情報を修正することが、更新された配信割り振りでのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第９０節に記載の方法。

第９２節 ルーティングデータストが、各ネットワークポイントオブプレゼンスマッピングのためのフェールオーバーリストをさらに含み、ネットワークポイントオブプレゼンスマッピング中で特定されたネットワークポイントオブプレゼンスが利用不可能である場合、フェールオーバーリストが、クエリＩＰアドレスに関連付けられたＤＮＳクエリを解決するために、１つまたは複数の代替ネットワークポイントオブプレゼンスを特定する、第８８節に記載の方法。

第９３節 ルーティング情報を修正することが、更新されたフェールオーバーでのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第９２節に記載の方法。

第９４節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられている、第７８節に記載の方法。

第９５節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられたＤＮＳ解決構成部分に関連付けられている、第９４節に記載の方法。

第９６節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた物理ロケーションに対応する、第７８節に記載の方法。

第９７節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた論理ロケーションに対応する、第７８節に記載の方法。

第９８節ロケーションベース識別子が、相対ロケーションに対応する、第７８節に記載の方法。

第９９節 相対ロケーションが、既知のロケーションへの相対ロケーションの関連付けに基づいて推測される、第９８節に記載の方法。

第１００節 相対ロケーションが、待ち時間情報に基づいて推測される、第９９節に記載の方法。

第１０１節 コンピュータシステムであって、
少なくとも部分的なクエリＩＰアドレスのロケーションベース識別子へのマッピングを含むルーティングデータストアと、
コンテンツ配信ネットワークサービスプロバイダに関連付けられた第１のネットワークポイントオブプレゼンスと備え、第１のネットワークポイントオブプレゼンスが、
第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスから第１のＤＮＳクエリを取得し、第１のＤＮＳクエリが、第１の要求されたリソースに対応し、第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
第１のＤＮＳサーバにおいて第１のＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
ルーティングデータストアから、クエリＩＰアドレスに対応する少なくとも部分的なＩＰアドレスに関連付けられたロケーションベース識別子を取得することと、
ロケーションベース識別子に基づいて、第１のＤＮＳクエリを解決することと、
第１の要求されたリソースの送信に関連するパフォーマンスデータを収集することと、
パフォーマンスデータに基づいて、クライアントコンピューティングデバイスのクエリＩＰアドレスに関連付けられたルーティングデータストア中のルーティング情報を更新することと、
第２のＤＮＳサーバにおいてクライアントコンピューティングデバイスから第２のＤＮＳクエリを取得し、第２のＤＮＳクエリが、第２の要求されたリソースに対応することと、
クライアントコンピューティングデバイスのクエリＩＰアドレスに関連付けられた更新されたルーティング情報に基づいて、第２のＤＮＳクエリを解決することとを行うように動作可能である、コンピュータシステム。

第１０２節 ルーティング情報を更新することが、クエリＩＰアドレスに関連付けられた更新されたロケーションベース識別子でのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第１０１節に記載のシステム。

第１０３節 ルーティングデータストアを修正することが、クエリＩＰアドレスを更新されたロケーションベース識別子にマッピングする新しいエントリをルーティングデータストアに追加することを含む、第１０２節に記載のシステム。

第１０４節 ルーティングデータストアを修正することが、更新されたロケーションベース識別子を用いて、既存のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリを修正することを含む、第１０２節に記載のシステム。

第１０５節 ルーティング情報を更新することが、パフォーマンスデータに基づいて、２つ以上のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのマッピングエントリを、単一のロケーションベース識別子の少なくとも部分的なＩＰアドレスへのデータエントリへと圧縮することを含む、第１０１節に記載のシステム。

第１０６節 ルーティングデータストア中の少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングが各々、対応する確信度を有する、第１０２節に記載の方法。

第１０７節 ルーティング情報を更新することが、クライアントコンピューティングデバイスのクエリＩＰアドレスに関連付けられた少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングに対応する確信度を更新することによって、パフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第１０６節に記載のシステム。

第１０８節 ルーティングデータストアが、ロケーションベース識別子の宛先識別子へのマッピングをさら含む、第１０２節に記載のシステム。

第１０９節 ルーティング情報を修正することが、クエリＩＰアドレスに関連付けられたロケーションベース識別子に対応する更新された宛先識別子でのパフォーマンスデータに基づいてルーティングデータストアを修正することを備える、第１０８節に記載のシステム。

第１１０節 ルーティングデータストアが、ロケーションベース識別子および宛先識別子のうちの少なくとも１つへのネットワークポイントオブプレゼンスマッピングをさらに含む、第１０８節に記載のシステム。

第１１１節 ルーティング情報を修正することが、更新されたネットワークポイントオブプレゼンスマッピングでのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第１１０節に記載のシステム。

第１１２節 ネットワークポイントオブプレゼンスマッピングが配信割振りを含む、第１１０節に記載のシステム。

第１１３節 ルーティング情報を修正することが、更新された配信割り振りでのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第１１２節に記載のシステム。

第１１４節 ルーティングデータストが、各ネットワークポイントオブプレゼンスマッピングのためのフェールオーバーリストをさらに含み、ネットワークポイントオブプレゼンスマッピング中で識別されたネットワークポイントオブプレゼンスが利用不可能である場合、フェールオーバーリストが、クエリＩＰアドレスに関連付けられたＤＮＳクエリを解決するために、１つまたは複数の代替ネットワークポイントオブプレゼンスを識別する、第１１０節に記載のシステム。

第１１５節 ルーティング情報を修正することが、更新されたフェールオーバーでのパフォーマンスデータに基づいてルーティングデータストアを修正することを含む、第１１４節に記載のシステム。

第１１６節 クエリＩＰアドレスが、クライアントコンピューティングデバイスに関連付けられている、第１０１節に記載のシステム。

第１１７節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられたＤＮＳ解決構成部分に対応する、第１１６節に記載のシステム。

第１１８節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた物理ロケーションに対応する、第１０１節に記載のシステム。

第１１９節 ロケーションベース識別子が、クライアントコンピューティングデバイスに関連付けられた論理ロケーションに対応する、第１０１節に記載のシステム。

第１２０節 ロケーションベース識別子が、相対ロケーションに対応する、第１０１節に記載のシステム。

第１２１節 相対ロケーションが、既知のロケーションに相対ロケーションへの関連付けに基づいて推測される、第１２０節に記載のシステム。

第１２２節 相対ロケーションが、待ち時間情報に基づいて推測される、第１２１節に記載のシステム。

上記の実施形態に多くの変更および修正を加えることができ、その要素は許容できる例に含まれるものと理解されるべきであることを強調されるべきである。すべてのそのような修正および変更は、本明細書における本開示の範囲内に含まれ、特許請求の範囲によって保護されることを意図する。

Claims (18)

1. 方法において、
   第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスからＤＮＳクエリを取得し、前記ＤＮＳクエリが、コンテンツプロバイダによって提供された元のリソース識別子に関連付けられた要求されたリソースに対応し、前記第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
   前記第１のＤＮＳサーバにおいて前記ＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
   クエリＩＰアドレスに関連付けられたロケーションベース識別子を取得することと、
   前記ロケーションベース識別子に基づいて、前記コンテンツ配信ネットワークサービスプロバイダに関連付けられたネットワークポイントオブプレゼンスを選択することと、
   前記選択されたネットワークポイントオブプレゼンスに基づいて、前記第１のＤＮＳサーバが前記ＤＮＳクエリに対して権限を有するかどうかを判断することと、
   前記第１のＤＮＳサーバが権限を有しない場合、
   前記選択されたネットワークポイントオブプレゼンスに基づいて代替リソース識別子を取得し、前記代替リソース識別子が、ＤＮＳクエリに前記選択されたネットワークポイントオブプレゼンスに対応するドメインを解決させるための情報を含むことと、
   前記代替リソース識別子を前記クライアントコンピューティングデバイスに送信することとを含む、方法。
2. 前記ＤＮＳクエリに関連付けられた宛先識別子を決定することをさらに含み、ネットワークポイントオブプレゼンスを選択することがさらに、前記宛先識別子に基づく、請求項１に記載の方法。
3. 前記宛先識別子が、前記ロケーションベース識別子に関連付けられたロケーションを含んでいる地域に対応する、請求項２に記載の方法。
4. 前記コンテンツプロバイダがアイデンティティに基づいて、前記決定された宛先識別子をオーバーライドすることさらに含む、請求項２に記載の方法。
5. 前記元のリソース識別子に基づいて、前記判断された宛先識別子をオーバーライドすることをさらに含み、前記元のリソース識別子が、代替宛先識別子に関連する情報を提供する、請求項２に記載の方法。
6. ネットワークポイントオブプレゼンスを選択することが、前記判断された宛先識別子に関連付けられたリソース要求に対応してサービスを提供することができるネットワークポイントオブプレゼンスの組から１つのネットワークポイントオブプレゼンスを選択することを含む、請求項２に記載の方法。
7. 前記選択されたネットワークポイントオブプレゼンスに基づいて、前記第１のＤＮＳサーバが前記ＤＮＳクエリに対して権限を有するかどうかを判定する前に、前記選択されたネットワークポイントオブプレゼンスが利用可能であるかどうかを判定することと、
   前記選択されたネットワークポイントオブプレゼンスが利用可能である場合、前記選択されたネットワークポイントオブプレゼンスを維持することと、
   選択されたネットワークポイントオブプレゼンスが利用可能でない場合、代替ネットワークポイントオブプレゼンスを選択することさらに含む、請求項１に記載の方法。
8. 前記第１のＤＮＳサーバが権限を有すると判定される場合、
   前記元のリソース要求に関連付けられたコンテンツを提供するためにキャッシュ構成部分を選択することと、
   前記選択されたキャッシュ構成部分を特定する情報を送信することとをさらに含む、請求項１に記載の方法。
9. 要求ルーティングのためのシステムにおいて、
   コンテンツ配信ネットワークサービスプロバイダに関連付けられた第１のネットワークポイントオブプレゼンスを備え、前記第１のネットワークポイントオブプレゼンスが、クライアントコンピューティングデバイスからＤＮＳクエリを受信するＤＮＳサーバ構成部分を含み、前記ＤＮＳクエリが、第１のリソース識別子に関連付けられた要求されたリソースに対応し、前記第１のネットワークポイントオブプレゼンス中の前記ＤＮＳサーバが、
   前記第１のＤＮＳサーバにおいて前記ＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
   前記クエリＩＰアドレスに関連付けられたロケーションベース識別子を取得することと、
   前記ロケーションベース識別子に基づいて、前記コンテンツ配信ネットワークサービスプロバイダに関連付けられたネットワークポイントオブプレゼンスを選択することと、
   前記選択されたネットワークポイントオブプレゼンスに基づいて、前記第１のＤＮＳサーバが前記ＤＮＳクエリに対して権限を有するかどうかを判定することと、
   前記第１のＤＮＳサーバが権限を有しない場合、
   前記選択されたネットワークポイントオブプレゼンスに基づいて代替リソース識別子を取得し、前記代替リソース識別子が、ＤＮＳクエリに前記選択されたネットワークポイントオブプレゼンスに対応するドメインを解決させるための情報を含むことと、
   前記代替リソース識別子を前記クライアントコンピューティングデバイスに送信することとを含む、システム。
10. 前記第１のネットワークポイントオブプレゼンス中の前記ＤＮＳサーバがさらに、前記ＤＮＳクエリに関連付けられた宛先識別子を判断するように動作可能であり、ネットワークポイントオブプレゼンスを選択することがさらに、前記宛先識別子に基づく、請求項９に記載のシステム。
11. 前記第１のネットワークポイントオブプレゼンス中の前記ＤＮＳサーバがさらに、
    前記選択されたネットワークポイントオブプレゼンスに基づいて、前記第１のＤＮＳサーバが前記ＤＮＳクエリに対して権限を有するかどうかを判定する前に、前記選択されたネットワークポイントオブプレゼンスが利用可能であるかどうかを判定することと、
    前記選択されたネットワークポイントオブプレゼンスが利用可能である場合、前記選択されたネットワークポイントオブプレゼンスを維持することと、
    前記選択されたネットワークポイントオブプレゼンスが利用可能でない場合、代替ネットワークポイントオブプレゼンスを選択することとを行うように動作可能である、請求項９に記載のシステム。
12. コンテンツ配信ネットワークサービスプロバイダに関連付けられた第２のネットワークポイントオブプレゼンスを備え、前記第２のネットワークポイントオブプレゼンスが、クライアントコンピューティングデバイスから後続のＤＮＳクエリを受信するＤＮＳサーバ構成部分を含み、前記後続のＤＮＳクエリが、前記代替リソース識別子に関連付けられた要求されたリソースに対応し、前記第２のネットワークポイントオブプレゼンス中の前記ＤＮＳサーバが、
    前記元のリソース要求に関連付けられたコンテンツを提供するためのキャッシュ構成部分を特定するために、前記後続のＤＮＳクエリを解決することと、
    前記特定されたキャッシュ構成部分を識別する情報を前記クライアントコンピューティングデバイスに送信することとを行うように動作可能である、請求項９に記載のシステム。
13. コンピュータ実装された方法において、
    第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスから第１のＤＮＳクエリを取得し、前記第１のＤＮＳクエリが、第１の要求されたリソースに対応し、前記第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
    前記第１のＤＮＳサーバにおいて前記第１のＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
    前記クエリＩＰアドレスに対応する少なくとも部分的なＩＰアドレスに関連付けられたロケーションベース識別子を、ルーティングデータストアから取得することと、
    前記ロケーションベース識別子に基づいて、前記第１のＤＮＳクエリを解決することと、
    前記第１の要求されたリソースの送信に関連するパフォーマンスデータを収集することと、
    前記パフォーマンスデータに基づいて、前記クライアントコンピューティングデバイスの前記クエリＩＰアドレスに関連付けられた前記ルーティングデータストア中のルーティング情報を更新することと、
    第２のＤＮＳサーバにおいて前記クライアントコンピューティングデバイスから第２のＤＮＳクエリを取得し、前記第２のＤＮＳクエリが、第２の要求されたリソースに対応することと、
    前記クライアントコンピューティングデバイスの前記クエリＩＰアドレスに関連付けられた前記更新されたロケーションベース識別子に基づいて、前記第２のＤＮＳクエリを解決することとを含む、方法。
14. 前記ルーティングデータストアが、少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングを含む、請求項１３に記載の方法。
15. コンピュータシステムであって、
    少なくとも部分的なクエリＩＰアドレスのロケーションベース識別子へのマッピングを含むルーティングデータストアと、
    コンテンツ配信ネットワークサービスプロバイダに関連付けられた第１のネットワークポイントオブプレゼンスと備え、前記第１のネットワークポイントオブプレゼンスが、
    第１のＤＮＳサーバにおいてクライアントコンピューティングデバイスから第１のＤＮＳクエリを取得し、前記第１のＤＮＳクエリが、第１の要求されたリソースに対応し、前記第１のＤＮＳサーバがコンテンツ配信ネットワークサービスに対応することと、
    前記第１のＤＮＳサーバにおいて前記第１のＤＮＳクエリに関連付けられたクエリＩＰアドレスを取得することと、
    前記ルーティングデータストアから、前記クエリＩＰアドレスに対応する少なくとも部分的なＩＰアドレスに関連付けられたロケーションベース識別子を取得することと、
    前記ロケーションベース識別子に基づいて、前記第１のＤＮＳクエリを解決することと、
    前記第１の要求されたリソースの送信に関連付けられたパフォーマンスデータを収集することと、
    前記パフォーマンスデータに基づいて、前記クライアントコンピューティングデバイスの前記クエリＩＰアドレスに関連付けられた前記ルーティングデータストア中のルーティング情報を更新することと、
    第２のＤＮＳサーバにおいて前記クライアントコンピューティングデバイスから第２のＤＮＳクエリを取得し、前記第２のＤＮＳクエリが、第２の要求されたリソースに対応することと、
    前記クライアントコンピューティングデバイスの前記クエリＩＰアドレスに関連付けられた前記更新されたルーティング情報に基づいて、前記第２のＤＮＳクエリを解決することとを行うように動作可能である、コンピュータシステム。
16. 前記ルーティング情報を更新することが、前記クエリＩＰアドレスに関連付けられた更新されたロケーションベース識別子での前記パフォーマンスデータに基づいて前記ルーティングデータストアを修正することを含む、請求項１５に記載のシステム。
17. 前記ルーティングデータストア中の前記少なくとも部分的なＩＰアドレスのロケーションベース識別子へのマッピングが各々、対応する確信度を有する、請求項１６に記載のシステム。
18. 前記ルーティングデータストアが、ロケーションベース識別子の宛先識別子へのマッピングをさら含む、請求項１６に記載のシステム。

Images