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

Description

本技術は、メールの返信を促す技術に関する。

通常、メール送信者は、メール受信者の状況（例えば、メールを確認できる状態であるか）を知ることはできない。そのため、すぐに回答が来ると思ってメールを送信した場合に、なかなか回答が来ないため、物事が先に進まないということが起こり得る。そこで、回答を要するメールを送信する場合には、期限までに回答を得られるように、期限に余裕を持たせたり、回答を促すメールを送信したりすることがある。

従来、回答を要するメールを送信した場合に、メールの受信側に対して回答の催促を行う技術が存在する。具体的には、回答を要するメールの送信側において回答の期限を管理しておき、回答の期限が迫ってきた場合に、送信側のユーザに対してその旨を提示したり、メールの受信側に対して回答を要するメールがあることを示すメッセージを通知する。

また、以下のような技術も存在する。具体的には、ユーザがメールに反応する確率を時刻及び場所に対応付けて格納するテーブルを保持しておく。そして、現在の時刻及び場所を検知し、現在の時刻及び場所に対応する確率が閾値以上である場合に、当該ユーザに対して通知すべき情報を通知する。

また、以下のような技術も存在する。具体的には、ユーザ自身の状態を表すコンテキスト情報とユーザ周辺の状態を表すコンテキスト情報とを収集し、ユーザが起こす可能性のある予定行動を推測する。また、推測された予定行動とユーザとの関係度を定量的に表す関係度情報を算出し、この関係度情報をもとに予定行動の中から行動支援対象とすべき予定行動を選択する。さらに、関係度情報の時系列変化を検出し、この時系列変化に基づいて行動支援情報を提供するタイミングを決定する。

しかし、上で述べたような技術によって回答を促すメールを送信した場合、期限までに回答をするメール受信者もいるが、メール受信者によっては、期限を過ぎてもなかなか回答をしないということがあった。

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

従って、本技術の目的は、一側面によれば、回答を要するメールに対する回答を効果的に促すための技術を提供することである。

本実施の形態に係るメール処理方法は、（Ａ）回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さを表す尺度を格納する第１データ格納部から、第１のメールの宛先メールアドレスに対応する尺度を特定する特定ステップと、（Ｂ）特定された尺度に応じて、第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを第１のメールの識別情報に対応付けて第２データ格納部に格納するタイミング決定ステップとを含む。

回答を要するメールに対する回答を効果的に促すことができるようになる。

図１は、第１の実施の形態に係るシステムの構成図である。 図２は、ユーザ端末の機能ブロック図である。 図３は、ルールＤＢに格納されているデータの一例を示す図である。 図４は、第１の実施の形態に係る依頼メール送信処理の処理フローを示す図である。 図５は、第１の実施の形態に係る監視ＤＢに格納されているデータの一例を示す図である。 図６は、第１の実施の形態に係るレスポンスＤＢに格納されているデータの一例を示す図である。 図７は、回答要求処理の処理フローを示す図である。 図８は、回答メール受信処理の処理フローを示す図である。 図９は、尺度補正ルールを考慮しない場合における尺度更新処理の処理フローを示す図である。 図１０は、尺度補正ルールを考慮する場合における尺度更新処理の処理フローを示す図である。 図１１は、第２の実施の形態に係るシステムの構成図である。 図１２は、メールサーバの機能ブロック図である。 図１３は、ＤＢに格納されている役職テーブルの一例を示す図である。 図１４は、ＤＢに格納されているユーザテーブルの一例を示す図である。 図１５は、第２の実施の形態に係る依頼メール送信処理の処理フローを示す図である。 図１６は、第２の実施の形態に係る監視ＤＢに格納されているデータの一例を示す図である。 図１７は、第２の実施の形態に係るレスポンスＤＢに格納されているデータの一例を示す図である。 図１８は、尺度配信処理の処理フローを示す図である。 図１９は、処理データ格納部に格納されているデータの一例を示す図である。 図２０は、コンピュータの機能ブロック図である。

［実施の形態１］
図１に、第１の実施の形態に係るシステムの構成図を示す。第１の実施の形態に係るシステムにおいては、例えばＬＡＮ（Local Area Network）であるネットワーク１１に、ユーザ端末１３と、ユーザ端末１５と、メールサーバ１７とが接続されている。ユーザ端末は２つしか示していないが、数に限定は無い。また、メールサーバは１つしか示していないが、複数のメールサーバにより処理を行う場合もある。なお、第１の実施の形態におけるメールサーバ１７は、一般的なメールサーバと同様の機能を有するものであるので、ここでは詳細な説明は省略する。

図２に、ユーザ端末１３及びユーザ端末１５の機能ブロック図を示す。ユーザ端末１３及びユーザ端末１５は、送受信部３０と、メール格納部３１と、回答要求部４０とを含む。回答要求部４０は、処理部３３及びタイミング決定部３４を含む管理部３２と、監視ＤＢ（データベース）３５と、レスポンスＤＢ３６と、ルールＤＢ３７と、フォーマットデータ格納部３８と、メール生成部３９とを含む。

メール送受信部３０は、メールの送受信を行ったり、送信メール及び受信メールのデータをメール格納部３１に格納する処理を行う。処理部３３は、監視ＤＢ３５及びレスポンスＤＢ３６に格納されているデータを管理する処理等を行う。タイミング決定部３４は、回答を促すメールを送信するタイミングを決定する処理を行い、処理結果を監視ＤＢ３５に格納する処理を行う。メール生成部３９は、管理部３２の指示に応じて、フォーマットデータ格納部３８に格納されているデータを用いて回答を促すメールを生成し、生成したメールを送受信部３０に出力する。

図３に、ルールＤＢ３７に格納されているデータの一例を示す。図３の例では、累計尺度の範囲毎に、回答を促すメールを送信するタイミングを定義するタイミングデータが格納されている。例えば１行目のレコードは、メール送信日から締切日（すなわち回答期限の日）までの１／２が経過した時点で確認メールを送信し、メール送信日から締切日までの３／４が経過した時点で確認メールを送信し、締切日になった時点で催促メールを送信することを表している。本実施の形態では、累計尺度が大きいほど、早い段階でメールを送信し、また頻繁にメールを送信するようになっている。また、本実施の形態では、督促メール、催促メール、確認メールの順に強く回答を促すメールであるとする。

