JP2009163525A - 電子メール送信方法 - Google Patents

Abstract

【課題】電子メールに添付するファイルへのアクセス権・暗号化と、当該ファイルの送信を一連の流れとして実施する機能を有する装置を提供する。
【解決手段】メール発信者がメール発信者の端末のメーラからメールを発信し((A)メール作成/発信機能)、当該メールの添付ファイルに対し閲覧権限を設定と暗号化を行い((B)ファイル暗号化機能)、閲覧権限をより制御するための閲覧者制御機能と((C)ユーザ情報登録照会機、(E)ユーザ情報登録機能)と、添付ファイル制御設定時のエラー処理((D)エラー処理機能)と、暗号化された添付ファイルを復号化する処理（(F)添付ファイル復号機能）を実行することで上記の課題を解決する連携する手段を提供する。
【選択図】図１２

Description

本発明は電子メールシステムに関し、特に電子メールの添付ファイルのアクセス制御に関する。

現在、コンピュータ装置における情報漏洩などの問題が発生しており、これへの対応が求められている。特に、電子メールに関しては、漏洩や改ざんさらに誤送信などのリスクが存在する。また、電子メールにおいては、ファイル(以下、添付ファイル)が添付され送受信されることが多い。この添付ファイルのアクセス制御は、ファイルサーバに該当ファイルを保存し、該当ファイルへアクセスする際にアクセス制御をかける方法が多い。別の方法として、ファイルのアクセス制御情報(ファイルアクセス対象者のユーザIDやパスワード、参照権限など)をサーバに保持し、該当ファイルへのアクセスを制御する方法もある。

後者の方法は、当該ファイルを閲覧する際に、ネットワークを介してアクセス制御情報を照会し、アクセス権がある場合のみ当該ファイルを開くことが可能である。すなわち、ネットワーク上に情報漏えいで流出したファイルに対しても、当該ファイルのアクセス制御情報を登録していた場合には、アクセス制御情報により、閲覧不可状態することで、既に配布状態となったファイルについて情報制御が可能である。

これらの方法において、添付ファイルに対する暗号化を、別途暗号化ファイルを用いて行う手間を省くための方法が特許文献１に記載されている。

特許文献１では、ファイルアクセス管理サーバに添付ファイルを登録して一元管理する方法が開示されている。すなわち、送信の際に、暗号化すべき添付ファイルを指定し、指定された添付ファイルについての暗号鍵をファイルアクセス管理サーバから取得して、暗号化を施し、その暗号化した添付ファイルをファイルアクセス管理サーバに登録することが記載されている。そして、受信側から送信された認証情報がファイルアクセス管理サーバで認証された場合、当該ファイルアクセス管理サーバに格納された添付ファイルに対するアクセス権限を受信装置に付与することが記載されている。この際、送信元のクライアント端末から、ファイルアクセス管理サーバに格納された添付ファイルに対するアクセス権限変更が可能であることが開示されている。

特開2006-344000号公報(P 2006-34000A) ・日立ソフトウェアエンジニアリング(株)刊、製品パンフレット「活文ドキュメント統制＆ソリューション『DocProducer』」カタログ番号:ZA9-01 ・日立ソフトウェアエンジニアリング(株)刊、製品パンフレット「活文ドキュメント統制＆ソリューション『KATAUBUN Delivery』」カタログ番号:ZB2-02 ・日立ソフトウェアエンジニアリング(株)刊、製品パンフレット「活文ドキュメント統制＆ソリューション『Rights Director』」カタログ番号:ZB5-02

メールに添付するファイルのアクセス制御については、メール送信時に、添付ファイルを自動でファイルサーバに保存し、当該ファイルのアクセス制御を行う方法があるが、この場合、メール受信者側がファイルを取得した後の当該ファイルのアクアセス制御は不可能となる。

特許文献１のように添付ファイルおよびそのアクセス制御情報をサーバに保存し、該当ファイルの閲覧時に、ネットワークを介してファイルアクセス制御情報を参照して閲覧可否を制御する方法は、アクセス制御対象となるファイルの閲覧可否を永続的に制御可能であるが、現在のところ、ファイルのアクセス制御情報をコンピュータの画面から手動で登録する、独立したソフトウェアとして存在しており、ファイル授受の際に逐一手動で登録する手間がかかり、不便である。

たとえば、メールにファイルを添付した場合、当該添付ファイルのアクセス制御情報、メールに添付する前にアクセス制御情報を制御可能な専用ソフトウェアで当該ファイルを処理し、アクセス制御情報(閲覧可能者、閲覧可能期間など)を当該専用ソフトウェアでサーバにアクセス制御情報として登録する必要がある。また、誤送信された場合など電子メールの本文は、漏洩することになり問題になる。

また、電子メールに添付して送信してしまうと、メール受信者側がファイルを取得した後の当該ファイルのアクアセス制御は不可能となる。

これらの課題の少なくとも１つを解決するために本発明では、メールに添付するファイルについて、ファイルのアクアセス制御情報をサーバに保存し、当該ファイルへのアクセス制御を、メール受信側が当該ファイルを入手した後も実施可能とするために、メール送信ソフトおよびメール送信サーバと、ファイルアクセス制御情報によるファイルアクセス制御方法を連携する方式の提案する。

本発明では、送信要求のあった電子メールについて、当該電子メールの送信があったことを示す情報および受信者を認証する情報（および／または受信を希望する情報）の入力を受付ける登録画面を、受信側の装置に送信する。そして、受信側の装置における入力内容により認証された場合（および／または受信を希望する情報の入力を受付けた場合）、当該電子メールを受信側の装置に送信する。この際、添付ファイルへの暗号化指定など所定の条件を満たす電子メールについて上記の処理を施してもよい。また、上記の認証がされるまで送信された電子メールを所定の待機領域に格納しておくことも含まれる。さらに、一定期間以上、受信側の装置から認証する情報や受信を希望する情報の受信がないか認証がなされなかった場合、当該電子メールを削除することが含まれる。また、送信側の装置から当該電子メールを削除したり、宛先を変更することも本発明に含まれる。これらの態様によって、本発明では、電子メールの受信を制御することが可能になる。

より具体的には、以下の態様も本発明に含まれる。

電子メールを送信する送信装置から、前記電子メールを、受信装置を宛先として送信する電子メール送信方法において、
前記装置からサーバ装置へ、電子メールを送信し、
前記サーバ装置が、
前記電子メールを格納し、
格納された前記電子メールを、前記受信装置に配信するための条件情報を、前記送信装置から受信し、
格納された前記電子メールの宛先である受信装置に対して、格納された前記電子メールについての当該電子メールの送信があったことを示す情報および受信者を認証する情報および／または受信を希望する情報の入力を受付ける登録画面を送信し、
前記受信装置から、利用者からの前記登録画面に対する入力内容を受信し、
受信した前記入力内容と前記条件情報を比較して、前記入力内容が前記条件情報を満たす場合、当該電子メールを受信装置に送信する。

本態様には、受信側からの要求に応じて登録画面を送信する構成も含まれる。この際、受信装置で電子メールを閉じた場合、その電子メールを受信装置から消去する構成も含まれる。つまり、電子メールを開こうとする毎に、比較処理を行うことも本発明には含まれる。

また、本発明には、以下の態様も含まれる。

添付ファイルに対して暗号化を含む無効化処理（所定の条件を満たすとその内容を表示等できることを指す）を行い、また、電子メールを識別するメールＩＤとその電子メールに添付する添付ファイルを識別する添付ファイルＩＤを対応付けておき、添付ファイルＩＤとその添付ファイルを有効化（無効化を解除）する条件を示す有効化条件を対応付けておき、この有効化条件を満たす場合、有効化処理に用いる有効化キーを発行するものである。この際、受信側からメールＩＤを送信し、これに対応した添付ファイルＩＤを特定し、さらに特定された添付ファイルＩＤに対応した有効化キーを特定することで、添付ファイルＩＤを通知しなくとも有効化キーの入手が可能になる。特に、１つの電子メールに対して、複数の添付ファイルが添付されている場合(その中でも特に、添付ファイルで異なる有効化条件を設定している場合)、手間を省くことが可能になる。この際、添付ファイルが存在するなど所定の条件を満たす場合、無効化処理以降の処理を実行するようにしてもよい。

