JP2019057234A - 配信制御装置、端末、配信制御方法、およびプログラム - Google Patents

Abstract

【課題】メールの機密性とメールの受信者の安全とを、低コストで保障するシステムを提供する。【解決手段】配信制御装置は、特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付部と、受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成部と、暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号部と、前記復号手段により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理部と、を備える。【選択図】 図１１

Description

本開示は、添付ファイルを含むメールの配信を制御する技術に関する。

メール（本開示では、電子メールを意味する）のやり取りを安全に行う方法として、Ｓ／ＭＩＭＥ（Ｓｅｃｕｒｅ Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ）が広く知られている。この方法によると、互いにやり取りされるメールは暗号化され、機密性が守られる。すなわち、通信経路の途中でデータが盗み見られたとしても内容を理解されることを防ぐことができる。しかし、Ｓ／ＭＩＭＥの利用には、メール送信側と受信側とが、証明書を発行したり、Ｓ／ＭＩＭＥ対応のメーラを利用したりする必要がある等といった制限が多い。

安全な添付ファイルのやりとりをより簡易な方法で実現する発明が、特許文献１から４に記載されている。

特許文献１に記載の方法は、電子ファイリングシステムがチケットメールを発行し、ユーザがそのチケットメールへの返信に対してファイルを添付して返信すると、返信メールを受信した電子ファイリングシステムが、返信メールの正当性をチェックした上で添付ファイルを所定の場所に格納する、という方法である。

特許文献２および３は、添付ファイルの暗号化と復号に関する技術を記載している。メールの受信側のサーバは、送信者にひもづいた暗号鍵をテーブルから取り出し、取り出した暗号鍵によって添付ファイルを復号する。

特許文献４に記載の方法では、メールサーバが、メールを受け取る毎に、そのメールに基づき暗号鍵を作成し、添付ファイルを暗号化する。メールの受信側である第２の端末はメールサーバから暗号鍵を受け取り、添付ファイルを復号する。

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

特許文献１の方法では、添付ファイルは暗号化されないため、インターネット上でのやり取りにこの方法を適用すると、機密性が十分でない。

特許文献２から４は機密性を保障する技術を開示しているが、送信者側で暗号鍵が生成される場合、復号のための鍵を受信側に伝える方法が問題となる。復号のための鍵を安全に送るためには、複雑な構成を要するか、さもなければ情報漏えいのリスクが高まる。また、送信者が信頼できる（すなわち、悪意のない）者であることを確認するためのしくみも必要となる。

また、特許文献１に記載の方法には、次のような問題もある。すなわち、送信側の信頼性は返信メールの送信元のメールアドレスのチェックによって保障されるが、チケットメールが第三者に漏えいした場合、その第三者はチケットメールに、送信元を偽った上で返信することで、悪意のあるファイルを送ることが可能である。送信元のメールアドレスを偽ることは、チケットメールの送信先を見ることにより容易にできてしまうため、なりすましが行われるリスクは高い。

このように、関連する技術は、受信者の安全、機密性、およびシステムの簡易さ（言い換えれば、コスト）のいずれかが、十分ではない。

本発明は、メールの機密性とメールの受信者の安全とを、低コストで保障するシステムを提供することを目的の１つとする。

本発明の一態様に係る配信制御装置は、特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付手段と、受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成手段と、暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号手段と、前記復号手段により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理手段と、を備える。

本発明の一態様に係る端末は、特定のメールアドレス宛のメールを受信する通信手段と、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報を含む、鍵生成依頼を、ユーザインタフェースを介して受け付ける受付手段と、受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信先に関連づけられる暗号鍵を生成する鍵生成手段と、暗号化された添付ファイルを含む前記メールが受信された場合に、当該メールの送信先に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号手段と、前記復号手段により復号された復号後の添付ファイルを含む前記メールを記憶するメール記憶手段と、を備える。

本発明の一態様に係る配信制御方法は、特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付け、受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成し、暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行い、復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う。

本発明の一態様に係るプログラムは、特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付処理と、受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成処理と、暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルの暗号化を解除するための復号処理を行う復号処理と、前記復号手段により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理と、をコンピュータに実行させる。

本発明によれば、添付ファイルの安全なやりとりを簡易に行える。

本発明の第１の実施形態に係るメール通信システムの構成を示すブロック図である。 第１の実施形態に係る配信制御装置の構成を示すブロック図である。 チケットの発行申請を行う際にユーザ端末に表示される画面の例である。 第１の実施形態に係る配信制御装置による、チケットの発行に係る動作の流れを示すフローチャートである。 チケットデータベースに記憶されるチケット情報の例を示す図である。 鍵データベースに記憶される情報の例を示す図である。 第１の実施形態に係る配信制御装置による、メールの受信に係る動作の流れを示すフローチャートである。 添付ファイルの復号処理の具体的な処理の流れを示すフローチャートである。 第１の実施形態に係る配信制御装置の変形例の構成を示すブロック図である。 本発明の第２の実施形態に係るユーザ端末の構成を示すブロック図である。 本発明の一実施形態に係る配信制御装置の構成を示すブロック図である。 本発明の一実施形態に係る配信制御装置の動作の流れを示すブロック図である。 本発明の一実施形態に係る端末の構成を示すブロック図である。 本発明の一実施形態に係る端末の動作の流れを示すブロック図である。 本発明の各実施形態の各部を構成するハードウェアの例を示すブロック図である。

以下、図面を参照しながら、本発明の実施形態を詳細に説明する。

＜＜第１の実施形態＞＞
まず、本発明の第１の実施形態について説明する。

＜構成＞
図１は、第１の実施形態に係るメール通信システム１の構成を示すブロック図である。メール通信システム１は、メールサーバ４１と、ユーザ端末２１とを含む。

メールサーバ４１は、他のメールサーバ４２からメールを受信し、受信したメールを保持し、または他のメールサーバに転送する。メールサーバ４１は、ＭＴＡ１５と、メールボックス１９と、配信制御装置１１と、を含む。

ＭＴＡ１５は、ＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）である。ＭＴＡ１５は、通信ネットワーク８を介して他のメールサーバ４２のＭＴＡ２５からメールを受け取る。そして、ＭＴＡ１５は、受け取ったメールの配送先がメールサーバ４１（当該ＭＴＡ１５を含むメールサーバ）であるかを判定する。なお、ＭＴＡ１５が他のＭＴＡ２５との間で用いる一般的なプロトコルは、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）である。

ＭＴＡ１５は、受け取ったメールの配送先がメールサーバ４１でない場合は、そのメールを、配送先であるメールサーバのＭＴＡへ転送する。

ＭＴＡ１５は、受け取ったメールの配送先がメールサーバ４１である場合は、そのメールを取り込む。「取り込む」とは、メールをメールサーバ４１の外部へ転送せずに、メールサーバ４１が保持するメールとして扱うことである。具体的には、ＭＴＡ１５は、配送先がメールサーバ４１であるメールを、メールサーバ４１内の配信制御装置１１に送る。

メールボックス１９は、メールを記憶する。メールは、ＭＴＡ１５から配信制御装置１１に送られた後、配信制御装置１１によりメールボックス１９に格納される。メールサーバ４１内のメールボックス１９を使用するユーザが複数いる場合は、ユーザごとに異なるメールボックス１９があってよい。

なお、メールサーバ４１とメールを送受信する他のメールサーバ４２の機能は、メールサーバ４１の機能と同一でもよいし、同一でなくてもよい。

