JPH1168832A - 電子メールシステム、および電子メールシステムプログラムを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 サーバを介してメールのやり取りを行う電子
メールシステムにおいて、不要なメールを受信者側が読
むことを防止し、キャンセル処理における送信者側の作
業を容易にする。 【解決手段】 サーバ１のメール処理手段１ａは、送信
側クライアント２から送信されたメールをメール記憶手
段１ｂに格納する。また、メール処理手段１ａは、受信
側クライアント３からの要求に応じてメール記憶手段１
ｂ内の対応するメールを提供する。そして、キャンセル
処理手段１ｃは、すでに送信されたメールのキャンセル
要求が送信側クライアント２からなされると、キャンセ
ル要求されたメールを受信側クライアント３が未開封の
場合、メール記憶手段１ｂ内の対応するメールを削除す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はサーバを介してメー
ルのやり取りを行う電子メールシステム、および電子メ
ールシステムプログラムを記録した記録媒体に関し、特
にメールの開封状態を管理する電子メールシステム、お
よび電子メールシステムプログラムを記録した記録媒体
に関する。

【０００２】

【従来の技術】従来、サーバを介してメールのやり取り
を行う電子メールシステムとしては、例えば特許第２５
８０８４９号がある。この発明では、中継システムが受
信したデータを保留し、送信元から宛て先アドレス変更
が通知された場合、転送保留中のデータを変更された宛
て先アドレスが指示するシステムに向けて中継、転送す
る宛て先アドレス変更ルーチン制御方式が開示されてい
る。

【０００３】

【発明が解決しようとする課題】しかし、特許第２５８
０８４９号では、メールの送信後に送信先を変更するこ
とができるが、送信そのものをキャンセルすることがで
きなかった。このため、受信者側では、自分に不要なメ
ールを読まされることがあった。また、送信側でも、メ
ールをキャンセルにしたことを知らせるためには、新た
に訂正のメールを送信しなければならず、作業効率が悪
かった。

【０００４】本発明はこのような点に鑑みてなされたも
のであり、不要なメールを受信者側が読まないですむよ
うにでき、またキャンセル処理における送信者側の作業
を容易にすることのできる電子メールシステム、および
電子メールシステムプログラムを記録した記録媒体を提
供することを目的とする。

【０００５】

【課題を解決するための手段】本発明では上記課題を解
決するために、サーバを介してクライアント間でメール
のやり取りを行う電子メールシステムにおいて、クライ
アントから送信されたメールをメール記憶部に格納する
一方、受信側のクライアントの要求に応じて前記メール
記憶部内の対応するメールを前記受信側のクライアント
に提供するメール処理手段と、前記送信側のクライアン
トから前記送信したメールに対するキャンセル要求がな
され、かつ、前記キャンセル要求されたメールを受信側
のクライアントが未開封の場合、前記メール格納手段内
の対応するメールを削除するキャンセル処理手段と、を
有することを特徴とする電子メールシステムが提供され
る。

【０００６】このような電子メールシステムでは、メー
ル処理手段は、クライアントから送信されたメールをメ
ール記憶部に格納する。また、メール処理手段は、受信
側のクライアントからの要求に応じてメール記憶部内の
対応するメールを提供する。キャンセル処理手段は、す
でに送信されたメールのキャンセル要求が送信側のクラ
イアントからなされ、かつ、キャンセル要求されたメー
ルを受信側のクライアントが未開封の場合、メール記憶
部内の対応するメールを削除する。

【０００７】これにより、受信者側では、自分に不要な
メールを読まされることがない。また、送信側でも、キ
ャンセル要求のみを送信すればよく、新たに訂正のメー
ルを送信する必要がない。

【０００８】また、本発明では、サーバを介してクライ
アント間でメールのやり取りを行う電子メールシステム
プログラムを記録した記録媒体において、クライアント
から送信されたメールをメール記憶部に格納する一方、
受信側のクライアントの要求に応じて前記メール記憶部
内の対応するメールを前記受信側のクライアントに提供
するメール処理手段、前記送信側のクライアントからキ
ャンセル要求がなされ、かつ、前記キャンセル要求され
たメールを受信側のクライアントが未開封の場合、前記
メール格納手段内の対応するメールを削除するキャンセ
ル処理手段、としてサーバを機能させるための電子メー
ルシステムプログラムを記録した記録媒体が提供され
る。

