JP6081472B2 - 専用のキャッシュを管理するためのシステム及び方法 - Google Patents

Description

本発明の実施の態様は、ウェブキャッシングなどのキャッシュ管理に関する。

昨今のウェブアプリケーションなどのクライアントサーバシステムは、エンドユーザコンピュータ又はネットワーク上のある場所などの様々な地点において、パフォーマンスを最適化するためにキャッシュを活用することができる。これらのウェブキャッシュソリューションは、一般に、後続のアクセスにおけるより高速なコンテンツの取得のためにコンテンツを格納するためのディスク及び／又はメモリ内の同一の空間を、複数のユーザ及び／又はサイトからのコンテンツが共有する共有キャッシュを備える。共有キャッシュでは、異なるサイト経由で、及び／又は、異なるユーザによりアクセスされるコンテンツの間で、同一の限られたキャッシュ空間が競合されることになる。

また、これらのウェブキャッシュソリューションは、アプリケーションに基づいてキャッシュの動作を一元的にカスタマイズする方法を備えない。例えば、大きな会社は、異なる部門又はビジネスユニットごとに独立したサーバなど、特定のウェブアプリケーションを実行する複数のサーバを有することがあるが、これらのアプローチは特定のドメイン及び／又はＵＲＬを対象にしているので、アプリケーションの種類に基づいてキャッシュポリシーを適用することはできない。

本発明の実施の態様は、一元的に管理されたキャッシュ制御を提供することにより、これらの及び他の問題を解決する。より詳細には、本発明の実施の態様は、ユーザごとに（又はユーザのアカウントごとに）何がキャッシュされ又は消去されるのかの細粒度制御（例えば、ＵＲＬパターンを介して）を提供する。更なる態様は、ＳＳＬ（secure sockets layer）、ＤＮＳ（domain name system）、又はネットワークの変更なしに、シームレスに可能にし、又は不可能にすることができる。更なる態様は、ドメイン又はＵＲＬパターンごとの空間の割り当てを提供する。更なる態様は、リード又はライト命令のキャッシュを調整し、ＵＲＬテンプレートを介して自動的に設定して（例えば、自動起動（auto-mobolizing））、アプリケーションに特化した制御を提供する。

さらに、本発明の実施の態様は、エンドポイント特有のウェブ性能の一元的制御を提供する。より詳細には、態様は、同期（sync）アクティビティの調整、フォームベースの認証のサポートの追加、オフラインアクセスの有効化又は無効化し、一意の識別子（ＵＩ）要素の設定、及び現実のエンドユーザの体験の測定又は報告を提供する。

したがって、本発明の実施の形態は、それぞれが、特定のＵＲＬパターン（例えば、特定のサーバ／サイト、サブパス／フォルダ、又はファイル／オブジェクト）に関連付けられたコンテンツのキャッシュに割り当て可能な専用キャッシュの管理を提供する。これらの専用キャッシュは、キャッシュがエンドユーザのコンピュータ、又は、１以上のサーバシステムと通信するクライアントシステムの間の中間キャッシュサーバに存在する場合など、管理システムから遠隔にあってもよい（この意味で、すなわち管理システムに関して、リモート専用キャッシュとも呼ばれる）。

関連特許出願である米国特許出願第１２／６３０，８０６号（以下、「Ｕ．Ｓ．１２／６３０，８０６」という）は、ＵＲＬの範囲内にあるクライアントリクエストに対するサーバの応答をキャッシュする目的で、１以上のＵＲＬをサーバアカウント又はアプリケーションに関連付ける方法を記載する。Ｕ．Ｓ．１２／６３０，８０６は、例えば、サーバアカウントのキャッシュのためのストレージの限度のカスタマイズを指定したり、サーバアカウントのキャッシュに何が格納されるかをカスタマイズしたりするなど、管理性を重大に向上させるサーバアカウントをキャッシュする様々な態様を記載する。それぞれのサーバアカウントについてストレージの限度をカスタマイズすることをサポートすることにより、Ｕ．Ｓ．１２／６３０，８０６は、サーバアカウントのプライベートなキャッシュ空間を専用にするなどの特徴を提供する。これにより、このキャッシュ空間はサーバアカウントに関連付けられたＵＲＬパターンのキャッシュに専用される。パターンはサイト、サブパス／フォルダ、特定のファイル／オブジェクトであってもよい。

サーバアカウントごとの専用キャッシュによる利点は、専用キャッシュは他のサイト／フォルダ／ファイルのためのコンテンツとキャッシュ空間を共有しないことである。これにより、ブラウザ又はプロクシサーバなどにより提供される共有キャッシュなど、共通のキャッシュ空間を共有することに起因する典型的なキャッシュの競合の影響を受けない。これらの共有キャッシュにおけるキャッシュの競合は、通常、専用キャッシュよりも高い。したがって、１以上のＵＲＬパターンに関連付けられた１以上の専用キャッシュを生成することにより、これらの専用キャッシュは、共有キャッシュよりも長いキャッシュ有効期間と高いヒット率を保証することができる。これにより、より高速なウェブ性能を提供し、使用される帯域幅をより狭くし、実行されるリクエスト／ラウンドトリップをより少なくし、サーバ側のインフラに対する全体の負荷をより低くすることができる。

本発明は、これらのキャッシュの細粒度管理及び制御を提供することにより、ＵＳ．１２／６３０，８０６の専用キャッシュを改良する。何をキャッシュするか、どのようにキャッシュするかの細粒度制御の提供により、性能を向上させ、インフラの負荷を低減させることができる。例えば、複数の関連するリクエスト／ＵＲＬを同一のキャッシュコンテンツにマッチさせたり、サーバにより指定された寿命を超えてキャッシュ可能なコンテンツの寿命を拡張したりしてもよい。

これらの専用キャッシュの一元的管理は、多数の専用キャッシュをリモートで制御するために管理者により実行可能な様々なアクションを提供することができる。例えば、これらのアクションは、これらの専用キャッシュを動的に生成／削除したり、それらがそれぞれ割り当てられた空間を調整したり、それぞれに適用されるキャッシュポリシーを設定／変更したりすることを含んでもよい。

