JP2011101337A - 電子メール保留システム - Google Patents

Abstract

【課題】電子メールを送信前に所定時間保留すると共に、組織内等、情報漏洩とはならない送信先には保留することなく先に送信することで、電子メール送信者の誤操作や悪意による情報漏洩を防止する電子メール保留システムを提供する。
【解決手段】内部クライアント１ａ，１ｂが、メールを所定時間保留自在のメール保留サーバ２を介して、メールサーバ４に通信自在に接続される電子メール保留システムであって、メール保留サーバ２は、内部クライアント１ａ，１ｂからメールを受信すると、保留すべき送信先を有する保留メールに保留開始時刻とを追加した保留メールレコードを保留メールＤＢ３１に格納する手段と、起動された時、保留メールＤＢ３１に格納された保留メールレコードが保留時間を経過している場合、当該保留メールをメールサーバ４に送信する手段と、送信した保留メールレコードを保留メールＤＢ３１から削除する手段等とを備える。
【選択図】図１

Description

本発明は、電子メールを所定時間保留した後に送信する、電子メール保留システムに関するものである。

近年、営業秘密や個人情報を記憶したファイルが、電子メールに添付されて送信され、その結果、組織外に情報が漏洩する事件が頻発し、社会問題にもなっている。
こうした情報漏洩は、コンピュータ・ウィルスにより発生することも多いが、一方、電子メールの送信者があて先や添付すべきファイルの指定を誤るといった誤操作によって発生することも多い。
電子メールに係わる誤操作による情報漏洩を防止するために、クライアントＰＣ（Personal Computer）等が送信した電子メールをネットワーク上で受信し、当該電子メールの送信者自身に送信するとともに、所定時間だけ保留し、所定時間経過後に送信者が指定していた送信先に送信する、という技術が知られている（特許文献１）。この技術によれば、当該電子メールの送信者自身に電子メールを送信することで、送信者に、宛先等を再度確認する機会を与えることができる。また、電子メールを保留している時間内に、電子メールの送信者が宛先の誤り等の誤操作に気づいた場合、保留している電子メールの送信中止を指示することで情報漏洩を防止することができる。

特開２００５−２７７９７６号公報

しかしながら、特許文献１に開示された技術によっては、誤操作を行った送信者自身が誤操作に気づかない限り、保留時間経過後に電子メールが送信されてしまう。つまり、送信者自身は送信先等が正しいと思い込んでいるのが通常であり、自分が送信した電子メールが送信されて来ても、客観的に宛先等を再度確認することは稀である。また、電子メールの送信者が悪意を持って情報漏洩しようとした場合、特許文献１に開示された技術によっては、情報漏洩を防止することはできない。

以上の現状に鑑み、本発明は、電子メールを送信前に所定時間保留すると共に、組織内等、情報漏洩とはならない送信先には保留することなく先に送信することで、電子メール送信者の誤操作や悪意による情報漏洩を防止する電子メール保留システムを提供する。

上記の課題を解決すべく、本発明は以下の構成を提供する。
内部クライアントが、メールを所定時間保留自在のメール保留サーバを介して、メールサーバに通信自在に接続される電子メール保留システムであって、
前記メール保留サーバは、前記内部クライアントからメールを受信すると、受信した前記メールに、前記メールに設定されている送信先を実際の送信先に変換した送信先と、送信元とを設定したメールエンベロープを追加するメールエンベロープ追加手段と、
該メールエンベロープ追加手段が追加したメールエンベロープの送信先を参照し、送信先がメールを保留すべき送信先かどうかを判定するメール保留当否判定手段と、
送信先が保留すべき送信先でない場合、保留すべき送信先でない送信先をメールエンベロープから削除し、保留すべき送信先でない送信先のみをメールの送信先として、前記メールサーバ宛にメールを送信する非保留先送信手段と、
送信先が保留すべき送信先である場合、保留すべき送信先を有する保留メールに保留開始時刻を追加した保留メールレコードを保留メールデータベースに格納する保留メール格納手段と、
起動された時、前記保留メールデータベースに格納された全ての保留メールレコードを順に参照し、前記保留メールレコードが所定の保留時間を経過したか判定する保留時間経過判定手段と、
所定の保留時間を経過している場合、当該保留メールを前記メールサーバに送信する時間経過後送信手段と、
該時間経過後送信手段によるメールの送信処理が正常に終了した場合、送信した保留メールレコードを前記保留メールデータベースから削除する保留メールレコード削除手段とを備えるものである。

さらに、前記メール保留サーバは、
受信したメールが保留したメールの削除を要求する削除指示メールであるか判定する削除指示判定手段と、
該削除指示判定手段が削除指示メールであると判定した場合、前記保留メールデータベースに指定された保留メールレコードの存在を確認し、削除可能か判定する削除可否判定手段と、
該削除可否判定手段が、指定された保留メールレコードが存在して削除可能と判定した場合、前記保留メールデータベースから当該保留メールレコードを削除し、削除指示メールの送信元に、削除通知メールを送信する削除実行手段と、
指定された保留メールレコードが存在せず削除不可能と判定した場合、削除指示メールの送信元に、削除失敗メールを送信する削除失敗通知手段とを備えることができる。

さらにまた、前記メール保留サーバは、
受信したメールが保留したメールの解除を要求する解除指示メールであるか判定する保留解除指示判定手段と、
該保留解除指示判定手段が、受信したメールを解除指示メールであると判定した場合、前記保留メールデータベースに指定された保留メールレコードの存在を確認し、解除可能か判定する保留解除可否判定手段と、
該保留解除可否判定手段が、指定された保留メールレコードが存在して解除可能と判定した場合、前記保留メールレコードのメールエンベロープの送信先を最終送信先として、前記メールサーバに保留メールを送信し、前記保留メールデータベースから当該保留メールレコードを削除する保留解除メール送信手段と、
前記保留解除可否判定手段が、前記保留メールデータベースに指定された保留メールレコードが存在せず、解除不可能と判定した場合、前記解除指示メールのメールエンベロープの送信元に解除失敗メールを送信する保留解除失敗通知手段とを備えることができる。

前記メール保留サーバは、
前記内部クライアントから保留メールの閲覧を要求するＨＴＴＰリクエストを受信した場合に、前記保留メールデータベースの全ての保留メールレコードを検索し、保留メール一覧を出力する閲覧要求処理手段と、
該閲覧要求処理手段により出力された出力結果をＨＴＴＰレスポンスに設定し、前記内部クライアントに送信する一覧出力結果送信手段と、
前記内部クライアントから保留メールの削除又は保留解除を要求するＨＴＴＰリクエストを受信した場合に、前記保留メールデータベースの保留メールレコードから、削除又は保留解除対象のレコードを削除又は保留解除して削除する保留メールＤＢ修正手段と、
該保留メールＤＢ修正手段が削除又は保留解除して削除した後、前記保留メールデータベースを検索して保留メール一覧を出力する修正後閲覧処理手段と、
該修正後閲覧処理手段による出力結果をＨＴＴＰレスポンスに設定し、前記内部クライアントに送信する修正後一覧出力結果送信手段とを備え、
前記内部クライアントは、
前記メール保留サーバに対し、保留メールの閲覧を要求する前記ＨＴＴＰリクエストを送信する閲覧要求送信手段と、
前記メール保留サーバからＨＴＴＰレスポンスとして保留メール一覧を取得すると、取得した保留メール一覧を表示する一覧出力結果表示手段と、
前記保留メール一覧内で削除又は保留解除したい保留メールが指定されると、前記メール保留サーバに対し保留メール削除又は保留解除要求を送信する保留メールＤＢ修正要求送信手段と、
前記メール保留サーバから、削除又は保留解除して削除が行われた後の保留メール一覧を取得すると、取得した保留メール一覧を表示する修正後一覧出力結果表示手段とを備えることができる。

前記メール保留サーバは、
前記内部クライアントからメールを受信し、受信したメールの送信先が保留すべき送信先である場合、保留時間データベースから、予め設定された保留時間を取得する保留時間取得手段と、
該保留時間取得手段が取得した保留時間を設定して、前記保留メールデータベースに保留メールレコードを追加する保留メールレコード追加手段と、
前記保留時間データベースから保留時間が取得できない場合は、予め定めた所定の値を設定する保留時間設定手段とを備えることができる。

前記メール保留サーバは、
受信したメールから誤送信の可能性の高さを示す高誤送信度を算出し、追加保留時間を算出する高誤送信度・追加保留時間算出手段と、
前記保留メールデータベースに保留メールレコードを記憶する際、前記保留時間データベースから取得した保留時間と、前記追加保留時間を加算して、保留時間に設定する追加保留時間加算手段とを備えることができる。

前記メール保留サーバは、
前記内部クライアントから受信したメールの前記メールエンベロープの送信先を参照し、送信先が保留対象送信先であると判断すると、当該送信先が承認依頼対象となる送信先であるか否かを判断する承認依頼対象当否判断手段と、
該承認依頼対象当否判定手段により、承認依頼対象と判断された場合、保留メールのメールエンベロープから当該送信先を削除する送信先削除手段と、
承認依頼メールデータベースの承認依頼メールレコードに格納されている承認待ちメールの宛先に、当該送信先を追加する送信先追加手段と、
当該メールに対する承認依頼メールレコードが作成されていない場合は、当該メールに対応する承認依頼メールレコードを作成し、一意の承認依頼メールＩＤを付与し、現在時刻を承認依頼開始時刻として設定し、当該メール本体を承認待ちメールとして格納した後に、承認待ちメールの宛先を当該送信先に置き換える送信先置き換え手段と、
前記承認依頼対象当否判定手段により承認依頼対象と判断され、メール承認が必要な宛先が存在する場合、所定の宛先について承認依頼を行う旨の通知メールを、メール送信元の内部クライアントに対して送信する承認依頼実行通知メール送信手段と、
前記承認依頼対象当否判定手段により承認依頼対象と判断された場合、予め承認依頼定義データベースに設定された当該メールのユーザのユーザＩＤに対応するレコードを参照し、職制承認者リスト及びユーザ定義承認者リストに設定されている承認者のユーザＩＤに対応するメールアドレスをすべてリストアップして、承認依頼メールデータベースにおける当該承認依頼メールＩＤに対応するレコードの承認者リストに設定する承認者リスト設定手段と、
前記承認依頼定義データベースにおいて当該ユーザのユーザＩＤに対応するレコードに、承認権限代理者リストが定義されている場合には、当該代理者のユーザＩＤに対応するメールアドレスもすべて承認者リストに追加する承認権限代理者追加手段と、
元の送信メールに対して一意の承認依頼メールＩＤを文字列としてメールの題名に付した承認依頼メールを、承認者リストに設定された承認者クライアントのメールアドレス宛送信する承認依頼メール送信手段と、
該承認依頼メール送信手段による承認依頼後、長時間にわたって承認／却下結果返信が行われない場合、前記内部クライアントに対して定期的に承認が未処理である旨の通知メールを送信する承認督促メール送信手段と、
前記承認者クライアントから承認または却下の返信が行われた場合、元の送信元の内部クライアントに対して、承認／却下結果の通知メールを送信する承認／却下結果通知メール送信手段と
をさらに備えることができる。

前記メール保留サーバは、
前記承認者クライアントから、承認または却下の返信メールを受信すると、当該承認／却下結果、承認者、受信時刻等を監査ログとして取得し、監査ログデータベースに記録する監査ログ記録手段と、
当該返信メールの題名に、承認依頼メールデータベースに存在するいずれかの承認依頼メールＩＤが文字列として含まれていること、及び承認または却下を示す、あらかじめ定めたキーワードが含まれていること、の双方を満たしている場合に承認／却下返信メールであると認識する承認／却下返信認識手段と、
当該返信者のメールアドレスが、当該メールの題名中に示された承認依頼メールＩＤに対応する承認者リストに含まれているか否かによって当該承認／却下返信メールが正規の承認者からの返信メールであるか否か判断する返信者当否判定手段と、
該返信者当否判定手段により、正規の承認者からの返信メールであると判断された返信メールについて当該返信が承認か却下かを判定する承認是非判定手段と、
該承認是非判定手段にて「承認」と判定された場合、当該承認依頼メールＩＤに対応する承認待ちメールを外部クライアントに対して送信する承認待ちメール送信手段と、
当該承認依頼メールＩＤに対応するレコードを承認依頼メールデータベースから削除する承認依頼レコード削除手段と
を備えることができる。

前記メール保留サーバは、
前記メールエンベロープまたは前記メールヘッダ、題名・本文等から前記特定ドメイン名、前記特定キーワード、前記添付ファイル種別とを取得し、予め優先度ポリシーＤＢに設定されたドメイン名、キーワード、添付ファイル種別に対応するレコードを参照し、当該ドメイン名、キーワード、添付ファイル種別に対応するレコードの優先度ＩＤと優先者ポリシーを判定する手段と、
前記特定ドメイン名、前記特定キーワード、前記特定添付ファイルが複数ある場合は、最も重要度の高いものを、前記メールの優先度ＩＤおよび優先者ポリシーと判定する手段と、
前記判定した優先者ポリシーの定義に適合する承認者を優先承認者と判定する手段と、
ユーザ端末から、出社時刻、退社時刻、ログオン状況、予定を取得し、在席状況データベースに格納する在席確認手段と、
前記在席状況データベースを参照し、優先承認候補者が在席してるか否かを判定する手段と、
在席であれば、通知メールに優先承認者である旨を付加する手段と、
をさらに備えることができる。

本発明によれば、電子メールを送信前に所定時間保留すると共に、組織内等、情報漏洩とはならない送信先には保留することなく先に送信することで、電子メール送信者の誤操作や悪意による情報漏洩を防止する電子メール保留システムを提供することができる。

削除指示判定、削除可否判定、削除実行、削除失敗通知を行う発明によれば、上記効果に加え、内部クライアント側から、保留したメールを削除することができる。

保留解除指示判定、保留解除可否判定、保留解除メール送信、保留解除失敗通知を行う発明によれば、上記効果に加え、内部クライアント側から、保留したメールの保留解除を行なうことができる。

メール保留サーバが閲覧要求処理、一覧出力結果送信、保留メールＤＢ修正、修正後閲覧処理、修正後一覧出力結果送信を行い、内部クライアントが閲覧要求送信、一覧出力結果表示、保留メールＤＢ修正要求、修正後一覧出力結果表示を行う発明によれば、上記効果に加え、内部クライアントによって、保留メール一覧を閲覧できると共に、保留メール一覧を介して、保留メールの削除又は保留解除を行なうことができる。

メール保留サーバが、保留時間取得、保留メールレコード追加、保留時間設定の処理を実行する発明によれば、上記効果に加え、保留時間のよりきめ細かな設定が容易になる。

メール保留サーバが、高誤送信度・追加保留時間算出、追加保留時間加算の処理を実行する発明によれば、上記効果に加え、受信したメールのメール本文から誤送信度を算出し、誤送信度に基づく追加保留時間を加算して設定することができる。

メール保留サーバが、承認依頼対象当否判定、送信先削除、送信先追加、送信先置き換え、承認依頼実行通知メール送信、承認者リスト設定、承認権限代理者追加、承認依頼メール送信、承認督促メール送信、承認／却下結果通知メール送信を実行する発明によれば、上記効果に加え、外部への送信メールに対して第三者による承認機能を設けることにより、外部者に対する誤送信または悪意による送信を、より確実に防止することができる。

監査ログ記録、承認／却下返信認識、返信者当否判定、承認是非判定、承認待ちメール送信、承認依頼レコード削除処理を実行する発明によれば、上記効果に加え、正規の承認者による承認がなされたメールを外部クライアントに対して送信することができる。

優先者判定、在席確認の処理を実行する発明によれば、上記効果に加え、承認者が複数いる場合、優先順位を判定し、承認者の優先順位を通知することができる。

