JP2004110444A - Management system and method for e-mail - Google Patents
Management system and method for e-mail Download PDFInfo
- Publication number
- JP2004110444A JP2004110444A JP2002272425A JP2002272425A JP2004110444A JP 2004110444 A JP2004110444 A JP 2004110444A JP 2002272425 A JP2002272425 A JP 2002272425A JP 2002272425 A JP2002272425 A JP 2002272425A JP 2004110444 A JP2004110444 A JP 2004110444A
- Authority
- JP
- Japan
- Prior art keywords
- information
- reply
- user
- received
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
Description
【0001】
【発明の属する技術分野】
本発明は電子メールシステムに関する。
【0002】
【従来の技術】
従来の電子メールシステムにおいては、ユーザが受信したメールの重要度の判断支援のためのものがある(たとえば、特許文献1参照。)。特許文献1では、送信者により回答期限が設定されたメールを回答漏れがあってはいけない重要なメールと考え、期限が近付くとユーザに回答期限が近い旨のメッセージ出力を行っている。
【0003】
【特許文献1】
特開平11−103314号公報(第2−3頁、第4図)
【0004】
【発明が解決しようとする課題】
従来の電子メールシステムでは、送信者により回答期限がヘッダや主題、本文中に設定されているメールに関しては返信する必要がある、重要度の高いメールとして処理されていた。しかし、送信者が回答期限を設定していなくても返信を要求する場合がある。そのような場合、従来の技術では対応できなかった。また、ユーザが返信要求をして送信したメールに対する返信メールに対しての優先度も考慮されていなかった。
【0005】
さらに、回答期限が近くなったメールに対しては、メッセージを出力する形でその旨をユーザに知らせていたが、その場合、同時に何通もメッセージが出力された場合、その対応に時間をとられてしまい却ってメールの処理効率が下がってしまうという問題があった。
【0006】
本発明の目的は、送信者により返信要求が設定されたメールのやりとりに対して、ユーザのメールの処理効率を下げないでその重要度を知らせることである。
【0007】
【課題を解決するための手段】
本発明の電子メールシステムであって、電子メールの送信ログを記憶装置に格納する手段と、前記送信ログに含まれる返信要求の情報と期限の情報と返信の有無の情報とにもとづいて、電子メールの情報を画面に表示させる順位を決定する手段とを備えることを特徴とする。
【0008】
また、上記課題を解決するために、本発明は次の特徴を持つ。1.メールに送信者によって返信要求属性が設定されていた場合、そのメールのメールヘッダや主題・本文に期限情報が設定されているか、ユーザが既に返信しているか、ユーザがメールを読んだかに基づいて優先度を決定するための手段を持つこと。2.受信メールに対し、ユーザが返信要求属性を設定したメールへの返信メールかどうかに基づいて優先度を決定するための手段を持つこと。3.1および2の条件に、メールの開封属性(既読・未読)の条件を追加考慮して、優先度の高いものから順に受信メール一覧の画面に表示する手段を持つこと。
【0009】
【発明の実施の形態】
以下、図面を参照しながら本発明の1実施形態を説明する。
図1は、本発明が適用される電子メールシステムの構成図である。電子メールシステムは、メールクライアント110とメールサーバ120から構成される。本実施形態では、送信されてきたメールはメールサーバ120からメールクライアント110に一度ダウンロードされてから表示されるものとする。
【0010】
メールクライアント110は、メール受信者が使用する装置の集まりであり、メールサーバ120へのログイン処理部111、メールサーバ120にメールを転送するメール送信部112、メールサーバ120からメールをダウンロードするメール受信部113、送信メールのメールヘッダを解析したり、メールサーバ120からダウンロードされたメールのメールヘッダを解析して受信用テーブルを作成したりするメール解析部114、それらの情報を表示するメール表示部115、および受信用テーブルを記憶する記憶装置116から構成される。
【0011】
メールサーバ120は、メールの送受信などを司る装置の集まりであり、メールクライアント110を使用しているユーザの認証部121、ユーザ宛に送信されてきたメールを保管してユーザの要求に従って受信メールのメールヘッダを解析しメールクライアント110にそれらの情報を配信する受信メール管理部122、ユーザが送信したメールの返信要求属性を解析して情報を送信用テーブルに保管してから送信処理を実行する送信メール管理部123、および送信用テーブルを記憶する記憶装置124から構成される。
【0012】
なお、メールクライアント110およびメールサーバ120には、通常のメールシステムが持つほかの機能部も存在するが、本発明と直接関連しないため、図示を省略する。
【0013】
図2はメールの作成からメールを送信するまでの処理フロー示している。
なお、メールクライアント110のメールサーバ120へのログイン処理は一般的な処理と変わりがないので、ログイン処理が終了しているものとして説明する。
【0014】
ユーザはまず送信メールエディタなどを用いて、送信するメールを作成する(ステップ211)。ここで、ユーザが送信先の相手にメールの返信を望む場合、返信要求属性を設定することができる。メール作成中に返信要求のボタンを押すなどして返信要求属性を付けると、作成したメールには返信要求を示すメールヘッダ「RepDmd:1」が設定される。この属性が付いているメールを受信すると、メール表示画面には「返信要求あり」の情報が表示される。次に、メール解析部114は、送信メールのメールヘッダReferenceの値を参照して、それが記憶装置116の受信用テーブルのMessage−IDに同じ値があるかどうか検索する(ステップ212)。
【0015】
ここでメールヘッダReferenceとは、ある受信メールに対しての返信メールである場合に付加されるメールヘッダで、従来から使用されているものである。ここには、返信対象のメールに設定されているメールヘッダMessage−IDの値が設定される。Message−IDはメールの識別子として使用される従来からあるメールヘッダである。つまり、ステップ212の検索がヒットした場合、ユーザの送信メールは受信メールに対する返信メールであることを意味する。受信用テーブルについては後述する(図6)。
【0016】
検索がヒットした場合、メール解析部114は、ヒットした受信メールに返信要求フラグが1であるか調べる(ステップ213)。1の場合、受信用テーブルの処理済フラグに1を設定する(ステップ214)。これにより返信要求のあった受信メールに返信をしたことが、受信用テーブルに記録される。ステップ212の検索がヒットしなかった場合、ステップ213で返信要求フラグが1でなかった場合、またはステップ214の処理のあと、メール送信部112により、メールサーバ120の受信メール管理部122に送信メールを転送する(ステップ215)。
受信メール管理部122は、送信メールを受け取るとステップ221で送信メールに返信要求(メールヘッダRepDmd:1)または期限情報が設定されているかを調べる。
【0017】
期限情報は、特開平11−103314などで回答期限と称している公知の技術である。返信要求または期限情報があった場合、記憶装置124の送信用テーブルに、送信メールのメールヘッダMessage−IDおよびSubjectの値を設定する(ステップ222)。これは受信メールが来たときに、ユーザが返信要求を設定したメールに対する返信メールかを調べるのに使用する。送信用テーブルについては後述する(図3)ステップ221で返信要求または期限情報が設定されていなかった場合、またはステップ222のあと、メールサーバ120は通常のメール送信処理を行い(ステップ223)フローは終了する。
【0018】
図3を参照して送信用テーブル300について説明する。送信用テーブルは、ユーザが返信要求または期限情報を設定したメールを送信したときに、そのデータを記憶しておくもので、記憶装置124に作成される。送信用テーブル300では、送信メールのメールヘッダMessage−IDとSubjectの値がテーブルMessage−ID311とSubject312に格納される。
【0019】
図4はメールクライアント110のログインから受信メール一覧を表示するまでの処理フローを示している。
メールクライアント110の処理を開始すると、まずログイン処理部がステップ411でメールクライアント110からメールサーバ120にログインするために、ユーザからユーザIDやパスワードなどのログイン情報の入力を受け付け、メールサーバ120のユーザ認証部に送付する。次に、メールサーバ120のユーザ認証部が入力されたログイン情報からユーザ認証を行う(ステップ421)。正しく認証できた場合、ユーザ認証部はメールクライアント110にユーザ情報を送付する。メールクライアント110のログイン処理部はメールサーバ120からユーザ情報(メールアドレス)を受信する(ステップ412)。
【0020】
本実施例では、ユーザ情報がメールサーバ120で管理され、メールクライアント110はその情報を持っていないものとしているが、メールクライアント110にあらかじめユーザ情報が登録されている場合や、受信メールの処理をメールサーバ120で行う場合などは、ステップ412は必要ない。
【0021】
なお、フローには図示していないが、ステップ421でユーザ認証が正しくできなかった場合、メールクライアント110にその旨報告され、メールクライアント110はその旨をユーザに表示し、ログイン情報の再入力を待つ。
【0022】
次に、メールクライアント110のメール受信部はメールサーバ120のメール管理部に対して、メール受信要求(ステップ413)を行う。
そして、メールサーバ120のメール管理部はログインしたユーザ宛に届いている受信メールに返事フラグ付加処理を行う(ステップ422)。返事フラグ付加処理とは、受信メールがユーザが返信要求を設定した送信メールに対する返信メールの場合、受信メールのメールヘッダにRepMail:1を付加する処理である。ステップ422のフローについては、図5で説明する。
【0023】
ステップ422のあと、メールサーバ120はメールクライアント110に受信メールを配信する(ステップ423)。メールクライアント110は、配信されたメールを受信すると(ステップ414)、受信用テーブル600を記憶装置116に生成する(ステップ415)。受信用テーブル600はメールの重要度を決定するために使用する。受信用テーブルの詳細については、図6で説明する。
【0024】
ステップ415で受信用テーブルの生成が終了すると、ステップ416で受信用テーブルの情報に基づいて受信メールに優先順位を付けて一覧表示して処理を終了する。ステップ416のフローについては、図7で説明する。
なお、メールの開封やメールの返信など、受信用テーブルの内容に変更を伴う操作があった場合は、ステップ415、ステップ416の処理を実行する。
【0025】
図5を参照して、ステップ422の返事フラグ付加処理のフローを説明する。
返事フラグ付加処理とは、ユーザが返信要求を設定して送信したメールに対しての返信メールのメールヘッダに、返事フラグ(RepMail:1)を付加するものである。返事フラグ付加処理は、受信メール管理部122で行われる。処理を開始すると、ステップ501で受信メールのメールヘッダReferenceの値を参照する。そして、その値が送信用テーブル300のMessage−ID310に同じ値が存在するか検索する(ステップ502)。存在しない場合、処理を終了する。存在した場合、次に受信メールのメールヘッダSubjectの値を参照する(ステップ503)。
【0026】
そして、送信用テーブル300のSubject312の値をその中に含むか調査する(ステップ504)。含まない場合(=メールタイトルが異なる)、ユーザの返信要求に対する返信メールではないと考えられるので処理を終了する。含む場合、ユーザの返信要求に対する返信メールと考え、受信メールのメールヘッダに返事フラグ(RepMail:1)を付加する。こうすることで、ユーザが返信要求を設定したメールに対する返信メールを知ることができる。
【0027】
図6を参照して受信用テーブル600について説明する。受信用テーブルは、受信メールの重要度を決定する情報をを記憶しておくもので、記憶装置116に作成される。受信用テーブル600には、次の要素が格納される。
【0028】
メールINDEX611:受信メールを管理するためのIDである。メールを受信したときに一意に設定される。
処理済フラグ612:返信要求のある受信メールに対して、ユーザが返信したかを示すフラグである。メール受信時のデフォルト値は0で、送信処理のステップ214で1に設定される。また、ユーザが返信しなくても、メール表示画面からボタンなどで「処理済」設定をすることで、1を設定することができる。これにより、返信要求が設定されているがユーザが返信の必要はないと判断したメールを「処理済」にして重要度を下げるようにできる。
【0029】
返信要求フラグ613:受信メールに返信要求が設定されているかを示すフラグである。メール受信時にメールヘッダを参照して、RepDmd:1があるときは1が、ないときは0が設定される。
期限情報614:受信メールに設定されている回答期限などの期限情報が設定される。
【0030】
返事フラグ615:受信メールが、ユーザが返信要求を設定して送信したメールに対する返信メールかを示すフラグである。メール受信時にメールヘッダを参照して、RepMail:1があるときは1が、ないときは0が設定される。
開封情報616:受信メールがユーザによって開封されたかそうかを示す情報である。メール受信時にデフォルト値「未読」が設定され、メールが開封されると「既読」が設定される。
【0031】
Message−ID617:メール送信処理のステップ221で回答済フラグの設定のために参照される情報である。メール受信時にメールヘッダMessage−IDの値が設定される。
Subject618:メール受信処理のステップ422で返事フラグの設定のために参照される情報である。メール受信時にメールヘッダSubjectの値が設定される。
ステップ416の受信メール一覧表示のときには、これらの情報を参照して、受信メールの重要度を決定する。
【0032】
図7を参照して、ステップ416の受信メール一覧表示のフローを説明する。
受信メール一覧表示では、受信用テーブルの情報に基づいてソートして重要度の高いメールから順に表示する。処理を開始すると、受信用テーブル600の処理済フラグ612によるソートを行う(ステップ701)。ここでは、0(未処理)が設定されているメールの方が、1(処理済)が設定されているメールより重要度が高くなる。
【0033】
次にステップ702で、ステップ701の結果グループ化された集団それぞれに対して、返信要求フラグによるソートを行う。ここでは、1(要求あり)の方が0(要求なし)よりも重要度が高くなる。
【0034】
次にステップ703で、ステップ702の結果グループ化された集団それぞれに対して、期限情報によるソートを行う。ここでは、まず期限情報が設定されているメールとされていないメールに分けられる。期限情報が設定されているメールの方が、されていないメールより重要度が高くなる。次に期限情報が設定されているメールを期限情報の日付の若い順にソートする。期限の日付がすでに過ぎてしまっている場合でも、日付の若い順にソートする。こうすることで、期限情報が設定されている(返信要求がある)のにユーザが返信していない情報は、重要度が高くなる。
【0035】
次にステップ704で、ステップ703の結果グループ化された集団それぞれに対して、返事フラグによるソートを行う。ここでは、1(返事)の方が0(通常メール)よりも重要度が高くなる。
最後にステップ705で、ステップ704の結果グループ化された集団それぞれに対して、開封情報によるソートを行う。ここでは、未読の方が既読よりも重要度が高くなる。
【0036】
図8は、ステップ416によるソート結果で決定する、メールの重要度(=表示順序)を表にしたものである。
この表では、受信用テーブル内の情報の組み合わせと重要度の関係を示している。なお、上位にあるものほど重要度が高い。
【0037】
たとえば、一番重要度が高く受信メール一覧の上位に表示されるメールは、メール801である。これは、処理済フラグが0、返信要求フラグが1、設定されている期限情報が最も若い日付で、ユーザが返信要求を設定したメールに対する返事で、未読のメールである。つまり、ユーザが返信要求したメールの返事で、さらに送信者から回答期限を要求されたメールを、まだ開封してない場合、重要度が最も高くなる。
【0038】
このようにしてメールの重要度を決定し表示することで、送信者により返信要求が設定されたメールのやりとりに対して、ユーザのメールの処理効率を下げないでその重要度を知らせる電子メールシステムが実現する。
【0039】
【発明の効果】
受信メールに返信要求や、回答期限などの期限情報に基づいて優先順位を付け、それらを優先順位に従って一覧表示することで、メールの重要度を判断しやすくし、メール処理作業の効率を向上させることができる。
【図面の簡単な説明】
【図1】本発明が適用される電子メールシステムの構成を示す図である。
【図2】本発明によるメール送信処理を実施する際のフローチャートを示す図である。
【図3】メールの送信時に作成される送信用テーブルのデータ構造を示す図である。
【図4】本発明によるメール受信処理を実施する際のフローチャートを示す図である。
【図5】メール受信時処理:返事フラグ付加処理のフローチャートを示す図である。
【図6】メールの受信時に作成される受信用テーブルのデータ構造を示す図である。
【図7】受信メール一覧を表示する際の重要度決定処理のフローチャートを示す図である。
【図8】重要度決定処理によって付けられる重要度と受信用テーブルの情報の組み合わせとの関連を示す図である。
【符号の説明】
110…メールクライアント
111…ログイン処理部
112…メール送信部
113…メール受信部
114…メール解析部
115…メール表示部
116…記憶装置
120…メールサーバ
121…ユーザ認証部
122…受信メール管理部
123…送信メール管理部
124…記憶装置[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an electronic mail system.
[0002]
[Prior art]
2. Description of the Related Art In a conventional electronic mail system, there is a system for assisting a user in determining the importance of a received mail (for example, see Patent Document 1). In
[0003]
[Patent Document 1]
JP-A-11-103314 (page 2-3, FIG. 4)
[0004]
[Problems to be solved by the invention]
In a conventional e-mail system, a mail whose reply time limit is set in the header, the subject, or the text by the sender is processed as a highly important mail that needs to be replied. However, a reply may be requested even if the sender has not set a response time limit. In such a case, the conventional technology could not cope. Further, the priority of the reply mail to the mail transmitted by the user with the reply request is not considered.
[0005]
In addition, for mails for which the response deadline is approaching, a message is output to notify the user of this fact.In this case, if several messages are output at the same time, take time to respond. There was a problem that the processing efficiency of the mail would be reduced instead.
[0006]
SUMMARY OF THE INVENTION An object of the present invention is to notify the importance of the exchange of mail for which a reply request has been set by the sender without lowering the processing efficiency of the user's mail.
[0007]
[Means for Solving the Problems]
An electronic mail system according to the present invention, comprising: means for storing an e-mail transmission log in a storage device; and an electronic mail based on information on a reply request, information on a time limit, and information on the presence or absence of a reply included in the transmission log. Means for determining the order in which the information of the mail is displayed on the screen.
[0008]
Further, in order to solve the above-mentioned problems, the present invention has the following features. 1. If a reply request attribute is set by the sender in the mail, it is based on whether the expiration information is set in the mail header, subject, or body of the mail, whether the user has already responded, or whether the user has read the mail. Have a means to determine priorities. 2. A means for determining the priority of the received mail based on whether or not the mail is a reply mail to the mail for which the reply request attribute is set by the user. 3. A means for displaying on the received mail list screen in ascending order of priority in consideration of the conditions of the opening attribute (read / unread) of the mail in addition to the conditions of 1 and 2.
[0009]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a configuration diagram of an electronic mail system to which the present invention is applied. The e-mail system includes a
[0010]
The
[0011]
The
[0012]
The
[0013]
FIG. 2 shows a processing flow from creation of a mail to transmission of the mail.
Note that the log-in process of the
[0014]
First, the user creates a mail to be transmitted using a transmission mail editor or the like (step 211). Here, when the user wants to reply to the mail to the destination, the reply request attribute can be set. When a reply request attribute is added by, for example, pressing a reply request button during mail creation, a mail header “RepDmd: 1” indicating a reply request is set in the created mail. When a mail with this attribute is received, information of "reply requested" is displayed on the mail display screen. Next, the
[0015]
Here, the mail header Reference is a mail header added when the mail is a reply mail to a certain received mail, and has been conventionally used. Here, the value of the mail header Message-ID set in the reply target mail is set. Message-ID is a conventional mail header used as a mail identifier. In other words, if the search in
[0016]
If the search is hit, the
Upon receiving the outgoing mail, the received
[0017]
The term information is a known technique referred to as a reply term in Japanese Patent Application Laid-Open No. 11-103314. If there is a reply request or time limit information, the value of the mail header Message-ID and the subject of the outgoing mail is set in the transmission table of the storage device 124 (step 222). This is used to check whether or not a received mail arrives as a reply to the mail for which the user has set a reply request. For the transmission table, which will be described later (FIG. 3), if no reply request or time limit information has been set in
[0018]
The transmission table 300 will be described with reference to FIG. The transmission table stores data when a user sends a reply request or an e-mail in which time limit information is set, and is created in the
[0019]
FIG. 4 shows a processing flow from the login of the
When the processing of the
[0020]
In this embodiment, it is assumed that the user information is managed by the
[0021]
Although not shown in the flow, if the user authentication has failed in
[0022]
Next, the mail receiving unit of the
Then, the mail management unit of the
[0023]
After
[0024]
When the generation of the receiving table is completed in
If there is an operation that changes the contents of the receiving table, such as opening the mail or replying to the mail, the processing of
[0025]
The flow of the reply flag adding process in
The reply flag adding process is to add a reply flag (RepMail: 1) to the mail header of a reply mail to the mail set by the user to send a reply request. The reply flag adding process is performed by the received
[0026]
Then, it is checked whether or not the value of the
[0027]
The reception table 600 will be described with reference to FIG. The receiving table stores information for determining the importance of the received mail, and is created in the
[0028]
Mail INDEX 611: ID for managing received mail. Uniquely set when an email is received.
Processed flag 612: This flag indicates whether the user has replied to the received mail for which a reply request has been made. The default value at the time of mail reception is 0, and is set to 1 at
[0029]
Reply request flag 613: A flag indicating whether a reply request is set in the received mail. When a mail is received, the mail header is referred to, and if RepDmd: 1 is set, 1 is set, and if not, 0 is set.
Deadline information 614: Deadline information such as the response deadline set in the received mail is set.
[0030]
Reply flag 615: This is a flag indicating whether the received mail is a reply mail to the mail transmitted by setting the reply request by the user. When a mail is received, a mail header is referred to, 1 is set when RepMail: 1 is present, and 0 is set when RepMail is not present.
Opening information 616: Information indicating whether the received mail has been opened by the user. The default value “unread” is set when receiving mail, and “read” is set when the mail is opened.
[0031]
Message-ID 617: Information referred to for setting the answered flag in
Subject 618: Information referred to for setting a reply flag in
At the time of displaying the received mail list in
[0032]
With reference to FIG. 7, the flow of the received mail list display in
In the received mail list display, the mails are sorted based on the information in the receiving table and displayed in order from the mail having the highest importance. When the processing is started, sorting is performed by the processed
[0033]
Next, in
[0034]
Next, in
[0035]
Next, in
Finally, in
[0036]
FIG. 8 is a table showing the importance (= display order) of the mail determined by the sorting result in
This table shows the relationship between the combination of information in the receiving table and the importance. The higher the rank, the higher the importance.
[0037]
For example, the mail with the highest importance and displayed at the top of the received mail list is the
[0038]
By determining and displaying the importance of the mail in this way, an e-mail system that notifies the importance of the exchange of mail for which a reply request has been set by the sender without lowering the processing efficiency of the user's mail. Is realized.
[0039]
【The invention's effect】
Priorities are assigned to received e-mails based on deadline information such as reply requests and response deadlines, and these are displayed in a list according to the priority, making it easier to determine the importance of the e-mail and improving the efficiency of e-mail processing be able to.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of an electronic mail system to which the present invention is applied.
FIG. 2 is a diagram showing a flowchart when performing a mail transmission process according to the present invention.
FIG. 3 is a diagram showing a data structure of a transmission table created when a mail is transmitted.
FIG. 4 is a diagram showing a flowchart when performing a mail receiving process according to the present invention.
FIG. 5 is a diagram showing a flowchart of mail reception processing: reply flag addition processing.
FIG. 6 is a diagram showing a data structure of a receiving table created when receiving a mail.
FIG. 7 is a diagram showing a flowchart of an importance determination process when a received mail list is displayed.
FIG. 8 is a diagram illustrating a relationship between the importance assigned by the importance determination processing and a combination of information in a reception table.
[Explanation of symbols]
110 ...
Claims (5)
前記計算機は、予め記憶装置に格納された電子メールと対応づけられた送信元からの返信要求の有無の情報と期限の情報と受信者から送信者への返信の有無の情報を読み出し、
前記読み出した情報にもとづいて電子メールの情報を画面へ表示させることを特徴とする電子メールの管理方法。An e-mail management method using a computer,
The computer reads the information on the presence or absence of a reply request from the sender and the information on the time limit and the information on the presence or absence of a reply from the receiver to the sender from the sender associated with the e-mail stored in advance in the storage device,
An e-mail management method, comprising displaying e-mail information on a screen based on the read information.
電子メールの送信ログを記憶装置に格納する手段と、
前記送信ログに含まれる返信要求の情報と期限の情報と返信の有無の情報とにもとづいて、電子メールの情報を画面に表示させる順位を決定する手段とを備えることを特徴とする電子メールシステム。An email system,
Means for storing an e-mail transmission log in a storage device;
An e-mail system comprising: means for determining the order in which e-mail information is to be displayed on a screen based on reply request information, time limit information, and presence / absence of a reply included in the transmission log. .
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002272425A JP2004110444A (en) | 2002-09-19 | 2002-09-19 | Management system and method for e-mail |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002272425A JP2004110444A (en) | 2002-09-19 | 2002-09-19 | Management system and method for e-mail |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004110444A true JP2004110444A (en) | 2004-04-08 |
Family
ID=32269443
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002272425A Pending JP2004110444A (en) | 2002-09-19 | 2002-09-19 | Management system and method for e-mail |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004110444A (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011053611A (en) * | 2009-09-04 | 2011-03-17 | Ricoh Co Ltd | Electronic signboard device and control program |
US8477381B2 (en) | 2006-10-03 | 2013-07-02 | Konica Monolta Business Technologies, Inc. | Document administration apparatus, document administration method and recording medium |
-
2002
- 2002-09-19 JP JP2002272425A patent/JP2004110444A/en active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8477381B2 (en) | 2006-10-03 | 2013-07-02 | Konica Monolta Business Technologies, Inc. | Document administration apparatus, document administration method and recording medium |
JP2011053611A (en) * | 2009-09-04 | 2011-03-17 | Ricoh Co Ltd | Electronic signboard device and control program |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10185479B2 (en) | Declassifying of suspicious messages | |
JP5383660B2 (en) | Synchronization of email messages between external email servers and / or local email servers and / or wireless devices | |
US7979495B2 (en) | Method and system for removing a person from an e-mail thread | |
JP4871113B2 (en) | Method and system for providing version control of email attachments | |
JP5129567B2 (en) | Messaging protocol for processing messages with attachments | |
US9015252B2 (en) | Method and system for forcing e-mail addresses into blind carbon copy (“Bcc”) to enforce privacy | |
KR101965023B1 (en) | Time-managed electronic mail messages | |
US6999993B1 (en) | Methods and systems for end-users extensible electronic mail | |
US20050198171A1 (en) | Managing electronic messages using contact information | |
US7945629B2 (en) | Active removal of e-mail recipient from replies and subsequent threads | |
JP2010525740A (en) | Apparatus and method for caching email messages within a wireless data service | |
JP2007065787A (en) | Mail transmission/reception program and mail transmission/reception device | |
US20100131666A1 (en) | System and Method for Managing Data Transfers Between Information Protocols | |
US20070124385A1 (en) | Preference-based content distribution service | |
US8095604B2 (en) | Automatically modifying distributed communications | |
CN101009666B (en) | Email sending control system and method | |
JP2010528356A (en) | Method, system, and computer program for correcting an email message with unsent recipients | |
JP2009169866A (en) | Electronic mail client and its control method, and computer program | |
US7627635B1 (en) | Managing self-addressed electronic messages | |
US9083558B2 (en) | Control E-mail download through instructional requests | |
JP2008242726A (en) | Mail processing server, mail management method, and program | |
JP2004110444A (en) | Management system and method for e-mail | |
JP2009118174A (en) | Information processor, approval method, and program | |
US20050216588A1 (en) | Blocking specified unread messages to avoid mailbox overflow | |
US20090187636A1 (en) | Mail sending and receiving apparatus and mail sending and receiving system |