JP2003345708A - データ転送装置、データ転送方法及びプログラム - Google Patents

Abstract

(57)【要約】 【課題】 ネットワークの負荷を軽減できるプロキシ装
置を提供すること。 【解決手段】 サーバ側プロキシ３０からクライアント
側プロキシ４０へ新たな内容のデータを転送するにあた
って、両プロキシにて、データとそのフィンガープリン
トとを対応付けて登録しておく。ただし、該データが既
登録の他のデータを元に圧縮できる場合には、該データ
の代わりに圧縮データを登録しておく。プロキシ３０か
らプロキシ４０へ登録されたフィンガープリントと同じ
フィンガープリントを持つデータを転送するにあたって
は、該データの代わりに該フィンガープリントを転送す
る。プロキシ４０では、受信したフィンガープリントに
対応して登録されているデータを取り出すとともに、そ
れが圧縮データならば、これを解凍して元のデータにす
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、他の装置のために
データ転送を行うデータ転送装置、データ転送方法及び
プログラムに関する。

【０００２】

【従来の技術】ネットワークを介して様々なサービスを
提供するサーバと、所望のサービスをサーバに対して要
求するクライアントとから構成される、クライアント・
サーバ型の情報システムが広く利用されている。特に、
インターネット上でＨＴＴＰプロトコルを使って通信す
るＷｅｂサーバとクライアントとからなるWorld Wide W
ebシステム（あるいは単にＷｅｂとも呼ばれる）は、大
変広く利用されているクライアント・サーバ型の情報シ
ステムである。通常、サーバ上ではサーバプログラムが
動作し、クライアント上ではブラウザなどの所定のツー
ル（プログラム）が動作する。インターネット上で提供
されるサービスの内容も多岐に渡っており、ネットワー
ク経由で文字、静止画像、動画像、音声等の情報（例え
ば、ホームページ、電子メール、デジタルコンテンツな
ど）や、プログラムなどを提供、配信あるいは転送など
するサービス、また商品を販売するための電子店舗サー
ビス、座席や部屋等の予約サービス、種々の契約の仲介
サービスなど、種々のサービスが既に存在し、また次々
と新たな形態のサービスが出現している。

【０００３】ところで、Ｗｅｂのようなクライアント・
サーバ型の情報システムにおいては、提供されるサービ
スがどのような形態のものであろうと、基本的にはクラ
イアント・サーバ間でデータ転送が行われることによっ
てサービスが提供される。したがって、クライアントと
サーバとの間で通信に用いるネットワークの容量（バン
ド幅）が、システム全体のボトルネックになりやすい。
そこで、通常、ネットワークの負荷を軽減させるために
キャッシュ技術が用いられる。

【０００４】Ｗｅｂシステムの場合、クライアント上で
動作するブラウザ等はキャッシュ機構を使用するものが
多く、最近アクセスしたデータをキャッシュしている。
ＷｅｂではＵＲＬと呼ばれる名前で情報やサービスを指
定してアクセスがなされるので、クライアント上のキャ
ッシュは、過去にＷｅｂサーバに要求した情報やサービ
スの結果として返されるデータのうちでキャッシュ可能
なものを、そのＵＲＬと対応させてキャッシュに記録し
ている。この場合、キャッシュ内にあるものと同じＵＲ
Ｌの情報やサービスのリクエストがあった際に、そのキ
ャッシュ内の応答データが古くなっていないと判断でき
るならば、そのデータを返すことで、Ｗｅｂサーバとの
間の通信を無くすことができる。

【０００５】企業のオフィス内のＬＡＮあるいは研究機
関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数の
ユーザがいる場合、該ＬＡＮとインターネットとの間に
プロキシサーバを置き、プロキシサーバにキャッシュ機
構を設けるようにすることも多い。クライアント内のキ
ャッシュ（例えば、ブラウザのキャッシュ）は、当該ク
ライアント・ユーザに専用のキャッシュとして動作する
が、ＬＡＮ上のプロキシサーバのキャッシュは、複数の
クライアント・ユーザに共有のキャッシュとして動作す
る。そのため、後者では、過去に他人（他クライアン
ト）がアクセスしたＵＲＬに対してアクセスする際にも
キャッシュが効く。

【０００６】さて、Ｗｅｂにおいて、クライアントとサ
ーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行わ
れる。ＨＴＴＰプロトコルは、クライアントからサーバ
へ送る「リクエストメッセージ」と、それに答えてサー
バからクライアントへ応答を返す「リプライメッセー
ジ」とが組になっている。

【０００７】リクエストメッセージは、「リクエストヘ
ッダ」と「リクエストボディ」からなる。リクエストヘ
ッダには、アクセスしたい情報やサービスを指定するＵ
ＲＬやアクセスの種類を示すメソッド名、その他アクセ
スに必要な各種の情報が入る。リクエストボディには、
サーバに送るデータを入れる。リクエストボディに入っ
ているデータを「リクエストデータ」とも呼ぶ。

【０００８】リプライメッセージは、「リプライヘッ
ダ」と「リプライボディ」からなる。リプライヘッダに
は、処理結果のステータスなどの情報が入り、リプライ
ボディには要求された情報や要求されたサービスの処理
結果などのデータが入る。リプライボディに入っている
データを「リプライデータ」とも呼ぶ。

【０００９】リクエストメッセージのメソッドとして
は、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユ
ーザの持つデータをサーバに書き込む「ＰＵＴメソッ
ド」、リクエストの応じて処理した結果を送り返しても
らう「ＰＯＳＴメソッド」が、情報やサービスのアクセ
スに用いられる主要なものである。その他、ＤＥＬＥＴ
Ｅなどのメソッドが定義されている。

【００１０】多くの場合、ＧＥＴメソッドのリクエスト
メッセージのリクエストボディ、ＰＵＴメソッドのリプ
ライメッセージのリプライボディは空である。ＰＯＳＴ
メソッドのリクエストメッセージのリクエストボディに
は、必要に応じてサーバ側での処理に用いる情報が入
り、ＰＯＳＴメソッドのリプライメッセージのリプライ
ボディには、その処理の結果のデータが入る。

【００１１】ＧＥＴメソッドでサーバから読み出すデー
タは、読み出す毎にサーバ側で生成する「動的データ」
と、既にサーバ側で記憶しているデータをそのまま送り
返す「静的データ」に分けることができる。これらのう
ち、動的データについては、同じＵＲＬでも読み出す度
に内容が異なる可能性があるので、多くの場合、サーバ
はキャッシュ不可の指定をそのリプライメッセージのヘ
ッダに入れて送り返す。したがって、Ｗｅｂのデータで
キャッシュの対象になるのは、静的データの部分であ
る。この静的データは、不特定多数のユーザが参照して
構わない「共有データ」と、ユーザ認証することで特定
のユーザだけがアクセスできるようにアクセス制御を行
う「プライベートデータ」に分けることができる。前者
の共有データは、どのようなキャッシュでもキャッシュ
可能である。しかしながら、後者のプライベートデータ
は、プロキシサーバなどの共有キャッシュでは、キャッ
シュ不可である（プライベートデータは必ずサーバで認
証して送り返す必要があるので）。ただし、ブラウザな
どの個人専用のキャッシュの場合には、プライベートデ
ータでもキャッシュは可能である。

【００１２】ＰＯＳＴメソッドは、サーバ側で処理をし
た結果を返すので、一般的にサーバはキャッシュ不可の
指定をリプライメッセージのヘッダに入れて結果を送り
返す。そのため、通常はキャッシュの対象にはならな
い。

【００１３】ＰＵＴメソッドは、データをサーバに送る
ものなので、キャッシュは何も処理をしない。

【００１４】

【発明が解決しようとする課題】従来のＷｅｂのキャッ
シュは、静的コンテンツをキャッシュの対象にしてい
る。かつては、Ｗｅｂで公開される情報やサービスに
は、情報の更新頻度がそれほど高くなく、不特定多数の
人に公開されているものが多かったため、静的コンテン
ツの割合は非常に高く、従来のキャッシュ技術でもネッ
トワークの負荷の軽減に有効であった。

【００１５】しかしながら、ＷｅｂベースのＡＳＰ(App
lication Service Provider)のように、ユーザがＷｅｂ
ブラウザを使って、ネットワーク経由でサーバ上の情報
やサービスにアクセスするシステムが普及するにつれ
て、下記のように従来のキャッシュ技術では対応できな
いデータが増加している。 ・ユーザの認証を行い、アクセスできるユーザを制限し
ているので、プライベートデータが多い。 ・バックエンドのデータベースを参照して生成する動的
データが多い。 ・帳票処理や検索などＰＯＳＴメソッドを使う場合が多
い。 ・グループ内の情報共有のためにＰＵＴメソッドを使う
場合が多い。 この結果、キャッシュ技術のみではネットワークの負荷
を軽減する手法として有効に機能しなくなってきてい
る。

【００１６】本発明は、上記事情を考慮してなされたも
ので、データ転送装置間を接続するネットワークの負荷
をより軽減することができるキャッシュ技術・圧縮技術
を備えたデータ転送装置、データ転送方法及びプログラ
ムを提供することを目的とする。

【００１７】

【課題を解決するための手段】本発明に係るデータ転送
装置は、過去に他のデータ転送装置へ送信したデータ又
は該データを圧縮して表現した圧縮データと、該データ
をもとに生成して該データに割り当てた名前とを対応付
けて保持する保持手段と、第１の通信装置から、前記他
のデータ転送装置を介した第２の通信装置を宛先とする
データを受信する受信手段と、この受信手段により前記
データを受信した際に、該受信したデータの内容をもと
に生成した名前が、前記保持手段に保持されている場合
には、該受信したデータの代わりに該名前を送信するた
めの処理を行い、該名前が、前記保持手段に保持されて
いない場合には、前記保持手段に保持されている他のデ
ータを参照データとし、該参照データに対応する前記名
前を利用して、該受信したデータを圧縮して表現するこ
とが可能であるならば、該受信したデータを圧縮して表
現した圧縮データと該名前とを対応付けて前記保持手段
に保持するとともに、該受信したデータの代わりに該圧
縮データを送信するための処理を行い、圧縮して表現す
ることが可能でないならば、該受信したデータと該名前
とを対応付けて前記保持手段に保持するとともに、該受
信したデータを送信するための処理を行う処理手段と、
前記処理手段の処理に応じて前記データの代わりの前記
名前、前記データの代わりの前記圧縮データ又は前記デ
ータを、前記他のデータ転送装置へ送信する送信手段と
を備えたことを特徴とする。

【００１８】また、本発明に係るデータ転送装置は、過
去に他のデータ転送装置から受信したデータ又は該デー
タを圧縮して表現した圧縮データと、該データをもとに
生成して該データに割り当てた名前と、圧縮データであ
るか否か示す識別情報とを対応付けて保持する保持手段
と、第１の通信装置から送信され、第２の通信装置を宛
先とするデータ、該データの代わりに該データを圧縮し
て表現した圧縮データ又は該データの代わりに該データ
の内容をもとに生成して該データに割り当てられた名前
を、前記他のデータ転送装置を介して受信する受信手段
と、この受信手段により前記データを受信した場合に
は、該受信したデータと該データに割り当てられるべき
名前と圧縮データでないことを示す識別情報とを対応付
けて前記保持手段に保持するとともに、該受信したデー
タを送信するための処理を行い、前記データの代わりに
前記圧縮データを受信した場合には、該受信したデータ
と該データに割り当てられるべき名前と圧縮データであ
ることを示す識別情報とを対応付けて前記保持手段に保
持するとともに、該受信した圧縮データを解凍し、該解
凍したデータを送信するための処理を行い、前記データ
の代わりに前記名前を受信した場合には、前記保持手段
に該受信した名前に対応付けて保持されている前記識別
情報を参照し、該データが圧縮データでないならば、該
保持手段から該受信した名前に対応付けて保持されてい
るデータを取得し、該取得したデータを送信するための
処理を行い、該データが圧縮データであるならば、該保
持手段から該受信した名前に対応付けて保持されている
圧縮データを取得し、該取得した圧縮データを解凍し、
該解凍したデータを送信するための処理を行う処理手段
と、前記処理手段の処理に応じて前記受信したデータ、
前記解凍したデータ又は前記取得したデータを、前記第
２の通信装置へ送信する送信手段とを備えたことを特徴
とする。

【００１９】また、本発明に係るデータ転送方法は、第
１の通信装置から、他のデータ転送装置を介した第２の
通信装置を宛先とするデータを受信し、受信された前記
データの内容をもとに生成した名前が、過去に前記他の
データ転送装置へ送信したデータ又は該データを圧縮し
て表現した圧縮データと該データをもとに生成して該デ
ータに割り当てた名前とを対応付けて保持する前記保持
手段に保持されているか否か判断し、保持されている場
合には、受信された前記データの代わりに前記名前を前
記他のデータ転送装置へ送信し、保持されていない場合
には、前記保持手段に保持されている他のデータを参照
データとし、該参照データに対応する前記名前を利用し
て、受信された前記データを圧縮して表現することが可
能であるか否か判断し、可能であるならば、受信された
前記データを圧縮して表現した圧縮データと前記名前と
を対応付けて前記保持手段に保持するとともに、受信さ
れた前記データの代わりに該圧縮データを前記他のデー
タ転送装置へ送信し、圧縮して表現することが可能でな
いならば、受信された前記データと該名前とを対応付け
て前記保持手段に保持するとともに、受信された前記デ
ータを前記他のデータ転送装置へ送信することを特徴と
する。

【００２０】また、本発明に係るデータ転送方法は、第
１の通信装置から送信され、第２の通信装置を宛先とす
るデータ、該データの代わりに該データを圧縮して表現
した圧縮データ又は該データの代わりに該データの内容
をもとに生成して該データに割り当てられた名前を、他
のデータ転送装置を介して受信し、前記他のデータ転送
装置から前記データを受信した場合には、過去に他のデ
ータ転送装置から受信したデータ又は該データを圧縮し
て表現した圧縮データと該データをもとに生成して該デ
ータに割り当てた名前と圧縮データであるか否か示す識
別情報とを対応付けて保持する保持手段に、該受信した
データと該データに割り当てられるべき名前と圧縮デー
タでないことを示す識別情報とを対応付けて保持すると
ともに、該受信したデータを前記第２の通信装置へ送信
し、前記データの代わりに前記圧縮データを受信した場
合には、該受信したデータと該データに割り当てられる
べき名前と圧縮データであることを示す識別情報とを対
応付けて前記保持手段に保持するとともに、該受信した
圧縮データを解凍し、該解凍したデータを前記第２の通
信装置へ送信し、前記データの代わりに前記名前を受信
した場合には、前記保持手段に該受信した名前に対応付
けて保持されている前記識別情報を参照し、該データが
圧縮データでないならば、該保持手段から該受信した名
前に対応付けて保持されているデータを取得し、該取得
したデータを前記第２の通信装置へ送信し、該データが
圧縮データであるならば、該保持手段から該受信した名
前に対応付けて保持されている圧縮データを取得し、該
取得した圧縮データを解凍し、該解凍したデータを前記
第２の通信装置へ送信することを特徴とする。

【００２１】また、本発明は、過去に他のデータ転送装
置へ送信したデータ又は該データを圧縮して表現した圧
縮データと、該データをもとに生成して該データに割り
当てた名前とを対応付けて記憶装置に保持する機能と、
第１の通信装置から、前記他のデータ転送装置を介した
第２の通信装置を宛先とするデータを受信した際に、該
受信したデータの内容をもとに生成した名前が、前記記
憶装置に保持されている場合には、該受信したデータの
代わりに該名前を送信するための処理を行い、該名前
が、前記記憶装置に保持されていない場合には、前記記
憶装置に保持されている他のデータを参照データとし、
該参照データに対応する前記名前を利用して、該受信し
たデータを圧縮して表現することが可能であるならば、
該受信したデータを圧縮して表現した圧縮データと該名
前とを対応付けて前記記憶装置に保持するとともに、該
受信したデータの代わりに該圧縮データを送信するため
の処理を行い、圧縮して表現することが可能でないなら
ば、該受信したデータと該名前とを対応付けて前記記憶
装置に保持するとともに、該受信したデータを送信する
ための処理を行う機能とをコンピュータに実現させるた
めのプログラムである。

【００２２】また、本発明は、過去に他のデータ転送装
置から受信したデータ又は該データを圧縮して表現した
圧縮データと、該データをもとに生成して該データに割
り当てた名前と、圧縮データであるか否か示す識別情報
とを対応付けて記憶装置に保持する機能と、第１の通信
装置から送信され、第２の通信装置を宛先とするデー
タ、該データの代わりに該データを圧縮して表現した圧
縮データ又は該データの代わりに該データの内容をもと
に生成して該データに割り当てられた名前を、前記他の
データ転送装置を介して受信する機能と、この受信機能
により前記データを受信した場合には、該受信したデー
タと該データに割り当てられるべき名前と圧縮データで
ないことを示す識別情報とを対応付けて前記記憶装置に
保持するとともに、該受信したデータを送信するための
処理を行い、前記データの代わりに前記圧縮データを受
信した場合には、該受信したデータと該データに割り当
てられるべき名前と圧縮データであることを示す識別情
報とを対応付けて前記記憶装置に保持するとともに、該
受信した圧縮データを解凍し、該解凍したデータを送信
するための処理を行い、前記データの代わりに前記名前
を受信した場合には、前記記憶装置に該受信した名前に
対応付けて保持されている前記識別情報を参照し、該デ
ータが圧縮データでないならば、該記憶装置から該受信
した名前に対応付けて保持されているデータを取得し、
該取得したデータを送信するための処理を行い、該デー
タが圧縮データであるならば、該記憶装置から該受信し
た名前に対応付けて保持されている圧縮データを取得
し、該取得した圧縮データを解凍し、該解凍したデータ
を送信するための処理を行う機能とをコンピュータに実
現させるためのプログラムである。

【００２３】なお、装置に係る本発明は方法に係る発明
としても成立し、方法に係る本発明は装置に係る発明と
しても成立する。また、装置または方法に係る本発明
は、コンピュータに当該発明に相当する手順を実行させ
るための（あるいはコンピュータを当該発明に相当する
手段として機能させるための、あるいはコンピュータに
当該発明に相当する機能を実現させるための）プログラ
ムとしても成立し、該プログラムを記録したコンピュー
タ読取り可能な記録媒体としても成立する。

