Nothing Special   »   [go: up one dir, main page]

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

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

Info

Publication number
JP2003288261A
JP2003288261A JP2002089949A JP2002089949A JP2003288261A JP 2003288261 A JP2003288261 A JP 2003288261A JP 2002089949 A JP2002089949 A JP 2002089949A JP 2002089949 A JP2002089949 A JP 2002089949A JP 2003288261 A JP2003288261 A JP 2003288261A
Authority
JP
Japan
Prior art keywords
response
data
communication device
request
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2002089949A
Other languages
English (en)
Other versions
JP3984086B2 (ja
Inventor
Yasuhiro Kimura
康浩 木村
Yuichi Koba
雄一 木場
Kenichiro Yoshii
謙一郎 吉井
Tokuji Shono
篤司 庄野
Hideaki Sato
英昭 佐藤
Toshibumi Seki
俊文 關
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2002089949A priority Critical patent/JP3984086B2/ja
Priority to US10/396,396 priority patent/US7069297B2/en
Publication of JP2003288261A publication Critical patent/JP2003288261A/ja
Application granted granted Critical
Publication of JP3984086B2 publication Critical patent/JP3984086B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Communication Control (AREA)

Abstract

(57)【要約】 【課題】 通信装置間を接続するネットワークの負荷を
より軽減することができるデータ転送装置を提供するこ
と。 【解決手段】 キャッシュ・サーバ２は、Ｗｅｂサーバ
３からＷｅｂブラウザ３に転送すべきレスポンスを受信
した際に、該レスポンスを転送する代わりに、該レスポ
ンスに対するフィンガープリントを生成し、該フィンガ
ープリントとＷｅｂサーバ３からのレスポンスに含まれ
るレスポンスデータとを対応付けて保存し、該フィンガ
ープリントと自身のホスト名とを含むＵＲＬへのリダイ
レクトレスポンスを生成してＷｅｂブラウザ５に送信す
る。その後、Ｗｅｂブラウザ５から該フィンガープリン
トと自身のホスト名とを含むＵＲＬへのリクエストメッ
セージを受信したならば、該フィンガープリントに対応
付けて保存されているレスポンスデータを含むレスポン
スを生成して、該Ｗｅｂブラウザ５に送信する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、他の装置のために
データの転送を行うデータ転送装置及びデータ転送方法
に関する。
【０００２】
【従来の技術】ネットワークを介して様々なサービスを
提供するサーバと、所望のサービスをサーバに対して要
求するクライアントとから構成される、クライアント・
サーバ型の情報システムが広く利用されている。特に、
インターネット上でＨＴＴＰプロトコルを使って通信す
るＷｅｂサーバとクライアントとからなるＷｏｒｌｄＷ
ｉｄｅ Ｗｅｂシステム（あるいは単にＷｅｂとも呼ば
れる）は、大変広く利用されているクライアント・サー
バ型の情報システムである。通常、サーバ上ではサーバ
プログラムが動作し、クライアント上ではブラウザなど
の所定のツール（プログラム）が動作する。インターネ
ット上で提供されるサービスの内容も多岐に渡ってお
り、ネットワーク経由で文字、静止画像、動画像、音声
等の情報（例えば、ホームページ、電子メール、デジタ
ルコンテンツなど）や、プログラムなどを提供、配信あ
るいは転送などするサービス、また商品を販売するため
の電子店舗サービス、座席や部屋等の予約サービス、種
々の契約の仲介サービスなど、種々のサービスが既に存
在し、また次々と新たな形態のサービスが出現してい
る。
【０００３】ところで、Ｗｅｂのようなクライアント・
サーバ型の情報システムにおいては、提供されるサービ
スがどのような形態のものであろうと、基本的にはクラ
イアント・サーバ間でデータ転送が行われることによっ
てサービスが提供される。したがって、クライアントと
サーバとの間で通信に用いるネットワークの容量（バン
ド幅）が、システム全体のボトルネックになりやすい。
そこで、通常、ネットワークの負荷を軽減させるために
キャッシュ技術が用いられる。
【０００４】Ｗｅｂシステムの場合、クライアント上で
動作するブラウザ等はキャッシュ機構を使用するものが
多く、最近アクセスしたデータをキャッシュしている。
ＷｅｂではＵＲＬと呼ばれる名前で情報やサービスを指
定してアクセスがなされるので、クライアント上のキャ
ッシュは、過去にＷｅｂサーバに要求した情報やサービ
スの結果として返されるデータのうちでキャッシュ可能
なものを、そのＵＲＬと対応させてキャッシュに記録し
ている。この場合、キャッシュ内にあるものと同じＵＲ
Ｌの情報やサービスのリクエストがあった際に、そのキ
ャッシュ内の応答データが古くなっていないと判断でき
るならば、そのデータを返すことで、Ｗｅｂサーバとの
間の通信を無くすことができる。
【０００５】企業のオフィス内のＬＡＮあるいは研究機
関におけるＬＡＮあるいは家庭内のＬＡＮなどで複数の
ユーザがいる場合、該ＬＡＮとインターネットとの間に
プロキシサーバを置き、プロキシサーバにキャッシュ機
構を設けるようにすることも多い。クライアント内のキ
ャッシュ（例えば、ブラウザのキャッシュ）は、当該ク
ライアント・ユーザに専用のキャッシュとして動作する
が、ＬＡＮ上のプロキシサーバのキャッシュは、複数の
クライアント・ユーザに共有のキャッシュとして動作す
る。そのため、後者では、過去に他人（他クライアン
ト）がアクセスしたＵＲＬに対してアクセスする際にも
キャッシュが効く。
【０００６】さて、Ｗｅｂにおいて、クライアントとサ
ーバとの間は、ＨＴＴＰと呼ぶプロトコルで通信が行わ
れる。ＨＴＴＰプロトコルは、クライアントからサーバ
へ送る「リクエストメッセージ」と、それに答えてサー
バからクライアントへ応答を返す「レスポンスメッセー
ジ」とが組になっている。
【０００７】リクエストメッセージは、「リクエストヘ
ッダ」と「リクエストボディ」からなる。リクエストヘ
ッダには、アクセスしたい情報やサービスを指定するＵ
ＲＬやアクセスの種類を示すメソッド名、その他アクセ
スに必要な各種の情報が入る。リクエストボディには、
サーバに送るデータを入れる。リクエストボディに入っ
ているデータを「リクエストデータ」とも呼ぶ。
【０００８】リクエストメッセージのメソッドとして
は、サーバ上の情報を読み出す「ＧＥＴメソッド」、ユ
ーザの持つデータをサーバに書き込む「ＰＵＴメソッ
ド」、リクエストの応じて処理した結果を送り返しても
らう「ＰＯＳＴメソッド」が、情報やサービスのアクセ
スに用いられる主要なものである。その他、ＤＥＬＥＴ
Ｅなどのメソッドが定義されている。
【０００９】多くの場合、ＧＥＴメソッドのリクエスト
メッセージのリクエストボディ、ＰＵＴメソッドのレス
ポンスメッセージのレスポンスボディは空である。ＰＯ
ＳＴメソッドのリクエストメッセージのリクエストボデ
ィには、必要に応じてサーバ側での処理に用いる情報が
入り、ＰＯＳＴメソッドのレスポンスメッセージのレス
ポンスボディには、その処理の結果のデータが入る。
【００１０】ＧＥＴメソッドでサーバから読み出すデー
タは、読み出す毎にサーバ側で生成する「動的データ」
と、既にサーバ側で記憶しているデータをそのまま送り
返す「静的データ」に分けることができる。これらのう
ち、動的データについては、同じＵＲＬでも読み出す度
に内容が異なる可能性があるので、多くの場合、サーバ
はキャッシュ不可の指定をそのレスポンスメッセージの
ヘッダに入れて送り返す。したがって、Ｗｅｂのデータ
でキャッシュの対象になるのは、静的データの部分であ
る。この静的データは、不特定多数のユーザが参照して
構わない「共有データ」と、ユーザ認証することで特定
のユーザだけがアクセスできるようにアクセス制御を行
う「プライベートデータ」に分けることができる。前者
の共有データは、どのようなキャッシュでもキャッシュ
可能である。しかしながら、後者のプライベートデータ
は、プロキシサーバなどの共有キャッシュでは、キャッ
シュ不可である（プライベートデータは必ずサーバでユ
ーザを認証して送り返す必要があるので）。ただし、ブ
ラウザなどの個人専用のキャッシュの場合には、プライ
ベートデータでもキャッシュは可能である。
【００１１】ＰＯＳＴメソッドは、サーバ側で処理をし
た結果を返すので、一般的にサーバはキャッシュ不可の
指定をレスポンスメッセージのヘッダに入れて結果を送
り返す。そのため、通常はキャッシュの対象にはならな
い。
【００１２】ＰＵＴメソッドは、データをサーバに送る
ものなので、キャッシュは何も処理をしない。
【００１３】一方、レスポンスメッセージは、「レスポ
ンスヘッダ」と「レスポンスボディ」からなる。レスポ
ンスヘッダは、処理結果を表すステータスコードと、そ
れに付随する情報を伝えるための各種へッダから構成さ
れており、レスポンスボディには、要求された情報や要
求されたサービスの処理結果などのデータが入る。レス
ポンスボディに入っているデータを「レスポンスデー
タ」とも呼ぶ。
【００１４】レスポンスへッダのステータスコードは、
三桁の数字によって構成される。ステータスコードの意
味は、数値ごとに異なるが、最初の一桁の数字の値によ
って大きく５つにクラス分けができる。
【００１５】最初の一桁が１のクラスは、リクエストに
対応する処理がまだ続いている状況で用いられるクラス
である。例えば、ステータスコード“１００”は、まさ
に処理が継続中であることを表し、ブラウザは、このス
テータスコードを受け取った後、更なるレスポンスがサ
ーバから送られてくるのを待つことになる。
【００１６】最初の一桁が２のクラスは、一般的に成功
を表すクラスである。例えば、ＧＥＴメソッドで指定さ
れたＵＲＬにあるデータへのアクセスが受理された場
合、サーバは、ステータスコード“２００”を含むレス
ポンスへッダとＵＲＬに対応するデータとを含んだレス
ポンスボディからなるレスポンスメッセージを、クライ
アントに送信する。また、ＰＵＴで指定されたＵＲＬに
データを保存するのに成功した場合には、ステータスコ
ード“２０１”を含むレスポンスへッダが、クライアン
トに送信される。
【００１７】最初の一桁が３のクラスは、リダイレクシ
ョンを表すクラスである。クライアントのリクエストに
対してサーバがこのクラスに属するステータスコードを
返した場合、それは、「このリクエストを送信した目的
を果たすためにはクライアント側で更に何らかのアクシ
ョンが必要である」、ということを示している。例え
ば、あるサーバマシンのトラブル等によって通常そのサ
ーバ上で提供されているサービスを一時的に提供できな
い場合に、他のサーバで代替的にサービスを提供すると
いうことはよく行われることであるが、この時トラブル
中のサーバはクライアントからのリクエストに対して、
「要求されたものは一時的に別の場所で提供されてい
る」ことを示すステータスコード“３０２”と、代替的
にサービスを提供している場所のＵＲＬを含むＬｏｃａ
ｔｉｏｎへッダとからなるレスポンスを返すことができ
る。クライアントは、ステータスコード“３０２”を含
むレスポンスを受け取ると、前述のＬｏｃａｔｉｏｎへ
ッダに書かれているＵＲＬを参照し、そのＵＲＬに対応
するサーバに対して再度リクエストを送信することによ
って、所望のサービスの提供を受けることができる。ま
た、前述のようにＷｅｂブラウザにはキャッシュ機能を
持つものが多くあるが、このようなキャッシュ機能を持
つＷｅｂブラウザが既にデータをキャッシュしているＵ
ＲＬに対して再度ＧＥＴリクエストを送信する場合、リ
クエストの中に前回このＵＲＬのデータを受け取った時
刻を付随情報として付加される。これは、サーバに対し
て、「ＵＲＬに相当するデータがこの時刻より後に更新
されている場合にのみ、データを送信して欲しい」、と
要求していることを意味している。このような方法は一
般的にリバリデーションと呼ばれるが、このブラウザか
らのリバリデーション要求に対して、ＵＲＬに相当する
データが指定された時刻より後に更新されてない場合、
サーバは、ブラウザに対してステータスコード“３０
４”を返すことができる。これは、「ローカルコピーを
使え」、という意味のステータスコードで、このレスポ
ンスを受け取ったブラウザは、キャッシュしておいたデ
ータを再度取出し、それをＧＥＴリクエストの結果得ら
れたデータとして利用するのである。
【００１８】最初の一桁が４のクラスは、クライアント
側が原因で何らかのエラーが発生したことを表すクラス
である。例えば、バグのあるクライアントプログラムが
ＨＴＴＰの規約に従わないリクエストを送信した場合、
サーバは、ステータスコード“４００”を返して、リク
エストがＨＴＴＰの規約からはずれていることを通知す
る。また、ユーザのミスタイプなどにより、存在しない
ＵＲＬに対するリクエストが送信された場合、サーバ
は、ステータスコード“４０４”を返して、指定された
ＵＲＬが存在しないことを通知する。
【００１９】最初の一桁が５のクラスは、サーバ側が原
因で何らかのエラーが発生したことを表すクラスであ
る。例えば、サーバマシンのトラブル等によってそのマ
シンがサービスを一時的に提供できない状況に陥り、か
つ代替的にサービスを提供する他のマシンを用意するこ
とが出来ないような場合、サーバは、クライアントから
のリクエストに対してステータスコード“５０３”を返
して、サービスが一時的に提供できない状況であること
を通知する。
【００２０】
【発明が解決しようとする課題】従来のＷｅｂのキャッ
シュは、静的コンテンツをキャッシュの対象にしてい
る。かつては、Ｗｅｂで公開される情報やサービスに
は、情報の更新頻度がそれほど高くなく、不特定多数の
人に公開されているものが多かったため、静的コンテン
ツの割合は非常に高く、従来のキャッシュ技術でもネッ
トワークの負荷の軽減に有効であった。
【００２１】しかしながら、ＷｅｂベースのＡＳＰ（Ａ
ｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄ
ｅｒ）のように、ユーザがＷＷｅｂブラウザを使って、
ネットワーク経由でサーバ上の情報やサービスにアクセ
スするシステムが普及するにつれて、下記のように従来
のキャッシュ技術では対応できないデータが増加してい
る。 ・ユーザの認証を行い、アクセスできるユーザを制限し
ているので、プライベートデータが多い。 ・バックエンドのデータベースを参照して生成する動的
データが多い。 ・帳票処理や検索などＰＯＳＴメソッドを使う場合が多
い。 ・グループ内の情報共有のためにＰＵＴメソッドを使う
場合が多い。
【００２２】この結果、キャッシュ技術のみではネット
ワークの負荷を軽減する手法として有効に機能しなくな
ってきている。
【００２３】本発明は、上記事情を考慮してなされたも
ので、第１の通信装置から第２の通信装置へ要求を行
い、この要求に応じて第２の通信装置から第１の通信装
置へ所定のデータを転送する場合において、第１の通信
装置とデータ転送装置との間を接続するネットワークの
負荷をより軽減することができるデータ転送装置及びデ
ータ転送方法を提供することを目的とする。
【００２４】
【課題を解決するための手段】本発明は、第１の通信装
置から送信されたリクエストメッセージを受信する第１
の受信手段と、受信されたリクエストメッセージが第２
の通信装置へ転送すべきものである場合に、該リクエス
トメッセージを前記第２の通信装置へ送信する第１の送
信手段と、前記第２の通信装置から返送された前記レス
ポンスデータを含む前記レスポンスメッセージを受信す
る第２の受信手段と、受信された前記レスポンスメッセ
ージに含まれる前記レスポンスデータに割り当てるべき
識別子を、該レスポンスデータの内容に基づいて生成す
る手段と、少なくとも前記レスポンスデータと前記識別
子とを対応付けて保持する保持手段と、前記第２の通信
装置から前記レスポンスデータを含む前記レスポンスメ
ッセージを受信した場合に、前記第１の通信装置に対し
て、該レスポンスデータを含むレスポンスメッセージを
送信する代わりに、前記識別子を含む所定のＵＲＬへの
リダイレクトレスポンスメッセージを送信する第２の送
信手段とを備え、前記第２の送信手段は、前記第１の受
信手段を介して前記第１の通信装置からの前記識別子を
含む所定のＵＲＬへのリクエストメッセージが受信され
た場合には、該ＵＲＬに含まれる該識別子に対応して前
記保持手段に保持されている前記レスポンスデータを含
むレスポンスメッセージを、前記第１の通信装置に送信
することを特徴とする。
【００２５】また、本発明は、所定のネットワークを介
して第１の通信装置から送信されたリクエストメッセー
ジを受信して第２の通信装置に転送し、該リクエストメ
ッセージを受け付けた該第２の通信装置から返送された
レスポンスデータを含むレスポンスメッセージを受信し
て第１の通信装置に転送するデータ転送装置におけるデ
ータ転送方法であって、前記第１の通信装置から送信さ
れたリクエストメッセージを受信し、受信されたリクエ
ストメッセージを前記第２の通信装置へ送信し、前記第
２の通信装置から返送された前記レスポンスデータを含
む前記レスポンスメッセージを受信し、受信された前記
レスポンスメッセージに含まれる前記レスポンスデータ
に割り当てるべき識別子を、該レスポンスデータの内容
に基づいて生成し、少なくとも前記レスポンスデータと
前記識別子とを対応付けて保持手段に保持し、前記第２
の通信装置から前記レスポンスデータを含む前記レスポ
ンスメッセージを受信した場合に、前記第１の通信装置
に対して、該レスポンスデータを含むレスポンスメッセ
ージを送信する代わりに、前記識別子を含む所定のＵＲ
Ｌへのリダイレクトレスポンスメッセージを送信し、前
記第１の通信装置から送信された前記識別子を含む所定
のＵＲＬへのリクエストメッセージを受信し、受信され
た前記リクエストメッセージの前記ＵＲＬに含まれる前
記識別子に対応して前記保持手段に保持されている前記
レスポンスデータを含むレスポンスメッセージを、前記
第１の通信装置に送信することを特徴とする。
【００２６】また、本発明は、所定のネットワークを介
して第１の通信装置から送信されたリクエストメッセー
ジを受信して第２の通信装置に転送し、該リクエストメ
ッセージを受け付けた該第２の通信装置から返送された
レスポンスデータを含むレスポンスメッセージを受信し
て第１の通信装置に転送するデータ転送装置としてコン
ピュータを機能させるためのプログラムであって、前記
第１の通信装置から送信されたリクエストメッセージを
受信する機能と、受信されたリクエストメッセージが前
記第２の通信装置へ転送すべきものである場合に、該リ
クエストメッセージを前記第２の通信装置へ送信する機
能と、前記第２の通信装置から返送された前記レスポン
スデータを含む前記レスポンスメッセージを受信する機
能と、受信された前記レスポンスメッセージに含まれる
前記レスポンスデータに割り当てるべき識別子を、該レ
スポンスデータの内容に基づいて生成する機能と、少な
くとも前記レスポンスデータと前記識別子とを対応付け
て保持する保持機能と、前記第２の通信装置から前記レ
スポンスデータを含む前記レスポンスメッセージを受信
した場合には、前記第１の通信装置に対して、該レスポ
ンスデータを含むレスポンスメッセージを送信する代わ
りに、前記識別子を含む所定のＵＲＬへのリダイレクト
レスポンスメッセージを送信し、前記第１の通信装置か
らの前記識別子を含む所定のＵＲＬへのリクエストメッ
セージが受信された場合には、該ＵＲＬに含まれる該識
別子に対応して前記保持機能に保持されている前記レス
ポンスデータを含むレスポンスメッセージを、前記第１
の通信装置に送信する機能とをコンピュータに実現させ
るためのプログラムである。
【００２７】なお、装置に係る本発明は方法に係る発明
としても成立し、方法に係る本発明は装置に係る発明と
しても成立する。また、装置または方法に係る本発明
は、コンピュータに当該発明に相当する手順を実行させ
るための（あるいはコンピュータを当該発明に相当する
手段として機能させるための、あるいはコンピュータに
当該発明に相当する機能を実現させるための）プログラ
ムとしても成立し、該プログラムを記録したコンピュー
タ読取り可能な記録媒体としても成立する。
【００２８】本発明によれば、第２の通信装置からレス
ポンスデータを含むレスポンスメッセージを受信した場
合に、該レスポンスメッセージに含まれる該レスポンス
データに割り当てるべき識別子を、該レスポンスデータ
の内容に基づいて生成し、少なくとも該レスポンスデー
タと該識別子とを対応付けて保持し、第１の通信装置に
対して、該レスポンスデータを含むレスポンスメッセー
ジを送信する代わりに、該識別子を含む所定のＵＲＬへ
のリダイレクトレスポンスメッセージを送信し、該第１
の通信装置からの該識別子を含む所定のＵＲＬへのリク
エストメッセージが受信された場合には、該ＵＲＬに含
まれる該識別子に対応して保持されている該レスポンス
データを含むレスポンスメッセージを、該第１の通信装
置に送信する。該第１の通信装置が内蔵のキャッシュ
（例えば、ブラウザキャッシュ）を持っていれば、該第
１の通信装置へ該識別子を含む所定のＵＲＬへのリダイ
レクトレスポンスメッセージを送信し、そして、該第１
の通信装置からの該識別子を含む所定のＵＲＬへのリク
エストメッセージが受信された場合に、該ＵＲＬに含ま
れる該識別子に対応して保持されている該レスポンスデ
ータを含むレスポンスメッセージを、該第１の通信装置
に送信すると、該レスポンスについては該内蔵のキャッ
シュに保持されるので、以降は、同一のレスポンスデー
タについては、データ中継装置から該第１の通信装置へ
該識別子を含む所定のＵＲＬへのリダイレクトレスポン
スメッセージを送信するだけで済むことになる。これに
よって、データ中継装置から第１の通信装置へのレスポ
ンスデータのデータ転送量を削減することができる。
【００２９】
【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。
【００３０】図１に、本発明の一実施形態に係るキャッ
シュ・サーバ（データ転送装置）を適用するコンピュー
タ・ネットワーク・システムの構成例を示す。
【００３１】この構成例では、企業のオフィス１００内
にＬＡＮ４１が敷設されており、所定のサービスを提供
するＷｅｂサーバ３がＬＡＮ４１に接続されている。こ
のＬＡＮ４１にはモデム４２が接続されており、電話な
どの公衆回線４３を利用してオフィス１００の外部から
このＬＡＮ４１に接続出来るようになっている。ユーザ
はモデム４４を利用して外部から公衆回線４３経由でＬ
ＡＮ１００に接続することができ、このモデム４４とＷ
ｅｂブラウザ５を繋ぐことによって公衆回線４３経由で
オフィス１００内のＷｅｂサーバ３にアクセスできる。
【００３２】なお、ＷＥＢブラウザ５は、ユーザが使用
する携帯型ＰＣ（図示せず）あるいは情報処理機能を有
する携帯電話端末（図示せず）等の装置（以下、それら
を総称してユーザ端末と呼ぶ）上で動作する。モデム４
４は、携帯型ＰＣ等のようなユーザ端末に外付けする場
合、携帯電話端末等のようなユーザ端末に内蔵される場
合など、種々の形態がある。また、ＷＥＢブラウザ５
は、汎用のものであっても、特定のサービスを利用する
ための専用のものであっても構わない。
【００３３】ここで、ユーザは、Ｗｅｂサーバ３のサー
ビスを利用するために、Ｗｅｂブラウザ５を使用する。
すなわち、ユーザがＷｅｂブラウザ５を操作すると、Ｗ
ＥＢブラウザ５からＷｅｂサーバ３へリクエストメッセ
ージ（以下、リクエスト）が転送され、Ｗｅｂサーバ３
からＷＥＢブラウザ５へレスポンスメッセージ（以下、
レスポンス）が転送され、ＷＥＢブラウザ５にて受信し
たレスポンスのデータについて表示やその他の処理が行
われ、またはこのような一連の手順が適宜繰り返される
ことになる。
【００３４】しかして、その際、このような利用形態に
おいて、従来の技術では、ユーザ端末に接続又は内蔵さ
れたモデム４４とオフィス１００内のモデム４２とを接
続する公衆回線４３の通信速度は、オフィス１００内の
ＬＡＮ４１の通信速度よりも遅いため、公衆回線４３が
性能上のボトルネックとなって通信遅延が発生し、ユー
ザがＷｅｂブラウザ５を使ってＷｅｂサーバ３により提
供されるデータやサービスにアクセスする際に、レスポ
ンスやスループットの低下するという問題が発生する。
【００３５】そこで、本実施形態では、図２に示すよう
に、オフィス１００内のＬＡＮ４１とモデム４２との間
にキャッシュ・サーバ１を設置し、該キャッシュ・サー
バ１によって、Ｗｅｂサーバ３と、キャッシュ・サーバ
１と、ユーザ端末上のＷｅｂブラウザ５（以下、Ｗｅｂ
ブラウザ５と略す）の三者の間にて後述するデータ転送
方式を実現させ、これによって通信データ量を削減さ
せ、公衆回線４３のボトルネックを解消させるようにす
る。
【００３６】なお、本実施形態のキャッシュ・サーバ１
の設置方法としては、図２のようにオフィス１００側の
モデム４２とＬＡＮ４１との間に配置する他にも、種々
のバリエーションが可能であり、例えば、図３のように
ＬＡＮ４１に直接接続する形で配置する方法、ＬＡＮ４
１上に存在する所定の機能を有する他のノード（Ｗｅｂ
サーバ３でもよい）に搭載する方法なども可能である。
【００３７】本実施形態のキャッシュ・サーバ１、Ｗｅ
ｂサーバ３、Ｗｅｂブラウザ５は、いずれも計算機上で
ソフトウェア（キャッシュ・プログラム、サーバ・プロ
グラム、Ｗｅｂブラウザ・プログラム）を動作させる形
で実現することができる。この場合に、必要に応じて計
算機所望の機能を有するＯＳやドライバソフト、パケッ
ト通信用ソフト、暗号ソフト等といったソフトウェア、
あるいは通信インタフェース装置や外部記憶装置や入出
力装置等といったハードウェアが搭載あるいは接続され
る。また、この場合に、ユーザあるいは管理者からの情
報の入力やユーザへの情報の呈示等のために、グラフィ
カル・ユーザ・インタフェース（ＧＵＩ）を用いると好
ましい。もちろん、キャッシュ・サーバ１、Ｗｅｂサー
バ３、Ｗｅｂブラウザ５は、いずれもその全部または一
部の機能をチップ化して所定の装置に組み込むことも可
能である。また、Ｗｅｂブラウザ５やＷｅｂサーバ３
は、従来と同様のもので構わない。
【００３８】本実施形態では、Ｗｅｂブラウザ５、キャ
ッシュ・サーバ１、Ｗｅｂサーバ３は、ＨＴＴＰの最新
バージョンであるＨＴＴＰ１．１に従った通信を行う場
合を例にとって説明する。
【００３９】なお、本実施形態では、Ｗｅｂブラウザ５
は、キャッシュ機構（以下、ブラウザキャッシュと呼
ぶ）を持つものとする。すなわち、Ｗｅｂサーバ３に要
求した情報やサービスの結果として返されるデータのう
ちでキャッシュ可能なものを、そのＵＲＬと対応させて
ブラウザキャッシュにキャッシュしておき、その後ユー
ザが同じＵＲＬの情報やサービスにアクセスしようとし
た際に、ブラウザキャッシュ内の応答データが古くなっ
ていないと判断できるならば、そのデータを使うものと
する。
【００４０】ここで、本実施形態では、キャッシュ・サ
ーバ１がＷｅｂサーバ３から受信したレスポンスデータ
に対してその内容を識別する識別子を割り当てる。ここ
では、そのような識別子として、フィンガープリント
（ＦＰ）を用いる場合を例にとって説明する。
【００４１】図４に例示するように、あるデータ（図４
の例ではコンテンツ）に対応するフィンガープリントの
値は、そのデータの内容に、あらかじめ決められた計算
方法（図４の例ではハッシュ関数）を適用することによ
って、生成される。フィンガープリントの値は、もとの
データに比べて、短い数値である。この数値は、可変長
でもよいが、処理の容易さの観点では、固定長の数値の
方が扱いやすい。
【００４２】フィンガープリントを計算する方法として
は、良く知られているＭＤ−５やＳＨＡ−１などのハッ
シュ関数を用いることができる。これらのハッシュ関数
は、データに対する電子署名などに使われており、任意
のデータが与えられると、ＭＤ−５の場合は１２８ビッ
トの数値に、ＳＨＡ−１の場合は１６０ビットの数値
に、変換することができる。これらのハッシュ関数の特
徴は、２つのデータＸ１，Ｘ２が与えられ、データＸ１
とデータＸ２とが同じであれば、データＸ１に対して計
算したハッシュ値とデータＸ２に対して計算したハッシ
ュ値とは等しくなるが、異なる２つのデータＡ，Ｂが与
えられた場合には、データＡに対して計算したハッシュ
値とデータＢに対して計算したハッシュ値とは、非常に
高い確率で異なるものになることである（原理上は、異
なる２つのデータＡ，Ｂに対してそれぞれ計算したハッ
シュ値が同じになる場合があるが、その確率は実用上無
視できるくらいに小さい）。
【００４３】本実施形態において、概略的には、キャッ
シュ・サーバ１（の後述するデータ管理部）は、まず、
図５に示すように、Ｗｅｂブラウザ５へ転送すべきレス
ポンスのボディに入っているデータ本体（図中の６１）
（または、該データを含むレスポンス全体）と、該デー
タから計算して求めたフィンガープリントの値（図中の
６２）とを対応付けて、キャッシュ情報（図中の６０）
として、記録・管理する。そして、キャッシュ・サーバ
１は、従来ならば（キャッシュ・サーバ１がなければ）
Ｗｅｂサーバ３側からＷｅｂブラウザ５側へデータ本体
が転送されることになる場合であっても、その代わり
に、まずは、対応するフィンガープリントと自身のホス
ト名とを含むリダイレクトレスポンスメッセージ（以
下、リダイレクトレスポンス）を作成してＷｅｂブラウ
ザ５へ転送する。ここで、該リダイレクトレスポンスを
受信したＷｅｂブラウザ５のブラウザキャッシュに該当
するデータがあれば、該ブラウザキャッシュ内のデータ
が利用可能であるので、キャッシュ・サーバ１からＷｅ
ｂブラウザ５へは、データ本体を転送せずに（特に、図
２の場合には、ＬＡＮ４１よりも通信速度の遅い公衆回
線４３を介してデータ本体を転送せずに）、済む。そし
て、あるＷｅｂページへの最初のアクセス時など、該リ
ダイレクトレスポンスを受信したＷｅｂブラウザ５のブ
ラウザキャッシュに該当するデータがない場合にだけ、
キャッシュ・サーバ１からＷｅｂブラウザ５へ該当する
データ本体を転送すればよい。
【００４４】以下、本実施形態についてさらに詳しく説
明する。
【００４５】図６に、本実施形態に係るキャッシュ・サ
ーバ１の構成例を示す。
【００４６】この構成例では、キャッシュ・サーバ１
は、リクエスト受信部１１、リクエスト保存部１２、リ
クエスト判別部１３、リクエスト送信部１４、レスポン
ス受信部１５、ＦＰ生成部１６、データ保存部１７、デ
ータ取出部１８、データ管理部１９、レスポンス生成部
２０、レスポンス送信部２１とを備えている。
【００４７】これらキャッシュ・サーバ１の各構成部分
の概要は、以下の通りである。
【００４８】リクエスト受信部１１は、Ｗｅｂブラウザ
５からのリクエストを受信する。
【００４９】リクエスト保存部１２は、リクエスト受信
部１１が受信したリクエストを保存する。
【００５０】リクエスト判別部１３は、リクエスト受信
部１１から受け取ったリクエストに含まれるＵＲＬを参
照し、そのリクエストをＷｅｂサーバ３に転送すべき
か、あるいはリクエストを転送せずにレスポンスをキャ
ッシュ・サーバ１内部で生成してＷｅｂブラウザ５に送
信すべきかを判断する。そして、転送すべきと判断した
ときは、リクエスト送信部１４にリクエストを送信すべ
きことを指令し、そうでないと判断したときは、データ
取出部１８に保存されているレスポンスの取り出しを指
令するとともに、取出されたレスポンス（のボディに入
っているレスポンスデータ）をもとにしてデータＷｅｂ
ブラウザ５へ送信するレスポンスを生成すべきことを、
レスポンス生成部２０に指令する。
【００５１】リクエスト送信部１４は、リクエスト判別
部１３がリクエストをＷｅｂサーバ３に転送すべきと判
断した際に、リクエストをＷｅｂサーバ３に送信する。
【００５２】レスポンス受信部１５は、Ｗｅｂサーバ３
からのレスポンスを受信する。
【００５３】ＦＰ生成部１６は、レスポンス受信部１５
が受信したレスポンスを入力として受け取り、そのレス
ポンスのボディに入っているレスポンスデータに対する
フィンガープリントを生成する。
【００５４】データ保存部１７は、レスポンス受信部１
５が受信したレスポンスと、ＦＰ生成部１６が生成した
フィンガープリントを受け取り、それらを対応付けて保
存すべきことを、データ管理部１９に指令する。
【００５５】データ取出部１８は、リクエスト判別部１
３の指令によって、フィンガープリントに対応するレス
ポンスを取出すことを、データ管理部１９に指令する。
【００５６】データ管理部１９は、データ保存部１７の
指令により、フィンガープリントとレスポンスを対応付
けて保存する。
【００５７】また、データ管理部１９は、データ取出部
１８の指令により、フィンガープリントを入力として受
け取って、それに対応したレスポンスを出力する。
【００５８】レスポンス生成部２０は、レスポンス受信
部１５が受信したレスポンスと、ＦＰ生成部１６が生成
したフィンガープリントと、リクエスト保存部１２が保
存していたリクエストを受け取って、Ｗｅｂブラウザ５
に送信するリダイレクトレスポンスを生成する。また、
レスポンス生成部２０は、リクエスト判別部１３の指令
と、データ管理部１９から受け取ったレスポンスから、
Ｗｅｂブラウザ５に送信するレスポンスを生成する。
【００５９】レスポンス送信部２１は、レスポンス生成
部２０から受け取ったレスポンスをＷｅｂブラウザ５に
送信する。
【００６０】なお、データ管理部１９には、フィンガー
プリントとレスポンスを対応付けて保存する代わりに、
フィンガープリントとレスポンスのレスポンスデータの
部分とを対応付けて保存するように構成することも可能
である。
【００６１】図７に、キャッシュ・サーバ１がＷｅｂブ
ラウザ５からのリクエストを受信した場合における概略
的な処理手順の一例を示す。
【００６２】Ｗｅｂブラウザ５からのリクエストを受信
し（ステップＳ１０１）、詳しくは後述するように、受
信したリクエストが、特別なリクエストかどうか調べ、
特別なリクエストでなければ（ステップＳ１０２）、受
信したリクエストを、Ｗｅｂサーバ３へ送信する（ステ
ップＳ１０４）。一方、特別なリクエストであれば（ス
テップＳ１０２）、該当するレスポンスデータを含むリ
クエストを作成して、Ｗｅｂブラウザ５へ返信する（ス
テップＳ１０３）。
【００６３】図８に、キャッシュ・サーバ１がＷｅｂサ
ーバ３からのレスポンスを受信した場合における概略的
な処理手順の一例を示す。
【００６４】Ｗｅｂサーバ３からのレスポンスを受信し
（ステップＳ１２１）、受信したレスポンスのレスポン
スデータに対するフィンガープリントを求め、該フィン
ガープリントとレスポンスとを対応付けて保存し（ステ
ップＳ１２２）、該フィンガープリントと自身のホスト
名を含むリダイレクトレスポンスを作成して、Ｗｅｂブ
ラウザ５へ返信する（ステップＳ）。
【００６５】次に、本実施形態におけるＷｅｂブラウザ
５、キャッシュ・サーバ１およびＷｅｂサーバ３の三者
間でのデータ転送および処理の流れについて詳しく説明
する。
【００６６】図９に、Ｗｅｂブラウザ５があるＵＲＬに
対するリクエストを初めて発し、これに対応するレスポ
ンスを取得する場合の処理シーケンスの例を示す。
【００６７】以下、処理の各段階を順番に説明する。
【００６８】まず、ユーザの操作等を契機としてＷｅｂ
ブラウザ５がリクエストを送信する（ステップＳ１）。
すると、該リクエストは、公衆網４３を転送された後
に、キャッシュ・サーバ１にて受信される（ステップＳ
１）。先に説明したように、ＨＴＴＰのリクエストは、
リクエストヘッダとリクエストボディとから構成され、
リクエストヘッダには、メソッドとＵＲＬが含まれる。
【００６９】ここでは、具体的な例として、メソッド
は、ＧＥＴメソッドであり、ＵＲＬは、 ｈｔｔｐ：／／ｗｗｗ．ｏｆｆｉｃｅ．ｃｏｍ／ｉｎｄ
ｅｘ．ｈｔｍｌ であったとする。なお、ＧＥＴメソッドの場合、リクエ
ストボディは空であるのが通常であるので、以下の説明
でもリクエストボディは空であるとする。
【００７０】Ｗｅｂブラウザ５からのリクエストを受信
したキャッシュ・サーバ１では、図６のリクエスト受信
部１１がこのリクエストを受け取り、その内容をリクエ
スト判別部１３に渡すとともに、リクエスト保存部１２
にも渡してリクエストの内容を保存させる。
【００７１】リクエスト判別部１３は、リクエストヘッ
ダのＵＲＬをチェックし、該ＵＲＬの内容に基づいて、
該リクエストをＷｅｂサーバ３に転送するか否かを決定
する（ステップＳ２）。なお、詳しくは後述するよう
に、特定のＵＲＬへのリクエストに対しては、キャッシ
ュ・サーバ１は、それをＷｅｂサーバ３に転送せず、内
部でレスポンスを生成してＷｅｂブラウザ５に送信し、
特定のＵＲＬ以外のＵＲＬへのリクエストに対しては、
それをＷｅｂサーバ３に転送するものとする。ここで
は、リクエストに含まれるＵＲＬは、 ｈｔｔｐ：／／ｗｗｗ．ｏｆｆｉｃｅ．ｃｏｍ／ｉｎｄ
ｅｘ．ｈｔｍｌ であり、これは、特定のＵＲＬに該当しないので、リク
エスト判別部１３は、該リクエストをＷｅｂサーバ３に
転送すると決定し、該リクエストの内容をリクエスト送
信部１４に渡する。そして、リクエスト送信部１４は、
該リクエストをＷｅｂサーバ３に転送する（ステップＳ
３）。
【００７２】Ｗｅｂサーバ３は、このリクエストを受け
取ると（ステップＳ３）、当該リクエストに応じた処理
を行う。そして、その処理の結果得られるデータをレス
ポンスに載せて送信する（ステップＳ４）。すると、該
レスポンスは、キャッシュ・サーバ１にて受信される
（ステップＳ４）。
【００７３】ここで、今回のリクエストの場合、Ｗｅｂ
サーバ３上にあるＨＴＭＬドキュメントのデータを要求
している。ここでは、そのＨＴＭＬドキュメントは、あ
らかじめ作成された状態でＷｅｂサーバ３上にファイル
として保存されているものとする。この場合、Ｗｅｂサ
ーバ３は、ファイルからデータを読み出し、ステータス
コード“２００”を含むレスポンスヘッダと、ファイル
から読み出したＨＴＭＬドキュメントのデータからなる
レスポンスボディとから構成されるレスポンスを、キャ
ッシュ・サーバ１に送信することになる。
【００７４】キャッシュ・サーバ１は、レスポンス受信
部１５がＷｅｂサーバ３からのレスポンスを受け取る
と、そのレスポンスをＦＰ生成部１６に送って、レスポ
ンスの内容を識別するためのフィンガープリントを生成
する（ステップＳ５）。ここでは、例えば、フィンガー
プリントの値が、 “０１２３４５６７８９０ａｂｃｄｅｆｇｈｉｊｋｌｍ
ｎｏｐｑｒｓｔｕ” であったものとする。
【００７５】次に、レスポンス受信部１５が受信したレ
スポンスと、ＦＰ生成部１６が生成したフィンガープリ
ントは、データ保存部１７に渡される。データ保存部１
７は、両者を対応付けて保存するようデータ管理部１９
に指令する。データ管理部１９は、両者を対応付けて保
存する（ステップＳ６）。
【００７６】今回はフィンガープリントの値が、 “０１２３４５６７８９０ａｂｃｄｅｆｇｈｉｊｋｌｍ
ｎｏｐｑｒｓｔｕ” であったので、この値とレスポンス全体の内容とが対応
付けられて保存される。
【００７７】次に、キャッシュ・サーバ１は、レスポン
ス生成部２０でリダイレクトレスポンスを生成する（ス
テップＳ７）。
【００７８】先に説明したように、レスポンスのステー
タスコードの最初の一桁が３の場合、それはリダイレク
ションを表す。ここでは、ステータスコード“３０２”
を返すこととする。
【００７９】また、Ｌｏｃａｔｉｏｎヘッダに指定する
ＵＲＬには、 ・キャッシュ・サーバのホスト名 ・Ｗｅｂサーバからのレスポンスに対するフィンガープ
リントの値 ・Ｗｅｂブラウザからのリクエストに含まれていたＵＲ
Ｌのｓｕｆｆｉｘ の３つから構成された、 http://(ホスト名)/(フィンカ゛ーフ゜リントの値).(suffix) というＵＲＬを指定するものとする。
【００８０】キャッシュ・サーバ１のホスト名があらか
じめ決まっているものであるとすると、Ｗｅｂサーバ３
からのレスポンスに対するフィンガープリントの値は、
ＦＰ生成部１６が生成しており、Ｗｅｂブラウザ５から
のリクエストに含まれていたＵＲＬのｓｕｆｆｉｘは、
リクエスト保存部１２が保存していたリクエストの中か
ら取出すことができるので、レスポンス生成部２０は、
ＦＰ生成部１６とリクエスト保存部１２から情報を受け
取ることによって、このＵＲＬを生成できることになる
（従って、リダイレクトレスポンスを生成できることに
なる）。
【００８１】ここでは、具体的な例として、キャッシュ
・サーバ１のホスト名を、 ｃａｃｈｅ．ｏｆｆｉｃｅ．ｃｏｍ とすると、このＵＲＬは、 http://cache.office.com/01234567890abcdefghijklmno
pqrstu.html となり、生成されるレスポンスのレスポンスヘッダは、 302 Found Location: http://cache.office.com/01234567890abcde
fghijklmnopqrstu.html のようになる。
【００８２】そして、レスポンス送信部２１は、生成さ
れたリダイレクトレスポンスをＷｅｂブラウザ５に送信
する（ステップＳ８）。
【００８３】Ｗｅｂブラウザ５は、ステータスコード
“３０２”を含むレスポンスを受信すると（ステップＳ
８）。
【００８４】ここで、受信したリダイレクトレスポンス
にて指定されたＵＲＬに該当するレスポンスがキャッシ
ュされているかどうか、Ｗｅｂブラウザ５のブラウザキ
ャッシュを検索し（ステップＳ９）、それがキャッシュ
されていれば、該ブラウザキャッシュから該レスポンス
のデータを取得して利用することができるが、今回は、
（あるＵＲＬに対するリクエストを初めて発した場合で
あるので）Ｗｅｂブラウザ５のブラウザキャッシュに該
当するレスポンスがないものとすると、実際に、Ｌｏｃ
ａｔｉｏｎに指定されたＵＲＬに対するリクエストを再
度送信することになる（ステップＳ１０）。
【００８５】この場合、最初に送信したリクエストのメ
ソッドがＧＥＴであるので、Ｗｅｂブラウザ５は、メソ
ッドに同じＧＥＴメソッドを、そしてＵＲＬには先ほど
受信したレスポンスのＬｏｃａｔｉｏｎヘッダに指定さ
れていた、 http://cache.office.com/01234567890abcdefghijklmno
pqrstu.html を指定してリクエストをキャッシュ・サーバ１に送信す
る。
【００８６】なお、ＨＴＴＰ１．１の規約では、リクエ
ストに対してステータスコード“３０２”を含むレスポ
ンスが帰ってきた場合は、ＥｘｐｉｒｅヘッダやＣａｃ
ｈｅ−Ｃｏｎｔｒｏｌヘッダによってキャッシュ可能な
ことが示されている場合を除き、そのステータスコード
“３０２”を含むレスポンスをキャッシュしてはいけな
いことになっている。ここでは、キャッシュ・サーバ１
は、レスポンスにそのようなキャッシュ可能を示すヘッ
ダを付加しておらず、従って、ブラウザ５のブラウザキ
ャッシュは、このレスポンスをキャッシュしなかったも
のとする。
【００８７】キャッシュ・サーバ１では、リクエスト受
信部１１がこのリクエストを受け取り（ステップＳ１
０）、その内容をリクエスト判別部１３に渡すととも
に、リクエスト保存部１２にも渡してリクエストの内容
を保存させる。
【００８８】リクエスト判別部１３は、リクエストヘッ
ダのＵＲＬをチェックし、このリクエストをＷｅｂサー
バ３に転送するか否かを決定する（ステップＳ１１）。
【００８９】今回のリクエストに含まれるＵＲＬは、 http://cache.office.com/01234567890abcdefghijklmno
pqrstu.html であるが、リクエスト判別部１３は、このようなＵＲＬ
へのリクエストを、Ｗｅｂサーバ３へは転送せずに、特
別なものとして通常のリクエストとは別の処理を行う。
【００９０】なお、リクエスト判別部１３が受け取った
リクエストを、Ｗｅｂサーバ３に転送するか、それとも
特別扱いするかについての判断は、例えば、ＵＲＬのホ
スト部分を抽出し、それがあらかじめ定められたキャッ
シュ・サーバ１のホスト名（この場合は、ｃａｃｈｅ．
ｏｆｆｉｃｅ．ｃｏｍ）と一致するかを調べることによ
って可能である。
【００９１】上記のように、リクエストをＷｅｂサーバ
３へは転送しないすなわち特別扱いすると判定される
と、具体的には、このリクエストはＷｅｂサーバ３に転
送せず、ＵＲＬの中に含まれるフィンガープリントを抽
出し、データ取出部１８に、このフィンガープリントに
対応するレスポンスの取出しを指令し、データ取出部１
８は、このフィンガープリントに対応するレスポンスを
データ管理部１９から取出す（ステップＳ１２）。
【００９２】そして、データ管理部１９から取出された
レスポンスがレスポンス生成部２０に渡され、保存され
ていたレスポンスと同じボディ（レスポンスデータ）を
持つレスポンス、すなわちＷｅｂサーバ３上にあったＨ
ＴＭＬドキュメントと同じ内容をボディに持つレスポン
スが生成される（ステップＳ１３）。
【００９３】生成されたレスポンスは、レスポンス送信
部２１によってＷｅｂブラウザ５に送信される（ステッ
プＳ１４）。
【００９４】このようにして、データ本体を含むレスポ
ンスが、Ｗｅｂブラウザ５によって受信される（ステッ
プＳ１４）。
【００９５】しかして、このＷｅｂブラウザ５は、ブラ
ウザキャッシュを持つので、受信されたレスポンスは、
該ブラウザキャッシュに保存されることになる（ステッ
プＳ１５）。
【００９６】ブラウザキャッシュへのキャッシュの仕方
には種々の方法が考えられるが、例えば、「リクエスト
に含まれていたＵＲＬ」と「そのリクエストに対するレ
スポンスの内容」とを対応付けて保存する。今回のこの
レスポンスに対応するのは、Ｗｅｂサーバ３からのリダ
イレクトレスポンスに対応するために発せられた、 http://cache.office.com/01234567890abcdefghijklmno
pqrstu.html へのＧＥＴリクエストである。従って、例えば、このＵ
ＲＬとレスポンスの内容とが対応付けられて、ブラウザ
キャッシュに保存されることになる。
【００９７】続いて、同じＷｅｂブラウザ５から、 http://www.office.com/index.html に対するＧＥＴのリクエストが再度発せられた場合につ
いて説明する。
【００９８】図１０に、この場合の処理シーケンスの例
を示す。
【００９９】これを図９のケース（リクエストを初めて
発したケース）と比較した場合、図１０のステップＳ２
１の「リクエストの送信」からステップＳ２８「リダイ
レクトレスポンスの送信」までは図９のステップＳ１〜
ステップＳ８と全く同じ処理の流れであり、さらに図１
０のステップＳ２４で送信されるレスポンスのボディに
含まれるデータの内容、ステップＳ２５で生成されるＦ
Ｐの値、ステップＳ２７で生成されステップＳ２８で送
信されるリダイレクトレスポンスのＬｏｃａｔｉｏｎヘ
ッダに含まれるＵＲＬも全て図９のステップＳ２４、ス
テップＳ２５、ステップＳ２７、ステップＳ２８の場合
とそれぞれ同一である。すなわち、Ｗｅｂブラウザ５が
リダイレクトレスポンスを受け取るまでは、初めてリク
エストを発する場合と同じ手順が行われる。
【０１００】しかし、Ｗｅｂブラウザ５がリダイレクト
レスポンスを受信した以降の処理は図９のケース（リク
エストを初めて発したケース）とは異なったものとな
る。
【０１０１】すなわち、リダイレクトレスポンスを受け
取った結果、Ｗｅｂブラウザ５は、 http://cache.office.com/01234567890abcdefghijklmno
pqrstu.html のＵＲＬに対するＧＥＴを実行しようとする。ところ
が、最初のときとは違って、Ｗｅｂブラウザ５のブラウ
ザキャッシュには、このＵＲＬに対するＧＥＴを実行し
た結果が保存されている。
【０１０２】従って、今回は、Ｗｅｂブラウザ５が、そ
のブラウザキャッシュを検索すると（ステップＳ２
９）、保存しておいたデータが得られるので、（指定さ
れたＵＲＬへのＧＥＴリクエストを発することなく）こ
の保存しておいたデータをＧＥＴの結果として利用する
（ステップＳ３０）。このため、処理の流れは、これで
終了する。
【０１０３】ここで、あらためて図９と図１０の処理の
流れを比較してみると、図９ではステップＳ１４におい
て、ＨＴＭＬドキュメントがレスポンスのボディとし
て、キャッシュ・サーバ１とＷｅｂブラウザ５との間を
転送されているのに対して、図１０ではＨＴＭＬドキュ
メントはキャッシュ・サーバ１とＷｅｂブラウザ５との
間を転送されていない。すなわち、本実施形態によれ
ば、２回目以降のデータ転送が不要とるのである。これ
は、両者の間に存在するボトルネックすなわち図２の場
合における（ＬＡＮ４１よりも通信速度の遅い）公衆回
線４３を流れるデータ量が削減されることを意味してお
り、つまり図１を参照しながら説明した従来の技術によ
るデータ転送のボトルネックが解消されることを意味し
ているのである。
【０１０４】ところで、以上の説明においては、Ｗｅｂ
ブラウザ５が要求したＵＲＬのサービスは、あらかじめ
作成された状態でＷｅｂサーバ３上にファイルとして保
存されている「静的」なものであるとして説明してき
た。以下では、ＵＲＬのサービスが「動的」なものであ
る場合について説明する。
【０１０５】ここでは、具体的な例として、Ｗｅｂサー
バ３上に一つのプログラムが置かれており、ユーザはこ
のプログラムが提供するサービスに、 http://www.office.com/program.cgi というＵＲＬに対するＧＥＴリクエストを発行すること
によってアクセスできるものとする。そして、このＵＲ
Ｌへのリクエストに対しては、状況によって２種類の異
なるデータがレスポンスとして送信されるものとする。
以下の説明では、２種類のデータをそれぞれＤａｔａ−
Ａ、Ｄａｔａ−Ｂと表し、それぞれのデータに対応する
フィンガープリントの値をＦＰ−Ａ、ＦＰ−Ｂと表すも
のとする。
【０１０６】まず、ユーザが上記のＵＲＬのサービスに
初めてリクエストを発し、Ｗｅｂサーバ３は、レスポン
スとしてＤａｔａ−Ａを返したとする。キャッシュ・サ
ーバ１のＦＰ生成部１６が生成するフィンガープリント
の値はＦＰ−Ａとなるので、（ここでは、データ管理部
１９にはフィンガープリントの値とレスポンスデータと
が対応付けて保存されるとすると）データ管理部１９に
は、（ＦＰ−Ａ， Ｄａｔａ−Ａ）という対応付けでフ
ィンガープリントとレスポンスが保存される。また、レ
スポンス生成部２０は、リダイレクトレスポンスを生成
するが、そのＬｏｃａｔｉｏｎヘッダには、 http://cache.office.com/FP-A.cgi というＵＲＬが指定される。
【０１０７】Ｗｅｂブラウザ５は、リダイレクトレスポ
ンスを受け取ると、上記のＵＲＬに対するＧＥＴリクエ
ストを実行しようとするが、その前に自らのブラウザキ
ャッシュに、このＵＲＬへのＧＥＴに対するレスポンス
が既にキャッシュされていないか確かめる。しかし、元
々のＵＲＬにアクセスしたのが初めてであるから、レス
ポンスは、キャッシュされていない。従って、リクエス
トをキャッシュ・サーバ１に送信する。
【０１０８】キャッシュ・サーバ１は、上記のＵＲＬへ
のリクエストを受け取ると、該リクエストに含まれるフ
ィンガープリントの値である“ＦＰ−Ａ”に対応するレ
スポンス“Ｄａｔａ−Ａ”を取出し、それをレスポンス
としてＷｅｂブラウザ５に送信する。Ｗｅｂブラウザ５
は、このレスポンスを、 (http://cache.office.com/FP-A.cgi, Data-A) という対応付けでブラウザキャッシュに保存する。
【０１０９】その後、同じＷｅｂブラウザ５から、 http://www.office.com/program.cgi へのＧＥＴリクエストが発せられた場合を考えてみる。
このリクエストは、キャッシュ・サーバ１からＷｅｂサ
ーバ３へと転送され、それに対してＷｅｂサーバ３は、
レスポンスを返すが、このレスポンスの内容は状況に応
じてＤａｔａ−ＡであったりＤａｔａ−Ｂであったりす
る。以下、それぞれの場合について処理の流れを説明す
る。
【０１１０】まず、Ｗｅｂサーバ３がＤａｔａ−Ａをレ
スポンスとして返した場合は、キャッシュ・サーバ１か
らＷｅｂブラウザ５にリダイレクトレスポンスが送信さ
れるまで最初と全く同じことの繰り返しになる。すなわ
ち、リダイレクトレスポンスのＬｏｃａｔｉｏｎヘッダ
には、 http://cache.office.com/FP-A.cgi が指定されている。
【０１１１】そして、Ｗｅｂブラウザ５は、このＵＲＬ
に対するＧＥＴリクエストを実行しようとするが、最初
のリクエストでＷｅｂブラウザ５のブラウザキャッシュ
には、 (http://cache.office.com/FP-A.cgi, Data-A) という対応付けのエントリが生成されている。
【０１１２】そこで、Ｗｅｂブラウザ５は、ＧＥＴリク
エストを発する代りに、Ｄａｔａ−Ａをそのリクエスト
に対するレスポンスとして利用する。
【０１１３】一方、Ｗｅｂサーバ３がＤａｔａ−Ｂをレ
スポンスとして返した場合は、キャッシュ・サーバ１の
データ管理部１９には、（ＦＰ−Ｂ， Ｄａｔａ−Ｂ）
というエントリが作成され、またキャッシュ・サーバ１
からＷｅｂブラウザ５に送信されるリダイレクトレスポ
ンスのＬｏｃａｔｉｏｎヘッダには、 http://cache.office.com/FP-B.cgi というＵＲＬが指定される。
【０１１４】Ｗｅｂブラウザ５は、このＵＲＬに対する
ＧＥＴリクエストをハッスル前にブラウザキャッシュを
確認するが、上記のＵＲＬに対応するエントリは存在し
ない。そのため、上記ＵＲＬへのＧＥＴリクエストが実
際にキャッシュ・サーバ１へと送信され、その結果、キ
ャッシュ・サーバ１に保存されていたＤａｔａ−Ｂがレ
スポンスとして送信される。
【０１１５】以上の結果を見ると、２回目のアクセスで
キャッシュ・サーバ１がＤａｔａ−Ａをレスポンスとし
て返した場合には、１回目のアクセスでＷｅｂブラウザ
５のブラウザキャッシュに保存されていたＤａｔａ−Ａ
が再利用され、一方Ｄａｔａ−Ｂをレスポンスとして返
した場合には、キャッシュ・サーバ１からＤａｔａ−Ｂ
がレスポンスとして送信されている。すなわち、本実施
形態によれば、ブラウザキャッシュのような、ＵＲＬと
レスポンスとを対応付けて保存するキャッシュではキャ
ッシュできなかった動的コンテンツでも、問題なくキャ
ッシュできるようになる。
【０１１６】さて、これまでの説明では、１つのＷｅｂ
サーバ３のみについて着目して説明してきた。しかし、
実際のＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂシステムでは、Ｗ
ｅｂサーバは複数存在し、それぞれのＷｅｂサーバがそ
れぞれのサービスを提供している、という状況が一般的
である。
【０１１７】そこで、以下では、１つのキャッシュ・サ
ーバ１が対象とするＷｅｂサーバが複数存在している場
合について考えてみる。
【０１１８】まず、図１１に示すように、ＬＡＮ４１上
にＷｅｂサーバ３が２つ存在する場合を例にとって、従
来の技術の問題点について説明する。
【０１１９】図１１に示すように２つのＷｅｂサーバが
存在する場合、その両方に同じデータが置かれていると
いうことは、よくあることである。例えば、画面の画像
に同じ画像データを使っている、といったような場合で
ある。この場合、同じ内容のデータが２つの異なるＵＲ
Ｌで提供されていることになる。例えば、図中、＃１で
示すＷｅｂサーバ３のホスト名を“www1.office.co
m”、図中、＃２で示すＷｅｂサーバ３のホスト名を“w
ww2.office.com”とすると、各Ｗｅｂサーバ３上にある
画像データにアクセスするためのＵＲＬは、それぞれ、 http://www1.office.com/image-1.gif http://www2.office.com/image-2.gif のようになる。
【０１２０】このような状況において、Ｗｅｂブラウザ
が上記の２つのＵＲＬへのＧＥＴリクエストを順番に発
したものとする。従来の技術によれば、リクエストは、
直接、Ｗｅｂサーバ３に送信され、レスポンスは、直
接、Ｗｅｂブラウザ５に送信され、そして、リクエスト
のＵＲＬとレスポンスの内容とが対応付けられてブラウ
ザキャッシュに保存される。上記の２つのＵＲＬにアク
セスしたときのレスポンスの内容をそれぞれＤａｔａ−
１、Ｄａｔａ−２とすると、ブラウザキャッシュには、 (http://www1.office.com/image-1.gif, Data-1) (http://www2.office.com/image-2.gif, Data-2) の２つのエントリが生成される。
【０１２１】ところが、２つのＵＲＬに置かれている画
像データは同じものであるから、Ｄａｔａ−１とＤａｔ
ａ−２とは等しい。従って、Ｗｅｂブラウザ５のブラウ
ザキャッシュには、 (http://www1.office.com/image-1.gif, Data-1) (http://www2.office.com/image-2.gif, Data-1) の２つのエントリが存在することになるが、これは同一
のデータＤａｔａ−１が重複して保存されていること、
あるいは既に同一のデータがキャッシュされているにも
関わらずうまく再利用されていないことを示していると
言える。
【０１２２】次に、図１２のように、図１１のＬＡＮ４
１に本実施形態のキャッシュ・サーバ１を設置した場合
について考えてみる。なお、前述と同様に、キャッシュ
・サーバ１の設置方法としては、種々のバリエーション
が可能であり、例えば、図３のようにＬＡＮ４１に直接
接続する形で配置する方法、ＬＡＮ４１上に存在する所
定の機能を有する他のノード（いずれかのＷｅｂサーバ
３でもよい）に搭載する方法なども可能である。
【０１２３】以下、図１２において、上記の２つのＵＲ
Ｌに対するＧＥＴリクエストを順番に発した場合の処理
の流れについて説明する。
【０１２４】まず、“http://www1.office.com/image-
1.gif”へのリクエストを初めて発したものとする。Ｗ
ｅｂブラウザ５からキャッシュ・サーバ１に送信された
リクエストは、キャッシュ・サーバ１から“www1.offic
e.com”なるＷｅｂサーバ３に転送される。
【０１２５】Ｗｅｂサーバ３は、レスポンスとして“Ｄ
ａｔａ−１”をキャッシュ・サーバ１に返す。キャッシ
ュ・サーバ１のＦＰ生成部１６が生成するフィンガープ
リントをＦＰ−１とすると、キャッシュ・サーバ１のデ
ータ管理部１９には、（ＦＰ−１， Ｄａｔａ−１）と
いうエントリが生成される。
【０１２６】そして、レスポンス生成部２０が、Ｌｏｃ
ａｔｉｏｎヘッダに、 http://cache.office.com/FP-1.gif なるＵＲＬを指定したリダイレクトレスポンスを生成
し、レスポンス送信部２１がこのリダイレクトレスポン
スをＷｅｂブラウザ５に送信する。
【０１２７】Ｗｅｂブラウザ５は、このＵＲＬに対する
ＧＥＴリクエストを発する前に、ブラウザキャッシュ
に、このＵＲＬに対応するエントリが存在するか確認す
る。今回は最初のアクセスなのでエントリは存在せず、
従ってＧＥＴリクエストがキャッシュ・サーバ１に送信
される。
【０１２８】キャッシュ・サーバ１は、ＦＰ−１に対応
するレスポンスであるＤａｔａ−１を取出し、それをレ
スポンスとしてＷｅｂブラウザ５に送信する。
【０１２９】Ｗｅｂブラウザ５は、レスポンスを受け取
ると、内蔵ブラウザの中に、 (http://cache.office.com/FP-1.gif, Data-1) というエントリを作成する。
【０１３０】続いて、“http://www2.office.com/image
-2.gif”へのリクエストを初めて発したものとする。今
度は、リクエストは、“www2.office.com”なるＷｅｂ
サーバ３に転送される。
【０１３１】２つのＵＲＬに置かれている画像データの
内容は同一なので、Ｗｅｂサーバ３は、レスポンスとし
てＤａｔａ−１を返す。従って、キャッシュ・サーバ１
のＦＰ生成部１６は、このレスポンスに対するフィンガ
ープリントとしてＦＰ−１を生成し、レスポンス生成部
２０が生成するリダイレクトレスポンスのＬｏｃａｔｉ
ｏｎヘッダには、 http://cache.office.com/FP-1.gif というＵＲＬが指定されることになる。
【０１３２】このリダイレクトレスポンスを受け取った
Ｗｅｂブラウザ５は、このＵＲＬへのＧＥＴリクエスト
を実行する前に、ブラウザキャッシュに、このＵＲＬに
対応するエントリが存在するか確認する。すると、先ほ
ど“http://www1.office.com/image-1.gif”へのＧＥＴ
リクエストを発した際に、ブラウザキャッシュには、 (http://cache.office.com/FP-1.gif, Data-1) というエントリが生成されている。従って、Ｗｅｂブラ
ウザ５は、リクエストを発する代りに、ブラウザキャッ
シュに保存されていた“Ｄａｔａ−１”をレスポンスと
して使用する。
【０１３３】以上の結果を見ると、１回目のリクエスト
のレスポンスとして転送されブラウザのブラウザキャッ
シュに保存されたデータが、２回目で違うＵＲＬへのリ
クエストであったにも関わらず再利用されている。すな
わち、異なるＵＲＬで内容の等しいデータが提供されて
いるような状況において、従来の技術によるのであれ
ば、ブラウザキャッシュのような、ＵＲＬとレスポンス
とを対応付づけて保存するキャッシュではうまく取り扱
えなかった場合であっても、本実施形態によれば有効に
キャッシュできるようになる。
【０１３４】ところで、キャッシュ・サーバ１のデータ
管理部１９においては、通常、キャッシュ情報の保存の
ための容量に上限があるため、所定のアルゴリズムに従
いガーベジコレクションを行って、例えば古いデータや
使いそうに無いデータを消して行くようにしてもよい。
【０１３５】ただし、この場合に、例えば、キャッシュ
・サーバ１において、フィンガープリントと自身のホス
ト名とを含むリダイレクトレスポンスをＷｅｂブラウザ
５へ送信した直後に、これに該当するフィンガープリン
トとデータの組をデータ管理部１９から削除すると、キ
ャッシュ・サーバ１から上記のリダイレクトレスポンス
を受信したＷｅｂブラウザ５があらためてキャッシュ・
サーバ１へリクエストを送信しても、該キャッシュ・サ
ーバ１のデータ管理部１９には該当するフィンガープリ
ントとデータの組が存在しないことになる。したがっ
て、どのようなアルゴリズムに従うにしても、キャッシ
ュ・サーバ１からＷｅｂブラウザ５へリダイレクトレス
ポンスを送信してから少なくとも一定の時間が経過する
までは、該当するフィンガープリントとデータの組を削
除しないようにするのが好ましい。
【０１３６】また、あるレスポンスのデータＡに対する
フィンガープリントと、あるレスポンスのデータＢ（デ
ータＡとは異なるものとする）に対するフィンガープリ
ントとが、非常に低い確率で一致することがあり得る
が、これに起因するエラーを回避する必要がある場合に
は、すべてのレスポンス（あるいは、例えばＵＲＬで規
定される重要なデータに係るレスポンス）について、キ
ャッシュ・サーバ１においてレスポンスを受信するごと
に、受信したレスポンスのデータに対応するフィンガー
プリントと対応付けてデータ管理部１９に保存されてい
るデータがあれば、そのデータと、受信したレスポンス
のデータとを、比較して、データの不一致が発生してい
ないか、確認するようにしてもよい。もしデータの不一
致が発生している場合には、例えば次に例示するいずれ
かの方法で対処すればよい。・そのフィンガープリント
は以降使用禁止とする（そのフィンガープリントを与え
るデータは以後キャッシュされないことになる）。・先
に登録されているフィンガープリント／データを優先す
る（登録中のフィンガープリントと同じ値のフィンガー
プリントを与える他のデータは、その登録中はキャッシ
ュされないことになる）。・現在登録対象となっている
フィンガープリント／データを優先する（登録中のフィ
ンガープリント／データは、同じ値のフィンガープリン
トを与える他のデータによって次々と更新されていくこ
とになる）。
【０１３７】なお、以上では、ＬＡＮに対する通信のボ
トルネットとなる公衆回線及びモデムを介して、企業オ
フィス内のＬＡＮ上のＷｅｂサーバとＷｅｂブラウザ
（ユーザ端末）との間で通信を行う場合を例にとって説
明してきたが、もちろん、本発明は、企業オフィス以外
のＬＡＮにも適用可能であるし、Ｗｅｂサーバ以外のデ
ータを提供するサーバ等の装置にも適用可能であるし、
Ｗｅｂブラウザ以外のデータの提供のサービスを受ける
クライアント等の装置にも適用可能であるし、どのよう
な公衆回線でも適用可能であるし、モデム以外の通信装
置でも適用可能である。
【０１３８】なお、以上の各機能は、ソフトウェアとし
て実現可能である。また、本実施形態は、コンピュータ
に所定の手段を実行させるための（あるいはコンピュー
タを所定の手段として機能させるための、あるいはコン
ピュータに所定の機能を実現させるための）プログラム
として実施することもでき、該プログラムを記録したコ
ンピュータ読取り可能な記録媒体として実施することも
できる。
【０１３９】なお、この発明の実施の形態で例示した構
成は一例であって、それ以外の構成を排除する趣旨のも
のではなく、例示した構成の一部を他のもので置き換え
たり、例示した構成の一部を省いたり、例示した構成に
別の機能あるいは要素を付加したり、それらを組み合わ
せたりすることなどによって得られる別の構成も可能で
ある。また、例示した構成と論理的に等価な別の構成、
例示した構成と論理的に等価な部分を含む別の構成、例
示した構成の要部と論理的に等価な別の構成なども可能
である。また、例示した構成と同一もしくは類似の目的
を達成する別の構成、例示した構成と同一もしくは類似
の効果を奏する別の構成なども可能である。また、この
発明の実施の形態で例示した各種構成部分についての各
種バリエーションは、適宜組み合わせて実施することが
可能である。また、この発明の実施の形態は、個別装置
としての発明、関連を持つ２以上の装置についての発
明、システム全体としての発明、個別装置内部の構成部
分についての発明、またはそれらに対応する方法の発明
等、種々の観点、段階、概念またはカテゴリに係る発明
を包含・内在するものである。従って、この発明の実施
の形態に開示した内容からは、例示した構成に限定され
ることなく発明を抽出することができるものである。
【０１４０】本発明は、上述した実施の形態に限定され
るものではなく、その技術的範囲において種々変形して
実施することができる。
【０１４１】
【発明の効果】本発明によれば、Ｗｅｂブラウザ等を搭
載した通信装置とデータ転送装置との間を接続するネッ
トワークの負荷をより軽減することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るキャッシュ・サーバ
を設置する対象となるコンピュータ・ネットワーク・シ
ステムの構成例を示す図
【図２】同実施形態に係るキャッシュ・サーバを設置し
たコンピュータ・ネットワーク・システムの構成例を示
す図
【図３】同実施形態に係るキャッシュ・サーバを設置し
たコンピュータ・ネットワーク・システムの構成例を示
す図
【図４】同実施形態で使用するフィンガープリントにつ
いて説明するための図
【図５】同実施形態で使用するフィンガープリントにつ
いて説明するための図
【図６】同実施形態に係るキャッシュ・サーバの構成例
を示す図
【図７】同実施形態に係るキャッシュ・サーバがＷｅｂ
ブラウザからのリクエストを受信した場合における処理
手順の一例を示すフローチャート
【図８】同実施形態に係るキャッシュ・サーバがＷｅｂ
サーバからのレスポンスを受信した場合における処理手
順の一例を示すフローチャート
【図９】あるＵＲＬへのリクエストを初めて発したとき
の処理の流れを表す図
【図１０】同一ＵＲＬへのリクエストを再度発したとき
の処理の流れを表す図
【図１１】同実施形態に係るキャッシュ・サーバを設置
する対象となるコンピュータ・ネットワーク・システム
の他の構成例を示す図
【図１２】同実施形態に係るキャッシュ・サーバを設置
したコンピュータ・ネットワーク・システムの他の構成
例を示す図
【符号の説明】
１…キャッシュ・サーバ ３…Ｗｅｂサーバ ５…Ｗｅｂブラウザ １１…リクエスト受信部 １２…リクエスト保存部 １３…リクエスト判別部 １４…リクエスト送信部 １５…レスポンス受信部 １６…ＦＰ生成部 １７…データ保存部 １８…データ取出部 １９…データ管理部 ２０…レスポンス生成部 ２１…レスポンス送信部 ４１…ＬＡＮ ４２…モデム ４３…公衆回線 ４４…モデム
フロントページの続き (72)発明者 吉井 謙一郎 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 庄野 篤司 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 佐藤 英昭 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 關 俊文 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B082 HA02 HA08 5K034 AA07 DD01 HH01 HH02 HH11 MM39 NN12 NN26

Claims (12)

    【特許請求の範囲】
  1. 【請求項１】第１の通信装置から送信されたリクエスト
    メッセージを受信する第１の受信手段と、 受信されたリクエストメッセージが第２の通信装置へ転
    送すべきものである場合に、該リクエストメッセージを
    前記第２の通信装置へ送信する第１の送信手段と、 前記第２の通信装置から返送された前記レスポンスデー
    タを含む前記レスポンスメッセージを受信する第２の受
    信手段と、 受信された前記レスポンスメッセージに含まれる前記レ
    スポンスデータに割り当てるべき識別子を、該レスポン
    スデータの内容に基づいて生成する手段と、 少なくとも前記レスポンスデータと前記識別子とを対応
    付けて保持する保持手段と、 前記第２の通信装置から前記レスポンスデータを含む前
    記レスポンスメッセージを受信した場合に、前記第１の
    通信装置に対して、該レスポンスデータを含むレスポン
    スメッセージを送信する代わりに、前記識別子を含む所
    定のＵＲＬへのリダイレクトレスポンスメッセージを送
    信する第２の送信手段とを備え、 前記第２の送信手段は、前記第１の受信手段を介して前
    記第１の通信装置からの前記識別子を含む所定のＵＲＬ
    へのリクエストメッセージが受信された場合には、該Ｕ
    ＲＬに含まれる該識別子に対応して前記保持手段に保持
    されている前記レスポンスデータを含むレスポンスメッ
    セージを、前記第１の通信装置に送信することを特徴と
    するデータ転送装置。
  2. 【請求項２】前記第１の受信手段により前記第１の通信
    装置から受信された前記リクエストメッセージが前記第
    ２の通信装置へ転送すべきものであるか否かを判別する
    判別手段を更に備えたことを特徴とする請求項１に記載
    のデータ転送装置。
  3. 【請求項３】前記判別手段は、前記第１の通信装置から
    受信された前記リクエストメッセージが前記識別子を含
    む所定のＵＲＬへのリクエストメッセージである場合
    に、該リクエストメッセージが前記第２の通信装置へ転
    送すべきものでないと判断し、それ以外の場合に、該リ
    クエストメッセージが前記第２の通信装置へ転送すべき
    ものであると判断することを特徴とする請求項２に記載
    のデータ転送装置。
  4. 【請求項４】前記ＵＲＬは、自データ転送装置のホスト
    名と、前記レスポンスデータに割り当てられた前記識別
    子とを用いて生成されたものであることを特徴とする請
    求項１ないし３のいずれか１項に記載のデータ転送装
    置。
  5. 【請求項５】前記識別子は、所定の方法によって前記デ
    ータを圧縮して得た値であることを特徴とする請求項１
    ないし３のいずれか１項に記載のデータ転送装置。
  6. 【請求項６】前記識別子は、前記データに所定のハッシ
    ュ関数を適用して得られた値であることを特徴とする請
    求項５に記載のデータ転送装置。
  7. 【請求項７】前記データ転送装置は、ローカルエリアネ
    ットワークに接続され、 前記ローカルエリアネットワークには、前記データ転送
    装置が対象とする１又は複数の前記第２の通信装置が接
    続されることを特徴とする請求項１ないし６のいずれか
    １項に記載のデータ転送装置。
  8. 【請求項８】前記データ転送装置は、ローカルエリアネ
    ットワークに接続され、 前記所定のネットワークは、前記ローカルエリアネット
    ワークの持つ通信速度よりも遅い通信速度を持つもので
    あることを特徴とする請求項１ないし７のいずれか１項
    に記載のデータ転送装置。
  9. 【請求項９】前記第１の通信装置はＷｅｂブラウザを起
    動可能なユーザ端末であり、前記第２の通信装置はＷｅ
    ｂサーバであることを特徴とする請求項１ないし８のい
    ずれか１項に記載のデータ転送装置。
  10. 【請求項１０】前記第１の通信装置は、通信装置を内蔵
    した若しくは外付け可能な携帯型ＰＣ又は情報処理機能
    を有する携帯電話端末であることを特徴とする請求項１
    ないし９のいずれか１項に記載のデータ転送装置。
  11. 【請求項１１】所定のネットワークを介して第１の通信
    装置から送信されたリクエストメッセージを受信して第
    ２の通信装置に転送し、該リクエストメッセージを受け
    付けた該第２の通信装置から返送されたレスポンスデー
    タを含むレスポンスメッセージを受信して第１の通信装
    置に転送するデータ転送装置におけるデータ転送方法で
    あって、 前記第１の通信装置から送信されたリクエストメッセー
    ジを受信し、 受信されたリクエストメッセージを前記第２の通信装置
    へ送信し、 前記第２の通信装置から返送された前記レスポンスデー
    タを含む前記レスポンスメッセージを受信し、 受信された前記レスポンスメッセージに含まれる前記レ
    スポンスデータに割り当てるべき識別子を、該レスポン
    スデータの内容に基づいて生成し、 少なくとも前記レスポンスデータと前記識別子とを対応
    付けて保持手段に保持し、 前記第２の通信装置から前記レスポンスデータを含む前
    記レスポンスメッセージを受信した場合に、前記第１の
    通信装置に対して、該レスポンスデータを含むレスポン
    スメッセージを送信する代わりに、前記識別子を含む所
    定のＵＲＬへのリダイレクトレスポンスメッセージを送
    信し、 前記第１の通信装置から送信された前記識別子を含む所
    定のＵＲＬへのリクエストメッセージを受信し、 受信された前記リクエストメッセージの前記ＵＲＬに含
    まれる前記識別子に対応して前記保持手段に保持されて
    いる前記レスポンスデータを含むレスポンスメッセージ
    を、前記第１の通信装置に送信することを特徴とするデ
    ータ転送方法。
  12. 【請求項１２】所定のネットワークを介して第１の通信
    装置から送信されたリクエストメッセージを受信して第
    ２の通信装置に転送し、該リクエストメッセージを受け
    付けた該第２の通信装置から返送されたレスポンスデー
    タを含むレスポンスメッセージを受信して第１の通信装
    置に転送するデータ転送装置としてコンピュータを機能
    させるためのプログラムであって、 前記第１の通信装置から送信されたリクエストメッセー
    ジを受信する機能と、 受信されたリクエストメッセージが前記第２の通信装置
    へ転送すべきものである場合に、該リクエストメッセー
    ジを前記第２の通信装置へ送信する機能と、 前記第２の通信装置から返送された前記レスポンスデー
    タを含む前記レスポンスメッセージを受信する機能と、 受信された前記レスポンスメッセージに含まれる前記レ
    スポンスデータに割り当てるべき識別子を、該レスポン
    スデータの内容に基づいて生成する機能と、 少なくとも前記レスポンスデータと前記識別子とを対応
    付けて保持する保持機能と、 前記第２の通信装置から前記レスポンスデータを含む前
    記レスポンスメッセージを受信した場合には、前記第１
    の通信装置に対して、該レスポンスデータを含むレスポ
    ンスメッセージを送信する代わりに、前記識別子を含む
    所定のＵＲＬへのリダイレクトレスポンスメッセージを
    送信し、前記第１の通信装置からの前記識別子を含む所
    定のＵＲＬへのリクエストメッセージが受信された場合
    には、該ＵＲＬに含まれる該識別子に対応して前記保持
    機能に保持されている前記レスポンスデータを含むレス
    ポンスメッセージを、前記第１の通信装置に送信する機
    能とをコンピュータに実現させるためのプログラム。
JP2002089949A 2002-03-27 2002-03-27 キャッシュサーバ、データ転送装置及びプログラム Expired - Fee Related JP3984086B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2002089949A JP3984086B2 (ja) 2002-03-27 2002-03-27 キャッシュサーバ、データ転送装置及びプログラム
US10/396,396 US7069297B2 (en) 2002-03-27 2003-03-26 Data transfer scheme using re-direct response message for reducing network load

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002089949A JP3984086B2 (ja) 2002-03-27 2002-03-27 キャッシュサーバ、データ転送装置及びプログラム

Publications (2)

Publication Number Publication Date
JP2003288261A true JP2003288261A (ja) 2003-10-10
JP3984086B2 JP3984086B2 (ja) 2007-09-26

Family

ID=28449545

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002089949A Expired - Fee Related JP3984086B2 (ja) 2002-03-27 2002-03-27 キャッシュサーバ、データ転送装置及びプログラム

Country Status (2)

Country Link
US (1) US7069297B2 (ja)
JP (1) JP3984086B2 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3829125B2 (ja) * 2003-05-16 2006-10-04 株式会社コナミデジタルエンタテインメント ネットワークシステム、ネットワーク制御方法及びプログラム
US7711799B2 (en) * 2004-11-22 2010-05-04 Alcatel-Lucent Usa Inc. Method and apparatus for pre-packetized caching for network servers
US7716306B2 (en) * 2005-01-25 2010-05-11 International Business Machines Corporation Data caching based on data contents
US20070192324A1 (en) * 2006-01-31 2007-08-16 Opera Software Asa Method and device for advanced cache management in a user agent
US20090070336A1 (en) * 2007-09-07 2009-03-12 Sap Ag Method and system for managing transmitted requests
US8719216B2 (en) * 2007-10-24 2014-05-06 The Boeing Company Caching of web form post-query requests
US8244799B1 (en) * 2008-07-21 2012-08-14 Aol Inc. Client application fingerprinting based on analysis of client requests
JPWO2011148719A1 (ja) * 2010-05-28 2013-07-25 日本電気株式会社 情報処理装置、ｇｕｉ操作支援方法およびｇｕｉ操作支援プログラム
US8856260B2 (en) 2011-06-14 2014-10-07 Microsoft Corporation Providing access to shared state data
US10776834B2 (en) * 2013-07-15 2020-09-15 Criteo Sa Domain selection for advertisement data
US10892968B2 (en) 2015-12-18 2021-01-12 Google Llc Systems and methods for latency reduction in content item interactions using client-generated click identifiers
US10277650B1 (en) * 2016-05-12 2019-04-30 Google Llc Parallel execution of request tracking and resource delivery
JP6747303B2 (ja) * 2017-01-13 2020-08-26 富士通株式会社 通信装置、通信システム、通信方法、および、通信プログラム
US11308524B2 (en) 2017-01-17 2022-04-19 Criteo Sa Risk-adjusted predictive bidding for electronic advertisements
US11120481B2 (en) 2017-10-27 2021-09-14 Criteo Sa Predictive adjusted bidding for electronic advertisements
US11049150B2 (en) 2018-06-22 2021-06-29 Criteo Sa Generation of incremental bidding and recommendations for electronic advertisements

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3167484B2 (ja) 1993-03-01 2001-05-21 富士通株式会社 送信側システム及び受信側システム並びにデータ転送処理システム
US6012085A (en) * 1995-11-30 2000-01-04 Stampede Technolgies, Inc. Apparatus and method for increased data access in a network file object oriented caching system
US5682514A (en) * 1995-11-30 1997-10-28 Stampede Technologies, Inc. Apparatus and method for increased data access in a network file oriented caching system
US5835943A (en) * 1995-11-30 1998-11-10 Stampede Technologies, Inc. Apparatus and method for increased data access in a network file oriented caching system
JP3102369B2 (ja) 1997-01-31 2000-10-23 富士通株式会社 データ処理装置
US5909569A (en) 1997-05-07 1999-06-01 International Business Machines Terminal emulator data stream differencing system
US6675161B1 (en) * 1999-05-04 2004-01-06 Inktomi Corporation Managing changes to a directory of electronic documents
US6990628B1 (en) * 1999-06-14 2006-01-24 Yahoo! Inc. Method and apparatus for measuring similarity among electronic documents
US6813690B1 (en) * 2001-06-12 2004-11-02 Network Appliance, Inc. Caching media data using content-sensitive identifiers
US6775743B2 (en) * 2001-09-12 2004-08-10 International Business Machines Corporation Content caching with special handling of multiple identical requests for content

Also Published As

Publication number Publication date
US20030187923A1 (en) 2003-10-02
US7069297B2 (en) 2006-06-27
JP3984086B2 (ja) 2007-09-26

Similar Documents

Publication Publication Date Title
US8024484B2 (en) Caching signatures
JP3990115B2 (ja) サーバ側プロキシ装置及びプログラム
EP1429517B1 (en) Access relaying apparatus
US6237031B1 (en) System for dynamically controlling a network proxy
US7636765B2 (en) Data transfer scheme using caching technique for reducing network load
US7480731B2 (en) Data transfer scheme using caching technique for reducing network load
US20030061275A1 (en) Method and system for remotely managing persistent state data
JP3984086B2 (ja) キャッシュサーバ、データ転送装置及びプログラム
CN103051663A (zh) 图片共享对等网络中用于改进访客图像查看性能的代理高速缓存技术
CN1272279A (zh) 预取对象的分布系统和方法
JP2003281023A (ja) データ転送装置、データ転送方法、データ受信表示装置、プログラム
JP3848209B2 (ja) データ転送装置、データ転送方法及びプログラム
JP4031516B2 (ja) サーバ側プロキシ装置、クライアント側プロキシ装置、データ転送方法及びプログラム
JP4053269B2 (ja) データ転送装置およびデータ転送方法
JP3983987B2 (ja) サーバ側プロキシ装置、データ転送方法及びプログラム
JP3943867B2 (ja) サーバ側プロキシ、データ転送方法及びプログラム
JP3943868B2 (ja) サーバ側プロキシ、データ転送方法及びプログラム
JP3913508B2 (ja) データ転送装置およびデータ転送方法
JP2003108464A (ja) データ転送装置およびデータ転送方法
JP4041157B2 (ja) クライアント側プロキシ装置、データ転送方法及びプログラム
JP3977651B2 (ja) データ転送方法、サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム
JP3977601B2 (ja) サーバ側プロキシ装置、クライアント側プロキシ装置及びプログラム
JP4300220B2 (ja) データ転送装置およびデータ転送方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061114

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070410

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070611

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070703

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070705

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100713

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100713

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110713

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120713

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130713

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees