JP2013210700A - メール処理プログラム，メール処理装置およびメール処理方法 - Google Patents

Abstract

【課題】電子メールの承認において，同様の問題を有する電子メールを減らし，承認者の手間を軽減する技術を提供する。
【解決手段】サーバ１０において，メッセージ作成処理部１４は，メールの作成要求を受け付ける。メッセージ作成処理部１４は，作成するメールが返信メールである場合に，メール間の返信関係を管理する返信管理情報を参照して，作成する返信メールの返信元メールと同じスレッドのメールである関連メールを抽出する。メッセージ作成処理部１４は，メールに対して承認者が記述したコメントを管理するコメント管理情報を参照して，抽出された関連メールに対するコメントを取得する。メッセージ作成処理部１４は，取得されたコメントを提示する画面を含む，メールの作成画面を生成し，クライアント２０に出力する。
【選択図】図２

Description

本発明は，電子メールの管理・制御の処理を行うメール処理プログラム，メール処理装置およびメール処理方法に関するものである。

近年，電子メールの利用が一般化し，多くの電子メールのやり取りが行われるようになった。電子メールは複数の人間と同時に情報を交換できる便利なツールではあるが，電子メールによって，秘密情報が外部に流出してしまうという事件も発生している。また，例えば企業組織等において，業務を行っているふりをして，業務には関係の無いプライベートな電子メールのやり取りを行うことなどもできる。そのため，メールシステムに電子メールの監視機能を持たせることが必要となってきている。

このような問題に対処できる技術として，ユーザが電子メールを送信する場合において，特定の承認者が送信する電子メールの承認を行う機能を有するメールシステムの技術がある。

例えば，企業などの組織のメールシステムにおいて，従業員が送信する電子メールに対して，承認者である上司による承認処理が行われるものとする。電子メールを作成した従業員は，承認者である上司に対して，作成した電子メールの承認を依頼する。承認者である上司は，従業員から依頼された電子メールの内容をチェックし，送信の可／不可を判断する。承認者である上司に送信可とされた電子メールは，送信先に送信される。承認者である上司は，送信を不可とする場合に，送信を不可とする理由や対策などのコメントを添えて，電子メールを従業員に差し戻す。電子メールを差し戻された従業員は，承認者である上司からのコメントを参照して，差し戻された電子メールを修正し，再度承認を依頼する。

なお，ルール違反となるメールの特徴を示す特徴データを用意し，ユーザが送信するメールがその特徴データのルールに違反すると判定された場合に，違反するとされたルールの文言や，事故事例，回避方法をユーザに提示する技術が知られている。また，電子メールの事後監査を行う際に，同一スレッドの電子メールを，監査者が一括で監査できるようにする技術が知られている。また，クライアントとメールサーバとの間に電子メールを所定期間保留するためのメール保留サーバを設けて，メール保留サーバに保留された電子メールを，メール保留サーバやクライアントの操作者が削除できるようにする技術が知られている。

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

例えば，複数のユーザ同士が，同じ案件について返信で電子メールのやり取りを行う場合において，あるユーザが送信しようとした電子メールが，ある理由から，承認者によって差し戻しされたものとする。このユーザは，承認者のコメントに従って電子メールを修正し，送信する。その後，別のユーザが送信しようとした電子メールが，前のユーザと同じ理由で差し戻しされたものとする。このとき，承認者は，前のユーザと同様のコメントを再度作成することになる。

このように，複数のユーザが返信で電子メールをやり取りする場合には，それぞれのユーザが同じような問題を有する電子メールを作成する可能性が高く，そのたびに同じ内容のコメントを作成することは，承認者にとって大きな手間となる。そのため，同様の問題を有する電子メールを減らして，承認者の手間を軽減することが望まれている。

一側面では，本発明は，電子メールの承認において，同様の問題を有する電子メールを減らし，承認者の手間を軽減する技術を提供することを目的とする。

１態様では，開示するプログラムは，コンピュータを，次のように機能させる。すなわち，前記プログラムは，前記プログラムがインストールされて実行されるコンピュータに，電子メールの作成の要求を受け付け，該電子メールが返信である場合に，記憶部に記憶された，電子メール間の返信関係を管理する返信管理情報を参照して，該電子メールの返信元の電子メールと同じスレッドの電子メールである第１の関連メールを抽出し，記憶部に記憶された，電子メールに対して過去に記述されたコメントを管理するコメント管理情報を参照して，第１の関連メールに対する第１のコメントを取得し，第１のコメントを提示する画面を含む，作成する電子メールの作成画面を生成し，生成された作成画面を出力する処理を実行させる。

１態様では，電子メールの承認において，同様の問題を有する電子メールを減らし，承認者の手間を軽減できる。

本実施の形態によるメールシステムの構成例を示す図である。 本実施の形態によるサーバとクライアントの機能構成例を示す図である。 本実施の形態によるサーバやクライアントを実現するコンピュータのハードウェア構成例を示す図である。 本実施の形態による利用者ＤＢの例を示す図である。 本実施の形態によるメールＤＢの例を示す図である。 本実施の形態による承認管理ＤＢの例を示す図である。 本実施の形態によるコメントＤＢの例を示す図である。 本実施の形態による返信管理ＤＢの例を示す図である。 本実施の形態によるメール表示画面の例を示す図である。 本実施の形態によるメッセージ作成画面の例を示す図である。 本実施の形態による承認一覧画面の例を示す図である。 本実施の形態による承認処理画面の例を示す図である。 本実施の形態による承認不可メール一覧画面の例を示す図である。 本実施の形態による修正画面の例を示す図である。 本実施の形態のサーバによるメール処理フローチャートである。 本実施の形態のサーバによるメール処理フローチャートである。 本実施の形態のサーバによるメッセージ作成処理フローチャートである。 本実施の形態のサーバによる承認処理フローチャートである。 本実施の形態のサーバによる承認処理フローチャートである。 本実施の形態のサーバによる承認結果対応処理フローチャートである。 本実施の形態のサーバによる承認結果対応処理フローチャートである。 本実施の形態の関連コメント取得部による関連コメント取得処理フローチャートである。 実施の形態のクライアントによるメール処理フローチャートである。 実施の形態のクライアントによるメール処理フローチャートである。 本実施の形態のクライアントによるメッセージ作成処理フローチャートである。 本実施の形態のクライアントによる承認処理フローチャートである。 本実施の形態のクライアントによる承認結果対応処理フローチャートである。

以下，本実施の形態について，図を用いて説明する。

図１は，本実施の形態によるメールシステムの構成例を示す図である。

図１に示すメールシステムは，サーバ１０と複数のクライアント２０を有する。サーバ１０は，各クライアント２０の電子メールを管理し，それらの電子メールの送受信を制御するコンピュータである。クライアント２０は，電子メールを利用するユーザのコンピュータである。なお，以下では，電子メールを単にメールとも呼ぶ。

図１に示すメールシステムにおいて，サーバ１０と各クライアント２０とは，ＬＡＮ（Local Area Network）やインターネットなどのネットワーク３０によって，通信が可能である。なお，図１に示すメールシステムは，ある組織内のメールシステムであり，図１に示すメールシステムの外部には，さらに別のネットワーク（図示省略）を介して，メールが送受信される。

本実施の形態において，図１に示すメールシステムは，Ｗｅｂメールシステムであるものとする。すなわち，各クライアント２０の送信メールや受信メールは，サーバ１０で管理保存される。また，サーバ１０は，各クライアント２０に対して，メールを閲覧・作成する画面を提供する。ユーザは，クライアント２０のブラウザでサーバ１０にアクセスし，サーバ１０が提供するメールの閲覧画面や作成画面をディスプレイに表示することで，メールの閲覧や作成を行う。

また，本実施の形態では，クライアント２０から送信されるメールに対して，送信の可／不可を判断する承認が行われるものとする。承認者は，自身のクライアント２０でサーバ１０にアクセスし，承認が依頼されているメールの承認作業を行う。なお，承認者も，メールシステムを利用するユーザである。

図２は，本実施の形態によるサーバとクライアントの機能構成例を示す図である。

