JP2017191600A - コンテンツ配信ネットワーク（ｃｄｎ）における無効化 - Google Patents

Abstract

【課題】無効なコンテンツ、または期限切れのコンテンツ、または古いコンテンツを供給される前にリフレッシュする。【解決手段】ＣＤＮにおけるコンテンツ配信（ＣＤ）サービスが、それぞれのプロパティに対し、１または複数のグループ無効化コマンドのリストを含むプロパティ無効化情報を、このＣＤサービスに保持する。結合された無効化コマンドを形成するために、１または複数の無効化コマンドを選択的に結合し、結合された無効化コマンドをこのリストに挿入することによって、新たなグループ無効化コマンドが追加される。結合することは、このリスト中の複数の要素の共通プレフィックスの長さに基づいている。それぞれのプロパティリストにおいて、プロパティ毎の共通プレフィックスリストが、無効化コマンドに対して保持される。【選択図】なし

Description

関連出願の相互参照
本特許出願は、２０１６年４月１１日に出願され、"Invalidation In A Content Delivery Network (CDN)"と題する、米国特許非仮出願第１５／０９５，２８２号からの優先権を主張し、その全内容が、全ての目的に対し、参照により本明細書に組み込まれる。
著作権の宣言

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

以下の米国特許は、これにより、全ての目的に対し、参照により本明細書に完全に組み込まれる。
１．２００７年１０月３１日に出願され、２０１１年１１月１５日に発行された、"Resource invalidation in a content delivery network"という発明の名称の米国特許第８，０６０，６１３号明細書。
２．２０１３年３月１５日に出願され、２０１４年９月２日に発行された、"Content Delivery Framework With Dynamic Service Network Topology"という発明の名称の米国特許第８，８２５，８３０号明細書。

本発明は、コンテンツ配信およびコンテンツ配信ネットワークに関する。より具体的には、本発明は、コンテンツ配信ネットワークにおける無効化に関する。

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

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

本明細書の例示的な実施形態に従った配信サービスの論理構造を示す。

本明細書の例示的な実施形態に従った無効化リストを格納するためのデータ構造例を示す。

特定のコンテンツプロバイダに対するプロパティ例の階層的またはツリー構造を示す。

本明細書の態様のオペレーションのフローチャートである。

本明細書の例示的な実施形態に従った共通プレフィックスリストを格納するためのデータ構造例を示す。

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

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

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

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

ＨＴＴＰＳは、ＨＴＴＰセキュア（HTTP Secure）を意味する。

ＭＯＶは、最小オリジンバージョン（minimum origin version）を意味する。

ＲＯＶは、リソースオリジンバージョン（resource origin version）を意味する。

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

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

"メカニズム"とは、あらゆるデバイス、プロセス、ルーチン、サービス、モジュール、またはそれらの組み合わせを指す。あるメカニズムは、ハードウェアで、ソフトウェアで、ファームウェアで、特定用途向けデバイスを使用して、またはそれらの任意の組み合わせによって実施されてよい。あるメカニズムは、単一のデバイスに統合されてよい。または、多数のデバイスにわたって分散されてよい。あるメカニズムの様々な構成要素が、同一の場所に配置されてよい。または分散されてよい。このメカニズムは、その他複数のメカニズムから形成されてよい。従って、本明細書にて使用されるように、一般に、"メカニズム"という用語は、デバイスおよび／またはプロセスおよび／またはサービスという用語に対する簡潔にした表現とみなされてよい。
バックグラウンドおよび概要

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

図１は、１または複数のコンテンツプロバイダ１０２が、１または複数のオリジンソース１０４および配信サービス（サーバ）１０６を介し、１または複数のネットワーク１１０を介して複数のクライアント１０８へとコンテンツを提供する、例示的なＣＤＮ１００の態様を示す。配信サービス（サーバ）１０６は、複数のクライアントがそこからコンテンツを取得し得る、配信ネットワークを形成してよい。配信サービス１０６は、論理的に、および／または物理的に階層的に編成されてよく、エッジキャッシュを含んでよい。

例示的なＣＤＮが、米国特許第８，０６０，６１３号明細書および第８，８２５，８３０号明細書に記載され、全ての目的に対し、その両者の全内容が参照により本明細書に完全に組み込まれている。

特定のコンテンツプロバイダに関連した、または特定のコンテンツプロバイダによって提供されるコンテンツは、プロパティと呼ばれることがある。プロパティは、例えばウェブサイトおよび関連するコンテンツであってよく、通常、多数のリソースを含む。ＣＤＮは、１または複数のコンテンツプロバイダに関連した、および／または、１または複数のコンテンツプロバイダの代わりに、１または複数のプロパティを提供し得る。コンテンツプロバイダは、１つよりも多くのプロパティを有してよい。従って、ＣＤＮは、特定のコンテンツプロバイダに関連した、および／または、特定のコンテンツプロバイダの代わりに、１または複数のプロパティを供給／提供し得る。

理解されるように、あるＣＤＮの複数の構成要素（例えば、配信サーバ、等）が、他の複数のＣＤＮ構成要素に対してコンテンツを配信すべく、このＣＤＮを使用し得る。従って、あるＣＤＮ構成要素は、それ自身がこのＣＤＮのクライアントであり得る。例えば、このＣＤＮは、それ自身のインフラストラクチャを使用して、複数のＣＤＮ構成要素に対してＣＤＮコンテンツ（例えば、ＣＤＮ制御および構成情報）を配信し得る。

コンテンツ（例えば、コンテンツプロバイダのプロパティに関連したリソース）が、このＣＤＮ内の様々な位置、例えば、このＣＤＮの様々な配信サービスによって形成される配信ネットワークにおける複数のノードにおいてキャッシュされてよい。コンテンツは、例えば、このＣＤＮから供給される場合にキャッシュされてよい。

ＣＤＮは、古いコンテンツ、または期限切れのコンテンツ、または無効化された（無効な）コンテンツを供給するべきではない。無効なコンテンツ、または期限切れのコンテンツ、または古いコンテンツは、（そのコンテンツの有効なバージョンが存在するのであれば）供給される前にリフレッシュされるべきである。コンテンツは、非同期的にリフレッシュされてよい。

無効化とは、これによって、サービス中に格納された情報（例えば、将来のリクエストに対する応答を導出するために使用され得る情報）が、応答導出のためにはもはや直接利用可能ではないとマークされる、または指定されるメカニズムである。従って、何らかの形での状態の更新、または、代替的な導出パスが、将来のリクエストに対する応答を導出するために使用されなくてはならないことを示す。無効化を利用するサービスは、無効化マニフェストを使用し、これらのマニフェストに含まれるコマンドをローカルに処理する。

キャッシングまたは配信サービスは、無効化を利用するサービスの典型的な例である。キャッシュは、リソースのリテラルなコピーを格納し、このコピーが古くない限り、格納されたリテラルなコピーを使用して、リソース（または、このリソースに基づく情報）に対する将来のリクエストに応答する。理解されるように、リクエストは、特定のリソース自身に対するもの、または、この特定のリソースに基づいて判断される、または導出される情報（例えば、別のリソース）に対するものであってよい。この場合、古さは、例えば、格納されたオリジナルコピーの経時的な期限切れに基づいたもの、または、このコピーが格納されて以来、このコピーが明確に無効化されたことがあったか否かに基づいたものであり得る。既にキャッシュにあるコマンドを対象として無効化コマンドが受信された場合、そのコマンドを実行するよう、キャッシュされたコピーにマークすれば十分である。そのリソースがキャッシュに無い場合、または、そのコマンドが、多数であり得るリソースの一群を指す場合には、最後に適用できる無効化コマンドの制約を（例えば、いくつかの他のキャッシュから）後で取得されるコピーが満たすことを保証するために、追加のステップが取られなくてはならない。"無効化"という用語は、本明細書において、場合によっては無効化コマンドを指すために使用される。

