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

Description

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

企業等において利用されるメールシステムには、承認機能が設けられている場合がある。この承認機能は、メールを送信する場合に、作成したメールを承認者（上司など）にチェックしてもらい、承認者によって送信が承認された場合にのみ、メール送信できる機能である。なお、承認者は、承認を行う場合、メール本文の内容をチェックするほか、メールの宛先についてもチェックする。

なお、返信メールの宛先を簡単に指定するための技術が知られている（例えば、特許文献１参照）。

特開２０１１−１７５３２２号公報

しかしながら、現状の承認機能においては、承認者がメールの宛先に誤りを発見した場合、宛先の変更をさせるためにメール送信者（承認依頼者）にメールを差し戻す必要があった。また、承認依頼者は宛先を変更した後に、承認者に対して承認依頼を再度行う必要があったため、メールが送信されるまでに手間と時間を要していた。

１つの側面では、本発明は、メール承認作業の簡素化を図ることが可能なメール処理プログラム、メール処理装置及びメール処理方法を提供することを目的とする。

本明細書に記載のメール処理プログラムは、第１端末からメールの承認依頼があった場合に、前記メールの情報を格納部に格納し、第２端末に対して、前記格納部に格納された前記メールの情報を送信し、前記第２端末から前記メールの宛先の変更を受信すると、前記宛先の変更の内容を示す情報を含む変更後の宛先の情報を、前記第１端末において閲覧可能な状態にするとともに、前記メールを前記変更後の宛先に送信する、処理をコンピュータに実行させるメール処理プログラムである。

本明細書に記載のメール処理装置は、第１端末からメールの承認依頼があった場合に、前記メールの情報を格納する格納部と、第２端末に対して、前記格納部に格納された前記メールの情報を送信する第１送信部と、前記第２端末から前記メールの宛先の変更を受信すると、前記宛先の変更の内容を示す情報を含む変更後の宛先の情報を、前記第１端末において閲覧可能な状態にするとともに、前記メールを前記変更後の宛先に送信する第２送信部と、を備えている。

本明細書に記載のメール処理方法は、第１端末からメールの承認依頼があった場合に、前記メールの情報を格納部に格納する工程と、第２端末に対して、前記格納部に格納された前記メールの情報を送信する工程と、前記第２端末から前記メールの宛先の変更を受信すると、前記宛先の変更の内容を示す情報を含む変更後の宛先の情報を、前記第１端末において閲覧可能な状態にするとともに、前記メールを前記変更後の宛先に送信する工程と、をコンピュータが実行するメール処理方法である。

本実施例に記載のメール処理プログラム、メール処理装置及びメール処理方法は、メール承認作業の簡素化を図ることができるという効果を奏する。

一実施形態に係る電子メールシステムの構成を概略的に示す図である。 図２（ａ）は、サーバのハードウェア構成を示す図であり、図２（ｂ）は、クライアントのハードウェア構成を示す図である。 サーバ及びクライアントの機能ブロック図である。 利用者認証ＤＢのデータ構造の一例を示す図である。 メールＤＢのデータ構造の一例を示す図（その１）である。 メールＤＢのデータ構造の一例を示す図（その２）である。 承認ＤＢのデータ構造の一例を示す図である。 返信管理ＤＢのデータ構造の一例を示す図である。 メール処理部の処理を示すフローチャート（その１）である。 メール処理部の処理を示すフローチャート（その２）である。 メール処理部の処理を示すフローチャート（その３）である。 メール処理部の処理を示すフローチャート（その４）である。 メール処理部の処理を示すフローチャート（その５）である。 メール処理部の処理を示すフローチャート（その６）である。 図１５（ａ）は、利用者ＩＤ、パスワード入力画面の一例を示す図であり、図１５（ｂ）は、認証エラー画面の一例を示す図である。 図１６（ａ）は、受信メール一覧画面の一例を示す図（その１）であり、図１６（ｂ）は、受信メール一覧画面の一例を示す図（その２）である。 図１７（ａ）は、メール送信画面（新規作成時）の一例を示す図であり、図１７（ｂ）は、メール送信画面（返信時）の一例を示す図である。 承認一覧画面の一例を示す図である。 承認画面の一例を示す図である。 承認画面の別例を示す図である。 宛先アドレスを削除した場合の承認画面の一例を示す図である。 「宛先追加」ボタンが押された場合の承認画面の一例を示す図である。 宛先アドレスを追加した場合の承認画面の一例を示す図である。 宛先変更を伴う承認処理が行われた場合の承認ＤＢを示す図である。 本文修正を伴う承認処理が行われた場合の承認ＤＢを示す図である。 承認処理後のメールＤＢを示す図である。 承認されたメールのメール表示画面の一例を示す図である。 承認結果一覧画面の一例を示す図である。 承認結果確認画面の一例を示す図である。

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

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

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

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

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

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

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

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

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

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

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