クライアント２０は，メール処理機能部２１を備える。メール処理機能部２１は，クライアント２０のユーザに対して，メールの閲覧や作成を行う環境を提供する機能部である。ユーザが承認者である場合には，メール処理機能部２１は，さらにメールの承認作業を行う環境も提供する。メール処理機能部２１は，例えば，ブラウザと，サーバ１０から提供されるＷｅｂページのデータとによって実現される。

サーバ１０は，メール処理部１１，情報記憶部１００を備える。情報記憶部１００は，サーバ１０で管理する電子メールを含む，本実施の形態によるメールシステムにおける様々なデータを記憶する記憶部である。情報記憶部１００は，利用者管理情報記憶部１１０，メール管理情報記憶部１２０，承認管理情報記憶部１３０，コメント管理情報記憶部１４０，返信管理情報記憶部１５０を備える。

利用者管理情報記憶部１１０は，利用者管理情報を記憶する記憶部である。利用者管理情報は，本実施の形態によるメールシステムを利用するユーザを管理する情報である。本実施の形態による利用者管理情報では，ユーザのメールアドレスの情報や，ユーザ認証の情報，承認者の情報などが管理される。

メール管理情報記憶部１２０は，メール管理情報を記憶する記憶部である。メール管理情報は，本実施の形態によるメールシステムを利用する各ユーザの受信メール，送信メールの管理情報である。

承認管理情報記憶部１３０は，承認管理情報を記憶する記憶部である。承認管理情報は，本実施の形態によるメールシステムを利用するユーザが作成して送信を行うメールについて，承認者による承認の状況を管理する情報である。本実施の形態による承認管理情報では，ユーザから承認が依頼されたメールについて，承認者による承認結果の情報などが管理される。

コメント管理情報記憶部１４０は，コメント管理情報を記憶する記憶部である。コメント管理情報は，承認者によって送信不可と判断され，差し戻しされたメールに対して，承認者により過去に記述されたコメントを管理する情報である。コメントには，メールが承認不可とされた理由や，メールを送信可能とするための修正の指示などが記述される。

返信管理情報記憶部１５０は，返信管理情報を記憶する記憶部である。返信管理情報は，メール間の返信関係を管理する情報である。一般に，同じ内容に関するメールのやり取りでは，相手からのメールに対する返信を繰り返すことにより，一連のやり取りが行われる。一連のやり取りで返信しあったメールのまとまりは，スレッドと呼ばれる。本実施の形態では，返信管理情報に示されるメール間の返信関係を辿ることにより，同じスレッドに属する，互いに親子関係，兄弟関係にあるメールの抽出が可能である。すなわち，本実施の形態による返信管理情報は，メールのスレッドを管理する情報でもある。

メール処理部１１は，本実施の形態によるメールシステムにおいて，メールに関する様々な処理を行う。なお，以下では，メール処理部１１による処理に関して，特にメールの作成から承認，送信までの処理について説明を行うが，実際にはメール処理部１１は，以下で説明される処理以外にもメールに関する様々な処理を行っている。メール処理部１１は，認証部１２，メール表示処理部１３，メッセージ作成処理部１４，承認処理部１５，承認結果対応処理部１６，関連コメント取得部１７を備える。

認証部１２は，クライアント２０を利用して本実施の形態によるメールシステムを利用するユーザの認証を行う。より具体的には，メールシステムを利用したいユーザが操作するクライアント２０からの要求に応じて，認証部１２は，該クライアント２０に認証画面を出力する。認証部１２は，利用者管理情報記憶部１１０に記憶された利用者管理情報を参照し，クライアント２０から受信した利用者ＩＤやパスワードによるユーザの認証を行う。

メール表示処理部１３は，認証に成功した場合に，メール管理情報記憶部１２０に記憶されたメール管理情報を参照して，認証に成功したユーザについてのメール表示画面を生成し，生成したメール表示画面を該当クライアント２０に出力する。メール表示処理部１３は，ユーザがメール表示画面で行う操作による要求をクライアント２０から取得し，その要求に応じたメッセージ作成処理，承認処理，承認結果対応処理などの処理を実行する。

メッセージ作成処理部１４は，メッセージ作成処理を行う。より具体的には，クライアント２０からメールの作成の要求を受け付けた場合に，メール作成画面を生成し，生成したメール作成画面を該当クライアント２０に出力する。作成するメールが返信である場合には，メッセージ作成処理部１４は，関連コメント取得部１７によって作成するメールの返信元メールと同じスレッドのメールに対する過去のコメントを取得し，取得したコメントを提示する画面を含むメール作成画面を生成する。作成するメールの返信元メールと同じスレッドのメールが第１の関連メールとなり，第１の関連メールに対するコメントが第１のコメントとなる。ここでは，同じスレッドに属するメールを，互いに関連するメールという意味で，関連メールと呼ぶ。

なお，以下では，返信で作成されるメールを返信メールとも呼ぶ。返信元メールは，返信メールで返信する元となる受信メールである。

メッセージ作成処理部１４は，作成されたメールの情報をクライアント２０から受けると，その情報を承認管理情報記憶部１３０に記憶された承認管理情報に記録する。

承認処理部１５は，承認処理を行う。より具体的には，承認処理部１５は，承認者であるユーザが操作するクライアント２０から承認処理の要求を受け付けた場合に，承認管理情報記憶部１３０に記憶された承認管理情報を参照し，該当承認者に対して承認が依頼されたメールの一覧画面である承認一覧画面を生成し，生成した承認一覧画面を該当クライアント２０に出力する。

承認処理部１５は，承認者であるユーザが操作するクライアント２０から，承認者により選択された，承認が依頼されたメールに対する承認実行の要求を受け付けた場合に，該当メールについての承認処理画面を生成し，生成した承認処理画面を該当クライアント２０に出力する。このとき，承認処理部１５は，関連コメント取得部１７によって承認処理を行う対象となる承認が依頼されたメールの返信元メールと同じスレッドのメールに対する過去のコメントを取得し，取得したコメントを提示する画面を含む承認処理画面を生成する。承認処理を行う対象となる承認が依頼されたメールの返信元メールと同じスレッドのメールが第３の関連メールとなり，第３の関連メールに対するコメントが第３のコメントとなる。

承認処理部１５は，承認結果の情報をクライアント２０から受けると，承認処理の対象となったメールに対して，その承認結果に応じた処理を行う。例えば，承認結果が差し戻し，すなわち承認不可である場合には，承認処理部１５は，承認管理情報記憶部１３０に記憶された承認管理情報にその旨を記録し，コメント管理情報記憶部１４０に記憶されたコメント管理情報に，該当メールに対する承認者によるコメントを記録する。ここでは，承認不可は，承認処理の対象となったメールの送信が不可であることを示す。

また，例えば，承認結果が承認可である場合には，承認処理部１５は，承認管理情報記憶部１３０に記憶された承認管理情報にその旨を記録し，承認処理の対象となったメールの送信処理を行う。ここでは，承認可は，承認の対象となったメールの送信が可能であることを示す。より具体的には，承認処理部１５は，例えば承認可とされたメールの宛先がメールシステムを利用する内部のユーザである場合に，そのメールの情報を，メール管理情報記憶部１２０に記憶されたメール管理情報における，該当ユーザの受信メールの領域に記録する。また，例えば，承認可とされたメールの宛先がメールシステムの外部である場合に，そのメールに対して必要な処理を施して，外部のネットワークに送信する。また，承認処理部１５は，承認可とされたメールの情報を，メール管理情報記憶部１２０に記憶されたメール管理情報における，発信者であるユーザの送信メールの領域に記録する。送信されたメールが返信メールである場合には，承認処理部１５は，返信管理情報記憶部１５０に記憶された返信管理情報に，送信されたメールとそのメールの返信元メールとの返信関係を示す情報を記録する。

承認結果対応処理部１６は，承認結果対応処理を行う。より具体的には，承認結果対応処理部１６は，クライアント２０からの承認依頼状況閲覧の要求を受け付けた場合に，承認管理情報記憶部１３０に記憶された承認管理情報を参照し，承認結果が差し戻し，すなわち承認不可であったメールの一覧画面である承認不可メール一覧画面を生成し，生成した承認不可メール一覧画面を該当クライアント２０に出力する。