キャッシュされたコンテンツは、有効期限（ＴＴＬ）値に関連付けられてよい。この場合、コンテンツは、自身の有効期限が満了となった後では、供給されるべきではない（すなわち、有効とみなされるべきではない）。コンテンツは、自身の無効化を配信サービスに対して（または配信サービスネットワークに対して）シグナリングすることによってもまた無効化され得る。無効化は、例えば、１または複数のリソースを特定する無効化命令を提供することによりシグナリングされ得る。

この説明を目的として、リソースは、コンテンツのアドレス指定可能なアイテムである。または、アドレス指定可能なアイテムに対応する。ＣＤＮによって提供され（例えば、供給され）、内部ＣＤＮリソースを含む各リソースは、ユニフォームリソースロケータ（ＵＲＬ）であり得るユニフォームリソース識別子（ＵＲＩ）によって識別またはアドレス指定され得る。ＵＲＩは、例えば、Network Working Group, Request for Comments (RFC) 3986, Berners-Lee、２００５年１月、"Uniform Resource Identifier (URI): Generic Syntax"に説明されている。また、ＵＲＬは、例えば、Network Working Group, Berners-Lee, Request for Comments 1738、１９９４年１２月、"Uniform Resource Locators (URL)"に説明されている。全ての目的に対し、これによって両者の全内容が、参照により本明細書に完全に組み込まれる。

好ましい実施形態において、各リソースはＵＲＬによってアドレス指定可能であり、無効化命令は、単一のリソースまたは一群の（ゼロまたはゼロよりも多くの）リソースを特定し得る。単一のリソースを特定する無効化命令は、そのリソースに対するＵＲＬ（またはＵＲＩ）を特定し得る。例えば、可能なリソースの組に対する一組の制約によって、リソースグループが特定され得る。従って、一般に、グループ無効化は、そのグループのメンバーを画定する１または複数の制約によって、グループを特定する。

グループ無効化命令は、例えば、ある特定のサブディレクトリにある全てのコンテンツ、または、共通の拡張子を有する全てのリソースがもはや有効ではないことを特定してよい。一群のリソースを特定する無効化命令は、例えば、それらのリソースの特定において、１または複数のワイルドカードを使用し得る。いくつかの実装において、グループ無効化は、ワイルドカード無効化と呼ばれる。

例えば、特定のコンテンツプロバイダ（ＣＰ）が、ルート"／ＣＰ"によって特定されるプロパティを有してよく、サブディレクトリ"／ＣＰ／Ｉｍａｇｅｓ"下に複数の画像を含んでよい。一群の画像（例えば、"／ＣＰ／Ｉｍａｇｅｓ／Ｉｍａｇｅ＿Ｓｅｐｔｅｍｂｅｒ＊２０１４．ｊｐｇ"）がそうされるように、特定の画像（例えば、"／ＣＰ／Ｉｍａｇｅｓ／Ｉｍａｇｅ１．ｊｐｇ"）が無効化され得る。ここで、スター符号は、ゼロまたはゼロよりも多くの文字に対応するメタ文字（またはワイルドカード）である。グループ無効化は、ゼロまたはゼロよりも多くのリソースを特定し得ることが理解されるべきである。例えば、制約"／ＣＰ／Ｉｍａｇｅｓ／Ｉｍａｇｅ＿Ｓｅｐｔｅｍｂｅｒ＊２０１４．ｊｐｇ"を満たすリソースが１つも存在しないことがあり得る。

本明細書で使用されるように、"リソース"とは、特定のリクエストに対し、（可能性として）キャッシュされた応答を意味する。そのため、理論的には、このリクエストまたはこの応答の任意の属性が、あるグループを画定するものとみなされ得る。リソースグループに基づいた無効化システムの実際的な実装は、複数のグループがどのようにして効率良く画定され得るかに関する追加の制約を課すかもしれないが、そのような制約は、アーキテクチャレベルで課される必要はない。

本明細書のいくつかの好ましい実装においては、いわゆる"グロブ"パターン言語のようなパターン言語によってグループが特定され得る。本明細書にて使用されるように、グロブパターン言語は、任意の文字列に合致させるべく"＊"メタ文字が使用される任意のパターン言語である。しかし、その他のメタ文字もまた存在してよい。グロブは、グロブパターン言語で書かれたパターンである。＊−グロブ（スターグロブ）パターン言語は、"＊"メタ文字およびリテラル文字のみによるグロブパターン言語である。＊−グロブ（スターグロブ）（または、＊−グロブパターン）は、＊−グロブパターン言語で書かれたパターンである。このシステムは、パターンマッチングアルゴリズムまたは本明細書で使用される、または説明される言語によって限定されるものでは決してないことが理解されるべきである。また、このシステムは、本明細書で説明されるパターンまたはパターンマッチング（または関連するオペレーション）を実行するために使用される、特定の言語またはプログラムによって限定されるものでも決してない。特に、ＵＲＬ上で定義される正規表現またはグロブパターンは、グループを定義する多数の可能なやり方のいくつかにすぎないことが理解されるべきである。当業者は、この記載を読めば、グループを記述する異なるやり方、および／またはその他のやり方が使用される得ること、および、本明細書にて考慮されていることに気付き、理解するだろう。
最小オリジンバージョン（ＭＯＶ）無効化

無効化マニフェストは、オリジンバージョンに基づいて無効化するための手法を実行する。無効化コマンドによってコンテンツが無効化される場合、その無効化されるコンテンツに対する最小オリジンバージョン（ｍｏｖ）がインクリメントされる。最小オリジンバージョン無効化は、各オリジンが単一のリソースネームスペースであること、および、全ての無効化コマンドが、単一のオリジン位置におけるいくつかのオリジン閾値イベントに関連することを仮定する。この手法は、無効化が、最小オリジンバージョンの設定として定義されることを可能にする。この場合、このシステムの各キャッシュは、オリジンからコンテンツが入ってくる際に、最小オリジンバージョンを推定する。ＭＯＶ無効化は、一般に、多数の位置でコンテンツを発行する場合に、オリジンサーバが一貫したものであることを必要とする。そうすることにより、どのオリジンがコンタクトされたかに関わらず、与えられたＵＲＬが一貫したリソースを受信するだろう。

キャッシュ中の各リソースは、それらと関連したリソースオリジンバージョン（ＲＯＶ）を有する。リソースに対するＲＯＶは、キャッシュが、オリジンサーバまたは別のキャッシュから直接にコンテンツを取得する場合に取得／設定される。ＲＯＶは、それが再有効化またはリフレッシュされるまで、それがどこへ行こうとも、リソースのそのコピーの実際のオリジンバージョンとして残る。キャッシュが別のキャッシュからコンテンツをリクエストする場合、クライアントキャッシュは、サーバが提供するどんなＲＯＶも、それがキャッシュに格納するＲＯＶとして使用する。