【００２４】本発明によれば、データ転送装置間でデー
タとその名前との対応を保持し、この対応を保持してい
るデータについては、データ本体を転送する代わりに対
応する名前を転送することで、データ転送装置間の転送
データ量を削減させることができる。例えば、ＧＥＴメ
ソッドのリプライメッセージがプライベートデータであ
っても、これをフィンガープリントにより圧縮してデー
タ転送装置間を転送することができるようになる。ま
た、例えば、ＧＥＴメソッドのリプライメッセージが動
的データであっても、内容が同じデータなら、これをフ
ィンガープリントにより圧縮してデータ転送装置間を転
送することができるようになる。また、例えば、ＰＯＳ
Ｔメソッドであっても、結果が同じデータなら、これを
フィンガープリントにより圧縮してデータ転送装置間を
転送することができるようになる。

【００２５】また、本発明によれば、データに対応する
名前が保持されていないために、データを転送するの代
わりに対応する名前を転送することができない場合であ
っても、保持されている参照データに対応する名前を利
用して当該データを圧縮して表現した圧縮データを転送
することによって、データ転送装置間の転送データ量を
削減することができる。例えば、ＧＥＴメソッドやＰＯ
ＳＴメソッドのリプライデータが以前にアクセスしたデ
ータと一部が異なる場合には、差分転送することで、デ
ータ量を削減することができる。また、例えば、ＰＵＴ
メソッドやＰＯＳＴメソッドのリクエストデータが以前
に送ったデータと一部が異なる場合には、差分転送する
ことでデータ量を削減することができる。

【００２６】また、本発明によれば、データ圧縮が可能
な場合には、データの代わりに圧縮データを保存するこ
とにより、記憶装置（メモリやハードディスクなど）を
有効利用できる。

【００２７】

【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。

【００２８】以下では、ＷＡＮがインターネットであ
り、クライアントはユーザオフィスＬＡＮに接続された
ものであり、ＨＴＴＰプロトコルが使用されるような場
合を例にとって説明するが、本発明は、ＷＡＮがインタ
ーネット以外のものでも、クライアントがオフィス以外
の例えば家庭内ＬＡＮ等に設置されたものでも、ＨＴＴ
Ｐ以外のプロトコルが使用されるものでも適用可能であ
る。

【００２９】図４９に本発明を適用するコンピュータ・
ネットワーク・システムの基本的な構成例を示す。この
構成例では、ＡＳＰサーバセンター２内のローカルエリ
アネットワーク（ＬＡＮ）１２とユーザオフィス４内の
ローカルエリアネットワーク（ＬＡＮ）１６との間が、
インターネットや専用回線などの広域ネットワーク（Ｗ
ＡＮ）１４を介して接続されており、サーバ２０とクラ
イアント５０とがＬＡＮ１２・ＷＡＮ１４・ＬＡＮ１６
を介して通信可能になっている。ＬＡＮ１２には１また
は複数のサーバが接続され、ＬＡＮ１６には１または複
数のクライアントが接続される。

【００３０】ＷｅｂベースのＡＳＰは、センター２に設
置したサーバ２０からＷＡＮ１４を介して様々なアプリ
ケーションプログラムによるサービスを提供し、ユーザ
はオフィス４に設置されたクライアント上のＷｅｂブラ
ウザ等を使ってそれらのサービスにアクセスする。この
ような利用形態においては、オフィス内ＬＡＮ１６とセ
ンター内ＬＡＮ１２とをつなぐネットワーク、特にイン
ターネットなどのＷＡＮ１４の実効的な通信容量（バン
ド幅）は、ＬＡＮ１２やＬＡＮ１６よりも低く、そこが
性能上のボトルネックになって通信遅延が発生し、アプ
リケーションの応答性能が低下するという問題が発生す
る。そこで、本実施形態では、例えば図１に示すよう
に、センター内ＬＡＮ１２とオフィス内ＬＡＮ１６をつ
なぐＷＡＮ１４の両端に、サーバ側プロキシ３０及びク
ライアント側プロキシ４０なる２つのモジュールを設置
し、サーバ２０とクライアント５０がＬＡＮ１２・プロ
キシ３０・ＷＡＮ１４・プロキシ４０・ＬＡＮ１６を介
して通信するにあたって、それらプロキシ間で後述する
フィンガープリント圧縮（ＦＰ圧縮）や差分圧縮を行っ
て通信データ量を低減することで、広域ネットワークの
ボトルネックを解消する。さらに、それらプロキシで
は、詳しくは後述するように、圧縮に必要なデータの一
部を差分情報によって保持することで、必要なキャッシ
ュ量を削減する。

【００３１】本実施形態のサーバ２０、サーバ側プロキ
シ３０、クライアント側プロキシ４０、クライアント５
０は、いずれも、計算機上でソフトウェア（サーバ・プ
ログラム、サーバ側プロキシ・プログラム、クライアン
ト側プロキシ・プログラム、クライアント・プログラ
ム）を動作させる形で実現することができる。この場合
に、所望の機能を有する、ＯＳやドライバソフト、パケ
ット通信用ソフト、暗号ソフト等といったソフトウェ
ア、あるいは通信インタフェース装置や外部記憶装置や
入出力装置等といったハードウェアが、必要に応じて計
算機に搭載あるいは接続される。また、この場合に、ユ
ーザあるいは管理者などからの情報の入力やユーザへの
情報の呈示等のために、グラフィカル・ユーザ・インタ
フェース（ＧＵＩ）を用いると好ましい。

【００３２】サービスを利用するためにユーザが使用す
るクライアント５０上では、その目的に応じて例えばＷ
ｅｂブラウザ等のプログラムが動作する。ユーザは、例
えば、Ｗｅｂブラウザからインターネットを介し情報転
送あるいは注文受付等の所望のサービスを提供するサー
バにリクエストメッセージを出し、リプライメッセージ
を受けることによって、またはこれを適宜繰り返すこと
によって、サービスを利用する。なお、Ｗｅｂブラウザ
等の汎用のソフトウェアではなく、特定のサービスを利
用するための専用のソフトウェアなどの他のものが用い
られても構わない。また、クライアントは、汎用の計算
機ではなく、例えばインターネット機能を有する携帯電
話端末等でもよい。

【００３３】サーバ２０上では、所定のサーバ・プログ
ラムが動作し、クライアント５０のユーザに対して、当
該サーバ・サイトに固有のサービスを提供する。

【００３４】サーバ側プロキシ３０は、図１のように、
サーバセンター内ＬＡＮ１２とＷＡＮ１４の両方に接続
し、トランスペアレント・プロキシとして動作するよう
に設置して実施してもよい。また、図２のようにサーバ
センター内ＬＡＮ１２上に設置して実施してもよい。ま
た、図３のようにサーバ側プロキシ３０の機能をサーバ
２０に内蔵するように実施してもよい。

【００３５】同様にクライアント側プロキシ４０は、図
１のように、ユーザオフィス内ＬＡＮ１６とＷＡＮ１４
の両方に接続し、トランスペアレント・プロキシとして
動作するように設置して実施してもよい。また、図２の
ようにユーザオフィス内ＬＡＮ１６上に設置して実施し
てもよい。また、図３のようにクライアント側プロキシ
４０の機能をクライアント５０上で動作するブラウザ等
に内蔵するように実施してもよい。あるいは、ブラウザ
等の動作するクライアント５０上に、個人用のクライア
ント側プロキシ４０を動作させるように実施してもよ
い。

【００３６】なお、サーバ側プロキシ３０とクライアン
ト側プロキシ４０とは、図１〜図３などのように同じ形
態であってもよいし、異なる形態であってもよい。

【００３７】以下では、フィンガープリント・キャッシ
ュ、これを利用したＦＰ圧縮及び差分圧縮、データ管理
について、それらの概要を説明する。

【００３８】なお、以下、サーバ側プロキシ３０とクラ
イアント側プロキシ４０との間のデータ転送方向として
いずれか一方向を例にとって説明する際には、サーバ側
プロキシ３０からクライアント側プロキシ４０へデータ
を転送する場合を例にとって説明していくが、クライア
ント側プロキシ４０からサーバ側プロキシ３０へデータ
を転送する場合にも同様のことが可能である。

【００３９】本実施形態のサーバ側プロキシ３０とクラ
イアント側プロキシ４０は、フィンガープリント・キャ
ッシュと呼ぶキャッシュ機構を持つ。フィンガープリン
ト・キャッシュは、フィンガープリント（ＦＰ）と呼ぶ
名前によって、ＨＴＴＰプロトコルでやりとりされるデ
ータを記録・管理する。

【００４０】フィンガープリントは、図４に例示するよ
うに、ＨＴＴＰプロトコルでやり取りされるデータ（図
４ではコンテンツ）の内容から、あらかじめ決められた
計算方法（図４ではハッシュ関数）で決定される、短い
数値である。この数値は、可変長でもよいが、処理の容
易さの観点では、固定長の数値の方が扱いやすい。

【００４１】フィンガープリントを計算する方法として
は、良く知られているＭＤ−５やＳＨＡ−１などのハッ
シュ関数を用いることができる。これらのハッシュ関数
は、データに対する電子署名などに使われており、任意
のデータが与えられると、ＭＤ−５の場合は１２８ビッ
トの数値に、ＳＨＡ−１の場合は１６０ビットの数値
に、変換することができる。これらのハッシュ関数の特
徴は、２つのデータＸ１、Ｘ２が与えられ、データＸ１
とデータＸ２とが同じであれば、データＸ１に対して計
算したハッシュ値とデータＸ２に対して計算したハッシ
ュ値とは等しくなるが、異なる２つのデータＡ、Ｂが与
えられた場合には、データＡに対して計算したハッシュ
値とデータＢに対して計算したハッシュ値とは、非常に
高い確率で異なるものになることである（原理上は、異
なる２つのデータＡ、Ｂに対してそれぞれ計算したハッ
シュ値が同じになる場合があるが、その確率は実用上無
視できるくらいに小さい）。

【００４２】図５に示すように、サーバ側プロキシ３０
やクライアント側プロキシ４０の持つフィンガープリン
ト・キャッシュ（２６０）は、過去にＨＴＴＰプロトコ
ルでやり取りされたデータ本体（２６１）または後述す
る差分圧縮により生成されたデータ（２６４）を、その
やりとりされたデータから計算して求めたフィンガープ
リントの値（２６２）を名前として、記録されているデ
ータがデータ本体かそれとも差分圧縮により生成された
データかを示す差分圧縮データ識別子（以下、圧縮識別
子と記述する）（２６３）とともに記録・管理する。な
お、以下では、該識別子＝０が“記録されているデータ
はデータ本体である”ことを示し、該識別子＝１が“記
録されているデータが差分圧縮により生成されたデータ
である”ことを示すものとした例で説明するが、これに
限定されるものではない。

【００４３】例えば、ＨＴＴＰプロトコルでサーバ側プ
ロキシ３０からクライアント側プロキシ４０へデータを
転送する場合に、サーバ側プロキシ３０は、当該データ
のフィンガープリントを計算し、そのフィンガープリン
トに対応するデータがフィンガープリント・キャッシュ
に入っていてかつ圧縮識別子が０であれば、キャッシュ
に存在するデータは差分圧縮により生成されたデータで
はないが、当該データ（と同じ内容のデータ）は過去に
転送したことがあるので、当該データを転送せずに、対
応するフィンガープリントの値を転送する。フィンガー
プリントを受け取ったクライアント側プロキシ４０は、
当該フィンガープリントの値に対応するデータをフィン
ガープリント・キャッシュから取り出すことで、転送す
べきデータを再現することができる。

【００４４】また例えば、上記の場合に、サーバ側プロ
キシ３０は、計算したフィンガープリントに対応するデ
ータがフィンガープリント・キャッシュに入っていてか
つ圧縮識別子が１であれば、キャッシュに存在するデー
タは差分圧縮により生成されたデータであり、当該受信
データ（と同じ内容のデータ）に対して過去に差分圧縮
が成功し、差分情報を転送したことがあることがわか
り、当該データを転送せずに、対応するフィンガープリ
ントの値を転送する。フィンガープリントを受け取った
クライアント側プロキシ４０は、当該フィンガープリン
トの値に対応するデータをフィンガープリント・キャッ
シュから取り出して差分圧縮されているデータを解凍す
ることで、転送すべきデータを再現することができる。

【００４５】このような方式（すなわち、フィンガープ
リントによるデータの圧縮→フィンガープリントの転送
→フィンガープリントによるデータの解凍）により、過
去に送ったものと同じデータ（データ本体あるいは差分
圧縮により生成されたデータ）ならばフィンガープリン
トの値を送るだけでよいので、ネットワークを流れるデ
ータ量を大幅に削減することができる。

【００４６】なお、上記の場合に、計算したフィンガー
プリントに対応するデータがフィンガープリント・キャ
ッシュに入っていないものについては、今回は、後述す
る差分圧縮により生成されたデータまたはデータ本体を
転送するとともに、フィンガープリント・キャッシュへ
の登録を行うことによって、次回からは、ＦＰ圧縮によ
るフィンガープリントの転送ができるようになる。

【００４７】説明上、サーバ側プロキシ３０とクライア
ント側プロキシ４０との間でのデータ転送にあたり、フ
ィンガープリント・キャッシュを利用してメッセージ・
ボディーのデータをフィンガープリントに置き換えて転
送情報量を圧縮することを、フィンガープリント圧縮
（ＦＰ圧縮）と呼ぶものとする。

【００４８】続いて、差分圧縮について説明する。

【００４９】上記のＦＰ圧縮では、データに対するフィ
ンガープリントを用いてデータの同一性を高速に判断
し、フィンガープリント・キャッシュに登録されている
データと同じデータはプロキシ間で転送せず、代わりに
当該データに対するフィンガープリントを転送するよう
にして、ネットワークの負荷を低減させる。しかし、フ
ィンガープリント・キャッシュに登録されているデータ
と異なるデータは、たとえ大部分は同じ内容であっても
ＦＰ圧縮を適用できない。そこで、本実施形態では、Ｆ
Ｐ圧縮できない場合であっても、フィンガープリント・
キャッシュに登録されている１または複数のデータを参
照データとして、参照データのフィンガープリントや、
参照データに対する差分情報など転送すべきデータを復
元するための情報によって、転送データを表現すること
によって、少ない情報量で転送データを表現し、なるべ
く転送データ量を減らすようにしている。すなわち、フ
ィンガープリント・キャッシュの中のデータを辞書とし
て使って、その中から取り出せるデータは送らないよう
にする。

【００５０】説明上、サーバ側プロキシ３０とクライア
ント側プロキシ４０との間でのデータ転送にあたり、フ
ィンガープリント・キャッシュを利用してメッセージ・
ボディーのデータを参照データのフィンガープリント等
に置き換えて転送情報量を圧縮することを、差分圧縮と
呼ぶものとする。また、この差分圧縮により生成された
転送データを、差分圧縮データと呼ぶものとする。

【００５１】なお、このようなフィンガープリントを利
用した差分圧縮は、転送すべきデータと参照データとの
間の関係を予め取り決めておく必要がなという利点も得
られる。すなわち、従来の差分転送では、予め双方で何
をベースに差分を取るかを決める必要があるため、差分
転送をＷｅｂシステムに実際に用いようとすると、この
ＵＲＬのデータはこのデータをベースに差分を取るとい
うようなルールを、双方に登録する手段が必要であり、
任意のデータに対して有効に機能させることは不可能で
あった。これに対して、本差分圧縮方法は、フィンガー
プリント・キャッシュの中にあるデータを参照データと
して差分を取ることで、差分のベースを予め決めておか
なくても、差分によるデータの圧縮の効果を得ることが
できる。

【００５２】次に、本実施形態のデータ管理方法につい
て説明する。

【００５３】本実施形態では、サーバ側プロキシ３０に
おいてサーバ２０から受信したリプライデータに対して
差分圧縮が成功した場合、サーバ側プロキシ３０は差分
圧縮により生成された差分圧縮データをクライアント側
プロキシ４０に送信するとともに、自分自身のフィンガ
ープリント・キャッシュ２６０には、該リプライデータ
から取得したフィンガープリントと該差分圧縮データと
を記録・管理する。この際、記録・管理されているデー
タが差分圧縮データであることを示すために、圧縮識別
子を１にセットする。

【００５４】クライアント側プロキシ４０においては、
サーバ側プロキシ３０から受信したリプライデータが差
分圧縮データであった場合には、差分圧縮データからサ
ーバ側プロキシ３０が受信したリプライデータを生成し
クライアント５０に送信するとともに、自分自身のフィ
ンガープリント・キャッシュ２６０には、差分圧縮デー
タから生成された該リプライデータに対するフィンガー
プリントと、サーバ側プロキシ３０から受信した差分圧
縮データとを記録・管理する。この際、記録・管理され
ているデータが差分圧縮データであることを示すため
に、圧縮識別子を１にセットする。

【００５５】一方、サーバ側プロキシ３０においてサー
バ２０から受信したリプライデータが初めてのデータで
あり、ＦＰ圧縮及び差分圧縮の両方とも失敗した場合に
は、サーバ側プロキシ３０はクライアント側プロキシ４
０に対して該リプライデータを送信するとともに、自分
自身のフィンガープリント・キャッシュ２６０には、該
リプライデータから取得したフィンガープリントと該リ
プライデータとを記録・管理する。この際、記録・管理
されているデータが差分圧縮データではないことを示す
ため、圧縮識別子を０にセットする。

【００５６】クライアント側プロキシ４０においては、
サーバ側プロキシ３０から受信したリプライデータがＦ
Ｐ圧縮及び差分圧縮のどちらも施されていないデータで
あることを検知した場合には、該リプライデータをクラ
イアント５０へ送信するとともに、自分自身のフィンガ
ープリント・キャッシュ２６０には、該リプライデータ
から取得したフィンガープリントと該リプライデータと
を記録・管理する。この際、記録・管理されているデー
タが差分圧縮データではないことを示すため、圧縮識別
子を０にセットする。

【００５７】これにより、差分圧縮が成功したデータに
ついては、サーバ側プロキシ３０及びクライアント側プ
ロキシ４０双方のフィンガープリント・キャッシュ２６
０において、差分圧縮データのみが保存されることにな
る。

