JP2022549076A - シングル・ページ・アプリケーションのキャッシャビリティの改善方法、システム、プログラム - Google Patents

Abstract

コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善する方法をする。この方法は、コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持し、グループのコンテンツ・アイテムの１つが更新されたと判定すると、コンテンツ・アイテムのグループのシード値を更新し、グループのコンテンツ・アイテムの１つを関連するシード値と共にキャッシング・システムにキャッシングし、キャッシング・システムによってＡＰＩ要求結果としてグループのコンテンツ・アイテムを要求するＡＰＩ要求を受信する。ここでＡＰＩ要求のパラメータは選択されたシード値である。

Description

本発明は一般に、コンテンツ・デリバリ・ネットワークにおけるコンテンツのキャッシングに関し、より詳細には、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティ（cachability）を改善するためのコンピュータ実装方法に関する。本発明はさらに、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するための関連するキャッシング・システムおよびコンピュータ・プログラム製品に関する。

あらゆる規模の企業に関してデータ、具体的にはいわゆる非構造化データの量が増えるほど、コンテンツ管理システムを使用してより多くの企業データを管理する必要がある。コンテンツ管理システムは、増え続けるドキュメントを記憶するためだけでなく、Ｗｅｂページなどのコンテンツ作成ツールとしても使用され得る。また、検索エンジンは、非構造化ドキュメントのみでなく、データ分析システムおよび他のソースからのレポートに関しても、企業のコンテンツ管理においてますます大きな役割を果たしている。

一方、コンテンツ・アイテムは、企業内で配布され、部分的には顧客およびサプライヤとも共有され、信頼性の高い一貫した方法でアクセス可能にされる必要がある。すなわち、ドキュメントおよび他のコンテンツ・アイテムは、常に最新バージョンで利用できる必要がある。これにより、ソースおよびターゲット（多くの場合、ブラウザを使用するクライアント・システム）の間にキャッシング・システムも含み得る配信ネットワークは、可能な最小の負担、すなわち、ネットワーク・トラフィックを搬送する必要がある。

現在、クライアント側でシングル・ページ・アプリケーション（ＳＰＡ）が使用されることがよくあり、その主な特徴は動的コンテンツを用いて動作することである。そのようなコンテンツは、新しい情報が利用可能になり次第、Ｗｅｂページの一部として更新され得る。これにより、Ｗｅｂページの他のコンテンツ要素は静的なままであり、定期的に更新されない場合がある。

中間キャッシングは、高性能のクライアント・アプリケーションを実現すると同時に、バックエンド・サーバへの要求の量（ひいては負荷）を許容可能なレベルに保つために非常に重要である。静的な不変のリソース（画像など）は、対応するＨＴＴＰキャッシュ制御ヘッダを追加することによって、キャッシュするのが容易である。

一方、ＲＥｓｔ ＡＰＩ（表現可能状態転送アプリケーション・プログラミング・インターフェース：representational state transfer application programming interface）応答のキャッシングははるかに困難であり、その理由は、結果が典型的には動的であり、有効期間に基づいてこれらの結果をキャッシングすると、その有効期間の間、データが古くなる可能性があるためである。この制限を克服するために、今日の多くのクラウド・サービスは、ＨＴＴＰの「ＥＴａｇ」および「ｉｆ－ｎｏｔ－ｍａｔｃｈ」アドレスを利用することにより、検証ベースのキャッシングを使用している。このアプローチにより、平均的なサーバ（またはキャッシュ・システム）は、対応するＨＴＴＰ要求をサービスの提供元に行うことによって、オブジェクトのキャッシュが古くなったか否かをチェックすることが可能になる。このアプローチにより、同じデータをソースからエッジ・サーバに繰り返し転送することが回避される。それは問題ないが、このアプローチでは依然としてソース・サーバへの検証要求が発生するので、典型的にはこのサーバおよびネットワークに大きな負担がかかる。さらに、検証自体は決して些細ではないことが多く、たとえば、検索ＡＰＩ呼び出しの結果は、目下の検索クエリによるフィルタリングに使用される多種多様なメタデータに依存し得る。

検証ベースのキャッシングは、典型的には、ＨＴＴＰキャッシングでは困難である。現在、ブラウザのキャッシュを無効化する技術的手段はない。一部のＣＤＮ（コンテンツ・デリバリ・ネットワーク）キャッシュは無効化をサポートしているが、ＣＤＮキャッシュの無効化は軽量な動作ではなく、典型的には、全てのエッジ・サーバ（すなわち、クライアント・システム）に行き渡るまでに長い時間がかかる。さらに、これは、典型的には、個々のパラメータ化されたＡＰＩ呼び出しのようなきめ細かいレベルで使用することを意図したものではない。

コンテンツ・デリバリ・システムにおいてコンテンツを管理するための方法に関連するいくつかの開示があり、米国特許出願公開第２０１７／００４６４３８号の文書では、クエリ受信器、ライブ・スクレイプ・システム、およびキャッシュ・マネージャを含む検索システムが開示されている。クエリ受信器は、第１のアプリケーションの第１のアプリケーション状態に関連する第１のクエリを受信するように構成される。第１のクエリは、ユーザ・デバイスによって要求される。キャッシュ・マネージャは、抽出されたコンテンツに基づく情報を記憶するように構成され、クエリ受信器が第１のクエリに一致する第２のクエリを受信したことに応答して、記憶された情報をユーザ・デバイスに選択的に提供してユーザに提示する。

米国特許出願公開第２０１４／０３７２５１５号の文書では、ネットワークを介してリモート・サーバと通信し、サーバによって提供されるコンテンツまたはサービスへのアクセスを提供するようになされたクライアントベースのコンピュータ・システムが開示されており、このシステムはストレージ・デバイスおよびキャッシュを含む。キャッシュは、ネットワークを介してサーバと通信し、クライアントからサーバへの要求をインターセプトし、サーバからの応答をストレージ・デバイスに記憶するようになされる。キャッシュはさらに、ネットワークを介してサーバに要求をいつ送信すべきかを自動的に決定するようになされる。

知られている解決策の欠点は、関係する様々なシステム、すなわち、コンテンツ・サーバ、キャッシング・システム、およびクライアント・システムの間のネットワーク・トラフィックが依然として継続的に比較的高いことである。これは特に、シングル・ページ・アプリケーションが動的に変化するコンテンツへのアクセスを提供する場合に当てはまる。

したがって、不十分な状況、すなわち、コンテンツ・デリバリ・ネットワークにおける不要なオーバーヘッド・ネットワーク・トラフィックを克服し、動的に変化するコンテンツへのアクセスを可能にするＷｅｂページを使用するコンテンツ・アイテムの最新バージョンへの信頼できるアクセスをなお提供することが必要であり得る。

本発明の一態様によれば、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのコンピュータ実装方法が提供され得る。この方法は、コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値（seed value）を保持することと、グループのコンテンツ・アイテムの１つが更新されたと判定すると、コンテンツ・アイテムのグループのシード値を更新することと、を含み得る。

さらに、この方法は、グループのコンテンツ・アイテムの１つを関連するシード値と共にキャッシング・システムにキャッシングすることと、キャッシング・システムによって、ＡＰＩ要求結果としてグループのコンテンツ・アイテムを要求するＡＰＩ要求を受信することであって、ＡＰＩ要求のパラメータは選択されたシード値である、受信することと、を含み得る。

本発明の他の態様によれば、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのキャッシング・システムが提供され得る。このシステムは、コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持するための手段と、グループのコンテンツ・アイテムの１つが更新されたと判定すると、コンテンツ・アイテムのグループのシード値を更新するための手段と、グループのコンテンツ・アイテムの１つを関連するシード値と共にキャッシング・システムにキャッシングするための手段と、キャッシング・システムによって、ＡＰＩ要求結果としてグループのコンテンツ・アイテムを要求するＡＰＩ要求を受信するための手段であって、ＡＰＩ要求のパラメータは選択されたシード値である、受信するための手段と、を備え得る。

コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するための提案したコンピュータ実装方法は、複数の利点、技術的効果、貢献、または改善、あるいはそれらの組合せを提供し得る。

クライアントと、典型的にはデータ・センタのバックエンド・サーバとして実装されるコンテンツ管理システムとの間のネットワーク・トラフィックは大幅に削減され、その結果、利用可能なリソースがより効率的に使用される。バックエンド・コンテンツ・サーバ・システムまたはコンテンツ管理システムと、典型的には情報をレンダリングするためのブラウザが備えられたクライアント・システムなどの情報消費デバイスとの間の通信ネットワークに典型的に実装されるキャッシュ・システムは、不要な無制御の要求をバックエンド・システムに送信するのではなく、分散型などのキャッシング・システムにキャッシングされたコンテンツ・アイテムを可能な限り最新に保てるようになされ得る。このために、クライアントとキャッシュ・システムとの間のインテリジェントな通信プロトコルは、クライアント・システム内のコンテンツ・アイテムの現実性（actuality）を制御するための手段を提供し得る。

キャッシュ・システムは、キャッシュ・システムにキャッシングされたコンテンツ・アイテムが陳腐化している（outdated）と判定された場合にのみ、コンテンツ・アイテム、具体的にはコンテンツ・アイテムの更新バージョンをコンテンツ管理システムに要求し得る。これは、同じＷｅｂページ（またはＷｅｂアプリケーション）上に静的コンテンツならびに動的に変化するコンテンツを含むシングル・ページ・アプリケーションが使用される環境で特に有利であり得る。

コンテンツ・アイテムの粒度および制御ならびにそれらの現実性は、コンテンツ・アイテムのグループを定義して設定され得る。これにより、バックエンド・システムおよびキャッシュ・システムの間のネットワークの利用可能な帯域幅、ならびにキャッシュ・システムおよびクライアントの間のネットワーク容量に依って、きめ細かいまたは粗いキャッシュ管理戦略に従い得る。また、この設定性（configurability）は、既存のリソースがより無駄なく利用される方法に影響を与え得る。

本明細書で提案している、新規のキャッシュ・シード・パラメータを利用する新たなキャッシング・アプローチにより、ＡＰＩ応答を無限時間キャッシュすることが可能になり得る。これを実現するために、関連するクラウド・サービスは、サービスによって公開されるアーティファクト（すなわち、コンテンツ・アイテム）のタイプごとの現在のキャッシュ・シード値（たとえば、コンテンツ用の１つのキャッシュ・シード、およびアセット用の別のキャッシュ・シード）を追跡する。そのようなタイプのインスタンスが作成、変更、または削除されるたびに、対応するキャッシュ・シード値は新たな一意の値（これは従来使用されたことがなかった）に更新され得る。クライアントは、対応するＲＥｓｔ ＡＰＩを介して所与のタイプの現在のシード値を取り出し得る。

さらに、このアプローチにより、ユーザは、クライアント側でロードされる情報がどれだけ新しいものである必要があるかを決定することが可能になり得る。この情報の新しさはロードされるキャッシュ・シード値と同じである。すなわち、データが１分間古くなることをクライアントが許容し得る場合、クライアント・システムはシード値を毎分再ロードする。クラウド・サービス（すなわち、コンテンツ管理システム）によって提供されるライフ（life）・データの更新がないときは、シード値は後続のＡＰＩ呼び出しで不変であり、依然としてＣＤＮキャッシュ、すなわち、キャッシュ・サーバから完全にサービス提供される。このアプローチは、特定の時間に更新されるが必ずしも信頼できる安定したスケジュールで更新されないサイトにとって特に有利であり得る。これはＷｅｂサイトの典型的なケースを表し得る。更新後、全てのクライアント・システムは最長で１分後に現在のデータを確認するが、変更がない長期間の間、ＣＤＮのキャッシュ・システムによって全ての応答が処理される。クライアントは、キャッシュ・シード・パラメータを省略するか、または再ロードすることによって、常に最新のデータを自由にロードすることができる。

さらに、ＣＤＮ中間レイヤ、すなわち、キャッシュ・サーバからの更新チェックが頻繁に回避されるので、バックエンド・サーバ（すなわち、ＣＭＳ）での負荷は大幅に削減され得る。これにより、バックエンド・サーバへの通常の要求に対する応答時間が良好になり、計算能力の要件が低くなり得る（すなわち、より小型のより安価なサーバになり得る）。

以下では、システムならびに方法に適用可能な本発明の概念の追加の実施形態について説明する。

１つの有利な実施形態によれば、この方法は、キャッシング・システムにおいて、具体的にはＡＰＩ要求を受信した後に、関連するシード値と選択されたシード値との相違を特定すると、ＡＰＩ要求結果として更新されたそれぞれのコンテンツ・アイテムを、具体的にはコンテンツ管理システムに要求することをさらに含み得る。要求およびキャッシング・システム上のコンテンツ・アイテムのシード値が同一である場合、キャッシング・システムは単にキャッシング・システムに記憶されたシード値を返す。しかしながら、シード値が変更されていない（すなわち、クライアントおよびキャッシング・システムで同一である）ので、何も実行されず、具体的には、バックエンド・システムに要求が全く送信されなくてもよい。

他の有利な実施形態によれば、この方法は、キャッシング・システムにおいて、グループのコンテンツ・アイテムに関するＡＰＩ要求を定期的に受信することをさらに含み得る。これはクライアントのブラウザでＳＰＡのコンテンツを定期的にリフレッシュするために実行され得る。「定期的に」とは、「定期的な時間間隔で」を意味するか、またはブラウザのクライアント・システムが受け取る他のイベントによってトリガされることを意味し得る。たとえば、コンテンツ・アイテムのコンテキストに属する予測不可能な時間間隔でメッセージが受信され、そして、シード値が異なる場合、クライアント／ブラウザは、更新されたコンテンツ・アイテムを取得するために、キャッシング・システムに要求を自動的に送出し得る。これは動的Ｗｅｂページにとって特に価値があり得る。

この方法の１つの有用な実施形態によれば、ＡＰＩ要求は、ＡＰＩ要求結果として異なるコンテンツ・アイテム・タイプのグループに属するアイテムのコンテンツを要求し得る。これにより、上述のメカニズムは、異なるグループのコンテンツ・アイテムにも適用され得る。これはまた、異なるコンテンツ・アイテム・タイプを扱う動的Ｗｅｂページにとって特に価値があり得る。したがって、グループは、ＣＭＳの全てのコンテンツ・アイテムのうちの、１つのコンテンツ・タイプの全てのコンテンツ・アイテムを表し得、すなわち、１つのタイプの全てのコンテンツ・アイテムが１つのグループに含まれる。この場合、グループは不要になり、タイプのみに注目してもよい。

この方法の１つの許容可能な実施形態によれば、ＡＰＩ要求のパラメータは、異なるタイプのシード値を入力とするＸＯＲ関数の結果であり得る。これはネットワーク・トラフィックを低く保つための簡単な方法を表し、その理由は、異なるコンテンツ・アイテム・タイプの２つ以上のシード値のシード値が結合されるためである。このため、異なるコンテンツ・アイテム・タイプの２つのシード値が変化した場合、またはクライアントによって要求された場合、ＸＯＲ関数を２つのシード値に適用することによって、既知のシード値を結合することができる。

