JP5929354B2 - 受信メール情報提供方法、メール装置及びメールプログラム - Google Patents

Description

本件は、受信メール情報提供方法、メール装置及びメールプログラムに関する。

電子メールを送信する場合、文面の最後に署名データ（シグネチャ）が付加されることが多い。例えば、電子メールを会社内外でのやりとりに用いる場合、シグネチャには、自らの所属名称、内線/外線電話番号、役職、ＦＡＸ番号などが記載される。この情報は、そのメールを発信した立場を示すものとして利用され、どの部署のどの役職の誰が発信したかということが電子データとして残される。

なお、特許文献１には、署名データの記載内容の変更状況に応じて適切な注釈文を生成し、電子メール本文中に挿入する方法についての開示がなされている。

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

電子メールのシグネチャは、メールを受信してから期間が経過した後においても、電子メールの発信者の連絡先情報を取得するために利用されることがある。例えば、あるユーザに電話をかけたいと考えた人が、過去に受信した電子メールを検索し、検索された電子メール本文に付加されたシグネチャに含まれる電話番号に電話をかけるような場合である。

しかしながら、このような利用方法では、電子メールが発信された後に電子メールの発信者の所属部署や連絡先が変更された場合、誤った（変更前の）連絡先に連絡をしてしまうことになる。また、上述した特許文献１の技術を用いたとしても、電子メールが発信された後に発信者の所属部署や連絡先が変更された場合には、ユーザによる誤った連絡先への連絡を防止することができない。

そこで本件は上記の課題に鑑みてなされたものであり、受信メールのメール本文に挿入された署名データの内容が事後的に変更されたことをユーザに通知することが可能な受信メール情報提供方法、メール装置及びメールプログラムを提供することを目的とする。

本明細書に記載の受信メール情報提供方法は、メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信する受信工程と、各ユーザの属性に関する情報を格納する第２格納部と、指定された前記受信メール情報と、を参照して、指定された前記受信メール情報のメール本文に挿入された署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なるか否かを判断する判断工程と、前記判断工程の結果、前記署名データの内容が指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断された場合に、該判断結果を付加して、指定された前記受信メール情報を表示する画面を生成する生成工程と、をコンピュータが実行する受信メール情報提供方法である。

本明細書に記載のメール装置は、メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部と、各ユーザの属性に関する情報を格納する第２格納部と、前記第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信したときに、前記第２格納部と、指定された前記受信メール情報と、を参照して、指定された前記受信メール情報のメール本文に挿入された署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なるか否かを判断する判断部と、前記判断部による判断の結果、前記署名データの内容が指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断された場合に、該判断結果を付加して、指定された前記受信メール情報を表示する画面を生成する生成部と、を備えている。

本明細書に記載のメールプログラムは、メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信し、各ユーザの属性に関する情報を格納する第２格納部と、指定された前記受信メール情報と、を参照して、指定された前記受信メール情報のメール本文に挿入された署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なるか否かを判断し、前記判断する処理における判断の結果、前記署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断された場合に、該判断結果を付加して、指定された前記受信メール情報を表示する画面を生成する、処理をコンピュータに実行させるメールプログラムである。

本明細書に記載の受信メール情報提供方法、メール装置及びメールプログラムは、受信メールのメール本文に挿入された署名データの内容が事後的に変更されたことをユーザに通知することができるという効果を奏する。

第１の実施形態に係る電子メールシステムの構成を概略的に示す図である。 図２（ａ）は、図１のメールサーバのハードウェア構成であり、図２（ｂ）は、図１のクライアント端末のハードウェア構成である。 図１のメールサーバ及びクライアント端末の機能ブロック図である。 図３のメールＤＢのデータ構造を示す図である。 図３の認証ＤＢのデータ構造を示す図である。 図３の人事ＤＢのデータ構造を示す図である。 第１の実施形態に係るメール処理部と表示・送受信部の処理の一連の流れを示すフローチャート（その１）である。 第１の実施形態に係るメール処理部と表示・送受信部の処理の一連の流れを示すフローチャート（その２）である。 第１の実施形態に係るメール処理部と表示・送受信部の処理の一連の流れを示すフローチャート（その３）である。 図１０（ａ）は、第１の実施形態に係る認証画面の一例を示す図であり、図１０（ｂ）は、第１の実施形態に係る認証エラー画面の一例を示す図である。 第１の実施形態に係るメール一覧表示画面の一例を示す図である。 図１２（ａ）は、図９のステップＳ３６においてメール処理部からクライアント端末に送信されるメッセージ表示画面の一例を示す図であり、図１２（ｂ）は、図９のステップＳ４４においてメール処理部からクライアント端末に送信されるメッセージ表示画面の一例を示す図である。 図９のステップＳ１３４で表示される画面の一例を示す図である。 第２の実施形態に係るメールサーバ及びクライアント端末の機能ブロック図である。 図１４のシグネチャＤＢのデータ構造を示す図である。 第２の実施形態に係るメール処理部と表示・送受信部の処理の一連の流れを示すフローチャート（第１の実施形態の図８に対応するフローチャート）である。 第２の実施形態に係るメール処理部と表示・送受信部の処理の一連の流れを示すフローチャート（第１の実施形態の図９に対応するフローチャート）である。