本発明の実施の形態において、ネットワークを介してリモートのサーバと通信し、サーバにより提供されるコンテンツ又はサービスに対するアクセスを提供するように構成された、クライアントベースのコンピュータシステムが提供される。システムは、プロセッサと、ストレージデバイスと、設定により指定されたリソースの集合のための専用のクライアント側のキャッシュと、設定により指示されたようにキャッシュを自動的に管理するキャッシュ管理部とを備える。クライアント側のキャッシュは、クライアントアプリケーションから前記サーバに対する前記リソースの１つのリクエストを透過的にインターセプトし、前記リクエストをいつ送信するかを自動的に判定し、前記クライアントアプリケーションが前記リクエストを前記サーバに送信して前記サーバから前記応答を受信したように前記クライアントアプリケーションからみえるように前記ネットワークを介した前記サーバからの応答を提供するための前記設定により指示される。クライアント側のキャッシュは、前記クライアントアプリケーションが前記リクエストを送信したように前記サーバからみえるように前記サーバに前記リクエストを送信し、前記サーバからの応答を提供し、前記ストレージデバイスに前記応答を格納するか、又は、前記キャッシュから前記応答を提供することにより、これを実行する。

本発明の別の態様において、ネットワークを介してリモートのサーバと通信し、サーバにより提供されるコンテンツ又はサービスを提供するための方法が提供される。方法は、それぞれが１以上のＵＲＬに関連付けられた１以上の専用キャッシュを生成するステップと、それぞれのキャッシュについて、１以上のルールにしたがってキャッシュを管理するステップと、クライアントアプリケーションからサーバに対するＵＲＬのうちの１つのリクエストを透過的にインターセプトするステップと、リクエストをいつ送信するか、及び、クライアントアプリケーションがリクエストをサーバに送信してサーバから応答を受信したようにクライアントアプリケーションからみえるようにネットワークを介したサーバからの応答をいつ提供するかを自動的に判定するステップと、を備える。応答を提供するステップは、クライアントアプリケーションがリクエストを送信したようにサーバからみえるようにサーバにリクエストを送信し、サーバからの応答を提供し、ストレージデバイスに応答を格納するステップ、又は、キャッシュの１つから応答を提供するステップを含む。

添付の図面は本発明の実施の形態を示し、詳細な説明とともに、本発明の原理及び態様を説明する役目を果たす。

図１は、本発明の実施の形態に係る、リモートサーバ上のアプリケーション／データにアクセスするクライアントコンピュータに保持された、一元的に管理された専用キャッシュのシステムアーキテクチャを示す図である。

図２は、本発明の実施の形態に係るクライアントプロセスのセットの例を示す図である。

図３は、実施の形態に係るクライアントコンピュータを管理サーバに登録するための登録処理の例を示す統一モデリング言語（ＵＭＬ）シーケンス図である。

図４は、実施の形態に係る管理タスクループの例を示すＵＭＬシーケンス図である。

図５は、実施の形態に係る管理サーバからタスクが取得されたときの管理部によるタスクの処理の例を示すＵＭＬシーケンス図である。

図６は、実施の形態に係る、アプリケーション設定データを処理するためのアプリケーション設定更新のＵＭＬフレームの例を示すＵＭＬシーケンス図である。

図７は、実施の形態に係る、サイト設定データを処理するためのサイト設定更新のＵＭＬフレームの例を示すＵＭＬシーケンス図である。

図８は、実施の形態に係る、設定テンプレートを処理するための設定テンプレート適用のＵＭＬフレームの例を示すＵＭＬシーケンス図である。

図９は、実施の形態に係る、キャッシュ消去タスクを処理するためのキャッシュ消去のＵＭＬフレームの例を示すＵＭＬシーケンス図である。

図１０は、実施の形態に係る、特定のアイテムをキャッシュから削除するためのキャッシュアイテムフラッシュのＵＭＬフレームの例を示すＵＭＬシーケンス図である。

図１１は、本発明の実施の形態に係る専用キャッシュ管理方法の例を示す図である。

以下に示す実施の形態は、本発明の単なる適用例であり、本発明の範囲を限定するためのものではない。本出願の実施例のより実装に特化した詳細を含む優先権書類において追加が提供される。

１ 専用キャッシュの管理
本発明の実施の形態は専用のキャッシュを提供する。それぞれのキャッシュは、１以上の統一資源位置指定子（ＵＲＬ：uniform resource locator）のパターンごとにコンテンツを格納するために専用される。これらの専用キャッシュは、サーバのアカウントにそれぞれ関連付けられる。サーバのアカウントは、関連特許出願である米国特許出願第１２／６３０，８０６に記載されたように、サーバの応答をキャッシュするために１以上のＵＲＬに関連付けられる。本発明の実施例は、例えばどのコンテンツをキャッシュするか、どのようにキャッシュするかを特定するなど、それぞれの専用キャッシュのカスタマイズを可能とすることにより、従来技術に対する重要な改良を提供する。

本発明の実施の形態は、エンドユーザ、システム管理者、又はウェブサイト開発者などにより動的にカスタマイズ可能な設定を介した粒度の細かいキャッシュ制御を提供する。これらの設定は、ファイル又はデータベースなど、当業者に知られた多数の異なる方法により格納されてもよい。本発明の実施の形態は、任意の標準的なテキストエディタにより直接編集可能で、シンプルで拡張可能な構造を可能とするＹＡＭＬ（http://www.yaml.org/）の仕様にしたがったテキストファイルにおいてこれらの設定をサポートする。

１．１ アプリケーションベースの設定
それぞれのウェブサイト／アプリケーションは、どのようにキャッシュされるかに影響する様々な異なる動作をとりうるので、本発明の実施例は、それぞれのウェブサイト／アプリケーションの異なる性能をサポートするために、それぞれのキャッシュをカスタマイズすることができるように、それぞれのキャッシュに異なるキャッシュルール／ポリシー／動作を割り当てることができる。本発明の実施例は、それぞれのウェブアプリケーションについてカスタマイズされた設定を定義するための柔軟な方法をサポートすることにより、現在及び将来の任意のアプリケーションをサポートするように適合されることができる。

