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

Abstract

記載する方法およびシステムは、ブランチ・オフィスにおけるクライアントが、アプリケーション・サーバーの代わりに、ＷＡＮを通じてローカル・ホスト・キャッシュからデータを引き出すことを可能にして、レイテンシーを改善しＷＡＮ全体のトラフィックを低減する。データ・センターにおけるサーバーは、ホスト・キャッシュ・システムが許可されているか否かに基づいて、ハッシュのリストまたは要求されたデータのいずれかを供給するように構成することができる。クライアント側のホスト・キャッシュは、ハッシュに基づいて、データをクライアントに供給することができる。ハッシュは、データの指紋を供給するために発生することができ、この指紋は効率的にデータをインデックス化するために用いることができる。
【選択図】図３

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