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

Abstract

(57)【要約】 【課題】 ネットワークの負荷を軽減できるプロキシ装
置を提供すること。 【解決手段】 サーバ側プロキシ３０からクライアント
側プロキシ４０へ新たな内容のリプライデータを転送す
るにあたって、両プロキシにて、該データと該データに
ハッシュ関数を適用して算出したフィンガープリントと
を対応付けて、フィンガープリント・キャッシュに登録
しておく。サーバ側プロキシ３０からクライアント側プ
ロキシ４０へフィンガープリント・キャッシュに登録さ
れたフィンガープリントと同じフィンガープリントを持
つリプライデータを転送するにあたっては、該リプライ
データの代わりに該フィンガープリントを転送する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

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

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

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

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

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

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

【００１４】

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

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

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

【００１７】

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

【００１８】本発明は、第１の通信装置から送信された
データを他のデータ転送装置を介して受信し、該データ
をその宛先となる第２の通信装置へ送信するとともに、
該第２の通信装置から送信されたデータを受信し、該デ
ータをその宛先となる第１の通信装置に通ずる他のデー
タ転送装置へ送信するデータ転送装置であって、前記他
のデータ転送装置から前記データまたは該データの代わ
りに該データの内容をもとに生成して該データに割り当
てられた名前を受信するための受信手段と、過去に前記
他のデータ転送装置から受信したデータと、該データの
内容をもとに生成して該データに割り当てられた名前と
を対応付けて保持するための保持手段と、前記他のデー
タ転送装置から前記名前を受信した場合には、前記保持
手段から該受信した名前に対応付けて保持されているデ
ータを取得し、該取得したデータを送信するための処理
を行い、前記他のデータ転送装置から前記データを受信
した場合には、該受信したデータと該データに割り当て
られるべき名前とを対応付けて前記保持手段に保持する
ための処理を行うとともに、該受信したデータを送信す
るための処理を行う処理手段と、前記処理手段の処理に
応じて前記取得したデータまたは前記受信したデータ
を、前記第２の通信装置へ送信するための送信手段とを
備えたことを特徴とする。

【００１９】好ましくは、前記名前は、所定の方法によ
って前記データを圧縮して得た値であるようにしてもよ
い。好ましくは、前記名前は、前記データに所定のハッ
シュ関数を適用して得られた値であるようにしてもよ
い。

【００２０】好ましくは、前記データ転送装置は、ロー
カルエリアネットワークを介して前記第１の通信装置と
接続されたものであるようにしてもよい。好ましくは、
前記データ転送装置は、前記第１の通信装置上にソフト
ウェアとして搭載されたものであるようにしてもよい。
好ましくは、前記データ転送装置は、ローカルエリアネ
ットワークを介して前記第２の通信装置と接続されたも
のであるようにしてもよい。好ましくは、前記データ転
送装置は、前記第２の通信装置上にソフトウェアとして
搭載されたものであるようにしてもよい。

【００２１】また、好ましくは、前記第１の通信装置か
ら受信したデータについて前記保持手段への保持を行う
場合に、該受信したデータが、前記第２の通信装置から
該第１の通信装置へのリクエストメッセージに対するリ
プライメッセージのデータであるときに、該リプライメ
ッセージに対応するリクエストメッセージが要求するデ
ータについてのＵＲＬと、該データに割り当てられた前
記名前とを対応付けて、前記保持手段または別の保持手
段に保持しておき、前記他のデータ転送装置から前記第
２の通信装置が送信したリクエストメッセージを受信し
た場合に、該リクエストメッセージが要求するデータに
ついてのＵＲＬが前記保持手段または別の保持手段に保
持されているときに、該ＵＲＬに対応する前記名前に対
応付けて前記保持手段に保持されている前記データをも
とに前記リクエストメッセージに対するリプライメッセ
ージであって前記第２の通信装置に宛てたものを作成
し、作成した前記リプライメッセージを前記他のデータ
転送装置へ送信するようにしてもよい。