より具体的な表現としては、添付ファイルが添付された電子メールを送信する送信装置から、前記電子メールを、受信装置を宛先として送信する電子メール送信方法において、
前記送信装置からサーバ装置へ、前記添付ファイルが添付された電子メールを送信し、
前記サーバ装置において、
送信された前記電子メールを識別するメールＩＤを生成し、
前記電子メールに添付された前記添付ファイルに対して無効化処理を施し、
前記添付ファイルを識別する添付ファイルＩＤを生成し、
前記メールＩＤ、前記添付ファイルＩＤおよび前記添付ファイルを有効化するための有効化条件（認証情報、いわゆる「開く」ための情報、受信可能とするための情報、復号化するための情報、閲覧不可状態から閲覧可能状態にする情報などが含まれる）について、前記メールＩＤと前記添付ファイルＩＤを、前記添付ファイルＩＤと前記有効化条件を対応付けてセキュリティ情報データベースに格納し、
前記送信装置から前記受信装置へ、前記添付ファイルを無効化（暗号化や受信自体を不可能とする処理を含む）した無効化添付ファイルを添付した前記電子メールを送信し、
前記受信装置において、前記電子メールに添付された前記無効化添付ファイルに対する有効化指示(もしくは無効化解除指示)を受付け、
前記受信装置から前記サーバ装置へ、前記メールＩＤおよび前記無効化添付ファイルの有効化が可能かを確認する有効化確認情報を含む有効化要求を送信し、
前記サーバ装置において、
送信された前記メールＩＤに対応する添付ファイルＩＤを、前記セキュリティ情報データベースから検索し、
検索された添付ファイルに対応する有効化条件を特定し、
送信された有効化確認情報が特定された有効化条件を満たすかを判断し、
前記有効化確認が前記有効化条件を満たす場合、前記無効化添付ファイルを有効化するための有効化キーを、前記受信装置に送信し、
受信装置において、前記有効化キーを用いて前記無効化添付ファイルの有効化を可能にする。

有効化キーの送信を、対応する添付ファイルＩＤと対応付けて送信してもよい。この場合、有効化キーをとりあえず送っておき、受信装置で、添付ファイルが指定されたときに実際にそれを使うように構成する。このように、複数の添付ファイルそれぞれを有効化するようにしてもよい。さらに、添付ファイルを転送する場合、添付ファイルＩＤを引き継ぐ（メールＩＤは元のメールＩＤと関連づいた内容）ようにしてもよい。さらに、メールＩＤも転送の際、元のＩＤを引き継ぐよう構成してもよい。なお、ここでの「引き継ぐ」とは、同じＩＤを利用する事としてもよいし、所定の関係を有するよう変換（数字で１を足したり、桁数を増やすことが含まれる）してもよい。このように構成することで、セキュリティ情報データベースの情報量を抑止できることになる。また、複数添付ファイルある場合、これら複数の添付ファイル全体を識別するグループＩＤを用いてもよい。

なお、上述した各態様の組み合わせも本発明に含まれる。

本発明によれば、り、以下2点を主な効果とする。
(1)メール送信時に、ファイルアクセス制御情報を取得・設定・保存することを連続して実施することが可能となる。

また、メール送信の際に、メール誤送信などにより誤って流出したファイルに対して永続的に情報閲覧制御を実施する機会を自動提供することが可能となる。

以下、図面を用いて、本発明の実施形態を詳細に説明する。
本発明に係る図について説明をする。

図1(a)〜(c)はは、本実施形態の発明を実現した場合の処理手順の一例を示すフローチャートである。各ステップには、ステップ番号を付してある。図２には、図１における本実施形態発明の実装を行った場合の機器構成(システム構成)を示す。

本実施形態発明は、大きく分けて、以下機能(A)〜(EF)の5６つの機能に分けることが可能になるの連携により実現する。
(A) メール作成/発信機能
(B) ファイル暗号化機能
(C) ユーザ情報登録照会機能
(D) エラー処理機能
(E) ユーザ情報登録機能
(F) 添付ファイルの復号機能
図１中に示す機能(A)〜(EF)は、各々上記機能を示す。機能(A)については、図１(a)〜(c)では機能(B)〜(E)の複数箇所に組み込む実装形態をとる。

まず、図２を用いて、本実施形態の機器構成の内容を説明する。本実施形態における機器構成は、下記に列挙する各装置で構成される。各装置はネットワークを介して接続され、各装置はいわゆるコンピュータで実現される。つまり、ＣＰＵのような処理部やプログラムなどを格納する記憶部を有し、プログラムに従って処理部が後述する各処理を実行する。

本実施形態を構成する各装置は、以下のとおりである。いわゆるパーソナルコンピュータで実現されるメール送信者端末１０、メール送信者端末１０から送信される電子メールを一旦保持する待機エリア（２５，２６）を有するアプリーションサーバ２０、いわゆるメールサーバ２１、本実施形態でのメールに関する情報であるメールパラメータ等を格納するセキュリティ情報データベース２２、電子メールを受信側へ送信するための受信側の情報を登録するユーザ情報登録データベース２３、いわゆるｗｅｂサーバ２４、パーソナルコンピュータで実現されるメール受信者端末４０である。なお、本実施実施形態では、各サーバやデータベースをそれぞれ別個のハードウエアで構成しているが、別個で実現しなくともよい。また、メール送信者端末１０、アプリケーションサーバ２０、メールサーバ２１、セキュリティ情報データベース２２およびユーザ情報データベース２３は、それぞれ通信回線であるイントラネット３０を介して接続されている。

また、メール受信者端末４０とｗｅｂサーバ２４は通信回線であるインターネット３１を介して接続されている。また、イントラネット３０とインターネット３１の間にはファイヤーウォール（Ｆ／Ｗ）が接続されている。なお、メール受信者端末４０はインターネット３１とファイヤーウォールと接続したイントラネットを介して接続するよう構成してもよい。

なお、メール送信者端末１０およびメール受信者端末２０は、それぞれ１つの端末を図示しているが、それぞれ複数の端末が各ネットワークに接続されるように構成してもよい。また、メール送信者端末１０およびメール受信者端末２０は、いわゆるパーソナルコンピュータで構成され、それぞれ表示画面(ディスプレイ)１１、４１や入出力装置であるキーボード１２、４２やマウスを有する。また、それぞれメールを送受信するためのソフトウエアであるメーラを有する。このメーラについても、他のプログラムと同様に処理部（図示せず）にてその処理が実行される。なお、各端末は、これは立場を変えるとメール送信者端末３０とメール受信者端末４０のいずれにもなりうる。なお、メール受信者端末４０は、メーラの他のプログラムとして、添付ファイルを扱う（開く）アプリケーションプログラムを有する。このアプリケーションプログラムとメーラに従って後述する図１（ｄ）の処理を実行する。

以下、図１(ａ)〜(ｃ)の処理手順と図2の機器構成図をに用いて基づき、その処理内容の詳細を説明する。

はじめに、図1(ａ)を用いて「 (B)ファイル暗号化機能」での処理について説明する。
メール送信者端末10は、メール送信者の指示(入力)に従い、メールソフト(メーラ13)を起動し、メール本文および送信先の入力をメール送信者から受付ける。メール送信者が、作成したメールに対しファイルの添付を行う場合は、メーラ13はメール送信者の指示(入力)を受付ける。メール送信者がメール作成を完了した後は、メーラ13は、メール送信者のメール発信操作に応じてメール発信処理を行う。メール作成者が行うメール発信処理は、例えば、メール送信者がメール発信ボタンを押下するなどの、メール送信者端末10の画面11やキーボード12(カーソルを含む)を用いた操作により発動し、これにより、メーラ13は、通信回線30を経由し、アプリケーションサーバ20に処理要求を送信する(ステップ1001)。ここで使用するメーラ13は、本実施形態発明の機能 (A)〜(ＦE)を有するシステムと連携する機能を有する。

メール送信者端末１０により発信処理が行われた(電子)メール(以下、メールA)をアプリケーションサーバ２０が受信する。そして、このメールＡに対して、アプリケーションサーバ20は、添付ファイルの有無を判別する(ステップ1002)。添付ファイルの有無は、例えばメーラ13がMIMEに基づく仕様であれば、マルチパートによりシステム側で判別可能である。

アプリケーションサーバ20が、メールAに添付ファイルが存在しないと判別した場合は、アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールAを伝送する。し、次にメールサーバ21は、メールAのメール送信処理を実施し(ステップ1003)、処理を終了する。すなわち、各通信回線３０を介してメール受信者端末４０にて、当該メールＡを表示可能とさせる。

アプリケーションサーバ20が、メールAに添付ファイルが存在すると判別した場合は、メール送信者端末10の画面11に、セキュリティ情報確認画面を表示する(ステップ1011)。画面11に表示するセキュリティ情報確認画面の例を、図3に示す。ここでのセキュリティ情報とは、「誰が」「何に対して」「いつまで」「何ができるかを」「誰が許可する」の5つの項目を示す。すなわち、メールAの添付ファイルについて、「誰が」=宛先(メールA受信者)、「何に対し」=メールA添付ファイル、「いつまで」=メールA添付ファイルの参照期限、「何ができるか」＝メールA添付ファイルへの操作(参照・印刷・改変など)、「誰が許可する」=メールA送信者、となる。図3では、「誰が」=送信先105、「何に対し」=添付ファイル名104、「いつまで」=失効期限109、「何ができるか」＝読み取り/印刷可/変更可(暗号化PDF化107)、「誰が許可する」=メール送信者(メール送信者端末10の操作者)となる。