高度な実施形態によれば、この方法は、キャッシング・システムにおいて、ＡＰＩ要求結果のコンテンツ・アイテムのキャッシュ有効期間として、事前定義されたキャッシュ有効期間閾値以上の時間値を使用することをさらに含み得る。この時間値は、技術的に可能な最大値（たとえば、最大の整数値）に近いか等しくてもよい。これにより、コンテンツ・アイテムは、実際に陳腐化するまでキャッシング・システム上にキャッシングされ得る。ブラウザ／クライアントの要求によるコンテンツ・アイテムの要求が原因で、誤った更新がトリガされなくなり得る。

他の任意選択の実施形態によれば、この方法は、コンテンツ・アイテムのキャッシュ有効期間として、事前定義されたキャッシュ有効期間閾値以上の、たとえば、技術的に可能な最大値に近いまたは等しい時間値を、具体的にはキャッシング・システムからクライアントに送信することを含み得る。これにより、クライアント／ブラウザは、キャッシング・システムでシード値の相違が特定されるまで、コンテンツ・アイテムの有効期間がほぼ無制限であると想定する。

さらに強化された１つの実施形態によれば、この方法は、グループのコンテンツ・アイテムの１つに関連するシード値の更新を示す通知を、具体的にはＣＭＳサーバによって、Ｗｅｂソケットなどのプッシュ技術を使用してキャッシュ・サーバをバイパスすることによって、クライアントにプッシュすることをさらに含み得る。プッシュ技術の仕組みにより、クライアントは通知を受信し、シード値が期限切れになっている可能性があると判定し得る。このとき、クライアントは、新たに受信した関連するシード値と共に、コンテンツ・アイテムの更新バージョンをキャッシュ・システムに要求し得る。キャッシング・システムは、キャッシングされたコンテンツ・アイテムのシード値とＡＰＩ要求で受信したものとが異なると判定し得る。これに基づいて、キャッシング・システムは、新たなシード値を有する更新されたコンテンツ・アイテムをコンテンツ管理サーバに要求し得る。

この方法の１つの実際的な実施形態によれば、コンテンツ・アイテムは、ＳＰＡの要素または別の方法で動的に生成されるコンテンツであり得る。このコンテキストでは、本明細書で提案した概念は、その完全な利点のセットをもたらし得る。

方法の他の実際的な実施形態によれば、ＡＰＩ要求結果は検索クエリの結果であり得る。これは提案した概念の一般的な使用例を表し得る。しかしながら、コンテンツ・アイテムは、ストリーミング分析またはビジネス・インテリジェンスおよびレポート・システムによっても配信および管理され得る。

１つの統合された実施形態によれば、この方法は、グループのコンテンツ・アイテムの１つを関連するシード値と共にキャッシング・システムにキャッシングすることの前に、キャッシング・システムにおいてＡＰＩ要求を、具体的にはクライアントから受信することと、ＡＰＩ要求結果を、具体的にはＣＭＳに要求することと、をさらに含み得る。これにより、ループを閉じることができ、陳腐化したコンテンツ・アイテムがクライアントに配信されて使用されることがなくなり得る。

この方法の他の強化された実施形態によれば、コンテンツ・タイプのシード値のいずれもが、具体的にはキャッシング・システムもしくはＣＭＳ、または異なるＣＭＳまたは検索システムの複数のコンテンツ・アイテムなどのシード値を扱う独立したサポート・システムに要求可能であり得る。

さらに、実施形態は、コンピュータまたは任意の命令実行システムによって、またはそれらに関連して使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセス可能な、関連するコンピュータ・プログラム製品の形態をとり得る。この説明の目的で、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによって、またはそれらに関連して使用するために、プログラムを記憶、通信、伝搬、または輸送するための手段を含み得る任意の装置であり得る。

本発明の実施形態は、様々な主題を参照して説明していることに留意されたい。具体的には、いくつかの実施形態は、方法タイプの請求項に関連して説明しているが、他の実施形態は、装置タイプの請求項に関連して説明している。しかしながら、当業者は、上記および下記の説明から、別段の通知がない限り、あるタイプの主題に属する特徴の任意の組合せに加えて、異なる主題に関連する特徴間の、具体的には、方法タイプの請求項の特徴と装置タイプの請求項の特徴との間の任意の組合せも本文書内に開示していると見なされることを察するであろう。

上記で定義した態様および本発明のさらなる態様は、以下に説明する実施形態の例から明らかであり、実施形態の例を参照して説明するが、本発明はそれらに限定されない。

本発明の好ましい実施形態を単なる例として、以下の図面を参照して説明する。

コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するための本発明のコンピュータ実装方法の一実施形態のブロック図である。 異なるデータ・センタ内の２つのＣＭＳ、キャッシュ・システム、およびクライアントを有する一実施形態のブロック図である。 ＣＤＮからキャッシュ・シード・サービスによってサポートされるコンテンツ・サービスへのデータフローの一実施形態のブロック図である。 コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するための本発明のキャッシング・システムの一実施形態のブロック図である。 図４によるキャッシング・システムを含むコンピューティング・システムの一実施形態を示す図である。

本説明の文脈では、以下の慣例（conventions）、用語、または表現、あるいはそれらの組合せを使用し得る。

「キャッシャビリティ」という用語は、発信元のシステムよりも効率的な方法でキャッシングされるコンテンツ・アイテムの特性を表し、すなわち、データ、具体的にはＷｅｂページのデータ、さらに具体的にはシングル・ページ・アプリケーションのデータを記憶して、より高速にアクセスできるようにするシステムの能力を表すものである。本文書の文脈でのシステムおよび焦点は、クライアント・システムからコンテンツ・ストレージ・バックエンド・システムへのネットワーク・トラフィックを削減する（ひいてはバックエンド・サーバへの負荷も軽減する）ことを可能にし得るキャッシング・システムである。キャッシング・システムは、キャッシング・システムに現在記憶されている、すなわち、キャッシングされているコンテンツ・アイテムが古いことが明らかな場合にのみ、特定のコンテンツ・アイテムをクライアント・システムへの配信のためにコンテンツ・ストレージ・バックエンド・システム（たとえば、コンテンツ管理システム）に要求することができる。

「ＡＰＩ要求結果」という用語は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）への関数呼び出しに応答したシステムの回答を表し得る。

「コンテンツ・デリバリ・システム」という用語は、あらゆる種類のコンテンツ・アイテムを記憶する単一コアの分散システムを示す場合がある。これは、コンテンツ管理システム、トランザクション・システム、またはその両方の組合せであってもよい。

「一意のシード値」という用語は、コンテンツ・アイテムの特定のクラスまたはグループに一意の数値を表し得る。数値の代わりに、英数字の値または他の任意のデジタル・パターンも使用され得る。一意のシード値、または単にシード値の１つの例は、単一のコンテンツ・アイテムのバージョン番号であり得る。しかし、本明細書で提案する概念はコンテンツ・アイテムのグループに基づいており、グループ内のコンテンツ・アイテムの１つが変更される場合、一意のシード値が変更される可能性がある。グループは、コンテンツ管理システム（または複数のコンテンツ管理システムの組合せ）における特定のタイプの全てのコンテンツ・アイテムで構成されてもよいし、特定のタイプのコンテンツ・アイテムのサブグループ、あるいは主題に従って編成された異なるタイプのコンテンツ・アイテムのグループであってもよい。

「コンテンツ・タイプ」という用語は、コンテンツ・アイテムのデータ・タイプを示すことがある。典型的なコンテンツ・タイプには、テキスト、画像、音声、ビデオ、およびそれらの組合せが含まれるが、これらに限定されなくてもよい。しかし、任意の構造化データ、半構造化データ及びいわゆる非構造化データが使用されてもよい。具体的には、１つのグループは、１つのコンテンツ・タイプの全てのコンテンツ・アイテムで構成されてもよい。

「キャッシング」という用語は、高速アクセスを確保するためのデータの中間記憶を表し得る。データの記憶は、典型的にはデータ・シンクの近くで実行され得る。

