JP2013149100A - 電子メール情報送信プログラム、電子メール情報送信方法及び電子メール情報送信装置 - Google Patents

Abstract

【課題】電子メールの宛先確認を支援する情報を送信する
【解決手段】メール処理部１２は、承認者による電子メールを指定した承認要求及び職制役職表示要求を受け付けた場合に、人事ＤＢ３６を参照して、承認者によって指定された電子メールに含まれる宛先に対応する職制役職及び氏名を取得する。また、メール処理部１２は、職制役職情報を、電子メールの本文とともに、承認者が使用するクライアント端末２０（表示・送受信部２２）に対して送信する。
【選択図】図３

Description

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

従来、電子メールの作成を支援したり、電子メールの詳細な情報を提供することを目的とした様々な技術が知られている。

例えば、電子メールを作成し、当該電子メールを送信する者（以下、送信者とする）が、誤った宛先を指定することを防ぐために、職制情報の樹形図を表示し、当該樹形図から宛先とするユーザを指定する技術が知られている（例えば、特許文献１参照）。また、メーリングリスト宛に発信されたメールの受信者に対して、メーリングリストに登録されたメンバを表示することで、自分以外にメールを受け取った人を知らせる技術が知られている（例えば、特許文献２参照）。

特開平５−２０４７９５号公報 特開平１１−２４８８０号公報

ところで、送信者が作成した電子メールを他のユーザが閲覧した場合に、当該電子メールの宛先に指定されたユーザの情報を確認しなければならない場合がある。

例えば、送信者が関係者外秘の内容が含まれたメールを発信する前に上司承認を得る必要がある場合には、上司は、メールの宛先に関係者以外の人が含まれていないかをチェックする必要がある。また、例えば、宛先が複数であるメール（同報メール）を受信した受信者が、送信者及び宛先の複数又は全員に返信メールを出す場合、返信メールが送信される先（宛先）に関係者以外の人が宛先に含まれていないかをチェックする必要がある。

すなわち、上述した上司や受信者などにとって、メールの宛先に含まれる人物の情報を把握することは、情報漏洩などの観点からすると非常に重要である。

しかしながら、特許文献１の技術では、送信者が宛先を指定する際に誤った宛先を指定してしまうのを防ぐことができるものの、送信者とは異なる者（実際の送信を承認する上司、あるいは、受信者など）が、宛先の人物の情報を把握することは難しい。また、特許文献２では、上司承認や同報メールの受信者による宛先チェックなどにおいて利用することが想定されていない。このため、特許文献２において表示されるメーリングリストのグループ構成員のメッセージアドレスを示す文字列のみでは、上司承認や返信メールの宛先チェックなどにおける有用な情報とはなりにくい。

そこで本件は上記の課題に鑑みてなされたものであり、電子メールの宛先確認を支援する情報を送信することが可能な電子メール情報送信プログラム、電子メール情報送信方法及び電子メール情報送信装置を提供することを目的とする。

本明細書に記載の電子メール情報送信プログラムは、メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付け、第２のユーザによる前記電子メール情報を指定した要求を受け付け、宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出し、前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する、処理をコンピュータに実行させる電子メール情報送信プログラムである。

本明細書に記載の電子メール情報送信方法は、メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付ける情報受け付け工程と、第２のユーザによる前記電子メール情報を指定した要求を受け付ける要求受け付け工程と、宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出する抽出工程と、前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する送信工程と、をコンピュータが実行する電子メール情報送信方法である。

本明細書に記載の電子メール情報送信装置は、メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付ける情報受け付け部と、第２のユーザによる前記電子メール情報を指定した要求を受け付ける要求受け付け部と、宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部と、前記記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出する抽出部と、前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する送信部と、を備えている。

本明細書に記載の電子メール情報送信プログラム、電子メール情報送信方法及び電子メール情報送信装置は、電子メールの宛先確認を支援する情報を送信することができるという効果を奏する。

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

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

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

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

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

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

メール処理部１２は、ＷＥＢメールの画面作成や、クライアント端末２０に対する画面の送信、ＷＥＢメールの送受信処理などを行う。また、メール処理部１２は、クライアント端末２０の利用者からの指示に応じて、電子メールの宛先の情報（職制役職などの人事情報を含む）をクライアント端末２０に対して提供する。

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

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

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

人事ＤＢ３６は、図５（ｂ）に示すように、「利用者ＩＤ」、「所属部」、「役職」、「氏名」、「承認者アドレス」の各フィールドを有している。「所属部」、「役職」の各フィールドには、利用者ＩＤに対応する人物の所属部、職制役職が入力される。また、「氏名」のフィールドには、利用者ＩＤに対応する人物の氏名が入力される。また、「承認者アドレス」のフィールドには、利用者ＩＤに対応する人物の上司（利用者が電子メールを送信する際に、承認を行う人物）の電子メールアドレスが入力される。なお、人事ＤＢ３６は、予め管理者等により作成されるものとし、変更があった場合には管理者等によって適宜更新されるものとする。

承認メールＤＢ３８は、承認が必要な電子メール（図５（ｂ）の人事ＤＢ３６において承認者アドレスが入力されている利用者が送信しようとしている電子メール、以下「承認メール」と呼ぶ）を格納するデータベースである。承認メールＤＢ３８は、承認者ごとに作成される。なお、図６には、一例として、承認者「山田一郎」（利用者ＩＤ「yamada@xxx.ww」）の承認メールＤＢ３８が図示されている。承認メールＤＢ３８は、図６に示すように、「利用者ＩＤ」、「メッセージＩＤ」、「宛先」、「メール情報（件名、本文）」の各フィールドを有している。「利用者ＩＤ」には、電子メール（承認メール）を送信しようとしている利用者（承認者の部下）のＩＤが入力され、「宛先」のフィールドには、承認メールにおいて指定された宛先が入力される。なお、その他のフィールドについては、図４のメールＤＢ３２と同様となっている。

次に、本実施形態におけるメール処理部１２と、表示・送受信部２２の処理について、図７〜図２０に基づいて詳細に説明する。

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

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

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

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

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

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

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

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

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

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

