JP5480893B2 - ローカル・ホスト・キャッシュおよび暗号ハッシュ機能を用いてネットワーク・トラフィックを低減する方法およびシステム - Google Patents

Description

[0001] 本発明は、一般的には、コンピューター・システムに関し、更に特定すれば、ネットワークを通じてデータを要求元クライアントに供給するための応答時間を改善するコンピューティングシステムに関する。

従来技術

[0002] 業務環境において一般的に実装されているデータ・ネットワーク構成では、データ・ストレージをデータ・センターに集中させ、このデータ（例えば、データ・センターにおけるサーバーを経由して）を複数のクライアントコンピューティングデバイスにワイド・エリア・ネットワークを通じて供給することを伴う。複数のクライアントコンピューティングデバイスは、ＷＡＮの１つ又複数のブランチに位置することができる。これらのブランチは、ＷＡＮに対する少なくとも１つの接続を有するローカル・エリア・ネットワーク（ＬＡＮ）を用いて互いに通信状態で結合されている複数のコンピューティングデバイスを表すことができる。ＬＡＮは、ルーターまたは当技術分野では周知のその他の橋架デバイスを通じてＷＡＮに結合することができる。大会社の環境では、データ・センターがブランチ（１つまたは複数）から離れて配置される場合もある。クライアント・デバイス上で実行するアプリケーションは、動作のために、データ・センターからのデータ（例えば、データ・センターにおけるアプリケーション・センターを通じて給送される）を必要とする場合がある。ワイド・エリア・ネットワーク（ＷＡＮ）上のデータ・トラフィックが増大すると、一般に、帯域幅が縮小し、ＷＡＮを通じたデータ要求に対するレイテンシーが長大化する虞れがある。このため、ブランチ・オフィスにあるコンピューティングデバイスにおけるアプリケーション応答時間が遅れる虞れがある。

[0003] ワイド・エリア・ネットワーク上におけるデータ・トラフィックを低減し、帯域幅およびレイテンシーを改善するのに役立てるために、一部の業務ではＷＡＮ最適化システムを実施する場合がある。一般に、ワイド・エリア・ネットワーク（ＷＡＮ）最適化システムとは、ＷＡＮ上における帯域幅消費を低減するように設計されたハードウェアである。ＷＡＮ最適化システムの目標は、データ・トラフィックを搬送するためのＷＡＮ帯域幅の量を低減することである。一般に、ＷＡＮ最適化装置は、データの圧縮、ならびにデータのＷＡＮへの送信およびＷＡＮからのデータの引き出しをインテリジェントに管理する（特定のアルゴリズムを用いて）ように動作することができる。ＷＡＮ上におけるデータ・トラフィックを圧縮することにより、データ・トラフィックを低減し、それに対応して輻輳も減少させることができる。ＷＡＮ上において輻輳が減少すると、ルーターのレイテンシー、ジッター、およびパケットの損失も対応して減少することができる。

[0004] 既存のＷＡＮ最適化システムは、ＷＡＮの帯域幅については一般に改善をもたらすが、既存のＷＡＮ最適化システムは、暗号化データを扱うことや、終端間(end-to-end)のセキュリティを設けることには適していない場合もある。更に、既存のＷＡＮ最適化システムは、データ・センターおよび各ブランチ・オフィスの双方においてインターフェース・ハードウェアの動作を必要とし、これによって保守コストの増大を招く虞れがある。

[0005] 本方法およびシステムは、ブランチ・オフィスにおけるクライアントが、アプリケーション・サーバーの代わりに、ホスト・キャッシュ(hosted cache)からＷＡＮを通じてデータを引き出すことを可能にして、レイテンシーを改善し、全体的なＷＡＮトラフィックを低減しようとするものである。データ・センターにおけるサーバーは、ホスト・キャッシュ・システムがイネーブルされているか否かに基づいて、ハッシュのリストまたは要求されたデータのいずれかを提供するように構成することができる。クライアント側におけるホスト・キャッシュは、ハッシュに基づいて、データをクライアントに供給することができる。ハッシュは、一般に、データの指紋(fingerprint)を与えることができ、この指紋はデータをインデックス化するために用いることができる。

図１は、記載する実施形態にしたがって動作することができるコンピューティングシステムのブロック図を示す。 図２は、一般的なＷＡＮ最適化システムを示す。 図３は、ホスト・キャッシュを用いたデータ引き出しプロセスのシステム実施形態を示す。 図４は、ホスト・キャッシュと共に用いるレコード・フォーマットを示す。 図５は、複数のホスト・キャッシュを実装したシステム実施形態を示す。 図６は、分散型キャッシュを用いるピア・ツー・ピア・ネットワークの実施形態を示す。 図７は、ホスト・キャッシュのために専用ピアを用いるピア・ツー・ピア・プロセスの実施形態を示す。 図８は、図３のシステムを用いたサーバー側プロセスの実施形態を示す。 図９は、図３のシステムを用いたクライアント側プロセスの実施形態を示す。 図１０は、失効(expiration)パラメーターを用いたレコード・フォーマットを示す。

[0016] 以下の本文は、多数の異なる実施形態の詳細な説明を明記するが、この記載の法的範囲は、本特許の終端に明記される特許請求の範囲の文言によって定義されることは言うまでもない。あらゆる可能な実施形態を記載することは、不可能ではないにしても、現実的ではないので、詳細な説明は単なる例示と解釈すべきであり、あらゆる可能な実施形態を記載するのではない。多数の大体実施形態も、現在の技術または本特許の出願日以降に開発された技術のいずれを用いても、実現することができ、これらも特許請求の範囲に該当するものとする。

[0017] また、「本明細書において用いる場合、「 」という用語は．．．を意味することを定めるものとする」という文章または同様の文章を用いて本特許において用語が明示的に定義されていないのであれば、その用語の意味を、その平素の意味または通常の意味を超えて、明示的にもまたは暗示的にも限定する意図はなく、このような用語は、本特許のいずれの章において作成されたいずれの言説（特許請求の範囲の文言以外）に基づいても、その範囲を限定するように解釈してはならないことは言うまでもない。本特許の最後にある特許請求の範囲において列挙されているいずれの用語も、本特許において、１つの意味で一貫性をもって言及されている場合については、読者を混乱させないことのみを目的とした明確化のためにそれを行ったのであり、このような請求項の用語が、暗示等によって、その１つの意味に限定されることを意図するのではない。最後に、請求項の要素が、「手段」という用語および機能を明記することによって定義され、何の構造の明言もない場合を除いて、いずれの請求項の要素も、３５Ｕ．Ｓ．Ｃ．§１１２、第６パラグラフの適用に基づいて、解釈されることを意図しているのではない。

[0018] 図１は、適したコンピューティングシステム環境１００の一例を示す。このコンピューティングシステム環境１００は、本明細書で記載するユーザー・インターフェースを表示し提供するように動作することができる。尚、コンピューティングシステム環境１００は、適したコンピューティング環境の一例に過ぎず、特許請求の範囲の方法および装置の使用または機能の範囲に関して、何の限定をも示唆することも意図していないことは、注記してしかるべきである。環境例１００に示されるいずれのコンポーネントまたはコンポーネントの組み合わせに関しても、コンピューティング環境１００が何らかの依存性または要件を有するように解釈してはならない。

[0019] 図１を参照すると、特許請求する方法および装置のブロックを実施するためのシステム例は、コンピューター１１０の形態とした汎用コンピューティングデバイスを含む。コンピューター１１０のコンポーネントには、限定ではないが、演算装置またはプロセッサ１２０、システム・メモリー１３０、およびシステム・メモリーを含む種々のシステム・コンポーネントを演算装置１２０に結合するシステム・バス１２１を含むことができる。

[0020] コンピューター１１０は、ネットワーク接続環境において、リモート・コンピューター１８０のような、１つ又複数のリモート・コンピューターに対する論理接続を用いて、ローカル・エリア・ネットワーク（ＬＡＮ）１７１および／またはワイド・エリア・ネットワーク（ＷＡＮ）１７３を通じて、モデム１７２を通じて、またはその他のネットワーク・インターフェース１７０を通じて動作することができる。