各無効化コマンド（ＩＣ）は、関連するＭＯＶ値を有する。キャッシュ中のリソースに対するＲＯＶ値が少なくともこのＭＯＶ値と同じ大きさである場合、このリソースは有効とみなされ、供給されることができる。一方、キャッシュされたリソースに対するＭＯＶ値よりもＲＯＶ値が小さい場合、このリソースの新たなバージョンが、供給される前に取得されなくてはならない。例えば、特定のリソースＲを暗示する無効化コマンドがｍｏｖ＝１００を有し、リソースＲのキャッシュされたバージョンはｒｏｖ＝９９を有する場合、このリソースＲは古いものとみなされ、供給されることができない。一方、リソースＲのキャッシュされたバージョンがｒｏｖ＝１００またはそれより大きい場合、リソースＲのキャッシュされたバージョンは古くはなく、使用されること（例えば、供給されること）ができる。

ＭＯＶ無効化は、２０１３年３月１５日に出願され、２０１４年９月２日に発行された"Content Delivery Framework With Dynamic Service Network Topology"という発明の名称の米国特許第８，８２５，８３０号明細書に記載されている。全ての目的に対し、特に、無効化およびＭＯＶ無効化の説明に対するものを含め、その全内容が参照により本明細書に完全に組み込まれる。

図２は、本明細書の例示的な実施形態に従った、配信サービス１０６の論理構造を示す。図２に示されるように、配信サービス１０６は、入ってくるリクエストに対する応答を処理し、提供するための、ルールエンジン２０４と相互作用するリクエスト／応答−処理メカニズム２０２を含む。リクエストされたリソースは、説明されたように、供給する前にあらゆるキャッシュされたリソースの有効性を判断する必要があるものの、配信サービス１０６と関連したローカルキャッシュ２０６に既にキャッシュされていてよい。これに関連して、ルールエンジン２０４は、無効化メカニズム２１０によって配信サービス１０６に保持される１または複数の無効化リスト２０８にアクセスしてよい。

この説明を目的として、無効化メカニズム２１０の役割は、以下においてより詳細に説明されるように、無効化情報（例えば、無効化リスト２０８）を、配信サービス１０６に保持することである。

好ましくは、各配信サービス１０６が、特定のプロパティまたは複数のプロパティの組を供給することを担当し、好ましくは、ある配信サービス１０６が担当する各プロパティに対して無効化リストが存在する。図３は、ｎ個の無効化リストであって、１つのリストが、配信サービス１０６が供給するであろう複数のプロパティＰ_１、Ｐ_２、…Ｐ_ｎのそれぞれに対するものである、無効化リストを格納するためのデータ構造例を示す（この場合、配信サービスが、ｎ個のプロパティのそれぞれを供給することを担当していることを仮定する）。特定のプロパティに対する例示的な無効化リストが、そのプロパティに対する多数の無効化コマンド（または制約）を含んでよい。例えば、図３に示されるように、プロパティＰ_ｎに対する無効化リストが、そのプロパティに対して、ｍ個までの無効化コマンド（ＩＣ_１、ＩＣ_２、ＩＣ_３、…、ＩＣ_ｍ）を含んでよい。この手法の一態様は、あるキャッシュにおいて受信され、そのキャッシュにおける（または、そのキャッシュから供給され得るプロパティに対する）リソースをヒットしない無効化コマンドは、合致するリソースのあらゆるその後のフィルがコヒーレントなやり方で行われることを保証すべく、保持される必要があり得ることである、ということが理解されるべきである。

無効化コマンド（ＩＣ_ｊ）は、ｍｏｖおよび現在キャッシュにあり得る、またはキャッシュに無い場合もあり得る単一のリソースまたは複数のリソースのグループを識別する、いくつかのリソース記述子または指定子を特定する。（例えば名称によって）正確に１つのリソースを特定するＩＣは、グランドリソース（ground resource）指定子ともまた呼ばれることがある。グランドＩＣは、受信されると処理されてよく、このＩＣが受信された場合に、特定されたリソースを無効とマークする。複数のリクエストが受信された場合に、グループ無効化（複数のグループを特定する無効化コマンド）が評価される。従って、無効化コマンドｌは、（ｉ）Ｒが正確に１つのリソースを特定し、ｍｏｖがそのリソースに対するＭＯＶ値である、ｌ（ｍｏｖ，Ｒ）の形のグランドコマンドであるか、または、（ｉｉ）ｍｏｖがＭＯＶ値であり、Ｇが制約設定を特定する、ｌ（ｍｏｖ，Ｇ）の形のグループコマンドであってよい。グランドリソース指定子が１つのリソースを特定するのに対し、いくつかの場合においては、グランド無効化コマンドは、それらの全てが単一のＵＲＬによってアクセスされ得る多数のリソース（例えば、多数のコンテンツエンコーディングが入手可能なリソース、または多数の変形を有するリソース）に影響を及ぼし得る。

図４は、特定のコンテンツプロバイダに対するプロパティ例の階層的またはツリー構造を示す。この例のため、プロパティは、スラッシュ"／"文字で始まり、複数のリソースの２つの主たるサブツリー（"／ＸＹＺ"および"／ａｂｃ"）を有する。"／ＸＹＺ"によって特定されるリソースのサブツリーは、リソース"／ＸＹＺ／ＰＱＲ"のサブツリーを含み、これは、リソース（"／ＸＹＺ／ＰＱＲ／ｆａ／"、"／ＸＹＺ／ＰＱＲ／ｆａｎ"、"／ＸＹＺ／ＰＱＲ／ｆｕｎ／"、および"／ＸＹＺ／ＰＱＲ／ｆｘ"）の４つのサブツリーを含む。このプロパティは、その他のサブツリー（図示されず）を含んでよい。

以下は、最大１０個の無効化コマンド（ＩＣ）を有するように構成されたプロパティに対する無効化リストの例であって、７個のコマンドが格納されており、さらに３個の無効化コマンドのためのスペースを有する。このリストは、無効化コマンドまたはマニフェストと共に提供されるＭＯＶ値に基づいて、または（以下に記載されるような）クランプリング（crumpling）の間に決定されたＭＯＶ値に基づいて、ＭＯＶが順序付けられていることに留意されたい。

このリストの例において、無効化コマンド／制約は、グロブ−＊パターンの形で特定される。従って、例えば、第１パターンが、ストリング"／ＸＹＺ／ＰＱＲ／ｆ"で始まるあらゆるリソースに合致するだろう。これに対し、第２パターンが、ストリング"／ＸＹＺ／ＰＱＲ／ｆｕ"で始まるあらゆるリソースに合致するだろう。従って、図４に示されるプロパティの階層を参照すると、第１パターン／制約（"／ＸＹＺ／ＰＱＲ／ｆ＊"）が、リソース "／ＸＹＺ／ＰＱＲ／ｆａ／"、"／ＸＹＺ／ＰＱＲ／ｆａｎ"、"／ＸＹＺ／ＰＱＲ／ｆｕｎ／"、および"／ＸＹＺ／ＰＱＲ／ｆｘ" の４つのサブツリーに合致するのに対し、第２制約（"／ＸＹＺ／ＰＱＲ／ｆｕ＊"）は、サブツリー"／ＸＹＺ／ＰＱＲ／ｆｕｎ"のみに合致する。