【００５８】ところで、ＷｅｂベースのＡＳＰのような
応用では、大部分は同じ内容であるが一部分だけが異な
っているようなデータが多く使われる。例えば、帳票の
データなどは、多くのフィールドに同じ情報が記入され
ていて、一部分だけが違うようなものが多数存在する。
また、例えば、Ｗｅｂページで日付もしくは時刻のみ異
なるものや、総アクセス回数のカウンタ値のみ異なるも
のなどもある。このような場合には、差分圧縮データに
よる転送や保存は特に有効で、データ本体による転送や
保存を効果的に少なくすることができる。

【００５９】なお、両プロキシ３０，４０間において、
全メッセージをＦＰ圧縮の適用対象としてもよいが、例
えば、予め定められた条件を満たすメッセージについて
は、これをＦＰ圧縮の適用対象外とする（常にＦＰ圧縮
しないで転送する）ようにしてもよい。予め定められた
条件は、例えば、メッセージ・ヘッダに予め定められた
情報（例えばＧＥＴメソッドを示す情報およびリクエス
トを示す情報）が記述されていること、転送されるデー
タが空（ｎｕｌｌ）あるいは非常に短いサイズであるこ
となど、種々のバリエーションが考えられる。

【００６０】また、ＦＰ圧縮の適用対象のメッセージを
すべて差分圧縮の適用対象としてもよいが、ＦＰ圧縮の
適用対象のメッセージのうち予め定められた条件を満た
すメッセージについては、これを差分圧縮の適用対象外
とするようにしてもよい（この場合、差分圧縮を適用さ
れる条件が、ＦＰ圧縮を適用される条件に対して更に他
の条件を加重したものになる）。例えば、ＦＰ圧縮しな
いデータサイズの上限値Ｕ１よりも、差分圧縮しないデ
ータサイズの上限値Ｕ２を大きくする（ＦＰ圧縮すべき
データサイズの下限値Ｌ１よりも、差分圧縮すべきデー
タサイズの下限Ｌ２を大きくする）という方法や、ＦＰ
圧縮の適用対象か否かはデータサイズで判断するが、差
分圧縮の適用対象か否かについては、ＦＰ圧縮の適用対
象のうちＨＴＭＬやＸＭＬ以外のデータを適用対象外と
する（ＨＴＭＬやＸＭＬのデータに対してのみ差分圧縮
を行う）という方法等、種々のバリエーションが考えら
れる。なお、以下では、ＦＰ圧縮の適用対象のメッセー
ジをすべて差分圧縮の適用対象とする場合を例にとって
説明する。

【００６１】本実施形態では、ＦＰ圧縮対象且つ差分圧
縮対象のメッセージは、データがＦＰ圧縮されたメッセ
ージ（ただし、圧縮識別子が０になるものと１になるも
のとがある）、データが差分圧縮されたメッセージ、ま
たはデータが圧縮されていないメッセージのいずれかと
して、サーバ側プロキシ３０とクライアント側プロキシ
４０との間を転送されることになる。

【００６２】また、ＦＰ圧縮対象であり且つ差分圧縮対
象でないメッセージがある場合、該メッセージは、デー
タがＦＰ圧縮されたメッセージ（圧縮識別子＝０にな
る）、またはデータが圧縮されていないメッセージのい
ずれかとして、サーバ側プロキシ３０とクライアント側
プロキシ４０との間を転送されることになる。

【００６３】また、ＦＰ圧縮対象でないメッセージがあ
る場合には、該メッセージは、データが圧縮されていな
いメッセージとして、サーバ側プロキシ３０とクライア
ント側プロキシ４０との間を転送されることになる。

【００６４】ここで、差分圧縮の方法について説明す
る。

【００６５】フィンガープリント・キャッシュを利用し
た差分圧縮の方法には次に例示するものなど種々の方法
がある。・フィンガープリント・キャッシュに登録され
ているデータのうちの１つを参照データとする。プロキ
シ間では、参照データに対応するフィンガープリントの
値と、転送データと参照データとの差分を示す情報とを
転送する。・上記の方法において、参照データとの差分
の全部または一部についても、フィンガープリント・キ
ャッシュに登録されているデータを利用する。あるい
は、フィンガープリント・キャッシュに登録されている
データ（の全体または部分）を組み合わせることによっ
て転送データの全部または一部を表現する。例えば、フ
ィンガープリント・キャッシュに登録されているデータ
のうち任意数のものを参照データとする。プロキシ間で
は、参照データに対応するフィンガープリントの値と、
参照データのうち転送データの復元に使用する部分を示
す情報と、その部分をもとにした転送データの復元方法
を示す情報とを転送する。

【００６６】以下では、差分圧縮データの表現方法の一
例を示す。

【００６７】図６に、転送すべきデータを表現するため
の３種類の指示を示す。データの代わりに転送される差
分圧縮データは、これら指示の並びで構成する。

【００６８】（ａ）は、フィンガープリント・キャッシ
ュ内のデータを参照するときに、参照データに番号を付
けて定義する指示である。１バイト目の８ｎ（図６の例
では、ｎ＝０）は指示識別子である。この指示識別子の
うちｎは、そのフィンガープリントで指定されるデータ
をｎ番の参照データとして扱うことを示す。２バイト目
から始まる１６バイトが当該参照データに対するフィン
ガープリントの値を示す。この例では、８０〜８Ｆによ
ってそれぞれ０番の参照データから、最大１５番までの
参照データが扱えるようになっている。扱える参照デー
タの最大数は、実装によって多くも少なくもできる。

【００６９】（ｂ）は、（ａ）で定義された参照データ
の中から部分データをコピーする指示を表す。１バイト
目の９ｎ（図６の例では、ｎ＝０）は指示識別子であ
る。この指示識別子のうちｎは、（ａ）の指示で定義さ
れたｎ番の参照データを使用することを示す。２バイト
目からの４バイトは、そのｎ番の参照データ中のオフセ
ット位置を、６バイト目からの４バイトでデータの長さ
をそれぞれ指示する。そして、それらによって、ｎ番の
参照データの中の指定オフセット位置から指定長さのデ
ータを、この指示の並びの位置（順番）に従って（転送
データの構成部分として）コピーすべきことを示す。

【００７０】（ｃ）は、データを直接指定するための指
示である。１バイト目のＡ０は、指示識別子である。２
バイト目からの４バイトは、データの長さを示す。６バ
イト目以降に、その長さで指定されたバイト数のデータ
が続く。そして、それらによって、６バイト目以降のデ
ータを、この指示の並びの位置（順番）に従って（転送
データの構成部分として）コピーすることを示す。

【００７１】このような指示の並びで構成された差分圧
縮データは、フィンガープリント・キャッシュを参照し
ながら、指示された順にデータをコピーして接続してい
くだけで解凍することができる。

【００７２】次に、上記の方法に従った差分圧縮の例を
示す。

【００７３】図７に示すようなデータがフィンガープリ
ント５Ｅ８３…Ｂ６としてフィンガープリント・キャッ
シュに入っていたとする。

【００７４】このとき、図８のようなデータが与えられ
ると、図７のデータを参照データとして、図９のように
差分圧縮することができる。

【００７５】すなわち、図８のデータは、図７のデータ
と比較すると、図７のデータの『ＴＯＫＹＯ』が『ＯＳ
ＡＫＡ』に変わっているだけである。そこで、図９のよ
うに、まず、０バイト目でフィンガープリント“５Ｅ８
３…Ｂ６”のデータを０番参照データとして定義するこ
とを指示し、１７バイト目で０番参照データの０バイト
目から６０バイトをコピーすることを指示し、次に２６
バイト目で『ＯＳＡＫＡ』の５文字をコピーすることを
指示し、最後に３６バイト目で０番参照データの６５バ
イト目から５１バイトをコピーすることを指示してい
る。

【００７６】この指示の通りに解凍すれば、図８のデー
タを再現することができる。

【００７７】この例では、参照データを１つだけ用いた
が、複数個使うことも可能である。

【００７８】次に、上記の方法に従った差分圧縮の他の
例を示す。

【００７９】図１０に示すようなデータがフィンガープ
リント８２Ｆ３…３８としてフィンガープリント・キャ
ッシュに入っており、図１１に示すようなデータがフィ
ンガープリントＡ２０Ｄ…ＣＢとしてフィンガープリン
ト・キャッシュに入っていたとする。このとき、図１２
のようなデータが与えられると、図１０のデータと図１
１のデータを参照データとして、図１３のように差分圧
縮することができる。

【００８０】図１３では、まず、０バイト目でフィンガ
ープリント“８２Ｆ３…３８”のデータを０番参照デー
タとして定義することを指示し、１７バイト目で０番参
照データの０バイト目から５３バイトをコピーすること
を指示し、２６バイト目でフィンガープリント“Ａ２０
Ｄ…ＣＢ”のデータを１番参照データとして定義するこ
とを指示し、４３バイト目で１番参照データの９６バイ
ト目から５５バイトをコピーすることを指示している。

【００８１】この指示の通りに解凍すれば、図１２のデ
ータを再現することができる。

【００８２】なお、上記した方法では、参照データの使
用すべき部分の指示と、使用すべきデータの直接指定を
行う方法（方法１）であったが、その代わりに、参照デ
ータのうち使用しない部分（直接指示データで置き換え
る部分）の指示と、その使用しない部分に嵌め込むデー
タの直接指定を行う方法（方法２）も可能である。

【００８３】また、方法１と方法２を併用することも可
能である。

【００８４】次に、図１４〜図１８を参照しながら、サ
ーバ側プロキシ３０とクライアント側プロキシ４０との
間でデータ転送する際の（ＦＰ圧縮の適用対象のメッセ
ージについての）プロキシ間メッセージ・フォーマット
について説明する。

【００８５】サーバ側プロキシ３０とクライアント側プ
ロキシ４０との間でデータ転送する場合、ＦＰ圧縮の適
用対象のメッセージには、データがＦＰ圧縮されてフィ
ンガープリントに置き換えられたメッセージ（ＦＰ圧縮
時のメッセージ）と、ＦＰ圧縮されいないが、差分圧縮
されたデータが搭載されているメッセージ（差分圧縮時
のメッセージ）と、ＦＰ圧縮も差分圧縮もされていない
データが搭載されているメッセージ（非圧縮時のメッセ
ージ）とがある。すべてのメッセージをＦＰ圧縮の適用
対象とするのではない構成の場合には、これら３つのメ
ッセージに加えて、ＦＰ圧縮の適用対象外のメッセージ
がある。

【００８６】両プロキシのうち送信側プロキシにおい
て、ＦＰ圧縮時のメッセージでは、データが削除され、
フィンガープリントが付加され、差分圧縮時のメッセー
ジでは、データが削除され、参照データのフィンガープ
リントなど当該データを復元するための情報が付加され
る。非圧縮時のメッセージおよび圧縮適用対象外のメッ
セージでは、データは削除されない。

【００８７】両プロキシのうち受信側プロキシにおいて
は、上記の３種もしくは４種のメッセージを識別できる
必要がある。ＦＰ圧縮時のメッセージ受信時は、フィン
ガープリントをデータに戻し（ただし、圧縮識別子が０
である場合には、データ本体が保持されているが、圧縮
識別子が１である場合には、差分圧縮により生成された
データが保持されているので、これをもとにデータを復
元する）、差分圧縮時のメッセージ受信時は、データを
復元する。また、差分圧縮時または非圧縮時のメッセー
ジ受信時は、フィンガープリント・キャッシュの登録を
行う。

【００８８】図１４に、メッセージ・フォーマットの一
例を示す。（ａ）は非圧縮時のメッセージであり、
（ｂ）は差分圧縮時のメッセージであり、（ｃ）はＦＰ
圧縮時のメッセージである。

【００８９】（ａ）ではメッセージ・ボディーにデータ
が載せられ、（ｂ）ではメッセージ・ボディーにデータ
の代わりに当該データを復元するための情報が載せら
れ、（ｃ）ではメッセージ・ボディーにデータの代わり
にフィンガープリント（ＦＰ）が載せられる。

【００９０】また、この例では、メッセージ・ヘッダ
に、メッセージの種類を識別可能とする識別情報が（圧
縮側のプロキシにおいて）記述され、この識別情報に基
づいて（解凍側のプロキシにおいて）ＦＰ圧縮の有無を
識別する（例えば、０１ならば非圧縮なし、１０ならば
差分圧縮、１１ならばＦＰ圧縮）。なお、識別情報は、
プロキシ間で使用される特別のものであってもよいし、
もともと通常のＨＴＴＰメッセージ・ヘッダに存在する
フィールドを利用あるいは併用したものであってもよ
い。

【００９１】なお、ＦＰ圧縮の適用対象外のメッセージ
が存在し得る構成の場合には、圧縮側（送信側）のプロ
キシにおいて、図１４（ｄ）に示すように、ＦＰ圧縮の
適用対象外のメッセージのメッセージ・ヘッダに上記の
識別情報（例えば、００とする）を含めればよい。

【００９２】また、ＦＰ圧縮の適用対象外のメッセージ
が存在し得る構成の場合に、解凍側（受信側）プロキシ
において、メッセージ・ヘッダに含まれる何らかの情報
によって当該メッセージがＦＰ圧縮の適用対象外のメッ
セージであることを判断できるとき、あるいはメッセー
ジ・ボディーが空（ｎｕｌｌ）のときに当該メッセージ
がＦＰ圧縮の適用対象外のメッセージであることを判断
するようにしたときなどには、ＦＰ圧縮の適用対象外の
メッセージのメッセージ・ヘッダには識別情報を含めな
いようにすることも可能である。

【００９３】なお、非圧縮時や差分圧縮時には、図１４
（ａ），（ｂ）の例では、メッセージに当該データに対
するフィンガープリントを含ませなかったが、メッセー
ジ・ヘッダにフィンガープリントを含ませるようにして
もよい（あるいは、メッセージ・ボディーに当該データ
に対するフィンガープリントを含ませるようにしてもよ
い）。図１５（ａ）〜（ｃ）は、非圧縮時や差分圧縮時
には、メッセージ・ヘッダにフィンガープリントを含ま
せ、ＦＰ圧縮時には、メッセージ・ボディーにフィンガ
ープリントを含ませる場合の一例である。このようにす
れば、解凍側で当該データについてフィンガープリント
・キャッシュの登録を行う際に、該フィンガープリント
を利用することによって、あらためて当該データからフ
ィンガープリントを求める手間が省ける。

【００９４】なお、以上のいずれの場合においても、図
１６に示すように、ＦＰ圧縮時のメッセージでは、メッ
セージ・ヘッダにフィンガープリント（ＦＰ）を含め、
メッセージ・ボディーを空（ｎｕｌｌ）にしてもよい。

【００９５】なお、以上の他にも、種々のメッセージ・
フォーマットが可能である。

【００９６】例えば、図１７では、（ａ）の非圧縮時の
メッセージのヘッダに非圧縮フラグを記述し且つフィン
ガープリントは記述せず、（ｂ）の差分圧縮時のメッセ
ージのヘッダに差分圧縮フラグを記述し且つフィンガー
プリントは記述せず、（ｃ）のＦＰ圧縮時のメッセージ
のヘッダにフィンガープリントは記述し且つボディーは
空（ｎｕｌｌ）にする。

【００９７】この場合には、メッセージ・ボディーが空
（ｎｕｌｌ）であることあるいはメッセージのヘッダに
フィンガープリントが記述されていることを検出するに
よって、当該メッセージがＦＰ圧縮時のメッセージであ
ることを識別することができる。また、非圧縮時のメッ
セージや差分圧縮時のメッセージは、ヘッダに非圧縮フ
ラグや差分圧縮フラグが記述されていることを検出する
ことによって、識別することができる。

【００９８】なお、ＦＰ圧縮の適用対象外のメッセージ
が存在し得る構成の場合には、圧縮側（送信側）のプロ
キシにおいて、図１８の（ａ），（ｂ）に示すように
（（ａ）はデータが空（ｎｕｌｌ）でない場合、（ｂ）
はデータが空（ｎｕｌｌ）である場合）、ＦＰ圧縮の適
用対象外のメッセージのメッセージ・ヘッダに対象外フ
ラグを含めればよい。

【００９９】また、ＦＰ圧縮の適用対象外のメッセージ
が存在し得る構成の場合に、解凍側（受信側）プロキシ
において、メッセージ・ヘッダに含まれる何らかの情報
によって当該メッセージがＦＰ圧縮の適用対象外のメッ
セージであることを判断できるときなどには、図１８の
（ｃ），（ｄ）に示すように（（ｃ）はデータが空（ｎ
ｕｌｌ）でない場合、（ｄ）はデータが空（ｎｕｌｌ）
である場合）ＦＰ圧縮の適用対象外のメッセージのメッ
セージ・ヘッダには対象外フラグを含めないようにする
ことも可能である。

【０１００】以下では、まずサーバ側プロキシ３０から
クライアント側プロキシ４０へリプライメッセージを転
送するときにそのリプライデータをＦＰ圧縮・解凍する
場合を中心に本実施形態について詳しく説明する。

【０１０１】図１９に本実施形態におけるサーバ側プロ
キシ３０の構成例を示し、図２０に本実施形態における
のクライアント側プロキシ４０の構成例を示す。なお、
図１９や図２０は、サーバ側プロキシ３０からクライア
ント側プロキシ４０へデータを転送する際の構成を中心
に示してある。

【０１０２】図１９のサーバ側プロキシ３０は、サーバ
センター内ＬＡＮ１２または広域ネットワーク１４から
転送メッセージを受信するための処理を行う受信部３
１、転送メッセージに含まれるデータに対してＦＰ圧
縮、差分圧縮を施すための処理部３２、サーバセンター
内ＬＡＮ１２または広域ネットワーク１４へ転送メッセ
ージを送信するための処理を行う送信部３３、フィンガ
ープリントとそのもととなったデータまたは差分圧縮デ
ータとを対応付けて記憶するためのフィンガープリント
・キャッシュ（ＦＰキャッシュ）３４を備えている。ま
た、処理部３２は、転送メッセージに含まれるデータを
圧縮対象とすべきか否かを判定するためのフィンガープ
リント圧縮判定部（ＦＰ圧縮判定部）３２１、ＦＰキャ
ッシュ３４に対する検索や登録などを行うためのフィン
ガープリント・キャッシュ管理部（ＦＰキャッシュ管理
部）３２２、転送メッセージに含まれるデータを対応す
るフィンガープリントで置き換えるなどの処理を行うた
めのフィンガープリント圧縮処理部（ＦＰ圧縮処理部）
３２３、転送メッセージに含まれるデータを差分圧縮デ
ータで置き換えるなどの処理を行うための差分圧縮処理
部３２４を含む。

