JP2011193319A - ファイル転送システム、ファイル転送方法 - Google Patents

Abstract

【課題】複数の相手先へファイルを安全に転送しつつ、送信側ユーザと受信側ユーザ双方の負担を低減することのできるファイル転送技術を提供する。
【解決手段】本発明に係るファイル転送システムは、転送対象となるファイルを取得するためのアドレスを記述した電子メールと、その復号化キーを記述した電子メールを、それぞれ異なるメールサーバから送信する。
【選択図】図６

Description

本発明は、電子ファイル（以下、ファイル）を送信元端末から転送先端末に転送する技術に関するものである。

従来、クライアント端末間で機密ファイルを送受信する技術として、送信元端末と送信先端末にそれぞれ暗号化通信路を用意し、その通信路を通して機密ファイルを送受信するものがある。この場合、送信先端末が複数存在するとその数の分だけ暗号化通信路を用意する必要があり、コストや管理作業の点で負担が大きい。また、機密ファイルが送信先端末に確実に到着したか否かを確認する際には、そのための固有のプロトコルなどを使う必要があるが、ファイアウォールなどによってそのプロトコルが遮断され、送信元端末に到着確認パケットが届かない可能性がある。

上記技術のほか、より機密性の高いファイルを送受信する際に、送信先端末でしか復号化することのできない暗号化処理を送信対象ファイルに施すなどの技術がある。

下記特許文献１では、クライアント端末に固有の情報を利用してユーザを認証する技術が記載されている。下記特許文献２では、送信すべき機密データを複数のピースに分割して宅配便やダウンロードなどの複数手段で配送する手法が記載されている。

特開２００３−２４２０４２号公報 特開２００８−１９１９１７号公報

上記特許文献１に記載の技術では、通信路は暗号化されているものの、送信対象となるファイル自体は暗号化されていない。そのため、通信路に接続する過程でユーザを認証することができても、ファイルの機密性を確保する観点からは、必ずしも万全ではない。

上記特許文献２に記載の技術では、送信対象となる機密データを複数のピースに分割して送信するため、送信先では複数のピースを結合するなどの手順が必要となり、ユーザに負担をかけてしまう。

本発明は、上記のような課題を解決するためになされたものであり、複数の相手先へファイルを安全に転送しつつ、送信側ユーザと受信側ユーザ双方の負担を低減することのできるファイル転送技術を提供することを目的とする。

本発明に係るファイル転送システムは、転送対象となるファイルを取得するためのアドレスを記述した電子メールと、その復号化キーを記述した電子メールを、それぞれ異なるメールサーバから送信する。

本発明に係るファイル転送システムによれば、転送対象となるファイルを取得するために必要となる情報を複数のメールサーバから分散的に送信するので、単一のメールサーバからこれら情報を送信する場合と比較して情報漏洩のリスクを低減することができる。また、ファイルを受け取る側ではファイルの結合処理などは必要ないため、格段の負担を要さない。さらには、ファイルを受け取る相手先が複数存在する場合でも、電子メールをそれぞれ２通ずつ配信すれば足りるので、ファイルを転送するために格段の作業負担が生じることもない。

実施の形態１に係るファイル転送システム１０００の構成図である。 送信元クライアント端末４００が転送対象ファイルをファイルサーバ１００にアップロードするまでの通信シーケンスを示す図である。 図２のステップ（１）で送信元クライアント端末４００のユーザが用いるファイルアップロード画面１１０の画面例である。 ファイルアップロード画面１１０上の操作が完了した後に送信元クライアント端末４００上で表示されるアップロード完了通知画面１２０の画面例である。 図２のステップ（３）でファイルサーバ１００が送信元クライアント端末４００のユーザへ送信するアドレス通知メール１３０の１例を示す図である。 転送対象ファイルを取得するためのアドレスと復号化キーなどを、転送先クライアント端末５００のユーザへ通知するための通信シーケンスを示す図である。 図６のステップ（５）で送信元クライアント端末４００のユーザがファイルサーバ１００へ完了通知を発行するために用いる完了通知画面１４０の画面例である。 図６のステップ（６）でファイルサーバ１００が転送先クライアント端末５００のユーザへ送信する復号化キー通知メール１５０の１例を示す図である。 送信元クライアント端末４００が転送対象ファイルをファイルサーバ１００にアップロードするまでの通信シーケンスを示す図である。 図９のステップ（１．１）が完了した後に送信元クライアント端末４００の画面に表示される画面１６０の１例を示す図である。 ステップ（１．３）で送信元クライアント端末４００のユーザが使用するＭＡＣアドレス入力画面１７０の画面例である。