《第１の実施形態》
以下、電子メールシステムの第１の実施形態について、図１〜図１３に基づいて詳細に説明する。図１には、第１の実施形態に係る電子メールシステム１００が概略的に示されている。

本第１の実施形態の電子メールシステム１００は、図１に示すように、メール装置としてのメールサーバ１０と、クライアント端末２０と、を備える。メールサーバ１０とクライアント端末２０は、インターネットやＬＡＮなどのネットワーク８０に接続されている。この電子メールシステム１００は、クライアント端末２０においてブラウザ上に表示されるＷＥＢメールの画面（メールサーバ１０から提供）において、利用者が入力や操作を行うことで、クライアント端末２０間における電子メールのやり取りを可能にするシステムである。なお、本実施形態では、一例として、クライアント端末２０を利用する利用者は、同一の会社に属する人物であるものとする。すなわち、クライアント端末２０から送信される電子メールは、全て、社内から発信される電子メールであるものとする。ただし、これはあくまで一例であり、同一の会社に属する人物に限らず、クライアント端末２０を利用する利用者は、同一のメールサーバを利用している人物であればよい。具体的には、あるプロバイダがメールサーバを用意する場合には、クライアント端末２０を利用する利用者は、そのプロバイダに加入している組織、利用者であればよい。

図２（ａ）には、メールサーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、メールサーバ１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard
Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらメールサーバ１０の構成各部は、バス９８に接続されている。メールサーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（メールプログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（メールプログラムを含む）をＣＰＵ９０が実行することにより、図３に示す機能が実現される。

また、図２（ｂ）には、クライアント端末２０のハードウェア構成が示されている。図２（ｂ）に示すように、クライアント端末２０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、表示部１９３、入力部１９５、ネットワークインタフェース１９７、及び可搬型記憶媒体用ドライブ１９９等を備えており、クライアント端末２０の構成各部は、バス１９８に接続されている。クライアント端末２０においても、ＣＰＵ１９０がプログラムを実行することで、図３に示す機能が実現される。

図３には、メールサーバ１０及びクライアント端末２０の機能ブロック図が示されている。図３に示すように、メールサーバ１０では、ＣＰＵ９０がプログラムを実行することで、判断部及び生成部としてのメール処理部１２の機能が実現されている。また、クライアント端末２０では、ＣＰＵ１９０がプログラムを実行することで、表示・送受信部２２としての機能が実現されている。なお、図３には、メールサーバ１０のＨＤＤ９６等に格納されている第１格納部としてのメールＤＢ３２、認証ＤＢ３４、及び第２格納部としての人事ＤＢ３６も図示されている。

メール処理部１２は、ＷＥＢメールの画面作成や、クライアント端末２０に対する画面の送信、ＷＥＢメールの送受信処理などを行う。

表示・送受信部２２は、メール処理部１２から送信されてきたＷＥＢメールの画面をブラウザ上に表示する。また、表示・送受信部２２は、クライアント端末２０の利用者から入力された情報や当該利用者からの指示（ブラウザ上での入力による指示）をメールサーバ１０に対して送信する。

メールＤＢ３２は、クライアント端末２０間で送受信された電子メールの情報を格納するデータベースである。メールＤＢ３２は、図４に示すように、「利用者ＩＤ」、「種別」、「メッセージＩＤ」、「宛先」、「差出人」、「メール情報（件名、本文）」、「発信日時」の各フィールドを有する。「利用者ＩＤ」のフィールドには、電子メールの送受信を行った利用者の利用者ＩＤが入力される。「種別」のフィールドには、電子メールが利用者ＩＤに対応する利用者によって送信されたのか受信されたのかの情報が入力される。「メッセージＩＤ」のフィールドには、電子メール毎に定義されるユニークなＩＤが入力される。「宛先」フィールドにはそのメールの宛先のメールアドレスが入力され、「差出人」のフィールドには、差出人のメールアドレスが入力される。なお、種別が「送信」の場合には、差出人はその利用者のメールアドレスとなる。「メール情報（件名、本文）」のフィールドには、電子メールの件名及び本文そのものが入力される。なお、本文の欄には、本文に付加されている署名データ（シグネチャ）も入力されるものとする。また、「発信日時」のフィールドには、メールを送信した日時（メールを受信した日時やメールを確認した日時ではない）が入力される。なお、本実施形態では、１つのメールＤＢ３２にて、複数の利用者の送受信メール情報を格納する形態としているが、利用者毎にフォルダを用意し、そのフォルダ配下にその利用者に対応する送受信メール情報を格納するという形態でも良い。その場合は、当然ながら、利用者ＩＤフィールドは不要となる。