次に、図４乃至図１０を用いて、ユーザ端末１３及びユーザ端末１５の動作について説明する。ここでは、ユーザ端末１３がユーザ端末１５に対して依頼メールを送信する場合を例にして説明する。

まず、図４乃至図６を用いて、依頼メール送信処理について説明する。まず、ユーザ端末１３の送受信部３０は、ユーザからユーザ端末１５宛の依頼メールの送信指示を受け付ける（図４：ステップＳ１）。ステップＳ１においては、例えばメール作成画面とは別に、依頼メールであるか否かの指定及び依頼メールである場合には回答期限の指定を行わせるための画面を表示することにより、依頼メールと通常のメールとを区別する。

そして、送受信部３０は、当該依頼メールをメールサーバ１７に送信し、当該依頼メールのデータをメール格納部３１に格納する（ステップＳ３）。ステップＳ３においては、メールタイトルの先頭に「［依頼］」を付しておき、また回答期限のデータもメールのデータと共に格納しておく。なお、ユーザ自らがメールタイトルに「［依頼］」を付しておき、また回答期限についてもメール本文中に所定の形式で記載しておくことにより、ステップＳ５において処理部３３が検出できるようにしてもよい。

一方、処理部３３は、例えばメールタイトルに「［依頼］」が付されていることを確認することにより、メール格納部３１に依頼メールが新たに格納されたことを検出すると、監視ＤＢ３５にレコードを生成する（ステップＳ５）。

図５に、監視ＤＢ３５に格納されているデータの一例を示す。図５の例では、宛先メールアドレスと、尺度と、依頼メール送信日と、確認メール送信日リストと、催促メール送信日リストと、督促メール送信日リストと、期日と、回答状況と、回答日と、メールＩＤと、送信元メールアドレスと、ＤＢ更新フラグと、メールタイトルとが格納されている。ステップＳ５の処理では、宛先メールアドレスと、依頼メール送信日と、期日と、メールＩＤと、送信元メールアドレスと、メールタイトルとが登録される。これらのデータは、メールのデータから抽出してもよいし、例えば期日についてはユーザから入力を別途受け付けるようにしてもよい。また、ステップＳ５の処理では、回答状況は「ｏｆｆ」に設定され、ＤＢ更新フラグは「未」に設定される。

図４の説明に戻り、処理部３３は、依頼メールの宛先メールアドレスについてのデータがレスポンスＤＢ３６に格納されているか判断する（ステップＳ７）。

図６に、レスポンスＤＢ３６に格納されているデータの一例を示す。図６の例では、送信元メールアドレスと、宛先メールアドレスと、累計尺度と、最新チェック済メールのＩＤと、回答メール総数と、回答期間平均と、最短回答期間と、最長回答期間と、回答遅れ数とが格納されている。ステップＳ７においては、依頼メールの宛先メールアドレスでレスポンスＤＢ３６を検索することにより判断する。レスポンスＤＢ３６にレコードが格納されている宛先メールアドレスは、以前に依頼メールを送信したことがあるメールアドレスである。なお、累計尺度は、依頼メールに対して回答を返信する早さを表す尺度であり、本実施の形態では、累計尺度が小さいほど依頼メールに対して回答を早く返信することを表している。累計尺度の計算方法については、後で説明する。

図４の説明に戻り、レスポンスＤＢ３６に宛先メールアドレスについてのデータが格納されていると判断された場合（ステップＳ５：Ｙｅｓルート）、処理部３３は、レスポンスＤＢ３６から依頼メールの宛先メールアドレスに対応する累計尺度を特定する（ステップＳ９）。

一方、レスポンスＤＢ３６に宛先メールアドレスについてのデータが格納されていないと判断された場合（ステップＳ７：Ｎｏルート）、処理部３３は、図示しないデータベースから累計尺度のデフォルト値を読み出す（ステップＳ１１）。

そして、処理部３３は、ステップＳ９において特定又はステップＳ１１において読み出された累計尺度が属する範囲に対応するタイミングデータをルールＤＢ３７から特定する（ステップＳ１３）。また、処理部３３は、ステップＳ１３において特定されたタイミングデータと、監視ＤＢ３５に格納されている依頼メール送信日及び期日のデータとを用いて送信日リスト（ここでは、確認メール送信日リスト、催促メール送信日リスト及び督促メール送信日リストの少なくともいずれか）を生成し、監視ＤＢ３５に登録する（ステップＳ１５）。そして処理を終了する。例えば、依頼メール送信日から期日までの長さが４日であり、タイミングデータが図３に示すテーブルの１行目のデータである場合には、依頼メール送信日から２日後及び３日後に確認メールを送信し、期日になったら催促メールを送信する。

以上のような処理を実施することにより、依頼メールの宛先ユーザに対して回答を効果的に促すことができるようになる。

次に、図７を用いて、回答要求処理について説明する。まず、ユーザ端末１３の処理部３３は、回答状況が「ｏｆｆ」であるレコードのうち未処理のレコードを監視ＤＢ３５から１つ特定する（図７：ステップＳ２１）。

そして、処理部３３は、現在の日付とステップＳ２１において特定されたレコードに含まれる送信日リスト（ここでは、確認メール送信日リスト、催促メール送信日リスト又は督促メール送信日リスト）に含まれる日付とが一致するか判断する（ステップＳ２３）。すなわち、回答を促すメールを送信するタイミングであるか判断する。回答を促すメールを送信するタイミングではないと判断された場合（ステップＳ２３：Ｎｏルート）、ステップＳ２９の処理に移行する。

一方、回答を促すメールを送信するタイミングであると判断された場合（ステップＳ２３：Ｙｅｓルート）、処理部３３は、メール生成部３９に対して回答を促すメールの生成を指示する。そして、メール生成部３９は、フォーマットデータ格納部３８に格納されているメールフォーマットに、処理部３３から受け取ったデータ（例えば、宛先メールアドレス、依頼メールのタイトル、期日など）を埋め込むことにより、回答を促すメールを生成する（ステップＳ２５）。なお、フォーマットデータ格納部３８には、確認メールのためのメールフォーマット、催促メールのためのメールフォーマット及び督促メールのためのメールフォーマットが格納されている。