＜実施の形態１＞
図１は、本発明の実施の形態１に係るファイル転送システム１０００の構成図である。ファイル転送システム１０００は、ファイルを送信元端末から転送先端末に転送するシステムであり、ファイルサーバ１００、第１メールサーバ２００、第２メールサーバ３００、送信元クライアント端末４００、転送先クライアント端末５００を有する。

送信元クライアント端末４００は、転送対象となるファイルを送信する端末である。転送先クライアント端末５００は、そのファイルの転送先となる端末である。送信元クライアント端末４００と転送先クライアント端末５００は、例えば一般的なパーソナルコンピュータ（ＰＣ）などで構成することができる。

ファイルサーバ１００は、送信元クライアント端末４００が送信するファイルを保存するサーバコンピュータである。第１メールサーバ２００と第２メールサーバ３００は、後述する電子メールを送受信するサーバコンピュータである。これら各サーバの詳細動作については後述する。

送信元クライアント端末４００のユーザは、ファイル転送システム１０００を利用するに当たり、ファイルサーバ１００上にあらかじめユーザアカウントを作成しておくものとする。ファイルサーバ１００は、送信元クライアント端末４００のユーザにユーザＩＤとパスワードを発行する。以下の説明では、送信元クライアント端末４００のユーザがファイルサーバ１００にログインする過程は省略する。

図２は、送信元クライアント端末４００が転送対象ファイルをファイルサーバ１００にアップロードするまでの通信シーケンスを示す図である。以下、図２の各ステップについて説明する。

（１）アップロード
送信元クライアント端末４００のユーザは、後述の図３で説明するファイルアップロード画面１１０を用いて、転送先クライアント端末５００に転送するファイルをファイルサーバ１００にアップロードする。送信元クライアント端末４００とファイルサーバ１００の間の通信路は、暗号化通信路としてもよい。送信元クライアント端末４００は、ファイルサーバ１００にファイルをアップロードする際に、暗号化キーをファイルサーバ１００へ併せて通知しておく。

（２）暗号化
ファイルサーバ１００は、ステップ（１）で送信元クライアント端末４００から受け取ったファイルを、同時に受け取った暗号化キーを用いて暗号化する。以下では暗号化キーと復号化キーは同じであることを想定するが、それぞれ異なるキーを用いてもよい。暗号化キーと復号化キーが異なる場合は、ステップ（１）において送信元クライアント端末４００は復号化キーも併せて通知するものとする。また、ファイルアップロード画面１１０においてそのための入力欄を設けるものとする。

（３）アドレス通知
ファイルサーバ１００は、ステップ（２）で暗号化したファイルをダウンロード等によってファイルサーバ１００の外部から取得するためのアドレスを、第１電子メールサーバ２００を用いて、電子メールにより送信元クライアント端末４００へ通知する。このアドレスは、例えば当該ファイルに対応付けられた乱数文字列などを用いて生成することができる。

図３は、図２のステップ（１）で送信元クライアント端末４００のユーザが用いるファイルアップロード画面１１０の画面例である。ファイルアップロード画面１１０は、送信元メールアドレス欄１１１、転送先メールアドレス欄１１２、転送対象ファイル欄１１３、暗号化キー欄１１４、ファイルタイトル欄１１５、実行ボタン１１６、取消ボタン１１７を有する。