図１は、実施形態１における、電子メール保留システムのシステム構成図である。 図２は、実施形態１における、保留メールＤＢのデータ構成図である。 図３は、実施形態１における、メールのデータ構成図である。 図４は、実施形態１における、メール保留判定手段の動作例１を示すフローチャートである。 図５は、実施形態１における、保留メール送信手段の動作を示すフローチャートである。 図６は、実施形態１における、削除指示メールのデータ構成図である。 図７は、実施形態１における、メール保留判定手段の動作例２を示すフローチャートである。 図８は、実施形態１における、解除指示メールのデータ構成図である。 図９は、実施形態１における、メール保留判定手段の動作例３を示すフローチャートである。 図１０は、実施形態２における、電子メール保留システムのシステム構成図である。 図１１は、実施形態２における、保留メール閲覧手段の動作を示すフローチャートである。 図１２は、実施形態２における、保留メール検索手段の動作を示すフローチャートである。 図１３は、実施形態２における、保留メール削除手段の動作を示すフローチャートである。 図１４は、実施形態２における、保留メール一覧画面の表示例である。 図１５は、実施形態３における、電子メール保留システムのシステム構成図である。 図１６は、実施形態３における、保留メールＤＢのデータ構成図である。 図１７は、実施形態３における、保留時間ＤＢのデータ構成図である。 図１８は、実施形態３における、メール保留判定手段の動作の第１の例を示すフローチャートである。 図１９は、実施形態３における、メール保留判定手段の動作の第２の例を示すフローチャートである。 図２０は、実施形態４における、電子メール保留システムのシステム構成図である。 図２１は、実施形態４における、承認依頼メールＤＢのデータ構成図である。 図２２は、実施形態４における、承認依頼定義ＤＢのデータ構成図である。 図２３は、実施形態４における、承認ポリシー定義ＤＢのデータ構成図である。 図２４は、実施形態４における、送信メールの第三者承認機能の流れを示すシーケンス図である。 図２５は、実施形態４における、メール保留・承認要否判定処理のフローチャートである。 図２６は、実施形態４における、メール承認／却下結果処理のフローチャートである。 図２７は、実施形態５における、承認依頼定義ＤＢのデータ構成図である。 図２８は、実施形態５における、送信メールの第三者承認機能の流れを示すシーケンス図である。 図２９は、実施形態５における、保留メール検索手段の動作を示すフローチャートである。 図３０は、実施形態５における、保留メール削除手段の動作を示すフローチャートである。 図３１は、実施形態６における、電子メール保留システムのシステム構成図である。 図３２は、実施形態６における、優先者ポリシーＤＢのデータ構成図である。 図３３は、実施形態６における、在席状況ＤＢのデータ構成図である。 図３４は、実施形態６における、第三者承認機能の流れを示すシーケンス図である。 図３５は、実施形態６における、優先者判定処理を示すフローチャートである。

以下、図面を参照しつつ本発明の実施形態を説明する。
尚、上記サーバ及びクライアントはＣＰＵを備えたコンピュータであり、上記各手段は、ＣＰＵが必要なコンピュータプログラムを読み込んで実行することにより実現される手段であり、以下に記載されるサーバー及びクライアントについても同様である。

図１は、実施形態１における、電子メール保留システムのシステム構成図である。
なお、以降の説明および図面においては、電子メールを「メール」と略記する。

＜電子メール保留システムの全体的な構成および機能＞
電子メール保留システムは、内部クライアント１（内部クライアント１ａおよび内部クライアント１ｂ）、メール保留サーバ２、メールサーバ４、ルータ６、および外部クライアント５の各装置を、有線又は無線の通信回線により通信可能に接続したシステムである。各装置は１台ずつ図示しているが、それぞれ２以上存在していても良い。例えば、図１においては、内部クライアント１として、内部クライアント１ａと内部クライアント１ｂの２台の装置を明示しているが、内部クライアント１は３台以上存在してもよい。なお、内部クライアント１ａおよび内部クライアント１ｂは同様の構成・機能を備えた装置であり、以降、特に区別する必要のない場合は、「内部クライアント１」と記載する。
また、各装置はそれぞれ１台ずつ存在する必要はなく、例えば、１台の装置が、メール保留サーバ２とメールサーバ４の両方の機能を備えるように構成することも可能である。

図１において、内部クライアント１、メール保留サーバ２、メールサーバ４、およびルータ６はＬＡＮ（Local Area Network）７によって互いに通信可能に接続されている。接続方法はＬＡＮに限定されるものではなく、互いに通信可能に接続されていればよい。また、図１においては、外部クライアント５がインターネット８によってＬＡＮ７と接続されているが、例えば、外部クライアント５がＬＡＮ７とは別のＬＡＮに接続されており、ルータ６がこれらのＬＡＮ同士を接続していても構わない。

以上のような構成、および各装置が後述する機能を備えていることにより、電子メール保留システム全体は、以下のような機能を備えている。
内部クライアント１が外部クライアント５宛に送信したメールは、まずメール保留サーバ２が受信する。メール保留サーバ２は受信したメールを所定の条件に従って、直ちに送信するか所定時間だけ保留するかを判定する。そして、メール保留サーバ２は直ちに送信すべきメール、および所定の保留時間を経過したメールをメールサーバ４に送信する。メールサーバ４は受信したメールをルータ６経由で外部クライアント５に送信する。なお、「直ちに送信する」とは、保留することなく送信処理を行うという意味に過ぎず、文字通りに短時間でメールが送信されることを要さない。
内部クライアント１（例えば内部クライアント１ｂ）が内部クライアント１宛（例えば内部クライアント１ａ宛）に送信したメールは、同様に、まずメール保留サーバ２が受信する。メール保留サーバ２は受信したメールを直ちにメールサーバ４に送信する。メールサーバ４が受信したメールは、図示していないがメールサーバ４の記憶装置内に記憶され、後述するように、内部クライアント１ａの操作者は、内部クライアント１ａを操作することで記憶されたメールを閲覧することができる。

以上のように、メール保留サーバ２を備えることで、内部クライアント１に特別な構成・機能を備えることなく、内部クライアント１が外部クライアント５宛に送信したメールだけを選択的に、所定の条件に従って所定時間だけ保留した後に送信することができる。
逆に、外部クライアント５が内部クライアント１宛（例えば内部クライアント１ａ宛）に送信したメールは、インターネット８を経由してルータ６が受信し、ルータ６は受信したメールをＬＡＮ７を経由してメールサーバ４に送信する。メールサーバ４が受信したメールは、図示していないがメールサーバ４の記憶装置内に記憶され、後述するように、内部クライアント１ａの操作者は、内部クライアント１ａを操作することで記憶されたメールを閲覧することができる。
なお、以上説明したメール送受信処理の各過程において、内部クライアント１、外部クライアント５、メール保留サーバ２、メールサーバ４およびルータ６は、必要に応じて、図示していないがそれぞれの主記憶装置等に、送受信するメールを記憶する。

＜電子メール保留システムの各装置の構成および機能＞
内部クライアント１が外部クライアント５宛に送信するメールに着目し、メールが送受信される順に沿って、各装置の構成・機能を説明する。
内部クライアント１はＰＣ等の装置であり、入力装置１８、および表示装置１９と通信可能に接続されている。
図１においては、入力装置１８、表示装置１９を、内部クライアント１ａについては、それぞれ、入力装置１８ａ、表示装置１９ａと、内部クライアント１ｂについては、それぞれ、入力装置１８ｂ、表示装置１９ｂと記載している。以降の説明において、特に区別する必要のない場合は、入力装置１８ａおよび入力装置１８ｂを「入力装置１８」と、表示装置１９ａおよび表示装置１９ｂを「表示装置１９」と記載する。

入力装置１８はキーボード、マウス等の装置であり、内部クライアント１の操作者は入力装置１８を操作することで、内部クライアント１が実行するべき処理を指示することができる。表示装置１９は液晶ディスプレイ、プリンタ等であり、内部クライアント１が実行した処理の結果等を表示する。すなわち、入力装置１８、表示装置１９は、それぞれ内部クライアント１の入力手段、表示手段として機能する。
内部クライアント１は図示していないがＣＰＵ（Central Processing Unit）、主記憶装置、および磁気ディスク等の記憶装置を備えている。内部クライアント１の主記憶装置等は、内部クライアント１の記憶手段として機能する。
ＣＰＵは、記憶装置に記憶されている各種プログラム（例えば、メール送受信プログラム）を、主記憶装置上にローディングし、その命令コードを実行することで各種の処理を実行する。
以上のようなプログラム実行にかかわる技術は周知であるので、以降の説明および図面においては、プログラム実行に係る説明が煩雑になるのを避けるため、メール送受信プログラムをメール送受信手段１１というように、各種プログラムについてあたかもハードウェアが存在するかのように記載し、各手段が処理を実行するかのように記載する。なお、実際に各手段（例えばメール送受信手段１１）をハードウェア（電子装置等）、またはハードウェアとファームウェアの組合せで構成することも可能である。

メール送受信手段１１（メール送受信手段１１ａおよびメール送受信手段１１ｂ）は上述したようにメール送受信プログラムであり、例えばＯＵＴＬＯＯＫ（ＯＵＴＬＯＯＫは登録商標）のような、いわゆるメーラソフトである。なお、以降の説明において、メール送受信手段１１ａとメール送受信手段１１ｂを特に区別する必要のない場合は、「メール送受信手段１１」と記載する。
メール送受信手段１１は、送信メールをまずメール保留サーバ２に送信するように設定されている。このような設定は、例えば、メール送受信プログラムの環境設定時に、送信サーバとして、メール保留サーバ２のＩＰ（Internet Protocol）アドレスを設定することで可能である。

メール保留サーバ２はＰＣ等の装置であり、記憶装置３と通信可能に接続されている。記憶装置３は磁気ディスク等の装置であり、メール保留サーバ２に内蔵され又は外部接続される。記憶装置３と、図示していないがメール保留サーバ２の主記憶装置等は、メール保留サーバ２の記憶手段として機能する。
記憶装置３は、保留メールＤＢ（Data Base）３１を備えている。保留メールＤＢ３１には、所定時間だけ保留した後に送信すべきメールが記憶される。

メール保留サーバ２には、入力装置２８および表示装置２９も通信可能に接続されている。入力装置２８はキーボード、マウス等の装置であり、メール保留サーバ２の操作者は入力装置２８を操作することで、メール保留サーバ２が実行するべき処理を指示することができる。表示装置２９は液晶ディスプレイ、プリンタ等であり、メール保留サーバ２が実行した処理の結果等を表示する。すなわち、入力装置２８、表示装置２９は、それぞれメール保留サーバ２の入力手段、表示手段として機能する。
メール保留サーバ２は、メール送受信手段２１（メール送受信プログラム）、メール保留判定手段２２（メール保留判定プログラム）、および保留メール送信手段２３（保留メール送信プログラム）を備えている。

メール送受信手段２１は、例えばＳｅｎｄｍａｉｌ（ＳＥＮＤＭＡＩＬは登録商標）等の、いわゆるＳＭＴＰ（Simple Mail Transfer Protocol）サーバソフトであり、メールを送受信する機能を有している。
メール保留判定手段２２は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールを所定時間保留する必要があるか判定し、保留する必要があるメールを保留メールＤＢ３１に記憶し、保留する必要がないメールは、直ちにメールサーバ４に送信する。すなわち、メール保留判定手段２２はメール送受信手段２１の機能の一部を代替する。
なお、メール保留判定手段２２は、本発明のさまざまな実施形態のそれぞれにおいて、異なる振る舞いをする場合があるので、解決手段の項においては、メール保留可否判定手段、保留時間経過判定手段、削除指示判定手段、削除可否判定手段、保留解除指示判定手段、保留解除可否判定手段、など判定対象となる内容ごとに異なるネーミングをしてある。

保留メール送信手段２３は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のＯＳ（Operating System）により）所定の時間間隔で継続的に起動される。保留メール送信手段２３は、保留メールＤＢ３１に記憶された各メールについて、保留時間を経過したか判定し、保留時間が経過したメールをメールサーバ４に送信する。そして、メールサーバ４に送信したメール（すなわち保留時間が経過したメール）を保留メールＤＢ３１から削除する。

以上のように、主としてメール保留判定手段２２と保留メール送信手段２３により、所定の条件に合致するメールが所定時間だけ保留された後に送信されることになる。すなわち、メール保留判定手段２２と保留メール送信手段２３は、メール保留・送信手段として機能する。
メールサーバ４はＰＣ等の装置であり、メール送受信手段４１（メール送受信プログラム）を備えている。メール送受信手段４１は、メール送受信手段２１と同様、ＳＭＴＰサーバソフトであり、メール保留サーバ２から受信したメールの宛先がＬＡＮ７に接続された機器である場合（例えば内部クライアント１ａ宛である場合）、図示していないが、メールサーバ４の記憶装置内に記憶する。一方、メール保留サーバ２から受信したメールの宛先がＬＡＮ７に接続された機器でない場合（例えば外部クライアント５宛である場合）、受信したメールをルータ６に送信する。
ルータ６は、ＬＡＮ７に接続された装置以外の宛先に送信されるメールを、インターネット８に送信する。逆に、このような機能を備えている装置であれば良く、必ずしもルータである必要はない。
インターネット８に送信されたメールは、図示していないが各種通信装置を経由して送信先（例えば外部クライアント５）が受信する。

外部クライアント５は内部クライアント１と同様に、ＰＣ等の装置であり、入力装置５８、および表示装置５９と通信可能に接続されている。入力装置５８はキーボード、マウス等の装置であり、外部クライアント５の操作者は入力装置５８を操作することで、外部クライアント５が実行するべき処理を指示することができる。表示装置５９は液晶ディスプレイ、プリンタ等であり、外部クライアント５が実行した処理の結果等を表示する。すなわち、入力装置５８、表示装置５９は、それぞれ外部クライアント５の入力手段、表示手段として機能する。
外部クライアント５はメール送受信手段５１（メール送受信プログラム）を備えている。メール送受信手段５１はいわゆるメーラソフトであり、外部クライアント５を送信先とするメールを受信する。

次に、内部クライアント１ａにメールが送信された場合を例として、各装置の構成・機能についての説明を補足する。
メールサーバ４にはＰＯＰ（Post Office Protocol）サーバ（プログラム）をさらに備えることもできる。
内部クライアント１ｂが内部クライアント１ａ宛に送信したメールは、メール保留サーバ２を経てメールサーバ４に送信される。メールサーバ４が受信したメールは図示していないが、メールサーバ４の記憶装置内に記憶される。そして、内部クライアント１ａの操作者は、入力装置１８ａを操作することで、メール送受信手段１１ａに、内部クライアント１ａ宛のメールを取得するように指示する。メール送受信手段１１ａは、メールサーバ４のＰＯＰサーバに、内部クライアント１ａ宛のメールを送信するように要求する。そして、メールサーバ４のＰＯＰサーバが送信したメールの一覧等を、表示装置１９ａに表示する。

また、外部クライアント５が内部クライアント１ａ宛に送信したメールは、インターネット８、ルータ６を経由して、メールサーバ４に送信される。メールサーバ４が受信したメールは図示していないが、メールサーバ４の記憶装置内に記憶されるので、内部クライアント１ａの操作者は、入力装置１８ａを操作することで、メールサーバ４のＰＯＰサーバが送信したメールの一覧等を、表示装置１９ａに表示させることができる。
以上のようにして、内部クライアント１ａの操作者は、内部クライアント１ａを操作することでメールの一覧や内容を閲覧することができる。

＜以上のようなシステム構成・機能による効果＞
以上のように、メール保留サーバ２とメールサーバ４を備えることで、次のような効果を得ることができる。
まず、既にメールサーバ４等によるメール送受信システムが構築されている場合、メールサーバ４とは別にメール保留サーバ２をＬＡＮ７に接続することで、外部クライアント５等が内部クライアント１宛に送信してくるメールの送受信の流れに影響を与えることなく、電子メール保留システムを構築することができる。すなわち、電子メール保留システム構築時のシステムの信頼性を向上させることができる。
また、メールを常に迅速に送信すべき特権的な立場の、内部クライアント１の操作者が存在する場合、当該内部クライアント１についてはメールサーバ４へのログインを許可し、メール保留サーバ２を経由せずにメールを送信できるようにすることで、メールを保留せずに送信することも容易になる。
しかしながら、メール送受信システムを新たに構築するような場合には、メール保留サーバ２とメールサーバ４を分けず、例えば、メール保留サーバ２のみの構成としてもよい。このようにすることで、電子メール保留システムを最小限度の機器で構築することができる。ただし、この場合、前述したような、メールを常に迅速に送信すべき特権的な立場の操作者については、例えば、メール保留判定手段２２において、操作者のＩＤ等を認証して、メールを保留せずに送信する等の機能を備える必要がある。