承認結果対応処理部１６は，クライアント２０からユーザにより選択された，外部から送信不可と判断された，すなわち承認結果が承認不可であったメールに対する修正の要求を受け付けた場合に，該当メールの修正画面を生成し，生成した修正画面を該当クライアント２０に送信する。このとき，承認結果対応処理部１６は，コメント管理情報記憶部１４０に記憶されたコメント管理情報から，修正するメールに対するコメントの情報を取得し，取得したコメントを提示する画面を含む修正画面を生成する。また，承認結果対応処理部１６は，関連コメント取得部１７によって修正するメールの返信元メールと同じスレッドのメールに対する過去のコメントを取得し，取得したコメントを提示する画面を含む修正画面を生成する。承認処理を行う対象となる承認が依頼されたメールの返信元メールと同じスレッドのメールが第２の関連メールとなり，第２の関連メールに対するコメントが第２のコメントとなる。

承認結果対応処理部１６は，修正されたメールの情報をクライアント２０から受けると，その情報を承認管理情報記憶部１３０に記憶された承認管理情報に記録する。

関連コメント取得部１７は，返信管理情報記憶部１５０に記憶された返信管理情報を参照し，該当返信メールの返信元メールと同じスレッドのメールである関連メールを抽出する。関連コメント取得部１７は，コメント管理情報記憶部１４０に記憶されたコメント管理情報を参照し，抽出された関連メールに対するコメントの情報を取得する。

図３は，本実施の形態によるサーバやクライアントを実現するコンピュータのハードウェア構成例を示す図である。

図１，図２に示す本実施の形態のサーバ１０やクライアント２０を実現するコンピュータ１は，例えば，ＣＰＵ（Central Processing Unit ）２，主記憶となるメモリ３，記憶装置４，通信装置５，媒体読取・書込装置６，入力装置７，出力装置８等を備える。記憶装置４は，例えばＨＤＤ（Hard Disk Drive ）等の外部記憶装置や，補助記憶装置などである。媒体読取・書込装置６は，例えばＣＤ−Ｒ（Compact Disc Recordable ）ドライブやＤＶＤ−Ｒ（Digital Versatile Disc Recordable ）ドライブなどである。入力装置７は，例えばキーボード・マウスなどである。出力装置８は，例えばディスプレイ等の表示装置などである。

図２に示すサーバ１０やサーバ１０が備える各機能部は，コンピュータ１が備えるＣＰＵ２，メモリ３等のハードウェアと，ソフトウェアプログラムとによって実現することが可能である。コンピュータ１が実行可能なプログラムは，記憶装置４に記憶され，その実行時にメモリ３に読み出され，ＣＰＵ２により実行される。

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

以下では，本実施の形態のサーバ１０とクライアント２０による処理について，より具体的な例を用いて説明する。

図４は，本実施の形態による利用者ＤＢの例を示す図である。

図４に示す利用者ＤＢ（Database）１１５は，利用者管理情報記憶部１１０に記憶された利用者管理情報の一例である。図４に示す利用者ＤＢ１１５は，利用者アドレス，パスワード，利用者名称，承認者アドレス，承認者名称の情報をもつ。利用者アドレスは，本実施の形態によるメールシステムを利用するユーザのメールアドレスである。パスワードは，該当ユーザの認証で使用するパスワードである。利用者名称は，該当ユーザの名称である。承認者アドレスは，該当ユーザが作成したメールの承認を行う承認者の利用者アドレスである。承認者名称は，該当ユーザが作成したメールの承認を行う承認者の名称である。

なお，本実施の形態の例では，利用者アドレスを，ユーザを一意に識別する利用者ＩＤとしても使用する。利用者アドレスとは別に利用者ＩＤを設定してもよい。

図５は，本実施の形態によるメールＤＢの例を示す図である。

図５に示すメールＤＢ（Database）１２５は，メール管理情報記憶部１２０に記憶されたメール管理情報の一例である。本実施の形態の例では，ユーザごとのメールＤＢ１２５で，各ユーザの受信メールと送信メールとが管理されるものとする。図５（Ａ）に示すメールＤＢ１２５ａは，利用者アドレスが“yamada@xxx.ww ”であるユーザ“山田”氏についてのメールＤＢ１２５の例である。図５（Ｂ）に示すメールＤＢ１２５ｂは，利用者アドレスが“tanaka@xxx.ww ”であるユーザ“田中”氏についてのメールＤＢ１２５の例である。

図５に示すメールＤＢ１２５は，利用者アドレス，受送信，メッセージＩＤ，発信者アドレス，宛先，最新承認依頼日時，発信日時，件名，本文の情報を持つ。利用者アドレスは，該当メールＤＢ１２５でメールが管理されているユーザの利用者アドレスである。送受信は，該当メールが該当ユーザにとって受信メールであるか送信メールであるかを示す。メッセージＩＤは，メールを一意に識別する識別情報である。発信者アドレスは，該当メールを発信，すなわち送信したユーザの利用者アドレスである。宛先は，該当メールの宛先のアドレスである。最新承認依頼日時は，該当メールについて，承認者に対して承認が依頼された最新の日時である。発信日時は，該当メールが発信，すなわち送信された時刻を示す。件名は，該当メールの件名を示す。本文は，該当メールの本文を示す。

図６は，本実施の形態による承認管理ＤＢの例を示す図である。

図６に示す承認管理ＤＢ（Database）１３５は，承認管理情報記憶部１３０に記憶された承認管理情報の一例である。本実施の形態の例では，承認者であるユーザごとの承認管理ＤＢ１３５で，各承認者に対する承認依頼が管理されるものとする。図６に示す承認管理ＤＢ１３５は，利用者アドレスが“yamada@xxx.ww ”である承認者“山田”氏についての承認管理ＤＢ１３５の例である。

図６に示す承認管理ＤＢ１３５は，承認ＩＤ，メッセージＩＤ，返信元メッセージＩＤ，承認結果，発信者アドレス，宛先，承認依頼日時，件名，本文の情報を持つ。承認ＩＤは，承認依頼を一意に識別する識別情報である。メッセージＩＤは，承認が依頼されたメールのメッセージＩＤである。返信元メッセージＩＤは，承認が依頼されたメールが返信メールである場合に，その返信元メールのメッセージＩＤである。承認結果は，承認が依頼されたメールに対する承認者による承認の結果を示す。承認結果が“承認依頼中”であるメールは，ユーザにより承認が依頼されてから承認者による承認処理がまだ行われていないメールである。承認結果が“送信可（承認可）”であるメールは，送信されたメールとなる。承認結果が“差し戻し（承認不可）”であるメールは，ユーザに差し戻しされたメールである。承認結果の“修正有り”は，元々は承認結果が“差し戻し（承認不可）”であったメールについて，後に該当メールを修正したメールの承認が依頼されたことを示す。発信者アドレスは，承認が依頼されたメールの発信者，すなわち承認の依頼者であるユーザの利用者アドレスである。宛先は，承認が依頼されたメールの宛先のアドレスである。承認依頼日時は，承認が依頼された日時である。件名は，該当メールの件名を示す。本文は，該当メールの本文を示す。

図７は，本実施の形態によるコメントＤＢの例を示す図である。

図７に示すコメントＤＢ（Database）１４５は，コメント管理情報記憶部１４０に記憶されたコメント管理情報の一例である。図７（Ａ）に示すコメントＤＢ１４５ａは，メッセージＩＤ“system5@xxx.ww”のメールに対する承認処理前のコメントＤＢ１４５の例である。図７（Ｂ）に示すコメントＤＢ１４５ｂは，メッセージＩＤ“system5@xxx.ww”のメールに対する承認処理後のコメントＤＢ１４５の例である。

図７に示すコメントＤＢ１４５は，承認ＩＤ，承認者アドレス，メッセージＩＤ，コメントの情報を持つ。承認ＩＤは，該当コメントが付されたメールの承認依頼における承認ＩＤを示す。承認者アドレスは，該当コメントを付した担当の承認者の利用者アドレスである。メッセージＩＤは，該当コメントが付されたメールのメッセージＩＤを示す。コメントは，承認者によって記述されたコメントである。