【０１０３】図２０のクライアント側プロキシ４０は、
ユーザオフィス内ＬＡＮ１６または広域ネットワーク１
４から転送メッセージを受信するための処理を行う受信
部４１、転送メッセージに含まれるデータに対してＦＰ
解凍を施すための処理部４２、ユーザオフィス内ＬＡＮ
１６または広域ネットワーク１４へ転送メッセージを送
信するための処理を行う送信部４３、フィンガープリン
トとそのもととなったデータまたは差分圧縮データとを
対応付けて記憶するためのフィンガープリント・キャッ
シュ（ＦＰキャッシュ）４４を備えている。また、処理
部４２は、転送メッセージに含まれるデータを圧縮対象
とすべきか否か並びに転送メッセージに対するＦＰ圧縮
および差分圧縮の有無を判定するためのフィンガープリ
ント圧縮判定部（ＦＰ圧縮判定部）４２１、ＦＰキャッ
シュ４４に対する検索や登録などを行うためのフィンガ
ープリント・キャッシュ管理部（ＦＰキャッシュ管理
部）４２２、ＦＰ圧縮された転送メッセージに含まれる
フィンガープリントから元のデータを解凍するなどの処
理を行うためのフィンガープリント解凍処理部（ＦＰ解
凍処理部）４２３、差分圧縮された転送メッセージに含
まれる差分圧縮データから元のデータを解凍するなどの
処理を行うための差分解凍処理部４２４を含む。

【０１０４】なお、圧縮側のＦＰ圧縮判定部３２１と解
凍側のＦＰ圧縮判定部４２１は、前述したようにメッセ
ージが予め定められた条件を満たすか否かを調べること
によって、そのメッセージに含まれるデータをＦＰ圧縮
の適用対象とするか否かを判断する（全メッセージをＦ
Ｐ圧縮の適用対象にする場合には、圧縮側のＦＰ圧縮判
定部３２１及び後に示す手順例の該当部分並びに解凍側
のＦＰ圧縮判定部４２１の該当判断の部分及び後に示す
手順例の該当部分は不要である）。また、解凍側のＦＰ
圧縮判定部４２１は、ＦＰ圧縮の適用対象のメッセージ
について、そのデータがＦＰ圧縮されたものか否かを判
定する。以下では、ＦＰ圧縮の適用対象となるメッセー
ジを転送する場合（ＦＰ圧縮の適用対象とすると判断さ
れた場合、または全メッセージをＦＰ圧縮の適用対象に
する場合）を中心に説明する。

【０１０５】図２１及び図２２に、サーバ側プロキシ３
０からクライアント側プロキシ４０へリプライメッセー
ジを転送する際のサーバ側プロキシ３０の処理手順の一
例を示す。なお、図２１及び図２２は、１つのリプライ
メッセージを受けたときの処理を記述しているが、実際
はサーバ側プロキシ３０が受け取ったリプライメッセー
ジ全てに対して、図２１及び図２２に例示する処理を行
う。

【０１０６】サーバ側プロキシ３０は、受信部３１によ
り、サーバ２０からリプライメッセージを受信する（ス
テップＳ１）。

【０１０７】ＦＰ圧縮判定部３２１は、該リプライメッ
セージのリプライデータがＦＰ圧縮対象のものであるか
否か調べ、判断する（Ｓ２）。リプライデータがＦＰ圧
縮対象外のものと判断されたならば（Ｓ２）、受信した
リプライメッセージを送信部３３からクライアント側プ
ロキシ４０へ転送する（Ｓ１３）。

【０１０８】ステップＳ２にて該リプライメッセージの
リプライデータがＦＰ圧縮対象のものであると判断され
たならば、ＦＰキャッシュ管理部３２２にて、該リプラ
イデータのフィンガープリントの値を計算し（Ｓ３）、
該フィンガープリントの値をキーとしてＦＰキャッシュ
３４を検索する（Ｓ４）。

【０１０９】そして、該フィンガープリントの値とこれ
に対応するデータ（データ本体または差分圧縮データ）
との組がＦＰキャッシュ３４に登録されていたならば
（Ｓ５）、ＦＰ圧縮処理部３２３にて、受信したリプラ
イメッセージを、該フィンガープリントの値を用いてＦ
Ｐ圧縮時のフォーマットにして、送信部３３から、クラ
イアント側プロキシ４０へ送信する（Ｓ６）。

【０１１０】一方、ステップＳ４の検索の結果、該フィ
ンガープリントの値とこれに対応するデータとの組がＦ
Ｐキャッシュ３４に登録されていなかったならば（Ｓ
５）、差分圧縮処理部３２４にて、差分圧縮を行い（Ｓ
７）、差分圧縮に成功したか否か判定する（Ｓ８）。

【０１１１】差分圧縮に成功したか否かは、例えば、差
分圧縮の対象とした元のデータのデータ量ｒ０と、差分
圧縮データのデータ量ｒ１とを比較し、ｒ０−ｒ１＞ｄ
を満たすならば、成功したと判断する。ここで、定数ｄ
は、予め定められた０以上の整数である。

【０１１２】ステップＳ８で差分圧縮に成功したと判断
された場合、次の２つの作業を行う(1-1と1-2のいずれ
を先に行ってもよいし、並行して行ってもよい)。 （１−１）差分圧縮処理部３２４にて、受信したリプラ
イメッセージを、（必要に応じて該フィンガープリント
の値を用いて）差分圧縮時のフォーマットにして、送信
部３３から、クライアント側プロキシ４０へ送信する
（Ｓ９）。 （１−２）ＦＰキャッシュ管理部３２２にて、該フィン
ガープリントの値と、ステップＳ７において生成された
差分圧縮データとを対応付けて（フィンガープリントの
値をキーにして）、ＦＰキャッシュ３４に登録する（Ｓ
１０）。この際、登録するデータは差分圧縮データであ
るので、圧縮識別子を１にセットする。

【０１１３】なお、上記（１−２）においては全ての差
分圧縮データをＦＰキャッシュに登録するものとした
が、（ｉ）差分圧縮データのサイズと該差分圧縮データ
の元になったデータのサイズがほとんど変わらない場合
は差分圧縮データではなく該差分圧縮データの元になっ
たデータを保存する、（ｉｉ）差分圧縮データのサイズ
が該差分圧縮データの元になったデータのサイズに比べ
て非常に小さい場合は差分圧縮データは保存せず、該差
分圧縮データの元になったデータも保存せず差分圧縮デ
ータ作成時に参照データとして用いたデータのＦＰキャ
ッシュにおける登録を維持する、などの方法も可能であ
る。その他にも種々のバリエーションがある。また、こ
の点は、後で説明する他の処理手順例において差分圧縮
データをＦＰキャッシュに登録する場合についても同様
である（なお、後の説明でも、全ての差分圧縮データを
ＦＰキャッシュに登録するものとした場合を例にとって
説明している）。

【０１１４】一方、ステップＳ８で差分圧縮に失敗した
と判断された場合、次の２つの作業を行う(2-1と2-2の
いずれを先に行ってもよいし、並行して行ってもよい)。 (2-1)差分圧縮処理部３２４（あるいはＦＰ圧縮処理部
３２３）にて、受信したリプライメッセージを、非圧縮
時のフォーマットにして、送信部３３から、クライアン
ト側プロキシ４０へ送信する（Ｓ１１）。 (2-2)ＦＰキャッシュ管理部３２２にて、該フィンガー
プリントの値と、該リプライメッセージとを対応付けて
（フィンガープリントの値をキーにして）、ＦＰキャッ
シュ３４に登録する（Ｓ１２）。この際、登録するデー
タは差分圧縮データではないので、圧縮識別子を０にセ
ットする。

【０１１５】次に、図２３〜図２５に、サーバ側プロキ
シ３０からクライアント側プロキシ４０へリプライメッ
セージを転送する際のクライアント側プロキシ４０の処
理手順の一例を示す。なお、図２３〜図２５は、１つの
リクエストメッセージを受けたときの処理を記述してい
るが、実際はクライアント側プロキシ４０が受け取った
リクエストメッセージ全てに対して、図２３〜図２５に
例示する処理を行う。

【０１１６】クライアント側プロキシ４０は、受信部４
１により、サーバ側プロキシ３０からリプライメッセー
ジを受信する（ステップＳ２１）。

【０１１７】ＦＰ圧縮判定部４２１は、該リプライメッ
セージのリプライデータがＦＰ圧縮対象のものであるか
否か調べ、判断する（Ｓ２２）。リプライデータがＦＰ
圧縮対象外のものと判断されたならば（Ｓ２２）、受信
したリプライメッセージを送信部４３からクライアント
５０へ転送する（Ｓ３８）。

【０１１８】ステップＳ２２にて該リプライメッセージ
のリプライデータがＦＰ圧縮対象のものであると判断さ
れたならば、ＦＰ圧縮判定部４２１は、さらに、リプラ
イデータがＦＰ圧縮されているか否か調べ、判断する
（Ｓ２３）。

【０１１９】ステップＳ２３にて該リプライメッセージ
のリプライデータがＦＰ圧縮されているものと判断され
たならば、ＦＰキャッシュ管理部４２２にて、該リプラ
イデータのフィンガープリントの値を求め（Ｓ２４）、
該フィンガープリントの値をキーとしてＦＰキャッシュ
４４を検索する（Ｓ２５）。

【０１２０】次に、ステップＳ２５において検索の結果
得られたデータが差分圧縮データかどうか、ＦＰキャッ
シュ管理部４２２にて該データの圧縮識別子を用いて調
べ、判断する（Ｓ２６）。

【０１２１】ステップＳ２６にて該データが差分圧縮デ
ータであると判断された（本例では、圧縮識別子が１）
ならば、差分解凍処理部４２４にて、（ＦＰキャッシュ
管理部４２２において参照データを検索・取得した後
に）差分圧縮データを解凍して元のリプライデータを復
元し（Ｓ２７）、該復元したリプライデータをリプライ
メッセージに付加し、またプロキシ間で特別の情報を使
用する場合には受信リプライメッセージから該情報を削
除し、該リプライメッセージを送信部４３からクライア
ント５０へ送信する（Ｓ２８）。

【０１２２】ステップＳ２６にて該データが差分圧縮デ
ータではないと判断された（本例では、圧縮識別子が
０）ならば、ＦＰ解凍処理部４２３にて、受信リプライ
メッセージに対して、ＦＰキャッシュ４４から検索され
た該フィンガープリントの値に対応するデータを付加
し、プロキシ間で特別の情報を使用する場合には該情報
を削除した後に、これを送信部４３からクライアント５
０へ送信する（Ｓ２９）。

【０１２３】一方、ステップＳ２３にて該リプライメッ
セージのリプライデータがＦＰ圧縮されていないものと
判断されたならば、ＦＰ圧縮判定部４２１は、さらに、
該リプライデータが差分圧縮されているか否か判定する
（Ｓ３０）。

【０１２４】ステップＳ３０で差分圧縮されていると判
断された場合、次の２つの作業を行う(1-1と1-2のいず
れを先に行ってもよいし、並行して行ってもよい)。 （１−１）差分解凍処理部４２４にて、（ＦＰキャッシ
ュ管理部４２２により参照データを検索・取得した後
に）差分圧縮データを解凍して元のリプライデータを復
元し（Ｓ３１）、該復元したリプライデータをリプライ
メッセージに付加し、またプロキシ間で特別の情報を使
用する場合には受信リプライメッセージから該情報を削
除し、該リプライメッセージを送信部４３からクライア
ント５０へ送信する（Ｓ３２）。 （１−２）ＦＰキャッシュ管理部４２２にて、該リプラ
イデータのフィンガープリントの値を求め（Ｓ３３）、
該フィンガープリントの値と、差分圧縮データとを対応
付けて（フィンガープリントの値をキーにして）、ＦＰ
キャッシュ４４に登録する（Ｓ３４）。このとき、ＦＰ
キャッシュ４４への登録においては、リプライメッセー
ジは差分圧縮データであるので、圧縮識別子は１にセッ
トする。

【０１２５】一方、ステップＳ３０で差分圧縮されてな
いと判断された場合、次の２つの作業を行う(2-1と2-2
のいずれを先に行ってもよいし、並行して行ってもよ
い)。 (2-1)差分解凍処理部４２４（あるいはＦＰ解凍処理部
４２３）にて、プロキシ間で特別の情報を使用する場合
には受信リプライメッセージから該情報を削除した後
に、これを送信部４３からクライアント５０へ送信する
（Ｓ３５）。 (2-2)ＦＰキャッシュ管理部４２２にて、該リプライデ
ータのフィンガープリントの値を求め（Ｓ３６）、該フ
ィンガープリントの値と、該リプライメッセージとを対
応付けて（フィンガープリントの値をキーにして）、Ｆ
Ｐキャッシュ４４に登録する（Ｓ３７）。このとき、Ｆ
Ｐキャッシュ４４への登録においては、リプライメッセ
ージは差分圧縮データではないので、圧縮識別子は０に
セットする。

【０１２６】なお、ステップＳ２４／Ｓ３３／Ｓ３６で
は、メッセージにフィンガープリントが記述されている
場合に、該メッセージからフィンガープリントを得る方
法と、メッセージにフィンガープリントが記述されてな
い場合に、リプライデータをもとにハッシュ関数等によ
ってフィンガープリントの値を計算する方法とがある。
なお、メッセージにフィンガープリントが記述されてい
る場合であっても、リプライデータをもとにフィンガー
プリントの値を計算する方法も可能である。また、ステ
ップＳ２４／Ｓ３３／Ｓ３６は、フィンガープリントを
使用する以前の他のタイミングで行って構わない。ま
た、ステップＳ２２、Ｓ２３、Ｓ２６、Ｓ３０の判断の
全部または一部を同時に行ってもよい。

【０１２７】次に、差分圧縮を行う手順について説明す
る。

【０１２８】図２６に、差分圧縮手順の一例を示す。こ
れは、先に説明した３種類の指定を用いる場合の手順例
である。

【０１２９】ここでは、差分圧縮を行うために、フィン
ガープリント・キャッシュに入っているデータのうち、
最近アクセスしたものを順に並べた履歴表を利用するも
のとする。この履歴表には、必ずしもフィンガープリン
ト・キャッシュに入っている全てのデータのフィンガー
プリントが記録されている必要は無い。例えば、予め定
められた個数が記録されていればよい（この場合、個数
は、例えば差分圧縮の参照データとして使用するに有効
な個数を想定して予め決定する）。もちろん、履歴表へ
の記録の基準として、最近のアクセスの順以外の１又は
複数の基準を用いてもよいし、最近のアクセスの順の基
準に加えて他に１又は複数の基準を併用してもよい。

【０１３０】なお、履歴表は、フィンガープリント・キ
ャッシュと一体化して構成する方法もある。

【０１３１】（ステップＳ２３１）まず、作業用のコピ
ーバッファおよび指示バッファを空にする。

【０１３２】このコピーバッファにコピーされた内容を
もとに、図６（ａ）〜（ｃ）の指示が作成され、これが
指示バッファに書き出される。最終的に、指示バッファ
に書き出された指示の並びが、差分圧縮データになる。

【０１３３】（ステップＳ２３２）差分圧縮の対象とす
るデータを文字列として扱い、その文字列上を指すポイ
ンタを用意する。まず、ポインタが当該文字列のうちの
最初の文字を指すように設定する。

【０１３４】以下では、ステップＳ２４１でポインタが
当該文字列のうちの最後の文字に辿りついたと判断され
るまで、ループ処理を実行することになる。

【０１３５】（ステップＳ２３３）履歴表に記録されて
いるフィンガープリントに対応するデータを、新しいも
のから順に取り出し、その中に、差分圧縮したいデータ
の中のポインタの指す場所から予め定められた長さ以上
マッチするデータを参照データとして取り出す。

【０１３６】なお、参照データと決定方法としては、種
々の方法がある。例えば、履歴表に記録されているフィ
ンガープリントに対応するデータを最新の順に調べてい
き、最初に予め定めた長さ以上マッチしたデータを参照
データとして取り出す方法、履歴表に記録されているフ
ィンガープリントに対応するデータの全てを調べ、その
中でマッチした長さが最も長かったデータ（ただし、予
め定めた長さ以上マッチしたことを条件とする）を参照
データとして取り出す方法などがある。

【０１３７】（ステップＳ２３４）参照データが見つけ
られたらならば、ステップＳ２３７へ移る。参照データ
が見つけられなかったならば、ステップＳ２３５へ移
る。

【０１３８】（ステップＳ２３７）ステップＳ２３４に
て参照データが見つけられた場合に、コピーバッファが
空でなければ、コピーバッファ中の文字列に対応する、
図６の（ｃ）の直接指定によるコピー指示を作成し、こ
れを指示バッファに書き出す。コピーバッファは、空に
する。なお、コピーバッファが空ならば、何もしない。

【０１３９】（ステップＳ２３８）ステップＳ２３３に
て見つかった参照データに対応する図６の（ａ）の参照
データ定義が未だ指示バッファに書き出されていなけれ
ば、指示バッファに当該参照データ定義の指示を書き出
す。

【０１４０】（ステップＳ２３９）参照データからマッ
チした文字列のコピー指示を、図６の（ｂ）のコピー指
示として指示バッファに書き出す。

【０１４１】（ステップＳ２４０）ポインタを参照デー
タとマッチした文字列の長さ分だけ進める。

【０１４２】（ステップＳ２３５）一方、ステップＳ２
３４にて参照データが見つけられた場合に、ポインタの
指す文字をコピーバッファに入れる。

【０１４３】（ステップＳ２３６）ポインタを１文字分
だけ進める。

【０１４４】（ステップＳ２４１）差分圧縮の対象とす
るデータの最後までポインタが来ていなければ（処理し
ていないデータ部分が残っていれば）、ステップＳ２３
３へ戻る。差分圧縮の対象とするデータの最後までポイ
ンタが来ていたら（処理していないデータ部分が残って
いなければ）、処理ループを抜けて、ステップＳ２４２
へ移る。

【０１４５】（ステップＳ２４２）コピーバッファが空
でなければ、コピーバッファ中の文字列に対応する、図
６の（ｃ）の直接指定によるコピー指示を作成し、これ
を指示バッファに書き出す。コピーバッファは、空にす
る。なお、コピーバッファが空ならば、何もしない。