無効化コマンド／制約は、有効なリソースを関係させてよい。例えば、図４に示される例において、サブツリー"／ＸＹＺ／ＰＱＲ／ｆｕｎ"におけるいくつかのリソースが無効であると仮定するが、その他のサブツリー（"／ＸＹＺ／ＰＱＲ／ｆａ／"、"／ＸＹＺ／ＰＱＲ／ｆａｎ"、および"／ＸＹＺ／ＰＱＲ／ｆｘ"）における全てのリソースは、依然として有効であると仮定する。無効化コマンド＃１（"／ＸＹＺ／ＰＱＲ／ｆ＊"は、たとえそれらが有効であろうとも、サブツリー（"／ＸＹＺ／ＰＱＲ／ｆａ／"、"／ＸＹＺ／ＰＱＲ／ｆａｎ"、および"／ＸＹＺ／ＰＱＲ／ｆｘ"）中のリソースの全てを関係させるだろう。一方、無効化コマンド＃２は、それらの有効なリソースを関係させないだろう。

無効化制約は、（存在するのであれば）可能な限り少ない有効なリソースを関係させること（従って、無効化すること）が、一般には好ましい。言い換えると、無効化制約は、全ての無効なリソースを依然として無効化しながらも、有効なリソースに対して最小の影響しか及ぼさないことが、一般には好ましい。

無効化メカニズム２１０は、適切な無効化リスト２０８に対して無効化コマンドを追加するために使用される、無効化追加メカニズム２１２を含む。配信サービス１０６が、（例えば、無効化マニフェストの形の）新たな無効化コマンド２１４を受信する場合、以下に記載されるように、無効化追加メカニズム２１２は、適切な無効化リスト２０８に対して、それらのコマンドの少なくともいくつかを追加しようと試みる。

言及されたように、各プロパティの無効化リストは、最大のサイズ（ｍａｘ）（すなわち、格納し得る最大数の制約）を有する。この最大は、好ましくは管理者によって設定され、好ましくは、ユーザによって（すなわち、ＣＤＮの加入者によって）は設定可能ではない。各無効化リストはまた、それらと関連する閾値（Ｔ）を有してもよい（ここで、Ｔ≦ｍａｘ）。現在の好ましい実装において、プロパティ毎に格納およびサーチするためのパターンの最大グローバルデフォルト数は１００である。この初期デフォルトに対する動機は、リクエスト毎の（リクエスト／応答処理の間の）グロブサーチの数を制限することである。異なる加入者は異なる最大リストサイズを有し得ることが理解されるべきである。

図５のフローチャートを参照すると、配信サービス１０６が新たな無効化コマンド２１４を受信する場合、無効化追加メカニズム２１２は、複製するために、適切な無効化リスト２０８に対して、この新たなコマンド２１４をチェックする。既存のパターンの正確な複製が削除され、この新たな（最後の）ＭＯＶ値、並びに強制ＭＯＶ値（以下において説明される、無効化が強制タイプの場合に追跡されるＭＯＶ）により更新される。オペレーションにおいて、無効なリソースは、（例えば、オリジンサーバまたはピアを介して）そのリソースに対するリクエストがそのリソースの再有効化をトリガするまで、通常、キャッシュに残る。再有効化は、それが変更された場合にのみリソースを取得する、条件付きＧＥＴの形を取る。いわゆる"強制された"無効化は、オリジンサーバ（または、適切な位置）から、このリソースの無条件の"ＧＥＴ"を実行する。

挿入すると、パターンの数が許容される数（またはそのプロパティに対する閾値）を超える場合、パターンの数が最大の許容される数（または閾値）を下回るまで、クランプリングが開始される。
クランプリング

パターンベースの（非明示的）無効化手法に対し、無効化は、決して安全に有効期限切れになることができない。この手法が性能に及ぼす影響の可能性を試し、低減するべく、クランプリングが最適化される。その目的は、クランプリングの結果が最小の影響を生じるように、２つのエントリをクランプリングすることである。

無効化リストの文脈において、クランプリングは、クランプリングメカニズム２１６によって実行される。クランプリングは、２またはそれ以上の無効化パターンまたは制約を結合すること、または何とかして組み合わせることの効果である。クランプリングは、入力として２またはそれ以上の無効化コマンド（それらの関連するＭＯＶ値を含む）を取り、入力無効化コマンドと少なくとも同じ程度に厳密な無効化コマンド（結合されたコマンド）を返す、クランプリング関数の観点から定義され得る。言い換えると、結合されたコマンドは、少なくとも、入力コマンドが無効化するあらゆるリソースを無効化すべきである。

組み合わされた／結合された制約が無効化リストに挿入され、組み合わされていた／結合されていた制約の全てを置き換える。その結果生じる無効化制約は、少なくとも、組み合わされた全ての制約と同じ程度に厳密であるべきである。

クランプリング関数への入力は、現在の無効化リストのみからのものであり得ること、または、新たに受信された無効化コマンドのうちの１または複数を含み得ることに留意されたい。

クランプリングが最小の実効的な影響を有するためには、２つの基本的な仮定が存在する。
１．ディレクトリ、特に'／'をクランプリングすることは、あるディレクトリ内でクランプリングすることよりも、より多くのリソースに影響を及ぼす。
２．あるディレクトリ内でより多くの文字をクランプリングすることは、より少ない文字をクランプリングすることよりも、より多くのリソースに影響を及ぼす。

好ましい実装において、キャッシュには、リソースのインデックスまたはリストが存在しない。また、一般に、あるサブディレクトリにいくつのリソースが実際に存在するのかを知る方法も無い。当業者は、この記載を読めば、任意のサブディレクトリにいくつのリソースが実際に存在するのかを知る方法が無いので、これらの仮定が常に最適な結果を与え得るものではないことに気付き、理解するだろう。

クランプリングメカニズム２１６は、サービス１０６が担当する各プロパティに対して、プレフィックスリスト（または共通プレフィックスアレイ）２１８を保持する。つまり、クランプリングメカニズム２１６は、無効化リスト２０８が存在するそれぞれのプロパティに対し、プロパティ毎に共通プレフィックスアレイを保持する（図２および図６）。新たな無効化パターンが受信された場合、既存のパターンのリストに対して、この新たなパターンがチェックされる。共通プレフィックスが見出された場合、（もし、まだそこにないのであれば）この共通プレフィックスがプレフィックスアレイに追加される。このプレフィックスアレイは、（上記の２つの仮定に基づいて）"最小の影響"から"最大の影響"の順にソートされる。このプレフィックスアレイは、許容されるパターンの最大数より大きくはなり得ない。クランプリングはまた、プレフィックスアレイ内でも起こり得るが、まれに起こるだけである。そして、そのような場合、複数の要素が、最大の影響から最小の影響へという順序で削除される。

クランプリングは、次に、最小の影響のプレフィックスアレイ要素を取ること、および、その共通プレフィックスに対して無効化パターンをマッチングすることおよび組み合わせることを含む。

以下は、最大１０個の無効化コマンドを有するように構成されたプロパティに対するＭＯＶ順の無効化リストの例であって、１０個のコマンドが格納されており、それ以上の無効化コマンド（ＩＣ）のためのスペースを有さない。例示的なＭＯＶ値がこれらの例に示される。

このプロパティに対し対応するプレフィックスリストは次の通りである。