図８には、返信管理ＤＢ３６の一例が示されている。返信管理ＤＢ３６は、返信メールが送信された場合に、返信メールの情報（現記事情報）と、返信元メールの情報（元記事情報）とを格納するデータベースである。返信管理ＤＢ３６は、図８に示すように、「現記事情報」と「元記事情報」とを含み、「現記事情報」として、「メッセージＩＤ」と「発信者アドレス」のフィールドを有し、「元記事情報」として、「メッセージＩＤ」と「発信者アドレス」のフィールドを有している。

この返信管理ＤＢ３６によれば、ある返信メールがどのメールに対する返信であるかが分かる。また、同一の話題に対してメール（返信メール）が複数回やり取りされている場合には、当該複数回やり取りされているメール（同一の話題で紐付いているメール）を遡って追跡することができる。

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

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

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

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

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

一方、ステップＳ１８の判断が肯定された場合、すなわち認証がＯＫであった場合には、ステップＳ２０に移行する。ステップＳ２０では、メール処理部４０は、メールＤＢ３２（図５や図６）を用いて、入力された利用者ＩＤに対応する受信メール一覧画面のデータを生成して、クライアント２０に送信する。この場合の受信メール一覧画面は、図１６（ａ）、図１６（ｂ）に示すような画面であるものとする。具体的には、入力された利用者ＩＤに対応するメールＤＢより、受送信が「受信」であるメール情報を取得し、発信者アドレス、発信日時、メール情報の件名を用いて、メール一覧画面を生成する。図１６では、その際に発信者アドレスを差出人として記載している。なお、図１６（ａ）の受信メール一覧画面が、図５のメールＤＢ３２（利用者が「黒田」の場合）に対応し、図１６（ｂ）の受信メール一覧画面が、図６のメールＤＢ３２（利用者が「田中」の場合）に対応している。クライアント２０の表示処理部５０は、画面のデータを受信した段階で、図１６（ａ）や図１６（ｂ）のメール表示画面を表示部１９３上に表示する。その後は、図１０のステップＳ３０に移行する。

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

ステップＳ３０の判断が肯定されてステップＳ３２に移行すると、メール処理部４０は、メール送信画面を作成し、クライアント２０に送信する。ここで、利用者によって「メール新規作成」ボタンが押された場合には、メール処理部４０は、図１７（ａ）のメール送信画面（新規作成時）を作成し、クライアント２０（表示処理部５０）に対して送信する。また、利用者によって「メール返信」ボタンが押された場合には、メール処理部４０は、図１７（ｂ）のメール送信画面（返信時）を作成し、クライアント２０（表示処理部５０）に対して送信する。なお、図１７（ｂ）のメール送信画面（返信時）においては、宛先、件名の欄にアドレス（返信元メールの送受信者のうち、メール送信しようとしている利用者を以外の利用者のアドレス）や件名（返信元メールの件名の先頭に「Re:」を付加したもの）が入力されており、記事入力画面に返信元メールの本文が引用形式にて入力されている。なお、メールの返信は、例えば、図１６のような受信メール一覧画面より、ある件名をマウスなどのポインティングデバイスのシングルクリックにて選択した後に、「返信」ボタンの押下があった場合に行われる。具体的には、その選択メールに対応するメッセージＩＤと返信を示す情報がサーバ１０のメール処理部４０に送信される。その場合に、選択していたメールのメッセージＩＤを使い、メールＤＢ３２の受信欄からそのメールの情報（件名、本文など）が取得され、その件名にＲｅ：を付加し、本文に引用符が付加されることで、返信時のメール送信画面が生成される。なお、図示しないが、図１６の受信メール一覧画面より、件名をポインティングデバイスのダブルクリックなどで、メールの内容を表示させ、その後で「返信」ボタンを押下しても、同様に図１７（ｂ）の画面が表示される。

次いで、ステップＳ３４では、メール処理部４０が、クライアント２０から本文などのメール情報および送信（承認）要求を受信するまで待機する。なお、利用者が図１７（ａ）や図１７（ｂ）の画面上で宛先や件名、メール本文を入力・修正するなどして、「送信（承認依頼）」ボタンを押すと、入力処理部５２は、該画面上に入力されている情報をメール処理部４０に送信する。

入力処理部５２からメール処理部４０に対してメール本文等の情報が送信されると（ステップＳ３４の判断が肯定されると）、ステップＳ３６に移行する。ステップＳ３６では、メール処理部４０が、利用者認証ＤＢ３０から、メールの送信者に対応する承認者のアドレスを取得する。次いで、ステップＳ３８では、メール処理部４０は、承認者のアドレスに対応する承認ＤＢ３４（図７）に、メール情報を記録する。この場合、メール処理部４０は、承認ＤＢ３４「承認結果」のフィールドには、「承認依頼中」と入力するものとする（例えば、図７の最上段のレコード参照）。なお、承認対象のメールが、あるメールに対する返信メールである場合には、メール処理部４０は、ステップＳ３８において、そのメールのメッセージＩＤと発信者アドレスの情報と、返信元のメールのメッセージＩＤと発信者アドレスの情報を返信管理ＤＢ３６に格納する。

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

