JP2017539029A - コンテンツ配信フレームワークにおけるキャッシング - Google Patents

Abstract

コンテンツ配信ネットワーク（ＣＤＮ）で動作可能な、コンピュータにより実施される方法は、キャッシングポリシーの遅延結合を使用し、上記ＣＤＮにおけるキャッシングノードにより、コンテンツについてのリクエストに応答して、上記コンテンツがローカルにキャッシュされたかどうかを判断する。上記コンテンツがローカルにキャッシュされたと判断された場合には、上記コンテンツに関連付けられている現在のキャッシュポリシーを判断し、次に、上記コンテンツに関連付けられている上記現在のキャッシュポリシーに基づいて、ローカルにキャッシュされた上記コンテンツを供給することが許容可能かどうかを判断し、上記判断に基づいて、ローカルにキャッシュされた上記コンテンツを供給することが許容可能ではない場合、上記コンテンツの新たなバージョンを取得し、次に、上記コンテンツの上記新たなバージョンを供給し、そうでなく、ローカルにキャッシュされた上記コンテンツを供給することが許容可能である場合、ローカルにキャッシュされた上記コンテンツを供給する。

Description

関連出願の相互参照 本特許協力条約（ＰＣＴ）特許出願は、２０１５年１２月１５日に出願された、"ＣＡＣＨＩＮＧ ＩＮ Ａ ＣＯＮＴＥＮＴ ＤＥＬＩＶＥＲＹ ＦＲＡＭＥＷＯＲＫ"と題する米国特許非仮出願第１４／５７０，５１２号の優先権を主張する。当該非仮出願は、その全体がここに参照により組み込まれる。

著作権の宣言 本特許文献は、著作権保護の対象となる資料を含む。著作権者は、本特許文献または米国特許商標局のファイルにおけるあらゆる関連資料の複製に対して異議を唱えるものではないが、そうでなければ、いかなる理由があろうとも全ての著作権を留保する。

参照による組み込み 以下の米国特許出願および米国特許出願公開は、ここに、全ての目的で、参照により本明細書に完全に組み込まれる。１． ２０１２年１２月１２日に出願された、"Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ"という発明の名称の米国特許出願公開第２０１３／０１５９４７２号明細書、２． ２０１２年１２月１２日に出願された、"Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ"という発明の名称の米国特許出願公開第２０１３−０１５９４７３号明細書、３． ２０１４年６月１７日に出願された、"Ｏｒｉｇｉｎ Ｓｅｒｖｅｒ‐Ｓｉｄｅ Ｃｈａｎｎｅｌ Ｉｎ Ａ Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｆｒａｍｅｗｏｒｋ"という発明の名称の米国特許出願公開第２０１４／０３４４３９９号明細書、および４． １９９８年２月１０日に出願された、"Ｏｐｔｉｍｉｚｅｄ Ｎｅｔｗｏｒｋ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｉｏｎ"という発明の名称の米国特許第６，１８５，５９８号明細書。

本発明は、コンテンツ配信およびコンテンツ配信ネットワークに関し、より具体的には、コンテンツ配信ネットワークにおけるキャッシングに関する。

本発明のその他の目的、特徴、および特性、並びに、関連する構造の要素の動作および機能に関する方法、製造の部分および経済性の組み合わせは、添付の図面を参照して以下の記載および添付の特許請求項を考慮することによって、より明らかになるであろう。これらの全てが、本明細書の一部分を形成する。

本明細書の例示的な実施形態に従った例示的なコンテンツ配信フレームワークの態様を示す。

本明細書の例示的な実施形態に従った例示的なコンテンツ配信ネットワーク（ＣＤＮ）の態様を示す。

本明細書の例示的な実施形態に従った処理の態様のフローチャートである。

本明細書の例示的な実施形態に従ったコンピューティングの態様を示す。

用語解説 そうでないように使用されない限り、本明細書において使用されるように、以下の用語または略語は、以下の意味を有する。

ＣＤは、コンテンツ配信を意味する。

ＣＤＮは、コンテンツ配信ネットワークを意味する。

ＨＴＴＰは、ハイパーテキストトランスファープロトコルを意味する。

ＨＴＴＰＳは、ＨＴＴＰセキュリティを意味する。

ＴＴＬは、生存時間を意味する。

ＵＲＩは、ユニフォームリソース識別子を意味する。

ＵＲＬは、ユニフォームリソースロケータを意味する。

背景および概要 コンテンツ配信ネットワーク（ＣＤＮ）は、１または複数のコンテンツプロバイダの代わりに、好ましくは公衆インターネットを介して、クライアントに効率的にコンテンツ（例えばリソース）を配信する。コンテンツプロバイダは、オリジンソース（オリジンサーバまたはオリジン）を介して、自身のコンテンツ（例えばリソース）を提供する。ＣＤＮは、反対方向に（クライアントからオリジンサーバに）コンテンツを効率的に送信するためのオーバー・ザ・トップ搬送メカニズムも提供し得る。エンドユーザ（クライアント）およびコンテンツプロバイダの両方が、ＣＤＮを使用することから恩恵を受ける。ＣＤＮを使用することで、コンテンツプロバイダは、自身のサーバ（例えば、自身のオリジンサーバ）から負担を取り除くこと（および、それにより、サーバにかかる負荷を低減すること）が可能である。クライアントは、より短い遅延でコンテンツを取得することが可能なことにより恩恵を受ける。

