JP2008165282A - 電子メールの優先順位の付加方法 - Google Patents

Abstract

【課題】電子メールの重要度につき、受信者側でキーワード等により抽出する方法では、動的に変化する新しいトピックや追加の情報に対して、受信者は重要度を的確に判断して対応できない。また、メーリングリスト内のユーザが他の受信者へ重要度を通知する場合、特定ユーザの判断が全ての同報者へ伝わってしまう。
【解決手段】メールの利用者が、同報のメールに対して重要度判断を実施してもらえるよう、メールクライアント制御部５０へ処理を依頼する。依頼を受けたら、判定者指定処理部２０が組織メンバやプロジェクトメンバ等のデータベースを参照して、同報者の中から判定依頼先を決める。その後、判定依頼処理部２１及び制御部５０で、あらかじめ選んだ判定依頼先に、メールの重要度の判断を依頼して判断を入力させる。重要度の判定後、その結果を重要度判断部２２で平均処理し、重要度判定依頼元へ提示する。
【選択図】図１

Description

本発明は、電子メールへ客観的に優先順位を付加する際の優先順位付加方法に関するものである。

多くの電子メールソフトウェアでは、電子メールを送信する際に重要度を指定することができる。重要度を指定しておくことで、受信者はそのメールをすぐに読んだ方がよいのか、または都合の良い時に読めばよいのかの判断ができる。現在はこの重要度を送信者が付加できる仕組みになっている。そのため、受信者側で重要度をさらに判別する方法として、従来は受信者があらかじめ指定したキーワード等による抽出や、特開平11-102331号公報に記載のように、メーリングリスト内のユーザの重要度判断を他の全ての受信者に伝えるなど様々な方法が考えられている。

特開平11-102331号公報

従来の、受信者側でキーワード等を指定したり抽出したりする方法では、しばしば参照されるキーワードについては重要度を判定することができるが、動的に変化する新しいトピックや追加の情報に対しては、重要度を的確に判断して対応することができないという欠点があった。このため、長期間メールを確認できなかった場合等で重要なトピックが動的に変化していた場合、それに対して柔軟に対応が出来なくなる。さらにメーリングリスト内のユーザが他の受信者へ重要度を通知する場合、メーリングリスト内の特定ユーザの判断が全ての同報者へ伝わってしまうため、個人へ的確な重要度判断が反映されない問題があった。

そのため、本発明が解決しようとする目的は、電子メールの重要度について、メールサーバ等が組織メンバやプロジェクトメンバ等を参照して同報者の中からあらかじめ選んだ第３者に当該メールの重要度を判断してもらい、その結果を受信者が得ることで、動的にトピックが変化するメールに対して、より的確な重要度判断を得て、多数のメールの中から重要なメールを効率よく判断して優先的に処理をする際の判断材料を得ることが可能になることを最も主要な特徴とする。

上記目的を達成するために、本発明の電子メールシステムでは、メールの利用者が同報のメールに対して重要度判断を実施してもらえるように処理を依頼する依頼手段と、依頼元の人を重要度判定者DBへ登録する登録手段と、送られてきた電子メールに対してメール識別番号を付与する付与手段と、重要度判定者DBへ登録された人へ同報のメールが送られてきた場合に判定者選択元DBから情報を取り出しメールの重要度を判断してもらう人を指定するための指定手段と、選択された特定の人をメールDBへ判定依頼フラグとして登録する登録手段を備えていることを特徴とする。

さらに、メール利用者がメールを受信した際に、メールDBからメールを取り出して、判定依頼フラグを付与されたメールを受信者へ送付する送付手段と、判定依頼フラグのついているメールに判定依頼および重要度判定画面を表示し、重要度判断結果の入力を促す表示手段と、判定した結果を通知する通知手段と、受け取った重要度を重要度DBへ格納する格納手段を備えていることを特徴とする。