ステップＳ４２に移行すると、メール処理部４０は、利用者ＩＤに対応する承認ＤＢ３４から、未承認である「承認依頼中」のメール情報を取得し、承認一覧画面を作成する。図１８には、図７の承認ＤＢ３４に基づいて作成された承認一覧画面の一例が示されている。

次いで、ステップＳ４４では、メール処理部４０が、承認者によって承認一覧画面上のメールが選択されるまで待機する。なお、利用者（承認者）は、図１８の画面において、承認処理を行うメールを入力部１９５を用いて選択する。そして、入力処理部５２は、メールの選択情報をメール処理部４０に対して送信する。上記のようにしてメールが選択されると、メール処理部４０は、図１１のステップＳ５０に移行する。なお、ここでは、承認者が、図１８の件名「○○システムについて」のメール（メッセージＩＤ：system5@xxx.ww）を選択したものとする。

図１１のステップＳ５０に移行すると、メール処理部４０は、選択されたメールの情報を承認ＤＢ３４から取得する。次いで、ステップＳ５２では、メール処理部４０が、取得したメールのメッセージＩＤが返信管理ＤＢ３６の現記事情報のメッセージＩＤ欄に含まれているか否かを判断する。すなわち、メール処理部４０は、選択したメールが、あるメールに対する返信メールであるかを判断する。ここでの判断が否定された場合には、ステップＳ６６に移行するが、肯定された場合にはステップＳ５４に移行する。なお、図８の返信管理ＤＢ３６には、メッセージＩＤ：system5@xxx.wwが存在していないので、ここでの判断は否定され、ステップＳ６６に移行する。

ステップＳ６６に移行すると、メール処理部４０は、現在の宛先アドレスに宛先更新ボタン（「宛先追加」ボタン及び「削除」ボタン）を設けた承認画面を作成する。そして、ステップＳ６２では、メール処理部４０が、承認画面（図１９）のデータを承認者が利用するクライアント２０（表示処理部５０）に対して送信する。この場合、表示処理部５０は、図１９の画面を表示部１９３上に表示する。その後は、図１２のステップＳ７０に移行する。

なお、承認依頼に対応するメール（承認依頼者のアドレス：tanaka@xxx.ww）のメッセージＩＤが「system6@xxx.ww」であった場合には、図１１の処理において、以下のような処理が実行される。

まず、ステップＳ５２の処理では、メッセージＩＤ：system6@xxx.wwが返信管理ＤＢ３６（図８）の現記事情報に含まれているので、ここでの判断が肯定され、ステップＳ５４に移行する。そして、ステップＳ５４では、メール処理部４０は、対応する返信元情報のメッセージＩＤを取得する。現記事情報のメッセージＩＤが「system6@xxx.ww」であるので、対応する返信元情報のメッセージＩＤとしては「system4@xxx.ww」が取得される。

次いで、ステップＳ５６では、メール処理部４０が、返信元情報のメッセージＩＤの発信者が利用者アドレス（承認依頼者のアドレス）と同一か否かを判断する。この場合、返信元情報のメッセージＩＤ「system4@xxx.ww」の発信者アドレスは「satou@xxx.ww」であり、承認依頼者のアドレス「tanaka@xxx.ww」と異なるため、ステップＳ５６の判断は否定され、ステップＳ６４に移行する。そして、ステップＳ６４では、メール処理部４０が、返信元情報のメッセージＩＤが返信管理ＤＢ３６の現記事情報のメッセージＩＤ欄に含まれているか否かを判断する。なお、メッセージＩＤ：system4@xxx.wwは、図８の返信管理ＤＢ３６の現記事情報に含まれているので、ここでの判断は肯定され、ステップＳ５４に戻る。

ステップＳ５４に戻ると、メール処理部４０は、対応する返信元情報のメッセージＩＤを取得する。現記事情報がメッセージＩＤ：system4@xxx.wwの場合には、対応する返信元情報のメッセージＩＤとして「system3@xxx.ww」が取得される。次いで、ステップＳ５６では、メール処理部４０が、返信元情報のメッセージＩＤの発信者が利用者アドレス（承認依頼者のアドレス）と同一か否かを判断する。なお、メッセージＩＤ：system3@xxx.wwの場合、発信者アドレスは「kuroda@xxx.ww」であり、承認依頼者のアドレス「tanaka@xxx.ww」と異なるため、ステップＳ５６の判断は否定され、再度ステップＳ６４に移行する。そして、ステップＳ６４では、メール処理部４０が、返信元情報のメッセージＩＤが返信管理ＤＢ３６の現記事情報のメッセージＩＤ欄に含まれているか否かを判断する。なお、メッセージＩＤ：system3@xxx.wwの場合には、返信管理ＤＢ３６の現記事情報のメッセージＩＤに含まれているので、ここでの判断は肯定され、ステップＳ５４に戻る。