【００２２】また、好ましくは、前記他のデータ転送装
置から受信したデータについて前記保持手段への保持を
行う場合に、該受信したデータが、前記第２の通信装置
から前記第１の通信装置への所定のリクエストメッセー
ジに対するリプライメッセージのデータであるときに、
該リプライメッセージに対応するリクエストメッセージ
が要求するデータについてのＵＲＬと、該データに割り
当てられた前記名前とを対応付けて、前記保持手段また
は別の保持手段に保持しておき、前記第２の通信装置か
ら前記所定のリクエストメッセージを受信した場合に、
該リクエストメッセージが要求するデータについてのＵ
ＲＬが前記保持手段または別の保持手段に保持されてい
るときに、該ＵＲＬに対応する前記名前に対応付けて前
記保持手段に保持されている前記データをもとに前記リ
クエストメッセージに対するリプライメッセージを作成
し、作成した前記リプライメッセージを前記第２の通信
装置へ送信するようにしてもよい。

【００２３】また、本発明は、第１の通信装置から送信
されたデータを受信し、該データをその宛先となる第２
の通信装置に通ずる他のデータ転送装置へ送信するとと
もに、該第２の通信装置から送信されたデータを該他の
データ転送装置を介して受信し、該データをその宛先と
なる該第１の通信装置へ送信するデータ転送装置におけ
るデータ転送方法であって、前記第１の通信装置から送
信されたデータを受信し、受信された前記データの内容
をもとに生成した該データに割り当てるべき名前が、過
去に前記他のデータ転送装置へ送信したデータと該デー
タの内容をもとに生成して該データに割り当てた名前と
を対応付けて保持するための保持手段に保持されている
か否か判断し、保持されている場合には、受信された前
記データの代わりに前記名前を送信するための処理を行
い、保持されていない場合には、受信された該データと
前記名前とを対応付けて前記保持手段に保持するための
処理を行うとともに、該データを送信するための処理を
行うことを特徴とする。

【００２４】また、本発明は、第１の通信装置から送信
されたデータを他のデータ転送装置を介して受信し、該
データをその宛先となる第２の通信装置へ送信するとと
もに、該第２の通信装置から送信されたデータを受信
し、該データをその宛先となる第１の通信装置に通ずる
他のデータ転送装置へ送信するデータ転送装置における
データ転送方法であって、前記他のデータ転送装置から
前記データまたは該データの代わりに該データの内容を
もとに生成して該データに割り当てられた名前を受信
し、前記他のデータ転送装置から前記データの代わりに
該データの内容をもとに生成して該データに割り当てら
れた名前を受信した場合には、過去に前記他のデータ転
送装置から受信されたデータと該データの内容をもとに
生成して該データに割り当てられた名前とを対応付けて
保持するための保持手段から、受信された前記名前に対
応付けて保持されているデータを取得し、該取得したデ
ータを送信するための処理を行い、前記他のデータ転送
装置から前記データを受信した場合には、受信された該
データと該データに割り当てられるべき名前とを対応付
けて前記保持手段に保持するための処理を行うととも
に、受信された該データを送信するための処理を行うこ
とを特徴とする。

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

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

【００２７】例えば、ＧＥＴメソッドのリプライメッセ
ージがプライベートデータであっても、これをフィンガ
ープリントにより圧縮してデータ転送装置間を転送する
ことができるようになる。また、例えば、ＧＥＴメソッ
ドのリプライメッセージが動的データであっても、内容
が同じデータなら、これをフィンガープリントにより圧
縮してデータ転送装置間を転送することができるように
なる。また、例えば、ＰＯＳＴメソッドであっても、結
果が同じデータなら、これをフィンガープリントにより
圧縮してデータ転送装置間を転送することができるよう
になる。

【００２８】

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

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

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

【００３１】ＷＥＢベースのＡＳＰは、サーバセンター
２に設置したサーバ２０から、ＷＡＮ１４を介して、様
々なアプリケーションプログラムによるサービスを提供
し、ユーザはオフィス４に設置されたクライアント上の
ＷＥＢブラウザ等を使ってそれらのサービスにアクセス
する。