本発明の実施の形態は、ＵＲＬテンプレートに基づいてキャッシュを自動的に生成してもよい。例えば、「serverl .acme.com」又は「server99.acme.com」など、可能性がある全てのサーバ名を予め知ることなく、「acme.com」などのインターネットドメインの範囲内の任意のサーバについて自動的にキャッシュを生成することが望ましい。ＵＲＬテンプレートにより、システムは、リモートサーバからアクセスされたコンテンツのＵＲＬとマッチするために用いられる文字ベースのパターンに基づいて、自動的にキャッシュを生成することができる。例えば、「http://*.acme.com」として特定されるＵＲＬテンプレートにより、クライアントシステムは、「acme.com」ドメイン内の任意のサーバからのコンテンツについて、それぞれを明示的に特定する必要なく、別個のキャッシュを自動的に生成することができる。

本発明の実施例は、例えば、それぞれの設定をＵＲＬパターンに割り当て、マッチしたＵＲＬを有する任意のサーバアカウントのキャッシュに設定を適用するなど、多数の異なる方法により、１以上の設定をキャッシュに適用してもよい。設定は、サーバから返送されるＨＴＴＰ応答の「Server」ヘッダ又はカスタムヘッダなど、サーバから取得可能な別の識別情報に割り当てられてもよい。

本発明の実施の形態は、それぞれの設定に割り当て可能な下記の属性をサポートすることにより、キャッシュに設定をマッチさせる。

下記は、ＵＲＬに基づいて設定を関連付けるための属性の例である。
id:
mode: domain
url: 'http[s]://maps\.***\.com/.!i!'

同様に、下記は、ＨＴＴＰのカスタム応答ヘッダに基づいて設定を関連付けるための属性の例である。
id:
mode: header
name: MicrosoftSharePointTeamServices
value: '12\.0\.0\.[0-9]+'

１．２ マッチング要求及び応答
一つの実施例において、アプリケーション設定は、２つの可能な属性のセットを含む。
・マッチング属性：アプリケーション設定が適用される要求／応答を特定する。
・アクション属性：アプリケーション設定のアクション／動作を特定する。

マッチング属性は、リクエストのＵＲＬやレスポンスの本体など、クライアント／サーバの要求又は応答の１以上の要素に対してマッチングを行うことができる。本発明の実施例は、下記のマッチング属性を提供する。

マッチング属性に基づいて要求又は応答にマッチする設定が発見されると、その要求／応答に対応するアクション属性を適用させることができる。

１．３ アクション設定
実施例において、アプリケーション設定に関連付け可能な多数の異なるアクション属性があり、１以上のアクションの任意の組み合わせが、キャッシュのデフォルト動作を変更するために指定されうる。これにより、例えば、異なる種別のウェブサイト／アプリケーションをサポートするために、又は、デフォルトを超えてウェブアプリケーションのキャッシュ能力を上乗せ／最適化するために、それぞれのサーバアカウントについて専用キャッシュの動作及び作用をカスタマイズすることができる。

１．３．１ 要求の再マッピング
それぞれ異なるＵＲＬに関する異なる複数の要求が、実際には同一の応答データに対応するケースがありうる。例えば、前ページのＵＲＬやセッションＩＤなど、一過性のデータを伝送するためにＵＲＬを利用することがウェブ開発者に知られている。このように、これらの一見異なる要求が実際にはサーバからの同一の応答をもたらすようなケースでは、それらを同一の要求であるとして扱うことが望ましい。これにより、これらの全ては、同一の応答のキャッシュされたバージョンから提供されることができる。

同じ要求の異なるバリエーションを同じ応答に再マッピングするために、本発明の実施例は、同一の基調をなす要求の類似するインスタンスの間で異なる部分をフィルタリングにより除去する。例えば、ＵＲＬクエリ文字列引数として指定された一過性のデータを除去する。これにより、これらの異なる要求のバリエーションは、最終的に同一にみえる。下記の表は、ＨＴＴＰリクエストの部分をフィルタリングにより除去するための設定のアクション属性の例のリストである。

下記は、これらのアクション属性を用いて、前のページを指定するリクエストＵＲＬからクエリ文字列引数を除去するための設定の例である。
cache:
gets:
- subPath: '.*\?retURL=.+'
filterUrlPatterns:
- '[\?&]retURL=[^&]+'

同様に、下記は、リクエストの一時的な要素を除去することにより、同一のウェブページ（シェアポイント（登録商標）のサイト）のリクエストのバリエーションを同一のキャッシュに再マッピングするための設定の別の、より複雑な例である。
cache:
posts:
- subPath: '.*/AllItems\.aspx.*'
notBodyPattems:
- '.*&ctl.*%24btnWikiSave=Apply&.*'
filterUrlPatterns:
- '(?i)[\?&]source=[^&]*'
- '(?i)[\?&]contenttypeid=[^&]*'
- '(?i)[\?&]initialtabid=[^&]*'
- '(?i)[\?&]visibilitycontext=[^&]*'
- '(?i)[\?&]isdlg=[^&]*'
- '(?i)[\?&]viewcount=[^&]*'

１．３．２ キャッシュの寿命の制御
サーバがキャッシュを実行可能とするために適切に設定されていない場合、ユーザがサーバにより指定されたキャッシュの寿命を変更したい場合など、キャッシュされた応答の寿命を制御又は変更するのが望ましいケースがある。例えば、サーバには、たいていキャッシュ可能な静的なコンテンツ（例えば、画像、Java（登録商標）Script、カスケーディング・スタイル・シート、ＰＤＦなど）があるが、クライアントにおいて最適にキャッシュされるよう適切に設定されていないものもある。

本発明の実施の形態に係る専用キャッシュ管理システムに格納されたアイテムの寿命を制御するために、システムは、サーバの応答に有効期間を適用する。サーバにより提供された有効期間がもしあれば、その有効期間よりもシステムの有効期間が優先される。下記の表は、サーバの応答がどのようにキャッシュされるかを制御する設定のアクション属性の例のリストである。

下記は、これらのアクション属性を用いて、「layouts」フォルダからの要求のキャッシュ有効期間として１年（３１，５３６，０００秒）を指定する設定の例である。
cache:
gets:
- subPath: '.*/_layouts/.*'
maxAge: 31536000

