JP2001005746A - ファイル転送システム - Google Patents

Abstract

(57)【要約】 【課題】インターネットなどのIPネットワーク上におい
て電子的なファイルを、ネットワークで送受信している
間に、ファイルの盗聴、改竄や送受信者への成りすまし
に対して安全であり、且つファイヤーウォールを通過さ
せるために汎用性の高いHTTPを利用することにより、利
用者の利便性を確保し、且つ大容量のファイルの転送を
行うためのバッチ処理的な利用を可能とする。 【解決手段】ネットワーク002において、転送サーバ001
を介し、送信クライアント003から受信クライアント004
へ電子ファイル006を転送するファイル転送システムで
あって、転送される電子ファイル006に関する情報を記
述した制御ファイルを用いて、クライアント間で転送す
る。この制御ファイルには、ファイルの転送先の情報を
１または複数記述するとともに、転送サーバとの間のフ
アイルの転送手順や、セキュリティ制御に関する情報を
記述する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ通信
分野における、電子的なファイルの転送技術に関するも
のであり、特にインターネット、エキストラネット、及
びイントラネットに代表されるIP（Internet Protoco
l）ネットワークにおいて上記電子的なファイルを安全
且つ簡単に送受信するためのファイル転送システムに関
する。

【０００２】

【従来の技術】インターネットやイントラネットに代表
される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サーバ0
20のレスポンス[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 Mark
up 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-mai
l等で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へのF
ORMタグによるファイルの送信指示の送信[033]、WWWサ
ーバ038からWWWブラウザ（送信）037へのレスポンス[03
4]という通信のやりとりが行われる。また、受信側のWW
Wブラウザ（受信）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（Re
quest for Comments）2068)に従う。これにより、ファ
イヤーウォールで守られたネットワーク内から、HTTPの
ポートが空けてあれば、HTTP PROXY(代理)サーバを利用
した環境で本発明の利用が可能となる。図2にクライア
ントから転送サーバへのHTTPの規定に準拠した要求メッ
セージの実現例を示す。request commandには要求メッ
セージの種別、application/X-contentTypeNameには要
求メッセージに対応したMIMEタイプにあらかじめ上記ク
ライアント〜転送サーバ間で規定した値を記述する。転
送サーバはこのrequest command若しくはapplication/X
-contentTypeNameの値を確認することによりクライアン
トからの要求メッセージを識別する。データ文はメッセ
ージに付属するパラメータ若しくは、送受信の対象とな
る電子ファイルのデータが記述され、クライアントから
転送サーバに引き渡される。

【００２３】図3に転送サーバからクライアントへのHTT
Pの規定に準拠したレスポンスメッセージの実現例を示
す。response commandにはレスポンスメッセージの種
別、application/X-contentTypeNameにはレスポンスメ
ッセージに対応したMIMEタイプにあらかじめ上記クライ
アント〜転送サーバ間で規定した値を記述する。クライ
アントはこのresponse command若しくはapplication/X-
contentTypeNameを判読することにより転送サーバから
のレスポンスメッセージを識別する。データ文はメッセ
ージに付属するパラメータ若しくは、送受信の対象とな
る電子ファイルのデータが記述され転送サーバからクラ
イアントへ引き渡される。

【００２４】本発明では上記送信クライアント〜上記受
信クライアント間で送受信する電子ファイルに関する情
報をファイルに記述し(このファイルを制御ファイルと
呼ぶ)、上記制御ファイルを上記送信クライアント〜上
記転送サーバ、上記転送サーバ〜受信クライアント間で
送受信することにより、送受信する電子ファイルに関す
る情報の交換を行う。

【００２５】上記制御ファイルは送信クライアント〜受
信クライアント間のみで情報交換を行うための部分、及
び送信クライアント〜受信クライアント間、送信クライ
アント〜転送サーバ間、転送サーバ〜受信クライアント
間で情報交換を行うための部分により構成され、それぞ
れ制御ファイル1、制御ファイル0と呼ぶ。

【００２６】制御ファイル1のフォーマットの実現例を
図4に示す。上記制御ファイル1には制御ファイル毎にユ
ニークな制御ファイル識別子、及びMasterDEK(Master D
ataEncryption Key)が記述される。MasterDEKは、送受
信する電子ファイル(upfile.i:i=1,2,...,n)を暗号化す
るDEK.i(i=1,2,...,n)を暗号化(隠蔽されたDEK.i)す
る、若しくは隠蔽された(暗号化）されたDEK.iを復号化
しDEK.iを取り出す為に利用される(電子ファイルupfil
e.iはDEK.iで暗号化される)。

【００２７】制御ファイル1の記述例を図5に示す。

【００２８】上記制御ファイル1は、送信者から転送サ
ーバ、受信者、及び上記送信者自身に対して相互認証可
能なE-mail暗号規格、例えばMOSS（Mime Object Securi
ty Service）(RFC1848)により、フォーマットを変換(暗
号化を含む)される。フォーマット変換された制御ファ
イル1の実現例を図6に示す。

【００２９】実現例におけるRecipient-ID)には上記電
子ファイルの送信者、及び上記電子ファイルの受信者の
受信者識別子を、ctrlfile 1 boundary内にDEK(Data En
cryption Key)を用いて秘密鍵暗号方式、例えばFealに
て暗号化された制御ファイル1が記述される。