【０１４６】このときの指示バッファの内容が、差分圧
縮データとなる。

【０１４７】なお、前述のように、実際には、このよう
にして差分圧縮を行った後、差分圧縮を行った結果のデ
ータサイズが、行う前のデータサイズよりも小さくなっ
ている（あるいは一定基準（一定の圧縮量）を超えて小
さくなっている）ことを確認する。差分圧縮によってデ
ータサイズが小さくならない（あるいは一定基準（一定
の圧縮量）を超えては小さくならない）場合には、差分
圧縮しない方が良いので、データはそのまま転送する。

【０１４８】ところで、上記の差分圧縮の処理におい
て、ステップＳ２３３の予め定められた長さ以上マッチ
する文字列を持つ最新のデータを選び出す処理が、最も
時間がかかる処理であると考えられる。この処理をより
高速化するために、ハッシュ表を利用することができ
る。履歴表に入れるデータから、その中の全ての予め定
められた長さの文字列を取り出し、そのハッシュ値（例
えば、全ての文字のコードを足したものなど）を計算
し、ハッシュ表に登録しておく。このハッシュ表は、同
じハッシュ値を持つデータがあればより最新のデータに
よって上書きされるようにしておく。このハッシュ表を
使って、差分圧縮したいデータの現在のポインタの位置
から予め定められた長さの文字列のハッシュ値を求め、
そのハッシュ値を使ってハッシュ表を引いて求めたデー
タが、ステップＳ２３３で選ぶべきデータの第１の候補
になる。ここで、異なる文字列でも同じハッシュ値を生
成する場合があるので、本当に同じかどうかは文字列を
実際に比較して確認し、同じでなければ、履歴表のデー
タを順に見るなど方法で次の候補を探す。

【０１４９】ステップＳ２３３の処理を高速化する他の
方法は、行を単位として比較処理を行う方法である。図
２６の手順では文字を単位として比較処理をしていた
が、履歴表にあるすべてのデータに対して、そのデータ
内の各行のハッシュ値の列を計算しておく。差分圧縮し
たいデータからも、まず、各行のハッシュ値の列を計算
する。以降は、図２６の手順と同様であるが、比較は文
字単位ではなく、行のハッシュ値を単位として行う。こ
の方法は、行を単位としているため、文字単位よりも比
較回数を減らすことができる。ただし、ハッシュ値で比
較するために、異なる行でも同じハッシュ値を持つ場合
があるので、最終的にはハッシュ値が同じだと判断した
後に、実際に行の中も比較して本当に同じかどうかを判
断するのが望ましい。もちろん、このように行を単位と
して比較する構成についても、上記のハッシュ技法を組
み合わせることができる。この場合、連続する複数行を
組み合わせて、予め定められた長さと同じか長くなる最
少の行数を単位としてハッシュ表に登録すればよい。

【０１５０】次に、図２７に、差分圧縮手順の他の例を
示す。これは、フィンガープリント・キャッシュに登録
されているデータのうちの１つを参照データとし、プロ
キシ間では、参照データに対応するフィンガープリント
の値と、転送データと参照データとの差分を示す情報と
を転送する場合の手順例である。

【０１５１】ここでも、前述したような履歴表を用いる
ものとする。

【０１５２】まず、履歴表に記録されているフィンガー
プリントに対応するデータのうち、所定の基準を満たす
一つを、参照データとして選択する（ステップＳ２４
５）。

【０１５３】所定の基準は、例えば、差分圧縮の対象と
するデータのうち、参照データとするデータとの間でマ
ッチしなかった部分のデータ量が、予め定められたデー
タ量以下であって、かつ、参照データをそのマッチしな
かった部分によって複数の塊に分断したときにおけるそ
の分断された塊の数が、予め定められた数以下である場
合に、これを参照データとして選択可能とする。

【０１５４】そして、参照データとして決定する方法と
しては、前述のように、例えば、履歴表に記録されてい
るフィンガープリントに対応するデータを最新の順に調
べていき、最初に予め定めた長さ以上マッチしたデータ
を参照データとして取り出す方法、履歴表に記録されて
いるフィンガープリントに対応するデータの全てを調
べ、その中でマッチしなかったデータ量や分断数が最も
少なかったデータを参照データとして取り出す方法な
ど、種々の方法がある。

【０１５５】参照データが見つけられたらならば（Ｓ２
４６）、参照データ定義の指示（例えば図６の（ａ））
を、指示バッファに書き出す（Ｓ２４７）。

【０１５６】参照データのうち、マッチしなかった部分
（直接指定データで置換する部分）を示す指示（例えば
図６の（ｂ）と同じフォーマットの指示で１バイト目の
指示識別子を変えたもの）を、指示バッファに書き出す
（Ｓ２４８）。

【０１５７】参照データのマッチしなかった部分に嵌め
込むべきデータを示す直接指定する指示（例えば図６の
（ｃ））を、指示バッファに書き出す（Ｓ２４９）。

【０１５８】なお、置換部分が複数個所ある場合には、
その分だけステップＳ２４８とステップＳ２４９を実行
する。

【０１５９】このときの指示バッファの内容が、差分圧
縮データとなる。

【０１６０】一方、参照データが見つけられたらならば
（Ｓ２４６）、差分圧縮はしないことになる。

【０１６１】なお、上記の図２６や図２７の説明では、
履歴表をフィンガープリント・キャッシュとは別に設け
るものとしたが、履歴表は、フィンガープリント・キャ
ッシュと一体化して構成する方法もある。

【０１６２】また、上記の説明では、履歴表を用いるも
のとしたが、履歴表を用いない方法もある。例えば、フ
ィンガープリント・キャッシュを所定の順番で（例え
ば、エントリ順にあるいはランダムに）予め定められた
上限数だけ調べ、それらのうちで最良のものを使用する
ようにする方法や、フィンガープリント・キャッシュを
所定の順番で（例えば、エントリ順にあるいはランダム
に）調べ、予め定められた条件を満たす参照データが初
めて得られた時点で、参照データを決定してしまう方法
など、種々の方法がある。

【０１６３】また、履歴表またはフィンガープリント・
キャッシュに、フィンガープリントに加えて、そのフィ
ンガープリントを登録したときに元となったリプライデ
ータを含んでいたリプライメッセージについてのＵＲＬ
をも保持しておき、参照データを探索する際に、まず差
分圧縮対象のリプライデータを含むリプライメッセージ
についてのＵＲＬと同じＵＲＬを持つデータが、履歴表
またはフィンガープリント・キャッシュに登録されてい
ないかどうか調べ、登録されているならば当該ＵＲＬと
同じＵＲＬを持つデータを他のものよりも優先して、参
照データとして使用できないかどうか調べるようにして
もよい。

【０１６４】もちろん、図２６や図２７の他にも、種々
の差分圧縮の手順が可能である。

【０１６５】なお、クライアント側プロキシ４０からサ
ーバ側プロキシ３０へリクエストメッセージを転送する
際にはフィンガープリント・キャッシュを用いないもの
とする場合には、サーバ側プロキシ３０は、図２８に例
示するように、クライアント側プロキシ４０からリクエ
ストメッセージを受信し（ステップＳ６０）、これをサ
ーバ２０へ送信する（ステップＳ６１）、という手順で
構わない。同様に、クライアント側プロキシ４０は、図
２９に例示するように、クライアント５０からリクエス
トメッセージを受信し（ステップＳ６２）、これをサー
バ側プロキシ３０へ送信する（ステップＳ６３）、とい
う手順で構わない。

【０１６６】以下では、図３０〜図３２を参照しなが
ら、フィンガープリント・キャッシュを利用したデータ
転送についてより具体的に説明する。

【０１６７】まず、図３０を参照しながら、サーバ側プ
ロキシ３０からクライアント側プロキシ４０へ、フィン
ガープリント・キャッシュ登録されていないデータであ
って且つ差分圧縮も成功しなかったデータを転送すると
ともに、該データについてフィンガープリント・キャッ
シュ登録する場合の動作について説明する。

【０１６８】（１）クライアント５０上のブラウザ等
は、例えば“/A.cgi”というＵＲＬでサーバ２０に、Ｐ
ＯＳＴメソッドのリクエストメッセージを出したとす
る。サーバ２０へのリクエストメッセージは、まず、ク
ライアント側プロキシ４０に送られるように、ブラウザ
等を設定しておく。

【０１６９】（２）クライアント５０からリクエストメ
ッセージを受け取ったクライアント側プロキシ４０は、
そのリクエストメッセージをサーバ側プロキシ３０に転
送する。

【０１７０】（３）リクエストメッセージを受け取った
サーバ側プロキシ３０は、そのリクエストメッセージを
サーバ２０へ転送する。

【０１７１】（４）サーバ２０は、該リクエストメッセ
ージに対する処理を行った後、サーバ側プロキシ３０
に、そのリプライメッセージを送り返す。

【０１７２】（５）リプライメッセージを受け取ったサ
ーバ側プロキシ３０は、まず、受信リプライメッセージ
の持つリプライデータのフィンガープリントを計算し、
そのフィンガープリント名を持ったデータがＦＰキャッ
シュ３４に入っているかどうかを調べる。ここでは、入
っておらず、初めてのデータ（一旦フィンガープリント
・キャッシュ登録されたものがその後に削除あるいは無
効化されることがある構成の場合に、一旦フィンガープ
リント・キャッシュ登録されたが削除あるいは無効化さ
れ、その後において初めてである場合を含む）であるの
で、そのデータをフィンガープリントを名前としてＦＰ
キャッシュ３４に入れる（登録する）。なお、ここで
は、リプライデータを差分圧縮してデータ量を減らすこ
とができなかったものとする。このとき、ＦＰキャッシ
ュ３４への登録においては、該データが差分圧縮データ
ではないので、圧縮識別子は０にセットする。

【０１７３】（６）サーバ側プロキシ３０は、データを
載せたリプライメッセージをクライアント側プロキシ４
０に転送する。なお、リプライデータから計算したフィ
ンガープリントの値を、リプライヘッダ等に入れて送る
と、クライアント側プロキシ４０で再度フィンガープリ
ントを計算する手間を省くことが出来る。

【０１７４】（７）リプライメッセージを受け取ったク
ライアント側プロキシ４０は、初めてのデータであるの
で、リプライデータをＦＰキャッシュ４４に登録する。
このとき、ＦＰキャッシュ４４への登録においては、該
リプライデータが差分圧縮データではないので、圧縮識
別子は０にセットする。なお、前述したように、リプラ
イデータからフィンガープリントを計算するか、あるい
はサーバ側プロキシがリプライヘッダ等に入れたフィン
ガープリントを取り出し、これを名前として入れる。

【０１７５】（８）クライアント側プロキシ４０は、
（リプライヘッダ等にフィンガープリントの値などのサ
ーバ側プロキシ３０とクライアント側プロキシ４０との
間だけで使用される情報が存在する構成の場合には、こ
れを削除した後に、）リプライメッセージを、クライア
ント５０（上で動作するブラウザ等）へ送り返す。

【０１７６】なお、サーバ側プロキシ３０において、上
記の（５）のフィンガープリント・キャッシュ登録は、
（６）の動作の後に行っても構わない。また、クライア
ント側プロキシ４０において、（７）のフィンガープリ
ント・キャッシュ登録は、（８）の動作の後に行っても
構わない。

【０１７７】次に、図３１を参照しながら、サーバ側プ
ロキシ３０からクライアント側プロキシ４０へ、フィン
ガープリント・キャッシュ登録されていないデータであ
って且つ差分圧縮が成功したデータを転送するととも
に、該データについてフィンガープリント・キャッシュ
登録する場合の動作について説明する。

【０１７８】（１）〜（４）は、図３０を参照して説明
した動作における（１）〜（４）と同様である。

【０１７９】（５）リプライメッセージを受け取ったサ
ーバ側プロキシ３０は、まず、受信リプライメッセージ
の持つリプライデータのフィンガープリントを計算し、
そのフィンガープリント名を持ったデータがＦＰキャッ
シュ３４に入っているかどうかを調べる。ここでは、入
っておらず、初めてのデータであることを判断する。そ
して、圧縮対象になるデータをＦＰ圧縮できなかった場
合には、差分圧縮処理を行い、リプライデータを差分圧
縮してデータ量を減らすことができるならば、差分圧縮
する。ここでは、フィンガープリントが“７１Ｆ０…７
３Ｅ６”のデータを参照データとした場合に、リプライ
データを差分圧縮してデータ量を減らすことができたも
のとする。リプライデータを差分圧縮データに置き換
え、リプライヘッダ等に差分圧縮したことを示す情報を
入れる。

【０１８０】（６）サーバ側プロキシ３０は、（５）に
おいて生成された差分圧縮データを同じく（５）で計算
したフィンガープリントを名前としてＦＰキャッシュ３
４へ入れる（登録する）。このとき、ＦＰキャッシュ３
４への登録においては、該データが差分圧縮データであ
るので、圧縮識別子を１にセットする。

【０１８１】（７）サーバ側プロキシ３０は、リプライ
メッセージをクライアント側プロキシ４０に転送する。

【０１８２】（８）クライアント側プロキシ４０は、リ
プライヘッダ等を見て、リプライデータが差分圧縮され
ていることを知り、圧縮の解凍を行う。このとき、ま
ず、圧縮されたデータ内に指定されている参照データの
フィンガープリント“７１Ｆ０…７３Ｅ６”を取り出
し、次に、該フィンガープリントに対応するデータをＦ
Ｐキャッシュ４４から取り出して使用する。そして解凍
したデータをリプライデータに入れ、リプライヘッダの
コンテンツサイズなど必要なヘッダを書き換える。

【０１８３】（９）また、リプライメッセージを受け取
ったクライアント側プロキシ４０は、初めてのデータで
あるので、サーバ側プロキシ３０から受信した差分圧縮
データをＦＰキャッシュ４４に登録する。このとき、Ｆ
Ｐキャッシュ４４への登録においては、登録するデータ
が差分圧縮データであるので、圧縮識別子を１にセット
する。また、リプライヘッダ等にフィンガープリントの
値などのサーバ側プロキシ３０とクライアント側プロキ
シ４０との間だけで使用される情報が存在する構成の場
合には、これを削除する。なお、前述したように、リプ
ライデータ（差分圧縮データから解凍して得られたデー
タ）からフィンガープリントを計算するか、あるいはサ
ーバ側プロキシがリプライヘッダ等に入れたフィンガー
プリントを取り出し、これを名前として入れる。

【０１８４】（１０）クライアント側プロキシ４０は、
リプライメッセージを、クライアント５０（上で動作す
るブラウザ等）へ送り返す。

【０１８５】なお、上記の（５）では、圧縮対象で未登
録のデータは、すべてフィンガープリント・キャッシュ
に登録するものとし、また、上記の（６）で参照データ
に用いたデータは、すべてフィンガープリント・キャッ
シュの登録を維持するものとしたが、参照データに唯一
のデータを使用した場合であって、かつ、差分圧縮対象
となったデータと、その差分圧縮に用いた参照データと
が、ほとんど同じ内容（例えば、両者でマッチしないデ
ータ量が基準以下）である場合には、（ｉ）圧縮対象で
未登録のデータはフィンガープリント・キャッシュに登
録せず、参照データはフィンガープリント・キャッシュ
の登録を維持する、あるいは（ii）圧縮対象で未登録の
データをフィンガープリント・キャッシュに登録し、参
照データはフィンガープリント・キャッシュから削除す
る、などの方法も可能である。また、参照データに唯一
のデータを使用した場合であって、かつ、差分圧縮対象
となったデータと、その差分圧縮に用いた参照データと
が、ほとんど同じ内容であって、かつ、ＵＲＬが同一の
場合には、データが更新されたものとして、圧縮対象で
未登録のデータをフィンガープリント・キャッシュに登
録し、参照データはフィンガープリント・キャッシュか
ら削除する、などの方法も可能である。その他にも種々
のバリエーションがある。

【０１８６】次に、図３２を参照しながら、図３０また
は図３１の動作が行われてキャッシュ登録されているデ
ータを、サーバ側プロキシ３０からクライアント側プロ
キシ４０へ転送する場合の動作について説明する。

【０１８７】（１）〜（４）は、図３０を参照して説明
した動作における（１）〜（４）と同様である。

【０１８８】（５）サーバ５０からリプライメッセージ
を受け取ったサーバ側プロキシ４０は、まず、受信リプ
ライメッセージの持つリプライデータのフィンガープリ
ントを計算し、そのフィンガープリント名を持ったデー
タがＦＰキャッシュ３４に入っているかどうかを調べ
る。ここではフィンガープリント・キャッシュ登録され
ているので、（例えばフィンガープリントの値をリプラ
イヘッダ等に入れ且つリプライボディを空にするなどし
て）リプライボディのデータをフィンガープリントで置
き換える。

【０１８９】（６）サーバ側プロキシ３０は、リプライ
ボディをフィンガープリントで置き換えたリプライメッ
セージをクライアント側プロキシ４０に転送する。

【０１９０】（７）リプライメッセージを受け取ったク
ライアント側プロキシ４０は、リプライデータがフィン
ガープリントで置き換えられていることを検出し、（前
述したように例えばリプライヘッダなどにて）指定され
たフィンガープリントを使ってＦＰキャッシュ４４から
対応するデータを取り出す。ここで、該データの圧縮識
別子が０である場合には、該データは差分圧縮データで
はないので、これをリプライボディに入れる。一方、該
データの圧縮識別子は１である場合には、該データは差
分圧縮データであるので、これを解凍してもとのリプラ
イデータを復元し、これをリプライボディに入れる。な
お、図３２は、前者の場合を例示している。また、リプ
ライヘッダ等にフィンガープリントの値などのサーバ側
プロキシ３０とクライアント側プロキシ４０との間だけ
で使用される情報が存在する構成の場合には、これを削
除する。

【０１９１】（８）そして、クライアント側プロキシ３
０は、リプライメッセージを、クライアント５０（上で
動作するブラウザ等）へ送り返す。

【０１９２】ところで、サーバ側プロキシ３０およびク
ライアント側プロキシ４０のフィンガープリント・キャ
ッシュは、その容量に上限があるため、所定のアルゴリ
ズムに従いガベージコレクションを行って、例えば古い
データや使いそうに無いデータを消して行くのが好まし
い。