２ 一元化された管理
本発明の実施例は、キャッシュの操作及び動作を一元的に設定するための管理者のための管理コンソールを表示する管理サーバを提供することにより、リモート専用キャッシュの一元管理を提供する。実施例において、管理コンソールは、キャッシュされたアプリケーション／サイトの標準的なクライアント−サーバ相互作用からアウトオブバンドで操作する。

図１は、リモートサーバ（例えば、サーバ１０８）上のアプリケーション／データにアクセスするクライアントコンピュータ（例えば、クライアント１００）に保持された、一元的に管理された専用キャッシュ（例えば、キャッシュ１０３）の実施例を示す図である。

図１を参照して、クライアント１００は、ネットワーク１０７（例えば、インターネット）を介したサーバ１０８との間の通信をサポートするコンピュータである。クライアント１００は、クライアントアプリケーション（クライアントＡｐｐ）１０１の実行をサポートする。クライアントアプリケーションは、例えば、ウェブブラウザなどの、リモートサーバと通信可能なインターネットベースの任意のクライアントアプリケーションであってもよい。クライアント１００は、コンピュータ命令の形式でソフトウェアを実行するための中央処理ユニット（ＣＰＵ）又はプロセッサ、ソフトウェア及びＣＰＵによりアクセス又は生成される関連するデータを格納するための不揮発性ストレージ（例えば、ディスクドライブ）、及びネットワーク１０７にアクセスするためのネットワークインタフェース（例えば、インターネットサービス１０４）を含んでもよい。

更に詳細には、アプリケーションプログラミングインタフェース（ＡＰＩ）インターセプト１０２は、クライアントＡｐｐ１０１とインターネットサービス１０４との間に挿入され、クライアントＡｐｐ１０１からサーバ１０８（インターネットサービス１０４を介して）、キャッシュ１０３へ、又は任意の２つの組み合わせでリクエストを導く。キャッシュ１０３に送られたリクエストは、ストレージ１０６（例えば、ディスクドライブなどの不揮発性ストレージデバイス）上にローカルに保持された応答を用いて処理されてもよい。ストレージ１０６に対するアクセスは、ファイルシステム、データベース、又はそれらの組み合わせなどの一般的なストレージアクセスレイヤであるストレージサービス１０５を介して処理されてもよい。

さらに、管理部１５０は、キャッシュ１０３の機能及び動作を管理し、設定の変更及びアクションを動的に取得及び処理するための管理サーバ１７０（例えば、キャッシュ１０３などのローカルな専用キャッシュを管理するためのリモートサーバ）と相互作用する。ここで、「ローカルな専用キャッシュ」は、クライアントコンピュータシステムの一部分であるストレージデバイス上に格納されている専用キャッシュを指す。

図２は、実施例のシステムにおけるクライアントの処理の実施の形態を示すソフトウェアアーキテクチャ図である。本図は、本実施の形態に最も関連するソフトウェアコンポーネントを示しており、図示されない他のソフトウェアコンポーネントもあることは当業者に理解されるところである。４つの論理的に区別される処理１１０、１３０、１４０、及び１５０がある。処理１１０及び１３０について、図１からソフトウェアレイヤ（例えば、クライアントＡｐｐ１０１、ＡＰＩインターセプト１０２、キャッシュ１０３、及びインターネットサービス１０４）が図示され、それらが本図において特定のインスタンスにどのようにマップされるかが示される。

処理１１０は、インターネットサービス１０４の一種であるマイクロソフトのWinlnetダイナミックリンクライブラリ（ＤＬＬ）に標準的にリンクするクライアントＡｐｐ１０１の一種であるマイクロソフトワード（登録商標）、インターネットエクスプローラ（登録商標）などのWinlnetクライアント１１１を実行する。Winlnetインターセプト１６０は、Winlnetクライアント１１１によるリクエストをインターセプトするＡＰＩインターセプト１０２の一例であり、Winlnet１６１に対して送られたリクエストをキャッシュ１０３にリダイレクトする。Winlnetクライアント１１１は、マイクロソフトワードのためのＣＯＭオフィスアドイン又はマイクロソフトインターネットエクスプローラのためのブラウザヘルパーオブジェクト（ＢＨＯ）として実装可能なアプリケーションプラグイン１１３をロードする。アプリケーションプラグインは、キャッシュコンテンツ又はステータスを取得又は設定するなど、クライアントユーザインタフェースからキャッシュ１０３に対するアクセスを提供可能である。アプリケーションプラグインは、更に、Winlnetクライアント１１１とWinlnet１６１との間のファンクションコールのインターセプトを可能とするための挿入としても機能する。これにより、キャッシュ１０３は、Winlnetクライアント１１１から発行されたインターネットリクエストを取得して処理することができる。

実施例は、インターネットサービスのためにMozilla Netlibを用いるMozilla Firefox（登録商標）など、インターネットサービス１０４にアクセスする任意のクライアントＡｐｐ１０１に適用される。インターネットサービス１０４のＡＰＩを介してインターネットにアクセスする任意のアプリケーションは、ＡＰＩインターセプト１０２によりインターセプトされ、そのインターネットリクエストはキャッシュ１０３にリダイレクトされる。異なるインターネットサービス１０４にアクセスするクライアントＡｐｐ１０１は、インターセプトを可能とするために、異なるＡＰＩインターセプト１０２を用いてもよい。