ステップＳ２２では、メール処理部１２が、メールＤＢ３２を用いて、利用者ＩＤに対応するメール表示画面を作成する。この場合のメール表示画面は、図１２に示すような画面であるものとする。次いで、ステップＳ２４では、メール処理部１２が、利用者ＩＤのメール表示画面（図１２）をクライアント端末２０（表示・送受信部２２）に対して送信する。その後は、図９のステップＳ２６に移行する。

一方、表示・送受信部２２では、認証エラー画面をメールサーバ１０（メール処理部１２）から受信するまで、又は、メール表示画面をメールサーバ１０（メール処理部１２）から受信するまで待機している（Ｓ１２４、Ｓ１２８）。したがって、表示・送受信部２２は、メール処理部１２から認証エラー画面を受信した場合には、ステップＳ１２４の判断が肯定されることにより、ステップＳ１２６に移行する。ステップＳ１２６に移行した場合には、表示・送受信部２２は、表示部１９３上に認証エラー画面（図１１）を表示した後、図７〜図９の全処理を終了する。

また、表示・送受信部２２が、メール処理部１２から認証エラー画面を受信せずに、メール表示画面（図１２）を受信した場合には、ステップＳ１２８の判断が肯定され、ステップＳ１３０に移行する。ステップＳ１３０に移行すると、表示・送受信部２２は、メール表示画面（図１２）をクライアント端末２０の表示部１９３（ブラウザ内）に表示する。その後は、図９のステップＳ１３２に移行する。

表示・送受信部２２は、図９のステップＳ１３２に移行すると、利用者（第１のユーザとしての電子メールの差出人）からメッセージ作成要求を受け付けたか否かを判断する。この場合、利用者は、メール表示画面上で、「新規作成」、「差出人に返信」、「全員に返信」のいずれかのボタンを押すことで、メッセージ作成要求を出すことができる。ステップＳ１３２の判断が否定された場合には、ステップＳ１３８に移行する。一方、ステップＳ１３２の判断が肯定された場合には、ステップＳ１３４に移行する。

ステップＳ１３４では、表示・送受信部２２が、メールサーバ１０のメール処理部１２に対して、メッセージ作成要求を送信する。その後は、ステップＳ１３６の送信処理サブルーチン（図１３）に移行する。

これに対し、メール処理部１２では、ステップＳ２６において、クライアント端末２０（表示・送受信部２２）からメッセージ作成要求を受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ３６に移行するが、ここでの判断が肯定された場合には、ステップＳ２８に移行する。なお、ステップＳ２８に移行する場合とは、表示・送受信部２２においてステップＳ１３４の処理が行われた場合を意味する。

ステップＳ２８に移行すると、メール処理部１２は、メッセージ作成画面を生成し、当該メッセージ作成画面をクライアント端末２０（表示・送受信部２２）に対して送信する。ここで、メッセージ作成画面は、図１３に示すような画面であるものとする。なお、メール処理部１２は、メッセージ作成要求が、「新規作成」であった場合には、図１３の画面をそのまま送信し、「差出人に返信」であった場合には、メールＤＢ３２から返信元の電子メールの発信者アドレス（利用者ＩＤ）、件名、本文を取得する。そして、図１３のメッセージ作成画面の宛先の欄に取得した発信者のアドレスを表示するとともに、件名及び記事入力画面の欄に取得した件名と、取得した本文を引用文（「Re:」を付した件名や「>」を付した本文）として表示した画面を送信する。また、メール処理部１２は、メッセージ作成要求が「全員返信」であった場合には、メールＤＢ３２から返信元の電子メールの発信者アドレス（利用者ＩＤ）および宛先、件名、本文を取得する。そして、図１３のメッセージ作成画面の宛先の欄に取得した発信者のアドレスおよび自らを抜いた宛先を表示するとともに、件名及び記事入力画面の欄に取得した件名と、取得した本文を引用文（「Re:」を付した件名や「>」を付した本文）として表示した画面を送信する。

ここで、表示・送受信部２２で行われる送信処理（ステップＳ１３６）について、詳細に説明する。図１４には、送信処理の詳細な処理がフローチャートにて示されている。

図１４の処理では、ステップＳ１５０において、表示・送受信部２２が、メッセージ作成画面をメールサーバ１０（メール処理部１２）から受信するまで待機する。この場合、前述した図７のステップＳ２８においてメール処理部１２からメッセージ作成画面（図１４）が送信されてきた段階で、ステップＳ１５２に移行することになる。

ステップＳ１５２に移行すると、表示・送受信部２２は、メール処理部１２から受信した図１３のメッセージ作成画面を表示部１９３（ブラウザ内）に表示する。

次いで、ステップＳ１５４では、表示・送受信部２２が、利用者による、宛先、件名、本文の入力を受け付ける。次いで、ステップＳ１５６では、表示・送受信部２２が、メッセージ送信要求を受け付けるまで待機する。この場合、表示・送受信部２２は、利用者によって図１３の画面中の送信ボタンが押された場合に、メッセージ送信要求を受け付けることになる。そして、表示・送受信部２２は、利用者からのメッセージ送信要求を受け付けると、ステップＳ１５８に移行し、宛先、件名、本文をメールサーバ１０（メール処理部１２）に送信する。なお、ステップＳ１５８の送信時には、送信ボタンを押した利用者の利用者ＩＤ（発信者ＩＤ）も送信される。その後は、図９のステップＳ１３８に移行する。

これに対し、メール処理部１２では、ステップＳ２８の後、ステップＳ３０において、クライアント端末２０の表示・送受信部２２から宛先、件名、メール本文情報としての本文、発信者ＩＤを受信するまで待機している。したがって、メール処理部１２は、上述した図１４のステップＳ１５８の処理が行われたタイミングで、ステップＳ３２に移行することになる。なお、ステップＳ３０は、本文と、差出人である利用者（第１のユーザ）により指定された宛先とを含む電子メール情報を受け付ける処理であるといえる。すなわち、メール処理部１２は、情報受け付け部としての機能を有する。

ステップＳ３２に移行すると、メール処理部１２は、人事ＤＢ３６（図５（ｂ））を参照して、発信者ＩＤに対応する承認者のアドレス（承認者アドレス）を取得する。例えば、発信者ＩＤが「tanaka@xxx.ww」であった場合には、承認者アドレスとして「yamada@xxx.ww」が取得されることになる。なお、本実施例では、発信者に対応する承認者を第２のユーザとしているが、第２のユーザは承認者に限られるものではない。