【０１９３】ただし、このようにすると、サーバ側プロ
キシ３０のＦＰキャッシュ３４は持っていてもクライア
ント側プロキシ４０のＦＰキャッシュ４４では既に消さ
れているようなデータが発生し得ることになるので、図
３２を参照して説明した動作における（７）で、クライ
アント側プロキシ４０において、フィンガープリントを
もとにしてＦＰキャッシュ４４からリプライデータを置
き換えるべきデータを得ようとしたが、ＦＰキャッシュ
４４に該当するフィンガープリントとデータの組が存在
しない場合がある。このような場合には、例えば、クラ
イアント側プロキシ４０は、サーバ側プロキシ３０に対
して、指定したフィンガープリントのデータを送るよう
に依頼し、依頼されたサーバ側プロキシ３０は、指定さ
れたフィンガープリントのデータをＦＰキャッシュ３４
から取り出して送り返すような仕組みを設ければよい。

【０１９４】なお、逆に、サーバ側プロキシ３０のＦＰ
キャッシュ３４では既に消されているがクライアント側
プロキシ４０のＦＰキャッシュ４４はまだ持っていてる
ようなデータが存在する場合には、図３０を参照して説
明した動作における（７）や図３１を参照して説明した
動作における（９）で、クライアント側プロキシ４０に
おいて、フィンガープリント／データをＦＰキャッシュ
４４に登録する際に、その時点で登録されていたフィン
ガープリント／リプライデータに対して上書きしてもよ
い。

【０１９５】図３２を参照して説明した動作における
（５）で、サーバ側プロキシ３０において、リプライデ
ータのフィンガープリントを求め、該フィンガープリン
トがＦＰキャッシュ３４に入っていれば、当該プライデ
ータと同じデータが該フィンガープリントと組になって
ＦＰキャッシュ３４に入っているものとみなして処理し
ている。実用上、異なるデータから同じフィンガープリ
ントが生成されないことを前提にすれば、この方法で十
分であるが、非常に小さな確率で異なるデータのフィン
ガープリントが偶々同じ値になってしまった場合に生じ
るエラーを取り除くようにする方法もある。この場合に
は、リプライデータから求めたフィンガープリントがＦ
Ｐキャッシュ３４に入っているときに、該フィンガープ
リントと組になってＦＰキャッシュ３４に入っているデ
ータと、当該プライデータとを比較して、同じか否かを
判断するようにすればよい。このとき、もしフィンガー
プリントは同じであるが内容が異なるデータが登録され
ていると判断された場合の処理は、以下に例示するよう
な方法が考えられる。 ・そのフィンガープリントは以降使用しないものとする
（そのフィンガープリントを与えるデータは以後キャッ
シュされないことになる） ・先に登録されているフィンガープリント／データを優
先する（登録中のフィンガープリントと同じ値のフィン
ガープリントを与える他のデータは、その登録中はキャ
ッシュされないことになる） ・現在登録対象となっているフィンガープリント／デー
タを優先する（登録中のフィンガープリント／データ
は、同じ値のフィンガープリントを与える他のデータに
よって次々と更新されていくことになる） ところで、これまで説明した例では、サーバ側プロキシ
３０からクライアント側プロキシ４０へリプライデータ
を転送する際にフィンガープリント・キャッシュを利用
するものとし、あるデータとこれに対するフィンガープ
リントとの組をフィンガープリント・キャッシュに登録
するタイミングは、そのデータが初めてサーバ側プロキ
シ３０からクライアント側プロキシ４０へ転送されると
きとしている。しかし、例えばＷｅｂベースのＡＳＰの
ような利用法では、データはまずユーザオフィス等で作
成されてサーバに登録され、それをブラウザ等からアク
セスするような場合が多いため、このような場合には、
当該データを（データ本体または差分圧縮データとし
て）サーバに登録する時点でクライアント側プロキシお
よびサーバ側プロキシのフィンガープリント・キャッシ
ュに登録しておくと、それ以降のアクセスを高速化する
ことができる。そこで、サーバが送信するリプライデー
タが、もともとはクライアントからサーバへ転送された
データ（ただし、この転送のときはリクエストデータ）
である場合には、登録タイミングを、該リプライデータ
となる元のリクエストデータが初めてクライアント側プ
ロキシ４０からサーバ側プロキシ３０へ転送されるとき
とするようにしてもよい（この場合、当該データがリプ
ライデータとなって初めてサーバ側プロキシ３０からク
ライアント側プロキシ４０へ転送される際には、すでに
フィンガープリント・キャッシュへの登録が完了してい
ることになるので、リプライデータとしては初めての転
送であっても、フィンガープリント・キャッシュを利用
して、転送データ量を削減することができる）。

【０１９６】さて、これまで説明した例では、サーバ側
プロキシ３０からクライアント側プロキシ４０へリプラ
イデータを転送するときに、該リプライデータがフィン
ガープリント・キャッシュに登録されているデータと同
じものである場合には、該リプライデータに代えて、対
応するフィンガープリントを転送し、または差分圧縮デ
ータを転送することで、ネットワークのトラフィックを
軽減しているが、本発明は、クライアント側プロキシ４
０からサーバ側プロキシ３０へリクエストデータを転送
する場合についてさらに適用することが可能である。

【０１９７】なお、ＦＰ圧縮を両方に適用する場合に、
差分圧縮をいずれか一方についてのみ適用することも可
能である。

【０１９８】また、ＦＰ圧縮および差分圧縮を、クライ
アント側プロキシ４０からサーバ側プロキシ３０へリク
エストデータを転送する場合についてのみ適用すること
も可能である。

【０１９９】ＦＰ圧縮および差分圧縮をクライアント側
プロキシ４０からサーバ側プロキシ３０へのリクエスト
データ転送に適用する場合、すでに説明したリプライデ
ータに対するサーバ側プロキシ３０とクライアント側プ
ロキシ４０との役割を逆にすればよいので、ＦＰ圧縮お
よび差分圧縮を両データ転送に適用する場合には、サー
バ側プロキシ３０は図１９の構成に加えて、更に処理部
３２にフィンガープリント解凍処理部および差分解凍処
理部を備え、クライアント側プロキシ４０は図２０の構
成に加えて、更に処理部４２にフィンガープリント圧縮
処理部および差分圧縮処理部を備えればよい。

【０２００】なお、いずれのプロキシにおいても、フィ
ンガープリント圧縮処理部とフィンガープリント解凍処
理部とを併せて、フィンガープリント（ＦＰ）圧縮・解
凍処理部としてもよい。同様に、差分圧縮処理部と差分
解凍処理部とを併せて、差分圧縮・解凍処理部としても
よい。

【０２０１】また、サーバ側プロキシ３０やクライアン
ト側プロキシ４０は、リプライデータ転送に対するフィ
ンガープリント・キャッシュとは独立にリクエストデー
タ転送に対するフィンガープリント・キャッシュを設け
てもよいが、リプライデータ転送とクエストデータ転送
とで同じフィンガープリント・キャッシュを共用しても
よい。なお、差分圧縮の際に前述した履歴表を使用する
構成の場合には、履歴表についても同様に独立して設け
てもよいし、共用してもよい。

【０２０２】図３３に、リプライデータ転送とクエスト
データ転送とで同じフィンガープリント・キャッシュを
共用する場合のプロキシ（サーバ側プロキシ、クライア
ント側プロキシ）の構成例を示す。

【０２０３】また、図３４及び図３５に、クライアント
側プロキシ４０からサーバ側プロキシ３０へリクエスト
メッセージを転送する際のクライアント側プロキシ４０
の処理手順の一例を示す。図３４及び図３５は、図２１
及び図２２において、転送するメッセージがリプライメ
ッセージからリクエストメッセージになり、メッセージ
送信元がサーバからクライアントになり、メッセージ送
信先がクライアントからサーバになり、サーバ側プロキ
シ３０の動作とクライアント側プロキシ４０の動作とを
入れ替えたものに相当する。

【０２０４】また、図３６〜図３８に、クライアント側
プロキシ４０からサーバ側プロキシ３０へリクエストメ
ッセージを転送する際のサーバ側プロキシ３０の処理手
順の一例を示す。

【０２０５】図３６〜図３８は、図２３〜図２５におい
て、転送するメッセージがリプライメッセージからリク
エストメッセージになり、メッセージ送信元がサーバか
らクライアントになり、メッセージ送信先がクライアン
トからサーバになり、サーバ側プロキシ３０の動作とク
ライアント側プロキシ４０の動作とを入れ替えたものに
相当する。

【０２０６】このようにリクエストデータに対してもフ
ィンガープリントまたは差分圧縮データで置き換えられ
るように実施すると、例えば、同じファイルを何度もサ
ーバにアップロードするときには、２回目以降フィンガ
ープリントを送るだけで済むので、ネットワークのトラ
フィックを軽減させることができる。

【０２０７】なお、本実施形態では、クライアント側プ
ロセスからサーバ側プロキシへ転送されるリクエストメ
ッセージや、サーバ側プロキシからクライアント側プロ
セスへ転送されるリプライメッセージを対象とする場合
について示してきたが、あるプロキシに、リクエストメ
ッセージを送信する装置とリプライメッセージを送信す
る装置との両方、あるいはリクエストメッセージおよび
リプライメッセージの両方を送信する装置が接続されて
いる場合には、もちろん、クライアント側プロセスから
サーバ側プロキシへ転送されるリクエストメッセージお
よびリプライメッセージならびにサーバ側プロキシから
クライアント側プロセスへ転送されるリクエストメッセ
ージおよびリプライメッセージを対象とすることや、ク
ライアント側プロセスからサーバ側プロキシへ転送され
るリクエストメッセージおよびサーバ側プロキシからク
ライアント側プロセスへ転送されるリクエストメッセー
ジのみ対象とすることなども可能である。

【０２０８】ところで、これまでは１つのサーバ側プロ
キシと１つのクライアント側プロキシとの間の１対１の
通信に着目して説明してきたが、本発明の適用範囲はも
ちろんサーバ側プロキシとクライアント側プロキシとが
１対１で通信するシステムには限定されるものではな
く、サーバ側プロキシとクライアント側プロキシとが１
対多で通信するシステム、サーバ側プロキシとクライア
ント側プロキシとが多対１で通信するシステム、あるい
はサーバ側プロキシとクライアント側プロキシとが多対
多で通信するシステムにも適用可能である。例えば、図
３９のように、複数のユーザオフィスに設置したクライ
アント側プロキシや、モバイルユーザが利用する個人用
プロキシなどがサーバ側プロキシを共有して使用するよ
うに実施することも可能である。

【０２０９】また、これまでは、１つのメッセージに含
まれるデータ全体をＦＰ圧縮する対象（フィンガープリ
ント・キャッシュに登録する対象）にしていたが、例え
ば、１つのメッセージに含まれるデータが所定の単位の
データの集合で構成される場合には、１つのメッセージ
に含まれる一部の単位データのみＦＰ圧縮する対象（フ
ィンガープリント・キャッシュに登録する対象）にする
構成も可能である。

【０２１０】ところで、本実施形態のサーバ側プロキシ
あるいはクライアント側プロキシ（一方でも両方でもよ
い）に、プロキシの共有キャッシュ機構でキャッシュ可
能とされているリプライデータについて、クライアント
が出したリクエストメッセージにおいて指定されていた
ＵＲＬと、該リクエストメッセージに対応するリプライ
メッセージに含まれていたリプライデータと、該リプラ
イデータに対応するフィンガープリントと、該リプライ
メッセージのリプライ・ヘッダに入れられて来たＭＩＭ
Ｅタイプなどのリクエスト・ヘッダを構成するのに必要
な情報や有効期間の判定に使うためのタイムスタンプな
どの情報を対応付けてキャッシュしておき（フィンガー
プリント・キャッシュにすべて保持してもよいし、リプ
ライデータを除く情報（ＵＲＬとフィンガープリントと
他の情報）を保持する対応テーブルを別途設けてもよ
い）、これとフィンガープリント・キャッシュとを併用
することで、プロキシサーバの共有キャッシュの動作を
も行うようにすることができる。例えば、クライアント
側プロキシに該キャッシュ機能を設けた場合、クライア
ントが送信したリクエストメッセージにて指定されてい
るＵＲＬに対するリプライデータがキャッシュされてお
り且つ該データが有効である場合には、該クライアント
側プロキシが、ＵＲＬに対応するデータをフィンガープ
リント・キャッシュから取得して、リプライメッセージ
を作成して、これをクライアントに応答することができ
る。

【０２１１】この機能は、個々のサーバ側プロキシ３０
毎に、また個々のクライアント側プロキシ４０毎に、設
けるか否かを定めることができる。

【０２１２】まず、上記機能を設けたクライアント側プ
ロキシ４０について説明する。

【０２１３】図４０に、この場合のクライアント側プロ
キシ４０の構成例を示す。このクライアント側プロキシ
４０は、図２０の構成・機能に加えて、更に過去にアク
セスしたＵＲＬと、そのリプライデータのフィンガープ
リントとの対応を保持するＵＲＬ・フィンガープリント
・テーブル（ＵＲＬ・ＦＰテーブル）４５と、ＵＲＬキ
ャッシュ処理部４２７とを備えている。

【０２１４】なお、ＵＲＬ・ＦＰテーブル４５には、Ｕ
ＲＬおよびフィンガープリント以外に、そのＵＲＬでア
クセスしたときにリプライヘッダに入れられて来たＭＩ
ＭＥタイプや、有効期間の判定に使うためのタイムスタ
ンプなどの情報も併せて記録する。また、ＵＲＬ・ＦＰ
テーブル４５には、従来の共有キャッシュがキャッシュ
できる場合にのみ必要な情報を記録する。

【０２１５】図４１に、サーバ側プロキシ３０からクラ
イアント側プロキシ４０へリプライメッセージを転送す
る際のクライアント側プロキシ４０の処理手順例を示
す。

【０２１６】なお、この場合の処理手順は、図２３〜図
２５の手順の端子４および端子６およびステップＳ３８
の後に追加される以外は、図２３〜図２５の手順と同じ
であり、図４１では、図２３〜図２５の手順の端子４お
よび端子６およびステップＳ３８より後の処理手順の部
分を示してある。ここでは、図２３〜図２５で説明した
手順に追加する部分を中心に説明する。

【０２１７】クライアント側プロキシ４０は、送信部４
３により、クライアント５０にリプライメッセージを送
信（図２３〜図２５のステップＳ２８、Ｓ２９、Ｓ３
２、Ｓ３５またはＳ３８）した後、ＵＲＬキャッシュ処
理部４２７にて、該リプライメッセージがキャッシュ対
象のものであるか否か調べ、判断する（Ｓ３９）。キャ
ッシュ対象であると判断されたならば、ＵＲＬキャッシ
ュ処理部４２７にて、ＵＲＬとフィンガープリントとリ
プライヘッダを構成するのに必要な情報等を対応付けて
（ＵＲＬをキーにして）をＵＲＬ・ＦＰテーブル４５に
登録する（Ｓ４０）。キャッシュ対象でないと判断され
たならば、何もしない。

【０２１８】なお、ステップＳ３９の判断およびステッ
プＳ４０のＵＲＬ・ＦＰテーブルへの登録は、ステップ
Ｓ２３とステップＳ２８あるいはＳ２９、ステップＳ２
３とステップＳ３２あるいはステップＳ３５の間にて行
うようにしても構わない。

【０２１９】なお、登録時の受信リプライメッセージが
キャッシュ対象のものであるか否かの判断方法は、従来
の登録時の手法と同様で構わない（例えば、ＧＥＴメソ
ッドのリプライデータであって、かつ、そのヘッダにキ
ャッシュ不可を示す情報が記述されていないものをキャ
ッシュ対象とする等）。

【０２２０】次に、図４２および図４３に、クライアン
ト２５０から受信したリクエストメッセージをクライア
ント側プロキシ４０からサーバ側プロキシ３０へ転送す
る際のクライアント側プロキシ４０におけるプロキシサ
ーバの共有キャッシュの動作に関する処理手順の一例を
示す。

【０２２１】クライアント側プロキシ４０は、受信部４
１により、クライアント５０からリクエストメッセージ
を受信する（ステップＳ１４１）。

【０２２２】ＵＲＬキャッシュ処理部４２７は、リクエ
ストメッセージに対するリプライメッセージがキャッシ
ュ対象のものであるか否か調べ、判断する（Ｓ１４
２）。なお、応答時のキャッシュ対象か否かの判断方法
は、従来の応答時の手法と同様で構わない（例えば、受
信リクエストメッセージがＧＥＴメソッドのものである
か否か）。

【０２２３】リクエストデータがキャッシュ対象外のも
のと判断されたならば（Ｓ１４２）、受信したリクエス
トメッセージを送信部４３からサーバ側プロキシ３０へ
転送する（Ｓ１５１）。

【０２２４】ステップＳ１４２にて該リクエストメッセ
ージに対するリプライメッセージがキャッシュ対象のも
のであると判断されたならば、ＵＲＬキャッシュ処理部
４２７は、さらに、該リクエストメッセージに指定され
ているＵＲＬを取り出し（Ｓ１４３）、そのＵＲＬをキ
ーとしてＵＲＬ・ＦＰテーブル４５を検索する（Ｓ１４
４）。

【０２２５】そのＵＲＬに対応するリプライデータのフ
ィンガープリントがキャッシュされていなければ（Ｓ１
４５）、受信したリクエストメッセージを送信部４３か
らサーバ側プロキシ３０へ転送する（Ｓ１５１）。この
とき、現在保持しているデータのタイムスタンプをリク
エストメッセージのIf-Modified-Sinceヘッダに記入し
てサーバ側プロキシ３０へ転送し、サーバ側プロキシ３
０から現在保持しているデータが有効であるとのリプラ
イメッセージを受け取ると、ステップＳ１４７へ行くよ
うに実施することもできる。

【０２２６】また、そのＵＲＬに対応するリプライデー
タのフィンガープリントが登録されていても（Ｓ１４
５）、併せて保持されている有効期間の判定のための情
報に基づいてそのデータが無効になっていると判断され
れば（Ｓ１４６）、受信したリクエストメッセージを送
信部４３からサーバ側プロキシ３０へ転送する（Ｓ１５
１）。

【０２２７】一方、そのＵＲＬに対応するリプライデー
タのフィンガープリントが登録されており（Ｓ１４
５）、かつ、併せて保持されている有効期間の判定のた
めの情報に基づいてそのデータが有効であると判断され
れば（Ｓ１４６）、ＵＲＬキャッシュ処理部４２７は、
ＵＲＬ・ＦＰテーブル４５からリプライデータを構成す
るのに必要な情報を得るとともに、当該ＵＲＬに対応す
るリプライデータのフィンガープリントをキーとしてＦ
Ｐキャッシュ４４を検索する（Ｓ１４７）。

