JP5974865B2 - メール処理プログラム、メール処理装置及びメール処理方法 - Google Patents

Description

本件は、メールに関する処理プログラム、処理装置及び処理方法に関する。

企業等において利用されるメールシステムには、承認機能が設けられている場合がある。この承認機能は、メールを送信する場合に、作成したメールを承認者（上司など）にチェックしてもらい、承認者によって送信が承認された場合にのみ、メール送信できる機能である。ここで、承認者によるメール内容のチェックが正確に行われるようにするためには、記載内容の真偽を確認するための情報を承認者に対して提供する必要がある。

なお、従来においては、医師の作成した患者の診療にかかるオーダーを第三者が確認し、承認できるようにするために、オーダー作成根拠となった資料の情報を第三者に提供するシステムが知られている（例えば、特許文献１参照）。

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

特許文献１のような技術をメールシステムに適用する場合、承認してもらうメールに該メールの記載内容の真偽を判断するための関連情報（ファイルやメール）をメール作成者が添付し、承認者に提供（送信）することが考えられる。

しかしながら、上記のように承認してもらうメールに関連情報を添付する場合、添付された関連情報を削除せずに承認者が承認してしまうことで、メールとともに関連情報の内容が宛先に送信されてしまう可能性がある。

１つの側面では、本発明は、送信メールの承認処理を適切に支援することが可能なメール処理プログラム、メール処理装置及びメール処理方法を提供することを目的とする。

本明細書に記載のメールに関する処理プログラムは、第１の端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信し、受信したメールの情報が記憶された記憶部から、前記第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報とを第２の端末に送信し、前記第２の端末から前記送信メールの送信許可を示す情報を受信すると、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信する、処理をコンピュータに実行させる。

本明細書に記載のメールに関する処理装置は、端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信する受信部と、前記受信部が受信したメールが記憶された記憶部と、第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を前記記憶部から読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報とを第２の端末に送信する情報送信部と、前記第２の端末から前記送信メールの送信許可を示す情報を受信した場合に、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信するメール送信部と、を備えている。

本明細書に記載のメールに関する処理方法は、第１の端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信する工程と、受信したメールが記憶された記憶部から、前記第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報とを第２の端末に送信する工程と、前記第２の端末から前記送信メールの送信許可を示す情報を受信した場合に、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信する工程と、をコンピュータが実行する。

本実施例に記載のメール処理プログラム、メール処理装置及びメール処理方法は、送信メールの承認処理を適切に支援することができるという効果を奏する。

一実施形態に係る電子メールシステムの構成を概略的に示す図である。 図２（ａ）は、サーバのハードウェア構成を示す図であり、図２（ｂ）は、クライアントのハードウェア構成を示す図である。 サーバ及びクライアントの機能ブロック図である。 利用者認証ＤＢのデータ構造の一例を示す図である。 メールＤＢのデータ構造の一例を示す図（その１）である。 メールＤＢのデータ構造の一例を示す図（その２）である。 承認ＤＢのデータ構造の一例を示す図である。 コメントＤＢのデータ構造の一例を示す図である。 メール処理部の一連の処理を示すフローチャートである。 図９のステップＳ２６の具体的処理を示すフローチャートである。 図９のステップＳ３０の具体的処理を示すフローチャートである。 図９のステップＳ３４の具体的処理を示すフローチャートである。 図１３（ａ）は、利用者ＩＤ、パスワード入力画面の一例を示す図であり、図１３（ｂ）は、認証エラー画面の一例を示す図である。 図１４（ａ）は、メール表示画面の一例を示す図（その１）であり、図１４（ｂ）は、メール表示画面の一例を示す図（その２）である。 図１５（ａ）は、メール送信画面（承認依頼画面）の一例を示す図（その１）であり、図１５（ｂ）は、メール送信画面（承認依頼画面）の一例を示す図（その２）である。 メール送信画面（承認依頼画面）の一例を示す図（その３）である。 メール送信画面（承認依頼画面）の一例を示す図（その４）である。 メール送信画面（承認依頼画面）の一例を示す図（その５）である。 図１９（ａ）は、承認一覧画面の一例を示す図（その１）であり、図１９（ｂ）は、承認一覧画面の一例を示す図（その２）である。 承認画面の一例を示す図（その１）である。 承認画面の一例を示す図（その２）である。 承認依頼状況一覧画面の一例を示す図である。 承認結果画面の一例を示す図である。

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

本実施形態の電子メールシステム１００は、図１に示すように、処理装置としてのサーバ１０と、クライアント２０と、を備える。サーバ１０とクライアント２０は、インターネットやＬＡＮ（Local Area Network）などのネットワーク８０に接続されている。この電子メールシステム１００は、クライアント２０においてブラウザ上に表示されるＷＥＢメールの画面（サーバ１０から提供）内で利用者が入力や操作を行うことで、クライアント２０間における電子メールのやり取りを可能にするシステムである。なお、本実施形態では、あるクライアント２０の利用者が他のクライアントの利用者に対して電子メールを送信する場合、予め定められた承認者（上司等）による電子メールのチェックが行われるものとする。そして、承認者によって電子メールの送信が承認された場合にのみ、電子メールが送信先に送信されるものとする。なお、以下においては、電子メールを「メール」と略述するものとする。