ステップＳ５４に戻ると、メール処理部４０は、再度、対応する返信元情報のメッセージＩＤを取得する。現記事情報がメッセージＩＤ：system3@xxx.wwの場合には、対応する返信元情報のメッセージＩＤとして「system2@xxx.ww」が取得される。

次いで、ステップＳ５６では、メール処理部４０が、返信元情報のメッセージＩＤの発信者が利用者アドレス（承認依頼者のアドレス）と同一か否かを判断する。なお、メッセージＩＤ：system2@xxx.wwの場合、発信者アドレスは「tanaka@xxx.ww」であり、承認依頼者のアドレス「tanaka@xxx.ww」と同一であるため、ステップＳ５６の判断は肯定され、ステップＳ５８に移行する。

なお、ステップＳ５４→Ｓ５６（否定）→Ｓ６４（肯定）→Ｓ５４→…のループでは、承認依頼メールに紐付いている返信元メールの中から、承認依頼者が直前に送信したメールを探し出しているといえる。すなわち、このようなメールが存在していた場合に、ステップＳ５８に移行することになる。

ステップＳ５８に移行すると、メール処理部４０は、メールＤＢ３２からその返信元情報のメッセージＩＤに対応する宛先アドレスを取得する。メッセージＩＤ：system2@xxx.wwの場合、承認依頼者「tanaka@xxx.ww」のメールＤＢ３２（図６）から宛先アドレス「satou@xxx.ww」と「kuroda@xxx.ww」が取得される。

次いで、ステップＳ６０では、メール処理部４０が、取得した宛先アドレスの情報と、現在の宛先アドレスに宛先更新ボタン（「宛先追加」ボタン及び「削除」ボタン）を設けた承認画面（図２０）を作成する。なお、取得した宛先アドレスの情報は、図２０において「関連メールのうち、田中さんから発信された直前のメールの宛先」として表示される。そして、ステップＳ６２では、メール処理部４０が、承認画面のデータを承認者が利用するクライアント２０（表示処理部５０）に対して送信する。この場合、表示処理部５０は、図２０の画面を表示部１９３上に表示する。その後は、図１２のステップＳ７０に移行する。なお、承認者は、図２０の承認画面を参照することで、承認依頼者が同一の話題に関するメールを前回送信した場合の宛先と今回の宛先とを比較することができる。これにより、承認者による承認処理を適切に支援することが可能である。

ところで、ステップＳ６４の判断が否定された場合、すなわち、承認依頼メールに紐付いている返信元メールの中に、承認依頼者が直前に送信したメールが存在していなかった場合には、ステップＳ６６に移行する。ステップＳ６６に移行すると、メール処理部４０は、前述と同様、図２０の承認画面（直前のメール宛先の表示が無いもの）を作成し、ステップＳ６２において、作成した承認画面のデータを承認者が利用するクライアント２０（表示処理部５０）に対して送信する。その後は、図１２のステップＳ７０に移行する。

なお、本実施形態では、ステップＳ６２において、承認者が利用するクライアント２０に対して図１９の承認画面が送信されたとして、説明を続ける。

図１２のステップＳ７０に移行すると、メール処理部４０は、宛先の削除要求をクライアント２０から受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ７４に移行し、メール処理部４０は、宛先の追加要求をクライアント２０から受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ８２に移行し、メール処理部４０が、承認結果を受信したか否かを判断する。ここでの判断が否定された場合には、ステップＳ７０に戻る。このステップＳ７０→Ｓ７４→Ｓ８２→Ｓ７０…のループが実行されている間は、メール処理部４０は、承認者によって図１９の画面上の「削除」、「宛先追加」、「送信（承認）」、「変更送信」、「却下」ボタンのいずれかが押されるまで待機しているといえる。

メール処理部４０が上記ループ（Ｓ７０、Ｓ７４、Ｓ８２）を実行している間に、承認者によっていずれかの宛先アドレスに対応する「削除」ボタンが押されると、ステップＳ７０の判断が肯定され、ステップＳ７２に移行する。

ステップＳ７２に移行すると、メール処理部４０は、「削除」ボタンが押されたアドレス（削除アドレス）を網掛け表示した承認画面（図２１）を作成する。また、メール処理部４０は、作成した画面のデータを承認者が利用するクライアント２０（表示処理部５０）に対して送信する。なお、図２１には、承認者が「商標部 山本」のアドレスに対応する「削除」ボタンを押したときの承認画面の例が示されている。表示処理部５０は、図２１の画面のデータを受信した段階で、当該画面を表示部１９３上に表示する。これにより、承認者は、削除したアドレスを確認した上で、承認作業を続行することができる。