次いで、ステップＳ３４では、メール処理部１２が、メッセージＩＤ、ヘッダを生成し、ヘッダ、件名、本文を、承認者に対応する承認メールＤＢ３８に記録する。この場合、例えば、図６（承認者「山田一郎」の承認メールＤＢ３８）に、利用者ＩＤ「tanaka@xxx.ww」の送信しようとしているメールが記録されることになる。

一方、表示・送受信部２２は、ステップＳ１３２が否定された後（メッセージ作成要求を受け付けなかった場合）、又はステップＳ１３６（送信処理）が終了した後、ステップＳ１３８に移行する。ステップＳ１３８では、表示・送受信部２２が、承認要求（承認画面表示）を受け付けたか否かを判断する。この場合、図１２のメール表示画面において、利用者（第２のユーザとしての承認者）が「承認画面表示」ボタンを押した場合に、ステップＳ１３８の判断が肯定されることになる。ステップＳ１３８の判断が肯定された場合には、ステップＳ１４０に移行し、承認要求をメールサーバ１０（メール処理部１２）に対して送信する。その後は、ステップＳ１４２（承認処理）に移行する。一方、ステップＳ１３８の判断が否定された場合には、ステップＳ１４４に移行する。

これに対し、メール処理部１２では、ステップＳ３６において、承認要求を受け付けたか否かを判断する。ここでの判断が肯定された場合（表示・送受信部２２においてステップＳ１４０の処理が行われた場合）には、ステップＳ３８（承認処理）に移行する。一方、ステップＳ３６の判断が否定された場合には、ステップＳ４０に移行する。

ここで、メール処理部１２及び表示・送受信部２２で行われる承認処理（Ｓ３８及びＳ１４２）について、図１５〜図１７のフローチャートに沿って詳細に説明する。

図１５の処理では、まず、メール処理部１２が、ステップＳ５０において、承認メールＤＢ３８を用いて、承認要求一覧画面を生成する。より具体的には、メール処理部１２は、図６の承認メールＤＢ３８から差出人や件名の情報を取得して、図１８に示す承認要求一覧画面を生成する。次いで、ステップＳ５２では、メール処理部１２は、クライアント端末２０（表示・送受信部２２）に対して、図１８の承認要求一覧画面を送信する。

一方、表示・送受信部２２は、図１５の処理開始後、ステップＳ１６０において、承認要求一覧画面を受信するまで待機している。したがって、表示・送受信部２２では、メール処理部１２において前述したステップＳ５２の処理が行われた段階で、ステップＳ１６２に移行する。

ステップＳ１６２に移行すると、表示・送受信部２２は、承認要求一覧画面（図１８）を表示部１９３（ブラウザ内）に表示する。次いで、ステップＳ１６４では、表示・送受信部２２は、利用者（承認者）によって承認要求一覧画面の中から承認したい電子メールが選択されたか否かを判断する。なお、利用者（承認者）は、図１８の電子メールの中から承認したい電子メールの先頭のチェックボックスにチェックを入れた後、「承認確認」ボタンを押すことで、電子メールの選択を行うことができる。

利用者（承認者）によって電子メールが選択されることにより、ステップＳ１６４の判断が肯定されると、ステップＳ１６６に移行する。ステップＳ１６６では、表示・送受信部２２が、メールサーバ１０（メール処理部１２）に対して、選択したメールの情報を送信する。

これに対し、メール処理部１２は、ステップＳ５２の後、ステップＳ５４において、承認者が選択したメールの情報を受信するまで待機している。したがって、メール処理部１２では、表示・送受信部２２において前述したステップＳ１６６の処理が行われた段階で、ステップＳ５６に移行することになる。

ステップＳ５６に移行すると、メール処理部１２は、承認メールＤＢ３８から、選択された電子メールの本文、宛先、件名を取得する。次いで、ステップＳ５８では、ステップＳ５６で取得した本文、宛先、件名を用いて、図１９に示す承認画面１を作成しクライアント端末（表示・送受信部２２）に送信する。その後は、図１６のステップＳ６０に移行する。なお、図１９に示す承認画面１には、「承認」ボタン及び「却下」ボタンと、差出人、宛先、件名及び本文の情報と、「職制役職表示」ボタンと、が含まれている。なお、宛先の欄には、電子メールの送信者（ここでは、田中二郎）のアドレス帳に氏名等が登録されている宛先については、当該氏名等（例えば、図１９の「黒田さん」）が表示され、それ以外の場合には、メールアドレス（利用者ＩＤ）が表示されることになる。

一方、表示・送受信部２２は、ステップＳ１６６の後、ステップＳ１６８において、承認画面１をメールサーバ１０（メール処理部１２）から受信するまで待機している。したがって、表示・送受信部２２では、メール処理部１２において前述したステップＳ１５８の処理が行われた段階で、ステップＳ１７０に移行することになる。

ステップＳ１７０では、表示・送受信部２２が、受信した承認画面１（図１９）を表示部１９３（ブラウザ内）に表示する。その後は、図１６のステップＳ１７２に移行する。

図１６のステップＳ１７２では、表示・送受信部２２が、承認者から職制役職表示要求を受け付けたか否かを判断する。この場合、承認者は、図１９の承認画面１の「職制役職表示」ボタンを押すことにより、職制役職表示要求を出すことができる。このステップＳ１７２の判断が否定された場合には、ステップＳ１７６に移行する。

ステップＳ１７６に移行した場合、表示・送受信部２２は、承認者によって「承認」ボタンが押されたか否かを判断する。このステップＳ１７６の判断が否定された場合には、表示・送受信部２２は、ステップＳ１７８において、承認者によって「却下」ボタンが押されたか否かを判断する。このステップＳ１７８の判断が否定された場合には、ステップＳ１７２に戻る。すなわち、承認者によって何もボタンが押されていない間は、ステップＳ１７２、Ｓ１７６，Ｓ１７８の判断のループを繰り返すことになる。

一方、承認者によって「職制役職表示」ボタンが押された場合（Ｓ１７２：肯定）には、ステップＳ１７４に移行する。また、承認者によって「承認」ボタンが押された場合（Ｓ１７６：肯定）には、ステップＳ１９２に移行し、承認者によって「却下」ボタンが押された場合（Ｓ１７８：肯定）には、ステップＳ１９４に移行する。