【０００９】この電子メールシステムプログラムをサー
バで実行させれば、受信者側では、自分に不要なメール
を読まされることがなく、また、送信側でも、キャンセ
ル要求のみを送信すればよく、新たに訂正のメールを送
信する必要がない。

【００１０】

【発明の実施の形態】以下、本発明の一形態を図面を参
照して説明する。図１は本発明の電子メールシステムの
機能の概念を示す図である。サーバ１のメール処理手段
１ａは、送信側クライアント２から送信されたメールを
メール格納手段１ｂに格納する。また、メール処理手段
１ａは、受信側クライアント３からの要求に応じてメー
ル格納手段１ｂ内の対応するメールを提供する。そし
て、キャンセル処理手段１ｃは、すでに送信されたメー
ルのキャンセル要求が送信側クライアント２からなさ
れ、かつ、キャンセル要求されたメールを受信側クライ
アント３が未開封の場合には、メール格納手段１ｂ内の
対応するメールを削除する。

【００１１】次に、本発明の電子メールシステムの具体
的な形態について説明する。図２は本形態の電子メール
システムの機能の構成を示すブロック図である。この電
子メールシステム１０は、複数のサーバ１１，１２など
や、複数のクライアント１３，１４，１５，１６，１７
などから構成される。各サーバ１１，１２およびクライ
アント１３，１４，１５，１６，１７間は、ＬＡＮや公
衆回線などのライン１８によって接続されている。ま
た、ここでは、例えば、サーバ１１の管理下にクライア
ント１３，１４，１５が、サーバ１２の管理下にクライ
アント１６，１７があるものとする。

【００１２】サーバ１１には、送信履歴テーブル領域２
１、受信履歴テーブル領域２２、メールスプール領域２
３が、ハードディスクなどの記憶手段内に設けられてい
る。送信履歴テーブル領域２１には、各ユーザからの送
信履歴を格納する送信履歴テーブル２１ａ，２１ｂ，２
１ｃが設けられている。ここでは、クライアント１３，
１４，１５のユーザをそれぞれユーザＵ１，Ｕ２，Ｕ３
と呼ぶことにし、それぞれに対応して送信履歴テーブル
２１ａ，２１ｂ，２１ｃが与えられているものとする。
この送信履歴テーブル２１ａ，２１ｂ，２１ｃには、各
ユーザＵ１，Ｕ２，Ｕ３から送信されたメールの送信日
時など、各種送信履歴データが格納される。送信履歴デ
ータの具体例については後述する。

【００１３】受信履歴テーブル領域２２には、各ユーザ
のメールの受信履歴を格納する受信履歴テーブル２２
ａ，２２ｂ，２２ｃが設けられている。ここでは、クラ
イアント１３，１４，１５のユーザＵ１，Ｕ２，Ｕ３に
対応して、それぞれ受信履歴テーブル２２ａ，２２ｂ，
２２ｃが与えられているものとする。この受信履歴テー
ブル２２ａ，２２ｂ，２２ｃには、各ユーザＵ１，Ｕ
２，Ｕ３宛てに送信されたメールの受信日時など、各種
受信履歴データが格納される。受信履歴データの具体例
については後述する。

【００１４】送信履歴テーブル領域２１および受信履歴
テーブル領域２２の各テーブルへのデータの書き込みや
読み出しは、送受信履歴管理部２５によって行われる。
メールスプール２３には、各ユーザのメールを格納する
メール領域２３ａ，２３ｂ，２３ｃが設けられている。
ここでは、クライアント１３，１４，１５のユーザＵ
１，Ｕ２，Ｕ３のそれぞれに対応して、メール領域２３
ａ，２３ｂ，２３ｃが与えられているものとする。メー
ル管理部２６は、リクエスト処理部２４からの指令に応
じて、各メールにメールＩＤを付してメール領域２３
ａ，２３ｂ，２３ｃに格納したり、メールを読み出して
リクエスト処理部２４に渡す。

【００１５】リクエスト処理部２４は、他のサーバ１
２、各クライアント１３〜１５などから送られるメール
送信要求、開封要求、メールキャンセル要求などに応じ
て、送受信履歴管理部２５およびメール管理部２６に指
令を送り、後述するような、メールの送受信処理を行
う。