ユーザ端末２１は、メールサーバ４１のメールボックス１９に記憶されるメールを閲覧するための端末である。本開示では、メールボックス１９にアクセスしメールを閲覧する人を、ユーザと呼ぶ。ユーザ端末２１は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、タブレット、携帯電話等の情報処理装置である。ユーザ端末２１は、ＭＵＡ（Ｍａｉｌ Ｕｓｅｒ Ａｇｅｎｔ）としての機能を備える。

メールサーバ４１とユーザ端末２１とは、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の通信ネットワークにより、互いに通信可能に接続される。メールサーバ４１とユーザ端末２１との間の通信がセキュアな通信であれば、メールの機密性はより高くなる。

メールサーバ４１とユーザ端末２１との間でメールをやりとりする一般的なプロトコルは、ＩＭＡＰ４（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ ４）やＰＯＰ３（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ３）である。

配信制御装置１１について、以下詳述する。

図２は、配信制御装置１１の構成を詳細に示すブロック図である。配信制御装置１１は、チケット申請受付部１１１と、チケット発行部１１２と、鍵生成部１１３と、チケットデータベース１２２と、鍵データベース１２３と、メール受付部１３１と、メール解析部１３２と、チケット検索部１３３と、鍵取得部１３４と、復号部１３５と、有効性確認部１３６と、メール加工部１３７と、格納処理部１３８と、を備える。

チケット申請受付部１１１と、チケット発行部１１２と、鍵生成部１１３とは、チケットの発行に係る処理を行う構成要素である。

チケット申請受付部１１１は、ユーザ端末２１から、チケットの発行の申請を受け付ける。

チケット発行部１１２は、チケットの発行の申請に基づき、チケットを発行する。

本開示におけるチケットとは、暗号鍵の使用に関する一群の情報である。チケットは、例えば、チケットを一意に識別可能なＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）（以下、「チケットＩＤ」と表記）、チケットの発行の申請を行う申請者、暗号鍵が使用されるメールの送信元および送信先を指定する情報、ならびに復号の条件を含む。

申請者、送信元および送信先を表す情報は、例えば、メールアドレスである。チケットＩＤは、例えば、チケット発行部１１２が任意のアルゴリズムを用いてチケットにＩＤを割り当てることにより生成される。復号の条件は、例えば、暗号鍵により復号される添付ファイルの条件と、添付ファイルが復号されるメールの条件とに大別される。暗号鍵により復号される添付ファイルの条件の一例は、添付ファイルのサイズの範囲の条件（例えば、「サイズが２０ＭＢ以下であること」等）である。添付ファイルが復号されるメールの条件の一例は、メールが送信された時刻に関する条件（例えば、「メールが送信された時刻が、設定された『有効期間』内であること」等）である。有効期間が設定される場合、有効期間内に送信されたメールが、添付ファイルが復号されるメールとなる。有効期間は、暗号鍵の有効期間とも言うことができるし、チケットの有効期間ということもできる。有効期間は、チケットの発行の申請において指定されてもよいし、チケット発行部１１２が、申請が受け付けられた時刻に基づく所定の期間を有効期間として設定してもよい。

以下、チケットを構成する情報を「チケット情報」とも称する。チケット発行部１１２は、チケットの発行の申請に基づいてチケット情報を生成し（本開示ではこの処理を「発行する」と呼ぶ）、そのチケット情報をチケットデータベース１２２に格納する。チケット発行部１１２は、チケットデータベース１２２が記憶する情報を制御することから、記憶制御部と呼ぶこともできる。

チケット発行部１１２は、チケットの申請者が、申請を許可された者として配信制御装置１１に登録されている者である場合に限り、チケットを発行してもよい。そのような構成により、悪意のある者による申請に基づくチケットの発行を防止することができる。

チケット申請受付部１１１が、所定の端末からの申請のみを受け付けるよう構成されていてもよい。たとえば、チケット申請受付部１１１は、配信制御装置１１が含まれる所定のネットワーク内のユーザ端末２１からの申請のみ受け付けてもよい。

チケット申請受付部１１１は、申請者の情報に基づき、チケットの発行の申請を受け付けるか否かを判定してもよい。例えば、チケット申請受付部１１１は、申請者の情報として記載されたメールアドレスが、メールサーバ４１が取り込む対象であるメールアドレスである場合（例えばメールサーバ４１が特定のドメイン名を含むメールアドレスを取り込む構成である場合において、申請者の情報として記載されたメールアドレスがそのドメイン名を含む場合）に、申請を受け付けることを決定してもよい。

鍵生成部１１３は、チケット発行部１１２が発行したチケット情報から、暗号鍵を生成する。暗号鍵を生成する方法には、暗号鍵を生成する既知の方法が採用されればよい。

暗号鍵の生成に用いられるチケット情報には、チケットの各々を一意に識別可能な情報が用いられる。それにより、生成される暗号鍵はチケットごとに異なる。チケットの各々を一意に識別可能な情報は、例えば、チケットの発行申請が送信された時刻と申請者との組、送信元と送信先と有効期間との組、または、チケットＩＤ等である。

鍵生成部１１３が生成する暗号鍵の種類は、例えば、共通鍵である。あるいは、鍵生成部１１３は、ファイルを暗号化するための第１の暗号鍵と、第１の暗号鍵により暗号化されたファイルを復号するための第２の暗号鍵と、を生成してもよい。この場合、公開鍵と秘密鍵との関係のように、第１の暗号鍵と第２の暗号鍵は異なっていてもよい。

鍵生成部１１３は、生成した暗号鍵（少なくとも、暗号化されたファイルを復号するための鍵）を、チケットＩＤに関連づけられる形式で、鍵データベース１２３に格納する。

また、鍵生成部１１３は、生成した、ファイルを暗号化するための暗号鍵を、申請者に通知する。例えば、鍵生成部１１３は、該暗号鍵を含む情報を、チケット申請受付部１１１を介して、申請者であるユーザ端末２１に送信する。

チケットデータベース１２２は、チケット発行部１１２により発行されたチケットのチケット情報を記憶する。

鍵データベース１２３は、鍵生成部１１３が生成した暗号鍵を記憶する。鍵データベース１２３は、例えば、チケットＩＤと暗号鍵との組を記憶する。鍵データベース１２３では、チケットＩＤを検索キーとして、暗号鍵を抽出することが可能である。

メール受付部１３１と、メール解析部１３２と、チケット検索部１３３と、鍵取得部１３４と、復号部１３５と、有効性確認部１３６と、メール加工部１３７と、格納処理部１３８とは、メールの受信と、受信したメールのメールボックス１９への格納とに係る処理を行う、構成要素である。

メール受付部１３１は、ＭＴＡ１５が取り込んだメールを受け付ける。メール受付部１３１は、受け付けたメールを、メール解析部１３２に渡す。

メール解析部１３２は、メール受付部１３１が受け付けたメールを解析する。具体的には、例えば、メール解析部１３２は、メールの送信元と送信先を抽出する。また、メール解析部１３２は、メールが添付ファイルを含むか否かを判定する。

メールが添付ファイルを含む場合、メール解析部１３２は、抽出した送信元および送信先の情報をチケット検索部１３３に送出する。

チケット検索部１３３は、メール解析部１３２から送信元および送信先の情報を受け取り、その送信元および送信先の組をチケット情報として含むチケットを、チケットデータベース１２２から検索する。検索の対象となるチケットがチケットデータベース１２２に存在した場合は、そのチケットのチケットＩＤを抽出する。