この例において、新たな無効化コマンド（例えば、"／ｓｔ／ｐｅｔｅｒ／＊"）が受信された場合、エントリ（"／ｓｔ／ｐ"）が、どれをクランプリングするかを判断する前（これと、無効化テーブルに既にある任意のエントリとの間の最も長い共通プレフィックス）のプレフィックスリストに追加されるべきである。これは、ディレクトリ内で６文字クランプリングするので、以下に示されるように、"／ｅｌｅｃｔ／２０１"の直前に挿入されるべきである。

無効化リストに場所を作ることもまた必要である。多数の可能な結合の候補が存在し、例えば、次の通りである。
（ｉ）"／ＸＹＺ／ＰＱＲ／ｆ＊"および"／ＸＹＺ／ＰＱＲ／ｆｕ＊"が"／ＸＹＺ／ＰＱＲ／ｆ＊"に結合されてよい。または、
（ｉｉ）"／ｄｉｅｔ／ａｔｋ＊"および"／ｄｉｅｔ／ｎｏｃｒｂ＊"が"／ｄｉｅｔ／＊"に結合されてよい。または、
（ｉｉｉ）"／ＸＹＺ／ＰＱＲ／ｆ＊"および"／ＸＹＺ／ＰＱＲ／ｆｕ＊"および"／ＸＹＺ／ＰＱＲ／ａｂ＊"が"／ＸＹＺ／ＰＱＲ／＊"に結合されてよい。または、
（ｉｖ）"／ａｂｃ／ｄｅｆ／２＊"および"／ａｂｃ／ｄｅｆ／４＊"が"／ａｂｃ／ｄｅｆ／＊"に結合されてよい。または、
（ｖ）"／ＸＹＺ／ＰＱＲ／ｆ＊"および"／ＸＹＺ／ＰＱＲ／ｆｕ＊"および"／ＸＹＺ／ＰＱＲ／ａｂ＊"および"／ｄｉｅｔ／ａｔｋ＊"および"／ｄｉｅｔ／ｎｏｃｒｂ＊"が"／ｄｉ＊"に全て結合されてよい。または、
（ｖｉ）"／ｅｌｅｃｔ／２０１５＊"および"／ｅｌｅｃｔ／２０１２＊"が"／ｅｌｅｃｔ／２０１＊"に結合されてよい。または、
（ｖｉｉｉ）"／ｓｔ／ｐｅｔｅｒ／＊"および"／ｓｔ／ｐａｔｒｉｃｋ／＊"が"／ｓｔ／ｐ＊"に結合されてよい。または、
（ｖｉｉ）全てのパターン／制約が"／＊"に結合されてよい。

明らかに最後のもの（ｖｉｉｉ）は、このプロパティに対するあらゆるリソースの無効化を効果的に強制するので、ほとんどのリソースを関係させるだろう。

しかしながら、プレフィックスアレイに基づくと、プレフィックス"／ＸＹＺ／ＰＱＲ／ｆ＊"へのＩＣの結合は、（有効なリソースに対する）最小の影響を有するはずである。従って、２つのパターン"／ＸＹＺ／ＰＱＲ／ｆ＊"および"／ＸＹＺ／ＰＱＲ／ｆｕ＊"が"／ＸＹＺ／ＰＱＲ／ｆ＊"に結合され、この新たなパターンがリストに挿入される。

クランプリングの結果が以下に示される。

言及されたように、無効化リストはＭＯＶ順である。クランプリングの間にＭＯＶ値が更新される。特に、結合されたパターンのＭＯＶ値は、結合されているパターンのうちで最も高いＭＯＶ値である。従って、例えば、"／ＸＹＺ／ＰＱＲ／ｆ＊"と"／ＸＹＺ／ＰＱＲ／ｆｕ＊"を組み合わせる場合、結果として生じるエントリは、組み合わされた無効化コマンドのうちで最も高いＭＯＶ、この場合は、"／ＸＹＺ／ＰＱＲ／ｆｕ＊"コマンドからのＭＯＶを有するだろう。"／ＸＹＺ／ＰＱＲ／ｆ＊"のＭＯＶ値は１００であり、"／ＸＹＺ／ＰＱＲ／ｆｕ＊"のＭＯＶ値は１１０であった。従って、結合されたパターンのＭＯＶ値は１１０＝ｍａｘ（１００，１１０）である。一般に、ｋ個の無効化パターン（Ｐ１…Ｐｋ）がパターンＰｃに結合されている（またはクランプリングされている）場合、ＰｃのＭＯＶは、ｍａｘ（ｍｏｖ_ｉ，ｉ＝１…ｋ）である。結合されている特定のパターンは、既に、以前の結合の結果であってよく、そうすると、その特定のパターンのＭＯＶは、その結合の間に設定されていたものであってよいことに留意されたい。また、パターンＰｃは、結合中の、既に存在しているパターン（Ｐｉ）のうちの１つであってよいが、しかしながら、それ自身のＭＯＶ値は変化してよいことにもまた留意されたい。例えば、この例において、クランプリングの前後のリストにパターン"／ＸＹＺ／ＰＱＲ／ｆ＊"があったが、自身のＭＯＶ値は（１００から１１０へ）変化したものと仮定する。

上記の例において、"／ａｂｃ／ｄｅｆ／２＊"およびそれを超えるものに対する値は、初期テーブルにあったもののままである。

当業者は、この記載を読めば、結合されたリソースのＭＯＶ値を更新することは、より多くの誤検出無効化を生じかねないことに気付き、理解するだろう。

本明細書にて与えられる例において、／ＸＹＺ／ＰＱＲ／ｆＡＢＣのリクエストパスを有し、１００またはそれより大きなＲＯＶを有して格納されていたリソースが、オリジナルの無効化制約リストでは新たなものとみなされてきただろう。しかしながら、クランプリング後には、１１０またはそれより大きなＲＯＶを有するようなリソースのみが有効とみなされよう。

結合および挿入に基づいて、共通プレフィックスリストが次のように更新される。

この例から明らかなように、クランプリングされた無効化コマンドは、新たなコマンドを含む必要がなく、リストに既にあるコマンドが結合されるものであってよい。

どの無効化コマンドをクランプリングまたは結合するかに関する判断は、組み合わされるコマンドのＭＯＶ値に基づくものであってよい。いくつかの場合において、無効化コマンドは、組み合わされるコマンドのうち、どれが最も小さなＭＯＶ値の変化を有するのかに基づいて結合されてよい。いくつかの場合において、無効化コマンドは、組み合わされるコマンドのうち、どれが最も小さな実際のＭＯＶ値を有するのかに基づいて結合されてよい。ＭＯＶ値は、例えば、複数の結合／クランプリング候補に対して結着を付けるものとして使用されてよい。

例として、４つの無効化コマンドを考える。
ＩＣ１：制約１、ｍｏｖ１。
ＩＣ２：制約２、ｍｏｖ２。
ＩＣ３：制約３、ｍｏｖ３。
ＩＣ４：制約４、ｍｏｖ４。

結合の選択は次の通りと仮定する：
ＩＣ５＝ＩＣ１＆ＩＣ２：ｍｏｖ５＝Ｍａｘ（ｍｏｖ１，ｍｏｖ２）。
ＩＣ６＝ＩＣ３＆ＩＣ４：ｍｏｖ６＝Ｍａｘ（ｍｏｖ３，ｍｏｖ４）。