図２（ａ）には、サーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらサーバ１０の構成各部は、バス９８に接続されている。サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（処理プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（処理プログラムを含む）をＣＰＵ９０が実行することにより、図３に示すメール処理部４０としての機能が実現される。メール処理部４０は、メールの送受信、承認処理に関する各種処理を実行する。なお、図３には、サーバ１０のＨＤＤ９６等に格納されている利用者認証ＤＢ（database）３０、記憶部としてのメールＤＢ３２、承認ＤＢ３４、コメントＤＢ３６も図示されている。なお、各ＤＢ３０〜３６の具体的なデータ構造等については後述する。

図２（ｂ）には、クライアント２０のハードウェア構成が示されている。図２（ｂ）に示すように、クライアント２０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、表示部１９３、入力部１９５、ネットワークインタフェース１９７、及び可搬型記憶媒体用ドライブ１９９等を備えており、クライアント２０の構成各部は、バス１９８に接続されている。表示部１９３は、液晶ディスプレイ等を含み、入力部１９５は、キーボードやマウス、タッチパネル等を含む。クライアント２０においては、ＣＰＵ１９０がプログラムを実行することで、図３に示す表示処理部５０及び入力処理部５２としての機能が実現される。表示処理部５０は、サーバ１０のメール処理部４０からの指示に応じて、クライアント２０の表示部１９３上にメール作成、送受信に関する画面を表示したり、メールの承認に関する画面を表示したりする。入力処理部５２は、クライアント２０の利用者が入力部１９５を介して入力した情報を受け付け、当該情報をサーバ１０のメール処理部４０に対して送信する。

ここで、サーバ１０が有する各種ＤＢについて説明する。

図４には、利用者認証ＤＢ３０のデータ構造の一例が示されている。利用者認証ＤＢ３０は、利用者がログインする際の認証に用いる情報や、利用者に対して予め対応付けられている承認者の情報を格納するデータベースである。この利用者認証ＤＢ３０は、図４に示すように、「利用者アドレス（利用者ＩＤ）」と、利用者ＩＤに対応する「パスワード」及び「利用者名称」と、利用者に対して予め対応付けられている承認者のアドレス（「承認者アドレス」）及び「承認者名称」の各フィールドを有している。例えば、図４からは、利用者「田中」、「佐藤」、「鈴木」に対して承認者「山田」が定められていることがわかる。

図５、図６には、メールＤＢ３２のデータ構造の一例が示されている。メールＤＢ３２は、クライアント２０間で送受信されたメールの情報を格納するデータベースであり、利用者ごとに用意される。なお、図５は、利用者「山田」に対応するメールＤＢであり、図６のメールＤＢ３２は、利用者「田中」に対応するメールＤＢである。

メールＤＢ３２は、図５、図６に示すように、「利用者ＩＤ」、「受送信」、「メッセージＩＤ」、「発信者アドレス（利用者アドレス）」、「宛先」、「最新承認依頼日時」、「発信日時（承認日時）」、「メール情報（件名、本文）」の各フィールドを有する。

「利用者ＩＤ」のフィールドには、メールの送信又は受信を行った利用者の利用者ＩＤが入力される。「受送信」のフィールドには、メールが利用者ＩＤに対応する利用者によって送信されたのか受信されたのかの情報が入力される。「メッセージＩＤ」のフィールドには、メール毎に定義されるユニークなＩＤが入力される。「発信者アドレス（利用者アドレス）」のフィールドには、メールの差出人のメールアドレスが入力される。なお、「受送信」のフィールドが「送信」である場合には、発信者アドレスとして利用者ＩＤが入力される。「宛先」のフィールドには、メールの宛先のメールアドレスが入力される。なお、「受送信」のフィールドが「受信」である場合には、宛先に利用者ＩＤが含まれることになる。「最新承認依頼日時」のフィールドには、メールの発信者がメールを送信するために承認者に対して承認依頼を出した日時（承認依頼が複数回出された場合には最新の承認依頼の日時）が入力される。「発信日時（承認日時）」は、メールが送信先に対して送信された日時であり、承認が必要なメールの場合には承認者によって承認された日時が入力される。「メール情報（件名、本文）」のフィールドには、メールの件名及び本文そのものが入力される。なお、本実施形態では、利用者ごとにメールＤＢ３２を作成し、管理することとしているが、これに限らず、１つのメールＤＢにて、複数の利用者の送受信メール情報を管理することとしてもよい。

