(57)【特許請求の範囲】
【請求項１】
クライアントとサーバの間で前記クライアントからのリクエストに対して前記サーバがレスポンスを送信する形式の通信方法において、
前記クライアントと前記サーバとに接続され、前記クライアントおよび前記サーバの間の通信を中継するプロキシシステムが、
前記サーバから取得したファイル一覧を含むレスポンスを、前記クライアントに送信し、
前記クライアントからの、前記ファイル一覧に含まれる第一のファイルを指定する第一のリクエストの受信を契機として、
前記クライアントから、前記ファイル一覧に含まれる前記第一のファイル以外の第二のファイルを指定する第二のリクエストを受信しなくても、前記ファイル一覧に含まれる、前記第二のファイルをプリフェッチするための第三のリクエストを前記サーバへ送信し、
前記サーバから、前記第三のリクエストに対するレスポンスである前記第二のファイルをプリフェッチする
ことを特徴とする通信方法。
【請求項２】
請求項１の通信方法であって、
前記プロキシシステムは、サーバ側プロキシとクライアント側プロキシとを含み、
前記プリフェッチは、前記サーバ側プロキシで行い、
前記サーバ側プロキシは、
一つ以上のファイル取得を要求する第三のリクエストを前記サーバへ送信し、
前記第三のリクエストに対するレスポンスとしてプリフェッチした一つ以上の前記第二のファイルを前記クライアント側プロキシに送信し、
前記クライアント側プロキシは、
前記サーバ側プロキシから前記一つ以上の第二のファイルを受信して保存し、
受信した前記第二のファイルの一つを取得するための前記第二のリクエストを前記クライアントから受信した場合に、保存している該当する前記第二のファイルの一つを前記クライアントに送信する
ことを特徴とする通信方法。
【請求項３】
請求項２の通信方法であって、
前記クライアント側プロキシは、
前記クライアントから前記第一のリクエストを受信した後に、前記クライアントから、前記第二のリクエストを受信した場合、
前記第二のリクエストに対するレスポンスとなるべき前記第二のファイルを前記サーバ側プロキシから受信していない場合に、前記第二リクエストを前記サーバ側プロキシに転送する
ことを特徴とする通信方法。
【請求項４】
請求項３の通信方法であって、
前記サーバ側プロキシは、
前記クライアント側プロキシから前記第二のファイルを指定する前記第二のリクエストを受信した場合に、
当該サーバ側プロキシが、前記第二のファイルを指定する前記第三のリクエストを未送信の場合に、前記第二のリクエストを前記第三のリクエストとして他のリクエストより優先的に前記サーバに送信する
ことを特徴とする通信方法。
【請求項５】
請求項１の通信方法であって、
前記プロキシシステムは、サーバ側プロキシとクライアント側プロキシとを含み、
前記クライアント側プロキシは、
一つ以上のファイル取得を要求する第三のリクエストを前記サーバ側プロキシへ送信し、
前記サーバ側プロキシは、
前記第三のリクエストを前記サーバに転送し、
前記サーバから前記第三のリクエストに対するレスポンスとして一つ以上の前記第二のファイルを受信し、
前記一つ以上の第二のファイルを前記クライアント側プロキシへ転送し、
前記クライアント側プロキシは、
前記サーバ側プロキシから前記一つ以上の第二のファイルを受信して保存し、
受信した前記第二のファイルの一つを取得するための前記第二のリクエストを前記クライアントから受信した場合に、保存している該当する前記第二のファイルの一つを前記クライアントに送信する
ことを特徴とする通信方法。
【請求項６】
請求項５の通信方法であって、
前記クライアント側プロキシは、前記第三のリクエストにより複数のファイル取得を要求する場合、
前記第三のリクエストにより複数のファイル取得を要求する場合、
前記第三のリクエストとして、一つのファイル取得を要求するリクエストを送信し、
当該リクエストに対するレスポンスである一つの前記第二のファイルを受信する前に、次のファイル取得を要求する次のリクエストを、前記第三のリクエストとして送信する
ことを特徴とする通信方法。
【請求項７】
請求項２の通信方法であって、
前記クライアント側プロキシは、
複数の前記クライアントに接続され、
前記ファイル一覧に含まれ、プリフェッチされた前記第二のファイルを保存し、
第一の前記クライアントがリクエストしたファイルと同一のファイルに対するリクエストを、第二の前記クライアントから受信した場合に、
前記第二のクライアントに対して、保存した前記ファイルを送信する
ことを特徴とする通信方法。
【請求項８】
請求項２の通信方法であって、
前記クライアント側プロキシは、複数の前記クライアントに接続され、
前記サーバ側プロキシは、
前記ファイル一覧に含まれプリフェッチされた前記第二のファイルを保存し、
第一の前記クライアントがリクエストしたファイルと同一のファイルに対する、第二の前記クライアントからのリクエストを受信した場合に、
前記第二のクライアントに対するレスポンスとして、保存した前記ファイルを送信する
ことを特徴とする通信方法。
【請求項９】
請求項２記載の通信方法であって、
前記クライアント側プロキシ及び前記サーバ側プロキシは、ＷｅｂＤＡＶに従う通信であって、
前記第一のリクエストは、ＰＲＯＰＦＩＮＤであり、
前記ファイル一覧は、前記ファイルの実体の場所を示すＵＲＬであって、「２０７ ＭｕｔｌｉＳｔａｔｕｓ」というレスポンスに含まれ、
前記第２のリクエストは、当該ファイルの実体の取得を要求するためのＧＥＴリクエストである
ことを特徴とする通信方法。
【請求項１０】
請求項２記載の通信方法であって、
前記クライアント側プロキシ及び前記サーバ側プロキシは、ＨＴＴＰプロトコルに従う通信であって、
前記第一のリクエストがＨＴＭＬファイルに対するＧＥＴリクエストであり、
前記前記ファイル一覧は、「２００ ＯＫ」というレスポンスに含まれ、
前記第２のリクエストは、当該ファイルの実体の取得を要求するためのＧＥＴリクエストである
ことを特徴とする通信方法。
【請求項１１】
クライアントとサーバ間で、前記サーバに格納される情報の通信制御を行うプロキシシステムであって、
前記クライアントと通信するクライアント通信部と、
前記サーバと通信するサーバ通信部と、
通信制御部と、を有し、
前記通信制御部は、
前記クライアントからの、第一のリクエストに対して前記サーバから取得したレスポンスが示す、前記サーバに格納されている複数の情報のうち、一つの第一の前記情報の取得要求を前記クライアントから受信したことを契機として、前記レスポンスが示す、前記第一の情報を含む複数の前記情報の取得要求を、前記サーバに送信し、
前記複数の情報取得要求に対するレスポンスである前記複数の情報を前記サーバから受信した場合、前記クライアントに当該複数の情報を送信する
ことを特徴とするプロキシシステム。
【請求項１２】
請求項１１記載のプロキシシステムであって、
前記通信制御部は、
バッファを備え、
ＷｅｂＤＡＶプロトコルに従う、前記クライアントからの送信される前記第一のリクエストであるＰＲＯＰＦＩＮＤに対する前記サーバからのレスポンスに基づいて、特定されるフォルダに含まれるファイルのＵＲＬを用いて、前記フォルダに含まれるいずれか一のファイルの取得要求を前記クライアントから受信した場合、前記フォルダに含まれる他のファイルも前記サーバからプリフェッチして前記バッファに保存し、
前記クライアントからの前記他のファイルの取得要求に応じて、保存したファイルをクライアントに送信する
ことを特徴とするプロキシシステム。
【請求項１３】
請求項１２記載のプロキシシステムであって、
前記クライアント通信部は、複数の前記クライアントと通信し、
前記通信制御部は、前記複数のクライアントから、ＰＲＯＰＦＩＮＤを受信した場合、前記バッファに保存したファイルを当該複数のクライアントにそれぞれ送信し、当該ファイルを前記バッファから削除する
ことを特徴とするプロキシシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信装置および方法に関する。
【背景技術】
【０００２】
ウェブシステムにおいて、クライアント側で、サーバからの情報を表示しようとする場合、クライアントサーバ間で、ウェブブラウザはHTMLを解析し、オブジェクトを発見するたびにそのオブジェクトに対するGETリクエストをサーバに送信する。通常ブラウザから一つのサーバへの同時接続数は制限されているため、ウェブページの読み込みにはクライアント・サーバ間の往復が多数回行われることとなる。
【０００３】
クライアントとサーバが大陸間海底ケーブルなどの遅延の大きなワイドエリアネットワーク (Wide Area Network: WAN)により接続されている場合、ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol: HTTP)による通信は、効率が著しく低下する。遅延の大きなネットワークでは、クライアントがリクエストを送信してからサーバからレスポンスが返ってくるまで長い時間がかかり、クライアントはその間待機する必要を生じる。これが多数回行われるためウェブページをリクエストしてから表示が完了するまでの時間が長くなる。
【０００４】
例えば、クライアントとサーバが、衛星回線を通じて通信し、ＨＴＴＰプロトコルに従って、サーバから衛星回線を介してダウンロードされるウエブページのインラインオブジェクトの呼び出し遅れを防ぐために、分散プロキシサーバが、基本コンポーネントの取得時に、インラインオブジェクトを先読みする技術が特許文献１に開示されている。
【０００５】
また、ＨＴＴＰ方式を拡張して、サーバ上のファイルを容易に編集可能としたWebDAV (Web Distributed Authoring and Versioning) という方式がある（非特許文献１）。WebDAVではサーバ上のファイルやフォルダをWebDAVクライアント経由で操作可能である。WebDAVでもHTTPと同様のリクエストが用いられるほか、フォルダ内のファイルに関するプロパティ情報を取得するためのPROPFINDというリクエストが用いられる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】WO1999008429A
【非特許文献】
【０００７】
【非特許文献１】IETF RFC2518 “HTTP Extensions for Distributed Authoring - WEBDAV”
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、ＷｅｂＤＡＶではＨＴＴＰと異なり、ファイルが基本コンポーネントとそれに付随するインラインオブジェクトのような主従関係になっておらず、特許文献１の技術を適用しても、ファイルの関係性を見出すことができないため先読みすることはできない。
【０００９】
そこで、本発明では、WebDAVをWAN経由で利用する場合に、適切なファイル一覧の取得方法を実現することを、一目的とする。
【００１０】
また、WebDAVではファイル一覧の情報を取得したとしても、次のリクエストが判明しないとそれらのファイルを転送するべきか否かを断定できないため、ファイルの転送が不要な場合にもファイルの転送を行ってしまう。そこで本発明では、必要な場合のみに複数のファイルを効率的に転送することを他の目的とする。また、WebDAVをWAN経由で利用する場合に適切なファイルの高速転送を実現することを他の目的とする。
【課題を解決するための手段】
【００１１】
少なくともいずれか一の課題を解決するために、本発明の一態様は、クライアントと接続されるクライアント側プロキシと、サーバと接続されるサーバ側プロキシとを含むシステムで、前記クライアントおよび前記サーバの間の通信を中継する通信方法であって、前記クライアントと前記サーバの間で前記クライアントからのリクエストに対して前記サーバがレスポンスを送信する形式の通信方法において、前記クライアントからが送信される第一のリクエストで取得される複数ファイルのリストを含むレスポンスを、クライアントに送信し、前記クライアントから、前記リストに関連する第二のリクエストを受領した場合、  前記クライアントからのリクエストを待たずに、前記サーバに対して前記リストに該当する複数ファイルを取得するためのリクエストを送信し、前記複数ファイル取得リクエストに対するレスポンスとして前記複数ファイルのリストに該当する前記複数ファイルの実体を、前記サーバからプリフェッチする、ことを特徴とする通信方法。
【００１２】
また別の態様は、クライアント装置とサーバ装置間で、サーバに格納されるデータの通信制御を行うプロキシシステムであって、クライアントと通信するクライアント通信部と、サーバと通信するサーバ通信部と、前記クライアントからの、第一のリクエストに対するレスポンスに含まれる複数の情報のうち、少なくともいずれか一の情報の取得要求を前記クライアントから受信した場合、前記レスポンスに含まれる複数の情報の取得要求を、サーバに送信し、前記複数の情報取得要求に対するレスポンスを、前記サーバからの受領した場合、前記クライアントに当該レスポンスを送信する、送信制御部と、を有する態様である。
【発明の効果】
【００１３】
ＨＴＴＰやＷｅｂＤＡＶに従う通信で、サーバからクライアントへの複数ファイルを効率的に転送する。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施例１における通信方式を表すシーケンス図である。
【図２】本実施例におけるネットワーク構成図である。
【図３】本実施例におけるクライアント側プロキシの内部構成を表す図である。
【図４】本実施例におけるサーバ側プロキシの内部構成を表す図である。
【図５】本実施例におけるクライアント側プロキシおよびサーバ側プロキシのデータ管理テーブルを表す図である。
【図６】本発明の実施例１におけるクライアント側プロキシの動作を表すフローチャートである。
【図７】本発明の実施例１におけるサーバ側プロキシの動作を表すフローチャートである。
【図８】本発明の実施例２における通信方式を表すシーケンス図である。
【図９】本発明の実施例２におけるクライアント側プロキシの動作を表すフローチャートである。
【図１０】本発明の実施例２におけるサーバ側プロキシの動作を表すフローチャートである。
【図１１】本発明の実施例３における通信方式を表すシーケンス図である。
【図１２】本発明の実施例３におけるクライアント側プロキシの動作を表すフローチャートである。
【図１３】本発明の実施例３におけるサーバ側プロキシの動作を表すフローチャートである。
【図１４】本発明の実施例４における通信方式を表すシーケンス図である。
【図１５】本発明の実施例４におけるクライアント側プロキシの内部構成を表す図である。
【図１６】本発明の実施例４におけるサーバ側プロキシの内部構成を表す図である。
【図１７】本発明の実施例４におけるクライアント側プロキシおよびサーバ側プロキシのデータ管理テーブルを表す図である
【図１８】本発明の実施例４におけるクライアント側プロキシの動作を表すフローチャートである。
【図１９】本発明の実施例４におけるサーバ側プロキシの動作を表すフローチャートである。
【発明を実施するための形態】
【実施例１】
【００１５】
図２は本実施例におけるネットワーク構成を表す図である。
【００１６】
クライアント（１１）と同一のLAN（１３）内にクライアント側プロキシ（１２）を設置し、クライアント側プロキシ（１２）がWAN（１４）との通信を行う。同様に、サーバ（１６）と同一のLAN（１７）内にサーバ側プロキシ（１５）を設置し、サーバ側プロキシ（１５）がWANとの通信を行う。クライアント側プロキシ（１２）とサーバ側プロキシ（１５）が協調して動作することにより、ＬＡＮに比べて遅延の大きなWANでも性能劣化を抑えて通信を行うことを可能とする。
【００１７】
本実施例では、クライアント側プロキシ（１２）とサーバ側プロキシ（１５）が協調して動作するシステムを説明するが、クライアント側プロキシ（１２）あるいはサーバプロキシ（１５）が他方のプロキシの動作を兼ねて、他方の処理を省略するプロキシシステムであってもよい。
【００１８】
本発明の第一の実施例における通信シーケンスを図１に示す。図１では通信にかかわる、少なくとも一以上のクライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。
【００１９】
クライアントがサーバ上のフォルダにアクセスする際、まず、クライアントは、そのフォルダに対してPROPFINDというリクエスト（１０１）を発行する。このリクエストは、クライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWANを介してを転送される（１１１）。
【００２０】
サーバ側プロキシ（１５）は、PROPFINDを受信すると、サーバ（１６）へさらに転送する（１２１）。PROPFINDを受信したサーバ（１６）はそれに対するレスポンスを生成し、クライアントに向けてＷＡＮ側へ返送する（１２２）。このレスポンスにはフォルダ内のファイル一覧が含まれる。同レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１１２）、サーバ側プロキシ（１５）は、ＰＲＯＰＦＩＮＤに対するレスポンスを解析し、フォルダ内のファイル一覧を取得する。さらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１０２）。クライアント側プロキシ（１２）でも同様にこのレスポンスを解析し、ファイル一覧を取得する。クライアント（１１）はクライアント側プロキシ（１２）およびサーバ側プロキシ（１５）とは、別にこのレスポンスを解析してファイル一覧を取得する。
【００２１】
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（１０３）は、クライアント側プロキシ（１２）によって転送され（１１３）、サーバ側プロキシ（１５）によって転送されて（１２３）サーバ（１６）によって受信される。サーバ（１６）はリクエスト（１２３）に対するレスポンスとしてファイルを送信する（１２４）。
【００２２】
まず、サーバ側プロキシ（１５）の動作を説明する。レスポンス（１２４）を受信したサーバ側プロキシ（１５）はこれをクライアント側プロキシ（１２）へ転送する（１１４）。同時に、サーバ側プロキシ（１５）はファイル一覧中の次のファイルに対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（１２５）。サーバ（１６）はこれに対するレスポンスとしてファイルを送信する（１２６）。該当ファイル（ファイル一覧のうちいずれか一のファイル）を受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（１１５）するとともに、ファイル一覧に次のファイルがあればそれに対するリクエストを送信する（１２７）。サーバ側プロキシ（１５）が同リクエストに対するレスポンスを受信（１２８）するとこれをクライアント側プロキシ（１２）へ転送する（１１６）。サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがないので、ファイル一覧を破棄して動作を完了する。
【００２３】
次に、クライアント側プロキシ（１２）の動作を説明する。クライアント側プロキシ（１２）はファイル１のレスポンスを受信（１１４）し、ファイル１を取得すると、ファイル１をクライアント（１１）へ転送する（１０４）。クライアント（１１）はファイル２に対するリクエストを送信する（１０５）。一方でファイル２のレスポンスはサーバ側プロキシ（１５）より送信されるされる（１１５）ので、クラアント側プロキシ（１２）は、ファイル２に対するリクエストとレスポンスがそろった段階で、クライアント（１１）に対してレスポンスを送信する（１０６）。同様の動作をファイル一覧中の全てのファイルに対して繰り返し（１０７，１１６，１０８）、ファイル一覧を破棄して動作を完了する。
【００２４】
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００２５】
以上により、「ＰＲＯＰＦＩＮＤ」に対するレスポンスに含まれる「２０７  Ｍｕｌｔｉ−Ｓｔａｔｕｓ」に該当するファイルの指定を受けたの契機にサーバ側プロキシ１５が、「２０７  Ｍｕｌｔｉ−Ｓｔａｔｕｓ」に対応する複数ファイルの読み出しを実行し、クライアント側プロキシ１２に「２００  ＯＫ」により、それぞれファイル１−３を送る例を示した。
【００２６】
図３はクライアント側プロキシ（１２）の内部構成を表す図である。サーバ側プロキシ（１２）は、クライアント１１とサーバ１６の間の通信を仲介し、パケットを送受信する通信装置であって、クライアント１１とＷＡＮの間にあるのが一例である。または、クライアント側の局所ネットワークのゲートウェイ装置であってもよい。クライアントは、例えば情報処理装置、無線情報処理端末である。局所ネットワークは、有線、無線少なくともいずれかで構成されてもよい。
【００２７】
LAN側コネクション管理部（３０１）はクライアント（１１）との通信を行う。クライアント（１１）からのリクエストはリクエスト判定部（３０２）にて、リクエストを送信したクライアント（１１）が識別される。また、そのリクエストがPROPFINDやGETなど、プリフェッチ動作の契機となるものかどうかが判定される。
【００２８】
プリフェッチ動作中でないとき、受信したリクエストはそのままリクエスト送信部（３０５）に送られ、サーバ側プロキシ（１５）へ送信される。プリフェッチ動作中はリクエストは一旦データ管理部（３０４）に登録される。
【００２９】
データ管理部（３０４）はIPアドレスで識別されるクライアント（１１）ごとにテーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアントが３台あれば３つのテーブル（３１１〜３１３）を持つ。リクエストを受信すればそのパス名をキーとしてテーブルを検索して、リクエスト受信済みのフラグを立てる。またプリフェッチされたレスポンスを受信すればレスポンス受信済みのフラグを立てる。テーブルのエントリは定期的に調べられ、リクエスト受信済みかつレスポンス受信済みであれば、レスポンスをレスポンス送信部（３０３）を介して、クライアントへ送信する。リクエスト受信時にレスポンスが登録されていなければ、リクエストをリクエスト送信部（３０５）を介してサーバ側プロキシ（１５）へ送信してもよい。
【００３０】
リクエスト送信部（３０５）は、リクエスト判定部（３０２）またはデータ管理部（３０４）から受け取ったリクエストをWAN側コネクション管理部（３０７）を用いて送信する。
【００３１】
WAN側コネクション管理部（３０７）は、WANを通じてサーバ側プロキシ（１５）との通信の制御を行う。
【００３２】
レスポンス解析部（３０６）ではサーバ側プロキシ（１５）から受信したレスポンスのIPアドレスを解析して、どのクライアント（１１）に対するものであるか判断する。また、PROPFINDに対するレスポンスであればその内容も解析しファイル一覧を取得してデータ管理部（３０４）に登録する。同時にレスポンス送信部（３０３）に渡してクライアント（１１）へ転送する。GETに対するレスポンスであればデータ管理部（３０４）に登録する。
【００３３】
レスポンス送信部（３０３）ではレスポンス解析部（３０６）またはデータ管理部（３０４）から受信したレスポンスデータをLAN側コネクション管理部（３０１）に渡してクライアント（１１）へ転送する。
【００３４】
図４はサーバ側プロキシ（１５）の内部構成を表す図である。サーバ側プロキシ（１５）は、クライアントとサーバの間の通信を仲介し、パケットを送受信する通信装置であって、サーバとＷＡＮの間にあるのが一例である。または、サーバ側の局所ネットワークのゲートウェイ装置であってもよい。サーバは、例えば情報処理装置である。サーバ側の局所ネットワークは、有線、無線少なくともいずれかで構成されてもよい。WAN側コネクション管理部（４０１）はクライアント側プロキシ（１２）との通信を行う。
【００３５】
クライアント側プロキシからのリクエストはリクエスト判定部（４０２）にて、リクエストを送信したクライアント（１１）が識別される。また、そのリクエストがPROPFINDやGETなど、プリフェッチ動作の契機となるものかどうかが判定される。
【００３６】
プリフェッチ動作中でないとき、受信したリクエストはそのままリクエスト送信部（４０５）に送られ、サーバへ送信される。プリフェッチ動作中の場合、リクエストは、一旦データ管理部（４０４）に登録される。
【００３７】
データ管理部（４０４）は、クライアント側プロキシ（１２）と同様にクライアント（１１）ごとにデータ管理テーブルを持ち、リクエスト・レスポンスの状態とそのデータを管理する。例えばクライアント（１１）が３台あれば３つのテーブル（４１１〜４１３）を持つ。プリフェッチ動作中は、テーブルは定期的に調べられ、プリフェッチ未了のエントリがあればプリフェッチを行うため、リクエスト送信部（４０５）へURLを渡す。クライアント側プロキシ（１２）からリクエストを受信した場合、該当レスポンスを送信していなければ、そのリクエストを優先的にリクエスト送信部（４０５）へ渡し、サーバ（１６）へ送信する。
【００３８】
リクエスト送信部（４０５）は、リクエスト判定部（４０２）またはデータ管理部（４０４）から受け取ったリクエストをLAN側コネクション管理部（４０７）を用いて送信する。LAN側コネクション管理部（４０６）は、サーバ側プロキシ（１５）とサーバ（１６）との通信を制御する。
【００３９】
レスポンス解析部（４０６）ではサーバ（１５）から受信したPROPFINDに対するレスポンスを解析しファイル一覧を取得してデータ管理部（４０４）に登録する。同時にレスポンス送信部（４０３）を介してクライアント（１６）へ転送する。またレスポンスがGETに対するレスポンスであればデータ管理部（４０４）に登録する。
【００４０】
レスポンス送信部（４０３）は、レスポンス解析部（４０６）またはデータ管理部（４０４）から受信したレスポンスデータをWAN側コネクション管理部（４０１）を介してクライアント側プロキシ（１２）へ転送する。
【００４１】
図５は、(a)クライアント側プロキシおよび(b)サーバ側プロキシのデータ管理部における、データ管理テーブル（３１１，４１１）を示す。クライアント側プロキシのデータ管理テーブル（３１１）は対象となるファイルごとに、ファイルのURL（３５１）、プリフェッチしたレスポンス（３５２）、および1または0の値をとる3種類のフラグを持っている。フラグは「クライアントからリクエスト受信済み（３５３）」、「サーバ側プロキシからレスポンス受信済み（３５４）」、「クライアントにレスポンス送信済み（３５５）」である。
【００４２】
「クライアントからリクエスト受信済み（３５３）」フラグは、そのファイルに対するリクエストをクライアントから受信したとき1に設定される。フラグの値は、０，１以外であっても、クライアントからのリクエストが受信されたかか否かを、識別できる値を用いてもよい。
【００４３】
「サーバ側プロキシからレスポンス受信済み（３５４）」フラグはそのファイルをサーバ側プロキシから受信したとき1に設定される。フラグの値は、１以外であっても、サーバ側プロキシからレスポンスが受信されたかか否かを、識別できる値を用いてもよい。これらのフラグの両方が1となっていれば、レスポンスはクライアント側プロキシからクライアントへ送信され、「クライアントにレスポンス送信済み（３５５）」フラグが1に設定される。「クライアントにレスポンス送信済み（３５５）」フラグが1であれば該当エントリは削除される。
【００４４】
サーバ側プロキシのデータ管理テーブルは対象となるファイルごとに、ファイルのURL（４５１）、プリフェッチしたレスポンス（４５２）、および1または0の値をとる3種類のフラグを持っている。フラグは「サーバにプリフェッチリクエスト送信済み（４５３）」、「クライアント側プロキシからリクエスト受信済み（４５４）」、「サーバからレスポンス受信済み（４５６）」である。
【００４５】
「サーバにプリフェッチリクエスト送信済み（４５３）」フラグは、そのファイルに対するリクエストをサーバに送信したとき1に設定される。フラグの値は、０，１以外であっても、サーバにプリフェッチリクエストが送信されたかか否かを、識別できる値を用いてもよい。「クライアント側プロキシからリクエスト受信済み（４５４）」フラグはクライアント側プロキシからリクエストを受信したときに1に設定される。「サーバからレスポンス受信済み（４５５）」フラグはサーバからレスポンスを受信したときに1に設定される。このフラグが1のときにレスポンスはクライアント側プロキシに送信され、エントリが削除される。
【００４６】
図６はクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（５０１）。クライアント側プロキシ（１２）は、ＬＡＮ側でパケットを受信すると、送信元および宛先IPアドレスごとに分離する（５０２）。そのパケットがPROPFINDリクエストであれば（５０３）、クライアント側プロキシ（１２）は、サーバ側プロキシへ転送して（５０４）、GET待ち状態へ移行する。その他のリクエストであれば（５５１）、同様にサーバ側プロキシへ転送する（５５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（５５３）それをクライアント（１１）へ転送し（５５４）、初期状態（５０１）へ戻る。
【００４７】
サーバ側プロキシへ転送したPROPFIND（５０４）のレスポンスが受信されるまで、クライアント側プロキシ（１２）は、当該ＰＲＯＰＦＩＮＤ（５０４）に関する処理を待機する（５０５）。ＰＲＯＰＦＩＮＤ（５０４）のレスポンスが受信されると、クライアント側プロキシ（１２）は、そのレスポンスをクライアント（１１）へ転送する（５０６）。また、クライアント側プロキシ（１２）は、このレスポンスを解析してファイル一覧を作成し、データ管理部（４０４）に登録する（５０７）。
【００４８】
続いて、クライアント側プロキシ（１２）は、クライアントからのGETリクエストを待ちうける（５０８）。GETを受信すると、クライアント側プロキシ（１２）は、これをサーバ側プロキシ（１５）へ転送し（５０９）、ＧＥＴリクエストに対するレスポンスを受信するまで待機する（５１０）。クライアント側プロキシ（１２）は、受信されればクライアント（１１）へ転送（５１１）し、サーバ側プロキシ（１５）からのプリフェッチデータを待ちうける（５１２）。GET以外のリクエストを受信した場合（５５５）は、同様にサーバ側プロキシ（１５）へ転送する（５５６）が、WAN側からレスポンスを受信するのを待って（５５７）それをクライアント（１１）へ転送し（５５８）、初期状態（５０１）へ戻る。
【００４９】
サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（５１２）、クライアント側プロキシ（１２）は、これをデータ管理部（３０４）に保存して（５１３）、クライアントからのリクエストを待ちうける（５１４）。リクエストを受信すると、リクエストに該当するファイルをデータ管理部（３０４）に保存されているプリフェッチデータから読み出し、保存していたプリフェッチデータをレスポンスとしてクライアントに送信する（５１５）。
【００５０】
ファイル一覧にファイルが残っていれば、５１２以降を繰り返す（５１６）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（５０１）に戻る（５１７）。
【００５１】
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００５２】
図７は、サーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（６０１）。サーバ側プロキシ（１５）は、受信すると送信元および宛先IPアドレスごとに分離する（６０２）。そのパケットがPROPFINDリクエストであれば（６０３）、サーバ側プロキシ（１５）は、サーバ（１６）へ転送して（６０４）GET待ち状態へ移行する。その他のリクエストであれば（６５１）、サーバ側プロキシ（１５）は、サーバ（１６）へ転送する（６５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）は、サーバ（１６）からレスポンスを受信するのを待って（６５３）それをクライアント（１１）側へ転送し（６５４）、初期状態（６０１）へ戻る。
【００５３】
一方、サーバ側プロキシ（１５）は、ステップ６０３の後、サーバ（１６）へ転送したPROPFIND（６０４）のレスポンスが受信されるまで待機し（６０５）受信されるとクライアント側プロキシ（１５）へ転送する（６０６）。また、サーバ側プロキシ（１５）は、ＰＲＯＰＦＩＮＤ（６０４）に対するレスポンスを解析してファイル一覧を作成し、データ管理部（４０４）に登録する（６０７）。
【００５４】
続いてクライアント側プロキシ（１２）からのGETリクエストを待ちうける（６０８）。GETを受信すると、サーバ側プロキシ（１５）は、これをサーバ（１６）へ転送し（６０９）、それに対するレスポンスを受信するまで待機する（６１０）。受信されればクライアント側プロキシ（１２）へ転送し（６１１）、データ管理部（４０４）に登録されているファイル一覧に従って、次のファイルに対するプリフェッチリクエストを送信する（６１２）。GET以外のリクエストを受信した場合（６５５）は、サーバ側プロキシ（１５）は、にサーバへ転送する（６５６）が、サーバ（１６）からレスポンスを受信するのを待って（６５７）それをクライアント側プロキシ（１２）へ転送し（６５８）、初期状態（６０１）へ戻る。
【００５５】
一方、ステップ６１２に対してサーバ（１６）からのプリフェッチデータを受信すると（６１３）、サーバ側プロキシ（１５）は、クライアント側プロキシに送信する（６１４）。
【００５６】
ファイル一覧に従って、サーバ側プロキシ（１５）は、サーバから受信されていないファイルが残っていれば、６１２以降を繰り返す（６１５）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（６０１）に戻る（６１６）。
【００５７】
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【実施例２】
【００５８】
本発明の第二の実施例における通信シーケンスを図８に示す。図８では通信にかかわる、クライアント（１１）、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）、およびサーバ（１６）のシーケンスを示している。本実施例の方式により、実施例１の場合と比べて同等の通信効率を保ちながら、WAN上の通信をWebDAVの標準プロトコルにのっとったものとする。それによりWAN上の通信がファイアウォール、Intrusion Detection System/Intrusion Protection System、Deep Packet Inspectionなどのセキュリティシステムにより、異常な通信であると判断されて遮断されることを防ぐことができる。
【００５９】
手順７０１、７０２、７１１、７１２、７２１、７２２は、図１の手順１０１、１０２、１１１、１１２、１２１、１２２と同様にＰＲＯＰＦＩＮＤのリクエストとそのレスポンスと同様である。
【００６０】
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（７０３）は、クライアント側プロキシ（１２）によって受信される。クライアント側プロキシ（１２）は、このリクエストを解析して、ＰＲＯＰＦＩＮＤリクエストに対するレスポンスであるファイル一覧中に含まれるファイル（ファイル１）であると判断すると、このリクエストをサーバ側プロキシ（１５）へ転送する（７１３）。さらに、クライアント側プロキシ（１２）は、クライアントからのリクエスト（７０７）で指定されるファイル（ファイル１）ではないが、ファイル一覧にある他のファイル（ファイル２、３）に対するリクエスト（７１４、７１５）も発行する。これらのリクエストは前のリクエストに対するレスポンスを待つことなくサーバ側プロキシ（１５）へ送信される（７１４，７１５）。
【００６１】
サーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのリクエストを受信（７１３）すると、ファイル一覧中のファイルで、クライアントからの最初のリクエストで指定されたファイル（ファイル１）に対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（７２３）。サーバ（１６）は、これに対するレスポンスとしてファイル１を送信する（７２４）。これを受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（７１６）する。
【００６２】
また、サーバ側プロキシ（１５）は、サーバ（１６）からのファイル１の受信に応じて、受信したファイル１が含まれるファイル一覧に次のファイル（ファイル２）があればそれに対するリクエストを送信する（７２５）。サーバ側プロキシ（１５）が同リクエストに対するレスポンスを受信（７２６）すると、これをクライアント側プロキシ（１２）へ転送する（７１７）。さらに、次のファイルも、ステップ７２５、７２６、７１７と同様にプリフェッチを行うと（７２７，７２８，７１８）、サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがない場合、ファイル一覧を破棄して動作を完了する。このリクエストは前のリクエストに対するレスポンスを受信してから開始してもよいし、複数のリクエストを同時に送信してもよい。
【００６３】
クライアント側プロキシ（１２）は、ファイル１のレスポンスを受信（７１６）すると、これをクライアント（１１）へ転送する（７０４）。クライアント（１１）はファイル２に対するリクエストを送信する（７０５）。一方でファイル２のレスポンスは、サーバ側プロキシ（１５）より受信される（７１７）ので、ファイル２に対するリクエストとレスポンスがそろった段階で、クライアント（１１）に対してレスポンスを送信する（７０６）。同様の動作をファイル一覧中の全てのファイルに対して繰り返し（７１８，７０７，７０８）、ファイル一覧を破棄して動作を完了する。
【００６４】
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００６５】
図９は第二の実施例におけるクライアント側プロキシ（１２）の動作を表すフローチャートである。ステップ８０１ないし８０７、８５１ないし８５４は、図６のステップ５０１ないし５０７、５５１ないし５５４と同様である。
【００６６】
続いてクライアントからのGETリクエストを待ちうける（８０８）。クライアント側プロキシ（１２）は、GETリクエストを受信するとこれを契機にファイル一覧中のファイルに対してプリフェッチリクエストを発行する（８０９）。このリクエストは前のリクエストに対するレスポンスを待たずに送信される。ファイル一覧中の全てのファイルに対してリクエストを送信するまでこれを繰り返す（８１０）。GET以外のリクエストを受信した場合（８５５）は、同様にサーバ側プロキシ（１５）へ転送する（８５６）が、WAN側からレスポンスを受信するのを待って（８５７）それをクライアント（１１）へ転送し（８５８）、初期状態（８０１）へ戻る。
【００６７】
サーバ側プロキシ（１５）から最初のリクエストに対するレスポンスを受信すると（８１１）、クライアント側プロキシ（１２）は、これをクライアントへ転送する（８１２）。クライアント側プロキシ（１２）は、サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（８１３）、これをデータ管理部（３０４）に保存して（８１４）、クライアントからのリクエストを待ちうける（８１５）。リクエストを受信すると、クライアント側プロキシ（１２）は、保存していたデータをレスポンスとしてクライアントに送信する（８１６）。
【００６８】
ファイル一覧にファイルが残っていれば、８１２以降を繰り返す（８１７）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（８０１）に戻る（８１８）。上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００６９】
図１０は第二の実施例におけるサーバ側プロキシ（１５）の動作を表すフローチャートである。ステップ９０１ないし９０７、９５１ないし９５４は、図７のステップ６０１ないし６０７、６５１ないし６５４と同様である。  続いてクライアント側プロキシ（１２）からのプリフェッチリクエストを待ちうける（９０８）。プリフェッチリクエストは、ファイル一覧に含まれるファイルの数に対応して複数送られるため、サーバ側プロキシ（１５）は、ファイル一覧に含まれるファイルの数に対応する全てのリクエストを受信するまでこれを繰り返す（９０９）。続いて、プリフェッチリクエストを順次サーバ（１６）へ転送し（９１０）、それに対するレスポンスを受信するまで待機する（９１１）。サーバ側プロキシ（１５）は、レスポンスが受信されればクライアント側プロキシ（１２）へ、それらを転送する（９１２）。GET以外のリクエストを受信した場合（９５５）は、サーバ側プロキシ（１５）は、同様にサーバ（１６）へ転送する（９５６）が、サーバ側プロキシ（１５）は、サーバ（１６）からGET以外のリクエストに対応するレスポンスを受信するのを待って（９５７）それをクライアント側プロキシ（１２）へ転送し（９５８）、初期状態（９０１）へ戻る。
【００７０】
ファイル一覧にサーバから取得していないファイルが残っていれば、９１０以降を繰り返す（９１３）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（９０１）に戻る（９１４）。上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００７１】
装置内の構成については実施例１の場合と同様であるので、ここでは省略する。
【００７２】
以上の実施例２の説明により、ＷｅｂＤＡＶに従った通信により得られた情報を用いて、プリフェッチするリクエストとレスポンスとを対応づけ、プロキシ間での通信制御を行うことを説明した。その制御により、WAN上の通信がファイアウォール、Intrusion Detection System/Intrusion Protection System、Deep Packet Inspectionなどのセキュリティシステムにより、プリフェッチするための通信が、異常な通信であると判断されて遮断されることを防ぐことができる。
【実施例３】
【００７３】
本発明の第三の実施例における通信シーケンスを図１１に示す。この例では実施例２の方式をHTTPに適用している。本実施例の方式により、実施例２の場合と同様に、WAN上の通信はHTTPの標準にのっとったものとなるため、セキュリティシステムにより異常な通信として判断され遮断されることを防ぐことができる。
【００７４】
クライアントが、サーバからウェブページを読み込む場合、まずHTMLファイルに対してGETというリクエスト（１００１）を発行する。これはクライアント側プロキシ（１２）で受信され、サーバ側プロキシ（１５）へとWAN上を転送される（１０１１）。サーバ側プロキシ（１５）はこれを受信すると、サーバ（１６）へさらに転送する（１０２１）。HTMLに対するGETを受信したサーバ（１６）は、そのHTMLファイルをクライアントへ返送する（１０２２）。このレスポンス（１０２２）は、ＨＴＴＰに従った「２００  ＯＫ」というレスポンスであり、フォルダ内のファイル一覧が含まれる。同レスポンスはサーバ側プロキシ（１５）でクライアント側プロキシ（１２）へ転送され（１０１２）、サーバ側プロキシ（１５）は、このレスポンスを解析することによりフォルダ内のファイル一覧を取得する。さらにクライアント側プロキシ（１２）でクライアント（１１）へ転送される（１００２）。クライアント側プロキシ（１２）でも同様にこのレスポンスを解析し、ファイル一覧を取得する。クライアント（１１）はクライアント側プロキシ（１２）およびサーバ側プロキシ（１５）とは、独立してこのレスポンスを解析してファイル一覧を取得する。
【００７５】
ファイル一覧を取得したクライアント（１１）は、各ファイルに対して順にリクエストを送信する。クライアント（１１）から送信された最初のファイルに対するリクエスト（１００３）は、クライアント側プロキシ（１２）によって受信される。
【００７６】
クライアント側プロキシ（１２）は、このリクエストを解析して、ファイル一覧中に含まれるファイルであると判断すると、このリクエストをサーバ側プロキシ（１５）へ転送する（１０１３）。クライアント１１からのリクエストで指定されるファイルが「２００  ＯＫ」のレスポンス（１０１２）で取得したファイル一覧中に含まれるファイル（file 1）であると、クライアント側プロキシ（１２）が判断すると、そのファイル一覧の他のファイル(file2, 3)に対するリクエストも発行する。これらのリクエストは前のリクエストに対するレスポンスを待つことなくサーバ側プロキシ（１５）へ送信される（１０１４，１０１５）。つまり、クライアントからファイル一覧に含まれる一のファイルを指定するリクエストがくると、クライアント側プロキシ（１２）は、ファイル一覧に含まれる他のファイルについてのリクエストも、クライアント（１１）からのリクエストを待つことなく、サーバ側プロキシ（１５）にプリフェッチリクエスト（１０１４、１０１５）を発行する。
【００７７】
サーバ側プロキシ（１５）は、クライアント側プロキシ（１２）からのリクエストを受信（１０１３）すると、ファイル一覧中のファイルに対するリクエストを、クライアント（１１）に代わってサーバ（１６）に送信する（１０２３）。サーバ（１６）はこれに対するレスポンスとしてファイルを送信する（１０２４）。
【００７８】
これを受信したサーバ側プロキシ（１５）は、このファイルをクライアント側プロキシ（１２）へ転送（１０１６）するとともに、レスポンス（１０２２）で取得したファイル一覧に他のファイルがあればそれに対するリクエストをサーバ（１６）に送信する（１０２５）。
【００７９】
サーバ側プロキシ（１５）は、同リクエストに対するレスポンスを受信（１０２６）すると、これをクライアント側プロキシ（１２）へ転送する（１０１７）。他のファイルも同様にプリフェッチを行う（１０２７，１０２８，１０１８）。なお、サーバ側プロキシ（１５）は。クライアント側プロキシ（１２）から送信されるプリフェッチリクエストに対応するファイルのリクエストをサーバ（１６）送信してもよい。サーバ側プロキシ（１５）は、ファイル一覧に次のファイルがないので、ファイル一覧を破棄して動作を完了する。このリクエストは前のリクエストに対するレスポンスを受信してから開始される。
【００８０】
クライアント側プロキシ（１２）は、ファイル１のレスポンスを受信（１０１６）すると、これをクライアント（１１）へ転送する（１００４）。クライアント（１１）は、ファイル一覧に含まれるファイル２に対するリクエストを送信する（１００５）。一方でファイル２のレスポンスはサーバ側プロキシ（１５）から送信される（１０１７）ので、クライアント側プロキシ（１２）は、ファイル２に対するリクエストを保持し、レスポンスを受領した場合に、クライアント（１１）に対して、保持しているファイル２に対するリクエストに対応するレスポンスを送信する（１００６）。同様の動作をファイル一覧に含まれるファイルに対して繰り返し（１０１８，１００７，１００８）、ファイル一覧をバッファから破棄して動作を完了する。
【００８１】
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００８２】
図１２は、実施例３におけるクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（１１０１）。受信すると送信元および宛先IPアドレスごとに分離する（１１０２）。そのパケットがHTMLに対するGETリクエストであれば（１１０３）サーバ側プロキシへ転送して（１１０４）GET待ち状態へ移行する。その他のリクエストであれば（１１５１）、同様にサーバ側プロキシ（１５）へ転送する（１１５２）が、プリフェッチの準備は行わず、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（１１５３）それをクライアント（１１）へ転送し（１１５４）、初期状態（１１０１）へ戻る。
【００８３】
サーバ側プロキシへ転送したHTMLに対するGET（１１０４）のレスポンスが受信されるまで待機し（１１０５）受信されるとクライアント（１１）へ転送する（１１０６）。同時にこのレスポンスを解析してファイル一覧を作成し、データ管理部（３０４）に登録する（１１０７）。
【００８４】
続いてクライアントからのGETリクエストを待ちうける（１１０８）。ファイル一覧に含まれるファイルに対するGETリクエストを受信すると、クライアント側プロキシは、これを契機にファイル一覧中のファイルに対してプリフェッチリクエストを発行する（１１０９）。これらのリクエストは前のリクエストに対するレスポンスを待たずに送信される。また、クライアントからのＧＥＴリクエストで指定されるファイルだけでなく、ＧＥＴリクエストで特定されるファイル一覧に含まれるファイルに対してリクエストを送信するまでこれを繰り返す（１１１０）。GET以外のリクエストを受信した場合（１１５５）は、同様にサーバ側プロキシ（１５）へ転送する（１１５６）が、WAN側からレスポンスを受信するのを待って（１１５７）それをクライアント（１１）へ転送し（１１５８）、初期状態（１１０１）へ戻る。
【００８５】
サーバ側プロキシ（１５）から最初のリクエストに対するレスポンスを受信すると（１１１１）、クライアント側プロキシ（１２）は、これをクライアントへ転送する（１１１２）。サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（１１１３）、クライアント側プロキシ（１２）は、これをデータ管理部（３０４）に保存して（１１１４）、クライアントからのリクエストを待ちうける（１１１５）。クライアントからのリクエストを受信すると、クライアント側プロキシ（１２）は、当該リクエストで指定されるファイルに対応する、ファイルを保存していたデータから読み出し、そのデータをレスポンスとしてクライアントに送信する（１１１６）。
【００８６】
クライアント側プロキシ（１２）は、ファイル一覧にファイルが残っていれば、１１１２以降を繰り返す（１１１７）。クライアント側プロキシ（１２）は、すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１１０１）に戻る（１１１８）。
【００８７】
上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００８８】
図１３は、実施例３におけるサーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（１２０１）。受信すると送信元および宛先IPアドレスごとに分離する（１２０２）。そのパケットがHTMLに対するGETリクエストであれば（１２０３）サーバ（１６）へ転送して（１２０４）GET待ち状態へ移行する。その他のリクエストであれば（１２５１）、同様にサーバ（１６）へ転送する（１２５２）が、プリフェッチの準備は行わず、サーバ（１６）からレスポンスを受信するのを待って（１２５３）それをクライアント（１１）へ転送し（１２５４）、初期状態（１２０１）へ戻る。
【００８９】
サーバ（１６）へ転送したHTMLに対するGET（１２０４）のレスポンスが受信されるまで待機し（１２０５）受信されるとクライアント側プロキシ（１５）へ転送する（１２０６）。同時にこのレスポンスを解析してファイル一覧を作成する（１２０７）。
【００９０】
続いてクライアント側プロキシ（１２）からのプリフェッチリクエストを待ちうける（１２０８）。図１１の１０１４及び１０１５がプリフェッチリクエストである。リクエストは連続して複数送られるため、全てのリクエストを受信するまでこれを繰り返す（１２０９）。続いてこれを順次サーバ（１６）へ転送し（１２１０）、それに対するレスポンスを受信するまで待機する（１２１１）。少なくとも一のレスポンスが受信されれば、サーバ側プロキシ（１５）は、そのレスポンスをクライアント側プロキシ（１２）へ転送する（１２１２）。なお、図１１の１０２３ないし１０２８のように、サーバ側プロキシは、一のファイルのリクエストに対するサーバからのレスポンス受領後に、別のファイルのリクエストを送信していてもよい。
【００９１】
GET以外のリクエストを受信した場合（１２５５）は、同様にサーバへ転送する（１２５６）が、サーバ（１６）からレスポンスを受信するのを待って（１２５７）それをクライアント側プロキシ（１２）へ転送し（１２５８）、初期状態（１２０１）へ戻る。
【００９２】
ファイル一覧にファイルが残っていれば、１２１０以降を繰り返す（１２１３）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１２０１）に戻る（１２１４）。  上記動作は、クライアント側プロキシ（１２）、サーバ側プロキシ（１５）の双方にてクライアント（１１）およびサーバ（１６）の組ごとに独立に行われる。クライアント（１１）およびサーバ（１６）の識別はパケットヘッダ中のIPアドレスを用いて行う。
【００９３】
装置内の構成については実施例１の場合と同様であるので、ここでは省略する。
【実施例４】
【００９４】
本発明の第四の実施例を図１４に示す。この例では実施例１の複数のクライアントが、同一のフォルダをダウンロードした際に、プロキシにて読み込み済みのデータをバッファに保持し、一のクライアントからのアクセスで削除するのではなく、複数のクライアントからのアクセスのためにバッファに保持し、複数のクライアントにファイルを転送することにより、データ転送量の削減を図っている。
【００９５】
この例では実施例１の場合にクライアントＢ（１１ｂ）が追加されており、クライアントＡ（１１ａ）と同一のフォルダに対しダウンロードを試みている。クライアントＡ（１１ａ）のシーケンスは実施例１と同様であるので、詳細は省略する。
【００９６】
クライアント側プロキシ（１２）では、フォルダカウント（１４１０）という値を用いてフォルダごとの同時アクセスしているクライアント数を管理する。クライアントＡ（１１ａ）からのPROPFIND（２０１）を受信すると、クライアント側プロキシ（１２）は、フォルダカウント（１４１０）を1に更新する。この値が1である間にクライアントＢ（１１ｂ）からPROPFIND（１４０１）が送信され、これを受信したクライアント側プロキシ（１２）は、フォルダカウントを2に更新する（１４１１）。クライアント側プロキシ（１２）は、PROPFINDに対するレスポンスを保持し、これをクライアントＢ（１１ｂ）に送信する（１４０２）。これを受けて、クライアント（１１）がフォルダ内のファイルに対してGETを発行する（１４０３）。これに対するレスポンスもクライアント側プロキシ（１２）が保持しているため、クライアント側プロキシ（１２）はそれをそのまま送信する。（１４０４）。
【００９７】
一方でクライアントA（１１ａ）への転送はファイル3にて終了し（２０８）、クライアント側プロキシ（１２）のフォルダカウントは1となる（１４１２）。
【００９８】
クライアントB（１１ｂ）への転送はファイル2（１４０５、１４０６）、ファイル3（１４０７、１４０８）と続き、終了する。このときクライアント側プロキシ（１２）のフォルダカウントが1であるので、このカウンタおよびフォルダ内のファイルを削除して終了する。
【００９９】
図１５はクライアント側プロキシ（１２）の内部構成を表す図である。本実施例では、実施例１の構成に共有データプール（１５０１）とフォルダテーブル（１５０２）を追加したものとなっている。レスポンスデータはクライアントごとのデータ管理テーブルではなく、クライアント（１１ａ、１１ｂ）間で共有される共有データプール（１５０１）に格納される。また、フォルダテーブル（１５０２）はフォルダごとにそのフォルダにアクセスしているクライアント数を示すテーブルである。他は図３と同様である。
【０１００】
図１６はサーバ側プロキシ（１５）の内部構成を表す図である。本実施例では、実施例１の構成に共有データプール（１６０１）とフォルダテーブル（１６０２）を追加したものとなっている。これらはクライアント側プロキシのものと同様の機能を持つ。他は図４と同様である。
【０１０１】
図１７(a)はクライアント側プロキシ（１２）のデータ管理部（３０４）における、データ管理テーブル（３１１〜３１３）を示す。また図１７(b)はサーバ側プロキシのデータ管理部（４０４）における、データ管理テーブル（４１１〜４１３）を示す。実施例１との違いは、これらのテーブルではレスポンスを管理しないため、レスポンス内容（３５２、４５２）の項目がない点である。
【０１０２】
図１７(c)は共有データプール（１５０１、１６０１）のデータテーブルを示す。これは、URL（１５５１）、レスポンス内容（１５５２）、ファイルが属するフォルダの情報（１５５３）を持つ。フォルダの情報は単なるフォルダ名でも、後述するフォルダテーブルのエントリへのポインタでよい。このデータはすべてのクライアント（１１ａ、１１ｂ）で共有され、他のクライアントのリクエストによりプリフェッチされたデータであっても、データがこの中にあればこのデータをレスポンスとして送信する。
【０１０３】
図１７(d)はフォルダテーブル（１５０２）を示す。これは、フォルダ名（１５５４）とカウンタ（１５５５）を持ち、カウンタ（１５５５）はフォルダごとにそのフォルダにアクセスしているクライアントの数を示しており、1以上の値をとる。フォルダ内全ファイルの転送が完了すると、プロキシはフォルダテーブル（１５０２）をチェックし、カウンタ（１５５５）の値が2以上であれば、他にアクセスしているクライアントがいるため同フォルダ内のファイルを削除しない。一方カウンタ（１５５５）の値が1であった場合は、他にアクセスしているクライアントがいないのでファイルを削除する。
【０１０４】
図１８はクライアント側プロキシ（１２）の動作を表すフローチャートである。初期状態ではLAN側でパケットを受信するまで待機する（１８０１）。受信すると送信元および宛先IPアドレスごとに分離する（１８０２）。そのパケットがPROPFINDリクエストであれば（１８０３）フォルダテーブルをカウントアップする（１８０４）。その他のリクエストであれば（１８５１）、同様にサーバ側プロキシ（１５）へ転送する（１８５２）が、サーバ側プロキシ（１５）からレスポンスを受信するのを待って（１８５３）それをクライアント（１１）へ転送し（１８５４）、初期状態（１８０１）へ戻る。
【０１０５】
フォルダカウントが2以上であれば（１８０５）、他のクライアントが読み込んだデータが存在するため、そのデータ（PROPFINDに対するレスポンス）をレスポンスとしてクライアント（１１）へ送信する（１８０６）。フォルダカウントが1であれば、PROPFINDリクエストをサーバ側プロキシ（１５）へ転送して（１８０７）GET待ち状態へ移行する。サーバ側プロキシ（１５）へ転送したPROPFINDのレスポンスが受信されるまで待機し（１８０８）受信されるとクライアント（１１）へ転送する（１８０９）。同時にこのレスポンスを解析してファイル一覧を作成する（１８１０）。
【０１０６】
続いてクライアントからのGETリクエストを待ちうける（１８１１）。GET以外のリクエストを受信した場合（１８５５）は、同様にサーバ側プロキシ（１５）へ転送する（５５６）が、WAN側からレスポンスを受信するのを待って（５５７）それをクライアント（１１）へ転送し（５５８）、初期状態（５０１）へ戻る。
【０１０７】
GETを受信した場合、フォルダカウントを参照し（１８１２）、2以上であれば他のクライアントが読み込んだデータが存在するため、そのデータをレスポンスとしてクライアントへ送信する（１８１３）。フォルダ内の全ファイルを転送完了するかタイムアウトするまでこれを繰り返し（１８１４）、終了したらフォルダカウントをカウントダウンする（１８１５）。
【０１０８】
フォルダカウントが1であった場合、リクエストをサーバ側プロキシ（１５）へ転送し（１８１６）、それに対するレスポンスを受信するまで待機して（１８１７）、受信されればクライアント（１１）へ転送し（１８１７）、サーバ側プロキシ（１５）からのプリフェッチデータを待ちうける（１８１８）。  サーバ側プロキシ（１５）からのプリフェッチデータを受信すると（１８１８）、これをデータ管理部（３０４）に保存して（１８２０）、クライアントからのリクエストを待ちうける（１８２１）。リクエストを受信すると保存していたデータをレスポンスとしてクライアントに送信する（１８２２）。
【０１０９】
ファイル一覧にファイルが残っていれば、５１２以降を繰り返す（１８２３）。すべてのデータを転送し終わるか、タイムアウトによりフォルダカウントをカウントダウンし、初期状態（１８０１）に戻る（１８２４）。
【０１１０】
図１９はサーバ側プロキシ（１５）の動作を表すフローチャートである。初期状態ではWAN側でパケットを受信するまで待機する（１９０１）。受信すると送信元および宛先IPアドレスごとに分離する（１９０２）。そのパケットがPROPFINDリクエストであれば（１９０３）フォルダテーブルをカウントアップする（１９０４）。その他のリクエストであれば（１９５１）、同様にサーバ（１６）へ転送する（１９５２）が、サーバ（１６）からレスポンスを受信するのを待って（１９５３）それをクライアント側プロキシ（１２）へ転送し（１９５４）、初期状態（１９０１）へ戻る。
【０１１１】
フォルダカウントが2以上であれば（１９０５）、他のクライアントが読み込んだデータが存在するため、そのデータ（PROPFINDに対するレスポンス）をレスポンスとしてクライアント側プロキシ（１２）へ送信する（１９０６）。フォルダカウントが1であれば、PROPFINDリクエストをサーバ（１６）へ転送して（１９０７）GET待ち状態へ移行する。サーバ（１６）へ転送したPROPFINDのレスポンスが受信されるまで待機し（１９０８）受信されるとクライアント側プロキシ（１２）へ転送する（１９０９）。同時にこのレスポンスを解析してファイル一覧を作成する（１９１０）。
【０１１２】
続いてクライアント側プロキシ（１２）からのGETリクエストを待ちうける（１９１１）。GET以外のリクエストを受信した場合（１９５５）は、同様にサーバへ転送する（１９５６）が、サーバ（１６）からレスポンスを受信するのを待って（１９５７）それをクライアント側プロキシ（１２）へ転送し（１９５８）、初期状態（１９０１）へ戻る。
【０１１３】
GETを受信した場合、フォルダカウントを参照し（１９１２）、2以上であれば他のクライアントが読み込んだデータが存在するため、そのデータをレスポンスとしてクライアント側プロキシ（１２）へ送信する（１９１３）。フォルダ内の全ファイルを転送完了するかタイムアウトするまでこれを繰り返し（１９１４）、終了したらフォルダカウントをカウントダウンする（１９１５）。
【０１１４】
フォルダカウントが1であった場合、リクエストをサーバ（１６）へ転送し（１９１６）、それに対するレスポンスを受信するまで待機する（１９１７）。受信されればクライアント側プロキシ（１２）へ転送し（１９１８）、次のファイルに対するプリフェッチリクエストを送信する（１９１９）。  サーバ（１６）からのプリフェッチデータを受信すると（１９２０）、クライアント側プロキシに送信する（１９２１）。ファイル一覧にファイルが残っていれば、１９１９以降を繰り返す（１９２２）。すべてのデータを転送し終わるか、タイムアウトによりプリフェッチしたデータを破棄し初期状態（１９０１）に戻る（１９２３）。
【０１１５】
上述の実施例により、ＨＴＴＰやＷｅｂＤＡＶに従う通信で、サーバからクライアントの利用状況に応じて複数ファイルを効率的に転送するとができる。
【図１】
0005948111.tif 000002
【図２】
0005948111.tif 000003
【図３】
0005948111.tif 000004
【図４】
0005948111.tif 000005
【図５】
0005948111.tif 000006
【図６】
0005948111.tif 000007
【図７】
0005948111.tif 000008
【図８】
0005948111.tif 000009
【図９】
0005948111.tif 000010
【図１０】
0005948111.tif 000011
【図１１】
0005948111.tif 000012
【図１２】
0005948111.tif 000013
【図１３】
0005948111.tif 000014
【図１４】
0005948111.tif 000015
【図１５】
0005948111.tif 000016
【図１６】
0005948111.tif 000017
【図１７】
0005948111.tif 000018
【図１８】
0005948111.tif 000019
【図１９】
0005948111.tif 000020