JP2017509074A - 動的キャッシュ割当およびネットワーク管理 - Google Patents

Abstract

【解決手段】ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを動的にキャッシュするためのシステムおよび方法が提供される。システムは、プロセッサと、ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを、ユーザによるネットワーク上でのサイトを用いた活動に基づいて保存するためのキャッシュアカウントを維持するための第１の記憶装置と、統計を保存するための第２の記憶装置と、非一時的物理媒体とを含む。非一時的物理媒体は命令を保存されていて、プロセッサによって実行されるときに、プロセッサに、ネットワーク活動に基づいてキャッシングに対するサイトの適合性に関する統計を収集させ、キャッシング適合性統計を第２の記憶装置に保存させ、そしてキャッシング適合性統計に基づいてキャッシュアカウントを動的に生成、削除、またはサイズ変更させる。【選択図】図１

Description

本発明の実施形態の態様は、動的キャッシュ割当（ｄｙｎａｍｉｃ ｃａｃｈｅ ａｌｌｏｃａｔｉｏｎ）およびネットワーク管理に関する。

スマートフォンやタブレットコンピュータ（タブレット）などのモバイル装置（ｍｏｂｉｌｅ ｄｅｖｉｃｅｓ）では、多くのエンドユーザが、今日では階層によって上限を定められているデータプランによって管理される。これは、部分的に、データ消費がインフラ能力よりも速く増大しているためである。さらに、ローミングコストが例えば欧州において法外となり得る（欧州では、ローミングは例えば国境を横切って一般的であり得る）。加えて、パフォーマンスがカバレージおよび輻輳に基づいて著しく変わることがある。これは、例えば、場所および無線通信事業者によって大きく変わるネットワークカバレージに起因することがある。

通信事業者は悪影響も経験している。ネットワークの輻輳は、セルのカバレージ／品質を減じる。事実上、セルサイトが過度の輻輳に適合するように「収縮する」。加えて、高いローミングコストが競合通信事業者に支払われる必要があることが多い。これは、特に小規模通信事業者に影響を及ぼし、小規模通信事業者は、ネットワーク外カバレージのために大規模の競合他社にローミングコストをより多く支払わなければならない。

企業もまた、とりわけトラベリングエグゼクティブにとって高いデータプランコストがかかることがある。オフラインでさらに働くなどの代替案は快適でないことがあり、これは、特にタブレットユーザにとって生産性を損なう。

ウェブサイトは、より遅いモバイルネットワークおよびあまり強力でない装置のために、ユーザ体験が緩慢／不十分である。これは、部分的にはセルの待ち時間に起因することがあり、セルの接続設定（しばしば１秒〜２秒）に起因して高いことがある。さらに、帯域幅のコストは、ウェブサイトアクセス、例えばウェブサイトの映像または音声にとって高くなる可能性がある。

このような問題の１つの可能な解決法が、媒体を解像度の低いバージョンに置き換えることによりプロクシサーバにサーバ応答のサイズを減少させることであるが、これにより媒体品質が低下し、ユーザ体験が減少する。別の解決法が、任意のオープンＷｉ−Ｆｉネットワークに積極的に接続することであるが、信頼できないネットワークに接続するのは危険な場合がある。別の解決法が、クライアント／サーバソフトウェアにデータ重複排除や下位レベルのパケットキャッシング（例えばＴＣＰ）などの様々なＷＡＮ最適化技法を提供させることであるが、これは、広範囲のサーバサイドのソフトウェアまたはアプライアンスを展開する必要があり、起点サーバへの往復／要求を減じるときに上位レベルのキャッシング（例えば、ＨＴＴＰ）ほど有効ではないことが多い。

上位レベルのキャッシングは多くの方法で行うことができる。例えば、キャッシュは、最長時間未使用のキャッシングプロトコルで管理される、装置によって受信されるすべての応答を保存することができる。しかしながら、これは、アクセスを繰り返さないデータ集約型アプリケーション用のキャッシングリソースを無駄にするとともに、より大きなアプリケーションのフットプリントに有利なようにキャッシュからより小さいアプリケーションのフットプリントを締め出す。対照的に、別の解決法は、各アプリケーション（例えば、ソフトウェアアプリケーション、すなわちアプリ（ａｐｐ））用の別個のキャッシュを使用することであるが、その場合、この種のキャッシュは、通信事業者または企業によって構成することができないはずであり、反復活動（例えば、その活動が同じコンテンツに対する局所的な再三の要求を示したときに、１つのアプリケーションを好む）または同じコンテンツ用のアプリケーション相互間の共有活動を活用することもできないはずである。

本発明の実施形態は、これらおよびその他の問題に対処するものである。他の実施形態は、例えばデスクトップコンピュータよりも限られたリソース（例えば、記憶装置、帯域幅、オペレーティングシステム）を有する携帯用装置（スマートフォン、タブレットなど）に適用されるような問題に対処するものである。他の実施形態は、限られたネットワーク帯域幅をより効率的に利用し、ネットワーク上での待ち時間を改善するために、動的キャッシュ割当のシステムおよび方法を対象とする。

本発明の一実施形態によれば、ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを動的にキャッシュするためのシステムが提供される。システムは、プロセッサと、ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを、ユーザによるネットワーク上でのサイトを用いた活動に基づいて保存するためのキャッシュアカウントを維持するための第１の記憶装置と、統計を保存するための第２の記憶装置と、非一時的物理媒体とを含む。非一時的物理媒体は命令を保存されていて、プロセッサによって実行されるときに、プロセッサに、ネットワーク活動に基づいてキャッシングに対するサイトの適合性に関する統計を収集させ、キャッシング適合性統計を第２の記憶装置に保存させ、そしてキャッシング適合性統計に基づいてキャッシュアカウントを動的に生成、削除、またはサイズ変更させる。

キャッシング適合性統計は、ユーザによるサイトを用いたキャッシュ可能活動の統計を含むことができる。命令は、プロセッサによって実行されるときに、さらにプロセッサに、キャッシュ可能活動統計に基づいてキャッシュアカウントを動的に生成させることができる。

キャッシュ可能活動統計は、ユーザによるサイトを用いたキャッシュ可能要求、またはキャッシュ可能要求に対応するネットワーク活動のキャッシュ可能バイトを含むことができる。

キャッシング適合性統計は、ユーザによるサイトを用いた反復活動の統計をさらに含むことができる。反復活動統計は、ユーザによるサイトを用いた反復要求を含むことができる。

命令は、プロセッサによって実行されるときに、さらにプロセッサに、キャッシング適合性統計に基づいてサイトのうちの上位サイトを識別させ、サイトのうちの上位サイトに対する反復要求を追跡させることができる。

命令は、プロセッサによって実行されるときに、さらにプロセッサに、キャッシュ可能要求またはキャッシュ可能バイトに基づいてサイトのうちの上位サイトを識別させることができる。

キャッシング適合性統計は、ユーザによるサイトを用いた反復活動の統計を含むことができる。命令は、プロセッサによって実行されるときに、さらにプロセッサに、反復活動統計に基づいてキャッシュアカウントを動的に生成させることができる。

反復活動統計は、ユーザによるサイトを用いた反復要求を含むことができる。

命令は、プロセッサによって実行されるときに、さらにプロセッサに、キャッシング適合性統計に基づいてサイトのうちの上位サイトを識別させ、サイトのうちの上位サイトに対する反復要求を追跡させることができる。

キャッシング適合性統計は、ユーザによるサイトを用いたキャッシュ可能活動の統計をさらに含むことができる。命令は、プロセッサによって実行されるときに、さらにプロセッサに、キャッシュ可能活動統計に基づいてサイトのうちの上位サイトを識別させることができる。

キャッシュ可能活動統計は、ユーザによるサイトを用いたキャッシュ可能要求、またはキャッシュ可能要求に対応するネットワーク活動のキャッシュ可能バイトを含むことができる。命令は、プロセッサによって実行されるときに、さらにプロセッサに、キャッシュ可能要求またはキャッシュ可能バイトに基づいてサイトのうちの上位サイトを識別させることができる。

本発明の別の実施形態によれば、ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを動的にキャッシュする方法が提供される。方法は、プロセッサにより、非一時的物理媒体に保存された命令を実行すること、プロセッサにより第１の記憶装置上に、ユーザによるネットワーク上でのサイトを用いた活動に基づいてユーザによってネットワークを通じてアクセスされるサイトのコンテンツを保存するためのキャッシュアカウントを維持すること、プロセッサにより第２の記憶装置に統計を保存すること、プロセッサにより、ネットワーク活動に基づいてキャッシングに対するサイトの適合性に関する統計を収集すること、プロセッサにより、第２の記憶装置にキャッシング適合性統計を保存すること、および、プロセッサにより、キャッシング適合性統計に基づいてキャッシュアカウントを動的に生成、削除、またはサイズ変更すること、を含む。

キャッシング適合性統計は、ユーザによるサイトを用いたキャッシュ可能活動の統計を含むことができる。方法は、プロセッサにより、キャッシュ可能活動統計に基づいてキャッシュアカウントを動的に生成することをさらに含むことができる。

キャッシュ可能活動統計は、ユーザによるサイトを用いたキャッシュ可能要求、またはキャッシュ可能要求に対応するネットワーク活動のキャッシュ可能バイトを含むことができる。

キャッシング適合性統計は、ユーザによるサイトを用いた反復活動の統計をさらに含むことができる。反復活動統計は、ユーザによるサイトを用いた反復要求を含むことができる。

方法は、プロセッサにより、キャッシング適合性統計に基づいてサイトのうちの上位サイトを識別すること、および、プロセッサにより、サイトのうちの上位サイトに対する反復要求を追跡すること、をさらに含むことができる。

方法は、プロセッサにより、キャッシュ可能要求またはキャッシュ可能バイトに基づいてサイトのうちの上位サイトを識別することをさらに含むことができる。

キャッシング適合性統計は、ユーザによるサイトを用いた反復活動の統計を含むことができる。方法は、プロセッサにより、反復活動統計に基づいてキャッシュアカウントを動的に生成することをさらに含むことができる。

反復活動統計は、ユーザによるサイトを用いた反復要求を含むことができる。

方法は、プロセッサにより、キャッシング適合性統計に基づいてサイトのうちの上位サイトを識別すること、および、プロセッサにより、サイトのうちの上位サイトに対する反復要求を追跡すること、をさらに含むことができる。

キャッシング適合性統計は、ユーザによるサイトを用いたキャッシュ可能活動の統計を含むことができる。方法は、プロセッサにより、キャッシュ可能活動統計に基づいてサイトのうちの上位サイトを識別することをさらに含むことができる。

キャッシュ可能活動統計は、ユーザによるサイトを用いたキャッシュ可能要求、またはキャッシュ可能要求に対応するネットワーク活動のキャッシュ可能バイトを含むことができる。方法は、プロセッサにより、キャッシュ可能要求またはキャッシュ可能バイトに基づいてサイトのうちの上位サイトを識別することをさらに含むことができる。

添付図面は、この説明とともに、本発明の実施形態の例を示す。これらの図面は、この説明とともに、本発明の態様および原理をより良く説明するのに役立つ。

本発明の一実施形態による動的キャッシュ割当およびネットワーク管理の実施での使用に適したモバイル装置（スマートフォンなど）のアーキテクチャ例を示す図である。

本発明の一実施形態による動的キャッシュ割当およびネットワーク管理の実施での使用に適したデータセット例を示す図である。

本発明の一実施形態による反復活動を追跡する方法例を示す図である。

本発明の実施形態による反復活動を検出する方法例を示す図である。 図４の本発明の実施形態による反復活動を検出する方法例を示す別の図である。 本発明の別の実施形態による反復活動を検出する方法例を示す図である。 図６の本発明の実施形態による反復活動を検出する方法例を示す別の図である。

本発明の一実施形態によるキャッシュアクセス重み付けおよび活動化／非活動化の例を示す２つのグラフである。

本発明の一実施形態によるキャッシングスペースを動的に割り当てる（動的キャッシュ割当）方法例を示す図である。 本発明の一実施形態によるキャッシングスペースを動的に割り当てる（動的キャッシュ割当）方法例を示す別の図である。 本発明の一実施形態によるキャッシングスペースを動的に割り当てる（動的キャッシュ割当）方法例を示す別の図である。 本発明の一実施形態によるキャッシングスペースを動的に割り当てる（動的キャッシュ割当）方法例を示す別の図である。 本発明の一実施形態によるキャッシングスペースを動的に割り当てる（動的キャッシュ割当）方法例を示す別の図である。

本発明の一実施形態による動的キャッシング編成例を示す図である。

次に、本発明の実施形態例について添付図面を参照しながら説明する。図面において、同一または類似の参照番号は、全体を通じて同一または類比の要素を意味する。本明細書では、「ｍａｙ」という用語の使用は、本発明の実施形態を説明するとき、「本発明の１つまたは複数の実施形態」を意味する。加えて、「ｏｒ」などの代替言語の使用は、本発明の実施形態を説明するとき、列挙されるそれぞれの対応アイテムに対する「本発明の１つまたは複数の実施形態」を意味する。

１つまたは複数の実施形態では、動的キャッシュ割当およびネットワーク管理のシステムおよび方法が提供される。実施形態例について図１〜図１４を参照しながら説明する。

図１は、本発明の一実施形態による動的キャッシュ割当およびネットワーク管理の実施での使用に適したモバイル装置（スマートフォンなど）のアーキテクチャ例１００である。例として、モバイル装置は、Ａｎｄｒｏｉｄ（登録商標）（アンドロイド）フォンとすることができる。例示する目的で、モバイル装置は、Ａｎｄｒｏｉｄフォンであるものとする。さらに、この種のモバイル装置は多くのユーザをサポートすることができるかもしれないが、説明を簡単にするために、モバイル装置は特定のユーザ専用であるものとし、したがって「ユーザ（ｕｓｅｒ）」および「モバイル装置（ｍｏｂｉｌｅ ｄｅｖｉｃｅ）」（すなわち個人でまたは携帯用に使用される計算装置）という用語は全体を通じて同意語として用いられることがある。