図７には、承認ＤＢ３４の一例が示されている。承認ＤＢ３４は、メールの承認依頼が出された場合に、そのメールの情報や承認結果などを格納するためのデータベースである。なお、承認ＤＢ３４は、承認者ごとに用意されるものとする（図７は、承認者「山田」の承認ＤＢ３４を示している）。承認ＤＢ３４は、「承認ＩＤ」、「メッセージＩＤ」、「証跡メッセージＩＤ」、「承認結果」、「発信者アドレス（利用者アドレス）」、「宛先」、「承認依頼日時」、「メール情報（件名、本文）」の各フィールドを有する。

「承認ＩＤ」のフィールドには、承認依頼ごとに定義されるユニークなＩＤが入力される。なお、図７の下から１行目と下から２行目には同一のメールに対する承認依頼の情報が格納されているが、承認ＩＤは承認依頼ごとに定義されるＩＤであるので、これらの承認ＩＤは異なっている。「メッセージＩＤ」のフィールドには、メール毎に定義されるユニークなＩＤが入力される。「証跡メッセージＩＤ」のフィールドには、メールの送信者が指定した、送信するメールに関連する関連メール（証跡メール）のメッセージＩＤが入力される。なお、送信者は証跡メールを複数指定することもあるので、「証跡メッセージＩＤ」のフィールドには、複数のメッセージＩＤが格納されることもある。また、送信者は証跡メールを指定しない場合もあるので、「証跡メッセージＩＤ」のフィールドに、何も格納されないこともある（図７では、「−」と記述されている）。「承認結果」のフィールドには、承認者によって承認される前か否か、承認されたか承認されなかったかが入力される。図７では、「承認結果」のフィールドに、「承認依頼中」、「送信可（承認可）」、「差し戻し（承認不可）」のいずれかが入力される。「発信者アドレス（利用者アドレス）」のフィールドには、メールの差出人のメールアドレスが入力される。「宛先」のフィールドには、メールの宛先のメールアドレスが入力される。「承認依頼日時」のフィールドには、メールの発信者がメールを送信するために承認者に対して承認依頼を出した日時が入力される。「メール情報（件名、本文）」のフィールドには、メールの件名及び本文そのものが入力される。

図８には、コメントＤＢ３６の一例が示されている。コメントＤＢ３６は、承認者によって承認不可とされたメールに対して入力されたコメント（承認者が承認不可とした理由や、修正すべき点など）が格納されるデータベースである。コメントＤＢ３６は、図８に示すように、「承認ＩＤ」、「承認者アドレス」、「メッセージＩＤ」、「コメント」の各フィールドを有する。「承認ＩＤ」のフィールドには、承認依頼ごとに定義されるユニークなＩＤが入力される。「承認者アドレス」のフィールドには、承認不可とした承認者のメールアドレスが入力される。「メッセージＩＤ」のフィールドには、メール毎に定義されるユニークなＩＤが入力される。「コメント」のフィールドには、承認者がクライアント２０上で入力したコメントそのものが入力される。

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

図９の処理では、まず、ステップＳ１０において、メール処理部４０は、メール利用要求をクライアント２０から受信するまで待機する。クライアント２０の利用者は、クライアント２０の表示部１９３上に表示されているブラウザ上でＷＥＢメールサービスのアドレスに対してアクセスすることによりメール利用要求を出すことができる。なお、メール利用要求は、クライアント２０の入力処理部５２から送信される。

メール処理部４０は、入力処理部５２から送信されてきたメール利用要求を受信すると（ステップＳ１０の判断が肯定されると）、ステップＳ１２に移行する。ステップＳ１２では、メール処理部４０は、利用者ＩＤ、パスワード入力画面のデータをクライアント２０（表示処理部５０）に対して送信する。この場合の利用者ＩＤ、パスワード入力画面は、図１３（ａ）に示すような画面であるものとする。なお、クライアント２０においては、表示処理部５０が、利用者ＩＤ、パスワード入力画面を表示部１９３上に表示する。

次いで、ステップＳ１４では、メール処理部４０は、利用者ＩＤ、パスワードをクライアント２０から受信するまで待機する。なお、利用者が利用者ＩＤとパスワードを図１３（ａ）の画面上で入力し、送信ボタンを押すと、入力処理部５２は、利用者ＩＤとパスワードをメール処理部４０に送信する。

入力処理部５２からメール処理部４０に対して利用者ＩＤとパスワードが送信されると（ステップＳ１４の判断が肯定されると）、ステップＳ１６に移行する。ステップＳ１６では、メール処理部４０が、利用者認証ＤＢ３０（図４）を用いて認証を実行する。次いで、ステップＳ１８では、メール処理部４０が、認証がＯＫであったか否かを判断する。ここでの判断が否定された場合には、ステップＳ２０に移行し、メール処理部４０、認証エラー画面（図１３（ｂ））をクライアント２０（表示処理部５０）に対して送信する。この場合、表示処理部５０は、図１３（ｂ）の画面を表示部１９３上に表示する。なお、ステップＳ２０の処理が行われた後は、図９の全処理を終了する。

