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