鍵取得部１３４は、チケット検索部１３３が検索により抽出したチケットＩＤに関連づけられる（すなわち、該チケットＩＤと組を成す）暗号鍵を、鍵データベース１２３から取得する。鍵取得部１３４は、取得した暗号鍵を復号部１３５に送る。

復号部１３５は、鍵取得部１３４から暗号鍵を受け取り、その暗号鍵を用いてメールの添付ファイルの復号を試みる。添付ファイルを復号できた場合は、配信制御装置１１は、有効性確認部１３６による確認（後述）の後、メール加工部１３７（後述）により、メールの添付ファイルを復号後の添付ファイルに差し替える。

有効性確認部１３６は、復号部１３５による復号が成功した暗号鍵に関連づけられるチケットの有効性を確認（チェック）する。チケットの有効性とは、そのチケットに関連づけられる暗号鍵の有効性である。具体的には、有効性確認部１３６は、該チケットに含まれる復号の条件が満たされるかを確認する。復号の条件が満たされることがすなわち、チケットが有効であるということである。例えば、チケット情報に含まれる復号の条件として、有効期間と添付ファイルのサイズとが指定されている場合、メールの送信時刻がその有効期間に含まれており、かつ、添付ファイルのサイズが申請において指定されたサイズ以下であれば、そのチケットは有効である。

チケットが有効である場合は、有効性確認部１３６は、復号部１３５に添付ファイルを復号させる。

チケットが有効でない場合は、配信制御装置１１は、エラー処理を行う。エラー処理の例は、添付ファイルを削除し、添付ファイルを削除したことを示すメッセージをメールの本文に挿入する処理である。

なお、有効性確認部１３６は、定期的に（例えば毎日決まった時刻に）、または不定期に、有効期間が過ぎたチケットを特定し、そのチケットのチケット情報および暗号鍵を、チケットデータベース１２２および鍵データベース１２３から削除してもよい。

メール加工部１３７は、メールを加工する。メール加工部１３７は、上述のエラー処理や、後述のセキュリティ処理における、メールを加工する処理を担う。

格納処理部１３８は、メールを送信先のユーザのメールボックス１９に格納する処理を行う。

＜動作＞
配信制御装置１１の動作の流れを説明する。

以下の説明では、メールの受信者側であるユーザをユーザＵＡ、ユーザＵＡ宛にファイル付きのメールを送信する者を送信者ＵＢとする。例として、送信者ＵＢは、外部からメールを送信する。すなわち、送信者ＵＢは、メールサーバ４１とは異なるメールサーバを経由するメールを送信する。

［チケットと暗号鍵の生成］
まず、チケットと暗号鍵の生成に係る動作を説明する。

例えば、ユーザＵＡが、外部の送信者ＵＢからメールで添付ファイルを受信することを希望する場合、配信制御装置１１に対してチケットの発行の申請（以下、「チケット発行申請」とも表記）を行う。

例えば、ユーザＵＡは、ユーザ端末２１で、チケット発行申請を行うための画面を開く。チケット発行申請は、アプリケーションプログラムによって行われてもよいし、Ｗｅｂブラウザを通じて行われてもよい。例えば、ユーザ端末２１はＷｅｂを介して配信制御装置にアクセスし、配信制御装置１１が、チケット発行申請を行うための画面をユーザ端末に提供してもよい。

図３は、チケット発行申請を行うための、ユーザＵＡのユーザ端末２１に表示される画面の例である。この画面の例においては、ユーザＵＡは、申請者を特定する情報、送信元のメールアドレス、送信先のメールアドレス、許容する添付ファイルのサイズの上限、チケットの有効期間、チケットの使用（すなわち、復号のための暗号鍵の使用）の回数の制限の指定を入力し、「チケット発行申請」ボタンを押下する。申請者を特定する情報は、例として、申請者が使用するユーザ端末２１のメールアドレスである。

なお、図３の画面は一例であり、画面の構成は様々に設計されてよい。

チケット発行申請を行う形態は、上記の形態に限られない。メールサーバ４１は、所定のフォーマットに基づいて申請事項を記載したメールを受信するのに応じて、チケットを発行する、という構成でもよい。

図４は、ユーザＵＡがチケット発行申請を実行した際の、配信制御装置１１の動作の流れを示すフローチャートである。まず、配信制御装置１１のチケット申請受付部１１１は、チケット発行申請を受け付ける（ステップＳ１１）。そして、チケット申請受付部１１１は、チケット発行申請の内容に、問題があるか否かをチェックする（ステップＳ１２）。

チケット発行申請の内容に問題があるケースとは、例えば、入力された文字が規定のフォーマットに適合しないケース、申請者がチケット発行申請を行う権利を持たない者であるケース、指定された有効期間が過去の期間であるケース、および、ファイルのサイズの上限を指定する数値が不適切である（０以下である等）ケース、等である。

チケット発行申請の内容に問題がある場合は（ステップＳ１３においてＹＥＳ）、チケット申請受付部１１１は、ユーザ端末２１に対してエラー情報を送信する（ステップＳ１７）。例えば、Ｗｅｂブラウザを通じてチケット発行申請が行われる場合、チケット申請受付部１１１は、エラーを示す画面情報をユーザ端末２１に送信すればよい。チケット申請受付部１１１は、メールボックス１９にエラーを示すメールを格納してもよい。

チケット発行申請の内容に問題がない場合は（ステップＳ１３においてＮＯ）、チケット発行部１１２が、その内容に基づき新たなチケットを生成し、生成したチケットのチケット情報をチケットデータベース１２２に登録する（ステップＳ１４）。

図５は、チケットデータベース１２２が記憶するデータのうち、１つのチケットに係るデータの具体例を示す図である。チケットデータベース１２２は、チケットごとに、例えば、チケットＩＤ、申請者、送信元を指定する情報、送信先を指定する情報、添付ファイルのサイズの上限、チケットの有効期間、および回数制限を、１件のレコードとして記憶する。

なお、回数制限は、暗号鍵が復号に使用される回数の上限である。回数制限が「１」である場合、そのチケットに関連づけられる暗号鍵は、いわゆるワンタイムパスワードである。回数制限は設定されずに「なし」（何度でも使用可能であることを意味する）等の値であってもよい。

そして、鍵生成部１１３が、生成されたチケットのチケット情報から暗号鍵を生成する（ステップＳ１５）。例えば、鍵生成部１１３は、チケット情報のうち、送信元と添付ファイルサイズ上限とチケットＩＤとを示す文字列（例として、「ｃｌｉｅｎｔ−ｂ＠ｅｘａｍｐｌｅ．ｃｏｍ５０ＭＢ０００００００００１」）を使用して、暗号鍵を生成する既知の方法によって、暗号鍵を生成してもよい。例えば、暗号鍵は、上記文字列のハッシュ値でもよい。鍵生成部１１３は、生成した暗号鍵を、その暗号鍵の基となったチケットＩＤと共に鍵データベース１２３に登録する。図６は、鍵データベース１２３が記憶するデータの具体例を示す図である。この例では、暗号化のための暗号鍵と復号のための暗号鍵は同じであるとする。

鍵生成部１１３は、生成した暗号鍵を申請者に通知する（ステップＳ１６）。Ｗｅｂブラウザを通じてチケット発行申請が行われる場合、鍵生成部１１３は、暗号鍵、または暗号鍵の所在（暗号鍵をダウンロードできるページへのリンク）を表示する画面情報を、申請者であるユーザ端末２１に送信してもよい。