一方、ステップＳ１８の判断が肯定された場合、すなわち認証がＯＫであった場合には、ステップＳ２２に移行する。ステップＳ２２では、メール処理部４０は、メールＤＢ３２（図５、図６）を用いて、入力された利用者ＩＤに対応するメール表示画面のデータを作成して、クライアント２０に送信する。この場合のメール表示画面は、図１４（ａ）、図１４（ｂ）に示すような画面であるものとする。なお、図１４（ａ）のメール表示画面が、図５のメールＤＢ３２（利用者が「山田」の場合）に対応し、図１４（ｂ）のメール表示画面が、図６のメールＤＢ３２（利用者が「田中」の場合）に対応している。クライアント２０の表示処理部５０は、データを受信した段階で、図１４（ａ）や図１４（ｂ）のメール表示画面を表示部１９３上に表示する。

次いで、ステップＳ２４では、メール処理部４０は、メール（送信メール）の作成要求をクライアント２０から受信したか否かを判断する。この場合、メール処理部４０は、図１４（ａ）、図１４（ｂ）のメール表示画面上の「メッセージ新規作成」ボタンが利用者によって押されたという情報を入力処理部５２から受信したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２６に移行するが、否定された場合には、ステップＳ２６を経ずにステップＳ２８に移行する。

ステップＳ２６に移行した場合、メール処理部４０は、メール送信処理（図１０のフローチャートに沿った処理）を実行する。なお、メール送信処理の詳細については後述する。ステップＳ２６の処理の後は、ステップＳ２８に移行する。

ステップＳ２８に移行すると、メール処理部４０は、承認要求をクライアント２０から受信したか否かを判断する。この場合、メール処理部４０は、図１４（ａ）のメール表示画面上の「承認処理」ボタンが利用者によって押されたという情報を入力処理部５２から受信したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ３０に移行するが、否定された場合には、ステップＳ３０を経ずにステップＳ３２に移行する。なお、図１４（ａ）、図１４（ｂ）のメール表示画面においては、図７の承認ＤＢに「承認依頼中」のメールが存在している場合にのみ、「承認処理」のボタンが表示されるものとする。

ステップＳ３０に移行した場合、メール処理部４０は、承認処理（図１１のフローチャートに沿った処理）を実行する。なお、承認処理の詳細については後述する。ステップＳ３０の処理の後は、ステップＳ３２に移行する。

ステップＳ３２に移行すると、メール処理部４０は、承認結果一覧表示要求を受け付けたか否かを判断する。この場合、メール処理部４０は、図１４（ａ）、図１４（ｂ）のメール表示画面上の「承認依頼状況閲覧」ボタンが利用者によって押されたという情報を入力処理部５２から受信したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ３４に移行するが、否定された場合には、ステップＳ３４を経ずにステップＳ３６に移行する。

ステップＳ３４に移行した場合、メール処理部４０は、承認結果一覧表示処理（図１２のフローチャートに沿った処理）を実行する。なお、承認結果一覧表示処理の詳細については後述する。ステップＳ３４の処理の後は、ステップＳ３６に移行する。

ステップＳ３６に移行すると、メール処理部４０は、ログアウト要求をクライアント２０から受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ２４に戻り、ステップＳ２４〜Ｓ３６の処理・判断を繰り返す。

なお、これまでの説明からわかるように、図９の処理では、クライアント２０の利用者が、図１４（ａ）、図１４（ｂ）のメール表示画面上で「メッセージ新規作成」ボタンを押したタイミングで、ステップＳ２６（メール送信処理（図１０））の処理が実行される。また、利用者が「承認処理」ボタンを押したタイミングで、ステップＳ３０（承認処理（図１１））の処理が実行される。更に、利用者が「承認依頼状況閲覧」ボタンを押したタイミングで、ステップＳ３４（承認結果一覧表示処理（図１２））の処理が実行されることになる。そして、ステップＳ３６の判断が肯定された場合、すなわち、利用者が図１４（ａ）等の画面上で「ログアウト」ボタンを押したという情報を、メール処理部４０が入力処理部５２から受信した場合、図９の全処理が終了する。

以下、図１０〜図１２の各処理について、詳細に説明する。

（メール送信処理（図１０））
図１０に基づいて、メール送信処理について説明する。図１０の処理では、まず、ステップＳ５０において、メール処理部４０が、メール送信画面（承認依頼画面）データを作成し、クライアント２０（表示処理部５０）に送信する。この場合、メール処理部４０は、図１５（ａ）に示すような画面のデータを作成し、クライアント２０の表示処理部５０に対して送信する。なお、表示処理部５０は、表示部１９３上に図１５（ａ）の画面を表示する。

次いで、ステップＳ５２では、メール処理部４０は、証跡メール添付要求をクライアント２０から受信したか否かを判断する。この場合、メール処理部４０は、クライアント２０の入力処理部５２から、利用者が図１５（ａ）の「証跡メール添付」ボタンを押したという情報が送信されてきたか否かを判断する。ここでの判断が否定された場合には、ステップＳ６４に移行するが、肯定された場合には、ステップＳ５４に移行する。なお、本実施形態では、利用者は、「証跡メール添付ボタン」を押す前の段階において、図１５（ｂ）に示すように、メール送信画面（承認依頼画面）の宛先、件名、記事画面の欄に対する入力を完了しているものとする。