本発明の１つまたは複数の実施形態によれば、モバイル装置上の一般的なアーキテクチャ（アーキテクチャ１００など）は、例えば、モバイル装置が例えばＷｉ−Ｆｉまたはセルラーネットワークを通じてアクセスするアプリケーションサーバ（またはアプリサーバ）２５０からアプリケーション（例えば、モバイルアプリ、または単に「アプリ」）を起源とする要求をサポートすることができる集中型キャッシングエンジン１１０を提供する。この手法は、キャッシュされたコンテンツが複数のネットワーク（例えばＷｉＦｉ（登録商標）およびセルラー）を通じて更新され、複数のアプリを通じて共有されることをイネーブルにするとともに、キャッシングが中央管理されることを可能にするが、本発明はこれらに限定されるものではない。他の実施形態では、キャッシングは、例えば各アプリ内で走るキャッシングエンジンを用いて分散して行うことができ、キャッシング全体が効果的に中央管理されるように協調して作動している。

スマートフォン１００のアプリおよび他のプログラマブルコンポーネントは、例えば、スマートフォン１００の非一時的記憶装置に保存されるコンピュータ命令セットとして実装され、スマートフォン１００の１つまたは複数のプロセッサ上で実行されるように構成することができる。キャッシングエンジン１１０は、ウェブブラウザなどから特定のウェブサイトに対する要求をサポートすることもできる。したがって、説明を簡単にするために、「アプリケーション（ａｐｐｌｉｃａｔｉｏｎ）」、「アプリ（ａｐｐ）」、「ウェブサイト（ｗｅｂ ｓｉｔｅ）」、「サイト（ｓｉｔｅ）」などの用語は、キャッシングエンジン１１０用のキャッシュ可能コンテンツのカテゴリを参照するときに、本出願を通じてある程度同義に用いられることがある。

キャッシングエンジン１１０は、プロクシサーバ（例えば、オペレーティングシステム（ＯＳ）ネットワーク設定を通じて）、仮想私設ネットワーク（ＶＰＮ）クライアント（例えば、ＯＳネットワーク設定を通じて）、インターセプションレイヤ（ｉｎｔｅｒｃｅｐｔｉｏｎ ｌａｙｅｒ）などのいくつかの異なる機構から係合することができる。例えば、図１におけるプロクシサーバ１３０、ＶＰＮクライアント１４０、またはインターセプションレイヤ１５０および１５５を参照のこと。キャッシングエンジン１１０は、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）１６０上で走ることができる。キャッシュされたコンテンツは、フラッシュメモリ１７０や他の不揮発性記憶装置などの物理的記憶装置に保存することができる。一般性を失わずに、この種の装置は、時には「ディスク（ｄｉｓｋ）」と呼ばれることがあるが、半導体ドライブなどの任意のタイプの非一時的記憶装置とすることができる。加えて、キャッシュされたコンテンツは、全部または一部がランダムアクセスメモリなどの揮発性記憶装置に保存されてもよく、この揮発性記憶装置は、不揮発性記憶装置と組み合わせて、例えば、ごく最近アクセスされたコンテンツが、そのコンテンツがより遅い不揮発性記憶装置へ移行される前により速い揮発性記憶装置に保存される段階的な方法で使用することができる。

プロクシサーバ１３０は、アプリケーションやカーネルドライバなどの様々なフォームファクタで、またはモバイル装置上のＯＳの中で走り、ネットワーク接続を、例えばＯＳのネットワーク設定によって受け入れるように構成することができる。１つまたは複数の実施形態では、プロクシサーバは、キャッシングエンジン１１０がその上で走る上記ＪＶＭ１６０などのＪＶＭ内で走ることができる。プロクシサーバ１３０は、クライアントアプリケーションのために仲介役として働くことができる。例えば、プロクシサーバ１３０は、別のＪＶＭ１６５内で走るアプリ１８０の要求に対応することができる。

アプリ１８０は、例えば、ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎ１９０などのＡｎｄｒｏｉｄサービスを使用するインターネットにアクセスしてもよい。この場合、ＨＴＴＰはハイパーテキスト転送プロトコルを表し、ＵＲＬはユニフォームリソースロケータ（例えば、ウェブアドレス）を表す。次いで、ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎ１９０は、インターネットにアクセスするためにネットワークサービス２００を呼び出すことができる。ネットワークサービス２００は、例えば、アクセスポイント名（ＡＰＮ）２１０（例えば、３Ｇなどのモバイルネットワーク）またはＷｉ−Ｆｉ接続２２０を使用して、インターネットにアクセスすることができる。ネットワークサービス２００は、システムに、またはＡＰＮまたはＷｉＦｉ接続に全体的に適用されるプロクシ構成を用いて、アプリ１８０からプロクシサーバ１３０への要求の経路を定めることができる。ネットワークサービス２００は、他の様々な方法を用いて、例えばネットワークトンネル（ＴＵＮ）２３０またはＩＰルーティングテーブル（「アイピーテーブルズ（ｉｐｔａｂｌｅｓ）」としても知られている）によって、アプリ１８０からプロクシサーバ１３０までの要求の経路を定めることもできる。

ネットワークサービス２００は、要求が、ソケット１２０（例えば、インターネットに接続するためのネットワークソケット）などの標準通信層を通じて送信され、プロクシサーバ１３０によって受信され得るように、インターネットにアクセスするためにプロクシを直接的または間接的に（例えば、装置上を走るアプリによって直接検出され使用されるグローバルシステムプロクシとして、またはＡＰＮ２１０もしくはＷｉ−Ｆｉ接続２２０上の設定を通じて間接的に）指定するように構成することができる。プロクシサーバ１３０は、（それ自体にループバックするのを回避するためにＡＰＮまたはＷｉＦｉプロクシ構成を迂回しながら）ネットワークサービス２００を通じてアプリサーバ２５０に要求をすることができ、アプリサーバ２５０はその要求に対応し、任意の応答通信をプロクシサーバ１３０に戻す。次いで、プロクシサーバ１３０は、キャッシングエンジン１１０を通じて応答の一部もしくは全部をキャッシュしてから、または応答を全くキャッシュしないで、応答をネットワークソケット１２０経由でアプリ１８０に戻し、上記の同じ段階を逆方向に進む。

アプリサーバ２５０に要求をする代わりに、プロクシサーバ１３０が代わりにキャッシングエンジン１１０からの要求に対応することができる。例えば、アプリサーバ２５０の同一または類似の要求が既に要求されており、その要求に関係する十分な応答または他の関連データがキャッシングエンジン１１０を通じてキャッシュされていれば、プロクシサーバ１３０は、アプリ１８０の要求に応答するためにキャッシュされたデータを使用することができる。これは、ネットワーキングインフラ（例えば無線通信）およびその他のリソース（アプリサーバ２５０のリソースなど）を使用すること、ならびに要求に応答することを（例えば、記憶装置からの応答に供給する低い電力消費に対するセルラー無線を通じてその応答に供給するより高い電力消費を活用することにより）回避するはずである。

ＡＰＮまたはＷｉ−Ｆｉ接続上にプロクシ構成を使用する代わりに、ネットワークサービス２００は、様々な他の手段を通じてプロクシサーバ１３０への要求の経路を定めるように構成することもできる。例えば、別の手法は、ＶＰＮ接続を確立するためにネットワークトンネル（ＴＵＮ）２３０を使用することであり、ＶＰＮ接続は、ネットワーク送信を処理するためにＶＰＮサービス１４０へのネットワーク活動の経路を定めることができる。次いで、ＶＰＮサービス１４０は、プロクシサーバ１３０への要求の経路を定めるか、場合によりキャッシングエンジン１１０と直接情報のやりとりをして、キャッシュからの応答に応えるかまたは（必要に応じて）ソケット１２０を用いてアプリサーバ２５０にアクセスし、それによって要求に対応し、応答をネットワークトンネル２３０経由で戻すことができる。

キャッシングエンジン１１０に係合するための別の機構が、アプリ内のインターセプションレイヤ（インターセプションレイヤ１５０および１５５など）を使用してトラフィックをキャッシングプロセスにリダイレクトすることである。例えば、上記例では、ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎ１９０にネットワークサービス２００を呼び出させてインターネットにアクセスする前にまたはそうする代わりに、ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎは、インターセプションレイヤ１５０にアプリ１８０からの要求をインターセプトさせ、キャッシングエンジン１１０を直接呼び出させて、キャッシングエンジン１１０のキャッシュからの応答に対応することができる。インターセプト１５０からキャッシュエンジン１１０を呼び出すのは、当業者には明らかであろう任意の標準プロセス間通信機構、例えば、メッセージ待ち行列、名前付きパイプ、または共有メモリを通じて行うことができる。

キャッシングエンジン１１０がＪＶＭ１６０などの別個のプロセスの中で動作するのに加えて、他の実施形態では、キャッシングエンジン１１０は、ＪＶＭ１６５やブラウザ１８５（ウェブブラウザなど）など要求プロセスに埋め込まれていてもよい。その場合、キャッシングエンジン１１０は、プロセス間通信を全く必要とせずに要求に対応することができる。例えば、キャッシングエンジン１１０は、キャッシュからの要求に対応する（可能かつ適切な場合）または応答してインターセプションレイヤ１５０に戻ることができ、それによって、次いで要求はネットワークサービス２００まで通り抜けることが可能となり得る。次いで、ネットワークサービス２００は要求を処理のためにプロクシサーバ１３０に送信することができる（プロクシサーバ１３０がＡＰＮ２１０、Ｗｉ−Ｆｉ２２０、ネットワークトンネル２３０などを通じてイネーブルにされた場合）、あるいは、ネットワークサービス２００は要求をアプリサーバ２５０に直接送信することができる（例えば、ＪＶＭ１６０内の別個のプロクシベースのキャッシュエンジン１１０を走らせていないとき）。異なるアプリに埋め込まれる複数のキャッシングエンジン１１０のインスタンスは、同じキャッシュ済みコンテンツが複数のアプリを通じてアクセスされ得るように、同じキャッシュを共有することができる。

別の実施形態では、キャッシングエンジン１１０が要求に対応することができない場合、処理は上述したように（例えば、ネットワークサービス２００を通じて）続く。別の実施形態では、不成功のキャッシングエンジン１１０がインターセプトした後で処理がネットワークサービス２００を通じて続けば、要求に印が付けられ、したがって、後のプロクシサーバ１３０がその要求を処理すれば、プロクシサーバ１３０は同一応答に対してキャッシングエンジン１１０の第２の要求を行わないことを気付くはずである。

別の例では、ウェブブラウザ１８５はインターネットにアクセスしようとする。上記のアプリ１８０と同様に、ウェブブラウザ１８５は、複数の異なる手法によってキャッシングエンジン１１０を巧みに利用することができる。例えば、ウェブブラウザ１８５は、ネットワークソケット１２５を使用することでインターネットにアクセスするように構成することができ、それにより、次いで、例えば上述したようにソケット１２０またはＶＰＮサービス１４０を使用してプロクシサーバ１３０からアプリサーバ２５０および／またはキャッシングエンジン１１０にアクセスするためにネットワークサービス２００を使用することができる。同様に、インターセプションレイヤ１５５は、ウェブブラウザ１８５に追加されてもよく、それにより、次いで、上述したように要求に対応するためにウェブブラウザ１８５からの要求をインターセプトし、キャッシングエンジン１１０を直接呼び出すことができる。別の実施形態として、キャッシングエンジン１１０は、キャッシングエンジン１１０がプロセス間通信を全く必要とせずに要求に直接対応することができるように、ブラウザ１８５と共に直接埋め込まれてもよい。例えば、キャッシングエンジン１１０は、キャッシュからの要求に対応する（可能かつ適切な場合）または応答してインターセプションレイヤ１５５に戻ることができ、それによって、次いで要求はネットワークサービス２００まで通り抜けることが可能となり得る。

より詳細には、上記技法は、セキュアソケットレイヤ（ＳＳＬ、例えば暗号化される）通信と非ＳＳＬ（例えば暗号化されない）通信との間の考えられる差異化と、既存のインタフェースに統合されてもよい。アプリケーションとの統合は、非ＳＳＬ通信に対して、例えばネットワークスタック内の集中位置でイネーブルにすることができる。例えば、プロクシサーバ１３０は、ネットワークプロトコルの全部または一部のためのプロクシとして、例えば、ＨＴＴＰ、ＨＴＴＰＳ、またはその両方だけのためのプロクシとして構成することができる。同様に、プロクシサーバ１３０は、ネットワークインタフェースの全部または一部のためのプロクシとして、例えば、セルラー、ＷｉＦｉ、またはその両方のためのプロクシとして構成することができる。例えば、ＡＰＮ２１０アクセスの場合、セルラーアクセスポイントをプロクシサーバ１３０に置くことができる。アイピーテーブルズアクセスの場合、対応するインターネットプロトコル（ＩＰ）ルーティングテーブルエントリを置くことができる。ＶＰＮサービスの場合、ＶＰＮクライアント（ＶＰＮサービス１４０など）はプロクシサーバ１３０へのトラフィックの経路を定めることができる。Ｗｉ−Ｆｉの場合、プロクシサーバ１３０を各Ｗｉ−Ｆｉポイント（ＡＰ）に対して置くことができる。

加えて、ＳＳＬ通信を使用するアプリケーションとの統合で、暗号化されていないネットワークデータへのアクセスを求めることができる。この場合に使用することができる手法がいくつかある。中間者手法の場合、ＳＳＬは、信頼されている認定機関（ＣＡ）を通じてサーバに扮することによって解除することができる。ソフトウェア開発キット（ＳＤＫ）手法（図１のインターセプションレイヤ１５５などを用いる）の場合、ビルド時のキャッシングエンジン１１０に対するフックとのリンキングを、ＳＳＬ暗号化より上位で使用することができる。再リンク手法の場合、ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎ１９０などを用いてカスタム交換アプリケーションプログラミングインタフェース（ＡＰＩ）を使用するために既存のアプリを逆コンパイルし再リンクすることができる。ウェブブラウザ１８５のようなブラウザなどを用いる代替手法の場合、インターセプションが既に配線されている所にアプリの代替バージョンを設けることができる。これは、広く用いられているオープンソースアプリに特に適しているかもしれない。