キャッシュ１０３は、例えば、処理１１０及び１３０など、複数のアプリケーションにわたって共通であってもよい。キャッシュ１０３は、キャッシュエンジン１６２を含んでもよく、キャッシュエンジン１６２は、アプリケーションの汎用の機能を提供する１以上のソフトウェアコンポーネントを含んでもよい。キャッシュ１０３は、アプリケーションの特有の機能をキャッシュエンジン１６２に論理的に拡張するゼロ以上のＡｐｐ拡張部１６３を含んでもよい。ある実施の形態において、キャッシュエンジン１６２は、異なるコンピュータプラットフォームにわたる移植性を向上させるJava（登録商標）仮想マシン（ＪＶＭ）１６４の内部で実行されるJava（登録商標）ソフトウェアであってもよい。キャッシュエンジン１６２がインターネットリクエストを取得すると、キャッシュエンジン１６２は、データベース１４１などを介して、ストレージからの応答データを問い合わせてもよい。データベース１４１は、別の処理１４０を介してアクセスされてもよい。キャッシュエンジン１６２は、リクエストをアシストするためにＡｐｐ拡張部１６３をコールしてもよい。有効な応答が発見されると、キャッシュエンジン１６２は、例えば処理１１０におけるWinlnetクライアント１１１などの上位層のクライアントＡｐｐ１０１に応答を返す。そうでなければ、キャッシュエンジン１６２は、リクエストをサーバに向けて発行させてもよい。これは、例えばクローラ処理１３０を介して、別のコンテクストにより実行されてもよい。

図２の実施例において、キャッシュ１０３はクライアントコンピュータ上で動作するが、キャッシュ１０３は、例えばサーバよりも入手可能性が高く、又は、クライアントコンピュータへの帯域が広い１以上の異なるコンピュータシステム上で実行されてもよい。例えば、キャッシュ１０３は、同一又は近接するローカルエリアネットワーク（例えば、イーサネット（登録商標）、WiFi（登録商標）、ブルートゥース（登録商標）など）上の別のプラットフォーム（例えば、サーバ、電話など）で実行されてもよい。これにより、ウェブアプリケーションに対して、向上したキャッシュ１０３の利用可能性及び／又は動作特性を提供することができる。

ある実施の形態に係る本発明の態様は、サードパーティーのソフトウェアによるアプリケーション特有のカスタマイズをサポートする。外部のソフトウェアがリクエストの処理をアシストすることが可能な直接的及び間接的な方法が多数存在する。例えば、アプリケーション特有のソフトウェアに対する直接的なコールは、キャッシュエンジン１６２にリンクされた外部機能を介してサポートされてもよい。別の例では、アプリケーション特有のソフトウェアに対する間接的なコールは、キャッシュエンジン１６２により開かれたメッセージキュー又はパイプなどのプロセス間通信を介してサポートされてもよい。外部のソフトウェアに対するコールは、リクエストパラメータに基づいて制限されるなど、条件付きであってもよい。例えば、外部のソフトウェアに対するコールは、特定のコールが実行される前にリクエストヘッダに対してマッチングをするためのパターンを指定する設定パラメータなど、キャッシュエンジン１６２の設定パラメータにより設定されてもよい。

処理１３０は、多くはバックグラウンドにおいて（すなわち、ユーザには不可視で）、サーバとの通信をサポートするクローラ１３１を実行する。クローラは、ＪＶＭ１３２の内部で実行されるJava（登録商標）ソフトウェアコンポーネントであってもよく、ＪＶＭ１３２はＪＶＭ１６４と同じインスタンスであってもよい。クローラ１３１は、Winlnetブラウザ１３４などのインターネットベースのクライアントＡｐｐ１０１をプログラムで制御することにより、サーバリソースを要求する。Winlnetブラウザ１３４は、Winlnetクライアント１１１と同一又は類似するものであってもよい。Winlnetブラウザ１３４は、Web Application Testing in Java（登録商標）（Ｗａｔｉｊ）又はTeamDev JExplorerなどのブラウザ制御レイヤ１３３を介して、プログラムで制御されてもよい。処理１１０と同様に、処理１３０は、Winlnetブラウザ１３４からのインターネットリクエストのインターセプトを可能とするために、Winlnetインターセプト１６０を挿入する（例えば、クローラ１３１がJava（登録商標） native interface（ＪＮＩ）を介してLoadLibraryをコールする）。

処理１３０は、例えば、キャッシュされたバージョンが失われたり、リフレッシュされる必要がある場合などに、キャッシュ１０３に対するインターネットリクエストがサーバに送信される点で処理１１０と異なってもよい。これらのリクエストは、サーバにより処理可能とするために、Winlnet１６１を介してWinlnetインターセプト１６０により送出される。キャッシュ１０３は、（処理１１０とは）異なる動作モードを提供することにより、この動作をサポートしてもよい。この動作モードは、初期化期間中になされたコールを介してなど、クローラ１３１により明示的にリクエストされてもよい。サーバから取得された任意の新しい応答データは、データベース１４１に格納されてもよい。これにより、応答データは持続され、処理１１０などによりアクセス可能とすることができる。

ある実施の形態は、ファイルシステム、データベース、又はそれらの組み合わせを含むデータベース１４１を介してストレージにアクセスしてもよい。データベース１４１は、キャッシュ１０３と同じ処理の中でアクセスされてもよいし、処理１４０などの別個のコンテクスト又は処理により提供されてもよい。ある実施の形態において、処理１４０はデータベース１４１を実行し、ローカルにキャッシュされたサーバのコンテンツに対するアクセスを管理する。データベース１４１は、ＪＶＭ１４２の内部で実行されるJava（登録商標）ソフトウェアコンポーネントであってもよい。他の処理が、Java（登録商標） remote method invocation（ＲＭＩ）又はJava（登録商標） database connectivity（ＪＤＢＣ）などの一般的なプロセス間通信（ＩＰＣ）機構を用いて処理１４０と通信することにより、データベースからデータを取得又は格納してもよい。データベース１４１は、例えば、データベース１４１が共有データのプロセス間シリアライゼーションをサポートする場合などに、処理１１０又は１３０などのクライアントプロセスの中で実行されてもよい。

処理１５０は、クローラを起動したり、サーバの接続性の変化を監視したりするなど、多岐にわたるタスクの制御及び管理を処理する管理部１５１を実行する。管理部１５１は、ＪＶＭ１５２の内部で実行されるJava（登録商標）ソフトウェアコンポーネントであってもよい。他のプロセスは、Java（登録商標） RMIなどの一般的なＩＰＣ機構を用いることにより、管理部１５１により提供されるサービスにアクセスしてもよい。