さらに、重要度判定依頼元がメールを受信した際に、重要度判定者DBへ登録されている人を確認し、登録されている人への同報メールに対する重要度判定結果を重要度DBから取得する取得手段と、重要度判定結果が複数ある場合に判定結果の統計処理を行う処理手段と、重要度の判定結果をメールDBへ格納して判定結果を付与したメールを受信者へ送付する送付手段と、判定結果画面を表示する表示手段を備えていることを特徴とする。

本発明によれば、電子メールの重要度について、メールサーバ等が組織メンバやプロジェクトメンバ等を参照して同報者の中からあらかじめ選んだ第３者に当該メールの重要度を判断してもらい、その結果を受信者が得ることによって、主に動的にトピックが変化するメールなどに対して、より的確な重要度判断を得ることができ、多数のメールの中から重要なメールを効率よく判断して優先的に処理をすることが可能になる。

以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。

図１は、本発明における一実施例である電子メール重要度付加システムの構成を示すものである。本実施例では、ネットワーク３で接続されたメールサーバ１とクライアント２で実現されており、サーバ１にはシステムの構成要素を成すCPU１０、キーボード１１、ディスプレイ１２、NIC１３、主記憶装置１４、HDD１５が割り当てられ、主記憶装置１４内に判定者指定処理部２０、判定者依頼処理部２１、重要度判断部２２、メール送受信部２３、メールサーバ制御部２４、OS２５が割り当てられ、HDD１５内に重要度判定者DB３０、判定者選択元DB３１、重要度DB３２、メールDB３３が割り当てられる。クライアント２にはシステムの構成要素を成すCPU４０、キーボード４１、ディスプレイ４２、NIC４３、主記憶装置４４、HDD４５が割り当てられ、主記憶装置４４内にメールクライアント制御部５０、OS５１が割り当てられている。

判定者指定処理部２０は、メールクライアント制御部５０から通知された重要度判定依頼元を、重要度判定者DB３０へ登録する機能を持つ。また、メールサーバ制御部２４からの依頼を受けて判定者選択元DB３１を参照し、重要度判定依頼者の抽出を行ってメールサーバ制御部２４へ通知する機能を持つ。

判定依頼処理部２１は、メールクライアント制御部５０から、重要度判定の結果を受け取り、重要度DB３２へ登録する機能を持つ。

重要度判断部２２は、重要度判定依頼の有無を重要度判定者DB３０で確認し、判定依頼をしている場合に、重要度DB３２から判定結果を取り出す機能を持つ。また、取り出した結果、重要度判定結果が複数ある場合には、値を平均処理する機能を持つ。さらに、取り出した判定結果または平均処理をした結果をメールDB３３の処理結果欄へ格納する機能を持つ。

メール送受信部２３は、ネットワークを利用してメールを送受信する。外部からメールを受信した際には、メールサーバ制御部２４へメールを渡す機能を持つ。また、クライアントや外部へメールを送受信する機能も持つ。

メールサーバ制御部２４は、受信したメールをメール送受信部２３から受け取り、メール識別番号を付けてメールDB３３へ登録する機能を持つ。また、メールの同報者有無の確認をし、同報者がある場合に重要度判定者DB３０を確認して重要度判定依頼有無の確認をし、判定依頼がある場合に、判定者指定処理部２０へ重要度判定者の選択を要求し、その結果の判定依頼先リストを判定者指定処理部２０から受け取り、メールDB３３内の依頼先のメールへ依頼元IDを登録する機能を持つ。また、メールクライアント制御部５０からメール受信依頼を受けて、メールDB３３からメールを取得しメール送受信部２３へ送信依頼をすることや、重要度判断部２２へ重要度確認依頼を行う機能を持つ。この他、メールサーバ内でのメール処理全般を管理する機能を持つ。