本明細書の例示的な実施形態に従った例示的なコンテンツ配信フレームワーク１００を示す図１を参照すると、１または複数の加入者１０４に関連付けられているコンテンツ１０２は、１または複数のＣＤＮ１０８を介して、クライアント１０６に配信され得る。ＣＤＮ１０８は、あらゆる種類のＣＤＮであり得、サブＣＤＮ、デリゲートＣＤＮ、部分的ＣＤＮ等を含み得る。例示的なＣＤＮは、両方とも２０１２年１２月１２に出願された米国特許出願公開第２０１３／０１５９４７２号明細書および第２０１３／０１５９４７３号明細書、ならびに２０１４年６月１７日に出願された米国特許出願公開第２０１４／０３４４３９９号明細書、および１９９８年２月１０日に出願された米国特許第６，１８５，５９８号明細書において説明されている。これらのそれぞれの全内容は、全ての目的で、参照により本明細書に完全に組み込まれている。図２は、本明細書の例示的な実施形態に従った例示的なＣＤＮ１０８の態様を示す。

本明細書において使用されるように、クライアントは、例えばエンドユーザがシステム内でリクエスト（例えば、ＤＮＳリクエストおよびＨＴＴＰリクエスト）を出すべく使用するエージェント（例えば、ブラウザ、セットトップボックス、または他のアプリケーション）である。ＣＤＮまたは他の中継手段が使用されない場合、そのようなリクエストは、加入者自身のサーバ（例えば、加入者のオリジンサーバ）またはインターネット上の他のコンポーネントに直接向かい得る。コンテンツプロバイダが（例えば、米国特許出願公開第２０１３／０１５９４７２号明細書および第２０１３／０１５９４７３号明細書において説明されるように）ＣＤサービスに加入している場合、エンドユーザのリクエストを、ともすると途中でコンテンツを変換およびキャッシングして、オリジンリクエストにマッピングし得る中間ＣＤサービスに様々なリクエストが向かい得る。

それぞれの別個のオリジン（例えばオリジンサーバ）は通常、一加入者に関連付けられているが、加入者は、加入者が所有しＣＤＮが提供するオリジンを含む、任意の数のオリジンに関連付けられ得る。

ＣＤＮがインタラクトし得る物理オリジンは、実際には、一連の中継手段からコンテンツ（おそらく例えば、加入者の実際のオリジンサーバで最終的に終わる違うコンテンツ取得システムの要素）を取得する中継手段であり得る。しかしながら、ＣＤＮの内部構成要素が関係している限り、オリジンは、コンテンツが直接取得されるシステム上の境界の外にあるサービスである。

本明細書において使用されるように、エンドユーザは、サービスプロバイダエンティティにより提供されるいくつかのインターネットサービス（例えば、ウェブサイト、ストリーミングサービス等）を最終的に消費するエンティティ（例えば、人または組織）である。このプロバイダエンティティは、場合によっては、本説明において加入者と称される。なぜなら、プロバイダエンティティは、自身のコンテンツを（例えば自身のオリジンから自身の消費者へ）効率的に配信するためにＣＤＮサービスに加入しているからである。ＣＤＮは、自身の加入者と加入者のエンドユーザとの間に付加価値のある媒介（例えば、キャッシング、変形等）を提供し得る。

キャッシング コンテンツ（例えばリソース）は、ＣＤＮ内のみならず、当該コンテンツが供給されているクライアントを含む他のエンティティによってもキャッシュされ得る。理解されるべきであるように、クライアントは、ＣＤＮ内のエンティティでもあり得る。いくつかの場合において、コンテンツは、ＣＤＮの内部および外部の両方で、中継手段によりキャッシュされ得る。再び図１のコンテンツ配信フレームワーク１００を参照すると、少なくともいくつかのコンテンツ１０２は、ＣＤＮ１０８（例えばＣＤＮキャッシュまたはキャッシュサービス１１０）内でキャッシュされ得る。

キャッシュされ、かつキャッシュ可能なコンテンツは通常、当該コンテンツに関連付けられたキャッシングポリシーを有する。そのようなコンテンツを処理するエンティティは、それらのキャッシングポリシーに従うであろうことが一般に予想される。ここで特定の関心の対象となるキャッシングポリシーは、コンテンツの期限切れに関連するポリシーを含む。古いコンテンツもしくは期限切れのコンテンツを供給すること、またはコンテンツを当該コンテンツに関連付けられているキャッシングポリシーとは整合性がないやり方で供給することは一般に望ましくないことが理解されよう。