鍵生成部１１３は、申請者宛のメールが格納されるメールボックス１９に、暗号鍵または暗号鍵の所在を記載した申請者宛のメールを、格納してもよい。

ユーザＵＡは、暗号鍵を通知されると、その暗号鍵を送信者ＵＢに伝える。暗号鍵を送信者ＵＢに伝える方法は任意である。ユーザＵＡは、暗号鍵、または暗号鍵の所在（暗号鍵をダウンロードできるページへのリンク）を記載したメール等を、送信者ＵＢ宛に送信してもよい。ユーザＵＡは、メール以外の、メッセージを送る方法で、暗号鍵を送信者ＵＢに送ってもよい。

送信者ＵＢは、伝えられた暗号鍵を用いて、ユーザＵＡに送信したいファイルを暗号化する。そして、送信者ＵＢは、暗号化されたファイルをメールに添付して、そのメールをユーザＵＡ宛に送信する。送信されたメールは通信ネットワーク８を介してメールサーバ４１に到達する。

［添付ファイル付きメールの受信］
次に、添付ファイル付きメールの受信に係る動作を、図７のフローチャートを参照しながら説明する。

メールサーバ４１のＭＴＡ１５は、メールを取り込むと、取り込んだメールを配信制御装置１１に送る。配信制御装置１１において、メール受付部１３１がメールを受け取ると、メール解析部１３２が、受信したメールから送信元および送信先を取得する（ステップＳ２１）。例えば、メール解析部１３２は、メールのヘッダにおける、「Ｆｒｏｍ」の項目に記載される情報を送信元のメールアドレスとして取得し、「Ｔｏ」の項目に記載される情報を送信先のメールアドレスとして取得すればよい。

また、メール解析部１３２は、そのメールに添付ファイルがあるかを確認する。添付ファイルがない場合（ステップＳ２２においてＮＯ）、格納処理部１３８が、受信したメールをメールボックス１９に格納する（ステップＳ２７）。添付ファイルがある場合（ステップＳ２２においてＹＥＳ）、メール解析部１３２は、その添付ファイルが暗号化されているかを確認する（ステップＳ２３）。

添付ファイルが暗号化されていない場合、配信制御装置１１は、後述のセキュリティ処理を行う（ステップＳ２８）。

添付ファイルが暗号化されている場合（ステップＳ２３においてＹＥＳ）、チケット検索部１３３が、取得した送信先および送信元をチケット情報として含むチケットを、チケットデータベース１２２から検索する（ステップＳ２４）。検索の結果、検索条件を満たす（すなわち、取得した送信先および送信元をチケット情報として含む）チケットが見つかった場合（ステップＳ２５においてＹＥＳ）、鍵取得部１３４と復号部１３５とが、添付ファイルの復号処理を行う（ステップＳ２６）。添付ファイルの復号処理の詳細については後述する。検索条件を満たすチケットが見つからなかった場合（ステップＳ２５においてＮＯ）、配信制御装置１１は、セキュリティ処理を行う（ステップＳ２８）。

ステップＳ２８のセキュリティ処理では、例えば、メール加工部１３７が、添付ファイルを削除し、添付ファイルを削除したことを示す通知文をメールの本文に挿入する。そして、格納処理部１３８が、そのメールをユーザＵＡのメールボックス１９に格納する。これにより、暗号化されていない、または、復号できない、（すなわち、チケットデータベース１２２に記憶されているチケットに適合しない、）添付ファイルが開かれることが抑止される。また、ユーザＵＡは、チケットに適合しない添付ファイルが送られてきたことを知る。

［添付ファイルの復号処理］
ステップＳ２６の添付ファイルの復号処理について、図８を参照しながら詳述する。図８は、添付ファイルの復号処理の詳細な具体例を示すフローチャートである。

配信制御装置１１は、鍵取得部１３４と復号部１３５とにより、ステップＳ２４の検索により見つかったチケット（以下、「対象のチケット」と表記）について、ステップＳ３３の判定がＹＥＳであるチケットが見つかるか、または全てのチケットについてステップＳ３３の判定がＮＯであることがわかるまで、順次、ステップＳ３１からステップＳ３３の処理を行う。

ステップＳ３１では、鍵取得部１３４が、対象のチケットのチケットＩＤを用いて、鍵データベース１２３から、対象のチケットに関連づけられる暗号鍵を読み出す。そして、ステップＳ３２では、復号部１３５が、読み出した暗号鍵を用いた添付ファイルの復号を試みる。

復号は、必ずしも成功するとは限らない。復号部１３５は、復号に成功したか（言い換えれば、復号が可能であるか）のチェックを行う。チェックの方法は、既知の方法（例えば、復号により生成されるデータを解析する等）でよい。

復号が可能であった場合（ステップＳ３３においてＹＥＳ）、処理はステップＳ３４へ移る。この場合、以後、他のチケットについて、ステップＳ３１からステップＳ３３の処理を行う必要はない。

復号が可能でない場合（ステップＳ３３においてＮＯ）、配信制御装置１１は、そのチケットを対象のチケットから除外する。配信制御装置１１は、他の対象のチケットについて、ステップＳ３１からステップＳ３３の処理を行う。対象のチケットがなくなった場合（すなわち、対象のチケットに関連づけられるいずれの暗号鍵も、添付ファイルを復号可能でなかった場合）、配信制御装置１１はエラー処理を行って（ステップＳ４１）、動作は終了する。

ステップＳ４１のエラー処理では、例えば、メール加工部１３７が、添付ファイルを復号できなかったことを示す通知文をメールの本文に挿入する。そして、格納処理部１３８が、そのメールをユーザＵＡのメールボックス１９に格納する。これにより、ユーザＵＡは、復号できない（すなわち、チケットデータベース１２２に記憶されているチケットに適合しない）添付ファイルが送られてきたことを知る。メール加工部１３７は、添付ファイルを削除してもよい。

ステップＳ３４では、有効性確認部１３６が、添付ファイルの復号が可能な暗号鍵が関連づけられたチケットの有効性を確認する。

チケットが有効である場合（ステップＳ３５においてＹＥＳ）、復号部１３５は、添付ファイルを復号する（ステップＳ３６）。そして、格納処理部１３８が、復号後の添付ファイルを含む受信メールをメールボックス１９に格納する（ステップＳ３７）。これにより、ユーザＵＡは、復号済みの添付ファイルを含むメールを閲覧することができる。

チケットが有効でない場合（ステップＳ３５においてＮＯ）、配信制御装置１１は、エラー処理を行う（ステップＳ４２）。

ステップＳ４２のエラー処理では、例えば、メール加工部１３７が、添付ファイルを削除し、添付ファイルを復号する暗号鍵に関連づけられたチケットが有効でないことを示す通知文をメールの本文に挿入する。そして、格納処理部１３８が、そのメールをユーザＵＡのメールボックス１９に格納する。これにより、ユーザＵＡは、有効でないチケットに関連づけられた暗号鍵で暗号化されたファイルが送られてきたことを知る。

ステップＳ３７の処理が行われる場合は、有効性確認部１３６は、チケットデータベース１２２において記憶される、該チケットの「回数制限」の値を、１減らす（ステップＳ３８）。ただし、「回数制限」の値が「なし」である場合は、有効性確認部１３６は値を変更しなくてよい。ステップＳ３８の処理によって「回数制限」の値が０になった場合（ステップＳ３９においてＹＥＳ）は、有効性確認部１３６は、該チケット情報および暗号鍵を、チケットデータベース１２２および鍵データベース１２３から削除する（ステップＳ４０）。