【００１６】なお、サーバ１２に関しては、サーバ１１
とほぼ同じ構成なので、説明を省略する。一方、各クラ
イアント１３〜１７には、それぞれ送信箱１３ａ，１４
ａ，１５ａ，１６ａ，１７ａと、受信箱１３ｂ，１４
ｂ，１５ｂ，１６ｂ，１７ｂが設けられている。送信箱
１３ａ，１４ａ，１５ａ，１６ａ，１７ａは、サーバ１
１，１２内の各自対応する送信履歴テーブルのデータを
読み込んで格納するものである。読み込んだデータは、
各クライアント１３〜１７のモニタ上で表示可能であ
る。

【００１７】受信箱１３ｂ，１４ｂ，１５ｂ，１６ｂ，
１７ｂは、サーバ１１，１２内の各自対応する受信履歴
テーブルを読み込んで格納するものである。読み込んだ
データは、各クライアント１３〜１７のモニタ上で表示
可能である。これらの表示例については後述する。

【００１８】次に、このような構成の電子メールシステ
ムのメール処理の具体的な方法について説明する。ま
ず、ここでは、サーバ１１の管理下にあるクライアント
１３〜１５間のみにおけるメールのやり取りについて述
べる。

【００１９】いま、クライアント１３のユーザＵ１が、
クライアント１４，１５のユーザＵ２，Ｕ３に対してメ
ールを送信したとする。このとき、ユーザＵ１は、メー
ルに、受信者および送信者のメールアドレスを付加す
る。受信者のメールアドレスは、「＠」を含む場合、
「＠」の前の部分を受信者のログイン名、「＠」の後の
部分をサーバ名とした文字列で構成される。これを受け
取ったサーバ１１側では、サーバ名が自サーバ名（ここ
では、サーバ１１のサーバ名をserver1 、サーバ１２の
サーバ名をserver2 とする）と異なる場合、その受信者
は他のサーバに属するものとみなす。また、「＠」を含
まない場合には、自サーバとみなす。

【００２０】同様に、送信者のメールアドレスは、送信
者のログイン名に、「＠」とサーバ名を付加した文字列
で構成される。また、後述するように、メールのキャン
セルをする場合には、送り直し情報を付加する。送り直
し情報は、送り直しメールの有無の指定や、メール送信
に必要な内容（ファイルのパス、件名、コメントなど）
で構成される。

【００２１】このようなメールを受け取ったサーバ１１
は、サーバ名と、サーバ内で一意な番号を「・」でつな
いだ文字列をメールＩＤとして、送信されたメールに付
加する。そして、送信履歴テーブル領域２１のユーザＵ
１用の送信履歴テーブル２１ａに、今回のメールに関す
る送信履歴を書き込み、一方、受信履歴テーブル２２の
ユーザＵ２，Ｕ３用の受信履歴テーブル２２ｂ，２２ｃ
に、受信履歴を書き込む。さらに、メールスプール２３
のユーザＵ２，Ｕ３用のメール領域２３ｂ，２３ｃに、
それぞれメールＩＤが付されたメールを格納する。

【００２２】また、各テーブルに格納されたデータは、
各クライアント１３、１４、１５からの要求に応じて読
み出され、それぞれの送信箱１３ａ，受信箱１４ｂ，１
５ｂに格納される。

【００２３】図３はメール送信直後の送信側のクライア
ント用の送信履歴テーブルの一例を示す図であり、
（Ａ）は送信履歴テーブル２１ａ内のデータを示す図、
（Ｂ）はクライアント１３の送信箱１３ａ内のデータを
示す図である。まず、図３（Ａ）に示すように、送信履
歴テーブル２１ａでは、メールＩＤ欄３１、受信者名欄
３２、メール状態欄３３、送信日時欄３４、件名欄３５
が設けられている。ここで、メール状態とは、ユーザＵ
１から送信されたメールがユーザＵ２，Ｕ３に対してど
のように処理されたかを示すデータである。メールが無
事に送信された場合には、図のように「送信終了」と書
き込まれる。

【００２４】また、図３（Ｂ）に示すように、送信箱１
３ａには、メールＩＤ欄４１、受信者名欄４２、送信日
時欄４３、件名欄４４が設けられている。この送信箱１
３ａのデータは、クライアント１３のモニタ上で、ユー
ザＵ１が確認できる。