３ クライアント／サーバ相互作用
３．１ クライアント登録
図１の実施例などの本発明の実施例において、それぞれのリモートキャッシュ（すなわち、中央の管理部に対して）は、管理サーバ１７０に保持された特定の設定に論理的に関連付けられる。これにより、リモートキャッシュはインストール時に事前設定され、又は、後に再設定されることができる。実施例において、リモートキャッシュ（例えばキャッシュ１０３）は、クライアント１００などのクライアントコンピュータ上に保持され、クライアント１００は、最初に設定データを取得し、その後定期的に設定変更をチェックするために、管理サーバ１７０に登録する。全てのクライアントは、特定の設定グループに関連付けられ、それぞれの設定グループは、オーナーのＧＵＩＤ（globally unique identifier）と呼ばれる、それぞれのクライアント１００に割り当てられる一意な識別子（ＵＩ）を有する。

クライアント１００に対するオーナーのＧＵＩＤの割り当ては、任意の数の方法により実行されてもよい。一つの実施例において、クライアント１００のソフトウェアインストールパッケージは、後にクライアント１００が利用可能となるように、内部に組み込まれたプロパティとしてオーナーのＧＵＩＤを含んでもよい。この場合、それぞれのグループごとに異なるインストールパッケージが存在し、これらのインストールパッケージのそれぞれは、異なるＵＲＬを介して一意に識別されうる。オーナーのＧＵＩＤを割り当てる別の例では、例えば、ユーザがクライアント１００をインストールする前又は後に設定のグループを選択することを可能としてもよいし、管理サーバ１７０がクライアントのＩＰアドレス、コンピュータ名、又は現在のユーザのユーザ名など、クライアントについての情報に基づいて、オーナーＧＵＩＤを割り当てることを可能としてもよい。

図３は、クライアント１００を管理サーバ１７０に登録する実施例の統一モデリング言語（Unified Modeling Language：ＵＭＬ）シーケンスを示す。インストーラ１８０が実行されると、インストーラ１８０は、ファイルのインストール３００１及び他の共通のインストールタスクを実行するとともに、オーナーＧＵＩＤの格納３００２を実行する。インストーラ１８０が終了するとき、その最後のタスクは、管理部の起動３００３を実行することにより、管理部１５０（例えば、キャッシュ管理部）を起動することである。

管理部１５０は、キャッシュ１０３の構成及び設定の取得、適用、及び更新を含む、クライアント側のキャッシュ管理機能を担当する。管理部１５０が最初に実行されると、管理サーバ１７０への最初の登録を実行するための登録ステップ３０１０を実行する。新規のクライアント１００が管理サーバ１７０に登録するたびに、管理サーバ１７０は、そのクライアントによる管理サーバ１７０への後の相互作用のための一意な識別子を割り当てるクライアントＧＵＩＤの割り当てステップ３０２０を実行する。管理サーバ１７０は、更に、新しいクライアント１００に関連付けられた任意の初期タスクを生成するために、タスク生成ステップ３０２１を実行する。管理サーバ１７０は、ステップ３０３０において、場合によっては新しい設定又はライセンスタスクなどの新規クライアントのための初期タスクとともに、新規クライアントＧＵＩＤを新規クライアント１００に返信する。

一つの実施の形態において、管理部１５０は、いったん登録した後、例えば管理サーバ１７０の管理者により変更された設定の結果として生成された新規のタスクがないか定期的に管理サーバ１７０をチェックする。これについては、図４を参照して更に後述するＵＭＬタスクループ３０４０において説明する。

３．２ ＭＭＣタスク
図４は、本発明の実施の形態に係るＵＭＬフレームタスクループ３０４０の例を示すＵＭＬシーケンス図である。

図４を参照して、ＵＭＬフレームタスクループ３０４０は、管理部１５０が管理サーバ１７０から取得するタスクの一般的な処理を示す。管理部１５０は、定期的に（例えば、５秒おきに）、タスク要求ステップ４００１において、管理サーバ１７０の管理者によりなされる設定の変更の結果として生成されうる新しいタスクをチェックする。タスク取得ステップ４０１０においてタスクが返信された場合、タスク処理ステップ４０２０においてタスクが適用される。実行されたタスクの結果は、結果報告ステップ４０３０において、管理サーバ１７０に報告される。

図４は、タスク取得ステップ４０１０において管理サーバ１７０により管理部１５０へ送信される一般化されたタスク４０１を更に示す。タスクは、タイプ４０２及びオプションのペイロード４０３により定義される。タスク４０１のタイプ４０２及びペイロード４０３は様々であり、文字列、バイナリデータなどを含む様々なエンコードにより表現されてもよい。タスク処理４０２０において、１以上のタスクが処理されてもよく、それらはそれぞれ異なるタイプであってもよい。それぞれの特定のタスクの処理は、タスク処理４０２０の個々のバリエーションとして後述する。全てのタスクが処理された後、管理部１５０は、管理サーバ１７０にタスクの結果を送信するための結果報告４０３０を実行する。

図５は、管理サーバ１７０からタスクが取得されたときの管理部１５０によるタスクの一般的な処理の実施例のＵＭＬシーケンスを詳細に示す。タスクループ３０４０の繰り返しのそれぞれにおいて１以上のタスクを取得可能であり、これらのタスクはループ５０００において管理部１５０により処理される。タスクのそれぞれは、ステップ５０１０において、タスクタイプ４０２により決定されたタスクのタイプに基づいて処理される。

３．２．１ 設定更新タスク
例えば、引き続き図５を参照して、管理部１５０が、タスクタイプ４０２に「Update Settings」が設定されたタスク４０１を取得した場合、ペイロード４０３は、クライアント１００で実行される必要がある、アプリケーション設定データの更新（ステップ５０１１）や、サイト設定データの更新（ステップ５０１２）や、設定テンプレートの設定（ステップ５０１３）など、複数のサブタスクを含みうる。これらについては、それぞれ、図６〜８を参照して後で詳述する。

設定更新タスクのペイロードが、アプリケーション設定が更新される必要があることを示す場合、ステップ５０１１においてアプリケーション設定が更新される。アプリケーション設定データは、細粒度制御、又は、例えばキャッシュ１０３及び／又は管理部１５０の動作を制御するための、クライアント１００の複雑な動作パラメータを提供することができる。例えば、アプリケーション設定データは、どのＨＴＴＰリクエストがキャッシュされるかや、特定のＵＲＬがどのようにキャッシュされるかなど、キャッシュ１０３のアプリケーション特有の動作を指定することができる。