ステップＳ５４に移行すると、メール処理部４０は、「証跡メール添付」ボタンを押した利用者の受信メールの情報（差出人、件名の情報）をメールＤＢ３２から取得する。なお、メール処理部４０は、メールＤＢ３２に格納されている全ての受信メールの情報を取得してもよいが、例えば、直近の所定件数の受信メールや、現在から所定期間の間に受信した受信メールなど、取得する受信メールの範囲を限定することとしてもよい。

次いで、ステップＳ５６では、メール処理部４０は、取得した情報から証跡メール一覧を作成し、その一覧をメール送信画面（承認依頼画面）に追加し、当該画面データをクライアント２０に送信する。具体的には、メール処理部４０は、図１６に示すような画面のデータをクライアント２０の表示処理部５０に対して送信する。この場合、表示処理部５０は、図１６の画面を表示部１９３上に表示する。なお、証跡メール一覧に含まれるメールが多い場合には、画面にスクロール機能を持たせてもよい。

なお、クライアント２０の利用者は、図１６の証跡メール一覧において、図１７に破線枠にて示すように、１又は複数のメールを証跡メールとして選択することができる。なお、証跡メールとは、現在作成中のメールの内容に関連するメール（メール作成の根拠となっているメール）であり、メールの内容の真偽を承認者が判断するために必要なメールであるものとする。利用者が証跡メールを１又は複数選択し、「証跡添付」ボタンを押すと、入力処理部５２は、証跡メールを選択したという情報（本実施形態では証跡メールのメッセージＩＤ）をメール処理部４０に対して送信する。

次いで、ステップＳ５８では、メール処理部４０は、添付する証跡メールのメッセージＩＤをクライアント２０から受信するまで待機する。証跡メールのメッセージＩＤをメール処理部４０が受信すると、ステップＳ６０に移行し、メール処理部４０は、選択された証跡メールのメッセージＩＤに対応する情報（本文等）をメールＤＢ３２から取得する。

次いで、ステップＳ６２では、メール処理部４０が、取得した情報から図１８において太枠線で示すような証跡メール画面が添付されたメール送信画面を作成し、当該画面データをクライアント２０（表示処理部５０）に送信する。表示処理部５０は、図１８の画面を表示部１９３上に表示する。なお、利用者は、図１８の画面において、証跡メールとして選択したメールが正しいかどうかや、証跡メールの内容と送信しようとしているメールの内容とが整合しているかどうか、などを確認することができる。利用者は、メールの内容を確認した後、図１８の画面上において「送信（承認依頼）」ボタンを押すことで、承認者に対する承認依頼を出すことができる。この場合、入力処理部５２は、承認依頼のあったメール（送信メール）の情報（宛先、件名、本文、発信者ＩＤ）や、証跡メールのメッセージＩＤ等をメール処理部４０に対して送信する。

ステップＳ６２の後、又はステップＳ５２の判断が否定された後は、ステップＳ６４に移行する。ステップＳ６４では、メール処理部４０が、送信メールの情報（宛先、件名、本文、発信者ＩＤ）や承認メールのメッセージＩＤ等をクライアント２０から受信するまで待機する。そして、メール処理部４０が受信した段階（ステップＳ６４の判断が肯定された段階）で、ステップＳ６６に移行する。ステップＳ６６では、メール処理部４０は、利用者認証ＤＢ３０と利用者アドレス（ＩＤ）とを用いて、利用者に対応する（予め対応付けられている）承認者アドレスを取得する。

次いで、ステップＳ６８では、メール処理部４０が、送信メールに関するメッセージＩＤと承認ＩＤとを生成する。次いで、ステップＳ７０では、メール処理部４０は、ステップＳ６４において受信した情報に証跡メールのメッセージＩＤが含まれているか否かを判断する。ここでの判断が肯定された場合（ステップＳ５４〜Ｓ６２を経た場合）には、ステップＳ７２に移行する。ステップＳ７２では、メール処理部４０は、承認ＩＤ，メッセージＩＤ，利用者アドレス（発信者アドレス）、宛先、件名、本文、証跡メールのメッセージＩＤ（証跡メッセージＩＤ）を、承認者アドレスに対応する承認ＤＢ３４に記録する。一方、ステップＳ７０の判断が否定された場合（ステップＳ５４〜Ｓ６２を経なかった場合）には、ステップＳ７４に移行する。ステップＳ７４では、メール処理部４０が、承認ＩＤ，メッセージＩＤ，利用者アドレス（発信者アドレス）、宛先、件名、本文を、承認者アドレスに対応する承認ＤＢ３４に記録する。なお、この場合には、図７の上から２行目のレコードのように証跡メッセージＩＤのフィールドを空欄「−」とする。