送信元メールアドレス欄１１１は、送信元クライアント欄末４００のユーザが保持する電子メールアドレスを入力する欄である。転送先メールアドレス欄１１２は、転送先クライアント端末５００のユーザが保持する電子メールアドレスを入力する欄である。転送対象ファイル欄１１３は、転送先クライアント端末５００へ転送するファイルのファイルパスを入力する欄である。暗号化キー欄１１４は、転送対象ファイルをファイルサーバ１００が暗号化する際に用いる暗号化キーを入力する欄である。暗号化キーをファイルサーバ１００に自動生成させることもできる。この場合は、その旨をファイルサーバ１００に指示するためのチェックボックスなどをファイルアップロード画面１１０上に設ければよい。ファイルタイトル欄１１５は、転送対象ファイルを一覧表示する際などに各ファイルの内容をユーザが把握し易くするためのものである。実行ボタン１１６、取消ボタン１１７は、ファイルアップロード画面１１０上の操作を完了し、またはキャンセルするためのボタンである。

図４は、ファイルアップロード画面１１０上の操作が完了した後に送信元クライアント端末４００上で表示されるアップロード完了通知画面１２０の画面例である。アップロード完了通知画面１２０は、ファイルのアップロードが完了した旨とともに、送信元クライアント端末４００のユーザが今後実施すべき事項を通知するためのものである。ユーザが実施すべき事項については後述する。

図５は、図２のステップ（３）でファイルサーバ１００が送信元クライアント端末４００のユーザへ送信するアドレス通知メール１３０の１例を示す図である。ファイルサーバ１００は、ファイルアップロード画面１１０の送信元メールアドレス欄１１１に入力されたアドレスに、図５のようなアドレス通知メール１３０を送信する。ユーザは、アドレス通知メール１３０に記述されているアドレスにアクセスすることにより、アップロードしたファイルを取得することができる。

ただし、図５に示すアドレス通知メール１３０は、転送対象ファイルを受け取るべき転送先クライアント端末５００のユーザへ宛てたものではなく、送信元クライアント端末４００のユーザへ宛てたものである。したがって図２のステップ（３）までの時点では、ファイルを取得するためのアドレスは転送先クライアント端末５００のユーザへ通知されていない。このような手順を踏む理由については、図６以降で改めて説明する。

以上、送信元クライアント端末４００が転送対象ファイルをアップロードするまでの手順を説明した。以下では、転送対象ファイルを取得するためのアドレスと復号化キーなどを、転送先クライアント端末５００のユーザへ通知する手順を説明する。

図６は、転送対象ファイルを取得するためのアドレスと復号化キーなどを、転送先クライアント端末５００のユーザへ通知するための通信シーケンスを示す図である。以下、図６の各ステップについて説明する。

（４）アドレス通知転送
送信元クライアント端末４００のユーザは、第２メールサーバ３００を用いて、図２のステップ（３）でファイルサーバ１００から受け取ったアドレス通知メール１３０を転送先クライアント端末５００のユーザ宛に転送する。本ステップにより、転送先クライアント端末５００のユーザは、転送対象ファイルを取得するためのアドレスを知ることができる。

（４）アドレス通知転送：補足
本ステップでは、ステップ（３）でアドレス通知メール１３０を受信するために用いる第１メールサーバ２００とは異なる第２メールサーバ３００を用いる。第１メールサーバ２００と第２メールサーバ３００を使い分けるためには、図２のステップ（３）でアドレス通知メール１３０を受信するときのメールアカウントと、本ステップでアドレス通知メール１３０を転送するときのメールアカウントを、区別するとよい。

（５）完了通知
送信元クライアント端末４００のユーザは、後述の図７で説明する完了通知画面１４０を用いて、アドレス通知メール１３０を転送先クライアント端末５００のユーザへ転送完了した旨を、ファイルサーバ１００へ通知する。本ステップは、ファイルサーバ１００から転送先クライアント端末５００のユーザへ、転送対象ファイルの復号化パスワードなどを通知すべき旨を指示することを兼ねている。

（６）復号化キー通知
ファイルサーバ１００は、第１メールサーバ２００を用いて、ファイルアップロード画面１１０の転送先メールアドレス欄１１２に入力されたアドレスに、転送対象ファイルを復号化するための復号化キーなどを記述した復号化キー通知メール１５０（後述）を送信する。本ステップにより、転送先クライアント端末５００のユーザは、転送対象ファイルの復号化キーを知ることができる。