メールクライアント制御部５０は、メール利用者からの重要度判定処理の要求を受けて、判定者指定処理部２０へ判定依頼元を通知する機能を持つ。また、登録が完了したら、完了したことを表示する機能を持つ。また、メール利用者からメール受信要求を受けて、メールサーバ制御部２４へ要求する機能を持つ。また、メール送受信部から受信したメールに判定依頼フラグがある場合に、受信メールリストの判定依頼欄へ表示をし、さらに受信メール画面に重要度判定画面を付加して表示をして判定を促し、判定された結果を受けて判定依頼処理部２１へ判定結果を通知する機能を持つ。また、メール送受信部２３から受信したメールの処理結果欄を参照して、重要度判定結果を受信者の受信メールリストへ表示する機能を持つ。この他、メールクライアント内でのメール処理全般を管理する機能を持つ。

重要度判定者DB３０は、メール利用者がメール判定を依頼する依頼元の氏名やID番号が格納される。詳細は図１２で説明する。

判定者選択元DB３１は、重要度判定依頼先となる人を選んで抽出を行う際の候補者リストを保持している。詳細は図１３で説明する。

重要度DB３２は、重要度判定依頼先からの重要度判定結果が格納される。詳細は図１４で説明する。

メールDB３３は、送受信されるメールが格納される。本発明では、このメールDB３３へメール識別番号及び重要度判定の処理結果も格納する。詳細は図１５で説明する。

本実施例では、ネットワーク３で接続されたシステムの、各々の計算機に処理機能等の要素を割り当てることにより、実現した例を示したが、複数要素を組み合わせて1台の計算機に割り付けてもよく、上記のように要素を複数台に分散させて割り当ててもよい。

図２は、メールの利用者が電子メールの重要度を同報者に判断してもらえるように、サーバに処理を依頼する時の手順例を、図１の各要素を利用して現したシーケンス図である。はじめに、メールクライアント制御部５０で、クライアント側で利用しているメールシステムの画面に、重要度判定依頼ボタンを表示し、メール利用者が同報者に重要度判定を依頼する場合に、ここで指示をさせる(ステップS１００)。詳細は図９で説明する。指示を受けた場合は、メールクライアント制御部５０が、メールサーバ１の判定者指定処理部２０へ、重要度判定依頼元の通知をする(ステップS１０１)。要求を受けた判定者指定処理部２０は通知された重要度判定依頼元を、重要度判定者DB３０へ登録する(ステップS１０２)。詳細は図１２で説明する。登録が完了(ステップS１０３)したら、判定者指定処理部２０からメールクライアント制御部５０へ登録完了を通知(ステップS１０４)し、メールクライアント制御部５０で、重要度の依頼元へ登録完了の表示をする(ステップS１０５)。

図３は、メールシステムが重要度を判断してもらう人の選択および登録をする手順例を、図１の各要素を利用して現したシーケンス図である。はじめに、メール送受信部２３でメールを受信する(ステップS２００)とメールサーバ制御部２４へ受信を通知(ステップS２０１)し、メールサーバ制御部２４で当該メールにメール識別番号を付与して、メールDB３３へ格納し(ステップS２０２)、格納の完了を受け取る(ステップS２０３)。識別番号の詳細は図１５で説明する。次に、メールサーバ制御部２４で当該メールの同報者有無の確認をし、同報者がある場合に重要度判定者DB３０を確認して重要度判定依頼有無の確認を行う(ステップS２０４)。判定依頼がある場合(ステップS２０５)、判定者指定処理部２０へ重要度判定者の選択を要求(ステップS２０６)する。要求を受けた判定者指定処理部２０は、判定者選択元DB３１を参照し、依頼元と同じ組織や部署などに所属するメンバで、かつメールの同報者として含まれている人を重要度判定依頼先として抽出を行い(ステップS２０７)、依頼先リストとして返す(ステップS２０８)。ここでは判定依頼先は複数人になる場合がある。詳細は図１３で説明する。抽出されたデータは、判定者指定処理部２０からメールサーバ制御部２４へ重要度判定者リストとして返される(ステップS２０９)。次に、メールサーバ制御部２４で、受け取った重要度判定依頼先の各メンバのメールに対し、判定依頼フラグとして依頼元IDをメールDB３３内の依頼先メールへ登録する(ステップS２１０)。登録が完了したら、登録完了を通知(ステップS２１１)する。詳細は図６で説明する。