なお、ステップＳ３８からステップＳ４０の処理は、ステップＳ３７の処理の前に行われてもよい。

以上のような動作の流れにより、添付ファイルの復号処理は完了する。

＜効果＞
第１の実施形態に係るメール通信システム１によれば、暗号化されていない添付ファイル、鍵データベース１２３に記憶された暗号鍵で復号できない添付ファイル、および、申請されたチケットのチケット情報に適合しないメールの添付ファイルを、受信者が開いたり閲覧したりすることが、エラー処理またはセキュリティ処理により、抑制される。

すなわち、復号される添付ファイルの送信者は、次の両方に該当する者に限られる。
・チケット発行申請に基づいて生成されたチケットに関連づけられた暗号鍵を知っている者
・チケットにおいて指定されている送信元の情報に適合するメールアドレスを、ファイルが添付されたメールの送信元として設定している者
少なくとも、暗号鍵が漏えいしない限り、受信者は安全に添付ファイルを受け取ることができる。また、暗号鍵の更新は容易であるため、頻繁に更新を行うことで漏えいのリスクを容易に軽減することができる。

そして、暗号鍵が漏えいしたとしても、送信元（Ｆｒｏｍ）のメールアドレスが偽装されない限り、第三者からの添付ファイルは復号化されず、受信者に届かない。メール通信システム１は、特許文献１に記載されるような、チケットメールの返信を条件とする構成ではないため、暗号鍵の漏えいと送信元のメールアドレスの漏えいとが同時に起こるリスクを低減することができる。例えば、暗号鍵を、送信元のメールアドレスとは別の連絡先に通知することで、リスクを分散できる。

さらに、チケットに条件が設定されることにより、なりすましが行われたメールの添付ファイルが受信者により開かれるリスクをさらに低減することができる。添付ファイルのサイズや有効期間等が細かく設定されるほど、復号の条件を満たすメールを第三者が作成することはより困難となる。

また、暗号化された添付ファイルは、通常、一般的なウイルス対策ではチェックの対象外となるが、本実施形態では、暗号化された添付ファイルは復号されてからメールボックスに格納されるため、一般的なウイルス対策が適用可能である。

このように、メール通信システム１では、メールの受信者の安全が保障される。

また、添付ファイルは、送信者側から受信者側のメールサーバまでの経路において、暗号化された状態で通信されるため、機密性が保障される。

他の効果として、メールの誤送信によるリスクを低減することができる。例えば、送信者が宛先を誤ってメールを送信してしまった場合に、メールを受信した人は添付ファイルを復号できないため、意図しない相手に添付ファイルを閲覧されることを防ぐことができる。

以上のように、メール通信システム１では、安全性および機密性が、低コストで保障される。言い換えれば、ユーザは、添付ファイルの安全なやりとりを簡易に行える。

＜＜変形例＞＞
［変形例１］
チケット情報のうち、送信元の情報として、メールアドレスの代わりにメールアドレスのドメイン名が指定されてもよい。そのような構成では、特定のメールアドレスのユーザからのメールではなく、特定のドメイン名を有するメールアドレスのユーザからのメールの、添付ファイルが復号される。

［変形例２］
チケット発行部１１２は、チケット発行申請における、送信先を指定する情報が、ＭＴＡ１５が取り込む対象であるメールアドレスまたはドメイン名である場合のみ、チケットを発行するよう、構成されていてもよい。チケット申請受付部１１１が、ＭＴＡ１５が取り込む対象であるメールアドレスまたはドメイン名を送信先として指定するチケット発行申請のみ受け付けるよう構成されていてもよい。すなわち、チケット申請受付部１１１は、ＭＴＡ１５が取り込む対象であるメールアドレスまたはドメイン名を送信先として指定していないチケット発行申請を拒否してもよい。

［変形例３］
暗号鍵を送信者ＵＢに伝える方法は任意であるが、配信制御装置１１が送信者ＵＢに暗号鍵を伝えるよう構成されていてもよい。例えば、配信制御装置１１は、図９に示される配信制御装置１１ａのように、暗号鍵を送信者ＵＢに通知する暗号鍵通知部１１４を備えてもよい。暗号鍵通知部１１４は、例えば、チケット情報において「送信元」として指定されたメールアドレス宛に、鍵生成部１１３が生成した暗号鍵または暗号鍵の所在を記載したメールを発信してもよい。そのような構成によれば、チケット発行申請を行った者が、わざわざ暗号鍵を伝達する必要がなくなる。

［変形例４］
チケット発行申請における、復号の条件の他の例を挙げる。

例えば、復号の条件として、メールの件名または本文に含まれる文字列、送信された時刻、経由すべきサーバ、経由すべきでないサーバ、添付ファイルの数、添付ファイルの種類、等々に関する条件が採用されてもよい。

［変形例５］
暗号鍵の生成方法が、再現性がある方法であれば、暗号鍵自体を記憶しておかなくてもよい。つまり、配信制御装置１１は、鍵データベース１２３を備えていなくてもよい。暗号鍵を生成するための情報を記憶しておけば、その情報に基づいて暗号鍵をいつでも生成可能である。この場合、ステップＳ３１の処理は「暗号鍵を生成するための情報から復号のための暗号鍵を生成する」という処理に、ステップＳ３２の処理は「生成された暗号鍵を用いた復号を試みる」という処理に、それぞれ変更されればよい。暗号鍵がデータベースに記録されないことで、暗号鍵が盗まれるリスクを低減することができる。

＜＜第２の実施形態＞＞
本発明の第２の実施形態は、ユーザ端末が、第１の実施形態の配信制御装置１１と同様の機能を備える形態である。

図１０は、第２の実施形態に係るユーザ端末２２の構成を示すブロック図である。ユーザ端末２２は、第１の実施形態の配信制御装置１１と同様に、チケット申請受付部１１１、チケット発行部１１２、鍵生成部１１３、チケットデータベース１２２、鍵データベース１２３、メール受付部１３１、メール解析部１３２、チケット検索部１３３、鍵取得部１３４、復号部１３５、有効性確認部１３６、メール加工部１３７、および格納処理部１３８を備える。これらの部は、ユーザ端末２２のプロセッサが所定のアプリケーションプログラムを実行することにより実現されてもよい。

また、ユーザ端末２２は、通信部２２０と、メールボックス２９と、表示制御部２２１と、表示部２２２と、を備える。表示部２２２は、液晶パネル等、画像を出力するハードウェアである。変形例として、表示部２２２はユーザ端末２２の外部に、ユーザ端末２２に接続される形態で存在する装置であってもよい。

通信部２２０は、他の装置から、ユーザ端末２２が使用するメールアドレス宛のメールを受信する。通信部２２０は、受信したメールをメール受付部１３１に渡す。

メールボックス２９は、メールを記憶する。メールボックス２９は、格納処理部１３８からメール（添付ファイルを含んでいてもよい）を受け取り、そのメールを記憶する。

表示制御部２２１は、表示部２２２に表示させる画面（画像）を制御する。表示制御部２２１は、たとえば、チケット発行申請を行うための画面、生成された鍵を表示する画面、メールボックスを閲覧するための画面等を、表示部２２２に表示させる。

配信制御装置１１が備える構成要素と同じ構成要素の機能は、配信制御装置１１における機能と同一でよい。ただし、チケット申請受付部１１１は、ユーザ端末２２に対する直接の入力操作を受け付けることにより、チケット発行申請を受け付ければよい。また、チケット発行申請における「申請者」および「送信先」の欄で指定される情報は、このユーザ端末２２が使用するメールアドレスであることは既に決まっていてよく、この情報の入力は省略されてもよい。