図２は、実施形態１における、保留メールＤＢ３１のデータ構成図である。
保留メールＤＢ３１は、０個以上の保留メールレコード３１０から構成される（保留すべきメールが存在しない場合には、保留メールレコード３１０は存在しない）。
保留メールレコード３１０は、保留メールＩＤ３１１、保留開始時刻３１２、および保留メール３１４の３つのデータ項目から構成される。保留メールレコード３１０の追加、更新、削除等は、図示していないが、メール保留サーバ２が備える、ＭｙＳＱＬ（ＭｙＳＱＬは登録商標）等のデータベース管理手段（プログラム）によって行われる。例えば、メール保留判定手段２２は、ＳＱＬ等によって、データベース管理手段に、保留メールレコード３１０を追加するように指示する。保留メール送信手段２３は、同様にデータベース管理手段に、保留メールレコード３１０を削除するように指示する。

保留メールＩＤ３１１は、保留メールレコード３１０を一意に識別するためのＩＤ（Identifier）である。例えば、図示していないが、記憶装置３に１を初期値とするカウンタを記憶しておき、保留メールレコード３１０を追加するたびに、“０００１”、“０００２”、“０００３”といったように、１を初期値とする通番を設定し、同時にカウンタを１ずつ加算すればよい。
保留開始時刻３１２には、例えば“２００８０４２８１３１５０４”（２００８年４月２８日１３時１５分４秒）といったように、保留メールレコード３１０を追加する際の時刻が設定される。保留メール送信手段２３は、保留開始時刻３１２とシステム時刻を比較することで、保留時間が経過したか判定する。
保留メール３１４には、保留しているメールの内容が設定される。具体的には、図３を使用して説明する。

図３は、実施形態１における、保留メール３１４のデータ構成図である。
保留メール３１４は、メールエンベロープ３１５、メールヘッダ３１６、および本文３１７から構成される。
本文３１７は、内部クライアント１の操作者が入力したメールの本文、およびメールに添付したファイルからなる。また、メールヘッダ３１６は、内部クライアント１の操作者が入力したメールの宛先、タイトル等を、メール送受信手段２１が編集した結果データからなる。すなわち、メールヘッダ３１６、および本文３１７は、内部クライアント１がメール保留サーバ２に送信したメールの内容である。
メールエンベロープ３１５は、メールの送信元（mail from）と、１以上の送信先（rcpt to）から構成され、後述するように、メール保留判定手段２２が、受信したメールから作成する。内部クライアント１の操作者は、送信先としてメーリングリストのアドレス等、実際の宛先とは異なる宛先を入力する場合がある。そこで、メール保留判定手段２２は、メールを受信すると、メールに設定されている（操作者が入力した）送信先を実際の送信先に変換して送信先（rcpt to）を作成する。そして、送信元（mail from）と送信先（rcpt to）をメールエンベロープ３１５としてメールに追加する。

図４は、実施形態１における、メール保留判定手段２２の動作を示すフローチャートの第１の例である。
メール送受信手段２１は、メールの受信を検知すると、メール保留判定手段２２を起動する。
メール保留判定手段２２は、メールを受信し、メールエンベロープ３１５を追加する（Ｓ４０１）。
次に、メール保留判定手段２２は、メールエンベロープ３１５の全ての送信先（rcpt to）を順に参照し、以下の処理を行う（Ｓ４０２〜Ｓ４０６）。
メール保留判定手段２２は、送信先（rcpt to）がメールを保留すべき送信先（保留対象送信先）かどうかを判定する（Ｓ４０３）。具体的には、送信元（mail from）のドメインと送信先（rcpt to）のドメインを比較し、一致しない場合には保留対象送信先と判定する。図３の例では、送信元（mail from）のドメインが“ｈｉｔａｃｈｉｓｏｆｔ．ｊｐ”なので、これと一致しない“ｅｘａｍｐｌｅ．ｃｏｍ”ドメインを含む送信先が、保留対象送信先と判定される。

メール保留判定手段２２は、送信先（rcpt to）が保留対象送信先である場合（Ｓ４０３でＹＥＳの場合）次の送信先（rcpt to）について判定を行う。
一方、送信先（rcpt to）が保留対象送信先でない場合（Ｓ４０３でＮＯの場合）、当該送信先（rcpt to）をメールエンベロープ３１５から削除し（Ｓ４０４）、当該送信先（rcpt to）のみをメールの（最終）送信先として、メールサーバ４宛にメールを送信する（Ｓ４０５）。
なお、送信するメールのメールヘッダ３１６および本文３１７としては、メール保留判定手段２２が受信したメールのメールヘッダ３１６および本文３１７を設定する。メールヘッダ３１６の送信先（Ｔｏ）は以上の処理によって変更されないので、メールの受信者は、送信者が入力した送信先全てを知ることができ、当該メールが外部（保留対象送信先）にも送信されることを知ることができる。なお、内部宛にメールを送信する際（Ｓ４０５）、送信先（rcpt to）に保留対象送信先が含まれているかを判定し、含まれている場合に、例えば本文３１７の冒頭に「外部にも送信されます」等のメッセージを付加してもよい。こうすることで、内部のメール受信者が、受信したメールの内容や宛先を慎重に確認することが期待できる。

メール保留判定手段２２は、全ての送信先（rcpt to）について以上の処理（Ｓ４０２〜Ｓ４０６）を終了すると、保留メールＤＢ３１に保留メールレコード３１０を追加する（Ｓ４１３）。このとき、保留メールＩＤ３１１には、保留メールレコード３１０を一意に識別可能なＩＤ（例えば１を初期値とする通番）を設定する。保留開始時刻３１２には、保留メールレコード３１０を追加する際のシステム日時・時刻を設定する。また、保留メール３１４には、Ｓ４０２〜Ｓ４０６の処理後のメールエンベロープ３１５（すなわちＳ４０５の処理によりメールを送信した送信先（rcpt to）以外の送信先（rcpt to）が設定されているメールエンベロープ３１５）、およびメールヘッダ３１６、本文３１７を設定する。なお、全ての送信先（rcpt to）について、Ｓ４０５の処理によりメールを送信済みの場合には、保留メールレコード３１０は追加しない。

以上の処理により、所定の条件に合致するメール（送信元と送信先のドメインが不一致の送信先（rcpt to）が指定されているメール）は保留され、一方、所定の条件に合致しないメールは、直ちに送信先に送信される。また、一部の送信先（rcpt to）について所定の条件に合致する場合には、当該一部の送信先（rcpt to）について、メールが保留され、一方、所定の条件に合致しない送信先（rcpt to）について、メールが直ちに送信先に送信される。
なお、保留対象送信先の判定（所定の条件に合致するか否かの判定）は、送信元と送信先のドメインを比較する以外の方法によってもよい。
例えば、ドメインの一部だけを比較してもよい。また、記憶装置３に直ちに送信してもよい送信先のドメインを１以上記憶しておき、送信先（rcpt to）ドメインが、このいずれとも一致しない場合に保留するようにしてもよい。このようにすることで、企業等の組織内に複数ドメインが存在する場合でも、組織内（内部）を送信先とするメールは保留せず、組織外（外部）を送信先とするメールを保留することができる。
メール保留判定手段２２は、保留メールレコード３１０を追加すると処理を終了する。

図５は、実施形態１における、保留メール送信手段２３の動作を示すフローチャートである。
保留メール送信手段２３は、前述したように、メール保留サーバ２のＯＳにより、所定の時間間隔で継続的に起動される。
保留メール送信手段２３は、起動されると、保留メールＤＢ３１に記憶された全ての保留メールレコード３１０を順に参照し、以下の処理を行う（Ｓ５０１〜Ｓ５０５）。
保留メール送信手段２３は、保留メールレコード３１０が保留時間を経過したか判定する（Ｓ５０２）。具体的には、判定時点のシステム日時・時刻と保留開始時刻３１２を比較し、判定時点において予め定めた所定時間（例えば１５分間）を経過したか判定する。
そして、保留時間を経過している場合（Ｓ５０２でＹＥＳの場合）、当該保留メール（保留メール３１４）をメールサーバ４に送信する（Ｓ５０３）。このとき、当該保留メールレコード３１０のメールエンベロープ３１５に設定されている全ての送信先（rcpt to）を、メールの（最終）送信先とする。
保留メール送信手段２３は、メールの送信処理（Ｓ５０３）が正常に終了した場合、当該保留メールレコード３１０を保留メールＤＢ３１から削除する。
保留メール送信手段２３は、以上の処理（Ｓ５０１〜Ｓ５０５）を終えると、処理を終了する。
以上の処理により、保留されたメールは所定時間経過後、特別な操作を行うことなく、自動的に送信される。

なお、保留メール送信手段２３は、所定の時間間隔で継続的に起動されるのでなく、例えば、メール保留サーバ２の操作者が、入力装置２８を操作することで起動するようにしてもよい。また、メール保留サーバ２の操作者が、入力装置２８を操作し、データベース管理手段（プログラム）にＳＱＬ等による指示を行い、表示装置２９に保留メールレコード３１０の一覧や保留メールの内容を表示させるようにするとよい。このようにすることで、メール保留サーバ２の操作者が定期的に保留メールの内容を確認し、送信してもよいと判断した時点で、保留されたメールを送信することが可能になる。
また、メール保留サーバ２の操作者は、保留メール送信手段２３を起動する前に、保留メールレコード３１０の保留開始時刻３１２を書き換え、あたかも所定時間が経過したようにすることもできる。このようにすることで、保留メール送信手段２３を起動するたびに、全ての保留メールレコード３１０について保留メール３１４が送信され、保留メールレコード３１０が削除されるので、既に内容確認済みの保留メールを何度も確認するといった重複を回避することができる。

さらに、メール保留サーバ２の操作者は、送信してはいけないメール（例えば営業秘密情報が本文に記載されているメール）が保留されていることを確認した場合、当該保留メールレコード３１０を削除することで、送信されないようにすることができる。
以上のように、例えばメール保留サーバ２の操作者が、保留メールレコード３１０の保留状態を強制的に解除したり、保留メールレコード３１０を削除することは容易であり、また、そのための専用プログラムが不要であるというメリットもある。

しかしながら、組織において送信されるメール全てについて、メール保留サーバ２の操作者が内容を確認するという方法は、現実的でない場合が多い。従って、保留されているメールの内容確認等は、できるだけ多数の人間が手分けして行うことが望ましい。
具体的には、保留されたメールを直ちに受信した者（例えば、送信者とドメインが同一の受信者）が、当該メールの内容を確認し、外部に送信すべきでない（破棄すべきメール）と判断した場合に、保留されているメールの保留メールレコード３１０を削除できるようにすればよい。すなわち、メールの受信者は、そのメールの内容について関心があり、かつ、メールの内容を思い込みなく冷静かつ客観的に確認できるので、破棄すべきメールであると気づく可能性が高いからである。
この点、自分が送信したメールを後で再確認することは一般的には期待できないので、メールの送信者が、破棄すべきメールであると気づく可能性は低い。しかし、その可能性もゼロではないので、メールの送信者も、保留されているメールの保留メールレコード３１０を削除できるようにすればよい。
これを実現する一つの方法として、送信済みメールが破棄すべきメールであると気づいた場合に、各内部クライアント１が、メール保留サーバ２に該当する保留メールレコード３１０を削除するように要求できるようにすればよい。例えば、メール送受信手段１１が、保留メールレコード３１０の削除を指示する特別なメール（削除指示メール）を送信するようにすればよい。

図６は、実施形態１における、削除指示メールのデータ構成図である。
内部クライアント１が送信した削除指示メールは、通常のメールと同様に、メール保留判定手段２２が受信し、メールエンベロープ３１５を追加する。
図６は、メールエンベロープ３１５が追加された後の削除指示メールのデータ構成図である。ここで、メールヘッダ３１６の送信先（Ｔｏ）には、特別な送信先“[email protected]”が設定されている。内部クライアント１の操作者は、メール送受信手段１１によって削除指示メールを作成する際に、送信先として、この特別な送信先を指定する。そして、メール保留判定手段２２は、この送信先が指定されていることで、通常のメールに対する処理と異なる処理を行う。

また、本文３１７の先頭には、［ＤＥＬＥＴＥ］の文字が入力されている。内部クライアント１の操作者は、メール送受信手段１１によって削除指示メールを作成する際に、本文に［ＤＥＬＥＴＥ］の文字を入力する。そして、メール保留判定手段２２は、本文３１７の先頭文字が［ＤＥＬＥＴＥ］であることで、保留メールレコード３１０を削除する処理を行う。
この他に、内部クライアント１の操作者は、どの保留メールレコード３１０を削除すべきか指定する必要がある。これは例えば、メールのタイトルとして、削除すべき保留メールレコード３１０に設定されている保留メール３１４のタイトル（すなわち、メールヘッダ３１６のSubjectとして設定されている文字）を入力することで、可能である。

次に、削除指示メールを受信した場合の、メール保留判定手段２２の処理内容を説明する。
図７は、実施形態１における、メール保留判定手段２２の動作を示すフローチャートの第２の例である。
第２の例においては、メール保留判定手段２２は、図４によって説明した通常のメールについての処理に加え、削除指示メールについての異なる処理を行う。ここで、図７のＳ４０１、Ｓ４０２〜Ｓ４０６、Ｓ４１３の処理内容は図４と同じであるので、説明を省略する。
メール保留判定手段２２は、受信したメールが保留したメールの削除を要求するメール（削除指示メール）であるか判定する（Ｓ４２１）。具体的には、メールエンベロープ３１５の送信先（rcpt to）が特別な送信先（例えば“[email protected]”）であり、かつ、本文３１７の先頭文字が［ＤＥＬＥＴＥ］である場合、削除指示メールと判定する。
メール保留判定手段２２は、受信したメールが削除指示メールであると判定した場合（Ｓ４２１でＹＥＳの場合）、保留メールＤＢ３１から、指定された保留メールレコード３１０を削除可能か判定する（Ｓ４２２）。例えば、指定された保留メールレコード３１０が存在するか否か判定する。具体的には、例えば、全ての保留メールレコード３１０を参照し、削除指示メールと、メールエンベロープ３１５の送信元（mail from）およびメールヘッダ３１６のタイトル（Subject）が一致するレコードが存在する場合、指定された保留メールレコード３１０が存在すると判定すればよい。

メール保留判定手段２２は、指定された保留メールレコード３１０が存在し削除可能と判定した場合（Ｓ４２２でＹＥＳの場合）、保留メールＤＢ３１から当該保留メールレコード３１０を削除する（Ｓ４２３）。そして、削除指示メールの送信元（メールエンベロープ３１５の送信元（mail from））に、削除通知メールを送信する（Ｓ４２４）。
削除通知メールの本文には、「以下のメールを削除しました」といったメッセージとともに、削除したメールのメールヘッダ３１６、本文３１７等を設定するとよい。こうすることで、削除指示メールを送信した内部クライアント１の操作者は、削除指定した保留メールが正しく削除されたか否かを確認することができる。
一方、メール保留判定手段２２は、指定された保留メールレコード３１０が存在しない等の理由で削除不可能と判定した場合（Ｓ４２２でＮＯの場合）、削除指示メールの送信元に、削除失敗メールを送信する（Ｓ４２５）。
削除失敗メールの本文には、「以下のメールは削除できません」といったメッセージとともに、削除指示メールのメールヘッダ３１６、本文３１７等を設定するとよい。こうすることで、削除指示メールを送信した内部クライアント１の操作者は、どの削除指示メールが失敗したかを確認することができる。

なお、Ｓ４２３において、例えば、送信元（mail from）かつタイトル（Subject）が同一の保留メールレコード３１０（削除対象レコード）が複数存在する場合、メール保留判定手段２２は、その全てを削除してもよい。このようにする場合、誤って同じメールを何度も送信したような場合、一度の削除指示メールによって、纏めて削除することができる。
また、保留開始時刻３１２が最も新しい日時である保留メールレコード３１０のみを削除するようにしてもよい。一般的には、より最近送信したメールが、より最近確認されるはずなので、削除対象である可能性が高い。従って、このようにする場合、削除すべきでない保留メールレコード３１０を削除する危険性は低くなる。
さらに、例えば、削除指示メールの本文３１７先頭に、［ＤＥＬＥＴＥ］の文字に加えて、保留メールＩＤ３１１を指定するようにしてもよい。この場合、メール保留判定手段２２は、Ｓ４２２において、指定された保留メールＩＤ３１１によって、削除対象レコードの有無を判定する。