（６）復号化キー通知：補足
本ステップは、送信元クライアント端末４００のユーザがステップ（５）でファイルサーバ１００へ完了通知を発行した後に初めて実行される。したがって、送信元クライアント端末４００のユーザが指示しない限り、転送先クライアント端末５００のユーザは、転送対象ファイルの復号化キーなどを知ることができない、ということになる。

図７は、図６のステップ（５）で送信元クライアント端末４００のユーザがファイルサーバ１００へ完了通知を発行するために用いる完了通知画面１４０の画面例である。送信元クライアント端末４００のユーザは、アドレス通知メール１３０を転送先クライアント端末５００のユーザへ転送した後、完了ボタン１４１をクリックする。ファイルサーバ１００はその後、図６のステップ（６）を実行する。

図８は、図６のステップ（６）でファイルサーバ１００が転送先クライアント端末５００のユーザへ送信する復号化キー通知メール１５０の１例を示す図である。復号化キー通知メール１５０には、転送対象ファイルを復号化するための復号化キーが記述されている。また、任意のユーザがファイルサーバ１００へアクセスすることのないよう、ログインＩＤとパスワードを復号化キー通知メール１５０によって通知するものとする。ログインＩＤとパスワードは、転送対象ファイルを取得するためのみに用いることができればよいので、ファイルサーバ１００は例えば有効期限付きの任意のＩＤ／パスワードの組を生成すればよい。

＜実施の形態１：補足＞
図６のステップ（５）において、送信元クライアント端末４００のユーザが、ファイルサーバ１００へ完了通知を発行することを失念し、長時間放置する可能性が考えられる。そこでファイルサーバ１００は、転送対象ファイルを受け取ってから所定時間経過しても完了通知が届かないときは、完了通知を行うよう促す電子メールを送信元クライアント端末４００のユーザへ定期的に送信するようにしてもよい。さらに所定期間経過しても完了通知が届かないときは、転送対象ファイルをいったん破棄するなどしてもよい。

図６のステップ（４）〜（５）において、送信元クライアント端末４００のユーザが、アドレス通知メール１３０を転送先クライアント端末５００のユーザへ転送することなく完了通知を発行する可能性が考えられる。このとき転送先クライアント端末５００のユーザは、復号化キー通知メール１５０のみを突然受け取ることになり、混乱を招く可能性がある。そこで復号化キー通知メール１５０の末尾などに、問い合わせ連絡先（メールアドレス、電話番号など）を記述しておき、転送先クライアント端末５００のユーザが復号化キー通知メール１５０の内容について問い合わせる手段を提供するようにしてもよい。

＜実施の形態１：まとめ＞
以上のように、本実施の形態１によれば、転送先クライアント端末５００が転送対象ファイルを取得するためには、転送対象ファイルを取得するためのアドレスを記述したアドレス通知メール１３０と、復号化キー等を記述した復号化キー通知メール１５０の双方を取得しなければならない。前者は第２メールサーバ３００を介して送信元クライアント端末４００のユーザが送信し、後者は第１メールサーバ２００を介してファイルサーバ１００が送信する。このように、転送対象ファイルを取得するために必要な情報を複数のメールに分けて配信し、かつ各メールの送信者およびメールサーバを分けることにより、双方のメール内容がともに漏洩するリスクを低減し、ファイル転送の安全性を高めることができる。

また、本実施の形態１によれば、ファイルサーバ１００は、送信元クライアント端末４００のユーザから完了通知があって初めて、復号化キー通知メール１５０を転送先クライアント端末５００のユーザに送信する。これにより、送信元クライアント端末４００のユーザが許可することなく転送対象ファイルが復号化される懸念が低減され、情報漏洩リスクを低めることができる。

また、本実施の形態１によれば、転送対象ファイルを複数の転送先クライアント端末５００に転送したい場合は、アドレス通知メール１３０と復号化キー通知メール１５０を転送先クライアント端末５００の数だけ配信すればよい。これにより、転送先クライアント端末５００毎に暗号化通信路を確保するなどの手間のかかる作業が必要なくなり、ユーザの負担を低減することができる。