また、メール生成部３９は、ステップＳ２５において生成したメールを送受信部３０に出力する。すると、送受信部３０は、メール生成部３９から受け取ったメールをメールサーバに送信する（ステップＳ２７）。一方、処理部３３は、監視ＤＢ３５に、回答状況が「ｏｆｆ」であり且つ未処理のレコードが有るか判断する（ステップＳ２９）。回答状況が「ｏｆｆ」であり且つ未処理のレコードが有ると判断された場合（ステップＳ２９：Ｙｅｓルート）、次のレコードについて処理するため、ステップＳ２１の処理に戻る。一方、回答状況が「ｏｆｆ」であり且つ未処理のレコードが無いと判断された場合（ステップＳ２９：Ｎｏルート）、処理を終了する。

以上のような処理を実施することにより、依頼メール送信処理において設定した送信日リストに従って回答を促すメールを送信し、宛先メールアドレスのユーザの注意を喚起することができるようになる。

次に、図８を用いて、回答メール受信処理について説明する。まず、ユーザ端末１３におけるメール送受信部３０は、メールサーバ１７からメールを受信し、メール格納部３１に格納する（図８：ステップＳ３１）。

そして、処理部３３は、メール格納部３１に新たに受信メールが格納されたことを検出すると、当該受信メールが依頼メールに対する回答メールであるか判断する（ステップＳ３３）。ステップＳ３３においては、例えば受信メールのヘッダに、監視ＤＢ３５に格納されているメールＩＤのいずれかと一致するメールＩＤが含まれていれば回答メールであると判断する。

そして、回答メールではないと判断された場合（ステップＳ３３：Ｎｏルート）、処理を終了する。一方、回答メールであると判断された場合（ステップＳ３３：Ｙｅｓルート）、処理部３３は、監視ＤＢ３５を更新する（ステップＳ３５）。ステップＳ３５においては、回答メールの監視ＤＢ３５に格納されているレコードのうち、ステップＳ３１において受信した回答メールに含まれるメールＩＤと回答メールの送信元アドレスとを含むレコードについて、回答状況を「ｏｎ」に設定し、また回答日を登録する。そして処理を終了する。

以上のような処理を実施することにより、依頼メールに対する回答が得られているかを管理することができるようになる。

次に、図９及び図１０を用いて、尺度更新処理について説明する。尺度更新処理は、回答メール受信処理に続けて行うようにしてもよいし、例えばユーザ端末１３が起動された場合などに行うようにしてもよい。

はじめに、図９を用いて、尺度補正ルールを考慮しない場合における尺度更新処理について説明する。まず、処理部３３は、監視ＤＢ３５から未処理のレコード（以下、処理対象のレコードと呼ぶ）を１つ特定する（図９：ステップＳ４１）。そして、処理部３３は、処理対象のレコードの回答状況が「ｏｎ」であり且つＤＢ更新フラグが「未」であるか判断する（ステップＳ４３）。処理対象のレコードの回答状況が「ｏｆｆ」又はＤＢ更新フラグが「済」であると判断された場合（ステップＳ４３：Ｎｏルート）、ステップＳ５１の処理に移行する。

一方、処理対象のレコードの回答状況が「ｏｎ」であり且つＤＢ更新フラグが「未」であると判断された場合（ステップＳ４３：Ｙｅｓルート）、処理部３３は、処理対象のレコードについて尺度を算出し、監視ＤＢ３５に登録する（ステップＳ４５）。ステップＳ４５においては、（依頼メール送信日から回答日までの日数）／（依頼メール送信日から期日までの日数）を尺度とする。

また、処理部３３は、処理対象のレコードに含まれる宛先メールアドレスについて累計尺度を再計算し、再計算された累計尺度でレスポンスＤＢ３６を更新する（ステップＳ４７）。ステップＳ４７においては、（（更新前の累計尺度）＊（回答メール総数）＋（ステップＳ４５において算出された尺度））／（（回答メール総数）＋１）を累計尺度とする。すなわち、宛先メールアドレスについて算出した尺度の平均値を累計尺度とする。また、ステップＳ４７においては、累計尺度だけではなく、最新チェック済メールＩＤ、回答メール総数及び回答期間平均も更新する。また、場合によっては、最短回答期間、最長回答期間及び回答遅れ数も更新する。

そして、処理部３３は、監視ＤＢ３５に格納されている処理対象のレコードを更新する（ステップＳ４９）。ステップＳ４９においては、ＤＢ更新フラグを「済」に設定する。また、処理部３３は、監視ＤＢ３５に未処理のレコードが有るか判断する（ステップＳ５１）。未処理のレコードが有ると判断された場合（ステップＳ５１：Ｙｅｓルート）、次のレコードについて処理するため、ステップＳ４１の処理に戻る。一方、未処理のレコードが無いと判断された場合（ステップＳ５１：Ｎｏルート）、処理を終了する。

このような処理を実施することにより、ユーザの回答実績を用いて実情に合った累計尺度を求めることができるようになる。

次に、図１０を用いて、尺度補正ルールを考慮する場合における尺度更新処理について説明する。まず、処理部３３は、監視ＤＢ３５から未処理のレコード（以下、処理対象のレコードと呼ぶ）を１つ特定する（図１０：ステップＳ６１）。そして、処理部３３は、処理対象のレコードの回答状況が「ｏｎ」であり且つＤＢ更新フラグが「未」であるか判断する（ステップＳ６３）。処理対象のレコードの回答状況が「ｏｆｆ」であるか又はＤＢ更新フラグが「済」であると判断された場合（ステップＳ６３：Ｎｏルート）、ステップＳ７５の処理に移行する。

一方、処理対象のレコードの回答状況が「ｏｎ」であり且つＤＢ更新フラグが「未」であると判断された場合（ステップＳ６３：Ｙｅｓルート）、処理部３３は、処理対象のレコードについて尺度を算出し、監視ＤＢ３５に登録する（ステップＳ６５）。ステップＳ６５においては、（依頼メール送信日から回答日までの日数）／（依頼メール送信日から期日までの日数）を尺度とする。