[0021] コンピューター１１０は、通例、種々のコンピューター読み取り可能媒体を含み、これらの媒体は、コンピューター１１０によってアクセスできる入手可能な媒体であればいずれでもよく、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。システム・メモリー１３０は、リード・オンリ・メモリー（ＲＯＭ）１３１およびランダム・アクセス・メモリー（ＲＡＭ）１３２のような、揮発性および／または不揮発性メモリーの形態としたコンピューター記憶媒体を含む。ＲＯＭは、基本入力／出力システム１３３（ＢＩＯＳ）を含むことができる。ＲＡＭ１３２は、通例、データおよび／またはプログラム・モジュールを収容する。プログラム・モジュールには、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７が含まれる。また、コンピューター１１０は、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体も含むことができ、ハード・ディスク・ドライブ１４１、磁気ディスク１５２に対して読み取りおよび書き込みを行う磁気ディスク・ドライブ１５１、光ディスク１５６に対して読み取りおよび書き込みを行う光ディスク・ドライブ１５５等が挙げられる。ハード・ドライブ１４１、１５１、および１５５は、インターフェース１４０、１５０を通じて、システム・バス１２１とインターフェースすることができる。

[0022] ユーザーは、キーボード１６２およびポインティング・デバイス１６１のような入力デバイスを通じてコンピューター２０にコマンドおよび情報を入力することができる。ポインティング・デバイス１６１は、慣例ではマウス、トラックボール、またはタッチ・パッドと呼ばれている。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バスに結合されているユーザー入力インターフェース１６０を通じて演算装置１２０に接続されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）というような、他のインターフェースおよびバス構造によって接続することもできる。モニター１９１またはその他のタイプのディスプレイ・デバイスも、ビデオ・インターフェース１９０のようなインターフェースを通じて、システム・バス１２１に接続することができる。モニターに加えて、コンピューターは、スピーカー１９７およびプリンター１９６のような他の周辺出力デバイスも含むことができ、これらは出力周辺インターフェース１９０を通じて接続することができる。
ＷＡＮ最適化システム
[0023] 図２は、当技術分野において一般に知られているＷＡＮ最適化システム２００を実現するワイド・エリア・ネットワーク（ＷＡＮ）を示す。ＷＡＮ最適化システムは、一般に、ワイド・エリア・ネットワーク接続の両側に配備することができる。

[0024] ＷＡＮ最適化システムは、一般に、１対のコンポーネント・ハードウェア・デバイスを伴う。即ち、一般にＷＡＮ２０３の一方側にあるデータ・センター２０２に設置されるサーバー側コンポーネント２０１と、ブランチ２０６に設置されるクライアント側コンポーネント２０４である。多くの場合、ＷＡＮ最適化コンポーネント・デバイス（サーバー２０１またはクライアント・コンポーネント２０４）は、ＷＡＮルーター２０８（例えば、ＷＡＮ接続とは反対側にあるポートにおいてルーターに結合されている）の背後に配置するとよい。これらのデバイス２０１および２０４は、ＷＡＮを通じたアプリケーション性能が向上するように、ＷＡＮ２０３に宛てられたアプリケーション・トラフィックを調整するように動作することができる。その結果、ＷＡＮを加速化し、アプリケーションの応答タイムを高速化することができる。これによって、ブランチ・オフィスにいるエンド・ユーザーや、移動体作業員（例えば、ラップトップまたはその他の移動体コンピューティングデバイスを通じて接続する）に、重要なアプリケーションへのアクセス速度を高めることが可能となる。

[0025] ブランチ２０６は、一般にデータ・センター２０２にデータを要求する複数のクライアント・コンピューター２１１を含むことができる。会社環境の中には、ブランチが機能（例えば、会計、調達、顧客サービス等）を分割するために設置されることもある。会社環境の中には、ブランチ２０６が特定の地理的サービス場所を提供する場合もある。一般に、クライアント・コンピューター２１１は、データ・センター２０２において１つ又複数のアプリケーション・サーバー２１５にアクセスする１つ又複数の業務アプリケーションを実行することができる。

[0026] アプリケーション・サーバー２１５は、当該アプリケーション・サーバー２１５によって実行されるアプリケーションにデータを供給するために、データベース２１７（例えば、データ・センターに位置するか、またはデータ・センターから離れて位置する）に結合することができ、そしてＷＡＮ２０３を通じてブランチ・オフィスにあるクライアント２１１に提供することができる。勿論、ＬＡＮ２１０を用いるブランチ構成の代わりに、図２は、ＷＡＮを通じてサーバー２１５からトラフィックを受信するためにＷＡＮに接続されているあらゆるクライアント・デバイス、例えば、インターネットを通じて接続するリモート・ラップトップにも等しく適用可能である。
ＷＡＮ最適化装置の機能
[0027] 一般に、サーバー側ＷＡＮ最適化デバイス２０１は、データ・センターのサーバー（例えば、サーバー２１５）によって発せられたデータを調査してインデックス化し、調査に基づいてデータ・パケットを圧縮し、ＷＡＮ２０３を通じてこのデータ・パケットを送信するように動作することができる。クライアント側ＷＡＮ最適化コンポーネント２０４は、ＷＡＮ２０３を通じてサーバー側コンポーネント２０１から圧縮データを受信し、データ・パケットを伸張し、ブランチ２０６における要求元クライアント２１１のデバイスにデータを供給するように動作することができる。

[0028] ＷＡＮ最適化システムの中には、サーバー側コンポーネント・デバイス２０１が、データの送信をスケジューリングするために（例えば、優先度に応じて）データをインデックス化する場合もある。クライアント２０４におけるＷＡＮ最適化コンポーネント・デバイスも、サーバー・デバイス２０１によって行われたインデックス化に基づいて、データをキャッシュするように動作することができる。ブランチ２０６におけるクライアント２１１からの同じデータに対する第２要求が、クライアント側ＷＡＮ最適化デバイス２０４によって受け取られると、クライアント側ＷＡＮ最適化デバイス２０４は、ＷＡＮ２０３を通って行く代わりに、単にそのキャッシュからデータを戻すことができる。
ＷＡＮ最適化装置に付随する問題
[0029] 図２に示したように、既存のＷＡＮ最適化システム２００は、一般に、サーバー端において、データ・センター２０２のような第１コンポーネント・デバイス２０１の設置を必要とし、更にクライアント端において、ブランチ・オフィス２０６のような第２コンポーネント・デバイス２０４の設置を必要とする。データ・センター２０２およびブランチ・オフィス２０６は、ワイド・エリア・ネットワーク（ＷＡＮ）２０３を通じて通信する。複数のブランチ・オフィス２０６を有する環境では、多数のクライアント側最適化デバイス２０４を設置する必要がある場合もある。

[0030] 多数のコンポーネント・デバイスの運用には、設置および保守にコストが嵩む。特に、ＷＡＮ最適化装置は、データ・トラフィックの非常に詳細な（即ち、高粒度の）調査を必要とするので、最適化システムの運用には、大量の処理オーバーヘッドが発生する可能性がある。更に、既存のＷＡＮ最適化装置の調査プロセスでは、データ部分の精細なレベルの粒度が必要となるので（即ち、最適化装置は、一般に、データを分類できるようにまたはデータに対してその他の動作ができるように、データがどのようなものか理解する必要がある）、ＷＡＮ最適化装置は、一般に、暗号化されたデータに対して動作することができない（例えば、IP Security、即ち、IPSecプロトコル、またはSecured Sockets Layer、即ち、ＳＳＬプロトコルのような、終端間暗号プロトコル(end-to-end encryption protocol)を用いてデータがネットワークを通じて送られる場合）。この場合、ＷＡＮ最適化装置は、このデータ・ストリームには動作することができないので、ＷＡＮトラフィックには何の影響も及ぼさなくてもよい（ＷＡＮ最適化装置のサーバー側コンポーネントは、暗号化データを理解することができず、したがって、既存のＷＡＮ最適化システムは、暗号化データを圧縮することや、インデックス化できない場合もある）。更に、ＷＡＮ最適化装置はデータを調査して理解する必要があるので、既存のＷＡＮ最適化装置を用いて端末間セキュリティを容易に設けることができない場合もある。また、ＷＡＮが公衆トラフィック（例えば、インターネットへの接続）を含む殆どの会社環境では、一般に、セキュリティは主要な関心事であるので、ＷＡＮ最適化装置は、有用な圧縮およびレイテンシーの利点を、安全を確保したトラフィック(secured traffic)（例えば、暗号化）には提供できないこともある。
ホスト・キャッシュを用いた最適化
[0031] 図３は、ブランチにあるクライアント・デバイスによるデータ引き出しを最適化するための終端間セキュリティを設けるコンピューティングシステム３００の一実施形態を示す。勿論、ＬＡＮを用いたブランチ構成の代わりに、図３は、ＷＡＮ（例えば、ラップトップ接続）を通じてサーバーからトラフィックを受信するためにＷＡＮに接続されているいずれのクライアント・デバイスにも等しく適用可能である。尚、クライアントという用語は、物理的なコンピューティングデバイス、またはサーバーにデータを要求するコンピューティングデバイス上で実行するクライアント・アプリケーションを意味するために用いることができることは、注記してしかるべきである。多数のアプリケーションを同じコンピューティングデバイスによって実行することもできる。