「ＡＰＩ要求」という用語は、応答をトリガするためにアプリケーション・プログラミング・インターフェースをアドレス指定する関数呼び出しを表し得る。典型的には、応答はデータのセットである。ＡＰＩ要求は典型的には、折返し受信したいデータのセットを指定する１つまたは複数のパラメータを含む。

「パラメータ」という用語は、本明細書では関数呼び出しの意味でのパラメータ、すなわち、ＡＰＩ要求の一部としての変数を表し得る。特定のパラメータは、クライアント・システムにおいて／クライアント・システムのために要求された、現在利用可能なまたは新たに共有されるコンテンツ・アイテムの特定のバージョンを示す、たとえば、クライアント・システムのブラウザに表示される、コンテンツ・アイテムのシード値であり得る。

「ＸＯＲ関数」という用語は、排他的に入力ビットの一方が論理「１」であり、他方の入力ビットが論理「０」である場合に、真出力を提供するビット演算を表し、ＸＯＲは「排他的論理和（exclusive or）」の略である。この排他的関数（exhaust function）は、より長いビットのシーケンス（たとえば、バイト）にも適用され、その場合、この関数は典型的にはビット単位で実行される。あるいは、ハッシュ関数が使用され得る。

「キャッシュ有効期間閾値」という用語は、タイムスタンプとしても実装可能な数値であって、その経過後に、キャッシングされたコンテンツ・アイテムが期限切れになり得る、すなわち、実際のものではなくなり、または陳腐化し得る数値を表し得る。

「シングル・ページ・アプリケーション」（ＳＰＡ）という用語は、ごく一部しか更新されない場合に、新しいＷｅｂページ全体をサーバからロードするのではなく、Ｗｅｂページのサブセットを動的に書き換えることによって、ユーザとやりとりするＷｅｂアプリケーションまたはＷｅｂサイトを表し得る。このアプローチにより、連続するページ（またはページの一部）間のユーザ体験の中断が回避され、アプリケーションがよりデスクトップ・アプリケーションのように振る舞い得る。ＳＰＡでは、必要なコード、たとえば、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、およびＣＳＳ（カスケード・スタイル・シート）が１回のページ・ロードで取り出され、または適切なリソース、すなわち、コンテンツ・アイテムが動的にロードされ、必要に応じて、典型的にははユーザ・アクションに応答してページに追加される。ページは過程のどの時点でも再ロードされず、制御が他のページに転送されることもない。ユーザとこのシングル・ページ・アプリケーションとのやりとりは、多くの場合、目に見えないところでのＷｅｂサーバとの動的な通信を含み得る。

「中間レイヤ」という用語は、コンテンツ管理バックエンド・システムとクライアント・システムとの間に挟まれたシステム、すなわち、本文書の文脈ではキャッシング・システムを表し得る。

「３層コンテンツ・デリバリ・システム（3-tier-content deliverysystem）」という用語は、ネットワークおよびキャッシング・システムの中間レイヤを介してコンテンツ・ストレージ・システムからクライアントにコンテンツ・アイテムを配信するためのアーキテクチャを表し得る。

「コンテンツ管理システム」（ＣＭＳ）という用語は、デジタル・コンテンツ、すなわち、コンテンツ・アイテムの作成および変更を管理することを可能にするハードウェア・システムおよびソフトウェア・コンポーネントの組合せを表し得る。これらのシステムは、典型的には、コラボレーション環境において複数のユーザをサポートすることによって、異なるスタイルの統治およびワークフローでドキュメント管理を実行することが可能になる。本文書の文脈では、典型的には、コンテンツ・アイテムは、シングル・ページ・アプリケーション専用であり得るＣＭＳによって管理される。ＣＭＳのもう１つの特徴は、コンテンツの作成、公開、およびコンテンツ・アイテムの表示が分離されていることである。

「クライアント」という用語は、たとえば、キャッシング・システム、ネットワーク・サーバ、バックエンド・システム、ストレージ・システムなどの他のシステムのネットワークの情報およびサービスにアクセスするためのユーザ・インターフェースとして機能するデジタル・ネットワーク内のエンド・ポイント・システムを表し得る。クライアント・システムの例には、パーソナル・コンピュータ、ワークステーション、タブレット・コンピュータ、携帯電話、または他の任意のモバイル・デバイスもしくは特別な専用デバイスが含まれる。この意味で、受信器を有するカメラ、または関連するコンピューティング・リソースを有する車の中のスクリーンもクライアントになり得る。

「コンテンツ・デリバリ・ネットワーク」（ＣＤＮ）またはコンテンツ・ディストリビューション・ネットワークという用語は、プロキシ・サーバおよびそれらに関連するデータ・センタの地理的に分散したネットワークを表し得る。目標は、サービスを区域的に分散させてエンドユーザに関連付けることによって、高可用性および高性能を提供することであり得る。このため、ユーザの特定のグループは、要求したコンテンツを主に特定のデータ・センタから受信し、例外的にのみバックアップ・データ・センタから受信し得る。データ・センタは、たとえば、メディア・ファイル、ソフトウェア、ドキュメント、アプリケーション、ライブ・ストリーミング・データ、オンデマンド・ストリーミング・データ、ソーシャル・メディア・サイトへのアクセスなど、ダウンロード可能なオブジェクトの形態でデジタル・コンテンツを配信し得る。

以下に、図の詳細な説明を示す。図中の全ての説明（instructions）は概略的なものである。最初に、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するための本発明のコンピュータ実装方法の一実施形態のブロック図を示す。その後、さらなる実施形態、ならびにコンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのキャッシング・システムの実施形態を説明する。

図１は、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのコンピュータ実装方法１００の好ましい実施形態のブロック図を示している。コンテンツ・デリバリ・システムは異なるレイヤ、すなわち、バックエンド・サーバ、キャッシング用の中間レイヤ、および情報コンシューマ・レイヤ、すなわち、クライアントで実装され得る。したがって、コンテンツ・デリバリ・システムは、クライアント・システムにコンテンツを提供するようになされる。この方法は、コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持すること１０２を含む。コンテンツ・タイプは、単純な形態では、コンテンツ・デリバリ・システム内の全てのテキスト・コンテンツ・アイテムに関連し、より複雑な実装では、コンテンツ・タイプ（場合によりサブタイプも含む）は、コンテンツ・タイプのサブセット（たとえば、特定の形式のテキスト、もしくは特定の包括的な主題に関連するテキスト）を含み、または様々な単純なコンテンツ・タイプに関連し、コンテンツの主題（たとえば、特定の会議に関連するレポート、画像、ビデオ・クリップ）に焦点を当て得る。コンテンツ・タイプには、テキスト（テキスト・タイプのサブタイプには、テキストの様々な形式、たとえば、ＰＤＦ形式、ＴＸＴ形式、ＨＴＭＬ形式、ＯｐｅｎＤｏｃｕｍｅｎｔ形式などが含まれ得る）、ピクセル・グラフィックもしくはベクター・グラフィック、音声ファイル、ビデオ・ストリーム、ならびに検索エンジン、データベースなどからの結果が含まれ得る。

方法１００はまた、グループのコンテンツ・アイテムの１つが更新されたと判定された場合１０４、コンテンツ・アイテムのグループのシード値（たとえば、バージョン番号またはハッシュ値と類似のもの）を更新すること１０６を含む。

方法１００はまた、グループのコンテンツ・アイテムのうちの１つ（すなわち、少なくとも１つ）を関連するシード値と共にキャッシング・システムにキャッシングすること１０８を含む。このとき、コンテンツ・アイテムは、クライアント・システムによって（典型的にはブラウザ内であるが、他の任意のデータ受信アプリケーション内にも）取り入れることが可能な（digestible）任意のデータ、すなわち、静的コンテンツ、動的コンテンツ、検索結果のリストなどであり得る。キャッシング・システムは、ＣＤＮの一部、すなわち、関連する配信サーバであり得る。しかしながら、配信サーバは、バックエンドＣＭＳシステムも実行するハードウェア・システムのサービスとしても実装されることにも気付くであろう。これはＣＤＮの特定の実装または構成に依存し得る。

