メールサーバシステム、ならびに、プログラム
【課題】ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするメールサーバシステムを提供する。
【解決手段】メールアドレスzを持つユーザBがユーザAの代表アドレスxにメール(201)を送ると、ユーザBの身元を個人情報サーバで確認(202,208)し、身元が確認できたら(209)、ユーザBからユーザA宛のメールの宛先となる個別アドレスyを生成して、ユーザBに知らせ(211)、以降は、ユーザBは、z発y宛のメール(212)を送ることとし、ユーザAがメールサーバに閲覧要求(213)するとA宛に個別アドレスで送信されたメールが閲覧応答(214)で得られることとして、代表アドレスxを公開しても迷惑メールの確認負担を低減できる。
【解決手段】メールアドレスzを持つユーザBがユーザAの代表アドレスxにメール(201)を送ると、ユーザBの身元を個人情報サーバで確認(202,208)し、身元が確認できたら(209)、ユーザBからユーザA宛のメールの宛先となる個別アドレスyを生成して、ユーザBに知らせ(211)、以降は、ユーザBは、z発y宛のメール(212)を送ることとし、ユーザAがメールサーバに閲覧要求(213)するとA宛に個別アドレスで送信されたメールが閲覧応答(214)で得られることとして、代表アドレスxを公開しても迷惑メールの確認負担を低減できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムに関する。
【背景技術】
【０００２】
従来から、迷惑メールを防止するための技術が種々提案されており、その一つに、メールの宛先と送信元をチェックする技術がある。メール本文に出現する単語の頻度情報を用いるものと異なり、本来迷惑メールと判定すべきでないメールを迷惑メールと判定してしまう欠点がない、という点で、この技術は有用性が高い。
【０００３】
メールの宛先と送信元を用いて迷惑メールを防止する技術は、たとえば、以下の文献に開示されている。
【特許文献１】特開２００２−０７３４９２号公報
【０００４】
本技術は本願発明者が考案したもので、その内容を簡単に説明すると、以下のようになる。
【０００５】
メールサーバに管理されるユーザＡは、１つの公開メールアドレスｘを有する。
【０００６】
メールアドレスｚを持つユーザＢが、初めてユーザＡにメールを送る場合は、公開メールアドレスｘをメールの宛先に指定することとなる。
【０００７】
このメールに対して、メールサーバはユーザＡにユーザＢとのメールのやりとりを承認するか問い合わせ、承認された場合、メールサーバは、ユーザＡに対して「ユーザＢ用のメールアドレス」となる個別アドレスｙを新たに生成して、ユーザＢのメールアドレスｚに、「ユーザＡにメールを送りたいときには、ｘではなくｙを宛先として使用せよ」と依頼するメールを送る。
【０００８】
これ以降、ユーザＢがユーザＡにメールを送りたいときには、送信元としてｚを、宛先としてｙを指定したメールを送らなければならない。
【０００９】
メールサーバは、ｚ発ｙ宛の電子メールについては、迷惑メールでないと判定し、そのままユーザＡに提示する。一方、ｚ発ｘ宛の電子メールについては、送信元のメールアドレスを偽装した迷惑メールであると推定して、ユーザＡには提示しない。
【００１０】
このように、メールの送信元と宛先の対が、送信元アドレスと個別アドレスの対とマッチすることが判明すれば、迷惑メールでない、と判断するのである。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、迷惑メールが多数やってきたり、存在しそうなユーザ名をランダムに選択して送信元に指定することにより送信元を偽装する迷惑メールが存在する近年の状況では、ユーザにメールのやりとりをするか否かの承認をさせることとすると、その確認作業だけで多大な労力を要することもありうる。
【００１２】
したがって、迷惑メールか否かを判定するユーザの確認負担をできるだけ低減する技術が強く求められている。
【００１３】
一方で、メールの送信元の身元保証情報を集中管理することにより、受信側および送信側での身元確認の作業負担をできるだけ低減したい、という要望もある。
【００１４】
本発明は、上記のような課題を解決するもので、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
以上の課題を解決するため、本発明の原理にしたがって、下記の発明を開示する。
【００１６】
本発明の第１の観点に係るメールサービスシステムは、メールサーバと、個人情報サーバと、を備え、以下のように構成する。
【００１７】
すなわち、メールサーバは、
管理対象のユーザの代表アドレスと、当該ユーザが閲覧対象とするメールの送信元および宛先の対に指定されるべき送信元アドレスおよび個別アドレスの対と、を対応付けて記憶するアドレス記憶部、
アドレス記憶部に記憶された代表アドレスもしくは個別アドレスが宛先に指定されたメールを受信するメール受信部、
受信されたメールの宛先がアドレス記憶部に記憶される代表アドレスのいずれかであり、当該メールの送信元を送信元アドレスとする対がアドレス記憶部において当該代表アドレスに対応付けて記憶されていない場合、当該メールの送信元を指定する問合せを、個人情報サーバに送信する確認問合せ送信部
を備える。
【００１８】
一方、個人情報サーバは、
携帯電話の個体識別番号と、当該携帯電話のユーザのメールアドレスと、を対応付けて記憶する個人情報記憶部、
メールアドレスを指定する問合せを受信する問合せ受信部、
受信された問合せに指定されるメールアドレスが、携帯電話の個体識別番号に対応付けて個人情報記憶部に記憶されていれば登録済と指定し、さもなくば未登録と指定する回答を、当該問合せの送信元に送信する回答送信部
を備える。
【００１９】
さらにメールサーバは、
確認問合せ送信部により送信された問合せに対して、個人情報サーバから送信された回答を受信する確認回答受信部、
受信されたメールにおいて、
（１）当該送信元および当該宛先の対が、アドレス記憶部に記憶される送信元アドレスおよび個別アドレスの対のいずれかである場合、当該メールを承認すべきと判定し、
（２）当該宛先が、アドレス記憶部に記憶される代表アドレスのいずれかであり、確認回答受信部により受信された回答に未登録と指定されている場合、当該メールを待機すべきと判定し、
（３）上記のいずれでもない場合、当該メールを拒否すべきと判定
する判定部、
受信されたメールと、その判定結果と、を、記憶するメール記憶部、
当該管理対象のユーザが使用する端末装置から、当該ユーザを指定するメール閲覧要求を、受信する閲覧要求受信部、
メール記憶部に承認すべきと記憶されているメールのうち、受信されたメール閲覧要求に指定されるユーザについてアドレス記憶部に記憶される代表アドレスもしくは個別アドレスを宛先とするメールを取得して、当該取得されたメールの内容を指定するメール閲覧応答を、当該ユーザが使用する端末装置へ送信する閲覧応答送信部、
受信されたメールが待機すべきと判定された場合、当該メールの送信元に登録依頼メールを送信する登録依頼送信部
をさらに備える。
【００２０】
ここで、当該登録依頼メールには、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話のブラウザを介して選択されたとすると、当該携帯電話の個体識別番号と、当該送信元のユーザのメールアドレスと、が指定された登録要求が、個人情報サーバへ送信されることとなるように、登録依頼メールの内容を構成する。
【００２１】
一方、個人情報サーバは、
携帯電話から送信された登録要求を受信する登録要求受信部、
受信された登録要求に指定される個体識別番号と、メールアドレスと、を対応付けて個人情報記憶部に追加して記憶させる個人情報登録部
をさらに備える。
【００２２】
そして、メールサーバは、
宛先がアドレス記憶部に記憶される代表アドレスであるメールが与えられると、当該代表アドレスのユーザに対して個別アドレスを新たに生成し、当該メールの送信元のアドレスおよび当該新たに生成された個別アドレスの対を、当該代表アドレスに対応付けてアドレス記憶部に追加して記憶させる生成更新部、
生成更新部に与えられたメールの送信元のアドレスへ、当該メールの宛先である代表アドレスのユーザ宛のメールにおいては新たに生成された個別アドレスを宛先として指定すべきことを依頼する宛先依頼メールを、送信する宛先依頼部、
確認回答受信部にて受信された回答に登録済と指定されている場合、受信されたメールを、生成更新部に与える自動追加処理部
をさらに備える。
【００２３】
また、本発明のメールサービスシステムにおいて、メールサーバの判定部が、受信されたメールを待機すべきと判定するのは、「当該宛先が、アドレス記憶部に記憶される代表アドレスのいずれかであり、確認回答受信部により受信された回答に未登録と指定されている場合」にかえて、「当該宛先が、アドレス記憶部に記憶される代表アドレスのいずれかであり、確認回答受信部により受信された回答に未登録と指定され、メール記憶部に、待機すべきと記憶されたメールに、受信されたメールと宛先および送信元を同じくするものが存在しない場合」であるように構成することができる。
【００２４】
また、本発明のメールサービスシステムにおいて、メールサーバの確認回答受信部にて受信された回答に登録済と指定されている場合、当該メールを、「拒否すべき」と判定するのにかえて、「承認すべき」と判定するように構成することができる。
【００２５】
また、本発明のメールサービスシステムは、以下のように構成することができる。
【００２６】
すなわち、個人情報サーバは、
受信された登録要求を送信した携帯電話、もしくは、当該登録要求に指定されるメールアドレスに、登録完了通知を送信する完了通知送信部
をさらに備える。
【００２７】
ここで、当該登録完了通知には、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話もしくは端末装置のブラウザにて処理されたとすると、当該メールアドレスが指定された追加要求が、メールサーバへ送信されることとなるように、当該登録完了通知を構成する。
【００２８】
一方、メールサーバは、
携帯電話もしくは端末装置から送信された追加要求を受信する追加要求受信部、
受信された追加要求に指定されるメールアドレスを指定する問合せを、個人情報サーバに送信する追加問合せ送信部、
追加問合せ送信部により送信された問合せに対して、個人情報サーバから送信された回答を受信する追加回答受信部、
追加回答受信部にて受信された回答に登録済と指定されている場合、メール記憶部に待機すべきと記憶されたメールのうち、受信された追加要求に指定されるメールアドレスを送信元とするメールを、生成更新部に与える追加要求処理部
をさらに備える。
【００２９】
また、本発明のメールサービスシステムにおいて、メールサーバの追加要求処理部は、メール記憶部に待機すべきと記憶されたメールのうち、受信された追加要求に指定されるメールアドレスを送信元とするメールの判定結果を、メール記憶部において承認すべきと更新するように構成することができる。
【００３０】
本発明のその他の観点に係るプログラムは、第１のコンピュータおよび第２のコンピュータを、上記のメールサービスシステムのメールサーバの各部および個人情報サーバの各部として機能させるように構成する。
【００３１】
また、本発明のプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、半導体メモリ等のコンピュータ読取可能な情報記憶媒体に記録することができる。
【００３２】
上記プログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網を介して配布・販売することができる。また、上記情報記憶媒体は、コンピュータとは独立して配布・販売することができる。
【発明の効果】
【００３３】
本発明によれば、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムを提供することができる。
【発明を実施するための最良の形態】
【００３４】
以下に本発明の実施形態を説明するが、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
【実施例１】
【００３５】
図１は、本発明の実施形態に係るメールサービスシステムおよびこれに接続される各種の機器の概要構成を示す説明図である。以下、本図を参照して説明する。
【００３６】
本図に示すメールサービスシステム１０１は、メールサーバ１３１と個人情報サーバ１５１とから構成され、両者はインターネット１７１を介して通信可能に接続されている。
【００３７】
このほか、メールサーバ１３１の管理対象とされるユーザAは、自身の端末装置１９１や携帯電話１９２（端末装置１９１としても機能する。）を用いて、メールサーバ１３１内に蓄積された自身宛のメールを閲覧することができる。閲覧の際には、ＰＯＰやＩＭＡＰなどのメール閲覧プロトコルに基づいた通信を用いても良いし、ブラウザを用いてメールを閲覧する、いわゆるウェブメールの形態を採用しても良い。
【００３８】
また、メールサーバ１３１の管理対象とされないユーザB1，B2，…,Bi，…は、自身の端末装置１９１や携帯電話１９２（端末装置１９１としても機能する。）を用いて、ユーザAのメールサーバ１３１に対して、インターネット１７１を経由しつつ、ＳＭＴＰプロトコルを用いて、メールを送信する。
【００３９】
メールのToフィールドには、当該メールの宛先のメールアドレスが指定され、Fromフィールドには、当該メールの送信元のメールアドレスが指定される。
【００４０】
したがって、ユーザBiからユーザAにメールが送信される場合には、そのメールの宛先はユーザAのメールアドレスであり、送信元はユーザBiのメールアドレスである、ということになる。
【００４１】
ここで、[特許文献１]に開示される技術、ならびに、本実施形態では、ユーザAは、代表アドレスxと個別アドレスy1，y2，…の、複数のメールアドレスを持つこととしている。
【００４２】
ここで、代表アドレスxは、名刺に印刷したりウェブサイトで公表したりするためのメールアドレスである。
【００４３】
一方、個別アドレスy1，y2，…は、それぞれ、ユーザAがメールのやりとりをすることを許可したユーザB1，B2，…のメールアドレスz1，z2，…に対応付けられている。
【００４４】
すなわち、メールサーバ１３１では、ユーザAに対して、
（１）ユーザAの代表アドレスx、および、
（２）対(ユーザB1のメールアドレスz1,個別アドレスy1)，対(ユーザB2のメールアドレスz2,個別アドレスy2)，対(ユーザB3のメールアドレスz3,個別アドレスy3)，…,対(ユーザBiのメールアドレスzi,個別アドレスyi)，…対(ユーザBnのメールアドレスzn,個別アドレスyn)
が管理されるのである。
【００４５】
典型的には、代表アドレスは「oga@144.ne.jp」のような「ユーザ名@メールサーバドメイン名」の形式を持つこととし、個別アドレスは、「ユーザ名」にランダムな文字列を付加した「oga-19234@144.ne.jp」や「oga-m9a3p@144.ne.jp」のような「ユーザ名-ランダム文字列@メールサーバドメイン名」の形式とする。ランダム文字列部分は、互いに区別が可能であり、有効なメールアドレスとして機能するものであれば、どのようなものでも良い。
【００４６】
すでに対(zi,yi)が登録されている状況下での判定基準は、以下のようになる。
（１）メールの送信元がziであり、宛先がyiであるときは、当該メールは迷惑メールではない、と判定する。
（２）メールの宛先がyiであるにもかかわらず、メールの送信元がziでない場合には、当該メールは、メールの送信元を偽装した迷惑メールである、と判定する。
（３）メールの送信元がziであるにもかかわらず、メールの宛先がxである場合には、当該メールは、メールの送信元を偽装した迷惑メールである、と判定する。
【００４７】
なお、(zi,yi)の組み合わせが何らかの手法で窃取されて偽装されてしまった場合には、迷惑メールか否かの判定は誤ることとなってしまうが、この場合は、ziに対する個別メールアドレスとして窃取されたyiにかわる新たなメールアドレスを生成して、対の内容の入れ換えを行えば良い。
【００４８】
また、何らかの事情でユーザBiとのメールのやり取りをやめたくなった場合には、ユーザAは、対(zi,yi)を削除することとする。このほか、さらに、ziをブラックリストに追加することとし、このブラックリストを参照して、個別アドレスを発行するか否かを判断することとしても良い。
【００４９】
このような手法を採用することで、迷惑メールか否かを完璧かつ自動的に判断できるのである。
【００５０】
このようなメールアドレス管理を行うため、上記のように、[特許文献１]に開示する技術では、新たなユーザBn+1がユーザAにメールのやり取りをしたいと申し込む際には、
（１）ユーザBn+1がメールアドレスzn+1発代表アドレスx宛のメールを送信し、
（２）このメールの内容をユーザAがチェックして当該ユーザBn+1とメールのやり取りをしても良いか否かを判断し、
（３）良いと判断した場合に、zn+1に対して個別メールアドレスyn+1を生成し、対(zn+1,yn+1）を追加登録するとともに、
（４）ユーザBn+1のメールアドレスyn+1に、今後自分の宛先として使用して欲しい個別メールアドレスzn+1を知らせる
こととしていた。
【００５１】
本実施形態においては、個人情報サーバ１５１を利用してユーザBn+1がメール送信に対して責任を持つことを確認して、迷惑メール送信者ないと推測することにより、ユーザAによる迷惑メールか否かを判断処理の負担を低減することとしている。
【００５２】
また、本発明では、メールの送信に対して責任を持たせるために、個人情報サーバ１５１へ携帯電話の個体識別番号（製造番号や電話番号を用いるのが典型的である。）を個人情報として登録してもらうこととしている。
【００５３】
メール送信者の立場からすれば、メール送信に責任を持つことを明確にするために、メールサーバ１３１ごとに個人情報を開示するよりも、一つの個人情報サーバ１５１に対して開示するのみとした方が抵抗が少なく、メール送信者の個人情報が漏れる機会をできるだけ減らすことができる。
【００５４】
図２は、本実施形態において、ユーザBがユーザAに対してメールのやり取りを申し込む際の通信の典型的な様子を示すセッション図である。以下、本図を参照して説明する。
【００５５】
本図に示す例では、ユーザBは、個人情報サーバ１５１に未登録である状況を想定している。
【００５６】
メールアドレスz（これは、ユーザBが端末装置１９１で使用する一般的なコンピュータ用メールアドレスであることが典型的であるが、ユーザBが携帯電話１９２で使用する携帯電話用メールアドレスであっても良い。）を用いるユーザBは、自身の端末装置１９１から、メールサーバ１３１に、ユーザAの代表アドレスxを宛先とし、自身のメールアドレスzを送信元とするメールを送信する（２０１）。
【００５７】
メールサーバ１３１がこのメールを受信すると、代表アドレスxを有するユーザAについて、送信元の要素としてzを含む対が、まだメールサーバ１３１に登録されていないため、個人情報サーバ１５１に、メールアドレスzを指定した問合せを送信する（２０２）。
【００５８】
個人情報サーバ１５１は、ユーザBのメールアドレスzが未登録である旨の回答を、メールサーバ１３１に送信する（２０３）。
【００５９】
すると、メールサーバ１３１は、メールアドレスzに、個人情報サーバ１５１への登録を促す登録依頼メールを送信する（２０４）。
【００６０】
以下では、日本で広く使われている携帯電話のブラウザ機能を採用する場合を例として考える。
【００６１】
当該登録依頼メールがＨＴＭＬ文書形式である場合には、たとえば、以下のような姿をしたa要素を含むようにする。
<a href="http://個人情報サーバ１５１のドメイン名/登録用ＣＧＩ名?addr=メールアドレスz&from=メールサーバ１３１のドメイン名" utn>ここを選択すると、あなたの携帯電話番号とメールアドレスを個人情報サーバ１５１に登録します</a>
【００６２】
また、登録依頼メールにＨＴＭＬ文書形式が利用できない場合には、このようなa要素に相当する情報を送信するフォームが内容として含まれるようなＵＲＬや、その２次元バーコードを指定しても良い。
【００６３】
ユーザBが端末装置１９１で受信した場合には、当該登録依頼メールの内容を携帯電話１９２に転送する。この際には、通常のメール転送を行っても良いし、２次元バーコードを携帯電話１９２が有するカメラで撮影して、携帯電話１９２のブラウザで当該ＵＲＬにアクセスし、画面にフォームを表示させても良い。
【００６４】
そして、ユーザが上記a要素やこれと同等なフォームのボタンを携帯電話１９２のブラウザから選択すると、個人情報サーバ１５１には、以下の情報を指定した登録要求がＨＴＴＰリクエストとして送信され（２０５）、登録ＣＧＩスクリプトが起動されることとなる。
（１）ユーザBのメールアドレスz（addrとして指定されている）。
（２）メールサーバ１３１のドメイン名（fromとして指定されている）。
（３）ユーザBが現在使用している携帯電話１９２の個体識別番号（utn属性による製造番号、付加送信される携帯電話１９２の電話番号等）。
【００６５】
登録要求を受信した個人情報サーバ１５１は、ユーザBのメールアドレスzと携帯電話１９２の個体識別番号とを対応付けて記憶する。これにより、当該個体識別番号の携帯電話１９２を有するユーザBが、メールアドレスzから送信されたメールについて、（メールアドレスの偽装がない限り）一定の責任を持つことを保証するのである。
【００６６】
登録を完了した個人情報サーバ１５１は、携帯電話１９２に対して、当該登録要求に対応するＨＴＴＰレスポンスである登録完了通知を送信する（２０６）。
【００６７】
この登録完了通知には、登録依頼メールと同様に、以下のようなa要素（もしくはこれと同等のもの）が含まれている。
<a href="http://メールサーバ１３１のドメイン名/報告用ＣＧＩ名?addr=メールアドレスz">ここを選択すると、あなたのメールアドレスが確認されたことをメールサーバ１３１に報告します</a>
【００６８】
ここで、当該a要素にて指定される「メールサーバ１３１のドメイン名」は、登録要求のfromとして指定されていたものであり、「メールアドレスz」は、登録要求のaddrとして指定されていたものである。
【００６９】
さて、ユーザBが上記のa要素（もしくはこれと同等のもの）を携帯電話１９２のブラウザから選択すると、メールサーバ１３１には、ユーザBのメールアドレスを指定した追加要求がＨＴＴＰリクエストとして送信される（２０７）。
【００７０】
なお、ユーザBが選択するのではなく、登録完了通知に上記ＵＲＬにリダイレクト（redirect）する旨を指定し、登録完了通知を受信したら、携帯電話１９２のブラウザを遷移させ、自動的にメールサーバ１３１に追加要求が送信されるような携帯を採用することとしても良い。
【００７１】
追加要求を受信したメールサーバ１３１は、これに指定されるメールアドレスzを指定した問合せを、もう一度個人情報サーバ１５１に送信する（２０８）。
【００７２】
すると、個人情報サーバ１５１は、当該メールアドレスzが登録済である旨の回答を送信してくる（２０９）。
【００７３】
これを確認して、メールサーバ１３１は、「メールアドレスzを有するユーザBがユーザAにメールを送信する際に宛先として使用すべき個別アドレスy」を生成し、対(z,y)をユーザAの代表アドレスxに対応付けて登録する。
【００７４】
そして、追加要求に対するＨＴＴＰレスポンスには、「メールアドレスz宛に、ユーザBの個別アドレスを送信した」旨を指定して送信するとともに（２１０）、メールアドレスz宛に、「代表アドレスxを有するユーザAに対して今後メールを送る際には、個別アドレスzを指定してください」という内容を指定した宛先依頼メールを送信する（２１１）。
【００７５】
これを受信したユーザBが、z発y宛のメールをメールサーバ１３１に送信すると（２１２）、当該メールは承認され、ユーザAの閲覧要求があったときに（２１３）、閲覧応答にその内容が指定されて送信されることになる（２１４）。
【００７６】
これによって、ユーザBは、個人情報サーバ１５１に登録済となる。したがって、ユーザA以外のユーザとのメールのやり取りを申し込みたいときには、上記の通信のうち、通信２０４〜２０８が実行されないこととなる。
【００７７】
また、ユーザBが、何らかの事情で、登録完了通知を受信しなかったり、追加要求を送信しなかったりした場合にも、一旦個人情報サーバ１５１に携帯電話１９２の個体識別番号とメールアドレスが登録されてしまえば、もう一度z発x宛のメールを送信することで、宛先依頼メールが返信されることになる。
【００７８】
したがって、ユーザAにとっては、到着したメールの内容を見て迷惑メールか否かの判断をする作業負担が低減される。また、ユーザBにとっても、一旦個人情報を一箇所の個人情報サーバ１５１に登録してしまえば、その後は、あるユーザの代表アドレスにメールを送付するだけで、そのユーザの個別アドレスが自動的に得られることになり、個人情報登録の作業負担や漏洩の可能性を低減することができる。
【００７９】
（各サーバの概要構成）
図３は、本実施形態に係るメールサーバ１３１の概要構成を示す説明図である。以下、本図を参照して説明する。
【００８０】
メールサーバ１３１は、アドレス記憶部３０１、メール受信部３０２、確認問合せ送信部３０３、確認回答受信部３０４、判定部３０５、メール記憶部３０６、閲覧要求受信部３０７、閲覧応答送信部３０８、登録依頼送信部３０９、生成更新部３１０、宛先依頼部３１１、自動追加処理部３１２を備える。
【００８１】
また、省略可能な要素として、追加要求受信部３１３、追加問合せ送信部３１４、追加回答受信部３１５、追加要求処理部３１６を備える。
【００８２】
図４は、本実施形態に係る個人情報サーバ１５１の概要構成を示す説明図である。以下、本図を参照して説明する。
【００８３】
個人情報サーバ１５１は、個人情報記憶部４０１、問合せ受信部４０２、回答送信部４０３、登録要求受信部４０４、個人情報登録部４０５を備える。
【００８４】
また、省略可能な要素として、完了通知送信部４０６を備える。
【００８５】
メールサーバ１３１および個人情報サーバ１５１は、それぞれ、サーバ用コンピュータにて所定のサーバ用プログラムを実行することによって実現される。典型的なサーバ用コンピュータは、ＣＰＵ（Central Processing Unit）の制御の下、一時的な記憶領域としてＲＡＭ（Random Access Memory）を、不揮発な記憶領域としてＨＤ（Hard Disk）を使用し、インターネット１７１を介した通信にはＮＩＣ（Network Interface Card）を使用する。ＣＰＵは、ＲＡＭやＨＤ等を参照し、あるいはＮＩＣを使用して、各種のデータの取得、提供、演算等の処理を行う。また、サーバ用コンピュータは、直接的または間接的に接続されたキーボードおよびモニタを用いて、維持管理が行われる。
【００８６】
サーバ用プログラムは、ＨＤに記録され、ＲＡＭに読み出されて実行される。また、その配布には、ＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）を利用したり、ＮＩＣ経由でインターネット内の他の機器からダウンロードしたりする。
【００８７】
（メールサーバ）
図５は、本実施形態に係るメールサーバ１３１にて実行されるメール処理の制御の流れを示すフローチャートである。以下、本図を参照して説明する。
【００８８】
ここで、メールサーバ１３１のアドレス記憶部３０１には、上記のように、管理対象のユーザごとに、代表アドレスと(送信元アドレス,個別アドレス)の対が記憶される。
【００８９】
また、メール記憶部３０６には、当該メールサーバ１３１の管理対象のユーザに対して送付されたメールが記憶される。
【００９０】
これらは、ＣＰＵの制御の下、ＨＤによって実現されるのが典型的である。
【００９１】
メール処理が開始されると、ＣＰＵは、ＮＩＣを監視して、インターネット１７１からパケットが到着したか否かを調べる（ステップＳ５００）到着していなければ（ステップＳ５０１；Ｎｏ）、一定時間待機した後（ステップＳ５０１）、ステップＳ５００に戻る。ステップＳ５００〜Ｓ５０２の処理は、パケットの到着を受信割込によって検知する手法で実現することも可能である。
【００９２】
パケットが到着していた場合、受信しされたパケットの種類を調べる（ステップＳ５０２）。当該パケットがメールのパケットであり、その宛先がいずれかの代表アドレスである場合（ステップＳ５０２；代表宛メール）、ステップＳ５１１に進み、当該パケットがメールのパケットであり、その宛先がいずれかの個別アドレスである場合（ステップＳ５０２；個別宛メール）、ステップＳ５３１に進む。したがって、ＣＰＵの制御の下、ＮＩＣはメール受信部３０２として機能する。
【００９３】
当該パケットが追加要求のパケットである場合（ステップＳ５０２；追加要求）、ステップＳ５５１に進む。したがって、ＣＰＵの制御の下、ＮＩＣは追加要求受信部３１３として機能する。
【００９４】
当該パケットが閲覧要求のパケットである場合（ステップＳ５０２；閲覧要求）、ステップＳ５７１に進む。したがって、ＣＰＵの制御の下、ＮＩＣは閲覧要求受信部３０７として機能する。
【００９５】
当該パケットがそれ以外のものである場合（ステップＳ５０２；その他）、当該パケットに対応する処理を実行して（ステップＳ５９１）、ステップＳ５００に戻る。
【００９６】
さて、受信したパケットが、代表アドレスを宛先とするメールである場合（ステップＳ５０２；代表宛メール）、その代表アドレスxに対応付けてアドレス記憶部３０１に記憶される対に、当該メールの送信元のメールアドレスzを含むものが存在するか否かを調べ（ステップＳ５１１）、存在する場合（ステップＳ５１１；Ｙｅｓ）、当該メールを拒否するため、ステップＳ５３４に進む。
【００９７】
一方、存在しない場合（ステップＳ５１１；Ｎｏ）、確認問合せ送信部３０３が、個人情報サーバ１５１に、当該メールアドレスzを指定した問合せを送信し（ステップＳ５１２）、確認回答受信部３０４は、当該問合せに対して個人情報サーバ１５１が送信した回答を受信する（ステップＳ５１３）。
【００９８】
したがって、ＣＰＵの制御の下、ＮＩＣは、確認問合せ送信部３０３および確認回答受信部３０４として機能する。
【００９９】
そして、ＣＰＵは、当該メールアドレスzが個人情報サーバ１５１に登録済か未登録かのいずれがこの回答に指定されているかを調べる（ステップＳ５１４）。当該回答に登録済と指定されていた場合（ステップＳ５１４；登録済）、当該メールを承認すると判定して（ステップＳ５１５）、当該メールと当該判定結果とをメール記憶部３０６に記憶させる（ステップＳ５１６）。したがって、ＣＰＵは、判定部３０５として機能する。
【０１００】
そして、ＣＰＵは、当該メールの宛先xと送信元zを参照して、個別アドレスyを生成し（ステップＳ５１７）、対(z,y)を代表アドレスxに対応付けて、アドレス記憶部３０１に追加記憶する（ステップＳ５１８）。
【０１０１】
したがって、ＣＰＵは、ＨＤと共働して、自動追加処理部３１２および生成更新部３１０として機能する。
【０１０２】
さらに、ＣＰＵは、ＮＩＣを介して、当該メールの送信元zに、宛先xのユーザ宛のメールには、今後個別アドレスyを使用するように記載された宛先依頼メールを送信し（ステップＳ５１９）、ステップＳ５００に戻る。したがって、ＮＩＣは、ＣＰＵの制御の下、宛先依頼部３１１として機能する。
【０１０３】
一方、当該回答に未登録と指定されていた場合（ステップＳ５１４；未登録）、ＣＰＵは、当該メールを待機すべきと判定して（ステップＳ５２０）、当該メールをメール記憶部３０６に記憶し（ステップＳ５２１）、当該メールの送信元zに、登録依頼メールを送信して（ステップＳ５２２）、ステップＳ５００に戻る。したがって、ＮＩＣは、ＣＰＵの制御の下、登録依頼送信部３０９として機能する。
【０１０４】
さて、送信元アドレスzのユーザが当該登録依頼メールに適切に対応すると、当該パケットとしてメールアドレスzが指定された追加要求のパケットが到達することとなる（ステップＳ５０２；追加要求）。したがって、ＣＰＵの制御の下、ＮＩＣは追加要求受信部３１３として機能する。
【０１０５】
そして、ＣＰＵは、ＮＩＣを介して、追加要求に指定されたメールアドレスzを指定した問合せを個人情報サーバ１５１に送信し（ステップＳ５５１）、その回答を受信する（ステップＳ５５２）。
【０１０６】
したがって、ＮＩＣは、ＣＰＵの制御の下、追加問合せ送信部３１４、追加回答受信部３１５として機能する。
【０１０７】
そして、その回答に指定されているのが登録済か未登録かを調べ（ステップＳ５５３）、登録済と指定されていれば（ステップＳ５５３；登録済）、メール記憶部３０６に待機すべきと記憶されているメールのうち、送信元がzであり、宛先がいずれかの代表メールアドレスであるメールを抽出し、当該抽出されたメールのそれぞれについて（ステップＳ５５４〜）以下の処理を繰り返す（〜ステップＳ５５９）。
【０１０８】
すなわち、当該メールの判定結果を承認すべきに更新し（ステップＳ５５５）、ステップＳ５１７と同様に当該メールの宛先と送信元を参照して個別アドレスを生成し（ステップＳ５５６）、ステップＳ５１８と同様に、送信元と個別アドレスの対を宛先に対応付けてアドレス記憶部に追加記憶し（ステップＳ５５７）、ステップＳ５１９と同様に送信元に、代表アドレスのユーザ宛のメールには、今後個別アドレスを使用するように記載された宛先依頼メールを送信する（ステップＳ５５８）。
【０１０９】
そして、繰り返し（ステップＳ５５４〜ステップＳ５５９）が終わったら、当該追加要求に対する成功応答（ＨＴＴＰレスポンス）を返して（ステップＳ５６０）ステップＳ５００に戻る。
【０１１０】
一方、未登録であれば（ステップＳ５５３；未登録）、当該追加要求が実行できなかった旨の失敗応答（ＨＴＴＰレスポンス）を返して（ステップＳ５６１）、ステップＳ５００に戻る。
【０１１１】
したがって、ＣＰＵは、ＨＤおよびＮＩＣと共働して、追加要求処理部３１６として機能する。
【０１１２】
さて、当該パケットがメールのパケットであり、その宛先がいずれかの個別アドレスである場合（ステップＳ５０２；個別宛メール）、当該メールの送信元と当該メールの宛先の個別アドレスとの対が、アドレス記憶部３０１に記憶されているか否かを調べ（ステップＳ５３１）、記憶されていれば（ステップＳ５３１；Ｙｅｓ）、当該メールを承認すべきと判定して（ステップＳ５３２）、当該メールと判定結果をメール記憶部３０６に記憶し（ステップＳ５３３）、ステップＳ５００に戻る。
【０１１３】
一方当該対が記憶されていなければ（ステップＳ５３１；Ｎｏ）、当該メールを拒否すべきと判定して（ステップＳ５３４）、当該メールと判定結果をメール記憶部３０６に記憶し（ステップＳ５３５）、ステップＳ５００に戻る。
【０１１４】
なお、拒否すべきと判定されたメールは、通常の迷惑メールの処理と同様に、メール記憶部３０６に記憶せず、廃棄することとしても良いし、メール記憶部３０６に記憶した後、一定期間ごとに消去することとしても良い。
【０１１５】
当該パケットが閲覧要求のパケットである場合（ステップＳ５０２；閲覧要求）、メール記憶部３０６に承認すべきと記憶されたメールのうち、当該パケットに指定されたユーザの代表アドレスもしくは個別アドレスを宛先とするメールを抽出し（ステップＳ５７１）、抽出されたメールの内容を閲覧要求の送信元に閲覧応答として送信して（ステップＳ５７２）、ステップＳ５００に戻る。この処理には、ＰＯＰやＩＭＡＰ、通常のウェブメール等の技術を適用することができる。したがって、ＣＰＵは、ＨＤやＮＩＣと共働して、閲覧応答送信部３０８として機能する。
【０１１６】
なお、「待機すべき」と判断する状況についてであるが、メールアドレスz発、代表アドレスx宛のメールについては、最初に到達したもののみを「待機すべき」と判断し、それ以降に到達したもの（「待機すべき」のメールが残っている状態で受信されたもの）は「拒否すべき」と判断することとしても良い。
【０１１７】
このほか、メールアドレスz発、いずれかの代表アドレス宛のメールについて、最初に到達したもののみを「待機すべき」と判断し、それ以降に到達したもの（「待機すべき」のメールが残っている状態で受信されたもの）は「拒否すべき」と判断することとしても良い。
【０１１８】
このような判断は、メール記憶部３０６を走査することによって可能である。
【０１１９】
このほか、「拒否すべき」と判断されたメールについては、当該メールを送信してきたメールサーバに対して、宛先が存在しない旨のエラーメールを返送しても良いし、上記のように、単に無視することとしても良い。
【０１２０】
（個人情報サーバ）
個人情報サーバ１５１は、メールサーバ１３１同様、ＣＰＵがＮＩＣを監視してパケットが到着しているか否かを判定し、到着している場合には、そのパケットの種類に応じて、問合せ回答処理、登録処理、もしくは、その他の処理を起動することを繰り返す。
【０１２１】
図６は、本実施形態に係る個人情報サーバ１５１にて実行される問合せ回答処理の制御の流れを示すフローチャートである。
【０１２２】
ＣＰＵがＮＩＣと共働して問合せ受信部４０２として機能し、問合せのパケットを受信すると（ステップＳ６０１）、ＨＤにより構成される個人情報記憶部４０１を参照して当該問合せに指定されるメールアドレスが記憶されているか否かを調べる（ステップＳ６０２）。
【０１２３】
そして、記憶されていれば（ステップＳ６０２；Ｙｅｓ）、ＣＰＵはＮＩＣを制御して、当該メールアドレスは登録済である旨の回答を送信して（ステップＳ６０３）、本処理を終了する。
【０１２４】
一方、記憶されていなければ（ステップＳ６０２；Ｎｏ）、ＣＰＵはＮＩＣを制御して、当該メールアドレスは未登録である旨の回答を送信して（ステップＳ６０４）、本処理を終了する。
【０１２５】
したがって、ＣＰＵがＮＩＣと共働して回答送信部４０３として機能する。
【０１２６】
図７は、本実施形態に係る個人情報サーバ１５１にて実行される登録処理の制御の流れを示すフローチャートである。以下、これら図を参照して説明する。
【０１２７】
ＣＰＵがＮＩＣと共働して、登録要求受信部４０４として機能して、登録要求のパケットを受信すると（ステップＳ７０１）、当該パケットに指定されたメールアドレスと携帯電話の個体識別番号とを対応付けて、ＨＤにより構成される個人情報記憶部４０１に追加記憶する（ステップＳ７０２）。したがって、ＣＰＵはＨＤと共働して、個人情報登録部４０５として機能する。
【０１２８】
そして、ＣＰＵがＮＩＣと共働して、完了通知送信部４０６として機能し、登録要求を送信した携帯電話に対して、登録要求のパケットに指定されたメールサーバ１３１を指定する完了通知を送信して（ステップＳ７０３）、本処理を終了する。
【０１２９】
なお、完了通知においてはリダイレクトを行うため、メールサーバ１３１が当該個人情報サーバ１５１と信頼関係あるいは契約関係にある有効なものであるか否かを判定することが望ましい。
【０１３０】
なお、メールサーバ１３１や個人情報サーバ１５１において、上記の省略可能な要素を省略した場合には、上記フローから当該要素に相当する処理を適宜省略することができる。
【実施例２】
【０１３１】
上記の実施例に加えて、以下のような種々の態様を採用することができる。
【０１３２】
第１に、ブラックリストを用いて個別アドレスの発行を拒否する相手を管理する手法については、さらに一歩進んで、以下のような手法をとることができる。
【０１３３】
すなわち、個人情報サーバ１５１は、メールアドレスと個体識別番号を対応付けて記録する際に、当該レコードのＩＤをユニークに決定する。これには、登録順序の番号を使用しても良いし、何らかの乱数を組み合わせたり、登録日時を一部に用いる等が可能である。
【０１３４】
そして、メールサーバ１３１から個人情報サーバ１５１へ問合せを行うと、回答には、登録済か未登録か、のほかに、レコードのＩＤが指定されてくることとする。
【０１３５】
そして、メールサーバ１３１では、ブラックリストにzを追加するのではなく、このＩＤを追加することとし、個別アドレスを発行するか否かの判断基準に、送信元のメールアドレスに対して回答されたＩＤがブラックリストに含まれないか含まれるか、も入れるのである。
【０１３６】
このような処理を行うと、１つの携帯電話で複数のメールアドレスを登録したり、メールアドレスを登録し直したりした場合であっても、携帯電話を基準にメールのやり取りをしたくないユーザであるか否かを判定することができる。
【０１３７】
また、メールサーバ１３１にてブラックリストに掲載された旨を個人情報サーバ１５１に通知することとし、その回数が多い場合には、問合せに対する回答に、そのような情報を含めることとして、個別アドレスの発行の可否の判断基準として、以前にその携帯電話がブラックリストに掲載された回数が何回であるか等を含めた処理を行っても良い。
【０１３８】
また、回答に毎回ＩＤを含めたり、ブラックリスト掲載回数が指定されるのではなく、メールサーバ１３１からブラックリストに追加したいメールアドレスを個人情報サーバ１５１に通知すると、その旨の情報が個人情報サーバ１５１で蓄積され、回答には、当該メールアドレスに対応付けられる携帯電話の個体識別番号についてのブラックリスト掲載回数が、一定閾値を超えているか否かのみの情報を指定することとする手法もある。
【０１３９】
この場合、メールサーバ１３１では、閾値を超えていると指定された場合には、自動的に個別アドレスの発行を拒否することとしても良いし、その旨を受信側ユーザに通知して、ユーザ自身に個別アドレスの発行の可否を判断させることとしても良い。
【０１４０】
第２に、承認するか否かの判断基準に、発信元アドレスそのものではなく、そのドメイン名を用いる、という手法である。
【０１４１】
たとえば、ある会社がメールマガジンを多くのユーザに発送したい場合を考える。この会社から発送されるメールマガジンの送信元は、ドメイン名は共通するが、ユーザ名が異なることがあり、また、ユーザ名が新しく作られることもある。
【０１４２】
そこで、個人情報サーバ１５１には、当該会社が所有する携帯電話の個体識別番号と、そのドメイン名と、を登録しておく。あるいは、その会社の何らかの信用情報を、携帯電話の個体識別番号のかわりに使うこととして、ドメイン名を組み合わせて登録することとしても良い。
【０１４３】
すなわち、「携帯電話の個体識別番号とメールアドレスの組み合わせ」のかわりに、「会社が信用できることを確認した旨の情報とドメイン名の組み合わせ」を用いることも可能とするのである。
【０１４４】
このような場合に、会社Ｂがユーザ名uとドメイン名dからなるメールアドレスu@dを用いてユーザＡの公開メールアドレスxに対して、最初のメールマガジンを発送すると、メールサーバ１３１から個人情報サーバ１５１に、u@dを指定した問合せがされる。
【０１４５】
個人情報サーバ１５１は、dがその会社のドメイン名であることから、登録済と回答することとなる。
【０１４６】
すると、メールサーバ１３１から、ユーザＡ用に生成された個別アドレスyが、u@d宛に送られてくる。そこで、会社Ｂでは、ユーザＡ用のメールマガジンの宛先をxからyに変更する。
【０１４７】
これらの処理をコンピュータに行わせることにより、メールマガジンの宛先管理を自動化することも可能である。
【産業上の利用可能性】
【０１４８】
本発明によれば、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムを提供することができる。
【図面の簡単な説明】
【０１４９】
【図１】本発明の実施形態に係るメールサービスシステムの概要構成を示す説明図である。
【図２】本実施形態に係るメールサーバ、個人情報サーバ、端末装置、携帯電話の間の通信の様子を示すセッション図である。
【図３】本実施形態に係るメールサーバの概要構成を示す説明図である。
【図４】本実施形態に係る個人情報サーバの概要構成を示す説明図である。
【図５】本実施形態に係るメールサーバにて実行されるメール処理の制御の流れを示すフローチャートである。
【図６】本実施形態に係る個人情報サーバにて実行される問合せ回答処理の制御の流れを示すフローチャートである。
【図７】本実施形態に係る個人情報サーバにて実行される登録処理の制御の流れを示すフローチャートである。
【符号の説明】
【０１５０】
１０１ メールサービスシステム
１３１ メールサーバ
１５１ 個人情報サーバ
１７１ インターネット
１９１ 端末装置
１９２ 携帯電話
３０１ アドレス記憶部
３０２ メール受信部
３０３ 確認問合せ送信部
３０４ 確認回答受信部
３０５ 判定部
３０６ メール記憶部
３０７ 閲覧要求受信部
３０８ 閲覧応答送信部
３０９ 登録依頼送信部
３１０ 生成更新部
３１１ 宛先依頼部
３１２ 自動追加処理部
３１３ 追加要求受信部
３１４ 追加問合せ送信部
３１５ 追加回答受信部
３１６ 追加要求処理部
４０１ 個人情報記憶部
４０２ 問合せ受信部
４０３ 回答送信部
４０４ 登録要求受信部
４０５ 個人情報登録部
４０６ 完了通知送信部
【技術分野】
【０００１】
本発明は、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムに関する。
【背景技術】
【０００２】
従来から、迷惑メールを防止するための技術が種々提案されており、その一つに、メールの宛先と送信元をチェックする技術がある。メール本文に出現する単語の頻度情報を用いるものと異なり、本来迷惑メールと判定すべきでないメールを迷惑メールと判定してしまう欠点がない、という点で、この技術は有用性が高い。
【０００３】
メールの宛先と送信元を用いて迷惑メールを防止する技術は、たとえば、以下の文献に開示されている。
【特許文献１】特開２００２−０７３４９２号公報
【０００４】
本技術は本願発明者が考案したもので、その内容を簡単に説明すると、以下のようになる。
【０００５】
メールサーバに管理されるユーザＡは、１つの公開メールアドレスｘを有する。
【０００６】
メールアドレスｚを持つユーザＢが、初めてユーザＡにメールを送る場合は、公開メールアドレスｘをメールの宛先に指定することとなる。
【０００７】
このメールに対して、メールサーバはユーザＡにユーザＢとのメールのやりとりを承認するか問い合わせ、承認された場合、メールサーバは、ユーザＡに対して「ユーザＢ用のメールアドレス」となる個別アドレスｙを新たに生成して、ユーザＢのメールアドレスｚに、「ユーザＡにメールを送りたいときには、ｘではなくｙを宛先として使用せよ」と依頼するメールを送る。
【０００８】
これ以降、ユーザＢがユーザＡにメールを送りたいときには、送信元としてｚを、宛先としてｙを指定したメールを送らなければならない。
【０００９】
メールサーバは、ｚ発ｙ宛の電子メールについては、迷惑メールでないと判定し、そのままユーザＡに提示する。一方、ｚ発ｘ宛の電子メールについては、送信元のメールアドレスを偽装した迷惑メールであると推定して、ユーザＡには提示しない。
【００１０】
このように、メールの送信元と宛先の対が、送信元アドレスと個別アドレスの対とマッチすることが判明すれば、迷惑メールでない、と判断するのである。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、迷惑メールが多数やってきたり、存在しそうなユーザ名をランダムに選択して送信元に指定することにより送信元を偽装する迷惑メールが存在する近年の状況では、ユーザにメールのやりとりをするか否かの承認をさせることとすると、その確認作業だけで多大な労力を要することもありうる。
【００１２】
したがって、迷惑メールか否かを判定するユーザの確認負担をできるだけ低減する技術が強く求められている。
【００１３】
一方で、メールの送信元の身元保証情報を集中管理することにより、受信側および送信側での身元確認の作業負担をできるだけ低減したい、という要望もある。
【００１４】
本発明は、上記のような課題を解決するもので、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
以上の課題を解決するため、本発明の原理にしたがって、下記の発明を開示する。
【００１６】
本発明の第１の観点に係るメールサービスシステムは、メールサーバと、個人情報サーバと、を備え、以下のように構成する。
【００１７】
すなわち、メールサーバは、
管理対象のユーザの代表アドレスと、当該ユーザが閲覧対象とするメールの送信元および宛先の対に指定されるべき送信元アドレスおよび個別アドレスの対と、を対応付けて記憶するアドレス記憶部、
アドレス記憶部に記憶された代表アドレスもしくは個別アドレスが宛先に指定されたメールを受信するメール受信部、
受信されたメールの宛先がアドレス記憶部に記憶される代表アドレスのいずれかであり、当該メールの送信元を送信元アドレスとする対がアドレス記憶部において当該代表アドレスに対応付けて記憶されていない場合、当該メールの送信元を指定する問合せを、個人情報サーバに送信する確認問合せ送信部
を備える。
【００１８】
一方、個人情報サーバは、
携帯電話の個体識別番号と、当該携帯電話のユーザのメールアドレスと、を対応付けて記憶する個人情報記憶部、
メールアドレスを指定する問合せを受信する問合せ受信部、
受信された問合せに指定されるメールアドレスが、携帯電話の個体識別番号に対応付けて個人情報記憶部に記憶されていれば登録済と指定し、さもなくば未登録と指定する回答を、当該問合せの送信元に送信する回答送信部
を備える。
【００１９】
さらにメールサーバは、
確認問合せ送信部により送信された問合せに対して、個人情報サーバから送信された回答を受信する確認回答受信部、
受信されたメールにおいて、
（１）当該送信元および当該宛先の対が、アドレス記憶部に記憶される送信元アドレスおよび個別アドレスの対のいずれかである場合、当該メールを承認すべきと判定し、
（２）当該宛先が、アドレス記憶部に記憶される代表アドレスのいずれかであり、確認回答受信部により受信された回答に未登録と指定されている場合、当該メールを待機すべきと判定し、
（３）上記のいずれでもない場合、当該メールを拒否すべきと判定
する判定部、
受信されたメールと、その判定結果と、を、記憶するメール記憶部、
当該管理対象のユーザが使用する端末装置から、当該ユーザを指定するメール閲覧要求を、受信する閲覧要求受信部、
メール記憶部に承認すべきと記憶されているメールのうち、受信されたメール閲覧要求に指定されるユーザについてアドレス記憶部に記憶される代表アドレスもしくは個別アドレスを宛先とするメールを取得して、当該取得されたメールの内容を指定するメール閲覧応答を、当該ユーザが使用する端末装置へ送信する閲覧応答送信部、
受信されたメールが待機すべきと判定された場合、当該メールの送信元に登録依頼メールを送信する登録依頼送信部
をさらに備える。
【００２０】
ここで、当該登録依頼メールには、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話のブラウザを介して選択されたとすると、当該携帯電話の個体識別番号と、当該送信元のユーザのメールアドレスと、が指定された登録要求が、個人情報サーバへ送信されることとなるように、登録依頼メールの内容を構成する。
【００２１】
一方、個人情報サーバは、
携帯電話から送信された登録要求を受信する登録要求受信部、
受信された登録要求に指定される個体識別番号と、メールアドレスと、を対応付けて個人情報記憶部に追加して記憶させる個人情報登録部
をさらに備える。
【００２２】
そして、メールサーバは、
宛先がアドレス記憶部に記憶される代表アドレスであるメールが与えられると、当該代表アドレスのユーザに対して個別アドレスを新たに生成し、当該メールの送信元のアドレスおよび当該新たに生成された個別アドレスの対を、当該代表アドレスに対応付けてアドレス記憶部に追加して記憶させる生成更新部、
生成更新部に与えられたメールの送信元のアドレスへ、当該メールの宛先である代表アドレスのユーザ宛のメールにおいては新たに生成された個別アドレスを宛先として指定すべきことを依頼する宛先依頼メールを、送信する宛先依頼部、
確認回答受信部にて受信された回答に登録済と指定されている場合、受信されたメールを、生成更新部に与える自動追加処理部
をさらに備える。
【００２３】
また、本発明のメールサービスシステムにおいて、メールサーバの判定部が、受信されたメールを待機すべきと判定するのは、「当該宛先が、アドレス記憶部に記憶される代表アドレスのいずれかであり、確認回答受信部により受信された回答に未登録と指定されている場合」にかえて、「当該宛先が、アドレス記憶部に記憶される代表アドレスのいずれかであり、確認回答受信部により受信された回答に未登録と指定され、メール記憶部に、待機すべきと記憶されたメールに、受信されたメールと宛先および送信元を同じくするものが存在しない場合」であるように構成することができる。
【００２４】
また、本発明のメールサービスシステムにおいて、メールサーバの確認回答受信部にて受信された回答に登録済と指定されている場合、当該メールを、「拒否すべき」と判定するのにかえて、「承認すべき」と判定するように構成することができる。
【００２５】
また、本発明のメールサービスシステムは、以下のように構成することができる。
【００２６】
すなわち、個人情報サーバは、
受信された登録要求を送信した携帯電話、もしくは、当該登録要求に指定されるメールアドレスに、登録完了通知を送信する完了通知送信部
をさらに備える。
【００２７】
ここで、当該登録完了通知には、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話もしくは端末装置のブラウザにて処理されたとすると、当該メールアドレスが指定された追加要求が、メールサーバへ送信されることとなるように、当該登録完了通知を構成する。
【００２８】
一方、メールサーバは、
携帯電話もしくは端末装置から送信された追加要求を受信する追加要求受信部、
受信された追加要求に指定されるメールアドレスを指定する問合せを、個人情報サーバに送信する追加問合せ送信部、
追加問合せ送信部により送信された問合せに対して、個人情報サーバから送信された回答を受信する追加回答受信部、
追加回答受信部にて受信された回答に登録済と指定されている場合、メール記憶部に待機すべきと記憶されたメールのうち、受信された追加要求に指定されるメールアドレスを送信元とするメールを、生成更新部に与える追加要求処理部
をさらに備える。
【００２９】
また、本発明のメールサービスシステムにおいて、メールサーバの追加要求処理部は、メール記憶部に待機すべきと記憶されたメールのうち、受信された追加要求に指定されるメールアドレスを送信元とするメールの判定結果を、メール記憶部において承認すべきと更新するように構成することができる。
【００３０】
本発明のその他の観点に係るプログラムは、第１のコンピュータおよび第２のコンピュータを、上記のメールサービスシステムのメールサーバの各部および個人情報サーバの各部として機能させるように構成する。
【００３１】
また、本発明のプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、半導体メモリ等のコンピュータ読取可能な情報記憶媒体に記録することができる。
【００３２】
上記プログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網を介して配布・販売することができる。また、上記情報記憶媒体は、コンピュータとは独立して配布・販売することができる。
【発明の効果】
【００３３】
本発明によれば、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムを提供することができる。
【発明を実施するための最良の形態】
【００３４】
以下に本発明の実施形態を説明するが、以下に説明する実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
【実施例１】
【００３５】
図１は、本発明の実施形態に係るメールサービスシステムおよびこれに接続される各種の機器の概要構成を示す説明図である。以下、本図を参照して説明する。
【００３６】
本図に示すメールサービスシステム１０１は、メールサーバ１３１と個人情報サーバ１５１とから構成され、両者はインターネット１７１を介して通信可能に接続されている。
【００３７】
このほか、メールサーバ１３１の管理対象とされるユーザAは、自身の端末装置１９１や携帯電話１９２（端末装置１９１としても機能する。）を用いて、メールサーバ１３１内に蓄積された自身宛のメールを閲覧することができる。閲覧の際には、ＰＯＰやＩＭＡＰなどのメール閲覧プロトコルに基づいた通信を用いても良いし、ブラウザを用いてメールを閲覧する、いわゆるウェブメールの形態を採用しても良い。
【００３８】
また、メールサーバ１３１の管理対象とされないユーザB1，B2，…,Bi，…は、自身の端末装置１９１や携帯電話１９２（端末装置１９１としても機能する。）を用いて、ユーザAのメールサーバ１３１に対して、インターネット１７１を経由しつつ、ＳＭＴＰプロトコルを用いて、メールを送信する。
【００３９】
メールのToフィールドには、当該メールの宛先のメールアドレスが指定され、Fromフィールドには、当該メールの送信元のメールアドレスが指定される。
【００４０】
したがって、ユーザBiからユーザAにメールが送信される場合には、そのメールの宛先はユーザAのメールアドレスであり、送信元はユーザBiのメールアドレスである、ということになる。
【００４１】
ここで、[特許文献１]に開示される技術、ならびに、本実施形態では、ユーザAは、代表アドレスxと個別アドレスy1，y2，…の、複数のメールアドレスを持つこととしている。
【００４２】
ここで、代表アドレスxは、名刺に印刷したりウェブサイトで公表したりするためのメールアドレスである。
【００４３】
一方、個別アドレスy1，y2，…は、それぞれ、ユーザAがメールのやりとりをすることを許可したユーザB1，B2，…のメールアドレスz1，z2，…に対応付けられている。
【００４４】
すなわち、メールサーバ１３１では、ユーザAに対して、
（１）ユーザAの代表アドレスx、および、
（２）対(ユーザB1のメールアドレスz1,個別アドレスy1)，対(ユーザB2のメールアドレスz2,個別アドレスy2)，対(ユーザB3のメールアドレスz3,個別アドレスy3)，…,対(ユーザBiのメールアドレスzi,個別アドレスyi)，…対(ユーザBnのメールアドレスzn,個別アドレスyn)
が管理されるのである。
【００４５】
典型的には、代表アドレスは「oga@144.ne.jp」のような「ユーザ名@メールサーバドメイン名」の形式を持つこととし、個別アドレスは、「ユーザ名」にランダムな文字列を付加した「oga-19234@144.ne.jp」や「oga-m9a3p@144.ne.jp」のような「ユーザ名-ランダム文字列@メールサーバドメイン名」の形式とする。ランダム文字列部分は、互いに区別が可能であり、有効なメールアドレスとして機能するものであれば、どのようなものでも良い。
【００４６】
すでに対(zi,yi)が登録されている状況下での判定基準は、以下のようになる。
（１）メールの送信元がziであり、宛先がyiであるときは、当該メールは迷惑メールではない、と判定する。
（２）メールの宛先がyiであるにもかかわらず、メールの送信元がziでない場合には、当該メールは、メールの送信元を偽装した迷惑メールである、と判定する。
（３）メールの送信元がziであるにもかかわらず、メールの宛先がxである場合には、当該メールは、メールの送信元を偽装した迷惑メールである、と判定する。
【００４７】
なお、(zi,yi)の組み合わせが何らかの手法で窃取されて偽装されてしまった場合には、迷惑メールか否かの判定は誤ることとなってしまうが、この場合は、ziに対する個別メールアドレスとして窃取されたyiにかわる新たなメールアドレスを生成して、対の内容の入れ換えを行えば良い。
【００４８】
また、何らかの事情でユーザBiとのメールのやり取りをやめたくなった場合には、ユーザAは、対(zi,yi)を削除することとする。このほか、さらに、ziをブラックリストに追加することとし、このブラックリストを参照して、個別アドレスを発行するか否かを判断することとしても良い。
【００４９】
このような手法を採用することで、迷惑メールか否かを完璧かつ自動的に判断できるのである。
【００５０】
このようなメールアドレス管理を行うため、上記のように、[特許文献１]に開示する技術では、新たなユーザBn+1がユーザAにメールのやり取りをしたいと申し込む際には、
（１）ユーザBn+1がメールアドレスzn+1発代表アドレスx宛のメールを送信し、
（２）このメールの内容をユーザAがチェックして当該ユーザBn+1とメールのやり取りをしても良いか否かを判断し、
（３）良いと判断した場合に、zn+1に対して個別メールアドレスyn+1を生成し、対(zn+1,yn+1）を追加登録するとともに、
（４）ユーザBn+1のメールアドレスyn+1に、今後自分の宛先として使用して欲しい個別メールアドレスzn+1を知らせる
こととしていた。
【００５１】
本実施形態においては、個人情報サーバ１５１を利用してユーザBn+1がメール送信に対して責任を持つことを確認して、迷惑メール送信者ないと推測することにより、ユーザAによる迷惑メールか否かを判断処理の負担を低減することとしている。
【００５２】
また、本発明では、メールの送信に対して責任を持たせるために、個人情報サーバ１５１へ携帯電話の個体識別番号（製造番号や電話番号を用いるのが典型的である。）を個人情報として登録してもらうこととしている。
【００５３】
メール送信者の立場からすれば、メール送信に責任を持つことを明確にするために、メールサーバ１３１ごとに個人情報を開示するよりも、一つの個人情報サーバ１５１に対して開示するのみとした方が抵抗が少なく、メール送信者の個人情報が漏れる機会をできるだけ減らすことができる。
【００５４】
図２は、本実施形態において、ユーザBがユーザAに対してメールのやり取りを申し込む際の通信の典型的な様子を示すセッション図である。以下、本図を参照して説明する。
【００５５】
本図に示す例では、ユーザBは、個人情報サーバ１５１に未登録である状況を想定している。
【００５６】
メールアドレスz（これは、ユーザBが端末装置１９１で使用する一般的なコンピュータ用メールアドレスであることが典型的であるが、ユーザBが携帯電話１９２で使用する携帯電話用メールアドレスであっても良い。）を用いるユーザBは、自身の端末装置１９１から、メールサーバ１３１に、ユーザAの代表アドレスxを宛先とし、自身のメールアドレスzを送信元とするメールを送信する（２０１）。
【００５７】
メールサーバ１３１がこのメールを受信すると、代表アドレスxを有するユーザAについて、送信元の要素としてzを含む対が、まだメールサーバ１３１に登録されていないため、個人情報サーバ１５１に、メールアドレスzを指定した問合せを送信する（２０２）。
【００５８】
個人情報サーバ１５１は、ユーザBのメールアドレスzが未登録である旨の回答を、メールサーバ１３１に送信する（２０３）。
【００５９】
すると、メールサーバ１３１は、メールアドレスzに、個人情報サーバ１５１への登録を促す登録依頼メールを送信する（２０４）。
【００６０】
以下では、日本で広く使われている携帯電話のブラウザ機能を採用する場合を例として考える。
【００６１】
当該登録依頼メールがＨＴＭＬ文書形式である場合には、たとえば、以下のような姿をしたa要素を含むようにする。
<a href="http://個人情報サーバ１５１のドメイン名/登録用ＣＧＩ名?addr=メールアドレスz&from=メールサーバ１３１のドメイン名" utn>ここを選択すると、あなたの携帯電話番号とメールアドレスを個人情報サーバ１５１に登録します</a>
【００６２】
また、登録依頼メールにＨＴＭＬ文書形式が利用できない場合には、このようなa要素に相当する情報を送信するフォームが内容として含まれるようなＵＲＬや、その２次元バーコードを指定しても良い。
【００６３】
ユーザBが端末装置１９１で受信した場合には、当該登録依頼メールの内容を携帯電話１９２に転送する。この際には、通常のメール転送を行っても良いし、２次元バーコードを携帯電話１９２が有するカメラで撮影して、携帯電話１９２のブラウザで当該ＵＲＬにアクセスし、画面にフォームを表示させても良い。
【００６４】
そして、ユーザが上記a要素やこれと同等なフォームのボタンを携帯電話１９２のブラウザから選択すると、個人情報サーバ１５１には、以下の情報を指定した登録要求がＨＴＴＰリクエストとして送信され（２０５）、登録ＣＧＩスクリプトが起動されることとなる。
（１）ユーザBのメールアドレスz（addrとして指定されている）。
（２）メールサーバ１３１のドメイン名（fromとして指定されている）。
（３）ユーザBが現在使用している携帯電話１９２の個体識別番号（utn属性による製造番号、付加送信される携帯電話１９２の電話番号等）。
【００６５】
登録要求を受信した個人情報サーバ１５１は、ユーザBのメールアドレスzと携帯電話１９２の個体識別番号とを対応付けて記憶する。これにより、当該個体識別番号の携帯電話１９２を有するユーザBが、メールアドレスzから送信されたメールについて、（メールアドレスの偽装がない限り）一定の責任を持つことを保証するのである。
【００６６】
登録を完了した個人情報サーバ１５１は、携帯電話１９２に対して、当該登録要求に対応するＨＴＴＰレスポンスである登録完了通知を送信する（２０６）。
【００６７】
この登録完了通知には、登録依頼メールと同様に、以下のようなa要素（もしくはこれと同等のもの）が含まれている。
<a href="http://メールサーバ１３１のドメイン名/報告用ＣＧＩ名?addr=メールアドレスz">ここを選択すると、あなたのメールアドレスが確認されたことをメールサーバ１３１に報告します</a>
【００６８】
ここで、当該a要素にて指定される「メールサーバ１３１のドメイン名」は、登録要求のfromとして指定されていたものであり、「メールアドレスz」は、登録要求のaddrとして指定されていたものである。
【００６９】
さて、ユーザBが上記のa要素（もしくはこれと同等のもの）を携帯電話１９２のブラウザから選択すると、メールサーバ１３１には、ユーザBのメールアドレスを指定した追加要求がＨＴＴＰリクエストとして送信される（２０７）。
【００７０】
なお、ユーザBが選択するのではなく、登録完了通知に上記ＵＲＬにリダイレクト（redirect）する旨を指定し、登録完了通知を受信したら、携帯電話１９２のブラウザを遷移させ、自動的にメールサーバ１３１に追加要求が送信されるような携帯を採用することとしても良い。
【００７１】
追加要求を受信したメールサーバ１３１は、これに指定されるメールアドレスzを指定した問合せを、もう一度個人情報サーバ１５１に送信する（２０８）。
【００７２】
すると、個人情報サーバ１５１は、当該メールアドレスzが登録済である旨の回答を送信してくる（２０９）。
【００７３】
これを確認して、メールサーバ１３１は、「メールアドレスzを有するユーザBがユーザAにメールを送信する際に宛先として使用すべき個別アドレスy」を生成し、対(z,y)をユーザAの代表アドレスxに対応付けて登録する。
【００７４】
そして、追加要求に対するＨＴＴＰレスポンスには、「メールアドレスz宛に、ユーザBの個別アドレスを送信した」旨を指定して送信するとともに（２１０）、メールアドレスz宛に、「代表アドレスxを有するユーザAに対して今後メールを送る際には、個別アドレスzを指定してください」という内容を指定した宛先依頼メールを送信する（２１１）。
【００７５】
これを受信したユーザBが、z発y宛のメールをメールサーバ１３１に送信すると（２１２）、当該メールは承認され、ユーザAの閲覧要求があったときに（２１３）、閲覧応答にその内容が指定されて送信されることになる（２１４）。
【００７６】
これによって、ユーザBは、個人情報サーバ１５１に登録済となる。したがって、ユーザA以外のユーザとのメールのやり取りを申し込みたいときには、上記の通信のうち、通信２０４〜２０８が実行されないこととなる。
【００７７】
また、ユーザBが、何らかの事情で、登録完了通知を受信しなかったり、追加要求を送信しなかったりした場合にも、一旦個人情報サーバ１５１に携帯電話１９２の個体識別番号とメールアドレスが登録されてしまえば、もう一度z発x宛のメールを送信することで、宛先依頼メールが返信されることになる。
【００７８】
したがって、ユーザAにとっては、到着したメールの内容を見て迷惑メールか否かの判断をする作業負担が低減される。また、ユーザBにとっても、一旦個人情報を一箇所の個人情報サーバ１５１に登録してしまえば、その後は、あるユーザの代表アドレスにメールを送付するだけで、そのユーザの個別アドレスが自動的に得られることになり、個人情報登録の作業負担や漏洩の可能性を低減することができる。
【００７９】
（各サーバの概要構成）
図３は、本実施形態に係るメールサーバ１３１の概要構成を示す説明図である。以下、本図を参照して説明する。
【００８０】
メールサーバ１３１は、アドレス記憶部３０１、メール受信部３０２、確認問合せ送信部３０３、確認回答受信部３０４、判定部３０５、メール記憶部３０６、閲覧要求受信部３０７、閲覧応答送信部３０８、登録依頼送信部３０９、生成更新部３１０、宛先依頼部３１１、自動追加処理部３１２を備える。
【００８１】
また、省略可能な要素として、追加要求受信部３１３、追加問合せ送信部３１４、追加回答受信部３１５、追加要求処理部３１６を備える。
【００８２】
図４は、本実施形態に係る個人情報サーバ１５１の概要構成を示す説明図である。以下、本図を参照して説明する。
【００８３】
個人情報サーバ１５１は、個人情報記憶部４０１、問合せ受信部４０２、回答送信部４０３、登録要求受信部４０４、個人情報登録部４０５を備える。
【００８４】
また、省略可能な要素として、完了通知送信部４０６を備える。
【００８５】
メールサーバ１３１および個人情報サーバ１５１は、それぞれ、サーバ用コンピュータにて所定のサーバ用プログラムを実行することによって実現される。典型的なサーバ用コンピュータは、ＣＰＵ（Central Processing Unit）の制御の下、一時的な記憶領域としてＲＡＭ（Random Access Memory）を、不揮発な記憶領域としてＨＤ（Hard Disk）を使用し、インターネット１７１を介した通信にはＮＩＣ（Network Interface Card）を使用する。ＣＰＵは、ＲＡＭやＨＤ等を参照し、あるいはＮＩＣを使用して、各種のデータの取得、提供、演算等の処理を行う。また、サーバ用コンピュータは、直接的または間接的に接続されたキーボードおよびモニタを用いて、維持管理が行われる。
【００８６】
サーバ用プログラムは、ＨＤに記録され、ＲＡＭに読み出されて実行される。また、その配布には、ＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）を利用したり、ＮＩＣ経由でインターネット内の他の機器からダウンロードしたりする。
【００８７】
（メールサーバ）
図５は、本実施形態に係るメールサーバ１３１にて実行されるメール処理の制御の流れを示すフローチャートである。以下、本図を参照して説明する。
【００８８】
ここで、メールサーバ１３１のアドレス記憶部３０１には、上記のように、管理対象のユーザごとに、代表アドレスと(送信元アドレス,個別アドレス)の対が記憶される。
【００８９】
また、メール記憶部３０６には、当該メールサーバ１３１の管理対象のユーザに対して送付されたメールが記憶される。
【００９０】
これらは、ＣＰＵの制御の下、ＨＤによって実現されるのが典型的である。
【００９１】
メール処理が開始されると、ＣＰＵは、ＮＩＣを監視して、インターネット１７１からパケットが到着したか否かを調べる（ステップＳ５００）到着していなければ（ステップＳ５０１；Ｎｏ）、一定時間待機した後（ステップＳ５０１）、ステップＳ５００に戻る。ステップＳ５００〜Ｓ５０２の処理は、パケットの到着を受信割込によって検知する手法で実現することも可能である。
【００９２】
パケットが到着していた場合、受信しされたパケットの種類を調べる（ステップＳ５０２）。当該パケットがメールのパケットであり、その宛先がいずれかの代表アドレスである場合（ステップＳ５０２；代表宛メール）、ステップＳ５１１に進み、当該パケットがメールのパケットであり、その宛先がいずれかの個別アドレスである場合（ステップＳ５０２；個別宛メール）、ステップＳ５３１に進む。したがって、ＣＰＵの制御の下、ＮＩＣはメール受信部３０２として機能する。
【００９３】
当該パケットが追加要求のパケットである場合（ステップＳ５０２；追加要求）、ステップＳ５５１に進む。したがって、ＣＰＵの制御の下、ＮＩＣは追加要求受信部３１３として機能する。
【００９４】
当該パケットが閲覧要求のパケットである場合（ステップＳ５０２；閲覧要求）、ステップＳ５７１に進む。したがって、ＣＰＵの制御の下、ＮＩＣは閲覧要求受信部３０７として機能する。
【００９５】
当該パケットがそれ以外のものである場合（ステップＳ５０２；その他）、当該パケットに対応する処理を実行して（ステップＳ５９１）、ステップＳ５００に戻る。
【００９６】
さて、受信したパケットが、代表アドレスを宛先とするメールである場合（ステップＳ５０２；代表宛メール）、その代表アドレスxに対応付けてアドレス記憶部３０１に記憶される対に、当該メールの送信元のメールアドレスzを含むものが存在するか否かを調べ（ステップＳ５１１）、存在する場合（ステップＳ５１１；Ｙｅｓ）、当該メールを拒否するため、ステップＳ５３４に進む。
【００９７】
一方、存在しない場合（ステップＳ５１１；Ｎｏ）、確認問合せ送信部３０３が、個人情報サーバ１５１に、当該メールアドレスzを指定した問合せを送信し（ステップＳ５１２）、確認回答受信部３０４は、当該問合せに対して個人情報サーバ１５１が送信した回答を受信する（ステップＳ５１３）。
【００９８】
したがって、ＣＰＵの制御の下、ＮＩＣは、確認問合せ送信部３０３および確認回答受信部３０４として機能する。
【００９９】
そして、ＣＰＵは、当該メールアドレスzが個人情報サーバ１５１に登録済か未登録かのいずれがこの回答に指定されているかを調べる（ステップＳ５１４）。当該回答に登録済と指定されていた場合（ステップＳ５１４；登録済）、当該メールを承認すると判定して（ステップＳ５１５）、当該メールと当該判定結果とをメール記憶部３０６に記憶させる（ステップＳ５１６）。したがって、ＣＰＵは、判定部３０５として機能する。
【０１００】
そして、ＣＰＵは、当該メールの宛先xと送信元zを参照して、個別アドレスyを生成し（ステップＳ５１７）、対(z,y)を代表アドレスxに対応付けて、アドレス記憶部３０１に追加記憶する（ステップＳ５１８）。
【０１０１】
したがって、ＣＰＵは、ＨＤと共働して、自動追加処理部３１２および生成更新部３１０として機能する。
【０１０２】
さらに、ＣＰＵは、ＮＩＣを介して、当該メールの送信元zに、宛先xのユーザ宛のメールには、今後個別アドレスyを使用するように記載された宛先依頼メールを送信し（ステップＳ５１９）、ステップＳ５００に戻る。したがって、ＮＩＣは、ＣＰＵの制御の下、宛先依頼部３１１として機能する。
【０１０３】
一方、当該回答に未登録と指定されていた場合（ステップＳ５１４；未登録）、ＣＰＵは、当該メールを待機すべきと判定して（ステップＳ５２０）、当該メールをメール記憶部３０６に記憶し（ステップＳ５２１）、当該メールの送信元zに、登録依頼メールを送信して（ステップＳ５２２）、ステップＳ５００に戻る。したがって、ＮＩＣは、ＣＰＵの制御の下、登録依頼送信部３０９として機能する。
【０１０４】
さて、送信元アドレスzのユーザが当該登録依頼メールに適切に対応すると、当該パケットとしてメールアドレスzが指定された追加要求のパケットが到達することとなる（ステップＳ５０２；追加要求）。したがって、ＣＰＵの制御の下、ＮＩＣは追加要求受信部３１３として機能する。
【０１０５】
そして、ＣＰＵは、ＮＩＣを介して、追加要求に指定されたメールアドレスzを指定した問合せを個人情報サーバ１５１に送信し（ステップＳ５５１）、その回答を受信する（ステップＳ５５２）。
【０１０６】
したがって、ＮＩＣは、ＣＰＵの制御の下、追加問合せ送信部３１４、追加回答受信部３１５として機能する。
【０１０７】
そして、その回答に指定されているのが登録済か未登録かを調べ（ステップＳ５５３）、登録済と指定されていれば（ステップＳ５５３；登録済）、メール記憶部３０６に待機すべきと記憶されているメールのうち、送信元がzであり、宛先がいずれかの代表メールアドレスであるメールを抽出し、当該抽出されたメールのそれぞれについて（ステップＳ５５４〜）以下の処理を繰り返す（〜ステップＳ５５９）。
【０１０８】
すなわち、当該メールの判定結果を承認すべきに更新し（ステップＳ５５５）、ステップＳ５１７と同様に当該メールの宛先と送信元を参照して個別アドレスを生成し（ステップＳ５５６）、ステップＳ５１８と同様に、送信元と個別アドレスの対を宛先に対応付けてアドレス記憶部に追加記憶し（ステップＳ５５７）、ステップＳ５１９と同様に送信元に、代表アドレスのユーザ宛のメールには、今後個別アドレスを使用するように記載された宛先依頼メールを送信する（ステップＳ５５８）。
【０１０９】
そして、繰り返し（ステップＳ５５４〜ステップＳ５５９）が終わったら、当該追加要求に対する成功応答（ＨＴＴＰレスポンス）を返して（ステップＳ５６０）ステップＳ５００に戻る。
【０１１０】
一方、未登録であれば（ステップＳ５５３；未登録）、当該追加要求が実行できなかった旨の失敗応答（ＨＴＴＰレスポンス）を返して（ステップＳ５６１）、ステップＳ５００に戻る。
【０１１１】
したがって、ＣＰＵは、ＨＤおよびＮＩＣと共働して、追加要求処理部３１６として機能する。
【０１１２】
さて、当該パケットがメールのパケットであり、その宛先がいずれかの個別アドレスである場合（ステップＳ５０２；個別宛メール）、当該メールの送信元と当該メールの宛先の個別アドレスとの対が、アドレス記憶部３０１に記憶されているか否かを調べ（ステップＳ５３１）、記憶されていれば（ステップＳ５３１；Ｙｅｓ）、当該メールを承認すべきと判定して（ステップＳ５３２）、当該メールと判定結果をメール記憶部３０６に記憶し（ステップＳ５３３）、ステップＳ５００に戻る。
【０１１３】
一方当該対が記憶されていなければ（ステップＳ５３１；Ｎｏ）、当該メールを拒否すべきと判定して（ステップＳ５３４）、当該メールと判定結果をメール記憶部３０６に記憶し（ステップＳ５３５）、ステップＳ５００に戻る。
【０１１４】
なお、拒否すべきと判定されたメールは、通常の迷惑メールの処理と同様に、メール記憶部３０６に記憶せず、廃棄することとしても良いし、メール記憶部３０６に記憶した後、一定期間ごとに消去することとしても良い。
【０１１５】
当該パケットが閲覧要求のパケットである場合（ステップＳ５０２；閲覧要求）、メール記憶部３０６に承認すべきと記憶されたメールのうち、当該パケットに指定されたユーザの代表アドレスもしくは個別アドレスを宛先とするメールを抽出し（ステップＳ５７１）、抽出されたメールの内容を閲覧要求の送信元に閲覧応答として送信して（ステップＳ５７２）、ステップＳ５００に戻る。この処理には、ＰＯＰやＩＭＡＰ、通常のウェブメール等の技術を適用することができる。したがって、ＣＰＵは、ＨＤやＮＩＣと共働して、閲覧応答送信部３０８として機能する。
【０１１６】
なお、「待機すべき」と判断する状況についてであるが、メールアドレスz発、代表アドレスx宛のメールについては、最初に到達したもののみを「待機すべき」と判断し、それ以降に到達したもの（「待機すべき」のメールが残っている状態で受信されたもの）は「拒否すべき」と判断することとしても良い。
【０１１７】
このほか、メールアドレスz発、いずれかの代表アドレス宛のメールについて、最初に到達したもののみを「待機すべき」と判断し、それ以降に到達したもの（「待機すべき」のメールが残っている状態で受信されたもの）は「拒否すべき」と判断することとしても良い。
【０１１８】
このような判断は、メール記憶部３０６を走査することによって可能である。
【０１１９】
このほか、「拒否すべき」と判断されたメールについては、当該メールを送信してきたメールサーバに対して、宛先が存在しない旨のエラーメールを返送しても良いし、上記のように、単に無視することとしても良い。
【０１２０】
（個人情報サーバ）
個人情報サーバ１５１は、メールサーバ１３１同様、ＣＰＵがＮＩＣを監視してパケットが到着しているか否かを判定し、到着している場合には、そのパケットの種類に応じて、問合せ回答処理、登録処理、もしくは、その他の処理を起動することを繰り返す。
【０１２１】
図６は、本実施形態に係る個人情報サーバ１５１にて実行される問合せ回答処理の制御の流れを示すフローチャートである。
【０１２２】
ＣＰＵがＮＩＣと共働して問合せ受信部４０２として機能し、問合せのパケットを受信すると（ステップＳ６０１）、ＨＤにより構成される個人情報記憶部４０１を参照して当該問合せに指定されるメールアドレスが記憶されているか否かを調べる（ステップＳ６０２）。
【０１２３】
そして、記憶されていれば（ステップＳ６０２；Ｙｅｓ）、ＣＰＵはＮＩＣを制御して、当該メールアドレスは登録済である旨の回答を送信して（ステップＳ６０３）、本処理を終了する。
【０１２４】
一方、記憶されていなければ（ステップＳ６０２；Ｎｏ）、ＣＰＵはＮＩＣを制御して、当該メールアドレスは未登録である旨の回答を送信して（ステップＳ６０４）、本処理を終了する。
【０１２５】
したがって、ＣＰＵがＮＩＣと共働して回答送信部４０３として機能する。
【０１２６】
図７は、本実施形態に係る個人情報サーバ１５１にて実行される登録処理の制御の流れを示すフローチャートである。以下、これら図を参照して説明する。
【０１２７】
ＣＰＵがＮＩＣと共働して、登録要求受信部４０４として機能して、登録要求のパケットを受信すると（ステップＳ７０１）、当該パケットに指定されたメールアドレスと携帯電話の個体識別番号とを対応付けて、ＨＤにより構成される個人情報記憶部４０１に追加記憶する（ステップＳ７０２）。したがって、ＣＰＵはＨＤと共働して、個人情報登録部４０５として機能する。
【０１２８】
そして、ＣＰＵがＮＩＣと共働して、完了通知送信部４０６として機能し、登録要求を送信した携帯電話に対して、登録要求のパケットに指定されたメールサーバ１３１を指定する完了通知を送信して（ステップＳ７０３）、本処理を終了する。
【０１２９】
なお、完了通知においてはリダイレクトを行うため、メールサーバ１３１が当該個人情報サーバ１５１と信頼関係あるいは契約関係にある有効なものであるか否かを判定することが望ましい。
【０１３０】
なお、メールサーバ１３１や個人情報サーバ１５１において、上記の省略可能な要素を省略した場合には、上記フローから当該要素に相当する処理を適宜省略することができる。
【実施例２】
【０１３１】
上記の実施例に加えて、以下のような種々の態様を採用することができる。
【０１３２】
第１に、ブラックリストを用いて個別アドレスの発行を拒否する相手を管理する手法については、さらに一歩進んで、以下のような手法をとることができる。
【０１３３】
すなわち、個人情報サーバ１５１は、メールアドレスと個体識別番号を対応付けて記録する際に、当該レコードのＩＤをユニークに決定する。これには、登録順序の番号を使用しても良いし、何らかの乱数を組み合わせたり、登録日時を一部に用いる等が可能である。
【０１３４】
そして、メールサーバ１３１から個人情報サーバ１５１へ問合せを行うと、回答には、登録済か未登録か、のほかに、レコードのＩＤが指定されてくることとする。
【０１３５】
そして、メールサーバ１３１では、ブラックリストにzを追加するのではなく、このＩＤを追加することとし、個別アドレスを発行するか否かの判断基準に、送信元のメールアドレスに対して回答されたＩＤがブラックリストに含まれないか含まれるか、も入れるのである。
【０１３６】
このような処理を行うと、１つの携帯電話で複数のメールアドレスを登録したり、メールアドレスを登録し直したりした場合であっても、携帯電話を基準にメールのやり取りをしたくないユーザであるか否かを判定することができる。
【０１３７】
また、メールサーバ１３１にてブラックリストに掲載された旨を個人情報サーバ１５１に通知することとし、その回数が多い場合には、問合せに対する回答に、そのような情報を含めることとして、個別アドレスの発行の可否の判断基準として、以前にその携帯電話がブラックリストに掲載された回数が何回であるか等を含めた処理を行っても良い。
【０１３８】
また、回答に毎回ＩＤを含めたり、ブラックリスト掲載回数が指定されるのではなく、メールサーバ１３１からブラックリストに追加したいメールアドレスを個人情報サーバ１５１に通知すると、その旨の情報が個人情報サーバ１５１で蓄積され、回答には、当該メールアドレスに対応付けられる携帯電話の個体識別番号についてのブラックリスト掲載回数が、一定閾値を超えているか否かのみの情報を指定することとする手法もある。
【０１３９】
この場合、メールサーバ１３１では、閾値を超えていると指定された場合には、自動的に個別アドレスの発行を拒否することとしても良いし、その旨を受信側ユーザに通知して、ユーザ自身に個別アドレスの発行の可否を判断させることとしても良い。
【０１４０】
第２に、承認するか否かの判断基準に、発信元アドレスそのものではなく、そのドメイン名を用いる、という手法である。
【０１４１】
たとえば、ある会社がメールマガジンを多くのユーザに発送したい場合を考える。この会社から発送されるメールマガジンの送信元は、ドメイン名は共通するが、ユーザ名が異なることがあり、また、ユーザ名が新しく作られることもある。
【０１４２】
そこで、個人情報サーバ１５１には、当該会社が所有する携帯電話の個体識別番号と、そのドメイン名と、を登録しておく。あるいは、その会社の何らかの信用情報を、携帯電話の個体識別番号のかわりに使うこととして、ドメイン名を組み合わせて登録することとしても良い。
【０１４３】
すなわち、「携帯電話の個体識別番号とメールアドレスの組み合わせ」のかわりに、「会社が信用できることを確認した旨の情報とドメイン名の組み合わせ」を用いることも可能とするのである。
【０１４４】
このような場合に、会社Ｂがユーザ名uとドメイン名dからなるメールアドレスu@dを用いてユーザＡの公開メールアドレスxに対して、最初のメールマガジンを発送すると、メールサーバ１３１から個人情報サーバ１５１に、u@dを指定した問合せがされる。
【０１４５】
個人情報サーバ１５１は、dがその会社のドメイン名であることから、登録済と回答することとなる。
【０１４６】
すると、メールサーバ１３１から、ユーザＡ用に生成された個別アドレスyが、u@d宛に送られてくる。そこで、会社Ｂでは、ユーザＡ用のメールマガジンの宛先をxからyに変更する。
【０１４７】
これらの処理をコンピュータに行わせることにより、メールマガジンの宛先管理を自動化することも可能である。
【産業上の利用可能性】
【０１４８】
本発明によれば、ユーザが自分のメールアドレスを公開したとしても、迷惑メールの閲覧・判定の作業をできるだけしないですみ、送信者の身元確認が適切にできるようにするのに好適なメールサーバシステム、ならびに、これをコンピュータにより実現するためのプログラムを提供することができる。
【図面の簡単な説明】
【０１４９】
【図１】本発明の実施形態に係るメールサービスシステムの概要構成を示す説明図である。
【図２】本実施形態に係るメールサーバ、個人情報サーバ、端末装置、携帯電話の間の通信の様子を示すセッション図である。
【図３】本実施形態に係るメールサーバの概要構成を示す説明図である。
【図４】本実施形態に係る個人情報サーバの概要構成を示す説明図である。
【図５】本実施形態に係るメールサーバにて実行されるメール処理の制御の流れを示すフローチャートである。
【図６】本実施形態に係る個人情報サーバにて実行される問合せ回答処理の制御の流れを示すフローチャートである。
【図７】本実施形態に係る個人情報サーバにて実行される登録処理の制御の流れを示すフローチャートである。
【符号の説明】
【０１５０】
１０１ メールサービスシステム
１３１ メールサーバ
１５１ 個人情報サーバ
１７１ インターネット
１９１ 端末装置
１９２ 携帯電話
３０１ アドレス記憶部
３０２ メール受信部
３０３ 確認問合せ送信部
３０４ 確認回答受信部
３０５ 判定部
３０６ メール記憶部
３０７ 閲覧要求受信部
３０８ 閲覧応答送信部
３０９ 登録依頼送信部
３１０ 生成更新部
３１１ 宛先依頼部
３１２ 自動追加処理部
３１３ 追加要求受信部
３１４ 追加問合せ送信部
３１５ 追加回答受信部
３１６ 追加要求処理部
４０１ 個人情報記憶部
４０２ 問合せ受信部
４０３ 回答送信部
４０４ 登録要求受信部
４０５ 個人情報登録部
４０６ 完了通知送信部
【特許請求の範囲】
【請求項１】
メールサーバと、個人情報サーバと、を備えるメールサービスシステムであって、
（ａ）前記メールサーバは、
管理対象のユーザの代表アドレスと、当該ユーザが閲覧対象とするメールの送信元および宛先の対に指定されるべき送信元アドレスおよび個別アドレスの対と、を対応付けて記憶するアドレス記憶部、
前記アドレス記憶部に記憶された代表アドレスもしくは個別アドレスが宛先に指定されたメールを受信するメール受信部、
前記受信されたメールの宛先が前記アドレス記憶部に記憶される代表アドレスのいずれかであり、当該メールの送信元を送信元アドレスとする対が前記アドレス記憶部において当該代表アドレスに対応付けて記憶されていない場合、当該メールの送信元を指定する問合せを、前記個人情報サーバに送信する確認問合せ送信部
を備え、
（ｂ）前記個人情報サーバは、
携帯電話の個体識別番号と、当該携帯電話のユーザのメールアドレスと、を対応付けて記憶する個人情報記憶部、
メールアドレスを指定する問合せを受信する問合せ受信部、
前記受信された問合せに指定されるメールアドレスが、携帯電話の個体識別番号に対応付けて前記個人情報記憶部に記憶されていれば登録済と指定し、さもなくば未登録と指定する回答を、当該問合せの送信元に送信する回答送信部
を備え、
（ｃ）前記メールサーバは、
前記確認問合せ送信部により送信された問合せに対して、前記個人情報サーバから送信された回答を受信する確認回答受信部、
前記受信されたメールにおいて、
（１）当該送信元および当該宛先の対が、前記アドレス記憶部に記憶される送信元アドレスおよび個別アドレスの対のいずれかである場合、当該メールを承認すべきと判定し、
（２）当該宛先が、前記アドレス記憶部に記憶される代表アドレスのいずれかであり、前記確認回答受信部により受信された回答に未登録と指定されている場合、当該メールを待機すべきと判定し、
（３）上記のいずれでもない場合、当該メールを拒否すべきと判定
する判定部、
前記受信されたメールと、その判定結果と、を、記憶するメール記憶部、
当該管理対象のユーザが使用する端末装置から、当該ユーザを指定するメール閲覧要求を、受信する閲覧要求受信部、
前記メール記憶部に承認すべきと記憶されているメールのうち、前記受信されたメール閲覧要求に指定されるユーザについて前記アドレス記憶部に記憶される代表アドレスもしくは個別アドレスを宛先とするメールを取得して、当該取得されたメールの内容を指定するメール閲覧応答を、当該ユーザが使用する端末装置へ送信する閲覧応答送信部、
前記受信されたメールが待機すべきと判定された場合、当該メールの送信元に登録依頼メールを送信する登録依頼送信部
をさらに備え、
当該登録依頼メールには、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話のブラウザを介して選択されたとすると、当該携帯電話の個体識別番号と、当該送信元のユーザのメールアドレスと、が指定された登録要求が、前記個人情報サーバへ送信されることとなり、
（ｄ）前記個人情報サーバは、
携帯電話から送信された登録要求を受信する登録要求受信部、
前記受信された登録要求に指定される個体識別番号と、メールアドレスと、を対応付けて前記個人情報記憶部に追加して記憶させる個人情報登録部
をさらに備え、
（ｅ）前記メールサーバは、
宛先が前記アドレス記憶部に記憶される代表アドレスであるメールが与えられると、当該代表アドレスのユーザに対して個別アドレスを新たに生成し、当該メールの送信元のアドレスおよび当該新たに生成された個別アドレスの対を、当該代表アドレスに対応付けて前記アドレス記憶部に追加して記憶させる生成更新部、
前記生成更新部に与えられたメールの送信元のアドレスへ、当該メールの宛先である代表アドレスのユーザ宛のメールにおいては前記新たに生成された個別アドレスを宛先として指定すべきことを依頼する宛先依頼メールを、送信する宛先依頼部、
前記確認回答受信部にて受信された回答に登録済と指定されている場合、前記受信されたメールを、前記生成更新部に与える自動追加処理部
をさらに備える
ことを特徴とするメールサービスシステム。
【請求項２】
請求項１に記載のメールサービスシステムであって、前記メールサーバにおいて、
前記判定部が、前記受信されたメールを待機すべきと判定するのは、「当該宛先が、前記アドレス記憶部に記憶される代表アドレスのいずれかであり、前記確認回答受信部により受信された回答に未登録と指定されている場合」にかえて、「当該宛先が、前記アドレス記憶部に記憶される代表アドレスのいずれかであり、前記確認回答受信部により受信された回答に未登録と指定され、前記メール記憶部に、待機すべきと記憶されたメールに、前記受信されたメールと宛先および送信元を同じくするものが存在しない場合」である
ことを特徴とするメールサービスシステム。
【請求項３】
請求項１または２に記載のメールサービスシステムであって、前記メールサーバにおいて、
前記確認回答受信部にて受信された回答に登録済と指定されている場合、当該メールを、「拒否すべき」と判定するのにかえて、「承認すべき」と判定する
ことを特徴とするメールサービスシステム。
【請求項４】
請求項１から３のいずれか１項に記載のメールサービスシステムであって、
（ｆ）前記個人情報サーバは、
前記受信された登録要求を送信した携帯電話、もしくは、当該登録要求に指定されるメールアドレスに、登録完了通知を送信する完了通知送信部
をさらに備え、
当該登録完了通知には、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話もしくは端末装置のブラウザにて処理されたとすると、当該メールアドレスが指定された追加要求が、前記メールサーバへ送信されることとなり、
（ｇ）前記メールサーバは、
携帯電話もしくは端末装置から送信された追加要求を受信する追加要求受信部、
前記受信された追加要求に指定されるメールアドレスを指定する問合せを、前記個人情報サーバに送信する追加問合せ送信部、
前記追加問合せ送信部により送信された問合せに対して、前記個人情報サーバから送信された回答を受信する追加回答受信部、
前記追加回答受信部にて受信された回答に登録済と指定されている場合、前記メール記憶部に待機すべきと記憶されたメールのうち、前記受信された追加要求に指定されるメールアドレスを送信元とするメールを、前記生成更新部に与える追加要求処理部
をさらに備える
ことを特徴とするメールサービスシステム。
【請求項５】
請求項４に記載のメールサービスシステムであって、メールサーバにおいて、
前記追加要求処理部は、前記メール記憶部に待機すべきと記憶されたメールのうち、前記受信された追加要求に指定されるメールアドレスを送信元とするメールの判定結果を、前記メール記憶部において承認すべきと更新する
ことを特徴とするメールサービスシステム。
【請求項６】
請求項１から５のいずれか１項に記載のメールサービスシステムにおいて、
前記個人情報サーバと、前記メールサーバと、は、当該送信元のメールアドレスにかえて当該送信元のメールアドレスのドメイン名により、受信されたメールの判定および個人情報の管理を行う
ことを特徴とするメールサービスシステム。
【請求項７】
第１のコンピュータおよび第２のコンピュータを、請求項１から６のいずれか１項に記載のメールサービスシステムの個人情報サーバの各部およびメールサーバの各部として機能させることを特徴とするプログラム。
【請求項１】
メールサーバと、個人情報サーバと、を備えるメールサービスシステムであって、
（ａ）前記メールサーバは、
管理対象のユーザの代表アドレスと、当該ユーザが閲覧対象とするメールの送信元および宛先の対に指定されるべき送信元アドレスおよび個別アドレスの対と、を対応付けて記憶するアドレス記憶部、
前記アドレス記憶部に記憶された代表アドレスもしくは個別アドレスが宛先に指定されたメールを受信するメール受信部、
前記受信されたメールの宛先が前記アドレス記憶部に記憶される代表アドレスのいずれかであり、当該メールの送信元を送信元アドレスとする対が前記アドレス記憶部において当該代表アドレスに対応付けて記憶されていない場合、当該メールの送信元を指定する問合せを、前記個人情報サーバに送信する確認問合せ送信部
を備え、
（ｂ）前記個人情報サーバは、
携帯電話の個体識別番号と、当該携帯電話のユーザのメールアドレスと、を対応付けて記憶する個人情報記憶部、
メールアドレスを指定する問合せを受信する問合せ受信部、
前記受信された問合せに指定されるメールアドレスが、携帯電話の個体識別番号に対応付けて前記個人情報記憶部に記憶されていれば登録済と指定し、さもなくば未登録と指定する回答を、当該問合せの送信元に送信する回答送信部
を備え、
（ｃ）前記メールサーバは、
前記確認問合せ送信部により送信された問合せに対して、前記個人情報サーバから送信された回答を受信する確認回答受信部、
前記受信されたメールにおいて、
（１）当該送信元および当該宛先の対が、前記アドレス記憶部に記憶される送信元アドレスおよび個別アドレスの対のいずれかである場合、当該メールを承認すべきと判定し、
（２）当該宛先が、前記アドレス記憶部に記憶される代表アドレスのいずれかであり、前記確認回答受信部により受信された回答に未登録と指定されている場合、当該メールを待機すべきと判定し、
（３）上記のいずれでもない場合、当該メールを拒否すべきと判定
する判定部、
前記受信されたメールと、その判定結果と、を、記憶するメール記憶部、
当該管理対象のユーザが使用する端末装置から、当該ユーザを指定するメール閲覧要求を、受信する閲覧要求受信部、
前記メール記憶部に承認すべきと記憶されているメールのうち、前記受信されたメール閲覧要求に指定されるユーザについて前記アドレス記憶部に記憶される代表アドレスもしくは個別アドレスを宛先とするメールを取得して、当該取得されたメールの内容を指定するメール閲覧応答を、当該ユーザが使用する端末装置へ送信する閲覧応答送信部、
前記受信されたメールが待機すべきと判定された場合、当該メールの送信元に登録依頼メールを送信する登録依頼送信部
をさらに備え、
当該登録依頼メールには、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話のブラウザを介して選択されたとすると、当該携帯電話の個体識別番号と、当該送信元のユーザのメールアドレスと、が指定された登録要求が、前記個人情報サーバへ送信されることとなり、
（ｄ）前記個人情報サーバは、
携帯電話から送信された登録要求を受信する登録要求受信部、
前記受信された登録要求に指定される個体識別番号と、メールアドレスと、を対応付けて前記個人情報記憶部に追加して記憶させる個人情報登録部
をさらに備え、
（ｅ）前記メールサーバは、
宛先が前記アドレス記憶部に記憶される代表アドレスであるメールが与えられると、当該代表アドレスのユーザに対して個別アドレスを新たに生成し、当該メールの送信元のアドレスおよび当該新たに生成された個別アドレスの対を、当該代表アドレスに対応付けて前記アドレス記憶部に追加して記憶させる生成更新部、
前記生成更新部に与えられたメールの送信元のアドレスへ、当該メールの宛先である代表アドレスのユーザ宛のメールにおいては前記新たに生成された個別アドレスを宛先として指定すべきことを依頼する宛先依頼メールを、送信する宛先依頼部、
前記確認回答受信部にて受信された回答に登録済と指定されている場合、前記受信されたメールを、前記生成更新部に与える自動追加処理部
をさらに備える
ことを特徴とするメールサービスシステム。
【請求項２】
請求項１に記載のメールサービスシステムであって、前記メールサーバにおいて、
前記判定部が、前記受信されたメールを待機すべきと判定するのは、「当該宛先が、前記アドレス記憶部に記憶される代表アドレスのいずれかであり、前記確認回答受信部により受信された回答に未登録と指定されている場合」にかえて、「当該宛先が、前記アドレス記憶部に記憶される代表アドレスのいずれかであり、前記確認回答受信部により受信された回答に未登録と指定され、前記メール記憶部に、待機すべきと記憶されたメールに、前記受信されたメールと宛先および送信元を同じくするものが存在しない場合」である
ことを特徴とするメールサービスシステム。
【請求項３】
請求項１または２に記載のメールサービスシステムであって、前記メールサーバにおいて、
前記確認回答受信部にて受信された回答に登録済と指定されている場合、当該メールを、「拒否すべき」と判定するのにかえて、「承認すべき」と判定する
ことを特徴とするメールサービスシステム。
【請求項４】
請求項１から３のいずれか１項に記載のメールサービスシステムであって、
（ｆ）前記個人情報サーバは、
前記受信された登録要求を送信した携帯電話、もしくは、当該登録要求に指定されるメールアドレスに、登録完了通知を送信する完了通知送信部
をさらに備え、
当該登録完了通知には、ＨＴＭＬ文書の要素もしくはＵＲＬが含まれ、当該要素もしくはＵＲＬが携帯電話もしくは端末装置のブラウザにて処理されたとすると、当該メールアドレスが指定された追加要求が、前記メールサーバへ送信されることとなり、
（ｇ）前記メールサーバは、
携帯電話もしくは端末装置から送信された追加要求を受信する追加要求受信部、
前記受信された追加要求に指定されるメールアドレスを指定する問合せを、前記個人情報サーバに送信する追加問合せ送信部、
前記追加問合せ送信部により送信された問合せに対して、前記個人情報サーバから送信された回答を受信する追加回答受信部、
前記追加回答受信部にて受信された回答に登録済と指定されている場合、前記メール記憶部に待機すべきと記憶されたメールのうち、前記受信された追加要求に指定されるメールアドレスを送信元とするメールを、前記生成更新部に与える追加要求処理部
をさらに備える
ことを特徴とするメールサービスシステム。
【請求項５】
請求項４に記載のメールサービスシステムであって、メールサーバにおいて、
前記追加要求処理部は、前記メール記憶部に待機すべきと記憶されたメールのうち、前記受信された追加要求に指定されるメールアドレスを送信元とするメールの判定結果を、前記メール記憶部において承認すべきと更新する
ことを特徴とするメールサービスシステム。
【請求項６】
請求項１から５のいずれか１項に記載のメールサービスシステムにおいて、
前記個人情報サーバと、前記メールサーバと、は、当該送信元のメールアドレスにかえて当該送信元のメールアドレスのドメイン名により、受信されたメールの判定および個人情報の管理を行う
ことを特徴とするメールサービスシステム。
【請求項７】
第１のコンピュータおよび第２のコンピュータを、請求項１から６のいずれか１項に記載のメールサービスシステムの個人情報サーバの各部およびメールサーバの各部として機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００８−２８７４００（Ｐ２００８−２８７４００Ａ）
【公開日】平成２０年１１月２７日（２００８．１１．２７）
【国際特許分類】
【出願番号】特願２００７−１３０３５９（Ｐ２００７−１３０３５９）
【出願日】平成１９年５月１６日（２００７．５．１６）
【出願人】（５９２１０２８２５）
【Ｆターム（参考）】
【公開日】平成２０年１１月２７日（２００８．１１．２７）
【国際特許分類】
【出願日】平成１９年５月１６日（２００７．５．１６）
【出願人】（５９２１０２８２５）
【Ｆターム（参考）】
[ Back to top ]