【００２５】図４はメール送信直後の受信側のクライア
ント用の受信履歴テーブルの一例を示す図であり、
（Ａ）はユーザＵ２の受信履歴テーブル２２ｂのデータ
を示す図、（Ｂ）はもう一方のユーザＵ３の受信履歴テ
ーブル２２ｃのデータを示す図である。両図に示すよう
に、それぞれの受信履歴テーブルには、メールＩＤ欄５
１，６１、送信者名欄５２，６２、メール状態欄５３，
６３、修正前のメールＩＤ欄５４，６４、送信日時欄５
５，６５、件名欄５６，６６が設けられている。ここ
で、メール状態とは、ユーザＵ１から送信されたメール
がユーザＵ２，Ｕ３に対してどのように処理されたかを
示すデータである。受信者側のメール送信直後のメール
状態欄５３，６３には、ともに「未開封」と書き込まれ
る。その後、メールがユーザによって開封されると、そ
のユーザのメール状態欄に「開封済み」と書き込まれ
る。

【００２６】このようにメールの送信が完了した後で、
間違いに気づくなどによりそのメールをキャンセルした
い場合、ユーザＵ１は、サーバ１１にキャンセル要求を
する。

【００２７】次に、ユーザＵ１からキャンセル要求がな
された場合の処理について説明する。図５はキャンセル
要求後の送信側のクライアント用の送信履歴テーブル２
１ａの一例を示す図である。ここでは、受信側のユーザ
Ｕ２でメールが未開封であり、ユーザＵ３で開封済みの
状態の場合を例にする。この状態でユーザＵ１側からキ
ャンセル要求がなされると、送信履歴テーブル２１ａの
各メール状態欄３３の内容は、ユーザＵ２については
「キャンセル済み」、ユーザＵ３については「キャンセ
ル要求」とされる。この送信履歴テーブル２１ａの内容
の変化に応じて、受信側のクライアント用の受信履歴テ
ーブル２２ｂ，２２ｃの内容も書き換えられる。

【００２８】図６はキャンセル要求後の受信側のクライ
アント用の受信履歴テーブルの一例を示す図であり、
（Ａ）はユーザＵ２の受信履歴テーブル２２ｂのデータ
を示す図、（Ｂ）はもう一方のユーザＵ３の受信履歴テ
ーブル２２ｃのデータを示す図である。まず図６（Ａ）
に示すように、ユーザＵ２の受信履歴テーブル２２ｂで
は、そのメール状態欄５３は「キャンセル済み」とな
る。また、これと同時に、メールスプールのユーザＵ２
用の領域２３ｂからメールが削除される。

【００２９】一方、図６（Ｂ）に示すように、ユーザＵ
３の受信履歴テーブル２２ｃでは、そのメール状態欄６
３は「キャンセル要求」となる。この場合、メールスプ
ールのユーザＵ３用の領域２３ｃのメールは、残された
ままである。

【００３０】図７はキャンセル要求後の受信側のクライ
アント用の受信箱の一例を示す図であり、（Ａ）はユー
ザＵ２の受信箱１４ｂのデータを示す図、（Ｂ）はもう
一方のユーザＵ３の受信箱１５ｂのデータを示す図であ
る。まず、図７（Ａ）に示すように、ユーザＵ２の受信
箱１４ｂには、メールＩＤ欄７１、メール状態欄７２、
送信者欄７３、送信日時欄７４、件名欄７５、修正前の
メールＩＤ欄７６が設けられている。受信箱１４ｂにお
いて、メール状態が「キャンセル済み」であるデータの
欄は空白にされ、モニタで画面表示されない。したがっ
て、ユーザＵ２には、メールが送られたことが知らされ
ない。

【００３１】一方、図７（Ｂ）に示すように、ユーザＵ
３の受信箱１５ｂには、メールＩＤ欄８１、メール状態
欄８２、送信者欄８３、送信日時欄８４、件名欄８５、
修正前のメールＩＤ欄８６が設けられている。この時点
では、修正後のメールが送り直されていないので、メー
ルＩＤ欄８１は、キャンセル要求されたメールのＩＤが
書き込まれている。また、当然、修正前のメールＩＤ欄
８６は空白となっている。この受信箱１５ｂのデータ
は、クライアント１５のモニタ上で、ユーザＵ３が確認
できる。