さらに、方法１００はまた、キャッシング・システムによって、ＡＰＩ要求結果としてグループのコンテンツ・アイテムを要求する、具体的にはクライアント／関連するブラウザからのＡＰＩ要求を受信すること１１０であって、ＡＰＩ要求のパラメータは選択されたシード値である、受信すること１１０を含む。選択されたシード値を示すために使用されるパラメータは、クライアントおよびＣＤＮの間の通常の既存のＡＰＩ呼び出しの拡張と考えられる。従来のＡＰＩ呼び出しが使用される場合、シード値パラメータがなくなり、これはキャッシング・サーバが従来の条件下で動作することを意味する。このため、新たに提案した方法は、従来のコンピューティング環境、ならびに本明細書で提案した概念をサポートするコンピューティング環境で使用され得る。いかなる場合でも、技術的な競合は発生しない。

図２は、異なるデータ・センタ内の２つのＣＭＳ、キャッシュ・システム２１２、および複数のクライアント・システム２１８を有する一実施形態のブロック図を示している。コンテンツ・デリバリ・ネットワークは、例示的には、第１のデータ・センタ２０２および第２のデータ・センタ２２０を含み得る。両方のデータ・センタ２０２、２２０はそれぞれコンテンツ管理システム（図示せず）を含み、各コンテンツ管理システムは、オーサリング・コンポーネント２０４、２２２、および配信コンポーネント２０８、２２６を有する。コンテンツ・アイテム（図示せず）が作成または更新された場合、それぞれのオーサリング・システム２０４、２２２からそれぞれの配信システム２０８、２２６に公開すること２０６、２２４ができる。作成もしくは更新された各コンテンツ・アイテム（ＣＩ）、またはコンテンツ・アイテムが属するグループは、関連するシード値を有する。作成されたコンテンツ・アイテムは、特定のコンテンツ・アイテム・グループのシード値１２３４を有し得る。コンテンツ・アイテムが更新（すなわち、変更）される場合、シード値も同様に値１２３５などに更新され得る。

対応するコンテンツ・アイテムが、第２のデータ・センタ２２０に存在し得る。特別なサービスが、オーサリング・コンポーネント２０４とオーサリング・コンポーネント２２２との間（参照番号２２８と比較されたい）、ならびに配信コンポーネント２０８と２２６との間（参照番号２３０と比較されたい）の同期を容易にし得る。第２のデータ・センタ２２０内のまだ更新されていないコンテンツ・アイテムのシード値は、たとえば、９８７６であり、更新後は９８７７になり得る。コンポーネント間の同期は、特定のコンテンツ・アイテムが変更された可能性があることを示し得る。これに基づいて、関連するコンテンツ・アイテムの第２のデータ・センタでのシード値が、自律的にシード値を変更し得る。

さらに、図２は、特定のコンテンツ・アイテム２１４およびそれに関連する実際のシード値をキャッシングするようになされたＣＤＮの一部としてのキャッシング・サーバ２１２を示している。クライアント・システム２１８がＡＰＩ呼び出しおよびネットワーク接続２１６を介してキャッシング・システム２１２に特定のコンテンツ・アイテムを要求し、特定のコンテンツ・アイテムがキャッシング・システム２１２で利用可能でない場合、キャッシング・システム２１２はネットワーク接続２１０を介して第１のデータ・センタ内のＣＭＳのコンテンツ・アイテムに（ＡＰＩ呼び出しを介して）要求を転送する。

このために、ＳＰＡの一部分を更新する目的で、クライアント・システム２１８は、ＡＰＩ要求の追加パラメータとしての特定のシード値と共にコンテンツ・アイテムを要求する。ＡＰＩ要求内のシード値と、キャッシング・システム２１２内のコンテンツ・アイテム２１４のシード値とが同一である場合、バックエンド・システムに関しては何もする必要がない。キャッシング・システムは、単にシード値をクライアントに返す。２つのシード値が異なる場合、キャッシング・システム２１２は、要求をバックエンド・システム（すなわち、ＣＭＳ）に転送し、データ・センタ２０２のコンテンツ管理システムからコンテンツ・アイテムを更新する。このため、通常、ネットワーク・トラフィックは劇的に減少する。

一般的な考え方は、コンテンツ・アイテムの分類ごとに、すなわち、グループまたはコンテンツ・タイプあるいはその両方ごとに、シード値を追跡することである。シード値は、データ・センタＩＤおよび分類情報をエンコードする必要がある。単純な形態の分類は、単一の小文字、すなわち、ｃ＝コンテンツ、ａ＝アセット、ｌ＝レイアウト・マッピング、ｔ＝タイプ、ｉ＝イメージ・プロファイル、小文字のｏ＝その他、によって行われ得る。このため、ワシントンのデータ・センタのコンテンツ・アイテムＡの要求は、シード値ｗｄｃ：ｃ：１２３４を含み、同様に、フランクフルトのアセット・データ・センタのシード値は、ｆｒａ：ａ：５６７８としてエンコードされる。集約されたシード値を算出するために、ＸＯＲ関数が使用され得る。関与する全ての小文字がアルファベット順に並べ替えられる場合、アセットおよびコンテンツの結合シード値は（例示的には）ｆｒａ：ａｃ：９０１２になる。しかしながら、そのような形式はユーザには公開されることはなく、キャッシュ・シード・サービスによって生成される非表示のシード値として使用され得る。

このキャッシュ・シード・サービスは、特定のキャッシュ・シード・サービスＡＰＩ呼び出しを介してアクセス可能であり得る。シード値をロードするためのクライアント・システムからの呼び出しは、次の形態を有し得る：
GET/delivery/v1/seeds?classifications={classifications}
そして、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔオブジェクト表記：JavaScriptObject Notation）応答は、所与の分類の結合シード値と、分類ごとの個別シード値とを含み得る。たとえば、/delivery/v1/seeds?classifications=content,asset,content-typeは以下を返し得る：
{
”content”: “fra: c: 1234”,
“asset”: “fra:a:354354”,
”content-type”: “fra:t: 3253466”,
“combined”:“fra:act 348767593”:
}

キャッシュ・シード・サービスＡＰＩの他の例は、次のシード検証呼び出し（ディスパッチャによるコート（court））であろう：
GET /delivery/v1/seed/validation/{seed-value}
関連するＪＳＯＮ応答は検証結果を含む。失格の場合は、有効なシード値が返される。たとえば、/delivery/v1/seeds/validation/ Classifications =wcd:ac:123456は以下を返し得る：
{
“valid”: true
}または
{
“valid”: false,
“value”: “fra:ac: 32465231”
}

少なくとも３つのケースを区別する必要がある。

ケース１：ＣＤＮでのキャッシュ・ミス
クライアントは要求と共にキャッシュ・シード値を送信し、キャッシュ・ミスがＣＤＮ、たとえばキャッシング・システム２１２で発生する。次いで、バックエンド・サーバの一部としてのディスパッチャ（図３と比較されたい）は、シード値内に提供されたデータ・センタ情報を使用して、シード値がそのグローバル・データ・センタで生成されたか否かをチェックすることができる。提供されたシード値が現在のシード値と一致する場合、ディスパッチャは通常通りＡＰＩ要求を引き渡し（dispatch）、設定されたエッジ・コントロール・キャッシュ・ヘッダ（非常に長い最大寿命（maximum age））をセットすることができる。