本発明の実施形態例の図1では、これらの5項目に加えて、メール添付ファイルに対する暗号化要否の判断基準となる情報(例えば図3の項目107・108)や、メール送信のタイミングの選択(図3の項目、メール送信のタイミング110)や、メールヘッダに含まれる情報(メール送信日時など)を含めて、図4セキュリティ情報データベースを構成する。図4セキュリティ情報データベースには、データをテーブルに登録した日時(登録日時151)やレコードの更新情報(更新日時152、更新者153)などのデータ管理上、一般的によく利用されるデータ項目を含む。

図3では、添付ファイルの参照権限などのメール送信者により設定が必要な項目は、図3のように画面上でチェックボックスなどの入力フィールドを設け、メール送信者がセキュリティ情報の確認だけでなく、入力作業も同時に実施可能としている。また送信先などの他の項目についても、メール送信者が修正等の入力ができるように入力フィールドを設けても可である。

メール送信者端末10は、セキュリティ情報確認画面においてメール送信者の指示(入力)に従い、次の処理へ進む操作を受付ける。例えば、図3の送信確認111の「キャンセル」ボタンをメール送信者が押下した場合は、処理を終了する。また、例えば、図3の送信確認111の「OK」ボタンをメール送信者が押下した場合は、これをメール送信者端末10が受け付け、メール送信者端末10は、メールAおよび図3中に含まれるセキュリティ情報確認画面の表示/入力情報をメールAパラメータ一式として、通信回線30を経由してアプリケーションサーバ20に送信する(ステップ1012)。

アプリケーションサーバ20は、メールAパラメータ一式を受け付け、これに対し、必須項目チェックを実施する(ステップ1013)。必死項目チェックとは、システム上、処理に必要なデータが存在しているかを確認する処理である。チェック対象となる項目は、例えば図3では、失効期限109、メール送信のタイミング110である。チェック方法は、例えば、各項目について順次存在の有無を確認していき、存在しない項目があった場合、以降の項目における確認は中止し、存在しないと判断する方法がある。なお、アプリケーションサーバ２０は、これら必須項目を示すテーブルを有しており、これと受付けた(受信した)パラメータ一式を比較することで必須項目チェック処理を行う。

アプリケーションサーバ20が、メールAパラメータ一式に対して、処理に必要なデータが存在していない項目を一つ以上確認した場合は、アプリケーションサーバ20はステップ1011へ処理を遷移する。

アプリケーションサーバ20が、メールAパラメータ一式に対して、処理に必要な各データが全て存在していることを確認した場合は、アプリケーションサーバ20は、メールAパラメータ一式に含まれる各項目のデータ形式の妥当性をチェックする(ステップ1014)。妥当性の判断は、例えば失効期限109に数値以外の文字が入っていないかなどの、あらかじめ格納されているルールと照らし合わせることで確認する。データ形式の妥当性をチェックするルールは、例えば図4セキュリティ情報データベースの各項目のデータ型や桁数を基に設定しておいてもよい。

アプリケーションサーバ20が、メールAパラメータ一式の各項目の値においてデータ形式の妥当性をチェックするルールを満たしていないと判断した場合、ステップ1011へ処理を遷移する。

アプリケーションサーバ20が、メールAパラメータ一式の各項目の値においてデータ形式の妥当性をチェックするルールを満たす判断した場合、アプリケーションサーバ20は、暗号化PDF化または暗号化する添付ファイルがメールAに存在するか判断する(ステップ1015)。判断方法は、ステップ1012でメール送信者端末10から送信されたメールAパラメータ一式に含まれる、図3の暗号化PDF化107、暗号化108のチェックボックスの値の有無で判断する。例えば、アプリケーションサーバ20は、暗号化PDF化107、暗号化108のチェックボックスにチェックが全く無かった場合、暗号化PDF化または暗号化はしないと判断する。

アプリケーションサーバ20が、メールA添付ファイルに対し暗号化PDF化または暗号化はしないと判断した場合、アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールAを伝送し、次にメールサーバ21はメールAの送信処理を実施し(ステップ1016)、処理を終了する。

アプリケーションサーバ20が、メールA添付ファイルに対し暗号化PDF化または暗号化はしないと判断した場合、アプリケーションサーバ20は、メールAに対しメールID101を作成する。そして、これを付与し、メールAパラメータ一式と対応付けてともにアプリケーションサーバ20 にて保持(記憶)する(ステップ1021)。メールID101は、後に、図4セキュリティ情報データベースのデータ項目、メールID101に格納するデータである。メールID101は、メールAを他のメールと識別できるようにするためのIDであるため、例えば、「ランダムな英数字+IDを付与した時のサーバのタイムスタンプ(年月日時分秒)」のような一意性のある文字列を使用する。

また、メールＩＤについては、マルチパートを利用するなどしてメール本体に附属させる。なお、メールＡが他のメールを転送する場合、他のメールのメールＩＤを利用してもよい。この利用については、同じメールＩＤを用いることに加え、メールＩＤに対して所定の変換を施したものも含まれる。このように利用するために、メールパラメータ一式に転送前のメールのメールＩＤを含ませてもよい。

アプリケーションサーバ20は、メールA添付ファイルに対し添付ファイルID103作成する。を付与し、そして、メールAパラメータ一式と対応付けてともにアプリケーションサーバ20 にて保持する(ステップ1022)。添付ファイルID103は、後に、図4セキュリティ情報データベースのデータ項目、添付ファイルID10３として格納するデータである。添付ファイルID103は、メールAの添付ファイルを他のファイルと識別できるようにするためのIDであるため、例えば、「ランダムな英数字+IDを付与した時のサーバのタイムスタンプ(年月日時分秒)」のような一意性のある文字列を使用する。また、メールAに複数の添付ファイルがある場合は、個々の添付ファイルに対し、添付ファイルID103を付与し、メールAパラメータ一式と対応付けてともにアプリケーションサーバ20 にて保持する。メールAの添付ファイルおよびその個数をアプリケーションサーバ20が判別するには、例えば、例えばメーラ13がMIMEに基づく仕様であれば、マルチパートによりシステム側で判別可能である。また、作成された添付ファイルＩＤについては、添付ファイルもしくはメールＡに保持(附属)させるようにしてもよい。

アプリケーションサーバ20は、当該サーバがメールAパラメータ一式として保持しているメールAの添付ファイル数を添付ファイルID103の個数により取得し(ステップ1023)、その個数の値分の回数だけ、暗号化処理とセキュリティ情報データベース登録処理を繰り返す(ステップ1024〜1029)。

アプリケーションサーバ20は、メールA添付ファイルにのうち含まれる添付ファイルの1つを任意に選択し、当該サーバで保持しているメールAパラメータ一式に含まれるの処理対象とした選択された任意添付ファイルに関する暗号化PDF化107の値を参照し、当該添付ファイルの暗号化PDF化の要否を判断する(ステップ1024)。例えば、図3添付ファイル901では、暗号化PDF化107には、チェックボックス「読み取り」「印刷可」にチェックが有り、チェックボックス「変更可」にはチェックが無い。これを、チェックボックスにチェックが有る場合を1、無い場合を0という値で暗号化PDF化107の値を「110」と表す。この場合、アプリケーションサーバ20は、暗号化PDF化107値が「000」(全てのチェックボックスにチェックが無かった)でないことから、図3の添付ファイル901に対しては暗号化PDF化をすると判断する。

なお、これまでの処理では、ステップ１０１２やステップ１０１５を、メール送信者端末１０を介した入力（指示）内容に基づいて判断しているが、添付ファイルの有無、容量、数、メールの主題、送信者(アドレス)、受信者(アドレス)などに基づいて、判断するようにしてもよい。例えば、メーラのフィルタリング機能と同様の機能をアプリケーションサーバ２０に持たせ、これを利用して添付ファイル有り、予め記憶された所定以上の容量、所定の文字を含むメール主題を有する、所定のドメイン、もしくはアドレスの少なくとも１つを満たす場合に、添付ファイルへの暗号化もしくはＰＤ化やセキュリティ情報画面への登録が必要、と判断してもよい。この場合、一方の判断（１０１２もしくは１０１５）をこのように判断し、他方をメール送信者端末１０からの入力（チェックボックス）に基づいて、判断する構成にすることも本実施態様の１つである。さらに、各メールについて、暗号化やセキュリティ情報画面を行うようにしてもよい。

アプリケーションサーバ20が、当該添付ファイルを暗号化PDF化すると判断した場合、暗号化付きPDF化を実施する(ステップ1025)。例えば、前ステップ(ステップ1024)の図3添付ファイル901の暗号化PDF化107の例では、暗号化PDF化107の値が「110」(読み取り可、印刷可)のため、当該添付ファイルを読み取り可・印刷可の設定でPDF化するとともに、暗号化ファイルに変換する。また、同時に、ファイルアクセス制御を行うWebサーバ24のURLを暗号化したファイルに埋め込む。

