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