図８は，本実施の形態による返信管理ＤＢの例を示す図である。

図８に示す返信管理ＤＢ（Database）１５５は，返信管理情報記憶部１５０に記憶された返信管理情報の一例である。図８に示す返信管理ＤＢ１５５では，返信メールと返信元メールとの対応が示される。上述したように，返信メールは，他のメールへの返信として作成されるメールである。返信元メールは，返信メールで返信する元となる受信メールである。例えば，図８の返信管理ＤＢ１５５に示すメール間の返信関係を辿ることによって，同じスレッドに属する互いに関連するメールを抽出することが可能となる。

図８に示す返信管理ＤＢ１５５において，返信メール情報は，返信メールについての情報を示す。返信メール情報は，メッセージＩＤと発信者アドレスの情報を持つ。メッセージＩＤは，該当返信メールのメッセージＩＤを示す。発信者アドレスは，該当返信メールの発信，すなわち送信を行ったユーザの利用者アドレスである。

図８に示す返信管理ＤＢ１５５において，返信元メール情報は，返信元メールについての情報を示す。返信元メール情報は，メッセージＩＤと発信者アドレスの情報を持つ。メッセージＩＤは，該当返信元メールのメッセージＩＤを示す。発信者アドレスは，該当返信元メールの発信，すなわち送信を行ったユーザの利用者アドレスである。

図９は，本実施の形態によるメール表示画面の例を示す図である。

図９に示すメール表示画面２１０は，クライアント２０からのメールの利用要求に応じて，メール表示処理部１３により生成され，該当クライアント２０に送信されるメール表示画面の一例である。サーバ１０からメール表示画面２１０の情報を受信したクライアント２０のメール処理機能部２１は，該クライアント２０のディスプレイに，メール表示画面２１０を表示する。

図９（Ａ）に示すメール表示画面２１０ａは，利用者アドレスが“yamada@xxx.ww ”であるユーザ“山田”氏が操作するクライアント２０のディスプレイに表示されるメール表示画面２１０の例である。図９（Ｂ）に示すメール表示画面２１０ｂは，利用者アドレスが“tanaka@xxx.ww ”であるユーザ“田中”氏が操作するクライアント２０のディスプレイに表示されるメール表示画面２１０の例である。“山田”氏は，承認者となるユーザであり，“田中”氏は，承認者とはならない一般のユーザである。

図９に示すメール表示画面２１０は，受信メールが表示される受信フォルダのメール表示画面２１０の例である。例えば，図９に示すメール表示画面２１０上の受信メールを選択する操作により，選択された受信メールの内容を閲覧可能である。なお，図示はされていないが，メニュー選択やフォルダのツリー表示などによってユーザに送信フォルダを指定させて，送信メールが表示される送信フォルダの画面を表示する等の実施は，当然可能である。

図９に示すメール表示画面２１０において，ユーザによりメッセージ新規作成ボタンが押下されると，クライアント２０からサーバ１０に，新規メールの作成要求が送られる。図９に示すメール表示画面２１０において，メールを選択した状態で，ユーザによりメッセージ返信ボタンが押下されると，クライアント２０からサーバ１０に，選択されたメールを返信元メールとする返信メールの作成要求が送られる。図９に示すメール表示画面２１０において，ユーザにより承認依頼状況閲覧ボタンが押下されると，クライアント２０からサーバ１０に，承認依頼状況閲覧の要求が送られる。なお，図９に示すメール表示画面２１０において，承認依頼状況閲覧ボタンに括弧書きされた件数は，該当ユーザが承認者に対してメールの承認を依頼している件数を示す。

図９（Ａ）に示すメール表示画面２１０ａには承認処理ボタンがあるが，図９（Ｂ）に示すメール表示画面２１０ｂには承認処理ボタンがない。これは，図９（Ａ）に示すメール表示画面２１０ａが承認者となる“山田”氏のメール表示画面２１０であり，図９（Ｂ）に示すメール表示画面２１０ｂが承認者とはならない“田中”氏のメール表示画面２１０であることによる。図９（Ａ）に示すメール表示画面２１０ａにおいて，承認者となるユーザにより承認処理ボタンが押下されると，クライアント２０からサーバ１０に，承認処理要求が送られる。なお，図９（Ａ）に示すメール表示画面２１０ａにおいて，承認処理ボタンに括弧書きされた件数は，承認者となる該当ユーザに対してメールの承認が依頼されている件数を示す。

図９に示すメール表示画面２１０において，ユーザによりログアウトボタンが押下されると，クライアント２０からサーバ１０に，ログアウトの要求が送られる。

図１０は，本実施の形態によるメッセージ作成画面の例を示す図である。

図１０に示すメッセージ作成画面２２０は，クライアント２０からのメッセージ作成要求に応じて，メッセージ作成処理部１４により生成され，該当クライアント２０に送信されるメッセージ作成画面の一例である。サーバ１０からメッセージ作成画面２２０の情報を受信したクライアント２０のメール処理機能部２１は，該クライアント２０のディスプレイに，メッセージ作成画面２２０を表示する。

図１０に示すメッセージ作成画面２２０は，特に，クライアント２０からのメッセージ作成要求が返信メールの作成要求であった場合の例となっている。そのため，図１０に示すメッセージ作成画面２２０における本文の欄には，返信元メールの本文の内容が引用符“＞”が行頭についた形で示されている。例えば，ユーザは，返信元メールの本文の内容を確認しながら，返信メールの本文を作成する。

図１０に示すメッセージ作成画面２２０において，ユーザにより送信（承認依頼）ボタンが押下されると，クライアント２０からサーバ１０に，作成されたメールの情報が送られる。作成されたメールについては，承認者に対して承認が依頼された状態となる。

図１０に示すメッセージ作成画面２２０において，右側の過去チェック内容の欄が，今回作成するメールの返信元メールと同じスレッドのメールに対して記述された，過去のコメントを提示する画面である。今回作成するメールの返信元メールと同じスレッドのメールが上述の第１の関連メールとなり，その第１の関連メールに対して記述された過去のコメントが上述の第１のコメントとなる。

ユーザは，図１０に示すメッセージ作成画面２２０で提示された，同じスレッドに属するメールに対する過去のコメントを参照して，メールの作成を行う。ユーザは，過去の同様のメールで承認者によって問題とされた内容に留意して，メールを作成することができる。これにより，過去のメールと同様の問題を有するメールの作成が抑制され，承認者は何度も同じ内容のコメントを記述する必要がなくなるので，承認者の手間を軽減することが可能となる。

図１１は，本実施の形態による承認一覧画面の例を示す図である。

図１１に示す承認一覧画面２３０は，クライアント２０からの承認処理要求に応じて，承認処理部１５により生成され，該当クライアント２０に送信される承認一覧画面の一例である。サーバ１０から承認一覧画面２３０の情報を受信したクライアント２０のメール処理機能部２１は，該クライアント２０のディスプレイに，承認一覧画面２３０を表示する。

図１１に示す承認一覧画面２３０は，利用者アドレスが“yamada@xxx.ww ”である承認者“山田”氏が操作するクライアント２０のディスプレイに表示される承認一覧画面２３０の例である。図１１に示す承認一覧画面２３０には，承認者である“山田”氏に対して承認が依頼されたメールのうち，承認管理ＤＢ１３５の承認結果が“承認依頼中”のメールのみが一覧表示されている。

図１１に示す承認一覧画面２３０において，承認者となるユーザにより承認処理を行う対象のメールが選択されると，クライアント２０からサーバ１０に，選択されたメールの情報が送られる。

図１２は，本実施の形態による承認処理画面の例を示す図である。

図１２に示す承認処理画面２４０は，クライアント２０からの承認処理を行う対象のメールの選択結果に応じて，承認処理部１５により生成され，該当クライアント２０に送信される承認処理画面の一例である。サーバ１０から承認処理画面２４０の情報を受信したクライアント２０のメール処理機能部２１は，該クライアント２０のディスプレイに，承認処理画面２４０を表示する。なお，図１２に示す承認処理画面２４０は，特に，承認処理を行う対象のメールが返信メールであった場合の例となっている。承認者となるユーザは，図１２に示す承認処理画面２４０で，承認が依頼されたメールの内容を確認し，該メールの送信を可とするか不可とするかを判断する。

