(57)【特許請求の範囲】
【請求項１】
分散ホストを相互接続して構成されるネットワークにおける前記分散ホストとして構成され、メールの送受信を行なう第１メールサービス手段及び同じくメールの送受信を行なう複数の第２メールサービス手段と、
前記ネットワークに接続され、前記複数の第２メールサービス手段それぞれに対応して設けられ、前記第２メールサービス手段からメールを読み出すユーザインターフェース手段とを備えた電子メールシステムにおいて、
前記第１メールサービス手段は、
メールの送受信を行なう第１のメール配送手段と、メール受信側からの既読通知を第１メールサービス手段へ通知させる制御用の付加情報をメールメッセージに付加するヘッダ付加手段と、特定のメッセージが受取り人に読まれたことを示す既読情報を記憶する第１の記憶手段とを備え、
前記第２メールサービス手段は、
メールの送受信を行なう第２のメール配送手段と、このメール配送手段によって受信されたメールを保持する第２の記憶手段と、前記受信メールが前記ユーザインターフェース手段によって読み出される際に、前記第１メールサービス手段により付加されたヘッダ情報に従って、前記第１メールサービス手段へ既読通知を発信する既読通知手段とを備えることを特徴とする電子メールシステム。
【請求項２】
前記第１メールサービス手段又は前記第２メールサービス手段の少なくともいずれか一方は、前記第１メールサービス手段によって付加されたヘッダ情報を用いて特定のメールに対する返信のメッセージを認識し、返信通知を発信する返信通知手段を備え、
さらに、前記第１メールサービス手段は、この返信通知情報を前記第１の記憶手段に保持しておくよう構成されていることを特徴とする請求項１に記載の電子メールシステム。
【請求項３】
前記ユーザインターフェース手段は、
前記第２メールサービス手段からメッセージを読み出す際に前記第１メールサービス手段によって付加されたヘッダ情報に従って前記既読通知情報を発信する既読通知手段、及び、前記読み出したメールに対する返信の際に前記第１メールサービス手段によって付加された情報に従って前記返信通知を発信する返信通知手段の少なくともいずれか一方を備えることを特徴とする請求項１又は２に記載の電子メールシステム。
【請求項４】
前記第１メールサービス手段は、
前記受信したメール中のコマンドを認識し、そのコマンドに従って前記第１の記憶手段中の既読情報及び返信情報をメール差し出し人に返信するコマンド実行手段を備えることを特徴とする請求項１〜３のいずれかに記載の電子メールシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散ホストを相互接続して構成されるネットワーク技術に関し、詳細には、ネットワーク上における電子メールの配送システムに関する。
【０００２】
【従来の技術】
従来、電子メールによるユーザサポート窓口を設ける場合、メールアドレスとして代表アドレスを設け、このアドレスに来たメールを複数の担当者に転送する形で運用することが一般的である。そして、分散ホストを相互接続して構成される広域ネットワーク上のメールシステムでは、各担当者のメールボックスが複数のメールサーバ上にある。
【０００３】
【発明が解決しようとする課題】
しかしながら、複数の担当者にメールを転送した場合、誰がそのメールを読んだか、あるいは誰が返事を出したか等を管理する必要がある場合、一台のホストで集中してメールを管理するシステムではメールシステム自体にその機能を組み込むことにより対応可能であるが、分散ホストによる広域ネットワークにおいては、複数のメールサーバにメールが送られるため、この情報を得ることが困難であった。
【０００４】
本発明は、上述した問題点を解決するためになされたものであり、窓口アドレスに対して送られたメールを複数の担当者に転送した後、どの担当者がそのメールを読んだか、さらにはどの担当者がそのメールに対して返事を出したかといった点を管理可能な電子メールシステムを提供することを目的としている。
【０００５】
【課題を解決するための手段】
この目的を達成するためになされた本発明の電子メールシステムは、図１に例示するように、基本構成として、分散ホストを相互接続して構成されるネットワーク上の分散ホストの一つとしてメールの送受信を行なう第１メールサービス手段及び同じくメールの送受信を行なう複数の第２メールサービス手段と、
前記ネットワークに接続され、前記複数の第２メールサービス手段それぞれに対応して設けられ、前記第２メールサービス手段からメールを読み出すユーザインターフェース手段との３つの手段を備えており、２つのメールサービス手段が、さらに以下のように構成されている。
【０００６】
すなわち、前記第１メールサービス手段は、メールの送受信を行なう第１のメール配送手段と、メール受信側からの既読通知を第１メールサービス手段へ通知させる制御用の制御用の付加情報をメールメッセージに付加するヘッダ付加手段と、特定のメッセージが受取り人に読まれたことを示す既読情報を記憶する第１の記憶手段とを備えている。
【０００７】
また、前記第２メールサービス手段は、メールの送受信を行なう第２のメール配送手段と、このメール配送手段によって受信されたメールを保持する第２の記憶手段と、前記受信メールが前記ユーザインターフェース手段によって読み出される際に、前記第１メールサービス手段により付加されたヘッダ情報に従って、前記第１メールサービス手段へ既読通知を発信する既読通知手段とを備えている。
【０００８】
本発明の電子メールシステムによれば、第１メールサービス手段により付加されたヘッダに従って、第２メールサービス手段が既読情報を第１メールサービス手段に送信することにより、第１メールサービス手段上で、メールの既読／未読の管理が容易に行なえる。そのため、窓口アドレスに対して送られたメールを複数の担当者に転送した後、どの担当者がそのメールを読んだかを管理することが容易にできる。
【０００９】
また、請求項２に示すように、上述の構成に加え、第１メールサービス手段又は第２メールサービス手段の少なくともいずれか一方は、第１メールサービス手段によって付加されたヘッダ情報を用いて特定のメールに対する返信のメッセージを認識し、返信通知を発信する返信通知手段を備え、さらに、第１メールサービス手段がこの返信通知情報を第１の記憶手段に保持しておくよう構成することも考えられる。
【００１０】
この場合には、第１メールサービス手段により付加されたヘッダに従って、第１メールサービス手段又は第２メールサービス手段が特定のメールに対する返信のメッセージを認識することが可能であり、このヘッダの内容に従って返信通知を第１メールサービス手段に送信することによって、第１メールサービス手段上で特定のメールに対する返信がなされたか否かが容易に管理できる。そのため、上述の複数担当者に転送した後でどの担当者がそのメールを読んだかに加えて、さらに、どの担当者がそのメールに対して返事を出したかを管理することが容易にできる。なお、返信通知のみの管理は現実的でない。それは、メールを読んだ結果として返信を実行するからである。
【００１１】
また、請求項３に示すように、ユーザインターフェース手段が、第２メールサービス手段からメッセージを読み出す際に、第１メールサービス手段によって付加されたヘッダ情報に従って既読通知情報を発信する既読通知手段と、読み出したメールに対する返信の際に、第１メールサービス手段によって付加された情報に従って返信通知を発信する返信通知手段との２つの手段の内の少なくともいずれか一方を備えるようにしてもよい。
【００１２】
この場合には、第１メールサービス手段により付加されたヘッダに従って、ユーザインターフェース手段においても既読情報及び返信情報の少なくとも一方を第１メールサービス手段に通知することが可能であり、この情報を用いることで第１メールサービス手段では、さらにきめ細かくメッセージが管理することができる。
【００１３】
そしてまた、請求項４に示すように、第１メールサービス手段が、受信したメール中のコマンドを認識し、そのコマンドに従って第１の記憶手段中の既読情報及び返信情報をメール差し出し人に返信するコマンド実行手段を備えるようにしてもよい。この場合には、第１メールサービス手段にメールによるコマンド実行手段が用意されているので、問い合わせのメールを第１メールサービス手段に送れば、容易に既読情報及び返信情報を入手できることとなる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。
本実施形態の電子メールシステムは、図３に示す分散ネットワーク上のメールシステムとして実現される。このシステムは、ネットワーク３１に接続された複数のサーバ２３，３２，３３，３４，３５と、端末３６から構成されている。なお、図３では複数のサーバとして、１台のメーリングリストサーバ２３と１台の中継サーバ（Ｄ）３３と、３台のメールサーバ（Ａ，Ｂ，Ｃ）３２，３４，３５とが示されている。以下の説明では、これらをまとめて指す場合には単に「サーバ」と呼び、区別して指す場合には個別名（メールサーバＡ等）で示すこととする。
【００１５】
メールメッセージは、各サーバ２３，３２，３３，３４，３５間でやり取りされ、各利用者（メンバＡ，Ｂ，Ｃ）３７，３８，３９は、端末３６を介してアクセスすることでメールの送受信を行なう。
本発明の基礎となるのは、このシステム上で動作するメーリングリストであるので、以下の説明に先だって、このメーリングリストについて説明する。
【００１６】
メーリングリストとは、図４の概念図に示すように、複数のユーザ４６，４７，４８（メーリングリストのメンバと呼び、ここではそれぞれＡ，Ｂ，Ｃで示す。なお、図４では概念説明のために用いたものであり、図３のメンバとの対応は取っていない。）に対して代表となるメールアドレス（以下、代表アドレスと呼ぶ。）４１を用意し、その代表アドレス４１に来たメールを、登録されているメンバ（Ａ，Ｂ，Ｃ）４６，４７，４８に転送するしくみである。
【００１７】
例えば、［ｓｕｐｐｏｒｔ＠ｄｅｆ．ｈｉｊ］という代表アドレス４１を持つメーリングリストに、メンバとしてＡ〜Ｃの３人のメールアドレスが登録されている場合には、この代表アドレス［ｓｕｐｐｏｒｔ＠ｄｅｆ．ｈｉｊ］にメールが来ると、配送システム４２はメンバリスト４４から各メンバ（Ａ〜Ｃ）のメールアドレスを取り出し、そのリスト中の全メンバにメールを配送する。
【００１８】
メーリングリストの基本機能は、このように、複数のユーザに対する代表アドレスを提供するということであるが、その他に、以下の（１）〜（３）の機能がある。
（１）アーカイブ機能…メーリングリストに送られて来たメールを、メッセージ保存部４３にファイルとして保存する。
【００１９】
（２）ヘッダの書き換え…メーリングリストに送られて来たメールに通し番号を振ったり、返事を書く場合の返事のあて先として、元の発信人個人のアドレスではなく、メーリングリストのアドレスになるようなヘッダを付加する。
（３）メールによるコマンドの実行…メーリングリストにメールでコマンドを送ると、コマンド実行部４５はコマンドに従って、アーカイブされたメールをメッセージ保存部４３から取り出したり、メンバリスト４４を変更することによりメンバの登録、削除を行なう。
【００２０】
さて、図３に示す本実施形態の分散ネットワークにおけるメーリングリストでは、メーリングリストのプログラムが動作しているメーリングリストサーバ２３と、各担当者のメールの受け取り先となっているメールサーバ（Ｂ，Ｃ）３４，３５は、異なるホストである。
【００２１】
そのため、メーリングリストをユーザサポート窓口に利用した場合、メーリングリストサーバ２３から各担当者のメールサーバ（Ｂ，Ｃ）３４，３５にメールは送れても、メールサーバ（Ｂ，Ｃ）３４，３５内部の情報は利用できない。そのため、どの担当者がメールを読んだか、また、どの担当者が返事を出したかはメーリングリストサーバ２３では管理できなかった。
【００２２】
本電子メールシステムの目的は、この様な場合に誰がメールを読んだか、そして返事を出したかを管理できるようにすることであり、その具体的な実現方法を以下に詳細に説明する。
本実施形態においては、図２の機能構成図に示すように、メーリングリストサーバ２３が、メーリングリストに送られて来たメール２１に対して必要なヘッダを付加した後に、そのメッセージ２５をメンバ２８にあててメールサーバ３４，３５に転送することと、メールを受信したメールサーバ３４，３５が、メーリングリストのメンバ２８がメールを読んだ時にメーリングリストサーバ２３によって付加されたヘッダを参照し、通知アドレス２７にメッセージが読まれたこと及び返事が送信されたことをメールメッセージとして送る点が特徴となっている。
【００２３】
従って、本実施形態においては、メーリングリストサーバ２３と、既読／返信情報を送信するメールサーバ３４，３５の二つが、主要な要素となっている。次に、この二つの要素の構成を示す。
まず、メーリングリストサーバ２３について説明する。
【００２４】
メーリングリストサーバ２３は本発明における「第１メールサービス手段」に相当し、周知のコンピュータを中心として構成され、主たる動作はそのコンピュータ上で動作するプログラムとして実現されている。その構成は、図５に示すように、「ヘッダ付加手段」や「返信通知手段」に相当するメッセージ管理部５３を処理機能の中心とし、ネットワークインターフェース５１から受信したメールを「第１のメール配送手段」に相当するメール配送部５２を経由して受け取り、ヘッダの付加５５などの処理を行った後、メーリングリストの各参加メンバに対してメッセージを送ることができるようにされている。各メールは、メール配送部５２によって各メンバに対応した送り先サーバが決定され、ネットワークインターフェス５１によって送信される。また、メッセージ管理部５３では、メンバの管理５６やヘッダの解析５７等も行なわれる。
【００２５】
各メンバ及びメッセージに関する情報は、「第１の記憶手段」に相当する記憶装置５４に保持されており、メッセージ管理部５３からの指示に従って、読み出し変更が行われる。また、記憶装置５４中には、メッセージの内容及びメッセージが各メンバによって読み出されたかを示す既読情報と、返事が出されたかを示す返信通知情報が記憶されている。
【００２６】
この記憶装置５４の記憶内容を図６に示す。受信したメッセージは、全てｍｅｓｓａｇｅｓディレクトリ６１中にファイル６２の形で記憶される。各メッセージは受信順の番号（０００１，０００２，……）が付けられ、その番号がファイル名となっている。また、メンバのアドレスを保持しているメンバリストは、各メンバのメールアドレスを列挙したｍｅｍｂｅｒｓファイル６３の形で保持されている。
【００２７】
本発明の特徴である既読情報や返信情報は、この記憶装置５４においてはｕｓｅｒｓディレクトリ６４内の、さらに各メンバ毎に作られたユーザディレクトリ６５中に保持される。このユーザディレクトリ６５中に、既読情報を示すｒｅａｄファイル６６と、ｒｅｐｌｙファイル６７を用意し、このファイルに既読及び返信を行なったメッセージの番号（０００１，０００２等）を記録する。
【００２８】
次に、メールサーバ３２，３４，３５について説明する。
なお、本実施形態においては、メールサーバ３２，３４，３５の内、メンバ（Ｂ，Ｃ）３８，３９に接続されているメールサーバ（Ｂ，Ｃ）３４，３５が本発明における「第２メールサービス手段」に相当する。
【００２９】
メールサーバ３２，３４，３５は、送られて来たメールメッセージをネットワークインターフェース７１を介して取得し、「第２のメール配送手段」に相当するメール配送部７２によって送信先を決定する。この送信先が当該メールサーバ３２，３４，３５上のユーザの場合は、そのメッセージを「第２の記憶手段」に相当する記憶装置７４中に保存し、後にユーザが端末３６（図３参照）から当該メールサーバ３２，３４，３５にアクセスして、そのメールを読む。
【００３０】
また、送信先が、他のメールサーバ３２，３４，３５である場合は、メール配送部７２によって再送信先が決定され、ネットワークインターフェース７１を介して他のメールサーバ３２，３４，３５に転送される。
また、「既読通知手段」や「返信通知手段」に相当するメッセージ管理部７３では、メッセージ中のヘッダを処理するためのヘッダ処理７５や、新たなメッセージを作成するためのメッセージ生成７６等も行われる。この電子メールシステムで扱うメッセージのフォーマットやメッセージの転送プロトコルとしては、インターネット等で既に利用されている周知のものを用いればよく、本案の特徴ではないので、ここでの説明を省略する。
【００３１】
さて、次に本実施形態の利用例の状況を説明する。図３に示す分散ネットワーク上のメールシステムにおいて、メーリングリストサーバ２３上でメーリングリストプログラムが動作しており、メーリングリスト名として、［ｓｕｐｐｏｒｔ＠ｄｅｆ．ｈｉｊ］というアドレスが割り当てられている。また、メンバとして、２つのメールサーバ（Ｂ，Ｃ）３４，３５上のユーザが登録されている。また、メールサーバ（Ａ）３２上には、メンバではないユーザ（Ａ）３７が接続されている。
【００３２】
さて、このシステムで、「ユーザ（Ａ）３７からメーリングリストにメールが出され、そのメールがメンバ（Ｂ，Ｃ）３８，３９に転送される。その後、メンバ（Ｃ）３９がメールを読み、ユーザ（Ａ）３７に返事を書く。その後、メンバ（Ｂ）３８がメールを読み、返事が出されたかどうかを確認するため、メーリングリストサーバ２３に問い合わせのメールを出し、その返事を受け取る」という状況を想定して以下の説明を進める。
【００３３】
まず、ユーザ（Ａ）３７がメーリングリストに対してメールを送信する。この時には、メールサーバ（Ａ）３２を介してメーリングリストサーバ２３にメッセージが送られる。メーリングリストサーバ２３では、このメールのあて先が、メーリングリストあてであるので、そのメーリングリストを各メンバ（Ｂ，Ｃ）３８，３９に配送する。
【００３４】
このときのメーリングリストサーバ２３での処理手順を図９のフローチャートを参照して説明する。
最初のステップ８０１（以下ステップをＳで示す。）にてメーリングリストサーバ２３のメッセージ管理部５３がメールを受け取ると、メッセージに番号を付け（Ｓ８０２）、記憶装置５４中に保存する（Ｓ８０３）。メッセージは、この番号を名前とするファイルとして記憶される。
【００３５】
次に、メッセージ管理部５３は、送られて来たメッセージにヘッダを追加する（Ｓ８０４）。ヘッダには、メーリングリストの名前や、［Ｆｒｏｍ：］ヘッダなどの一般的なヘッダがあるが、本案の場合には、既読・返信の連絡先を示す［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］ヘッダを付加することが特徴となっている。このヘッダには、図８に示すように、メンバがメールを読んだり返事をした際に、そのことを通知する先のメールアドレス９１が入っている。
【００３６】
このアドレスとしては、当該メーリングリストのサーバで、メーリングリストのアドレス名とは異なる名前が用いられる。本実施形態では、例えば［ｓｕｐｐｏｒｔ−ｎｏｔｉｆｙ＠ｄｅｆ．ｈｉｊ］になる。
次に、メッセージ管理部５３は記憶装置５４からメンバリスト６３（図６参照）を取り出し（Ｓ８０５）、リスト中の全メンバに対して、前述のヘッダを追加したメッセージを送信する（Ｓ８０６，Ｓ８０７）。
【００３７】
メーリングリストサーバ２３から送信されたメールは、各メンバのサーバに送られる。メッセージが各メンバのサーバに届いた後、メンバ（Ｃ）３９がメールを読むためにメールサーバ（Ｃ）３５にアクセスすると、そのメールサーバ（Ｃ）３５では、図１０に示す処理を実行する。
【００３８】
端末３６からアクセス待ち（Ｓ１００１）の後、ユーザ名を特定し（Ｓ１００２）、ユーザあてメッセージがあった場合には（Ｓ１００３：ＹＥＳ）、そのユーザへのメッセージを取り出す（Ｓ１００４）。
そして、そのメッセージ中のヘッダをチェックして既読通知要求ヘッダ［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］があれば（Ｓ１００５：ＹＥＳ）、そのヘッダから通知先を取り出し（Ｓ１００６）、そのアドレスに対してメールが読まれたことを示す既読通知メールを送信する（Ｓ１００７）。また、同時に、このメールの［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダに入っているメッセージＩＤと、［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］のヘッダ対を保存しておく（Ｓ１００８）。これは、後述する返信通知のためである。
【００３９】
その後、端末３６側にメッセージを送信する（Ｓ１００９）。この処理をユーザあての全てのメッセージについて行なう（Ｓ１００３）。
なお、この既読通知のメールは、図８に示す［Ｓｕｂｊｅｃｔ：］ヘッダ９３に、「Ｒｅａｄ  メッセージ番号（←図８では０００６）  メンバのメールアドレス」が入っているだけで本文のないメールである。
【００４０】
このメールは、メーリングリストサーバ２３に転送される。メーリングリストサーバ２３内のメッセージ管理部５３（図５参照）はこのメールを受け取ると、既読情報を更新する。メッセージ管理部５３は、［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］ヘッダ９１を持つメッセージを受信したとき、該当するメンバのユーザディレクトリ６５中のｒｅａｄファイル６６（図６参照）にメッセージ番号を追加する。
【００４１】
さて、次にメンバ（Ｃ）３９が受信したメールに対して返事を出す場合の動作について説明する。既読通知については、メールサーバ３２，３４，３５側だけで処理が可能であるが、返信通知については、返信のメールがどのメールに対する返事であるかを直接知ることができない。そこで、本実施形態においては、次の３つの方法を用意し、適宜選択して使用する。
【００４２】
１つ目の方法は、端末３６上で動作するメールユーザインターフェースプログラム（以下、「メーラー」と呼ぶ。）に返信確認メールを出す機能を追加することで実現する。メーラーを用いて返事を出す際に、元のメールに［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］ヘッダが含まれていた場合、その内容を用いて、返信メールを出す時、同時に返信確認メールをメーリングリストサーバ２３に対して送ることで返信の確認ができる。
【００４３】
この方法では、メンバが使用する端末３６上のメーラー全てにこの機能を持たせることが必要となるが、返信先によらず、全ての返信メールをチェックすることが可能である。
２つ目の方法は、返信通知機能を端末３６ではなく、メールサーバ３２，３４，３５に組み込む方法である。この方法では、全ての端末３６に機能を追加する必要はなくなる。この第２の方法では、返信メールに一般的に含まれている［Ｒｅｆｅｒｅｎｃｅｓ：］ヘッダをメールサーバ３２，３４，３５側でチェックして返信メールであることを検出し、返信通知メールを出す。一般的に、メーラーが返信を行なう際には、元のメールの［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダの内容を［Ｒｅｆｅｒｅｎｃｅｓ：］ヘッダとして付加するので、これを利用して、返信通知の必要なメールであるかをチェックする。
【００４４】
この第２の方法の詳細を以下に示す。これまでにも述べたように、メンバ３８，３９がメールサーバ３４，３５からメールを読み出す際に、メールサーバ３４，３５側では、［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダと、［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］ヘッダの対をメールサーバ３４，３５内部の記憶装置７４（図７参照）に記憶しておく。
【００４５】
メンバ（Ｂ，Ｃ）３８，３９が、このメールに対して返信し、その返信メールがメールサーバ３４，３５に送られると、メールサーバ３４，３５は、図１１に示す返信通知処理を実行する。
まずメールメッセージを受信し（Ｓ１１０１）、その受信したメールメッセージに対して、その返信メールの［Ｒｅｆｅｒｅｎｃｅｓ：］ヘッダをチェックする（Ｓ１１０２）。ヘッダが存在すれば（Ｓ１１０３：ＹＥＳ）、メールサーバ３４，３５内に保存されているメッセージから上述のヘッダ対を取り出し（Ｓ１１０４）、［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダと、返信メールの［Ｒｅｆｅｒｅｎｃｅｓ：］ヘッダとを比較する（Ｓ１１０５）。
【００４６】
そして、一致するものがあった場合は（Ｓ１１０６：ＹＥＳ）、そのメールに対する返信であると判断して、［Ｍｅｓｓａｇｅ−ＩＤ：］と対で保持している［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］の内容を取り出し（Ｓ１１０９）、そのアドレスに返信通知メールを送信する（Ｓ１１１０）。その後、通常通りメールメッセージを返信先に送信する（Ｓ１１０８）。なお、ヘッダ対が一致していない場合には（Ｓ１１０６：ＮＯ）、全てのヘッダ対についての比較が終了するまで実行し（Ｓ１１０７）、それでも一致するものがない場合は（Ｓ１１０７：ＹＥＳ）、Ｓ１１０８へ移行する。
【００４７】
一般に、ユーザ３８，３９がメールを出す場合は、メールサーバ３４，３５を経由するので、この第２の方法でも、返信のあて先によらず返信チェックが可能である。
また、この方式は、各メンバ３８，３９に対応するメールサーバ３４，３５上だけでなく、メーリングリストサーバ２３でも実現可能である。従って、３つ目の方法としては、メーリングリストサーバ２３上で上記の方法を用いることが考えられる。メーリングリストでは、メーリングリストから各メンバに対して送られたメールに対する返信もメーリングリストにすることが一般的である。これは、メーリングリストに来たメールは全メンバに転送されるので、それに対する返事もメーリングリストのメンバ全てに送ることが自然なためである。
【００４８】
そのため、メーリングリストサーバ２３では、メンバに転送するメッセージの［Ｒｅｐｌｙ−Ｔｏ：］ヘッダに、メーリングリスト自身のアドレスを入れている。そのため、メーリングリストからのメッセージに対して返信を行なった場合、その返信メールは、差し出し人あてではなく、メーリングリストあてとなる。そして、メーリングリストのメンバ全員が返事を受け取れるようになっている。従って、メーリングリストあてのメールに対する返事は、メーリングリストサーバ２３を経由するので、メーリングリストサーバで上記の［Ｒｅｆｅｒｅｎｃｅｓ：］ヘッダをチェックすることにより、返信通知が行なえる。この方法では、メーリングリストあてでないメールについては返信はチェックできないが、全ての処理をメーリングリストサーバで行なえるので、実現が容易である。
【００４９】
ところで、これまでの手順によって、メーリングリストサーバ２３上にはメールが読まれたかどうかを示す既読情報と返信されたかどうかを示す返信通知情報が保持されている。そのため、次に、メンバＢが確認のためこの情報を取り出す手順について説明する。
【００５０】
メーリングリストに対して、通常のメールを送るのではなく、特別な動作をさせるためには、コマンドメールと呼ばれるメールをメーリングリストに対して送ることにより実現されている。既読／返信の確認についても、このコマンドメールを用いる。コマンド・メールにはいくつかの方式があるが、ここでは、メールのヘッダにコマンドを記入する方法を用いる。
【００５１】
このときに送られるコマンドは、返信通知のチェックであることを示す文字列と、返信通知情報のチェック対象となるメッセージの番号を［Ｘ−ＭＬ−Ｃｏｍｍａｎｄ：］ヘッダ９２（図８参照）に入れたものである。例えば、「Ｘ−ＭＬ−Ｃｏｍｍａｎｄ：  ｃｈｅｃｋ  ｒｅｐｌｙ  ２０」というメールをメーリングリストに送信すると、メーリングリストプログラムがコマンドを実行し、その結果をコマンドメールの発信者に返送する。
【００５２】
この手順を図１２のフローチャートを参照して説明する。
メーリングリストサーバ２３がコマンドメールを受信すると、その［Ｘ−ＭＬ−ｃｏｍｍａｎｄ：］ヘッダ９２（図８参照）からコマンドを取り出す（Ｓ１２０１）。次にこのコマンドがｃｈｅｃｋコマンドであるかどうかを調べる（Ｓ１２０２）。ここでは、ｃｈｅｃｋコマンド以外の場合は、そのコマンドに対応した適宜しかるべき処理を行なう（Ｓ１２１１）ものとして、その詳しい内容の説明は省略する。
【００５３】
一方、ｃｈｅｃｋコマンドの場合は（Ｓ１２０２：ＹＥＳ）、そのコマンドが既読通知である「ｒｅａｄ」であるか（Ｓ１２０３）、返信通知である「ｒｅｐｌｙ」であるか（Ｓ１２０４）に従って、処理を振り分ける。
返信通知のｒｅｐｌｙの場合（Ｓ１２０４：ＹＥＳ）、［Ｘ−ＭＬ−Ｃｏｍｍａｎｄ：］ヘッダ９２からメッセージ番号を取り出し（Ｓ１２０５）、この番号が各メンバのディレクトリ中のｒｅｐｌｙファイル６７（図６参照）にあるかどうかサーチする（Ｓ１２０６）。もし、番号がｒｅｐｌｙファイル６７中にあれば、そのメンバが返信メールを出したことになるので、そのユーザ名を結果とする（Ｓ１２０８）。そして、全てのメンバについて上記のチェックが終了すると（Ｓ１２０９：ＹＥＳ）、結果をコマンド・メールの送信者に返信する。
【００５４】
一方、既読通知のｒｅａｄの場合（Ｓ１２０３：ＹＥＳ）は、Ｓ１２１２〜Ｓ１２１６の処理を実行するが、これは上記ｒｅｐｌｙの場合のＳ１２０５〜Ｓ１２０９の処理と同様なので、詳しい説明は省略する。そして、この場合も、全てのメンバについてチェックが終了すると（Ｓ１２１６：ＹＥＳ）、結果をコマンドメールの送信者に返信して本処理を終了する。これでメールを読んだメンバのリストが得られる。
【００５５】
なお、この図１２のフローチャートが本発明の「コマンド実行手段」としての処理の実行に相当する。
このように、本電子メールシステムを用いることで、これまで不可能であった分散メールシステム上での既読、返信の確認が可能となり、メッセージの管理をきめ細かく行なうことができる。そのため、窓口アドレスに対して送られたメールを複数の担当者に転送した後、どの担当者がそのメールを読んだか、そしてどの担当者がそのメールに対して返事を出したかを管理することが容易にできる。
【００５６】
また、全ての操作をメールにより行なえるので、ユーザが特別な装置・ソフトウェアを準備する必要がなく、実現が容易である。
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
【００５７】
例えば、上記実施形態においては、端末３６側では返信情報のみを扱っていたが、既読通知についても端末３６側でヘッダを見て送信することができる。もちろん、この場合は、全ての端末３６にそのための処理が必要である。
また、メーリングリストのシステムに限らず、受信側のメールサーバに既読通知の機能があれば、発信者が直接ヘッダを付加することで、既読情報を得ることが可能である。
【００５８】
また、このシステムでは、既読情報を保持しているが、実際には、メンバは全てのメールを読むはずなので、既読情報ではなく、未読情報を保持する方が利用の上では便利である。
また、実際に運用する場合には、管理用にいくつかの処理の追加が望まれる。たとえば、前記既読情報及び返信情報は、増える一方なので、定期的に消す必要がある。そのためには、メッセージに含まれている［Ｄａｔｅ：］ヘッダを記録しておき、この日付からある一定の期間を過ぎた既読情報や、返信情報に用いる［Ｍｅｓｓａｇｅ−ＩＤ：］ヘッダ、及び［Ｘ−ｎｏｔｉｆｙ−ｒｅｃｅｉｖｅ−ｒｅｐｌｙ：］ヘッダの対を消すことにより対応できる。
【図面の簡単な説明】
【図１】  本発明の構成を例示する説明図である。
【図２】  本発明の実施形態の概要を示す機能構成図である。
【図３】  本発明が実現される分散ネットワーク上の電子メールシステムの概略構成図である。
【図４】  メーリングリストの概念説明図である。
【図５】  メーリングリストサーバの概略構成図である。
【図６】  メーリングリストサーバの記憶装置の内容を示す説明図である。
【図７】  メールサーバの概略構成図である。
【図８】  メールのヘッダの概略構成図である。
【図９】  メーリングリストの基本処理手順を示すフローチャートである。
【図１０】  メールサーバにて実行される既読通知処理手順を示すフローチャートである。
【図１１】  メールサーバにて実行される返信通知処理手順を示すフローチャートである。
【図１２】  メーリングリストサーバにて実行されるコマンドメールの処理手順を示すフローチャートである。
【符号の説明】
２３…メーリングリストサーバ          ３１…ネットワーク
３２…メールサーバＡ                  ３３…中継サーバＤ
３４…メールサーバＢ                  ３５…メールサーバＣ
３６…端末                            ３７…ユーザＡ
３８…メンバＢ                        ３９…メンバＣ
５１…ネットワークインターフェース    ５２…メール配送部
５３…メッセージ管理部                ５４…記憶装置
７１…ネットワークインターフェース    ７２…メール配送部
７３…メッセージ管理部                ７４…記憶装置
【図１】
0003648325.tif 000002
【図２】
0003648325.tif 000003
【図３】
0003648325.tif 000004
【図４】
0003648325.tif 000005
【図５】
0003648325.tif 000006
【図６】
0003648325.tif 000007
【図７】
0003648325.tif 000008
【図８】
0003648325.tif 000009
【図９】
0003648325.tif 000010
【図１０】
0003648325.tif 000011
【図１１】
0003648325.tif 000012
【図１２】
0003648325.tif 000013