【００３０】Recipient-IDに続くKey-infoは対をなし、
上記Key-infoには上記制御ファイル1を暗号化したDEK
を、鍵交換方式例えばDiffie&Hellmanの方式(後述）に
より求めた本制御ファイル1の送信者と、続くRecipient
-IDに含まれた受信者識別子を持つ受信者との共有鍵で
暗号化した値が含まれる。

【００３１】本記述例では、受信者の識別子としてE-ma
ilアドレスのフォーマットを利用し、送信者自身、send
er@winca、及び受信者としてreceiver0@winca、receive
r1@wincaに対し制御ファイル1の解読を認めている。注
意すべき点は転送サーバのRecipient-IDとKey-infoが無
いことである。この事実はこの制御ファイル1の内容を
転送サーバ自身は解読できない、すなわち上記MasterDE
Kを取り出せないことを意味する。転送サーバは上記Mas
terDEKを取り出せないことから、上記送受信する電子フ
ァイル（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）、送信されるファイル
を例えばあらかじめ指定されたサイズに分割した各ブロ
ック(これをブロックファイルと呼ぶ)のファイル名(upf
ile.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を全てのブロックファ
イル毎、全ての送信ファイル毎に記述し、最後に上記MO
SSフォーマット化された制御ファイル1を記述する。

【００３６】上記電子ファイルの分割は、上記電子ファ
イルのアップロード、またはダウンロード時になんらか
の障害がおきファイルの送受信が中断された場合に、再
度上記電子ファイルを頭から送受信するのではなく、送
受信できなかったブロックファイルから再度電子ファイ
ルのアップロード(これをアップロード再送信処理と呼
ぶ)、またはダウンロード(これをダウンロード再受信処
理と呼ぶ)を行うために実施するものであり、送受信す
るファイルのサイズが比較的小さい場合、必ずしも実施
する必要はない。

【００３７】上記制御ファイル0の記述例を図9及び図10
に示す。なお、図9と図10は、２図でで１つのファイル
を示している。

【００３８】本記述例では送信ファイルupfolder\jpeg\
logo.jpgを、logo.jpg.1、logo.jpg.2、…、logo.jpg.n
のブロックファイルに分割し、ファイルupfolder\w3\in
dex.htmを、index.htm.1、index.htm.2、...、index.ht
m.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は、制御ファイルの送
信者、受信者、転送サーバ毎に鍵交換方式例えば上記Di
ffie Hellman方式により生成した共有鍵により秘密暗号
方式例えばFealにより暗号化され、送信者、受信者、転
送サーバの受信者識別子を含むRecipient-IDに続く、Ke
y-infoに設定される。

【００４５】以上により、制御ファイル0の送受信者は
送受信が論理的に成功すれば相互に認証が可能となる。

【００４６】本発明の装置構成の実現例を図12に示す。
またアップロード処理におけるフロチャートの実現例を
図13、図14、及び図15に示す。なお、図13、図14、及び
図15は、一連の処理の流れを示すフロチャートを分割し
て示したものであって、各図の接続点は、同一の符号を
円で囲った結合子（例えば図13の結合子C01と図14の結
合子C01が接続される。）を用いて示している（以降の
フロチャートでも同様）。

【００４７】なお、図12において、送信または受信側の
クライアント601は、ファイル選択処理部603、受信者選
択処理部604、送信処理部605、受信処理部606、リクエ
スト組立処理部607、レスポンス解析処理部608、制御フ
ァイル生成処理部609、制御ファイル解析処理部610、DE
K生成処理部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を生成し内
部メモリに格納する。さらに送信する電子ファイル(upf
ile.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を生成し、電子ファイル(upfi
le.i)と関連づけて内部メモリに保存する。

【００５７】次にステップ108では、送信クライアント
ではトランザクション制御部619が制御ファイル生成処
理部609に依頼し、ユニークな制御ファイル識別子を、
例えば乱数などの方法で生成し内部メモリに記憶し、内
部メモリよりMasterDEKを取りだし、上記制御ファイル
識別子とともに制御ファイル1を生成し、さらに内部メ
モリより、送信者自身の公開鍵、受信者全員の受信者識
別子と公開鍵を取り出し、送信者の受信者識別子と秘密
鍵を外部記憶装置より取り出し、つづいて制御ファイル
1を暗号化するためのDEKを例えば乱数にてDEK生成部に
依頼し生成し、第一番目のRecipient-IDに送信者自身の
受信者識別子を、続くKey-infoに共有鍵交換方式、例え
ばDiffie Hellman方式により送信者自身の公開鍵と秘密
鍵より生成した共有鍵で制御ファイル1を暗号化するた
めのDEKを暗号化したものを設定し、二番目以降のRecip
ient-IDに受信者の受信者識別子を、続くkey-infoに共
有鍵交換方式、例えばDiffie Hellman方式により上記受
信者の公開鍵と送信者の秘密鍵より生成した共有鍵で制
御ファイル1を暗号化するためのDEKを暗号化したものを
設定し、上記生成した制御ファイル1と上記生成したDEK
を暗号処理部に依頼し、秘密暗号化方式例えばFealで暗
号し、上記制御ファイル1をMOSSフォーマットに変換し
外部記憶装置に保存する。

【００５８】次にステップ109では、送信クライアント
ではトランザクション制御部619が制御ファイル生成処
理部609に依頼し、内部メモリより上記生成した制御フ
ァイル識別子を取得し、さらに内部メモリより、上記MO
SSフォーマット化した制御ファイル1、送信する電子フ
ァイルのパス、送信する電子ファイルのブロックファイ
ル名、各ブロックファイルに対応するOrgMD.i.j、EncMD
i.j、隠蔽されたDEK.iを読み出し、上記制御ファイル識
別子とともに制御ファイル0を生成し、さらに内部メモ
リより、送信者自身の公開鍵、転送サーバの公開鍵、及
び受信者全員の受信者識別子と公開鍵を取り出し、送信
者の受信者識別子と秘密鍵、及び転送サーバの受信者識
別子を外部記憶装置より取り出し、つづいて制御ファイ
ル0を暗号化するためのDEKをDEK生成部に依頼し例えば
乱数にて生成し、第一番目のRecipient-IDに送信者自身
の受信者識別子を、続くkey-infoに共有鍵交換方式、例
えばDiffie Hellman方式により送信者自身の公開鍵と秘
密鍵より生成した共有鍵で制御ファイル0を暗号化する
ためのDEKを暗号化したものを設定し、二番目以降のRec
ipient-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 comm
andを設定し、データ文として上記制御ファイルを設定
し、upload依頼要求(開始）要求メッセージを生成し、
生成した上記要求メッセージを送信処理部605に渡し、
転送サーバにネットワークを介して送信し、受信処理部
606は送信したメッセージに対するレスポンスメッセー
ジの受信待ち状態に入り、転送サーバでは送られてきた
要求メッセージを受信処理部653が受信し、リクエスト
解析処理部654に渡し、上記リクエスト解析処理部で
は、要求メッセージのrequest commandの値から、uploa
d依頼要求(開始)要求メッセージであることを識別しト
ランザクション制御部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より送信される全てのブロックファイル(up
file.i.j)に対して上記制御ファイル識別子、ブロック
ファイル名(upfile.i.j)、Enc.i.j、及び隠蔽されたDE
K.iを取りだし、データベースのブロックファイルを管
理しているテーブル（図29)に、全ての送信されるブロ
ックファイル(upfile.i.j)に対して上記取得した制御フ
ァイル識別子、ブロックファイル名(upfile.i.j)、Enc.
i.jをフィールド値とするレコードを追加する。

【００６４】次にステップ115では、転送サーバでは、
上記トランザクション制御部がレスポンス組立処理部65
5に依頼し、受信したupload依頼要求(開始)要求メッセ
ージに対応するレスポンスメッセージ(例えばupload依
頼要求(終了)レスポンスメッセージと呼ぶ)を、図3に示
したHTTPに準拠したレスポンスメッセージのフォーマッ
トの実現例にのっとり、あらかじめupload依頼要求(終
了)レスポンスメッセージとして、クライアント、転送
サーバで取り決められたcontent-type、及びresponse c
ommandを設定し、データ文として、上記生成したトラン
ザクション識別子を設定し、upload依頼要求(終了)レス
ポンスメッセージを生成し、送信処理部652に渡し、送
信クライアントにネットワークを介して送信し、送信ク
ライアントでは送られてきたレスポンスメッセージを受
信処理部606で受信し、レスポンス解析処理部608に渡
す。レスポンス解析処理部では、要求メッセージのresp
onsecommandフィールドの値から、upload依頼要求(終
了)レスポンスメッセージであることを識別し、データ
文フィールドよりトランザクション識別子を取り出し、
内部メモリに格納し、トランザクション制御部に通知す
る。

【００６５】次にステップ116では、送信クライアント
では、トランザクション制御部において、リクエスト組
立処理部に依頼し、上記内部メモリまたは外部記憶装置
に記憶された送信するファイルブロック名、及び送信ロ
グより、未アップロードの暗号化されたファイルブロッ
ク名を取得し、上記ブロックファイル名に対応する暗号
化されたブロックファイルの1つを転送サーバにアップ
ロードすることを要求するための要求メッセージ(例え
ばupload upfile.i.j依頼要求(開始)要求メッセージと
呼ぶ)として、図2に示したHTTPに準拠した要求フォーマ
ットにのっとり、あらかじめupload upfile.i.j依頼要
求(開始)を要求メッセージとして、クライアント、転送
サーバで決められたcontent-type、及びrequest comman
dを設定し、データ文として、第一に上記トランザクシ
ョン識別子、第二に送信する暗号化されたブロックファ
イルのブロックファイル名、及び第三に外部記憶装置に
保存された上記暗号化されたブロックファイル(upfile.
i.j)を設定し、upload upfile.i.j依頼要求(開始）要求
メッセージを生成し、送信処理部605に渡し、転送サー
バにネットワークを介して送信し、受信処理部606は送
信した要求メッセージに対するレスポンスメッセージの
受信待ち状態に入り、次に転送サーバでは送られてきた
要求メッセージを受信処理部653で受信し、リクエスト
解析処理部654に渡す。リクエスト解析処理部では、要
求メッセージのrequest commandフィールドの値から、u
pload upfile.i.j依頼要求(開始)要求メッセージである
ことを識別し、データ文フィールドよりトランザクショ
ン識別子、ブロックファイル名、及び暗号化されたブロ
ックファイル(upfile.i.j)を取得し、トランザクション
制御部に通知し、データベース制御処理部661に依頼
し、上記取得したトランザクション識別子をキーとして
データベースに記録された電子ファイルのアップロード
トランザクションを管理しているテーブルを検索し、マ
ッチする制御ファイル識別子を取得し、さらに上記制御
ファイル識別子、及び受信したブロックファイル名をキ
ーとして、ブロックファイルを管理しているテーブルを
検索し、マッチするレコードを取得し、受信したブロッ
クファイルをブロック処理部662に依頼し、外部記憶装
置に保存し、上記受信したブロックファイルの保存場所
を、上記マッチしたブロックファイルを管理しているテ
ーブルの上記レコードのブロックファイルの保存先フィ
ールドの値として記録する。

【００６６】次にステップ117では、転送サーバでは、
トランザクション制御部がレスポンス組立処理部625に
依頼し、受信したupload upfile.i.j要求(開始)要求メ
ッセージに対応するupload upfile.i.j(終了)レスポン
スメッセージを、図3に示したHTTPに準拠したレスポン
スメッセージのフォーマットの実現例にのっとり、あら
かじめupload upfile.i.j(終了)レスポンスメッセージ
として、クライアント、転送サーバで取り決められたco
ntent-type、及びresponse commandを設定し、データ文
として、上記upload upfile.i.j要求(開始)要求メッセ
ージより取得したトランザクション識別子、及びブロッ
クファイル名を設定し、upload upfile.i.j要求(終了)
レスポンスメッセージを生成し、送信処理部652に渡
し、送信クライアントにネットワークを介して送信す
る。次に送信クライアントでは送られてきたレスポンス
メッセージを受信処理部606にて受信し、レスポンス解
析処理部608に渡す。レスポンス解析処理部では、要求
メッセージのresponse commandフィールドの値から、up
load 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に依頼し、パラメータで指定した条件を満たす
制御ファイルの取得を要求する要求メッセージ(例えばl
ist要求(開始）要求メッセージと呼ぶ)として、図2に示
したHTTPに準拠した要求フォーマットの実現例にのっと
り、あらかじめlist要求(開始)要求メッセージとして、
クライアント、転送サーバで取り決められたcontent-ty
pe、及びrequest commandを設定し、データ文として、
アップロードが完了していないファイルの情報を含む制
御ファイルを検索することをサーバに指示するパラメー
タ、及び送信者の受信者識別子を例えば外部記憶装置よ
り取得して設定し、list要求(開始)要求メッセージを生
成し、送信処理部605に渡し、転送サーバにネットワー
クを介して送信し、受信処理部606は送信したメッセー
ジに対するレスポンスメッセージの受信待ち状態に入
り、次に転送サーバでは送られてきた要求メッセージを
受信処理部653で受信し、リクエスト解析処理部654に渡
す。リクエスト解析処理部では、要求メッセージのrequ
est commandフィールドの値から、list要求(開始)要求
メッセージであることを識別し、データ文フィールドよ
り送信者の受信者識別子を取得し内部メモリに記憶し、
さらにデータ文フィールドより上記要求メッセージがア
ップロードが完了していないファイルの情報を含む制御
ファイルを検索することを指示していることを認識し、
トランザクション制御部に通知する。

【００７２】次にステップ202では、転送サーバではト
ランザクション制御部が、上記内部メモリより送信者の
受信者識別子を取得し、データベース制御処理部に依頼
し、データベースの制御ファイルを管理しているテーブ
ルを、送信者の受信者識別子をキーに検索し、マッチす
るレコードの制御ファイル識別子を取得し、取得した制
御ファイル識別子をキーに、アップロードトランザクシ
ョンを管理しているテーブルを検索し、ステータスフィ
ールドが完了になっていないものを検索し、上記マッチ
したレコードより制御ファイル識別子をキーに制御ファ
イルを管理しているテーブルを検索し、マッチしたレコ
ードよりMOSSフォーマット化された制御ファイルを取得
し、内部メモリまたは外部記憶装置に記録する。

【００７３】次にステップ203では、転送サーバでは、
トランザクション制御部が、レスポンス組立処理部655
に依頼し、受信したlist要求(開始)要求メッセージに対
応するlist要求(終了)レスポンスメッセージを、図3に
示したHTTPに準拠したレスポンスメッセージのフォーマ
ットの実現例にのっとり、あらかじめlist要求(終了)レ
スポンスメッセージとして、クライアント、転送サーバ
で取り決められたcontent-type、及びresponse command
を設定し、データ文として、上記内部メモリまたは外部
記憶装置に記録したMOSSフォーマット化された制御ファ
イルを設定し、list要求(終了)レスポンスメッセージを
生成し、送信処理部652に渡し、送信クライアントにネ
ットワークを介して送信する。次に送信クライアントで
は送られてきたレスポンスメッセージを受信処理部606
で受信し、レスポンス解析処理部608に渡す。レスポン
ス解析処理部では、要求メッセージのresponse command
フィールドの値から、list要求（終了)レスポンスメッ
セージであることを識別し、データ文フィールドよりMO
SSフォーマット化された制御ファイルを取得し、内部メ
モリまたは外部記憶装置に記録し、トランザクション制
御部に通知する。

【００７４】次にステップ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では、転送サーバではト
ランザクション制御部が、上記内部メモリより制御ファ
イル識別子を取得し、データベース管理部に依頼し、上
記制御ファイル識別子をキーにデータベースのブロック
ファイルを管理しているテーブルを検索し、受信したブ
ロックファイルの保存先が設定されていないレコードを
検索し、マッチするレコードのブロックファイル名(upf
ile.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を検索し、対応するke
y-infoより暗号化されたDEKを取り出し、上記転送サー
バの公開鍵、及び送信者の秘密鍵を復号処理部615に依
頼し、共有鍵交換方式例えばDiffie Hellman方式により
転送サーバの公開鍵と送信者の秘密鍵より共有鍵を生成
し、上記共有鍵を用いて上記暗号化されたDEKを復号化
し、上記DEKを用いて復号化された上記ブロックファイ
ル名(upfile.i.j)を内部メモリまたは外部記憶装置に記
録する。

【００８２】次にステップ212では、送信クライアント
ではトランザクション制御部619が、リクエスト組立処
理部607に依頼し、電子ファイルの転送サーバへのアッ
プロードを要求するメッセージ(例えばupload依頼要求
(開始)要求メッセージと呼ぶ)を要求メッセージとし
て、図2に示したHTTPに準拠した要求メッセージのフォ
ーマットの実現例に従い、あらかじめupload依頼要求
(開始）要求メッセージとして、クライアント、転送サ
ーバで取り決められたcontent-type、及びrequest comm
andを設定し、データ文として上記内部メモリまたは外
部記憶装置に記憶したMOSS化された制御ファイルを設定
し、upload依頼要求(開始）要求メッセージを生成し、
生成した上記要求メッセージを送信処理部605に渡し、
転送サーバにネットワークを介して送信し、受信処理部
606は送信したメッセージに対するレスポンスメッセー
ジの受信待ち状態に入り、転送サーバでは送られてきた
要求メッセージを受信処理部653が受信し、リクエスト
解析処理部654に渡し、上記リクエスト解析処理部で
は、要求メッセージのrequest commandの値から、uploa
d依頼要求（開始）要求メッセージであることを識別し
トランザクション制御部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では、転送サーバでは、
上記トランザクション制御部がレスポンス組立処理部65
5に依頼し、受信したupload依頼要求(開始）要求メッセ
ージに対応するレスポンスメッセージ(例えばupload依
頼要求(終了)レスポンスメッセージと呼ぶ）を、図3に
示したHTTPに準拠したレスポンスメッセージのフォーマ
ットの実現例にのっとり、あらかじめupload依頼要求
(終了)レスポンスメッセージとして、クライアント、転
送サーバで取り決められたcontent-type、及びresponse
commandを設定し、データ文として、上記内部メモリか
ら取得した上記トランザクション識別子を設定し、uplo
ad依頼要求(終了)レスポンスメッセージを生成し、送信
処理部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要求(開始)要求メ
ッセージに対応するレスポンスメッセージ(例えばuploa
d upfile.i.j(終了)レスポンスメッセージと呼ぶ)を、
図3に示したHTTPに準拠したレスポンスメッセージのフ
ォーマットの実現例にのっとり、あらかじめupload upf
ile.i.j(終了)をレスポンスメッセージとして、クライ
アント、転送サーバで取り決められたcontent-type、及
びresponse commandを設定し、データ文として、上記up
load 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に依頼し、パラメータで指定した条件を満たす
制御ファイルの取得を要求する要求メッセージ(例えばl
ist要求(開始)要求メッセージと呼ぶ)として、図2に示
したHTTPに準拠した要求フォーマットの実現例にのっと
り、あらかじめlist要求(開始)要求メッセージとして、
クライアント、転送サーバで取り決められたcontent-ty
pe、及びrequest commandを設定し、受信者が電子ファ
イルの受信者に指定されており、且つ制御ファイルに記
載された電子ファイルのダウンロードを全く開始してい
ない制御ファイルを検索することをサーバに指示するパ
ラメータ、及び受信者の受信者識別子を例えば外部記憶
装置より取得してデータ文に設定し、list要求(開始)要
求メッセージを生成し、送信処理部605に渡し、転送サ
ーバにネットワークを介して送信し、受信処理部606は
送信したメッセージに対するレスポンスメッセージの受
信待ち状態に入り、次に転送サーバでは送られてきた要
求メッセージを受信処理部653で受信し、リクエスト解
析処理部654に渡す。リクエスト解析処理部では、要求
メッセージのrequest commandフィールドの値から、lis
t要求(開始)要求メッセージであることを識別し、デー
タ文フィールドより受信者の受信者識別子を取得し内部
メモリに記憶し、さらにデータ文フィールドより上記要
求メッセージがファイルのダウンロードを全く開始して
いない制御ファイルを検索することをサーバに指示して
いることを認識し、トランザクション制御部に通知す
る。

【００９５】次にステップ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では、受信クライアント
ではトランザクション制御部において、ユニークなdown
loadTicketを例えば乱数を用いて生成し、内部メモリに
格納する。

【０１００】次にステップ307では、受信クライアント
では、トランザクション制御部において、内部メモリよ
り上記downloadTicket、受信者、及び転送サーバの公開
鍵を取り出し、さらに転送サーバの受信者識別子と受信
者の秘密鍵、及び受信者の受信者識別子を例えば外部記
憶装置より取りだし、つづいて上記downloadTicket、受
信者の受信者識別子を暗号化するためのDEKをDEK生成処
理部に依頼し、上記DEKを例えば乱数にて生成し、第一
番目のRecipient-IDに受信者の受信者識別子、続くkey-
infoに共有鍵交換方式例えばDiffie Hellman方式により
暗号処理部に依頼し、上記受信者の公開鍵と上記受信者
の秘密鍵で生成した共有鍵で上記downloadTicket、受信
者の受信者識別子を暗号するためのDEKを暗号化したも
のを設定し、第二番目のRecipient-IDに転送サーバの受
信者識別子を、続くkey-infoに共有鍵交換方式、例えば
Diffie Hellman方式により暗号処理部に依頼し、上記転
送サーバの公開鍵と上記受信者の秘密鍵で生成した共有
鍵で上記downloadTicket、受信者の受信者識別子を暗号
するためのDEKを暗号化したものを設定し、上記downloa
dTicket、受信者の受信者識別に渡し、上記DEKで上記do
wnloadTicket、受信者の受信者識別子を秘密鍵暗号方式
例えばFealにて暗号化し、downloadTicket、受信者の受
信者識別子MOSSフォーマット化し、内部メモリまたは外
部記憶装置に記憶する。

【０１０１】次にステップ308では、受信クライアント
ではトランザクション制御部619が、リクエスト組立処
理部607に依頼し、電子ファイルの受信クライアントへ
のダウンロードを要求するメッセージ(例えばdownload
依頼要求(開始）要求メッセージと呼ぶ)を要求メッセー
ジとして、図2に示したHTTPに準拠した要求メッセージ
のフォーマットの実現例に従い、あらかじめdownload依
頼要求(開始)要求メッセージとして、クライアント、転
送サーバで取り決められたcontent-type、及びrequest
commandを設定し、データ文として上記内部メモリまた
は外部記憶装置に記憶したMOSSフォーマット化されたdo
wnloadTicket、受信の受信者識別子、及び上記MOSSフォ
ーマット化された制御ファイルを設定し、download依頼
要求(開始)要求メッセージを生成し、生成した上記要求
メッセージを送信処理部605に渡し、転送サーバにネッ
トワークを介して送信し、受信処理部606は送信したメ
ッセージに対するレスポンスメッセージの受信待ち状態
に入り、転送サーバでは送られてきた要求メッセージを
受信処理部653が受信し、リクエスト解析処理部654に渡
し、上記リクエスト解析処理部では、要求メッセージの
request commandの値から、download依頼要求(開始)要
求メッセージであることを識別しトランザクション制御
部664に通知し、データ文フィールドより上記MOSSフォ
ーマット化されたdownloadTicket、受信者の受信者識別
子及び上記MOSSフォーマット化された制御ファイルを取
得し、上記MOSSフォーマット化されたdownloadTicket、
受信者の受信者識別子の第一番目のRecipient-IDより受
信者の受信者識別子を取得し内部メモリに格納し、上記
MOSSフォーマット化された制御ファイルの第一番目のRe
cipient-IDより送信者の受信者識別子を取得し内部メモ
リに格納し、上記取得したMOSSフォーマット化されたdo
wnloadTicket、受信者の受信者識別子、及びMOSSフォー
マット化された制御ファイルを内部メモリまたは外部記
憶装置に記憶する。

【０１０２】次にステップ309では、転送サーバではト
ランザクション制御部が公開鍵取得部に依頼し、内部メ
モリに記憶されている受信者の受信者識別子、送信者の
受信者識別子、例えば外部記憶装置に記憶されている転
送サーバ自身の受信者識別子をキーにCAサーバに公開鍵
の取得メッセージを送信し、レスポンスとして対応する
公開鍵を取得し、内部メモリに受信者識別子と関連づけ
て記憶する。

【０１０３】次にステップ310では、転送サーバではト
ランザクション制御部が、制御ファイル解析処理部に依
頼し、上記内部メモリまたは外部記憶装置に記憶された
制御ファイルより、転送サーバの受信者識別子でRecipi
ent-IDを検索し、続くkey-infoより暗号化された制御フ
ァイル0の暗号化に利用したDEKを取り出し、内部メモリ
より送信者の公開鍵を取得し、例えば外部記憶装置より
転送サーバの秘密鍵を取得し、復号処理部659に依頼
し、共有鍵交換方式例えばDiffie Hellman方式により送
信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成
し、上記共有鍵を用いて上記暗号化された制御ファイル
0の暗号化に利用したDEKを復号化し、上記復号化したDE
Kを用いて制御ファイル0を復号化し、内部メモリまたは
外部記憶装置に記録する。このとき制御ファイル0の文
脈をチェックし、制御ファイル0のフォーマットとして
解読不能の場合、不正な制御ファイルの受信と判断しエ
ラー処理に入り、フォーマットに問題がない場合、さら
に上記受信した要求メッセージのMOSSフォーマット化さ
れたdownloadTicket、受信者の受信者識別子より、転送
サーバの受信者識別子でRecipient-IDを検索し、対応す
るkey-infoより暗号化されたdownloadTicket、受信者の
受信者識別子の暗号化に利用したDEKを取り出し、内部
メモリより受信者の公開鍵を取得し、例えば外部記憶装
置より転送サーバの秘密鍵を取得し、復号処理部659に
依頼し、共有鍵交換方式例えばDiffie Hellman方式によ
り受信者の公開鍵と転送サーバの秘密鍵より共有鍵を生
成し、上記共有鍵を用いて暗号化されたdownloadTicke
t、受信者の受信識別子の暗号化に利用したDEKを復号化
し、上記DEKを用いてdownloadTicket、受信者の受信者
識別子を復号化し、復号化した受信者識別子と内部メモ
リに記憶されている受信者識別子を比較し、上記比較結
果が一致しない場合、不正なdownloadTicket、受信者の
受信者識別子の受信と判断しエラー処理に入り、一致し
た場合、上記downloadTicketを内部メモリに記憶し、さ
らに上記復号化した制御ファイル0より制御ファイル識
別子を取得し、内部メモリに記憶する。

【０１０４】次にステップ311では、転送サーバではト
ランザクション制御部が、ユニークなトランザクション
識別子を例えば乱数にて生成し内部メモリに格納する。

【０１０５】次にステップ312では、転送サーバではト
ランザクション制御部が、データベース制御処理部に依
頼し、ダウンロードトランザクションを管理しているテ
ーブルに、上記内部メモリに記憶されている制御ファイ
ル識別子、受信者の受信者識別子、及び上記生成したト
ランザクション識別子、及びdownloadTicketをフィール
ド値とするレコードを、ステータスフィールドを未完と
し新たに追加する。

【０１０６】次にステップ313では、転送サーバでは、
上記トランザクション制御部が、レスポンス組立処理部
655に依頼し、受信したdownload依頼要求(開始)要求メ
ッセージに対応するレスポンスメッセージ(例えばdownl
oad依頼要求(終了)レスポンスメッセージと呼ぶ)を、図
3に示したHTTPに準拠したレスポンスメッセージのフォ
ーマットの実現例にのっとり、あらかじめdownload依頼
要求(終了)レスポンスメッセージとして、クライアン
ト、転送サーバで取り決められたcontent-type、及びre
sponse commandを設定し、データ文として、上記内部メ
モリから取得した上記トランザクション識別子を設定
し、download依頼要求(終了)レスポンスメッセージを生
成し、送信処理部652に渡し、受信クライアントにネッ
トワークを介して送信し、受信クライアントでは送られ
てきたレスポンスメッセージを受信処理部606で受信
し、レスポンス解析処理部608に渡す。レスポンス解析
処理部では、要求メッセージのresponse commandフィー
ルドの値から、download依頼要求(終了)レスポンスメッ
セージであることを識別し、データ文フィールドよりト
ランザクション識別子を取り出し、内部メモリに格納
し、トランザクション制御部に通知する。

【０１０７】次にステップ314では、受信クライアント
では、トランザクション制御部において、内部メモリに
記憶されたダウンロードするブロックファイル名、及び
受信ログより未ダウンロードのブロックファイルを取得
し、リクエスト組立処理部に依頼し、上記取得されたブ
ロックファイル名に対応するブロックファイルの1つを
転送サーバからダウンロードすることを要求するための
要求メッセージ(例えばdownload upfile.i.j要求(開始)
要求メッセージと呼ぶ)として、図2に示したHTTPに準拠
した要求フォーマットにのっとり、あらかじめdownload
upfile.i.j要求(開始)要求メッセージとして、クライ
アント、転送サーバで決められたcontent-type、及びre
quest 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要求(開始）要求メッ
セージに対応するレスポンスメッセージ(例えばdownloa
d upfile.i.j(終了)レスポンスメッセージと呼ぶ)を、
図3に示したHTTPに準拠したレスポンスメッセージのフ
ォーマットの実現例にのっとり、あらかじめdownload u
pfile.i.j(終了)レスポンスメッセージとして、クライ
アント、転送サーバで取り決められたcontent-type、及
びresponse commandを設定し、データ文として、上記内
部メモリに格納されたトランザクション識別子、ブロッ
クファイル名、及び内部メモリまたは外部記憶装置に記
憶され暗号化されたブロックファイル(upfile.i.j)を設
定し、download upfile.i.j要求(終了)レスポンスメッ
セージを生成し、送信処理部に渡し、受信クライアント
にネットワークを介して送信する。次に受信クライアン
トでは送られてきたレスポンスメッセージを受信処理部
606で受信し、レスポンス解析処理部608に渡す。レスポ
ンス解析処理部では、要求メッセージのresponse comma
ndフィールドの値から、download upfile.i.j(終了)レ
スポンスメッセージであることを識別し、データ文フィ
ールドよりトランザクション識別子、ブロックファイル
名を取得し内部メモリに格納し、さらにデータ文より暗
号化されたブロックファイル(upfile.i.j)を取得し、外
部記憶装置に上記ブロックファイル名と関連づけて記憶
し、上記トランザクション識別子、上記ブロックファイ
ル名を、内部メモリまたは外部記憶装置に受信ログとし
て記録する。

【０１１０】次にステップ317では、受信クライアント
では、トランザクション制御部が上記受信ログの記録、
及び上記内部メモリに格納された受信するブロックファ
イル名をチェックし、未受信のブロックファイルがある
か調べる。未受信のブロックファイルが存在する場合、
ステップ314に戻る。

【０１１１】次にステップ318では、受信クライアント
では、トランザクション制御部が上記内部メモリ若しく
は外部記憶装置に保存している制御ファイル1よりMaste
rDEKを取得し、内部メモリに格納する。

【０１１２】次にステップ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では、受信クライアント
では、トランザクション制御部が、例えば外部記憶装置
より受信者の受信者識別子を取得し、上記内部メモリに
格納されているトランザクション識別子、downloadTick
et及び上記ダウンロードが終了した電子ファイルのファ
イル名(upfile.i)を記述したCompleteTicketを生成し、
内部メモリより受信者、及び転送サーバの公開鍵を取り
出し、さらに受信者の受信者識別子と秘密鍵を例えば外
部記憶装置より取りだし、つづいて上記Complete Ticke
tを暗号化するためのDEKをDEK生成処理部に依頼し、例
えば乱数を用いて生成し、第一番目のRecipient-IDに受
信者の受信者識別子を、続くkey-infoに共有鍵交換方
式、例えばDiffie Hellman方式により受信者の公開鍵と
受信者の秘密鍵より暗号処理部に依頼し共有鍵を生成
し、上記生成した共有鍵で上記CompleteTicketを暗号す
るためのDEKを暗号処理部に依頼し暗号化したものを設
定し、第二番目のRecipient-IDに転送サーバの受信者識
別子を、続くkey-infoに共有鍵交換方式、例えばDiffie
Hellman方式により転送サーバの公開鍵と受信者の秘密
鍵より暗号処理部に依頼し共有鍵を生成し、上記生成し
た共有鍵で上記CompleteTicketを暗号するためのDEKを
暗号処理部に依頼し暗号化したものを設定し、上記Comp
leteTicketを暗号処理部に依頼し、上記DEKを秘密暗号
方式例えばFealにて暗号化しCompleteTicketをMOSSフォ
ーマット化し、内部メモリに格納する。

【０１１７】次にステップ324では、受信クライアント
ではトランザクション制御部619が、リクエスト組立処
理部607に依頼し、電子ファイルの受信クライアントへ
のダウンロードの終了を通知する要求メッセージ(例え
ばdownload complete要求(開始）要求メッセージと呼
ぶ)を要求メッセージとして、図2に示したHTTPに準拠し
た要求メッセージのフォーマットの実現例に従い、あら
かじめdownload complete要求(開始)を要求メッセージ
として、クライアント、転送サーバで取り決められたco
ntent-type、及びrequest commandを設定し、データ文
として上記内部メモリまたは外部記憶装置に記憶したMO
SSフォーマット化されたCompleteTicketを設定し、down
load complete要求（開始）要求メッセージを生成し、
生成した上記要求メッセージを送信処理部605に渡し、
転送サーバにネットワークを介して送信し、受信処理部
606は送信したメッセージに対するレスポンスメッセー
ジの受信待ち状態に入り、転送サーバでは送られてきた
要求メッセージを受信処理部653が受信し、リクエスト
解析処理部654に渡し、上記リクエスト解析処理部で
は、要求メッセージのrequest commandの値から、downl
oad complete要求(開始)要求メッセージであることを識
別しトランザクション制御部664に通知し、データ文フ
ィールドより上記MOSSフォーマット化されたCompleteTi
cketを取得し、上記MOSSフォーマット化されたComplete
Ticketを内部メモリまたは外部記憶装置に記憶する。

【０１１８】次にステップ325では、転送サーバではト
ランザクション制御部が、上記内部メモリより上記MOSS
フォーマット化されたCompleteTicketを取得し、上記MO
SSフォーマット化されたCompleteTicketの第一番目のRe
cipient-IDよりMOSSフォーマット化されたCompleteTick
etの送信者(電子ファイルの受信者)の受信者識別子を取
得し、内部メモリより上記受信者識別子に対応する受信
者の公開鍵を取得し、続いて上記MOSSフォーマット化さ
れたCompleteTicketの第二番目のRecipient-IDに例えば
外部記憶装置に記録された転送サーバの受信者識別子が
含まれることを確認し、続くkey-infoより暗号化された
DEKを取り出し、復号処理部659に依頼し、共有鍵交換方
式例えばDiffie Hellman方式によりMOSSフォーマット化
されたCompleteTicketの送信者（電子ファイルの受信
者)の公開鍵と、転送サーバの例えば外部記憶装置に記
録された秘密鍵より共有鍵を生成し、上記共有鍵を用い
て上記暗号化されたDEKを復号化し、上記DEKを用いて上
記MOSSフォーマット化されたCompleteTicketを復号化
し、復号化した上記Complete Ticketより、MOSSフォー
マット化されたCompleteTicketの送信者(電子ファイル
の受信者)の受信者識別子、トランザクション識別子、d
ownloadTicket、受信ファイル名(upfile.i）を取りだし
内部メモリに記憶する。このとき取り出した受信者識別
子と内部メモリに格納されていた受信者の受信者識別子
を比較し、同値でない場合、不正なCompleteTicketの受
信と判断しエラー処理に入る。

【０１１９】次にステップ326では、転送サーバではト
ランザクション制御部が、データベース管理部に依頼
し、ダウンロードトランザクションを管理しているテー
ブルを、上記内部メモリ記憶されているトランザクショ
ン識別子、及びdownloadTicketをキーに検索し、マッチ
したレコードのステータスフィールドの値を完了にす
る。

【０１２０】次にステップ327では、転送サーバでは、
上記トランザクション制御部が、レスポンス組立処理部
655に依頼し、受信したdownload complete依頼要求(開
始)要求メッセージに対応するレスポンスメッセージ(例
えばdownload complete要求(終了)レスポンスメッセー
ジと呼ぶ)を、図3に示したHTTPに準拠したレスポンスメ
ッセージのフォーマットの実現例にのっとり、あらかじ
めdownload complete要求(終了)レスポンスメッセージ
として、クライアント、転送サーバで取り決められたco
ntent-type、及びresponse commandを設定し、データ文
として、上記内部メモリに格納されている受信クライア
ントから受信したdownloadTicket、及び上記内部メモリ
に格納されている受信クライアントから受信したトラン
ザクション識別子を設定し、download complete要求(終
了)レスポンスメッセージを生成し、送信処理部652に渡
し、受信クライアントにネットワークを介して送信し、
転送サーバは上記トランザクション識別子に対応するダ
ウンロード処理を終了し、受信クライアントでは送られ
てきたレスポンスメッセージを受信処理部606で受信
し、レスポンス解析処理部608に渡す。レスポンス解析
処理部では、要求メッセージのresponse commandフィー
ルドの値から、download complete要求(終了)レスポン
スメッセージであることを識別し、データ文フィールド
よりトランザクション識別子を取り出し、トランザクシ
ョン制御部に通知し、トランザクション制御部は、上記
トランザクション識別子に対応するダウンロード処理を
終了する。

【０１２１】ダウンロード再受信処理におけるフロチャ
ートの実現例を図23、図24、図25、及び図26に示す。

【０１２２】以下、ダウンロード再受信処理について説
明する。

【０１２３】ステップ401では、受信クライアントで
は、トランザクション制御部がタイマ621を監視し、他
のトランザクションが開始されていない状態であれば、
あらかじめ指定された一定時間間隔でリクエスト組立処
理部607に依頼し、パラメータで指定した条件を満たす
制御ファイルの取得を要求する要求メッセージ(例えばl
ist要求(開始)要求メッセージと呼ぶ)として、図2に示
したHTTPに準拠した要求フォーマットの実現例にのっと
り、あらかじめlist要求(開始)要求メッセージとして、
クライアント、転送サーバで取り決められたcontent-ty
pe、及び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より制御ファイル識別
子を取得し、データベース管理部に依頼し、上記内部メ
モリに格納された受信者識別子と上記制御ファイル識別
子をキーにダウンロードトランザクションを管理してい
るテーブルを検索し、マッチするレコードよりdownload
Ticketを取得し、内部メモリに格納する。

【０１３０】次にステップ408では、転送サーバではト
ランザクション制御部が、内部メモリより上記download
Ticket、受信者の受信者識別子、受信者の公開鍵を取得
し、さらに転送サーバの秘密鍵を例えば外部記憶装置よ
り取りだし、つづいて上記downloadTicketを暗号化する
ためのDEKをDEK生成処理部667に依頼し、例えば乱数に
て生成し、Recipient-IDに受信者の受信者識別子を、続
くkey-infoに共有鍵交換方式、例えばDiffie Hellman方
式により受信者の公開鍵と転送サーバの秘密鍵で共有鍵
を生成し、上記共有鍵で上記downloadTicketを暗号する
ためのDEKを暗号処理部に依頼し暗号化したものを設定
し、上記downloadTicketを暗号処理部に依頼し、上記DE
Kで上記downloadTicketを秘密鍵暗号方式例えばFealに
て暗号化し、downloadTicketをMOSSフォーマット化し、
内部メモリに格納する。

【０１３１】次にステップ409では、転送サーバではト
ランザクション制御部が、レスポンス組立処理部655に
依頼し、受信したinfo要求(開始)要求メッセージに対応
するinfo要求(終了)レスポンスメッセージを、図3に示
したHTTPに準拠したレスポンスメッセージのフォーマッ
トの実現例にのっとり、あらかじめlist要求(終了)レス
ポンスメッセージとして、クライアント、転送サーバで
取り決められたcontent-type、及びresponse commandを
設定し、データ文として、上記内部メモリに記録された
MOSSフォーマット化されたdownloadTicketを設定し、li
st要求(終了)レスポンスメッセージを生成し、送信処理
部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を復号化し、上記D
EKを用いて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方式により上記転送サーバの公開鍵と
上記受信者の秘密鍵で生成した共有鍵で上記downloadTi
cket、受信者の受信者識別子を暗号するためのDEKを暗
号化したものを設定し、上記downloadTicket、受信者の
受信者識別子を暗号処理部に依頼し、上記DEKで上記dow
nloadTicket、受信者の受信者識別子を秘密鍵暗号方式
例えばFealにて暗号化し、downloadTicket、受信者の受
信者識別子をMOSSフォーマット化し、内部メモリまたは
外部記憶装置に記憶する。

【０１３５】次にステップ413では、受信クライアント
ではトランザクション制御部619が、リクエスト組立処
理部607に依頼し、電子ファイルの受信クライアントへ
のダウンロードを要求するメッセージ(例えばdownload
依頼要求(開始）要求メッセージと呼ぶ)を要求メッセー
ジとして、図2に示したHTTPに準拠した要求メッセージ
のフォーマットの実現例に従い、あらかじめdownload依
頼要求(開始）要求メッセージとして、クライアント、
転送サーバで取り決められたcontent-type、及びreques
t commandを設定し、データ文として上記内部メモリま
たは外部記憶装置に記憶したMOSSフォーマット化された
downloadTicket、受信者の受信者識別子、及び上記MOSS
フォーマット化された制御ファイルを設定し、download
依頼要求(開始)要求メッセージを生成し、生成した上記
要求メッセージを送信処理部605に渡し、転送サーバに
ネットワークを介して送信し、受信処理部606は送信し
たメッセージに対するレスポンスメッセージの受信待ち
状態に入り、転送サーバでは送られてきた要求メッセー
ジを受信処理部653が受信し、リクエスト解析処理部654
に渡し、上記リクエスト解析処理部では、要求メッセー
ジのrequest commandの値から、download依頼要求(開
始)要求メッセージであることを識別しトランザクショ
ン制御部664に通知し、データ文フィールドより上記MOS
Sフォーマット化されたdownloadTicket、受信者の受信
者識別子及び上記MOSSフォーマット化された制御ファイ
ルを取得し、MOSSフォーマット化されたdownloadTicke
t、受信者の受信者識別子の第一番目のRecipient-IDよ
り受信者の受信者識別子を取得し内部メモリに格納し、
上記MOSSフォーマット化された制御ファイルの第一番目
のRecipient-IDより送信者の受信者識別子を取得し内部
メモリに格納し、上記取得したMOSSフォーマット化され
たdownloadTicket、受信者の受信者識別子、及びMOSSフ
ォーマット化された制御ファイルを内部メモリまたは外
部記憶装置に記憶する。

【０１３６】次にステップ414では、転送サーバではト
ランザクション制御部が公開鍵取得部に依頼し、内部メ
モリに記憶されている受信者の受信者識別子、送信者の
受信者識別子、例えば外部記憶装置に記憶されている転
送サーバ自身の受信者識別子をキーにCAサーバに公開鍵
の取得メッセージを送信し、レスポンスとして対応する
公開鍵を取得し、内部メモリに受信者識別子と関連づけ
て記憶する。

【０１３７】次にステップ415では、転送サーバではト
ランザクション制御部が、制御ファイル解析処理部に依
頼し、上記内部メモリまたは外部記憶装置に記憶された
制御ファイルより、転送サーバの受信者識別子でRecipi
ent-IDを検索し、続くkey-infoより暗号化された制御フ
ァイル0の暗号化に利用したDEKを取り出し、内部メモリ
より送信者の公開鍵を取得し、例えば外部記憶装置より
転送サーバの秘密鍵を取得し、復号処理部659に依頼
し、共有鍵交換方式例えばDiffie Hellman方式により送
信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成
し、上記共有鍵を用いて上記暗号化された制御ファイル
0の暗号化に利用したDEKを復号化し、上記復号化したDE
Kを用いて制御ファイル0を復号化し、内部メモリまたは
外部記憶装置に記録する。このとき制御ファイル0の文
脈をチェックし、制御ファイル0のフォーマットとして
解読不能の場合、不正な制御ファイルの受信と判断しエ
ラー処理に入り、フォーマットに問題がない場合、さら
に上記受信した要求メッセージのMOSSフォーマット化さ
れたdownloadTicket、受信者の受信者識別子より、転送
サーバの受信者識別子でRecipient-IDを検索し、対応す
るkey-infoより暗号化されたdownloadTicket、受信者の
受信者識別子の暗号化に利用したDEKを取り出し、内部
メモリより受信者の公開鍵を取得し、例えば外部記憶装
置より転送サーバの秘密鍵を取得し、復号処理部に依頼
し、共有鍵交換方式例えばDiffie Hellman方式により受
信者の公開鍵と転送サーバの秘密鍵より共有鍵を生成
し、上記共有鍵を用いて暗号化されたdownloadTicket、
受信者の受信者識別子の暗号化に利用したDEKを復号化
し、上記DEKを用いてdownloadTicket、受信者の受信者
識別子を復号化し、復号化した受信者識別子と内部メモ
リに記憶されている受信者識別子を比較し、上記比較結
果が一致しない場合、不正なdownloadTicket、受信者の
受信者識別子の受信と判断しエラー処理に入り、一致し
た場合、上記downloadTicketを内部メモリに記憶する。

【０１３８】次にステップ416では、転送サーバではト
ランザクション制御部が、データベース管理部に依頼
し、上記内部メモリに格納されたdownloadTicketをキー
として、ダウンロードトランザクションを管理している
テーブルを検索し、マッチするレコードより、トランザ
クション識別子を取得し、内部メモリに格納する。

【０１３９】次にステップ417では、転送サーバでは、
上記トランザクション制御部が、レスポンス組立処理部
655に依頼し、受信したdownload依頼要求（開始)を要求
メッセージに対応するレスポンスメッセージ(例えばdow
nload依頼要求（終了)レスポンスメッセージと呼ぶ)
を、図3に示したHTTPに準拠したレスポンスメッセージ
のフォーマットの実現例にのっとり、あらかじめdownlo
ad依頼要求(終了)レスポンスメッセージとして、クライ
アント、転送サーバで取り決められた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に
準拠した要求フォーマットにのっとり、あらかじめdown
load upfile.i.j要求(開始)要求メッセージとして、ク
ライアント、転送サーバで決められたcontent-type、及
びrequest commandを設定し、データ文として、第一に
上記内部メモリに格納されたトランザクション識別子、
第二に受信するブロックファイルのブロックファイル
名、を設定し、download upfile.i.j要求(開始）要求メ
ッセージを生成し、送信処理部605に渡し、転送サーバ
にネットワークを介して送信し、受信処理部606は送信
した要求メッセージに対するレスポンスメッセージの受
信待ち状態に入り、次に転送サーバでは送られてきた要
求メッセージを受信処理部653で受信し、リクエスト解
析処理部654に渡す。リクエスト解析処理部では、要求
メッセージのrequest commandフィールドの値から、dow
nload upfile.i.j要求(開始）要求メッセージであるこ
とを識別し、データ文フィールドよりトランザクション
識別子、ブロックファイル名を取得し内部メモリに記憶
する。

【０１４２】次にステップ420では、転送サーバではト
ランザクション制御部が、データベース制御処理部661
に依頼し、上記取得したトランザクション識別子をキー
としてデータベースに記録されたファイルのダウンロー
ドトランザクションを管理しているテーブルを検索し、
マッチするレコードより制御ファイル識別子を取得し、
さらに上記制御ファイル識別子、及び受信したブロック
ファイル名をキーとして、ブロックファイルを管理して
いるテーブルを検索し、マッチするレコードのブロック
ファイルの保存先を取得し、取得した保存先より暗号化
されたブロックファイル(upfile.i.j)を取得し、内部メ
モリまたは外部記憶装置に記憶する。

【０１４３】次にステップ421では、転送サーバではト
ランザクション制御部が、レスポンス組立処理部に依頼
し、受信したdownload upfile.i.j要求(開始)要求メッ
セージに対応するレスポンスメッセージ(例えばdownloa
d upfile.i.j(終了)レスポンスメッセージと呼ぶ)を、
図3に示したHTTPに準拠したレスポンスメッセージのフ
ォーマットの実現例にのっとり、あらかじめdownload u
pfile.i.j(終了)をレスポンスメッセージとして、クラ
イアント、転送サーバで取り決められたcontent-type、
及びresponse commandを設定し、データ文として、上記
内部メモリに格納されたトランザクション識別子、ブロ
ックファイル名、及び内部メモリまたは外部記憶装置に
記憶され暗号化されたブロックファイル(upfile.i.j)を
設定し、download upfile.i.j要求(終了)レスポンスメ
ッセージを生成し、送信処理部に渡し、受信クライアン
トにネットワークを介して送信する。次に受信クライア
ントでは送られてきたレスポンスメッセージを受信処理
部606で受信し、レスポンス解析処理部608に渡す。レス
ポンス解析処理部では、要求メッセージのresponsecomm
andフィールドの値から、download upfile.i.j(終了)レ
スポンスメッセージであることを識別し、データ文フィ
ールドよりトランザクション識別子、ブロックファイル
名を取得し内部メモリに格納し、さらにデータ文より暗
号化されたブロックファイル(upfile.i.j）を取得し、
外部記憶装置に上記ブロックファイル名と関連づけて記
憶し、上記トランザクション識別子、上記ブロックファ
イル名を、内部メモリまたは外部記憶装置に受信ログと
して記録する。

【０１４４】次にステップ422では、受信クライアント
では、トランザクション制御部が上記受信ログの記録、
及び上記内部メモリに格納された受信するブロックファ
イル名をチェックし、未受信のブロックファイルがある
か調べる。未受信のブロックファイルが存在する場合、
ステップ419に戻る。

【０１４５】次にステップ423では、受信クライアント
では、トランザクション制御部が上記内部メモリ若しく
は外部記憶装置に保存している制御ファイル1よりMaste
rDEKを取得し、内部メモリに格納する。

【０１４６】次にステップ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では、受信クライアント
では、トランザクション制御部が、例えば外部記憶装置
より受信者の受信者識別子を取得し、上記内部メモリに
格納されているトランザクション識別子、downloadTick
et、及び上記ダウンロードが終了した電子ファイルのフ
ァイル名(upfile.i）を記述したCompleteTicketを生成
し、内部メモリより受信者、及び転送サーバの公開鍵を
取り出し、さらに受信者の受信者識別子と秘密鍵、及び
転送サーバの受信者識別子を例えば外部記憶装置より取
りだし、つづいてDEK生成処理部に依頼し、上記Complet
eTicketを暗号化するためのDEKを例えば乱数を用いて生
成し、Recipient-IDに受信者の受信者識別子を第一番目
に、続くkey-infoに共有鍵交換方式、例えばDiffie Hel
lman方式により受信者の公開鍵と受信者の秘密鍵より暗
号処理部に依頼し共有鍵を生成し、上記生成した共有鍵
で上記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要求(開始）要求メッセージと
して、クライアント、転送サーバで取り決められたcont
ent-type、及びrequest commandを設定し、データ文と
して上記内部メモリまたは外部記憶装置に記憶したMOSS
フォーマット化されたCompleteTicketを設定し、downlo
ad complete要求(開始）要求メッセージを生成し、生成
した上記要求メッセージを送信処理部605に渡し、転送
サーバにネットワークを介して送信し、受信処理部606
は送信したメッセージに対するレスポンスメッセージの
受信待ち状態に入り、転送サーバでは送られてきた要求
メッセージを受信処理部653が受信し、リクエスト解析
処理部654に渡し、上記リクエスト解析処理部では、要
求メッセージのrequest commandの値から、download co
mplete要求(開始)要求メッセージであることを識別しト
ランザクション制御部664に通知し、データ文フィール
ドより上記MOSSフォーマット化されたCompleteTicketを
取得し、上記MOSSフォーマット化されたCompleteTicket
を内部メモリまたは外部記憶装置に記憶する。

【０１５２】次にステップ430では、転送サーバではト
ランザクション制御部が、上記内部メモリより上記MOSS
フォーマット化されたCompleteTicketを取得し、上記MO
SSフォーマット化されたCompleteTicketの第一番目のRe
cipient-IDよりMOSSフォーマット化されたCompleteTick
etの送信者(電子ファイルの受信者)の受信者識別子を取
得し、内部メモリより上記受信者識別子に対応する受信
者の公開鍵、及び転送サーバの公開鍵を取得し、続いて
上記MOSSフォーマット化されたCompleteTicketの第二番
目のRecipient-IDに例えば外部記憶装置に記録された転
送サーバの受信者識別子が含まれることを確認し、続く
key-infoより暗号化されたDEKを取り出し、復号処理部5
59に依頼し、共有鍵交換方式例えばDiffie Hellman方式
によりMOSSフォーマット化されたCompleteTicketの送信
者(電子ファイルの受信者)の公開鍵と、転送サーバの例
えば外部記憶装置に記録された秘密鍵より共有鍵を生成
し、上記共有鍵を用いて上記暗号化されたDEKを復号化
し、上記DEKを用いて上記MOSSフォーマット化されたCom
pleteTicketを復号化し、復号化した上記CompleteTicke
tより、MOSSフォーマット化されたCompleteTicketの送
信者(電子ファイルの受信者)の受信者識別子、トランザ
クション識別子、downloadTicket、受信ファイル名(upf
ile.i)を取りだし内部メモリに記憶する。このとき取り
出した受信者の受信者識別子と内部メモリに記憶されて
いた受信者識別子を比較し、同値でない場合、不正なCo
mpleteTicketの受信と判断しエラー処理に入る。

【０１５３】次にステップ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
を利用した安全で且つファイルサイズによらないファイ
ル転送システムを容易に構築することが可能となる。

【０１５６】また、請求項２記載の発明によれば、制御
ファイルにファイルの転送先が少なくても１つ以上記載
されているので、１対複数の転送が可能となる。

【０１５７】また、請求項３記載の発明によれば、転送
サーバ上にある制御ファイルの転送先を送信クライアン
トによって変更可能とする手段を有するので、１度サー
バーに転送しておけば制御ファイルの転送先を変更する
ことで、他のクライアントに転送可能となる。

【０１５８】また、請求項４記載の発明によれば、送信
クライアントが、送信するファイルをブロック化する手
段と、暗号化する手段と、ブロック化した情報を制御フ
ァイルに書きこむ手段を有し、受信クライアントが、暗
号化されたブロックを復号化する手段と、復号化したブ
ロックを制御ファイルに書きこまれているブロック化し
た情報をもとにファイルを組み立てる手段を有するの
で、例えば、マルチスレッドによるファイルブロックの
転送が可能となり高速なファイル転送が実現できる。

【０１５９】また、請求項５記載の発明によれば、送信
クライアントから転送サーバにファイルを転送する際に
異常があった場合に送信クライアントが未送信のブロッ
ク化したファイルのみを送信する手段を有するので、送
信時に転送を失敗しても、ブロック単位で再送が可能と
なる。

【０１６０】また、請求項６記載の発明によれば、転送
サーバから受信クライアントにファイルを転送する際に
異常があった場合に受信クライアントが未受信のブロッ
ク化したファイルのみを受信する手段を有するので、受
信時に転送を失敗しても、ブロック単位で再受信が可能
となる。

【０１６１】また、請求項７記載の発明によれば、制御
ファイルが送信クライアントから受信クライアントのみ
で情報交換を行う部分と、送信クライアントから受信ク
ライアント間、送信クライアントから転送サーバ間、転
送サーバから受信クライアント間で情報交換を行う部分
との、２階層で構成されているので、制御ファイルの管
理が容易であり、また、請求項８記載の発明によれば、
制御ファイルの送信クライアントから受信クライアント
のみで情報交換を行う部分が受信クライアントのみで復
号化できる暗号で記載されているので、ファイル転送経
路にある転送サーバなとでサーバ管理者を含めた第三者
に内容を知られる危険性がない。

【図面の簡単な説明】

【図１】本発明によるファイル転送システムのシステム
構成の実現例。

【図２】クライアントから転送サーバへの要求メッセー
ジのフォーマットの実現例。

【図３】転送サーバからクライアントへのレスポンスメ
ッセージのフォーマットの実現例。

【図４】制御ファイル1のフォーマット例。

【図５】MOSSフォーマット化される前の制御ファイル1
の記述例。

【図６】送信者から電子ファイルの受信者向けにMOSSフ
ォーマット化された制御ファイル1の実現例。

【図７】先行技術Diffie Hellmanによる鍵交換方式。

【図８】制御ファイル0のフォーマット例。

【図９】送信者から電子ファイルの受信者向けにMOSSフ
ォーマット化された制御ファイル1を含むMOSSフォーマ
ット化される前の制御ファイル0の実現例(図10へ続
く)。

【図１０】送信者から電子ファイルの受信者向けにMOSS
フォーマット化された制御ファイル1を含むMOSSフォー
マット化される前の制御ファイル0の実現例(図9から続
く)。

【図１１】送信者から転送サーバ、及び電子ファイルの
受信者向けにMOSSフォーマット化された制御ファイル0
の実現例。

【図１２】装置構成の実現例。

【図１３】アップロード処理のフロチャートの実現例。

【図１４】アップロード処理のフロチャートの実現例
（図13の続き）。

【図１５】アップロード処理のフロチャートの実現例
（図14の続き）。

【図１６】アップロード再送信処理のフロチャートの実
現例。

【図１７】アップロード再送信処理のフロチャートの実
現例（図16の続き）。

【図１８】アップロード再送信処理のフロチャートの実
現例（図17の続き）。

【図１９】ダウンロード処理のフロチャートの実現例。

【図２０】ダウンロード処理のフロチャートの実現例
（図19の続き）。

【図２１】ダウンロード処理のフロチャートの実現例
（図20の続き）。

【図２２】ダウンロード処理のフロチャートの実現例
（図21の続き）。

【図２３】ダウンロード再送信処理のフロチャートの実
現例。

【図２４】ダウンロード再送信処理のフロチャートの実
現例（図23の続き）。

【図２５】ダウンロード再送信処理のフロチャートの実
現例（図24の続き）。

【図２６】ダウンロード再送信処理のフロチャートの実
現例（図25の続き）。

【図２７】アップロードトランザクションを管理してい
るテーブルの実現例。

【図２８】制御ファイルを管理しているテーブルの実現
例。

【図２９】ブロックファイルを管理しているテーブルの
実現例。

【図３０】ダウンロードトランザクションを管理してい
るテーブルの実現例。

【図３１】FTPサーバ〜クライアントシステムにおける
電子ファイル送受信の実現例。

【図３２】WWWサーバ〜WWWブラウザシステムにおける電
子ファイル送受信の実現例。

【図３３】WWWブラウザから電子ファイルをWWWサーバに
送信する場合のHTMLファイルの記述例。

【符号の説明】

601：クライアント 603：ファイル選択処理部 604：受信者選択処理部 621：タイマ 605：送信処理部 606：受信処理部 607：リクエスト組立処理部 608：レスポンス解析処理部 609：制御ファイル生成処理部 618：内部メモリ 619：トランザクション制御部 610：制御ファイル解析処理部 611：DEK生成処理部 612：ハッシュ処理部 613：復号処理部 614：暗号処理部 615：公開鍵取得処理部 620：外部記憶装置 616：ブロック処理部 651：転送サーバ 652：送信処理部 653：受信処理部 654：リクエスト解析処理部 655：レスポンス組立処理部 656：制御ファイル解析処理部 657：公開鍵取得処理部 664：トランザクション制御部 663：内部メモリ 658：ハッシュ処理部 659：復号処理部 660：暗号処理部 665：データベース 661：データベース制御処理部 662：ブロック処理部 667：DEK生成処理部 666：外部記憶装置

───────────────────────────────────────────────────── フロントページの続き (72)発明者 山下 豊一郎 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 (72)発明者 高井 敦 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 (72)発明者 石井 茂 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 (72)発明者 須藤 忍 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 (72)発明者 長谷部 潤 東京都新宿区西新宿三丁目19番２号 日本 電信電話株式会社内 Ｆターム(参考） 5B089 GA11 GA21 HA10 HB05 JA32 JB23 KA12 KA17 KC58 KH30 5J104 AA01 AA16 EA02 JA03 PA07 PA14 5K030 GA15 HA08 KA06 LA07 LD11 LE11 LE14 9A001 CC03 DD15 EE03 EE04 JJ13 JJ14 JJ25 JJ27 KK54 KK56 LL03

Claims (8)

【特許請求の範囲】
1. 【請求項１】 ネットワークにおいて、転送サーバを介
   し、送信クライアントから受信クライアントへ電子ファ
   イルを転送するファイル転送システムにおいて、 転送される電子ファイルに関する情報を記述した制御フ
   ァイルを、送信クライアントと受信クライアントとの間
   で転送する転送手段を有することを特徴とするファイル
   転送システム。
2. 【請求項２】 前記制御ファイルにファイルの転送先が
   少なくても１つ以上記載されていることを特徴とする請
   求項１記載のファイル転送システム。
3. 【請求項３】 さらに転送サーバ上にある制御ファイル
   の転送先を送信クライアントによって変更可能とする手
   段を有することを特徴とする請求項１記載のファイル転
   送システム。
4. 【請求項４】 送信クライアントが、 送信するファイルをブロック化する手段と、 暗号化する手段と、 ブロック化した情報を制御ファイルに書きこむ手段を有
   し、 受信クライアントが、 暗号化されたブロックを復号化する手段と、 復号化したブロックを制御ファイルに書きこまれている
   ブロック化した情報をもとにファイルを組み立てる手段
   を有することを特徴とする請求項１記載のファイル転送
   システム。
5. 【請求項５】 送信クライアントから転送サーバにファ
   イルを転送する際に異常があった場合に送信クライアン
   トが未送信のブロック化したファイルのみを送信する手
   段を有することを特徴とする請求項４記載のファイル転
   送システム。
6. 【請求項６】 転送サーバから受信クライアントにファ
   イルを転送する際に異常があった場合に受信クライアン
   トが未受信のブロック化したファイルのみを受信する手
   段を有することを特徴とする請求項４記載のファイル転
   送システム。
7. 【請求項７】 制御ファイルが送信クライアントから受
   信クライアントのみで情報交換を行う部分と、送信クラ
   イアントから受信クライアント間、送信クライアントか
   ら転送サーバ間、転送サーバから受信クライアント間で
   情報交換を行う部分との、２階層で構成されていること
   を特徴とする請求項１〜６のいずれか１項に記載のファ
   イル転送システム。
8. 【請求項８】 前記制御ファイルの送信クライアントか
   ら受信クライアントのみで情報交換を行う部分が受信ク
   ライアントのみで復号化できる暗号で記載されているこ
   とを特徴とする請求項７記載のファイル転送システム。