このような構成によっても、第１の実施形態と同じ効果が得られる。

＜＜第３の実施形態＞＞
本発明の一実施形態に係る配信制御装置１０について説明する。

図１１は、配信制御装置１０の構成を示すブロック図である。

配信制御装置１０は、受付部１０１と、鍵生成部１０２と、復号部１０３と、格納処理部１０４と、を備える。

受付部１０１は、特定のメールアドレスに関連づけられる端末から、鍵生成依頼を受け付ける。

特定のメールアドレスに関連づけられる端末とは、特定のメールアドレスの使用のもと、メールの送受信を行う端末である。特定のメールアドレスに関連づけられる端末は、例えば、特定のメールアドレス宛のメールを記憶するメールボックスから、メールを取得して該メールを表示したり、送信元の情報（Ｆｒｏｍに記載される情報）が特定のメールアドレスであるようなメールを送信したりする。

鍵生成依頼は、鍵を生成する依頼である。上記各実施形態のチケット発行申請は、鍵生成依頼の一例である。鍵生成依頼は、上記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む。指定された送信元および送信先は、復号部１０３が復号処理を行う際に用いる暗号鍵を取得する際に使用される。なお、「メールアドレスの情報」とは、例えば、メールアドレスそれ自体、または、メールアドレスの一部（例えば、ドメイン名）である。

受付部１０１は、送信先として指定する情報が、上記特定のメールアドレス、または上記特定のメールアドレスのドメイン名である、鍵生成依頼のみを受け付けるよう、構成されていてもよい。

なお、第１の実施形態のチケット申請受付部１１１は、受付部１０１の一例である。

鍵生成部１０２は、受け付けられた鍵生成依頼に応じて、少なくとも指定された送信元と送信先との組に関連づけられる暗号鍵を生成する。暗号鍵は、指定された送信元と送信先との組の他、復号の条件を示す情報とも関連づけられてもよい。鍵生成部１０２は、受け付けられた鍵生成依頼ごとに異なる暗号鍵を生成してもよい。

第１の実施形態の鍵生成部１１３は、鍵生成部１０２の一例である。

復号部１０３は、暗号化された添付ファイルを含むメールが受信された場合に、そのメールの送信元と送信先との組に関連づけられる暗号鍵を用いて、添付ファイルを復号する（すなわち、添付ファイルの暗号化を解除する）ための復号処理を行う。第１の実施形態の復号部１３５は、復号部１０３の一例である。

なお、復号処理により添付ファイルの復号が成功しない場合があってもよい。添付ファイルの復号が成功しなかった場合は、そのメールの受信者が添付ファイルを開くことを抑制するためのメールの加工（例えば、添付ファイルの削除、件名や本文への注意書きの挿入等）が行われてもよい。第１の実施形態のメール加工部１３７は、そのような加工を行う部の例である。

格納処理部１０４は、復号部１０３により復号された復号後の添付ファイルを含むメールを、そのメールの送信先に関連づけられるメールボックス（言い換えれば、そのメールの送信先に記載されるメールアドレス宛のメールを記憶するためのメールボックス）に格納する処理を行う。これにより、そのメールの受信者（すなわち、そのメールの送信先のメールアドレスに関連づけられる端末を使用する者）が、復号後の添付ファイルを開くことが可能な状態になる。

第１の実施形態の格納処理部１３８は、格納処理部１０４の一例である。

図１２は、配信制御装置１０の動作の流れを示すフローチャートである。

まず、受付部１０１が、特定のメールアドレスに関連づけられる端末から、鍵生成依頼を受け付ける（ステップＳ１０１）。

次に、鍵生成部１０２が、受け付けられた鍵生成依頼に応じて、少なくとも指定された送信元と送信先との組に関連づけられる暗号鍵を生成する（ステップＳ１０２）。

そして、復号部１０３が、暗号化された添付ファイルを含むメールが受信された場合に、復号処理を行う（ステップＳ１０３）。

そして、格納処理部１０４が、復号された復号後の添付ファイルを含むメールを、そのメールの送信先に関連づけられるメールボックスに格納する処理を行う（ステップＳ１０４）。

配信制御装置１０によれば、添付ファイルの安全なやりとりを、簡易に行うことができる。その理由は、特定のメールアドレスに関連づけられる端末により指定された送信先が、鍵生成部１０２により生成された暗号鍵を用いてファイルを暗号化すれば、そのファイルが通信経路の途中で盗み見られることを防止できるからである。そして、復号部１０３が用いる暗号鍵は指定された送信元と送信先との組に関連づけられる暗号鍵であることから、ファイルの復号ができた場合、そのファイルは鍵生成依頼にて指定された送信先からのファイルであることが保障されるからである。また、暗号鍵は鍵生成依頼に応じて生成されるため、暗号鍵が漏えいするリスクが低い。さらに、暗号鍵に復号の条件（有効期間等）が関連づけられれば、第三者によるなりすましの被害を受けるリスクをさらに低減することができる。

＜＜第４の実施形態＞＞
本発明の一実施形態に係る端末２０について説明する。第２の実施形態のユーザ端末２２が、端末２０の一例である。

図１３は、端末２０の構成を示すブロック図である。

端末２０は、通信部２００と、受付部２０１と、鍵生成部２０２と、復号部２０３と、メール記憶部２０４と、を備える。

通信部２００は、特定のメールアドレス宛のメールを受信する。第２の実施形態の通信部２２０は、通信部２００の一例である。

受付部２０１は、鍵生成依頼を、ユーザインタフェースを介して受け付ける。鍵生成依頼は、特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報を含む。第２の実施形態のチケット申請受付部１１１は、受付部２０１の一例である。

鍵生成部２０２は、受け付けられた前記鍵生成依頼に応じて、少なくとも指定された送信先に関連づけられる暗号鍵を生成する。第２の実施形態の鍵生成部１１３は、鍵生成部２０２の一例である。

復号部２０３は、暗号化された添付ファイルを含むメールが受信された場合に、そのメールの送信元と送信先との組に関連づけられる暗号鍵を用いて、添付ファイルを復号するための復号処理を行う。第２の実施形態の復号部１３５は、復号部２０３の一例である。

メール記憶部２０４は、復号された復号後の添付ファイルを含むメールを記憶する。第２の実施形態のメールボックス２９は、メール記憶部２０４の一例である。

図１４は、端末２０の動作の流れを示すフローチャートである。

まず、受付部２０１は、鍵生成依頼を、ユーザインタフェースを介して受け付ける（ステップＳ２０１）。

そして、鍵生成部２０２は、受け付けられた前記鍵生成依頼に応じて、少なくとも指定された送信先に関連づけられる暗号鍵を生成する（ステップＳ２０２）。

そして、通信部２００が暗号化された添付ファイルを含むメールを受信する（ステップＳ２０３）と、復号部２０３が、そのメールの送信元と送信先との組に関連づけられる暗号鍵を用いて、添付ファイルを復号するための復号処理を行う（ステップＳ２０４）。

そして、メール記憶部２０４が、復号された復号後の添付ファイルを含むメールを記憶する（ステップＳ２０５）。

端末２０によれば、添付ファイルの安全なやりとりを、簡易に行うことができる。その理由は、第３の実施形態で説明した理由と同様である。

＜実施形態の各部を実現するハードウェアの構成＞
以上で説明された本発明の各実施形態において、各装置の各構成要素を示すブロックは、機能単位で示されている。しかし、構成要素を示すブロックは、各構成要素が別個のモジュールにより構成されることを必ずしも意味していない。