[0032] 図３のシステムの一般的な動作について説明する。データ・センター３０２は、アプリケーション・サーバー３１５を通じて、ブランチ３０６にあるクライアント３１１にデータを供給する。ブランチ３０６は、複数のクライアント・コンピューター３１１がローカル・エリア・ネットワーク即ちＬＡＮ３１０を通じて接続されている地理的場所を表すことができる。図２と同様、クライアント・コンピューター３１１はサーバー３１５と通信して、データ・センター３０２において格納および管理されているデータを要求し引き出すことができる。クライアント・コンピューター３１１は、ＬＡＮ３１０とＷＡＮ３０３との間にある接続を経由してデータを引き出すことができる。ＷＡＮへの接続は、ルーター３０８を経由してもよい。この実施形態では、ホスト・キャッシュ(hosted cache)３２０はブランチ３０６においてＬＡＮ３１０にも結合されている。ホスト・キャッシュ３２０は、特定のコンピューティングデバイス上に実装してもよいし、または、例えば、クライアントがピア・ツー・ピアの様式で動作するときには、複数のコンピューティングデバイスにおいて実装される分散キャッシュを表すこともできる（以下で更に論ずる）。ホスト・キャッシュ３２０は、ローカル・エリア・ネットワークを通じてクライアントに通信状態で結合することができる。実施形態の中には、ホスト・キャッシュが、データを要求するクライアント、例えば、クライアント３１１の内いずれかと同じデバイスに位置することもある。

[0033] 図３のクライアント３１１は、データ要求をサーバー３１５に送るようにプログラミングすることができる。アプリケーション・サーバー３１５は、データを要求しているクライアント３１１がホスト・キャッシュ３２０を使用することを許可されている(enabled)か否か判断するようにプログラミングすることができる。次いで、アプリケーション・サーバー３１５は、クライアント３１１によって要求されたデータ、またはクライアント３１１によって要求されたデータを具体的に識別する識別子のリストを供給することができる。アプリケーション・サーバー３１５は、識別子を発生することができ（例えば、アルゴリズムを用いて）、または他のコンピューティングエンティティまたはアプリケーション（例えば、データベース管理システム）が識別子を発生し、アプリケーション・サーバーによる引き出しのためにこれらをある場所（例えば、データ・センターにおけるデータベース）に格納することができる。識別子の一例には、ハッシュ関数によって生成するハッシュがあり、ハッシュは要求されたデータの指紋として機能することができる（以下で更に論ずる）。サーバーがデータベース３１７に接続されている場合、ハッシュをデータと共にデータベース３１７に格納することができ、あるいはサーバー３１５によってデータとしてハッシュされたものがクライアントへの送信のために引き出される。

[0034] 一部のクライアント３１１には、ホスト・キャッシュ３２０を用いることを許可しつつ、一方では一部のクライアント（例えば、旧式のコンピューティングデバイスやシステム）には許可しなくてもよい。クライアント３１１がホスト・キャッシュ３２０を用いることを許可された場合、このクライアント３１１は、アプリケーション・サーバー３１５からの要求データ、または要求データに対応する１組のハッシュをアプリケーション・サーバー３１５から受信するようにプログラミングすることができる。クライアント３１１は、アプリケーション・サーバー３１５の代わりに、キャッシュされているデータをホスト・キャッシュ３２０から引き出すためにハッシュを用いるように構成することができる。ホスト・キャッシュ３２０は、対応するハッシュによってインデックス化された受信データ３２６を格納するようにプログラミングすることができる。ハッシュは、レコード・キー３２７としての役割を果たすことができる。ホスト・キャッシュ３２０は、更に、ハッシュ値即ちキー３２７に対応するデータ３２６を引き出して戻すようにプログラミングすることができる。ホスト・キャッシュ３２０は、表３２５または他のプログラム・オブジェクトのような、いずれの周知の作表方法を用いても、インデックス化されたデータを格納することができる。
ハッシュ関数およびハッシュ・インデックス化
[0035] ハッシュ関数は、一般に、ある種のデータを受け取り比較的小さな値（例えば、小さな整数）を出力するアルゴリズムまたは明確な(well-defined)手順である。ハッシュ関数によって戻される値をハッシュ値、ハッシュ・コード、ハッシュ和(hash sum)、または単にハッシュと呼ぶことができる。更に、個々のハッシュ関数に応じて、ハッシュはデータ部分（例えば、セグメント、パケット、ブロック等）の統計的に一意の指紋を備えることができる。場合によって、これらのハッシュ関数を暗号ハッシュ関数と呼ぶこともある。ハッシュ指紋は、ハッシュに対応するデータについてデータ完全性分析を実行するために用いることができる。例えば、ハッシュに基づいてデータを戻すとき、このデータを同じハッシュ関数（分かっている場合）に入力してハッシュを戻すことができる。ハッシュが一致した場合、受信したデータが、ハッシュを生成するために用いられたデータと同じであるという統計的に高い確率があると考えられる。

[0036] ハッシュ関数は、データベースにおいて項目を見つける、大きなファイルにおいて重複しているレコードまたは同様のレコードを検出する、データ・シーケンスにおいて同様のストレッチ(stretch)を見つける等のような、表の調査またはデータ比較作業を高速化するために用いることができる。特に、ハッシュ関数は比較的一意の（例えば、データ範囲について一意）インデックスを小さな数値フォーマットで与えるので、ハッシュ値を読み取り、ハッシュ値に基づいてインデックス化する際、一般に、要する処理時間を短縮することができる。
ホスト・キャッシュの動作
[0037] 本システムの一実施形態では、ホスト・キャッシュ３２０はハッシュ・テーブル３２５を収容することができる。ハッシュ・テーブル３２５は、受信データ３２６をハッシュ値３２７によってインデックス化するときに用いられる。ホスト・キャッシュ３２０は、例えば、データ・ベース・テーブルとして維持することができ、あるいはハッシュ値によってデータを引き出すことができるその他の掲載機能またはレジストリ(registry)として維持することもできる。当技術分野において知られている引き出しメカニズム（例えば、クエリー言語コール）であればいずれでも、ハッシュ値（例えば、ＳＱＬ）に基づいてデータを求めるためにホスト・キャッシュに問い合わせるために用いることができる。

[0038] 一実施形態では、ハッシュ関数は、公開および／または秘密鍵対に基づく暗号化アルゴリズムであってもよい。このように、ハッシュは、暗号鍵に結び付けられたデータ部分の暗号的に一意の識別子（ＣＵＩ）を表すことができる。公開−秘密鍵対暗号化の実施態様は、当技術分野では一般に周知である。公開−秘密鍵対暗号化を用いる一実施形態では、クライアントが暗号鍵を必要としない場合もある。例えば、クライアントがサーバーから受け取ったハッシュ値を単にホスト・キャッシュに受け渡す場合、クライアントが暗号鍵を持ち運ぶ必要はないと考えられる。別の例では、データ完全性をチェックする場合、クライアントは暗号鍵を暗号アルゴリズムと共に用いて、サーバーから戻されたデータがハッシュに対応することを検証することができる。勿論、暗号鍵を伴わないハッシュ関数も、データ完全性機能をチェックするために用いることができる。