【００３２】このように、メールのキャンセル要求をす
るユーザＵ１は、必要に応じて、修正したメールを送り
直す。キャンセル要求には、メールの送り直し情報が付
加される。送り直し情報には、メールの送り直しの有無
の指定や、メール送信に必要な内容（ファイルのパス、
件名、コメントなど）がある。メールの送り直しが無い
場合には、メール送信に必要な内容は送り直し情報には
含まれない。一方、メールの送り直しの指定がある場
合、サーバ１１側は、送り直しメールの受け取り準備を
する。

【００３３】図８はメール送り直し後の送信側のクライ
アント用の送信履歴テーブル２１ａの一例を示す図であ
り、（Ａ）は送信履歴テーブル内のデータを示す図、
（Ｂ）はクライアントの送信箱１３ａ内のデータを示す
図である。まず、図８（Ａ）に示すように、送信履歴テ
ーブル２１ａでは、キャンセル前のメール（メールＩＤ
「server1.1 」）の状態と、キャンセル後の送り直した
メールの状態の両方が格納されている。送り直したメー
ルは、送り直したことが分かるような新たなメールＩＤ
「server1.2 」が付されている。送り直したメールのメ
ール状態は、各ユーザＵ２，Ｕ３ともに「送信終了」と
なる。

【００３４】一方、送信箱１３ａでは、図８（Ｂ）に示
すように、キャンセル前のメールおよび送り直したメー
ルの両方の送信データが格納されている。図９はメール
送り直し後の受信側のクライアント用の受信履歴テーブ
ルの一例を示す図であり、（Ａ）はユーザＵ２の受信履
歴テーブル２２ｂのデータを示す図、（Ｂ）はもう一方
のユーザＵ３の受信履歴テーブル２２ｃのデータを示す
図である。まず、図９（Ａ）に示すように、メールを未
開封のユーザＵ２では、最初に送られたメールのデータ
に加えて、送り直されたメールのデータが追加される。
このとき、送り直されたメールのメール状態は、「未開
封」とされる。

【００３５】また、図９（Ｂ）に示すように、ユーザＵ
３についても同様に、最初に送られたメールのデータに
加えて、送り直されたメールのデータが追加される。こ
のとき、送り直されたメールのメール状態は、「未開
封」とされる。

【００３６】図１０はメール送り直し後の受信側のクラ
イアント用の受信箱の一例を示す図であり、（Ａ）はユ
ーザＵ２の受信箱１４ｂのデータを示す図、（Ｂ）はも
う一方のユーザＵ３の受信箱１５ｂのデータを示す図で
ある。図１０（Ａ）に示すように、ユーザＵ２の受信箱
１４ｂでは、送り直されたメールのデータのみが格納さ
れ、モニタで表示される。したがって、ユーザＵ２は、
送り直されたメールについてのみ参照可能となる。

【００３７】一方、ユーザＵ３の受信箱１５ｂでは、図
１０（Ｂ）に示すように、最初に送られたメールのデー
タ、送り直されたメールのデータがともに格納され、こ
れがモニタで表示される。これにより、ユーザＵ３は、
すでに読んだメールが、修正されて送り直されたことを
知ることができる。また、修正前のメールＩＤ欄８６に
は、キャンセル前のメールＩＤ「server1.1 」が記録さ
れる。

【００３８】次に、図２に戻り、クライアント１３のユ
ーザＵ１が、他のサーバ１２の管理下のクライアント１
６，１７のユーザＵ４，Ｕ５にメールを送る場合の処理
について説明する。

【００３９】ユーザＵ１がユーザＵ４，Ｕ５にメールを
送信すると、サーバ１１側では、前述したように、その
メールアドレスの内容から、受信者が別のサーバ１２の
管理下にあることを判断する。そして、そのメールおよ
び関連するデータをサーバ１２に送信する。これを受け
たサーバ１２では、サーバ１２内の各ユーザに対応した
受信履歴テーブルに各種データを書き込み、メールを送
信する。

【００４０】その後、ユーザＵ１がキャンセル要求を送
ると、サーバ１１は、サーバ１２に対して送信者に関す
るデータとともにキャンセル要求を送る。また、これと
同時に、サーバ１１は、サーバ１２から受信者であるユ
ーザＵ４，Ｕ５のメール状態を取得する。