一方、上記ループ（Ｓ７０、Ｓ７４、Ｓ８２）を繰り返している間に、承認者によって「宛先追加」ボタンが押されると、ステップＳ７４の判断が肯定され、ステップＳ７６に移行する。

ステップＳ７６に移行すると、メール処理部４０は、利用者認証ＤＢ３０を用いて現在の宛先に含まれていないアドレスの一覧画面（図２２の画面１５０）を作成する。また、メール処理部４０は、作成した画面のデータを承認者が利用するクライアント２０（表示処理部５０）に送信する。この場合、表示処理部５０は、図２２の画面を表示部１９３上に表示する。承認者は、図２２の一覧画面１５０において、追加したいアドレスの「選択」欄にチェックを入れ、「追加」ボタンを押すことで、追加したいアドレスを選択することができる。

次いで、ステップＳ７８では、メール処理部４０が、承認者が利用するクライアント２０（入力処理部５２）からアドレスの選択を受信するまで待機する。メール処理部４０は、アドレスの選択情報をクライアント２０からを受信した段階で、ステップＳ８０に移行する。ステップＳ８０では、メール処理部４０が、選択されたアドレスを追加表示した承認画面（図２３）を作成し、当該画面のデータを承認者が利用するクライアント２０に送信する。なお、図２３には、承認者が「ライセンス部 山田」のアドレスを追加したときの承認画面の例が示されている。表示処理部５０は、画面のデータを受信した段階で、図２３の画面を表示部１９３上に表示する。これにより、承認者は、追加したアドレスを確認した上で、承認作業を続行することができる。

ところで、ループ（Ｓ７０、Ｓ７４、Ｓ８２）を繰り返している間に、承認者によって「送信（承認）」、「変更送信」、「却下」のいずれかのボタンが押されると、ステップＳ８２の判断が肯定され、図１３のステップＳ９０に移行する。なお、承認者は、宛先の追加・削除、メール本文の修正を行った後に、その内容を反映させたメールの送信を承認する場合には、「変更送信」ボタンを押すものとする。また、承認者は、承認依頼者から承認依頼のあったメールの宛先や本文を変更せずに承認する場合には「送信（承認）」ボタンを押すものとする。また、承認者は、「変更送信」ボタンや「却下」ボタンを押す場合には、その理由等を承認画面のコメント欄に入力することができる。

図１３のステップＳ９０では、メール処理部４０は、承認結果を承認ＤＢ３４に記録する。なお、承認結果が却下の場合や宛先等が変更された場合には、承認者が入力したコメントがあれば、承認ＤＢ３４の「コメント」フィールドに記録する。また、承認者によって宛先が修正された場合には、承認ＤＢ３４の「修正後宛先」フィールドに修正後の宛先を記録する。なお、図２３の状態で承認者が「変更送信」ボタンを押した場合には、承認ＤＢ３４が、図７の状態から図２４の状態に変更される（変更部分は太字にて記載。ただし、「承認結果」フィールドは「承認依頼中」のままである）。

次いで、ステップＳ９２では、メール処理部４０が、承認結果がＯＫであったか否か、すなわち、承認者が「送信（承認）」ボタン及び「変更送信」ボタンのいずれかを押したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ９４に移行する。

ステップＳ９４に移行すると、メール処理部４０は、承認者が「変更送信」ボタンを押したか否かを判断する。ここでの判断が肯定された場合には、ステップＳ９５に移行し、メール処理部４０は、メール本文が変更（修正）されていれば、承認ＤＢ３４の「修正後本文」のフィールドに変更後のメール本文を記録する。図２５には、メール本文が変更（修正）された場合の承認ＤＢ３４の例が示されている（ただし、「承認結果」フィールドは「承認依頼中」のままである）。

次いで、ステップＳ９６では、メール処理部４０が、修正された宛先及び／又はメール本文とともに承認されたメールの情報を、承認依頼者のメールＤＢ３２（送信区分）に格納する。図２６には、図６のメールＤＢ３２に新たなメール情報（メッセージＩＤ：system5@xxx.wwのメール情報）が格納（追加）された状態が示されている。

また、ステップＳ９８では、メール処理部４０が、修正された宛先のメールＤＢ３２（受信区分）に承認者が承認したメールの情報を格納する。なお、ステップＳ９８の処理が行われることで、メールが承認依頼者から宛先に対して送信されたことになる。したがって、メールを受信した利用者が、メールＤＢ３２に格納されたメールを受信メール一覧画面（図１６（ａ）等）上で選択することで、クライアント２０の表示部１９３上には、図２７に示すようなメール表示画面が表示されることになる。その後は、メール処理部４０は、ステップＳ１００に移行し、承認ＤＢ３４の「承認結果」フィールドを「送信（承認）」に変更するとともに、コメントを承認ＤＢ３４のコメント欄に記録する。そして、図１４のステップＳ１１０に移行する。