図１に示すように、キャッシングエンジン１１０は、ソフトウェアスタック内の１つまたは複数の場所で呼び出すことができ、キャッシングエンジン１１０の複数のインスタンス、例えば、キャッシングエンジン１１０のそれ自体が埋め込まれているインスタンスを有するアプリケーションを呼び出して、それぞれのアプリケーションがプロクシサーバ１３０を有するモバイル装置１００上で同時に走るのは、無効であり、非効率的であり、さらには非生産的であるかもしれない。したがって、一実施形態では、キャッシングが、例えばキャッシングエンジン１１０がアプリに（例えば、ローカルプロクシサーバ１３０の上位）直接埋め込まれることにより、１つのインスタンスで既に実行されているとき、キャッシングはダウンストリームインスタンスに対して、例えば、アプリからのキャッシュミスのプロクシ探索が二重探索オーバーヘッドを回避するためにディスエーブルにされるプロクシサーバ１３０でディスエーブルにされ得る。例えば、それ自体がキャッシングエンジン１１０に埋め込まれているアプリなどによってキャッシングエンジン１１０の１つのインスタンスで既に処理されている要求にヘッダを追加することができ、したがって、これらの要求に関する冗長キャッシュ処理オーバーヘッドを回避するために、キャッシングエンジン１１０の他のインスタンスに、例えばプロクシサーバ１３０で警報を出す。

図１は、主としてモバイル装置のアーキテクチャ１００を対象としているが、動的キャッシュ割当およびネットワーク管理は、モバイル装置１００の１つまたは複数のプロセッサ上で走るように構成されたソフトウェアコンポーネントなどの他のコンポーネントを伴うこともできる。図２は、本発明の一実施形態による動的キャッシュ割当およびネットワーク管理の実施での使用に適したデータセット例である。

図２において、アプリまたはウェブサイトの１つまたは複数のテーブル２６０をスマートフォン１００に構築するまたはその他の方法で利用できるようにすることができる。これらのテーブル２６０は、例えば、上位のグローバルウェブサイトまたはアプリを含むことができる。この種のテーブル２６０は、どのアプリケーションをキャッシュすべきか、および各アプリケーションのキャッシングにどのくらいのスペースを割り当てるべきかについて、キャッシングエンジン１１０にガイダンスを提供することができる。例えば、テーブル２６０は、多くのモバイル装置のネットワーク使用量分析から構築されて、キャッシングから最も恩恵を受ける広く用いられているアプリまたは頻繁にアクセスされるウェブサイトを識別することができる。これは、次いで特定のユーザまたはモバイル装置１００に合わせてカスタマイズされ得る動的キャッシュ割当およびネットワーク管理に適所にデフォルト規則を定めるのに役立つ。

例えば、多くのユーザは、上位グローバルランキングテーブル２６０内にない少数のアプリまたはウェブサイトに対して有意な活動を行う。したがって、本発明の１つまたは複数の実施形態では、キャッシュの自動的な追加／削除を容易にするために、帯域幅追跡テーブル２７０、往復追跡テーブル２８０、反復活動追跡テーブル２９０などの１つまたは複数の動的キャッシュ割当テーブルが提供される。これらの追跡テーブルは、様々なキャッシングポリシーを用いて動的キャッシュ割当を可能にする。これは、例えば、それぞれの個々のユーザに対して理想的またはほぼ理想的な専用キャッシュセットを自動的に構成することを可能にすることができる。例として、これは、個々のユーザの活動（ユーザの最も活動的なサイトなど）が互いに異なるか経時的に変化するかのどちらかのときに最適化をイネーブルにすることができる。

追跡テーブルは、例えば、どのアプリケーションまたはウェブサイトをキャッシュすべきか、およびキャッシュされる各アプリまたはウェブサイトにどのくらいのスペースを割り当てるべきかを含む、多面的なキャッシュ割当の動的決定を可能にすることができる。どのキャッシングポリシー（例えば、どの追跡テーブル）を使用すべきかの選択は、どのポリシーが特定のアプリまたは時間に最も効率的であるように見えるか、などの因子に応じて、アプリごとにまたは時々変わることがある。

一実施形態では、帯域幅追跡テーブル２７０は、総転送バイト数ならびにキャッシュ可能バイト（例えば、特定のウェブサイトからＧＥＴ方法によってアクセスされるＨＴＴＰ応答データなど、キャッシュされることができるバイト）を表すかかるバイトの数の両方のための集約カウンタ（ａｇｇｒｅｇａｔｅ ｃｏｕｎｔｅｒｓ）を提供する。集約カウンタは、ウェブサイトやアプリなど（または説明を簡便にするために、単に「サイト」）で分類することができる。この種の帯域幅追跡テーブル２７０は、ネットワーク負荷がどのようにして様々なサイト全体に分散されるのか、ならびにその負荷のどのくらいの比率がキャッシングから恩恵を受けることができるのか、の良い分類を提供することができる。

一実施形態では、往復追跡テーブル２８０は、総要求数ならびにキャッシュ可能要求（例えば、特定のウェブサイトからデータをダウンロードするための要求などの、キャッシュすることができる要求）を表すかかる要求の数の両方のための集約カウンタを提供する。カウンタは、帯域幅追跡テーブル２７０と同様にサイトで分類することができる。この種の往復追跡テーブル２８０は、総ネットワーク待ち時間がどのようにして様々なサイト全体に分散されるのか、または様々な応答のためのサイズ、特に比較的少ないバイトが転送されるサイトのためのサイズの分散、ならびにその待ち時間のどのくらいの比率またはその応答の数がキャッシングから恩恵を受けることができるのか、の良い分類を提供することができる。

一実施形態では、反復追跡テーブル２９０は、転送されるバイトや行われる要求などによって反復活動を追跡するための集約カウンタを提供する。反復活動は、例えば、転送されるバイトまたは転送された同一データに対して行われる要求または前に行われた同一要求を表すことができる。したがって、キャッシュ可能バイトまたは要求は、総帯域幅または要求数のどのくらいの比率がキャッシングに望ましいかの指標を与えるのと同様に、反復のバイトまたは要求は、総帯域幅または要求数のどのくらいの比率がキャッシングから実際に恩恵を受けることになるのかの指標を与える。反復活動追跡はさらに、高帯域幅を有するサイトを識別するが、反復活動（ストリーミングビデオサイトなど）をほとんどまたは全く識別しない。

したがって、反復活動はサイトでキャッシュ割当を決定するための有用な統計を表すが、反復活動は帯域幅または往復よりも追跡するのが困難である。これは、反復活動が以前の行われた要求および戻されたデータに依存するためであるが、帯域幅および往復のカウンタは以前の要求とは無関係に集約することができる。したがって、反復活動を追跡するためのこの「学習期間」は追跡に複雑さを加える（例えば、同一データに対する将来の反復要求を識別することができるように、どの要求が行われているのかを追跡するための時間および記憶）。

例えば、反復活動を追跡することは、以前に行われた要求およびそれらの要求の応答に関する詳細（および／または要求および要求の応答を表す情報、例えばサブセットまたはハッシュ値）の要求テーブル２９５を維持することを伴うことができる。さらに、この複雑さは、以前の要求の数および各要求について保存される情報の量（例えば、要求テーブル２９５のサイズ）と共に増し、このことは、特定の実施形態では、反復活動を検出するために維持され得る以前の要求の数に制限を課す。恩恵は同等に報いのあるものかもしれないが、反復活動の場合、達成可能なキャッシュヒット率（例えば、キャッシュからサービスを受けることができる要求またはバイトの百分率）の分かりやすい兆候を与えることができる。

図３は、本発明の一実施形態による反復活動を追跡する方法例である。本明細書で開示されるこのおよびその他の方法は、例えば、マイクロプロセッサなどのプロセッサ（またはその他の計算装置）によって実行されるべき一連のコンピュータ命令として実施することができる。反復活動追跡の複雑さの問題に対処するために、図３の方法のステップ３１０で、すべてのサイトが、例えば、転送されるバイトおよび行われる要求（全部のかつキャッシュ可能バイト／要求で分類される）で第１の期間Ｔ１にわたって追跡される。

これらのカウントから、ステップ３２０で、上位サイト（Ｔ１上位サイト）が識別される（例えば、上位サイトは、最も多くのキャッシュ可能要求および／または最も多くのキャッシュ可能バイトを第１の期間Ｔ１にわたって転送される）。したがって、Ｔ１上位サイトは、キャッシングから最も恩恵を受けやすいように見えるサイトセットである。Ｔ１は、ユーザが積極的に使用しているかもしれないサイトの大部分または全部が得られるほど長く選択されるべきである。一実施形態では、Ｔ１は、すべてのサイトがキャッシュ可能な要求およびバイトに対して永久に追跡されるように無限とすることができる。別の実施形態では、Ｔ１は、Ｔ１上位サイトのランキングがユーザによる現在の活動をより良く反映するように古い活動が落とされる／実行されるスライディングタイムウィンドウを表すことができる。

ステップ３３０で、個々の要求または他のパラメータ（例えば、探訪されるＵＲＬ、送信されるパラメータまたはヘッダ、戻されるデータ）が、これらのＴ１上位サイトに対して第２の期間Ｔ２にわたって追跡される。前述のように、反復追跡は時間および記憶集約的とすることができる。したがって、反復活動に対して追跡されるサイトが多いほど、この追跡を行うのに費やされる時間が長いほど、それに追跡されている各サイに対して追跡することができる要求の数が多いほど、要求追跡の精度を損なうことになる。したがって、反復活動に対して多過ぎるサイトを同時に追跡すると非生産的になる可能性があり、したがって図３の方法では、Ｔ１上位サイトだけが反復活動に対してＴ２の間に追跡される。原理的説明は、高反復活動をするがＴ１上位サイトにないサイトでも、Ｔ２の間に反復追跡を行う価値のある総キャッシングに十分には寄与をしないことである。これらの要求から、ステップ３４０で、第２の期間Ｔ２にわたって同一データにアクセスしているように見える（例えば、同じパラメータまたは応答を有する）要求が識別される。

ステップ３５０で、第２の期間Ｔ２にわたる反復要求は、転送されるバイトと行われる要求の両方によってサイト（Ｔ１上位サイト）で集約される。これらのカウントから、ステップ３６０で、第２の期間Ｔ２にわたる反復活動による上位サイト（Ｔ２上位サイト）が識別される（例えば、Ｔ１上位サイトは、同じデータに対して最も多くの反復要求を行い、かつ／または反復された要求に対して最も多くのバイトを転送する）。したがって、図３の方法は、以下の２段階手法を採用している。すなわち、キャッシングから最も恩恵を受けやすいサイトを識別する、すなわち第１の期間Ｔ１にわたって最も活動的なサイト（例えば、転送されるほとんどのデータおよび行われる要求）を識別し（Ｔ１上位サイト）、次いで、最も活動的なサイトから第２の期間Ｔ２にわたってほとんどの反復活動（例えば、反復要求から転送されるほとんどの反復要求またはほとんどのデータ）を有するサイトを選定する（Ｔ２上位サイト）。

Ｔ２は、十分な反復活動がＴ１上位サイトの間で追跡されるくらい十分長くなるように選択されるべきである。しかしながら、前述したように、反復活動は、全部のまたはキャッシュ可能バイトまたは要求が追跡することになるほど追跡するのは容易ではない。各要求に対してかなりの量の情報を追跡することに関する懸念があるだけでなく、各要求に関してまさにどの情報を追跡すべきかをも反復活動を追跡するときに考慮されなければならない。したがって、Ｔ２はさらに、様々な理由で、例えば、それがユーザの現在の活動（経時的に変わることがある）を反映させるようにするとともに、繰り返されていない（またはもはや繰り返されない）古い要求を追跡することの記憶／計算オーバーヘッドを回避するには長過ぎないように選択されるべきである。

より詳細には、反復活動は、要求自体の様々なコンテンツを用いて一意に識別することができる。ほとんどのＨＴＴＰ要求は、例えば、その要求のＵＲＬとその要求のヘッダまたは本体の１つまたは複数のコンポーネントとに基づいて容易に識別することができる。したがって、一実施形態では、第１の手法は、要求または要求コンポーネントのハッシュをベースとすることができる「ルックアップキー」を計算することである。ルックアップキーは、有効となるために一意であるべきである（例えば、当業者には明らかなように、この目標を達成するために使用することができる種々の暗号学的安全なハッシュ関数がある）。

どのコンポーネントを使用すべきかを選定するのに注意を払うべきであるが、いくつか（例えば、ＵＲＬにクエリ文字列引数として支持されるタイムスタンプ（ｔｉｍｅｓｔａｍｐ）またはビューカウント（ｖｉｅｗ ｃｏｕｎｔ））では、応答に影響を及ぼすことはなく、要求を一意のものに見せるが、反復を一意のものには見せないことがある。これは、これらの無関係なコンポーネントが同じ応答に対する複数の要求の間で変わるときに、同一応答のキャッシュルックアップミスおよび冗長コピーを引き起こす可能性がある。例えば、これらの無関係なコンポーネントは、例えば、ソフトウェアパッケージかユーザのどちらかによって指定されるまたは管理者によって中央管理される構成設定に指定される規則により、キャッシュルックアップからフィルタをかけることができる。

どのパラメータが応答に影響を及ぼすかの決定は、どの応答が実際に全く同じであるかを比較するために、応答を追跡することも伴うことができる。要求と同様に、応答は、セキュアハッシュ関数が様々な応答に対して同じハッシュ値を決して戻しそうにないので、スペースを節約するためにハッシュされるなど、様々な方法で追跡することもできる。

これらの検討を考慮して、図４〜図５および図６〜図７は、本発明の実施形態による反復活動を検出する方法の例である。前述したように、反復要求を検出することは、２つの別々の比較過程の対話、すなわち、要求を比較することに対して対応する応答を比較することを含むことができる。その場合、手法は、どの比較が行われるかまたはどの比較が最初に実行されるかで異なることがある。