各構成要素の処理は、たとえば、コンピュータシステムが、コンピュータ読み取り可能な記憶媒体により記憶された、その処理をコンピュータシステムに実行させるプログラムを、読み出し、実行することによって、実現されてもよい。「コンピュータ読み取り可能な記憶媒体」は、たとえば、光ディスク、磁気ディスク、光磁気ディスク、および不揮発性半導体メモリ等の可搬媒体、ならびに、コンピュータシステムに内蔵されるＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）およびハードディスク等の記憶装置である。「コンピュータ読み取り可能な記憶媒体」は、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントにあたるコンピュータシステム内部の揮発性メモリのように、プログラムを一時的に保持しているものも含む。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、更に前述した機能をコンピュータシステムにすでに記憶されているプログラムとの組み合わせで実現できるものであってもよい。

「コンピュータシステム」とは、一例として、図１５に示されるようなコンピュータ９００を含むシステムである。コンピュータ９００は、以下のような構成を含む。
・１つまたは複数のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１
・ＲＯＭ９０２
・ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０３
・ＲＡＭ９０３へロードされるプログラム９０４Ａおよび記憶情報９０４Ｂ
・プログラム９０４Ａおよび記憶情報９０４Ｂを格納する記憶装置９０５
・記憶媒体９０６の読み書きを行うドライブ装置９０７
・通信ネットワーク９０９と接続する通信インタフェース９０８
・データの入出力を行う入出力インタフェース９１０
・各構成要素を接続するバス９１１

たとえば、各実施形態における各装置の各構成要素は、その構成要素の機能を実現するプログラム９０４ＡをＣＰＵ９０１がＲＡＭ９０３にロードして実行することで実現される。各装置の各構成要素の機能を実現するプログラム９０４Ａは、例えば、予め、記憶装置９０５やＲＯＭ９０２に格納される。そして、必要に応じてＣＰＵ９０１がプログラム９０４Ａを読み出す。記憶装置９０５は、たとえば、ハードディスクである。プログラム９０４Ａは、通信ネットワーク９０９を介してＣＰＵ９０１に供給されてもよいし、予め記憶媒体９０６に格納されており、ドライブ装置９０７に読み出され、ＣＰＵ９０１に供給されてもよい。なお、記憶媒体９０６は、たとえば、光ディスク、磁気ディスク、光磁気ディスク、および不揮発性半導体メモリ等の、可搬媒体である。

各装置の実現方法には、様々な変形例がある。例えば、各装置は、構成要素毎にそれぞれ別個のコンピュータ９００とプログラムとの可能な組み合わせにより実現されてもよい。また、各装置が備える複数の構成要素が、一つのコンピュータ９００とプログラムとの可能な組み合わせにより実現されてもよい。

また、各装置の各構成要素の一部または全部は、その他の汎用または専用の回路、コンピュータ等やこれらの組み合わせによって実現されてもよい。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。

各装置の各構成要素の一部または全部が複数のコンピュータや回路等により実現される場合には、複数のコンピュータや回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、コンピュータや回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

本願発明は以上に説明した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

上記実施形態の一部または全部は以下の付記のようにも記載され得るが、以下には限られない。

＜＜付記＞＞
［付記１］
特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付手段と、
受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成手段と、
暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号手段と、
前記復号手段により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理手段と、
を備える、配信制御装置。
［付記２］
前記鍵生成依頼は復号の条件を指定する情報を含み、
前記配信制御装置は、
前記暗号鍵に関連づけられる前記条件を、記憶手段に記憶させる記憶制御手段と、
前記添付ファイルを復号可能である前記暗号鍵に関連づけられている前記条件が満たされるかを確認する有効性確認手段と、
前記条件が満たされない場合、前記メールの受信者が当該添付ファイルを開くことを抑制するための前記メールの加工を行うメール加工手段と、
をさらに備える、付記１に記載の配信制御装置。
［付記３］
前記メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて前記添付ファイルを復号できない場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工手段を、さらに備える、付記１に記載の配信制御装置。
［付記４］
暗号化されていない添付ファイルを含むメールが受信された場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工手段を、さらに備える、付記１に記載の配信制御装置。
［付記５］
前記記憶制御手段は、前記暗号鍵ごとに、当該暗号鍵の生成に使用された情報を、前記記憶手段に記憶させ、
前記復号手段は、前記暗号鍵の生成に使用された情報に基づいて再生成されることにより取得された前記暗号鍵を用いて、前記復号処理を行う、
付記２に記載の配信制御装置。
［付記６］
前記受付手段は、送信先として指定する情報が、前記特定のメールアドレス、または前記特定のメールアドレスのドメイン名である、前記鍵生成依頼のみを受け付ける、付記１から５のいずれか一つに記載の配信制御装置。
［付記７］
付記１から６のいずれか一つに記載の前記配信制御装置と、
前記特定のメールアドレスのドメイン名を含むメールアドレス宛のメールを受信して、受信した前記メールを前記配信制御装置に渡すＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）と、
前記メールボックスと、
を含むメールサーバ。
［付記８］
特定のメールアドレス宛のメールを受信する通信手段と、
前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報を含む、鍵生成依頼を、ユーザインタフェースを介して受け付ける受付手段と、
受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信先に関連づけられる暗号鍵を生成する鍵生成手段と、
暗号化された添付ファイルを含む前記メールが受信された場合に、当該メールの送信先に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号手段と、
前記復号手段により復号された復号後の添付ファイルを含む前記メールを記憶するメール記憶手段と、
を備える、端末。
［付記９］
前記鍵生成依頼は復号の条件を指定する情報を含み、
前記端末は、
前記暗号鍵に関連づけられる前記条件を、記憶手段に記憶させる記憶制御手段と、
前記添付ファイルを復号可能である前記暗号鍵に関連づけられている前記条件が満たされるかを確認する有効性確認手段と、
前記条件が満たされない場合、前記端末の使用者が当該添付ファイルを開くことを抑制するための前記メールの加工を行うメール加工手段と、
をさらに備える、付記８に記載の端末。
［付記１０］
前記メールの送信先に関連づけられる前記暗号鍵を用いて前記添付ファイルを復号できない場合に、前記端末の使用者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工手段を、さらに備える、付記８に記載の端末。
［付記１１］
暗号化されていない添付ファイルを含むメールが受信された場合に、前記端末の使用者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工手段を、さらに備える、付記８に記載の端末。
［付記１２］
前記記憶制御手段は、前記暗号鍵ごとに、当該暗号鍵の生成に使用された情報を、前記記憶手段に記憶させ、
前記復号手段は、前記暗号鍵の生成に使用された情報に基づいて再生成されることにより取得された前記暗号鍵を用いて、前記復号処理を行う、
付記９に記載の端末。
［付記１３］
特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付け、
受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成し、
暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行い、
復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う、
配信制御方法。
［付記１４］
前記鍵生成依頼は復号の条件を指定する情報を含み、
前記暗号鍵に関連づけられる前記条件を、記憶手段に記憶させ、
前記添付ファイルを復号可能である前記暗号鍵に関連づけられている前記条件が満たされるかを確認し、
前記条件が満たされない場合、前記メールの受信者が当該添付ファイルを開くことを抑制するための前記メールの加工を行う、
付記１３に記載の配信制御方法。
［付記１５］
前記メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて前記添付ファイルを復号できない場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行う、付記１３に記載の配信制御方法。
［付記１６］
暗号化されていない添付ファイルを含むメールが受信された場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行う、付記１３に記載の配信制御方法。
［付記１７］
前記暗号鍵ごとに、当該暗号鍵の生成に使用された情報を、前記記憶手段に記憶させ、
前記暗号鍵の生成に使用された情報に基づいて再生成されることにより取得された前記暗号鍵を用いて、前記復号処理を行う、
付記１４に記載の配信制御方法。
［付記１８］
送信先として指定する情報が、前記特定のメールアドレス、または前記特定のメールアドレスのドメイン名である、前記鍵生成依頼のみを受け付ける、付記１３から１７のいずれか一つに記載の配信制御方法。
［付記１９］
特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付処理と、
受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成処理と、
暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための処理である復号処理と、
前記復号処理により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理と、
をコンピュータに実行させるプログラム。
［付記２０］
前記鍵生成依頼は復号の条件を指定する情報を含み、
前記プログラムは、
前記暗号鍵に関連づけられる前記条件を、記憶手段に記憶させる記憶制御処理と、
前記添付ファイルを復号可能である前記暗号鍵に関連づけられている前記条件が満たされるかを確認する有効性確認処理と、
前記条件が満たされない場合、前記メールの受信者が当該添付ファイルを開くことを抑制するための前記メールの加工を行うメール加工処理と、
をコンピュータにさらに実行させる、付記１９に記載のプログラム。
［付記２１］
前記メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて前記添付ファイルを復号できない場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工処理を、コンピュータにさらに実行させる、付記１９に記載のプログラム。
［付記２２］
暗号化されていない添付ファイルを含むメールが受信された場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工処理を、コンピュータにさらに実行させる、付記１９に記載のプログラム。
［付記２３］
前記記憶制御処理は、前記鍵情報として、当該暗号鍵の生成に使用された情報を、前記記憶手段に記憶させ、
前記復号処理は、前記鍵情報に基づいて再生成されることにより取得された前記暗号鍵を用いる、
付記２０に記載のプログラム。
［付記２４］
前記受付処理は、送信先として指定する情報が、前記特定のメールアドレス、または前記特定のメールアドレスのドメイン名である、前記鍵生成依頼のみを受け付ける、付記１９から２３のいずれか一つに記載のプログラム。
［付記２５］
特定のメールアドレス宛のメールを受信する通信処理と、
前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報を含む、鍵生成依頼を、ユーザインタフェースを介して受け付ける受付処理と、
受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信先に関連づけられる暗号鍵を生成する鍵生成処理と、
暗号化された添付ファイルを含む前記メールが受信された場合に、当該メールの送信先に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための処理である復号処理と、
前記復号処理により復号された復号後の添付ファイルを含む前記メールを記憶するメール記憶処理と、
をコンピュータに実行させるプログラム。

