(57)【特許請求の範囲】
【請求項１】
クライアント装置からサーバ装置宛に送信されクライアント側プロキシに中継されたリクエストデータを受信して前記サーバ装置へ転送し、前記リクエストデータへの返答として前記サーバ装置から前記クライアント装置宛に送信されるリプライデータを前記クライアント側プロキシへ転送するサーバ側プロキシのデータ転送方法であって、
複数のクライアント側プロキシそれぞれから転送されるリクエストデータそれぞれへの返答であるリプライデータそれぞれを、前記サーバ装置から受信し、
前記リプライデータそれぞれのフィンガープリントを生成し、
生成した前記フィンガープリントそれぞれを、それぞれの元であった前記リプライデータそれぞれに関連付けて、前記リプライデータそれぞれの宛先となるクライアント装置それぞれに通ずるクライアント側プロキシ毎に、クライアント側プロキシ毎フィンガープリント・キャッシュとして保持し、
或クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータを前記サーバ装置から受信し、
前記或リプライデータのフィンガープリントである或フィンガープリントを生成し、
前記或フィンガープリントが、前記或リプライデータの宛先となる或クライアント装置に通ずる或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されているか否か判定し、
前記判定にて、前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていると判定された場合に、前記或リプライデータの代わりに前記或フィンガープリントを前記或クライアント装置宛として前記或クライアント側プロキシへ送信し、
前記判定にて、前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていないと判定された場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記或クライアント側プロキシに対応する前記クライアント側プロキシ毎フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記或クライアント側プロキシへ送信することを特徴とするデータ転送方法。
【請求項２】
複数のクライアント装置それぞれからサーバ装置宛に送信され、複数のクライアント装置それぞれの前記サーバ装置へのアクセスの代理を担当するクライアント側プロキシそれぞれに中継された、複数のリクエストデータを受信して前記サーバ装置へ転送し、前記複数のリクエストデータそれぞれへの返答として前記サーバ装置から前記クライアント装置それぞれ宛に送信されるリプライデータそれぞれを、リプライデータそれぞれの宛先たるクライアント装置の代理であるクライアント側プロキシそれぞれへ転送するサーバ側プロキシであって、
複数のクライアント側プロキシそれぞれから転送されるリクエストデータそれぞれへの返答であるリプライデータそれぞれを、前記サーバ装置から受信し、さらに、前記複数のクライアント側プロキシのうちの或クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信手段と、
前記リプライデータそれぞれのフィンガープリントを生成し、さらに前記或リプライデータのフィンガープリントである或フィンガープリントを生成するフィンガープリント生成手段と、
生成した前記フィンガープリントそれぞれを、それぞれの元であった前記リプライデータそれぞれに関連付けて、前記リプライデータそれぞれの宛先たるクライアント装置それぞれの代理であるクライアント側プロキシ毎に、クライアント側プロキシ毎フィンガープリント・キャッシュとして保持する保持手段と、
前記或フィンガープリントが、前記或リプライデータの宛先たる或クライアント装置の代理である或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、
前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを前記或クライアント装置宛として前記或クライアント側プロキシへ送信し、前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記或クライアント側プロキシに対応する前記クライアント側プロキシ毎フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記或クライアント側プロキシへ送信する送信手段とを備えることを特徴とするサーバ側プロキシ。
【請求項３】
前記フィンガープリントは、所定の方法によって前記リプライデータを圧縮して得た値であることを特徴とする請求項２に記載のサーバ側プロキシ。
【請求項４】
前記フィンガープリントは、前記リプライデータに所定のハッシュ関数を適用して得られた値であることを特徴とする請求項２に記載のサーバ側プロキシ。
【請求項５】
前記クライアント側プロキシは、第1のローカルエリアネットワークを介して前記クライアント装置と接続されたものであり、前記サーバ側プロキシは、第２のローカルエリアネットワークを介して前記サーバ装置と接続されたものであることを特徴とする請求項２に記載のサーバ側プロキシ。
【請求項６】
前記クライアント側プロキシと前記サーバ側プロキシとは、インターネットを介して接続されたものであることを特徴とする請求項２に記載のサーバ側プロキシ。
【請求項７】
複数のクライアント装置それぞれからサーバ装置宛に送信され、複数のクライアント装置それぞれの前記サーバ装置へのアクセスの代理を担当するクライアント側プロキシそれぞれに中継された、複数のリクエストデータを受信して前記サーバ装置へ転送し、前記複数のリクエストデータそれぞれへの返答として前記サーバ装置から前記クライアント装置それぞれ宛に送信されるリプライデータそれぞれを、リプライデータそれぞれの宛先たるクライアント装置の代理であるクライアント側プロキシそれぞれへ転送するサーバ側プロキシとしてコンピュータを機能させるためのプログラムであって、
複数のクライアント側プロキシそれぞれから転送されるリクエストデータそれぞれへの返答であるリプライデータそれぞれを、前記サーバ装置から受信し、さらに、前記複数のクライアント側プロキシのうちの或クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信機能と、
前記リプライデータそれぞれのフィンガープリントを生成し、さらに前記或リプライデータのフィンガープリントである或フィンガープリントを生成するフィンガープリント生成機能と、
生成した前記フィンガープリントそれぞれを、それぞれの元であった前記リプライデータそれぞれに関連付けて、前記リプライデータそれぞれの宛先たるクライアント装置それぞれの代理であるクライアント側プロキシ毎に、クライアント側プロキシ毎フィンガープリント・キャッシュとして保持する保持機能と、
前記或フィンガープリントが、前記或リプライデータの宛先たる或クライアント装置の代理である或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されているか否か判定する判定機能と、
前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていると前記判定機能が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを前記或クライアント装置宛として前記或クライアント側プロキシへ送信し、前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていないと前記判定機能が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記或クライアント側プロキシに対応する前記クライアント側プロキシ毎フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記或クライアント側プロキシへ送信する送信機能とをコンピュータに実現させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、他の装置のためにデータ転送を行うサーバ側プロキシ、データ転送方法及びプログラムに関する。
【０００２】
【従来の技術】
ネットワークを介して様々なサービスを提供するサーバと、所望のサービスをサーバに対して要求するクライアントとから構成される、クライアント・サーバ型の情報システムが広く利用されている。特に、インターネット上でＨＴＴＰプロトコルを使って通信するＷＥＢサーバとクライアントとからなるＷＯＲＬＤ  ＷＩＤＥ  ＷＥＢシステム（あるいは単にＷＥＢとも呼ばれる）は、大変広く利用されているクライアント・サーバ型の情報システムである。通常、サーバ上ではサーバプログラムが動作し、クライアント上ではブラウザなどの所定のツール（プログラム）が動作する。インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報（例えば、ホームページ、電子メール、デジタルコンテンツなど）や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋等の予約サービス、種々の契約の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。
【０００３】
ところで、ＷＥＢのようなクライアント・サーバ型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバ間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバとの間で通信に用いるネットワークの容量（バンド幅）が、システム全体のボトルネックになりやすい。そこで、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【０００４】
ＷＥＢシステムの場合、クライアント上で動作するブラウザ等はキャッシュ機構を使用するものが多く、最近アクセスしたデータをキャッシュしている。ＷＥＢではＵＲＬと呼ばれる名前で情報やサービスを指定してアクセスがなされるので、クライアント上のキャッシュは、過去にＷＥＢサーバに要求した情報やサービスの結果として返されるデータのうちでキャッシュ可能なものを、そのＵＲＬと対応させてキャッシュに記録している。この場合、キャッシュ内にあるものと同じＵＲＬの情報やサービスのリクエストがあった際に、そのキャッシュ内の応答データが古くなっていないと判断できるならば、そのデータを返すことで、ＷＥＢサーバとの間の通信を無くすことができる。
【０００５】
企業のオフィス内のＬＡＮあるいは研究機関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数のユーザがいる場合、該ＬＡＮとインターネットとの間にプロキシサーバを置き、プロキシサーバにキャッシュ機構を設けるようにすることも多い。クライアント内のキャッシュ（例えば、ブラウザのキャッシュ）は、当該クライアント・ユーザに専用のキャッシュとして動作するが、ＬＡＮ上のプロキシサーバのキャッシュは、複数のクライアント・ユーザに共有のキャッシュとして動作する。そのため、後者では、過去に他人（他クライアント）がアクセスしたＵＲＬに対してアクセスする際にもキャッシュが効く。
【０００６】
さて、ＷＥＢにおいて、クライアントとサーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行われる。ＨＴＴＰプロトコルは、クライアントからサーバへ送る「リクエストメッセージ」と、それに答えてサーバからクライアントへ応答を返す「リプライメッセージ」とが組になっている。
【０００７】
リクエストメッセージは、「リクエストヘッダ」と「リクエストボディ」からなる。リクエストヘッダには、アクセスしたい情報やサービスを指定するＵＲＬやアクセスの種類を示すメソッド名、その他アクセスに必要な各種の情報が入る。リクエストボディには、サーバに送るデータを入れる。リクエストボディに入っているデータを「リクエストデータ」とも呼ぶ。
【０００８】
リプライメッセージは、「リプライヘッダ」と「リプライボディ」からなる。リプライヘッダには、処理結果のステータスなどの情報が入り、リプライボディには要求された情報や要求されたサービスの処理結果などのデータが入る。リプライボディに入っているデータを「リプライデータ」とも呼ぶ。
【０００９】
リクエストメッセージのメソッドとしては、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユーザの持つデータをサーバに書き込む「ＰＵＴメソッド」、リクエストに応じて処理した結果を送り返してもらう「ＰＯＳＴメソッド」が、情報やサービスのアクセスに用いられる主要なものである。その他、ＤＥＬＥＴＥなどのメソッドが定義されている。
【００１０】
多くの場合、ＧＥＴメソッドのリクエストメッセージのリクエストボディ、ＰＵＴメソッドのリプライメッセージのリプライボディは空である。ＰＯＳＴメソッドのリクエストメッセージのリクエストボディには、必要に応じてサーバ側での処理に用いる情報が入り、ＰＯＳＴメソッドのリプライメッセージのリプライボディには、その処理の結果のデータが入る。
【００１１】
ＧＥＴメソッドでサーバから読み出すデータは、読み出す毎にサーバ側で生成する「動的データ」と、既にサーバ側で記憶しているデータをそのまま送り返す「静的データ」に分けることができる。これらのうち、動的データについては、同じＵＲＬでも読み出す度に内容が異なる可能性があるので、多くの場合、サーバはキャッシュ不可の指定をそのリプライメッセージのヘッダに入れて送り返す。したがって、ＷＥＢのデータでキャッシュの対象になるのは、静的データの部分である。この静的データは、不特定多数のユーザが参照して構わない「共有データ」と、ユーザ認証することで特定のユーザだけがアクセスできるようにアクセス制御を行う「プライベートデータ」に分けることができる。前者の共有データは、どのようなキャッシュでもキャッシュ可能である。しかしながら、後者のプライベートデータは、プロキシサーバなどの共有キャッシュでは、キャッシュ不可である（プライベートデータは必ずサーバでユーザを認証して送り返す必要があるので）。ただし、ブラウザなどの個人専用のキャッシュの場合には、プライベートデータでもキャッシュは可能である。
【００１２】
ＰＯＳＴメソッドは、サーバ側で処理をした結果を返すので、一般的にサーバはキャッシュ不可の指定をリプライメッセージのヘッダに入れて結果を送り返す。そのため、通常はキャッシュの対象にはならない。
【００１３】
ＰＵＴメソッドは、データをサーバに送るものなので、キャッシュは何も処理をしない。
【００１４】
【発明が解決しようとする課題】
従来のＷＥＢのキャッシュは、静的コンテンツをキャッシュの対象にしている。かつては、ＷＥＢで公開される情報やサービスには、情報の更新頻度がそれほど高くなく、不特定多数の人に公開されているものが多かったため、静的コンテンツの割合は非常に高く、従来のキャッシュ技術でもネットワークの負荷の軽減に有効であった。
【００１５】
しかしながら、ＷＥＢベースのＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）のように、ユーザがＷＥＢブラウザを使って、ネットワーク経由でサーバ上の情報やサービスにアクセスするシステムが普及するにつれて、下記のように従来のキャッシュ技術では対応できないデータが増加している。
・ユーザの認証を行い、アクセスできるユーザを制限しているので、プライベートデータが多い。
・バックエンドのデータベースを参照して生成する動的データが多い。
・帳票処理や検索などＰＯＳＴメソッドを使う場合が多い。
・グループ内の情報共有のためにＰＵＴメソッドを使う場合が多い。
この結果、キャッシュ技術のみではネットワークの負荷を軽減する手法として有効に機能しなくなってきている。
【００１６】
本発明は、上記事情を考慮してなされたもので、サーバ側プロキシとクライアント側プロキシとの間を接続するネットワークの負荷をより軽減することができるキャッシュ技術・圧縮技術を備えたサーバ側プロキシ、データ転送方法及びプログラムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明は、複数のクライアント装置それぞれからサーバ装置宛に送信され、複数のクライアント装置それぞれの前記サーバ装置へのアクセスの代理を担当するクライアント側プロキシそれぞれに中継された、複数のリクエストデータを受信して前記サーバ装置へ転送し、前記複数のリクエストデータそれぞれへの返答として前記サーバ装置から前記クライアント装置それぞれ宛に送信されるリプライデータそれぞれを、リプライデータそれぞれの宛先たるクライアント装置の代理であるクライアント側プロキシそれぞれへ転送するサーバ側プロキシであって、複数のクライアント側プロキシそれぞれから転送されるリクエストデータそれぞれへの返答であるリプライデータそれぞれを、前記サーバ装置から受信し、さらに、前記複数のクライアント側プロキシのうちの或クライアント側プロキシから転送された或リクエストデータへの返答である或リプライデータをも受信する受信手段と、前記リプライデータそれぞれのフィンガープリントを生成し、さらに前記或リプライデータのフィンガープリントである或フィンガープリントを生成するフィンガープリント生成手段と、生成した前記フィンガープリントそれぞれを、それぞれの元であった前記リプライデータそれぞれに関連付けて、前記リプライデータそれぞれの宛先たるクライアント装置それぞれの代理であるクライアント側プロキシ毎に、クライアント側プロキシ毎フィンガープリント・キャッシュとして保持する保持手段と、前記或フィンガープリントが、前記或リプライデータの宛先たる或クライアント装置の代理である或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されているか否か判定する判定手段と、前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていると前記判定手段が判定した場合に、前記或リプライデータの代わりに前記或フィンガープリントを前記或クライアント装置宛として前記或クライアント側プロキシへ送信し、前記或フィンガープリントが前記或クライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されていないと前記判定手段が判定した場合に、前記或フィンガープリントと前記或リプライデータとを関連付けて前記或クライアント側プロキシに対応する前記クライアント側プロキシ毎フィンガープリント・キャッシュに追加しかつ前記或リプライデータを前記或クライアント装置宛として前記或クライアント側プロキシへ送信する送信手段とを備えることを特徴とする。
【００２１】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２２】
本発明によれば、サーバ装置側に設けられたサーバ側プロキシは、クライアント装置側に設けられたクライアント側プロキシから該クライアント装置が該サーバ装置へ宛てて発したリクエストデータを受信してサーバ装置へ転送した後に、該サーバ装置が該クライアント装置へ宛てて発した該リクエストデータへの返答であるリプライデータを受信してクライアント側プロキシへ転送するにあたって、受信したリプライデータから生成したフィンガープリントを、該リプライデータに関連付けて、該リプライデータの宛先となるクライアント装置に係るクライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持しておくことによって、サーバ装置からリプライデータを受信した場合に、そのフィンガープリントが該リプライデータの宛先となるクライアント装置に係るクライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されているリプライデータについては、該リプライデータを転送する代わりに対応するフィンガープリントを転送することで、それらサーバ側プロキシとクライアント側プロキシとの間の転送データ量を削減することができる。また、サーバ側プロキシとクライアント側プロキシとが１対多で接続される際に、サーバ側プロキシは、クライアント側プロキシごとに、リプライデータとそのフィンガープリントとを関連付けたクライアント側プロキシ毎フィンガープリント・キャッシュを保持しているので、あるリプライデータについて、その宛先となるクライアント装置に係るクライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに該リプライデータとそのフィンガープリントとの対応が保持されていない場合に、そのクライアント側プロキシに対して、当該あるリプライデータの代わりにそのフィンガープリントを転送してしまうことを回避することができる。
【００２３】
また、本発明によれば、例えば、ＧＥＴメソッドのリプライメッセージがプライベートデータであっても、これをフィンガープリントにより圧縮してクライアント側プロキシとサーバ側プロキシとの間を転送することができるようになる。また、例えば、ＧＥＴメソッドのリプライメッセージが動的データであっても、内容が同じデータなら、これをフィンガープリントにより圧縮してクライアント側プロキシとサーバ側プロキシとの間を転送することができるようになる。また、例えば、ＰＯＳＴメソッドであっても、結果が同じデータなら、これをフィンガープリントにより圧縮してクライアント側プロキシとサーバ側プロキシとの間を転送することができるようになる。
【００２４】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００２５】
以下では、ＷＡＮがインターネットであり、クライアントはユーザオフィスＬＡＮに接続されたものであり、ＨＴＴＰプロトコルが使用されるような場合を例にとって説明するが、もちろん、本発明は、ＷＡＮがインターネット以外のものであっても、クライアントがオフィス以外の例えば家庭内ＬＡＮ等に設置されたものであっても、ＨＴＴＰプロトコル以外のプロトコルが使用されるものであっても適用可能である。
【００２６】
図２２に本発明を適用するコンピュータ・ネットワーク・システムの基本的な構成例を示す。この構成例では、ＡＳＰサーバセンター２内のローカルエリアネットワーク（ＬＡＮ）１２と、ユーザオフィス４内のローカルエリアネットワーク（ＬＡＮ）１６との間が、インターネットや専用回線などの広域ネットワーク（ＷＡＮ）１４を介して接続されており、ＡＳＰサーバセンター２内のサーバ２０と、ユーザオフィス４内のクライアント５０とが、ＬＡＮ１２・ＷＡＮ１４・ＬＡＮ１６を介して通信可能になっている。ＡＳＰサーバセンター内ＬＡＮには１または複数のサーバが接続され、ユーザオフィス内ＬＡＮには１または複数のクライアントが接続される。
【００２７】
ＷＥＢベースのＡＳＰは、サーバセンター２に設置したサーバ２０から、ＷＡＮ１４を介して、様々なアプリケーションプログラムによるサービスを提供し、ユーザはオフィス４に設置されたクライアント上のＷＥＢブラウザ等を使ってそれらのサービスにアクセスする。
【００２８】
なお、ＡＳＰサーバセンター２や、ユーザオフィス４は、複数存在し得る。
【００２９】
このような利用形態においては、ユーザオフィス内ＬＡＮ１６とサーバセンター内ＬＡＮ１２とをつなぐネットワーク、特にインターネットなどの広域ネットワーク１４の実効的な通信容量（バンド幅）は、サーバセンター内ＬＡＮ１２やユーザオフィス内ＬＡＮ１６よりも低く、そこが性能上のボトルネックになって通信遅延が発生し、アプリケーションの応答性能が低下するという問題が発生する。
【００３０】
そこで、本実施形態では、図１に示すように、サーバセンター内ＬＡＮ１２とユーザオフィス内ＬＡＮ１６とをつなぐ広域ネットワーク１４の両端に、サーバ側プロキシ３０およびクライアント側プロキシ４０という２つのモジュールを設置し、それらの間で後述するフィンガープリント圧縮（ＦＰ圧縮）を行って通信データ量を低減することで、広域ネットワークのボトルネックを解消する。
【００３１】
なお、ここでは、１つのサーバ側プロキシ３０と複数のクライアント側プロキシ４０との間の通信にＦＰ圧縮を適用する場合を考えている（１つのクライアント側プロキシ４０は（ある時点において）１つのサーバ側プロキシ３０とＦＰ圧縮を適用した通信を行う場合を考える）。
【００３２】
本実施形態のサーバ２０、サーバ側プロキシ３０、クライアント側プロキシ４０、クライアント５０は、いずれも、計算機上でソフトウェア（サーバ・プログラム、サーバ側プロキシ・プログラム、クライアント側プロキシ・プログラム、クライアント・プログラム）を動作させる形で実現することができる。この場合に、必要に応じて計算機に所望の機能を有するＯＳやドライバソフト、パケット通信用ソフト、暗号ソフト等といったソフトウェア、あるいは通信インタフェース装置や外部記憶装置や入出力装置等といったハードウェアが搭載あるいは接続される。また、この場合に、ユーザあるいは管理者からの情報の入力やユーザへの情報の呈示等のために、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を用いると好ましい。
【００３３】
サービスを利用するためにユーザが使用するクライアント５０上では、その目的に応じて例えばＷＥＢブラウザ等のプログラムが動作する。ユーザは、例えば、ＷＥＢブラウザからインターネットを介し情報転送あるいは注文受付等の所望のサービスを提供するサーバにリクエストメッセージを出し、リプライメッセージを受けることによって、またはこれを適宜繰り返すことによって、サービスを利用する。もちろん、ＷＥＢブラウザ等の汎用のソフトウェアではなく、特定のサービスを利用するための専用のソフトウェアなどの他のものが用いられても構わない。また、クライアントは、汎用の計算機ではなく、例えばインターネット機能を有する携帯電話端末等でもよい。
【００３４】
サーバ２０上では、所定のサーバ・プログラムが動作し、クライアント５０のユーザに対して、当該サーバ・サイトに固有のサービスを提供する。
【００３５】
サーバ側プロキシ３０は、図１のように、サーバセンター内ＬＡＮ１２とＷＡＮ１４との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図２のように、サーバセンター内ＬＡＮ１２上に設置して実施することもできる。また、図３のように、サーバ側プロキシ３０の機能をサーバ２０に内蔵するように実施することもできる。
【００３６】
同様に、クライアント側プロキシ４０は、図１のように、ユーザオフィス内ＬＡＮ１６とＷＡＮ１４との両方に接続し、トランスペアレント・プロキシとして動作するように設置して実施することができる。また、図２のように、ユーザオフィス内ＬＡＮ１６上に設置して実施することもできる。また、図３のように、クライアント側プロキシ４０の機能をクライアント５０上で動作するブラウザ等に内蔵するように実施することもできる。あるいは、ブラウザ等の動作するクライアント５０上に、個人用のクライアント側プロキシ４０を動作させるように実施することもできる。
【００３７】
なお、各サーバ側プロキシ３０及び各クライアント側プロキシ４０は、例えば図１〜図３などのように、すべて同じ形態のものであってもよい。また、例えば、あるサーバ側プロキシ３０は図１の形態で、あるサーバ側プロキシ３０は図２の形態で、あるクライアント側プロキシ４０は図１の形態で、あるクライアント側プロキシ４０は図３の形態で、というように、異なる形態のものが混在していてもよい。
【００３８】
また、クライアント側プロキシ４０は、モバイル端末もしくはモバイル計算機等に内蔵されたものであってもよい。図４に、この場合の一例を示す。
【００３９】
さて、本実施形態のサーバ側プロキシ３０およびクライアント側プロキシ４０は、いずれも、フィンガープリント・キャッシュ（ＦＰキャッシュ）と呼ぶキャッシュ機構を持つ。フィンガープリント・キャッシュは、フィンガープリント（ＦＰ）と呼ぶ名前によって、ＨＴＴＰプロトコルでやりとりされるデータを記録・管理する。
【００４０】
フィンガープリントは、図５に例示するように、ＨＴＴＰプロトコルでやり取りされるデータ（図５の例ではコンテンツ）の内容から、あらかじめ決められた計算方法（図５の例ではハッシュ関数）で決定される、短い数値である。この数値は、可変長でもよいが、処理の容易さの観点では、固定長の数値の方が扱いやすい。
【００４１】
フィンガープリントを計算する方法としては、良く知られているＭＤ−５やＳＨＡ−１などのハッシュ関数を用いることができる。これらのハッシュ関数は、データに対する電子署名などに使われており、任意のデータが与えられると、ＭＤ−５の場合は１２８ビットの数値に、ＳＨＡ−１の場合は１６０ビットの数値に、変換することができる。これらのハッシュ関数の特徴は、２つのデータＸ１，Ｘ２が与えられ、データＸ１とデータＸ２とが同じであれば、データＸ１に対して計算したハッシュ値とデータＸ２に対して計算したハッシュ値とは等しくなるが、異なる２つのデータＡ，Ｂが与えられた場合には、データＡに対して計算したハッシュ値とデータＢに対して計算したハッシュ値とは、非常に高い確率で異なるものになることである（原理上は、異なる２つのデータＡ，Ｂに対してそれぞれ計算したハッシュ値が同じになる場合があるが、その確率は実用上無視できるくらいに小さい）。
【００４２】
図６に示すように、サーバ側プロキシ３０やクライアント側プロキシ４０の持つフィンガープリント・キャッシュ（図中の６０）は、過去にＨＴＴＰプロトコルでやり取りされたデータ本体（図中の６１）を、そのデータから計算して求めたフィンガープリントの値（図中の６２）を名前として、記録・管理している。なお、詳しくは後述するように、サーバ側プロキシ３０は、ＦＰ圧縮を適用する通信を行う相手となるクライアント側プロキシ４０毎に、フィンガープリントとデータとの対応を管理する。
【００４３】
例えば、ＨＴＴＰプロトコルでサーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送するときに、サーバ側プロキシ３０は、当該データのフィンガープリントを計算し、そのフィンガープリントに対応するデータが、当該クライアント側プロキシ４０に対応するフィンガープリント・キャッシュに入っていれば、当該データ（と同じ内容のデータ）は当該クライアント側プロキシ４０に対して過去に転送したことがあるので、当該データを転送せずに、対応するフィンガープリントの値を転送する。フィンガープリントを受け取ったクライアント側プロキシ４０は、当該フィンガープリントの値に対応するデータをフィンガープリント・キャッシュから取り出すことで、転送すべきデータを再現することができる。このような方式（すなわち、データ圧縮→データ転送→データ解凍）により、過去に送ったものと同じデータならばフィンガープリントの値を送るだけでよいので、ネットワークを流れるデータ量を大幅に削減することができる。
【００４４】
なお、サーバ側プロキシ３０は、例えば、所定の通信規約に従って、サーバ２０から受信したデータを転送すべきクライアント側プロキシ４０を特定することができる。
【００４５】
また、クライアント側プロキシ４０は、登録時に、サーバ側プロキシ３０からのメッセージ内にフィンガープリントが記述されてあって且つ該記述されているフィンガープリントを使用する構成と、サーバ側プロキシ３０からのメッセージ内にフィンガープリントが記述されてなく且つ自身でフィンガープリントを計算する構成と、サーバ側プロキシ３０からのメッセージ内にフィンガープリントが記述されてあって且つ自身であらためてフィンガープリントを計算する構成とがある。
【００４６】
説明上、サーバ側プロキシ３０とクライアント側プロキシ４０との間でのデータ転送にあたり、フィンガープリント・キャッシュを利用してメッセージ・ボディーのデータをフィンガープリントに置き換えて転送情報量を圧縮することを、フィンガープリント圧縮（ＦＰ圧縮）と呼ぶものとする。
【００４７】
なお、サーバ側プロキシ３０とクライアント側プロキシ４０との間において、すべてのメッセージをＦＰ圧縮を適用する対象（すなわち、フィンガープリント・キャッシュを利用してデータをフィンガープリントに置き換えるための処理を行う対象）としてもよいが、例えばフィンガープリント・キャッシュの効果が期待できないものなどに対する適用を除外するために、予め定められた条件を満たすメッセージについては、これをＦＰ圧縮の適用対象外とする（常にＦＰ圧縮しないで転送する）ようにしてもよい。
この場合の予め定められた条件とは、例えば、メッセージ・ヘッダに予め定められた情報が記述されていることである。具体的には、例えば、メッセージ・ヘッダにＧＥＴメソッドを示す情報およびリクエストを示す情報が記述されていることである。また、予め定められた条件の他の例としては、転送されるデータが空（ｎｕｌｌ）あるいは非常に短いサイズであることである。
もちろん、それらの他にも種々のバリエーションがある。また、複数の条件を組み合わせて使用するようにしてもよい。
なお、このようなＦＰ圧縮の適用対象に関する設定内容は、例えば、システム全体で同一にする方法や、サーバ側プロキシ３０とクライアント側プロキシ４０との対ごとに取り決める方法などがある。また、後者の場合には、予め設定しておく方法や、セッション毎に設定する方法などがある。
【００４８】
次に、図７〜図１１を参照しながら、サーバ側プロキシ３０とクライアント側プロキシ４０との間でデータ転送する際の（ＦＰ圧縮の適用対象のメッセージについての）プロキシ間メッセージ・フォーマットについて説明する。
【００４９】
なお、ＦＰ圧縮の適用対象外のメッセージは、ＦＰ圧縮については、何もせずにそのままの（ＦＰ圧縮側（送信側）のプロキシが受信した際の）メッセージ・フォーマットでプロキシ間を転送して構わない。あるいは、ＦＰ圧縮側（送信側）のプロキシが、例えばそのメッセージ・ヘッダに当該メッセージがＦＰ圧縮の適用対象外を識別可能とする情報を持つようにして転送することも可能である。
【００５０】
さて、サーバ側プロキシ３０とクライアント側プロキシ４０との間でデータ転送する場合、ＦＰ圧縮の適用対象のメッセージには、データがＦＰ圧縮されてフィンガープリントに置き換えられたメッセージ（圧縮時のメッセージ）と、ＦＰ圧縮されおらず、データが搭載されているメッセージ（非圧縮時のメッセージ）とがある。
【００５１】
非圧縮時のメッセージ・フォーマットは、メッセージに含まれるデータが、その転送先となるクライアント側プロキシ４０に対応するサーバ側プロキシ３０のフィンガープリント・キャッシュに登録されていない場合に使用される。一方、圧縮時のメッセージ・フォーマットは、メッセージに含まれるデータが、その転送先となるクライアント側プロキシ４０に対応するサーバ側プロキシ３０のフィンガープリント・キャッシュに登録されている場合に使用される。
【００５２】
解凍側（受信側）では、非圧縮時のフォーマットのメッセージを受信したことを契機として、当該データについてフィンガープリント・キャッシュへの登録を行うことができる。
【００５３】
図７に、メッセージ・フォーマットの一例を示す。（ａ）は非圧縮時のメッセージであり、（ｂ）は圧縮時のメッセージである。
【００５４】
（ａ）ではメッセージ・ボディーにデータが載せられ、（ｂ）ではメッセージ・ボディーにデータの代わりにフィンガープリント（ＦＰ）が載せられる。また、この例では、メッセージ・ヘッダに、ＦＰ圧縮の有無を識別可能とする識別情報が（圧縮側のプロキシにおいて）記述され、この識別情報に基づいて（解凍側のプロキシにおいて）ＦＰ圧縮の有無を識別する（例えば、０ならば圧縮なし、１ならば圧縮あり）。なお、識別情報は、プロキシ間で使用される特別のものであってもよいし、もともと通常のＨＴＴＰメッセージ・ヘッダに存在するフィールドを利用あるいは併用したものであってもよい。
【００５５】
なお、非圧縮時には、図７（ａ）の例では、メッセージにフィンガープリントを含ませなかったが、メッセージ・ボディーにデータに加えてフィンガープリントを含ませるようにしてもよいし、または図８に示すように、メッセージ・ヘッダにフィンガープリントを含ませるようにしてもよい。このようにすれば、解凍側で当該データについてフィンガープリント・キャッシュの登録を行う際に、該フィンガープリントを利用することによって、あらためて当該データからフィンガープリントを求める手間が省ける。
【００５６】
なお、ＦＰ圧縮の適用対象外のメッセージが存在し得る場合には、解凍側（受信側）では、メッセージ・ヘッダに上記の識別情報が含まれるか否かで、ＦＰ圧縮の適用対象のメッセージか適用対象外のメッセージかを判断することもできる。また、ＦＰ圧縮の適用対象外のメッセージのヘッダにも識別情報を設け、該識別情報によって３種類のメッセージを識別するようにしてもよい（例えば、０１ならば適用対象外、１０なら（適用対象であって且つ）圧縮なし、１１なら（適用対象であって且つ）圧縮あり）。
【００５７】
図９に、メッセージ・フォーマットの他の例を示す。（ａ）は非圧縮時のメッセージであり、（ｂ）は圧縮時のメッセージである。（ａ）ではメッセージ・ボディーにデータが載せられ、（ｂ）ではメッセージ・ボディーは空（ｎｕｌｌ）である。また、この例では、（ａ），（ｂ）ともにメッセージ・ヘッダにフィンガープリント（ＦＰ）が記述される。ＦＰ圧縮の有無を識別可能とする識別情報について上記の例と同様である。
【００５８】
なお、この場合に、非圧縮時には図７の（ａ）と同様のメッセージ・フォーマット（フィンガープリントを含まないフォーマット）を用いる方法もある。
【００５９】
なお、ＦＰ圧縮の適用対象外のメッセージが存在し得る場合には、上記した識別情報に基づく方法の他に、圧縮側（送信側）のプロキシがＦＰ圧縮の適用対象のメッセージ・ヘッダに常にフィンガープリントを記述する構成の場合には、解凍側（受信側）では、メッセージ・ヘッダにフィンガープリントが含まれるか否かで判断することもできる。
【００６０】
図１０に、メッセージ・フォーマットのさらに他の例を示す。（ａ）は非圧縮時のメッセージであり、（ｂ）は圧縮時のメッセージである。（ａ）ではメッセージ・ボディーにデータが載せられ、（ｂ）ではメッセージ・ボディーは空（ｎｕｌｌ）である。また、この例では、（ａ），（ｂ）ともにメッセージ・ヘッダにフィンガープリント（ＦＰ）が記述される。ただし、この例では、ＦＰ圧縮の有無を識別可能とする識別情報は使用しない。
【００６１】
この例では、メッセージ・ボディーが空（ｎｕｌｌ）か否かによって、ＦＰ圧縮の有無を識別することができる。ただし、ＦＰ圧縮の適用対象外のメッセージでメッセージ・ボディーが空（ｎｕｌｌ）のものが存在し得る場合には、例えば、メッセージ・ヘッダにフィンガープリント（ＦＰ）が存在するか否かによって、ＦＰ圧縮の適用対象で圧縮時のメッセージか、ＦＰ圧縮の適用対象外でメッセージ・ボディーが空（ｎｕｌｌ）のメッセージかを識別する（あるいは、メッセージ・ヘッダにＦＰ圧縮の適用対象か適用対象外かを示す情報を設けてもよい）。
【００６２】
なお、非圧縮時には図１１に示すようにメッセージにフィンガープリントを記述しないフォーマットを用いる方法もある。この場合には、メッセージ・ヘッダにフィンガープリントが含まれるか否かによって、ＦＰ圧縮の有無を識別することができる。ただし、ＦＰ圧縮の適用対象外のメッセージが存在し得る場合には、例えば、メッセージ・ヘッダにＦＰ圧縮の適用対象か適用対象外かを示す情報を設ければよい。
【００６３】
以下では、サーバ側プロキシ３０からクライアント側プロキシ４０へリプライメッセージを転送するときにそのリプライデータをＦＰ圧縮・解凍する場合を中心に本実施形態について詳しく説明する。
【００６４】
図１２に本実施形態のサーバ側プロキシ３０の構成例を示し、図１３に本実施形態のクライアント側プロキシ４０の構成例を示す。なお、図１２や図１３は、サーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送する際の構成を中心に示してある。
【００６５】
図１２に示されるように、本サーバ側プロキシ３０は、サーバセンター内ＬＡＮ１２または広域ネットワーク１４から転送メッセージを受信するための処理を行う受信部３１、転送メッセージに含まれるデータに対してＦＰ圧縮を施すための処理部３２、サーバセンター内ＬＡＮ１２または広域ネットワーク１４へ転送メッセージを送信するための処理を行う送信部３３、フィンガープリントとそのもととなったデータとを対応付けて記憶するためのフィンガープリント・キャッシュ（ＦＰキャッシュ）３４を備えている。また、処理部３２は、転送メッセージに含まれるデータを圧縮対象とすべきか否かを判定するためのフィンガープリント（ＦＰ）圧縮判定部３２１、フィンガープリント・キャッシュ３４に対する検索や登録などを行うためのフィンガープリント・キャッシュ（ＦＰキャッシュ）管理部３２２、転送メッセージに含まれるデータを対応するフィンガープリントで置き換えるなどの処理を行うためのフィンガープリント（ＦＰ）圧縮処理部３２３を含む。
【００６６】
さて、ＦＰキャッシュ管理部３２２は、ＦＰ圧縮を適用する通信を行う相手となるクライアント側プロキシ４０毎に、フィンガープリントとデータとの対応を管理する。その形態には種々のバリエーションがあるが、以下、その幾つかについて説明する（なお、図１２は、論理的にクライアント側プロキシ４０のそれぞれに対応したＦＰキャッシュ３４が設けられる様子を表している）。
【００６７】
（１）図１４は、クライアント側プロキシ４０毎にハッシュテーブルを設けるとともに、フィンガープリントに対応するデータも、クライアント側プロキシ４０毎に保持する（同一コンテンツでもクライアント側プロキシ毎にそのコピーを持つ）構成例である。この場合、ＦＰキャッシュ管理部３２２では、データの転送先となるクライアント側プロキシ４０に対応するＦＰキャッシュ３４を特定し、そのＦＰキャッシュ３４に該データに対応するフィンガープリントが保持されているか否かをチェックすることになる。
【００６８】
（２）図１５は、ハッシュテーブルはクライアント側プロキシ４０毎に設けるが、同一のコンテンツは一つしか持たず、そのポインター情報をハッシュテーブルに保持する（なお、クライアント側プロキシ４０が異なり且つフィンガープリントの値が同じでも、元のデータの内容が異なる場合には、それぞれのデータを保持することになる）構成例である。この場合、ＦＰキャッシュ管理部３２２では、データの転送先となるクライアント側プロキシ４０に対応するＦＰキャッシュ３４を特定し、そのＦＰキャッシュ３４に該データに対応するフィンガープリントが保持されているか否かをチェックすることになる。
【００６９】
（３）図１６は、クライアント側プロキシ４０毎にはＦＰキャッシュ３４を設けない代わりに、ハッシュテーブルに、当該フィンガープリントに対応するデータの転送先となるクライアント側プロキシを識別するクライアント側プロキシ識別情報を追加して、クライアント側プロキシ識別情報とフィンガープリントの値の対からなるようにした構成例である。なお、図１６では、（２）のように同一のコンテンツは一つしか持たず、そのポインター情報をハッシュテーブルに保持する構成例を示しているが、その代わりに、（１）のように、各エントリ毎にデータを保持する構成例も可能である。クライアント側プロキシ識別情報は、ユニークにクライアント側プロキシを識別できる情報であり、例えば、ＩＰアドレスやＭＡＣアドレス、ホストＩＤ、チャネル識別子、あるいはそれらを一意に特定可能な情報などを用いることができる。この場合、ＦＰキャッシュ管理部３２２では、データの転送先となるクライアント側プロキシ４０のクライアント側プロキシ識別情報を特定し、ＦＰキャッシュ３４に、該クライアント側プロキシ識別情報と該データに対応するフィンガープリントとの対が保持されているか否かをチェックすることになる。
【００７０】
（４）図１７は、クライアント側プロキシ４０毎にはＦＰキャッシュ３４を設けず、ハッシュテーブルに、フィンガープリントの値に対応して、該フィンガープリントを利用可能なクライアント側プロキシ識別情報群を保持するようにした構成例である。この場合、ＦＰキャッシュ管理部３２２では、データの転送先となるクライアント側プロキシ４０のクライアント側プロキシ識別情報を特定し、ＦＰキャッシュ３４に、該データに対応するフィンガープリントが保持されているか否か、およびそのフィンガープリントに対するクライアント側プロキシ識別情報群に該クライアント側プロキシ識別情報が保持されているか否かをチェックすることになる。
【００７１】
次に、図１３に示されるように、本クライアント側プロキシ４０は、ユーザオフィス内ＬＡＮ１６または広域ネットワーク１４から転送メッセージを受信するための処理を行う受信部４１、転送メッセージに含まれるデータに対してＦＰ解凍を施すための処理部４２、ユーザオフィス内ＬＡＮ１６または広域ネットワーク１４へ転送メッセージを送信するための処理を行う送信部４３、フィンガープリントとそのもととなったデータとを対応付けて記憶するためのフィンガープリント・キャッシュ（ＦＰ・キャッシュ）４４を備えている。また、処理部４２は、転送メッセージに含まれるデータを圧縮対象とすべきか否かおよび転送メッセージに対するＦＰ圧縮の有無を判定するためのフィンガープリント（ＦＰ）圧縮判定部４２１、フィンガープリント・キャッシュ３４に対する検索や登録などを行うためのフィンガープリント・キャッシュ（ＦＰキャッシュ）管理部４２２、ＦＰ圧縮された転送メッセージに含まれるフィンガープリントから元のデータを解凍するなどの処理を行うためのフィンガープリント（ＦＰ）解凍処理部４２３を含む。
【００７２】
なお、圧縮側のＦＰ圧縮判定部３２１と解凍側のＦＰ圧縮判定部４２１は、前述したようにメッセージが予め定められた条件を満たすか否かを調べることによって、そのメッセージに含まれるデータをＦＰ圧縮の適用対象とするか否かを判断する（すべてのメッセージをＦＰ圧縮の適用対象にする場合には、圧縮側のＦＰ圧縮判定部３２１および後に示す手順例の該当部分は不要であり、解凍側のＦＰ圧縮判定部４２１の該当判断の部分および後に示す手順例の該当部分は不要である）。また、解凍側のＦＰ圧縮判定部４２１は、ＦＰ圧縮の適用対象のメッセージについて、そのデータがＦＰ圧縮されたものか否かを判定する。以下では、ＦＰ圧縮の適用対象となるメッセージを転送する場合（ＦＰ圧縮の適用対象とすると判断された場合、またはすべてのメッセージをＦＰ圧縮の適用対象にする場合）を中心に説明する。
【００７３】
図１８に、サーバ側プロキシ３０が、クライアント側プロキシ４０からリクエストメッセージを受信してから、当該クライアント側プロキシ４０へリプライメッセージを転送するまでのサーバ側プロキシ３０の処理手順の一例を示す。
【００７４】
図１８は、サーバ側プロキシ３０のクライアント側プロキシ４０からの１回のリクエストに応じた処理を記述しているが、例えば、複数のクライアント側プロキシ４０から同時にリクエストメッセージを受ける場合には、それぞれのリクエストを受け取る都度、図１８の処理を並行して行う。
【００７５】
なお、図１８は、クライアント側プロキシ４０からサーバ側プロキシ３０へのリクエストメッセージの転送ではＦＰ圧縮を行わず、サーバ側プロキシ３０からクライアント側プロキシ４０へのリプライメッセージの転送ではＦＰ圧縮を利用する場合の手順例である。
【００７６】
以下では、要求元のクライアント側プロキシとは、１対のリクエストメッセージ及びリプライメッセージに対する処理において、当該要求元のクライアントに対応するクライアント側プロキシ、すなわち、リクエストメッセージの送信元且つリプライメッセージの受信先となるクライアント側プロキシを意味するものとする。
【００７７】
サーバ側プロキシ３０は、複数存在するクライアント側プロキシ中の或る１つのクライアント側プロキシ（すなわち、要求元のクライアント側プロキシ）４０から、リクエストメッセージを受信すると（ステップＳ１）、これを宛先となるサーバ２０へ送信する（ステップＳ２）。この時点で、当該１対のリクエストメッセージ及びリプライメッセージに対する処理としては、一旦、該当するリプライメッセージの受信を待つ状態に入ることになる。
【００７８】
さて、その後、サーバ側プロキシ３０は、受信部３１により、サーバ２０からリプライメッセージを受信すると（ステップＳ３）、まず、ＦＰ圧縮判定部３２１にて、該リプライメッセージのリプライデータがＦＰ圧縮対象のものであるか否か調べ、判断する（ステップＳ４）。リプライデータがＦＰ圧縮対象外のものと判断されたならば（ステップＳ４）、受信したリプライメッセージを送信部３３からクライアント側プロキシ４０へ転送する（ステップＳ９）。
【００７９】
ステップＳ４にて該リプライメッセージのリプライデータがＦＰ圧縮対象のものであると判断されたならば、ＦＰキャッシュ管理部３２２にて、該リプライデータのフィンガープリントの値を計算し（ステップＳ５）、該フィンガープリントの値をキーとして、要求元のクライアント側プロキシ４０に対応するフィンガープリント・キャッシュ３４を検索する（ステップＳ６）。
【００８０】
そして、該フィンガープリントの値とこれに対応するデータとの組が、当該要求元のクライアント側プロキシ４０に対応するフィンガープリント・キャッシュ３４に登録されていたならば（ステップＳ７）、ＦＰ圧縮処理部３２３にて、受信したリプライメッセージを、該フィンガープリントの値を用いてＦＰ圧縮時のフォーマットにして（例えば図９（ｂ）等）、送信部３３から、当該要求元のクライアント側プロキシ４０へ送信する（ステップＳ８）。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：フィールド）の値を、ＦＰ圧縮時のフォーマットにあわせて設定する。
【００８１】
一方、ステップＳ６の検索の結果、該フィンガープリントの値とこれに対応するデータとの組が、当該要求元のクライアント側プロキシ４０に対応するフィンガープリント・キャッシュ３４に登録されていなかったならば（ステップＳ７）、次の２つの作業を行う。
（１）ＦＰ圧縮処理部３２３にて、受信したリプライメッセージを、（必要に応じて該フィンガープリントの値を用いて）非ＦＰ圧縮時のフォーマットにして（例えば図９（ａ）等）、送信部３３から、当該要求元のクライアント側プロキシ４０へ送信する（ステップＳ１０）。
（２）ＦＰキャッシュ管理部３２２にて、該フィンガープリントの値と、該リプライデータとを対応付けて（フィンガープリントの値をキーにして）、当該要求元のクライアント側プロキシ４０に対応するフィンガープリント・キャッシュ３４に登録する（ステップＳ１１）。
【００８２】
なお、上記の（１）と（２）は、いずれを先に行ってもよいし、並行して行ってもよい。
【００８３】
図１９に、クライアント側プロキシ４０が、クライアント５０からリクエストメッセージを受信してから、当該クライアント５０へリプライメッセージを転送するまでのクライアント側プロキシ４０の処理手順の一例を示す。
【００８４】
図１９は、クライアント側プロキシ４０のクライアント５０からの１回のリクエストに応じた処理を記述しているが、例えば、複数のクライアント５０から同時にリクエストメッセージを受ける場合には、それぞれのリクエストを受け取る都度、図１９の処理を並行して行う。
【００８５】
なお、図１９は、クライアント側プロキシ４０からサーバ側プロキシ３０へのリクエストメッセージの転送ではＦＰ圧縮を行わず、サーバ側プロキシ３０からクライアント側プロキシ４０へのリプライメッセージの転送ではＦＰ圧縮を利用する場合の手順例である。
【００８６】
クライアント側プロキシ４０は、要求元のクライアント５０から、リクエストメッセージを受信すると（ステップＳ２１）、これを宛先となるサーバ２０に対応するサーバ側プロキシ３０へ送信する（ステップＳ２２）。この時点で、当該１対のリクエストメッセージ及びリプライメッセージに対する処理としては、一旦、該当するリプライメッセージの受信を待つ状態に入ることになる。
【００８７】
さて、その後、クライアント側プロキシ４０は、受信部４１により、サーバ側プロキシ３０からリプライメッセージを受信すると（ステップＳ２３）、まず、ＦＰ圧縮判定部４２１にて、該リプライメッセージのリプライデータがＦＰ圧縮対象のものであるか否か調べ、判断する（ステップＳ２４）。リプライデータがＦＰ圧縮対象外のものと判断されたならば（ステップＳ２４）、受信したリプライメッセージを送信部４３からクライアント５０へ転送する（ステップＳ３２）。
【００８８】
ステップＳ２４にて該リプライメッセージのリプライデータがＦＰ圧縮対象のものであると判断されたならば、ＦＰ圧縮判定部４２１は、さらに、リプライデータがＦＰ圧縮されているか否か調べ、判断する（ステップＳ２５）。
【００８９】
ステップＳ２５にて該リプライメッセージのリプライデータがＦＰ圧縮されているものと判断されたならば（例えば図９（ｂ）等の場合）、ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（ステップＳ２６）、該フィンガープリントの値をキーとしてフィンガープリント・キャッシュ４４を検索する（ステップＳ２７）。
【００９０】
そして、ＦＰ解凍処理部４２３にて、受信リプライメッセージに対して、フィンガープリント・キャッシュ４４から検索された該フィンガープリントの値に対応するデータを付加し、プロキシ間で特別の情報を使用する場合には該情報を削除した後に、これを送信部４３からクライアント５０へ送信する（ステップＳ２８）。このとき、必要に応じて、リプライヘッダ内のデータ長を表すフィールド（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：フィールド）の値を、該フィンガープリントの値に対応するデータの長さに設定する。
【００９１】
一方、ステップＳ２５にて該リプライメッセージのリプライデータがＦＰ圧縮されていないものと判断されたならば（例えば図９（ａ）等の場合）、次の２つの作業を行う。
（１）ＦＰ解凍処理部４２３にて、プロキシ間で特別の情報を使用する場合には受信リプライメッセージから該情報を削除した後に、これを送信部４３からクライアント５０へ送信する（ステップＳ３０）。
（２）ＦＰキャッシュ管理部４２２にて、該リプライデータのフィンガープリントの値を求め（ステップＳ２９）、該フィンガープリントの値と、該リプライデータとを対応付けて（フィンガープリントの値をキーにして）、フィンガープリント・キャッシュ４４に登録する（ステップＳ３１）。
【００９２】
なお、上記の（１）と（２）は、いずれを先に行ってもよいし、並行して行ってもよい。
【００９３】
ところで、ステップＳ２６では、メッセージにフィンガープリントが記述されている。しかし、ステップＳ２９では、メッセージにフィンガープリントが記述されている場合に、該メッセージからフィンガープリントを得る方法と、メッセージにフィンガープリントが記述されてない場合に、リプライデータをもとにハッシュ関数等によってフィンガープリントの値を計算する方法とがある。なお、メッセージにフィンガープリントが記述されている場合であっても、リプライデータをもとにフィンガープリントの値を計算する方法も可能である。
また、ステップＳ２６／ステップＳ２９は、ステップＳ２４とステップＳ２５の間にて行うようにしても構わないし、ステップＳ２９は、ステップＳ３０とステップＳ３１の間にて行うようにしても構わない。
【００９４】
また、ステップＳ２４の判断とステップＳ２５の判断は、同時に行ってもよい。
【００９５】
次に、図２０に、サーバ側プロキシ３０からクライアント側プロキシ４０へフィンガープリント・キャッシュ登録されていないデータを転送するとともに当該フィンガープリント・キャッシュ登録する場合の動作例を示す。
【００９６】
（１）クライアント５０上のブラウザ等は、例えば、“／Ａ．ｃｇｉ”というＵＲＬでサーバ２０に、ＰＯＳＴメソッドのリクエストメッセージを出したとする。サーバ２０へのリクエストメッセージは、まず、クライアント側プロキシ４０に送られるように、ブラウザ等を設定しておく。
【００９７】
(2),(3)クライアント側プロキシ４０及び宛先となるサーバ２０に対応するサーバ側プロキシ３０により、該リクエストメッセージは、サーバ２０へ転送される。
【００９８】
（４）サーバ２０は、該リクエストメッセージに対する処理を行った後、サーバ側プロキシ３０に、そのリプライメッセージを転送する。
【００９９】
(5),(6)サーバ側プロキシ３０は、受信したリプライメッセージのリプライデータは要求元のクライアント側プロキシ４０について初めてのデータであるので、該リプライデータを要求元のクライアント側プロキシ４０に対応するフィンガープリント・キャッシュ３４に登録するとともに、該リプライメッセージを該クライアント側プロキシ４０へ転送する。
【０１００】
(7),(8)クライアント側プロキシ４０は、受信したリプライメッセージのリプライデータが初めてのデータであるので、該リプライデータをもとにフィンガープリントを求め、該リプライデータとともにフィンガープリント・キャッシュ４４に登録する。そして、該リプライメッセージを要求元のクライアント５０（上で動作するブラウザ等）へ転送する。
【０１０１】
続いて、図２１に、図２０の動作が行われてキャッシュ登録されているデータをサーバ側プロキシ３０からクライアント側プロキシ４０へ転送する場合の動作例を示す。
【０１０２】
（１）〜（４）は、図２０を参照して説明した動作における（１）〜（４）と同様である。
【０１０３】
(5),(6)サーバ側プロキシ４０は、サーバ２０から受け取ったリプライメッセージのリプライデータを、要求元のクライアント側プロキシ４０に対応するフィンガープリント・キャッシュ３４に登録されている該当するフィンガープリントで置き換え、該クライアント側プロキシ４０へ転送する。
【０１０４】
(7),(8)クライアント側プロキシ４０は、リプライメッセージのリプライデータがフィンガープリントで置き換えられていることを検出し、指定されたフィンガープリントを使ってフィンガープリント・キャッシュ４４から対応するデータを取り出し、これをリプライボディに入れた後に、該リプライメッセージを要求元のクライアント５０（上で動作するブラウザ等）へ転送する。
【０１０５】
さて、これまでは、サーバ側プロキシからクライアント側プロキシへ転送されるリプライメッセージを対象とする場合を中心に説明してきたが、もちろん、他のメッセージについても本発明は適用可能である。
【０１０６】
また、これまでは、サーバ側プロキシ３０からクライアント側プロキシ４０へデータを転送するときに、該データがフィンガープリント・キャッシュに登録されているデータと同じものである場合には、該データに代えて、対応するフィンガープリントを転送することで、ネットワークのトラフィックを軽減しているが、このＦＰ圧縮は、クライアント側プロキシ４０からサーバ側プロキシ３０へリクエストデータ等のデータを転送する場合に適用することも可能である。
【０１０７】
また、これまでは、１つのメッセージに含まれるデータ全体をＦＰ圧縮する対象（フィンガープリント・キャッシュに登録する対象）にしていたが、例えば、１つのメッセージに含まれるデータが所定の単位のデータの集合で構成される場合には、１つのメッセージに含まれる一部の単位データのみＦＰ圧縮する対象（フィンガープリント・キャッシュに登録する対象）にする構成も可能である。
【０１０８】
なお、以上の各機能は、ソフトウェアとして実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１０９】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０１１０】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１１１】
【発明の効果】
本発明によれば、サーバ装置側に設けられたサーバ側プロキシは、クライアント装置側に設けられたクライアント側プロキシから該クライアント装置が該サーバ装置へ宛てて発したリクエストデータを受信してサーバ装置へ転送した後に、該サーバ装置が該クライアント装置へ宛てて発した該リクエストデータへの返答であるリプライデータを受信してクライアント側プロキシへ転送するにあたって、受信したリプライデータから生成したフィンガープリントを、該リプライデータに関連付けて、該リプライデータの宛先となるクライアント装置に係るクライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持しておくことによって、サーバ装置からリプライデータを受信した場合に、そのフィンガープリントが該リプライデータの宛先となるクライアント装置に係るクライアント側プロキシに対応するクライアント側プロキシ毎フィンガープリント・キャッシュに保持されているリプライデータについては、該リプライデータを転送する代わりに対応するフィンガープリントを転送することで、それらサーバ側プロキシとクライアント側プロキシとの間の転送データ量を削減することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るコンピュータ・ネットワーク・システムの構成例を示す図
【図２】同実施形態に係るコンピュータ・ネットワーク・システムの他の構成例を示す図
【図３】同実施形態に係るコンピュータ・ネットワーク・システムのさらに他の構成例を示す図
【図４】同実施形態に係るコンピュータ・ネットワーク・システムのさらに他の構成例を示す図
【図５】同実施形態で使用するフィンガープリントについて説明するための図
【図６】同実施形態で使用するフィンガープリント・キャッシュについて説明するための図
【図７】同実施形態で使用するメッセージ・フォーマットの一例を示す図
【図８】同実施形態で使用するメッセージ・フォーマットの他の例を示す図
【図９】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１０】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１１】同実施形態で使用するメッセージ・フォーマットのさらに他の例を示す図
【図１２】同実施形態に係るサーバ側プロキシの構成例を示す図
【図１３】同実施形態に係るクライアント側プロキシの構成例を示す図
【図１４】同実施形態におけるフィンガープリント・キャッシュの一例について説明するための図
【図１５】同実施形態におけるフィンガープリント・キャッシュの他の例について説明するための図
【図１６】同実施形態におけるフィンガープリント・キャッシュのさらに他の例について説明するための図
【図１７】同実施形態におけるフィンガープリント・キャッシュのさらに他の例について説明するための図
【図１８】同実施形態に係るサーバ側プロキシの手順例を示すフローチャート
【図１９】同実施形態に係るクライアント側プロキシの手順例を示すフローチャート
【図２０】同実施形態に係るサーバ側プロキシとクライアント側プロキシとの間のデータ転送について説明するための図
【図２１】同実施形態に係るサーバ側プロキシとクライアント側プロキシとの間のデータ転送について説明するための図
【図２２】従来のコンピュータ・ネットワーク・システムについて説明するための図
【符号の説明】
２…ＡＳＰサーバセンター
４…ユーザオフィス
１２…ＡＳＰサーバセンター内ＬＡＮ
１４…ＷＡＮ
１６…ユーザオフィス内ＬＡＮ
２０…サーバ装置
３０…サーバ側プロキシ装置
４０…クライアント側プロキシ装置
５０…クライアント装置
３１，４１…受信部
３２，４２…処理部
３３，４３…送信部
３４，４４…フィンガープリント・キャッシュ
３５，４５…ＵＲＬ・ＦＰテーブル
３２１，４２１…ＦＰ圧縮判定部
３２２，４２２…フィンガープリント・キャッシュ管理部
３２３…ＦＰ圧縮処理部
４２３…ＦＰ解凍処理部
３２４，４２４…ＵＲＬキャッシュ処理部
３２５，４２５…ＦＰ解凍・解凍処理部
【図１】
0003943867.tif 000002
【図２】
0003943867.tif 000003
【図３】
0003943867.tif 000004
【図４】
0003943867.tif 000005
【図５】
0003943867.tif 000006
【図６】
0003943867.tif 000007
【図７】
0003943867.tif 000008
【図８】
0003943867.tif 000009
【図９】
0003943867.tif 000010
【図１０】
0003943867.tif 000011
【図１１】
0003943867.tif 000012
【図１２】
0003943867.tif 000013
【図１３】
0003943867.tif 000014
【図１４】
0003943867.tif 000015
【図１５】
0003943867.tif 000016
【図１６】
0003943867.tif 000017
【図１７】
0003943867.tif 000018
【図１８】
0003943867.tif 000019
【図１９】
0003943867.tif 000020
【図２０】
0003943867.tif 000021
【図２１】
0003943867.tif 000022
【図２２】
0003943867.tif 000023