承認者によって「職制役職表示」ボタンが押され、ステップＳ１７４に移行すると、表示・送受信部２２は、メールサーバ１０（メール処理部１２）に対して、職制役職表示要求を送信する。

これに対し、メール処理部１２では、図１５のステップＳ５８の後、ステップＳ６０において、表示・送受信部２２から職制役職表示要求を受信したか否かを判断する。ここでの判断が肯定された場合（すなわち、表示・送受信部２２においてステップＳ１７４の処理が行われた場合）には、ステップＳ６２に移行するが、判断が否定された場合には、図１７のステップＳ６６に移行する。なお、メール処理部１２は、承認者による電子メールを指定した要求（職制役職表示要求）を受け付ける要求受け付け部としての機能を有しているといえる。

ステップＳ６２に移行した場合、メール処理部１２は、人事ＤＢ３６から、各宛先の人物の職制役職及び氏名を取得する。より具体的には、メール処理部１２は、宛先と、当該宛先に該当する人物の職制役職及び氏名とを対応付けて記憶する人事ＤＢ３６を参照して、承認者によって指定された電子メールに含まれる宛先を利用者ＩＤとする所属部、役職、氏名を取得する。すなわち、メール処理部１２は、承認者によって指定された電子メールに含まれる宛先に対応する人事情報を抽出する抽出部としての機能を有しているといえる。

次いで、ステップＳ６４では、メール処理部１２は、取得した職制役職および氏名を用いて、図２０に示す承認画面２を作成しクライアント端末２０（表示・送受信部２２）に対して送信する。なお、図２０の承認画面２は、図１９と比較するとわかるように、宛先のメールアドレスが、職制役職及び氏名に変換された状態となっている。また、メール処理部１２は、各宛先を、職制役職を用いてソートして順番を並べ替えた状態で承認画面２を作成するものとする。なお、人事ＤＢ３６に含まれていない宛先アドレスについては、社外、また、役職不明として、メールアドレスのみを表記させる。すなわち、メール処理部１２は、ステップＳ６４において、電子メールの本文等とともに、ステップＳ６２で抽出した職制役職及び氏名を、承認者が使用するクライアント端末２０に対して送信する送信部としての機能を有しているといえる。なお、承認画面２では、図２０に示すように、承認画面１（図１９）の「職制役職表示」ボタンの位置に「アドレスを元に戻す」ボタンが配置されている。なお、上記ステップＳ６４の処理の後は、図１７のステップＳ６６の処理に移行する。

一方、表示・送受信部２２は、ステップＳ７４の後、ステップＳ１８０において、メール処理部１２から承認画面２を受信するまで待機している。したがって、メール処理部１２において前述したステップＳ６４の処理が行われた段階で、表示・送受信部２２は、ステップＳ１８２に移行することになる。

ステップＳ１８２では、表示・送受信部２２は、承認画面２を表示部１９３（ブラウザ内）に表示する。この場合、承認者は、承認画面２を見ることで、送信者（差出人）がどの所属部のどの役職の誰にメールを出そうとしているかを簡易かつ正確に把握することができる。したがって、承認者は、承認画面２を見ることで、承認するか却下するかを的確に判断することが可能である。なお、承認画面１を最初から表示せずに承認画面２を承認者の求めに応じて表示することとしているのは、宛先が少なくメールアドレスを見れば承認するか否かを簡易に判断できる場合（職制役職及び氏名を表示するまでもない場合）もあるからである。なお、これに限らず、本第１の実施形態では、承認画面１を表示することなく、最初から承認画面２を表示するようにしてもよい。

次いで、ステップＳ１８４では、承認者によって「アドレスを元に戻す」ボタンが押されたか否かを判断する。ここでの判断が肯定された場合、すなわち、承認者によって「アドレスを元に戻す」ボタンが押された場合には、表示・送受信部２２は、ステップＳ１８６において、承認画面１を表示部１９３（ブラウザ内）に表示する。なお、この場合の承認画面１は、表示・送受信部２２がキャッシュに記憶しておいた画面を表示することとすればよい。ただし、これに限らず、図１５のステップＳ５６、Ｓ５８、Ｓ１７０のように、表示・送受信部２２は、メール処理部１２に承認画面１を新たに作成してもらい、当該承認画面１を表示部１９３に表示するようにしてもよい。なお、ステップＳ１８６の後は、ステップＳ１７２に戻る。

一方、ステップＳ１８４の判断が否定された場合には、ステップＳ１８８に移行し、表示・送受信部２２は、承認者によって「承認」ボタンが押されたか否かを判断する。ここでの判断が否定された場合には、表示・送受信部２２は、ステップＳ１９０において、承認者によって「却下」ボタンが押されたか否かを判断する。このステップＳ１９０の判断が否定された場合には、ステップＳ１８４に戻る。すなわち、承認者によって何もボタンが押されていない間は、ステップＳ１８４、Ｓ１８８、Ｓ１９０の判断のループを繰り返すことになる。

これに対し、承認者によって「承認」ボタンが押された場合には、ステップＳ１８８の判断が肯定されてステップＳ１９２に移行する。また、承認者によって「承認」ボタンが押されず、「却下」ボタンが押された場合には、ステップＳ１９０の判断が肯定されてステップＳ１９４に移行する。

ステップＳ１９２に移行した場合（ステップＳ１７６又はＳ１８８で、「承認」ボタンが押された場合）には、表示・送受信部２２は、メール処理部１２に対して、承認者が承認したことを示す情報（承認情報）を送信する。一方、ステップＳ１９４に移行した場合（ステップＳ１７８又はＳ１９０で、「却下」ボタンが押された場合）には、表示・送受信部２２は、メール処理部１２に対して、承認者が却下したことを示す情報「却下情報」を送信する。

上記ステップＳ１９２又はＳ１９４を経た後は、表示・送受信部２２は、承認処理の全処理を終了し、図９のステップＳ１４４に移行する。

これに対し、メール処理部１２では、図１６のステップＳ６４を経て、又はステップＳ６０の判断が肯定された後、図１７のステップＳ６６に移行している。ステップＳ６６では、メール処理部１２は、表示・送受信部２２から承認情報を受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ６８に移行し、メール処理部１２は、表示・送受信部２２から却下情報を受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ６６に戻る。すなわち、メール処理部１２は、承認情報又は却下情報を受信するまで待機し、承認情報を受信した場合（Ｓ６６：肯定）には、ステップＳ７０に移行する。一方、メール処理部１２は、却下情報を受信した場合（Ｓ６８：肯定）には、ステップＳ７４に移行する。