そして、処理部３３は、処理対象のレコードについて尺度補正ルールの適用があるか判断する（ステップＳ６７）。尺度補正ルールの適用がないと判断された場合（ステップＳ６７：Ｎｏルート）、ステップＳ７１の処理に移行する。一方、尺度補正ルールの適用があると判断された場合（ステップＳ６７：Ｙｅｓルート）、処理部３３は、ステップＳ６５において算出された尺度を補正し、監視ＤＢ３５に登録する（ステップＳ６９）。

ここで、ステップＳ６７及びＳ６９において行われる処理について説明する。まず、ステップＳ６７においては、処理対象のレコードのメールＩＤと同じメールＩＤを有するレコード（すなわち、同一の依頼メールに係るレコード）の尺度を監視ＤＢ３５から特定する。そして、特定された尺度が、期日の設定が不適切であると判定するための条件を満たすか判断する。例えば、ほとんどの尺度が極端に小さい値（例えば０．１未満）であるような場合には、期日が遅いために小さい値になっている可能性がある。このような場合には、尺度補正ルールの適用があると判断し、ステップＳ６９において尺度に所定の値（例えば０．３）を加える。また、例えば、ほとんどの尺度が極端に大きい値（例えば１．０以上）であるような場合には、期日が早いために大きい値になっている可能性がある。このような場合にも、尺度補正ルールの適用があると判断し、ステップＳ６９において尺度から所定の値（例えば０．３）を減ずる。なお、ステップＳ６７における尺度補正ルールはこのような例に限られない。

図１０の説明に戻り、処理部３３は、処理対象のレコードに含まれる宛先メールアドレスについて累計尺度を再計算し、再計算された累計尺度でレスポンスＤＢ３６を更新する（ステップＳ７１）。ステップＳ７１においては、（（更新前の累計尺度）＊（回答メール総数）＋（ステップＳ６９において算出された尺度））／（（回答メール総数）＋１）を累計尺度とする。すなわち、宛先メールアドレスについて算出した尺度の平均値を累計尺度とする。また、ステップＳ７１においては、累計尺度だけではなく、最新チェック済メールＩＤ、回答メール総数及び回答期間平均も更新する。また、場合によっては、最短回答期間、最長回答期間及び回答遅れ数も更新する。

そして、処理部３３は、監視ＤＢ３５に格納されている処理対象のレコードを更新する（ステップＳ７３）。ステップＳ７３においては、ＤＢ更新フラグを「済」に設定する。また、処理部３３は、監視ＤＢ３５に未処理のレコードが有るか判断する（ステップＳ７５）。未処理のレコードが有ると判断された場合（ステップＳ７５：Ｙｅｓルート）、次のレコードについて処理するため、ステップＳ６１の処理に戻る。一方、未処理のレコードが無いと判断された場合（ステップＳ７５：Ｎｏルート）、処理を終了する。

このように、実情に合わないと考えられる尺度を補正することにより、適切な累計尺度を求めることができるようになる。

［実施の形態２］
図１１に、第２の実施の形態に係るシステムの構成図を示す。第２の実施の形態に係るシステムにおいては、例えばＬＡＮ（Local Area Network）であるネットワーク２１に、ユーザ端末２３と、ユーザ端末２５と、メールサーバ２７と、データベースサーバ２９とが接続されている。また、データベースサーバ２９にはＤＢ２９１が接続されている。ここでは、ユーザ端末は２つしか示していないが、数に限定は無い。また、メールサーバは１つしか示していないが、複数のメールサーバにより処理を行う場合もある。

図１２に、第２の実施の形態に係るメールサーバ２７の機能ブロック図を示す。メールサーバ２７は、送受信部７１と、更新部７２と、処理データ格納部７３とを含む。送受信部７１は、ユーザ端末２３及びユーザ端末２５から受信した処理要求に含まれるデータを更新部７２に出力したり、処理データ格納部７３に格納されているデータをユーザ端末２３及びユーザ端末２５に送信する処理等を行う。更新部７２は、送受信部７１から受け取ったデータを用いて処理データ格納部７３を更新する処理を行う。

なお、第２の実施の形態に係るユーザ端末２３及びユーザ端末２５の機能ブロック図は図２に示した機能ブロック図と同じであるので、説明を省略する。

図１３に、データベースサーバ２９が管理するＤＢ２９１に格納されている役職テーブルの一例を示す。図１３の例では、役職のレベルの列と、役職の列とが含まれる。

図１４に、データベースサーバ２９が管理するＤＢ２９１に格納されているユーザテーブルの一例を示す。図１４の例では、メールアドレスの列と、氏名の列と、役職の列と、所属の列とが含まれる。

次に、図１５乃至図１７を用いて、ユーザ端末２３及びユーザ端末２５の動作について説明する。ここでは、ユーザ端末２３がユーザ端末２５に対して依頼メールを送信する場合を例にして説明する。但し、回答メール受信処理、回答要求処理及び尺度更新処理については第１の実施の形態の処理と同じであるので、ここでは依頼メール送信処理についてのみ説明する。

まず、ユーザ端末２３の送受信部３０は、ユーザからユーザ端末２５宛の依頼メールの送信指示を受け付ける。そして、送受信部３０は、当該依頼メールをメールサーバ１７に送信し、当該依頼メールのデータをメール格納部３１に格納する（図１５：ステップＳ８１）。

そして、処理部３３は、メール格納部３１に依頼メールが新たに格納されたことを検出すると、監視ＤＢ３５にレコードを生成する（ステップＳ８３）。ステップＳ８３においては、例えばメールタイトルの先頭に「［依頼］」が付されている場合や、メール本文に所定のキーワード（例えば「回答期限」）が含まれる場合に依頼メールであると判断する。