キャッシングポリシーは、コンテンツと関連付けられているキャッシュディレクティブとして指定され得る。キャッシュディレクティブは、例えばリソースのタイプに依存し得る。例えば、ＨＴＴＰリソース（ＨＴＴＰＳリソースを含む）は、その全内容が全ての目的でここに参照により本明細書に完全に組み込まれているＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ） ７２３４, "Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ／１．１）：Ｃａｃｈｉｎｇ"において説明されているもののような従来のＨＴＴＰキャッシングディレクティブを使用するのが好ましい。知られているように、ＨＴＴＰリソースの場合、キャッシュディレクティブは、リソースに関連付けられているヘッダを介して提供され得る。キャッシュディレクティブがリソースに提供されなかった場合には、エンティティ（例えばキャッシュノード）は、当該タイプの、または当該プロバイダからのリソースについて、デフォルトキャッシングポリシーを使用し得る。エンティティは、デフォルトキャッシングポリシーを別のソースから判断し得る。一般に、コンテンツ（例えば、１つのリソース、またはリソースのセット）に関連付けられているキャッシュディレクティブ（またはキャッシングポリシー）は、（例えば、ＨＴＴＰリソースの場合には、ヘッダとして）当該コンテンツが提供され得、および／または当該コンテンツとは別個の位置もしくはエンティティ（例えばデータベース等）から入手可能であり得る。

ＣＤＮは、自身の加入者の代わりにコンテンツをキャッシュし得うる。ＣＤＮは、例えばＣＤＮノード内で、当該ＣＤＮが自身の加入者の代わりにキャッシュするコンテンツのキャッシュ期限切れポリシーの指定を可能にすることが好ましい。ＣＤＮは、コンテンツ（例えば、１つのリソース、もしくはリソースのセット）についての内部キャッシングポリシーを有し得、またはサポートし得る。これは、当該内部キャッシングポリシーが、ＣＤＮのキャッシュが順守するポリシーであって、同一のコンテンツについての外部キャッシングポリシーとは違う、ともすると別個のもの（例えば、クライアントに配信される時にコンテンツと共に送られるキャッシングポリシー）である場合である。

いくつかの実施形態において、ＣＤＮは、加入者、またはリソースについての内部キャッシングポリシーを設定またはオーバーライドしている他のユーザもしくはエンティティをサポートし得る。例えば、そのようなシステムにおいて、ＣＤＮの顧客／加入者は、（例えばアプリケーションプログラム（プログラミング）インタフェース（ＡＰＩ）を介して）セルフサービスポータル等にアクセスし得、自身のコンテンツのいくつかまたは全てについてのオリジンサーバからキャッシングポリシーをオーバーライドし得る。例えば、特定のＣＤＮ加入者は、ポータルを使用して、特定の種類の自身のコンテンツ（例えば自身のＰＤＦファイル等）についてのキャッシングポリシーを設定し得る。これにより、例えば、それらのファイルは、特定の期間（例えば、１週間、１時間等）キャッシュされる。

キャッシュされたコンテンツ（例えばリソース）を、当該コンテンツについてのキャッシングポリシーが設定される毎に無効化を試すよりむしろ、本明細書において説明されるように、ＣＤＮの内部リクエスト処理プロセスにより、フィル時よりむしろリクエスト時に、リクエストされたコンテンツのキャッシングポリシーが判断され得る。実際には、リクエスト処理は、キャッシングポリシーの遅延結合を使用することにより、無効化（ともすると高価な処理）を強制する必要なく最新の内部キャッシングポリシーが使用されることを保証する。

外部キャッシングに使用されるものと類似するキャッシュディレクティブは、内部キャッシュポリシーに使用され得る。しかしながら、内部キャッシュポリシーディレクティブを外部キャッシュポリシーディレクティブと都合良く区別するため、ＣＤＮは、内部キャッシュポリシー用に異なる名称を使用し、および／またはこれらのポリシーを（例えば、内部で使用されるＨＴＴＰヘッダを介して）提供するであろうことが理解されるべきである。このやり方で、外部キャッシュポリシーが外部エンティティに提供され得るものの、内部キャッシュポリシーは、ＣＤＮエンティティ（例えばキャッシュ）が従い得る。

例えば、再び図１のコンテンツ配信フレームワーク１００を参照すると、加入者１０４からのコンテンツ１０２は、それに関連付けられている内部および／または外部キャッシュポリシー（例えばキャッシュディレクティブ）を有し得る。ＣＤＮ１０８によりクライアント１０６に提供されるコンテンツ１０２'は、外部キャッシュポリシー（例えばキャッシュディレクティブ）を含むことが好ましい。内部キャッシュポリシーは、クライアント１０６へのコンテンツ１０２'に提供され得る。なぜなら、これらのポリシーは、クライアントが認識しないであろう、または従わないであろうディレクティブを使用することが好ましいからである。特定のコンテンツに関連付けられているキャッシュポリシーは、当該コンテンツに（例えば、ＨＴＴＰリソースの場合、ＨＴＴＰヘッダとして）含まれ得るか、または他の箇所に配置され得る。コンテンツに関連付けられている特定のディレクティブが存在しない場合、ＣＤＮは、当該コンテンツにデフォルトキャッシングポリシーを適用し得る。

