トップ :: G 物理学 :: G06 計算;計数

【発明の名称】 ファイル転送システム
【発明者】 【氏名】荻原 利彦
【氏名】山下 豊一郎
【氏名】高井 敦
【氏名】石井 茂
【氏名】須藤 忍
【氏名】長谷部 潤
【課題】インターネットなどのIPネットワーク上において電子的なファイルを、ネットワークで送受信している間に、ファイルの盗聴、改竄や送受信者への成りすましに対して安全であり、且つファイヤーウォールを通過させるために汎用性の高いHTTPを利用することにより、利用者の利便性を確保し、且つ大容量のファイルの転送を行うためのバッチ処理的な利用を可能とする。

【解決手段】ネットワーク002において、転送サーバ001を介し、送信クライアント003から受信クライアント004へ電子ファイル006を転送するファイル転送システムであって、転送される電子ファイル006に関する情報を記述した制御ファイルを用いて、クライアント間で転送する。この制御ファイルには、ファイルの転送先の情報を１または複数記述するとともに、転送サーバとの間のフアイルの転送手順や、セキュリティ制御に関する情報を記述する。
【特許請求の範囲】
【請求項１】 ネットワークにおいて、転送サーバを介し、送信クライアントから受信クライアントへ電子ファイルを転送するファイル転送システムにおいて、転送される電子ファイルに関する情報を記述した制御ファイルを、送信クライアントと受信クライアントとの間で転送する転送手段を有することを特徴とするファイル転送システム。
【請求項２】 前記制御ファイルにファイルの転送先が少なくても１つ以上記載されていることを特徴とする請求項１記載のファイル転送システム。
【請求項３】 さらに転送サーバ上にある制御ファイルの転送先を送信クライアントによって変更可能とする手段を有することを特徴とする請求項１記載のファイル転送システム。
【請求項４】 送信クライアントが、送信するファイルをブロック化する手段と、暗号化する手段と、ブロック化した情報を制御ファイルに書きこむ手段を有し、受信クライアントが、暗号化されたブロックを復号化する手段と、復号化したブロックを制御ファイルに書きこまれているブロック化した情報をもとにファイルを組み立てる手段を有することを特徴とする請求項１記載のファイル転送システム。
【請求項５】 送信クライアントから転送サーバにファイルを転送する際に異常があった場合に送信クライアントが未送信のブロック化したファイルのみを送信する手段を有することを特徴とする請求項４記載のファイル転送システム。
【請求項６】 転送サーバから受信クライアントにファイルを転送する際に異常があった場合に受信クライアントが未受信のブロック化したファイルのみを受信する手段を有することを特徴とする請求項４記載のファイル転送システム。
【請求項７】 制御ファイルが送信クライアントから受信クライアントのみで情報交換を行う部分と、送信クライアントから受信クライアント間、送信クライアントから転送サーバ間、転送サーバから受信クライアント間で情報交換を行う部分との、２階層で構成されていることを特徴とする請求項１〜６のいずれか１項に記載のファイル転送システム。
【請求項８】 前記制御ファイルの送信クライアントから受信クライアントのみで情報交換を行う部分が受信クライアントのみで復号化できる暗号で記載されていることを特徴とする請求項７記載のファイル転送システム。
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、コンピュータ通信分野における、電子的なファイルの転送技術に関するものであり、特にインターネット、エキストラネット、及びイントラネットに代表されるIP（Internet Protocol）ネットワークにおいて上記電子的なファイルを安全且つ簡単に送受信するためのファイル転送システムに関する。
【０００２】
【従来の技術】インターネットやイントラネットに代表されるIPベースのネットワークの普及にともない、パーソナルコンピュータのワードプロセッサソフトウェアや、DTP（デスクトップ・パブリッシング)ソフトウェアなどで作成した電子的なファイルをフロッピーディスクなどの記憶媒体に記録して郵便で送るのではなく、上記ネットワークを介して、取引先などの遠隔地に転送し、輸送コストの削減をはかる、若しくは輸送にかかる時間を短くしたいというニーズが顕在化している。
【０００３】
【発明が解決しようとする課題】従来、上記ネットワークを用いたファイルの転送にはE-mail（電子メール）による添付ファイルが利用されているが、一般にインターネットを利用したE-mail送受信では、インターネットのサービス提供者がE-mailを転送するためのSMTPサーバのディスク容量を保護するために、1M〜2Mバイト以上のメールの転送を拒否する制限を施している場合が多く、制限以上のファイルを転送するためには、事前にファイルを例えばワードプロセッサのファイルであれば、数ページ単位に上記ファイルを分割してサイズを小さくして送信する必要があった。従って、本発明はファイルのサイズによらないファイル転送システムを提供することを目的としている。
【０００４】また、ファイルを転送するための先行技術としてFTP(File Transfer Protocol)サーバ、及びクライアントを利用する方法がある(図31)。FTPは元来IPネットワーク上でファイルを転送するためのアプリケーション・プロトコルであるが、下記の２点においてファイルの簡単な送受信を妨げる。第一点は、インターネットに接続している多くの企業がファイヤーウォールを設置しており、ウイルス等に感染している危険なファイルの受信や、社内文書のファイルを流出を防ぐ目的でFTPプロトコルのポートを止めており、利用者の端末から容易にFTPプロトコルを利用できない。このため、従来は一旦送信するためのファイルをファイヤーウォールの外側のマシンに移し、上記マシンから送信する必要があり、同様に受信のためのFTPサーバもファイヤーウォールの外側に設置する必要があり、ファイルのセキュリティ上も問題があった。
【０００５】第二に、FTPクライアント〜サーバシステムでは、基本的に送信クライアントからファイルをサーバにPUT[013]し、受信クライアント021は、受信者みずからがFTPサーバ020にログイン[015]し、目的のファイルをGET[017]する必要があり、容量の大きいファイルを早く転送したい場合、例えば夜間にファイルを送信し、翌朝までにファイルを取り出したい場合、翌朝人手を介してGETを実行しなければ目的の受信クライアント021にファイルを届けることができなかった。
【０００６】なお、図31において、FTPサーバ020と、ファイルを送信する側のFTP（送信）クライアント019間では、ファイルを送信する際に、FTP（送信）クライアント019からのログイン[011]、それに対するFTPサーバ020のレスポンス[012]、FTP（送信）クライアント019からのPUT（アップロード）[013]、それに対するFTPサーバ020のレスポンス[014]の信号のやりとりが行われる。また、FTPサーバ020と、FTP（受信）クライアント021間では、ファイルを受信するする際に、FTP（受信）クライアント021からのログイン[015]、それに対するFTPサーバ020のレスポンス[016]、FTP（受信）クライアント017からのGET（ダウンロード）[017]、それに対するFTPサーバ020のレスポンス[018]の信号のやりとりが行われる。
【０００７】従って、本発明はファイヤーウォールで一般的に利用可能になっているHTTP(Hyper Text Transfer Protocol)を利用し、送信クライアントから受信クライアントに、簡易にファイルを送るためのファイル転送システムを提供することを目的とする。
【０００８】さらに、上記HTTPプロトコルを利用したファイルの転送方法の先行技術の例としては、例えば図32に示すようなWWW(World Wide Web)を利用したシステムにおいて、ファイルの送信者に向け、WWWサーバ038からFORM（フォーム）タグを記述したHTML(Hyper Text Markup Language)ファイル(図33)をWWWブラウザ037に送信し、上記WWWブラウザにて送信するファイルを選択し、例えば“ファイル送信”ボタンを押すことにより、指定したファイルをWWWサーバ038にアップロードし、受信者は、上記アップロードされたファイルへのURL(Uniform Resource Locator)にWWWブラウザ039でアクセスすることによりファイルを受信する方法が挙げられる。この手法によるファイル転送においても下記の２点において安全且つ簡単なファイル転送の実現が妨げられる。
【０００９】第一に送信したファイルの第三者への秘匿の確保が困難である点が上げられる。アップロード、ならびにダウンロード時においてWWWブラウザとWWWサーバの間でSSL(Secure Socket Layer)を利用すれば、送受信クライアントとWWWサーバ間は暗号通信が実施され、ファイルを第三者に盗み見される危険性を下げることは可能である。しかし、上記FORMタグを利用した手法では送信したファイルはCGI(Common Gateway Interface)に代表されるサーバ側のプログラムに平文で引き渡される。従って悪意のある第三者がサーバにアクセスし、ファイルを盗み見るプログラムをしかけた場合、これに防御できない。
【００１０】第二に、アップロードしたファイルをWWWブラウザを用いて利用者がダウンロードする場合、事前にファイルが格納されている場所を示す、URLを知っておく必要がある。このURLを受信者に通知するためE-mail等でURLを受信者に通知し、受信者はそのE-mailに記述されたURLに対しWWWブラウザでアクセスし、目的のファイルをダウンロードする方法が上げられるがこの場合、ダウンロードは受信者が指示してから開始される。従って容量の大きいファイルをバッチ処理的に夜間に人手を介さずに受信者のクライアントに届けることはできない。
【００１１】なお、上記の図32に示すシステムにおいては、送信側のWWWブラウザ（送信）037とWWWサーバ038との間では、一般に、WWWブラウザ（送信）037とWWWサーバ038との間では、一般に、WWWブラウザ（送信）037からWWWサーバ038へのGETコマンドの送信[031]、WWWサーバ038からWWWブラウザ（送信）037へのHTML文書の送信[032]、WWWブラウザ（送信）037からWWWサーバ038へのFORMタグによるファイルの送信指示の送信[033]、WWWサーバ038からWWWブラウザ（送信）037へのレスポンス[034]という通信のやりとりが行われる。また、受信側のWWWブラウザ（受信）039とWWWサーバ038との間では、WWWブラウザ（受信）039からWWWサーバ038へのGETコマンドの送信[035]と、WWWサーバ038からWWWブラウザ（受信）039へのレスポンスとファイル転送[036]のための通信が行われる。なお、図33は、ファイルを送信する際に用いられるFORMタグを利用したHTMLファイルの一例を示したものである。
【００１２】以上により、本発明はインターネットやイントラネット、エクストラネットなどのIPネットワーク上において電子的なファイルを、上記ネットワークで送受信している間に、ファイルの盗聴、改竄や送受信者への成りすましに対して安全であり、且つファイヤーウォールを通過させるために汎用性の高いHTTPを利用することにより、利用者の利便性を確保し、且つ大容量のファイルの転送を行うためのバッチ処理的な利用を可能とするファイル転送システムを提供することを目的とする。
【００１３】
【課題を解決するための手段】上記課題を解決するため、請求項１記載の発明は、ネットワークにおいて、転送サーバを介し、送信クライアントから受信クライアントへ電子ファイルを転送するファイル転送システムにおいて、転送される電子ファイルに関する情報を記述した制御ファイルを、送信クライアントと受信クライアントとの間で転送する転送手段を有することを特徴としている。
【００１４】また、請求項２記載の発明は、前記制御ファイルにファイルの転送先が少なくても１つ以上記載されていることを特徴としている。また、請求項３記載の発明は、さらに転送サーバ上にある制御ファイルの転送先を送信クライアントによって変更可能とする手段を有することを特徴としている。また、請求項４記載の発明は、送信クライアントが、送信するファイルをブロック化する手段と、暗号化する手段と、ブロック化した情報を制御ファイルに書きこむ手段を有し、受信クライアントが、暗号化されたブロックを復号化する手段と、復号化したブロックを制御ファイルに書きこまれているブロック化した情報をもとにファイルを組み立てる手段を有することを特徴としている。
【００１５】また、請求項５記載の発明は、送信クライアントから転送サーバにファイルを転送する際に異常があった場合に送信クライアントが未送信のブロック化したファイルのみを送信する手段を有することを特徴としている。また、請求項６記載の発明は、転送サーバから受信クライアントにファイルを転送する際に異常があった場合に受信クライアントが未受信のブロック化したファイルのみを受信する手段を有することを特徴としている。
【００１６】また、請求項７記載の発明は、制御ファイルが送信クライアントから受信クライアントのみで情報交換を行う部分と、送信クライアントから受信クライアント間、送信クライアントから転送サーバ間、転送サーバから受信クライアント間で情報交換を行う部分との、２階層で構成されていることを特徴としている。また、請求項８記載の発明は、前記制御ファイルの送信クライアントから受信クライアントのみで情報交換を行う部分が受信クライアントのみで復号化できる暗号で記載されていることを特徴としている。
【００１７】
【発明の実施の形態】本発明のシステムの構成例を図1に示す。送信クライアント003は、電子ファイル006を送信するためのアプリケーションを搭載したパーソナルコンピュータを示し、受信クライアント004は電子ファイルを受信するためのアプリケーションを搭載したパーソナルコンピュータを示す。電子ファイルは、上記送信クライアントから1つまたは複数の上記受信クライアントに送信される電子的な1つまたは複数のファイルを示している。
【００１８】上記送信クライアント、及び上記受信クライアントは通常同じパーソナルコンピュータで機能させる。また上記送信クライアント、及び上記受信クライアントはネットワーク002に接続されており、上記ネットワークはインターネット、イントラネット、エクストラネットに代表されるIPネットワークである。さらに上記送信クライアントと上記受信クライアントの間にはネットワークを介して転送サーバ001、及びCA(Certificate Authority)サーバ005が接続されており、上記送信クライアント、上記転送サーバ、及び上記受信クライアントは、それぞれ送信者、転送サーバ、受信者を特定するための受信者識別子があらかじめ割り当てられている。
【００１９】尚、CAサーバは先行技術により、上記送信クライアント、上記転送サーバ、及び上記受信クライアントからの要求に基づき、上記受信者識別子で指定された上記送信クライアント、上記転送サーバ、及び上記受信クライアントのいずれかの公開鍵を安全に要求元に送信するプログラム、及び装置を示す。上記、転送サーバとCAサーバは同じコンピュータ上で動作してもよいし、また別のコンピュータ上で動作させてもよい。
【００２０】上記送信クライアントから送信する電子ファイル006は、ネットワークを介し、一旦転送サーバに送信される。このプロセスをアップロード処理007と呼ぶ。転送サーバに転送された上記電子ファイルはさらに受信クライアントへ送信される。このプロセスをダウンロード処理008と呼ぶ。
【００２１】さらに上記電子ファイルのアップロードの最中にネットワークの障害等、なんらかの要因で電子ファイルの転送が中断された後に、ファイルの残りの部分の転送を行うプロセスをアップロード再送信処理、同様に上記電子ファイルのダウンロードの最中にファイルの転送が中断された後に、電子ファイルの残りの部分の転送を行うプロセスをダウンロード再受信処理と呼ぶ。
【００２２】本発明において上記送信クライアント、及び上記受信クライアントから上記転送サーバに向けた要求メッセージ、及び上記転送サーバから上記送信クライアント、及び上記受信クライアントに向けたレスポンスメッセージは全てアプリケーションのプロトコルとしてHTTPを利用し、HTTPで規定されたフォーマット(RFC（Request for Comments）2068)に従う。これにより、ファイヤーウォールで守られたネットワーク内から、HTTPのポートが空けてあれば、HTTP PROXY(代理)サーバを利用した環境で本発明の利用が可能となる。図2にクライアントから転送サーバへのHTTPの規定に準拠した要求メッセージの実現例を示す。request commandには要求メッセージの種別、application/X-contentTypeNameには要求メッセージに対応したMIMEタイプにあらかじめ上記クライアント〜転送サーバ間で規定した値を記述する。転送サーバはこのrequest command若しくはapplication/X-contentTypeNameの値を確認することによりクライアントからの要求メッセージを識別する。データ文はメッセージに付属するパラメータ若しくは、送受信の対象となる電子ファイルのデータが記述され、クライアントから転送サーバに引き渡される。
【００２３】図3に転送サーバからクライアントへのHTTPの規定に準拠したレスポンスメッセージの実現例を示す。response commandにはレスポンスメッセージの種別、application/X-contentTypeNameにはレスポンスメッセージに対応したMIMEタイプにあらかじめ上記クライアント〜転送サーバ間で規定した値を記述する。クライアントはこのresponse command若しくはapplication/X-contentTypeNameを判読することにより転送サーバからのレスポンスメッセージを識別する。データ文はメッセージに付属するパラメータ若しくは、送受信の対象となる電子ファイルのデータが記述され転送サーバからクライアントへ引き渡される。
【００２４】本発明では上記送信クライアント〜上記受信クライアント間で送受信する電子ファイルに関する情報をファイルに記述し(このファイルを制御ファイルと呼ぶ)、上記制御ファイルを上記送信クライアント〜上記転送サーバ、上記転送サーバ〜受信クライアント間で送受信することにより、送受信する電子ファイルに関する情報の交換を行う。
【００２５】上記制御ファイルは送信クライアント〜受信クライアント間のみで情報交換を行うための部分、及び送信クライアント〜受信クライアント間、送信クライアント〜転送サーバ間、転送サーバ〜受信クライアント間で情報交換を行うための部分により構成され、それぞれ制御ファイル1、制御ファイル0と呼ぶ。
【００２６】制御ファイル1のフォーマットの実現例を図4に示す。上記制御ファイル1には制御ファイル毎にユニークな制御ファイル識別子、及びMasterDEK(Master DataEncryption Key)が記述される。MasterDEKは、送受信する電子ファイル(upfile.i:i=1,2,...,n)を暗号化するDEK.i(i=1,2,...,n)を暗号化(隠蔽されたDEK.i)する、若しくは隠蔽された(暗号化）されたDEK.iを復号化しDEK.iを取り出す為に利用される(電子ファイルupfile.iはDEK.iで暗号化される)。
【００２７】制御ファイル1の記述例を図5に示す。
【００２８】上記制御ファイル1は、送信者から転送サーバ、受信者、及び上記送信者自身に対して相互認証可能なE-mail暗号規格、例えばMOSS（Mime Object Security Service）(RFC1848)により、フォーマットを変換(暗号化を含む)される。フォーマット変換された制御ファイル1の実現例を図6に示す。
【００２９】実現例におけるRecipient-ID)には上記電子ファイルの送信者、及び上記電子ファイルの受信者の受信者識別子を、ctrlfile 1 boundary内にDEK(Data Encryption Key)を用いて秘密鍵暗号方式、例えばFealにて暗号化された制御ファイル1が記述される。
【００３０】Recipient-IDに続くKey-infoは対をなし、上記Key-infoには上記制御ファイル1を暗号化したDEKを、鍵交換方式例えばDiffie&Hellmanの方式(後述）により求めた本制御ファイル1の送信者と、続くRecipient-IDに含まれた受信者識別子を持つ受信者との共有鍵で暗号化した値が含まれる。
【００３１】本記述例では、受信者の識別子としてE-mailアドレスのフォーマットを利用し、送信者自身、sender@winca、及び受信者としてreceiver0@winca、receiver1@wincaに対し制御ファイル1の解読を認めている。注意すべき点は転送サーバのRecipient-IDとKey-infoが無いことである。この事実はこの制御ファイル1の内容を転送サーバ自身は解読できない、すなわち上記MasterDEKを取り出せないことを意味する。転送サーバは上記MasterDEKを取り出せないことから、上記送受信する電子ファイル（upfile.i)の暗号化に利用する上記DEK.iを隠蔽されたDEK.iから復号化できないことを意味する。すなわち転送サーバではupfile.iを復号化して中身を見ることは不可能になる。
【００３２】上記先行技術Diffie&Hellmanの方式を図7に示す。まず制御ファイル1を暗号化するためのDEKを制御ファイル1の送信者側で生成する。制御ファイル1の送信者側は自分の秘密鍵と送信先(受信者)の公開鍵をもちいて送信者と受信者で共有可能な鍵Kabを生成する。このKabも用いて上記DEKを例えばFEALなどの秘密鍵暗号方式で暗号化したものを受信者のRecipient-IDと対をなすKey-infoに記述する。MOSSフォーマット化された制御ファイル1の受信者は自分の秘密鍵と送信者の公開鍵より鍵Kbaを求める。（Kab=Kba)のため受信者ではKbaを用いてKey-infoを復号化しDEKを取り出し、制御ファイル1を復号化しMasterDEKを取得可能となる。
【００３３】上記MOSSフォーマット化された制御ファイルの交換を送信者〜受信者間で行うと相互認証が可能な点に注意すべきである。悪意のある第三者が送信者になりすまし制御ファイルを上記MOSSフォーマット化された制御ファイルの送信を企てた場合、共有鍵Kabは、真の送信者の秘密鍵を知り得なくては作成できない。仮にでたらめに生成したとしても、受信者は送信者を真の送信者として共有鍵Kbaを算出し、Key-infoを復号化するので真KabとKbaは同じ値にならないので真のDEKを取り出すことは不可能になる。
【００３４】また、真の受信者ではない第三者がMOSSフォーマット化された制御ファイルを入手しても、正当な受信者の秘密鍵を知らなくては真の共有鍵Kbaを算出できない。したがって、MOSSフォーマット化された制御ファイルの送受信が論理的に成功すれば、送信側〜受信側での相互認証がされたことになる。本発明では上記相互認証可能なE-mail暗号規格、例えばMOSSによりフォーマット変換を行うため、送信者、転送サーバ、受信者はあらかじめ例えば上記鍵交換方式例えばDiffie Hellman方式により公開鍵、秘密鍵を求めておく。さらに上記秘密鍵は送信クライアント、転送サーバ、受信クライアントにおいて例えば暗号化されて保持されており、また公開鍵はCAサーバで管理されており、送信クライアント、転送サーバ、受信クライアントの要求に従い指定された受信者識別子により該当する公開鍵を返す。
【００３５】制御ファイル0のフォーマットの実現例を図8に示す。上記制御ファイル０には制御ファイル毎にユニークな制御ファイル識別子、送信されるファイルのパス名(upfile.i:i=1,2,...,n）、送信されるファイルを例えばあらかじめ指定されたサイズに分割した各ブロック(これをブロックファイルと呼ぶ)のファイル名(upfile.i.j:i=1,2,...,n;j=1,2,...,m)、及び上記ブロックファイルからハッシュ関数例えばSHA−1により算出したハッシュ値(OrgMD.i.j:i=1,2,...,n;j=1,2,...,m),及びDEK.i(i=1,2,...,n)により秘密鍵暗号方式例えばfealにより暗号化された上記ブロックファイルからハッシュ関数例えばSHA-1により算出したハッシュ値(EncMD.i.j:i=1,2,...,n;j=1,2,...,m)、及び上記ブロックファイルを暗号化するために生成した上記DEK.iを上記MasterDEKで暗号化した上記隠蔽されたDEK.iを全てのブロックファイル毎、全ての送信ファイル毎に記述し、最後に上記MOSSフォーマット化された制御ファイル1を記述する。
【００３６】上記電子ファイルの分割は、上記電子ファイルのアップロード、またはダウンロード時になんらかの障害がおきファイルの送受信が中断された場合に、再度上記電子ファイルを頭から送受信するのではなく、送受信できなかったブロックファイルから再度電子ファイルのアップロード(これをアップロード再送信処理と呼ぶ)、またはダウンロード(これをダウンロード再受信処理と呼ぶ)を行うために実施するものであり、送受信するファイルのサイズが比較的小さい場合、必ずしも実施する必要はない。
【００３７】上記制御ファイル0の記述例を図9及び図10に示す。なお、図9と図10は、２図でで１つのファイルを示している。
【００３８】本記述例では送信ファイルupfolder\jpeg\logo.jpgを、logo.jpg.1、logo.jpg.2、…、logo.jpg.nのブロックファイルに分割し、ファイルupfolder\w3\index.htmを、index.htm.1、index.htm.2、...、index.htm.nに分割して送信することを示している。
【００３９】尚、ctrlfile 1 boundary内部は上記MOSSフォーマット化された制御ファイル1を示している。
【００４０】制御ファイル0を送信する際には相互認証可能なE-mail暗号規格、例えば上記MOSSによりフォーマット変換を行い、文書の暗号化を行う。
【００４１】MOSSフォーマット化された制御ファイル0の実現例を図11に示す。
【００４２】制御ファイル0の内容は転送サーバで解読する必要があるため、Recipient-IDに送信者、受信者に加え転送サーバの受信者識別子の例server@wincaが記述されている。これにより制御ファイル0の内容は転送サーバにて解読可能となる。Ctrlfile0 boundary内部のデータは暗号化された制御ファイル0を示す。
【００４３】送信クライアントは上記制御ファイルを暗号化するためのDEKを生成し、制御ファイル0を秘密暗号方式例えばFEALなどで暗号化する。
【００４４】暗号化に用いたDEKは、制御ファイルの送信者、受信者、転送サーバ毎に鍵交換方式例えば上記Diffie Hellman方式により生成した共有鍵により秘密暗号方式例えばFealにより暗号化され、送信者、受信者、転送サーバの受信者識別子を含むRecipient-IDに続く、Key-infoに設定される。
【００４５】以上により、制御ファイル0の送受信者は送受信が論理的に成功すれば相互に認証が可能となる。
【００４６】本発明の装置構成の実現例を図12に示す。またアップロード処理におけるフロチャートの実現例を図13、図14、及び図15に示す。なお、図13、図14、及び図15は、一連の処理の流れを示すフロチャートを分割して示したものであって、各図の接続点は、同一の符号を円で囲った結合子（例えば図13の結合子C01と図14の結合子C01が接続される。）を用いて示している（以降のフロチャートでも同様）。
【００４７】なお、図12において、送信または受信側のクライアント601は、ファイル選択処理部603、受信者選択処理部604、送信処理部605、受信処理部606、リクエスト組立処理部607、レスポンス解析処理部608、制御ファイル生成処理部609、制御ファイル解析処理部610、DEK生成処理部611、ハッシュ処理部612、復号処理部613、暗号処理部614、公開鍵取得処理部615、ブロック処理部616、内部メモリ618、トランザクション制御部619、外部記憶装置620、及びタイマ621から構成されている。また、１または複数のクライアント601とネットワークを介して接続された転送サーバ651は、送信処理部652、受信処理部653、リクエスト解析処理部654、レスポンス組立処理部655、制御ファイル解析処理部656、公開鍵取得処理部657、ハッシュ処理部658、復号処理部659、暗号処理部660、データベース制御処理部661、ブロック処理部662、内部メモリ663、トランザクション制御部664、データベース665、外部記憶装置666、及びDEK生成処理部667から構成されている。なお、各部の基本的な機能は、各部の名称から自明であるが、詳細な機能についての説明は、以下のフロチャートを参照した動作の説明において行う。また、本発明のファイル転送システムは、コンピュータと、それによって実行されるソフトウェアプログラムとから、上記の各部の機能を実現することができるが、そのプログラムは、コンピュータ読みとり可能な記録媒体に記録して頒布することが可能である。
【００４８】以下、アップロード処理の実現例について説明する。
【００４９】ステップ100では、送信者は送信クライアントにて送信する電子ファイルの送り先を受信者識別子で指定する。受信者識別子は例えば受信者のE-mailアドレスなど一意に受信者を特定できる文字列であればよい。但し、上記受信者識別子はCAサーバより上記受信者の公開鍵が取得できるものでなくてはならない。また、電子ファイルの受信者（ファイルの転送先）は一人ないし複数でかまわない。受信者の指定は受信者選択処理部604でユーザインタフェースを介して行われる。指定された受信者の識別子は内部メモリに格納される。
【００５０】次にステップ101では、送信者は送信クライアントにて送信する電子ファイル、若しくは電子ファイルの集合であるフォルダを指定し、送信クライアントに対して送信を指示する。ここで電子ファイルの指定やフォルダの指定は1つであっても複数であってもかまわない。電子ファイルやフォルダの指定はファイル選択処理部603においてユーザインタフェースを介して行われる。指定された電子ファイルのファイル名、若しくはフォルダ指定された場合は、フォルダ内の全ファイルへのパス名を内部メモリに記憶する。ここで指定された電子ファイルをupfile.i(i=1,2,...,n)と表現する。
【００５１】次にステップ102では、送信クライアントではトランザクション制御部619がブロック処理部616に依頼し、上記内部メモリに格納されたパス名が指し示す全電子ファイル（upfile.i)を、例えばあらかじめ指定されたサイズの上記ブロックファイル(upfile.i.j)に分割し、分割された各々のブロックにブロックファイル名（upfile.i.j(i=1,2,...,n;j=1,2,...,m)と表現する。)を付与し、内部メモリまたは外部記憶装置620において送信が完了するまで保存される。但し、本ステップは省略してもかまわない。
【００５２】次にステップ103では、送信クライアントではトランザクション制御部619が公開鍵取得処理部615に依頼し、内部メモリに記憶している上記受信者の受信者識別子、外部記憶装置620に記録されている送信者自身の受信者識別子、及び転送サーバの受信者識別子をキーにCAサーバに公開鍵の取得の要求メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【００５３】次にステップ104では、送信クライアントではトランザクション制御部619がDEK生成処理部611に依頼し、例えば乱数などを用いてMasterDEKを生成し内部メモリに格納する。さらに送信する電子ファイル(upfile.i)毎に各々のブロックファイルを暗号化するための鍵（DEK.i)を例えば乱数などを用いて生成し、上記電子ファイル名と関連づけて内部メモリに記憶する。
【００５４】次にステップ105では、送信クライアントではトランザクション制御部619がハッシュ処理部612に依頼し、外部記憶装置に記録された上記全てのブロックファイル(upfile.i.j)(i=1,2,...,n;j=1,2,...,m)のハッシュ値をハッシュ関数例えばSHA-1を用いて暗号化前のハッシュ値（OrgMD.i.j)を計算し、上記ブロックファイル名(upfile.i.j）と関連づけて内部メモリに記憶する。
【００５５】次にステップ106では、送信クライアントではトランザクション制御部619が暗号処理部614に依頼し、外部記憶装置に記録された上記全てのブロックファイル(upfile.i.j)を暗号化するためのDEK.iを内部メモリより取得し、秘密鍵暗号方式例えばFealを用いて暗号化を行い、さらに暗号化された各ブロックファイルのハッシュ値をハッシュ関数例えばSHA-1を用いてハッシュ処理部にて暗号化後のハッシュ値(EncMD.i.j)を計算し、ブロックファイル名(upfile.i.j)と関連づけて内部メモリに記憶する。また暗号化されたupfile.i.jは上記ブロック処理部を介して外部記憶装置に保存される。
【００５６】次にステップ107では、送信クライアントではトランザクション制御部619が暗号処理部614に依頼し、内部メモリよりMasterDEK、及び全てのDEK.iを取りだし、上記DEK.iをMasterDEKを用い方式例えばfealで暗号化し、隠蔽されたDEK.iを生成し、電子ファイル(upfile.i)と関連づけて内部メモリに保存する。
【００５７】次にステップ108では、送信クライアントではトランザクション制御部619が制御ファイル生成処理部609に依頼し、ユニークな制御ファイル識別子を、例えば乱数などの方法で生成し内部メモリに記憶し、内部メモリよりMasterDEKを取りだし、上記制御ファイル識別子とともに制御ファイル1を生成し、さらに内部メモリより、送信者自身の公開鍵、受信者全員の受信者識別子と公開鍵を取り出し、送信者の受信者識別子と秘密鍵を外部記憶装置より取り出し、つづいて制御ファイル1を暗号化するためのDEKを例えば乱数にてDEK生成部に依頼し生成し、第一番目のRecipient-IDに送信者自身の受信者識別子を、続くKey-infoに共有鍵交換方式、例えばDiffie Hellman方式により送信者自身の公開鍵と秘密鍵より生成した共有鍵で制御ファイル1を暗号化するためのDEKを暗号化したものを設定し、二番目以降のRecipient-IDに受信者の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により上記受信者の公開鍵と送信者の秘密鍵より生成した共有鍵で制御ファイル1を暗号化するためのDEKを暗号化したものを設定し、上記生成した制御ファイル1と上記生成したDEKを暗号処理部に依頼し、秘密暗号化方式例えばFealで暗号し、上記制御ファイル1をMOSSフォーマットに変換し外部記憶装置に保存する。
【００５８】次にステップ109では、送信クライアントではトランザクション制御部619が制御ファイル生成処理部609に依頼し、内部メモリより上記生成した制御ファイル識別子を取得し、さらに内部メモリより、上記MOSSフォーマット化した制御ファイル1、送信する電子ファイルのパス、送信する電子ファイルのブロックファイル名、各ブロックファイルに対応するOrgMD.i.j、EncMDi.j、隠蔽されたDEK.iを読み出し、上記制御ファイル識別子とともに制御ファイル0を生成し、さらに内部メモリより、送信者自身の公開鍵、転送サーバの公開鍵、及び受信者全員の受信者識別子と公開鍵を取り出し、送信者の受信者識別子と秘密鍵、及び転送サーバの受信者識別子を外部記憶装置より取り出し、つづいて制御ファイル0を暗号化するためのDEKをDEK生成部に依頼し例えば乱数にて生成し、第一番目のRecipient-IDに送信者自身の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により送信者自身の公開鍵と秘密鍵より生成した共有鍵で制御ファイル0を暗号化するためのDEKを暗号化したものを設定し、二番目以降のRecipient-IDに受信者の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により上記受信者の公開鍵と送信者の秘密鍵より生成した共有鍵で制御ファイル0を暗号化するためのDEKを暗号化したものを設定し、最後のRecipient-IDに転送サーバの受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により転送サーバの公開鍵と送信者の秘密鍵より生成した共有鍵を制御ファイル0を暗号化するためのDEKで暗号化したものを設定し、上記生成した制御ファイル0と上記生成したDEKを暗号処理部に依頼し、秘密暗号化方式例えばFealで暗号し、上記制御ファイル0をMOSSフォーマットに変換し外部記憶装置に保存する。
【００５９】次にステップ110では、送信クライアントではトランザクション制御部619が、リクエスト組立処理部607に依頼し、電子ファイルの転送サーバへのアップロードを要求するメッセージ(例えばupload依頼要求(開始)要求メッセージと呼ぶ)を要求メッセージとして、図2に示したHTTPに準拠した要求メッセージのフォーマットの実現例に従い、あらかじめupload依頼要求(開始）要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として上記制御ファイルを設定し、upload依頼要求(開始）要求メッセージを生成し、生成した上記要求メッセージを送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、転送サーバでは送られてきた要求メッセージを受信処理部653が受信し、リクエスト解析処理部654に渡し、上記リクエスト解析処理部では、要求メッセージのrequest commandの値から、upload依頼要求(開始)要求メッセージであることを識別しトランザクション制御部664に通知し、データ文フィールドより第一番目のRecipient-IDから送信者の受信者識別子を取り出し、内部メモリに記憶する。
【００６０】次にステップ111では、転送サーバではトランザクション制御部が公開鍵取得処理部657に依頼し、内部メモリに記憶している上記送信者の受信者識別子、例えば外部記憶装置666に記憶されている転送サーバ自身の受信者識別子をキーにCAサーバに公開鍵の取得メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【００６１】次にステップ112では、転送サーバではトランザクション制御部が、制御ファイル解析処理部656に依頼し、上記受信した要求メッセージに含まれる制御ファイルより、内部メモリより取得した転送サーバの受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と受信者の秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化されたDEKを復号化し、上記DEKを用いて制御ファイルを復号化し制御ファイル0を取得し、復号化した制御ファイル0の文脈をチェックし、規定された制御ファイルのフォーマットとして解読不能の場合は、不正な制御ファイルの送信と判断しエラー処理に入り、解読可能な場合は、上記制御ファイル0を内部メモリまたは外部記憶装置に記録する。
【００６２】次にステップ113では、転送サーバでは上記トランザクション制御部において、上記記録された制御ファイル0より制御ファイル識別子を取得し、データベース制御処理部に依頼し、上記制御ファイル識別子をキーとしてデータベースに記録された電子ファイルのアップロードトランザクションを管理しているテーブル（図27)を検索し、対応するレコードが存在する場合、アップロード再送信処理に入る。対応するテーブルが存在しない場合、ユニークなトランザクション識別子を例えば乱数にて生成し内部メモリに格納する。
【００６３】次にステップ114では、転送サーバでは上記トランザクション制御部において、上記記録された制御ファイル0より制御ファイル識別子、及び受信者の受信者識別子を取得し、上記内部メモリより上記トランザクション識別子を取得し、上記データベース上の電子ファイルのアップロードトランザクションを管理しているテーブルに対し、上記制御ファイル識別子、及び新たに生成したトランザクション識別子、及びステータスを未完としたフィールド値を持つレコードを新たに追加し、さらに制御ファイルを管理しているテーブル(図28)に、上記制御ファイル識別子、上記受信者識別子、上記MOSSフォーマット化された制御ファイルそのものをフィールド値としてもつレコードを新たに追加し、さらに上記制御ファイル0より送信される全てのブロックファイル(upfile.i.j)に対して上記制御ファイル識別子、ブロックファイル名(upfile.i.j)、Enc.i.j、及び隠蔽されたDEK.iを取りだし、データベースのブロックファイルを管理しているテーブル（図29)に、全ての送信されるブロックファイル(upfile.i.j)に対して上記取得した制御ファイル識別子、ブロックファイル名(upfile.i.j)、Enc.i.jをフィールド値とするレコードを追加する。
【００６４】次にステップ115では、転送サーバでは、上記トランザクション制御部がレスポンス組立処理部655に依頼し、受信したupload依頼要求(開始)要求メッセージに対応するレスポンスメッセージ(例えばupload依頼要求(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめupload依頼要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記生成したトランザクション識別子を設定し、upload依頼要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、送信クライアントにネットワークを介して送信し、送信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponsecommandフィールドの値から、upload依頼要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子を取り出し、内部メモリに格納し、トランザクション制御部に通知する。
【００６５】次にステップ116では、送信クライアントでは、トランザクション制御部において、リクエスト組立処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶された送信するファイルブロック名、及び送信ログより、未アップロードの暗号化されたファイルブロック名を取得し、上記ブロックファイル名に対応する暗号化されたブロックファイルの1つを転送サーバにアップロードすることを要求するための要求メッセージ(例えばupload upfile.i.j依頼要求(開始)要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットにのっとり、あらかじめupload upfile.i.j依頼要求(開始)を要求メッセージとして、クライアント、転送サーバで決められたcontent-type、及びrequest commandを設定し、データ文として、第一に上記トランザクション識別子、第二に送信する暗号化されたブロックファイルのブロックファイル名、及び第三に外部記憶装置に保存された上記暗号化されたブロックファイル(upfile.i.j)を設定し、upload upfile.i.j依頼要求(開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信した要求メッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、upload upfile.i.j依頼要求(開始)要求メッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名、及び暗号化されたブロックファイル(upfile.i.j)を取得し、トランザクション制御部に通知し、データベース制御処理部661に依頼し、上記取得したトランザクション識別子をキーとしてデータベースに記録された電子ファイルのアップロードトランザクションを管理しているテーブルを検索し、マッチする制御ファイル識別子を取得し、さらに上記制御ファイル識別子、及び受信したブロックファイル名をキーとして、ブロックファイルを管理しているテーブルを検索し、マッチするレコードを取得し、受信したブロックファイルをブロック処理部662に依頼し、外部記憶装置に保存し、上記受信したブロックファイルの保存場所を、上記マッチしたブロックファイルを管理しているテーブルの上記レコードのブロックファイルの保存先フィールドの値として記録する。
【００６６】次にステップ117では、転送サーバでは、トランザクション制御部がレスポンス組立処理部625に依頼し、受信したupload upfile.i.j要求(開始)要求メッセージに対応するupload upfile.i.j(終了)レスポンスメッセージを、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめupload upfile.i.j(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記upload upfile.i.j要求(開始)要求メッセージより取得したトランザクション識別子、及びブロックファイル名を設定し、upload upfile.i.j要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、送信クライアントにネットワークを介して送信する。次に送信クライアントでは送られてきたレスポンスメッセージを受信処理部606にて受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、upload upfile.i.j(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名を取り出し、トランザクション制御部に通知し、上記トランザクション識別子、上記ブロックファイル名を、内部メモリまたは外部記憶装置に送信ログとして記録する。
【００６７】次にステップ118では、送信クライアントでは、トランザクション制御部が上記送信ログの記録をチェックし、未送信のブロックファイルがあるか調べる。未アップロードのブロックファイルがない場合、送信クライアントは処理を終了する。未送信のブロックファイルが1存在する場合、ステップ116に戻る。
【００６８】次にステップ119では、転送サーバではトランザクション制御部が、データベース制御処理部に依頼し、上記アップロードトランザクションを管理しているテーブルを、内部メモリに格納されている上記トランザクション識別子をキーに検索し、マッチする全レコードより制御ファイル識別子を取得し、上記制御ファイル識別子をキーに上記ブロックファイルを管理しているテーブルを検索し、マッチするレコードのEnc.i.j、及びブロックファイルの保存先を取得し、取得した上記ブロックファイルの保存先よりブロックファイル(upfile.i.j)を取得し、さらに上記取得したブロックファイルのハッシュ値を送信クライアントと転送サーバの間であらかじめ決められたハッシュ関数、例えばSHA-1を用いてハッシュ処理部658に依頼して算出し、上記Enc.i.jと比較し、結果が同値でないブロックファイルが存在する場合、エラー処理に入る。全てのハッシュ値が同値の場合、上記アップロードトランザクションを管理しているテーブルの上記検索されたレコードのステータスフィールドの値を完了に設定し、転送サーバはアップロード処理を終了する。
【００６９】アップロード再送信処理におけるフロチャートの実現例を図16、図17、及び図18に示す。
【００７０】以下、アップロード再開処理について説明する。
【００７１】ステップ201では、送信クライアントでは、トランザクション制御部がタイマ621を監視し、他のトランザクションが開始されていない状態であれば、あらかじめ指定された一定時間間隔でリクエスト組立処理部607に依頼し、パラメータで指定した条件を満たす制御ファイルの取得を要求する要求メッセージ(例えばlist要求(開始）要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットの実現例にのっとり、あらかじめlist要求(開始)要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として、アップロードが完了していないファイルの情報を含む制御ファイルを検索することをサーバに指示するパラメータ、及び送信者の受信者識別子を例えば外部記憶装置より取得して設定し、list要求(開始)要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、list要求(開始)要求メッセージであることを識別し、データ文フィールドより送信者の受信者識別子を取得し内部メモリに記憶し、さらにデータ文フィールドより上記要求メッセージがアップロードが完了していないファイルの情報を含む制御ファイルを検索することを指示していることを認識し、トランザクション制御部に通知する。
【００７２】次にステップ202では、転送サーバではトランザクション制御部が、上記内部メモリより送信者の受信者識別子を取得し、データベース制御処理部に依頼し、データベースの制御ファイルを管理しているテーブルを、送信者の受信者識別子をキーに検索し、マッチするレコードの制御ファイル識別子を取得し、取得した制御ファイル識別子をキーに、アップロードトランザクションを管理しているテーブルを検索し、ステータスフィールドが完了になっていないものを検索し、上記マッチしたレコードより制御ファイル識別子をキーに制御ファイルを管理しているテーブルを検索し、マッチしたレコードよりMOSSフォーマット化された制御ファイルを取得し、内部メモリまたは外部記憶装置に記録する。
【００７３】次にステップ203では、転送サーバでは、トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したlist要求(開始)要求メッセージに対応するlist要求(終了)レスポンスメッセージを、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめlist要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリまたは外部記憶装置に記録したMOSSフォーマット化された制御ファイルを設定し、list要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、送信クライアントにネットワークを介して送信する。次に送信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、list要求（終了)レスポンスメッセージであることを識別し、データ文フィールドよりMOSSフォーマット化された制御ファイルを取得し、内部メモリまたは外部記憶装置に記録し、トランザクション制御部に通知する。
【００７４】次にステップ204では、送信クライアントでは、トランザクション制御部がリクエスト組立処理部607に依頼し、転送サーバに対し制御ファイルの内容に関する情報を検索し返却することを要求する要求メッセージ(例えばinfo要求(開始）要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットの実現例にのっとり、あらかじめinfo要求(開始）要求メッセージとして、クライアント、転送サーバで取り決められたContent-type、及びrequest commandを設定し、データ文として、送信者の受信者識別子を、上記内部メモリまたは外部記憶装置に記憶された上記MOSSフォーマット化された制御ファイル、上記制御ファイルに記述されたブロックファイルのうち、アップロードが完了していないブロックファイル名(upfile.i.j)を検索し返却することをサーバに指示するパラメータを設定し、info要求(開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部652で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、info要求(開始)要求メッセージであることを識別し、データ文フィールドより送信者の受信者識別子、MOSSフォーマット化された制御ファイルを取得し、上記取得した送信者の受信者識別子を内部メモリに格納し、上記取得したMOSSフォーマット化された制御ファイルを内部メモリまたは外部記憶装置に記録し、さらにデータ文フィールドより上記要求メッセージがアップロードが完了していないブロックファイル名（upfile.i.j)を検索することを指示していることを認識し、トランザクション制御部に通知する。
【００７５】次にステップ205では、転送サーバではトランザクション制御部が公開鍵取得部に依頼し、内部メモリに記憶されている送信者の受信者識別子、例えば外部記憶装置に記憶されている転送サーバ自身の受信者識別子をキーにCAサーバに公開鍵の取得メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【００７６】次にステップ206では、転送サーバではトランザクション制御部が、制御ファイル解析処理部656に依頼し、上記受信した要求メッセージに含まれる制御ファイルより、例えば外部記憶装置に記憶されている転送サーバの受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化されたDEKを復号化し、上記DEKを用いて制御ファイルを復号化し制御ファイル0を取得し、復号化した制御ファイル0の文脈をチェックし、規定された制御ファイルのフォーマットとして解読不能の場合は、不正な制御ファイルの送信と判断しエラー処理に入り、解読可能な場合は、上記制御ファイル0を内部メモリまたは外部記憶装置に記憶し、上記制御ファイル0より制御ファイル識別子を取得し、内部メモリに記憶する。
【００７７】次にステップ207では、転送サーバではトランザクション制御部が、上記内部メモリより制御ファイル識別子を取得し、データベース管理部に依頼し、上記制御ファイル識別子をキーにデータベースのブロックファイルを管理しているテーブルを検索し、受信したブロックファイルの保存先が設定されていないレコードを検索し、マッチするレコードのブロックファイル名(upfile.i.j)を取得し内部メモリに格納する。
【００７８】次にステップ208では、転送サーバではトランザクション制御部が、内部メモリより上記取得したブロックファイル名(upfile.i.j)、送信者の公開鍵を取り出し、内部メモリより送信者の受信者識別子を取得し、さらに転送サーバの受信者識別子と秘密鍵を例えば外部記憶装置より取り出し、つづいて暗号処理部に依頼し上記ブロックファイル名(upfile.i.j)を暗号化するためのDEKを例えば乱数にて生成し、Recipient-IDに送信者の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により上記送信者の公開鍵と転送サーバの秘密鍵より生成した共有鍵で上記ブロックファイル名(upfile.i.j)を暗号化するためのDEKを暗号化したものを設定し、上記ブロックファイル名(upfile.i.j)と上記生成したDEKを暗号処理部に依頼し、上記DEKで秘密鍵暗号化方式例えばFealにて暗号化し、上記ブロックファイル名(upfile.i.j)をMOSSフォーマットに変換し外部記憶装置に記録する。
【００７９】次にステップ209では、転送サーバではトランザクション制御部が、レスポンス組立処理部655に依頼し、受信したinfo要求(開始)要求メッセージに対応するinfo要求(終了)レスポンスメッセージを、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめlist要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記記録されたMOSSフォーマット化されたブロックファイル名（upfile.i.j)を設定し、list要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、送信クライアントにネットワークを介して送信し、次に送信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、info要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりMOSSフォーマット化されたブロックファイル名(upfile.i.j)を取得し、内部メモリに格納し、トランザクション制御部に通知する。
【００８０】次にステップ210では、送信クライアントではトランザクション制御部619が公開鍵取得処理部615に依頼し、例えば外部記憶装置620に記録されている送信者自身の受信者識別子、及び転送サーバの受信者識別子をキーにCAサーバに公開鍵の取得の要求メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【００８１】次にステップ211では、送信クライアントではトランザクション制御部において、制御ファイル解析処理部610に依頼し、上記内部メモリまたは外部記憶装置に記録されているMOSSフォーマット化された制御ファイルより、送信者の受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたDEKを取り出し、さらに内部メモリより送信者、及び転送サーバの公開鍵を取得し、例えば外部記憶装置より送信者の秘密鍵を取得し、復号処理部615に依頼し、共通鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と送信者の秘密鍵より共有鍵を生成し、上記共有鍵を用いて上記暗号化されたDEKを復号化し、上記DEKを用いてMOSSフォーマット化された制御ファイルを復号化し、上記制御ファイル0を内部メモリまたは外部記憶装置に記録し、つづいて上記内部メモリに格納されているMOSSフォーマット化されたブロックファイル名(upfile.i.j)より、送信者の受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたDEKを取り出し、上記転送サーバの公開鍵、及び送信者の秘密鍵を復号処理部615に依頼し、共有鍵交換方式例えばDiffie Hellman方式により転送サーバの公開鍵と送信者の秘密鍵より共有鍵を生成し、上記共有鍵を用いて上記暗号化されたDEKを復号化し、上記DEKを用いて復号化された上記ブロックファイル名(upfile.i.j)を内部メモリまたは外部記憶装置に記録する。
【００８２】次にステップ212では、送信クライアントではトランザクション制御部619が、リクエスト組立処理部607に依頼し、電子ファイルの転送サーバへのアップロードを要求するメッセージ(例えばupload依頼要求(開始)要求メッセージと呼ぶ)を要求メッセージとして、図2に示したHTTPに準拠した要求メッセージのフォーマットの実現例に従い、あらかじめupload依頼要求(開始）要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として上記内部メモリまたは外部記憶装置に記憶したMOSS化された制御ファイルを設定し、upload依頼要求(開始）要求メッセージを生成し、生成した上記要求メッセージを送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、転送サーバでは送られてきた要求メッセージを受信処理部653が受信し、リクエスト解析処理部654に渡し、上記リクエスト解析処理部では、要求メッセージのrequest commandの値から、upload依頼要求（開始）要求メッセージであることを識別しトランザクション制御部664に通知し、データ文フィールドより第一番目のRecipient-IDから送信者の受信者識別子を取り出し、内部メモリに記憶する。
【００８３】次にステップ213では、転送サーバではトランザクション制御部が公開鍵取得処理部6571に依頼し、内部メモリに記憶している上記送信者の受信者識別子、外部記憶装置666に記憶されている転送サーバ自身の受信者識別子をキーにCAサーバに公開鍵の取得メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【００８４】次にステップ214では、転送サーバではトランザクション制御部が、制御ファイル解析処理部656に依頼し、上記受信した要求メッセージに含まれる制御ファイルより、例えば外部記憶装置より取得した転送サーバの受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化されたDEKを復号化し、上記DEKを用いて制御ファイルを復号化し制御ファイル0を取得し、復号化した制御ファイル0の文脈をチェックし、規定された制御ファイルのフォーマットとして解読不能の場合は、不正な制御ファイルの送信と判断しエラー処理に入り、解読可能な場合は、上記制御ファイル0を内部メモリまたは外部記憶装置に記録する。
【００８５】次にステップ215では、転送サーバでは上記トランザクション制御部において、上記記録された制御ファイル0より制御ファイル識別子を取得し、データベース制御処理部に依頼し、上記制御ファイル識別子をキーとしてデータベースに記録された電子ファイルのアップロードトランザクションを管理しているテーブル(図27)を検索し、マッチするレコードのトランザクション識別子を取得し、内部メモリに格納する。
【００８６】次にステップ216では、転送サーバでは、上記トランザクション制御部がレスポンス組立処理部655に依頼し、受信したupload依頼要求(開始）要求メッセージに対応するレスポンスメッセージ(例えばupload依頼要求(終了)レスポンスメッセージと呼ぶ）を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめupload依頼要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリから取得した上記トランザクション識別子を設定し、upload依頼要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、送信クライアントにネットワークを介して送信し、送信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、upload依頼要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子を取り出し、内部メモリに格納し、トランザクション制御部に通知する。
【００８７】次にステップ217では、送信クライアントでは、トランザクション制御部において、リクエスト組立処理部に依頼し、上記内部メモリに格納されたブロックファイル名、及び送信ログより未アップロードのブロックファイルを取得し、上記未アップロードのブロックファイルの1つを転送サーバにアップロードすることを要求するための要求メッセージ(例えばupload upfile.i.j依頼要求（開始）要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットにのっとり、あらかじめupload upfile.i.j依頼要求(開始）要求メッセージとして、クライアント、転送サーバで決められたcontext-type、及びrequest commandを設定し、データ文として、第一に上記内部メモリに格納されたトランザクション識別子、第二に送信する暗号化されたブロックファイルのブロックファイル名、及び第三に外部記憶装置に保存された上記ブロックファイル名に対応する暗号化されたブロックファイル(upfile.i.j)を設定し、upload upfile.i.j依頼要求（開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信した要求メッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、upload upfile.i.j依頼要求(開始）要求メッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名、及び暗号化されたブロックファイル(upfile.i.j)を取得し、トランザクション制御部に通知し、データベース制御処理部661に依頼し、上記取得したトランザクション識別子をキーとしてデータベースに記録されたファイルのアップロードトランザクションを管理しているテーブルを検索し、マッチする制御ファイル識別子を取得し、さらに上記制御ファイル識別子、及び受信したブロックファイル名をキーとして、ブロックファイルを管理しているテーブルを検索し、マッチするレコードを取得し、受信したブロックファイルをブロック処理部661に依頼し、外部記憶装置に保存し、上記受信したブロックファイルの保存場所を、上記マッチしたブロックファイルを管理しているテーブルの上記レコードのフィールド値として記録する。
【００８８】次にステップ218では、転送サーバでは、トランザクション制御部がレスポンス組立処理部622に依頼し、受信したupload upfile.i.j要求(開始)要求メッセージに対応するレスポンスメッセージ(例えばupload upfile.i.j(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめupload upfile.i.j(終了)をレスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記upload upfile.i.j要求(開始)要求メッセージより取得したトランザクション識別子、及びブロックファイル名を設定し、upload upfile.i.j要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、送信クライアントにネットワークを介して送信する。次に送信クライアントでは送られてきたレスポンスメッセージを受信処理部606にて受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、upload upfile.i.j(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名を取り出し、トランザクション制御部に通知し、上記トランザクション識別子、上記ブロックファイル名を、内部メモリまたは外部記憶装置に送信ログとして記録する。
【００８９】次にステップ219では、送信クライアントでは、トランザクション制御部が上記送信ログの記録、及び上記内部メモリに格納されたブロックファイル名をチェックし、未送信のブロックファイルがあるか調べる。未送信のブロックファイルがない場合、送信クライアントは上記トランザクション識別子に対応するアップロード処理を終了する。未送信のブロックファイルが存在する場合、ステップ217に戻る。
【００９０】次にステップ220では、転送サーバではトランザクション制御部が、データベース制御処理部に依頼し、上記アップロードトランザクションを管理しているテーブルを、内部メモリに格納されている上記トランザクション識別子をキーに検索し、マッチするレコードより制御ファイル識別子を取得し、上記制御ファイル識別子をキーに上記ブロックファイルを管理しているテーブルを検索し、マッチする全レコードのEnc.i.j、及びブロックファイルの保存先を取得し、取得した上記ブロックファイルの保存先よりブロックファイル(upfile.i.j)を取得し、さらに上記取得したブロックファイルのハッシュ値を送信クライアントと転送サーバの間であらかじめ決められたハッシュ関数、例えばSHA-1を用いてハッシュ処理部658に依頼して算出し、上記ハッシュ値を算出したブロックファイルに対応する上記レコードより取得したEnc.i.jと比較し、結果が同値でないブロックファイルが存在する場合、エラー処理に入る。全てのハッシュ値が同値の場合、上記アップロードトランザクションを管理しているテーブルの上記検索されたレコードのステータスフィールドの値を完了に設定し、転送サーバは上記トランザクション識別子に対応するアップロード処理を終了する。
【００９１】なお、実施の形態において、一旦送信したデータの送り先を変更する場合には、データを再送信する必要はなく、送信クライアントから転送サーバへ、同一のファイルに対して送り先を変更した情報を記述した制御ファイルを送ることで、転送サーバのデータベース内のデータを変更するができる。したがって、一旦送信したデータの送り先の変更を、制御ファイルの変更だけで行うことができ、データの再送信は不要となる。
【００９２】ダウンロード処理におけるフロチャートの実現例を図19、図20、図21、及び図22に示す。
【００９３】以下、ダウンロード処理について説明する。
【００９４】ステップ301では、受信クライアントでは、トランザクション制御部がタイマ621を監視し、他のトランザクションが開始されていない状態であれば、あらかじめ指定された一定時間間隔でリクエスト組立処理部607に依頼し、パラメータで指定した条件を満たす制御ファイルの取得を要求する要求メッセージ(例えばlist要求(開始)要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットの実現例にのっとり、あらかじめlist要求(開始)要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、受信者が電子ファイルの受信者に指定されており、且つ制御ファイルに記載された電子ファイルのダウンロードを全く開始していない制御ファイルを検索することをサーバに指示するパラメータ、及び受信者の受信者識別子を例えば外部記憶装置より取得してデータ文に設定し、list要求(開始)要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、list要求(開始)要求メッセージであることを識別し、データ文フィールドより受信者の受信者識別子を取得し内部メモリに記憶し、さらにデータ文フィールドより上記要求メッセージがファイルのダウンロードを全く開始していない制御ファイルを検索することをサーバに指示していることを認識し、トランザクション制御部に通知する。
【００９５】次にステップ302では、転送サーバではトランザクション制御部が、上記内部メモリより上記受信者の受信者識別子を取得し、データベース制御処理部に依頼し、データベースの制御ファイルを管理しているテーブルを、受信者の受信者識別子をキーに検索し、マッチするレコードの制御ファイル識別子を取得し、取得した制御ファイル識別子、及び上記受信者の受信者識別子をキーに、ダウンロードトランザクションを管理しているテーブルを検索し、上記検索にマッチするレコードのない制御ファイル識別子をキーに制御ファイルを管理しているテーブル(図30)を検索し、マッチしたレコードよりMOSS化された制御ファイルを取得し、内部メモリまたは外部記憶装置に記録する。
【００９６】次にステップ303では、転送サーバでは、トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したlist要求(開始）要求メッセージに対応するレスポンスメッセージ(例えばlist要求(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめlist要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリまたは外部記憶装置に記録したMOSSフォーマット化された制御ファイルを設定し、list要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信する。次に受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、list要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりMOSSフォーマット化された制御ファイルを取得し、内部メモリまたは外部記憶装置に記録し、トランザクション制御部に通知する。
【００９７】次にステップ304では、受信クライアントではトランザクション制御部619が、上記記録した制御ファイルの送信者の受信者識別子が設定されている第一番目のRecipient-IDより、上記送信者の受信者識別子を取得し内部メモリに記憶し、公開鍵取得処理部615に依頼し、上記内部メモリに記憶された送信者の受信者識別子、外部記憶装置620に記録されている受信者自身の受信者識別子、及び転送サーバの受信者識別子をキーにCAサーバに公開鍵の取得の要求メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【００９８】次にステップ305では、受信クライアントではトランザクション制御部において、制御ファイル解析処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶されたMOSSフォーマット化された制御ファイルより、受信者の受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化された制御ファイル0を暗号化するのに利用した暗号化されたDEKを取り出し、内部メモリより上記送信者の公開鍵を取得し、例えば外部記憶装置より受信者の秘密鍵を取得し、復号処理部613に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と受信者の秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化された上記制御ファイル0を暗号化するのに利用した暗号化されたDEKを復号化し、上記DEKを用いて制御ファイル0を復号化し、上記復号化した制御ファイル0の文脈をチェックし、規定された制御ファイル0のフォーマットとして解読不能の場合は、不正な制御ファイルの受信と判断し、エラー処理に入り、フォーマットに問題がない場合、上記制御ファイル0を内部メモリまたは外部記憶装置に記録し、さらに上記復号化された制御ファイル0に含まれるMOSSフォーマット化された制御ファイル1より、受信者の受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化された制御ファイル1を暗号化するのに利用した暗号化されたDEKを取り出し、復号処理部に依頼し上記共有鍵を用いて暗号化されたDEKを復号化し、上記DEKを用いて制御ファイル1を復号化し、内部メモリまたは外部記憶装置に記録し、上記制御ファイル0よりダウンロードする全ブロックファイル名を取得し、内部メモリに記憶する。
【００９９】次にステップ306では、受信クライアントではトランザクション制御部において、ユニークなdownloadTicketを例えば乱数を用いて生成し、内部メモリに格納する。
【０１００】次にステップ307では、受信クライアントでは、トランザクション制御部において、内部メモリより上記downloadTicket、受信者、及び転送サーバの公開鍵を取り出し、さらに転送サーバの受信者識別子と受信者の秘密鍵、及び受信者の受信者識別子を例えば外部記憶装置より取りだし、つづいて上記downloadTicket、受信者の受信者識別子を暗号化するためのDEKをDEK生成処理部に依頼し、上記DEKを例えば乱数にて生成し、第一番目のRecipient-IDに受信者の受信者識別子、続くkey-infoに共有鍵交換方式例えばDiffie Hellman方式により暗号処理部に依頼し、上記受信者の公開鍵と上記受信者の秘密鍵で生成した共有鍵で上記downloadTicket、受信者の受信者識別子を暗号するためのDEKを暗号化したものを設定し、第二番目のRecipient-IDに転送サーバの受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により暗号処理部に依頼し、上記転送サーバの公開鍵と上記受信者の秘密鍵で生成した共有鍵で上記downloadTicket、受信者の受信者識別子を暗号するためのDEKを暗号化したものを設定し、上記downloadTicket、受信者の受信者識別に渡し、上記DEKで上記downloadTicket、受信者の受信者識別子を秘密鍵暗号方式例えばFealにて暗号化し、downloadTicket、受信者の受信者識別子MOSSフォーマット化し、内部メモリまたは外部記憶装置に記憶する。
【０１０１】次にステップ308では、受信クライアントではトランザクション制御部619が、リクエスト組立処理部607に依頼し、電子ファイルの受信クライアントへのダウンロードを要求するメッセージ(例えばdownload依頼要求(開始）要求メッセージと呼ぶ)を要求メッセージとして、図2に示したHTTPに準拠した要求メッセージのフォーマットの実現例に従い、あらかじめdownload依頼要求(開始)要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として上記内部メモリまたは外部記憶装置に記憶したMOSSフォーマット化されたdownloadTicket、受信の受信者識別子、及び上記MOSSフォーマット化された制御ファイルを設定し、download依頼要求(開始)要求メッセージを生成し、生成した上記要求メッセージを送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、転送サーバでは送られてきた要求メッセージを受信処理部653が受信し、リクエスト解析処理部654に渡し、上記リクエスト解析処理部では、要求メッセージのrequest commandの値から、download依頼要求(開始)要求メッセージであることを識別しトランザクション制御部664に通知し、データ文フィールドより上記MOSSフォーマット化されたdownloadTicket、受信者の受信者識別子及び上記MOSSフォーマット化された制御ファイルを取得し、上記MOSSフォーマット化されたdownloadTicket、受信者の受信者識別子の第一番目のRecipient-IDより受信者の受信者識別子を取得し内部メモリに格納し、上記MOSSフォーマット化された制御ファイルの第一番目のRecipient-IDより送信者の受信者識別子を取得し内部メモリに格納し、上記取得したMOSSフォーマット化されたdownloadTicket、受信者の受信者識別子、及びMOSSフォーマット化された制御ファイルを内部メモリまたは外部記憶装置に記憶する。
【０１０２】次にステップ309では、転送サーバではトランザクション制御部が公開鍵取得部に依頼し、内部メモリに記憶されている受信者の受信者識別子、送信者の受信者識別子、例えば外部記憶装置に記憶されている転送サーバ自身の受信者識別子をキーにCAサーバに公開鍵の取得メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【０１０３】次にステップ310では、転送サーバではトランザクション制御部が、制御ファイル解析処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶された制御ファイルより、転送サーバの受信者識別子でRecipient-IDを検索し、続くkey-infoより暗号化された制御ファイル0の暗号化に利用したDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて上記暗号化された制御ファイル0の暗号化に利用したDEKを復号化し、上記復号化したDEKを用いて制御ファイル0を復号化し、内部メモリまたは外部記憶装置に記録する。このとき制御ファイル0の文脈をチェックし、制御ファイル0のフォーマットとして解読不能の場合、不正な制御ファイルの受信と判断しエラー処理に入り、フォーマットに問題がない場合、さらに上記受信した要求メッセージのMOSSフォーマット化されたdownloadTicket、受信者の受信者識別子より、転送サーバの受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたdownloadTicket、受信者の受信者識別子の暗号化に利用したDEKを取り出し、内部メモリより受信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により受信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化されたdownloadTicket、受信者の受信識別子の暗号化に利用したDEKを復号化し、上記DEKを用いてdownloadTicket、受信者の受信者識別子を復号化し、復号化した受信者識別子と内部メモリに記憶されている受信者識別子を比較し、上記比較結果が一致しない場合、不正なdownloadTicket、受信者の受信者識別子の受信と判断しエラー処理に入り、一致した場合、上記downloadTicketを内部メモリに記憶し、さらに上記復号化した制御ファイル0より制御ファイル識別子を取得し、内部メモリに記憶する。
【０１０４】次にステップ311では、転送サーバではトランザクション制御部が、ユニークなトランザクション識別子を例えば乱数にて生成し内部メモリに格納する。
【０１０５】次にステップ312では、転送サーバではトランザクション制御部が、データベース制御処理部に依頼し、ダウンロードトランザクションを管理しているテーブルに、上記内部メモリに記憶されている制御ファイル識別子、受信者の受信者識別子、及び上記生成したトランザクション識別子、及びdownloadTicketをフィールド値とするレコードを、ステータスフィールドを未完とし新たに追加する。
【０１０６】次にステップ313では、転送サーバでは、上記トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したdownload依頼要求(開始)要求メッセージに対応するレスポンスメッセージ(例えばdownload依頼要求(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめdownload依頼要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリから取得した上記トランザクション識別子を設定し、download依頼要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信し、受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、download依頼要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子を取り出し、内部メモリに格納し、トランザクション制御部に通知する。
【０１０７】次にステップ314では、受信クライアントでは、トランザクション制御部において、内部メモリに記憶されたダウンロードするブロックファイル名、及び受信ログより未ダウンロードのブロックファイルを取得し、リクエスト組立処理部に依頼し、上記取得されたブロックファイル名に対応するブロックファイルの1つを転送サーバからダウンロードすることを要求するための要求メッセージ(例えばdownload upfile.i.j要求(開始)要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットにのっとり、あらかじめdownload upfile.i.j要求(開始)要求メッセージとして、クライアント、転送サーバで決められたcontent-type、及びrequest commandを設定し、データ文として、第一に上記内部メモリに格納されたトランザクション識別子、第二に受信するブロックファイルのブロックファイル名、を設定し、download upfile.i.j要求(開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信した要求メッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、download upfile.i.j要求(開始)要求メッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名を取得し内部メモリに記憶する。
【０１０８】次にステップ315では、転送サーバではトランザクション制御部が、データベース制御処理部661に依頼し、上記取得したトランザクション識別子をキーとしてデータベースに記録されたファイルのダウンロードトランザクションを管理しているテーブルを検索し、マッチするレコードの制御ファイル識別子を取得し、さらに上記制御ファイル識別子、及び受信したブロックファイル名をキーとして、ブロックファイルを管理しているテーブルを検索し、マッチするレコードのブロックファイルの保存先を取得し、取得した保存先より暗号化されたブロックファイル(upfile.i.j)を取得し、内部メモリまたは外部記憶装置に記憶する。
【０１０９】次にステップ316では、転送サーバではトランザクション制御部が、レスポンス組立処理部に依頼し、受信したdownload upfile.i.j要求(開始）要求メッセージに対応するレスポンスメッセージ(例えばdownload upfile.i.j(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめdownload upfile.i.j(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリに格納されたトランザクション識別子、ブロックファイル名、及び内部メモリまたは外部記憶装置に記憶され暗号化されたブロックファイル(upfile.i.j)を設定し、download upfile.i.j要求(終了)レスポンスメッセージを生成し、送信処理部に渡し、受信クライアントにネットワークを介して送信する。次に受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、download upfile.i.j(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名を取得し内部メモリに格納し、さらにデータ文より暗号化されたブロックファイル(upfile.i.j)を取得し、外部記憶装置に上記ブロックファイル名と関連づけて記憶し、上記トランザクション識別子、上記ブロックファイル名を、内部メモリまたは外部記憶装置に受信ログとして記録する。
【０１１０】次にステップ317では、受信クライアントでは、トランザクション制御部が上記受信ログの記録、及び上記内部メモリに格納された受信するブロックファイル名をチェックし、未受信のブロックファイルがあるか調べる。未受信のブロックファイルが存在する場合、ステップ314に戻る。
【０１１１】次にステップ318では、受信クライアントでは、トランザクション制御部が上記内部メモリ若しくは外部記憶装置に保存している制御ファイル1よりMasterDEKを取得し、内部メモリに格納する。
【０１１２】次にステップ319では、受信クライアントでは、トランザクション制御部が、上記内部メモリ若しくは外部記憶装置に保存している制御ファイル0より、上記受信した外部記憶装置に記録されている全ての暗号化されたブロックファイル(upfile.i.j)に対応する全ての隠蔽されたDEK.iを、復号処理部に渡し、内部メモリに記憶されているMasterDEKにて復号化し、全てのブロックファイルを暗号化するのに利用したDEK.iを取得し、内部メモリにまたは外部記憶装置に記録する。
【０１１３】次にステップ320では、受信クライアントでは、トランザクション制御部が、上記受信した外部記憶装置に記録されている暗号化されたブロックファイル(upfile.i.j)の保存先と、上記内部メモリに格納されているDEK.iを復号処理部に渡し、上記暗号化されたブロックファイル(upfile.i.j)を復号化し、外部記憶装置に上記ブロックファイルのファイル名と関連づけて保存し、対応する暗号化されたブロックファイルを外部記憶装置より消去する。
【０１１４】次にステップ321では、受信クライアントでは、トランザクション制御部が、ハッシュ処理部に依頼し、上記復号化した全てのブロックファイル(upfile.i.j)のハッシュ値を送信クライアントと同一の方式、例えばSHA-1により算出し、上記内部メモリ若しくは外部記憶装置に記憶されている制御ファイル0より、上記ブロックファイル(upfile.i.j）に対応するOrgMD.i.jと比較する。ハッシュ値が同値でないブロックファイルが存在する場合、エラー処理に入る。
【０１１５】次にステップ322では、受信クライアントでは、トランザクション制御部が、ブロック処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶されている制御ファイル0に記述された電子ファイル(upfile.i）毎のブロックファイル名(upfile.i.j)の記述順序に従い、上記受信した外部記憶装置に記憶されている全ブロックファイルを上記電子ファイル毎に結合し、上記電子ファイルを復元し、上記復元した電子ファイルに、上記制御ファイル0に記述された上記電子ファイルのファイル名(相対パス名)を付与し、あらかじめ受信した電子ファイルの保存先としてきめられた外部記憶装置のディレクトリに、上記復元した電子ファイルを保存する。
【０１１６】次にステップ323では、受信クライアントでは、トランザクション制御部が、例えば外部記憶装置より受信者の受信者識別子を取得し、上記内部メモリに格納されているトランザクション識別子、downloadTicket及び上記ダウンロードが終了した電子ファイルのファイル名(upfile.i)を記述したCompleteTicketを生成し、内部メモリより受信者、及び転送サーバの公開鍵を取り出し、さらに受信者の受信者識別子と秘密鍵を例えば外部記憶装置より取りだし、つづいて上記Complete Ticketを暗号化するためのDEKをDEK生成処理部に依頼し、例えば乱数を用いて生成し、第一番目のRecipient-IDに受信者の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により受信者の公開鍵と受信者の秘密鍵より暗号処理部に依頼し共有鍵を生成し、上記生成した共有鍵で上記CompleteTicketを暗号するためのDEKを暗号処理部に依頼し暗号化したものを設定し、第二番目のRecipient-IDに転送サーバの受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により転送サーバの公開鍵と受信者の秘密鍵より暗号処理部に依頼し共有鍵を生成し、上記生成した共有鍵で上記CompleteTicketを暗号するためのDEKを暗号処理部に依頼し暗号化したものを設定し、上記CompleteTicketを暗号処理部に依頼し、上記DEKを秘密暗号方式例えばFealにて暗号化しCompleteTicketをMOSSフォーマット化し、内部メモリに格納する。
【０１１７】次にステップ324では、受信クライアントではトランザクション制御部619が、リクエスト組立処理部607に依頼し、電子ファイルの受信クライアントへのダウンロードの終了を通知する要求メッセージ(例えばdownload complete要求(開始）要求メッセージと呼ぶ)を要求メッセージとして、図2に示したHTTPに準拠した要求メッセージのフォーマットの実現例に従い、あらかじめdownload complete要求(開始)を要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として上記内部メモリまたは外部記憶装置に記憶したMOSSフォーマット化されたCompleteTicketを設定し、download complete要求（開始）要求メッセージを生成し、生成した上記要求メッセージを送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、転送サーバでは送られてきた要求メッセージを受信処理部653が受信し、リクエスト解析処理部654に渡し、上記リクエスト解析処理部では、要求メッセージのrequest commandの値から、download complete要求(開始)要求メッセージであることを識別しトランザクション制御部664に通知し、データ文フィールドより上記MOSSフォーマット化されたCompleteTicketを取得し、上記MOSSフォーマット化されたCompleteTicketを内部メモリまたは外部記憶装置に記憶する。
【０１１８】次にステップ325では、転送サーバではトランザクション制御部が、上記内部メモリより上記MOSSフォーマット化されたCompleteTicketを取得し、上記MOSSフォーマット化されたCompleteTicketの第一番目のRecipient-IDよりMOSSフォーマット化されたCompleteTicketの送信者(電子ファイルの受信者)の受信者識別子を取得し、内部メモリより上記受信者識別子に対応する受信者の公開鍵を取得し、続いて上記MOSSフォーマット化されたCompleteTicketの第二番目のRecipient-IDに例えば外部記憶装置に記録された転送サーバの受信者識別子が含まれることを確認し、続くkey-infoより暗号化されたDEKを取り出し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式によりMOSSフォーマット化されたCompleteTicketの送信者（電子ファイルの受信者)の公開鍵と、転送サーバの例えば外部記憶装置に記録された秘密鍵より共有鍵を生成し、上記共有鍵を用いて上記暗号化されたDEKを復号化し、上記DEKを用いて上記MOSSフォーマット化されたCompleteTicketを復号化し、復号化した上記Complete Ticketより、MOSSフォーマット化されたCompleteTicketの送信者(電子ファイルの受信者)の受信者識別子、トランザクション識別子、downloadTicket、受信ファイル名(upfile.i）を取りだし内部メモリに記憶する。このとき取り出した受信者識別子と内部メモリに格納されていた受信者の受信者識別子を比較し、同値でない場合、不正なCompleteTicketの受信と判断しエラー処理に入る。
【０１１９】次にステップ326では、転送サーバではトランザクション制御部が、データベース管理部に依頼し、ダウンロードトランザクションを管理しているテーブルを、上記内部メモリ記憶されているトランザクション識別子、及びdownloadTicketをキーに検索し、マッチしたレコードのステータスフィールドの値を完了にする。
【０１２０】次にステップ327では、転送サーバでは、上記トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したdownload complete依頼要求(開始)要求メッセージに対応するレスポンスメッセージ(例えばdownload complete要求(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめdownload complete要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリに格納されている受信クライアントから受信したdownloadTicket、及び上記内部メモリに格納されている受信クライアントから受信したトランザクション識別子を設定し、download complete要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信し、転送サーバは上記トランザクション識別子に対応するダウンロード処理を終了し、受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、download complete要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子を取り出し、トランザクション制御部に通知し、トランザクション制御部は、上記トランザクション識別子に対応するダウンロード処理を終了する。
【０１２１】ダウンロード再受信処理におけるフロチャートの実現例を図23、図24、図25、及び図26に示す。
【０１２２】以下、ダウンロード再受信処理について説明する。
【０１２３】ステップ401では、受信クライアントでは、トランザクション制御部がタイマ621を監視し、他のトランザクションが開始されていない状態であれば、あらかじめ指定された一定時間間隔でリクエスト組立処理部607に依頼し、パラメータで指定した条件を満たす制御ファイルの取得を要求する要求メッセージ(例えばlist要求(開始)要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットの実現例にのっとり、あらかじめlist要求(開始)要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、受信者が電子ファイルの受信者に指定されており、且つ制御ファイルに記載された電子ファイルのダウンロードが完了していない制御ファイルを検索することをサーバに指示するパラメータ、及び受信者の受信者識別子を例えば外部記憶装置より取得してデータ文に設定し、list要求(開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、list要求(開始)要求メッセージであることを識別し、データ文フィールドより受信者の受信者識別子を取得し内部メモリに記憶し、さらにデータ文フィールドより上記要求メッセージがファイルのダウンロードが完了していない制御ファイルを検索することをサーバに指示していることを認識し、トランザクション制御部に通知する。
【０１２４】次にステップ402では、転送サーバではトランザクション制御部が、上記内部メモリより受信者の受信者識別子を取得し、データベース制御処理部に依頼し、データベースの制御ファイルを管理しているテーブルを、受信者の受信者識別子をキーに検索し、マッチするレコードの制御ファイル識別子を取得し、取得した制御ファイル識別子、及び上記受信者の受信者識別子をキーに、ダウンロードトランザクションを管理しているテーブルを検索し、ステータスフィールドが完了になっていないものを検索し、上記マッチしたレコードの制御ファイル識別子をキーに制御ファイルを管理しているテーブルを検索し、マッチしたレコードよりMOSS化された制御ファイルを取得し、内部メモリまたは外部記憶装置に記録する。
【０１２５】次にステップ403では、転送サーバでは、トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したlist要求(開始)を要求メッセージに対応するレスポンスメッセージ(例えばlist要求(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめlist要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリまたは外部記憶装置に記録したMOSSフォーマット化された制御ファイルを設定し、list要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信する。次に受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、list要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりMOSSフォーマット化された制御ファイルを取得し、内部メモリまたは外部記憶装置に記録し、トランザクション制御部に通知する。
【０１２６】次にステップ404では、受信クライアントでは、トランザクション制御部がリクエスト組立処理部607に依頼し、転送サーバに対し制御ファイルの内容に関する情報を検索し返却することを要求する要求メッセージ(例えばinfo要求(開始)要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットの実現例にのっとり、あらかじめinfo要求(開始)要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として、受信者の送信者識別子、上記内部メモリまたは外部記憶装置に記憶されたMOSSフォーマット化された制御ファイル、上記制御ファイルに記述されたブロックファイルのうち、ダウンロードが完了していないブロックファイル名(upfile.i.j)を検索し返却することをサーバに指示するパラメータをデータ文に設定し、info要求(開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、info要求(開始)要求メッセージであることを識別し、データ文フィールドより受信者の受信者識別子、MOSSフォーマット化された制御ファイルを取得し、上記取得した受信者の受信者識別子を内部メモリに格納し、上記MOSSフォーマット化された制御ファイルの第一番目のRecipient-IDより上記制御ファイル(電子ファイル）の送信の受信者識別子を取得し内部メモリに記憶し、上記取得したMOSSフォーマット化された制御ファイルを内部メモリまたは外部記憶装置に記録し、さらにデータ文フィールドより上記要求メッセージがダウンロードが完了していないブロックファイル名(upfile.i.j)を検索することを指示していることを認識し、トランザクション制御部に通知する。
【０１２７】次にステップ405では、転送サーバではトランザクション制御部が公開鍵取得処理部657に依頼し、内部メモリに記憶している上記送信者の受信者識別子、上記受信者の受信者識別子、及び外部記憶装置666に記憶されている転送サーバ自身の受信者識別子をキーにCAサーバに公開鍵の取得メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【０１２８】次にステップ406では、転送サーバではトランザクション制御部が、制御ファイル解析処理部656に依頼し、上記受信した要求メッセージに含まれる制御ファイルより、内部メモリより取得した転送サーバの受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化されたDEKを復号化し、上記DEKを用いて制御ファイルを復号化し制御ファイル0を取得し、復号化した制御ファイル0の文脈をチェックし、規定された制御ファイルのフォーマットとして解読不能の場合は、不正な制御ファイルの送信と判断しエラー処理に入り、解読可能な場合は、上記制御ファイル0を内部メモリまたは外部記憶装置に記録する。
【０１２９】次にステップ407では、転送サーバではトランザクション制御部が、上記内部メモリまたは外部記憶装置に記録した制御ファイル0より制御ファイル識別子を取得し、データベース管理部に依頼し、上記内部メモリに格納された受信者識別子と上記制御ファイル識別子をキーにダウンロードトランザクションを管理しているテーブルを検索し、マッチするレコードよりdownloadTicketを取得し、内部メモリに格納する。
【０１３０】次にステップ408では、転送サーバではトランザクション制御部が、内部メモリより上記downloadTicket、受信者の受信者識別子、受信者の公開鍵を取得し、さらに転送サーバの秘密鍵を例えば外部記憶装置より取りだし、つづいて上記downloadTicketを暗号化するためのDEKをDEK生成処理部667に依頼し、例えば乱数にて生成し、Recipient-IDに受信者の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により受信者の公開鍵と転送サーバの秘密鍵で共有鍵を生成し、上記共有鍵で上記downloadTicketを暗号するためのDEKを暗号処理部に依頼し暗号化したものを設定し、上記downloadTicketを暗号処理部に依頼し、上記DEKで上記downloadTicketを秘密鍵暗号方式例えばFealにて暗号化し、downloadTicketをMOSSフォーマット化し、内部メモリに格納する。
【０１３１】次にステップ409では、転送サーバではトランザクション制御部が、レスポンス組立処理部655に依頼し、受信したinfo要求(開始)要求メッセージに対応するinfo要求(終了)レスポンスメッセージを、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめlist要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリに記録されたMOSSフォーマット化されたdownloadTicketを設定し、list要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信し、次に受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、info要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりMOSSフォーマット化されたdownloadTicketを取得し、内部メモリに格納し、トランザクション制御部に通知する。
【０１３２】次にステップ410では、受信クライアントではトランザクション制街部619が、上記記録した制御ファイルの送信者の受信者識別子が設定されている第一番目のRecipient-IDより、上記送信者の受信者識別子を取得し内部メモリに記憶し、公開鍵取得処理部615に依頼し、上記内部メモリに記憶された送信者の受信者識別子、例えば外部記憶装置620に記録されている受信者自身の受信者識別子、及び転送サーバの受信者識別子をキーにCAサーバに公開鍵の取得の要求メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【０１３３】次にステップ411では、受信クライアントではトランザクション制御部619が、上記内部メモリに記憶しMOSSフォーマット化したdownloadTicketより、受信者の受信者識別子でRecipient-IDを検索し、続くkey-infoより暗号化されたDEKを取り出し、内部メモリより転送サーバの公開鍵を取得し、例えば外部記憶装置より受信者の秘密鍵を取得し、復号処理部615に依頼し、共有鍵交換方式例えばDiffie Hellman方式により転送サーバの公開鍵と受信者の秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化された上記DEKを復号化し、上記DEKを用いてdownloadTicketを復号化し、内部メモリに記録する。このときdownloadTicketの文脈をチェックし、downloadTicketのフォーマットとして解読不能の場合、不正なdownloadTicketの受信と判断し、エラー処理に入る。
【０１３４】次にステップ412では、受信クライアントでは、トランザクション制御部において、内部メモリより上記downloadTicket、及び受信者、転送サーバの公開鍵を取り出し、さらに転送サーバの受信者識別子、受信者の受信者識別子、及び受信者の秘密鍵を例えば外部記憶装置より取りだし、つづいて上記downloadTicket、受信者の受信者識別子を暗号化するためのDEKをDEK生成処理部に依頼し、上記DEKをDEK生成処理部に依頼し例えば乱数にて生成し、第一番目のRecipient-IDに受信者の受信者識別子を、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により上記受信者の公開鍵と上記受信者の秘密鍵で生成した共有鍵で上記downloadTicket、受信者の受信者識別子を暗号するためのDEKを暗号化したものを設定し、第二番目のRecipient-IDに転送サーバの受信者識別子を、続くkey-infoに共有鍵交換方式例えばDiffie Hellman方式により上記転送サーバの公開鍵と上記受信者の秘密鍵で生成した共有鍵で上記downloadTicket、受信者の受信者識別子を暗号するためのDEKを暗号化したものを設定し、上記downloadTicket、受信者の受信者識別子を暗号処理部に依頼し、上記DEKで上記downloadTicket、受信者の受信者識別子を秘密鍵暗号方式例えばFealにて暗号化し、downloadTicket、受信者の受信者識別子をMOSSフォーマット化し、内部メモリまたは外部記憶装置に記憶する。
【０１３５】次にステップ413では、受信クライアントではトランザクション制御部619が、リクエスト組立処理部607に依頼し、電子ファイルの受信クライアントへのダウンロードを要求するメッセージ(例えばdownload依頼要求(開始）要求メッセージと呼ぶ)を要求メッセージとして、図2に示したHTTPに準拠した要求メッセージのフォーマットの実現例に従い、あらかじめdownload依頼要求(開始）要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として上記内部メモリまたは外部記憶装置に記憶したMOSSフォーマット化されたdownloadTicket、受信者の受信者識別子、及び上記MOSSフォーマット化された制御ファイルを設定し、download依頼要求(開始)要求メッセージを生成し、生成した上記要求メッセージを送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、転送サーバでは送られてきた要求メッセージを受信処理部653が受信し、リクエスト解析処理部654に渡し、上記リクエスト解析処理部では、要求メッセージのrequest commandの値から、download依頼要求(開始)要求メッセージであることを識別しトランザクション制御部664に通知し、データ文フィールドより上記MOSSフォーマット化されたdownloadTicket、受信者の受信者識別子及び上記MOSSフォーマット化された制御ファイルを取得し、MOSSフォーマット化されたdownloadTicket、受信者の受信者識別子の第一番目のRecipient-IDより受信者の受信者識別子を取得し内部メモリに格納し、上記MOSSフォーマット化された制御ファイルの第一番目のRecipient-IDより送信者の受信者識別子を取得し内部メモリに格納し、上記取得したMOSSフォーマット化されたdownloadTicket、受信者の受信者識別子、及びMOSSフォーマット化された制御ファイルを内部メモリまたは外部記憶装置に記憶する。
【０１３６】次にステップ414では、転送サーバではトランザクション制御部が公開鍵取得部に依頼し、内部メモリに記憶されている受信者の受信者識別子、送信者の受信者識別子、例えば外部記憶装置に記憶されている転送サーバ自身の受信者識別子をキーにCAサーバに公開鍵の取得メッセージを送信し、レスポンスとして対応する公開鍵を取得し、内部メモリに受信者識別子と関連づけて記憶する。
【０１３７】次にステップ415では、転送サーバではトランザクション制御部が、制御ファイル解析処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶された制御ファイルより、転送サーバの受信者識別子でRecipient-IDを検索し、続くkey-infoより暗号化された制御ファイル0の暗号化に利用したDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部659に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて上記暗号化された制御ファイル0の暗号化に利用したDEKを復号化し、上記復号化したDEKを用いて制御ファイル0を復号化し、内部メモリまたは外部記憶装置に記録する。このとき制御ファイル0の文脈をチェックし、制御ファイル0のフォーマットとして解読不能の場合、不正な制御ファイルの受信と判断しエラー処理に入り、フォーマットに問題がない場合、さらに上記受信した要求メッセージのMOSSフォーマット化されたdownloadTicket、受信者の受信者識別子より、転送サーバの受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化されたdownloadTicket、受信者の受信者識別子の暗号化に利用したDEKを取り出し、内部メモリより受信者の公開鍵を取得し、例えば外部記憶装置より転送サーバの秘密鍵を取得し、復号処理部に依頼し、共有鍵交換方式例えばDiffie Hellman方式により受信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化されたdownloadTicket、受信者の受信者識別子の暗号化に利用したDEKを復号化し、上記DEKを用いてdownloadTicket、受信者の受信者識別子を復号化し、復号化した受信者識別子と内部メモリに記憶されている受信者識別子を比較し、上記比較結果が一致しない場合、不正なdownloadTicket、受信者の受信者識別子の受信と判断しエラー処理に入り、一致した場合、上記downloadTicketを内部メモリに記憶する。
【０１３８】次にステップ416では、転送サーバではトランザクション制御部が、データベース管理部に依頼し、上記内部メモリに格納されたdownloadTicketをキーとして、ダウンロードトランザクションを管理しているテーブルを検索し、マッチするレコードより、トランザクション識別子を取得し、内部メモリに格納する。
【０１３９】次にステップ417では、転送サーバでは、上記トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したdownload依頼要求（開始)を要求メッセージに対応するレスポンスメッセージ(例えばdownload依頼要求（終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめdownload依頼要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリから取得した上記トランザクション識別子を設定し、download依頼要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信し、受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、download依頼要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子を取り出し、内部メモリに格納し、トランザクション制御部に通知する。
【０１４０】次にステップ418では、受信クライアントではトランザクション制御部において、制御ファイル解析処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶されたMOSSフォーマット化された制御ファイルより、受信者の受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化された制御ファイル0を暗号化するのに利用したDEKを取り出し、内部メモリより送信者の公開鍵を取得し、例えば外部記憶装置より受信者の秘密鍵を取得し、復号処理部613に依頼し、共有鍵交換方式例えばDiffie Hellman方式により送信者の公開鍵と受信者の秘密鍵より共有鍵を生成し、上記共有鍵を用いて暗号化された上記制御ファイル0を暗号化するのに利用したDEKを復号化し、上記DEKを用いて制御ファイル0を復号化し、上記復号化した制御ファイル0の文脈をチェックし、規定された制御ファイル0のフォーマットとして解読不能の場合は、不正な制御ファイルの受信と判断しエラー処理に入り、フォーマットに問題がない場合、上記制御ファイル0を内部メモリまたは外部記憶装置に記録し、さらに上記復号化された制御ファイル0に含まれるMOSSフォーマット化された制御ファイル1より、受信者の受信者識別子でRecipient-IDを検索し、対応するkey-infoより暗号化された制御ファイル1を暗号化するのに利用したDEKを取り出し、上記共有鍵を用いて復号処理部に依頼し暗号化されたDEKを復号化し、上記DEKを用いて制御ファイル1を復号化し、内部メモリまたは外部記憶装置に記録し、上記制御ファイル0よりダウンロードする全ブロックファイル名を取得し内部メモリに記憶する。
【０１４１】次にステップ419では、受信クライアントでは、トランザクション制御部において、内部メモリに記憶されたダウンロードするブロックファイル名、及び受信ログより未ダウンロードのブロックファイルを取得し、リクエスト組立処理部に依頼し、上記取得されたブロックファイル名に対応するブロックファイルの1つを転送サーバからダウンロードすることを要求するための要求メッセージ(例えばdownload upfile.i.j要求(開始）要求メッセージと呼ぶ)として、図2に示したHTTPに準拠した要求フォーマットにのっとり、あらかじめdownload upfile.i.j要求(開始)要求メッセージとして、クライアント、転送サーバで決められたcontent-type、及びrequest commandを設定し、データ文として、第一に上記内部メモリに格納されたトランザクション識別子、第二に受信するブロックファイルのブロックファイル名、を設定し、download upfile.i.j要求(開始）要求メッセージを生成し、送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信した要求メッセージに対するレスポンスメッセージの受信待ち状態に入り、次に転送サーバでは送られてきた要求メッセージを受信処理部653で受信し、リクエスト解析処理部654に渡す。リクエスト解析処理部では、要求メッセージのrequest commandフィールドの値から、download upfile.i.j要求(開始）要求メッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名を取得し内部メモリに記憶する。
【０１４２】次にステップ420では、転送サーバではトランザクション制御部が、データベース制御処理部661に依頼し、上記取得したトランザクション識別子をキーとしてデータベースに記録されたファイルのダウンロードトランザクションを管理しているテーブルを検索し、マッチするレコードより制御ファイル識別子を取得し、さらに上記制御ファイル識別子、及び受信したブロックファイル名をキーとして、ブロックファイルを管理しているテーブルを検索し、マッチするレコードのブロックファイルの保存先を取得し、取得した保存先より暗号化されたブロックファイル(upfile.i.j)を取得し、内部メモリまたは外部記憶装置に記憶する。
【０１４３】次にステップ421では、転送サーバではトランザクション制御部が、レスポンス組立処理部に依頼し、受信したdownload upfile.i.j要求(開始)要求メッセージに対応するレスポンスメッセージ(例えばdownload upfile.i.j(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめdownload upfile.i.j(終了)をレスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリに格納されたトランザクション識別子、ブロックファイル名、及び内部メモリまたは外部記憶装置に記憶され暗号化されたブロックファイル(upfile.i.j)を設定し、download upfile.i.j要求(終了)レスポンスメッセージを生成し、送信処理部に渡し、受信クライアントにネットワークを介して送信する。次に受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponsecommandフィールドの値から、download upfile.i.j(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子、ブロックファイル名を取得し内部メモリに格納し、さらにデータ文より暗号化されたブロックファイル(upfile.i.j）を取得し、外部記憶装置に上記ブロックファイル名と関連づけて記憶し、上記トランザクション識別子、上記ブロックファイル名を、内部メモリまたは外部記憶装置に受信ログとして記録する。
【０１４４】次にステップ422では、受信クライアントでは、トランザクション制御部が上記受信ログの記録、及び上記内部メモリに格納された受信するブロックファイル名をチェックし、未受信のブロックファイルがあるか調べる。未受信のブロックファイルが存在する場合、ステップ419に戻る。
【０１４５】次にステップ423では、受信クライアントでは、トランザクション制御部が上記内部メモリ若しくは外部記憶装置に保存している制御ファイル1よりMasterDEKを取得し、内部メモリに格納する。
【０１４６】次にステップ424では、受信クライアントでは、トランザクション制御部が、上記内部メモリ若しくは外部記憶装置に保存している制御ファイル0より、上記受信した外部記憶装置に記録されている全ての暗号化されたブロックファイル(upfile.i.j)に対応する全ての隠蔽されたDEK.iを、復号処理部に渡し、内部メモリに記憶されているMasterDEKにて復号化し、全てのブロックファイルを暗号化するのに利用したDEK.iを取得し、内部メモリにまたは外部記憶装置に記録する。
【０１４７】次にステップ425では、受信クライアントでは、トランザクション制御部が、上記受信した外部記憶装置に記録されている暗号化されたブロックファイル(upfile.i.j)の保存先と、上記内部メモリに格納されているDEK.iを復号処理部に渡し、上記暗号化されたブロックファイル(upfile.i.j)を復号化し、外部記憶装置に上記ブロックファイルのファイル名と関連づけて保存し、対応する暗号化されたブロックファイルを外部記憶装置より消去する。
【０１４８】次にステップ426では、受信クライアントでは、トランザクション制御部が、ハッシュ処理部に依頼し、上記復号化した全てのブロックファイル(upfile.i.j)のハッシュ値を送信クライアントと同一の方式、例えばSHA-1により算出し、上記内部メモリ若しくは外部記憶装置に記憶されている制御ファイル0より、上記ブロックファイル(upfile.i.j)に対応するOrgMD.i.jと比較する。ハッシュ値が同値でないブロックファイルが存在する場合、エラー処理に入る。
【０１４９】次にステップ427では、受信クライアントでは、トランザクション制御部が、ブロック処理部に依頼し、上記内部メモリまたは外部記憶装置に記憶されている制御ファイル0に記述された電子ファイル(upfile.i)毎のブロックファイル名(upfile.i.j)の記述順序に従い、上記受信した外部記憶装置に記憶されている全ブロックファイルを上記電子ファイル毎に結合し、上記電子ファイルを復元し、上記復元した電子ファイルに、上記制御ファイル0に記述された上記電子ファイルのファイル名(相対パス名)を付与し、あらかじめ受信した電子ファイルの保存先としてきめられた外部記憶装置のディレクトリに、上記復元した電子ファイルを保存する。
【０１５０】次にステップ428では、受信クライアントでは、トランザクション制御部が、例えば外部記憶装置より受信者の受信者識別子を取得し、上記内部メモリに格納されているトランザクション識別子、downloadTicket、及び上記ダウンロードが終了した電子ファイルのファイル名(upfile.i）を記述したCompleteTicketを生成し、内部メモリより受信者、及び転送サーバの公開鍵を取り出し、さらに受信者の受信者識別子と秘密鍵、及び転送サーバの受信者識別子を例えば外部記憶装置より取りだし、つづいてDEK生成処理部に依頼し、上記CompleteTicketを暗号化するためのDEKを例えば乱数を用いて生成し、Recipient-IDに受信者の受信者識別子を第一番目に、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により受信者の公開鍵と受信者の秘密鍵より暗号処理部に依頼し共有鍵を生成し、上記生成した共有鍵で上記Complete Ticketを暗号するためのDEKを暗号処理部に依頼し暗号化したものを設定し、Recipient-IDに転送サーバの受信者識別子を第二番目に、続くkey-infoに共有鍵交換方式、例えばDiffie Hellman方式により転送サーバの公開鍵と受信者の秘密鍵より暗号処理部に依頼し共有鍵を生成し、上記生成した共有鍵で上記Complete Ticketを暗号するためのDEKを暗号処理部に依頼し暗号化したものを設定し、上記Complete Ticketを暗号処理部に依頼し、上記DEKを秘密鍵暗号方式例えばFealにて暗号化しComplete TicketをMOSSフォーマット化し、内部メモリに格納する。
【０１５１】次にステップ429では、受信クライアントではトランザクション制御部619が、リクエスト組立処理部607に依頼し、電子ファイルの受信クライアントへのダウンロードの終了を通知する要求メッセージ(例えばdownload complete要求(開始）要求メッセージと呼ぶ)を要求メッセージとして、図2に示したHTTPに準拠した要求メッセージのフォーマットの実現例に従い、あらかじめdownload complete要求(開始）要求メッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びrequest commandを設定し、データ文として上記内部メモリまたは外部記憶装置に記憶したMOSSフォーマット化されたCompleteTicketを設定し、download complete要求(開始）要求メッセージを生成し、生成した上記要求メッセージを送信処理部605に渡し、転送サーバにネットワークを介して送信し、受信処理部606は送信したメッセージに対するレスポンスメッセージの受信待ち状態に入り、転送サーバでは送られてきた要求メッセージを受信処理部653が受信し、リクエスト解析処理部654に渡し、上記リクエスト解析処理部では、要求メッセージのrequest commandの値から、download complete要求(開始)要求メッセージであることを識別しトランザクション制御部664に通知し、データ文フィールドより上記MOSSフォーマット化されたCompleteTicketを取得し、上記MOSSフォーマット化されたCompleteTicketを内部メモリまたは外部記憶装置に記憶する。
【０１５２】次にステップ430では、転送サーバではトランザクション制御部が、上記内部メモリより上記MOSSフォーマット化されたCompleteTicketを取得し、上記MOSSフォーマット化されたCompleteTicketの第一番目のRecipient-IDよりMOSSフォーマット化されたCompleteTicketの送信者(電子ファイルの受信者)の受信者識別子を取得し、内部メモリより上記受信者識別子に対応する受信者の公開鍵、及び転送サーバの公開鍵を取得し、続いて上記MOSSフォーマット化されたCompleteTicketの第二番目のRecipient-IDに例えば外部記憶装置に記録された転送サーバの受信者識別子が含まれることを確認し、続くkey-infoより暗号化されたDEKを取り出し、復号処理部559に依頼し、共有鍵交換方式例えばDiffie Hellman方式によりMOSSフォーマット化されたCompleteTicketの送信者(電子ファイルの受信者)の公開鍵と、転送サーバの例えば外部記憶装置に記録された秘密鍵より共有鍵を生成し、上記共有鍵を用いて上記暗号化されたDEKを復号化し、上記DEKを用いて上記MOSSフォーマット化されたCompleteTicketを復号化し、復号化した上記CompleteTicketより、MOSSフォーマット化されたCompleteTicketの送信者(電子ファイルの受信者)の受信者識別子、トランザクション識別子、downloadTicket、受信ファイル名(upfile.i)を取りだし内部メモリに記憶する。このとき取り出した受信者の受信者識別子と内部メモリに記憶されていた受信者識別子を比較し、同値でない場合、不正なCompleteTicketの受信と判断しエラー処理に入る。
【０１５３】次にステップ431では、転送サーバではトランザクション制御部が、データベース管理部に依頼し、ダウンロードトランザクションを管理しているテーブルを、上記内部メモリ記憶されているトランザクション識別子、及びdownloadTicketをキーに検索し、マッチしたレコードのステータスフィールドの値を完了にする。
【０１５４】次にステップ432では、転送サーバでは、上記トランザクション制御部が、レスポンス組立処理部655に依頼し、受信したdownload complete依頼要求(開始)を要求メッセージに対応するレスポンスメッセージ(例えばdownload complete要求(終了)レスポンスメッセージと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメッセージのフォーマットの実現例にのっとり、あらかじめdownload complete要求(終了)レスポンスメッセージとして、クライアント、転送サーバで取り決められたcontent-type、及びresponse commandを設定し、データ文として、上記内部メモリに格納されている受信クライアントから受信したdownloadTicket、及び上記内部メモリに格納されている受信クライアントから受信したトランザクション識別子を設定し、download complete要求(終了)レスポンスメッセージを生成し、送信処理部652に渡し、受信クライアントにネットワークを介して送信し、転送サーバは上記トランザクション識別子に対応するダウンロード処理を終了し、受信クライアントでは送られてきたレスポンスメッセージを受信処理部606で受信し、レスポンス解析処理部608に渡す。レスポンス解析処理部では、要求メッセージのresponse commandフィールドの値から、download complete要求(終了)レスポンスメッセージであることを識別し、データ文フィールドよりトランザクション識別子を取り出し、トランザクション制御部に通知し、トランザクション制御部は、上記トランザクション識別子に対応するダウンロード再受信処理を終了する。
【０１５５】
【発明の効果】以上説明したように本発明によれば、ファイヤーウォールで一般的に利用可能になっているHTTPを利用した安全で且つファイルサイズによらないファイル転送システムを容易に構築することが可能となる。
【０１５６】また、請求項２記載の発明によれば、制御ファイルにファイルの転送先が少なくても１つ以上記載されているので、１対複数の転送が可能となる。
【０１５７】また、請求項３記載の発明によれば、転送サーバ上にある制御ファイルの転送先を送信クライアントによって変更可能とする手段を有するので、１度サーバーに転送しておけば制御ファイルの転送先を変更することで、他のクライアントに転送可能となる。
【０１５８】また、請求項４記載の発明によれば、送信クライアントが、送信するファイルをブロック化する手段と、暗号化する手段と、ブロック化した情報を制御ファイルに書きこむ手段を有し、受信クライアントが、暗号化されたブロックを復号化する手段と、復号化したブロックを制御ファイルに書きこまれているブロック化した情報をもとにファイルを組み立てる手段を有するので、例えば、マルチスレッドによるファイルブロックの転送が可能となり高速なファイル転送が実現できる。
【０１５９】また、請求項５記載の発明によれば、送信クライアントから転送サーバにファイルを転送する際に異常があった場合に送信クライアントが未送信のブロック化したファイルのみを送信する手段を有するので、送信時に転送を失敗しても、ブロック単位で再送が可能となる。
【０１６０】また、請求項６記載の発明によれば、転送サーバから受信クライアントにファイルを転送する際に異常があった場合に受信クライアントが未受信のブロック化したファイルのみを受信する手段を有するので、受信時に転送を失敗しても、ブロック単位で再受信が可能となる。
【０１６１】また、請求項７記載の発明によれば、制御ファイルが送信クライアントから受信クライアントのみで情報交換を行う部分と、送信クライアントから受信クライアント間、送信クライアントから転送サーバ間、転送サーバから受信クライアント間で情報交換を行う部分との、２階層で構成されているので、制御ファイルの管理が容易であり、また、請求項８記載の発明によれば、制御ファイルの送信クライアントから受信クライアントのみで情報交換を行う部分が受信クライアントのみで復号化できる暗号で記載されているので、ファイル転送経路にある転送サーバなとでサーバ管理者を含めた第三者に内容を知られる危険性がない。
【出願人】 【識別番号】３９９０４０４０５
【氏名又は名称】東日本電信電話株式会社
【識別番号】３９９０４１１５８
【氏名又は名称】西日本電信電話株式会社
【識別番号】３９９０３５７６６
【氏名又は名称】エヌ・ティ・ティ・コミュニケーションズ株式会社
【出願日】 平成１１年６月１８日（１９９９．６．１８）
【代理人】
【公開番号】 特開２００１−５７４６（Ｐ２００１−５７４６Ａ）
【公開日】 平成１３年１月１２日（２００１．１．１２）
【出願番号】 特願平１１−１７３３９４