【０２２８】次に、ＦＰキャッシュ管理部４２２は、ス
テップＳ１４７にて取得したデータが差分圧縮データで
あるかどうかを、圧縮識別子が０または１のいずれであ
るかをもって判断する（Ｓ１４８）。圧縮識別子が０で
あれば、差分圧縮データではないと判断され、１であれ
ば、差分圧縮データであると判断される。

【０２２９】該データが差分圧縮データであることが判
明した場合（Ｓ１４８）、差分解凍処理部４２４は該デ
ータを解凍し、リプライデータを生成する（Ｓ１４
９）。そして、該リプライデータからリプライメッセー
ジを生成し、送信部４３からクライアントへ転送する
（Ｓ１５０）。

【０２３０】一方、該データが差分圧縮データでないこ
とが判明した場合（Ｓ１４８）、ＦＰ圧縮解凍部４２３
は、該データからリプライデータを生成し、送信部４３
からクライアントへ転送する（Ｓ１５０）。

【０２３１】以下では、図４４（応答時）を参照しなが
ら、共有キャッシュの動作についてより具体的に説明す
る。

【０２３２】（１）クライアント５０上のブラウザ等
は、例えば“/C.html”というＵＲＬでサーバ２０に、
ＧＥＴメソッドのリクエストメッセージを出したとす
る。

【０２３３】（２）新しいＵＲＬでリクエストが来たと
きに、そのＵＲＬがＵＲＬ・ＦＰテーブル４５に載って
いれば、従来の共有キャッシュと同様に有効期間の判定
を行い、有効と判断できれば、そのＵＲＬに対応するフ
ィンガープリントをＵＲＬ・ＦＰテーブル４５を引いて
求め、それを名前とするデータをＦＰキャッシュ４４か
ら取り出す。そして、圧縮識別子により、該データが差
分圧縮データかどうか調べる。図４４の例では、圧縮識
別子が１であるので差分圧縮データである。すると、差
分圧縮を解凍し（図４４では、差分圧縮データ内に、フ
ィンガープリントが“７１Ｆ０…７３Ｅ６”であるデー
タへの参照情報があるため、既にキャッシュされている
該データが参照され、解凍される）、これをリプライデ
ータとする。さらに、ＵＲＬ・ＦＰテーブル４５からＭ
ＩＭＥタイプ等のリプライヘッダを構成するのに必要な
情報を取り出してリプライヘッダを作成する。

【０２３４】（３）作成したリプライメッセージを、ク
ライアント５０（上で動作するブラウザ等）へ送り返
す。

【０２３５】なお、キャッシュの内容が指定した時間以
降に更新されている場合にのみデータを送ることを依頼
するIf-Modified-Sinceヘッダを持つリクエストメッセ
ージの場合も、まずＵＲＬ・ＦＰテーブルを参照し更新
されていないことが判断できれば、そこでリプライメッ
セージを作成して返し、そうでなければサーバまで再び
If-Modified-Sinceの情報を書き直して聞きに行くよう
に実施することもできる。

【０２３６】次に、キャッシュ機能を設けたサーバ側プ
ロキシ３０について説明する。

【０２３７】上記ではクライアント側プロキシ４０のキ
ャッシュ機能について説明したが、サーバ側プロキシ３
０も同様に実施可能である。

【０２３８】この場合、クライアント側プロキシ４０に
対するメッセージ転送元のクライアント５０とメッセー
ジ転送先のサーバ側プロキシ３０が、サーバ側プロキシ
３０に対してはそれぞれクライアント側プロキシ４０
（転送元）とサーバ２０（転送先）になり、キャッシュ
に関係する構成・手順は同様である。

【０２３９】図４５に、この場合のサーバ側プロキシ３
０の構成例を示す。このサーバ側プロキシ３０は、図１
９の構成・機能に加えて、更に過去にアクセスしたＵＲ
Ｌと、そのリプライデータのフィンガープリントとの対
応を保持するＵＲＬ・フィンガープリント・テーブル
（ＵＲＬ・ＦＰテーブル）３５と、ＵＲＬキャッシュ処
理部３２７とを備えている。

【０２４０】図４６に、サーバ側プロキシ３０からクラ
イアント側プロキシ４０へリプライメッセージを転送す
る際のサーバ側プロキシ３０の処理手順の一例を示す。

【０２４１】なお、この場合の処理手順は、図２１及び
図２２の手順のステップＳ６および端子２およびＳ１３
の後に追加される以外は、図２１及び図２２の手順と同
じであり、図４６では、図２１及び図２２の手順のステ
ップＳ６および端子２およびＳ１３より後の処理手順の
部分を示してある。ここでは、図２１及び図２２で説明
した手順と相違する部分を中心に説明する。

【０２４２】サーバ側プロキシ３０は、送信部３３によ
り、クライアント側プロキシ４０にリプライメッセージ
を送信（図２１及び図２２のステップＳ６、Ｓ９、Ｓ１
１、またはＳ１３）した後、ＵＲＬキャッシュ処理部３
２７にて、該リプライメッセージのリプライデータがキ
ャッシュ対象のものであるか否か調べ、判断する（Ｓ１
４）。キャッシュ対象であると判断されたならば、ＵＲ
Ｌキャッシュ処理部３２７にて、ＵＲＬとフィンガープ
リントとリプライヘッダを構成するのに必要な情報等を
対応付けて（ＵＲＬをキーにして）をＵＲＬ・ＦＰテー
ブル３５に登録する（Ｓ１５）。キャッシュ対象でない
と判断されたならば、何もしない。

【０２４３】もちろん、前述と同様に、この手順も種々
変形することが可能である。

【０２４４】図４７に、クライアント側プロキシ４０か
ら受信したリクエストメッセージをサーバ側プロキシ３
０からサーバ２０へ転送する際のサーバ側プロキシ３０
におけるプロキシサーバの共有キャッシュの動作に関す
る処理手順の一例を示す。

【０２４５】サーバ側プロキシ３０は、受信部３１によ
り、クライアント側プロキシ４０からリクエストメッセ
ージを受信する（ステップＳ１６１）。

【０２４６】ＵＲＬキャッシュ処理部３２７は、リクエ
ストメッセージに対するリプライメッセージがキャッシ
ュ対象のものであるか否か調べ、判断する（Ｓ１６
２）。なお、応答時のキャッシュ対象か否かの判断方法
は、従来の応答時の手法と同様で構わない（例えば、受
信リクエストメッセーシ゛がGETメソット゛のものであるか否か）。

【０２４７】リクエストデータがキャッシュ対象外のも
のと判断されたならば（Ｓ１６２）、受信したリクエス
トメッセージを送信部３３からサーバ２０へ転送する
（Ｓ１６９）。

【０２４８】ステップＳ１６２にて該リクエストメッセ
ージに対するリプライメッセージがキャッシュ対象のも
のであると判断されたならば、ＵＲＬキャッシュ処理部
３２７は、さらに、該リクエストメッセージに指定され
ているＵＲＬを取り出し（Ｓ１６３）、そのＵＲＬをキ
ーとしてＵＲＬ・ＦＰテーブル３５を検索する（Ｓ１６
４）。

【０２４９】そのＵＲＬに対応するリプライデータのフ
ィンガープリントがキャッシュされていなければ（Ｓ１
６５）、受信したリクエストメッセージを送信部３３か
らサーバ２０へ転送する（Ｓ１６９）。このとき、現在
保持しているデータのタイムスタンプをリクエストメッ
セージのIf-Modified-Sinceヘッダに記入してサーバ２
０へ転送し、サーバ２０から現在保持しているデータが
有効であるとのリプライメッセージを受け取ると、ステ
ップＳ１６７へ行くように実施することもできる。

【０２５０】また、そのＵＲＬに対応するリプライデー
タのフィンガープリントが登録されていても（Ｓ１６
５）、併せて保持されている有効期間の判定のための情
報に基づいてそのデータが無効になっていると判断され
れば（Ｓ１６６）、受信したリクエストメッセージを送
信部３３からサーバ２０へ転送する（Ｓ１６９）。

【０２５１】一方、そのＵＲＬに対応するリプライデー
タのフィンガープリントが登録されており（Ｓ１６
５）、かつ、併せて保持されている有効期間の判定のた
めの情報に基づいてそのデータが有効であると判断され
れば（Ｓ１６６）、ＵＲＬキャッシュ処理部３２７は、
ＵＲＬ・ＦＰテーブル３５からリプライデータを構成す
るのに必要な情報を得るとともに、当該ＵＲＬに対応す
るリプライデータのフィンガープリントをキーとしてＦ
Ｐキャッシュ３４を検索する（Ｓ１６７）。

【０２５２】ＦＰキャッシュ管理部３２２は、ＦＰキャ
ッシュ３４から取得したデータから、該フィンガープリ
ントの値を用いてリプライメッセージをＦＰ圧縮時のフ
ォーマットで生成し、送信部３３から、クライアント側
プロキシ４０へ送信する（Ｓ１６８）。

【０２５３】このように、サーバ側プロキシにもＵＲＬ
・ＦＰテーブル表を持ってキャッシュの処理をする構成
は、一つのサーバ側プロキシが複数のクライアント側プ
ロキシから使われているときに有効に働く。すなわち、
あるクライアント側プロキシから要求のあったキャッシ
ュ可能なデータが既に他のクライアント側プロキシによ
ってアクセスされている場合には、サーバ側プロキシに
もキャッシュされているので、そのデータを送り返すだ
けで処理が完了する。

【０２５４】このように、サーバ側プロキシにもＵＲＬ
・ＦＰテーブル表を持ってキャッシュの処理をする構成
は、一つのサーバ側プロキシが複数のクライアント側プ
ロキシから使われているときに有効に働く。すなわち、
あるクライアント側プロキシから要求のあったキャッシ
ュ可能なデータが既に他のクライアント側プロキシによ
ってアクセスされている場合には、サーバ側プロキシに
もキャッシュされているので、そのデータを送り返すだ
けで処理が完了する。

【０２５５】なお、以上では、ＵＲＬ・ＦＰテーブル表
をフィンガープリント・キャッシュとは別途に設ける場
合について説明したが、ＵＲＬ・ＦＰテーブル表をフィ
ンガープリント・キャッシュと一体化して構成すること
も可能である。

【０２５６】なお、いずれのプロキシにおいても、フィ
ンガープリント圧縮処理部とフィンガープリント解凍処
理部とを併せて、フィンガープリント（ＦＰ）圧縮・解
凍処理部としてもよい。また、いずれのプロキシにおい
ても、差分圧縮処理部と差分解凍処理部とを併せて、差
分圧縮・解凍処理部としてもよい。図４８に、この場合
のプロキシ（サーバ側プロキシ、クライアント側プロキ
シ）の構成例を示す。

【０２５７】ＦＰ圧縮を該リクエストデータ転送のみに
適用した場合、ＦＰ圧縮を該リプライデータ転送のみに
適用した場合、ＦＰ圧縮を該リクエストデータ転送およ
び該リプライデータ転送に適用した場合のいずれにおい
ても、リクエストメッセージが指定するＵＲＬに対応す
るリプライデータに対する共用キャッシュ機能に関する
構成をクライアント側プロキシのみに設けることも、サ
ーバ側プロキシのみに設けることも、両プロキシに設け
ることも可能である。

【０２５８】なお、本実施形態は、コンピュータに所定
の手段を実行させるための（あるいはコンピュータを所
定の手段として機能させるための、あるいはコンピュー
タに所定の機能を実現させるための）プログラムとして
実施することも、該プログラムを記録したコンピュータ
読取り可能な記録媒体として実施することもできる。

【０２５９】なお、この発明の実施の形態で例示した構
成は一例であって、それ以外の構成を排除する趣旨のも
のではなく、例示した構成の一部を他のもので置き換え
たり、例示した構成の一部を省いたり、例示した構成に
別の機能あるいは要素を付加したり、それらを組み合わ
せたりすることなどによって得られる別の構成も可能で
ある。また、例示した構成と論理的に等価な別の構成、
例示した構成と論理的に等価な部分を含む別の構成、例
示した構成の要部と論理的に等価な別の構成なども可能
である。また、例示した構成と同一もしくは類似の目的
を達成する別の構成、例示した構成と同一もしくは類似
の効果を奏する別の構成なども可能である。また、この
発明の実施の形態で例示した各種構成部分についての各
種バリエーションは、適宜組み合わせて実施することが
可能である。また、この発明の実施の形態は、個別装置
としての発明、関連を持つ２以上の装置についての発
明、システム全体としての発明、個別装置内部の構成部
分についての発明、またはそれらに対応する方法の発明
等、種々の観点、段階、概念またはカテゴリに係る発明
を包含・内在するものである。従って、この発明の実施
の形態に開示した内容からは、例示した構成に限定され
ることなく発明を抽出することができるものである。

【０２６０】本発明は、上述した実施の形態に限定され
るものではなく、その技術的範囲において種々変形して
実施することができる。

【０２６１】

【発明の効果】本発明によれば、データ転送装置間でデ
ータとその名前との対応を保持し、この対応を保持して
いるデータについては、データ本体を転送する代わりに
対応する名前を転送することで、データ転送装置間の転
送データ量を削減させることができる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るネットワーク・シス
テムの構成例を示す図

【図２】同実施形態に係るネットワーク・システムの他
の構成例を示す図

【図３】同実施形態に係るネットワーク・システムのさ
らに他の構成例を示す図

【図４】フィンガープリントについて説明するための図

【図５】同実施形態に係るフィンガープリント・キャッ
シュについて説明するための図

【図６】同実施形態で使用する差分圧縮の指示方法につ
いて説明するための図

【図７】同実施形態の差分圧縮の具体例について説明す
るための図

【図８】同実施形態の差分圧縮の具体例について説明す
るための図

【図９】同実施形態の差分圧縮の具体例について説明す
るための図

【図１０】同実施形態の差分圧縮の他の具体例について
説明するための図

【図１１】同実施形態の差分圧縮の他の具体例について
説明するための図

【図１２】同実施形態の差分圧縮の他の具体例について
説明するための図

【図１３】同実施形態の差分圧縮の他の具体例について
説明するための図

【図１４】同実施形態で使用するメッセージ・フォーマ
ットの一例を示す図

【図１５】同実施形態で使用するメッセージ・フォーマ
ットの他の例を示す図

【図１６】同実施形態で使用するメッセージ・フォーマ
ットのさらに他の例を示す図

【図１７】同実施形態で使用するメッセージ・フォーマ
ットのさらに他の例を示す図

【図１８】同実施形態で使用するメッセージ・フォーマ
ットのさらに他の例を示す図

【図１９】同実施形態に係るサーバ側プロキシの構成例
を示す図

【図２０】同実施形態に係るクライアント側プロキシの
構成例を示す図

【図２１】同実施形態に係るサーバ側プロキシの手順例
を示すフローチャート

【図２２】同実施形態に係るサーバ側プロキシの手順例
を示すフローチャート

【図２３】同実施形態に係るクライアント側プロキシの
手順例を示すフローチャート

【図２４】同実施形態に係るクライアント側プロキシの
手順例を示すフローチャート

【図２５】同実施形態に係るクライアント側プロキシの
手順例を示すフローチャート

【図２６】同実施形態の差分圧縮の処理手順の一例を示
すフローチャート

【図２７】同実施形態の差分圧縮の処理手順の他の例を
示すフローチャート

【図２８】同実施形態に係るサーバ側プロキシの手順例
を示すフローチャート

【図２９】同実施形態に係るクライアント側プロキシの
手順例を示すフローチャート

【図３０】同実施形態に係るプロキシ間のデータ転送に
ついて説明するための図

【図３１】同実施形態に係るプロキシ間のデータ転送に
ついて説明するための図

【図３２】同実施形態に係るプロキシ間のデータ転送に
ついて説明するための図

【図３３】同実施形態にプロキシの他の構成例を示す図

【図３４】同実施形態に係るクライアント側プロキシの
他の手順例を示すフローチャート

【図３５】同実施形態に係るクライアント側プロキシの
他の手順例を示すフローチャート

【図３６】同実施形態に係るサーバ側プロキシの他の手
順例を示すフローチャート

【図３７】同実施形態に係るサーバ側プロキシの他の手
順例を示すフローチャート

【図３８】同実施形態に係るサーバ側プロキシの他の手
順例を示すフローチャート

【図３９】同実施形態に係るネットワーク・システムの
さらに他の構成例を示す図

【図４０】同実施形態に係るクライアント側プロキシの
他の構成例を示す図

【図４１】同実施形態に係るクライアント側プロキシの
他の手順例を示すフローチャート

【図４２】同実施形態に係るクライアント側プロキシの
他の手順例を示すフローチャート

【図４３】同実施形態に係るクライアント側プロキシの
他の手順例を示すフローチャート

【図４４】同実施形態に係るクライアントとクライアン
ト側プロキシとの間のデータ転送について説明するため
の図

【図４５】同実施形態に係るサーバ側プロキシの他の構
成例を示す図

【図４６】同実施形態に係るサーバ側プロキシの他の手
順例を示すフローチャート

【図４７】同実施形態に係るサーバ側プロキシの他の手
順例を示すフローチャート

【図４８】同実施形態に係るプロキシのさらに他の構成
例を示す図

【図４９】従来のコンピュータ・ネットワーク・システ
ムについて説明するための図

【符号の説明】

２…ＡＳＰサーバセンター ４…ユーザオフィス １２…ＡＳＰサーバセンター内ＬＡＮ １４…ＷＡＮ １６…ユーザオフィス内ＬＡＮ ２０…サーバ装置 ３０…サーバ側プロキシ装置 ４０…クライアント側プロキシ装置 ３１，４１…受信部 ３２，４２…処理部 ３３，４３…送信部 ３４，４４…フィンガープリント・キャッシュ ３５，４５…ＵＲＬ・ＦＰテーブル ３２１，４２１…ＦＰ圧縮判定部 ３２２，４２２…フィンガープリント・キャッシュ管理
部 ３２３…ＦＰ圧縮処理部 ４２３…ＦＰ解凍処理部 ３２４…差分圧縮処理部 ４２４…差分解凍処理部 ３２５，４２５…ＦＰ圧縮・解凍処理部 ３２６，４２６…差分圧縮・解凍処理部 ３２７，４２７…ＵＲＬキャッシュ処理部 ５０…クライアント装置

