(57)【要約】【課題】参照データをもとに対象データを圧縮して転送するデータ転送装置において、参照データ・キャッシュのより効果的な管理を可能にするデータ転送装置を提供すること。【解決手段】サーバー側装置５００のキャッシュ保持部５０３は、過去にクライアント側装置へ送信したデータを参照データとしてキャッシュする。通信部５０１がサーバー装置からデータを受信すると、差分圧縮部５０２によりキャッシュ保持部５０３の参照データに基づき該データを差分圧縮し、該差分圧縮したデータを通信部５０１からクライアント側装置へ転送する。キャッシュ保持部５０３にキャッシュした総データサイズがキャッシュ可能サイズを超える場合には、削除判定部５０８が、より圧縮率の高いものから優先的に削除すべき参照データを選択し、削除部５０４が、選択された参照データをキャッシュ保持部５０３から削除する。【選択図】      図１
2005190339.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも過去に圧縮して特定のクライアント装置側データ転送装置へ送信したデータにつき、これを圧縮していない状態で参照データとして保持するための保持手段と、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを受信する受信手段と、
前記保持手段に保持されている前記参照データに基づいて、受信した前記データを圧縮した圧縮データを生成する生成手段と、
生成された前記圧縮データを前記クライアント装置側データ転送装置へ送信する送信手段と、
前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データから生成された圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶する記憶手段と、
前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択手段と、
この選択手段により選択された参照データを前記保持手段から削除する削除手段とを備えたことを特徴とするサーバー装置側データ転送装置。
【請求項２】
少なくとも過去に特定のサーバー装置側データ転送装置から受信した圧縮データにつき、これを圧縮されていない状態で参照データとして保持するための保持手段と、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを、前記サーバー装置側データ転送装置から受信する受信手段と、
受信した前記データにつき、それが圧縮されていないデータであるか又は圧縮されている圧縮データであるかを、受信した前記データに付加されている特定の情報に基づいて判断する判断手段と、
受信した前記データが圧縮データである場合に、前記保持手段に保持されている前記参照データに基づいて、該圧縮データを伸長して圧縮されていない状態のデータを生成する生成手段と、
生成された前記データを、前記或るクライアント装置へ送信する送信手段と、
前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データを生成するもととなった圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶する記憶手段と、
前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択手段と、
この選択手段により選択された参照データを前記保持手段から削除する削除手段とを備えたことを特徴とするクライアント装置側データ転送装置。
【請求項３】
前記選択手段は、選択した前記参照データが前記削除手段により前記保持手段から削除された後における、前記保持手段に保持される全参照データに係る前記第１の情報の総和が、基準値以下になるまで、前記選択を行うことを特徴とする請求項１または２に記載のデータ転送装置。
【請求項４】
前記選択手段は、或るデータを参照データとして前記保持手段に保持するのに先立って、該或るデータ及び前記保持手段に保持される参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和が、前記保持手段の保持可能なデータ・サイズの上限値を超える場合に、前記選択を行うものであり、
前記保持手段は、前記選択手段により選択された前記参照データが前記削除手段により前記保持手段から削除された後に、前記或るデータを参照データとして保持するものであることを特徴とする請求項３に記載のデータ転送装置。
【請求項５】
前記選択手段は、前記第２の情報により前記圧縮の程度がより高いことが示される参照データを優先的に選択することを特徴とする請求項１ないし４のいずれか１項に記載のデータ転送装置。
【請求項６】
前記選択手段により選択された前記参照データを特定する情報を、前記クライアント装置側データ転送装置に通知する通知手段を更に備えたことを特徴とする請求項１に記載のデータ転送装置。
【請求項７】
或るデータを参照データとして前記保持手段に保持するか否かを、当該或るデータに係る前記第２の情報に基づいて判定する判定手段を更に備えたことを特徴とする請求項１または２に記載のデータ転送装置。
【請求項８】
前記クライアント装置側データ転送装置へ送信する或るデータを参照データとして前記保持手段に保持するか否かを、当該或るデータに係る前記第２の情報に基づいて判定する判定手段と、
前記或るデータに係る前記判定手段による判定結果を、前記クライアント装置側データ転送装置に通知する通知手段とを更に備えたことを特徴とする請求項１に記載のデータ転送装置。
【請求項９】
前記保持手段は、前記判定手段により保持すると判定された場合にのみ、前記或るデータを参照データとして保持することを特徴とする請求項７または８に記載のデータ転送装置。
【請求項１０】
前記判定手段は、前記或るデータに係る前記第２の情報により示される圧縮の程度が、基準値以下である場合に、前記保持手段に保持すると判定することを特徴とする請求項７ないし９のいずれか１項に記載のデータ転送装置。
【請求項１１】
サーバー装置側データ転送装置及びクライアント装置側データ転送装置を含む通信システムにおいて、
前記サーバー装置側データ転送装置は、
少なくとも過去に圧縮して特定のクライアント装置側データ転送装置へ送信したデータにつき、これを圧縮していない状態で参照データとして保持するための第１の保持手段と、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを受信する第１の受信手段と、
前記第１の保持手段に保持されている前記参照データに基づいて、受信した前記データを圧縮した圧縮データを生成する第１の生成手段と、
生成された前記圧縮データを前記クライアント装置側データ転送装置へ送信する第１の送信手段と、
前記第１の保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データから生成された圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶する記憶手段と、
前記第１の保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記第１の保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記第１の保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記第１の及び第２の保持手段から削除すべき参照データを選択する選択手段と、
この選択手段により選択された参照データを前記第１の保持手段から削除する第１の削除手段と、
前記選択手段により選択された前記参照データを特定する情報を、前記クライアント装置側データ転送装置に通知する特定情報通知手段とを備え、
前記クライアント装置側データ転送装置は、
少なくとも過去に前記サーバー装置側データ転送装置から受信した前記圧縮データにつき、これを圧縮されていない状態で参照データとして保持するための第２の保持手段と、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを、前記サーバー装置側データ転送装置から受信する第２の受信手段と、
受信した前記データにつき、それが圧縮されていないデータであるか又は圧縮されている圧縮データであるかを、受信した前記データに付加されている特定の情報に基づいて判断する判断手段と、
受信した前記データが圧縮データである場合に、前記第１の保持手段に保持されている前記参照データに基づいて、該圧縮データを伸長して圧縮されていない状態のデータを生成する第２の生成手段と、
生成された前記データを、前記或るクライアント装置へ向けて送信する第２の送信手段と、
前記サーバー装置側データ転送装置から、前記選択手段により選択された前記参照データを特定する情報の通知を取得する特定情報通知取得手段と、
取得された前記情報により特定される参照データを前記第２の保持手段から削除する第２の削除手段とを備えたことを特徴とする通信システム。
【請求項１２】
前記選択手段は、選択した前記参照データが前記第１の削除手段により前記第１の保持手段から削除された後における、前記第１の保持手段に保持される全参照データに係る前記第１の情報の総和が、基準値以下になるまで、前記選択を行うことを特徴とする請求項１１に記載の通信システム。
【請求項１３】
前記選択手段は、或るデータを参照データとして前記第１の保持手段に保持するのに先立って、該或るデータ及び前記第１の保持手段に保持される参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和が、前記第１の保持手段の保持可能なデータ・サイズの上限値を超える場合に、前記選択を行うものであり、
前記第１及び第２の保持手段は、それぞれ、前記選択手段により選択された前記参照データが前記第１及び第２の削除手段により前記第１及び第２保持手段から削除された後に、前記或るデータを参照データとして保持するものであることを特徴とする請求項１２に記載の通信システム。
【請求項１４】
前記選択手段は、前記第２の情報により前記圧縮の程度がより高いことが示される参照データを優先的に選択することを特徴とする請求項１１ないし１３のいずれか１項に記載の通信システム。
【請求項１５】
前記第１のデータ転送装置は、
前記第２のデータ転送装置へ送信する或るデータを参照データとして前記第１及び第２の保持手段に保持するか否かを、当該或るデータに係る前記第２の情報に基づいて判定する判定手段と、
前記或るデータに係る前記判定手段による判定結果を、前記第２のデータ転送装置に通知する判定結果通知手段とを更に備え、
前記第２のデータ転送装置は、
前記第１のデータ転送装置から、前記或るデータに係る前記判定手段による判定結果の通知を取得する判定結果通知取得手段を更に備えたことを特徴とする請求項１１に記載の通信システム。
【請求項１６】
前記第１及び第２の保持手段は、前記判定手段により保持すると判定された場合にのみ、前記或るデータを参照データとして保持することを特徴とする請求項１５に記載のデータ転送装置。
【請求項１７】
前記判定手段は、前記或るデータに係る前記第２の情報により示される圧縮の程度が、基準値以下である場合に、前記第１及び第２の保持手段に保持すると判定することを特徴とする請求項１５または１６に記載のデータ転送装置。
【請求項１８】
少なくとも過去に圧縮して特定のクライアント装置側データ転送装置へ送信したデータにつき、これを圧縮していない状態で参照データとして保持手段に保持するための保持ステップと、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを受信する受信ステップと、
前記保持手段に保持されている前記参照データに基づいて、受信した前記データを圧縮した圧縮データを生成する生成ステップと、
生成された前記圧縮データを前記クライアント装置側データ転送装置へ送信する送信ステップと、
前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データから生成された圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶手段に記憶する記憶ステップと、
前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択ステップと、
この選択ステップにより選択された参照データを前記保持手段から削除する削除ステップとを有することを特徴とするデータ転送方法。
【請求項１９】
少なくとも過去に特定のサーバー装置側データ転送装置から受信した圧縮データにつき、これを圧縮されていない状態で参照データとして保持手段に保持するための保持ステップと、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを、前記サーバー装置側データ転送装置から受信する受信ステップと、
受信した前記データにつき、それが圧縮されていないデータであるか又は圧縮されている圧縮データであるかを、受信した前記データに付加されている特定の情報に基づいて判断する判断ステップと、
受信した前記データが圧縮データである場合に、前記保持手段に保持されている前記参照データに基づいて、該圧縮データを伸長して圧縮されていない状態のデータを生成する生成ステップと、
生成された前記データを、前記或るクライアント装置へ送信する送信ステップと、
前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データを生成するもととなった圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶手段に記憶する記憶ステップと、
前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択ステップと、
この選択ステップにより選択された参照データを前記保持手段から削除する削除ステップとを有することを特徴とするデータ転送方法。
【請求項２０】
サーバー装置側データ転送装置としてコンピュータを機能させるためのプログラムにおいて、
前記プログラムは、
少なくとも過去に圧縮して特定のクライアント装置側データ転送装置へ送信したデータにつき、これを圧縮していない状態で参照データとして保持手段に保持するための保持ステップと、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを受信する受信ステップと、
前記保持手段に保持されている前記参照データに基づいて、受信した前記データを圧縮した圧縮データを生成する生成ステップと、
生成された前記圧縮データを前記クライアント装置側データ転送装置へ送信する送信ステップと、
前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データから生成された圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶手段に記憶する記憶ステップと、
前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択ステップと、
この選択ステップにより選択された参照データを前記保持手段から削除する削除ステップとをコンピュータに実行させることを特徴とするプログラム。
【請求項２１】
クライアント装置側データ転送装置としてコンピュータを機能させるためのプログラムにおいて、
前記プログラムは、
少なくとも過去に特定のサーバー装置側データ転送装置から受信した圧縮データにつき、これを圧縮されていない状態で参照データとして保持手段に保持するための保持ステップと、
或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを、前記サーバー装置側データ転送装置から受信する受信ステップと、
受信した前記データにつき、それが圧縮されていないデータであるか又は圧縮されている圧縮データであるかを、受信した前記データに付加されている特定の情報に基づいて判断する判断ステップと、
受信した前記データが圧縮データである場合に、前記保持手段に保持されている前記参照データに基づいて、該圧縮データを伸長して圧縮されていない状態のデータを生成する生成ステップと、
生成された前記データを、前記或るクライアント装置へ送信する送信ステップと、
前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データを生成するもととなった圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶手段に記憶する記憶ステップと、
前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択ステップと、
この選択ステップにより選択された参照データを前記保持手段から削除する削除ステップとをコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ転送を行うデータ転送装置、複数のデータ転送装置を含む通信システム、データ転送方法及びプログラムに関する。
【背景技術】
【０００２】
ネットワークを介して様々なサービスを提供するサーバーと、所望のサービスをサーバーに対して要求するクライアントとから構成される、クライアント・サーバー型の情報システムが広く普及している。特に、インターネット上でＨＴＴＰプロトコルを使って通信するＷｅｂサーバーとクライアントからなるＷＯＲＬＤ  ＷＩＤＥ  ＷＥＢシステム（あるいは単にＷｅｂシステムとも呼ばれる）は、大変広く利用されているクライアント・サーバー型の情報システムである。通常、サーバー上ではサーバープログラムが動作し、クライアント上ではブラウザなどの所定のツール（プログラム）が動作する。インターネット上で提供されるサービスの内容も多岐に渡っており、ネットワーク経由で文字、静止画像、動画像、音声等の情報（たとえば、ホームページ、電子メール、デジタルコンテンツなど）や、プログラムなどを提供、配信あるいは転送などするサービス、また商品を販売するための電子店舗サービス、座席や部屋などの予約サービス、種々の仲介サービスなど、種々のサービスが既に存在し、また次々と新たな形態のサービスが出現している。
【０００３】
ところで、Ｗｅｂのようなクライアント・サーバー型の情報システムにおいては、提供されるサービスがどのような形態のものであろうと、基本的にはクライアント・サーバー間でデータ転送が行われることによってサービスが提供される。したがって、クライアントとサーバーとの間で通信に用いるネットワーク容量（バンド幅）がシステム全体のパフォーマンスのボトルネックになりやすい。そこで、通常、ネットワークの負荷を軽減させるためにキャッシュ技術が用いられる。
【０００４】
Ｗｅｂ閲覧をする場合、ＷｅｂブラウザとＷｅｂサーバーの間にあるキャッシングプロキシサーバーやＷｅｂブラウザ自身のキャッシュを使うことで、Ｗｅｂ閲覧に際して転送データ量を削減し、リクエストを出してからレスポンスを受け取りＷｅｂブラウザにコンテンツを表示する一連のシーケンスにかかる時間（レスポンスタイム）を高速化する技術がある。キャッシングプロキシサーバーとしてはｓｑｕｉｄ（ｈｔｔｐ：／／ｒｉｎｇ．ａｉｓｔ．ｇｏ．ｊｐ／ａｒｃｈｉｖｅｓ／ｎｅｔ／ｗｗｗ／ｓｑｕｉｄ／）が有名で、ｓｑｕｉｄをＷｅｂサーバーとＷｅｂブラウザを結ぶネットワーク上に配置することで、Ｗｅｂブラウザからのリクエストに対して、以前閲覧されｓｑｕｉｄにキャッシュされているコンテンツの場合はｓｑｕｉｄからレスポンスを返すことで、Ｗｅｂサーバーまでのネットワーク転送を回避し、レスポンスタイムの向上を実現している。また、Ｗｅｂブラウザ自身に備えられているキャッシュを用いることで、Ｗｅｂブラウザからリクエストを出した時点で既にＷｅｂブラウザのキャッシュに保存されているコンテンツの場合は、ただちに該当コンテンツをＷｅｂブラウザに表示し、ネットワークを流れる転送データ量を削減すると伴に、レスポンスタイムを向上している。これらのキャッシュ技術はＵＲＬに対してコンテンツが一意に定まるＷｅｂコンテンツ（静的なコンテンツ）に対してＷｅｂデータ転送量削減効果やレスポンスタイム向上効果が得られる有効な手段である。
【０００５】
しかし、近年のＷｅｂ技術の進化に伴い、ＣＧＩ(Common Gateway Interface)、ＡＳＰ(Active Server Pages)、ＪＳＰ(Java Server Pages)等といったＷｅｂサーバーにリクエストが届いた時点でデーターベースの検索結果やリクエストを出したユーザーの入力等によって動的に生成される動的なコンテンツが増加している。これら動的なコンテンツは同じＵＲＬに対してコンテンツが毎回異なることがあり、ＵＲＬに対してコンテンツが一意に定まらない。このような動的なコンテンツに対して従来からあるキャッシングプロキシやＷｅｂブラウザのキャッシュは有効に動作せず、リクエストのたびにＷｅｂブラウザからＷｅｂサーバーまでのネットワーク間をコンテンツの全データを送受信しなければならず、バンド幅の大量消費やそれに伴うレスポンスタイムの遅延が問題となっている。
【０００６】
特許文献１〜３では、動的なコンテンツに対してコンテンツ自身のハッシュ値（フィンガープリント）とコンテンツを一対一に対応付けてキャッシュするフィンガープリントキャッシュを提案している。これらの技術は、Ｗｅｂサーバー側ＬＡＮにプロキシサーバーとしてフィンガープリントキャッシュを備えるサーバー側プロキシと、クライアント側ＬＡＮにプロキシサーバーとしてフィンガープリントキャッシュを備えるクライアント側プロキシを設置し、Ｗｅｂサーバー側のＬＡＮとクライアント側ＬＡＮの間を結ぶインターネット・ＬＡＮ・ＷＡＮ等といったネットワークを流れるＷｅｂデータを削減する。その方法としては、取得した動的なコンテンツに対してフィンガープリントを計算し、フィンガープリントとコンテンツをフィンガープリントキャッシュに保存する。次回以降、もしＷｅｂサーバーからレスポンスを受信した場合、サーバー側プロキシは、フィンガープリントを計算し一致した場合はコンテンツ自体が一致していると判断して、コンテンツの代わりにフィンガープリントのみをクライアント側プロキシに送信し、クライアント側プロキシは、送られてきたフィンガープリントと一致するコンテンツをフィンガープリントキャッシュから取得しＷｅｂブラウザにそのコンテンツを転送する（ＦＰ転送）。また、Ｗｅｂサーバーからのレスポンスに類似したコンテンツがフィンガープリントキャッシュにあった場合は、サーバー側プロキシは、ベースとなるコンテンツのフィンガープリントと差分部分から構成される差分データを送り、クライアント側装置では、差分データによって指定されたフィンガープリントのコンテンツをフィンガープリントキャッシュから取得すると伴に差分部分のデータを用いてオリジナルのコンテンツを復元し、Ｗｅｂブラウザに転送する（差分転送）。これらの技術を用いることで、動的なコンテンツに対してもキャッシュを用いてＷｅｂ転送データを削減し、レスポンスタイムを向上させることが可能となる。
【０００７】
サーバー側プロキシでは、次回以降にベースとして利用するために差分圧縮前のコンテンツをフィンガープリントキャッシュに保存すると伴に、クライアント側プロキシも、差分伸長後のコンテンツをフィンガープリントキャッシュに保存する。
【０００８】
ところで、キャッシュデータの保存に使われるデータ保存領域はキャッシュを行うコンピュータに直接もしくはネットワーク経由で接続されている主記憶装置や補助記憶装置が利用される。補助記憶装置に関してはＲＡＩＤ(Redundant Array of Independent)技術によって冗長性を向上させると伴に容量を増加させることも可能であるが、データ保存領域は有限なためキャッシュを削除する必要がある。従来、静的なコンテンツのキャッシュに対して、参照された日時の古いものから順に削除するＬＲＵ(Least Recently Used)アルゴリズムや、利用頻度の低いコンテンツから順に削除するＬＦＵ(Least Frequently Used)アルゴリズム等がある。キャッシュされたコンテンツの総量がキャッシュ可能サイズを超えた場合やコンピュータの管理者による明示的な削除命令が出された場合、ある一定時間を経過した場合、またはなにかしらの条件を満たした場合に起動され、上記ＬＲＵやＬＦＵもしくは別のアルゴリズムに従ってキャッシュを削除することで、削除後も最近アクセスしたコンテンツや閲覧頻度の高いコンテンツがキャッシュに残るような仕組みが導入されている。
【特許文献１】特開２００２−２６８９３５
【特許文献２】特開２００３−２６８９３６
【特許文献３】特開２００３−２６８９３７
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来、フィンガープリントキャッシュのように、取得したコンテンツをユニークに識別する識別子とコンテンツを対にしてキャッシュし、新たに取得したコンテンツがキャッシュにあるコンテンツと同一部分を持つ場合にベースとなるコンテンツの識別子と差分部分から構成される差分情報をサーバー側装置が計算し下流に転送するとともに、クライアント側装置が受信した差分データを指定された識別子のコンテンツをキャッシュから取得し差分部分と組み合わせて元のデータを復元するシステムがある。このような技術は近年普及の著しい動的なコンテンツの転送データ量を削減するものとして非常に有効な手段である。
【００１０】
しかしながら、従来、キャッシュの削除方法に関しては、動的なコンテンツを対象とした場合の有効な方法が知られていなかった。また、従来、取得したコンテンツは全てキャッシュに登録されており、より有効なキャッシュの方法が知られていなかった。また、従来、サーバー側装置とクライアント側装置とにそれぞれキャッシュされているコンテンツに不一致が発生し、クライアント側装置で差分データを復元する際に差分データで指定された識別子を持つコンテンツがなければ差分伸長が行えず、差分転送に失敗するというケースが発生し得るが、これを回避する方法が知られていなかった。
【００１１】
本発明は、上記事情を考慮してなされたもので、参照データをもとに対象データを圧縮して転送するデータ転送装置において、参照データのキャッシュに対するより効果的な管理を可能にするデータ転送装置、通信システム、データ転送方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明に係るサーバー装置側データ転送装置は、少なくとも過去に圧縮して特定のクライアント装置側データ転送装置へ送信したデータにつき、これを圧縮していない状態で参照データとして保持するための保持手段と、或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを受信する受信手段と、前記保持手段に保持されている前記参照データに基づいて、受信した前記データを圧縮した圧縮データを生成する生成手段と、生成された前記圧縮データを前記クライアント装置側データ転送装置へ送信する送信手段と、前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データから生成された圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶する記憶手段と、前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択手段と、この選択手段により選択された参照データを前記保持手段から削除する削除手段とを備えたことを特徴とする。
【００１３】
また、本発明に係るクライアント装置側データ転送装置は、少なくとも過去に特定のサーバー装置側データ転送装置から受信した圧縮データにつき、これを圧縮されていない状態で参照データとして保持するための保持手段と、或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを、前記サーバー装置側データ転送装置から受信する受信手段と、受信した前記データにつき、それが圧縮されていないデータであるか又は圧縮されている圧縮データであるかを、受信した前記データに付加されている特定の情報に基づいて判断する判断手段と、受信した前記データが圧縮データである場合に、前記保持手段に保持されている前記参照データに基づいて、該圧縮データを伸長して圧縮されていない状態のデータを生成する生成手段と、生成された前記データを、前記或るクライアント装置へ送信する送信手段と、前記保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データを生成するもととなった圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶する記憶手段と、前記保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記保持手段から削除すべき参照データを選択する選択手段と、この選択手段により選択された参照データを前記保持手段から削除する削除手段とを備えたことを特徴とする。
【００１４】
また、本発明に係る通信システムは、サーバー装置側データ転送装置及びクライアント装置側データ転送装置を含む通信システムにおいて、前記サーバー装置側データ転送装置は、少なくとも過去に圧縮して特定のクライアント装置側データ転送装置へ送信したデータにつき、これを圧縮していない状態で参照データとして保持するための第１の保持手段と、或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを受信する第１の受信手段と、前記第１の保持手段に保持されている前記参照データに基づいて、受信した前記データを圧縮した圧縮データを生成する第１の生成手段と、生成された前記圧縮データを前記クライアント装置側データ転送装置へ送信する第１の送信手段と、前記第１の保持手段に保持されている前記参照データの各々につき、当該データのデータ・サイズを示す第１の情報、及び当該データのデータ・サイズと当該データから生成された圧縮データのデータ・サイズとにより定まる圧縮の程度を示す第２の情報を記憶する記憶手段と、前記第１の保持手段に保持される全参照データの各々に係る前記第１の情報により示されるデータ・サイズの総和と、前記第１の保持手段の保持可能なデータ・サイズの上限値との関係が、或る条件を満たす場合に、前記第１の保持手段に記憶されている各参照データに係る前記第２の情報に基づいて、前記第１の及び第２の保持手段から削除すべき参照データを選択する選択手段と、この選択手段により選択された参照データを前記第１の保持手段から削除する第１の削除手段と、前記選択手段により選択された前記参照データを特定する情報を、前記クライアント装置側データ転送装置に通知する特定情報通知手段とを備え、
前記クライアント装置側データ転送装置は、少なくとも過去に前記サーバー装置側データ転送装置から受信した前記圧縮データにつき、これを圧縮されていない状態で参照データとして保持するための第２の保持手段と、或るサーバー装置を送信元とし或るクライアント装置を宛先とするデータを、前記サーバー装置側データ転送装置から受信する第２の受信手段と、受信した前記データにつき、それが圧縮されていないデータであるか又は圧縮されている圧縮データであるかを、受信した前記データに付加されている特定の情報に基づいて判断する判断手段と、受信した前記データが圧縮データである場合に、前記第１の保持手段に保持されている前記参照データに基づいて、該圧縮データを伸長して圧縮されていない状態のデータを生成する第２の生成手段と、生成された前記データを、前記或るクライアント装置へ向けて送信する第２の送信手段と、前記サーバー装置側データ転送装置から、前記選択手段により選択された前記参照データを特定する情報の通知を取得する特定情報通知取得手段と、取得された前記情報により特定される参照データを前記第２の保持手段から削除する第２の削除手段とを備えたことを特徴とする。
【００１５】
本発明によれば、参照データをもとに転送対象データを圧縮して転送するデータ転送装置において、参照データのキャッシュに対するより効果的な管理が可能になる（差分圧縮・伸長に対してより効率の良いキャッシュ維持方法が実現できる）。
【００１６】
例えば、ＵＲＬとコンテンツが一意に定まらない（例えば、ＣＧＩ等によって生成されるアクセスのたびに内容の異なる）動的コンテンツに対して、サーバー側データ転送装置とクライアント側データ転送装置との間で差分圧縮して転送することで、それらの間を流れるデータ転送量を削減する場合に、差分圧縮における圧縮率に基づいてキャッシュから削除すべきコンテンツを選択する手段を導入することによって、動的なコンテンツのキャッシュに差分圧縮のベースとして相応しいコンテンツを維持することができる。また、例えば、この手段をサーバー側データ転送装置のみに設け、サーバー側データ転送装置が削除対象コンテンツをクライアント側データ転送装置に通知して互いのキャッシュの同期をとるようにすることによって、それらの間のキャッシュの不一致から生じる差分転送の失敗をなくすことができるとともに、クライアント側データ転送装置の処理負荷を軽減できる。また、例えば、差分圧縮における圧縮率に基づいて当該コンテンツをキャッシュへ登録するか否かを判定する手段を導入することによって、登録処理やキャッシュ領域の有効利用を行うことができる。また、例えば、この手段を、サーバー側データ転送装置のみに設け、サーバー側データ転送装置が各コンテンツの登録の有無をクライアント側データ転送装置に通知して互いのキャッシュの同期をとるようにすることによって、それらの間のキャッシュの不一致から生じる差分転送の失敗をなくすことができるとともに、クライアント側データ転送装置の処理負荷を軽減できる。
【００１７】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。  
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手段を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。
【発明の効果】
【００１８】
本発明によれば、参照データをもとに転送対象データを圧縮して転送するデータ転送装置において、参照データのキャッシュに対するより効果的な管理が可能になる。
【発明を実施するための最良の形態】
【００１９】
以下、図面を参照しながら本発明の実施形態について説明する。
【００２０】
本実施形態のＷｅｂサーバー、プロキシ、Ｗｅｂブラウザは、いずれも計算機上でソフトウェア（Ｗｅｂサーバー・プログラム、プロキシ・プログラム、Ｗｅｂブラウザ・プログラム）を動作させる形で実現することができる。この場合に、必要に応じて計算機所望の機能を有するＯＳやドライバソフト、あるいは通信インターフェース装置や外部記憶装置や入出力装置といったハードウェアが搭載、あるいは接続される。また、この場合に、ユーザーあるいは管理者からの情報やユーザーへの情報呈示等のために、グラフィカル・ユーザー・インターフェース（ＧＵＩ）を用いると好ましい。
【００２１】
本実施形態では、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂシステムでの通信は、ＨＴＴＰプロトコルに従って行なわれる。ＨＴＴＰプロトコルに関しては、ＲＦＣ１９４５に示されているＨＴＴＰ１．０もしくはＲＦＣ２６１６に示されているＨＴＴＰ１．１を用いて説明する。
【００２２】
以下では、インターネットがＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）であり、クライアントがユーザーオフィスのＬＡＮに接続されたＰＣであり、ＨＴＴＰプロトコルが使用されるような場合を例にとって説明するが、もちろん、本発明を実施するにあたりＷＡＮが例えばインターネットであったりＰＨＳや携帯電話等を用いた無線ネットワークなどであったり、ＷＡＮ以外のものであっても適用可能である。また、クライアントがオフィス以外の例えば家庭内ＬＡＮ等に設置されたものであっても、ＨＴＴＰプロトコル以外のプロトコルが使用されるものであっても適用可能である。
【００２３】
図１に、本発明を適用するコンピュータ・ネットワークシステムの構成例を示す。この構成例では、ＡＳＰ(Application Service Provider)サーバーセンター内のローカルエリアネットワーク（ＬＡＮ）１００とユーザーオフィス内のＬＡＮ１０４との間が、インターネットや専用回線等の広域ネットワークＷＡＮ１０３を介して接続されており、ＡＳＰサーバーセンター内のＬＡＮ１００に接続されたサーバー１０１と、ユーザーオフィス内のＬＡＮ１０４に接続されたクライアント１０６とが、ＬＡＮ１０４、ＷＡＮ１０３、ＬＡＮ１００を介して通信可能となっている。ＡＳＰサーバーセンター内のＬＡＮ１００には１または複数のサーバーが接続され、ユーザーオフィス内のＬＡＮ１０４には１または複数のクライアントが接続される。
【００２４】
ＷｅｂベースのＡＳＰは、サーバーセンター内ＬＡＮ１００に設置したサーバー１０１からＷＡＮ１０３を介して、様々なアプリケーションプログラムによるサービスを提供し、ユーザーはユーザーオフィス内のＬＡＮ１０４に設置されたクライアント１０６上のＷｅｂブラウザ１０７を使ってそれらのサービスにアクセスする。
【００２５】
このような利用形態においては、ユーザーオフィスのＬＡＮ１０４とサーバーセンターのＬＡＮ１００を繋ぐネットワーク、特にインターネットなどの広域ネットワーク１０３の実効的な通信容量（バンド幅）はサーバーセンターのＬＡＮ１０４やユーザーオフィスのＬＡＮ１００よりも低く、そこが性能上のボトルネックになって通信の遅延が発生し、アプリケーションのレスポンスタイムが低下するという問題が発生する。
【００２６】
そこで、本実施形態では、図１に示すようにサーバーセンターのＬＡＮ１０４とユーザーオフィスのＬＡＮ１００とを繋ぐ広域ネットワーク１０３の両端にサーバー側プロキシ１０５及びクライアント側プロキシ１０２という二つのモジュールを設置し、それらの間で後述する差分圧縮を行って通信データ量を削減することで、広域ネットワークのボトルネックを解消する。
【００２７】
図２に、本発明を適用するコンピュータ・ネットワークシステムの別の構成例を示す。この構成例では、企業内の業務アプリケーションセンター内のＬＡＮ１１０とノートＰＣ等の携帯クライアント１１６との間が、インターネットや専用回線等の広域ネットワークＷＡＮ１１３と携帯電話やＰＨＳ等の無線ネットワーク１１５とを介して接続されており、業務アプリケーションセンター内のＬＡＮ１１０に接続されたサーバー１１１と、クライアントＰＣ１１６とが、無線ネットワーク１１５、ＷＡＮ１１３、ＬＡＮ１１０を介して通信可能となっている。業務アプリケーションのＬＡＮ１１０には１又は複数のサーバーが接続され、ＷＡＮ１１３や無線ネットワーク１１５を介して１又は複数のクライアントが接続される。
【００２８】
Ｗｅｂベースの業務アプリケーションセンターのＬＡＮ１１０に設置されたサーバー１１１からＷＡＮ１０３を介して、様々な企業内定型業務アプリケーションプログラムや業務用アプリケーションプログラムによる様々なサービスを提供し、ユーザーはクライアント１１６上のＷｅｂブラウザ１１８を使ってそれらサービスにアクセスする。
【００２９】
このような利用形態においては、業務アプリケーションセンターのＬＡＮ１１０とクライアント１１６を繋ぐネットワーク、特にインターネットなどの広域ネットワーク１１３や無線ネットワーク１１５のバンド幅は業務アプリケーションセンターのＬＡＮ１１０よりも低く、そこがボトルネックになることで、アプリケーションのレスポンスタイムが低下するという問題が発生する。
【００３０】
そこで、本実施形態では、図２に示すように業務アプリケーションセンターのＬＡＮ１１０とクライアント１１６とを繋ぐＷＡＮ１１３と無線ネットワーク１１５の両端にサーバー側プロキシ１１２とクライアント１１６上にクライアント側モジュール１１７という二つのモジュールを設置し、それらの間で後述する差分圧縮を行って通信データ量を削減することで、ボトルネックを解消する。
【００３１】
ただし、図１の構成例では、サーバー側装置はサーバー側プロキシ、クライアント側装置はクライアント側プロキシとして実現されているが、これに限定されるものではない。また、図２の構成例では、サーバー側装置はサーバー側プロキシ、クライアント側装置はアプリケーションとして実現されているが、これに限定されるものではない。また、サーバー側装置及びクライアント側装置が、それぞれ、サーバー側システムを構成するコンポーネント及びクライアント側システムを構成するコンポーネントとして実現されていれば、その実現形態は問わない。
【００３２】
次に、図３を参照しながら差分圧縮処理及び差分伸長処理について説明する。
【００３３】
図１及び図２の構成例の場合、図１のサーバー側プロキシ１０５及び図２のサーバー側プロキシ１１２がそれぞれ図３のサーバー側装置２００に相当し、図１のクライアント側プロキシ１０２及び図２のクライアント側モジュール１１７がそれぞれ図３のクライアント側装置２０７に相当する。
【００３４】
サーバー側装置２００には直接またはネットワーク経由で接続されたキャッシュ２０５が、クライアント側装置２０７には直接またはネットワーク経由で接続されたキャッシュ２１２が設置されている。サーバー側装置２００のキャッシュ２０５には、以前Ｗｅｂブラウザを備えたクライアントからＧＥＴメソッドなどのＨＴＴＰリクエストに対してＷｅｂサーバーがＨＴＴＰレスポンスとして転送したコンテンツＡ２０３とコンテンツＢ２０４が保存されているものとする。コンテンツＡ２０３にはコンテンツＡであることをユニークに識別できる識別子Ａが、コンテンツＢ２０４にはコンテンツＢであることをユニークに識別できる識別子Ｂが割り振られている。
【００３５】
なお、この識別子は、コンテンツ自体をユニークに識別するものであればどのようなものであってもよい。例えば、取得した順に昇順に番号を付けたものでもよいし、ＭＤ５やＳＨＡ−１等に代表されるハッシュ関数を用いて算出したものであってもよい。
【００３６】
サーバー側装置２００のキャッシュ２０５にはコンテンツＡを識別子Ａと一対一の関係付けで保存してあり、同様に、コンテンツＢを識別子Ｂと一対一の関係付けで保存してある。他方、クライアント側装置２０７のキャッシュ２１２には、同様に、識別子ＡとコンテンツＡ２１０が一対一の関係付けで、識別子ＢとコンテンツＢ２１１が一対一の関係付けで保存されている。クライアント側装置２０７では、サーバー側装置２００と同じアルゴリズムで各コンテンツに識別子を取得しても良いし、サーバー側装置２００から転送されてくるコンテンツＡのＨＴＴＰレスポンスのヘッダーに付加された識別子から識別子を取得しても良い。
【００３７】
上記ＨＴＴＰレスポンスのヘッダーに付加される場合のＨＴＴＰレスポンスの例を図４に示す。図４中、Ｘ−Ｉｄｅｎｔｉｆｉｅｒヘッダーをサーバー側装置２００がＨＴＴＰレスポンスヘッダーに付加しクライアント側装置２０７に送信し、該当レスポンスをクライアント側装置２０７が受信するとともにＸ−Ｉｄｅｎｔｉｆｉｅｒヘッダーの値を取得することでコンテンツＡの識別子Ａを取得する。なお、クライアント側装置２０７は、コンテンツＡを下流に送信する際にＸ−Ｉｄｅｎｔｉｆｉｅｒヘッダーを削除しておくことが望ましい。
【００３８】
上記のような手順を踏むことで、クライアント側装置２０７でコンテンツＡ２１０と識別子Ａとを一対一に関係付けて、コンテンツＢ２１１と識別子Ｂとを一対一に関係付けてキャッシュ２１２に保存することが可能となる。
【００３９】
以下、上述した状態に置かれたサーバー側装置２００及びクライアント側装置２０７を前提に、図３に示した処理の流れを参照しながら、差分圧縮処理及び差分伸長処理の概要について説明する。
【００４０】
（１）サーバー側装置２００が上流から新たなコンテンツＣ２０１を受信する。コンテンツＣ２０１の識別子はＣとする。
【００４１】
（２）コンテンツＣ２０１は差分圧縮処理に掛けられる。その際、キャッシュ２０５にキャッシュされているコンテンツＡ２０３の部分２０３３とコンテンツＢ２０４の部分２０４１が、それぞれ、コンテンツＣの部分２０２３と部分２０２１に一致していたとする。また、コンテンツＣ２０２の部分２０２２はキャッシュ２０５に保存されているどのコンテンツとも同じ部分がなかったとする。
【００４２】
（３）差分圧縮の結果、差分データ２０６が生成される。差分データ２０６の中身は、部分２０２１と同等な識別子Ｂの先頭からのオフセットバイト及び長さ、部分２０２２のそのままの内容（オリジナル）、部分２０２３と同等な識別子Ａの先頭からのオフセット及び長さの３要素で構成される。生成された差分データ２０６はクライアント側装置２０７に転送される。
【００４３】
（４）また、（２）及び（３）と相前後して、コンテンツＣ２０１は、識別子Ｃと伴に次回以降の差分圧縮に用いるために、キャッシュ２０５にキャッシュされる。
【００４４】
（５）クライアント側装置２０７は差分データ２０６を受信する。
【００４５】
（６）差分データ２０６は差分伸長処理にかけられる。その際、差分データ２０６に埋め込まれている識別子Ｂのコンテンツ２１１をキャッシュ２１２から取得し、オフセット及び長さ情報から部分２１１１を取り出す。また、差分データ２０６に埋め込まれているそのままの部分を取り出す。また、差分データ２０６に埋め込まれている識別子Ａのコンテンツ２１０をキャッシュ２１２から取得し、オフセット及び長さ情報から部分２１１１を取り出す。最終的に、差分データ２０６は、コンテンツＢ２１１の部分２１１１に相当する部分２０８１、そのままの部分２０８２、コンテンツＡ２１０の部分２１０３に相当する部分２０８３を結合したコンテンツ２０８が生成される。
【００４６】
（７）コンテンツ２０８は、ＨＴＴＰヘッダーでサーバー側装置２００によって指定された識別子Ｃが与えられ、識別子ＣのコンテンツＣ２０９となる。コンテンツＣ２０９は下流に送信される。
【００４７】
（８）コンテンツＣ２０９は、次回以降の差分伸長に用いるために、識別子Ｃと伴にキャッシュ２１２にキャッシュされる。
【００４８】
なお、キャッシュにあるコンテンツとまったく同じコンテンツを受信した際には、差分圧縮処理でキャッシュ済みコンテンツの識別子とオフセットを０、長さをそのコンテンツのサイズという差分データで表現することになる。
【００４９】
上記処理（３）でサーバー側装置２００から送信される差分データのレスポンスをＨＴＴＰプロトコルに従って示すと、図５のようになる。
【００５０】
図５中、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｏｃｔｅｔ−ｓｔｒｅａｍ／ｘ−ｄｉｆｆ−ｃｏｍｐｒｅｓｓｉｏｎヘッダーは、ボディが差分圧縮されたデータであることを示している。クライアント側装置２０７は、本ヘッダーをみてレスポンスのボディが差分データであることを識別する。
【００５１】
また、Ｘ−Ｉｄｅｎｔｉｆｉｅｒ：識別子Ｃヘッダーは、差分復元後のコンテンツに対して付与される識別子であるが、クライアント側装置２０７がサーバー側装置２００と同じアルゴリズムで識別子を取得できる場合は不要となる。
【００５２】
Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ，ｘ−ｄｉｆｆヘッダーは、サーバー側装置２００とクライアント側装置２０７との間にあるキャッシングプロキシなどによって差分データがキャッシュされないように、ＨＴＴＰプロトコルに従ってサーバー側装置が付けたヘッダーである。Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ，ｘ−ｄｉｆｆヘッダーも同様である。
【００５３】
また、Ｘ−Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ、Ｘ−Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅは、それそれ、復元後のコンテンツに付加されるべきＰｒａｇｍａ、Ｃａｃｈｅ−Ｃｏｎｔｒｏｌヘッダーである。これらは、サーバー側装置２００で差分圧縮前にコンテンツに対して付加されていたＨＴＴＰヘッダーを退避させたものである。なお、クライアント側装置２０７では、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダーの値（ＭＩＭＥ／ＴＹＰＥ）を元のコンテンツの値に修正し、Ｘ−Ｉｄｅｎｔｉｆｉｅｒヘッダーを削除し、ＰｒａｇｍａへッダーとＣａｃｈｅ−Ｃｏｎｔｒｏｌヘッダーを削除し、Ｘ−Ｐｒａｇｍａヘッダーの値をＰｒａｇｍａヘッダーに付け替え、Ｘ−Ｃａｃｈｅ−Ｃｏｎｔｒｏｌヘッダーの値をＣａｃｈｅ−Ｃｏｎｔｒｏｌヘッダーの値に付け替える処理を行うものとする。
【００５４】
図３に示されているサーバー側装置２００とクライアント側装置２０７を機能別ブロック図に示したのがそれぞれ図６と図７である。
【００５５】
図６に示されるように、サーバー側装置３００は、データの送受信を行う通信部３０１、差分圧縮処理を行う差分圧縮部３０２、差分圧縮前のコンテンツをサーバー側キャッシュ保持部に保存するサーバー側登録部３０３から構成される。
【００５６】
他方、図７に示されるように、クライアント側装置３０５は、データの送受信を行う通信部３０６、差分伸長処理を行う差分復元部３０７、復元後のコンテンツをクライアント側キャッシュ保持部３０９に保存するクライアント側登録部３０８から構成される。
【００５７】
ここで、図６のサーバー側装置３００、サーバー側キャッシュ保持部３０４、図７のクライアント側装置３０５、クライアント側キャッシュ保持部３０９は、それぞれ、図３のサーバー側装置２００、キャッシュ２０５、クライアント側装置２０７、キャッシュ２１２に相当する。
【００５８】
以上、差分圧縮処理及び差分伸長処理の概要について説明したが、ＨＴＴＰヘッダーの構成や差分データのフォーマットは、上記に説明したことと同じことを実現できるものであればどのようなものであっても良い。
【００５９】
ところで、従来、動的コンテンツに対して差分をとるサーバー側装置及びクライアント側装置のキャッシュの削除方法として相応しいアルゴリズムが知られていなかった。そこで、以下では、キャッシュ削除方法の幾つかの具体例を示す。
【００６０】
まず、図８を参照しながらキャッシュ削除方法の一例について説明する。
【００６１】
図８に示したヒストグラム（４００）は、縦軸にキャッシュされたコンテンツのサイズ、横軸に差分圧縮時に取得された差分データの圧縮率をとったものであり、サーバー側装置及びクライアント装置の主記憶装置（メモリ）に置かれるものとする。圧縮率は、例えば、圧縮前のコンテンツサイズをＳ、圧縮後の差分データのサイズをΔＳとすると、式（１）  
圧縮率＝１００×（１−ΔＳ／Ｓ）                                  （１）  
で算出される（この例では、圧縮後の差分データ・サイズΔＳが小さくなるほど、圧縮率は大きくなる）。
【００６２】
図９に、上記ヒストグラム（４００）への登録処理手順の一例を示す。まず、コンテンツの識別子とサイズと圧縮率を取得する（ステップＳ１）。追加するとリストにあるコンテンツの総サイズがキャッシュ可能サイズを超えない場合（ステップＳ２）、ＣＲ＝（ｉｎｔ）（（圧縮率／１０）×１０）によりＣＲを計算（正規化）する（ステップＳ４）。他方、追加するとリストにあるコンテンツの総サイズがキャッシュ可能サイズを超える場合（ステップＳ２）、削除処理を実行（ステップＳ３）した後に、ＣＲを計算（正規化）する（ステップＳ４）。そして、ＣＲ％〜（ＣＲ＋１０）％に対応するグリッドに登録する（ステップＳ５）。
【００６３】
図１０に、上記ヒストグラム（４００）及びキャッシュからの削除処理手順の一例を示す。まず、削除していないグリッドで最も圧縮率の高いグリッドに属するコンテンツを全て削除する（ステップＳ１１）。キャッシュサイズが８０％以下ならば（ステップＳ１２）、処理を終了する。他方、キャッシュサイズが８０％を越えているならば（ステップＳ１２）、さらに、削除していないグリッドで最も圧縮率の高いグリッドに属するコンテンツを全て削除する（ステップＳ１１）。以上の処理を、キャッシュサイズが８０％以下になるまで、繰り返し実行する。
【００６４】
さて、図８の具体例において、時系列に取得したコンテンツを並べると、Ａ，Ｂ，Ｃ，Ｄ，…，Ｍ，Ｎ，Ｏであったとする。なお、Ａ，Ｂ，Ｃ等は、各コンテンツの識別子とする。各コンテンツの差分圧縮前のサイズと差分圧縮後のサイズとから式（１）によって圧縮率が算出される。その際、各コンテンツの圧縮率を横軸に（ただし、図８の例では、横軸のグリッド幅を１０％であるとする。）、各コンテンツのサイズを縦軸にした図８の構成のヒストグラム（４００）に、図９に示した登録手順で登録すると、図８に例示した状態になったものとする。すなわち、コンテンツＡの圧縮率は０〜１０％の間であり、コンテンツＢの圧縮率は２０〜３０％の間であり、コンテンツＣの圧縮率は６０〜７０％間である等となる。
【００６５】
しかして、図８に例示した状態において、新たにコンテンツＰを取得しその圧縮率をｐとしたとき、図９の処理フローでキャッシュされたコンテンツの総サイズがキャッシュ容量を超えたものとする。この場合、図９の削除処理（ステップＳ３）が実行され、図１０に示した削除処理フローに従って、既にキャッシュ済みのコンテンツにつき、総サイズが予め定められた基準値以下になるまで、圧縮率の高いものを優先して削除する（なお、図１０では、一例として、この基準値をキャッシュ容量の８０％としている。）。
【００６６】
なお、予め定められた基準値は、例えば、キャッシュ容量の８０％などであるが、これに限定されるものではなく、キャッシュ容量に対する他の比率でもよいし、キャッシュ容量とは関係なく決定される値であってもよい。ただし、キャッシュされたコンテンツを削除しすぎると差分圧縮に使えるコンテンツが減り差分圧縮効果が下がり、残しすぎても本削除処理が頻発し性能上の問題となるので、妥当な値を用いる必要がある。
【００６７】
図９に関して処理フローに従って例を挙げると、例えば、新たに取得したコンテンツＰが圧縮率３２．４％のコンテンツであった場合、図９のＣＲの計算によって、ＣＲ＝（ｉｎｔ）（（３２．４／１０）×１０）＝（ｉｎｔ）（３×１０）＝３０となり、圧縮率３０％〜４０％に対応するグリッドに登録される。
【００６８】
上記具体例の場合、圧縮率が６０〜７０％の間にあるコンテンツＣと圧縮率が５０〜６０％の間にあるコンテンツＯ、Ｌ、Ｉを削除するとキャッシュされているコンテンツの総サイズが８０％以下になったものとする。キャッシュの総サイズは、圧縮率の高いグリッドから順に、そのグリッドに含まれるコンテンツを全て削除する度に計算する。本具体例では、圧縮率５０％〜６０％に対応するグリッド（４０１）に含まれるコンテンツＯ、Ｌ、Ｉを削除した後にまだキャッシュに残っているコンテンツの総サイズがキャッシュ容量の８０％以下になったため、圧縮率４０％〜５０％に対応するグリッド（４０２）の削除は行われなかった。また、コンテンツＰは圧縮率ｐの値とサイズによって、ヒストグラムの適切なグリッドに登録されるとともに、キャッシュされる。
【００６９】
なお、本具体例では、ヒストグラムを用いてグリッド幅を１０％、削除する際にキャッシュ容量に対して削除後にキャッシュに残るコンテンツの総サイズをキャッシュ容量の８０％という値を用いたが、これらに限定されるものではなく、圧縮率の高いものを優先的に削除するものであればどのような形態でも良い。
【００７０】
次に、図１１を参照しながら動的コンテンツに対するキャッシュ削除方法の他の例について説明する。
【００７１】
図１１の具体例において、時系列に取得したコンテンツを並べると、（先の例と同様）Ａ，Ｂ，Ｃ，Ｄ，…，Ｍ，Ｎ，Ｏであったとする。図１１は、メモリ上に設置されるヘッドとテイルを持つ双方向連結リスト（４５０）によって、キャッシュ済みコンテンツのうち圧縮率の高いものから順に削除する方法を示している。図１１のリストヘッド（４５１）から圧縮率の低いコンテンツを順にその識別子とサイズと圧縮率がリストの要素として連結リスト（４５０）に登録されている。例えば、識別子Ａのコンテンツは識別子Ａ・サイズ１００２３（Ｂｙｔｅｓ）・圧縮率０．０％として要素４５２に登録されている。同様に、既にキャッシュ済みのコンテンツ全てについて圧縮率の低い順にリストヘッド（４５１）からリストテイル（４６２）までの間に登録されている。
【００７２】
図１２に、上記連結リスト（４５０）にキャッシュするコンテンツを登録する際の処理手順の一例を示す。まず、識別子とサイズと圧縮率を取得する（ステップＳ２１）。追加するとリストにあるコンテンツの総サイズがキャッシュ可能サイズを超えない場合（ステップＳ２）、ステップＳ２４に進む。他方、追加するとリストにあるコンテンツの総サイズがキャッシュ可能サイズを超える場合（ステップＳ２２）、削除処理を実行（ステップＳ２３）した後に、ステップＳ２４に進む。ステップＳ２４において圧縮率が５０％以上ならば、リストテイルから検索開始し（ステップＳ２５）、リストをたどって自分のサイズ以下の要素を探し（ステップＳ２６）、該当要素の直後の要素として登録する（ステップＳ２７）。他方、ステップＳ２４において圧縮率が５０％を超えているならば、リストヘッドから検索開始し（ステップＳ２８）、リストをたどって自分のサイズ以上の要素を探し（ステップＳ２９）、該当要素の直前の要素として登録する（ステップＳ３０）。
【００７３】
図１３に、上記ヒストグラム（４００）及びキャッシュからの削除処理手順の一例を示す。まず、リストテイルから開始し（ステップＳ３１）、前の要素へたどり（ステップＳ３２）、要素を削除する（ステップＳ３３）。ここで、キャッシュに残っているコンテンツの総サイズが８０％以下ならば（ステップＳ３４）、処理を終了する。他方、キャッシュに残っているコンテンツの総サイズが８０％を越えているならば（ステップＳ３４）、さらに、要素を削除する（ステップＳ３３）。以上の処理を、キャッシュに残っているコンテンツの総サイズが８０％以下になるまで、繰り返し実行する。
【００７４】
さて、図１２に示された登録手順に従ってコンテンツを登録することによって、図１１に示されている状態ができたものとする。ただし、図１１の状態では、まだ、図１２に示されている削除処理（ステップＳ２３）は行われていないものとする。
【００７５】
図１１で新たにコンテンツを取得し連結リストに登録しようとする際、図１２の手順によると、そのコンテンツの識別子Ｐとサイズ７６３４と圧縮率１８．５の要素を登録しようとした場合、キャッシュ済みのコンテンツの総サイズがキャッシュ可能サイズを超えるので、削除処理（ステップＳ２３）を実行することになる。削除処理では、リストテイルから順にすなわち圧縮率の高いものから順に、要素を削除し、キャッシュに残っているコンテンツのサイズの総和が予め定められた基準値以下になったら、この削除処理は終了する。そして、引き続き、図１２の残りの部分を実行し、一連の処理が終了する（なお、図１３では、一例として、この基準値をキャッシュ容量の８０％としている）。図１１では、上記処理の結果、識別子Ｃ、Ｉ、Ｏ、Ｌが削除された場合を示している。
【００７６】
なお、本具体例では、連結リスト用いて、削除する際にキャッシュ容量に対して削除後にキャッシュに残るコンテンツの総サイズをキャッシュ容量の８０％という値を用いたが、これに限定されるものではなく、圧縮率の高いものを優先的に削除するものであればどのような形態でも良い。
【００７７】
上記に二つ例を示したが、このように圧縮率の高いものを優先的に削除すると、動的コンテンツに対して差分をとる場合に、重複のある無駄なコンテンツがキャッシュから削除されることになる。なぜなら、もしあるコンテンツαを取得した際にそのコンテンツを差分圧縮するのに十分なコンテンツが１つないしは複数が既にキャッシュにあった場合、新たに取得したコンテンツαは既にキャッシュにあるコンテンツによって圧縮され、圧縮率が高くなる。さらに、コンテンツαと非常に似たコンテンツα´を取得したとしてもコンテンツαの場合と同様に既にキャッシュにある１つないし複数のコンテンツによって十分に圧縮することができるため、コンテンツαとα´をキャッシュに残しておく必要がないためである。
【００７８】
次に、図１４及び図１５に、上述の削除方法を実現するために必要な機能ブロックを示す。図１４及び図１５には、サーバー側装置５００及びクライアント側装置５２０それぞれの機能ブロックを示してある。
【００７９】
サーバー側装置５００には、下流からＨＴＴＰリクエストを受信し上流に該当ＨＴＴＰリクエストを送信したり、上流からＨＴＴＰレスポンスを受信し下流に差分データ等のＨＴＴＰレスポンスを送信したりする通信部５０１が備えられている。
【００８０】
サーバー側装置５００は、上流からＨＴＴＰレスポンスを受信すると、差分圧縮処理（図３中の丸数字３で示される部分参照）を差分圧縮部５０２で行い、通信部５０１を介して下流に差分圧縮データを送信すると伴に、サーバー側登録部５０５によってサーバー側キャッシュ保持部５０３に差分圧縮前のコンテンツをキャッシュする。同時に、サーバー側圧縮率計算部５０６が、差分圧縮部５０２から取得した差分データのサイズと通信部５０１から取得した差分圧縮前のコンテンツサイズとから式（１）を用いて圧縮率を計算するとともに、サーバー側サイズ取得部５０９が、通信部５０１から差分圧縮前のコンテンツのサイズを取得し、サーバー側サイズ・圧縮率保持部５０７に登録する。
【００８１】
サーバー側サイズ・圧縮率保持部５０７は、図８ではヒストグラム（４００）が該当し、図１１では双方向連結リスト（４５０）が該当する。
【００８２】
サーバー側サイズ・圧縮率保持部５０７が保持するキャッシュ済みコンテンツの総サイズが、サーバー側キャッシュ可能サイズ保持部５１０から取得したキャッシュ可能サイズ（通常はユーザーが設定した値）を超えた場合、サーバー側削除判定部５０８によって１つないしは複数の削除対象コンテンツを検出し、サーバー側削除判定部５０４によってサーバー側キャッシュ保持部５０３から該当削除対象コンテンツを削除する。
【００８３】
サーバー側削除判定部５０８は、図８で説明した形態では図１０に示した処理フローが該当し、図１１で説明した形態では図１３に示した処理フローが該当する。
【００８４】
クライアント側装置５２０には、下流からＨＴＴＰリクエストを受信し上流に該当ＨＴＴＰリクエストを送信したり、上流からＨＴＴＰレスポンスを受信し下流に差分データ等のＨＴＴＰレスポンスを送信したりする通信部５２１が備えられている。
【００８５】
クライアント側装置５２０は、上流から差分圧縮データを含むのＨＴＴＰレスポンスを受信すると、差分伸長処理（図３中の丸数字６で示される部分参照）を差分伸長部５２２で行い、通信部５２１を介して下流に伸長後のコンテンツを送信すると伴に、クライアント側登録部５２５によってクライアント側キャッシュ保持部５２３に差分伸長後のコンテンツをキャッシュする。同時に、クライアント側圧縮率計算部５２６が、通信部５２１から取得した差分データのサイズと差分伸長部５２２から取得した差分伸長後のサイズとから式（１）を用いて圧縮率を計算するとともに、クライアント側サイズ取得部５２９が、差分伸長部５２２から取得した差分伸長後のコンテンツのサイズを取得し、クライアント側サイズ・圧縮率保持部５２７に登録する。
【００８６】
クライアント側サイズ・圧縮率保持部５２７は、図８ではヒストグラム（４００）が該当し、図１１では双方向連結リスト（４５０）が該当する。
【００８７】
クライアント側サイズ・圧縮率保持部５２７が保持するキャッシュ済みコンテンツの総サイズが、クライアント側キャッシュ可能サイズ保持部５３０から取得したキャッシュ可能サイズ（通常はユーザーが設定した値）を超えた場合、クライアント側削除判定部５２８によって１つないしは複数の削除対象コンテンツを検出し、クライアント側削除判定部５２４によってクライアント側キャッシュ保持部５２３から該当削除対象コンテンツを削除する。
【００８８】
クライアント側削除判定部５２８は、図８で説明した形態では図１０に示した処理フローが該当し、図１１で説明した形態では図１３に示した処理フローが該当する。
【００８９】
上述した構成例では、キャッシュの削除方法は、サーバー側装置、クライアント側装置が独立して行っていたものである。しかし、クライアント側装置がＰＤＡ(Personal Digital Assistants)や携帯電話等の小型形態端末であって、メモリ上にキャッシュ領域がとられる場合もある。この場合、図１５に示したクライアント側キャッシュ保持部５２３とクライアント側サイズ・圧縮率保持部５２７の両方をメモリ上に設置する必要があり、クライアント側キャッシュ保持部５２３のサイズと図１４に示したサーバー側キャッシュ保持部５０３のサイズとが極端に異なることになる。また、システムパフォーマンスの低い小型携帯端末で、クライアント側削除判定部５２７によって削除対象を決定する必要があるため、処理の量の観点からクライアント側装置で上記判定を行いたくない場合がある。
【００９０】
そこで、以下では、サーバー側装置とクライアント装置との間で連携して上記キャッシュ領域サイズの違いとクライアント側装置の処理量の削減を実現する方法の一例について説明する。
【００９１】
図１６及び図１７は、サーバー側装置６００とクライアント側装置６２０それぞれの機能ブロックを示した図である。クライアント側装置６２０はＰＤＡや携帯端末等の小型携帯端末である。
【００９２】
クライアント側装置６２０は、図１５に示したクライアント側サイズ・圧縮率保持部５２７、クライアント側圧縮率計算部５２６、クライアント側削除判定部５２８が省かれている。クライアント側サイズ・圧縮率保持部５２７が省かれているためメモリ使用量が削減され、クライアント側圧縮率計算部５２６、クライアント側削除判定部５２８が省かれているため処理量が削減されている。一方、図１７で新たに追加された機能として、クライアント側キャッシュ可能サイズ通知部６２７、クライアント側削除通知取得部６２６がある。また、サーバー側装置６００は、サーバー側キャッシュ可能サイズ保持部５１０の代わりにキャッシュ可能サイズ保持部６１０、クライアント側キャッシュ可能サイズ取得部６１２、サーバー側削除通知部６１１が追加されている。
【００９３】
まず、予め、クライアント側装置６２０が、クライアント側のキャッシュ可能サイズを、クライアント側キャッシュ可能サイズ通知部６２７によって通信部６２１を介してサーバー側装置６００に送信する。
【００９４】
サーバー側装置６００は、通信部６０１で受信したクライアント側キャッシュ可能サイズを、クライアント側キャッシュ可能サイズ取得部６１２によって取得する。サーバー側キャッシュ可能サイズとクライアント側キャッシュ可能サイズとを比較してより小さい値を、キャッシュ可能サイズ保持部６１０に登録する。ここでは、クライアント側装置６２０のキャッシュ可能サイズが明らかに小さく、クライアント側キャッシュ可能サイズがキャッシュ可能サイズ保持部６１０に登録されることになる。
【００９５】
クライアント側装置６２０のクライアント側キャッシュ可能サイズ通知部６２７から通信部６２１とサーバー側装置６００の通信部６０１を介してクライアント側キャッシュ可能サイズ取得部６１２に通知されるクライアント側キャッシュ可能サイズは、例えば、図１８に示すようにＨＴＴＰ１．１のＯＰＴＩＯＮＳメソッドを用いて実現可能である。図１８のリクエストヘッダーを、クライアント側装置６２０のキャッシュ可能サイズが３２（ＭＢｙｔｅｓ）であることをＸ−Ｃａｃｈｅ−Ｓｉｚｅヘッダーを用いてサーバー側装置６００（ホスト名：ｈｏｇｅｈｏｇｅ．○○○．ｃｏ．ｊｐ）に対して通知するために、送信する。また、レスポンスヘッダーは、サーバー側装置６００が該当リクエストからクライアント側キャッシュ可能サイズを正常に受け取った旨を通知するために、クライアント側装置６２０に対して送信する。ただし、上記のようにＨＴＴＰを利用するのではなく、他のプロトコルや人の手によって設定されてもよく、その形態は問わない。
【００９６】
上述のようにして予めサーバー側装置６００は、クライアント側装置６２０のキャッシュ可能サイズを取得し、キャッシュ可能サイズ保持部６１０の値を決定しておく。
【００９７】
サーバー側装置６００には、下流からＨＴＴＰリクエストを受信し上流に該当ＨＴＴＰリクエストを送信したり、上流からＨＴＴＰレスポンスを受信し下流に差分データ等のＨＴＴＰレスポンスを送信したりする通信部６０１が備えられている。
【００９８】
サーバー側装置６００は、上流からＨＴＴＰレスポンスを受信すると、差分圧縮処理（図３中の丸数字３で示される部分参照）を差分圧縮部６０２で行い、通信部６０１を介して下流に差分圧縮データを送信すると伴に、サーバー側登録部６０５によってサーバー側キャッシュ保持部６０３に差分圧縮前のコンテンツをキャッシュする。同時に、サーバー側圧縮率計算部６０６が、差分圧縮部６０２から取得した差分データのサイズと通信部６０１から取得した差分圧縮前のコンテンツサイズから式（１）を用いて圧縮率を計算するとともに、サーバー側サイズ取得部６０９が、通信部６０１から差分圧縮前のコンテンツのサイズを取得し、サーバー側サイズ・圧縮率保持部６０７に登録する。
【００９９】
サーバー側サイズ・圧縮率保持部６０７は、図８ではヒストグラム（４００）が該当し、図１１では双方向連結リスト（４５０）が該当する。
【０１００】
サーバー側サイズ・圧縮率保持部６０７が保持するキャッシュ済みコンテンツの総サイズが、キャッシュ可能サイズ保持部６１０から取得したキャッシュ可能サイズを超えた場合、サーバー側削除判定部６０８によって１つないしは複数の削除対象コンテンツを検出し、サーバー側削除判定部６０４によってサーバー側キャッシュ保持部６０３から該当削除対象コンテンツを削除するとともに、サーバー側削除通知部６１１によって削除対象コンテンツを通信部６０１を介してクライアント側装置６００に送信する。ただし、削除対象コンテンツは、差分データをクライアント側装置６２０に送信する際に、レスポンスヘッダーの一部として通知する。
【０１０１】
なお、サーバー側削除判定部６０８は、図８で説明した形態では図１０に示した処理フローが該当し、図１１で説明した形態では図１３に示した処理フローが該当する。
【０１０２】
クライアント側装置６２０は、サーバー側装置６００から送信されてきた差分データと削除対象コンテンツを含むレスポンスとを通信部６２１によって受信する。差分伸長部６２２は、該当レスポンスが差分データであることを判定し、差分伸長処理を行う。伸長処理が終わり復元されたコンテンツは、通信部６２１を介して下流に送信されるとともに、クライアント側登録部６２５によってクライアント側キャッシュ保持部６２３に保存される。また、クライアント側削除通知取得部６２６は、レスポンスヘッダーに削除対象コンテンツがあると、指定された識別子のコンテンツをクライアント側削除部６２４によってクライアント側キャッシュ保持部６２３から削除する。
【０１０３】
図１９に、上記差分データと削除対象コンテンツを指定したＨＴＴＰレスポンスの一例を示す。図１９では、削除対象コンテンツの識別子が図８又は図１１の例で示されたＣ，Ｏ，Ｌ，Ｉであった場合であり、Ｘ−Ｐｕｒｇｅ−Ｉｄｅｎｔｉｆｉｅｒヘッダーにその識別子を指定することで、クライアント側装置６２０は、クライアント側削除通知取得部６２６によって削除対象コンテンツがＣ，Ｏ，Ｌ，Ｉであることを判別し、クライアント側削除部６２４によってクライアント側キャッシュ保持部６２３から削除する。
【０１０４】
このようにして、キャッシュ可能サイズの明らかに異なるサーバー側装置とクライアント側装置を連携することで、クライアント側装置の処理量を軽減するとともに、キャッシュされているコンテンツの不一致による差分伸長処理の失敗がなくなり、よりサーバー側装置とクライアント側装置との間を流れるデータ転送量を削減することができる。
【０１０５】
なお、上記では、差分データのレスポンスヘッダーの一部として削除対象コンテンツを指定したが、もちろん、他のプロトコルを用いて別途クライアント側装置に通知しても良い。
【０１０６】
ところで、図１４及び図１５に示した構成例によって動的コンテンツのキャッシュを削除するのに有効な削除方法を示したが、この場合、キャッシュを削除した後にも引き続いて差分圧縮対象となったコンテンツがその圧縮率に関わらず新たにキャッシュされていく。もし既にキャッシュにある１つないし複数のコンテンツによって十分圧縮されるコンテンツを新たに取得した場合、圧縮率が高くなる。その場合、キャッシュに登録する前に圧縮率によってキャッシュに登録するのかしないのかを判定することでより、効率よく動的コンテンツをキャッシュすることが可能となる。
【０１０７】
この判定には、ある圧縮率の閾値が必要になるが、この閾値は、例えば、図８又は図１１の構成により取得することができる。図８においては、例えば、図１０の削除処理フローでキャッシュサイズが８０％以下になった際のグリッドの最小値を閾値Ｔとする。図８の具体例の場合、Ｔ＝５０という値が取得できる（図８の閾値Ｔ（４０３））。また、図１１においては、例えば、図１３の削除処理フローでキャッシュサイズが８０％以下になった際に削除した最後の要素のコンテンツの圧縮率を閾値Ｔとする。図８の具体例の場合、Ｔ＝５４．５（図１１の閾値Ｔ（４６４））という値が取得できる。
【０１０８】
この閾値Ｔは、削除処理が行われるたびに上記方法によって更新される。初回の削除処理が行われる前のＴの初期値は１００％が望ましいが、これに限定されるものではない。
【０１０９】
以下では、動的コンテンツの登録判定方法の一例について説明する。
【０１１０】
図２０に、上記のようにして取得した閾値Ｔを用いてキャッシュに登録するかどうかを判定する処理手順の一例を示す。まず、圧縮率を取得する（ステップＳ４１）。圧縮率がＴ以下ならば（ステップＳ４２）、登録する（ステップＳ４３）。他方、圧縮率がＴを越えているならば（ステップＳ４２）、登録しないものとする（ステップＳ４４）。
【０１１１】
また、図２１に、図２０に示した圧縮率の閾値による判定部を入れた場合のサーバー側装置の機能ブロックを示す。図１４と比較して、新たにサーバー側登録判定部７１１が新規に追加されている。
【０１１２】
図２１における一連の処理フローは次のようになる。
【０１１３】
サーバー側装置７００には、下流からＨＴＴＰリクエストを受信し上流に該当ＨＴＴＰリクエストを送信したり、上流からＨＴＴＰレスポンスを受信し下流に差分データ等のＨＴＴＰレスポンスを送信したりする通信部７０１が備えられている。
【０１１４】
サーバー側装置７００は、上流からＨＴＴＰレスポンスを受信すると、差分圧縮処理（図３中の丸数字３で示される部分参照）を差分圧縮部７０２で行い、通信部７０１を介して下流に差分圧縮データを送信する。続いて、サーバー側登録判定部７１１は、式（１）によって圧縮率をサーバー側圧縮率計算部７０６から取得するとともに、サーバー側削除判定部７０８からそのときの閾値Ｔを取得し、図２０に示した判定処理によって差分圧縮前のコンテンツをキャッシュするかどうかを判定する。もしサーバー側登録判定部７１１によって登録しないと判定された場合は、そこで処理が終わる。もし登録すると判定された場合は、サーバー側登録部７０５によってサーバー側キャッシュ保持部７０３に差分圧縮前のコンテンツをキャッシュする。同時に、サーバー側圧縮率計算部７０６とサーバー側サイズ取得部７０９から取得した圧縮率とサイズを、サーバー側サイズ・圧縮率保持部７０７に登録する。
【０１１５】
サーバー側サイズ・圧縮率保持部７０７は、図８ではヒストグラム（４００）が該当し、図１１では双方向連結リスト（４５０）が該当する。
【０１１６】
サーバー側サイズ・圧縮率保持部７０７が保持するキャッシュ済みコンテンツの総サイズが、サーバー側キャッシュ可能サイズ保持部７１０から取得したキャッシュ可能サイズを超えた場合、サーバー側削除判定部７０８によって１つないしは複数の削除対象コンテンツを検出し、サーバー側削除判定部７０４によってサーバー側キャッシュ保持部７０３から該当削除対象コンテンツを削除する。
【０１１７】
サーバー側削除判定部７０８は、図８で説明した形態では図１０に示した処理フローが該当し、図１１で説明した形態では図１３に示した処理フローが該当する。また、削除に際してサーバー側削除判定部５０８が閾値Ｔを再計算する。
【０１１８】
図２２に、図２０に示した圧縮率の閾値による判定部を入れた場合のクライアント側装置の機能ブロックを示す。図１５と比較して、新たにクライアント側登録判定部７３１が新規に追加されている。
【０１１９】
図２２における一連の処理フローは次のようになる。
【０１２０】
クライアント側装置７２０には、下流からＨＴＴＰリクエストを受信し上流に該当ＨＴＴＰリクエストを送信したり、上流からＨＴＴＰレスポンスを受信し下流に差分データ等のＨＴＴＰレスポンスを送信したりする通信部７２１が備えられている。
【０１２１】
クライアント側装置７２０は、上流から差分圧縮データを含むのＨＴＴＰレスポンスを受信すると、差分伸長処理（図３中の丸数字６で示される部分参照）を差分伸長部７２２で行い、通信部７２１を介して下流に伸長後のコンテンツを送信する。続いて、クライアント側登録判定部７３１は、式（１）によって圧縮率をクライアント側圧縮率計算部７２６から取得するとともに、クライアント側削除判定部７２８からそのときの閾値Ｔを取得し、図２０に示した判定処理によって差分伸長後のコンテンツをキャッシュするかどうかを判定する。もしクライアント側登録判定部７３１によって登録しないと判定された場合は、そこで処理が終わる。もし登録すると判定された場合は、クライアント側登録部７２５によってクライアント側キャッシュ保持部７２３に差分伸長後のコンテンツをキャッシュする。同時に、クライアント側圧縮率計算部７２６とクライアント側サイズ取得部７２９から圧縮率とコンテンツのサイズ取得し、クライアント側サイズ・圧縮率保持部７２７に登録する。
【０１２２】
クライアント側サイズ・圧縮率保持部７２７は、図８ではヒストグラム（４００）が該当し、図１１では双方向連結リスト（４５０）が該当する。
【０１２３】
クライアント側サイズ・圧縮率保持部７２７が保持するキャッシュ済みコンテンツの総サイズが、クライアント側キャッシュ可能サイズ保持部７３０から取得したキャッシュ可能サイズを超えた場合、クライアント側削除判定部７２８によって１つないしは複数の削除対象コンテンツを検出し、クライアント側削除判定部７２４によってクライアント側キャッシュ保持部７２３から該当削除対象コンテンツを削除する。
【０１２４】
クライアント側削除判定部７２８は、図８で説明した形態では図１０に示した処理フローが該当し、図１１で説明した形態では図１３に示した処理フローが該当する。また、削除に際してクライアント側削除判定部７０８が閾値Ｔを再計算する。
【０１２５】
図１６及び図１７で説明した圧縮率に基づくサーバー側装置によるキャッシュ削除方法に加えて、図２１及び図２２で説明した圧縮率に基づくキャッシュ登録方法を適用したものが、図２３及び図２４に示した構成例である。
【０１２６】
以下では、サーバー側装置８００が圧縮率に基づきキャッシュから削除するコンテンツの判定とキャッシュに登録するべきコンテンツの判定の両方を行い、その判定をクライアント側装置８２０に通知することで、サーバー側装置８００とクライアント側装置８２０のキャッシュを同期する方法を示す。
【０１２７】
図２３のサーバー側装置８００は、図１６のサーバー側装置６００に加えて新たにサーバー側登録判定通知部８１３を持つ。図２４のクライアント側装置は、図１７のクライアント側装置６２０に加えて新たにクライアント側登録判定通知取得部８２８を持つ。
【０１２８】
新たにコンテンツを上流からサーバー側装置８００が受け取った際に、図２０及び図２１の構成例で説明した閾値Ｔによる登録判定がサーバー側登録判定部８１４にて行われ、キャッシュに登録すると判定された場合は、サーバー側登録部８０５によってサーバー側キャッシュ保持部８０３に保存されるとともに、サーバー側登録判定部８１４はサーバー側登録判定通知部８１３にその判定を知らせ、サーバー側登録判定通知部８１３は差分データを送信する際に図２５に示すようなＨＴＴＰヘッダーをレスポンスに追加し、通信部８０１を介してレスポンスを下流に送信する。
【０１２９】
クライアント側装置８２０は、通信部８２１を介して上記レスポンスを受信すると、クライアント側登録判定通知取得部８２８が、差分伸長部８２２によって伸長されたコンテンツをキャッシュするかどうかを、図２５に示したＨＴＴＰヘッダーから判定し、キャッシュすると指定されていたら伸長後のコンテンツはクライアント側登録判定部８２５によってクライアント側キャッシュ保持部８２３に登録される。
【０１３０】
なお、キャッシュの削除に関しては図１６〜図１９で示した構成例と同様のものである。
【０１３１】
また、図２５に示した例は、Ｘ−Ｉｄｅｎｔｉｆｉｅｒヘッダーに追加された“，  ｓａｖｅ”によって、クライアント側装置８２０に伸長後のコンテンツをキャッシュするように指定している。もしサーバー側登録判定部８１４によってキャッシュしないと判定された場合は、上記“，  ｓａｖｅ”をＨＴＴＰヘッダーから削除することでクライアント側装置８２０に伸長後のコンテンツをキャッシュしないように指定する。
【０１３２】
このようにして、キャッシュの登録時にもサーバー側装置とクライアント側装置を連携することで、キャッシュされているコンテンツの不一致による差分伸長処理の失敗を回避し、よりサーバー側装置とクライアント側装置間を流れるデータ転送量を削減することができる。
【０１３３】
なお、図２５に示した例では差分データを含むＨＴＴＰレスポンスヘッダーを用いてキャッシュ対象コンテンツをサーバー側装置からクライアント側装置に通知しているが、勿論他のプロトコルなどを用いて通知しても良い。
【０１３４】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。  
また、本実施形態は、コンピュータに所定の手段を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１３５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【０１３６】
【図１】本発明の一実施形態に係るコンピュータ・ネットワークシステムの構成例を示す図
【図２】同実施形態に係るコンピュータ・ネットワークシステムの他の構成例を示す図
【図３】動的コンテンツに対する差分転送について説明するための図
【図４】サーバー側装置がクライアント側装置にコンテンツの識別子を通知するＨＴＴＰヘッダーの一例を示す図
【図５】サーバー側装置がクライアント側装置に差分データを転送する際のＨＴＴＰレスポンスの一例を示す図
【図６】同実施形態に係るサーバー側装置の構成例を示す図
【図７】同実施形態に係るクライアント側装置の構成例を示す図
【図８】同実施形態におけるキャッシュ削除方法の一例について説明するための図
【図９】図８のヒストグラムへの登録処理手順の一例を示すフローチャート
【図１０】図８のヒストグラム及びキャッシュからの削除処理手順の一例を示すフローチャート
【図１１】同実施形態におけるキャッシュ削除方法の他の例について説明するための図
【図１２】図１１の双方向連結リストへの登録処理手順の一例を示すフローチャート
【図１３】図１１の双方向連結リスト及びキャッシュからの削除処理手順の一例を示すフローチャート
【図１４】同実施形態に係るサーバー側装置の他の構成例を示す図
【図１５】同実施形態に係るクライアント側装置の他の構成例を示す図
【図１６】同実施形態に係るサーバー側装置のさらに他の構成例を示す図
【図１７】同実施形態に係るクライアント側装置のさらに他の構成例を示す図
【図１８】図１６及び図１７の構成例におけるクライアント側キャッシュ可能サイズの通知方法の一例について説明するための図
【図１９】図１６及び図１７の構成例におけるサーバー側装置がクライアント側装置に送信する差分データのＨＴＴＰレスポンスの一例を示す図
【図２０】同実施形態に係る圧縮率によるキャッシュ登録判定部の処理手順の一例を示すフローチャート
【図２１】同実施形態に係るサーバー側装置のさらに他の構成例を示す図
【図２２】同実施形態に係るクライアント側装置のさらに他の構成例を示す図
【図２３】同実施形態に係るサーバー側装置のさらに他の構成例を示す図
【図２４】同実施形態に係るクライアント側装置のさらに他の構成例を示す図
【図２５】図２３及び図２４の構成例におけるサーバー側装置がクライアント側装置に送信する差分データのＨＴＴＰレスポンスの一例を示す図
【符号の説明】
【０１３７】
１００…サーバーセンターのＬＡＮ、１０１，１１１…サーバー、１０２，１１２…サーバー側プロキシ、１０３，１１３…ＷＡＮ、１０４…クライアント側オフィスのＬＡＮ、１０５…クライアント側プロキシ、１０６，１１６…クライアント、１０７，１１８…Ｗｅｂブラウザ、１１０…業務アプリケーションセンターのＬＡＮ、１１４…アクセスポイント、１１５…無線ネットワーク、１１７…クライアント側モジュール、２００，３００，５００，６００，７００，８００…サーバー側装置、２０５…サーバー側装置のキャッシュ、２０７，３０５，５２０，６２０，７２０，８２０…クライアント側装置、２１２…クライアント側装置のキャッシュ、３０１，５０１，６０１，７０１…サーバー側装置の通信部、３０２，５０２，６０２，７０２，８０２…差分圧縮部、３０３，５０５，６０５，７０５，８０５…サーバー側登録部、３０４，５０３，６０３，７０３，８０３…サーバー側キャッシュ保持部、３０６，５２１，６２１，７２１，８２１…クライアント側装置の通信部、３０７，５２２，６２２，７２２，８２２…差分伸長部、３０８，５２５，６２５，７２５，８２５…クライアント側登録部、３０９，５２３，６２３，７２３，８２３…クライアント側キャッシュ保持部、５０４，６０４，７０４，８０４…サーバー側削除部、５０６，６０６，７０６，８０６…サーバー側圧縮率計算部、５０７，６０７，７０７，８０７…サーバー側サイズ・圧縮率保持部、５０８，６０８，７０８，８０８…サーバー側削除判定部、５０９，６０９，７０９，８０９…サーバー側サイズ取得部、５１０，７１０…サーバー側キャッシュ可能サイズ保持部、５２４，６２４，７２４，８２４…クライアント側削除部、５２６，７２６…クライアント側圧縮率計算部、５２７，７２７…クライアント側サイズ・圧縮率保持部、５２８，７２８…クライアント側削除判定部、５２９，７２９…クライアント側サイズ取得部、５３０，７３０…クライアント側キャッシュ可能サイズ保持部、６１０，８１０…キャッシュ可能サイズ保持部、６１１，８１１…サーバー側削除通知部、６１２，８１２…クライアント側キャッシュ可能サイズ取得部、６２６，８２６…クライアント側削除通知取得部、６２７，８２７…クライアント側キャッシュ可能サイズ通知部、７３１…クライアント側登録判定部、８０１…サーバー側装置通信部、８１３…サーバー側登録判定通知部、８１４…サーバー側登録判定部、８２８…クライアント側登録判定通知取得部
【図１】
2005190339.tif 000003
【図２】
2005190339.tif 000004
【図３】
2005190339.tif 000005
【図４】
2005190339.tif 000006
【図５】
2005190339.tif 000007
【図６】
2005190339.tif 000008
【図７】
2005190339.tif 000009
【図８】
2005190339.tif 000010
【図９】
2005190339.tif 000011
【図１０】
2005190339.tif 000012
【図１１】
2005190339.tif 000013
【図１２】
2005190339.tif 000014
【図１３】
2005190339.tif 000015
【図１４】
2005190339.tif 000016
【図１５】
2005190339.tif 000017
【図１６】
2005190339.tif 000018
【図１７】
2005190339.tif 000019
【図１８】
2005190339.tif 000020
【図１９】
2005190339.tif 000021
【図２０】
2005190339.tif 000022
【図２１】
2005190339.tif 000023
【図２２】
2005190339.tif 000024
【図２３】
2005190339.tif 000025
【図２４】
2005190339.tif 000026
【図２５】
2005190339.tif 000027