図４〜図５の反復活動を検出する方法では、要求が主要な基礎としての比較である。すなわち、要求テーブルは要求によってインデックス化される（要求パラメータのハッシュ値など）。ステップ４１０で、要求コンポーネントの一部または全部、例えば、（ＨＴＴＰ要求の場合）ＵＲＩ／ＵＲＬ、ヘッダ、本体などを検討することにより要求が一意に識別される。これは無限長の文字列を生成し得るので、ステップ４２０で、選択済みコンポーネントは、十分に一意のルックアップキーを生成するために適切なハッシング関数によってハッシュされる。他の実施形態では、サーバ提供の一意の識別子（例えば、ＵＲＬのコンテンツを一意に識別するためのＨＴＴＰエンティティタグまたはその他のタグなどのクッキーまたはＥＴａｇ（エンティティタグ））がハッシュ値の代わりに使用されてもよい。ステップ４３０で、エントリは、エントリのルックアップキーによって要求テーブルに追加される。エントリが既に存在する（例えば、同じルックアップキーが既にある）場合、ステップ４４０で、適切な反復要求カウンタがインクリメントされる（反復バイト数や反復要求数など）。

随意に、いくつかの実施形態などでは、類似の要求が、それらの要求を同じ応答にマッチさせるために統合されてもよく、これは、キャッシュ利用、ならびに他の恩恵（例えばスペースを節約する）を改善する。しかしながら、この種の統合は、計算コストが高い実行すべき操作であり得る。したがって、ステップ４５０で、類似要求を統合するかどうかの決定は、例えば構成設定または何らかの発見的問題解決法に基づいてなされるまたはその他の方法で決定される（例えば、多数の異なるが類似している要求が見られる）。類似要求が統合されていない場合、処理は終了する。そうでない場合、処理は図５およびステップ５１０において継続し、そこで、要求への応答は、実際に同等である異なる要求コンポーネントを有する要求を、それらの要求が同じ応答に対応するという点で識別するために得られる。応答は要求テーブルに保存されるかもしれないが、応答は大きいことがあり、これは要求テーブルのサイズを損なう可能性がある。さらに、他の応答との比較は、比較に完全な応答が使用される場合にさらに時間がかかることがある。したがって、応答は、適切なハッシュ関数によって十分に一意の値にハッシュされ、その値が要求テーブルに保存され得る。

ステップ５２０で、ステップ５２０は応答が見られたときに直ちに実行されてもよく、または後で定期的に実行されてもよく、ハッシュ済み応答値は互いに比較されてもよい。応答ハッシュ値のいずれかが他の要求ハッシュ値と同じであれば、ステップ５３０で、対応する要求コンポーネントを比較して、応答に影響を及ぼさない要求コンポーネントを識別し、それによってどの要求コンポーネントをフィルタ除去する（例えば、削除する、無視する）ことができるかを決定することができ、したがって同等の要求を同じルックアップキーで識別することができる。さらに、対応する要求テーブルエントリは共通コンポーネントおよび応答ハッシュ値で統合することができる（場合により、共通エントリ用のプロセスで新たなルックアップキーを入手し、以前のエントリを削除する）。このようにして、システムは、どの要求コンポーネントが応答に影響を及ぼし、どの要求コンポーネントを無視することができるかを学習することができる。

図４〜図５の反復活動検出方法とは対照的に、図６〜図７の反復活動検出方法では、応答が主要な基礎としての比較である。すなわち、要求テーブルは応答によってインデックス化される（応答のハッシュ値など）。ステップ６１０で、応答は次の要求に対して得られる。ステップ６２０で、応答は適切なハッシュ関数によってハッシュされて十分に一意のルックアップキーを生成する。ステップ６３０で、要求は、ルックアップキーを用いてその要求に対応する応答から要求テーブルに保存される。これがこのルックアップキーを有する最初のエントリである（例えば、応答は前に追跡されたことがない）場合、処理は次の要求で再開する（ステップ６１０）。

そうでない場合は、ルックアップキーが既に存在し、したがってステップ６５０で、反復要求カウンタがインクリメントされる（反復バイト数や反復要求数など）。随意に、いくつかの実施形態などでは、類似の要求が、それらの要求を同じ応答にマッチさせるために統合されてもよく、これは、キャッシュ利用、ならびに他の恩恵（例えばスペースを節約する）を改善する。しかしながら、この種の統合は、計算コストが高い実行すべき操作であり得る。したがって、図７へ進み、ステップ７１０で、類似要求を統合するかどうかの決定は、例えば構成設定または何らかの発見的問題解決法に基づいてなされるまたはその他の方法で決定される（例えば、多数の異なるが類似している要求が見られる）。そうである場合、処理はステップ７２０へ進み、そこで、応答は同じルックアップキーを有する以前の要求を見つけるために使用され、それらの要求は、（既存の保存済み要求が要求テーブル内に同じルックアップキーを有するのを使用して）比較される。ステップ７３０で、同じ要求の間の共通要求コンポーネントが統合され、応答に影響を及ぼすようには見えない要求コンポーネントはフィルタ除去する（例えば、削除する、無視する）ことができる。

図４〜図７のいずれの方法でも、システムは反復活動を追跡することができ、どの要求コンポーネントがキャッシュ応答に影響を及ぼすために重要であるかを経時的に学習することもでき、これによりシステムは動的キャッシュ割当をより良く管理することができる。

反復活動を追跡する目標は、上位サイトの最新のビューを反復活動で維持することである。ただし、「最新の」は、ユーザがこれらのサイト上のコンテンツを近い将来に再探訪する可能性が高いのを反映することを意味する。これは、ランキングは、ユーザがアクセスしているかもしれない「上位」アプリまたはサイトへの変更に適合する必要があることを意味する。このことを考慮して、反復活動が行われているかもしれない何種類かのサイトがある。これらのサイトとしては、例えば、ワークアプリ／サイト（ＳｈａｒｅＰｏｉｎｔ、企業イントラネット、ＨＲ（人材）など）、カジュアル／お気に入りサイト（ＷＳＪ（ウォールストリートジャーナル）、バースト的サイト（ＮＣＡＡ．ｃｏｍ、Ｏｌｙｍｐｉｃｓ．ｏｒｇなど）などがある。

ワークアプリ／サイトは、例えば、多分お気に入りサイトより少ない頻度で（例えば一日おきに）短期間に、ただし長期にわたって絶えずアクセスされるものとして特徴づけることができる。この種のサイトは、まれに変わる大きい静的コンテンツ（例えば、ＰＰＴ（パワーポイントプレゼンテーション（商標）、映像など）を含んでいることが多い。この種のサイトのキャッシング目標は、キャッシュされたコンテンツを何日もの間アクセスされなくても維持すること、とすることができる。というのは、キャッシュされたコンテンツは、近い将来に再びアクセスされる見込みであるからである。この種のサイトに対する可能なキャッシング手法は、これらのサイトを総反復キャッシュ済みバイト数でランク付けすることである。

カジュアルサイトまたはお気に入りサイトは、例えば、数日間または最長１週間で隔てられた探訪で定期的に探訪されるものとして特徴づけることができる。これらのサイトは、頻繁に変わる大きい静的コンテンツ（例えば、画像、映像など）を含んでいることが多い。この種のサイトのキャッシング目標は、キャッシュされるサイトのコンテンツを維持しようとすること、とすることができるが、これらのサイトは、それほど頻繁には変わらない静的コンテンツを有するサイトほど有用ではない。この場合、可能なキャッシング手法は総反復要求数を考慮に入れることができる。

バースト的サイトは、例えば、ＮＣＡＡ．ｃｏｍのように、ユーザが定期的に、ただし比較的短い期間中にのみ探訪するサイトであるものとして特徴づけることができ、ＮＣＡＡ．ｃｏｍは、ちょうど３月／４月中（例えば、全米大学競技協会（ＮＣＡＡ）ベースボールトーナメントと重なる）の上位２０サイトである。この種のサイトは、ユーザのカジュアル／お気に入りサイトと同様に、複数日にわたって繰り返し行われる多数のアクセスを有することができる。この種のサイトのキャッシング目標は、この高活動期間（能動的使用の１日または２日以内）の開始時にそれらのサイトに対して迅速にキャッシュすることをイネーブルにし、次いで、高活動期間の最後にそれらのサイトに対して同様に迅速にキャッシュすることをディスエーブルにすること、とすることができる。この場合、可能なキャッシング手法は、マルチデイウィンドウをまたぐ高活動を検出すること、とすることができる。

この反復活動追跡をサポートする一方法は、ドメインまたはアプリに関する活動を時間フレームにわたって測定することであり、この場合、時間フレームは設定可能または動的とすることができ、かつ／または、測定は活動がどのくらい最近に行われたかに応じて活動の重さを計ることができる。例えば、検討される時間フレームは、移動平均を与えるために最近のサブセットに制限することができ、次いで、この値は、その値が経時的に変化するにつれて、専用キャッシュの生成、削除、またはサイジングを引き起こすことができる。より具体的には、閾値がこの平均を得るために設定され、固定される／設定可能であるか動的／自動調整式であるかのどちらかとすることができ、閾値を超えると、キャッシングを自動的にイネーブルにすることが可能になる。これは、累加平均、単純移動平均（ＳＭＡ）、加重移動平均（ＷＭＡ）などの様々な平均を比較することによって説明することができる。

累加平均は、すべての履歴活動にわたる非加重平均を表す。この種の平均は、かかるサイトが数日間アクセスされていないかもしれないが、長期間にわたる持続的活動のために上位累加平均に現れるという点で、古いお気に入りを「覚えている」。他方、もはやアクセスされていない古いサイトを忘れるには長時間（場合により数週間）かかることがある。したがって、ワークアプリ／サイト（上述）は、累加平均を使用することから最も恩恵を受けることができる（ワークアプリ／サイトが経時的に絶えずアクセスされるため）が、バースト的サイトは、サイトへの頻繁なアクセスが注目されるようになるまで長い時間がかかるので、累加平均の特徴があまりない、他方、この種のサイトは、サイトがもはやアクセスされていない状態のずっと後で高累加平均が現れ続けることがある。

単純移動平均（ＳＭＡ）は、最後のＮ日間（数週間などの適度に短い期間）の活動にわたる非加重移動平均を表す。ＳＭＡは、累加平均より速く新しいお気に入りに適応することができる（最近のアクセスをおおい隠す履歴データがずっと少ないため）が、新しいお気に入りサイトを検出するためにまだ数日間かかることがある。したがって、バースト的サイトは、ＳＭＡでより迅速に検出されより迅速に忘れられるので、累加平均よりもＳＭＡでより良く機能する。

加重移動平均（ＷＭＡ）は、ＷＭＡの名前が含意しているように、ＷＭＡが最後のＮ日間の活動にわたる加重移動平均を表すことを除けば、ＳＭＡに類似している。重みは、平均を、昔の活動（例えば、Ｎ日前により近い活動）よりも最近の活動に斜めにする。線形重み付けや指数重み付けなど、様々な重み付けオプションがある。線形重み付けでは、アクセスの寄与は経時的に線形的に減少し、したがって最近のアクセスは１００％の重みを付けられてもよく、重み付け百分率が２０日間にわたって１日当たり５％で線形に減少すると、この時点でアクセスはもはや追跡されない。

他方、指数重み付けでは、アクセスの寄与は経時的に指数的に、例えば２日ごとに５０％減少する。すなわち、最近のアクセスは１００％の重みを付けられ、２日前のアクセスは５０％の重みを付けられ、４日前のアクセスは２５％（すなわち５０％の半分）の重みを付けられ、６日前のアクセスは１２．５％（すなわち２５％の半分）の重みを付けられる、などであり、２０日前のアクセスが０．１％の重みを付けられると、寄与は反復活動追跡に影響を及ぼすのに十分でありそうにないので、この時点でアクセスは安全に無視される（例えば０％として処理される）。

バースト的サイトは、ＷＭＡで、特に指数重み付けで有意に良く機能する。これは、指数重み付けが、上述した平均法の（新しい上位サイトについて学習する）最短「ウォームアップ」期間を有するためである。しかしながら、指数重み付けは、古いお気に入りをあまりにも速く（例えば、重み付けに応じて１日または２日以内に）廃棄することができる。

図８は、本発明の一実施形態によるキャッシュアクセス重み付けおよび活動化／非活動化の例を示す２つのグラフである。図８Ａでは、線８１０は、特定の（キャッシュ可能な）サイトへのアクセス（バイト数または要求数、ｙ軸線）を経時的に（ｘ軸線）表している。これらは瞬時アクセスである。対照的に、線８２０は、平均速度を上述した平均アクセス速度のうちの１つなどで経時的に表している。最後に、線８３０は、特定サイトのキャッシングをイネーブル／ディスエーブルにするための閾値を表している。平均アクセス速度８２０が閾値８３０の上を行くと、サイトはキャッシングに適格となり、平均アクセス速度８２０が閾値８３０の下を行くと、サイトはキャッシングをディスエーブルにするのに適格となる。

図８Ａでは、初期活動はキャッシュの動的使用可能性を引き起こさず、継続する反復活動は平均を押し上げてキャッシングをイネーブルにする。より詳細には、図８Ａの左側に見られるように、閾値８３０の上のアクセス速度８１０の瞬時スパイクはキャッシングを活動的にしない（平均アクセス速度８２０は閾値８３０の下のままであるため）。しかしながら、図８Ａの右側に見られるように、閾値８３０の上の持続的アクセス速度８１０はキャッシングを活動的にする（平均アクセス速度８２０は閾値８３０に「追いつき」始め、閾値８３０の上を行くため）。

対照的に、図８Ｂは図８Ａと同じ３本の線を使用していて、状況だけが逆になっている。図８Ｂでは、初期不活動はキャッシュの即時無効化を引き起こさず、継続する反復不活動は平均を押し下げて最終的にキャッシングをディスエーブルにする。より詳細には、図８Ｂでは、キャッシングはサイトに対して高い平均アクセス速度（閾値のかなり上）で最初にイネーブルにされる。しかしながら、サイトへのアクセス速度は経時的に低下し始めている。実際、適時に中間点を過ぎた所で、アクセス速度は閾値を下回るが、くぼみは、平均アクセス速度を閾値未満に下落させキャッシングをディスエーブルにするほど長くはない。それにもかかわらず、アクセス速度が図８Ｂで下がり続けると、最終的には平均アクセス速度は閾値を下回り、サイトに対するキャッシングをディスエーブルにすることになる。