メールの送信を可とする場合には，承認者となるユーザは，図１２に示す承認処理画面２４０で，送信（承認可）ボタンを押下する。このとき，クライアント２０からサーバ１０には，承認結果として承認可の情報が送られる。

メールの送信を不可とする場合には，承認者となるユーザは，図１２に示す承認処理画面２４０で，差し戻し（承認不可）ボタンを押下する。承認者となるユーザは，承認不可とした理由や，メールの修正の指示などをコメント欄に入力する。このとき，クライアント２０からサーバ１０には，承認結果として承認不可の情報とともに，承認者となるユーザにより入力されたコメントの情報が送られる。

図１２に示す承認処理画面２４０において，右側の過去チェック内容の欄が，今回承認処理を行う対象のメールの返信元メールと同じスレッドのメールに対して記述された，過去のコメントを提示する画面である。今回承認処理を行う対象のメールの返信元メールと同じスレッドのメールが上述の第３の関連メールとなり，その第３の関連メールに対して記述された過去のコメントが上述の第３のコメントとなる。

承認者となるユーザは，図１２に示す承認処理画面２４０で提示された，同じスレッドに属するメールに対する過去のコメントを参照して，メールの承認作業を行う。そのため，承認者となるユーザは，承認処理を行う対象となるメールに，過去の同様のメールに対するコメントの内容が反映されているかを確認しながら，メールの承認作業を行うことが可能となる。また，図１２に示す承認処理画面２４０で提示されたコメントは，承認不可となったメールを修正するユーザの修正画面にも表示される。そのため，承認者となるユーザは，過去の同様のメールに対するコメントに記述されている内容については，詳細な内容をコメントに記述する必要がなくなる。これにより，承認者の手間を軽減することが可能となる。

図１３は，本実施の形態による承認不可メール一覧画面の例を示す図である。

図１３に示す承認不可メール一覧画面２５０は，クライアント２０からの承認依頼状況閲覧要求に応じて，承認結果対応処理部１６により生成され，該当クライアント２０に送信される承認不可メール一覧画面の一例である。サーバ１０から承認不可メール一覧画面２５０の情報を受信したクライアント２０のメール処理機能部２１は，該クライアント２０のディスプレイに，承認不可メール一覧画面２５０を表示する。

図１３に示す承認不可メール一覧画面２５０において，ユーザは承認不可とされたメールから修正するメールを選択して，メッセージ修正ボタンを押下する。図１３に示す承認不可メール一覧画面２５０において，ユーザによりメッセージ修正ボタンが押下されると，クライアント２０からサーバ１０に，修正するメールとして選択されたメールの情報が送られる。

図１４は，本実施の形態による修正画面の例を示す図である。

図１４に示す修正画面２６０は，クライアント２０からの修正するメールの選択結果に応じて，承認結果対応処理部１６により生成され，該当クライアント２０に送信される修正画面の一例である。サーバ１０から修正画面２６０の情報を受信したクライアント２０のメール処理機能部２１は，該クライアント２０のディスプレイに，修正画面２６０を表示する。なお，図１４に示す修正画面２６０は，特に，修正するメールが返信メールであった場合の例となっている。

図１４に示す修正画面２６０において，ユーザは，承認不可とされたメールの修正を行う。図１４に示す修正画面２６０において，ユーザにより修正（承認依頼）ボタンが押下されると，クライアント２０からサーバ１０に，修正されたメールの情報が送られる。修正されたメールについては，承認者に対して承認が依頼された状態となる。

図１４に示す修正画面２６０において，右側の今回チェック内容の欄が，今回修正する承認不可とされたメールに対する承認者のコメントを提示する画面である。また，図１４に示す修正画面２６０において，右側の過去チェック内容の欄が，今回修正するメールの返信元メールと同じスレッドのメールに対して記述された，過去のコメントを提示する画面である。今回返信するメールの返信元メールと同じスレッドのメールが上述の第２の関連メールとなり，その第２の関連メールに対して記述された過去のコメントが上述の第２のコメントとなる。

ユーザは，図１４に示す修正画面２６０で提示された，今回修正する承認不可とされたメールに対する承認者のコメントとともに，同じスレッドに属するメールに対する過去のコメントを参照して，メールの修正を行う。ユーザは，過去の同様のメールで承認者によって問題とされた内容に留意して，メールを修正することができる。これにより，過去のメールと同様の問題を有するメールの作成が抑制され，承認者は何度も同じ内容のコメントを記述する必要がなくなるので，承認者の手間を軽減することが可能となる。

図１５，図１６は，本実施の形態のサーバによるメール処理フローチャートである。

ここでは，サーバ１０のメール処理部１１によるメール処理の流れの一例を説明する。

サーバ１０において，メール処理部１１がクライアント２０からのメール利用要求を受信すると（ステップＳ１０），認証部１２は，該当クライアント２０に認証画面の情報を送信する（ステップＳ１１）。

認証部１２は，クライアント２０から利用者ＩＤとパスワードとを受信すると（ステップＳ１２のＹＥＳ），受信した利用者ＩＤ，パスワードと，利用者ＤＢ１１５とを用いて，クライアント２０を操作するユーザの認証を行う（ステップＳ１３）。本実施の形態では利用者アドレスを利用者ＩＤとしても使用するので，受信した利用者ＩＤは，利用者ＤＢ１１５の利用者アドレスと照合される。

認証部１２は，認証に成功したかを判定する（ステップＳ１４）。認証に成功しなかった場合（ステップＳ１４のＮＯ），すなわち認証に失敗した場合には，認証部１２は，該当クライアント２０に認証エラー画面の情報を送信し（ステップＳ１５），処理を終了する。

認証に成功した場合には（ステップＳ１４のＹＥＳ），メール表示処理部１３は，メール表示画面２１０を生成する（ステップＳ１６）。より具体的には，メール表示処理部１３は，認証されたユーザの利用者アドレスに対応するメールＤＢ１２５から受信メールの情報を取得し，例えば，図９に示すようなメール表示画面２１０を生成する。このとき，メール表示処理部１３は，例えば利用者ＤＢ１１５を参照して，認証されたユーザが承認者となるユーザであるかを判断する。メール表示処理部１３は，認証されたユーザが承認者となるユーザであれば，例えば図９（Ａ）に示すようなメール表示画面２１０ａを生成する。メール表示処理部１３は，認証されたユーザが承認者とならないユーザであれば，例えば図９（Ｂ）に示すようなメール表示画面２１０ｂを生成する。メール表示処理部１３は，生成されたメール表示画面２１０の情報を該当クライアント２０に送信する（ステップＳ１７）。

メール処理部１１がクライアント２０からメッセージ作成要求を受信すると（ステップＳ１８のＹＥＳ），メッセージ作成処理部１４は，メッセージ作成処理を実行する（ステップＳ１９）。サーバ１０によるメッセージ作成処理の詳細については，後述する。

メール処理部１１がクライアント２０から承認処理要求を受信すると（ステップＳ２０のＹＥＳ），承認処理部１５は，サーバ１０による承認処理を実行する（ステップＳ２１）。承認処理の詳細については，後述する。

メール処理部１１がクライアント２０から承認依頼状況閲覧要求を受信すると（ステップＳ２２のＹＥＳ），承認結果対応処理部１６は，承認結果対応処理を実行する（ステップＳ２３）。サーバ１０による承認結果対応処理の詳細については，後述する。

メール処理部１１は，クライアント２０からログアウト要求を受信すると（ステップＳ２４のＹＥＳ），処理を終了する。

図１７は，本実施の形態のサーバによるメッセージ作成処理フローチャートである。

ここでは，サーバ１０のメール処理部１１のメッセージ作成処理部１４によるメッセージ作成処理の流れの一例を説明する。

メール処理部１１がクライアント２０からメッセージ作成要求を受信すると，メッセージ作成処理部１４は，受信したメッセージ作成要求が返信メールの作成要求であるかを判定する（ステップＳ３０）。返信メールの作成要求であれば（ステップＳ３０のＹＥＳ），関連コメント取得部１７は，関連コメント取得処理を実行する（ステップＳ３１）。関連コメント取得処理の詳細については，後述する。ここでは，作成するメールの返信元メールの関連メールである第１の関連メールに対する第１のコメントが取得される。