以上のようにして、ステップＳ７２又はＳ７４の処理が行われた後は、図１０の全処理を終了し、図９のステップＳ２８に移行する。なお、ステップＳ２８に移行する前には、表示処理部５０は、表示部１９３上に図１４（ａ）や図１４（ｂ）のようなメール表示画面を表示するものとする。

本実施形態では、メール処理部４０が図１０の処理を実行することで、送信するメール本文に関連する関連メール（証跡メール）がある場合に、当該証跡メールのメッセージＩＤを送信するメールに対応付けて承認ＤＢ３４に格納することができる。また、本実施形態では、証跡メールを設定する際に、クライアント２０の表示部１９３上に証跡メール一覧が表示されるので（図１６）、利用者は証跡メールの設定を簡易に行うことができるようになっている。

（承認処理（図１１））
次に、図１１のフローチャートに沿って、承認処理について説明する。図１１の処理は、前述のように、図１４（ａ）のメール表示画面において、「承認処理」ボタンが押された段階で実行される処理である。なお、以下の説明では、「承認処理」ボタンを押した利用者を「承認者」と呼ぶものとする。

図１１の処理では、まず、ステップＳ１００において、メール処理部４０が、承認者の利用者アドレスに対応する承認ＤＢ３４から、承認結果が承認依頼中となっている案件の発信者アドレス、発信日時、件名を取得する。

次いで、ステップＳ１０２では、メール処理部４０が、取得した情報を用いて、承認一覧画面を作成し、当該画面のデータを承認者が利用するクライアント２０（表示処理部５０）に対して送信する。図７の承認ＤＢ３４の場合、承認一覧画面としては、図１９（ａ）に示すような画面が作成される。この場合、表示処理部５０は、図１９（ａ）の画面を表示部１９３上に表示する。

次いで、ステップＳ１０４では、メール処理部４０が、メールの選択情報をクライアント２０（入力処理部５２）から受信するまで待機する。なお、利用者（承認者）は、図１９（ａ）の画面において、承認処理を行うメールを入力部１９５を用いて選択する。そして、入力処理部５２は、メールの選択情報をメール処理部４０に対して送信する。

ステップＳ１０４の判断が肯定され、ステップＳ１０６に移行すると、メール処理部４０は、選択されたメールのメッセージＩＤに対応する情報（本文等）を承認ＤＢ３４から取得する。

次いで、ステップＳ１０８では、メール処理部４０は、取得した情報に証跡メッセージＩＤが含まれているか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１１０に移行する。ステップＳ１１０では、メール処理部４０が、証跡メッセージＩＤに対応する情報（本文等）をメールＤＢ３２から取得し、ステップＳ１１２に移行する。なお、ステップＳ１０８の判断が否定された場合、すなわち、ステップＳ１０６において取得した情報に証跡メッセージＩＤが含まれていなかった場合には、ステップＳ１１０を経ずに、ステップＳ１１２に移行する。

ステップＳ１１２に移行した場合、メール処理部４０は、選択したメールの承認画面を作成し、当該画面のデータをクライアント２０（表示処理部５０）に送信する。なお、ステップＳ１０８の判断が肯定された場合には、図２０に示すような証跡メールの内容を含む承認画面が作成される。一方、ステップＳ１０８の判断が否定された場合には、図２１に示すような証跡メールの内容を含まない承認画面が作成される。なお、利用者（承認者）は、図２０や図２１の承認画面を参照し、メール送信を承認する場合には、「送信（承認）」ボタンを押す。一方、メール送信を承認しない場合には、利用者（承認者）は、コメント入力画面にコメントを入力した後、又は入力せずに、「取り下げ（承認不可）」ボタンを押す。なお、利用者（承認者）がボタンを押した場合には、入力処理部５２は、どのボタンが押されたかの情報（承認可否の情報）及びコメント（コメントが入力された場合のみ）をメール処理部４０に対して送信する。

次いで、ステップＳ１１４では、メール処理部４０が、承認可否の情報やコメントをクライアント２０から受信するまで待機する。そして、受信した段階で、メール処理部４０は、ステップＳ１１６において、承認可か否かを判断する。ここでの判断が肯定された場合（承認可の場合）には、ステップＳ１１８において、メール処理部４０は、承認ＤＢ３４に送信可（承認可）情報を記録する。また、ステップＳ１２０において、メール処理部４０は、宛先に対応するメールＤＢ３２に、メッセージＩＤ，宛先、件名、本文を記録する（この場合、メールを宛先に対して送信したことになる）。更に、ステップＳ１２２において、メール処理部４０は、発信者のメールＤＢ３２の「受送信」フィールドが「送信」であるレコードに、メッセージＩＤ、件名、本文を記録する。

一方、ステップＳ１１６の判断が否定された場合、すなわち承認不可であった場合には、ステップＳ１２４に移行し、メール処理部４０は、承認ＤＢ３４に差し戻し（承認不可）情報を記録する。そして、ステップＳ１２６において、メール処理部４０は、コメントＤＢ３６に、承認ＩＤ、メッセージＩＤ、承認者アドレス、コメントを記録する。