───────────────────────────────────────────────────── フロントページの続き (72)発明者 木村 康浩 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 庄野 篤司 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 佐藤 英昭 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 關 俊文 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B082 GA01 HA02 HA05 HA08

Claims (22)

【特許請求の範囲】
1. 【請求項１】過去に他のデータ転送装置へ送信したデー
   タ又は該データを圧縮して表現した圧縮データと、該デ
   ータをもとに生成して該データに割り当てた名前とを対
   応付けて保持する保持手段と、 第１の通信装置から、前記他のデータ転送装置を介した
   第２の通信装置を宛先とするデータを受信する受信手段
   と、 この受信手段により前記データを受信した際に、該受信
   したデータの内容をもとに生成した名前が、前記保持手
   段に保持されている場合には、該受信したデータの代わ
   りに該名前を送信するための処理を行い、該名前が、前
   記保持手段に保持されていない場合には、前記保持手段
   に保持されている他のデータを参照データとし、該参照
   データに対応する前記名前を利用して、該受信したデー
   タを圧縮して表現することが可能であるならば、該受信
   したデータを圧縮して表現した圧縮データと該名前とを
   対応付けて前記保持手段に保持するとともに、該受信し
   たデータの代わりに該圧縮データを送信するための処理
   を行い、圧縮して表現することが可能でないならば、該
   受信したデータと該名前とを対応付けて前記保持手段に
   保持するとともに、該受信したデータを送信するための
   処理を行う処理手段と、 前記処理手段の処理に応じて前記データの代わりの前記
   名前、前記データの代わりの前記圧縮データ又は前記デ
   ータを、前記他のデータ転送装置へ送信する送信手段と
   を備えたことを特徴とするデータ転送装置。
2. 【請求項２】過去に他のデータ転送装置から受信したデ
   ータ又は該データを圧縮して表現した圧縮データと、該
   データをもとに生成して該データに割り当てた名前と、
   圧縮データであるか否か示す識別情報とを対応付けて保
   持する保持手段と、 第１の通信装置から送信され、第２の通信装置を宛先と
   するデータ、該データの代わりに該データを圧縮して表
   現した圧縮データ又は該データの代わりに該データの内
   容をもとに生成して該データに割り当てられた名前を、
   前記他のデータ転送装置を介して受信する受信手段と、 この受信手段により前記データを受信した場合には、該
   受信したデータと該データに割り当てられるべき名前と
   圧縮データでないことを示す識別情報とを対応付けて前
   記保持手段に保持するとともに、該受信したデータを送
   信するための処理を行い、前記データの代わりに前記圧
   縮データを受信した場合には、該受信したデータと該デ
   ータに割り当てられるべき名前と圧縮データであること
   を示す識別情報とを対応付けて前記保持手段に保持する
   とともに、該受信した圧縮データを解凍し、該解凍した
   データを送信するための処理を行い、前記データの代わ
   りに前記名前を受信した場合には、前記保持手段に該受
   信した名前に対応付けて保持されている前記識別情報を
   参照し、該データが圧縮データでないならば、該保持手
   段から該受信した名前に対応付けて保持されているデー
   タを取得し、該取得したデータを送信するための処理を
   行い、該データが圧縮データであるならば、該保持手段
   から該受信した名前に対応付けて保持されている圧縮デ
   ータを取得し、該取得した圧縮データを解凍し、該解凍
   したデータを送信するための処理を行う処理手段と、 前記処理手段の処理に応じて前記受信したデータ、前記
   解凍したデータ又は前記取得したデータを、前記第２の
   通信装置へ送信する送信手段とを備えたことを特徴とす
   るデータ転送装置。
3. 【請求項３】前記圧縮データは、前記保持手段に保持さ
   れている他のデータを参照データとし、該参照データに
   対応する前記名前を利用して表現したものであることを
   特徴とする請求項２に記載のデータ転送装置。
4. 【請求項４】前記処理手段は、前記圧縮データを受信し
   た場合に、該受信した圧縮データを解凍するにあたって
   は、該圧縮データに含まれる参照データに対応する名前
   と同一の名前に対応付けて前記保持手段に保持されてい
   るデータを取得し、該取得したデータを前記参照データ
   として、該圧縮データの元となったデータを復元するこ
   とをことを特徴とする請求項３に記載のデータ転送装
   置。
5. 【請求項５】前記圧縮データは、１又は複数の前記参照
   データに対応する前記名前と、当該各参照データのうち
   使用する部分を示す情報と、該使用する部分の接続方法
   を示す情報とを含むものであることを特徴とする請求項
   １ないし４のいずれか１項に記載のデータ転送装置。
6. 【請求項６】前記圧縮データは、１つの前記参照データ
   に対応する前記名前と、該参照データのうち該圧縮デー
   タの元となったデータと相違する部分を示す情報と、該
   相違する部分に嵌め込むべき内容とを含むものであるこ
   とを特徴とする請求項１ないし４のいずれか１項に記載
   のデータ転送装置。
7. 【請求項７】前記名前は、所定の方法によって前記デー
   タを圧縮して得た値であることを特徴とする請求項１な
   いし６のいずれか１項に記載のデータ転送装置。
8. 【請求項８】前記名前は、前記データに所定のハッシュ
   関数を適用して得られた値であることを特徴とする請求
   項１ないし６のいずれか１項に記載のデータ転送装置。
9. 【請求項９】前記第１の通信装置から受信したデータに
   ついて前記保持手段への保持を行う場合に、該受信した
   データが、前記第２の通信装置から該第１の通信装置へ
   の所定のリクエストメッセージに対するリプライメッセ
   ージのデータであるときに、該リプライメッセージに対
   応するリクエストメッセージが要求するデータについて
   のＵＲＬと、該データに割り当てられた前記名前とを対
   応付けて、前記保持手段または別の保持手段に保持して
   おき、 前記他のデータ転送装置から前記第２の通信装置が送信
   した所定のリクエストメッセージを受信した場合に、該
   リクエストメッセージが要求するデータについてのＵＲ
   Ｌが前記保持手段または別の保持手段に保持されている
   ときに、該ＵＲＬに対応する前記名前に対応付けて前記
   保持手段に保持されている前記データ又は前記圧縮デー
   タをもとに前記所定のリクエストメッセージに対するリ
   プライメッセージであって前記第２の通信装置に宛てた
   ものを作成し、 作成した前記リプライメッセージを前記他のデータ転送
   装置へ送信することを特徴とする請求項１に記載のデー
   タ転送装置。
10. 【請求項１０】前記他のデータ転送装置から受信したデ
    ータについて前記保持手段への保持を行う場合に、該受
    信したデータが、前記第２の通信装置から前記第１の通
    信装置への所定のリクエストメッセージに対するリプラ
    イメッセージのデータであるときに、該リプライメッセ
    ージに対応するリクエストメッセージが要求するデータ
    についてのＵＲＬと、該データに割り当てられた前記名
    前とを対応付けて、前記保持手段または別の保持手段に
    保持しておき、 前記第２の通信装置から所定のリクエストメッセージを
    受信した場合に、該リクエストメッセージが要求するデ
    ータについてのＵＲＬが前記保持手段または別の保持手
    段に保持されているときに、該ＵＲＬに対応する前記名
    前に対応付けて前記保持手段に保持されている前記デー
    タ又は前記圧縮データをもとに前記所定のリクエストメ
    ッセージに対するリプライメッセージを作成し、 作成した前記リプライメッセージを前記第２の通信装置
    へ送信することを特徴とする請求項２に記載のデータ転
    送装置。
11. 【請求項１１】前記所定のリクエストメッセージは、Ｇ
    ＥＴメソッドのリクエストメッセージであることを特徴
    とする請求項９または１０に記載のデータ転送装置。
12. 【請求項１２】少なくともリプライメッセージのデータ
    であって空でないものを対象として前記保持手段への保
    持及び前記名前の転送を行うことを特徴とする請求項１
    ないし１１のいずれか１項に記載のデータ転送装置。
13. 【請求項１３】予め定められた条件を満たすデータは、
    前記保持手段への保持を行う対象から除外することを特
    徴とする請求項１ないし１１のいずれか１項に記載のデ
    ータ転送装置。
14. 【請求項１４】前記第１の通信装置はサーバ装置であ
    り、前記第２の通信装置はクライアント装置であること
    を特徴とする請求項１ないし１３のいずれか１項に記載
    のデータ転送装置。
15. 【請求項１５】第１の通信装置から、他のデータ転送装
    置を介した第２の通信装置を宛先とするデータを受信
    し、 受信された前記データの内容をもとに生成した名前が、
    過去に前記他のデータ転送装置へ送信したデータ又は該
    データを圧縮して表現した圧縮データと該データをもと
    に生成して該データに割り当てた名前とを対応付けて保
    持する前記保持手段に保持されているか否か判断し、 保持されている場合には、受信された前記データの代わ
    りに前記名前を前記他のデータ転送装置へ送信し、 保持されていない場合には、前記保持手段に保持されて
    いる他のデータを参照データとし、該参照データに対応
    する前記名前を利用して、受信された前記データを圧縮
    して表現することが可能であるか否か判断し、可能であ
    るならば、受信された前記データを圧縮して表現した圧
    縮データと前記名前とを対応付けて前記保持手段に保持
    するとともに、受信された前記データの代わりに該圧縮
    データを前記他のデータ転送装置へ送信し、圧縮して表
    現することが可能でないならば、受信された前記データ
    と該名前とを対応付けて前記保持手段に保持するととも
    に、受信された前記データを前記他のデータ転送装置へ
    送信することを特徴とするデータ転送方法。
16. 【請求項１６】前記第１の通信装置から受信したデータ
    について前記保持手段への保持を行う場合に、該受信し
    たデータが、前記第２の通信装置から該第１の通信装置
    への所定のリクエストメッセージに対するリプライメッ
    セージのデータであるときに、該リプライメッセージに
    対応するリクエストメッセージが要求するデータについ
    てのＵＲＬと、該データに割り当てられた前記名前とを
    対応付けて、前記保持手段または別の保持手段に保持し
    ておき、 前記他のデータ転送装置から前記第２の通信装置が送信
    した所定のリクエストメッセージを受信した場合に、該
    リクエストメッセージが要求するデータについてのＵＲ
    Ｌが前記保持手段または別の保持手段に保持されている
    ときに、該ＵＲＬに対応する前記名前に対応付けて前記
    保持手段に保持されている前記データ又は前記圧縮デー
    タをもとに前記所定のリクエストメッセージに対するリ
    プライメッセージであって前記第２の通信装置に宛てた
    ものを作成し、 作成した前記リプライメッセージを前記他のデータ転送
    装置へ送信することを特徴とする請求項１５に記載のデ
    ータ転送方法。
17. 【請求項１７】第１の通信装置から送信され、第２の通
    信装置を宛先とするデータ、該データの代わりに該デー
    タを圧縮して表現した圧縮データ又は該データの代わり
    に該データの内容をもとに生成して該データに割り当て
    られた名前を、他のデータ転送装置を介して受信し、 前記他のデータ転送装置から前記データを受信した場合
    には、過去に他のデータ転送装置から受信したデータ又
    は該データを圧縮して表現した圧縮データと該データを
    もとに生成して該データに割り当てた名前と圧縮データ
    であるか否か示す識別情報とを対応付けて保持する保持
    手段に、該受信したデータと該データに割り当てられる
    べき名前と圧縮データでないことを示す識別情報とを対
    応付けて保持するとともに、該受信したデータを前記第
    ２の通信装置へ送信し、 前記データの代わりに前記圧縮データを受信した場合に
    は、該受信したデータと該データに割り当てられるべき
    名前と圧縮データであることを示す識別情報とを対応付
    けて前記保持手段に保持するとともに、該受信した圧縮
    データを解凍し、該解凍したデータを前記第２の通信装
    置へ送信し、 前記データの代わりに前記名前を受信した場合には、前
    記保持手段に該受信した名前に対応付けて保持されてい
    る前記識別情報を参照し、該データが圧縮データでない
    ならば、該保持手段から該受信した名前に対応付けて保
    持されているデータを取得し、該取得したデータを前記
    第２の通信装置へ送信し、該データが圧縮データである
    ならば、該保持手段から該受信した名前に対応付けて保
    持されている圧縮データを取得し、該取得した圧縮デー
    タを解凍し、該解凍したデータを前記第２の通信装置へ
    送信することを特徴とするデータ転送方法。
18. 【請求項１８】前記他のデータ転送装置から受信したデ
    ータについて前記保持手段への保持を行う場合に、該受
    信したデータが、前記第２の通信装置から前記第１の通
    信装置への所定のリクエストメッセージに対するリプラ
    イメッセージのデータであるときに、該リプライメッセ
    ージに対応するリクエストメッセージが要求するデータ
    についてのＵＲＬと、該データに割り当てられた前記名
    前とを対応付けて、前記保持手段または別の保持手段に
    保持しておき、 前記第２の通信装置から所定のリクエストメッセージを
    受信した場合に、該リクエストメッセージが要求するデ
    ータについてのＵＲＬが前記保持手段または別の保持手
    段に保持されているときに、該ＵＲＬに対応する前記名
    前に対応付けて前記保持手段に保持されている前記デー
    タ又は前記圧縮データをもとに前記所定のリクエストメ
    ッセージに対するリプライメッセージを作成し、 作成した前記リプライメッセージを前記第２の通信装置
    へ送信することを特徴とする請求項１７に記載のデータ
    転送方法。
19. 【請求項１９】過去に他のデータ転送装置へ送信したデ
    ータ又は該データを圧縮して表現した圧縮データと、該
    データをもとに生成して該データに割り当てた名前とを
    対応付けて記憶装置に保持する機能と、 第１の通信装置から、前記他のデータ転送装置を介した
    第２の通信装置を宛先とするデータを受信した際に、該
    受信したデータの内容をもとに生成した名前が、前記記
    憶装置に保持されている場合には、該受信したデータの
    代わりに該名前を送信するための処理を行い、該名前
    が、前記記憶装置に保持されていない場合には、前記記
    憶装置に保持されている他のデータを参照データとし、
    該参照データに対応する前記名前を利用して、該受信し
    たデータを圧縮して表現することが可能であるならば、
    該受信したデータを圧縮して表現した圧縮データと該名
    前とを対応付けて前記記憶装置に保持するとともに、該
    受信したデータの代わりに該圧縮データを送信するため
    の処理を行い、圧縮して表現することが可能でないなら
    ば、該受信したデータと該名前とを対応付けて前記記憶
    装置に保持するとともに、該受信したデータを送信する
    ための処理を行う機能とをコンピュータに実現させるた
    めのプログラム。
20. 【請求項２０】前記第１の通信装置から受信したデータ
    について前記記憶装置への保持を行う場合に、該受信し
    たデータが、前記第２の通信装置から該第１の通信装置
    への所定のリクエストメッセージに対するリプライメッ
    セージのデータであるときに、該リプライメッセージに
    対応するリクエストメッセージが要求するデータについ
    てのＵＲＬと、該データに割り当てられた前記名前とを
    対応付けて前記記憶装置に保持する機能と、 前記他のデータ転送装置から前記第２の通信装置が送信
    した所定のリクエストメッセージを受信した場合に、該
    リクエストメッセージが要求するデータについてのＵＲ
    Ｌが前記記憶装置に保持されているときに、該ＵＲＬに
    対応する前記名前に対応付けて前記記憶装置に保持され
    ている前記データ又は前記圧縮データをもとに前記所定
    のリクエストメッセージに対するリプライメッセージで
    あって前記第２の通信装置に宛てたものを作成する機能
    とを更にコンピュータに実現させるための請求項１９に
    記載のプログラム。
21. 【請求項２１】過去に他のデータ転送装置から受信した
    データ又は該データを圧縮して表現した圧縮データと、
    該データをもとに生成して該データに割り当てた名前
    と、圧縮データであるか否か示す識別情報とを対応付け
    て記憶装置に保持する機能と、 第１の通信装置から送信され、第２の通信装置を宛先と
    するデータ、該データの代わりに該データを圧縮して表
    現した圧縮データ又は該データの代わりに該データの内
    容をもとに生成して該データに割り当てられた名前を、
    前記他のデータ転送装置を介して受信する機能と、 この受信機能により前記データを受信した場合には、該
    受信したデータと該データに割り当てられるべき名前と
    圧縮データでないことを示す識別情報とを対応付けて前
    記記憶装置に保持するとともに、該受信したデータを送
    信するための処理を行い、前記データの代わりに前記圧
    縮データを受信した場合には、該受信したデータと該デ
    ータに割り当てられるべき名前と圧縮データであること
    を示す識別情報とを対応付けて前記記憶装置に保持する
    とともに、該受信した圧縮データを解凍し、該解凍した
    データを送信するための処理を行い、前記データの代わ
    りに前記名前を受信した場合には、前記記憶装置に該受
    信した名前に対応付けて保持されている前記識別情報を
    参照し、該データが圧縮データでないならば、該記憶装
    置から該受信した名前に対応付けて保持されているデー
    タを取得し、該取得したデータを送信するための処理を
    行い、該データが圧縮データであるならば、該記憶装置
    から該受信した名前に対応付けて保持されている圧縮デ
    ータを取得し、該取得した圧縮データを解凍し、該解凍
    したデータを送信するための処理を行う機能とをコンピ
    ュータに実現させるためのプログラム。
22. 【請求項２２】前記他のデータ転送装置から受信したデ
    ータについて前記記憶装置への保持を行う場合に、該受
    信したデータが、前記第２の通信装置から前記第１の通
    信装置への所定のリクエストメッセージに対するリプラ
    イメッセージのデータであるときに、該リプライメッセ
    ージに対応するリクエストメッセージが要求するデータ
    についてのＵＲＬと、該データに割り当てられた前記名
    前とを対応付けて前記記憶装置に保持する機能と、 前記第２の通信装置から所定のリクエストメッセージを
    受信した場合に、該リクエストメッセージが要求するデ
    ータについてのＵＲＬが前記記憶装置に保持されている
    ときに、該ＵＲＬに対応する前記名前に対応付けて前記
    記憶装置に保持されている前記データ又は前記圧縮デー
    タをもとに前記所定のリクエストメッセージに対するリ
    プライメッセージを作成する機能とを更にコンピュータ
    に実現させるための請求項２１に記載のプログラム。