【００３２】このような利用形態においては、ユーザオ
フィス内ＬＡＮ１６とサーバセンター内ＬＡＮ１２とを
つなぐネットワーク、特にインターネットなどの広域ネ
ットワーク１４の実効的な通信容量（バンド幅）は、サ
ーバセンター内ＬＡＮ１２やユーザオフィス内ＬＡＮ１
６よりも低く、そこが性能上のボトルネックになって通
信遅延が発生し、アプリケーションの応答性能が低下す
るという問題が発生する。

【００３３】そこで、本実施形態では、図１に示すよう
に、サーバセンター内ＬＡＮ１２とユーザオフィス内Ｌ
ＡＮ１６とをつなぐ広域ネットワーク１４の両端に、サ
ーバ側プロキシ３０およびクライアント側プロキシ４０
という２つのモジュールを設置し、それらの間で後述す
るフィンガープリント圧縮（ＦＰ圧縮）を行って通信デ
ータ量を低減することで、広域ネットワークのボトルネ
ックを解消する。

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

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

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

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

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

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

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

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

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

【００４３】図５に示すように、サーバ側プロキシ３０
やクライアント側プロキシ４０の持つフィンガープリン
ト・キャッシュ（図中の６０）は、過去にＨＴＴＰプロ
トコルでやり取りされたデータ本体（図中の６１）を、
そのデータから計算して求めたフィンガープリントの値
（図中の６２）を名前として、記録・管理している。

【００４４】例えばＨＴＴＰプロトコルでサーバ側プロ
キシ３０からクライアント側プロキシ４０へデータを転
送するときに、サーバ側プロキシ３０は、当該データの
フィンガープリントを計算し、そのフィンガープリント
に対応するデータがフィンガープリント・キャッシュに
入っていれば、当該データ（と同じ内容のデータ）は過
去に転送したことがあるので、当該データを転送せず
に、対応するフィンガープリントの値を転送する。フィ
ンガープリントを受け取ったクライアント側プロキシ４
０は、当該フィンガープリントの値に対応するデータを
フィンガープリント・キャッシュから取り出すことで、
転送すべきデータを再現することができる。このような
方式（すなわち、データ圧縮→データ転送→データ解
凍）により、過去に送ったものと同じデータならばフィ
ンガープリントの値を送るだけでよいので、ネットワー
クを流れるデータ量を大幅に削減することができる。も
ちろん、クライアント側プロキシ４０からサーバ側プロ
キシ３０へデータを転送するときも同様である。

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

【００４６】なお、サーバ側プロキシ３０とクライアン
ト側プロキシ４０との間において、すべてのメッセージ
をＦＰ圧縮を適用する対象（すなわち、フィンガープリ
ント・キャッシュを利用してデータをフィンガープリン
トに置き換えるための処理を行う対象）としてもよい
が、例えばフィンガープリント・キャッシュの効果が期
待できないものなどに対する適用を除外するために、予
め定められた条件を満たすメッセージについては、これ
をＦＰ圧縮の適用対象外とする（常にＦＰ圧縮しないで
転送する）ようにしてもよい。この場合の予め定められ
た条件とは、例えば、メッセージ・ヘッダに予め定めら
れた情報が記述されていることである。具体的には、例
えば、メッセージ・ヘッダにＧＥＴメソッドを示す情報
およびリクエストを示す情報が記述されていることであ
る。また、予め定められた条件の他の例としては、転送
されるデータが空（ｎｕｌｌ）あるいは非常に短いサイ
ズであることである。もちろん、それらの他にも種々の
バリエーションがある。また、複数の条件を組み合わせ
て使用するようにしてもよい。

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

【００４８】なお、ＦＰ圧縮の適用対象外のメッセージ
は、ＦＰ圧縮については、何もせずにそのままの（ＦＰ
圧縮側（送信側）のプロキシが受信した際の）メッセー
ジ・フォーマットでプロキシ間を転送して構わない。あ
るいは、ＦＰ圧縮側（送信側）のプロキシが、例えばそ
のメッセージ・ヘッダに当該メッセージがＦＰ圧縮の適
用対象外を識別可能とする情報を持つようにして転送す
ることも可能である。

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