アプリケーションサーバ20が、当該添付ファイルを暗号化PDF化しないと判断した場合、当該サーバで保持しているメールAパラメータ一式の処理対象とした任意添付ファイルに関する暗号化108の値を参照し、当該添付ファイルの暗号化の要否を判断する(ステップ1026)。例えば、図3に示す添付ファイル902では、暗号化108には、チェックボックスにチェックが有る。これを、チェックボックスにチェックが有る場合を1、ない場合を0という値で暗号化108の値を「1」と表す。この場合、アプリケーションサーバ20は、暗号化108の値が「0」(チェックボックスにチェックが無かった)でないことから、図3添付ファイル902に対しては暗号化をすると判断する。

アプリケーションサーバ20が、当該添付ファイルを暗号化すると判断した場合、アプリケーションサーバ20は、添付ファイルを暗号化する(ステップ1027)。暗号化処理は、例えば公開鍵暗号化方式でも秘密鍵暗号化方式でも可であり、また、公知の暗号化手法に加えて、暗号化したファイルにファイルアクセス制御を行うWebサーバ24のURLを埋め込みファイルアクセス時にWebサーバ24によりアクセス制御を施してもよい。

アプリケーションサーバ20が、当該添付ファイルを暗号化しないと判断した場合、アプリケーションサーバ20は、当該添付ファイルへの処理は行わず、ステップ1029へ遷移する。

アプリケーションサーバ20が、当該添付ファイルを暗号化PDF化(ステップ1025)または暗号化(ステップ1027)をした場合、アプリケーションサーバ20は、メールAパラメータ一式から、メールID101、送信元102、当該添付ファイルの添付ファイルID103、当該添付ファイルの添付ファイル名104、送信先105、属性106、暗号化PDF化107、暗号化108、失効期限107、メール送信のタイミング110、送信日時111を抽出し、データベースサーバ22のセキュリティ情報登録データベースへ通信回線30を経由して送信し、データベースサーバ22はこれらのデータを受け付け、セキュリティ情報登録データベースに登録する(ステップ1028)。セキュリティ情報データデータベースの例は、図4に示す。なお、図４には図示しないが、各レコードについて、その添付ファイルを復号するための復号鍵（もしくはこれを識別する情報）を格納したり、復号鍵へのリンク情報を格納してもよい。これは、後述する（Ｆ）添付ファイルの復号機能で用いられる。つまり、認証されたメール受信者端末で用いられるように制御する。

アプリケーションサーバ20は、メールAに他の添付ファイルがないか、ステップ1023で取得したメールAの添付ファイル数で確認し、他の添付ファイルがある場合はステップ1024へ処理を遷移する(ステップ1029)。なお、アプリケーションサーバ20がステップ1024、1026で暗号化PDF化または暗号化の対象としなかった添付ファイルは、処理済みのファイルとみなす。例えば、アプリケーションサーバ２０は、セキュリティ情報データベース２２に処理済とのフラグを立てる（図示せず）。また、暗号化PDF化や暗号化設定の欄に、処理済但し不要、を意味する情報を書き込んでもよい。

アプリケーションサーバ20がメールAに暗号化PDF化または暗号化処理をしていない他の添付ファイルがないと判断した場合、アプリケーションサーバ20は、メールAをすぐ送信するか否かを確認する(ステップ1030)。なお、「すぐ送信」とは、「待機エリア２５，２６」に保存するか、メール受信者端末４０を宛先として送信を行うかの判断であって、時間的に遅れが出ても構わない。このすぐに送信するか否かの確認は、例えば、図3メール送信のタイミング110のラジオボタンのチェック値を用いて行う。図3メール送信のタイミング110のラジオボタンでは「全てすぐ送信」904にチェックが入っており、「宛先が全て登録されてから一斉送信」905、「登録された宛先から個別に送信」906にはチェックが入っていない。「全てすぐ送信」904にチェックが入っている場合を「1」、「宛先が全て登録されてから一斉送信」905にチェックが入っている場合を「2」、「登録された宛先から個別に送信」906にチェックが入っている場合を「3」という値でメール送信のタイミング110の値をメールAパラメータ一式に保持するとした場合、メール送信のタイミング110の値が「1」であればすぐに送信と判断し、ステップ1031へ処理を遷移する。「1」以外の値であれば、ステップ2001へ処理を遷移する。なお、一斉送信とは、時間的にまったく一致して送信することのみを意味するのでなく、メール受信者端末４２での認証がなくとも同報送信することを意味する。このことに関しては、後述する。

アプリケーションサーバ20は、暗号化PDF化(ステップ1025)または暗号化(ステップ1027)をしたメールA添付ファイル、また暗号化しなかったメールA添付ファイルをメールAに添付し、メールAの元の添付ファイルは削除する(ステップ1031)。

アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールAを伝送し、次にメールサーバ21はメールAの送信処理を実施し(ステップ1032)、処理を終了する。なお、ステップ１０３０の判断も、メールや添付ファイルに応じてアプリケーションサーバ２０が判断してもよい。例えば、添付ファイルの容量、数、メールの主題、送信者(アドレス)、受信者(アドレス)などに基づいて、判断するようにしてもよい。例えば、メーラのフィルタリング機能と同様の機能をアプリケーションサーバ２０に持たせ、これを利用して添付ファイルが予め記憶された所定以上の容量、所定の文字を含むメール主題を有する、所定のドメイン、もしくはアドレスの少なくとも１つを満たす場合に、そのまま送信：YESもしくはそれに対してNOと、判断してもよい。また、本ステップ１０３０をスキップして各メールについては、そのまま送信YESもしくはNO以降の処理に進むようにしてもよい。

この(B)ファイル暗号化機能を実行することにより、添付ファイルへの暗号化およびメールへの送信制御(例えば、アクセス制御すべき（すぐに送信しない）メールとそれ以外の区別等)を行うことが可能になる。

次に、以下、図1(b)を用いて「 (C) ユーザ登録情報照会機能」での処理について説明する。この機能は、「(B)ファイル暗号化機能」での処理のステップ１０３０で「すぐ送信：NO」と判断されたメールの送信制御を行うものであり、メール受信者端末４０へ送信の準備(送信可能かの判断)処理である。

ステップ1030にて、アプリケーションサーバ20が、メールAをすぐに送信しないと確認した場合、アプリケーションサーバ20は、通信回線30を経由して、データベースサーバ23のユーザ情報登録データベースに、送信先105がユーザとして登録済みかを照会し、未登録ユーザの登録内容を取得する(ステップ2001)。照会方法は、送信先105が、図5ユーザ情報登録データベースのメールアドレス203に合致するかにより、ユーザとして登録済みか否かを確認する。照会結果として、例えば、アプリケーションサーバ20は、メールAパラメータ一式の送信先105から、データベースサーバ23のユーザ情報登録データベースに未登録の送信先一覧を取得する。送信先105が複数ある場合は、個々の送信先について、メールアドレス203に合致するか照会する。

アプリケーションサーバ20は、ステップ2001において取得した照会結果を基に、ユーザ情報登録データベースの未登録ユーザ数が1件以上かを確認する(ステップ2002)。確認方法は、例えばステップ2001で取得した照会結果の未登録ユーザ数をカウントする。

アプリケーションサーバ20が未登録ユーザ数無しと確認した場合、アプリケーションサーバ20は、処理をステップ2007へ遷移する。

アプリケーションサーバ20が未登録ユーザ数1以上判断した場合、アプリケーションサーバ20は、処理をステップ2003へ遷移する。

アプリケーションサーバ20は、ステップ2001において取得した照会結果を基に、未登録ユーザの送信先を宛先とした図6の登録依頼メールのようなユーザ情報登録データベースへの登録依頼メール(以下メールB)を作成する(ステップ2003)。図6では、メール本文テンプレートファイルをアプリケーションサーバ20に用意しておき、メール本文テンプレートファイルに、宛先などを埋め込む方法でメール文面を作成している。

アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールBを伝送し、次にメールサーバ21はメールBの送信処理を実施する(ステップ2004)。

アプリケーションサーバ20は、メールA送信者に対し、ステップ2001で照会結果の未登録ユーザの送信先を基に、図7のような未登録ユーザの連絡メール(以下メールC)を作成する(ステップ2005)。図７では、メール本文テンプレートファイルをアプリケーションサーバ20に用意しておき、メール本文テンプレートファイルに、宛先などを埋め込む方法でメール文面を作成している。

アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールCを伝送し、次にメールサーバ21はメールCの送信処理を実施する(ステップ2006)。

