JP4334210B2 - メッセージ提供システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はメッセージ提供システムに関し、例えば、電子メールシステムなどに適用して好適なものである。
【０００３】
【従来の技術】
近年、インターネットや携帯電話の普及の速度は凄まじく、これに比例して、各個人の電子メールの利用も急増している。この結果、人々が電子メールの処理に費やす時間は年々増加している。そして、この問題を解消すべく、電子メールの文章内容をコンピュータに自動解析させようとする研究が広く行なわれている。
【０００４】
文章の解析においては、下記の特許文献１に記載されたものなど、多くのアルゴリズムが研究、開発されているが、ほとんどのアルゴリズムでは、文章を単語毎に区切り、予め用意したデータベースの検索結果を利用してそれが何を示すものかを判定する処理を伴う。文章の中から人名を抜き出す処理も、あらかじめ用意された汎用人名データベースを参照し、これに一致するものを人名候補とする処理が一般的である。しかしながら、この汎用人名データベースの作成手段について述べられることは少なく、実際には人名辞書や電話帳等を手作業やスキャナを用いて一つ一つ入力することによって作成することが多い。
【０００５】
特に日本においては、姓の種類が世界一とも言われ、数万とも数十万とも言われる姓をデータベースに入力することは膨大な手数を要する作業となる。このような膨大な手数によって作成され、数万〜数十万程度におよぶ登録人名数の巨大な汎用人名データベースは、不特定多数のユーザによって、共通に使用される。
【０００６】
電子メールを対象とした文章の解析も同様で、電子メールの本文部分を、当該汎用人名データベースを利用して解析することが可能である。
【０００７】
【特許文献１】
特開平２００１−２０２３８１公報
【０００８】
【発明が解決しようとする課題】
しかしながら、基本的に１対１のコミュニケーション手段として利用される電子メールの性質を考慮すると、この巨大な汎用人名データベースをそのまま電子メールの本文部分の解析に利用した場合には、以下の問題（１）〜（３）が発生する。
【０００９】
（１）記憶資源の利用や検索処理などの観点で、効率が低い。
【００１０】
通常、あるユーザＵ１が受信する電子メールの本文部分の文章に出現する人名の大部分は、そのユーザＵ１の知人の名であり、一般的な電子メールユーザの知人の数は、一生を通して知る知人を累計したとしても前記汎用人名データベースの登録人名数（数万〜数十万程度）に比べてはるかに少ない。
【００１１】
換言するなら、当該汎用人名データベースに登録されている人名の大部分は、ユーザＵ１の知人に存在しない人名であり、ユーザＵ１が受信する電子メールの文章に含まれる確率が極めて低い不必要な人名である。そして、この不必要な人名を汎用人名データベースに蓄積しておくために、膨大な記憶資源が消費されることになるから、前記記憶資源の実効的な利用効率が著しく低い。また、具体的な実行方法にも依存するが、多くの場合、前記検索処理は、汎用人名データベースに登録されている人名の数が多いほど、その検索のために要する処理量が増大し、処理時間も長くなるため、不必要な人名を登録した汎用人名データベースを用いる以上、検索処理の効率も低下する。
【００１２】
（２）汎用人名データベースの登録人名数が多いほど、汎用人名データベースから検索された人名が他の固有名詞と一致する頻度が高くなり、検索結果を利用して行われる電子メールの文章の解析処理の効率や品質が低下する。
【００１３】
一般的に、人名が他の固有名詞（例えば、地名など）と偶然、一致することがあるが、その場合には、その固有名詞が人名であるか地名であるかを識別するための新たな解析処理（例えば、意味解析など）が必要になって処理量が増大するし、その意味解析などの精度が低ければ、前記文章全体の解析結果の品質を低下させる原因ともなる。
【００１４】
上述した不必要な人名を多く登録している前記汎用人名データベースを利用すると、当該汎用人名データベースの検索結果として得られた人名が他の固有名詞と一致する頻度が高いから、当該意味解析などに起因する解析処理の効率低下や、品質低下が大きくなる。
【００１５】
例えば「長野」という文字列が、もし汎用人名データベースに格納されていなければ、前記意味解析などを施すことさえ必要なく、地名として扱われることになる可能性が高いが、「長野」という姓は「鈴木」や「田中」といったものに比べると少ないものの、現実に存在しているので、汎用人名データベースが充実し登録人名数が多いほど「長野」という文字列が汎用人名データベースに登録されている確率は高くなる。前記文章に対する解析の具体的な内容にも依存するが、汎用人名データベースに登録されていれば、登録されていない場合に比べ、「長野」という文字列は人名として扱われる確率が高くなる。
【００１６】
実際には、「長野」という知人がいる人に対して送られた電子メールの文章中に存在する「長野」という文字列はその知人をさす可能性が高いが、「長野」という知人がいない人に対して送られた電子メールの文章中に存在する「長野」という文字列は地名である確率の方が高いと考えられるが、不特定多数のユーザによって共通に用いられる前記汎用人名データベースの登録内容に、個々のユーザごとに相違する知人の名を反映させることは不可能である。
【００１７】
（３）前記汎用人名データベースでは、正規の姓などと異なる変則的な人名に対応することが困難で、柔軟性に欠ける。
【００１８】
電子メールがプライベートの利用にも多く使われるようになった結果、人名として、正規の姓（家族名：Ｆａｍｉｌｙ ｎａｍｅ）ではなく、例えば、愛称（Ｎｉｃｋｎａｍｅ）や名（個人名：Ｐｅｒｓｏｎａｌ ｎａｍｅ）だけを記述した変則的な人名も多く見られるようになったが、これらを前記汎用人名データベースに予め登録して不特定多数のユーザが共有するのは不可能に近い。特に、愛称などは、極めてユニークで変則的なものも多く、愛称を示す文字列を予め予測すること自体、困難である。
【００１９】
また、もし愛称や個人名を予め前記汎用人名データベースに登録することが可能であったとしても、前記姓の場合と同様に、汎用人名データベースの登録人名数（この場合は、登録された愛称や個人名の数）が多くなるほど、他の固有名詞と区別することが困難となり、前記問題（２）が深刻化する。例えば電子メールの文章中に「ユリ」という文字列があった場合、「ユリ」と呼ばれている知人がいるならば、その文字列は人をさす可能性が高く、そうでなければ、その文字列は植物名である可能性が高いが、不特定多数のユーザにより共通に使用される前記汎用人名データベースの登録内容に、個々のユーザごとに相違する知人の愛称や個人名を反映させることは不可能だからである。
【００２０】
前記問題（１）〜（３）を解決するため、不特定多数のユーザが共通に使用する前記汎用人名データベースの替わりに、特定のユーザ（例えば、Ｕ１）だけが使用し、そのユーザＵ１の知人が格納された小さな個別人名データベースを利用することが有効であると考えられるが、そのような個別人名データベースを作成することは、例え、自分の知人だけを入力するにしても、決して容易なものではなく、そのために作業負担も大きい。
【００２１】
通常、ユーザＵ１の知人のすべてが予め整理され明確になっているわけではなく、知人の範囲自体も動的に変動、拡大し得るものだからである。
【００２２】
【課題を解決するための手段】
かかる課題を解決するために、本発明は、発信元から発信先に電子メールによってメッセージを提供するためのメッセージ提供システムにおいて、（１）電子メールの発信元又は発信先となり得る個人、又は、複数人が所属するグループに、関連する個人又はグループの識別情報を蓄積している識別情報用データベース手段と、（２）受信又は送信した電子メールのヘッダを解析するヘッダ解析手段と、（３）前記ヘッダ解析手段が解析を終了した直後に、受信又は送信した前記電子メールのメール本文を解析する本文解析手段とを備え、（２）前記ヘッダ解析手段は、（２−１）受信又は送信した前記電子メールのヘッダ内に所定の記述態様で記述される発信元又は発信先識別情報を、当該記述態様をもとに抽出する識別情報抽出手段と、（２−２）当該識別情報抽出手段が抽出した発信元又は発信先識別情報を前記識別情報用データベース手段に蓄積する識別情報蓄積手段とを備え、（３）前記本文解析手段は、受信又は送信した前記電子メールのメール本文を解析する際には、その電子メールのヘッダ解析で得られた識別情報が蓄積された前記識別情報用データベース手段を優先的に利用することを特徴とする。
【００２４】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかるメッセージ提供システムの一実施形態について説明する。
【００２５】
第１および第２の実施形態に共通する特徴は、受信した電子メールの記述に基づいて、自動的に、当該電子メールを受信した各ユーザ固有の人名データベース（すなわち、個別人名データベース）を作成する点にある。
【００２６】
そして、作成された個別人名データベースは、電子メールの本文部分の解析に活用される。
【００２７】
電子メールの本文部分の解析は、その解析の内容や目的に応じて、電子メール受信時だけでなく、送信時に行われることもあり得るが、以下では、主として受信時に解析を行う場合を想定する。
【００２８】
（Ａ−１）第１の実施形態の構成
本実施形態にかかる通信システム３０の全体構成例を図４に示す。
【００２９】
図４において、当該通信システム３０は、ネットワーク３１と、メールサーバ３２，３３と、通信端末３４，３５とを備えている。
【００３０】
このうちネットワーク３１は、ＬＡＮ（ローカルエリアネットワーク）などであってもかまわないが、ここでは、インターネットであるものとする。
【００３１】
メールサーバ３２はＳＭＴＰサーバやＩＭＡＰ４サーバ（またはＰＯＰ３サーバなど）の機能を有するサーバで、通信端末３４を収容している。したがって通信端末３４（ユーザＵ１）の電子メールアドレス（ＡＵ１＠ＡＡＡ）を宛先電子メールアドレスとする電子メールは、当該メールサーバ３２内の通信端末３４のためのメールボックスに着信する。通信端末３５を操作するユーザＵ２が当該ユーザＵ１宛てに送信する電子メールＭＥ１もそのような電子メールの１つである。
【００３２】
メールサーバ３３は当該メールサーバ３２と同じ機能を有するサーバであってもよいが、ここでは、ユーザＵ２側から送信した電子メールＭＥ１をユーザＵ１側が受信する場合に注目するため、着信した電子メールをその宛先のユーザが取り出すためのプロトコルであるＩＭＡＰ４（やＰＯＰ３）などに対応したＩＭＡＰ４サーバ（またはＰＯＰ３サーバなど）の機能は、当該メールサーバ３５が搭載する必要はない。
【００３３】
通信端末３４はユーザＵ１によって操作される端末で、例えば、通常のパーソナルコンピュータであってよい。ユーザＵ１が電子メール（例えば、ＭＥ１）を受信するときには、当該通信端末３４に搭載されているメールクライアントソフト（メーラ）を利用する。
【００３４】
前記個別人名データベースの配置位置には様々なものが考えられ、例えば、メールサーバ３２などに配置することも可能であるが、処理の効率などの観点から、電子メールＭＥ１のヘッダ部分や本文部分に対する解析を実行する機能主体の配置位置と、当該個別人名データベースの配置位置は近いほうが好ましい。図１に示すように、ヘッダ部分に対する解析（ヘッダ解析）の結果ＣＡ１が当該個別人名データベース（例えば、ＤＢ１）に登録され、当該個別人名データベースの登録内容ＣＡ２（ＣＡ１に等しいこともあり得る）を利用して、本文部分に対する解析（本文解析）が実行されるからである。
【００３５】
本実施形態では、この機能主体を通信端末３４に配置するものとしたため、当該個別人名データベースも通信端末３４に配置する。なお、当該個別人名データベースには、符号ＤＢ１を付与してある。
【００３６】
通信端末３５はユーザＵ２によって操作される端末で、前記通信端末３４と同様に、例えば、通常のパーソナルコンピュータであってよい。ユーザＵ２が電子メール（例えば、ＭＥ１）を送信するときには、当該通信端末３５に搭載されているメーラを利用する。ここで、前記通信端末３４が搭載しているメーラをＭＬ１とし、当該通信端末３５が搭載しているメーラをＭＬ２とする。
【００３７】
前記電子メールＭＥ１を受信する通信端末３４の内部構成例を図５に示す。送信側の通信端末３５の内部構成例も基本的に当該通信端末３４と同じであってよいが、本実施形態では上述したように、電子メール受信時の解析を想定しているため、後述するメール解析部（前記機能主体に対応）４５や前記個別人名データベースＤＢ１など、本実施形態で特徴的な構成要素は、送信側の通信端末３５に搭載される必要はない。
【００３８】
（Ａ−１−１）通信端末の内部構成例
図５において、当該通信端末３４は、通信部４０と、制御部４１と、操作部４２と、表示部４３と、記憶部４４と、前記メール解析部４５とを備えている。
【００３９】
このうち通信部４０はインターネット３１などを経由した通信のために機能する部分で、電子メールＭＥ１の受信時には、前記メールサーバ３２とのあいだでＴＣＰコネクションの設定などを含む通信を行う。
【００４０】
操作部４２は、ユーザＵ１が操作して通信端末３４に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。
【００４１】
表示部４３は様々な情報の画面表示を行うディスプレイ装置に対応する部分で、例えば、前記メーラＭＬ１などの機能に応じ、受信または送信する電子メールの内容（例えば、本文部分の内容など）の画面表示を行う。
【００４２】
前記電子メールの本文部分に対する本文解析には様々な目的のものが考えられ、同じ目的に対応する本文解析にも様々な処理内容のものがあり得るが、一例として、当該本文部分の要約を作成することが当該本文解析の目的であるものとすると、解析結果に応じた前記本文部分（ここでは、電子メールＭＥ１の本文部分）の要約ＡＢ１が当該表示部４３に画面表示されることになる。
【００４３】
制御部４１は、ハードウエア的には当該通信端末３４のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）や前記メーラＭＬ１、ＤＢＭＳ（データベース管理システム）などの各種プログラムに相当する部分である。当該ＤＢＭＳは、前記個別人名データベースＤＢ１を管理するためのシステムである。
【００４４】
記憶部４４はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、前記個別人名データベースＤＢ１や各種のファイルがこの部分に含まれ得る。前記メーラＭＬ１などのプログラムファイルもこのようなファイルの一つであるから、メーラＭＬ１などの物理的な実体は、この記憶部４４に位置する。
【００４５】
なお、当該個別人名データベースＤＢ１には、通信端末３４が受信した電子メール（例えば、ＭＥ１）のヘッダ部分の解析結果に基づいて得られたユーザＵ１の知人の人名を登録したデータベースである。知人は個々のユーザごとに異なるため、ユーザＵ１以外のユーザが使用する通信端末（図示せず）が搭載する個別人名データベースには、ユーザＵ１のための当該個別人名データベースＤＢ１とは異なる人名が登録されることになる。
【００４６】
個別人名データベース（ここでは、ＤＢ１）に登録される人名には、上述した正規の家族名（姓）のほか、個人名や愛称なども含まれる。もちろん、姓名（家族名＋個人名）が含まれていてもよい。
【００４７】
メール解析部４５は通信端末３４が受信した電子メール（例えば、ＭＥ１）に対して解析を行って解析結果を出力する部分で、ヘッダ解析部４５Ａと本文解析部４５Ｂから構成される。メール解析部４５が行う解析には大きく分けて２つの種類があり、その１つは、前記ヘッダ解析であり、もう１つは、前記本文解析である。当該ヘッダ解析は、前記ヘッダ解析部４５Ａが行い、当該本文解析は、前記本文解析部４５Ｂが行う。
【００４８】
当該ヘッダ解析は、具体的には、メールヘッダ中の該当するフィールドからユーザＵ１の知人の人名を抽出する処理である。例えば、現在、広く普及しているＲＦＣ２８２２に準拠した電子メールにおいては、主として、Ｆｒｏｍフィールド内のコメントがこの人名に該当するが、必要に応じて、ＴｏフィールドやＣｃフィールドのコメントから人名を抽出してもよい。
【００４９】
Ｆｒｏｍフィールドに記述されるコメントは、ユーザＵ１が受信した電子メール（ここでは、ＭＥ１）の送信元（ここでは、ユーザＵ２）の人名である。スパムメールなどの例外もあるが、本来、未知の人から電子メールが届くことはないはずなので、Ｆｒｏｍフィールドに記述されたコメントはユーザＵ１の知人の人名である可能性が高い。
【００５０】
また、Ｃｃフィールドは、同じ内容の電子メール（カーボンコピー）を複数の宛先に届ける場合に、その宛先の電子メールアドレスやコメントを記述するフィールドであるため、このフィールドに記述されたコメントは、電子メールＭＥ１と同じものを受信している第３のユーザ（図示せず）の人名である。同じ内容の電子メールを受信したからといって、この第３のユーザとユーザＵ１が知り合いである保証はないが、少なくとも、この第３のユーザと送信元であるユーザＵ２は知り合いであるはずなので、当該電子メールＭＥ１の本文部分に当該第３のユーザの人名が出現する可能性は高く、前記本文解析との関係上、第３のユーザの人名を抽出して個別人名データベースＤＢ１に登録しておく必要性は高い。この場合、第３のユーザは、ユーザＵ１にとって、少なくとも間接的な知人であるといえる。
【００５１】
Ｔｏフィールドは本来、電子メールの宛先の電子メールアドレス（ここでは、ＡＵ１＠ＡＡＡ）やコメントを記述するフィールドであるが、このＴｏフィールドに複数の宛先の電子メールアドレスやコメントを羅列して前記Ｃｃフィールドと同様な使い方をすることもあるため、前記Ｃｃフィールドと同様な理由で、このフィールドのコメントから人名を抽出し個別人名データベースＤＢ１に登録しておく必要性は高いといえる。
【００５２】
なお、各フィールドに対する前記コメントは必ずしも必須の記述事項ではないため、その記述自体が存在しないこともある。もちろん、記述が存在しなければ、そのフィールドから知人の人名を抽出することはできないが、電子メールユーザは、他の電子メールユーザに理解しやすいように配慮して、コメントを記述することが多い。
【００５３】
また、コメントが存在しない場合などには、コメントの替わりに、電子メールアドレス中で＠マークから左側に記述されるユーザ名（通常、ユーザのメールボックス名と同じ）を抽出するようにしてもよい。当該ユーザ名は、例えば、前記電子メールアドレス「ＡＵ１＠ＡＡＡ」の例では、「ＡＵ１」の部分に相当する。
【００５４】
コメントの記述を省略する場合、このユーザ名が極めて分かりやすい記述（例えば、ユーザの家族名や姓名をそのままアルファベット表記した記述など）であることが少なくないからである。ユーザ名が十分に分かりやすければ、電子メールを受信したユーザにとって、当該ユーザ名の記述は実質的にコメントと同等な機能を持つことになる。
【００５５】
電子メールの本文部分の人名はアルファベットではなく、漢字や仮名で記述されることが多いが、アルファベット表記を漢字や仮名の表記に変換することは比較的容易なので、その変換結果を、個別人名データベースＤＢ１に登録しておくとよい。
【００５６】
なお、ヘッダ解析部４５Ａが電子メール（例えば、ＭＥ１）のヘッダ部分から抽出し個別人名データベースＤＢ１に登録した人名は、当該電子メールＭＥ１の本文解析を行うときだけ使用し、その本文解析が完了したあとで削除することも可能であるが、削除せずに保存しておき、以降に受信される電子メール（図示せず）の本文解析にも活用することが望ましい。
【００５７】
保存することにより、電子メールを受信するたびに当該個別人名データベースＤＢ１の登録人名数が増加し、ユーザＵ１の知人または間接的な知人の人名を、ほとんど漏れなく登録した有用なデータベースが構成される。また、当該個別人名データベースＤＢ１に登録されるのは、基本的に、ユーザＵ１の知人または間接的な知人の人名だけである。
【００５８】
通信端末３４から電子メールを送信するときにもヘッダ解析を実行する場合には、送信時のヘッダ解析によって抽出された知人の人名も、受信時のヘッダ解析で抽出された人名と同様、個別人名データベースＤＢ１へ登録しておき、受信時の本文解析に活用してよい。
【００５９】
ユーザＵ１が送信する電子メール（図示せず）のヘッダ部分の各フィールド（前記Ｔｏフィールドや、Ｃｃフィールド、あるいは、Ｂｃｃフィールド）から抽出できる人名は、通常、ユーザＵ１の知人であり、ユーザＵ１が受信する電子メール（例えば、ＭＥ１）の本文部分にその人名が出現する確率が高いからである。
【００６０】
前記本文解析部４５Ｂが行う本文解析の目的の具体例には、上述した本文部分の要約ＡＢ１の生成など様々なものがあり得るが、いずれにしても、当該本文解析は、個別人名データベースＤＢ１に登録された人名を利用して実行される。
【００６１】
以下、上記のような構成を有する本実施形態の動作について、図２のフローチャートを参照しながら説明する。
【００６２】
図２のフローチャートは、Ｓ１〜Ｓ５の各ステップを備えている。
【００６３】
（Ａ−２）第１の実施形態の動作
前記通信端末３５を操作するユーザＵ２がメーラＭＬ２を利用して作成、送信し、メールサーバ３３，３２を経由して配送され、ユーザＵ１のメールボックスに着信した電子メールＭＥ１を、通信端末３４を操作するユーザＵ１がメーラＭＬ１を利用して取り出すと、当該電子メールＭＥ１は通信端末３４へ届く。
【００６４】
このとき、通信端末３４内の前記ヘッダ解析部４５Ａが前記ヘッダ解析を実行し、電子メールＭＥ１のヘッダ部分から該当するフィールドの記述内容を取得する（Ｓ１）。ここでは、上述したＦｒｏｍ、Ｃｃ、Ｔｏの各フィールドのすべてから、その記述内容を取得してもよく、一部だけから取得してもよい。
【００６５】
そして、当該フィールドの記述内容のなかから、前記コメントを取得する（Ｓ２）。
【００６６】
コメントの記述が存在しないためにコメントの取得に失敗した場合、次のステップＳ３はＮｏ側に分岐して処理は前記本文解析部４５Ｂが行う本文解析に進むが、コメントの取得に成功した場合には、ステップＳ３はＹｅｓ側に分岐してコメントのデコードを行う（Ｓ４）。
【００６７】
電子メールのヘッダは一般に、漢字を直接記述することができない規則であるので、漢字でコメント（人名など）を記述すると、電子メールの送信時に、当該漢字は、特定の規則に基づきアルファベットなどにエンコード（符号化）される。もし、エンコードされたままの状態で前記個別人名データベースＤＢ１に格納すると、本文解析を行い個別人名データベースＤＢ１の検索結果を得るたびにデコードする必要が生じてオーバーヘッドが大きくなるから、このように登録前にデコードして本文解析などに有利な所定の文字コードに変換し、デコードした人名を個別人名データベースＤＢ１に登録するのが効率的である（Ｓ５）。
【００６８】
このようにして個別人名データベースＤＢ１への人名の登録を行うため、ユーザＵ１の知人等のなかに、例えば、上述した「長野」という姓を持つ者が存在する場合には当該「長野」が個別人名データベースＤＢ１に登録されるが、存在しない場合には、当該「長野」が個別人名データベースＤＢ１に登録されることはない。この点は、前記「ユリ」や愛称などについても同様である。
【００６９】
また、前記「鈴木」や「田中」など、我が国では極めて多い姓でさえ、ユーザＵ１の知人等のなかに、「鈴木」や「田中」という姓を持つ者が存在しなければ、個別人名データベースＤＢ１にこれらが登録されることはない。
【００７０】
前記ステップＳ５の次には、前記ステップＳ３がＮｏ側に分岐した場合と同様に、前記本文解析部４５Ｂによる本文解析が実行される。上述したように、個別人名データベースＤＢ１には、当該電子メールＭＥ１だけでなく、電子メールＭＥ１より前に当該通信端末３４が受信または送信した電子メールのヘッダ部分の各フィールドから取得した人名も登録してあるため、当該本文解析では、これらの人名も個別人名データベースＤＢ１から検索されて活用される。
【００７１】
本文解析の結果として、例えば、前記要約ＡＢ１が通信端末３４の表示部４３に画面表示され得る点は、すでに述べた通りである。
【００７２】
なお、ステップＳ３がＮｏ側に分岐したときには、本文解析を実行するまえに、前記コメントの替わりに上述したユーザ名の抽出、登録等を行うようにしてもよい。
【００７３】
以上のような動作により、前記個別人名データベースＤＢ１に登録されるのは、実際に、通信端末３４で受信または送信された電子メールのヘッダ部分から抽出された人名だけであるため、上述した汎用人名データベースに比べると、登録人名数ははるかに少ない。しかも、登録されているのは、ユーザＵ１の知人等の特定の人名に限られるため、不特定多数の人名を登録する必要がない。
【００７４】
すなわち、個別人名データベースＤＢ１には基本的に、ユーザＵ１の知人または間接的な知人の人名だけしか登録されていないため、上述した記憶資源（ここでは、記憶部４４）の利用や検索処理などの観点で、効率が高い。
【００７５】
また、個別人名データベースＤＢ１から検索された人名が他の固有名詞と一致する頻度も、前記汎用人名データベースに比べて十分に低いため、当該個別人名データベースＤＢ１の検索結果を利用して実行される前記本文解析の効率が高く、なおかつ、解析結果の品質も高い。
【００７６】
さらに、登録する人名は単純に電子メールのヘッダ部分の各フィールドから取り出した記述（コメント等の記述）だけに基づいているため、前記愛称や個人名だけの人名など、変則的な人名も、姓や姓名から成る正規の人名と同様の簡単な処理で登録することが可能である。
【００７７】
このため、上述した問題（１）〜（３）を解決することができる。
【００７８】
なお、前記ＴｏフィールドやＣｃフィールドからは、ユーザＵ１自身の人名が取得される可能性も高い。ユーザＵ１自身の人名も、電子メール（ここでは、ＭＥ１）の本文部分に出現する可能性が高いため、個別人名データベースＤＢ１に登録しておくことが望ましい。
【００７９】
また、何回も電子メール（ＭＥ１はその１つ）を受信していると、同じ人名（ユーザＵ１自身の人名も含む）が複数回、取得される可能性が高いが、記憶部４４の記憶容量を節約するため、同じ人名は一度だけ登録することが望ましい。ただし同じ人名であるか否かの判断も含め、同じ人名を一度だけ登録することは、通常、前記ＤＢＭＳの機能によって実現されるため、ヘッダ解析部４５Ａがそのために特段の機能を持つ必要性は低い。
【００８０】
（Ａ−３）第１の実施形態の効果
本実施形態によれば、ユーザ（Ｕ１）が電子メール（例えば、ＭＥ１）を受信または送信するだけで、極めて有用な前記個別人名データベース（ＤＢ１）を、自動的に生成することが可能である。
【００８１】
当該個別人名データベースは、愛称などの変則的な人名を容易に登録できる点で柔軟性に優れ、ユーザ（Ｕ１）の知人等、特定の人名だけを登録し、不特定多数の人名を登録する必要がない点で記憶資源（例えば、記憶部４４）の利用効率が高い。
【００８２】
また本実施形態では、このような個別人名データベースを利用して本文解析を行うことにより、検索処理の効率が向上するため当該検索処理の結果を利用する本文解析の効率も向上する。
【００８３】
さらに、当該個別人名データベースにはユーザ（Ｕ１）の知人等、特定の人名しか登録されていないため、不特定多数の人名が検索されることに起因して発生する検索された人名と他の固有名詞との一致の頻度も低減し、この点でも、本文解析の効率が向上する。また、当該一致が発生した場合に必要となる意味解析などの実行に起因する本文解析の効率の低下や、品質の低下を抑制することも可能である。
【００８４】
（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。
【００８５】
第１の実施形態では、前記コメントの記述はすべて人名を示すものとしたが、実際には、団体や、メーリングリストなどの名称を示すこともあるため、本実施形態は、このようなケースにも対応できるようにしたものである。
【００８６】
上述した本文解析の内容や目的によっては、これら団体名なども、広義の人名とみなして前記個別人名データベースＤＢ１に登録したほうが好ましい結果が得られることも多いものと考えられるが、本実施形態が想定するのは、個別人名データベースＤＢ１には、真に、人名のみを登録したほうがよいケースである。
【００８７】
（Ｂ−１）第２の実施形態の構成および動作
本実施形態の通信システム１０の全体構成例は図４に示す通りで、第１の実施形態と同じであってよい。同様に、本実施形態の通信端末３４の内部構成例も図５に示す通りで、第１の実施形態と同じであってよい。
【００８８】
本実施形態が第１の実施形態と相違するのは、実質的に、前記ヘッダ解析部４５Ａの動作のみである。
【００８９】
当該ヘッダ解析部４５Ａの動作は、図３のフローチャートに示す。図３のフローチャートは、Ｓ１〜Ｓ７の各ステップを有するが、すでに説明した図２のフローチャートと同じ符号を付与した各ステップＳ１〜Ｓ５の処理は、第１の実施形態と同じである。
【００９０】
図３のフローチャートは、前記ステップＳ４とＳ５のあいだに、ステップＳ６とＳ７が挿入された構造となっている。
【００９１】
当該ステップＳ４で前記コメントの記述がデコードされたあとに実行されるステップＳ６では、非人名判定処理を実行する。
【００９２】
非人名判定処理はコメントの記述が人名であるか否かを判定するための処理である。非人名判定処理の具体的な内容としては様々なものが考えられるが、一例として、人名の構成要素となる可能性の少ない所定のキーワード（例えば、「株式会社」など）を予め設定しておき、そのキーワードと同じ文字列が含まれている記述は人名ではないと判定することも簡便である。
【００９３】
当該非人名判定処理の結果、人名でない（人名の可能性が低い）と判定された場合には、ステップＳ７はＹｅｓ側に分岐してその記述は個別人名データベースＤＢ１に登録しないが、反対に、人名である（人名の可能性が高い）と判定された場合には、ステップＳ７はＮｏ側に分岐して当該記述を個別人名データベースＤＢ１に登録することになる。
【００９４】
以降の動作も含め、これ以外の動作は、第１の実施形態と同様である。
【００９５】
（Ｂ−２）第２の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【００９６】
加えて、本実施形態では、人名であると判定された（人名である可能性が高い）記述だけを個別人名データベース（ＤＢ１）に登録することができるため、前記本文解析が団体名などを人名と区別する必要性の高いものである場合にも適切に対応でき、高い品質の解析結果を得ることが可能である。
【００９７】
（Ｃ）他の実施形態
第１および第２の実施形態における前記本文解析の内容や目的は上述した要約の作成に限らない。例えば、要約を作るのではなく、本文部分の重要と推定される一部だけを単純に切り取って抽出するための解析であってもよい。
【００９８】
また、本文解析の解析結果の出力先は、第１および第２の実施形態における表示部４３に限定する必要はない。この出力先は本文解析の目的などに依存して変化し得るからである。例えば、ネットワーク経由で転送し、通信端末３４以外の通信端末（図示せず）から出力させるようにしてもよい。
【００９９】
さらに、本文解析は、その内容や目的に応じて、電子メール受信時だけでなく、送信時に行ってもよい点は上述した通りである。電子メール送信時の解析が必要となるケースとしては、一例として、外部に持ち出すことが禁じられている機密情報を社員などが電子メールを悪用して社外へ流出させることを防止するケースなどがあげられる。これは、例えば、電子メールの本文部分などの解析を通じて機密情報の流出を自動的に検知し、阻止する機能を有するセキュリティシステムなどで利用できる。
【０１００】
なお、前記個別人名データベースＤＢ１に登録されている各人名には、最後に読み出された日付を対応付けて管理しておき、所定期間以上、読み出されない人名など、使用の頻度が極めて低いものは削除するようにしてもよい。人名でない記述を誤って登録した場合などには、この削除によって、個別人名データベースＤＢ１の内容を適正化することができる。
【０１０１】
また、上記第１および第２の実施形態では、電子メールの送信元のユーザＵ２も宛先のユーザＵ１も一人であったが、いずれか一方または双方が、複数のユーザから構成されるグループであってもよいことは当然である。一般的に、前記ＩＭＡＰ４などに対応したメールサーバでは、１つのメールボックスを複数のユーザで共有することも容易である。
【０１０２】
例えば、電子メールを受信する側がグループの場合には、当該電子メールのＴｏフィールドなどに記述される宛先電子メールアドレスも、グループを構成する個々のユーザではなく、当該グループそのものを指定することになるため、前記個別人名データベース（ＤＢ１）は、個々のユーザごとに設けられるのではなく、グループごとに設けることになる。
【０１０３】
なお、宛先（または送信元）のユーザが一人で前記ＴｏフィールドやＦｒｏｍフィールドに当該一人のユーザの電子メールアドレスが記述される場合であっても、個別人名データベースをグループごとに設けることは可能である。
【０１０４】
例えば、共通の知人が多い複数のユーザが操作する各通信端末をネットワークで接続し、いずれかのユーザが電子メールを受信したり、送信したりするたびに、前記ヘッダ解析を実行して、当該ヘッダ解析で抽出された記述（コメントなど）を同じ個別人名データベースに登録するように構成することが考えられる。
【０１０５】
一般的に、個別人名データベースの導入直後は、登録人名数が少なすぎて高い品質の本文解析結果を得ることが困難であることが予想できるが、このような構成を取ることによって、早期に、個別人名データベースの登録人名数が十分な数に達することが期待できる。
【０１０６】
また、個別人名データベースの導入直後に登録人名数が少なすぎて高い品質の本文解析結果を得ることが困難となること等を防止するため、導入時に、ユーザＵ１自身が手作業で、その場で思い出せる知人の人名を個別人名データベースＤＢ１へ登録することができるようにしてもよい。
【０１０７】
さらに、必要に応じて、導入時以降に、ユーザＵ１が個別人名データベースＤＢ１中の登録内容を確認し、不必要と判断した人名等の登録を適宜、抹消できるようにしてもよい。
【０１０８】
また、上記第１および第２の実施形態では、本発明を電子メールに適用したが、本発明の適用範囲は電子メールに限定されるものではない。
【０１０９】
例えば、特定のグループ内で利用される電子掲示板などにも、本発明を適用できる可能性がある。電子掲示板は通常、一人の発信者が、不特定多数のユーザに情報を発信するための通信手段であるが、電子掲示板の利用方法や電子掲示板自体の構成によっては、一人（または特定グループ）の発信者が特定の一人（または特定グループ）に対して情報を発信するために利用することも可能だからである。
【０１１０】
なお、上記第２の実施形態では、人名でないと判定された記述はいずれのデータベースにも登録しなかったが、例えば、団体名を登録するための個別団体名データベースを用意して、当該個別団体名データベースにその記述を登録するようにしてもよい。本文解析の内容などによっては、個別団体名データベースの登録内容も有用である。
【０１１１】
また、上記第１および第２の実施形態では、電子メールの（ヘッダ部分の）記述から生成した個別人名データベースを、電子メールの（本文部分の）解析に利用したが、個別人名データベースはそれ自体で価値を有するものであるため、本文解析以外の用途に利用することも可能である。
【０１１２】
一例としては、ユーザ（Ｕ１）とは異なる第３者が、例えば、ＣＲＭ（顧客関係管理）のために、当該個別人名データベースの登録内容を活用することが考えられる。
【０１１３】
また、パーソナルコンピュータである通信端末３４は、住所録などのＰＩＭ（個人情報管理）ソフトを搭載していることも多いが、当該ＰＩＭソフトの登録内容と前記個別人名データベースの登録内容を相互に利用したり、補完したりできるように構成してもよい。
なお、前記通信端末３４，３５はパーソナルコンピュータであるものとしたが、これらが、携帯電話機、ＰＨＳ端末、メール端末などの携帯通信端末であってもよいことは当然である。
【０１１４】
また、前記メール解析部４５や個別人名データベースＤＢ１は、上述した前記通信端末３４やメールサーバ３２などのほか、メールサーバ３２と通信端末３４のあいだ等に介在し得るファイアウオールなどに配置することも可能である。
【０１１５】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１１６】
【発明の効果】
以上に説明したように、本発明では、メッセージ発信元ユーザ集合を特定する発信元識別情報を蓄積することにより、メッセージ発信先ユーザ集合ごとに固有の蓄積内容を有する柔軟な識別情報用データベース手段を自動的に生成することができ、メッセージ発信先ユーザ集合に属するユーザに当該識別情報用データベース手段を生成するための作業負担は、ほとんど発生しない。
【０１１７】
また、本発明のメッセージ提供システムでは、このような識別情報用データベース手段を利用することにより、高品質なメッセージ本文の解析結果を、少ない処理量で効率的に得ることが可能となる。
【図面の簡単な説明】
【図１】第１および第２の実施形態の動作説明図である。
【図２】第１の実施形態の動作説明図である。
【図３】第２の実施形態の動作説明図である。
【図４】第１および第２の実施形態にかかる通信システムの全体構成例を示す概略図である。
【図５】第１および第２の実施形態で使用する通信端末の内部構成例を示す概略図である。
【符号の説明】
３０…通信システム、３１…ネットワーク（インターネット），３２，３３…メールサーバ、３４，３５…通信端末、４０…通信部、４１…制御部、４２…操作部、４３…表示部、４４…記憶部、４５…メール解析部、４５Ａ…ヘッダ解析部、４５Ｂ…本文解析部、ＭＥ１…電子メール。