【００４１】以後、送り直しメールの送信などの処理に
ついては、図８〜図１０で説明した処理とほぼ同じなの
で、ここでは説明を省略する。図１１は本形態の電子メ
ールシステムにおけるキャンセル要求後のサーバ側の処
理手順を示すフローチャートである。 〔Ｓ１〕送信者からメールのキャンセルの要求がなされ
たか否かを判断し、なされればステップＳ２に進み、な
されなければステップＳ１を繰り返す。 〔Ｓ２〕送られたキャンセル要求が別サーバからのもの
であるか否かを判断し、別サーバからのものであればス
テップＳ６に進み、自サーバのクライアントからのもの
であればステップＳ３に進む。 〔Ｓ３〕送信者の送信履歴テーブルから、関連するメー
ルのメール状態などの必要なデータを取得する。 〔Ｓ４〕取得した送信者のメール状態が、「送信終了」
となっているか否かを判断し、なっていればステップＳ
５に進み、なっていなければ本フローチャートを終了す
る。 〔Ｓ５〕受信者が、別のサーバの管理下のものであるか
否かを判断し、そうであればステップＳ８に進む、そう
でなければステップＳ６に進む。 〔Ｓ６〕受信者の受信履歴テーブルから、関連するメー
ルのメール状態などの必要なデータを取得する。 〔Ｓ７〕自サーバの管理下の受信者に対して、そのメー
ル状態に応じた受信履歴の更新、およびメールの送り直
し処理を行う。 〔Ｓ８〕受信者のいるサーバに対してキャンセル要求を
行う。このとき、キャンセル要求とともに、送信者名、
メールＩＤ、受信者名、サーバ名、サーバからのキャン
セル要求であることを示すフラグなども送信する。ま
た、この応答として、相手のサーバから、受信者のメー
ル状態を取得する。 〔Ｓ９〕別のサーバの管理下の受信者に対して、そのメ
ール状態に応じた送信履歴の更新、およびメールの送り
直し処理を行う。

【００４２】図１２は図１１のステップＳ７の具体的な
処理手順を示すフローチャートである。 〔Ｓ１１〕対象の受信者の受信履歴テーブルの関連する
メールのメール状態が「未開封」であるか否かを判断
し、「未開封」であればステップＳ１２に進み、そうで
なければステップ１７に進む。 〔Ｓ１２〕送られたキャンセル要求が別サーバからのも
のであるか否かを判断し、別サーバからのものであれば
ステップＳ１３に進み、自サーバのクライアントからの
ものであればステップＳ１４に進む。 〔Ｓ１３〕別サーバに対して、対象の受信者のメール状
態が「未開封」である旨の応答を行う。 〔Ｓ１４〕キャンセル要求した送信者の送信履歴テーブ
ルの関連するメール状態を「キャンセル済み」にする。 〔Ｓ１５〕未開封である受信者の受信履歴データの関連
するメール状態を「キャンセル済み」にする。 〔Ｓ１６〕未開封である受信者の該当するメールを削除
する。 〔Ｓ１７〕対象の受信者の受信履歴テーブルの関連する
メール状態が「開封済み」であるか否かを判断し、「開
封済み」であればステップＳ１８に進み、そうでなけれ
ば他の状態と判断して本フローチャートを終了する。 〔Ｓ１８〕送られたキャンセル要求が別サーバからのも
のであるか否かを判断し、別サーバからのものであれば
ステップＳ１９に進み、自サーバのクライアントからの
ものであればステップＳ２０に進む。 〔Ｓ１９〕別サーバに対して、対象の受信者のメール状
態が「開封済み」である旨の応答を行う。 〔Ｓ２０〕キャンセル要求した送信者の送信履歴テーブ
ルの関連するメール状態を「キャンセル要求」にする。 〔Ｓ２１〕開封済みである受信者の受信履歴テーブルの
関連するメール状態を「キャンセル要求」にする。 〔Ｓ２２〕送られたキャンセル要求が別サーバからのも
のであるか否かを判断し、別サーバからのものであれば
本フローチャートを終了し、自サーバのクライアントか
らのものであればステップＳ２３に進む。 〔Ｓ２３〕送信者から送り直しのメールが送られたか否
かを判断し、送られればステップＳ２４に進み、送られ
なければ本フローチャートを終了する。 〔Ｓ２４〕修正された送り直しのメールを受信者に送信
する。