アプリケーションサーバ20は、メールAパラメータ一式のメール送信のタイミング110を参照し、メールAの各宛先全てがユーザ情報登録データベースに登録されてからメールAをメールA宛先に一斉送信するか否かを確認する(ステップ2007)。
一斉送信するか否かの確認は、例えば、図3メール送信のタイミング110のラジオボタンのチェック値を用いて行う。図3メール送信のタイミング110のラジオボタンにて、「宛先が全て登録されてから一斉送信」905にチェックが入っている場合を「2」、「登録された宛先から個別に送信」906にチェックが入っている場合を「3」という値でメール送信のタイミング110の値をメールAパラメータ一式に保持するとした場合、メール送信のタイミング110の値が「2」であれば一斉送信すると判断し、ステップ2008へ処理を遷移する。メール送信のタイミング110の値「3」値であれば、ステップ2010へ処理を遷移する。

なお、ここでの一斉送信とは、メールAの送信先105のメールアドレスが、各全てユーザ情報登録データベースのメールアドレス25に登録された後に、メールAをメールA 宛先に同時同報送信することをいう。つまり、一斉送信をしない場合は、メールAの送信先105のメールアドレスが、ユーザ情報登録データベースのメールアドレス25に登録ありとアプリケーションサーバ20が確認したものから順次メールを送信する。このため、前述したように時間的に差が出ても構わない。

アプリケーションサーバ20は、メールAを一斉送信すると判断した場合は、メールAに対し、ステップ1031と同様の処理を実施する(ステップ2008)。

アプリケーションサーバ20は、ステップ2008を経たメールAを、アプリケーションサーバ20に有する待機エリア25に保存する(ステップ2009)。

アプリケーションサーバ20が、メールAを一斉送信しないと判断した場合は、メールAパラーメータ一式に含まれる送信先105、属性106を参照して、メールA を宛先ごとに複製する(以下、複製したメールをメールAAと表記する 。)(ステップ2010)。

アプリケーションサーバ20は、複製したメールAAに対し、ステップ1031と同様の処理を実施する(ステップ2011)。

アプリケーションサーバ20は、ステップ20１0を経たメールAAを、アプリケーションサーバ20に有する待機エリア26に保存する(ステップ2012)。

アプリケーションサーバ20は、待機エリア25、26に保持するメールAAが、有効期限内のメールであるか確認する(ステップ2013)。例えば、あらかじめ待機エリア25、26に保持するファイルの期間を、ルールとしてアプリケーションサーバ20にパラメータファイルとして保持しておく。メール送信者端末10がステップ1001でメールAを送信した時間を、メールAのメールヘッダから取得し、取得した値に、当該パラメータファイルの期間を足す。これを、アプリケーションサーバ20の現在日時と比較し、アプリケーションサーバ20の現在の方が古ければ、アプリケーションサーバ20は、メールAを有効期限内と判断する。アプリケーションサーバ20による待機エリア25、26に保持するメール有効期限の確認は、例えばあらかじめ3分毎などと設定しておき、設定された内容これに基づいた期間で定期的に本ステップを実施する。

アプリケーションサーバ20が、待機エリア25、26に保持するメールを、有効期限内のメールであると判断した場合、当該メールの送信先が、ユーザ情報登録データベースに登録済みであるか確認する(ステップ2014)。確認方法は、ステップ1030と同様に、アプリケーションサーバ20は、通信回線30を経由して、データベースサーバ23のユーザ情報登録データベースに、当該送信先メールアドレスが、図5ユーザ情報登録データベースのメールアドレス203に合致するかで、ユーザとして登録済みか否かを確認する。このとき、当該送信先メールアドレスが複数ある場合は、各当該アドレスすべてが図5ユーザ情報登録データベースのメールアドレス203に合致することを確認する。

アプリケーションサーバ20が、待機エリア25、26に保持するメールAもしくはメールAAについて、当該メールアドレスが図5ユーザ情報登録データベースのメールアドレス203に合致することを確認できた場合、アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へ当該メールAもしくはメールAAを伝送し、次にメールサーバ21はメールAもしくはメールAAの送信処理を実施し(ステップ2015)、処理を終了する。

アプリケーションサーバ20が、待機エリア25、26に保持するメールについて、当該メールアドレスが図5ユーザ情報登録データベースのメールアドレス203に合致することを確認できなかった場合は、ステップ2013へ処理を遷移する。

以上の「(C)ユーザ情報登録照会処理」により、待機エリアにメールを保持し、受信側からの要求を待つことになる。

次に、以下、引き続き図1(b)を用いて 「(D)エラー処理機能」での処理について説明する。「(D)エラー処理機能」は、上述したステップ２０１３で、待機エリアに有効期限が切れたメールに対する処理を実行する機能である。なお、ステップ２０１３は有効期限か否かを判断して分岐しているが、本ステップをスキップして、ステップ２０１４やステップ３０１１のいずれかに進むように制御しても構わない。

ステップ2013で、アプリケーションサーバ20が、待機エリア25、26に保持するメールを、有効期限内のメールでない判断した場合、当該メールの送信者に対し、図8のような有効期限超過通知メール(以下、メールE)を作成する(ステップ3011)。図8では、メール本文テンプレートファイルをアプリケーションサーバ20に用意しておき、メール本文テンプレートファイルに、宛先などを埋め込む方法でメール文面を作成する。

アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールEを伝送し、次にメールサーバ21はメールEの送信処理を実施する(ステップ3012)。

アプリケーションサーバ20は、通信回線30を経由し、データベースサーバ22のセキュリティ情報データベースに、有効期限内のメールでない判断した当該メールについてのレコードを照会し、抽出したレコードを削除する(ステップ3013)。アプリケーションサーバ20からのセキュリティ情報データベースへの照会は、有効期限内のメールでない判断した当該メールのメールヘッダから取得できるの「送信元メールアドレス、送信先メールアドレス、属性、送信日時」の組み合わせが、順に「送信元102、送信先105、属性106、送信日時111」に合致するかに基づき実施する。

アプリケーションサーバ20は、待機エリア25、26に保持するメールで、有効期限内のメールでない判断した当該メールを待機エリア25もしくは26から削除し(ステップ3014)、処理を終了する。

次に、以下、図1(c)を用いて、「 (E)ユーザ情報登録機能」での処理について、説明する。「(E)ユーザ情報登録機能」は、(C)ユーザ情報登録機能のステップ２００４にて、メールBが送信される際、メール受信者端末４０に対してメール通知およびそれからの受信要求を受付けるための処理である。

ステップ2004にてメールサーバ21がメールBを伝送した後、メールB受信者の操作に従いメール受信者端末40はメールBを受信する。メール受信者端末40は、メールB受信者の操作に従い、Webブラウザを起動し、メールBに記載している図6のURL301にアクセスし、URL301のWebサーバ24は、メール受信者端末40の画面41にユーザ情報登録申請ログイン画面を表示する(ステップ4001)。

メール受信者端末40は、メールB受信者がキーボード42を操作して入力する図6の仮ユーザID 302と仮パスワード303を受け付け、メールB受信者のログインボタンを押下するなどのログイン処理開始操作により、通信回線31を経由して、Webサーバ24に仮ユーザID302、仮パスワード303を送信し、Webサーバ24はこれを受付ける。Webサーバ24は、受付けた仮ユーザID302と仮パスワード303を、通信回線31、30を経由して、アプリケーションサーバ20へ送信し、アプリケーションサーバ20はこれを受け付け、DBサーバ23のユーザ情報登録データベースに対して、通信回線30を経由して、当該登録用ユーザID302とパスワード303が存在するか問い合わせる。存在の有無の問い合わせは、図5ユーザ情報登録データベースのユーザID201又はメールアドレス203の中で、仮ユーザID302と合致するデータがあるか、また、合致したデータがあるならばその中で、パスワード202と仮パスワード303とが合致するデータがあるか、データベースサーバ23が問い合わせ実施し、問い合わせ結果を、通信回線30を経由してアプリケーションサーバ20へ伝送する(ステップ4002)。

当該登録用ユーザID302とパスワード303の組み合わせが存在しない場合、アプリケーションサーバ20は、通信回線30、31を経由し、Webサーバ24を経由し、ID又はパスワードが間違っているなどのメッセージをメール受信者端末40に送信し、メール受信者端末40は画面41に当該画面を表示させ(ステップ4003)、処理を終了する。

当該登録用ユーザID302とパスワード303の組み合わせが存在した場合、アプリケーションサーバ20は、通信回線30、31を経由して、Webサーバ24を経由し、図9のようなユーザ情報登録申請画面をメール受信者端末40の画面41に表示させる(ステップ4004)。

メール受信者端末40は、画面41に表示したユーザ情報登録申請画面に対するメールB受信者のキーボード42からの入力操作を受付ける。メール受信者端末40は、メールB受信者が入力を完了し、メールB受信者の登録処理へ遷移するボタンを押下するなどの操作を受け付け、これにより、メール受信者端末40は、通信回線31、Webサーバ24、通信回線31、30を経由して、アプリケーションサーバ20へ画面41に表示したユーザ情報登録申請画面の入力内容を登録申請内容パラメータ一式として送信する(ステップ4005)。