[0039] ホスト・キャッシュ・インデックス化方式の一実施形態では、図４において更に詳細に示すような、特定のレコード・フォーマットを用いる。図４のインデックス化の実施形態では、インデックス化データ・ストア４００がレコード４０１を収容することができる。レコード４０１は、レコード・キー４０３によってインデックス化されたデータ部分４０２を有する。レコード・キー４０３は、このレコードのハッシュとすることができる（この場合、ハッシュは、本明細書に記載しているシステムにおいて用いられる共通のハッシュ関数に対応する）。レコード・キーまたはハッシュ４０３は、暗号的に一意の識別子（ＣＵＩ）とするとよい。ＣＵＩは２つの主要な特異性を有することができる。第１に、ＣＵＩは統計的に一意であることができる。共通のデータベース・インデックス化方式と同様に、レコード・キーは、表におけるエントリ全体の重複を防止するために一意である必要がある場合もある。したがって、ＣＵＩは、それが特定の状況またはアプリケーションに対して一意であることの確率が高くなるように、導出されたものであるとよい。例えば、前述したようなデータ・システムでは、ＣＵＩが統計的に一意となることができるのは、暗号的に一意の識別子が同じデータ部分から導出することができる確率が、ある範囲のデータ値においてありそうもない場合である。第２に、ＣＵＩは特定のユーザー・ハッシュ関数、例えば、サーバー、クライアント、およびホスト・キャッシュによって用いられる共通のハッシュ関数に対応することができる。ハッシュが鍵対暗号システムである状況では、ＣＵＩは、ハッシュを発生するために用いられる特定の暗号アルゴリズムの特定の公開または秘密鍵と対応することができる。例えば、ＣＵＩは、公開鍵から、暗号アルゴリズムを用いて導出することができる。実施形態の中には、アルゴリズムを用いてＣＵＩがその公開鍵と対応するまたは一致することを検証するとよい場合もある。

[0040] 図４のレコード４０１は、ハッシュ値によってインデックス化されたデータをキャッシュするために用いることができる。ＣＵＩレコード・ハッシュ・キー４０３は、各レコード４０１を突き止め、ハッシュ・キー４０３に対応するデータ部分４０２を引き出すために用いることができる。一実施形態では、レコード４１０はローカル・ネットワークに対して公開してもよい。即ち、インデックス化した情報は暗号化されていなくてもよい（恐らくは、ハッシュ・キーを除いて）。しかしながら、以下に記載する他の実施形態では、データ部分４０２またはレコード４０１を暗号化することができる。
多数のホスト・キャッシュ
[0041] 図５は、複数のホスト・キャッシュ３１２〜３２２を実装したシステムの実施形態を示す。この実施形態では、クライアント３１１は、最適化パラメーターの数に基づいて、ホスト・キャッシュ３２１〜３２２の内特定の１つと通信または相互作用することができる。例えば、企業(business enterprise)が、地理的近接度またはネットワーク近接度（例えば、キャッシュとクライアントとの間で通信するのに必要な最小限のネットワーク・ルーティングであるもの）に基づいてクライアント毎にホスト・キャッシュを設けることができる。更に、サブネットまたは他のネットワーク分割に基づいて、異なるホスト・キャッシュを設けることもできる。一実施形態では、多数のホスト・キャッシュを冗長性尺度として設けることができる。例えば、ホスト・キャッシュの内一部(subset)だけ（例えば、１つのホスト・キャッシュ）をアクティブに指定して、クライアントとの接続および相互作用に利用可能にすることができる。指定されたホスト・キャッシュ（１つまたは複数）で障害が発生した場合、冗長なホスト・キャッシュを活性化することができる。冗長な、インアクティブなホスト・キャッシュ（１つまたは複数）には、指定されたアクティブなホスト・キャッシュ（１つまたは複数）と同じ情報を収容すること、そしてその情報で更新することができる。例えば、データは、複数のホスト・キャッシュに跨って複製することができる。

ピア・ツー・ピア・ネットワークを用いた分散型ハッシュ・テーブル
[0042] 一実施形態では、クライアントはピア・ツー・ピア・ネットワークの一部であってもよい。図６は、分散型ホスト・キャッシュ(distributed hosted hash)６００を実装するピア・ツー・ピア・ネットワークを用いる一実施形態を示す。この分散型ホスト・キャッシュは、サーバー−独立永続的インデックス化システムを表すことができる。分散型キャッシュ６００は、ピア・ツー・ピア・ネットワーク６０５を形成するピア・エンティティ６０１〜６０４のグループ全体にわたって維持することができる。分散型ホスト・キャッシュ６００の中にあるレコードは、例えば、ハッシュ関数を用いて、論理的に分割または分類することができる。ハッシュ関数は、引き出しを一層効率的に行うことができるように、ある論理的な順序でエントリを一緒に分類またはクラスタ化することができる。ハッシュ関数は、編成された態様でレコードを互いに凝集することによって、引き出しを一層効率的にすることができる。分散型ホスト・キャッシュは、２つの主要な固有性を有することができる。その固有性とは、１）ノード６０１〜６０４のような複数のノード／クライアント／ピア間でのレコード内容の分散、および２）レコードを公開し引き出すための方法を提供するルーティング・メカニズム（図示せず）である。

[0043] 図６の実施形態では、サーバーは、情報を要求するクライアント６０１〜６０４のいずれの１つにでも、データのハッシュを供給するために、前述のように構成することができる。次いで、クライアントは、ハッシュを含むブロードキャスト要求メッセージをピア・ツー・ピア・ネットワーク６０５に送り、ピア・ツー・ピア・ネットワークにおいて、ハッシュに対応するデータを収容しているピア・ノードを突き止めることができる。ピアが以前にデータを要求し格納している場合、このピアが要求に回答して、ブロードキャスト・メッセージを送ったピアにそのデータを供給することができる。このように、ホスト・キャッシュは、ピア・ツー・ピア・ネットワークの複数の異なるピア（ピア・ノード）に跨って維持することができる。つまり、ブランチにあるクライアントは、アプリケーション・サーバーが提供したハッシュに基づいて、要求されたデータを戻すことができる。この実施形態では、ピア・ツー・ピア・ネットワークにおけるピアは、協調してデータをキャッシュすることができる。ピア・ツー・ピアの実施形態についてこの章では記載しているが、本方法およびシステムは、ピア・ツー・ピア・ネットワークを伴わないプロトコルを含む、いずれのクライアント−サーバー・プロトコルにおいても用いることができることは注記してしかるべきである。

[0044] 図７は、分散型ホスト・キャッシュを用いない、別のピア・ツー・ピア・ネットワークの実施形態を示す。多数のピアに跨ってホスト・キャッシュを実装して、各ピアがデータのコピーまたはそのデータの一部を格納する代わりに、１つのピア７０１を選択して、唯一のホスト・キャッシュ（これをスーパー・ピアと呼ぶこともできる）に指定することもできる。クライアント／ノード／ピア７０２〜７０４は、ホスト・キャッシュのサービスおよび情報を求めて、１つのピア７０１に頼るようにプログラミングすることができる。しかしながら、クライアント７０２〜７０４の各々は、キャッシュをホストすることができ、冗長性またはフェイルオーバーの目的でそうすることができる。この実施形態では、１つのピアをホスト・キャッシュとして指定または選択する際に、数個のパラメーターを考慮するとよい。例えば、指定は、ピアの作業負荷(workload)、ピアの処理能力、および／またはピアの記憶容量に基づくことができる。

