JP2016538669A - 通知ベースの無効化を伴うコンテンツのキャッシングのためのシステム及び方法 - Google Patents

Abstract

【課題】 本明細書では、インターネット上でのコンテンツ配信のためのシステム、デバイス、及び方法を説明する。【解決手段】 ある非限定的な実施形態では、潜在的に無限であるか又は相対的に長い有効期間値を伴う無期限のキャッシングをサポートしつつ、下位のオリジン・コンテンツが変更された場合に迅速な更新を提供することが可能な、キャッシング・モデルが提供される。一手法では、オリジン・サーバは、コンテンツ要求に対する応答にトークンを用いて注釈を付けること、例えばそれらを付加されるＨＴＴＰヘッダ内に配置することが可能である。トークンはキャッシング・プロセスをドライブすることが可能であり、コンテンツを配信するキャッシング・プロキシ・サーバ内でのその後に応答を無効化するためのハンドルとして使用可能である。トークンを使用することにより、応答内で様々な種類の依存性を表すことができ、それには制限なしデータ、データ範囲、又は応答の構築のための基本であった論理を含む。【選択図】 図４ａ

Description

本開示は一般に、分散データ処理システム及びコンピュータ・ネットワークを介したユーザへのコンテンツの配信に関し、より具体的に言えば、コンピュータ・ネットワークを介したコンテンツの配信を高速化するためにコンテンツをキャッシングするための技法に関する。

分散コンピュータ・システムは従来技術で知られている。こうした分散コンピュータ・システムの１つが、サービス・プロバイダによって動作及び管理される「コンテンツ配信ネットワーク」又は「ＣＤＮ」である。サービス・プロバイダは典型的には、第三者に代わってコンテンツ配信サービスを提供する。この種の「分散システム」は、典型的には、コンテンツ配信又は委託サイト・インフラストラクチャのサポートなどの様々なサービスを容易にするように設計されたソフトウェア、システム、プロトコル、及び技法と共に、ネットワークによってリンクされた自律コンピュータの集合を指す。このインフラストラクチャは、典型的には複数のテナント、コンテンツ・プロバイダによって共有される。インフラストラクチャは一般に、こうしたコンテンツ・プロバイダ又は他のテナントに代わって、ウェブ・ページ、ストリーミング媒体、及びアプリケーションなどのコンテンツの記憶、キャッシング、又は伝送に使用される。プラットフォームは、ＤＮＳ照会ハンドリング、提供、データの監視及び報告、コンテンツ・ターゲティング、個人化、並びにビジネス・インテリジェンスを含むが限定されない、それらと共に使用される補助技術も提供することができる。

図１に示されたような既知のシステムでは、分散コンピュータ・システム１００がコンテンツ配信ネットワーク（ＣＤＮ）として構成され、インターネットを中心に分散された機械１０２のセットを有する。典型的には、ほとんどの機械はインターネットの縁部付近、すなわちエンド・ユーザ・アクセス・ネットワーク又はその近傍に配置されたサーバである。ネットワーク・オペレーション・コマンド・センター（ＮＯＣＣ）１０４を使用して、システム内の様々な機械の動作を処理及び管理することができる。ウェブ・サイト１０６などのコンテンツ・プロバイダと提携している第三者サイトは、分散コンピュータ・システム１００への、及び特に（時には「エッジ」サーバと呼ばれる）ＣＤＮサーバへの、コンテンツ（例えば、ＨＴＭＬ又は他のマークアップ言語ファイル、埋め込まれたページ・オブジェクト、ストリーミング媒体、ソフトウェア・ダウンロードなど）の配信をオフロードする。こうしたサーバはまとめて、特定の地理的位置でポイント・オブ・プレゼンス（ＰＯＰ）１０７にグループ化することができる。

ＣＤＮサーバは、典型的には、インターネット上でパブリックにルーティング可能なノードに、モバイル・ネットワーク内に配置されたノード内又はノードの近傍に、企業ベースの専用ネットワーク内又は専用ネットワークの近傍に、或いはそれらの組み合わせに配置される。

典型的には、コンテンツ・プロバイダは、所与のコンテンツ・プロバイダ・ドメイン又はサブドメインを、サービス・プロバイダの権威あるドメイン名サービスによって管理されるドメインへとエイリアス化することによって（例えばＤＮＳ ＣＮＡＭＥによって）、それらのコンテンツ配信をオフロードする。サーバ・プロバイダのドメイン名サービスは、コンテンツをより確実及び効率的に取得するために、コンテンツを所望するエンド・ユーザ・クライアント機械１２２を分散コンピュータ・システムに（又はより具体的には、プラットフォーム内のＣＤＮサーバのうちの１つに）導く。ＣＤＮサーバは、例えばローカル・キャッシュから、別のＣＤＮサーバから、コンテンツ・プロバイダに関連付けられたオリジン・サーバ１０６から、又は他のソースから要求されたコンテンツをフェッチすることによって、クライアント要求に応答する。

キャッシュ可能なコンテンツの場合、ＣＤＮサーバは典型的には、各キャッシュ可能オブジェクトに対して有効期間（ＴＴＬ）を設定することに依拠するキャッシング・モデルを採用する。これがフェッチされた後、オブジェクトが典型的にはオリジン・サーバ１０６から再有効化又は再フェッチされる時点であるＴＴＬが満了するまで、オブジェクトを所与のＣＤＮサーバにローカルに記憶することができる。キャッシュ不能オブジェクト（時には「動的」コンテンツと呼ばれる）の場合、オブジェクトがクライアントによって要求されるごとに、ＣＤＮサーバは典型的にはオリジン・サーバ１０６に戻らなければならない。ＣＤＮは、オリジン・サーバ１０６よりもクライアント要求を取り扱うＣＤＮサーバに近い様々なＣＤＮサーバ内の顧客コンテンツの中間キャッシングを提供するために、サーバ・キャッシュ階層を動作させることが可能であって、こうしたキャッシュ階層サブシステムの１つが米国特許第７３７６７１６号に記載されており、その開示は参照により本明細書に組み込まれている。

図１には詳細に示されていないが、分散コンピュータ・システムは、ＣＤＮサーバから使用量及び他のデータを収集し、そのデータを領域又は領域のセット全体にわたって集約し、監視、ロギング、警告、課金、管理、並びに他の動作及び処理機能を容易にするためにそのデータを他のバックエンド・システム１１０、１１２、１１４、及び１１６に渡す、分散データ収集システム１０８などの他のインフラストラクチャも含むことができる。分散ネットワーク・エージェント１１８は、ネットワーク並びにサーバ・ロードを監視し、ネットワーク、トラフィック、及びロード・データをＤＮＳ照会ハンドリング機構１１５に提供する。分散データ移送機構１２０を使用して、制御情報（例えば、コンテンツを管理するため、ロード・バランシングを容易にするためなどのメタデータ）をＣＤＮサーバに分散することができる。ＣＤＮは、米国特許第７４７２１７８号に記載されており、その開示が参照により本明細書に組み込まれているような、ＣＤＮサーバにアクセス可能なネットワーク・データセンタ内に配置可能であり、コンテンツのソースとして動作可能な、ネットワーク・ストレージ・サブシステム（本明細書では時には「ＮｅｔＳｔｏｒａｇｅ」と呼ばれる）を含むことができる。

図２に示されるように、ＣＤＮ内の所与の機械２００は、１つ又は複数のアプリケーション２０６をサポートする（Ｌｉｎｕｘ又は変形などの）オペレーティング・システム・カーネル２０４を実行する商品ハードウェア（例えばマイクロプロセッサ）２０２を備える。例えばコンテンツ配信サービスを容易にするために、所与のマシンは典型的には、（ハイパーテキスト転送プロトコル）ＨＴＴＰプロキシ２０７、ネーム・サーバ２０８、ローカル監視プロセス２１０、分散データ収集プロセス２１２などのアプリケーションのセットを実行する。ＨＴＴＰプロキシ２０７（本明細書では時にはグローバル・ホスト又は「ゴースト」と呼ばれる）は典型的には、機械からのコンテンツのキャッシュ及び配信を管理するためのマネージャ・プロセスを含む。ストリーミング媒体の場合、機械は、サポートされる媒体フォーマットによって必要とされる、ウィンドウズ・メディア・サーバ（ＷＭＳ）又はＦｌａｓｈサーバなどの１つ又は複数の媒体サーバを含むことができる。

図２に示される所与のＣＤＮサーバは、好ましくはドメイン固有、コンテンツ・プロバイダ固有ベースで、好ましくは構成システムを使用してＣＤＮサーバに分散された構成ファイルを使用して、１つ又は複数の拡張コンテンツ配信機能を提供するように構成可能である。所与の構成ファイルは、好ましくはＸＭＬベース（拡張マークアップ言語ベース）であり、１つ又は複数の高度なコンテンツ・ハンドリング機能を容易にするコンテンツ・ハンドリング規則及び指示のセットを含む。構成ファイルは、データ移送機構を介してＣＤＮサーバに配信することができる。本明細書によってコンテンツが参照により組み込まれている米国特許第７２４０１００号は、ＣＤＮサーバ・コンテンツ制御情報を配信及び管理するための有用なインフラストラクチャについて記載しており、この制御情報及び他の制御情報（時には「メタデータ」と呼ばれる）は、ＣＤＮサービス・プロバイダ自体、又は（エクストラネットなどを介して）オリジン・サーバを操作するコンテンツ・プロバイダ顧客によって、提供することができる。参照により本明細書に組み込まれている米国特許第７１１１０５７号は、ＣＤＮマシンからコンテンツをパージするためのアーキテクチャについて記載している。ＣＤＮプラットフォームに関するより詳細な情報は米国特許第６１０８７０３号及び第７５９６６１９号で見ることが可能であり、その教示は本明細書によってそれらの全体が参照により組み込まれている。

典型的な動作において、コンテンツ・プロバイダは、ＣＤＮによってサービスが提供されることを希望するコンテンツ・プロバイダ・ドメイン又はサブドメインを識別する。ＣＤＮサービス・プロバイダは、（例えば正規名又はＣＮＡＭＥ、或いは他のエイリアス技法を介して）コンテンツ・プロバイダ・ドメインをＣＤＮホスト名に関連付け、その後ＣＤＮプロバイダは、そのＣＤＮホスト名をコンテンツ・プロバイダに提供する。コンテンツ・プロバイダ・ドメイン又はサブドメインに対するＤＮＳ照会がコンテンツ・プロバイダのドメイン名サーバで受信されると、それらのサーバはＣＤＮホスト名を戻すことで応答する。そのネットワーク・ホスト名はＣＤＮを指示し、その後そのホスト名はＣＤＮネーム・サービスを介して解決される。そのため、ＣＤＮネーム・サービスは１つ又は複数のＩＰアドレスを戻す。要求側クライアント・アプリケーション（例えばブラウザ）は、その後（例えばＨＴＴＰ又はＨＴＴＰＳを介して）ＩＰアドレスに関連付けられたＣＤＮサーバ機械にコンテンツを要求する。要求は、元のコンテンツ・プロバイダ・ドメイン又はサブドメインを含むホスト・ヘッダを含む。ホスト・ヘッダを伴う要求を受信すると同時に、ＣＤＮサーバはその構成ファイルをチェックして、要求されたコンテンツ・ドメイン又はサブドメインが実際にＣＤＮによってハンドリングされているかどうかを決定する。ハンドリングされている場合、ＣＤＮサーバは、構成に指定されているようにそのドメイン又はサブドメインに関するそのコンテンツ・ハンドリング規則及び指示を適用する。これらのコンテンツ・ハンドリング規則及び指示は、前述のようにＸＭＬベースの「メタデータ」構成ファイル内に配置可能である。

ＣＤＮプラットフォームは、通信効率が改善され得るインターネット全体にわたるオーバーレイとみなすことができる。オーバーレイ上の改善された通信は、ＣＤＮサーバがオリジン・サーバ１０６から、又は中間キャッシュ・ペアレントとして動作している別のＣＤＮサーバから、要求されたコンテンツを取得する必要がある場合、或いは、コンテンツ・プロバイダに代わって、又は別の方法で、オーバーレイ全体にわたるキャッシュ不能コンテンツの通信を高速化する場合に役立ち得る。ＣＤＮサーバ間及び／又はオーバーレイ全体にわたる通信は、ルート選択、ＴＣＰ強化を含むプロトコル最適化、持続的接続のプーリング及び再使用、コンテンツ及びヘッダ圧縮並びに重複排除、並びに、とりわけその開示が参照により本明細書に組み込まれている米国特許第６８２０１３３号、第７２７４６５８号、第７６０７０６２号、及び第７６６０２９６号に記載されたような他の技法を使用して、強化又は改善することができる。

通信の強化及び高速化をもたらすオーバーレイとして、ＣＤＮサーバ・リソースを使用して、企業データ・センター間及び／又は（非公開で管理可能な）支店本店オフィス間での、並びに企業ユーザによって使用される第三者サービス型ソフトウェア（ＳａａＳ）プロバイダとの間の、ワイド・エリア・ネットワーク（ＷＡＮ）高速化サービスを容易にすることができる。

これらのラインに沿って、ＣＤＮ顧客は、顧客の企業ファイアウォール内でホストされているイントラネット・ウェブ・アプリケーションを高速化するため、並びに、ファイアウォール内のユーザ間においてインターネット・クラウド内でホストされているアプリケーションへの（例えばＳａａＳプロバイダからの）橋渡しをするウェブ・アプリケーションを高速化するために、「ファイアウォール内(behind the firewall)」管理サービス製品に加入することができる。

これらの２つの使用ケースを達成するために、ＣＤＮソフトウェアは、１つ又は複数の顧客データ・センター内でホストされている（潜在的には顧客ハードウェア上で実行する仮想機械内の）機械上、及びリモートの「支店オフィス」内でホストされている機械上で、実行可能である。顧客データ・センター内で実行しているＣＤＮソフトウェアは、典型的にはサービス構成、サービス管理、サービス報告、リモート管理アクセス、顧客ＳＳＬ証明書管理、並びに構成済みウェブ・アプリケーションに関する他の機能を提供する。支店オフィス内で実行しているソフトウェアは、そこに配置されているユーザに、ラスト・マイル・ウェブ高速化を提供する。ＣＤＮ自体は典型的には、顧客ファイアウォール内で実行しているノードと、ＣＤＮサービス・プロバイダの他のインフラストラクチャ（例えばネットワーク及び運営施設）との間にゲートウェイを提供するために、ＣＤＮデータ・センター内でホストされているＣＤＮハードウェアを提供する。この種の管理ソリューションは、自社のイントラネットに関してＣＤＮ技術を活用して、ワイド・エリア・ネットワーク最適化ソリューションを提供するための機会を企業に提供する。この種のソリューションは、企業に対する高速化をインターネット上のどこにでもサービスを提供するアプリケーションへと拡大する。企業のＣＤＮベースの専用オーバーレイ・ネットワークと、既存のＣＤＮ公衆インターネット・オーバーレイ・ネットワークとを橋渡しすることによって、リモートの支店オフィスにいるエンド・ユーザはエンドツーエンドの高速化されたアプリケーションを取得する。図３は、あり得るオーバーレイ全体にわたるデータ・フローの例と共に、前述のようなＷＡＮ最適化された「ファイアウォール内」サービス提供に関する一般的なアーキテクチャを示す。ファイアウォール内サービス提供に関する他の情報は、米国特許第７６０００２５号の教示内に見ることが可能であり、その教示は本明細書によって参照により組み込まれている。