また、本実施の形態１によれば、転送先クライアント端末５００のユーザは、複数の転送対象ファイルを結合するなどの作業を行う必要はなく、各メールに記載されたアドレスや復号化キーなどを用いるのみでよい。これにより、転送先クライアント端末５００のユーザにかける負担を抑えることができる。

＜実施の形態２＞
実施の形態１では、転送対象ファイルを取得するためのアドレスと、転送対象ファイルの復号化キー等を知ることができれば、任意のクライアント端末が転送対象ファイルを取得することができる。本発明の実施の形態２では、転送対象ファイルを取得することのできるクライアント端末を、各端末のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓ Ｃｏｎｔｒｏｌ）アドレスによって限定する手法について説明する。ファイル転送システム１０００の構成は実施の形態１と同様であるため、以下では差異点を中心に説明する。

図９は、送信元クライアント端末４００が転送対象ファイルをファイルサーバ１００にアップロードするまでの通信シーケンスを示す図である。本実施の形態２では、送信元クライアント端末４００が転送対象ファイルをファイルサーバ１００にアップロードしてから、ファイルサーバ１００が暗号化を開始するまでのステップが、実施の形態１とは異なる。以下、図９の各ステップについて説明する。

（１．１）アップロード
本ステップは、図２のステップ（１）と同様であるが、本ステップの時点では暗号化キーをファイルサーバ１００に通知しない点が、図２のステップ（１）とは異なる。ファイルアップロード画面１１０の構成は、図３と同様でもよいし、図２のステップ（１）とは異なる処理であることを明確にするため、暗号化キー欄１１４を除いた同様の画面を設けてもよい。本ステップを完了した後、送信元クライアント端末４００の画面には、送信元クライアント端末４００のＭＡＣアドレスと転送先クライアントアドレス５００のＭＡＣアドレスを通知するよう促すメッセージが表示される。この画面の例は、後述の図１０で改めて説明する。

（１．２）ＭＡＣアドレス通知
送信元クライアント端末４００のユーザは、転送先クライアント端末５００のユーザに対して、転送先クライアント端末５００のＭＡＣアドレスを通知するよう依頼する。転送先クライアント端末５００のユーザは、例えば第２メールサーバ３００を経由する電子メールを用いて、転送先クライアント端末５００のＭＡＣアドレスを送信元クライアント端末４００のユーザへ通知する。

（１．３）ＭＡＣアドレス通知
送信元クライアント端末４００のユーザは、送信元クライアント端末４００のＭＡＣアドレスと転送先クライアントアドレス５００のＭＡＣアドレスを、後述のＭＡＣアドレス入力画面１７０を用いてファイルサーバ１００へ通知する。

（２）暗号化
ファイルサーバ１００は、送信元クライアント端末４００のＭＡＣアドレスと転送先クライアントアドレス５００のＭＡＣアドレスを用いて暗号化キーを生成し、ステップ（１．１）で受け取った転送対象ファイルを暗号化する。暗号化キーと復号化キーを共通化してもよいし、同様の手法で復号化キーを別途生成してもよい。以後のステップは、実施の形態１と同様である。

図１０は、図９のステップ（１．１）が完了した後に送信元クライアント端末４００の画面に表示される画面１６０の１例を示す図である。実施の形態１と異なり、ステップ（１．１）が完了した時点では、ファイルサーバ１００は転送対象ファイルを暗号化しない。ファイルサーバ１００は各クライアント端末のＭＡＣアドレスを用いて転送対象ファイルを暗号化するので、各クライアント端末のＭＡＣアドレスをファイルサーバ１００へ通知するよう、図１０のような画面によって送信元クライアント端末４００のユーザへ促す必要がある。

図１１は、ステップ（１．３）で送信元クライアント端末４００のユーザが使用するＭＡＣアドレス入力画面１７０の画面例である。ユーザは、送信元ＭＡＣアドレス欄１７１と転送先ＭＡＣアドレス欄１７２に各クライアント端末のＭＡＣアドレスを入力し、実行ボタン１７３をクリックする。操作を取り消すときは取消ボタン１７４をクリックする。