アプリケーションサーバ20は、メール受信者端末40からの登録申請内容パラメータ一式を受け付け、これに対し、アプリケーションサーバ20はステップ1013と同様に、必須項目チェックを行う(ステップ4006)。例えば、図9では、入力項目全てが必須項目である。チェック方法は、各項目について、各項目について順次存在の有無を確認していき、存在しない項目があった場合、移行の項目の確認は中止、存在しないと判断してもよい。
必須項目のうち、必要な値が一つでも存在していない場合、アプリケーションサーバ20はステップ4044へ処理を遷移する。

必須項目の必要な値が存在している場合、アプリケーションサーバ20は、ステップ1014と同様に、登録申請内容パラメータ一式の各項目のデータ形式の妥当性をチェックする(ステップ4007)。

アプリケーションサーバ20が、登録申請内容パラメータ一式の各項目の値がデータ形式の妥当性をチェックするルールを満たさないと判断した場合、ステップ4004へ処理を遷移する。

アプリケーションサーバ20が、登録申請内容パラメータ一式の各項目の値がデータ形式の妥当性をチェックするルールを満たす判断した場合、アプリケーションサーバ20は、データベースサーバ23のユーザ情報登録データベースに登録申請内容パラメータ一式のデータを登録するSQL文を作成し、データベースサーバ23へ、通信回線30を経由し、伝送する。データベースサーバ23は、アプリケーションサーバ20からの当該SQL文を受け付け、ユーザ情報登録データベースにデータを登録し、登録完了の後、通信回線30を経由し、登録完了をアプリケーションサーバ20へ返す(ステップ4008)。このとき、ユーザ情報登録データベースにおけるメールB受信者のユーザ登録の状態は仮登録状態とし、仮登録状態を判別する方法として、例えば、図5ユーザ情報登録データベースの「登録状態208」に識別できる値を登録する。具体例を挙げると、登録状態208の値を、それぞれ「0」=未登録、「1」=仮登録(承認待ち)、「2」=承認済み、「3」=無効、と定義する。ステップ4008で、「1」=仮登録(承認待ち)となり、それ以前の、メールB 受信者が登録申請作業を実施する前の状態を、「0」=未登録とする。

アプリケーションサーバ20は、データベースサーバ23からの登録完了を受け付け、「登録申請中です。申請結果はメールでご連絡します」などのメッセージをメール受信者端末40に表示する指示を通信回線30、31、Webサーバ24を経由し、メール受信者端末40へ送信する。メール受信者端末40は、これを受け付け、画面41にこのメッセージを表示し(ステップ4009)、処理を終了する。

ステップ4008でユーザ情報登録データベースに登録申請内容パラメータ一式のデータを登録した後、仮登録状態となっているメールB受信者のユーザ登録を完了し、ステップ201４からメールAもしくはメールAAをアプリケーションサーバ20が送信先105のメールアドレスがユーザ登録済みとなるようにする必要がある。メールB受信者のユーザ情報登録データベースへのユーザ登録は、メールA送信者によるメールB受信者のユーザ情報登録内容の承認をもって完了とする。そこで、ステップ4001と同様に、メール送信者端末10は、メールA送信者の操作に従い、Webブラウザを起動し、図6のURL301にアクセスし、URL301のWebサーバ24は、メール受信者端末40の画面41にユーザ情報登録申請ログイン画面を表示する(ステップ4021)。

メール送信者端末10は、メールA送信者がキーボード12を操作して入力するユーザID201とパスワード202の入力を受け付け、メールA送信者のログインボタンを押下するなどのログイン処理開始操作により、通信回線31を経由して、Webサーバ24にユーザID201、パスワード202を送信し、Webサーバ24はこれを受付ける。Webサーバ24は、受付けたユーザID201とパスワード202を、通信回線31、30を経由して、アプリケーションサーバ20へ送信し、アプリケーションサーバ20はこれを受け付け、DBサーバ23のユーザ情報登録データベースに対して、通信回線30を経由して、当該ユーザID201とパスワード202が存在するか問い合わせる。存在の有無の問い合わせは、図5ユーザ情報登録データベースのユーザID201又はメールアドレス203の中で、ユーザID201と合致するデータがあるか、また、合致したデータがあるならばその中で、図5のパスワード201にメールA送信者が入力したパスワード202とが合致するデータがあるか、データベースサーバ23が問い合わせを実施する。また、メールA送信者が入力したユーザID201が、ユーザ情報データベースのユーザID201にて一致した場合は、当該データの登録状態208の値を取得し、問い合わせ結果を通信回線30を、経由してアプリケーションサーバ20へ伝送する(ステップ4022)。

当該ユーザID201とパスワード202の組み合わせがデータベースサーバ23のユーザ情報登録データベースに存在しない場合、アプリケーションサーバ20は、通信回線30、31を経由し、Webサーバ24を経由し、ID又はパスワードが間違っているなどのメッセージをメール送信者端末10に送信し、メール送信者端末10は画面11に当該画面を表示させ(ステップ4023)、処理を終了する。

当該ユーザID201とパスワード202の組み合わせがデータベースサーバ23のユーザ情報登録データベースに存在した場合にあって、で、且つ同時にDBサーバ23が取得した登録状態208の値が2である場合、アプリケーションサーバ20は、通信回線30、31を経由して、Webサーバ24を経由し、メニュー画面をメール送信者端末10の画面11に表示させる(ステップ4024)。ここでのメニュー画面とは、ステップ4004でメール受信者端末40が表示したユーザ情報登録申請画面へ進むリンクや、ログインユーザ自身の登録内容更新画面へ進むリンクなどが、機能目次を記載した画面であり、ここに承認作業へ進むリンクも含む。

メール送信者端末10は、メールA送信者が画面11に表示したメニュー画面の承認作業へ進むリンクを押下するなどの、メール送信者のキーボード12等からの入力操作を受付ける。これにより、メール送信者端末10は、通信回線30、31、Webサーバ24、通信回線3１、30を経由して、アプリケーションサーバ20へ、承認作業画面へ遷移要求を送信する (ステップ4025)。

アプリケーションサーバ20は、承認作業画面への遷移要求を受け付け、通信回線30を経由し、データベースサーバ23へ、メールA送信者のユーザID201がユーザ情報登録データベースの承認者209に合致し、且つ登録状態208が「1」=承認待ちであるレコードを探す問い合わせを作成し、送信する。データベースサーバ23は、これを受け付け、ユーザ情報登録データベースに問い合わせを実施し、当該結果を通信回線30を経由し、アプリケーションサーバ20へ送信する(ステップ4026)。

アプリケーションサーバ20は、問い合わせ結果を受け付け、メールA送信者のユーザID201がユーザ情報登録データベースの承認者209に合致し、且つ登録状態208が「1」=承認待ちであるレコードが、ユーザ情報登録データベースに存在しない場合は、「承認待ちはありません」などのメッセージを通信回線30、31、Webサーバ24、通信回線31を経由し、メール送信者端末10に送信し、メール送信者端末10は、これを画面11に表示させ(ステップ4027)、処理を終了する。

アプリケーションサーバ20は、問い合わせ結果を受け付け、メールA送信者のユーザID201がユーザ情報登録データベースの承認者209に合致し、且つ登録状態208が「1」=承認待ちであるレコードが、ユーザ情報登録データベースに存在した場合は、該当レコードの、ユーザID201、メールアドレス203、姓204、名205、所属206、tel207を、問い合わせ結果として受け付け、これを通信回線30、31、Webサーバ24、通信回線31を経由し、メール送信者端末10に送信し、メール送信者端末10は、これを画面11に表示した図10のような承認作業画面として表示する(ステップ4028)。

メール送信者端末10は、画面11に表示した図10の承認作業画面に対する、メールA送信者のキーボード12からの入力操作を受付ける。メール送信者端末10は、メールA送信者が入力を完了し、図10の承認作業画面の承認ボタンを押下するなどの操作を受け付け、これにより、メール送信者端末10は、通信回線31、Webサーバ24、通信回線31、30を経由し、アプリケーションサーバ20へ、画面11に表示した承認作業画面の入力・表示内容を、承認登録内容パラメータとして送信する(ステップ4029)。

アプリケーションサーバ20は、承認登録内容パラメータを受け付け、承認登録内容パラメータに含まれるユーザID201を、承認・非承認で区別する。例えば、図10のチェックボックス「承認」にチェックが有る場合は「1」=承認する、「0」=承認しない、として、数値で区別し、承認するユーザIDに対しては、ユーザ情報登録データベースの当該ユーザIDの登録状態208が「2」=承認済みとなるように、更新SQLを作成する。また、承認しないユーザIDに対しては、ユーザ情報登録データベースの当該ユーザIDの登録状態208が「3」=却下となるように、更新SQLを作成する。アプリケーションサーバ20は、作成したSQL文を、通信回路30を経由し、データベースサーバ23へ送信する。データベースサーバ23は、これを受け付け、ユーザ情報登録データベースを更新する(ステップ4030)。