図３に戻り、認証ＤＢ３４は、利用者がログインする際の認証に用いる情報が格納されたデータベースである。この認証ＤＢ３４には、図５に示すように、利用者ＩＤと、利用者ＩＤに対応するパスワードと、が格納されている。

人事ＤＢ３６は、各利用者の属性に関する情報を格納するデータベースであり、図６に示すように、「利用者ＩＤ」、「所属部署名」、「役職」、「氏名」、「発令日」、「内線」、「外線」、「事業所」、「フロア」の各フィールドを有している。「所属部署名」、「役職」、「氏名」のフィールドには、利用者ＩＤに対応する人物の所属部、職制役職、氏名が入力される。「発令日」のフィールドには、各レコードの人事情報の効力が発生する日（人事異動発令日）が入力される。「内線」、「外線」のフィールドには、利用者ＩＤの連絡先電話番号が入力される。「事業所」のフィールドには、事業所名が入力され、「フロア」のフィールドには、事業所のうちの利用者が常駐しているフロアが入力される。なお、人事ＤＢ３６は、予め人事部などの管理者等により作成されるものとし、変更があった場合には管理者等によって適宜更新されるものとする。

次に、本実施形態におけるメール処理部１２と、表示・送受信部２２の処理について、図７〜図９のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。

図７〜図９には、メール処理部１２と表示・送受信部２２の処理の一連の流れがフローチャートにて示されている。なお、図７〜図９のフローチャートでは、メール処理部１２と表示・送受信部２２の処理・判断のタイミングを考慮して、各処理・判断を配置している。

図７の処理では、表示・送受信部２２が、ステップＳ１００において、利用者から電子メールの表示要求を受け付けるまで待機する。この場合の表示要求は、利用者がブラウザ上でＷＥＢメールサービスのアドレスに対してアクセスすることにより行われる。ステップＳ１００の判断が肯定されると、ステップＳ１０２に移行する。ステップＳ１０２に移行すると、表示・送受信部２２は、メールサーバ１０（メール処理部１２）に対して、メール一覧表示要求を送信する。

これに対し、メール処理部１２では、ステップＳ１０において、メール一覧表示要求をクライアント端末２０（表示・送受信部２２）から受信するまで待機している。したがって、メール処理部１２では、表示・送受信部２２が、ステップＳ１０２の処理を行った段階で、ステップＳ１２に移行する。

ステップＳ１２では、メール処理部１２が、利用者ＩＤ、パスワードの入力画面をクライアント端末２０（表示・送受信部２２）に送信する。この場合の入力画面は、図１０（ａ）に示すような認証画面（利用者ＩＤ及びパスワードの入力欄と、送信及びキャンセルボタンを含む画面）であるものとする。

一方、表示・送受信部２２は、ステップＳ１０２の後、ステップＳ１０４において、メールサーバ１０のメール処理部１２から、利用者ＩＤ、パスワード入力画面を受信するまで待機している。したがって、上述したようにステップＳ１２において入力画面がメールサーバ１０側から送信されてきた段階で、表示・送受信部２２は、ステップＳ１０６に移行することになる。

ステップＳ１０６では、表示・送受信部２２は、利用者ＩＤ及びパスワードの入力画面（図１０（ａ））をクライアント端末２０の表示部１９３上（ブラウザ内）に表示する。次いで、ステップＳ１０８では、表示・送受信部２２が、利用者ＩＤ及びパスワードの入力を受け付けるまで待機する。この場合、利用者がクライアント端末２０の入力部１９５を用いて利用者ＩＤ及びパスワードを入力し、かつ、送信ボタンを押した段階で、ステップＳ１１０に移行することになる。

ステップＳ１１０に移行すると、表示・送受信部２２は、利用者ＩＤ及びパスワードをメールサーバ１０（メール処理部１２）に対して送信する。なお、ステップＳ１１０の処理が終了した後は、ステップＳ１１２に移行する。

これに対し、メール処理部１２では、ステップＳ１２の後、ステップＳ１４において、利用者ＩＤ及びパスワードがクライアント端末２０（表示・送受信部２２）から送信されてくるまで待機している。したがって、メール処理部１２は、ステップＳ１１０において、表示・送受信部２２から利用者ＩＤ等が送信されてきた段階で、ステップＳ１６に移行する。

ステップＳ１６に移行すると、メール処理部１２は、送信されてきた利用者ＩＤ及びパスワードと、認証ＤＢ３４を用いて、利用者の認証を行う。その後は、ステップＳ１８に移行する。

ステップＳ１８に移行すると、メール処理部１２は、認証に成功したか否かを判断する。ここでの判断が否定された場合には、認証エラー画面（図１０（ｂ））を作成し、クライアント端末２０（表示・送受信部２２）に対して送信し、図７〜図９の全処理を終了する。一方、ステップＳ１８の判断が肯定された場合には、図８のステップＳ２２に移行する。これに対し、クライアント端末２０（表示・送受信部２２）は、ステップＳ１１２において、認証エラー画面を受信したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１１４において認証エラー画面をクライアント端末２０の表示部１９３上（ブラウザ内）に表示し、図７〜図９の全処理を終了する。一方、ステップＳ１１２の判断が否定された場合には、図８のステップＳ１１６に移行する。