[0045] 図７では１つのピアだけのホスト・キャッシュに指定しても、ピア・ツー・ピア・ネットワーク７０５においてクライアント（７０２〜７０４）として活動する各ピアは、それ自体のホスト・キャッシュを維持することができる。この構成では、クライアント・ピア（例えば、７０１〜７０４）は、サーバーにデータを要求し、サーバーから１組のハッシュを受け取り、そのローカル・キャッシュがデータを含むか否か最初にチェックすることができる。ピアのローカル・キャッシュがそのデータを収容していない場合、ピアは、指定されたホスト・キャッシュ・ピアを検索することができる。別の実施形態では、ピア７０１の障害の場合、ピア・ツー・ピア・ネットワークにおける他のピア（例えば、７０２〜７０４）が分散型ホスト・キャッシュ・モデルに切り替わることができ、これらはピア・ネットワークのローカル・キャッシュを検索してデータを求め始めることができる（即ち、分散型ホスト・キャッシュ・モデル）。

[0046] ホスト・キャッシュは、個々のクライアント構成に基づいて、多数の方法で実装することができる。先に論じたように、ホスト・キャッシュは、ピア・ツー・ピア・ネットワーク上に実装する必要はない。ホスト・キャッシュは、オペレーティング・システムのコンポーネントとして、またはコンピューティングデバイス上で一般的に実行するプロセスとして実装することもできる。例えば、ホスト・キャッシュは、Microsoft Windowsオペレーティング・システムのコンポーネントとして実装することもできる。

[0047] ホスト・キャッシュ・サービスは、ハッシュ・インデックス化に基づいてデータを戻すという目標の機能(focused function)を提供する。データの暗号化を実施しなくてもよい場合もある。何故なら、ホスト・キャッシュは一般にブランチにおいて信頼を得られたエンティティであるからである。しかしながら、実施形態の中には、特定の実施態様にとって適しているのであれば、いずれかの利用可能な暗号方式を用いて、キャッシュの暗号化を実施する場合もある。例えば、正規のユーザーだけにホスト・キャッシュへのアクセスを付与できるように、ホスト・キャッシュに対して認証または許可方式を実施することもできる（例えば、ホスト・キャッシュから読み取るため、そしてホスト・キャッシュに書き込むために付与されるアクセス）。尚、このセキュリティは、例えば、ＬＡＮ上において、ブランチ全体に実施するとよいことは注記してしかるべきである。

[0048] データ送信のために、前述のシステムを用いて異なるプロセスを実施して、終端間セキュリティに備えることもでき、これによってレイテンシーが改善する。

[0049] 図８は、前述のシステムを用いて実施することができるこのようなプロセスの一実施形態を示す。即ち、アプリケーション・サーバー３１５のようなサーバーが、ネットワークを通じてクライアントからデータ要求メッセージを受信することができる（８０１）。サーバーは、クライアントがホスト・キャッシュを用いることを許可されているか否か判断することができる（８０２）。一実施形態では、クライアントの要求は、ヘッダー、またはクライアントがホスト・キャッシュを用いることを許可されていることを示す他の指示を含むことができる。別の実施形態では、サーバーは、ストア（レジストリのような）においてクライアントを参照することによって、クライアントがホスト・キャッシュを用いることを許可されているか否か調べるようにプログラミングすることができる。この実施形態では、クライアントはサーバーにクライアントの識別を（例えば、クライアントからの要求メッセージの中にある識別子を通じて）通知することができる。クライアントがホスト・キャッシュを用いることを許可されていないとサーバーが判断した場合、サーバーは、要求されたデータを供給することによって、この要求を処理することができる（８０３）。クライアントがホスト・キャッシュを用いることを許可されているとサーバーが判断した場合、サーバーは、データ自体の代わりに、データのハッシュを供給することができる（８０４）。別の実施形態では、サーバーは、ホスト・キャッシュを用いることを許可されているクライアントの集合体を参照することができる。

[0050] 実施形態の中には、サーバーがその応答をクライアント要求に対して送信する前にまたは送信しつつ、追加の最適化技法を採用することができる場合もある。例えば、サーバーは複数の応答（ハッシュおよび／または要求データ）を集めて、１つ又複数のパラメーター（例えば、監視／測定したネットワーク・帯域幅、スケジュール等）に基づいてそれらを送信することができる。また、サーバーは、ハッシュ関数に基づいて、１組のハッシュを並べることもでき、ハッシュ関数は、この1組のハッシュの編成（例えば、連続または順序）を規定する。また、サーバーは、１組のハッシュに基づいて、データ送信に優先順位を付けることもできる。

[0051] 一実施形態では、サーバーは、ハッシュを用いてそのデータをインデックス化するように構成することができる。例えば、サーバーは、サーバーがアクセスすることができるデータ・ファイルに対して、ハッシュ関数を用いてハッシュを発生することができる。別の実施形態では、別のデバイスまたはプログラムが、ハッシュ関数を用いて、データをハッシュし、これらのハッシュをサーバーまたは他の要求元デバイス（例えば、クライアントまたはホスト・キャッシュ）に利用可能にすることができる。ハッシュは、これらのハッシュを発生するために用いられるデータに対するインデックスとして作用することができる。更に、ハッシュ自体が、データの完全性を検証するメカニズムを備えている（以下で更に論ずる）。一実施形態では、サーバーは、要求されたときにだけ、要求データに対してハッシュ関数を実行することもできる。別の実施形態では、ハッシュ処理は、要求とは独立して実行することもできる（例えば、いずれのデータ要求を受ける前でも、そのデータをハッシュすることができる）。
ステートフル・サーバーの実施形態
[0052] 前述の実施形態では、サーバーは、クライアントとの以前のトランザクションに関してステートレスであってもよい（例えば、クライアントのデータ要求に対する以前の回答）。言い換えると、サーバーは、いずれの特定のデータにしても、当該サーバーがそれをクライアントに供給したということの指示を覚えていなくても、あるいは格納しなくてもよい。サーバーが状態を維持する実施形態では、サーバーは、クライアントによって要求されているデータをホスト・キャッシュが既に格納している可能性が高いか否か判断するように構成することができる。例えば、サーバーは、特定のデータが既に要求されてブランチにあるクライアントに送られているか否か指示する情報を格納するようにプログラミングすることができ、このクライアントには、ホスト・キャッシュを用いることを許可されていることが分かっている。同じデータに対する要求を後に受けたとき、サーバーは、この後からの要求を行ったクライアントに、単にデータのハッシュ（１つまたは複数）だけを供給するようにプログラミングすることができる。この動作は、ホスト・キャッシュが、以前に要求されたデータを既にキャッシュしていると仮定して、プログラミングすることができる。サーバーが、要求された１組のデータを以前に送ったこと（またはデータが既に要求されたまたは供給されたことを示す情報を格納したこと）を覚えていない場合、そのデータを要求元クライアントに供給するようにサーバーをプログラミングすることができる。このように、更なるレイテンシーの改善を実現することができ、アプリケーション・サーバー、ホスト・キャッシュ、またはクライアントのいずれとの間におけるある種の相互通信も削減または回避することができる。この実施形態では、サーバーは、クライアントがホスト・キャッシュを許可されているか否か判断することなく動作するように構成することができる。代替実施形態では、サーバーは、クライアントがホスト・キャッシュを許可されているか否かチェックするのであってもよい。これは、旧式のアプリケーションおよびデバイスを有する混成ネットワークにおいて、ホスト・キャッシュを用いることを許可されることができず、サーバーが特定のクライアントのみに（即ち、ハッシュなしで）送る(send only send)ことが必要となる場合にも、用いることができる。この場合、サーバーは要求データをブランチのクライアントに送っており、要求データをローカル・キャッシュに格納することができても、旧式のデバイスはなおも動作のために実際のデータを戻す必要がある。