本明細書のいくつかの実施形態において、コンテンツ（例えば、１つのリソース、またはリソースのグループ）と関連付けられている（内部および外部）キャッシングポリシーは、データベース（場合によっては、本明細書においてルールベースと称される）に格納され得る。リソースについてのクライアントリクエストが処理されている場合、要求された（内部および外部）キャッシングポリシーを検索／取得するため、ルールベースがアクセスされ得る。再び図１を参照すると、キャッシュ１１０は、コンテンツに関連付けられている内部および／または外部キャッシングポリシーについての情報を取得するため、１または複数のデータベース１１２にアクセスし得る。

上述のように、いくつかの実施形態において、ＣＤＮは、加入者、または、例えばセルフサービスポータル等を介して（例えばＡＰＩを介して）リソースについての内部キャッシングポリシーを設定またはオーバーライドしている他のユーザもしくはエンティティをサポートし得る。例示的なポータル１１４が図１に示される。ポータル１１４により、加入者は、自身のコンテンツに（すなわち、ＣＤＮにより自身の代わりに供給されるコンテンツに）関連付けられているキャッシングポリシーにアクセスし得、および／または当該キャッシングポリシーを変更し得る。

故に、本明細書の例示的な実施形態に従って、コンテンツについてのリクエストがクライアントからのＣＤＮノードで受信されると、ノードは、当該コンテンツについてのキャッシング期限切れポリシーを判断するであろう（例えば、オーバーライドポリシーが存在するか、そうである場合それは何かである。そうでなければ、オリジンサーバにより提供されたポリシーが順守されるべきである）。コンテンツについてのキャッシングポリシーは、例えばルールベースへのアクセスにより、判断され得る。

次に、このポリシーは、例えば１または複数のキャッシュ制約として、キャッシングノード（キャッシュとも称される）に送られる。次に、キャッシュは、それらの制約を使用して、自身が保有しているコンテンツ（存在する場合）がリクエスティングクライアントに戻され得るかどうか、またはリフレッシュ／リロード等が必要かどうかを判断し得る。理解されるべきように、入手可能なリソースをノードが有していない場合には、ノードは、内部キャッシングポリシーに拘らずリソースを取得する必要があるが、その時点のキャッシングポリシーを順守し得る。

例えば、構成により「１時間」という内部キャッシングポリシーが指定されているときには、アプリケーションがリソースをリクエストしている場合、当該ポリシーはキャッシュに送られる。キャッシュがリソースを有している場合には、自身が有するリソースのオリジナルフィル時間（および現在の時間）を、指定されたポリシーと比較して、キャッシュされたリソースから自身が有するリソースが供給され得るかどうか、またはそれが最初に（もしくはともすると非同期的に）リフレッシュ／リロードされる必要があるかどうかを判断する。

リクエストされたリソースがキャッシュに無い場合において、指定されたポリシーによりそれが許容または要求されているときには、そのときにのみ、フィルが行われ、キャッシュに格納される（例えば、応答が未格納と示されているものの、キャッシングポリシーを指定する内部ポリシーが提供されていない場合には、応答を格納しない等）。

いかなる内部キャッシングポリシーもオーバーライドされていなければ、オリジンからの応答のキャッシングルールが依然として適用されるであろう（すなわち、リソースが未使用であり、制約がないと認識した場合、キャッシュはリソースを戻すであろう）。

リソースがクライアントに配信される場合、任意の外部ポリシーが適用されるであろう。これは、異なるクラスのクライアントが異なる制約を指定することを見込んでいる。例えば、いくつかの場合において、リソースについての内部リクエストは、リフレッシュの発生を常に防止するようなやり方でリソースをリクエストし得、または、リソースの期限切れをキャッシュがどうみなすかに拘らず、リフレッシュを同様に要求し得る。

図３は、本明細書の例示的な実施形態に従った処理の態様のフローチャートである。図３のフローチャートに示されるように、ＣＤＮにおけるキャッシュ（キャッシングノード）は（３０２で）、コンテンツ（Ｃ）についてのリクエストを受信する。リクエストは、任意のやり方で（例えば、ＣＤＮのランデブーシステムを介して）、キャッシングノードに到達済みである可能性がある。コンテンツＣは、１または複数のリソースであり得るか、１または複数のリソースを含み得る。リクエストは、それらのリソースを指定しているＵＲＩまたはＵＲＬの形式を取り得る。キャッシュは（３０４で）、リクエストされたコンテンツがローカルにキャッシュされたかどうかを判断する。Ｃのローカルにキャッシュされたコピーが入手可能ではないと（３０４で）判断された場合には、ノードは（３０６で）、好ましくはＣ'のキャッシングポリシーに沿って、コンテンツＣのコピーを取得する。ノードは、ＣＤＮにおける適切なフィル権限保有ノードからＣのコピーを取得し得る。フィル権限保有ノードはまた、そのキャッシュされたバージョン（存在する場合）が古くないことを確認するであろうことが理解されよう。言い換えると、遅延結合キャッシュポリシーの確認は、リクエストされたコンテンツのコピーを提供する全ての中間ノードにより、それらの中間ノードが当該コンテンツを外部クライアントまたは内部クライアントのどちらに提供していようと実行されることが好ましい。