ステップＳ７０に移行した場合、メール処理部１２は、メッセージＩＤ、ヘッダを生成し、ヘッダ、件名、本文を宛先（フォルダ）に送信する。また、メール処理部１２は、次のステップＳ７２において、メールＤＢ３２の種別を「送信」として、利用者ＩＤ、メッセージＩＤ、件名、本文を記録する。一方、ステップＳ７４に移行した場合には、メール処理部１２は、却下通知をメッセージ作成元（電子メールを作成して送信しようとしていた利用者）のクライアント端末２０に対して通知する。

以上のようにして、メール処理部１２の承認処理が終了すると、図９のステップＳ４０に移行する。

図９に戻り、ステップＳ１４４では、表示・送受信部２２が、利用者によってログアウト要求が出されたか否か（図１２の「ログアウト」ボタンが押されたか否か）を判断する。ここでの判断が否定された場合には、ステップＳ１３２に戻る。一方、ステップＳ１４４の判断が肯定された場合、すなわち、利用者によってログアウト要求が出された場合には、ステップＳ１４６に移行する。そして、ステップＳ１４６では、表示・送受信部２２は、ログアウト要求をメールサーバ１０（メール処理部１２）に対して送信し、図７〜図９の一連の処理を終了する。

これに対し、メール処理部１２では、ステップＳ４０において、ログアウト要求をクライアント端末２０（表示・送受信部２２）から受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ２６に戻るが、ステップＳ４０の判断が肯定された場合、すなわち、表示・送受信部２２でステップＳ１４６の処理が行われた場合には、図７〜図９の一連の処理を終了する。

以上のように、図７〜図９の一連の処理を行うことで、利用者が電子メールを作成して送信したり、承認者が電子メールの承認を行ったりすることができる。また、承認者は、承認画面１において職制役職表示ボタンを押すことにより、職制役職及び氏名が表示された承認画面２を用いた承認を行うことができる。

以上、詳細に説明したように、本第１の実施形態によると、メール処理部１２は、承認者による職制役職表示要求を受け付けた場合に、人事ＤＢ３６を参照して、電子メールに含まれる宛先に対応する職制役職および氏名を取得する。そして、メール処理部１２は、職制役職および氏名の情報を、電子メールの本文とともに、承認者が使用するクライアント端末２０（表示・送受信部２２）に対して送信する。このように、本第１の実施形態では、承認者の利用するクライアント端末２０に対して、電子メールの宛先確認を支援する情報を送信することができるので、承認者は、部下等が作成した電子メールの承認を行う際に、電子メールの宛先がどの所属部のどの役職の誰であるかを簡易かつ正確に把握することができるようになる。したがって、承認者は、電子メールの承認するか却下するかを的確に判断することができるようになるので、電子メールの誤送信等による情報漏洩の発生を抑制することが可能となる。

なお、上記第１の実施形態では、電子メールの送信処理と、承認処理とを同一のフローチャート内で実行する場合について説明したが、これに限らず、送信処理と承認処理を別々のフローチャートにおいて実行するようにしてもよい。

なお、上記第１の実施形態では、社内の職制役職を表示する場合について説明したが、社外のメールアドレスが宛先に入っていた場合には、職制役職として「社外」などの表示を行うこととすればよい。また、ドメイン名などにより、所属会社等が判別できる場合には、当該所属会社等の名称を表示することとしてもよい。

なお、上記第１の実施形態では、承認する電子メールの宛先の職制役職及び氏名を表示しなくても承認ができるような場合について説明したが、これに限られるものではない。例えば、宛先が所定数以上ある場合には、承認者が職制役職及び氏名を表示しなければ承認ができないように制限を設けることとしてもよい。また、宛先が所定数以上あるのに職制役職及び氏名の表示を行わずに承認がされた場合には、確認のメッセージを表示するようにしてもよい。また、宛先が所定数以上ある場合には、強制的に職制役職及び氏名を表示するようにしてもよい。

《第２の実施形態》
次に、電子メールシステムの第２の実施形態について、図２１、図２２に基づいて詳細に説明する。なお、本第２の実施形態では、第１の実施形態と異なり、利用者が他のメールに対する返信メールを作成するときに、メッセージ作成画面に宛先の人物の職制役職および氏名を表示するというものである。なお、本第２の実施形態は、第１の実施形態で説明した処理の一部のみが異なる。したがって、同一の処理・判断には同一の符号を付すとともに、説明を省略又は簡略化するものとする。なお、本第２の実施形態では、上記第１の実施形態で説明した承認処理を行わないので、図３の承認メールＤＢ３８を省略してもよい。

図２１には、本第２の実施形態にかかるメール処理部１２及び表示・送受信部２２の処理の一部（第１の実施形態における図７、図８の処理に続く処理）が示されている。

図２１の処理では、図７、図８の処理（認証処理やメール表示画面の表示処理など）が行われた後、ステップＳ１３２において、クライアント端末２０の表示・送受信部２２が、利用者（第２のユーザとしての電子メールの作成をしようとしている利用者）からメッセージ作成要求を受け付けたか否かを判断する。この場合、利用者は、メール表示画面（図１２）上で、「新規作成」、「差出人に返信」、「全員に返信」のいずれかのボタンを押すことで、メッセージ作成要求を出す。ステップＳ１３２の判断が否定された場合には、ステップＳ１４４に移行する。一方、ステップＳ１３２の判断が肯定された場合には、ステップＳ１３４に移行する。ステップＳ１３４に移行した場合、表示・送受信部２２は、メールサーバ１０のメール処理部１２に対してメッセージ作成要求を送信し、その後は、ステップＳ１３６において、送信処理（第１の実施形態の図１４の処理と同一）を実行する。

これに対し、メール処理部１２では、ステップＳ２６において、クライアント端末２０（表示・送受信部２２）からメッセージ作成要求を受信するまで待機する。この場合、表示・送受信部２２においてステップＳ１３４が行われると、ステップＳ２７ａに移行する。

