メッセージ伝送システム及びそれを構成するサーバ装置
【課題】 異なる組織間のメッセージ伝送においても、いったん送信したメッセージの変更や取消が可能で、メッセージ伝送における秘密性の維持が簡易に行え、安全性の高いメッセージ伝送の実現。
【解決手段】 第１のメッセージ管理機構の送信側サーバは、送信者の認証をし、認証の成功した送信者により作成されたメッセージを送信端末から受信し、受信したメッセージの本体を保存し、宛先に対応する受信側サーバに対してはメッセージの存在を示す通知を送出する。第２のメッセージ管理機構の受信側サーバは、送信側サーバからの通知を保存し、受信者の認証をし、認証の成功した受信者による当該受信者が宛先のメッセージの閲覧要求を受信端末から受信し、これを契機として、保存されている通知に基づく取得要求を送信側サーバへ送出する。この取得要求に応答して、送信側サーバに保存されているメッセージ本体が、受信側サーバ経由で、受信端末へ送信される。
【解決手段】 第１のメッセージ管理機構の送信側サーバは、送信者の認証をし、認証の成功した送信者により作成されたメッセージを送信端末から受信し、受信したメッセージの本体を保存し、宛先に対応する受信側サーバに対してはメッセージの存在を示す通知を送出する。第２のメッセージ管理機構の受信側サーバは、送信側サーバからの通知を保存し、受信者の認証をし、認証の成功した受信者による当該受信者が宛先のメッセージの閲覧要求を受信端末から受信し、これを契機として、保存されている通知に基づく取得要求を送信側サーバへ送出する。この取得要求に応答して、送信側サーバに保存されているメッセージ本体が、受信側サーバ経由で、受信端末へ送信される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信端末からのメッセージを受信端末へ伝送するシステムと、このシステムを構成するサーバ装置に関する。
【背景技術】
【０００２】
これまで、インターネットなどの通信設備を用いたメッセージ伝送システムは、電子メールやインスタントメッセージを用いたものが一般的であった。これらの技術は、簡単な操作と即時性、標準化されたプロトコルによって、世界中のコンピュータや携帯電話で使われている。
【０００３】
これらの技術は、基本的に、送信元のサーバが、自己のサービスを受ける送信端末からのメッセージを、メッセージの宛先（送信先ともいう。）となる受信端末にサービスを提供する送信先のサーバへ、転送し、この送信先のサーバに保存されているメッセージを、受信端末がダウンロードすることで、メッセージ伝送を実現している。例えば、電子メールは、Simple Mail Transfer Protocol (RFC2821)によって送信先のサーバへ転送され、Post Office Protocol Version 3 (RFC1939)やInternet Message Access Protocol (RFC3501)によって受信端末へ送信されるのが、一般的である。
【０００４】
しかし、この方式では、添付ファイルを含む電子メール等、サイズの大きなメッセージを、複数の送信先へ伝送しようとすると、ネットワークが輻輳状態に陥りやすく、また、送信先のサーバにおいても、受信者のメールボックスの空き容量が確保できないことにより、メッセージが伝送不可能になることが頻繁に生じる。
【０００５】
特許文献１の技術では、送信側の電子メールサーバにおいて、端末から送信要求がなされた電子メールに含まれる添付ファイルを抽出して、抽出したファイルをＷＷＷサーバ上に保存し、ＷＷＷサーバのアドレスを示す情報を添付ファイルの代わりに付加した電子メールを、宛先側に送信することにより、上記の問題を解決している。
【特許文献１】特開２００２−１８３０５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、既存のメッセージ伝送システムには、特許文献１の技術によっても解決できない多くの課題が存在している。
【０００７】
例えば、既存の方式では、作成したメッセージをいったん送信してしまうと、そのメッセージについて宛先の変更や内容の修正、削除等ができないため、錯誤により別の宛先を指定して送信してしまったり、内容を間違ってしまったりした場合には、復旧することができず、送信先の個人や会社との信頼関係の毀損や、情報漏洩につながる危険性が高い。
【０００８】
そして、電子メールの特性上、通信経路上では平文でメッセージが転送されるため、秘密情報の取り扱いが難しい。これまでも、ディジタル署名によって改ざんを防止したり、添付ファイルを暗号化したりといった手法がとられてはいるが、前者を導入する場合、ディジタル署名の取得や設定変更について、全てのエンドユーザが対応できるほどの容易性はなく、後者の場合は、ファイル毎にパスワードを管理しなければならず、業務負担が増加してしまう。
【０００９】
さらに、既存の方式では、受信者の宛先情報（電子メールアドレス等）が知られると、受信者本人の意向に関わらず、一方的にメールを受信させることができてしまうため、スパムメールないし迷惑メールへの対処が、大きな問題となっている。
【００１０】
また、既存の方式では、受信者が受信したメッセージを第三者へ転送することについて制約を受けないため、メッセージの作成者が意図しない相手に転送されたり、Ｗｅｂ上に公開されたりしてしまうリスクがある。
【００１１】
なお、一つの組織内に閉じられて運用されるグループウェアであれば、上述した問題を部分的に解決することは可能かもしれないが、異なる組織間において（例えば、送信者と受信者が異なるドメインに属し、その間がインターネットで接続される場合等）、上述した問題を解決可能な仕組みは、全く知られていない。
【００１２】
本発明は、以上のような事情を考慮し、異なる組織間のメッセージ伝送においても、いったん送信したメッセージの変更や取消が可能で、メッセージ伝送における秘密性の維持が簡易に行え、安全性の高いメッセージ伝送を実現することのできる仕組みを提供することを、目的とする。
【課題を解決するための手段】
【００１３】
本発明の原理に従う一つのメッセージ伝送システムは、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバとを含む。送信側サーバは、送信者が前記第１の利用者群の一人であるかの認証を行う認証手段と、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する受信手段と、受信した前記メッセージの少なくともメッセージ本体を保存する保存手段と、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する送出手段と、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する送信手段とを備える。受信側サーバは、前記送信側サーバから送出された前記通知を保存する保存手段と、受信者が前記第２の利用者群の一人であるかの認証を行う認証手段と、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する受信手段と、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する送出手段と、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する送信手段とを備える。
【００１４】
この構成によれば、既存技術のように作成したメッセージが宛先側のサーバに転送されて全てが送信先の設備に委ねられるのではなく、送信元（送信側）のサーバから送信先（受信側）のサーバへ送信されるのは、メッセージの存在を示す通知にとどまり、実際のメッセージ本体は、メッセージの作成者あるいは送信者の側の管理が及ぶ送信元のメッセージ管理機構のサーバに保存される。受信者は、受信側のサーバが受信した通知に従って、送信側のサーバにアクセスし、そこに保存されているメッセージ本体を閲覧するということになる。なお、メッセージ本体には、メッセージの本文と添付ファイルの両方が含まれてよい。
【００１５】
しかも、上記の構成によれば、受信者の認証を、受信側のメッセージ管理機構が行うため、送信側のメッセージ管理機構は、送信者の認証さえ行えばよく、受信者の認証のための個人情報を保持する必要がない。しかも、認証の成功した受信者しか、メッセージ本体の閲覧をすることはできない。よって、送信者の属する組織やドメインと受信者の属するそれとが異なる場合でも、安全性の高いメッセージ伝送が可能になる。
【００１６】
上記のメッセージ伝送システムにおいて、前記通知が、前記メッセージの送信元についての情報を含み、受信側サーバの前記送出手段は、前記通知が含む情報に従って特定される送信元に対応する送信側サーバへ、前記取得要求を送出するようにしてもよい。
【００１７】
これにより、一つの受信側サーバが、複数の送信側サーバから、メッセージの存在を示す通知を受け取る場合にも、受信者は、それぞれのメッセージ本体が保存されている送信側サーバに適切にアクセスして、メッセージ本体を閲覧することができる。
【００１８】
上記のメッセージ伝送システムにおいて、前記通知が、前記メッセージの送信元及び／又は概要についての情報を含み、受信側サーバが、前記保存手段に保存された通知を、前記認証の成功した受信者の受信端末へ送信する手段をさらに備え、受信端末からの閲覧要求が、前記受信者を宛先とするメッセージの中から当該受信者が前記通知の内容に基づいて選択したメッセージについての閲覧要求であるようにしてもよい。ここでのメッセージの概要についての情報は、例えば、メッセージのヘッダ部分に含まれる件名でもよいし、本文部分から適当に抽出される概要でもよい。
【００１９】
これにより、受信者は、メッセージの存在を示す通知のリストを見て、本体の内容を見るべきメッセージを選択することができる。この場合、選択されたメッセージについてしか、メッセージ本体の取得要求及びそれに応答してのメッセージ本体の送信がなされないため、ネットワーク資源を有効に利用できる。
【００２０】
一方、上記のメッセージ伝送システムにおいて、受信端末からの閲覧要求が、前記受信者を宛先とする全てのメッセージについての閲覧要求であり、受信側サーバの前記送信手段は、前記受信者について保存されている全ての通知に基づいて、各通知に対応する送信側サーバから収集した前記メッセージ本体を、まとめて受信端末へ送信するものであってもよい。
【００２１】
これにより、受信者は、受信端末にメッセージ本体のコピーを残せるシステムであれば、例えば、受信端末が受信側サーバに接続可能である間にまとめて全ての新着メッセージの本体を受信して、オフラインでその内容を閲覧することが可能になる。
【００２２】
上述したように、本メッセージ伝送システムでは、送信側のサーバにメッセージ本体が保存されているので、メッセージの存在をいったん受信側のサーバへ通知してしまった後でも、受信端末が、実際にそのメッセージの本体を閲覧するために送信側のサーバへアクセスしてくる前であれば、受信者に気付かれることなく、内容の変更を行うことができる。
【００２３】
このためには、例えば、上記のメッセージ伝送システムにおいて、前記メッセージ本体の内容変更が、前記メッセージを作成した送信者から要求された場合に、送信側サーバの前記保存手段に保存されたメッセージ本体を書き換える手段を、送信側サーバがさらに備え、送信側サーバの前記送信手段は、受信側サーバからの取得要求に応答して、変更後のメッセージ本体を送信するようにすればよい。
【００２４】
このようにすると、受信者がメッセージ本体を閲覧した後に、送信者が同じメッセージ本体の内容を変更する場合も、受信端末にそのメッセージ本体のコピーを残せないシステムであれば、受信者はもはや変更後の内容しか見ることができないため、間違った内容が流布することを防止できる。なお、受信者が閲覧した後のメッセージ本体を送信者が変更する場合には、そのメッセージの存在を示す通知を再度、送信側サーバから受信側サーバへ送信するようにしてもよい。メッセージ本体の最初の保存時に送信する通知を新着通知とし、内容の変更時に送信する通知を更新通知としてもよい。
【００２５】
同様に、送信側のサーバにメッセージ本体が保存されているので、メッセージの存在をいったん受信側のサーバへ通知してしまった後でも、受信端末が、実際にそのメッセージの本体を閲覧するために送信側のサーバへアクセスしてくる前であれば、受信者に内容を知られることなく、メッセージの削除を行うことができる。
【００２６】
このためには、例えば、上記のメッセージ伝送システムにおいて、前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、送信側サーバの前記保存手段に保存されたメッセージ本体を削除する手段を、送信側サーバがさらに備え、送信側サーバの前記送信手段は、受信側サーバからの取得要求に応答して、削除されたメッセージ本体の代わりに、当該メッセージ本体が削除されたことを示すメッセージを送信するようにすればよい。
【００２７】
別の例として、上記のメッセージ伝送システムにおいて、前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、送信側サーバの前記保存手段に保存されたメッセージ本体を削除するとともに、前記メッセージに対応して送出された前記通知の訂正通知を、受信側サーバに対して送出する手段を、送信側サーバがさらに備え、受信側サーバの前記保存手段に保存されている前記通知を前記訂正通知に基づいて削除することにより、削除された前記メッセージ本体についての取得要求が受信側サーバから送出されないようにしてもよい。
【００２８】
上記の二つの例のように、メッセージの削除を可能にする場合、メッセージを完全に削除するのではなく、そのメッセージの他人への開示は止めるが、作成者自身は利用を継続できるようにしてもよい。
【００２９】
このためには、例えば、上記のメッセージ伝送システムにおいて、送信側サーバの前記受信手段により受信したメッセージを、当該メッセージに対応する通知を送出することなく、保存する第２の保存手段を、送信側サーバがさらに備え、前記メッセージを作成した送信者からの要求が、当該メッセージの受信側への伝送を中止する要求である場合に、削除された前記メッセージ本体を、前記第２の保存手段で保存するようにすればよい。
【００３０】
なお、メッセージの存在をいったん受信側のサーバへ通知してしまった後に、送信者がそのメッセージの宛先を変更する場合には、送信側のサーバが、変更前の宛先の受信者に対しては、メッセージ本体が削除されたものとして扱い（受信側からメッセージ本体の取得要求が来たときにエラーメッセージを返すか、もしくは、送信済みの通知を訂正してメッセージ本体が削除されたことが受信側に分かるようにする通知をあらかじめ送っておく）、変更後の宛先の受信者に対しては、新しいメッセージが送信端末から受信されたものとして扱う（受信側へ新着通知を送る）ようにすればよい。
【００３１】
上述したメッセージ伝送システムでは、送信側サーバが、メッセージ本体を暗号化して保存しておくことによって、情報の秘密性を保つことが可能になる。例えば、この暗号化を受信者の公開鍵で行えば、真正な受信者でない者が、送信側サーバにアクセスして、暗号化されたメッセージ本体を取得しても、これを解読するための秘密鍵がないため、内容を見ることはできない。そして、真正な受信者は、秘密鍵があれば、自身宛の全てのメッセージ本体の内容を見ることができるため、ファイルごとにパスワードを管理するような手間はかからない。
【００３２】
このためには、例えば、上記のメッセージ伝送システムにおいて、送信側サーバが、各受信者の公開鍵を記憶する記憶手段をさらに備え、送信側サーバの前記保存手段は、前記メッセージ本体を前記メッセージの宛先である受信者の前記公開鍵で暗号化して保存するものであり、受信側サーバからの取得要求に応答して送信される前記メッセージ本体が、暗号化されたものとなるようにすればよい。なお、メッセージ本体を暗号化するだけでなく、メッセージの存在を示す通知についても、暗号化して送信するようにしてもよい。また、送信側サーバと送信端末の間の通信は、別の手段で暗号化される。
【００３３】
そして、暗号化されたメッセージ本体の受信側は、一つの例では、受信端末が、その受信端末を利用する受信者の秘密鍵を記憶して、受信側サーバの前記送信手段は、前記メッセージ本体を暗号化されたまま送信し、受信端末で復号化されるようにすればよい。この例の場合、実際には、暗号化されたメッセージ本体は、送信側サーバから受信端末へ、受信側サーバを介さずに送信されても構わない。但し、このメッセージ本体の送信の契機となる取得要求については、受信側サーバから受信されたものかどうかによって、認証された受信者からの閲覧要求かどうかを、送信側サーバが区別するため、受信側サーバを介することが望ましい。
【００３４】
別の例では、受信側サーバが、前記第２の利用者群の各人の秘密鍵を記憶する記憶手段をさらに備え、受信側サーバの前記送信手段が、送信側サーバから送信された前記メッセージ本体を、当該メッセージの受信者の前記秘密鍵で復号化して、受信端末へ送信するようにする。なお、受信側サーバと受信端末の間の通信は、別の手段で暗号化される。この例の場合、受信端末で秘密鍵を管理する必要がないため、エンドユーザが何もしなくても、公開鍵方式を導入して復号化や返信のディジタル署名を行うことが可能になる。
【００３５】
上記のうち後者の例においては、前記秘密鍵の記憶手段を備える受信側サーバが、送信側サーバから送信された前記メッセージ本体を復号化して受信端末へ送信した後は、復号化した前記メッセージ本体も暗号化されたままの前記メッセージ本体も、受信側サーバ内に残さないようにすることにより、さらに情報のセキュリティを高く保つことが可能になる。つまり、同じサーバに暗号化されたメッセージ本体と秘密鍵とが一緒に保存されているという状況を作らないことにより、不正に復号化される危険性を低くすることができる。なお、この例では、受信端末は、復号化されたメッセージ本体を受信してもそのコピーを作成したり、端末外部へ転送したりすることはできず、本メッセージ伝送システムに専用の端末ソフトウェアを閉じると、復号化されたメッセージ本体は消去される。
【００３６】
また、上述したメッセージ伝送システムにおいては、メッセージ本体を暗号化する場合もしない場合も、受信側サーバ及び受信端末において、一切メッセージ本体を保存しないという運用が可能である。この運用によれば、メッセージ本体は、送信者が明示的に削除しない限り、送信側サーバに保存され続けており、受信側サーバには、メッセージの存在を示す通知（過去に受信して既にメッセージ本体を閲覧した通知を含む）のリストだけが保存されている。受信者は、受信側サーバに保存されている通知のリストを見て、再度メッセージ本体を閲覧したくなれば、その都度、送信側サーバにアクセスして、閲覧すればよい。なお、受信者は、受信側サーバに保存されている通知を削除することはでき、送信者は、上述したように送信側サーバに保存されているメッセージ本体を変更、削除することができる。
【００３７】
このようにすれば、受信者が、メッセージ本体もしくはコピーを第三者へ渡すことはできず、また、通知についても、第三者へ転送することはできない（仮に、第三者が転送された通知を用いて送信側サーバにアクセスしようとしても、そのような取得要求を送出してくるのは、本メッセージ伝送システムを構成する受信側サーバではないため、送信側サーバが受け付けない）ため、メッセージの作成者ないし送信者が、メッセージの伝送後も、そのメッセージの内容の配布や公開についてコントロールし続けることが可能である。
【００３８】
公開鍵方式による暗号化を行う上記のメッセージ伝送システムにおいて、送信側サーバが、前記第１の利用者群の利用者毎に前記公開鍵の記憶手段を有し、前記第１の利用者群の一人である送信者の前記記憶手段に公開鍵が記憶されていない新規受信者に対して、当該送信者からのメッセージを伝送するために、少なくとも前記送信者の情報を含む許諾依頼を前記新規受信者の利用する受信端末へ送信し、この許諾依頼に応答して前記受信端末から承諾通知が返信されてきた場合に、前記新規受信者の公開鍵を前記記憶手段に登録するようにしてもよい。ここでの許諾依頼と承諾通知は、受信側サーバを介して通信されてもよい。また、登録される新規受信者の公開鍵は、受信側から返信される承諾通知に含まれていてもよいし、承諾通知を受信した送信側サーバが第三者機関から入手してもよい。
【００３９】
このようにすると、送信端末で通信相手の公開鍵を管理する必要がなく、送信側サーバにおいて自動的に、通信相手の了解を取りつつ入用な公開鍵を収集できるため、エンドユーザが何もしなくても、公開鍵方式を導入して暗号化や返信のディジタル署名の検証を行うことが可能になる。
【００４０】
さらに、受信側サーバが、前記第２の利用者群の利用者毎に、各送信者の公開鍵を記憶する記憶手段をさらに備え、前記許諾依頼を前記受信端末へ転送する際に、この許諾依頼を一時記憶しておき、前記許諾依頼に応答する承諾通知を前記送信側サーバへ転送する際に、前記送信者の公開鍵を前記記憶手段に登録するようにしてもよい。登録される送信者の公開鍵は、送信側から受け取った許諾依頼に含まれていてもよいし、許諾依頼に対する承諾通知を送信する受信側サーバが第三者機関から入手してもよい。
【００４１】
このようにすると、許諾依頼と承諾通知という一度の往復により、送信者と受信者との間の両方向の鍵交換プロセスを済ませることができる。もちろん、受信者は送信者からのメッセージを受け取る意思がある（送信側サーバに受信者の公開鍵が登録される）が、送信者は受信者からの返信メッセージを受け取る意思がない（受信側サーバに送信者の公開鍵は登録されない）という場合もあるため、許諾依頼と承諾通知の一度の往復で、鍵交換プロセスの片方向のみが実行されるようにしてもよい。
【００４２】
ここで、送信側サーバが、送信端末から受信したメッセージの宛先が前記記憶手段に公開鍵が記憶されていない受信者である場合には、前記通知を送出しないことにしてもよい。これにより、送信者が、誤って意図しない相手を宛先としてメッセージを送信してしまうことがなくなる。
【００４３】
さらに、受信側サーバが、本メッセージ伝送システムを構成する送信側サーバからのものでない通知を受信した場合、これを保存しないようにしてもよい。これにより、受信者は、あらかじめ承諾した送信者からのメッセージに係る通知しか受け取らないことになるため、スパムメールを受信しなくて済むことになる。
【００４４】
また、受信者が、送信者の方に受信者からのメッセージを受け取る意思がないならば、その送信者からのメッセージは受け取らないという方針をとる場合、受信側サーバは、受信した通知の送信者の公開鍵が当該受信者の前記記憶手段に記憶されていなければ、通知を保存しないという処理をしてもよい。
【００４５】
なお、送信側サーバは、送信端末から受信したメッセージが、公開鍵の記憶されていない受信者宛であったり、本メッセージ伝送システムの受信側サーバが存在しないドメイン宛であったりした場合に、既存方式のメッセージ（例えば、ＷＷＷサーバのアドレスを示す情報を添付ファイルの代わりに付加した電子メール等）を送信するようにしてもよい。
【００４６】
上記のメッセージ伝送システムにおいて、送信側サーバの前記受信手段が受信したメッセージの宛先情報が、複数の受信者を含む場合に、送信側サーバは、前記メッセージの少なくともメッセージ本体を前記受信者の数だけコピーして前記保存手段に保存し、各受信者に対応する受信側サーバからの取得要求が、それぞれの受信者のタイミングで前記送信側サーバに受信され、それぞれの保存場所に保存されている前記メッセージ本体のコピーの各受信側サーバへの送信も、対応したそれぞれのタイミングで行われるようにしてもよい。
【００４７】
これにより、一つのメッセージを複数の受信者（メーリングリストのようなグループに属する受信者であってもよい）に伝送することが可能になる。特に、メッセージ本体を受信者の数だけコピーして保存し、それぞれのコピーについて個別の受信者との対応をとっておく（通知に含まれる、メッセージの保存場所を特定可能な情報も、受信者毎に異なるものとなる）ことにより、どの受信者が取得要求によりメッセージ本体を閲覧したのかを、送信側サーバで確認することができる。
【００４８】
さらに、送信側サーバは、各受信者の公開鍵を記憶する記憶手段を備え、送信側サーバの前記保存手段は、前記メッセージ本体の複数のコピーをそれぞれ対応する受信者の前記公開鍵で暗号化して保存し、前記各受信側サーバからの取得要求に応答して送信される前記メッセージ本体のコピーが、暗号化されたものとなるようにしてもよい。
【００４９】
上述したように、本メッセージ伝送システムでは、送信側のサーバにメッセージ本体が保存されており、受信端末が閲覧する際には、送信側のサーバにアクセスすることになるので、受信側から開封確認メッセージを送信することなく、送信側のサーバで、開封確認に類する確認を行うことが可能になる。また、一つのメッセージを複数の受信者に伝送する場合、受信者毎に開封確認を行うこともできる。
【００５０】
そこで、上記のメッセージ伝送システムにおいて、送信側サーバが、受信側サーバからの取得要求に応答して前記メッセージ本体を送信したことに基づいて、当該メッセージ本体をその宛先の受信者が取得したことを、前記メッセージを作成した送信者に対して知らせる手段をさらに備えるようにしてもよい。これにより、送信側のサーバで行われた開封確認を、送信端末に伝えることが可能になる。
【００５１】
送信端末へ、その送信者が過去に送信したメッセージの状況（受信側へ通知済み、受信側の開封済み、受信側への開示停止、メッセージの削除等）を伝える方法は、送信端末が、過去に送信したメッセージのリストの提示を送信側サーバに要求した際でもよいし、送信端末からの要求がなくても、状況が変化したときに送信端末が送信側サーバに接続されていれば、教えるようにしてもよい。
【００５２】
上記のメッセージ伝送システムにおいて、前記メッセージの保存場所を特定可能な情報として、それぞれのメッセージに対して一意に付与されるメッセージ識別子を用い、メッセージ本体が書き換えられても、一旦付与されたメッセージ識別子は不変であるようにしてもよい。
【００５３】
上述したメッセージ伝送システムの運用例では、メッセージ本体は、送信者が明示的に削除しない限り、送信側サーバに保存され続けており、受信側サーバには、メッセージの存在を示す通知（過去に受信して既にメッセージ本体を閲覧した通知を含む）のリストが保存されており、送／受信双方のサーバで、同じメッセージ識別子を用いて、メッセージの本体／通知を保持するから、メッセージの履歴を系統立てて管理することが可能になる。
【００５４】
さらに、メッセージ識別子を用いる上記のメッセージ伝送システムにおいて、受信端末へメッセージ本体が送信されたメッセージへの返信メッセージが、前記受信者により作成される場合、受信側サーバの前記保存手段に保存されている通知のうち前記メッセージに対応する通知を参照することにより、前記返信メッセージに前記メッセージのメッセージ識別子を含ませることが可能となるようにしてもよい。
【００５５】
これにより、あるメッセージへの返信メッセージは、返信元のメッセージの識別子も保持するため、メッセージのスレッド管理（メッセージ同士の前後関係あるいは依存関係の把握）を容易にすることができる。
【００５６】
上記のメッセージ伝送システムが、前記第１及び第２のメッセージ管理機構が登録される全体管理サーバをさらに含み、送信側サーバは、前記第２のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、受信側サーバへの通信を行い、受信側サーバは、前記第１のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、送信側サーバへの通信を行うようにしてもよい。
【００５７】
これにより、全体管理サーバに、それぞれの組織あるいはドメインに対応するメッセージ管理機構のサーバを登録し、各メッセージ管理機構で自組織あるいはドメインのユーザーを管理するという分散管理が可能になり、異なるドメイン名をもつ組織間でのメッセージ交換を実現することができるようになる。つまり、各メッセージ管理機構のサーバは、通信先の他のサーバが、本メッセージ伝送システムを構成するメッセージ管理機構サーバであるのかどうかを、全体管理サーバに問い合わせることによって知ることができる。
【００５８】
上記のメッセージ伝送システムが、送信側サーバと受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、前記仲介サーバは、送信側サーバ及び受信側サーバのそれぞれと確認信号を交換することにより、送信側サーバから送出された前記通知が受信側サーバに受信されたかを、送信側サーバと受信側サーバの双方が確認できるようにする手段を備えてもよい。
【００５９】
このような確認を仲介サーバが行うことにより、送信側サーバから受信側サーバへの通知が、どの段階まで実際に行われ、途中で止まっているとすればその原因は何かということを、送信側サーバに把握させることができる。この例で確認の対象としているのは、メッセージの存在を示す通知であるが、送信側サーバから受信側サーバへの通信という観点から、公開鍵登録の際の許諾依頼を確認の対象としてもよいし、逆方向の受信側サーバから送信側サーバへの通信である、公開鍵登録の際の承諾通知を確認の対象としてもよい。
【００６０】
この仲介サーバも、上記の全体管理サーバに登録されるようにし、送信側サーバと受信側サーバは、通信先のサーバが、本メッセージ伝送システムを構成する仲介サーバであるのかどうかを、全体管理サーバに問い合わせるようにしてもよい。
【００６１】
また、仲介サーバとメッセージ管理機構サーバとの間の通信を暗号化することにより、メッセージの存在を示す通知、許諾依頼、承諾通知についても、暗号化して通信することが可能である。メッセージ本体については、上述したような公開鍵方式による別の暗号化が可能であるため、仲介サーバを通さずに、別の通信経路で送信側サーバから受信側へ送信しても構わない。
【００６２】
上記のメッセージ伝送システムが、送信側サーバと受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、前記仲介サーバは、送信側サーバから受信側サーバへの前記通知についての処理を記録することにより、前記メッセージ伝送システムの利用状況の監視を可能にする手段を備えてもよい。
【００６３】
これにより、送信側サーバと受信側サーバとの間の通信について、ログをとることが可能になり、このログを統計情報として処理し、本メッセージ伝送システム全体の管理に役立てることが可能になる。
【００６４】
上述した本発明はいずれも、メッセージ伝送システムを構成する各サーバ装置の発明としても、各サーバ装置が行う方法の発明としても、メッセージ伝送システム全体が行う方法の発明としても、成立するものである。また、これらの各装置あるいはシステムとしてコンピュータあるいはコンピュータ群を機能させるためのプログラムの発明や、このようなプログラムを記録した記録媒体の発明としても、勿論成立するものである。
【００６５】
例えば、本発明の一つの態様に係るサーバ装置は、送信側のサーバ機能と受信側のサーバ機能を利用してメッセージを伝送するシステムの構成要素となるサーバ装置であって、当該サーバ装置が実現するメッセージ管理機構の利用者群の各利用者の情報を登録する登録手段と、送信者が登録された前記利用者であるかの認証を行う第１の認証手段と、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する第１の受信手段と、受信した前記メッセージの少なくともメッセージ本体を保存する第１の保存手段と、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する第１の送出手段と、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する第１の送信手段と、送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存する第２の保存手段と、受信者が登録された前記利用者であるかの認証を行う第２の認証手段と、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する第２の受信手段と、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する第２の送出手段と、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する第２の送信手段と、を備える。
【００６６】
また例えば、本発明の一つの態様に係るメッセージ伝送方法は、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、により実行され、前記送信側サーバが、送信者が前記第１の利用者群の一人であるかの認証を行い、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信し、受信した前記メッセージの少なくともメッセージ本体を保存し、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出し、前記受信側サーバは、前記送信側サーバから送出された前記通知を保存し、受信者が前記第２の利用者群の一人であるかの認証を行い、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信し、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出し、前記送信側サーバは、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信し、前記受信側サーバは、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する。
【００６７】
本発明のある態様に係るソフトウェアは、コンピュータに組み込まれることによって、該コンピュータを、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、送信側サーバとして機能させるものであって、送信者が前記第１の利用者群の一人であるかの認証を行うためのプログラムコードと、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信するためのプログラムコードと、受信した前記メッセージの少なくともメッセージ本体を保存するためのプログラムコードと、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出するためのプログラムコードと、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信するためのプログラムコードと、を備える。本発明のこの態様は、このソフトウェアをコンピュータに組み込むことにより出現する送信側サーバ装置の発明としても把握される。
【００６８】
本発明の別の態様に係るソフトウェアは、コンピュータに組み込まれることによって、該コンピュータを、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、受信側サーバとして機能させるものであって、前記送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存するためのプログラムコードと、受信者が前記第２の利用者群の一人であるかの認証を行うためのプログラムコードと、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信するためのプログラムコードと、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出するためのプログラムコードと、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信するためのプログラムコードと、を備える。本発明のこの態様は、このソフトウェアをコンピュータに組み込むことにより出現する受信側サーバ装置の発明としても把握される。
【発明の効果】
【００６９】
以上のとおりであるから、本発明によれば、いったん送信したメッセージの変更や取消が可能で、メッセージ伝送における秘密性の維持が簡易に行え、安全性の高いメッセージ伝送を実現することが可能になる。
【発明を実施するための最良の形態】
【００７０】
以下、本発明の実施の形態について、図面を用いて説明する。本実施形態では、電子メール等のメッセージを伝送するシステムの場合を例示する。
［システム全体］
図１は、本実施形態のメッセージ伝送システム全体の構成例を示す図である。図１に示すように、本メッセージ伝送システムは、ドメイン内のユーザー情報の管理やメッセージ（以下、ＭＳＧという）を管理するＭＳＧ管理機構１０−１、１０−２（これらのそれぞれを、あるいは、これらをまとめて、ＭＳＧ管理機構１０ということもある）のサーバと、各ドメイン間でＭＳＧの作成通知やユーザーの公開鍵の伝達を行う通知機構２０のサーバと、このＭＳＧ管理機構１０と通知機構２０の完全修飾ドメイン名（以下、ＦＱＤＮという）を管理するＩＤ管理機構３０のサーバと、端末ソフトウェア５０−１、５０−２（これらをまとめて端末ソフトウェア５０ということもある）がインストールされている端末で構成される。本メッセージ伝送システムを構成する複数のサーバの間は、例えばＴＣＰ／ＩＰのようなネットワーク６０で接続される。
【００７１】
図１の例では、説明の便宜のため、二つのＭＳＧ管理機構１０−１、１０−２と二つの端末ソフトウェア５０−１、５０−２が図示されているが、一つのＭＳＧ管理機構に多数の端末ソフトウェアが接続することや、一つのＭＳＧ管理機構が複数のＭＳＧ管理機構のそれぞれへＭＳＧを送信したり、一つのＭＳＧ管理機構が複数のＭＳＧ管理機構のそれぞれからＭＳＧを受信したりすることは、勿論可能である。また、図１の例では、一つの通知機構２０が図示されているが、多数のＭＳＧ管理機構がある場合、通知機構を複数設けて、ＭＳＧ管理機構間の仲介機能を分担させてもよく、あるＭＳＧ管理機構から別のＭＳＧ管理機構までの間に、二つ以上の通知機構が介在するようにしてもよい。
【００７２】
以下、一方のＭＳＧ管理機構１０−１に対応するドメインのユーザーから、他方のＭＳＧ管理機構１０−２に対応するドメインのユーザーへ、ＭＳＧ（例えば電子メール）が伝送されるときの動作について概略を説明する（本発明の特徴的な動作については、図面を用いて後述する）。
【００７３】
この例では、送信元（送信側）のＭＳＧ管理機構１０−１のサーバが、本発明の第１のメッセージ管理機構の送信側サーバに相当し、送信先（受信側）のＭＳＧ管理機構１０−２のサーバが、本発明の第２のメッセージ管理機構の受信側サーバに相当する。また、通知機構２０のサーバが、本発明の仲介サーバに相当し、ＩＤ管理機構３０のサーバが、本発明の全体管理サーバに相当する。さらに、端末ソフトウェア５０−１がインストールされている端末が、本発明における送信端末に相当し、端末ソフトウェア５０−２がインストールされている端末が、本発明の受信端末に相当する。
【００７４】
この場合、作成されるＭＳＧは、作成者ユーザーのドメイン内にあるＭＳＧ管理機構１０−１に登録され、送信先のユーザーを管理するＭＳＧ管理機構１０−２に対して、ＭＳＧのヘッダー情報が通知される。このヘッダー情報には、少なくとも送信元ユーザーのドメインＩＤ及びユーザーＩＤ、送信先となるユーザーのドメインＩＤ及びユーザーＩＤ、件名、概要、送信日時、ＭＳＧＩＤ（ＭＳＧごとにユニークなＩＤ）が含まれる。ただし、ＭＳＧ本文や添付ファイルは、ＭＳＧ管理機構１０−２に通知される情報には含まれていない。そのため、これらを利用する場合は、送信元ユーザーのドメインにあるＭＳＧ管理機構１０−１に対して、送信先となったＭＳＧ管理機構１０−２が、送信先となっているユーザーのドメインＩＤ、ユーザーＩＤ、当該ＭＳＧＩＤを通知して、ＭＳＧ本文や添付ファイルを都度取得する。このようにして、ＭＳＧ本文や添付ファイルが、送信先ユーザーの端末ソフトウェア５０−２に提供される。
【００７５】
送信先として指定できるユーザーＩＤは、ＭＳＧ作成に先立ち、当該ユーザーの許諾を得て、相互に公開鍵とともに受け渡しを行う必要がある。ここで交換したユーザーＩＤと公開鍵は、それぞれのＭＳＧ管理機構１０−１、１−２に保持され、ユーザーごとのアドレス帳に相手先となるユーザーのドメインＩＤとユーザーＩＤが登録される。ＭＳＧ本文及び添付ファイルは、ここで取得した公開鍵を用いて暗号化された状態で、後から来る取得要求に応じて伝送される。取得要求に先立って送信されるヘッダー情報を、上記の公開鍵を用いて暗号化してもよい。
【００７６】
以下には、本実施の形態のメッセージ伝送システムの各構成要素について、図面を参照して詳しく説明する。
【００７７】
［端末ソフトウェア］
まず、端末ソフトウェア５０がインストールされた端末（単に端末５０ともいう）の構成について、図２を参照しながら、この端末ソフトウェア５０によって実現される機能とともに、説明する。
【００７８】
（１）ＳＳＬによる暗号化通信と認証トークンの利用
図２は、端末５０の構成例を示す図である。図２に示すように、端末５０は、暗号化・認証部５１０を備えている。この暗号化・認証部５１０によって、端末ソフトウェア５０とＩＤ管理機構３０のサーバ、ＭＳＧ管理機構１０のサーバとの間の通信に、ＳＳＬを用いた暗号通信が適用される。また、ＭＳＧ管理機構１０との通信の際は、当該ユーザーのドメインＩＤ及びユーザーＩＤ、認証済みトークンを用いて識別（以下、ユーザー識別情報）が行われる。
【００７９】
（２）ユーザー認証
端末５０は、入出力部５２０と認証処理部５３０と名前解決要求部５３５を備えている。この入出力部５２０は、端末ソフトウェアの起動後、ユーザーからユーザーのドメインＩＤ、ユーザーＩＤ及びパスワードの入力を受け付け、認証処理部５３０に送り、ユーザー認証処理を行わせる。また、認証処理部５３０は、名前解決要求部５３５に対して、ＭＳＧ管理機構１０のＦＱＤＮを要求する。名前解決要求部５３５は、入力されたドメインＩＤをＩＤ管理機構３０に通知し、当該ドメインのＭＳＧ管理機構１０−１のＦＱＤＮを取得し、認証処理部５３０に返す。認証処理部５３０は、取得したＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザーＩＤ及びパスワードを通知し、認証結果（ＯＫ又はＮＧ）及び認証済みトークンを取得する。
【００８０】
（３）各ＭＳＧリストの取得
端末５０は、ＭＳＧリスト取得部５４０を備えている。認証結果がＯＫとなって認証が得られた場合、ＭＳＧリスト取得部５４０は、同ＭＳＧ管理機構１０−１に対して、ユーザーＩＤを通知し、受信ＭＳＧリスト、送信済みＭＳＧリスト、下書き保存済みリストの要求を行い、各ＭＳＧリストを取得する。以下、各ＭＳＧリストの内容について詳しく説明する。
【００８１】
（４）受信ＭＳＧリストの項目
受信ＭＳＧリストは、当該ユーザー宛に作成されたＭＳＧの一覧である。この受信ＭＳＧリストには、少なくとも送信元ユーザーのユーザー識別情報、件名、送信日時、送信先となるユーザーのドメインＩＤ及びユーザーＩＤ、ＭＳＧごとに一意のＩＤ、過去のＭＳＧに対する返信の場合は、関連づけられた過去のすべてのＭＳＧＩＤが含まれる。
【００８２】
（５）送信ＭＳＧリストの項目
送信済みＭＳＧリストは、当該ユーザーが過去に送信したＭＳＧの一覧である。この送信済みＭＳＧリストには、少なくとも送信先となるユーザーのユーザー識別情報、件名、送信日時、ＭＳＧ本文、添付ファイルのＵＲＩ、ＭＳＧごとに一意のＩＤ、過去のＭＳＧに対する返信の場合は、関連づけられた過去のすべてのＭＳＧＩＤが含まれる。そのＭＳＧの本文が送信先ユーザーの取得要求に応じて伝送済みかどうかを示す開封フラグがさらに含まれてもよい。
【００８３】
（６）下書き保存済みＭＳＧリストの項目
下書き保存済みＭＳＧリストは、当該ユーザーが作成途中で保存した下書きＭＳＧの一覧である。この下書き保存済みＭＳＧリストには、少なくともすでに入力された送信先となるユーザーのユーザー識別情報、件名、保存日時、ＭＳＧ本文、添付ファイルのＵＲＩ、ＭＳＧごとに一意のＩＤと過去のＭＳＧに対する返信の場合は、関連づけられた過去のすべてのＭＳＧＩＤが含まれる。
【００８４】
（７）各ＭＳＧリストの取得結果の表示
ＭＳＧリスト取得部５４０で取得した各ＭＳＧリストは、入出力部５２０に渡され、画面に出力される。
【００８５】
（８）各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示
端末５０は、ＭＳＧ取得部５５０とＭＳＧ処理部５５５を備えている。入出力部５２０において、各ＭＳＧリストに含まれる特定のＭＳＧＩＤがユーザーによって選択された場合には、当該ＭＳＧＩＤと当該ＭＳＧのドメインＩＤが、ＭＳＧ取得部５５０に渡される。このＭＳＧ取得部５５０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ＭＳＧ取得要求を行うユーザーのユーザー識別情報、当該ＭＳＧＩＤを通知し、ＭＳＧ本文及び添付ファイルのＵＲＩを要求する。また、ＭＳＧ処理部５５５は、取得したＭＳＧ本文及び添付ファイルのＵＲＩを入出力部５２０に渡して画面に出力させる。
【００８６】
（９）新規ＭＳＧの作成
端末５０は、アドレス帳リスト取得部５６０を備えている。入出力部５２０において、ユーザーからＭＳＧの作成指示を受けた場合に、アドレス帳リスト取得部５６０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報を通知し、当該ユーザーのＭＳＧ交換可能な相手先ユーザーのドメインＩＤ及びユーザーＩＤの一覧となるアドレス帳リストを取得して、入出力部５２０に渡して画面に出力させる。また、このアドレス帳リスト取得部５６０は、出力されたアドレス帳リストの中から相手先となるユーザーＩＤを指定し、件名、本文、添付ファイルを入出力部５２０で受け付けて、ＭＳＧ処理部５５５に渡す。ＭＳＧ処理部５５５は、入力または指定された項目をＭＳＧ管理機構１０−１のＦＱＤＮに対して、新規ＭＳＧ作成を要求し、要求結果（ＯＫまたはＮＧ）を取得する。要求結果がＯＫだった場合、ＭＳＧ処理部５５５は、上記（８）と同様に送信済みＭＳＧリストを再取得し、画面表示を更新する。
【００８７】
（１０）アドレス帳リストへの個別追加
端末５０は、交換許諾依頼発行部５７０と交換許諾リスト取得部５７５を備えている。アドレス帳リストに送信したい相手先となるユーザーのドメインＩＤ及びユーザーＩＤが含まれていない場合は、入出力部５２０にて新規に追加したい相手先ユーザーのドメインＩＤとユーザーＩＤを入力させ、入力されたドメインＩＤとユーザーＩＤが交換許諾依頼発行部５７０に渡される。交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報と入力された相手方となるドメインＩＤ及びユーザーＩＤのアドレス帳リストへの追加を要求する。ここで要求した相手先ユーザーのドメインＩＤ及びユーザーＩＤのうち、アドレス帳リストに登録されていないユーザー情報の取得を要求された場合、交換許諾リスト取得部５７５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報を通知し、交換許諾依頼中リストを取得し、入出力部５２０に渡して、画面に出力させる。
【００８８】
（１１）アドレス帳リストへの追加要求の撤回
交換許諾依頼中リストに含まれる相手先ユーザーへの要求の撤回指示について入出力部５２０が受けた場合、交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報と当該相手先ユーザーのドメインＩＤ及びユーザーＩＤ、要求の撤回指示を通知する。その後、交換許諾依頼発行部５７０は、上記（１０）と同様に交換許諾中リストを再取得し、画面表示を更新する。
【００８９】
（１２）被交換許諾依頼保留中リストの取得
当該ログイン中ユーザーへの被交換許諾依頼保留中リスト（相手方から公開鍵の交換を要求され、承諾や却下等の回答を保留しているリスト）の取得要求があった場合、交換許諾リスト取得部５７５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報を通知し、被交換許諾依頼保留中リストを取得して、入出力部５２０に渡して、画面に表示させる。
【００９０】
（１３）被交換許諾依頼の承諾または却下
端末５０は、交換許諾依頼処理部５８０を備えている。被交換許諾依頼保留中リストに含まれるユーザーのドメインＩＤ及びユーザーＩＤを指定し、承諾または却下の指示について入出力部５２０が受けた場合、交換許諾依頼処理部５８０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報と対象となる依頼元ユーザーのドメインＩＤ及びユーザーＩＤ、許諾又は却下の指示を通知する。その後、交換許諾依頼処理部５８０は、上記（１２）と同様に被交換許諾依頼保留中リストを再取得し、画面表示を更新する。
【００９１】
（１４）送信済みＭＳＧの訂正、開示中止、削除
送信済みＭＳＧリストに含まれるＭＳＧＩＤが指定され、当該ＭＳＧの送信先、件名、本文、添付ファイルについての訂正または開示中止、削除を入出力部５２０が受けた場合、ＭＳＧ処理部５５５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、当該ユーザーのユーザー識別情報、当該ＭＳＧＩＤ、入力または指定された項目内容と訂正または開示中止もしくは削除の指示を要求し、要求結果（ＯＫまたはＮＧ）を取得する。ＭＳＧ処理部５５５は、要求結果がＯＫだった場合、上記（８）と同様に送信済みＭＳＧリスト及び下書きＭＳＧリストを再取得し、画面表示を更新する。
【００９２】
（１５）グループリスト作成要求
複数のユーザーＩＤを指定して送信先として指定できるようにするグループリスト（例えばメーリングリスト）の作成要求について入出力部５２０が受けた場合、交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報とグループ名、参加させたいすべてのユーザーのドメインＩＤ及びユーザーＩＤ並びにユーザー名を「グループリスト作成要求」として通知する。
【００９３】
（１６）グループリスト削除要求
グループリストの削除要求について入出力部５２０が受けた場合、交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報とグループ名を「グループリスト削除要求」として通知する。
【００９４】
（１７）グループリスト参加保留中リストの取得
当該ログイン中ユーザーへのグループリスト参加保留中リスト（グループ管理者からグループリストへの参加を要求され、承諾や拒否等の回答を保留しているリスト）の取得要求があった場合、交換許諾リスト取得部５７５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報を通知し、グループリスト参加保留中リストを取得して、入出力部５２０に渡して、画面に表示させる。
【００９５】
（１８）グループリスト参加の承諾または拒否
グループリストへの参加の承諾または拒否の指示について入出力部５２０が受けた場合、交換許諾依頼処理部５８０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報と対象となるグループのドメインＩＤ及びグループＩＤ、許諾又は拒否の指示を通知する。
【００９６】
［ＩＤ管理機構］
つぎに、ＩＤ管理機構３０のサーバの構成について説明する。以下、ＩＤ管理機構３０のサーバの各構成を、図３および図４を参照しながら、このサーバの機能と対応させて説明する。
【００９７】
（１）ＳＳＬによる暗号化通信
図３は、ＩＤ管理機構３０のサーバの構成例を示す図である。図３に示すように、ＩＤ管理機構３０のサーバは、暗号化・認証部３１０を備えている。この暗号化・認証部３１０によって、ＩＤ管理機構３０と端末ソフトウェア５０、ＭＳＧ管理機構１０、通知機構２０との間の通信に、ＳＳＬを用いた暗号通信が適用される。
【００９８】
（２）ＭＳＧ管理機構のＦＱＤＮ応答
ＩＤ管理機構３０のサーバは、名前解決処理部３１５とドメイン情報処理部３２０とドメイン情報保管部３３０を備えている。名前解決処理部３１５が、端末ソフトウェアまたはＭＳＧ管理機構もしくは通知機構からドメイン名と各機構のＦＱＤＮ要求を取得した場合は、ドメイン情報処理部３２０が、ドメイン情報保管部３３０の管理する「ドメイン情報管理テーブル」から、ドメイン名を検索キーにして、対応するドメインＩＤ、ＭＳＧ管理機構のＦＱＤＮ、通知機構のＦＱＤＮのうち要求される項目を抽出し、要求元に応答を返す。
図４は、ドメイン情報管理テーブルの一例を示す図である。図４に示すように、ドメイン情報管理テーブルには、ドメイン情報ごとに、ドメイン名、ドメインＩＤ、ＭＳＧ管理機構１０のＦＱＤＮ、ＭＳＧ管理機構１０の公開鍵、通知機構２０のＦＱＤＮ、管理者のＩＤなどの情報が記録されている。
【００９９】
［ＭＳＧ管理機構］
つづいて、ＭＳＧ管理機構１０のサーバの構成について説明する。以下、ＭＳＧ管理機構１０のサーバの各構成を、図５〜図１２を参照しながら、このサーバの機能と対応させて説明する。
【０１００】
（１）ＳＳＬと公開鍵による暗号化通信
図５は、ＭＳＧ管理機構１０のサーバの構成例を示す図である。図５に示すように、ＭＳＧ管理機構１０のサーバは、二つの暗号化・認証部（サーバ間の暗号化・認証部１１０と、端末との間の暗号化・認証部１１５）を備えている。これらの暗号化・認証部１１０、１１５によって、ＭＳＧ管理機構１０と端末ソフトウェア５０、ＩＤ管理機構３０、通知機構２０との間の通信に、ＳＳＬを用いた暗号通信が適用される。
送信元のＭＳＧ管理機構１０−１から通知機構２０を介して、送信先のＭＳＧ管理機構１０−２に送信されるすべての通知は、ヘッダー部とデータ部の二つで構成される。ヘッダー部には、少なくとも送信元ドメインＩＤと送信先ドメインＩＤ、データ部のハッシュ値、送信日時が含まれる。また、データ部には、少なくとも送信元ユーザーＩＤや送信先ユーザーＩＤ、通知本文が含まれる。データ部は、ＩＤ管理機構３０から取得する送信先ドメインのＭＳＧ管理機構１０の公開鍵で暗号化される。
【０１０１】
（２）ユーザー認証及び認証済みトークンの発行
ＭＳＧ管理機構１０のサーバは、利用者情報処理部１２０と利用者情報保管部１２２を備えている。端末ソフトウェア５０からユーザーのドメインＩＤ及びユーザーＩＤ、パスワードが通知され、認証要求を取得した場合、利用者情報処理部１２０は、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から、当該ユーザーＩＤを検索キーにし、パスワードの照合を行う。通知されたパスワードと「ユーザー管理テーブル」に記録されたパスワードが同一である場合は、認証済みトークンを発行し、端末ソフトウェアに認証結果（ＯＫ又はＮＧ）とともに応答が返される。ここで発行した認証済みトークン及び有効期限は、上記の「ユーザー管理テーブル」に保存される。
図６は、ユーザー管理テーブルの一例を示す図である。図６に示すように、ユーザー管理テーブルには、ユーザーごとに、ユーザーＩＤ、ユーザー名、表示名、パスワード、公開鍵、秘密鍵、認証済みトークン、トークンの有効期限などの情報が記録されている。
【０１０２】
（３）受信ＭＳＧリストの要求に対する応答
ＭＳＧ管理機構１０のサーバは、ＭＳＧリスト発行部と通知保管部１３２と通知取得部１９０とＭＳＧ取得部１３６を備えている。端末ソフトウェア５０からユーザー識別情報と受信ＭＳＧリストの取得要求があった場合、ＭＳＧリスト発行部１３０は、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から当該ユーザーＩＤを検索キーにして、認証済みトークンを照合する。そして、ＭＳＧリスト発行部１３０は、有効期間内にあることを確認できた場合（以下、「認証済みトークンが有効」という）、通知保管部１３２が管理する「受信ＭＳＧ管理テーブル」から当該ユーザーのユーザーＩＤを検索キーにし、ＭＳＧＩＤ、送信元ユーザーＩＤ、送信元ユーザーのドメインＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、開示種別、返信元ＭＳＧＩＤ、件名をすべて取得して、受信ＭＳＧリストを作成する。この受信ＭＳＧリストは、このリストを要求した端末ソフトウェアに返される。
通知保管部１３２で管理される「受信ＭＳＧ管理テーブル」には、通知取得部１９０が通知機構２０を介して取得した、送信元ＭＳＧ管理機構１０で発行された「ＭＳＧ作成通知」が逐次記録される。また、受信ＭＳＧリストを作成する際、抽出されたＭＳＧＩＤごとにＭＳＧ取得部１３６に対して、当該ＭＳＧの本文及び添付ファイルのＵＲＩ取得要求を行い、結果通知を受信ＭＳＧリストに追加して、端末ソフトウェアに応答を返すこともできる。
図７は、受信ＭＳＧ管理テーブルの一例を示す図である。図７に示すように、受信ＭＳＧ管理テーブルには、受信ＭＳＧごとに、メッセージＩＤ、送信元ユーザーＩＤ、送信元ユーザーのドメインＩＤ、宛先ユーザーＩＤ，宛先ユーザーのドメインＩＤ、開示種別（無指定、ＴＯ、ＣＣ、ＢＣＣ、ブラックリストなど）、返信元メッセージＩＤ（ＭＳＧＩＤと当該ＭＳＧが作成されたドメインＩＤの組み合わせ）、件名、開封フラグ（メッセージ本体の取得要求を発行すると、あるいは取得要求したメッセージ本体が送信元ＭＳＧ管理機構から受信されると、１に変更される）などの情報が記録されている。
【０１０３】
（４）送信済みＭＳＧリストの要求に対する応答
ＭＳＧ管理機構１０のサーバは、「作成ＭＳＧ管理テーブル」を管理するＭＳＧ保管部１３８を備えている。端末ソフトウェア５０からユーザー識別情報と送信済みＭＳＧリストの取得要求があった場合、ＭＳＧリスト発行部１３０は、認証済みトークンが有効の場合、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ユーザーのユーザーＩＤを検索キーにし、開示フラグが１（開示済み）であるＭＳＧを抽出し、ＭＳＧＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、開示種別（ＴＯ、ＣＣ，ＢＣＣ、ブラックリスト）、件名、本文、添付ファイルパスをすべて取得して、送信済みＭＳＧリストを作成する。作成された送信済みＭＳＧリストは、このリストを要求した端末ソフトウェアに返される。そのＭＳＧの本文を送信先ユーザーの取得要求に応じて伝送したかどうかを示す開封フラグがさらに含まれてもよい。
図８は、作成ＭＳＧ管理テーブルの一例を示す図である。図８に示すように、作成ＭＳＧ管理テーブルには、作成ＭＳＧごとに、メッセージＩＤ、作成ユーザーＩＤ、送信先ユーザーＩＤ，送信先ユーザーのドメインＩＤ、開示種別（無指定、ＴＯ、ＣＣ、ＢＣＣ、ブラックリストなど）、件名、本文、添付ファイルパス、開示フラグ（下書き、開示済み、いったん開示後に一時非開示、削除）、開封フラグなどの情報が記録されている。
【０１０４】
（５）下書き済みＭＳＧリストの要求に対する応答
端末ソフトウェア５０からユーザー識別情報と下書き保存済みＭＳＧリストの取得要求があった場合、ＭＳＧリスト発行部１３０は、認証済みトークンが有効の場合、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ユーザーのユーザーＩＤを検索キーにし、開示フラグが０（下書き）であるＭＳＧを抽出し、ＭＳＧＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、開示種別（ＴＯ、ＣＣ，ＢＣＣ、ブラックリスト）、件名、本文、添付ファイルパスをすべて取得して、下書き保存済みＭＳＧリストを作成する。作成された下書き保存済みＭＳＧリストは、このリストを要求した端末ソフトウェアに返される。
【０１０５】
（６）受信ＭＳＧの取得要求に対する応答
ＭＳＧ管理機構１０のサーバは、名前解決要求部１４０を備えている。端末ソフトウェア５０からユーザー識別情報と特定の受信ＭＳＧの取得要求があり、認証済みトークンが有効の場合、ＭＳＧ取得部１３６は、通知保管部１３２が管理する「受信ＭＳＧ管理テーブル」からＭＳＧＩＤを検索キーにして、送信元ユーザーのドメインＩＤを抽出し、続いて、名前解決要求部１４０に対して抽出されたドメインＩＤのＭＳＧ管理機構１０−２のＦＱＤＮを要求する。
名前解決要求部１４０は、ＩＤ管理機構３０に対して、当該ドメインＩＤのＭＳＧ管理機構１０−２のＦＱＤＮを要求し、要求結果通知を取得し、ＦＱＤＮが適切に取得できた場合は、ＭＳＧ取得部１３６に当該ＦＱＤＮを通知する。ＭＳＧ取得部１３６は、ＭＳＧ管理機構１０−２のＦＱＤＮに対して、ＭＳＧＩＤと要求しているユーザーＩＤを通知し、本文及び添付ファイルのＵＲＩを取得する。取得された本文及び添付ファイルは、要求しているユーザーの公開鍵で暗号化されているため、ＭＳＧ取得部１３６は、利用者情報保管部１２２が管理する「ユーザー管理テーブル」からユーザーＩＤを検索キーとして当該ユーザーの秘密鍵を抽出し、復号を行う。
復号された本文及び添付ファイルのＵＲＩは、ＭＳＧ提示部１４５により、通知保管部１３２が管理する「受信ＭＳＧ管理テーブル」からＭＳＧＩＤを検索キーとして抽出された送信元ユーザーのドメインＩＤ、送信元ユーザーＩＤ、件名、開示種別、返信元ＭＳＧＩＤとともに、ＭＳＧ要求した端末ソフトウェアに返される。
【０１０６】
（７）アドレス帳リストの取得要求と応答
ＭＳＧ管理機構１０のサーバは、アドレス帳発行部１５０とアドレス帳保管部１５２を備えている。端末ソフトウェア５０からユーザー識別情報とアドレス帳リスト取得要求があり、認証済みトークンが有効の場合、アドレス帳発行部１５０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」からユーザーＩＤを検索キーとして許諾済みユーザーＩＤ及び許諾済みユーザーのドメインＩＤ、許諾済みユーザー名、グループフラグ（０：個人、１：グループ）を抽出し、アドレス帳リストを作成する。作成されたアドレス帳リストは、このリストを要求した端末ソフトウェアに返される。
図９は、アドレス帳管理テーブルの一例を示す図である。図９に示すように、アドレス帳管理テーブルには、ユーザーＩＤ、承諾済みユーザーＩＤ、承諾済みユーザーのドメインＩＤ、承諾済みユーザー名、グループフラグ（非グループＩＤ／個人ＩＤ，グループＩＤ）、公開鍵などの情報が記録されている。
【０１０７】
（８）新規ＭＳＧの作成要求に対する応答
ＭＳＧ管理機構１０のサーバは、ＭＳＧ発行処理部１６０と通知発行部１６２とグループ情報保管部１６６を備えている。端末ソフトウェア５０からユーザー識別情報と新規ＭＳＧ作成要求と作成項目（送信先となるユーザーのドメインＩＤとユーザーＩＤ及びグループフラグ、開示種別、件名、本文、添付ファイルのＵＲＩ）を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」に対して、新規レコードを追加し、取得した項目を記録する。
ＭＳＧ発行処理部１６０は、これに先立ち、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」に対して、作成者ユーザーＩＤを検索キーとして、送信先となるユーザーのドメインＩＤ及びユーザーＩＤを抽出する。抽出できなかった場合は、（１３）と同様に送信先となるユーザーに対して、公開鍵の交換許諾を要求し、開示フラグを０（下書き）としてレコードを保存する。抽出できた場合は、開示フラグを１（開示済み）としてレコードを保存し、「ＭＳＧ作成通知」を作成する。「ＭＳＧ作成通知」には、送信先ユーザーのドメインＩＤ及びユーザーＩＤ、件名、送信日時、ＭＳＧＩＤ、通知を一意に識別するＩＤが含まれる。このような「ＭＳＧ作成通知」が通知発行部１６２に通知される。
この際、ＭＳＧ保管部１３８が管理する「送信ＭＳＧ管理テーブル」を使用する場合には、これに対して、新規にレコードを追加し、ＭＳＧ本体（本文、添付ファイル）を送信先ユーザーの公開鍵で暗号化して記録する。同じ「送信ＭＳＧ管理テーブル」を使用しない場合は、（１２）において、送信先のＭＳＧ管理機構１０−２のＭＳＧ取得部１３６からＭＳＧ本体の取得要求があった際に、送信先ユーザーの公開鍵によるＭＳＧ本体の暗号化を行う。
図１２は、送信ＭＳＧ管理テーブルの一例を示す図である。図１２に示すように、送信ＭＳＧ管理テーブルには、ＭＳＧごとに、ＭＳＧＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、送信日時、送信先ユーザーの公開鍵による暗号化済みの件名、送信先ユーザーの公開鍵による暗号化済みの本文、送信先ユーザーの公開鍵による暗号化済みの添付ファイルのＵＲＩなどの情報が記録されている。
ただし、グループフラグが１（グループのＩＤ）という送信先が含まれている場合、通知発行部１６２は、通知機構２０を介してグループのＩＤを管理しているＭＳＧ管理機構１０に対して、許諾済みユーザー（グループ）のＭＳＧ管理機構１０が保持しているグループのメンバーリスト（ユーザーのドメインＩＤ及びユーザーＩＤ、公開鍵）を要求し、取得結果通知をグループ情報保管部１６６が管理する「グループ管理テーブル」に保存し、さらにＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」に当該グループに含まれる個別のユーザーＩＤでレコードを追加し、それぞれに対して「ＭＳＧ作成通知」を発行する。
図１０は、グループ管理テーブルの一例を示す図である。図１０に示すように、グループ管理テーブルには、グループごとに、グループＩＤ，グループ名、管理者ユーザーＩＤ、参加者ユーザーＩＤ，参加者ユーザーのドメインＩＤ、状況フラグ（参加依頼中、回答保留中、承諾済み、承諾撤回、依頼拒否）、参加者ユーザーの公開鍵などの情報が記録されている。
また、通知発行部１６２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。名前解決要求部１４０は、ＩＤ管理機構３０に対して、当該ドメインの通知機構２０のＦＱＤＮを要求し、要求結果通知を取得する。ＦＱＤＮが適切に取得できた場合は、通知発行部１６２に当該ＦＱＤＮを通知する。通知発行部１６２は、取得した通知機構のＦＱＤＮに対して、上記の「ＭＳＧ作成通知」を発行する。この処理が完了した場合、通知発行部１６２は、ＭＳＧ発行処理部１６０に処理結果通知を通知し、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１０８】
（９）送信済みＭＳＧの訂正要求に対する応答
端末ソフトウェア５０からユーザー識別情報と送信済みＭＳＧＩＤと訂正要求、訂正内容（送信先となるユーザーのドメインＩＤとユーザーＩＤ、開示種別、件名、本文、添付ファイルのＵＲＩ）を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」に対して、ＭＳＧＩＤを検索キーとして、当該レコードを抽出し、要求された項目を修正する。送信先となるユーザーのドメインＩＤ及びユーザーＩＤが変更になる場合は、新たに指定された送信先ユーザーに対して、（８）と同様に「ＭＳＧ作成通知」を発行する。この処理が完了した場合、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１０９】
（１０）送信済みＭＳＧの開示中止要求に対する応答
端末ソフトウェア５０からユーザー識別情報と送信済みＭＳＧＩＤ、開示中止要求を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧテーブル」に対して、ＭＳＧＩＤを検索キーとして当該レコードを抽出し、開示フラグを０（下書き）に変更する。この処理が完了した場合、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１１０】
（１１）送信済み又は下書き保存済みＭＳＧの削除要求に対する応答
端末ソフトウェア５０からユーザー識別情報とＭＳＧＩＤ、削除要求を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧテーブル」に対して、ＭＳＧＩＤを検索キーとして当該レコードを抽出し、レコードの削除を行う。この処理が完了した場合、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１１１】
（１２）ＭＳＧ本文及び添付ファイルＵＲＩの取得要求に対する応答
ＭＳＧ管理機構１０のサーバは、ＭＳＧ発行部１７０を備えている。他のＭＳＧ管理機構１０から受信ユーザーのドメインＩＤ及びユーザーＩＤ、ＭＳＧＩＤが通知され、ＭＳＧ本文及び添付ファイルのＵＲＩに関する取得要求があった場合、ＭＳＧ発行部１７０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」からＭＳＧＩＤを検索キーにして当該ＭＳＧのレコードを抽出し、要求元ユーザーのドメインＩＤ及びユーザーＩＤが送信先ユーザーのドメインＩＤと送信先ユーザーＩＤの項目と合致した場合、件名、本文、添付ファイルのＵＲＩ、その他必要な項目を抽出する。また、このとき、ＭＳＧ発行部１７０は、同時にアドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から要求元ユーザーのドメインＩＤ及びユーザーＩＤを検索キーとして当該ユーザーの公開鍵を抽出する。
そして、ＭＳＧ発行部１７０は、上記の件名、本文、添付ファイルＵＲＩ、その他必要な項目を上記公開鍵で暗号化し、通知機構２０を介さず、直接に要求元のＭＳＧ管理機構１０に結果通知を返すとともに、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ＭＳＧＩＤと要求元ユーザーのドメインＩＤ及びユーザーＩＤでレコードを抽出し、当該レコードの開封フラグを１（開封済み）に変更する。
また、ＭＳＧ発行部１７０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ＭＳＧを作成したユーザーを抽出し、当該ユーザーに対して、送信先ユーザーが当該ＭＳＧ本体の取得を行った事実について記載した「開封済み通知」を発行することができる。
上記のように、ＭＳＧ作成者の「作成ＭＳＧ管理テーブル」の開封フラグを１に変更したり、ＭＳＧ作成者の「受信ＭＳＧ管理テーブル」に「開封済み通知」という新たなレコードを書き込んだりすることにより、送信先ユーザーがＭＳＧ本体の取得を行ったことをＭＳＧ作成者に知らせるという機能を、ＭＳＧ毎にＯＮ／ＯＦＦできるようにしてもよい。
【０１１２】
（１３）アドレス帳リストへの追加要求に対する応答
ＭＳＧ管理機構１０のサーバは、交換許諾要求取得部１８０と交換許諾発行部１８２を備えている。端末ソフトウェア５０からユーザー識別情報と相手方となるドメインＩＤ及びユーザーＩＤについて、アドレス帳リストへの追加要求があった場合、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該ユーザーＩＤを検索キーとして、取得した相手先となるドメインＩＤ及びユーザーＩＤが登録されているかどうかを判定する。登録されていない場合には、交換許諾発行部１８２に対して、相手方となるユーザーへの公開鍵交換の許諾依頼の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの公開鍵交換の許諾依頼を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェア５０に結果通知を返す。公開鍵交換の許諾依頼の通知には、通知を一意に識別するＩＤが含まれる。
【０１１３】
（１４）アドレス帳リストへの追加要求の撤回要求に対する応答
端末ソフトウェア５０からユーザー識別情報と相手方となるドメインＩＤ及びユーザーＩＤについて、アドレス帳リストへの追加要求の撤回要求があった場合、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該ユーザーＩＤを検索キーとして、取得した相手先となるドメインＩＤ及びユーザーＩＤが登録されているかどうかを判定する。登録されている場合には、さらに状況フラグが０（許諾依頼中）であることを確認し、交換許諾発行部１８２に対して、相手方となるユーザーへの公開鍵交換依頼の撤回を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「公開鍵交換依頼の撤回」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、当該レコードを削除するとともに要求した端末ソフトウェアに結果通知を返す。
【０１１４】
（１５）被交換許諾依頼保留中リストの取得要求に対する応答
ＭＳＧ管理機構１０のサーバは、交換許諾情報保管部１８６と交換許諾リスト発行部１８８を備えている。ＭＳＧ管理機構１０の管理下にあるユーザーの交換許諾要求に基づいて、その相手方となるユーザーに対して発行した交換許諾依頼の情報Ａが、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」に記憶されるとともに、他のＭＳＧ管理機構１０から受信した交換許諾依頼の情報Ｂも、同じ「交換許諾状況管理テーブル」に記憶される。ここでは、その情報Ｂの中から、許諾依頼を受信したが未だ承諾通知も却下通知も返信していない（状況フラグが「回答保留中」の）レコードを抽出したリストを、「被交換許諾依頼保留中リスト」と呼ぶ。
図１１は、交換許諾状況管理テーブルの一例を示す図である。図１１に示すように、交換許諾状況管理テーブルには、ユーザーＩＤ、対象ユーザーＩＤ、対象ユーザーのドメインＩＤ、状況フラグ（許諾依頼中、回答保留中、許諾済み、許諾撤回、依頼却下）、交換依頼ユーザーの公開鍵、グループフラグ（非グループ、グループ）などの情報が記録されている。
端末ソフトウェア５０からユーザー識別情報と当該ユーザーの被交換許諾依頼保留中リストの取得要求があった場合、交換許諾リスト発行部１８８は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該ユーザーＩＤを検索キーとしてレコードを抽出し、さらに状況フラグが１（回答保留中）のレコードを抽出し、「被交換許諾依頼保留中」リストを作成して、要求元の端末ソフトウェア５０に返す。
【０１１５】
（１６）被交換許諾依頼の承諾要求に対する応答
承諾通知要求とは、保留中の許諾依頼に対して、承諾通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求である。端末ソフトウェア５０からユーザー識別情報と相手方となるユーザーのドメインＩＤ及びユーザーＩＤと承諾通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該ユーザーＩＤを検索キーとして、相手方となるユーザーのドメインＩＤ及びユーザーＩＤが含まれるレコードを抽出し、状況フラグを２（許諾済み）に更新する。同時に、交換許諾発行部１８２に対して、相手方となるユーザーへの承諾通知の発行を要求する。
さらに、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」に、新規レコードを追加し、承諾したユーザーＩＤ、依頼元ユーザーＩＤ、依頼元ユーザーのドメインＩＤ、依頼元ユーザー名、グループフラグ０（非グループＩＤ＝個人ＩＤ）、「公開鍵交換依頼」から取得した依頼元ユーザーの公開鍵を保存する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「公開鍵交換の許諾依頼に対する承諾通知」を発行する。この「公開鍵交換の許諾依頼に対する承諾通知」には、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から抽出した承諾したユーザーの公開鍵が含まれる。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェアに結果通知を返す。
【０１１６】
（１７）被交換許諾依頼の却下要求に対する応答
却下通知要求は、保留中の許諾依頼に対して、却下通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求である。端末ソフトウェア５０からユーザー識別情報と相手方となるユーザーのドメインＩＤ及びユーザーＩＤと却下通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該ユーザーＩＤを検索キーとして、相手方となるユーザーのドメインＩＤ及びユーザーＩＤが含まれるレコードを抽出し、状況フラグを４（依頼却下）に更新します。同時に交換許諾発行部１８２に対して、相手方となるユーザーへの却下通知の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「公開鍵交換の許諾依頼に対する却下通知」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、当該レコードを削除するとともに要求した端末ソフトウェアに結果通知を返す。なお、承認及び却下通知には、発行ごとに通知を一意に識別するＩＤが含まれる。
【０１１７】
（１８）交換許諾依頼の承諾通知に対する処理
ＭＳＧ管理機構１０のサーバは、交換許諾処理部１９５を備えている。通知機構２０を介して依頼先ユーザーのＭＳＧ管理機構１０から発行された「公開鍵交換依頼に対する承諾通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から依頼元ユーザーＩＤを検索キーとし、承諾ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを２（承諾済み）に更新するとともに「公開鍵交換依頼に対する承諾通知」から取得した承諾ユーザーの公開鍵を保存する。
さらに交換許諾処理部１９５は、アドレス帳保管部１５２が管理している「アドレス帳管理テーブル」に新規レコードを追加し、依頼元ユーザーＩＤ、承諾済みユーザーＩＤ、承諾済みユーザーのドメインＩＤ、承諾済みユーザー名、グループフラグ０（非グループＩＤ＝個人ＩＤ）、「公開鍵交換依頼に対する承諾通知」から取得した承諾済みユーザーの公開鍵を保存する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１１８】
（１９）交換許諾依頼の却下通知に関する処理
通知機構２０から「公開鍵交換依頼に対する却下通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から依頼元ユーザーＩＤを検索キーとし、承諾ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを４（依頼却下）に更新する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１１９】
（２０）グループリスト作成要求に対する応答
端末ソフトウェア５０からユーザー識別情報とグループ名、参加させたいユーザーのドメインＩＤ及びユーザーＩＤ、ユーザー名が含まれた「グループリスト作成要求」があった場合、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該グループ名を検索キーとして、取得したグループ名が登録されているかどうかを評価し、登録されていない場合は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」に新規レコードを追加し、そのレコードの状況フラグを０（許諾依頼中）に変更する。
続いて、交換許諾要求取得部１８０は、交換許諾発行部１８２に対して、参加させたいユーザーへのグループリスト参加依頼の発行を要求する。交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「グループリスト参加依頼通知」を発行する。
また、交換許諾発行部１８２は、アドレス帳保管部１５２が管理している「アドレス帳管理テーブル」に新規レコードを追加し、管理者のユーザーＩＤ、グループＩＤ、グループのドメインＩＤ、グループ名、グループフラグ１（グループＩＤ）を保存する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェア５０に結果通知を返す。公開鍵交換依頼の通知には、通知を一意に識別するＩＤが含まれる。
【０１２０】
（２１）グループリスト参加保留中リストの取得要求に対する応答
ＭＳＧ管理機構１０の交換許諾情報保管部１８６で管理される「交換許諾状況管理テーブル」に記憶され、かつグループフラグが１（グループＩＤ）であるレコードのうち、グループリスト参加依頼を受信したが未だ承諾通知も却下通知も返信していない（状況フラグが「回答保留中」の）レコードを抽出したリストを「グループリスト参加保留中リスト」と呼ぶ。
端末ソフトウェア５０からユーザー識別情報と当該ユーザーのグループリスト参加保留中リストの取得要求があった場合、交換許諾リスト発行部１８８は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該ユーザーＩＤを検索キーとしてレコードを抽出し、さらにグループフラグが１（グループＩＤ）及び状況フラグが１（回答保留中）のレコードを抽出し、「グループリスト参加保留中リスト」を作成して、要求元の端末ソフトウェア５０に返す。
【０１２１】
（２２）グループリスト参加承諾通知に関する処理
グループリスト参加承諾通知要求とは、保留中の参加許諾依頼に対して、承諾通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求をいう。
端末ソフトウェア５０からユーザー識別情報と対象となるグループＩＤと承諾通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該グループＩＤを検索キーとして、レコードを抽出し、状況フラグを２（許諾済み）に更新する。同時に交換許諾発行部１８２に対して、依頼元ＭＳＧ管理機構に対して、グループリスト参加承諾通知の発行を要求する。
さらに、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」に新規レコードを追加し、承諾したユーザーＩＤ、承諾したユーザーのドメインＩＤ、管理者ユーザーＩＤ、管理者ユーザーのドメインＩＤ、グループ名、「公開鍵交換依頼」から取得した管理者ユーザーの公開鍵を保存する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介してグループリストを管理しているＭＳＧ管理機構１０に対し、管理者ユーザーへの「グループリスト参加承諾通知」を発行する。この「グループリスト参加承諾通知」には、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から抽出した承諾したユーザーの公開鍵が含まれる。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェアに結果通知を返す。
【０１２２】
（２３）グループリスト参加拒否通知に関する処理
グループリスト参加拒否通知要求は、保留中の参加許諾依頼に対して、拒否通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求である。端末ソフトウェア５０からユーザー識別情報と対象となるグループＩＤと拒否通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該グループＩＤを検索キーとして、レコードを抽出し、状況フラグを４（依頼拒否）に更新する。同時に交換許諾発行部１８２に対して、依頼元ＭＳＧ管理機構に対して、グループリスト参加拒否通知の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介してグループリストを管理しているＭＳＧ管理機構１０に対し、管理者ユーザーへの「グループリスト参加拒否通知」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該グループＩＤを検索キーとして、レコードを削除し、要求した端末ソフトウェアに結果通知を返す。
【０１２３】
（２４）グループリスト参加承諾通知に関する処理
通知機構２０を介して依頼先ユーザーのＭＳＧ管理機構１０から発行された「グループリスト参加承諾通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」からグループ管理者ユーザーＩＤを検索キーとして、承諾ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを２（承諾済み）に更新するとともに「グループリスト参加承諾通知」から取得した承諾ユーザーの公開鍵を保存する。
さらに交換許諾処理部１９５は、「グループリスト参加承諾通知」の送信者が自己の管理下にあるユーザーの場合、アドレス帳保管部１５２が管理している「アドレス帳管理テーブル」に新規レコードを追加し、承諾ユーザーＩＤ、グループＩＤ、グループのドメインＩＤ、グループ名、グループフラグ１（グループＩＤ）を保存する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１２４】
（２５）グループリスト参加拒否通知に関する処理
通知機構２０から「グループリスト参加拒否通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」から依頼元ユーザーＩＤを検索キーとし、拒否ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを４（依頼拒否）に更新する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１２５】
（２６）グループリスト削除要求に対する応答
端末ソフトウェア５０からユーザー識別情報とグループＩＤが通知され当該グループリストの削除要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」から当該グループＩＤを検索キーとして、すべての参加ユーザーを抽出し、状況フラグを５（削除準備中）に更新する。続いて、交換許諾要求取得部１８０は、交換許諾発行部１８２に対して、当該グループに参加しているユーザーへ「グループ削除通知」の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「グループ削除通知」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、当該レコードを削除するとともに要求した端末ソフトウェアに結果通知を返す。
【０１２６】
（２７）グループリスト削除通知に関する処理
通知機構２０から「グループリスト削除」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該グループＩＤを含むレコードを抽出し、状況フラグを５（削除準備中）に更新し、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該グループＩＤを含むレコードを抽出して削除するとともに要求したＭＳＧ管理機構１０に結果通知を返す。また、交換許諾処理部１９５は、結果通知の送信後、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該グループＩＤを含むレコードを抽出し、削除を行う。
【０１２７】
［通知機構］
つぎに、通知機構２０のサーバの構成について説明する。以下、通知機構２０のサーバの各構成を、図１３および図１４を参照しながら、このサーバの機能と対応させて説明する。
（１）ＳＳＬによる暗号化通信
図１３は、通知機構２０のサーバの構成例を示す図である。図３に示すように、通知機構２０のサーバは、暗号化・認証部２１０を備えている。この暗号化・認証部２１０によって、ＭＳＧ管理機構１０とＩＤ管理機構３０、他の通知機構２０との間の通信に、ＳＳＬを用いた暗号通信が適用される。
（２）各要求に対する応答
通知機構２０が仲介する通知には、少なくとも、新たにＭＳＧが作成されたときに送信元ドメインのＭＳＧ管理機構１０が送信先ドメインのＭＳＧ管理機構１０へ発行する「ＭＳＧ作成通知」、公開鍵交換依頼を行うために依頼元ドメインのＭＳＧ管理機構１０が依頼先ドメインのＭＳＧ管理機構１０へ発行する「公開鍵交換依頼通知」、「公開鍵交換依頼通知」を受け取った依頼先ドメインのＭＳＧ管理機構１０が依頼元ドメインのＭＳＧ管理機構１０へ発行する「公開鍵交換依頼の承諾通知」もしくは「公開鍵交換依頼の却下通知」、要求された処理の完了を示す「処理完了通知」が含まれる。
通知機構２０のサーバは、通知要求処理部２２０と名前解決要求部２３０と通知発行部２４０を備えている。通知要求処理部２２０は、ＭＳＧ管理機構１０から通知要求を取得した場合に、通知に記載されている送信先ドメインＩＤを抽出し、名前解決要求部２３０は、ＩＤ管理機構３０に対して、送信先となるＭＳＧ管理機構１０のＦＱＤＮ要求を発行し、取得した結果通知を通知発行部２４０に送る。通知発行部２４０は、取得したＭＳＧ管理機構１０のＦＱＤＮに対して、要求された通知の転送を行う。転送が完了した場合、通知要求処理部２２０は、要求元のＭＳＧ管理機構１０に結果通知を返す。すべての結果通知には、通知を一意に識別するためのＩＤが含まれる。
（３）統計情報の取得処理
通知機構２０のサーバは、ＭＳＧ管理機構１０間で送受信される通知を仲介する役割を担う統計情報処理部２５０を備える。統計情報処理部２５０は、送受信される履歴を統計処理するために、統計情報保管部（図示せず）が管理する「統計情報テーブル」に、通知要求日時、通知元ドメインのＩＤ、通知元ＭＳＧ管理機構のＦＱＤＮ、通知先ドメインのＩＤ、通知を一意に識別するＩＤを記録する。
図１４は、統計情報テーブルの一例を示す図である。図１４に示すように、統計情報テーブルには、通知要求日時、通知元ドメインＩＤ、通知元ＭＳＧ管理機構のＦＱＤＮ、通知識別ＩＤなどの情報が記録されている。
以上のように構成された本発明のメッセージ伝送システムについて、図１５〜３４を用いてその動作を説明する。
【０１２８】
［ユーザー認証］
図１５は、端末ソフトウェアの（２）ユーザー認証の処理の流れを示すシーケンス図である。図１５に示すように、ユーザー認証が行われるときには、まず、端末ソフトウェア５０がユーザーのドメインＩＤ、ユーザーＩＤ及びパスワードの入力を受け付け（Ｓ１５００）、ＭＳＧ管理機構１０のＦＱＤＮ要求をＩＤ管理機構３０に送信する（Ｓ１５０１）。ＩＤ管理機構３０は、ＭＳＧ管理機構のＦＱＤＮ要求を受信すると（Ｓ１５０２）、ドメイン情報テーブルからＦＱＤＮを抽出し（Ｓ１５０３）、ＭＳＧ管理機構１０のＦＱＤＮを端末ソフトウェア５０に返信する（Ｓ１５０４）。
【０１２９】
端末ソフトウェア５０は、返信されたＭＳＧ管理機構１０のＦＱＤＮを受信すると（Ｓ１５０５）、ユーザー認証情報をＭＳＧ管理機構１０に送信する（Ｓ１５０６）。ＭＳＧ管理機構１０は、そのユーザー認証情報を受信すると（Ｓ１５０７）、ユーザー管理テーブルでユーザー認証情報の照合を行い（Ｓ１５０８）、認証結果と認証済みトークンを端末ソフトウェア５０に返信する（Ｓ１５０９）。端末ソフトウェア５０は、この認証結果と認証済みトークンを受信する（Ｓ１５１０）。
【０１３０】
［各ＭＳＧリストの取得］
図１６は、端末ソフトウェアの（３）各ＭＳＧリストの取得の処理の流れを示すシーケンス図である。図１６に示すように、各ＭＳＧリストの取得が行われるときには、まず、端末ソフトウェア５０で認証結果がＯＫだったか否かの判定が行われる（Ｓ１６００）。認証結果がＯＫだった場合には、端末ソフトウェア５０からＭＳＧ管理機構１０に受信ＭＳＧリスト取得要求が送信される（Ｓ１６０１）。
【０１３１】
ＭＳＧ管理機構１０は、受信ＭＳＧリスト取得要求を受信すると（Ｓ１６０２）、受信ＭＳＧ管理テーブルから該当するＭＳＧを抽出して（Ｓ１６０３）、受信ＭＳＧリストを作成し（Ｓ１６０４）、その受信ＭＳＧリストを端末ソフトウェア５０へ返信する（Ｓ１６０５）。
【０１３２】
端末ソフトウェア５０は、返信された受信ＭＳＧリストを取得すると、送信済みＭＳＧリストの取得要求をＭＳＧ管理機構１０へ送信する。ＭＳＧ管理機構１０は、この送信済みＭＳＧリスト取得要求を受け付けると（Ｓ１６０８）、作成ＭＳＧ管理テーブルを参照して、該当するＭＳＧを抽出し（Ｓ１６０９）、送信済みＭＳＧリストを作成して（Ｓ１６１０）、端末ソフトウェア５０へ送信する（Ｓ１６１１）。
【０１３３】
端末ソフトウェア５０は、この送信済みＭＳＧリストを受信すると（Ｓ１６１２）、下書き保存済みＭＳＧリストの取得要求をＭＳＧ管理機構へ送信する（Ｓ１６１３）。ＭＳＧ管理機構１０は、下書き保存済みＭＳＧリストの取得要求を受けると（Ｓ１６１４）、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１６１５）、下書き保存済みＭＳＧリストを作成する（Ｓ１６１６）。作成された下書き保存済みＭＳＧリストは、ＭＳＧ管理機構１０から端末ソフトウェアに送信される（Ｓ１６１７、Ｓ１６１８）。
【０１３４】
［各ＭＳＧリストの取得結果の表示］
図１７は、端末ソフトウェアの（７）各ＭＳＧリストの取得結果の表示の処理の流れを示すシーケンス図である。図１７に示すように、各ＭＳＧリストの取得結果の表示が行われるときには、まず、端末ソフトウェア５０において、受信ＭＳＧリストを取得済みであるか否かの判定が行われる（Ｓ１７０）。受信ＭＳＧリストを取得済みである場合には、その受信ＭＳＧリストの取得結果を画面に出力する（Ｓ１７１）。受信ＭＳＧリストを取得済みでない場合には、画面へ出力は行われない。
【０１３５】
つぎに、端末ソフトウェア５０は、送信済みＭＳＧリストを取得済みであるか否かの判定を行う（Ｓ１７２）。送信済みＭＳＧリストを取得済みである場合には、その送信済みＭＳＧリストの取得結果を画面に出力する（Ｓ１７３）。送信済みＭＳＧリストを取得済みでない場合には、画面へ出力は行われない。
【０１３６】
また、端末ソフトウェア５０は、下書き保存ＭＳＧリストを取得済みであるか否かの判定を行う（Ｓ１７４）。下書き保存ＭＳＧリストを取得済みである場合には、その下書き保存ＭＳＧリストの取得結果を画面に出力する（Ｓ１７５）。下書き保存ＭＳＧリストを取得済みでない場合には、画面へ出力は行われない。
【０１３７】
［各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示（１）］
図１８は、端末ソフトウェアの（８）各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図である。図１８に示すように、各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示が行われるときには、まず、送信元の端末ソフトウェア５０−１（以下、端末ソフトウェア（Ａ）とも表記する）において、特定の受信ＭＳＧを取得したか否かの判定が行われる（Ｓ１８００）。特定の受信ＭＳＧを取得した場合には、端末ソフトウェア（Ａ）から送信元のＭＳＧ管理機構１０−１（以下、ＭＳＧ管理機構（Ａ）とも表記する）へ、受信ＭＳＧの取得要求が送信される（Ｓ１８０１、Ｓ１８０２）。
【０１３８】
ＭＳＧ管理機構（Ａ）では、その受信ＭＳＧの取得要求に基づいて、受信ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１８０３）、送信元ＭＳＧ管理機構のＦＱＤＮの取得要求をＩＤ管理機構３０へ送信する（Ｓ１８０４、Ｓ１８０５）。
【０１３９】
ＩＤ管理機構３０は、ＭＳＧ管理機構（Ａ）からのＦＱＤＮの取得要求に基づいて、ドメイン情報管理テーブルからＦＱＤＮを抽出し（Ｓ１８０６）、送信元ＭＳＧ管理機構のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ１８０７、Ｓ１８０８）。
【０１４０】
つぎに、ＭＳＧ管理機構（Ａ）は、ＭＳＧ取得要求を送信先のＭＳＧ管理機構１０−２（以下、ＭＳＧ管理機構（Ｂ）とも表記する）へ送信する（Ｓ１８０９、Ｓ１８１０）。
【０１４１】
ＭＳＧ管理機構（Ｂ）は、そのＭＳＧ取得要求に基づいて、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１８１１）、送信ＭＳＧ管理テーブルから暗号化済みのＭＳＧ本体を抽出する。ＭＳＧ本体が平文のまま送信ＭＳＧ管理テーブルに保存されている場合は、ＭＳＧ本体を送信先ユーザーの公開鍵で暗号化する（Ｓ１８１２）。そして、ＭＳＧ管理機構（Ｂ）からＭＳＧ管理機構（Ａ）へＭＳＧ本体が送信される（Ｓ１８１３、Ｓ１８１４）。
【０１４２】
ＭＳＧ管理機構（Ａ）では、ＭＳＧ本体をユーザーの秘密鍵で復号し（Ｓ１８１５）、復号済みの受信ＭＳＧを端末ソフトウェア（Ａ）へ送信する（Ｓ１８１６、Ｓ１８１７）。そして、端末ソフトウェア（Ａ）で、復号済みの受信ＭＳＧが画面に表示される（Ｓ１８１８）。
【０１４３】
一方、ＭＳＧ管理機構（Ｂ）は、作成ＭＳＧテーブルの開封フラグを「開封済み」に更新し（Ｓ１８１９）、そのＭＳＧの作成ユーザーに対する開封済みの通知を受信側の端末ソフトウェア５０−２（以下、端末ソフトウェア（Ｂ）とも表記する）へ送信する（Ｓ１８２０）。端末ソフトウェア（Ｂ）では、この開封済み通知を受信すると（Ｓ１８２１）、画面のその通知の内容が表示される（Ｓ１８２２）。
［各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示（２）］
図１９は、端末ソフトウェアの（８）各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図である。図１９に示すように、各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示が行われるときには、まず、端末ソフトウェア（Ａ）において、特定の送信済みＭＳＧを取得したか否かの判定が行われる（Ｓ１９００）。特定の送信済みＭＳＧを取得した場合には、端末ソフトウェア（Ａ）からＭＳＧ管理機構（Ａ）へ、送信済みＭＳＧの取得要求が送信される（Ｓ１９０１、Ｓ１９０２）。
【０１４４】
ＭＳＧ管理機構（Ａ）では、その送信済みＭＳＧの取得要求に基づいて、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１９０３）、送信済みＭＳＧを端末ソフトウェア（Ａ）へ返信する（Ｓ１９０４、Ｓ１９０５）。そして、端末ソフトウェア（Ａ）では、送信済みＭＳＧが画面に表示される（Ｓ１９０６）。
【０１４５】
また、端末ソフトウェア（Ａ）は、特定の下書き保存ＭＳＧを取得したか否かの判定を行う（Ｓ１９０７）。特定の下書き保存ＭＳＧを取得した場合には、端末ソフトウェア（Ａ）からＭＳＧ管理機構（Ａ）へ、下書き保存済みＭＳＧの取得要求が送信される（Ｓ１９０８、Ｓ１９０９）。
【０１４６】
ＭＳＧ管理機構（Ａ）では、その下書き保存済みＭＳＧの取得要求に基づいて、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１９１０）、下書き保存済みＭＳＧを端末ソフトウェア（Ａ）へ返信する（Ｓ１９１１、Ｓ１９１２）。そして、端末ソフトウェア（Ａ）では、下書き保存済みＭＳＧが画面に表示される（Ｓ１９１３）。
［新規ＭＳＧの作成］
図２０は、端末ソフトウェアの（９）新規ＭＳＧの作成の処理の流れを示すシーケンス図である。図２０に示すように、新規ＭＳＧの作成が行われるときには、まず、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へアドレス帳リストの取得要求が送信される（Ｓ２０００、Ｓ２００１）。
【０１４７】
ＭＳＧ管理機構（Ａ）は、このアドレス帳リストの取得要求に基づいて、アドレス帳管理テーブルから該当するユーザーの公開鍵交換済みユーザーを抽出し（Ｓ２００２）、アドレス帳リストを作成して（Ｓ２００３）、端末ソフトウェア５０へ返信する（Ｓ２００４、Ｓ２００５）。
【０１４８】
つぎに、端末ソフトウェア５０では、送信先ユーザーの選択が行われた後（Ｓ２００６）、件名、本文、添付ファイルの指定が行われる（Ｓ２００７）。そして、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ新規ＭＳＧ作成要求が送信される（Ｓ２００８、Ｓ２００９）。
【０１４９】
ＭＳＧ管理機構（Ａ）では、この新規ＭＳＧ作成要求に基づいて、（宛先がグループの場合には、グループリストの取得処理後に）作成ＭＳＧ管理テーブルの保存が行われ（Ｓ２０１０）、ＭＳＧ作成完了通知がＭＳＧ管理機構（Ａ）から端末ソフトウェア５０へ送信される（Ｓ２０１１、２０１２）。
【０１５０】
つづいて、ＭＳＧ管理機構（Ａ）は、通知機構２０のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２０１３、Ｓ２０１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２０１５）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２０１６、Ｓ２０１７）。
【０１５１】
ＭＳＧ管理機構（Ａ）は、通知機構２０へＭＳＧ作成通知を送信する（Ｓ２０１８、Ｓ２０１９）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２０２０、Ｓ２０２１）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２０２２）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２０２３、Ｓ２０２４）。
【０１５２】
通知機構２０が、ＭＳＧ作成通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２０２５、Ｓ２０２６）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルへの保存を行って（Ｓ２０２７）、結果通知を通知機構２０へ返信する（Ｓ２０２８、Ｓ２０２９）。そして、通知機構２０は、その結果通知をＭＳＧ管理機構（Ａ）へ転送する（Ｓ２０３０、Ｓ２０３１）。
【０１５３】
［アドレス帳リストへの個別追加］
図２１は、端末ソフトウェアの（１０）アドレス帳リストへの個別追加の処理の流れを示すシーケンス図である。図２１に示すように、アドレス帳リストへの個別追加が行われるときには、まず、端末ソフトウェア５０において、公開鍵交換要求先ユーザー情報の入力が行われる（Ｓ２１００）。
【０１５４】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へアドレス帳リストの追加要求が送信されると（Ｓ２１０１、Ｓ２１０２）、ＭＳＧ管理機構（Ａ）では、新規のユーザーＩＤであるか否かの判定が行われる（Ｓ２１０３）。新規のユーザーＩＤである場合には、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルに新規ユーザーの追加を行って（Ｓ２１０４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２１０５、Ｓ２１０６）。
【０１５５】
ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２１０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２１０８、Ｓ２１０９）。
【０１５６】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼を通知機構２０へ送信する（Ｓ２１１０、Ｓ２１１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２１１２、Ｓ２１１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２１１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２１１５、Ｓ２１１６）。
【０１５７】
通知機構２０が、公開鍵交換依頼をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２１１７、Ｓ２１１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルに新規追加を行って（Ｓ２１１９）、結果通知を通知機構２０へ返信する（Ｓ２１２０、Ｓ２１２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２１２２、Ｓ２１２３）、ＭＳＧ管理機構（Ａ）は、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２１２４、Ｓ２１２５）。
［アドレス帳リストへの追加要求の撤回］
図２２は、端末ソフトウェアの（１１）アドレス帳リストへの追加要求の撤回の処理の流れを示すシーケンス図である。図２２に示すように、アドレス帳リストへの追加要求の撤回が行われるときには、まず、端末ソフトウェア５０において、アドレス帳リスト追加の撤回指示が入力される（Ｓ２２００）。そうすると、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へアドレス帳リスト追加要求の撤回指示が送信される（Ｓ２２０１、Ｓ２２０２）。
【０１５８】
ＭＳＧ管理機構（Ａ）では、該当する追加要求があるか否かの判定が行われ（Ｓ２２０３）、該当する追加要求があると判定された場合には、交換許諾状況管理テーブルから該当する追加要求を抽出し、状況フラグの更新を行う（Ｓ２２０４）。
【０１５９】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２２０５、Ｓ２２０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２２０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２２０８、Ｓ２２０９）。
【０１６０】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼を通知機構２０へ送信する（Ｓ２２１０、Ｓ２２１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２２１２、Ｓ２２１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２２１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２２１５、Ｓ２２１６）。
【０１６１】
通知機構２０が、公開鍵交換依頼をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２２１７、Ｓ２２１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルから該当する追加要求を抽出し、そのレコードを削除して（Ｓ２２１９）、結果通知を通知機構２０へ返信する（Ｓ２２２０、Ｓ２２２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２２２２、Ｓ２２２３）、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する追加要求を抽出し、そのレコードを削除した後（Ｓ２２２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２２２５、Ｓ２２２６）。
【０１６２】
［被交換許諾依頼保留中リストの取得］
図２３は、端末ソフトウェアの（１２）被交換許諾依頼保留中リストの取得の処理の流れを示すシーケンス図である。図２３に示すように、被交換許諾依頼保留中リストの取得が行われるときには、まず、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ、被交換許諾依頼保留中リストの取得要求が送信される（Ｓ２３０、Ｓ２３１）。
【０１６３】
ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当するユーザーのレコードを抽出し（Ｓ２３２）、被交換許諾依頼保留中リストを作成する（Ｓ２３３）。そして、ＭＳＧ管理機構（Ａ）が、作成した被交換許諾依頼保留中リストを端末ソフトウェア５０へ送信すると（Ｓ２３５）、端末ソフトウェアは、取得した被交換許諾依頼保留中リストを画面に出力する（Ｓ２３６）。
【０１６４】
［被交換許諾依頼の承諾］
図２４は、端末ソフトウェアの（１３）被交換許諾依頼の承諾の処理の流れを示すシーケンス図である。図２４に示すように、被交換許諾依頼の承諾が行われるときには、まず、端末ソフトウェア５０において、被交換許諾依頼の承諾指示の入力が行われる（Ｓ２４００）。
【０１６５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ承諾指示が送信されると（Ｓ２４０１、Ｓ２４０２）、ＭＳＧ管理機構（Ａ）では、該当する被交換許諾依頼があるか否かの判定が行われる（Ｓ２４０３）。該当する被交換許諾依頼がある場合には、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する交換許諾依頼を抽出し、状況フラグの更新を行う（Ｓ２４０４）。
【０１６６】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２４０５、Ｓ２４０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２４０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２４０８、Ｓ２４０９）。
【０１６７】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼の承諾通知と公開鍵を通知機構２０へ送信する（Ｓ２４１０、Ｓ２４１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２４１２、Ｓ２４１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２４１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２４１５、Ｓ２４１６）。
【０１６８】
通知機構２０が、公開鍵交換依頼の承諾通知と公開鍵をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２４１７、Ｓ２４１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルから該当する被交換許諾依頼を抽出し、その状況フラグの更新と承諾ユーザーへの公開鍵を保存して（Ｓ２４１９）、アドレス帳管理テーブルに新規レコードを追加し（Ｓ２４２０）、結果通知を通知機構２０へ返信する（Ｓ２４２１、Ｓ２４２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２４２３、Ｓ２４２４）、ＭＳＧ管理機構（Ａ）は、アドレス帳管理テーブルに新規レコードを追加した後（Ｓ２４２５）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２４２６、Ｓ２４２７）。
【０１６９】
［被交換許諾依頼の却下］
図２５は、端末ソフトウェアの（１３）被交換許諾依頼の却下の処理の流れを示すシーケンス図である。図２５に示すように、被交換許諾依頼の却下が行われるときには、まず、端末ソフトウェア５０において、被交換許諾依頼の却下指示の入力が行われる（Ｓ２５００）。
【０１７０】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ却下指示が送信されると（Ｓ２５０１、Ｓ２５０２）、ＭＳＧ管理機構（Ａ）では、該当する被交換許諾依頼があるか否かの判定が行われる（Ｓ２５０３）。該当する被交換許諾依頼がある場合には、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する交換許諾依頼を抽出し、状況フラグの更新を行う（Ｓ２５０４）。
【０１７１】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２５０５、Ｓ２５０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２５０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２５０８、Ｓ２５０９）。
【０１７２】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼の却下通知を通知機構２０へ送信する（Ｓ２５１０、Ｓ２５１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２５１２、Ｓ２５１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２５１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２５１５、Ｓ２５１６）。
【０１７３】
通知機構２０が、公開鍵交換依頼の却下通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２５１７、Ｓ２５１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルから該当する被交換許諾依頼を抽出し、その状況フラグの更新を行って（Ｓ２５１９）、結果通知を通知機構２０へ返信する（Ｓ２５２０、Ｓ２５２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２５２２、Ｓ２５２３）、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する非交換許諾依頼を抽出し、そのレコードを削除した後（Ｓ２５２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２５２５、Ｓ２５２６）。
【０１７４】
［送信済みＭＳＧの訂正］
図２６は、端末ソフトウェアの（１４）送信済みＭＳＧの訂正の処理の流れを示すシーケンス図である。図２６に示すように、送信済みＭＳＧの訂正が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの内容の訂正指示の入力が行われる（Ｓ２６００）。
【０１７５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ訂正指示が送信されると（Ｓ２６０１、Ｓ２６０２）、ＭＳＧ管理機構（Ａ）では、該当するＭＳＧＩＤがあるか否かの判定が行われる（Ｓ２６０３）。該当するＭＳＧＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、訂正内容の更新を行う（Ｓ２６０４）。
【０１７６】
ＭＳＧ管理機構（Ａ）は、（宛先変更の場合には）送信ＭＳＧ管理テーブルに新規宛先ユーザーのレコードを追加し、不要レコードを削除して（Ｓ２６０５）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２６０６、Ｓ２６０７）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２６０８）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２６０９、Ｓ２６１０）。
【０１７７】
ＭＳＧ管理機構（Ａ）は、（宛先変更の場合）該当するユーザー宛のＭＳＧ作成通知または削除通知を通知機構２０へ送信する（Ｓ２６１１、Ｓ２６１２）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２６１３、Ｓ２６１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２６１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２６１６、Ｓ２６１７）。
【０１７８】
通知機構２０が、ＭＳＧ作成通知または削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２６１８、Ｓ２６１９）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルへ新規レコードの追加または該当するレコードの削除を行って（Ｓ２６２０）、結果通知を通知機構２０へ返信する（Ｓ２６２１、Ｓ２６２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２６２３、Ｓ２６２４）、ＭＳＧ管理機構（Ａ）は、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２６２５、Ｓ２６２６）。
【０１７９】
［送信済みＭＳＧの開示中止］
図２７は、端末ソフトウェアの（１４）送信済みＭＳＧの開示中止の処理の流れを示すシーケンス図である。図２７に示すように、送信済みＭＳＧの開示中止が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの開示中止指示の入力が行われる（Ｓ２７００）。
【０１８０】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ開示中止指示が送信されると（Ｓ２７０１、Ｓ２７０２）、ＭＳＧ管理機構（Ａ）では、該当するＭＳＧＩＤがあるか否かの判定が行われる（Ｓ２７０３）。該当するＭＳＧＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、開示フラグの更新を行う（Ｓ２７０４）。
【０１８１】
そして、ＭＳＧ管理機構（Ａ）は、送信ＭＳＧ管理テーブルから該当するＭＳＧＩＤのレコードを削除して（Ｓ２７０５）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２７０６、Ｓ２７０７）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２７０８）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２７０９、Ｓ２７１０）。
【０１８２】
つづいて、ＭＳＧ管理機構（Ａ）は、ＭＳＧ削除通知を通知機構２０へ送信する（Ｓ２７１１、Ｓ２７１２）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２７１３、Ｓ２７１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２７１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２７１６、Ｓ２７１７）。
【０１８３】
通知機構２０が、ＭＳＧ削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２７１８、Ｓ２７１９）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルから該当するレコードの削除を行って（Ｓ２７２０）、結果通知を通知機構２０へ返信する（Ｓ２７２１、Ｓ２７２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２７２３、Ｓ２７２４）、ＭＳＧ管理機構（Ａ）は、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２７２５、Ｓ２７２６）。
【０１８４】
［送信済みＭＳＧの削除］
図２８は、端末ソフトウェアの（１４）送信済みＭＳＧの削除の処理の流れを示すシーケンス図である。図２８に示すように、送信済みＭＳＧの削除が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの削除指示の入力が行われる（Ｓ２８００）。
【０１８５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ削除指示が送信されると（Ｓ２８０１、Ｓ２８０２）、ＭＳＧ管理機構（Ａ）では、該当するＭＳＧＩＤがあるか否かの判定が行われる（Ｓ２８０３）。該当するＭＳＧＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、開示フラグの更新を行う（Ｓ２８０４）。
【０１８６】
そして、ＭＳＧ管理機構（Ａ）は、送信ＭＳＧ管理テーブルから該当するＭＳＧＩＤのレコードを削除して（Ｓ２８０５）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２８０６、Ｓ２８０７）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２８０８）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２８０９、Ｓ２８１０）。
【０１８７】
つづいて、ＭＳＧ管理機構（Ａ）は、ＭＳＧ削除通知を通知機構２０へ送信する（Ｓ２８１１、Ｓ２８１２）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２８１３、Ｓ２８１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２８１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２８１６、Ｓ２８１７）。
【０１８８】
通知機構２０が、ＭＳＧ削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２８１８、Ｓ２８１９）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルから該当するレコードの削除を行って（Ｓ２８２０）、結果通知を通知機構２０へ返信する（Ｓ２８２１、Ｓ２８２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２８２３、Ｓ２８２４）、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、そのレコードを削除した後（Ｓ２８２５）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２８２６、Ｓ２８２７）。
【０１８９】
［新規ＭＳＧの作成要求に対する応答］
図２９は、ＭＳＧ管理機構の（８）新規ＭＳＧの作成要求に対する応答の処理の流れを示すシーケンス図である。図２９に示すように、新規ＭＳＧの作成要求に対する応答（グループリストの取得）が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの作成指示の入力が行われる（Ｓ２９００）。
【０１９０】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へＭＳＧ作成指示が送信されると（Ｓ２９０１、Ｓ２９０２）、ＭＳＧ管理機構（Ａ）では、該当するグループＩＤがあるか否かの判定が行われる（Ｓ２９０３）。該当するグループＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、該当するグループを管理するドメインＩＤを抽出して（Ｓ２９０４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２９０５、Ｓ２９０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２９０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２９０８、Ｓ２９０９）。
【０１９１】
つづいて、ＭＳＧ管理機構（Ａ）は、グループメンバーリストの取得要求を通知機構２０へ送信する（Ｓ２９１０、Ｓ２９１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２９１２、Ｓ２９１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２９１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２９１５、Ｓ２９１６）。
【０１９２】
通知機構２０が、グループメンバーリストの取得要求をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２９１７、Ｓ２９１８）、ＭＳＧ管理機構（Ｂ）は、グループ管理テーブルから該当するグループメンバーのユーザーＩＤ、ドメインＩＤ、公開鍵を抽出して（Ｓ２９１９）、メンバーリストを通知機構２０へ返信する（Ｓ２９２０、Ｓ２９２１）。
【０１９３】
その後、通知機構２０が、そのメンバーリストをＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２９２２、Ｓ２９２３）、ＭＳＧ管理機構（Ａ）は、メンバーリストからユーザーＩＤ、ドメインＩＤ、公開鍵を抽出して、グループ管理テーブルに追加する（Ｓ２９２４）。そして、ＭＳＧ管理機構（Ａ）は、グループメンバーごとのＭＳＧを作成ＭＳＧテーブルに追加して、それ以降は個人ＩＤと同様の処理を実行する（Ｓ２９２５）。
【０１９４】
［グループリスト作成要求］
図３０は、端末ソフトウェアの（１５）グループリスト作成要求の処理の流れを示すシーケンス図である。図３０に示すように、グループリスト作成要求が行われたときには、まず、端末ソフトウェア５０において、グループ名、参加ユーザー名、参加ユーザーのドメインＩＤ、参加ユーザーのユーザーＩＤの入力が行われる（Ｓ３０００）。
【０１９５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へグループリスト作成要求が送信されると（Ｓ３００１、Ｓ３００２）、ＭＳＧ管理機構（Ａ）では、新規のグループ名であるか否かの判定が行われる（Ｓ３００３）。新規なグループ名である場合には、ＭＳＧ管理機構（Ａ）は、グループ管理テーブルに新規レコードを追加して（Ｓ３００４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３００５、Ｓ３００６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３００７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３００８、Ｓ３００９）。
【０１９６】
つづいて、ＭＳＧ管理機構（Ａ）は、グループリスト参加依頼を通知機構２０へ送信するとともに（Ｓ３０１０）、アドレス帳管理テーブルに新規レコードを追加する（Ｓ３０１１）。
【０１９７】
通知機構２０は、グループリスト参加依頼を受信すると（Ｓ３０１２）、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３０１３、Ｓ３０１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３０１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３０１６、Ｓ３０１７）。
【０１９８】
通知機構２０が、グループリスト参加依頼をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３０１８、Ｓ３０１９）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルに新規追加を行って（Ｓ３０２０）、結果通知を通知機構２０へ返信する（Ｓ３０２１、Ｓ３０２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ３０２３、Ｓ３０２４）、ＭＳＧ管理機構（Ａ）は、グループ管理テーブルの参加ユーザーのレコードを更新した後（Ｓ３０２５）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３０２６、Ｓ３０２７）。
【０１９９】
［グループリスト削除要求］
図３１は、端末ソフトウェアの（１６）グループリスト削除要求の処理の流れを示すシーケンス図である。図３１に示すように、グループリスト削除要求が行われたときには、まず、端末ソフトウェア５０において、グループリストの削除指示の入力が行われる（Ｓ３１００）。
【０２００】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へグループリスト削除要求が送信されると（Ｓ３１０１、Ｓ３１０２）、ＭＳＧ管理機構（Ａ）では、既存のグループＩＤであるか否かの判定が行われる（Ｓ３１０３）。既存のグループＩＤである場合には、ＭＳＧ管理機構（Ａ）は、グループ管理テーブルから参加ユーザーを抽出して、状況フラグを「５」に更新して（Ｓ３１０４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３１０５、Ｓ３１０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３１０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３１０８、Ｓ３１０９）。
【０２０１】
つづいて、ＭＳＧ管理機構（Ａ）は、グループ削除通知を通知機構２０へ送信する（Ｓ３１１０、Ｓ３１１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３１１２、Ｓ３１１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３１１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３１１５、Ｓ３１１６）。
【０２０２】
通知機構２０が、グループ削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３１１７、Ｓ３１１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルの該当するグループＩＤのレコードを更新するとともに（Ｓ３１１９）、アドレス帳管理テーブルから該当するグループＩＤのレコードを削除する（Ｓ３１２０）。そして、ＭＳＧ管理機構（Ｂ）は、結果通知を通知機構２０へ返信するとともに（Ｓ３１２１）、交換許諾状況管理テーブルの該当するグループＩＤのレコードを削除する（Ｓ３１２２）。
【０２０３】
通知機構２０は、結果通知を受信すると（Ｓ３１２３）、その結果通知をＭＳＧ管理機構（Ａ）へ転送する（Ｓ３１２４、Ｓ３１２５）。ＭＳＧ管理機構（Ａ）は、グループ管理テーブルから該当するグループＩＤのレコードを削除するとともに（Ｓ３１２６）、グループ管理テーブルから該当するグループＩＤのレコードを削除した後（Ｓ３１２７）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３１２８、Ｓ３１２９）。
【０２０４】
［グループリスト参加保留中リストの取得］
図３２は、端末ソフトウェアの（１７）グループリスト参加保留中リストの取得の処理の流れを示すシーケンス図である。図３２に示すように、グループリスト参加保留中リストの取得が行われるときには、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ、グループリスト参加保留中リストの取得要求が送信される（Ｓ３２０、Ｓ３２１）。
【０２０５】
ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当するユーザーかつグループのレコードを抽出し（Ｓ３２２）、グループリスト参加保留中リストを作成する（Ｓ３２３）。ＭＳＧ管理機構（Ａ）が、作成したグループリスト参加保留中リストを端末ソフトウェア５０へ送信すると（Ｓ３２４、Ｓ３２５）、端末ソフトウェア５０は、取得したグループリスト参加保留中リストを画面に出力する（Ｓ３２６）。
【０２０６】
［グループリスト参加承諾通知］
図３３は、端末ソフトウェアの（１８）グループリスト参加承諾通知の処理の流れを示すシーケンス図である。図３３に示すように、グループリスト参加承諾通知が行われるときには、まず、端末ソフトウェア５０において、グループリストへの参加承諾指示が入力される（Ｓ３３００）。そうすると、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ承諾指示が送信される（Ｓ３３０１、Ｓ３３０２）。
【０２０７】
ＭＳＧ管理機構（Ａ）では、該当する依頼があるか否かの判定が行われ（Ｓ３３０３）、該当する依頼があると判定された場合には、交換許諾状況管理テーブルから該当する要求を抽出し、状況フラグの更新を行う（Ｓ３３０４）。
【０２０８】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３３０５、Ｓ３３０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３３０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３３０８、Ｓ３３０９）。
【０２０９】
つづいて、ＭＳＧ管理機構（Ａ）は、グループリスト参加の承諾通知と公開鍵を通知機構２０へ送信する（Ｓ３３１０、Ｓ３３１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３３１２、Ｓ３３１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３３１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３３１５、Ｓ３３１６）。
【０２１０】
通知機構２０が、グループリスト参加の承諾通知と公開鍵をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３３１７、Ｓ３３１８）、ＭＳＧ管理機構（Ｂ）は、グループ管理テーブルから該当する要求を抽出し、状況フラグの更新と承諾ユーザーの公開鍵を保存して（Ｓ３３１９）、結果通知を通知機構２０へ返信する（Ｓ３３２０、Ｓ３３２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ３３２２、Ｓ３３２３）、ＭＳＧ管理機構（Ａ）は、アドレス帳管理テーブルに新規レコードを追加した後（Ｓ３３２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３３２５、Ｓ３３２６）。
【０２１１】
［グループリスト参加拒否通知］
図３４は、端末ソフトウェアの（１８）グループリスト参加拒否通知の処理の流れを示すシーケンス図である。図３４に示すように、グループリスト参加拒否通知が行われるときには、まず、端末ソフトウェア５０において、グループリストへの参加許否指示が入力される（Ｓ３４００）。そうすると、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ拒否指示が送信される（Ｓ３４０１、Ｓ３４０２）。
【０２１２】
ＭＳＧ管理機構（Ａ）では、該当する依頼があるか否かの判定が行われ（Ｓ３４０３）、該当する依頼があると判定された場合には、交換許諾状況管理テーブルから該当する要求を抽出し、状況フラグの更新を行う（Ｓ３４０４）。
【０２１３】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３４０５、Ｓ３４０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３４０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３４０８、Ｓ３４０９）。
【０２１４】
つづいて、ＭＳＧ管理機構（Ａ）は、グループリスト参加の拒否通知を通知機構２０へ送信する（Ｓ３４１０、Ｓ３４１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３４１２、Ｓ３４１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３４１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３４１５、Ｓ３４１６）。
【０２１５】
通知機構２０が、グループリスト参加の拒否通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３４１７、Ｓ３４１８）、ＭＳＧ管理機構（Ｂ）は、グループ管理テーブルから該当する要求を抽出し、状況フラグの更新を行って（Ｓ３４１９）、結果通知を通知機構２０へ返信する（Ｓ３４２０、Ｓ３４２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ３４２２、Ｓ３４２３）、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する要求を抽出し、そのレコードを削除した後（Ｓ３４２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３４２５、Ｓ３４２６）。
【０２１６】
以上に詳述したような本実施形態のメッセージ伝送システムによれば、従来型のメッセージ伝送システムにはない優れた作用効果が奏される。以下、それらの優れた機能の例を、図面を参照して説明しておく。
【０２１７】
図３５は、本実施形態のメッセージ伝送システムにおける送信済みＭＳＧの変更・削除機能の説明図である。本メッセージ伝送システムでは、ＭＳＧを作成して送信した後（１回目の作成要求が送信され、作成通知が発行された後）であっても、送信側の端末ソフトウェア（Ａ）において、同じＭＳＧＩＤを用いてそのＭＳＧの内容を更新することができる。また、この場合、ＭＳＧの内容が更新されても、そのＭＳＧのＭＳＧＩＤは変更されない。
【０２１８】
したがって、従来型のメッセージ伝送システムでは、いったんＭＳＧを作成した後は、その内容を変更したり削除したりすることはできなかった（新たに別のＭＳＧを送り直すことしかできなかった）のに対して、本メッセージ伝送システムでは、受信者に知られることなく、送信側のＭＳＧ管理機構（Ａ）のサーバでＭＳＧの内容変更、開示中止（ＭＳＧを完全に削除するのではなく送信者だけが利用できる状態に変更）、削除（サーバからＭＳＧを完全に削除）を行うことができる。また、同一のＭＳＧＩＤを用いたままＭＳＧの内容を更新できるため、受信者に常に最新のＭＳＧを閲覧させることができる。
【０２１９】
図３６は、本実施形態のメッセージ伝送システムにおけるメーリングリストへの送信機能の説明図である。本メッセージ伝送システムでは、メーリングリストへ送信する（宛先にグループが指定された）場合に、送信側のＭＳＧ管理機構（Ａ）において、送信グループが個別のユーザーＩＤに展開され、それぞれの受信者の公開鍵で、ＭＳＧ内容が暗号化され、ユーザーＩＤごとに一意のＭＳＧＩＤを使って宛先に通知される。そして、受信側のＭＳＧ管理機構（Ｂ）では、ユーザーＩＤごとに通知された情報に基づいて、個別に取得されるＭＳＧ内容が、各受信者の秘密鍵で復号され、各ユーザーが個別にＭＳＧを閲覧することができる。
【０２２０】
したがって、従来型のメッセージ伝送システムでは、ＷＷＷサーバにファイルを保存した旨を伝えるメールをメーリングリストへの送信を行っても、限られた数の受信者（例えば先着Ｎ番目までの受信者）しかファイルをダウンロードすることができず、どの受信者がダウンロードしたかも確認することができなかったのに対して、本メッセージ伝送システムでは、送信先のグループに含まれるすべてのユーザーがＭＳＧを閲覧することができ、どのユーザーがＭＳＧを閲覧したのかを確認（開封確認）することもできる。
【０２２１】
図３７は、本実施形態のメッセージ伝送システムにおける真正な受信者への送信機能の説明図である。本メッセージ伝送システムでは、送信側のＭＳＧ管理機構（Ａ）において、受信者Ｂの承諾が得られたら（公開鍵が取得できたら）、送信者Ａのアドレス帳に受信者ＢのＩＤや公開鍵が登録される。一方、受信側のＭＳＧ管理機構（Ｂ）においては、受信者Ｂが送信者ＡとのＭＳＧ交換を承諾したら、受信者Ｂのアドレス帳に送信者ＡのＩＤや公開鍵が登録されるとともに、送信者Ａへ自分の公開鍵を通知する。また、受信側の端末ソフトウェア（Ｂ）では、ＭＳＧの転送が制限されており、秘密鍵を用いなければＭＳＧの復号をすることができないようにされている。
【０２２２】
したがって、従来型のメッセージ伝送システムでは、送信者が送信先のアドレスを間違って入力してしまったような場合、真正な受信者に送信されたかどうかわからないのに対して、本メッセージ伝送システムでは、あらかじめＭＳＧ交換許諾を与えられた相手から公開鍵を預かり、その相手としかＭＳＧ交換を行わない（ＭＳＧは受信者の公開鍵で暗号化される）ため、全く関係のない第三者や実在しない相手に対してＭＳＧの送信を行うことがなく、情報が漏洩するおそれを低減することができる。
【０２２３】
図３８は、本実施形態のメッセージ伝送システムにおける受信者の認証機能の説明図である。本メッセージ伝送システムでは、組織や企業ごとに設置され管理されるＭＳＧ管理機構のサーバが、それぞれ属するユーザーを管理（登録、変更、削除、認証等）する機能を有しており、ＩＤ管理機構のサーバは、各ＭＳＧ管理機構を管理する機能を有するが、個別のユーザー管理は行わない。送信側のＭＳＧ管理機構は、ＩＤ管理機構に管理されている受信側のＭＳＧ管理機構が受信者の認証を行うことで、間接的に受信者の認証を行えることになる。
【０２２４】
したがって、従来型のメッセージ伝送システムでは、受信者の認証が行われておらず、仮に受信者の認証を行うとすると、すべての組織や企業のユーザーの個人情報を、例えばファイルを保存するＷＷＷサーバの管理者等の第三者に管理させることになってしまうのに対して、本メッセージ伝送システムでは、各組織や企業のユーザーの個人情報は、それぞれの組織や企業に閉じて管理したままでよく、全体を管理するＩＤ管理機構を介して、他の組織や企業のサーバに認証機能を任せることで、受信者の認証を実現できる。
【０２２５】
図３９は、本実施形態のメッセージ伝送システムにおけるＭＳＧの関連付け機能の説明図である。本メッセージ伝送システムでは、送信側と受信側の双方のＭＳＧ管理機構において、送信済み／受信済みの通知情報が保持され、また、すべてのＭＳＧに対して一意のＭＳＧのＩＤが付与される（同一のＭＳＧが更新された場合には、ＭＳＧＩＤの変更は行われない）ため、ＭＳＧを関連付けて管理することができる。また、ＭＳＧへの返信の際には返信元のＭＳＧのＩＤも付与することが可能であるため、あるＭＳＧと返信元のＭＳＧとの関連付けにも対応できる。
【０２２６】
したがって、従来型のメッセージ伝送システムでは、受信者がＭＳＧを統一的に管理することが困難であり、受信日時等でソートする程度のことしかできないのに対して、本メッセージ伝送システムでは、ＭＳＧの前後関係の把握が容易になり、内容や順番で関連づけられたスレッド等によってＭＳＧを管理することも可能になる。
【０２２７】
図４０は、本実施形態のメッセージ伝送システムにおける通知の正確性担保機能の説明図である。本メッセージ伝送システムでは、送信側のＭＳＧ管理機構のサーバが通知機構のサーバに通知を行い、通知機構のサーバが受信側のＭＳＧ管理機構サーバに伝達するプロセスが採用され、それぞれのサーバはＩＤ管理機構サーバの管理下にあり、サーバ間の通知処理の結果は依頼元に報告されるため、この報告によって、通知がどの段階まで実際に行われたか、途中で通知が阻害されていた場合にはその阻害原因が何かということを、把握することができる。
【０２２８】
したがって、従来型のメッセージ伝送システムでは、メールが相手のスパムメールフィルタによってブロックされたり、ドメイン指定拒否（携帯電話のように拒否されたことも発信者に返信しないものもある）されたり、遅延によって送達が遅れたりすることがあり、確実に相手に届いたことが保証されないのに対して、本メッセージ伝送システムでは、ＭＳＧ管理機構と通知機構との間で送受信される通知は、その都度、通知処理の結果の確認が行われるため、通知機構では、通知がどの段階であるかを把握することができ、これを、送信側のＭＳＧ管理機構に把握させることもできる。
【０２２９】
最後に、図４１に、以上に説明した本実施形態のＭＳＧ管理機構サーバの具体的構造の一例を示しておく。この例では、利用者Ａ用のＭＳＧ管理機構サーバ１０が、ネットワーク６０側のフロントエンドと、端末５０側のバックエンドとから構成されており、ネットワーク６０（この例では、ＳＳＬ通信）を介して、利用者Ｘ用のＭＳＧ管理機構サーバ１０や、利用者Ｙ用のＭＳＧ管理機構サーバ１０に接続可能である。ＭＳＧ管理機構サーバ間の通信は、既述のとおり通信機構のサーバを介してもよい。ネットワーク６０におけるこれらのサーバ間は、フルメッシュ型で接続されていてもよいし、リフレクタ型で接続されていてもよい。
【０２３０】
利用者Ａの作成したＭＳＧは、バックエンドでは利用者Ａ専用のＤＢにおいて平文で保存可能であり、フロントエンドへ送られる際に、宛先の利用者ＸあるいはＹの公開鍵で暗号化される。フロントエンドにある宛先Ｘ専用のＤＢおよび／または宛先Ｙ専用のＤＢには、ＭＳＧは暗号化された状態で保存され、その暗号化されたＭＳＧを、それぞれ利用者Ｘ／利用者Ｙが閲覧することになる。このように作成者以外の利用者に開示するＭＳＧは、改ざんや第三者による利用を制限できるようにテキストデータからバイナリデータへ変換したり、一定の利用制限がかけられるファイル形式（例えばＦＬＡＳＨやＰＤＦ等）に変換したりしたものとしてもよい。
【０２３１】
さらに、ＭＳＧの作成者が、ＭＳＧの本体に自らの望む利用条件を、ＤＲＭ（ディジタル著作権管理）情報のような形式で含ませておき、ＭＳＧ管理機構サーバが、バックエンドからフロントエンドへＭＳＧを渡す際に、作成者の設定した条件に従ってフロントエンドでのＭＳＧの保存が行われるように、制御することも可能である。そうすると、例えば、ＭＳＧを利用できる有効期限がＤＲＭ情報として設定してあれば、期限切れのＭＳＧを、宛先Ｘや宛先Ｙ用のＤＢから削除することにより、ＭＳＧをいったん発行した後でも、作成者側が指定した条件を守った利用を強制することができる。また、ＭＳＧのオリジナルを一つの場所で管理するため、監査証跡を残すことも可能になる。
【０２３２】
以上、本発明の実施形態について説明してきたが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。
【図面の簡単な説明】
【０２３３】
【図１】本発明の一実施形態に係るメッセージ（ＭＳＧ）伝送システムの構成例を示す図
【図２】端末の構成例を示す図
【図３】ＩＤ管理機構のサーバの構成例を示す図
【図４】ドメイン情報管理テーブルの一例を示す図
【図５】ＭＳＧ管理機構のサーバの構成例を示す図
【図６】ユーザー管理テーブルの一例を示す図
【図７】受信ＭＳＧ管理テーブルの一例を示す図
【図８】作成ＭＳＧ管理テーブルの一例を示す図
【図９】アドレス帳管理テーブルの一例を示す図
【図１０】グループ管理テーブルの一例を示す図
【図１１】交換許諾状況管理テーブルの一例を示す図
【図１２】送信ＭＳＧ管理テーブルの一例を示す図
【図１３】通知機構２０のサーバの構成例を示す図
【図１４】統計情報テーブルの一例を示す図
【図１５】ユーザー認証の処理の流れを示すシーケンス図
【図１６】各ＭＳＧリストの取得の処理の流れを示すシーケンス図
【図１７】各ＭＳＧリストの取得結果の表示の処理の流れを示すシーケンス図
【図１８】各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図
【図１９】各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図
【図２０】新規ＭＳＧの作成の処理の流れを示すシーケンス図
【図２１】アドレス帳リストへの個別追加の処理の流れを示すシーケンス図
【図２２】アドレス帳リストへの追加要求の撤回の処理の流れを示すシーケンス図
【図２３】被交換許諾依頼保留中リストの取得の処理の流れを示すシーケンス図
【図２４】被交換許諾依頼の承諾の処理の流れを示すシーケンス図
【図２５】被交換許諾依頼の却下の処理の流れを示すシーケンス図
【図２６】送信済みＭＳＧの訂正の処理の流れを示すシーケンス図
【図２７】送信済みＭＳＧの開示中止の処理の流れを示すシーケンス図
【図２８】送信済みＭＳＧの削除の処理の流れを示すシーケンス図
【図２９】新規ＭＳＧの作成要求に対する応答の処理の流れを示すシーケンス図
【図３０】グループリスト作成要求の処理の流れを示すシーケンス図
【図３１】グループリスト削除要求の処理の流れを示すシーケンス図
【図３２】グループリスト参加保留中リストの取得の処理の流れを示すシーケンス図
【図３３】グループリスト参加承諾通知の処理の流れを示すシーケンス図
【図３４】グループリストの参加拒否通知の処理の流れを示すシーケンス図
【図３５】送信済みＭＳＧの変更・削除機能の説明図
【図３６】メーリングリストへの送信機能の説明図
【図３７】真正な受信者への送信機能の説明図
【図３８】受信者の認証機能の説明図
【図３９】ＭＳＧの関連付け機能の説明図
【図４０】通知の正確性の担保機能の説明図
【図４１】ＭＳＧ管理機構のサーバの構造の具体例を示す図
【符号の説明】
【０２３４】
１０ メッセージ管理機構サーバ
２０ 通知機構サーバ
３０ ＩＤ管理機構サーバ
４０ 統計情報統合機構サーバ
５０ 端末
６０ ネットワーク
【技術分野】
【０００１】
本発明は、送信端末からのメッセージを受信端末へ伝送するシステムと、このシステムを構成するサーバ装置に関する。
【背景技術】
【０００２】
これまで、インターネットなどの通信設備を用いたメッセージ伝送システムは、電子メールやインスタントメッセージを用いたものが一般的であった。これらの技術は、簡単な操作と即時性、標準化されたプロトコルによって、世界中のコンピュータや携帯電話で使われている。
【０００３】
これらの技術は、基本的に、送信元のサーバが、自己のサービスを受ける送信端末からのメッセージを、メッセージの宛先（送信先ともいう。）となる受信端末にサービスを提供する送信先のサーバへ、転送し、この送信先のサーバに保存されているメッセージを、受信端末がダウンロードすることで、メッセージ伝送を実現している。例えば、電子メールは、Simple Mail Transfer Protocol (RFC2821)によって送信先のサーバへ転送され、Post Office Protocol Version 3 (RFC1939)やInternet Message Access Protocol (RFC3501)によって受信端末へ送信されるのが、一般的である。
【０００４】
しかし、この方式では、添付ファイルを含む電子メール等、サイズの大きなメッセージを、複数の送信先へ伝送しようとすると、ネットワークが輻輳状態に陥りやすく、また、送信先のサーバにおいても、受信者のメールボックスの空き容量が確保できないことにより、メッセージが伝送不可能になることが頻繁に生じる。
【０００５】
特許文献１の技術では、送信側の電子メールサーバにおいて、端末から送信要求がなされた電子メールに含まれる添付ファイルを抽出して、抽出したファイルをＷＷＷサーバ上に保存し、ＷＷＷサーバのアドレスを示す情報を添付ファイルの代わりに付加した電子メールを、宛先側に送信することにより、上記の問題を解決している。
【特許文献１】特開２００２−１８３０５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、既存のメッセージ伝送システムには、特許文献１の技術によっても解決できない多くの課題が存在している。
【０００７】
例えば、既存の方式では、作成したメッセージをいったん送信してしまうと、そのメッセージについて宛先の変更や内容の修正、削除等ができないため、錯誤により別の宛先を指定して送信してしまったり、内容を間違ってしまったりした場合には、復旧することができず、送信先の個人や会社との信頼関係の毀損や、情報漏洩につながる危険性が高い。
【０００８】
そして、電子メールの特性上、通信経路上では平文でメッセージが転送されるため、秘密情報の取り扱いが難しい。これまでも、ディジタル署名によって改ざんを防止したり、添付ファイルを暗号化したりといった手法がとられてはいるが、前者を導入する場合、ディジタル署名の取得や設定変更について、全てのエンドユーザが対応できるほどの容易性はなく、後者の場合は、ファイル毎にパスワードを管理しなければならず、業務負担が増加してしまう。
【０００９】
さらに、既存の方式では、受信者の宛先情報（電子メールアドレス等）が知られると、受信者本人の意向に関わらず、一方的にメールを受信させることができてしまうため、スパムメールないし迷惑メールへの対処が、大きな問題となっている。
【００１０】
また、既存の方式では、受信者が受信したメッセージを第三者へ転送することについて制約を受けないため、メッセージの作成者が意図しない相手に転送されたり、Ｗｅｂ上に公開されたりしてしまうリスクがある。
【００１１】
なお、一つの組織内に閉じられて運用されるグループウェアであれば、上述した問題を部分的に解決することは可能かもしれないが、異なる組織間において（例えば、送信者と受信者が異なるドメインに属し、その間がインターネットで接続される場合等）、上述した問題を解決可能な仕組みは、全く知られていない。
【００１２】
本発明は、以上のような事情を考慮し、異なる組織間のメッセージ伝送においても、いったん送信したメッセージの変更や取消が可能で、メッセージ伝送における秘密性の維持が簡易に行え、安全性の高いメッセージ伝送を実現することのできる仕組みを提供することを、目的とする。
【課題を解決するための手段】
【００１３】
本発明の原理に従う一つのメッセージ伝送システムは、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバとを含む。送信側サーバは、送信者が前記第１の利用者群の一人であるかの認証を行う認証手段と、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する受信手段と、受信した前記メッセージの少なくともメッセージ本体を保存する保存手段と、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する送出手段と、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する送信手段とを備える。受信側サーバは、前記送信側サーバから送出された前記通知を保存する保存手段と、受信者が前記第２の利用者群の一人であるかの認証を行う認証手段と、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する受信手段と、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する送出手段と、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する送信手段とを備える。
【００１４】
この構成によれば、既存技術のように作成したメッセージが宛先側のサーバに転送されて全てが送信先の設備に委ねられるのではなく、送信元（送信側）のサーバから送信先（受信側）のサーバへ送信されるのは、メッセージの存在を示す通知にとどまり、実際のメッセージ本体は、メッセージの作成者あるいは送信者の側の管理が及ぶ送信元のメッセージ管理機構のサーバに保存される。受信者は、受信側のサーバが受信した通知に従って、送信側のサーバにアクセスし、そこに保存されているメッセージ本体を閲覧するということになる。なお、メッセージ本体には、メッセージの本文と添付ファイルの両方が含まれてよい。
【００１５】
しかも、上記の構成によれば、受信者の認証を、受信側のメッセージ管理機構が行うため、送信側のメッセージ管理機構は、送信者の認証さえ行えばよく、受信者の認証のための個人情報を保持する必要がない。しかも、認証の成功した受信者しか、メッセージ本体の閲覧をすることはできない。よって、送信者の属する組織やドメインと受信者の属するそれとが異なる場合でも、安全性の高いメッセージ伝送が可能になる。
【００１６】
上記のメッセージ伝送システムにおいて、前記通知が、前記メッセージの送信元についての情報を含み、受信側サーバの前記送出手段は、前記通知が含む情報に従って特定される送信元に対応する送信側サーバへ、前記取得要求を送出するようにしてもよい。
【００１７】
これにより、一つの受信側サーバが、複数の送信側サーバから、メッセージの存在を示す通知を受け取る場合にも、受信者は、それぞれのメッセージ本体が保存されている送信側サーバに適切にアクセスして、メッセージ本体を閲覧することができる。
【００１８】
上記のメッセージ伝送システムにおいて、前記通知が、前記メッセージの送信元及び／又は概要についての情報を含み、受信側サーバが、前記保存手段に保存された通知を、前記認証の成功した受信者の受信端末へ送信する手段をさらに備え、受信端末からの閲覧要求が、前記受信者を宛先とするメッセージの中から当該受信者が前記通知の内容に基づいて選択したメッセージについての閲覧要求であるようにしてもよい。ここでのメッセージの概要についての情報は、例えば、メッセージのヘッダ部分に含まれる件名でもよいし、本文部分から適当に抽出される概要でもよい。
【００１９】
これにより、受信者は、メッセージの存在を示す通知のリストを見て、本体の内容を見るべきメッセージを選択することができる。この場合、選択されたメッセージについてしか、メッセージ本体の取得要求及びそれに応答してのメッセージ本体の送信がなされないため、ネットワーク資源を有効に利用できる。
【００２０】
一方、上記のメッセージ伝送システムにおいて、受信端末からの閲覧要求が、前記受信者を宛先とする全てのメッセージについての閲覧要求であり、受信側サーバの前記送信手段は、前記受信者について保存されている全ての通知に基づいて、各通知に対応する送信側サーバから収集した前記メッセージ本体を、まとめて受信端末へ送信するものであってもよい。
【００２１】
これにより、受信者は、受信端末にメッセージ本体のコピーを残せるシステムであれば、例えば、受信端末が受信側サーバに接続可能である間にまとめて全ての新着メッセージの本体を受信して、オフラインでその内容を閲覧することが可能になる。
【００２２】
上述したように、本メッセージ伝送システムでは、送信側のサーバにメッセージ本体が保存されているので、メッセージの存在をいったん受信側のサーバへ通知してしまった後でも、受信端末が、実際にそのメッセージの本体を閲覧するために送信側のサーバへアクセスしてくる前であれば、受信者に気付かれることなく、内容の変更を行うことができる。
【００２３】
このためには、例えば、上記のメッセージ伝送システムにおいて、前記メッセージ本体の内容変更が、前記メッセージを作成した送信者から要求された場合に、送信側サーバの前記保存手段に保存されたメッセージ本体を書き換える手段を、送信側サーバがさらに備え、送信側サーバの前記送信手段は、受信側サーバからの取得要求に応答して、変更後のメッセージ本体を送信するようにすればよい。
【００２４】
このようにすると、受信者がメッセージ本体を閲覧した後に、送信者が同じメッセージ本体の内容を変更する場合も、受信端末にそのメッセージ本体のコピーを残せないシステムであれば、受信者はもはや変更後の内容しか見ることができないため、間違った内容が流布することを防止できる。なお、受信者が閲覧した後のメッセージ本体を送信者が変更する場合には、そのメッセージの存在を示す通知を再度、送信側サーバから受信側サーバへ送信するようにしてもよい。メッセージ本体の最初の保存時に送信する通知を新着通知とし、内容の変更時に送信する通知を更新通知としてもよい。
【００２５】
同様に、送信側のサーバにメッセージ本体が保存されているので、メッセージの存在をいったん受信側のサーバへ通知してしまった後でも、受信端末が、実際にそのメッセージの本体を閲覧するために送信側のサーバへアクセスしてくる前であれば、受信者に内容を知られることなく、メッセージの削除を行うことができる。
【００２６】
このためには、例えば、上記のメッセージ伝送システムにおいて、前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、送信側サーバの前記保存手段に保存されたメッセージ本体を削除する手段を、送信側サーバがさらに備え、送信側サーバの前記送信手段は、受信側サーバからの取得要求に応答して、削除されたメッセージ本体の代わりに、当該メッセージ本体が削除されたことを示すメッセージを送信するようにすればよい。
【００２７】
別の例として、上記のメッセージ伝送システムにおいて、前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、送信側サーバの前記保存手段に保存されたメッセージ本体を削除するとともに、前記メッセージに対応して送出された前記通知の訂正通知を、受信側サーバに対して送出する手段を、送信側サーバがさらに備え、受信側サーバの前記保存手段に保存されている前記通知を前記訂正通知に基づいて削除することにより、削除された前記メッセージ本体についての取得要求が受信側サーバから送出されないようにしてもよい。
【００２８】
上記の二つの例のように、メッセージの削除を可能にする場合、メッセージを完全に削除するのではなく、そのメッセージの他人への開示は止めるが、作成者自身は利用を継続できるようにしてもよい。
【００２９】
このためには、例えば、上記のメッセージ伝送システムにおいて、送信側サーバの前記受信手段により受信したメッセージを、当該メッセージに対応する通知を送出することなく、保存する第２の保存手段を、送信側サーバがさらに備え、前記メッセージを作成した送信者からの要求が、当該メッセージの受信側への伝送を中止する要求である場合に、削除された前記メッセージ本体を、前記第２の保存手段で保存するようにすればよい。
【００３０】
なお、メッセージの存在をいったん受信側のサーバへ通知してしまった後に、送信者がそのメッセージの宛先を変更する場合には、送信側のサーバが、変更前の宛先の受信者に対しては、メッセージ本体が削除されたものとして扱い（受信側からメッセージ本体の取得要求が来たときにエラーメッセージを返すか、もしくは、送信済みの通知を訂正してメッセージ本体が削除されたことが受信側に分かるようにする通知をあらかじめ送っておく）、変更後の宛先の受信者に対しては、新しいメッセージが送信端末から受信されたものとして扱う（受信側へ新着通知を送る）ようにすればよい。
【００３１】
上述したメッセージ伝送システムでは、送信側サーバが、メッセージ本体を暗号化して保存しておくことによって、情報の秘密性を保つことが可能になる。例えば、この暗号化を受信者の公開鍵で行えば、真正な受信者でない者が、送信側サーバにアクセスして、暗号化されたメッセージ本体を取得しても、これを解読するための秘密鍵がないため、内容を見ることはできない。そして、真正な受信者は、秘密鍵があれば、自身宛の全てのメッセージ本体の内容を見ることができるため、ファイルごとにパスワードを管理するような手間はかからない。
【００３２】
このためには、例えば、上記のメッセージ伝送システムにおいて、送信側サーバが、各受信者の公開鍵を記憶する記憶手段をさらに備え、送信側サーバの前記保存手段は、前記メッセージ本体を前記メッセージの宛先である受信者の前記公開鍵で暗号化して保存するものであり、受信側サーバからの取得要求に応答して送信される前記メッセージ本体が、暗号化されたものとなるようにすればよい。なお、メッセージ本体を暗号化するだけでなく、メッセージの存在を示す通知についても、暗号化して送信するようにしてもよい。また、送信側サーバと送信端末の間の通信は、別の手段で暗号化される。
【００３３】
そして、暗号化されたメッセージ本体の受信側は、一つの例では、受信端末が、その受信端末を利用する受信者の秘密鍵を記憶して、受信側サーバの前記送信手段は、前記メッセージ本体を暗号化されたまま送信し、受信端末で復号化されるようにすればよい。この例の場合、実際には、暗号化されたメッセージ本体は、送信側サーバから受信端末へ、受信側サーバを介さずに送信されても構わない。但し、このメッセージ本体の送信の契機となる取得要求については、受信側サーバから受信されたものかどうかによって、認証された受信者からの閲覧要求かどうかを、送信側サーバが区別するため、受信側サーバを介することが望ましい。
【００３４】
別の例では、受信側サーバが、前記第２の利用者群の各人の秘密鍵を記憶する記憶手段をさらに備え、受信側サーバの前記送信手段が、送信側サーバから送信された前記メッセージ本体を、当該メッセージの受信者の前記秘密鍵で復号化して、受信端末へ送信するようにする。なお、受信側サーバと受信端末の間の通信は、別の手段で暗号化される。この例の場合、受信端末で秘密鍵を管理する必要がないため、エンドユーザが何もしなくても、公開鍵方式を導入して復号化や返信のディジタル署名を行うことが可能になる。
【００３５】
上記のうち後者の例においては、前記秘密鍵の記憶手段を備える受信側サーバが、送信側サーバから送信された前記メッセージ本体を復号化して受信端末へ送信した後は、復号化した前記メッセージ本体も暗号化されたままの前記メッセージ本体も、受信側サーバ内に残さないようにすることにより、さらに情報のセキュリティを高く保つことが可能になる。つまり、同じサーバに暗号化されたメッセージ本体と秘密鍵とが一緒に保存されているという状況を作らないことにより、不正に復号化される危険性を低くすることができる。なお、この例では、受信端末は、復号化されたメッセージ本体を受信してもそのコピーを作成したり、端末外部へ転送したりすることはできず、本メッセージ伝送システムに専用の端末ソフトウェアを閉じると、復号化されたメッセージ本体は消去される。
【００３６】
また、上述したメッセージ伝送システムにおいては、メッセージ本体を暗号化する場合もしない場合も、受信側サーバ及び受信端末において、一切メッセージ本体を保存しないという運用が可能である。この運用によれば、メッセージ本体は、送信者が明示的に削除しない限り、送信側サーバに保存され続けており、受信側サーバには、メッセージの存在を示す通知（過去に受信して既にメッセージ本体を閲覧した通知を含む）のリストだけが保存されている。受信者は、受信側サーバに保存されている通知のリストを見て、再度メッセージ本体を閲覧したくなれば、その都度、送信側サーバにアクセスして、閲覧すればよい。なお、受信者は、受信側サーバに保存されている通知を削除することはでき、送信者は、上述したように送信側サーバに保存されているメッセージ本体を変更、削除することができる。
【００３７】
このようにすれば、受信者が、メッセージ本体もしくはコピーを第三者へ渡すことはできず、また、通知についても、第三者へ転送することはできない（仮に、第三者が転送された通知を用いて送信側サーバにアクセスしようとしても、そのような取得要求を送出してくるのは、本メッセージ伝送システムを構成する受信側サーバではないため、送信側サーバが受け付けない）ため、メッセージの作成者ないし送信者が、メッセージの伝送後も、そのメッセージの内容の配布や公開についてコントロールし続けることが可能である。
【００３８】
公開鍵方式による暗号化を行う上記のメッセージ伝送システムにおいて、送信側サーバが、前記第１の利用者群の利用者毎に前記公開鍵の記憶手段を有し、前記第１の利用者群の一人である送信者の前記記憶手段に公開鍵が記憶されていない新規受信者に対して、当該送信者からのメッセージを伝送するために、少なくとも前記送信者の情報を含む許諾依頼を前記新規受信者の利用する受信端末へ送信し、この許諾依頼に応答して前記受信端末から承諾通知が返信されてきた場合に、前記新規受信者の公開鍵を前記記憶手段に登録するようにしてもよい。ここでの許諾依頼と承諾通知は、受信側サーバを介して通信されてもよい。また、登録される新規受信者の公開鍵は、受信側から返信される承諾通知に含まれていてもよいし、承諾通知を受信した送信側サーバが第三者機関から入手してもよい。
【００３９】
このようにすると、送信端末で通信相手の公開鍵を管理する必要がなく、送信側サーバにおいて自動的に、通信相手の了解を取りつつ入用な公開鍵を収集できるため、エンドユーザが何もしなくても、公開鍵方式を導入して暗号化や返信のディジタル署名の検証を行うことが可能になる。
【００４０】
さらに、受信側サーバが、前記第２の利用者群の利用者毎に、各送信者の公開鍵を記憶する記憶手段をさらに備え、前記許諾依頼を前記受信端末へ転送する際に、この許諾依頼を一時記憶しておき、前記許諾依頼に応答する承諾通知を前記送信側サーバへ転送する際に、前記送信者の公開鍵を前記記憶手段に登録するようにしてもよい。登録される送信者の公開鍵は、送信側から受け取った許諾依頼に含まれていてもよいし、許諾依頼に対する承諾通知を送信する受信側サーバが第三者機関から入手してもよい。
【００４１】
このようにすると、許諾依頼と承諾通知という一度の往復により、送信者と受信者との間の両方向の鍵交換プロセスを済ませることができる。もちろん、受信者は送信者からのメッセージを受け取る意思がある（送信側サーバに受信者の公開鍵が登録される）が、送信者は受信者からの返信メッセージを受け取る意思がない（受信側サーバに送信者の公開鍵は登録されない）という場合もあるため、許諾依頼と承諾通知の一度の往復で、鍵交換プロセスの片方向のみが実行されるようにしてもよい。
【００４２】
ここで、送信側サーバが、送信端末から受信したメッセージの宛先が前記記憶手段に公開鍵が記憶されていない受信者である場合には、前記通知を送出しないことにしてもよい。これにより、送信者が、誤って意図しない相手を宛先としてメッセージを送信してしまうことがなくなる。
【００４３】
さらに、受信側サーバが、本メッセージ伝送システムを構成する送信側サーバからのものでない通知を受信した場合、これを保存しないようにしてもよい。これにより、受信者は、あらかじめ承諾した送信者からのメッセージに係る通知しか受け取らないことになるため、スパムメールを受信しなくて済むことになる。
【００４４】
また、受信者が、送信者の方に受信者からのメッセージを受け取る意思がないならば、その送信者からのメッセージは受け取らないという方針をとる場合、受信側サーバは、受信した通知の送信者の公開鍵が当該受信者の前記記憶手段に記憶されていなければ、通知を保存しないという処理をしてもよい。
【００４５】
なお、送信側サーバは、送信端末から受信したメッセージが、公開鍵の記憶されていない受信者宛であったり、本メッセージ伝送システムの受信側サーバが存在しないドメイン宛であったりした場合に、既存方式のメッセージ（例えば、ＷＷＷサーバのアドレスを示す情報を添付ファイルの代わりに付加した電子メール等）を送信するようにしてもよい。
【００４６】
上記のメッセージ伝送システムにおいて、送信側サーバの前記受信手段が受信したメッセージの宛先情報が、複数の受信者を含む場合に、送信側サーバは、前記メッセージの少なくともメッセージ本体を前記受信者の数だけコピーして前記保存手段に保存し、各受信者に対応する受信側サーバからの取得要求が、それぞれの受信者のタイミングで前記送信側サーバに受信され、それぞれの保存場所に保存されている前記メッセージ本体のコピーの各受信側サーバへの送信も、対応したそれぞれのタイミングで行われるようにしてもよい。
【００４７】
これにより、一つのメッセージを複数の受信者（メーリングリストのようなグループに属する受信者であってもよい）に伝送することが可能になる。特に、メッセージ本体を受信者の数だけコピーして保存し、それぞれのコピーについて個別の受信者との対応をとっておく（通知に含まれる、メッセージの保存場所を特定可能な情報も、受信者毎に異なるものとなる）ことにより、どの受信者が取得要求によりメッセージ本体を閲覧したのかを、送信側サーバで確認することができる。
【００４８】
さらに、送信側サーバは、各受信者の公開鍵を記憶する記憶手段を備え、送信側サーバの前記保存手段は、前記メッセージ本体の複数のコピーをそれぞれ対応する受信者の前記公開鍵で暗号化して保存し、前記各受信側サーバからの取得要求に応答して送信される前記メッセージ本体のコピーが、暗号化されたものとなるようにしてもよい。
【００４９】
上述したように、本メッセージ伝送システムでは、送信側のサーバにメッセージ本体が保存されており、受信端末が閲覧する際には、送信側のサーバにアクセスすることになるので、受信側から開封確認メッセージを送信することなく、送信側のサーバで、開封確認に類する確認を行うことが可能になる。また、一つのメッセージを複数の受信者に伝送する場合、受信者毎に開封確認を行うこともできる。
【００５０】
そこで、上記のメッセージ伝送システムにおいて、送信側サーバが、受信側サーバからの取得要求に応答して前記メッセージ本体を送信したことに基づいて、当該メッセージ本体をその宛先の受信者が取得したことを、前記メッセージを作成した送信者に対して知らせる手段をさらに備えるようにしてもよい。これにより、送信側のサーバで行われた開封確認を、送信端末に伝えることが可能になる。
【００５１】
送信端末へ、その送信者が過去に送信したメッセージの状況（受信側へ通知済み、受信側の開封済み、受信側への開示停止、メッセージの削除等）を伝える方法は、送信端末が、過去に送信したメッセージのリストの提示を送信側サーバに要求した際でもよいし、送信端末からの要求がなくても、状況が変化したときに送信端末が送信側サーバに接続されていれば、教えるようにしてもよい。
【００５２】
上記のメッセージ伝送システムにおいて、前記メッセージの保存場所を特定可能な情報として、それぞれのメッセージに対して一意に付与されるメッセージ識別子を用い、メッセージ本体が書き換えられても、一旦付与されたメッセージ識別子は不変であるようにしてもよい。
【００５３】
上述したメッセージ伝送システムの運用例では、メッセージ本体は、送信者が明示的に削除しない限り、送信側サーバに保存され続けており、受信側サーバには、メッセージの存在を示す通知（過去に受信して既にメッセージ本体を閲覧した通知を含む）のリストが保存されており、送／受信双方のサーバで、同じメッセージ識別子を用いて、メッセージの本体／通知を保持するから、メッセージの履歴を系統立てて管理することが可能になる。
【００５４】
さらに、メッセージ識別子を用いる上記のメッセージ伝送システムにおいて、受信端末へメッセージ本体が送信されたメッセージへの返信メッセージが、前記受信者により作成される場合、受信側サーバの前記保存手段に保存されている通知のうち前記メッセージに対応する通知を参照することにより、前記返信メッセージに前記メッセージのメッセージ識別子を含ませることが可能となるようにしてもよい。
【００５５】
これにより、あるメッセージへの返信メッセージは、返信元のメッセージの識別子も保持するため、メッセージのスレッド管理（メッセージ同士の前後関係あるいは依存関係の把握）を容易にすることができる。
【００５６】
上記のメッセージ伝送システムが、前記第１及び第２のメッセージ管理機構が登録される全体管理サーバをさらに含み、送信側サーバは、前記第２のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、受信側サーバへの通信を行い、受信側サーバは、前記第１のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、送信側サーバへの通信を行うようにしてもよい。
【００５７】
これにより、全体管理サーバに、それぞれの組織あるいはドメインに対応するメッセージ管理機構のサーバを登録し、各メッセージ管理機構で自組織あるいはドメインのユーザーを管理するという分散管理が可能になり、異なるドメイン名をもつ組織間でのメッセージ交換を実現することができるようになる。つまり、各メッセージ管理機構のサーバは、通信先の他のサーバが、本メッセージ伝送システムを構成するメッセージ管理機構サーバであるのかどうかを、全体管理サーバに問い合わせることによって知ることができる。
【００５８】
上記のメッセージ伝送システムが、送信側サーバと受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、前記仲介サーバは、送信側サーバ及び受信側サーバのそれぞれと確認信号を交換することにより、送信側サーバから送出された前記通知が受信側サーバに受信されたかを、送信側サーバと受信側サーバの双方が確認できるようにする手段を備えてもよい。
【００５９】
このような確認を仲介サーバが行うことにより、送信側サーバから受信側サーバへの通知が、どの段階まで実際に行われ、途中で止まっているとすればその原因は何かということを、送信側サーバに把握させることができる。この例で確認の対象としているのは、メッセージの存在を示す通知であるが、送信側サーバから受信側サーバへの通信という観点から、公開鍵登録の際の許諾依頼を確認の対象としてもよいし、逆方向の受信側サーバから送信側サーバへの通信である、公開鍵登録の際の承諾通知を確認の対象としてもよい。
【００６０】
この仲介サーバも、上記の全体管理サーバに登録されるようにし、送信側サーバと受信側サーバは、通信先のサーバが、本メッセージ伝送システムを構成する仲介サーバであるのかどうかを、全体管理サーバに問い合わせるようにしてもよい。
【００６１】
また、仲介サーバとメッセージ管理機構サーバとの間の通信を暗号化することにより、メッセージの存在を示す通知、許諾依頼、承諾通知についても、暗号化して通信することが可能である。メッセージ本体については、上述したような公開鍵方式による別の暗号化が可能であるため、仲介サーバを通さずに、別の通信経路で送信側サーバから受信側へ送信しても構わない。
【００６２】
上記のメッセージ伝送システムが、送信側サーバと受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、前記仲介サーバは、送信側サーバから受信側サーバへの前記通知についての処理を記録することにより、前記メッセージ伝送システムの利用状況の監視を可能にする手段を備えてもよい。
【００６３】
これにより、送信側サーバと受信側サーバとの間の通信について、ログをとることが可能になり、このログを統計情報として処理し、本メッセージ伝送システム全体の管理に役立てることが可能になる。
【００６４】
上述した本発明はいずれも、メッセージ伝送システムを構成する各サーバ装置の発明としても、各サーバ装置が行う方法の発明としても、メッセージ伝送システム全体が行う方法の発明としても、成立するものである。また、これらの各装置あるいはシステムとしてコンピュータあるいはコンピュータ群を機能させるためのプログラムの発明や、このようなプログラムを記録した記録媒体の発明としても、勿論成立するものである。
【００６５】
例えば、本発明の一つの態様に係るサーバ装置は、送信側のサーバ機能と受信側のサーバ機能を利用してメッセージを伝送するシステムの構成要素となるサーバ装置であって、当該サーバ装置が実現するメッセージ管理機構の利用者群の各利用者の情報を登録する登録手段と、送信者が登録された前記利用者であるかの認証を行う第１の認証手段と、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する第１の受信手段と、受信した前記メッセージの少なくともメッセージ本体を保存する第１の保存手段と、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する第１の送出手段と、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する第１の送信手段と、送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存する第２の保存手段と、受信者が登録された前記利用者であるかの認証を行う第２の認証手段と、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する第２の受信手段と、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する第２の送出手段と、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する第２の送信手段と、を備える。
【００６６】
また例えば、本発明の一つの態様に係るメッセージ伝送方法は、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、により実行され、前記送信側サーバが、送信者が前記第１の利用者群の一人であるかの認証を行い、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信し、受信した前記メッセージの少なくともメッセージ本体を保存し、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出し、前記受信側サーバは、前記送信側サーバから送出された前記通知を保存し、受信者が前記第２の利用者群の一人であるかの認証を行い、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信し、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出し、前記送信側サーバは、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信し、前記受信側サーバは、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する。
【００６７】
本発明のある態様に係るソフトウェアは、コンピュータに組み込まれることによって、該コンピュータを、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、送信側サーバとして機能させるものであって、送信者が前記第１の利用者群の一人であるかの認証を行うためのプログラムコードと、前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信するためのプログラムコードと、受信した前記メッセージの少なくともメッセージ本体を保存するためのプログラムコードと、前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出するためのプログラムコードと、前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信するためのプログラムコードと、を備える。本発明のこの態様は、このソフトウェアをコンピュータに組み込むことにより出現する送信側サーバ装置の発明としても把握される。
【００６８】
本発明の別の態様に係るソフトウェアは、コンピュータに組み込まれることによって、該コンピュータを、第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、受信側サーバとして機能させるものであって、前記送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存するためのプログラムコードと、受信者が前記第２の利用者群の一人であるかの認証を行うためのプログラムコードと、前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信するためのプログラムコードと、前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出するためのプログラムコードと、前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信するためのプログラムコードと、を備える。本発明のこの態様は、このソフトウェアをコンピュータに組み込むことにより出現する受信側サーバ装置の発明としても把握される。
【発明の効果】
【００６９】
以上のとおりであるから、本発明によれば、いったん送信したメッセージの変更や取消が可能で、メッセージ伝送における秘密性の維持が簡易に行え、安全性の高いメッセージ伝送を実現することが可能になる。
【発明を実施するための最良の形態】
【００７０】
以下、本発明の実施の形態について、図面を用いて説明する。本実施形態では、電子メール等のメッセージを伝送するシステムの場合を例示する。
［システム全体］
図１は、本実施形態のメッセージ伝送システム全体の構成例を示す図である。図１に示すように、本メッセージ伝送システムは、ドメイン内のユーザー情報の管理やメッセージ（以下、ＭＳＧという）を管理するＭＳＧ管理機構１０−１、１０−２（これらのそれぞれを、あるいは、これらをまとめて、ＭＳＧ管理機構１０ということもある）のサーバと、各ドメイン間でＭＳＧの作成通知やユーザーの公開鍵の伝達を行う通知機構２０のサーバと、このＭＳＧ管理機構１０と通知機構２０の完全修飾ドメイン名（以下、ＦＱＤＮという）を管理するＩＤ管理機構３０のサーバと、端末ソフトウェア５０−１、５０−２（これらをまとめて端末ソフトウェア５０ということもある）がインストールされている端末で構成される。本メッセージ伝送システムを構成する複数のサーバの間は、例えばＴＣＰ／ＩＰのようなネットワーク６０で接続される。
【００７１】
図１の例では、説明の便宜のため、二つのＭＳＧ管理機構１０−１、１０−２と二つの端末ソフトウェア５０−１、５０−２が図示されているが、一つのＭＳＧ管理機構に多数の端末ソフトウェアが接続することや、一つのＭＳＧ管理機構が複数のＭＳＧ管理機構のそれぞれへＭＳＧを送信したり、一つのＭＳＧ管理機構が複数のＭＳＧ管理機構のそれぞれからＭＳＧを受信したりすることは、勿論可能である。また、図１の例では、一つの通知機構２０が図示されているが、多数のＭＳＧ管理機構がある場合、通知機構を複数設けて、ＭＳＧ管理機構間の仲介機能を分担させてもよく、あるＭＳＧ管理機構から別のＭＳＧ管理機構までの間に、二つ以上の通知機構が介在するようにしてもよい。
【００７２】
以下、一方のＭＳＧ管理機構１０−１に対応するドメインのユーザーから、他方のＭＳＧ管理機構１０−２に対応するドメインのユーザーへ、ＭＳＧ（例えば電子メール）が伝送されるときの動作について概略を説明する（本発明の特徴的な動作については、図面を用いて後述する）。
【００７３】
この例では、送信元（送信側）のＭＳＧ管理機構１０−１のサーバが、本発明の第１のメッセージ管理機構の送信側サーバに相当し、送信先（受信側）のＭＳＧ管理機構１０−２のサーバが、本発明の第２のメッセージ管理機構の受信側サーバに相当する。また、通知機構２０のサーバが、本発明の仲介サーバに相当し、ＩＤ管理機構３０のサーバが、本発明の全体管理サーバに相当する。さらに、端末ソフトウェア５０−１がインストールされている端末が、本発明における送信端末に相当し、端末ソフトウェア５０−２がインストールされている端末が、本発明の受信端末に相当する。
【００７４】
この場合、作成されるＭＳＧは、作成者ユーザーのドメイン内にあるＭＳＧ管理機構１０−１に登録され、送信先のユーザーを管理するＭＳＧ管理機構１０−２に対して、ＭＳＧのヘッダー情報が通知される。このヘッダー情報には、少なくとも送信元ユーザーのドメインＩＤ及びユーザーＩＤ、送信先となるユーザーのドメインＩＤ及びユーザーＩＤ、件名、概要、送信日時、ＭＳＧＩＤ（ＭＳＧごとにユニークなＩＤ）が含まれる。ただし、ＭＳＧ本文や添付ファイルは、ＭＳＧ管理機構１０−２に通知される情報には含まれていない。そのため、これらを利用する場合は、送信元ユーザーのドメインにあるＭＳＧ管理機構１０−１に対して、送信先となったＭＳＧ管理機構１０−２が、送信先となっているユーザーのドメインＩＤ、ユーザーＩＤ、当該ＭＳＧＩＤを通知して、ＭＳＧ本文や添付ファイルを都度取得する。このようにして、ＭＳＧ本文や添付ファイルが、送信先ユーザーの端末ソフトウェア５０−２に提供される。
【００７５】
送信先として指定できるユーザーＩＤは、ＭＳＧ作成に先立ち、当該ユーザーの許諾を得て、相互に公開鍵とともに受け渡しを行う必要がある。ここで交換したユーザーＩＤと公開鍵は、それぞれのＭＳＧ管理機構１０−１、１−２に保持され、ユーザーごとのアドレス帳に相手先となるユーザーのドメインＩＤとユーザーＩＤが登録される。ＭＳＧ本文及び添付ファイルは、ここで取得した公開鍵を用いて暗号化された状態で、後から来る取得要求に応じて伝送される。取得要求に先立って送信されるヘッダー情報を、上記の公開鍵を用いて暗号化してもよい。
【００７６】
以下には、本実施の形態のメッセージ伝送システムの各構成要素について、図面を参照して詳しく説明する。
【００７７】
［端末ソフトウェア］
まず、端末ソフトウェア５０がインストールされた端末（単に端末５０ともいう）の構成について、図２を参照しながら、この端末ソフトウェア５０によって実現される機能とともに、説明する。
【００７８】
（１）ＳＳＬによる暗号化通信と認証トークンの利用
図２は、端末５０の構成例を示す図である。図２に示すように、端末５０は、暗号化・認証部５１０を備えている。この暗号化・認証部５１０によって、端末ソフトウェア５０とＩＤ管理機構３０のサーバ、ＭＳＧ管理機構１０のサーバとの間の通信に、ＳＳＬを用いた暗号通信が適用される。また、ＭＳＧ管理機構１０との通信の際は、当該ユーザーのドメインＩＤ及びユーザーＩＤ、認証済みトークンを用いて識別（以下、ユーザー識別情報）が行われる。
【００７９】
（２）ユーザー認証
端末５０は、入出力部５２０と認証処理部５３０と名前解決要求部５３５を備えている。この入出力部５２０は、端末ソフトウェアの起動後、ユーザーからユーザーのドメインＩＤ、ユーザーＩＤ及びパスワードの入力を受け付け、認証処理部５３０に送り、ユーザー認証処理を行わせる。また、認証処理部５３０は、名前解決要求部５３５に対して、ＭＳＧ管理機構１０のＦＱＤＮを要求する。名前解決要求部５３５は、入力されたドメインＩＤをＩＤ管理機構３０に通知し、当該ドメインのＭＳＧ管理機構１０−１のＦＱＤＮを取得し、認証処理部５３０に返す。認証処理部５３０は、取得したＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザーＩＤ及びパスワードを通知し、認証結果（ＯＫ又はＮＧ）及び認証済みトークンを取得する。
【００８０】
（３）各ＭＳＧリストの取得
端末５０は、ＭＳＧリスト取得部５４０を備えている。認証結果がＯＫとなって認証が得られた場合、ＭＳＧリスト取得部５４０は、同ＭＳＧ管理機構１０−１に対して、ユーザーＩＤを通知し、受信ＭＳＧリスト、送信済みＭＳＧリスト、下書き保存済みリストの要求を行い、各ＭＳＧリストを取得する。以下、各ＭＳＧリストの内容について詳しく説明する。
【００８１】
（４）受信ＭＳＧリストの項目
受信ＭＳＧリストは、当該ユーザー宛に作成されたＭＳＧの一覧である。この受信ＭＳＧリストには、少なくとも送信元ユーザーのユーザー識別情報、件名、送信日時、送信先となるユーザーのドメインＩＤ及びユーザーＩＤ、ＭＳＧごとに一意のＩＤ、過去のＭＳＧに対する返信の場合は、関連づけられた過去のすべてのＭＳＧＩＤが含まれる。
【００８２】
（５）送信ＭＳＧリストの項目
送信済みＭＳＧリストは、当該ユーザーが過去に送信したＭＳＧの一覧である。この送信済みＭＳＧリストには、少なくとも送信先となるユーザーのユーザー識別情報、件名、送信日時、ＭＳＧ本文、添付ファイルのＵＲＩ、ＭＳＧごとに一意のＩＤ、過去のＭＳＧに対する返信の場合は、関連づけられた過去のすべてのＭＳＧＩＤが含まれる。そのＭＳＧの本文が送信先ユーザーの取得要求に応じて伝送済みかどうかを示す開封フラグがさらに含まれてもよい。
【００８３】
（６）下書き保存済みＭＳＧリストの項目
下書き保存済みＭＳＧリストは、当該ユーザーが作成途中で保存した下書きＭＳＧの一覧である。この下書き保存済みＭＳＧリストには、少なくともすでに入力された送信先となるユーザーのユーザー識別情報、件名、保存日時、ＭＳＧ本文、添付ファイルのＵＲＩ、ＭＳＧごとに一意のＩＤと過去のＭＳＧに対する返信の場合は、関連づけられた過去のすべてのＭＳＧＩＤが含まれる。
【００８４】
（７）各ＭＳＧリストの取得結果の表示
ＭＳＧリスト取得部５４０で取得した各ＭＳＧリストは、入出力部５２０に渡され、画面に出力される。
【００８５】
（８）各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示
端末５０は、ＭＳＧ取得部５５０とＭＳＧ処理部５５５を備えている。入出力部５２０において、各ＭＳＧリストに含まれる特定のＭＳＧＩＤがユーザーによって選択された場合には、当該ＭＳＧＩＤと当該ＭＳＧのドメインＩＤが、ＭＳＧ取得部５５０に渡される。このＭＳＧ取得部５５０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ＭＳＧ取得要求を行うユーザーのユーザー識別情報、当該ＭＳＧＩＤを通知し、ＭＳＧ本文及び添付ファイルのＵＲＩを要求する。また、ＭＳＧ処理部５５５は、取得したＭＳＧ本文及び添付ファイルのＵＲＩを入出力部５２０に渡して画面に出力させる。
【００８６】
（９）新規ＭＳＧの作成
端末５０は、アドレス帳リスト取得部５６０を備えている。入出力部５２０において、ユーザーからＭＳＧの作成指示を受けた場合に、アドレス帳リスト取得部５６０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報を通知し、当該ユーザーのＭＳＧ交換可能な相手先ユーザーのドメインＩＤ及びユーザーＩＤの一覧となるアドレス帳リストを取得して、入出力部５２０に渡して画面に出力させる。また、このアドレス帳リスト取得部５６０は、出力されたアドレス帳リストの中から相手先となるユーザーＩＤを指定し、件名、本文、添付ファイルを入出力部５２０で受け付けて、ＭＳＧ処理部５５５に渡す。ＭＳＧ処理部５５５は、入力または指定された項目をＭＳＧ管理機構１０−１のＦＱＤＮに対して、新規ＭＳＧ作成を要求し、要求結果（ＯＫまたはＮＧ）を取得する。要求結果がＯＫだった場合、ＭＳＧ処理部５５５は、上記（８）と同様に送信済みＭＳＧリストを再取得し、画面表示を更新する。
【００８７】
（１０）アドレス帳リストへの個別追加
端末５０は、交換許諾依頼発行部５７０と交換許諾リスト取得部５７５を備えている。アドレス帳リストに送信したい相手先となるユーザーのドメインＩＤ及びユーザーＩＤが含まれていない場合は、入出力部５２０にて新規に追加したい相手先ユーザーのドメインＩＤとユーザーＩＤを入力させ、入力されたドメインＩＤとユーザーＩＤが交換許諾依頼発行部５７０に渡される。交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報と入力された相手方となるドメインＩＤ及びユーザーＩＤのアドレス帳リストへの追加を要求する。ここで要求した相手先ユーザーのドメインＩＤ及びユーザーＩＤのうち、アドレス帳リストに登録されていないユーザー情報の取得を要求された場合、交換許諾リスト取得部５７５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報を通知し、交換許諾依頼中リストを取得し、入出力部５２０に渡して、画面に出力させる。
【００８８】
（１１）アドレス帳リストへの追加要求の撤回
交換許諾依頼中リストに含まれる相手先ユーザーへの要求の撤回指示について入出力部５２０が受けた場合、交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報と当該相手先ユーザーのドメインＩＤ及びユーザーＩＤ、要求の撤回指示を通知する。その後、交換許諾依頼発行部５７０は、上記（１０）と同様に交換許諾中リストを再取得し、画面表示を更新する。
【００８９】
（１２）被交換許諾依頼保留中リストの取得
当該ログイン中ユーザーへの被交換許諾依頼保留中リスト（相手方から公開鍵の交換を要求され、承諾や却下等の回答を保留しているリスト）の取得要求があった場合、交換許諾リスト取得部５７５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報を通知し、被交換許諾依頼保留中リストを取得して、入出力部５２０に渡して、画面に表示させる。
【００９０】
（１３）被交換許諾依頼の承諾または却下
端末５０は、交換許諾依頼処理部５８０を備えている。被交換許諾依頼保留中リストに含まれるユーザーのドメインＩＤ及びユーザーＩＤを指定し、承諾または却下の指示について入出力部５２０が受けた場合、交換許諾依頼処理部５８０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報と対象となる依頼元ユーザーのドメインＩＤ及びユーザーＩＤ、許諾又は却下の指示を通知する。その後、交換許諾依頼処理部５８０は、上記（１２）と同様に被交換許諾依頼保留中リストを再取得し、画面表示を更新する。
【００９１】
（１４）送信済みＭＳＧの訂正、開示中止、削除
送信済みＭＳＧリストに含まれるＭＳＧＩＤが指定され、当該ＭＳＧの送信先、件名、本文、添付ファイルについての訂正または開示中止、削除を入出力部５２０が受けた場合、ＭＳＧ処理部５５５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、当該ユーザーのユーザー識別情報、当該ＭＳＧＩＤ、入力または指定された項目内容と訂正または開示中止もしくは削除の指示を要求し、要求結果（ＯＫまたはＮＧ）を取得する。ＭＳＧ処理部５５５は、要求結果がＯＫだった場合、上記（８）と同様に送信済みＭＳＧリスト及び下書きＭＳＧリストを再取得し、画面表示を更新する。
【００９２】
（１５）グループリスト作成要求
複数のユーザーＩＤを指定して送信先として指定できるようにするグループリスト（例えばメーリングリスト）の作成要求について入出力部５２０が受けた場合、交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報とグループ名、参加させたいすべてのユーザーのドメインＩＤ及びユーザーＩＤ並びにユーザー名を「グループリスト作成要求」として通知する。
【００９３】
（１６）グループリスト削除要求
グループリストの削除要求について入出力部５２０が受けた場合、交換許諾依頼発行部５７０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、ユーザー識別情報とグループ名を「グループリスト削除要求」として通知する。
【００９４】
（１７）グループリスト参加保留中リストの取得
当該ログイン中ユーザーへのグループリスト参加保留中リスト（グループ管理者からグループリストへの参加を要求され、承諾や拒否等の回答を保留しているリスト）の取得要求があった場合、交換許諾リスト取得部５７５は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報を通知し、グループリスト参加保留中リストを取得して、入出力部５２０に渡して、画面に表示させる。
【００９５】
（１８）グループリスト参加の承諾または拒否
グループリストへの参加の承諾または拒否の指示について入出力部５２０が受けた場合、交換許諾依頼処理部５８０は、ＭＳＧ管理機構１０−１のＦＱＤＮに対して、要求しているユーザーのユーザー識別情報と対象となるグループのドメインＩＤ及びグループＩＤ、許諾又は拒否の指示を通知する。
【００９６】
［ＩＤ管理機構］
つぎに、ＩＤ管理機構３０のサーバの構成について説明する。以下、ＩＤ管理機構３０のサーバの各構成を、図３および図４を参照しながら、このサーバの機能と対応させて説明する。
【００９７】
（１）ＳＳＬによる暗号化通信
図３は、ＩＤ管理機構３０のサーバの構成例を示す図である。図３に示すように、ＩＤ管理機構３０のサーバは、暗号化・認証部３１０を備えている。この暗号化・認証部３１０によって、ＩＤ管理機構３０と端末ソフトウェア５０、ＭＳＧ管理機構１０、通知機構２０との間の通信に、ＳＳＬを用いた暗号通信が適用される。
【００９８】
（２）ＭＳＧ管理機構のＦＱＤＮ応答
ＩＤ管理機構３０のサーバは、名前解決処理部３１５とドメイン情報処理部３２０とドメイン情報保管部３３０を備えている。名前解決処理部３１５が、端末ソフトウェアまたはＭＳＧ管理機構もしくは通知機構からドメイン名と各機構のＦＱＤＮ要求を取得した場合は、ドメイン情報処理部３２０が、ドメイン情報保管部３３０の管理する「ドメイン情報管理テーブル」から、ドメイン名を検索キーにして、対応するドメインＩＤ、ＭＳＧ管理機構のＦＱＤＮ、通知機構のＦＱＤＮのうち要求される項目を抽出し、要求元に応答を返す。
図４は、ドメイン情報管理テーブルの一例を示す図である。図４に示すように、ドメイン情報管理テーブルには、ドメイン情報ごとに、ドメイン名、ドメインＩＤ、ＭＳＧ管理機構１０のＦＱＤＮ、ＭＳＧ管理機構１０の公開鍵、通知機構２０のＦＱＤＮ、管理者のＩＤなどの情報が記録されている。
【００９９】
［ＭＳＧ管理機構］
つづいて、ＭＳＧ管理機構１０のサーバの構成について説明する。以下、ＭＳＧ管理機構１０のサーバの各構成を、図５〜図１２を参照しながら、このサーバの機能と対応させて説明する。
【０１００】
（１）ＳＳＬと公開鍵による暗号化通信
図５は、ＭＳＧ管理機構１０のサーバの構成例を示す図である。図５に示すように、ＭＳＧ管理機構１０のサーバは、二つの暗号化・認証部（サーバ間の暗号化・認証部１１０と、端末との間の暗号化・認証部１１５）を備えている。これらの暗号化・認証部１１０、１１５によって、ＭＳＧ管理機構１０と端末ソフトウェア５０、ＩＤ管理機構３０、通知機構２０との間の通信に、ＳＳＬを用いた暗号通信が適用される。
送信元のＭＳＧ管理機構１０−１から通知機構２０を介して、送信先のＭＳＧ管理機構１０−２に送信されるすべての通知は、ヘッダー部とデータ部の二つで構成される。ヘッダー部には、少なくとも送信元ドメインＩＤと送信先ドメインＩＤ、データ部のハッシュ値、送信日時が含まれる。また、データ部には、少なくとも送信元ユーザーＩＤや送信先ユーザーＩＤ、通知本文が含まれる。データ部は、ＩＤ管理機構３０から取得する送信先ドメインのＭＳＧ管理機構１０の公開鍵で暗号化される。
【０１０１】
（２）ユーザー認証及び認証済みトークンの発行
ＭＳＧ管理機構１０のサーバは、利用者情報処理部１２０と利用者情報保管部１２２を備えている。端末ソフトウェア５０からユーザーのドメインＩＤ及びユーザーＩＤ、パスワードが通知され、認証要求を取得した場合、利用者情報処理部１２０は、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から、当該ユーザーＩＤを検索キーにし、パスワードの照合を行う。通知されたパスワードと「ユーザー管理テーブル」に記録されたパスワードが同一である場合は、認証済みトークンを発行し、端末ソフトウェアに認証結果（ＯＫ又はＮＧ）とともに応答が返される。ここで発行した認証済みトークン及び有効期限は、上記の「ユーザー管理テーブル」に保存される。
図６は、ユーザー管理テーブルの一例を示す図である。図６に示すように、ユーザー管理テーブルには、ユーザーごとに、ユーザーＩＤ、ユーザー名、表示名、パスワード、公開鍵、秘密鍵、認証済みトークン、トークンの有効期限などの情報が記録されている。
【０１０２】
（３）受信ＭＳＧリストの要求に対する応答
ＭＳＧ管理機構１０のサーバは、ＭＳＧリスト発行部と通知保管部１３２と通知取得部１９０とＭＳＧ取得部１３６を備えている。端末ソフトウェア５０からユーザー識別情報と受信ＭＳＧリストの取得要求があった場合、ＭＳＧリスト発行部１３０は、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から当該ユーザーＩＤを検索キーにして、認証済みトークンを照合する。そして、ＭＳＧリスト発行部１３０は、有効期間内にあることを確認できた場合（以下、「認証済みトークンが有効」という）、通知保管部１３２が管理する「受信ＭＳＧ管理テーブル」から当該ユーザーのユーザーＩＤを検索キーにし、ＭＳＧＩＤ、送信元ユーザーＩＤ、送信元ユーザーのドメインＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、開示種別、返信元ＭＳＧＩＤ、件名をすべて取得して、受信ＭＳＧリストを作成する。この受信ＭＳＧリストは、このリストを要求した端末ソフトウェアに返される。
通知保管部１３２で管理される「受信ＭＳＧ管理テーブル」には、通知取得部１９０が通知機構２０を介して取得した、送信元ＭＳＧ管理機構１０で発行された「ＭＳＧ作成通知」が逐次記録される。また、受信ＭＳＧリストを作成する際、抽出されたＭＳＧＩＤごとにＭＳＧ取得部１３６に対して、当該ＭＳＧの本文及び添付ファイルのＵＲＩ取得要求を行い、結果通知を受信ＭＳＧリストに追加して、端末ソフトウェアに応答を返すこともできる。
図７は、受信ＭＳＧ管理テーブルの一例を示す図である。図７に示すように、受信ＭＳＧ管理テーブルには、受信ＭＳＧごとに、メッセージＩＤ、送信元ユーザーＩＤ、送信元ユーザーのドメインＩＤ、宛先ユーザーＩＤ，宛先ユーザーのドメインＩＤ、開示種別（無指定、ＴＯ、ＣＣ、ＢＣＣ、ブラックリストなど）、返信元メッセージＩＤ（ＭＳＧＩＤと当該ＭＳＧが作成されたドメインＩＤの組み合わせ）、件名、開封フラグ（メッセージ本体の取得要求を発行すると、あるいは取得要求したメッセージ本体が送信元ＭＳＧ管理機構から受信されると、１に変更される）などの情報が記録されている。
【０１０３】
（４）送信済みＭＳＧリストの要求に対する応答
ＭＳＧ管理機構１０のサーバは、「作成ＭＳＧ管理テーブル」を管理するＭＳＧ保管部１３８を備えている。端末ソフトウェア５０からユーザー識別情報と送信済みＭＳＧリストの取得要求があった場合、ＭＳＧリスト発行部１３０は、認証済みトークンが有効の場合、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ユーザーのユーザーＩＤを検索キーにし、開示フラグが１（開示済み）であるＭＳＧを抽出し、ＭＳＧＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、開示種別（ＴＯ、ＣＣ，ＢＣＣ、ブラックリスト）、件名、本文、添付ファイルパスをすべて取得して、送信済みＭＳＧリストを作成する。作成された送信済みＭＳＧリストは、このリストを要求した端末ソフトウェアに返される。そのＭＳＧの本文を送信先ユーザーの取得要求に応じて伝送したかどうかを示す開封フラグがさらに含まれてもよい。
図８は、作成ＭＳＧ管理テーブルの一例を示す図である。図８に示すように、作成ＭＳＧ管理テーブルには、作成ＭＳＧごとに、メッセージＩＤ、作成ユーザーＩＤ、送信先ユーザーＩＤ，送信先ユーザーのドメインＩＤ、開示種別（無指定、ＴＯ、ＣＣ、ＢＣＣ、ブラックリストなど）、件名、本文、添付ファイルパス、開示フラグ（下書き、開示済み、いったん開示後に一時非開示、削除）、開封フラグなどの情報が記録されている。
【０１０４】
（５）下書き済みＭＳＧリストの要求に対する応答
端末ソフトウェア５０からユーザー識別情報と下書き保存済みＭＳＧリストの取得要求があった場合、ＭＳＧリスト発行部１３０は、認証済みトークンが有効の場合、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ユーザーのユーザーＩＤを検索キーにし、開示フラグが０（下書き）であるＭＳＧを抽出し、ＭＳＧＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、開示種別（ＴＯ、ＣＣ，ＢＣＣ、ブラックリスト）、件名、本文、添付ファイルパスをすべて取得して、下書き保存済みＭＳＧリストを作成する。作成された下書き保存済みＭＳＧリストは、このリストを要求した端末ソフトウェアに返される。
【０１０５】
（６）受信ＭＳＧの取得要求に対する応答
ＭＳＧ管理機構１０のサーバは、名前解決要求部１４０を備えている。端末ソフトウェア５０からユーザー識別情報と特定の受信ＭＳＧの取得要求があり、認証済みトークンが有効の場合、ＭＳＧ取得部１３６は、通知保管部１３２が管理する「受信ＭＳＧ管理テーブル」からＭＳＧＩＤを検索キーにして、送信元ユーザーのドメインＩＤを抽出し、続いて、名前解決要求部１４０に対して抽出されたドメインＩＤのＭＳＧ管理機構１０−２のＦＱＤＮを要求する。
名前解決要求部１４０は、ＩＤ管理機構３０に対して、当該ドメインＩＤのＭＳＧ管理機構１０−２のＦＱＤＮを要求し、要求結果通知を取得し、ＦＱＤＮが適切に取得できた場合は、ＭＳＧ取得部１３６に当該ＦＱＤＮを通知する。ＭＳＧ取得部１３６は、ＭＳＧ管理機構１０−２のＦＱＤＮに対して、ＭＳＧＩＤと要求しているユーザーＩＤを通知し、本文及び添付ファイルのＵＲＩを取得する。取得された本文及び添付ファイルは、要求しているユーザーの公開鍵で暗号化されているため、ＭＳＧ取得部１３６は、利用者情報保管部１２２が管理する「ユーザー管理テーブル」からユーザーＩＤを検索キーとして当該ユーザーの秘密鍵を抽出し、復号を行う。
復号された本文及び添付ファイルのＵＲＩは、ＭＳＧ提示部１４５により、通知保管部１３２が管理する「受信ＭＳＧ管理テーブル」からＭＳＧＩＤを検索キーとして抽出された送信元ユーザーのドメインＩＤ、送信元ユーザーＩＤ、件名、開示種別、返信元ＭＳＧＩＤとともに、ＭＳＧ要求した端末ソフトウェアに返される。
【０１０６】
（７）アドレス帳リストの取得要求と応答
ＭＳＧ管理機構１０のサーバは、アドレス帳発行部１５０とアドレス帳保管部１５２を備えている。端末ソフトウェア５０からユーザー識別情報とアドレス帳リスト取得要求があり、認証済みトークンが有効の場合、アドレス帳発行部１５０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」からユーザーＩＤを検索キーとして許諾済みユーザーＩＤ及び許諾済みユーザーのドメインＩＤ、許諾済みユーザー名、グループフラグ（０：個人、１：グループ）を抽出し、アドレス帳リストを作成する。作成されたアドレス帳リストは、このリストを要求した端末ソフトウェアに返される。
図９は、アドレス帳管理テーブルの一例を示す図である。図９に示すように、アドレス帳管理テーブルには、ユーザーＩＤ、承諾済みユーザーＩＤ、承諾済みユーザーのドメインＩＤ、承諾済みユーザー名、グループフラグ（非グループＩＤ／個人ＩＤ，グループＩＤ）、公開鍵などの情報が記録されている。
【０１０７】
（８）新規ＭＳＧの作成要求に対する応答
ＭＳＧ管理機構１０のサーバは、ＭＳＧ発行処理部１６０と通知発行部１６２とグループ情報保管部１６６を備えている。端末ソフトウェア５０からユーザー識別情報と新規ＭＳＧ作成要求と作成項目（送信先となるユーザーのドメインＩＤとユーザーＩＤ及びグループフラグ、開示種別、件名、本文、添付ファイルのＵＲＩ）を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」に対して、新規レコードを追加し、取得した項目を記録する。
ＭＳＧ発行処理部１６０は、これに先立ち、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」に対して、作成者ユーザーＩＤを検索キーとして、送信先となるユーザーのドメインＩＤ及びユーザーＩＤを抽出する。抽出できなかった場合は、（１３）と同様に送信先となるユーザーに対して、公開鍵の交換許諾を要求し、開示フラグを０（下書き）としてレコードを保存する。抽出できた場合は、開示フラグを１（開示済み）としてレコードを保存し、「ＭＳＧ作成通知」を作成する。「ＭＳＧ作成通知」には、送信先ユーザーのドメインＩＤ及びユーザーＩＤ、件名、送信日時、ＭＳＧＩＤ、通知を一意に識別するＩＤが含まれる。このような「ＭＳＧ作成通知」が通知発行部１６２に通知される。
この際、ＭＳＧ保管部１３８が管理する「送信ＭＳＧ管理テーブル」を使用する場合には、これに対して、新規にレコードを追加し、ＭＳＧ本体（本文、添付ファイル）を送信先ユーザーの公開鍵で暗号化して記録する。同じ「送信ＭＳＧ管理テーブル」を使用しない場合は、（１２）において、送信先のＭＳＧ管理機構１０−２のＭＳＧ取得部１３６からＭＳＧ本体の取得要求があった際に、送信先ユーザーの公開鍵によるＭＳＧ本体の暗号化を行う。
図１２は、送信ＭＳＧ管理テーブルの一例を示す図である。図１２に示すように、送信ＭＳＧ管理テーブルには、ＭＳＧごとに、ＭＳＧＩＤ、送信先ユーザーＩＤ、送信先ユーザーのドメインＩＤ、送信日時、送信先ユーザーの公開鍵による暗号化済みの件名、送信先ユーザーの公開鍵による暗号化済みの本文、送信先ユーザーの公開鍵による暗号化済みの添付ファイルのＵＲＩなどの情報が記録されている。
ただし、グループフラグが１（グループのＩＤ）という送信先が含まれている場合、通知発行部１６２は、通知機構２０を介してグループのＩＤを管理しているＭＳＧ管理機構１０に対して、許諾済みユーザー（グループ）のＭＳＧ管理機構１０が保持しているグループのメンバーリスト（ユーザーのドメインＩＤ及びユーザーＩＤ、公開鍵）を要求し、取得結果通知をグループ情報保管部１６６が管理する「グループ管理テーブル」に保存し、さらにＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」に当該グループに含まれる個別のユーザーＩＤでレコードを追加し、それぞれに対して「ＭＳＧ作成通知」を発行する。
図１０は、グループ管理テーブルの一例を示す図である。図１０に示すように、グループ管理テーブルには、グループごとに、グループＩＤ，グループ名、管理者ユーザーＩＤ、参加者ユーザーＩＤ，参加者ユーザーのドメインＩＤ、状況フラグ（参加依頼中、回答保留中、承諾済み、承諾撤回、依頼拒否）、参加者ユーザーの公開鍵などの情報が記録されている。
また、通知発行部１６２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。名前解決要求部１４０は、ＩＤ管理機構３０に対して、当該ドメインの通知機構２０のＦＱＤＮを要求し、要求結果通知を取得する。ＦＱＤＮが適切に取得できた場合は、通知発行部１６２に当該ＦＱＤＮを通知する。通知発行部１６２は、取得した通知機構のＦＱＤＮに対して、上記の「ＭＳＧ作成通知」を発行する。この処理が完了した場合、通知発行部１６２は、ＭＳＧ発行処理部１６０に処理結果通知を通知し、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１０８】
（９）送信済みＭＳＧの訂正要求に対する応答
端末ソフトウェア５０からユーザー識別情報と送信済みＭＳＧＩＤと訂正要求、訂正内容（送信先となるユーザーのドメインＩＤとユーザーＩＤ、開示種別、件名、本文、添付ファイルのＵＲＩ）を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」に対して、ＭＳＧＩＤを検索キーとして、当該レコードを抽出し、要求された項目を修正する。送信先となるユーザーのドメインＩＤ及びユーザーＩＤが変更になる場合は、新たに指定された送信先ユーザーに対して、（８）と同様に「ＭＳＧ作成通知」を発行する。この処理が完了した場合、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１０９】
（１０）送信済みＭＳＧの開示中止要求に対する応答
端末ソフトウェア５０からユーザー識別情報と送信済みＭＳＧＩＤ、開示中止要求を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧテーブル」に対して、ＭＳＧＩＤを検索キーとして当該レコードを抽出し、開示フラグを０（下書き）に変更する。この処理が完了した場合、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１１０】
（１１）送信済み又は下書き保存済みＭＳＧの削除要求に対する応答
端末ソフトウェア５０からユーザー識別情報とＭＳＧＩＤ、削除要求を取得し、認証済みトークンが有効の場合、ＭＳＧ発行処理部１６０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧテーブル」に対して、ＭＳＧＩＤを検索キーとして当該レコードを抽出し、レコードの削除を行う。この処理が完了した場合、ＭＳＧ発行処理部１６０は、要求した端末ソフトウェアに結果通知を返す。
【０１１１】
（１２）ＭＳＧ本文及び添付ファイルＵＲＩの取得要求に対する応答
ＭＳＧ管理機構１０のサーバは、ＭＳＧ発行部１７０を備えている。他のＭＳＧ管理機構１０から受信ユーザーのドメインＩＤ及びユーザーＩＤ、ＭＳＧＩＤが通知され、ＭＳＧ本文及び添付ファイルのＵＲＩに関する取得要求があった場合、ＭＳＧ発行部１７０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」からＭＳＧＩＤを検索キーにして当該ＭＳＧのレコードを抽出し、要求元ユーザーのドメインＩＤ及びユーザーＩＤが送信先ユーザーのドメインＩＤと送信先ユーザーＩＤの項目と合致した場合、件名、本文、添付ファイルのＵＲＩ、その他必要な項目を抽出する。また、このとき、ＭＳＧ発行部１７０は、同時にアドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から要求元ユーザーのドメインＩＤ及びユーザーＩＤを検索キーとして当該ユーザーの公開鍵を抽出する。
そして、ＭＳＧ発行部１７０は、上記の件名、本文、添付ファイルＵＲＩ、その他必要な項目を上記公開鍵で暗号化し、通知機構２０を介さず、直接に要求元のＭＳＧ管理機構１０に結果通知を返すとともに、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ＭＳＧＩＤと要求元ユーザーのドメインＩＤ及びユーザーＩＤでレコードを抽出し、当該レコードの開封フラグを１（開封済み）に変更する。
また、ＭＳＧ発行部１７０は、ＭＳＧ保管部１３８が管理する「作成ＭＳＧ管理テーブル」から当該ＭＳＧを作成したユーザーを抽出し、当該ユーザーに対して、送信先ユーザーが当該ＭＳＧ本体の取得を行った事実について記載した「開封済み通知」を発行することができる。
上記のように、ＭＳＧ作成者の「作成ＭＳＧ管理テーブル」の開封フラグを１に変更したり、ＭＳＧ作成者の「受信ＭＳＧ管理テーブル」に「開封済み通知」という新たなレコードを書き込んだりすることにより、送信先ユーザーがＭＳＧ本体の取得を行ったことをＭＳＧ作成者に知らせるという機能を、ＭＳＧ毎にＯＮ／ＯＦＦできるようにしてもよい。
【０１１２】
（１３）アドレス帳リストへの追加要求に対する応答
ＭＳＧ管理機構１０のサーバは、交換許諾要求取得部１８０と交換許諾発行部１８２を備えている。端末ソフトウェア５０からユーザー識別情報と相手方となるドメインＩＤ及びユーザーＩＤについて、アドレス帳リストへの追加要求があった場合、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該ユーザーＩＤを検索キーとして、取得した相手先となるドメインＩＤ及びユーザーＩＤが登録されているかどうかを判定する。登録されていない場合には、交換許諾発行部１８２に対して、相手方となるユーザーへの公開鍵交換の許諾依頼の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの公開鍵交換の許諾依頼を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェア５０に結果通知を返す。公開鍵交換の許諾依頼の通知には、通知を一意に識別するＩＤが含まれる。
【０１１３】
（１４）アドレス帳リストへの追加要求の撤回要求に対する応答
端末ソフトウェア５０からユーザー識別情報と相手方となるドメインＩＤ及びユーザーＩＤについて、アドレス帳リストへの追加要求の撤回要求があった場合、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該ユーザーＩＤを検索キーとして、取得した相手先となるドメインＩＤ及びユーザーＩＤが登録されているかどうかを判定する。登録されている場合には、さらに状況フラグが０（許諾依頼中）であることを確認し、交換許諾発行部１８２に対して、相手方となるユーザーへの公開鍵交換依頼の撤回を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「公開鍵交換依頼の撤回」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、当該レコードを削除するとともに要求した端末ソフトウェアに結果通知を返す。
【０１１４】
（１５）被交換許諾依頼保留中リストの取得要求に対する応答
ＭＳＧ管理機構１０のサーバは、交換許諾情報保管部１８６と交換許諾リスト発行部１８８を備えている。ＭＳＧ管理機構１０の管理下にあるユーザーの交換許諾要求に基づいて、その相手方となるユーザーに対して発行した交換許諾依頼の情報Ａが、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」に記憶されるとともに、他のＭＳＧ管理機構１０から受信した交換許諾依頼の情報Ｂも、同じ「交換許諾状況管理テーブル」に記憶される。ここでは、その情報Ｂの中から、許諾依頼を受信したが未だ承諾通知も却下通知も返信していない（状況フラグが「回答保留中」の）レコードを抽出したリストを、「被交換許諾依頼保留中リスト」と呼ぶ。
図１１は、交換許諾状況管理テーブルの一例を示す図である。図１１に示すように、交換許諾状況管理テーブルには、ユーザーＩＤ、対象ユーザーＩＤ、対象ユーザーのドメインＩＤ、状況フラグ（許諾依頼中、回答保留中、許諾済み、許諾撤回、依頼却下）、交換依頼ユーザーの公開鍵、グループフラグ（非グループ、グループ）などの情報が記録されている。
端末ソフトウェア５０からユーザー識別情報と当該ユーザーの被交換許諾依頼保留中リストの取得要求があった場合、交換許諾リスト発行部１８８は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該ユーザーＩＤを検索キーとしてレコードを抽出し、さらに状況フラグが１（回答保留中）のレコードを抽出し、「被交換許諾依頼保留中」リストを作成して、要求元の端末ソフトウェア５０に返す。
【０１１５】
（１６）被交換許諾依頼の承諾要求に対する応答
承諾通知要求とは、保留中の許諾依頼に対して、承諾通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求である。端末ソフトウェア５０からユーザー識別情報と相手方となるユーザーのドメインＩＤ及びユーザーＩＤと承諾通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該ユーザーＩＤを検索キーとして、相手方となるユーザーのドメインＩＤ及びユーザーＩＤが含まれるレコードを抽出し、状況フラグを２（許諾済み）に更新する。同時に、交換許諾発行部１８２に対して、相手方となるユーザーへの承諾通知の発行を要求する。
さらに、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」に、新規レコードを追加し、承諾したユーザーＩＤ、依頼元ユーザーＩＤ、依頼元ユーザーのドメインＩＤ、依頼元ユーザー名、グループフラグ０（非グループＩＤ＝個人ＩＤ）、「公開鍵交換依頼」から取得した依頼元ユーザーの公開鍵を保存する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「公開鍵交換の許諾依頼に対する承諾通知」を発行する。この「公開鍵交換の許諾依頼に対する承諾通知」には、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から抽出した承諾したユーザーの公開鍵が含まれる。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェアに結果通知を返す。
【０１１６】
（１７）被交換許諾依頼の却下要求に対する応答
却下通知要求は、保留中の許諾依頼に対して、却下通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求である。端末ソフトウェア５０からユーザー識別情報と相手方となるユーザーのドメインＩＤ及びユーザーＩＤと却下通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該ユーザーＩＤを検索キーとして、相手方となるユーザーのドメインＩＤ及びユーザーＩＤが含まれるレコードを抽出し、状況フラグを４（依頼却下）に更新します。同時に交換許諾発行部１８２に対して、相手方となるユーザーへの却下通知の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「公開鍵交換の許諾依頼に対する却下通知」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、当該レコードを削除するとともに要求した端末ソフトウェアに結果通知を返す。なお、承認及び却下通知には、発行ごとに通知を一意に識別するＩＤが含まれる。
【０１１７】
（１８）交換許諾依頼の承諾通知に対する処理
ＭＳＧ管理機構１０のサーバは、交換許諾処理部１９５を備えている。通知機構２０を介して依頼先ユーザーのＭＳＧ管理機構１０から発行された「公開鍵交換依頼に対する承諾通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から依頼元ユーザーＩＤを検索キーとし、承諾ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを２（承諾済み）に更新するとともに「公開鍵交換依頼に対する承諾通知」から取得した承諾ユーザーの公開鍵を保存する。
さらに交換許諾処理部１９５は、アドレス帳保管部１５２が管理している「アドレス帳管理テーブル」に新規レコードを追加し、依頼元ユーザーＩＤ、承諾済みユーザーＩＤ、承諾済みユーザーのドメインＩＤ、承諾済みユーザー名、グループフラグ０（非グループＩＤ＝個人ＩＤ）、「公開鍵交換依頼に対する承諾通知」から取得した承諾済みユーザーの公開鍵を保存する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１１８】
（１９）交換許諾依頼の却下通知に関する処理
通知機構２０から「公開鍵交換依頼に対する却下通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から依頼元ユーザーＩＤを検索キーとし、承諾ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを４（依頼却下）に更新する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１１９】
（２０）グループリスト作成要求に対する応答
端末ソフトウェア５０からユーザー識別情報とグループ名、参加させたいユーザーのドメインＩＤ及びユーザーＩＤ、ユーザー名が含まれた「グループリスト作成要求」があった場合、交換許諾要求取得部１８０は、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該グループ名を検索キーとして、取得したグループ名が登録されているかどうかを評価し、登録されていない場合は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」に新規レコードを追加し、そのレコードの状況フラグを０（許諾依頼中）に変更する。
続いて、交換許諾要求取得部１８０は、交換許諾発行部１８２に対して、参加させたいユーザーへのグループリスト参加依頼の発行を要求する。交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「グループリスト参加依頼通知」を発行する。
また、交換許諾発行部１８２は、アドレス帳保管部１５２が管理している「アドレス帳管理テーブル」に新規レコードを追加し、管理者のユーザーＩＤ、グループＩＤ、グループのドメインＩＤ、グループ名、グループフラグ１（グループＩＤ）を保存する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェア５０に結果通知を返す。公開鍵交換依頼の通知には、通知を一意に識別するＩＤが含まれる。
【０１２０】
（２１）グループリスト参加保留中リストの取得要求に対する応答
ＭＳＧ管理機構１０の交換許諾情報保管部１８６で管理される「交換許諾状況管理テーブル」に記憶され、かつグループフラグが１（グループＩＤ）であるレコードのうち、グループリスト参加依頼を受信したが未だ承諾通知も却下通知も返信していない（状況フラグが「回答保留中」の）レコードを抽出したリストを「グループリスト参加保留中リスト」と呼ぶ。
端末ソフトウェア５０からユーザー識別情報と当該ユーザーのグループリスト参加保留中リストの取得要求があった場合、交換許諾リスト発行部１８８は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該ユーザーＩＤを検索キーとしてレコードを抽出し、さらにグループフラグが１（グループＩＤ）及び状況フラグが１（回答保留中）のレコードを抽出し、「グループリスト参加保留中リスト」を作成して、要求元の端末ソフトウェア５０に返す。
【０１２１】
（２２）グループリスト参加承諾通知に関する処理
グループリスト参加承諾通知要求とは、保留中の参加許諾依頼に対して、承諾通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求をいう。
端末ソフトウェア５０からユーザー識別情報と対象となるグループＩＤと承諾通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該グループＩＤを検索キーとして、レコードを抽出し、状況フラグを２（許諾済み）に更新する。同時に交換許諾発行部１８２に対して、依頼元ＭＳＧ管理機構に対して、グループリスト参加承諾通知の発行を要求する。
さらに、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」に新規レコードを追加し、承諾したユーザーＩＤ、承諾したユーザーのドメインＩＤ、管理者ユーザーＩＤ、管理者ユーザーのドメインＩＤ、グループ名、「公開鍵交換依頼」から取得した管理者ユーザーの公開鍵を保存する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介してグループリストを管理しているＭＳＧ管理機構１０に対し、管理者ユーザーへの「グループリスト参加承諾通知」を発行する。この「グループリスト参加承諾通知」には、利用者情報保管部１２２が管理する「ユーザー管理テーブル」から抽出した承諾したユーザーの公開鍵が含まれる。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、要求した端末ソフトウェアに結果通知を返す。
【０１２２】
（２３）グループリスト参加拒否通知に関する処理
グループリスト参加拒否通知要求は、保留中の参加許諾依頼に対して、拒否通知を送ってほしいという、端末ソフトウェア５０からＭＳＧ管理機構１０への要求である。端末ソフトウェア５０からユーザー識別情報と対象となるグループＩＤと拒否通知要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該グループＩＤを検索キーとして、レコードを抽出し、状況フラグを４（依頼拒否）に更新する。同時に交換許諾発行部１８２に対して、依頼元ＭＳＧ管理機構に対して、グループリスト参加拒否通知の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介してグループリストを管理しているＭＳＧ管理機構１０に対し、管理者ユーザーへの「グループリスト参加拒否通知」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「交換許諾管理状況テーブル」から当該グループＩＤを検索キーとして、レコードを削除し、要求した端末ソフトウェアに結果通知を返す。
【０１２３】
（２４）グループリスト参加承諾通知に関する処理
通知機構２０を介して依頼先ユーザーのＭＳＧ管理機構１０から発行された「グループリスト参加承諾通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」からグループ管理者ユーザーＩＤを検索キーとして、承諾ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを２（承諾済み）に更新するとともに「グループリスト参加承諾通知」から取得した承諾ユーザーの公開鍵を保存する。
さらに交換許諾処理部１９５は、「グループリスト参加承諾通知」の送信者が自己の管理下にあるユーザーの場合、アドレス帳保管部１５２が管理している「アドレス帳管理テーブル」に新規レコードを追加し、承諾ユーザーＩＤ、グループＩＤ、グループのドメインＩＤ、グループ名、グループフラグ１（グループＩＤ）を保存する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１２４】
（２５）グループリスト参加拒否通知に関する処理
通知機構２０から「グループリスト参加拒否通知」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」から依頼元ユーザーＩＤを検索キーとし、拒否ユーザーのドメインＩＤ及びユーザーＩＤを含むレコードを抽出し、状況フラグを４（依頼拒否）に更新する。この処理が完了した場合、交換許諾処理部１９５は、通知機構２０を介して承諾ユーザーのＭＳＧ管理機構１０に対して、結果通知を返す。
【０１２５】
（２６）グループリスト削除要求に対する応答
端末ソフトウェア５０からユーザー識別情報とグループＩＤが通知され当該グループリストの削除要求があった場合、交換許諾要求取得部１８０は、交換許諾情報保管部１８６が管理する「グループ管理テーブル」から当該グループＩＤを検索キーとして、すべての参加ユーザーを抽出し、状況フラグを５（削除準備中）に更新する。続いて、交換許諾要求取得部１８０は、交換許諾発行部１８２に対して、当該グループに参加しているユーザーへ「グループ削除通知」の発行を要求する。
交換許諾発行部１８２は、名前解決要求部１４０に対して、通知機構２０のＦＱＤＮを要求する。交換許諾発行部１８２は、取得した通知機構２０のＦＱＤＮを介して相手先となるＭＳＧ管理機構１０に対し、対象となるユーザーへの「グループ削除通知」を発行する。この処理が完了した場合、交換許諾発行部１８２は、交換許諾要求取得部１８０に処理結果通知を通知し、交換許諾要求取得部１８０は、当該レコードを削除するとともに要求した端末ソフトウェアに結果通知を返す。
【０１２６】
（２７）グループリスト削除通知に関する処理
通知機構２０から「グループリスト削除」を取得した交換許諾処理部１９５は、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該グループＩＤを含むレコードを抽出し、状況フラグを５（削除準備中）に更新し、アドレス帳保管部１５２が管理する「アドレス帳管理テーブル」から当該グループＩＤを含むレコードを抽出して削除するとともに要求したＭＳＧ管理機構１０に結果通知を返す。また、交換許諾処理部１９５は、結果通知の送信後、交換許諾情報保管部１８６が管理する「交換許諾状況管理テーブル」から当該グループＩＤを含むレコードを抽出し、削除を行う。
【０１２７】
［通知機構］
つぎに、通知機構２０のサーバの構成について説明する。以下、通知機構２０のサーバの各構成を、図１３および図１４を参照しながら、このサーバの機能と対応させて説明する。
（１）ＳＳＬによる暗号化通信
図１３は、通知機構２０のサーバの構成例を示す図である。図３に示すように、通知機構２０のサーバは、暗号化・認証部２１０を備えている。この暗号化・認証部２１０によって、ＭＳＧ管理機構１０とＩＤ管理機構３０、他の通知機構２０との間の通信に、ＳＳＬを用いた暗号通信が適用される。
（２）各要求に対する応答
通知機構２０が仲介する通知には、少なくとも、新たにＭＳＧが作成されたときに送信元ドメインのＭＳＧ管理機構１０が送信先ドメインのＭＳＧ管理機構１０へ発行する「ＭＳＧ作成通知」、公開鍵交換依頼を行うために依頼元ドメインのＭＳＧ管理機構１０が依頼先ドメインのＭＳＧ管理機構１０へ発行する「公開鍵交換依頼通知」、「公開鍵交換依頼通知」を受け取った依頼先ドメインのＭＳＧ管理機構１０が依頼元ドメインのＭＳＧ管理機構１０へ発行する「公開鍵交換依頼の承諾通知」もしくは「公開鍵交換依頼の却下通知」、要求された処理の完了を示す「処理完了通知」が含まれる。
通知機構２０のサーバは、通知要求処理部２２０と名前解決要求部２３０と通知発行部２４０を備えている。通知要求処理部２２０は、ＭＳＧ管理機構１０から通知要求を取得した場合に、通知に記載されている送信先ドメインＩＤを抽出し、名前解決要求部２３０は、ＩＤ管理機構３０に対して、送信先となるＭＳＧ管理機構１０のＦＱＤＮ要求を発行し、取得した結果通知を通知発行部２４０に送る。通知発行部２４０は、取得したＭＳＧ管理機構１０のＦＱＤＮに対して、要求された通知の転送を行う。転送が完了した場合、通知要求処理部２２０は、要求元のＭＳＧ管理機構１０に結果通知を返す。すべての結果通知には、通知を一意に識別するためのＩＤが含まれる。
（３）統計情報の取得処理
通知機構２０のサーバは、ＭＳＧ管理機構１０間で送受信される通知を仲介する役割を担う統計情報処理部２５０を備える。統計情報処理部２５０は、送受信される履歴を統計処理するために、統計情報保管部（図示せず）が管理する「統計情報テーブル」に、通知要求日時、通知元ドメインのＩＤ、通知元ＭＳＧ管理機構のＦＱＤＮ、通知先ドメインのＩＤ、通知を一意に識別するＩＤを記録する。
図１４は、統計情報テーブルの一例を示す図である。図１４に示すように、統計情報テーブルには、通知要求日時、通知元ドメインＩＤ、通知元ＭＳＧ管理機構のＦＱＤＮ、通知識別ＩＤなどの情報が記録されている。
以上のように構成された本発明のメッセージ伝送システムについて、図１５〜３４を用いてその動作を説明する。
【０１２８】
［ユーザー認証］
図１５は、端末ソフトウェアの（２）ユーザー認証の処理の流れを示すシーケンス図である。図１５に示すように、ユーザー認証が行われるときには、まず、端末ソフトウェア５０がユーザーのドメインＩＤ、ユーザーＩＤ及びパスワードの入力を受け付け（Ｓ１５００）、ＭＳＧ管理機構１０のＦＱＤＮ要求をＩＤ管理機構３０に送信する（Ｓ１５０１）。ＩＤ管理機構３０は、ＭＳＧ管理機構のＦＱＤＮ要求を受信すると（Ｓ１５０２）、ドメイン情報テーブルからＦＱＤＮを抽出し（Ｓ１５０３）、ＭＳＧ管理機構１０のＦＱＤＮを端末ソフトウェア５０に返信する（Ｓ１５０４）。
【０１２９】
端末ソフトウェア５０は、返信されたＭＳＧ管理機構１０のＦＱＤＮを受信すると（Ｓ１５０５）、ユーザー認証情報をＭＳＧ管理機構１０に送信する（Ｓ１５０６）。ＭＳＧ管理機構１０は、そのユーザー認証情報を受信すると（Ｓ１５０７）、ユーザー管理テーブルでユーザー認証情報の照合を行い（Ｓ１５０８）、認証結果と認証済みトークンを端末ソフトウェア５０に返信する（Ｓ１５０９）。端末ソフトウェア５０は、この認証結果と認証済みトークンを受信する（Ｓ１５１０）。
【０１３０】
［各ＭＳＧリストの取得］
図１６は、端末ソフトウェアの（３）各ＭＳＧリストの取得の処理の流れを示すシーケンス図である。図１６に示すように、各ＭＳＧリストの取得が行われるときには、まず、端末ソフトウェア５０で認証結果がＯＫだったか否かの判定が行われる（Ｓ１６００）。認証結果がＯＫだった場合には、端末ソフトウェア５０からＭＳＧ管理機構１０に受信ＭＳＧリスト取得要求が送信される（Ｓ１６０１）。
【０１３１】
ＭＳＧ管理機構１０は、受信ＭＳＧリスト取得要求を受信すると（Ｓ１６０２）、受信ＭＳＧ管理テーブルから該当するＭＳＧを抽出して（Ｓ１６０３）、受信ＭＳＧリストを作成し（Ｓ１６０４）、その受信ＭＳＧリストを端末ソフトウェア５０へ返信する（Ｓ１６０５）。
【０１３２】
端末ソフトウェア５０は、返信された受信ＭＳＧリストを取得すると、送信済みＭＳＧリストの取得要求をＭＳＧ管理機構１０へ送信する。ＭＳＧ管理機構１０は、この送信済みＭＳＧリスト取得要求を受け付けると（Ｓ１６０８）、作成ＭＳＧ管理テーブルを参照して、該当するＭＳＧを抽出し（Ｓ１６０９）、送信済みＭＳＧリストを作成して（Ｓ１６１０）、端末ソフトウェア５０へ送信する（Ｓ１６１１）。
【０１３３】
端末ソフトウェア５０は、この送信済みＭＳＧリストを受信すると（Ｓ１６１２）、下書き保存済みＭＳＧリストの取得要求をＭＳＧ管理機構へ送信する（Ｓ１６１３）。ＭＳＧ管理機構１０は、下書き保存済みＭＳＧリストの取得要求を受けると（Ｓ１６１４）、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１６１５）、下書き保存済みＭＳＧリストを作成する（Ｓ１６１６）。作成された下書き保存済みＭＳＧリストは、ＭＳＧ管理機構１０から端末ソフトウェアに送信される（Ｓ１６１７、Ｓ１６１８）。
【０１３４】
［各ＭＳＧリストの取得結果の表示］
図１７は、端末ソフトウェアの（７）各ＭＳＧリストの取得結果の表示の処理の流れを示すシーケンス図である。図１７に示すように、各ＭＳＧリストの取得結果の表示が行われるときには、まず、端末ソフトウェア５０において、受信ＭＳＧリストを取得済みであるか否かの判定が行われる（Ｓ１７０）。受信ＭＳＧリストを取得済みである場合には、その受信ＭＳＧリストの取得結果を画面に出力する（Ｓ１７１）。受信ＭＳＧリストを取得済みでない場合には、画面へ出力は行われない。
【０１３５】
つぎに、端末ソフトウェア５０は、送信済みＭＳＧリストを取得済みであるか否かの判定を行う（Ｓ１７２）。送信済みＭＳＧリストを取得済みである場合には、その送信済みＭＳＧリストの取得結果を画面に出力する（Ｓ１７３）。送信済みＭＳＧリストを取得済みでない場合には、画面へ出力は行われない。
【０１３６】
また、端末ソフトウェア５０は、下書き保存ＭＳＧリストを取得済みであるか否かの判定を行う（Ｓ１７４）。下書き保存ＭＳＧリストを取得済みである場合には、その下書き保存ＭＳＧリストの取得結果を画面に出力する（Ｓ１７５）。下書き保存ＭＳＧリストを取得済みでない場合には、画面へ出力は行われない。
【０１３７】
［各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示（１）］
図１８は、端末ソフトウェアの（８）各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図である。図１８に示すように、各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示が行われるときには、まず、送信元の端末ソフトウェア５０−１（以下、端末ソフトウェア（Ａ）とも表記する）において、特定の受信ＭＳＧを取得したか否かの判定が行われる（Ｓ１８００）。特定の受信ＭＳＧを取得した場合には、端末ソフトウェア（Ａ）から送信元のＭＳＧ管理機構１０−１（以下、ＭＳＧ管理機構（Ａ）とも表記する）へ、受信ＭＳＧの取得要求が送信される（Ｓ１８０１、Ｓ１８０２）。
【０１３８】
ＭＳＧ管理機構（Ａ）では、その受信ＭＳＧの取得要求に基づいて、受信ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１８０３）、送信元ＭＳＧ管理機構のＦＱＤＮの取得要求をＩＤ管理機構３０へ送信する（Ｓ１８０４、Ｓ１８０５）。
【０１３９】
ＩＤ管理機構３０は、ＭＳＧ管理機構（Ａ）からのＦＱＤＮの取得要求に基づいて、ドメイン情報管理テーブルからＦＱＤＮを抽出し（Ｓ１８０６）、送信元ＭＳＧ管理機構のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ１８０７、Ｓ１８０８）。
【０１４０】
つぎに、ＭＳＧ管理機構（Ａ）は、ＭＳＧ取得要求を送信先のＭＳＧ管理機構１０−２（以下、ＭＳＧ管理機構（Ｂ）とも表記する）へ送信する（Ｓ１８０９、Ｓ１８１０）。
【０１４１】
ＭＳＧ管理機構（Ｂ）は、そのＭＳＧ取得要求に基づいて、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１８１１）、送信ＭＳＧ管理テーブルから暗号化済みのＭＳＧ本体を抽出する。ＭＳＧ本体が平文のまま送信ＭＳＧ管理テーブルに保存されている場合は、ＭＳＧ本体を送信先ユーザーの公開鍵で暗号化する（Ｓ１８１２）。そして、ＭＳＧ管理機構（Ｂ）からＭＳＧ管理機構（Ａ）へＭＳＧ本体が送信される（Ｓ１８１３、Ｓ１８１４）。
【０１４２】
ＭＳＧ管理機構（Ａ）では、ＭＳＧ本体をユーザーの秘密鍵で復号し（Ｓ１８１５）、復号済みの受信ＭＳＧを端末ソフトウェア（Ａ）へ送信する（Ｓ１８１６、Ｓ１８１７）。そして、端末ソフトウェア（Ａ）で、復号済みの受信ＭＳＧが画面に表示される（Ｓ１８１８）。
【０１４３】
一方、ＭＳＧ管理機構（Ｂ）は、作成ＭＳＧテーブルの開封フラグを「開封済み」に更新し（Ｓ１８１９）、そのＭＳＧの作成ユーザーに対する開封済みの通知を受信側の端末ソフトウェア５０−２（以下、端末ソフトウェア（Ｂ）とも表記する）へ送信する（Ｓ１８２０）。端末ソフトウェア（Ｂ）では、この開封済み通知を受信すると（Ｓ１８２１）、画面のその通知の内容が表示される（Ｓ１８２２）。
［各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示（２）］
図１９は、端末ソフトウェアの（８）各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図である。図１９に示すように、各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示が行われるときには、まず、端末ソフトウェア（Ａ）において、特定の送信済みＭＳＧを取得したか否かの判定が行われる（Ｓ１９００）。特定の送信済みＭＳＧを取得した場合には、端末ソフトウェア（Ａ）からＭＳＧ管理機構（Ａ）へ、送信済みＭＳＧの取得要求が送信される（Ｓ１９０１、Ｓ１９０２）。
【０１４４】
ＭＳＧ管理機構（Ａ）では、その送信済みＭＳＧの取得要求に基づいて、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１９０３）、送信済みＭＳＧを端末ソフトウェア（Ａ）へ返信する（Ｓ１９０４、Ｓ１９０５）。そして、端末ソフトウェア（Ａ）では、送信済みＭＳＧが画面に表示される（Ｓ１９０６）。
【０１４５】
また、端末ソフトウェア（Ａ）は、特定の下書き保存ＭＳＧを取得したか否かの判定を行う（Ｓ１９０７）。特定の下書き保存ＭＳＧを取得した場合には、端末ソフトウェア（Ａ）からＭＳＧ管理機構（Ａ）へ、下書き保存済みＭＳＧの取得要求が送信される（Ｓ１９０８、Ｓ１９０９）。
【０１４６】
ＭＳＧ管理機構（Ａ）では、その下書き保存済みＭＳＧの取得要求に基づいて、作成ＭＳＧ管理テーブルから該当するＭＳＧを抽出し（Ｓ１９１０）、下書き保存済みＭＳＧを端末ソフトウェア（Ａ）へ返信する（Ｓ１９１１、Ｓ１９１２）。そして、端末ソフトウェア（Ａ）では、下書き保存済みＭＳＧが画面に表示される（Ｓ１９１３）。
［新規ＭＳＧの作成］
図２０は、端末ソフトウェアの（９）新規ＭＳＧの作成の処理の流れを示すシーケンス図である。図２０に示すように、新規ＭＳＧの作成が行われるときには、まず、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へアドレス帳リストの取得要求が送信される（Ｓ２０００、Ｓ２００１）。
【０１４７】
ＭＳＧ管理機構（Ａ）は、このアドレス帳リストの取得要求に基づいて、アドレス帳管理テーブルから該当するユーザーの公開鍵交換済みユーザーを抽出し（Ｓ２００２）、アドレス帳リストを作成して（Ｓ２００３）、端末ソフトウェア５０へ返信する（Ｓ２００４、Ｓ２００５）。
【０１４８】
つぎに、端末ソフトウェア５０では、送信先ユーザーの選択が行われた後（Ｓ２００６）、件名、本文、添付ファイルの指定が行われる（Ｓ２００７）。そして、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ新規ＭＳＧ作成要求が送信される（Ｓ２００８、Ｓ２００９）。
【０１４９】
ＭＳＧ管理機構（Ａ）では、この新規ＭＳＧ作成要求に基づいて、（宛先がグループの場合には、グループリストの取得処理後に）作成ＭＳＧ管理テーブルの保存が行われ（Ｓ２０１０）、ＭＳＧ作成完了通知がＭＳＧ管理機構（Ａ）から端末ソフトウェア５０へ送信される（Ｓ２０１１、２０１２）。
【０１５０】
つづいて、ＭＳＧ管理機構（Ａ）は、通知機構２０のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２０１３、Ｓ２０１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２０１５）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２０１６、Ｓ２０１７）。
【０１５１】
ＭＳＧ管理機構（Ａ）は、通知機構２０へＭＳＧ作成通知を送信する（Ｓ２０１８、Ｓ２０１９）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２０２０、Ｓ２０２１）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２０２２）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２０２３、Ｓ２０２４）。
【０１５２】
通知機構２０が、ＭＳＧ作成通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２０２５、Ｓ２０２６）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルへの保存を行って（Ｓ２０２７）、結果通知を通知機構２０へ返信する（Ｓ２０２８、Ｓ２０２９）。そして、通知機構２０は、その結果通知をＭＳＧ管理機構（Ａ）へ転送する（Ｓ２０３０、Ｓ２０３１）。
【０１５３】
［アドレス帳リストへの個別追加］
図２１は、端末ソフトウェアの（１０）アドレス帳リストへの個別追加の処理の流れを示すシーケンス図である。図２１に示すように、アドレス帳リストへの個別追加が行われるときには、まず、端末ソフトウェア５０において、公開鍵交換要求先ユーザー情報の入力が行われる（Ｓ２１００）。
【０１５４】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へアドレス帳リストの追加要求が送信されると（Ｓ２１０１、Ｓ２１０２）、ＭＳＧ管理機構（Ａ）では、新規のユーザーＩＤであるか否かの判定が行われる（Ｓ２１０３）。新規のユーザーＩＤである場合には、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルに新規ユーザーの追加を行って（Ｓ２１０４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２１０５、Ｓ２１０６）。
【０１５５】
ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２１０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２１０８、Ｓ２１０９）。
【０１５６】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼を通知機構２０へ送信する（Ｓ２１１０、Ｓ２１１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２１１２、Ｓ２１１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２１１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２１１５、Ｓ２１１６）。
【０１５７】
通知機構２０が、公開鍵交換依頼をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２１１７、Ｓ２１１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルに新規追加を行って（Ｓ２１１９）、結果通知を通知機構２０へ返信する（Ｓ２１２０、Ｓ２１２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２１２２、Ｓ２１２３）、ＭＳＧ管理機構（Ａ）は、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２１２４、Ｓ２１２５）。
［アドレス帳リストへの追加要求の撤回］
図２２は、端末ソフトウェアの（１１）アドレス帳リストへの追加要求の撤回の処理の流れを示すシーケンス図である。図２２に示すように、アドレス帳リストへの追加要求の撤回が行われるときには、まず、端末ソフトウェア５０において、アドレス帳リスト追加の撤回指示が入力される（Ｓ２２００）。そうすると、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へアドレス帳リスト追加要求の撤回指示が送信される（Ｓ２２０１、Ｓ２２０２）。
【０１５８】
ＭＳＧ管理機構（Ａ）では、該当する追加要求があるか否かの判定が行われ（Ｓ２２０３）、該当する追加要求があると判定された場合には、交換許諾状況管理テーブルから該当する追加要求を抽出し、状況フラグの更新を行う（Ｓ２２０４）。
【０１５９】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２２０５、Ｓ２２０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２２０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２２０８、Ｓ２２０９）。
【０１６０】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼を通知機構２０へ送信する（Ｓ２２１０、Ｓ２２１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２２１２、Ｓ２２１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２２１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２２１５、Ｓ２２１６）。
【０１６１】
通知機構２０が、公開鍵交換依頼をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２２１７、Ｓ２２１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルから該当する追加要求を抽出し、そのレコードを削除して（Ｓ２２１９）、結果通知を通知機構２０へ返信する（Ｓ２２２０、Ｓ２２２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２２２２、Ｓ２２２３）、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する追加要求を抽出し、そのレコードを削除した後（Ｓ２２２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２２２５、Ｓ２２２６）。
【０１６２】
［被交換許諾依頼保留中リストの取得］
図２３は、端末ソフトウェアの（１２）被交換許諾依頼保留中リストの取得の処理の流れを示すシーケンス図である。図２３に示すように、被交換許諾依頼保留中リストの取得が行われるときには、まず、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ、被交換許諾依頼保留中リストの取得要求が送信される（Ｓ２３０、Ｓ２３１）。
【０１６３】
ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当するユーザーのレコードを抽出し（Ｓ２３２）、被交換許諾依頼保留中リストを作成する（Ｓ２３３）。そして、ＭＳＧ管理機構（Ａ）が、作成した被交換許諾依頼保留中リストを端末ソフトウェア５０へ送信すると（Ｓ２３５）、端末ソフトウェアは、取得した被交換許諾依頼保留中リストを画面に出力する（Ｓ２３６）。
【０１６４】
［被交換許諾依頼の承諾］
図２４は、端末ソフトウェアの（１３）被交換許諾依頼の承諾の処理の流れを示すシーケンス図である。図２４に示すように、被交換許諾依頼の承諾が行われるときには、まず、端末ソフトウェア５０において、被交換許諾依頼の承諾指示の入力が行われる（Ｓ２４００）。
【０１６５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ承諾指示が送信されると（Ｓ２４０１、Ｓ２４０２）、ＭＳＧ管理機構（Ａ）では、該当する被交換許諾依頼があるか否かの判定が行われる（Ｓ２４０３）。該当する被交換許諾依頼がある場合には、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する交換許諾依頼を抽出し、状況フラグの更新を行う（Ｓ２４０４）。
【０１６６】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２４０５、Ｓ２４０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２４０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２４０８、Ｓ２４０９）。
【０１６７】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼の承諾通知と公開鍵を通知機構２０へ送信する（Ｓ２４１０、Ｓ２４１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２４１２、Ｓ２４１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２４１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２４１５、Ｓ２４１６）。
【０１６８】
通知機構２０が、公開鍵交換依頼の承諾通知と公開鍵をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２４１７、Ｓ２４１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルから該当する被交換許諾依頼を抽出し、その状況フラグの更新と承諾ユーザーへの公開鍵を保存して（Ｓ２４１９）、アドレス帳管理テーブルに新規レコードを追加し（Ｓ２４２０）、結果通知を通知機構２０へ返信する（Ｓ２４２１、Ｓ２４２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２４２３、Ｓ２４２４）、ＭＳＧ管理機構（Ａ）は、アドレス帳管理テーブルに新規レコードを追加した後（Ｓ２４２５）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２４２６、Ｓ２４２７）。
【０１６９】
［被交換許諾依頼の却下］
図２５は、端末ソフトウェアの（１３）被交換許諾依頼の却下の処理の流れを示すシーケンス図である。図２５に示すように、被交換許諾依頼の却下が行われるときには、まず、端末ソフトウェア５０において、被交換許諾依頼の却下指示の入力が行われる（Ｓ２５００）。
【０１７０】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ却下指示が送信されると（Ｓ２５０１、Ｓ２５０２）、ＭＳＧ管理機構（Ａ）では、該当する被交換許諾依頼があるか否かの判定が行われる（Ｓ２５０３）。該当する被交換許諾依頼がある場合には、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する交換許諾依頼を抽出し、状況フラグの更新を行う（Ｓ２５０４）。
【０１７１】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２５０５、Ｓ２５０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２５０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２５０８、Ｓ２５０９）。
【０１７２】
つづいて、ＭＳＧ管理機構（Ａ）は、公開鍵交換依頼の却下通知を通知機構２０へ送信する（Ｓ２５１０、Ｓ２５１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２５１２、Ｓ２５１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２５１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２５１５、Ｓ２５１６）。
【０１７３】
通知機構２０が、公開鍵交換依頼の却下通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２５１７、Ｓ２５１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルから該当する被交換許諾依頼を抽出し、その状況フラグの更新を行って（Ｓ２５１９）、結果通知を通知機構２０へ返信する（Ｓ２５２０、Ｓ２５２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２５２２、Ｓ２５２３）、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する非交換許諾依頼を抽出し、そのレコードを削除した後（Ｓ２５２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２５２５、Ｓ２５２６）。
【０１７４】
［送信済みＭＳＧの訂正］
図２６は、端末ソフトウェアの（１４）送信済みＭＳＧの訂正の処理の流れを示すシーケンス図である。図２６に示すように、送信済みＭＳＧの訂正が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの内容の訂正指示の入力が行われる（Ｓ２６００）。
【０１７５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ訂正指示が送信されると（Ｓ２６０１、Ｓ２６０２）、ＭＳＧ管理機構（Ａ）では、該当するＭＳＧＩＤがあるか否かの判定が行われる（Ｓ２６０３）。該当するＭＳＧＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、訂正内容の更新を行う（Ｓ２６０４）。
【０１７６】
ＭＳＧ管理機構（Ａ）は、（宛先変更の場合には）送信ＭＳＧ管理テーブルに新規宛先ユーザーのレコードを追加し、不要レコードを削除して（Ｓ２６０５）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２６０６、Ｓ２６０７）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２６０８）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２６０９、Ｓ２６１０）。
【０１７７】
ＭＳＧ管理機構（Ａ）は、（宛先変更の場合）該当するユーザー宛のＭＳＧ作成通知または削除通知を通知機構２０へ送信する（Ｓ２６１１、Ｓ２６１２）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２６１３、Ｓ２６１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２６１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２６１６、Ｓ２６１７）。
【０１７８】
通知機構２０が、ＭＳＧ作成通知または削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２６１８、Ｓ２６１９）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルへ新規レコードの追加または該当するレコードの削除を行って（Ｓ２６２０）、結果通知を通知機構２０へ返信する（Ｓ２６２１、Ｓ２６２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２６２３、Ｓ２６２４）、ＭＳＧ管理機構（Ａ）は、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２６２５、Ｓ２６２６）。
【０１７９】
［送信済みＭＳＧの開示中止］
図２７は、端末ソフトウェアの（１４）送信済みＭＳＧの開示中止の処理の流れを示すシーケンス図である。図２７に示すように、送信済みＭＳＧの開示中止が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの開示中止指示の入力が行われる（Ｓ２７００）。
【０１８０】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ開示中止指示が送信されると（Ｓ２７０１、Ｓ２７０２）、ＭＳＧ管理機構（Ａ）では、該当するＭＳＧＩＤがあるか否かの判定が行われる（Ｓ２７０３）。該当するＭＳＧＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、開示フラグの更新を行う（Ｓ２７０４）。
【０１８１】
そして、ＭＳＧ管理機構（Ａ）は、送信ＭＳＧ管理テーブルから該当するＭＳＧＩＤのレコードを削除して（Ｓ２７０５）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２７０６、Ｓ２７０７）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２７０８）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２７０９、Ｓ２７１０）。
【０１８２】
つづいて、ＭＳＧ管理機構（Ａ）は、ＭＳＧ削除通知を通知機構２０へ送信する（Ｓ２７１１、Ｓ２７１２）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２７１３、Ｓ２７１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２７１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２７１６、Ｓ２７１７）。
【０１８３】
通知機構２０が、ＭＳＧ削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２７１８、Ｓ２７１９）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルから該当するレコードの削除を行って（Ｓ２７２０）、結果通知を通知機構２０へ返信する（Ｓ２７２１、Ｓ２７２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２７２３、Ｓ２７２４）、ＭＳＧ管理機構（Ａ）は、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２７２５、Ｓ２７２６）。
【０１８４】
［送信済みＭＳＧの削除］
図２８は、端末ソフトウェアの（１４）送信済みＭＳＧの削除の処理の流れを示すシーケンス図である。図２８に示すように、送信済みＭＳＧの削除が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの削除指示の入力が行われる（Ｓ２８００）。
【０１８５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ削除指示が送信されると（Ｓ２８０１、Ｓ２８０２）、ＭＳＧ管理機構（Ａ）では、該当するＭＳＧＩＤがあるか否かの判定が行われる（Ｓ２８０３）。該当するＭＳＧＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、開示フラグの更新を行う（Ｓ２８０４）。
【０１８６】
そして、ＭＳＧ管理機構（Ａ）は、送信ＭＳＧ管理テーブルから該当するＭＳＧＩＤのレコードを削除して（Ｓ２８０５）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２８０６、Ｓ２８０７）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２８０８）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２８０９、Ｓ２８１０）。
【０１８７】
つづいて、ＭＳＧ管理機構（Ａ）は、ＭＳＧ削除通知を通知機構２０へ送信する（Ｓ２８１１、Ｓ２８１２）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２８１３、Ｓ２８１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２８１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２８１６、Ｓ２８１７）。
【０１８８】
通知機構２０が、ＭＳＧ削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２８１８、Ｓ２８１９）、ＭＳＧ管理機構（Ｂ）は、受信ＭＳＧ管理テーブルから該当するレコードの削除を行って（Ｓ２８２０）、結果通知を通知機構２０へ返信する（Ｓ２８２１、Ｓ２８２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２８２３、Ｓ２８２４）、ＭＳＧ管理機構（Ａ）は、作成ＭＳＧ管理テーブルから該当するＭＳＧＩＤを抽出し、そのレコードを削除した後（Ｓ２８２５）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ２８２６、Ｓ２８２７）。
【０１８９】
［新規ＭＳＧの作成要求に対する応答］
図２９は、ＭＳＧ管理機構の（８）新規ＭＳＧの作成要求に対する応答の処理の流れを示すシーケンス図である。図２９に示すように、新規ＭＳＧの作成要求に対する応答（グループリストの取得）が行われるときには、まず、端末ソフトウェア５０において、特定のＭＳＧＩＤの作成指示の入力が行われる（Ｓ２９００）。
【０１９０】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へＭＳＧ作成指示が送信されると（Ｓ２９０１、Ｓ２９０２）、ＭＳＧ管理機構（Ａ）では、該当するグループＩＤがあるか否かの判定が行われる（Ｓ２９０３）。該当するグループＩＤがある場合には、ＭＳＧ管理機構（Ａ）は、該当するグループを管理するドメインＩＤを抽出して（Ｓ２９０４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２９０５、Ｓ２９０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２９０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ２９０８、Ｓ２９０９）。
【０１９１】
つづいて、ＭＳＧ管理機構（Ａ）は、グループメンバーリストの取得要求を通知機構２０へ送信する（Ｓ２９１０、Ｓ２９１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ２９１２、Ｓ２９１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ２９１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ２９１５、Ｓ２９１６）。
【０１９２】
通知機構２０が、グループメンバーリストの取得要求をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ２９１７、Ｓ２９１８）、ＭＳＧ管理機構（Ｂ）は、グループ管理テーブルから該当するグループメンバーのユーザーＩＤ、ドメインＩＤ、公開鍵を抽出して（Ｓ２９１９）、メンバーリストを通知機構２０へ返信する（Ｓ２９２０、Ｓ２９２１）。
【０１９３】
その後、通知機構２０が、そのメンバーリストをＭＳＧ管理機構（Ａ）へ転送すると（Ｓ２９２２、Ｓ２９２３）、ＭＳＧ管理機構（Ａ）は、メンバーリストからユーザーＩＤ、ドメインＩＤ、公開鍵を抽出して、グループ管理テーブルに追加する（Ｓ２９２４）。そして、ＭＳＧ管理機構（Ａ）は、グループメンバーごとのＭＳＧを作成ＭＳＧテーブルに追加して、それ以降は個人ＩＤと同様の処理を実行する（Ｓ２９２５）。
【０１９４】
［グループリスト作成要求］
図３０は、端末ソフトウェアの（１５）グループリスト作成要求の処理の流れを示すシーケンス図である。図３０に示すように、グループリスト作成要求が行われたときには、まず、端末ソフトウェア５０において、グループ名、参加ユーザー名、参加ユーザーのドメインＩＤ、参加ユーザーのユーザーＩＤの入力が行われる（Ｓ３０００）。
【０１９５】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へグループリスト作成要求が送信されると（Ｓ３００１、Ｓ３００２）、ＭＳＧ管理機構（Ａ）では、新規のグループ名であるか否かの判定が行われる（Ｓ３００３）。新規なグループ名である場合には、ＭＳＧ管理機構（Ａ）は、グループ管理テーブルに新規レコードを追加して（Ｓ３００４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３００５、Ｓ３００６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３００７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３００８、Ｓ３００９）。
【０１９６】
つづいて、ＭＳＧ管理機構（Ａ）は、グループリスト参加依頼を通知機構２０へ送信するとともに（Ｓ３０１０）、アドレス帳管理テーブルに新規レコードを追加する（Ｓ３０１１）。
【０１９７】
通知機構２０は、グループリスト参加依頼を受信すると（Ｓ３０１２）、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３０１３、Ｓ３０１４）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３０１５）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３０１６、Ｓ３０１７）。
【０１９８】
通知機構２０が、グループリスト参加依頼をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３０１８、Ｓ３０１９）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルに新規追加を行って（Ｓ３０２０）、結果通知を通知機構２０へ返信する（Ｓ３０２１、Ｓ３０２２）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ３０２３、Ｓ３０２４）、ＭＳＧ管理機構（Ａ）は、グループ管理テーブルの参加ユーザーのレコードを更新した後（Ｓ３０２５）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３０２６、Ｓ３０２７）。
【０１９９】
［グループリスト削除要求］
図３１は、端末ソフトウェアの（１６）グループリスト削除要求の処理の流れを示すシーケンス図である。図３１に示すように、グループリスト削除要求が行われたときには、まず、端末ソフトウェア５０において、グループリストの削除指示の入力が行われる（Ｓ３１００）。
【０２００】
つぎに、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へグループリスト削除要求が送信されると（Ｓ３１０１、Ｓ３１０２）、ＭＳＧ管理機構（Ａ）では、既存のグループＩＤであるか否かの判定が行われる（Ｓ３１０３）。既存のグループＩＤである場合には、ＭＳＧ管理機構（Ａ）は、グループ管理テーブルから参加ユーザーを抽出して、状況フラグを「５」に更新して（Ｓ３１０４）、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３１０５、Ｓ３１０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３１０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３１０８、Ｓ３１０９）。
【０２０１】
つづいて、ＭＳＧ管理機構（Ａ）は、グループ削除通知を通知機構２０へ送信する（Ｓ３１１０、Ｓ３１１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３１１２、Ｓ３１１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３１１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３１１５、Ｓ３１１６）。
【０２０２】
通知機構２０が、グループ削除通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３１１７、Ｓ３１１８）、ＭＳＧ管理機構（Ｂ）は、交換許諾状況管理テーブルの該当するグループＩＤのレコードを更新するとともに（Ｓ３１１９）、アドレス帳管理テーブルから該当するグループＩＤのレコードを削除する（Ｓ３１２０）。そして、ＭＳＧ管理機構（Ｂ）は、結果通知を通知機構２０へ返信するとともに（Ｓ３１２１）、交換許諾状況管理テーブルの該当するグループＩＤのレコードを削除する（Ｓ３１２２）。
【０２０３】
通知機構２０は、結果通知を受信すると（Ｓ３１２３）、その結果通知をＭＳＧ管理機構（Ａ）へ転送する（Ｓ３１２４、Ｓ３１２５）。ＭＳＧ管理機構（Ａ）は、グループ管理テーブルから該当するグループＩＤのレコードを削除するとともに（Ｓ３１２６）、グループ管理テーブルから該当するグループＩＤのレコードを削除した後（Ｓ３１２７）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３１２８、Ｓ３１２９）。
【０２０４】
［グループリスト参加保留中リストの取得］
図３２は、端末ソフトウェアの（１７）グループリスト参加保留中リストの取得の処理の流れを示すシーケンス図である。図３２に示すように、グループリスト参加保留中リストの取得が行われるときには、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ、グループリスト参加保留中リストの取得要求が送信される（Ｓ３２０、Ｓ３２１）。
【０２０５】
ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当するユーザーかつグループのレコードを抽出し（Ｓ３２２）、グループリスト参加保留中リストを作成する（Ｓ３２３）。ＭＳＧ管理機構（Ａ）が、作成したグループリスト参加保留中リストを端末ソフトウェア５０へ送信すると（Ｓ３２４、Ｓ３２５）、端末ソフトウェア５０は、取得したグループリスト参加保留中リストを画面に出力する（Ｓ３２６）。
【０２０６】
［グループリスト参加承諾通知］
図３３は、端末ソフトウェアの（１８）グループリスト参加承諾通知の処理の流れを示すシーケンス図である。図３３に示すように、グループリスト参加承諾通知が行われるときには、まず、端末ソフトウェア５０において、グループリストへの参加承諾指示が入力される（Ｓ３３００）。そうすると、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ承諾指示が送信される（Ｓ３３０１、Ｓ３３０２）。
【０２０７】
ＭＳＧ管理機構（Ａ）では、該当する依頼があるか否かの判定が行われ（Ｓ３３０３）、該当する依頼があると判定された場合には、交換許諾状況管理テーブルから該当する要求を抽出し、状況フラグの更新を行う（Ｓ３３０４）。
【０２０８】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３３０５、Ｓ３３０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３３０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３３０８、Ｓ３３０９）。
【０２０９】
つづいて、ＭＳＧ管理機構（Ａ）は、グループリスト参加の承諾通知と公開鍵を通知機構２０へ送信する（Ｓ３３１０、Ｓ３３１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３３１２、Ｓ３３１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３３１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３３１５、Ｓ３３１６）。
【０２１０】
通知機構２０が、グループリスト参加の承諾通知と公開鍵をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３３１７、Ｓ３３１８）、ＭＳＧ管理機構（Ｂ）は、グループ管理テーブルから該当する要求を抽出し、状況フラグの更新と承諾ユーザーの公開鍵を保存して（Ｓ３３１９）、結果通知を通知機構２０へ返信する（Ｓ３３２０、Ｓ３３２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ３３２２、Ｓ３３２３）、ＭＳＧ管理機構（Ａ）は、アドレス帳管理テーブルに新規レコードを追加した後（Ｓ３３２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３３２５、Ｓ３３２６）。
【０２１１】
［グループリスト参加拒否通知］
図３４は、端末ソフトウェアの（１８）グループリスト参加拒否通知の処理の流れを示すシーケンス図である。図３４に示すように、グループリスト参加拒否通知が行われるときには、まず、端末ソフトウェア５０において、グループリストへの参加許否指示が入力される（Ｓ３４００）。そうすると、端末ソフトウェア５０からＭＳＧ管理機構（Ａ）へ拒否指示が送信される（Ｓ３４０１、Ｓ３４０２）。
【０２１２】
ＭＳＧ管理機構（Ａ）では、該当する依頼があるか否かの判定が行われ（Ｓ３４０３）、該当する依頼があると判定された場合には、交換許諾状況管理テーブルから該当する要求を抽出し、状況フラグの更新を行う（Ｓ３４０４）。
【０２１３】
つぎにＭＳＧ管理機構（Ａ）は、通知機構のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３４０５、Ｓ３４０６）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３４０７）、その通知機構２０のＦＱＤＮをＭＳＧ管理機構（Ａ）へ返信する（Ｓ３４０８、Ｓ３４０９）。
【０２１４】
つづいて、ＭＳＧ管理機構（Ａ）は、グループリスト参加の拒否通知を通知機構２０へ送信する（Ｓ３４１０、Ｓ３４１１）。そうすると、通知機構２０は、ＭＳＧ管理機構（Ｂ）のＦＱＤＮ取得要求をＩＤ管理機構３０へ送信する（Ｓ３４１２、Ｓ３４１３）。ＩＤ管理機構３０は、このＦＱＤＮ取得要求に基づいて、ドメイン情報管理テーブルから該当するＦＱＤＮを抽出し（Ｓ３４１４）、そのＭＳＧ管理機構（Ｂ）のＦＱＤＮを通知機構２０へ返信する（Ｓ３４１５、Ｓ３４１６）。
【０２１５】
通知機構２０が、グループリスト参加の拒否通知をＭＳＧ管理機構（Ｂ）へ転送すると（Ｓ３４１７、Ｓ３４１８）、ＭＳＧ管理機構（Ｂ）は、グループ管理テーブルから該当する要求を抽出し、状況フラグの更新を行って（Ｓ３４１９）、結果通知を通知機構２０へ返信する（Ｓ３４２０、Ｓ３４２１）。そして、通知機構２０が、その結果通知をＭＳＧ管理機構（Ａ）へ転送すると（Ｓ３４２２、Ｓ３４２３）、ＭＳＧ管理機構（Ａ）は、交換許諾状況管理テーブルから該当する要求を抽出し、そのレコードを削除した後（Ｓ３４２４）、処理完了通知を端末ソフトウェア５０へ送信する（Ｓ３４２５、Ｓ３４２６）。
【０２１６】
以上に詳述したような本実施形態のメッセージ伝送システムによれば、従来型のメッセージ伝送システムにはない優れた作用効果が奏される。以下、それらの優れた機能の例を、図面を参照して説明しておく。
【０２１７】
図３５は、本実施形態のメッセージ伝送システムにおける送信済みＭＳＧの変更・削除機能の説明図である。本メッセージ伝送システムでは、ＭＳＧを作成して送信した後（１回目の作成要求が送信され、作成通知が発行された後）であっても、送信側の端末ソフトウェア（Ａ）において、同じＭＳＧＩＤを用いてそのＭＳＧの内容を更新することができる。また、この場合、ＭＳＧの内容が更新されても、そのＭＳＧのＭＳＧＩＤは変更されない。
【０２１８】
したがって、従来型のメッセージ伝送システムでは、いったんＭＳＧを作成した後は、その内容を変更したり削除したりすることはできなかった（新たに別のＭＳＧを送り直すことしかできなかった）のに対して、本メッセージ伝送システムでは、受信者に知られることなく、送信側のＭＳＧ管理機構（Ａ）のサーバでＭＳＧの内容変更、開示中止（ＭＳＧを完全に削除するのではなく送信者だけが利用できる状態に変更）、削除（サーバからＭＳＧを完全に削除）を行うことができる。また、同一のＭＳＧＩＤを用いたままＭＳＧの内容を更新できるため、受信者に常に最新のＭＳＧを閲覧させることができる。
【０２１９】
図３６は、本実施形態のメッセージ伝送システムにおけるメーリングリストへの送信機能の説明図である。本メッセージ伝送システムでは、メーリングリストへ送信する（宛先にグループが指定された）場合に、送信側のＭＳＧ管理機構（Ａ）において、送信グループが個別のユーザーＩＤに展開され、それぞれの受信者の公開鍵で、ＭＳＧ内容が暗号化され、ユーザーＩＤごとに一意のＭＳＧＩＤを使って宛先に通知される。そして、受信側のＭＳＧ管理機構（Ｂ）では、ユーザーＩＤごとに通知された情報に基づいて、個別に取得されるＭＳＧ内容が、各受信者の秘密鍵で復号され、各ユーザーが個別にＭＳＧを閲覧することができる。
【０２２０】
したがって、従来型のメッセージ伝送システムでは、ＷＷＷサーバにファイルを保存した旨を伝えるメールをメーリングリストへの送信を行っても、限られた数の受信者（例えば先着Ｎ番目までの受信者）しかファイルをダウンロードすることができず、どの受信者がダウンロードしたかも確認することができなかったのに対して、本メッセージ伝送システムでは、送信先のグループに含まれるすべてのユーザーがＭＳＧを閲覧することができ、どのユーザーがＭＳＧを閲覧したのかを確認（開封確認）することもできる。
【０２２１】
図３７は、本実施形態のメッセージ伝送システムにおける真正な受信者への送信機能の説明図である。本メッセージ伝送システムでは、送信側のＭＳＧ管理機構（Ａ）において、受信者Ｂの承諾が得られたら（公開鍵が取得できたら）、送信者Ａのアドレス帳に受信者ＢのＩＤや公開鍵が登録される。一方、受信側のＭＳＧ管理機構（Ｂ）においては、受信者Ｂが送信者ＡとのＭＳＧ交換を承諾したら、受信者Ｂのアドレス帳に送信者ＡのＩＤや公開鍵が登録されるとともに、送信者Ａへ自分の公開鍵を通知する。また、受信側の端末ソフトウェア（Ｂ）では、ＭＳＧの転送が制限されており、秘密鍵を用いなければＭＳＧの復号をすることができないようにされている。
【０２２２】
したがって、従来型のメッセージ伝送システムでは、送信者が送信先のアドレスを間違って入力してしまったような場合、真正な受信者に送信されたかどうかわからないのに対して、本メッセージ伝送システムでは、あらかじめＭＳＧ交換許諾を与えられた相手から公開鍵を預かり、その相手としかＭＳＧ交換を行わない（ＭＳＧは受信者の公開鍵で暗号化される）ため、全く関係のない第三者や実在しない相手に対してＭＳＧの送信を行うことがなく、情報が漏洩するおそれを低減することができる。
【０２２３】
図３８は、本実施形態のメッセージ伝送システムにおける受信者の認証機能の説明図である。本メッセージ伝送システムでは、組織や企業ごとに設置され管理されるＭＳＧ管理機構のサーバが、それぞれ属するユーザーを管理（登録、変更、削除、認証等）する機能を有しており、ＩＤ管理機構のサーバは、各ＭＳＧ管理機構を管理する機能を有するが、個別のユーザー管理は行わない。送信側のＭＳＧ管理機構は、ＩＤ管理機構に管理されている受信側のＭＳＧ管理機構が受信者の認証を行うことで、間接的に受信者の認証を行えることになる。
【０２２４】
したがって、従来型のメッセージ伝送システムでは、受信者の認証が行われておらず、仮に受信者の認証を行うとすると、すべての組織や企業のユーザーの個人情報を、例えばファイルを保存するＷＷＷサーバの管理者等の第三者に管理させることになってしまうのに対して、本メッセージ伝送システムでは、各組織や企業のユーザーの個人情報は、それぞれの組織や企業に閉じて管理したままでよく、全体を管理するＩＤ管理機構を介して、他の組織や企業のサーバに認証機能を任せることで、受信者の認証を実現できる。
【０２２５】
図３９は、本実施形態のメッセージ伝送システムにおけるＭＳＧの関連付け機能の説明図である。本メッセージ伝送システムでは、送信側と受信側の双方のＭＳＧ管理機構において、送信済み／受信済みの通知情報が保持され、また、すべてのＭＳＧに対して一意のＭＳＧのＩＤが付与される（同一のＭＳＧが更新された場合には、ＭＳＧＩＤの変更は行われない）ため、ＭＳＧを関連付けて管理することができる。また、ＭＳＧへの返信の際には返信元のＭＳＧのＩＤも付与することが可能であるため、あるＭＳＧと返信元のＭＳＧとの関連付けにも対応できる。
【０２２６】
したがって、従来型のメッセージ伝送システムでは、受信者がＭＳＧを統一的に管理することが困難であり、受信日時等でソートする程度のことしかできないのに対して、本メッセージ伝送システムでは、ＭＳＧの前後関係の把握が容易になり、内容や順番で関連づけられたスレッド等によってＭＳＧを管理することも可能になる。
【０２２７】
図４０は、本実施形態のメッセージ伝送システムにおける通知の正確性担保機能の説明図である。本メッセージ伝送システムでは、送信側のＭＳＧ管理機構のサーバが通知機構のサーバに通知を行い、通知機構のサーバが受信側のＭＳＧ管理機構サーバに伝達するプロセスが採用され、それぞれのサーバはＩＤ管理機構サーバの管理下にあり、サーバ間の通知処理の結果は依頼元に報告されるため、この報告によって、通知がどの段階まで実際に行われたか、途中で通知が阻害されていた場合にはその阻害原因が何かということを、把握することができる。
【０２２８】
したがって、従来型のメッセージ伝送システムでは、メールが相手のスパムメールフィルタによってブロックされたり、ドメイン指定拒否（携帯電話のように拒否されたことも発信者に返信しないものもある）されたり、遅延によって送達が遅れたりすることがあり、確実に相手に届いたことが保証されないのに対して、本メッセージ伝送システムでは、ＭＳＧ管理機構と通知機構との間で送受信される通知は、その都度、通知処理の結果の確認が行われるため、通知機構では、通知がどの段階であるかを把握することができ、これを、送信側のＭＳＧ管理機構に把握させることもできる。
【０２２９】
最後に、図４１に、以上に説明した本実施形態のＭＳＧ管理機構サーバの具体的構造の一例を示しておく。この例では、利用者Ａ用のＭＳＧ管理機構サーバ１０が、ネットワーク６０側のフロントエンドと、端末５０側のバックエンドとから構成されており、ネットワーク６０（この例では、ＳＳＬ通信）を介して、利用者Ｘ用のＭＳＧ管理機構サーバ１０や、利用者Ｙ用のＭＳＧ管理機構サーバ１０に接続可能である。ＭＳＧ管理機構サーバ間の通信は、既述のとおり通信機構のサーバを介してもよい。ネットワーク６０におけるこれらのサーバ間は、フルメッシュ型で接続されていてもよいし、リフレクタ型で接続されていてもよい。
【０２３０】
利用者Ａの作成したＭＳＧは、バックエンドでは利用者Ａ専用のＤＢにおいて平文で保存可能であり、フロントエンドへ送られる際に、宛先の利用者ＸあるいはＹの公開鍵で暗号化される。フロントエンドにある宛先Ｘ専用のＤＢおよび／または宛先Ｙ専用のＤＢには、ＭＳＧは暗号化された状態で保存され、その暗号化されたＭＳＧを、それぞれ利用者Ｘ／利用者Ｙが閲覧することになる。このように作成者以外の利用者に開示するＭＳＧは、改ざんや第三者による利用を制限できるようにテキストデータからバイナリデータへ変換したり、一定の利用制限がかけられるファイル形式（例えばＦＬＡＳＨやＰＤＦ等）に変換したりしたものとしてもよい。
【０２３１】
さらに、ＭＳＧの作成者が、ＭＳＧの本体に自らの望む利用条件を、ＤＲＭ（ディジタル著作権管理）情報のような形式で含ませておき、ＭＳＧ管理機構サーバが、バックエンドからフロントエンドへＭＳＧを渡す際に、作成者の設定した条件に従ってフロントエンドでのＭＳＧの保存が行われるように、制御することも可能である。そうすると、例えば、ＭＳＧを利用できる有効期限がＤＲＭ情報として設定してあれば、期限切れのＭＳＧを、宛先Ｘや宛先Ｙ用のＤＢから削除することにより、ＭＳＧをいったん発行した後でも、作成者側が指定した条件を守った利用を強制することができる。また、ＭＳＧのオリジナルを一つの場所で管理するため、監査証跡を残すことも可能になる。
【０２３２】
以上、本発明の実施形態について説明してきたが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。
【図面の簡単な説明】
【０２３３】
【図１】本発明の一実施形態に係るメッセージ（ＭＳＧ）伝送システムの構成例を示す図
【図２】端末の構成例を示す図
【図３】ＩＤ管理機構のサーバの構成例を示す図
【図４】ドメイン情報管理テーブルの一例を示す図
【図５】ＭＳＧ管理機構のサーバの構成例を示す図
【図６】ユーザー管理テーブルの一例を示す図
【図７】受信ＭＳＧ管理テーブルの一例を示す図
【図８】作成ＭＳＧ管理テーブルの一例を示す図
【図９】アドレス帳管理テーブルの一例を示す図
【図１０】グループ管理テーブルの一例を示す図
【図１１】交換許諾状況管理テーブルの一例を示す図
【図１２】送信ＭＳＧ管理テーブルの一例を示す図
【図１３】通知機構２０のサーバの構成例を示す図
【図１４】統計情報テーブルの一例を示す図
【図１５】ユーザー認証の処理の流れを示すシーケンス図
【図１６】各ＭＳＧリストの取得の処理の流れを示すシーケンス図
【図１７】各ＭＳＧリストの取得結果の表示の処理の流れを示すシーケンス図
【図１８】各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図
【図１９】各ＭＳＧリストに含まれる個別ＭＳＧの取得と表示の処理の流れを示すシーケンス図
【図２０】新規ＭＳＧの作成の処理の流れを示すシーケンス図
【図２１】アドレス帳リストへの個別追加の処理の流れを示すシーケンス図
【図２２】アドレス帳リストへの追加要求の撤回の処理の流れを示すシーケンス図
【図２３】被交換許諾依頼保留中リストの取得の処理の流れを示すシーケンス図
【図２４】被交換許諾依頼の承諾の処理の流れを示すシーケンス図
【図２５】被交換許諾依頼の却下の処理の流れを示すシーケンス図
【図２６】送信済みＭＳＧの訂正の処理の流れを示すシーケンス図
【図２７】送信済みＭＳＧの開示中止の処理の流れを示すシーケンス図
【図２８】送信済みＭＳＧの削除の処理の流れを示すシーケンス図
【図２９】新規ＭＳＧの作成要求に対する応答の処理の流れを示すシーケンス図
【図３０】グループリスト作成要求の処理の流れを示すシーケンス図
【図３１】グループリスト削除要求の処理の流れを示すシーケンス図
【図３２】グループリスト参加保留中リストの取得の処理の流れを示すシーケンス図
【図３３】グループリスト参加承諾通知の処理の流れを示すシーケンス図
【図３４】グループリストの参加拒否通知の処理の流れを示すシーケンス図
【図３５】送信済みＭＳＧの変更・削除機能の説明図
【図３６】メーリングリストへの送信機能の説明図
【図３７】真正な受信者への送信機能の説明図
【図３８】受信者の認証機能の説明図
【図３９】ＭＳＧの関連付け機能の説明図
【図４０】通知の正確性の担保機能の説明図
【図４１】ＭＳＧ管理機構のサーバの構造の具体例を示す図
【符号の説明】
【０２３４】
１０ メッセージ管理機構サーバ
２０ 通知機構サーバ
３０ ＩＤ管理機構サーバ
４０ 統計情報統合機構サーバ
５０ 端末
６０ ネットワーク
【特許請求の範囲】
【請求項１】
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムであって、
前記送信側サーバは、
送信者が前記第１の利用者群の一人であるかの認証を行う認証手段と、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する受信手段と、
受信した前記メッセージの少なくともメッセージ本体を保存する保存手段と、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する送出手段と、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する送信手段と、を備え、
前記受信側サーバは、
前記送信側サーバから送出された前記通知を保存する保存手段と、
受信者が前記第２の利用者群の一人であるかの認証を行う認証手段と、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する受信手段と、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する送出手段と、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する送信手段と、を備えることを特徴とするメッセージ伝送システム。
【請求項２】
前記通知は、前記メッセージの送信元についての情報を含み、
前記受信側サーバの前記送出手段は、前記通知が含む情報に従って特定される送信元に対応する送信側サーバへ、前記取得要求を送出するものであることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項３】
前記通知は、前記メッセージの送信元及び／又は概要についての情報を含み、
前記受信側サーバが、前記保存手段に保存された通知を、前記認証の成功した受信者の受信端末へ送信する手段をさらに備え、
前記受信端末からの閲覧要求が、前記受信者を宛先とするメッセージの中から当該受信者が前記通知の内容に基づいて選択したメッセージについての閲覧要求であることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項４】
前記受信端末からの閲覧要求が、前記受信者を宛先とする全てのメッセージについての閲覧要求であり、
前記受信側サーバの前記送信手段は、前記受信者について保存されている全ての通知に基づいて、各通知に対応する送信側サーバから収集した前記メッセージ本体を、まとめて前記受信端末へ送信するものであることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項５】
前記メッセージ本体の内容変更が、前記メッセージを作成した送信者から要求された場合に、前記送信側サーバの前記保存手段に保存されたメッセージ本体を書き換える手段を、前記送信側サーバがさらに備え、
前記送信側サーバの前記送信手段は、前記受信側サーバからの取得要求に応答して、変更後のメッセージ本体を送信することを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項６】
前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、前記送信側サーバの前記保存手段に保存されたメッセージ本体を削除する手段を、前記送信側サーバがさらに備え、
前記送信側サーバの前記送信手段は、前記受信側サーバからの取得要求に応答して、削除されたメッセージ本体の代わりに、当該メッセージ本体が削除されたことを示すメッセージを送信することを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項７】
前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、前記送信側サーバの前記保存手段に保存されたメッセージ本体を削除するとともに、前記メッセージに対応して送出された前記通知の訂正通知を、前記受信側サーバに対して送出する手段を、前記送信側サーバがさらに備え、
前記受信側サーバの前記保存手段に保存されている前記通知を前記訂正通知に基づいて削除することにより、削除された前記メッセージ本体についての取得要求が前記受信側サーバから送出されないようにすることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項８】
前記送信側サーバの前記受信手段により受信したメッセージを、当該メッセージに対応する通知を送出することなく、保存する第２の保存手段を、前記送信側サーバがさらに備え、
前記メッセージを作成した送信者からの要求が、当該メッセージの受信側への伝送を中止する要求である場合に、削除された前記メッセージ本体を、前記第２の保存手段で保存するものであることを特徴とする請求項６又は７に記載のメッセージ伝送システム。
【請求項９】
前記送信側サーバは、各受信者の公開鍵を記憶する記憶手段をさらに備え、
前記送信側サーバの前記保存手段は、前記メッセージ本体を前記メッセージの宛先である受信者の前記公開鍵で暗号化して保存するものであり、前記受信側サーバからの取得要求に応答して送信される前記メッセージ本体は、暗号化されたものとなることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項１０】
前記受信端末は、その受信端末を利用する受信者の秘密鍵を記憶するものであり、
前記受信側サーバの前記送信手段は、前記メッセージ本体を暗号化されたまま送信して、前記受信端末で復号化されるようにするものであることを特徴とする請求項９に記載のメッセージ伝送システム。
【請求項１１】
前記受信側サーバは、前記第２の利用者群の各人の秘密鍵を記憶する記憶手段をさらに備え、
前記受信側サーバの前記送信手段は、前記送信側サーバから送信された前記メッセージ本体を、当該メッセージの受信者の前記秘密鍵で復号化して、前記受信端末へ送信するものであることを特徴とする請求項９に記載のメッセージ伝送システム。
【請求項１２】
前記秘密鍵の記憶手段を備える前記受信側サーバは、前記送信側サーバから送信された前記メッセージ本体を復号化して前記受信端末へ送信した後は、復号化した前記メッセージ本体も暗号化されたままの前記メッセージ本体も、前記受信側サーバ内に残さないことを特徴とする請求項１１に記載のメッセージ伝送システム。
【請求項１３】
前記送信側サーバは、前記第１の利用者群の利用者毎に前記公開鍵の記憶手段を有し、
前記送信側サーバは、前記第１の利用者群の一人である送信者の前記記憶手段に公開鍵が記憶されていない新規受信者に対して、当該送信者からのメッセージを伝送するために、少なくとも前記送信者の情報を含む許諾依頼を前記新規受信者の利用する受信端末へ送信し、この許諾依頼に応答して前記受信端末から承諾通知が返信されてきた場合に、前記新規受信者の公開鍵を前記記憶手段に登録する手段をさらに備えることを特徴とする請求項９に記載のメッセージ伝送システム。
【請求項１４】
前記受信側サーバは、前記第２の利用者群の利用者毎に、各送信者の公開鍵を記憶する記憶手段をさらに備え、前記許諾依頼を前記受信端末へ転送する際に、この許諾依頼を一時記憶しておき、前記許諾依頼に応答する承諾通知を前記送信側サーバへ転送する際に、前記送信者の公開鍵を前記記憶手段に登録するものであることを特徴とする請求項１３に記載のメッセージ伝送システム。
【請求項１５】
前記送信側サーバは、送信端末から受信したメッセージの宛先が前記記憶手段に公開鍵が記憶されていない受信者である場合には、前記通知を送出しないことを特徴とする請求項１４に記載のメッセージ伝送システム。
【請求項１６】
前記送信側サーバの前記受信手段が受信したメッセージの宛先情報が、複数の受信者を含む場合に、前記送信側サーバは、前記メッセージの少なくともメッセージ本体を前記受信者の数だけコピーして前記保存手段に保存するものであり、
各受信者に対応する受信側サーバからの取得要求は、それぞれの受信者のタイミングで前記送信側サーバに受信され、それぞれの保存場所に保存されている前記メッセージ本体のコピーの各受信側サーバへの送信も、対応したそれぞれのタイミングで行われることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項１７】
前記送信側サーバは、各受信者の公開鍵を記憶する記憶手段をさらに備え、
前記送信側サーバの前記保存手段は、前記メッセージ本体の複数のコピーをそれぞれ対応する受信者の前記公開鍵で暗号化して保存するものであり、前記各受信側サーバからの取得要求に応答して送信される前記メッセージ本体のコピーは、暗号化されたものとなることを特徴とする請求項１６に記載のメッセージ伝送システム。
【請求項１８】
前記送信側サーバが、前記受信側サーバからの取得要求に応答して前記メッセージ本体を送信したことに基づいて、当該メッセージ本体をその宛先の受信者が取得したことを、前記メッセージを作成した送信者に対して知らせる手段をさらに備えることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項１９】
前記メッセージの保存場所を特定可能な情報は、それぞれのメッセージに対して一意に付与されるメッセージ識別子であり、メッセージ本体が書き換えられても、一旦付与されたメッセージ識別子は不変であることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２０】
前記受信端末へメッセージ本体が送信されたメッセージへの返信メッセージが、前記受信者により作成される場合、前記受信側サーバの前記保存手段に保存されている通知のうち前記メッセージに対応する通知を参照することにより、前記返信メッセージに前記メッセージのメッセージ識別子を含ませることが可能となることを特徴とする請求項１９に記載のメッセージ伝送システム。
【請求項２１】
前記第１及び第２のメッセージ管理機構が登録される全体管理サーバをさらに含み、
前記送信側サーバは、前記第２のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、前記受信側サーバへの通信を行い、
前記受信側サーバは、前記第１のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、前記送信側サーバへの通信を行うことを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２２】
前記送信側サーバと前記受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、
前記仲介サーバは、前記送信側サーバ及び前記受信側サーバのそれぞれと確認信号を交換することにより、前記送信側サーバから送出された前記通知が前記受信側サーバに受信されたかを、前記送信側サーバと前記受信側サーバの双方が確認できるようにする手段を備えることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２３】
前記送信側サーバと前記受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、
前記仲介サーバは、前記送信側サーバから前記受信側サーバへの前記通知についての処理を記録することにより、前記メッセージ伝送システムの利用状況の監視を可能にする手段を備えることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２４】
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、により実行されるメッセージ伝送方法であって、
前記送信側サーバが、
送信者が前記第１の利用者群の一人であるかの認証を行い、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信し、
受信した前記メッセージの少なくともメッセージ本体を保存し、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出し、
前記受信側サーバは、
前記送信側サーバから送出された前記通知を保存し、
受信者が前記第２の利用者群の一人であるかの認証を行い、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信し、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出し、
前記送信側サーバは、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信し、
前記受信側サーバは、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信することを特徴とするメッセージ伝送方法。
【請求項２５】
コンピュータに組み込まれることによって、該コンピュータを、
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、送信側サーバとして機能させるソフトウェアであって、
送信者が前記第１の利用者群の一人であるかの認証を行うためのプログラムコードと、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信するためのプログラムコードと、
受信した前記メッセージの少なくともメッセージ本体を保存するためのプログラムコードと、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出するためのプログラムコードと、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信するためのプログラムコードと、を備えることを特徴とするソフトウェア。
【請求項２６】
コンピュータに組み込まれることによって、該コンピュータを、
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、受信側サーバとして機能させるソフトウェアであって、
前記送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存するためのプログラムコードと、
受信者が前記第２の利用者群の一人であるかの認証を行うためのプログラムコードと、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信するためのプログラムコードと、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出するためのプログラムコードと、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信するためのプログラムコードと、を備えることを特徴とするソフトウェア。
【請求項２７】
送信側のサーバ機能と受信側のサーバ機能を利用してメッセージを伝送するシステムの構成要素となるサーバ装置であって、
当該サーバ装置が実現するメッセージ管理機構の利用者群の各利用者の情報を登録する登録手段と、
送信者が登録された前記利用者であるかの認証を行う第１の認証手段と、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する第１の受信手段と、
受信した前記メッセージの少なくともメッセージ本体を保存する第１の保存手段と、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する第１の送出手段と、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する第１の送信手段と、
送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存する第２の保存手段と、
受信者が登録された前記利用者であるかの認証を行う第２の認証手段と、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する第２の受信手段と、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する第２の送出手段と、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する第２の送信手段と、を備えることを特徴とするサーバ装置。
【請求項１】
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムであって、
前記送信側サーバは、
送信者が前記第１の利用者群の一人であるかの認証を行う認証手段と、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する受信手段と、
受信した前記メッセージの少なくともメッセージ本体を保存する保存手段と、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する送出手段と、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する送信手段と、を備え、
前記受信側サーバは、
前記送信側サーバから送出された前記通知を保存する保存手段と、
受信者が前記第２の利用者群の一人であるかの認証を行う認証手段と、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する受信手段と、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する送出手段と、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する送信手段と、を備えることを特徴とするメッセージ伝送システム。
【請求項２】
前記通知は、前記メッセージの送信元についての情報を含み、
前記受信側サーバの前記送出手段は、前記通知が含む情報に従って特定される送信元に対応する送信側サーバへ、前記取得要求を送出するものであることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項３】
前記通知は、前記メッセージの送信元及び／又は概要についての情報を含み、
前記受信側サーバが、前記保存手段に保存された通知を、前記認証の成功した受信者の受信端末へ送信する手段をさらに備え、
前記受信端末からの閲覧要求が、前記受信者を宛先とするメッセージの中から当該受信者が前記通知の内容に基づいて選択したメッセージについての閲覧要求であることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項４】
前記受信端末からの閲覧要求が、前記受信者を宛先とする全てのメッセージについての閲覧要求であり、
前記受信側サーバの前記送信手段は、前記受信者について保存されている全ての通知に基づいて、各通知に対応する送信側サーバから収集した前記メッセージ本体を、まとめて前記受信端末へ送信するものであることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項５】
前記メッセージ本体の内容変更が、前記メッセージを作成した送信者から要求された場合に、前記送信側サーバの前記保存手段に保存されたメッセージ本体を書き換える手段を、前記送信側サーバがさらに備え、
前記送信側サーバの前記送信手段は、前記受信側サーバからの取得要求に応答して、変更後のメッセージ本体を送信することを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項６】
前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、前記送信側サーバの前記保存手段に保存されたメッセージ本体を削除する手段を、前記送信側サーバがさらに備え、
前記送信側サーバの前記送信手段は、前記受信側サーバからの取得要求に応答して、削除されたメッセージ本体の代わりに、当該メッセージ本体が削除されたことを示すメッセージを送信することを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項７】
前記メッセージ本体の削除が、前記メッセージを作成した送信者から要求された場合に、前記送信側サーバの前記保存手段に保存されたメッセージ本体を削除するとともに、前記メッセージに対応して送出された前記通知の訂正通知を、前記受信側サーバに対して送出する手段を、前記送信側サーバがさらに備え、
前記受信側サーバの前記保存手段に保存されている前記通知を前記訂正通知に基づいて削除することにより、削除された前記メッセージ本体についての取得要求が前記受信側サーバから送出されないようにすることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項８】
前記送信側サーバの前記受信手段により受信したメッセージを、当該メッセージに対応する通知を送出することなく、保存する第２の保存手段を、前記送信側サーバがさらに備え、
前記メッセージを作成した送信者からの要求が、当該メッセージの受信側への伝送を中止する要求である場合に、削除された前記メッセージ本体を、前記第２の保存手段で保存するものであることを特徴とする請求項６又は７に記載のメッセージ伝送システム。
【請求項９】
前記送信側サーバは、各受信者の公開鍵を記憶する記憶手段をさらに備え、
前記送信側サーバの前記保存手段は、前記メッセージ本体を前記メッセージの宛先である受信者の前記公開鍵で暗号化して保存するものであり、前記受信側サーバからの取得要求に応答して送信される前記メッセージ本体は、暗号化されたものとなることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項１０】
前記受信端末は、その受信端末を利用する受信者の秘密鍵を記憶するものであり、
前記受信側サーバの前記送信手段は、前記メッセージ本体を暗号化されたまま送信して、前記受信端末で復号化されるようにするものであることを特徴とする請求項９に記載のメッセージ伝送システム。
【請求項１１】
前記受信側サーバは、前記第２の利用者群の各人の秘密鍵を記憶する記憶手段をさらに備え、
前記受信側サーバの前記送信手段は、前記送信側サーバから送信された前記メッセージ本体を、当該メッセージの受信者の前記秘密鍵で復号化して、前記受信端末へ送信するものであることを特徴とする請求項９に記載のメッセージ伝送システム。
【請求項１２】
前記秘密鍵の記憶手段を備える前記受信側サーバは、前記送信側サーバから送信された前記メッセージ本体を復号化して前記受信端末へ送信した後は、復号化した前記メッセージ本体も暗号化されたままの前記メッセージ本体も、前記受信側サーバ内に残さないことを特徴とする請求項１１に記載のメッセージ伝送システム。
【請求項１３】
前記送信側サーバは、前記第１の利用者群の利用者毎に前記公開鍵の記憶手段を有し、
前記送信側サーバは、前記第１の利用者群の一人である送信者の前記記憶手段に公開鍵が記憶されていない新規受信者に対して、当該送信者からのメッセージを伝送するために、少なくとも前記送信者の情報を含む許諾依頼を前記新規受信者の利用する受信端末へ送信し、この許諾依頼に応答して前記受信端末から承諾通知が返信されてきた場合に、前記新規受信者の公開鍵を前記記憶手段に登録する手段をさらに備えることを特徴とする請求項９に記載のメッセージ伝送システム。
【請求項１４】
前記受信側サーバは、前記第２の利用者群の利用者毎に、各送信者の公開鍵を記憶する記憶手段をさらに備え、前記許諾依頼を前記受信端末へ転送する際に、この許諾依頼を一時記憶しておき、前記許諾依頼に応答する承諾通知を前記送信側サーバへ転送する際に、前記送信者の公開鍵を前記記憶手段に登録するものであることを特徴とする請求項１３に記載のメッセージ伝送システム。
【請求項１５】
前記送信側サーバは、送信端末から受信したメッセージの宛先が前記記憶手段に公開鍵が記憶されていない受信者である場合には、前記通知を送出しないことを特徴とする請求項１４に記載のメッセージ伝送システム。
【請求項１６】
前記送信側サーバの前記受信手段が受信したメッセージの宛先情報が、複数の受信者を含む場合に、前記送信側サーバは、前記メッセージの少なくともメッセージ本体を前記受信者の数だけコピーして前記保存手段に保存するものであり、
各受信者に対応する受信側サーバからの取得要求は、それぞれの受信者のタイミングで前記送信側サーバに受信され、それぞれの保存場所に保存されている前記メッセージ本体のコピーの各受信側サーバへの送信も、対応したそれぞれのタイミングで行われることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項１７】
前記送信側サーバは、各受信者の公開鍵を記憶する記憶手段をさらに備え、
前記送信側サーバの前記保存手段は、前記メッセージ本体の複数のコピーをそれぞれ対応する受信者の前記公開鍵で暗号化して保存するものであり、前記各受信側サーバからの取得要求に応答して送信される前記メッセージ本体のコピーは、暗号化されたものとなることを特徴とする請求項１６に記載のメッセージ伝送システム。
【請求項１８】
前記送信側サーバが、前記受信側サーバからの取得要求に応答して前記メッセージ本体を送信したことに基づいて、当該メッセージ本体をその宛先の受信者が取得したことを、前記メッセージを作成した送信者に対して知らせる手段をさらに備えることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項１９】
前記メッセージの保存場所を特定可能な情報は、それぞれのメッセージに対して一意に付与されるメッセージ識別子であり、メッセージ本体が書き換えられても、一旦付与されたメッセージ識別子は不変であることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２０】
前記受信端末へメッセージ本体が送信されたメッセージへの返信メッセージが、前記受信者により作成される場合、前記受信側サーバの前記保存手段に保存されている通知のうち前記メッセージに対応する通知を参照することにより、前記返信メッセージに前記メッセージのメッセージ識別子を含ませることが可能となることを特徴とする請求項１９に記載のメッセージ伝送システム。
【請求項２１】
前記第１及び第２のメッセージ管理機構が登録される全体管理サーバをさらに含み、
前記送信側サーバは、前記第２のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、前記受信側サーバへの通信を行い、
前記受信側サーバは、前記第１のメッセージ管理機構が前記全体管理サーバに登録されていることを確認してから、前記送信側サーバへの通信を行うことを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２２】
前記送信側サーバと前記受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、
前記仲介サーバは、前記送信側サーバ及び前記受信側サーバのそれぞれと確認信号を交換することにより、前記送信側サーバから送出された前記通知が前記受信側サーバに受信されたかを、前記送信側サーバと前記受信側サーバの双方が確認できるようにする手段を備えることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２３】
前記送信側サーバと前記受信側サーバとの間の通信を仲介する仲介サーバをさらに含み、
前記仲介サーバは、前記送信側サーバから前記受信側サーバへの前記通知についての処理を記録することにより、前記メッセージ伝送システムの利用状況の監視を可能にする手段を備えることを特徴とする請求項１に記載のメッセージ伝送システム。
【請求項２４】
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、により実行されるメッセージ伝送方法であって、
前記送信側サーバが、
送信者が前記第１の利用者群の一人であるかの認証を行い、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信し、
受信した前記メッセージの少なくともメッセージ本体を保存し、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出し、
前記受信側サーバは、
前記送信側サーバから送出された前記通知を保存し、
受信者が前記第２の利用者群の一人であるかの認証を行い、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信し、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出し、
前記送信側サーバは、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信し、
前記受信側サーバは、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信することを特徴とするメッセージ伝送方法。
【請求項２５】
コンピュータに組み込まれることによって、該コンピュータを、
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、送信側サーバとして機能させるソフトウェアであって、
送信者が前記第１の利用者群の一人であるかの認証を行うためのプログラムコードと、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信するためのプログラムコードと、
受信した前記メッセージの少なくともメッセージ本体を保存するためのプログラムコードと、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出するためのプログラムコードと、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信するためのプログラムコードと、を備えることを特徴とするソフトウェア。
【請求項２６】
コンピュータに組み込まれることによって、該コンピュータを、
第１の利用者群が登録される第１のメッセージ管理機構の送信側サーバと、
第２の利用者群が登録される第２のメッセージ管理機構の受信側サーバと、を含むメッセージ伝送システムの、受信側サーバとして機能させるソフトウェアであって、
前記送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存するためのプログラムコードと、
受信者が前記第２の利用者群の一人であるかの認証を行うためのプログラムコードと、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信するためのプログラムコードと、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出するためのプログラムコードと、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信するためのプログラムコードと、を備えることを特徴とするソフトウェア。
【請求項２７】
送信側のサーバ機能と受信側のサーバ機能を利用してメッセージを伝送するシステムの構成要素となるサーバ装置であって、
当該サーバ装置が実現するメッセージ管理機構の利用者群の各利用者の情報を登録する登録手段と、
送信者が登録された前記利用者であるかの認証を行う第１の認証手段と、
前記認証の成功した送信者により作成されたメッセージであって、宛先情報とメッセージ本体を含むメッセージを、送信端末から受信する第１の受信手段と、
受信した前記メッセージの少なくともメッセージ本体を保存する第１の保存手段と、
前記メッセージの宛先に対応する受信側サーバに対して、前記メッセージの保存場所を特定可能な情報を含む通知を送出する第１の送出手段と、
前記受信側サーバからの取得要求に応答して、この取得要求が含む情報に従って特定される保存場所に保存されているメッセージ本体を送信する第１の送信手段と、
送信側サーバにメッセージ本体が保存されていることを示す通知を、前記送信側サーバから受信して保存する第２の保存手段と、
受信者が登録された前記利用者であるかの認証を行う第２の認証手段と、
前記認証の成功した受信者により発せられた、当該受信者を宛先とするメッセージの閲覧要求を、受信端末から受信する第２の受信手段と、
前記閲覧要求の受信を契機として、保存されている前記通知に基づく取得要求を、前記送信側サーバへ送出する第２の送出手段と、
前記送信側サーバから前記取得要求に応答して送信された前記メッセージ本体を、前記受信端末へ送信する第２の送信手段と、を備えることを特徴とするサーバ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【公開番号】特開２０１０−１０９６２９（Ｐ２０１０−１０９６２９Ａ）
【公開日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願番号】特願２００８−２７８９３７（Ｐ２００８−２７８９３７）
【出願日】平成２０年１０月２９日（２００８．１０．２９）
【出願人】（５０２４５６５７４）株式会社 インテック・ネットコア (15)
【Ｆターム（参考）】
【公開日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願日】平成２０年１０月２９日（２００８．１０．２９）
【出願人】（５０２４５６５７４）株式会社 インテック・ネットコア (15)
【Ｆターム（参考）】
[ Back to top ]