(57)【要約】本発明に係るパスワード通知方法は、ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのＵＲＬを生成して記憶装置に登録するステップと、生成されたアクセスキー及びＵＲＬを、受信したメールアドレス宛のメール及び他の手段にて、ユーザ宛に別々に送信するステップと、アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーとＵＲＬとの対応関係を含む所定の条件を満たしているか判断するステップと、所定の条件を満たしている場合には、ユーザの端末にパスワードを暗号化して通知するステップとを含む。このようにアクセスキーとアクセスキーの確認を行うためのＵＲＬとが別々に別の手段にてユーザに通知されるので、いずれかが第三者に取得されたとしてもパスワードは漏洩することが無く安全である。
2004055684.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのユニフォーム・リソース・ロケータ（ＵＲＬ）を生成して記憶装置に登録する登録ステップと、
生成された前記アクセスキー及び前記ＵＲＬを、受信した前記メールアドレス宛のメール及び他の手段にて、前記ユーザ宛に別々に送信する送信ステップと、
アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーと前記ＵＲＬとの対応関係を含む所定の条件を満たしているか判断する判断ステップと、
前記所定の条件を満たしている場合には、前記ユーザの端末にパスワードを通知する通知ステップと、
を含むパスワード通知方法。
【請求項２】
前記登録ステップが、
前記ユーザの端末から受信したメールアドレスが予め登録されたメールアドレスか否かを判断するステップ
を含むことを特徴とする請求項１記載のパスワード通知方法。
【請求項３】
前記登録ステップが、
前記アクセスキー及びＵＲＬに対応して、受信したメールアドレスを記憶装置に登録するステップ、
を含むことを特徴とする請求項１記載のパスワード通知方法。
【請求項４】
前記他の手段が、暗号化されたウェブ・ページであることを特徴とする請求項１記載のパスワード通知方法。
【請求項５】
前記送信ステップにおいて、
生成された前記アクセスキーを前記暗号化されたウェブ・ページ経由で、前記ＵＲＬを前記メールアドレス宛のメールにて送信する
ことを特徴とする請求項４記載のパスワード通知方法。
【請求項６】
アクセスキーの確認を行うためのＵＲＬへのアクセスに応答して、当該ＵＲＬに対応して設定されている有効期限内であるか判断するステップ
をさらに含む請求項１記載のパスワード通知方法。
【請求項７】
前記ユーザの端末から受信したメールアドレスと当該受信したアクセスキー及びＵＲＬとの対応関係が正当なものであるか前記記憶装置を参照して判断するステップ
をさらに含む請求項３記載のパスワード通知方法。
【請求項８】
アクセスキーの確認を行うためのＵＲＬへのアクセスに応答して、当該ＵＲＬに対応して登録されているアクセス履歴についての条件を満たしているか判断するステップ
をさらに含む請求項１記載のパスワード通知方法。
【請求項９】
前記アクセス履歴についての条件が、当該ＵＲＬへの最初のアクセスであるという条件を含むことを特徴とする請求項８記載のパスワード通知方法。
【請求項１０】
前記アクセス履歴についての条件が、当該ＵＲＬ経由でパスワードが未通知であるという条件を含むことを特徴とする請求項８記載のパスワード通知方法。
【請求項１１】
前記アクセス履歴についての条件が、当該ＵＲＬに対応しないアクセスキーが受信されたことがないという条件を含むことを特徴とする請求項８記載のパスワード通知方法。
【請求項１２】
前記ＵＲＬに対応して登録されているアクセス履歴についての条件が満たしていないと判断された場合には、前記アクセス履歴を含むデータを前記ユーザの端末に送信するステップ
をさらに含む請求項８記載のパスワード通知方法。
【請求項１３】
前記所定の条件が、アクセス履歴についての条件を含むことを特徴とする請求項１記載のパスワード通知方法。
【請求項１４】
前記所定の条件が、前記アクセスキーの確認を行うためのＵＲＬへのアクセスが、当該ＵＲＬに対応して設定されている有効期限内であるという条件を含むことを特徴とする請求項１記載のパスワード通知方法。
【請求項１５】
請求項１乃至１４のいずれか１項記載のパスワード通知方法をコンピュータに実行させるためのプログラムを格納した記録媒体。
【請求項１６】
ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのユニフォーム・リソース・ロケータ（ＵＲＬ）を生成して記憶装置に登録する登録ステップと、
生成された前記アクセスキー及び前記ＵＲＬを、受信した前記メールアドレス宛のメール及び他の手段にて、前記ユーザ宛に別々に送信する送信ステップと、
アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーとＵＲＬとの対応関係を含む所定の条件を満たしているか判断する判断ステップと、
前記所定の条件を満たしている場合には、前記ユーザの端末にパスワードを通知する通知ステップと、
をコンピュータに実行させるためのプログラム。
【請求項１７】
ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのユニフォーム・リソース・ロケータ（ＵＲＬ）を生成して記憶装置に登録する登録手段と、
生成された前記アクセスキー及び前記ＵＲＬを、受信した前記メールアドレス宛のメール及び他の手段にて、前記ユーザ宛に別々に送信する送信手段と、
アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーとＵＲＬとの対応関係を含む所定の条件を満たしているか判断する判断手段と、
前記所定の条件を満たしている場合には、前記ユーザの端末にパスワードを通知する通知手段と、
を有するパスワード通知システム。
【請求項１８】
前記登録手段が、
前記ユーザの端末から受信したメールアドレスが予め登録されたメールアドレスか否かを判断する手段
を含むこと特徴とする請求項１５記載のパスワード通知システム。
【請求項１９】
前記登録手段が、
前記アクセスキー及びＵＲＬに対応して、受信したメールアドレスを記憶装置に登録する手段
を含むことを特徴とする請求項１５記載のパスワード通知システム。
【請求項２０】
前記他の手段が、暗号化されたウェプ・ページであることを特徴とする請求項１５記載のパスワード通知システム。
【請求項２１】
アクセスキーの確認を行うためのＵＲＬへのアクセスに応答して、当該ＵＲＬに対応して設定されている有効期限内であるか判断する手段
をさらに有する請求項１５記載のパスワード通知システム。
【請求項２２】
アクセスキーの確認を行うためのＵＲＬへのアクセスに応答して、当該ＵＲＬに対応して登録されているアクセス履歴についての条件を満たしているか判断する手段
をさらに有する請求項１５記載のパスワード通知システム。
【請求項２３】
前記所定の条件が、アクセス履歴についての条件を含むことを特徴とする請求項１５記載のパスワード通知システム。
【発明の詳細な説明】
【技術分野】  本発明は、ログインなどのためのパスワードなどを安全にユーザに通知するための技術に関する。
【背景技術】  インターネットの普及とその帯域のブロードバンド化により教育分野でもインターネットの利用が進んできている。これは従来のように固定された時間及び場所において提供される講習などに参加するのではなく、必要なときに又は可能な時間にインターネット接続が可能な場所で教育を受けることができ、効率的だからである。このようなインターネットを利用した教育において非常に大きな問題は、受講者が受講のために必要なＩＤやパスワードを失念してしまうということである。通常ＩＤやパスワードは個人特有の情報であり、他人にその情報が漏れることのないように確実な方法で本人に通知されるべき情報である。よって、その受講者がＩＤやパスワードを失念した場合には、システム管理者に自分のＩＤとパスワードを問い合わせることが必要になってくる。しかし、ＩＤやパスワードは非常に重要な情報なので限られた人しかアクセスできず、さらに問い合わせがあっても問い合わせた人間が本人かどうかを確認してからでなければ、教えることはできない。
このように慎重に取り扱うべきＩＤやパスワードの問い合わせにシステム管理者が応対する場合には、多くの作業が必要であり、問い合わせ件数が増えると非常に大きな負担が発生する。特に、初心者が多い講座の場合には、その件数が非常に大きくなり、負担はさらに多大なものとなる。
現在、パスワードの再発行は、例えば初期登録時に合言葉を登録しておくといった方法も用いられているが、パスワードを失念する人は合言葉も失念することが多く、あまり効果が無い。
なお、例えば日本国特許公開公報特開２００１−３３１４４７号には、パスワードが忘れられることを前提として安全にパスワードを顧客に伝達することを課題として、様々なセキュアな通信手段を特別に用意して安全にパスワードを通知する技術が開示されている。従って現在広く利用されているインターネットのようにセキュアではないコンピュータ・ネットワークだけを用いる場合には、本公報に開示されている技術の適用は難しい。
また、日本国特許公開公報特開平１１−２５０５０号には、第三者による偶然又は故意による本人へのなりすましを防止することを課題として、テンポラリパスワードと確認用ホームページのＵＲＬをユーザが予め登録されている電子メールアドレス宛に通知する技術が開示されている。しかし、テンポラリパスワードと確認用ホームページのＵＲＬを同じメールで送信すると、当該メールのデータを取得した第三者は簡単にログインできてしまうという問題がある。
【発明の開示】
以上のように、セキュアでないネットワークを介してパスワードなどを安全にユーザに通知する有効な技術は存在していなかった。
よって本発明の目的は、パスワードなどを安全にユーザに通知するための新規な技術を提供することである。
本発明に係るパスワード通知方法は、ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのユニフォーム・リソース・ロケータ（ＵＲＬ：Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を生成して記憶装置に登録する登録ステップと、生成されたアクセスキー及びＵＲＬを、受信したメールアドレス宛のメール及び他の手段にて、ユーザ宛に別々に送信する送信ステップと、アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーとＵＲＬとの対応関係を含む所定の条件を満たしているか判断する判断ステップと、所定の条件を満たしている場合には、ユーザの端末にパスワードを通知する通知ステップとを含む。
このようにアクセスキーとアクセスキーの確認を行うためのＵＲＬとが別々に別の手段にてユーザに通知されるので、いずれかが第三者に取得されたとしてもパスワードは漏洩することが無く安全である。また、指定したメールアドレス宛のメールを受信できる者でなければパスワードを取得できないということもなりすましを防止する点において重要である。
また、上で述べた登録ステップが、ユーザの端末から受信したメールアドレスが予め登録されたメールアドレスか否かを判断するステップを含むようにしてもよい。例えば、本発明はパスワードの新規発行の場合でも、このようにパスワードの再発行の場合でも適用することができる。
さらに、上で述べた登録ステップが、アクセスキー及びＵＲＬに対応して、受信したメールアドレスを記憶装置に登録するステップを含むようにしてもよい。メールアドレスについてもパスワード通知時に確認することができるようになる。
また、上で述べた他の手段が、暗号化されたウェブ・ページである場合もある。このようにすれば、安全にデータを通知することができる。例えばＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）を用いるということである。
さらに、上で述べた送信ステップにおいて、生成されたアクセスキーを暗号化されたウェブ・ページ経由で、ＵＲＬをメールアドレス宛のメールにて送信するような構成であってもよい。アクセスキーは非常に重要なので暗号化し、ＵＲＬについては仮に盗み見られても他の手段を講じることができるのでメールにて送信するものである。
また、本発明に係るパスワード通知方法において、アクセスキーの確認を行うためのＵＲＬへのアクセスに応答して、当該ＵＲＬに対応して設定されている有効期限内であるか判断するステップをさらに含むような構成であってもよい。ＵＲＬの有効期限を設けることにより、例えばＵＲＬが盗み見られた場合であっても有効期限後であればパスワードの漏洩を防止することができるようになる。
さらに、本発明に係るパスワード通知方法において、ユーザの端末から受信したメールアドレスと当該受信したアクセスキー及びＵＲＬとの対応関係が正当なものであるか記憶装置を参照して判断するステップをさらに含むようにしてもよい。
また、本発明に係るパスワード通知方法において、アクセスキーの確認を行うためのＵＲＬへのアクセスに応答して、当該ＵＲＬに対応して登録されているアクセス履歴についての条件を満たしているか判断するステップをさらに含むようにしてもよい。このようにすれば、さらにアクセスキーの確認を行うためのＵＲＬへのアクセス自体を制限的にすることができるようになる。
すなわち、上で述べたアクセス履歴についての条件が、当該ＵＲＬへの最初のアクセスであるという条件を含むような構成であってもよい。指定されたＵＲＬ自体がワンタイム化される。
また、上で述べたアクセス履歴についての条件が、当該ＵＲＬ経由でパスワードが未通知であるという条件を含むような構成であってもよい。例えば指定されたＵＲＬからパスワードが表示されるページまでに何らかの理由でリンクが切れる場合もあるので、ＵＲＬへのアクセス回数ではなく、パスワードの通知の有無に基準を設けるものである。
さらに、上で述べたアクセス履歴についての条件が、当該ＵＲＬに対応しないアクセスキーが受信されたことがないという条件を含むような構成であってもよい。例えばＵＲＬを盗み見た第三者が何らかのアクセスキーを入力してパスワードを不正に取得しようとしたことを検出して、何度も異なるアクセスキーを入力できないようにロックするためである。
また、本発明に係るパスワード通知方法では、ＵＲＬに対応して登録されているアクセス履歴についての条件が満たされていないと判断された場合には、アクセス履歴を含むデータをユーザの端末に送信するステップをさらに含むような構成であってもよい。指定されたＵＲＬにアクセスできない場合には、過去のアクセス履歴により不正なアクセスがあったことなどをユーザに知らせるためである。
さらに、上で述べた所定の条件が、アクセス履歴についての条件を含むような構成であってもよい。アクセスに応答してアクセス履歴についての条件をチェックするのではなく、例えばアクセスキーの入力を受信した際に合わせて判断するようにしても良い。
同様に、上で述べた所定の条件が、アクセスキーの確認を行うためのＵＲＬへのアクセスが、当該ＵＲＬに対応して設定されている有効期限内であるという条件を含むような構成であってもよい。
なお、上で述べたパスワード通知方法は、プログラム及びコンピュータにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【図面の簡単な説明】  第１図は、本発明の一実施例に係るシステム概要図である。
第２図は、マスタＤＢに格納されるデータの一例を示す図である。
第３図は、アクセスＤＢに格納されるデータの一例を示す図である。
第４図は、本発明の実施例に係る前半の処理フローを示す図である。
第５図は、ログインＩＤ及びパスワード照会ページの一例を示す図である。
第６図は、メールアドレス入力ページの一例を示す図である。
第７図は、エラー後のメールアドレス入力ページの一例を示す図である。
第８図は、パスワード問い合わせページの一例を示す図である。
第９図は、アクセスキー通知ページの一例を示す図である。
第１０図は、照会用ＵＲＬ通知メールの一例を示す図である。
第１１図は、本発明の実施例１に係る後半の処理フローを示す図である。
第１２図は、有効期限経過後のエラーメッセージ表示ページの一例を示す図である。
第１３図は、メールアドレス及びアクセスキー入力ページの一例を示す図である。
第１４図は、エラー後のメールアドレス及びアクセスキー入力ページの一例を示す図である。
第１５図は、ＩＤ及びパスワードを含むページの一例を示す図である。
第１６図は、本発明の実施例２に係る後半の処理フローを示す図である。
第１７図は、本発明の実施例３に係る後半の処理フローを示す図である。
第１８図は、本発明の実施例４に係る後半の処理フローを示す図である。
［本発明を実施するための最良の形態］
第１図を用いて、本発明の一実施例に係るシステム概要を説明する。例えばインターネットである、セキュアではないネットワーク１には、ＳＳＬでの通信が可能なウェブ（Ｗｅｂ）ブラウザ及びメーラ機能を有する複数のユーザ端末３及び７と、Ｗｅｂサーバ機能及びメールサーバ機能を有し且つ本実施例における主要な処理を実施するサーバ５とが接続されている。ユーザ端末３及び７は、例えばパーソナルコンピュータであるが、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）や携帯電話機の場合もある。サーバ５は、例えばネットワーク１を介して会員制のサービスを提供するための処理を実施する構成の場合もあれば、本実施の形態のための処理のみを実施するような構成の場合もある。サーバ５は、以下で説明する処理のためのアクセスＤＢ５２を管理しており、また会員情報が登録されたマスタＤＢ５１を参照できるようになっている。
第２図にマスタＤＢ５１に格納されるデータの一例を示す。第２図のテーブル例では、ユーザのＩＤの列２０１と、パスワードの列２０２と、メールアドレスの列２０３とが設けられている。但し、これ以外の他の個人情報を登録するようにしても良い。ここでは、ユーザＩＤに対応して、パスワード及びメールアドレスが登録されているものとする。
第３図にアクセスＤＢ５２に格納されるデータの一例を示す。第３図のテーブル例では、パスワードを通知する際の認証用のアクセスキーの列３０１と、パスワード照会用のＵＲＬの列３０２と、当該照会用ＵＲＬの有効期限の列３０３と、当該パスワード照会を行う正当なユーザのメールアドレスの列３０４と、照会用ＵＲＬへのアクセス履歴の列３０５とが設けられている。なお、アクセス履歴には、アクセス日時、認証結果、パスワード通知済みか否かについてのデータが、アクセス毎に含まれる。但し、パスワード通知済みか否かのデータについては不要の場合もある。
次に、第４図乃至第１８図を用いて第１図に示したシステムの処理内容について説明する。ユーザは、会員制サービスの提供を受けようとしてあるサイトにアクセスしたが、パスワードを失念してしまったことに気付いたとする。なお、ＩＤを忘れてしまっていても同様である。このような場合、ユーザは、そのサイトのログインＩＤ及びパスワード照会ボタンなどをクリックして、ユーザ端末（ここではユーザ端末３とする）にログインＩＤ及びパスワード照会ページへアクセスさせる（ステップＳ１）。なお、この際ログインＩＤ及びパスワード照会ボタンが設けられているページが表示されているブラウザのウインドウとは別のウインドウを開いて、当該別のウインドウからログインＩＤ及びパスワード照会ページにアクセスさせてもよい。サーバ５は、ユーザ端末３からのアクセスに応答して、ログインＩＤ及びパスワード照会ページ・データを当該ユーザ端末３に送信する（ステップＳ３）。ユーザ端末３は、サーバ５からログインＩＤ及びパスワード照会ページ・データを受信し、表示装置に表示する（ステップＳ５）。
例えば第５図に示すような表示がなされる。第５図の例では、ログインＩＤ及びパスワード照会ページは、照会手順を説明するページである。第５図に示すように以後、登録したメールアドレスの入力に対応して、仮パスワード（アクセスキーの意）を発行してＳＳＬで提供し、また照会用ＵＲＬをメールで通知する。その後、ユーザからの照会用ＵＲＬへのアクセスに応答して、メールアドレスと仮パスワードの入力を求め、当該メールアドレスと仮パスワードと照会用ＵＲＬとによる認証が成功すれば、ログインＩＤ及びパスワードをユーザに提示するようになっている。ユーザはこの手順を理解した上で、次へボタン５０１をクリックする。
ユーザ端末３は、ユーザによる確認入力であるクリックを受け付けると、次へボタン５０１の次のページへアクセスする（ステップＳ７）。サーバ５は、ユーザ端末３からの次のページへのアクセスを受信し（ステップＳ９）、次のページであるメールアドレス入力ページのページ・データを当該ユーザ端末３に送信する（ステップＳ１１）。ユーザ端末３は、サーバ５からメールアドレス入力ページ・データを受信し、表示装置に表示する（ステップＳ１３）。
例えば第６図に示すような表示がなされる。第６図の例では、登録済みのメールアドレスを入力するための入力欄６０１と、次のページに移行するための次へボタン６０２とが設けられている。ユーザは、入力欄６０１にメールアドレスを入力すると共に次へボタン６０２をクリックする。なお、ユーザはメールアドレスを複数利用していても、通常忘れてしまうほど多くのメールアドレスを利用してはおらず、通常はよく使用するメールアドレスを登録するので、このページにおいてメールアドレスが入力できない場合はあまりないと考えられる。
ユーザ端末３は、ユーザからのメールアドレス入力及びクリックを受け付け、メールアドレス・データをサーバ５に送信する（ステップＳ１５）。サーバ５は、ユーザ端末３からメールアドレス・データを受信し（ステップＳ１７）、マスタＤＢ５１を参照してメールアドレス確認処理を実施する（ステップＳ１９）。すなわち、メールアドレスがマスタＤＢ５１に登録されているか否かを判断する（ステップＳ２１）。そして、メールアドレスが登録されていないと判断された場合には（ステップＳ２１：Ｎｏルート）、ステップＳ１１に戻る。すなわち、メールアドレスの再入力を求める。なお、ステップＳ１３で表示される画面は、例えば第６図のような画面に「入力いただいたＥ−ｍａｉｌアドレスは、ご登録がありませんでした。」というメッセージを追加したものであっても良いし、第７図に示すような画面となる場合もある。
第７図の例では、メールアドレスの再入力を行うための入力欄７０１と、次へボタン７０２と、登録しているメールアドレスが不明な場合に別途ＩＤ及びパスワードなどの照会を行うためのリンク７０３とが設けられている。ユーザは、メールアドレスを入力欄７０１に再入力して次へボタン７０２をクリックする。なお登録メールアドレスが不明である場合には、リンク７０３をクリックすると、例えば第８図のような表示がなされる。第８図では、本実施例とは別のパスワード照会のためのページであって、ログインＩＤ入力欄８０１と、氏名入力欄８０２と、メールアドレス入力欄８０３と、送信ボタン８０４とが設けられている。ここでユーザは、ログインＩＤ、氏名、使用可能なメールアドレスを入力して、送信ボタン８０４をクリックする。そうすると、第８図にも示してあるように受付メールが、入力されたメールアドレスに送信され、当該受付メールにて後の手続きについて説明がなされ、別途パスワードなどが通知される。なお、第８図以降の処理については本実施例とは直接関係無いので、これ以上説明しない。
一方、メールアドレスがマスタＤＢ５１に登録されていると判断された場合には（ステップＳ２１：Ｙｅｓルート）、アクセスキーを発行し、メールアドレスと共にアクセスＤＢ５２に新規レコードとして登録する（ステップＳ２２）。そして、アクセスキー通知ページ・データを生成し、ユーザ端末３にＳＳＬで送信する（ステップＳ２３）。ユーザ端末３は、サーバ５からアクセスキー通知ページ・データをＳＳＬで受信し、表示装置に表示する（ステップＳ２５）。
例えば、第９図のような表示がなされる。第９図では、アクセスキーである仮パスワード９０１が含まれている。これによりユーザは、アクセスキーを安全に取得することができる。このアクセスキーは後の処理で使用されるので、第９図にも示されているように、メモ又は印刷しておく方がよい。また、第９図にも示されているように、照会用ＵＲＬには有効期限が設定される。なお、本実施例では３日であるがこれに限定されるものではない。例えば数時間、数十分であってもよい。
また、サーバ５は、照会用ＵＲＬを生成し、有効期限と共にアクセスＤＢ５２に、上記のアクセスキー及びメールアドレスに対応して登録する（ステップＳ２７）。なお、有効期限ではなく、発行日時を登録して、有効期限をアクセス時に計算して求めるようにしても良い。そして、サーバ５は、アクセスキーに対応して登録されているメールアドレス宛に照会用ＵＲＬを含むメールを送信する（ステップＳ２９）。ユーザは、ユーザ端末３を操作して、照会用ＵＲＬを含むメールを受信させ、表示装置に表示させる（ステップＳ３１）。例えば第１０図のようなメールが表示される。第１０図の例では、照会用ＵＲＬのリンク１００１が含まれている。ユーザは、このリンク１００１をクリックすれば、照会用ＵＲＬへアクセスできるようになっている。
このような処理を実施することにより、アクセスキーと照会用ＵＲＬが別々に送信されるため、たとえ照会用ＵＲＬが第三者に知られるようになってもアクセスキーを知得されなければパスワードは漏洩しない。また逆に第三者にアクセスキーが知られるようになっても、照会用ＵＲＬを含むメールを受信できなければ、アクセスキーを入力できないのでパスワードは漏洩しない。なお、以下に説明するように、別人の照会用ＵＲＬで盗み見たアクセスキーを入力しても、パスワードを得ることはできないので、安全性が高まっている。
【実施例１】  実施例１は照会用ＵＲＬの有効期限のみ確認する処理例（第１１図乃至図１５）である。ユーザが、ステップＳ３１において受信したメールに含まれる照会用ＵＲＬのリンク１００１をクリックすると、ユーザ端末３は照会用ＵＲＬへアクセスする（ステップＳ４１）。サーバ５は、照会用ＵＲＬへのアクセスを受信し（ステップＳ４３）、当該照会用ＵＲＬが使用可能になっているかを判断する。実際には、当該照会用ＵＲＬが、アクセスＤＢ５２に登録が無いか又はアクセスＤＢ５２に登録されていても有効期限からさらに所定期間以上経過しているか（例えば削除フラグがオンに設定されるか等）判断する。もしそのような場合には例えば「Ｎｏｔ  Ｆｏｕｎｄ」といったメッセージを含むＷｅｂページ・データをユーザ端末３に送信する。ユーザ端末３は、当該Ｗｅｂページ・データを受信し、表示装置に表示する。
一方、照会用ＵＲＬがアクセスＤＢ５２に登録されている場合には、アクセス対象の照会用ＵＲＬを用いてアクセスＤＢ５２を参照し、対応するレコードを読み出すと共に、アクセス履歴に今回のアクセスのデータを追加する（ステップＳ４５）。ここでは、日時のデータをアクセス履歴に登録する。なお、アクセス元のＩＰアドレスをさらに登録するような場合もある。そして、システム時刻と読み出したレコードの有効期限とを比較して、今回のアクセスが有効期限内であるか判断する（ステップＳ４７）。有効期限内ではないと判断された場合には（ステップＳ４７：Ｎｏルート）、有効期限切れを通知するエラーメッセージをユーザ端末３に送信する。ユーザ端末３は、サーバ５から有効期限切れを通知するエラーメッセージを受信し、表示装置に表示する（ステップＳ４８）。例えば第１２図のような表示がなされる。第１２図の例では、有効期限切れ通知表示欄１２０２と、仮パスワード（アクセスキー）を発行するためのＷｅｂページ（第５図）へのリンク１２０１とが含まれている。ユーザは、例えばリンク１２０１をクリックして、再度アクセスキー発行を行う。
今回のアクセスが有効期限内であると判断された場合には（ステップＳ４７：Ｙｅｓルート）、現段階では照会用ＵＲＬが有効であるということだけが確認されたことになるので、メールアドレス及びアクセスキー入力ページ・データを生成し、ユーザ端末３に送信する（ステップＳ４９）。ユーザ端末３は、メールアドレス及びアクセスキー入力ページ・データを受信し、表示装置に表示する（ステップＳ５１）。例えば第１３図のような表示がなされる。第１３図の例では、メールアドレスの入力欄１３０１と、アクセスキー（図では仮パスワード）の入力欄１３０２と、次へボタン１３０３とが設けられている。ユーザは、登録しているメールアドレスをメールアドレスの入力欄１３０１に、取得したアクセスキーをアクセスキーの入力欄１３０２にそれぞれ入力し、次へボタン１３０３をクリックする。
ユーザ端末３は、メールアドレス及びアクセスキー入力を受け付け、次へボタン１３０３のクリックによる送信指示に応答して、メールアドレス及びアクセスキーをサーバ５に送信する（ステップＳ５３）。サーバ５は、メールアドレス及びアクセスキーをユーザ端末３から受信し、記憶装置に格納する。そして、ステップＳ４５において読み出したレコードに含まれるメールアドレス及びアクセスキーと受信したメールアドレス及びアクセスキーとを用いて認証処理を実施する（ステップＳ５５）。すなわち、ステップＳ４５において読み出したレコードに含まれるメールアドレスと受信したメールアドレスとを比較し、ステップＳ４５において読み出したレコードに含まれるアクセスキーと受信したアクセスキーとを比較する。メールアドレス及びアクセスキーの両方が一致していれば認証は成功である。このような比較により、照会用ＵＲＬとアクセスキー及びメールアドレスとの対応関係が正当なものであるか判断することができる。なお、ステップＳ４５ではなくステップＳ５５において照会用ＵＲＬからアクセスＤＢ５２を参照して、該当するレコードを読み出すようにしても良い。認証結果については、本アクセスに係る照会用ＵＲＬに対応するレコード（又は受信したアクセスキー又はメールアドレスに対応するレコード）に、ＮＧ又はＯＫなどの成否を表すデータを登録する（ステップＳ５７）。なお、認証が失敗した場合には（ステップＳ５９：Ｎｏルート）、メールアドレス又はアクセスキー若しくはその両方が間違っているためステップＳ４９に戻る。この際、アクセスＤＢ５２に照会用ＵＲＬに対応してアクセス履歴を追加する。
例えばこのような場合には第１３図ではなく例えば第１４図のような表示がなされる。第１４図の例では、エラーメッセージ表示欄１４０１と、メールアドレスの入力欄１４０２と、アクセスキー（図では仮パスワード）の入力欄１４０３と、次へボタン１４０４とが設けられている。ユーザは、再度、メールアドレスの入力欄１４０２にメールアドレスを、アクセスキーの入力欄１４０３にアクセスキーを入力し、次へボタン１４０４をクリックする。
一方、認証に成功した場合には（ステップＳ５９：Ｙｅｓルート）、マスタＤＢ５１からメールアドレスに対応するＩＤ及びパスワードを読み出し（ステップＳ６１）、当該ＩＤ及びパスワードを含むＷｅｂページ・データを生成し、例えばＳＳＬで送信する（ステップＳ６３）。ユーザ端末３は、サーバ５からＩＤ及びパスワードを含むＷｅｂページ・データを例えばＳＳＬで受信し、表示装置に表示する（ステップＳ６５）。例えば第１５図のような表示がなされる。第１５図の例では、ログインＩＤ表示部１５０１と、パスワード表示部１５０２と、ログインページへのリンク１５０３とが含まれている。このようにすれば、本人であることが確認された後に、ＩＤ及びパスワードがＳＳＬでユーザ端末３に送信されるので、安全なパスワード通知が実現される。なお、以上のような処理がサーバ５では全て自動的に実行されるので、システム管理者がパスワード通知作業に忙殺されることも無くなる。
ユーザは、例えば第１５図のようなページを印刷したり、ＩＤ及びパスワードのメモをとったりして、本来のログイン時に用いる。もし、ユーザが、直ぐにログインする場合には、ログインページへのリンク１５０３をクリックする。ユーザ端末３は、ログイン指示であるリンク１５０３のクリックを受け付け、ログインページへアクセスする（ステップＳ６７）。サーバ５は、ユーザ端末３からログインページへのアクセスを受信し（ステップＳ６９）、ログインページ・データをユーザ端末３に送信する（ステップＳ７１）。ユーザ端末３は、サーバ５からログインページ・データを受信し、表示装置に表示する（ステップＳ７３）。このようにして取得したＩＤ及びパスワードにより、本来の会員制サービスにログインすることができるようになる。
なお、第１１図には示していないが、例えばステップＳ６３の後に又は確実にはステップＳ６９の後に、アクセスＤＢ５２に、本処理に係るアクセス（アクセス先の照会用ＵＲＬに対応するレコード又は受信したメールアドレス又はアクセスキーに対応するレコード）のアクセス履歴の情報として、パスワード通知済みを表すデータを登録するようにしても良い。なお、第１１図の処理では当該データは用いないので、登録しなくとも良い。
さらに有効期限内であるか確認するステップを照会用ＵＲＬアクセス受信後直ぐに行っているが、有効期限経過後か否かにかかわらずメールアドレス及びアクセスキー入力ページ・データを送信して、ユーザ端末３からメールアドレス及びアクセスキーを受信した後に、認証処理と共に又は認証処理に先立って有効期限内か否かを判断するようにしても良い。
【実施例２】  実施例２は、一度でも照会用ＵＲＬにアクセスした場合には二度と同じ照会用ＵＲＬを用いることができないというポリシーを採用した場合の処理例（第１６図）である。これにより、例えば第三者が先にアクセスしたということを本人が知ることができるようになるので、パスワードが盗まれた可能性があることをシステム管理者に通知することも可能になる。また、本人より後に第三者がアクセスしようとした場合には既に使用できなくなっているので、非常に安全である。
ユーザが、ステップＳ３１において受信したメールに含まれる照会用ＵＲＬのリンク１００１をクリックすると、ユーザ端末３は照会用ＵＲＬへアクセスする（ステップＳ８１）。サーバ５は、照会用ＵＲＬへのアクセスを受信し（ステップＳ８３）、当該照会用ＵＲＬが使用可能になっているか判断する。もし使用不可となっている場合には例えば「Ｎｏｔ  Ｆｏｕｎｄ」といったメッセージを含むＷｅｂページ・データをユーザ端末３に送信する。ユーザ端末３は、当該Ｗｅｂページ・データを受信し、表示装置に表示する。
一方、当該照会用ＵＲＬがアクセスＤＢ５２に登録されている場合には、アクセス対象の照会用ＵＲＬを用いてアクセスＤＢ５２を参照し、対応するレコードを読み出すと共に、アクセス履歴に今回のアクセスのデータを追加する（ステップＳ８５）。ここでは、日時のデータをアクセス履歴に登録する。そして、今回のアクセスが最初のアクセスであるか判断する（ステップＳ８７）。すなわち今回登録したアクセス履歴以外に何らの履歴も登録されていない状態であるか判断する。もし、一度でもアクセスがあったことが登録されている場合には（ステップＳ８７：Ｎｏルート）、エラーメッセージ又はエラーメッセージを含むアクセス履歴通知をユーザ端末３に送信する。ユーザ端末３は、サーバ５からエラーメッセージ又はエラーメッセージを含むアクセス履歴通知を受信し、表示装置に表示する（ステップＳ８８）。アクセス履歴通知は、例えば「既に２００２年１１月２３日に一度アクセスされていますので、本照会用ＵＲＬでパスワードをお知らせすることはできません。お心当たりのない方は、システム管理者にお問い合わせください。既に本照会用ＵＲＬにアクセスしたことのある方は、再度仮パスワード（アクセスキー）を発行させてください」といったメッセージを含む。
一方初めてのアクセスであることが確認された場合には（ステップＳ８７：Ｙｅｓルート）、システム時刻とステップＳ８５で読み出したレコードの有効期限とを比較して、今回のアクセスが有効期限内であるか判断する（ステップＳ８９）。有効期限内ではないと判断された場合には（ステップＳ８９：Ｎｏルート）、有効期限切れを通知するエラーメッセージをユーザ端末３に送信する。ユーザ端末３は、サーバ５から有効期限切れを通知するエラーメッセージを受信し、表示装置に表示する（ステップＳ９０）。例えば第１２図にような表示がなされる。
今回のアクセスが有効期限内であると判断された場合には（ステップＳ８９：Ｙｅｓルート）、メールアドレス及びアクセスキー入力ページ・データを生成し、ユーザ端末３に送信する（ステップＳ９１）。ユーザ端末３は、メールアドレス及びアクセスキー入力ページ・データを受信し、表示装置に表示する（ステップＳ９３）。例えば第１３図のような表示がなされる。
ユーザ端末３は、メールアドレス及びアクセスキー入力を受け付け、次へボタン１３０３のクリックによる送信指示に応答して、メールアドレス及びアクセスキーをサーバ５に送信する（ステップＳ９５）。サーバ５は、メールアドレス及びアクセスキーをユーザ端末３から受信し、記憶装置に格納する。そして、ステップＳ８５において読み出したレコードに含まれるメールアドレス及びアクセスキーと受信したメールアドレス及びアクセスキーとを用いて認証処理を実施する（ステップＳ９７）。すなわち、ステップＳ８５において読み出したレコードに含まれるメールアドレスと受信したメールアドレスとを比較し、ステップＳ８５において読み出したレコードに含まれるアクセスキーと受信したアクセスキーとを比較する。メールアドレス及びアクセスキーの両方が一致していれば認証は成功である。このような比較により、照会用ＵＲＬとアクセスキー及びメールアドレスとの対応関係が正当なものであるか判断することができる。認証結果については、本アクセスに係る照会用ＵＲＬに対応するレコード（又は受信したアクセスキー又はメールアドレスに対応するレコード）に、ＮＧ又はＯＫなどの成否を表すデータを登録する（ステップＳ９９）。なお、認証が失敗した場合には（ステップＳ１０１：Ｎｏルート）、二度と同じ照会用ＵＲＬは使用できないので、サーバ５は「アクセスキー又はメールアドレスが異なります。再度仮パスワード（アクセスキー）を発行してください」といったエラーメッセージをユーザ端末３に送信する。ユーザ端末３は、サーバ５からエラーメッセージを受信し、表示装置に表示する（ステップＳ１０２）。正当なユーザの場合には、再度アクセスキーを発行することにより、パスワードを取得することができる。一方、認証に成功した場合には（ステップＳ１０１：Ｙｅｓルート）、端子Ａを介して第１１図のステップＳ６１に移行して、同様の処理を実施する。
このようにすれば、本人であることが確認された後に、ＩＤ及びパスワードがＳＳＬでユーザ端末３に送信されるので、安全なパスワード通知が実現される。なお、以上のような処理がサーバ５では全て自動的に実行されるので、システム管理者がパスワード通知作業に忙殺されることも無くなる。
なお、初めてのアクセスか及び有効期限内であるか確認するステップを照会用ＵＲＬアクセス受信後直ぐに行っているが、初めてのアクセスであるか否か又は有効期限経過後であるか否かにかかわらずメールアドレス及びアクセスキー入力ページ・データを送信して、ユーザ端末３からメールアドレス及びアクセスキーを受信した後に、認証処理と共に又は認証処理に先立って初めてのアクセスか否か及び有効期限内か否かを判断するようにしても良い。
【実施例３】  実施例３は、既に一度でも同じ照会用ＵＲＬ経由でパスワードを通知している場合には、二度と同じ照会用ＵＲＬ経由でパスワードを通知しないというポリシーを採用した場合の処理例（第１７図）である。
ユーザが、ステップＳ３１において受信したメールに含まれる照会用ＵＲＬのリンク１００１をクリックすると、ユーザ端末３は照会用ＵＲＬへアクセスする（ステップＳ１１１）。サーバ５は、照会用ＵＲＬへのアクセスを受信し（ステップＳ１１３）、当該照会用ＵＲＬが使用可能になっているか判断する。もし使用不可であると判断された場合には例えば「Ｎｏｔ  Ｆｏｕｎｄ」といったメッセージを含むＷｅｂページ・データをユーザ端末３に送信する。ユーザ端末３は、当該Ｗｅｂページ・データを受信し、表示装置に表示する。
一方、当該照会用ＵＲＬがアクセスＤＢ５２に登録されている場合には、アクセス対象の照会用ＵＲＬを用いてアクセスＤＢ５２を参照し、対応するレコードを読み出すと共に、アクセス履歴に今回のアクセスのデータを追加する（ステップＳ１１５）。ここでは、日時のデータをアクセス履歴に登録する。なお、アクセス元のＩＰアドレスをさらに登録するような場合もある。そして、読み出したアクセス履歴に基づき、既に一回同じ照会用ＵＲＬ経由でパスワード（及びＩＤ）を提示しているか判断する（ステップＳ１１７）。より具体的には、アクセス履歴にパスワード通知済みを表すデータが含まれるか判断する。既に同じ照会用ＵＲＬ経由でパスワードを通知しているので、再度同じ照会用ＵＲＬにアクセスしている場合には、何らかの問題が発生している可能性があるためである。すなわち、第三者が先に不正にパスワードを取得してしまった場合や、本人がパスワードを取得した後に第三者が不正にパスワードを取得しようとしている場合の可能性があるためである。
既に一回同じ照会用ＵＲＬ経由でパスワードを提示していると判断された場合には（ステップＳ１１７：Ｙｅｓルート）、エラーメッセージ又はエラーメッセージを含むアクセス履歴通知をユーザ端末３に送信する。ユーザ端末３は、サーバ５からエラーメッセージ又はエラーメッセージを含むアクセス履歴通知を受信し、表示装置に表示する（ステップＳ１１８）。アクセス履歴通知は、例えば「既に２００２年１１月２３日に一度ＩＤ及びパスワードを提示しておりますので、本照会用ＵＲＬでＩＤ及びパスワードをお知らせすることはできません。お心当たりのない方は、システム管理者にお問い合わせください。既に本照会用ＵＲＬを経由してパスワードを取得されたことのある方は、再度仮パスワード（アクセスキー）を発行させてください」といったメッセージを含む。
一方未だ当該照会用ＵＲＬ経由でパスワードを提示したことが無いことが確認された場合には（ステップＳ１１７：Ｎｏルート）、システム時刻と読み出したレコードの有効期限とを比較して、今回のアクセスが有効期限内であるか判断する（ステップＳ１１９）。もし、有効期限内ではないと判断された場合には（ステップＳ１１９：Ｎｏルート）、有効期限切れを通知するエラーメッセージをユーザ端末３に送信する。ユーザ端末３は、サーバ５から有効期限切れを通知するエラーメッセージを受信し、表示装置に表示する（ステップＳ１２０）。例えば第１２図にような表示がなされる。
今回のアクセスが有効期限内であると判断された場合には（ステップＳ１１９：Ｙｅｓルート）、メールアドレス及びアクセスキー入力ページ・データを生成し、ユーザ端末３に送信する（ステップＳ１２１）。ユーザ端末３は、メールアドレス及びアクセスキー入力ページ・データを受信し、表示装置に表示する（ステップＳ１２３）。例えば第１３図のような表示がなされる。
ユーザ端末３は、メールアドレス及びアクセスキー入力を受け付け、次へボタン１３０３のクリックによる送信指示に応答して、メールアドレス及びアクセスキーをサーバ５に送信する（ステップＳ１２５）。サーバ５は、メールアドレス及びアクセスキーをユーザ端末３から受信し、記憶装置に格納する。そして、ステップＳ１１５において読み出したレコードに含まれるメールアドレス及びアクセスキーと受信したメールアドレス及びアクセスキーとを用いて認証処理を実施する（ステップＳ１２７）。すなわち、ステップＳ１１５において読み出したレコードに含まれるメールアドレスと受信したメールアドレスとを比較し、ステップＳ１１５において読み出したレコードに含まれるアクセスキーと受信したアクセスキーとを比較する。メールアドレス及びアクセスキーの両方が一致していれば認証は成功である。このような比較により、照会用ＵＲＬとアクセスキー及びメールアドレスとの対応関係が正当なものであるか判断することができる。なお、ステップＳ１１５ではなくステップＳ１２７において照会用ＵＲＬからアクセスＤＢ５２を参照して、該当するレコードを読み出すようにしても良い。認証結果については、本アクセスに係る照会用ＵＲＬに対応するレコード（又は受信したアクセスキー又はメールアドレスに対応するレコード）に、ＮＧ又はＯＫなどの成否を表すデータを登録する（ステップＳ１２９）。なお、認証が失敗した場合には（ステップＳ１３１：Ｎｏルート）、メールアドレス又はアクセスキー若しくはその両方が間違っているためステップＳ１２１に戻る。例えばこのような場合には第１３図ではなく例えば第１４図のような表示がなされる。
一方、認証に成功した場合には（ステップＳ１３１：Ｙｅｓルート）、マスタＤＢ５１からメールアドレスに対応するＩＤ及びパスワードを読み出し（ステップＳ１３３）、当該ＩＤ及びパスワードを含むＷｅｂページ・データを例えばＳＳＬで送信する（ステップＳ１３５）。ユーザ端末３は、サーバ５からＩＤ及びパスワードを含むＷｅｂページ・データを例えばＳＳＬで受信し、表示装置に表示する（ステップＳ１３７）。例えば第１５図のような表示がなされる。このようにすれば、本人であることが確認された後に、ＩＤ及びパスワードがＳＳＬでユーザ端末３に送信されるので、安全なパスワード通知が実現される。なお、以上の処理がサーバ５では全て自動的に実行されるので、システム管理者がパスワード通知作業に忙殺されることも無くなる。
ユーザは、例えば第１５図のようなページを印刷したり、ＩＤ及びパスワードのメモをとったりして、本来のログイン時に用いる。もし、ユーザが、直ぐにログインする場合には、ログインページへのリンク１５０３をクリックする。ユーザ端末３は、ログイン指示であるリンク１５０３のクリックを受け付け、ログインページへアクセスする（ステップＳ１３９）。サーバ５は、ユーザ端末３からログインページへのアクセスを受信し、パスワード通知済みを表すデータを、本照会用ＵＲＬ、受信したアクセスキー又はメールアドレスに対応するアクセス履歴に登録する（ステップＳ１４１）。なお、パスワード通知済みを表すデータの登録については、ログインページへのアクセスの受信後ではなく、ＩＤ及びパスワードを含むページ・データの送信後に実施しても良い。そして端子Ｂを介して第１１図のステップＳ７１に移行する。このようにして取得したＩＤ及びパスワードにより、本来の会員制サービスにログインすることができるようになる。
なお、既に同じ照会用ＵＲＬ経由でパスワードを提示しているかを確認するステップ及び有効期限内であるか確認するステップを照会用ＵＲＬアクセス受信後直ぐに行っているが、既に同じ照会用ＵＲＬ経由でパスワードを提示しているか否か又は有効期限経過後であるか否かにかかわらずメールアドレス及びアクセスキー入力ページ・データを送信して、ユーザ端末３からメールアドレス及びアクセスキーを受信した後に、認証処理と共に又は認証処理に先立って既に同じ照会用ＵＲＬ経由でパスワードを提示しているか否か及び有効期限内か否かを判断するようにしても良い。
【実施例４】  実施例４は、一度でも認証に失敗している場合には二度と同じ照会用ＵＲＬを用いることができないというポリシーを採用した場合の処理例（第１８図）である。これにより、例えば第三者が照会用ＵＲＬを偶然又は不正に取得したがアクセスキーを取得できていない場合に、アクセスキーを総当り方式などで試すようなケースを回避することができる。
実施例４では、ユーザが、ステップＳ３１において受信したメールに含まれる照会用ＵＲＬのリンク１００１をクリックすると、ユーザ端末３は照会用ＵＲＬへアクセスする（ステップＳ１５１）。サーバ５は、照会用ＵＲＬへのアクセスを受信し（ステップＳ１５３）、当該照会用ＵＲＬが使用可能になっているか判断する。もし使用不可となっている場合には例えば「Ｎｏｔ  Ｆｏｕｎｄ」といったメッセージを含むＷｅｂページ・データをユーザ端末３に送信する。ユーザ端末３は、当該Ｗｅｂページ・データを受信し、表示装置に表示する。
一方、当該照会用ＵＲＬがアクセスＤＢ５２に登録されている場合には、アクセス対象の照会用ＵＲＬを用いてアクセスＤＢ５２を参照し、対応するレコードを読み出すと共に、アクセス履歴に今回のアクセスのデータを追加する（ステップＳ１５５）。ここでは、日時のデータをアクセス履歴に登録する。そして、一度でも認証失敗があったか否かを判断する（ステップＳ１５７）。すなわち読み出したレコードに含まれるアクセス履歴に認証失敗が登録されていない状態であるか判断する。もし、一度でも認証失敗が登録されていた場合には（ステップＳ１５７：Ｙｅｓルート）、エラーメッセージ又はエラーメッセージを含むアクセス履歴通知をユーザ端末３に送信する。ユーザ端末３は、サーバ５からエラーメッセージ又はエラーメッセージを含むアクセス履歴通知を受信し、表示装置に表示する（ステップＳ１５８）。アクセス履歴通知は、例えば「既に２００２年１１月２３日に認証に失敗されていますので、本照会用ＵＲＬでパスワードをお知らせすることはできません。お心当たりのない方は、システム管理者にお問い合わせください。お心当りのある方は、再度仮パスワード（アクセスキー）を発行させてください」といったメッセージを含む。
一方一度も認証失敗が登録されていないことが確認された場合には（ステップＳ１５７：Ｎｏルート）、システム時刻とステップＳ１５５で読み出したレコードの有効期限とを比較して、今回のアクセスが有効期限内であるか判断する（ステップＳ１５９）。もし、有効期限内ではないと判断された場合には（ステップＳ１５９：Ｎｏルート）、有効期限切れを通知するエラーメッセージをユーザ端末３に送信する。ユーザ端末３は、サーバ５から有効期限切れを通知するエラーメッセージを受信し、表示装置に表示する（ステップＳ１６０）。例えば第１２図にような表示がなされる。
今回のアクセスが有効期限内であると判断された場合には（ステップＳ１５９：Ｙｅｓルート）、メールアドレス及びアクセスキー入力ページ・データを生成し、ユーザ端末３に送信する（ステップＳ１６１）。ユーザ端末３は、メールアドレス及びアクセスキー入力ページ・データを受信し、表示装置に表示する（ステップＳ１６３）。例えば第１３図のような表示がなされる。
ユーザ端末３は、メールアドレス及びアクセスキー入力を受け付け、次へボタン１３０３のクリックによる送信指示に応答して、メールアドレス及びアクセスキーをサーバ５に送信する（ステップＳ１６５）。サーバ５は、メールアドレス及びアクセスキーをユーザ端末３から受信し、記憶装置に格納する。そして、ステップＳ１５５において読み出したレコードに含まれるメールアドレス及びアクセスキーと受信したメールアドレス及びアクセスキーとを用いて認証処理を実施する（ステップＳ１６７）。すなわち、ステップＳ１５５において読み出したレコードに含まれるメールアドレスと受信したメールアドレスとを比較し、ステップＳ１５５において読み出したレコードに含まれるアクセスキーと受信したアクセスキーとを比較する。メールアドレス及びアクセスキーの両方が一致していれば認証は成功である。このような比較により、照会用ＵＲＬとアクセスキー及びメールアドレスとの対応関係が正当なものであるか判断することができる。認証結果については、本アクセスに係る照会用ＵＲＬに対応するレコード（又は受信したアクセスキー又はメールアドレスに対応するレコード）に、ＮＧ又はＯＫなどの成否データを登録する（ステップＳ１６９）。なお、認証が失敗した場合には（ステップＳ１７１：Ｎｏルート）、二度と同じ照会用ＵＲＬは使用できないので、サーバ５は「アクセスキー又はメールアドレスが異なります。再度仮パスワード（アクセスキー）を発行してください」といったエラーメッセージをユーザ端末３に送信する。ユーザ端末３は、サーバ５からエラーメッセージを受信し、表示装置に表示する（ステップＳ１７２）。正当なユーザの場合には、再度アクセスキーを発行することにより、パスワードを取得することができる。一方、認証に成功した場合には（ステップＳ１７１：Ｙｅｓルート）、端子Ａを介して第１１図のステップＳ６１に移行して、同様の処理を実施する。
このようにすれば、本人であることが確認された後に、ＩＤ及びパスワードがＳＳＬでユーザ端末３に送信されるので、安全なパスワード通知が実現される。なお、以上の処理がサーバ５では全て自動的に実行されるので、システム管理者がパスワード通知作業に忙殺されることも無くなる。
さらに一度でも認証に失敗したことがあるか及び有効期限内であるか確認するステップを照会用ＵＲＬアクセス受信後直ぐに行っているが、一度でも認証に失敗したことがあるか否か又は有効期限経過後であるか否かにかかわらずメールアドレス及びアクセスキー入力ページ・データを送信して、ユーザ端末３からメールアドレス及びアクセスキーを受信した後に、認証処理と共に又は認証処理に先立って初めてのアクセスか否か及び有効期限内か否かを判断するようにしても良い。
以上本発明の実施例を説明したが、本発明はこれに限定されない。例えば実施例１乃至４を任意に組み合わせることも可能である。さらに、アクセス履歴などについて新たな条件を設定することも可能である。
また、上で述べた表示画面例は一例であって、同様の内容を表す他の構成の画面を採用することも可能である。さらに、本実施例における一画面を複数の画面に分割して表示するようにしても良い。
さらに、上ではパスワードを失念した人がパスワードを再発行する場面を説明したが、例えばパスワードの新規発行についても適用可能である。
【図１】
2004055684.tif 000003
【図２】
2004055684.tif 000004
【図３】
2004055684.tif 000005
【図４】
2004055684.tif 000006
【図５】
2004055684.tif 000007
【図６】
2004055684.tif 000008
【図７】
2004055684.tif 000009
【図８】
2004055684.tif 000010
【図９】
2004055684.tif 000011
【図１０】
2004055684.tif 000012
【図１２】
2004055684.tif 000013
【図１３】
2004055684.tif 000014
【図１１】
2004055684.tif 000015
【図１４】
2004055684.tif 000016
【図１５】
2004055684.tif 000017
【図１６】
2004055684.tif 000018
【図１７】
2004055684.tif 000019
【図１８】
2004055684.tif 000020
【手続補正書】
【提出日】平成17年1月18日(2005.1.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのユニフォーム・リソース・ロケータ（ＵＲＬ）を生成して記憶装置に登録する登録ステップと、
生成された前記アクセスキー及び前記ＵＲＬを、受信した前記メールアドレス宛のメール及び他の手段にて、前記ユーザ宛に別々に送信する送信ステップと、
アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーと前記ＵＲＬとの対応関係を含む所定の条件を満たしているか判断する判断ステップと、
前記所定の条件を満たしている場合には、前記ユーザの端末にパスワードを通知する通知ステップと、
を含むパスワード通知方法。
【請求項２】
前記登録ステップが、
前記ユーザの端末から受信したメールアドレスが予め登録されたメールアドレスか否かを判断するステップ
を含むことを特徴とする請求項１記載のパスワード通知方法。
【請求項３】
前記登録ステップが、
前記アクセスキー及びＵＲＬに対応して、受信したメールアドレスを記憶装置に登録するステップ、
を含むことを特徴とする請求項１記載のパスワード通知方法。
【請求項４】
前記他の手段が、暗号化されたウェブ・ページであることを特徴とする請求項１記載のパスワード通知方法。
【請求項５】
ユーザの端末からメールアドレスを受信した場合、アクセスキー及び当該アクセスキーに対応し且つ当該アクセスキーの確認を行うためのユニフォーム・リソース・ロケータ（ＵＲＬ）を生成して記憶装置に登録する登録ステップと、
生成された前記アクセスキー及び前記ＵＲＬを、受信した前記メールアドレス宛のメール及び他の手段にて、前記ユーザ宛に別々に送信する送信ステップと、
アクセスキーの確認を行うためのＵＲＬへのアクセスに対応してユーザの端末からアクセスキーを受信した場合には、少なくとも当該受信したアクセスキーとＵＲＬとの対応関係を含む所定の条件を満たしているか判断する判断ステップと、
前記所定の条件を満たしている場合には、前記ユーザの端末にパスワードを通知する通知ステップと、
をコンピュータに実行させるためのプログラム。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図５
【補正方法】変更
【補正の内容】
【図５】
2004055684.tif 000021
【国際調査報告】
2004055684.tif 000022
2004055684.tif 000023
2004055684.tif 000024
2004055684.tif 000025