一方、削除指示メールに、保留メールＩＤ３１１が指定されていない場合は、既に説明したように、送信元（mail from）かつタイトル（Subject）が同一の保留メールレコード３１０が存在するか否かによって、削除対象レコードの有無を判定する。そして、削除対象レコードが複数存在する場合、保留メールレコード３１０を削除することなく（Ｓ４２３の処理を行わず）、削除通知メールの本文に、「削除すべきメールのＩＤを指定してください」といったメッセージとともに、当該複数の削除対象レコードの保留メールＩＤ３１１、メールヘッダ３１６、本文３１７等を設定する。
以上のようにすることで、内部クライアント１の操作者は、削除が必要な保留メールレコード３１０を保留メールＩＤ３１１によって特定することが可能になる。従って、このようにする場合、削除すべきでない保留メールレコード３１０を削除する危険性を最小限にすることができる。

ところで、送信したメールが所定条件に合致する場合に常に所定時間だけ保留される場合、急ぎの場合等は不都合である。従って、メールの保留状態を解除し、直ちに送信できるようにすることが望ましい。例えば、削除指示メールと同様に、解除指示メールによって、メールの保留状態を解除することができる。

図８は、実施形態１における、解除指示メールのデータ構成図である。
内部クライアント１が送信した解除指示メールは、通常のメールと同様に、メール保留判定手段２２が受信し、メールエンベロープ３１５を追加する。
図８は、メールエンベロープ３１５が追加された後の解除指示メールのデータ構成図である。ここで、メールヘッダ３１６の送信先（Ｔｏ）には、削除指示メールと同様、特別な送信先“[email protected]”が設定されている。内部クライアント１の操作者は、メール送受信手段１１によって解除指示メールを作成する際に、送信先として、この特別な送信先を指定する。そして、メール保留判定手段２２は、この送信先が指定されていることで、通常のメールに対する処理と異なる処理を行う。
また、本文３１７の先頭には、［ＲＥＬＥＡＳＥ］の文字が入力されている。内部クライアント１の操作者は、メール送受信手段１１によって解除指示メールを作成する際に、本文に［ＲＥＬＥＡＳＥ］の文字を入力する。そして、メール保留判定手段２２は、本文３１７の先頭文字が［ＲＥＬＥＡＳＥ］であることで、保留メールレコード３１０を保留状態から解除する処理を行う。
また、保留状態から解除すべき保留メールレコード３１０を指定するためには、削除指示メールと同様、メールのタイトルとして、解除すべき保留メールレコード３１０に設定されている保留メール３１４のタイトルを入力すればよい。
次に、解除指示メールを受信した場合の、メール保留判定手段２２の処理内容を説明する。

図９は、実施形態１における、メール保留判定手段２２の動作を示すフローチャートの第３の例である。
第３の例においては、メール保留判定手段２２は、図４によって説明した通常のメールについての処理に加え、解除指示メールについての異なる処理を行う。ここで、図７のＳ４０１、Ｓ４０２〜Ｓ４０６、Ｓ４１３の処理内容は図４と同じであるので、説明を省略する。また、図９においては、削除指示メールについての処理を明示していないが、削除指示メールについての処理と解除指示メールについての処理は相反するものではなく、両方について処理を行うことも可能である。具体的には、図９のＳ４０１とＳ４３１の処理の間に、図７のＳ４２１の判定処理を加え、Ｓ４２１においてＹＥＳの場合にＳ４２１〜Ｓ４２５の処理を行い、ＮＯの場合に、Ｓ４３１の判定を行うようにすることで、削除指示メールと解除指示メールの両方について、処理を行うようにすることができる。

メール保留判定手段２２は、受信したメールが保留したメールの解除を要求するメール（解除指示メール）であるか判定する（Ｓ４３１）。具体的には、メールエンベロープ３１５の送信先（rcpt to）が特別な送信先（例えば“[email protected]”）であり、かつ、本文３１７の先頭文字が［ＲＥＬＥＡＳＥ］である場合、解除指示メールと判定する。
メール保留判定手段２２は、受信したメールが解除指示メールであると判定した場合（Ｓ４３１でＹＥＳの場合）、保留メールＤＢ３１から、指定された保留メールレコード３１０を解除可能か判定する（Ｓ４３２）。例えば、指定された保留メールレコード３１０が存在するか否か判定する。具体的には、例えば、全ての保留メールレコード３１０を参照し、解除指示メールと、メールエンベロープ３１５の送信元（mail from）およびメールヘッダ３１６のタイトル（Subject）が一致するレコードが存在する場合、指定された保留メールレコード３１０が存在すると判定すればよい。

メール保留判定手段２２は、指定された保留メールレコード３１０が存在し解除可能と判定した場合（Ｓ４３２でＹＥＳの場合）、メールエンベロープ３１５の送信先（rcpt to）を（最終）送信先として、メールサーバ４に保留メール３１４を送信する（Ｓ４３３）。そして、メール保留判定手段２２は、保留メールＤＢ３１から当該保留メールレコード３１０を削除する（Ｓ４３４）。
一方、メール保留判定手段２２は、指定された保留メールレコード３１０が存在しない等の理由で解除不可能と判定した場合（Ｓ４３２でＮＯの場合）、メールエンベロープ３１５の送信元（mail from）に、解除失敗メールを送信する（Ｓ４３５）。
解除失敗メールの本文には、「以下のメールは保留解除できません」といったメッセージとともに、解除指示メールのメールヘッダ３１６、本文３１７等を設定するとよい。こうすることで、解除指示メールを送信した内部クライアント１の操作者は、どの解除指示メールが失敗したかを確認することができる。

なお、Ｓ４３３〜Ｓ４３４において、例えば、送信元（mail from）及びタイトル（Subject）が同一の保留メールレコード３１０（解除対象レコード）が複数存在する場合、削除指示メールについての処理と同様に、さまざまな処理が可能である。
以上のように、メール保留サーバ２を備えることで、内部クライアント１に専用プログラムを備えることなく、メールを所定の条件で保留したり、保留したメールが送信されないようにしたり、逆に直ちに送信されるようにできる。

以降では、さらに利便性を高めた実施形態について説明する。
図１０は、本発明に係る実施形態２における、電子メール保留システムのシステム構成図である。
実施形態１と実施形態２の相違点は、内部クライアント１およびメール保留サーバ２の構成・機能である。以下、この点について説明する。
実施形態２において、内部クライアント１は、さらに保留メール閲覧手段（保留メール閲覧プログラム）１２を備えている。
保留メール閲覧手段１２（保留メール閲覧手段１２ａおよび保留メール閲覧手段１２ｂ）は、保留メールＤＢ３１の記憶内容を閲覧するためのプログラムであり、例えばＷＥＢブラウザである。保留メール閲覧手段１２を一般のＷＥＢブラウザによって実現することで、内部クライアント１に専用プログラム等を備えることなく、以降で説明するように、記憶装置３に記憶されている保留メールの一覧・内容を表示装置１９に表示することができる。一方、保留メール閲覧手段１２を保留メール閲覧機能に特化した専用プログラム等によって実現すれば、より機能や操作性に優れた保留メール閲覧手段１２を実現することも可能である。

なお、以降の説明において、保留メール閲覧手段１２ａと保留メール閲覧手段１２ｂを特に区別する必要のない場合は、「保留メール閲覧手段１２」と記載する。
実施形態２において、メール保留サーバ２は、さらにＨＴＴＰ処理手段（ＨＴＴＰ処理プログラム）２４、保留メール検索手段（保留メール検索プログラム）２５、および保留メール削除手段（保留メール削除プログラム）２６を備えている。
ＨＴＴＰ処理手段２４は、例えばＡｐａｃｈｅ等の、いわゆるＷＥＢサーバソフトであり、ＷＥＢブラウザ等が送信したＨＴＴＰリクエストを受信し、要求された処理を行い、処理結果をＨＴＴＰレスポンスとして送信する機能を有している。

保留メール検索手段２５は、ＨＴＴＰ処理手段２４が保留メールの閲覧を要求するＨＴＴＰリクエストを受信した場合に、ＨＴＴＰ処理手段２４によって起動され、保留メールＤＢ３１から所定の条件に合致する保留メールレコード３１０を検索し、検索結果をＷＥＢページに編集して出力する。保留メール検索手段２５が出力したＷＥＢページは、ＨＴＴＰ処理手段２４がＨＴＴＰレスポンスに設定し、保留メールの閲覧を要求したＷＥＢブラウザ等に送信する。保留メール検索手段２５は、例えばＣＧＩ（Common Gateway Interface）を利用して実現することができる。

保留メール削除手段２６は、ＨＴＴＰ処理手段２４が保留メールの削除を要求するＨＴＴＰリクエストを受信した場合に、ＨＴＴＰ処理手段２４によって起動され、保留メールＤＢ３１から所定の条件に合致する保留メールレコード３１０を削除する。保留メール削除手段２６も保留メール検索手段２５と同様に、例えばＣＧＩ（Common Gateway Interface）を利用して実現することができる。

以上のような構成・機能により、内部クライアント１の操作者は、ＷＥＢブラウザ、または専用プログラム等を使用して、保留メールの一覧・内容等を表示装置１９に表示し、表示内容を確認しながら、削除すべき保留メールや保留状態を解除すべき保留メールを選択することが可能になる。

以下、フローチャートを使用して、保留メール閲覧手段１２、保留メール検索手段２５、および保留メール削除手段２６の詳細動作を説明する。
図１１は、実施形態２における、保留メール閲覧手段１２の動作を示すフローチャートである。
なお、図１１においては、保留メール閲覧手段１２がＷＥＢブラウザによって実現されているという前提で説明を行うが、前述したように、保留メール閲覧手段１２は、保留メール閲覧のための専用プログラムであってもよい。
まず、内部クライアント１の操作者は、入力装置１８を操作してＷＥＢブラウザを起動し、ＷＥＢブラウザは、表示装置１９にＷＥＢブラウザの画面（ＷＥＢ画面）を表示する。
内部クライアント１の操作者が、ＷＥＢ画面のＵＲＬ（Uniform Resource Locator）入力フィールドに、保留メール検索を行うための所定のＵＲＬ（例えば「http://horyu.hitachisoft.jp/cgi=horyusearch」）を入力し、入力装置１８を操作して画面を送信するように指示すると、保留メール閲覧手段１２は、入力された所定のＵＲＬ等をＨＴＴＰリクエストに設定して、メール保留サーバ２に送信する。これによって、保留メール検索要求がなされる（Ｓ１１０１）。
保留メール閲覧手段１２は、ＨＴＴＰレスポンスとして保留メール一覧を取得すると（Ｓ１１０２）、取得した保留メール一覧をＷＥＢ画面に表示する（Ｓ１１０３）。

図１４は、保留メール一覧画面の表示例である。図１４に示したように、ＷＥＢ画面全体（Ｄ１４００）の上部にＵＲＬ入力フィールド（Ｄ１４０１）があり、内部クライアント１の操作者が入力した、保留メール検索を行うための所定のＵＲＬが表示されている。また、ＵＲＬ入力フィールド（Ｄ１４０１）の下方に、保留メール一覧エリア（Ｄ１４０２）および「削除」ボタン（Ｄ１４０６）が配置されている。
保留メール一覧エリア（Ｄ１４０２）は、見出しフィールド（Ｄ１４０３）とデータエリア（Ｄ１４０４）に分かれており、保留メール一覧エリア（Ｄ１４０２）全体が上下にスクロール表示可能である。

見出しフィールド（Ｄ１４０３）には、データエリア（Ｄ１４０４）に表示する保留メール一覧の各データ項目の見出しが表示される。図１４の例では、保留メールＩＤ、送信者（保留メール送信元のメールアドレス）、件名（保留メールのタイトル）、送信先（保留メール送信先のメールアドレス）、日付（保留メールの保留開始日）、および残り時間（保留メールが保留メール送信手段２３によって送信されるまでの残り時分秒）が表示されているが、表示するデータ項目はこれらに限られるのもではなく、電子メール保留システム運用上の都合や内部クライアント１の操作者の要望に応じて、適切に定めればよい。また、保留メール一覧画面の構成についても、同様に必要に応じて適切に定めればよい。

データエリア（Ｄ１４０４）には、保留メールのデータ項目が、見出しフィールド（Ｄ１４０３）に対応して表示される。図１４の例では、１つの保留メールについてデータ項目内容を例示しているが、実際には、検索された保留メール全てが表示される。このほか、図１４の例では、各保留メールに対応して、データエリア（Ｄ１４０４）の左端にチェックボックス（Ｄ１４０５）が表示されている。内部クライアント１の操作者は、入力装置１８（例えばマウス）を操作してチェックボックス（Ｄ１４０５）をクリックすることで、削除したい保留メールを指定することができる。

すなわち、内部クライアント１の操作者が、「削除」ボタン（Ｄ１４０６）を押下すると、保留メール閲覧手段１２は、削除が指示されたと判定し（Ｓ１１０４でＹＥＳの場合）、いずれの保留メールについて削除指示がなされたかを示す情報等を、ＨＴＴＰリクエストに設定し、メール保留サーバ２に送信する。これによって、保留メール削除要求がなされる（Ｓ１１０５）。より具体的には、保留メール閲覧手段１２は、例えば、“cgi=horyudelete? Id=0001”（保留メールＩＤ３１１に「０００１」が設定された保留メールレコード３１０を削除）というデータが設定されたＨＴＴＰリクエストを、メール保留サーバ２に送信する。
保留メール閲覧手段１２は、ＨＴＴＰレスポンスとして、指示した削除が行われた後の、保留メール一覧を取得すると（Ｓ１１０６）、取得した保留メール一覧をＷＥＢ画面に表示する（Ｓ１１０３）。
以上の処理は、内部クライアント１の操作者が、保留メールの閲覧等を続けている限り、繰り返される。

保留メール閲覧手段１２は、以上の動作に加え、以下の動作を行うようにすることもできる。例えば、保留メール一覧画面において、保留メールＩＤ（図１４において“０００１”）をクリックすると、当該保留メールのヘッダ、本文の内容等を、例えば別画面で表示するようにできる。これにより、削除すべき保留メールの確認がより容易になる。この場合、当該別画面で、送信先の変更入力を可能にしてもよい。
また、例えば、ＵＲＬ入力フィールド（Ｄ１４０１）と保留メール一覧エリア（Ｄ１４０２）の間に、検索条件フィールドを設け、検索対象とすべき送信者、送信先等の検索条件を指定できるようにしてもよい。これにより、保留メールを的を絞って表示することが可能になる。また、保留メール一覧エリア（Ｄ１４０２）での保留メールの表示順番を残り時間が短い順にしてもよい。これにより、より迅速な確認が必要な保留メールについて、優先的に確認することが容易になる。

図１２は、実施形態２における、保留メール検索手段２５の動作を示すフローチャートである。
保留メール検索手段２５は、ＨＴＴＰ処理手段２４が、保留メール閲覧手段１２から保留メールの閲覧を要求するＨＴＴＰリクエスト（例えば、“cgi=horyusearch”が設定されたＨＴＴＰリクエスト）を受信した場合に、ＨＴＴＰ処理手段２４によって起動される。
保留メール検索手段２５は、起動すると、保留メールＤＢ３１の全ての保留メールレコード３１０を検索し、保留メール一覧を作成する（Ｓ１２０１）。

図１４の保留メール一覧画面を表示する場合には、保留メールレコード３１０の、保留メールＩＤ３１１、メールヘッダ３１６の送信元（From）設定内容、メールヘッダ３１６のタイトル（Subject）設定内容、メールヘッダ３１６の送信先（To、Cc、Bcc）設定内容、保留開始時刻３１２に設定された年月日、および保留メールが保留メール送信手段２３によって送信されるまでの残り時分秒（保留開始時刻３１２以降の経過時間を、予め定めた所定時間（例えば１５分間）から、減算した値）等を、ＷＥＢブラウザによって表示可能なＨＴＭＬ（HyperText Markup Language）形式に編集することで、保留メール一覧を作成する。