一方、メール処理部１２は、図８のステップＳ２２に移行すると、メールＤＢ３２を用いて、利用者ＩＤに対応する受信メールを取得し、受信メール一覧画面を生成する。この場合のメール一覧表示画面は、図１１に示すような画面であるものとする。なお、図１１は、利用者ＩＤがtanaka@xxx.wwである利用者の受信メール一覧画面を示している。次いで、ステップＳ２４では、メール処理部１２が、受信メール一覧画面（図１１）をクライアント端末２０（表示・送受信部２２）に対して送信する。

これに対し、表示・送受信部２２は、ステップＳ１１２の後、ステップＳ１１６において、受信メール一覧画面をメールサーバ１０（メール処理部１２）から受信するまで待機している。したがって、表示・送受信部２２は、メール処理部１２においてステップＳ２４の処理が行われた段階で、ステップＳ１１８に移行する。ステップＳ１１８に移行すると、表示・送受信部２２は、受信メール一覧画面（図１１）をクライアント端末２０の表示部１９３（ブラウザ内）に表示する。

次いで、ステップＳ１２０では、表示・送受信部２２は、受信メール一覧画面上において利用者からのメッセージ選択を受け付ける。なお、利用者は、受信メール一覧画面上に表示されているいずれかのメッセージをマウスでクリックするなどすることで、メッセージ選択を行うことができる。次いで、ステップＳ１２２では、表示・送受信部２２が、メールサーバ１０（メール処理部１２）に対して、選択されたメッセージの閲覧要求を送信する。その後は、表示・送受信部２２は、図９のステップＳ１２４に移行する。

一方、メール処理部１２では、ステップＳ２４の後、ステップＳ２６において、クライアント端末２０からメッセージの閲覧要求を受信するまで待機している。実際の動作としては、図１１の一覧画面からログアウトボタンが押下されることもありえ、その要求をメール処理部１２にて受信したときには、図７〜図９の全処理を終了する動きとなるが、本フローでは発明がわかりやすくなるように、メッセージの閲覧要求を受信するまで待機としている。したがって、上述したように、表示・送受信部２２においてステップＳ１２２が行われた段階で、メール処理部１２は、ステップＳ２８に移行する。

ステップＳ２８に移行すると、メール処理部１２は、メールＤＢ３２から、閲覧要求のあったメッセージのメッセージＩＤに対応するメール本文、発信日時、差出人（送信者）などの情報を取得する。次いで、ステップＳ３０では、メール処理部１２は、取得した差出人の人事情報を、差出人の利用者ＩＤに基づいて人事ＤＢ３６から取得する。例えば、クライアント端末２０の利用者が、差出人の利用者ＩＤがyamada@xxx.wwのメッセージの閲覧要求を出した場合、メール処理部１２は、利用者ＩＤがyamada@xxx.wwである利用者の人事情報（図６の１行目のレコード）を取得する。その後は、メール処理部１２は、図９のステップＳ３４に移行する。

図９のステップＳ３４では、メール処理部１２は、メールＤＢ３２から取得した発信日時が、人事ＤＢ３６から取得した発令日よりも前か否かを判断する。すなわち、閲覧要求の出されたメッセージに挿入されているシグネチャの内容が現在のユーザの属性（人事情報）と異なるか否かを判断する。ここでの判断が否定された場合、すなわち、人事情報が発令した後にメールが発信された場合には、ステップＳ３６に移行する。

ステップＳ３６に移行した場合には、メール処理部１２は、メール本文などを含めたメッセージ表示画面（図１２（ａ）参照）をクライアント端末２０に対して送信する。その後は、ステップＳ３８に移行する。なお、ステップＳ３８に移行すると、メール処理部１２は、クライアント端末２０から、メール一覧表示要求を受信したか否かを判断する。ここでの判断が肯定された場合には、図８のステップＳ２２に戻り、否定された場合には、ステップＳ４０に移行する。また、ステップＳ４０では、メール処理部１２は、クライアント端末２０から、ログアウト要求を受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ３８に戻り、肯定された場合には、図７〜図９の全処理を終了する。

一方、ステップＳ３４の判断が肯定された場合、すなわち、人事情報が発令する前にメールが発信された場合（現在においてシグネチャが過去の人事情報を含んでいる可能性が高い場合）には、メール処理部１２は、ステップＳ４２に移行する。なお、図１１の差出人の利用者ＩＤがyamada@xxx.wwのメッセージの閲覧要求が出された場合には、メールの発信日時が2011/11/30であり、人事情報の発令日が2011/12/01であるので、ステップＳ３４の判断は肯定されることになる。