現在ＣＤＮで使用されているような既知の技法は多くの利点を提供するが、インターネット上のトラフィックの増加する重要な部分である、ノーストア又は明示的ＴＴＬキャッシング手法が準最適な、トラフィックをより良く高速化するための技法が求められている。アプリケーション・プログラマ・インターフェース（ＡＰＩ）を介してアクセスされるコンテンツは、こうしたトラフィックの一例である。上記を序論として、本開示の主題である改良されたシステム、方法、及び装置を以下で説明する。

本開示はとりわけ、インターネット上でのコンテンツの配信のためのシステム、デバイス、及び方法を説明する。既知の有効期間（ＴＴＬ）ベースのキャッシング及びノーストア手法を向上させる、キャッシング・モデルを説明する（但し以下で説明するように、こうした技法は本明細書の教示と共に使用可能である）。本明細書で説明する手法は、無期限のキャッシングをサポートすることが可能でありながら、下位のオリジン・コンテンツが変更されるとすぐに更新し、それらをとりわけアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して取り出されるコンテンツに適合したものとするが、これに限定されるものではない。

例えば一実施形態において、オリジン・サーバは、クライアント・コンテンツ要求に対する応答にトークンの形の識別子を用いて注釈を付けるようにプログラミング可能である。（ＡＰＩの場合、オリジン・サーバ上で実行するＡＰＩは、ＡＰＩに対して行われたクライアント要求への応答にトークンを用いて注釈を付けるようにプログラミング可能である。）トークンは、配信プラットフォーム内のキャッシング・プロキシ・サーバ内で、オリジン応答をキャッシングするプロセスをドライブすることができる。発行された応答に関するＴＴＬは、無限であるか又は相対的に長いものとみなすことが可能であり、プロキシ内にキャッシュされた応答からの高速化を可能にする。その後、トークンをハンドルとして使用し、以前の応答を無効にすることができる。

好ましくは、トークンは、オリジンで応答を作成するために使用されるデータ又は論理に対応するか又はこれを示すことが可能である。例えば、オリジンでのコンテンツ生成をドライブするデータベース内の特定のレコードは、トークンに対応し得る。トークンは、オリジンでのファイル又は他のデータにも対応し得る。こうしたレコード、ファイル、又は他のオリジン・データが更新された場合、トークンに関する無効化アサーションを（例えばオリジンから）発行し、適切なプロキシ・キャッシュに伝搬することができる。そして、当該トークンでタグ付けされたプロキシ・キャッシュ内の応答は変更されたデータに依存するため、それらの応答を無効化することが可能である。トークンは任意のアイテム又はデータ・セットに対応し得るものであるため、手法は、オリジン・データベース構造及びコンテンツ生成インフラストラクチャに関してフレキシブルである。

トークンは、様々な他の方法で使用可能である。例えばトークンを使用して、応答を作成するためにデータの選択又は分類アルゴリズムが使用された旨を示すことができる。後に、応答内のデータの選択又は分類が期限切れになったときに、応答を無効にするためのハンドルとして「選択／分類」トークンを使用することができる。このようにトークンは、オリジンで適用され応答内に表現された論理を示すことができる。

更なる例として、トークンは、特定の構文スタイルで値の範囲を表現することによって、「範囲」トークンとみなすこともできる。応答には、例えば応答が関わる値の範囲を示す範囲トークンでタグ付けすることができる。以前に列挙された範囲トークンの範囲内にある特定の値を後に無効化することによって、それらの範囲トークン及びそれらが接続された応答を無効にすることができる。

本明細書で説明する主題は、コンテンツの配信及びオンライン・プラットフォーム・アーキテクチャにおける多種多様な適用例を有し、ＣＤＮのサービス及び技術と共に使用可能である。

当業者であれば理解されるように、上記の説明は序論を提供するために単に本発明の例に言及するものである。他の実施形態は本書の残りの部分で説明する。上記は限定的なものではなく、その教示は様々なシステム、方法、装置、及び持続性コンピュータ可読媒体内で実現可能である。本明細書に記載された機能は、異なる機械間で様々な方法で組み合わせるか又は分割することが可能であるため、特定の機械への機能の割り振りは限定的なものではないことにも留意されたい。

本発明は、添付の図面に関連した以下の詳細な説明からより完全に理解されよう。

コンテンツ配信ネットワークとして構成された既知の分散コンピュータ・システムの一実施形態を示す概略図である。 図１のシステム内のコンテンツ配信サーバが実装可能な機械の一実施形態を示す概略図である。 オーバーレイＣＤＮプラットフォーム全体にわたるメッセージ・フロー及び高速化の一実施形態を示す概略図である。 本明細書の教示を活用するキャッシング技法を使用してコンテンツの配信を高速化する例示のシステムにおける、メッセージ・フローの一実施形態を示す概略図である。 本明細書の教示を活用するキャッシング技法を使用してコンテンツの配信を高速化する例示のシステムにおける、メッセージ・フローの別の実施形態を示す概略図である。 ＡＰＩコンテンツを高速化する場合の、ＡＰＩ応答間の関係の例及び下位のＡＰＩデータベースの例を示すブロック図である。 本発明の教示に従った、ホログラム・ノードの例示ネットワーク及びノード間のメッセージング・フローを示す概略図である。 図６に示されたネットワークの例示のネットワーク状態を示す概略図である。 キャッシング・サーバの階層状配置構成でのメッセージ・フローの例を示す概略図である。 キャッシング・サーバの階層状配置構成でのメッセージ・フローの例を示す概略図である。 キャッシング・サーバの階層状配置構成でのメッセージ・フローの例を示す概略図である。 キャッシング・サーバの階層状配置構成でのメッセージ・フローの例を示す概略図である。 キャッシング・サーバの階層状配置構成でのメッセージ・フローの例を示す概略図である。 図６〜図７に示されるノードに関するソケット・セット設計の例を示す概略図である。 図９に示されるソケット・セット設計を使用する３つのノードに関する例示のネットワーク状態を示す概略図である。 本明細書の教示を実装するために使用可能なコンピュータ・システム内のハードウェアを示すブロック図である。

以下の説明は、本明細書で開示される方法及び装置の構造、機能、製造、及び使用の原理を全面的に理解するための、本発明の実施形態を示す。本明細書で説明され添付の図面に示されるシステム、方法、及び装置は非限定的な例であり、特許請求の範囲のみが求められる保護の範囲を定義する。例示の一実施形態に関連して説明又は図示された特徴は、他の実施形態の特徴と組み合わせることができる。こうした修正及び変形は、本発明の範囲内に含められることが意図される。本明細書に記載されたすべての特許、公開、及び参照は、それらの全体が参照により本明細書に明白に組み込まれている。原文「ｅ．ｇ．」という略語は、本明細書において非限定的な句「例えば」の省略形として使用される。

本開示によれば、サーバの機能は、無期限のキャッシング期間、別の言い方をすれば、期間満了ベースの無効化に代わる、又はそれを補足する通知ベースの無効化をサポートするキャッシング・システムを使用して、コンテンツの高速化を提供するように修正される。サーバは、典型的には本明細書の教示に従って修正されたキャッシング・プロキシ・サーバであり、分散ＣＤＮプラットフォームの一部とすることができる。

本明細書で説明する技法は、ある実施形態において、様々な種類のトラフィックに対して改良された高速化を提供することが可能であり、（限定はしないが）特にＡＰＩトラフィックに有用である。本開示は、製品化されたＡＰＩの高速化を可能にするように、コンテンツ・プロバイダ顧客がそのユーザにＡＰＩを与え、そのＡＰＩを介して配信された要求／応答がＣＤＮを介して搬送及び高速化されるような、ＡＰＩトラフィックのキャッシングに対する手法を説明する。具体的な例及び例示を提供するために本明細書ではしばしばＡＰＩ使用ケースが用いられるが、本明細書の教示はＡＰＩトラフィックに限定されない。通知ベースの無効化を伴う無期限のキャッシングから恩恵を受けることが可能ないずれのトラフィックも、本明細書の教示から恩恵を受けることが可能である。恩恵は様々であり得るが、本明細書の教示は任意の種類のオブジェクトの配信に関して使用可能である。

一実施形態において、システムは前述のＣＤＮプロキシ・サーバなどのキャッシング・プロキシ・サーバのセットを採用し、これらのキャッシング・プロキシ・サーバは本明細書の教示に従って修正される。こうした修正済みサーバは本明細書では「ホログラム」サーバと呼ばれることがあり、これは、システムとデータベースの信頼できるコピーをこれらの教示では必要としない（が適合性もある）ＣＤＮシステム自体の中に配置することとを区別するために、「データベースのホログラムをネットワーク内に投影する」ことから着想を得たニーモニックである。

いくつかの実装において、ホログラム・サーバは、例えば、ネットワーク・エッジに配備されたＣＤＮプロキシ・サーバの最前線に対するキャッシュ親として働くことによって、（例えば、本明細書で説明するキャッシング及び高速化機能を提供しない）他のＣＤＮプロキシ・サーバの補足で使用可能であることに留意されたい。

動作時、顧客のオリジン・インフラストラクチャは、好ましくはある非標準ＨＴＴＰヘッダ内でＡＰＩ応答と共に１つ又は複数のトークン（タグと呼ばれることがある）を発行することができる。これはオリジン・プログラミングに対する調整である。トークンは、ＣＤＮプラットフォーム内及び特にホログラム・サーバで、これらのＡＰＩ応答のキャッシング及び無効化のプロセスをドライブする。オリジンによって発行されるトークンは、ＡＰＩ応答で使用されるいくつかのデータを記録する。ＡＰＩ応答に関するＴＴＬは、これらの応答について無期限（又は非常に長い、例えば１年）であるものとみなすことが可能であり、それらをキャッシュできるようにする。後にオリジンはトークンごとに無効化し、潜在的には多数の以前のＡＰＩ応答を無効化する。

トークンはキャッシュ・ハンドリング指示として使用可能であり、応答コンテンツがキャッシュ内に存在し、下位のオリジン・データが静穏な場合長期間サービスするために有効を維持し、その後オリジンでの突然の変更に応答して迅速に更新することが可能である。この手法は、現在はキャッシュ不能の動的オブジェクトを高速化するための主要な手法である、ノーストアでもＴＴＬベースでもないキャッシングをサポートすることが可能であり、最終的に一致する（しかし好ましくは迅速に一致する）データ・モデルを与える。手法はデータベースにとらわれず、コンテンツ・プロバイダの顧客がオリジンで好むいずれかのＳＱＬ又はＮｏＳＱＬデータベースを利用できるようにする。

トークンは様々なことを示すことができる。一般的なケースでは、トークンは所与のＡＰＩ応答に現れるか又はこれを構築する際に使用された、データの項目に関連付けられる。こうしたトークンは、ＡＰＩの下位にあるオリジン・データベースにおけるその所与のデータ・トークンの変更がもはや有効でない場合、ＡＰＩ応答を（キャッシングの観点から）無効にするためのハンドルとして動作することができる。したがってトークンは、下位のデータベースに対応可能であるか、又はその中に何らかの用意された同等のものを有する。例えばトークンは、オリジン・データベース内のレコードに対して１次キーを表すことが可能であり、そのレコードが変更された場合、トークンを使用してそのレコードに基づいていたそれらのＡＰＩ応答を無効にすることができる。

トークンは、データベース内のデータの実際のフィールド又は行に代わる抽象を表すことができる。したがってトークンは、オリジンで所与の応答を作成するために使用された論理を示すことができる。例えばトークンを使用して、ＡＰＩ応答がデータ分類、データ選択アルゴリズム、又は他のアルゴリズムの成果であることを示すことができる。こうしたトークンは、例えば（データ自体ではなく）データの分類又は選択が期限切れになった場合に、キャッシュされた応答を無効にするためのハンドルとして使用可能である。テーブル内の最も新しい１０項目を表す応答のケースを考えてみる。この応答はこうしたトークンを活用することができる。１０個の現在の構成項目に対してトークンを発行することで、より新しい項目が到着した時に適切に無効化が行われることはなく、より新しい項目が到着すると、１０個のオリジナル項目トークンのうちの１つではなく、このテーブルに関する分類トークンの無効化を開始することができる。

トークンは、認識される特定の構文スタイルで値の範囲を表現することによって、「範囲」トークンとみなすこともできる。応答には、例えば応答内で戻されるマップ・データに関する緯度／経度範囲などの応答が関係する値の範囲を示す、範囲トークンでタグ付けすることができる。以前に列挙された範囲トークンの範囲内の特定の値を後に無効化することで、それらの範囲トークン及びそれらが接続された応答を無効にすることができる。したがって、（マップ内の特定の座標での当該の新しい地点の追加などの）範囲内の所与の地点を更新して、以前の応答のキャッシュ無効化を開始することができる。

トークンの手段は、好ましくは、特定の応答を記録しているトークンが、応答を構築したがその後の何らかの時点で変更された可能性のあるデータ及び論理に、集合的に結び付けられるように、並びに、オリジン・システムがそれ自体の状態をどのように維持及び監視するか、ハンドルによっていくつかのデータを便宜上どのように言い表すか、及び、１つ又は複数のトークンを介してデータに対するすべての変更をどのように確実に表現するかを考慮して、後にそれらのトークンで無効化するための機能に便宜上合わせるように、選択される。

図４ａは、一実施形態の一般的な概要を提供し、ＡＰＩコンテンツのプロキシ化及びキャッシングによってオリジンに関するＡＰＩトラフィックを高速化するホログラム・サーバを示す。図４ａには２つの代替が示されている。実線は、ホログラム・サーバがクライアント要求に答え、オリジンまで直接前進するフローを示す。破線は、ホログラム・サーバがクライアント要求を受け取り、オリジンの近くの別のホログラム・サーバへと前進し、その後オリジンへと前進する別のフローを示す。結果として生じる（付加トークンを備える）応答は、オリジンから親ホログラム、子ホログラム・サーバへと下方に渡される。ホログラムはトークンと共に応答をキャッシュし、後続のクライアント要求について、トークンが依然として有効な場合、ホログラム・サーバはローカル・キャッシュから応答をサービスすることができる。典型的には、キャッシュされた応答は、その関連付けられたトークンのいずれかが無効化されている場合、後続のクライアントにサービスするのには無効であると見なすことができる。