ここで、残り時分秒が０未満になる場合がある。この場合、当該保留メールは、保留メール送信手段２３が、次回起動された際に送信されるので、削除が必要か否かの確認を急ぐ必要がある。そこで、残り時分秒が０未満である場合、赤字、太字、イタリック等、他の表示項目と異なった態様で表示することが好ましい。また、残り時分秒が０未満の場合に加え、例えば残り時分秒が３分未満である等、保留メール送信手段２３による送信が差し迫っている場合に、他の表示項目と異なった態様で表示してもよい。

また、メールヘッダ３１６の送信先（To、Cc、Bcc）設定内容のうち、Ｂｃｃについては、送信元以外に見られるのは好ましくない場合が多い。Ｂｃｃが送信元以外に見られないようにするためには、ＢｃｃそのものをＨＴＭＬ形式に編集するのでなく、例えば、Ｂｃｃに送信元と異なるドメインのメールアドレスが含まれている場合に“外部あてに送信”といった文字を編集すればよい。また、後述するように、保留メールの閲覧・削除についてユーザＩＤによるアクセス制限をかけるような場合は、保留メール検索を要求したユーザＩＤと保留メールの送信者のユーザＩＤを比較し、当該メールの送信元からの保留メール検索要求である場合は、ＢｃｃそのものをＨＴＭＬ形式に編集すればよい。

なお、前述したように、ＷＥＢ画面（図１４）において、検索対象とすべき送信元、送信先等の検索条件を指定できるようにすることができる。例えば、送信元を指定する場合、ＨＴＴＰリクエストにおいて、“cgi=horyusearch?sender=aaa.hitachisoft.jp”（送信元が「aaa.hitachisoft.jp」である保留メールを検索）のように、検索条件を示すことができる。この場合、保留メール検索手段２５は、メールエンベロープ３１５の送信元（mail from）が、aaa.hitachisoft.jpと一致する保留メールレコード３１０を検索する。同様に、例えば“cgi=horyusearch?sender=aaa.hitachisoft.jp?order=time”等とすることで、保留メール一覧を、残り時間の昇順に作成するように指定することもできる。
保留メール検索手段２５は、作成した保留メール一覧を出力する（Ｓ１２０２）。出力結果は、ＨＴＴＰ処理手段２４がＨＴＴＰレスポンスに設定し、保留メール閲覧手段１２に送信する。

図１３は、実施形態２における、保留メール削除手段２６の動作を示すフローチャートである。
保留メール削除手段２６は、ＨＴＴＰ処理手段２４が、保留メール閲覧手段１２から保留メールの削除を要求するＨＴＴＰリクエスト（例えば、“cgi=horyudelete? Id=0001”が設定されたＨＴＴＰリクエスト）を受信した場合に、ＨＴＴＰ処理手段２４によって起動される。
保留メール削除手段２６は、起動すると、保留メールＤＢ３１の保留メールレコード３１０から、削除対象のレコード（例えば、保留メールＩＤ３１１の設定値が“０００１”であるレコード）を削除する（Ｓ１３０１）。削除レコードは１レコードである必要はなく、例えば、ＨＴＴＰリクエストに“cgi=horyudelete? Id=0001,0003”が設定されている場合、保留メールＩＤ３１１の設定値が“０００１”であるレコードと“０００３” であるレコードの２レコードを削除するようにすることができる。

保留メール削除手段２６は、指定された保留メールレコード３１０を削除した後、保留メールＤＢを検索して保留メール一覧を作成し（Ｓ１３０２）、作成した保留メール一覧を出力する（Ｓ１３０３）。Ｓ１３０２およびＳ１３０３の処理内容は、それぞれ、保留メール検索手段２５のＳ１２０１、Ｓ１２０２の処理と同じである。出力結果（保留メール一覧）は、ＨＴＴＰ処理手段２４がＨＴＴＰレスポンスに設定し、保留メール閲覧手段１２に送信する。
保留メールの保留状態の解除についても、保留メールの削除と同様の方法で行うことが可能である。例えば、保留メール閲覧手段１２から保留メールの解除を要求するＨＴＴＰリクエスト（例えば、“cgi=horyurelease? Id=0001”が設定されたＨＴＴＰリクエスト）を受信した場合に、ＨＴＴＰ処理手段２４が、図示していないが、保留メール解除手段を起動するようにすればよい。

実施形態２における、電子メール保留システムにおいては、以上のような構成・機能を備えることで、内部クライアント１の操作者は、保留メールの一覧・内容等を表示装置１９に表示し、表示内容を確認しながら、削除すべき保留メールや保留状態を解除すべき保留メールを選択することが可能になる。すなわち、全ての内部クライアント１の操作者が保留メールの一覧・内容等を表示し、また削除することができる。従って、送信すべきでないメール（例えば営業秘密情報が本文に記載されているメール）であると気づいた操作者は誰でも保留メールを削除でき、送信すべきでないメールが誤って外部に送信される危険性を減少させることができる。

しかしながら、逆に、当該メールとは無関係の操作者に保留メールの内容を知られる、すなわち一部の操作者以外に知られてはならないメール（例えば個人情報が本文に記載されているメール）が閲覧されたり、あるいは、誤操作や悪意によって削除される危険性は高くなる。この危険性を減少させるためには、保留メールの閲覧・削除についてアクセス制限をかければよい。
例えば、内部クライアント１の操作者が一覧表示および削除可能な保留メールを、当該操作者が送信元又は送信先であるメールに限定すればよい。

このようにするためには、例えば、保留メールの検索を行うための所定のＵＲＬ（例えば“http://horyu.hitachisoft.jp”）が指定された場合に、ＨＴＴＰ処理手段２４が内部クライアント１に認証要求画面を送信し、内部クライアント１のＷＥＢブラウザが、当該認証要求画面を表示装置１９に表示する。そして、内部クライアント１の操作者が、予め定められたユーザＩＤ、パスワードを入力することで、認証が行われるようにすればよい。
そして、例えば記憶装置３に、内部クライアント１の操作者のユーザＩＤとメールアドレスを対応付けて記憶しておけばよい。
保留メール閲覧手段１２とＨＴＴＰ処理手段２４は、認証済みのユーザＩＤを、ＨＴＴＰｃｏｏｋｉｅ等によって保持する。そして、保留メール検索手段２５は、メールヘッダ３１６の（To、Cc、Bcc）から、実際の送信先（rcpt to）を求め、この実際の送信先（rcpt to）またはメールエンベロープ３１５の送信元（mail from）に、当該ユーザＩＤと対応するメールアドレスが含まれている場合に、保留メール一覧の作成対象とする。同様に、保留メール削除手段２６も削除指定された保留メールレコード３１０について、実際の送信先（rcpt to）またはメールエンベロープ３１５の送信元（mail from）に、削除指示した操作者のユーザＩＤと対応するメールアドレスが含まれている場合に、削除するようにすればよい。

次に、保留メールの保留時間をメールの内容等によって変更可能とする方法等について説明する。
図１５は、本発明に係る実施形態３における、電子メール保留システムのシステム構成図である。
実施形態２と実施形態３の相違点は、メール保留サーバ２および記憶装置３の構成・機能である。以下、この点について説明する。
実施形態３において、記憶装置３は、さらに保留時間ＤＢ３２を備えている。また、後述するように、保留メールＤＢ３１のデータ構成が、実施形態２（および実施形態１）と異なる。また、メール保留判定手段２２は、実施形態２（および実施形態１）と異なり、メールの内容等によって保留時間を変える。さらに、保留メール送信手段２３の動作が、実施形態２（および実施形態１）と異なる。
以上のような構成・機能により、内部クライアント１から送信されたメールが情報漏洩の危険性が高いメールである場合に、より長時間保留し、一方、危険性が低いメールについては短時間保留することが可能になる。

以下、データ構成図を使用して、保留メールＤＢ３１および保留時間ＤＢ３２のデータ内容を詳述するとともに、フローチャートを使用して、メール保留判定手段２２および保留メール送信手段２３の詳細動作を説明する。
図１６は、実施形態３における、保留メールＤＢ３１のデータ構成図である。
保留メールＤＢ３１は、実施形態２（および実施形態１）と同様に、０個以上の保留メールレコード３１０から構成される。
保留メールレコード３１０は、保留メールＩＤ３１１、保留開始時刻３１２、保留時間３１３、および保留メール３１４の４つのデータ項目から構成される。
保留メールＩＤ３１１、保留開始時刻３１２、および保留メール３１４の設定内容等は、図２によって説明した通りである。
保留時間３１３には、例えば“００１５００”（０時間１５分０秒）といったように、保留メールレコード３１０を保留すべき時間が設定される。保留メール送信手段２３は、保留開始時刻３１２とシステム時刻を比較し、保留時間３１３が経過した場合に、保留メール３１４を送信する。

図１７は、実施形態３における、保留時間ＤＢ３２のデータ構成図である。
保留時間ＤＢ３２は、０個以上の保留時間レコード３２０から構成される（メールアドレス等によって保留時間を決める必要がない場合には、保留時間レコード３２０は存在しない）。
保留時間レコード３２０は、メールアドレス３２１、および保留時間３２２の２つのデータ項目から構成される。保留時間レコード３２０の追加、更新、削除等は、図示していないが、保留メールレコード３１０と同様に、メール保留サーバ２が備える、データベース管理手段（プログラム）によって行われる。例えば、メール保留サーバ２の操作者は、データベース管理手段を使用して、所定の値を設定した保留時間レコード３２０を追加し、あるいは、保留時間レコード３２０の設定値を変更し、保留時間レコード３２０を削除することができる。
メールアドレス３２１には、例えば“aaa.hitachisoft.jp”というようにメールアドレスが設定される。保留時間３２２には、メールアドレス３２１に対応した保留時間が、例えば“０１２０００”（１時間２０分０秒）というように設定される。
メールアドレス３２１および保留時間３２２は、後述するように、メール保留判定手段２２がメールの保留時間を設定する際に参照する。

図１８は、実施形態３における、メール保留判定手段２２の動作を示すフローチャートの第１の例である。
実施形態１と同様、メール送受信手段２１は、メールの受信を検知すると、メール保留判定手段２２を起動する。
メール保留判定手段２２は、メールを受信し、メールエンベロープ３１５を追加する（Ｓ４０１）。
次に、メール保留判定手段２２は、メールエンベロープ３１５の全ての送信先（rcpt to）を順に参照し、Ｓ４０２〜Ｓ４０６の処理を行う。Ｓ４０２〜Ｓ４０６の処理内容は、実施形態１において説明したものと同じである。
メール保留判定手段２２は、全ての送信先（rcpt to）についてＳ４０２〜Ｓ４０６の処理を終了すると、保留時間ＤＢ３２から、保留時間を取得する（Ｓ４１１）。具体的には、保留時間レコード３２０のうち、メールアドレス３２１が、メールエンベロープ３１５の送信元（mail from）と同一のレコードを検索し、当該レコードの保留時間３２２を、保留時間とする。

メール保留判定手段２２は、次に、保留メールＤＢ３１に保留メールレコード３１０を追加する（Ｓ４１３）。このとき、保留メールＩＤ３１１、保留開始時刻３１２、および保留メール３１４には、実施形態１と同様に値を設定する。そして、保留時間３１３には、保留時間ＤＢ３２から取得した保留時間を設定する。ここで、Ｓ４１１において、条件を満たす保留時間レコード３２０が存在しない場合、すなわち保留時間ＤＢ３２から保留時間が取得できない場合は、予め定めた所定の値（０以上の値）を設定する。
なお、全ての送信先（rcpt to）について、Ｓ４０５の処理によりメールを送信済みの場合には、保留メールレコード３１０は追加しない。

以上の処理により、所定の条件に合致するメール（送信元と送信先のドメインが不一致の送信先（rcpt to）が指定されているメール等）は保留され、一方、所定の条件に合致しないメールは、直ちに送信先に送信される。また、一部の送信先（rcpt to）について所定の条件に合致する場合には、当該一部の送信先（rcpt to）について、メールが保留され、一方、所定の条件に合致しない送信先（rcpt to）について、メールが直ちに送信先に送信される。また、送信元によって保留時間３１３の設定値を変えることで、後述するように、保留後送信されるまでの時間を送信元によって変えることができる。従って、内部クライアント１の操作者のうち、誤送信の多い者については、保留時間を長めにすることが可能になる。

また、逆に、メールを保留してはいけない操作者については、当該操作者のメールアドレス（送信元（mail from））について保留時間レコード３２０の保留時間３２２に“０”（０時間０分０秒）を設定しておく、または、保留時間レコード３２０を作成せず、送信元（mail from）について保留時間レコード３２０が存在しない場合、Ｓ４１３において、保留時間３１３に“０”を設定するようにしておくといった方法により、最小限の保留時間で送信されるようにすることが可能になる。なお、保留時間３１３に“０”を設定した場合、保留メール送信手段２３が次回起動された際に送信されるが、逆に、それまでの間は、保留メールを削除することが可能なので、送信後、送信者または内部の受信者が誤操作等に気づいた場合、外部に送信される前に削除することも可能である。

なお、前述したように、保留メールの閲覧・削除についてユーザＩＤを参照してアクセス制限をかけるような場合、保留時間レコード３２０を、メールアドレス３２１と保留時間３２２を対にして記憶するのでなく、ユーザＩＤと保留時間３２２を対にして記憶し、Ｓ４１１において、ユーザＩＤを参照して、保留時間レコード３２０を検索してもよい。
このようにすることで、例えば、同一ユーザＩＤの操作者が複数のメールアドレスを使用している場合、各メールアドレスについて保留時間を設定する必要がなくなる。逆に、メールアドレス３２１と保留時間３２２を対にして記憶する場合には、同一ユーザＩＤの操作者が送信元を変えて送信することで、保留時間を変更することが可能になり、一刻も早く送信する必要がある場合には保留時間が短いメールアドレス（例えば保留時間が０のメールアドレス）を使用するといったことが可能になるので、利便性が向上する。

また、Ｓ４１１において、メールアドレス３２１が、メールエンベロープ３１５の送信元（mail from）と同一のレコードを検索するのでなく、メールエンベロープ３１５の送信先（rcpt to）と同一のレコードを検索するようにしてもよい。このようにすることで、メールの保留時間３１３を送信先によって変更することができる。従って、送信先が顧客先等、誤送信を行った場合にトラブルが発生する可能性が高い場合には保留時間を長めにし、例えば子会社等、誤送信を行ってもトラブルが発生する可能性が低い場合には保留時間を短めにするといったことが可能になる。このようにする場合、送信先（rcpt to）そのものではなく、送信先（rcpt to）のドメイン（例えば“example.com”）に対して、保留時間３２２を設定してもよい。このようにして、Ｓ４１１において、送信先（rcpt to）のドメインを参照して保留時間レコード３２０を検索することで、送信先メールアドレスそれぞれに対して保留時間３２２を設定するという膨大な作業を避けることができる。
また、送信元（mail from）と送信先（rcpt to）の組み合わせについて、保留時間３２２を設定しておくこともできる。このようにすることで、よりきめ細かに保留時間を決めることが可能になる。

なお、送信先（rcpt to）または送信先（rcpt to）のドメインを参照して保留時間を決める場合、一つのメールに、保留時間が異なる複数の送信先（rcpt to）が存在する可能性がある。この場合には、Ｓ４１３において、各保留時間ごとにメール（メールエンベロープ３１５、メールヘッダ３１６、および本文３１７）を複製し、保留時間が同一の送信先（rcpt to）ごとに、保留メールレコード３１０を追加すればよい。

次に、実施形態３における、保留メール送信手段２３の動作について、再び図５を使用して、実施形態１との相違点を説明する。
保留メール送信手段２３は、Ｓ５０２において、判定時点のシステム日時・時刻と保留開始時刻３１２を比較し、判定時点において保留時間３１３を経過したか判定する。従って、前述したように、保留後送信されるまでの時間を送信元等によって変えることができる。

図１９は、実施形態３における、メール保留判定手段２２の動作を示すフローチャートの第２の例である。
第２の例においては、メール保留判定手段２２は、保留時間ＤＢ３１からの保留時間の取得処理（Ｓ４１１）に加え、メール本文から誤送信度を算出し、追加保留時間を算出する（Ｓ４１２）。なお、図１９のＳ４０１〜Ｓ４０６、Ｓ４１１の処理内容はこれまでの説明と同じであるので、説明を省略する。
Ｓ４１２において、メール保留判定手段２２は、例えば、メール本文先頭付近（例えば、先頭から３行以内）に「株式会社」や「様」等、外部への送信を示唆する記載があれば送信先が誤りである可能性が高いと判定する。また、例えば、メール本文に、「送信」、「添付」等の記載があり、ファイルが添付されていない場合には、ファイル添付漏れの可能性が高いと判定する。