一方、リクエストされたコンテンツのローカルにキャッシュされたコピーが存在すると（３０４で）判断された場合には、ノードは、（例えばデータベース１１２から）コンテンツＣに関連付けられている現在のキャッシュポリシーを（３１０で）取得する。次に、現在のキャッシュポリシーは、リクエストされたコンテンツの現在キャッシュされているバージョンをノードが供給し得るかどうかを判断すべく（３１２で）使用される。３１０で取得／判断された現在のキャッシュポリシーに基づいて、リクエストされたコンテンツＣのローカルにキャッシュされたバージョンを供給するのが不都合な場合には、ノードは、上記で説明されるように（３０６で）コンテンツＣの現在のバージョンを取得し、（３０８で）Ｃの現在のバージョンを供給する。一方、ノードがコンテンツＣの現在キャッシュされているバージョンを供給するのは許容可能であると（３１０で取得されたＣについての現在のキャッシュポリシーに少なくとも部分的に基づいて）（３１２で）判断された場合には、（３０８で）コンテンツＣの現在キャッシュされているバージョンが供給される。

ルールベースにおいて指定されるキャッシングポリシー、例えば、ＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）タイプおよび／またはステータスコードに基づいて指定されるポリシー（ネガティブキャッシングはこの特定の場合である）は、キャッシュに渡される制約を拡張することにより対処され得る。例えば、「キャッシュされたのが１時間以内であった場合、それがｔｅｘｔ／ＨＴＭＬでない限り、そのような場合には、それをキャッシュ不能またはｔｅｘｔ／＊とみなし、そのような場合には１日キャッシュ可能とみなすこと」のようにである。そのような制約には簡潔な構文が適用され、かつ、簡潔な構文が使用されるのが好適であろうことが理解されるべきである。

いくつかの場合において、ルールベースの制約セットは、シーケンス生成時にコンパイル可能であり得る。なぜなら、当該制約セットは通常、プロパティ全体に適用されるからである。しかしながら、追加のフィルタについての規定が必要であろう（セットは、限定されるべきであり、リクエスト作成の間に容易に選択可能であるべきである）。ネガティブキャッシングは、制約セットに負のＴＴＬ値およびステータスコードのリストを含めることにより、同様に処理され得る。

理解されるであろうように、この手法の欠点は、あらゆるリクエストについてキャッシングポリシーの判断を行わなくてはならないことである。これは自由になる見込みがなく、比較的費用のかかるものになり得る。一方、比較的即時にポリシーの更新を行うことの恩恵は、大きくない可能性がある。なぜなら、ポリシーの更新はまれである可能性があるからである。当該コストを低減するべく、実装は、各リソースと共に構成バージョン番号を格納し得、構成が変更された場合にのみ、構成バージョン番号を再計算し得る。例えば、そのような手法では、現在の構成バージョン番号が付されたキャッシングエンジンにコールを出し、現在の構成バージョン番号とリソースと関連付けられている構成番号とをキャッシュに比較させるであろう。構成番号が同一である場合には、リソースに添付されたポリシー情報を使用し、そうでなければ、コールバックして、制約の現在の設定を取得する。この手法では、制約が変更されたと見受けられる場合に、効果的にルールベースを処理して制約を取得するのみということになる。いくつかの実装において、バージョン番号は、キャッシングポリシーのチェックサムまたはハッシュ等（並びにまたは代わりにシーケンス番号）であり得、またはそれらを含み得る。ハッシュは、ＭＤ５またはＳＨＡ等のような暗号ハッシュであり得る。このやり方で、引き続きなされていない変更は、前のバージョンに一致しているとみなされ得る。

そのようなシステムは、現在の制約をリクエストさせるいくつかのセンチネルシーケンス番号を入力することにより、奇数の制約（例えば、リフレッシュの発生を決して望まない、内部リクエストのタイプ）に対処するであろう。そのような手法をサポートするべく、キャッシュのインタフェースは、リクエストがシーケンス番号および／または制約のセットを送ることを許容されるであろうようであり得る。あらゆるリクエストについてルールベースがいずれにせよ処理される必要がある場合には、制約は、処理の間に集められ得、リクエスト時にキャッシュに送られ得る。シーケンス番号が変更になっていない場合、キャッシュから呼び出すよりむしろ、単に無視し得る。