アプリケーションサーバ20は、図11のような承認結果の通知メール(以下、メールD)を作成する(ステップ4031)。承認結果通知メールは、メールB受信者を宛先とし、アプリケーションサーバ20で保持する承認登録内容パラメータから宛先を抽出する。承認登録内容パラメータ内に、承認・非承認したユーザIDが複数ある場合は、ユーザID毎に個別に宛先をセットした承認結果通知メールを作成する。図11では、メール本文テンプレートファイルをアプリケーションサーバ20に用意しておき、メール本文テンプレートファイルに、承認結果などを埋め込む方法でメール文面を作成する。

アプリケーションサーバ20は、通信回線30を経由しメールサーバ21へメールDを伝送し、次にメールサーバ21はメールDの送信処理を実施し(ステップ4032)、処理を終了する。

なお、ここまでメールＡ〜Ｄと異なる名称を用いて説明したが、それぞれは内容として同じメールである。但し、各処理において情報が埋め込まれたりした点で異なっていてもよい。
また、ここまでの処理の概要に関しては、図１２に示したとおりである。

次に、図１(d)を用いて「(F)添付ファイルの復号機能」での処理を説明する。つまり、ステップ4032で送信されたメールＤの添付ファイルを、メール受信者端末４０で復号化するための処理を説明する。この処理それぞれは前述のように、メーラとアプリケーションプログラムのいずれかによって実行される。アプリケーションプログラムは、添付ファイルの拡張子によって、その対応するものが実行するように構成されている。

まず、メール受信者端末４０は、メールＤを受信する(ステップ5001)。これを受け、操作者が添付ファイルを開こうとする指定を、メール受信者端末４０は受付ける(ステップ5002)。

次に、メール受信者端末４０は、指定された添付ファイルから、もしくはメールＩＤから埋め込まれた添付ファイルＩＤを読み取る。そして、読み取った添付ファイルＩＤを含む復号要求情報をアプリケーションサーバ２０にｗｅｂサーバ２４を経由して送信する(ステップ5003)。この場合、復号要求情報には、メールＤのメールＩＤを含めてもよいし、添付ファイルＩＤでなくメールＩＤを用いてもよい。

また、この処理については、アプリケーションプログラムが、以下のように処理を実行してもよい。前提として、添付ファイルにはヘッダ情報が含まれ、ヘッダ情報には添付ファイルＩＤおよびアプリケーションサーバ２０に添付ファイルＩＤを含む復号要求情報を送信する命令を含ませる。これは、メール送信者端末１０においてアプリケーションプログラムもしくはメーラが埋め込むように制御する。そして、メール受信者端末４０が、アプリケーションプログラムに従って、添付ファイルのヘッダ情報から添付ファイルＩＤを読み取り、上記の命令に従って復号要求を、アプリケーションサーバ２０に送信する。

次に、アプリケーションサーバ２０は、受信した復号要求情報に基づいて、指定された添付ファイルの復号キーを検索する（ステップ5004）。すなわち、セキュリティ情報データベース２２を、復号要求情報に含まれる添付ファイルＩＤを含むレコードを検索する。そして、このレコードに含まれる「復号キー」を特定する（上述したように図４には復号キーについての情報は図示していない）。また、さらに復号要求情報に含まれる添付ファイルＩＤに対応するメールＩＤを、セキュリティ情報データベースから検索する。そして、このメールＩＤに対応付いている添付ファイルＩＤを特定する。この処理によって、メールＤに複数の添付ファイルが添付された際、そのうちの少なくとも１つがステップ5002で指定されても、他の添付ファイルの添付ファイルＩＤを特定可能になる。そして、この他の添付ファイルの添付ファイルＩＤに対応付いた復号キーを特定する。このように、特定された復号キーをそれぞれの添付ファイルＩＤと対応付ける。そして、ステップ5005に進みアプリケーションサーバ２０は、これら対応付けられた復号キーを、メール受信者端末４０に送信する。

また、復号要求情報にメールＩＤが含まれている場合には、このメールＩＤに対応する添付ファイルＩＤを検索し、これに対応付いた復号キーを特定する。また、メールＩＤと添付ファイルＩＤの双方が、復号要求情報に含まれる場合、いずれを用いてもよい。

ここで、ステップ5004においては、図１３に示すようなメールＩＤ−添付ファイルＩＤ対応表を用いて、送信された復号要求情報に含まれる添付ファイルＩＤに対応するメールＩＤを特定してもよいし、逆に送信された復号要求情報に含まれるメールＩＤに対応する添付ファイルＩＤを特定してもよい。この対応表は、セキュリティ情報データベース２２と同じ記憶装置内に設けてもよいし、他の記憶装置に設けてもよい。この対応表は、復号キーを添付ファイル毎に設定する場合、より有効である。

なお、セキュリティ情報データベースにおいて、送信先(受信者)毎に復号キーを設定している場合、復号要求情報には、送信先（メールアドレス）を含めるようにしてその復号キーを特定する。

さらに、添付ファイルに暗号化を施していないものをセキュリティ情報データベースの暗号化設定108で判断し、これに関しては暗号化なしを示す情報を送信するようにてもよい。また、上記の対応表では、暗号化設定の領域を設けてもよいし、暗号化している添付ファイルの添付ファイルＩＤを対応表に記録するようにしてもよい（暗号化されないものは除いて記録）。

そして、メール受信者端末４０では、ステップ5005で送信される復号キー（添付ファイルと対応付いた）を受信する(ステップ5006)。

次に、メール受信者端末４０は、復号キーを受信した場合、ステップ5002で指定された添付ファイルに対応する復号キーを抽出する(5007)。ここで、複数の復号キーを受信した場合、抽出される復号キーの特定を、以下のように実行する。本実施形態では、メール受信者端末４０が、ステップ5002で指定された添付ファイルの添付ファイルＩＤをメモリなどの記憶領域に保持しておき、これと送信された復号キーの添付ファイルＩＤを比較して特定する。

メール受信者端末４０は、ステップ5007で抽出した復号キーを用いて、ステップ5002で指定された添付ファイルを復号する。なお、指定した添付ファイルに関して、暗号化されていないとの情報を受信した場合、そのまま添付ファイルを開く。また、暗号化されていないファイルか否かは、メール受信者端末４０で判断可能なので、ステップ5003以降の処理をスキップして指定された添付ファイルを開いてもよい。逆に、メール受信者端末４０は、指定された添付ファイルが暗号化されているか否かを判断し、暗号化されていると判断した場合に、ステップ5003に進むようにしてもよい。また、複数の添付ファイルが有る場合に、指定された添付ファイルが暗号化されていないと判断しても、他の添付ファイルが暗号化されている場合、ステップ5003に進むように制御してもよい。

メール受信者端末４０は、ステップ5007で抽出された復号キーを用いて、ステップ5002で指定された添付ファイルを復号化する(ステップ5008-1)。この場合、この復号キー適当な記憶領域に記憶してもよい。

また、メール受信者端末４０は、指定された添付ファイル以外の復号キーも受信した場合、これらを適当な記憶領域に添付ファイルＩＤと対応付けて記憶しておく(ステップ5008-2)。なお、ステップ5008-1,2で記憶した復号キーは、一定回数利用された場合(含む1回)、消去するよう制御してもよい。この場合、復号キーの利用（復号）の度にカウンタを動作させ、メール受信者端末４０の記憶領域にその復号キーを識別する情報（もしくは添付ファイルＩＤ）ごとにその利用回数もしくは一定回数から利用回数を引いた数値を記録するように実装する。

そして、メール受信者端末４０は、ステップ5002で指定された以外の添付ファイルの指定を受付けた場合、ステップ5008-2で記憶された復号キーを用いて復号する。なお、上記のステップ5008-2の格納処理やステップ5004での指定された添付ファイル以外のファイルについての処理を省略し、添付ファイルが指定される毎に指定されたものの復号キーをアプリケーションサーバ２０に要求するように制御してもよい。

なお、本実施形態では、復号キーをアプリケーションサーバ２０から送信されるよう制御したが、復号キーをメールや添付ファイルに利用できない形で埋め込んでおき（附属させておき）、これを利用できるような情報を送信されるようにしてもよい。つまり、何らかの形で添付ファイルが表示、編集などの利用可能（有効化、無効化解除）となる情報を送信されるようできればよい。

なお、これらのステップ5008-1および２についても、アプリケーションプログラムが、ヘッダ情報に含まれる命令に従って、上記の処理を実行してもよい。特に、「消去」（カウンタを利用した復号回数の制限）については、アプリケーションプログラムに従って、アプリケーションサーバ２０に、復号したことおよびセキュリティ情報の書き換え指示を送信する。これを受けて、図５のセキュリティ情報データベースでのカウンタエリア（図示せず）に復号回数を記録し、予め記録した閾値と比較する。この結果、閾値以上になった場合、１０９の失効期限を受信した日時など記録することで、失効したことを登録するようにしてもよい。
このようにして、暗号化された添付ファイルも復号化（閲覧可能）となる。