そして、これらの判定結果から誤送信度を算出する。例えば、上述の例であれば、送信先が誤りである可能性が高く、かつファイル添付漏れの可能性が高い場合には、誤送信度を２とし、送信先が誤りである可能性が低く、かつファイル添付漏れの可能性が低い場合には、誤送信度を０とする。また、送信先が誤りである可能性が高いか、またはファイル添付漏れの可能性が高いか、いずれかの場合には、誤送信度を１とする。以上のようにメール本文から誤送信度を算出するだけでなく、例えば、送信先として異なるドメインを有する外部のメールアドレスが指定されている等、メールヘッダからも誤送信度を算出するようにできる。

メール保留判定手段２２は、以上のように算出した誤送信度から、追加保留時間を算出する。例えば、誤送信度が０の場合には０（０時間０分０秒）、誤送信度が１の場合には１０（０時間１０分０秒）、誤送信度が２の場合には２０（０時間２０分０秒）、といったように、誤送信度を変数として、単調増加関数によって、追加保留時間を算出すればよい。なお、ここで「単調増加関数」とは広義の単調増加関数であり、すなわちｘ＞ｙである場合、ｆ（ｘ）≧ｆ（ｙ）となる関数である。
メール保留判定手段２２は、Ｓ４１３において、保留メールレコード３１０を記憶する際、保留時間ＤＢ３２から取得した保留時間と、Ｓ４１２で算出した追加保留時間を加算して、保留時間３１３に設定する。
以上の処理により、誤送信の危険性が高いメールについて、保留時間を長めに設定することが可能になる。

また、以上の処理に加え、Ｓ４１２において、誤送信の可能性があると判定した場合（誤送信度＞０の場合）、当該メールの送信元に、誤送信の可能性がある旨の通知メールを送信してもよい。この場合、通知メールの本文には、注意を喚起するメッセージとともに、保留メールのメールヘッダ３１６および本文３１７を設定すればよい。
このようにすることで、メール本文中の記載内容や、メールヘッダ等によって、いわば機械的に判断した誤送信の危険性についてはメール送信者本人の確認を促し、一方、機械的には判断できない誤送信の危険性については、送信者と同一ドメインの受信者によって確認する機会を設けることが可能になる。

次に、保留メールに対して、更に第三者による承認機能を追加し、第三者による承認または却下を受けられない間、保留メールを保留し続ける方法等について説明する。
図２０は、本発明に係る実施形態４における、電子メール保留システムのシステム構成図である。
実施形態３までとの相違点は、通常の内部クライアント１以外に承認者クライアント９を設けている点、及びメール保留サーバ２および記憶装置３の構成・機能である。以下、この点について説明する。
本実施形態においては、メール送信元としての内部クライアント１の他に、当該メールの外部クライアント５への送信について承認可否を判定する承認者クライアント９（内部クライアント９ａおよび内部クライアント９ｂ）が組織内部に設置されている。承認者クライアント９の構成は、通常の内部クライアント１と同一である。
また、メール保留サーバ２においては、メール承認依頼手段２７が追加されており、記憶装置３には承認依頼メールＤＢ３３、承認依頼メール管理ＤＢ３４、監査ログＤＢ３５が追加されている。これらの内容については後述する。

図２１は、承認依頼メールＤＢ３３のデータ構成図である。
承認依頼メールＤＢ３３は、０個以上の承認依頼メールレコード３３０から構成される（承認依頼すべきメールが存在しない場合には、承認依頼メールレコード３３０は存在しない）。
承認依頼メールレコード３３０は、承認依頼メールＩＤ３３１、承認依頼開始時刻３３２、承認者リスト３３３、および承認待ちメール３３４のデータ項目から構成され、承認者リスト３３３が加わっている以外は、図２に示した保留メールレコード３１０と同様の構成から成っている。承認者リスト３３３は、当該メールに対して承認依頼を行う承認者ＩＤまたは承認者のメールアドレスの一覧である。また、承認待ちメールのメールエンベロープの送信先（rcpt to）には、送信に承認を要する宛先のみが記されている。
承認依頼メールレコード３３０の追加、更新、削除等は、図示していないが、保留メールレコード３１０と同様、メール保留サーバ２が備える、ＭｙＳＱＬ（登録商標）等のデータベース管理手段（プログラム）によって行われる。例えば、メール承認依頼手段２７は、ＳＱＬ等によって、データベース管理手段に、承認依頼メールレコード３３０を追加するように指示する。同様にデータベース管理手段に、承認依頼メールレコード３３０を削除するように指示する。

図２２は、承認依頼定義ＤＢ３４０の構成図である。承認依頼定義ＤＢ３４０は、承認依頼メール管理ＤＢ３４に含まれる。
承認依頼定義ＤＢ３４０は、ユーザＩＤ毎に定義されたレコードから成り、各レコードには、ユーザＩＤ３４１、当該ユーザのメールアドレス３４２、承認免除フラグ３４３、職位フラグ３４４、承認ポリシーＩＤ３４５、職制承認者リスト３４６、ユーザ定義承認者リスト３４７、承認権限代理者リスト３４８等の項目から構成される。承認免除フラグ３４３は、本システムにおいて第三者に承認依頼を必要としないユーザ（例えば、社長、役員、システム管理者等）に対して設定するフラグであり、例えば、承認免除ユーザには「１」、他のユーザには「０」が設定される。職位フラグ３４４は、当該ユーザの職位を示すものであり、例えば、一般担当者「１」、主任「２」、課長「３」、部長「４」・・というように設定される。承認ポリシーＩＤ３４５は、当該ユーザが属するグループに適用される承認ポリシーを指定するものであり、当該ユーザが属する部署、職位等によって同一の承認ポリシーが設定される。承認ポリシーの詳細については後述する。

職制承認者リスト３４６は、当該ユーザの職制上の承認者（上長）のユーザＩＤの一覧である。承認者には、当該ユーザの直接の上長（例えば課長）以外に、更に上位の上長（例えば部長）等を含める必要がある場合もあり、複数名定義可能となっている。職制上の承認者は、別途定義される職制表データ等を参照して、あらかじめシステム管理者等によって、または自動的に設定されるものであり、当該ユーザ自身が設定・変更することはできない。
ユーザ定義承認者リスト３４７は、当該ユーザ自身が定義できる承認者のユーザＩＤの一覧である。当該ユーザの業務の形態によっては、必ずしも職制上の上長の下で作業しているとは限らず、職制上の上長以外の者を責任者とするプロジェクト、チーム等で作業していることもありうるので、業務形態に応じて臨機応変に承認者を追加できるようにしている。ユーザによる承認者定義は、図示しないが、ＨＴＴＰ処理手段２４等を用いて、ユーザが保持する内部クライアント１のブラウザ上で追加・変更等を行えるようにしてもよい。ただし、ユーザが無関係の承認者を定義することを防止するために、一定の職位以上の者（例えば課長以上とする場合、職位フラグ３４４が３以上の者）でなければ承認者として定義できないようにしておくことが望ましい。また、ユーザ自身の職位より上位の者（承認者の職位フラグ＞当該ユーザの職位フラグ）のみを定義可能とするようにしておいてもよい。
承認権限代理者リスト３４８は、一定の職位以上の者（例えば課長以上のみ権限委譲可能とする場合、職位フラグ３４４が３以上の者）が、自身が不在等の場合に承認権限を委譲する代理者のユーザＩＤの一覧である。承認権限代理者の設定も、ＨＴＴＰ処理手段２４等を用いて、当該ユーザが保持する内部クライアント１のブラウザ上で追加・変更等を行えるようにしてもよい。
なお、図２２に示す承認依頼定義ＤＢ３４０の各項目は単なる例示であり、このうち一部の項目のみを定義してもよく、また、必要に応じて他の項目を追加してもよい。

図２３は、承認ポリシー定義ＤＢ３５０の構成の一例を示す図である。承認ポリシー定義ＤＢ３５０は、承認依頼メール管理ＤＢ３４に含まれる。
承認ポリシー定義ＤＢ３５０は、承認ポリシーＩＤ毎に定義されたレコードから成り、この例においては、各レコードには、承認ポリシーＩＤ３５１、承認依頼必須部署フラグ３５２、添付ファイル考慮フラグ３５３、特定ドメイン名リスト３５４、特定キーワードリスト３５５等の項目から構成される。承認ポリシーは、承認依頼の要否を決定するための一連の判断基準を定義するものであり、部署、職位等に応じて異なる承認ポリシーを適用したいグループ毎に定義される。
承認依頼必須部署フラグ３５２は、当該承認ポリシーが適用される部署（例えば営業部等）の外部クライアント宛メールについて、無条件に承認依頼が必要とされるか否かを設定するフラグであり、承認依頼必須部署には「１」、他の部署には「０」が設定される。
添付ファイル考慮フラグ３５３は、添付ファイルの有無によって承認依頼要否を考慮するか否かのフラグであり、「１」ならば添付ファイルが付されている外部クライアント宛メールは承認依頼必要とし、「０」ならば添付ファイルは考慮せず、他の条件によって承認依頼要否を判断する。特定ドメイン名リスト３５４は、承認依頼を必要とする宛先のドメイン名（顧客のドメイン名等）一覧である。特定キーワードリスト３５５は、外部クライアント宛メールの題名・本文等に特定のキーワード（例えば特定の顧客名、製品名等）が含まれていれば承認依頼を必要とするためのものである。
なお、これらの判断基準項目は単なる例示であり、必要により、適宜判断基準を設定してよい。

次に、第三者承認機能の処理内容について説明する。
図２４は、送信メールの第三者承認機能の流れを示すシーケンス図である。
まず、内部クライアント１がメールを送信すると、メール保留サーバ２のメール送受信手段２１が当該メールを受信する（Ｓ５０１）。
次に、メール保留サーバ２のメール保留判定手段２１及びメール承認依頼手段２７がメール保留・承認要否判定処理を行う（Ｓ５０２）。この処理の詳細については後述する。
メール保留・承認要否判定処理（Ｓ５０２）によって、保留・承認が必要と判定され、メール承認が必要な宛先が存在する場合、メール承認依頼手段２７は、所定の宛先について承認依頼を行う旨の通知メールを、メール送信元の内部クライアント１に対して送信する（Ｓ５０３）。
また、この場合、承認依頼メール管理ＤＢ３４を参照して、承認依頼先メールアドレスの抽出を行う（Ｓ５０４）。具体的には、承認依頼定義ＤＢ３４０において、当該ユーザのユーザＩＤに対応するレコードを参照し、職制承認者リスト３４６及びユーザ定義承認者リスト３４７に設定されている承認者のユーザＩＤに対応するメールアドレス３４２をすべてリストアップして、承認依頼メールＤＢ３３における当該承認依頼メールＩＤに対応するレコードの承認者リスト３３３に設定する。また、当該ユーザのユーザＩＤに対応するレコードに、承認権限代理者リスト３４８が定義されている場合には、当該代理者のユーザＩＤに対応するメールアドレス３４２もすべて承認者リスト３３３に追加する。

次に、メール承認依頼手段２７は、元の送信メールに対して一意の承認依頼メールＩＤを文字列としてメールの題名に付した承認依頼メールを、承認者リスト３３３に設定されたメールアドレス宛に、即ち承認者クライアント９に対して送信する（Ｓ５０５）。
なお、承認依頼メールは、承認者クライアント９から承認または却下の返信が行われない間は、承認依頼メールＤＢ３４に保管されたままになるため、メール承認依頼（Ｓ５０５）後、長時間にわたって承認／却下結果返信が行われない場合、メール承認依頼手段２７は、内部クライアント１に対して定期的に承認が未処理である旨の通知メールを送信して、元のメール送信者に対して注意喚起を行う（Ｓ５０６）。当該通知メール送信は、承認依頼開始時刻３３２から一定時間（例えば１２時間、１日、２日等）経過する毎に行う。
承認者クライアント９から承認または却下の返信が行われた場合（Ｓ５０７）、メール承認依頼手段２７は、承認または却下の結果に応じた処理を行う（Ｓ５０８）。この処理の詳細については後述する。
次に、メール承認依頼手段２７は、元の送信元の内部クライアント１に対して、承認／却下結果の通知メールを送信し（Ｓ５０９）、承認済みの承認待ちメール３３４を、外部クライアント５に対して送信する（Ｓ５１０）。

図２５は、図２４のＳ５０２に示されたメール保留・承認要否判定処理のフローチャートである。
Ｓ４０１、Ｓ４０２、Ｓ４０３、Ｓ４０４、Ｓ４０５、Ｓ４０６及びＳ４１３におけるメール保留判定手段２２の動作については、図４のフローチャートと同一である。以下、図４のフローチャートとの相違点について述べる。
Ｓ４０３において、送信先（rcpt to）が保留対象送信先であると判断されると、メール承認依頼手段２７によって、当該送信先が承認依頼対象となる送信先であるか否かを判断する（Ｓ４４１）。この判断は、承認依頼定義ＤＢ３４０において、送信元のユーザＩＤに対応するレコードを参照することによって行う。
まず、承認免除フラグ３４３が「１」である場合は、当該ユーザは承認免除者なので、直ちに「ＮＯ」と判断する。
それ以外の場合、承認ポリシーＩＤ３４５が示す承認ポリシー定義ＤＢ３５０のレコードを参照して各判断基準項目について判断する。

図２３の例では、まず、承認依頼必須部署フラグ３５２が「１」の場合、全ての保留対象メールが承認依頼対象メールなので、「ＹＥＳ」と判断する。それ以外の場合、添付ファイル考慮フラグ３５３が「１」ならば、当該メールに添付ファイルが付されていれば「ＹＥＳ」と判断する。それ以外の場合、特定ドメイン名リスト３５４、特定キーワードリスト３５５を順に参照して、当該メールの宛先が特定ドメイン名リスト３５４のいずれかに合致した場合、または題名・本文中に特定キーワードリスト３５５に設定されたいずれかのキーワードに合致した場合は「ＹＥＳ」と判断する。上記いずれにも該当しない場合には「ＮＯ」と判断する。

Ｓ４４１で「ＮＯ」と判断された場合、メール承認依頼手段２７は何もせずにＳ４０６に戻る。Ｓ４４１で「ＹＥＳ」と判断された場合、当該送信先は通常の保留メールから承認依頼メールの対象に移さなければならないので、メール承認依頼手段２７は、保留メールのメールエンベロープから当該送信先(rcpt to)を削除する（Ｓ４４２）。
次に、メール承認依頼手段２７は、承認依頼メールレコード３３０に格納されている承認待ちメール３３４の宛先に、当該送信先を追加する（Ｓ４４３）。もし当該メールに対する承認依頼メールレコード３３０が作成されていない場合は、最初に当該メールに対応する承認依頼メールレコード３３０を作成し、一意の承認依頼メールＩＤを付与し（例えば、特定文字に「０００１」から順にカウントアップした数字を結合）、現在時刻を承認依頼開始時刻３３２として設定し、当該メール本体を承認待ちメール３３４として格納した後に、承認待ちメール３３４の宛先のみは、当該送信先に置き換える。その後、Ｓ４０６に戻る。

図２６は、図２４のＳ５０８に示されたメール承認／却下結果処理の、メール承認依頼手段２７による動作を示したフローチャートである。
承認者クライアント９から、承認または却下の返信メールを受信すると（Ｓ６０１）、まずは当該承認／却下結果、承認者、受信時刻等を監査ログとして取得し、監査ログＤＢ３５に記録する（Ｓ６０２）。監査ログによって、後に監査者が、承認者の承認／却下行為の妥当性等を判断する材料とすることができる。なお、メール承認依頼手段２７は、当該返信メールの題名に、承認依頼メールＤＢ３３に存在するいずれかの承認依頼メールＩＤが文字列として含まれていること、及び承認または却下を示す、あらかじめ定めたキーワード（例えば「承認」または「却下」）が含まれていること、の双方を満たしている場合に承認／却下返信メールであると認識する。
次に、当該承認／却下返信メールが正規の承認者からの返信メールであるか否か判断する（Ｓ６０３）。正規の承認者か否かは、当該返信者のメールアドレスが、当該メールの題名中に示された承認依頼メールＩＤに対応する承認者リスト３３３に含まれているか否かによって行う。
Ｓ６０３において「ＮＯ」と判断されれば、メール承認依頼手段２７は何もせず修了し、「ＹＥＳ」と判断されれば、次に当該返信が承認か却下かを判定する（Ｓ６０４）。
当該返信が「承認」の場合、メール承認依頼手段２７は当該承認依頼メールＩＤに対応する承認待ちメール３３４を外部クライアント５に対して送信し（Ｓ６０５）、当該返信が「却下」の場合、メール送信は行わずに次の処理に移る。
最後に、メール承認依頼手段２７は、当該承認依頼メールＩＤに対応するレコードを承認依頼メールＤＢ３３から削除して（Ｓ６０６）処理を終了する。
なお、この実施形態においては、いずれかの承認者から最初に承認／却下返信メールを受付けた段階でメール承認／却下結果処理を完了させるようにしているが、承認者に優劣がある場合や、複数者の承認を得たい場合は、承認／却下結果を一時保存して、複数者の返信結果を組合わせて判断するようにしてもよい。