[0053] 図９は、ブランチにおいて本システムを用いるプロセスを示す。データを要求するクライアントが、サーバーから応答メッセージ（１つまたは複数）を受け取ることができる（９０１）。この応答は、クライアントが要求したデータ、または実際のデータ集合は含まず、要求されたデータに対応する１組のハッシュを含むことができる。ブロック９０２において、クライアントは、応答がデータを含むか、またはデータなしで１組のハッシュを含むか判断するようにプログラミングすることができる。クライアントが、サーバーからの応答が要求した実際のデータを含むと判断した場合、クライアントはデータを消費し（９０３）、このデータのコピーをホスト・キャッシュに格納することができる（９０４）。ホスト・キャッシュは、ハッシュ値によってインデックス化されたデータを格納することができる。ハッシュ値は、サーバーによって発生すること、または実際のデータと共に受け渡すこと（例えば、ブロック９０１において）のいずれでも可能である。あるいは、クライアントはデータをハッシュして、これらのハッシュを実際のデータと共にホスト・キャッシュに供給することもできる。更に別の実施形態では、ホスト・キャッシュがデータをハッシュすることもできる。どのエンティティがハッシュ機能を実行するかには関係なく、ハッシュは、ホスト・キャッシュによって格納されているデータをインデックス化するために、ホスト・キャッシュによって用いることができる。更に、これらのエンティティのいずれによって用いられるハッシュ関数も（１つよりも多いエンティティがハッシュ機能を実行している場合）、全て同一であってもよい。

[0054] クライアントが、実際の１組のデータなしで１組のハッシュを受信した場合、クライアントは、ハッシュに基づいて、ホスト・キャッシュに問い合わせてデータを求めることができる（９０５）。ホスト・キャッシュは、１組のハッシュに対応するデータをそれが有するか否か判断することができる（９０６）。ホスト・キャッシュがそのデータを収容している場合、クライアントは、それがアプリケーション・サーバーから受信したハッシュに基づいて、ホスト・キャッシュからデータを引き出すことができる（９０７）。オプションとして、クライアントは、ハッシュを用いて、ホスト・キャッシュによって受信されたデータに対してデータ完全性チェックを実行することもできる（９０８）。当業者にはお分かりであろうが、ハッシュは、当該ハッシュを発生するために用いられるデータの一意の指紋を与える。つまり、クライアントがホスト・キャッシュから受け取るデータの完全性および識別を検証する１つの方法は、ホスト・キャッシュからのデータに対して同じハッシュ関数（例えば、ハッシュを供給したサーバーとホスト・キャッシュとの間で共通であることが分かっているハッシュ関数）を実行して、そのデータから同じハッシュが得られるか否か確認することである。同じハッシュが得られた場合、そのデータの完全性および識別が検証できたことになる。データが検証され有効であると判断された場合（９０９）、クライアントは、ブロック９１０において、引き出したデータを消費することができる。データが検証されず、つまり無効でない(not invalid)場合、サーバーから１組のデータを引き出すことができ、サーバーから引き出した新たなデータで、ホスト・キャッシュを更新することができる（９１１）。

[0055] ホスト・キャッシュが要求データを収容していない場合、ホスト・キャッシュに１組のデータを入力し（９１１）、この１組のデータをクライアントに供給する（９１２）には、様々な方法を実施することができる。一実施形態では、ホスト・キャッシュは、クライアントによって要求されたがそれが現在格納していないデータを引き出す機能を実施することができる。例えば、アプリケーション・サーバーにデータを要求するように、ホスト・キャッシュをプログラミングすることができる。この場合、アプリケーション・サーバーは、そのデータをホスト・キャッシュに、ハッシュと共にまたはハッシュなしで、戻すことができ、次いで、ホスト・キャッシュは要求データを要求元のクライアントに供給することができる。次いで、ホスト・キャッシュは、新たなデータを、サーバーから受信したハッシュと共に、またはデータに基づいてそれが発生したハッシュに基づいて格納することができる。ホスト・キャッシュおよびサーバーが用いたハッシュ関数が同一である場合、この実施形態の方法およびシステムは、後の引き出しのために、同じハッシュ・インデックスをクライアントに供給するように動作することができる。

[0056] 別の実施形態では、クライアントは、ホスト・キャッシュに格納されていないデータをアプリケーション・サーバーから引き出す責務(responsibility)を担うこともできる。例えば、ホスト・キャッシュがメッセージをクライアントに戻して、クライアントが送ったハッシュに基づいて、ホスト・キャッシュが、クライアントが要求したデータを現在格納していないことを示すと、クライアントは、そのデータを求めて、第２の要求をアプリケーション・サーバーに送ることができる。この状況では、クライアントは、この第２の要求と共に、ホスト・キャッシュが要求データを収容していないことの指示も、アプリケーション・サーバーに送ることができる。一実施形態では、クライアントがホスト・キャッシュを用いることを許可されていないことを示すことによって、これを実行することができる。この状況では、アプリケーション・サーバーは単に要求データをクライアントに供給することができ、クライアントはこのデータをホスト・キャッシュにプッシュすることができる。このデータは、サーバー、クライアント、またはホスト・キャッシュのいずれかによってハッシュすることができる。別の実施形態では、ホスト・キャッシュが現在要求データを有していないかもしれないという指示を、別の指示として送ることもできる。例えば、クライアントからアプリケーション・サーバーへの第２の要求におけるヘッダーは、クライアントがホスト・キャッシュを用いることを許可されていること、およびホスト・キャッシュが要求された情報を含んでいないことの双方の指示を含むことができる。この例では、サーバーは、要求されたデータ、およびこの要求されたデータのハッシュを戻すことができる。

[0057] 一実施形態では、最初のクライアント要求に基づいてホスト・キャッシュに最初から入力するのを待つ代わりに、ホスト・キャッシュに、高いアクセス率を有することが分かっている１組のデータを予め入力しておいてもよい。これは、システム・ダウンタイムの間に予定したロードによって、行うことができる。

[0058] ホスト・キャッシュのデータ管理は、タイム・スタンプによって、ホスト・キャッシュの中にあるデータの周期的浄化によって行うことができる。例えば、各データ・セグメントまたはブロックに、ある数の変数（作成日、受信日等）で時間コードを付けることができる。タイム・スタンプから存在期間が経過したときに、そのデータ・ブロックを削除することができる。これによって、データを比較的新鮮に保つメカニズムが設けられる。例えば、データを削除すると、そのデータは（要求されたときには）、後になってから新たなバージョンでアプリケーション・サーバーからダウンロードされる。ハッシュされたデータについて注記すべき重要なことは、複数のハッシュによって１つのファイルがインデックス化されることもあるということである。更に、２つ以上のファイルが、同じハッシュを収容している共通のデータ・ブロックを有する場合もある。データは、データ・ブロック毎に浄化される場合があり、したがって、データ・ファイルは削除された部分の一部を収容していることがある。削除された部分は、アプリケーション・サーバーから新たに引き出し直す必要がある場合がある。

[0059] 図１０に示す実施形態では、各レコードに失効パラメーター１００１を含ませることができる。レコードは、これらが公開者(publisher)によって削除されるまで、または失効パラメーターに基づいてこれらが失効するまで、ホスト・キャッシュに永続することができる。この失効パラメーター１００１は、データが有効である期間に対応することができる。失効パラメーター１００１は、レコードについて有効性の失効を示すことができる。つまり、失効パラメーター１００１は、図９に示したような引き出しプロセスにおいて用いることができる。例えば、ブロック９０９において、失効パラメーター１００１によって示される期限をチェックして、失効になっているか否か判断することができる。失効パラメーター１００１が過ぎている場合、レコードは無効であると考えられ、ブロック９１１を用いて、サーバーから新たなデータを引き出すことができる。それ以外の場合、レコードは有効であり、クライアント９１０によって消費することができる。
ホスト・キャッシュ発見プロセス
[0060] ホスト・キャッシュは、発見プロトコルと共に実装することもできる。発見プロトコルは、ネットワーク上においてホスト・キャッシュの存在を検出する能力をクライアントに提供するのに適したプロトコルであればいずれでもよい。発見メカニズムは、明示的でも自動でもよい。例えば、明示的発見プロトコルでは、登録されているホスト・キャッシュ（１つまたは複数）であればそのいずれに関する情報を提供するレジスタにも、クライアントを誘導することができる。あるいは、明示的な発見は、各コンピューティングデバイスを特定のホスト・キャッシュに導くグループコンピューティング方針(group computing policy)またはスクリプトを用いて実現することもできる。自動発見の実施形態では、接続するクライアントに、このクライアントにアクセス可能なネットワーク・セグメント上にあるホスト・キャッシュの存在に関する情報をプッシュすることができる。尚、地理的に互いに近接する位置に複数のクライアント・マシンを含むブランチにクライアントを接続することができても、これらのクライアント・マシンはドメインまたはサブネットに区分され、これらのドメインまたはサブネット内またはその間でのアクセスが制限されている場合もあることは注記してしかるべきである。

