認証システム、認証計算機及びプログラム
【課題】安全性及び利便性の高い個人認証システムを提供する。
【解決手段】認証計算機であって、ユーザ情報を記憶し、前記クライアント計算機から認証要求を受信すると、当該認証計算機が受信可能なメールアドレスのうち、以前に受信した認証要求のいずれにも割り当てられていないメールアドレスを、当該受信した認証要求に割り当て、認証用メールアドレス対応情報に記憶し、電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを特定し、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、前記認証用メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する認証要求を特定し、前記特定された認証要求では、前記特定されたユーザによって認証が要求されていると判断する。
【解決手段】認証計算機であって、ユーザ情報を記憶し、前記クライアント計算機から認証要求を受信すると、当該認証計算機が受信可能なメールアドレスのうち、以前に受信した認証要求のいずれにも割り当てられていないメールアドレスを、当該受信した認証要求に割り当て、認証用メールアドレス対応情報に記憶し、電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを特定し、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、前記認証用メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する認証要求を特定し、前記特定された認証要求では、前記特定されたユーザによって認証が要求されていると判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は認証システム、認証計算機及びプログラムに関するものである。
【背景技術】
【０００２】
従来、ユーザを特定してサービスを提供する場合の個人認証として、ユーザＩＤ及びパスワードの組み合わせが知られている。例えば、インターネットを経由してＷＥＢサイトにログインする者は、操作するパーソナルコンピュータに表示されたＷＥＢ画面に応じて、ユーザＩＤ及びパスワードを入力し、ＷＥＢサーバに認証要求を送信する。また、金融機関の利用者が金融機関のＡＴＭで預け金を引き出す場合は、ＡＴＭにキャッシュカードを挿入して、暗証番号を入力し、認証要求を認証サーバに送信する。この場合のユーザＩＤは、キャッシュカードである。
【０００３】
しかし、ＷＥＢサイトのユーザは、ＷＥＢサイトの画面に応じてユーザＩＤ及びパスワードを入力する手間がいる。また、この認証方法は広く普及しており、インターネットバンキングや各種電子商取引のＷＥＢサイトで採用されている。このため、一人が管理すべきユーザＩＤ及びパスワードが増えている。ＷＥＢサイトのユーザは、ユーザＩＤ又はパスワードを忘れた場合には、ユーザＩＤ又はパスワードをサイト運営者に問い合わせる必要があり、ＷＥＢサイトの利便性を享受できない。また、本来のユーザではない者が、ユーザＩＤ及びパスワードを掠め取り、取引を行うなりすましが社会問題化している。ユーザＩＤ及びパスワードを掠め取る手段として、フィッシングやスパイウェアが知られている。フィッシングとは、正規のＷＥＢサイトにそっくりな擬似サイトを設けて、本来のユーザにユーザＩＤ及びパスワードを入力させ、ユーザＩＤ及びパスワードを掠め取る行為である。また、スパイウェアとは、パーソナルコンピュータのユーザが知らないうちにインストールされるソフトウェアで、ユーザが入力する各種ユーザＩＤ及びパスワードを読み取り、インターネット経由で盗聴者のサーバまで通知するソフトウェアのことである。インターネットバンキングや電子商取引でなりすましによる取引が成立した場合、本来のユーザはもとより、ＷＥＢサイトの運営者にもサイトの信頼性失墜や補償問題で甚大な被害が発生する。
【０００４】
金融機関の利用者が金融機関のＡＴＭで預け金を引き出す場合は、ＡＴＭにキャッシュカードを挿入して、暗証番号を入力する手間がいる。また、盗撮機によって暗証番号が盗撮され、キャッシュカードが盗まれた場合、なりすましのユーザによって預金が引き出されてしまう。預金者はもとより、銀行は、信頼性の失墜や補償問題で大きな被害を受ける。
【０００５】
特許文献１では、ＷＥＢサイトのユーザが認証を受ける際に、ＷＥＢサイトにユーザＩＤ及びパスワードを入力し、特定の電話番号にダイヤルすることで、ユーザを認証する個人認証方法が公開されている。
【０００６】
特許文献２では、ＷＥＢサイトのユーザが認証を受ける際に、電話番号をユーザＩＤとして、ＷＥＢサイトに入力し、特定の電話番号にダイヤルすることで、ユーザを認証する個人認証方法が公開されている。
【特許文献１】特許公開２００２−２２９９５１
【特許文献２】特許公開２００４−２１３４４０
【発明の開示】
【発明が解決しようとする課題】
【０００７】
特許文献１の技術によれば、発信者電話番号を利用するために、ユーザＩＤ及びパスワードを掠め取られた場合でも、なりすましを防止できる。また、特許文献２の技術によれば、発信者電話番号を利用するために、なりすましの電話番号をＷＥＢサイトに入力された場合でも、なりすましを防止することができる。しかし、特許文献１及び特許文献２の技術では、発信者番号通知を伴うダイヤルをユーザが発信できない場合には、認証できない。例えば、携帯電話の電波が届かない場合等には、認証できない。
【０００８】
また、特許文献１及び特許文献２の技術では、発信者電話番号通知を伴うダイヤルをしたユーザと当該ユーザが操作する計算機との対応を正確に把握できない。そのため、特許文献１及び特許文献２の技術では、安全性及び利便性の高い認証を提供することができない。例えば、特許文献１及び特許文献２の技術では、本来のユーザでない者が、正当なユーザのユーザＩＤ等を何度も入力することによって、当該正当なユーザになりすませてしまう可能性がある。具体的には、正当なユーザが、特定の電話番号にダイヤルすることによって認証を行った後に、当該特定の電話番号に誤ってリダイヤルしてしまうと、本来のユーザでない者が正当なユーザとして認証されてしまう。
【０００９】
本発明は、前述した問題点に鑑みてなされたものであって、安全性及び利便性の高い個人認証システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
複数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びインタフェースを備える認証計算機であって、前記プロセッサは、ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、前記クライアント計算機から認証要求を受信すると、当該認証計算機が受信可能なメールアドレスのうち、以前に受信した認証要求のいずれにも割り当てられていないメールアドレスを、当該受信した認証要求に割り当て、前記受信した認証要求と当該認証要求に割り当てられたメールアドレスとの対応を、認証用メールアドレス対応情報に記憶し、電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを特定し、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、前記認証用メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する認証要求を特定し、前記特定された認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする。
【発明の効果】
【００１１】
本発明の代表的な実施形態によれば、個人認証システムの安全性及び利便性を高めることができる。
【発明を実施するための最良の形態】
【００１２】
本発明の実施形態を図面を参照して説明する。なお、第１の実施形態として、本発明の汎用的な実施形態を説明する。次に、第２の実施形態として、第１の実施形態を、ＷＥＢサイトに用いた具体的な実施形態を説明する。次に、第３の実施形態として、第２の実施形態を、既存のＷＥＢサーバへ容易に導入するための具体的な実施形態を説明する。次に、第４の実施形態として、第３の実施形態を、インターネットのクレジットカード決済に用いる具体的な実施形態を説明する。次に、第５の実施形態として、第１の実施形態を、金融機関のＡＴＭに用いる具体的な実施形態について説明する。次に、第６の実施形態として、第１の実施形態を、店舗でのクレジットカード決済に用いる具体的な実施形態を説明する。次に、第７の実施形態として、第１の実施形態を、社内イントラネットの接続に用いる具体的な実施形態を説明する。次に、第８の実施形態として、第１の実施形態を、シンクライアントの集中サーバへの接続に用いる具体的な実施形態を説明する。次に、第９の実施形態として、第１の実施形態を、公衆無線ＬＡＮの接続に用いる具体的な実施形態を説明する。次に、第１０の実施形態として、認証要求ＩＤの代わりに、クライアント装置の識別子であるクライアントＩＤを用いる汎用的な実施形態を説明する。
【００１３】
（第１の実施形態）
図１は、第１の実施形態の個人認証システムの概略の構成図である。図１に示す個人認証システムは、複数のクライアント装置１０及びメール認証装置３を備える。クライアント装置１０は、認証を受けようとするユーザによって操作される計算機である。また、クライアント装置１０は、ネットワーク９に接続されている。クライアント装置１０については、図２で詳細を説明する。なお、ネットワーク９は、専用線網、公衆交換電話回線網又はＬＡＮ等のようなデータ通信網である。また、ネットワーク９は、インターナルネットワークであってもよいし、インターネットであってもよい。メール認証装置３は、ネットワーク９を介してクライアント装置１０に接続されている。具体的には、メール認証装置３は、インターネット又はインターナルネットワークを介してクライアント装置１０に接続される。なお、メール認証装置３は、インターネット用のインタフェース及びインターナルネットワーク用のインタフェースを備えてもよい。この場合、メール認証装置３は、インターネットを介していくつかのクライアント装置１０と接続し、更にインターナルネットワークを介して他のいくつかのクライアント装置１０と接続する。メール認証装置３については、図３で詳細を説明する。なお、説明を明瞭にするために、第１の実施形態の個人認証システムでは、１台のクライアント装置１０に対する認証処理を説明する。実際には、メール認証装置３は、ネットワーク９を介して、複数のクライアント装置１０に対する認証を行う。つまり、メール認証装置３は、複数のクライアント装置１０から認証要求を受けることができる。なお、図１では、クライアント装置１０は５台を図示したが、個人認証システムに何台備わっていても良い。
【００１４】
図２は、第１の実施形態の個人認証システムに備わるクライアント装置１０の構成のブロック図である。クライアント装置１０は、物理的には、送受信部１１、中央処理装置１２、主記憶装置１３、補助記憶装置１４、入力装置（図示省略）及び表示装置（図示省略）等を備えたコンピュータシステムである。送受信部１１は、ネットワーク９に接続され、外部の装置（メール認証装置３）とデータを送受信するインタフェースである。中央処理装置１２は、例えば、ＣＰＵである。中央処理装置１２は、主記憶装置１３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置１３は、例えば、メモリである。主記憶装置１３は、中央処理装置１２によって実行されるプログラム及び中央処理装置１２によって必要とされる情報等が記憶される。補助記憶装置１４は、例えば、ハードディスクである。補助記憶装置１４は、各種情報を記憶する。入力装置は、例えば、マウス、キーボード又はタッチパネルである。入力装置には、ユーザから各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置１２から表示を指示された情報が表示される。なお、クライアント装置１０は、送受信部１１、中央処理装置１２及び主記憶装置１３を備えれば、いかなる形態であってもよい。例えば、クライアント装置１０は、パーソナルコンピュータ、サーバ、携帯電話又はＡＴＭ等である。
【００１５】
クライアント装置１０は、ユーザの操作によって、認証用メールアドレス取得要求をメール認証装置３に送信する。すると、クライアント装置１０は、メール認証装置３から認証用メールアドレスを受信する。認証用メールアドレスについては後ほど詳細を説明する。
【００１６】
クライアント装置１０は、ユーザの操作を契機として、認証用メールアドレス宛てに電子メールを送信する。
【００１７】
クライアント装置１０は、認証用メールアドレスを含む認証要求を、メール認証装置３に送信する。なお、認証要求は、認証用メールアドレスの全部を含んでいてもよいし、認証用メールアドレスの一部を含んでいてもよい。なお、クライアント装置１０は、ユーザの操作を契機に認証要求を送信してもよいし、一定時間ごとに認証要求を送信してもよい。
【００１８】
クライアント装置１０は、認証結果をメール認証装置３から受信する。
【００１９】
図３は、第１の実施形態の個人認証システムに備わるメール認証装置３の構成のブロック図である。メール認証装置３は、物理的には、送受信部３１、中央処理装置３２、主記憶装置３３、補助記憶装置３４、入力装置（図示省略）、表示装置（図示省略）などを備えたコンピュータシステムである。なお、メール認証装置３には、電子メールを受信するためのＩＰアドレス及びドメイン（ＤＯＭＡＩＮ）が割り当てられている。送受信部３１は、ネットワーク９に接続され、外部の装置（クライアント装置１０）とデータを送受信するインタフェースである。中央処理装置３２は、例えば、ＣＰＵである。中央処理装置３２は、主記憶装置３３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置３３は、例えば、メモリである。主記憶装置３３は、中央処理装置３２によって実行されるプログラム及び中央処理装置３２によって必要とされる情報等が記憶される。補助記憶装置３４は、例えば、ハードディスクである。補助記憶装置３４は、各種情報を記憶する。入力装置は、例えば、マウス、キーボード又はタッチパネルである。入力装置には、管理者から各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置３２から表示を指示された情報が表示される。なお、メール認証装置３は、送受信部３１、中央処理装置３２及び主記憶装置３３を備えれば、いかなる形態であってもよい。例えば、メール認証装置３は、パーソナルコンピュータ又はサーバ等である。
【００２０】
図４は、第１の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１の実施形態の認証プログラム３００が記憶されている。第１の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証用メールアドレス取得要求受信モジュール３３２１、認証要求受信モジュール３３２２、認証用メールアドレス生成モジュール３３４、認証用メールアドレス送信モジュール３３５、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【００２１】
メインモジュール３３１は、認証用メールアドレス取得要求受信モジュール３３２１、認証要求受信モジュール３３２２、認証用メールアドレス生成モジュール３３４、認証用メールアドレス送信モジュール３３５、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【００２２】
認証用メールアドレス取得要求受信モジュール３３２１は、クライアント装置１０から認証用メールアドレス取得要求を受信する。認証用メールアドレス取得要求受信モジュール３３２１は、認証用メールアドレス取得要求を受信すると、認証用メールアドレス生成モジュール３３４に認証用メールアドレスの生成を依頼する。
【００２３】
認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【００２４】
認証用メールアドレス生成モジュール３３４は、認証用メールアドレス取得要求受信モジュール３３２１から依頼を受けると、メール認証装置３によって受信可能なメールアドレスを新たに生成する。そして、認証用メールアドレス生成モジュール３３４は、生成したメールアドレスを認証用メールアドレスとして、認証用メールアドレス送信モジュール３３５に引き渡す。なお、認証用メールアドレス生成モジュール３３４は、認証用メールアドレスを生成してから所定の時間が経過すると、認証用メールアドレスを破棄してもよい。認証用メールアドレスが破棄されると、メール認証装置３は、当該認証用メールアドレスで電子メールを受信できない。よって、当該認証用メールアドレスによる成りすましのアクセスがなくなる。なお、認証用メールアドレスが破棄される時期については、本発明の実施者に委ねられる。
【００２５】
認証用メールアドレス生成モジュール３３４の認証用メールアドレスの生成方法の一例を説明する。認証用メールアドレス生成モジュール３３４は、メール認証装置３に割り当てられているドメインに基づいて、認証用メールアドレスを生成する。メール認証装置３に割り当てられているドメインが「ａｕｔｈａｄｄ．ｃｏｍ」の場合を説明する。認証用メールアドレス生成モジュール３３４は、乱数、アプリケーションＩＤ及び認証用メールアドレスの生成時刻等に基づいて、ランダムな文字列を生成する。なお、アプリケーションＩＤは、当該メール認証装置３にインストールされている認証プログラム３００の一意な識別子である。なお、アプリケーションＩＤは、一般的にライセンスキーとして知られているものであり、詳細な説明は省略する。例えば、認証用メールアドレス生成モジュール３３４は、ランダムな文字列の「００２９３８２」を生成する。そして、認証用メールアドレス生成モジュール３３４は、生成された文字列の「００２９３８２」及びドメインの「ａｕｔｈａｄｄ．ｃｏｍ」に基づいて、「００２９３８２＠ａｕｔｈａｄｄ．ｃｏｍ」を認証用メールアドレスとして生成する。なお、認証用メールアドレスの生成方法は、その目的を達成する限り他の方法を用いてもよい。
【００２６】
仮に、メール認証装置３は、認証用メールアドレス取得要求を複数のクライアント装置１０から同時に受信すると、受信したそれぞれの認証用メールアドレス取得要求ごとに異なる認証用メールアドレスを生成する。また、メール認証装置３は、第１の認証用メールアドレス取得要求を受信した後に、当該第１の認証要求の送信元であるクライアント装置１０から第２の認証用メールアドレス取得要求を受信してもよい。この場合、メール認証装置３は、第１の認証用メールアドレス取得要求に対して生成された認証用メールアドレスと異なる認証用メールアドレスを生成する。これによって、メール認証装置３は、同一のクライアント装置１０から送信される複数の認証要求を同時に処理できる。
【００２７】
次に、認証用メールアドレス生成モジュール３３４は、生成した認証用メールアドレスを、認証用メールアドレス送信モジュール３３５に引き渡す。
【００２８】
認証用メールアドレス送信モジュール３３５は、認証用メールアドレス生成モジュール３３４から引き受けた認証用メールアドレスを、クライアント装置１０に送信する。
【００２９】
メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する。なお、メール受信モジュール３３６は、クライアント装置１０以外から電子メールを受信してもよい。次に、メール受信モジュール３３６は、受信した電子メールから、送信先のメールアドレスを取得する。次に、メール受信モジュール３３６は、取得した送信先メールアドレスと一致する認証用メールアドレスを破棄する。これによって、メール認証装置３は、破棄された認証用メールアドレス宛ての電子メールを受信できなくなる。なお、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。なお、送信元のメールアドレスの偽装は、いかなる方法で判定されてもよい。
【００３０】
受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。続けて、受信メール読取モジュール３３７は、メールアドレス対応テーブル３４１（図５）に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信先メールアドレス３４１２に、電子メールから取得した送信先メールアドレスを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１３に、電子メールから取得した送信元メールアドレスを格納する。
【００３１】
図５は、第１の実施形態のメール認証装置３の補助記憶装置３４に記憶されているメールアドレス対応テーブル３４１の構成図である。メールアドレス対応テーブル３４１は、送信先メールアドレス３４１２及び送信元メールアドレス３４１３を含む。送信先メールアドレス３４１２は、当該メール認証装置３が受信した電子メールの送信先メールアドレスである。送信元メールアドレス３４１３は、当該メール認証装置３が受信した電子メールの送信元メールアドレスである。なお、本実施の形態では、送信先メールアドレス３４１２は、メール認証装置３と接続される多数のクライアント計算機１０の中から、認証を要求するユーザによって操作されるクライアント計算機１０を特定するために使用される。また、送信元メールアドレス３４１３は、認証を要求するユーザを特定するために使用される。
【００３２】
認証モジュール３３８は、認証用メールアドレスを含む認証要求をクライアント装置１０から受信する。なお、認証要求は、認証用メールアドレスの一部を含んでいてもよいし、認証用メールアドレスの全部を含んでいてもよい。例えば、認証用メールアドレスの一部は、認証用メールアドレスのドメインを除く文字列である。なお、クライアント装置１０は、認証要求と共に、当該認証要求に対応する認証用メールアドレスをメール認証装置３に通知できればいかなる方法であってもよい。例えば、認証要求を送信するための通信のセッションＩＤが、認証用メールアドレスの一部又は全部を含んでいてもよい。セッションＩＤは、ＷＥＢサーバとＷＥＢブラウザとの間の通信を識別する識別子である。セッションＩＤの生成及び管理は、通常のＷＥＢサーバ及び通常のＷＥＢブラウザの機能である。したがって、セッションＩＤの詳細な説明は、省略する。
【００３３】
続けて、認証モジュール３３８は、受信した認証要求から認証用メールアドレスを取得する。次に、認証モジュール３３８は、取得した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。これによって、認証モジュール３３８は、まったく別個の通信である認証要求と電子メールとの対応を把握する。つまり、認証モジュール３３８は、メール受信モジュール３３６が受信した電子メールの中から、受信した認証要求に対応する電子メールを特定する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１３を抽出する。つまり、認証モジュール３３８は、受信した認証要求に対応する電子メールの送信元アドレスを特定する。認証モジュール３３８は、送信元メールアドレス３４１３を抽出できない場合、認証不可と判定する。
【００３４】
次に、認証モジュール３３８は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。ユーザ管理テーブル３４２については、詳細を後述する。認証モジュール３３８は、メールアドレスが一致するレコードを選択できない場合は、認証不可と判定する。一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できる場合は、認証可能と判定する。そして、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元の計算機を操作するユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、認証要求の発行元の計算機が、抽出したユーザＩＤ３４２１によって識別されるユーザによって操作されていると判断する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【００３５】
図６は、第１の実施形態のメール認証装置３の補助記憶装置３４に記憶されているユーザ管理テーブル３４２の構成図である。ユーザ管理テーブル３４２は、ユーザＩＤ３４２１、メールアドレス３４２２を含む。ユーザＩＤ３４２１は、第１の実施形態のメール認証装置３で認証を受けるユーザの一意な識別子である。メールアドレス３４２２は、当該レコードのユーザＩＤ３４２１によって識別されるユーザの電子メールアドレスである。通常、メールアドレス３４２２は、当該レコードのユーザＩＤ３４２１によって識別されるユーザのみが使用可能な電子メールアドレスである。電子メールにはプライベートな内容が含まれるため、多くの個人が、自分専用の電子メールアドレスを保有している。なお、ユーザ管理テーブル３４２は、ユーザ固有のその他の情報を保有してもよい。ユーザの固有な情報は、例えば、ユーザ名、パスワード、クレジットカード番号、キャッシュカード番号、ユーザの生体情報、スケジュール表、操作履歴及び預金残高のうち少なくとも一つを含む。つまり、ユーザ管理テーブル３４２では、ユーザの固有な情報はユーザＩＤ３４２１に対応して管理されている。
【００３６】
第１の実施形態のメール認証装置３のユーザは、予め所定の方法で、ユーザ管理テーブル３４２にユーザＩＤ３４２１及びメールアドレス３４２２を登録する。なお、メールアドレス３４２２がユーザＩＤとして使用される場合、ユーザＩＤ３４２１は省略できる。
【００３７】
認証結果送信モジュール３３９は、認証モジュール３３８が判定した認証結果を、クライアント装置１０に送信する。なお、認証モジュール３３８が認証可能と判定した場合、認証結果送信モジュール３３９は、ユーザＩＤ３４２１に対応するユーザの固有な情報を付随した認証結果を送信してもよい。
【００３８】
次に、第１の実施形態の個人認証方法の処理について図を用いて説明する。図７は、第１の実施形態の個人認証方法の処理のシーケンス図である。
【００３９】
クライアント装置１０は、ユーザの操作を契機に、認証用メールアドレス取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ１１１）。
【００４０】
すると、認証用メールアドレス取得要求受信モジュール３３２１は、クライアント装置１０から認証用メールアドレス取得要求を受信する（ＳＴ１１２）。次に、認証用メールアドレス取得要求受信モジュール３３２１は、認証用メールアドレス生成モジュール３３４に、認証用メールアドレスの生成を依頼する。
【００４１】
認証用メールアドレス生成モジュール３３４は、認証用メールアドレスの生成の依頼を受けると、認証用メールアドレスを生成する（ＳＴ１１４）。次に、認証用メールアドレス生成モジュール３３４は、生成した認証用メールアドレスを、認証用メールアドレス送信モジュール３３５に引き渡す。
【００４２】
認証用メールアドレス送信モジュール３３５は、認証用メールアドレスを、認証用メールアドレス生成モジュール３３４から引き受ける。次に、認証用メールアドレス送信モジュール３３５は、引き受けた認証用メールアドレスを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ１１６）。
【００４３】
クライアント装置１０は、メール認証装置３から認証用メールアドレスを受信する（ＳＴ１１７）。
【００４４】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、認証用メールアドレス宛ての電子メールを送信する（ＳＴ１１８）。
【００４５】
すると、メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する（ＳＴ１１９）。次に、メール受信モジュール３３６は、受信した電子メールから、送信先のメールアドレスを取得する。次に、メール受信モジュール３３６は、取得したメールアドレスと一致する認証用メールアドレスを破棄する。このとき、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。
【００４６】
続いて、受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、受信メール読取モジュール３３７は、メールアドレス対応テーブル３４１に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信先メールアドレス３４１２に、取得した送信先メールアドレスを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１３に、取得した送信元メールアドレスを格納する（ＳＴ１２０）。
【００４７】
一方で、クライアント装置１０は、認証用メールアドレスの一部又は全部を含む認証要求を、ネットワーク９を介して、メール認証装置３に送信する（ＳＴ１２１）。
【００４８】
すると、認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する（ＳＴ１２２）。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【００４９】
続けて、認証モジュール３３８は、認証の依頼を受けると、認証要求受信モジュール３３２２が受信した認証要求から認証用メールアドレスを取得する。次に、認証モジュール３３８は、取得した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１３を抽出する。なお、認証モジュール３３８は、送信元メールアドレス３４１３を抽出できない場合、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。一方、認証モジュール３３８は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２が一致するレコードを、ユーザ管理テーブル３４２から選択する（ＳＴ１２３）。認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合は、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。なお、第１の実施形態では、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、認証不可と判定した。しかし、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、新規のユーザとして認証してもよい。この場合、認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合、新たなユーザＩＤを生成する。このとき、認証モジュール３３８は、ユーザ管理テーブル３４２に含まれるすべてのユーザＩＤ３４２１と重複しないように、ユーザＩＤを生成する。次に、認証モジュール３３８は、ユーザ管理テーブル３４２に、新たにレコードを生成する。次に、認証モジュール３３８は、生成したユーザＩＤを、生成した新たなレコードのユーザＩＤ３４２１に格納する。更に、認証モジュール３３８は、抽出した送信元メールアドレス３４１３を、生成した新たなレコードのメールアドレス３４２２に格納する。これによって、認証モジュール３３８は、生成したユーザＩＤと電子メールから取得した送信元のメールアドレスとを対応付けて、ユーザ管理テーブル３４２に記憶する。そして、認証モジュール３３８は、電子メールから取得した送信先のメールアドレスに対応するユーザを、新規のユーザとして認証を許可する。なお、認証モジュール３３８は、登録されるユーザの固有な情報をクライアント装置１０から受信してもよい。そして、認証モジュール３３８は、受信したユーザの固有な情報を、新たに生成したレコードに格納する。なお、ユーザの固有な情報は、認証要求に含まれてもよいし、単独で送信されてもよい。
【００５０】
一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できた場合、認証可能と判定する。次に、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元のクライアント計算機１０を操作しているユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、取得したユーザＩＤ３４２１によって識別される認証要求の発行元のクライアント計算機１０を操作しているユーザが、抽出したユーザＩＤ３４２１によって識別されるユーザあると特定する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【００５１】
認証結果送信モジュール３３９は、認証モジュール３３８から認証結果を引き受ける。次に、認証結果送信モジュール３３９は、引き受けた認証結果を、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ１２４）。
【００５２】
すると、クライアント装置１０は、メール認証装置３から認証結果を受信する（ＳＴ１２５）。
【００５３】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、ユーザＩＤ及びパスワードが掠め取られる危険性がない。また、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを管理する必要がない。このように、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【００５４】
本実施の形態では、メール認証装置３は、１台の装置で構成されるものとしたが、提供するサービスの規模などによっては、複数の装置で構成されてもよい。この場合、メール認証装置３を構成する装置は、適宜なデータ転送経路を介して互いに接続される。また、メール認証装置３は、機能別に複数の装置で構成されてもよい。例えば、メール認証装置３は、認証用メールアドレスを生成し、電子メールを受信する装置と、認証用メールアドレス取得要求及び認証要求を受信し、認証用メールアドレス及び認証結果を送信する装置と、で構成する。この場合も、メール認証装置３を構成する装置は、適宜なデータ転送経路を介して互いに接続される。そして、認証用メールアドレス及び電子メールのメールアドレス等を含む情報は、前記データ転送経路を介して装置間で引き渡される。
【００５５】
ここで、本実施の形態の最大の特徴について述べる。メール認証装置３は、認証要求を受信する。メール認証装置３は、受信した認証要求に含まれる認証用メールアドレスに基づいて、受信した電子メールと受信した認証要求との対応を特定できる。つまり、認証用メールアドレスは、一つの認証要求に一意に割り当てられ、認証要求の識別子としても使用される。更に、メール認証装置３は、認証要求に対応する電子メールの送信元のメールアドレスに基づいて、認証を受けようとするユーザを特定する。このようにして、メール認証装置３は、認証要求と当該認証要求によって認証を要求するユーザとの対応を特定できる。これによって、本実施の形態では、メール認証装置３は、認証要求にユーザＩＤが含まれないにもかかわらず、認証を実現できる。ユーザＩＤ及びパスワードによる認証方法では、認証要求に、ユーザＩＤ及びパスワードが含まれる。一方、本実施の形態のメール認証装置３は、認証を受けるユーザを電子メールで特定する。そして、メール認証装置３は、特定したユーザによって操作されるクライアント装置を特定する。これによって、メール認証装置３は、認証要求にユーザＩＤが含まれていなくても、認証を行うことができる。
【００５６】
また、本実施の形態では、クライアント装置１０は、メール認証装置３から認証用メールアドレスを受信し、受信した認証用メールアドレス宛てに電子メールを送信した。しかし、次の通りであってもよい。クライアント装置１０は、メール認証装置３から受信した認証用メールアドレスを表示装置に表示する。続いて、ユーザは、認証用メールアドレスを表示しているクライアント装置１０と異なる第２のクライアント装置１０から、認証用メールアドレス宛てに電子メールを送信してもよい。この場合、認証されるユーザは、第２のクライアント装置１０から送信した電子メールの送信元メールアドレスに対応するユーザである。そして、認証用メールアドレスを表示したクライアント装置１０が、メール認証装置３から認証結果を受信する。例えば、認証用メールアドレスを表示するクライアント装置１０は、パーソナルコンピュータであり、電子メールを送信する第２のクライアント装置１０は、インターネットに接続され電子メールの送信が可能な携帯電話である。
【００５７】
ところで、前述した実施形態では、クライアント装置１０のユーザは、認証を受けるために、電子メールを用いた。クライアント装置１０のユーザは、認証を受けるために、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）による通信を用いてもよい。この場合、クライアント装置１０は、ＳＩＰユーザ・エージェントの機能を備える。また、メール認証装置３は、ＳＩＰユーザ・エージェントの機能及びＳＩＰサーバの機能を備える。そして、メール認証装置３は、認証用メールアドレスの代わりに、認証用ユーザエージェントアドレスを生成する。認証用ユーザエージェントアドレスは、メール認証装置３がＳＩＰに基づく通信を受信するためのアドレスである。アドレス体系は、電子メールと同様のため、詳細な説明は省略する。認証用ユーザエージェントアドレスの生成方法は、認証用メールアドレスの生成方法と同様であればよい。メール認証装置３は、認証用ユーザエージェントアドレスを生成し、クライアント装置１０に通知する。クライアント装置１０は、ユーザの操作を契機に、ＳＩＰによって、認証用ユーザエージェントアドレス宛てにシグナリングを送信する。メール認証装置３は、クライアント装置１０からシグナリングを受信する。メール認証装置３は、受信したシグナリングから、送信元のユーザエージェントアドレス及び送信先のユーザエージェントアドレスを抽出する。次に、メール認証装置３は、取得した送信先のユーザエージェントアドレスと認証用メールアドレス対応テーブルの認証用ユーザエージェントアドレスとの対応を、ユーザエージェントアドレス対応テーブルに格納する。一方、クライアント装置１０は、認証用ユーザエージェントアドレスの一部又は全部を含む認証要求をメール認証装置３に送信する。メール認証装置３は、クライアント装置１０から認証要求を受信する。メール認証装置３は、受信した認証要求から、認証用ユーザエージェントアドレスを抽出する。次に、メール認証装置３は、抽出した認証用ユーザエージェントアドレスとユーザエージェントアドレス対応テーブルの送信先ユーザエージェントアドレスとが一致するレコードを、ユーザエージェントアドレス対応テーブルから選択する。次に、メール認証装置３は、選択したレコードから、送信元ユーザエージェントアドレスを抽出する。次に、メール認証装置３は、抽出した送信元ユーザエージェントアドレスとユーザ管理テーブルのユーザのユーザエージェントアドレスとが、一致するレコードを選択する。ここで、メール認証装置３は、ユーザ管理テーブルから、ユーザエージェントアドレスが一致するレコードを選択できたか否かを判定する。選択できた場合、メール認証装置３は、認証可能と判定する。そして、メール認証装置３は、認証要求の発行元のユーザを特定できる。具体的には、メール認証装置３は、選択したレコードから、ユーザＩＤを抽出する。そして、メール認証装置３は、受信した認証要求の発行元が、抽出したユーザＩＤによって識別されるユーザであると特定する。なお、メール認証装置３は、抽出したユーザＩＤに対応するユーザの固有な情報を、認証結果に含めてもよい。なお、すべての実施の形態において、電子メールの代わりに、ＳＩＰによる通信を用いてもよい。
【００５８】
ところで、本発明のなりすましに対する安全性は、電子メールの偽装に対する強度に依存しているため、電子メールの偽装について述べる。
【００５９】
はじめに、電子メールの送信元が偽装された場合について述べる。偽装者は、電信メールの送信元を偽装して、第１の実施形態のメール認証装置３で認証されれば、偽装した電子メールアドレスを保有する本来のユーザになりすますことができる。そこで、メール受信モジュール３３６は、ＳＰＦ（Ｓｅｎｄｅｒ Ｐｏｌｉｃｙ Ｆｒａｍｅｗｏｒｋ）に沿ったメール受信機能を搭載する。ＳＰＦとは、電子メールサーバが偽装メールを検知するための技術である。メール受信モジュール３３６は、受信した電子メールのドメインについて、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）に照会を要求する。そして、メール受信モジュール３３６は、ＤＮＳによる照会結果と電子メールの送信元のＩＰアドレスとを照合することによって、電子メールの送信元のメールアドレスが偽装されているか否かを判定する。なお、メール受信モジュール３３６が採用する偽装メール検知技術は、その目的を達成する限り、ＤＫＩＭ等の他の方法であってもよい。
【００６０】
次に、電子メールの送信先が偽装された場合について述べる。偽装者は、電子メールの送信先を偽装して、第１の実施形態のメール認証装置３で認証されても、他者になりすますことはできない。むしろ、他者が、偽装者になりすましてしまう。偽装者になりすます他者は、偽装した送信先メールアドレスと同一のメールアドレスを認証用メールアドレスとして受信したクライアント装置を操作する者である。したがって、偽装者は、電子メールの送信先を偽装しても、利益を得られない。また、認証用メールアドレスは乱数などによって生成されるため、偽装したメールアドレスが認証用メールアドレスと一致することは稀である。
【００６１】
ここでは、本発明における認証について説明する。本発明における認証は、一般的な概念だけでなく、広い意味での認証を含む。具体的には、本発明における認証とは、個人認証システムによって提供されるサービスを利用する権利が、ユーザにあるか否かの検証である。本発明の個人認証システムは、クライアント装置を利用しているユーザを識別し、識別したユーザごとに対応するサービスを提供できる。従って、本発明における認証要求とは、個人認証システムによって提供されるサービスを利用する権利が、ユーザにあるか否かの検証の要求である。例えば、認証要求は、ＷＥＢページのログインの要求である。この場合、メール認証装置３は、ＷＥＢサーバであってもよいし、ＷＥＢサーバから認証の依頼を受ける認証専用装置であってもよい。また、認証要求は、ＷＥＢページでのクレジットカード決済の要求である。この場合、メール認証装置３は、クレジットカード決済を行うＷＥＢサーバであってもよいし、当該ＷＥＢサーバから認証の依頼を受ける認証専用装置であってもよい。また、認証要求は、ＡＴＭにおける預金の引き出し、借入金返済又は借入金の借り入れの要求である。この場合、クライアント装置１０は、ＡＴＭである。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、ＡＴＭにおける決済を管理する管理サーバである。また、認証要求は、店舗でのクレジットカード決済の要求である。この場合、クライアント装置１０は、クレジットカードの情報を読み取るリーダ装置である。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該リーダ装置におけるクレジットカードの決済を管理する管理サーバである。また、認証要求は、デビットカード決済の要求である。この場合、クライアント装置１０は、デビットカードの情報を読み取るリーダ装置である。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該リーダ装置におけるデビットカードの決済を管理する管理サーバである。また、認証要求は、公共料金との合算後払いによる借り入れの要求である。この場合、クライアント装置１０は、ＡＴＭである。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該ＡＴＭにおける借り入れを管理する管理サーバである。また、認証要求とは、公共料金の未払金の支払いの要求である。この場合、クライアント装置１０は、コンビニ等に設置されている情報端末である。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該情報端末を管理する管理サーバである。また、認証要求は、社内イントラネットへの接続の要求である。この場合、メール認証装置３は、社内のイントラネットを管理する管理サーバである。また、認証要求は、シンクライアント（ＴＨＩＮ ＣＬＩＥＮＴ）によるサーバへの接続の要求である。この場合、メール認証装置３は、シンクライアント装置とサーバとの接続を管理する管理サーバである。また、認証要求は、無線ＬＡＮのアクセスポイントへの接続の要求である。この場合、メール認証装置３は、クライアント装置１０とアクセスポイントとの接続を管理する管理サーバである。本実施の形態の認証要求は、ユーザＩＤ及びパスワードを含まないが、メール認証装置３は、認証処理を行うことができる。なお、メール認証装置３は、本実施の形態の認証処理とあわせて、従来の認証処理を実行することによって、安全性を高めてもよい。例えば、メール認証装置３は、本実施の形態の認証処理とあわせて、ユーザの固有な情報を照合することによって、認証してもよい。ユーザの固有な情報は、例えば、ユーザ名、パスワード、クレジットカード番号、キャッシュカード番号、ユーザの生体情報、メールアドレス及び電話番号のうち少なくとも一つを含む。但し、ユーザの固有な情報は、ユーザ管理テーブル３４２のメールアドレス３４２２に登録されているメールアドレス以外であるのが好ましい。なぜなら、なりすましによって認証を受けようとする悪意者は、ユーザ管理テーブル３４２に登録されているメールアドレスを知っているので、本実施の形態の認証システムの安全性を高めることにならないからである。次に、ユーザの固有な情報を照合する認証方法の具体例を説明する。具体的には、メール認証装置３は、ユーザＩＤ及びパスワードの少なくとも一方を照合することによって、認証してもよい。この場合、メール認証装置３は、ユーザＩＤとユーザの固有な情報との対応を予め記憶しておく。一方、認証を受けようとするユーザは、クライアント装置１０に、ユーザの固有な情報を入力する。ここでの入力は、キーボード等の操作によるものでだけでなく、カードリーダにカードを読み込ませる等を含む。つまり、クライアント装置１０が、ユーザの固有な情報を取得できればいかなるものであってもよい。また、ユーザの固有な情報の入力タイミングは、いつでもよい。クライアント装置１０は、入力されたユーザの固有な情報を、メール認証装置３に送信する。なお、クライアント装置１０は、入力されたユーザの固有な情報を、認証用メールアドレス取得要求に含めて送信してもよいし、認証要求に含めて送信してもよいし、単独で送信してもよい。メール認証装置３は、ユーザの固有な情報をクライアント装置１０から受信する。メール認証装置３の認証モジュール３３８は、個人認証方法の処理（図７）のステップＳＴ１２３において認証要求の発行元のユーザを特定する。次に、メール認証装置３は、特定したユーザのユーザＩＤに対応して記憶されているユーザの固有な情報を特定する。次に、メール認証装置３の認証モジュール３３８は、特定したユーザの固有な情報と、クライアント装置１０から受信したユーザの固有な情報と、が一致するか否かを判定する。そして、メール認証装置３は、二つのユーザの固有な情報が一致すると、認証可能と判定する。一方、メール認証装置３は、二つのユーザの固有な情報が一致しない場合、認証不可と判定する。
【００６２】
また、本実施の形態のユーザは、人でなく、コンピュータであってもよい。例えば、コンピュータがユーザとして、認証を受けてもよい。
【００６３】
（第２の実施形態）
以下で第２の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【００６４】
図８は、第２の実施形態の個人認証システムの概略の構成図である。図８に示す個人認証システムは、クライアント装置９０１０及びメール認証ＷＥＢ装置９０３を備える。クライアント装置９０１０は、認証を受けようとするユーザによって操作される計算機である。また、クライアント装置９０１０は、ネットワーク９に接続されている。なお、第３の実施の形態では、ネットワーク９は、インターネットである。クライアント装置９０１０の構成は、第１の実施形態の個人認証システムに備わるクライアント装置１０（図２）と同一なので、説明を省略する。なお、クライアント装置９０１０は、送受信部、中央処理装置及び主記憶装置を備えれば、いかなる形態であってもよい。例えば、クライアント装置９０１０は、パーソナルコンピュータ、サーバ、携帯電話又はＡＴＭ等である。但し、携帯電話は、クライアント装置９０１０である場合、ＷＥＢブラウザ機能を搭載している。メール認証ＷＥＢ装置９０３は、ネットワーク９を介してクライアント装置９０１０に接続されている。メール認証ＷＥＢ装置９０３は、ＷＥＢサーバ機能及びメール受信サーバ機能を備える。メール認証ＷＥＢ装置９０３の構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図３）と同一なので、説明を省略する。なお、説明を明瞭にするために、第２の実施形態の個人認証システムでは、１台のクライアント装置９０１０に対する認証処理を説明する。実際には、メール認証ＷＥＢ装置９０３は、ネットワーク９を介して、複数のクライアント装置９０１０に対する認証を行う。なお、図８では、クライアント装置９０１０は、５台（パーソナルコンピュータ３台及び携帯電話２台）を図示したが、個人認証システムに何台備わっていても良い。
【００６５】
クライアント装置９０１０の機能は、第１の実施形態の個人認証システムに備わるクライアント装置１０と同様なので、説明を省略する。具体的には、クライアント装置９０１０は、ＨＴＴＰによって、認証要求及び認証要求を、メール認証ＷＥＢ装置９０３へ送信する。また、クライアント装置９０１０は、ＨＴＴＰによって、認証用メールアドレス及び認証結果を、メール認証ＷＥＢ装置９０３から受信する。
【００６６】
図９は、第２の実施形態のメール認証ＷＥＢ装置９０３の機能ブロック図である。メール認証ＷＥＢ装置９０３の補助記憶装置には、第２の実施形態の認証プログラム９０３００が記憶されている。第２の実施形態の認証プログラム９０３００が実行されると、メール認証ＷＥＢ装置９０３の主記憶装置には、メインモジュール３３１、認証用メールアドレス取得要求受信モジュール３３２１、認証要求受信モジュール３３２２、認証用メールアドレス生成モジュール３３４、認証用メールアドレス送信モジュール９０３３５、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール９０３３９が記憶される。
【００６７】
認証用メールアドレス送信モジュール９０３３５は、第１の実施形態のメール認証装置３に備わる認証用メールアドレス送信モジュール３３５と同一の機能を備える。また、認証結果送信モジュール９０３３９は、第１の実施形態のメール認証装置３に備わる認証結果送信モジュール３３９と同一の機能を備える。その他のモジュールは、第１の実施形態のメール認証装置３に備わるものと同一なので、説明を省略する。
【００６８】
認証用メールアドレス送信モジュール９０３３５は、認証用メールアドレス送信モジュール３３５の機能に加え、認証用メールアドレスを含むＷＥＢページを生成する。認証用メールアドレス送信モジュール９０３３５は、生成したＷＥＢページを、クライアント装置９０１０に送信する。
【００６９】
認証用メールアドレス送信モジュール９０３３５によって生成されるＷＥＢページ（図示省略）は、認証用メールアドレス及び認証要求ボタンを含み、クライアント装置９０１０に表示される。認証要求ボタンは、ユーザから認証要求の送信の指示を受け付けるものである。つまり、認証要求ボタンがユーザによって操作されると、クライアント装置９０１０は、認証要求をメール認証ＷＥＢ装置９０３に送信する。なお、認証用メールアドレス送信モジュール９０３３５によって生成されるＷＥＢページは、認証要求ボタンを含まなくてもよい。この場合、クライアント装置９０１０は、ユーザの操作を契機とせずに、認証要求をメール認証ＷＥＢ装置９０３へ一定間隔で送信する。
【００７０】
認証結果送信モジュール９０３３９は、認証結果送信モジュール３３９の機能に加え、認証モジュール３３８による認証結果を含むＷＥＢページを生成する。認証結果送信モジュール９０３３９は、生成したＷＥＢページを認証結果として、クライアント装置９０１０に送信する。なお、認証結果が認証可能であった場合、認証結果送信モジュール９０３３９によって生成されたＷＥＢページには、ユーザＩＤに対応するユーザの固有な情報が含まれてもよい。ユーザの固有な情報は、例えば、ユーザ名、パスワード、クレジットカード番号、キャッシュカード番号、ユーザの生体情報、スケジュール表、操作履歴及び預金残高のうち少なくとも一つを含む。
【００７１】
次に、第２の実施形態の個人認証方法について図を用いて説明する。図１０は、第２の実施形態の個人認証方法の処理のシーケンス図である。第２の実施形態の個人認証方法（図１０）と第１の実施形態の個人認証方法（図７）とを比較する。第２の実施形態の個人認証方法は、ＳＴ９０１１６を、ＳＴ１１６の代わりに含む。また、第２の実施形態の個人認証方法は、ＳＴ９０１２４を、ＳＴ１２４の代わりに含む。なお、第２の実施形態の個人認証方法の処理は、ＳＴ９０１１６及びＳＴ９０１２４を除いて、第１の実施形態の個人認証方法（図７）と同様である。したがって、ＳＴ９０１１６及びＳＴ９０１２４以外のステップについては、説明を省略する。
【００７２】
ＳＴ９０１１６について述べる。認証用メールアドレス送信モジュール９０３３５は、認証用メールアドレス生成モジュール３３４によって生成された認証用メールアドレスを、認証用メールアドレス生成モジュール３３４から引き受ける。次に、認証用メールアドレス送信モジュール３３５は、引き受けた認証用メールアドレスを含むＷＥＢページを生成する。次に、認証用メールアドレス送信モジュール９０３３５は、生成したＷＥＢページを、ネットワーク９を介して、クライアント装置９０１０に送信する（ＳＴ９０１１６）。
【００７３】
次に、ＳＴ９０１２４について述べる。認証結果送信モジュール９０３３９は、認証モジュール３３８から認証結果を引き受ける。次に、認証結果送信モジュール９０３３９は、引き受けた認証結果を含むＷＥＢページを生成する。次に、認証結果送信モジュール９０３３９は、生成したＷＥＢページを、ネットワーク９を介してクライアント装置９０１０に送信する（ＳＴ９０１２４）。なお、認証結果送信モジュール９０３３９は、ユーザＩＤに対応するユーザの固有な情報を含むＷＥＢページを生成し、生成したＷＥＢページを送信してもよい。
【００７４】
前述の通り、クライアント装置９０１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、ユーザＩＤ及びパスワードが掠め取られる危険性がない。また、クライアント装置９０１０のユーザは、ユーザＩＤ及びパスワードを管理する必要がない。このように、本実施の形態は、ＷＥＢサイトのユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、フィッシング又はスパイウェア等によって、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【００７５】
（第３の実施形態）
以下で第３の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システム又は第２の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【００７６】
第２の実施形態の個人認証システムに備わるメール認証ＷＥＢ装置９０３は、認証機能及びユーザの固有な情報を含むＷＥＢページの送信機能を備える。このとき、従来のＷＥＢサーバをメール認証ＷＥＢ装置９０３の機能を備えるように変更するためには、ＷＥＢサーバのプログラムの変更が不可欠である。これに対して、第３の実施形態では、従来のＷＥＢサーバへ、本発明の個人認証方法を容易に導入可能な実施形態を説明する。第３の実施形態の個人認証システムに備わる従来のＷＥＢサーバを、導入ＷＥＢサーバ５とする。
【００７７】
図１１は、第３の実施形態の個人認証システムの概略の構成図である。図１１に示す個人認証システムは、複数のクライアント装置１０、複数の携帯電話６０、導入ＷＥＢサーバ５及びメール認証専用ＷＥＢ装置９４３を備える。クライアント装置１０は、認証を受けようとするユーザによって操作される計算機である。クライアント装置１０はネットワーク９に接続されている。クライアント装置１０の構成は、第１の実施形態の個人認証システムに備わるクライアント装置１０（図２）と同一なので、説明を省略する。携帯電話６０は、認証を受けようとするユーザによって操作される。携帯電話６０は、ＷＥＢブラウザを搭載する。また、携帯電話６０は、電子メール送信機能を搭載する。携帯電話６０は、ネットワーク９に接続されている。導入ＷＥＢサーバ５は、ネットワーク９を介してクライアント装置１０及び携帯電話６０に接続されている。なお、本実施の形態では、ネットワーク９はインターネットである。導入ＷＥＢサーバ５は、従来のＷＥＢサーバである。例えば、導入ＷＥＢサーバ５は、クライアント装置１０のユーザからログインを受け付ける。そして、導入ＷＥＢサーバ５は、ユーザの固有な情報を含むＷＥＢページをクライアント装置１０に送信する。具体的には、導入ＷＥＢサーバ５は、ユーザＩＤに対応する会員用のＷＥＢページを送信する。メール認証専用ＷＥＢ装置９４３は、ネットワーク９を介してクライアント装置１０及び携帯電話６０に接続されている。メール認証専用ＷＥＢ装置９４３は、ＷＥＢサーバ機能及びメール受信サーバ機能を備えている。メール認証専用ＷＥＢ装置９４３の構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図３）と同一なので、説明を省略する。なお、図１１では、クライアント装置１０は、３台を図示したが、個人認証システムに何台備わっていても良い。また、携帯電話６０は、２台を図示したが、個人認証システムに何台備わっていてもよい。
【００７８】
なお、説明を明瞭にするために、第３の実施形態の個人認証システムの説明では、導入ＷＥＢサーバ５には、ドメイン「ｄｏｕｎｙｕ．ｊｐ」が割り当てられているとする。また、メール認証専用ＷＥＢ装置９４３には、ドメイン「ｎｉｎｓｈｏ．ｊｐ」が割り当てられているとする。
【００７９】
クライアント装置１０の機能構成は、第１の実施形態の個人認証システムに備わるクライアント装置１０と同一なので、説明を省略する。なお、クライアント装置１０は、導入ＷＥＢサーバ５でなく、メール認証専用ＷＥＢ装置９４３に、認証用メールアドレス取得要求を送信する。その後、クライアント装置１０は、認証用メールアドレスを、メール認証専用ＷＥＢ装置９４３から受信する。また、クライアント装置１０は、認証用メールアドレス宛てに電子メールを送信することによって、メール認証専用ＷＥＢ装置９４３に電子メールを送信する。そして、クライアント装置１０は、認証用メールアドレスの一部又は全部を含む認証要求をメール認証専用ＷＥＢ装置９４３に送信する。
【００８０】
クライアント装置１０は、第１の実施形態の個人認証システムに備わるクライアント装置１０の機能に加えて、次の機能を持つ。クライアント装置１０は、ユーザの操作を契機に、ログイン用のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。また、クライアント装置１０は、メール認証専用ＷＥＢ装置９４３から受信する認証の結果を示すＷＥＢページに含まれる情報によって、会員用のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。
【００８１】
導入ＷＥＢサーバ５は、クライアント装置１０から、ログイン用のＷＥＢページの要求を受信する。すると、導入ＷＥＢサーバ５は、要求されたログイン用のＷＥＢページをクライアント装置１０に送信する。当該ログイン用のＷＥＢページは、認証サイト情報を含む。認証サイト情報とは、クライアント装置１０に、メール認証専用ＷＥＢ装置９４３への認証要求の送信を促す情報である。また、認証サイト情報は、戻先ＵＲＬを含む。戻先ＵＲＬとは、メール認証専用ＷＥＢ装置９４３による認証完了後に、クライアント装置１０が会員用のＷＥＢページの要求を送信するＵＲＬである。ここで、認証サイト情報の例を示す。例えば、認証サイト情報は、「＜ＳＣＲＩＰＴ ＳＲＣ＝‘ｈｔｔｐ：／／ｗｗｗ．ｎｉｎｓｈｏ．ｊｐ／ｉｎｄｅｘ．ｐｈｐ？ｒｕｒｌ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ’＞＜／ＳＣＲＩＰＴ＞」である。「ｒｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。また、例えば、認証サイト情報は、「＜Ａ ＨＲＥＦ＝‘ｈｔｔｐ：／／ｗｗｗ．ｎｉｎｓｈｏ．ｊｐ／ｉｎｄｅｘ．ｐｈｐ？ｒｕｒｌ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ’＞認証はこちら＜／Ａ＞」である。「ｒｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。認証サイト情報は、その目的を達成する限り、他のものであってもよい。
【００８２】
導入ＷＥＢサーバ５は、クライアント装置１０から、会員用のＷＥＢページの要求を受信する。導入ＷＥＢサーバ５は、受信した会員用のＷＥＢページの要求から、ユーザのメールアドレスを抽出する。導入ＷＥＢサーバ５は、抽出したメールアドレスに基づいて、事前に記憶しているユーザの固有な情報を含むＷＥＢページを生成する。導入ＷＥＢサーバ５は、生成したＷＥＢページを、会員用のＷＥＢページとして、クライアント装置１０に送信する。
【００８３】
メール認証専用ＷＥＢ装置９４３の機能は、主に、第２の実施形態の個人認証システムに備わるメール認証ＷＥＢ装置９０３と同様である。メール認証専用ＷＥＢ装置９４３の機能は、第２の実施形態の個人認証システムに備わるメール認証ＷＥＢ装置９０３の機能に加えて、次の機能を備える。メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から受信する認証用メールアドレス取得要求から、戻先ＵＲＬを抽出する。また、メール認証専用ＷＥＢ装置９４３は、抽出した戻先ＵＲＬを、生成した認証用メールアドレスと共に送信する。また、メール認証専用ＷＥＢ装置９４３は、認証の結果、戻先ＵＲＬ及びユーザのメールアドレスを含むＷＥＢページを生成する。生成されたＷＥＢページに含まれるソースコードの例を示す。例えば、ソースコードは、「＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝“Ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝“０；ｕｒｌ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ？ｕｓｒｍａｉｌ＝ｔａｋａ＠ｙａｈｏｏ．ｃｏ．ｊｐ＆ａｕｔｈ＝１”＞」である。「ｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。「ｕｓｒｍａｉｌ＝」以降のメールアドレスが、ユーザのメールアドレスである。「ａｕｔｈ＝」以降の値が、認証の結果である。例えば、「１」は、認証可能であり、「０」は認証不可である。ただし、「ａｕｔｈ＝」は必ずしも含まれている必要はない。また、例えば、ソースコードは、「＜Ａ ＨＲＥＦ＝“ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ？ｕｓｒｍａｉｌ＝ｔａｋａ＠ｙａｈｏｏ．ｃｏ．ｊｐ＆ａｕｔｈ＝１”＞会員ページはこちら＜／Ａ＞」である。「ｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。「ｕｓｒｍａｉｌ＝」以降のメールアドレスが、ユーザのメールアドレスである。「ａｕｔｈ＝」以降の値が、認証の結果である。例えば、「１」は、認証可能であり、「０」は認証不可である。ただし、「ａｕｔｈ＝」は必ずしも含まれている必要はない。なお、前記ＷＥＢページが含むソースコードは、その目的を達成する限り、他のものであってもよい。
【００８４】
次に、第３の実施形態の個人認証方法について図を用いて説明する。図１２は、第３の実施形態の個人認証方法の処理のシーケンス図である。第３の実施形態の個人認証方法（図１２）と第２の実施形態の個人認証方法（図１０）とを比較する。第３の実施形態の個人認証方法は、ＳＴ９４１１２を、ＳＴ１１２の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１１６を、ＳＴ９０１１６の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１２１を、ＳＴ１２１の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１２２を、ＳＴ１２２の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１２４を、ＳＴ１２４の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１０９、ＳＴ９４１１０、ＳＴ９４１２６、ＳＴ９４１２１、ＳＴ９４１２２、ＳＴ９４１２７及びＳＴ９４１２８を含む。なお、第３の実施形態の個人認証方法の処理は、ＳＴ９４１０９、ＳＴ９４１１０、ＳＴ９４１１２、ＳＴ９４１１６、ＳＴ９４１２４、ＳＴ９４１２６、ＳＴ９４１２７及びＳＴ９４１２８を除いて、第２の実施形態の個人認証方法（図１０）と同様である。したがって、ＳＴ９４１０９、ＳＴ９４１１０、ＳＴ９４１１２、ＳＴ９４１１５、ＳＴ９４１２４、ＳＴ９４１２６、ＳＴ９４１２７及びＳＴ９４１２８以外のステップについては、説明を省略する。
【００８５】
ＳＴ９４１０９について説明する。クライアント装置１０は、ネットワーク９を介して導入ＷＥＢサーバ５へ、ログイン用のＷＥＢページの要求を送信する（ＳＴ９４１０９）。
【００８６】
ＳＴ９４１１０について説明する。導入ＷＥＢサーバ５は、クライアント装置１０から、ログイン用のＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、認証サイト情報を含むログイン用のＷＥＢページを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ９４１１０）。
【００８７】
ＳＴ９４１１２について説明する。メール認証専用ＷＥＢ装置９４３に備わる認証要求受信モジュールは、クライアント装置１０から認証要求を受信する。次に、認証要求受信モジュールは、受信した認証要求に含まれる戻先ＵＲＬを抽出する。次に、認証要求受信モジュールは、認証用メールアドレス生成モジュールに、認証要求メールアドレスの生成を依頼する（ＳＴ９４１１２）。
【００８８】
ＳＴ９４１１６について説明する。認証用メールアドレス送信モジュールは、認証用メールアドレス生成モジュールによって生成された認証用メールアドレスを、認証用メールアドレス生成モジュールから引き受ける。次に、認証用メールアドレス送信モジュールは、引き受けた認証用メールアドレスを含むＷＥＢページを生成する。次に、認証用メールアドレス送信モジュール９０３３５は、生成したＷＥＢページ及び認証要求受信モジュールによって抽出された戻先ＵＲＬを、ネットワーク９を介して、クライアント装置１０に送信する（ＳＴ９４１１６）。
【００８９】
ＳＴ９４１２１について説明する。クライアント装置１０は、ＳＴ９４１１６で受信した戻先ＵＲＬ及び認証用メールアドレスを含む認証要求を、ネットワーク９を介して、メール認証専用ＷＥＢ装置９４３に送信する（ＳＴ９４１２１）。
【００９０】
ＳＴ９４１２１について説明する。認証要求受信モジュールは、クライアント装置１０から認証要求を受信する。次に、認証要求受信モジュールは、受信した認証要求から、戻先ＵＲＬ及び認証用メールアドレスを抽出する。そして、認証要求受信モジュールは、認証要求を受信すると、認証モジュールに認証を依頼する。
【００９１】
ＳＴ９４１２４について説明する。認証結果送信モジュールは、認証モジュールから認証の結果を引き受ける。次に、認証結果送信モジュールは、認証の結果、ユーザのメールアドレスを及び認証要求受信モジュールが受信した戻先ＵＲＬ含むＷＥＢページを生成する。次に、認証結果送信モジュールは、生成したＷＥＢページを、認証の結果として、ネットワーク９を介して、クライアント装置１０に送信する（ＳＴ９４１２４）。
【００９２】
ＳＴ９４１２６について説明する。クライアント装置１０は、メール認証専用ＷＥＢ装置９４３から、認証の結果として送信されたＷＥＢページを受信する。次に、クライアント装置１０は、受信したＷＥＢページに基づいて、会員用のＷＥＢページの要求を、ネットワーク９を介して導入ＷＥＢサーバ５へ送信する（ＳＴ９４１２６）。クライアント装置１０によって送信される会員用のＷＥＢページの要求は、ユーザのメールアドレスを含む。例えば、会員用のＷＥＢページの要求は、「ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ？ｕｓｒｍａｉｌ＝ｔａｋａ＠ｙａｈｏｏ．ｃｏ．ｊｐ＆ａｕｔｈ＝１」というＵＲＬである。「ｕｓｒｍａｉｌ＝」以降のメールアドレスが、ユーザのメールアドレスである。
【００９３】
ＳＴ９４１２７について説明する。導入ＷＥＢサーバ５は、クライアント装置１０から会員用ＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、受信した会員用のＷＥＢページの要求から、ユーザのメールアドレスを抽出する。次に、導入ＷＥＢサーバ５は、抽出したメールアドレスに基づいて、ユーザを特定する。次に、メール認証専用ＷＥＢ装置９４３は、特定したユーザに対応する会員用のＷＥＢページを生成する。次に、導入ＷＥＢサーバ５は、生成した会員用のＷＥＢページを、ネットワーク９を介して、クライアント装置１０に送信する（ＳＴ９４１２７）。
【００９４】
ＳＴ９４１２８について説明する。クライアント装置１０は、会員用のＷＥＢページを、ネットワーク９を介して導入ＷＥＢサーバ５から受信する。次に、クライアント装置１０は、受信した会員用のＷＥＢページを、表示装置に表示する（ＳＴ９４１２８）。
【００９５】
第３の実施形態の個人認証方法の処理の概要を説明する。クライアント装置１０は、ユーザの操作を契機に、ログイン用のＷＥＢページを、導入ＷＥＢサーバ５に、要求する（ＳＴ９４１０９）。導入ＷＥＢサーバ５は、要求されたログイン用のＷＥＢページを、クライアント装置１０に送信する（ＳＴ９４１１０）。クライアント装置１０は、ログイン用のＷＥＢページに含まれる認証サイト情報に基づいて、メール認証専用ＷＥＢ装置９４３に認証要求を送信する（ＳＴ１１１）。メール認証専用ＷＥＢ装置９４３は、認証要求を受信する。次に、メール認証専用ＷＥＢ装置９４３は、受信した認証要求から戻先ＵＲＬを抽出する（ＳＴ９４１１２）。次に、メール認証専用ＷＥＢ装置９４３は、認証用メールアドレスを生成する（ＳＴ１１４）。。次に、メール認証専用ＷＥＢ装置９４３は、生成した認証用メールアドレス及び抽出した戻先ＵＲＬを、クライアント装置１０に送信する（ＳＴ９４１１６）。クライアント装置１０は、認証用メールアドレス及び戻先ＵＲＬを受信する（ＳＴ１１７）。次に、クライアント装置１０は、認証用メールアドレス宛てに、電子メールを送信する（ＳＴ１１８）。すると、メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から、電子メールを受信する（ＳＴ１１９）。次に、メール認証専用ＷＥＢ装置９４３は、受信した電子メールの送信元のメールアドレス及び送信先のメールアドレスを特定する。次に、メール認証専用ＷＥＢ装置９４３は、特定した送信先のメールアドレスと特定した送信元のメールアドレスとを対応付けて、メールアドレス対応テーブル３４１に記憶する（ＳＴ１２０）。一方で、クライアント装置１０は、認証要求を、メール認証専用ＷＥＢ装置９４３に送信する（ＳＴ１２１）。すると、メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から、認証要求を受信する（ＳＴ１２２）。メール認証専用ＷＥＢ装置９４３は、受信した認証要求から、認証用メールアドレス及び戻先ＵＲＬを抽出する。次に、メール認証専用ＷＥＢ装置９４３は、メールアドレス対応テーブル３４１から、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証専用ＷＥＢ装置９４３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出した送信元メールアドレス３４１３がユーザ管理テーブル３４２のメールアドレス３４２２に格納されているか否かを判定する（ＳＴ１２３）。送信元メールアドレス３４１３がユーザ管理テーブル３４２に格納されている場合、メール認証専用ＷＥＢ装置９４３は、認証可能と判定する。一方、送信元メールアドレス３４１３がユーザ管理テーブル３４２に格納されていない場合、メール認証専用ＷＥＢ装置９４３は、認証不可と判定する。次に、メール認証専用ＷＥＢ装置９４３は、認証の結果を、クライアント装置１０に送信する（ＳＴ９４１２４）。クライアント装置１０は、認証の結果を受信する（ＳＴ１２５）。次に、クライアント装置１０は、受信した認証の結果に基づいて、会員用のＷＥＢページの要求を導入ＷＥＢサーバ５に送信する（ＳＴ９４１２６）。導入ＷＥＢサーバ５は、クライアント装置１０から、会員用のＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、受信した会員用のＷＥＢページの要求から、ユーザのメールアドレスを抽出する。次に、導入ＷＥＢサーバ５は、抽出したメールアドレスに対応する会員用のＷＥＢページを、クライアント装置１０に送信する（ＳＴ９４１２７）。なお、会員用ＷＥＢページは、抽出されたメールアドレスのユーザに対応するユーザの固有な情報を含む。次に、クライアント装置１０は、会員用のＷＥＢページを、導入ＷＥＢサーバ５から受信する。次に、クライアント装置１０は、受信した会員用のＷＥＢページを、表示装置に表示する（ＳＴ９４１２８）。
【００９６】
前述の通り、従来のＷＥＢサーバである導入ＷＥＢサーバ５は、クライアント装置１０に送信するログイン用のＷＥＢページに、認証サイト情報を含めるだけで、本発明の個人認証方法を導入できる。
【００９７】
前述した実施形態では、メール認証専用ＷＥＢ装置９４３は、ユーザ管理テーブル３４２を記憶している。しかし、メール認証専用ＷＥＢ装置９４３は、必ずしも、ユーザ管理テーブル３４２を記憶している必要はない。この場合、導入ＷＥＢサーバ５が、ユーザ管理テーブル３４２を記憶する。この場合、ステップＳＴ１２３において、メール認証専用ＷＥＢ装置９４３は、抽出した送信元メールアドレス３４１３がユーザ管理テーブル３４２のメールアドレス３４２２に格納されているか否かを判定する必要がない。その代わりに、導入ＷＥＢサーバ５は、クライアント装置１０から受信する会員用のＷＥＢページの要求に含まれるメールアドレスが、ユーザ管理テーブル３４２に格納されているか否かを判定する。
【００９８】
前述した実施形態では、導入ＷＥＢサーバ５は、クライアント装置１０から受信する会員用のＷＥＢページの要求に含まれるメールアドレスを信頼して、会員用のＷＥＢページを送信する。しかし、会員用のＷＥＢページの要求に含まれるメールアドレスは、偽造されことがある。そこで、導入ＷＥＢサーバ５は、ｒｅｆｅｒｅｒを参照することによって、リンク元がメール認証専用ＷＥＢ装置９４３であることを確認してもよい。
【００９９】
（第４の実施形態）
以下で第４の実施形態の個人認証システムについて説明するが、第３の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１００】
インターネット上の電子商取引では、決済手段として、クレジットカードが用いられることが多い。第４の実施形態では、第３の実施形態の個人認証システムを、インターネット上のクレジットカード決済に応用する例を説明する。
【０１０１】
第４の実施形態の個人認証システムの概略の構成図は、第３の実施形態の個人認証システムの概略の構成図（図１１）と同一なので、詳細の説明は省略する。クライアント装置１０は、クレジットカード決済を実行しようとするユーザによって操作される。携帯電話６０は、クレジットカード決済を実行しようとするユーザによって操作される。導入ＷＥＢサーバ５は、物品販売又はサービス販売等の電子商取引を提供するＷＥＢサーバである。メール認証専用ＷＥＢ装置９４３は、クレジットカードの与信審査及び課金を処理するＷＥＢ装置である。メール認証専用ＷＥＢ装置９４３のユーザ管理テーブル３４２は、クレジットカード番号（図示省略）を含む。ユーザ管理テーブルに含まれるクレジットカード番号は、ユーザのクレジットカードの番号である。ユーザ管理テーブル３４２には、クレジットカード番号と当該クレジットカードを所有するユーザの電子メールアドレスとが対応付けて記憶されている。
【０１０２】
第４の実施形態の個人認証方法の処理の概要を説明する。導入ＷＥＢサーバ５は、ユーザの操作を契機に、決済金額を確定する。決済金額の確定方法は、従来の電子商取引のサイトで採用されている方法でよい。次に、クライアント装置１０は、ユーザの操作を契機に、ログイン用のＷＥＢページの要求に代えて、決済用のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。導入ＷＥＢサーバ５は、決済用のＷＥＢページの要求を受信する。すると、導入ＷＥＢサーバ５は、要求された決済用のＷＥＢページを生成する。次に、導入ＷＥＢサーバ５は、生成した決済用のＷＥＢページを、クライアント装置１０に送信する。導入ＷＥＢサーバ５によって生成される決済用のＷＥＢページは、認証サイト情報を含む。認証サイト情報は、戻先ＵＲＬだけではなく、決済金額を含む。クライアント装置１０は、決済用のＷＥＢページを受信する。次に、クライアント装置１０は、受信した決済用のＷＥＢページに含まれる認証サイト情報に基づいて、認証用メールアドレス取得要求をメール認証専用ＷＥＢ装置９４３に送信する。メール認証専用ＷＥＢ装置９４３は、認証用メールアドレス取得要求を受信する。次に、メール認証専用ＷＥＢ装置９４３は、受信した認証要求から戻先ＵＲＬ及び決済金額を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、認証用メールアドレスを生成する。次に、メール認証専用ＷＥＢ装置９４３は、生成した認証用メールアドレス、抽出した戻先ＵＲＬ及び抽出した決済金額を、クライアント装置１０に送信する。クライアント装置１０は、認証用メールアドレス、戻先ＵＲＬ及び決済金額を受信する。次に、クライアント装置１０は、認証用メールアドレス宛てに、電子メールを送信する。これによって、クライアント装置１０は、電子メールをメール認証専用ＷＥＢ装置９４３に送信する。メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から電子メールを受信する。すると、メール認証専用ＷＥＢ装置９４３は、受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、メール認証専用ＷＥＢ装置９４３は、取得した送信先のメールアドレスと、取得した送信元のメールアドレスと、を対応付けて、メールアドレス対応テーブル３４１に記憶する。一方で、クライアント装置１０は、認証用メールアドレス、戻先ＵＲＬ及び決済金額を含む認証要求を、メール認証専用ＷＥＢ装置９４３に送信する。メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から、認証要求を受信する。メール認証専用ＷＥＢ装置９４３は、受信した認証要求から、認証用メールアドレス、戻先ＵＲＬ及び決済金額を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証専用ＷＥＢ装置９４３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出した送信先メールアドレス３４１３に対応するクレジットカード番号を、ユーザ管理テーブル３４２から抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出したクレジットカード番号で、抽出した決済金額を利用可能か否かを判定することによって、与信審査を行う。ここでの与信審査は、従来のクレジットカード利用時の与信審査と同様である。メール認証専用ＷＥＢ装置９４３は、与信審査が良好であると、クレジットカードに決済金額を課金する。メール認証専用ＷＥＢ装置９４３は、与信審査処理及び課金処理を、与信審査処理及び課金処理を専用に行う装置に依頼してもよい。メール認証専用ＷＥＢ装置９４３は、課金処理を完了すると、認証の結果を認証可能と判定する。メール認証専用ＷＥＢ装置９４３は、認証の結果を、クライアント装置１０に送信する。クライアント装置１０は、受信した認証の結果に基づいて、決済終了のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。導入ＷＥＢサーバ５は、クライアント装置１０から、決済終了のＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、ＷＥＢページの要求から、ユーザのメールアドレスを抽出する。次に、導入ＷＥＢサーバ５は、抽出したメールアドレスに対応する決済終了のＷＥＢページを、クライアント装置１０に送信する。なお、決済終了のＷＥＢページは、抽出されたメールアドレスに対応するユーザの固有な情報を含む。
【０１０３】
前述の通り、第３の実施形態の個人認証システムは、クレジットカードの決済に、応用することができる。なお、第４の実施形態では、クレジットカード決済について説明したが、決済手段は、認証を経て決済する手段であればなんであってもよい。例えば、決済手段には、「Ｅｄｙ」（商標）、「ジェイデビット」（商標）又は「ケータイ払いサービス」（商標）等がある。「Ｅｄｙ」（商標）は、店舗やインターネット上で利用可能な電子マネーである。「ジェイデビット」（商標）は、店舗やインターネット上で利用可能な預金口座引き落としの決済サービスである。「ケータイ払いサービス」（商標）は、決済金額が携帯電話料金の請求に合算される、インターネット上で利用可能な後払いの決済サービスである。
【０１０４】
ここで、第４の実施形態の個人認証システムの変形例を説明する。第４の実施形態の個人認証システムに備わるメール認証専用ＷＥＢ装置９４３は、電子メールの送信元に基づいて、クレジットカード番号を特定した。そのため、電子メールの送信元が偽装された場合は、なりすましのユーザによって決済されてしまう。なりすましの決済を防止するために、ユーザは、クレジットカード番号をクライアント装置１０に入力する。クライアント装置１０は、入力されたクレジットカード番号をメール認証専用ＷＥＢ装置９４３に送信する。なお、クライアント装置１０は、入力されたクレジットカード番号を、認証用メールアドレス取得要求又は認証要求に含めて送信してもよい。メール認証専用ＷＥＢ装置９４３は、クレジットカード番号をクライアント装置１０から受信する。すると、メール認証専用ＷＥＢ装置９４３は、受信したクレジットカード番号とユーザ管理テーブル３４２から抽出したクレジットカード番号とを照合する。双方のクレジットカード番号が一致する場合のみ、メール認証専用ＷＥＢ装置９４３は、当該クレジットカードに対して与信審査して、課金する。なお、第９の実施の形態の変形例では、クレジットカード番号をユーザに入力させる代わりに、暗証番号等の他の情報を入力させることによって、なりすましを防止してもよい。
【０１０５】
（第５の実施形態）
以下で第５の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１０６】
図１３は、第５の実施形態の個人認証システムの概略の構成図である。図１３に示す個人認証システムは、複数のＡＴＭ（ＡＵＴＯＭＡＴＩＣ ＴＥＬＬＥＲ ＭＡＣＨＩＮＥ）２０１０、複数の携帯電話２０６０及びＡＴＭメール認証装置９２３を備える。ＡＴＭ２０１０は、認証を受け、現金を出し入れしようとするユーザによって操作されるＡＵＴＯＭＡＴＩＣ ＴＥＬＬＥＲ ＭＡＣＨＩＮＥである。ＡＴＭ２０１０はネットワーク９に接続されている。ＡＴＭメール認証装置９２３は、ネットワーク９を介してＡＴＭ２０１０に接続されている。第５の実施の形態では、ネットワーク９はインターナルネットワークである。また、ネットワーク９は、複数の金融機関に設置されたＡＴＭメール認証装置を集約する中継装置を含んでもよい。また、ＡＴＭメール認証装置９２３は、インターネット１を介して携帯電話２０６０に接続されている。ＡＴＭメール認証装置９２３の構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図３）と同一なので、説明を省略する。なお、説明を明瞭にするために、第５の実施形態の個人認証システムでは、１台のＡＴＭ２０１０に対する認証処理を説明する。実際には、ＡＴＭメール認証装置９２３は、ネットワーク９を介して、複数のＡＴＭ２０１０に対する認証を行う。なお、図１３では、ＡＴＭ２０１０は、３台を図示したが、個人認証システムに何台備わっていても良い。また、携帯電話２０６０は、３台を図示したが、個人認証システムに何台備わっていてもよい。なお、個人認証システムは、携帯電話２０６０の代わりに、電子メール送信機能を備える端末を備えてもよい。
【０１０７】
図１４は、第５の実施形態の個人認証システムに備わるＡＴＭ２０１０の構成のブロック図である。ＡＴＭ２０１０は、物理的には、送受信部１１、中央処理装置１２、主記憶装置１３、補助記憶装置１４、入力装置（図示省略）、表示装置（図示省略）及び現金取扱部１５等を備えたＡＴＭ（ＡＵＴＯＭＡＴＩＣ ＴＥＬＬＥＲ ＭＡＣＨＩＮＥ）である。送受信部１１は、ネットワーク９に接続され、外部の装置（ＡＴＭメール認証装置９２３）とデータを送受信するインタフェースである。中央処理装置１２は、例えば、ＣＰＵである。中央処理装置１２は、主記憶装置１３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置１３は、例えば、メモリである。主記憶装置１３は、中央処理装置１２によって実行されるプログラム及び中央処理装置１２によって必要とされる情報等が記憶される。補助記憶装置１４は、例えば、ハードディスクである。補助記憶装置１４は、各種情報を記憶する。入力装置は、例えば、キーボード又はタッチパネルである。入力装置には、ユーザから各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置１２から表示を指示された情報が表示される。現金取扱部１５は、紙幣及び貨幣を物理的に管理する。更に、現金取扱部１５は、紙幣及び貨幣を入出金する。現金取扱部１５は、一般的な金融機関のＡＴＭに備えられているものでよい。
【０１０８】
ＡＴＭ２０１０の機能は、現金取扱部１５を除いて、第１の実施形態の個人認証システムに備わるクライアント装置１０と同一なので、説明を省略する。
【０１０９】
携帯電話２０６０は、インターネット接続機能を搭載する。よって、携帯電話２０６０は、ネットワーク９を介して、ＡＴＭメール認証装置９２３へ電子メールを送信する。
【０１１０】
第５の実施形態のＡＴＭメール認証装置９２３の機能構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図４）と同一なので、説明を省略する。
【０１１１】
なお、ＡＴＭメール認証装置９２３の補助記憶装置に記憶されているユーザ管理テーブル３４２には、ユーザＩＤに対応してユーザの固有な情報が格納される。本実施の形態におけるユーザの固有な情報は、金融機関の口座情報である。金融機関の口座情報は、口座番号、預金残高、借入金残高及び借入可能残高等を含む。ただし、ユーザの固有な情報は、必ずしもユーザ管理テーブル３４２によって管理されている必要はなく、ユーザＩＤに対応して管理されていればいかなる方法であってもよい。ユーザの固有な情報の管理方法は、サービスの種類及び利用者の規模に応じて、本発明の実施者に委ねられる。ユーザＩＤに対応するユーザの固有な情報の一部は、ＡＴＭメール認証装置９２３からＡＴＭ２０１０へ送信される認証の結果に含まれる。
【０１１２】
次に、第５の実施形態の個人認証方法について説明する。第５の実施形態の個人認証方法の処理は、第１の実施形態の個人認証方法（図７）と同一なので、説明を省略する。但し、ここでは、第５の実施形態の個人認証方法の特徴的なステップを説明する。
【０１１３】
第５の実施形態におけるＳＴ１１８について説明する。電子メールを送信する装置は、ＡＴＭ２０１０ではなく、第二のクライアント装置である携帯電話２０６０である。携帯電話２０６０は、ユーザの操作を契機に、電子メールを、ＡＴＭメール認証装置９２３に送信する。
【０１１４】
第５の実施形態におけるＳＴ１２４について説明する。ＡＴＭメール認証装置９２３の認証結果送信モジュール３３９は、認証の結果を、ネットワーク９を介して、ＡＴＭ２０１０に送信する。認証の結果は、ユーザＩＤに対応する口座番号、預金残高、借入金残高又は借入可能残高等のユーザの固有な情報を含む。
【０１１５】
ＳＴ１２４に引き続き、ＡＴＭ２０１０は、ＡＴＭメール認証装置９２３から受信した認証の結果及びユーザの固有な情報を表示装置に表示する。ＡＴＭ２０１０のユーザは、表示された情報に基づいて、後続の操作を実行する。後続の操作とは、例えば、預金の引き出し、借入金の返済又は借入金の借り入れである。
【０１１６】
ところで、一般的なＡＴＭは、預金の引き出し、借入金の返済及び借入金の借り入れ等の種々の操作を受け付けることができる。そこで、ＳＴ１１１に先立って、ＡＴＭ２０１０は、ユーザから操作の種類を受け付ける。ＡＴＭ２０１０は、ＡＴＭメール認証装置９２３へ送信する認証用メールアドレス取得要求に、ユーザが求める操作の種類を含める。ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０から受信する認証用メールアドレス取得要求から、ＡＴＭ２０１０のユーザが求める操作の種類を抽出する。そして、ＡＴＭメール認証装置９２３は、抽出した操作の種類に基づいて、認証の結果に含めるユーザの固有な情報を決定する。
【０１１７】
また、次のような手順であってもよい。一般的なＡＴＭは、預金の引き出し、借入金の返済及び借入金の借り入れ等の種々の操作を受け付けることができる。ここでは、ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザから受け付け可能な操作をユーザＩＤに対応して予め記憶しておく。この場合、ＡＴＭ２０１０は、認証要求の送信の前に、ユーザから操作の種類を受け付けない。まず、ＡＴＭ２０１０は、第５の実施形態の個人認証方法によって、認証を受ける。ＡＴＭメール認証装置９２３は、認証したユーザＩＤに対応する受け付け可能な操作を、認証の結果に含めて、ＡＴＭ２０１０に送信する。ＡＴＭ２０１０は、ＡＴＭメール認証装置９２３から受信した認証の結果及び受け付け可能な操作を表示装置に表示する。ＡＴＭ２０１０のユーザは、ＡＴＭ２０１０の表示装置に表示された操作の種類の中から、操作を選択する。すると、ＡＴＭ２０１０は、選択された種類の操作を実行する。
【０１１８】
なお、第５の実施形態の個人認証方法は、従来のキャッシュカード及び暗証番号による個人認証方法と組み合わせてもよい。これによって、キャッシュカード及び暗証番号が盗まれても、ユーザのメールアドレスによって電子メールが送信されない限り、なりすましのユーザによって預金が引き出されることがない。また、第５の実施形態の個人認証方法は、キャッシュカード又は暗証番号の一方による個人認証と組み合わせてもよい。
【０１１９】
ここで、本発明の第５の実施形態の変形例を説明する。第５の実施形態では、ＡＴＭメール認証装置９２３は、認証用メールアドレスを生成し、ＡＴＭ２０１０に送信する。しかし変形例では、ＡＴＭ２０１０が、自身のＡＴＭ＿ＩＤを含む認証用メールアドレスを生成してもよい。ＡＴＭ＿ＩＤは、ＡＴＭ２０１０の一意な識別子である。ＡＴＭメール認証装置９２３は、携帯電話２０６０から電子メールを受信すると、受信した電子メールの送信の送信先アドレスからＡＴＭ＿ＩＤを抽出する。そして、ＡＴＭメール認証装置９２３は、抽出したＡＴＭ＿ＩＤによって識別されるＡＴＭ２０１０に認証の結果を送信する。つまり、ＡＴＭメール認証装置９２３は、認証要求をＡＴＭ２０１０から受信しなくても、認証の結果を送信できる。
【０１２０】
ここで、本発明の第５の実施形態の応用例を説明する。第５の実施形態の応用例の個人認証システムに備わるＡＴＭメール認証装置９２３は、公共料金の料金を計算する装置を兼ねる。この場合、ＡＴＭメール認証装置９２３は、公共料金を計算し、請求書を発行し、支払状況を管理する。例えば、公共料金は、電話料金、携帯電話料金、電気料金、ガス料金又は水道料金等である。ＡＴＭメール認証装置９２３は、携帯電話２０６０のメールアドレスと、公共料金のサービスを受けるユーザの識別子とを、対応付けて記憶する。ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザに貸付金を貸し付ける場合、貸付金を公共料金の請求に合算して請求する。また、ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザから、公共料金の支払いの要求を受け付ける。ＡＴＭメール認証装置９２３は、前述したようにＡＴＭ２０１０のユーザを認証すると、携帯電話２０６０のユーザの未払分の公共料金の支払いをＡＴＭ２０１０から受け付ける。また、ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザから、貸付金の貸し出しの要求を受け付ける。ＡＴＭメール認証装置９２３は、前述したようにＡＴＭ２０１０のユーザを認証すると、貸付金をＡＴＭ２０１０から貸し出す。なお、ＡＴＭメール認証装置９２３は、貸付金を公共料金の請求に合算して請求する。
【０１２１】
また、本発明の第５の実施の形態では、重複しない認証用メールアドレスを、すべてのＡＴＭ２０１０のそれぞれに予め割り当てておいてもよい。この場合、ＡＴＭ２０１０と認証用メールアドレスとの対応は、不変である。そして、ＡＴＭメール認証装置９２３は、送信先のメールアドレスに基づいて、ユーザの認証要求の送信元のＡＴＭ２０１０を特定できる。
【０１２２】
（第６の実施形態）
以下で第６の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システム及び第５の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１２３】
第６の実施形態の個人認証システムとして、第１の実施形態の個人認証システムを、店舗でのクレジットカード決済に用いる具体的な実施形態について説明する。従来、店舗のクレジットカード決済では、なりすましの利用を防止するために、店舗の販売員が、利用伝票の署名とクレジットカード裏面の署名とを目視で照合する。しかし、目視の照合は、なりすまし防止策としては、不十分である。第６の実施形態の個人認証システムでは、署名の照合の代わりに、電子メールアドレスを用いる実施例を説明する。
【０１２４】
図１５は、第６の実施形態の個人認証システムの概略の構成図である。図１５に示す個人認証システムは、複数のリーダ装置２１１０、複数の携帯電話６０及びメール認証装置３を備える。リーダ装置２１１０は、ネットワーク９に接続されている。メール認証装置３は、インターネット１を介して携帯電話６０に接続されている。リーダ装置２１１０は、クレジットカード情報を読み取るための装置である。リーダ装置２１１０については、図１６で詳細を説明する。店舗では、通常は、店舗の販売員がリーダ装置２１１０を操作する。しかし、第６の実施形態の個人認証システムにおいて認証を受けるユーザは、クレジットカードの保有者である。そこで、説明を簡単にするために、本実施形態の説明においては、リーダ装置２１１０のユーザは、クレジットカードの保有者とする。メール認証装置３は、ネットワーク９を介してリーダ装置２１１０に接続されている。メール認証装置３のブロック図は、第１の実施形態の個人認証システムが備えるメール認証装置３と同じ図３であり、説明を省略する。なお、説明を明瞭にするために、第６の実施形態の個人認証システムでは、１台のリーダ装置２１１０の認証処理を説明する。実際には、メール認証装置３は、ネットワーク９を介して、複数のリーダ装置２１１０に対する認証を行う。つまり、メール認証装置３は、複数のリーダ装置２１１０から認証要求及び認証要求を受けることができる。また、実際には、メール認証装置３は、インターネット１を介して、複数の携帯電話６０に接続されている。なお、図１５では、リーダ装置２１１０は３台を図示したが、個人認証システムに何台備わっていても良い。また、図１５では、携帯電話は３台を図示したが、個人認証システムに何台備わっていても良い。
【０１２５】
図１６は、第６の実施形態の個人認証システムに備わるリーダ装置２１１０の構成のブロック図である。リーダ装置２１１０は、物理的には、送受信部１１、中央処理装置１２、主記憶装置１３、補助記憶装置１４、入力装置（図示省略）、表示装置（図示省略）及びカード情報読取部１６等を備える。送受信部１１は、ネットワーク９に接続され、外部の装置（メール認証装置３）とデータを送受信するインタフェースである。中央処理装置１２は、例えば、ＣＰＵである。中央処理装置１２は、主記憶装置１３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置１３は、例えば、メモリである。主記憶装置１３は、中央処理装置１２によって実行されるプログラム及び中央処理装置１２によって必要とされる情報等が記憶される。補助記憶装置１４は、例えば、ハードディスクである。補助記憶装置１４は、各種情報を記憶する。入力装置は、例えば、キーボード又はタッチパネルである。入力装置には、ユーザから各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置１２から表示を指示された情報が表示される。カード情報読取部１６とは、クレジットカードに記憶された情報を読み取る装置である。カード情報読取部１６は、一般的なクレジットカードのカードリーダに備えられているもので十分である。なお、リーダ装置２１１０は、必ずしも、補助記憶装置１４を備えている必要はない。
【０１２６】
第６の実施形態の個人認証システムが備えるリーダ装置２１１０の機能は、主に、第１の実施形態の個人認証システムが備えるクライアント装置１０と同様である。第６の実施形態の個人認証システムが備えるリーダ装置２１１０は、第１の実施形態の個人認証システムが備えるクライアント装置１０の機能に加えて、次の機能を持つ。リーダ装置２１１０は、ユーザの操作によって、クレジットカード番号及び決済金額を受け付ける。リーダ装置２１１０は、メール認証装置３に送信する認証要求に、受け付けたクレジットカード番号及び決済金額を含める。
【０１２７】
携帯電話６０は、インターネット接続機能を搭載した、携帯電話である。携帯電話６０は、インターネット１を介して、メール認証装置３へ電子メールを送信する。
【０１２８】
第６の実施形態のメール認証装置３の機能は、主に、第１の実施形態の個人認証システムと同様である。第６の実施形態のメール認証装置３は、第１の実施形態の個人認証システムが備えるメール認証装置３の機能に加えて、次の機能を持つ。第６の実施形態のメール認証装置３は、クレジットカードの与信審査及び課金を処理する。メール認証装置３のユーザ管理テーブル３４２は、クレジットカード番号（図示省略）を含む。ユーザ管理テーブル３４２に含まれるクレジットカード番号は、ユーザが所有するクレジットカードの番号である。つまり、ユーザ管理テーブル３４２には、クレジットカード番号とユーザの電子メールアドレスとが関連付けて予め記憶されている。
【０１２９】
次に、第６の実施形態の個人認証方法の処理の概要を説明する。第６の実施形態の個人認証方法のシーケンス図は、主に、第１の実施形態の個人認証方法のシーケンス図である図７と同様である。但し、電子メールを送信する装置は、リーダ装置２１１０ではなく、第二のクライアント装置である携帯電話６０である。
【０１３０】
第６の実施形態の個人認証方法の処理の概要は、以下の通りである。リーダ装置２１１０は、ユーザから決済金額を受け付ける。また、リーダ装置２１１０のカード情報読取部１６は、ユーザのカード操作によって、クレジットカード番号を読み取る。次に、リーダ装置２１１０は、受け付けた決済金額及び読み取ったクレジットカード番号を含む認証用メールアドレス取得要求を、メール認証装置３に送信する（ＳＴ１１１）。メール認証装置３は、認証要求を受信する（ＳＴ１１２）。次に、メール認証装置３は、受信した認証要求から、決済金額及びクレジットカード番号を抽出する。次に、メール認証装置３は、認証用メールアドレスを生成する（ＳＴ１１４）。次に、メール認証装置３は、生成した認証用メールアドレス、抽出した決済金額及び抽出したクレジットカード番号をリーダ装置２１１０に送信する（ＳＴ１１６）。リーダ装置２１１０は、認証用メールアドレス、決済金額及びクレジットカード番号を受信する（ＳＴ１１７）。次に、リーダ装置２１１０は、表示装置に、受信した認証用メールアドレスを表示する。なお、リーダ装置２１１０は、認証用メールアドレスを表示せずに、認証用メールアドレスが記載された紙を印刷してもよい。つまり、リーダ装置２１１０は、認証用メールアドレスをユーザに通知できれば、いかなる方法であってもよい。また、リーダ装置２１１０は、認証用メールアドレスに対応するＱＲコード等を表示又は印刷してもよい。携帯電話６０は、ユーザの操作を契機に、表示された認証用メールアドレス宛てに電子メールを送信する（ＳＴ１１８）。すると、メール認証装置３は、携帯電話６０から電子メールを受信する（ＳＴ１１９）。次に、メール認証装置３は、受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、メール認証装置３は、取得した送信先のメールアドレスと、取得した送信元のメールアドレスとを対応付けて、メールアドレス対応テーブル３４１に記憶する（ＳＴ１２０）。一方で、リーダ装置２１１０は、認証用メールアドレス、決済金額及びクレジットカード番号を含む認証要求を、メール認証装置３に送信する（ＳＴ１２１）。メール認証装置３は、リーダ装置２１１０から認証要求を受信する（ＳＴ１２２）。メール認証装置３は、受信した認証要求から、認証用メールアドレス、決済金額及びクレジットカード番号を抽出する。次に、メール認証装置３は、メールアドレス対応テーブル３４１から、抽出した認証用メールアドレスに対応する送信先メールアドレス３４１３を抽出する（ＳＴ１２３）。具体的には、メール認証装置３は、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証装置３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証装置３は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。次に、メール認証装置３は、抽出したレコードから、クレジットカード番号を抽出する。次に、メール認証装置３は、メールアドレス対応テーブル３４１から抽出したクレジットカード番号と、認証要求から抽出したクレジットカード番号と、を照合する。抽出された二つのクレジットカード番号が一致しない場合、メール認証装置３は、認証不可と判定する。一方、抽出された二つのクレジットカード番号が一致する場合、メール認証装置３は、抽出した決済金額が利用可能か否かを判定する与信審査を行う。与信審査は、従来のクレジットカード利用時に行われるものと同様である。メール認証装置３は、与信審査が良好であると、クレジットカードに決済金額を課金する。なお、メール認証装置３は、与信審査及び課金処理を専用の装置に依頼してもよい。この場合、メール認証装置３は、与信審査及び課金を行う専用の装置とネットワークを介して接続される。メール認証装置３は、課金処理が完了すると、認証可能と判定する。メール認証装置３は、認証の結果を、リーダ装置２１１０に送信する（ＳＴ１２４）。リーダ装置２１１０は、認証結果を受信する（ＳＴ１２５）。次に、リーダ装置２１１０は、認証結果を、表示装置に表示する。
【０１３１】
上述の通り、第６の実施形態の個人認証システムでは、店舗でのクレジットカード決済において、署名の照合代わりに、電子メールアドレスを用いることができた。なお、第６の実施形態では、クレジットカード決済について、説明したが、決済手段は、認証を経て決済する手段であれば、なんでもよく、クレジットカードに限定されるものではない。例えば、決済手段は、「ジェイデビット」（商標）がある。
【０１３２】
上述した実施例では、リーダ装置２１１０によって送信される認証用メールドレス取得要求が、クレジットカード番号を含む。しかし、次の通りであってもよい。リーダ装置２１１０は、クレジットカード番号を、認証用メールアドレス取得要求でなく、認証要求に含めてもよい。
【０１３３】
次に、本発明の第６の実施形態の変形例を説明する。第６の実施形態の個人認証システムでは、リーダ装置２１１０は、クレジットカードの情報を読み取った。しかし、第６の実施形態の変形例では、リーダ装置２１１０によるクレジットカードの情報の読み取りがなくても、クレジットカード決済が実行できる実施例について説明する。すなわち、ユーザが、物理的にクレジットカードを保有していなくても、店舗でクレジットカード決済ができる。
【０１３４】
第６の実施形態の変形例に備わるリーダ装置２１１０が送信する認証用メールアドレス取得要求は、クレジットカード番号を含まない。
【０１３５】
第６の実施形態の変形例の処理の概要を説明する。リーダ装置２１１０は、ユーザの操作を契機に、認証用メールアドレス取得要求をメール認証装置３に送信する。メール認証装置３は、認証用メールアドレス取得要求を受信する。次に、メール認証装置３は、受信した認証用メールアドレス取得要求から、決済金額を抽出する。次に、メール認証装置３は、認証用メールアドレスを生成する。次に、メール認証装置３は、生成した認証用メールアドレス及び抽出した決済金額を、リーダ装置２１１０に送信する。リーダ装置２１１０は、認証用メールアドレス及び決済金額を受信する。次に、リーダ装置２１１０は、受信した認証用メールアドレスを表示装置に表示する。携帯電話６０は、ユーザの操作を契機に、表示された認証用メールアドレス宛てに電子メールを送信する。メール認証装置３は、携帯電話６０から電子メールを受信する。次に、メール認証装置３は、受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、メール認証装置３は、取得した送信先のメールアドレスと、取得した送信元のメールアドレスとを対応付けて、メールアドレス対応テーブル３４１に記憶する。一方、リーダ装置２１１０は、認証要求をメール認証装置３に送信する。メール認証装置３は、リーダ装置２１１０から、認証用メールアドレス及び決済金額を含む認証要求を受信する。メール認証装置３は、受信した認証要求から、認証用メールアドレス及び決済金額を抽出する。次に、メール認証装置３は、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証装置３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証装置３は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。次に、メール認証装置３は、選択したレコードからクレジットカード番号を抽出する。次に、メール認証装置３は、抽出したクレジットカード番号に対して、与信審査を行う。与信審査は、従来のクレジットカード利用時に行われるものである。与信審査が良好であると、メール認証装置３は、クレジットカードに決済金額を課金する。なお、メール認証装置３は、与信審査及び課金処理を、専用の装置に依頼してもよい。この場合、メール認証装置３は、与信審査及び課金を行う専用の装置にネットワークを介して、接続される。メール認証装置３は、課金処理が完了すると、認証可能と判定する。メール認証装置３は、認証の結果をリーダ装置２１１０に送信する。リーダ装置２１１０は、認証結果を受信する。そして、リーダ装置２１１０は、受信した認証結果を表示装置に表示する。
【０１３６】
前述の通り、第６の実施形態の変形例では、ユーザが、店舗で、物理的にクレジットカードを保有していなくても、クレジットカード決済ができる。
【０１３７】
ここで、本発明の第６の実施形態の変形例の応用例を説明する。第６の実施形態の変形例の応用例の個人認証システムに備わるメール認証装置３は、公共料金を計算する装置を兼ねる。つまり、メール認証装置３は、公共料金を計算し、請求書を発行し、支払状況を管理する。例えば、公共料金は、電話料金、携帯電話料金、電気料金、ガス料金又は水道料金等である。第６の実施形態では、メール認証装置３のユーザ管理テーブル３４２は、携帯電話６０の電子メールアドレスとクレジットカード番号とを関連付けて記憶する。第６の実施形態の変形例の応用例では、メール認証装置３のユーザ管理テーブル３４２は、携帯電話６０の電子メールアドレスと公共料金のサービスを受けるユーザの識別子との対応を記憶する。メール認証装置３は、店舗での決済金額を、クレジットカードに課金する代わりに、公共料金に合算する。リーダ装置２１１０のユーザは、携帯電話６０を保有するだけで、店舗での支払いを済ませることができる。
【０１３８】
（第７の実施形態）
以下では、第７の実施形態の個人認証システムとして、第１の実施形態の個人認証システムで、パーソナルコンピュータ及びＰＤＡを、社内イントラネットに接続する例を説明する。第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いる。
【０１３９】
多くの企業が、社内の情報の機密性を保ちながら、従業員間の情報連絡を促すために、社内イントラネットを設ける。従業員は、出先からの社内情報の閲覧又は更新や、電子メールの送受信を目的として、パーソナルコンピュータ又はＰＤＡといったポータブル端末を、ダイヤルアップやＶＰＮといった通信手段によって、社内イントラネットに接続する。従来、従業員は、ユーザＩＤ及びパスワードを入力して、社内イントラネットに接続する。パーソナルコンピュータ又はＰＤＡのユーザは、第１の実施形態の認証方法を用いて、認証を受け、ポータブル端末を、社内イントラネットに接続する。この場合、クライアント装置１０は、社内のイントラネットに接続されようとするポータブル端末である。また、メール認証装置３は、社内のイントラネットを管理する管理サーバである。従業員は、ユーザＩＤ及びパスワードを入力せずに、社内イントラネットに接続できる。なお、ポータブル端末と異なる第２のクライアント装置を用いてメール認証装置３に電子メールを送信することによって、更に、セキュリティを高めることができる。この場合、ポータブル端末を社内イントラに接続しようとするユーザは、ポータブル端末及びユーザメールアドレスを送信元とする電子メールを送信可能な第２のクライアント装置の両方がなければ、個人認証を受けることができない。これによって、ポータブル端末だけを取得した他人は、当該ポータブル端末のユーザに成り済まして、認証を受けることができない。つまり、ポータブル端末を紛失したとしても、情報流出を防ぐことができる。
【０１４０】
（第８の実施形態）
以下では、第８の実施形態の個人認証システムとして、第１の実施形態の個人認証システムで、シンクライアント（ＴＨＩＮ ＣＬＩＥＮＴ）装置を社内サーバに接続する例を説明する。第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いる。
【０１４１】
シンクライアント装置は、必要最低限の補助記憶装置を備えたパーソナルコンピュータである。企業は、パーソナルコンピュータの盗難又は紛失による、情報流出を防止するために、シンクライアントシステムを導入している。シンクライアント装置の補助記憶装置は、十分な社内データ及びアプリケーションを記憶しない。社内データ及びアプリケーションは、集中サーバによって記憶される。従業員は、シンクライアント装置を操作して集中サーバに接続し、社内データを閲覧、更新する。従来であれば、従業員は、ユーザＩＤ及びパスワードを入力して、集中サーバに接続する。シンクライアント装置のユーザは、第１の実施形態の認証方法を用いて、認証を受け、シンクライアント装置を、社内イントラネットに接続する。この場合、クライアント装置１０は、集中サーバに接続されようとするシンクライアント装置である。また、メール認証装置３は、シンクライアント装置とサーバの接続を管理する管理サーバである。管理サーバは、集中サーバに含まれていてもよい。従業員は、ユーザＩＤ及びパスワードを入力せずに、シンクライアント装置を、集中サーバに接続できる。
【０１４２】
（第９の実施形態）
以下では、第９の実施形態の個人認証システムとして、第１の実施形態の個人認証システムで、パーソナルコンピュータ及びＰＤＡを公衆無線ＬＡＮに接続する例を説明する。第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いる。
【０１４３】
出先で、インターネットに接続する公衆無線ＬＡＮが、普及している。従来、公衆無線ＬＡＮのユーザは、ユーザＩＤ及びパスワードを入力して、パーソナルコンピュータ及びＰＤＡといったポータブル端末を、公衆無線ＬＡＮのアクセスポイントに接続する。公衆無線ＬＡＮのユーザは、第１の実施形態の認証用法を用いて、認証を受け、ポータブル端末を、アクセスポイントに接続する。この場合、クライアント装置１０は、アクセスポイントに接続されようとするポータブル端末である。また、メール認証装置３は、ポータブル端末とアクセスポイントとの接続を管理する管理サーバである。公衆無線ＬＡＮのユーザは、ユーザＩＤ及びパスワードを入力せずに、アクセスポイントに接続できる。
【０１４４】
（第１０の実施形態）
以下で第１０の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１４５】
第１の実施形態の個人認証システムでは、メール認証装置３が、認証用メールアドレスを生成する。しかし、第１０の実施形態の個人認証システムでは、クライアント装置１０が、認証要求ＩＤを生成する。第１０の実施形態の個人認証システムは、第１〜第９の個人認証システムのいずれにも適用できる。ここでは、第１の実施形態の認証システムに適用した場合を説明する。
【０１４６】
第１０の実施形態のクライアント装置１０について説明する。クライアント装置１０は、ユーザの操作によって、認証用メールアドレス生成情報取得要求をメール認証装置３に送信する。すると、クライアント装置１０は、認証用メールアドレス生成情報を、メール認証装置３から受信する。認証用メールアドレス生成情報は、クライアント装置１０が認証用メールアドレスを生成するための情報である。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔで記述されたクライアントサイドプログラムである。なお、認証用メールアドレス生成情報は、メール認証装置３が電子メールを受信可能なドメインを含む。クライアント装置１０は、受信した認証用メールアドレス生成情報に基づいて、認証用メールアドレスを生成する。例えば、クライアント装置１０は、時刻及び乱数のうち少なくとも一方を用いて、認証用メールアドレスを生成する。なお、生成される認証用メールアドレスは、一意でなければならない。そこで、クライアント装置１０によって生成される認証用メールアドレスの文字列の数は、メール認証装置３が所定の時間内に認証するユーザの数に応じて、十分な長さとする。
【０１４７】
クライアント装置１０は、ユーザの操作を契機に、電子メールを、認証用メールアドレスに送信する。
【０１４８】
クライアント装置１０は、認証用メールアドレスを含む認証要求を、メール認証装置３に送信する。なお、認証要求は、認証用メールアドレスの全部を含んでいてもよいし、認証用メールアドレスの一部を含んでいてもよい。なお、クライアント装置１０は、ユーザの操作を契機に認証要求を送信してもよいし、一定時間ごとに認証要求を送信してもよい。
【０１４９】
クライアント装置１０は、認証結果をメール認証装置３から受信する。
【０１５０】
次に、第１０の実施形態のメール認証装置３について説明する。図１７は、第１０の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１０の実施形態の認証プログラム３００が記憶されている。第１０の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証用メールアドレス生成情報取得要求受信モジュール３３２５、認証要求受信モジュール３３２２、認証用メールアドレス生成情報送信モジュール３３５３、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【０１５１】
認証要求受信モジュール３３２２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９は、第１１の実施形態のメール認証装置３に備わるものと同一なので、説明を省略する。
【０１５２】
メインモジュール３３１は、認証用メールアドレス生成情報取得要求受信モジュール３３２５、認証要求受信モジュール３３２２、認証用メールアドレス生成情報送信モジュール３３５３、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【０１５３】
認証用メールアドレス生成情報取得要求受信モジュール３３２５は、クライアント装置１０から認証用メールアドレス生成情報取得要求を受信する。認証用メールアドレス生成情報取得要求受信モジュール３３２５は、認証用メールアドレス生成情報取得要求を受信すると、認証用メールアドレス生成情報送信モジュール３３５３に、認証用メールアドレス生成情報の送信を依頼する。
【０１５４】
認証用メールアドレス生成情報送信モジュール３３５３は、認証用メールアドレス生成情報を、クライアント装置１０に送信する。
【０１５５】
次に、第１０の実施形態の個人認証方法の処理について図を用いて説明する。図１８は、第１０の実施形態の個人認証方法の処理のシーケンス図である。
【０１５６】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤ取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ２１１）。
【０１５７】
すると、認証用メールアドレス生成情報取得要求受信モジュール３３２５は、クライアント装置１０から認証用メールアドレス生成情報取得要求を受信する（ＳＴ２１２）。すると、認証用メールアドレス生成情報取得要求受信モジュール３３２５は、認証用メールアドレス生成情報送信モジュール３３５３に、認証用メールアドレス生成情報の送信を依頼する。
【０１５８】
認証用メールアドレス生成情報送信モジュール３３５３は、依頼を受けると、認証用メールアドレス生成情報を、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２１４）。
【０１５９】
クライアント装置１０は、メール認証装置３から認証用メールアドレス生成情報を受信する（ＳＴ２１６）。
【０１６０】
次に、クライアント装置１０は、受信した認証用メールアドレス生成情報取得に基づいて、認証用メールアドレスを生成する（ＳＴ２１７）。
【０１６１】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、生成した認証用メールアドレスへ電子メールを送信する（ＳＴ２１８）。
【０１６２】
以降のステップは、第１の実施形態の個人認証システムと同様のため説明を省略する。
【０１６３】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【０１６４】
（第１１の実施の形態）
以下で第１１の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１６５】
第１１の実施形態の個人認証システムは、認証用メールアドレスの代わりに、認証要求ＩＤ又はクライアントＩＤを用いる。なお、認証要求ＩＤは、認証要求の一意な識別子である。また、クライアントＩＤは、クライアント装置１０の一意な識別子である。なお、第１１の実施形態の個人認証システムは、第１〜第１０の個人認証システムのいずれにも適用できる。ここでは、第１の実施形態の認証システムに適用した場合を説明する。
【０１６６】
図１９は、第１１の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１１の実施形態の認証プログラム３００が記憶されている。第１１の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証要求ＩＤ取得要求受信モジュール３３２３、認証要求受信モジュール３３２２、認証要求ＩＤ生成モジュール３３３、認証要求ＩＤ送信モジュール３３５１、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【０１６７】
メインモジュール３３１は、認証要求ＩＤ取得要求受信モジュール３３２３、認証要求受信モジュール３３２２、認証要求ＩＤ生成モジュール３３３、認証要求ＩＤ送信モジュール３３５１、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【０１６８】
認証要求ＩＤ取得要求受信モジュール３３２３は、クライアント装置１０から認証要求ＩＤ取得要求を受信する。認証要求ＩＤ取得要求受信モジュール３３２３は、認証要求ＩＤ取得要求を受信すると、認証要求ＩＤ生成モジュール３３３に認証要求ＩＤの生成を依頼する。
【０１６９】
認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【０１７０】
認証要求ＩＤ生成モジュール３３３は、認証要求ＩＤ取得要求受信モジュール３３２３から依頼を受けると、認証要求ＩＤを生成する。認証要求ＩＤは、認証要求の一意な識別子である。例えば、認証要求ＩＤ生成モジュール３３３は、乱数、アプリケーションＩＤ及び認証要求ＩＤの生成時刻等に基づいて、認証要求ＩＤを生成する。なお、アプリケーションＩＤは、当該メール認証装置３にインストールされている認証プログラム３００の一意な識別子である。なお、アプリケーションＩＤは、一般的にライセンスキーとして知られているものであり、詳細な説明は省略する。なお、認証要求ＩＤの生成方法は、その目的を達成する限り他の方法を用いてもよい。続いて、認証要求ＩＤ生成モジュール３３３は、生成した認証要求ＩＤを認証要求ＩＤ送信モジュール３３５１に引き渡す。
【０１７１】
仮に、メール認証装置３は、認証要求ＩＤ取得要求を複数のクライアント装置１０から同時に受信すると、受信したそれぞれの認証要求ＩＤ取得要求ごとに異なる認証要求ＩＤを生成する。また、メール認証装置３は、第１の認証要求ＩＤ取得要求を受信した後に、当該第１の認証要求の送信元であるクライアント装置１０から第２の認証要求ＩＤ取得要求を受信してもよい。この場合、メール認証装置３は、第１の認証要求ＩＤ取得要求に対して生成された認証要求ＩＤと異なる認証要求ＩＤを生成する。これによって、メール認証装置３は、同一のクライアント装置１０から送信される複数の認証要求を同時に処理できる。
【０１７２】
認証要求ＩＤ送信モジュール３３５１は、認証要求ＩＤ生成モジュール３３３から引き受けた認証要求ＩＤ及びメール認証装置が受信可能なメールアドレスを、クライアント装置１０に送信する。
【０１７３】
メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する。なお、メール受信モジュール３３６は、クライアント装置１０以外から電子メールを受信してもよい。なお、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。なお、送信元のメールアドレスの偽装は、いかなる方法で判定されてもよい。
【０１７４】
受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び認証要求ＩＤを取得する。例えば、受信メール読取モジュール３３７は、電子メールの本文又は件名から、認証要求ＩＤを取得する。続けて、受信メール読取モジュール３３７は、認証要求ＩＤ対応テーブル３４１１（図２０）に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信先メールアドレスに３４１２に、電子メールから取得した送信先メールアドレスを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１３に、電子メールから取得した送信元メールアドレスを格納する。
【０１７５】
図２０は、第１１の実施形態のメール認証装置３の補助記憶装置３４に記憶されている認証要求ＩＤ対応テーブル３４１１の構成図である。認証要求ＩＤ対応テーブル３４１１は、認証要求ＩＤ３４１１２及び送信元メールアドレス３４１１３を含む。認証要求ＩＤ３４１１２は、当該メール認証装置３が受信した電子メールに含まれる認証要求ＩＤである。送信元メールアドレス３４１１３は、当該メール認証装置３が受信した電子メールの送信元メールアドレスである。なお、本実施の形態では、認証要求ＩＤ３４１１２は、メール認証装置３と接続される多数のクライアント計算機１０の中から、認証を要求するユーザによって操作されるクライアント計算機１０を特定するために使用される。また、送信元メールアドレス３４１１３は、認証を要求するユーザを特定するために使用される。
【０１７６】
認証モジュール３３８は、認証要求ＩＤを含む認証要求をクライアント装置１０から受信する。なお、クライアント装置１０は、認証要求と共に、当該認証要求を識別する認証要求ＩＤをメール認証装置３に通知できればいかなる方法であってもよい。例えば、認証要求を送信するための通信のセッションＩＤが、認証要求ＩＤを含んでいてもよい。セッションＩＤは、ＷＥＢサーバとＷＥＢブラウザとの間の通信を識別する識別子である。セッションＩＤの生成及び管理は、通常のＷＥＢサーバ及び通常のＷＥＢブラウザの機能である。したがって、セッションＩＤの詳細な説明は、省略する。
【０１７７】
続けて、認証モジュール３３８は、受信した認証要求から認証要求ＩＤを取得する。次に、認証モジュール３３８は、取得した認証要求ＩＤと認証要求ＩＤ対応テーブル３４１１の認証要求ＩＤ３４１１２とが一致するレコードを、認証要求ＩＤ対応テーブル３４１１から選択する。これによって、認証モジュール３３８は、別個の通信である認証要求と電子メールとの対応を把握する。つまり、認証モジュール３３８は、メール受信モジュール３３６が受信した電子メールの中から、受信した認証要求に対応する電子メールを特定する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１１３を抽出する。つまり、認証モジュール３３８は、受信した認証要求に対応する電子メールの送信元アドレスを特定する。認証モジュール３３８は、送信元メールアドレス３４１１３を抽出できない場合、認証不可と判定する。
【０１７８】
次に、認証モジュール３３８は、抽出した送信元メールアドレス３４１１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。認証モジュール３３８は、メールアドレスが一致するレコードを選択できない場合は、認証不可と判定する。一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できる場合は、認証可能と判定する。そして、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元の計算機を操作するユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、認証要求の発行元の計算機が、抽出したユーザＩＤ３４２１によって識別されるユーザによって操作されていると判断する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【０１７９】
認証結果送信モジュール３３９は、認証モジュール３３８が判定した認証結果を、クライアント装置１０に送信する。なお、認証モジュール３３８が認証可能と判定した場合、認証結果送信モジュール３３９は、ユーザＩＤ３４２１に対応するユーザの固有な情報を付随した認証結果を送信してもよい。
【０１８０】
次に、第１１の実施形態の個人認証方法の処理について図を用いて説明する。図２１は、第１１の実施形態の個人認証方法の処理のシーケンス図である。
【０１８１】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤ取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ２１１）。
【０１８２】
すると、認証要求ＩＤ取得要求受信モジュール３３２３は、クライアント装置１０から認証要求ＩＤ取得要求を受信する（ＳＴ２１２）。次に、認証要求ＩＤ取得要求受信モジュール３３２３は、認証要求ＩＤ生成モジュール３３３に、認証要求ＩＤの生成を依頼する。
【０１８３】
認証要求ＩＤ生成モジュール３３３は、認証要求ＩＤの生成の依頼を受けると、認証要求ＩＤを生成する（ＳＴ２１４）。次に、認証要求ＩＤ生成モジュール３３３は、生成した認証要求ＩＤを、認証要求ＩＤ送信モジュール３３５１に引き渡す。
【０１８４】
認証要求ＩＤ送信モジュール３３５１は、認証要求ＩＤを、認証要求ＩＤ生成モジュール３３３から引き受ける。次に、認証要求ＩＤ送信モジュール３３５１は、引き受けた認証要求ＩＤ及びメール認証装置３が受信可能なメールアドレスを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２１６）。
【０１８５】
クライアント装置１０は、メール認証装置３から認証要求ＩＤ及びメールアドレスを受信する（ＳＴ２１７）。
【０１８６】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、認証要求ＩＤを含む電子メールを送信する（ＳＴ２１８）。なお、電子メールの送信先メールアドレスは、メール認証装置３から受信したメールアドレスであり、メール認証装置３が受信可能なメールアドレスである。また、電子メールに含まれる認証要求ＩＤは、本文又は件名のいずれに記載されていてもよい。更に、電子メールに含まれる認証要求ＩＤは、暗号化されていてもよい。
【０１８７】
すると、メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する（ＳＴ２１９）。このとき、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。
【０１８８】
続いて、受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び認証要求ＩＤを取得する。次に、受信メール読取モジュール３３７は、認証要求ＩＤ対応テーブル３４１１に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの認証要求ＩＤ３４１１２に、取得した認証要求ＩＤを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１１３に、取得した送信元メールアドレスを格納する（ＳＴ２２０）。
【０１８９】
一方で、クライアント装置１０は、認証要求ＩＤを含む認証要求を、ネットワーク９を介して、メール認証装置３に送信する（ＳＴ２２１）。なお、認証要求に含まれる認証要求ＩＤは、暗号化されていてもよい。
【０１９０】
すると、認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する（ＳＴ２２２）。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【０１９１】
続けて、認証モジュール３３８は、認証の依頼を受けると、認証要求受信モジュール３３２２が受信した認証要求から認証要求ＩＤを取得する。次に、認証モジュール３３８は、取得した認証要求ＩＤと認証要求ＩＤ対応テーブル３４１１の認証要求ＩＤ３４１１２とが一致するレコードを、認証要求ＩＤ対応テーブル３４１１から選択する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１１３を抽出する。なお、認証モジュール３３８は、送信元メールアドレス３４１１３を抽出できない場合、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。一方、認証モジュール３３８は、抽出した送信元メールアドレス３４１１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する（ＳＴ２２３）。認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合は、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。なお、第１の実施形態では、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、認証不可と判定した。しかし、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、新規のユーザとして認証してもよい。この場合、認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合、新たなユーザＩＤを生成する。このとき、認証モジュール３３８は、ユーザ管理テーブル３４２に含まれるすべてのユーザＩＤ３４２１と重複しないように、ユーザＩＤを生成する。次に、認証モジュール３３８は、ユーザ管理テーブル３４２に、新たにレコードを生成する。次に、認証モジュール３３８は、生成したユーザＩＤを、生成した新たなレコードのユーザＩＤ３４２１に格納する。更に、認証モジュール３３８は、抽出した送信元メールアドレス３４１１３を、生成した新たなレコードのメールアドレス３４２２に格納する。これによって、認証モジュール３３８は、生成したユーザＩＤと電子メールから取得した送信元のメールアドレスとを対応付けて、ユーザ管理テーブル３４２に記憶する。そして、認証モジュール３３８は、電子メールから取得した送信先のメールアドレスに対応するユーザを、新規のユーザとして認証を許可する。なお、認証モジュール３３８は、登録されるユーザの固有な情報をクライアント装置１０から受信してもよい。そして、認証モジュール３３８は、受信したユーザの固有な情報を、新たに生成したレコードに格納する。なお、ユーザの固有な情報は、認証要求に含まれてもよいし、単独で送信されてもよい。
【０１９２】
一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できた場合、認証可能と判定する。次に、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元のクライアント計算機１０を操作しているユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、取得した認証要求ＩＤによって識別される認証要求の発行元のクライアント計算機１０を操作しているユーザが、抽出したユーザＩＤ３４２１によって識別されるユーザあると特定する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【０１９３】
認証結果送信モジュール３３９は、認証モジュール３３８から認証結果を引き受ける。次に、認証結果送信モジュール３３９は、引き受けた認証結果を、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２２４）。
【０１９４】
すると、クライアント装置１０は、メール認証装置３から認証結果を受信する（ＳＴ２２５）。
【０１９５】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、ユーザＩＤ及びパスワードが掠め取られる危険性がない。また、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを管理する必要がない。このように、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【０１９６】
（第１２の実施形態）
以下で第１２の実施形態の個人認証システムについて説明するが、第１及び第１１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１９７】
第１１の実施形態の個人認証システムは、メール認証装置３が、認証要求ＩＤを生成する。しかし、第１２の実施形態の個人認証システムでは、クライアント装置１０が、認証要求ＩＤを生成する。第１２の実施形態の個人認証システムは、第１〜第１０の個人認証システムのいずれにも適用できる。ここでは、第１の実施形態の認証システムに適用した場合を説明する。
【０１９８】
第１２の実施形態のクライアント装置１０について説明する。クライアント装置１０は、ユーザの操作によって、認証要求ＩＤ取得要求をメール認証装置３に送信する。すると、クライアント装置１０は、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを、メール認証装置３から受信する。認証要求ＩＤ生成情報は、クライアント装置１０が認証要求ＩＤを生成するための情報である。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔで記述されたクライアントサイドプログラムである。クライアント装置１０は、受信した認証要求ＩＤ生成情報に基づいて、認証要求ＩＤを生成する。例えば、クライアント装置１０は、時刻及び乱数のうち少なくとも一方を用いて、認証要求ＩＤを生成する。なお、生成される認証要求ＩＤは、一意でなければいけない。そこで、クライアント装置１０によって生成される認証要求ＩＤの文字列の数は、メール認証装置３が所定の時間内に認証するユーザの数に応じて、十分な長さとする。
【０１９９】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤを本文又は件名に含む電子メールを、送信する。この電子メールの送信先メールアドレスは、メール認証装置３から受信したメールアドレスであり、メール認証装置３が受信可能なメールアドレスである。
【０２００】
クライアント装置１０は、生成した認証要求ＩＤを含む認証要求を、メール認証装置３に送信する。
【０２０１】
次に、第１２の実施形態のメール認証装置３について説明する。図２２は、第１２の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１２の実施形態の認証プログラム３００が記憶されている。第１２の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証要求ＩＤ取得要求受信モジュール３３２４、認証要求受信モジュール３３２２、認証要求ＩＤ送信モジュール３３５２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【０２０２】
認証要求受信モジュール３３２２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９は、第１１の実施形態のメール認証装置３に備わるものと同一なので、説明を省略する。
【０２０３】
メインモジュール３３１は、認証要求ＩＤ取得要求受信モジュール３３２４、認証要求受信モジュール３３２２、認証要求ＩＤ送信モジュール３３５２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【０２０４】
認証要求ＩＤ取得要求受信モジュール３３２４は、クライアント装置１０から認証要求ＩＤ取得要求を受信する。認証要求ＩＤ取得要求受信モジュール３３２４は、認証要求ＩＤ取得要求を受信すると、認証要求ＩＤ送信モジュール３３５２に、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスの送信を依頼する。
【０２０５】
認証要求ＩＤ送信モジュール３３５２は、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを、クライアント装置１０に送信する。
【０２０６】
次に、第１２の実施形態の個人認証方法の処理について図を用いて説明する。図２３は、第１２の実施形態の個人認証方法の処理のシーケンス図である。
【０２０７】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤ取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ２１１）。
【０２０８】
すると、認証要求ＩＤ取得要求受信モジュール３３２４は、クライアント装置１０から認証要求ＩＤ取得要求を受信する（ＳＴ２１２）。すると、認証要求ＩＤ取得要求受信モジュール３３２４は、認証要求ＩＤ送信モジュール３３５２に、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスの送信を依頼する。
【０２０９】
認証要求ＩＤ送信モジュール３３５２は、依頼を受けると、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２１４）。
【０２１０】
クライアント装置１０は、メール認証装置３から認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを受信する（ＳＴ２１６）。
【０２１１】
次に、クライアント装置１０は、受信した認証要求ＩＤ生成情報に基づいて、認証要求ＩＤを生成する（ＳＴ２１７）。
【０２１２】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、生成した認証要求ＩＤを含む電子メールを送信する（ＳＴ２１８）。この電子メールの送信先メールアドレスは、メール認証装置３から受信したメールアドレスであり、メール認証装置３が受信可能なメールアドレスである。また、電子メールに含まれる認証要求ＩＤは、本文又は件名のいずれに記載されていてもよい。更に、電子メールに含まれる認証要求ＩＤは、暗号化されていてもよい。
【０２１３】
以降のステップは、第１１の実施形態の個人認証システムと同様のため説明を省略する。
【０２１４】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【図面の簡単な説明】
【０２１５】
【図１】第１の実施形態の個人認証システムの概略構成を示す図である。
【図２】クライアント装置１０の構成のブロック図である。
【図３】メール認証装置３の構成のブロック図である。
【図４】メール認証装置３の機能ブロック図である。
【図５】メール認証装置３の補助記憶装置３４に記憶されているメールアドレス対応テーブル３４１の構成図である。
【図６】メール認証装置３の補助記憶装置３４に記憶されているユーザ管理テーブル３４２の構成図である。
【図７】第１の実施形態の個人認証方法の処理のシーケンス図である。
【図８】第２の実施形態の個人認証システムの概略の構成図である。
【図９】メール認証ＷＥＢ装置９０３の機能ブロック図である。
【図１０】第２の実施形態の個人認証方法の処理のシーケンス図である。
【図１１】第３の実施形態の個人認証システムの概略の構成図である。
【図１２】第３の実施形態の個人認証方法の処理のシーケンス図である。
【図１３】第５の実施形態の個人認証システムの概略の構成図である。
【図１４】ＡＴＭ２０１０の構成のブロック図である。
【図１５】第６の実施形態の個人認証システムの概略の構成図である。
【図１６】リーダ装置２１１０の構成のブロック図である。
【図１７】第１０の実施形態のメール認証装置３の機能ブロック図である。
【図１８】第１０の実施形態の個人認証方法の処理のシーケンス図である。
【図１９】第１１の実施形態のメール認証装置３の機能ブロック図である。
【図２０】第１１の実施形態のメール認証装置３の補助記憶装置３４に記憶されている認証要求ＩＤ対応テーブル３４１１の構成図である。
【図２１】第１１の実施形態の個人認証方法の処理のシーケンス図である。
【図２２】第１２の実施形態のメール認証装置３の機能ブロック図である。
【図２３】第１２の実施形態の個人認証方法の処理のシーケンス図である。
【符号の説明】
【０２１６】
１ インターネット
３ メール認証装置
５ 導入ＷＥＢサーバ
９ ネットワーク
１０ クライアント装置
１１ 送受信部
１２ 中央処理装置
１３ 主記憶装置
１４ 補助記憶装置
１５ 現金取扱部
１６ カード情報読取部
２０１０ ＡＴＭ
２０６０ 携帯電話
２１１０ リーダ装置
２０３４１ 認証用メールアドレス対応テーブル
２０３４１１ クライアントＩＤ
３１ 送受信部
３２ 中央処理装置
３３ 主記憶装置
３４ 補助記憶装置
３００ 認証プログラム
３３１ メインモジュール
３３２１ 認証要求受信モジュール
３３２２ 認証要求受信モジュール
３３２３ 認証要求ＩＤ取得要求受信モジュール
３３２４ 認証要求ＩＤ取得要求受信モジュール
３３２５ 認証用メールアドレス生成情報取得要求受信モジュール
３３３ 認証要求ＩＤ生成モジュール
３３４ 認証用メールアドレス生成モジュール
３３５ 認証用メールアドレス送信モジュール
３３５１ 認証要求ＩＤ送信モジュール
３３５２ 認証要求ＩＤ送信モジュール
３３５３ 認証用メールアドレス生成情報送信モジュール
３３６ メール受信モジュール
３３７ 受信メール読取モジュール
３３８ 認証モジュール
３３９ 認証結果送信モジュール
３４１ 認証用メールアドレス対応テーブル
３４１１ 認証要求ＩＤ
３４１２ 認証用メールアドレス
３４１３ ユーザメールアドレス
３４２ ユーザ管理テーブル
３４２１ ユーザＩＤ
３４２２ メールアドレス
６０ 携帯電話
９０３ メール認証ＷＥＢ装置
９２３ ＡＴＭメール認証装置
９４３ メール認証専用ＷＥＢ装置
９０１０ クライアント装置
９０３００ 認証プログラム
９０３３５ 認証用メールアドレス送信モジュール
９０３３９ 認証結果送信モジュール
【技術分野】
【０００１】
本発明は認証システム、認証計算機及びプログラムに関するものである。
【背景技術】
【０００２】
従来、ユーザを特定してサービスを提供する場合の個人認証として、ユーザＩＤ及びパスワードの組み合わせが知られている。例えば、インターネットを経由してＷＥＢサイトにログインする者は、操作するパーソナルコンピュータに表示されたＷＥＢ画面に応じて、ユーザＩＤ及びパスワードを入力し、ＷＥＢサーバに認証要求を送信する。また、金融機関の利用者が金融機関のＡＴＭで預け金を引き出す場合は、ＡＴＭにキャッシュカードを挿入して、暗証番号を入力し、認証要求を認証サーバに送信する。この場合のユーザＩＤは、キャッシュカードである。
【０００３】
しかし、ＷＥＢサイトのユーザは、ＷＥＢサイトの画面に応じてユーザＩＤ及びパスワードを入力する手間がいる。また、この認証方法は広く普及しており、インターネットバンキングや各種電子商取引のＷＥＢサイトで採用されている。このため、一人が管理すべきユーザＩＤ及びパスワードが増えている。ＷＥＢサイトのユーザは、ユーザＩＤ又はパスワードを忘れた場合には、ユーザＩＤ又はパスワードをサイト運営者に問い合わせる必要があり、ＷＥＢサイトの利便性を享受できない。また、本来のユーザではない者が、ユーザＩＤ及びパスワードを掠め取り、取引を行うなりすましが社会問題化している。ユーザＩＤ及びパスワードを掠め取る手段として、フィッシングやスパイウェアが知られている。フィッシングとは、正規のＷＥＢサイトにそっくりな擬似サイトを設けて、本来のユーザにユーザＩＤ及びパスワードを入力させ、ユーザＩＤ及びパスワードを掠め取る行為である。また、スパイウェアとは、パーソナルコンピュータのユーザが知らないうちにインストールされるソフトウェアで、ユーザが入力する各種ユーザＩＤ及びパスワードを読み取り、インターネット経由で盗聴者のサーバまで通知するソフトウェアのことである。インターネットバンキングや電子商取引でなりすましによる取引が成立した場合、本来のユーザはもとより、ＷＥＢサイトの運営者にもサイトの信頼性失墜や補償問題で甚大な被害が発生する。
【０００４】
金融機関の利用者が金融機関のＡＴＭで預け金を引き出す場合は、ＡＴＭにキャッシュカードを挿入して、暗証番号を入力する手間がいる。また、盗撮機によって暗証番号が盗撮され、キャッシュカードが盗まれた場合、なりすましのユーザによって預金が引き出されてしまう。預金者はもとより、銀行は、信頼性の失墜や補償問題で大きな被害を受ける。
【０００５】
特許文献１では、ＷＥＢサイトのユーザが認証を受ける際に、ＷＥＢサイトにユーザＩＤ及びパスワードを入力し、特定の電話番号にダイヤルすることで、ユーザを認証する個人認証方法が公開されている。
【０００６】
特許文献２では、ＷＥＢサイトのユーザが認証を受ける際に、電話番号をユーザＩＤとして、ＷＥＢサイトに入力し、特定の電話番号にダイヤルすることで、ユーザを認証する個人認証方法が公開されている。
【特許文献１】特許公開２００２−２２９９５１
【特許文献２】特許公開２００４−２１３４４０
【発明の開示】
【発明が解決しようとする課題】
【０００７】
特許文献１の技術によれば、発信者電話番号を利用するために、ユーザＩＤ及びパスワードを掠め取られた場合でも、なりすましを防止できる。また、特許文献２の技術によれば、発信者電話番号を利用するために、なりすましの電話番号をＷＥＢサイトに入力された場合でも、なりすましを防止することができる。しかし、特許文献１及び特許文献２の技術では、発信者番号通知を伴うダイヤルをユーザが発信できない場合には、認証できない。例えば、携帯電話の電波が届かない場合等には、認証できない。
【０００８】
また、特許文献１及び特許文献２の技術では、発信者電話番号通知を伴うダイヤルをしたユーザと当該ユーザが操作する計算機との対応を正確に把握できない。そのため、特許文献１及び特許文献２の技術では、安全性及び利便性の高い認証を提供することができない。例えば、特許文献１及び特許文献２の技術では、本来のユーザでない者が、正当なユーザのユーザＩＤ等を何度も入力することによって、当該正当なユーザになりすませてしまう可能性がある。具体的には、正当なユーザが、特定の電話番号にダイヤルすることによって認証を行った後に、当該特定の電話番号に誤ってリダイヤルしてしまうと、本来のユーザでない者が正当なユーザとして認証されてしまう。
【０００９】
本発明は、前述した問題点に鑑みてなされたものであって、安全性及び利便性の高い個人認証システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
複数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びインタフェースを備える認証計算機であって、前記プロセッサは、ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、前記クライアント計算機から認証要求を受信すると、当該認証計算機が受信可能なメールアドレスのうち、以前に受信した認証要求のいずれにも割り当てられていないメールアドレスを、当該受信した認証要求に割り当て、前記受信した認証要求と当該認証要求に割り当てられたメールアドレスとの対応を、認証用メールアドレス対応情報に記憶し、電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを特定し、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、前記認証用メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する認証要求を特定し、前記特定された認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする。
【発明の効果】
【００１１】
本発明の代表的な実施形態によれば、個人認証システムの安全性及び利便性を高めることができる。
【発明を実施するための最良の形態】
【００１２】
本発明の実施形態を図面を参照して説明する。なお、第１の実施形態として、本発明の汎用的な実施形態を説明する。次に、第２の実施形態として、第１の実施形態を、ＷＥＢサイトに用いた具体的な実施形態を説明する。次に、第３の実施形態として、第２の実施形態を、既存のＷＥＢサーバへ容易に導入するための具体的な実施形態を説明する。次に、第４の実施形態として、第３の実施形態を、インターネットのクレジットカード決済に用いる具体的な実施形態を説明する。次に、第５の実施形態として、第１の実施形態を、金融機関のＡＴＭに用いる具体的な実施形態について説明する。次に、第６の実施形態として、第１の実施形態を、店舗でのクレジットカード決済に用いる具体的な実施形態を説明する。次に、第７の実施形態として、第１の実施形態を、社内イントラネットの接続に用いる具体的な実施形態を説明する。次に、第８の実施形態として、第１の実施形態を、シンクライアントの集中サーバへの接続に用いる具体的な実施形態を説明する。次に、第９の実施形態として、第１の実施形態を、公衆無線ＬＡＮの接続に用いる具体的な実施形態を説明する。次に、第１０の実施形態として、認証要求ＩＤの代わりに、クライアント装置の識別子であるクライアントＩＤを用いる汎用的な実施形態を説明する。
【００１３】
（第１の実施形態）
図１は、第１の実施形態の個人認証システムの概略の構成図である。図１に示す個人認証システムは、複数のクライアント装置１０及びメール認証装置３を備える。クライアント装置１０は、認証を受けようとするユーザによって操作される計算機である。また、クライアント装置１０は、ネットワーク９に接続されている。クライアント装置１０については、図２で詳細を説明する。なお、ネットワーク９は、専用線網、公衆交換電話回線網又はＬＡＮ等のようなデータ通信網である。また、ネットワーク９は、インターナルネットワークであってもよいし、インターネットであってもよい。メール認証装置３は、ネットワーク９を介してクライアント装置１０に接続されている。具体的には、メール認証装置３は、インターネット又はインターナルネットワークを介してクライアント装置１０に接続される。なお、メール認証装置３は、インターネット用のインタフェース及びインターナルネットワーク用のインタフェースを備えてもよい。この場合、メール認証装置３は、インターネットを介していくつかのクライアント装置１０と接続し、更にインターナルネットワークを介して他のいくつかのクライアント装置１０と接続する。メール認証装置３については、図３で詳細を説明する。なお、説明を明瞭にするために、第１の実施形態の個人認証システムでは、１台のクライアント装置１０に対する認証処理を説明する。実際には、メール認証装置３は、ネットワーク９を介して、複数のクライアント装置１０に対する認証を行う。つまり、メール認証装置３は、複数のクライアント装置１０から認証要求を受けることができる。なお、図１では、クライアント装置１０は５台を図示したが、個人認証システムに何台備わっていても良い。
【００１４】
図２は、第１の実施形態の個人認証システムに備わるクライアント装置１０の構成のブロック図である。クライアント装置１０は、物理的には、送受信部１１、中央処理装置１２、主記憶装置１３、補助記憶装置１４、入力装置（図示省略）及び表示装置（図示省略）等を備えたコンピュータシステムである。送受信部１１は、ネットワーク９に接続され、外部の装置（メール認証装置３）とデータを送受信するインタフェースである。中央処理装置１２は、例えば、ＣＰＵである。中央処理装置１２は、主記憶装置１３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置１３は、例えば、メモリである。主記憶装置１３は、中央処理装置１２によって実行されるプログラム及び中央処理装置１２によって必要とされる情報等が記憶される。補助記憶装置１４は、例えば、ハードディスクである。補助記憶装置１４は、各種情報を記憶する。入力装置は、例えば、マウス、キーボード又はタッチパネルである。入力装置には、ユーザから各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置１２から表示を指示された情報が表示される。なお、クライアント装置１０は、送受信部１１、中央処理装置１２及び主記憶装置１３を備えれば、いかなる形態であってもよい。例えば、クライアント装置１０は、パーソナルコンピュータ、サーバ、携帯電話又はＡＴＭ等である。
【００１５】
クライアント装置１０は、ユーザの操作によって、認証用メールアドレス取得要求をメール認証装置３に送信する。すると、クライアント装置１０は、メール認証装置３から認証用メールアドレスを受信する。認証用メールアドレスについては後ほど詳細を説明する。
【００１６】
クライアント装置１０は、ユーザの操作を契機として、認証用メールアドレス宛てに電子メールを送信する。
【００１７】
クライアント装置１０は、認証用メールアドレスを含む認証要求を、メール認証装置３に送信する。なお、認証要求は、認証用メールアドレスの全部を含んでいてもよいし、認証用メールアドレスの一部を含んでいてもよい。なお、クライアント装置１０は、ユーザの操作を契機に認証要求を送信してもよいし、一定時間ごとに認証要求を送信してもよい。
【００１８】
クライアント装置１０は、認証結果をメール認証装置３から受信する。
【００１９】
図３は、第１の実施形態の個人認証システムに備わるメール認証装置３の構成のブロック図である。メール認証装置３は、物理的には、送受信部３１、中央処理装置３２、主記憶装置３３、補助記憶装置３４、入力装置（図示省略）、表示装置（図示省略）などを備えたコンピュータシステムである。なお、メール認証装置３には、電子メールを受信するためのＩＰアドレス及びドメイン（ＤＯＭＡＩＮ）が割り当てられている。送受信部３１は、ネットワーク９に接続され、外部の装置（クライアント装置１０）とデータを送受信するインタフェースである。中央処理装置３２は、例えば、ＣＰＵである。中央処理装置３２は、主記憶装置３３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置３３は、例えば、メモリである。主記憶装置３３は、中央処理装置３２によって実行されるプログラム及び中央処理装置３２によって必要とされる情報等が記憶される。補助記憶装置３４は、例えば、ハードディスクである。補助記憶装置３４は、各種情報を記憶する。入力装置は、例えば、マウス、キーボード又はタッチパネルである。入力装置には、管理者から各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置３２から表示を指示された情報が表示される。なお、メール認証装置３は、送受信部３１、中央処理装置３２及び主記憶装置３３を備えれば、いかなる形態であってもよい。例えば、メール認証装置３は、パーソナルコンピュータ又はサーバ等である。
【００２０】
図４は、第１の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１の実施形態の認証プログラム３００が記憶されている。第１の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証用メールアドレス取得要求受信モジュール３３２１、認証要求受信モジュール３３２２、認証用メールアドレス生成モジュール３３４、認証用メールアドレス送信モジュール３３５、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【００２１】
メインモジュール３３１は、認証用メールアドレス取得要求受信モジュール３３２１、認証要求受信モジュール３３２２、認証用メールアドレス生成モジュール３３４、認証用メールアドレス送信モジュール３３５、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【００２２】
認証用メールアドレス取得要求受信モジュール３３２１は、クライアント装置１０から認証用メールアドレス取得要求を受信する。認証用メールアドレス取得要求受信モジュール３３２１は、認証用メールアドレス取得要求を受信すると、認証用メールアドレス生成モジュール３３４に認証用メールアドレスの生成を依頼する。
【００２３】
認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【００２４】
認証用メールアドレス生成モジュール３３４は、認証用メールアドレス取得要求受信モジュール３３２１から依頼を受けると、メール認証装置３によって受信可能なメールアドレスを新たに生成する。そして、認証用メールアドレス生成モジュール３３４は、生成したメールアドレスを認証用メールアドレスとして、認証用メールアドレス送信モジュール３３５に引き渡す。なお、認証用メールアドレス生成モジュール３３４は、認証用メールアドレスを生成してから所定の時間が経過すると、認証用メールアドレスを破棄してもよい。認証用メールアドレスが破棄されると、メール認証装置３は、当該認証用メールアドレスで電子メールを受信できない。よって、当該認証用メールアドレスによる成りすましのアクセスがなくなる。なお、認証用メールアドレスが破棄される時期については、本発明の実施者に委ねられる。
【００２５】
認証用メールアドレス生成モジュール３３４の認証用メールアドレスの生成方法の一例を説明する。認証用メールアドレス生成モジュール３３４は、メール認証装置３に割り当てられているドメインに基づいて、認証用メールアドレスを生成する。メール認証装置３に割り当てられているドメインが「ａｕｔｈａｄｄ．ｃｏｍ」の場合を説明する。認証用メールアドレス生成モジュール３３４は、乱数、アプリケーションＩＤ及び認証用メールアドレスの生成時刻等に基づいて、ランダムな文字列を生成する。なお、アプリケーションＩＤは、当該メール認証装置３にインストールされている認証プログラム３００の一意な識別子である。なお、アプリケーションＩＤは、一般的にライセンスキーとして知られているものであり、詳細な説明は省略する。例えば、認証用メールアドレス生成モジュール３３４は、ランダムな文字列の「００２９３８２」を生成する。そして、認証用メールアドレス生成モジュール３３４は、生成された文字列の「００２９３８２」及びドメインの「ａｕｔｈａｄｄ．ｃｏｍ」に基づいて、「００２９３８２＠ａｕｔｈａｄｄ．ｃｏｍ」を認証用メールアドレスとして生成する。なお、認証用メールアドレスの生成方法は、その目的を達成する限り他の方法を用いてもよい。
【００２６】
仮に、メール認証装置３は、認証用メールアドレス取得要求を複数のクライアント装置１０から同時に受信すると、受信したそれぞれの認証用メールアドレス取得要求ごとに異なる認証用メールアドレスを生成する。また、メール認証装置３は、第１の認証用メールアドレス取得要求を受信した後に、当該第１の認証要求の送信元であるクライアント装置１０から第２の認証用メールアドレス取得要求を受信してもよい。この場合、メール認証装置３は、第１の認証用メールアドレス取得要求に対して生成された認証用メールアドレスと異なる認証用メールアドレスを生成する。これによって、メール認証装置３は、同一のクライアント装置１０から送信される複数の認証要求を同時に処理できる。
【００２７】
次に、認証用メールアドレス生成モジュール３３４は、生成した認証用メールアドレスを、認証用メールアドレス送信モジュール３３５に引き渡す。
【００２８】
認証用メールアドレス送信モジュール３３５は、認証用メールアドレス生成モジュール３３４から引き受けた認証用メールアドレスを、クライアント装置１０に送信する。
【００２９】
メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する。なお、メール受信モジュール３３６は、クライアント装置１０以外から電子メールを受信してもよい。次に、メール受信モジュール３３６は、受信した電子メールから、送信先のメールアドレスを取得する。次に、メール受信モジュール３３６は、取得した送信先メールアドレスと一致する認証用メールアドレスを破棄する。これによって、メール認証装置３は、破棄された認証用メールアドレス宛ての電子メールを受信できなくなる。なお、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。なお、送信元のメールアドレスの偽装は、いかなる方法で判定されてもよい。
【００３０】
受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。続けて、受信メール読取モジュール３３７は、メールアドレス対応テーブル３４１（図５）に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信先メールアドレス３４１２に、電子メールから取得した送信先メールアドレスを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１３に、電子メールから取得した送信元メールアドレスを格納する。
【００３１】
図５は、第１の実施形態のメール認証装置３の補助記憶装置３４に記憶されているメールアドレス対応テーブル３４１の構成図である。メールアドレス対応テーブル３４１は、送信先メールアドレス３４１２及び送信元メールアドレス３４１３を含む。送信先メールアドレス３４１２は、当該メール認証装置３が受信した電子メールの送信先メールアドレスである。送信元メールアドレス３４１３は、当該メール認証装置３が受信した電子メールの送信元メールアドレスである。なお、本実施の形態では、送信先メールアドレス３４１２は、メール認証装置３と接続される多数のクライアント計算機１０の中から、認証を要求するユーザによって操作されるクライアント計算機１０を特定するために使用される。また、送信元メールアドレス３４１３は、認証を要求するユーザを特定するために使用される。
【００３２】
認証モジュール３３８は、認証用メールアドレスを含む認証要求をクライアント装置１０から受信する。なお、認証要求は、認証用メールアドレスの一部を含んでいてもよいし、認証用メールアドレスの全部を含んでいてもよい。例えば、認証用メールアドレスの一部は、認証用メールアドレスのドメインを除く文字列である。なお、クライアント装置１０は、認証要求と共に、当該認証要求に対応する認証用メールアドレスをメール認証装置３に通知できればいかなる方法であってもよい。例えば、認証要求を送信するための通信のセッションＩＤが、認証用メールアドレスの一部又は全部を含んでいてもよい。セッションＩＤは、ＷＥＢサーバとＷＥＢブラウザとの間の通信を識別する識別子である。セッションＩＤの生成及び管理は、通常のＷＥＢサーバ及び通常のＷＥＢブラウザの機能である。したがって、セッションＩＤの詳細な説明は、省略する。
【００３３】
続けて、認証モジュール３３８は、受信した認証要求から認証用メールアドレスを取得する。次に、認証モジュール３３８は、取得した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。これによって、認証モジュール３３８は、まったく別個の通信である認証要求と電子メールとの対応を把握する。つまり、認証モジュール３３８は、メール受信モジュール３３６が受信した電子メールの中から、受信した認証要求に対応する電子メールを特定する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１３を抽出する。つまり、認証モジュール３３８は、受信した認証要求に対応する電子メールの送信元アドレスを特定する。認証モジュール３３８は、送信元メールアドレス３４１３を抽出できない場合、認証不可と判定する。
【００３４】
次に、認証モジュール３３８は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。ユーザ管理テーブル３４２については、詳細を後述する。認証モジュール３３８は、メールアドレスが一致するレコードを選択できない場合は、認証不可と判定する。一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できる場合は、認証可能と判定する。そして、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元の計算機を操作するユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、認証要求の発行元の計算機が、抽出したユーザＩＤ３４２１によって識別されるユーザによって操作されていると判断する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【００３５】
図６は、第１の実施形態のメール認証装置３の補助記憶装置３４に記憶されているユーザ管理テーブル３４２の構成図である。ユーザ管理テーブル３４２は、ユーザＩＤ３４２１、メールアドレス３４２２を含む。ユーザＩＤ３４２１は、第１の実施形態のメール認証装置３で認証を受けるユーザの一意な識別子である。メールアドレス３４２２は、当該レコードのユーザＩＤ３４２１によって識別されるユーザの電子メールアドレスである。通常、メールアドレス３４２２は、当該レコードのユーザＩＤ３４２１によって識別されるユーザのみが使用可能な電子メールアドレスである。電子メールにはプライベートな内容が含まれるため、多くの個人が、自分専用の電子メールアドレスを保有している。なお、ユーザ管理テーブル３４２は、ユーザ固有のその他の情報を保有してもよい。ユーザの固有な情報は、例えば、ユーザ名、パスワード、クレジットカード番号、キャッシュカード番号、ユーザの生体情報、スケジュール表、操作履歴及び預金残高のうち少なくとも一つを含む。つまり、ユーザ管理テーブル３４２では、ユーザの固有な情報はユーザＩＤ３４２１に対応して管理されている。
【００３６】
第１の実施形態のメール認証装置３のユーザは、予め所定の方法で、ユーザ管理テーブル３４２にユーザＩＤ３４２１及びメールアドレス３４２２を登録する。なお、メールアドレス３４２２がユーザＩＤとして使用される場合、ユーザＩＤ３４２１は省略できる。
【００３７】
認証結果送信モジュール３３９は、認証モジュール３３８が判定した認証結果を、クライアント装置１０に送信する。なお、認証モジュール３３８が認証可能と判定した場合、認証結果送信モジュール３３９は、ユーザＩＤ３４２１に対応するユーザの固有な情報を付随した認証結果を送信してもよい。
【００３８】
次に、第１の実施形態の個人認証方法の処理について図を用いて説明する。図７は、第１の実施形態の個人認証方法の処理のシーケンス図である。
【００３９】
クライアント装置１０は、ユーザの操作を契機に、認証用メールアドレス取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ１１１）。
【００４０】
すると、認証用メールアドレス取得要求受信モジュール３３２１は、クライアント装置１０から認証用メールアドレス取得要求を受信する（ＳＴ１１２）。次に、認証用メールアドレス取得要求受信モジュール３３２１は、認証用メールアドレス生成モジュール３３４に、認証用メールアドレスの生成を依頼する。
【００４１】
認証用メールアドレス生成モジュール３３４は、認証用メールアドレスの生成の依頼を受けると、認証用メールアドレスを生成する（ＳＴ１１４）。次に、認証用メールアドレス生成モジュール３３４は、生成した認証用メールアドレスを、認証用メールアドレス送信モジュール３３５に引き渡す。
【００４２】
認証用メールアドレス送信モジュール３３５は、認証用メールアドレスを、認証用メールアドレス生成モジュール３３４から引き受ける。次に、認証用メールアドレス送信モジュール３３５は、引き受けた認証用メールアドレスを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ１１６）。
【００４３】
クライアント装置１０は、メール認証装置３から認証用メールアドレスを受信する（ＳＴ１１７）。
【００４４】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、認証用メールアドレス宛ての電子メールを送信する（ＳＴ１１８）。
【００４５】
すると、メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する（ＳＴ１１９）。次に、メール受信モジュール３３６は、受信した電子メールから、送信先のメールアドレスを取得する。次に、メール受信モジュール３３６は、取得したメールアドレスと一致する認証用メールアドレスを破棄する。このとき、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。
【００４６】
続いて、受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、受信メール読取モジュール３３７は、メールアドレス対応テーブル３４１に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信先メールアドレス３４１２に、取得した送信先メールアドレスを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１３に、取得した送信元メールアドレスを格納する（ＳＴ１２０）。
【００４７】
一方で、クライアント装置１０は、認証用メールアドレスの一部又は全部を含む認証要求を、ネットワーク９を介して、メール認証装置３に送信する（ＳＴ１２１）。
【００４８】
すると、認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する（ＳＴ１２２）。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【００４９】
続けて、認証モジュール３３８は、認証の依頼を受けると、認証要求受信モジュール３３２２が受信した認証要求から認証用メールアドレスを取得する。次に、認証モジュール３３８は、取得した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１３を抽出する。なお、認証モジュール３３８は、送信元メールアドレス３４１３を抽出できない場合、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。一方、認証モジュール３３８は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２が一致するレコードを、ユーザ管理テーブル３４２から選択する（ＳＴ１２３）。認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合は、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。なお、第１の実施形態では、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、認証不可と判定した。しかし、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、新規のユーザとして認証してもよい。この場合、認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合、新たなユーザＩＤを生成する。このとき、認証モジュール３３８は、ユーザ管理テーブル３４２に含まれるすべてのユーザＩＤ３４２１と重複しないように、ユーザＩＤを生成する。次に、認証モジュール３３８は、ユーザ管理テーブル３４２に、新たにレコードを生成する。次に、認証モジュール３３８は、生成したユーザＩＤを、生成した新たなレコードのユーザＩＤ３４２１に格納する。更に、認証モジュール３３８は、抽出した送信元メールアドレス３４１３を、生成した新たなレコードのメールアドレス３４２２に格納する。これによって、認証モジュール３３８は、生成したユーザＩＤと電子メールから取得した送信元のメールアドレスとを対応付けて、ユーザ管理テーブル３４２に記憶する。そして、認証モジュール３３８は、電子メールから取得した送信先のメールアドレスに対応するユーザを、新規のユーザとして認証を許可する。なお、認証モジュール３３８は、登録されるユーザの固有な情報をクライアント装置１０から受信してもよい。そして、認証モジュール３３８は、受信したユーザの固有な情報を、新たに生成したレコードに格納する。なお、ユーザの固有な情報は、認証要求に含まれてもよいし、単独で送信されてもよい。
【００５０】
一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できた場合、認証可能と判定する。次に、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元のクライアント計算機１０を操作しているユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、取得したユーザＩＤ３４２１によって識別される認証要求の発行元のクライアント計算機１０を操作しているユーザが、抽出したユーザＩＤ３４２１によって識別されるユーザあると特定する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【００５１】
認証結果送信モジュール３３９は、認証モジュール３３８から認証結果を引き受ける。次に、認証結果送信モジュール３３９は、引き受けた認証結果を、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ１２４）。
【００５２】
すると、クライアント装置１０は、メール認証装置３から認証結果を受信する（ＳＴ１２５）。
【００５３】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、ユーザＩＤ及びパスワードが掠め取られる危険性がない。また、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを管理する必要がない。このように、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【００５４】
本実施の形態では、メール認証装置３は、１台の装置で構成されるものとしたが、提供するサービスの規模などによっては、複数の装置で構成されてもよい。この場合、メール認証装置３を構成する装置は、適宜なデータ転送経路を介して互いに接続される。また、メール認証装置３は、機能別に複数の装置で構成されてもよい。例えば、メール認証装置３は、認証用メールアドレスを生成し、電子メールを受信する装置と、認証用メールアドレス取得要求及び認証要求を受信し、認証用メールアドレス及び認証結果を送信する装置と、で構成する。この場合も、メール認証装置３を構成する装置は、適宜なデータ転送経路を介して互いに接続される。そして、認証用メールアドレス及び電子メールのメールアドレス等を含む情報は、前記データ転送経路を介して装置間で引き渡される。
【００５５】
ここで、本実施の形態の最大の特徴について述べる。メール認証装置３は、認証要求を受信する。メール認証装置３は、受信した認証要求に含まれる認証用メールアドレスに基づいて、受信した電子メールと受信した認証要求との対応を特定できる。つまり、認証用メールアドレスは、一つの認証要求に一意に割り当てられ、認証要求の識別子としても使用される。更に、メール認証装置３は、認証要求に対応する電子メールの送信元のメールアドレスに基づいて、認証を受けようとするユーザを特定する。このようにして、メール認証装置３は、認証要求と当該認証要求によって認証を要求するユーザとの対応を特定できる。これによって、本実施の形態では、メール認証装置３は、認証要求にユーザＩＤが含まれないにもかかわらず、認証を実現できる。ユーザＩＤ及びパスワードによる認証方法では、認証要求に、ユーザＩＤ及びパスワードが含まれる。一方、本実施の形態のメール認証装置３は、認証を受けるユーザを電子メールで特定する。そして、メール認証装置３は、特定したユーザによって操作されるクライアント装置を特定する。これによって、メール認証装置３は、認証要求にユーザＩＤが含まれていなくても、認証を行うことができる。
【００５６】
また、本実施の形態では、クライアント装置１０は、メール認証装置３から認証用メールアドレスを受信し、受信した認証用メールアドレス宛てに電子メールを送信した。しかし、次の通りであってもよい。クライアント装置１０は、メール認証装置３から受信した認証用メールアドレスを表示装置に表示する。続いて、ユーザは、認証用メールアドレスを表示しているクライアント装置１０と異なる第２のクライアント装置１０から、認証用メールアドレス宛てに電子メールを送信してもよい。この場合、認証されるユーザは、第２のクライアント装置１０から送信した電子メールの送信元メールアドレスに対応するユーザである。そして、認証用メールアドレスを表示したクライアント装置１０が、メール認証装置３から認証結果を受信する。例えば、認証用メールアドレスを表示するクライアント装置１０は、パーソナルコンピュータであり、電子メールを送信する第２のクライアント装置１０は、インターネットに接続され電子メールの送信が可能な携帯電話である。
【００５７】
ところで、前述した実施形態では、クライアント装置１０のユーザは、認証を受けるために、電子メールを用いた。クライアント装置１０のユーザは、認証を受けるために、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）による通信を用いてもよい。この場合、クライアント装置１０は、ＳＩＰユーザ・エージェントの機能を備える。また、メール認証装置３は、ＳＩＰユーザ・エージェントの機能及びＳＩＰサーバの機能を備える。そして、メール認証装置３は、認証用メールアドレスの代わりに、認証用ユーザエージェントアドレスを生成する。認証用ユーザエージェントアドレスは、メール認証装置３がＳＩＰに基づく通信を受信するためのアドレスである。アドレス体系は、電子メールと同様のため、詳細な説明は省略する。認証用ユーザエージェントアドレスの生成方法は、認証用メールアドレスの生成方法と同様であればよい。メール認証装置３は、認証用ユーザエージェントアドレスを生成し、クライアント装置１０に通知する。クライアント装置１０は、ユーザの操作を契機に、ＳＩＰによって、認証用ユーザエージェントアドレス宛てにシグナリングを送信する。メール認証装置３は、クライアント装置１０からシグナリングを受信する。メール認証装置３は、受信したシグナリングから、送信元のユーザエージェントアドレス及び送信先のユーザエージェントアドレスを抽出する。次に、メール認証装置３は、取得した送信先のユーザエージェントアドレスと認証用メールアドレス対応テーブルの認証用ユーザエージェントアドレスとの対応を、ユーザエージェントアドレス対応テーブルに格納する。一方、クライアント装置１０は、認証用ユーザエージェントアドレスの一部又は全部を含む認証要求をメール認証装置３に送信する。メール認証装置３は、クライアント装置１０から認証要求を受信する。メール認証装置３は、受信した認証要求から、認証用ユーザエージェントアドレスを抽出する。次に、メール認証装置３は、抽出した認証用ユーザエージェントアドレスとユーザエージェントアドレス対応テーブルの送信先ユーザエージェントアドレスとが一致するレコードを、ユーザエージェントアドレス対応テーブルから選択する。次に、メール認証装置３は、選択したレコードから、送信元ユーザエージェントアドレスを抽出する。次に、メール認証装置３は、抽出した送信元ユーザエージェントアドレスとユーザ管理テーブルのユーザのユーザエージェントアドレスとが、一致するレコードを選択する。ここで、メール認証装置３は、ユーザ管理テーブルから、ユーザエージェントアドレスが一致するレコードを選択できたか否かを判定する。選択できた場合、メール認証装置３は、認証可能と判定する。そして、メール認証装置３は、認証要求の発行元のユーザを特定できる。具体的には、メール認証装置３は、選択したレコードから、ユーザＩＤを抽出する。そして、メール認証装置３は、受信した認証要求の発行元が、抽出したユーザＩＤによって識別されるユーザであると特定する。なお、メール認証装置３は、抽出したユーザＩＤに対応するユーザの固有な情報を、認証結果に含めてもよい。なお、すべての実施の形態において、電子メールの代わりに、ＳＩＰによる通信を用いてもよい。
【００５８】
ところで、本発明のなりすましに対する安全性は、電子メールの偽装に対する強度に依存しているため、電子メールの偽装について述べる。
【００５９】
はじめに、電子メールの送信元が偽装された場合について述べる。偽装者は、電信メールの送信元を偽装して、第１の実施形態のメール認証装置３で認証されれば、偽装した電子メールアドレスを保有する本来のユーザになりすますことができる。そこで、メール受信モジュール３３６は、ＳＰＦ（Ｓｅｎｄｅｒ Ｐｏｌｉｃｙ Ｆｒａｍｅｗｏｒｋ）に沿ったメール受信機能を搭載する。ＳＰＦとは、電子メールサーバが偽装メールを検知するための技術である。メール受信モジュール３３６は、受信した電子メールのドメインについて、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｅｒ）に照会を要求する。そして、メール受信モジュール３３６は、ＤＮＳによる照会結果と電子メールの送信元のＩＰアドレスとを照合することによって、電子メールの送信元のメールアドレスが偽装されているか否かを判定する。なお、メール受信モジュール３３６が採用する偽装メール検知技術は、その目的を達成する限り、ＤＫＩＭ等の他の方法であってもよい。
【００６０】
次に、電子メールの送信先が偽装された場合について述べる。偽装者は、電子メールの送信先を偽装して、第１の実施形態のメール認証装置３で認証されても、他者になりすますことはできない。むしろ、他者が、偽装者になりすましてしまう。偽装者になりすます他者は、偽装した送信先メールアドレスと同一のメールアドレスを認証用メールアドレスとして受信したクライアント装置を操作する者である。したがって、偽装者は、電子メールの送信先を偽装しても、利益を得られない。また、認証用メールアドレスは乱数などによって生成されるため、偽装したメールアドレスが認証用メールアドレスと一致することは稀である。
【００６１】
ここでは、本発明における認証について説明する。本発明における認証は、一般的な概念だけでなく、広い意味での認証を含む。具体的には、本発明における認証とは、個人認証システムによって提供されるサービスを利用する権利が、ユーザにあるか否かの検証である。本発明の個人認証システムは、クライアント装置を利用しているユーザを識別し、識別したユーザごとに対応するサービスを提供できる。従って、本発明における認証要求とは、個人認証システムによって提供されるサービスを利用する権利が、ユーザにあるか否かの検証の要求である。例えば、認証要求は、ＷＥＢページのログインの要求である。この場合、メール認証装置３は、ＷＥＢサーバであってもよいし、ＷＥＢサーバから認証の依頼を受ける認証専用装置であってもよい。また、認証要求は、ＷＥＢページでのクレジットカード決済の要求である。この場合、メール認証装置３は、クレジットカード決済を行うＷＥＢサーバであってもよいし、当該ＷＥＢサーバから認証の依頼を受ける認証専用装置であってもよい。また、認証要求は、ＡＴＭにおける預金の引き出し、借入金返済又は借入金の借り入れの要求である。この場合、クライアント装置１０は、ＡＴＭである。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、ＡＴＭにおける決済を管理する管理サーバである。また、認証要求は、店舗でのクレジットカード決済の要求である。この場合、クライアント装置１０は、クレジットカードの情報を読み取るリーダ装置である。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該リーダ装置におけるクレジットカードの決済を管理する管理サーバである。また、認証要求は、デビットカード決済の要求である。この場合、クライアント装置１０は、デビットカードの情報を読み取るリーダ装置である。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該リーダ装置におけるデビットカードの決済を管理する管理サーバである。また、認証要求は、公共料金との合算後払いによる借り入れの要求である。この場合、クライアント装置１０は、ＡＴＭである。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該ＡＴＭにおける借り入れを管理する管理サーバである。また、認証要求とは、公共料金の未払金の支払いの要求である。この場合、クライアント装置１０は、コンビニ等に設置されている情報端末である。また、電子メールを送信するための第２のクライアント装置１０は、携帯電話等のポータブル端末である。更に、メール認証装置３は、当該情報端末を管理する管理サーバである。また、認証要求は、社内イントラネットへの接続の要求である。この場合、メール認証装置３は、社内のイントラネットを管理する管理サーバである。また、認証要求は、シンクライアント（ＴＨＩＮ ＣＬＩＥＮＴ）によるサーバへの接続の要求である。この場合、メール認証装置３は、シンクライアント装置とサーバとの接続を管理する管理サーバである。また、認証要求は、無線ＬＡＮのアクセスポイントへの接続の要求である。この場合、メール認証装置３は、クライアント装置１０とアクセスポイントとの接続を管理する管理サーバである。本実施の形態の認証要求は、ユーザＩＤ及びパスワードを含まないが、メール認証装置３は、認証処理を行うことができる。なお、メール認証装置３は、本実施の形態の認証処理とあわせて、従来の認証処理を実行することによって、安全性を高めてもよい。例えば、メール認証装置３は、本実施の形態の認証処理とあわせて、ユーザの固有な情報を照合することによって、認証してもよい。ユーザの固有な情報は、例えば、ユーザ名、パスワード、クレジットカード番号、キャッシュカード番号、ユーザの生体情報、メールアドレス及び電話番号のうち少なくとも一つを含む。但し、ユーザの固有な情報は、ユーザ管理テーブル３４２のメールアドレス３４２２に登録されているメールアドレス以外であるのが好ましい。なぜなら、なりすましによって認証を受けようとする悪意者は、ユーザ管理テーブル３４２に登録されているメールアドレスを知っているので、本実施の形態の認証システムの安全性を高めることにならないからである。次に、ユーザの固有な情報を照合する認証方法の具体例を説明する。具体的には、メール認証装置３は、ユーザＩＤ及びパスワードの少なくとも一方を照合することによって、認証してもよい。この場合、メール認証装置３は、ユーザＩＤとユーザの固有な情報との対応を予め記憶しておく。一方、認証を受けようとするユーザは、クライアント装置１０に、ユーザの固有な情報を入力する。ここでの入力は、キーボード等の操作によるものでだけでなく、カードリーダにカードを読み込ませる等を含む。つまり、クライアント装置１０が、ユーザの固有な情報を取得できればいかなるものであってもよい。また、ユーザの固有な情報の入力タイミングは、いつでもよい。クライアント装置１０は、入力されたユーザの固有な情報を、メール認証装置３に送信する。なお、クライアント装置１０は、入力されたユーザの固有な情報を、認証用メールアドレス取得要求に含めて送信してもよいし、認証要求に含めて送信してもよいし、単独で送信してもよい。メール認証装置３は、ユーザの固有な情報をクライアント装置１０から受信する。メール認証装置３の認証モジュール３３８は、個人認証方法の処理（図７）のステップＳＴ１２３において認証要求の発行元のユーザを特定する。次に、メール認証装置３は、特定したユーザのユーザＩＤに対応して記憶されているユーザの固有な情報を特定する。次に、メール認証装置３の認証モジュール３３８は、特定したユーザの固有な情報と、クライアント装置１０から受信したユーザの固有な情報と、が一致するか否かを判定する。そして、メール認証装置３は、二つのユーザの固有な情報が一致すると、認証可能と判定する。一方、メール認証装置３は、二つのユーザの固有な情報が一致しない場合、認証不可と判定する。
【００６２】
また、本実施の形態のユーザは、人でなく、コンピュータであってもよい。例えば、コンピュータがユーザとして、認証を受けてもよい。
【００６３】
（第２の実施形態）
以下で第２の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【００６４】
図８は、第２の実施形態の個人認証システムの概略の構成図である。図８に示す個人認証システムは、クライアント装置９０１０及びメール認証ＷＥＢ装置９０３を備える。クライアント装置９０１０は、認証を受けようとするユーザによって操作される計算機である。また、クライアント装置９０１０は、ネットワーク９に接続されている。なお、第３の実施の形態では、ネットワーク９は、インターネットである。クライアント装置９０１０の構成は、第１の実施形態の個人認証システムに備わるクライアント装置１０（図２）と同一なので、説明を省略する。なお、クライアント装置９０１０は、送受信部、中央処理装置及び主記憶装置を備えれば、いかなる形態であってもよい。例えば、クライアント装置９０１０は、パーソナルコンピュータ、サーバ、携帯電話又はＡＴＭ等である。但し、携帯電話は、クライアント装置９０１０である場合、ＷＥＢブラウザ機能を搭載している。メール認証ＷＥＢ装置９０３は、ネットワーク９を介してクライアント装置９０１０に接続されている。メール認証ＷＥＢ装置９０３は、ＷＥＢサーバ機能及びメール受信サーバ機能を備える。メール認証ＷＥＢ装置９０３の構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図３）と同一なので、説明を省略する。なお、説明を明瞭にするために、第２の実施形態の個人認証システムでは、１台のクライアント装置９０１０に対する認証処理を説明する。実際には、メール認証ＷＥＢ装置９０３は、ネットワーク９を介して、複数のクライアント装置９０１０に対する認証を行う。なお、図８では、クライアント装置９０１０は、５台（パーソナルコンピュータ３台及び携帯電話２台）を図示したが、個人認証システムに何台備わっていても良い。
【００６５】
クライアント装置９０１０の機能は、第１の実施形態の個人認証システムに備わるクライアント装置１０と同様なので、説明を省略する。具体的には、クライアント装置９０１０は、ＨＴＴＰによって、認証要求及び認証要求を、メール認証ＷＥＢ装置９０３へ送信する。また、クライアント装置９０１０は、ＨＴＴＰによって、認証用メールアドレス及び認証結果を、メール認証ＷＥＢ装置９０３から受信する。
【００６６】
図９は、第２の実施形態のメール認証ＷＥＢ装置９０３の機能ブロック図である。メール認証ＷＥＢ装置９０３の補助記憶装置には、第２の実施形態の認証プログラム９０３００が記憶されている。第２の実施形態の認証プログラム９０３００が実行されると、メール認証ＷＥＢ装置９０３の主記憶装置には、メインモジュール３３１、認証用メールアドレス取得要求受信モジュール３３２１、認証要求受信モジュール３３２２、認証用メールアドレス生成モジュール３３４、認証用メールアドレス送信モジュール９０３３５、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール９０３３９が記憶される。
【００６７】
認証用メールアドレス送信モジュール９０３３５は、第１の実施形態のメール認証装置３に備わる認証用メールアドレス送信モジュール３３５と同一の機能を備える。また、認証結果送信モジュール９０３３９は、第１の実施形態のメール認証装置３に備わる認証結果送信モジュール３３９と同一の機能を備える。その他のモジュールは、第１の実施形態のメール認証装置３に備わるものと同一なので、説明を省略する。
【００６８】
認証用メールアドレス送信モジュール９０３３５は、認証用メールアドレス送信モジュール３３５の機能に加え、認証用メールアドレスを含むＷＥＢページを生成する。認証用メールアドレス送信モジュール９０３３５は、生成したＷＥＢページを、クライアント装置９０１０に送信する。
【００６９】
認証用メールアドレス送信モジュール９０３３５によって生成されるＷＥＢページ（図示省略）は、認証用メールアドレス及び認証要求ボタンを含み、クライアント装置９０１０に表示される。認証要求ボタンは、ユーザから認証要求の送信の指示を受け付けるものである。つまり、認証要求ボタンがユーザによって操作されると、クライアント装置９０１０は、認証要求をメール認証ＷＥＢ装置９０３に送信する。なお、認証用メールアドレス送信モジュール９０３３５によって生成されるＷＥＢページは、認証要求ボタンを含まなくてもよい。この場合、クライアント装置９０１０は、ユーザの操作を契機とせずに、認証要求をメール認証ＷＥＢ装置９０３へ一定間隔で送信する。
【００７０】
認証結果送信モジュール９０３３９は、認証結果送信モジュール３３９の機能に加え、認証モジュール３３８による認証結果を含むＷＥＢページを生成する。認証結果送信モジュール９０３３９は、生成したＷＥＢページを認証結果として、クライアント装置９０１０に送信する。なお、認証結果が認証可能であった場合、認証結果送信モジュール９０３３９によって生成されたＷＥＢページには、ユーザＩＤに対応するユーザの固有な情報が含まれてもよい。ユーザの固有な情報は、例えば、ユーザ名、パスワード、クレジットカード番号、キャッシュカード番号、ユーザの生体情報、スケジュール表、操作履歴及び預金残高のうち少なくとも一つを含む。
【００７１】
次に、第２の実施形態の個人認証方法について図を用いて説明する。図１０は、第２の実施形態の個人認証方法の処理のシーケンス図である。第２の実施形態の個人認証方法（図１０）と第１の実施形態の個人認証方法（図７）とを比較する。第２の実施形態の個人認証方法は、ＳＴ９０１１６を、ＳＴ１１６の代わりに含む。また、第２の実施形態の個人認証方法は、ＳＴ９０１２４を、ＳＴ１２４の代わりに含む。なお、第２の実施形態の個人認証方法の処理は、ＳＴ９０１１６及びＳＴ９０１２４を除いて、第１の実施形態の個人認証方法（図７）と同様である。したがって、ＳＴ９０１１６及びＳＴ９０１２４以外のステップについては、説明を省略する。
【００７２】
ＳＴ９０１１６について述べる。認証用メールアドレス送信モジュール９０３３５は、認証用メールアドレス生成モジュール３３４によって生成された認証用メールアドレスを、認証用メールアドレス生成モジュール３３４から引き受ける。次に、認証用メールアドレス送信モジュール３３５は、引き受けた認証用メールアドレスを含むＷＥＢページを生成する。次に、認証用メールアドレス送信モジュール９０３３５は、生成したＷＥＢページを、ネットワーク９を介して、クライアント装置９０１０に送信する（ＳＴ９０１１６）。
【００７３】
次に、ＳＴ９０１２４について述べる。認証結果送信モジュール９０３３９は、認証モジュール３３８から認証結果を引き受ける。次に、認証結果送信モジュール９０３３９は、引き受けた認証結果を含むＷＥＢページを生成する。次に、認証結果送信モジュール９０３３９は、生成したＷＥＢページを、ネットワーク９を介してクライアント装置９０１０に送信する（ＳＴ９０１２４）。なお、認証結果送信モジュール９０３３９は、ユーザＩＤに対応するユーザの固有な情報を含むＷＥＢページを生成し、生成したＷＥＢページを送信してもよい。
【００７４】
前述の通り、クライアント装置９０１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、ユーザＩＤ及びパスワードが掠め取られる危険性がない。また、クライアント装置９０１０のユーザは、ユーザＩＤ及びパスワードを管理する必要がない。このように、本実施の形態は、ＷＥＢサイトのユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、フィッシング又はスパイウェア等によって、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【００７５】
（第３の実施形態）
以下で第３の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システム又は第２の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【００７６】
第２の実施形態の個人認証システムに備わるメール認証ＷＥＢ装置９０３は、認証機能及びユーザの固有な情報を含むＷＥＢページの送信機能を備える。このとき、従来のＷＥＢサーバをメール認証ＷＥＢ装置９０３の機能を備えるように変更するためには、ＷＥＢサーバのプログラムの変更が不可欠である。これに対して、第３の実施形態では、従来のＷＥＢサーバへ、本発明の個人認証方法を容易に導入可能な実施形態を説明する。第３の実施形態の個人認証システムに備わる従来のＷＥＢサーバを、導入ＷＥＢサーバ５とする。
【００７７】
図１１は、第３の実施形態の個人認証システムの概略の構成図である。図１１に示す個人認証システムは、複数のクライアント装置１０、複数の携帯電話６０、導入ＷＥＢサーバ５及びメール認証専用ＷＥＢ装置９４３を備える。クライアント装置１０は、認証を受けようとするユーザによって操作される計算機である。クライアント装置１０はネットワーク９に接続されている。クライアント装置１０の構成は、第１の実施形態の個人認証システムに備わるクライアント装置１０（図２）と同一なので、説明を省略する。携帯電話６０は、認証を受けようとするユーザによって操作される。携帯電話６０は、ＷＥＢブラウザを搭載する。また、携帯電話６０は、電子メール送信機能を搭載する。携帯電話６０は、ネットワーク９に接続されている。導入ＷＥＢサーバ５は、ネットワーク９を介してクライアント装置１０及び携帯電話６０に接続されている。なお、本実施の形態では、ネットワーク９はインターネットである。導入ＷＥＢサーバ５は、従来のＷＥＢサーバである。例えば、導入ＷＥＢサーバ５は、クライアント装置１０のユーザからログインを受け付ける。そして、導入ＷＥＢサーバ５は、ユーザの固有な情報を含むＷＥＢページをクライアント装置１０に送信する。具体的には、導入ＷＥＢサーバ５は、ユーザＩＤに対応する会員用のＷＥＢページを送信する。メール認証専用ＷＥＢ装置９４３は、ネットワーク９を介してクライアント装置１０及び携帯電話６０に接続されている。メール認証専用ＷＥＢ装置９４３は、ＷＥＢサーバ機能及びメール受信サーバ機能を備えている。メール認証専用ＷＥＢ装置９４３の構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図３）と同一なので、説明を省略する。なお、図１１では、クライアント装置１０は、３台を図示したが、個人認証システムに何台備わっていても良い。また、携帯電話６０は、２台を図示したが、個人認証システムに何台備わっていてもよい。
【００７８】
なお、説明を明瞭にするために、第３の実施形態の個人認証システムの説明では、導入ＷＥＢサーバ５には、ドメイン「ｄｏｕｎｙｕ．ｊｐ」が割り当てられているとする。また、メール認証専用ＷＥＢ装置９４３には、ドメイン「ｎｉｎｓｈｏ．ｊｐ」が割り当てられているとする。
【００７９】
クライアント装置１０の機能構成は、第１の実施形態の個人認証システムに備わるクライアント装置１０と同一なので、説明を省略する。なお、クライアント装置１０は、導入ＷＥＢサーバ５でなく、メール認証専用ＷＥＢ装置９４３に、認証用メールアドレス取得要求を送信する。その後、クライアント装置１０は、認証用メールアドレスを、メール認証専用ＷＥＢ装置９４３から受信する。また、クライアント装置１０は、認証用メールアドレス宛てに電子メールを送信することによって、メール認証専用ＷＥＢ装置９４３に電子メールを送信する。そして、クライアント装置１０は、認証用メールアドレスの一部又は全部を含む認証要求をメール認証専用ＷＥＢ装置９４３に送信する。
【００８０】
クライアント装置１０は、第１の実施形態の個人認証システムに備わるクライアント装置１０の機能に加えて、次の機能を持つ。クライアント装置１０は、ユーザの操作を契機に、ログイン用のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。また、クライアント装置１０は、メール認証専用ＷＥＢ装置９４３から受信する認証の結果を示すＷＥＢページに含まれる情報によって、会員用のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。
【００８１】
導入ＷＥＢサーバ５は、クライアント装置１０から、ログイン用のＷＥＢページの要求を受信する。すると、導入ＷＥＢサーバ５は、要求されたログイン用のＷＥＢページをクライアント装置１０に送信する。当該ログイン用のＷＥＢページは、認証サイト情報を含む。認証サイト情報とは、クライアント装置１０に、メール認証専用ＷＥＢ装置９４３への認証要求の送信を促す情報である。また、認証サイト情報は、戻先ＵＲＬを含む。戻先ＵＲＬとは、メール認証専用ＷＥＢ装置９４３による認証完了後に、クライアント装置１０が会員用のＷＥＢページの要求を送信するＵＲＬである。ここで、認証サイト情報の例を示す。例えば、認証サイト情報は、「＜ＳＣＲＩＰＴ ＳＲＣ＝‘ｈｔｔｐ：／／ｗｗｗ．ｎｉｎｓｈｏ．ｊｐ／ｉｎｄｅｘ．ｐｈｐ？ｒｕｒｌ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ’＞＜／ＳＣＲＩＰＴ＞」である。「ｒｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。また、例えば、認証サイト情報は、「＜Ａ ＨＲＥＦ＝‘ｈｔｔｐ：／／ｗｗｗ．ｎｉｎｓｈｏ．ｊｐ／ｉｎｄｅｘ．ｐｈｐ？ｒｕｒｌ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ’＞認証はこちら＜／Ａ＞」である。「ｒｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。認証サイト情報は、その目的を達成する限り、他のものであってもよい。
【００８２】
導入ＷＥＢサーバ５は、クライアント装置１０から、会員用のＷＥＢページの要求を受信する。導入ＷＥＢサーバ５は、受信した会員用のＷＥＢページの要求から、ユーザのメールアドレスを抽出する。導入ＷＥＢサーバ５は、抽出したメールアドレスに基づいて、事前に記憶しているユーザの固有な情報を含むＷＥＢページを生成する。導入ＷＥＢサーバ５は、生成したＷＥＢページを、会員用のＷＥＢページとして、クライアント装置１０に送信する。
【００８３】
メール認証専用ＷＥＢ装置９４３の機能は、主に、第２の実施形態の個人認証システムに備わるメール認証ＷＥＢ装置９０３と同様である。メール認証専用ＷＥＢ装置９４３の機能は、第２の実施形態の個人認証システムに備わるメール認証ＷＥＢ装置９０３の機能に加えて、次の機能を備える。メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から受信する認証用メールアドレス取得要求から、戻先ＵＲＬを抽出する。また、メール認証専用ＷＥＢ装置９４３は、抽出した戻先ＵＲＬを、生成した認証用メールアドレスと共に送信する。また、メール認証専用ＷＥＢ装置９４３は、認証の結果、戻先ＵＲＬ及びユーザのメールアドレスを含むＷＥＢページを生成する。生成されたＷＥＢページに含まれるソースコードの例を示す。例えば、ソースコードは、「＜ｍｅｔａ ｈｔｔｐ−ｅｑｕｉｖ＝“Ｒｅｆｒｅｓｈ” ｃｏｎｔｅｎｔ＝“０；ｕｒｌ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ？ｕｓｒｍａｉｌ＝ｔａｋａ＠ｙａｈｏｏ．ｃｏ．ｊｐ＆ａｕｔｈ＝１”＞」である。「ｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。「ｕｓｒｍａｉｌ＝」以降のメールアドレスが、ユーザのメールアドレスである。「ａｕｔｈ＝」以降の値が、認証の結果である。例えば、「１」は、認証可能であり、「０」は認証不可である。ただし、「ａｕｔｈ＝」は必ずしも含まれている必要はない。また、例えば、ソースコードは、「＜Ａ ＨＲＥＦ＝“ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ？ｕｓｒｍａｉｌ＝ｔａｋａ＠ｙａｈｏｏ．ｃｏ．ｊｐ＆ａｕｔｈ＝１”＞会員ページはこちら＜／Ａ＞」である。「ｕｒｌ＝」以降のＵＲＬが、戻先ＵＲＬである。「ｕｓｒｍａｉｌ＝」以降のメールアドレスが、ユーザのメールアドレスである。「ａｕｔｈ＝」以降の値が、認証の結果である。例えば、「１」は、認証可能であり、「０」は認証不可である。ただし、「ａｕｔｈ＝」は必ずしも含まれている必要はない。なお、前記ＷＥＢページが含むソースコードは、その目的を達成する限り、他のものであってもよい。
【００８４】
次に、第３の実施形態の個人認証方法について図を用いて説明する。図１２は、第３の実施形態の個人認証方法の処理のシーケンス図である。第３の実施形態の個人認証方法（図１２）と第２の実施形態の個人認証方法（図１０）とを比較する。第３の実施形態の個人認証方法は、ＳＴ９４１１２を、ＳＴ１１２の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１１６を、ＳＴ９０１１６の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１２１を、ＳＴ１２１の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１２２を、ＳＴ１２２の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１２４を、ＳＴ１２４の代わりに含む。また、第３の実施形態の個人認証方法は、ＳＴ９４１０９、ＳＴ９４１１０、ＳＴ９４１２６、ＳＴ９４１２１、ＳＴ９４１２２、ＳＴ９４１２７及びＳＴ９４１２８を含む。なお、第３の実施形態の個人認証方法の処理は、ＳＴ９４１０９、ＳＴ９４１１０、ＳＴ９４１１２、ＳＴ９４１１６、ＳＴ９４１２４、ＳＴ９４１２６、ＳＴ９４１２７及びＳＴ９４１２８を除いて、第２の実施形態の個人認証方法（図１０）と同様である。したがって、ＳＴ９４１０９、ＳＴ９４１１０、ＳＴ９４１１２、ＳＴ９４１１５、ＳＴ９４１２４、ＳＴ９４１２６、ＳＴ９４１２７及びＳＴ９４１２８以外のステップについては、説明を省略する。
【００８５】
ＳＴ９４１０９について説明する。クライアント装置１０は、ネットワーク９を介して導入ＷＥＢサーバ５へ、ログイン用のＷＥＢページの要求を送信する（ＳＴ９４１０９）。
【００８６】
ＳＴ９４１１０について説明する。導入ＷＥＢサーバ５は、クライアント装置１０から、ログイン用のＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、認証サイト情報を含むログイン用のＷＥＢページを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ９４１１０）。
【００８７】
ＳＴ９４１１２について説明する。メール認証専用ＷＥＢ装置９４３に備わる認証要求受信モジュールは、クライアント装置１０から認証要求を受信する。次に、認証要求受信モジュールは、受信した認証要求に含まれる戻先ＵＲＬを抽出する。次に、認証要求受信モジュールは、認証用メールアドレス生成モジュールに、認証要求メールアドレスの生成を依頼する（ＳＴ９４１１２）。
【００８８】
ＳＴ９４１１６について説明する。認証用メールアドレス送信モジュールは、認証用メールアドレス生成モジュールによって生成された認証用メールアドレスを、認証用メールアドレス生成モジュールから引き受ける。次に、認証用メールアドレス送信モジュールは、引き受けた認証用メールアドレスを含むＷＥＢページを生成する。次に、認証用メールアドレス送信モジュール９０３３５は、生成したＷＥＢページ及び認証要求受信モジュールによって抽出された戻先ＵＲＬを、ネットワーク９を介して、クライアント装置１０に送信する（ＳＴ９４１１６）。
【００８９】
ＳＴ９４１２１について説明する。クライアント装置１０は、ＳＴ９４１１６で受信した戻先ＵＲＬ及び認証用メールアドレスを含む認証要求を、ネットワーク９を介して、メール認証専用ＷＥＢ装置９４３に送信する（ＳＴ９４１２１）。
【００９０】
ＳＴ９４１２１について説明する。認証要求受信モジュールは、クライアント装置１０から認証要求を受信する。次に、認証要求受信モジュールは、受信した認証要求から、戻先ＵＲＬ及び認証用メールアドレスを抽出する。そして、認証要求受信モジュールは、認証要求を受信すると、認証モジュールに認証を依頼する。
【００９１】
ＳＴ９４１２４について説明する。認証結果送信モジュールは、認証モジュールから認証の結果を引き受ける。次に、認証結果送信モジュールは、認証の結果、ユーザのメールアドレスを及び認証要求受信モジュールが受信した戻先ＵＲＬ含むＷＥＢページを生成する。次に、認証結果送信モジュールは、生成したＷＥＢページを、認証の結果として、ネットワーク９を介して、クライアント装置１０に送信する（ＳＴ９４１２４）。
【００９２】
ＳＴ９４１２６について説明する。クライアント装置１０は、メール認証専用ＷＥＢ装置９４３から、認証の結果として送信されたＷＥＢページを受信する。次に、クライアント装置１０は、受信したＷＥＢページに基づいて、会員用のＷＥＢページの要求を、ネットワーク９を介して導入ＷＥＢサーバ５へ送信する（ＳＴ９４１２６）。クライアント装置１０によって送信される会員用のＷＥＢページの要求は、ユーザのメールアドレスを含む。例えば、会員用のＷＥＢページの要求は、「ｈｔｔｐ：／／ｗｗｗ．ｄｏｕｎｙｕ．ｊｐ／ｍｅｍｂｅｒ．ｐｈｐ？ｕｓｒｍａｉｌ＝ｔａｋａ＠ｙａｈｏｏ．ｃｏ．ｊｐ＆ａｕｔｈ＝１」というＵＲＬである。「ｕｓｒｍａｉｌ＝」以降のメールアドレスが、ユーザのメールアドレスである。
【００９３】
ＳＴ９４１２７について説明する。導入ＷＥＢサーバ５は、クライアント装置１０から会員用ＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、受信した会員用のＷＥＢページの要求から、ユーザのメールアドレスを抽出する。次に、導入ＷＥＢサーバ５は、抽出したメールアドレスに基づいて、ユーザを特定する。次に、メール認証専用ＷＥＢ装置９４３は、特定したユーザに対応する会員用のＷＥＢページを生成する。次に、導入ＷＥＢサーバ５は、生成した会員用のＷＥＢページを、ネットワーク９を介して、クライアント装置１０に送信する（ＳＴ９４１２７）。
【００９４】
ＳＴ９４１２８について説明する。クライアント装置１０は、会員用のＷＥＢページを、ネットワーク９を介して導入ＷＥＢサーバ５から受信する。次に、クライアント装置１０は、受信した会員用のＷＥＢページを、表示装置に表示する（ＳＴ９４１２８）。
【００９５】
第３の実施形態の個人認証方法の処理の概要を説明する。クライアント装置１０は、ユーザの操作を契機に、ログイン用のＷＥＢページを、導入ＷＥＢサーバ５に、要求する（ＳＴ９４１０９）。導入ＷＥＢサーバ５は、要求されたログイン用のＷＥＢページを、クライアント装置１０に送信する（ＳＴ９４１１０）。クライアント装置１０は、ログイン用のＷＥＢページに含まれる認証サイト情報に基づいて、メール認証専用ＷＥＢ装置９４３に認証要求を送信する（ＳＴ１１１）。メール認証専用ＷＥＢ装置９４３は、認証要求を受信する。次に、メール認証専用ＷＥＢ装置９４３は、受信した認証要求から戻先ＵＲＬを抽出する（ＳＴ９４１１２）。次に、メール認証専用ＷＥＢ装置９４３は、認証用メールアドレスを生成する（ＳＴ１１４）。。次に、メール認証専用ＷＥＢ装置９４３は、生成した認証用メールアドレス及び抽出した戻先ＵＲＬを、クライアント装置１０に送信する（ＳＴ９４１１６）。クライアント装置１０は、認証用メールアドレス及び戻先ＵＲＬを受信する（ＳＴ１１７）。次に、クライアント装置１０は、認証用メールアドレス宛てに、電子メールを送信する（ＳＴ１１８）。すると、メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から、電子メールを受信する（ＳＴ１１９）。次に、メール認証専用ＷＥＢ装置９４３は、受信した電子メールの送信元のメールアドレス及び送信先のメールアドレスを特定する。次に、メール認証専用ＷＥＢ装置９４３は、特定した送信先のメールアドレスと特定した送信元のメールアドレスとを対応付けて、メールアドレス対応テーブル３４１に記憶する（ＳＴ１２０）。一方で、クライアント装置１０は、認証要求を、メール認証専用ＷＥＢ装置９４３に送信する（ＳＴ１２１）。すると、メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から、認証要求を受信する（ＳＴ１２２）。メール認証専用ＷＥＢ装置９４３は、受信した認証要求から、認証用メールアドレス及び戻先ＵＲＬを抽出する。次に、メール認証専用ＷＥＢ装置９４３は、メールアドレス対応テーブル３４１から、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証専用ＷＥＢ装置９４３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出した送信元メールアドレス３４１３がユーザ管理テーブル３４２のメールアドレス３４２２に格納されているか否かを判定する（ＳＴ１２３）。送信元メールアドレス３４１３がユーザ管理テーブル３４２に格納されている場合、メール認証専用ＷＥＢ装置９４３は、認証可能と判定する。一方、送信元メールアドレス３４１３がユーザ管理テーブル３４２に格納されていない場合、メール認証専用ＷＥＢ装置９４３は、認証不可と判定する。次に、メール認証専用ＷＥＢ装置９４３は、認証の結果を、クライアント装置１０に送信する（ＳＴ９４１２４）。クライアント装置１０は、認証の結果を受信する（ＳＴ１２５）。次に、クライアント装置１０は、受信した認証の結果に基づいて、会員用のＷＥＢページの要求を導入ＷＥＢサーバ５に送信する（ＳＴ９４１２６）。導入ＷＥＢサーバ５は、クライアント装置１０から、会員用のＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、受信した会員用のＷＥＢページの要求から、ユーザのメールアドレスを抽出する。次に、導入ＷＥＢサーバ５は、抽出したメールアドレスに対応する会員用のＷＥＢページを、クライアント装置１０に送信する（ＳＴ９４１２７）。なお、会員用ＷＥＢページは、抽出されたメールアドレスのユーザに対応するユーザの固有な情報を含む。次に、クライアント装置１０は、会員用のＷＥＢページを、導入ＷＥＢサーバ５から受信する。次に、クライアント装置１０は、受信した会員用のＷＥＢページを、表示装置に表示する（ＳＴ９４１２８）。
【００９６】
前述の通り、従来のＷＥＢサーバである導入ＷＥＢサーバ５は、クライアント装置１０に送信するログイン用のＷＥＢページに、認証サイト情報を含めるだけで、本発明の個人認証方法を導入できる。
【００９７】
前述した実施形態では、メール認証専用ＷＥＢ装置９４３は、ユーザ管理テーブル３４２を記憶している。しかし、メール認証専用ＷＥＢ装置９４３は、必ずしも、ユーザ管理テーブル３４２を記憶している必要はない。この場合、導入ＷＥＢサーバ５が、ユーザ管理テーブル３４２を記憶する。この場合、ステップＳＴ１２３において、メール認証専用ＷＥＢ装置９４３は、抽出した送信元メールアドレス３４１３がユーザ管理テーブル３４２のメールアドレス３４２２に格納されているか否かを判定する必要がない。その代わりに、導入ＷＥＢサーバ５は、クライアント装置１０から受信する会員用のＷＥＢページの要求に含まれるメールアドレスが、ユーザ管理テーブル３４２に格納されているか否かを判定する。
【００９８】
前述した実施形態では、導入ＷＥＢサーバ５は、クライアント装置１０から受信する会員用のＷＥＢページの要求に含まれるメールアドレスを信頼して、会員用のＷＥＢページを送信する。しかし、会員用のＷＥＢページの要求に含まれるメールアドレスは、偽造されことがある。そこで、導入ＷＥＢサーバ５は、ｒｅｆｅｒｅｒを参照することによって、リンク元がメール認証専用ＷＥＢ装置９４３であることを確認してもよい。
【００９９】
（第４の実施形態）
以下で第４の実施形態の個人認証システムについて説明するが、第３の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１００】
インターネット上の電子商取引では、決済手段として、クレジットカードが用いられることが多い。第４の実施形態では、第３の実施形態の個人認証システムを、インターネット上のクレジットカード決済に応用する例を説明する。
【０１０１】
第４の実施形態の個人認証システムの概略の構成図は、第３の実施形態の個人認証システムの概略の構成図（図１１）と同一なので、詳細の説明は省略する。クライアント装置１０は、クレジットカード決済を実行しようとするユーザによって操作される。携帯電話６０は、クレジットカード決済を実行しようとするユーザによって操作される。導入ＷＥＢサーバ５は、物品販売又はサービス販売等の電子商取引を提供するＷＥＢサーバである。メール認証専用ＷＥＢ装置９４３は、クレジットカードの与信審査及び課金を処理するＷＥＢ装置である。メール認証専用ＷＥＢ装置９４３のユーザ管理テーブル３４２は、クレジットカード番号（図示省略）を含む。ユーザ管理テーブルに含まれるクレジットカード番号は、ユーザのクレジットカードの番号である。ユーザ管理テーブル３４２には、クレジットカード番号と当該クレジットカードを所有するユーザの電子メールアドレスとが対応付けて記憶されている。
【０１０２】
第４の実施形態の個人認証方法の処理の概要を説明する。導入ＷＥＢサーバ５は、ユーザの操作を契機に、決済金額を確定する。決済金額の確定方法は、従来の電子商取引のサイトで採用されている方法でよい。次に、クライアント装置１０は、ユーザの操作を契機に、ログイン用のＷＥＢページの要求に代えて、決済用のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。導入ＷＥＢサーバ５は、決済用のＷＥＢページの要求を受信する。すると、導入ＷＥＢサーバ５は、要求された決済用のＷＥＢページを生成する。次に、導入ＷＥＢサーバ５は、生成した決済用のＷＥＢページを、クライアント装置１０に送信する。導入ＷＥＢサーバ５によって生成される決済用のＷＥＢページは、認証サイト情報を含む。認証サイト情報は、戻先ＵＲＬだけではなく、決済金額を含む。クライアント装置１０は、決済用のＷＥＢページを受信する。次に、クライアント装置１０は、受信した決済用のＷＥＢページに含まれる認証サイト情報に基づいて、認証用メールアドレス取得要求をメール認証専用ＷＥＢ装置９４３に送信する。メール認証専用ＷＥＢ装置９４３は、認証用メールアドレス取得要求を受信する。次に、メール認証専用ＷＥＢ装置９４３は、受信した認証要求から戻先ＵＲＬ及び決済金額を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、認証用メールアドレスを生成する。次に、メール認証専用ＷＥＢ装置９４３は、生成した認証用メールアドレス、抽出した戻先ＵＲＬ及び抽出した決済金額を、クライアント装置１０に送信する。クライアント装置１０は、認証用メールアドレス、戻先ＵＲＬ及び決済金額を受信する。次に、クライアント装置１０は、認証用メールアドレス宛てに、電子メールを送信する。これによって、クライアント装置１０は、電子メールをメール認証専用ＷＥＢ装置９４３に送信する。メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から電子メールを受信する。すると、メール認証専用ＷＥＢ装置９４３は、受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、メール認証専用ＷＥＢ装置９４３は、取得した送信先のメールアドレスと、取得した送信元のメールアドレスと、を対応付けて、メールアドレス対応テーブル３４１に記憶する。一方で、クライアント装置１０は、認証用メールアドレス、戻先ＵＲＬ及び決済金額を含む認証要求を、メール認証専用ＷＥＢ装置９４３に送信する。メール認証専用ＷＥＢ装置９４３は、クライアント装置１０から、認証要求を受信する。メール認証専用ＷＥＢ装置９４３は、受信した認証要求から、認証用メールアドレス、戻先ＵＲＬ及び決済金額を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証専用ＷＥＢ装置９４３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出した送信先メールアドレス３４１３に対応するクレジットカード番号を、ユーザ管理テーブル３４２から抽出する。次に、メール認証専用ＷＥＢ装置９４３は、抽出したクレジットカード番号で、抽出した決済金額を利用可能か否かを判定することによって、与信審査を行う。ここでの与信審査は、従来のクレジットカード利用時の与信審査と同様である。メール認証専用ＷＥＢ装置９４３は、与信審査が良好であると、クレジットカードに決済金額を課金する。メール認証専用ＷＥＢ装置９４３は、与信審査処理及び課金処理を、与信審査処理及び課金処理を専用に行う装置に依頼してもよい。メール認証専用ＷＥＢ装置９４３は、課金処理を完了すると、認証の結果を認証可能と判定する。メール認証専用ＷＥＢ装置９４３は、認証の結果を、クライアント装置１０に送信する。クライアント装置１０は、受信した認証の結果に基づいて、決済終了のＷＥＢページの要求を、導入ＷＥＢサーバ５に送信する。導入ＷＥＢサーバ５は、クライアント装置１０から、決済終了のＷＥＢページの要求を受信する。次に、導入ＷＥＢサーバ５は、ＷＥＢページの要求から、ユーザのメールアドレスを抽出する。次に、導入ＷＥＢサーバ５は、抽出したメールアドレスに対応する決済終了のＷＥＢページを、クライアント装置１０に送信する。なお、決済終了のＷＥＢページは、抽出されたメールアドレスに対応するユーザの固有な情報を含む。
【０１０３】
前述の通り、第３の実施形態の個人認証システムは、クレジットカードの決済に、応用することができる。なお、第４の実施形態では、クレジットカード決済について説明したが、決済手段は、認証を経て決済する手段であればなんであってもよい。例えば、決済手段には、「Ｅｄｙ」（商標）、「ジェイデビット」（商標）又は「ケータイ払いサービス」（商標）等がある。「Ｅｄｙ」（商標）は、店舗やインターネット上で利用可能な電子マネーである。「ジェイデビット」（商標）は、店舗やインターネット上で利用可能な預金口座引き落としの決済サービスである。「ケータイ払いサービス」（商標）は、決済金額が携帯電話料金の請求に合算される、インターネット上で利用可能な後払いの決済サービスである。
【０１０４】
ここで、第４の実施形態の個人認証システムの変形例を説明する。第４の実施形態の個人認証システムに備わるメール認証専用ＷＥＢ装置９４３は、電子メールの送信元に基づいて、クレジットカード番号を特定した。そのため、電子メールの送信元が偽装された場合は、なりすましのユーザによって決済されてしまう。なりすましの決済を防止するために、ユーザは、クレジットカード番号をクライアント装置１０に入力する。クライアント装置１０は、入力されたクレジットカード番号をメール認証専用ＷＥＢ装置９４３に送信する。なお、クライアント装置１０は、入力されたクレジットカード番号を、認証用メールアドレス取得要求又は認証要求に含めて送信してもよい。メール認証専用ＷＥＢ装置９４３は、クレジットカード番号をクライアント装置１０から受信する。すると、メール認証専用ＷＥＢ装置９４３は、受信したクレジットカード番号とユーザ管理テーブル３４２から抽出したクレジットカード番号とを照合する。双方のクレジットカード番号が一致する場合のみ、メール認証専用ＷＥＢ装置９４３は、当該クレジットカードに対して与信審査して、課金する。なお、第９の実施の形態の変形例では、クレジットカード番号をユーザに入力させる代わりに、暗証番号等の他の情報を入力させることによって、なりすましを防止してもよい。
【０１０５】
（第５の実施形態）
以下で第５の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１０６】
図１３は、第５の実施形態の個人認証システムの概略の構成図である。図１３に示す個人認証システムは、複数のＡＴＭ（ＡＵＴＯＭＡＴＩＣ ＴＥＬＬＥＲ ＭＡＣＨＩＮＥ）２０１０、複数の携帯電話２０６０及びＡＴＭメール認証装置９２３を備える。ＡＴＭ２０１０は、認証を受け、現金を出し入れしようとするユーザによって操作されるＡＵＴＯＭＡＴＩＣ ＴＥＬＬＥＲ ＭＡＣＨＩＮＥである。ＡＴＭ２０１０はネットワーク９に接続されている。ＡＴＭメール認証装置９２３は、ネットワーク９を介してＡＴＭ２０１０に接続されている。第５の実施の形態では、ネットワーク９はインターナルネットワークである。また、ネットワーク９は、複数の金融機関に設置されたＡＴＭメール認証装置を集約する中継装置を含んでもよい。また、ＡＴＭメール認証装置９２３は、インターネット１を介して携帯電話２０６０に接続されている。ＡＴＭメール認証装置９２３の構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図３）と同一なので、説明を省略する。なお、説明を明瞭にするために、第５の実施形態の個人認証システムでは、１台のＡＴＭ２０１０に対する認証処理を説明する。実際には、ＡＴＭメール認証装置９２３は、ネットワーク９を介して、複数のＡＴＭ２０１０に対する認証を行う。なお、図１３では、ＡＴＭ２０１０は、３台を図示したが、個人認証システムに何台備わっていても良い。また、携帯電話２０６０は、３台を図示したが、個人認証システムに何台備わっていてもよい。なお、個人認証システムは、携帯電話２０６０の代わりに、電子メール送信機能を備える端末を備えてもよい。
【０１０７】
図１４は、第５の実施形態の個人認証システムに備わるＡＴＭ２０１０の構成のブロック図である。ＡＴＭ２０１０は、物理的には、送受信部１１、中央処理装置１２、主記憶装置１３、補助記憶装置１４、入力装置（図示省略）、表示装置（図示省略）及び現金取扱部１５等を備えたＡＴＭ（ＡＵＴＯＭＡＴＩＣ ＴＥＬＬＥＲ ＭＡＣＨＩＮＥ）である。送受信部１１は、ネットワーク９に接続され、外部の装置（ＡＴＭメール認証装置９２３）とデータを送受信するインタフェースである。中央処理装置１２は、例えば、ＣＰＵである。中央処理装置１２は、主記憶装置１３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置１３は、例えば、メモリである。主記憶装置１３は、中央処理装置１２によって実行されるプログラム及び中央処理装置１２によって必要とされる情報等が記憶される。補助記憶装置１４は、例えば、ハードディスクである。補助記憶装置１４は、各種情報を記憶する。入力装置は、例えば、キーボード又はタッチパネルである。入力装置には、ユーザから各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置１２から表示を指示された情報が表示される。現金取扱部１５は、紙幣及び貨幣を物理的に管理する。更に、現金取扱部１５は、紙幣及び貨幣を入出金する。現金取扱部１５は、一般的な金融機関のＡＴＭに備えられているものでよい。
【０１０８】
ＡＴＭ２０１０の機能は、現金取扱部１５を除いて、第１の実施形態の個人認証システムに備わるクライアント装置１０と同一なので、説明を省略する。
【０１０９】
携帯電話２０６０は、インターネット接続機能を搭載する。よって、携帯電話２０６０は、ネットワーク９を介して、ＡＴＭメール認証装置９２３へ電子メールを送信する。
【０１１０】
第５の実施形態のＡＴＭメール認証装置９２３の機能構成は、第１の実施形態の個人認証システムに備わるメール認証装置３（図４）と同一なので、説明を省略する。
【０１１１】
なお、ＡＴＭメール認証装置９２３の補助記憶装置に記憶されているユーザ管理テーブル３４２には、ユーザＩＤに対応してユーザの固有な情報が格納される。本実施の形態におけるユーザの固有な情報は、金融機関の口座情報である。金融機関の口座情報は、口座番号、預金残高、借入金残高及び借入可能残高等を含む。ただし、ユーザの固有な情報は、必ずしもユーザ管理テーブル３４２によって管理されている必要はなく、ユーザＩＤに対応して管理されていればいかなる方法であってもよい。ユーザの固有な情報の管理方法は、サービスの種類及び利用者の規模に応じて、本発明の実施者に委ねられる。ユーザＩＤに対応するユーザの固有な情報の一部は、ＡＴＭメール認証装置９２３からＡＴＭ２０１０へ送信される認証の結果に含まれる。
【０１１２】
次に、第５の実施形態の個人認証方法について説明する。第５の実施形態の個人認証方法の処理は、第１の実施形態の個人認証方法（図７）と同一なので、説明を省略する。但し、ここでは、第５の実施形態の個人認証方法の特徴的なステップを説明する。
【０１１３】
第５の実施形態におけるＳＴ１１８について説明する。電子メールを送信する装置は、ＡＴＭ２０１０ではなく、第二のクライアント装置である携帯電話２０６０である。携帯電話２０６０は、ユーザの操作を契機に、電子メールを、ＡＴＭメール認証装置９２３に送信する。
【０１１４】
第５の実施形態におけるＳＴ１２４について説明する。ＡＴＭメール認証装置９２３の認証結果送信モジュール３３９は、認証の結果を、ネットワーク９を介して、ＡＴＭ２０１０に送信する。認証の結果は、ユーザＩＤに対応する口座番号、預金残高、借入金残高又は借入可能残高等のユーザの固有な情報を含む。
【０１１５】
ＳＴ１２４に引き続き、ＡＴＭ２０１０は、ＡＴＭメール認証装置９２３から受信した認証の結果及びユーザの固有な情報を表示装置に表示する。ＡＴＭ２０１０のユーザは、表示された情報に基づいて、後続の操作を実行する。後続の操作とは、例えば、預金の引き出し、借入金の返済又は借入金の借り入れである。
【０１１６】
ところで、一般的なＡＴＭは、預金の引き出し、借入金の返済及び借入金の借り入れ等の種々の操作を受け付けることができる。そこで、ＳＴ１１１に先立って、ＡＴＭ２０１０は、ユーザから操作の種類を受け付ける。ＡＴＭ２０１０は、ＡＴＭメール認証装置９２３へ送信する認証用メールアドレス取得要求に、ユーザが求める操作の種類を含める。ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０から受信する認証用メールアドレス取得要求から、ＡＴＭ２０１０のユーザが求める操作の種類を抽出する。そして、ＡＴＭメール認証装置９２３は、抽出した操作の種類に基づいて、認証の結果に含めるユーザの固有な情報を決定する。
【０１１７】
また、次のような手順であってもよい。一般的なＡＴＭは、預金の引き出し、借入金の返済及び借入金の借り入れ等の種々の操作を受け付けることができる。ここでは、ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザから受け付け可能な操作をユーザＩＤに対応して予め記憶しておく。この場合、ＡＴＭ２０１０は、認証要求の送信の前に、ユーザから操作の種類を受け付けない。まず、ＡＴＭ２０１０は、第５の実施形態の個人認証方法によって、認証を受ける。ＡＴＭメール認証装置９２３は、認証したユーザＩＤに対応する受け付け可能な操作を、認証の結果に含めて、ＡＴＭ２０１０に送信する。ＡＴＭ２０１０は、ＡＴＭメール認証装置９２３から受信した認証の結果及び受け付け可能な操作を表示装置に表示する。ＡＴＭ２０１０のユーザは、ＡＴＭ２０１０の表示装置に表示された操作の種類の中から、操作を選択する。すると、ＡＴＭ２０１０は、選択された種類の操作を実行する。
【０１１８】
なお、第５の実施形態の個人認証方法は、従来のキャッシュカード及び暗証番号による個人認証方法と組み合わせてもよい。これによって、キャッシュカード及び暗証番号が盗まれても、ユーザのメールアドレスによって電子メールが送信されない限り、なりすましのユーザによって預金が引き出されることがない。また、第５の実施形態の個人認証方法は、キャッシュカード又は暗証番号の一方による個人認証と組み合わせてもよい。
【０１１９】
ここで、本発明の第５の実施形態の変形例を説明する。第５の実施形態では、ＡＴＭメール認証装置９２３は、認証用メールアドレスを生成し、ＡＴＭ２０１０に送信する。しかし変形例では、ＡＴＭ２０１０が、自身のＡＴＭ＿ＩＤを含む認証用メールアドレスを生成してもよい。ＡＴＭ＿ＩＤは、ＡＴＭ２０１０の一意な識別子である。ＡＴＭメール認証装置９２３は、携帯電話２０６０から電子メールを受信すると、受信した電子メールの送信の送信先アドレスからＡＴＭ＿ＩＤを抽出する。そして、ＡＴＭメール認証装置９２３は、抽出したＡＴＭ＿ＩＤによって識別されるＡＴＭ２０１０に認証の結果を送信する。つまり、ＡＴＭメール認証装置９２３は、認証要求をＡＴＭ２０１０から受信しなくても、認証の結果を送信できる。
【０１２０】
ここで、本発明の第５の実施形態の応用例を説明する。第５の実施形態の応用例の個人認証システムに備わるＡＴＭメール認証装置９２３は、公共料金の料金を計算する装置を兼ねる。この場合、ＡＴＭメール認証装置９２３は、公共料金を計算し、請求書を発行し、支払状況を管理する。例えば、公共料金は、電話料金、携帯電話料金、電気料金、ガス料金又は水道料金等である。ＡＴＭメール認証装置９２３は、携帯電話２０６０のメールアドレスと、公共料金のサービスを受けるユーザの識別子とを、対応付けて記憶する。ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザに貸付金を貸し付ける場合、貸付金を公共料金の請求に合算して請求する。また、ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザから、公共料金の支払いの要求を受け付ける。ＡＴＭメール認証装置９２３は、前述したようにＡＴＭ２０１０のユーザを認証すると、携帯電話２０６０のユーザの未払分の公共料金の支払いをＡＴＭ２０１０から受け付ける。また、ＡＴＭメール認証装置９２３は、ＡＴＭ２０１０のユーザから、貸付金の貸し出しの要求を受け付ける。ＡＴＭメール認証装置９２３は、前述したようにＡＴＭ２０１０のユーザを認証すると、貸付金をＡＴＭ２０１０から貸し出す。なお、ＡＴＭメール認証装置９２３は、貸付金を公共料金の請求に合算して請求する。
【０１２１】
また、本発明の第５の実施の形態では、重複しない認証用メールアドレスを、すべてのＡＴＭ２０１０のそれぞれに予め割り当てておいてもよい。この場合、ＡＴＭ２０１０と認証用メールアドレスとの対応は、不変である。そして、ＡＴＭメール認証装置９２３は、送信先のメールアドレスに基づいて、ユーザの認証要求の送信元のＡＴＭ２０１０を特定できる。
【０１２２】
（第６の実施形態）
以下で第６の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システム及び第５の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１２３】
第６の実施形態の個人認証システムとして、第１の実施形態の個人認証システムを、店舗でのクレジットカード決済に用いる具体的な実施形態について説明する。従来、店舗のクレジットカード決済では、なりすましの利用を防止するために、店舗の販売員が、利用伝票の署名とクレジットカード裏面の署名とを目視で照合する。しかし、目視の照合は、なりすまし防止策としては、不十分である。第６の実施形態の個人認証システムでは、署名の照合の代わりに、電子メールアドレスを用いる実施例を説明する。
【０１２４】
図１５は、第６の実施形態の個人認証システムの概略の構成図である。図１５に示す個人認証システムは、複数のリーダ装置２１１０、複数の携帯電話６０及びメール認証装置３を備える。リーダ装置２１１０は、ネットワーク９に接続されている。メール認証装置３は、インターネット１を介して携帯電話６０に接続されている。リーダ装置２１１０は、クレジットカード情報を読み取るための装置である。リーダ装置２１１０については、図１６で詳細を説明する。店舗では、通常は、店舗の販売員がリーダ装置２１１０を操作する。しかし、第６の実施形態の個人認証システムにおいて認証を受けるユーザは、クレジットカードの保有者である。そこで、説明を簡単にするために、本実施形態の説明においては、リーダ装置２１１０のユーザは、クレジットカードの保有者とする。メール認証装置３は、ネットワーク９を介してリーダ装置２１１０に接続されている。メール認証装置３のブロック図は、第１の実施形態の個人認証システムが備えるメール認証装置３と同じ図３であり、説明を省略する。なお、説明を明瞭にするために、第６の実施形態の個人認証システムでは、１台のリーダ装置２１１０の認証処理を説明する。実際には、メール認証装置３は、ネットワーク９を介して、複数のリーダ装置２１１０に対する認証を行う。つまり、メール認証装置３は、複数のリーダ装置２１１０から認証要求及び認証要求を受けることができる。また、実際には、メール認証装置３は、インターネット１を介して、複数の携帯電話６０に接続されている。なお、図１５では、リーダ装置２１１０は３台を図示したが、個人認証システムに何台備わっていても良い。また、図１５では、携帯電話は３台を図示したが、個人認証システムに何台備わっていても良い。
【０１２５】
図１６は、第６の実施形態の個人認証システムに備わるリーダ装置２１１０の構成のブロック図である。リーダ装置２１１０は、物理的には、送受信部１１、中央処理装置１２、主記憶装置１３、補助記憶装置１４、入力装置（図示省略）、表示装置（図示省略）及びカード情報読取部１６等を備える。送受信部１１は、ネットワーク９に接続され、外部の装置（メール認証装置３）とデータを送受信するインタフェースである。中央処理装置１２は、例えば、ＣＰＵである。中央処理装置１２は、主記憶装置１３に記憶されているプログラムを実行することによって、各種処理を行う。主記憶装置１３は、例えば、メモリである。主記憶装置１３は、中央処理装置１２によって実行されるプログラム及び中央処理装置１２によって必要とされる情報等が記憶される。補助記憶装置１４は、例えば、ハードディスクである。補助記憶装置１４は、各種情報を記憶する。入力装置は、例えば、キーボード又はタッチパネルである。入力装置には、ユーザから各種情報が入力される。表示装置は、ディスプレイである。表示装置には、中央処理装置１２から表示を指示された情報が表示される。カード情報読取部１６とは、クレジットカードに記憶された情報を読み取る装置である。カード情報読取部１６は、一般的なクレジットカードのカードリーダに備えられているもので十分である。なお、リーダ装置２１１０は、必ずしも、補助記憶装置１４を備えている必要はない。
【０１２６】
第６の実施形態の個人認証システムが備えるリーダ装置２１１０の機能は、主に、第１の実施形態の個人認証システムが備えるクライアント装置１０と同様である。第６の実施形態の個人認証システムが備えるリーダ装置２１１０は、第１の実施形態の個人認証システムが備えるクライアント装置１０の機能に加えて、次の機能を持つ。リーダ装置２１１０は、ユーザの操作によって、クレジットカード番号及び決済金額を受け付ける。リーダ装置２１１０は、メール認証装置３に送信する認証要求に、受け付けたクレジットカード番号及び決済金額を含める。
【０１２７】
携帯電話６０は、インターネット接続機能を搭載した、携帯電話である。携帯電話６０は、インターネット１を介して、メール認証装置３へ電子メールを送信する。
【０１２８】
第６の実施形態のメール認証装置３の機能は、主に、第１の実施形態の個人認証システムと同様である。第６の実施形態のメール認証装置３は、第１の実施形態の個人認証システムが備えるメール認証装置３の機能に加えて、次の機能を持つ。第６の実施形態のメール認証装置３は、クレジットカードの与信審査及び課金を処理する。メール認証装置３のユーザ管理テーブル３４２は、クレジットカード番号（図示省略）を含む。ユーザ管理テーブル３４２に含まれるクレジットカード番号は、ユーザが所有するクレジットカードの番号である。つまり、ユーザ管理テーブル３４２には、クレジットカード番号とユーザの電子メールアドレスとが関連付けて予め記憶されている。
【０１２９】
次に、第６の実施形態の個人認証方法の処理の概要を説明する。第６の実施形態の個人認証方法のシーケンス図は、主に、第１の実施形態の個人認証方法のシーケンス図である図７と同様である。但し、電子メールを送信する装置は、リーダ装置２１１０ではなく、第二のクライアント装置である携帯電話６０である。
【０１３０】
第６の実施形態の個人認証方法の処理の概要は、以下の通りである。リーダ装置２１１０は、ユーザから決済金額を受け付ける。また、リーダ装置２１１０のカード情報読取部１６は、ユーザのカード操作によって、クレジットカード番号を読み取る。次に、リーダ装置２１１０は、受け付けた決済金額及び読み取ったクレジットカード番号を含む認証用メールアドレス取得要求を、メール認証装置３に送信する（ＳＴ１１１）。メール認証装置３は、認証要求を受信する（ＳＴ１１２）。次に、メール認証装置３は、受信した認証要求から、決済金額及びクレジットカード番号を抽出する。次に、メール認証装置３は、認証用メールアドレスを生成する（ＳＴ１１４）。次に、メール認証装置３は、生成した認証用メールアドレス、抽出した決済金額及び抽出したクレジットカード番号をリーダ装置２１１０に送信する（ＳＴ１１６）。リーダ装置２１１０は、認証用メールアドレス、決済金額及びクレジットカード番号を受信する（ＳＴ１１７）。次に、リーダ装置２１１０は、表示装置に、受信した認証用メールアドレスを表示する。なお、リーダ装置２１１０は、認証用メールアドレスを表示せずに、認証用メールアドレスが記載された紙を印刷してもよい。つまり、リーダ装置２１１０は、認証用メールアドレスをユーザに通知できれば、いかなる方法であってもよい。また、リーダ装置２１１０は、認証用メールアドレスに対応するＱＲコード等を表示又は印刷してもよい。携帯電話６０は、ユーザの操作を契機に、表示された認証用メールアドレス宛てに電子メールを送信する（ＳＴ１１８）。すると、メール認証装置３は、携帯電話６０から電子メールを受信する（ＳＴ１１９）。次に、メール認証装置３は、受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、メール認証装置３は、取得した送信先のメールアドレスと、取得した送信元のメールアドレスとを対応付けて、メールアドレス対応テーブル３４１に記憶する（ＳＴ１２０）。一方で、リーダ装置２１１０は、認証用メールアドレス、決済金額及びクレジットカード番号を含む認証要求を、メール認証装置３に送信する（ＳＴ１２１）。メール認証装置３は、リーダ装置２１１０から認証要求を受信する（ＳＴ１２２）。メール認証装置３は、受信した認証要求から、認証用メールアドレス、決済金額及びクレジットカード番号を抽出する。次に、メール認証装置３は、メールアドレス対応テーブル３４１から、抽出した認証用メールアドレスに対応する送信先メールアドレス３４１３を抽出する（ＳＴ１２３）。具体的には、メール認証装置３は、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証装置３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証装置３は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。次に、メール認証装置３は、抽出したレコードから、クレジットカード番号を抽出する。次に、メール認証装置３は、メールアドレス対応テーブル３４１から抽出したクレジットカード番号と、認証要求から抽出したクレジットカード番号と、を照合する。抽出された二つのクレジットカード番号が一致しない場合、メール認証装置３は、認証不可と判定する。一方、抽出された二つのクレジットカード番号が一致する場合、メール認証装置３は、抽出した決済金額が利用可能か否かを判定する与信審査を行う。与信審査は、従来のクレジットカード利用時に行われるものと同様である。メール認証装置３は、与信審査が良好であると、クレジットカードに決済金額を課金する。なお、メール認証装置３は、与信審査及び課金処理を専用の装置に依頼してもよい。この場合、メール認証装置３は、与信審査及び課金を行う専用の装置とネットワークを介して接続される。メール認証装置３は、課金処理が完了すると、認証可能と判定する。メール認証装置３は、認証の結果を、リーダ装置２１１０に送信する（ＳＴ１２４）。リーダ装置２１１０は、認証結果を受信する（ＳＴ１２５）。次に、リーダ装置２１１０は、認証結果を、表示装置に表示する。
【０１３１】
上述の通り、第６の実施形態の個人認証システムでは、店舗でのクレジットカード決済において、署名の照合代わりに、電子メールアドレスを用いることができた。なお、第６の実施形態では、クレジットカード決済について、説明したが、決済手段は、認証を経て決済する手段であれば、なんでもよく、クレジットカードに限定されるものではない。例えば、決済手段は、「ジェイデビット」（商標）がある。
【０１３２】
上述した実施例では、リーダ装置２１１０によって送信される認証用メールドレス取得要求が、クレジットカード番号を含む。しかし、次の通りであってもよい。リーダ装置２１１０は、クレジットカード番号を、認証用メールアドレス取得要求でなく、認証要求に含めてもよい。
【０１３３】
次に、本発明の第６の実施形態の変形例を説明する。第６の実施形態の個人認証システムでは、リーダ装置２１１０は、クレジットカードの情報を読み取った。しかし、第６の実施形態の変形例では、リーダ装置２１１０によるクレジットカードの情報の読み取りがなくても、クレジットカード決済が実行できる実施例について説明する。すなわち、ユーザが、物理的にクレジットカードを保有していなくても、店舗でクレジットカード決済ができる。
【０１３４】
第６の実施形態の変形例に備わるリーダ装置２１１０が送信する認証用メールアドレス取得要求は、クレジットカード番号を含まない。
【０１３５】
第６の実施形態の変形例の処理の概要を説明する。リーダ装置２１１０は、ユーザの操作を契機に、認証用メールアドレス取得要求をメール認証装置３に送信する。メール認証装置３は、認証用メールアドレス取得要求を受信する。次に、メール認証装置３は、受信した認証用メールアドレス取得要求から、決済金額を抽出する。次に、メール認証装置３は、認証用メールアドレスを生成する。次に、メール認証装置３は、生成した認証用メールアドレス及び抽出した決済金額を、リーダ装置２１１０に送信する。リーダ装置２１１０は、認証用メールアドレス及び決済金額を受信する。次に、リーダ装置２１１０は、受信した認証用メールアドレスを表示装置に表示する。携帯電話６０は、ユーザの操作を契機に、表示された認証用メールアドレス宛てに電子メールを送信する。メール認証装置３は、携帯電話６０から電子メールを受信する。次に、メール認証装置３は、受信した電子メールから、送信元のメールアドレス及び送信先のメールアドレスを取得する。次に、メール認証装置３は、取得した送信先のメールアドレスと、取得した送信元のメールアドレスとを対応付けて、メールアドレス対応テーブル３４１に記憶する。一方、リーダ装置２１１０は、認証要求をメール認証装置３に送信する。メール認証装置３は、リーダ装置２１１０から、認証用メールアドレス及び決済金額を含む認証要求を受信する。メール認証装置３は、受信した認証要求から、認証用メールアドレス及び決済金額を抽出する。次に、メール認証装置３は、抽出した認証用メールアドレスとメールアドレス対応テーブル３４１の送信先メールアドレス３４１２とが一致するレコードを、メールアドレス対応テーブル３４１から選択する。次に、メール認証装置３は、選択したレコードから、送信元メールアドレス３４１３を抽出する。次に、メール認証装置３は、抽出した送信元メールアドレス３４１３とユーザ管理テーブル３４２のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。次に、メール認証装置３は、選択したレコードからクレジットカード番号を抽出する。次に、メール認証装置３は、抽出したクレジットカード番号に対して、与信審査を行う。与信審査は、従来のクレジットカード利用時に行われるものである。与信審査が良好であると、メール認証装置３は、クレジットカードに決済金額を課金する。なお、メール認証装置３は、与信審査及び課金処理を、専用の装置に依頼してもよい。この場合、メール認証装置３は、与信審査及び課金を行う専用の装置にネットワークを介して、接続される。メール認証装置３は、課金処理が完了すると、認証可能と判定する。メール認証装置３は、認証の結果をリーダ装置２１１０に送信する。リーダ装置２１１０は、認証結果を受信する。そして、リーダ装置２１１０は、受信した認証結果を表示装置に表示する。
【０１３６】
前述の通り、第６の実施形態の変形例では、ユーザが、店舗で、物理的にクレジットカードを保有していなくても、クレジットカード決済ができる。
【０１３７】
ここで、本発明の第６の実施形態の変形例の応用例を説明する。第６の実施形態の変形例の応用例の個人認証システムに備わるメール認証装置３は、公共料金を計算する装置を兼ねる。つまり、メール認証装置３は、公共料金を計算し、請求書を発行し、支払状況を管理する。例えば、公共料金は、電話料金、携帯電話料金、電気料金、ガス料金又は水道料金等である。第６の実施形態では、メール認証装置３のユーザ管理テーブル３４２は、携帯電話６０の電子メールアドレスとクレジットカード番号とを関連付けて記憶する。第６の実施形態の変形例の応用例では、メール認証装置３のユーザ管理テーブル３４２は、携帯電話６０の電子メールアドレスと公共料金のサービスを受けるユーザの識別子との対応を記憶する。メール認証装置３は、店舗での決済金額を、クレジットカードに課金する代わりに、公共料金に合算する。リーダ装置２１１０のユーザは、携帯電話６０を保有するだけで、店舗での支払いを済ませることができる。
【０１３８】
（第７の実施形態）
以下では、第７の実施形態の個人認証システムとして、第１の実施形態の個人認証システムで、パーソナルコンピュータ及びＰＤＡを、社内イントラネットに接続する例を説明する。第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いる。
【０１３９】
多くの企業が、社内の情報の機密性を保ちながら、従業員間の情報連絡を促すために、社内イントラネットを設ける。従業員は、出先からの社内情報の閲覧又は更新や、電子メールの送受信を目的として、パーソナルコンピュータ又はＰＤＡといったポータブル端末を、ダイヤルアップやＶＰＮといった通信手段によって、社内イントラネットに接続する。従来、従業員は、ユーザＩＤ及びパスワードを入力して、社内イントラネットに接続する。パーソナルコンピュータ又はＰＤＡのユーザは、第１の実施形態の認証方法を用いて、認証を受け、ポータブル端末を、社内イントラネットに接続する。この場合、クライアント装置１０は、社内のイントラネットに接続されようとするポータブル端末である。また、メール認証装置３は、社内のイントラネットを管理する管理サーバである。従業員は、ユーザＩＤ及びパスワードを入力せずに、社内イントラネットに接続できる。なお、ポータブル端末と異なる第２のクライアント装置を用いてメール認証装置３に電子メールを送信することによって、更に、セキュリティを高めることができる。この場合、ポータブル端末を社内イントラに接続しようとするユーザは、ポータブル端末及びユーザメールアドレスを送信元とする電子メールを送信可能な第２のクライアント装置の両方がなければ、個人認証を受けることができない。これによって、ポータブル端末だけを取得した他人は、当該ポータブル端末のユーザに成り済まして、認証を受けることができない。つまり、ポータブル端末を紛失したとしても、情報流出を防ぐことができる。
【０１４０】
（第８の実施形態）
以下では、第８の実施形態の個人認証システムとして、第１の実施形態の個人認証システムで、シンクライアント（ＴＨＩＮ ＣＬＩＥＮＴ）装置を社内サーバに接続する例を説明する。第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いる。
【０１４１】
シンクライアント装置は、必要最低限の補助記憶装置を備えたパーソナルコンピュータである。企業は、パーソナルコンピュータの盗難又は紛失による、情報流出を防止するために、シンクライアントシステムを導入している。シンクライアント装置の補助記憶装置は、十分な社内データ及びアプリケーションを記憶しない。社内データ及びアプリケーションは、集中サーバによって記憶される。従業員は、シンクライアント装置を操作して集中サーバに接続し、社内データを閲覧、更新する。従来であれば、従業員は、ユーザＩＤ及びパスワードを入力して、集中サーバに接続する。シンクライアント装置のユーザは、第１の実施形態の認証方法を用いて、認証を受け、シンクライアント装置を、社内イントラネットに接続する。この場合、クライアント装置１０は、集中サーバに接続されようとするシンクライアント装置である。また、メール認証装置３は、シンクライアント装置とサーバの接続を管理する管理サーバである。管理サーバは、集中サーバに含まれていてもよい。従業員は、ユーザＩＤ及びパスワードを入力せずに、シンクライアント装置を、集中サーバに接続できる。
【０１４２】
（第９の実施形態）
以下では、第９の実施形態の個人認証システムとして、第１の実施形態の個人認証システムで、パーソナルコンピュータ及びＰＤＡを公衆無線ＬＡＮに接続する例を説明する。第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いる。
【０１４３】
出先で、インターネットに接続する公衆無線ＬＡＮが、普及している。従来、公衆無線ＬＡＮのユーザは、ユーザＩＤ及びパスワードを入力して、パーソナルコンピュータ及びＰＤＡといったポータブル端末を、公衆無線ＬＡＮのアクセスポイントに接続する。公衆無線ＬＡＮのユーザは、第１の実施形態の認証用法を用いて、認証を受け、ポータブル端末を、アクセスポイントに接続する。この場合、クライアント装置１０は、アクセスポイントに接続されようとするポータブル端末である。また、メール認証装置３は、ポータブル端末とアクセスポイントとの接続を管理する管理サーバである。公衆無線ＬＡＮのユーザは、ユーザＩＤ及びパスワードを入力せずに、アクセスポイントに接続できる。
【０１４４】
（第１０の実施形態）
以下で第１０の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１４５】
第１の実施形態の個人認証システムでは、メール認証装置３が、認証用メールアドレスを生成する。しかし、第１０の実施形態の個人認証システムでは、クライアント装置１０が、認証要求ＩＤを生成する。第１０の実施形態の個人認証システムは、第１〜第９の個人認証システムのいずれにも適用できる。ここでは、第１の実施形態の認証システムに適用した場合を説明する。
【０１４６】
第１０の実施形態のクライアント装置１０について説明する。クライアント装置１０は、ユーザの操作によって、認証用メールアドレス生成情報取得要求をメール認証装置３に送信する。すると、クライアント装置１０は、認証用メールアドレス生成情報を、メール認証装置３から受信する。認証用メールアドレス生成情報は、クライアント装置１０が認証用メールアドレスを生成するための情報である。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔで記述されたクライアントサイドプログラムである。なお、認証用メールアドレス生成情報は、メール認証装置３が電子メールを受信可能なドメインを含む。クライアント装置１０は、受信した認証用メールアドレス生成情報に基づいて、認証用メールアドレスを生成する。例えば、クライアント装置１０は、時刻及び乱数のうち少なくとも一方を用いて、認証用メールアドレスを生成する。なお、生成される認証用メールアドレスは、一意でなければならない。そこで、クライアント装置１０によって生成される認証用メールアドレスの文字列の数は、メール認証装置３が所定の時間内に認証するユーザの数に応じて、十分な長さとする。
【０１４７】
クライアント装置１０は、ユーザの操作を契機に、電子メールを、認証用メールアドレスに送信する。
【０１４８】
クライアント装置１０は、認証用メールアドレスを含む認証要求を、メール認証装置３に送信する。なお、認証要求は、認証用メールアドレスの全部を含んでいてもよいし、認証用メールアドレスの一部を含んでいてもよい。なお、クライアント装置１０は、ユーザの操作を契機に認証要求を送信してもよいし、一定時間ごとに認証要求を送信してもよい。
【０１４９】
クライアント装置１０は、認証結果をメール認証装置３から受信する。
【０１５０】
次に、第１０の実施形態のメール認証装置３について説明する。図１７は、第１０の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１０の実施形態の認証プログラム３００が記憶されている。第１０の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証用メールアドレス生成情報取得要求受信モジュール３３２５、認証要求受信モジュール３３２２、認証用メールアドレス生成情報送信モジュール３３５３、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【０１５１】
認証要求受信モジュール３３２２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９は、第１１の実施形態のメール認証装置３に備わるものと同一なので、説明を省略する。
【０１５２】
メインモジュール３３１は、認証用メールアドレス生成情報取得要求受信モジュール３３２５、認証要求受信モジュール３３２２、認証用メールアドレス生成情報送信モジュール３３５３、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【０１５３】
認証用メールアドレス生成情報取得要求受信モジュール３３２５は、クライアント装置１０から認証用メールアドレス生成情報取得要求を受信する。認証用メールアドレス生成情報取得要求受信モジュール３３２５は、認証用メールアドレス生成情報取得要求を受信すると、認証用メールアドレス生成情報送信モジュール３３５３に、認証用メールアドレス生成情報の送信を依頼する。
【０１５４】
認証用メールアドレス生成情報送信モジュール３３５３は、認証用メールアドレス生成情報を、クライアント装置１０に送信する。
【０１５５】
次に、第１０の実施形態の個人認証方法の処理について図を用いて説明する。図１８は、第１０の実施形態の個人認証方法の処理のシーケンス図である。
【０１５６】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤ取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ２１１）。
【０１５７】
すると、認証用メールアドレス生成情報取得要求受信モジュール３３２５は、クライアント装置１０から認証用メールアドレス生成情報取得要求を受信する（ＳＴ２１２）。すると、認証用メールアドレス生成情報取得要求受信モジュール３３２５は、認証用メールアドレス生成情報送信モジュール３３５３に、認証用メールアドレス生成情報の送信を依頼する。
【０１５８】
認証用メールアドレス生成情報送信モジュール３３５３は、依頼を受けると、認証用メールアドレス生成情報を、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２１４）。
【０１５９】
クライアント装置１０は、メール認証装置３から認証用メールアドレス生成情報を受信する（ＳＴ２１６）。
【０１６０】
次に、クライアント装置１０は、受信した認証用メールアドレス生成情報取得に基づいて、認証用メールアドレスを生成する（ＳＴ２１７）。
【０１６１】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、生成した認証用メールアドレスへ電子メールを送信する（ＳＴ２１８）。
【０１６２】
以降のステップは、第１の実施形態の個人認証システムと同様のため説明を省略する。
【０１６３】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【０１６４】
（第１１の実施の形態）
以下で第１１の実施形態の個人認証システムについて説明するが、第１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１６５】
第１１の実施形態の個人認証システムは、認証用メールアドレスの代わりに、認証要求ＩＤ又はクライアントＩＤを用いる。なお、認証要求ＩＤは、認証要求の一意な識別子である。また、クライアントＩＤは、クライアント装置１０の一意な識別子である。なお、第１１の実施形態の個人認証システムは、第１〜第１０の個人認証システムのいずれにも適用できる。ここでは、第１の実施形態の認証システムに適用した場合を説明する。
【０１６６】
図１９は、第１１の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１１の実施形態の認証プログラム３００が記憶されている。第１１の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証要求ＩＤ取得要求受信モジュール３３２３、認証要求受信モジュール３３２２、認証要求ＩＤ生成モジュール３３３、認証要求ＩＤ送信モジュール３３５１、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【０１６７】
メインモジュール３３１は、認証要求ＩＤ取得要求受信モジュール３３２３、認証要求受信モジュール３３２２、認証要求ＩＤ生成モジュール３３３、認証要求ＩＤ送信モジュール３３５１、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【０１６８】
認証要求ＩＤ取得要求受信モジュール３３２３は、クライアント装置１０から認証要求ＩＤ取得要求を受信する。認証要求ＩＤ取得要求受信モジュール３３２３は、認証要求ＩＤ取得要求を受信すると、認証要求ＩＤ生成モジュール３３３に認証要求ＩＤの生成を依頼する。
【０１６９】
認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【０１７０】
認証要求ＩＤ生成モジュール３３３は、認証要求ＩＤ取得要求受信モジュール３３２３から依頼を受けると、認証要求ＩＤを生成する。認証要求ＩＤは、認証要求の一意な識別子である。例えば、認証要求ＩＤ生成モジュール３３３は、乱数、アプリケーションＩＤ及び認証要求ＩＤの生成時刻等に基づいて、認証要求ＩＤを生成する。なお、アプリケーションＩＤは、当該メール認証装置３にインストールされている認証プログラム３００の一意な識別子である。なお、アプリケーションＩＤは、一般的にライセンスキーとして知られているものであり、詳細な説明は省略する。なお、認証要求ＩＤの生成方法は、その目的を達成する限り他の方法を用いてもよい。続いて、認証要求ＩＤ生成モジュール３３３は、生成した認証要求ＩＤを認証要求ＩＤ送信モジュール３３５１に引き渡す。
【０１７１】
仮に、メール認証装置３は、認証要求ＩＤ取得要求を複数のクライアント装置１０から同時に受信すると、受信したそれぞれの認証要求ＩＤ取得要求ごとに異なる認証要求ＩＤを生成する。また、メール認証装置３は、第１の認証要求ＩＤ取得要求を受信した後に、当該第１の認証要求の送信元であるクライアント装置１０から第２の認証要求ＩＤ取得要求を受信してもよい。この場合、メール認証装置３は、第１の認証要求ＩＤ取得要求に対して生成された認証要求ＩＤと異なる認証要求ＩＤを生成する。これによって、メール認証装置３は、同一のクライアント装置１０から送信される複数の認証要求を同時に処理できる。
【０１７２】
認証要求ＩＤ送信モジュール３３５１は、認証要求ＩＤ生成モジュール３３３から引き受けた認証要求ＩＤ及びメール認証装置が受信可能なメールアドレスを、クライアント装置１０に送信する。
【０１７３】
メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する。なお、メール受信モジュール３３６は、クライアント装置１０以外から電子メールを受信してもよい。なお、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。なお、送信元のメールアドレスの偽装は、いかなる方法で判定されてもよい。
【０１７４】
受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び認証要求ＩＤを取得する。例えば、受信メール読取モジュール３３７は、電子メールの本文又は件名から、認証要求ＩＤを取得する。続けて、受信メール読取モジュール３３７は、認証要求ＩＤ対応テーブル３４１１（図２０）に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信先メールアドレスに３４１２に、電子メールから取得した送信先メールアドレスを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１３に、電子メールから取得した送信元メールアドレスを格納する。
【０１７５】
図２０は、第１１の実施形態のメール認証装置３の補助記憶装置３４に記憶されている認証要求ＩＤ対応テーブル３４１１の構成図である。認証要求ＩＤ対応テーブル３４１１は、認証要求ＩＤ３４１１２及び送信元メールアドレス３４１１３を含む。認証要求ＩＤ３４１１２は、当該メール認証装置３が受信した電子メールに含まれる認証要求ＩＤである。送信元メールアドレス３４１１３は、当該メール認証装置３が受信した電子メールの送信元メールアドレスである。なお、本実施の形態では、認証要求ＩＤ３４１１２は、メール認証装置３と接続される多数のクライアント計算機１０の中から、認証を要求するユーザによって操作されるクライアント計算機１０を特定するために使用される。また、送信元メールアドレス３４１１３は、認証を要求するユーザを特定するために使用される。
【０１７６】
認証モジュール３３８は、認証要求ＩＤを含む認証要求をクライアント装置１０から受信する。なお、クライアント装置１０は、認証要求と共に、当該認証要求を識別する認証要求ＩＤをメール認証装置３に通知できればいかなる方法であってもよい。例えば、認証要求を送信するための通信のセッションＩＤが、認証要求ＩＤを含んでいてもよい。セッションＩＤは、ＷＥＢサーバとＷＥＢブラウザとの間の通信を識別する識別子である。セッションＩＤの生成及び管理は、通常のＷＥＢサーバ及び通常のＷＥＢブラウザの機能である。したがって、セッションＩＤの詳細な説明は、省略する。
【０１７７】
続けて、認証モジュール３３８は、受信した認証要求から認証要求ＩＤを取得する。次に、認証モジュール３３８は、取得した認証要求ＩＤと認証要求ＩＤ対応テーブル３４１１の認証要求ＩＤ３４１１２とが一致するレコードを、認証要求ＩＤ対応テーブル３４１１から選択する。これによって、認証モジュール３３８は、別個の通信である認証要求と電子メールとの対応を把握する。つまり、認証モジュール３３８は、メール受信モジュール３３６が受信した電子メールの中から、受信した認証要求に対応する電子メールを特定する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１１３を抽出する。つまり、認証モジュール３３８は、受信した認証要求に対応する電子メールの送信元アドレスを特定する。認証モジュール３３８は、送信元メールアドレス３４１１３を抽出できない場合、認証不可と判定する。
【０１７８】
次に、認証モジュール３３８は、抽出した送信元メールアドレス３４１１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する。認証モジュール３３８は、メールアドレスが一致するレコードを選択できない場合は、認証不可と判定する。一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できる場合は、認証可能と判定する。そして、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元の計算機を操作するユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、認証要求の発行元の計算機が、抽出したユーザＩＤ３４２１によって識別されるユーザによって操作されていると判断する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【０１７９】
認証結果送信モジュール３３９は、認証モジュール３３８が判定した認証結果を、クライアント装置１０に送信する。なお、認証モジュール３３８が認証可能と判定した場合、認証結果送信モジュール３３９は、ユーザＩＤ３４２１に対応するユーザの固有な情報を付随した認証結果を送信してもよい。
【０１８０】
次に、第１１の実施形態の個人認証方法の処理について図を用いて説明する。図２１は、第１１の実施形態の個人認証方法の処理のシーケンス図である。
【０１８１】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤ取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ２１１）。
【０１８２】
すると、認証要求ＩＤ取得要求受信モジュール３３２３は、クライアント装置１０から認証要求ＩＤ取得要求を受信する（ＳＴ２１２）。次に、認証要求ＩＤ取得要求受信モジュール３３２３は、認証要求ＩＤ生成モジュール３３３に、認証要求ＩＤの生成を依頼する。
【０１８３】
認証要求ＩＤ生成モジュール３３３は、認証要求ＩＤの生成の依頼を受けると、認証要求ＩＤを生成する（ＳＴ２１４）。次に、認証要求ＩＤ生成モジュール３３３は、生成した認証要求ＩＤを、認証要求ＩＤ送信モジュール３３５１に引き渡す。
【０１８４】
認証要求ＩＤ送信モジュール３３５１は、認証要求ＩＤを、認証要求ＩＤ生成モジュール３３３から引き受ける。次に、認証要求ＩＤ送信モジュール３３５１は、引き受けた認証要求ＩＤ及びメール認証装置３が受信可能なメールアドレスを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２１６）。
【０１８５】
クライアント装置１０は、メール認証装置３から認証要求ＩＤ及びメールアドレスを受信する（ＳＴ２１７）。
【０１８６】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、認証要求ＩＤを含む電子メールを送信する（ＳＴ２１８）。なお、電子メールの送信先メールアドレスは、メール認証装置３から受信したメールアドレスであり、メール認証装置３が受信可能なメールアドレスである。また、電子メールに含まれる認証要求ＩＤは、本文又は件名のいずれに記載されていてもよい。更に、電子メールに含まれる認証要求ＩＤは、暗号化されていてもよい。
【０１８７】
すると、メール受信モジュール３３６は、クライアント装置１０から電子メールを受信する（ＳＴ２１９）。このとき、メール受信モジュール３３６は、当該受信した電子メールの送信元のメールアドレスが偽装されたか否かを判定してもよい。そして、送信元のメールアドレスが偽装されていないとメール受信モジュール３３６が判定した場合のみ、受信メール読取モジュール３３７が処理を行う。
【０１８８】
続いて、受信メール読取モジュール３３７は、メール受信モジュール３３６が受信した電子メールから、送信元のメールアドレス及び認証要求ＩＤを取得する。次に、受信メール読取モジュール３３７は、認証要求ＩＤ対応テーブル３４１１に新たなレコードを作成する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの認証要求ＩＤ３４１１２に、取得した認証要求ＩＤを格納する。次に、受信メール読取モジュール３３７は、作成した新たなレコードの送信元メールアドレス３４１１３に、取得した送信元メールアドレスを格納する（ＳＴ２２０）。
【０１８９】
一方で、クライアント装置１０は、認証要求ＩＤを含む認証要求を、ネットワーク９を介して、メール認証装置３に送信する（ＳＴ２２１）。なお、認証要求に含まれる認証要求ＩＤは、暗号化されていてもよい。
【０１９０】
すると、認証要求受信モジュール３３２２は、クライアント装置１０から認証要求を受信する（ＳＴ２２２）。認証要求受信モジュール３３２２は、認証要求を受信すると、認証モジュール３３８に認証を依頼する。
【０１９１】
続けて、認証モジュール３３８は、認証の依頼を受けると、認証要求受信モジュール３３２２が受信した認証要求から認証要求ＩＤを取得する。次に、認証モジュール３３８は、取得した認証要求ＩＤと認証要求ＩＤ対応テーブル３４１１の認証要求ＩＤ３４１１２とが一致するレコードを、認証要求ＩＤ対応テーブル３４１１から選択する。続けて、認証モジュール３３８は、選択したレコードから、送信元メールアドレス３４１１３を抽出する。なお、認証モジュール３３８は、送信元メールアドレス３４１１３を抽出できない場合、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。一方、認証モジュール３３８は、抽出した送信元メールアドレス３４１１３とユーザ管理テーブル３４２（図６）のメールアドレス３４２２とが一致するレコードを、ユーザ管理テーブル３４２から選択する（ＳＴ２２３）。認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合は、認証不可と判定する。認証不可と判定すると、認証モジュール３３８は、認証結果送信モジュール３３９に、認証不可を認証結果として引き渡す。なお、第１の実施形態では、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、認証不可と判定した。しかし、認証モジュール３３８は、ユーザ管理テーブル３４２に予め登録されていないユーザを、新規のユーザとして認証してもよい。この場合、認証モジュール３３８は、メールアドレスが一致するレコードをユーザ管理テーブル３４２から抽出できない場合、新たなユーザＩＤを生成する。このとき、認証モジュール３３８は、ユーザ管理テーブル３４２に含まれるすべてのユーザＩＤ３４２１と重複しないように、ユーザＩＤを生成する。次に、認証モジュール３３８は、ユーザ管理テーブル３４２に、新たにレコードを生成する。次に、認証モジュール３３８は、生成したユーザＩＤを、生成した新たなレコードのユーザＩＤ３４２１に格納する。更に、認証モジュール３３８は、抽出した送信元メールアドレス３４１１３を、生成した新たなレコードのメールアドレス３４２２に格納する。これによって、認証モジュール３３８は、生成したユーザＩＤと電子メールから取得した送信元のメールアドレスとを対応付けて、ユーザ管理テーブル３４２に記憶する。そして、認証モジュール３３８は、電子メールから取得した送信先のメールアドレスに対応するユーザを、新規のユーザとして認証を許可する。なお、認証モジュール３３８は、登録されるユーザの固有な情報をクライアント装置１０から受信してもよい。そして、認証モジュール３３８は、受信したユーザの固有な情報を、新たに生成したレコードに格納する。なお、ユーザの固有な情報は、認証要求に含まれてもよいし、単独で送信されてもよい。
【０１９２】
一方で、認証モジュール３３８は、メールアドレスが一致するレコードを選択できた場合、認証可能と判定する。次に、認証モジュール３３８は、認証可能を認証結果として、認証結果送信モジュール３３９に引き渡す。これによって、認証モジュール３３８は、認証要求の発行元のクライアント計算機１０を操作しているユーザを特定できる。具体的には、認証モジュール３３８は、選択したレコードから、ユーザＩＤ３４２１を抽出する。そして、認証モジュール３３８は、取得した認証要求ＩＤによって識別される認証要求の発行元のクライアント計算機１０を操作しているユーザが、抽出したユーザＩＤ３４２１によって識別されるユーザあると特定する。なお、認証モジュール３３８は、抽出したユーザＩＤ３４２１に対応するユーザの固有な情報を、認証結果に含めてもよい。
【０１９３】
認証結果送信モジュール３３９は、認証モジュール３３８から認証結果を引き受ける。次に、認証結果送信モジュール３３９は、引き受けた認証結果を、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２２４）。
【０１９４】
すると、クライアント装置１０は、メール認証装置３から認証結果を受信する（ＳＴ２２５）。
【０１９５】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、ユーザＩＤ及びパスワードが掠め取られる危険性がない。また、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを管理する必要がない。このように、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【０１９６】
（第１２の実施形態）
以下で第１２の実施形態の個人認証システムについて説明するが、第１及び第１１の実施形態の個人認証システムと重複する箇所は、同じ符号を用いることによって、説明を省略する。
【０１９７】
第１１の実施形態の個人認証システムは、メール認証装置３が、認証要求ＩＤを生成する。しかし、第１２の実施形態の個人認証システムでは、クライアント装置１０が、認証要求ＩＤを生成する。第１２の実施形態の個人認証システムは、第１〜第１０の個人認証システムのいずれにも適用できる。ここでは、第１の実施形態の認証システムに適用した場合を説明する。
【０１９８】
第１２の実施形態のクライアント装置１０について説明する。クライアント装置１０は、ユーザの操作によって、認証要求ＩＤ取得要求をメール認証装置３に送信する。すると、クライアント装置１０は、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを、メール認証装置３から受信する。認証要求ＩＤ生成情報は、クライアント装置１０が認証要求ＩＤを生成するための情報である。例えば、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔで記述されたクライアントサイドプログラムである。クライアント装置１０は、受信した認証要求ＩＤ生成情報に基づいて、認証要求ＩＤを生成する。例えば、クライアント装置１０は、時刻及び乱数のうち少なくとも一方を用いて、認証要求ＩＤを生成する。なお、生成される認証要求ＩＤは、一意でなければいけない。そこで、クライアント装置１０によって生成される認証要求ＩＤの文字列の数は、メール認証装置３が所定の時間内に認証するユーザの数に応じて、十分な長さとする。
【０１９９】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤを本文又は件名に含む電子メールを、送信する。この電子メールの送信先メールアドレスは、メール認証装置３から受信したメールアドレスであり、メール認証装置３が受信可能なメールアドレスである。
【０２００】
クライアント装置１０は、生成した認証要求ＩＤを含む認証要求を、メール認証装置３に送信する。
【０２０１】
次に、第１２の実施形態のメール認証装置３について説明する。図２２は、第１２の実施形態のメール認証装置３の機能ブロック図である。メール認証装置３の補助記憶装置３４には、第１２の実施形態の認証プログラム３００が記憶されている。第１２の実施形態の認証プログラム３００が実行されると、メール認証装置３の主記憶装置３３には、メインモジュール３３１、認証要求ＩＤ取得要求受信モジュール３３２４、認証要求受信モジュール３３２２、認証要求ＩＤ送信モジュール３３５２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９が記憶される。
【０２０２】
認証要求受信モジュール３３２２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９は、第１１の実施形態のメール認証装置３に備わるものと同一なので、説明を省略する。
【０２０３】
メインモジュール３３１は、認証要求ＩＤ取得要求受信モジュール３３２４、認証要求受信モジュール３３２２、認証要求ＩＤ送信モジュール３３５２、メール受信モジュール３３６、受信メール読取モジュール３３７、認証モジュール３３８及び認証結果送信モジュール３３９の処理を統括する。
【０２０４】
認証要求ＩＤ取得要求受信モジュール３３２４は、クライアント装置１０から認証要求ＩＤ取得要求を受信する。認証要求ＩＤ取得要求受信モジュール３３２４は、認証要求ＩＤ取得要求を受信すると、認証要求ＩＤ送信モジュール３３５２に、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスの送信を依頼する。
【０２０５】
認証要求ＩＤ送信モジュール３３５２は、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを、クライアント装置１０に送信する。
【０２０６】
次に、第１２の実施形態の個人認証方法の処理について図を用いて説明する。図２３は、第１２の実施形態の個人認証方法の処理のシーケンス図である。
【０２０７】
クライアント装置１０は、ユーザの操作を契機に、認証要求ＩＤ取得要求を、ネットワーク９を介してメール認証装置３に送信する（ＳＴ２１１）。
【０２０８】
すると、認証要求ＩＤ取得要求受信モジュール３３２４は、クライアント装置１０から認証要求ＩＤ取得要求を受信する（ＳＴ２１２）。すると、認証要求ＩＤ取得要求受信モジュール３３２４は、認証要求ＩＤ送信モジュール３３５２に、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスの送信を依頼する。
【０２０９】
認証要求ＩＤ送信モジュール３３５２は、依頼を受けると、認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを、ネットワーク９を介してクライアント装置１０に送信する（ＳＴ２１４）。
【０２１０】
クライアント装置１０は、メール認証装置３から認証要求ＩＤ生成情報及びメール認証装置３が受信可能な電子メールアドレスを受信する（ＳＴ２１６）。
【０２１１】
次に、クライアント装置１０は、受信した認証要求ＩＤ生成情報に基づいて、認証要求ＩＤを生成する（ＳＴ２１７）。
【０２１２】
クライアント装置１０は、ユーザの操作を契機に、ネットワーク９を介して、生成した認証要求ＩＤを含む電子メールを送信する（ＳＴ２１８）。この電子メールの送信先メールアドレスは、メール認証装置３から受信したメールアドレスであり、メール認証装置３が受信可能なメールアドレスである。また、電子メールに含まれる認証要求ＩＤは、本文又は件名のいずれに記載されていてもよい。更に、電子メールに含まれる認証要求ＩＤは、暗号化されていてもよい。
【０２１３】
以降のステップは、第１１の実施形態の個人認証システムと同様のため説明を省略する。
【０２１４】
前述の通り、クライアント装置１０のユーザは、ユーザＩＤ及びパスワードを入力することなく、個人認証を受けることができる。したがって、本実施の形態は、クライアント装置１０のユーザによるユーザＩＤ及びパスワードの管理を不要とする。また、ユーザＩＤ及びパスワードをユーザが入力する手間を省略できる。更に、ユーザＩＤ及びパスワードが掠め取られる危険性がなくなる。つまり、本実施の形態の個人認証システムは、安全且つ便利に、ユーザを認証できる。
【図面の簡単な説明】
【０２１５】
【図１】第１の実施形態の個人認証システムの概略構成を示す図である。
【図２】クライアント装置１０の構成のブロック図である。
【図３】メール認証装置３の構成のブロック図である。
【図４】メール認証装置３の機能ブロック図である。
【図５】メール認証装置３の補助記憶装置３４に記憶されているメールアドレス対応テーブル３４１の構成図である。
【図６】メール認証装置３の補助記憶装置３４に記憶されているユーザ管理テーブル３４２の構成図である。
【図７】第１の実施形態の個人認証方法の処理のシーケンス図である。
【図８】第２の実施形態の個人認証システムの概略の構成図である。
【図９】メール認証ＷＥＢ装置９０３の機能ブロック図である。
【図１０】第２の実施形態の個人認証方法の処理のシーケンス図である。
【図１１】第３の実施形態の個人認証システムの概略の構成図である。
【図１２】第３の実施形態の個人認証方法の処理のシーケンス図である。
【図１３】第５の実施形態の個人認証システムの概略の構成図である。
【図１４】ＡＴＭ２０１０の構成のブロック図である。
【図１５】第６の実施形態の個人認証システムの概略の構成図である。
【図１６】リーダ装置２１１０の構成のブロック図である。
【図１７】第１０の実施形態のメール認証装置３の機能ブロック図である。
【図１８】第１０の実施形態の個人認証方法の処理のシーケンス図である。
【図１９】第１１の実施形態のメール認証装置３の機能ブロック図である。
【図２０】第１１の実施形態のメール認証装置３の補助記憶装置３４に記憶されている認証要求ＩＤ対応テーブル３４１１の構成図である。
【図２１】第１１の実施形態の個人認証方法の処理のシーケンス図である。
【図２２】第１２の実施形態のメール認証装置３の機能ブロック図である。
【図２３】第１２の実施形態の個人認証方法の処理のシーケンス図である。
【符号の説明】
【０２１６】
１ インターネット
３ メール認証装置
５ 導入ＷＥＢサーバ
９ ネットワーク
１０ クライアント装置
１１ 送受信部
１２ 中央処理装置
１３ 主記憶装置
１４ 補助記憶装置
１５ 現金取扱部
１６ カード情報読取部
２０１０ ＡＴＭ
２０６０ 携帯電話
２１１０ リーダ装置
２０３４１ 認証用メールアドレス対応テーブル
２０３４１１ クライアントＩＤ
３１ 送受信部
３２ 中央処理装置
３３ 主記憶装置
３４ 補助記憶装置
３００ 認証プログラム
３３１ メインモジュール
３３２１ 認証要求受信モジュール
３３２２ 認証要求受信モジュール
３３２３ 認証要求ＩＤ取得要求受信モジュール
３３２４ 認証要求ＩＤ取得要求受信モジュール
３３２５ 認証用メールアドレス生成情報取得要求受信モジュール
３３３ 認証要求ＩＤ生成モジュール
３３４ 認証用メールアドレス生成モジュール
３３５ 認証用メールアドレス送信モジュール
３３５１ 認証要求ＩＤ送信モジュール
３３５２ 認証要求ＩＤ送信モジュール
３３５３ 認証用メールアドレス生成情報送信モジュール
３３６ メール受信モジュール
３３７ 受信メール読取モジュール
３３８ 認証モジュール
３３９ 認証結果送信モジュール
３４１ 認証用メールアドレス対応テーブル
３４１１ 認証要求ＩＤ
３４１２ 認証用メールアドレス
３４１３ ユーザメールアドレス
３４２ ユーザ管理テーブル
３４２１ ユーザＩＤ
３４２２ メールアドレス
６０ 携帯電話
９０３ メール認証ＷＥＢ装置
９２３ ＡＴＭメール認証装置
９４３ メール認証専用ＷＥＢ装置
９０１０ クライアント装置
９０３００ 認証プログラム
９０３３５ 認証用メールアドレス送信モジュール
９０３３９ 認証結果送信モジュール
【特許請求の範囲】
【請求項１】
複数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びインタフェースを備える認証計算機であって、
前記プロセッサは、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、
電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを抽出し、
前記抽出された送信先のメールアドレスと、前記抽出された送信元のメールアドレスと、の対応をメールアドレス対応情報に記憶し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定し、
前記メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する送信元のメールアドレスを特定し、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする認証計算機。
【請求項２】
前記プロセッサは、
当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当て、
前記割り当てられたメールアドレスを、当該メールアドレスを割り当てられた認証要求を送信するクライアント計算機に通知し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求に割り当てられているメールアドレスを特定することによって、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定することを特徴とする請求項１に記載の認証計算機。
【請求項３】
前記認証要求は、当該認証要求に割り当てられているメールアドレスの一部又は全部を含み、
前記プロセッサは、前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求から、メールアドレスの一部又は全部を抽出することによって、前記受信した認証要求に割り当てられているメールアドレスを特定することを特徴とする請求項２に記載の認証計算機。
【請求項４】
前記プロセッサは、
メールアドレスを割り当ててから所定の時間が経過すると、当該メールアドレスの割り当てを解除し、
前記割り当てを解除したメールアドレスを再度割り当てることを特徴とする請求項２に記載の認証計算機。
【請求項５】
前記プロセッサは、
当該認証計算機が受信可能なメールアドレスを新たに作成し、
前記作成された新たなメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることによって、当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることを特徴とする請求項２に記載の認証計算機。
【請求項６】
前記プロセッサは、前記メールアドレスを新たに作成してから所定の時間が経過すると、当該作成されたメールアドレスを無効とすることによって、当該作成されたメールアドレスの割り当てを解除することを特徴とする請求項５に記載の認証計算機。
【請求項７】
前記プロセッサは、
前記特定された送信元のメールアドレスが偽装されているか否かを判定し、
前記特定された送信元のメールアドレスが偽装されている場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１に記載の認証計算機。
【請求項８】
前記プロセッサは、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１に記載の認証計算機。
【請求項９】
前記プロセッサは、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、当該特定された送信元のメールアドレスを新規ユーザのメールアドレスとして、前記ユーザ情報に格納することを特徴とする請求項１に記載の認証計算機。
【請求項１０】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの固有な情報との対応を含み、
前記プロセッサは、
前記ユーザ情報を参照して、前記特定されたユーザに対応する固有な情報を特定し、
前記クライアント計算機からユーザの固有な情報を受信し、
前記特定された固有な情報と前記受信した固有な情報とが一致すると、前記受信した認証要求の結果を、認証可能と判定することを特徴とする請求項１に記載の認証計算機。
【請求項１１】
前記ユーザ情報は、更に、前記ユーザと当該ユーザが所有するクレジットカードとの対応を含み、
前記プロセッサは、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し、
前記受信した認証要求の結果を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応するクレジットカードを特定し、
前記特定されたクレジットカードに対する与信審査を行い、
与信審査の結果が良好であると、前記特定されたクレジットカードでの決済を許可することを特徴とする請求項１に記載の認証計算機。
【請求項１２】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの口座との対応を含み、
前記プロセッサは、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し
前記受信した認証要求を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応する口座を特定し、
前記特定された口座に対する取引の実行を許可することを特徴とする請求項１に記載の認証計算機。
【請求項１３】
プロセッサ、メモリ及びインタフェースを備える複数のクライアント計算機と、前記複
数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びイン
タフェースを備える認証計算機と、を備える認証システムであって、
前記認証計算機は、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、
電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを抽出し、
前記抽出された送信先のメールアドレスと、前記抽出された送信元のメールアドレスと、の対応をメールアドレス対応情報に記憶し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定し、
前記メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する送信元のメールアドレスを特定し、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする認証システム。
【請求項１４】
前記認証計算機は、
当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当て、
前記割り当てられたメールアドレスを、当該メールアドレスを割り当てられた認証要求を送信するクライアント計算機に通知し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求に割り当てられているメールアドレスを特定することによって、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定することを特徴とする請求項１３に記載の認証システム。
【請求項１５】
前記認証要求は、当該認証要求に割り当てられているメールアドレスの一部又は全部を含み、
前記認証計算機は、前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求から、メールアドレスの一部又は全部を抽出することによって、前記受信した認証要求に割り当てられているメールアドレスを特定することを特徴とする請求項１４に記載の認証システム。
【請求項１６】
前記認証計算機は、
メールアドレスを割り当ててから所定の時間が経過すると、当該メールアドレスの割り当てを解除し、
前記割り当てを解除したメールアドレスを再度割り当てることを特徴とする請求項１４に記載の認証システム。
【請求項１７】
前記認証計算機は、
当該認証計算機が受信可能なメールアドレスを新たに作成し、
前記作成された新たなメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることによって、当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることを特徴とする請求項１４に記載の認証システム。
【請求項１８】
前記認証計算機は、前記メールアドレスを新たに作成してから所定の時間が経過すると、当該作成されたメールアドレスを無効とすることによって、当該作成されたメールアドレスの割り当てを解除することを特徴とする請求項１７に記載の認証システム。
【請求項１９】
前記認証計算機は、
前記特定された送信元のメールアドレスが偽装されているか否かを判定し、
前記特定された送信元のメールアドレスが偽装されている場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１３に記載の認証システム。
【請求項２０】
前記認証計算機は、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１３に記載の認証システム。
【請求項２１】
前記認証計算機は、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、当該特定された送信元のメールアドレスを新規ユーザのメールアドレスとして、前記ユーザ情報に格納することを特徴とする請求項１３に記載の認証システム。
【請求項２２】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの固有な情報との対応を含み、
前記認証計算機は、
前記ユーザ情報を参照して、前記特定されたユーザに対応する固有な情報を特定し、
前記クライアント計算機からユーザの固有な情報を受信し、
前記特定された固有な情報と前記受信した固有な情報とが一致すると、前記受信した認証要求の結果を、認証可能と判定することを特徴とする請求項１３に記載の認証システム。
【請求項２３】
前記ユーザ情報は、更に、前記ユーザと当該ユーザが所有するクレジットカードとの対応を含み、
前記認証計算機は、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し、
前記受信した認証要求の結果を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応するクレジットカードを特定し、
前記特定されたクレジットカードに対する与信審査を行い、
与信審査の結果が良好であると、前記特定されたクレジットカードでの決済を許可することを特徴とする請求項１３に記載の認証システム。
【請求項２４】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの口座との対応を含み、
前記認証計算機は、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し
前記受信した認証要求を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応する口座を特定し、
前記特定された口座に対する取引の実行を許可することを特徴とする請求項１３に記載の認証システム。
【請求項２５】
前記クライアント計算機は、
前記認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、以後に送信する認証要求に割り当て、
前記メールアドレスが割り当てられた認証要求を、前記認証計算機に送信し、
前記認証計算機は、前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求に割り当てられているメールアドレスを特定することによって、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定することを特徴とする請求項１３に記載の認証システム。
【請求項２６】
前記クライアント計算機は、
当該認証計算機が受信可能なメールアドレスを新たに作成し、
前記作成された新たなメールアドレスを、以後に送信する認証要求に割り当てることによって、当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、以後に送信する認証要求に割り当てることを特徴とする請求項２５に記載の認証システム。
【請求項２７】
複数のクライアント計算機にネットワークを介して接続される認証計算機に実行されるプログラムであって、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶するステップと、
電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを抽出するステップと、
前記抽出された送信先のメールアドレスと、前記抽出された送信元のメールアドレスと、の対応をメールアドレス対応情報に記憶するステップと、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定するステップと、
前記メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する送信元のメールアドレスを特定するステップと、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定するステップと、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断するステップと、を含むことを特徴とするプログラム。
【請求項２８】
当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てるステップと、
前記割り当てられたメールアドレスを、当該メールアドレスを割り当てられた認証要求を送信するクライアント計算機に通知するステップと、を含み、
前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定するステップでは、前記受信した認証要求に割り当てられているメールアドレスを特定することを特徴とする請求項２７に記載のプログラム。
【請求項２９】
プロセッサ、メモリ及びインタフェースを備える複数のクライアント計算機と、前記複
数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びイン
タフェースを備える認証計算機と、を備える認証システムであって、
前記認証計算機は、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、
電子メールを受信すると、当該受信した電子メールから、認証要求識別情報及び送信元のメールアドレスを抽出し、
前記抽出された認証要求識別情報と、前記抽出された送信元のメールアドレスと、の対応を認証要求識別情報対応情報に記憶し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている認証要求識別情報の中から、前記受信した認証要求を識別可能な認証要求識別情報を特定し、
前記認証要求識別情報対応対応情報を参照して、前記特定された認証要求識別情報に対応する送信元のメールアドレスを特定し、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする認証システム。
【請求項３０】
前記認証要求識別情報は、電子メールの送信先のメールアドレスであることを特徴とする請求項２９に記載の認証システム。
【請求項１】
複数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びインタフェースを備える認証計算機であって、
前記プロセッサは、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、
電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを抽出し、
前記抽出された送信先のメールアドレスと、前記抽出された送信元のメールアドレスと、の対応をメールアドレス対応情報に記憶し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定し、
前記メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する送信元のメールアドレスを特定し、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする認証計算機。
【請求項２】
前記プロセッサは、
当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当て、
前記割り当てられたメールアドレスを、当該メールアドレスを割り当てられた認証要求を送信するクライアント計算機に通知し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求に割り当てられているメールアドレスを特定することによって、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定することを特徴とする請求項１に記載の認証計算機。
【請求項３】
前記認証要求は、当該認証要求に割り当てられているメールアドレスの一部又は全部を含み、
前記プロセッサは、前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求から、メールアドレスの一部又は全部を抽出することによって、前記受信した認証要求に割り当てられているメールアドレスを特定することを特徴とする請求項２に記載の認証計算機。
【請求項４】
前記プロセッサは、
メールアドレスを割り当ててから所定の時間が経過すると、当該メールアドレスの割り当てを解除し、
前記割り当てを解除したメールアドレスを再度割り当てることを特徴とする請求項２に記載の認証計算機。
【請求項５】
前記プロセッサは、
当該認証計算機が受信可能なメールアドレスを新たに作成し、
前記作成された新たなメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることによって、当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることを特徴とする請求項２に記載の認証計算機。
【請求項６】
前記プロセッサは、前記メールアドレスを新たに作成してから所定の時間が経過すると、当該作成されたメールアドレスを無効とすることによって、当該作成されたメールアドレスの割り当てを解除することを特徴とする請求項５に記載の認証計算機。
【請求項７】
前記プロセッサは、
前記特定された送信元のメールアドレスが偽装されているか否かを判定し、
前記特定された送信元のメールアドレスが偽装されている場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１に記載の認証計算機。
【請求項８】
前記プロセッサは、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１に記載の認証計算機。
【請求項９】
前記プロセッサは、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、当該特定された送信元のメールアドレスを新規ユーザのメールアドレスとして、前記ユーザ情報に格納することを特徴とする請求項１に記載の認証計算機。
【請求項１０】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの固有な情報との対応を含み、
前記プロセッサは、
前記ユーザ情報を参照して、前記特定されたユーザに対応する固有な情報を特定し、
前記クライアント計算機からユーザの固有な情報を受信し、
前記特定された固有な情報と前記受信した固有な情報とが一致すると、前記受信した認証要求の結果を、認証可能と判定することを特徴とする請求項１に記載の認証計算機。
【請求項１１】
前記ユーザ情報は、更に、前記ユーザと当該ユーザが所有するクレジットカードとの対応を含み、
前記プロセッサは、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し、
前記受信した認証要求の結果を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応するクレジットカードを特定し、
前記特定されたクレジットカードに対する与信審査を行い、
与信審査の結果が良好であると、前記特定されたクレジットカードでの決済を許可することを特徴とする請求項１に記載の認証計算機。
【請求項１２】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの口座との対応を含み、
前記プロセッサは、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し
前記受信した認証要求を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応する口座を特定し、
前記特定された口座に対する取引の実行を許可することを特徴とする請求項１に記載の認証計算機。
【請求項１３】
プロセッサ、メモリ及びインタフェースを備える複数のクライアント計算機と、前記複
数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びイン
タフェースを備える認証計算機と、を備える認証システムであって、
前記認証計算機は、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、
電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを抽出し、
前記抽出された送信先のメールアドレスと、前記抽出された送信元のメールアドレスと、の対応をメールアドレス対応情報に記憶し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定し、
前記メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する送信元のメールアドレスを特定し、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする認証システム。
【請求項１４】
前記認証計算機は、
当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当て、
前記割り当てられたメールアドレスを、当該メールアドレスを割り当てられた認証要求を送信するクライアント計算機に通知し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求に割り当てられているメールアドレスを特定することによって、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定することを特徴とする請求項１３に記載の認証システム。
【請求項１５】
前記認証要求は、当該認証要求に割り当てられているメールアドレスの一部又は全部を含み、
前記認証計算機は、前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求から、メールアドレスの一部又は全部を抽出することによって、前記受信した認証要求に割り当てられているメールアドレスを特定することを特徴とする請求項１４に記載の認証システム。
【請求項１６】
前記認証計算機は、
メールアドレスを割り当ててから所定の時間が経過すると、当該メールアドレスの割り当てを解除し、
前記割り当てを解除したメールアドレスを再度割り当てることを特徴とする請求項１４に記載の認証システム。
【請求項１７】
前記認証計算機は、
当該認証計算機が受信可能なメールアドレスを新たに作成し、
前記作成された新たなメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることによって、当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てることを特徴とする請求項１４に記載の認証システム。
【請求項１８】
前記認証計算機は、前記メールアドレスを新たに作成してから所定の時間が経過すると、当該作成されたメールアドレスを無効とすることによって、当該作成されたメールアドレスの割り当てを解除することを特徴とする請求項１７に記載の認証システム。
【請求項１９】
前記認証計算機は、
前記特定された送信元のメールアドレスが偽装されているか否かを判定し、
前記特定された送信元のメールアドレスが偽装されている場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１３に記載の認証システム。
【請求項２０】
前記認証計算機は、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、前記受信した認証要求の結果を、認証不可と判定することを特徴とする請求項１３に記載の認証システム。
【請求項２１】
前記認証計算機は、前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定できない場合、当該特定された送信元のメールアドレスを新規ユーザのメールアドレスとして、前記ユーザ情報に格納することを特徴とする請求項１３に記載の認証システム。
【請求項２２】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの固有な情報との対応を含み、
前記認証計算機は、
前記ユーザ情報を参照して、前記特定されたユーザに対応する固有な情報を特定し、
前記クライアント計算機からユーザの固有な情報を受信し、
前記特定された固有な情報と前記受信した固有な情報とが一致すると、前記受信した認証要求の結果を、認証可能と判定することを特徴とする請求項１３に記載の認証システム。
【請求項２３】
前記ユーザ情報は、更に、前記ユーザと当該ユーザが所有するクレジットカードとの対応を含み、
前記認証計算機は、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し、
前記受信した認証要求の結果を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応するクレジットカードを特定し、
前記特定されたクレジットカードに対する与信審査を行い、
与信審査の結果が良好であると、前記特定されたクレジットカードでの決済を許可することを特徴とする請求項１３に記載の認証システム。
【請求項２４】
前記ユーザ情報は、更に、前記ユーザと当該ユーザの口座との対応を含み、
前記認証計算機は、
前記ユーザ情報を参照して、前記受信した認証要求の結果を判定し
前記受信した認証要求を認証可能と判定すると、前記ユーザ情報を参照して、前記特定されたユーザに対応する口座を特定し、
前記特定された口座に対する取引の実行を許可することを特徴とする請求項１３に記載の認証システム。
【請求項２５】
前記クライアント計算機は、
前記認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、以後に送信する認証要求に割り当て、
前記メールアドレスが割り当てられた認証要求を、前記認証計算機に送信し、
前記認証計算機は、前記複数のクライアント計算機のうちの一つから認証要求を受信すると、当該受信した認証要求に割り当てられているメールアドレスを特定することによって、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定することを特徴とする請求項１３に記載の認証システム。
【請求項２６】
前記クライアント計算機は、
当該認証計算機が受信可能なメールアドレスを新たに作成し、
前記作成された新たなメールアドレスを、以後に送信する認証要求に割り当てることによって、当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、以後に送信する認証要求に割り当てることを特徴とする請求項２５に記載の認証システム。
【請求項２７】
複数のクライアント計算機にネットワークを介して接続される認証計算機に実行されるプログラムであって、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶するステップと、
電子メールを受信すると、当該受信した電子メールから、送信先のメールアドレス及び送信元のメールアドレスを抽出するステップと、
前記抽出された送信先のメールアドレスと、前記抽出された送信元のメールアドレスと、の対応をメールアドレス対応情報に記憶するステップと、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定するステップと、
前記メールアドレス対応情報を参照して、前記特定された送信先のメールアドレスに対応する送信元のメールアドレスを特定するステップと、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定するステップと、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断するステップと、を含むことを特徴とするプログラム。
【請求項２８】
当該認証計算機が受信可能なメールアドレスのうち、認証要求のいずれにも割り当てられていないメールアドレスを、前記複数のクライアント計算機のうちの一つから送信される認証要求に割り当てるステップと、
前記割り当てられたメールアドレスを、当該メールアドレスを割り当てられた認証要求を送信するクライアント計算機に通知するステップと、を含み、
前記メールアドレス対応情報に対応が記憶されている送信先のメールアドレスの中から、前記受信した認証要求に対応する送信先のメールアドレスを特定するステップでは、前記受信した認証要求に割り当てられているメールアドレスを特定することを特徴とする請求項２７に記載のプログラム。
【請求項２９】
プロセッサ、メモリ及びインタフェースを備える複数のクライアント計算機と、前記複
数のクライアント計算機にネットワークを介して接続され、プロセッサ、メモリ及びイン
タフェースを備える認証計算機と、を備える認証システムであって、
前記認証計算機は、
ユーザと当該ユーザのメールアドレスとの対応を示すユーザ情報を記憶し、
電子メールを受信すると、当該受信した電子メールから、認証要求識別情報及び送信元のメールアドレスを抽出し、
前記抽出された認証要求識別情報と、前記抽出された送信元のメールアドレスと、の対応を認証要求識別情報対応情報に記憶し、
前記複数のクライアント計算機のうちの一つから認証要求を受信すると、前記メールアドレス対応情報に対応が記憶されている認証要求識別情報の中から、前記受信した認証要求を識別可能な認証要求識別情報を特定し、
前記認証要求識別情報対応対応情報を参照して、前記特定された認証要求識別情報に対応する送信元のメールアドレスを特定し、
前記ユーザ情報を参照して、前記特定された送信元のメールアドレスに対応するユーザを特定し、
前記受信した認証要求では、前記特定されたユーザによって認証が要求されていると判断することを特徴とする認証システム。
【請求項３０】
前記認証要求識別情報は、電子メールの送信先のメールアドレスであることを特徴とする請求項２９に記載の認証システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２００８−１１７３２５（Ｐ２００８−１１７３２５Ａ）
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願番号】特願２００６−３０２２２２（Ｐ２００６−３０２２２２）
【出願日】平成１８年１１月８日（２００６．１１．８）
【出願人】（３０６０１６６８２）株式会社キーテル (28)
【Ｆターム（参考）】
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願日】平成１８年１１月８日（２００６．１１．８）
【出願人】（３０６０１６６８２）株式会社キーテル (28)
【Ｆターム（参考）】
[ Back to top ]