(57)【要約】      （修正有）【課題】送信確認の際に送信制御に用いる情報を学習することで、管理者の手間を軽減させる。【解決手段】電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理し、送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する。保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける。【選択図】図１
2018005415.tif 000002
【特許請求の範囲】
【請求項１】
電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理する管理手段と、
送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、前記管理手段に管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する送信制御手段と、
前記送信制御手段により送信保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける監査結果受付手段と、
前記監査結果受付手段により監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける選択受付手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記管理手段は、
前記監査結果受付手段により送信を許可する旨の指示を受け付けた場合に、前記選択受付手段により管理する旨の選択を受け付けた組織名と送信先ドメインとの組み合わせを管理することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記送信制御手段により送信が保留された電子メールに対する監査を行うための画面を表示する表示制御手段を備え、
前記表示制御手段により表示される画面には、当該電子メールから抽出された組織名と対応付けて管理された送信先ドメインであって送信履歴回数の最も多い送信先ドメインと、当該電子メールにおける送信先ドメインに対応付けて管理された組織名であって送信履歴回数の最も多い送信先ドメインが表示されることを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
情報処理装置における情報処理方法であって、
前記情報処理装置の管理手段が、電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理する管理工程と、
前記情報処理装置の送信制御手段が、送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、前記管理工程おいて管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する送信制御工程と、
前記情報処理装置の監査結果受付手段が、前記送信制御工程により送信保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける監査結果受付工程と、
前記情報処理装置の選択受付手段が、前記監査結果受付工程により監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける選択受付工程と、
を備えることを特徴とする情報処理方法。
【請求項５】
情報処理装置において実行可能なプログラムであって、
前記情報処理装置を、
電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理する管理手段と、
送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、前記管理手段に管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する送信制御手段と、
前記送信制御手段により送信保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける監査結果受付手段と、
前記監査結果受付手段により監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける選択受付手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、プログラムに関する。
【背景技術】
【０００２】
メールの誤送信は、機密情報の漏えい、顧客の信頼喪失の原因となり、企業活動において多大な損害を発生させる恐れがある。
【０００３】
誤送信を防止するために、「添付ファイルが付いている」や「送信先が１０以上ある」といった予め定められた条件（送信制御ルール）に合致する電子メールについては、一時的に送信を保留し、他者が確認してからメールを送出するように制御する製品が販売されている。
【０００４】
特許文献１には、予め定められた保留度判定情報に基づき、電子メールの送信を保留する時間を決め、当該時間の間、送信を保留する技術について記載がされている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２９５０７６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１に示される技術は、管理者等が送信を保留するか否かを決定するための条件や保留度を予め設定しておく必要がある。また、適切に条件を設定しなければ、実効性のない条件となってしまい、誤送信を防止できなくなるといった事態も生じうる。
【０００７】
そこで、本発明は、送信確認の際に送信制御に用いる情報を学習することで管理者の手間を軽減させることが可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の情報処理装置は、電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理する管理手段と、送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、前記管理手段に管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する送信制御手段と、前記送信制御手段により送信保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける監査結果受付手段と、前記監査結果受付手段により監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける選択受付手段と、を備えることを特徴とする。
【０００９】
また、本発明の情報処理方法は、情報処理装置における情報処理方法であって、前記情報処理装置の管理手段が、電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理する管理工程と、前記情報処理装置の送信制御手段が、送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、前記管理工程おいて管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する送信制御工程と、前記情報処理装置の監査結果受付手段が、前記送信制御工程により送信保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける監査結果受付工程と、前記情報処理装置の選択受付手段が、前記監査結果受付工程により監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける選択受付工程と、を備えることを特徴とする。
【００１０】
また、本発明のプログラムは、情報処理装置において実行可能なプログラムであって、前記情報処理装置を、電子メールの本文から抽出した組織名と、当該電子メールの送信先ドメインとの組み合わせ毎に送信履歴を管理する管理手段と、送信指示された電子メールから抽出した組織名と当該電子メールの送信先ドメインとの組み合わせが、前記管理手段に管理された組み合わせに存在しない場合、当該送信指示された電子メールの送信を保留する送信制御手段と、前記送信制御手段により送信保留された電子メールについて、送信を許可するか否かの監査結果を受け付ける監査結果受付手段と、前記監査結果受付手段により監査結果を受け付ける際に、当該組織名と送信先ドメインとの組み合わせを管理するか否かの選択を受け付ける選択受付手段として機能させるためのプログラム。
【発明の効果】
【００１１】
本発明によれば、送信確認の際に送信制御に用いる情報を学習することで管理者の手間を軽減させることが可能となる。
【図面の簡単な説明】
【００１２】
【図１】メール誤送信防止システムが備える機能を説明する図
【図２】メール誤送信防止システムを適用可能な情報処理装置のハードウェア構成を示す図
【図３】宛先情報抽出処理を示すフローチャート
【図４】送信制御ルール判定処理を示すフローチャート
【図５】宛先ルール判定処理を示すフローチャート
【図６】本文組織名分類処理を示すフローチャート
【図７】宛先ドメイン分類処理を示すフローチャート
【図８】添付組織名分類処理を示すフローチャート
【図９】保留判定処理を示すフローチャート
【図１０】本実施例で用いる電子メールの一例を示す図
【図１１】保留メール一覧画面の一例を示す図
【図１２】電子メール監査画面の一例を示す図
【図１３】送信確認、新規ドメイン追加画面の一例を示す図
【図１４】抽出された宛先情報を示す図
【図１５】送信履歴および送信制御ルールを示す図
【図１６】抽出された組織名・宛先ドメインの分類結果を示す図
【図１７】送信制御ルールの無効化に関する情報を示す図
【図１８】送信制御ルールの判定区分を示す図
【図１９】保留メールＤＢに登録された情報を示す図
【図２０】更新された送信制御ルールの無効化に関する情報を示す図
【図２１】更新された送信履歴を示す図
【発明を実施するための形態】
【００１３】
本発明は、「同じ送受信者の組み合わせ」について、「２回目以降の確認作業の省略」が可能か否かを制御ルールごとに制御することが可能なシステムである。また、送信確認の際に宛先と宛名の組み合わせを学習可能なシステムであり、事前に詳細な制御ルールを作成することなくシステムを利用することができる。以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１４】
図１は、本発明の実施形態におけるメール誤送信防止システムの構成を示す図である。
【００１５】
メール誤送信防止システム１００は、メール受付部１０１と、宛先情報抽出部１０２と、送信制御ルール判定部１０３と、保留判定部１０４と、保留メール操作・システム設定部１０５と、メール送信部１０６、送信制御ルールＤＢ１１０、確認操作キャッシュＤＢ１２０、保留メールＤＢ１３０とを備える。
【００１６】
なお、本実施例においては、メール誤送信防止システム１００は、図１に示すようにクライアント端末と通信可能に接続されたサーバ装置（情報処理装置）として説明するが、クライアント端末が図１に示す機能を備えていても良い。
【００１７】
メール受付部１０１は、システムのユーザが送信したメールを受け付け、宛先情報抽出部１０２へメールを送る。システムのユーザは、自身が使用しているメールクライアントにおけるメールの送信先を、メール受付部１０１に設定することでメール誤送信防止システム１００の利用が可能となる。
【００１８】
宛先情報抽出部１０２は、メールアドレス、メールの本文、添付ファイルから、自然言語処理を用いて宛先情報（ドメイン、組織名、氏名など）を抽出し、メールと併せて送信制御ルール判定部１０３に送る。宛先情報抽出部１０２における宛先情報抽出処理については、後に例を用いて詳しく説明する。
【００１９】
送信制御ルール判定部１０３は、送信制御ルールＤＢ１１０を参照し、宛先情報抽出部１０２から入力されたメールに適用すべき送信制御ルールをすべて取得し、宛先情報とメールを併せて保留判定部１０４へ送る。送信制御ルールＤＢ１１０、および、送信制御ルール判定部１０３における送信制御ルール判定処理については、後に例を用いて詳しく説明する。
【００２０】
保留判定部１０４は、確認操作キャッシュＤＢ１２０を参照し、送信制御ルール判定部１０３がメールに適用したルール、および、メールの送信先アドレスの組み合わせからメールの送信を保留するか否かを判定する。メールを保留する場合は、保留メールＤＢ１３０にメールと保留理由（メールに適用したルールなど）を登録し、保留しない場合は、メール送信部１０６にメールを送る。確認操作キャッシュＤＢ１２０、保留メールＤＢ１３０、および、保留判定部１０４における保留判定処理は、後に例を用いて詳しく説明する。
【００２１】
保留メール操作・システム設定部１０５は、システムのユーザに対して、ＷＥＢブラウザなどを通じて、保留メールＤＢ１３０に登録したメールの送出処理や、送信制御ルールＤＢ１１０、確認操作キャッシュＤＢ１２０のメンテナンス処理を提供する。保留メール操作・システム設定部１０５がシステムのユーザに提供する操作画面は、後に例を用いて詳しく説明する。
【００２２】
メール送信部１０６は、保留判定部１０４が送出可能と判定したメール、および、システムのユーザが保留メール操作・システム設定部１０５を通じて送出処理を行ったメールを、メールの宛先アドレスに向けてメールを送信する。
【００２３】
送信制御ルールＤＢ１１０は、送信履歴テーブル１１１と、宛先ルールテーブル１１２と、手動ルールテーブル１１３とを備える。
【００２４】
送信履歴テーブル１１１は、ドメインと組織名の組み合わせごとに、過去の送信回数を保持している。なお、送信履歴テーブル１１１に存在する組み合わせの送信回数は、メール送信部１０６におけるメール送信処理の際に自動的に更新され、新しい組み合わせの追加は、システムのユーザによるメール確認処理の際に行われる。宛先ルールテーブル１１２、および、手動ルールテーブル１１３は、送信制御ルール判定処理において使用するルールの一覧を保持している。送信制御ルールＤＢ１１０における各項目の詳細については、後の送信制御判定処理の説明において詳しく説明する。
【００２５】
確認操作キャッシュＤＢ１２０は、キャッシュ利用設定テーブル１２１と、確認操作キャッシュテーブル１２２とを備える。キャッシュ利用設定テーブル１２１は、送信制御ルールごとに、メール確認操作の履歴を用いた保留操作の省略を実施するか否かの設定を保持する。確認操作キャッシュテーブル１２２は、システムのユーザが最近確認した保留理由（送信制御ルール）の一覧を、送受信者と宛名の組み合わせごとに保持する。確認操作キャッシュＤＢ１２０の詳細については、後の保留判定処理、および、保留メール操作処理の説明において詳しく説明する。
【００２６】
保留メールＤＢ１３０は、保留判定部１０４が保留と判定したメールを一時的に保管するＤＢであり、保留メールテーブル１３１を備える。保留メールテーブル１３１は、メールのソース（元データ）に加え、宛先情報抽出部１０２が抽出した宛先情報、送信制御ルール判定部１０３が適用した送信制御ルールの情報を併せて保持する。保留メールＤＢ１３０の詳細は、後の保留判定処理、および、保留メール操作処理の説明において詳しく説明する。
【００２７】
図２は、本発明の実施例におけるメール誤送信防止システム１００を適用可能な情報処理装置１００のハードウェア構成の一例を示すブロック図である。
【００２８】
図２に示すように、情報処理装置では、システムバス２００を介してＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３、記憶装置２０４、入力コントローラ２０５、音声入力コントローラ２０６、ビデオコントローラ２０７、メモリコントローラ２０８、よび通信Ｉ／Ｆコントローラ２０９が接続される。
【００２９】
ＣＰＵ２０１は、システムバス２００に接続される各デバイスやコントローラを統括的に制御する。
【００３０】
ＲＯＭ２０２あるいは記憶装置２０４は、ＣＰＵ２０１が実行する制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や、本情報処理方法を実現するためのコンピュータ読み取り実行可能なプログラムおよび必要な各種データ（データテーブルを含む）を保持している。
【００３１】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは記憶装置２０４からＲＡＭ２０３にロードし、ロードしたプログラムを実行することで各種動作を実現する。
【００３２】
入力コントローラ２０５は、キーボード／タッチパネル２１０などの入力装置からの入力を制御する。入力装置はこれに限ったものでなく、マウスやマルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。
【００３３】
ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができる。
【００３４】
この入力装置を用いて各種通信装置で利用可能な通信宛先に対する宛先を入力するようになっている。
【００３５】
音声入力コントローラ２０６は、マイク２１１からの入力を制御する。マイク２１１から入力された音声を音声認識することが可能となっている。
【００３６】
ビデオコントローラ２０７は、ディスプレイ２１２などの外部出力装置への表示を制御する。ディスプレイは本体と一体になったノート型パソコンのディスプレイも含まれるものとする。なお、外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。また、前述のタッチ操作により受け付け可能な装置については、キーボード／タッチパネル２１０からの入力を受け付けることも可能となる。
【００３７】
なおビデオコントローラ２０７は、表示制御を行うためのビデオメモリ（ＶＲＡＭ）を制御することが可能で、ビデオメモリ領域としてＲＡＭ２０３の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。
【００３８】
本発明では、ユーザが情報処理装置を通常する場合の表示に用いられる第１のビデオメモリ領域と、所定の画面が表示される場合に、第１のビデオメモリ領域の表示内容に重ねての表示に用いられる第２のビデオメモリ領域を有している。ビデオメモリ領域は２つに限ったものではなく、情報処理装置の資源が許す限り複数有することが可能なものとする。
【００３９】
メモリコントローラ２０８は、外部メモリ２１３へのアクセスを制御する。外部メモリとしては、ブートプログラム、各種アプリケーション、フォントデータ、ユーザファイル、編集ファイル、および各種データ等を記憶する外部記憶装置（ハードディスク）、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等を利用可能である。
【００４０】
通信Ｉ／Ｆコントローラ２０９、ネットワーク２１４を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信やＩＳＤＮなどの電話回線、および携帯電話の３Ｇ回線を用いた通信が可能である。
【００４１】
なお、記憶装置２０４は情報を永続的に記憶するための媒体であって、その形態をハードディスク等の記憶装置に限定するものではない。例えば、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）などの媒体であってもよい。
【００４２】
また本実施形態における通信端末で行われる各種処理時の一時的なメモリエリアとしても利用可能である。
【００４３】
次に図３〜図９に示すフローチャートを用いて、本実施例におけるメール誤送信防止処理について説明する。
【００４４】
なお、図３〜図９のフローチャートで示す処理は、情報処理装置１００のＣＰＵ２０１が所定の制御プログラムを読み出して実行する処理である。
【００４５】
まず、宛先情報抽出部１０２における宛先情報抽出処理について、図３、図１０、図１４を用いて説明する。図３は、宛先情報抽出処理のフローチャートである。以下、図３の処理に従って、図１０に示すメール（メール１）から、図４に示す各種情報を抽出する例を示す。
【００４６】
まず、ステップＳ１０１で、送信者のメールアドレスをメールから抽出する。送信者のメールアドレスは、メールヘッダーにおけるＦｒｏｍの値から抽出する。なお、エンベロープ情報が参照可能な環境下においては、エンベロープに記載の送信者アドレスを取得してもよい。メール１における送信者アドレスは、Ｆｒｏｍの値「ｋｕｒａｍｉｔｓｕ＠ＥＸＡＭＰＬＥ．ＪＰ」である。
【００４７】
ステップＳ１０２では、ステップＳ１０１で取得した送信者アドレスから、ドメイン部分（”＠”以降の文字列）のみを抽出する。本システムでは、送信者のドメインを内部ドメインと呼び、内部ドメイン以外のドメイン（外部ドメイン）と区別して取り扱う。メール１における内部ドメインは「ＥＸＡＭＰＬＥ．ＪＰ」である。
【００４８】
なお、送信者のドメインと異なる場合であっても、グループ会社等は内部ドメインとして扱うことを可能とするため、予め対応付けられたドメインについては、内部ドメインとして判断しても良い。
【００４９】
次に、ステップＳ１０３で、宛先のメールアドレスの一覧を取得する。宛先アドレスは、メールヘッダーにおけるＴｏ、および、Ｃｃの値から抽出する。送信者アドレスと同様に、エンベロープ情報が参照可能な環境下においては、エンベロープ情報から取得してもよい。メール１における宛先アドレスは、「ｎａｋａｍｕｒａ＠ＥＸＡＭＰＬＥ１．ＪＰ」、「ｉｔｏ＠ＥＸＡＭＰＬＥ２．ＪＰ」、「ｏｔａｎｉ＠ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」、「ｋｕｒａｍｉｔｓｕ＠ＥＸＡＭＰＬＥ．ＪＰ」の４つである。
【００５０】
ステップＳ１０４では、ステップＳ１０３で取得した各宛先アドレスから、外部ドメインのみを抽出する。ここで、同じドメインは重複を取り除き、１つの要素として取り扱う。メール１における宛先ドメインは、「ＥＸＡＭＰＬＥ１．ＪＰ」、「ＥＸＡＭＰＬＥ２．ＪＰ」、「ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」の３つである。
【００５１】
ステップＳ１０５では、本文の宛名に含まれる組織名（本文組織名）の一覧を抽出する。説明を簡略化するため、本実施形態では、「本文の宛名」を、文末が敬称（「様」、「さん」、「殿」など）で終わる行とし、「本文組織名」を、「本文の宛名」を空白文字で分割した先頭の要素として抽出する。なお、空白文字で分割した要素の数が１つ以下である場合は、組織名が含まれないものとして取り扱う。メール１における本文組織名は、「ＥＸ１」の１つである。
【００５２】
ステップＳ１０６では、添付ファイルから組織名（添付組織名）の一覧を抽出する。説明を簡略化するため、本実施形態では、「添付組織名」を、添付ファイルに含まれるテキストにおいて、「御中」の直前に出現する文字列として抽出する。該当する文字列が存在しない場合、組織名が含まれないものとして取り扱う。メール１における添付組織名は、「ＥＸＡＭＰＬＥ１」の１つである。
【００５３】
以上、宛先情報抽出部１０２における宛先情報抽出処理について、例を用いて説明した。なお、説明の簡略化のため、組織名（本文組織名、添付組織名）の抽出方法については一例として簡易な方法を記載したが、あらかじめ組織名のＤＢを構築したものを使用する、抽出箇所を本文や添付ファイルの前半部分に制限する、形態素解析などの自然言語処理技術を用いて組織名らしき文字列を抽出する、などの方法を組み合わせることで、抽出精度の向上、および、より柔軟な書式への対応を図ることが可能である。
【００５４】
図３のフローチャートで抽出された宛先情報を図１４に示す。
【００５５】
次に、送信制御ルール判定部１０３における送信制御ルール判定処理について、図４〜図８、図１５、図１６を用いて説明する。図４〜図８は、送信制御ルール判定処理のフローチャートである。図１５は送信制御ルールＤＢ１１０の一例であり、送信履歴テーブル１１１、宛先ルールテーブル１１２、および、手動ルールテーブル１１３から成る。
【００５６】
送信履歴テーブル１１１は、ドメインと組織名の組み合わせごとに、過去の送信回数を保持している。なお、送信履歴テーブル１１１に存在する組み合わせの送信回数は、メール送信部１０６におけるメール送信処理の際に自動的に更新され、新しい組み合わせの追加は、後に説明する、システムのユーザによるメール確認処理の際に行われる。
【００５７】
宛先ルールテーブル１１２、および、手動ルールテーブル１１３は、送信制御ルール判定処理において使用するルールの一覧を保持しており、ルールを一意に識別する「ルールＩＤ」、および、ルールの適用可否を定めるための「判定条件」、ルールを人間がわかりやすい文言で示す「説明」から成る。以下、図４〜図８の処理に従って、メール１から、図１６に示す「本文組織名分類結果」、「宛先ドメイン分類結果」、「添付組織名分類結果」、「宛名ルールＩＤ」、「手動ルールＩＤ」を抽出する例を示す。
【００５８】
まずステップＳ２０１では、宛先ルール判定処理を実行する。宛先ルール判定処理の詳細は、図５のフローチャートを用いて説明する。
【００５９】
図５のフローチャートにおけるステップＳ３０１では、処理対象の電子メールにおける本文組織名、および、添付組織名に対して、送信履歴テーブル１１１から、尤もらしい組み合わせのドメイン（以下、最尤ドメイン）を抽出する。
【００６０】
説明を簡略化するため、本実施形態では、ある組織名に対する「最尤ドメイン」を、送信履歴テーブル１１１において、当該組織名を含むレコードのうち、最も送信回数が多いレコードのドメインと定義する。例えば、メール１における本文組織名「ＥＸ１」、および、添付組織名「ＥＸＡＭＰＬＥ１」における最尤ドメインはともに「ＥＸＡＭＰＬＥ１．ＪＰ」である。
【００６１】
ステップＳ３０２では、処理対象の電子メールの宛先ドメインに対して、送信履歴テーブル１１１から、尤もらしい組み合わせの組織名（以下、最尤組織名）を抽出する。
【００６２】
説明を簡略化するため、本実施形態では、あるドメインに対する「最尤組織名」を、送信履歴テーブル１１１において、当該ドメインを含むレコードのうち、最も送信回数が多いレコードの組織名と定義する。例えば、メール１における宛先ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」、「ＥＸＡＭＰＬＥ２．ＪＰ」の最尤組織名はそれぞれ、「ＥＸＡＭＰＬＥ１」、「ＥＸ２」であり、「ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」に対する最尤組織名は存在しない。
【００６３】
次にステップＳ３０３では、処理対象の電子メールにおける各本文組織名に基づき、本文組織名と宛先ドメインの組み合わせに対して「判定区分」および「組織コード」を求める。
【００６４】
ステップ３０３における処理の詳細は、図６のフローチャートを用いて説明する。
【００６５】
なお、「判定区分」は、処理対象の電子メールにおける宛先ドメインと本文組織名との組み合わせが正しい組み合わせであることを意味する「整合」、正しい組み合わせではないことを意味する「不整合」、未登録の宛先である（送信履歴が存在しない）ことを示す「新規」の３つの区分であり、本文組織名、宛先ドメイン、および、過去の送信履歴に基づいて分類する。
【００６６】
「組織コード」は、本文組織名と宛先ドメインの対応関係を識別するための数値であり、後に説明する保留理由確認画面において、本文組織名や宛先ドメインの表示色を定める際に用いる。
【００６７】
ステップＳ４０２では、ステップＳ３０１の処理において、本文組織名に対する最尤ドメインを取得できたか否かを判定する。
【００６８】
取得できていればステップＳ４０３へ処理を進め、取得できていなければ処理をステップＳ４０４に進め、判定区分を「新規」にする。すなわち、当該本文組織名が記載された電子メールを過去に送信したことがないことを意味する。
【００６９】
メール１の本文組織名「ＥＸ１」には最尤ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」が存在するため、ステップＳ４０３に処理を進める。
【００７０】
ステップＳ４０３では、処理対象の電子メールにおける宛先ドメインが、ステップＳ３０１で取得した本文組織名に対応する最尤ドメインであるか否かを判定する。
【００７１】
処理対象の電子メールにおける宛先ドメインが本文組織名に対する最尤ドメインである場合は、処理をステップＳ４０５へ移行する。
【００７２】
宛先ドメインが最尤ドメインではない場合は、処理をステップＳ４０６に進め、判定区分を「不整合」にする。すなわち、最尤ドメイン以外の宛先ドメインに送信されるメールであることを意味する。
【００７３】
メール１の宛先ドメインは、本文組織名「ＥＸ１」の最尤ドメインである「ＥＸＡＭＰＬＥ１．ＪＰ」であるため、ステップＳ４０５へ処理を進める。
【００７４】
ステップＳ４０５では、処理対象の電子メールにおける本文組織名と宛先ドメインとの組み合わせについて、判定区分を「整合」とし、ステップＳ４０７に処理を進める。本実施形態において、「整合」と区分された場合は、処理対象の電子メールに、本文組織名に対応する最尤ドメインのメールアドレスが送信先として少なくとも１つは設定されていることを意味している。
【００７５】
ステップＳ４０７からステップＳ４１１の処理は、本文組織名と宛先ドメインとの組み合わせにおける組織コードを定める処理である。判定区分が「新規」および「不整合」である場合は、ステップＳ４１１で新しい組織コードを一意に割り振る。一方、判定区分が「整合」かつ最尤ドメインが同じ場合には、ステップＳ４０７からステップＳ４１０において、同じ組織コードを割り当てる（異なる組織名の組織コードを同じ値にする処理は、複数の組織名を単一の組織の別名として取り扱うことに相当する）。
【００７６】
ステップＳ４０７では、最尤ドメインの組織コードが決定済みか否かを判定し、決定済みであれば、ステップＳ４０８で最尤ドメインの組織コードを割り当て、そうでなければ、ステップＳ４０９で新しい組織コードを割り当ててステップＳ４１０へ処理を進める。メール１において、組織名「ＥＸ１」の最尤ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」の組織コードは、まだ決定していないため、ステップＳ４０９において、新しい組織コード「１」を割り当てる。
【００７７】
ステップＳ４１０では、最尤ドメインの判定区分と組織コードを、前ステップで求めた値で更新する。前述の例では、最尤ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」の判定区分と組織コードを「整合」、「１」でそれぞれ更新する。
【００７８】
同様に、各本文組織名に対して、判定区分、および、組織コードを求めて、本文組織名分類処理を終了し、ステップＳ３０４に処理を進める。
【００７９】
ステップＳ３０４では、宛先ドメイン分類処理を行う。宛先ドメイン分類処理は、処理対象の電子メールの各宛先ドメインに基づき、本文組織名と宛先ドメインとの組み合わせに対して「判定区分」および「組織コード」を決定する処理であり、詳細は図７に示すフローチャートを用いて説明する。
【００８０】
まずステップＳ５０２で、図６の本文組織名分類処理によって、処理対象の宛先ドメインについて、本文組織名に基づく組織コードと判定区分が決定済みか否かを判定する。決定済みであれば、ステップＳ５０３へ処理を進め、そうでなければステップＳ５０４へ処理を進める。メール１において、宛先ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」における判定区分、および、組織コードは、本文組織名分類処理によって、「整合」、「１」にそれぞれ決定済みであるため、ステップＳ５０３へ処理を進める。（なお、「ＥＸＡＭＰＬＥ１．ＪＰ」における最尤組織名は「ＥＸＡＭＰＬＥ１」であり、本文組織名には存在しない。本実施形態では、本文組織名に対する最尤ドメイン、または、宛先ドメインに対する最尤組織名のいずれかが存在する組み合わせを「整合」なものとして取り扱う。）
【００８１】
ステップＳ５０３において、宛先ドメインにおける最尤組織名が本文組織名に存在し、かつ、判定区分が「整合」以外であれば、ステップＳ５０５で、当該組織名の判定区分、および、組織コードを、宛先ドメインに基づく判定区分、および、組織コードの値でそれぞれ更新する。前述の例では、宛先ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」における最尤組織名「ＥＸＡＭＰＬＥ１」は、本文組織名に存在しないため、ステップＳ５０５は実行せずに、次の宛先ドメイン「ＥＸＡＭＰＬＥ２．ＪＰ」に対する処理をステップＳ５０２から進める。
【００８２】
ステップＳ５０４では、最尤組織名が存在するか否かを判定し、存在すればステップＳ５０６に処理を進め、そうでなければ、ステップＳ５０７で判定区分を「新規」にし、ステップＳ５１２で新しい組織コードを割り当てる。前述の例において、宛先ドメイン「ＥＸＡＭＰＬＥ２．ＪＰ」には最尤組織名「ＥＸ２」が存在するため、ステップＳ５０６に処理を進める。
【００８３】
ステップＳ５０６では、処理対象の電子メールにおける本文組織名が、宛先ドメインに対応する最尤組織名であるか（最尤組織名が本文組織名に存在するか）否かを判定する。
【００８４】
本文組織名が、宛先ドメインに対応する最尤組織名である（最尤組織名が本文組織名に存在する）場合は、処理をステップＳ５０８に移行し、判定区分を「整合」にする。そして、ステップＳ５１０に処理を進める。
【００８５】
本文組織名が、宛先ドメインに対応する最尤組織名ではない（最尤組織名が本文組織名に存在しない）場合は、処理をステップＳ５０９に移行し、判定区分を「不整合」にする。そして、ステップＳ５１２に処理を進める。
【００８６】
前述の例では、最尤組織名「ＥＸ２」は、本文組織名に存在しないため、宛先ドメイン「ＥＸＡＭＰＬＥ２．ＪＰ」に対する判定区分は「不整合」であり、組織コードは新しい値の「２」となる。
【００８７】
ステップＳ５１０では、最尤組織名の組織コードを宛先ドメインの組織コードとして割り当て、ステップＳ５１１で最尤組織名の判定区分を「整合」で更新する。（最尤組織名の組織コードは更新しない）
【００８８】
同様に、各宛先ドメインに対して、判定区分、および、組織コードを求めて、宛先ドメイン分類処理を終了し、ステップＳ３０５に処理を進める。なお、前述の例において、残りの宛先ドメイン「ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」は、最尤組織名が存在しないため、判定区分は「新規」であり、組織コードは新しい値の「３」となる。
【００８９】
ステップＳ３０５では、添付組織名分類処理を行う。添付組織名分類処理は、処理対象の電子メールの各添付組織名に対して「判定区分」、および「組織コード」を求める処理であり、図８のフローチャートを用いて説明する。なお、添付組織名分類処理においては、本文組織名、および、宛先ドメインの判定区分と組織コードが更新されることはしない。
【００９０】
まず、ステップＳ６０２で添付組織名が本文組織名に含まれるか否かを判定し、含まれていればステップＳ６０３で判定区分を「整合」にしたのちステップＳ６０５で本文組織名の組織コードを割り当てる。含まれていなければ、ステップＳ６０４に処理を進める。メール１における添付組織名「ＥＸＡＭＰＬＥ１」は、本文組織名に存在しないため、ステップＳ６０４に処理を進める。
【００９１】
ステップＳ６０４では、添付組織名に最尤ドメインが存在するか否かを判定し、存在すればステップＳ６０６に処理を進め、存在しなければ、ステップＳ６０７で判定区分を「新規」にしてステップＳ６１１で新しい組織コードを割り当てる。前述の例では、添付組織名「ＥＸＡＭＰＬＥ１」に最尤ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」が存在するため、ステップＳ６０６に処理を進める。
【００９２】
ステップＳ６０６では、添付組織名の最尤ドメインが宛先ドメインに含まれるか否かを判定し、存在すれば、ステップＳ６０８で判定区分を「整合」にしてステップＳ６１０で最尤ドメインの組織コードを割り当てる。存在しなければ、ステップＳ６０９で判定区分を「不整合」にしてステップＳ６１１で新しい組織コードを割り当てる。前述の例では、最尤ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」が宛先ドメインに含まれるため、添付組織名「ＥＸＡＭＰＬＥ１」の判定区分を「整合」にし、組織コードを最尤ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」の組織コード「１」にする。
【００９３】
同様に、各添付組織名に対して、判定区分、および、組織コードを求めて、添付組織名分類処理を終了し、ステップＳ３０６に処理を進める。
【００９４】
ステップＳ３０６では、ステップＳ３０３〜ステップＳ３０５において取得した各分類結果をもとに、宛先ルールテーブル１１２に記載の判定条件と一致するルールＩＤの一覧を取得し、宛先ルール判定処理を終える。前述の例では、判定区分が「不整合」である宛先ドメイン「ＥＸＡＭＰＬＥ２．ＪＰ」と、判定区分が「新規」である宛先ドメイン「ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」が存在するため、宛先ルールＩＤとして「ＩＮＣＯＲＲＥＣＴ」、および、「ＮＥＷＤＯＭＡＩＮ」を取得する。
【００９５】
そして、ステップＳ２０２で、手動ルールテーブル１１３を参照し、判定条件を満たすルールＩＤの一覧を取得する。メール１においては、添付ファイル「御見積書．ｐｄｆ」のテキスト情報にキーワード「見積書」が含まれるため、手動ルールＩＤとして「ルール４」を取得する。
【００９６】
以上、送信制御ルール判定部１０３における送信制御ルール判定処理について、例を用いて説明した。なお、説明を簡略化するため、最尤ドメイン、最尤組織名を、単に同じ組み合わせで送信した回数が最も多いものとして取り扱ったが、尤もらしさの尺度として、同じ組み合わせで送ったことのある送信者の数や、宛名に含まれる部署名や人名が組織名やドメインと共起する確率など、複数の判断基準を組み合わせた結果を用いてもよい。また、判定区分を「整合」とする条件を、最尤ドメイン、または、最尤組織名が存在するか否かで判定する方法を説明したが、送信履歴テーブル１１１において、一定の送信回数を超える組み合わせは許容するなど、別の判断記述を組み合わせてもよい。
【００９７】
次に、保留判定部１０４における保留判定処理について、図９、図１７〜図１９を用いて説明する。
図９は、保留判定処理のフローチャートである。
【００９８】
図１７は確認操作キャッシュＤＢ１２０の一例であり、キャッシュ利用設定テーブル１２１、および、確認操作キャッシュテーブル１２２から成る。
【００９９】
図１８は保留メールＤＢ１３０の一例であり、保留判定部１０４が保留と判定したメール、各種分類結果、適用したルールＩＤを一時的に保管する。
【０１００】
キャッシュ利用設定テーブル１２１は、送信制御ルールごとに、メール確認操作の履歴を用いた保留操作の省略を実施するか否かの設定を保持する。確認操作キャッシュテーブル１２２は、送受信者と本文組織名の組み合わせごとに、システムのユーザが保留メール操作により確認したルールＩＤと送信日時の一覧を保持する。
【０１０１】
以下、図９の処理に従って、メール１に関して、図１８に示す「適用ルールＩＤ分類結果」を取得し、メールの送信を保留するか否かを判定する処理について説明する。
【０１０２】
まず、ステップＳ７０１で、送受信者アドレスを取得する。本実施形態では、「送受信者アドレス」を、送信者アドレスと受信者アドレスを辞書順に整列し、重複を除いた上で、空白文字で連結した文字列と定義する。メール１における送受信者アドレスは、「ｉｔｏ＠ＥＸＡＭＰＬＥ２．ＪＰ  ｋｕｒａｍｉｔｓｕ＠ＥＸＡＭＰＬＥ．ＪＰ  ｎａｋａｍｕｒａ＠ＥＸＡＭＰＬＥ１．ＪＰ  ｏｔａｎｉ＠ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」である。
【０１０３】
ステップＳ７０２で、送受信者アドレスと本文組織名の組み合わせが確認操作キャッシュテーブル１２２に存在するか確認する。組み合わせが存在する場合は、ステップＳ７０３に処理を進め、存在しない場合はステップＳ７０８で全てのルールＩＤの判定区分を「要確認」としステップＳ７０９へ処理を進める。なお、確認の際に用いる本文組織名は、送受信者アドレスと同様に、辞書順に整列し、重複を除いた上、空白文字で連結した文字列を使用する。前述の例においては、確認の際に用いる本文組織名は「ＥＸ１」であり、確認操作キャッシュテーブル１２２において、送受信者アドレスとの組み合わせが存在するため、ステップＳ７０３へ処理を進める。
【０１０４】
ステップＳ７０３からステップＳ７０７は、送信制御ルール判定処理によって適用した各ルールＩＤが、それぞれ確認すべきルールか否か（最近確認したことがあるか否か）を判定する処理である。
【０１０５】
まず、ステップＳ７０４では、キャッシュ利用設定テーブル１２１を参照して、ルールＩＤに対するキャッシュの利用可否を判定する。利用可能であれば、ステップＳ７０５に処理を進め、利用不可であれば、ステップＳ７０７へ処理を進める。なお、利用可否の判定処理は、キャッシュ利用設定テーブル１２１において、適用順序の値が小さいものから実施し、該当する設定が存在しなければ、利用禁止となる。前述の例において、宛先ルールＩＤ「ＩＮＣＯＲＲＥＣＴ」は、適用順序１の条件に適合して利用可能であるため、ステップＳ７０５に処理を進める。（宛先ルールＩＤ「ＮＥＷＤＯＭＡＩＮ」、および、手動ルールＩＤ「ルール４」においても、それぞれ、適用順序５、および、適用順の７の条件に適合するため、ステップＳ７０５に処理を進める）
【０１０６】
ステップＳ７０５では、確認操作キャッシュテーブル１２２における、送受信者アドレスと本文組織名の組み合わせに該当するレコードにおいて、ルールＩＤが確認済項目に存在し、かつ、確認日時がキャッシュ期間ないであるか否かを判定する。条件を満たす場合、ステップＳ７０６でルールＩＤの判定区分を「確認済」にし、そうでない場合は、ステップＳ７０７で判定区分を「要確認」にする。前述の例では、宛先ルールＩＤ「ＩＮＣＯＲＲＥＣＴ」および、「ＮＥＷＤＯＭＡＩＮ」は、条件を満たすため、判定区分を「確認済」にし、手動ルールＩＤ「ルール４」は確認済項目に存在しないため、判定区分を「要確認」とする。
【０１０７】
次にステップＳ７０９で、判定区分が「要確認」であるルールＩＤが１つでも存在すれば、ステップＳ７１０でメールの保留処理を行い、存在しなければステップＳ７１１でメールをメール送信部へ送る。前述の例では、手動ルールＩＤ「ルール４」の判定区分が「要確認」であるため、ステップＳ７１０へ処理を進める。
【０１０８】
ステップＳ７１０におけるメールの保留処理は、メールの送信を一時的に保留する処理であり、保留メールテーブル１３１に、メールＩＤ、メールのソース、本文組織名分類結果、宛先ドメイン分類結果、添付組織名分類結果、適用ルールＩＤを格納する。図１９は、保留メールＤＢ１３０の一例を表しており、メール１を保留した後の状態を表す。
【０１０９】
以上、保留判定部１０４における保留判定処理について説明した。前述の例は、「最近、同じ送受信者と本文組織名の組み合わせで送信したことはあるが、見積書が含まれる（ルール４と一致する）メールを同組み合わせには送信してはいないため、保留操作を行った」という動作を表している。
【０１１０】
以上説明したように、本実施例においては、送信制御ルール毎にキャッシュ期間（当該送信制御ルールが無効化される期間に相当）が設定されている。そして、監査者により、当該送信制御ルールが適用されて送信が保留された電子メールに対して送信許可の指示（監査結果）を受け付けると、当該送信許可の指示がなされたときからキャッシュ期間の間は、当該送信制御ルールは確認済みであるとして、当該送信制御ルールを理由とした送信保留は行わない（送信制御ルールが無効化される）。
【０１１１】
このような制御により、同じ理由で送信が保留された電子メールについては監査する手間を省くことが可能となり、監査者の負担を減らすことが可能となる。また、監査する電子メールの数が減ることで、本当に監査が必要な電子メールについて適切に監査を行わせることが可能となる。
【０１１２】
また、本実施例においては、送信制御ルールに合致した（送信制御ルールが適用された）電子メールは送信が保留されるものとして説明したが、送信制御ルールを「条件」と「動作」により定義し、動作として「送信」「保留」「削除」等を定義してもよい。例えば、「添付ファイルがあるメール（＝条件）は保留（＝動作）する」や「送信者の上司がＣＣに含まれているメール（＝条件）は送信する（＝動作）」といった構成とする。この場合は、上述したキャッシュ期間の間は動作を「保留」から「送信」に変更しておくといった制御でも、本実施例と同様の効果を奏することが可能となる。
【０１１３】
次に、保留メール操作・システム設定部１０５がシステムのユーザに提供する画面、および、メール送信部１０６における処理について、図１１〜図１３、図２０、図２１を用いて説明する。
【０１１４】
図１１は、本実施形態における保留メール一覧画面の一例を示しており、システムのユーザは、ＷＥＢブラウザを経由して画面の参照、操作が可能である。保留メール一覧画面には、保留メールテーブル１３１に存在する各メールについて、送信日時、件名、本文組織名、宛先ドメイン、保留理由の一覧を提示する。ここで、保留理由の項目には、適用ルールＩＤごとの説明（宛先ルールテーブル１１２、および、手動ルールテーブル１１３から取得）を表示する。特に、判定区分が「要確認」であるルールＩＤについては、特に確認が必要な項目として、太文字・赤字などで強調して表示する。
【０１１５】
システムのユーザは、保留メール一覧画面において、送信日時の項目を押下することにより、当該メールの保留理由確認画面を参照することができる。
【０１１６】
図１２は、本実施形態における保留理由確認画面の一例を示している。保留理由確認画面は、保留理由、メール内容、削除ボタン、送出ボタンから成る。
【０１１７】
保留理由確認画面における保留理由には、適用ルールＩＤごとのチェックボックスを設け、判定区分が「確認済」のものはチェック済の状態で提示し、「要確認」のものは、チェックを外した状態で提示する。また、宛先ルールに関するルールＩＤにおいては、ルールごとの説明に加え、確認すべき組織名とドメインを合わせて提示する。なお、提示する組織名とドメインは、組織コードごとに色を変えて表示する。ここで表示した組織名、および、ドメインは、クリック操作によって、最尤ドメイン、または、最尤組織名をポップアップで表示する機能を備える。
【０１１８】
保留理由確認画面におけるメール内容には、送受信者のアドレス、件名、添付ファイル名、本文などの情報を提示する。各項目の表示にあたり、本文組織名、および、宛先ドメイン、添付組織名に関しては、組織コードごとの色でハイライトして表示する。ここで表示した組織名、および、ドメインにおいても、クリック操作によって、最尤ドメイン、または、最尤組織名をポップアップで表示する機能を備える。なお、添付組織名が存在する添付ファイルに関しては、クリック操作により、添付ファイルに存在するすべての添付組織名をポップアップにより表示する機能を備える。
【０１１９】
保留理由確認画面における削除ボタンは、一時的に保留しているメールを送信せずに削除するボタンである。システムのユーザが削除ボタンを押下すると、保留メール操作・システム設定部１０５は、保留メールＤＢから該当するレコードを削除した上で、ユーザに保留メール一覧画面を提示する。
【０１２０】
保留理由確認画面における送出ボタンは、後述する送信確認画面へ移行するためのボタンであり、保留理由におけるすべてのチェックボックスがチェック済である場合に押下可能な状態になる。システムのユーザが送信ボタンを押下すると、保留メール操作・システム設定部１０５は、送信確認画面をシステムのユーザに提示する。
【０１２１】
図１３は、本実施形態における送信確認画面の一例を示している。送信確認画面は、新規学習対象一覧、キャンセルボタン、送出ボタンから成る。
【０１２２】
送信確認画面における、新規学習対象一覧は、本文組織名、または、添付組織名と、宛先ドメインの全組合せのうち、送信履歴テーブル１１１に存在しない組合せであり、組合せごとに、新しく送信履歴テーブルに登録するか否かを表すチェックボックスを備える。
【０１２３】
送信確認画面における、キャンセルボタンは、メールの送出を取りやめるボタンである。システムのユーザがキャンセルボタンを押下すると、保留メール操作・システム設定部１０５は、当該メールの保留理由確認画面をシステムのユーザに提示する。
【０１２４】
送信確認画面における、送出ボタンは、当該メールを送出するためのボタンである。システムのユーザが送出ボタンを押下すると、保留メール操作・システム設定部１０５は、新規学習対象一覧においてチェック済の組合せを送信履歴テーブル１１１に追加（送信回数の値は０）し、確認操作キャッシュテーブル１２２において、適用ルールＩＤごとに確認日時を更新する。その後、メール送信部１０６に当該メールを送った上で、保留メールＤＢから該当するレコードを削除し、ユーザに保留メール一覧画面を提示する。
【０１２５】
図２０は、メール１の送出操作後における、確認操作キャッシュテーブル１２２を示している。送出操作前の状態（図１７）と比較して、ルールＩＤ「ＩＮＣＯＲＲＥＣＴ」および「ＮＥＷＤＯＭＡＩＮ」に対する確認日時が更新され、ルールＩＤ「ルール４」に関するレコードが追加されている。
【０１２６】
図２１は、図１３の送信確認画面において、組織名「ＥＸ１」、ドメイン「ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」がチェックされた状態で、メール１が送出された後の送信履歴テーブル１１１を示している。送出前の状態（図１５）と比較して、ドメイン「ＥＸＡＭＰＬＥ１．ＪＰ」と組織名「ＥＸ１」の組合せにおける送信回数が１つ増加しており、ドメイン「ＥＸＡＭＰＬＥ１．ＳＵＢ．ＪＰ」と組織名「ＥＸ１」の組合せが追加されている。
【０１２７】
以上、保留メール操作・システム設定部１０５が提供する画面、および、メール送信部１０６における処理について説明した。同じ送受信者アドレスと本文組織名の組合せに関して、一度確認した保留制御ルールは確認操作キャッシュテーブルに保存され、２回目以降は保留操作が省略されるため、確認操作が形骸化することを防ぐことができる。一方、「添付ファイルの宛先と宛先ドメインの不一致」（宛先ルールＩＤ：Ａ＿ＩＮＣＯＲＲＥＣＴ）のように、一度は内容を確認したとしても、２回目以降の保留操作を省略したくないルールについては、キャッシュ利用設定テーブル１２１において「利用禁止」を設定することにより、保留操作を省略しないように定義することも可能である。
【０１２８】
保留メール一覧画面においては、「要確認」とする保留理由が強調されて表示され、また、保留理由確認画面においては、同一組織ごとに組織名とドメインが異なる色で表示されるため、注視して確認すべき点が明確になる。
【０１２９】
送信履歴テーブル１１１は、保留理由の確認時、および、メールの送出時に更新される仕組みであるため、手動ルールを細かく設定する場合と比較して、ルールのメンテナンスに要するコストを大幅に削減することが可能である。なお、上記では、ドメインと組織名との組合せを学習する実施形態を説明したが、メールアドレスと宛名全体の組合せを学習することで、個人向けのメールに対しても同様のアイデアを適用することが可能になる。
【０１３０】
また、本発明におけるプログラムは、図３〜図９の処理をコンピュータに実行させるプログラムである。なお、本発明におけるプログラムは、図３〜図９の各処理ごとのプログラムであってもよい。
【０１３１】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
【０１３２】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
【０１３３】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。
【０１３４】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３５】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３６】
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３７】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１３８】
１００  メール誤送信防止システム（情報処理装置）
【図１】
2018005415.tif 000003
【図２】
2018005415.tif 000004
【図３】
2018005415.tif 000005
【図４】
2018005415.tif 000006
【図５】
2018005415.tif 000007
【図６】
2018005415.tif 000008
【図７】
2018005415.tif 000009
【図８】
2018005415.tif 000010
【図９】
2018005415.tif 000011
【図１０】
2018005415.tif 000012
【図１１】
2018005415.tif 000013
【図１２】
2018005415.tif 000014
【図１３】
2018005415.tif 000015
【図１４】
2018005415.tif 000016
【図１５】
2018005415.tif 000017
【図１６】
2018005415.tif 000018
【図１７】
2018005415.tif 000019
【図１８】
2018005415.tif 000020
【図１９】
2018005415.tif 000021
【図２０】
2018005415.tif 000022
【図２１】
2018005415.tif 000023