また、上記のステップ5003以降の処理は、以下のように実行してもよい。その概要は、メール受信者端末４０を介して、メーラ、アプリケーションプログラムもしくはアプリケーションサーバ２０のいずれかに従ってメール受信者からＩＤ、パスワードの入力を受付け、これに従って復号キーの送付の可否および復号キーの検索を行うものである。その内容を以下、説明する。

まず、ステップ5003において、添付ファイルの指定を受付けるとメール受信者端末４０は、ＩＤとパスワードを要求する画面を表示する。この表示は、メーラが行ってもよいし、アプリケーションプログラムがヘッダ情報のＩＤ、パスワード要求情報に従って行ってもよいし、アプリケーションサーバ２０からの指示に従って行ってもよい。

そして、メール受信者端末４０は、メール受信者から受付けたＩＤ、パスワードを、アプリケーションサーバ２０に送信する。

次に、ステップ５００４において、図５のユーザ情報登録データベースに格納されたＩＤ、パスワードと送信されたＩＤ、パスワードが一致するか検索する。この結果、一致する場合には、セキュリティ情報データベースから、ＩＤに対応する復号キーを特定する。この特定においては、上述した添付ファイルＩＤをメール受信者端末４０から受信してこれをキーにしてセキュリティ情報データベースから特定してもよい。また、ＩＤとしてメールアドレスを用いてもよい。

本発明の一実施形態の処理手順実施の形態における「（B）ファイル暗号化機能」を示すフローチャートである。 本発明の一実施形態の処理手順における「(C)ユーザ情報登録照会機能」および「(D)エラー処理機能」を示すフローチャートである。 本発明の一実施形態の処理手順における「(E)ユーザ情報登録機能」を示すフローチャートである。 本発明の一実施形態の処理手順における「(F)添付ファイル復号機能」を示すフローチャートである。 本発明の一実施形態における図1における、システム機器構成図である。 図1における、ステップ1011で画面11に表示するセキュリティ情報確認画面の構成例である。 図2における、データベースサーバ22のセキュリティ情報データベース項目一覧である。 図2における、データベースサーバ23のユーザ情報登録データベース項目一覧である。 図1における、ステップ2002でアプリケーションサーバ20が作成する、ユーザ情報登録依頼メールの本文例である。 図1における、ステップ2004でアプリケーションサーバ20が作成する、未登録ユーザ連絡メールの本文例である。 図1における、ステップ3011でアプリケーションサーバ20が作成する、有効期間超過通知メールの本文例である。 図1における、ステップ4004でアプリケーションサーバ20が作成する、ユーザ情報登録申請画面である。 図1における、ステップ4028でアプリケーションサーバ20が作成する、ユーザ情報登録申請の承認画面である。 図1における、ステップ4031でアプリケーションサーバ20が作成する、承認結果通知メール本文である。 図1(a)〜(c)の概要を示すフローチャート、本発明の処理手順実施形態の（簡略図）である。 メールＩＤ−添付ファイルＩＤ対応表を示す図である。

符号の説明

(A) メール作成/発信機能
(B) ファイル暗号化機能
(C) ユーザ登情報照会機能
(D) エラー処理機能
(E) ユーザ情報登録機能
10 メール送信者端末 (PC)
11 画面(ディスプレイ)
12 キーボード(カーソル含む)
13 メーラ
20 アプリケーションサーバ
21 メールサーバ
22 データベースサーバ(セキュリティ情報データベース)
23 データベースサーバ(ユーザ情報登録データベース)
24 Webサーバ
25 待機エリア
26 待機エリア
30 通信回線(イントラネット)
31 通信回線(インターネット)
40 メール受信者端末(PC)
41 画面(メディスプレイ)
42 キーボード(カーソル含む)

Claims (10)

1. 電子メールを送信する送信装置から、前記電子メールを、受信装置を宛先として送信する電子メール送信方法において、
   前記装置からサーバ装置へ、電子メールを送信し、
   前記サーバ装置が、
   前記電子メールを格納し、
   格納された前記電子メールを、前記受信装置に配信するための条件情報を、前記送信装置から受信し、
   格納された前記電子メールの宛先である受信装置に対して、格納された前記電子メールについての当該電子メールの送信があったことを示す情報および受信者を認証する情報および／または受信を希望する情報の入力を受付ける登録画面を送信し、
   前記受信装置から、利用者からの前記登録画面に対する入力内容を受信し、
   受信した前記入力内容と前記条件情報を比較して、前記入力内容が前記条件情報を満たす場合、当該電子メールを受信装置に送信することを特徴とする電子メール送信方法。
2. 請求項１に記載の電子メール送信方法において、
   前記サーバ装置は、前記受信装置から前記登録画面を要求する要求情報を受信した場合に、前記登録画面を前記受信装置に送信することを特徴とする電子メール送信方法。
3. 請求項１または２のいずれかに記載の電子メール送信方法において、
   前記サーバ装置は、前記電子メールが所定の条件を満たす場合に、前記電子メールの格納を行い、前記所定の条件を満たされない場合、前記電子メールを前記受信装置に対して送信することを特徴とする電子メール送信方法。
4. 請求項３に記載の電子メール送信方法において、
   前記所定の条件は、前記送信装置からの前記電子メールに対する変更指示および前記電子メールへの送信が前記条件情報を条件とするか否かの指示であることを特徴とする電子メール送信方法。
5. 請求項４に記載の電子メール送信方法において、
   前記電子メールには、添付ファイルが添付され、前記変更指示は、前記添付ファイルに対する暗号化指示であることを特徴とする電子メール送信方法。
6. 添付ファイルが添付された電子メールを送信する送信装置から、前記電子メールを、受信装置を宛先として送信する電子メール送信方法において、
   前記送信装置からサーバ装置へ、前記添付ファイルが添付された電子メールを送信し、
   前記サーバ装置において、
   送信された前記電子メールを識別するメールＩＤを生成し、
   前記電子メールに添付された前記添付ファイルに対して無効化処理を施し、
   前記添付ファイルを識別する添付ファイルＩＤを生成し、
   前記メールＩＤ、前記添付ファイルＩＤおよび前記添付ファイルを有効化するための有効化条件について、前記メールＩＤと前記添付ファイルＩＤを、前記添付ファイルＩＤと前記有効化条件を対応付けてセキュリティ情報データベースに格納し、
   前記送信装置から前記受信装置へ、前記添付ファイルを無効化した無効化添付ファイルを添付した前記電子メールを送信し、
   前記受信装置において、前記電子メールに添付された前記無効化添付ファイルに対する有効化指示を受付け、
   前記受信装置から前記サーバ装置へ、前記メールＩＤおよび前記無効化添付ファイルの有効化が可能かを確認する有効化確認情報を含む有効化要求を送信し、
   前記サーバ装置において、
   送信された前記メールＩＤに対応する添付ファイルＩＤを、前記セキュリティ情報データベースから検索し、
   検索された添付ファイルに対応する有効化条件を特定し、
   送信された有効化確認情報が特定された有効化条件を満たすかを判断し、
   前記有効化確認が前記有効化条件を満たす場合、前記無効化添付ファイルを有効化するための有効化キーを、前記受信装置に送信し、
   受信装置において、前記有効化キーを用いて前記無効化添付ファイルの有効化を可能にすることを特徴とする電子メール送信方法。
7. 請求項６に記載の電子メール送信方法において、
   前記無効化処理には、前記添付ファイルに対する暗号化処理が含まれることを特徴とする電子メール送信方法。
8. 請求項６または７のいずれかに記載の電子メール送信方法において、
   前記電子メールには、複数の添付ファイルが添付され、
   前記サーバ装置は、前記受信装置に対して複数の添付ファイルそれぞれの有効化キーを送信し、
   前記受信装置は、前記複数の添付ファイルに含まれる添付ファイルが指定された場合に、対応する有効化キーを用いて指定された添付ファイルに対して有効化処理を実行することを特徴とする電子メール送信方法。
9. 請求項６乃至８のいずれかに記載の電子メール送信方法において、
   前記受信装置が、受信した前記電子メールに前記添付ファイルを添付して転送する場合、
   前記サーバ装置は、転送される前記電子メールに添付された前記添付ファイルの添付ファイルＩＤを当該添付ファイルの添付ファイルＩＤとすることを特徴とする電子メール送信方法。
10. 請求項６乃至９のいずれかに記載の電子メール送信方法において、
    サーバ装置は、前記有効化キーの送信を、当該有効化キーで有効化される添付ファイルの添付ファイルＩＤと対応付けて送信することを特徴とする電子メール送信方法。

Images