メッセージ作成処理部１４は，メッセージ作成画面２２０を生成する（ステップＳ３２）。作成するメールが返信メールである場合には，メッセージ作成処理部１４は，例えば図１０に示すような，取得された第１のコメントの提示画面を含むメッセージ作成画面２２０を生成する。メッセージ作成処理部１４は，生成されたメッセージ作成画面２２０を該当クライアント２０に送信する（ステップＳ３３）。

クライアント２０から作成されたメールの情報を受信すると（ステップＳ３４のＹＥＳ），メッセージ作成処理部１４は，作成されたメールの承認を行う承認者を特定する（ステップＳ３５）。より具体的には，メッセージ作成処理部１４は，利用者ＤＢ１１５から，メールを作成したユーザの利用者アドレスに対応する承認者アドレスを取得する。

メッセージ作成処理部１４は，作成されたメールに対するメッセージＩＤと承認ＩＤとを生成する（ステップＳ３６）。メッセージ作成処理部１４は，承認依頼の情報として，生成されたメッセージＩＤと承認ＩＤとを含む，作成されたメールの情報を，承認管理ＤＢ１３５に記録する（ステップＳ３７）。このとき，承認結果には，承認依頼中が記録される。

図１８，図１９は，本実施の形態のサーバによる承認処理フローチャートである。

ここでは，サーバ１０のメール処理部１１の承認処理部１５による承認処理の流れの一例を説明する。

メール処理部１１がクライアント２０から承認処理要求を受信すると，承認処理部１５は，該当クライアント２０を操作する，承認者となるユーザの承認管理ＤＢ１３５から，該ユーザに承認が依頼された，承認結果が承認依頼中であるメールの情報を取得する（ステップＳ４０）。承認処理部１５は，例えば図１１に示すような承認一覧画面２３０を生成する（ステップＳ４１）。承認処理部１５は，生成された承認一覧画面２３０の情報を該当クライアント２０に送信する（ステップＳ４２）。

承認処理部１５は，クライアント２０から承認を行う対象のメールの選択情報を受信すると（ステップＳ４３のＹＥＳ），選択された承認を行う対象のメールの情報を，該当クライアント２０を操作する承認者の承認管理ＤＢ１３５から取得する（ステップＳ４４）。

承認処理部１５は，選択された承認を行う対象のメールが返信メールであるかを判定する（ステップＳ４５）。例えば，承認管理ＤＢ１３５の該当メールの承認依頼の情報に，返信元メッセージＩＤの情報があれば，選択された承認を行う対象のメールは返信メールであると判断できる。返信メールであれば（ステップＳ４５のＹＥＳ），関連コメント取得部１７は，関連コメント取得処理を実行する（ステップＳ４６）。関連コメント取得処理の詳細については，後述する。ここでは，承認を行う対象のメールの返信元メールの関連メールである第３の関連メールに対する第３のコメントが取得される。

承認処理部１５は，承認処理画面２４０を生成する（ステップＳ４７）。承認を行う対象のメールが返信メールである場合には，承認処理部１５は，例えば図１２に示すような，取得された第３のコメントの提示画面を含む承認処理画面２４０を生成する。承認処理部１５は，生成された承認処理画面２４０を該当クライアント２０に送信する（ステップＳ４８）。

クライアント２０から承認結果を受信すると（ステップＳ４９のＹＥＳ），承認処理部１５は，受信した承認結果が承認可であるかを判定する（ステップＳ５０）。承認結果が承認可でなければ（ステップＳ５０のＮＯ），すなわち承認結果が承認不可であれば，承認処理部１５は，該当クライアント２０を操作する承認者の承認管理ＤＢ１３５における該当メールの承認依頼の情報の承認結果に差し戻し（承認不可）を記録する（ステップＳ５１）。承認処理部１５は，承認結果とともに受信したコメントの情報を，コメントＤＢ１４５に記録し（ステップＳ５２），処理を終了する。

承認結果が承認可であれば（ステップＳ５０のＹＥＳ），承認処理部１５は，該当クライアント２０を操作する承認者の承認管理ＤＢ１３５における該当メールの承認依頼の情報の承認結果に送信可（承認可）を記録する（ステップＳ５３）。承認処理部１５は，該当メールのヘッダ情報を生成する（ステップＳ５４）。承認処理部１５は，該当メールの宛先に対応するメールＤＢ１２５に，該当メールの情報を，受信メールの情報として記録する（ステップＳ５５）。なお，該当メールの宛先がメールシステムの外部である場合には，該当メールを外部のネットワークに送信する処理を行う。承認処理部１５は，該当メールの発信者アドレスに対応するメールＤＢ１２５に，該当メールの情報を，送信メールの情報として記録する（ステップＳ５６）。

承認処理部１５は，送信したメールが，返信メールであるかを判定する（ステップＳ５７）。返信メールでなければ（ステップＳ５７のＮＯ），承認処理部１５は，処理を終了する。

返信メールであれば（ステップＳ５７のＹＥＳ），承認処理部１５は，送信したメールのヘッダ情報から，送信したメールの返信元メールの情報を取得する（ステップＳ５８）。承認処理部１５は，送信したメールとその返信元メールとの間の返信関係を，返信管理ＤＢ１５５に記録し（ステップＳ５９），処理を終了する。

図２０，図２１は，本実施の形態のサーバによる承認結果対応処理フローチャートである。

ここでは，サーバ１０のメール処理部１１の承認結果対応処理部１６による承認結果対応処理の流れの一例を説明する。

メール処理部１１がクライアント２０から承認依頼状況閲覧要求を受信すると，承認結果対応処理部１６は，利用者ＤＢ１１５を参照し，該当クライアント２０を操作するユーザの承認者を特定する（ステップＳ６０）。承認結果対応処理部１６は，特定された承認者の承認管理ＤＢ１３５から，該当クライアント２０を操作するユーザが承認を依頼したメールを検索する（ステップＳ６１）。より具体的には，承認結果対応処理部１６は，該当クライアント２０を操作するユーザの利用者アドレスで，特定された承認者の承認管理ＤＢ１３５の発信者アドレスを検索する。

承認結果対応処理部１６は，承認管理ＤＢ１３５に，該当クライアント２０を操作するユーザが承認を依頼したメールで，承認結果が承認不可のメールがあるかを判定する（ステップＳ６２）。承認不可のメールがなければ（ステップＳ６２のＮＯ），承認結果対応処理部１６は，該当クライアント２０に対して，承認結果が承認不可のメールがない旨を通知し（ステップＳ６３），処理を終了する。

承認不可のメールがあれば（ステップＳ６２のＹＥＳ），承認結果対応処理部１６は，承認管理ＤＢ１３５から取得された承認結果が承認不可であるメールの情報を用いて，図１３に示すような承認不可メール一覧画面２５０を生成する（ステップＳ６４）。承認結果対応処理部１６は，生成された承認不可メール一覧画面２５０の情報を該当クライアント２０に送信する（ステップＳ６５）。

承認結果対応処理部１６は，クライアント２０から修正するメールの選択情報を受信すると（ステップＳ６６のＹＥＳ），選択された修正するメールの情報を，該当クライアント２０を操作するユーザに対応する承認者の承認管理ＤＢ１３５から取得する（ステップＳ６７）。承認結果対応処理部１６は，選択された修正するメールのメッセージＩＤでコメントＤＢ１４５を参照し，修正するメールに対するコメントを取得する（ステップＳ６８）。

承認結果対応処理部１６は，選択された修正するメールが返信メールであるかを判定する（ステップＳ６９）。例えば，承認管理ＤＢ１３５の該当メールの承認依頼の情報に，返信元メッセージＩＤの情報があれば，選択された修正するメールは返信メールであると判断できる。返信メールであれば（ステップＳ６９のＹＥＳ），関連コメント取得部１７は，関連コメント取得処理を実行する（ステップＳ７０）。関連コメント取得処理の詳細については，後述する。ここでは，修正するメールの返信元メールの関連メールである第２の関連メールに対する第２のコメントが取得される。