【００５０】非圧縮時のメッセージ・フォーマットは、
メッセージに含まれるデータがフィンガープリントキャ
ッシュに登録されていない場合に使用される。一方、圧
縮時のメッセージ・フォーマットは、メッセージに含ま
れるデータがフィンガープリントキャッシュに登録され
ている場合に使用される。

【００５１】解凍側（受信側）では、非圧縮時のフォー
マットのメッセージを受信したことを契機として、当該
データについてフィンガープリントキャッシュへの登録
を行うことができる。

【００５２】図６に、メッセージ・フォーマットの一例
を示す。（ａ）は非圧縮時のメッセージであり、（ｂ）
は圧縮時のメッセージである。

【００５３】（ａ）ではメッセージ・ボディーにデータ
が載せられ、（ｂ）ではメッセージ・ボディーにデータ
の代わりにフィンガープリント（ＦＰ）が載せられる。
また、この例では、メッセージ・ヘッダに、ＦＰ圧縮の
有無を識別可能とする識別情報が（圧縮側のプロキシに
おいて）記述され、この識別情報に基づいて（解凍側の
プロキシにおいて）ＦＰ圧縮の有無を識別する（例え
ば、０ならば圧縮なし、１ならば圧縮あり）。なお、識
別情報は、プロキシ間で使用される特別のものであって
もよいし、もともと通常のＨＴＴＰメッセージ・ヘッダ
に存在するフィールドを利用あるいは併用したものであ
ってもよい。

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

【００５５】なお、ＦＰ圧縮の適用対象外のメッセージ
が存在し得る場合には、解凍側（受信側）では、メッセ
ージ・ヘッダに上記の識別情報が含まれるか否かで、Ｆ
Ｐ圧縮の適用対象のメッセージか適用対象外のメッセー
ジかを判断することもできる。また、ＦＰ圧縮の適用対
象外のメッセージのヘッダにも識別情報を設け、該識別
情報によって３種類のメッセージを識別するようにして
もよい（例えば、０１ならば適用対象外、１０なら（適
用対象であって且つ）圧縮なし、１１なら（適用対象で
あって且つ）圧縮あり）。

【００５６】ここで、図３２に図６（ａ）のフォーマッ
トのメッセージの具体例を示し、図３３に図６（ｂ）の
フォーマットのメッセージの具体例を示す。各図のヘッ
ダ中の“Ｆｉｎｇｅｒｐｒｉｎｔ−Ｍｏｄｅ：…”が識
別情報に相当し、図３３のボディの“６Ｅ３９…０１２
８”がフィンガープリントに相当する。

【００５７】また、図３４に、図７のフォーマットのメ
ッセージの具体例を示す。ヘッダ中の“Ｆｉｎｇｅｒｐ
ｒｉｎｔ：…”がフィンガープリントに相当する。

【００５８】図８に、メッセージ・フォーマットの他の
例を示す。（ａ）は非圧縮時のメッセージであり、
（ｂ）は圧縮時のメッセージである。（ａ）ではメッセ
ージ・ボディーにデータが載せられ、（ｂ）ではメッセ
ージ・ボディーは空（ｎｕｌｌ）である。また、この例
では、（ａ），（ｂ）ともにメッセージ・ヘッダにフィ
ンガープリント（ＦＰ）が記述される。ＦＰ圧縮の有無
を識別可能とする識別情報について上記の例と同様であ
る。

【００５９】なお、この場合に、非圧縮時には図６の
（ａ）と同様のメッセージ・フォーマット（フィンガー
プリントを含まないフォーマット）を用いる方法もあ
る。

【００６０】なお、ＦＰ圧縮の適用対象外のメッセージ
が存在し得る場合には、上記した識別情報に基づく方法
の他に、圧縮側（送信側）のプロキシがＦＰ圧縮の適用
対象のメッセージ・ヘッダに常にフィンガープリントを
記述する構成の場合には、解凍側（受信側）では、メッ
セージ・ヘッダにフィンガープリントが含まれるか否か
で判断することもできる。