提供されたシード値が一致しない場合、ディスパッチャはキャッシュ・シード・サービスを呼び出して現在のデータ・センタの有効なシードを取得し（/validate...を使用）、シード値を現在の値に単に置き換えた同ＵＲＬへのリダイレクトを送信する。これは非常にまれなケース（たとえば、データ・センタのフェイルオーバーの場合）でしか発生しないはずであるということに気付くであろう。これにより、別のデータ・センタで生成された特定のコンテンツ・アイテム（またはコンテンツ・アイテムのグループ）のより最近のシード値の途中段階データ（stage data）が提供されないようになり得る。

ケース２：ＣＤＮ上の期限切れのシード値
クライアント２００がそれぞれのＡＰＩ要求と共にキャッシュ・シード値を送信し、ＣＤＮに期限切れのキャッシュ値がある場合、ディスパッチャはデータ・センタ情報を検証することができ（上記と同様）、一致した場合、ディスパッチャは実際のＡＰＩ呼び出しを支障なくスキップし、代わりに３０４コード「変更なし（not modified）」を返すことができる。その結果、ＣＤＮはキャッシュ値がまだ有効であると通知され、ＣＤＮはこれを有効期限付きキャッシュ（expiration cache）に戻す。一致しない場合、リダイレクト・コマンドが送信される（上記のキャッシュ・ミス・ワークフローと同じ）。

ケース３：ＣＤＮ上の有効期限内のキャッシュ・ヒット
この場合、ＡＰＩ要求の結果は通常通りＣＤＮから提供される。

図３は、ＣＤＮからキャッシュ・シード・サービス３１０によってサポートされるコンテンツ・サービスへのデータフローの一実施形態のブロック図３００を示している。ＡＰＩ要求は、例示的にはＡＫＡＭＡＩシステムであり得る（他のＣＤＮ管理システムも同様に使用され得る）コンポーネント３０４によって管理されるＣＤＮに入来３０２し得る。ＣＤＮ管理コンポーネント３０４は、要求をバックエンド・サーバに送信する。バックエンド・サーバはディスパッチャ３０６を含み、ディスパッチャ３０６から要求がコンテンツ配信用の特定のサービス３０８に転送される。並行して、ディスパッチャ３０６は、キャッシュ・シード・サービス３１０と連絡をとる。キャッシュ・シード値内のデータ・センタ情報が現在のデータ・センタと一致しない場合、キャッシュ・シード・サービスが呼び出され、それぞれのリダイレクト・コマンドが送信される。一致した場合、引き渡しが従来のシステムと同様に実行され、長いｍａｘ－ａｇｅ値が送信される。

クライアント側でのキャッシュ・シード管理は次のように実行され、全てのクライアントは、自由にキャッシュ・シードの概念を無視し、従来のシステムとして動作することができる（キャッシングは知られているシステムと同じくらい不十分なままである）。しかしながら、特定のコンテンツ・アイテムまたはそのクラスの現在のキャッシュ・シード値が、パブリックＡＰＩ呼び出しを介して利用可能である。キャッシュ・シード値は「ページ」レンダリングのコンテキストでも利用可能になされ、その後の要求で有効なシード値を使用できるようになる。クライアントは、適切な時間に、たとえば一定の時間間隔で（たとえば、毎分）、またはユーザが操作する更新ボタンによってトリガされて、シード値を自由に再ロードすることができる。

明らかにまれなケースではあるが、データ・センタの移行がＣＤＮ管理コンポーネント３０４によって対処される。一方、典型的なフローでは、所与のクライアントの要求はいつも同じデータ・センタに向けられ得る。第１のデータ・センタから得られたシード値は、まだ有効であっても、第２のデータ・センタでは有効でなく、その結果、クライアントは現在のシード値の第２のデータ・センタのバージョンへの（上記の例では、第１のデータ・センタＤＣ１：ｃ：１２３５からＤＣ２：ｃ：９８７７への）リダイレクトを取得し得る。

コンテンツ・アイテムが長期間更新されない場合、その間キャッシング・システム上のコンテンツ・アイテムは不変のままであり、すなわち、キャッシング・システムは、ＣＭＳからのキャッシング・システム内のコンテンツ・アイテムの更新が不要であり得る。したがって、しばらくすると（after a while）、ほとんど全てのＡＰＩ呼び出しでＣＤＮキャッシュ・ヒットが発生するはずである（すなわち、コンテンツ・アイテムがキャッシング・システムで見つかる）。

クライアント・システムは、特定の呼び出しによってシード値を検証する頻度を制御することもできる。その結果、最新のシード値がそれぞれのＡＰＩ要求のパラメータとして使用される場合、最大待ち時間は発行された待ち時間（ｍａｘ－ａｇｅ）である。

図４は、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するための本発明のキャッシング・システム４００の一実施形態のブロック図を示している。また、コンテンツ・デリバリ・システムは、本明細書では、クライアント・システムにコンテンツを供給するようになされており、キャッシング・システムは、コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持するための手段、具体的にはそのようになされたシード管理ユニット（またはモジュール）４０２と、判定ユニット（またはモジュール）４０６によってグループのコンテンツ・アイテムの１つが更新されたと判定すると、コンテンツ・アイテムのグループのシード値を更新するための手段、具体的にはそのようになされた更新ユニット（またはモジュール）４０４と、を含む。

さらに、キャッシング・システム４００は、グループのコンテンツ・アイテムの１つを関連するシード値と共にキャッシング・システムにキャッシングするための手段、具体的にはそのようになされたキャッシング・ユニット（またはモジュール）と、キャッシング・システムによって、ＡＰＩ要求結果としてグループのコンテンツ・アイテムを要求するＡＰＩ要求を受信するための手段、具体的にはそのようになされた受信器ユニット（またはモジュール）４０８と、を含み、ＡＰＩ要求のパラメータは選択されたシード値である。

本発明の実施形態は、プラットフォームがプログラム・コードを記憶または実行あるいはその両方を行うのに適しているかに関係なく、事実上任意のタイプのコンピュータと共に実装され得る。

図５は、提案した方法に関連するプログラム・コードを実行するのに適したコンピューティング・システム５００、具体的にはキャッシング・システムを一例として示している。

コンピューティング・システム５００は、適切なコンピュータ・システムの一例に過ぎず、コンピュータ・システム５００が実装可能であるか否か、または上述の機能のいずれかを実行可能であるか否か、あるいはその両方にかかわらず、本明細書に記載の本発明の実施形態の使用または機能の範囲に関する限定を示唆することを意図したものではない。コンピュータ・システム５００には、他の多数の汎用または専用のコンピューティング・システム環境または構成で動作可能なコンポーネントが存在する。コンピュータ・システム／サーバ５００での使用に適し得るよく知られているコンピューティング・システム、環境、または構成、あるいはそれらの組合せの例には、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベースのシステム、セット・トップ・ボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムもしくはデバイスのいずれか含む分散型クラウド・コンピューティング環境などが含まれるが、これらに限定されない。コンピュータ・システム／サーバ５００は、コンピュータ・システム５００によって実行されるプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的なコンテキストで説明し得る。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造などが含まれ得る。コンピュータ・システム／サーバ５００は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施され得る。分散型クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ・デバイスを含むローカルおよびリモート両方のコンピュータ・システム記憶媒体に配置され得る。