【００４３】図１３は図１１のステップＳ９の具体的な
処理手順を示すフローチャートである。 〔Ｓ３１〕対象の受信者の受信履歴テーブルの関連する
メールのメール状態が「未開封」であるか否かを判断
し、「未開封」であればステップＳ３２に進み、そうで
なければステップ３５に進む。 〔Ｓ３２〕キャンセル要求した送信者の送信履歴テーブ
ルの関連するメール状態を「キャンセル済み」にする。 〔Ｓ３３〕送信者から送り直しのメールが送られたか否
かを判断し、送られればステップＳ３４に進み、送られ
なければ本フローチャートを終了する。 〔Ｓ３４〕修正された送り直しのメールを受信者に送信
する。 〔Ｓ３５〕対象の受信者の受信履歴テーブルの関連する
メール状態が「開封済み」であるか否かを判断し、「開
封済み」であればステップＳ３６に進み、そうでなれ
ば、他の状態と判断して本フローチャートを終了する。 〔Ｓ３６〕キャンセル要求した送信者の送信履歴テーブ
ルの関連するメール状態を「キャンセル要求」にする。 〔Ｓ３７〕送信者から送り直しのメールが送られたか否
かを判断し、送られればステップＳ３８に進み、送られ
なければ本フローチャートを終了する。 〔Ｓ３８〕修正された送り直しのメールを受信者に送信
する。

【００４４】このように、本形態では、メールの送信
後、キャンセル要求されたメールについて、未開封の受
信者に対しては、すでに送られているメールを削除する
ようにしたので、受信者側では、自分に不要なメールを
読まされることがない。

【００４５】また、送信側でも、キャンセル要求のみを
送信すればよく、新たに訂正のメールを送信する必要が
ない。さらに、本形態では、受信側で未開封の場合に
は、キャンセル要求後、送信者が修正して送り直したメ
ールを新しいメールとして提供するようにしたので、受
信者は、通常のメールと同様の処理を行うことができ
る。

【００４６】また、キャンセル要求後、送信者が修正し
て送り直す場合、受信側がメールをすでに開封済みの場
合には、送り直しのメールである旨を示すデータととも
に送り直しのメールを提供するようにしたので、受信者
側では、すでに読んだメールがキャンセルされたことを
知ることができるとともに、改めて修正後のメールを読
むことができる。

【００４７】

【発明の効果】以上説明したように本発明では、送信側
のクライアントからキャンセル要求がなされ、かつ、キ
ャンセル要求されたメールを受信側のクライアントが未
開封の場合、メール格納手段内の対応するメールを削除
するようにしたので、受信者側では、自分に不要なメー
ルを読まないで済む。

【００４８】また、送信側でも、キャンセル要求のみを
送信すればよく、新たに訂正のメールを送信する必要が
ない。

【図面の簡単な説明】

【図１】本発明の電子メールシステムの機能の概念を示
す図である。

【図２】本形態の電子メールシステムの機能の構成を示
すブロック図である。

【図３】メール送信直後の送信側のクライアント用の送
信履歴テーブルの一例を示す図であり、（Ａ）は送信履
歴テーブル内のデータを示す図、（Ｂ）はクライアント
の送信箱内のデータを示す図である。

【図４】メール送信直後の受信側のクライアント用の受
信履歴テーブルの一例を示す図であり、（Ａ）はユーザ
の受信履歴テーブルのデータを示す図、（Ｂ）はもう一
方のユーザの受信履歴テーブルのデータを示す図であ
る。

【図５】キャンセル要求後の送信側のクライアント用の
送信履歴テーブルの一例を示す図である。

【図６】キャンセル要求後の受信側のクライアント用の
受信履歴テーブルの一例を示す図であり、（Ａ）はユー
ザの受信履歴テーブルのデータを示す図、（Ｂ）はもう
一方のユーザの受信履歴テーブルのデータを示す図であ
る。

【図７】キャンセル要求後の受信側のクライアント用の
受信箱の一例を示す図であり、（Ａ）はユーザの受信箱
のデータを示す図、（Ｂ）はもう一方のユーザの受信箱
のデータを示す図である。

【図８】メール送り直し後の送信側のクライアント用の
送信履歴テーブルの一例を示す図であり、（Ａ）は送信
履歴テーブル内のデータを示す図、（Ｂ）はクライアン
トの送信箱内のデータを示す図である。