【００６１】ここで、図３５に図８（ａ）のフォーマッ
トのメッセージの具体例を示し、図３６に図８（ｂ）の
フォーマットのメッセージの具体例を示す。

【００６２】図９に、メッセージ・フォーマットのさら
に他の例を示す。（ａ）は非圧縮時のメッセージであ
り、（ｂ）は圧縮時のメッセージである。（ａ）ではメ
ッセージ・ボディーにデータが載せられ、（ｂ）ではメ
ッセージ・ボディーは空（ｎｕｌｌ）である。また、こ
の例では、（ａ），（ｂ）ともにメッセージ・ヘッダに
フィンガープリント（ＦＰ）が記述される。ただし、こ
の例では、ＦＰ圧縮の有無を識別可能とする識別情報は
使用しない。

【００６３】この例では、メッセージ・ボディーが空
（ｎｕｌｌ）か否かによって、ＦＰ圧縮の有無を識別す
ることができる。ただし、ＦＰ圧縮の適用対象外のメッ
セージでメッセージ・ボディーが空（ｎｕｌｌ）のもの
が存在し得る場合には、例えば、メッセージ・ヘッダに
フィンガープリント（ＦＰ）が存在するか否かによっ
て、ＦＰ圧縮の適用対象で圧縮時のメッセージか、ＦＰ
圧縮の適用対象外でメッセージ・ボディーが空（ｎｕｌ
ｌ）のメッセージかを識別する（あるいは、メッセージ
・ヘッダにＦＰ圧縮の適用対象か適用対象外かを示す情
報を設けてもよい）。

【００６４】なお、非圧縮時には図１０に示すようにメ
ッセージにフィンガープリントを記述しないフォーマッ
トを用いる方法もある。この場合には、メッセージ・ヘ
ッダにフィンガープリントが含まれるか否かによって、
ＦＰ圧縮の有無を識別することができる。ただし、ＦＰ
圧縮の適用対象外のメッセージが存在し得る場合には、
例えば、メッセージ・ヘッダにＦＰ圧縮の適用対象か適
用対象外かを示す情報を設ければよい。

【００６５】ここで、図３７に図９（ａ）のフォーマッ
トのメッセージの具体例を示し、図３８に図９（ｂ）の
フォーマットのメッセージの具体例を示す。

【００６６】また、図３９に、図１０のフォーマットの
メッセージの具体例を示す。

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

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

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

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

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

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

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

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

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

【００７６】そして、該フィンガープリントの値とこれ
に対応するデータとの組がフィンガープリント・キャッ
シュ３４に登録されていたならば（ステップＳ５）、Ｆ
Ｐ圧縮処理部３２３にて、受信したリプライメッセージ
を、該フィンガープリントの値を用いてＦＰ圧縮時のフ
ォーマットにして（例えば図８（ｂ）等）、送信部３３
から、クライアント側プロキシ４０へ送信する（ステッ
プＳ６）。このとき、必要に応じて、リプライヘッダ内
のデータ長を表すフィールド（Ｃｏｎｔｅｎｔ−Ｌｅｎ
ｇｔｈ：フィールド）の値を、ＦＰ圧縮時のフォーマッ
トにあわせて設定する。

【００７７】一方、ステップＳ４の検索の結果、該フィ
ンガープリントの値とこれに対応するデータとの組がフ
ィンガープリント・キャッシュ３４に登録されていなか
ったならば（ステップＳ５）、次の２つの作業を行う。 （１）ＦＰ圧縮処理部３２３にて、受信したリプライメ
ッセージを、（必要に応じて該フィンガープリントの値
を用いて）非ＦＰ圧縮時のフォーマットにして（例えば
図８（ａ）等）、送信部３３から、クライアント側プロ
キシ４０へ送信する（ステップＳ７）。 （２）ＦＰキャッシュ管理部３２２にて、該フィンガー
プリントの値と、該リプライデータとを対応付けて（フ
ィンガープリントの値をキーにして）、フィンガープリ
ント・キャッシュ３４に登録する（ステップＳ８）。

【００７８】なお、上記の（１）と（２）は、いずれを
先に行ってもよいし、並行して行ってもよい。

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

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

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

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

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