反復活動を追跡するには特定の要求を監視する必要があるかもしれず、実行されるすべてのネットワーク要求に対してそうするのは費用がかかるまたはひどく高いことがある。追跡は、上位サイト／サーバまたは上位アプリに対する反復活動を選択的に追跡するために最適化することができ、その場合、普遍的目標は、追跡に価値のあるものにするのに十分な活動を有するサイト／アプリを識別して、そのサイト／アプリが後にイネーブルにされるべきキャッシングを動的に引き起こすことができるようにすることである。十分なキャッシュ可能活動（例えば、要求またはバイト）があるかどうかを識別するなど、「上位」サイトまたはアプリを決定するための様々な手法がある。

ヘビーユーザの場合、計算のための総オーバーヘッドおよび反復活動を追跡するための保存を制限するために、合計でいくつのサイトまたはアプリが追跡されているのかを制限することが望ましいこともある。例えば、総キャッシュ可能活動に関して、上位Ｘサイトに対する反復活動の追跡をイネーブルにすることだけが望ましいことがある。反復活動追跡のために時間フレームを制限するのと同様の理由で、上位サイト／アプリを識別するために検討されている活動の時間フレームを制限することが望ましいこともある。例えば、古い活動の上に最近の活動を検討するまたは重みを付け過ぎることだけが望ましいことがある。上位サイト／アプリに対して追跡する反復活動をイネーブルにする前に追加条件を検討することが望ましいこともある。例えば、サイト／アプリが、設定可能または動的とすることができる一定の閾値を超えた（または超えない）場合、反復活動追跡はイネーブルにすることができる（またはイネーブルにすることができない）。

以下の手法は、設定可能閾値または動的閾値とともに、サイトまたはアプリが反復活動の追跡を正当化するのに十分な活動を有しているかどうかを要求の数でまたは応答バイトで決定するために活用するまたは組み合わせることができる。「要求の数で」は、各サイトをそのサイトへのキャッシュ可能要求の総数でランク付けすることを意味する。この活動は、特定の時間フレーム（例えば、最後のＸ日の間のキャッシュ可能要求の数）にわたって行うことができる。これは、サイトをかなりの待ち時間で識別するのに役立つことができるが、待ち時間は、例えば、スペクトル制限容量を有するセルラーネットワークまたはその他の無線ネットワークのための帯域幅の節約についての二次的検討とすることができる。

対照的に、「応答バイトで」は、各サイトをそのサイトからのキャッシュ可能な応答バイトでランク付けすることを意味する。やはり、この活動は、特定の時間フレーム（例えば、最後のＸ日の間の総キャッシュ可能応答バイト）にわたって行うことができる。これは、帯域幅を最も消費するサイトを識別するのに役立つことができるが、それは、たまの（または１回限りの）大量のダウンロードによって斜めにすることができる。別の実施検討として、オーバーヘッドを最小限に抑えかつ不変の再ランキングを回避するのを助けるために、上位サイト／アプリを計算することがより賢明であるかもしれない。

モバイル装置上に極めて限定され得る記憶スペースを、記憶スペースの効率的な使用を最大限にするためにサイトまたはアプリに知的に割り当てることができるように、活動に基づいてキャッシュのサイズを変更することが有利であろう。これは、最近行われた反復活動の量、キャッシュヒット率がキャッシュサイズを増大することによって向上するかどうか、など、サイト／アプリのキャッシュ可能性に関する情報を収集し活用することにより可能である。例えば、総キャッシュ可能バイトでまたは反復キャッシュ可能バイトで、キャッシュサイズの変更を決定する多くの可能な手法がある。

総キャッシュ可能バイトの場合、キャッシュサイズは、どのくらいのキャッシュ可能コンテンツ（例えば、最後のＸ日の間に見られるキャッシュ可能バイト）が最近見られてきたかに基づいて制限される。これは、過大なサイズが選択された場合に古いデータを長い間放置しておくことができる単純なキャッシュサイズ限度（固定サイズキャッシュなど）よりも効率が良い。必要なバイトの数は比較的簡単に計算することができる。というのは、この技法は、２回以上はアクセスされないアイテムのキャッシングを除外する必要がないからである。しかしながら、この技法では、１回しかアクセスされないアイテムにキャッシュスペースを使用することができる。

対照的に、反復キャッシュ可能バイトの場合、キャッシュサイズは、どのくらいのキャッシュ可能コンテンツが２回以上要求されてきたか（例えば、最後のＸ日の間に複数回アクセスされるバイト）に基づいて制限される。キャッシュサイズは、２回以上アクセスされるキャッシュ可能アイテムのより小さいキャッシュサイズ限度に対応しているので、より効率的なキャッシュサイズとすることができる。しかしながら、この技法は、キャッシングが繰り返しアクセスされないアイテムを除外して、繰り返しアクセスされるアイテムのためにスペースが確保されるようにすることを条件とすることができる。

より詳細には、反復活動だけに基づいてキャッシュサイズを設定するには、繰り返されない活動がキャッシュスペースを得るために競合することのないように反復活動だけをキャッシュする必要があるかもしれない。これは、キャッシュに入るべきまたは入るべきでないアイテムを識別する能力を必要とすることができる。この識別をするための２つの可能な手法がホワイトリストおよびブラックリストである。ホワイトリストは、キャッシュされるべきアイテムを識別することによりアイテムのキャッシングを動的にイネーブルにすることによって働く。キャッシングをイネーブルにすることは、明示的ＵＲＬや正規表現パターンなどの要求に基づくことができる。この技法は高効率である。というのは、この技法は、それを必要とすることが分かっているアイテムだけにキャッシュスペースを割り当てるからである。しかしながら、これは遅延時間を追加し、したがって初期要求は逃した機会である。

対照的に、ブラックリストは、キャッシュされるべきでないアイテムを識別することによりアイテムのキャッシングを動的にディスエーブルにすることによって働く。キャッシングは、すべてのものに対してイネーブルにされ、次いで二度と見られない（例えば、再び見られたことがない、または最後のＸ日以内に見られない）アイテムに対してディスエーブルにすることから始めることができる。この技法は、可能なキャッシュ節約を最大限にするためにキャッシングを即座にイネーブルにする。他方、この技法は、二度と要求されないかもしれないアイテムのキャッシング（および例えば、そのキャッシングを管理する記憶装置／ＣＰＵオーバーヘッド）もイネーブルにする。

効率的なキャッシュ記憶装置使用法の関連する懸念が、重複キャッシング（例えば、プロクシサーバ内の中央キャッシュとアプリ自体の中の埋込みキャッシュの両方でのキャッシング）の可能性である。キャッシングが、プロクシサーバ１３０の外部／ダウンストリームキャッシュなどの１つのキャッシュ内のアイテムに対してイネーブルにされる場合、アプリのキャッシュ内の「アップストリーム」などの他のキャッシュ内でのキャッシングをディスエーブルにして、アイテムのキャッシュされたコピーが１つしかないようにすることが望ましいことがある。これは、アイテムをアップストリームで（例えば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダを通じて）キャッシュすることができないことを示すようにＨＴＴＰ応答ヘッダを設定することなどによってサポートすることができる様々な方法がある。

図９〜図１３は、本発明の一実施形態によるキャッシングスペースを動的に割り当てる（動的キャッシュ割当）方法例を示す。図９〜図１３では、特定のステップが特定の順序で行われるものとして示されている。しかしながら、本発明は必ずしもその順序に限定されるものではなく、他の実施形態では、上記ステップは、当業者には明らかなように、同じまたは類似のタスクを達成するために異なる順序で行われてもよい（または場合により省略されてもよい）。加えて、図９〜図１３におけるステップの多くは、いくぶん過度に単純化した形で提示され、以下でさらに論じるように、より多くのチェックまたは検討で実施されてもよく、当業者には明らかであろう。

図９〜図１３の方法は、限られた記憶スペースを有する装置上でのディスク（または他の不揮発性記憶装置）使用量を改善または最適化する方法として、キャッシングスペースを（例えば、別々のキャッシュアカウント（またはキャッシュ）の中へ、それぞれ潜在的にそれら自体のキャッシングポリシーで）動的に割り当てるために使用することができる。この場合、特定のキャッシュアカウントおよび／またはキャッシングポリシーの有効性または値は、１つの数（または小さい数群）として要約することができ、この数は１つまたは複数の他の値から導出することができる。そのような数の１つが、キャッシュから供給されるバイトの数（すなわち、セーブされるネットワークトラフィック）とアプリに供給されるバイトの総数の比である。そのような数のもう１つが、キャッシュから供給される要求の数（すなわち、回避される往復）とアプリに供給される応答の数の比である。例えば、セーブされるネットワークバイトまたは往復の比は、所与のタイムウィンドウにアプリをキャッシュする有効性を表すことができる。

図９〜図１３では、「使用サイズ（Ｕｓｅｄ Ｓｉｚｅ）」は、キャッシュアカウントによって使用されるディスク上のバイトの数を意味し、「割当サイズ（Ａｌｌｏｃａｔｅｄ Ｓｉｚｅ）」は、アカウントに書き込むことができるバイトの数を意味する。使用サイズが割当サイズを超えると、ファイル（またはアイテム）は、キャッシュ内の値アイテムをランク付けするための１つまたは複数のポリシーに従ってキャッシュから削除される。例えば、キャッシュされたアイテムを、そのアイテムがキャッシュから供給された頻度に基づいてより高く評価するポリシーは、使用サイズが割当サイズを超えるとキャッシュされたアイテムを削除するために、最も長く使われていないアイテム（最長時間未使用のリストに維持される）のランク付けと組み合わせることができる。使用サイズと割当サイズは共に、利用可能なキャッシュ記憶スペース、現在のキャッシュ使用量、キャッシングポリシーなどのファクタに応じて特定のタイムウィンドウの間に変わることができる。

図９〜図１３を続けると、「一意のバイト（Ｕｎｉｑｕｅ Ｂｙｔｅｓ）」は、タイムウィンドウの間に見られるすべての一意の要求のためのバイトの数を意味し、「供給バイト（Ｂｙｔｅｓ Ｓｅｒｖｅｄ）」は、キャッシュから（例えば、特定の時間フレーム以内に）供給されるバイトの数を意味し、「最大サイズ（Ｍａｘ Ｓｉｚｅ）」は、割当サイズがあり得る最大量を意味し、「最小サイズ（Ｍｉｎ Ｓｉｚｅ）」は、割当サイズがあり得る最小量を意味する。加えて、「総使用サイズ（Ｔｏｔａｌ Ｕｓｅｄ Ｓｉｚｅ）」、「総割当サイズ（Ｔｏｔａｌ Ａｌｌｏｃａｔｅｄ Ｓｉｚｅ）」などの「総（Ｔｏｔａｌ）」の使用は、すべてのキャッシュアカウントのための対応サイズの合計を意味する。

例えば、最大サイズは、デフォルト値（５０メガバイト（ＭＢ）など）、現在の使用サイズプラス若干の百分率（１０％など）、一意のバイト、最小または無視できる程の増分値を有すると分かっているサイズを超えるスペースを割り当てるのを回避するような、キャッシュアカウントの割当サイズの最大値、あるいはこれらまたはその他の可能な最大サイズの組合せ（最大など）とすることができる。同様に、最小サイズは、デフォルト値（５メガバイト（ＭＢ）など）、現在の使用サイズ、有意なキャッシング非能率を引き起こすと分かっているサイズを下回るスペースを減少させるのを回避するような、キャッシュアカウントの割当サイズの最小値、あるいはこれらまたはその他のゼロを含む可能な最小サイズとすることができる。

さらに、図９〜図１３では、「総動的キャッシュパーセント（Ｔｏｔａｌ Ｄｙｎａｍｉｃ Ｃａｃｈｅ Ｐｅｒｃｅｎｔ）」は、キャッシュに割り当てる総記憶スペースの計算に組み入れるために、空き記憶スペース（アプリ記憶装置に現在使用されていない記憶スペース）や総記憶スペースなどの別の値の百分率を意味する。この百分率は、例えば、ユーザが設定できる数、または装置もしくはオペレーティングシステムが設定できる数、管理者が設定する数、またはアルゴリズム、発見的問題解決法、もしくはポリシーに基づく動的に計算された数（例えば、ユーザが長期間にわたって空き記憶スペースを使用しない場合に増大する数）を表すことができる。同様に、「総動的キャッシュサイズ（Ｔｏｔａｌ Ｄｙｎａｍｉｃ Ｃａｃｈｅ Ｓｉｚｅ）」は、例えば、総動的キャッシュパーセントなどの上記コンポーネントから計算される、すべてのキャッシュに割り当てる総スペースの上限を意味する。したがって、総動的キャッシュサイズは、ユーザ入力や装置上で走る他のアプリなどのファクタに応じて経時的に変わることができる。しかしながら、図９〜図１３の動的キャッシュ割当の基礎となる目標は、総割当サイズを総動的キャッシュサイズと一致させることである。

したがって、総使用サイズ、総割当サイズ、および総最大サイズは、総使用サイズ≦総割当サイズ≦総最大サイズで、図９〜図１３の方法を制御する総キャッシングの３つの限度を定義する。理想ケースでは、総動的キャッシュサイズは総割当サイズに等しくすることができる。しかしながら、上記の数はキャッシング活動によって動的に変わる。したがって、総動的キャッシュサイズなどの総利用可能キャッシュ記憶レベルを説明する変数は、４つの異なる範囲のうちの１つまたは中間点（例えば、理想点または目標点）で、（１）総最大サイズより大きい、（２）総割当サイズ（排他的）と総最大サイズ（包含的）との間にある、（３）総割当サイズに等しい、（４）総使用サイズ（包含的）と総割当サイズ（排他的）との間にある、（５）総使用サイズ未満である、ものとして説明することができる。ケース（１）の処理は図９に記述され、ケース（２）の処理は図１０に記述され、ケース（４）の処理は図１１に記述され、ケース（５）の処理は図１２〜図１３に記述され、理想ケース（３）はさらなる処理を必要としない。

同様に、使用サイズ、割当サイズ、および最大サイズは、特定のキャッシュアカウントのキャッシングを制御する３つの対応する限度を定義し、各特定のキャッシュアカウントに対して同じ関係式、使用サイズ≦割当サイズ≦最大サイズを維持する（ただし、異なるキャッシュアカウントの間に必ずしも同じ値を有するわけではない）。したがって、使用サイズ、割当サイズ、および最大サイズは、異なるキャッシュアカウントの間で異なることができる。

図９〜図１３の概観として、総動的キャッシュサイズが総最大サイズより大きいとき、図９に示されているように、さらなるキャッシュアカウントを追加することができる。このキャッシュアカウントの追加は、適格性要件、例えば、いくつかの基準（例えば、見られるキャッシュ可能バイトの数および要求の数に対する最小量を超える）を満たしているドメインのためにキャッシュアカウントを追加することだけに従うものとすることができる。同様に、総動的キャッシュサイズが総割当サイズより大きい（かつ総割当サイズが総最大サイズ未満である）とき、既存のキャッシュアカウント用の割当スペースは、図１０に示されているように増大させることができる。例えば、キャッシュアカウント用の割当サイズは、そのキャッシュアカウントが最高ヒット率を有し下方へ作動することで始まって増大させることができる。

他方、総動的キャッシュサイズが総割当サイズ未満であるが、総使用サイズより大きい（または総使用サイズに等しい）場合、既存キャッシュアカウント用の割当スペースは、図１１に示されているように減少させることができる。例えば、キャッシュアカウント用の割当サイズは、そのキャッシュアカウントが最低ヒット率を有し下方へ作動することで始まって減少させることができる。加えて、総動的キャッシュサイズが総使用サイズ未満であるとき、キャッシュアカウントは、図１２〜図１３に示されているように削除する、またはキャッシュアカウントの使用スペースを減少させることができる。

これらの原理を考慮して、図９〜図１３の方法を検討する。図９では、処理が始まり、ステップ９１０で、総動的キャッシュサイズ、総最大サイズ、総割当サイズ、および総使用サイズが計算される。図９における処理の開始は、上記総サイズのうちの１つまたは複数が変わるときに自動的に、スケジュールに従って定期的に、などの１つまたは複数の異なる方法で引き起こされてもよく、または多分管理者などによって手動で開始されてもよい。いくつかの実施形態では、これらの数の一部または全図の計算は、（例えば、数のうちの１つまたは複数の任意の構成コンポーネントに変わると）連続的に行うことができ、ステップ９１０は、それらの連続的に計算された数を単に参照することを伴うことができる。ステップ９２０で、総動的キャッシュサイズは総最大サイズと比較され、総動的キャッシュサイズが総最大サイズより大きい場合、処理は、さらなるキャッシュアカウントを追加するためにステップ９３０へ進む。そうでない場合は、処理は以下に説明する図１０へ進む。

ステップ９３０で、追加すべき新キャッシュアカウントがある（例えば、追跡されているドメインが任意の必要な事前キャッシング判定基準を満たしている）場合、総動的キャッシュサイズは、総最大サイズ＋次の新キャッシュアカウントの最大サイズと比較される。総動的キャッシュサイズが総最大サイズ＋新キャッシュアカウントの最大サイズより大きい場合、新キャッシュアカウントを完全に追加するのに十分な余地があるので、処理はステップ９４０へ進む。そうでない場合は、新キャッシュアカウントがない、または新アカウントを追加するのに十分なキャッシングスペースがないので、処理は、（非割当スペースがあればこれを割り当てることを確認するために）図１０へ続く。別の実施形態では、新キャッシュアカウントは、最大サイズを保持するのに十分なキャッシングスペースがない（かつ最小サイズを保持するのに十分なキャッシングスペースがない）ときでも追加することができるが、新キャッシュアカウントの割当スペースは、総最大サイズが総動的キャッシュサイズを超えないように十分小さい数、例えば、総動的キャッシュサイズ−総最大サイズ（新キャッシュアカウントを追加する前）となるように設定される。

いくつかの実施形態では、新キャッシュアカウントが追加されると、新キャッシュアカウントは特別に表示される。これは、新キャッシュアカウントが、キャッシュヒット率などの、キャッシュ用の代表的有効性値を確立するのに十分な履歴を有していないことがあり、したがってシステムは普通ならそれらを時期尚早に削除するかもしれないからである（例えば、下記の図１２において）。例えば、（当業者には明らかなように）一定の経過時間が過ぎた後または一定のドメイン活動量が生じた後で、キャッシュ用の代表的有効性値（例えばキャッシュヒット率）を生成するのに十分な時間が経過すると、特別な表示は除去することができる。しかしながら、キャッシングスペースが極端に不足していると、特別に表示されたキャッシュアカウントでも、キャッシングスペースを空けるために削除する対象となり得る。特別な表示は、中央のもしくは設定可能なキャッシュヒット率または他のランキング値を割り当てるなど、他のキャッシュアカウントに対する一時的な人為的ランキング値の形をもたらすまたはとることができ、したがって、この新キャッシュアカウントは、高パフォーマンスの既存アカウントよりも低くランク付けしながらも、低パフォーマンスの既存アカウントよりも高くランク付けすることができる。

ステップ９４０で、新キャッシュアカウントは、最大サイズに（または、別の実施形態では、最大サイズと総動的キャッシュサイズ−総最大サイズの小さい方に）等しい割当スペースで追加される。ステップ９５０で、総最大サイズは（例えば、新たに追加されたキャッシュアカウントを考慮するために）再計算される。次いで、処理はステップ９３０に戻って、（可能なら）図１０に進む前にさらなるキャッシュアカウントを追加し続ける。

図１０では、処理は図９から続き（または、後で見られるように図１２および図１３からも続き）、ステップ１０１０で、総動的キャッシュサイズは総割当サイズと比較される。総動的キャッシュサイズが総割当サイズより大きい場合、キャッシングスペースがキャッシュアカウントに利用可能であり、したがって処理はステップ１０２０に進んで割当スペースを増大させる。そうでない場合は、処理は以下に説明する図１１へ進む。

ステップ１０２０で、総割当サイズは総最大サイズと比較され、総動的キャッシュサイズは総割当サイズと比較される。総割当サイズが総最大サイズ未満である（すなわち、その最大サイズまでのスペースを割り当てられていない少なくとも１つのキャッシュアカウントがある）かつ総動的キャッシュサイズが総割当サイズより大きい（すなわち、他の割当をキャッシュアカウントへ戻すための利用可能なキャッシングスペースがまだある）場合、処理はステップ１０３０へ進んで、どの割当スペースを増大させるかを選定する。そうでない場合は、割当スペースを増大させることができるキャッシュアカウントがない、またはキャッシュアカウントにさらなるスペースを割り当てる動的キャッシュスペースがこれ以上ない。

ステップ１０３０で、割当スペースは、パフォーマンスが最も高いキャッシュアカウント（および割当スペースが最大サイズにまだ達していないキャッシュアカウント）、例えば、最高ヒット率（キャッシュから供給されるアイテムに関する）、最高キャッシュ節約（キャッシュから供給されるバイトに関する）、最大増加変化率（ヒット率またはキャッシュ節約に関する）、またはこれらまたはその他のファクタの組合せを有するキャッシュアカウントを選定することによって増大させる。次いで、このキャッシュアカウントに対する割当スペースは、例えば最大限のサイズ、すなわち最大サイズに増大させる（または、別の実施形態では、この増大は、総動的キャッシュサイズ−総割当サイズ以下に制限される）。

選定済みキャッシュアカウントに対する最大割当キャッシュスペースの増大は、１回の操作で、または経時的に一連の増大として、例えば、固定された設定可能な増分値、アカウントに基づく動的値（例えば、現在のキャッシュサイズの百分率）、またはこれらまたはその他のファクタの組合せに基づく値で行うことができる。増大を複数ステップで行うことで、他のキャッシュアカウント（他の好パフォーマンスのキャッシュアカウントなど）は選定済みキャッシュアカウントと同時に割当スペースを増大させることが可能になり、選定済みキャッシュアカウントの追跡は、それがこれ以上のスペースをキャッシュアカウントに割り当てる前に追加スペースを効率的に使用していることを確認することが可能になる、などとすることができる。

パフォーマンスが最も高いキャッシュアカウントの割当スペースを増大させることは、この選定済みキャッシュアカウントが増大したサイズからさらに恩恵を引き出すだろうという見込みで、キャッシュから最大の恩恵を引き出しているキャッシュアカウントにより多くのキャッシュリソースを当てようとする試みである。しかしながら、これは必ずしも該当するとは限らず、いくつかの実施形態では、例えば、キャッシング効率への最小もしくは無視できる増分値を有すると分かっているサイズを超えたスペースを割り当てないようにするために、キャッシュアカウントの割当サイズのための最大値（この値は最大サイズに組み入れられる）があり得る。加えて、より小さい増分の増大を行うことで、その増分からあまり恩恵を受けていないキャッシュアカウントにキャッシング効率を低下させ、それによってさらなるキャッシングスペースを得にくくさせる（または既存のキャッシングスペースをより放棄しやすくさせる）ことにより、プロセス内のより動的なフィードバックを可能にする。

ステップ１０４０で、総割当サイズが計算される（このとき、最近増大したキャッシュアカウントを考慮する）。次いで、処理はステップ１０２０の戻り、ステップ１０２０で、処理は、十分なキャッシュスペースが割り当てられるまで繰り返される（例えば、キャッシュアカウントが次の最高ヒット率（またはそうでなければ次善のキャッシングパフォーマンス）を有し、キャッシュアカウントの割当スペースがまだ最大サイズに達していない状態で再開する）。プロセスは、例えば、総動的キャッシュサイズのすべてがキャッシュアカウントに割り当てられる、またはキャッシュアカウントのすべてが、それらのアカウントの割当スペースをそれらのアカウントの対応する最大サイズに増大させていると、かつ／またはすべてのキャッシュアカウントが処理されたときに、終了する。

図１１では、処理は図１０から続き、総動的キャッシュサイズが総割当サイズ未満であることが既に決定されているので、割当スペースは減少させる必要がある。ステップ１１１０で、総動的キャッシュサイズは総使用サイズと比較される。総動的キャッシュサイズが少なくとも総使用サイズと同じ大きさである場合、十分なキャッシングスペースがキャッシュアカウントの既存の使用法に利用可能であり、したがって処理はステップ１１２０に進んで、割り当てられるが、まだ使用されていないスペースを減少させる。そうでない場合は、処理は以下に説明する図１２へ進む。ステップ１１２０で、総動的キャッシュサイズは総割当サイズと比較される。総動的キャッシュサイズが総割当サイズ未満である場合、処理はステップ１１３０へ進んで、どの割当スペースを減少させるべきかを選定する。そうでない場合は、総動的キャッシュサイズは少なくとも総割当サイズであるので、割当スペースのさらなる減少が行われる必要はなく、処理は終了する。

ステップ１１３０で、割当スペースは、パフォーマンスが最も低いキャッシュアカウント（および割当スペースが使用サイズにまだ減少していないキャッシュアカウント）、例えば、最低ヒット率（キャッシュから供給されるアイテムに関する）、最低キャッシュ節約（キャッシュから供給されるバイトに関する）、最小増加変化率（または最大減少変化率、ヒット率またはキャッシュ節約に関する）、またはこれらまたはその他のファクタの組合せを有するキャッシュアカウントを選定することによって減少させる。次いで、このキャッシュアカウントに対する割当スペースは、例えば最小限の（かつキャッシュコンテンツを廃棄していない）サイズ、すなわち使用サイズに減少させる（または、別の実施形態では、この減少は、総割当サイズ−総動的キャッシュサイズ以下に制限される）。

選定済みキャッシュアカウントに対する最小割当キャッシュスペースの減少は、１回の操作で、または経時的に一連の減少として、例えば、固定された設定可能な減分値、アカウントに基づく動的値（例えば、現在のキャッシュサイズの百分率）、またはこれらまたはその他のファクタの組合せに基づく値で行うことができる。減少を複数ステップで行うことで、他のキャッシュアカウント（他のパフォーマンスが悪いキャッシュアカウントなど）は選定済みキャッシュアカウントと同時に割当スペースを減少させることが可能になり、選定済みキャッシュアカウントの追跡は、それがこれ以上のスペースをキャッシュアカウントから減少させる前に減少スペースを非効率的に使用し続けていることを確認することが可能になる、などとすることができる。

パフォーマンスが最も低いキャッシュアカウントの割当スペースを減少させることは、この選定済みキャッシュアカウントが減少したサイズから有意に少ない恩恵を引き出さないだろうという見込みで、キャッシュから最小の恩恵を引き出しているキャッシュアカウントにより少ないキャッシュリソースを当てようとする試みである。しかしながら、これは必ずしも該当するとは限らず、いくつかの実施形態では、例えば、それ未満ではキャッシュを有していても価値がないかもしれない最小限のコンテンツを保持するのに十分なスペースがあるようにするために、キャッシュアカウントの割当サイズのための最小値（この値は最小サイズに組み入れられる）があり得る。加えて、さらに小さい減分の減少を行うことで、減分後に改善し始める効率を有するキャッシュアカウントにより大きなキャッシングスペースを減少しにくくさせる（またはキャッシングスペースを追加しやすくさせる）ことにより、プロセス内のより動的なフィードバックを可能にする。

ステップ１１４０で、総割当サイズが計算される（このとき、最近減少したキャッシュアカウントを考慮する）。次いで、処理はステップ１１２０の戻り、ステップ１１２０で、処理は、十分なキャッシュスペースが割り当てられるまで繰り返されるが、未使用のキャッシュスペースは解放される（例えば、キャッシュアカウントが次の最低ヒット率を有し、キャッシュアカウントの割当スペースがまだ使用サイズまで減少していない状態で再開する）。プロセスは、キャッシュアカウントのすべての総割当スペースが総動的キャッシュサイズ以下に減少した、またはキャッシュアカウントのすべてが、それらアカウントの割当スペースをそれらのアカウントの対応する最小サイズに減少させていると、かつ／またはすべてのキャッシュアカウントが処理されたときに、終了する。