以上のように、ステップＳ１２２又はＳ１２６の処理が行われた段階で、図１１の処理を終了し、図９のステップＳ３２に移行する。なお、承認が完了すると、図１９（ｂ）に示すように、承認一覧画面から承認処理されたメールの情報が削除されることになる。

本実施形態では、メール処理部４０が図１１の処理を実行することで、承認者によるメールの承認処理が行われる際に、承認画面（図２０）に証跡メールを表示することができる。これにより、承認者は、証跡メールを用いたメールの承認処理を行うことができるため、メールの承認を正確に行うことが可能となる。また、承認後において、証跡メールの内容をメールに添付して送信することはないため、証跡メールを宛先に送信してしまうことによる不都合の発生を防止することができる。

（承認結果一覧表示処理（図１２））
次に、図１２のフローチャートに沿って、承認結果一覧表示処理について説明する。図１２の処理は、利用者が承認依頼を出したメールが承認されたか否かを確認するための画面を表示する処理である。なお、図１２の処理は、前述のように、図１４（ａ）のメール表示画面上で「承認依頼状況閲覧」ボタンが押された段階で実行される処理である。

図１２の処理では、まず、ステップＳ１５２において、メール処理部４０が、クライアント２０の利用者に対応する承認者を利用者認証ＤＢ３０から取得する。次いで、ステップＳ１５４では、メール処理部４０が、承認者の承認ＤＢ３４から、利用者が発信者である承認結果とメールの件名を取得し、承認依頼状況一覧画面を作成する。なお、承認依頼状況一覧画面は、図２２に示すような画面である。

次いで、ステップＳ１５６では、メール処理部４０は、承認依頼状況一覧画面（図２２）のデータをクライアント２０（表示処理部５０）に対して送信する。なお、表示処理部５０では、データ受信後、図２２の画面を表示部１９３上に表示する。

次いで、ステップＳ１５８では、メール処理部４０は、承認依頼状況一覧画面の中から１つのメールが選択されるまで待機する。この場合、メールが選択された段階で、ステップＳ１６０に移行する。ステップＳ１６０に移行すると、メール処理部４０は、承認ＤＢ３４内のメール情報を用いて、承認結果画面（図２３）を作成し、ステップＳ１６２において、クライアント２０（表示処理部５０）に承認結果画面のデータを送信する。なお、表示処理部５０では、データ受信後、図２３の画面を表示部１９３上に表示する。

なお、承認結果が取り下げ（承認不可）であった場合には、メール処理部４０は、コメントＤＢ３６を参照して、承認ＩＤが一致するコメントが存在しているか否かを確認する。そして、承認ＩＤが一致するコメントが存在していた場合には、メール処理部４０は、図２３の画面にコメントを追記した画面を生成する。

以上の処理により、図１２の処理が終了すると、図９のステップＳ３６に移行することになる。

本実施形態では、メール処理部４０が図１２の処理を実行することで、利用者は承認者による承認結果を閲覧することが可能となる。また、承認結果が取り下げ（承認不可）であった場合で、承認者によってコメントが残されている場合には、利用者は当該コメントを承認結果画面上において確認することができる。

なお、本実施形態では、メールを作成して送信する利用者が利用する端末が、第１の端末に相当し、メールの承認を行う利用者（承認者）が利用する端末が、第２の端末に相当する。すなわち、利用者の実行する処理に応じて同一の端末が第１の端末に相当したり、第２の端末に相当することになる。また、本実施形態では、サーバ１０のメール処理部４０が、受信部、情報送信部、メール送信部の機能を実現している。

以上、詳細に説明したように、本実施形態によると、サーバ１０（メール処理部４０）は、クライアント２０から宛先に対して送信される送信メールの情報（本文等）及び当該送信メールに関連する関連メール（証跡メール）の識別情報（証跡メールのメッセージＩＤ）を受信し（Ｓ６４）、受信したメールを記憶するメールＤＢ３２から、受信した証跡メールのメッセージＩＤに対応するメールの情報（本文等）を読み出し、読み出した証跡メールの情報と受信した送信メールの情報（本文等）を承認者が利用するクライアント２０に対して送信し（Ｓ１１０，Ｓ１１２）、承認者が利用するクライアント２０からメールの送信許可を示す情報（承認可の情報）を受信すると、証跡メールの情報（本文等）を宛先に送信せずに、送信メールの情報（本文）を宛先に送信する（Ｓ１２０）。このように、本実施形態では、証跡メールのメッセージＩＤに基づいて、承認者に対して証跡メールの本文等を提供することができるので、承認者は、証跡メールの本文等を用いてメールの承認処理を正確に行うことができる。また、証跡メールの本文等をメールに添付していないことから、証跡メールが添付された送信メールを宛先に対して送信することもない。これにより、証跡メールを宛先に送信してしまうことによる不都合の発生を防止することができる。このように、本実施形態では、送信メールの承認処理を適切に支援することができる。また、メール送信先のクライアント２０とサーバ１０の間で証跡メールの本文等のやり取りが発生しないため、クライアント２０とサーバ１０間における通信負荷を低減することができる。