【００８４】そして、ＦＰ解凍処理部４２３にて、受信
リプライメッセージに対して、フィンガープリント・キ
ャッシュ３４から検索された該フィンガープリントの値
に対応するデータを付加し、プロキシ間で特別の情報を
使用する場合には該情報を削除した後に、これを送信部
４３からクライアント５０へ送信する（ステップＳ１
６）。このとき、必要に応じて、リプライヘッダ内のデ
ータ長を表すフィールド（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔ
ｈ：フィールド）の値を、該フィンガープリントの値に
対応するデータの長さに設定する。

【００８５】一方、ステップＳ１３にて該リプライメッ
セージのリプライデータがＦＰ圧縮されていないものと
判断されたならば（例えば図８（ａ）等の場合）、次の
２つの作業を行う。 （１）ＦＰ解凍処理部４２３にて、プロキシ間で特別の
情報を使用する場合には受信リプライメッセージから該
情報を削除した後に、これを送信部４３からクライアン
ト５０へ送信する（ステップＳ１８）。 （２）ＦＰキャッシュ管理部４２２にて、該リプライデ
ータのフィンガープリントの値を求め（ステップＳ１
７）、該フィンガープリントの値と、該リプライデータ
とを対応付けて（フィンガープリントの値をキーにし
て）、フィンガープリント・キャッシュ３４に登録する
（ステップＳ１９）。

【００８６】なお、上記の（１）と（２）は、いずれを
先に行ってもよいし、並行して行ってもよい。

【００８７】ところで、ステップＳ１４では、メッセー
ジにフィンガープリントが記述されている。しかし、ス
テップＳ１７では、メッセージにフィンガープリントが
記述されている場合に、該メッセージからフィンガープ
リントを得る方法と、メッセージにフィンガープリント
が記述されてない場合に、リプライデータをもとにハッ
シュ関数等によってフィンガープリントの値を計算する
方法とがある。なお、メッセージにフィンガープリント
が記述されている場合であっても、リプライデータをも
とにフィンガープリントの値を計算する方法も可能であ
る。また、ステップＳ１４／ステップＳ１７は、ステッ
プＳ１２とステップＳ１３の間にて行うようにしても構
わないし、ステップＳ１７は、ステップＳ１８とステッ
プＳ１９の間にて行うようにしても構わない。

【００８８】また、ステップＳ１２の判断とステップＳ
１３の判断は、同時に行ってもよい。

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

【００９０】以下では、図１７（登録時すなわち非ＦＰ
圧縮時）および図１８（ＦＰ圧縮時）を参照しながら、
フィンガープリント・キャッシュを利用したデータ転送
についてより具体的に説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１０５】（７）リプライメッセージを受け取ったク
ライアント側プロキシ４０は、リプライデータがフィン
ガープリントで置き換えられていることを検出し、（前
述したように例えばリプライヘッダなどにて）指定され
たフィンガープリントを使ってフィンガープリント・キ
ャッシュ４４から対応するデータを取り出し、これをリ
プライボディに入れる。

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

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

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

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

【０１１０】図１８を参照して説明した動作における
（５）で、サーバ側プロキシ３０において、リプライデ
ータのフィンガープリントを求め、該フィンガープリン
トがフィンガープリント・キャッシュ３４に入っていれ
ば、当該リプライデータと同じデータが該フィンガープ
リントと組になってフィンガープリント・キャッシュ３
４に入っているものとみなして処理している。実用上、
異なるデータから同じフィンガープリントが生成されな
いことを前提にすれば、この方法で十分であるが、非常
に小さな確率で異なるデータのフィンガープリントが偶
々同じ値になってしまった場合に生じるエラーを取り除
くようにする方法もある。この場合には、リプライデー
タから求めたフィンガープリントがフィンガープリント
・キャッシュ３４に入っているときに、該フィンガープ
リントと組になってフィンガープリント・キャッシュ３
４に入っているデータと、当該プライデータとを比較し
て、同じか否かを判断するようにすればよい。このと
き、もしフィンガープリントは同じであるが内容が異な
るデータが登録されていると判断された場合の処理は、
以下に例示するような方法が考えられる。・そのフィン
ガープリントは以降使用しないものとする（そのフィン
ガープリントを与えるデータは以後キャッシュされない
ことになる）。・先に登録されているフィンガープリン
ト／データを優先する（登録中のフィンガープリントと
同じ値のフィンガープリントを与える他のデータは、そ
の登録中はキャッシュされないことになる）。・現在登
録対象となっているフィンガープリント／データを優先
する（登録中のフィンガープリント／データは、同じ値
のフィンガープリントを与える他のデータによって次々
と更新されていくことになる）。