コンピューティング 図４は、本明細書において説明された処理を実行するのに使用され得るプロキシ、親サーバまたは他のコンピューティングデバイスを実装したコンピューティングシステム４００の例示的な概略図である。コンピューティングシステムは、バス４０２（すなわち相互接続）、少なくとも１つのプロセッサ４０４、少なくとも１つの通信ポート４１４、メインメモリ４０６、リムーバブルストレージ媒体４１０、リードオンリーメモリ４０８、および大容量ストレージデバイス４１２を含む。プロセッサ４０４は、これに限定されるものではないが、インテル（登録商標）Ｉｔａｎｉｕｍ（登録商標）もしくはＩｔａｎｉｕｍ ２（登録商標）プロセッサ、ＡＭＤ（登録商標）Ｏｐｔｅｒｏｎ（登録商標）もしくはＡｔｈｌｏｎ ＭＰ（登録商標）プロセッサ、またはモトローラ（登録商標）の一連のプロセッサ、のような任意の既知のプロセッサであり得る。通信ポート４１４は、モデムベースのダイヤルアップ接続と共に使用するためのＲＳ‐２３２ポート、１０／１００イーサネット（登録商標）ポート、銅もしくはファイバを使用したギガビットポート、またはＵＳＢポートのいずれでもあり得る。通信ポート４１４は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはコンピュータシステムが接続する任意のネットワーク、のようなネットワークに応じて選択されてよい。サーバは、入出力（Ｉ／Ｏ）ポート４２０を介して周辺機器（例えば、ディスプレイスクリーン４１６、入力デバイス４１８）と通信し得る。

メインメモリ４０６は、ランダムアクセスメモリ（ＲＡＭ）または当技術分野において一般に知られている任意の他の動的ストレージデバイスであり得る。リードオンリーメモリ４０８は、プロセッサ４０４についての命令のような静的情報を格納するためのプログラマブルリードオンリーメモリ（ＰＲＯＭ）チップのような、任意の静的ストレージデバイスであり得る。大容量ストレージデバイス４１２は、情報および命令を格納するのに使用され得る。例えば、Ａｄａｐｔｅｃ（登録商標）の小型コンピュータシリアルインタフェース（ＳＣＳＩ）ドライブのファミリのようなハードディスク、光学ディスク、Ａｄａｐｔｅｃ（登録商標）のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）ドライブのファミリのようなＲＡＩＤのような一連のディスク、または任意の他の大容量ストレージデバイスが使用され得る。

バス４０２は、プロセッサ４０４を他のメモリ、ストレージおよび通信ブロックと通信可能に連結する。バス４０２は、使用されるストレージデバイスに応じて、ＰＣＩ／ＰＣＩ‐Ｘ、ＳＣＳＩもしくはユニバーサルシリアルバス（ＵＳＢ）ベースのシステムバス（またはその他）であり得る。リムーバブルストレージ媒体４１０は、あらゆる種類の外部ハードドライブ、フロッピー（登録商標）ドライブ、ＩＯＭＥＧＡ（登録商標）Ｚｉｐドライブ、コンパクトディスク―リードオンリーメモリ（ＣＤ‐ＲＯＭ）、コンパクトディスク―リライタブル（ＣＤ‐ＲＷ）、デジタルビデオディスク―リードオンリーメモリ（ＤＶＤ‐ＲＯＭ）等であり得る。

本明細書における実施形態は、コンピュータプログラムプロダクトとして提供され得る。コンピュータプログラムプロダクトは、プロセスを実行するようコンピュータ（または他の電子デバイス）をプログラムするのに使用され得る命令が格納された機械可読媒体を含み得る。機械可読媒体は、限定されるものではないが、フロッピー（登録商標）ディスク、光学ディスク、ＣＤ‐ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）、磁気カードもしくは光カード、フラッシュメモリ、または電子命令を格納するのに適した他のタイプの媒体／機械可読媒体を含み得る。

示されるように、メインメモリは、様々な図面および他の箇所に関して上記で説明された機能をサポートする１または複数のアプリケーション／サービス４２２で符号化され得る。例えば、一実施形態において、アプリケーション４２２は、本明細書に記載される様々な処理および／または命令を含み得、またはそうでなければ実行し得る。アプリケーション４２２（および／または本明細書において説明される他のリソース）は、本明細書において説明される異なる実施形態に従った処理機能をサポートするデータおよび／または論理命令のようなソフトウェアコード（例えば、メモリに、またはディスクのような別のコンピュータ可読媒体に格納されたコード）として具現化され得る。一実施形態の動作の間、プロセッサ４０４は、アプリケーション４２２の論理命令を起動するため、動作させるため、実行するため、解釈するため、またはそうでなければ行うために、バス４０２の使用を介してメインメモリ４０６にアクセスする。アプリケーション４２２の実行により、アプリケーションプロセス４２４において、処理機能が生成される。言い換えると、プロセス４２４は、コンピュータシステム４００のプロセッサ４０４内で、またはプロセッサ４０４上で動作しているアプリケーション４２２の１または複数の部分を表す。