一方、図１３のステップＳ９４の判断が否定された場合、すなわち、承認者が「承認（送信）」ボタンを押した場合には、ステップＳ１０２に移行する。そして、ステップＳ１０２では、メール処理部４０は、承認依頼者のメールＤＢ３２（送信区分）に、承認者によって承認されたメールの情報を格納する。また、ステップＳ１０４では、メール処理部４０が、宛先のメールＤＢ３２（受信区分）に承認者によって承認されたメールの情報を格納する。なお、ステップＳ１０４により、メールが承認依頼者から宛先に対して送信されたことになる。

一方、図１３のステップＳ９２の判断が否定された場合、すなわち、承認結果がＮＧ（却下）であった場合には、ステップＳ１０６に移行し、メール処理部４０は、承認ＤＢ３４の「承認結果」フィールドを「差戻し」に変更する。また、コメントがあれば、承認ＤＢ３４のコメント欄に記録する。その後は、図１４のステップＳ１１０に移行する。なお、前述のように、図１０のステップＳ４０の判断が否定された場合、すなわち、利用者が承認処理要求を出していない場合にも、図１４のステップＳ１１０に移行する。

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

ステップＳ１１０の判断が肯定されてステップＳ１１２に移行すると、メール処理部４０は、承認結果表示要求を出した利用者（「承認依頼状況閲覧」ボタンを押した利用者）の承認者のアドレスを、利用者認証ＤＢ３０から取得する。

次いで、ステップＳ１１４では、メール処理部４０が、承認者の承認ＤＢ３４から、利用者が発信者である承認結果とメールの件名を取得し、承認結果一覧画面を作成する。なお、承認結果一覧画面は、図２８に示すような画面である。

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

次いで、ステップＳ１１８では、メール処理部４０は、承認結果一覧画面の中から１つのメールが選択されるまで待機する。この場合、メールが選択された段階で、ステップＳ１２０に移行する。ステップＳ１２０に移行すると、メール処理部４０は、承認ＤＢ３４内のメール情報を用いて、承認結果確認画面（図２９）を作成する。この場合、メール処理部４０は、承認ＤＢ３４の「修正後宛先」、「コメント」、「修正後本文」の各フィールドに情報が記録されている場合には、その情報を承認結果確認画面に反映させるものとする。そして、次のステップＳ１２２では、メール処理部４０は、クライアント２０（表示処理部５０）に対して、承認結果確認画面のデータを送信する。なお、表示処理部５０では、データ受信後、図２９の画面を表示部１９３上に表示する。

ステップＳ１２２の処理の後、又はステップＳ１１０の判断が否定されてステップＳ１２４に移行すると、メール処理部４０は、ログアウト要求を受信したか否かを判断する。ここでの判断が否定された場合には、図１０のステップＳ３０に戻り、ステップＳ３０以降の処理・判断を繰り返す。そして、ステップＳ１２４の判断が肯定された場合、すなわち、利用者が図１６（ａ）等の画面上で「ログアウト」ボタンを押したという情報を、メール処理部４０が入力処理部５２から受信した場合、図９〜図１４の全処理が終了する。

なお、図９〜図１４の処理では、利用者認証後は、利用者からの要求がない限り、ステップＳ３０、Ｓ４０、Ｓ１１０、Ｓ１２４の判断を繰り返す。そして、利用者からメール作成要求が出された場合に、メール処理部４０は、ステップＳ３２〜Ｓ３８を実行し、利用者から承認処理要求が出された場合に、メール処理部４０は、ステップＳ４２〜Ｓ１１０を実行する。また、利用者から承認結果表示要求が出された場合に、メール処理部４０は、ステップＳ１１２〜Ｓ１２２を実行し、利用者からログアウト要求が出された場合に、メール処理部４０は、図９〜図１４の全処理を終了する。

なお、上記説明から分かるように、サーバ１０のメール処理部４０により、承認者のクライアント２０に対して、承認依頼に対応するメールを送信する第１送信部としての機能が実現されている。また、メール処理部４０により、承認者のクライアント２０からメールの宛先の変更を受信した場合に、宛先を変更した旨の情報を承認依頼者のクライアント２０において閲覧可能な状態にするとともに、メールを変更後の宛先に送信する第２送信部、としての機能が実現されている。

以上、詳細に説明したように、本実施形態によると、サーバ１０のメール処理部４０は、承認依頼者のクライアント２０から承認者のクライアント２０に対してメールの承認依頼があった場合に、当該メール情報を承認ＤＢ３４に格納し（Ｓ３８）、承認者のクライアント２０に対して、承認依頼に対応するメール（承認画面）を送信する（Ｓ６２）。そして、メール処理部４０は、承認者のクライアント２０からメールの宛先の変更（追加／削除）を受信した場合に、宛先を変更した旨の情報を承認依頼者のクライアント２０において閲覧可能な状態にする（修正後の宛先やコメントを承認ＤＢ３４に格納する）（Ｓ９０）とともに、メールを変更後の宛先に送信する（Ｓ９８）。これにより、本実施形態では、承認依頼に対応するメールの宛先の変更が必要な場合であっても、承認依頼者に差し戻し、承認依頼者が宛先を変更した後、再度承認処理を行うという、承認者と承認依頼者との間のやりとりを省略することができる。したがって、本実施形態では、メール承認作業の簡素化を図ることが可能となる。