図１６に、監視ＤＢ３５に格納されているデータの一例を示す。図１６の例では、宛先メールアドレスと、役職比較データと、尺度と、依頼メール送信日と、確認メール送信日リストと、催促メール送信日リストと、督促メール送信日リストと、期日と、回答状況と、回答日と、メールＩＤと、送信元メールアドレスと、ＤＢ更新フラグと、メールタイトルとが格納されている。図５に示したデータとの違いは、役職比較データの列が設けられている点である。役職比較データは、宛先メールアドレスのユーザの役職が、ユーザ端末２３のユーザの役職と比較した場合において上位、同列又は下位のいずれに該当するかを表している。

なお、ステップＳ８３の処理では、宛先メールアドレスと、依頼メール送信日と、期日と、メールＩＤと、送信元メールアドレスと、メールタイトルとが登録される。これらのデータは、メールのデータから抽出してもよいし、例えば期日についてはユーザから入力を別途受け付けるようにしてもよい。また、ステップＳ８３の処理では、回答状況は「ｏｆｆ」に設定され、ＤＢ更新フラグは「未」に設定される。

図１５の説明に戻り、処理部３３は、依頼メールの宛先メールアドレスについてのデータがレスポンスＤＢ３６に格納されているか判断する（ステップＳ８５）。

図１７に、レスポンスＤＢ３６に格納されているデータの一例を示す。図１７の例では、宛先メールアドレスと、役職比較データと、累計尺度と、最新チェック済メールのＩＤと、回答メール総数と、回答期間平均と、最短回答期間と、最長回答期間と、回答遅れ数とが格納されている。図６に示したデータとの違いは、役職比較データの列が設けられた点がある。

なお、ステップＳ８５においては、依頼メールの宛先メールアドレスでレスポンスＤＢ３６を検索することにより判断を行う。レスポンスＤＢ３６にレコードが格納されている宛先メールアドレスとは、以前に依頼メールを送信したことがあるメールアドレスである。

図１５の説明に戻り、レスポンスＤＢ３６に宛先メールアドレスについてのデータが格納されていると判断された場合（ステップＳ８５：Ｙｅｓルート）、処理部３３は、レスポンスＤＢ３６から依頼メールの宛先メールアドレスに対応する累計尺度を特定する（ステップＳ８７）。

そして、処理部３３は、ステップＳ８７において特定された累計尺度が属する範囲に対応するタイミングデータをルールＤＢ３７から特定する（ステップＳ８９）。また、処理部３３は、ステップＳ８９において特定されたタイミングデータと、監視ＤＢ３５に格納されている依頼メール送信日及び期日のデータとを用いて送信日リスト（ここでは、確認メール送信日リスト、催促メール送信日リスト及び督促メール送信日リストの少なくともいずれか）を生成し、監視ＤＢ３５に登録する（ステップＳ９１）。さらに、処理部３３は、依頼メールの宛先メールアドレスに対応付けてレスポンスＤＢ３６に格納されている役職比較データを監視ＤＢ３５に登録する（ステップＳ９３）。

一方、レスポンスＤＢ３６に宛先メールアドレスについてのデータが格納されていないと判断された場合（ステップＳ８５：Ｎｏルート）、送受信部３０は、依頼メールの送信元メールアドレス及び宛先メールアドレスを含む取得要求をデータベースサーバ２９に送信する。なお、データベースサーバ２９へのアクセスには例えばＬＤＡＰ（Lightweight Directory Access Protocol）が用いられる。一方、データベースサーバ２９は、ＤＢ２９１に格納されているユーザテーブルから送信元メールアドレス及び宛先メールアドレスに対応する役職データを抽出すると共に、抽出された役職データに対応する役職のレベルのデータをＤＢ２９１に格納されている役職テーブルから抽出し、ユーザ端末２３に送信する。そして、ユーザ端末２３の送受信部３０は、データベースサーバ２９から役職のレベルのデータを受信し、メインメモリ等の記憶装置に格納する（ステップＳ９５）。

そして、処理部３３は、ステップＳ９５において受信した役職のレベルのデータを比較することにより、依頼メールの宛先メールアドレスのユーザの役職が「上位」、「同列」又は「下位」のいずれに該当するかを決定して役職比較データを生成し、依頼メールの宛先メールアドレスに対応付けてレスポンスＤＢ３６及び監視ＤＢ３５に登録する（ステップＳ９７）。ステップＳ９７においては、役職のレベルの値が大きい方が上位の役職であると判断する。

そして、処理部３３は、図示しないデータベースから累計尺度のデフォルト値を読み出す（ステップＳ９９）。ステップＳ９９においては、例えばステップＳ９７において生成した役職比較データに対応する累計尺度を図示しないデータベースから読み出す。

また、処理部３３は、ステップＳ９９において読み出された累計尺度が属する範囲に対応するタイミングデータをルールＤＢ３７から特定する（ステップＳ１０１）。また、処理部３３は、ステップＳ１０１において特定されたタイミングデータと、監視ＤＢ３５に格納されている依頼メール送信日及び期日のデータとを用いて送信日リスト（ここでは、確認メール送信日リスト、催促メール送信日リスト及び督促メール送信日リストの少なくともいずれか）を生成し、監視ＤＢ３５に登録する（ステップＳ１０３）。そして処理を終了する。

以上のような処理を実施することにより、依頼メールの宛先ユーザに対して回答を効果的に促すことができるようになる。また、レスポンスＤＢ３６に役職比較データを登録しておくことにより、後述する尺度配信処理に利用することができる。

次に、図１８及び図１９を用いて、尺度配信処理について説明する。まず、ユーザ端末２３の処理部３３は、レスポンスＤＢ３６に格納されているデータを読み出し、送受信部３０に出力する。そして、送受信部３０は、処理部３３から受け取ったデータを含む処理要求をメールサーバ２７に送信する（図１８：ステップＳ１１１）。

一方、メールサーバ２７の送受信部７１は、ユーザ端末２３から処理要求を受信し、メインメモリ等の記憶装置に格納する（ステップＳ１１３）。そして、更新部７２は、受信した処理要求に含まれるデータを用いて、処理データ格納部７３に格納されている累計尺度を役職比較データの値毎に再計算し、再計算された累計尺度で処理データ格納部７３を更新する（ステップＳ１１５）。ここでは、処理要求に含まれる累計尺度及び回答メール総数と、処理データ格納部７３に含まれる累計尺度及び回答メール総数とを用いて累計尺度の平均値を算出する。また、ステップＳ１１５においては、累計尺度だけではなく、回答メール総数及び回答期間平均も更新する。また、場合によっては、最短回答期間、最長回答期間及び回答遅れ数も更新する。