ステップＳ４２に移行すると、メール処理部１２は、メッセージ表示画面（図１２（ａ））に、「送信者情報変更有」のボタンを付加する（図１２（ｂ）参照）。すなわち、メール処理部１２は、シグネチャの内容が変更されていることを示す情報を付加したメッセージ表示画面を生成する。そして、メール処理部１２は、ステップＳ４４において、メッセージ表示画面（図１２（ｂ））を、クライアント端末２０に対して送信する。その後は、ステップＳ４６に移行する。

これに対し、クライアント端末２０（表示・送受信部２２）では、図８のステップＳ１２２の後、図９のステップＳ１２４においてメッセージ表示画面を受信するまで待機している。したがって、表示・送受信部２２は、メール処理部１２においてステップＳ３６又はステップＳ４４の処理が行われた段階で、ステップＳ１２６に移行することになる。

ステップＳ１２６に移行すると、表示・送受信部２２は、受信したメッセージ表示画面をクライアント端末２０の表示部１９３（ブラウザ内）に表示する。なお、ステップＳ１２６において表示される画面が図１２（ｂ）のような画面（「送信者情報変更有」ボタンが付加された画面）であった場合には、利用者は、シグネチャに変更があったことを認識することができる。これにより、利用者がシグネチャに記載されている誤った（変更前の）連絡先に連絡をとってしまうような事態の発生を抑制することが可能となる。

次いで、ステップＳ１２８では、表示・送受信部２２は、送信者連絡先情報の表示要求を受け付けたか否かを判断する。なお、利用者は、図１２（ｂ）に示す画面の「送信者連絡先変更有」ボタンを押すことにより、送信者連絡先情報の表示要求を出すことができる。なお、クライアント端末２０に図１２（ａ）のメッセージ表示画面が表示されている場合には、そのメールの送信時以降、送信者の連絡先が変更されていないことを示すため、利用者は、送信者連絡先情報の表示要求を出す必要がない。

利用者が、図１２（ｂ）の「送信者連絡先変更有」ボタンを押した場合、ステップＳ１２８の判断が肯定されてステップＳ１３０に移行し、押していない場合には、ステップＳ１２８の判断が否定されてステップＳ１３６に移行する。

ステップＳ１２８の判断が肯定されて、ステップＳ１３０に移行すると、表示・送受信部２２は、メールサーバ１０に、送信者連絡先情報の表示要求を送信する。その後は、ステップＳ１３２に移行する。

これに対し、メール処理部１２では、ステップＳ４４の後、ステップＳ４６において、クライアント端末２０から、送信者連絡先情報の表示要求を受信したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ４８に移行し、人事ＤＢ３６から、連絡先情報を取得し、クライアント端末２０に対して送信する。その後は、ステップＳ５０に移行する。一方、ステップＳ４６の判断が否定された場合には、ステップＳ４８を経ずに、ステップＳ５０に直接移行する。

一方、クライアント端末２０側では、表示・送受信部２２が、ステップＳ１３０の処理の後、ステップＳ１３２において、連絡先情報を受け付けるまで待機している。したがって、表示・送受信部２２は、メール処理部１２においてステップＳ４８の処理が行われた段階で、ステップＳ１３４に移行する。そして、ステップＳ１３４では、表示・送受信部２２は、連絡先情報を画面に表示する。この場合、表示・送受信部２２は、図１３に示すような最新の連絡先情報のポップアップ画面を表示する。このように、過去に受信したメールのシグネチャの内容が変更された場合に、新たな連絡先をポップアップ画面にて表示することで、利用者が誤った連絡先に対して連絡をとるのを抑制することが可能となる。

なお、メール処理部１２は、ステップＳ５０に移行した場合には、クライアント端末２０から、メール一覧表示要求を受信したか否かを判断する。ここでの判断が肯定された場合には、図８のステップＳ２２に戻り、否定された場合には、ステップＳ５２に移行する。また、ステップＳ５２では、メール処理部１２は、クライアント端末２０からログアウト要求を受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ５０に戻り、肯定された場合には、図７〜図９の全処理を終了する。

一方、クライアント端末２０（表示・送受信部２２）では、ステップＳ１２８の判断が否定された場合、又はステップＳ１３４の処理が行われた場合には、ステップＳ１３６に移行する。ステップＳ１３６では、表示・送受信部２２が、メール一覧表示要求を再度受け付けたか否かを判断する。ここでの判断が肯定された場合には、表示・送受信部２２は、ステップＳ１３８において、メールサーバ１０に対してメール一覧表示要求を送信し、その後、図８のステップＳ１１６に戻る。なお、表示・送受信部２２が、ステップＳ１３８の処理を行った場合には、メール処理部１２側では、前述したステップＳ３８又はステップＳ５０の判断が肯定されることになる。