【０１１１】ところで、本実施形態のサーバ側プロキシ
３０あるいはクライアント側プロキシ４０に、後述する
ＵＲＬとフィンガープリントとの対応テーブル（ＵＲＬ
・ＦＰテーブル）を設け、これとフィンガープリント・
キャッシュとを併用することで、プロキシサーバの共有
キャッシュの動作をも行うようにすることができる。こ
の機能は、個々のサーバ側プロキシ３０毎に、また個々
のクライアント側プロキシ４０毎に、設けるか否かを定
めることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１３０】（２）新しいＵＲＬでリクエストが来たと
きに、そのＵＲＬがＵＲＬ・ＦＰテーブル４５に載って
いれば、従来の共有キャッシュと同様に有効期間の判定
を行い、有効と判断できれば、そのＵＲＬに対応するフ
ィンガープリントをＵＲＬ・ＦＰテーブル４５を引いて
求め、それを名前とするデータをフィンガープリント・
キャッシュ４４から取り出してリプライデータとし、さ
らに、ＵＲＬ・ＦＰテーブル４５からＭＩＭＥタイプ等
のリプライヘッダを構成するのに必要な情報を取り出し
てリプライヘッダを作成する。

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

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

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

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

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

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

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

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

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

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

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

【０１４２】この場合の処理手順は、基本的には図２１
の手順と同様である。なお、図２１のＳ３７ではリプラ
イデータを作成してクライアント５０へ転送するが、こ
れに対応する図２５のＳ４７ではＦＰ圧縮時のフォーマ
ット（例えば図８（ｂ）等）でリプライデータを作成し
てクライアント側プロキシ４０へ転送することになる。

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

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

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

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

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

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

【０１４９】また、サーバ側プロキシ３０やクライアン
ト側プロキシ４０は、リプライデータ転送に対するフィ
ンガープリント・キャッシュとは独立にリクエストデー
タ転送に対するフィンガープリント・キャッシュを設け
てもよいが、リプライデータ転送とクエストデータ転送
とで同じフィンガープリント・キャッシュを共用しても
よい。

【０１５０】図２６に、この場合のプロキシ（サーバ側
プロキシ、クライアント側プロキシ）の構成例を示す。

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

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

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

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

【０１５５】そして、該フィンガープリントの値とこれ
に対応するデータとの組がフィンガープリント・キャッ
シュ４４に登録されていたならば（ステップＳ５５）、
ＦＰ圧縮・解凍処理部４２５にて、受信したリクエスト
メッセージを、該フィンガープリントの値を用いてＦＰ
圧縮時のフォーマットにして（例えば図８（ｂ）等）、
送信部４３から、サーバ側プロキシ３０へ送信する（ス
テップＳ５６）。

【０１５６】一方、ステップＳ５４の検索の結果、該フ
ィンガープリントの値とこれに対応するデータとの組が
フィンガープリント・キャッシュ４４に登録されていな
かったならば（ステップＳ５５）、次の２つの作業を行
う。 （１）ＦＰ圧縮・解凍処理部４２５にて、受信したリク
エストメッセージを、（必要に応じて該フィンガープリ
ントの値を用いて）非ＦＰ圧縮時のフォーマットにして
（例えば図８（ａ）等）、送信部４３から、サーバ側プ
ロキシ３０へ送信する（ステップＳ５７）。 （２）ＦＰキャッシュ管理部４２２にて、該フィンガー
プリントの値と、該リクエストデータとを対応付けて
（フィンガープリントの値をキーにして）、フィンガー
プリント・キャッシュ４４に登録する（ステップＳ５
８）。