いくつかの場合において、ｍｏｖ５およびｍｏｖ６の小さい方を有する結合が選択されてよい。いくつかの場合において、（ｉ）ｍｏｖ５とｍｉｎ（ｍｏｖ１，ｍｏｖ２）との間、および（ｉｉ）ｍｏｖ６とｍｉｎ（ｍｏｖ３，ｍｏｖ４）との間の差を最小限にする結合が選択されてよい。従って、例えば、ｍｏｖ１＝１００且つｍｏｖ２＝１０１とすると、ｍｏｖ５＝１０１であり、ｍｉｎ（ｍｏｖ１，ｍｏｖ２）との間の差は１である。ｍｏｖ３＝９０且つｍｏｖ４＝１２０とすると、ｍｏｖ６＝１２０であり、ｍｏｖ６とｍｉｎ（ｍｏｖ３，ｍｏｖ４）との間の差は３０である。この差を最小限にする結合（すなわち、ＩＣ５）が選択されるだろう。
リクエスト−応答処理

好ましい実装において、実際のリソースの無効化は、そのリソースに対するリクエスト時に行われる。これは、このリソースがリクエストされなければ、（無効化情報を格納することの他には）本質的に何も行う必要が無いという点を含めて、多数の理由から有利である。

リソースに対するリクエスト（例えば、ＨＴＴＰリクエスト）をサービスが取得する場合、それは、無効なリソースの適切なリストに対して（すなわち、そのプロパティに対する無効なリソースのリストに対して）、リクエストされたリソースをチェックする。このリソースがリスト上の制約に対応し、このリソースのＲＯＶ値がその制約のＭＯＶ値より小さい場合、このリソースが供給され得る前に、このリソースの有効な／新たなバージョンが取得されなくてはならない。従って、このリストに対する制約が、リクエストされたリソースが無効であることを示す場合、このサービスは、（例えば、オリジンサーバのようなコンテンツプロバイダのコンテンツソースから、または、ＣＤＮ中の別の位置（例えば、ピア）から）このリソースを複製する。このリソースの新たなバージョンが取得された場合に、このリソースのＲＯＶ値が更新される。

例えば、上記のクランプリング前に、リソース"／ＸＹＺ／ＰＱＲ／ｆａ．ｇｉｆ"をユーザがリクエストするものと仮定する。この例において、キャッシュは、ｒｏｖ＝１０１であるバージョンの"／ＸＹＺ／ＰＱＲ／ｆａ．ｇｉｆ"を有するものと仮定する。リクエストされたリソースは、無効化制約"／ＸＹＺ／ＰＱＲ／ｆ＊"に合致するが、キャッシュされたリソース（ｒｏｖ＝１０１）のＲＯＶは、この制約に関連するＭＯＶ値（ｍｏｖ＝１００）より大きい。このキャッシュされたバージョンが供給され得る。上記のクランプリング後には、制約"／ＸＹＺ／ＰＱＲ／ｆ＊"のＭＯＶ値は１１０であり、そのため、ｒｏｖ＝１０１を有するキャッシュされたリソース"／ＸＹＺ／ＰＱＲ／ｆａ．ｇｉｆ"は無効とみなされる。サーバは、例えば、オリジンサーバまたはＣＤＮ中の別の位置からリソース"／ＸＹＺ／ＰＱＲ／ｆａ．ｇｉｆ"をリフレッシュする。リフレッシュされたバージョンは、有効とみなされるために、少なくとも１１０のＲＯＶを有さなくてはならない。上記にて説明されたように、このバージョンは既に有効であってよく、クランプリングのために（誤検出として）無効と暗示されていたものであってよい。

ＣＤＮにおける無効化の例示的なオペレーションが、米国特許第８，０６０，６１３号明細書に記載され、全ての目的に対し、その全内容が参照により本明細書に完全に組み込まれる。

クランプリングは、コンテンツが供給されるデバイスと同一のデバイスで行われる必要はないことが理解されるべきである。例えば、クランプリングは、末端のデバイスで行われてよいし、あるいは、中央で行われることもできる。
コンピューティング

上記にて示され、説明されたサービス、メカニズム、オペレーション、および動作は、少なくとも部分的に、ＣＤＮ１００の１または複数のコンピュータにおいて実行しているソフトウェアによって実施される。

そのような方法を実行するプログラム（並びに、その他のタイプのデータ）が、様々な媒体（例えば、コンピュータ可読媒体）を使用して、多数のやり方で格納され、送信されてよい。ハードワイヤードの回路またはカスタムハードウェアが、様々な実施形態のプロセスを実行することのできるソフトウェア命令のいくつか、または全ての代わりに、あるいはそれらと組み合わせて使用されてよい。従って、ハードウェアおよびソフトウェアの様々な組み合わせが、ソフトウェアのみの代わりに使用されてよい。

当業者は、この記載を読めば、本明細書にて説明される様々なプロセスが、例えば、適切にプログラムされた汎用コンピュータ、特定用途向けコンピュータおよびコンピューティングデバイスによって実施され得ることを、容易に認識および理解するだろう。１または複数のそのようなコンピュータまたはコンピューティングデバイスが、コンピュータシステムと呼ばれ得る。

図７は、本開示の実施形態が実施され、実行され得るコンピュータシステム７００の略図である。

本例に従うと、コンピュータシステム７００は、バス７０２（すなわち、相互接続）、１または複数のプロセッサ７０４、メインメモリ７０６、リムーバブルストレージ媒体７１０、リードオンリメモリ７０８、大容量ストレージ７１２、および１または複数の通信ポート７１４を含む。通信ポート７１４は、１または複数のネットワークに接続されてよく、これを通じて、コンピュータシステム７００がデータを受信および／または送信してよい。

本明細書にて使用されるように、"プロセッサ"とは、１または複数のマイクロプロセッサ、中央処理装置（ＣＰＵ）、コンピューティングデバイス、マイクロコントローラ、デジタル信号プロセッサ、または同様なデバイス、またはそれらの任意の組み合わせを、それらのアーキテクチャに関わらず意味する。プロセスを実行する装置は、例えば、プロセッサと、そのプロセスを実行するのに適切な、入力デバイスおよび出力デバイスのような複数のデバイスを含むことができる。

プロセッサ７０４は、これに限定されるものではないが、インテル（登録商標）Ｉｔａｎｉｕｍ（登録商標）またはＩｔａｎｉｕｍ２（登録商法）プロセッサ、ＡＭＤ（登録商標）Ｏｐｔｅｒｏｎ（登録商標）またはＡｔｈｌｏｎ ＭＰ（登録商標）プロセッサ、または、モトローラ（登録商標）の一連のプロセッサ、等のような、任意の既知のプロセッサであり得る。通信ポート７１４は、モデムベースのダイヤルアップ接続と共に使用するためのＲＳ−２３２ポート、１０／１００イーサネット（登録商標）ポート、銅またはファイバを使用したギガビットポート、または、ＵＳＢポート、等のいずれであってもよい。通信ポート７１４は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ＣＤＮ、または、コンピュータシステム７００が接続する任意のネットワークのような、ネットワークに応じて選択されてよい。コンピュータシステム７００は、周辺機器（例えば、ディスプレイスクリーン７１６、入出力（Ｉ／Ｏ）ポート７２０を介した入力デバイス７１８）と通信し得る。

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

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