一方、ステップＳ１３６の判断が否定された場合には、ステップＳ１４０に移行する。ステップＳ１４０では、利用者からログアウト要求があったか否かを判断する。ここでの判断が否定された場合には、ステップＳ１２８に戻るが、肯定された場合には、ステップＳ１４２に移行する。そして、ステップＳ１４２に移行した場合には、表示・送受信部２２は、ログアウト要求をメールサーバ１０に対して送信し、図７〜図９の全処理を終了する。なお、ステップＳ１４２の処理が行われた場合には、メール処理部１２側では、前述したステップＳ４０又はステップＳ５２の判断が肯定されることになる。

なお、上記処理の途中であっても、利用者が図１１の受信メール一覧画面や、図１２（ａ）、図１２（ｂ）中の「新規作成」ボタンや「差出人に返信」ボタンを押す場合がある。このような場合には、メール処理部１２や表示・送受信部２２は、通常行われるメール作成のための処理を実行すればよい。

以上、詳細に説明したように、本第１の実施形態によると、メールサーバ１０は、メール本文、差出人、発信日時を含む受信メールの情報を格納するメールＤＢ３２と、人事情報を格納する人事ＤＢ３６とを有し、メール処理部１２は、利用者からメッセージを指定したメッセージ閲覧要求を受信したときに、人事ＤＢ３６のうち指定されたメッセージの差出人の人事情報の発令日と、メッセージの発信日時と、を参照して、メッセージ本文に含まれるシグネチャの内容が現在のユーザの人事情報と異なるか否かを判断する（Ｓ３４）。そして、判断の結果、シグネチャの内容が現在のユーザの人事情報と異なると判断された場合に、メール処理部１２は、「送信者連絡先変更有」ボタンを付加したメッセージ画面（図１２（ｂ））を生成する（Ｓ４２）。これにより、シグネチャの内容が事後的に変更されたことを「送信者連絡先変更有」ボタンによって利用者に通知することができるので、利用者が誤って過去の連絡先に対して連絡をとるなどすることを抑制することができる。

なお、上記実施形態では、人事情報の発令日と、現在の日時との比較は行っていないが、例えば、人事情報の発令日が現在の日時よりも後である場合には、「送信者連絡先変更有」ボタンを付加しないようにすることが好ましい。人事情報が発令していないため、シグネチャの内容は未だ変更されていないといえるからである。

なお、上記実施形態では、会社における人事ＤＢ３６を用意しておき、これに基づいて、シグネチャの内容が変更されたか否かを判断する場合について説明したが、これに限られるものではない。例えば、メールサーバ１０を利用するユーザ（会社内外を問わない）の属性情報（例えば、住所や電話番号）を属性ＤＢ等で管理しておき、当該属性情報が変更された日（変更の効力が発生する日）に基づいて、受信メール（メッセージ）に含まれるシグネチャの内容が変更されたか否かを判断するようにしてもよい。

なお、上記第１の実施形態では、人事情報の発令日と、メールの送信日時との比較により、メール本文に含まれるシグネチャの情報が現在の人事情報と異なっているかを判断する場合について説明した。しかしながら、これに限られるものではなく、その他の方法により、メール本文に含まれるシグネチャの情報が現在の人事情報と異なっているかを判断することもできる。以下に説明する第２の実施形態は、当該その他の方法の一例に関するものである。

《第２の実施形態》
次に、第２の実施形態に係る電子メールシステムについて、図１４〜図１７に基づいて、詳細に説明する。なお、第２の実施形態に係る電子メールシステムの全体構成は、図１と同様となっているが、図１４に示すように、メールサーバ１０が第２格納部としてのシグネチャＤＢ３８を有している点が第１の実施形態と異なっている。また、これに伴い、メール処理部１２の処理の詳細についても、第１の実施形態と異なっている。

シグネチャＤＢ３８は、図１５に示すようなデータ構造を有している。具体的には、シグネチャＤＢ３８には、利用者の利用者ＩＤと、当該利用者のシグネチャ情報（利用者の属性に関する情報を含む）とが格納されている。なお、シグネチャＤＢ３８は、各利用者が所定の登録画面上から登録するものとする。また、メール処理部１２は、利用者がメールを作成する際には、シグネチャＤＢ３８を参照して、メール作成画面に利用者のシグネチャを自動的に挿入するものとする。

次に、メール処理部１２の処理について、図１６、図１７のフローチャートに基づいて詳細に説明する。本第２の実施形態のメール処理部１２の処理は、第１の実施形態の図７の処理と同様の処理を行った後、図１６、図１７の処理を実行する。なお、図１６、図１７のフローチャートでは、図８、図９の処理と異なる処理を太線にて示している。

図１６のメール処理部１２の処理のステップＳ２２〜Ｓ３０は、上記第１の実施形態と同様である。すなわち、ここまでの処理では、利用者がメッセージの閲覧要求を出したときに、メール処理部１２がメールＤＢ３２からメッセージの内容を取得するとともに（ステップＳ２８）、人事ＤＢ３６から差出人の人事情報を取得していることになる（ステップＳ３０）。

ステップＳ３０の後は、ステップＳ２００に移行し、メール処理部１２は、利用者ＩＤに対応するシグネチャ情報をシグネチャＤＢ３８から取得する。例えば、閲覧要求が出されたメッセージの差出人の利用者ＩＤがyamada@xxx.wwであった場合には、図１５の１行目のシグネチャ情報を取得する。