ファイルサーバ１００が用いる暗号化キーの例として、例えば送信元クライアント端末４００のＭＡＣアドレスと転送先クライアントアドレス５００のＭＡＣアドレスを結合した文字列を暗号化キーとすることが考えられる。あるいは、送信元クライアント端末４００のＭＡＣアドレスと転送先クライアントアドレス５００のＭＡＣアドレスから一意のハッシュ値などを生成し、これを暗号化キーとして用いてもよい。復号化キーについても同様である。

本実施の形態２において、転送先クライアント端末５００が複数存在する場合は、その分だけＭＡＣアドレスを取得しなければならないが、暗号化通信路を転送先クライアント端末５００毎に構築するよりは遥かに少ない手間で済む点で有利である。

以上のように、本実施の形態２によれば、ファイルサーバ１００は、送信元クライアント端末４００と転送先クライアント端末５００それぞれに固有の識別情報（ＭＡＣアドレス）を用いて暗号化キー（または復号化キー）を生成する。これにより、第３者が暗号化キーを推測しにくくし、転送対象ファイルの機密性を高めることができる。

＜実施の形態３＞
実施の形態２において、各クライアント端末のＭＡＣアドレスをファイルサーバ１００に通知することを説明したが、各クライアント端末のユーザにとって、端末のＭＡＣアドレスを調べることが難しく感じる場合も考えられる。

この場合、例えば図９のステップ（１．１）を完了する時点で、ファイルサーバ１００から送信元クライアント端末４００に対して、ＭＡＣアドレスを画面表示するための専用ツールを送信するようにしてもよい。送信元クライアント端末４００のユーザは、その専用ツールを実行し、送信元クライアント端末４００のＭＡＣアドレスを知ることができる。同様に、その専用ツールを転送先クライアント端末５００のユーザにも転送し、転送先クライアント端末５００のＭＡＣアドレスを画面表示できるようにしてもよい。

専用ツールを各クライアント端末に送信するには、例えば電子メールの添付ファイルとして送信すればよい。専用ツール自体は機密情報を保持していないので、メールサーバはいずれでもよい。

＜実施の形態４＞
実施の形態２〜３において、ＭＡＣアドレスを各クライアント端末固有の識別情報として取得することを説明したが、その他の情報を各クライアント端末固有の識別情報として用いることもできる。例えば、各クライアント端末にインストールされているオペレーティングシステム（ＯＳ）が固有のＩＤを持つ場合は、ＭＡＣアドレスに代えてそのＩＤを用いることもできる。実施の形態３で説明した専用ツールは、ＯＳのＩＤを取得してユーザに通知するように構成しておけばよい。

＜実施の形態５＞
以上の実施の形態１〜４において、ファイルサーバ１００は、転送対象ファイルがダウンロードされたときに、送信元メールアドレス欄１１１に入力されたアドレスに対して、ダウンロード完了通知を電子メールで送信するようにしてもよい。これにより、送信元クライアント端末４００のユーザは、ファイル転送が完了したことを確実に知ることができる。ファイル転送完了通知自体は機密情報を含まないので、メールサーバはいずれでもよい。

１００：ファイルサーバ、１１０：ファイルアップロード画面、１１１：送信元メールアドレス欄、１１２：転送先メールアドレス欄、１１３：転送対象ファイル欄、１１４：暗号化キー欄、１１５：ファイルタイトル欄、１１６：実行ボタン、１１７：取消ボタン、１２０：アップロード完了通知画面、１３０：アドレス通知メール、１４０：完了通知画面、１５０：復号化キー通知メール、１６０：画面、１７０：ＭＡＣアドレス入力画面、１７１：送信元ＭＡＣアドレス欄、１７２：転送先ＭＡＣアドレス欄、１７３：実行ボタン、１７４：取消ボタン、２００：第１メールサーバ、３００：第２メールサーバ、４００：送信元クライアント端末、５００：転送先クライアント端末、１０００：ファイル転送システム。

Claims (5)