[0061] 一実施形態では、ホスト・キャッシュを用いることを許可されたクライアントは、所定の発見プロトコルを用いて、ホスト・キャッシュが当該クライアントのネットワーク上で利用可能か否か判断することができる。言い換えると、クライアントは、ネットワークに接続するときに、特定の発見プロトコルを用いて通信するようにプログラミングすることができる。１つ注意しておくと、クライアントはクライアント・アプリケーションまたはクライアント・デバイスを表すこともできる。代替実施形態では、クライアントは、ネットワークに接続するときに、それ自体の可用性または存在を公開する責務がある場合もある。また、発見プロトコルは、クライアントの存在を公表するメカニズムも備えることができ、通信ドメインに基づいて、クライアントおよびホスト・キャッシュが互いを意識するようにさせる。例えば、クライアントが移動体（例えば、ラップトップ）であるように構成されている場合、クライアントは第１ネットワークまたは第２ネットワークに接続することができ（ドメインまたはサブネットに基づいて）、各ネットワークは別のホスト・キャッシュを有することができる。いずれの場合でも、発見プロトコルは、クライアントと共に動作して、クライアントを直接接続するホスト・キャッシュをネットワークにおいて提供するように構成することができる。
最適化監視
[0062] ホスト・キャッシュおよび対応するサーバーのシステム上においてデータ・トラフィックを監視することによって、記載したシステムに更なる最適化を行うこともできる。例えば、監視することができるデータ送信パラメーターの中には、クライアントからのデータ要求のレイテンシーが含まれる。別の変数を挙げると、クライアントによるホスト・キャッシュへのアクセス頻度に対するＷＡＮ接続を通じたアクセスの回数がある。データ・トラフィックの監視および記録ならびに分析によって、ネットワーク管理者が、記載した本方法およびシステムの動作パラメーターを調節することを可能にすることができる。例えば、監視データに基づいて、管理者は、オフピーク時の間にどのデータを予め入力しておけばよいか発見することができる。
既存のＷＡＮ最適化装置との統合
[0063] 一実施形態では、クライアント側ＷＡＮ最適化デバイスは、ホスト・キャッシュとして動作するように構成することができる。この実施形態では、サーバー側ＷＡＮデバイスは不要である。

一実施形態では、ＷＡＮ最適化デバイスは、ホスト・キャッシュに加えて用いることもできる。ＷＡＮ最適化装置は一般に暗号化ファイルを扱うことができないので、ＷＡＮ最適化装置は、データが暗号化されて送信されていないときにはいつでも、クライアントとサーバーとの間における一般的なデータまたはファイルのアクセスに用いることができる。暗号化データについては、ホスト・キャッシュの実装を用いることができる。この構成は、旧式のシステムまたはデバイス、例えば、ホスト・キャッシュを認識するまたはこれと通信するように構成されていないデバイスを有するネットワークにおいて行うことができる。別の実施形態では、クライアントがホスト・キャッシュを用いることができない場合、既存のＷＡＮ最適化システム（例えば、サーバーおよびクライアント側双方にＷＡＮ最適化コンポーネント・デバイスを含むもの））を用い、一方ホスト・キャッシュを用いることができるクライアントはそうすればよい。サーバーは、データ要求メッセージに埋め込まれている情報を通じて（例えば、前述のようにヘッダーを通じて）、クライアントの要求にどのように応答すればよいか判断することができる。

[0064] 特許請求する方法およびシステムを用いることの利点は、ＷＡＮのサーバーおよびクライアント側双方において２つのコンポーネント・ボックスを含み維持する必要性を低減できることである。これによって、保守コストを削減する。更に、既存のＷＡＮ最適化システムによって得られるレイテンシーの改善を達成および／または凌駕しつつなおも、暗号化データをＷＡＮを通じて送ることができる。記載した本方法およびシステムの別の利点は、インデックス化および圧縮を行うためにデータの詳細な調査を行う際に必要とされる処理容量の減少である。言い換えると、ＷＡＮ最適化装置がデータをインデックス化する際、粒度が細かい程大きな処理容量が必要となる。一方、特許請求する方法およびシステムは、データに基づいてハッシュを発生し、ハッシュ処理機能(hashing function)は一般に効率的であり、多くの処理オーバーヘッドを必要としない。

[0065] 記載した本方法およびシステムの別の利点は、ＷＡＮ上においてクライアントとサーバーとの間に仲介デバイスの必要性を全体的に排除したことである。代わりに、記載した本方法およびシステムは、安全を確保したブランチ環境の境界内に収容されたホスト・キャッシュを用いる。キャッシュに要求データが入力されていない状況について疑問が生ずる。この場合、クライアントとアプリケーション・サーバーとの間で取り決めた何らかの態様でデータを送ればよい。言い換えると、データは暗号化されていても、暗号化されていなくてもよい。中間において人間を排除することは、ＷＡＮを通じてクライアントとサーバーとの間においてあらゆる動作部(working parts)を除去することを指す。

[0066] 別の利点は、プロトコルに依存しないことである。既存のＷＡＮ最適化装置は、動作するためには、多数の異なるプロトコルを用いるようにプログラミングする必要がある場合もある。本願の方法およびシステムは、サーバーとクライアントとの間で用いられる既存のプロトコルを通じて、ハッシュを単に送るだけでよい。

Claims (20)

1. 第１のネットワークの帯域幅利用を低減する方法であって、
   第１のリクエスト・メッセージを前記第１のネットワークを経由してクライアントからサーバーへ送信するステップであって、
   前記第１のリクエスト・メッセージは、前記クライアントはホスト・キャッシュを用いるようにイネーブルされているという指示を含み、
   前記第１のリクエスト・メッセージは、複数のデータ部分に対する複数のハッシュをリクエストし、
   前記複数のデータ部分はそれぞれが、リクエストされた前記複数のハッシュの中に対応するハッシュを有し、
   前記複数のハッシュの中のそれぞれのハッシュは、当該ハッシュを生成するのに用いられる対応するデータ部分へのインデックスとして動作可能であり、また、前記対応するデータ部分に対するデータ・インテグリティを検証するように動作可能である、ステップと、
   前記ホスト・キャッシュが前記リクエストされた複数のデータ部分を格納している可能性が高いとの判断に応答して、前記クライアントによって、前記複数のデータ部分を含まない前記複数のハッシュを前記第１のネットワークを経由して受信するステップと、
   前記ホスト・キャッシュが前記リクエストされた複数のデータ部分を格納している可能性が低いとの判断に応答して、前記クライアントによって、前記複数のデータ部分を前記第１のネットワークを経由して受信するステップと、
   前記クライアントによって、第２のネットワークを経由して、前記受信された複数のハッシュに基づいて、前記複数のデータ部分の少なくとも第１のデータ部分に関して、前記ホスト・キャッシュに問い合わせをするステップであって、前記第２のネットワークは前記クライアントと前記ホスト・キャッシュとを前記第１のネットワークとは独立に通信状態で接続することができる、ステップと、
   を含む方法。
2. 請求項１記載の方法において、前記第１ネットワークはセキュアード・ソケット・レイヤ・プロトコル（ＳＳＬ）を実行する終端間で安全が確保されたネットワークである、方法。
3. 請求項１記載の方法であって、
   少なくとも前記第１のデータ部分に関して前記ホスト・キャッシュに問い合わせるステップの後で、前記ホスト・キャッシュは前記第１のデータ部分を含まないと判断するステップと、
   前記ホスト・キャッシュは前記第１のデータ部分を含まないと判断した後で、前記第１のデータ部分に関する前記ホスト・キャッシュによる第２のリクエストを前記サーバーに送るステップと、
   を更に含む方法。