【図９】メール送り直し後の受信側のクライアント用の
受信履歴テーブルの一例を示す図であり、（Ａ）はユー
ザの受信履歴テーブルのデータを示す図、（Ｂ）はもう
一方のユーザの受信履歴テーブルのデータを示す図であ
る。

【図１０】メール送り直し後の受信側のクライアント用
の受信箱の一例を示す図であり、（Ａ）はユーザの受信
箱のデータを示す図、（Ｂ）はもう一方のユーザの受信
箱のデータを示す図である。

【図１１】本形態の電子メールシステムにおけるキャン
セル要求後のサーバ側の処理手順を示すフローチャート
である。

【図１２】図１１のステップＳ７の具体的な処理手順を
示すフローチャートである。

【図１３】図１１のステップＳ９の具体的な処理手順を
示すフローチャートである。

【符号の説明】

１ サーバ １ａ メール処理手段 １ｂ メール格納手段 １ｃ キャンセル処理手段 ２ 送信側クライアント ３ 受信側クライアント １０ 電子メールシステム １１，１２ サーバ １３〜１７ クライアント １３ａ，１４ａ，１５ａ，１６ａ，１７ａ 送信箱 １３ｂ，１４ｂ，１５ｂ，１６ｂ，１７ｂ 受信箱 ２１ 送信履歴テーブル領域 ２１ａ，２１ｂ，２１ｃ 送信履歴テーブル ２２ 受信履歴テーブル領域 ２２ａ，２２ｂ，２２ｃ 受信履歴テーブル ２３ メールスプール ２４ リクエスト処理部 ２５ 送受信履歴管理部 ２６ メール管理部

Claims (6)

【特許請求の範囲】
1. 【請求項１】 サーバを介してクライアント間でメール
   のやり取りを行う電子メールシステムにおいて、 クライアントから送信されたメールをメール記憶部に格
   納する一方、受信側のクライアントの要求に応じて前記
   メール記憶部内の対応するメールを前記受信側のクライ
   アントに提供するメール処理手段と、 前記送信側のクライアントから前記送信したメールに対
   するキャンセル要求がなされ、かつ、前記キャンセル要
   求されたメールを受信側のクライアントが未開封の場
   合、前記メール格納手段内の対応するメールを削除する
   キャンセル処理手段と、 を有することを特徴とする電子メールシステム。
2. 【請求項２】 前記キャンセル処理手段は、前記送信側
   のクライアントからキャンセル要求がなされ、かつ、前
   記キャンセル要求されたメールを受信側のクライアント
   が開封済みの場合、前記受信側のクライアントに前記メ
   ールがキャンセルされた旨を通知するように構成されて
   いることを特徴とする請求項１記載の電子メールシステ
   ム。
3. 【請求項３】 前記キャンセル処理手段は、前記キャン
   セルされたメールの内容が変更されて送り直され、か
   つ、前記受信側のクライアントが前記メールを未開封の
   場合には、新しいメールとして提供し、一方、前記受信
   側のクライアントが前記メールをすでに開封済みの場合
   には、前記送り直しのメールである旨を示すデータとと
   もに前記送り直しのメールを提供するように構成されて
   いることを特徴とする請求項１記載の電子メールシステ
   ム。
4. 【請求項４】 前記メールの送信履歴データを前記サー
   バ側から前記送信側のクライアントに供給する送信履歴
   データ供給手段を有することを特徴とする請求項１記載
   の電子メールシステム。
5. 【請求項５】 前記メールの受信履歴データを前記サー
   バ側から前記受信側のクライアントに供給する受信履歴
   データ供給手段を有することを特徴とする請求項１記載
   の電子メールシステム。
6. 【請求項６】 サーバを介してクライアント間でメール
   のやり取りを行う電子メールシステムプログラムを記録
   した記録媒体において、 クライアントから送信されたメールをメール記憶部に格
   納する一方、受信側のクライアントの要求に応じて前記
   メール記憶部内の対応するメールを前記受信側のクライ
   アントに提供するメール処理手段、 前記送信側のクライアントからキャンセル要求がなさ
   れ、かつ、前記キャンセル要求されたメールを受信側の
   クライアントが未開封の場合、前記メール格納手段内の
   対応するメールを削除するキャンセル処理手段、 としてサーバを機能させるための電子メールシステムプ
   ログラムを記録した記録媒体。