本願発明は以上に説明した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１ メール通信システム
８ 通信ネットワーク
１０、１１、１１ａ 配信制御装置
１５、２５ ＭＴＡ
１９、２９ メールボックス
２０ 端末
２１、２２ ユーザ端末
４１、４１ａ メールサーバ
１０１ 受付部
１０２ 鍵生成部
１０３ 復号部
１０４ 格納処理部
１１１ チケット申請受付部
１１２ チケット発行部
１１３ 鍵生成部
１２２ チケットデータベース
１２３ 鍵データベース
１３１ メール受付部
１３２ メール解析部
１３３ チケット検索部
１３４ 鍵取得部
１３５ 復号部
１３６ 有効性確認部
１３７ メール加工部
１３８ 格納処理部
２００、２２０ 通信部
２０１ 受付部
２０２ 鍵生成部
２０３ 復号部
２０４ メール記憶部
２２１ 表示制御部
２２２ 表示部
９００ コンピュータ
９０１ ＣＰＵ
９０２ ＲＯＭ
９０３ ＲＡＭ
９０４Ａ プログラム
９０４Ｂ 記憶情報
９０５ 記憶装置
９０６ 記憶媒体
９０７ ドライブ装置
９０８ 通信インタフェース
９０９ 通信ネットワーク
９１０ 入出力インタフェース
９１１ バス

Claims (10)

1. 特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付手段と、
   受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成手段と、
   暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号手段と、
   前記復号手段により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理手段と、
   を備える、配信制御装置。
2. 前記鍵生成依頼は復号の条件を指定する情報を含み、
   前記配信制御装置は、
   前記暗号鍵に関連づけられる前記条件を、記憶手段に記憶させる記憶制御手段と、
   前記添付ファイルを復号可能である前記暗号鍵に関連づけられている前記条件が満たされるかを確認する有効性確認手段と、
   前記条件が満たされない場合、前記メールの受信者が当該添付ファイルを開くことを抑制するための前記メールの加工を行うメール加工手段と、
   をさらに備える、請求項１に記載の配信制御装置。
3. 前記メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて前記添付ファイルを復号できない場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工手段を、さらに備える、請求項１に記載の配信制御装置。
4. 暗号化されていない添付ファイルを含むメールが受信された場合に、前記メールの受信者が当該添付ファイルを開くことを抑制するための当該メールの加工を行うメール加工手段を、さらに備える、請求項１に記載の配信制御装置。
5. 前記記憶制御手段は、前記暗号鍵ごとに、当該暗号鍵の生成に使用された情報を、前記記憶手段に記憶させ、
   前記復号手段は、前記暗号鍵の生成に使用された情報に基づいて再生成されることにより取得された前記暗号鍵を用いて、前記復号処理を行う、
   請求項２に記載の配信制御装置。
6. 前記受付手段は、送信先として指定する情報が、前記特定のメールアドレス、または前記特定のメールアドレスのドメイン名である、前記鍵生成依頼のみを受け付ける、請求項１から５のいずれか一項に記載の配信制御装置。
7. 請求項１から６のいずれか一項に記載の前記配信制御装置と、
   前記特定のメールアドレスのドメイン名を含むメールアドレス宛のメールを受信して、受信した前記メールを前記配信制御装置に渡すＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）と、
   前記メールボックスと、
   を含むメールサーバ。
8. 特定のメールアドレス宛のメールを受信する通信手段と、
   前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報を含む、鍵生成依頼を、ユーザインタフェースを介して受け付ける受付手段と、
   受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信先に関連づけられる暗号鍵を生成する鍵生成手段と、
   暗号化された添付ファイルを含む前記メールが受信された場合に、当該メールの送信先に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号手段と、
   前記復号手段により復号された復号後の添付ファイルを含む前記メールを記憶するメール記憶手段と、
   を備える、端末。
9. 特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付け、
   受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成し、
   暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行い、
   復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う、
   配信制御方法。
10. 特定のメールアドレスに関連づけられる端末から、前記特定のメールアドレス以外のメールアドレスの情報を送信元として指定する情報と、送信先を指定する情報とを含む、鍵生成依頼を受け付ける受付処理と、
    受け付けられた前記鍵生成依頼に応じて、少なくとも前記指定された送信元と送信先との組に関連づけられる暗号鍵を生成する鍵生成処理と、
    暗号化された添付ファイルを含むメールが受信された場合に、当該メールの送信元と送信先との組に関連づけられる前記暗号鍵を用いて、前記添付ファイルを復号するための復号処理を行う復号処理と、
    前記復号手段により復号された復号後の添付ファイルを含む前記メールを、当該メールの送信先に関連づけられるメールボックスに格納する処理を行う格納処理と、
    をコンピュータに実行させるプログラム。

Images