【０１５７】なお、上記の（１）と（２）は、いずれを
先に行ってもよいし、並行して行ってもよい。

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

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

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

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

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

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

【０１６４】一方、ステップＳ６３にて該リクエストメ
ッセージのリクエストデータがＦＰ圧縮されていないも
のと判断されたならば（例えば図８（ａ）等の場合）、
次の２つの作業を行う。 （１）ＦＰ圧縮・解凍処理部３２５にて、プロキシ間で
特別の情報を使用する場合には受信リプライメッセージ
から該情報を削除した後に、これを送信部３３からサー
バ２０へ送信する（ステップＳ６８）。 （２）ＦＰキャッシュ管理部３２２にて、該リクエスト
データのフィンガープリントの値を求め（ステップＳ６
７）、該フィンガープリントの値と、該リクエストデー
タとを対応付けて（フィンガープリントの値をキーにし
て）、フィンガープリント・キャッシュ３４に登録する
（ステップＳ６９）。

【０１６５】なお、上記の（１）と（２）は、いずれを
先に行ってもよいし、並行して行ってもよい。

【０１６６】前述と同様、ステップＳ６７では、メッセ
ージにフィンガープリントが記述されている場合に、該
メッセージからフィンガープリントを得る方法と、メッ
セージにフィンガープリントが記述されてない場合に、
リクエストデータをもとにハッシュ関数等によってフィ
ンガープリントの値を計算する方法とがある。なお、メ
ッセージにフィンガープリントが記述されている場合で
あっても、リクエストデータをもとにフィンガープリン
トの値を計算する方法も可能である。また、ステップＳ
６４／ステップＳ６７は、ステップＳ６２とステップＳ
６３の間にて行うようにしても構わないし、ステップＳ
６７は、ステップＳ６８とステップＳ６９の間にて行う
ようにしても構わない。

【０１６７】また、ステップＳ６２の判断とステップＳ
６３の判断は、同時に行ってもよい。

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

【０１６９】もちろん、この場合に、前述したクライア
ントが送信したリクエストメッセージが指定するＵＲＬ
に対応するリプライデータに対する共用キャッシュ機能
に関する構成をサーバ側プロキシやクライアント側プロ
キシに対して併せて実施することも可能である。この場
合のプロキシ（サーバ側プロキシ、クライアント側プロ
キシ）の構成例を図２９に示す。この場合のサーバ側プ
ロキシやクライアント側プロキシの動作は既に説明した
ものと同様である。

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

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

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

【０１７３】なお、以上の各機能は、ソフトウェアとし
て実現可能である。また、本実施形態は、コンピュータ
に所定の手段を実行させるための（あるいはコンピュー
タを所定の手段として機能させるための、あるいはコン
ピュータに所定の機能を実現させるための）プログラム
として実施することもでき、該プログラムを記録したコ
ンピュータ読取り可能な記録媒体として実施することも
できる。

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

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

【０１７６】

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

【図面の簡単な説明】

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

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

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

【図４】同実施形態で使用するフィンガープリントにつ
いて説明するための図

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図３２】図６（ａ）のフォーマットのメッセージの具
体例を示す図

【図３３】図６（ｂ）のフォーマットのメッセージの具
体例を示す図

【図３４】図７のフォーマットのメッセージの具体例を
示す図

【図３５】図８（ａ）のフォーマットのメッセージの具
体例を示す図

【図３６】図８（ｂ）のフォーマットのメッセージの具
体例を示す図

【図３７】図９（ａ）のフォーマットのメッセージの具
体例を示す図

【図３８】図９（ｂ）のフォーマットのメッセージの具
体例を示す図

【図３９】図１０のフォーマットのメッセージの具体例
を示す図

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 關 俊文 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 吉井 謙一郎 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 佐藤 英昭 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 宮澤 隆幸 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 木村 康浩 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 外山 春彦 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B082 EA09 GA01 GA20 HA02 HA05 HA08

Claims (24)

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