上記説明は、本開示の技術を具現化する例示的なシステム、方法、技術、命令、シーケンスおよび／またはコンピュータプログラムプロダクトを含む。しかしながら、説明された開示はこれらの具体的詳細なく実施され得ることが理解されよう。本開示において、開示される方法は、デバイスにより読み取り可能な命令またはソフトウェアのセットとして実施され得る。さらに、開示される方法におけるステップの特定の順序または階層は例示的な手法の例であることが理解されよう。設計上の優先性に基づいて、方法におけるステップの特定の順序または階層は、再編成され得るものの、開示される主題内に留まることが理解されよう。添付の方法の請求項は、例としての順序での様々なステップの要素を示しており、示される特定の順序または階層に限定されることを必ずしも意味しない。

結論 特許請求の範囲を含め、本明細書において使用されるように、「少なくともいくつか」という表現は、「１または複数」を意味し、１つだけという場合を含む。故に、例えば、「少なくともいくつかのサービス」という表現は、「１または複数のサービス」を意味し、１つのサービスの場合を含む。

特許請求の範囲を含め、本明細書において使用されるように、「に基づいて」という表現は、「に部分的に基づいて」または「に少なくとも部分的に基づいて」を意味し、排他的なものではない。故に、例えば、「ファクタＸに基づいて」という表現は、「ファクタＸに部分的に基づいて」または「ファクタＸに少なくとも部分的に基づいて」を意味する。「のみ」という文言を用いて具体的に述べられていない限り、「Ｘに基づいて」という表現は、「Ｘのみに基づいて」を意味するものではない。

特許請求の範囲を含め、本明細書において使用されるように、「を使用して」という表現は、「を少なくとも使用して」を意味し、排他的なものではない。故に、例えば、「Ｘを使用して」という表現は、「少なくともＸを使用して」を意味する。「のみ」という文言を用いて具体的に述べられない限り、「Ｘを使用して」という表現は、「Ｘのみを使用して」を意味するものではない。

一般に、特許請求の範囲を含め、本明細書において使用されるように、「のみ」という文言が表現中で具体的に使用されない限り、その表現に解釈されるべきではない。

特許請求の範囲を含め、本明細書において使用されるように、「別個」という表現は、「少なくとも部分的に別個」を意味する。具体的に述べられない限り、別個は完全に別個を意味するものではない。故に、例えば、「ＸはＹとは別個である」という表現は、「Ｘは少なくとも部分的にＹとは別個である」を意味し、「ＸはＹとは完全に別個である」を意味するものではない。故に、特許請求の範囲を含め、本明細書において使用されるように、「ＸはＹとは別個である」という表現は、Ｘは少なくともいくつかの点でＹとは異なることを意味する。

特許請求の範囲を含め、本明細書において使用されるように、リストはアイテムを１つだけ含んでよく、そうでないと述べられない限り、多数のアイテムのリストが任意の特定のやり方で順序付けられる必要はない。リストは、複製のアイテムを含んでよい。例えば、本明細書において使用されるように、「ＣＤＮサービスのリスト」という表現は、１または複数のＣＤＮサービスを含んでよい。

説明および特許請求の範囲における「第１」および「第２」という文言は、区別または識別するために使用されるものであって、連続的または数的限定を示すものではないことが理解されるべきである。同様に、（「（ａ）」、「（ｂ）」等のような）文字または数的符号の使用は、区別および／または識別を助けるために使用されるものであって、いかなる連続的または数的限定もしくは順序も示すものではない。

具体的に示され、述べられない限り、いずれのフロー図においても、符号付けされたボックスのいずれによっても、順序は示唆されない。切り離された複数のボックスが図中に示されている場合、それらのボックスに関連付けられている動作は、完全に、または部分的に並列である場合を含め、任意の順序で実行されてよい。

現在のところ最も実際的かつ好ましいと思われる実施形態に関連して本発明を説明してきたものの、本発明は、開示される実施形態に限定されるべきでなく、それどころか、添付の特許請求の主旨および範囲内に含まれる様々な変更および同等の構成を網羅することが意図されているということが理解されるべきである。

Claims (16)

1. コンテンツ配信ネットワーク（ＣＤＮ）で動作可能な、コンピュータにより実施される方法であって、
   前記ＣＤＮにおけるノードにより、
   （Ａ）コンテンツについてのリクエストに応答して、前記コンテンツがローカルにキャッシュされたかどうかを判断する段階と、
   （Ｂ）前記コンテンツがローカルにキャッシュされたと判断された場合には、
   （Ｂ）（１）前記コンテンツに関連付けられている現在のキャッシュポリシーを判断し、次に、
   （Ｂ）（２）前記コンテンツに関連付けられている前記現在のキャッシュポリシーに基づいて、ローカルにキャッシュされた前記コンテンツを供給することが許容可能かどうかを判断し、
   （Ｂ）（３）（Ｂ）（２）での前記判断に基づいて、
   （ｉ）ローカルにキャッシュされた前記コンテンツを供給することが許容可能ではない場合、前記コンテンツの新たなバージョンを取得し、次に、前記コンテンツの前記新たなバージョンを供給し、
   （ｉｉ）ローカルにキャッシュされた前記コンテンツを供給することが許容可能である場合、ローカルにキャッシュされた前記コンテンツを供給する段階と
   を備える方法。
