(57)【要約】【課題】  契約者の本人認証機能を備えた取引システムにおいて、不正アクセスに関する情報を契約者に速やかに通知するとともに、ログイン失敗により認証機能がロックされた場合に契約者本人による認証機能のリカバリが可能な本人認証機能のリカバリシステムを提供する。【解決手段】  本人認証機能を備えた取引システムの外に、リカバリ情報を表示するためのサブシステムを設ける。認証機能がロックされる毎に個別にリカバリ情報を表示するアドレスを割り当てて、契約者には該アドレスを通知することによってリカバリに必要な情報にアクセスさせる。該情報にはリカバリ権限を特定する情報を埋め込んでおき、所定の期間が経過するとアクセス不可となるよう設定すると、サブシステム経由で行われたリカバリ要求を正当な契約者からの要求であると判断することによって、情報の安全性を確保しながら、本人認証機能のリカバリを行わせることができる。【選択図】        図２
2007310630.tif 000002
【特許請求の範囲】
【請求項１】
契約者の本人認証機能を備えた取引システムと、前記取引システムへのログイン失敗により認証機能がロックされた際に再ログインのためのリカバリ情報を表示するためのサブシステムとからなる本人認証機能のリカバリシステムであって、前記取引システムは、
契約者毎に、本人認証のための認証情報と、前記契約者に情報を通知するための通知先と、認証機能ロックの有無と、リカバリ権限の有無と、前記リカバリ情報を表示するリカバリ情報ファイルの記憶領域を指定したアドレス情報と、を少なくとも含む契約者情報を記憶する契約者情報記憶手段と、
ログイン失敗の操作が所定の条件に合致すると、前記契約者情報記憶手段において対応する契約者の契約者情報の認証機能ロックを有、リカバリ権限を有とし、新たなアドレス情報を記憶させ、前記契約者情報に記憶された通知先に前記アドレス情報を含むリカバリ通知を送信するリカバリ通知送信手段と、
前記サブシステムに、前記アドレス情報により指定される記憶領域に、前記契約者と前記契約者に付与されたリカバリ権限を識別するためのリカバリ権限情報が埋め込まれたリカバリ情報ファイルを記憶させることを要求するリカバリ情報要求手段と、
契約者の操作する端末から、前記リカバリ権限情報が付与された認証機能のロックを解除するためのリカバリ要求を受信するリカバリ要求受信手段と、
前記リカバリ要求に付与されたリカバリ権限情報から契約者を特定し、前記契約者情報記憶手段において対応する契約者の契約者情報を参照し、リカバリ権限が有となっていて、かつリカバリ権限情報から識別されるリカバリ権限を所定の契約者情報と照合して所定の条件に一致することを確認すると、正当なリカバリ要求であると判定するリカバリ権限判定手段と、
前記リカバリ権限判定手段が正当なリカバリ要求であると判定すると、前記端末に再ログインのための認証情報の入力画面を表示させる再ログイン画面表示手段と、
前記端末から、前記入力画面に入力された認証情報を受信すると、前記契約者情報記憶手段において対応する契約者の契約者情報に含まれる認証情報と照合して、認証情報が一致する場合には、前記契約者情報に含まれる認証機能ロックを無に、かつリカバリ権限を無に更新する認証機能リカバリ手段と、を備えていて、
前記サブシステムに記憶されたリカバリ情報ファイルは、所定の期間が経過すると前記アドレス情報を指定してもアクセス不可となるよう設定されていること
を特徴とするリカバリシステム。
【請求項２】
前記サブシステムは、前記アドレス情報を暗号化した情報をリカバリ権限情報としてリカバリ情報ファイルに埋め込んで、
前記リカバリ権限判定手段は、前記リカバリ権限情報を複合化して、前記契約者情報に含まれるアドレス情報と照合して、正当なリカバリ要求であるかを判定すること
を特徴とする請求項１記載のリカバリシステム。
【請求項３】
前記リカバリ通知送信手段がリカバリ通知を送信する際には、前記契約者情報記憶手段において対応する契約者の契約者情報に新たに設定したリカバリ権限を識別するための識別コードを記憶させ、
前記サブシステムは、前記識別コードをリカバリ権限情報としてリカバリ情報ファイルに埋め込んで、
前記リカバリ権限判定手段は、前記リカバリ要求に付与された識別コードを前記契約者情報に含まれる識別コードと照合して、正当なリカバリ要求であるかを判定すること
を特徴とする請求項１記載のリカバリシステム。
【請求項４】
前記サブシステムは、前記リカバリ権限情報に代えてリカバリ要求の送信時に前記アドレス情報を付与させる命令を埋め込んで、
前記リカバリ権限判定手段は、前記リカバリ権限情報に代えて前記アドレス情報を受信し、前記契約者情報に含まれるアドレス情報と照合して、正当なリカバリ要求であるかを判定すること
を特徴とする請求項１記載のリカバリシステム。
【請求項５】
前記リカバリ通知送信手段がリカバリ通知を送信する際には、前記契約者情報記憶手段において対応する契約者の契約者情報に新たに設定したリカバリ権限の有効期限を記憶させ、
前記リカバリ権限判定手段は、前記リカバリ要求の受付時間が前記契約者情報に含まれる有効期限を経過している場合は、正当なリカバリ要求でないと判定すること
を特徴とする請求項１乃至４いずれかに記載のリカバリシステム。
【請求項６】
前記取引システムは、
前記契約者情報記憶手段に記憶された契約者情報において有効期限が到来した契約者情報を特定し、前記契約者情報に含まれるリカバリ権限を無に更新するとともに、前記契約者情報に含まれるアドレス情報を特定するアドレス情報特定手段と、
前記サブシステムに、前記アドレス情報特定手段が特定したアドレス情報に対応するリカバリ情報ファイルについて、前記アドレス情報を指定してもアクセス不可となるよう設定する命令を送信するリカバリ情報停止手段と、
を備えること特徴とする請求項５記載のリカバリシステム。
【請求項７】
前記リカバリ情報要求手段は、前記サブシステムに、前記リカバリ情報ファイルと関連付けて前記有効期限を記憶させることを要求し、
前記取引システムには、前記契約者情報記憶手段に記憶された契約者情報において有効期限が到来した契約者情報を特定し、前記契約者情報に含まれるリカバリ権限を無に更新するリカバリ権限消去手段が備えられ、
前記サブシステムには、前記リカバリ情報ファイルに関連付けられた有効期限が到来したリカバリ情報ファイルについて、前記リカバリ情報ファイルのアドレス情報を指定してもアクセス不可となるよう設定するリカバリ情報停止手段が備えられること
を特徴とする請求項５記載のリカバリシステム。
【請求項８】
前記認証機能リカバリ手段は、前記認証情報が一致する場合には、前記サブシステムに、前記契約者情報に含まれるアドレス情報に対応するリカバリ情報ファイルについて、前記アドレス情報を指定してもアクセス不可となるよう設定する命令を送信すること
を特徴とする請求項１乃至７いずれかに記載のリカバリシステム。
【請求項９】
契約者の本人認証機能を備えた取引システムと、前記取引システムへのログイン失敗により認証機能がロックされた際に再ログインのためのリカバリ情報を表示するためのサブシステムとにより実行される本人認証機能のリカバリ方法であって、
前記取引システムには、契約者毎に、本人認証のための認証情報と、前記契約者に情報を通知するための通知先と、認証機能ロックの有無と、リカバリ権限の有無と、前記リカバリ情報を表示するリカバリ情報ファイルの記憶領域を指定したアドレス情報と、を少なくとも含む契約者情報を記憶する契約者情報記憶部が備えられていて、
前記取引システムが、ログイン失敗の操作が所定の条件に合致すると、前記契約者情報記憶部において対応する契約者の契約者情報の認証機能ロックを有、リカバリ権限を有とし、新たなアドレス情報を記憶させ、前記契約者情報に記憶された通知先に前記アドレス情報を含むリカバリ通知を送信するリカバリ通知送信ステップと、
前記取引システムが、前記サブシステムに、前記アドレス情報により指定される記憶領域に、前記契約者と前記契約者に付与されたリカバリ権限を識別するためのリカバリ権限情報が埋め込まれたリカバリ情報ファイルを記憶させることを要求するリカバリ情報要求ステップと、
前記取引システムが、契約者の操作する端末から、前記リカバリ権限情報が付与された認証機能のロックを解除するためのリカバリ要求を受信するリカバリ要求受信ステップと、
前記取引システムが、前記リカバリ要求に付与されたリカバリ権限情報から契約者を特定し、前記契約者情報記憶部において対応する契約者の契約者情報を参照し、リカバリ権限が有となっていて、かつリカバリ権限情報から識別されるリカバリ権限を所定の契約者情報と照合して所定の条件に一致することを確認すると、正当なリカバリ要求であると判定するリカバリ権限判定ステップと、
前記取引システムが、前記リカバリ権限判定ステップで正当なリカバリ要求であると判定すると、前記端末に再ログインのための認証情報の入力画面を表示させる再ログイン画面表示ステップと、
前記取引システムが、前記端末から、前記入力画面に入力された認証情報を受信すると、前記契約者情報記憶部において対応する契約者の契約者情報に含まれる認証情報と照合して、認証情報が一致する場合には、前記契約者情報に含まれる認証機能ロックを無に、かつリカバリ権限を無に更新する認証機能リカバリステップと、を有していて、
前記サブシステムは、前記サブシステムに記憶するリカバリ情報ファイルを、所定の期間が経過すると前記アドレス情報を指定してもアクセス不可となるよう設定すること
を特徴とするリカバリ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、契約者の本人認証機能を備えた取引システムにおいて、不正アクセスに関する情報を契約者に速やかに通知するとともに、ログイン失敗により認証機能がロックされた場合に、契約者本人による認証機能のリカバリを可能にするための、本人認証機能のリカバリシステム及びリカバリ方法に関するものである。
【背景技術】
【０００２】
インターネットを介したショッピングサイトやインターネットバンキング等の取引システムにおいては、取引システムにログインする際に、契約者にパスワードを入力させることによって、契約者本人の認証を行うことが一般的である。このような取引システムを利用するためには、契約者はパスワードを正確に記憶しておかなければならず、パスワードを失念してしまうと、取引システムにログインできないという問題が生じることとなってしまう。
【０００３】
このような問題に対応するためには、例えば、ログインの際に入力されたパスワードが連続して基準回数を超えて不一致となった場合に、契約者に対してパスワードを通知する方法が考えられる。ここでパスワード通知の可否を判断するためには、ログインを試みた者が正規の契約者か悪意の第三者かを判別することが必要になるが、管理者からパスワードの通知を行うか否かを選択させることによって、正規の契約者のみに対してパスワードを通知する発明が開示されている（例えば、特許文献１参照。）。
【０００４】
【特許文献１】特開２００２−１３２７２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１記載の発明は、悪意の第三者がログインを試みた場合であれば、管理者からの通知を受けられないとの考え方に基づくものであるが、例えば正規の契約者のメールアドレスや電話番号等の個人情報が流出してしまった場合であれば、正規の契約者になりすますことによって、悪意の第三者が管理者からパスワードを受け取ってしまうリスクが生じることになる。不正取引を回避することを重視すると、パスワードの不一致が連続した場合には、まずは不正なログインが行われようとしたものと判断するほうが安全であり、かかる考え方に基づいてパスワードロック（パスワードによる認証機能の停止）が行われることが一般的になっている。
【０００６】
一方、不正なログインが行われようとしたという事実を正規の契約者に通知することが必要になるが、詳細な情報を全てアウトバンドで通知することは好ましくない。そこで、インターネットバンキングシステム等においては、ログイン後の操作画面において詳細な情報を表示することが行われており、契約者が登録した電子メールアドレスに電子メールで通知を行う場合は、通知内容を制約することが一般的である。
【０００７】
しかしながら、ログイン後の操作画面に表示する方法は、正規の契約者によってログインが行われることが前提となるため、ログインを行わないと不正アクセスを了知することができないことに加えて、パスワードの不一致が連続してパスワードロックがされてしまった場合には、正規の契約者はログインを行えないために通知を確認することができないという問題も生じてしまう。一方、電子メールによる通知は、第三者によって電子メールが不正に取得されるリスクを考慮すると、通知内容を制限せざるを得ないという問題が生じてしまう。
【０００８】
本発明は、このようなこのような課題を解決するためになされたものであり、契約者の本人認証機能を備えたインターネットバンキング等の取引システムにおいて、不正アクセスに関する情報を契約者に速やかに通知するとともに、ログイン失敗により認証機能がロックされた場合に、契約者本人による認証機能のリカバリを可能にするための、本人認証機能のリカバリシステム及びリカバリ方法を提供することを目的とするものである。
【課題を解決するための手段】
【０００９】
このような課題を解決する本発明は、契約者の本人認証機能を備えた取引システムと、前記取引システムへのログイン失敗により認証機能がロックされた際に再ログインのためのリカバリ情報を表示するためのサブシステムとからなる本人認証機能のリカバリシステムであって、前記取引システムは、契約者毎に、本人認証のための認証情報と、前記契約者に情報を通知するための通知先と、認証機能ロックの有無と、リカバリ権限の有無と、前記リカバリ情報を表示するリカバリ情報ファイルの記憶領域を指定したアドレス情報と、を少なくとも含む契約者情報を記憶する契約者情報記憶手段と、ログイン失敗の操作が所定の条件に合致すると、前記契約者情報記憶手段において対応する契約者の契約者情報の認証機能ロックを有、リカバリ権限を有とし、新たなアドレス情報を記憶させ、前記契約者情報に記憶された通知先に前記アドレス情報を含むリカバリ通知を送信するリカバリ通知送信手段と、前記サブシステムに、前記アドレス情報により指定される記憶領域に、前記契約者と前記契約者に付与されたリカバリ権限を識別するためのリカバリ権限情報が埋め込まれたリカバリ情報ファイルを記憶させることを要求するリカバリ情報要求手段と、契約者の操作する端末から、前記リカバリ権限情報が付与された認証機能のロックを解除するためのリカバリ要求を受信するリカバリ要求受信手段と、前記リカバリ要求に付与されたリカバリ権限情報から契約者を特定し、前記契約者情報記憶手段において対応する契約者の契約者情報を参照し、リカバリ権限が有となっていて、かつリカバリ権限情報から識別されるリカバリ権限を所定の契約者情報と照合して所定の条件に一致することを確認すると、正当なリカバリ要求であると判定するリカバリ権限判定手段と、前記リカバリ権限判定手段が正当なリカバリ要求であると判定すると、前記端末に再ログインのための認証情報の入力画面を表示させる再ログイン画面表示手段と、前記端末から、前記入力画面に入力された認証情報を受信すると、前記契約者情報記憶手段において対応する契約者の契約者情報に含まれる認証情報と照合して、認証情報が一致する場合には、前記契約者情報に含まれる認証機能ロックを無に、かつリカバリ権限を無に更新する認証機能リカバリ手段と、を備えていて、前記サブシステムに記憶されたリカバリ情報ファイルは、所定の期間が経過すると前記アドレス情報を指定してもアクセス不可となるよう設定されていることを特徴とするリカバリシステムである。
【００１０】
本発明においては、本人認証機能を備えた取引システムの外にリカバリ情報を表示するためのサブシステムを設け、認証機能がロックされる毎に個別にリカバリ情報を表示するアドレスを割り当てて、契約者には該アドレスを通知することによってリカバリに必要な情報にアクセスさせる。リカバリ情報は本人認証機能の外にあるため、認証機能がロックされた後にも契約者がアクセスすることが可能である。契約者に送信される通知には詳細な情報は含まれず、契約者はサブシステムのリカバリ情報ファイルを閲覧することによって、詳細な情報にアクセスすることができる。リカバリ情報ファイルは、所定の期間経過後にアクセス不可と設定することによって、情報の安全性を確保することができる。
【００１１】
本発明は、前記サブシステムは、前記アドレス情報を暗号化した情報をリカバリ権限情報としてリカバリ情報ファイルに埋め込んで、前記リカバリ権限判定手段は、前記リカバリ権限情報を複合化して、前記契約者情報に含まれるアドレス情報と照合して、正当なリカバリ要求であるかを判定することを特徴とすることもできる。
【００１２】
本発明は、前記リカバリ通知送信手段がリカバリ通知を送信する際には、前記契約者情報記憶手段において対応する契約者の契約者情報に新たに設定したリカバリ権限を識別するための識別コードを記憶させ、前記サブシステムは、前記識別コードをリカバリ権限情報としてリカバリ情報ファイルに埋め込んで、前記リカバリ権限判定手段は、前記リカバリ要求に付与された識別コードを前記契約者情報に含まれる識別コードと照合して、正当なリカバリ要求であるかを判定することを特徴とすることもできる。
【００１３】
本発明は、前記サブシステムは、前記リカバリ権限情報に代えてリカバリ要求の送信時に前記アドレス情報を付与させる命令を埋め込んで、前記リカバリ権限判定手段は、前記リカバリ権限情報に代えて前記アドレス情報を受信し、前記契約者情報に含まれるアドレス情報と照合して、正当なリカバリ要求であるかを判定することを特徴とすることもできる。
【００１４】
本発明において、サブシステムに表示したリカバリ権限と端末からのリカバリ要求を紐付けるための方法は特に限定されるものではないが、上記のように、ＵＲＬ等のアドレス情報を暗号化した情報や、リカバリ権限毎に割り当てた識別コードを紐付けのキーとして用いたり、端末から前ページのＵＲＬを送信される等の設定を行ってアドレス情報を送信させたりする方法によって、リカバリ要求の対象となるリカバリ権限を特定することができる。
【００１５】
また、本発明は、前記リカバリ通知送信手段がリカバリ通知を送信する際には、前記契約者情報記憶手段において対応する契約者の契約者情報に新たに設定したリカバリ権限の有効期限を記憶させ、前記リカバリ権限判定手段は、前記リカバリ要求の受付時間が前記契約者情報に含まれる有効期限を経過している場合は、正当なリカバリ要求でないと判定することを特徴とすることもできる。
【００１６】
このように、リカバリ権限に有効期限を設けるように構成すると、正規の契約者以外によってリカバリが行われるリスクを低減し、取引の安全性を高めることができる。
【００１７】
上記の構成において、本発明は、前記取引システムは、前記契約者情報記憶手段に記憶された契約者情報において有効期限が到来した契約者情報を特定し、前記契約者情報に含まれるリカバリ権限を無に更新するとともに、前記契約者情報に含まれるアドレス情報を特定するアドレス情報特定手段と、前記サブシステムに、前記アドレス情報特定手段が特定したアドレス情報に対応するリカバリ情報ファイルについて、前記アドレス情報を指定してもアクセス不可となるよう設定する命令を送信するリカバリ情報停止手段と、を備えること特徴としてもよい。前記リカバリ情報要求手段は、前記サブシステムに、前記リカバリ情報ファイルと関連付けて前記有効期限を記憶させることを要求し、前記取引システムには、前記契約者情報記憶手段に記憶された契約者情報において有効期限が到来した契約者情報を特定し、前記契約者情報に含まれるリカバリ権限を無に更新するリカバリ権限消去手段が備えられ、前記サブシステムには、前記リカバリ情報ファイルに関連付けられた有効期限が到来したリカバリ情報ファイルについて、前記リカバリ情報ファイルのアドレス情報を指定してもアクセス不可となるよう設定するリカバリ情報停止手段が備えられることを特徴としてもよい。
【００１８】
このように、リカバリ権限に有効期限を設けるように構成した場合には、有効期限が到来した場合にはリカバリ情報ファイルにアクセス不可とするよう構成することによって、正規の契約者以外によってリカバリ情報が参照されるリスクを低減し、取引の安全性を高めることができる。
【００１９】
さらに、本発明は、前記認証機能リカバリ手段は、前記認証情報が一致する場合には、前記サブシステムに、前記契約者情報に含まれるアドレス情報に対応するリカバリ情報ファイルについて、前記アドレス情報を指定してもアクセス不可となるよう設定する命令を送信することを特徴とすることもできる。
【００２０】
このように、正規の契約者によって認証機能のリカバリが行われるとリカバリ情報ファイルにアクセス不可とするよう構成することによって、正規の契約者以外によってリカバリ情報が参照されるリスクを低減し、取引の安全性を高めることができる。
【００２１】
さらに、本発明は、本発明にかかる本人認証機能のリカバリシステムによって実行される、本人認証機能のリカバリ方法として特定することもできる。
【００２２】
つまり、本発明にかかる本人認証機能のリカバリ方法は、契約者の本人認証機能を備えた取引システムと、前記取引システムへのログイン失敗により認証機能がロックされた際に再ログインのためのリカバリ情報を表示するためのサブシステムとにより実行される本人認証機能のリカバリ方法であって、前記取引システムには、契約者毎に、本人認証のための認証情報と、前記契約者に情報を通知するための通知先と、認証機能ロックの有無と、リカバリ権限の有無と、前記リカバリ情報を表示するリカバリ情報ファイルの記憶領域を指定したアドレス情報と、を少なくとも含む契約者情報を記憶する契約者情報記憶部が備えられていて、前記取引システムが、ログイン失敗の操作が所定の条件に合致すると、前記契約者情報記憶部において対応する契約者の契約者情報の認証機能ロックを有、リカバリ権限を有とし、新たなアドレス情報を記憶させ、前記契約者情報に記憶された通知先に前記アドレス情報を含むリカバリ通知を送信するリカバリ通知送信ステップと、前記取引システムが、前記サブシステムに、前記アドレス情報により指定される記憶領域に、前記契約者と前記契約者に付与されたリカバリ権限を識別するためのリカバリ権限情報が埋め込まれたリカバリ情報ファイルを記憶させることを要求するリカバリ情報要求ステップと、前記取引システムが、契約者の操作する端末から、前記リカバリ権限情報が付与された認証機能のロックを解除するためのリカバリ要求を受信するリカバリ要求受信ステップと、前記取引システムが、前記リカバリ要求に付与されたリカバリ権限情報から契約者を特定し、前記契約者情報記憶部において対応する契約者の契約者情報を参照し、リカバリ権限が有となっていて、かつリカバリ権限情報から識別されるリカバリ権限を所定の契約者情報と照合して所定の条件に一致することを確認すると、正当なリカバリ要求であると判定するリカバリ権限判定ステップと、前記取引システムが、前記リカバリ権限判定ステップで正当なリカバリ要求であると判定すると、前記端末に再ログインのための認証情報の入力画面を表示させる再ログイン画面表示ステップと、前記取引システムが、前記端末から、前記入力画面に入力された認証情報を受信すると、前記契約者情報記憶部において対応する契約者の契約者情報に含まれる認証情報と照合して、認証情報が一致する場合には、前記契約者情報に含まれる認証機能ロックを無に、かつリカバリ権限を無に更新する認証機能リカバリステップと、を有していて、前記サブシステムは、前記サブシステムに記憶するリカバリ情報ファイルを、所定の期間が経過すると前記アドレス情報を指定してもアクセス不可となるよう設定することを特徴とするリカバリ方法である。
【００２３】
本発明にかかる本人認証機能のリカバリ方法は、前記サブシステムが、前記アドレス情報を暗号化した情報をリカバリ権限情報としてリカバリ情報ファイルに埋め込むステップを有していて、前記リカバリ権限判定ステップにおいて、前記取引システムは、前記リカバリ権限情報を複合化して、前記契約者情報に含まれるアドレス情報と照合して、正当なリカバリ要求であるかを判定することを特徴とすることもできる。
【００２４】
本発明にかかる本人認証機能のリカバリ方法は、前記リカバリ通知送信手段でリカバリ通知を送信する際には、前記取引システムは、前記契約者情報記憶部において対応する契約者の契約者情報に新たに設定したリカバリ権限を識別するための識別コードを記憶させ、前記サブシステムが、前記識別コードをリカバリ権限情報としてリカバリ情報ファイルに埋め込むステップを有していて、前記リカバリ権限判定ステップにおいて、前記取引システムは、前記リカバリ要求に付与された識別コードを前記契約者情報に含まれる識別コードと照合して、正当なリカバリ要求であるかを判定することを特徴とすることもできる。
【００２５】
本発明にかかる本人認証機能のリカバリ方法は、前記サブシステムが、前記リカバリ権限情報に代えてリカバリ要求の送信時に前記アドレス情報を付与させる命令を埋め込むステップを有していて、前記リカバリ権限判定ステップにおいて、前記取引システムは、前記リカバリ権限情報に代えて前記アドレス情報を受信し、前記契約者情報に含まれるアドレス情報と照合して、正当なリカバリ要求であるかを判定することを特徴とすることもできる。
【００２６】
また、本発明にかかる本人認証機能のリカバリ方法は、前記リカバリ通知送信ステップでリカバリ通知を送信する際には、前記取引システムは、前記契約者情報記憶部において対応する契約者の契約者情報に新たに設定したリカバリ権限の有効期限を記憶させ、前記リカバリ権限判定ステップにおいて、前記取引システムは、前記リカバリ要求の受付時間が前記契約者情報に含まれる有効期限を経過している場合は、正当なリカバリ要求でないと判定することを特徴とすることもできる。
【００２７】
上記の方法において、本発明にかかる本人認証機能のリカバリ方法は、前記取引システムが、前記契約者情報記憶部に記憶された契約者情報において有効期限が到来した契約者情報を特定し、前記契約者情報に含まれるリカバリ権限を無に更新するとともに、前記契約者情報に含まれるアドレス情報を特定するアドレス情報特定ステップと、前記取引システムが、前記サブシステムに、前記アドレス情報特定ステップで特定したアドレス情報に対応するリカバリ情報ファイルについて、前記アドレス情報を指定してもアクセス不可となるよう設定する命令を送信するリカバリ情報停止ステップと、を有すること特徴としてもよい。前記リカバリ情報要求ステップにおいて、前記取引システムは、前記サブシステムに、前記リカバリ情報ファイルと関連付けて前記有効期限を記憶させることを要求し、前記取引システムが、前記契約者情報記憶部に記憶された契約者情報において有効期限が到来した契約者情報を特定し、前記契約者情報に含まれるリカバリ権限を無に更新するリカバリ権限消去ステップと、前記サブシステムが、前記リカバリ情報ファイルに関連付けられた有効期限が到来したリカバリ情報ファイルについて、前記リカバリ情報ファイルのアドレス情報を指定してもアクセス不可となるよう設定するリカバリ情報停止ステップと、を有することを特徴としてもよい。
【００２８】
さらに、本発明にかかる本人認証機能のリカバリ方法は、前記認証機能リカバリステップにおいて、前記取引システムは、前記認証情報が一致する場合には、前記サブシステムに、前記契約者情報に含まれるアドレス情報に対応するリカバリ情報ファイルについて、前記アドレス情報を指定してもアクセス不可となるよう設定する命令を送信することを特徴とすることもできる。
【発明の効果】
【００２９】
本発明によって、契約者の本人認証機能を備えたインターネットバンキング等の取引システムにおいて、悪意の第三者によって不正なアクセスが行われた場合に、不正アクセスに関する情報を契約者に速やかかつ安全に通知することが可能になるとともに、不正アクセス時のログイン失敗により認証機能がロックされた場合であっても、契約者本人によって認証機能を容易にリカバリすることが可能になる。
【発明を実施するための最良の形態】
【００３０】
本発明を実施するための最良の形態について、図面を用いて以下に詳細に説明する。尚、以下の実施形態は、本発明をインターネットバンキングの取引システムに適用する例について説明するが、かかる実施形態は本発明の一例であって、本発明を適用する取引システムはインターネットバンキングに限られるものではなく、その他の実施の態様についても以下の説明に限定されるものではない。
【００３１】
図１は、本発明にかかるリカバリシステムの実施形態の概要を示す図である。図２は、本発明にかかるリカバリシステムの構成を示すブロック図である。図３は、本発明にかかるリカバリシステムの契約者マスタテーブルの一例を示す図である。図４は、本発明にかかるリカバリシステムにおける、アクセスログテーブルの一例を示す図である。図５は、本発明にかかるリカバリシステムにおける、リカバリ権限テーブルの一例を示す図である。図６〜図１３は、本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第１〜第８の図である。図１４〜図２１は、本発明にかかるリカバリシステムによって、不正アクセスが行われてから、本人認証機能のリカバリが行われるまでの、取引システム、サブシステム、端末における処理フローを示すフローチャートである。
【００３２】
図１を用いて、本発明にかかるリカバリシステムの実施形態の概要について説明する。本発明にかかるリカバリシステムは、インターネットバンキング等の取引システムにおける本人認証機能のリカバリ処理を実行するために、取引システム及びサブシステムの機能として備えられるものである。インターネットバンキング等の契約者は、ＰＣや携帯電話等の端末を操作し、インターネットを介して取引システムにアクセスして、様々な取引を実行する。
【００３３】
取引システムには、契約者の本人認証機能が備えられていて、契約者が取引システムにアクセスして取引を行う際には、端末に契約者番号とパスワードを入力して、取引システムに対してログインの要求を行なう。要求を受けた取引システムでは、入力された契約者番号とパスワードを、予め取引システムに登録された契約者番号に対応するパスワードと照合し、一致する場合は、契約者本人であると判定してログインを承認する。不一致の場合は、パスワードの入力ミスである可能性を考慮して、所定の回数までは契約者番号及びパスワードの再入力を要求する。不一致が所定の回数を超えると、悪意の第三者による不正アクセスであると判断して、該契約者番号について以後のログイン操作を受け付けないパスワードロックが行われる。
【００３４】
パスワードがロックされると、該契約者に不正アクセスが行われたことを通知するとともに、パスワードロックを解除して認証機能をリカバリするリカバリ権限を設定し、リカバリを行うために必要なリカバリ情報を表示するためのファイルを、サブシステムに格納する。サブシステムには、取引システムの認証機能の外にある、インターネットに接続されたＷｅｂサーバ等が用いられる。契約者への通知は電子メールで行われ、該ファイルにアクセスするためのアドレスが通知される。
【００３５】
尚、リカバリ情報を表示するためのファイルを格納するアドレスはリカバリの権限毎に設定され、所定の期間が経過すると外部からのアクセスが禁止される。このように設定することによって、アウトバウンドの電子メールによって通知する内容を制限する一方で、リカバリ情報その他の詳細な情報についても、契約者に安全に了知させることを可能にしている。
【００３６】
電子メールによる通知を受けた契約者は、自らの取引口座に対して不正アクセスが試みられたことを了知するとともに、詳細な情報を取得するために、電子メールに指定されたアドレスを指定してサブシステムにアクセスする。サブシステムにアクセスさせるための方法は特に限定されるものではなく、電子メール本文にアドレスを埋め込んだリンクを設けてもよいし、ＵＲＬを本文に記述することとしてもよい。
【００３７】
契約者がサブシステムにアクセスすると、指定されたアドレスに格納されたリカバリ情報に関するファイルが端末に表示される。表示される画面に、本人認証機能のリカバリを行うためのボタンを設けておき、このボタンを押下すると、各々について設定されたリカバリ権限を特定したリカバリ要求が行われ、取引システムにおいて正当なリカバリ権限に基づく要求であることが確認されると、再ログイン用の画面が端末に表示される。契約者が再ログイン画面に契約者番号とパスワードを入力して再ログイン要求を行なうと、予め取引システムに登録された契約者番号に対応するパスワードと照合し、一致するとパスワードロックが解除されて、ログインが承認される。
【００３８】
尚、本発明において取引システムで用いられる認証方法は、パスワードによる認証に限定されるものではなく、指紋等による生体認証や音声による認証など他の認証方法によるものであってもよく、他の認証方法を用いる場合にも認証機能のロックとリカバリが行われる。サブシステムについては、取引システムによる本人認証を要求することなく、アクセスした端末に情報を表示させることができるものであればよく、インターネットバンキングシステムとして用いられるＷｅｂサーバの一部を構成するものであってもよい。
【００３９】
続いて、本発明にかかるリカバリシステムをインターネットバンキングシステムに用いた場合の構成について、図２のブロック図と、図３〜図５に示した各テーブルの一例を用いて、詳細に説明する。
【００４０】
図２において、本発明にかかるリカバリシステムは、インターネットバンキングの取引システム２０に備えられ、サブシステム３０と協働して、契約者への不正アクセスの通知と、本人認証機能のリカバリを行う。端末１０、端末４０は、ＰＣ、携帯電話、ＰＤＡ等のインターネットに接続可能な端末装置であって、Ｗｅｂブラウザを用いて取引システム２０にアクセスして、インターネットバンキングのサービスを利用することができる。また、Ｗｅｂブラウザを用いてサブシステム３０にアクセスして、情報を閲覧することが可能となっている。
【００４１】
取引システム２０は、Ｗｅｂサーバの機能や本人認証機能を有するコンピュータシステムであって、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤを備えている。取引システムにより実行される各々の機能は、ＨＤＤに格納されたアプリケーションプログラムによって実行され、これらのアプリケーションプログラムを実行するためには、ＲＯＭに記憶された入力制御や出力制御などのハードウェア制御のための基本的な各種プログラムを起動し、ＲＡＭをアプリケーションプログラムのワークエリアとして機能させながら、ＣＰＵによって所定の演算処理が行われる。取引システム２０のログイン処理部２２、リカバリ制御部２３、サブシステム制御部２４は、いずれも機能的に特定されるものであって、実際にログインやリカバリの処理を実行する際には、ＨＤＤに記憶された各々のアプリケーションプログラムがＲＡＭに読み出されて、ＣＰＵで演算処理が実行されることとなる。
【００４２】
取引システム２０には契約者データベース２１が備えられ、契約者データベース２１には契約者マスタテーブル２１１、アクセスログテーブル２１２、リカバリ権限テーブル２１３が備えられている。契約者マスタテーブル２１１には、図３の例に示したように口座番号やパスワードなどの契約者の基本情報が、アクセスログテーブル２１２には、図４の例に示したように契約者番号毎のアクセス履歴が、リカバリ権限テーブル２１３には、図５の例に示したようにパスワードロック後にリカバリ権限が設定された場合のリカバリ権限に関する情報が、それぞれ記憶される。
【００４３】
尚、ここでは本発明に必要な契約者とアクセス権限に関する情報を、契約者マスタテーブル２１１、アクセスログテーブル２１２、リカバリ権限テーブル２１３の３つのテーブルに記憶させる例を示したが、契約者データベース２１に設けられるテーブルの構成は、必要な情報が関連付けて記憶されるものであれば、この例に限定されるものではない。また、契約者データベース２１は、取引システム２０とは別のデータベースサーバ等の物理的に分離されたコンピュータシステムに備えられるものであってもよい。
【００４４】
サブシステム３０は取引システム２０と接続されていて、取引システム２０においてパスワードロックが行われてリカバリ権限が設定されると、取引システム２０からの命令を受けて、リカバリ情報作成部３１においてリカバリ情報ファイルを作成する。作成されたリカバリ情報ファイルは、端末１０等からアクセスすることが可能なリカバリ情報格納部３２に格納される。
【００４５】
尚、サブシステム３０も、Ｗｅｂサーバの機能を有するコンピュータシステムであって、ＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤを備え、ＨＤＤに格納されたアプリケーションプログラムを実行するためには、ＲＯＭに記憶された入力制御や出力制御などのハードウェア制御のための基本的な各種プログラムを起動し、ＲＡＭをアプリケーションプログラムのワークエリアとして機能させながら、ＣＰＵによって所定の演算処理が行われることは、取引システム２０と同様である。リカバリ情報作成部３１は機能的に特定されるものであって、実際にリカバリ情報を作成する際には、ＨＤＤに記憶されたアプリケーションプログラムがＲＡＭに読み出されて、ＣＰＵで演算処理が実行されることとなる。サブシステム３０は、取引システム２０と物理的に同一のコンピュータシステムに備えられるものであってもよいが、取引システム２０における本人認証を経ないでサブシステム３０にアクセスできるよう構成されていることが必要である。
【００４６】
図３は、契約者データベース２１の契約者マスタテーブル２１１の一例を示したものである。契約者番号毎に設けられたレコードには、契約者の有する預金口座の店番号、口座番号、契約者名、本人認証に用いられるパスワード、通知先のメールアドレス等の契約者の基本情報のほか、不正アクセスによるパスワードロックの有無を示すフラグ（この例では「１」がロック有り、「０」がロック無しとする。）、パスワードロックを解除して本人認証機能をリカバリするためのリカバリ権限が契約者に付与されていることを示すフラグ（この例では「１」が権限有り、「０」が権限無しとする。）が記憶されている。パスワードロックが有となっている場合は、本人認証機能が停止され、ログイン要求が受付けられなくなる。
【００４７】
図４は、契約者データベース２１のアクセスログテーブル２１２の一例を示したものである。契約者番号毎にログイン要求の履歴を記録するためのテーブルが設けられ、アクセス日時、アクセス元のＩＰアドレス、パスワードの照合結果等がアクセスログとして記憶されている。ログイン要求で指定されたパスワードが契約者マスタテーブル２１１に指定されたパスワードと一致する場合は、照合結果に「ＯＫ」と記録されるが、不一致となった場合には「ＮＧ」と記録され、連続して「ＮＧ」となった回数がエラー回数のフィールドにカウントされる。エラー回数が所定の回数に達すると、不正アクセスであると判断して、パスワードロックが行われる。
【００４８】
図５は、契約者データベース２１のリカバリ権限テーブル２１３の一例を示したものである。アクセスログテーブル２１２におけるエラーが所定の回数を超えると、図３に示したようにパスワードロックを有とするフラグと、リカバリ権限を有とするフラグが立てられて、正規の契約者にはリカバリ権限が付与される。リカバリ権限は、契約者番号、リカバリ情報作成日、パスワードロック日時、アドレス情報、リカバリ権限有効期限等によって特定される。アドレス情報とは、不正アクセスに関する詳細情報や、リカバリの処理に必要なリカバリ権限に関する情報を契約者に了知させるためのリカバリ情報ファイルを格納するＵＲＬ等のアドレスで、リカバリ権限が付与される毎に取引システム２０のリカバリ制御部２３において発行される。
【００４９】
以上の構成を前提にして、本発明にかかるリカバリシステムの動作について、図６〜図１３の本人認証機能のリカバリのフローの一例を用いて、詳細に説明する。尚、リカバリシステムに登録された契約者番号やパスワード等は、図３〜図５の例に従うものとする。
【００５０】
図６に示したように、端末４０を操作する悪意の第三者が、契約者番号（１２３４５６７８）を指定して取引システム２０に不正なアクセスを試みたとする。パスワードは了知していないことが通常であるので、契約者の誕生日等を把握している場合はそれらの情報からパスワードを推測し、端末４０に契約者番号とパスワードを入力して、取引システムにログイン要求を送信する。
【００５１】
ログイン要求を受信した取引システム２０では、ログイン処理部２２が起動され、契約者マスタテーブル２１１において指定された契約者番号に対応するレコードを特定し、パスワード（ｘｙｚ９９９９）を取得する。取得した正規のパスワードを入力されたパスワードと照合して、照合結果をアクセスログテーブル２１２に記録する。パスワードが不一致となるとエラー回数がカウントされ、所定の回数（この例では３回）に到達すると、リカバリ処理部２３が起動されて、パスワードロックとリカバリ権限の設定が行われる。
【００５２】
パスワードロックとリカバリ権限の設定は、次のように行われる。まず、契約者マスタテーブル２１１では、対応する契約者番号パスワードロックのフラグを、ロック無し（０）からロック有り（１）に更新する。パスワードロックのフラグがロック有り（１）となっている場合は、その後に該契約者番号が指定されたログイン要求を受け付けたとしても、本人認証機能は停止され、パスワードが一致するか否かに関わらずログインが受け付けられない状態となる。また、対応する契約者番号リカバリ権限のフラグを、権限無し（０）から権限有り（１）に更新する。
【００５３】
さらに、リカバリ権限テーブル２１３に、新たに設定したリカバリ権限に関する情報を記録する。リカバリ権限として記録される情報の内容は特に限定されるものではないが、不正アクセスに関する詳細情報や、リカバリの処理に必要なリカバリ権限に関する情報を契約者に了知させるためのリカバリ情報ファイルを格納するＵＲＬ等のアドレス情報（ｈｔｔｐ：／／ｓｕｂｓｙｓｔｅｍ．ｍｕｆｇ．ｊｐ／１２３４５６７８／０４０５）と、リカバリ情報ファイルにアクセス可能な期間を定めたリカバリ権限の有効期限（２００６年４月６日２４時００分）が必ず設定される。アドレス情報は、後にリカバリ権限の照合にも用いられるため、リカバリ権限毎に異なる固有のアドレスが割当てられる。また、このアドレスには、アクセスに本人認証を要しないサブシステム３０の記憶領域が割当てられる。
【００５４】
続いて、取引システム２０は、図７に示したように、契約者が不正アクセスに関する詳細情報やリカバリの処理に必要なリカバリ権限に関する情報を取得するためのアドレス情報を通知する電子メールを、正規の契約者が予め登録して契約者マスタテーブル２１１に記憶されたメールアドレス（ｘｙｚ＠ｉｐｖ．ｊｐ）宛に送信する。この電子メールは、アウトバウンド通知として送信されるため、上記アドレス情報以外に特に必要のない情報は含まないものであることが好ましい。尚、アドレス情報の通知方法は特に限定されるものではなく、電子メールの本文にＵＲＬ等を記載することとしてもよいし、電子メールにリンクを埋め込むこととしてもよい。
【００５５】
また、取引システム２０ではサブシステム制御部２４が起動されて、サブシステム３０に対して、不正アクセスに関する詳細情報やリカバリの処理に必要なリカバリ権限に関する情報を表示させるためのリカバリ情報ファイルの作成要求を送信する。リカバリ情報ファイルはリカバリ権限毎に格納するアドレスがサブシステム３０に割当てられているので、サブシステム３０に設定されたアドレスが併せて通知される。アドレスはリカバリ権限毎に設けられるので、アドレスが特定されれば後のアクセス権限の確認の際には設定されたアクセス権限との照合が可能となっているが、アクセス権限の確認をスムーズに行うためには、サブシステム３０に契約者番号を併せて通知することが好ましい。
【００５６】
リカバリ情報ファイルの作成要求を受信したサブシステム３０では、図８に示したように、リカバリ情報作成部３１が起動され、契約者が操作する端末にリカバリ情報を表示するためのＨＴＭＬファイル等のリカバリ情報ファイルが作成される。リカバリ情報ファイルには、パスワードロックが行われたことや、ロックが行われた日時等を記載した本文に加えて、正当な契約者によってパスワードロックを解除して本人認証機能をリカバリすることを要求するためのリカバリボタンが表示される。リカバリボタンには、リカバリ権限を識別するための取引システム２０から受信したアドレス情報（契約者番号を含んでもよい）が埋め込まれるが、埋め込まれる情報は暗号化されたものであることが好ましい。
【００５７】
ここで作成されたリカバリ情報ファイルは、リカバリ情報記憶部３２のうち、取引システム２０から受信したアドレス情報により指定される記憶領域に格納される。サブシステム３０のリカバリ情報格納部３２は、取引システム２０の本人認証機能の外にあるものであるため、パスワードロックが行われた後であっても、端末１０等からＷｅｂブラウザを用いてアクセスすることが可能となっている。
【００５８】
電子メールを受信した正規の契約者は、図９に示したように、端末１０において電子メール本文に表示されたＵＲＬのリンク等を選択して、サブシステム３０のリカバリ情報ファイルにアクセスする。リカバリ情報ファイルは、端末１０のＷｅｂブラウザによって表示され、正規の契約者は不正アクセスについての詳細な情報を了知することができる。
【００５９】
正規の契約者がパスワードロックを解除して本人認証機能のリカバリを行いたい場合には、図１０に示したように、端末に表示されたリカバリボタンを押下する。リカバリボタンが押下されると、リカバリボタンに埋め込まれた暗号化されたアドレス情報を付して、リカバリ要求が取引システム２０に対して送信される。
【００６０】
取引システム２０が端末１０からのリカバリ要求を受信すると、リカバリ制御部２３の動作によって、リカバリ要求に付された暗号化されたアドレス情報の複合化が行われる。複合化されたアドレス情報はリカバリ権限毎に割当てられたものなので、これによって対応するリカバリ権限を特定するととともに、該リカバリ権限に対応する契約者マスタを特定することができる。尚、アドレス情報と併せて契約者番号をリカバリボタンに埋め込んだり、アドレス情報の一部に契約者番号を含んだり（例えば、「ｈｔｔｐ：／／ｓｕｂｓｙｓｔｅｍ．ｍｕｆｇ．ｊｐ／１２３４５６７８／０４０５」の「１２３４５６７８」部分）するように設定すれば、契約者番号に対応する契約者マスタをダイレクトに特定することが可能になる。
【００６１】
リカバリ権限を特定する方法は上記の方法に限られるものではなく、例えばアドレス情報とは別に、リカバリ権限を識別するための識別コードを採番し、リカバリ権限テーブルに識別コードを記憶させるとともに、リカバリボタンに識別コードを埋め込むよう構成することとしてもよい。また、アドレス情報をリカバリボタンに埋め込むのではなく、リカバリボタンが押下されると、Ｗｅｂブラウザのリファラ機能等によって表示されているファイルのＵＲＬを併せて送信するよう設定することによって、リカバリ要求と併せてアドレス情報を取得するよう構成することとしてもよい。
【００６２】
このようにして、リカバリ要求を受け付けたリカバリ権限と契約者マスタが特定されると、リカバリ要求が正当なものであるか否かの確認が行なわれる。リカバリ要求が正当なものであると判断するためには、対応する契約者番号とアドレス情報が存在し、かつ契約者マスタのリカバリ権限が有り（１）となっていて、かつリカバリ権限に設定された有効期限を経過していないことが条件となるので、これらの条件を満たすか否かが、契約者マスタテーブル２１１とリカバリ権限テーブル２１３において確認される。
【００６３】
上記の全ての条件を満たすものであることが確認されると、図１１に示したように、取引システム２０は端末１０に再ログインのための契約者番号とパスワードの入力画面を表示させる。
【００６４】
再ログインの入力画面が表示された端末１０では、図１２に示したように、正規の契約者が契約者番号（１２３４５６７８）とパスワード（ｘｙｚ９９９９）を入力する。入力された契約者番号とパスワードは取引システム２０に送信され、契約者番号（１２３４５６７８）により特定される契約者マスタテーブル２１１に記憶されたパスワード（ｘｙｚ９９９９）と、入力されたパスワードを照合する。パスワードが一致すると、正当な契約者によるリカバリ要求であると判断されて、リカバリのための処理がリカバリ制御部２３の動作によって実行される。
【００６５】
リカバリのための処理は、図１３に示したように、契約者マスタのパスワードロックをロック有り（１）からロック無し（０）に更新し、リカバリ権限を権限有り（１）から権限無し（０）に更新することによって行われる。これによってパスワードロックが解除されて本人認証機能が有効となり、正規の契約者による取引システム２０へのログインが可能になる。併せて、アクセスログテーブル２１２に記録された対応する契約者のエラー回数のカウントが、「０」にクリアされる。
【００６６】
また、サブシステム制御部２４の動作によって、サブシステム３０に対して、リカバリ情報格納部３２に格納されたリカバリ情報ファイルへのアクセスを不可とする、停止要求が送信される。停止要求はアドレス情報を特定して行われ、サブシステム３０では対応するアドレスに格納されたリカバリ情報ファイルの表示を停止するための処理を実行する。表示を停止させるための処理は特に限定されるものではないが、例えば該リカバリ情報ファイルを外部からのアクセス不能な記憶領域に移動させることとしてもよいし、該リカバリ情報ファイルを削除することとしてもよい。
【００６７】
尚、リカバリ情報ファイルへのアクセスを不可とするための処理は、リカバリが行われた後のみでなく、リカバリ権限の有効期限が経過した後においても行うように構成することが好ましい。具体的には、例えば、取引システム２０において有効期限が経過したリカバリ権限のアドレス情報を特定し、特定されたアドレス情報に格納されたリカバリ情報ファイルへのアクセスを不可とする命令をサブシステム３０に送信するように構成してもよいし、サブシステム３０へのリカバリ情報ファイルの作成要求時に併せて有効期限に関する情報を送信し、サブシステム３０にリカバリ情報ファイル毎の有効期限を記憶しておいて、サブシステム３０において有効期限が経過したリカバリ情報ファイルを確認してアクセスを不可とするように構成してもよい。
【００６８】
再ログインの入力画面に入力されたパスワードが契約者マスタのパスワードが一致しない場合は、リカバリ要求を行ったのは正当な契約者ではないものと判断される。この場合は、本人認証機能のリカバリは行わず、再ログインが承認されないのは勿論であるが、悪意の第三者によって何度も再ログインが試みられることを防止するために、リカバリ権限を権限有り（１）から権限無し（０）に更新することが好ましい。このように構成することによって、リカバリが不正に行われるリスクを低減して、取引の安全性を高めることができる。
【００６９】
図１４〜図２１のフローチャートを用いて、本発明にかかるリカバリシステムによって、不正アクセスが行われてから、本人認証機能のリカバリが行われるまでの、取引システム、サブシステム、端末における処理フローについて説明する。
【００７０】
図１４は、取引システムにおいて、不正アクセスを認識してパスワードロックを設定するまでの処理フローを示している。インターネットバンキングサービスを提供する取引システムにおいて、取引システムへのログイン要求を受け付けると（Ｓ０１）、ログイン要求において指定されたパスワードが、ログイン要求を行った契約者について予め登録されたパスワードと一致するか否かが確認される（Ｓ０２）。パスワードが一致する場合には、正当な契約者によるログイン要求であると判断され、アクセスログを記録して（Ｓ０３）、ログイン処理が進められる。
【００７１】
一方、パスワードが一致しない場合には、アクセスログにエラーとなったことを記録するとともに（Ｓ０４）、連続してエラーとなった回数のカウントに１回分を加算する（Ｓ０５）。ここで、連続したエラー回数がｎ回（不正アクセスと判断する基準となる回数）以上であるか確認して（Ｓ０６）、ｎ回に満たない場合は、パスワードの再入力を求める画面を表示する等によって、改めてログイン要求を受け付ける（Ｓ０１）。
【００７２】
エラー回数がｎ回以上である場合は、正規の契約者による誤入力によるエラーではなく、悪意の第三者による不正アクセスであるものと判断して、本人認証機能を停止させてログインを受け付けないこととするための処理を実行する。具体的には、契約者番号により特定される契約者マスタのパスワードロックを有りに設定し（Ｓ０７）、同じく契約者マスタのリカバリ権限も有りに設定する（Ｓ０８）。
【００７３】
さらに、正当な契約者に不正アクセスに関する詳細情報やリカバリの処理に必要なリカバリ権限に関する情報を了知させるためのリカバリ情報ファイルを格納するための、リカバリ権限毎に固有のＵＲＬを割り当てる（Ｓ０９）。また、新たに設定されたリカバリ権限について、パスワードロックが行われた日時、割当てられたＵＲＬ、リカバリ権限の有効期限等の情報が登録され（Ｓ１０）、サブシステムに対しは、ＵＲＬを指定したリカバリ情報ファイルの作成要求を送信する（Ｓ１１）。さらに、契約者マスタに記憶された契約者が予め登録したメールアドレスを宛先として、契約者にＵＲＬを記載したリカバリ通知を電子メールで送信する（Ｓ１２）。尚、不正アクセスと判断した後のこれらの処理（Ｓ０７〜Ｓ１２）の処理手順については、上記の順序に特に限定されるものではない。
【００７４】
図１５は、取引システムからリカバリ情報ファイルの作成要求を受信した、サブシステムにおける処理フローを示している。リカバリ情報ファイルの作成要求を受信すると（Ｓ２１）、リカバリ情報ファイルを作成する（Ｓ２２）。リカバリ情報ファイルの作成方法については、通知内容の本文やパスワードロックが行われた日時、リカバリ権限の有効期限等を含む表示ファイルのレイアウトを作成し（Ｓ２２１）、リカバリ情報ファイルの作成要求に指定されたＵＲＬを暗号化する（Ｓ２２２）。暗号化したＵＲＬは、リカバリ情報ファイルによって表示されるリカバリボタンに埋め込まれる（Ｓ２２３）。このように作成されたリカバリ情報ファイルは、ＵＲＬによって指定されるファイルパスに格納される（Ｓ２３）。
【００７５】
尚、Ｓ２２１〜Ｓ２２３において説明したリカバリ情報ファイルの作成処理は、取引システムにおいて行うこととして、サブシステムにおいては取引システムから受信したリカバリ情報ファイルを、併せて取引システムから指定されたＵＲＬに単に格納することとしてもよい。
【００７６】
図１６は、取引システムからリカバリ通知を受信した、契約者の操作する端末における処理フローを示している。リカバリ通知を受信して（Ｓ３１）、契約者によってメールに表示されたＵＲＬが選択されると（Ｓ３２）、ＵＲＬによって指定されたリカバリ情報ファイルを閲覧するため、Ｗｅｂブラウザによってサブシステムへのアクセスが行われる（Ｓ３３）。ＵＲＬが選択されない場合は（Ｓ３２）、そのまま処理を終了する。
【００７７】
図１７は、契約者の操作する端末からリカバリ情報ファイルへのアクセスを受け付けた、サブシステムにおける処理フローを示している。サブシステムが端末からのアクセスを受け付けると（Ｓ４１）、ＵＲＬによって特定されるファイルパスからリカバリ情報ファイルを読出して（Ｓ４２）、契約者の操作する端末に表示させる（Ｓ４３）。
【００７８】
図１８は、サブシステムのリカバリ情報ファイルによりリカバリ情報が表示された、契約者の操作する端末における処理フローを示している。契約者の操作する端末の操作画面に、リカバリ情報ファイルによってリカバリ情報が表示され（Ｓ５１）、リカバリ情報の一部に表示されたリカバリボタンが押下されると（Ｓ５２）、リカバリボタンに埋め込まれた暗号化されたＵＲＬを付したリカバリ要求を取引システムに送信する（Ｓ５３）。リカバリボタンが押下されない場合は（Ｓ５２）、そのまま処理を終了する。
【００７９】
図１９は、契約者の操作する端末からリカバリ要求を受信した、取引システムにおける処理フローを示している。取引システムがリカバリ要求を受信すると（Ｓ６１）、リカバリ要求に付された暗号化されたＵＲＬを複合化する（Ｓ６２）。複合化したＵＲＬについて、リカバリ権限が設定されたＵＲＬと一致するかを照合する（Ｓ６３）。一致するＵＲＬが存在しない場合は、エラーとなる。
【００８０】
一致するＵＲＬが存在する場合は、複合化されたＵＲＬから対応する契約者の契約者番号を特定し、契約者番号が契約者マスタに存在するかを確認する（Ｓ６４）。契約者番号が存在しない場合は、エラーとなる。契約者番号が存在する場合は、対応する契約者マスタのリカバリ権限が有りとなっているか（Ｓ６５）、対応するリカバリ権限の有効期限内に該当するかを確認する（Ｓ６６）。いずれか一方に該当しない場合には、エラーとなる。これらの条件について、全て合致することが確認されれば、契約者の操作する端末の操作画面に再ログインのための入力画面を表示させる（Ｓ６７）。
【００８１】
図２０は、再ログインのための入力画面が表示された、契約者の操作する端末における処理フローを示している。契約者の端末に再ログイン画面を表示し（Ｓ７１）、契約者が入力した契約者番号とパスワードを受け付けると（Ｓ７２）、取引システムに対して、受け付けた契約者番号とパスワードを指定した再ログイン要求を送信する（Ｓ７３）。
【００８２】
図２１は、契約者の操作する端末から再ログイン要求を受信した、取引システムにおける処理フローを示している。取引システムにおいて再ログイン要求を受信して（Ｓ８１）、ログイン要求に指定された契約者番号とパスワードを特定する（Ｓ８２）。特定した契約者番号について予め登録されたパスワードを契約者マスタから取得して、特定したパスワードと一致するかを照合する（Ｓ８３）。一致する場合には、正当な契約者からの再ログイン要求と判断して、以下のリカバリ処理を実行する。
【００８３】
まず、契約者マスタのパスワードロックを無しに更新し（Ｓ８４）、リカバリ権限を無しに更新する（Ｓ８５）。続いて、アクセスログのエラー回数のカウントをクリアして（Ｓ８６）、サブシステムに格納されたリカバリ情報ファイルについて、サブシステムに非表示とするための要求を送信する（Ｓ８７）。このようなリカバリ処理によって、パスワードロックが解除されて本人認証機能が回復し、通常どおり取引を行うことが可能になる
【００８４】
一方、パスワードが一致しない場合には、再ログイン要求は不正なものであると判断して、以後のリカバリ要求を受け付けることができないように、リカバリ権限を無しに更新し（Ｓ８８）、契約者の操作する端末にエラー画面を表示させて（Ｓ８９）、処理を終了する。
【図面の簡単な説明】
【００８５】
【図１】本発明にかかるリカバリシステムの実施形態の概要を示す図である。
【図２】本発明にかかるリカバリシステムの構成を示すブロック図である。
【図３】本発明にかかるリカバリシステムの契約者マスタテーブルの一例を示す図である。
【図４】本発明にかかるリカバリシステムにおけるアクセスログテーブルの一例を示す図である。
【図５】本発明にかかるリカバリシステムにおけるリカバリ権限テーブルの一例を示す図である。
【図６】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第１の図である。
【図７】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第２の図である。
【図８】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第３の図である。
【図９】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第４の図である。
【図１０】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第５の図である。
【図１１】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第６の図である。
【図１２】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第７の図である。
【図１３】本発明にかかるリカバリシステムによる、本人認証機能のリカバリのフローを示す第８の図である。
【図１４】本発明にかかるリカバリシステムにおける、取引システムの処理フローを示す第１のフローチャートである。
【図１５】本発明にかかるリカバリシステムにおける、サブシステムの処理フローを示す第１のフローチャートである。
【図１６】本発明にかかるリカバリシステムにおける、契約者が操作する端末の処理フローを示す第１のフローチャートである。
【図１７】本発明にかかるリカバリシステムにおける、サブシステムの処理フローを示す第２のフローチャートである。
【図１８】本発明にかかるリカバリシステムにおける、契約者が操作する端末の処理フローを示す第２のフローチャートである。
【図１９】本発明にかかるリカバリシステムにおける、取引システムの処理フローを示す２のフローチャートである。
【図２０】本発明にかかるリカバリシステムにおける、契約者が操作する端末の処理フローを示す第３のフローチャートである。
【図２１】本発明にかかるリカバリシステムにおける、取引システムの処理フローを示す第３のフローチャートである。
【００８６】
１０    端末
２０    取引システム
２１    契約者データベース
２１１  契約者マスタテーブル
２１２  アクセスログテーブル
２１３  リカバリ権限テーブル
２２    ログイン処理部
２３    リカバリ制御部
２４    サブシステム制御部
３０    サブシステム
３１    リカバリ情報作成部
３２    リカバリ情報格納部
４０    端末
【図１】
2007310630.tif 000003
【図２】
2007310630.tif 000004
【図３】
2007310630.tif 000005
【図４】
2007310630.tif 000006
【図５】
2007310630.tif 000007
【図６】
2007310630.tif 000008
【図７】
2007310630.tif 000009
【図１１】
2007310630.tif 000010
【図１２】
2007310630.tif 000011
【図１３】
2007310630.tif 000012
【図１４】
2007310630.tif 000013
【図１５】
2007310630.tif 000014
【図１６】
2007310630.tif 000015
【図１７】
2007310630.tif 000016
【図１８】
2007310630.tif 000017
【図１９】
2007310630.tif 000018
【図２０】
2007310630.tif 000019
【図２１】
2007310630.tif 000020
【図８】
2007310630.tif 000021
【図９】
2007310630.tif 000022
【図１０】
2007310630.tif 000023