図６は、本発明の実施の形態に係る、管理部１５０がアプリケーション設定データを含む設定更新タスク４０１のペイロード４０３を検出したときのアプリケーション設定データの処理の例を示す。まず、管理部１５０は、アプリケーション設定データを取得するために、又は、アプリケーション設定取得ステップ６００２において、例えば管理サーバ１７０からアプリケーション設定データの取得先を示す、タスクペイロードの読み込み６００１を実行する。管理部１５０は、アプリケーション設定のパース６００３において、アプリケーション設定データをパースし、アプリケーション設定保存ステップ６００４においてアプリケーション設定をストレージ１０６に保存する前に、それが有効であることをチェックする。管理部１５０は、アプリケーション設定の適用６００５において、新しい設定を適用してもよい。新しい設定の適用は、ランタイムデータ構造の更新や、コンポーネントへの通知６００６において変更を他のコンポーネント、例えばキャッシュ１０３に通知することなどを含んでもよい。

図５に戻り、設定更新タスクのペイロードが、サイト設定データが更新される必要があることを示す場合、ステップ５０１２においてサイト設定データが更新される。サイト設定データは、生成すべき専用キャッシュ、及び、どのホスト名又はＵＲＬパターンをそれぞれのキャッシュが扱うかを指定することができる。

図７は、本発明の実施の形態に係る、管理部１５０がサイト設定データを含む設定更新タスク４０１のペイロード４０３を検出したときのサイト設定データの処理の例を示す。まず、管理部１５０は、新しいサイト設定からサイトを取得するために、入手サイトの読み込み７００１を実行する。管理部１５０は、データベース１４１に格納された、更新が必要な現状のサイトを取得するために、既存サイトの読み込み７００２を実行する。ループ７００３において、入手サイト設定におけるそれぞれのサイトについて、管理部１５０は、例えば新規サイトの追加又は既存サイトの更新を実行する、入手サイトの適用７００４を実行してもよい。サイトの保存７００５において、変更がデータベース１４１に保存されてもよい。管理部は、それぞれの変更をキャッシュ１０３などの他のコンポーネントが適用できるように、コンポーネントに通知７００６を実行してもよい。次に、ループ７０１０において、管理部１５０は、もはやサイト設定の一部ではないサイトを探し、削除されたサイトの消去７０１１においてそれらを消去する。

図５に戻り、設定更新タスクのペイロードが、設定テンプレートからの設定が利用可能であることを示す場合、設定テンプレートの適用５０１３においてその設定を適用する。設定テンプレートは、本発明の実施の形態のシステムの動作に影響を与える、アプリケーション設定データに類似する設定を含む。これらの設定は、アプリケーション設定における設定と異なってもよい。例えば、グラフィカルユーザインタフェースを介してエンドユーザ又は管理者により修正可能な設定など、より動的な性質を有してもよい。

図８は、本発明の実施の形態に係る、管理部１５０がペイロード４０３から設定を取得するために入手設定の読み込み８００１を実行するときの設定テンプレートの処理の例を示す。管理部１５０は、データベース１４１から現状の設定を取得するために、ローカル設定の取得８００２を実行してもよい。つづいて、入手した設定に基づいてローカル設定の更新８００３を実行してもよい。つづいて、ローカル設定をデータベース１４１に保持するために、ローカル設定の保存８００４を実行する。

設定更新サブタスクの結果は、ステップ４０３０において管理サーバ１７０に送信可能とするために収集される。

３．２．２ キャッシュ消去タスク
管理部１５０が、タスクタイプ４０２に「Purge Cache」が設定されたタスクを取得した場合、ペイロード４０３は、図５のステップ５０１４に示されるように、クライアント１００においてキャッシュを消去する命令を指定する。

図９は、本発明の実施の形態に係る、キャッシュ消去５０１４タスクを処理するためのＵＭＬシーケンスの例を詳細に示す。図９を参照して、管理部１５０は、例えば消去すべきキャッシュなどを記述したペイロード４０３からの消去設定の読み出し９００１を実行し、ループ９０１０において、指定されたそれぞれのキャッシュを消去する。それぞれのキャッシュ消去要求は、例えばホスト名又はＵＲＬパターンにより、消去すべきサイトを識別してもよい。管理部１５０は、ストレージ１０６において、そのサイトのキャッシュが格納された位置を判定するために、サイト情報の読み込み９０１１を実行し、サイトキャッシュの消去９０１２を実行可能としてもよい。

キャッシュ消去タスクの結果は、ステップ４０３０において管理サーバ１７０に送信可能とするために収集される。

３．２．３ キャッシュアイテムフラッシュタスク
管理部１５０が、タスクタイプ４０２に「Flush Cache Items」が設定されたタスクを取得した場合、ペイロード４０３は、図５のステップ５０１５に示されるように、クライアント１００においてキャッシュから特定のアイテムを消去する命令を指定する。

図１０は、本発明の実施の形態に係る、キャッシュアイテムフラッシュ５０１５タスクを処理するためのＵＭＬシーケンスの例を詳細に示す。図１０を参照して、管理部１５０は、例えばクライアント１００上のキャッシュから削除すべきキャッシュアイテムなどを記述したペイロード４０３からのフラッシュ要求の読み出し１０００１を実行する。管理部１５０は、データベース１４１から、例えば現状のコンテンツなど、それぞれのサイトのキャッシュに関する情報を取得するために、サイト情報の読み込み１０００２を実行してもよい。

つづいて、ループ１００１０（外側のループ）において、ペイロード４０３から取得されたフラッシュ要求のそれぞれについて、フラッシュ要求は、例えば正規表現又はＵＲＬパターンを用いて、キャッシュから消去すべき特定のコンテンツ又はコンテンツの種別を記述する。ループ１００２０（中間のループ）において、これらのフラッシュ要求のそれぞれについて、管理部１５０は、ストレージ１０６に格納されたサイトキャッシュに対応するフラッシュ要求にマッチしたアイテムの位置を検索するために、キャッシュアイテムの検索１００２３を実行してもよい。一つの実施例において、キャッシュアイテムは、例えばキャッシュアイテムのＵＲＬのハッシュを用いた高速検索のために、「lookup key」と名付けられたファイルに格納され、これらのキャッシュの位置検索は、それらの実際のＵＲＬを取得して比較するために、これらのキャッシュアイテムの対応するメタデータを読み出すことを必要としてもよい。