図示のように、コンピュータ・システム／サーバ５００は、汎用コンピューティング・デバイスの形態で示している。コンピュータ・システム／サーバ５００のコンポーネントは、１つまたは複数のプロセッサまたは処理ユニット５０２、システム・メモリ５０４、およびシステム・メモリ５０４を含む様々なシステム・コンポーネントをプロセッサ５０２に結合するバス５０６を含み得るが、これらに限定されない。バス５０６は、メモリ・バスまたはメモリ・コントローラ、ペリフェラル・バス、アクセラレーテッド・グラフィックス・ポート、および種々のバス・アーキテクチャのいずれかを使用するプロセッサ・バスまたはローカル・バスを含む、いくつかのタイプのバス構造のうちのいずれかの１つまたは複数を表す。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス規格協会（ＶＥＳＡ）ローカル・バス、および周辺機器相互接続（ＰＣＩ）バスが含まれる。コンピュータ・システム／サーバ５００は、典型的には、種々のコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ５００によってアクセス可能な任意の利用可能な媒体であり得、これには揮発性および不揮発性の媒体、取り外し可能および取り外し不可能な媒体の両方が含まれる。

システム・メモリ５０４は、ランダム・アクセス・メモリ（ＲＡＭ）５０８またはキャッシュ・メモリ５１０あるいはその両方などの揮発性メモリの形態のコンピュータ・システム可読媒体を含み得る。コンピュータ・システム／サーバ５００は、他の取り外し可能／取り外し不可能な揮発性／不揮発性のコンピュータ・システム記憶媒体をさらに含み得る。単なる例として、取り外し不可能な不揮発性の磁気媒体（図示せず、典型的には「ハード・ドライブ」と呼ばれるもの）に読み書きするためのストレージ・システム５１２が設けられ得る。図示していないが、取り外し可能な不揮発性の磁気ディスク（たとえば、「フロッピー（Ｒ）・ディスク」）に読み書きするための磁気ディスク・ドライブと、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、または他の光学媒体などの取り外し可能な不揮発性の光ディスクに読み書きするための光ディスク・ドライブと、が設けられ得る。そのような例では、それぞれを、１つまたは複数のデータ・メディア・インターフェースによってバス５０６に接続することができる。以下でさらに図示および説明するように、メモリ５０４は、本発明の実施形態の機能を実行するように構成されるプログラム・モジュールのセット（たとえば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含み得る。

プログラム・モジュール５１６のセット（少なくとも１つ）を有するプログラム／ユーティリティは、限定ではなく例として、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データと同様に、メモリ５０４に記憶され得る。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データまたはそれらの任意の組合せのそれぞれは、ネットワーキング環境の実装形態を含み得る。プログラム・モジュール５１６は一般に、本明細書に記載のように、本発明の実施形態の機能または方法論あるいはその両方を実行する。

コンピュータ・システム／サーバ５００はまた、キーボード、ポインティング・デバイス、ディスプレイ５２０などの１つまたは複数の外部デバイス５１８、ユーザがコンピュータ・システム／サーバ５００とやりとりすることを可能にする１つまたは複数のデバイス、ならびに／あるいはコンピュータ・システム／サーバ５００が１つまたは複数の他のコンピューティング・デバイスと通信することを可能にする任意のデバイス（たとえば、ネットワーク・カード、モデムなど）と通信し得る。そのような通信は、入力／出力（Ｉ／Ｏ）インターフェース５１４を介して行うことができる。またさらに、コンピュータ・システム／サーバ５００は、ネットワーク・アダプタ５２２を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ）、またはパブリック・ネットワーク（たとえば、インターネット）、あるいはそれらの組合せなどの、１つまたは複数のネットワークと通信し得る。図示のように、ネットワーク・アダプタ５２２は、バス５０６を介してコンピュータ・システム／サーバ５００の他のコンポーネントと通信し得る。図示していないが、他のハードウェアまたはソフトウェアあるいはその両方のコンポーネントを、コンピュータ・システム／サーバ５００と併用できることを理解されたい。例には、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが含まれるが、これらに限定されない。

さらに、コンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのキャッシング・システム４００は、バス・システム５０６に接続され得る。

本発明の様々な実施形態の説明は、例示の目的で提示しているが、網羅的であることも、開示した実施形態に限定されることも意図したものではない。記載した実施形態の範囲および思想から逸脱することなく、多くの修正および変形が当業者には明らかであろう。本明細書で使用する用語は、実施形態の原理、実際の適用、または市場に見られる技術に対する技術的改善を最もよく説明するために、または当業者が本明細書に開示した実施形態を理解できるようにするために選択している。

本発明は、システム、方法、またはコンピュータ・プログラム製品、あるいはそれらの組合せとして具現化され得る。コンピュータ・プログラム製品は、本発明の態様をプロセッサに実行させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読記憶媒体（または複数の媒体）を含み得る。

媒体は、伝搬媒体用の電子、磁気、光学、電磁、赤外線、または半導体システムであり得る。コンピュータ可読媒体の例には、半導体または個体メモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、リジッド磁気ディスク、および光ディスクが含まれ得る。光ディスクの現在の例には、コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ－Ｒ／Ｗ）、ＤＶＤ、およびＢｌｕ－Ｒａｙ（Ｒ）ディスクが含まれる。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のために命令を保持および記憶可能な有形のデバイスとすることができる。コンピュータ可読記憶媒体は、たとえば、限定はしないが、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組合せであり得る。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストには、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリー・スティック（Ｒ）、フロッピー（Ｒ）・ディスク、命令が記録されたパンチ・カードまたは溝の隆起構造などの機械的にコード化されたデバイス、およびこれらの任意の適切な組合せが含まれる。コンピュータ可読記憶媒体は、本明細書で使用する場合、たとえば、電波または他の自由に伝搬する電磁波、導波管もしくは他の伝送媒体を伝搬する電磁波（たとえば、光ファイバ・ケーブルを通過する光パルス）、または有線で伝送される電気信号などの一過性の信号自体であると解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいは、たとえば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくは無線ネットワーク、またはそれらの組合せなどのネットワークを介して外部コンピュータまたは外部ストレージ・デバイスにダウンロードすることができる。ネットワークは、銅線伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはそれらの組合せを含み得る。各コンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または類似のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組合せで書かれたソース・コードまたはオブジェクト・コードであり得る。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン・ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上かつ部分的にリモート・コンピュータ上で、あるいは完全にリモート・コンピュータまたはサーバ上で実行され得る。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続され、または（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータへの接続がなされ得る。いくつかの実施形態では、たとえば、プログラマブル・ロジック回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用してコンピュータ可読プログラム命令を実行することによって、電子回路を個人向けにし得る。

本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して本明細書で説明している。フローチャート図またはブロック図あるいはその両方の各ブロック、およびフローチャート図またはブロック図あるいはその両方におけるブロックの組合せが、コンピュータ可読プログラム命令によって実装できることは理解されよう。

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／行為を実装するための手段を生成するように、汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供されてマシンを生成し得る。また、これらのコンピュータ可読プログラム命令は、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／行為の態様を実装する命令を含む製造品を構成するように、コンピュータ、プログラム可能データ処理装置、または他のデバイス、あるいはそれらの組合せに特定の方法で機能するように指示することが可能なコンピュータ可読記憶媒体に記憶され得る。

また、コンピュータ可読プログラム命令は、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／行為が実装するように、コンピュータ実装処理を生成するべく、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードされ、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実行させ得る。

図中のフローチャートまたはブロック図あるいはその両方は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能、および動作を示している。これに関して、フローチャートまたはブロック図の各ブロックは、指定された論理的機能を実装するための１つまたは複数の実行可能命令を含むモジュール、セグメント、または命令の一部を表し得る。いくつかの代替的実装形態では、ブロックに記載した機能は、図示した順序以外で行われ得る。たとえば、関与する機能に応じて、連続して示した２つのブロックは、実際には実質的に同時に実行され、またはそれらのブロックは、場合により逆の順序で実行され得る。ブロック図またはフローチャート図あるいはその両方の各ブロック、およびブロック図またはフローチャート図あるいはその両方におけるブロックの組合せは、指定される機能もしくは行為を実行するか、または専用ハードウェアおよびコンピュータ命令の組合せを実行する専用のハードウェア・ベースのシステムによって実装できることにも気付くであろう。