ステップＳ２７ａでは、メール処理部１２は、クライアント端末２０から受信したメッセージ作成要求が、他のメールに対する返信メッセージの作成要求か否かを判断する。ここでの判断が否定された場合には、ステップＳ３０に移行するが、肯定された場合には、ステップＳ２７ｂに移行する。

ステップＳ２７ｂでは、メール処理部１２は、人事ＤＢ３６を参照して、返信メッセージの宛先の人物の職制役職及び氏名を抽出し、取得する。次いで、ステップＳ２７ｃでは、メール処理部１２は、取得した職制役職および氏名を用いてメッセージ作成画面を作成し、クライアント端末２０（表示・送受信部２２）に対して送信する。このステップＳ２７ｃで作成、送信されるメッセージ作成画面が、図２２に示されている。図２２に示すように、メッセージ作成画面の宛先は、職制役職および氏名を用いた表示がなされているとともに、職制役職にてソートされて順番が入れ替えられている。

なお、図２２の画面は、図１４の送信処理のステップＳ１５２において、クライアント端末２０の表示部１９３に表示されることになる。この場合、第１のユーザとしての元のメールの差出人が指定した宛先の少なくとも１つの宛先に対する返信メールを作成する利用者（第２のユーザ）は、図２２の画面を見ることで、どの所属部のどの役職の誰にメールを出そうとしているかを簡易かつ正確に把握することができる。したがって、返信メールを作成し送信する者は、図２２の画面を見ることで、返信メールの内容を宛先全員に送って良いものかどうかなどを的確に判断することができる。

次いで、ステップＳ３０では、メール処理部１２は、宛先、件名、本文、発信者ＩＤを受信するまで待機する。この場合、メール処理部１２は、図１４のステップＳ１５８の処理が行われたタイミングで、ステップＳ３２に移行することになる。

次いで、ステップＳ３１ａでは、メール処理部１２は、メッセージＩＤ、ヘッダを生成し、ヘッダ、件名、本文を宛先（フォルダ）に送信する。また、メール処理部１２は、次のステップＳ３１ｂにおいて、メールＤＢ３２の種別を「送信」として、利用者ＩＤ、メッセージＩＤ、件名、本文を記録する。

その後は、利用者がログアウト要求が出されるまで（ステップＳ１４４の判断が肯定され、ステップＳ１４６が実行された後、ステップＳ１４８の判断が肯定されるまで）、上記処理が繰り返されることになる。

以上、説明したように、本第２の実施形態によると、メール処理部１２は、メールを作成しようとしている利用者による電子メールを指定した返信メールの作成要求を受け付けた場合（Ｓ２６：肯定の場合）に、人事ＤＢ３６を参照して、利用者により指定された電子メールに含まれる宛先に対応する職制役職及び氏名を取得する。そして、メール処理部１２は、職制役職及び氏名の情報を、電子メールの本文とともにメッセージ作成画面に表示して、利用者が使用するクライアント端末２０（表示・送受信部２２）に対して送信する。このように、本第２の実施形態では、返信メールを作成する利用者のクライアント端末２０に対して、電子メールの宛先確認を支援する情報を送信することができるので、利用者は、返信メールを作成する際に、電子メールの宛先がどの所属部のどの役職の誰であるかを簡易かつ正確に把握することができるようになる。これにより、利用者は、電子メールを送ってよいかどうかを的確に判断することができるので、電子メールの誤送信等による情報漏洩の発生を抑制することが可能となる。

なお、上記第２の実施形態では、メッセージ作成要求が、返信メールの作成である場合に、メッセージ作成画面に職制役職及び氏名を表示する場合について説明したが、これに限られるものではない。例えば、返信メールが複数の宛先に対する返信メールである場合や、同報メールに対する全員返信メールである場合などにおいて、メッセージ作成画面に職制役職及び氏名を表示するようにしてもよい。このように、複数又は多数の宛先に対する返信メールを作成する場合にメッセージ作成画面に職制役職及び氏名を表示することで、情報漏洩の発生を効率よく抑制することができる。

なお、上記第２の実施形態では、返信メールを作成する場合に、自動的に職制役職及び氏名を表示することとしたが、これに限られるものではない。例えば、第１の実施形態と同様、最初の段階では、メッセージ作成画面に職制役職表示をさせず、「職制役職表示」ボタンを設けておき、当該ボタンが利用者によって押された段階で、職制役職及び氏名が表示されるようにしてもよい。

なお、上記第２の実施形態では、返信メールを作成する場合に、職制役職及び氏名を表示することとしたが、これに限らず、電子メールを受信した際に、差出人や差出人が指定した宛先に含まれる人物の職制役職及び氏名を表示するようにしてもよい。

なお、上記第２の実施形態は、上記第１の実施形態と組み合わせることとしてもよい。すなわち、図２１のフローチャートに、承認処理を組み込むこととしても良い。

《第３の実施形態》
次に、電子メールシステムの第３の実施形態について、図２３〜図３０に基づいて詳細に説明する。なお、本第３の実施形態は、第１、第２の実施形態のような、クライアント端末２０が、メールサーバ１０が作成した電子メールに関する画面を取得して、ブラウザ内に表示する場合（ＷＥＢメール）と異なり、クライアント端末２０が、メールクライアントのプログラムを実行することで、メールサーバ１０から送信されてきた情報に基づいて画面を作成し、表示する。

本第３の実施形態のクライアント端末２０では、ＣＰＵ１９０がプログラム（メールクライアント）を実行することで、図２３に示すメール機能部１２２としての機能が実現されている。このメール機能部１２２は、メールクライアントの動作（電子メールに関する画面の表示、利用者から入力された情報のメールサーバ１０への送信、メールサーバ１０からの電子メールに関する情報の受信など）を行う。なお、本第３の実施形態では、メールサーバ１０のメール処理部１２は、第１の実施形態と異なり、電子メールに関する画面の作成やクライアント端末２０に対する画面の送信処理は行わない。

以下、メールサーバ１０のメール処理部１２と、クライアント端末２０のメール機能部１２２の処理について、図２４〜図３０に基づいて、及び第１の実施形態のフローチャートと比較しつつ説明する。