次いで、ステップＳ２０２では、メール処理部１２は、取得したシグネチャの行数を取得する。上記例の場合、行数として３行を取得する。

次いで、ステップＳ２０４では、メール処理部１２は、メール本文の末端から、取得した行数分の文字列を取得する。この場合、図１２（ａ）の末端の３行が取得されることになる。

次いで、図１７のステップＳ２０６に移行すると、メール処理部１２は、ステップＳ２０４で取得した文字列と、ステップＳ２００で取得したシグネチャ情報と、が一致するか否かを判断する。なお、このステップＳ２０６では、第１の実施形態と同様、メールを発信した時点と現在とで、差出人の属性情報（連絡先など）が変更されたか否かを判断しているといえる。ここでの判断が肯定された場合には、ステップＳ３６に移行し、否定された場合には、ステップＳ４２に移行する。なお、以降の処理は、第１の実施形態と同様となっている。

なお、クライアント端末２０（表示・送受信部２２）の処理については、第１の実施形態と同様となっている。

以上説明したように、本第２の実施形態では、メールサーバ１０は、メールＤＢ３２と、各利用者の属性を含むシグネチャ情報を格納するシグネチャＤＢ３８とを有し、メール処理部１２は、利用者からメッセージを指定したメッセージ閲覧要求を受信したときに、シグネチャＤＢ３８のシグネチャ情報と、メール本文に付加されているシグネチャとが同一か否かに基づいてシグネチャの内容が現在のユーザの属性情報と異なるか否かを判断し（Ｓ２０６）、判断の結果、シグネチャの内容が現在のユーザの属性情報と異なると判断された場合に、「送信者連絡先変更有」ボタンを付加したメッセージ画面を生成する（Ｓ４２）。これにより、本第２の実施形態では、上記第１の実施形態と同様、シグネチャの内容が事後的に変更されたことを「送信者連絡先変更有」ボタンによって利用者に通知することができるので、利用者が誤って過去の連絡先に対して連絡をとるなどすることを抑制することができる。

また、本第２の実施形態では、メッセージのどの部分がシグネチャであるかを判別することもできるので、シグネチャ近傍に「送信者連絡先変更有」ボタンを付加することが可能となる。これにより、利用者による「送信者連絡先変更有」ボタンの見落としを抑制することができる。

なお、上記第２の実施形態では、メールサーバ１０が人事ＤＢ３６を有していなくてもよい。この場合、利用者が図１２（ｂ）の画面上において「送信者連絡先変更有」ボタンを押した場合には、シグネチャＤＢ３８に格納されている変更後のシグネチャ情報をポップアップ表示するなどすればよい。

なお、上記第１、第２の実施形態では、メールサーバを用いた電子メールシステムについて説明したが、これに限らず、メールクライアントを用いた電子メールシステムでも上記第１，第２の実施形態と同様の処理を行うことができる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact
Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１） メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部に格納されている受信メール情報のいずれかを指定したユーザからの表示要求を受信する受信工程と、
各ユーザの属性に関する情報を格納する第２格納部と、前記指定された受信メール情報と、を参照して、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なるか否かを判断する判断工程と、
前記判断工程の結果、前記署名データの内容が現在のユーザの属性に関する情報と異なると判断された場合に、当該判断結果を付加して、前記指定された受信メール情報を表示する画面を生成する生成工程と、をコンピュータが実行することを特徴とする受信メール情報提供方法。
（付記２） 前記第２格納部は、前記ユーザの属性に関する情報と、当該情報の効力発生日時と、を格納しており、
前記判断工程では、前記指定された受信メール情報に含まれる発信日時と、前記第２格納部に格納されている、前記指定された受信メールの発信先のユーザの属性に関する情報の効力発生日時と、を比較して、前記効力発生日時のほうが後であった場合に、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なると判断することを特徴とする付記１に記載の受信メール情報提供方法。
（付記３） 前記第２格納部は、前記ユーザの署名データを格納しており、
前記判断工程では、前記指定された受信メールのメール本文に挿入されている署名データと、前記第２格納部に格納されている前記指定された受信メールの発信先のユーザの署名データと、を比較して、両者が異なっていた場合に、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なると判断することを特徴とする付記１に記載の受信メール情報提供方法。
（付記４） メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部と、
各ユーザの属性に関する情報を格納する第２格納部と、
ユーザから前記第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信したときに、前記第２格納部と、前記指定された受信メール情報と、を参照して、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なるか否かを判断する判断部と、
前記判断部による判断の結果、前記署名データの内容が現在のユーザの属性に関する情報と異なると判断された場合に、当該判断結果を付加して、前記指定された受信メール情報を表示する画面を生成する生成部と、を備えるメール装置。
（付記５） 前記第２格納部は、前記ユーザの属性に関する情報と、当該情報の効力発生日時と、を格納しており、
前記判断部は、前記指定された受信メール情報に含まれる発信日時と、前記第２格納部に格納されている、前記指定された受信メールの発信先のユーザの属性に関する情報の効力発生日時と、を比較して、前記効力発生日時のほうが後であった場合に、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なると判断することを特徴とする付記４に記載のメール装置。
（付記６） 前記第２格納部は、前記ユーザの署名データを格納しており、
前記判断部は、前記指定された受信メールのメール本文に挿入されている署名データと、前記第２格納部に格納されている前記指定された受信メールの発信先のユーザの署名データと、を比較して、両者が異なっていた場合に、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なると判断することを特徴とする付記４に記載のメール装置。
（付記７） メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部に格納されている受信メール情報のいずれかを指定したユーザからの表示要求を受信し、
各ユーザの属性に関する情報を格納する第２格納部と、前記指定された受信メール情報と、を参照して、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なるか否かを判断し、
前記判断する処理における判断の結果、前記署名データの内容が現在のユーザの属性に関する情報と異なると判断された場合に、当該判断結果を付加して、前記指定された受信メール情報を表示する画面を生成する、処理をコンピュータに実行させることを特徴とするメールプログラム。
（付記８） 前記第２格納部は、前記ユーザの属性に関する情報と、当該情報の効力発生日時と、を格納しており、
前記判断する処理では、前記指定された受信メール情報に含まれる発信日時と、前記第２格納部に格納されている、前記指定された受信メールの発信先のユーザの属性に関する情報の効力発生日時と、を比較して、前記効力発生日時のほうが後であった場合に、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なると判断することを特徴とする付記７に記載のメールプログラム。
（付記９） 前記第２格納部は、前記ユーザの署名データを格納しており、
前記判断する処理では、前記指定された受信メールのメール本文に挿入されている署名データと、前記第２格納部に格納されている前記指定された受信メールの発信先のユーザの署名データと、を比較して、両者が異なっていた場合に、前記指定された受信メールのメール本文に挿入された署名データの内容が現在のユーザの属性に関する情報と異なると判断することを特徴とする付記７に記載のメールプログラム。