また、本実施形態では、メール処理部４０は、承認者のクライアント２０から承認依頼に対応するメールの宛先の変更とともにメールの本文の変更を受信した場合に、変更後のメールの本文情報を承認依頼者のクライアント２０において閲覧可能な状態にする（修正後本文を承認ＤＢ３４に格納する）（Ｓ９５）とともに、変更後のメールの本文を変更後の宛先に送信する（Ｓ９８）。これにより、本実施形態では、承認依頼に対応するメールの本文の変更（例えば宛先の変更に基づくメール本文の一部の変更など）が必要な場合であっても、承認依頼者に差し戻し、承認依頼者が宛先を変更した後、再度承認処理を行うという煩雑な処理を行わなくても、承認者が本文を修正して、変更後の宛先にメールを送信することができる。したがって、本実施形態では、この点からも、メール承認作業の簡素化を図ることが可能とである。

また、本実施形態では、メール処理部４０は、承認依頼に対応するメールが返信メールである場合に、当該承認依頼に対応するメールに紐付く返信元メールのうち、承認依頼者が直前に送信したメールを特定し（Ｓ５４，Ｓ５６（肯定））、特定されたメールの情報を承認者のクライアント２０に対して送信する（Ｓ６０）。これにより、本実施形態では、承認者は、承認依頼者が送信しようとしているメールの宛先と、送信済のメールの宛先とを比較して承認作業を行うことができるので、メール承認作業をより簡素化することができる。

なお、上記実施形態では、メール処理部４０は、承認依頼に対応するメールに紐付く返信元メールのうち、承認依頼者が直前に送信したメールを特定して、当該メールの宛先を承認画面に表示することとした。しかしながら、これに限られるものではなく、例えば、メール処理部４０は、承認依頼に対応するメールの返信元メールの送受信者（承認依頼者を除く）の情報を承認者のクライアント２０に対して送信することとしてもよい。その他、メール処理部４０は、承認依頼に対応するメールに紐付く返信元メールのいずれかの送受信者（承認依頼者を除く）の情報を承認者のクライアント２０に対して送信することとしてもよい。

なお、上記実施形態では、メール処理部４０は、ステップＳ５４〜Ｓ６４の処理を行うことで、図２０のような承認画面を生成する場合について説明したが、これに限られるものではない。例えば、メール処理部４０は、ステップＳ５４〜Ｓ６４の処理を省略して、いずれの場合にも図１９のような承認画面を生成するようにしてもよい。この場合、図３の返信管理ＤＢ３６を省略することとしてもよい。

