ファイル交換システム、ファイル交換サーバ、およびファイル交換プログラム
【課題】専用のユーザＩＤ等を有さない相手方に対してファイル交換サービスによってセキュアにファイルを転送する際に、送信側ユーザが通常の電子メールクライアントを利用して添付ファイルとして送信することを可能とする。
【解決手段】ファイル交換サーバ２０は、受信側ユーザの電子メールアドレスと、受信側ユーザが設定したパスワードに係る情報とを保管しており、添付ファイル４３を有する第１の電子メールを受け取った際に、添付ファイル４３を保管するとともにダウンロードするためのＵＲＬ４５を生成して添付ファイル４３とＵＲＬ４５とを保管し、さらにメール本文４１とＵＲＬ４５とを含む第２の電子メールを受信側ユーザに対して送信し、第２の電子メールを受信した受信側ユーザがＵＲＬ４５に基づいてアクセスしてきた際に、パスワード４６を入力させて認証を行ったうえで添付ファイル４３のダウンロードを可能とする。
【解決手段】ファイル交換サーバ２０は、受信側ユーザの電子メールアドレスと、受信側ユーザが設定したパスワードに係る情報とを保管しており、添付ファイル４３を有する第１の電子メールを受け取った際に、添付ファイル４３を保管するとともにダウンロードするためのＵＲＬ４５を生成して添付ファイル４３とＵＲＬ４５とを保管し、さらにメール本文４１とＵＲＬ４５とを含む第２の電子メールを受信側ユーザに対して送信し、第２の電子メールを受信した受信側ユーザがＵＲＬ４５に基づいてアクセスしてきた際に、パスワード４６を入力させて認証を行ったうえで添付ファイル４３のダウンロードを可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してファイルを転送する技術に関し、特に、インターネットを介してセキュアにファイルの送受信を行うファイル交換システム、ファイル交換サーバ、およびファイル交換プログラムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
近年では、ＩＴ技術の発展に伴い、インターネットを始めとするネットワークを介した情報の授受によりコミュニケーションを行うことが一般化しており、特にビジネス環境では不可欠となっている。インターネットを介した情報の授受では、電子メールが一般的に用いられているが、授受される情報量がますます増大する中、電子メールの添付ファイルも大容量化する傾向にあり、電子メールシステムにおける添付ファイルサイズの制限によって送受信できないという状況も多く発生している。
【０００３】
これに対し、電子メールでは送受信できないような大容量のファイルをインターネットを介してセキュアに送受信するための各種のファイル交換サービスも提供されている。このようなシステムでは、一般的にユーザインタフェースとしてはＷｅｂブラウザが用いられ、送信側ユーザは対象のファイルをＷｅｂブラウザを利用して所定のサーバにアップロードするとともに、受信側ユーザはＷｅｂブラウザを利用して所定のサーバから対象のファイルをダウンロードする。送信側ユーザによってファイルがアップロードされた旨は、電子メールによって受信側ユーザに通知される。
【０００４】
このとき、通常はファイル交換サービスを利用するユーザはあらかじめユーザ登録を行って電子メールアドレス等を登録してユーザＩＤの発行を受け、当該ユーザＩＤおよびパスワード等による認証を経て所定のサーバにアクセスする（ファイルをアップロード／ダウンロードする）ことで、セキュアにファイルを交換するのが一般的である。
【０００５】
また、受信側ユーザによる事前のユーザ登録を要さずに、受信側ユーザに対してファイルのダウンロード用ＷｅｂサイトのＵＲＬ（Uniform Resource Locator）とワンタイムパスワード（もしくはパスワードのヒント等）等を電子メールにより通知し、受信側ユーザがサーバへアクセスする際に、通知されたワンタイムパスワード等により認証を行ってからファイルをダウンロード可能とする場合もある。これにより、誤った宛先に送信してしまった場合でも、相手方によりファイルが参照されることを防止することができる。
【０００６】
これに関連する技術として、例えば、特開２００９−１８７３８２号公報（特許文献１）には以下のような技術が記載されている。すなわち、ホストクライアントが、ファイル送信依頼をゲストユーザに対して送信する場合に、返信先アドレスと、当該ゲストユーザのメールアドレスと、ホストクライアントから受け付けた添付ファイルとをそれぞれファイル送信依頼に含めて転送サーバに送信し、転送サーバが、ファイル送信依頼によるファイル送信の依頼先がゲストユーザであるか否かを判定し、依頼先がゲストユーザであると判定した場合に、受信したファイル送信依頼をゲストサーバまで転送する。
【０００７】
さらにゲストサーバが、返信用ＵＲＬおよび返信用パスワードと、添付ファイル取得用パスワードを含めた依頼到着通知メールをゲストユーザのメールアドレスに送信し、その後、添付ファイル取得用パスワードをゲストユーザから受け付けた場合に、添付ファイルをゲストユーザに転送し、返信用ＵＲＬおよび返信用パスワードをゲストユーザから受け付けた場合に、同時に受け付けた返信ファイルをファイル送信依頼に含まれていた返信アドレスに転送することで、ファイル交換用の専用アドレスが付与されていないユーザとの間でもファイル交換を可能にする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−１８７３８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
セキュアなファイル交換サービスにおいて、従来技術では、送信側ユーザは、Ｗｅｂブラウザもしくは専用のクライアントプログラムを利用して、送信するファイルをサーバにアップロードするとともに、ダウンロード用のパスワードや返信先等の情報を指定する一方、受信側ユーザは、ファイルが送信（アップロード）された旨の通知を電子メールで受け取り、Ｗｅｂブラウザを利用してサーバにアクセスして当該ファイルをダウンロードする手順となるのが一般的である。
【００１０】
ここで、送信側ユーザにとっては、ファイルを相手方に送信するにあたり、電子メールの添付ファイルとして送信するか、ファイル交換サービスを利用して送信するかを判断して使い分けるのは非効率であり、共通のファイルの送信方法として、ビジネス上のコミュニケーションツールとして通常利用している電子メールクライアントを利用して、添付ファイルとしてファイル交換を行えるのが望ましい。これに対しては、電子メールでの添付ファイルの送信とファイル交換サービスとを連携させ、送信側ユーザは電子メールでの添付ファイルという統一されたインタフェースによってファイルを送信する一方、受信側ユーザはファイル交換サービスを介してセキュアにファイルを受信するという仕組みをとることが考えられる。
【００１１】
しかしながら、電子メールクライアントでは、インタフェースとして電子メールの本文と添付ファイルを指定できるのみであり、Ｗｅｂブラウザを利用する場合のようにアプリケーションによってユーザインタフェースを実装することができない。すなわち、ファイルの送信に際して入力フィールド等のユーザインタフェースを介して各種情報や条件等を送信側ユーザに入力させることは困難である。従って、特に、新規の相手方に対してファイルを転送する場合等、受信側ユーザがファイル交換サービスにユーザ登録されておらずユーザＩＤを有していないような場合では、従来技術では、送信側ユーザがファイルの送信に際して例えばダウンロード用のパスワード等の情報を指定する必要があるため、実装に際しては何らかの仕組みが必要となる。
【００１２】
そこで本発明の目的は、専用のユーザＩＤ等を有さない相手方に対してファイル交換サービスによってセキュアにファイルを転送する際に、送信側ユーザが通常の電子メールクライアントを利用して添付ファイルとして送信することを可能とするファイル交換システム、ファイル交換サーバ、およびファイル交換プログラムを提供することにある。
【００１３】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１４】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１５】
本発明の代表的な実施の形態によるファイル交換システムは、ネットワークを介して通信可能な、送信側ユーザの情報処理端末上で稼働する送信側メールクライアントと、ファイル交換サーバと、受信側ユーザの情報処理端末上で稼働する受信側メールクライアントおよび受信側Ｗｅｂブラウザとからなり、前記送信側ユーザから前記受信側ユーザに対して前記ネットワークを介してファイルを転送するファイル交換システムであって、以下の特徴を有するものである。
【００１６】
すなわち、前記ファイル交換サーバは、前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、前記送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信する。
【００１７】
さらに、前記第２の電子メールを前記受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするものである。
【００１８】
また、本発明は、コンピュータを前記ファイル交換サーバとして機能させるプログラムにも適用することができる。
【発明の効果】
【００１９】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００２０】
本発明の代表的な実施の形態によれば、専用のユーザＩＤ等を有さない相手方に対してファイル交換サービスによってセキュアにファイルを転送する際に、送信側ユーザが通常の電子メールクライアントを利用して添付ファイルとして送信することが可能となる。また、専用のユーザＩＤ等を有さない受信側ユーザがパスワード等の認証情報を独自に設定することが可能となり、受信側ユーザの利便性を向上させることができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施の形態におけるファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。
【図２】本発明の一実施の形態におけるファイル交換サーバでの添付ファイルの保管処理の流れの例について示したフローチャートである。
【図３】本発明の一実施の形態におけるファイル交換サーバからの添付ファイルの受信処理の流れの例について示したフローチャートである。
【図４】従来技術のファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【００２３】
＜概要＞
図４は、従来技術のファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。ここでは、受信側ユーザがファイル交換サービスの専用のユーザＩＤ等を有していない場合の処理の流れを示している。図４において、ファイル交換システム１は、送信側ユーザの情報処理端末上で稼働する送信側Ｗｅｂブラウザ１１と、ファイル交換処理を行うファイル交換サーバ２０と、受信側ユーザの情報処理端末上で稼働する受信側メールクライアント３０、および受信側Ｗｅｂブラウザ３１からなる。
【００２４】
送信側ユーザは、送信側Ｗｅｂブラウザ１１を利用して、例えばファイル交換サーバ２０上で稼働するＷｅｂアプリケーションにアクセスし、送信ファイル４４、および宛先となる受信側ユーザの電子メールアドレスを指定してファイル交換サーバ２０にアップロードする。このとき、関連する内容の文章（電子メールの本文に相当）からなるメッセージ４２を指定することができる。また、受信側ユーザに対する説明用の簡単なコメント等を指定することもできる。また、受信側ユーザがファイル交換サーバ２０にアクセスして送信ファイル４４をダウンロードする際の認証用のワンタイムパスワード４７を指定する。ワンタイムパスワード４７は、例えば送信側ユーザが独自に作成した文字列等からなる。
【００２５】
ファイル交換サーバ２０では、送信ファイル４４をデータベース等に保管するとともに、送信ファイル４４をダウンロードするためのＵＲＬ４５を生成し、ＵＲＬ４５および受信側ユーザに対する説明用の簡単なコメントを含む電子メールを受信側ユーザの電子メールアドレス宛に送信することで、受信側ユーザに対してファイルが送信されている旨を通知する。このＵＲＬ４５は、ファイル交換の都度異なるＵＲＬとなるようにファイル交換サーバ２０がランダムにアクセストークンを生成する等の公知技術を利用して生成するのが望ましい。
【００２６】
受信側ユーザは、受信側メールクライアント３０によってファイルが送信されている旨の電子メールを受信すると、当該電子メールに含まれているＵＲＬ４５に基づいて、受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスし、送信ファイル４４およびメッセージ４２をダンロードして取得する。
【００２７】
このとき、送信側ユーザが送信時に指定したワンタイムパスワード４７を指定することによって、ダウンロードを許可するための認証を行う。なお、このワンタイムパスワード４７は、予め電話等の別の手段にて送信側ユーザから受信側ユーザに伝えておくか、ファイルが送信された旨を通知する電子メールに含まれる簡単なコメントにおいて、ワンタイムパスワード４７のヒントとなる情報（例えば送信側ユーザと受信側ユーザのみが共有する情報に基づくもの）を指定する等により、間接的に受信側ユーザに対して伝えておく。
【００２８】
このように、ファイルが送信された旨の電子メールによる通知と、送信ファイル４４およびメッセージ４２の内容についてのダウンロードを分離し、かつダウンロード時に正しい受信側ユーザのみが知り得るワンタイムパスワード４７による認証を要求する。これにより、万一誤った相手方にファイルが送信された旨の電子メールが誤送信された場合であっても、送信ファイル４４およびメッセージ４２の内容が参照されてしまうことを防ぎ、セキュアなファイル交換を実現することができる。
【００２９】
このようなファイル交換サービスの仕組みにおいて、送信側ユーザがＷｅｂブラウザではなく通常業務等で使用している一般的な電子メールクライアントを使用して添付ファイルとして送信可能とすることでインタフェースを共通化して効率化を図ることを考えた場合、送信側ユーザが電子メールクライアントを利用して図４の例に示すようにワンタイムパスワード４７を指定することは困難である。
【００３０】
そこで、本発明の一実施の形態であるファイル交換システムは、受信側ユーザがファイルをダウンロードする際の認証用のパスワードを、送信側ユーザとは関わりなく受信側ユーザが独自に設定できるようにすることで、送信側ユーザが送信時にワンタイムパスワード４７を指定することを不要とする。これにより、送信側ユーザは、通常使用している電子メールクライアントを利用して、電子メールの本文と添付ファイルの形式でファイルを送信することを可能とするものである。
【００３１】
＜電子メールとファイル交換サービスとの連携＞
図１は、本発明の一実施の形態であるファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。上述した図４の例と同様に、受信側ユーザがファイル交換サービスの専用のユーザＩＤ等を有していない場合の処理の流れを示している。
【００３２】
図１において、ファイル交換システム１は、図４の例と異なり、送信側ユーザのインタフェースが送信側Ｗｅｂブラウザ１１から送信側メールクライアント１０に代わっている。また、送信側メールクライアント１０によって作成された電子メールが送信されるメールサーバ５０、およびメールサーバ間で電子メールを中継するサーバ機器であるメールゲートウェイ５１を有している。メールサーバ５０およびメールゲートウェイ５１は、例えば送信側ユーザが属する企業等に設置されて管理される。また、ファイル交換サーバ２０は、メールサーバの機能を有しており、メールゲートウェイ５１を介してメールサーバ５０から電子メールの転送を受けることができる。
【００３３】
送信側ユーザは、送信側メールクライアント１０を利用して、メール本文４１および送信対象のファイルである添付ファイル４３からなる電子メールを作成して受信側ユーザの電子メールアドレスに対して送信する。当該電子メールを受け取ったメールサーバ５０は、メールゲートウェイ５１に当該電子メールを転送し、メールゲートウェイ５１は、予め設定されたルールに従って電子メールを振り分ける。
【００３４】
すなわち、ファイル交換に係る電子メールであると判断されるものについてはファイル交換サーバ２０宛に転送し、そうでないと判断されるものについては通常の電子メールとして受信側ユーザの電子メールアドレス宛にそのまま転送する。電子メールの振り分けのルールとしては、例えば、添付ファイルの有無や件名などによって判断することが可能である。これらのルールに従って送信先を振り分ける機能は、一般的なメールゲートウェイが通常有する機能を利用することができる。
【００３５】
なお、図１の例では、ファイル交換サーバ２０と、メールサーバ５０やメールゲートウェイ５１とを独立した機器としているが、これらのうちの少なくとも２つ以上を同一の機器上で実装してもよい。また、例えば、ファイル交換に係る電子メールであるか否かに関わらず全ての電子メールについてファイル交換サーバ２０を経由して処理するものとするような場合は、メールゲートウェイ５１における電子メールの振り分け処理も不要である。
【００３６】
電子メールが振り分けられたファイル交換サーバ２０では、上述した図４の例と同様に、添付ファイル４３をデータベース等に保管するとともに、添付ファイル４３をダウンロードするためのＵＲＬ４５を生成し、メール本文４１にＵＲＬ４５を追加した内容の電子メールを受信側ユーザの電子メールアドレス宛に送信することで、受信側ユーザに対してファイルが送信されている旨を通知する。
【００３７】
受信側ユーザは、受信側メールクライアント３０によってファイルが送信されている旨の電子メールを受信すると、当該電子メールに含まれているＵＲＬ４５に基づいて、受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスし、添付ファイル４３をダンロードして取得する。
【００３８】
このとき、受信側ユーザが独自に設定しているパスワード４６を指定することによって、ファイル交換サーバ２０においてダウンロードのための認証を行う。これにより、送信側ユーザはファイルの送信時にパスワード等を指定することが不要となるため、通常使用している電子メールクライアントを利用して、電子メールの本文と添付ファイルの形式でファイルを送信することが可能となる。
【００３９】
＜処理の流れ（添付ファイル保管）＞
以下では、ファイル交換サーバ２０がメールゲートウェイ５１を介して添付ファイル４３を有する電子メールを受け取り、添付ファイル４３を保管する際の処理の流れについて説明する。図２は、ファイル交換サーバ２０での添付ファイル４３の保管処理の流れの例について示したフローチャートである。
【００４０】
ファイル交換サーバ２０は、メールサーバ５０およびメールゲートウェイ５１を介して送信側メールクライアント１０から添付ファイル４３を有する電子メールを受け取ると、まず、当該電子メールの送信先（受信側ユーザ）にとって当該ファイル交換システム１を介したファイルの受信が初めてか否かを判定する（Ｓ０１）。ここでは例えば、ファイル交換サーバ２０が有する後述する暗号鍵ＤＢ２２に、受信側ユーザの電子メールアドレスに対応するレコードが存在するか否かによって判定する。
【００４１】
暗号鍵ＤＢ２２に受信側ユーザの電子メールアドレスに対応するレコードが存在しない場合は、当該受信側ユーザにとって初回の受信であると判定し、ファイル交換サーバ２０は、当該受信側ユーザについて、秘密鍵と公開鍵からなる鍵ペアを生成する（Ｓ０２）。ここでは、ＰＫＩ（Public Key Infrastructure：公開鍵基盤）を利用した一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。生成した鍵ペアのうち、公開鍵については、暗号鍵を保持・管理するデータベースである暗号鍵ＤＢ２２に、受信側ユーザの電子メールアドレスと対応付けて新たなレコードとして格納する。
【００４２】
次に、ファイル交換サーバ２０は、当該受信側ユーザに対して初期パスワードを発行する（Ｓ０３）。初期パスワードは、例えば、ランダムに生成した十分な長さの文字列とする。生成した初期パスワードは、ハッシュ化してＡＥＳ（Advanced Encryption Standard）による暗号化の際の暗号鍵として利用可能な１２８ビット〜２５６ビットのデータとして、暗号鍵ＤＢ２２の受信側ユーザのレコードに追加して格納する。その後、生成した初期パスワードを通知する電子メールを、受信側ユーザの電子メールアドレスに対して送信する（Ｓ０４）。
【００４３】
次に、ファイル交換サーバ２０は、ステップＳ０２で生成した秘密鍵をステップＳ０３で生成した初期パスワードによって暗号化する（Ｓ０５）。ここでは例えば、初期パスワードをハッシュ化したもの（ステップＳ０３にて暗号鍵ＤＢ２２に格納したもの）を暗号鍵としてＡＥＳによって秘密鍵を暗号化する。ＡＥＳによる暗号化については、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。暗号化した秘密鍵は、暗号鍵ＤＢ２２の受信側ユーザのレコードに追加して格納する。なお、元の暗号化されていない秘密鍵のデータは第三者に取得されないよう破棄する。
【００４４】
一方、ステップＳ０１で受信側ユーザにとってファイルの受信が初回ではない場合、すなわち、暗号鍵ＤＢ２２に受信側ユーザの電子メールアドレスに対応するレコードが存在する場合は、当該レコードから受信側ユーザに対応する公開鍵を取得する（Ｓ０６）。
【００４５】
上述の処理によって受信側ユーザに対応する公開鍵を生成もしくは取得すると、次に、ファイル交換サーバ２０は、送信側メールクライアント１０から受け取った添付ファイル４３を暗号化するための共通鍵を生成する（Ｓ０７）。当該共通鍵の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。
【００４６】
次に、ファイル交換サーバ２０は、送信側メールクライアント１０から受け取った添付ファイル４３をステップＳ０７で生成した共通鍵によって暗号化する（Ｓ０８）。ここでは、送信側メールクライアント１０から受け取った電子メールから添付ファイル４３を分離し、これをステップＳ０７で生成した共通鍵を暗号鍵としてＡＥＳによって暗号化する。暗号化した添付ファイル４３は、添付ファイルを保持・管理するデータベースであるファイルＤＢ２１に、受信側ユーザの電子メールアドレスと対応付けて格納する。
【００４７】
さらに、添付ファイル４３をダウンロードするためのＵＲＬ４５を生成して、当該添付ファイル４３のレコードに追加して格納する（Ｓ０９）。ＵＲＬ４５は、上述したように、ファイル交換の都度異なるＵＲＬとなるようにランダムにアクセストークンを生成する等の公知技術を利用して生成する。その後、送信側ユーザからの電子メールの本文および添付ファイル４３をダウンロードするためのＵＲＬ４５の情報を通知する電子メールを、受信側ユーザの電子メールアドレスに対して送信する（Ｓ１０）。
【００４８】
次に、ファイル交換サーバ２０は、ステップＳ０７で生成した共通鍵をステップＳ０２で生成した公開鍵もしくはステップＳ０６で取得した公開鍵によって暗号化する（Ｓ１１）。ここでは、例えば公開鍵によるＲＳＡ（Rivest Shamir Adleman）暗号化などを利用することができる。ＲＳＡによる暗号化についても、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。暗号化した共通鍵は、暗号鍵ＤＢ２２の受信側ユーザのレコードに追加して格納する。なお、元の暗号化されていない共通鍵のデータは第三者に取得されないよう破棄する。
【００４９】
以上のように、ファイル交換サーバ２０において、受信側ユーザが添付ファイル４３をダウンロードする際に使用するパスワードおよび添付ファイル４３の暗号化／復号化のための暗号鍵を生成し、これらを電子メールアドレスに対応付けて管理する。これにより、送信側ユーザによるファイルの送信時におけるパスワード等の指定を不要とすることができる。なお、上記の処理の流れは一例であり、処理順序は可能な範囲で適宜前後させることが可能である。
【００５０】
＜処理の流れ（添付ファイル受信）＞
以下では、受信側ユーザがファイル交換サーバ２０を介して送信側ユーザからのファイルを送信する旨の電子メールを受信し、これに基づいてファイル交換サーバ２０から添付ファイル４３を受信する際の処理の流れについて説明する。図３は、ファイル交換サーバ２０からの添付ファイル４３の受信処理の流れの例について示したフローチャートである。
【００５１】
送信側ユーザからのファイルを送信する旨の電子メールを受信した受信側ユーザは、本文の内容を確認し、当該電子メールに含まれている添付ファイル４３のダウンロード用のＵＲＬ４５に基づいて、受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスすることで、添付ファイル４３の受信処理を開始する。
【００５２】
受信処理を開始すると、ファイル交換サーバ２０は、まず、当該受信側ユーザにとって当該ファイル交換システム１を介したファイルの受信が初めてか否かを判定する（Ｓ２１）。ここでは例えば、受信側ユーザが受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスしてきたときのＵＲＬ４５の内容に基づいて、ファイルＤＢ２１を参照して対象となる添付ファイル４３および受信側ユーザの電子メールアドレスを特定する。さらに、特定した電子メールアドレスに基づいて暗号鍵ＤＢ２２における当該受信側ユーザのレコードを参照することで初回受信か否かを判定する。初回受信か否かについては、例えば、これを示すフラグを暗号鍵ＤＢ２２に設ける等によって判定することができる。
【００５３】
受信側ユーザにとって初回受信である場合は、ファイル交換サーバ２０は、受信側Ｗｅｂブラウザ３１を介して受信側ユーザに対して初期パスワードおよび新パスワードの入力を要求し、これに対して受信側ユーザは初期パスワードおよび新パスワードを入力してパスワードを更新する（Ｓ２２）。このとき、入力された初期パスワードが暗号鍵ＤＢ２２における受信側ユーザの初期パスワードと一致しない場合はファイルの受信処理を終了し、一致する場合には暗号鍵ＤＢ２２の該当の初期パスワードを入力された新パスワード（ハッシュ化したもの）によって更新する。
【００５４】
次に、ファイル交換サーバ２０は、暗号鍵ＤＢ２２の当該受信側ユーザのレコードから暗号化された秘密鍵を取得し、これをステップＳ２２にて入力された初期パスワードを利用して復号化する（Ｓ２３）。ここでは、秘密鍵は図１のステップＳ０５においてＡＥＳによって暗号化されているため、初期パスワードをハッシュ化したものを復号鍵としてＡＥＳによって復号化する。
【００５５】
さらに、復号化した秘密鍵をステップＳ２２にて入力された新パスワードによって暗号化する（Ｓ２４）。ここでは、図１のステップＳ０５と同様に、新パスワードをハッシュ化したもの（ステップＳ２２にて暗号鍵ＤＢ２２に格納したもの）を暗号鍵としてＡＥＳによって秘密鍵を暗号化する。また、暗号化した秘密鍵によって、暗号鍵ＤＢ２２の受信側ユーザのレコードの内容を上書きして更新する。その後、パスワードが変更された旨を通知する電子メールを、受信側ユーザに対して送信する（Ｓ２５）。
【００５６】
一方、ステップＳ２１で受信側ユーザにとって初回受信ではない場合は、ファイル交換サーバ２０は、受信側Ｗｅｂブラウザ３１を介して受信側ユーザに対してパスワードの入力を要求し、これに対して受信側ユーザはパスワード（原則として以前に自身がステップＳ２２において新パスワードとして指定したもの）を入力する（Ｓ２６）。入力されたパスワードが暗号鍵ＤＢ２２における受信側ユーザのパスワードと一致しない場合はファイルの受信処理を終了する。
【００５７】
パスワードが一致する場合には暗号鍵ＤＢ２２の当該受信側ユーザのレコードから暗号化された秘密鍵を取得し、これをステップＳ２６にて入力されたパスワードを利用して復号化する（Ｓ２７）。ここでは、ステップＳ２４と同様に、秘密鍵は図１のステップＳ０５においてＡＥＳによって暗号化されているため、パスワードをハッシュ化したもの（ステップＳ２２にて暗号鍵ＤＢ２２に格納したもの）を復号鍵としてＡＥＳによって復号化する。
【００５８】
上述の処理によって受信側ユーザに対応する秘密鍵を取得すると、次に、ファイル交換サーバ２０は、暗号鍵ＤＢ２２から対象の添付ファイル４３の復号化に用いる共通鍵（すなわち暗号化に用いられた共通鍵）を取得してこれを復号化する（Ｓ２８）。ここでは、当該共通鍵は、図２のステップＳ１１において受信側ユーザに対応する公開鍵を暗号鍵としてＲＳＡによって暗号化されているため、対応する秘密鍵によってこれを復号化することができる。
【００５９】
次に、ファイル交換サーバ２０は、ファイルＤＢ２１に格納された対象の添付ファイル４３を取得し、これをステップＳ２８で取得した共通鍵を利用して復号化する（Ｓ２９）。ここでは、添付ファイル４３は、図２のステップＳ０８においてＡＥＳによって暗号化されているため、共通鍵を復号鍵としてＡＥＳによって復号化する。その後、復号化した添付ファイル４３を、受信側Ｗｅｂブラウザ３１を介して受信側ユーザによってダウンロード可能とすることで、受信側ユーザは添付ファイル４３をダウンロードして取得する（Ｓ３０）。
【００６０】
以上のように、受信側ユーザは、ファイル交換サービスの専用のユーザＩＤ等を有していない場合であっても、自身が設定したパスワードによってセキュアに添付ファイル４３を取得することができる。なお、上記の処理の流れは一例であり、処理順序は可能な範囲で適宜前後させることが可能である。
【００６１】
なお、受信側ユーザがパスワードを紛失した場合など、パスワードをクリアしたい場合には、例えば、受信側Ｗｅｂブラウザ３１を介してファイル交換サーバ２０に対してパスワードクリアの要求を行う。このとき、ファイル交換サーバ２０は、暗号鍵ＤＢ２２における当該受信側ユーザのレコードを削除するとともに、図２のステップＳ０２〜Ｓ０５と同様の処理を行って、当該受信側ユーザに対応する公開鍵と秘密鍵、およびパスワードを新たに生成する。その後、受信側ユーザは、送信側ユーザに対して添付ファイル４３を含む電子メールの再送を依頼することで添付ファイル４３を受信することができる。
【００６２】
以上に説明したように、本発明の一実施の形態であるファイル交換システム１によれば、受信側ユーザが添付ファイル４３をダウンロードする際の認証用のパスワードを、ファイル交換サーバ２０が生成して発行し、送信側ユーザとは関わりなく受信側ユーザが独自に設定できるようにすることで、送信側ユーザが送信時にワンタイムパスワード等のダウンロードに係る情報や条件を指定することが不要となる。これにより、送信側ユーザは、通常使用している電子メールクライアントを利用して、電子メールの本文と添付ファイルの形式でファイルを送信することが可能となる。また、専用のユーザＩＤ等を有さない受信側ユーザであってもパスワード等の認証情報を独自に設定することが可能となり、受信側ユーザの利便性を向上させることができる。
【００６３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００６４】
本発明は、インターネットを介してセキュアにファイルの送受信を行うファイル交換システム、ファイル交換サーバ、およびファイル交換プログラムに利用可能である。
【符号の説明】
【００６５】
１…ファイル交換システム、
１０…送信側メールクライアント、
２０…ファイル交換サーバ、
３０…受信側メールクライアント、３１…受信側Ｗｅｂブラウザ、
４１…メール本文、４２…メッセージ、４３…添付ファイル、４４…送信ファイル、４５…ＵＲＬ、４６…パスワード、４７…ワンタイムパスワード、
５０…メールサーバ、５１…メールゲートウェイ。
【技術分野】
【０００１】
本発明は、ネットワークを介してファイルを転送する技術に関し、特に、インターネットを介してセキュアにファイルの送受信を行うファイル交換システム、ファイル交換サーバ、およびファイル交換プログラムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
近年では、ＩＴ技術の発展に伴い、インターネットを始めとするネットワークを介した情報の授受によりコミュニケーションを行うことが一般化しており、特にビジネス環境では不可欠となっている。インターネットを介した情報の授受では、電子メールが一般的に用いられているが、授受される情報量がますます増大する中、電子メールの添付ファイルも大容量化する傾向にあり、電子メールシステムにおける添付ファイルサイズの制限によって送受信できないという状況も多く発生している。
【０００３】
これに対し、電子メールでは送受信できないような大容量のファイルをインターネットを介してセキュアに送受信するための各種のファイル交換サービスも提供されている。このようなシステムでは、一般的にユーザインタフェースとしてはＷｅｂブラウザが用いられ、送信側ユーザは対象のファイルをＷｅｂブラウザを利用して所定のサーバにアップロードするとともに、受信側ユーザはＷｅｂブラウザを利用して所定のサーバから対象のファイルをダウンロードする。送信側ユーザによってファイルがアップロードされた旨は、電子メールによって受信側ユーザに通知される。
【０００４】
このとき、通常はファイル交換サービスを利用するユーザはあらかじめユーザ登録を行って電子メールアドレス等を登録してユーザＩＤの発行を受け、当該ユーザＩＤおよびパスワード等による認証を経て所定のサーバにアクセスする（ファイルをアップロード／ダウンロードする）ことで、セキュアにファイルを交換するのが一般的である。
【０００５】
また、受信側ユーザによる事前のユーザ登録を要さずに、受信側ユーザに対してファイルのダウンロード用ＷｅｂサイトのＵＲＬ（Uniform Resource Locator）とワンタイムパスワード（もしくはパスワードのヒント等）等を電子メールにより通知し、受信側ユーザがサーバへアクセスする際に、通知されたワンタイムパスワード等により認証を行ってからファイルをダウンロード可能とする場合もある。これにより、誤った宛先に送信してしまった場合でも、相手方によりファイルが参照されることを防止することができる。
【０００６】
これに関連する技術として、例えば、特開２００９−１８７３８２号公報（特許文献１）には以下のような技術が記載されている。すなわち、ホストクライアントが、ファイル送信依頼をゲストユーザに対して送信する場合に、返信先アドレスと、当該ゲストユーザのメールアドレスと、ホストクライアントから受け付けた添付ファイルとをそれぞれファイル送信依頼に含めて転送サーバに送信し、転送サーバが、ファイル送信依頼によるファイル送信の依頼先がゲストユーザであるか否かを判定し、依頼先がゲストユーザであると判定した場合に、受信したファイル送信依頼をゲストサーバまで転送する。
【０００７】
さらにゲストサーバが、返信用ＵＲＬおよび返信用パスワードと、添付ファイル取得用パスワードを含めた依頼到着通知メールをゲストユーザのメールアドレスに送信し、その後、添付ファイル取得用パスワードをゲストユーザから受け付けた場合に、添付ファイルをゲストユーザに転送し、返信用ＵＲＬおよび返信用パスワードをゲストユーザから受け付けた場合に、同時に受け付けた返信ファイルをファイル送信依頼に含まれていた返信アドレスに転送することで、ファイル交換用の専用アドレスが付与されていないユーザとの間でもファイル交換を可能にする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−１８７３８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
セキュアなファイル交換サービスにおいて、従来技術では、送信側ユーザは、Ｗｅｂブラウザもしくは専用のクライアントプログラムを利用して、送信するファイルをサーバにアップロードするとともに、ダウンロード用のパスワードや返信先等の情報を指定する一方、受信側ユーザは、ファイルが送信（アップロード）された旨の通知を電子メールで受け取り、Ｗｅｂブラウザを利用してサーバにアクセスして当該ファイルをダウンロードする手順となるのが一般的である。
【００１０】
ここで、送信側ユーザにとっては、ファイルを相手方に送信するにあたり、電子メールの添付ファイルとして送信するか、ファイル交換サービスを利用して送信するかを判断して使い分けるのは非効率であり、共通のファイルの送信方法として、ビジネス上のコミュニケーションツールとして通常利用している電子メールクライアントを利用して、添付ファイルとしてファイル交換を行えるのが望ましい。これに対しては、電子メールでの添付ファイルの送信とファイル交換サービスとを連携させ、送信側ユーザは電子メールでの添付ファイルという統一されたインタフェースによってファイルを送信する一方、受信側ユーザはファイル交換サービスを介してセキュアにファイルを受信するという仕組みをとることが考えられる。
【００１１】
しかしながら、電子メールクライアントでは、インタフェースとして電子メールの本文と添付ファイルを指定できるのみであり、Ｗｅｂブラウザを利用する場合のようにアプリケーションによってユーザインタフェースを実装することができない。すなわち、ファイルの送信に際して入力フィールド等のユーザインタフェースを介して各種情報や条件等を送信側ユーザに入力させることは困難である。従って、特に、新規の相手方に対してファイルを転送する場合等、受信側ユーザがファイル交換サービスにユーザ登録されておらずユーザＩＤを有していないような場合では、従来技術では、送信側ユーザがファイルの送信に際して例えばダウンロード用のパスワード等の情報を指定する必要があるため、実装に際しては何らかの仕組みが必要となる。
【００１２】
そこで本発明の目的は、専用のユーザＩＤ等を有さない相手方に対してファイル交換サービスによってセキュアにファイルを転送する際に、送信側ユーザが通常の電子メールクライアントを利用して添付ファイルとして送信することを可能とするファイル交換システム、ファイル交換サーバ、およびファイル交換プログラムを提供することにある。
【００１３】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１４】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１５】
本発明の代表的な実施の形態によるファイル交換システムは、ネットワークを介して通信可能な、送信側ユーザの情報処理端末上で稼働する送信側メールクライアントと、ファイル交換サーバと、受信側ユーザの情報処理端末上で稼働する受信側メールクライアントおよび受信側Ｗｅｂブラウザとからなり、前記送信側ユーザから前記受信側ユーザに対して前記ネットワークを介してファイルを転送するファイル交換システムであって、以下の特徴を有するものである。
【００１６】
すなわち、前記ファイル交換サーバは、前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、前記送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信する。
【００１７】
さらに、前記第２の電子メールを前記受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするものである。
【００１８】
また、本発明は、コンピュータを前記ファイル交換サーバとして機能させるプログラムにも適用することができる。
【発明の効果】
【００１９】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００２０】
本発明の代表的な実施の形態によれば、専用のユーザＩＤ等を有さない相手方に対してファイル交換サービスによってセキュアにファイルを転送する際に、送信側ユーザが通常の電子メールクライアントを利用して添付ファイルとして送信することが可能となる。また、専用のユーザＩＤ等を有さない受信側ユーザがパスワード等の認証情報を独自に設定することが可能となり、受信側ユーザの利便性を向上させることができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施の形態におけるファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。
【図２】本発明の一実施の形態におけるファイル交換サーバでの添付ファイルの保管処理の流れの例について示したフローチャートである。
【図３】本発明の一実施の形態におけるファイル交換サーバからの添付ファイルの受信処理の流れの例について示したフローチャートである。
【図４】従来技術のファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【００２３】
＜概要＞
図４は、従来技術のファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。ここでは、受信側ユーザがファイル交換サービスの専用のユーザＩＤ等を有していない場合の処理の流れを示している。図４において、ファイル交換システム１は、送信側ユーザの情報処理端末上で稼働する送信側Ｗｅｂブラウザ１１と、ファイル交換処理を行うファイル交換サーバ２０と、受信側ユーザの情報処理端末上で稼働する受信側メールクライアント３０、および受信側Ｗｅｂブラウザ３１からなる。
【００２４】
送信側ユーザは、送信側Ｗｅｂブラウザ１１を利用して、例えばファイル交換サーバ２０上で稼働するＷｅｂアプリケーションにアクセスし、送信ファイル４４、および宛先となる受信側ユーザの電子メールアドレスを指定してファイル交換サーバ２０にアップロードする。このとき、関連する内容の文章（電子メールの本文に相当）からなるメッセージ４２を指定することができる。また、受信側ユーザに対する説明用の簡単なコメント等を指定することもできる。また、受信側ユーザがファイル交換サーバ２０にアクセスして送信ファイル４４をダウンロードする際の認証用のワンタイムパスワード４７を指定する。ワンタイムパスワード４７は、例えば送信側ユーザが独自に作成した文字列等からなる。
【００２５】
ファイル交換サーバ２０では、送信ファイル４４をデータベース等に保管するとともに、送信ファイル４４をダウンロードするためのＵＲＬ４５を生成し、ＵＲＬ４５および受信側ユーザに対する説明用の簡単なコメントを含む電子メールを受信側ユーザの電子メールアドレス宛に送信することで、受信側ユーザに対してファイルが送信されている旨を通知する。このＵＲＬ４５は、ファイル交換の都度異なるＵＲＬとなるようにファイル交換サーバ２０がランダムにアクセストークンを生成する等の公知技術を利用して生成するのが望ましい。
【００２６】
受信側ユーザは、受信側メールクライアント３０によってファイルが送信されている旨の電子メールを受信すると、当該電子メールに含まれているＵＲＬ４５に基づいて、受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスし、送信ファイル４４およびメッセージ４２をダンロードして取得する。
【００２７】
このとき、送信側ユーザが送信時に指定したワンタイムパスワード４７を指定することによって、ダウンロードを許可するための認証を行う。なお、このワンタイムパスワード４７は、予め電話等の別の手段にて送信側ユーザから受信側ユーザに伝えておくか、ファイルが送信された旨を通知する電子メールに含まれる簡単なコメントにおいて、ワンタイムパスワード４７のヒントとなる情報（例えば送信側ユーザと受信側ユーザのみが共有する情報に基づくもの）を指定する等により、間接的に受信側ユーザに対して伝えておく。
【００２８】
このように、ファイルが送信された旨の電子メールによる通知と、送信ファイル４４およびメッセージ４２の内容についてのダウンロードを分離し、かつダウンロード時に正しい受信側ユーザのみが知り得るワンタイムパスワード４７による認証を要求する。これにより、万一誤った相手方にファイルが送信された旨の電子メールが誤送信された場合であっても、送信ファイル４４およびメッセージ４２の内容が参照されてしまうことを防ぎ、セキュアなファイル交換を実現することができる。
【００２９】
このようなファイル交換サービスの仕組みにおいて、送信側ユーザがＷｅｂブラウザではなく通常業務等で使用している一般的な電子メールクライアントを使用して添付ファイルとして送信可能とすることでインタフェースを共通化して効率化を図ることを考えた場合、送信側ユーザが電子メールクライアントを利用して図４の例に示すようにワンタイムパスワード４７を指定することは困難である。
【００３０】
そこで、本発明の一実施の形態であるファイル交換システムは、受信側ユーザがファイルをダウンロードする際の認証用のパスワードを、送信側ユーザとは関わりなく受信側ユーザが独自に設定できるようにすることで、送信側ユーザが送信時にワンタイムパスワード４７を指定することを不要とする。これにより、送信側ユーザは、通常使用している電子メールクライアントを利用して、電子メールの本文と添付ファイルの形式でファイルを送信することを可能とするものである。
【００３１】
＜電子メールとファイル交換サービスとの連携＞
図１は、本発明の一実施の形態であるファイル交換システムによって実装されるセキュアなファイル交換サービスの例について概要を示した図である。上述した図４の例と同様に、受信側ユーザがファイル交換サービスの専用のユーザＩＤ等を有していない場合の処理の流れを示している。
【００３２】
図１において、ファイル交換システム１は、図４の例と異なり、送信側ユーザのインタフェースが送信側Ｗｅｂブラウザ１１から送信側メールクライアント１０に代わっている。また、送信側メールクライアント１０によって作成された電子メールが送信されるメールサーバ５０、およびメールサーバ間で電子メールを中継するサーバ機器であるメールゲートウェイ５１を有している。メールサーバ５０およびメールゲートウェイ５１は、例えば送信側ユーザが属する企業等に設置されて管理される。また、ファイル交換サーバ２０は、メールサーバの機能を有しており、メールゲートウェイ５１を介してメールサーバ５０から電子メールの転送を受けることができる。
【００３３】
送信側ユーザは、送信側メールクライアント１０を利用して、メール本文４１および送信対象のファイルである添付ファイル４３からなる電子メールを作成して受信側ユーザの電子メールアドレスに対して送信する。当該電子メールを受け取ったメールサーバ５０は、メールゲートウェイ５１に当該電子メールを転送し、メールゲートウェイ５１は、予め設定されたルールに従って電子メールを振り分ける。
【００３４】
すなわち、ファイル交換に係る電子メールであると判断されるものについてはファイル交換サーバ２０宛に転送し、そうでないと判断されるものについては通常の電子メールとして受信側ユーザの電子メールアドレス宛にそのまま転送する。電子メールの振り分けのルールとしては、例えば、添付ファイルの有無や件名などによって判断することが可能である。これらのルールに従って送信先を振り分ける機能は、一般的なメールゲートウェイが通常有する機能を利用することができる。
【００３５】
なお、図１の例では、ファイル交換サーバ２０と、メールサーバ５０やメールゲートウェイ５１とを独立した機器としているが、これらのうちの少なくとも２つ以上を同一の機器上で実装してもよい。また、例えば、ファイル交換に係る電子メールであるか否かに関わらず全ての電子メールについてファイル交換サーバ２０を経由して処理するものとするような場合は、メールゲートウェイ５１における電子メールの振り分け処理も不要である。
【００３６】
電子メールが振り分けられたファイル交換サーバ２０では、上述した図４の例と同様に、添付ファイル４３をデータベース等に保管するとともに、添付ファイル４３をダウンロードするためのＵＲＬ４５を生成し、メール本文４１にＵＲＬ４５を追加した内容の電子メールを受信側ユーザの電子メールアドレス宛に送信することで、受信側ユーザに対してファイルが送信されている旨を通知する。
【００３７】
受信側ユーザは、受信側メールクライアント３０によってファイルが送信されている旨の電子メールを受信すると、当該電子メールに含まれているＵＲＬ４５に基づいて、受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスし、添付ファイル４３をダンロードして取得する。
【００３８】
このとき、受信側ユーザが独自に設定しているパスワード４６を指定することによって、ファイル交換サーバ２０においてダウンロードのための認証を行う。これにより、送信側ユーザはファイルの送信時にパスワード等を指定することが不要となるため、通常使用している電子メールクライアントを利用して、電子メールの本文と添付ファイルの形式でファイルを送信することが可能となる。
【００３９】
＜処理の流れ（添付ファイル保管）＞
以下では、ファイル交換サーバ２０がメールゲートウェイ５１を介して添付ファイル４３を有する電子メールを受け取り、添付ファイル４３を保管する際の処理の流れについて説明する。図２は、ファイル交換サーバ２０での添付ファイル４３の保管処理の流れの例について示したフローチャートである。
【００４０】
ファイル交換サーバ２０は、メールサーバ５０およびメールゲートウェイ５１を介して送信側メールクライアント１０から添付ファイル４３を有する電子メールを受け取ると、まず、当該電子メールの送信先（受信側ユーザ）にとって当該ファイル交換システム１を介したファイルの受信が初めてか否かを判定する（Ｓ０１）。ここでは例えば、ファイル交換サーバ２０が有する後述する暗号鍵ＤＢ２２に、受信側ユーザの電子メールアドレスに対応するレコードが存在するか否かによって判定する。
【００４１】
暗号鍵ＤＢ２２に受信側ユーザの電子メールアドレスに対応するレコードが存在しない場合は、当該受信側ユーザにとって初回の受信であると判定し、ファイル交換サーバ２０は、当該受信側ユーザについて、秘密鍵と公開鍵からなる鍵ペアを生成する（Ｓ０２）。ここでは、ＰＫＩ（Public Key Infrastructure：公開鍵基盤）を利用した一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。生成した鍵ペアのうち、公開鍵については、暗号鍵を保持・管理するデータベースである暗号鍵ＤＢ２２に、受信側ユーザの電子メールアドレスと対応付けて新たなレコードとして格納する。
【００４２】
次に、ファイル交換サーバ２０は、当該受信側ユーザに対して初期パスワードを発行する（Ｓ０３）。初期パスワードは、例えば、ランダムに生成した十分な長さの文字列とする。生成した初期パスワードは、ハッシュ化してＡＥＳ（Advanced Encryption Standard）による暗号化の際の暗号鍵として利用可能な１２８ビット〜２５６ビットのデータとして、暗号鍵ＤＢ２２の受信側ユーザのレコードに追加して格納する。その後、生成した初期パスワードを通知する電子メールを、受信側ユーザの電子メールアドレスに対して送信する（Ｓ０４）。
【００４３】
次に、ファイル交換サーバ２０は、ステップＳ０２で生成した秘密鍵をステップＳ０３で生成した初期パスワードによって暗号化する（Ｓ０５）。ここでは例えば、初期パスワードをハッシュ化したもの（ステップＳ０３にて暗号鍵ＤＢ２２に格納したもの）を暗号鍵としてＡＥＳによって秘密鍵を暗号化する。ＡＥＳによる暗号化については、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。暗号化した秘密鍵は、暗号鍵ＤＢ２２の受信側ユーザのレコードに追加して格納する。なお、元の暗号化されていない秘密鍵のデータは第三者に取得されないよう破棄する。
【００４４】
一方、ステップＳ０１で受信側ユーザにとってファイルの受信が初回ではない場合、すなわち、暗号鍵ＤＢ２２に受信側ユーザの電子メールアドレスに対応するレコードが存在する場合は、当該レコードから受信側ユーザに対応する公開鍵を取得する（Ｓ０６）。
【００４５】
上述の処理によって受信側ユーザに対応する公開鍵を生成もしくは取得すると、次に、ファイル交換サーバ２０は、送信側メールクライアント１０から受け取った添付ファイル４３を暗号化するための共通鍵を生成する（Ｓ０７）。当該共通鍵の生成についても、一般的に入手可能な鍵生成ソフトウェアやライブラリを使用することができる。
【００４６】
次に、ファイル交換サーバ２０は、送信側メールクライアント１０から受け取った添付ファイル４３をステップＳ０７で生成した共通鍵によって暗号化する（Ｓ０８）。ここでは、送信側メールクライアント１０から受け取った電子メールから添付ファイル４３を分離し、これをステップＳ０７で生成した共通鍵を暗号鍵としてＡＥＳによって暗号化する。暗号化した添付ファイル４３は、添付ファイルを保持・管理するデータベースであるファイルＤＢ２１に、受信側ユーザの電子メールアドレスと対応付けて格納する。
【００４７】
さらに、添付ファイル４３をダウンロードするためのＵＲＬ４５を生成して、当該添付ファイル４３のレコードに追加して格納する（Ｓ０９）。ＵＲＬ４５は、上述したように、ファイル交換の都度異なるＵＲＬとなるようにランダムにアクセストークンを生成する等の公知技術を利用して生成する。その後、送信側ユーザからの電子メールの本文および添付ファイル４３をダウンロードするためのＵＲＬ４５の情報を通知する電子メールを、受信側ユーザの電子メールアドレスに対して送信する（Ｓ１０）。
【００４８】
次に、ファイル交換サーバ２０は、ステップＳ０７で生成した共通鍵をステップＳ０２で生成した公開鍵もしくはステップＳ０６で取得した公開鍵によって暗号化する（Ｓ１１）。ここでは、例えば公開鍵によるＲＳＡ（Rivest Shamir Adleman）暗号化などを利用することができる。ＲＳＡによる暗号化についても、一般的に入手可能な暗号化ソフトウェアやライブラリを使用することができる。暗号化した共通鍵は、暗号鍵ＤＢ２２の受信側ユーザのレコードに追加して格納する。なお、元の暗号化されていない共通鍵のデータは第三者に取得されないよう破棄する。
【００４９】
以上のように、ファイル交換サーバ２０において、受信側ユーザが添付ファイル４３をダウンロードする際に使用するパスワードおよび添付ファイル４３の暗号化／復号化のための暗号鍵を生成し、これらを電子メールアドレスに対応付けて管理する。これにより、送信側ユーザによるファイルの送信時におけるパスワード等の指定を不要とすることができる。なお、上記の処理の流れは一例であり、処理順序は可能な範囲で適宜前後させることが可能である。
【００５０】
＜処理の流れ（添付ファイル受信）＞
以下では、受信側ユーザがファイル交換サーバ２０を介して送信側ユーザからのファイルを送信する旨の電子メールを受信し、これに基づいてファイル交換サーバ２０から添付ファイル４３を受信する際の処理の流れについて説明する。図３は、ファイル交換サーバ２０からの添付ファイル４３の受信処理の流れの例について示したフローチャートである。
【００５１】
送信側ユーザからのファイルを送信する旨の電子メールを受信した受信側ユーザは、本文の内容を確認し、当該電子メールに含まれている添付ファイル４３のダウンロード用のＵＲＬ４５に基づいて、受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスすることで、添付ファイル４３の受信処理を開始する。
【００５２】
受信処理を開始すると、ファイル交換サーバ２０は、まず、当該受信側ユーザにとって当該ファイル交換システム１を介したファイルの受信が初めてか否かを判定する（Ｓ２１）。ここでは例えば、受信側ユーザが受信側Ｗｅｂブラウザ３１を利用してファイル交換サーバ２０にアクセスしてきたときのＵＲＬ４５の内容に基づいて、ファイルＤＢ２１を参照して対象となる添付ファイル４３および受信側ユーザの電子メールアドレスを特定する。さらに、特定した電子メールアドレスに基づいて暗号鍵ＤＢ２２における当該受信側ユーザのレコードを参照することで初回受信か否かを判定する。初回受信か否かについては、例えば、これを示すフラグを暗号鍵ＤＢ２２に設ける等によって判定することができる。
【００５３】
受信側ユーザにとって初回受信である場合は、ファイル交換サーバ２０は、受信側Ｗｅｂブラウザ３１を介して受信側ユーザに対して初期パスワードおよび新パスワードの入力を要求し、これに対して受信側ユーザは初期パスワードおよび新パスワードを入力してパスワードを更新する（Ｓ２２）。このとき、入力された初期パスワードが暗号鍵ＤＢ２２における受信側ユーザの初期パスワードと一致しない場合はファイルの受信処理を終了し、一致する場合には暗号鍵ＤＢ２２の該当の初期パスワードを入力された新パスワード（ハッシュ化したもの）によって更新する。
【００５４】
次に、ファイル交換サーバ２０は、暗号鍵ＤＢ２２の当該受信側ユーザのレコードから暗号化された秘密鍵を取得し、これをステップＳ２２にて入力された初期パスワードを利用して復号化する（Ｓ２３）。ここでは、秘密鍵は図１のステップＳ０５においてＡＥＳによって暗号化されているため、初期パスワードをハッシュ化したものを復号鍵としてＡＥＳによって復号化する。
【００５５】
さらに、復号化した秘密鍵をステップＳ２２にて入力された新パスワードによって暗号化する（Ｓ２４）。ここでは、図１のステップＳ０５と同様に、新パスワードをハッシュ化したもの（ステップＳ２２にて暗号鍵ＤＢ２２に格納したもの）を暗号鍵としてＡＥＳによって秘密鍵を暗号化する。また、暗号化した秘密鍵によって、暗号鍵ＤＢ２２の受信側ユーザのレコードの内容を上書きして更新する。その後、パスワードが変更された旨を通知する電子メールを、受信側ユーザに対して送信する（Ｓ２５）。
【００５６】
一方、ステップＳ２１で受信側ユーザにとって初回受信ではない場合は、ファイル交換サーバ２０は、受信側Ｗｅｂブラウザ３１を介して受信側ユーザに対してパスワードの入力を要求し、これに対して受信側ユーザはパスワード（原則として以前に自身がステップＳ２２において新パスワードとして指定したもの）を入力する（Ｓ２６）。入力されたパスワードが暗号鍵ＤＢ２２における受信側ユーザのパスワードと一致しない場合はファイルの受信処理を終了する。
【００５７】
パスワードが一致する場合には暗号鍵ＤＢ２２の当該受信側ユーザのレコードから暗号化された秘密鍵を取得し、これをステップＳ２６にて入力されたパスワードを利用して復号化する（Ｓ２７）。ここでは、ステップＳ２４と同様に、秘密鍵は図１のステップＳ０５においてＡＥＳによって暗号化されているため、パスワードをハッシュ化したもの（ステップＳ２２にて暗号鍵ＤＢ２２に格納したもの）を復号鍵としてＡＥＳによって復号化する。
【００５８】
上述の処理によって受信側ユーザに対応する秘密鍵を取得すると、次に、ファイル交換サーバ２０は、暗号鍵ＤＢ２２から対象の添付ファイル４３の復号化に用いる共通鍵（すなわち暗号化に用いられた共通鍵）を取得してこれを復号化する（Ｓ２８）。ここでは、当該共通鍵は、図２のステップＳ１１において受信側ユーザに対応する公開鍵を暗号鍵としてＲＳＡによって暗号化されているため、対応する秘密鍵によってこれを復号化することができる。
【００５９】
次に、ファイル交換サーバ２０は、ファイルＤＢ２１に格納された対象の添付ファイル４３を取得し、これをステップＳ２８で取得した共通鍵を利用して復号化する（Ｓ２９）。ここでは、添付ファイル４３は、図２のステップＳ０８においてＡＥＳによって暗号化されているため、共通鍵を復号鍵としてＡＥＳによって復号化する。その後、復号化した添付ファイル４３を、受信側Ｗｅｂブラウザ３１を介して受信側ユーザによってダウンロード可能とすることで、受信側ユーザは添付ファイル４３をダウンロードして取得する（Ｓ３０）。
【００６０】
以上のように、受信側ユーザは、ファイル交換サービスの専用のユーザＩＤ等を有していない場合であっても、自身が設定したパスワードによってセキュアに添付ファイル４３を取得することができる。なお、上記の処理の流れは一例であり、処理順序は可能な範囲で適宜前後させることが可能である。
【００６１】
なお、受信側ユーザがパスワードを紛失した場合など、パスワードをクリアしたい場合には、例えば、受信側Ｗｅｂブラウザ３１を介してファイル交換サーバ２０に対してパスワードクリアの要求を行う。このとき、ファイル交換サーバ２０は、暗号鍵ＤＢ２２における当該受信側ユーザのレコードを削除するとともに、図２のステップＳ０２〜Ｓ０５と同様の処理を行って、当該受信側ユーザに対応する公開鍵と秘密鍵、およびパスワードを新たに生成する。その後、受信側ユーザは、送信側ユーザに対して添付ファイル４３を含む電子メールの再送を依頼することで添付ファイル４３を受信することができる。
【００６２】
以上に説明したように、本発明の一実施の形態であるファイル交換システム１によれば、受信側ユーザが添付ファイル４３をダウンロードする際の認証用のパスワードを、ファイル交換サーバ２０が生成して発行し、送信側ユーザとは関わりなく受信側ユーザが独自に設定できるようにすることで、送信側ユーザが送信時にワンタイムパスワード等のダウンロードに係る情報や条件を指定することが不要となる。これにより、送信側ユーザは、通常使用している電子メールクライアントを利用して、電子メールの本文と添付ファイルの形式でファイルを送信することが可能となる。また、専用のユーザＩＤ等を有さない受信側ユーザであってもパスワード等の認証情報を独自に設定することが可能となり、受信側ユーザの利便性を向上させることができる。
【００６３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００６４】
本発明は、インターネットを介してセキュアにファイルの送受信を行うファイル交換システム、ファイル交換サーバ、およびファイル交換プログラムに利用可能である。
【符号の説明】
【００６５】
１…ファイル交換システム、
１０…送信側メールクライアント、
２０…ファイル交換サーバ、
３０…受信側メールクライアント、３１…受信側Ｗｅｂブラウザ、
４１…メール本文、４２…メッセージ、４３…添付ファイル、４４…送信ファイル、４５…ＵＲＬ、４６…パスワード、４７…ワンタイムパスワード、
５０…メールサーバ、５１…メールゲートウェイ。
【特許請求の範囲】
【請求項１】
ネットワークを介して通信可能な、送信側ユーザの情報処理端末上で稼働する送信側メールクライアントと、ファイル交換サーバと、受信側ユーザの情報処理端末上で稼働する受信側メールクライアントおよび受信側Ｗｅｂブラウザとからなり、前記送信側ユーザから前記受信側ユーザに対して前記ネットワークを介してファイルを転送するファイル交換システムであって、
前記ファイル交換サーバは、
前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、
前記送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信し、
前記第２の電子メールを前記受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするファイル交換システム。
【請求項２】
請求項１に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記受信側ユーザの電子メールアドレスと、前記受信側ユーザに対応する公開鍵とを対応付けて保管しており、
前記第１の電子メールを受け取った際に、前記受信側ユーザの電子メールアドレスに対応する前記公開鍵を取得し、さらに共通鍵を生成して、前記添付ファイルを保管する際に前記共通鍵によって暗号化して保管するとともに、前記共通鍵を前記公開鍵によって暗号化して、前記受信側ユーザの電子メールアドレスと対応付けて保管することを特徴とするファイル交換システム。
【請求項３】
請求項２に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記受信側ユーザの電子メールアドレスと、前記公開鍵に対応する秘密鍵を前記認証用のパスワードを利用して暗号化したものを保管しており、
前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記受信側ユーザの電子メールアドレスに対応する暗号化された前記秘密鍵、暗号化された前記共通鍵、および暗号化された前記添付ファイルを取得し、暗号化された前記秘密鍵を前記受信側ユーザによって入力された前記認証用のパスワードを利用して復号化し、さらに暗号化された前記共通鍵を前記秘密鍵によって復号化し、さらに暗号化された前記添付ファイルを前記共通鍵によって復号化して、取得した前記添付ファイルをダウンロード可能とすることを特徴とするファイル交換システム。
【請求項４】
請求項１〜３のいずれか１項に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記第１の電子メールを受け取った際に、前記受信側ユーザにとって当該ファイル交換システムを介したファイルの受信が初めてである場合、
前記受信側ユーザに対して初期パスワードを発行し、前記初期パスワードに係る情報を前記受信側ユーザの電子メールアドレスと対応付けて保管するとともに、前記初期パスワードを通知する第３の電子メールを前記受信側ユーザの電子メールアドレスに対して送信することを特徴とするファイル交換システム。
【請求項５】
請求項４に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記第１の電子メールを受け取った際に、前記受信側ユーザにとって当該ファイル交換システムを介したファイルの受信が初めてである場合、
前記受信側ユーザに対応する公開鍵と秘密鍵とからなる鍵ペアを生成し、前記公開鍵を前記受信側ユーザの電子メールアドレスと対応付けて保管し、さらに前記秘密鍵を前記初期パスワードを利用して暗号化して、前記受信側ユーザの電子メールアドレスと対応付けて保管することを特徴とするファイル交換システム。
【請求項６】
請求項５に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記受信側ユーザにとって当該ファイル交換システムを介したファイルの受信が初めてである場合、
前記受信側ユーザに前記初期パスワードと前記受信側ユーザが設定した新パスワードを入力させ、前記新パスワードに係る情報を前記受信側ユーザの電子メールアドレスと対応付けて保管するとともに、前記受信側ユーザの電子メールアドレスに対応する暗号化された前記秘密鍵、暗号化された前記共通鍵、および暗号化された前記添付ファイルを取得し、暗号化された前記秘密鍵を前記受信側ユーザによって入力された前記初期パスワードを利用して復号化し、さらに暗号化された前記共通鍵を前記秘密鍵によって復号化するとともに、前記秘密鍵を前記新パスワードを利用して暗号化して前記受信側ユーザの電子メールアドレスと対応付けて保管し、さらに暗号化された前記添付ファイルを前記共通鍵によって復号化して、取得した前記添付ファイルをダウンロード可能とすることを特徴とするファイル交換システム。
【請求項７】
ネットワークを介して送信側ユーザから受信側ユーザに対してファイルを転送するファイル交換サーバであって、
前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、
前記送信側ユーザの情報処理端末上で稼働する送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信し、
前記第２の電子メールを前記受信側ユーザの情報処理端末上で稼働する受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側ユーザの情報処理端末上で稼働する受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするファイル交換サーバ。
【請求項８】
ネットワークを介して送信側ユーザから受信側ユーザに対してファイルを転送するファイル交換サーバとしてコンピュータを機能させるファイル交換プログラムであって、
前記ファイル交換サーバにおいて、前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、
前記送信側ユーザの情報処理端末上で稼働する送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信し、
前記第２の電子メールを前記受信側ユーザの情報処理端末上で稼働する受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側ユーザの情報処理端末上で稼働する受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするファイル交換プログラム。
【請求項１】
ネットワークを介して通信可能な、送信側ユーザの情報処理端末上で稼働する送信側メールクライアントと、ファイル交換サーバと、受信側ユーザの情報処理端末上で稼働する受信側メールクライアントおよび受信側Ｗｅｂブラウザとからなり、前記送信側ユーザから前記受信側ユーザに対して前記ネットワークを介してファイルを転送するファイル交換システムであって、
前記ファイル交換サーバは、
前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、
前記送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信し、
前記第２の電子メールを前記受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするファイル交換システム。
【請求項２】
請求項１に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記受信側ユーザの電子メールアドレスと、前記受信側ユーザに対応する公開鍵とを対応付けて保管しており、
前記第１の電子メールを受け取った際に、前記受信側ユーザの電子メールアドレスに対応する前記公開鍵を取得し、さらに共通鍵を生成して、前記添付ファイルを保管する際に前記共通鍵によって暗号化して保管するとともに、前記共通鍵を前記公開鍵によって暗号化して、前記受信側ユーザの電子メールアドレスと対応付けて保管することを特徴とするファイル交換システム。
【請求項３】
請求項２に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記受信側ユーザの電子メールアドレスと、前記公開鍵に対応する秘密鍵を前記認証用のパスワードを利用して暗号化したものを保管しており、
前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記受信側ユーザの電子メールアドレスに対応する暗号化された前記秘密鍵、暗号化された前記共通鍵、および暗号化された前記添付ファイルを取得し、暗号化された前記秘密鍵を前記受信側ユーザによって入力された前記認証用のパスワードを利用して復号化し、さらに暗号化された前記共通鍵を前記秘密鍵によって復号化し、さらに暗号化された前記添付ファイルを前記共通鍵によって復号化して、取得した前記添付ファイルをダウンロード可能とすることを特徴とするファイル交換システム。
【請求項４】
請求項１〜３のいずれか１項に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記第１の電子メールを受け取った際に、前記受信側ユーザにとって当該ファイル交換システムを介したファイルの受信が初めてである場合、
前記受信側ユーザに対して初期パスワードを発行し、前記初期パスワードに係る情報を前記受信側ユーザの電子メールアドレスと対応付けて保管するとともに、前記初期パスワードを通知する第３の電子メールを前記受信側ユーザの電子メールアドレスに対して送信することを特徴とするファイル交換システム。
【請求項５】
請求項４に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記第１の電子メールを受け取った際に、前記受信側ユーザにとって当該ファイル交換システムを介したファイルの受信が初めてである場合、
前記受信側ユーザに対応する公開鍵と秘密鍵とからなる鍵ペアを生成し、前記公開鍵を前記受信側ユーザの電子メールアドレスと対応付けて保管し、さらに前記秘密鍵を前記初期パスワードを利用して暗号化して、前記受信側ユーザの電子メールアドレスと対応付けて保管することを特徴とするファイル交換システム。
【請求項６】
請求項５に記載のファイル交換システムにおいて、
前記ファイル交換サーバは、
前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記受信側ユーザにとって当該ファイル交換システムを介したファイルの受信が初めてである場合、
前記受信側ユーザに前記初期パスワードと前記受信側ユーザが設定した新パスワードを入力させ、前記新パスワードに係る情報を前記受信側ユーザの電子メールアドレスと対応付けて保管するとともに、前記受信側ユーザの電子メールアドレスに対応する暗号化された前記秘密鍵、暗号化された前記共通鍵、および暗号化された前記添付ファイルを取得し、暗号化された前記秘密鍵を前記受信側ユーザによって入力された前記初期パスワードを利用して復号化し、さらに暗号化された前記共通鍵を前記秘密鍵によって復号化するとともに、前記秘密鍵を前記新パスワードを利用して暗号化して前記受信側ユーザの電子メールアドレスと対応付けて保管し、さらに暗号化された前記添付ファイルを前記共通鍵によって復号化して、取得した前記添付ファイルをダウンロード可能とすることを特徴とするファイル交換システム。
【請求項７】
ネットワークを介して送信側ユーザから受信側ユーザに対してファイルを転送するファイル交換サーバであって、
前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、
前記送信側ユーザの情報処理端末上で稼働する送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信し、
前記第２の電子メールを前記受信側ユーザの情報処理端末上で稼働する受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側ユーザの情報処理端末上で稼働する受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするファイル交換サーバ。
【請求項８】
ネットワークを介して送信側ユーザから受信側ユーザに対してファイルを転送するファイル交換サーバとしてコンピュータを機能させるファイル交換プログラムであって、
前記ファイル交換サーバにおいて、前記受信側ユーザの電子メールアドレスと、前記受信側ユーザが設定した認証用のパスワードに係る情報とを対応付けて保管しており、
前記送信側ユーザの情報処理端末上で稼働する送信側メールクライアントを利用して前記送信側ユーザから前記受信側ユーザの電子メールアドレスに対して送信された添付ファイルを有する第１の電子メールを受け取った際に、前記第１の電子メールにおける前記添付ファイルを保管するとともに、前記添付ファイルをダウンロードするためのＵＲＬを生成して、前記受信側ユーザの電子メールアドレスと対応付けて前記添付ファイルと前記ＵＲＬとを保管し、さらに前記第１の電子メールにおける本文と前記ＵＲＬとを含む第２の電子メールを、前記受信側ユーザの電子メールアドレスに対して送信し、
前記第２の電子メールを前記受信側ユーザの情報処理端末上で稼働する受信側メールクライアントによって受信した前記受信側ユーザが、前記第２の電子メールに含まれる前記ＵＲＬに基づいて、前記受信側ユーザの情報処理端末上で稼働する受信側Ｗｅｂブラウザを利用してアクセスしてきた際に、前記ＵＲＬの情報に基づいて前記受信側ユーザを特定し、前記受信側ユーザに前記認証用のパスワードを入力させて前記受信側ユーザの認証を行ったうえで、前記添付ファイルのダウンロードを可能とすることを特徴とするファイル交換プログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−１６０１１０（Ｐ２０１２−１６０１１０Ａ）
【公開日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願番号】特願２０１１−２０６０１（Ｐ２０１１−２０６０１）
【出願日】平成２３年２月２日（２０１１．２．２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年８月２３日（２０１２．８．２３）
【国際特許分類】
【出願日】平成２３年２月２日（２０１１．２．２）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]