4. 請求項１記載の方法であって、
   少なくとも前記第１のデータ部分に関して前記ホスト・キャッシュに問い合わせるステップの後で、前記ホスト・キャッシュから、前記ホスト・キャッシュは前記第１のデータ部分を含まないという指示を受信するステップと、
   前記ホスト・キャッシュは前記第１のデータ部分を含まないという指示を受信するステップの後で、前記クライアントによって、第２のリクエストを前記サーバーに送るステップであって、前記第２のリクエストは前記第１のデータ部分に対するリクエストを含む、ステップと、
   を更に含む方法。
5. 請求項１記載の方法において、前記ホスト・キャッシュは前記データ部分のそれぞれと関連する失効パラメーターを格納しており、前記失効パラメーターはそれぞれのデータ・ブロックに対する有効期間を示す、方法。
6. 請求項１記載の方法であって、前記第２のネットワークを経由して接続されている複数のクライアントに跨って格納された分散型ハッシュ・テーブルとして前記ホスト・キャッシュを実装するステップを更に含む方法。
7. 請求項１記載の方法であって、暗号化アルゴリズムに基づいて前記複数のハッシュを生成するステップを更に含み、前記１組のハッシュは前記ホスト・キャッシュによってキャッシュされているデータ部分に対して統計的に一意的であるように生成される、方法。
8. 請求項１記載の方法であって、
   少なくとも前記第１のデータ部分に関して前記ホスト・キャッシュに問い合わせるステップの後で、少なくとも前記第１のデータ部分を前記クライアントにおいて前記ホスト・キャッシュから受信するステップと、
   少なくとも前記第１のデータ部分を受信した後で、前記第１のデータ部分を検証するステップであって、
   前記第１のデータ部分に対してハッシュ関数を実行し、ハッシュ関数の結果を生じるステップと、
   前記ハッシュ関数の結果が、前記第１のデータ部分に関する対応するハッシュと一致するかどうかを判断するステップと、
   を含むステップと、
   を更に含む方法。
9. ネットワークの帯域幅利用を低減する方法であって、
   クライアントからの第１のリクエスト・メッセージをサーバーにおいて前記ネットワークを経由して受信するステップであって、前記第１のリクエスト・メッセージは、第１のハッシュ関数を用いて作成されるハッシュに基づいてデータにインデックスを付するホスト・キャッシュを用いるように前記クライアントがイネーブルされているという指示と、前記サーバーに格納されている１組のデータに関する指示と、を含む、ステップと、
   前記サーバーに格納されている前記１組のデータに対して前記第１のハッシュ関数を用いて１組のハッシュを生成するステップであって、前記１組のハッシュは第１のファイルに対する第１の複数のハッシュを含み、前記第１のファイルは第１の複数のデータ部分を含み、前記第１の複数のハッシュはそれぞれが前記第１の複数のデータ部分の対応するデータ部分を有し、前記１組のハッシュはそれぞれが前記１組のデータのそれぞれのデータ部分の統計的に一意的な指紋を表す、ステップと、
   前記サーバーにおいて、前記クライアントは前記ホスト・キャッシュを用いるようにイネーブルされていると判断するステップと、
   前記サーバーにおいて、前記ホスト・キャッシュが前記第１のリクエスト・メッセージにより指示された前記１組のデータを格納している可能性が高いか否か判断するステップと、
   前記ホスト・キャッシュが前記１組のデータを格納している可能性が高いとの判断に応答して、前記ネットワークを経由して前記サーバーによって前記クライアントに、前記１組のデータを含めずに前記１組のハッシュを送信するステップと、
   前記ホスト・キャッシュが前記１組のデータを格納している可能性が低いとの判断に応答して、前記ネットワークを経由して前記サーバーによって前記クライアントに、前記１組のデータを送信するステップと、
   を含む方法。
10. 請求項９記載の方法であって、前記１組のデータに対して前記１組のハッシュを生成するのに用いられたハッシュ関数に対応するハッシュ関数を、前記クライアントに提供するステップを更に含む方法。
11. 請求項９記載の方法であって、
    前記１組のデータを含まずに前記１組のハッシュを送信するステップに応答して、第２のリクエスト・メッセージを、前記ネットワークを経由して前記ホスト・キャッシュから前記サーバーにおいて受信するステップを更に含み、前記第２のリクエスト・メッセージは、前記サーバーに格納されている前記第１の複数のデータ部分の少なくとも第１のデータ部分に対する前記ホスト・キャッシュのリクエストを含む、方法。
12. 請求項９記載の方法であって、
    同じ１組のデータを求める第２のリクエスト・メッセージを前記クライアントから前記サーバーにおいて受信するステップを更に含み、前記クライアントは、前記第２のリクエスト・メッセージにおいて、前記ホスト・キャッシュは前記１組のデータを含まないという指示を提供する、方法。
13. 請求項９記載の方法において、前記クライアントがホスト・キャッシュを用いるようにイネーブルされていると判断するステップは、前記第１のリクエスト・メッセージにおける指示を読み取り前記クライアントがイネーブルされていると判断するステップを含む、方法。
14. １組のコンピューティングデバイスを含むワイド・エリア・ネットワーク上においてレイテンシーを低減するコンピューティングシステムであって、前記コンピューティングデバイスは、プロセッサと、前記プロセッサに動作的に結合されており前記プロセッサによって実行可能な命令を格納するメモリーとを含む、コンピューティングシステムにおいて、
    ハッシュ値によってインデックスが付されたデータを格納するように構成されているホスト・キャッシュと、
    クライアントとサーバーとを通信状態で結合する第の１ネットワークと、
    前記クライアントとホスト・キャッシュとを通信状態で結合する第２のネットワークであって、前記第２のネットワークは、前記第１のネットワークとは独立しており、前記第１のネットワークを用いずに、前記クライアントと前記ホスト・キャッシュとの間の通信を提供するように構成されている、第２ネットワークと、
    クライアントのリクエストに応答して、前記第１ネットワークを経由して、１組のデータ又は前記１組のデータに対応する１組のハッシュを送信するように構成されているサーバーであって、前記ホスト・キャッシュが前記リクエストに係る前記１組のデータを格納している可能性が高いか否か判断し、可能性が高いと判断した場合、前記１組のデータを含めずに前記１組のハッシュを送信し、可能性が低いと判断した場合、前記１組のデータを送信する、サーバーと、
    前記サーバーが前記１組のハッシュを送信した場合、前記１組のハッシュを受信し、前記受信された１組の対応するハッシュに基づいて、前記１組のデータに関して、前記第２のネットワークを経由して前記ホスト・キャッシュに問い合わせるように構成されているクライアントと、
    を備えているコンピューティングシステム。
15. 請求項１４記載のシステムにおいて、前記クライアントは、前記サーバーが前記１組のデータを送信すると、前記１組のデータを受信し、ハッシュ値にしたがって前記１組のデータのコピーを前記ホスト・キャッシュに格納するように構成されている、システム。
16. 請求項１４記載のシステムにおいて、前記ホスト・キャッシュは、更に、前記ホスト・キャッシュが前記リクエストされたデータを含まないときには、前記クライアントによってリクエストされた１組のデータに対するリクエストを前記サーバーに送るように構成されている、システム。
17. 請求項１４記載のシステムにおいて、前記クライアントは、更に、前記ホスト・キャッシュが前記リクエストされたデータを含まないときには、前記１組のデータに対するリクエスト前記サーバーに送るように構成されている、システム。
18. 請求項１４記載のシステムにおいて、
    前記サーバーは、更に、ハッシュ関数を用いて前記ハッシュを発生するように構成されており、
    前記クライアントは、更に、前記サーバーと同じハッシュ関数を用いて、前記ホスト・キャッシュから受信されたデータをハッシュすることによって、前記ホスト・キャッシュから受信されたデータを検証するように構成されている、システム。
19. 請求項１４記載のシステムにおいて、前記サーバーは、更に、クライアントに既に送信された前記１組のデータを追跡し、同じ１組のデータに対する別のリクエストに応答して、前記１組のデータの代わりに、前記１組のデータに対応する１組のハッシュを送信するように構成されている、システム。
20. 請求項１記載の方法において、前記第１のネットワークは、ＩＰセキュリティ（ＩＰＳｅｃ）プロトコルを動作させ終端間で安全確保されたネットワークである、方法。

Images