図１２では、処理は図１１から続き、総動的キャッシュサイズが総使用サイズ未満であることが既に決定されているので、キャッシュ済みアイテムは、キャッシュ内の使用スペースを減少させるために削除される必要がある。最初に、ただ１つのキャッシュアカウントの特別なケースが対処される。ステップ１２１０で、キャッシュアカウントの数が１である場合、処理はステップ１２２０へ進んで特別ケースを処理する。そうでない場合は、処理はステップ１２４０へ進んで複数のキャッシュアカウントを処理する。ステップ１２２０で、使用サイズがもはや総動的キャッシュサイズより大きくない状態になるまで、アイテムが１つのキャッシュアカウントから削除される。ステップ１２３０で、割当サイズは、最大サイズまたは総動的キャッシュサイズの小さい方に設定され、処理は終了する。

複数のキャッシュアカウントがある場合、最初にステップ１２４０でチェックが行われて、低効率のキャッシュアカウントは完全に除去されるべきかどうかを確認する。ステップ１２４０で、いくつかの判定基準が選択され、例えば、キャッシュアカウントの数とキャッシュアカウントの最小数を比較する、または総最小サイズが総動的キャッシュサイズと比較される、またはこれらまたはその他の判定基準を組み合わせたものが用いられる。この場合、キャッシュアカウントの最小数は、キャッシュすべきドメインの最小数を表すことができ、この最小数を超えると、効率の悪いキャッシュを無条件に検出することでかまわないが、最小数未満では、キャッシュの総数ではなく残存キャッシュのサイズを減少させることがさらに有効かもしれない。この最小数より多くのキャッシュアカウントがある、または総最小サイズが総動的キャッシュサイズを超える場合、利用可能なキャッシングスペースにとって過大な数のキャッシュアカウントがあるので、処理はステップ１２５０へ進んでキャッシュアカウントの数を減らす。そうでない場合は、処理は以下に説明する図１３へ進む。

他の実施形態では、無条件に削除され得るアカウントを選定するために使用される他のファクタ、例えば、キャッシュアカウントを特定のサイズ（例えば、キャッシュがそのサイズ未満では無効になりやすいサイズ、最小サイズなど）未満に減少させざるを得ないこと、キャッシュアカウントのキャッシングパフォーマンスが１つまたは複数の有効性尺度（例えば、キャッシュヒット率や節約されるバイトなど）を下回ったとき、などがあり得る。例えば、キャッシュから最低レベルの要求またはバイトを最近の時間フレーム以内に供給しないキャッシュアカウントは削除のために選定されることはない。

ステップ１２５０で、使用スペースは、例えば最低ヒット率を有するキャッシュアカウント（または上述した判定基準で測定されるような最低パフォーマンスのキャッシュアカウント）を削除することによって減少させる。ステップ１２６０で、総使用サイズおよび総割当サイズが再計算される（このとき、最近削除されたキャッシュアカウントを考慮する）。次いで処理は図１０に戻って、最近削除されたキャッシュアカウントに照らして総割当サイズを総動的キャッシュサイズと一致させることを再び試みる。

図１３では、処理は図１１から続き、総動的キャッシュサイズが総使用サイズ未満であり、かつキャッシュアカウントの数がキャッシュすべきドメインの最小数以下である（またはその他の判定基準、例えば総動的キャッシュサイズが少なくとも総最小サイズであることが満たされる）ことが既に決定されているので、キャッシュ済みアイテムは、キャッシング記憶装置から、ただしキャッシュアカウント全体を無条件に削除せずに削除される必要がある。したがって、図１３の実施形態では、（例として）以下の２つの代替案が検討される。（１）割り当てられた（拡張して、使用された）スペースを残りのキャッシュの間で比例的に減少させて、総動的キャッシュサイズがこのとき総使用サイズに等しくなるようにする、または（２）パフォーマンスが最も低いキャッシュアカウント、例えば最低ヒット率を有するキャッシュアカウントを削除する（上記の図１２のステップ１２５０〜ステップ１２６０と同様）。大部分のキャッシュスペースを、キャッシングパフォーマンスを損なわずに空き状態にする代替案が選定される。

代替案（１）でのキャッシュアカウントに適用される比例は、例えば、各キャッシュの態様（例えば、ヒット率、供給されるバイトなど）によって異なる比例係数を用いて、定数または変数とすることができ、したがって、比例的減少（ｐｒｏｐｏｒｔｉｏｎａｌ ｒｅｄｕｃｔｉｏｎ）は、低パフォーマンスのキャッシュでは高くなり、高パフォーマンスのキャッシュでは低くなり得る。したがって、ステップ１３１０で、「総供給バイト（Ｔｏｔａｌ Ｂｙｔｅｓ Ｓｅｒｖｅｄ）」は、各割当サイズの比例的減少が総割当サイズを総動的キャッシュサイズまで引き下げるのに十分であるものとして再計算される。この再計算済み総供給バイトの正確な数はキャッシングシミュレータを必要とし得るが、再計算済み総供給バイトは、代わりに、各キャッシュに対して供給バイトを同量の割当サイズ減少だけ比例的に減少させることにより近似することができる。ステップ１３２０で、この再計算済み総供給バイトは、最低ヒット率を有するキャッシュアカウントを除くすべてのキャッシュアカウントに対するすべての（未減少）供給バイトの合計と比較される。このテストの目標は、２つの上記代替案のどちらが選定されるべきかを決定することである。

再計算済み総供給バイトが、最低ヒット率を有するキャッシュアカウント以外のすべてに対する供給バイトの合計より大きい場合、処理はステップ１３３０へ進んで、すべてのキャッシュアカウントの比例的減少を行う。すなわち、全体的なキャッシングパフォーマンスは、キャッシュアカウント全体を削除するより、既存のキャッシュアカウントへの比例的減少によってより良い働きをするようである。そうでない場合は、処理はステップ１３４０へ進んで、最低パフォーマンスのキャッシュアカウント（ヒット率が最低のアカウントなど）を削除する。このことは図１２のステップ１２５０〜１２６０と同様であるので、さらに説明を繰り返さない。ステップ１３３０で、各キャッシュアカウントの割当サイズを比例的に減少させて総割当サイズが総動的キャッシュサイズに等しくなるようにする。次いで、各キャッシュアカウントから十分なアイテムを削除して、使用サイズがもはや新たに減少した割当サイズより大きくないようにし、この時点で処理は終了する。

したがって、図９〜図１３の方法では、総動的キャッシュサイズは動的に変わることができ、キャッシュアカウントは、それに応じて、総割当サイズを総動的キャッシュサイズと同じにしておくように調整する。これは、さらなるキャッシュアカウントを追加すること（図９）、または総動的キャッシュサイズ総動的キャッシュサイズが増大するときに割当スペースを既存のキャッシュアカウントまで減少させること（図１０）、または割当スペースを既存のキャッシュアカウントに減少させること（図１１および図１３）、キャッシュアカウントを削除すること（図１２および図１３）、および／または総動的キャッシュサイズが収縮するときにキャッシュアカウントからキャッシュ済みアイテムを削除すること（図１２および図１３）を含むことができる。特に、キャッシュアカウントを削除するか、既存のキャッシュアカウントの割当スペースを減少させるか、の選択は、最低パフォーマンスの（例えば、最低ヒット率またはその他の判定基準）キャッシュアカウントが他のキャッシュアカウントに対してどのくらいうまく機能しているかに基づいて行われる。

当業者には明らかなように、図９〜図１３の上記方法に修正を加えることができることに留意すべきである。例えば、図１３では、最低パフォーマンスのキャッシュアカウント（例えば、ヒット率が最低のアカウント）は、キャッシング記憶不足を完全に軽減するには小さ過ぎることがあり、その場合、ステップ１３２０および１３４０での最低パフォーマンスのキャッシュアカウントをいくつかの低パフォーマンスキャッシュアカウント（例えば、最低パフォーマンスのキャッシュアカウントに代えて２つの最低ヒット率を有する２つの最低パフォーマンスのキャッシュアカウント）に置き換える方が良いかもしれない。この概念は、極端なキャッシング記憶不足などの場合に、ステップ１３２０でテストを行うときまたはステップ１３４０の処理を行うときに、最高パフォーマンスのキャッシュアカウント（例えば、最高ヒット率を有するアカウント）を除いてすべて排除する点まで拡張することができる。

別の例として、図１２における無条件の削除は、例えば、最小閾値（例えば、ヒット率、供給バイト）未満で実行されているキャッシュアカウントの除去を確実にするために、総動的キャッシュサイズが総使用サイズより大きいときでも実行することができ、このことは、キャッシュを有することで決して十分には恩恵を受けないドメインにキャッシュするオーバーヘッドを回避する。

図１４は、本発明の一実施形態による動的キャッシング編成例１４００である。図１４は、ネットワーク活動統計収集モジュール１４１０、反復活動統計収集モジュール１４２０、動的キャッシュアカウント管理モジュール１４３０、キャッシング統計記憶装置１４４０など、編成１４００の一層重要なコンポーネントのうちのいくつかを示す。本発明のこれらまたはその他のモジュールは、例えば、当業者には明らかなように汎用プロセッサまたは専用プロセッサ上で走る（例えば、このプロセッサで実行される）ように設計されたコンピュータ命令などのハードウェアまたはソフトウェアに実装することができる。さらに、キャッシング統計記憶装置１４４０は、例えば、不揮発性記憶装置（ディスクやフラッシュドライブなど）および／または揮発性記憶装置（ＲＡＭなど）に保持することができる。

ネットワーク活動統計収集モジュール１４１０は、アプリのためのネットワーク活動の高レベル収集を行う。新しいアプリが開始されるとき（または探訪される新しいウェブサイト、または他の潜在的なキャッシュ可能活動、これは一般に「アプリ」と呼ばれる）、ネットワーク活動統計収集モジュール１４１０は、キャッシュ可能要求や転送されるバイトなどのカウンタセットを開始する。例えば、新しいアプリは図２に記載されている追跡テーブルに追加することができ、アプリの活動は、そのアプリが動的キャッシュ管理または反復活動統計収集のための潜在的候補になるかどうかを確認するために、最初の期間（例えば、図３の方法に記載されているＴ１期間）中に追跡することができる。これらのカウンタおよび追跡テーブルは、例えば、キャッシング統計記憶装置１４４０に保存することができる。新しいアプリが動的キャッシュ管理のための有望な候補であるように見える場合（例えば、そのアプリのキャッシュ可能要求カウントまたは転送されるバイトが、Ｔ１期間中に、セットや所定の閾値などの閾値を超えた場合）、アプリは、より集中的な統計収集のために反復活動統計収集モジュール１４２０に渡されてもよい。

得られる統計に応じて、ネットワーク活動統計収集モジュール１４１０は、アプリのネットワーク活動統計を、そのアプリが動的キャッシュ管理または反復活動統計収集のための候補として識別された後でも蓄積し続けることができる。例えば、ネットワーク活動統計収集モジュール１４１０は、アプリのための別のＴ１追跡期間を開始することができる。ネットワーク活動の動的性質、および基本的ネットワーク活動集計の比較的低いオーバーヘッド（例えば、キャッシュ可能要求または転送されるバイト）のために、アプリの大部分または全部がネットワーク活動統計収集モジュール１４１０による動的キャッシュ管理のために検討されるのを監視し続けることが有益となり得る。

反復活動統計収集モジュール１４２０は、動的キャッシュ管理として考慮されるアプリのキャッシング挙動をシミュレートする。例えば、反復活動統計収集モジュール１４２０は、ネットワーク活動統計収集モジュール１４１０によって識別される候補アプリが動的キャッシュ管理に適しているかどうかを決定するために、図２の追跡テーブルおよび図３〜図７における反復活動を追跡する方法を使用することができる。すなわち、追跡期間（例えば、図３の方法に記載されているＴ２期間）にわたってアプリ用の追跡テーブルおよび要求テーブルおよび／または応答テーブル（例えば、キャッシング統計記憶装置１４４０に保存され得る）を使用して明白な反復要求活動（例えば、反復要求および転送される応答バイト）を追跡することにより、反復活動統計収集モジュール１４２０は、アプリが動的キャッシュ管理から恩恵を受けるように見えるかどうかを識別することができる。

例えば、Ｔ２期間中のアプリに対する反復要求または転送されるバイトがセットまたは所定の閾値を超えた場合、反復活動統計収集モジュール１４２０は、アプリを動的キャッシュアカウント管理モジュール１４３０に渡す、またはアプリを動的キャッシュ管理に適した（例えば、キャッシング統計記憶装置１４４０に保持された）アプリリスト上に置くことができる。

ネットワーク活動統計収集モジュール１４１０とは異なり、反復活動統計収集モジュール１４２０による反復活動統計の収集は、基本的ネットワーク活動統計収集よりもかなりコンピュータ的かつ記憶集約的である。このため、反復活動統計収集モジュール１４２０は、動的キャッシュアカウント管理モジュール１４３０による動的キャッシュ管理から恩恵を受けるであろうアプリの代表的な現在のリストをより良く保持するために、２〜３のアプリだけを一度に監視することができる。例えば、反復活動統計収集モジュール１４２０は、ネットワーク活動統計収集モジュール１４１０によって（例えば最近のＴ１期間中に）決定された要求のキャッシュ可能性に基づいてアプリ／サイトのための反復活動追跡を開始することができ、次いで、モジュール１４２０が反復活動を追跡しているアプリ／サイトについて、モジュール１４２０は、そのアプリ／サイトの反復要求および最近の期間（例えば最近のＴ２期間）にわたって転送されたバイトなどの統計に基づいて動的キャッシュ管理のための最良の（かる現在キャッシュされていない）アプリの動的な保存済みリストを維持することができる。