１０ メールサーバ（メール装置）
１２ メール処理部（判断部、生成部）
３２ メールＤＢ（第１格納部）
３６ 人事ＤＢ（第２格納部）
３８ シグネチャＤＢ（第２格納部）

Claims (5)

1. メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信する受信工程と、
   各ユーザの属性に関する情報を格納する第２格納部と、指定された前記受信メール情報と、を参照して、指定された前記受信メール情報のメール本文に挿入された署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なるか否かを判断する判断工程と、
   前記判断工程の結果、前記署名データの内容が指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断された場合に、該判断結果を付加して、指定された前記受信メール情報を表示する画面を生成する生成工程と、をコンピュータが実行することを特徴とする受信メール情報提供方法。
2. 前記第２格納部は、前記ユーザの属性に関する情報と、当該情報の効力発生日時と、を格納しており、
   前記判断工程では、指定された前記受信メール情報に含まれる発信日時と、前記第２格納部に格納されている、指定された前記受信メール情報の発信先のユーザの属性に関する情報の効力発生日時と、を比較して、前記効力発生日時のほうが後であった場合に、指定された前記受信メール情報のメール本文に挿入された署名データの内容が指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断することを特徴とする請求項１に記載の受信メール情報提供方法。
3. 前記第２格納部は、前記ユーザの署名データを格納しており、
   前記判断工程では、指定された前記受信メール情報のメール本文に挿入されている署名データと、前記第２格納部に格納されている指定された前記受信メール情報の発信先のユーザの署名データと、を比較して、両者が異なっていた場合に、指定された前記受信メール情報のメール本文に挿入された署名データの内容が指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断することを特徴とする請求項１に記載の受信メール情報提供方法。
4. メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部と、
   各ユーザの属性に関する情報を格納する第２格納部と、
   前記第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信したときに、前記第２格納部と、指定された前記受信メール情報と、を参照して、指定された前記受信メール情報のメール本文に挿入された署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なるか否かを判断する判断部と、
   前記判断部による判断の結果、前記署名データの内容が指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断された場合に、該判断結果を付加して、指定された前記受信メール情報を表示する画面を生成する生成部と、を備えるメール装置。
5. メール本文、発信先、発信日時を含む受信メール情報を格納する第１格納部に格納されている受信メール情報のいずれかを指定した表示要求を受信し、
   各ユーザの属性に関する情報を格納する第２格納部と、指定された前記受信メール情報と、を参照して、指定された前記受信メール情報のメール本文に挿入された署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なるか否かを判断し、
   前記判断する処理における判断の結果、前記署名データの内容が、指定された前記受信メール情報の発信先のユーザの属性に関する情報と異なると判断された場合に、該判断結果を付加して、指定された前記受信メール情報を表示する画面を生成する、処理をコンピュータに実行させることを特徴とするメールプログラム。

Images