本明細書で使用する用語は、特定の実施形態を説明するためのものに過ぎず、本発明を限定することを意図するものではない。本明細書で使用する場合、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈がそうでないことを明確に示さない限り、複数形も含むものとする。本明細書で使用される場合、「備える（comprises）」という用語、もしくは「備える（comprising）」という用語、またはその両方は、記述した特徴、整数、ステップ、動作、要素、もしくは構成要素、またはそれらの組合せの存在を示すものであるが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、もしくはそれらのグループ、またはそれらの組合せの存在または追加を排除するものではないということはさらに理解されよう。

以下の特許請求の範囲における全てのミーンズまたはステップ・プラス・ファンクション要素の対応する構造、材料、行為、および均等物は、明確に特許請求された他の特許請求要素と組み合わせて機能を実行するための任意の構造、材料、または行為を含むものとする。本発明の説明は、例示および説明の目的で提示しているが、網羅的であることも、開示した形態の発明に限定されることも意図したものではない。本発明の範囲および思想から逸脱することなく、多くの修正および変形が当業者には明らかであろう。本発明の原理および実際の適用を最もよく説明し、企図した特定の用途に適した様々な修正を有する様々な実施形態について本発明を当業者が理解できるようにするために、実施形態を選択し、説明している。

Claims (20)

1. クライアント・システムにコンテンツを供給するようになされたコンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのコンピュータ実装方法であって、
   コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持することと、
   前記グループの前記コンテンツ・アイテムの１つが更新されたと判定すると、
   前記コンテンツ・アイテムのグループの前記シード値を更新することと、
   前記グループの前記コンテンツ・アイテムの１つを前記関連するシード値と共にキャッシング・システムにキャッシングすることと、
   前記キャッシング・システムによって、ＡＰＩ要求結果として前記グループのコンテンツ・アイテムを要求するＡＰＩ要求を受信することであって、前記ＡＰＩ要求のパラメータは選択されたシード値である、前記受信することと、
   を含む、コンピュータ実装方法。
2. 前記キャッシング・システムにおいて、前記関連するシード値と前記選択されたシード値との相違を特定すると、
   ＡＰＩ要求結果として更新されたそれぞれのコンテンツ・アイテムを要求すること
   をさらに含む、請求項１に記載の方法。
3. 前記キャッシング・システムにおいて、前記グループの前記コンテンツ・アイテムに関するＡＰＩ要求を定期的に受信すること
   をさらに含む、請求項１または２に記載の方法。
4. 前記ＡＰＩ要求は、ＡＰＩ要求結果として異なるコンテンツ・アイテム・タイプのグループに属するアイテムのコンテンツを要求する、請求項１ないし３のいずれかに記載の方法。
5. 前記ＡＰＩ要求の前記パラメータは、前記異なるタイプの前記シード値を入力とするＸＯＲ関数の結果である、請求項４に記載の方法。
6. 前記キャッシング・システムにおいて、ＡＰＩ要求結果のコンテンツ・アイテムのキャッシュ有効期間として、事前定義されたキャッシュ有効期間閾値以上の時間値を使用すること
   をさらに含む、請求項１ないし５のいずれかに記載の方法。
7. コンテンツ・アイテムのキャッシュ有効期間として、事前定義されたキャッシュ有効期間閾値以上の時間値を送信すること
   をさらに含む、請求項１ないし６のいずれかに記載の方法。
8. 前記クライアントに通知をプッシュすることであって、前記通知はグループの前記コンテンツ・アイテムの１つに関連するシード値の更新を示す、前記プッシュすること
   をさらに含む、請求項１ないし７のいずれかに記載の方法。
9. 前記コンテンツ・アイテムは、シングル・ページ・アプリケーション（ＳＰＡ）の要素または別の方法で動的に生成されるコンテンツである、請求項１ないし８のいずれかに記載の方法。
10. 前記ＡＰＩ要求結果は検索クエリの結果である、請求項１ないし９のいずれかに記載の方法。
11. 前記グループの前記コンテンツ・アイテムの１つを前記関連するシード値と共にキャッシング・システムに前記キャッシングすることの前に、
    前記キャッシング・システムにおいて前記ＡＰＩ要求を受信することと、
    前記ＡＰＩ要求結果を要求することと、
    をさらに含む、請求項１ないし１０のいずれかに記載の方法。
12. コンテンツ・タイプの前記シード値のいずれもが要求可能である、請求項１ないし１１のいずれかに記載の方法。
13. クライアント・システムにコンテンツを供給するようになされたコンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのキャッシング・システムであって、
    コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持するための手段と、
    前記グループの前記コンテンツ・アイテムの１つが更新されたと判定すると、前記コンテンツ・アイテムのグループの前記シード値を更新するための手段と、
    前記グループの前記コンテンツ・アイテムの１つを前記関連するシード値と共にキャッシング・システムにキャッシングするための手段と、
    前記キャッシング・システムによって、ＡＰＩ要求結果として前記グループのコンテンツ・アイテムを要求するＡＰＩ要求を受信するための手段であって、前記ＡＰＩ要求のパラメータは選択されたシード値である、前記受信するための手段と、
    を備える、キャッシング・システム。
14. 前記キャッシング・システムは、
    前記キャッシング・システムにおいて、前記関連するシード値と前記選択されたシード値との相違を特定すると、ＡＰＩ要求結果として更新されたそれぞれのコンテンツ・アイテムを要求するための手段
    を備える、請求項１３に記載のキャッシング・システム。
15. 前記ＡＰＩ要求は、ＡＰＩ要求結果として異なるコンテンツ・アイテム・タイプのグループに属するアイテムのコンテンツを要求する、請求項１３または１４に記載のキャッシング・システム。
16. 前記ＡＰＩ要求の前記パラメータは、前記異なるタイプの前記シード値を入力とするＸＯＲ関数の結果である、請求項１５に記載のキャッシング・システム。
17. 前記キャッシング・システムにおいて、ＡＰＩ要求結果のコンテンツ・アイテムのキャッシュ有効期間として、事前定義されたキャッシュ有効期間閾値以上の時間値を使用するための手段
    をさらに備える、請求項１３ないし１６のいずれか一項に記載のキャッシング・システム。
18. コンテンツ・アイテムのキャッシュ有効期間として、事前定義されたキャッシュ有効期間閾値以上の時間値を送信するための手段
    をさらに備える、請求項１３ないし１７のいずれか一項に記載のキャッシング・システム。
19. 前記キャッシング・システムは、コンテンツ管理システム、キャッシュ・サーバ、およびクライアントを含む３層コンテンツ・デリバリ・システムの中間レイヤを表す、請求項１３ないし１８のいずれか一項に記載のキャッシング・システム。
20. クライアント・システムにコンテンツを供給するようになされたコンテンツ・デリバリ・システムのＡＰＩ要求結果のキャッシャビリティを改善するためのコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は、プログラム命令を具現化したコンピュータ可読記憶媒体を備え、前記プログラム命令は、１つまたは複数のコンピューティング・システムまたはコントローラによって実行可能であり、前記１つまたは複数のコンピューティング・システムに、
    コンテンツ・タイプのコンテンツ・アイテムのグループごとに一意のシード値を保持することと、
    前記グループの前記コンテンツ・アイテムの１つが更新されたと判定すると、
    前記コンテンツ・アイテムのグループの前記シード値を更新することと、
    前記グループの前記コンテンツ・アイテムの１つを前記関連するシード値と共にキャッシング・システムにキャッシングすることと、
    前記キャッシング・システムによって、ＡＰＩ要求結果として前記グループのコンテンツ・アイテムを要求するＡＰＩ要求を受信することであって、前記ＡＰＩ要求のパラメータは選択されたシード値である、前記受信することと、
    を行わせる、コンピュータ・プログラム製品。

Images