(58)【調査した分野】(Int.Cl.,DB名)
前記分類情報格納部に格納する処理では、前記メール情報格納部に格納されたメールの識別情報を前記送信者と受信者との関係以外の情報で更に分類して前記分類情報格納部に格納することを特徴とする請求項1に記載のメール処理プログラム。
前記送信者と受信者との関係以外の情報は、前記メール情報格納部に格納されたメールに対する特定の処理が行われた日時の情報であることを特徴とする請求項2に記載のメール処理プログラム。
【発明を実施するための形態】
【0012】
以下、電子メールシステムの一実施形態について、
図1〜
図29に基づいて詳細に説明する。
図1には、一実施形態に係る電子メールシステム100が概略的に示されている。
【0013】
本実施形態の電子メールシステム100は、
図1に示すように、メール処理装置としてのサーバ10と、表示装置としてのクライアント20と、を備える。サーバ10とクライアント20は、インターネットやLAN(Local Area Network)などのネットワーク80に接続されている。この電子メールシステム100は、クライアント20においてブラウザ上に表示されるWEBメールの画面(サーバ10から提供)において、利用者(ユーザ)が入力や操作を行うことで、クライアント20間における電子メールのやり取りを可能にするシステムである。
【0014】
図2(a)には、サーバ10のハードウェア構成が示されている。
図2(a)に示すように、サーバ10は、CPU(Central Processing Unit)90、ROM(Read Only Memory)92、RAM(Random Access Memory)94、記憶部(ここではHDD(Hard Disk Drive))96、ネットワークインタフェース97、及び可搬型記憶媒体用ドライブ99等を備えている。これらサーバ10の構成各部は、バス98に接続されている。サーバ10では、ROM92あるいはHDD96に格納されているプログラム(処理プログラムを含む)、或いは可搬型記憶媒体用ドライブ99が可搬型記憶媒体91から読み取ったプログラム(処理プログラムを含む)をCPU90が実行することにより、
図3に示すメール処理部40としての機能が実現される。メール処理部40は、電子メールの送受信のほか、クライアント20上で表示する画面を生成し、送信するなどの機能を有する。なお、
図3には、サーバ10のHDD96等に格納されている人事DB(database)30、メールDB32、属性設定DB34、発信時職制DB36、分類情報格納部としての属性別受信DB(発信時)38、最新分類情報格納部としての属性別受信DB(現在)39も図示されている。なお、各DB30〜39の具体的なデータ構造等については後述する。なお、以下においては、電子メールを「メール」と略述するものとする。
【0015】
図2(b)には、クライアント20のハードウェア構成が示されている。
図2(b)に示すように、クライアント20は、CPU190、ROM192、RAM194、記憶部(HDD)196、表示部193、入力部195、ネットワークインタフェース197、及び可搬型記憶媒体用ドライブ199等を備えており、クライアント20の構成各部は、バス198に接続されている。表示部193は、液晶ディスプレイ等を含み、入力部195は、キーボードやマウス、タッチパネル等を含む。クライアント20においては、CPU190がプログラムを実行することで、
図3に示す表示処理部50及び入力処理部52としての機能が実現される。表示処理部50は、サーバ10のメール処理部40からの指示に応じて、クライアント20の表示部193上にメール閲覧、メール作成、送受信に関する画面等を表示する。入力処理部52は、クライアント20の利用者が入力部195を介して入力した情報を受け付け、当該情報をサーバ10のメール処理部40に対して送信する。
【0016】
ここで、サーバ10が有する各種DBについて説明する。
【0017】
図4、
図5には、人事DB30のデータ構造の一例が示されている。
図4は、更新前の人事DB(人事DB(旧))、
図5は更新後の人事DB(人事DB(現在))の例を示している。人事DB30は、会社に属する人物の人事情報を格納するデータベースである。人事DB30は、
図4、
図5に示すように、「利用者アドレス(ID)」、「パスワード」、「利用者氏名」、「役職」、「役職フラグ」、「所属課コード」、「課名」、「所属部コード」、「部名」、「所属本部コード」、「本部名」、「グループ」の各フィールドを有する。
【0018】
「利用者アドレス(ID)」のフィールドには、利用者が有するメールアドレス(利用者ID)が格納される。「パスワード」のフィールドには、利用者それぞれが設定したパスワードが格納される。「利用者氏名」のフィールドには、利用者の氏名(
図4、
図5では氏のみ)が格納され、「役職」のフィールドには、利用者の役職名が格納される。「役職フラグ」のフィールドには、役職ごとに設定されたフラグが格納される。
図4、
図5では、一般が「0」、課長が「1」、部長が「2」、本部長が「3」というように、各役職にフラグが設定されている。「所属課コード」のフィールドには、利用者が属する課に割り当てられたコードが格納され、「課名」のフィールドには、特許課や意匠課、商標課、契約課などの、利用者が属する課の名称が格納される。「所属部コード」のフィールドには、利用者が属する部に割り当てられたコードが格納され、「部名」のフィールドには、知財部や法務部などの、利用者が属する部の名称が格納される。また、「所属本部コード」のフィールドには、利用者が属する本部に割り当てられたコードが格納され、「本部名」のフィールドには、利用者が属する課の名称が格納される。更に、「グループ」のフィールドには、利用者が属するグループの名称が格納される。なお、
図4、
図5では、人事異動によって、利用者「富士」が法務部契約課から知財部特許課に異動した状態が示されている。
【0019】
図6には、メールDB32のデータ構造の一例が示されている。メールDB32は、利用者ごとに用意されるデータベースであり、各利用者が送受信したメールを格納するデータベースである。メールDBは、
図6に示すように、「受送信区分」、「メッセージID」、「発信者アドレス(利用者アドレス)」、「宛先」、「開封状況」、「発信日時」、「メール情報(件名、本文)」の各フィールドを有する。
【0020】
「受送信区分」のフィールドには、利用者が「受信」したメールであるか、「送信」したメールであるかを示す区分が格納される。「メッセージID」のフィールドには、メールごとに定められるユニークなIDが格納される。「発信者アドレス(利用者アドレス)」のフィールドには、メールの発信者(送信者)のアドレスが格納される。なお、「受送信区分」のフィールドが「送信」であるメールの場合、「発信者アドレス(利用者アドレス)」のフィールドには、メールDB32の利用者のアドレスが格納されることになる。「宛先」のフィールドには、メールの宛先のアドレスが1又は複数格納される。なお、「受送信区分」のフィールドが「受信」であるメールの場合、「宛先」のフィールドに格納されるアドレスには、メールDB32の利用者のアドレスが含まれることになる。「開封状況」のフィールドには、利用者がメールを閲覧したか否かの情報が格納される。一例として、
図6では、開封状況が「1」であれば、開封済み(閲覧済み)を意味し、開封状況が「0」であれば、未開封(未閲覧)を意味する。「発信日時」のフィールドには、メールを発信した年月日及び時刻の情報が格納され、「メール情報(件名、本文)」のフィールドには、メールの件名及び本文そのものが格納される。
【0021】
図7には、属性設定DB34のデータ構造の一例が示されている。属性設定DB34は、利用者がどのようにメールを表示するかを設定した結果を格納するデータベースである。属性設定DB34は、
図7に示すように、「利用者アドレス」、「同課」、「同部(同課含めず)」、「同部(同課含める)」、「上司(範囲)」、「部下(範囲)」、「他部全員」、「他部幹部」、「他部一般」、「社外」の各フィールドを有する。
【0022】
例えば、利用者アドレスが「inoue@x.jp」のレコードでは、「同課」、「同部(同課含めず)」、「他部全員」、「社外」のフィールドにフラグ「1」が格納されている。したがって、属性設定DB34によれば、利用者「井上」は、「同課」、「同部(同課含めず)」、「他部全員」、「社外」の4つの属性でメールを区分けして表示すると、設定したことになる。また、「部下(範囲)」のフィールドに「2」が格納されているので、利用者「井上」は、同組織の二階層下の職位までを部下として設定し、「部下」の属性でもメールを区分けして表示すると、設定したことになる。
【0023】
また、例えば、利用者アドレスが「yamada@x.jp」のレコードでは、「同部(同課含める)」、「他部全員」、「社外」のフィールドにフラグ「1」が格納されている。したがって、属性設定DB34によれば、利用者「山田」は、「同部(同課含める)」、「他部全員」、「社外」の3つの属性でメールを区分けして表示すると、設定したことになる。また、「上司(範囲)」、「部下(範囲)」のフィールドに「1」が格納されているので、利用者「山田」は、同組織の一階層上の職位を上司とし、同組織の一階層下の職位までを部下として設定し、「上司」及び「部下」の属性でもメールを区分けして表示すると、設定したことになる。
【0024】
図8には、発信時職制DB36のデータ構造の一例が示されている。発信時職制DB36は、メールが送受信された場合において、当該メールが送受信された時点における発信者(送信者)と受信者(宛先)の情報(関係)を格納するデータベースである。発信時職制DB36は、
図8に示すように、「メッセージID」、「発信者情報」、「受信者(宛先)情報」の各フィールドを有する。
【0025】
「メッセージID」のフィールドには、メールDB32にメールの情報が格納される際に割り振られたメッセージIDが格納される。「発信者情報」のフィールドには、発信者のメール発信時における職制の情報が格納される。具体的には、発信者の利用者ID、役職フラグ、課コード、部コード、本部コードが入力される。なお、
図8に格納される発信者情報は、人事DB30から取得可能である。「受信者(宛先)情報」のフィールドには、メール発信時における受信者(宛先)の職制の情報が格納される。格納される具体的な情報は、発信者情報と同一である。
【0026】
図9には、属性別受信DB(発信時)38のデータ構造の一例が示されている。属性別受信DB(発信時)38は、利用者ごとに用意されるデータベースである。属性別受信DB(発信時)38には、所定期間における各属性(属性設定DB34で設定されている属性)の利用者から受信したメールの件数等が格納される。属性別受信DB(発信時)38は、期間を定義する「開始日」、「終了日」と、利用者において属性設定DB34で設定されている属性ごとの「件数」、「未開封件数」、「メッセージID」が格納される。「件数」には、各属性に属する利用者から送信されたメールの件数が入力され、「未開封件数」には、各属性に属する利用者から送信されたメールのうち未開封であるメールの件数が入力される。また、「メッセージID」には、各属性に属する利用者から送信されたメールに割り振られたメッセージIDが格納される。
【0027】
図10には、属性別受信DB(現在)39のデータ構造の一例が示されている。属性別受信DB(現在)39は、利用者ごとに用意されるデータベースであり、最新の人事DB30において各属性(属性設定DB34で設定されている属性)に属する利用者から受信したメールの件数等を所定期間ごとに格納する。属性別受信DB(現在)39のデータ構造は、属性別受信DB(発信時)38のデータ構造と同一であるが、
図10において太線枠にて示す部分のデータが、
図9とは異なっている。
【0028】
(メール処理部40の処理について)
次に、本実施形態におけるメール処理部40の処理について、
図11〜
図13のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。
【0029】
図9の処理では、まず、ステップS10において、メール処理部40が、メール表示要求をクライアント20から受信するまで待機する。クライアント20の利用者は、クライアント20の表示部193上に表示されているブラウザ上でWEBメールサービスのアドレスに対してアクセスすることによりメール利用要求を出すことができる。なお、メール利用要求は、クライアント20の入力処理部52から送信される。
【0030】
メール処理部40は、入力処理部52から送信されてきたメール利用要求を受信すると(ステップS10の判断が肯定されると)、ステップS12に移行する。ステップS12では、メール処理部40が、利用者ID(メールアドレス),パスワード入力画面をクライアント20に送信する。この場合の利用者ID、パスワード入力画面は、
図14(a)に示すような画面であるものとする。なお、クライアント20においては、表示処理部50が、受信した利用者ID、パスワード入力画面を表示部193上に表示する。
【0031】
次いで、ステップS14に移行すると、メール処理部40は、利用者ID(メールアドレス)、パスワードをクライアント20から受信するまで待機する。なお、利用者が利用者IDとパスワードを
図14(a)の画面上で入力し、「送信」ボタンを押すと、入力処理部52は、利用者IDとパスワードをメール処理部40に送信する。
【0032】
入力処理部52によって利用者IDとパスワードがメール処理部40に対して送信されると(ステップS14の判断が肯定されると)、ステップS16に移行する。ステップS16では、メール処理部40が、人事DB30(
図5)を用いて、利用者の認証を行う。すなわち、メール処理部40は、入力された利用者ID(メールアドレス)とパスワードの組み合わせが人事DB30に存在しているか否かを判断する。次いで、ステップS18では、メール処理部40が、認証がOKであったか否かを判断する。ここでの判断が否定された場合には、
図11〜
図13の全処理を終了する。なお、ステップS18の判断が否定された後、
図11〜
図13の全処理を終了する前に、メール処理部40が、認証エラー画面(
図14(b))をクライアント20(表示処理部50)に対して送信することとしてもよい。この場合、表示処理部50は、
図14(b)の画面を表示部193上に表示する。
【0033】
一方、ステップS18の判断が肯定された場合、すなわち、認証がOKであった場合には、ステップS20に移行する。ステップS20では、メール処理部40は、処理に用いる属性別受信DB(対象属性別受信DBと呼ぶ)を、属性別受信DB(発信時)38として定める。
【0034】
次いで、ステップS22では、メール処理部40が、利用者のメールDB32から、受信メールの情報を取得し、受信メール一覧画面(
図15参照)を作成し、当該画面のデータをクライアント20(表示処理部50)に送信する。表示処理部50は、
図15の受信メール一覧画面を表示部193上に表示する。
【0035】
次いで、
図12のステップS24に移行すると、メール処理部40は、クライアント20から、差出人属性表示要求を受信したか否かを判断する。ここでの判断が肯定された場合には、ステップS26に移行する。なお、クライアント20の利用者は、差出人属性表示要求を出す場合には、
図15の受信メール一覧表示画面において、「差出人属性振り分け」ボタンを押すものとする。利用者が当該ボタンを押した場合、入力処理部52は、差出人属性表示要求をメール処理部40に対して送信する。
【0036】
メール処理部40は、差出人属性表示要求を受信すると、ステップS26に移行し、属性設定DB34(
図7)にクライアント20の利用者のIDが含まれているか否かを判断する。なお、このステップS26では、利用者が属性設定を既に行っているか否かを判断しているともいえる。なお、属性設定とは、受信メールを属性別に表示する場合において、どの属性の表示を行うかを設定することをいう。
【0037】
ステップS26の判断が否定された場合、すなわち、属性設定が未だ行われていない場合には、ステップS28に移行し、メール処理部40は、属性登録処理のサブルーチンを実行する。以下、属性登録処理のサブルーチンについて、
図16のフローチャートに沿って説明する。
【0038】
(属性登録処理)
図16の処理では、まず、ステップS120において、メール処理部40が、属性設定DB34の「利用者アドレス」以外の全てのフィールド名を取得し、属性設定画面(初期画面)(
図17参照)を作成する。そして、メール処理部40は、作成した画面のデータをクライアント20の表示処理部50に対して送信する。なお、
図17の属性設定画面では、利用者は、登録(現在設定されていないもの)に含まれる項目(属性)を選択し、「確定」ボタンを押すことで、登録(属性設定)することができるようになっている。なお、利用者は、属性を1又は複数選択することができる。
【0039】
次いで、ステップS122では、メール処理部40が、属性の選択をクライアント20から受信するまで、すなわち、クライアント20の利用者が属性を選択し、「確定」ボタンを押すまで待機する。利用者が属性設定画面において「確定」ボタンを押すと、メール処理部40は、ステップS124に移行し、属性設定DB34に利用者アドレスを登録するとともに、選択された属性のフラグを1にし、他の属性を0にする。
【0040】
次いで、ステップS126では、メール処理部40が、利用者が上司あるいは部下を選択したか否か、すなわち、属性「上司」又は「部下」のフラグが1となっているか否かを判断する。ここでの判断が否定された場合には、
図16の全処理を終了する(
図12のステップS30に移行する)が、肯定された場合には、ステップS128に移行する。
【0041】
ステップS128に移行すると、メール処理部40は、人事DB30の内容を用いて、上司部下設定画面(
図18(a),
図18(b)参照)を作成し、当該画面のデータをクライアント20(表示処理部50)に対して送信する。この場合、メール処理部40は、人事DB30において利用者の役職フラグよりも大きいフラグ及び小さいフラグがあるか否かに基づいて、上司部下設定画面を作成する。なお、
図18(a)は、人事DB30の役職が「一般」である場合(役職フラグが0)の例を示し、
図18(b)は、人事DB30の役職が「課長」である場合(役職フラグが1)の例を示している。表示処理部50は、上司部下設定画面のデータを取得すると、当該画面を表示部193上に表示する。なお、クライアント20の利用者は、上司設定及び部下設定において、何階層上までを上司とし、何階層下までを部下とするかの範囲情報を入力することができる。そして、入力処理部52は、利用者から範囲情報が入力された場合(「確定」ボタンが押された場合)に、当該情報をメール処理部40に対して送信する。
【0042】
次いで、ステップS130では、メール処理部40が、上司あるいは部下の範囲情報を入力処理部52から受信するまで待機する。そして、受信した後は、ステップS132に移行する。ステップS132では、メール処理部40は、受信した範囲を示す数字を、上司部下属性フラグとして、属性設定DB34に記録する。
図7の利用者アドレス「kuroda@x.jp」の例では、上司として2階層上までが選択された場合が示されている。
【0043】
以上のようにして、
図16の属性登録処理(S28)が終了すると、メール処理部40は、
図12のステップS30に移行する。なお、
図12のステップS26の判断が肯定された場合、すなわち、既に利用者の属性設定が行われていた場合には、上述したステップS28のサブルーチンの処理(
図16の処理)を実行せずに、ステップS30に移行する。
【0044】
ステップS30に移行した場合、メール処理部40は、属性別受信DB作成処理のサブルーチンを実行する。以下、属性別受信DB作成処理のサブルーチンについて、
図19のフローチャートに沿って説明する。
【0045】
(属性別受信DB作成処理)
図19の処理では、まず、ステップS160において、メール処理部40が、発信時職制DB36(
図8)と、メールDB32(
図6)の内容に基づいて、メールの発信時の(発信者、受信者の)職制コードを比較する。そして、メール処理部40は、属性設定DB34(
図7)に設定された属性の利用者が送信したメールの件数、開封状況、メッセージIDを属性別受信DB(発信時)38(
図9)に記録する。ここでは、メール処理部40は、メールの発信者と受信者の関係に基づいてメッセージIDを分類し、属性別受信DB(発信時)38に格納していることになる。なお、発信時職制DB36は、前述のように、メール送信が行われる度に、当該メールが送信された時点における送信者と受信者(宛先)の職制コード(役職フラグ、課コード、部コード、本部コード)が登録されるデータベースである。この発信時職制DB36へのデータ登録については、
図23の処理(メール送信処理)において説明する。
【0046】
次いで、ステップS162では、メール処理部40が、メールDB32と人事DB30に基づいて、メールの発信者と受信者の現在の職制コードを比較し、属性設定DB34に設定された属性の件数、開封状況を属性別受信DB(現在)39(
図10)に記録する。
【0047】
次いで、ステップS164では、メール処理部40は、属性設定DB34の上司あるいは部下のフラグが1以上か否かを判断する。ここでの判断が否定された場合、すなわち、上司及び部下のフラグが0であった場合には、
図19の全処理を終了する。一方、ステップS164の判断が肯定された場合には、ステップS166に移行する。
【0048】
ステップS166に移行した場合、メール処理部40は、上司部下範囲情報を
図7の属性設定DB34から取得する。例えば、利用者アドレス「inoue@x.jp」であれば、属性設定DB34から、上司の範囲=0、部下の範囲=2を取得する。次いで、ステップS168では、メール処理部40は、メールDB32と、発信時職制DB36の役職フラグと、職制コードと、上司部下範囲情報を用いて、メールの発信時の(発信者、受信者の)上司部下範囲のメールを抽出する。そして、メール処理部40は、上司部下属性に属する利用者が送信したメールの件数、開封状況、メッセージIDを属性別受信DB(発信時)38に記録する。例えば、利用者アドレス「inoue@x.jp」は、品質管理本部の本部長であるので、当該品質管理本部の部長及び課長のメールを抽出して、当該メールの情報を属性別受信DB(発信時)38に記録する。
【0049】
次いで、ステップS170では、メール処理部40が、メールDB32と、人事DB30の役職フラグ及び職制コードとを利用し、メールの発信者、受信者の上司部下範囲のメールを抽出し、上司部下属性の件数、開封状況を属性別受信DB(現在)39に記録する。
【0050】
以上のような処理を行うことで、属性別受信DB(発信時)38(
図9)においては、各メールが発信されたときの発信者と受信者との関係に基づいた件数、未開封件数、メッセージIDの分類がされることになる。一方、属性別受信DB(現在)39(
図10)においては、現在の発信者と受信者との関係に基づいた件数、未開封件数、メッセージIDの分類がされることになる。
【0051】
図12に戻り、上述したステップS30の属性別受信DB作成処理の後は、ステップS32に移行する。ステップS32では、メール処理部40が、対象属性別受信DBを用いて、属性別表示画面(
図20)を作成し、当該画面のデータをクライアント20(表示処理部50)に送信する。なお、ここでは、対象属性別受信DBとして、属性別受信DB(発信時)38が設定されているものとする(
図11のステップS20参照)。
【0052】
図20の属性別表示画面には、所定期間内(1週間)に受信したメールの総数と、各期間に受信したメールの送信者の属性ごとのメール件数、未開封件数が帯グラフにて示されている。表示処理部50は、
図20の属性別表示画面のデータを受信すると、表示部193上に属性別表示画面を表示する。なお、クライアント20の利用者は、
図20の属性別表示画面上において、各エリアを選択できるものとする。利用者がエリアのいずれかを選択した場合には、入力処理部52は、選択したエリアの情報をメール処理部40に対して送信する。
【0053】
次いで、ステップS34では、メール処理部40が、属性別表示画面のいずれかのエリアが選択されるまで待機する。そして、エリアが選択された情報を入力処理部52から受信すると、ステップS36に移行する。ステップS36では、メール処理部40が、対象属性別受信DB(ここでは、属性別受信DB(発信時)38)から、選択された期間及び選択された属性に対応するメッセージIDを取得する。例えば、利用者によって、期間(2012/8/6〜2012/8/12)の属性「他部幹部」が選択された場合には、
図9から、メッセージID「0011」、「0006」、「0005」、「0003」が取得される。
【0054】
次いで、ステップS38では、メール処理部40が、取得したメッセージIDに対応する情報をメールDB32から取得し、メール一覧表示画面(
図21)を生成する。なお、
図21のメール一覧画面は、2012/8/6〜12の期間の、属性「他部幹部」のメール一覧を表示する画面である。
【0055】
次いで、ステップS40では、メール処理部40が、メール一覧表示画面のデータをクライアント20(表示処理部50)に対して送信する。表示処理部50では、メール一覧表示画面のデータを受信した段階で、メール一覧表示画面を表示部193上に表示する。なお、ステップS40の処理が終了すると、ステップS60に移行する。
【0056】
ところで、ステップS24の判断が否定された場合、すなわち、利用者によって、
図15の「差出人属性振り分け」ボタンが押されていない場合には、ステップS42に移行する。
【0057】
ステップS42に移行した場合、メール処理部40は、受信メール一覧画面(
図15)上で、利用者によってメールが選択されたという情報を受信したか否かを判断する。ここでの判断が否定された場合には、ステップS54に移行するが、肯定された場合には、ステップS44に移行する。
【0058】
ステップS44に移行した場合(いずれかのメールが選択された場合)、メール処理部40は、メールDB32の、選択されたメールの開封状況を1にする。次いで、ステップS46では、メール処理部40は、属性設定DB34にその利用者IDがあるか否かを判断する。ここでの判断が肯定された場合、ステップS48に移行する。なお、ステップS48に移行する場合とは、利用者に対応する属性別受信DB38,39(
図9、
図10)が既に存在している場合を意味する。
【0059】
ステップS48に移行すると、メール処理部40は、属性別受信DB(現在)39と、属性別受信DB(発信時)38との、選択されたメールのメッセージIDが含まれている未開封件数をデクリメント(−1)する。その後は、ステップS50に移行する。なお、ステップS46の判断が否定された場合、すなわち、利用者に対応する属性別受信DB38,39が未だ存在していない場合には、ステップS48を経ずに、ステップS50に移行する。
【0060】
ステップS50に移行すると、メール処理部40は、選択されたメールの件名や本文などの情報を取得し、メッセージ表示画面(
図22)のデータを作成し、クライアント20(表示処理部50)に対して送信する。表示処理部50は、メッセージ表示画面のデータを受信した段階で、表示部193上にメッセージ表示画面を表示する。ステップS50の後は、ステップS52に移行する。
【0061】
ステップS52に移行すると、メール処理部40は、クライアント20の入力処理部52から件名一覧表示の要求を受信したか否かを判断する。なお、件名一覧表示の要求は、クライアント20の利用者が
図22のメッセージ表示画面において「一覧に戻る」ボタンを押した段階で、入力処理部52が出力するものである。
【0062】
ステップS52の判断が肯定された場合には、
図11のステップS22に戻るが、判断が否定された場合には、ステップS54に移行する。
【0063】
ステップS52の判断が否定され、又はステップS42の判断が否定され、ステップS54に移行すると、メール処理部40は、メール送信要求を受信したか否かを判断する。なお、メール送信要求は、クライアント20の利用者が
図22のメッセージ表示画面において「返信」ボタンを押した段階、又は、
図15の受信メール一覧表示画面において「メール送信」ボタンを押した段階で、入力処理部52が出力する。
【0064】
ステップS54の判断が否定された場合には、ステップS58に移行するが、判断が肯定された場合には、ステップS56のメール送信処理のサブルーチンを実行する。以下、メール送信処理のサブルーチンについて、
図23のフローチャートに沿って説明する。
【0065】
(メール送信処理)
図23の処理では、まず、ステップS200において、メール処理部40が、メッセージ作成画面(
図24)のデータを生成し、クライアント20(表示処理部50)に対して送信する。表示処理部50では、当該データを受信した段階で、表示部193上にメッセージ作成画面(
図24)を表示する。なお、利用者が
図22のメッセージ表示画面において「返信」ボタンを押した後に、ステップS200に移行した場合には、メール処理部40は、返信用のメッセージ作成画面を生成するものとする。
図22のメールに対する返信の場合、メッセージ作成画面として、宛先欄に
図22の差出人欄の利用者アドレスが入力され、件名に「Re:訃報」が入力され、本文入力画面に
図22の本文から生成した引用文を入力されたメッセージ作成画面を生成する。
【0066】
次いで、ステップS202では、メール処理部40が、宛先、タイトル、本文、発信者IDを入力処理部52から受信するまで待機する。なお、入力処理部52は、利用者が、
図24の画面上において必要事項を入力し、「送信」ボタンを押した段階で、宛先、件名、本文、発信者IDをメール処理部40に対して送信する。この送信が行われた段階で、ステップS204に移行する。
【0067】
ステップS204に移行すると、メール処理部40は、メッセージIDを生成し、件名及び本文を宛先のメールDB32の受送信区分が「受信」のレコードとして記録する。
【0068】
次いで、ステップS206では、メール処理部40が、メッセージID、件名、本文を利用者(送信者)のメールDB32の送信の欄に記録する。次いで、ステップS208では、メール処理部40が、宛先のそのときの職制コードと、利用者(送信者)の職制コードと、メッセージIDとを対応づけて、発信時職制DB36に記録する。例えば、メッセージIDが「0012」の場合、発信者情報として、利用者「田中」の利用者ID「tanaka@x.jp」と職制コードが入力され、受信者情報として、利用者「黒田」の利用者ID「kuroda@x.jp」と職制コードが入力される。
【0069】
次いで、ステップS210では、メール処理部40が、属性設定DB34にメールを送信した宛先の利用者IDがあるか否かを判断する。すなわち、メール処理部40は、宛先の利用者に対応する属性別受信DB(発信時)38、属性別受信DB(現在)39が既に存在しているか否かを判断する。ここでの判断が肯定された場合には、ステップS212に移行するが、否定された場合には、
図23の全処理を終了する。
【0070】
ステップS212に移行すると、メール処理部40は、宛先(利用者ID)に対応する属性別受信DB(発信時)38、属性別受信DB(現在)39を取得する。次いで、ステップS214では、メール処理部40は、取得した属性別受信DB(発信時)38、属性別受信DB(現在)39のそのメールの属性に対応する件数、未開封件数をインクリメント(+1)するとともに、そのメールのメッセージIDを追加する。
【0071】
上記のようにして、
図23の処理が終了すると、
図12のステップS58に移行する。
【0072】
ステップS56の後又はステップS54の判断が否定された後にステップS58に移行すると、メール処理部40は、ログアウト要求を入力処理部52から受信したか否かを判断する。なお、ログアウト要求は、利用者が、表示部193上に表示されている画面上の「ログアウト」ボタンを押した段階で、入力処理部52からメール処理部40に対して送信される。ログアウト要求が出されると、メール処理部40は、
図11〜
図13の全処理を終了するが、ログアウト要求が出されていなければ、ステップS42に戻る。
【0073】
ところで、前述したステップS40の処理が行われた後、
図13のステップS60に移行すると、メール処理部40は、メールが選択されたか否かを判断する。なお、この段階では、クライアント20の表示部193上には、メール一覧表示画面(
図21)が表示された状態であり、利用者が
図21の画面上においてメールを選択した場合、ステップS60の判断が肯定される。このように、ステップS60の判断が肯定されると、ステップS62に移行する。
【0074】
ステップS62に移行すると、メール処理部40は、メールDB32の、選択されたメールの開封状況を1にする。次いで、ステップS64では、メール処理部40が、属性別受信DB(現在)39と、属性別受信DB(発信時)38との、選択されたメールのメッセージIDが含まれている未開封件数をデクリメント(−1)する。次いで、ステップS66では、メール処理部40が、選択されたメールの本文などの情報を取得し、メッセージ表示画面(
図22)のデータを作成し、クライアント20(表示処理部50)に送信する。表示処理部50は、当該データを受信した段階で、メッセージ表示画面を表示部193上に表示する。その後は、ステップS68に移行する。
【0075】
一方、ステップS60の判断が否定された場合には、ステップS70に移行する。ステップS70では、メール処理部40が、利用者によって
図21のメール一覧表示画面上の「進む」又は「戻る」ボタンが押下されたか否かを判断する。ここでの判断が肯定されると、ステップS72に移行し、メール処理部40は、同じ属性の次の期間あるいは前の期間(進む・戻るに対応)のメッセージIDを対象属性別受信DB(属性別受信DB(発信時)38又は属性別受信DB(現在)39)から取得し、メール一覧表示画面を作成する。そして、メール処理部40は、作成したメール一覧表示画面のデータをクライアント20(表示処理部50)に対して送信する。なお、同じ属性の次の期間あるいは前の期間(進む・戻るに対応)にメッセージIDが存在していない場合には、
図25に示すようなメール一覧表示画面が作成される。この
図25のメール一覧表示画面には、メッセージ「この期間の、指定の属性のメールはありません」が表示されている。なお、表示処理部50は、メール一覧表示画面のデータを受信した段階で、表示部193上にメール一覧表示画面を表示する。なお、その後は、ステップS70に戻る。
【0076】
一方、ステップS70の判断が否定された場合(「進む」、「戻る」ボタンが押されていない場合)には、ステップS74に移行する。ステップS74では、メール処理部40が、入力処理部52から現在属性表示要求を受信したか否かを判断する。なお、現在属性表示要求は、利用者が、
図21や
図25において、「発信時/現在属性表示」ボタンを押した場合、又は
図20において、「現在属性表示」ボタンを押した場合に、入力処理部52からメール処理部40に対して出力される。ステップS74の判断が肯定された場合には、ステップS76に移行し、メール処理部40は、対象属性別受信DBとして、属性別受信DB(現在)39を設定し、
図12のステップS32に戻る。なお、ステップS32が実行されることにより、クライアント20の表示部193上には、
図26に示すような、
図10の属性別受信DB(現在)39に基づいた、属性別表示画面が表示されることになる。その後は、
図26の画面を用いた、ステップS34以降の処理が行われることになる。
【0077】
一方、
図13のステップS74の判断が否定された場合には、ステップS78に移行する。
【0078】
ステップS78では、メール処理部40が、入力処理部52から発信時属性表示要求を受信したか否かを判断する。なお、発信時属性表示要求は、利用者が、
図21や
図25において、「発信時/現在属性表示」ボタンを押した場合、又は
図26において、「現在属性表示」ボタンを押した場合に、入力処理部52からメール処理部40に対して出力される。ステップS78の判断が肯定された場合には、ステップS80に移行し、メール処理部40は、対象属性別受信DBを、属性別受信DB(発信時)とし、
図12のステップS32に戻る。
【0079】
一方、ステップS78の判断が否定された場合には、ステップS82に移行する。ステップS82に移行した場合、メール処理部40は、設定変更要求を受信したか否かを判断する。設定変更要求は、利用者が
図20や
図26の属性別表示画面上において「設定変更」ボタンを押した場合に、入力処理部52からメール処理部40に対して出力される。ステップS82の判断が肯定された場合には、ステップS84に移行する。以下、ステップS84の属性更新処理のサブルーチンについて、
図27のフローチャートに沿って説明する。
【0080】
(属性更新処理)
図27の処理では、まず、ステップS220において、メール処理部40が、属性設定DB34の情報を用い、属性設定画面(更新画面)(
図28参照)を作成し、クライアント20の表示処理部50に対して送信する。ここで、
図28の属性設定画面(更新画面)の右欄(削除(現在設定されているもの))には、既に設定されている属性が表示されている。また、
図28の左欄(登録(現在設定されていないもの))には、全属性のうち、右欄に表示されていない属性(現在設定されていない属性)が表示されている。なお、
図28の属性設定画面では、登録(現在設定されていないもの)に含まれる項目(属性)を選択し、「確定」ボタンを押すことで登録することができるようになっている。また、削除(現在設定されているもの)に含まれる項目(属性)を選択し、「確定」ボタンを押すことで削除することができるようになっている。なお、利用者は、属性を1又は複数選択することができる。
【0081】
次いで、ステップS222では、メール処理部40が、属性の選択をクライアント20から受信するまで、すなわち、クライアント20の利用者が属性を選択し、「確定」ボタンを押すまで待機する。利用者が「確定」ボタンを押すと、メール処理部40は、ステップS224に移行し、属性設定DB34の、利用者アドレスに対応する項目を更新する(登録された属性のフラグを1にし、削除された属性のフラグを0にする)。
【0082】
次いで、ステップS226では、メール処理部40が、フラグが0から1になった項目に上司あるいは部下があるか否かを判断する。ここでの判断が否定された場合には、
図27の全処理を終了するが、肯定された場合には、ステップS228に移行する。
【0083】
ステップS228に移行すると、メール処理部40は、人事DB30の内容を用いて、上司部下設定画面(
図18(a),
図18(b)参照)を作成し、クライアント20(表示処理部50)に対して送信する。表示処理部50は、上司部下設定画面のデータを取得すると、当該画面を表示部193上に表示する。なお、クライアント20の利用者は、上司設定及び部下設定において、何階層上までを上司とし、何階層下までを部下とするかの範囲情報を入力することができる。入力処理部52は、利用者から範囲情報が入力されると、当該情報をメール処理部40に対して送信する。
【0084】
次いで、ステップS230では、メール処理部40が、上司あるいは部下の範囲情報を入力処理部52から受信するまで待機する。そして、受信した後は、ステップS232に移行する。ステップS232では、メール処理部40は、受信した範囲を示す数字を、上司部下属性フラグとして、属性設定DB34に記録する。
【0085】
以上のようにして、
図27の属性更新処理(S84)が終了すると、メール処理部40は、
図13のステップS68に移行する。なお、
図13のステップS82の判断が否定された場合、すなわち、設定変更要求を受信しなかった場合には、上述したステップS84のサブルーチンの処理を実行せずに、ステップS68に移行する。
【0086】
図13のステップS68では、メール処理部40が、受信メール一覧表示の要求を受信したか否かを判断する。受信メール一覧表示の要求は、利用者が、
図20、
図26等の画面において、「一覧に戻る」ボタンを押した場合に、入力処理部52からメール処理部40に対して出力される。ステップS68の判断が否定された場合には、
図11のステップS22に戻る。一方、ステップS68の判断が否定された場合には、ステップS86に移行する。
【0087】
ステップS86に移行した場合、メール処理部40は、メール送信要求を受信したか否かを判断する。メール送信要求は、利用者が、
図22等の画面において、「返信」ボタンを押した場合に、入力処理部52からメール処理部40に対して出力される。ステップS86の判断が肯定された場合には、ステップS88に移行し、否定された場合には、ステップS90に移行する。なお、ステップS88の処理は、前述したステップS56と同様、
図23のフローチャートに沿って行われる。したがって、ステップS88の詳細な説明については省略する。ステップS88の処理が終了した後は、ステップS90に移行する。
【0088】
ステップS90に移行すると、メール処理部40は、ログアウト要求を受信したか否かを判断する。ログアウト要求は、利用者が、表示部193上に表示されている画面上の「ログアウト」ボタンを押した段階で、入力処理部52からメール処理部40に対して送信される。ログアウト要求が出されると、メール処理部40は、
図11〜
図13の全処理を終了するが、ログアウト要求が出されていなければ、ステップS60(
図13の先頭の処理)に戻る。
【0089】
ところで、メール処理部40は、
図11〜
図13の処理を実行するのと並行して、
図29のフローチャートに沿った処理も実行する。以下、
図29の処理について説明する。
【0090】
図29の処理では、まず、ステップS300において、メール処理部40が、人事DB30が更新されるまで待機する。そして、人事DB30が更新されると、ステップS302に移行し、メール処理部40は、最新の人事DB30を用いた属性別受信DB作成処理を実行する。なお、このステップS302では、
図19の処理のうち、ステップS160とステップS168を除く処理を、最新の人事DB30を用いて行う。
【0091】
このように、
図29の処理を実行することで、人事DB30が更新されたタイミングで、最新の人事DB30に対応するように属性別受信DB(現在)39を更新することができる。
【0092】
なお、上記においては、受信メールを送信者の属性に応じて分類して表示する場合について説明した。しかしながらこれに限られるものではなく、上記と同様にして、送信メールを受信者の属性に応じて分類し、利用者からの求めに応じて属性別表示を行うこととしてもよい。
【0093】
これまでの説明からわかるように、メール処理部40によって、格納部、取得部、分類部、画面生成部としての機能が実現されている。
【0094】
以上、詳細に説明したように、本実施形態によると、送信元の利用者から宛先の利用者へのメールの送信を受け付けた場合に、メールの情報をメールDB32に格納し(S204)、利用者の所属情報(職制コード等)を格納する人事DB30を参照して、メールDB32に格納されたメールが送信されたときの送信元と宛先との関係を取得して発信時職制DB36に記録し(S208)、メールDB32に格納されたメールのメッセージIDを、発信時職制DB36に格納された発信元と宛先との関係に基づいて分類して、属性別受信DB(発信時)38に記録し(S214)、宛先の利用者からの閲覧要求に応じて、メールDB32に格納されているメールの閲覧画面(属性別表示画面(発信時属性表示)(
図20))を属性別受信DB(発信時)38に基づいて生成し、表示処理部50に対し、表示部193への閲覧画面の表示を実行させる(S32)。これにより、本実施形態では、
図20に示すように、送信者の属性ごとに受信件数や未開封件数を表示することができる。また、利用者が属性を選択することで、対応するメールの一覧を表示することができる。したがって、所望のメールを探し出す作業が容易になり、利用者の負担を軽減し作業時間の短縮を図ることができるので、利用者の使い勝手を向上することができる。また、本実施形態では、メールを属性ごとにフォルダ分けせずに、属性別受信DB(発信時)38において属性ごとにメッセージIDを管理(区分け)することから、利用者の求めに応じて、
図20の属性別表示画面と、
図15の受信メール一覧表示画面とを切り替えて表示することができ、この点からも利用者の使い勝手を向上することができる。
【0095】
また、本実施形態では、属性別受信DB(発信時)38にメッセージIDを記録する処理において、メールDB32に格納されたメールのメッセージIDを、送信元と宛先との関係以外の情報(本実施形態では、発信日時(期間))で更に分類している。これにより、利用者は、送信者の属性と発信日時とに基づいて、所望のメールを探し出すことができるので、探し出す作業がより容易となる。なお、上記においては、属性別受信DB(発信時)38にメッセージIDを記録する処理において、送信元と宛先との関係と発信日時(期間)とに基づいて、メッセージIDを分類する場合について説明したが、これに限られるものではない。例えば、発信日時(期間)に代えて、発信曜日や、午前、午後などの1日における時間帯に基づいて、メッセージIDを分類することとしてもよい。また、発信日時(期間)に代えて、発信者の情報、例えば男性、女性、年齢、住所などに基づいて、メッセージIDを分類することとしてもよい。また、発信日時以外の、メールに対して特定の処理を行った日時に基づいて、メッセージIDを分類することとしてもよい。
【0096】
また、本実施形態では、最新の(現在の)人事DB30を参照して、送信元の利用者と宛先の利用者の最新の(現在の)関係を取得し、当該関係に基づいて、メールDB32に格納されているメールのメッセージIDを分類して、属性別受信DB(現在)39に記録し(S162、S170)、利用者からの閲覧要求に応じて、メールDB32に格納されているメールの閲覧画面(属性別表示画面(現在属性表示)(
図26))を属性別受信DB(現在)39に基づいて生成し、表示処理部50に表示させる(S32)。これにより、現在の属性に基づいた属性別表示画面(
図26)を表示することができるので、利用者は、現在の属性に基づいてメールを探し出すことが可能となる。この場合、利用者は、メールを受信した時点における送信者の属性を思い出したり、調べたりする必要がなくなり、作業効率を向上することができる。
【0097】
なお、上記実施形態では、属性別表示画面(
図20、
図26)において、いずれの属性にも含まれないメールが存在する場合がある。このような場合には、それらのメールの件数を属性「その他」として属性別表示画面に表示してもよいし、属性別表示画面では表示しないようにしてもよい。
【0098】
なお、上記実施形態で説明した画面やデータベースは一例である。すなわち、画面の構成やデータベースのデータ構造については、種々変更してもよい。また、フローチャートの処理についても、一部の処理を省略したり、一部の処理の順番を変更してもよい。
【0099】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体(ただし、搬送波は除く)に記録しておくことができる。
【0100】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD(Digital Versatile Disc)、CD−ROM(Compact Disc Read Only Memory)などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【0101】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【0102】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【0103】
なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
(付記1) ユーザ間でメールの送受信が行われた場合に、当該メールの情報をメールの識別情報とともにメール情報格納部に格納し、
ユーザの所属情報を格納する所属情報格納部に基づいて、前記メール情報格納部に格納されたメールが送受信されたときの送信者と受信者との関係を取得し、
前記メール情報格納部に格納されたメールの識別情報を、前記送信者と受信者との関係に基づいて分類して、分類情報格納部に格納し、
ユーザからの閲覧要求に応じ、前記分類情報格納部において分類されているメールの識別情報に基づいて前記メール情報格納部に格納されているメールの閲覧画面を生成し、当該閲覧画面を表示装置に表示させる、処理をコンピュータに実行させることを特徴とするメール処理プログラム。
(付記2) 前記分類情報格納部に格納する処理では、前記メール情報格納部に格納されたメールの識別情報を前記送信者と受信者との関係以外の情報で更に分類して前記分類情報格納部に格納することを特徴とする付記1に記載のメール処理プログラム。
(付記3) 前記送信者と受信者との関係以外の情報は、前記メール情報格納部に格納されたメールに対する特定の処理が行われた日時の情報であることを特徴とする付記2に記載のメール処理プログラム。
(付記4) 所定のタイミングで、最新の所属情報が格納された前記所属情報格納部に基づいて、前記メール情報格納部に格納されているメールの送信者と受信者との関係を取得し、
取得した前記送信者と受信者との関係に基づいて、前記メール情報格納部に格納されているメールの識別情報を分類して、最新分類情報格納部に格納し、
ユーザからの閲覧要求に応じ、前記最新分類情報格納部において分類されているメールの識別情報に基づいて前記メール情報格納部に格納されているメールの閲覧画面を生成し、当該閲覧画面を前記表示部に表示させる処理をコンピュータに実行させることを特徴とする請求項1〜3のいずれか一項に記載のメール処理プログラム。
(付記5) ユーザ間でメールの送受信が行われた場合に、当該メールの情報をメールの識別情報とともに格納するメール情報格納部と、
ユーザの所属情報を格納する所属情報格納部と、
前記所属情報格納部に基づいて、前記メール情報格納部に格納されたメールが送受信されたときの送信者と受信者との関係を取得する取得部と、
前記メール情報格納部に格納されたメールの識別情報を、前記取得部が取得した前記送信者と受信者との関係に基づいて分類する分類部と、
前記分類部による分類結果を記録する分類情報格納部と、
ユーザからの閲覧要求に応じ、前記分類情報格納部において分類されているメールの識別情報に基づいて前記メール情報格納部に格納されているメールの閲覧画面を生成し、当該閲覧画面を表示装置に表示させる画面生成部と、を備えるメール処理装置。
(付記6) 前記分類部は、前記メール情報格納部に格納されたメールの識別情報を前記送信者と受信者との関係以外の情報で更に分類して前記分類情報格納部に格納することを特徴とする付記5に記載のメール処理装置。
(付記7) 前記送信者と受信者との関係以外の情報は、前記メール情報格納部に格納されたメールに対する特定の処理が行われた日時の情報であることを特徴とする付記6に記載のメール処理装置。
(付記8) 所定のタイミングで、最新の所属情報が格納された前記所属情報格納部に基づいて、前記メール情報格納部に格納されているメールの送信者と受信者との関係を取得する最新情報取得部と、
取得した前記送信者と受信者との関係に基づいて、前記メール情報格納部に格納されているメールの識別情報を分類する最新分類部と、
前記最新分類部による分類結果を記録する最新分類情報格納部と、を更に備え、
前記画像生成部は、ユーザからの閲覧要求に応じ、前記最新分類情報格納部において分類されているメールの識別情報に基づいて前記メール情報格納部に格納されているメールの閲覧画面を生成し、当該閲覧画面を前記表示装置に表示させることを特徴とする付記5〜7のいずれかに記載のメール処理装置。
(付記9) ユーザ間でメールの送受信が行われた場合に、当該メールの情報をメールの識別情報とともにメール情報格納部に格納する工程と、
ユーザの所属情報を格納する所属情報格納部に基づいて、前記メール情報格納部に格納されたメールが送受信されたときの送信者と受信者との関係を取得する工程と、
前記メール情報格納部に格納されたメールの識別情報を、前記送信者と受信者との関係に基づいて分類して、前記分類情報格納部に記録する工程と、
ユーザからの閲覧要求に応じ、前記分類情報格納部において分類されているメールの識別情報に基づいて前記メール情報格納部に格納されているメールの閲覧画面を生成し、当該閲覧画面を表示装置に表示させる工程と、をコンピュータが実行することを特徴とするメール処理方法。
(付記10)
前記分類情報格納部に格納する工程では、前記メール情報格納部に格納されたメールの識別情報を前記送信者と受信者との関係以外の情報で更に分類して前記分類情報格納部に格納することを特徴とする付記9に記載のメール処理方法。
(付記11)
前記送信者と受信者との関係以外の情報は、前記メール情報格納部に格納されたメールに対する特定の処理が行われた日時の情報であることを特徴とする付記10に記載のメール処理方法。
(付記12)
所定のタイミングで、最新の所属情報が格納された前記所属情報格納部に基づいて、前記メール情報格納部に格納されているメールの送信者と受信者との関係を取得する工程と、
取得した前記送信者と受信者との関係に基づいて、前記メール情報格納部に格納されているメールの識別情報を分類して、最新分類情報格納部に格納する工程と、
ユーザからの閲覧要求に応じ、前記最新分類情報格納部において分類されているメールの識別情報に基づいて前記メール情報格納部に格納されているメールの閲覧画面を生成し、当該閲覧画面を前記表示装置に表示させる工程と、をコンピュータが実行することを特徴とする付記9〜11のいずれかに記載のメール処理方法。