図４ｂは、ホログラム・サーバが（ホログラム機能を有していない）他のＣＤＮプロキシ・サーバをサポートして配備され、キャッシュ階層機能をそれらの他のＣＤＮプロキシ・サーバに提供する、別の実施形態を示す。図４ｂにおいて、非ホログラムＣＤＮプロキシ・サーバはクライアント要求に答え、オリジンに直接戻すのではなく、応答を求めるためにホログラム・サーバへの転送要求を出す。ホログラム・サーバは、（キャッシュされた応答が有効な場合）それらのキャッシュから応答するか、要求を別のホログラム・サーバへと転送するか、要求を（最終的にオリジンに転送するために）ＣＤＮプロキシに転送するか、又は要求をオリジンに直接転送する。

図５は単なる例として、ＡＰＩ応答、オリジン・データベース内のレコードを表すトークンの間の関係の例を示す。図５では、キー１に関連付けられたレコードが更新されたため、データ・トークン１が無効化されている例が示されている。この場合、システム内でのデータ・トークン１の無効化は、ＡＰＩ応答Ａ及びＡＰＩ応答Ｂが両方ともデータ・トークン１に依存しているため、それらの両方がキャッシュ内で無効化されることを意味する。

好ましい実装において、システムはＣＤＮに組み込まれ、データベースをホストし、ＡＰＩからのデータの権威あるソースとして働くオリジン・インフラストラクチャから分離される。しかしながら本明細書の教示は、ＣＤＮサービスの外部での実装にも適用される。

アプリケーション・プログラマ・インターフェース（ＡＰＩ）
ＡＰＩ、すなわちアプリケーション・プログラマ・インターフェースは、典型的にはしばしばそれら自体の組織の外部で、１チームのプログラマによって別のチームに対して作られたサービス、データベース、又はシステムを取り囲むラッパーである。いくつかのＡＰＩは公共消費のために作られ、いくつかのＡＰＩは組織機能として会社の様々なチームによる内部使用のために作られる。ＡＰＩは一般に、不必要な細部のカプセル化を促し、ビジネス論理及び最良実施を強制する。ＡＰＩはしばしば、理解するのはＡＰＩのみで他には一切必要ないため、ＡＰＩ無しよりもかなり簡略的な、システム又はエコシステムに大きく寄与させるための「焦点化エージェント」として働く。

一般的な技術シーンでは、ＡＰＩはしばしば、どのように挙動するかに関する定義及び通常は戻すことになるデータを備えている、呼び出しのドキュメント化されたセットとしてしばしば了解される。ウェブとの関連において、ＡＰＩはしばしば、ウェブ・サーバ・システムの内部及びシステムに接続された状態で動作し、情報をウェブ・クライアントに戻すか、又はアクションを起こして結果をウェブ・クライアントに報告することになる、あるドメイン又はＵＲＬ経路で理解されたＨＴＴＰ要求のパターンを備える。

ウェブ・クライアントは、ウェブ・ブラウジングのケースのように、情報が戻されたときに単に直接表示又はレンダリングすることはそれほど多くはなく、むしろ何らかの論理を使用し、データに対してプログラマティックに動作することになる。しばしばその論理はＪａｖａＳｃｒｉｐｔで、或いはクライアント・アプリケーションに生来的に、例えばｉＯＳ又はＡｎｄｒｏｉｄオペレーティング・システム用に作成されたようなモバイル・アプリケーションで符号化されている。このようにしてトランザクションは達成可能であるが、アプリケーション内の「ページ」上に単に情報をレイアウトすることも一般的な用法であると言うべきであり、但しこれは、技術的にはウェブ・ブラウザ・ソフトウェアの考察との関連において理解されるようなＨＴＭＬページではない可能性がある。

データはしばしば、ＧＥＴ及びＰＯＳＴ又は他のＨＴＴＰ呼び出しを使用してウェブＡＰＩ内に渡され、ＸＭＬ又はＪａｖａＳｃｒｉｐｔオブジェクト表記（ＪＳＯＮ）、他のオープン・フォーマット、或いは独自仕様のフォーマットを使用して、ウェブＡＰＩから戻される。フォーマットは一般に、コンピュータにとって解析しやすいように設計される。

例示のＡＰＩ呼び出し
多くのＡＰＩワークは、ＳＱＬデータベース照会からＸＭＬ又はＪＳＯＮをもたらすＲＥＳＴ呼び出しのラッパーである。時には照会はきわめて複雑であるか、又は一連の照会が単一の応答のために実行される。時にはアプリケーション層キャッシングは性能に関わる。

例えば、以下のような、ドメインapi.flight-example.comに対する航空会社のフライト・ステータス検索について考えてみる。
GET/xml/flight?id=12345 HTTP/1.1
...

このＡＰＩ要求は、応答で以下のＸＭＬペイロードをもたらすものと想定する。
<flightInfo>
<flightId>12345</flightId>
<carrier>
<iata>AA</iata>
<name>Airy Airlines</name>
<country>US</country>
</carrier>
<number>AA100</number>
<airports>
<departure>
<iata>JFK</iata>
<name>John F. Kennedy International Airport</name>
<street1>JFK Airport</street1>
<street2/>
<cityName>New York</cityName>
<city>NYC</city>
<state>NY</state>
<postcode>11430</postcode>
<country>US</country>
<countryName>United States</countryName>
<regionName>North America</regionName>
<timezoneName>America/New_York</timezoneName>
<weatherzone>NYZ076</weatherzone>
<latitude>40.642335</latitude>
<longitude>-73.78817</longitude>
<elevationFeet>13</elevationFeet>
</departure>
<arrival>
<iata>LHR</iata>
<name>Heathrow Airport</name>
<cityName>London</cityName>
<city>LON</city>
<state>EN</state>
<country>GB</country>
<countryName>United Kingdom</countryName>
<regionName>Europe</regionName>
<timezoneName>Europe/London</timezoneName>
<latitude>51.469603</latitude>
<longitude>-0.453566</longitude>
<elevationFeet>80</elevationFeet>
</arrival>
</airports>
<status>late</status>
<times>
<departure>
<scheduled>
<local>2013-01-01T18:10:00.000</local>
<utc>2013-01-01T22:10:00.000Z</utc>
</scheduled>
<actual>
<local>2013-01-01T18:05:00.000</local>
<utc>2013-01-01T22:05:00.000Z</utc>
</actual>
</departure>
<arrival>
<scheduled>
<local>2013-01-02T06:20:00.000</local>
<utc>2013-01-02T05:20:00.000Z</utc>
</scheduled>
<actual>
<local>2013-01-02T06:09:00.000</local>
<utc>2013-01-02T05:09:00.000Z</utc>
</actual>
</arrival>
<takeoff>
<scheduled>
<local>2013-01-01T18:49:00.000</local>
<utc>2013-01-01T22:49:00.000Z</utc>
</scheduled>
<actual>
<local>2012-08-07T18:23:00.000</local>
<utc>2012-08-07T22:23:00.000Z</utc>
</actual>
</takeoff>
</times>
<codeshares>
<codeshare>
<carrier>
<iata>GF</iata>
<name>Great Air</name>
</carrier>
<flightNumber>6654</flightNumber>
</codeshare>
</codeshares>
<airportinfo>
<departureTerminal>8</departureTerminal>
<departureGate>B3</departureGate>
<arrivalTerminal>3</arrivalTerminal>
<arrivalGate>36</arrivalGate>
</airportinfo>
<equipment>
<iata>777</iata>
<name>Boeing 777 Passenger</name>
<enginetype>jet</enginetype>
<equipmentNumber>N783AN</equipmentNumber>
</equipment>
</flightInfo>

本応答は、空港及び飛行機器を含み、さらに予定及び実際のイベントに関するタイムスタンプも含む、フライトに関する情報を担持する。本要求内の情報はフライトを待っている間に変更される可能性は全くなく、その後数時間にわたってＡＰＩの任意の消費者にとってかなりリアルタイム・センシティブである変更が相次いで生じることになり、その後フライトが終了すると、データは再度永続的に静的な期間に落ち着くことになるであろう。フライトにつながる何らかの大きなデータの変更の場合、航空機、出発時間、又はターミナルといった種類のものである可能性があり、いずれの場合もこれらはできる限り即時に応答に反映されるべき変更である。

すべてのトラフィックがオリジンで終端する動的ノー・ストアＣＤＮ配信ソリューション全体にわたってこのタイプのＡＰＩ応答にサービスすることで、自己ホスティングよりも信頼性を高めることができる。ＣＤＮ内に短期間の時間ベース（ＴＴＬ）キャッシングを追加することで、オリジン・トラフィックをより許容可能にすることができるが、消費者に対するグローバルな待ち時間はＴＴＬが高い場合にのみ抑えられ、あるレベルでデータの新鮮さを打ち消す。高いＴＴＬの設定及び大規模ＣＤＮのパージ機能への訴求は、結果として、これ及び同様の使用ケースに対する満足な更新にとっては長すぎるパージ時間枠を生じさせることになる。ここではキャッシング及びパージング機能を見据える新しい方法が有用であり得、本明細書の教示によって対処される。

例示のＡＰＩ応答へのホログラム・データ・トークンの付加
ホログラム・システムは、上記のＡＰＩ例示応答のそれと同様のＡＰＩ出力を高速化することができる。

一実施形態において、オリジンＡＰＩ応答はホログラムに適合するように増補することができる。通常のヘッダとしてペイロードの前に、又はトレーラとしてペイロードの後に列挙可能な、「Ｘホログラム・データ」という名前のＨＴＴＰヘッダを追加することができる。トレーラの使用は、トレーラ内のメタデータがオリジンでのペイロード構築の副産物として生じることから有利であり得る。以下の例では、このヘッダの値はコンマ及び各コンマに続くオプションの空白によって分けられたトークンを担持し、トークンは（応答を構築するために使用される論理又は範囲ではなく）データを示す。
...
Trailer:X-Hologram-Data
...
X-Hologram-Data:flightId:12345,airport:JFK,airport:LHR,carrier:AA,flightnumber:AA100,carrier:GF,flightnum:GF6654,equipmentnumber:N783AN,equipment:777

追加されたヘッダ又はトレーラのサイズは恐らく２〜３００バイトであり、典型的にはＡＰＩ応答全体のサイズにごくわずかを追加することになるため、ホログラム・キャッシングを実行可能にする。この例では、メタデータはコンマで分けられたトークンのリストである。前述のように、様々なタイプのトークン（データ・トークン、選択／分類トークンなど）があり得て、様々なフォーマットもあり得る。このケースでは、データ照会はフライトＩＤの直接検索であったため、オリジン・データを示すトークンのみが必要であり、すべてのトークンは本質的にテーブル／１次キーの組み合わせである。

（この例では、オリジンでのテーブル名及び構造がわかっているものと想定する。これは必ずしもＡＰＩ応答のＸＭＬ内に反映されない。実際には、トークンはＡＰＩと同じ開発者によって作成されたコードによって発行可能であるため、下位のデータ方式を理解している。）

トークンは、オリジンの下位データベース内の任意のデータ・セットに関するように構築可能である。この例では、ＡＰＩをサポートしているデータベースは１次キーとしてフライトＩＤを含むフライト・テーブルを有するものと想定する。したがって、トークンをテーブル／１次キーに基づかせ、テーブル／１次キーをデータベース内に表すことが便利であるため、「table:key」の形が妥当なデフォルト・テンプレートである。