図１９に、処理データ格納部７３に格納されているデータの一例を示す。図１９の例では、役職比較データと、累計尺度と、回答メール総数と、回答期間平均と、最短回答期間と、最長回答期間と、回答遅れ数とが格納されるようになっている。

図１８の説明に戻り、送受信部７１は、処理データ格納部７３に格納されているデータを含む処理結果をユーザ端末２３に送信する（ステップＳ１１７）。一方、ユーザ端末２３の送受信部７１は、処理結果をメールサーバ２７から受信し、累計尺度を役職比較データに対応付けて図示しないデータベースに格納する（ステップＳ１１９）。ステップＳ１１９において受信した累計尺度は、例えばステップＳ９５において、累計尺度のデフォルト値として用いられる。

以上のような処理を実施することにより、宛先メールアドレスに対応する尺度がレスポンスＤＢ３６に格納されていない（すなわち、回答実績が無い）場合であっても、メールサーバ２７から配信された累計尺度を用いて送信タイミングを適切に決定することができるようになる。

以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上で説明したユーザ端末及びメールサーバの機能ブロック図は必ずしも実際のプログラムモジュール構成に対応するものではない。

また、上で説明した各テーブルの構成は一例であって、必ずしも上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、第２の実施の形態においては、役職比較データの値毎に累計尺度を算出しているが、このような例に限られるわけではない。例えば、メールサーバ２７において、所属グループやメーリングリスト毎に累計尺度を算出し、ユーザ端末に配信するようにしてもよい。

また、尺度配信処理については、上で述べた例のように、ユーザ端末から処理要求を受信した場合に行うようにしてもよいし、その他のタイミングで行うようにしてもよい。例えば、メールサーバ２７がユーザ端末からレスポンスＤＢ３６に格納されているデータを適宜受信して蓄積しておき、所定のタイミング（例えば１ヶ月毎）において累計尺度の再計算を行い、ユーザ端末に配信するようにしてもよい。

また、第２の実施の形態においては、尺度配信処理をメールサーバ２７が行うようにしているが、尺度配信処理のためのサーバを別途設けるようにしてもよい。

また、尺度更新処理については、例えば直近の１ヶ月や１年など所定の期間における回答実績を監視ＤＢ３５から抽出して、累計尺度の算出に用いるようにしてもよい。

なお、上で述べたユーザ端末、メールサーバ及びデータベースサーバ２９は、コンピュータ装置であって、図２０に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

なお、図２及び図１２に示した各処理部は、ＣＰＵ２５０３及びプログラムの組み合わせ、すなわち、ＣＰＵ２５０３がプログラムを実行することにより実現してもよい。より具体的には、ＣＰＵ２５０３は、ＨＤＤ２５０５又はメモリ２５０１に記憶されたプログラムに従った動作を行うことで、上で述べたような処理部として機能してもよい。また、図２及び図１２に示した各データ格納部は、図２０におけるメモリ２５０１やＨＤＤ２５０５等として実現してもよい。

以上述べた本技術の実施の形態をまとめると以下のようになる。

本実施の形態に係るメール処理方法は、（Ａ）回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さを表す尺度を格納する第１データ格納部から、第１のメールの宛先メールアドレスに対応する尺度を特定する特定ステップと、（Ｂ）特定された尺度に応じて、第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを第１のメールの識別情報に対応付けて第２データ格納部に格納するタイミング決定ステップとを含む。

このように、回答に関するユーザの個性を反映した尺度を導入して回答を促すメールの送信タイミングを決定すれば、宛先メールアドレスのユーザに対して回答を効果的に促すことができるようになる。

また、上で述べた本方法が、（Ｃ）所定のタイミングにて、第２データ格納部に格納されているデータを読み出し、第１のメールに対する回答を促すメールの送信タイミングであるか判断するステップと、（Ｄ）第１のメールに対する回答を促すメールの送信タイミングであると判断された場合には、第１のメールに対する回答を促すメールを第１のメールの宛先メールアドレス宛に送信するステップとをさらに含むようにしてもよい。これにより、実際に回答を促すメールを送信し、宛先メールアドレスのユーザの注意を喚起することができる。

また、上で述べた本方法が、（Ｅ）第１のメールに対する回答の期限と第１のメールの送信時とを第１のメールの識別情報に対応付けて第２データ格納部に格納するステップと、（Ｆ）第１のメールの識別情報を含む回答メールを受信した場合、第２データ格納部に格納されているデータを用いて、第１のメールの送信時から第１のメールに対する回答の期限までの長さに対する、第１のメールの送信時から第１のメールに対する回答メールの受信時までの長さの割合を算出するステップと、（Ｇ）算出された割合と特定ステップにおいて特定された尺度とを用いて、第１のメールの宛先アドレスについての尺度を再計算し、再計算された当該尺度で第１データ格納部を更新するステップとをさらに含むようにしてもよい。このように、実際の回答実績を用いることにより、実情に合った尺度を算出することができるようになる。

また、上で述べた本方法が、（Ｈ）第１のメールに対する回答の期限と第１のメールの送信時とを第１のメールの識別情報に対応付けて第２データ格納部に格納するステップと、（Ｉ）第１のメールの識別情報を含む複数の回答メールを受信した場合、当該複数の回答メールの各々について、第２データ格納部に格納されているデータを用いて、第１のメールの送信時から第１のメールに対する回答の期限までの長さに対する、第１のメールの送信時から当該回答メールの受信時までの長さの割合を算出する算出ステップと、（Ｊ）算出ステップにおいて算出された複数の割合が、回答の期限の設定が不適切であることを判定するための条件を満たすか判断するステップと、（Ｋ）条件を満たすと判断された場合には、複数の割合の各々を補正するステップと、（Ｌ）補正後の割合と特定ステップにおいて特定された尺度とを用いて、第１のメールの宛先アドレスの各々について尺度を再計算し、再計算された当該尺度で第１データ格納部を更新するステップとをさらに含むようにしてもよい。例えば、算出された割合が全体的に極端に高いような場合には回答の期限までの時間が短いと考えられ、逆に算出された割合が全体的に極端に低いような場合には回答の期限までの時間が長いと考えられる。このような、回答の期限の設定が不適切である場合に算出された割合を用いて尺度を算出することは好ましくない。そこで、このような場合には割合の補正を行うことにより、実情に合わない尺度が算出されることを抑制することができるようになる。

