(57)【要約】【課題】ｈｔｔｐまたはｈｔｔｐｓ通信において大容量のファイルを送受信する場合でも、通信経路上のキャッシュ機能に負担をかけないデータ転送方法を提供することを目的とする。【解決手段】ＷｅｂブラウザとＷｅｂサイト間での通信において、送信データをセッションを分けて送信することにより通信経路上のキャッシュ機能の負荷を極力抑える。例えば、通信時に自動的にファイルを圧縮した後、指定サイズに分割し、各分割ファイル毎にそれぞれ別セッションでＷｅｂサイトに送信する。Ｗｅｂサイトでは送信されたファイルを結合した後に解凍する。これによりデータを送信するユーザは圧縮、分割を意識することなく、大量データの送信が実現でき、Ｗｅｂサイトでもメモリの負荷を抑えることができる。【選択図】  図４
2005011119.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されたクライアント端末とＷｅｂサーバとの間でｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、
送信側装置の処理手段が、送信するファイルを所定サイズに分割するステップと、
前記送信側装置の処理手段が、受信側装置に、分割した結果の各分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各分割ファイルをデータ転送するステップと、
受信側装置の処理手段が、前記別々のリクエストでそれぞれ転送された各分割ファイルを結合し、元ファイルを取得するステップと
を備えたことを特徴とするデータ転送方法。
【請求項２】
ネットワークに接続されたクライアント端末からＷｅｂサーバにｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、
前記クライアント端末の処理手段が、送信するファイルを所定サイズに分割するステップと、
前記クライアント端末の処理手段が、前記Ｗｅｂサーバに、分割した結果の各分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各分割ファイルをデータ転送するステップと、
前記Ｗｅｂサーバの処理手段が、前記別々のリクエストでそれぞれ転送された各分割ファイルを結合し、元ファイルを取得するステップと
を備えたことを特徴とするデータ転送方法。
【請求項３】
ネットワークに接続されたクライアント端末からＷｅｂサーバにｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、
前記クライアント端末の処理手段が、送信するファイルを圧縮するステップと、
前記クライアント端末の処理手段が、前記圧縮したファイルを所定サイズに分割するステップと、
前記クライアント端末の処理手段が、前記Ｗｅｂサーバに、分割した結果の各分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各分割ファイルをデータ転送するステップと、
前記Ｗｅｂサーバの処理手段が、前記別々のリクエストでそれぞれ転送された各分割ファイルを結合し、前記圧縮したファイルを取得するステップと、
前記Ｗｅｂサーバの処理手段が、前記圧縮したファイルを解凍し、元ファイルを取得するステップと
を備えたことを特徴とするデータ転送方法。
【請求項４】
ネットワークに接続されたクライアント端末からＷｅｂサーバにｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、
前記クライアント端末の処理手段が、送信するファイルを所定サイズに分割するステップと、
前記クライアント端末の処理手段が、前記分割した結果の各分割ファイルをそれぞれ圧縮するステップと、
前記クライアント端末の処理手段が、前記Ｗｅｂサーバに、各圧縮後の分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各圧縮後の分割ファイルをデータ転送するステップと、
前記Ｗｅｂサーバの処理手段が、前記別々のリクエストでそれぞれ転送された各圧縮後の分割ファイルをそれぞれ解凍し、各分割ファイルを取得するステップと、
前記Ｗｅｂサーバの処理手段が、前記取得した各分割ファイルを結合し、元ファイルを取得するステップと
を備えたことを特徴とするデータ転送方法。
【請求項５】
請求項２から４の何れか１つに記載のデータ転送方法において、
前記クライアント端末の処理手段は、前記クライアント端末のＣＰＵと該ＣＰＵが実行するプログラム（予めクライアント端末にインストールされているソフトウェア部品および動作時にＷｅｂサーバからダウンロードされて実行されるソフトウェア部品を含む）から構成されるものであることを特徴とするデータ転送方法。
【請求項６】
請求項２から４の何れか１つに記載のデータ転送方法において、
前記Ｗｅｂサーバの処理手段は、前記ＷｅｂサーバのＣＰＵと該ＣＰＵが実行するサーバアプリケーションプログラムから構成されるものであることを特徴とするデータ転送方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信路上のキャッシュ機能に負荷をかけないデータ転送方法に関する。
【０００２】
【従来の技術】
従来より、ネットワークのトラフィック緩和方法として、例えば特許文献１や特許文献２に記載の技術が知られている。特許文献１に記載の技術は、ＷＷＷサーバに、トラフィックの多い状態時にクライアントが要求するデータを保持しているプロキシサーバを動的に決定する仕組みを設け、クライアントのアクセス要求に対してクライアントが要求するデータを保持しているプロキシサーバを紹介することにより、プロキシサーバのキャッシュを有効に利用して負荷分散を実現するものである。特許文献２に記載の技術は、ネットワーク上のクライアントやサーバやゲートウエイにデータ通信制御を行うためのエージェントを実装し、それらのエージェント間でダミーパケットをやり取りするなどの方法で、ネットワークの伝送帯域や構成に関する情報などを取得し、この情報に基づいて端末から送信すべきデータを変換して送受信するものである。
【０００３】
一方、ｈｔｔｐまたはｈｔｔｐｓ通信でのデータ送受信は周知の技術であり、これらのプロトコルを用いてクライアントとサーバ間でデータを送受信することも行われている。また、大容量データを細分化する技術として、データ圧縮／解凍技術、ファイル分割技術についても周知の技術となっている。そこで、これらの技術を組み合わせて、大容量データを送受信する際に該データを分割したり圧縮し、ｈｔｔｐまたはｈｔｔｐｓ通信で送受信し、受信側で結合したり解凍して元データを得ることが考えられる。
【０００４】
Ｗｅｂサイトの構築において高セキュリティ化の技術は日々進化しており、通信経路上にリバースプロキシ技術を適用したＷｅｂサイトが考えられている。これは、クライアントから送信されたデータを一時的にリバースプロキシサーバにキャッシュし、該キャッシュしたデータをバックエンドのサーバに送付する方式を採るものである。
【０００５】
【特許文献１】特開２００２−２４１９１
【０００６】
【特許文献２】特開平１１−５５３２４
【０００７】
【発明が解決しようとする課題】
上述の特許文献１や特許文献２に記載の技術では、大容量のデータをクライアントとサーバとの間で送受信する場合、通信経路上のキャッシュ機能に負担（大容量のデータをキャッシュするための大容量の実メモリが必要）がかかる。
【０００８】
上述のリバースプロキシ技術は、大容量の１ファイルを送受信する場合は、当該リバースプロキシサーバ内のキャッシュメモリとして大容量の実メモリが必要であり、キャッシュ機能に負担がかかる。この場合、従来の技術の欄で述べたファイル分割技術を適用してファイルを複数に分割したとしても、それら分割した複数ファイルを同一リクエストで送信した場合は、分割していない大きな１つのファイルを送信するときと変わらず、キャッシュ機能に負荷をかける。ｈｔｔｐ通信では問い合わせ応答の１リクエスト単位に処理するため、１リクエスト単位にキャッシュするためである。例えば、１００ＭＢのファイルを送信する場合、そのまま送信すると１００ＭＢがキャッシュされるので実メモリを１００ＭＢ使用することになる。当該ファイルを１０ＭＢ毎に１０個に分割したとしても、１リクエストでそれら１０個の分割ファイルを送信すると、サーバ上では１０ＭＢ×１０個で１００ＭＢのキャッシュが必要となる。
【０００９】
本発明は、大容量のファイルを送受信する場合でも、通信経路上のキャッシュ機能に負担をかけないデータ転送方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、請求項１に係る発明は、ネットワークに接続されたクライアント端末とＷｅｂサーバとの間でｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、送信側装置の処理手段が、送信するファイルを所定サイズに分割するステップと、前記送信側装置の処理手段が、受信側装置に、分割した結果の各分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各分割ファイルをデータ転送するステップと、受信側装置の処理手段が、前記別々のリクエストでそれぞれ転送された各分割ファイルを結合し、元ファイルを取得するステップとを備えたことを特徴とする。
【００１１】
請求項２に係る発明は、ネットワークに接続されたクライアント端末からＷｅｂサーバにｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、前記クライアント端末の処理手段が、送信するファイルを所定サイズに分割するステップと、前記クライアント端末の処理手段が、前記Ｗｅｂサーバに、分割した結果の各分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各分割ファイルをデータ転送するステップと、前記Ｗｅｂサーバの処理手段が、前記別々のリクエストでそれぞれ転送された各分割ファイルを結合し、元ファイルを取得するステップとを備えたことを特徴とする。
【００１２】
請求項３に係る発明は、ネットワークに接続されたクライアント端末からＷｅｂサーバにｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、前記クライアント端末の処理手段が、送信するファイルを圧縮するステップと、前記クライアント端末の処理手段が、前記圧縮したファイルを所定サイズに分割するステップと、前記クライアント端末の処理手段が、前記Ｗｅｂサーバに、分割した結果の各分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各分割ファイルをデータ転送するステップと、前記Ｗｅｂサーバの処理手段が、前記別々のリクエストでそれぞれ転送された各分割ファイルを結合し、前記圧縮したファイルを取得するステップと、前記Ｗｅｂサーバの処理手段が、前記圧縮したファイルを解凍し、元ファイルを取得するステップとを備えたことを特徴とする。
【００１３】
請求項４に係る発明は、ネットワークに接続されたクライアント端末からＷｅｂサーバにｈｔｔｐまたはｈｔｔｐｓ通信でデータ転送するデータ転送方法であって、前記クライアント端末の処理手段が、送信するファイルを所定サイズに分割するステップと、前記クライアント端末の処理手段が、前記分割した結果の各分割ファイルをそれぞれ圧縮するステップと、前記クライアント端末の処理手段が、前記Ｗｅｂサーバに、各圧縮後の分割ファイル毎にｈｔｔｐまたはｈｔｔｐｓ通信の別々のリクエストで、各圧縮後の分割ファイルをデータ転送するステップと、前記Ｗｅｂサーバの処理手段が、前記別々のリクエストでそれぞれ転送された各圧縮後の分割ファイルをそれぞれ解凍し、各分割ファイルを取得するステップと、前記Ｗｅｂサーバの処理手段が、前記取得した各分割ファイルを結合し、元ファイルを取得するステップとを備えたことを特徴とする。
【００１４】
請求項５に係る発明は、請求項２から４の何れか１つに記載のデータ転送方法において、前記クライアント端末の処理手段は、前記クライアント端末のＣＰＵと該ＣＰＵが実行するプログラム（予めクライアント端末にインストールされているソフトウェア部品および動作時にＷｅｂサーバからダウンロードされて実行されるソフトウェア部品を含む）から構成されるものであることを特徴とする。
【００１５】
請求項６に係る発明は、請求項２から４の何れか１つに記載のデータ転送方法において、前記Ｗｅｂサーバの処理手段は、前記ＷｅｂサーバのＣＰＵと該ＣＰＵが実行するサーバアプリケーションプログラムから構成されるものであることを特徴とする。
【００１６】
【発明の実施の形態】
以下、本発明の実施形態に関して、図面を使用して、具体的に説明する。
【００１７】
図１に、本発明の方法を適用したシステムの全体構成の概要を示す。１０１ａ〜１０１ｃは、それぞれＷｅｂブラウザ１０２ａ〜１０２ｃを有するクライアント端末で、インターネット１０３に接続可能な端末である。１０３は、大量データを送信する通信路であるインターネットである。１０４は、大量データを受信するＷｅｂサイトであり、各利用者に各種サービスを提供する。１０５は、セキュリティを高めるために適用されているリバースプロキシサーバであり、本サーバを実装することにより、高セキュリティを実現する。リバースプロキシサーバ１０５は、クライアントから送信されるデータを一時蓄積するキャッシュ領域１０７を備えている。１０６は、各種サービスを提供するＷｅｂサーバであり、サービス利用時に大量データファイルの送信を受け付ける。
【００１８】
図２は、図１のクライアント端末側の処理の流れを示すフローチャートである。
【００１９】
ステップ２０１では、送信ファイルを指定する。これは、クライアント端末のＷｅｂブラウザで、Ｗｅｂサイト１０４にアップロードするファイルを指定する処理である。次にステップ２０２で、圧縮処理によりデータサイズを縮小する。具体的には、指定されたアップロードファイルを、ＡｃｔｉｖｅＸ（マイクロソフトコーポレイションの登録商標）またはクライアントアプリケーションを用いて圧縮する処理である。次にステップ２０３で、ファイル分割処理により、指定サイズ毎にデータを分割する。これは、圧縮したアップロードファイルを、ＡｃｔｉｖｅＸまたはクライアントアプリケーションを用いて複数の分割ファイルに分割する処理である。各分割ファイルが指定サイズとなるように分割する。また、分割ファイル名は、予め定められたルールで付ければよいが、ここでは元ファイル名に対して分割番号（分割したときの何番目のファイルかを示す番号であり、ここでは３桁とする）を付ける方式とする。具体的には、元ファイル名がＵＰＴＥＳＴＤＡＴＡ．ｃｓｖで、３ファイルに分割する場合、分割ファイル名は、元ファイルに分割番号を付けて、ＵＰＴＥＳＴＤＡＴＡ．ｃｓｖ００１、ＵＰＴＥＳＴＤＡＴＡ．ｃｓｖ００２、およびＵＰＴＥＳＴＤＡＴＡ．ｃｓｖ００３となる。
【００２０】
次にステップ２０４で、分割ファイルを１ファイル毎にサーバ（Ｗｅｂサイト１０４）に送信する。これは、圧縮し分割したファイルを、ＡｃｔｉｖｅＸまたはクライアントアプリケーションを用いて送信する処理である。プロトコルは、例えばｈｔｔｐまたはｈｔｔｐｓ通信を用いる。ファイルは１ファイル毎にセッションを分け別リクエストで送信する。具体的には、以下のようにする。まずファイル送信時にセッションキー情報を一緒に送付する。セッションキー情報とは、分割した複数ファイルを別セッション（別リクエスト）で送付しサーバ側で結合するために、分割されたセッションを関連付けるキー情報であり、例えば、認証ユーザＩＤまたはｃｏｏｋｉｅ情報などのユニーク情報、送信するファイルを特定する情報、および日時情報（ミリ秒まで）などを結合して作成する。あるセッションのリクエストで分割ファイルを１ファイル送信し、サーバから当該送信処理の正常終了のリターンを取得すると、そのセッションの終了となる。正常終了のリターンを受信したら、新たなセッションのリクエストで次の分割ファイルを送信する。このとき１ファイル目で送信した際に使用したセッションキーを一緒に送付する。最後の分割ファイル送信時には、最終ファイルフラグを付けて送付する。
【００２１】
ステップ２０５で全ての分割ファイルを送信したか否か判定し、未だ送信すべき分割ファイルがあったら、ステップ２０４を繰り返す。最後の分割ファイルを送信し終えたら、正常終了のリターンをＷｅｂブラウザに返す。途中で障害が発生した場合は、エラーリターンをＷｅｂブラウザに返す。
【００２２】
上記図２の処理は、ステップ２０１でユーザが送信ファイルを指定して送信指示を入力すれば、それ以降はユーザが介在することなく自動的に実行される。具体的には、クライアント端末のＣＰＵ（中央処理装置）が予めクライアント端末にインストールされているソフトウェア部品および動作時にＷｅｂサーバからダウンロードされて実行されるソフトウェア部品を使用して、これらの処理を行うものである。
【００２３】
図３は、図１のＷｅｂサーバ１０６側の処理のフローチャートである。
【００２４】
ステップ３０１で、１ファイルを受信する。これは、クライアント端末から送信された分割ファイルをｈｔｔｐまたはｈｔｔｐｓ通信プロトコルで受信する処理である。受信処理は、サーバサイドアプリケーションにて行う。ファイル受信後、当該受信ファイルを一時的なワーク領域３１１に格納する。なお、ファイル名重複を避けるために、ファイル名を変更（ファイル名に適当な文字を追加）して、ワーク領域３１１に格納するものとする。
【００２５】
ステップ３０２では、受信した分割ファイルに関するファイル情報をテーブルに格納する。この処理は、サーバサイドアプリケーションにて行う。具体的には、分割ファイル管理情報格納部３１２内の分割ファイル管理情報テーブルに下記の情報を書き込む。書き込む情報は、「セッションキー」、「ファイル番号」、「ファイル名＿フルパス」、および「登録日時」である（図４，５で後述）。「ファイル番号」は分割の何番目のファイルかを示す番号である。「セッションキー」および「ファイル番号」によって、各分割ファイルは本システム内でユニークに区別できる。上記処理が正常終了した場合、レスポンスとして正常リターンを返す。
【００２６】
ステップ３０３で、最終ファイルを処理したか判定する。これはクライアントから送信される最終ファイルフラグにより判定する。最終ファイルでないときは、次の分割ファイルが送信されてくるはずだから、ステップ３０１に戻って受信処理を繰り返す。最終の分割ファイルが送られてきたら、最終ファイル送信の正常終了のリターンをＷｅｂブラウザに返す。途中で障害が発生した場合はエラーリターンをＷｅｂブラウザに返す。
【００２７】
次に、ステップ３０４で、ファイル結合処理により圧縮データとする。このファイル結合処理は、サーバサイドアプリケーションにて行う。具体的には、以下のような処理である。まず、結合対象ファイル名の取得処理を行う。これは分割ファイル管理情報テーブルから、最終ファイルが送られたセッションのセッションキーと一致するセッションキーをすべて探索し、探索されたセッションキーに対応するファイル番号が００１から最終ファイルのファイル番号まで揃っていることを確認した後、それらの分割ファイルのファイル名＿フルパスを取得する処理である。そして、取得したファイル番号００１から最終ファイルのファイル番号までの分割ファイルを結合して、元ファイルを生成する。さらに、ファイル削除処理にて、前記元ファイルの結合に使用した、ワーク領域に格納されている分割ファイルを、削除する。また、分割ファイル管理情報テーブルから、前記削除した分割ファイルに対応するレコードを削除する。
【００２８】
次に、ステップ３０５で、前記結合処理で得られた元ファイルに対し解凍処理を施して元データに戻す。解凍処理は、サーバサイドアプリケーションにて行う。
【００２９】
上記図３の処理は、基本的には人が介在することなく自動的に実行される。具体的には、ＷｅｂサーバのＣＰＵ（中央処理装置）が予めインストールされているサーバアプリケーションプログラムを使用して、これらの処理を行うものである。
【００３０】
図２および図３の手順でファイル転送を行うことにより、転送するファイルが大容量である場合でも、自動的に、分割され各分割ファイルは別リクエストで転送され受信側で結合される。したがって、通信経路上のキャッシュ機能（例えばリバースプロキシサーバ）への負担が小さい。
【００３１】
図４および図５は、図３の手順によりファイルデータが具体的にどのように処理されるかを示したブロック図である。４０３は図１のクライアント１０１ａなどからＷｅｂサイト１０４に送られるファイルデータＡ（元ファイルのファイル名はＡ０４１８．ｄａｔとする）を示す。受信ファイルデータＡは、実際には、分割されて複数の分割ファイルデータとして、１セッションで１分割ファイルずつ送られてくる。
【００３２】
ファイル受信処理４０１の受信ファイル一時保存４１１は、主として図３のステップ３０１に相当する。この処理により、受信ファイル一時保存領域３１１に、分割されてそれぞれ送られてきた分割ファイルデータが保存される。例えば図４では、受信ファイルデータＡ４０３を分割した第１番目の分割ファイルデータＡＡＡ＿Ａ０４１８．ｄａｔ００１、２番目の分割ファイルデータＡＡＡ＿Ａ０４１８．ｄａｔ００２、および３番目の分割ファイルデータＡＡＡ＿Ａ０４１８．ｄａｔ００３が格納されている。なお、受信ファイルについては、ファイル名重複を避けるために、各分割ファイルのファイル名の先頭にＡＡＡ＿を追加して格納している。ただし、受信ファイルのファイル名として、元のファイル名と全く無関係な名称を付けて格納するようにしてもよい。分割ファイル管理情報テーブル４０２により、セッションキーとファイル番号で特定されるファイルがどれかは分かるからである。
【００３３】
ファイル情報格納処理４１２は、主として図３のステップ３０２に相当する。この処理により、分割ファイル管理情報テーブル４０２に、受信ファイル一時保存領域３１１に一時保存した各分割ファイルデータの情報を格納する。図４の分割ファイル管理情報テーブル４０２では、「セッションキー」と「ファイル番号」と「ファイル名＿フルパス」と「登録日時」とを格納している。「セッションキー」は、当該分割ファイルが転送されてきたときに一緒に送られてきたセッションキーを格納する。「ファイル番号」は、受信した分割ファイルのファイル名の末尾３桁を参照することにより取得したファイル番号を格納する。「ファイル名＿フルパス」は、受信ファイル一時保存４１１が受信ファイルを一時保存領域３１１に格納する際に付けたファイル名をフルパスで記載する。「登録日時」は、当該分割ファイル管理情報テーブル４０２に各レコードを登録した日時（図では秒以下は省略して＊＊とした）を記載する。
【００３４】
なお、セッションキー中の「ユーザＩＤ」の部分は、実際には当該ファイルを送信したユーザを特定するユーザＩＤが設定されている。アンダーバーを挟んでユーザＩＤの次に、送信されたファイルのファイル名を特定するデータが設定される。例えば、セッションキー４１１中の「Ａ０４１８」は、当該分割ファイルの元ファイル名の一部である。セッションキー中の「日時」は、実際にはクライアント側で元ファイルを分割した第１番目の分割ファイル送信時の日時（ミリ秒まで含む）である。図４の４１１〜４１３の３つのセッションキーは、受信ファイルデータＡ（元ファイル名Ａ０４１８．ｄａｔ）を分割した３つの分割ファイルのセッションキーであるので、同じ値である。
【００３５】
分割ファイルの最終ファイルを受信したときは、図５のファイル受信処理（最終ファイル）５０１を実行する。この処理５０１は、主として図３のステップ３０４，３０５に相当する。
【００３６】
まず、受信ファイル情報取得５１１により、受信した最終ファイルのセッションキーをキーとして分割ファイル管理情報テーブルを探索する。例えば、受信ファイルデータＡ（元ファイル名Ａ０４１８．ｄａｔ）であればファイル番号が００３の分割ファイルが最終ファイルであるので、当該最終ファイルのセッションキー４１３と同じ値のセッションキーが探索される。ここでは４１１と４１２が見つかるので、結果として３つの分割ファイルのフルパスのファイル名をすべて取得できる。ファイル結合処理５１２は、前記取得した３つの分割ファイルのファイルを一時保存領域３１１から取り出して結合・解凍する。受信ファイルデータＡの例では、ＡＡＡ＿Ａ０４１８．ｄａｔ００１、ＡＡＡ＿Ａ０４１８．ｄａｔ００２、およびＡＡＡ＿Ａ０４１８．ｄａｔ００３が結合・解凍される。これにより、元の受信ファイルデータＡ５０３が取得される。
【００３７】
なお、上記実施形態では、クライアントからＷｅｂサーバへのアップロードに本発明を適用した例で説明したが、本発明はＷｅｂサーバからクライアントにファイルを転送する場合にも適用可能である。また、転送するファイルを圧縮した後に分割し、サーバ側では結合した後に解凍しているが、転送するファイルを分割した後に各分割ファイルを圧縮して転送し、サーバ側では受信ファイルを解凍して各分割ファイルを取得し、その後、結合するようにしてもよい。
【００３８】
【発明の効果】
以上、説明したように、本発明によれば、Ｗｅｂシステムで通信経路上のキャッシュ機能（リバースプロキシサーバ）に負荷をかけずに大量データの転送を実現できる。クライアントの利用者は、送信ファイルを指定して送信指示を与えるだけでデータ転送が行われ、例えばデータの圧縮、分割、セッション分割、サーバサイドでのデータ組み立て、解凍などの処理は自動で行われるので、利用者に対する操作負荷なくデータ転送を実現することが可能となる。また、本発明に係る方法はＷｅｂサーバの負荷分散の点でも効果がある。すなわち、１セッションで大量のデータが送付される場合、従来はＷｅｂサーバのセッションが占有されていたが、本発明に係る方法では複数回に分けてデータを送付することにより、Ｗｅｂサーバのセッションの占有を防ぐことができる。
【図面の簡単な説明】
【図１】本発明の実施形態のシステム構成を示す概念図
【図２】クライアント端末側の処理フロー図
【図３】Ｗｅｂサーバ側の処理フロー図
【図４】Ｗｅｂサーバ側の処理詳細（その１）図
【図５】Ｗｅｂサーバ側の処理詳細（その２）図
【符号の説明】
１０１ａ〜１０１ｃ…クライアント端末、１０３…インターネット網、１０４…サービスを提供するＷｅｂシステム、１０５…リバースプロキシサーバ、１０６…Ｗｅｂサーバ、４０３…受信したファイル、４０１…ファイル受信プログラム、４１１…受信ファイル一時保存処理、４１２…ファイル情報格納処理、３１１…受信ファイル一時保存領域、４０２…分割ファイル管理情報テーブル（例）、５０１…ファイル受信プログラム（最終ファイル処理）、５１１…受信ファイル情報取得処理、５１２…ファイル結合処理、５０３…受信したファイル（結合後）。
【図１】
2005011119.tif 000003
【図２】
2005011119.tif 000004
【図３】
2005011119.tif 000005
【図４】
2005011119.tif 000006
【図５】
2005011119.tif 000007