図２４〜図２６は、メール処理部１２及びメール機能部１２２による一連の処理を示すフローチャートであり、第１の実施形態の図７〜図９に対応する。また、図２７は、メール機能部１２２の送信処理を示すフローチャートであり、第１の実施形態の図１４に対応する。また、図２８〜３０は、メール処理部１２及びメール機能部１２２の承認処理を示すフローチャートであり、第１の実施形態の図１５〜図１７に対応する。

図２４の処理について説明する。図２４の処理では、図７と比較するとわかるように、メール機能部１２２は、第１の実施形態の表示・送受信部２２の処理のうち、ステップＳ１１４の処理を行わないようになっている。また、メール処理部１２は、第１の実施形態のメール処理部１２の処理のうち、ステップＳ１２に代えてステップＳ１２’の処理が実行される。ステップＳ１２’では、メール処理部１２は、利用者ＩＤ，パスワード入力画面をメール機能部１２２に送信するのではなく、利用者ＩＤ，パスワード入力要求を送信する。なお、これに伴い、メール機能部１２２のステップＳ１１６’では、予め用意しておいた利用者ＩＤ，パスワード入力画面を表示する。

図２５の処理について説明する。図２５の処理では、図８と比較するとわかるように、メール処理部１２は、認証がＯＫでなかった場合（Ｓ１８：否定の場合）に、ステップＳ２０’において、認証エラー画面ではなく、認証エラーを通知する。なお、メール処理部１２は、第１の実施形態のメール処理部１２の処理のうち、ステップＳ２２、Ｓ２４の処理を行わないようになっている。一方、メール機能部１２２は、認証エラーを受信した場合（Ｓ１２４’：肯定の場合）に、ステップＳ１２６’において、予め用意している認証エラー画面を表示する。また、メール機能部１２２は、認証エラーを受信しなかった場合（Ｓ１２４’：肯定の場合）には、ステップＳ１３０’において、メール表示画面を表示部１９３に表示する。なお、メール機能部１２２は、第１の実施形態の表示・送受信部２２の処理のうち、ステップＳ２８の判断を行わないようになっている。

なお、図２６の処理に関しては、図９と比較するとわかるように、メール処理部１２が、ステップＳ２８の処理（メッセージ作成画面の生成及び送信）を行わないようになっている。また、図２７のメール機能部１２２の送信処理に関しては、図１４と比較するとわかるように、ステップＳ１５０の処理（メッセージ作成画面を受信したか否かを判断する処理）を行わないようになっている。

次に、図２８の処理について説明する。図２８の処理では、図１５の処理と比較するとわかるように、メール処理部１２は、第１の実施形態のメール処理部１２の処理のうち、ステップＳ５０、Ｓ５２に代えて、ステップＳ５０’の処理を実行し、ステップＳ５６、Ｓ５８に代えて、ステップＳ５６’の処理を実行する。ステップＳ５０’では、メール処理部１２は、承認メールＤＢ３８を用いて、承認要求一覧画面ではなく、承認要求一覧をメール機能部１２２に対して送信する。また、ステップＳ５６’では、クライアント端末２０側から選択メール情報を受信したとき（承認者が図１８の画面上でチェックボックスにチェックを入れて送信ボタンを押したとき）に、メール処理部１２が、承認メールＤＢ３８を参照して、選択されたメールの本文、宛先、件名の情報を送信する。一方、メール機能部１２２は、第１の実施形態の表示・送受信部２２の処理のステップＳ１６０、Ｓ１６２に代えて、ステップＳ１６０’、Ｓ１６２の処理を実行し、ステップＳ１６８、Ｓ１７０に代えて、ステップＳ１６８’、Ｓ１７０’の処理を実行する。ステップＳ１６０’では、メール機能部１２２は、メール処理部１２から承認要求一覧を受信するまで待機し、ステップＳ１６２’では、メール機能部１２２は、受信した承認要求一覧を用いて承認要求一覧画面を作成し、表示する。また、ステップＳ１６８’では、メール機能部１２２は、メールサーバ１０（メール処理部１２）から本文、宛先、件名を受信するまで待機する。また、ステップＳ１７０’では、メール機能部１２２が、受信した本文、宛先、件名に基づいて図１９に示す承認画面１を作成し、表示部１９３に表示する。

次に、図２９の処理について説明する。図２９の処理では、図１６の処理と比較するとわかるように、メール処理部１２は、第１の実施形態のメール処理部１２の処理のステップＳ６２，Ｓ６４に代えて、ステップＳ６４’の処理を実行する。ステップＳ６４’では、メール処理部１２は、クライアント端末２０側から職制役職表示要求を受信した場合に、人事ＤＢ３６から職制役職及び氏名を取得し、クライアント端末２０に送信するようになっている。また、図２９の処理では、図１６の処理と比較するとわかるように、メール機能部１２２は、第１の実施形態の表示・送受信部２２の処理のステップＳ１８０，Ｓ１８２に代えて、ステップＳ１８０’、Ｓ１８２’の処理を実行する。ステップＳ１８０’では、メール機能部１２２は、メールサーバ１０（メール処理部１２）から職制役職及び氏名を受信するまで待機する。また、ステップＳ１８２’では、メール機能部１２２は、受信した職制役職及び氏名に基づいて、承認画面２（図２０）を作成し、表示部１９３に表示する。なお、図３０の処理は、図１７の処理と同一となっているので説明を省略する。

以上、説明したように、本第３の実施形態によると、クライアント端末２０においてメールクライアントを用いる場合でも、上記第１の実施形態と同様、宛先を職制役職及び氏名を用いて表示することができる。これにより、第１の実施形態と同様、電子メールの宛先確認を支援する情報を承認者に提供することができるので、承認者は、部下等が作成した電子メールの承認を行う際に、電子メールの宛先がどの所属部のどの役職の誰であるかを簡易かつ正確に把握することができるようになる。したがって、承認者は、電子メールの承認を行うか否かを的確に判断することができるので、電子メールの誤送信等による情報漏洩の発生を抑制することが可能となる。

なお、上記第２の実施形態の内容に関しても、メールクライアントを用いた電子メールシステムにおいて実現することが可能である。この場合、上記第３の実施形態の図２６の処理に代えて、図３１の処理を行うこととすればよい。この図３１の処理は、第２の実施形態の図２１の処理の一部を変更したものである。