また、本実施形態では、メール処理部４０が、メールＤＢ３２に記憶されているメールの情報（件名など）に基づいて、クライアント２０において受信したメールの一覧（証跡メール一覧（図１７））を生成し、生成した証跡メール一覧をクライアント２０に対して送信する。これにより、利用者は、証跡メールを一覧から選択すればよいため、証跡メールを決定する作業を簡素化することができる。

なお、上記実施形態では、ステップＳ５２において、利用者がメールの件名や本文を入力した後に、証跡メールを決定する処理を行う場合について説明したが、これに限られるものではない。例えば、利用者が証跡メールを決定した後に、当該証跡メールの本文に基づいて、メールの件名や本文を作成し、入力するようにしてもよい。

なお、上記実施形態の画面やデータベースは一例である。すなわち、画面の構成やデータベースのデータ構造等を種々変更してもよい。

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

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

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

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

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 第１の端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信し、
受信したメールを記憶する記憶部から、前記第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報を第２の端末に対して送信し、
前記第２の端末から前記送信メールの送信許可を示す情報を受信すると、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信する、処理をコンピュータに実行させるメールに関する処理プログラム。
（付記２） 前記記憶部に記憶されているメールの情報に基づいて、前記第１の端末において受信したメールの一覧を生成し、
生成した前記メールの一覧を前記第１の端末に対して送信する処理を前記コンピュータに更に実行させ、
前記第１の端末において前記メールの一覧の中から選択されたメールの識別情報を前記関連メールの識別情報として受信することを特徴とする付記１に記載のメールに関する処理プログラム。
（付記３） 端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信する受信部と、
前記受信部が受信したメールを記憶する記憶部と、
第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を前記記憶部から読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報を第２の端末に対して送信する情報送信部と、
前記第２の端末から前記送信メールの送信許可を示す情報を受信した場合に、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信するメール送信部と、を備えるメールに関する処理装置。
（付記４） 前記記憶部に記憶されているメールの情報に基づいて、前記第１の端末において受信したメールの一覧を生成する生成部と、
生成した前記メールの一覧を前記第１の端末に対して送信する一覧送信部と、を更に備え、
前記受信部は、前記第１の端末において前記メールの一覧の中から選択されたメールの識別情報を前記関連メールの識別情報として受信することを特徴とする付記３に記載のメールに関する処理装置。
（付記５） 第１の端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信する工程と、
受信したメールを記憶する記憶部から、前記第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報を第２の端末に対して送信する工程と、
前記第２の端末から前記送信メールの送信許可を示す情報を受信した場合に、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信する工程と、をコンピュータが実行することを特徴とするメールに関する処理方法。
（付記６） 前記記憶部に記憶されているメールの情報に基づいて、前記第１の端末において受信したメールの一覧を生成する工程と、
生成した前記メールの一覧を前記第１の端末に対して送信する工程と、を前記コンピュータが更に実行し、
前記受信する工程では、第１の端末において前記メールの一覧の中から選択されたメールの識別情報を前記関連メールの識別情報として受信することを特徴とする付記１に記載のメールに関する処理方法。

１０ サーバ（処理装置）
２０ クライアント（第１の端末、第２の端末）
３２ メールＤＢ（記憶部）
４０ メール処理部（受信部、情報送信部、メール送信部）

Claims (4)

1. 第１の端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信し、
   受信したメールの情報が記憶された記憶部から、前記第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報とを第２の端末に送信し、
   前記第２の端末から前記送信メールの送信許可を示す情報を受信すると、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信する、
   処理をコンピュータに実行させるメール処理プログラム。
2. 前記記憶部に記憶されているメールの情報に基づいて、前記第１の端末において受信したメールの一覧を生成し、
   生成した前記メールの一覧を前記第１の端末に送信する処理を前記コンピュータに更に実行させ、
   前記第１の端末において前記メールの一覧の中から選択されたメールの識別情報を前記関連メールの識別情報として受信することを特徴とする請求項１に記載のメール処理プログラム。
3. 端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信する受信部と、
   前記受信部が受信したメールが記憶された記憶部と、
   第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を前記記憶部から読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報とを第２の端末に送信する情報送信部と、
   前記第２の端末から前記送信メールの送信許可を示す情報を受信した場合に、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信するメール送信部と、
   を備えるメール処理装置。
4. 第１の端末から送信される送信メールの情報及び前記送信メールに関連する関連メールの識別情報を受信する工程と、
   受信したメールが記憶された記憶部から、前記第１の端末から受信した前記関連メールの識別情報に対応する関連メールの情報を読み出し、読み出した前記関連メールの情報と受信した前記送信メールの情報とを第２の端末に送信する工程と、
   前記第２の端末から前記送信メールの送信許可を示す情報を受信した場合に、前記関連メールの情報を前記送信メールの送信先に送信せずに、前記送信メールの情報を前記送信先に送信する工程と、
   をコンピュータが実行することを特徴とするメール処理方法。

Images