図４は、同報のメールに対して指定した受信者に重要度判断を実施させ、その重要度情報を入手する手順例を、図１の各要素を利用して現したシーケンス図である。はじめに、メールクライアント制御部５０から、メールサーバ制御部２４へメール受信依頼があった場合(ステップS３００)、メールサーバ制御部２４はメールDB３３からメールの取得(ステップS３０１)をする。メールを取得した(ステップS３０２)後、メール送受信部２３へメールを渡して、送信依頼(ステップS３０３)をする。次に、メール送受信部２３はメールクライアント制御部５０へ依頼者のメール一覧を送る(ステップS３０４)。

メールクライアント制御部５０は、メールサーバ１のメール送受信部２３からメールを受け取り、判定依頼フラグの付与されているメールについては、受信者への受信メールリスト表示の際に、判定依頼欄へ判定依頼有無の表示を行う。詳細は図１１で説明する。これにより、メール受信者は受信メールリストを見ただけで、どのメールで判定依頼を受けているのかを知ることができる。さらに、判定依頼を受けているメールの内容表示の際には、メール受信者の判断指定画面を表示して判定結果を待つ(ステップS３０５)。詳細は図１０で説明する。その後、メールの利用者が送信を実施(ステップS３０６)した際には、メールクライアント制御部５０から判定依頼処理部２１へ、判定結果と共にメールの識別番号と依頼元ID番号と判定依頼先ID番号を返す(ステップS３０７)。詳細は図７で説明する。

判定依頼処理部２１は、メールクライアント制御部５０からの判定結果通知を受けて、重要度DB３２へ登録する(ステップS３０８)。詳細は図１４で説明する。登録が完了したら、判定依頼処理部２１が登録完了を受け取り(ステップS３０９)、処理を完了する。