なお、上記実施形態では、承認画面において承認者がメール本文を修正できる場合について説明したが、これに限られるものではなく、承認者は、宛先のみを修正できるようにしてもよい。また、上記実施形態では、サーバ１０側のメール処理部４０にて、各種画面を生成し、クライアント２０に送信しているが、画面生成のための情報をクライアント２０に送信し、クライアント２０がその情報を用いて画面を生成・表示してもよい。

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

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

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

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

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 第１端末から第２端末に対してメールの承認依頼があった場合に、当該メール情報を格納部に格納し、
前記第２端末に対して、前記承認依頼に対応するメールを送信し、
前記第２端末から前記メールの宛先の変更を受信した場合に、前記宛先を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記メールを変更後の宛先に送信する、処理をコンピュータに実行させることを特徴とするメール処理プログラム。
（付記２） 前記メールを変更後の宛先に送信する処理では、前記第２端末から、前記メールの宛先の変更とともに前記メールの本文の変更を受信した場合に、前記メールの本文を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記変更後のメールの本文を前記変更後の宛先に送信することを特徴とする付記１に記載のメール処理プログラム。
（付記３） 前記承認依頼に対応するメールが、あるメールに関連するメールである場合に、前記関連するメールの宛先の情報を取得する処理を前記コンピュータに更に実行させ、
前記承認依頼に対応するメールを送信する処理では、前記関連するメールの宛先の情報を前記第２端末に対して送信することを特徴とする付記１又は２に記載のメール処理プログラム。
（付記４） 前記関連するメールは、前記承認依頼に対応するメールに返信元として紐付くメールのうち、前記第１端末から送信されたメールであることを特徴とする付記３に記載のメール処理プログラム。
（付記５） 第１端末から第２端末に対してメールの承認依頼があった場合に、当該メール情報を格納する格納部と、
前記第２端末に対して、前記承認依頼に対応するメールを送信する第１送信部と、
前記第２端末から前記メールの宛先の変更を受信した場合に、前記宛先を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記メールを変更後の宛先に送信する第２送信部と、を備えるメール処理装置。
（付記６） 前記第２送信部は、前記第２端末から、前記メールの宛先の変更とともに前記メールの本文の変更を受信した場合に、前記メールの本文を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記変更後のメールの本文を前記変更後の宛先に送信することを特徴とする付記５に記載のメール処理装置。
（付記７） 前記承認依頼に対応するメールが、あるメールに関連するメールである場合に、前記関連するメールの宛先の情報を取得する取得部を更に備え、
前記第１送信部は、前記関連するメールの宛先の情報を前記第２端末に対して送信することを特徴とする付記５又は６に記載のメール処理装置。
（付記８） 前記関連するメールは、前記承認依頼に対応するメールに返信元として紐付くメールのうち、前記第１端末から送信されたメールであることを特徴とする付記７に記載のメール処理装置。
（付記９） 第１端末から第２端末に対してメールの承認依頼があった場合に、当該メール情報を格納部に格納する工程と、
前記第２端末に対して、前記承認依頼に対応するメールを送信する工程と、
前記第２端末から前記メールの宛先の変更を受信した場合に、前記宛先を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記メールを変更後の宛先に送信する工程と、をコンピュータが実行することを特徴とするメール処理方法。
（付記１０） 前記メールを変更後の宛先に送信する工程では、前記第２端末から、前記メールの宛先の変更とともに前記メールの本文の変更を受信した場合に、前記メールの本文を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記変更後のメールの本文を前記変更後の宛先に送信することを特徴とする付記９に記載のメール処理方法。
（付記１１） 前記承認依頼に対応するメールが、あるメールに関連するメールである場合に、前記関連するメールの宛先の情報を取得する工程を前記コンピュータが更に実行し、
前記承認依頼に対応するメールを送信する工程では、前記関連するメールの宛先の情報を前記第２端末に対して送信することを特徴とする付記９又は１０に記載のメール処理方法。
（付記１２） 前記関連するメールは、前記承認依頼に対応するメールに返信元として紐付くメールのうち、前記第１端末から送信されたメールであることを特徴とする付記１１に記載のメール処理方法。

１０ サーバ（メール処理装置）
２０ クライアント（第１端末、第２端末）
３４ 承認ＤＢ（格納部）
４０ メール処理部（第１送信部、第２送信部）

Claims (6)

1. 第１端末からメールの承認依頼があった場合に、前記メールの情報を格納部に格納し、
   第２端末に対して、前記格納部に格納された前記メールの情報を送信し、
   前記第２端末から前記メールの宛先の変更を受信すると、前記宛先の変更の内容を示す情報を含む変更後の宛先の情報を、前記第１端末において閲覧可能な状態にするとともに、前記メールを前記変更後の宛先に送信する、
   処理をコンピュータに実行させることを特徴とするメール処理プログラム。
2. 前記メールを前記変更後の宛先に送信する処理では、前記第２端末から、前記メールの宛先の変更とともに前記メールの本文の変更を受信すると、前記メールの本文を変更した旨の情報を前記第１端末において閲覧可能な状態にするとともに、前記変更後のメールの本文を前記変更後の宛先に送信することを特徴とする請求項１に記載のメール処理プログラム。
3. 前記格納部に格納された前記メールの情報が、あるメールに関連するメールの情報である場合に、前記関連するメールの宛先の情報を取得する処理を前記コンピュータに更に実行させ、
   前記格納部に格納された前記メールの情報を送信する処理では、前記関連するメールの宛先の情報を前記第２端末に対して送信することを特徴とする請求項１又は２に記載のメール処理プログラム。
4. 前記関連するメールは、前記格納部に格納された前記メールの情報においてメールの返信元とされるメールのうち、前記第１端末から送信されたメールであることを特徴とする請求項３に記載のメール処理プログラム。
5. 第１端末からメールの承認依頼があった場合に、前記メールの情報を格納する格納部と、
   第２端末に対して、前記格納部に格納された前記メールの情報を送信する第１送信部と、
   前記第２端末から前記メールの宛先の変更を受信すると、前記宛先の変更の内容を示す情報を含む変更後の宛先の情報を、前記第１端末において閲覧可能な状態にするとともに、前記メールを前記変更後の宛先に送信する第２送信部と、を備えるメール処理装置。
6. 第１端末からメールの承認依頼があった場合に、前記メールの情報を格納部に格納する工程と、
   第２端末に対して、前記格納部に格納された前記メールの情報を送信する工程と、
   前記第２端末から前記メールの宛先の変更を受信すると、前記宛先の変更の内容を示す情報を含む変更後の宛先の情報を、前記第１端末において閲覧可能な状態にするとともに、前記メールを前記変更後の宛先に送信する工程と、
   をコンピュータが実行することを特徴とするメール処理方法。
   

Images