図３１の処理では、メール処理部１２は、第２の実施形態のメール処理部１２の処理のうち、ステップＳ２７ｂ，Ｓ２７ｃに代えて、ステップＳ２７ｂ’の処理を実行する。このステップＳ２７ｂ’では、メール処理部１２は、人事ＤＢ３６を参照して、返信メールの宛先に対応する職制役職及び氏名を取得し、クライアント端末２０（メール機能部１２２）に対して送信する。

なお、図３１の送信処理（ステップＳ１３６）では、図３２に示すように、メール機能部１２２は、ステップＳ１５２’において、職制役職及び氏名を受信した場合、メッセージ作成画面を受信した職制役職及び氏名を用いて作成し、当該メッセージ作成画面を、表示部１９３に表示する。一方、職制役職及び氏名を受信しなかった場合には、メール機能部１２２は、メッセージ作成画面を受信した職制役職及び氏名を用いずに作成し、当該メッセージ作成画面を、表示部１９３に表示する。なお、その他の処理は、図１４と同一となっている。

以上、図３１、図３２の処理を行うことで、第２の実施形態と同様の処理を、メールクライアントを用いた電子メールシステムでも実現することが可能である。これにより、上記第２の実施形態と同様、返信メールを作成する際に、利用者は、電子メールの宛先がどの所属部のどの役職の誰であるかを簡易かつ正確に把握することができるようになる。これにより、利用者は、電子メールを送ってよいかどうかを的確に判断することができるので、電子メールの誤送信等による情報漏洩の発生を抑制することが可能となる。

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

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

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

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

なお、以上の説明に関して更に以下の付記を開示する。
（付記１） メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付け、
第２のユーザによる前記電子メール情報を指定した要求を受け付け、
宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出し、
前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する、処理をコンピュータに実行させることを特徴とする電子メール情報送信プログラム。
（付記２） 前記第２のユーザは、前記第１のユーザが作成した電子メールの送信について承認する承認者であり、
前記要求を受け付ける処理では、前記第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする付記１に記載の電子メール情報送信プログラム。
（付記３） 前記宛先の情報には、複数の宛先の情報が含まれ、
前記要求を受け付ける処理では、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールの複数の宛先の全てに対する返信メール作成要求を受け付けることを特徴とする付記１に記載の電子メール情報送信プログラム。
（付記４） 前記宛先の情報には、複数の宛先の情報が含まれ、
前記要求を受け付ける処理では、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする付記１に記載の電子メール情報送信プログラム。
（付記５） メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付ける情報受け付け工程と、
第２のユーザによる前記電子メール情報を指定した要求を受け付ける要求受け付け工程と、
宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出する抽出工程と、
前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する送信工程と、をコンピュータが実行することを特徴とする電子メール情報送信方法。
（付記６） 前記第２のユーザは、前記第１のユーザが作成した電子メールの送信について承認する承認者であり、
前記要求受け付け工程では、前記第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする付記５に記載の電子メール情報送信方法。
（付記７） 前記宛先の情報には、複数の宛先の情報が含まれ、
前記要求受け付け工程では、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールの複数の宛先の全てに対する返信メール作成要求を受け付けることを特徴とする付記５に記載の電子メール情報送信方法。
（付記８） 前記宛先の情報には、複数の宛先の情報が含まれ、
前記要求受け付け工程では、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする付記５に記載の電子メール情報送信方法。
（付記９） メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付ける情報受け付け部と、
第２のユーザによる前記電子メール情報を指定した要求を受け付ける要求受け付け部と、
宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部と、
前記記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出する抽出部と、
前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する送信部と、を備える電子メール情報送信装置。
（付記１０） 前記第２のユーザは、前記第１のユーザが作成した電子メールの送信について承認する承認者であり、
前記要求受け付け部は、前記第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする付記９に記載の電子メール情報送信装置。
（付記１１） 前記宛先の情報には、複数の宛先の情報が含まれ、
前記要求受け付け部は、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールの複数の宛先の全てに対する返信メール作成要求を受け付けることを特徴とする付記９に記載の電子メール情報送信装置。
（付記１２） 前記宛先の情報には、複数の宛先の情報が含まれ、
前記要求受け付け部は、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする付記９に記載の電子メール情報送信装置。

１０ メールサーバ（電子メール情報送信装置）
１２ メール処理部（情報受け付け部、要求受け付け部、抽出部、送信部）
３６ 人事ＤＢ（記憶部）
９０ ＣＰＵ（コンピュータ）

Claims (6)

1. メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付け、
   第２のユーザによる前記電子メール情報を指定した要求を受け付け、
   宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出し、
   前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する、処理をコンピュータに実行させることを特徴とする電子メール情報送信プログラム。
2. 前記第２のユーザは、前記第１のユーザが作成した電子メールの送信について承認する承認者であり、
   前記要求を受け付ける処理では、前記第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする請求項１に記載の電子メール情報送信プログラム。
3. 前記宛先の情報には、複数の宛先の情報が含まれ、
   前記要求を受け付ける処理では、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールの複数の宛先の全てに対する返信メール作成要求を受け付けることを特徴とする請求項１に記載の電子メール情報送信プログラム。
4. 前記宛先の情報には、複数の宛先の情報が含まれ、
   前記要求を受け付ける処理では、前記複数の宛先のいずれかの宛先に該当する第２のユーザによる、前記第１のユーザが作成した電子メールを指定した表示要求を受け付けることを特徴とする請求項１に記載の電子メール情報送信プログラム。
5. メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付ける情報受け付け工程と、
   第２のユーザによる前記電子メール情報を指定した要求を受け付ける要求受け付け工程と、
   宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出する抽出工程と、
   前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する送信工程と、をコンピュータが実行することを特徴とする電子メール情報送信方法。
6. メール本文情報と、第１のユーザにより指定された宛先の情報とを含む電子メール情報を受け付ける情報受け付け部と、
   第２のユーザによる前記電子メール情報を指定した要求を受け付ける要求受け付け部と、
   宛先の情報と、当該宛先に該当する人物の人事情報とを対応付けて記憶する記憶部と、
   前記記憶部を参照して、前記第２のユーザによって指定された電子メール情報に含まれる宛先の情報に対応する人事情報を抽出する抽出部と、
   前記抽出された人事情報を、前記電子メール情報に含まれる前記メール本文情報とともに、前記第２のユーザが使用する端末に対して送信する送信部と、を備える電子メール情報送信装置。

Images