承認結果対応処理部１６は，修正画面２６０を生成する（ステップＳ７１）。修正するメールが返信メールである場合には，承認結果対応処理部１６は，例えば図１４に示すような，取得された第２のコメントの提示画面を含む修正画面２６０を生成する。承認結果対応処理部１６は，生成された修正画面２６０を該当クライアント２０に送信する（ステップＳ７２）。

クライアント２０から修正されたメールの情報を受信すると（ステップＳ７３のＹＥＳ），承認結果対応処理部１６は，承認依頼の情報として，修正されたメールの情報を，該当クライアント２０を操作するユーザに対応する承認者の承認管理ＤＢ１３５に記録する（ステップＳ７４）。このとき，メッセージＩＤには修正前のメールのメッセージＩＤが記録され，承認ＩＤには新たに生成された承認ＩＤが記録される。また，承認結果には，承認依頼中が記録される。

承認結果対応処理部１６は，承認管理ＤＢ１３５に，修正されたメールの承認依頼とメッセージＩＤが同じ承認依頼のレコードがあるかを判定する（ステップＳ７５）。メッセージＩＤが同じ承認依頼のレコードがあれば（ステップＳ７５のＹＥＳ），承認結果対応処理部１６は，承認管理ＤＢ１３５において，修正されたメールの承認依頼と同じメッセージＩＤの過去の承認依頼のレコードにおける承認結果を，修正有りに変更する（ステップＳ７６）。

図２２は，本実施の形態の関連コメント取得部による関連コメント取得処理フローチャートである。

ここでは，サーバ１０のメール処理部１１の関連コメント取得部１７による関連コメント処理の流れの一例を説明する。

関連コメント取得部１７は，該当返信メールの返信元メールのメッセージＩＤを取得する（ステップＳ８０）。例えば，該当返信メールを作成する場合には，ユーザにより返信元メールとして指定された受信メールのメッセージＩＤをメールＤＢ１２５から取得することにより，返信元メールのメッセージＩＤを取得できる。また，該当返信メールが，承認処理を行う対象のメールである場合には，承認管理ＤＢ１３５から返信元メッセージＩＤを取得することで，返信元メールのメッセージＩＤを取得できる。また，該当返信メールが，修正するメールである場合には，承認管理ＤＢ１３５から返信元メッセージＩＤを取得することで，返信元メールのメッセージＩＤを取得できる。

関連コメント取得部１７は，返信元メールの関連メールを取得する（ステップＳ８１）。より具体的には，関連コメント取得部１７は，ステップＳ８０で取得されたメッセージＩＤで返信管理ＤＢ１５５の返信メール情報のメッセージＩＤを検索し，対応する返信元メール情報のメッセージＩＤを取得する。さらに取得されたメッセージＩＤを用いて返信管理ＤＢ１５５の検索を行う処理を繰り返すことにより，該当返信メールの返信元メールから親子関係を辿って関係する関連メールがすべて得られる。また，関連コメント取得部１７は，取得されたメッセージＩＤで返信管理ＤＢ１５５の返信元メール情報のメッセージＩＤを検索し，対応する返信メール情報のメッセージＩＤを取得する。この処理により，該当返信メールの返信元メールの関連メールと兄弟関係にあるメールがさらに関連メールとして得られる。このような処理を繰り返すことで，関連コメント取得部１７は，該当返信メールの返信元メールと同じスレッドに属するすべての関連メールを取得することができる。

関連コメント取得部１７は，取得された各関連メールについて，該関連メールに対するコメントと，該コメントを記述した承認者の承認者アドレスとを取得する（ステップＳ８２）。より具体的には，関連コメント取得部１７は，取得された各関連メールのメッセージＩＤでコメントＤＢ１４５を参照し，コメントＤＢ１４５に対応するコメントが存在する関連メールについて，そのコメントと，承認者アドレスとを取得する。

関連コメント取得部１７は，コメントが存在する関連メールについて，発信者アドレス，件名を取得する（ステップＳ８３）。より具体的には，関連コメント取得部１７は，コメントが存在する関連メールについて，取得された承認者アドレスの承認者の承認管理ＤＢ１３５を該当関連メールのメッセージＩＤで検索し，発信者アドレスと件名とを取得する。

図２３，図２４は，本実施の形態のクライアントによるメール処理フローチャートである。

ここでは，クライアント２０のメール処理機能部２１によるメール処理の流れの一例を説明する。

クライアント２０において，メール処理機能部２１は，ユーザによるメール利用操作を受け付けると（ステップＳ１００），サーバ１０にメール利用要求を送信する（ステップＳ１０１）。

メール処理機能部２１は，サーバ１０から認証画面の情報を受信すると（ステップＳ１０２のＹＥＳ），クライアント２０のディスプレイに認証画面を表示する（ステップＳ１０３）。

メール処理機能部２１は，ユーザによる利用者ＩＤとパスワードの入力を受け付けると（ステップＳ１０４のＹＥＳ），受け付けた利用者ＩＤとパスワードとをサーバ１０に送信する（ステップＳ１０５）。

メール処理機能部２１は，サーバ１０から認証エラー画面の情報を受信すると（ステップＳ１０６のＹＥＳ），クライアント２０のディスプレイに認証エラー画面を表示し（ステップＳ１０７），処理を終了する。

メール処理機能部２１は，サーバ１０からメール表示画面２１０の情報を受信すると（ステップＳ１０８），クライアント２０のディスプレイに，図９に示すようなメール表示画面２１０を表示する（ステップＳ１０９）。例えば，ユーザが承認者となるユーザであれば，図９（Ａ）に示すようなメール表示画面２１０ａが表示される。例えば，ユーザが承認者とならないユーザであれば，図９（Ｂ）に示すようなメール表示画面２１０ｂが表示される。

メール処理機能部２１は，ユーザによるメッセージ作成操作を受け付けると（ステップＳ１１０），メッセージ作成処理を実行する（ステップＳ１１１）。クライアント２０によるメッセージ作成処理の詳細については，後述する。例えば，図９に示すメール表示画面２１０が表示されている場合において，ユーザによるメッセージ新規作成ボタンやメッセージ返信ボタンの押下操作が，メッセージ作成操作となる。

メール処理機能部２１は，ユーザによる承認処理操作を受け付けると（ステップＳ１１２），承認処理を実行する（ステップＳ１１３）。承認処理操作は，ユーザが承認者である場合にのみ行われる。クライアント２０による承認処理の詳細については，後述する。例えば，図９（Ａ）に示すメール表示画面２１０ａが表示されている場合において，承認者となるユーザによる承認処理ボタンの押下操作が，承認処理操作となる。

メール処理機能部２１は，ユーザによる承認依頼状況閲覧操作を受け付けると（ステップＳ１１４），承認結果対応処理を実行する（ステップＳ１１５）。クライアント２０による承認結果対応処理の詳細については，後述する。例えば，図９に示すメール表示画面２１０が表示されている場合において，ユーザによる承認依頼状況閲覧ボタンの押下操作が，承認依頼状況閲覧操作となる。

メール処理機能部２１は，ユーザによるログアウト操作を受け付けると（ステップＳ１１６），ログアウト要求をサーバ１０に送信し（ステップＳ１１７），処理を終了する。例えば，図９に示すメール表示画面２１０が表示されている場合において，ユーザによるログアウトボタンの押下操作が，ログアウト操作となる。

図２５は，本実施の形態のクライアントによるメッセージ作成処理フローチャートである。

ここでは，クライアント２０のメール処理機能部２１によるメッセージ作成処理の流れの一例を説明する。

クライアント２０において，メール処理機能部２１は，ユーザによるメッセージ作成操作に応じて，メッセージ作成要求をサーバ１０に送信する（ステップＳ１２０）。

メール処理機能部２１は，サーバ１０からメッセージ作成画面２２０の情報を受信すると（ステップＳ１２１），クライアント２０のディスプレイに，図１０に示すようなメッセージ作成画面２２０を表示する（ステップＳ１２２）。メール処理機能部２１は，メッセージ作成画面２２０に対するユーザによるメール作成の入力を受け付ける（ステップＳ１２３）。