Claims (2)

1. 発信元から発信先に電子メールによってメッセージを提供するためのメッセージ提供システムにおいて、
   電子メールの発信元又は発信先となり得る個人、又は、複数人が所属するグループに、関連する個人又はグループの識別情報を蓄積している識別情報用データベース手段と、
   受信した又は送信する電子メールのヘッダを解析するヘッダ解析手段と、
   前記ヘッダ解析手段が解析を終了した直後に、受信した又は送信する前記電子メールのメール本文を解析する本文解析手段とを備え、
   前記ヘッダ解析手段は、
   受信した又は送信する前記電子メールのヘッダ内に所定の記述態様で記述される発信元又は発信先識別情報を、当該記述態様をもとに抽出する識別情報抽出手段と、
   当該識別情報抽出手段が抽出した発信元又は発信先識別情報を前記識別情報用データベース手段に蓄積する識別情報蓄積手段とを備え、
   前記本文解析手段は、受信した又は送信する前記電子メールのメール本文を解析する際には、その電子メールのヘッダ解析で得られた識別情報が蓄積された前記識別情報用データベース手段を利用する
   ことを特徴とするメッセージ提供システム。
2. 請求項１に記載のメッセージ提供システムにおいて、
   前記ヘッダ解析手段は、前記識別情報抽出手段が抽出した前記発信元又は発信先識別情報が非人名であるか否かを判定する非人名判定手段をさらに備え、前記識別情報蓄積手段は、前記非人名判定手段が非人名ではないと判定した場合に、前記識別情報用データベース手段に蓄積することを特徴とするメッセージ提供システム。

Images