また、上で述べたタイミング決定ステップが、（ｂ１）回答を要するメールの送信時から回答の期限までの間において回答を促すメールを送信するタイミングを定義するタイミングデータを尺度の範囲毎に格納する第３データ格納部から、特定された尺度が属する範囲に対応するタイミングデータを特定するステップと、（ｂ２）特定されたタイミングデータと第１のメールの送信時と第１のメールの回答の期限とを用いて、第１のメールに対する回答を促すメールの送信タイミングを決定するステップとを含むようにしてもよい。これにより、尺度に応じた適切な送信タイミングを決定することができるようになる。

また、上記第１データ格納部には、メールアドレス毎に当該メールアドレスを利用するユーザの特定の属性についての属性値がさらに格納されるようにしてもよい。そして、上で述べた本方法が、（Ｍ）第１データ格納部に格納されているデータを含む処理要求をサーバに送信するステップと、（Ｎ）サーバから、特定の属性についての属性値毎に算出された尺度を含む処理結果を受信し、記憶装置に格納するステップとをさらに含むようにし、上で述べた特定ステップが、（ａ１）第１データ格納部に第１のメールの宛先メールアドレスに対応する尺度が格納されていない場合、記憶装置から、第１のメールの宛先メールアドレスを利用するユーザの特定の属性についての属性値に対応する尺度を特定するステップを含むようにしてもよい。このようにすれば、宛先メールアドレスに対応する尺度が第１データ格納部に格納されていない（すなわち、回答実績が無い）場合であっても対処することができるようになる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さを表す尺度を格納する第１データ格納部から、前記第１のメールの宛先メールアドレスに対応する尺度を特定する特定ステップと、
特定された前記尺度に応じて、前記第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを前記第１のメールの識別情報に対応付けて第２データ格納部に格納するタイミング決定ステップと、
を含み、コンピュータにより実行されるメール処理方法。

（付記２）
所定のタイミングにて、前記第２データ格納部に格納されているデータを読み出し、前記第１のメールに対する回答を促すメールの送信タイミングであるか判断するステップと、
前記第１のメールに対する回答を促すメールの送信タイミングであると判断された場合には、前記第１のメールに対する回答を促すメールを前記第１のメールの宛先メールアドレス宛に送信するステップと、
をさらに含む付記１記載のメール処理方法。

（付記３）
前記第１のメールに対する回答の期限と前記第１のメールの送信時とを前記第１のメールの識別情報に対応付けて前記第２データ格納部に格納するステップと、
前記第１のメールの識別情報を含む回答メールを受信した場合、前記第２データ格納部に格納されているデータを用いて、前記第１のメールの送信時から前記第１のメールに対する回答の期限までの長さに対する、前記第１のメールの送信時から前記第１のメールに対する回答メールの受信時までの長さの割合を算出するステップと、
算出された前記割合と前記特定ステップにおいて特定された前記尺度とを用いて、前記第１のメールの宛先アドレスについての尺度を再計算し、再計算された当該尺度で前記第１データ格納部を更新するステップと、
をさらに含む付記１又は２記載のメール処理方法。

（付記４）
前記第１のメールに対する回答の期限と前記第１のメールの送信時とを前記第１のメールの識別情報に対応付けて前記第２データ格納部に格納するステップと、
前記第１のメールの識別情報を含む複数の回答メールを受信した場合、当該複数の回答メールの各々について、前記第２データ格納部に格納されているデータを用いて、前記第１のメールの送信時から前記第１のメールに対する回答の期限までの長さに対する、前記第１のメールの送信時から当該回答メールの受信時までの長さの割合を算出する算出ステップと、
前記算出ステップにおいて算出された複数の割合が、回答の期限の設定が不適切であることを判定するための条件を満たすか判断するステップと、
前記条件を満たすと判断された場合には、前記複数の割合の各々を補正するステップと、
補正後の前記割合と前記特定ステップにおいて特定された前記尺度とを用いて、前記第１のメールの宛先アドレスの各々について尺度を再計算し、再計算された当該尺度で前記第１データ格納部を更新するステップと、
をさらに含む付記１又は２記載のメール処理方法。

（付記５）
前記タイミング決定ステップが、
回答を要するメールの送信時から回答の期限までの間において回答を促すメールを送信するタイミングを定義するタイミングデータを尺度の範囲毎に格納する第３データ格納部から、特定された前記尺度が属する範囲に対応するタイミングデータを特定するステップと、
特定された前記タイミングデータと前記第１のメールの送信時と前記第１のメールの回答の期限とを用いて、前記第１のメールに対する回答を促すメールの送信タイミングを決定するステップと、
を含む付記１乃至４いずれか１つ記載のメール処理方法。

（付記６）
前記第１データ格納部には、メールアドレス毎に当該メールアドレスを利用するユーザの特定の属性についての属性値がさらに格納されており、
前記第１データ格納部に格納されているデータを含む処理要求をサーバに送信するステップと、
前記サーバから、前記特定の属性についての属性値毎に算出された尺度を含む処理結果を受信し、記憶装置に格納するステップと、
をさらに含み、
前記特定ステップが、
前記第１データ格納部に前記第１のメールの宛先メールアドレスに対応する尺度が格納されていない場合、前記記憶装置から、前記第１のメールの宛先メールアドレスを利用するユーザの前記特定の属性についての属性値に対応する尺度を特定するステップ
を含む付記１乃至５いずれか１つ記載のメール処理方法。