本明細書における実施形態は、プロセスを実行するようにコンピュータ（または、その他の電子デバイス）をプログラムするために使用され得る命令がそこに格納された機械可読媒体を含み得る、１または複数のコンピュータプログラムプロダクトとして提供されてよい。本明細書にて使用されるように、"機械可読媒体"という用語は、コンピュータ、プロセッサ、または同様なデバイスによって読み出され得るデータ（例えば、命令、データ構造）を提供することに関与する任意の媒体、その媒体の複数、または、異なる媒体の組み合わせを指す。そのような媒体は、限定されるものではないが、不揮発性媒体、揮発性媒体、および伝送媒体を含めて、多くの形態を取り得る。不揮発性媒体は、例えば、光学ディスクまたは磁気ディスク、およびその他の永続メモリを含む。揮発性媒体は、コンピュータのメインメモリを通常構成する、ダイナミックランダムアクセスメモリを含む。伝送媒体は、プロセッサに連結されるシステムバスを備えるワイヤを含めて、同軸ケーブル、銅線、および光ファイバを含む。伝送媒体は、無線周波数（ＲＦ）および赤外（ＩＲ）データ通信の間で発生されるもののような、音波、光波、および電磁放射を含み得る、または伝え得る。

機械可読媒体は、限定されるものではないが、フロッピー（登録商標）ディスク、光学ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、ＲＯＭ、ＲＡＭ、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、磁気カードまたは光カード、フラッシュメモリ、または、電子命令を格納するのに適したその他のタイプの媒体／機械可読媒体を含んでよい。さらに、本明細書における実施形態はまた、コンピュータプログラムプロダクトしてダウンロードされてもよい。その場合、プログラムは、搬送波またはその他の伝搬媒体で具現化されるデータ信号を通じて、通信リンク（例えば、モデムまたはネットワーク接続）を介して、リモートコンピュータから要求しているコンピュータへと伝送されてよい。

様々な形態のコンピュータ可読媒体が、データ（例えば、一連の命令）をプロセッサへ搬送することに関与し得る。例えば、データは、（ｉ）ＲＡＭからプロセッサへ配信され得る。（ｉｉ）無線伝送媒体を介して搬送され得る。（ｉｉｉ）多くのフォーマット、規格、またはプロトコルに従ってフォーマットされ得る、および／または送信され得る。および／または、（ｉｖ）当技術分野において良く知られている様々なやり方の任意のもので暗号化され得る。

コンピュータ可読媒体は、これらの方法を実行するのに適切な、それらのプログラム要素を（任意の適切なフォーマットで）格納することができる。

示されるように、メインメモリ７０６は、本明細書にて説明された機能性をサポートするアプリケーション７２２により符号化される（アプリケーション７２２は、本明細書にて説明されるＣＤサービスの機能性のいくつか、または全てを提供するアプリケーションであり得る）。アプリケーション７２２（および／または、本明細書にて説明されるその他のリソース）は、本明細書にて説明される様々な実施形態に従った処理機能をサポートする、データおよび／または論理命令のようなソフトウェアコード（例えば、メモリまたはディスクのような別のコンピュータ可読媒体に格納されたコード）として具現化され得る。

１つの実施形態のオペレーションの間、アプリケーション７２２の論理命令を起動するため、動作させるため、実行するため、解釈するため、またはそうでなければ行うために、プロセッサ７０４がバス７０２を使用してメインメモリ７０６にアクセスする。アプリケーション７２２の実行は、このアプリケーションに関連するサービスの処理機能を生成する。言い換えると、プロセス７２４は、コンピュータシステム７００のプロセッサ７０４内で、またはプロセッサ７０４上で実行している、アプリケーション７２２の１または複数の部分を表す。

本明細書にて説明されたようなオペレーションを実行するプロセス７２４に加えて、本明細書のその他の実施形態が、アプリケーション７２２自身（すなわち、実行されない、または、実行しない論理命令および／またはデータ）を含むことに留意すべきである。アプリケーション７２２は、ディスクのようなコンピュータ可読媒体（例えば、レポジトリ）または光学媒体に格納され得る。その他の実施形態に従うと、アプリケーション７２２はまた、ファームウェア、リードオンリメモリ（ＲＯＭ）のようなメモリタイプのシステムに格納されることもできる。または、この例のように、メインメモリ７０６内（例えば、ランダムアクセスメモリまたはＲＡＭ内）の実行可能なコードとして格納されることもできる。例えば、アプリケーション７２２はまた、リムーバブルストレージ媒体７１０、リードオンリメモリ７０８、および／または、大容量ストレージデバイス７１２に格納されてもよい。

当業者は、コンピュータシステム７００が、ハードウェアリソースの割り当ておよび使用を制御するオペレーティングシステムのような、その他のプロセスおよび／またはソフトウェアおよびハードウェアコンポーネントを含み得ることを理解するだろう。

本明細書にて説明されるように、本発明の実施形態は、様々なステップまたはオペレーションを含む。これらの様々なステップは、ハードウェアコンポーネントによって実行されてよい。または、これらの命令によってプログラムされた汎用または特定用途向けプロセッサにこれらのオペレーションを実行させるために使用され得る、機械実行可能な命令中に具現化されてよい。代替的に、これらのステップは、ハードウェア、ソフトウェア、および／またはファームウェアの組み合わせによって実行されてよい。"モジュール"という用語は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせを含むことのできる、自己完結型の機能的構成要素を指す。

当業者は、この記載を読めば、装置の実施形態が、説明されたプロセスの（必ずしも全てでなくてよいが）いくつかを実行するように動作可能なコンピュータ／コンピューティングデバイスを含み得ることを、容易に認識および理解するだろう。

プログラムまたはデータ構造を格納するコンピュータ可読媒体の実施形態は、実行された場合に、説明されたプロセスの（必ずしも全てでなくてよいが）いくつかをプロセッサに実行させることのできるプログラムを格納するコンピュータ可読媒体を含む。

本明細書にてプロセスが説明される場合、当業者は、ユーザの介入無く、このプロセスが動作し得ることを理解するだろう。別の実施形態において、このプロセスは、いくつかの人間の介入を含む（例えば、人間の支援により、または人間の支援を用いてステップが実行される）。

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

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

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

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

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

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

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

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

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

Claims (16)

1. コンテンツ配信ネットワーク（ＣＤＮ）中のデバイスにおいて動作可能な、コンピュータによって実施される方法であって、前記ＣＤＮは、少なくとも１つのコンテンツプロバイダの代わりにコンテンツを配信し、前記少なくとも１つのコンテンツプロバイダに関連した前記コンテンツは少なくとも１つのプロパティを含み、前記デバイスはコンテンツ配信（ＣＤ）サービスを実行し、
   前記方法は、前記デバイスにおける前記サービスにより、
   （Ａ）前記ＣＤサービスにプロパティ無効化情報を保持する段階であって、前記プロパティ無効化情報は、前記ＣＤサービスによって処理されるそれぞれのプロパティに対し、１または複数のグループ無効化コマンドのリストを含む、保持する段階と、
   （Ｂ）前記ＣＤサービスが特定のプロパティに対する少なくとも１つの新たなグループ無効化コマンドを受信することに応答して、
   （Ｂ）（１）前記特定のプロパティに対する１または複数のグループ無効化コマンドの前記リストのサイズが特定の閾値を超えない場合、前記リストに前記新たなグループ無効化コマンドを挿入することによって、さもなければ、
   （Ｂ）（２）前記特定のプロパティに対する１または複数のグループ無効化コマンドの前記リストのサイズが特定の閾値を超える場合、（ｉ）結合された無効化コマンドを形成すべく１または複数の無効化コマンドを結合することであって、前記結合することが、結合される前記無効化コマンドの共通プレフィックスの長さに基づいている、結合すること、（ｉｉ）前記結合された無効化コマンドを前記リストに挿入すること、および、（ｉｉｉ）前記リストから前記１または複数の無効化コマンドを除去することによって、
   前記プロパティ無効化情報に対して前記新たなグループ無効化コマンドを追加することを試みる段階と、
   を有する、方法。