以上示したように、実施形態４においては、外部への送信メールに対して第三者による承認機能を設けることにより、外部者に対する誤送信または悪意による送信を、より確実に防止することができる。
しかしながら、実施形態４によると、承認が必要なメールを外部へ送信しようとすると、当該メールの送信者には、承認依頼が行われたことを通知するメール、いまだ承認されていないことを通知するメール、及び承認／却下結果を通知するメールが次々と送信されることになる。特に外部へのメール送信を頻繁に行う必要がある場合、上記のようなメールが多量に送信されると業務の妨げになりかねない。
また、承認者も、例えば部下が外部へメール送信するたびに承認依頼のメールが送信されると、実行中の業務への注意がそのたびに殺がれかねない。
そこで、メールの送信者や承認者が、メールによる通知等を受信するのでなく、自ら選択したタイミングで、承認依頼が行われていること等を確認できることが望ましい。さらに、メールによる通知等を受けるのか、自ら確認するのかを選択できることがさらに望ましい。

以下、そのような機能を備えた実施形態である、本発明による実施形態５について説明する。
まず、実施形態５における、電子メール保留システムのシステム構成は実施形態４と同じであり、既に図２１に示したとおりである。ただし、承認依頼定義ＤＢ３４０のデータ構成が実施形態４と異なり、また、各手段の動作が既に説明した動作と異なっている。以下、これらの相違点を中心に説明する。

図２７は、本発明による実施形態５における、承認依頼定義ＤＢのデータ構成図である。
実施形態４と同じく、承認依頼定義ＤＢ３４０は、ユーザＩＤ毎に定義されたレコードから成るが、各レコードは、図２２で示した項目に加え、通知要否フラグ３４９を備えている。通知要否フラグ３４９は、メールの送信者や承認者に対して、メールによる通知や承認依頼を行う必要があるか否かを示すフラグであり、「１」（メールによる通知や承認依頼を行う必要あり）又は「０」（メールによる通知や承認依頼を行う必要なし）が設定される。通知要否フラグ３４９は、各レコード作成時にシステム管理者等が設定し、各ユーザには変更できないようにしてもよいし、各ユーザが図示していないが、通知要否フラグ変更手段を操作して、自らのレコードの設定値を自由に変更できるようにしてもよい。いずれにするかは、システムのセキュリティ方針等に合せて選択すればよい。
なお、通知要否フラグ３４９以外のデータ項目の目的、設定内容等は実施形態４と同じである。

次に、実施形態５における、第三者承認機能の処理内容について説明する。
図２８は、送信メールの第三者承認機能の流れを示すシーケンス図である。実施形態４（図２４）との相違点は、メール承認依頼手段２７が、所定の宛先について承認依頼を行う旨の通知メールを、メール送信元の内部クライアント１に対して送信する（Ｓ５０３）場合、承認依頼メールを承認者クライアント９に対して送信する（Ｓ５０５）場合、内部クライアント１に対して定期的に承認が未処理である旨の通知メールを送信する場合（Ｓ５０６）、及び内部クライアント１に対して承認／却下結果の通知メールを送信する場合（Ｓ５０９）に、当該通知等が必要か否かを判定し、必要な場合にのみ当該通知等を行う点である。具体的には、実施形態４における送信メールの第三者承認機能の流れに対し、Ｓ５２０、Ｓ５２１、Ｓ５２２、及びＳ５２３の処理が加わる。

具体的には、Ｓ５２０において、メール承認依頼手段２７は、承認依頼定義ＤＢ３４０において、当該メール送信元ユーザのユーザＩＤに対応するレコードを参照し、通知要否フラグ３４９に「１」が設定されている場合（Ｓ５２０でＹＥＳの場合）は、所定の宛先について承認依頼を行う旨の通知メールを、メール送信元の内部クライアント１に対して送信する（Ｓ５０３）が、「０」が設定されている場合（Ｓ５２０でＮＯの場合）は、通知メールを送信しない。メール承認依頼手段２７は、Ｓ５２２、及びＳ５２３においても、同様の処理を行う。
また、Ｓ５２１において、メール承認依頼手段２７は、承認依頼定義ＤＢ３４０において、当該承認依頼メールの各承認者のユーザＩＤに対応するレコードを参照し、通知要否フラグ３４９に「１」が設定されている場合（Ｓ５２１でＹＥＳの場合）は、承認依頼メールを当該承認者クライアント９に対して送信する（Ｓ５０５）が、「０」が設定されている場合（Ｓ５２１でＮＯの場合）は、当該承認者クライアント９に対しては、承認依頼メールを送信しない。

実施形態５においては、以上のとおり、通知メールや承認依頼メールを送信する際に、当該通知メール等の送信先のユーザに係わる通知要否を判定し、通知が必要な場合にのみ、通知メール等を送信する。従って、ユーザは、通知の必要がない旨の設定を行っておくことにより、多量の通知メール等によって煩わされることがなくなる。
しかしながら、通知メールが送信されないということは、当該ユーザは、承認依頼が行われているために外部へのメール送信が未だ行われていないということを知るタイミングを失うということを意味する。また、承認依頼メールが送信されないということは、当該ユーザは、自分に承認依頼が行われていることを知るタイミングを失うということを意味する。
そこで、通知の必要がない旨の設定を行った場合には、承認依頼が行われたこと等を、別の手段により知る必要がある。そのためには、保留メール閲覧手段１２を使用すればよい。すなわち、保留メール一覧画面に図１４に示した、件名、送信先、日付、残り時間等の項目に加え、当該メールについて承認依頼が行われているか否か、承認依頼先ユーザＩＤ、承認結果等を表示すればよい。

具体的には、保留メール検索手段２５（実施形態２において、図１２を使用して説明済み）、及び保留メール削除手段２６（実施形態２において、図１３を使用して説明済み）の動作を以下のように変更すればよい。

図２９は、本発明による実施形態５における、保留メール検索手段２５の動作を示すフローチャートである。実施形態２との相違点は、保留メール一覧の作成（Ｓ１２０１ａ）において、保留メールＤＢ３１の全ての保留メールレコード３１０だけでなく、各保留メールレコード３１０に対応する承認依頼メールレコード３３０を参照することである。

具体的には、保留メール検索手段２５は、各保留メールレコード３１０について、承認依頼メールＩＤ３３１に保留メールＩＤ３１１と同一値が設定されている承認依頼メールレコード３３０を参照し、承認者リスト３３３等を保留メール一覧に編集する。なお、保留メール検索手段２５は、当該承認依頼メールレコード３３０が存在すれば当該メールについて承認依頼が行われていると判定し、当該承認依頼メールレコード３３０が存在しなければ当該メールについて承認依頼が行われていないと判定すればよい。

図３０は、本発明による実施形態５における、保留メール削除手段２６の動作を示すフローチャートである。実施形態２との相違点は、保留メール検索手段２５と同様、保留メール一覧の作成（Ｓ１３０２ａ）において、保留メールＤＢ３１の全ての保留メールレコード３１０だけでなく、各保留メールレコード３１０に対応する承認依頼メールレコード３３０を参照することである。
なお、当然ながら、保留メール閲覧手段１２は、ＨＴＴＰレスポンスとして保留メール一覧を取得すると（Ｓ１１０２）、取得した保留メール一覧に含まれている、当該メールについて承認依頼が行われているか否か、承認依頼先ユーザＩＤ、承認結果等についてもＷＥＢ画面に表示する（Ｓ１１０３）。

保留メール検索手段２５等が、以上のような動作を行うことにより、外部へメール送信を行ったユーザは、通知メールが送信されなくても、承認依頼が行われているために外部へのメール送信が未だ行われていないということを知ることができる。また、承認依頼されているユーザは、承認依頼メールが送信されなくても自分に承認依頼が行われていることを知ることができる。
しかしながら、メールを緊急に外部へ送信する必要がある場合、以上のように承認依頼されているユーザがそのことに気づくのを待っているわけにいかない場合もある。そこで、通知要否フラグ３４９に「０」（メールによる通知や承認依頼を行う必要なし）が設定されている場合であっても、緊急メールについてはメールによる承認依頼を行うとともに、メール送信者にも承認依頼が行われたことをメールで通知するようにしてもよい。

具体的には、メール承認依頼手段２７が、通知等が必要か否かを判定する処理（図２８の、Ｓ５２０、Ｓ５２１、Ｓ５２２、及びＳ５２３の処理）において、保留メール３１４のメールヘッダ３１６や本文３１７の内容を参照して、緊急メールかどうか判定し、緊急メールの場合には、通知要否フラグ３４９の設定内容に係わらず、メールによる通知等を行うようにすればよい。ここで、例えば、メールヘッダ３１６又は本文３１７の一部に「緊急」、「至急」等の文字が存在する場合に、緊急メールであると判定することができる。なお、承認依頼のメールを送信するか否かの判定（Ｓ５２１）においてのみ緊急メールの判定を行い、通知メールを送信するか否かの判定（Ｓ５２０、Ｓ５２２、及びＳ５２３の処理）においては緊急メールの判定を行わないようにする等、さまざまな方法をとることができる。

さらに、緊急メールでない場合においても、メール送信者や、承認依頼したユーザが、長時間にわたって保留メールの閲覧を行っていない場合、注意を喚起するために、通知メール等を送信してもよい。
具体的には、例えば、承認依頼定義ＤＢ３４０にデータ項目として保留メール閲覧日時を設け、保留メール検索手段２５が保留メール閲覧日時に処理年月日時刻を設定することで、保留メール閲覧日時には当該ユーザが保留メールを一覧した最新日時が設定されるようにする。そして、メール承認依頼手段２７は、内部クライアント１に対して定期的に承認が未処理である旨の通知メールを送信する必要があるか判定する場合（Ｓ５２２）、対象保留メールについての承認依頼開始時刻３３２と、各承認依頼先ユーザ（当該内部クライアント１のユーザにつき、承認者リスト３３３に設定されたユーザ）の保留メール閲覧日時を比較し、いずれの承認依頼先ユーザについても、承認依頼開始時刻３３２が保留メール閲覧日時以降である場合は、各承認依頼先ユーザに、保留メールを閲覧し早く承認又は却下するように要求するメールを送信すればよい。

なお、実施形態１から実施形態４までに示した、電子メール保留システムの各構成・機能はさまざまに組み合わせることが可能である。例えば、承認者が出張・年休などで不在の場合、スケジュール管理ソフトやイントラ勤休管理表等と連携して、承認者不在を判断し、不在の旨をメール送信者（承認依頼者）に通知したり、承認者が不在の場合、送信者がsubjectに「事後承認」というキーワードを入力することで、そのキーワードを検知したシステムは承認者の承認を待つことなく、メール送信するなどのさまざまな機能をさらに設けることも可能である。そうすることで、各電子メール保留システムに、より適したシステムを構築することが可能となる。

以上示したように、実施形態４においては、外部への送信メールに対して第三者による承認機能を設けることにより、外部者に対する誤送信または悪意による送信を、より確実に防止することができる。
また、実施形態５においては、通知要否の設定を行う機能、および、ブラウザでの保留メール閲覧機能を備えることで、自ら選択したタイミングで、承認依頼が行われていること等を確認できる。
しかしながら、実施形態４、５によると、複数の承認者がいる場合、どの承認者の承認を優先させるか、一人ではなく複数者の返信結果を組合わせるか否か等、承認者の優先順位を判断することができなかった。
そこで、承認者が複数いる場合、優先順位を判断し、承認者ごとに優先順位を通知し、その優先承認者に承認を促すことが望ましい。

以下、そのような機能を備えた実施形態である、本発明による実施形態６について説明する。図３１は、本発明の実施形態６における、電子メール保留システムのシステム構成図である。
実施形態５までとの相違点は、メール保留サーバ２および記憶装置３の構成・機能である。以下、この点について説明する。
本実施形態のメール保留サーバ２においては、優先者判定手段２８および在席確認手段２９が追加されており、記憶装置３には、優先度ＤＢ３６および在席ＤＢ３７が追加されている。以下、この追加した手段およびＤＢに関する処理を中心に説明する。

図３２は、本発明による実施形態６における、優先度ＤＢ３６のデータ構成図である。優先度ＤＢ３６は、優先度ＩＤごとに定義した優先度ポリシーＤＢ３６０から構成されている。優先度ポリシーＤＢ３６０は、この例においては、優先度ＩＤ３６１、キーワード３６２、ドメイン名３６３、添付ファイル種別３６４、優先者ポリシー３６５から構成される。
優先度ＩＤ３６１は、重要度を示す値である。この重要度により、承認者の職位・人数を定義している。
キーワード３６２は、承認依頼を必要とする特定のキーワードである。例えば、キーワードとして「社外秘、予算会議・・・」、「カタログ、公開・・・」 等が、優先度ＩＤ３６１（重要度）ごとに設定される。
ドメイン名３６３は、承認依頼を必要とするドメイン名である。例えば、ドメイン名として「example.com」、「hitachi.xxx.com」・・・等が、優先度ＩＤ３６１（重要度）ごとに設定される。
添付ファイル種別３６４は、承認依頼を必要とする添付ファイルの種類を示す。例えば、「暗号化文書」、「テキスト文書」 ・・・等が、優先度ＩＤ３６１（重要度）ごとに設定される。
優先者ポリシー３６５は、優先承認者の職位・人数を判断するための基準が定義される。例えば、優先度３６１の値が「Ａ」の場合、優先者ポリシー３６５には、承認者の職位が部長以上の全員の承認を必要とする「部長以上全員」が定義され、優先度３６１の値が「Ｃ」の場合、優先者ポリシー３６５には、最先の承認者一人の承認のみ必要とする「最先一人」が定義される。

図３３は、在席ＤＢ３７のデータ構成図である。在席ＤＢ３７は、承認者ＩＤごとに定義された在席状況ＤＢ３７０から構成されている。在席状況ＤＢ３７０は、この例においては、承認者ＩＤ３７１、ＩＰアドレス３７２、出社時刻３７３、退社時刻３７４、ログオン状況３７５、予定３７６から構成される。
承認者ＩＤ３７１は、承認者を識別するＩＤである。例えば、社員番号が設定される。
ＩＰアドレス３７２は、承認者の使用する端末のＩＰアドレスが設定される。これを基に承認者の端末が参照され、在席状況が取得される。
出社時刻３７３は、承認者の端末から取得した出社時刻であり、承認者ＩＤ３７１ごとに設定される。
退社時刻３７４は、承認者の端末から取得した退社した時刻であり、承認者ＩＤ３７１ごとに設定される。
ログオン状況３７５は、承認者の端末が使用されている状態であるか否かをを示す。たとえば、「ｌｏｇｏｎ」 等が、承認者ＩＤ３７１ごとに設定される。
予定３７６は、承認者の直近のスケジュールを示す。たとえば、１３時から１５時は会議に出席予定であり、その時間帯は不在である旨を示す「１３００−１５００／会議」等が設定される。

次に、実施形態６における、優先者判定処理について説明する。
図３４は、第三者承認機能の流れを示すシーケンス図である。実施形態５（図２８）との相違点は、優先者判定手段２８が、複数の承認者がいる場合、優先的に承認を行う者を判定する処理を行う点である。具体的には、実施形態５における送信メールの第三者承認機能の流れに対し、Ｓ５２４の処理が加わる。