（付記７）
回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さを表す尺度を格納する第１データ格納部から、前記第１のメールの宛先メールアドレスに対応する尺度を特定するステップと、
特定された前記尺度に応じて、前記第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを前記第１のメールの識別情報に対応付けて第２データ格納部に格納するステップと、
を、コンピュータに実行させるためのメール処理プログラム。

（付記８）
メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さを表す尺度を格納する第１データ格納部と、
回答を要する第１のメールを送信した場合、前記第１データ格納部から、前記第１のメールの宛先メールアドレスに対応する尺度を特定する特定部と、
特定された前記尺度に応じて、前記第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを前記第１のメールの識別情報に対応付けて第２データ格納部に格納するタイミング決定部と、
を有するメール処理装置。

１１，２１ ネットワーク １３，１５，２３，２５ ユーザ端末
１７，２７ メールサーバ ２９ データベースサーバ
２９１ ＤＢ ３０ 送受信部
３１ メール格納部 ３２ 管理部
３３ 処理部 ３４ タイミング決定部
３５ 監視ＤＢ ３６ レスポンスＤＢ
３７ ルールＤＢ ３８ フォーマットデータ格納部
３９ メール生成部 ４０ 回答要求部
７１ 送受信部 ７２ 更新部
７３ 処理データ格納部

Claims (8)

1. 回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さの程度を表す尺度を格納する第１データ格納部から、前記第１のメールの宛先メールアドレスに対応する尺度を特定する特定ステップと、
   特定された前記尺度に応じて、前記第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを前記第１のメールの識別情報に対応付けて第２データ格納部に格納するタイミング決定ステップと、
   を含み、コンピュータにより実行されるメール処理方法。
2. 所定のタイミングにて、前記第２データ格納部に格納されているデータを読み出し、前記第１のメールに対する回答を促すメールの送信タイミングであるか判断するステップと、
   前記第１のメールに対する回答を促すメールの送信タイミングであると判断された場合には、前記第１のメールに対する回答を促すメールを前記第１のメールの宛先メールアドレス宛に送信するステップと、
   をさらに含む請求項１記載のメール処理方法。
3. 前記第１のメールに対する回答の期限と前記第１のメールの送信時とを前記第１のメールの識別情報に対応付けて前記第２データ格納部に格納するステップと、
   前記第１のメールの識別情報を含む回答メールを受信した場合、前記第２データ格納部に格納されているデータを用いて、前記第１のメールの送信時から前記第１のメールに対する回答の期限までの長さに対する、前記第１のメールの送信時から前記第１のメールに対する回答メールの受信時までの長さの割合を算出するステップと、
   算出された前記割合と前記特定ステップにおいて特定された前記尺度とを用いて、前記第１のメールの宛先アドレスについての尺度を再計算し、再計算された当該尺度で前記第１データ格納部を更新するステップと、
   をさらに含む請求項１又は２記載のメール処理方法。
4. 前記第１のメールに対する回答の期限と前記第１のメールの送信時とを前記第１のメールの識別情報に対応付けて前記第２データ格納部に格納するステップと、
   前記第１のメールの識別情報を含む複数の回答メールを受信した場合、当該複数の回答メールの各々について、前記第２データ格納部に格納されているデータを用いて、前記第１のメールの送信時から前記第１のメールに対する回答の期限までの長さに対する、前記第１のメールの送信時から当該回答メールの受信時までの長さの割合を算出する算出ステップと、
   前記算出ステップにおいて算出された複数の割合が、回答の期限の設定が不適切であることを判定するための条件を満たすか判断するステップと、
   前記条件を満たすと判断された場合には、前記複数の割合の各々を補正するステップと、
   補正後の前記割合と前記特定ステップにおいて特定された前記尺度とを用いて、前記第１のメールの宛先アドレスの各々について尺度を再計算し、再計算された当該尺度で前記第１データ格納部を更新するステップと、
   をさらに含む請求項１又は２記載のメール処理方法。
5. 前記タイミング決定ステップが、
   回答を要するメールの送信時から回答の期限までの間において回答を促すメールを送信するタイミングを定義するタイミングデータを尺度の範囲毎に格納する第３データ格納部から、特定された前記尺度が属する範囲に対応するタイミングデータを特定するステップと、
   特定された前記タイミングデータと前記第１のメールの送信時と前記第１のメールの回答の期限とを用いて、前記第１のメールに対する回答を促すメールの送信タイミングを決定するステップと、
   を含む請求項１乃至４いずれか１つ記載のメール処理方法。
6. 前記第１データ格納部には、メールアドレス毎に当該メールアドレスを利用するユーザの特定の属性についての属性値がさらに格納されており、
   前記第１データ格納部に格納されているデータを含む処理要求をサーバに送信するステップと、
   前記サーバから、前記特定の属性についての属性値毎に算出された尺度を含む処理結果を受信し、記憶装置に格納するステップと、
   をさらに含み、
   前記特定ステップが、
   前記第１データ格納部に前記第１のメールの宛先メールアドレスに対応する尺度が格納されていない場合、前記記憶装置から、前記第１のメールの宛先メールアドレスを利用するユーザの前記特定の属性についての属性値に対応する尺度を特定するステップ
   を含む請求項１乃至５いずれか１つ記載のメール処理方法。
7. 回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さの程度を表す尺度を格納する第１データ格納部から、前記第１のメールの宛先メールアドレスに対応する尺度を特定するステップと、
   特定された前記尺度に応じて、前記第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを前記第１のメールの識別情報に対応付けて第２データ格納部に格納するステップと、
   を、コンピュータに実行させるためのメール処理プログラム。
8. 回答を要する第１のメールを送信した場合、メールアドレス毎に当該メールアドレスのユーザが回答を要するメールに対して回答メールを返信する早さの程度を表す尺度を格納する第１データ格納部から、前記第１のメールの宛先メールアドレスに対応する尺度を特定する特定部と、
   特定された前記尺度に応じて、前記第１のメールに対する回答を促すメールの送信タイミングを決定し、当該送信タイミングのデータを前記第１のメールの識別情報に対応付けて第２データ格納部に格納するタイミング決定部と、
   を有するメール処理装置。

Images