2. （Ｃ）前記ＣＤサービスにおいて、それぞれのプロパティリストにおける無効化コマンドに対してプロパティ毎の共通プレフィックスリストを保持する段階であって、前記結合することが、どの無効化コマンドを結合すべきかを判断するために前記共通プレフィックスリストを使用する、保持する段階をさらに有する、請求項１に記載の方法。
3. 前記プロパティ毎の共通プレフィックスリストは、１または複数の影響の仮定に基づいて、最小の影響から最大の影響の順にソートされる、請求項２に記載の方法。
4. 新たな無効化パターンが受信された場合、前記新たなパターンは、複数のパターンの既存の前記リストに対してチェックされ、共通プレフィックスが見出された場合、前記共通プレフィックスが選択的に前記共通プレフィックスリストに追加される、請求項２に記載の方法。
5. グループ無効化コマンドが制約パターンを含む、請求項１から請求項４のいずれか１項に記載の方法。
6. 前記制約パターンはグロブパターンを含む、請求項５に記載の方法。
7. （Ｄ）前記ＣＤサービスにおいて受信された、特定のリソースに対するリクエストに応答して、前記特定のリソースのコピーが前記ＣＤサービスのキャッシュに存在する場合、
   （Ｄ）（１）前記ＣＤサービスにおける前記プロパティ無効化情報を使用して、前記特定のリソースが有効どうかを判断する段階と、
   （Ｄ）（２）段階（Ｄ）（１）における前記判断することに基づいて、前記特定のリソースが有効ではないと判断された場合、前記特定のリソースの有効なバージョンを取得する段階、および、前記リクエストに対する応答を前記特定のリソースの前記有効なバージョンに基づかせる段階と、
   をさらに有する、請求項１から請求項６のいずれか１項に記載の方法。
8. １または複数のグループ無効化コマンドの前記リストは、ソートされた順序でプレフィックスリストを保持するデータ構造を含む、請求項１から請求項７のいずれか１項に記載の方法。
9. 前記データ構造は、最小の影響から最大の影響の順にソートされた前記プレフィックスリストを保持する、請求項８に記載の方法。
10. １または複数のグループ無効化コマンドの前記リストにおけるそれぞれの無効化コマンドは、制約および最小オリジンバージョン（ＭＯＶ）値を含み、１または複数のグループ無効化コマンドの前記リストは、ＭＯＶ順のリストである、請求項１から請求項９のいずれか１項に記載の方法。
11. （Ｂ）（２）（ｉ）における１または複数の無効化コマンドの前記結合は、結合される前記１または複数の無効化コマンドのＭＯＶ値に基づいて、前記結合された無効化コマンドに対するＭＯＶ値を決定することを含む、請求項１０に記載の方法。
12. 前記結合された無効化コマンドに対する前記ＭＯＶ値は、結合される前記１または複数の無効化コマンドの前記ＭＯＶ値のうちの最大のものに設定される、請求項１１に記載の方法。
13. 前記結合された無効化コマンドの前記制約は、前記結合することの前に既に前記リストに存在していた、請求項１０に記載の方法。
14. 前記結合された無効化コマンドの前記制約は、（Ｂ）（２）（ｉ）において結合される前記１または複数の無効化コマンドのうちの１つの制約であった、請求項１３に記載の方法。
15. コンテンツ配信ネットワーク（ＣＤＮ）中のコンピュータシステムにおいて動作可能なコンピュータプログラムであって、前記ＣＤＮは、少なくとも１つのコンテンツプロバイダの代わりにコンテンツを配信し、前記少なくとも１つのコンテンツプロバイダに関連した前記コンテンツは少なくとも１つのプロパティを含み、前記コンピュータシステムはコンテンツ配信（ＣＤ）サービスを実行し、前記コンピュータシステムの１または複数のプロセッサによる前記コンピュータプログラムの実行は、前記１または複数のプロセッサに、
    （Ａ）前記ＣＤサービスにプロパティ無効化情報を保持する動作であって、前記プロパティ無効化情報は、前記ＣＤサービスによって処理されるそれぞれのプロパティに対し、１または複数のグループ無効化コマンドのリストを含む、保持する動作と、
    （Ｂ）前記ＣＤサービスが特定のプロパティに対する少なくとも１つの新たなグループ無効化コマンドを受信することに応答して、
    （Ｂ）（１）前記特定のプロパティに対する１または複数のグループ無効化コマンドの前記リストのサイズが特定の閾値を超えない場合、前記リストに前記新たなグループ無効化コマンドを挿入することによって、さもなければ、
    （Ｂ）（２）前記特定のプロパティに対する１または複数のグループ無効化コマンドの前記リストのサイズが特定の閾値を超える場合、（ｉ）結合された無効化コマンドを形成すべく１または複数の無効化コマンドを結合することであって、前記結合することが、結合される前記無効化コマンドの共通プレフィックスの長さに基づいている、結合すること、（ｉｉ）前記結合された無効化コマンドを前記リストに挿入すること、および、（ｉｉｉ）前記リストから前記１または複数の無効化コマンドを除去することによって、
    前記プロパティ無効化情報に対して前記新たなグループ無効化コマンドを追加することを試みる動作と、
    を実行させる、コンピュータプログラム。
16. コンテンツ配信ネットワーク（ＣＤＮ）におけるデバイスであって、前記ＣＤＮは、少なくとも１つのコンテンツプロバイダの代わりにコンテンツを配信し、前記少なくとも１つのコンテンツプロバイダに関連した前記コンテンツは少なくとも１つのプロパティを含み、前記デバイスはコンテンツ配信（ＣＤ）サービスを実行し、前記デバイスは、
    （Ａ）前記ＣＤサービスにプロパティ無効化情報を保持し、前記プロパティ無効化情報は、前記ＣＤサービスによって処理されるそれぞれのプロパティに対し、１または複数のグループ無効化コマンドのリストを含み、
    （Ｂ）前記ＣＤサービスが特定のプロパティに対する少なくとも１つの新たなグループ無効化コマンドを受信することに応答して、
    （Ｂ）（１）前記特定のプロパティに対する１または複数のグループ無効化コマンドの前記リストのサイズが特定の閾値を超えない場合、前記リストに前記新たなグループ無効化コマンドを挿入することによって、さもなければ、
    （Ｂ）（２）前記特定のプロパティに対する１または複数のグループ無効化コマンドの前記リストのサイズが特定の閾値を超える場合、（ｉ）結合された無効化コマンドを形成すべく１または複数の無効化コマンドを結合することであって、前記結合することが、結合される前記無効化コマンドの共通プレフィックスの長さに基づいている、結合すること、（ｉｉ）前記結合された無効化コマンドを前記リストに挿入すること、および、（ｉｉｉ）前記リストから前記１または複数の無効化コマンドを除去することによって、
    前記プロパティ無効化情報に対して前記新たなグループ無効化コマンドを追加することを試みる、デバイス。

Images