システムはフレキシブルであるが、システムは一般にトークンがオリジン・データベースにどのように関するかにとらわれない。名前が変化するか又は一定のままであるデータのバンドルをまとめて参照するための方法である限り、実際のテーブル名を使用する必要はない。完全な正規化は不要であり、データが変更された場合、このライン上に表されたトークンのうちの１つがオリジンによる影響を受けるものとみなされる限り、あらゆるテーブル関係が表される必要はない。要するに、トークンは実際の１次キーである必要はないが、好ましくはオリジンが迅速に参照し、データベース内の実際の１次キーに関係することが可能な、固有にインデックス付けされたキー又はハッシュを表す。実際には、テーブル−コロン−値構造も不要であり、正規表現「[A-Za-z0-9/:;_-」+」に一致する任意のトークンが受け入れ可能である。構文拡張を行えば、追加の特徴表現も許容できる。

このフレキシビリティは、任意の種類のデータをシステム用にトークン化できることを意味する。上記の例はＳＱＬデータベース・コンテキストに焦点を当てているが、非ＳＱＬ、ｍｅｍｃａｃｈｅ、又はファイル・システム要素までもトークンに変換することができる。（例えば、オリジンは記憶されたファイルの名前を表すトークンを有するように決定することができる。）

例に戻ると、ＡＰＩ応答は２つの空港、出発及び到着空港を参照している。トークンでは空港の関係は重要でないため、どちらが出発でどちらが到着かは記録されておらず、システムはＸＭＬの解析を試行する必要がないため、ＸＭＬへのいずれの後方参照もまったく必要ではなく、実際にこのデータ・ペイロードはＪＳＯＮ又は別のフォーマットとして符号化されている場合があることに留意されたい。

代替実施形態では、システムは、ヘッダ内のデータ・トークンを生成及び付加するためにオリジンに依拠するのではなく、ＡＰＩ応答ペイロード自体からトークンを決定することが可能である。これは、そのコンテンツ・プロバイダのＡＰＩトラフィックに対してＣＤＮ内のドメイン固有の構成の支援を伴うか又は伴わずに起こる可能性がある。ＣＤＮ内のドメイン固有の構成は、様々なペイロードを制御ヘッダ又は適切なトークンを備える等価の表現に変換するための変換命令を含む。例えば構成は、応答に埋め込まれるトークン情報を指定するある所定のパターン又はマークアップについて、ホログラム・サーバによってスキャンされることになるオリジン応答ペイロードを要求する場合がある。トークン情報は、典型的には応答から取り除かれ、ホログラム・システム内での通信のためにヘッダ又は他の等価のフィールドに変換されることになる。

別の例として、ＸＳＬＴファイルはＸＭＬ放出ＡＰＩ内の各ＵＲＬパターンに関連付けることが可能であり、応答がホログラム・サーバ（例えばオリジンに最も近いホログラム・サーバ）を介してトラバースする場合、第１の場所の応答と共に伝送された可能性のある必要なヘッダと同じであるために生じるドキュメント、又は容易に解析可能なＸＭＬフラグメントを生成するために、ＸＳＬＴは規格を遵守するようにＸＭＬに適用されることになる。同様にＪＳＯＮ応答の場合、ＪＳＯＮからの値が高くなるように進むデータ構造経路を表現するドキュメントを、ＸＬＳＴの代わりに保存することができる。

変換後、変換されたドキュメントは通常はペイロードに付随する制御データ（トークン）を提供するが、変換は必ずしもペイロードを置換することを意図していない。制御データは、通常、サーバ間で変更する必要はないため、サーバがオリジンからの制御ヘッダを正常に保持し、その後変換を実行した場合、サーバは応答をダウンストリーム要求ホログラム・サーバに戻す前に変換から導出された制御ヘッダを他のＨＴＴＰヘッダに付加することができる。したがって図４ａ（破線）との関連において、親ホログラム・サーバは、装飾された応答を子ホログラム・サーバに伝送する前に、制御データを付加することができる。

更にＡＰＩ応答におけるＸＭＬを見ていくと、タイムスタンプはフライト出発時間などのイベントに使用可能なことがわかる。これらはすべて、トークン「flightId:12345」の下のトークン・リスト内に表されるアトミック・データとみなされる。したがって、タイムスタンプが変更されるか又は新しいタイムスタンプが追加されると、オリジン・プログラミングは、トークン「flightId:12345」を有するすべての応答に影響し、（恐らくは）無効化されることが必要であることがわかるように構成される。

キャリア・コードは、各々関係するキャリア、及び関係するキャリアのフライト番号に対するトークンを列挙し、トークン・リスト内に表されている。このタイプのフライト番号は消費者フライト番号であるため、オリジンでの開発者はこれを別のテーブルに記憶させるように、及び「flightnum」テーブル指示子をトークンとして使用するように設計することができる。

最終的に、「equipmentNumber:N783AN」及び「equipment:777」トークンは、航空機自体及び飛行機（機器）のタイプについてのレコードを表す。

付加されたトークンに基づくキャッシング及びトークンの無効化
上記では、ＡＰＩ応答ペイロードを伴うオリジンからのトークンの発行と、ペイロード内にコンテンツを生じさせたオリジン・データベース内のデータ構造をトークンがどのように表すことができるかを説明した。

ＡＰＩ応答の場合、何らかの時間が表現されるＴＴＬベースのキャッシングとは異なり、キャッシュ時間は無限か又は非常に長期にわたる可能性がある。ホログラム適合応答は、いずれの構成トークンも無効化されていない限り有効である。言い換えれば、一実装において、ＣＤＮ内のＨＴＴＰプロキシ・キャッシュは、オリジンによって肯定的に無効化されるまでＡＰＩ応答を無期限にキャッシュすることができる。

上記のフライト・レコード例において、列挙された１３のトークンのうちの１つについて無効化が受信されるまで、応答ＸＭＬドキュメントはエンド・ユーザ・クライアント要求に応答してサービスするために有効であるものとみなされる。かなり長い可能性があるこの期間中、ドキュメントはネットワーク内のホログラム・サーバによってキャッシュし、キャッシュから繰り返しサービスすることができる。

代替実施形態において、ホログラム・システムは、安全対策としてオリジンを用いたトークンの定期的な再有効化を要求することが可能であり、それらの対応するデータ・トークンが安全対策として又はデータ記憶保全手段として依然として有効であるにも関わらず、ＡＰＩ応答を満了させるためにグローバルＴＴＬをオーバーレイすることも可能である。これらはどちらも本明細書の教示に適合可能である。

実施形態において、オリジンから放出された標準のキャッシュ関係ＨＴＴＰヘッダがホログラム制御ヘッダと共に表現され、したがってかなり長い期間が適切であることを考慮できるものと考えると、ホログラム・サーバはこうしたヘッダに従うことが可能である。すべての正常なＨＴＴＰヘッダに従うことは、本明細書の教示に適合する。

トークンを無効化するための多くの可能な技法が存在する。単なる例として、トークンは（ｉ）トークンに対する無効化アサーションを所与のＡＰＩ応答に含めること、又は（ｉｉ）オリジンによるトークン無効化ＡＰＩのアクティブな呼び出し（オリジンがウェブ要求のサービスとの関連外でデータを変更する場合）によって、無効化することができる。こうした「トークン無効化ＡＰＩ」は、高速化されているＡＰＩと混同されることはない。

無効化機構（ｉ）に戻ると、サーバのホログラム・ネットワークは、好ましくは任意のＡＰＩ応答の線上にある無効化を取り扱うことができる。ほとんどのケースで、ＡＰＩ応答は、そのイベントがデータベース内のレコードを変更させ、無効化を引き起こさせる限りにおいて、実際にはＡＰＩデータベースを更新するためのクライアント要求（すなわち「書き込み」メッセージ）に対する応答となる。しかしながらアーキテクチャは、データベースに書き込んでいないクライアント要求への応答に整合して無効化をサポートすることもできる。

説明すると、上記からのフライト・ステータスＡＰＩがデータへの更新も可能にすること、及び、フライトに関してＧｒｅａｔ Ａｉｒコードシェアのフライト番号を更新することになるＨＴＴＰ呼び出しを認証されたユーザがそのＡＰＩに発行したことを、例示として挙げたい。オリジンからのＡＰＩ応答、例えばＨＴＴＰ２００「ＯＫ」応答に、ホログラム無効化を含めることができる。
X-Hologram-Data:!flightnumber:AA100,!flightId:12345

この表記は、オリジナルのフライト番号及び問題のフライトに依拠する任意のドキュメントを、フライトＩＤによって無効にする。無効化は、無効化を示すための感嘆符が追加されたトークンを列挙することによってアサートされる。ホログラム・ノードは、ホログラム・ネットワークの残余部を介して無効化の伝搬を開始することに対して、又は好ましくは、以下でより詳細に説明する、所与のＡＰＩドメインについての無効化チャネルを公開するネットワーク内の発行者ノードに無効化を送信することに対して、責務を負うことができる。

無効化機構（ｉｉ）に戻ると、トークン無効化ＡＰＩ機構は、何らかの地点で１つの情報が変更されるものと想定するように動作可能である。航空機が着陸する前にＸＭＬが取り出され、その後航空機が着陸し、結果として「arrivalDate」、「status」、及び「actualArrival」というノードがＸＭＬ内で更新されるものと想定してみる。オリジンは、トークンを無効化するために、ＣＤＮネットワークへの専用及びセキュアなトークン無効化ＡＰＩ呼び出しを利用することができる。ＨＴＴＰ及び何らかの形のＡＰＩキー認可を、ここでの例にオーバーレイさせることができる。「/hologram」経路は、ＣＤＮネットワークによってサービスされるホログラム実行可能ドメインによって理解される疑似経路であろう。
POST/hologram/invalidate HTTP/1.1
...
tokens=flightID:12345

多くのケースでは、単一トークンの無効化は、ネットワーク規模の多数のＡＰＩ応答ドキュメントを潜在的に表すことが可能な、そのトークンでマーク付けされたすべての応答を無効化するように機能することができる。無効化メッセージは、ホログラムをサポートする機械全体にわたって伝搬されなければならない。この単一の無効化は、上記のＸＭＬ応答を無効化するのに十分であり得るため、結果として同じコンテンツについての後続のクライアント要求は、解決するためにオリジンへと転送される必要がある。この無効化は、フライト１２３４５に関する情報、すなわち、その様々な付加トークンの中の「flightId:12345」のトークンで以前にサービスされた任意のドキュメントに依存する、任意の他の応答も同時に無効化する。

代替の無効化例として、ロンドン・ヒースロー空港がその名前をロイヤル空港に変更したと想像してみる。無効化ＡＰＩ呼び出しは以下のようになる。
POST/hologram/invalidate HTTP/1.1
...
tokens=airport:LHR

いったん伝搬されると、この特定のＡＰＩ上のヒースローに関する情報を含む任意の応答はＣＤＮネットワーク内で無効となり、更にオリジンからの今後の応答は異なる空港名を反映することになり、クライアント要求が満たされた場合、新規の正しいデータをキャッシュ内のＣＤＮネットワークに追加することができる。

好ましくは、オリジンはトークン無効化ＡＰＩエントリポイントへの永続ＨＴＴＰ又はＳＰＤＹ接続をオープンに保持することが可能であるため、予測される一連の無効化をこの接続上で多重化することができる。

代替の実施形態において、ＷｅｂＳｏｃｋｅｔサービスを使用可能にすることが可能であり、その結果、オリジンがＣＤＮサーバ（例えばホログラム・サーバのうちの１つ又はその他）に対してＷｅｂＳｏｃｋｅｔをオープンし、以下で説明するように、ＷｅｂＳｏｃｋｅｔを使用して、増分によって無効化を暗黙的に知らせる更新済みの一連の番号を備えるトークンを担持する無効化又はメッセージを伝送することになる。

更に別の例において、オリジンによってフック・ポーリング呼び出しを要求することが可能であり、これは、オリジンが要求するためにＡＰＩを呼び出すか、又は、ドメイン固有のＣＤＮ構成が、正常なデータ担持応答内に提供する代替として、その後応答内でオリジンによって提示されることになる、任意又はすべての更新済みのトークン情報を要求する、ＣＤＮサーバからオリジンへの正規のポーリングされたＨＴＴＰ要求を規定することを意味する。

シリアル番号トークン
代替の実施形態において、トークンはシリアル番号構文を有することができる。例えば各トークンは、シリアル番号（flightID:12345.1）を伴う名前又は呼称（moniker、例えばflightID:12345）によって識別可能である。より堅固には、シリアル番号フォーマットは、＠記号とそれに続くサーバ番号、コロン、シリアル番号、コロン、及び秒単位のエポック・タイムスタンプ番号として表現されるタイムスタンプとして表現することができる。例えば割り当てられたサーバ番号２０００、１０１まで増分されたシリアル番号、及びタイムスタンプ1380679283（2013年10月1日7:01:23PDTに対応する）で、以下のようになる。
flightID:12345@2000:101:1380679010

シリアル番号構文ではなく呼称を伴うトークンの識別子は以下では「短形式」と呼び、シリアル番号構文の使用は「長形式」と呼ぶ。こうしたトークンの形式は具体的な実装を例示するための単なる例であり、限定的であることは意味しない。

シリアル番号はトークンのバージョン又は反復回数と考えることが可能であり、オリジンで対応するデータが更新されるごとにカウントが増分される。この手法は、オリジンを明白な無効化コマンド送信の必要性から解放し、代わりに現行の反復を報告するだけで良いものとすることが可能であり、ホログラム・ノードにはすべての以前のトークン反復を無効として取り扱うことがわかっているため、暗黙の無効化コマンドとして機能することができる。したがって各ＡＰＩ応答で、オリジンは関連するデータ・トークンの最新の反復を付加することができる。この無効化機構は、前述のトークン無効化ＡＰＩにも適合可能である。

当業者であれば理解されるように、システムは様々なアルゴリズム及びトークン構文を使用して、所与のホログラム・サーバが応答と共にキャッシュされたトークンとその後受信したトークンとを比較すること、及びキャッシュされたトークンが有効であるかどうかについて決定することを可能にする。この手法は、例えばタイムスタンプの順序付け、ベクトル・クロック手法、又はＬａｍｐｏｒｔタイムスタンプに依存可能である。

例示のホログラム・ネットワーク
以下で、ホログラム・サーバのネットワークの非限定的な実施形態を説明する。最初に、ホログラム・ネットワークの通信についての序説の概要を提示する。

この実施形態において、ホログラム・ネットワーク内の様々なサーバは、ＨＴＴＰクライアント要求に返答すること、要求をオリジンにより近いノードに転送すること、オリジンに転送すること、及び戻された応答が再度サービスされるようにキャッシングすることが可能な、ＨＴＴＰプロキシ・ネットワークとして機能する。

加えてホログラム・サーバは、クライアントと通信するため並びにクライアントに対する応答を要求及び取り出すために使用されるＨＴＴＰチャネルから離れたメッセージング・システムを介して、互いに通信することができる。（ホログラム・メッセージング・システムは、所望であればＨＴＴＰを活用することも可能であるが、本明細書では説明のために、ＨＴＴＰトラフィックはクライアントのコンテンツ要求及びそれに対する応答、並びにプロキシ動作の結果として生じる転送要求及び転送応答を指すものと想定する。）

メッセージは、それらのうちの１つがレジストラとして動作し、ネットワーク上のいずれのサーバが任意の所与の時点で任意の所与のドメイン名に関する発行者ステータスを保持するかを追跡及び割り当てる、ホログラム・サーバによって交換される。メッセージは、各それぞれの発行者から、レジストラによって追跡された場合、公開サーバが発行者であるドメインに関するＨＴＴＰクライアント要求を受信することによって加入したすべてのサーバまでの、発行者・加入者モデル上でも公開される。加入はトークン無効化を加入サーバに送るため、この手法で加入しているということは、所与のドメインに関して権威あるものとしてローカル・キャッシュを取り扱うために必要なステータスである。非発行者がＨＴＴＰ要求と共にオリジンへと前進（及びトークン無効化と共にオリジン応答を受信）するか、又はトークン無効化ＡＰＩ上でオリジンからの要求を受信する場合、メッセージは非発行者から所与のドメインの発行者へも渡され、そのいずれの場合も、公開されるべきであるトークン・メッセージを有するものとすることができる。

様々な接続のすべてが接続自体のトラフィックに基づく論理タイムアウト条件を有することが可能であり、更に加入は、ドメインごとにそのドメインに対するＨＴＴＰトラフィックがなくなると未加入となり得、発行者ステータスは、発行者で所与のドメインに対するＨＴＴＰトラフィックがなくなるとクリア可能である。すべてのメッセージ接続は直接として説明されるが、スケーラビリティのために、１つ又は複数のブローカ・ノード又は親を介して間接的に行うことも可能である。レジストラは、標準的なアクションに加えてレジストラとして動作するその他の通常のホログラム・サーバとすることが可能であるが、特化されたレジストラ専用サーバ又はサーバ・セット、或いは分散データベース・サービス又はＤＮＳサービスなどの他の手段によって提供される抽象サービスであってもよい。

図６は、例示のホログラム・サーバ・プラットフォームの様々な役割及び機能性を示す図である。図６に示された実施形態では、クライアントとホログラム・サーバとの間で、非ホログラムＣＤＮプロキシ・サーバ（図４ｂ）の追加の層は使用されない。その実施形態については後で説明する。

図６を参照すると、様々なホログラム・サーバ６０２がプラットフォーム内に分散されている。ラベル付けされたライン・セグメントは機械間の接続を表しており、実線はＨＴＴＰ要求及び応答メッセージを示し、破線及び点線はトークン関連及び他のメッセージを渡すためのホログラム・サーバ間の接続を示す。点線はレジストラ用のメッセージを示し、破線は発行者・加入者又はピア関係にあるホログラム・サーバ間のメッセージを示す。いくつかのケースでは、ライン・セグメントを重複して描画することなく、同じノード間の複数のライン・セグメントを示すための省略形として複数の数字ラベルが使用される。

クライアント・デバイス６１０を備えるユーザは、矢印１によって示されるように、ＨＴＴＰを使用してホログラム・サーバ６０２ａへのＡＰＩ要求を行うものと想定する。

サーバ６０２ａは、インスタントＨＴＴＰ要求についてホスト・ドメインを決定し、当該ドメインについてホログラム加入ステータスがローカルに設定されているかどうかを決定する。ステータスは未加入である（unscribed）ものと想定する。未加入である（及び発行者でもない）ことの結果として、サーバ６０２ａは、以前の応答についてそのローカル・キャッシュを調べることから除外される。サーバ６０２ａは、オリジン６０１に最も近いホログラム・サーバをサーバ６０２ｂとして決定し、したがってＨＴＴＰ要求をサーバ６０２ｂに転送するように準備する（サーバ６０２ａの構成によっては、代わりに、最終的にサーバ６０２ｂに転送する前に１つ又は複数のキャッシュ親サーバに転送させることができる。）サーバ６０２ａは、矢印２によって示されるようにＨＴＴＰ要求をサーバ６０２ｂに転送する。

サーバ６０２ａは、ネットワーク上のレジストラとして現在サービスしているサーバ６０２ｃに、メッセージを送信することによって、ドメイン、自身の身元、及びＨＴＴＰ要求が別のホログラム・サーバに転送されていることを表示するフラグを示す。このメッセージは矢印３によって示される。レジストラとして動作しているサーバ６０２ｃは、当該所与のドメインに対して発行者が設定されていないこと、及び要求サーバは内部で転送していることを判定し、矢印３でのリターンによって示される未知の応答を戻す。

サーバ６０２ｂはサーバ６０２ａによって転送されたＨＴＴＰ要求を受信し、同じドメイン・チェックを実行する。サーバ６０２ｂも未加入であるものと想定する。サーバ６０２ｂは、矢印４によって示されるようにＨＴＴＰ要求をオリジン６０１に転送する。

サーバ６０２ｂも矢印５によって示されるように、レジストラであるサーバ６０２ｃにメッセージを送信し、サーバ６０２ｂはオリジンに最も近いホログラム・サーバであるため（又は、何らかの他の基準又はそれらの組み合わせに基づいて）、サーバ６０２ｃは、当該ドメインに対して発行者の役割を実行するべくサーバ６０２ｂを割り当て、矢印５でのリターンによって示される回答メッセージで自身の識別子を戻す。サーバ６０２ｂは、回答を受信すると自身を当該所与のドメインに対する発行者として設定する。

矢印５でのリターンによって示されるレジストラ・サーバ６０２ｃからの回答は、矢印４でのリターンによって示されるオリジン６０１から受信するＨＴＴＰ応答の完了以前に、サーバ６０２ｂに到達するものと想定する。オリジン６０１からＨＴＴＰ応答が受信された場合、応答に付加されたトークンが解析され、応答はインデックス付けされたトークンと共にサーバ６０２ｂでローカルにキャッシュされる。この実装で各トークンは、オリジンから長形式で受信されない場合、短形式から長形式にアップグレードされ、サーバ６０２ｂはシリアル番号を各トークン及び自身のサーバ番号に割り当てる。長形式トークンはローカルにキャッシュされる形式であり、トークンを担持しているオリジナル・ヘッダを置換することによってＨＴＴＰを介して戻される。

サーバ６０２ｂは、矢印２でのリターンによって示されるように、サーバ６０２ａからのＨＴＴＰ要求に回答する。未加入ステータスを有するサーバ６０２ａは、応答をローカルにキャッシュせず、トークン関連ヘッダをストリップし、矢印１でのリターンによって示されるように応答をクライアント・デバイス６１０に戻す。（サーバ６０２ａが加入ステータスを有するならば、以下でより詳細に述べるように、同じコンテンツに対する後続のクライアント要求への応答で使用するために、応答をローカルにキャッシュすることができる。）

次に、クライアント・デバイス６１１を備えるユーザは、矢印６によって示されるようにホログラム・サーバ６０２ａへのＡＰＩ要求を行い、要求はクライアント・デバイス６１０によって以前に要求されたものと同じコンテンツに対するものであると想定する。このドメイン上では、キャッシュ・キーはユーザ識別子から導出されないものと想定する。

サーバ６０２ａは以前と同じチェックを実行し、第１のＨＴＴＰクライアント要求に関してサーバ６０２ｃのレジストラにメッセージを送信する。このメッセージは矢印７によって示される。サーバ６０２ｃは、矢印７でのリターンによって示されるように、発行者としてのサーバ６０２ｂの識別子で応答する。サーバ６０２ａは、ライン・セグメント９によって示されるように、サーバ６０２ｂへの加入接続をオープンするが、オープンしているならば、接続を再使用する。サーバ６０２ａは、以前と同じ計算を実行して、オリジンに最も近いサーバを決定し、矢印８によって示されるようにＨＴＴＰ要求をサーバ６０２ｂに転送する。

サーバ６０２ｂは、発行者であるそのローカル・キャッシュを調べ、ＨＴＴＰ要求に関する応答コンテンツを見つける。更にサーバ６０２ｂは、応答がキャッシュされた後にオリジナル要求に付加された各トークンが（例えばシリアル番号増分によって）明示的又は暗黙的に無効化されていないことを検証し、矢印８でのリターンによって示されるように、キャッシュされたコンテンツをサーバ６０２ａに戻す。

ライン・セグメント９上に示された加入（サブスクリプション）は、矢印８でのリターンによって示されたサーバ６０２ｂから受信されるＨＴＴＰ応答の完了以前に手配されているものと想定する。サーバ６０２ｂからのＨＴＴＰ応答がサーバ６０２ａによって受信された場合、応答に付加されたトークンが解析され、応答はインデックス付けされたトークンと共にサーバ６０２ａでローカルにキャッシュされる。トークンはサーバ６０２ｂがサーバ起源として識別される長形式であるため、アップグレードは不要であり、後にサーバ６０２ｂによって発行される増分されたシリアル番号と比較可能である。

上記と同じコンテンツについてのサーバ６０２ａへの更なる要求が行われた場合には、（キャッシュ制御ヘッダなどのように）常用（customary）ＨＴＴＰキャッシュ制御が満たされるか又はなかったという条件、並びに、本来は応答と共に与えられたトークンのいずれも、そのドメインについての加入チャネルを介した発行者（サーバ６０２ｂ）からのメッセージによって無効になっていないという条件で、サーバ６０２ａのローカル・キャッシュからコンテンツが戻されることになる。

更なる例として、矢印１０によって示されるように、クライアント・デバイス６１２は前述と同じコンテンツについてサーバ６０２ｄに対して要求を行うものと想定する。サーバ６０２ｄは前述のプロセスと同様に、矢印１１によって示されるようにサーバ６０２ｃに発行者識別子を要求し、矢印１２によって示されるようにサーバ６０２ｂにＨＴＴＰ要求を転送し、ライン・セグメント１３によって示されるようにドメイン・メッセージに関してサーバ６０２ｂに加入する。

クライアント・デバイス６１２はその後、矢印１４によって示されるようにＡＰＩ上で「書き込み」要求を行い、ＨＴＴＰ ＰＯＳＴをサーバ６０２ｄに送信するものと想定する。このドメインは、ＨＴＴＰでは極めて通例であるように、ＰＯＳＴ応答をキャッシュしないように構成されるものと想定する。サーバ６０２ｄは、矢印１５によって示されるように要求をサーバ６０２ｂに転送し、これが矢印１６によって示されるように要求をオリジン６０１に転送する。

オリジンは、矢印１６でのリターンによって示されるようにＨＴＴＰ応答を戻し、サーバ６０２ｂで受信されると、ホログラム・トークンは前述と同様に解析されるが、今回、オリジンのＨＴＴＰ応答メッセージは先頭に付加された感嘆符構文を使用するトークンに対する無効化を含む。無効化されたトークンは、前述のようにクライアント・デバイス６１０、６１１、及び６１２に戻されたコンテンツに関して以前に述べたトークンのうちの１つであったものと想定する。サーバ６０２ｂは、無効化されているトークン上に以前に割り当てられた番号よりも高位のシリアル番号を備える長形式に、トークンをアップグレードする（オリジンから既にその形式でない場合）。サーバ６０２ｂは、ドメインに関するトークン・メッセージへのそれらの加入により、サーバ６０２ａ及び６０２ｄに発行（パブリッシュ）されるトークン・メッセージを作成する。サーバ６０２ａ及び６０２ｄはトークン・メッセージを受信し、より高位のシリアル番号を示すようにそれらのローカル・トークン・キャッシュを更新して、（例えば以前にキャッシュされた応答の使用を試み、トークン・シリアル番号及び／又はタイムスタンプを比較する場合、サーバ６０２ａ及び６０２ｄによって発見されるように）より古いバージョンのトークンと共に以前にキャッシュされたＨＴＴＰ応答を暗黙的に無効化する。

ＡＰＩ「書き込み」アクションに対するＨＴＴＰ応答は、矢印１５でのリターンによって示されるようにサーバ６０２ｄに戻され、その後矢印１４でのリターンによって示されるようにクライアント・デバイス６１２に送信される。

ここで無効化されたトークンを使用して以前にキャッシュされたコンテンツについてのサーバ６０２ａ、６０２ｂ、又は６０２ｄへの更なる要求が行われると、前述のようにオリジン６０１に戻る全トラバースが生じ、前述と同様にキャッシュされたコンテンツの再ポピュレーションが続くことになる。

クライアント・デバイス６１２は、矢印１７によって示されるように、前述のようなコンテンツについての要求をサーバ６０２ｄに対して行うものと想定する。サーバ６０２ｄは、場合によっては補助システムがサーバ６０２ｂ上の負荷が高いことを示したため、又は単に代替実装の結果、オリジンに直接転送すべきであることを計算するものと想定する。サーバ６０２ｄは、矢印１８によって示されるようにＨＴＴＰ要求をオリジン６０１に転送する。応答を受信するとホログラム・トークンが解析され、発行が必要であるが、サーバ６０２ｄは発行者ではない。サーバ６０２ｄはピアツーピアのトークン・パスのために接続をオープンするか、又はドメインに対する発行者であるサーバ６０２ｂへの既存のコネクションを利用して、矢印１９によって示されるようにサーバ６０２ｂにトークン・メッセージを渡す。そのトークン・キャッシュを更新した後、サーバ６０２ｂはすべての加入者にメッセージを渡し、この時点ではサーバ６０２ａ及び６０２ｄである。サーバ６０２ａは矢印２０によって示されるようにトークン・メッセージを受信し、そのローカル・トークン・キャッシュを更新する。サーバ６０２ｄは矢印２１によって示されるようにトークン・メッセージを受信するが、これはメッセージに対するソースであり、そのようにすでに実行しているため、そのトークン・キャッシュを変更する必要はない。

図７を参照すると、例示のホログラム・ネットワークのスナップショット状態が示されている。これは非限定的な実施形態である。この状態で、すべてのホログラム・サーバ７０２ａ、７０２ｂ、７０２ｄ、及び７０２ｅはレジストラとして動作するサーバ７０２ｃに対してオープンな接続を有する。１つのドメインに対するＨＴＴＰトラフィックがクライアント・デバイスから受信され、結果としてサーバ７０２ａ、７０２ｄ、及び７０２ｅから７０２ｂへのオープンなＨＴＴＰ接続、並びにサーバ７０２ｂからオリジン７０１への接続が生じ、サーバ７０２ｄからオリジン７０１へのＨＴＴＰ接続もオープンとなる。メッセージの発行を容易にするために、オープンなＨＴＴＰ接続を有する同じサーバであるサーバ７０２ａ、７０２ｄ、及び７０２ｅも、当該ドメインに対する発行者の役割が割り当てられたサーバ７０２ｂへのオープンな加入接続を有する。加えてサーバ７０２ｄは、ＨＴＴＰ応答のためにオリジンに接触することから生じるトークン・メッセージを渡すために、サーバ７０２ｂに対してオープンなピア接続を有する。トークン無効化に関するメッセージは、たとえそれらが発行者として指定されたサーバから発せられておらず、最初に発行者に送信されなければならない場合であっても、一般に、オリジンに近いポイントからすべての加入ノードへと外側に向けて分散され得る。トークン・メッセージは、加入ノードがキャッシュ内に保存した可能性のある以前の応答を無効化することが可能であり、加入している状態とは、無限か又は非常に長いＴＴＬであるにも関わらずキャッシュを権限あるものにし得る状態のことである。

代替の実施形態において、ＣＤＮは、図２及び図４ｂに関連して以前に例示したように、非ホログラムＨＴＴＰプロキシ・サーバの補足でホログラム・サーバを採用する。

この代替の実施形態では、ホログラム・サーバは更に、ホログラム適合ＡＰＩ応答をフェッチ及びキャッシュするためにオリジンへと前進するため、トークンを記憶してトークンによる高速アクセスのためにそれらにインデックス付けするため、並びにできる限り速くトークン無効化を受信及び伝搬するための責務を負い、上記で図６に関連して説明したようにその他の方法で動作可能である。しかしながらホログラム・サーバは、例えば本明細書の教示の恩恵なしにＣＤＮプラットフォームに投入するような種類の非ホログラムＨＴＴＰプロキシの背後に位置する。

非ホログラムＨＴＴＰプロキシ・サーバ単独の場合、ノーストア又は再有効化必須トランザクションは、典型的には図８ａに示されたフロー・タイプを有する（ここで非ホログラムＨＴＴＰプロキシは単に「プロキシ」と示される）。図８ａ〜ｅで使用される表記法では、矢印は要求の方向を表し、（応答の形で）コンテンツは左から右へと流れる。

ＴＴＬベースのキャッシング・トランザクションは図８ｂに示されたフロー・タイプを有し、これは要求されたコンテンツの有効で満了していないコピーが見つかった場所に依存している。

ＴＴＬベースのキャッシングのケースでは、図８ｂの第１のインスタンスはクライアントに近いキャッシュされた応答を示し、第２のインスタンスはオリジンに近いキャッシュされた応答を示し、第３のインスタンスはオリジンに近いキャッシュされた応答を示す。

ここで、ホログラム・ノード（「ホロ」と表記）を導入する。プロキシ・サーバは応答を、ノーストア又は再有効化必須として（すなわち動的オブジェクトとして）、又は数秒などの非常に短いＴＴＬであるがキャッシュ可能オブジェクトとして取り扱うように求められることになるが、ホログラム・サーバはキャッシングに関して権威あるものであり得る。ホログラム・ネットワークはキャッシュ階層と同様であると見なすことができる。これによって、図８ｃに示されたフローの可能性をもたらす。

図８ｃに示された第１のインスタンスでは、ホログラム・サーバがキャッシュされた文書を有し、そのインスタンスの時点でそれを無効にするいずれのトークン無効化も知らないとの理解の下で、長いネットワーク・トラバースが回避される。第２のインスタンスでは、ホログラム・サーバは有効な文書を有さず、第２の試行のためにオリジンに近いホログラム・サーバに要求を転送し（キャッシュ・チョーク技法）、第３のインスタンスでは、権威ある回答を求めてオリジンに接触するために長距離が必要である。

代替として、ホログラム逆マッピングを用いない場合、フローは図８ｄに示されたようになる。

前述のように、アクティブ・トークン無効化アサーションはオリジンから発生可能であり、図８ｅに示されるように無効化を受信する初期のホログラム・サーバから、発行者・加入者又は他の技法を使用して、他のホログラム・サーバへと伝搬される。

ホログラム・ノード内でのメッセージ・フローのサポート
ホログラム・ノード内でのメッセージングのための例示のソケット実装を、以下で説明する。下記は、可能な設計を例示するための単なる非限定的な例であることが意図される。

この実施形態では、ホログラム・ノードは、ホログラムの加入及び無効化をサポートするためのメッセージ・フローを容易にする、ソケット動作のセットを用いて設計される。これらの動作は従来のＨＴＴＰプロキシ機能を拡大させることが可能である。

図９は、単一のホログラム・サーバの観点からの例示のソケット・セット設計を示す。各ボックス上に示された名前は、ソケットへの参照を保持する変数を識別するため、及びソケットとの間の通信を示すログ・ラインにラベル付けするために使用される、ホログラム・サーバ内の名前である。各ソケットのタイプ及び機能を以下で説明する。

この例示の設計ではソケットは限定機能に特化されるため、２つのノードを同時に複数のソケットに接続することが可能である。代替の設計では、これらのボックスが他のノードに対する仮想ハンドルを表すものであり、単一のソケットであれば最大でもノード間でオープンであり、同じソケット上で複数のメッセージ・タイプが搬送されるものとみなし、、キュー、その実施、及び他の細部はかなり単純に異なるものであろう。

設計はメッセージに基づき、メッセージの始め及び終わりのフレーミング・フォーマット、メッセージの最大サイズ、並びに、ソース、宛先、ルーティング、及び他のメッセージ受け渡し情報を担持するためのヘッダを暗示する。この機能層を提供するためにメッセージ・キュー・ライブラリが採用可能であるか、又はこれらの規則はカスタム・ベースで設計可能である。以下で説明するメッセージに加えて、普通に通信するすべてのノード間での「心拍」メッセージのサブシステムが実装されるべきであり、不全の心拍は破損した接続としてカウントされるべきであり、これは特に加入者にとって不本意な未加入イベントとみなされるものである。

この設計では「ＩＮ」及び「ＰＡＳＳ」は単一ソケットではなく、ソケットのアレイであり、ゼロ・メンバから始まって通常の動作で拡縮する。説明を簡潔にするために、これは図９には示されていない。

ホログラム・メッセージング・システムは、ＨＴＴＰプロキシ・システムと同じオペレーティング・システム・プロセスで実行するようにエンジニアリング可能であるか、又は別々に実行するようにエンジニアリング可能であり、ここではＴＣＰソケット又はオペレーティング・システムに本来備わっているプロセス間通信システムを使用して、ＨＴＴＰプロキシ・システムからホログラム・メッセージング・システムにメッセージを渡すことができる。このプロセス間リンクには少なくとも２つのタイプのメッセージが適切であり、ＲＥＰ及びＡＰＰに到達するメッセージについては、以下を参照されたい。

以下でメッセージ・タイプを説明する。

「ＲＥＰ」は、複数の接続を受け入れ、サーバ側の要求−回答パラダイムを実行するリスニング・ソケットを表すオブジェクトである。クライアント側の送信要求は、同じサーバ上のローカルＨＴＴＰプロキシ・システムである。

インバウンド要求及びその後の回答例：
加入しているかどうかを調べるための、ドメインに関するＨＴＴＰプロキシ・ソフトウェアからの照会。
フォーマット：「SUBホストHOP|FINAL」
例えば「SUB example.com HOP」
回答オプション：
フォーマット：「OK PUB|SUBホスト・タイムスタンプ」
例えば「OK PUB example.com 123456789」
フォーマット：「PENDINGホスト」
例えば「PENDING example.com」

ドメインに関する増分されたシリアル番号のためのＨＴＴＰプロキシ・ソフトウェアからの照会。
フォーマット：「SERIALホスト」
例えば「SERIAL example.com」
回答：
フォーマット：「SERIALホスト・サーバ_id番号」
例えば「SERIAL example.com 1000 1234」

「ＡＰＰ」は、プッシュ−プル・パラダイムでプルの役割を果たす、複数の接続を受け入れ、メッセージを受け入れるリスニング・ソケットを表すオブジェクトである。プッシュ側の送信要求は、同じサーバ上のローカルＨＴＴＰプロキシ・システムである。

インバウンド・メッセージの例：
トークン・イベントが処理されるべきＨＴＴＰプロキシ・ソフトウェアからの通知。
フォーマット：「DATAホスト・トークン［@サーバ_id:番号:タイムスタンプ］」
例えば「DATA example.com users:123@1000:1234:123456789」

「ＲＥＧ」は、ホログラム・ネットワーク上の通常ノードからホログラム・ネットワーク上のレジストラ・ノードへと接続し、要求−回答パラダイムで要求を実行する、ソケットを表すオブジェクトである。このソケットの反対側はホログラム・レジストラ上の「ＲＧＲ」に接続され、メッセージの詳細については「ＲＧＲ」を参照のこと。ホログラム・レジストラは、データを通常ノードとして処理する場合、「ＲＥＧ」上で「ＲＧＲ」にメッセージを「送信すること」、及び回答を別のイベントとして処理することによって、レジストラに関連する問題を解決する。

「ＲＧＲ」は、複数の接続を受け入れ、ホログラム・ノードからのメッセージを受け入れ、それらにレジストラとして回答する、リスニング・ソケットを表すオブジェクトである。好ましくは、すべてのホログラム・ノードはレジストラとして動作するための機能を有する。外部監視システムは、レジストラを変更する必要がある場合、ＤＮＳエントリを変更するか又はローカル構成を変更することによってすべてのホログラム・ノードに信号を送信することが可能であり、代替としてホログラム・ノードは、ネットワーク内部のフェイルオーバー・ストラテジに依拠することが可能である。

インバウンド要求及び後続の回答の例：
ホストに対して発行者識別子を要求するため、及び必要であれば発行者となるためにボランティアのデフォルト・アクションを提供するための、ホログラム・ノードからの照会。
フォーマット：「GETホストHOP|FINAL要求者_ip_アドレス」
例えば「GET example.com HOP 1.2.3.4」
回答：
フォーマット：「KNOWNホストip_アドレス」
例えば「KNOWN example.com 1.2.3.4」
フォーマット：「UNKNOWNホスト」
例えば「UNKNOWN example.com」

その発行者ステータスをクリアするためのホログラム・ノードからの命令。
フォーマット：「CLEARホスト要求者_ip_アドレス」
例えば「CLEAR example.com 1.2.3.4」
回答：
フォーマット：「OK CLEARホスト・クリア済み_ip_アドレス」
例えば「OK CLEAR example.com 1.2.3.4」

「ＯＵＴ」は、所与のノードが発行者であるドメインに関するメッセージに加入している他のホログラム・ノードから複数の接続を受け入れる、リスニング・ソケットを表すオブジェクトである。ホログラム・ノードは、接続された加入者にメッセージが分散されることを保証する「ＯＵＴ」オブジェクトを介して加入したノードに、トークン・メッセージを発行することになり、同じノードから発行されるすべてのドメインが同じソケットを介して発行できるようにするために、加入者が示すドメインへのメッセージを制限するようにオプションでフィルタリングする。

「ＯＵＴ」オブジェクト内のソケットを介して送信されるメッセージは、様々な他のノードの「ＩＮ」オブジェクト内のソケットに到達する。

「ＩＮ」は、加入者の役割又は発行者・加入者パラダイムでメッセージを受信するためにホログラム・発行者「ＯＵＴ」ソケットに接続するソケットを表す、ゼロ又はそれ以上のオブジェクトのアレイである。「ＩＮ」ソケットは、ホストごとのメッセージに加入する必要性が生じるとアレイに追加され、典型的には「ＲＥＰ」ソケット上での活動及びそれに続く「ＲＥＧ」ソケット上での活動によって決定される。

ネットワークのスケーラビリティを強化するために、ホログラム「ＩＮ」ノードはブローカ・ノードへの直接接続を行うことが可能であり、これによって最終宛先に接続されるため、あらゆるノードがあらゆる他のノードに接続される場合よりも、完全接続ネットワーク上での接続の総数が少なくなる。ブローカ・ノードの編成は、構成の全体又は一部に基づく動的選定又は他の自己編成ストラテジによってハード・コード化又はノミネートが可能である。更にブローカは、直接接続を更に分離するために、配置構成内の他のブローカと通信することができる。

何らかの所定の期間に加入者による（「ＲＥＰ」ソケットを介した）特定のホストに対するＨＴＴＰプロキシ活動が見られない場合、ノードはホストごとにそれらのメッセージに未加入とすることができる。

インバウンド・メッセージの例：
トークン・イベントが処理されるべきホログラム発行者からの通知。
フォーマット：「DATAホスト・トークン［@サーバ_id:番号:タイムスタンプ］」
例えば「DATA example.comusers:123@1000:1234:123456789」

発行がホストに対して切断されることになるホログラム発行者からの通知。
フォーマット：「DATAホスト:END発行者_ip_アドレス」
例えば「DATA example.com:END 1.2.3.4」

「ＰＡＳＳ」は、プッシュ−プル・パラダイムのプッシュの役割でメッセージを渡すための、発行者である他のホログラム・ノードに接続するためにオープンされたゼロ又はそれ以上のソケットのアレイである。「ＰＡＳＳ」を介して渡されるメッセージは、オフ発行者から生じるが、権威あるものとされ伝搬されなければならないトークン・メッセージである。このソケットの反対側は各ホログラム発行者上の「ＦＵＮ」に接続され、メッセージの詳細については「ＦＵＮ」を参照のこと。

ノードが発行者に対して「ＰＡＳＳ」ソケットをオープンしたが、連続して１８００秒間（３０分）任意のホストに対してピアを介して渡すメッセージを有さない場合、その発行者への「ＰＡＳＳ」ソケットはクローズされ、アレイから除去される。

ホログラム・システム内の「ＰＡＳＳ」ソケット及び対応する「ＦＵＮ」ソケットの存在により、オリジンに接触するネットワークのサブセットにおいてスケーラビリティを提供することが可能であり、それらがない場合、すべての要求は好ましくは１つのホログラム・サーバを介してオリジンへと進む。「ＰＡＳＳ」／「ＦＵＮ」ソケットの存在は、結果として生じるホログラム無効化がネットワークを介した経路を保持するため、複数のホログラム・ノードをＨＴＴＰ応答のためにオリジンへと進ませることができる１つの機構である。

ホログラム・ノードがトークン・を生成するが、現時点では所与のホストに対する発行者がわからないというイベント（レジストラは、このノードによって調べられた時点でのみ、オリジンの前の最終ノードについて「ＨＯＰ」ステータスを伴い「ＦＩＮＡＬ」ステータスを伴わないＧＥＴ呼び出しを受信していることから、通常動作で生じる可能性があり、更にサーバの再起動などの異常動作からも生じる可能性があるステータス）では、ノードは「ＰＡＳＳ」ソケットを使用してレジストラにメッセージを渡すことになる。レジストラ自体は、メッセージがその「ＦＵＮ」ソケットに到達すると動作可能であり、詳細については「ＦＵＮ」を参照のこと。

「ＦＵＮ」は、「ＰＡＳＳ」ソケットからトークン・メッセージを受信するために、複数の接続を受け入れてプッシュ−プル・パラダイムでプルの役割を果たし、通常はトークン・メッセージを「ＯＵＴ」ソケットに渡すことによってそれらに対して動作する、リスニング・ソケットを表すオブジェクトである。レジストラ上の「ＦＵＮ」ソケットは、メッセージのアプリケーション・レベルのキューイングを生じさせることが可能である。発行者が決定されるとすぐに、レジストラ上の「ＰＡＳＳ」ソケットを使用してキューイングされたメッセージが発行者の「ＦＵＮ」ソケットに渡され、通常の動作が続行されることになる。

インバウンド・メッセージの例：
トークン・メッセージが伝搬されるべきホログラム・ピアからの通知。
フォーマット：「DATAホスト・トークン［@サーバ_id:番号:タイムスタンプ］」
例えば「DATA example.comusers:123@1000:1234:123456789」

図１０では、例示のネットワーク状態が示されている。「Ｈ１」、「Ｈ２」、及び「Ｈ３」はホログラム・ネットワーク上のノードである。これは、例示のために提供された非限定的な実施形態である。

この例の各ノード内で「ＰＲＳＯ」（プロキシ加入出力）及び「ＰＲＴＯ」（プロキシ・トークン出力）オブジェクトは、ＨＴＴＰプロキシ・ソフトウェア内でオープンなソケットである。マルチプロセス・プロキシ・デーモン上ではＵｎｉｘプロセスごとに１つが存在するが、簡略化するために各々について単一のボックスが図示されている。「ＰＲＳＯ」は、ホログラム付属ソフトウェアの「ＲＥＰ」ソケットと通信するために、要求−回答パラダイムで要求の役割を果たすプロセス間ソケットである。「ＰＲＴＯ」は、ホログラム・メッセージング・ソフトウェアの「ＡＰＰ」ソケットと通信するために、プッシュ−プル・パラダイムでプッシュの役割を果たすプロセス間ソケットである。

図１０に示された例では、「Ｈ３」はレジストラとして動作している。「ＲＥＧ」、「ＲＥＧ２」、「ＲＥＧ３」はすべて、「ＲＥＰ」ソケットに到達するトラフィックによって必然的に生じる照会を容易にするために、「ＲＧＲ３」に対してオープンである。「Ｈ１」は少なくとも１つのドメインに対して発行されており、「Ｈ２」及び「Ｈ３」はどちらもそのドメインに対するトラフィックを見た後、「ＩＮ２」及び「ＩＮ３」を介して更新を受信するために加入した。

加えて図１０では、逆マップ・システムが、「Ｈ１」が発行者であるドメイン（場合によっては上記と同じドメイン）に対して「Ｈ２」及び「Ｈ３」の両方をオリジンの前の最終ホップにしたため、「ＰＡＳＳ２」及び「ＰＡＳＳ３」は「ＦＵＮ」に対してオープンである。「Ｈ２」は、いずれのノードが発行者としてサービスしているかがわかるまでドメインに対する最終ホップであったため、メッセージをレジストラに送信するために「ＰＡＳＳ２」は「ＦＵＮ３」に対してもオープンであった。

選択及び分類基準及びトークンとしての他の論理の表示
いくつかの実施形態では、オリジン応答に含まれるあるトークンは、１次キー又はデータのセットを示さず、むしろ応答構築に関連する照会の他の部分を示す場合がある。こうしたトークンは、応答内のその実際のデータではなく、応答を構築するために使用された選択／分類又は他の論理を示す。

ＡＰＩドメインにとって何が適切であるかに関わらず、最新のオファー、ニュース、取引、登録などであり得る「最新の１０のレコード」を示すＡＰＩ呼び出しについて考えてみる。時間が経過してより多くのレコードが追加されるにつれて、正しい応答はデータ自体を直接変更することなく、したがって以前のホログラム適合応答に付加されたトークンを直接変更することなく、潜在的に変更されていく。データの応答セットは変更／更新されているが、データの項目自体は変更されていない可能性がある。したがって、ＡＰＩ呼び出し内に存在する分類又は選択挙動を反映するトークンを導入する。実際にはこれらのトークンは、以前に論じた例示のケースと同様に、ＡＰＩ応答内のデータが変更されたためではなく、ＡＰＩ応答内のデータの分類又は選択が期限切れになったために、ＡＰＩ応答が無効になった時に無効化される。したがってＡＰＩ応答内のデータは、ここでは同じＡＰＩ呼び出しに応答して提供する「誤った」データである。

「市のイベント」ＡＰＩを例に取ってみよう。これは、ボストンで行われるイベントに関するデータをフェッチするためにオファーされたＡＰＩである。
GET/events/listings?sort=last_modified+desc&filters=category:
(Theater+Dance)&ll=40.766146,-73.99021&api-key=123
Host:api.city-events-example.com
...
X-Hologram-Data:...,events:COUNTSORT

オリジン・サーバはＡＰＩ呼び出しが分類コマンドを参照することがわかっているため、「events:COUNTSORT」トークンがＡＰＩ応答に付加される。「events:COUNTSORT」トークンは後に、テーブル内のエントリのカウントが修正されるごとにオリジンによって無効化することが可能であり、したがってテーブルからの照会のカウント又は順序付けのいずれかに依存する応答を正しく無効化する。

当業者であれば理解されるように、こうした「選択／分類」トークンは、「最近」のイベント或いは「トレンド」又は「現在流行」のイベントなどといったものを戻す、ＡＰＩ呼び出しに使用することができる。

範囲トークン
いくつかのケースでは、アプリケーションはＡＰＩを呼び出し、例えばユーザによってマップ上で選択されるような、要求された特定の地理的区域内に入る当該のアイテムを戻すＡＰＩなどの、データ範囲を提出することができる。当該のアイテムは、販売中の家、当該の特定の店又は場所の位置、写真が撮影された正確な位置などとすることができる。本明細書で説明するシステム及び方法は、これらの用途に適用可能である。

前述の例示のトークン構文規則を基礎として、範囲トークンは一実装において[A..B]の形で範囲構文を定義するために大括弧文字を使用することが可能であり、ここでＡ及びＢは２つのピリオド文字によって分けられ大括弧によって囲まれた整数又は浮動小数点数、例えば[1.1..3.14]であり、これは１．１から３．１４までの範囲を包含的に表記している。この表記は、例えば２１才から５０才までの５０才を含む年齢を論理的に指定するための「age:[21..50]」などの他の方法で、通常データ・トークンに付加される。

例示のために、以下のようなこうしたアプリケーションによって生成されるＨＴＴＰ ＧＥＴ要求について考えてみる。
GET/api/foo...
?lat=1.1234567890,1.1244567890...
&long=1.1234567890,1.1244567890...
&num=25...

...yielding…

Property101 data
Property123 data
Property150 data
...

この例では、緯度／経度パラメータは提供された４つの座標からのボックスを表し、最大２５までの結果が戻される。従来技術のＴＴＬベースのキャッシング・ソリューションは、位置決めが非常にきめ細かいため、この応答をあまり適切にキャッシュできない。それらの特定の座標がＴＴＬ内の別のクライアントによって要求されていない限り、座標に対するわずかな変化が結果としてキャッシュ・ミスを生じさせる可能性がある。したがってある実施形態では、オリジンは、許容差によって定義されるように、特定の地理的ボックス（又は他のデータ範囲）についての結果を同様のボックス（又は同様のデータ範囲）に再使用できることを示すことができる。キャッシュ・ヒットが存在するかどうかを決定するために、キャッシング・サーバは要求されたＵＲＬパラメータ（ｌａｔ／ｌｏｎｇ）を解釈し、キャッシュ・インデックス内の一致するエントリを探す場合、何らかの許容差をそれらに適用することができる。

次に、ホログラムに関するこの種の応答をトークン化するために、オリジン・サーバは各プロパティ識別子に関するトークンを付加することが可能であり、これによって、そのプロパティに関するデータが変更された（例えば価格又はステータスが変更された）場合、システムはキャッシュされた応答を無効化できるようになる。新しいプロパティ又は地理的ボックス内に現れる他のものを反映するために、特定の座標に関するホログラム・トークンを使用することができる（例えば、latlong:a;b;c;d）。しかしながら、こうしたトークンは非常に特有であり、それらを無効化しようとする際に困難が生じる可能性がある。例えばオリジンは、オリジン・データベース内に追加される新しいプロパティに基づいて、以前の座標セット（及びトークン）を無効化すべきかどうかを決定しなければならない可能性がある。こうした論理、例えば当該の新しいアイテムの何らかの距離内にあるすべての座標及びトークンを無効化する論理を、オリジン内に展開及び配置することができるが、これはオリジンに負荷をかけ、すべてのケースにおいて正確でない可能性がある。

この問題により良く対処するために、ある実施形態において、応答が依存しているデータの範囲全体を反映する範囲トークンを用いてＡＰＩ応答にタグ付けすることができる。前述の例では、こうしたトークンを備える応答は以下のようであり得る。
GET/api/foo...
?lat=1.1234567890,1.1244567890...
&long=1.1234567890,1.1244567890...
&num=25...
…yielding…

...
X-Hologram-Data:geo:[1.1234567890..1.1244567890][ 1.1234567890..1.1244567890], property:101,property:123, property:150
...
Property101
Property123
Property150

オリジンは、新しいプロパティ（又は当該の他の新しいアイテム）が配置される特定の座標に対応するトークンによって、無効化することができる。例えば新しいプロパティ１６０が、プロパティ１０１の次のドアに、及び前の要求で座標によって定義されたボックス内に追加されるものと想定する。無効化アサーションは以下のようであり得る。
POST/hologram/invalidate HTTP/1.1
...
tokens=geo:[1.1234567899][1.1234567899]

このケースでは、無効化アサーションによって記述される特定の位置は、ホログラム・サーバによって範囲内の２つの特定のポイント、１つは緯度、１つは経度として解釈される。無効化アサーション内の特定の位置を包含する緯度及び経度範囲で表記される上記の例のような応答は、キャッシュ内で識別及び無効化される。

このように、応答は、応答が依存することになるデータ値の範囲を示す範囲トークンを用いて表記することができる。イベントがデータ範囲内のオリジンで発生する場合、オリジンは、範囲内の特定のデータ・ポイントに関しては無効化アサーションによって無効化することができる。

この手法は、ＡＰＩが要求内のデータ範囲に基づいて情報を戻す様々なデータ及び環境に適用可能である。例えば上記に加えて、特定の日付又は時間範囲についてのイベント又はＴＶ番組などを戻すＡＰＩは、範囲を用いて表記することが可能であり、新しいイベントが追加されるか、又はイベントのスケジュールが再構成される場合、その範囲をカバーする応答は上記の機構を介して無効化することができる。こうしたケースでは、トークンは、例えばより広いスケジュール内で変更されたＴＶについての時間範囲が現在無効であることをアサートすることによって、範囲内の部分的な範囲のポイントに対する無効化を含むことが可能である。

システムの潜在的利点
以下は、開示された教示で達成可能ないくつかの特典であるが、必ずしもこうした特典のすべてを表すものではなく、こうした潜在的特典の記述は、こうした特典を達成することが本明細書の教示の実施に要求されるか又は必要であることを意味するものではない。

潜在的利点：トラフィックのローカライズ
本明細書で説明する技法は、結果として、「ノーストア」モードに比べてプラットフォームをトラバースするコンテンツ・トラフィックを少なくすることができ、更にＡＰＩに関するコンテンツ・トラフィックをプラットフォーム・エッジに局所的にローカライズすることができる。要求がホログラム・サーバに入ってくる場合、ＵＲＬを調べて文書をサービスすることができる。

任意の非ホログラム・プロキシを使用して、ホログラム・プロキシの前に、ＡＰＩ応答に対する従来のＴＴＬキャッシングの追加の層を提供することができる。秒単位の短いＴＴＬが使用可能である。これは、大量の公衆ＡＰＩトラフィックに直面するためにプロキシの広域配備が必要な、極端に高トラフィックのシナリオに有用である。

潜在的利点：オリジン・オフロード
ＡＰＩ応答の大部分はそれらが表すデータ・レコードが「静穏」であるので、オリジン・サーバからのオフロードを達成することができる。

潜在的利点：待ち時間
ＡＰＩ応答の大部分はそれらが表すデータ・レコードが「静穏」であるので、クライアントに対する待ち時間の削減を達成することができる。通常はオリジンから数百ミリ秒「離れた」クライアントは、今やより近くに配置されたホログラム・サーバからより頻繁に返答を受信しているので、エンド・ユーザに対する待ち時間を低減させることができる。

オンライン・プレゼンスのための協調更新
本明細書の教示は、ＡＰＩコンテンツ以外の様々な種類のコンテンツに適用可能であり、コンテンツ・プロバイダのオンライン・プレゼンス全体にわたる協調コンテンツ更新をサポート可能である。例示のために、ＣＤＮコンテンツ・プロバイダがそのオンライン・プレゼンス全体にわたって「トップ・ニュース」のフィードを提供したいものと想定する。「トップ・ニュース」コンテンツに関するデータは、ウェブサイト・ページ上に含めるためにコンテンツ・プロバイダのコンテンツ管理システムによって取り上げられる文書（例えばＸＭＬ文書）で実現可能であり、それはアプリケーションを使用しているエンド・ユーザに表示するためのコンテンツ・プロバイダのモバイル・アプリケーションによって取得可能であり、且つ／又は他のクライアントにとって「contentprovider.com/API/topnews」でＡＰＩを介して使用可能なものである。本明細書の教示を活用し、これらのシステムのうちのいずれかからの応答（例えばウェブ・サーバからのｈｔｍｌページ、モバイル・アプリケーションを処理しているサーバからのモバイル・アプリケーション応答、及び／又はＡＰＩ応答）に、「トップ・ニュース」文書に関するトークンで以てタグ付けすることができる。その文書が更新された場合、トークンは無効化され、結果としてオンライン・プレゼンス全体にわたる様々な応答の各々がキャッシングの観点から無効化され、協調リアルタイム更新を促進させることになる。

コンピュータ・ベースの実装
本明細書で説明するクライアント、サーバ、及び他のコンピュータ・デバイスは、特定用途向けハードウェア、内部に記憶されたソフトウェアによって特定用途向けに構成された汎用ハードウェア、又はそれらの組み合わせにおいて具体化された、上記の機能特徴を用いて本明細書の教示によって修正された場合、従来のコンピュータ・システムで実装可能である。

ソフトウェアは、１つ又はいくつかの離散プログラムを含むことができる。所与の機能は、任意の所与のモジュール、プロセス、実行スレッド、又は他のこうしたプログラミング構造の一部を備えることができる。一般的に前述の各機能は、コンピュータ・コードとして、すなわち特定用途向け機械を提供するために１つ又は複数のマイクロプロセッサ内で実行可能なコンピュータ命令のセットとして実装可能である。コードは、本明細書の教示によって修正された場合、コンピュータ、デジタル・データ処理デバイス、又は他のコンピューティング装置内のマイクロプロセッサなどの、従来の装置を使用して実行可能である。一実施形態において、こうしたソフトウェアは、Ｌｉｎｕｘなどのオペレーティング・システムを実行する標準のＩｎｔｅｌハードウェア・プラットフォーム上でプロキシと共に実行するプログラミング言語で実装可能である。機能はプロキシ・コードに組み込むか、又はそのコードの付属として実行可能である。

上記のいくつかのケースでは、ある実施形態によって実行される特定順序の動作が示されているが、こうした順序は例示的であり、異なる順序、組み合わせなどで実行可能であることを理解されたい。更に、機能のうちのいくつかは、所与の命令、プログラム・シーケンス、コード部分などで組み合わせるか又は共有することができる。本明細書における所与の実施形態に対する言及は、説明された実施形態が特定の機能、構造、又は特徴を含み得ることを示しているが、あらゆる実施形態が必ずしも特定の機能、構造、又は特徴を含まなくてもよい。

図１１は、本発明の実施形態が実装可能なコンピュータ・システム１１００内のハードウェアを示すブロック図である。コンピュータ・システム１１００は、クライアント、サーバ、パーソナル・コンピュータ、ワークステーション、タブレット・コンピュータ、ワイヤレス・デバイス、モバイル・デバイス、ネットワーク・デバイス、ルータ、ハブ、ゲートウェイ、又は他のデバイス内で具体化することができる。

コンピュータ・システム１１００は、バス１１０１に結合されたマイクロプロセッサ１１０４を含む。いくつかのシステムにおいて、複数のマイクロプロセッサ及び／又はマイクロプロセッサ・コアが採用可能である。コンピュータ・システム１１００は、情報及びマイクロプロセッサ１１０４によって実行されることになる命令を記憶するためにバス１１０１に結合された、ランダム・アクセス・メモリ（ＲＡＭ）又は他のストレージ・デバイスなどのメイン・メモリ１１１０を更に含む。マイクロプロセッサ１１０４のための情報及び命令を記憶するために、読み取り専用メモリ（ＲＯＭ）１１０８がバス１１０１に結合される。別の形のメモリとして、磁気ディスク、ソリッド・ステート・メモリ（例えばフラッシュ・メモリ）、又は光ディスクなどの不揮発性ストレージ・デバイス１１０６が、情報及び命令を記憶するために提供され、バス１１０１に結合される。本明細書で説明する機能を実行するために、他の特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は回路をコンピュータ・システム１１００に含めることができる。

コンピュータ・システム１１００はしばしば通信インターフェース１１１６を介してリモートに管理されるが、ローカル管理の場合、システム１１００は、コンピュータ・システム上で実行するソフトウェアの出力を表示するユーザ・ディスプレイ１１１４、並びに、ユーザ入力及び命令をコンピュータ・システム１１００に送る入力デバイス１１１５（例えばキーボード、マウス、トラックパッド、タッチスクリーン）に、コンピュータ・システム１１００を通信可能に結合する、周辺インターフェース１１１２を有することができる。周辺インターフェース１１１２は、ユニバーサル・シリアル・バス（ＵＳＢ）又は他の通信リンクなどのローカル・バスのためのインターフェース回路及び論理を含むことができる。

コンピュータ・システム１１００は、システム・バス１１０１と外部通信リンクとの間にリンクを提供する通信インターフェース１１１６に結合される。通信インターフェース１１１６はネットワーク・リンク１１１８を提供する。通信インターフェース１１１６は、イーサネット又は他のネットワーク・インターフェース・カード（ＮＩＣ）、ワイヤレス・インターフェース、モデム、光学インターフェース、又は他の種類の入力／出力インターフェースを表すことができる。

ネットワーク・リンク１１１８は、１つ又は複数のネットワークを介した他のデバイスへのデータ通信を提供する。こうしたデバイスは、ローカル・エリア・ネットワーク（ＬＡＮ）１１２６の一部である他のコンピュータ・システムを含む。更にネットワーク・リンク１１１８は、インターネット・サービス・プロバイダ（ＩＳＰ）１１２０を介したインターネット１１２２へのリンクを提供する。次にインターネット１１２２は、リモート・サーバ１１３０及び／又はリモート・クライアント１１３１などの他のコンピューティング・システムへのリンクを提供することができる。ネットワーク・リンク１１１８及びこうしたネットワークは、パケット交換、回路交換、又は他のデータ伝送手法を使用して、データを伝送することができる。

動作時にコンピュータ・システム１１００は、マイクロプロセッサ実行コードの結果として本明細書で説明する機能を実装することができる。こうしたコードは、メモリ１１１０、ＲＯＭ１１０８、又はストレージ・デバイス１１０６などの、持続性コンピュータ可読媒体から読み取るか、又はこれらに記憶することができる。他の形の持続性コンピュータ可読媒体は、ディスク、テープ、磁気媒体、ＣＤ−ＲＯＭ、光媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、及びＥＥＰＲＯＭを含む。任意の他の持続性コンピュータ可読媒体が採用可能である。実行コードは、（例えばインターフェース・バッファ、ローカル・メモリ、又は他の回路に記憶した後に）ネットワーク・リンク１１１８から読み取ることもできる。

クライアント・デバイスは、ウェブ・ブラウザ又は他のレンダリング・エンジンを実行する従来のデスクトップ、ラップトップ、又は他のインターネット・アクセス可能機械とすることができるが、前述のようにクライアントはモバイル・デバイスとすることもできる。例えば携帯電話、ページャ、携帯情報端末（例えばＧＰＲＳ ＮＩＣを備えるＰＤＡ）、スマートフォン・クライアントを備えるモバイル・コンピュータ、タブレットなどの、任意のワイヤレス・クライアント・デバイスを利用することができる。技法を実施することが可能な他のモバイル・デバイスは、ワイヤレス・プロトコルを使用してワイヤレスにデータを送信及び受信することが可能な任意のアクセス・プロトコル実行可能デバイス（例えば、ｉＯＳ（商標）ベース・デバイス、Ａｎｄｒｏｉｄ（商標）ベース・デバイス、他のモバイルＯＳベース・デバイスなど）を含む。典型的なワイヤレス・プロトコルは、ＷｉＦｉ、ＧＳＭ／ＧＰＲＳ、ＣＤＭＡ、又はＷｉＭａｘを含む。これらのプロトコルは、ＩＰ、ＴＣＰ、ＳＳＬ／ＴＬＳ、及びＨＴＴＰを備えた、従来のネットワーキング・スタックが構築されたＩＳＯ／ＯＳＩ物理及びデータ・リンク・レイヤ（レイヤ１及び２）を実装する。ＷＡＰ（ワイヤレス・アクセス・プロトコル）は、とりわけ、ネットワーク通信レイヤのセット（例えばＷＤＰ、ＷＴＬＳ、ＷＴＰ）並びにＧＳＭ及びＣＤＭＡワイヤレス・ネットワークで使用される対応する機能も提供する。

代表的な実施形態では、モバイル・デバイスは、ＧＳＭネットワーク用のデータ技術であるＧＰＲＳ（汎用パケット無線サービス）を介して動作する携帯電話である。一般的に、本明細書で使用されるモバイル・デバイスは、加入者固有情報を担持するスマート・カードである加入者識別モジュール（ＳＩＭ）、モバイル機器（例えば無線及び関連付けられた信号処理デバイス）、マン・マシン・インターフェース（ＭＭＩ）、及び外部デバイス（例えばコンピュータ、ＰＤＡなど）への１つ又は複数のインターフェースを含む、３Ｇ（又は次世代）準拠デバイスである。本明細書で開示される技法は、特定のアクセス・プロトコルを使用するモバイル・デバイスでの使用に限定されない。モバイル・デバイスは、典型的には、ＷｉＦｉなどのワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）技術に対するサポートも有する。ＷＬＡＮはＩＥＥＥ８０２．１１規格に基づく。本明細書で開示される教示は、モバイル・デバイス通信用の任意の特定モード又はアプリケーション・レイヤに限定されない。

上記は、限定的であるものと解釈されるべきでない本発明のある実施形態を提示していることを理解されたい。例えば、ある言語、構文、及び命令は例示のために上記に示されており、それらは限定的であるものと解釈されるべきでない。当業者であれば、本開示に鑑みて、及びその範囲及び趣旨に従って、他の可能な実装を理解するであろうと企図されている。添付の特許請求の範囲は、保護が求められる主題を定義する。

本明細書に示された商標はそれらのそれぞれの所有者の所有権であり、当該主題の性質を前提とし、いかなる場合も承認又は提携を暗示せず、識別及び説明の目的のみに使用されることに留意されたい。

Claims (29)

1. １つ又は複数のプロセッサを形成する回路及び前記１つ又は複数のプロセッサによって実行される命令を保持するメモリを有するサーバ内で動作可能な、コンピュータによって実行される方法であって、
   クライアント要求を受信すること、
   前記クライアント要求に応答して、リモート・ソースへの転送要求を生成すること、
   前記リモート・ソースからの前記転送要求への応答を受信することであって、前記応答は応答コンテンツ及び少なくとも１つのトークンを備えるものである、受信すること、
   前記応答コンテンツ及び前記少なくとも１つのトークンをローカルにキャッシュすること、
   前記クライアント要求に応答して、前記クライアントに対して前記応答コンテンツをサービスすること、
   前記少なくとも１つのトークンが無効であることを示すメッセージを受信すること、及び、
   前記応答コンテンツが、前記メッセージ内で無効であると示された前記少なくとも１つのトークンに関連付けられているため、後続のクライアント要求に応答してサービスするに際して、前記キャッシュされた応答コンテンツを無効であるとして取り扱うこと、
   を含む、コンピュータ実装方法。
2. 前記メッセージは、前記少なくとも１つのトークンが無効である旨の明示的アサーションを備える、請求項１に記載の方法。
3. 前記メッセージは、前記少なくとも１つのトークンが無効である旨の暗黙的アサーションを備える、請求項１に記載の方法。
4. 前記少なくとも１つのトークンは呼称及びシリアル番号又はタイムスタンプを備え、前記メッセージが前記呼称及び異なるシリアル番号又はタイムスタンプを含むため、前記メッセージは前記少なくとも１つのトークンが無効である旨を示す、請求項１に記載の方法。
5. 前記メッセージは前記リモート・ソースから受信される、請求項１に記載の方法。
6. 前記サーバはＣＤＮ内の複数のノードのうちの１つであり、前記メッセージは前記ＣＤＮ内のノードから受信される、請求項１に記載の方法。
7. 前記クライアント要求はアプリケーション・プログラマ・インターフェース（ＡＰＩ）からのサービス要求から成り、前記応答はＡＰＩ応答である、請求項１に記載の方法。
8. 前記リモート・ソースはコンテンツ・プロバイダに関連付けられた１つ又は複数のオリジン・サーバを備える、請求項１に記載の方法。
9. 前記サーバはＣＤＮ内のプロキシ・サーバである、請求項１に記載の方法。
10. 前記少なくとも１つのトークンは、前記応答を構築するために使用された前記リモート・ソースのデータベース内のデータに対応する、請求項１に記載の方法。
11. 前記少なくとも１つのトークンは、前記リモート・ソースのデータベース内の１次キーに対応する、請求項１に記載の方法。
12. 前記少なくとも１つのトークンは、前記応答を構築する際に使用されるデータを選択又は分類するために前記リモート・ソースによって使用されたデータ選択又は分類機能に対応する、請求項１に記載の方法。
13. 前記トークンは前記ソースでのデータ構造を示し、前記メッセージは前記データ構造内のデータへの更新後に受信される、請求項１に記載の方法。
14. 前記少なくとも１つのトークンは、前記応答を構築するために使用された前記ソースのファイルに対応する、請求項１に記載の方法。
15. 前記少なくとも１つのトークンは、前記リモート・ソースでのメモリ・オブジェクト・キャッシング・システム内へのキーに対応する、請求項１に記載の方法。
16. 複数の他の転送要求を送信すること、
    複数の他の応答を受信することであって、そのうちの少なくとも一部は前記少なくとも１つのトークンを備えるものである、受信すること、
    前記複数の他の応答をキャッシュすること、
    前記メッセージの受信後に、クライアント要求に応答してサービスするに際して、前記少なくとも１つのトークンを備える前記他の応答の各々を無効であるとして取り扱うこと、
    を更に含む、請求項１に記載の方法。
17. 前記少なくとも１つのトークンは呼称及びデータ範囲の識別子を備え、前記メッセージは前記呼称及び前記データ範囲内の少なくとも１つの特定のデータ値の識別子を備える、請求項１に記載の方法。
18. 前記応答は、応答コンテンツ及び前記少なくとも１つのトークンを保持するヘッダを備える、請求項１に記載の方法。
19. マイクロプロセッサと、１つ又は複数の前記マイクロプロセッサによって実行されるコンピュータ・プログラム命令を記憶するメモリとを備える、装置であって、前記コンピュータ・プログラム命令が実行されることによって、前記装置に、
    クライアント要求を受信すること、
    前記クライアント要求に応答して、リモート・ソースへの転送要求を生成すること、
    前記リモート・ソースからの前記転送要求への応答を受信することであって、前記応答は応答コンテンツ及び少なくとも１つのトークンを備える、受信すること、
    前記応答コンテンツ及び前記少なくとも１つのトークンを、前記装置に対してローカルなキャッシュ内にキャッシュすること、
    前記クライアント要求に応答して、前記クライアントに対して前記応答コンテンツをサービスすること、
    前記少なくとも１つのトークンが無効であることを示すメッセージを受信すること、及び、
    前記応答データが、前記メッセージ内で無効であると示された前記少なくとも１つのトークンに関連付けられているため、後続のクライアント要求に応答してサービスするに際して、前記キャッシュされた応答データを無効として取り扱うこと、
    を実行させる、装置。
20. １つ又は複数のプロセッサを形成する回路及び前記１つ又は複数のプロセッサによって実行される命令を保持するメモリを有するサーバ内で動作可能な、コンピュータによって実行される方法であって、
    １つ又は複数のトークンが付加されたコンテンツを受信すること、
    前記コンテンツ及び前記１つ又は複数のトークンをキャッシュすること、
    コンテンツに対するクライアント要求を受信すること、
    キャッシュされたコンテンツが前記要求に応答するものである旨を決定すること、
    前記キャッシュされた１つ又は複数のトークンの各々が有効であるかどうかを決定すること、
    前記１つ又は複数のキャッシュされたトークンのすべてが有効である旨を決定すると、前記クライアントに対して前記キャッシュされた応答をサービスすること、
    前記１つ又は複数のキャッシュされたトークンのうちの少なくとも１つが有効でない旨を決定すると、前記コンテンツについてリモート・ソースに転送要求を送信すること、
    を含む、コンピュータ実装方法。
21. 前記１つ又は複数のトークンをキャッシュする前に、前記応答に付加された前記１つ又は複数のトークンを装飾することを更に含む、請求項２０に記載の方法。
22. 前記応答と共に受信された前記１つ又は複数のキャッシュされたトークンのうちの所与の１つが有効であるかどうかの決定は、前記所与のトークンのタイムスタンプ及びシリアル番号のうちのいずれかを、現行トークンのキャッシュに記憶された対応するトークンのそれぞれのタイムスタンプ又はシリアル番号と比較することを含む、請求項２０に記載の方法。
23. 前記クライアント要求はＵＲＬに差し向けられており、前記キャッシュされたコンテンツが前記要求に応答している旨の前記決定は、前記ＵＲＬの少なくとも一部に対応するキャッシュされたコンテンツを捜し出すことに基づく、請求項２０に記載の方法。
24. 前記クライアント要求はＵＲＬに差し向けられており、前記キャッシュされたコンテンツが前記要求に応答している旨の前記決定は、前記ＵＲＬの少なくとも一部に対応するキャッシュされたコンテンツを捜し出すこと及び前記クライアント要求から抽出された別の値に基づく、請求項２０に記載の方法。
25. ＣＤＮサービス・プロバイダによって動作される複数の分散サーバを備えるシステムであって、前記複数の分散サーバは、アプリケーション・プログラマのインターフェース（ＡＰＩ）を介してアクセス可能なコンテンツに対するクライアントからの要求を受信し、
    クライアントからの前記要求に応答して、前記複数の分散サーバは、ＡＰＩコンテンツ・プロバイダに関連付けられた少なくとも１つのオリジン・サーバへのそれぞれの転送要求を生成し、
    前記複数の分散サーバは、前記少なくとも１つのオリジン・サーバからそれぞれのＡＰＩ応答を受信し、前記それぞれのＡＰＩ応答は応答データ及び１つ又は複数のトークンを備えるものであり、
    前記複数の分散サーバは、前記それぞれのＡＰＩ応答をそれぞれのローカル・キャッシュ内に記憶し、
    前記少なくとも１つのオリジン・サーバは、前記１つ又は複数のトークンのうちの少なくとも１つのトークンに差し向けられる無効化を生成し、前記無効化を前記ＣＤＮサービス・プロバイダによって動作される少なくとも１つの機械に送信し、
    前記少なくとも１つの機械は、前記無効化を前記複数の分散サーバに送信し、
    前記複数の分散サーバの各々は、前記無効化の受信の結果として、後続のクライアント要求に応答してサービスするに際して、前記少なくとも１つのトークンに関連付けられたローカルに記憶されたＡＰＩ応答を無効であるとして取り扱う、
    システム。
26. 前記少なくとも１つのオリジン・サーバは、データベースからデータを取得すること、及び、所与のＡＰＩ応答が生成された前記データベース内の前記データに対応する１つ又は複数のトークンを含めることによって、前記所与のＡＰＩ応答を生成する、請求項２５に記載のシステム。
27. 前記少なくとも１つのオリジン・サーバは、前記ＡＰＩをサポートするデータベース内の所与のデータの変更時に所与の無効化を生成し、前記無効化は変更された前記データに対応するトークンを備える、請求項２４に記載のシステム。
28. 前記複数の分散サーバは複数のキャッシング・プロキシ・サーバを備える、請求項２５に記載のシステム。
29. 前記少なくとも１つのオリジン・サーバは、データベースからデータを取得すること、及び、所与のＡＰＩ応答を作成する際に、前記応答データを選択又は分類するために前記少なくとも１つのオリジン・サーバによって使用された、データの選択又は分類機能に対応する１つ又は複数のトークンを含めることによって、前記所与のＡＰＩ応答を生成する、請求項２５に記載のシステム。