1. 電子ファイルを送信元端末から転送先端末に転送するシステムであって、
   前記電子ファイルを保存するファイルサーバと、
   電子メールを送受信する第１メールサーバおよび第２メールサーバと、
   を有し、
   前記ファイルサーバは、
   前記電子ファイル、暗号化キー、および復号化キーを前記送信元端末から受信して前記電子ファイルを前記暗号化キーによって暗号化し、
   前記第１メールサーバを用いて、前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末に送信し、
   前記復号化キーを前記転送先端末に送信すべき旨の指示を前記送信元端末より受け取ると、前記第１メールサーバを用いて、前記復号化キーを記述した電子メールを前記転送先端末に送信し、
   前記第２メールサーバは、
   前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末から受信し、その電子メールを前記転送先端末に送信する
   ことを特徴とするファイル転送システム。
2. 電子ファイルを送信元端末から転送先端末に転送するシステムであって、
   前記電子ファイルを保存するファイルサーバと、
   電子メールを送受信する第１メールサーバおよび第２メールサーバと、
   を有し、
   前記ファイルサーバは、
   前記電子ファイル、前記送信元端末の識別情報、および前記転送先端末の識別情報を前記送信元端末から受信し、
   前記送信元端末の識別情報と前記転送先端末の識別情報から暗号化キーおよび復号化キーを生成して前記電子ファイルを暗号化し、
   前記第１メールサーバを用いて、前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末に送信し、
   前記復号化キーを前記転送先端末に送信すべき旨の指示を前記送信元端末より受け取ると、前記第１メールサーバを用いて、前記復号化キーを記述した電子メールを前記転送先端末に送信し、
   前記第２メールサーバは、
   前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末から受信し、その電子メールを前記転送先端末に送信する
   ことを特徴とするファイル転送システム。
3. 前記ファイルサーバは、
   前記転送先端末が前記アドレスにアクセスして前記電子ファイルを取得した日時を、前記第１メールサーバまたは前記第２メールサーバを用いて前記送信元端末に電子メールで通知する
   ことを特徴とする請求項１または２記載のファイル転送システム。
4. 電子ファイルを保存するファイルサーバと、
   電子メールを送受信する第１メールサーバおよび第２メールサーバと、
   を有するファイル転送システムにおいて、
   前記電子ファイルを送信元端末から転送先端末に転送する方法であって、
   前記ファイルサーバが、
   前記電子ファイル、暗号化キー、および復号化キーを前記送信元端末から受信して前記電子ファイルを前記暗号化キーによって暗号化するステップと、
   前記ファイルサーバが、
   前記第１メールサーバを用いて、前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末に送信するステップと、
   前記第２メールサーバが、
   前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末から受信し、その電子メールを前記転送先端末に送信するステップと、
   前記ファイルサーバが、
   前記復号化キーを前記転送先端末に送信すべき旨の指示を前記送信元端末より受け取るステップと、
   前記ファイルサーバが、
   前記第１メールサーバを用いて、前記復号化キーを記述した電子メールを前記転送先端末に送信するステップと、
   を有することを特徴とするファイル転送方法。
5. 電子ファイルを保存するファイルサーバと、
   電子メールを送受信する第１メールサーバおよび第２メールサーバと、
   を有するファイル転送システムにおいて、
   前記電子ファイルを送信元端末から転送先端末に転送する方法であって、
   前記ファイルサーバが、
   前記電子ファイル、前記送信元端末の識別情報、および前記転送先端末の識別情報を前記送信元端末から受信するステップと、
   前記ファイルサーバが、
   前記送信元端末の識別情報と前記転送先端末の識別情報から暗号化キーおよび復号化キーを生成して前記電子ファイルを暗号化するステップと、
   前記ファイルサーバが、
   前記第１メールサーバを用いて、前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末に送信するステップと、
   前記第２メールサーバが、
   前記電子ファイルを取得するためにアクセスすべきアドレスを記述した電子メールを前記送信元端末から受信し、その電子メールを前記転送先端末に送信するステップと、
   前記ファイルサーバが、
   前記復号化キーを前記転送先端末に送信すべき旨の指示を前記送信元端末より受け取るステップと、
   前記ファイルサーバが、
   前記第１メールサーバを用いて、前記復号化キーを記述した電子メールを前記転送先端末に送信するステップと、
   を有することを特徴とするファイル転送方法。

Images