情報端末、および認証サーバ
【課題】ユーザに複雑な操作を強いることなく、短時間で、個人情報に紐付けてケータイ端末のメールアドレスを登録できるようにする。
【解決手段】ATMでワンタイムパスワードを生成し、キャッシュカードから読み取った口座番号とワンタイムパスワードを認証サーバに送信し、認証サーバはそれらの情報を証DBに登録し、そしてATMのFeliCaリーダにケータイ端末がかざされたら、ATMはワンタイムパスワードを含む空メールを3者間通信によりケータイ端末に送信し、ケータイ端末から空メールが送信されたら、認証サーバはそれらを受信して空メールに含まれるワンタイムパスワードと同一のワンタイムパスワードを持つレコードを認証DBから探し出し、レコードの口座番号に紐付けて顧客DBにメールアドレスを登録する。
【解決手段】ATMでワンタイムパスワードを生成し、キャッシュカードから読み取った口座番号とワンタイムパスワードを認証サーバに送信し、認証サーバはそれらの情報を証DBに登録し、そしてATMのFeliCaリーダにケータイ端末がかざされたら、ATMはワンタイムパスワードを含む空メールを3者間通信によりケータイ端末に送信し、ケータイ端末から空メールが送信されたら、認証サーバはそれらを受信して空メールに含まれるワンタイムパスワードと同一のワンタイムパスワードを持つレコードを認証DBから探し出し、レコードの口座番号に紐付けて顧客DBにメールアドレスを登録する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ATM(現金預入支払機)等の本人確認可能な装置において生成したワンタイムパスワードを、FeliCa(ソニー株式会社の登録商標である)リーダの3者間通信機能を利用してモバイル端末に送信し、そのワンタイムパスワードを用いてサーバにアクセスさせることにより、メールアドレスの登録や個人専用ページへのログイン処理を行う技術に関する。
【背景技術】
【0002】
ATM等の本人確認機能付きの端末を利用した人への付加的サービスとして、利用直後に携帯電話(以下、ケータイ)にメールを配信することによって、近隣のスーパー等で売られている商品に関する情報提供やクーポン配布を行おうとした場合、銀行が管理する顧客データベースに当該利用者のケータイのメールアドレスが登録されていることが必要となる。
【0003】
事前に銀行口座の開設時の手続きやインターネットの会員専用ページ等においてメールアドレスを登録していれば問題はないが、そうでない場合は、ATMを利用したその場での迅速なメールアドレス登録が必要となる。すぐにクーポンを受け取って使いたい、あるいはすぐに詳細な情報を見たい利用者にとっては、書類にメールアドレスやその他本人確認情報を記入して郵送したり、自宅に帰ってインターネットバンキングにログインしてメールアドレスを登録するといった時間のかかる作業は好ましくない。ATMの利用中、または利用直後にメールアドレスを登録することが求められる。
【0004】
上記を実現する公知の方法としては、主に以下に示す3つがある。
【0005】
1つ目は、ATMの画面から利用者に直接入力してもらう方法である。
【0006】
2つ目は、2次元バーコードを用いる方法である。特許文献1には、ケータイに2次元バーコードを読み込ませることによって、Webサイトのアドレス情報の入力操作を行うことなくWebサイトにアクセスする技術が開示されている。この技術を応用し、メールアドレスを登録するためのモバイルサイトのURLを情報として含んだ2次元バーコードをATMの画面に表示し、それを利用者のケータイに読み取らせ、ATM利用後に上記サイトにアクセスしてもらう。そして、上記サイト内でメールアドレスとその他本人確認情報を入力させることによってメールアドレスを登録する。ここで本人確認情報とは、口座番号やニックネーム、パスワード、生年月日などの、個人を特定可能な情報である。誰のメールアドレスなのかを特定するためには、本人確認情報の入力が必要である。
【0007】
3つ目として、空メールの送信による方法がある。ATMに付属のFeliCaリーダから3者間通信機能を用いてケータイに空メールを送信し、その空メールをユーザに送信してもらうことで送信元(すなわちユーザのケータイ)のメールアドレスを取得し、登録する。
【0008】
【特許文献1】特開2005−57501号公報
【発明の開示】
【発明が解決しようとする課題】
【0009】
1つ目の方法では、メールアドレスの入力操作に時間がかかってしまい、ATMの待ち行列に並んでいる他の顧客の満足度が下がるため、この方法は実用に適さない。
【0010】
2つ目の2次元バーコードを用いる方法は、モバイルサイト内でメールアドレスや本人確認情報を入力するのに手間がかかってしまう。ユーザに多くの入力操作を行わせると、途中で登録を諦めてしまうユーザが多くなるため、より簡易な操作で登録を行わせる方法が求められる。
【0011】
3つ目の方法では、本人を特定する情報が得られないため、誰のメールアドレスなのかが分からない。
【0012】
メールアドレスの登録と並んで、モバイル端末のユーザにとって不便な操作を強いられているものが、個人専用ページへのログインである。個人専用ページとは、契約状況や保有資産、購買履歴などの個人ごとに異なる情報を閲覧したり、金融商品の売買やサービスの契約等の指示を出したりするためのページであり、アクセスするには通常、IDとパスワードの入力が必要とされる。モバイル端末でログインのためのIDやパスワードを入力するのはユーザにとって負担であり、より簡便なログイン操作が求められている。しかし、ケータイによる個人専用ページへのログインを簡便に行うための公知の技術は現在のところ存在しない。
【0013】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、ユーザに複雑な操作を強いることなく、短時間で、個人情報に紐付けてユーザのメールアドレスを登録できるようにすること、または、簡単な操作でユーザ端末から個人専用ページへログインできるようにし、ユーザの負担を軽減する装置、システム。方法、プログラムを提供することにある。
【課題を解決するための手段】
【0014】
上記課題を解決するために、本発明は、ATM等の情報端末においてワンタイムパスワードを生成し、ユーザのカード(例えば、キャッシュカード)から読み取った口座番号と前記ワンタイムパスワードを認証サーバに送信し、認証サーバはそれらの情報を認証DBに登録する。そして、情報端末の非接触方式通信手段(例えば、FeliCaリーダ)にユーザ端末(例えば、ケータイ)がかざされたら、情報端末は前記ワンタイムパスワードを含む空メールまたはURLを3者間通信によりユーザ端末に送信する。ユーザ端末から空メールが送信されるか、URLにアクセスされたら、認証サーバはそれらを受信して空メールまたはURLに含まれるワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから探し出し、当該レコードの口座番号に紐付けて顧客DBにメールアドレスを登録する、あるいは当該レコードの口座番号に紐付く個人専用ページを前記ユーザ端末に送信する。
【発明の効果】
【0015】
本発明によれば、ユーザに複雑な操作を求めずに、短時間で、個人情報に紐付けてケータイのメールアドレスを登録することができる。また、簡単な操作でケータイから個人専用ページへログインすることができる。よって、ユーザの負担を軽減できる。
【発明を実施するための最良の形態】
【0016】
以下に、本発明の実施の形態について説明する。
【0017】
図1は、本発明の一実施形態に係るシステム構成図である。ATM110は、銀行や小売店の店舗に設置されているATMである。ケータイ端末130は、ATMのユーザが所有しているケータイ端末であり、ここではATMの近くにあるものとする。認証サーバ120は、銀行のセンタに設置されているサーバであり、メールアドレスの登録や個人専用ページへのログインに必要な認証処理などを行う。ケータイ端末は、FeliCa方式のICチップを内蔵する。
【0018】
ATM110は、FeliCaリーダ(非接触通信手段)内蔵型のATMであり、FeliCaの三者間通信によりケータイ端末130と通信を行うことができる。また、ATM110はネットワーク150(例えば、有線LAN)を介して認証サーバ120と通信を行う。ケータイ端末130は、無線ネットワーク160(例えば、携帯電話通信網)を介して認証サーバ120と通信を行う。
【0019】
なお、ATM110は必ずしもATMである必要はなく、例えば現金入出金機能のないキオスク端末でもよい。また、通信方式は、FeliCa方式に限られない。
【0020】
図2は、ATM110または認証サーバ120の機能を実現する情報処理装置200のハードウェア構成を例示する図である。情報処理装置200は、HDDに記録されたプログラムをメモリを利用して実行することにより各部の機能を実現するCPU(Central Processing Unit)210、メモリ220、HDD(Hard Disk Drive)230、FeliCa通信インタフェース240、有線通信インタフェース250、無線通信インタフェース260、入出力インタフェース270を備え、これらはバスにより接続される。
【0021】
以下では、ATM110と認証サーバ120がメールアドレスの登録に利用される場合の実施形態と、個人専用ページへのログインに利用される場合の実施形態とについて、順に述べていく。
【実施例1】
【0022】
まずはメールアドレスの登録に利用される場合の実施形態を説明する。
【0023】
図3は、認証サーバ120の詳細な機能構成の一例を示すブロック図である。認証サーバ120は、パスワード登録部310、メールアドレス確認部320、個人情報照合部330、パスワード抽出部340、メールアドレス登録部350、パスワード削除部360、URL記載メール送信部390を備える。これらの機能は、CPUがプログラムを実行することにより実現される。さらに、認証DB370、顧客DB380を備える。これらはHDDなどの記憶装置に格納される。
【0024】
パスワード登録部310、メールアドレス確認部320、個人情報照合部330、パスワード抽出部340、メールアドレス登録部350、パスワード削除部360、URL記載メール送信部390の処理内容は、後に述べる認証サーバ120のフローチャートの中で詳しく説明する。
【0025】
認証DB370は、ATM110から送られてきた口座番号とワンタイムパスワード等の情報を一時的に登録し、ケータイ端末130から送られてきた空メールに含まれるワンタイムパスワードを突き合わせることによって、空メールを送信してきたユーザの口座番号を特定するために用いる。認証DB370は、例えば図4に示すように、口座番号410、口座番号410に対応する顧客が最後にATMを利用した日時420、およびワンタイムパスワード430を格納する。このワンタイムパスワード430は、口座番号410と日時420の値に基づいてATM110が作成し認証サーバ120に送信したパスワードである。
【0026】
顧客DB380は、顧客の口座番号に紐付けて顧客の個人情報を管理するデータベースである。これは例えば図5に示すように、口座番号510、口座番号510に対応する顧客の生年月日520とメールアドレス530を格納する。
【0027】
なお、生年月日520は、個人を特定するための情報であって他人が容易に知りえない情報であれば他のものでもよく、例えば電話番号や郵便番号でも構わない。ただし、後で述べるようにこれらの個人情報は個人情報照合部330においてケータイ端末から入力された値との照合を行うために用いるため、ケータイ端末での入力のしやすさを鑑みて数字で表現されるものとする。また、口座番号の代わりに、個人ごとに割り当てられた個人IDであってもよい。
【0028】
図6は、ATM110の詳細な機能構成の一例を示すブロック図である。ATM110は、本人確認部610、パスワード生成部620、空メール送信部630を備える。これらの処理内容は、後に述べるATM110のフローチャートにおいて詳しく説明する。
【0029】
図7および図8は、ユーザによるATM利用時におけるATM110および認証サーバ120の動作の一例を示すフローチャートである。まず、ATM110は、ユーザから入金または出金の指示を受ける。通常この指示はATMに表示されたメニュー画面へのユーザのタッチ操作によって行われる(S100)。なお、各画面は記憶装置内に予め記憶されており、ATMは記憶装置から画面を読み出して、表示する。
【0030】
次に、ATM110はユーザが挿入したキャッシュカードから口座番号を読み取る(S101)。
【0031】
続いて、ATM110はユーザからの暗証番号(PIN)の入力を受け付ける(S102)。このPINが正しいかどうかの確認は、PINが入力されてすぐに行う場合もあれば、入出金の額などの必要事項が入力された後に認証サーバ120と交信する際に行われる場合もあるが、ここでは詳しく説明しない。いずれにしてもPINが正しければ入出金等の処理を継続し、正しくなければ処理を中止する。例えば、ユーザから入力されたPINの検証は、ユーザから入力されたPINがキャッシュカードから読み取られたPINに一致するか否かにより行う。一致すれば、PINが正しいと判定し、一致しなければ、PINが正しくないと判定する。
【0032】
S100における指示が出金の場合、ATM110はユーザからの出金金額の入力を受け付ける(S103)。
【0033】
S100における指示が入金の場合、ATM110は現金投入口を介してユーザから現金を受け取る(S104)。
【0034】
なお、入出金機能のないキオスク端末の場合、上記S100、S103、S104の処理は行われない。
【0035】
次に、ATM110は、S101で読み取った口座番号とATM110が認識している現在日時に基づいてパスワードを生成する(S105)。例えば、ATM110は、ATM110に内蔵された時計から読み取ることにより、またはATM110に接続されたセンタサーバへの問い合わせにより、現在日時を認識できる。
【0036】
パスワードの具体的な生成方法としては、例えば図9に示すように、最初のX桁で口座番号を表し、次の14桁で現在の西暦、月、日、時、分、秒を表した数を、所定のハッシュ関数に入力してハッシュ値を求める方法がある。ハッシュ関数は一方向性関数であるためハッシュ関数を使ってパスワードを生成すると、万一ハッシュ関数が第三者に漏れて、さらに後で述べるケータイ端末130から認証サーバ120へ送信するメールが傍受され、メール本文に書かれたパスワードがその第三者に知られても、口座番号が知られることはないというメリットがある。それに対して、共通鍵を使ってパスワードを生成すると、万一共通鍵とパスワードが第三者に漏れた場合、パスワードが復号されて口座番号が知られることになるが、共通鍵を使ってパスワードを生成してもよい。
【0037】
パスワードを現在日時と口座番号に基づいて生成する理由は、同じパスワードが2回以上生成される可能性を極力少なくするためである。異なるユーザが同時刻に別々のATMを利用することや、同一のユーザが異なる時刻に複数回ATMを利用することはあるが、同一のユーザが同時刻に別々のATMを利用することは不可能である。そのため、パスワードの元となる値(ハッシュ関数に入力する値)は同じものが2度使われることはない。その結果、他のユーザとパスワードがかぶる可能性は事実上ゼロに等しくなる。ハッシュ関数の性質上、異なる値のハッシュ値を求めた結果が同じになる可能性はゼロではないが、実務上はその可能性は無視してよい。
【0038】
図7に戻って説明を続ける。ATM110は、パスワード、パスワードを生成する元となった口座番号と日時、および入出金に関する指示を、認証サーバ120に対して送信する。なお、ATM110が入出金機能のないキオスク端末の場合は、入出金に関する指示は送信しない(S106)。
【0039】
上記のように、入出金指示と同時にパスワードや日時を認証サーバ120に送信することによって、ATM110と認証サーバ120との間のメッセージ授受の回数が、入出金処理のみを行う場合と比較して変わらずに済む。したがって、ATMユーザから見た処理パフォーマンスを落とさずに、現状世の中に出回っているATMに本発明の認証機能を追加することができる。
【0040】
認証サーバ120は、ATM110からのパスワード、パスワードを生成する元となった口座番号と日時、および入出金に関する指示を受信する(S200)。
【0041】
認証サーバ120は、上記で受信したパスワード、口座番号、日時を認証DB370に登録する。このとき、同じ口座番号のレコードが既に存在していれば上書きする。それにより、1つの口座番号に関して許される(認証をパスできる)パスワードが常に1つ以下に保たれ、第三者による成りすましの成功確率がより低くなる(S201)。
【0042】
認証サーバ120は、入出金指示の内容に基づき、口座残高の変更を行う(S202)。
【0043】
パスワードを登録する処理(S201)と口座残高の変更処理(S202)はそれぞれ独立に行う。これは、何らかの障害によりパスワードの登録がスムーズに行えなかった場合でも、本来の銀行業務である入出金処理を滞りなく行い、速やかにATMの画面に処理結果を表示することで、ATMユーザの満足度を低下させないことを目的としている。
【0044】
認証サーバ120は、顧客DB380を参照し、S200で受信した口座番号に対応する顧客のメールアドレスが既に登録されているか否かを確認する。そして、その結果とS202における残高変更処理の結果をATM110に送信する(S203)。
【0045】
ATM110は、メールアドレスが登録されているか否かの確認結果と残高変更処理の結果を受信する(S107)。
【0046】
ATM110は、画面に広告を表示する(S108)。なお、広告の表示タイミングは必ずしもS107の後である必要はなく、金額の入力受付S103または現金の受け取りS104の後から、S105、S106、S107の処理と並行しながら広告を表示していてもよい。また、必ずしも次に述べるS109やS110の前である必要もなく、S109やS110の画面表示と同時に広告表示を開始してもよい。
【0047】
次にATM110は、メールアドレスが未登録であった場合、明細書を印刷するか否かの選択肢と、メールアドレス登録方法の案内を表示する。画面遷移が増えてユーザが煩わしさを感じる事態を避けるため、これら2つの情報は1画面に表示する。なお、上で述べたように、ここで同時に広告を表示してもよい(S109)。
【0048】
図10に、ATMの画面イメージの一例を示す。S109の処理における画面のイメージはG109である。同様に、これから説明するS110、S111、S112の処理における画面のイメージはそれぞれG110、G111、G112である。
【0049】
図7に戻って説明を続ける。S108の処理の後、メールアドレスが登録済みであった場合、ATM110はメール送信を行うか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレス変更方法の案内を表示する。これらの情報は1画面に表示し、さらに広告を表示してもよい。(S110)。
【0050】
S109またはS110においてATMに付属したFeliCaリーダにケータイ端末130がかざされたら、ATMはケータイ端末からのレスポンスの受信によりケータイ端末130がかざされたことを検知してFeliCaの3者間通信によりケータイ端末130のメーラー(メール機能を実現するアプリケーションプログラム)を起動して空メールを送信する。このとき、空メールの送信先アドレスには所定の空メール受付用のアドレスを設定し、空メールの本文にはS105で作成したパスワードを記載する。また、ATM110の画面からはメールの送信可否を問う選択肢を削除する。これは、ユーザにメールアドレスの登録または変更の意思があり、旧メールアドレス(未登録の場合も含めて)にメールを送る意味がないためである。(S111)。
【0051】
図11に、S111でケータイ端末130に送信する空メールの内容の一例を示す。3者間通信機能により、ケータイ端末130のメーラーを起動すると同時に宛先や本文に図11に示すような文字列を記載させることが可能である。ユーザはケータイ端末の「メール送信」ボタンを押すだけで空メールを銀行の空メール受付用アドレス(ここでは「bank@jp」)に送信することができる。
【0052】
S109またはS111の後に明細書の印刷可否が選択されたら、またはS110の後に明細書の印刷可否とメールの送信可否が選択されたら、ATM110は取引完了画面を表示する(S112)。
【0053】
なお、G110の画面でメールを送信する旨が選択された場合、ATM110からメールサーバ等に対してメール送信指示が出され、S108で表示した広告の商品やサービスに関する詳細な情報やWebサイトへのリンクを本文に記載したメールが、登録済みのメールアドレスに対して送信される。
【0054】
図7および図8に示したフローチャートにおいて、本人確認部610はS101およびS102の処理を、パスワード生成部620はS105およびS106の処理を、空メール送信部630はS107、S108、S109、S110、S111、S112の処理を、パスワード登録部310はS200とS201の処理を、メールアドレス確認部320はS203の処理を行う。
【0055】
次に、別の実施形態として、認証サーバ120がメールアドレスの登録済/未登録の確認を行わない場合のフローチャートを図12および図13に示す。また、ATM画面のイメージを図14に示す。以下ではそれらが図7、図8、図10と異なる部分について述べる。
【0056】
まず、図7におけるメールアドレス登録済/未登録の確認処理(S203)は図12では存在せず、認証サーバ120はS202の処理の後に直ちにATM110に残高変更処理の結果を送信し(S204)、ATM110はこれを受信する(S113)。
【0057】
メールアドレスが登録済みか未登録かATM110は分からないため、S109とS110のように分岐はせず、ATM110はメール送信を行うか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレス登録/変更方法の案内を表示する(S114)。
【0058】
S114におけるATM110の画面イメージが図14におけるG114である。以下同様に、S115、S116、S118に対応するATM110の画面イメージはG115、G116、G118である。
【0059】
S114の後、ATM110に付属のFeliCaリーダにケータイ端末がかざされたら、3者間通信によりケータイ端末のメーラーを起動して空メールを送信する。空メールの内容はS111の場合と同様である。このとき、画面からはメールの送信可否を問う選択肢を削除する。これは、ユーザにメールアドレスの登録または変更の意思があり、旧メールアドレス(未登録の場合も含めて)にメールを送る意味がないためである(S115)。
【0060】
S115の後にユーザによって明細書の印刷可否が選択されたら、ATM110は取引完了の画面を表示する(S116)。
【0061】
S114の後にユーザによって明細書の印刷可否およびメール送信可否が選択されたら、ATM110はメールの送信可否について「送信する」が選択されたか「送信しない」が選択されたかを識別する(S117)。
【0062】
「送信しない」が選択された場合、ATM110は取引完了の画面を表示する(S116)。
【0063】
「送信する」が選択された場合、ATM110は取引完了の旨とともにメールがユーザに届かない場合の案内を表示する。これは、ユーザのメールアドレスが未登録でありながらメールを「送信する」旨がユーザによって選択される可能性があり、その場合にはユーザにメールが届かないためである。
【0064】
図15は、ユーザによってパスワード付き空メールが送信された際のケータイ端末130および認証サーバ120の動作の一例を示すフローチャートである。まず、ケータイ端末130は認証サーバ120に空メールを送信する(S301)。
【0065】
認証サーバ120はケータイ端末130から送信された空メールを受信する(S401)。
【0066】
次に、認証サーバ120は受信した空メールからパスワード部分を抽出する。このパスワード部分とは、図11の例で言えば本文に記載された「bmsv8pm42aaat」の文字列のことである(S402)。
【0067】
次に、認証サーバ120はメールから抽出したパスワードをキーとして認証DB370のワンタイムパスワード430の項目を検索する(S403)。
【0068】
認証DB370に対する検索(S403)の結果、レコードが見つからなかった場合、認証サーバ120は認証失敗と判断し、認証失敗の旨のメールをケータイ端末130に送信する。その際の送信先メールアドレスは、空メールの送信元アドレスである(S405)。
【0069】
認証DB370に対する検索(S403)の結果、レコードが見つかった場合、そのレコードの口座番号410の値は、空メールの送信元ユーザの口座番号であるはずである。そこで、認証サーバ120は認証成功と判断し、見つかったレコードの口座番号410の値をキーとして顧客DB380の口座番号510の項目を検索し、ヒットしたレコードのメールアドレス530の項目に、空メールの送信元のメールアドレスを登録する(S406)。
【0070】
さらに認証サーバ120は、認証成功の旨のメールをケータイ端末130に送信する。その際の送信先メールアドレスは、空メールの送信元アドレスである(S407)。
【0071】
そして、認証サーバ120は認証DB370から、S406でヒットしたレコードを削除する。これにより、その後悪意のある第三者が自らパスワード付き空メールを作成して他者に成りすまし、他者の顧客DBレコードに自分のメールアドレスを登録させる行為を防止する(S408)。
【0072】
また、別の実施形態として、空メールから抽出したパスワードをキーとして認証DBを検索(S403)した結果、レコードがヒットした場合に、すぐに認証成功とは判断せず、より万全を期するため個人情報の照合を行い、照合が一致したら認証成功と判断することとしてもよい。その場合、まず認証サーバ120はケータイ端末130にメールを送信する(S409)。
【0073】
このメールの本文には、個人情報の入力を行うためのサイトに誘導するURL(サイトの格納場所)を記載しておく。そのURLには、S402でメールから抽出したパスワードを埋め込んでおく。それにより、当該URLにユーザがアクセスした際に、どのユーザからのアクセスであるかを認証サーバが認識することができる。
【0074】
そして、認証サーバ120は前記URLに対するケータイ端末からのアクセスを受け、個人情報の照合を行う(S410)。この部分の詳細は後述する。
【0075】
個人情報の照合結果が一致の場合は認証成功と判断し、前述したS406の処理に進む。
【0076】
個人情報の照合結果が不一致の場合は認証失敗と判断し、認証サーバ120はケータイ端末130に認証失敗の旨のメールを送信する(S411)。
【0077】
個人情報の照合処理について、図16のフローチャートを用いて説明する。まず、認証サーバ120は、ケータイ端末130がアクセスしたURLに埋め込まれたパスワードをキーにして認証DBを検索することにより、アクセスしたユーザの口座番号を特定する(S412)。
【0078】
なお、口座番号の特定方法は、必ずしもパスワードをキーにした認証DBの検索によらなくてもよく、例えばパスワードが口座番号を含む文字列を共通鍵で暗号化したものであるならば、バスワードを共通鍵で復号することにより口座番号を特定してもよい。
【0079】
次に、認証サーバ120は個人情報の入力画面をケータイ端末130へ送信してケータイ端末130に表示させる。ここでの個人情報とは、例えば生年月日である。このときの入力画面は、例えば図17のようになる。S412において口座番号が特定されているため、ユーザは口座番号を入力する必要はなく、個人情報だけを入力すればよい(S413)。
【0080】
ケータイ端末130からの個人情報の入力(S304)を受けて、認証サーバ120は顧客DBに登録されている個人情報との照合を行う。すなわち、S412で特定された口座番号をキーにして顧客DB380を検索し、ヒットしたレコードの生年月日520とケータイ端末130から入力された生年月日とが一致するかを判定する(S414)。
【0081】
一致した場合は認証成功と判断し(S416)、不一致の場合は認証失敗と判断する(S417)。
【0082】
ここまでで述べた実施形態は、認証サーバ120がATM110から送信された口座番号やパスワードを登録する処理(例えばS201)が、認証サーバ120がケータイ端末130から空メールを受信する処理(S401)よりも前に行われていることが前提となっている。しかし、処理負荷増大などの理由により認証サーバのパフォーマンスが落ち、パスワード登録処理(S201)が完了するのに時間がかかってしまい、空メールの受信(S401)が先に行われる可能性も考えられる。そのようなことが起こった場合、これまでに述べた実施形態では、空メールから抽出したパスワードをキーにして認証DBを検索(S403)してもヒットせず、認証が失敗(S405)してしまう。そこで、空メールの受信処理が先に来ても認証が成功するような実施形態について、これまでに述べた実施形態との違いを次に述べる。
【0083】
まず、図15におけるメールアドレス登録部350がどのように変わるかを述べる。図15のフローチャートで示したメールアドレス登録部350では、空メールから抽出したパスワードをキーにして認証DBを検索(S403)してヒットしなかった場合、認証失敗と判断して認証失敗の旨のメールをケータイ端末130に送信(S405)していたが、認証失敗と判断せず、認証DBに日時、パスワード、およびメールアドレスを登録する。ここでの日時は認証サーバが認識する現在日時であり、メールアドレスは空メールの送信元アドレスである。認証DBにメールアドレスを登録するため、認証DBは図19に示すようにメールアドレス1840を格納することができるものを用いる。
【0084】
次に、図7のフローチャートにおけるパスワード登録部310がどのように変わるかを、図18のフローチャートを用いて述べる。
【0085】
認証サーバ120は、ATM110から口座番号、日時、パスワード、および入出金指示を受信(S500)した後、受信したパスワードをキーにして認証DBのワンタイムパスワード430の項目を検索する(S501)。
【0086】
検索でヒットしなかった場合、図7におけるパスワードの登録(S201)と同じ処理を行う(S502)。
【0087】
検索でヒットした場合、すなわち先にユーザからの空メールが到着しており、認証DBにパスワードとメールアドレスが登録されている場合、認証サーバ120は認証成功と判断し、ATM110から受信した口座番号をキーとして顧客DB380の口座番号510の項目を検索し、ヒットしたレコードのメールアドレス530の項目に、認証DB370に登録されていたメールアドレスを登録する(S503)。
【0088】
さらに認証サーバ120は、認証成功の旨のメールをケータイ端末130に送信する。その際の送信先メールアドレスは、認証DB370に登録されていたメールアドレスである(S504)。
【0089】
そして、認証が成功したらS501でヒットしたレコードは不要になるため、認証サーバ120は認証DB370から当該レコードを削除する。(S505)。
【0090】
また、別の実施形態として、ATM110から受信したパスワードをキーとして認証DBを検索(S501)した結果、レコードがヒットした場合に、すぐに認証成功とは判断せず、より万全を期するため個人情報の照合を行い、照合が一致したら認証成功と判断することとしてもよい。その場合、まず認証サーバ120はヒットしたレコードに記録されているメールアドレスに対してメールを送信し(S506)、個人情報の照合を行う(S507)。送信するメールの内容、および個人情報の照合方法は、それぞれ前述の図15におけるメール送信処理(S409)と個人情報照合処理(S410)と同様である。個人情報の照合結果が一致であれば顧客DBにメールアドレスを登録(S503)し、不一致であれば認証失敗と判断して認証失敗の旨のメールをケータイ端末130へ送信する(S508)。
【0091】
ここで、セキュリティが一部破られた場合の影響について述べる。ATM110と認証サーバ120との間の伝送路は通常は強固なセキュリティで守られているので、ここではユーザが認証サーバに送った空メールが傍受された場合と、ATMでパスワードを生成する際のハッシュ関数が漏れた場合について述べる。
【0092】
メールが第三者によって傍受された場合の影響は以下である。その第三者が同じ内容のメールを自分のケータイ端末から送って、顧客DBにおける他者のレコードに自分のメールアドレスを登録しようと企てたとする。その場合、正当なユーザのメールが第三者のメールよりも先に認証サーバ120に到着しているはずであるので、正当なユーザの認証は成功し、その後第三者がメールを送ったときには既に認証DB370からレコードは削除されているため、第三者の認証は失敗する。したがって、メールが傍受されることによって実質的な被害は発生しない。
【0093】
ハッシュ関数が第三者に漏れた場合の影響は以下である。その第三者が、他者の口座番号を入手し、かつその口座番号のユーザのATM最終利用日時を知ることができれば、それらの情報からハッシュ関数を使ってパスワードを生成し、メールを認証サーバ120に送信し、顧客DBにおける他者のレコードに自分のメールアドレスを登録することができる。しかし、特定の他者がATMを利用した日時を正確に知ることは通常不可能である。しかも、パスワードは一定期間しか有効でないため、本ケースで第三者が成りすましに成功する可能性は低い。
【0094】
メールが傍受され、かつハッシュ関数も第三者に漏れたとする。その場合でも、前に述べたように、メール本文のパスワードを復号することはできないので、口座番号が第三者に知られることはなく、実質的な被害は発生しない。
【0095】
以上で、ATM110と認証サーバ120がメールアドレスの登録に利用される場合の実施形態について述べた。
【実施例2】
【0096】
次に、ATM110と認証サーバ120が個人専用ページへのログインに利用される場合の実施形態について述べる。
【0097】
図20は、認証サーバ120の詳細な機能構成の一例を示すブロック図である。メールアドレスの登録に認証サーバが利用される場合の実施形態(図3)との違いは、メールアドレス確認部320がないことと、メールアドレス登録部350がログイン処理部350Aになっていること、およびURL記載メール送信部390がないことである。
【0098】
図21は、ATM110の詳細な機能構成の一例を示すブロック図である。メールアドレスの登録にATMが利用される場合の実施形態(図6)との違いは、空メール送信部630がURL送信部630Aになっていることである。
【0099】
図22は、ユーザによるATM利用時におけるATM110および認証サーバ120の動作の一例を示すフローチャートである。以下、図7および図8との相違点について述べる。
【0100】
まず、ATM110の本人確認部610、パスワード生成部620の動作は図7と同様である。また、認証サーバ120のパスワード登録部310の動作も図7と同様である。
【0101】
図7ではメールアドレスが登録済みか否かの確認(S203)を認証サーバ120にて行っていたが、本実施例ではメールアドレスの登録が目的ではないのでこの処理はない。残高の変更(S202A)の後、直ちにATM110に対して処理結果を送信する。
【0102】
ATM110は、処理結果を受信し(S601)、画面に広告を表示する(S602)。そして、画面に明細書を印刷するか否かの選択肢と、ケータイ端末130でFeliCaリーダからURLを受信する方法の案内を表示する。画面遷移が増えてユーザが煩わしさを感じる事態を避けるため、これら2つの情報は1画面に表示する。また、同時に広告を表示してもよい(S603)。
【0103】
図23に、ATM110の画面イメージの一例を示す。S603の処理における画面のイメージはG603である。同様に、これから説明するS604、S605の処理における画面のイメージはそれぞれG604、G605である。
【0104】
明細書の印刷可否の選択肢とURL受信方法の案内を表示(S603)した後、ATMに付属したFeliCaリーダにケータイ端末130がかざされたら、ATMはそれを検知してFeliCaの3者間通信によりケータイ端末130のWebブラウザを起動してURLを送信する。このURLは、ユーザが個人専用ページにログインするためのURLである。また、このURLには、パスワード生成部620においてATM110が生成したパスワードを埋め込んでおく(S604)。
【0105】
S603またはS604の処理の後、ユーザによって明細書の印刷可否が選択されたら、ATM110は取引終了画面を表示する(S605)。
【0106】
図24は、ATM110からケータイ端末130に送信されたURLに基づいてユーザが認証サーバ120にアクセスした際のケータイ端末130および認証サーバ120の動作の一例を示すフローチャートである。
【0107】
まず、ケータイ端末130はパスワードが埋め込まれたURLに基づいて認証サーバ120にアクセスする(S701)。
【0108】
認証サーバ120はケータイ端末130からのアクセスを受け付け(S801)、アクセスしてきたURLからパスワード部分を抽出する(S802)。
【0109】
次に、認証サーバ120はURLから抽出したパスワードをキーとして認証DB370のワンタイムパスワード430の項目を検索する(S803)。
【0110】
認証DB370に対する検索(S803)の結果、レコードが見つからなかった場合、認証サーバ120は認証失敗と判断し、認証失敗の旨を記載したページデータをケータイ端末130に送信する(S804)。
【0111】
認証DB370に対する検索(S803)の結果、レコードが見つかった場合、そのレコードの口座番号410の値は、パスワード付きURLに基づき認証サーバ120にアクセスしたユーザの口座番号と同一のはずである。そこで、認証サーバ120は認証成功と判断し、当該口座番号に紐付く個人専用ページのデータをケータイ端末130に送信する(S805)。
【0112】
そして、認証サーバ120は認証DB370から、S803でヒットしたレコードを削除する(S806)。
【0113】
また、別の実施形態として、URLから抽出したパスワードをキーとして認証DB370を検索(S803)した結果、レコードがヒットした場合に、すぐに認証成功とは判断せず、より万全を期するため個人情報(S807)の照合を行い、照合が一致したら認証成功と判断することとしてもよい。その場合の個人情報照合処理は、図16のフローチャートを用いて既に説明した個人情報照合部330の処理と同様である。個人情報の照合結果が不一致の場合は認証失敗と判断し、認証サーバ120はケータイ端末130に認証失敗の旨を記載したページデータをケータイ端末130に送信する(S808)。その後、パスワードの削除処理を行う(S806)。
【0114】
以上の説明は、認証サーバ120によるパスワードの登録処理(S201)が、ケータイ端末130から認証サーバ120へのアクセス(S701)よりも前に行われることが前提になっている。しかし、処理負荷増大などの理由により認証サーバのパフォーマンスが落ち、パスワード登録処理(S201)が完了するのに時間がかかってしまい、ケータイ端末130からのアクセス(S701)が先に行われる可能性も考えられる。そのようなことが起こった場合、これまでに述べた実施形態では、URLから抽出したパスワードをキーにして認証DBを検索(S803)してもヒットせず、認証が失敗(S804)してしまう。そこで、そもそもパスワード登録処理(S201)を行わず、ケータイ端末130からのアクセスを受けたときにURLから抽出したパスワードを復号して口座番号と日時を復元することによって、認証サーバのパフォーマンスに関係なく確実に認証を行うことを可能にする。この実施形態について次に述べる。
【0115】
図25は、ユーザによるATM利用時におけるATM110および認証サーバ120の動作の一例を示すフローチャートである。以下、図22との相違点について述べる。
【0116】
まず、パスワード生成部620において、ATM110は口座番号と日時に基づいてパスワードを生成する(S900)。
【0117】
このとき、ハッシュ関数を使うのではなく、ATM110が保管する共通鍵を使ってパスワードを生成する。また、この共通鍵は認証サーバ120でも保管しておく。
【0118】
ATM110は生成したパスワード、口座番号および日時を認証サーバ120に送信することはしない。また、認証サーバ120ではパスワード登録処理は行わない。
【0119】
URL送信部630Aにおける処理については図22の説明と同様である。
【0120】
続いて、図26のフローチャートを用いて、ATM110からケータイ端末130に送信されたURLに基づいてユーザが認証サーバ120にアクセスした際のケータイ端末130および認証サーバ120の動作の一例を説明する。なお、図24における説明との相違点についてのみ述べる。
【0121】
まず、パスワード抽出部340は図24の説明と同様である。
【0122】
URLからパスワードを抽出(S1002)した後、認証サーバ120は共通鍵を用いてパスワードを復号し、パスワードの元となった日時と口座番号とを抽出する(S1003)。
【0123】
次に、認証サーバ120は、抽出した日時が現在時刻から見て一定時間(仮にaとする)以上前でないか、一定時間(仮にbとする)以上後でないかを確認する。このaとbは同一でなくてよい。正当なユーザからのアクセスであれば、ユーザはATMの利用直後にアクセスしたのだから、抽出した日時は現在時刻よりも少しだけ前の時刻であるはずである。ただし、ATMと認証サーバの内部時計がずれている可能性もあるため、抽出した日時が現在時刻よりも少しだけ後の時刻であってもよいこととする。第三者からの不正アクセスを防止するため、抽出した日時が現在時刻よりも一定以上離れていたら、認証失敗と判定することとする(S1004)。
【0124】
抽出した日時が現在時刻から見て一定以上前か、または一定以上後であれば、認証サーバ120は認証失敗と判定し、認証失敗の旨を記載したページデータをケータイ端末130に送信する(S1005)。
【0125】
抽出した日時が現在時刻から見て一定以上前でなく、または一定以上後でなければ、認証サーバ120はS1003で抽出した口座番号をキーとして顧客DBを検索する(S1006)。
【0126】
ここでヒットしなければ、認証サーバ120は認証失敗と判定し、認証失敗の旨を記載したページデータをケータイ端末130に送信する(S1005)。
【0127】
ヒットすれば、認証サーバ120は個人情報照合処理を行う。この処理内容は、図16のフローチャートを用いて既に説明した個人情報照合部330の処理と同様である。
【0128】
なお、これまでに説明した他の実施例では個人情報の照合を行わずに認証成功と判定する例もあったが、パスワードを復号することにより日時と口座番号を復元する本実施例では、個人情報の照合を行うものとする。これは、本実施例が他の実施例に比べてセキュリティの面で脆弱であるためである。すなわち、他の実施例ではハッシュ関数が外部に漏れても、第三者が他のユーザに成りすますためには他のユーザの口座番号に加えてATM利用日時を正確に知る必要があるが、本実施例では、第三者が共通鍵を入手すると他のユーザの口座番号を知るだけで成りすましが成功する恐れがある。そのため、より万全を期するため個人情報の照合を行う。
【0129】
個人情報の照合の結果、一致であれば個人専用ページのデータをケータイ端末130に送信し(S1006)、不一致であれば認証失敗の旨を記載したページのデータをケータイ端末130に送信する(S1007)。
【0130】
なお、図24のフローチャートで説明したパスワードの削除処理(S806)は、本実施例ではそもそも認証DBを用いないので不要である。
【0131】
最後に、認証DBに登録されてから一定期間が過ぎたレコードを削除する処理について説明する。これは、パスワードを一定期間のみ有効とすることにより、認証DBのデータ容量を削減するとともに、第三者による不正アクセスの可能性を削減することを目的とする。通常、正当なユーザはATMの利用直後にケータイ端末から空メールもしくはパスワード埋め込み型URLによって認証サーバにアクセスすることが想定されるので、認証DBにおいて登録から一定期間が過ぎたレコードを削除することによって正当なユーザの利便性が損なわれることはない。
【0132】
図27は、認証DBからのレコード削除に関する認証サーバ120の動作の一例を示すフローチャートである。まず、認証サーバ120は、認証DB370から、日時420が一定期日よりも前のレコードを全て抽出する(S1101)。
【0133】
次に、認証サーバ120は抽出したレコードを削除する(S1102)。
【産業上の利用可能性】
【0134】
本発明は、ATMと携帯電話とを利用した携帯電話のメールアドレスの登録に利用可能である。
【図面の簡単な説明】
【0135】
【図1】システム全体のシステム構成図
【図2】ATMまたは認証サーバの機能を実現する情報処理装置のハードウェア構成図
【図3】認証サーバの機能構成図
【図4】認証DBの格納する1レコードのデータ構成図
【図5】顧客DBの格納するレコードのデータ構成図
【図6】ATMの機能構成図
【図7】ATM利用時のATMおよび認証サーバの処理のフローチャート
【図8】ATM利用時のATMの処理のフローチャート
【図9】パスワード生成方法を示す概念図
【図10】ATMの画面イメージ
【図11】ケータイ端末の空メールの画面イメージ
【図12】メールアドレスの登録済/未登録の確認を行わない場合のATM利用時のATMおよび認証サーバの処理のフローチャート
【図13】メールアドレスの登録済/未登録の確認を行わない場合のATM利用時のATMの処理のフローチャート
【図14】ATMの画面イメージ
【図15】パスワード付き空メール送信時のケータイ端末および認証サーバの処理のフローチャート
【図16】個人情報の照合時の認証サーバおよびケータイ端末の処理のフローチャート
【図17】ケータイ端末の個人情報の入力画面イメージ
【図18】認証サーバおよびケータイ端末の処理のフローチャート
【図19】認証DBの1レコードのデータ構成図
【図20】認証サーバの機能構成図
【図21】ATMの機能構成図
【図22】ATM利用時のATMおよび認証サーバの処理のフローチャート
【図23】ATMの画面イメージ
【図24】認証サーバアクセス時のケータイ端末および認証サーバの処理のフローチャート
【図25】ATM利用時のATMおよび認証サーバの処理のフローチャート
【図26】ATM利用時のケータイ端末および認証サーバの処理のフローチャート
【図27】レコード削除時の認証サーバの処理のフローチャート
【符号の説明】
【0136】
110‥ATM、120‥認証サーバ、130‥ケータイ端末、140‥三者間通信網、150‥ネットワーク、160‥無線ネットワーク。
【技術分野】
【0001】
本発明は、ATM(現金預入支払機)等の本人確認可能な装置において生成したワンタイムパスワードを、FeliCa(ソニー株式会社の登録商標である)リーダの3者間通信機能を利用してモバイル端末に送信し、そのワンタイムパスワードを用いてサーバにアクセスさせることにより、メールアドレスの登録や個人専用ページへのログイン処理を行う技術に関する。
【背景技術】
【0002】
ATM等の本人確認機能付きの端末を利用した人への付加的サービスとして、利用直後に携帯電話(以下、ケータイ)にメールを配信することによって、近隣のスーパー等で売られている商品に関する情報提供やクーポン配布を行おうとした場合、銀行が管理する顧客データベースに当該利用者のケータイのメールアドレスが登録されていることが必要となる。
【0003】
事前に銀行口座の開設時の手続きやインターネットの会員専用ページ等においてメールアドレスを登録していれば問題はないが、そうでない場合は、ATMを利用したその場での迅速なメールアドレス登録が必要となる。すぐにクーポンを受け取って使いたい、あるいはすぐに詳細な情報を見たい利用者にとっては、書類にメールアドレスやその他本人確認情報を記入して郵送したり、自宅に帰ってインターネットバンキングにログインしてメールアドレスを登録するといった時間のかかる作業は好ましくない。ATMの利用中、または利用直後にメールアドレスを登録することが求められる。
【0004】
上記を実現する公知の方法としては、主に以下に示す3つがある。
【0005】
1つ目は、ATMの画面から利用者に直接入力してもらう方法である。
【0006】
2つ目は、2次元バーコードを用いる方法である。特許文献1には、ケータイに2次元バーコードを読み込ませることによって、Webサイトのアドレス情報の入力操作を行うことなくWebサイトにアクセスする技術が開示されている。この技術を応用し、メールアドレスを登録するためのモバイルサイトのURLを情報として含んだ2次元バーコードをATMの画面に表示し、それを利用者のケータイに読み取らせ、ATM利用後に上記サイトにアクセスしてもらう。そして、上記サイト内でメールアドレスとその他本人確認情報を入力させることによってメールアドレスを登録する。ここで本人確認情報とは、口座番号やニックネーム、パスワード、生年月日などの、個人を特定可能な情報である。誰のメールアドレスなのかを特定するためには、本人確認情報の入力が必要である。
【0007】
3つ目として、空メールの送信による方法がある。ATMに付属のFeliCaリーダから3者間通信機能を用いてケータイに空メールを送信し、その空メールをユーザに送信してもらうことで送信元(すなわちユーザのケータイ)のメールアドレスを取得し、登録する。
【0008】
【特許文献1】特開2005−57501号公報
【発明の開示】
【発明が解決しようとする課題】
【0009】
1つ目の方法では、メールアドレスの入力操作に時間がかかってしまい、ATMの待ち行列に並んでいる他の顧客の満足度が下がるため、この方法は実用に適さない。
【0010】
2つ目の2次元バーコードを用いる方法は、モバイルサイト内でメールアドレスや本人確認情報を入力するのに手間がかかってしまう。ユーザに多くの入力操作を行わせると、途中で登録を諦めてしまうユーザが多くなるため、より簡易な操作で登録を行わせる方法が求められる。
【0011】
3つ目の方法では、本人を特定する情報が得られないため、誰のメールアドレスなのかが分からない。
【0012】
メールアドレスの登録と並んで、モバイル端末のユーザにとって不便な操作を強いられているものが、個人専用ページへのログインである。個人専用ページとは、契約状況や保有資産、購買履歴などの個人ごとに異なる情報を閲覧したり、金融商品の売買やサービスの契約等の指示を出したりするためのページであり、アクセスするには通常、IDとパスワードの入力が必要とされる。モバイル端末でログインのためのIDやパスワードを入力するのはユーザにとって負担であり、より簡便なログイン操作が求められている。しかし、ケータイによる個人専用ページへのログインを簡便に行うための公知の技術は現在のところ存在しない。
【0013】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、ユーザに複雑な操作を強いることなく、短時間で、個人情報に紐付けてユーザのメールアドレスを登録できるようにすること、または、簡単な操作でユーザ端末から個人専用ページへログインできるようにし、ユーザの負担を軽減する装置、システム。方法、プログラムを提供することにある。
【課題を解決するための手段】
【0014】
上記課題を解決するために、本発明は、ATM等の情報端末においてワンタイムパスワードを生成し、ユーザのカード(例えば、キャッシュカード)から読み取った口座番号と前記ワンタイムパスワードを認証サーバに送信し、認証サーバはそれらの情報を認証DBに登録する。そして、情報端末の非接触方式通信手段(例えば、FeliCaリーダ)にユーザ端末(例えば、ケータイ)がかざされたら、情報端末は前記ワンタイムパスワードを含む空メールまたはURLを3者間通信によりユーザ端末に送信する。ユーザ端末から空メールが送信されるか、URLにアクセスされたら、認証サーバはそれらを受信して空メールまたはURLに含まれるワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから探し出し、当該レコードの口座番号に紐付けて顧客DBにメールアドレスを登録する、あるいは当該レコードの口座番号に紐付く個人専用ページを前記ユーザ端末に送信する。
【発明の効果】
【0015】
本発明によれば、ユーザに複雑な操作を求めずに、短時間で、個人情報に紐付けてケータイのメールアドレスを登録することができる。また、簡単な操作でケータイから個人専用ページへログインすることができる。よって、ユーザの負担を軽減できる。
【発明を実施するための最良の形態】
【0016】
以下に、本発明の実施の形態について説明する。
【0017】
図1は、本発明の一実施形態に係るシステム構成図である。ATM110は、銀行や小売店の店舗に設置されているATMである。ケータイ端末130は、ATMのユーザが所有しているケータイ端末であり、ここではATMの近くにあるものとする。認証サーバ120は、銀行のセンタに設置されているサーバであり、メールアドレスの登録や個人専用ページへのログインに必要な認証処理などを行う。ケータイ端末は、FeliCa方式のICチップを内蔵する。
【0018】
ATM110は、FeliCaリーダ(非接触通信手段)内蔵型のATMであり、FeliCaの三者間通信によりケータイ端末130と通信を行うことができる。また、ATM110はネットワーク150(例えば、有線LAN)を介して認証サーバ120と通信を行う。ケータイ端末130は、無線ネットワーク160(例えば、携帯電話通信網)を介して認証サーバ120と通信を行う。
【0019】
なお、ATM110は必ずしもATMである必要はなく、例えば現金入出金機能のないキオスク端末でもよい。また、通信方式は、FeliCa方式に限られない。
【0020】
図2は、ATM110または認証サーバ120の機能を実現する情報処理装置200のハードウェア構成を例示する図である。情報処理装置200は、HDDに記録されたプログラムをメモリを利用して実行することにより各部の機能を実現するCPU(Central Processing Unit)210、メモリ220、HDD(Hard Disk Drive)230、FeliCa通信インタフェース240、有線通信インタフェース250、無線通信インタフェース260、入出力インタフェース270を備え、これらはバスにより接続される。
【0021】
以下では、ATM110と認証サーバ120がメールアドレスの登録に利用される場合の実施形態と、個人専用ページへのログインに利用される場合の実施形態とについて、順に述べていく。
【実施例1】
【0022】
まずはメールアドレスの登録に利用される場合の実施形態を説明する。
【0023】
図3は、認証サーバ120の詳細な機能構成の一例を示すブロック図である。認証サーバ120は、パスワード登録部310、メールアドレス確認部320、個人情報照合部330、パスワード抽出部340、メールアドレス登録部350、パスワード削除部360、URL記載メール送信部390を備える。これらの機能は、CPUがプログラムを実行することにより実現される。さらに、認証DB370、顧客DB380を備える。これらはHDDなどの記憶装置に格納される。
【0024】
パスワード登録部310、メールアドレス確認部320、個人情報照合部330、パスワード抽出部340、メールアドレス登録部350、パスワード削除部360、URL記載メール送信部390の処理内容は、後に述べる認証サーバ120のフローチャートの中で詳しく説明する。
【0025】
認証DB370は、ATM110から送られてきた口座番号とワンタイムパスワード等の情報を一時的に登録し、ケータイ端末130から送られてきた空メールに含まれるワンタイムパスワードを突き合わせることによって、空メールを送信してきたユーザの口座番号を特定するために用いる。認証DB370は、例えば図4に示すように、口座番号410、口座番号410に対応する顧客が最後にATMを利用した日時420、およびワンタイムパスワード430を格納する。このワンタイムパスワード430は、口座番号410と日時420の値に基づいてATM110が作成し認証サーバ120に送信したパスワードである。
【0026】
顧客DB380は、顧客の口座番号に紐付けて顧客の個人情報を管理するデータベースである。これは例えば図5に示すように、口座番号510、口座番号510に対応する顧客の生年月日520とメールアドレス530を格納する。
【0027】
なお、生年月日520は、個人を特定するための情報であって他人が容易に知りえない情報であれば他のものでもよく、例えば電話番号や郵便番号でも構わない。ただし、後で述べるようにこれらの個人情報は個人情報照合部330においてケータイ端末から入力された値との照合を行うために用いるため、ケータイ端末での入力のしやすさを鑑みて数字で表現されるものとする。また、口座番号の代わりに、個人ごとに割り当てられた個人IDであってもよい。
【0028】
図6は、ATM110の詳細な機能構成の一例を示すブロック図である。ATM110は、本人確認部610、パスワード生成部620、空メール送信部630を備える。これらの処理内容は、後に述べるATM110のフローチャートにおいて詳しく説明する。
【0029】
図7および図8は、ユーザによるATM利用時におけるATM110および認証サーバ120の動作の一例を示すフローチャートである。まず、ATM110は、ユーザから入金または出金の指示を受ける。通常この指示はATMに表示されたメニュー画面へのユーザのタッチ操作によって行われる(S100)。なお、各画面は記憶装置内に予め記憶されており、ATMは記憶装置から画面を読み出して、表示する。
【0030】
次に、ATM110はユーザが挿入したキャッシュカードから口座番号を読み取る(S101)。
【0031】
続いて、ATM110はユーザからの暗証番号(PIN)の入力を受け付ける(S102)。このPINが正しいかどうかの確認は、PINが入力されてすぐに行う場合もあれば、入出金の額などの必要事項が入力された後に認証サーバ120と交信する際に行われる場合もあるが、ここでは詳しく説明しない。いずれにしてもPINが正しければ入出金等の処理を継続し、正しくなければ処理を中止する。例えば、ユーザから入力されたPINの検証は、ユーザから入力されたPINがキャッシュカードから読み取られたPINに一致するか否かにより行う。一致すれば、PINが正しいと判定し、一致しなければ、PINが正しくないと判定する。
【0032】
S100における指示が出金の場合、ATM110はユーザからの出金金額の入力を受け付ける(S103)。
【0033】
S100における指示が入金の場合、ATM110は現金投入口を介してユーザから現金を受け取る(S104)。
【0034】
なお、入出金機能のないキオスク端末の場合、上記S100、S103、S104の処理は行われない。
【0035】
次に、ATM110は、S101で読み取った口座番号とATM110が認識している現在日時に基づいてパスワードを生成する(S105)。例えば、ATM110は、ATM110に内蔵された時計から読み取ることにより、またはATM110に接続されたセンタサーバへの問い合わせにより、現在日時を認識できる。
【0036】
パスワードの具体的な生成方法としては、例えば図9に示すように、最初のX桁で口座番号を表し、次の14桁で現在の西暦、月、日、時、分、秒を表した数を、所定のハッシュ関数に入力してハッシュ値を求める方法がある。ハッシュ関数は一方向性関数であるためハッシュ関数を使ってパスワードを生成すると、万一ハッシュ関数が第三者に漏れて、さらに後で述べるケータイ端末130から認証サーバ120へ送信するメールが傍受され、メール本文に書かれたパスワードがその第三者に知られても、口座番号が知られることはないというメリットがある。それに対して、共通鍵を使ってパスワードを生成すると、万一共通鍵とパスワードが第三者に漏れた場合、パスワードが復号されて口座番号が知られることになるが、共通鍵を使ってパスワードを生成してもよい。
【0037】
パスワードを現在日時と口座番号に基づいて生成する理由は、同じパスワードが2回以上生成される可能性を極力少なくするためである。異なるユーザが同時刻に別々のATMを利用することや、同一のユーザが異なる時刻に複数回ATMを利用することはあるが、同一のユーザが同時刻に別々のATMを利用することは不可能である。そのため、パスワードの元となる値(ハッシュ関数に入力する値)は同じものが2度使われることはない。その結果、他のユーザとパスワードがかぶる可能性は事実上ゼロに等しくなる。ハッシュ関数の性質上、異なる値のハッシュ値を求めた結果が同じになる可能性はゼロではないが、実務上はその可能性は無視してよい。
【0038】
図7に戻って説明を続ける。ATM110は、パスワード、パスワードを生成する元となった口座番号と日時、および入出金に関する指示を、認証サーバ120に対して送信する。なお、ATM110が入出金機能のないキオスク端末の場合は、入出金に関する指示は送信しない(S106)。
【0039】
上記のように、入出金指示と同時にパスワードや日時を認証サーバ120に送信することによって、ATM110と認証サーバ120との間のメッセージ授受の回数が、入出金処理のみを行う場合と比較して変わらずに済む。したがって、ATMユーザから見た処理パフォーマンスを落とさずに、現状世の中に出回っているATMに本発明の認証機能を追加することができる。
【0040】
認証サーバ120は、ATM110からのパスワード、パスワードを生成する元となった口座番号と日時、および入出金に関する指示を受信する(S200)。
【0041】
認証サーバ120は、上記で受信したパスワード、口座番号、日時を認証DB370に登録する。このとき、同じ口座番号のレコードが既に存在していれば上書きする。それにより、1つの口座番号に関して許される(認証をパスできる)パスワードが常に1つ以下に保たれ、第三者による成りすましの成功確率がより低くなる(S201)。
【0042】
認証サーバ120は、入出金指示の内容に基づき、口座残高の変更を行う(S202)。
【0043】
パスワードを登録する処理(S201)と口座残高の変更処理(S202)はそれぞれ独立に行う。これは、何らかの障害によりパスワードの登録がスムーズに行えなかった場合でも、本来の銀行業務である入出金処理を滞りなく行い、速やかにATMの画面に処理結果を表示することで、ATMユーザの満足度を低下させないことを目的としている。
【0044】
認証サーバ120は、顧客DB380を参照し、S200で受信した口座番号に対応する顧客のメールアドレスが既に登録されているか否かを確認する。そして、その結果とS202における残高変更処理の結果をATM110に送信する(S203)。
【0045】
ATM110は、メールアドレスが登録されているか否かの確認結果と残高変更処理の結果を受信する(S107)。
【0046】
ATM110は、画面に広告を表示する(S108)。なお、広告の表示タイミングは必ずしもS107の後である必要はなく、金額の入力受付S103または現金の受け取りS104の後から、S105、S106、S107の処理と並行しながら広告を表示していてもよい。また、必ずしも次に述べるS109やS110の前である必要もなく、S109やS110の画面表示と同時に広告表示を開始してもよい。
【0047】
次にATM110は、メールアドレスが未登録であった場合、明細書を印刷するか否かの選択肢と、メールアドレス登録方法の案内を表示する。画面遷移が増えてユーザが煩わしさを感じる事態を避けるため、これら2つの情報は1画面に表示する。なお、上で述べたように、ここで同時に広告を表示してもよい(S109)。
【0048】
図10に、ATMの画面イメージの一例を示す。S109の処理における画面のイメージはG109である。同様に、これから説明するS110、S111、S112の処理における画面のイメージはそれぞれG110、G111、G112である。
【0049】
図7に戻って説明を続ける。S108の処理の後、メールアドレスが登録済みであった場合、ATM110はメール送信を行うか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレス変更方法の案内を表示する。これらの情報は1画面に表示し、さらに広告を表示してもよい。(S110)。
【0050】
S109またはS110においてATMに付属したFeliCaリーダにケータイ端末130がかざされたら、ATMはケータイ端末からのレスポンスの受信によりケータイ端末130がかざされたことを検知してFeliCaの3者間通信によりケータイ端末130のメーラー(メール機能を実現するアプリケーションプログラム)を起動して空メールを送信する。このとき、空メールの送信先アドレスには所定の空メール受付用のアドレスを設定し、空メールの本文にはS105で作成したパスワードを記載する。また、ATM110の画面からはメールの送信可否を問う選択肢を削除する。これは、ユーザにメールアドレスの登録または変更の意思があり、旧メールアドレス(未登録の場合も含めて)にメールを送る意味がないためである。(S111)。
【0051】
図11に、S111でケータイ端末130に送信する空メールの内容の一例を示す。3者間通信機能により、ケータイ端末130のメーラーを起動すると同時に宛先や本文に図11に示すような文字列を記載させることが可能である。ユーザはケータイ端末の「メール送信」ボタンを押すだけで空メールを銀行の空メール受付用アドレス(ここでは「bank@jp」)に送信することができる。
【0052】
S109またはS111の後に明細書の印刷可否が選択されたら、またはS110の後に明細書の印刷可否とメールの送信可否が選択されたら、ATM110は取引完了画面を表示する(S112)。
【0053】
なお、G110の画面でメールを送信する旨が選択された場合、ATM110からメールサーバ等に対してメール送信指示が出され、S108で表示した広告の商品やサービスに関する詳細な情報やWebサイトへのリンクを本文に記載したメールが、登録済みのメールアドレスに対して送信される。
【0054】
図7および図8に示したフローチャートにおいて、本人確認部610はS101およびS102の処理を、パスワード生成部620はS105およびS106の処理を、空メール送信部630はS107、S108、S109、S110、S111、S112の処理を、パスワード登録部310はS200とS201の処理を、メールアドレス確認部320はS203の処理を行う。
【0055】
次に、別の実施形態として、認証サーバ120がメールアドレスの登録済/未登録の確認を行わない場合のフローチャートを図12および図13に示す。また、ATM画面のイメージを図14に示す。以下ではそれらが図7、図8、図10と異なる部分について述べる。
【0056】
まず、図7におけるメールアドレス登録済/未登録の確認処理(S203)は図12では存在せず、認証サーバ120はS202の処理の後に直ちにATM110に残高変更処理の結果を送信し(S204)、ATM110はこれを受信する(S113)。
【0057】
メールアドレスが登録済みか未登録かATM110は分からないため、S109とS110のように分岐はせず、ATM110はメール送信を行うか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレス登録/変更方法の案内を表示する(S114)。
【0058】
S114におけるATM110の画面イメージが図14におけるG114である。以下同様に、S115、S116、S118に対応するATM110の画面イメージはG115、G116、G118である。
【0059】
S114の後、ATM110に付属のFeliCaリーダにケータイ端末がかざされたら、3者間通信によりケータイ端末のメーラーを起動して空メールを送信する。空メールの内容はS111の場合と同様である。このとき、画面からはメールの送信可否を問う選択肢を削除する。これは、ユーザにメールアドレスの登録または変更の意思があり、旧メールアドレス(未登録の場合も含めて)にメールを送る意味がないためである(S115)。
【0060】
S115の後にユーザによって明細書の印刷可否が選択されたら、ATM110は取引完了の画面を表示する(S116)。
【0061】
S114の後にユーザによって明細書の印刷可否およびメール送信可否が選択されたら、ATM110はメールの送信可否について「送信する」が選択されたか「送信しない」が選択されたかを識別する(S117)。
【0062】
「送信しない」が選択された場合、ATM110は取引完了の画面を表示する(S116)。
【0063】
「送信する」が選択された場合、ATM110は取引完了の旨とともにメールがユーザに届かない場合の案内を表示する。これは、ユーザのメールアドレスが未登録でありながらメールを「送信する」旨がユーザによって選択される可能性があり、その場合にはユーザにメールが届かないためである。
【0064】
図15は、ユーザによってパスワード付き空メールが送信された際のケータイ端末130および認証サーバ120の動作の一例を示すフローチャートである。まず、ケータイ端末130は認証サーバ120に空メールを送信する(S301)。
【0065】
認証サーバ120はケータイ端末130から送信された空メールを受信する(S401)。
【0066】
次に、認証サーバ120は受信した空メールからパスワード部分を抽出する。このパスワード部分とは、図11の例で言えば本文に記載された「bmsv8pm42aaat」の文字列のことである(S402)。
【0067】
次に、認証サーバ120はメールから抽出したパスワードをキーとして認証DB370のワンタイムパスワード430の項目を検索する(S403)。
【0068】
認証DB370に対する検索(S403)の結果、レコードが見つからなかった場合、認証サーバ120は認証失敗と判断し、認証失敗の旨のメールをケータイ端末130に送信する。その際の送信先メールアドレスは、空メールの送信元アドレスである(S405)。
【0069】
認証DB370に対する検索(S403)の結果、レコードが見つかった場合、そのレコードの口座番号410の値は、空メールの送信元ユーザの口座番号であるはずである。そこで、認証サーバ120は認証成功と判断し、見つかったレコードの口座番号410の値をキーとして顧客DB380の口座番号510の項目を検索し、ヒットしたレコードのメールアドレス530の項目に、空メールの送信元のメールアドレスを登録する(S406)。
【0070】
さらに認証サーバ120は、認証成功の旨のメールをケータイ端末130に送信する。その際の送信先メールアドレスは、空メールの送信元アドレスである(S407)。
【0071】
そして、認証サーバ120は認証DB370から、S406でヒットしたレコードを削除する。これにより、その後悪意のある第三者が自らパスワード付き空メールを作成して他者に成りすまし、他者の顧客DBレコードに自分のメールアドレスを登録させる行為を防止する(S408)。
【0072】
また、別の実施形態として、空メールから抽出したパスワードをキーとして認証DBを検索(S403)した結果、レコードがヒットした場合に、すぐに認証成功とは判断せず、より万全を期するため個人情報の照合を行い、照合が一致したら認証成功と判断することとしてもよい。その場合、まず認証サーバ120はケータイ端末130にメールを送信する(S409)。
【0073】
このメールの本文には、個人情報の入力を行うためのサイトに誘導するURL(サイトの格納場所)を記載しておく。そのURLには、S402でメールから抽出したパスワードを埋め込んでおく。それにより、当該URLにユーザがアクセスした際に、どのユーザからのアクセスであるかを認証サーバが認識することができる。
【0074】
そして、認証サーバ120は前記URLに対するケータイ端末からのアクセスを受け、個人情報の照合を行う(S410)。この部分の詳細は後述する。
【0075】
個人情報の照合結果が一致の場合は認証成功と判断し、前述したS406の処理に進む。
【0076】
個人情報の照合結果が不一致の場合は認証失敗と判断し、認証サーバ120はケータイ端末130に認証失敗の旨のメールを送信する(S411)。
【0077】
個人情報の照合処理について、図16のフローチャートを用いて説明する。まず、認証サーバ120は、ケータイ端末130がアクセスしたURLに埋め込まれたパスワードをキーにして認証DBを検索することにより、アクセスしたユーザの口座番号を特定する(S412)。
【0078】
なお、口座番号の特定方法は、必ずしもパスワードをキーにした認証DBの検索によらなくてもよく、例えばパスワードが口座番号を含む文字列を共通鍵で暗号化したものであるならば、バスワードを共通鍵で復号することにより口座番号を特定してもよい。
【0079】
次に、認証サーバ120は個人情報の入力画面をケータイ端末130へ送信してケータイ端末130に表示させる。ここでの個人情報とは、例えば生年月日である。このときの入力画面は、例えば図17のようになる。S412において口座番号が特定されているため、ユーザは口座番号を入力する必要はなく、個人情報だけを入力すればよい(S413)。
【0080】
ケータイ端末130からの個人情報の入力(S304)を受けて、認証サーバ120は顧客DBに登録されている個人情報との照合を行う。すなわち、S412で特定された口座番号をキーにして顧客DB380を検索し、ヒットしたレコードの生年月日520とケータイ端末130から入力された生年月日とが一致するかを判定する(S414)。
【0081】
一致した場合は認証成功と判断し(S416)、不一致の場合は認証失敗と判断する(S417)。
【0082】
ここまでで述べた実施形態は、認証サーバ120がATM110から送信された口座番号やパスワードを登録する処理(例えばS201)が、認証サーバ120がケータイ端末130から空メールを受信する処理(S401)よりも前に行われていることが前提となっている。しかし、処理負荷増大などの理由により認証サーバのパフォーマンスが落ち、パスワード登録処理(S201)が完了するのに時間がかかってしまい、空メールの受信(S401)が先に行われる可能性も考えられる。そのようなことが起こった場合、これまでに述べた実施形態では、空メールから抽出したパスワードをキーにして認証DBを検索(S403)してもヒットせず、認証が失敗(S405)してしまう。そこで、空メールの受信処理が先に来ても認証が成功するような実施形態について、これまでに述べた実施形態との違いを次に述べる。
【0083】
まず、図15におけるメールアドレス登録部350がどのように変わるかを述べる。図15のフローチャートで示したメールアドレス登録部350では、空メールから抽出したパスワードをキーにして認証DBを検索(S403)してヒットしなかった場合、認証失敗と判断して認証失敗の旨のメールをケータイ端末130に送信(S405)していたが、認証失敗と判断せず、認証DBに日時、パスワード、およびメールアドレスを登録する。ここでの日時は認証サーバが認識する現在日時であり、メールアドレスは空メールの送信元アドレスである。認証DBにメールアドレスを登録するため、認証DBは図19に示すようにメールアドレス1840を格納することができるものを用いる。
【0084】
次に、図7のフローチャートにおけるパスワード登録部310がどのように変わるかを、図18のフローチャートを用いて述べる。
【0085】
認証サーバ120は、ATM110から口座番号、日時、パスワード、および入出金指示を受信(S500)した後、受信したパスワードをキーにして認証DBのワンタイムパスワード430の項目を検索する(S501)。
【0086】
検索でヒットしなかった場合、図7におけるパスワードの登録(S201)と同じ処理を行う(S502)。
【0087】
検索でヒットした場合、すなわち先にユーザからの空メールが到着しており、認証DBにパスワードとメールアドレスが登録されている場合、認証サーバ120は認証成功と判断し、ATM110から受信した口座番号をキーとして顧客DB380の口座番号510の項目を検索し、ヒットしたレコードのメールアドレス530の項目に、認証DB370に登録されていたメールアドレスを登録する(S503)。
【0088】
さらに認証サーバ120は、認証成功の旨のメールをケータイ端末130に送信する。その際の送信先メールアドレスは、認証DB370に登録されていたメールアドレスである(S504)。
【0089】
そして、認証が成功したらS501でヒットしたレコードは不要になるため、認証サーバ120は認証DB370から当該レコードを削除する。(S505)。
【0090】
また、別の実施形態として、ATM110から受信したパスワードをキーとして認証DBを検索(S501)した結果、レコードがヒットした場合に、すぐに認証成功とは判断せず、より万全を期するため個人情報の照合を行い、照合が一致したら認証成功と判断することとしてもよい。その場合、まず認証サーバ120はヒットしたレコードに記録されているメールアドレスに対してメールを送信し(S506)、個人情報の照合を行う(S507)。送信するメールの内容、および個人情報の照合方法は、それぞれ前述の図15におけるメール送信処理(S409)と個人情報照合処理(S410)と同様である。個人情報の照合結果が一致であれば顧客DBにメールアドレスを登録(S503)し、不一致であれば認証失敗と判断して認証失敗の旨のメールをケータイ端末130へ送信する(S508)。
【0091】
ここで、セキュリティが一部破られた場合の影響について述べる。ATM110と認証サーバ120との間の伝送路は通常は強固なセキュリティで守られているので、ここではユーザが認証サーバに送った空メールが傍受された場合と、ATMでパスワードを生成する際のハッシュ関数が漏れた場合について述べる。
【0092】
メールが第三者によって傍受された場合の影響は以下である。その第三者が同じ内容のメールを自分のケータイ端末から送って、顧客DBにおける他者のレコードに自分のメールアドレスを登録しようと企てたとする。その場合、正当なユーザのメールが第三者のメールよりも先に認証サーバ120に到着しているはずであるので、正当なユーザの認証は成功し、その後第三者がメールを送ったときには既に認証DB370からレコードは削除されているため、第三者の認証は失敗する。したがって、メールが傍受されることによって実質的な被害は発生しない。
【0093】
ハッシュ関数が第三者に漏れた場合の影響は以下である。その第三者が、他者の口座番号を入手し、かつその口座番号のユーザのATM最終利用日時を知ることができれば、それらの情報からハッシュ関数を使ってパスワードを生成し、メールを認証サーバ120に送信し、顧客DBにおける他者のレコードに自分のメールアドレスを登録することができる。しかし、特定の他者がATMを利用した日時を正確に知ることは通常不可能である。しかも、パスワードは一定期間しか有効でないため、本ケースで第三者が成りすましに成功する可能性は低い。
【0094】
メールが傍受され、かつハッシュ関数も第三者に漏れたとする。その場合でも、前に述べたように、メール本文のパスワードを復号することはできないので、口座番号が第三者に知られることはなく、実質的な被害は発生しない。
【0095】
以上で、ATM110と認証サーバ120がメールアドレスの登録に利用される場合の実施形態について述べた。
【実施例2】
【0096】
次に、ATM110と認証サーバ120が個人専用ページへのログインに利用される場合の実施形態について述べる。
【0097】
図20は、認証サーバ120の詳細な機能構成の一例を示すブロック図である。メールアドレスの登録に認証サーバが利用される場合の実施形態(図3)との違いは、メールアドレス確認部320がないことと、メールアドレス登録部350がログイン処理部350Aになっていること、およびURL記載メール送信部390がないことである。
【0098】
図21は、ATM110の詳細な機能構成の一例を示すブロック図である。メールアドレスの登録にATMが利用される場合の実施形態(図6)との違いは、空メール送信部630がURL送信部630Aになっていることである。
【0099】
図22は、ユーザによるATM利用時におけるATM110および認証サーバ120の動作の一例を示すフローチャートである。以下、図7および図8との相違点について述べる。
【0100】
まず、ATM110の本人確認部610、パスワード生成部620の動作は図7と同様である。また、認証サーバ120のパスワード登録部310の動作も図7と同様である。
【0101】
図7ではメールアドレスが登録済みか否かの確認(S203)を認証サーバ120にて行っていたが、本実施例ではメールアドレスの登録が目的ではないのでこの処理はない。残高の変更(S202A)の後、直ちにATM110に対して処理結果を送信する。
【0102】
ATM110は、処理結果を受信し(S601)、画面に広告を表示する(S602)。そして、画面に明細書を印刷するか否かの選択肢と、ケータイ端末130でFeliCaリーダからURLを受信する方法の案内を表示する。画面遷移が増えてユーザが煩わしさを感じる事態を避けるため、これら2つの情報は1画面に表示する。また、同時に広告を表示してもよい(S603)。
【0103】
図23に、ATM110の画面イメージの一例を示す。S603の処理における画面のイメージはG603である。同様に、これから説明するS604、S605の処理における画面のイメージはそれぞれG604、G605である。
【0104】
明細書の印刷可否の選択肢とURL受信方法の案内を表示(S603)した後、ATMに付属したFeliCaリーダにケータイ端末130がかざされたら、ATMはそれを検知してFeliCaの3者間通信によりケータイ端末130のWebブラウザを起動してURLを送信する。このURLは、ユーザが個人専用ページにログインするためのURLである。また、このURLには、パスワード生成部620においてATM110が生成したパスワードを埋め込んでおく(S604)。
【0105】
S603またはS604の処理の後、ユーザによって明細書の印刷可否が選択されたら、ATM110は取引終了画面を表示する(S605)。
【0106】
図24は、ATM110からケータイ端末130に送信されたURLに基づいてユーザが認証サーバ120にアクセスした際のケータイ端末130および認証サーバ120の動作の一例を示すフローチャートである。
【0107】
まず、ケータイ端末130はパスワードが埋め込まれたURLに基づいて認証サーバ120にアクセスする(S701)。
【0108】
認証サーバ120はケータイ端末130からのアクセスを受け付け(S801)、アクセスしてきたURLからパスワード部分を抽出する(S802)。
【0109】
次に、認証サーバ120はURLから抽出したパスワードをキーとして認証DB370のワンタイムパスワード430の項目を検索する(S803)。
【0110】
認証DB370に対する検索(S803)の結果、レコードが見つからなかった場合、認証サーバ120は認証失敗と判断し、認証失敗の旨を記載したページデータをケータイ端末130に送信する(S804)。
【0111】
認証DB370に対する検索(S803)の結果、レコードが見つかった場合、そのレコードの口座番号410の値は、パスワード付きURLに基づき認証サーバ120にアクセスしたユーザの口座番号と同一のはずである。そこで、認証サーバ120は認証成功と判断し、当該口座番号に紐付く個人専用ページのデータをケータイ端末130に送信する(S805)。
【0112】
そして、認証サーバ120は認証DB370から、S803でヒットしたレコードを削除する(S806)。
【0113】
また、別の実施形態として、URLから抽出したパスワードをキーとして認証DB370を検索(S803)した結果、レコードがヒットした場合に、すぐに認証成功とは判断せず、より万全を期するため個人情報(S807)の照合を行い、照合が一致したら認証成功と判断することとしてもよい。その場合の個人情報照合処理は、図16のフローチャートを用いて既に説明した個人情報照合部330の処理と同様である。個人情報の照合結果が不一致の場合は認証失敗と判断し、認証サーバ120はケータイ端末130に認証失敗の旨を記載したページデータをケータイ端末130に送信する(S808)。その後、パスワードの削除処理を行う(S806)。
【0114】
以上の説明は、認証サーバ120によるパスワードの登録処理(S201)が、ケータイ端末130から認証サーバ120へのアクセス(S701)よりも前に行われることが前提になっている。しかし、処理負荷増大などの理由により認証サーバのパフォーマンスが落ち、パスワード登録処理(S201)が完了するのに時間がかかってしまい、ケータイ端末130からのアクセス(S701)が先に行われる可能性も考えられる。そのようなことが起こった場合、これまでに述べた実施形態では、URLから抽出したパスワードをキーにして認証DBを検索(S803)してもヒットせず、認証が失敗(S804)してしまう。そこで、そもそもパスワード登録処理(S201)を行わず、ケータイ端末130からのアクセスを受けたときにURLから抽出したパスワードを復号して口座番号と日時を復元することによって、認証サーバのパフォーマンスに関係なく確実に認証を行うことを可能にする。この実施形態について次に述べる。
【0115】
図25は、ユーザによるATM利用時におけるATM110および認証サーバ120の動作の一例を示すフローチャートである。以下、図22との相違点について述べる。
【0116】
まず、パスワード生成部620において、ATM110は口座番号と日時に基づいてパスワードを生成する(S900)。
【0117】
このとき、ハッシュ関数を使うのではなく、ATM110が保管する共通鍵を使ってパスワードを生成する。また、この共通鍵は認証サーバ120でも保管しておく。
【0118】
ATM110は生成したパスワード、口座番号および日時を認証サーバ120に送信することはしない。また、認証サーバ120ではパスワード登録処理は行わない。
【0119】
URL送信部630Aにおける処理については図22の説明と同様である。
【0120】
続いて、図26のフローチャートを用いて、ATM110からケータイ端末130に送信されたURLに基づいてユーザが認証サーバ120にアクセスした際のケータイ端末130および認証サーバ120の動作の一例を説明する。なお、図24における説明との相違点についてのみ述べる。
【0121】
まず、パスワード抽出部340は図24の説明と同様である。
【0122】
URLからパスワードを抽出(S1002)した後、認証サーバ120は共通鍵を用いてパスワードを復号し、パスワードの元となった日時と口座番号とを抽出する(S1003)。
【0123】
次に、認証サーバ120は、抽出した日時が現在時刻から見て一定時間(仮にaとする)以上前でないか、一定時間(仮にbとする)以上後でないかを確認する。このaとbは同一でなくてよい。正当なユーザからのアクセスであれば、ユーザはATMの利用直後にアクセスしたのだから、抽出した日時は現在時刻よりも少しだけ前の時刻であるはずである。ただし、ATMと認証サーバの内部時計がずれている可能性もあるため、抽出した日時が現在時刻よりも少しだけ後の時刻であってもよいこととする。第三者からの不正アクセスを防止するため、抽出した日時が現在時刻よりも一定以上離れていたら、認証失敗と判定することとする(S1004)。
【0124】
抽出した日時が現在時刻から見て一定以上前か、または一定以上後であれば、認証サーバ120は認証失敗と判定し、認証失敗の旨を記載したページデータをケータイ端末130に送信する(S1005)。
【0125】
抽出した日時が現在時刻から見て一定以上前でなく、または一定以上後でなければ、認証サーバ120はS1003で抽出した口座番号をキーとして顧客DBを検索する(S1006)。
【0126】
ここでヒットしなければ、認証サーバ120は認証失敗と判定し、認証失敗の旨を記載したページデータをケータイ端末130に送信する(S1005)。
【0127】
ヒットすれば、認証サーバ120は個人情報照合処理を行う。この処理内容は、図16のフローチャートを用いて既に説明した個人情報照合部330の処理と同様である。
【0128】
なお、これまでに説明した他の実施例では個人情報の照合を行わずに認証成功と判定する例もあったが、パスワードを復号することにより日時と口座番号を復元する本実施例では、個人情報の照合を行うものとする。これは、本実施例が他の実施例に比べてセキュリティの面で脆弱であるためである。すなわち、他の実施例ではハッシュ関数が外部に漏れても、第三者が他のユーザに成りすますためには他のユーザの口座番号に加えてATM利用日時を正確に知る必要があるが、本実施例では、第三者が共通鍵を入手すると他のユーザの口座番号を知るだけで成りすましが成功する恐れがある。そのため、より万全を期するため個人情報の照合を行う。
【0129】
個人情報の照合の結果、一致であれば個人専用ページのデータをケータイ端末130に送信し(S1006)、不一致であれば認証失敗の旨を記載したページのデータをケータイ端末130に送信する(S1007)。
【0130】
なお、図24のフローチャートで説明したパスワードの削除処理(S806)は、本実施例ではそもそも認証DBを用いないので不要である。
【0131】
最後に、認証DBに登録されてから一定期間が過ぎたレコードを削除する処理について説明する。これは、パスワードを一定期間のみ有効とすることにより、認証DBのデータ容量を削減するとともに、第三者による不正アクセスの可能性を削減することを目的とする。通常、正当なユーザはATMの利用直後にケータイ端末から空メールもしくはパスワード埋め込み型URLによって認証サーバにアクセスすることが想定されるので、認証DBにおいて登録から一定期間が過ぎたレコードを削除することによって正当なユーザの利便性が損なわれることはない。
【0132】
図27は、認証DBからのレコード削除に関する認証サーバ120の動作の一例を示すフローチャートである。まず、認証サーバ120は、認証DB370から、日時420が一定期日よりも前のレコードを全て抽出する(S1101)。
【0133】
次に、認証サーバ120は抽出したレコードを削除する(S1102)。
【産業上の利用可能性】
【0134】
本発明は、ATMと携帯電話とを利用した携帯電話のメールアドレスの登録に利用可能である。
【図面の簡単な説明】
【0135】
【図1】システム全体のシステム構成図
【図2】ATMまたは認証サーバの機能を実現する情報処理装置のハードウェア構成図
【図3】認証サーバの機能構成図
【図4】認証DBの格納する1レコードのデータ構成図
【図5】顧客DBの格納するレコードのデータ構成図
【図6】ATMの機能構成図
【図7】ATM利用時のATMおよび認証サーバの処理のフローチャート
【図8】ATM利用時のATMの処理のフローチャート
【図9】パスワード生成方法を示す概念図
【図10】ATMの画面イメージ
【図11】ケータイ端末の空メールの画面イメージ
【図12】メールアドレスの登録済/未登録の確認を行わない場合のATM利用時のATMおよび認証サーバの処理のフローチャート
【図13】メールアドレスの登録済/未登録の確認を行わない場合のATM利用時のATMの処理のフローチャート
【図14】ATMの画面イメージ
【図15】パスワード付き空メール送信時のケータイ端末および認証サーバの処理のフローチャート
【図16】個人情報の照合時の認証サーバおよびケータイ端末の処理のフローチャート
【図17】ケータイ端末の個人情報の入力画面イメージ
【図18】認証サーバおよびケータイ端末の処理のフローチャート
【図19】認証DBの1レコードのデータ構成図
【図20】認証サーバの機能構成図
【図21】ATMの機能構成図
【図22】ATM利用時のATMおよび認証サーバの処理のフローチャート
【図23】ATMの画面イメージ
【図24】認証サーバアクセス時のケータイ端末および認証サーバの処理のフローチャート
【図25】ATM利用時のATMおよび認証サーバの処理のフローチャート
【図26】ATM利用時のケータイ端末および認証サーバの処理のフローチャート
【図27】レコード削除時の認証サーバの処理のフローチャート
【符号の説明】
【0136】
110‥ATM、120‥認証サーバ、130‥ケータイ端末、140‥三者間通信網、150‥ネットワーク、160‥無線ネットワーク。
【特許請求の範囲】
【請求項1】
ユーザのメールアドレスを登録するための情報端末であって、
表示手段と、
ユーザ端末と非接触方式で通信可能な通信手段と、
ユーザによって挿入されたカードからユーザの口座番号および暗証番号を読み取る読取手段と、
ユーザによる暗証番号の入力を受け付ける入力手段と、
ユーザによって入力された暗証番号を前記カードから読み取られた暗証番号と照合する本人確認手段と、
前記口座番号と現在日時に基づいてワンタイムパスワードを生成するパスワード生成手段と、
前記口座番号と前記現在日時、および前記ワンタイムパスワードを認証サーバに送信するパスワード送信手段と、
メールを送信するか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレスの登録方法または変更方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードをメール本文に記載したメールを前記ユーザ端末に送信するメール送信手段とを備えることを特徴とする情報端末。
【請求項2】
請求項1に記載の情報端末であって、
前記パスワード送信手段は、前記口座番号と前記現在日時、および前記ワンタイムパスワードに加えて、入出金指示を前記認証サーバに送信することを特徴とする情報端末。
【請求項3】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、前記表示手段に前記案内を表示した後に前記通信手段が前記ユーザ端末を検知しないままユーザによって前記メールを送信するか否かの選択肢のいずれかまたは前記明細書を印刷するか否かの選択肢のいずれかが選択されたら、取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項4】
請求項3に記載の情報端末であって、
前記メール送信手段は、前記メールを送信するか否かの選択肢において送信する旨が選択されていたら、前記取引完了画面とともにメールが届かない場合の案内を前記表示手段に表示することを特徴とする情報端末。
【請求項5】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、前記表示手段に前記案内を表示した後に前記通信手段によって前記ユーザ端末を検知した場合に、前記メールを送信するか否かの選択肢を前記表示手段の画面から削除することを特徴とする情報端末。
【請求項6】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、ユーザのメールアドレスの登録有無を前記認証サーバから受信し、前記ユーザのメールアドレスが未登録であれば、明細書を印刷するか否かの選択肢およびメールアドレスの登録方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードをメール本文に記載したメールを前記ユーザ端末に送信し、前記明細書を印刷するか否かの選択肢のいずれかが選択されたら取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項7】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、ユーザのメールアドレスの登録有無を前記認証サーバから受信し、前記ユーザのメールアドレスが登録済みであれば、メールを送信するか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレスの変更方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードをメール本文に記載したメールを前記ユーザ端末に送信し、その後に前記明細書を印刷するか否かの選択肢のいずれか選択されたら取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項8】
請求項1または2に記載の情報端末であって、
前記パスワード生成手段は、前記口座番号と前記現在日時を含む数字のハッシュ値を計算することにより前記ワンタイムパスワードを算出することを特徴とする情報端末。
【請求項9】
ユーザのメールアドレスを登録するための認証サーバであって、 情報端末から、情報端末によってユーザの口座番号と日時から生成されたワンタイムパスワード、ユーザのカードから読み取られた口座番号、および日時を受信する受信手段と、
受信した前記ワンタイムパスワード、前記口座番号、および前記日時を格納する認証DBと、前記口座番号、当該口座番号に対応するユーザの生年月日または電話番号または郵便番号、および前記ユーザのメールアドレスを格納する顧客DBと、を有する記憶装置と、
前記情報端末から前記口座番号、前記日時、および前記ワンタイムパスワードを受信し、前記認証DBに追加するパスワード登録手段と、
ユーザ端末からのメールを受信し、前記メールから前記ワンタイムパスワードを抽出するパスワード抽出手段と、
抽出した前記ワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つかったらそのレコードの口座番号と同一の口座番号を持つ前記顧客DBのレコードの、メールアドレスの項目に前記メールの受信元アドレスを記録するメールアドレス登録手段とを備えることを特徴とする認証サーバ。
【請求項10】
請求項9に記載の認証サーバであって、
前記メールアドレス登録手段は、前記顧客DBのレコードのメールアドレスの項目に前記メールの受信元アドレスを記録したら、さらに前記メールから抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから削除することを特徴とする認証サーバ。
【請求項11】
請求項9に記載の認証サーバであって、
さらに、前記情報端末から受信した口座番号をキーにして前記顧客DBを参照し、当該口座番号のユーザのメールアドレスが既に登録済みか否かを確認し、その結果を前記情報端末に送信するメールアドレス確認手段を備えることを特徴とする認証サーバ。
【請求項12】
請求項9に記載の認証サーバであって、
前記パスワード登録手段は、前記情報端末から受信した前記口座番号と同一の口座番号を持つレコードが既に前記認証DBに登録されていたら、当該レコードを上書きして前記口座番号、前記日時、および前記パスワードを登録することを特徴とする認証サーバ。
【請求項13】
請求項9に記載の認証サーバであって、
前記メールアドレス登録手段は、前記顧客DBのレコードのメールアドレスの項目に前記メールの受信元アドレスを記録したら、さらに前記メールを送信してきたユーザ端末に対して認証が成功した旨のメールを送信することを特徴とする認証サーバ。
【請求項14】
請求項9に記載の認証サーバであって、
さらに、前記メールから抽出したワンタイムパスワードをURLに埋め込み、前記URLを本文に記載したメールを前記メールの送信元であるユーザ端末に送信するメール送信手段を備えることを特徴とする認証サーバ。
【請求項15】
請求項14に記載の認証サーバであって、
さらに、前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致していれば認証成功と判定し、不一致であれば認証失敗と判定する個人情報照合手段を備えることを特徴とする認証サーバ。
【請求項16】
請求項9に記載の認証サーバであって、
前記認証DBは、さらにメールアドレスを格納し、
前記メールアドレス登録手段は、前記メールから抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つからなかったら前記認証DBに前記ワンタイムパスワードと前記メールの送信元アドレスと現在日時を登録し、
前記パスワード登録手段は、前記情報端末から前記口座番号、前記日時、および前記ワンタイムパスワードを受信したら、前記ワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つかったらそのレコードのメールアドレスを、前記情報端末から受信した口座番号と同一の口座番号を持つ前記顧客DBのレコードのメールアドレスの項目に記録することを特徴とする認証サーバ。
【請求項17】
請求項16に記載の認証サーバであって、さらに、
前記情報端末から受信したワンタイムパスワードをURLに埋め込み、前記ワンタイムパスワードと同一のワンタイムパスワードを持つ前記認証DBのレコードにおけるメールアドレスに対して、前記URLを本文に記載したメールを送信するメール送信手段と、
前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致していれば認証成功と判定し、不一致であれば認証失敗と判定する個人情報照合手段とを備えることを特徴とする認証サーバ。
【請求項18】
ユーザ端末から個人専用ページへログインを支援するための情報端末であって、
表示手段と、
ユーザ端末と非接触方式で通信可能な通信手段と、
ユーザによって挿入されたカードからユーザの口座番号および暗証番号を読み取る読取手段と、
ユーザによる暗証番号の入力を受け付ける入力手段と、
ユーザによって入力された暗証番号を前記カードから読み取られた暗証番号と照合する本人確認手段と、
前記口座番号と現在日時に基づいてワンタイムパスワードを生成するパスワード生成手段と、
前記口座番号と前記現在日時、および前記ワンタイムパスワードを認証サーバに送信するパスワード送信手段と、
明細書を印刷するか否かの選択肢とURLの受信方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードを埋め込んだURLをケータイに送信するURL送信手段を備えることを特徴とする情報端末。
【請求項19】
請求項18に記載の情報端末であって、
前記URL送信手段は、前記明細書を印刷するか否かの選択肢と前記URLの受信方法の案内を前記表示手段の画面に表示し、その後に前記通信手段が前記ユーザ端末を検知しないままユーザによって前記明細書を印刷するか否かの選択肢のいずれかが選択されたら、取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項20】
請求項18に記載の情報端末であって、
前記パスワード生成手段は、前記口座番号と前記現在日時を含む数字のハッシュ値を計算することにより前記ワンタイムパスワードを算出することを特徴とする情報端末。
【請求項21】
ユーザ端末から個人専用ページへログインを支援するための認証サーバであって、
情報端末から、情報端末によってユーザの口座番号と日時から生成されたワンタイムパスワード、ユーザのカードから読み取られた口座番号、および日時を受信する受信手段と、
受信した前記ワンタイムパスワード、前記口座番号、および前記日時を格納する認証DBと、前記口座番号、当該口座番号に対応するユーザの生年月日または電話番号または郵便番号、および前記ユーザのメールアドレスを格納する顧客DBと、を有する記憶装置と、
前記情報端末から前記口座番号、前記日時、および前記ワンタイムパスワードを受信し、前記認証DBに追加するパスワード登録手段と、
ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受け付け、前記URLからワンタイムパスワードを抽出するパスワード抽出手段と、
抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つかったらそのレコードの口座番号に紐付く個人専用ページのデータをユーザ端末に送信するログイン処理手段とを備えることを特徴とする認証サーバ。
【請求項22】
請求項21に記載の認証サーバであって、
前記ログイン処理手段は、前記個人専用ページのデータをユーザ端末に送信したら、さらに前記URLから抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから削除することを特徴とする認証サーバ。
【請求項23】
請求項21に記載の認証サーバであって、
さらに、前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致していれば認証成功と判定し、不一致であれば認証失敗と判定する個人情報照合手段を備えることを特徴とする認証サーバ。
【請求項24】
ユーザ端末から個人専用ページへログインを支援するための認証サーバであって、
口座番号、当該口座番号に対応するユーザの生年月日または電話番号または郵便番号、およびユーザのメールアドレスを格納する顧客DBを有する記憶装置と、
ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受け付け、前記URLからワンタイムパスワードを抽出するパスワード抽出手段と、
URLから抽出したワンタイムパスワードを復号して日時と口座番号を抽出し、前記日時が現在時刻よりも一定時間以上前でなく、かつ一定時間以上後でもなく、また前記口座番号と同一の口座番号を持つレコードが前記顧客DBに存在していれば、前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致であれば、前記口座番号に対応する個人専用ページのデータを前記ユーザ端末に送信するログイン処理手段とを備えることを特徴とする認証サーバ。
【請求項25】
請求項9または10または11または12または13または14または15または16または17または21または22または23に記載の認証サーバであって、
前記認証DBから、日時が一定の期日以前であるレコードを全て削除するパスワード削除手段を備えることを特徴とする認証サーバ。
【請求項1】
ユーザのメールアドレスを登録するための情報端末であって、
表示手段と、
ユーザ端末と非接触方式で通信可能な通信手段と、
ユーザによって挿入されたカードからユーザの口座番号および暗証番号を読み取る読取手段と、
ユーザによる暗証番号の入力を受け付ける入力手段と、
ユーザによって入力された暗証番号を前記カードから読み取られた暗証番号と照合する本人確認手段と、
前記口座番号と現在日時に基づいてワンタイムパスワードを生成するパスワード生成手段と、
前記口座番号と前記現在日時、および前記ワンタイムパスワードを認証サーバに送信するパスワード送信手段と、
メールを送信するか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレスの登録方法または変更方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードをメール本文に記載したメールを前記ユーザ端末に送信するメール送信手段とを備えることを特徴とする情報端末。
【請求項2】
請求項1に記載の情報端末であって、
前記パスワード送信手段は、前記口座番号と前記現在日時、および前記ワンタイムパスワードに加えて、入出金指示を前記認証サーバに送信することを特徴とする情報端末。
【請求項3】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、前記表示手段に前記案内を表示した後に前記通信手段が前記ユーザ端末を検知しないままユーザによって前記メールを送信するか否かの選択肢のいずれかまたは前記明細書を印刷するか否かの選択肢のいずれかが選択されたら、取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項4】
請求項3に記載の情報端末であって、
前記メール送信手段は、前記メールを送信するか否かの選択肢において送信する旨が選択されていたら、前記取引完了画面とともにメールが届かない場合の案内を前記表示手段に表示することを特徴とする情報端末。
【請求項5】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、前記表示手段に前記案内を表示した後に前記通信手段によって前記ユーザ端末を検知した場合に、前記メールを送信するか否かの選択肢を前記表示手段の画面から削除することを特徴とする情報端末。
【請求項6】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、ユーザのメールアドレスの登録有無を前記認証サーバから受信し、前記ユーザのメールアドレスが未登録であれば、明細書を印刷するか否かの選択肢およびメールアドレスの登録方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードをメール本文に記載したメールを前記ユーザ端末に送信し、前記明細書を印刷するか否かの選択肢のいずれかが選択されたら取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項7】
請求項1または2に記載の情報端末であって、
前記メール送信手段は、ユーザのメールアドレスの登録有無を前記認証サーバから受信し、前記ユーザのメールアドレスが登録済みであれば、メールを送信するか否かの選択肢、明細書を印刷するか否かの選択肢、およびメールアドレスの変更方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードをメール本文に記載したメールを前記ユーザ端末に送信し、その後に前記明細書を印刷するか否かの選択肢のいずれか選択されたら取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項8】
請求項1または2に記載の情報端末であって、
前記パスワード生成手段は、前記口座番号と前記現在日時を含む数字のハッシュ値を計算することにより前記ワンタイムパスワードを算出することを特徴とする情報端末。
【請求項9】
ユーザのメールアドレスを登録するための認証サーバであって、 情報端末から、情報端末によってユーザの口座番号と日時から生成されたワンタイムパスワード、ユーザのカードから読み取られた口座番号、および日時を受信する受信手段と、
受信した前記ワンタイムパスワード、前記口座番号、および前記日時を格納する認証DBと、前記口座番号、当該口座番号に対応するユーザの生年月日または電話番号または郵便番号、および前記ユーザのメールアドレスを格納する顧客DBと、を有する記憶装置と、
前記情報端末から前記口座番号、前記日時、および前記ワンタイムパスワードを受信し、前記認証DBに追加するパスワード登録手段と、
ユーザ端末からのメールを受信し、前記メールから前記ワンタイムパスワードを抽出するパスワード抽出手段と、
抽出した前記ワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つかったらそのレコードの口座番号と同一の口座番号を持つ前記顧客DBのレコードの、メールアドレスの項目に前記メールの受信元アドレスを記録するメールアドレス登録手段とを備えることを特徴とする認証サーバ。
【請求項10】
請求項9に記載の認証サーバであって、
前記メールアドレス登録手段は、前記顧客DBのレコードのメールアドレスの項目に前記メールの受信元アドレスを記録したら、さらに前記メールから抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから削除することを特徴とする認証サーバ。
【請求項11】
請求項9に記載の認証サーバであって、
さらに、前記情報端末から受信した口座番号をキーにして前記顧客DBを参照し、当該口座番号のユーザのメールアドレスが既に登録済みか否かを確認し、その結果を前記情報端末に送信するメールアドレス確認手段を備えることを特徴とする認証サーバ。
【請求項12】
請求項9に記載の認証サーバであって、
前記パスワード登録手段は、前記情報端末から受信した前記口座番号と同一の口座番号を持つレコードが既に前記認証DBに登録されていたら、当該レコードを上書きして前記口座番号、前記日時、および前記パスワードを登録することを特徴とする認証サーバ。
【請求項13】
請求項9に記載の認証サーバであって、
前記メールアドレス登録手段は、前記顧客DBのレコードのメールアドレスの項目に前記メールの受信元アドレスを記録したら、さらに前記メールを送信してきたユーザ端末に対して認証が成功した旨のメールを送信することを特徴とする認証サーバ。
【請求項14】
請求項9に記載の認証サーバであって、
さらに、前記メールから抽出したワンタイムパスワードをURLに埋め込み、前記URLを本文に記載したメールを前記メールの送信元であるユーザ端末に送信するメール送信手段を備えることを特徴とする認証サーバ。
【請求項15】
請求項14に記載の認証サーバであって、
さらに、前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致していれば認証成功と判定し、不一致であれば認証失敗と判定する個人情報照合手段を備えることを特徴とする認証サーバ。
【請求項16】
請求項9に記載の認証サーバであって、
前記認証DBは、さらにメールアドレスを格納し、
前記メールアドレス登録手段は、前記メールから抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つからなかったら前記認証DBに前記ワンタイムパスワードと前記メールの送信元アドレスと現在日時を登録し、
前記パスワード登録手段は、前記情報端末から前記口座番号、前記日時、および前記ワンタイムパスワードを受信したら、前記ワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つかったらそのレコードのメールアドレスを、前記情報端末から受信した口座番号と同一の口座番号を持つ前記顧客DBのレコードのメールアドレスの項目に記録することを特徴とする認証サーバ。
【請求項17】
請求項16に記載の認証サーバであって、さらに、
前記情報端末から受信したワンタイムパスワードをURLに埋め込み、前記ワンタイムパスワードと同一のワンタイムパスワードを持つ前記認証DBのレコードにおけるメールアドレスに対して、前記URLを本文に記載したメールを送信するメール送信手段と、
前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致していれば認証成功と判定し、不一致であれば認証失敗と判定する個人情報照合手段とを備えることを特徴とする認証サーバ。
【請求項18】
ユーザ端末から個人専用ページへログインを支援するための情報端末であって、
表示手段と、
ユーザ端末と非接触方式で通信可能な通信手段と、
ユーザによって挿入されたカードからユーザの口座番号および暗証番号を読み取る読取手段と、
ユーザによる暗証番号の入力を受け付ける入力手段と、
ユーザによって入力された暗証番号を前記カードから読み取られた暗証番号と照合する本人確認手段と、
前記口座番号と現在日時に基づいてワンタイムパスワードを生成するパスワード生成手段と、
前記口座番号と前記現在日時、および前記ワンタイムパスワードを認証サーバに送信するパスワード送信手段と、
明細書を印刷するか否かの選択肢とURLの受信方法の案内を前記表示手段の画面に表示し、その後に前記通信手段によって前記ユーザ端末を検知した場合に、前記ワンタイムパスワードを埋め込んだURLをケータイに送信するURL送信手段を備えることを特徴とする情報端末。
【請求項19】
請求項18に記載の情報端末であって、
前記URL送信手段は、前記明細書を印刷するか否かの選択肢と前記URLの受信方法の案内を前記表示手段の画面に表示し、その後に前記通信手段が前記ユーザ端末を検知しないままユーザによって前記明細書を印刷するか否かの選択肢のいずれかが選択されたら、取引完了画面を前記表示手段に表示することを特徴とする情報端末。
【請求項20】
請求項18に記載の情報端末であって、
前記パスワード生成手段は、前記口座番号と前記現在日時を含む数字のハッシュ値を計算することにより前記ワンタイムパスワードを算出することを特徴とする情報端末。
【請求項21】
ユーザ端末から個人専用ページへログインを支援するための認証サーバであって、
情報端末から、情報端末によってユーザの口座番号と日時から生成されたワンタイムパスワード、ユーザのカードから読み取られた口座番号、および日時を受信する受信手段と、
受信した前記ワンタイムパスワード、前記口座番号、および前記日時を格納する認証DBと、前記口座番号、当該口座番号に対応するユーザの生年月日または電話番号または郵便番号、および前記ユーザのメールアドレスを格納する顧客DBと、を有する記憶装置と、
前記情報端末から前記口座番号、前記日時、および前記ワンタイムパスワードを受信し、前記認証DBに追加するパスワード登録手段と、
ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受け付け、前記URLからワンタイムパスワードを抽出するパスワード抽出手段と、
抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから検索し、見つかったらそのレコードの口座番号に紐付く個人専用ページのデータをユーザ端末に送信するログイン処理手段とを備えることを特徴とする認証サーバ。
【請求項22】
請求項21に記載の認証サーバであって、
前記ログイン処理手段は、前記個人専用ページのデータをユーザ端末に送信したら、さらに前記URLから抽出したワンタイムパスワードと同一のワンタイムパスワードを持つレコードを前記認証DBから削除することを特徴とする認証サーバ。
【請求項23】
請求項21に記載の認証サーバであって、
さらに、前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致していれば認証成功と判定し、不一致であれば認証失敗と判定する個人情報照合手段を備えることを特徴とする認証サーバ。
【請求項24】
ユーザ端末から個人専用ページへログインを支援するための認証サーバであって、
口座番号、当該口座番号に対応するユーザの生年月日または電話番号または郵便番号、およびユーザのメールアドレスを格納する顧客DBを有する記憶装置と、
ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受け付け、前記URLからワンタイムパスワードを抽出するパスワード抽出手段と、
URLから抽出したワンタイムパスワードを復号して日時と口座番号を抽出し、前記日時が現在時刻よりも一定時間以上前でなく、かつ一定時間以上後でもなく、また前記口座番号と同一の口座番号を持つレコードが前記顧客DBに存在していれば、前記ワンタイムパスワードが埋め込まれたURLに基づくユーザ端末からのアクセスを受けて、前記ワンタイムパスワードをキーとして前記認証DBを検索することにより、アクセスしたユーザの口座番号を特定し、前記ユーザの個人情報を入力するページのデータを前記ユーザ端末に送信し、前記ユーザ端末から送信された個人情報を前記顧客DBに登録されている個人情報と照合し、一致であれば、前記口座番号に対応する個人専用ページのデータを前記ユーザ端末に送信するログイン処理手段とを備えることを特徴とする認証サーバ。
【請求項25】
請求項9または10または11または12または13または14または15または16または17または21または22または23に記載の認証サーバであって、
前記認証DBから、日時が一定の期日以前であるレコードを全て削除するパスワード削除手段を備えることを特徴とする認証サーバ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【公開番号】特開2009−276864(P2009−276864A)
【公開日】平成21年11月26日(2009.11.26)
【国際特許分類】
【出願番号】特願2008−125374(P2008−125374)
【出願日】平成20年5月13日(2008.5.13)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
【公開日】平成21年11月26日(2009.11.26)
【国際特許分類】
【出願日】平成20年5月13日(2008.5.13)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】
[ Back to top ]