(57)【要約】【課題】受信メールに設定された返信要求や期限情報を考慮して、メールの重要度を受信メール一覧画面に表示することを特徴とする電子メールシステムを提供する。【解決手段】メールの重要度判定に使用する情報テーブルを作成し、それを基に重要度を判断する。そして、重要度の高い受信メールから順に受信メール一覧に表示する。【選択図】　図８
2004110444.tif 000002
【特許請求の範囲】
【請求項１】
計算機を用いた電子メールの管理方法であって、
前記計算機は、予め記憶装置に格納された電子メールと対応づけられた送信元からの返信要求の有無の情報と期限の情報と受信者から送信者への返信の有無の情報を読み出し、
前記読み出した情報にもとづいて電子メールの情報を画面へ表示させることを特徴とする電子メールの管理方法。
【請求項２】
前記読み出した情報にもとづいて電子メールの情報を画面へ表示させる際に、送信元からの返信要求が有る電子メールの情報を画面の上位へ表示させることを特徴とする請求項１記載の電子メールの管理方法。
【請求項３】
前記読み出した情報にもとづいて電子メールの情報を画面へ表示させる際に、前記期限情報に含まれる日付の順序に従って画面へ表示させることを特徴とする請求項１記載の電子メールの管理方法。
【請求項４】
前記読み出した情報にもとづいて電子メールの情報を画面へ表示させる際に、受信者から送信者へ返信がされていない電子メールの情報を画面の上位へ表示させることを特徴とする請求項１記載の電子メールの管理方法。
【請求項５】
電子メールシステムであって、
電子メールの送信ログを記憶装置に格納する手段と、
前記送信ログに含まれる返信要求の情報と期限の情報と返信の有無の情報とにもとづいて、電子メールの情報を画面に表示させる順位を決定する手段とを備えることを特徴とする電子メールシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は電子メールシステムに関する。
【０００２】
【従来の技術】
従来の電子メールシステムにおいては、ユーザが受信したメールの重要度の判断支援のためのものがある（たとえば、特許文献１参照。）。特許文献１では、送信者により回答期限が設定されたメールを回答漏れがあってはいけない重要なメールと考え、期限が近付くとユーザに回答期限が近い旨のメッセージ出力を行っている。
【０００３】
【特許文献１】
特開平１１−１０３３１４号公報（第２−３頁、第４図）
【０００４】
【発明が解決しようとする課題】
従来の電子メールシステムでは、送信者により回答期限がヘッダや主題、本文中に設定されているメールに関しては返信する必要がある、重要度の高いメールとして処理されていた。しかし、送信者が回答期限を設定していなくても返信を要求する場合がある。そのような場合、従来の技術では対応できなかった。また、ユーザが返信要求をして送信したメールに対する返信メールに対しての優先度も考慮されていなかった。
【０００５】
さらに、回答期限が近くなったメールに対しては、メッセージを出力する形でその旨をユーザに知らせていたが、その場合、同時に何通もメッセージが出力された場合、その対応に時間をとられてしまい却ってメールの処理効率が下がってしまうという問題があった。
【０００６】
本発明の目的は、送信者により返信要求が設定されたメールのやりとりに対して、ユーザのメールの処理効率を下げないでその重要度を知らせることである。
【０００７】
【課題を解決するための手段】
本発明の電子メールシステムであって、電子メールの送信ログを記憶装置に格納する手段と、前記送信ログに含まれる返信要求の情報と期限の情報と返信の有無の情報とにもとづいて、電子メールの情報を画面に表示させる順位を決定する手段とを備えることを特徴とする。
【０００８】
また、上記課題を解決するために、本発明は次の特徴を持つ。１．メールに送信者によって返信要求属性が設定されていた場合、そのメールのメールヘッダや主題・本文に期限情報が設定されているか、ユーザが既に返信しているか、ユーザがメールを読んだかに基づいて優先度を決定するための手段を持つこと。２．受信メールに対し、ユーザが返信要求属性を設定したメールへの返信メールかどうかに基づいて優先度を決定するための手段を持つこと。３．１および２の条件に、メールの開封属性（既読・未読）の条件を追加考慮して、優先度の高いものから順に受信メール一覧の画面に表示する手段を持つこと。
【０００９】
【発明の実施の形態】
以下、図面を参照しながら本発明の１実施形態を説明する。
図１は、本発明が適用される電子メールシステムの構成図である。電子メールシステムは、メールクライアント１１０とメールサーバ１２０から構成される。本実施形態では、送信されてきたメールはメールサーバ１２０からメールクライアント１１０に一度ダウンロードされてから表示されるものとする。
【００１０】
メールクライアント１１０は、メール受信者が使用する装置の集まりであり、メールサーバ１２０へのログイン処理部１１１、メールサーバ１２０にメールを転送するメール送信部１１２、メールサーバ１２０からメールをダウンロードするメール受信部１１３、送信メールのメールヘッダを解析したり、メールサーバ１２０からダウンロードされたメールのメールヘッダを解析して受信用テーブルを作成したりするメール解析部１１４、それらの情報を表示するメール表示部１１５、および受信用テーブルを記憶する記憶装置１１６から構成される。
【００１１】
メールサーバ１２０は、メールの送受信などを司る装置の集まりであり、メールクライアント１１０を使用しているユーザの認証部１２１、ユーザ宛に送信されてきたメールを保管してユーザの要求に従って受信メールのメールヘッダを解析しメールクライアント１１０にそれらの情報を配信する受信メール管理部１２２、ユーザが送信したメールの返信要求属性を解析して情報を送信用テーブルに保管してから送信処理を実行する送信メール管理部１２３、および送信用テーブルを記憶する記憶装置１２４から構成される。
【００１２】
なお、メールクライアント１１０およびメールサーバ１２０には、通常のメールシステムが持つほかの機能部も存在するが、本発明と直接関連しないため、図示を省略する。
【００１３】
図２はメールの作成からメールを送信するまでの処理フロー示している。
なお、メールクライアント１１０のメールサーバ１２０へのログイン処理は一般的な処理と変わりがないので、ログイン処理が終了しているものとして説明する。
【００１４】
ユーザはまず送信メールエディタなどを用いて、送信するメールを作成する（ステップ２１１）。ここで、ユーザが送信先の相手にメールの返信を望む場合、返信要求属性を設定することができる。メール作成中に返信要求のボタンを押すなどして返信要求属性を付けると、作成したメールには返信要求を示すメールヘッダ「ＲｅｐＤｍｄ：１」が設定される。この属性が付いているメールを受信すると、メール表示画面には「返信要求あり」の情報が表示される。次に、メール解析部１１４は、送信メールのメールヘッダＲｅｆｅｒｅｎｃｅの値を参照して、それが記憶装置１１６の受信用テーブルのＭｅｓｓａｇｅ−ＩＤに同じ値があるかどうか検索する（ステップ２１２）。
【００１５】
ここでメールヘッダＲｅｆｅｒｅｎｃｅとは、ある受信メールに対しての返信メールである場合に付加されるメールヘッダで、従来から使用されているものである。ここには、返信対象のメールに設定されているメールヘッダＭｅｓｓａｇｅ−ＩＤの値が設定される。Ｍｅｓｓａｇｅ−ＩＤはメールの識別子として使用される従来からあるメールヘッダである。つまり、ステップ２１２の検索がヒットした場合、ユーザの送信メールは受信メールに対する返信メールであることを意味する。受信用テーブルについては後述する（図６）。
【００１６】
検索がヒットした場合、メール解析部１１４は、ヒットした受信メールに返信要求フラグが１であるか調べる（ステップ２１３）。１の場合、受信用テーブルの処理済フラグに１を設定する（ステップ２１４）。これにより返信要求のあった受信メールに返信をしたことが、受信用テーブルに記録される。ステップ２１２の検索がヒットしなかった場合、ステップ２１３で返信要求フラグが１でなかった場合、またはステップ２１４の処理のあと、メール送信部１１２により、メールサーバ１２０の受信メール管理部１２２に送信メールを転送する（ステップ２１５）。
受信メール管理部１２２は、送信メールを受け取るとステップ２２１で送信メールに返信要求（メールヘッダＲｅｐＤｍｄ：１）または期限情報が設定されているかを調べる。
【００１７】
期限情報は、特開平１１−１０３３１４などで回答期限と称している公知の技術である。返信要求または期限情報があった場合、記憶装置１２４の送信用テーブルに、送信メールのメールヘッダＭｅｓｓａｇｅ−ＩＤおよびＳｕｂｊｅｃｔの値を設定する（ステップ２２２）。これは受信メールが来たときに、ユーザが返信要求を設定したメールに対する返信メールかを調べるのに使用する。送信用テーブルについては後述する（図３）ステップ２２１で返信要求または期限情報が設定されていなかった場合、またはステップ２２２のあと、メールサーバ１２０は通常のメール送信処理を行い（ステップ２２３）フローは終了する。
【００１８】
図３を参照して送信用テーブル３００について説明する。送信用テーブルは、ユーザが返信要求または期限情報を設定したメールを送信したときに、そのデータを記憶しておくもので、記憶装置１２４に作成される。送信用テーブル３００では、送信メールのメールヘッダＭｅｓｓａｇｅ−ＩＤとＳｕｂｊｅｃｔの値がテーブルＭｅｓｓａｇｅ−ＩＤ３１１とＳｕｂｊｅｃｔ３１２に格納される。
【００１９】
図４はメールクライアント１１０のログインから受信メール一覧を表示するまでの処理フローを示している。
メールクライアント１１０の処理を開始すると、まずログイン処理部がステップ４１１でメールクライアント１１０からメールサーバ１２０にログインするために、ユーザからユーザＩＤやパスワードなどのログイン情報の入力を受け付け、メールサーバ１２０のユーザ認証部に送付する。次に、メールサーバ１２０のユーザ認証部が入力されたログイン情報からユーザ認証を行う（ステップ４２１）。正しく認証できた場合、ユーザ認証部はメールクライアント１１０にユーザ情報を送付する。メールクライアント１１０のログイン処理部はメールサーバ１２０からユーザ情報（メールアドレス）を受信する（ステップ４１２）。
【００２０】
本実施例では、ユーザ情報がメールサーバ１２０で管理され、メールクライアント１１０はその情報を持っていないものとしているが、メールクライアント１１０にあらかじめユーザ情報が登録されている場合や、受信メールの処理をメールサーバ１２０で行う場合などは、ステップ４１２は必要ない。
【００２１】
なお、フローには図示していないが、ステップ４２１でユーザ認証が正しくできなかった場合、メールクライアント１１０にその旨報告され、メールクライアント１１０はその旨をユーザに表示し、ログイン情報の再入力を待つ。
【００２２】
次に、メールクライアント１１０のメール受信部はメールサーバ１２０のメール管理部に対して、メール受信要求（ステップ４１３）を行う。
そして、メールサーバ１２０のメール管理部はログインしたユーザ宛に届いている受信メールに返事フラグ付加処理を行う（ステップ４２２）。返事フラグ付加処理とは、受信メールがユーザが返信要求を設定した送信メールに対する返信メールの場合、受信メールのメールヘッダにＲｅｐＭａｉｌ：１を付加する処理である。ステップ４２２のフローについては、図５で説明する。
【００２３】
ステップ４２２のあと、メールサーバ１２０はメールクライアント１１０に受信メールを配信する（ステップ４２３）。メールクライアント１１０は、配信されたメールを受信すると（ステップ４１４）、受信用テーブル６００を記憶装置１１６に生成する（ステップ４１５）。受信用テーブル６００はメールの重要度を決定するために使用する。受信用テーブルの詳細については、図６で説明する。
【００２４】
ステップ４１５で受信用テーブルの生成が終了すると、ステップ４１６で受信用テーブルの情報に基づいて受信メールに優先順位を付けて一覧表示して処理を終了する。ステップ４１６のフローについては、図７で説明する。
なお、メールの開封やメールの返信など、受信用テーブルの内容に変更を伴う操作があった場合は、ステップ４１５、ステップ４１６の処理を実行する。
【００２５】
図５を参照して、ステップ４２２の返事フラグ付加処理のフローを説明する。
返事フラグ付加処理とは、ユーザが返信要求を設定して送信したメールに対しての返信メールのメールヘッダに、返事フラグ（ＲｅｐＭａｉｌ：１）を付加するものである。返事フラグ付加処理は、受信メール管理部１２２で行われる。処理を開始すると、ステップ５０１で受信メールのメールヘッダＲｅｆｅｒｅｎｃｅの値を参照する。そして、その値が送信用テーブル３００のＭｅｓｓａｇｅ−ＩＤ３１０に同じ値が存在するか検索する（ステップ５０２）。存在しない場合、処理を終了する。存在した場合、次に受信メールのメールヘッダＳｕｂｊｅｃｔの値を参照する（ステップ５０３）。
【００２６】
そして、送信用テーブル３００のＳｕｂｊｅｃｔ３１２の値をその中に含むか調査する（ステップ５０４）。含まない場合（＝メールタイトルが異なる）、ユーザの返信要求に対する返信メールではないと考えられるので処理を終了する。含む場合、ユーザの返信要求に対する返信メールと考え、受信メールのメールヘッダに返事フラグ（ＲｅｐＭａｉｌ：１）を付加する。こうすることで、ユーザが返信要求を設定したメールに対する返信メールを知ることができる。
【００２７】
図６を参照して受信用テーブル６００について説明する。受信用テーブルは、受信メールの重要度を決定する情報をを記憶しておくもので、記憶装置１１６に作成される。受信用テーブル６００には、次の要素が格納される。
【００２８】
メールＩＮＤＥＸ６１１：受信メールを管理するためのＩＤである。メールを受信したときに一意に設定される。
処理済フラグ６１２：返信要求のある受信メールに対して、ユーザが返信したかを示すフラグである。メール受信時のデフォルト値は０で、送信処理のステップ２１４で１に設定される。また、ユーザが返信しなくても、メール表示画面からボタンなどで「処理済」設定をすることで、１を設定することができる。これにより、返信要求が設定されているがユーザが返信の必要はないと判断したメールを「処理済」にして重要度を下げるようにできる。
【００２９】
返信要求フラグ６１３：受信メールに返信要求が設定されているかを示すフラグである。メール受信時にメールヘッダを参照して、ＲｅｐＤｍｄ：１があるときは１が、ないときは０が設定される。
期限情報６１４：受信メールに設定されている回答期限などの期限情報が設定される。
【００３０】
返事フラグ６１５：受信メールが、ユーザが返信要求を設定して送信したメールに対する返信メールかを示すフラグである。メール受信時にメールヘッダを参照して、ＲｅｐＭａｉｌ：１があるときは１が、ないときは０が設定される。
開封情報６１６：受信メールがユーザによって開封されたかそうかを示す情報である。メール受信時にデフォルト値「未読」が設定され、メールが開封されると「既読」が設定される。
【００３１】
Ｍｅｓｓａｇｅ−ＩＤ６１７：メール送信処理のステップ２２１で回答済フラグの設定のために参照される情報である。メール受信時にメールヘッダＭｅｓｓａｇｅ−ＩＤの値が設定される。
Ｓｕｂｊｅｃｔ６１８：メール受信処理のステップ４２２で返事フラグの設定のために参照される情報である。メール受信時にメールヘッダＳｕｂｊｅｃｔの値が設定される。
ステップ４１６の受信メール一覧表示のときには、これらの情報を参照して、受信メールの重要度を決定する。
【００３２】
図７を参照して、ステップ４１６の受信メール一覧表示のフローを説明する。
受信メール一覧表示では、受信用テーブルの情報に基づいてソートして重要度の高いメールから順に表示する。処理を開始すると、受信用テーブル６００の処理済フラグ６１２によるソートを行う（ステップ７０１）。ここでは、０（未処理）が設定されているメールの方が、１（処理済）が設定されているメールより重要度が高くなる。
【００３３】
次にステップ７０２で、ステップ７０１の結果グループ化された集団それぞれに対して、返信要求フラグによるソートを行う。ここでは、１（要求あり）の方が０（要求なし）よりも重要度が高くなる。
【００３４】
次にステップ７０３で、ステップ７０２の結果グループ化された集団それぞれに対して、期限情報によるソートを行う。ここでは、まず期限情報が設定されているメールとされていないメールに分けられる。期限情報が設定されているメールの方が、されていないメールより重要度が高くなる。次に期限情報が設定されているメールを期限情報の日付の若い順にソートする。期限の日付がすでに過ぎてしまっている場合でも、日付の若い順にソートする。こうすることで、期限情報が設定されている（返信要求がある）のにユーザが返信していない情報は、重要度が高くなる。
【００３５】
次にステップ７０４で、ステップ７０３の結果グループ化された集団それぞれに対して、返事フラグによるソートを行う。ここでは、１（返事）の方が０（通常メール）よりも重要度が高くなる。
最後にステップ７０５で、ステップ７０４の結果グループ化された集団それぞれに対して、開封情報によるソートを行う。ここでは、未読の方が既読よりも重要度が高くなる。
【００３６】
図８は、ステップ４１６によるソート結果で決定する、メールの重要度（＝表示順序）を表にしたものである。
この表では、受信用テーブル内の情報の組み合わせと重要度の関係を示している。なお、上位にあるものほど重要度が高い。
【００３７】
たとえば、一番重要度が高く受信メール一覧の上位に表示されるメールは、メール８０１である。これは、処理済フラグが０、返信要求フラグが１、設定されている期限情報が最も若い日付で、ユーザが返信要求を設定したメールに対する返事で、未読のメールである。つまり、ユーザが返信要求したメールの返事で、さらに送信者から回答期限を要求されたメールを、まだ開封してない場合、重要度が最も高くなる。
【００３８】
このようにしてメールの重要度を決定し表示することで、送信者により返信要求が設定されたメールのやりとりに対して、ユーザのメールの処理効率を下げないでその重要度を知らせる電子メールシステムが実現する。
【００３９】
【発明の効果】
受信メールに返信要求や、回答期限などの期限情報に基づいて優先順位を付け、それらを優先順位に従って一覧表示することで、メールの重要度を判断しやすくし、メール処理作業の効率を向上させることができる。
【図面の簡単な説明】
【図１】本発明が適用される電子メールシステムの構成を示す図である。
【図２】本発明によるメール送信処理を実施する際のフローチャートを示す図である。
【図３】メールの送信時に作成される送信用テーブルのデータ構造を示す図である。
【図４】本発明によるメール受信処理を実施する際のフローチャートを示す図である。
【図５】メール受信時処理：返事フラグ付加処理のフローチャートを示す図である。
【図６】メールの受信時に作成される受信用テーブルのデータ構造を示す図である。
【図７】受信メール一覧を表示する際の重要度決定処理のフローチャートを示す図である。
【図８】重要度決定処理によって付けられる重要度と受信用テーブルの情報の組み合わせとの関連を示す図である。
【符号の説明】
１１０…メールクライアント
１１１…ログイン処理部
１１２…メール送信部
１１３…メール受信部
１１４…メール解析部
１１５…メール表示部
１１６…記憶装置
１２０…メールサーバ
１２１…ユーザ認証部
１２２…受信メール管理部
１２３…送信メール管理部
１２４…記憶装置
【図１】
2004110444.tif 000003
【図２】
2004110444.tif 000004
【図３】
2004110444.tif 000005
【図４】
2004110444.tif 000006
【図５】
2004110444.tif 000007
【図６】
2004110444.tif 000008
【図７】
2004110444.tif 000009
【図８】
2004110444.tif 000010