つづいて、ループ１００３０（内側のループ）において、これらのキャッシュアイテムのそれぞれについて、管理部１５０は、キャッシュアイテムのユーザフレンドリーな名前に参照をつけるマッピングファイルや、このキャッシュアイテムに対応するＨＴＴＰ応答ヘッダなど、これらのアイテムに関連する任意のコンテンツの位置を検索するために、関連アイテムの検索１００３４を更に実行してもよい。ステップ１００３５において、フラッシュリクエストにマッチするキャッシュアイテムを検出した管理部１５０は、全てのアイテムをストレージ１０６から削除する。

キャッシュアイテムフラッシュタスクの結果は、ステップ４０３０において管理サーバ１７０に送信可能とするために収集される。

３．３ 方法の実施例
図１１は、本発明の実施の形態に係る専用キャッシュ管理方法１１００の例を示す。方法１１００は、ネットワークを介してリモートサーバと通信するためのコンピュータを設定し、サーバにより提供されるコンテンツ又はサービスに対するアクセスを提供する。

処理が開始されると、ステップ１１１０において、１以上のＵＲＬにそれぞれ関連付けられた１以上の専用キャッシュが生成される。それぞれのキャッシュは、ステップ１１２０において、１以上のルールを用いて管理される。クライアントアプリケーションからサーバに対するＵＲＬのリクエストは、ステップ１１３０において、ユーザには気づかれないようにインターセプトされる。キャッシュは、ステップ１１４０において、リクエストをいつ送信するかを自動的に判定し、クライアントアプリケーションがリクエストをサーバに送信してサーバから応答を受信したようにクライアントアプリケーションからみえるようにネットワークを介したサーバからの応答を提供する。キャッシュは、（１）ステップ１１５０において、クライアントアプリケーションがリクエストを送信したようにサーバからみえるようにサーバにリクエストを送信し、サーバからの応答を提供し、ストレージデバイスに応答を格納するか、又は、（２）ステップ１１６０において、キャッシュから応答を提供することにより、これを実行する。処理はステップ１１２０に戻り、キャッシュを管理し、リクエストをインターセプトして提供する。

４ 結論
上述した例は、特定のインターネットアプリケーション及びプロトコルに関連して示されたが、本発明はこれらのインターネットアプリケーション又はプロトコルに限定されない。現在及び将来の他のインターネットアプリケーション又はプロトコルが、上述の適応的な態様に用いられうる。

本発明が特定の実施の形態に関連して説明されたが、これらの実施の形態は単に説明のためのものであり、限定的ではない。他の多くの本発明の適用例及び実施例が、本開示、後述の特許請求の範囲、及びそれらの均等物に照らして明らかである。

Claims (40)

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. 前記コマンドは、前記キャッシュ中のコンテンツを削除するためのものであることを特徴とする請求項２７に記載のシステム。
30. 前記コマンドは、ＵＲＬパターンに対応する前記キャッシュ中のコンテンツを削除するためのものであることを特徴とする請求項２９に記載のシステム。
31. 前記コマンドは、前記キャッシュ中のコンテンツをリフレッシュするためのものであることを特徴とする請求項２７に記載のシステム。
32. ネットワークを介してリモートのサーバと通信し、前記サーバにより提供されるコンテンツ又はサービスを提供するための方法であって、
    それぞれが１以上のＵＲＬに関連付けられた１以上の専用キャッシュを生成するステップと、
    それぞれのキャッシュについて、１以上のルールにしたがって前記キャッシュを管理するステップと、
    クライアントアプリケーションから前記サーバに対する前記ＵＲＬのうちの１つのリクエストを透過的にインターセプトするステップと、
    前記リクエストをいつ送信するか、及び、前記クライアントアプリケーションが前記リクエストを前記サーバに送信して前記サーバから応答を受信したように前記クライアントアプリケーションからみえるように前記ネットワークを介した前記サーバからの応答をいつ提供するかを自動的に判定するステップと、
    を備え、
    前記自動的に判定するステップは、
    前記クライアントアプリケーションが前記リクエストを送信したように前記サーバからみえるように前記サーバに前記リクエストを送信し、前記サーバからの応答を提供し、ストレージデバイスに前記応答を格納するステップ、又は、
    前記キャッシュの１つから前記応答を提供するステップを含む
    ことを特徴とする方法。
33. 前記１以上のキャッシュを再設定するステップを更に備えることを特徴とする請求項３２に記載の方法。
34. 前記キャッシュのそれぞれに関連付けられた前記ＵＲＬを再設定するステップを更に備えることを特徴とする請求項３２に記載の方法。
35. 前記ストレージデバイスに前記応答をいつ格納するか、又は、前記キャッシュから前記応答をいつ提供するかを決定するためにＵＲＬパターンを用いるステップを更に備えることを特徴とする請求項３２に記載の方法。
36. 格納された応答が前記キャッシュに保持される期間を決定するためにルールを使用するステップを更に備えることを特徴とする請求項３２に記載の方法。
37. 格納された応答が、指定された値に基づいて前記サーバから妥当性を確認されることなしに、前記応答に供給するために使用可能な期間を決定するためにルールを使用するステップを更に備えることを特徴とする請求項３２に記載の方法。
38. 前記キャッシュ中のコンテンツを削除するためのコマンドに応答するステップを更に備えることを特徴とする請求項３２に記載の方法。
39. ＵＲＬパターンに対応する前記キャッシュ中のコンテンツを削除するためのコマンドに応答するステップを更に備えることを特徴とする請求項３２に記載の方法。
40. 前記キャッシュ中のコンテンツをリフレッシュするためのコマンドに応答するステップを更に備えることを特徴とする請求項３２に記載の方法。

Images