2. （Ｃ）前記コンテンツがローカルにキャッシュされなかったと判断された場合には、（Ｃ）（１）前記コンテンツを取得し、次に、（Ｃ）（２）（Ｃ）（１）において取得した前記コンテンツを供給する段階
   をさらに備える、請求項１に記載の方法。
3. 前記リクエストはＨＴＴＰリクエストを含み、前記コンテンツは１または複数のリソースを含む、請求項１または２に記載の方法。
4. 前記現在のキャッシュポリシーは、前記ノードとは別個の位置から判断される、請求項１から３のいずれか一項に記載の方法。
5. 前記位置はデータベースである、請求項４に記載の方法。
6. 前記キャッシュポリシーは、前記ＣＤＮ内でのコンテンツのキャッシングに関する、請求項１から５のいずれか一項に記載の方法。
7. 前記キャッシュポリシーは、前記ＣＤＮ外でのコンテンツのキャッシングにも関する、請求項６に記載の方法。
8. バージョン識別子はキャッシングポリシーに関連付けられ、（Ｂ）（１）において前記現在のキャッシュポリシーを判断する前記段階は、（ｉ）前記現在のキャッシュポリシーと関連付けられている第１バージョン識別子を、前記ＣＤＮにおける前記ノードでの前記コンテンツに関連付けられているキャッシュポリシーに関連付けられている第２バージョン識別子と比較し、（ｉｉ）前記第１バージョン識別子が前記第２バージョン識別子と同一である場合、前記ノードでの前記コンテンツと関連付けられている前記キャッシュポリシーを前記現在のキャッシュポリシーとして使用し、そうでなければ、前記ノードとは別個の位置から前記現在のキャッシュポリシーを取得する段階を有する、請求項１から７のいずれか一項に記載の方法。
9. コンテンツ配信サービス（ＣＤＮ）において動作可能なコンピュータに、
   （Ａ）コンテンツについてのリクエストに応答して、前記コンテンツがローカルにキャッシュされたかどうかを判断する段階と、
   （Ｂ）前記コンテンツがローカルにキャッシュされたと判断された場合には、
   （Ｂ）（１）前記コンテンツに関連付けられている現在のキャッシュポリシーを判断し、次に、
   （Ｂ）（２）前記コンテンツに関連付けられている前記現在のキャッシュポリシーに基づいて、ローカルにキャッシュされた前記コンテンツを供給することが許容可能かどうかを判断し、
   （Ｂ）（３）（Ｂ）（２）での前記判断に基づいて、
   （ｉ）ローカルにキャッシュされた前記コンテンツを供給することが許容可能ではない場合、前記コンテンツの新たなバージョンを取得し、次に、前記コンテンツの前記新たなバージョンを供給し、
   （ｉｉ）ローカルにキャッシュされた前記コンテンツを供給することが許容可能である場合、ローカルにキャッシュされた前記コンテンツを供給する段階と
   を実行させるためのプログラム。
10. （Ｃ）前記コンテンツがローカルにキャッシュされなかったと判断された場合には、（Ｃ１）前記コンテンツを取得し、次に、（Ｃ２）（Ｃ）（１）において取得した前記コンテンツを供給する段階を前記コンピュータにさらに実行させる、請求項９に記載のプログラム。
11. 前記リクエストはＨＴＴＰリクエストを含み、前記コンテンツは１または複数のリソースを含む、請求項９または１０に記載のプログラム。
12. 前記現在のキャッシュポリシーは、前記ＣＤＮにおけるノードとは別個の位置から判断される、請求項９から１１のいずれか一項に記載のプログラム。
13. 前記位置はデータベースである、請求項１２に記載のプログラム。
14. 前記キャッシュポリシーは、前記ＣＤＮ内でのコンテンツのキャッシングに関する、請求項９から１３のいずれか一項に記載のプログラム。
15. 前記キャッシュポリシーは、前記ＣＤＮ外でのコンテンツのキャッシングにも関する、請求項１４に記載のプログラム。
16. バージョン識別子はキャッシングポリシーに関連付けられ、（Ｂ）（１）において前記現在のキャッシュポリシーを判断する前記段階は、（ｉ）前記現在のキャッシュポリシーと関連付けられている第１バージョン識別子を、前記ＣＤＮにおけるノードでの前記コンテンツに関連付けられているキャッシュポリシーに関連付けられている第２バージョン識別子と比較し、（ｉｉ）前記第１バージョン識別子が前記第２バージョン識別子と同一である場合、前記ノードでの前記コンテンツと関連付けられている前記キャッシュポリシーを前記現在のキャッシュポリシーとして使用し、そうでなければ、前記ノードとは別個の位置から前記現在のキャッシュポリシーを取得する段階を有する、請求項９から１５のいずれか一項に記載のプログラム。