図５は、重要度判定依頼元がメールを受信した際に、入手した重要度情報の統計処理を実施し、メールと共に判定結果を通知する手順例を、図１の各要素を利用して現したシーケンス図である。はじめに、メールクライアント制御部５０から、メールサーバ制御部２４へメール受信依頼があった場合(ステップS４００)、メールサーバ制御部２４は重要度判断部２２へ重要度判定結果の処理を依頼する(ステップS４０１)。重要度判断部２２は、重要度判定結果の処理を実施する。詳細は図８で説明する。具体的には、重要度判定者DB３０の判定依頼元ID番号を確認し重要度判定依頼をしているのかの有無を確認する(ステップS４０２)。判定依頼をしている場合は、判定依頼元のID番号を取得する(ステップS４０３)。次に、重要度判断部２２は重要度DB３２を確認し、判定結果の有無を確認する(ステップS４０４)。依頼元のID番号が存在する場合は判定結果を受け取っているので、判定結果を取得する(ステップS４０５)。受け取った判定結果が１つの場合、重要度判断部２２は結果の数値をメールDB３３の処理結果へ登録する(ステップS４０７。受け取った判定結果が複数の場合、重要度判断部２２は判定結果の平均処理を実施し(ステップS４０６)、その結果をメールDB３３の処理結果へ登録する(ステップS４０７)。その後、重要度判断部２２は登録完了を受け取る(ステップS４０８)。次に、重要度判断部２２はメールサーバ制御部２４へ処理完了通知をする(ステップS４０９)。メールサーバ制御部２４は処理完了通知を受け取った後、メールDB３３からメールの取得(ステップS４１０)をする。メールを取得した(ステップS４１１)後、メール送受信部２３へメールを渡して、送信依頼(ステップS４１２)をする。次に、メール送受信部２３はメールクライアント制御部５０へ依頼者のメール一覧を送る(ステップS４１３)。

メールクライアント制御部５０は、メールを受け取った後、メールデータの判定結果をもとに判定重要度を受信メールリストへ表示する(ステップS４１４)。詳細は図１１で説明する。

図６は、図３のメールサーバ制御部２４での重要度判定依頼処理の手順例を具体的に現したフローチャートである。はじめに、受信メールに一意のメール識別番号を付けてメールDB３３へ登録する(ステップS２０２)。次に当該メールに対して同報者有無の確認(ステップS５００)をし、同報者がない場合には以降の処理をせずに終了する。同報者がある場合には、重要度判定者DB３０を確認して重要度判定依頼有無の確認を行う(ステップS２０４)。判定依頼がない場合には以降の処理をせずに終了する。判定依頼がある場合には、判定者指定処理部２０へ重要度判定者の選択を要求する(ステップS２０６)。その後、抽出されたデータが、判定者指定処理部２０からメールサーバ制御部２４へ重要度判定者リストとして返される。次に、メールサーバ制御部２４で、受け取った重要度判定依頼先の各メンバのメールに対し、判定依頼フラグとして依頼元IDをメールDB３３内の依頼先メールへ登録する(ステップS２１０)。

図７は、図４のメールクライアント制御部５０で重要度判定結果入力時の手順例を具体的に現したフローチャートである。はじめにメールクライアント制御部５０がメールを受け取った後、判定依頼フラグの付与されているメールについては、受信者への受信メールリスト表示の際に、判定依頼欄へ判定依頼有無の表示を行う。詳細は図１１で説明する。さらに、受信者へのメール内容表示の際に、メール受信者の判断指定画面を表示して判定結果を待つ(ステップS３０５)。詳細は図１０で説明する。その後、メールの利用者が送信を実施した際(ステップS３０６)には、重要度判定が入力されていることを確認(ステップS５１０)し、入力されていない場合には入力するように促す。判定結果が入力されている場合には、メールクライアント制御部５０から判定依頼処理部２１へ、判定結果と共にメールの識別番号と依頼元ID番号と判定依頼先ID番号を返す(ステップS３０７)。

図８は、図５の重要度判定結果処理の手順例を具体的に現したフローチャートである。はじめに、重要度判定者DB３０の判定依頼元ID番号を確認し、受信依頼をしているクライアントと同じIDかどうかで重要度判定依頼をしているのかを確認する(ステップS４０２)。判定依頼をしていない場合は、以降の重要度判定結果処理を実施せず、メール送受信部２３からメールクライアント制御部５０へ依頼者のメール一覧を送る。判定依頼をしている場合は、判定依頼元のID番号を取得する。

次に、重要度判断部２２は重要度DB３２を確認し、依頼元のID番号があるかどうかで判定結果の有無を確認する(ステップS４０４)。依頼元のID番号が存在しない場合は、判定結果を受け取っていないので、以降の重要度判定結果処理を実施せず、メール送受信部２３からメールクライアント制御部５０へ依頼者のメール一覧を送る指示をする(ステップS５２０)。依頼元のID番号が存在する場合は判定結果を受け取っているので、判定結果を取得する。受け取った判定結果が１つの場合、重要度判断部２２は結果の数値をそのまま図１５に示すようなメールDB３３の処理結果へ登録する(ステップS４０７)。受け取った判定結果が複数の場合、重要度判断部２２は判定結果の平均処理を実施し(ステップS４０６)、その結果を図１５に示すようなメールDB３３の処理結果へ登録する(ステップS４０７)。

図９は、図２で説明している受信メールリスト画面の重要度判定依頼ボタン(Z６００)の例を具体的に現した図である。通常の「受信」や「送信」、「返信」といった操作を行う入力機能と同様に表示する。メール利用者がメールの重要度判定依頼処理をメールシステムに対して依頼する場合に、最初にこのボタンにより指示する。重要度判定依頼ボタン(Z６００)を選択すると、重要度判定者DB３０へ判定依頼元として登録され、判定依頼を実施していることを示す。

図１０は、重要度判定依頼先のメール受信者が判断指定を行う画面の例を具体的に現した図である。通常のメールでは、送信者や宛先、件名などの基本的な項目を表示し、判定依頼フラグの付与されているメールを受けた場合には、メールの開封時に判断指定画面(Z６１０)を通常の項目に付与して表示する。具体的には、メールクライアント制御部５０がメールを受け取った後、判定依頼フラグの付与されているメールについて、受信者へのメール内容表示の際に、図１０に示すメール受信者の判断指定画面(Z６１０)を表示して判定を促す。判定後、送信ボタンにより、判定結果をメールクライアント制御部５０から判定依頼処理部２１へ通知する。ここで、判断指定画面(Z６１０)は判定を依頼している同報者の数分が表示される。

図１１は、メール利用者のメール受信リスト画面の例を具体的に現した図である。通常の「返信要求」や「宛先種別」、「件名」といった表示と共に、判定重要度欄(Z６２０)および判定依頼欄(Z６２１)を追加して表示する。メールクライアント制御部５０が受信メールを受け取った後、メールの処理結果欄およびメールの判定依頼フラグ欄のデータをもとに、受信メールリストの判定重要度(Z６２０)および判定依頼欄(Z６２１)へ表示する。判定重要度(Z６２０)については、処理結果のあるもののみを、判定依頼欄(Z６２１)については判定依頼フラグのあるもののみを表示する。

図１２は、重要度判定者DB３０の例を具体的に現した図である。重要度判定者DB３０には、図１３のZ６３０からZ６３１で示すように、判定依頼元氏名(Z６３０)、判定依頼元ID番号(Z６３１)が登録される。本データベースへの登録は、メール利用者から重要度判定依頼があった場合に、判定者指定処理部２０が重要度判定者DB３０へ登録する。

図１３は、判定者選択元DB３１の例を具体的に現した図である。判定者選択元DB３１には、Z６４０からZ６４４で示すような項目が登録されている。Z６４０にはメール利用登録者のID番号が登録されている。Z６４１にはメール利用登録者の所属組織が会社名からユニットの名称まで階層的に登録されている。Z６４２にはメール利用登録者の役職が登録されている。Z６４３にはメール利用登録者が業務などで頻繁にやり取りをする関連部署が登録されている。Z６４４にはメール利用登録者が登録されているプロジェクトの登録先が登録されている。これらの項目は、メールの判定依頼先リストを決める際のキーとなるもので、本実施例では、判定者指定処理部２０の要求を受けて、組織（Z６４１）をキーワードとして候補者の抽出を行う。具体的には、重要度判定者の選択依頼があった場合に、組織（Z６４１）の項目を参照し、依頼元と同じ組織や所属の人を選び出し、氏名およびID番号を返す。なお、本実施例ではID番号(Z６４０)へは0以外の一意の数値を割り当てる。

図１４は、重要度DB３２の例を具体的に現した図である。重要度DB３２には、メールクライアント制御部５０から送られてきたメール識別番号(Z６５０)、依頼元のID番号(Z６５０)、判定依頼先のID番号(Z６５２)、判定結果(Z６５３)が登録される。この時、メール識別番号(Z６５０)及び依頼元のID番号(Z６５１)、判定依頼先のID番号(Z６５２)の全てが同じものがある場合は、そのデータの判定結果のみを上書きする。

図１５は、メールDB３３の例を具体的に現した図である。メールDB３３には、通常のメール送受信時に必要となる送信者や受信者一覧、タイトル等の項目の他に、メール識別番号(Z６６０)、判定依頼フラグ(Z６６１)、処理結果(Z６６２)が登録される。はじめに、外部からメールが送られてきた際に、メールサーバ制御部２４によりメール識別番号(Z６６０)が付与され、さらに判定依頼フラグ(Z６６１)へ初期値として０を登録し、処理結果(Z６２２)へも期値として０を登録してメールDB３３へ格納する。次に、重要度判定依頼がある場合にはメールサーバ制御部２４により、判定依頼フラグとして依頼元IDを依頼先メールの判定依頼フラグ(Z６６１)へ登録される。また、メール利用者がメール受信依頼をした際に、重要度判定依頼をしていてかつ判定結果がある場合に、重要度判断部２２により、重要度判定の処理結果を処理結果(Z６２２)へ登録される。

本発明のメールシステムの全体構造を示す構成図。 本発明の実施例で重要度判定依頼元が判定処理を依頼した時の処理の流れを説明するシーケンス図。 本発明の実施例で重要度判定依頼先を指定する処理の流れを説明するシーケンス図。 本発明の実施例で重要度判定依頼及び結果の格納までの流れを説明するシーケンス図。 本発明の実施例でメール受信依頼から重要度判定依頼元へ結果を提示するまでの流れを説明するシーケンス図。 本発明の実施例で重要度判定依頼先リストを入手してメールDBへ判定依頼フラグを付加する手順を説明するフローチャート。 本発明の実施例でクライアント側での重要度判定の手順を説明するフローチャート。 本発明の実施例で判定結果の統計処理を説明するフローチャート。 本発明の実施例でメールの重要度判定依頼画面の例を説明する図。 本発明の実施例でメール受信者の判断指定画面の例を説明する図。 本発明の実施例で重要度の判定依頼および判定結果をメール利用者へ提示する画面の例を説明する図。 本発明の実施例で重要度判定者データベースのデータ構造の例を説明する図。 本発明の実施例で判定者選択元データベースのデータ構造の例を説明する図。 本発明の実施例で重要度データベースのデータ構造の例を説明する図。 本発明の実施例でメールデータベースのデータ構造の例を説明する図。

符号の説明

１…計算機（メールサーバ）、２…計算機（クライアント）、３…ネットワーク、１０…CPU（メールサーバ）、１１…キーボード（メールサーバ）、１２…ディスプレイ（メールサーバ）、１３…NIC（メールサーバ）、１４…主記憶装置（メールサーバ）、１５…HDD（メールサーバ）、２０…判定者指定処理部、２１…判定依頼処理部、２２…重要度判断部、２３…メール送受信部、２４…メールサーバ制御部、２５…OS（メールサーバ）、３０…重要度判定者DB、３１…判定者選択元DB、３２…重要度DB、３３…メールDB、４０…CPU（クライアント）、４１…キーボード（クライアント）、４２…ディスプレイ（クライアント）、４３…NIC（クライアント）、４４…主記憶装置（クライアント）、４５…HDD（クライアント）、５０…メールクライアント制御部、５１…OS（クライアント）。

Claims (3)

1. ネットワークを利用した電子メールシステムにおいて、メールの利用者が同報のメールに対して重要度判断を実施してもらえるように処理を依頼する依頼手段と、依頼元の人を重要度判定者DBへ登録する登録手段と、送られてきた電子メールに対しメール識別番号を付与する付与手段と、重要度判定者DBへ登録された人へ同報のメールが送られてきた場合に判定者選択元DBから情報を取り出しメールの重要度を判断してもらう人を指定するための指定手段と、選択された特定の人をメールDBへ判定依頼フラグとして登録する登録手段を備え、同報メールが来た時に、電子メールの重要度を判断してもらう人の指定をすることを特徴とするメールシステム。
2. メール利用者がメールを受信した際に、メールDBからメールを取り出して、判定依頼フラグを付与されたメールを受信者へ送付する送付手段と、判定依頼フラグのついているメールに対して重要度判定画面を表示し、重要度判断結果の入力を促す表示手段と、判定した結果を通知する通知手段と、受け取った重要度を重要度DBへ格納する格納手段を備え、同報のメールに対して、特定した受信者に重要度判断を実施させ、その重要度情報を入手することを特徴とするメールシステム。
3. 重要度判定依頼元がメールを受信した際に、重要度判定者DBへ登録されている人を確認し、登録されている人への同報メールに対する判定結果を重要度DBから取得する取得手段と、重要度判定結果が複数ある場合に判定結果の統計処理を行う統計処理手段と、重要度の判定結果をメールDBへ格納し、判定結果を付与したメールを受信者へ送付する送付手段と、判定結果画面を表示する表示手段を備え、入手した重要度情報の処理を実施し、重要度依頼者へ通知することを特徴とするメールシステム。

Images