図３５は、図３４のＳ５２４に示された優先者判定処理を示すフローチャートである。
Ｓ５０２の処理で、対象となる外部クライアント宛メールのメールエンベロープまたはメールヘッダ、題名・本文等から特定ドメイン名、特定キーワード、添付ファイルの種別を取得する。
図３４のＳ１４０１において、優先者判定手段２８は、Ｓ５０２の処理で取得した特定ドメイン名、特定キーワード、添付ファイルの種別の各値が一致するレコードを優先度ポリシーＤＢ３６０から抽出する。そのレコードから優先度ＩＤ３６１の値を取得し、これを当該メールの重要度と判定する。取得したドメイン名、キーワード、添付ファイルが複数ある場合は、最も優先度ＩＤ（重要度）の高いものを、当該メールの重要度と判定する。さらに、判定された優先度ＩＤ３６１のレコードから、そのレコードに対応する優先者ポリシー３６５を取得し、その定義に適合する職位の承認者を優先承認候補者と判断する。

図３２の例では、Ｓ５０４の処理で抽出した特定キーワードが「社外秘」の場合を説明する。
優先者判定手段２８は、優先者ポリシーＤＢ３６０のキーワード３６２が「社外秘」であるレコードを抽出する。当該レコードに対応する優先度ＩＤ３６１は、「Ａ」であり、その値を重要度 と判定する。当該レコードに対応する優先者ポリシーは「部長以上全員」であり、その定義に適合する承認者を優先承認候補者と判断する。

しかし、優先承認候補者が不在である場合が想定される。不在の場合、その承認は、長期間保留された状態となるため、迅速にメール送信したい場合に不都合が生じる。このため、優先承認候補者が在席しているか否かを判定する必要がある（Ｓ１４０２）。以下、優先承認候補者が在席であるか否かの在席判定処理２９について説明する。

在席確認手段２９は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のＯＳ（Operating System）により）所定の時間間隔で継続的に起動される。
在席判定手段２９は、承認者のＩＰアドレスを基に、承認者となりえる職位の者の端末を参照し、一定の時間間隔で、イントラ勤休管理表の出社／退社登録、およびＷｉｎｄｏｗｓ（登録商標）のログインスクリプトのログオン／ログオフ状態、さらには、スケジュール管理ソフトの予定作業／時間を取得し、その結果を、在席状況ＤＢ３７０の出社時間３７３、退社時間３７４、ログオン状況３７４、予定３７５に記録・更新する。
優先者判定処理２８は、在席状況ＤＢ３７０から、優先承認候補者のＩＤと一致する承認者ＩＤ３７１のレコードを取得する。そのレコードの出社時刻３７３、退社時刻３７４、ログオン状況３７４、予定３７５を確認し、年休等の休みではなく、会議等の予定もスケジュールされいない場合や、ログオン状態である場合に、在席していると判断し、該優先承認候補者を優先承認者と判定する。不在と判定した場合、優先順位者の決定処理に戻る。

図３３の例では、優先承認候補者として判定された承認者ＩＤ３７１「１８９ｘｘｘ」のレコードを取得し、そのレコードに対応する出社時刻３７３、退社時刻３７４を参照し、出社時刻が入力されていて、退社時刻が未入力の場合、出社していると判断する。さらに、ログオン状況３７５および予定３７６を参照し、「ｌｏｇｏｎ」状態であり、現在の時刻が、スケジュールされた会議の時間帯である１３：００〜１５：００ではない場合、在席していると判断する。

Ｓ１４０３において、優先者定義に該当する承認依頼を通知するメールに優先者である旨の記載を付加し、これを承認者に送信し通知することで、自分が承認をする必要があることを認識させる。

電子メール、とりわけ企業などの組織の構成員が、外部に対して送信する電子メールの誤送信、企業秘密の外部漏れ、個人情報の漏洩などの防止をするシステムに用いることができる。

１ａ、１ｂ 内部クライアント
２ メール保留サーバ
４ メールサーバ
３１ 保留メールデータベース
３１０ 保留メールレコード
３１２ 保留開始時刻
３１４ 保留メール
３１５ メールエンベロープ
３２ 保留時間データベース
３２１ メールアドレス
３２２ 保留時間
３３ 承認依頼メールデータベース
３３０ 承認依頼メールレコード
３３１ 承認依頼メールＩＤ
３３２ 承認依頼開始時刻
３３３ 承認者リスト
３３４ 承認待ちメール
３４ 承認依頼メール管理データベース
３４０ 承認依頼定義データベース
３４１ ユーザＩＤ
３４２ メールアドレス
３４６ 職制承認者リスト
３４７ ユーザ定義承認者リスト
３４８ 承認権限代理者リスト
３５ 監査ログデータベース
５ 外部クライアント、
９ａ，９ｂ 承認者クライアント

Claims (10)

1. 内部クライアントが、メールを所定時間保留自在のメール保留サーバを介して、メールサーバに通信自在に接続される電子メール保留システムであって、
   前記メール保留サーバは、
   前記内部クライアントからメールを受信すると、受信した前記メールに、前記メールに設定されている送信先を実際の送信先に変換した送信先と、送信元とを設定したメールエンベロープを追加するメールエンベロープ追加手段と、
   該メールエンベロープ追加手段が追加したメールエンベロープの送信先を参照し、送信先がメールを保留すべき送信先かどうかを判定するメール保留当否判定手段と、
   送信先が保留すべき送信先でない場合、保留すべき送信先でない送信先をメールエンベロープから削除し、保留すべき送信先でない送信先のみをメールの送信先として、前記メールサーバ宛にメールを送信する非保留先送信手段と、
   送信先が保留すべき送信先である場合、保留すべき送信先を有する保留メールに保留開始時刻を追加した保留メールレコードを保留メールデータベースに格納する保留メール格納手段と、
   起動された時、前記保留メールデータベースに格納された全ての保留メールレコードを順に参照し、前記保留メールレコードが所定の保留時間を経過したか判定する保留時間経過判定手段と、
   所定の保留時間を経過している場合、当該保留メールを前記メールサーバに送信する時間経過後送信手段と、
   該時間経過後送信手段によるメールの送信処理が正常に終了した場合、送信した保留メールレコードを前記保留メールデータベースから削除する保留メールレコード削除手段と
   を備える電子メール保留システム。
2. 請求項１記載の電子メール保留システムであって、
   前記メール保留サーバは、
   受信したメールが保留したメールの削除を要求する削除指示メールであるか判定する削除指示判定手段と、
   該削除指示判定手段が削除指示メールであると判定した場合、前記保留メールデータベースに指定された保留メールレコードの存在を確認し、削除可能か判定する削除可否判定手段と、
   該削除可否判定手段が、指定された保留メールレコードが存在して削除可能と判定した場合、前記保留メールデータベースから当該保留メールレコードを削除し、削除指示メールの送信元に、削除通知メールを送信する削除実行手段と、
   前記削除可否判定手段が、指定された保留メールレコードが存在せず削除不可能と判定した場合、削除指示メールの送信元に、削除失敗メールを送信する削除失敗通知手段と
   をさらに備えることを特徴とする電子メール保留システム。
3. 請求項１又は２のいずれか一に記載の電子メール保留システムであって、
   前記メール保留サーバは、受信したメールが保留したメールの解除を要求する解除指示メールであるか判定する保留解除指示判定手段と、
   該保留解除指示判定手段が、受信したメールを解除指示メールであると判定した場合、前記保留メールデータベースに指定された保留メールレコードの存在を確認し、解除可能か判定する保留解除可否判定手段と、
   該保留解除可否判定手段が、指定された保留メールレコードが存在して解除可能と判定した場合、前記保留メールレコードのメールエンベロープの送信先を最終送信先として、前記メールサーバに保留メールを送信し、前記保留メールデータベースから当該保留メールレコードを削除する保留解除メール送信手段と、
   前記保留解除可否判定手段が、前記保留メールデータベースに指定された保留メールレコードが存在せず、解除不可能と判定した場合、前記解除指示メールのメールエンベロープの送信元に解除失敗メールを送信する保留解除失敗通知手段と
   をさらに備えることを特徴とする電子メール保留システム。
4. 請求項１，２又は３のいずれか一に記載の電子メール保留システムであって、
   前記メール保留サーバは、
   前記内部クライアントから保留メールの閲覧を要求するＨＴＴＰリクエストを受信した場合に、前記保留メールデータベースの全ての保留メールレコードを検索し、保留メール一覧を出力する閲覧要求処理手段と、
   該閲覧要求処理手段により出力された出力結果をＨＴＴＰレスポンスに設定し、前記内部クライアントに送信する一覧出力結果送信手段と、
   前記内部クライアントから保留メールの削除又は保留解除を要求するＨＴＴＰリクエストを受信した場合に、前記保留メールデータベースの保留メールレコードから、削除又は保留解除対象のレコードを削除又は保留解除して削除する保留メールＤＢ修正手段と、
   該保留メールＤＢ修正手段が削除又は保留解除して削除した後、前記保留メールデータベースを検索して保留メール一覧を出力する修正後閲覧処理手段と、
   該修正後閲覧処理手段による出力結果をＨＴＴＰレスポンスに設定し、前記内部クライアントに送信する修正後一覧出力結果送信手段と
   を備え、
   前記内部クライアントは、
   前記メール保留サーバに対し、保留メールの閲覧を要求する前記ＨＴＴＰリクエストを送信する閲覧要求送信手段と、
   前記メール保留サーバからＨＴＴＰレスポンスとして保留メール一覧を取得すると、取得した保留メール一覧を表示する一覧出力結果表示手段と、
   前記保留メール一覧内で削除又は保留解除したい保留メールが指定されると、前記メール保留サーバに対し保留メール削除又は保留解除要求を送信する保留メールＤＢ修正要求手段と、
   前記メール保留サーバから、削除又は保留解除して削除が行われた後の保留メール一覧を取得すると、取得した保留メール一覧を表示する修正後一覧出力結果表示手段と
   をさらに備えることを特徴とする電子メール保留システム。
5. 請求項１，２，３又は４のいずれか一に記載の電子メール保留システムであって、
   前記メール保留サーバは、
   前記内部クライアントからメールを受信し、受信したメールの送信先が保留すべき送信先である場合、保留時間データベースから、予め設定された保留時間を取得する保留時間取得手段と、
   該保留時間取得手段が取得した保留時間を設定して、前記保留メールデータベースに保留メールレコードを追加する保留メールレコード追加手段と、
   前記保留時間データベースから保留時間が取得できない場合は、予め定めた所定の保留時間を設定する保留時間設定手段と
   を備えることを特徴とする電子メール保留システム。
6. 請求項５に記載の電子メール保留システムであって、
   前記メール保留サーバは、
   受信したメールから誤送信の可能性の高さを示す高誤送信度を算出し、追加保留時間を算出する高誤送信度・追加保留時間算出手段と、
   前記保留メールデータベースに保留メールレコードを記憶する際、前記保留時間データベースから取得した保留時間と、前記追加保留時間を加算して、保留時間に設定する追加保留時間加算手段と
   をさらに備える電子メール保留システム。
7. 請求項１，２，３，４，５又は６のいずれか一に記載の電子メール保留システムであって、
   前記メール保留サーバは、
   前記内部クライアントから受信したメールの前記メールエンベロープの送信先を参照し、送信先が保留対象送信先であると判断すると、当該送信先が承認依頼対象となる送信先であるか否かを判断する承認依頼対象当否判定手段と、
   該承認依頼対象当否判定手段により、承認依頼対象と判断された場合、保留メールのメールエンベロープから当該送信先を削除する送信先削除手段と、
   承認依頼メールデータベースの承認依頼メールレコードに格納されている承認待ちメールの宛先に、当該送信先を追加する送信先追加手段と、
   当該メールに対する承認依頼メールレコードが作成されていない場合は、当該メールに対応する承認依頼メールレコードを作成し、一意の承認依頼メールＩＤを付与し、現在時刻を承認依頼開始時刻として設定し、当該メール本体を承認待ちメールとして格納した後に、承認待ちメールの宛先を当該送信先に置き換える送信先置き換え手段と、
   前記承認依頼対象当否判定手段により承認依頼対象と判断され、メール承認が必要な宛先が存在する場合、所定の宛先について承認依頼を行う旨の通知メールを、メール送信元の内部クライアントに対して送信する承認依頼実行通知メール送信手段と、
   前記承認依頼対象当否判定手段により承認依頼対象と判断された場合、予め承認依頼定義データベースに設定された当該メールのユーザのユーザＩＤに対応するレコードを参照し、職制承認者リスト及びユーザ定義承認者リストに設定されている承認者のユーザＩＤに対応するメールアドレスをすべてリストアップして、承認依頼メールデータベースにおける当該承認依頼メールＩＤに対応するレコードの承認者リストに設定する承認者リスト設定手段と、
   前記承認依頼定義データベースにおいて当該ユーザのユーザＩＤに対応するレコードに、承認権限代理者リストが定義されている場合には、当該代理者のユーザＩＤに対応するメールアドレスもすべて承認者リストに追加する承認権限代理者追加手段と、
   元の送信メールに対して一意の承認依頼メールＩＤを文字列としてメールの題名に付した承認依頼メールを、承認者リストに設定された承認者クライアントのメールアドレス宛送信する承認依頼メール送信手段と、
   該承認依頼メール送信手段による承認依頼後、長時間にわたって承認／却下結果返信が行われない場合、前記内部クライアントに対して定期的に承認が未処理である旨の通知メールを送信する承認督促メール送信手段と、
   前記承認者クライアントから承認または却下の返信が行われた場合、元の送信元の内部クライアントに対して、承認／却下結果の通知メールを送信する承認／却下結果通知メール送信手段と
   をさらに備える電子メール保留システム。
8. 請求項７に記載した電子メール保留システムであって、
   前記メール保留サーバは、
   前記承認者クライアントから、承認または却下の返信メールを受信すると、当該承認／却下結果、承認者、受信時刻等を監査ログとして取得し、監査ログデータベースに記録する監査ログ記録手段と、
   当該返信メールの題名に、承認依頼メールデータベースに存在するいずれかの承認依頼メールＩＤが文字列として含まれていること、及び承認または却下を示す、あらかじめ定めたキーワードが含まれていること、の双方を満たしている場合に承認／却下返信メールであると認識する承認／却下返信認識手段と、
   当該返信者のメールアドレスが、当該メールの題名中に示された承認依頼メールＩＤに対応する承認者リストに含まれているか否かによって当該承認／却下返信メールが正規の承認者からの返信メールであるか否か判断する返信者当否判定手段と、
   該返信者当否判定手段により、正規の承認者からの返信メールであると判断された返信メールについて当該返信が承認か却下かを判定する承認是非判定手段と、
   該承認是非判定手段にて「承認」と判定された場合、当該承認依頼メールＩＤに対応する承認待ちメールを外部クライアントに対して送信する承認待ちメール送信手段と、
   当該承認依頼メールＩＤに対応するレコードを承認依頼メールデータベースから削除する承認依頼レコード削除手段と
   を備える電子メール保留システム。
9. 請求項１，２，３，４，５，６，７又は８のいずれか一に記載した電子メール保留システムであって、
   前記メール保留サーバは、前記メールエンベロープまたは前記メールヘッダ、題名・本文等から前記特定ドメイン名、前記特定キーワード、前記添付ファイル種別とを取得し、予め優先度ポリシーＤＢに設定されたドメイン名、キーワード、添付ファイル種別に対応するレコードを参照し、当該ドメイン名、キーワード、添付ファイル種別に対応するレコードの優先度ＩＤと優先者ポリシーを判定する手段と、
   前記特定ドメイン名、前記特定キーワード、前記特定添付ファイルが複数ある場合は、最も重要度の高いものを、前記メールの優先度ＩＤおよび優先者ポリシーと判定する手段と、
   前記判定した優先者ポリシーの定義に適合する承認者を優先承認者と判定する手段と、
   を備えることを特徴とする電子メール保留システム。
10. 請求項９に記載した電子メール保留システムであって、
    前記メール保留サーバは、
    ユーザ端末から、出社時刻、退社時刻、ログオン状況、予定を取得し、在席状況データベースに格納する在席確認手段と、
    前記在席状況データベースを参照し、優先承認候補者が在席してるか否かを判定する手段と、
    在席であれば、通知メールに優先承認者である旨を付加する手段と、
    をさらに備えることを特徴とする電子メール保留システム。

Images