動的キャッシュアカウント管理モジュール１４３０は、ネットワーク活動統計収集モジュール１４１０、反復活動統計収集モジュール１４２０、またはそれらを組み合わせたものによって識別される実際のキャッシングを、キャッシングから恩恵を受けやすいものとして管理する。動的キャッシュアカウント管理モジュール１４３０は、キャッシング統計１４４０ならびに他の可能なファクタ、例えば、どのアプリ／サイトをキャッシュすることができ、どのアプリ／サイトをキャッシュすることができないのかを管理者によって提供される規則に基づいて、アプリまたはウェブサイト用のキャッシュ１４５０を割り当て維持する。例えば、動的キャッシュアカウント管理モジュール１４３０は、図９〜図１３を参照して上述したような技法を使用することができる。

動的キャッシュアカウント管理モジュール１４３０は、例えば、現在のアプリがキャッシュされるのをよりうまく管理し、キャッシングから恩恵を受けることができない（またはもはや受けることができない）アプリならびにキャッシングから大いに恩恵を受けるアプリを識別するために、キャッシング統計記憶装置１４４０に保存されるような、キャッシング挙動の実際の統計（例えば、キャッシュサイズ、転送される反復要求およびバイトの実際の数、キャッシュヒット率など）を維持することもできる。これらの統計は、どのアプリをキャッシュ（または追跡）すべきか、およびどの調整（例えばキャッシュサイズ）がかかるアプリに行われるべきかを決定する際に動的キャッシュアカウント管理モジュール１４３０（およびその他のモジュール１４１０および１４２０）を支援するためにキャッシング統計記憶装置１４４０に維持することができる。

本発明の他の実施形態はネットワーク管理を対象としている。ネットワーク活動を管理することで、帯域幅使用量を監視／識別するツールおよび帯域幅使用量を制御／調整するツールを利用することができる。フォン上でのネットワーク活動のために帯域内にあることにより、本発明の実施形態は、その活動のためのリソース使用量（例えば、帯域幅、電池、ＣＰＵ、セルの接続、など）を監視し、その活動をネットワーク内のさらにダウンストリームでしばしば利用できない非常に詳細な情報と関連付けることができる。この種のデータ分析の例としては、帯域幅使用状況、セルの接続状態、パフォーマンス、および電池使用状況がある。

帯域幅使用状況は、複数のアプリが同一ドメインをアクセスすることができるので、各アプリ用の各目標／宛先ドメインに対する帯域幅使用状況を追跡することを意味する。これは、例えば、（遠隔サーバから受信される）インデータと（遠隔サーバに送信さされる）アウトデータの両方に対して追跡することができる。これは、総帯域幅（ネットワークおよびキャッシュ）対ネットワーク／キャッシュに関して追跡することができる。プロクシサーバは、ＯＳによって提供されるプロセスごとの接続情報と関連付けることができるＴＣＰポート番号などの接続レベルの詳細を見ることができ、したがって装置上で走る特定のアプリ／プロセスに対して活動を追跡することができる。

セルの接続状態は、これがセルサイト内の他のユーザの間の限られた／共有されたリソースであるので、セルラーネットワークがどのくらいの頻度でまたはどのくらいの量で接続されるのかを追跡することを意味する。例えば、これは、接続状態がどのくらいの頻度で変わる（例えば、切断される、接続される、休止状態、一時停止される）のかという点で追跡することができる。これは、接続状態がどのくらいの期間「接続された」ままであるのかに関して追跡することもできる。この値は、キャッシングの増大が総接続時間を短縮するかどうかを決定するなどのために帯域幅データと関連付けるとともに、装置上で走る特定のアプリ／プロセスと関連付けることもできる。

パフォーマンスは、要求当たりの時間や秒当たりのバイトなどのパフォーマンス関連状態を測定することを意味し、これは、ＨＴＴＰ要求やブラウザのページロード時間などの様々なネットワーク関連活動に必要となり得る。実施形態は、ネットワークから完全に、キャッシュから完全に、サーバの再バリデーション後にキャッシュから、などの、要求が処理される様々な道筋に対して、スループットを別々に測定することができる。

電池使用状況は、電池がネットワーク活動に、ドメインやアプリなどによってどのくらい使用されているかを追跡することを意味する。一実施形態では、電池レベルは各要求の前後に測定される。より詳細には、電池使用状況は、ドメイン、アプリ、コンテンツタイプ、Ｗｉ−Ｆｉ対セルラー、などで測定することができる。
１．ネットワークアクセスポリシー

フォン上でのネットワーク活動のために「帯域内」にあることにより、本発明の実施形態は、ネットワーク活動を、特にネットワーク内で実施されるときに可能でないかもしれない方法で制御および／または制限することができる。例えば、装置において実施されるポリシーは、ユーザがアクセスすることができる様々なネットワークタイプを、ＷｉＦｉネットワークなどの無線通信事業者または企業によって制御されないものを含めてカバーする制御を提供することができる。

ネットワークアクセスポリシー例のいくつかは、好ましくないコンテンツを監視もしくはブロックすること、および情報漏えいを監視もしくはブロックすることを含む。好ましくないコンテンツを監視もしくはブロックする場合、ポルノ、さらには広告などの好ましくないコンテンツへのアクセスは、例えば、要求、宛先サーバ、および／またはコンテンツタイプに基づいて、装置によってアクセスされる様々なネットワークを通じて検出またはブロックすることができる。これをする１つの方法が、ＵＲＬパターンやホスト名などの要求パラメータのリストを維持することであり、このリストはすべての要求に対してチェックされる。他の検出方法は、ウェブページ用のＨＴＭＬなどのコンテンツ内のキーワードを照合すること、または写真もしくは映像内の画像パターンを照合することを含む。

情報漏えいを監視もしくはブロックする場合、情報の予期せぬまたは望まれない送信は、例えば、要求コンテンツまたは宛先サーバに基づいてブロックすることができる。これをする１つの方法が、すべての要求に対してチェックされる、ＵＲＬパターンやホスト名（例えば、既知のマルウェア／フィッシングサーバ）などの要求パラメータのリストを維持することである。別の検出方法は、社会保障番号または電子メールアドレスを探すなどして、要求コンテンツ内のパターンを照合することである。

これらのネットワークアクセスポリシーを管理するには多くのオーバーヘッドを伴うことがある。例えば、ネットワークアクセスポリシー情報を装置に維持することで、最新状態に保たれる必要がある大量のコンテンツ／マタデータ、例えば、ポルノまたは既知のマルウェア／フィッシングウェブサイトを提供するドメイン／サーバのグローバルリストを構成することができる。この情報を効率的に維持するために、以下の手法の一方または両方をとることができる。すなわち、集中型サーバまたは管理コンソールにおいて変更内容をチェックし処理し、そこで装置への最新情報を効率的に計算／圧縮／分配することができる、あるいは、要求情報をハッシュして短縮された「ルックアップキー」、キャッシュに保存される応答を検索するために使用されるルックアップキーなどにする。

本発明について、いくつかの実機形態例に関連して説明してきたが、本発明は、開示された実施形態に限定されるものではなく、それどころか、下記の特許請求の範囲によって定義される本発明の精神および範囲から逸脱することなく、当業者には明らかであろう様々な修正形態および均等構成、ならびにそれらの均等物を網羅するためのものである。

Claims (22)

1. ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを動的にキャッシュするためのシステムであって、
   プロセッサと、
   前記ユーザによって前記ネットワークを通じてアクセスされる前記サイトの前記コンテンツを、前記ユーザによる前記ネットワーク上での前記サイトを用いた活動に基づいて保存するためのキャッシュアカウントを維持するための第１の記憶装置と、
   統計を保存するための第２の記憶装置と、
   命令を保存されている非一時的物理媒体とを備え、前記命令は、前記プロセッサによって実行されるときに、前記プロセッサに、
   前記ネットワークでの活動に基づいてキャッシングに対する前記サイトの適合性に関する統計を収集させ、
   前記キャッシングの適合性統計を前記第２の記憶装置に保存させ、
   前記キャッシングの適合性統計に基づいて前記キャッシュアカウントを動的に生成、削除、またはサイズ変更させる、
   ことを特徴とするシステム。
2. 前記キャッシングの適合性統計が、前記ユーザによる前記サイトを用いたキャッシュ可能活動の統計を含み、
   前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、前記キャッシュ可能活動の統計に基づいて前記キャッシュアカウントを動的に生成させる、
   請求項１に記載のシステム。
3. 前記キャッシュ可能活動の統計が、前記ユーザによる前記サイトを用いたキャッシュ可能要求、または前記キャッシュ可能要求に対応する前記ネットワークでの活動のキャッシュ可能バイトを含む、請求項２に記載のシステム。
4. 前記キャッシングの適合性統計が前記ユーザによる前記サイトを用いた反復活動の統計をさらに含み、
   前記反復活動の統計が前記ユーザによる前記サイトを用いた反復要求を含む、
   請求項３に記載のシステム。
5. 前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、
   前記キャッシングの適合性統計に基づいて前記サイトのうちの上位サイトを識別させ、
   前記サイトのうちの前記上位サイトに対する前記反復要求を追跡させる、
   請求項４に記載のシステム。
6. 前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、前記キャッシュ可能要求または前記キャッシュ可能バイトに基づいて前記サイトのうちの前記上位サイトを識別させる、請求項５に記載のシステム。
7. 前記キャッシングの適合性統計が、前記ユーザによる前記サイトを用いた反復活動の統計を含み、
   前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、前記反復活動の統計に基づいて前記キャッシュアカウントを動的に生成させる、
   請求項１に記載のシステム。
8. 前記反復活動の統計が前記ユーザによる前記サイトを用いた反復要求を含む、請求項７に記載のシステム。
9. 前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、
   前記キャッシングの適合性統計に基づいて前記サイトのうちの上位サイトを識別させ、
   前記サイトのうちの前記上位サイトに対する前記反復要求を追跡させる、
   請求項８に記載のシステム。
10. 前記キャッシングの適合性統計が、前記ユーザによる前記サイトを用いたキャッシュ可能活動の統計をさらに含み、
    前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、前記キャッシュ可能活動の統計に基づいて前記サイトのうちの前記上位サイトを識別させる、
    請求項９に記載のシステム。
11. 前記キャッシュ可能活動の統計が、前記ユーザによる前記サイトを用いたキャッシュ可能要求、または前記キャッシュ可能要求に対応する前記ネットワークでの活動のキャッシュ可能バイトを含み、
    前記命令が、前記プロセッサによって実行されるときに、さらに前記プロセッサに、前記キャッシュ可能要求または前記キャッシュ可能バイトに基づいて前記サイトのうちの前記上位サイトを識別させる、
    請求項１０に記載のシステム。
12. ユーザによってネットワークを通じてアクセスされるサイトのコンテンツを動的にキャッシュする方法であって、
    プロセッサにより、非一時的物理媒体に保存された命令を実行することと、
    前記プロセッサにより第１の記憶装置上に、前記ユーザによる前記ネットワーク上での前記サイトを用いた活動に基づいて前記ユーザによって前記ネットワークを通じてアクセスされる前記サイトの前記コンテンツを保存するためのキャッシュアカウントを維持することと、
    前記プロセッサにより第２の記憶装置に統計を保存することと、
    前記プロセッサにより、前記ネットワークでの活動に基づいてキャッシングに対する前記サイトの適合性に関する統計を収集することと、
    前記プロセッサにより、前記第２の記憶装置上に前記キャッシングの適合性統計を保存することと、
    前記プロセッサにより、前記キャッシングの適合性統計に基づいて前記キャッシュアカウントを動的に生成、削除、またはサイズ変更することと
    を含む方法。
13. 前記キャッシングの適合性統計が、前記ユーザによる前記サイトを用いたキャッシュ可能活動の統計を含み、
    前記方法が、前記プロセッサにより、前記キャッシュ可能活動の統計に基づいて前記キャッシュアカウントを動的に生成することをさらに含む、
    請求項１２に記載の方法。
14. 前記キャッシュ可能活動の統計が、前記ユーザによる前記サイトを用いたキャッシュ可能要求、または前記キャッシュ可能要求に対応する前記ネットワークでの活動のキャッシュ可能バイトを含む、請求項１３に記載の方法。
15. 前記キャッシングの適合性統計が前記ユーザによる前記サイトを用いた反復活動の統計をさらに含み、
    前記反復活動の統計が前記ユーザによる前記サイトを用いた反復要求を含む、
    請求項１４に記載の方法。
16. 前記プロセッサにより、前記キャッシングの適合性統計に基づいて前記サイトのうちの上位サイトを識別することと、
    前記プロセッサにより、前記サイトのうちの前記上位サイトに対する前記反復要求を追跡することと
    をさらに含む、請求項１５に記載の方法。
17. 前記プロセッサにより、前記キャッシュ可能要求または前記キャッシュ可能バイトに基づいて前記サイトのうちの前記上位サイトを識別することをさらに含む、請求項１６に記載の方法。
18. 前記キャッシングの適合性統計が、前記ユーザによる前記サイトを用いた反復活動の統計を含み、
    前記方法が、前記プロセッサにより、前記反復活動の統計に基づいて前記キャッシュアカウントを動的に生成することをさらに含む、
    請求項１２に記載の方法。
19. 前記反復活動の統計が前記ユーザによる前記サイトを用いた反復要求を含む、請求項１８に記載の方法。
20. 前記プロセッサにより、前記キャッシングの適合性統計に基づいて前記サイトのうちの上位サイトを識別することと、
    前記プロセッサにより、前記サイトのうちの前記上位サイトに対する前記反復要求を追跡することと
    をさらに含む、請求項１９に記載の方法。
21. 前記キャッシングの適合性統計が、前記ユーザによる前記サイトを用いたキャッシュ可能活動の統計を含み、
    前記方法が、前記プロセッサにより、前記キャッシュ可能活動の統計に基づいて前記サイトのうちの前記上位サイトを識別することをさらに含む、
    請求項２０に記載の方法。
22. 前記キャッシュ可能活動の統計が、前記ユーザによる前記サイトを用いたキャッシュ可能要求、または前記キャッシュ可能要求に対応する前記ネットワークでの活動のキャッシュ可能バイトを含み、
    前記方法が、前記プロセッサにより、前記プロセッサに、前記キャッシュ可能要求または前記キャッシュ可能バイトに基づいて前記サイトのうちの前記上位サイトを識別することをさらに含む、
    請求項２１に記載の方法。