メール処理機能部２１は，ユーザによる送信操作を受け付けると（ステップＳ１２４のＹＥＳ），ユーザにより入力された作成メールの情報をサーバ１０に送信し（ステップＳ１２５），処理を終了する。例えば，図１０に示すメッセージ作成画面２２０が表示されている場合において，ユーザによる送信（承認依頼）ボタンの押下操作が，送信操作となる。

図２６は，本実施の形態のクライアントによる承認処理フローチャートである。

ここでは，クライアント２０のメール処理機能部２１による承認処理の流れの一例を説明する。

クライアント２０において，メール処理機能部２１は，承認者となるユーザによる承認処理操作に応じて，承認処理要求をサーバ１０に送信する（ステップＳ１３０）。

メール処理機能部２１は，サーバ１０から承認一覧画面２３０の情報を受信すると（ステップＳ１３１のＹＥＳ），クライアント２０のディスプレイに，図１１に示すような承認一覧画面２３０を表示する（ステップＳ１３２）。

メール処理機能部２１は，承認者となるユーザによる承認を行う対象のメールを選択する操作を受け付けると（ステップＳ１３３のＹＥＳ），メールの選択情報をサーバ１０に送信する（ステップＳ１３４）。

メール処理機能部２１は，サーバ１０から承認処理画面２４０の情報を受信すると（ステップＳ１３５のＹＥＳ），クライアント２０のディスプレイに，図１２に示すような承認処理画面２４０を表示する（ステップＳ１３６）。

メール処理機能部２１は，承認者となるユーザによるコメントの入力操作がある場合には（ステップＳ１３７のＹＥＳ），承認者となるユーザによるコメントの入力を受け付ける（ステップＳ１３８）。

メール処理機能部２１は，ユーザによる承認結果を受け付けると（ステップＳ１３９のＹＥＳ），その承認結果の情報をサーバ１０に送信し（ステップＳ１４０），処理を終了する。このとき，承認結果が承認不可であれば，メール処理機能部２１は，入力されたコメントの情報を承認結果と併せて送信する。例えば，図１２に示す承認処理画面２４０が表示されている場合において，送信（承認可）ボタンや差し戻し（承認不可）ボタンの押下操作が，送信操作となる。

図２７は，本実施の形態のクライアントによる承認結果対応処理フローチャートである。

ここでは，クライアント２０のメール処理機能部２１による承認結果対応処理の流れの一例を説明する。

クライアント２０において，メール処理機能部２１は，承認者となるユーザによる承認依頼状況閲覧操作に応じて，承認依頼状況閲覧要求をサーバ１０に送信する（ステップＳ１５０）。

メール処理機能部２１は，サーバ１０から承認不可のメールがない旨を示す情報を受信すると（ステップＳ１５１のＹＥＳ），クライアント２０のディスプレイに，承認不可のメールがない旨を表示し（ステップＳ１５２），処理を終了する。

メール処理機能部２１は，サーバ１０から承認不可メール一覧画面２５０の情報を受信すると（ステップＳ１５３のＹＥＳ），クライアント２０のディスプレイに，図１３に示すような承認不可メール一覧画面２５０を表示する（ステップＳ１５４）。

メール処理機能部２１は，ユーザによる修正するメールを選択する操作を受け付けると（ステップＳ１５５のＹＥＳ），メールの選択情報をサーバ１０に送信する（ステップＳ１５６）。

メール処理機能部２１は，サーバ１０から修正画面２６０の情報を受信すると（ステップＳ１５７），クライアント２０のディスプレイに，図１４に示すような修正画面２６０を表示する（ステップＳ１５８）。メール処理機能部２１は，修正画面２６０に対するユーザによる修正の入力を受け付ける（ステップＳ１５９）。

メール処理機能部２１は，ユーザによる送信操作を受け付けると（ステップＳ１６０のＹＥＳ），ユーザにより入力された修正メールの情報をサーバ１０に送信し（ステップＳ１６１），処理を終了する。例えば，図１４に示す修正画面２６０が表示されている場合において，ユーザによる修正（承認依頼）ボタンの押下操作が，送信操作となる。

以上，本実施の形態について説明したが，本発明はその主旨の範囲において種々の変形が可能であることは当然である。

１０ サーバ
１１ メール処理部
１２ 認証部
１３ メール表示処理部
１４ メッセージ作成処理部
１５ 承認処理部
１６ 承認結果対応処理部
１７ 関連コメント取得部
１００ 情報記憶部
１１０ 利用者管理情報記憶部
１２０ メール管理情報記憶部
１３０ 承認管理情報記憶部
１４０ コメント管理情報記憶部
１５０ 返信管理情報記憶部
２０ クライアント
２１ メール処理機能部
３０ ネットワーク

Claims (5)

1. コンピュータに，
   電子メールの作成の要求を受け付け，
   前記電子メールが返信である場合に，記憶部に記憶された，電子メール間の返信関係を管理する返信管理情報を参照して，前記電子メールの返信元の電子メールと同じスレッドの電子メールである第１の関連メールを抽出し，
   記憶部に記憶された，電子メールに対して過去に記述されたコメントを管理するコメント管理情報を参照して，前記第１の関連メールに対する第１のコメントを取得し，
   前記第１のコメントを提示する画面を含む，前記作成する電子メールの作成画面を生成し，
   前記生成された作成画面を出力する
   処理を実行させるためのメール処理プログラム。
2. 前記コンピュータに，さらに，
   外部から送信不可と判断された電子メールに対する修正の要求を受け付け，
   前記修正する電子メールが返信である場合に，前記返信管理情報を参照して，前記修正する電子メールの返信元の電子メールと同じスレッドの電子メールである第２の関連メールを抽出し，
   記憶部に記憶された前記コメント管理情報を参照して，前記第２の関連メールに対する第２のコメントを取得し，
   前記第２のコメントを提示する画面を含む，前記修正する電子メールの修正画面を生成し，
   前記生成された修正画面を出力する
   処理を実行させるための請求項１に記載のメール処理プログラム。
3. 前記コンピュータに，さらに，
   承認が依頼された電子メールに対する承認実行の要求を受け付け，
   前記承認が依頼された電子メールが返信である場合に，前記返信管理情報を参照して，前記承認が依頼された電子メールの返信元の電子メールと同じスレッドの電子メールである第３の関連メールを抽出し，
   前記コメント管理情報を参照して，前記第３の関連メールに対する第３のコメントを取得し，
   前記第３のコメントを提示する画面を含む，前記承認が依頼された電子メールの承認画面を生成し，
   前記生成された承認画面を出力する
   処理を実行させるための請求項１または請求項２に記載のメール処理プログラム。
4. 電子メール間の返信関係を管理する返信管理情報の記憶部と，
   電子メールに対して過去に記述されたコメントを管理するコメント管理情報の記憶部と，
   電子メールの作成の要求を受け付け，該作成する電子メールの作成画面を生成し，生成した作成画面を出力するメッセージ作成処理部と，
   前記作成する電子メールが返信である場合に，前記返信管理情報を参照して，前記作成する電子メールの返信元の電子メールと同じスレッドの電子メールである第１の関連メールを抽出し，前記コメント管理情報を参照して，第１の関連メールに対する第１のコメントを取得する関連コメント取得部とを備え，
   前記メッセージ作成処理部は，前記作成画面を生成する際に，前記第１のコメントを提示する画面を含む前記作成画面を生成する
   ことを特徴とするメール処理装置。
5. コンピュータが，
   電子メールの作成の要求を受け付け，
   前記電子メールが返信である場合に，記憶部に記憶された，電子メール間の返信関係を管理する返信管理情報を参照して，前記電子メールの返信元の電子メールと同じスレッドの電子メールである第１の関連メールを抽出し，
   記憶部に記憶された，電子メールに対して過去に記述されたコメントを管理するコメント管理情報を参照して，前記第１の関連メールに対する第１のコメントを取得し，
   前記第１のコメントを提示する画面を含む，前記作成する電子メールの作成画面を生成し，
   前記生成された作成画面を出力する処理を実行する
   ことを特徴とするメール処理方法。

Images