JP2006146456A

JP2006146456A - 認証装置

Info

Publication number: JP2006146456A
Application number: JP2004333978A
Authority: JP
Inventors: Takuji Numata; 卓治沼田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-11-18
Filing date: 2004-11-18
Publication date: 2006-06-08
Anticipated expiration: 2024-11-18
Also published as: JP4677768B2

Abstract

【課題】
一ユーザあたりの認証端末の占有時間を極力抑えながら、複数のサービス運営者が生体認証端末を利用できるようにする。
【解決手段】
各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、ユーザからユーザ識別情報および認証情報を受け付ける受付手段と、ユーザから入力された認証情報と、認証するための基準となる基準認証情報とを比較し、その比較結果に基づき本人認証を行う認証手段と、前記認証テーブルを参照し、前記ユーザに対応する前記ユーザ端末に対して、本人認証の結果を通知する通知手段を備える。
【選択図】
図１

Description

本発明は、特定の認証方法を複数のサービスで共同利用することを可能とする認証装置に関する。

現在、コンビニエンスストアに設置されるＡＴＭ（現金自動預け入れ払い機）の中には、複数の銀行の取引を可能とするものがある（非特許文献１）。

一方、最近の銀行ＡＴＭにおいて、生体情報を利用した認証方法を採用したものが搭乗している。（非特許文献２）
イーネットＡＴＭについて、[online]、[平成１６年１１月８日検索]、インターネット＜ＵＲＬ：http://www.enetcom.co.jp/s%5fcontents/e-net/index.html＞東京三菱銀行、手のひら静脈認証に対応したキャッシュカード、[online]、[平成１６年１１月８日検索]、インターネット＜ＵＲＬ：http://k-tai.impress.co.jp/cda/article/news%5f toppage/20695.html＞

生体認証には専用の生体認証端末が必要となる。しかし、全てのサービスが独自に生体認証端末を設置すると設置コストがかかる。したがって、生体認証できる端末を共同で利用することが考えられる。

しかし、設置台数の少ない生体認証端末において、従来の共同利用ＡＴＭと同じように、本人認証の後に取引処理まで行ってしまうと、現在のＡＴＭ設置コーナーで生じているより、もっとひどいユーザ待ち行列が出来る恐れがある。

さらに、銀行業界だけでなく、複数の業界が生体認証を共同利用するようになれば、ユーザ待ち行列の問題はより深刻になる。

本発明の目的は、一ユーザあたりの認証端末利用時間を極力抑えながら、複数のサービス運営者が生体認証端末を利用できるようにすることにある。

本発明は、ユーザの本人認証を行う認証装置であって、各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、ユーザからユーザ識別情報および認証情報を受け付ける受付手段と、ユーザから入力された認証情報と、認証するための基準となる基準認証情報と比較し、その比較結果に基づき本人認証を行う認証手段と、前記認証テーブルを参照し、前記ユーザに対応する前記ユーザ端末に対して、本人認証の結果を通知する通知手段を備えることを特徴とする。

さらに、本発明は、前記認証手段が、本人を認証済みであることを示す認証済み情報を生成し、前記通知手段が、本人認証の結果とともに、前記認証済み情報を通知することを特徴とする。

また、本発明は、ユーザの本人認証を行う認証装置であって、各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、各サービスを示すサービス識別情報に対応してサービス装置の連絡先を管理するサービス管理テーブルと、ユーザからユーザ識別情報、認証情報、特定のサービス識別情報、および、該特定のサービスにおいて前記ユーザに対して発行された発行情報を受け付ける受付手段と、ユーザから入力された認証情報と、認証するための基準となる基準認証情報と比較し、その結果に基づき本人認証を行う認証手段と、前記認証手段で本人認証が成功した場合は、前記サービス管理テーブルを参照し、前記受信したサービスの識別情報に対応するサービス装置に対して、認証結果、前記ユーザの識別情報、前記発行情報を通知するとともに、前記認証テーブルを参照し、前記ユーザに対応するユーザ端末に対して認証結果および前記発行情報を通知する通知手段を備えることを特徴とする。

本発明は、認証端末に認証処理だけを行わせるため、一ユーザ当たりの認証端末の占有時間を極力短くすることが可能である。

本発明は、認証端末は認証情報の入力のみを行い、認証結果はユーザ端末に通知するため、さらに占有時間を短くすることが可能である。

本発明は、本人認証済の情報をユーザ端末に通知するため、ユーザは、その該認証済み情報を簡便に再利用して、希望サービスへのログイン操作を容易にすることが可能である。

本発明は、各サービスがユーザに対して発行した、例えば注文番号のような発行情報を、本人認証結果とともにサービス装置へ通知するため、サービス運営者は各取引毎の本人認証を確認することが可能である。

以下、本発明における第一から第三の実施形態を示す。尚、ここに示す実施例と同等の効果が生じるものであれば、どのような変更を加えても構わない。

本発明における第一の実施例におけるシステム全体の構成を図１に示す。本発明は、認証仲介装置１００、認証端末２００、サービス装置３００・３０１、携帯端末４００で構成される。

認証仲介装置１００は、さらに、認証仲介手段１１０、システムＤＢ（データベース）１２０、個人情報ＤＢ１３０、認証履歴ＤＢ１４０で構成される。

認証仲介手段１１０は、認証端末２００から生体認証結果を受信し、その認証結果を認証履歴ＤＢ１４０に蓄積するとともに、携帯端末４００に認証結果を通知する。この際、認証結果が本人である場合は、サービス装置３００・３０１にユーザ情報を照会した上で、本人認証済みである認証済み情報を生成して携帯端末４００に通知する。

システムＤＢ１２０は、認証仲介手段１１０が各サービス装置３００・３０１へ通信する際のアドレス情報が管理される。図４に示すように、システムＤＢ１２０内で管理されるシステム管理テーブル６００は、サービス名称とサービス装置の接続先情報で構成される。

個人情報ＤＢ１３０には、図３に示すような個人情報テーブル５００が存在する。個人情報テーブル５００は、生体認証のためのユーザＩＤ、ユーザ氏名、ユーザ住所、および、ユーザのメールアドレスが対応づけて管理される。

認証履歴ＤＢ１４０には、図５に示すような認証履歴テーブル７００が存在する。認証履歴テーブル７００は、認証端末２００から送信される認証結果（認証結果、生体認証の為のユーザＩＤ）とともに、ユーザが希望するサービス名称、および、該当サービス装置へのユーザ照会結果が管理される。

認証端末２００は、複数のユーザが使用できる環境に設置され、静脈認証処理を行う。認証端末２００は、諸画面を表示しユーザからの各種入力を受け付ける表示手段２１０、認証端末２００に挿入されたＩＣカード内に登録された静脈情報とユーザが入力してきた静脈情報の一致度により生体認証を判定する静脈認証手段２２０で構成される。

本実施例では、生体認証として静脈認証を採用しているが、この他、指紋、声紋、掌紋、虹彩、顔など他の身体的特徴に基づく認証でも構わないし、あるいは、生体認証以外の認証方法でも構わない。また、通常は金融端末として機能させるため、この認証端末２００に、金融取引に係わる一連の端末側処理手段が備えられても構わない。

サービス装置３００・３０１は、ウェブ技術によって、携帯端末４００に各種サービスを提供し、かつ、認証仲介装置１００と認証情報の送受信を行うサービス手段３１０・３１１、認証情報を含む各取引情報を管理する取引ＤＢ３２０・３２１、そして、サービス利用の為のユーザ情報を管理する顧客ＤＢ３３０・３３１で構成される。

取引ＤＢ３２０内には、図７に示すような、取引テーブル９００が存在する。取引テーブル９００は、サービス利用のためのユーザＩＤ、本人を認証済みであることを示す認証日時情報および認証結果、実際にユーザがサービス装置３００に接続してきた接続日時情報、および、ユーザとの具体的な取引を示す注文番号が管理される。なお、取引ＤＢ３２１内に存在する取引テーブルも取引テーブル９００同様の構成なので図示しない。

顧客ＤＢ３３０内には、図６に示すような、顧客テーブル８００が存在する。顧客テーブル８００は、サービス利用のためのユーザＩＤ、ユーザ氏名、ユーザ住所、サービス利用のためのパスワードが管理される。なお、顧客ＤＢ３３１内に存在する顧客テーブルも顧客テーブル８００同様の構成なので図示しない。

携帯端末４００は、インターネット上のウェブサイトとデータ送受信しながら画面上にウェブサイトの情報を表示する閲覧手段４１０と、電子メールを作成および送受信するメール手段４２０で構成される。携帯端末４００は、携帯電話、ノートパソコン、ＰＤＡ（パーソナル・デジタル・アシスタンス）など、ウェブサイトの閲覧と電子メールが可能であればどのような機器でも構わない。したがって、本実施例では携帯可能な端末としているが、デスクトップパソコンのような据え置き型の情報処理端末であっても何ら問題ない。

認証仲介装置１００、認証端末２００、サービス装置３００・３０１、携帯端末４００は、ネットワークで接続されている。ネットワークは、デジタルコミュニケーションを可能とするのであれば、どのような通信回線でも構わない。また、有線回線か無線回線の区別も必要ない。また、有線回線と無線回線の混在であっても構わない。

図２に、認証仲介装置１００、認証端末２００、サービス装置３００・３０１、携帯端末４００間で行われる処理フローを示す。なお、ここでは、本発明の説明を明確にするため、ユーザがサービス装置３００を利用希望した場合を想定して，以降の説明を進める。

Ｓ１で、認証端末２００がユーザの静脈認証処理を行う。具体的には、表示手段２１０によって表示されたメニュー画面上でユーザが静脈認証処理を選択すると、表示手段２１０は、図８に示すような認証受付画面１０００を表示する。認証受付画面１０００を表示するため、表示手段２１０は、認証仲介装置１００からシステムＤＢ１２０内のシステム管理テーブル６００に登録されているサービス名称を予め取得しておき、そのサービス名称を認証受付画面１０００に表示する。

ユーザは、自分のＩＣカードを認証端末２００に挿入した上で、認証受付画面１０００の静脈登録ＩＤを入力し、画面表示されたサービスから利用を希望するサービスを選択して、静脈認証ボタンを押下する。すると、表示手段２１０は認証処理画面に切替え、静脈認証手段２２０に認証処理を依頼する。静脈認証手段２２０は、ユーザの手のひらから静脈情報をスキャンし、ＩＣカード内に登録されている静脈情報と比較して、その一致度により本人かどうかを判定する。この認証判定処理については、既に実際に行われている従来技術と同じなので、詳細な説明は省略する。

Ｓ2で、認証判定処理を終えたことを静脈認証手段２２０から通知されると、認証端末２００の表示手段２１０は、認証処理の終了を知らせる画面を表示する。さらに、表示手段２１０は静脈認証手段２２０がユーザＩＤ、ユーザの認証結果、および、選択サービス情報を認証仲介装置１００へ送信完了した時点で、再び画面上にメニュー画面を表示し、次ユーザの入力を待つ。本実施例では、認証受付画面１０００に、認証結果は登録メールアドレスへ通知される旨の文章を表示しているが、これを、認証処理の終了を知らせる画面に表示してもよい。

Ｓ３で、認証端末２００から送信されてきたユーザＩＤ、認証結果、および、選択サービス情報に基づき、認証仲介装置１００の認証仲介手段１１０は、認証履歴ＤＢ１４０内の認証履歴テーブル７００に新規レコードを作成し、受信した上記データを記録する。その上で、認証仲介手段１１０は、認証結果が本人認証成功なのか、あるいは、失敗なのか、を判断する。そして、本人認証成功と判断すると、認証仲介手段１１０はＳ４の処理へ進み、一方、本人認証失敗と判断すると、Ｓ８の処理へと進む。

Ｓ４で、認証仲介装置１００の認証仲介手段１１０は、個人情報ＤＢ１３０内の個人情報テーブル５００を参照し、受信したユーザＩＤに該当するユーザ氏名、ユーザ住所を識別する。そして、システムＤＢ１２０内のシステム管理テーブル６００から、受信した選択サービスに該当する接続先情報を特定し、その接続先に設定されるサービス装置３００にユーザ氏名、住所を含むユーザ照会要求を送信する。この際、今回の照会要求を一意に識別する照会番号を生成し、これを認証履歴テーブル７００に記録した上、照会番号を付加した形で照会要求を送信してもよい。

Ｓ５で、認証仲介装置１００から照会要求を、サービス装置３００のサービス手段３１０が受信する。

Ｓ６で、認証仲介装置１００のサービス手段３１０は、受信したユーザ氏名、ユーザ住所の組み合わせを持つレコードが顧客ＤＢ３３０内の顧客テーブル８００に存在するか否かを判定する。そして、該当レコードが存在する場合は、取引ＤＢ３２０内の取引テーブル９００に新規レコードを作成し、当サービス内のユーザＩＤ、認証結果を記録する。そして、静脈認証を済ませていることを確認したことを示す認証済み情報として、現在システム日時を認証日時項目に設定する。さらに、サービス手段３１０は、ユーザ氏名および住所とともに、認証日時を認証済み情報として、認証仲介装置１００に照会結果を送信する。この際、照会番号を受信していれば、照会番号を付加した形で認証仲介装置１００へ送信してもよい。

なお、顧客テーブル８００に該当するユーザ情報が存在しない場合、サービス手段３１０は、認証仲介装置１００から受信したユーザ氏名および住所に照会エラー情報を付して、この照会結果を認証仲介装置１００に送信する。

Ｓ７で、認証仲介装置１００の認証仲介手段１１０は、サービス装置３００からの照会結果を受信する。認証仲介手段１１０は、個人情報テーブル５００に基づき、受信したユーザ氏名および住所からユーザＩＤを識別し、認証履歴テーブル７００の該当ユーザＩＤおよび該当サービスの組み合わせとなっているレコードに対して照会結果の情報を記録する。この際、認証履歴テーブル７００の各レコードが照会番号によって管理されているならば、照会番号で対象レコードを特定してもよい。

サービス装置３００でもユーザ確認ができた場合は、認証仲介手段１１０は、認証履歴テーブル７００の認証日時項目にサービス装置３００から送信されてきた認証日時を、そして、照会項目に「ＯＫ」を設定する。一方、サービス装置３００でユーザ確認できない場合は、認証日時項目は空白のまま、照会項目に「ＮＧ」を設定する。

Ｓ８で、認証仲介装置１００の認証仲介手段１１０は、個人情報テーブル５００を参照し、該当するユーザＩＤのメールアドレスを送信先に設定し、認証結果を携帯端末４００に送信する。すなわち、認証履歴テーブル７００で認証項目および照会項目がともに「ＯＫ」ならば、本人認証されたとみなし、図９に示すような、サービス名称と認証日時情報を含む本人認証完了のメールを送信し、一方、認証履歴テーブル７００で認証項目あるいは照会項目のいずれかが「ＮＧ」ならば、本人認証に失敗したとみなし、図１０に示すような、サービス名称を含む本人認証エラーのメールを送信する。

Ｓ９で、携帯端末４００のメール手段４２０は、認証仲介装置１００からの認証結果を受信する。

Ｓ１０で、携帯端末４００のメール手段４２０はユーザの表示要求に応じて認証結果を表示し、表示された認証結果に応じて、ユーザが、閲覧手段４１０を介して利用希望サービスを提供するサービス装置３００に接続するか否かを判断する。そして、ユーザが利用希望サービスに接続すると判断した場合は、携帯端末４００はＳ１１の処理へと進む。一方、ユーザが他の判断を行った場合は、携帯端末４００は、本実施例に関連する処理を終了する。

Ｓ１１で、携帯端末４００の閲覧手段４１０は、ユーザからのログイン接続要求に応じてサービス装置３００に接続し、サービス装置３００からのログイン画面を受信し、図１１に示すようなログイン画面を表示する。そして、閲覧手段４１０は、当画面上でユーザが入力した、サービス装置３００が提供するサービス用のユーザＩＤおよびパスワード、さらに、認証仲介装置１００から送信されてきた認証日時情報を、サービス装置３００に送信する。

Ｓ１２で、サービス装置３００のサービス手段３１０は、携帯端末４００からの上記ログイン情報を受信する。

Ｓ１３で、サービス装置３００のサービス手段３１０は、受信したユーザＩＤとパスワードの組み合わせが顧客テーブル８００に存在するか否かを確認し、存在する場合は、さらに、取引テーブル９００に受信したユーザＩＤと認証日時情報の組み合わせが存在するか否かを確認する。

そして、取引テーブル９００にもその組み合わせがあれば、サービス手段３１０は、ユーザのログインを承認した日時をそのレコードの接続日時項目に記録した上で、サービスメニュー画面を携帯端末４００へ送信する。一方、取引テーブルに該当する組み合わせがなければ、サービス手段３１０は、ログインエラー画面を携帯端末４００へ送信する。

Ｓ１４で、携帯端末４００の閲覧手段４１０は、サービス装置３００からサービスメニュー画面あるいはログインエラー画面を受信し、画面表示する。

そして、サービスメニュー画面が表示されれば、あとは、ユーザの入力指示に従って閲覧手段４１０は、Ｓ１５でサービス装置３００に特定の画面を要求したり、ユーザの入力情報を送信し、Ｓ１６で、携帯端末４００からのデータに応じて、サービス装置３００のサービス手段３１０は、要求された画面やデータを携帯端末４００に送信したり、携帯端末４００から送信されてきた注文要求に対して、新たな注文番号を生成し、取引テーブル９００の注文番号項目に記録するとともに、注文の詳細内容を図示しない注文ＤＢに蓄積するなどの処理を行う。

一方、Ｓ１４でログインエラー画面が表示されれば、ユーザからの入力に応じて、携帯端末４００は、Ｓ１１の処理を再び繰り返すか、あるいは、本実施例とは関係しない他のサービス装置へ接続するか、あるいは、閲覧手段４１０の処理を終了する。

Ｓ１４〜Ｓ１６の処理は、既に実際に実現されている各種商品販売サイトを利用する場合と同一の処理であり、その処理の詳細説明は省略する。

以上が、本発明における第一の実施例の処理内容である。

次に、本発明における第二の実施例を説明する。第一の実施例と第二の実施例の違いは、第一の実施例では、携帯端末４００に認証結果が送信される前に認証仲介装置１００とサービス装置３００との間で照会処理が行われるのに対して、第二の実施例では、携帯端末４００がサービス装置３００にログイン接続した時点で、認証仲介装置１００とサービス装置３００との間で照会処理がなされる点である。

したがって、第二の実施例では、認証端末２００でユーザが認証依頼してから携帯端末４００に認証結果が受信されるまでの時間が短縮され、本人認証に対するユーザの不安を軽減することができる。また、第二の実施例では認証依頼画面でユーザが利用希望サービスを選択する必要が無いため、ユーザ一人当たりの認証端末２００の占有時間も短くなる。

第二の実施例におけるシステム構成および個々のデータテーブル構成は、第一の実施例のそれとほぼ同一なので、図は省略する。異なる点は、これ以降、適宜説明する。

図１２を用いて、本発明における第二の実施例の処理フローを説明する。

Ｓ２１で、認証端末２００の表示手段２１０および静脈認証手段２２０は、静脈認証に係わる一連の処理を行う。この処理は、第一の実施例におけるＳ１の処理とほぼ同様なので、異なる点のみ説明する。

すなわち、表示手段２１０は、図１３のような認証受付画面２１００を表示する。認証受付画面２１００では、システム管理テーブル６００で管理されるサービス名称を表示するが、ユーザによって希望利用サービスが選択されることはない。

Ｓ２２で、認証端末２００の表示手段２１０および静脈認証手段２２０は、認証処理終了の画面表示とともに、認証仲介装置１００に認証結果を送信するが、これは第一の実施例におけるＳ２の処理とほぼ同様である。但し、認証仲介装置１００に送信される情報は、ユーザＩＤおよび認証結果である。Ｓ２のように選択されたサービス情報が送信されることはない。

Ｓ２３で、認証端末２００から送信されてきたユーザＩＤ、認証結果に基づき、認証仲介装置１００の認証仲介手段１１０は、認証履歴テーブル７００に新規レコードを作成し、受信した上記データを記録する。その上で、認証仲介手段１１０は、受信した認証結果が本人認証成功か、あるいは、失敗か、を判断する。そして、本人認証成功と判断すると、認証仲介手段１１０はＳ２４の処理へ進み、一方、本人認証失敗と判断すると、Ｓ２５の処理へと進む。

Ｓ２４で、認証仲介手段１１０は、本人認証成功と判断したため、本人認証を確認したことを示す認証済み情報として認証履歴テーブル７００の認証日時項目に現在のシステム日時を設定する。

Ｓ２５で、認証仲介手段１１０は、認証履歴テーブル７００に基づき、認証結果と認証日時情報を、対象となる携帯端末４００へ送信する（送信先の設定は、第一の実施例におけるＳ８の処理と同じ）。なお、認証結果が本人認証失敗の場合は、認証日時情報は送信されない。

Ｓ２６で、携帯端末４００のメール手段４２０は、認証仲介装置１００から認証結果の電子メールを受信する。この処理は第一の実施例におけるＳ９と同じである。

Ｓ２７で、携帯端末４００のメール手段４２０が、ユーザの要求に応じて、認証結果の電子メールを表示するとともに、そのメール内容を見たユーザの要求に応じて、メール手段４２０および閲覧手段４１０がそれぞれの処理を行うが、この処理は第一の実施例におけるＳ１０と同じである。

Ｓ２８で、携帯端末４００の閲覧手段４１０がサーバ装置３００にログイン接続の要求をする。この処理は第一の実施例におけるＳ１１と同じである。

Ｓ２９で、サービス装置３００のサービス手段３１０が、携帯端末４００からのログイン接続要求を受信する。この処理は第一の実施例におけるＳ１２と同じである。

Ｓ３０で、サービス装置３００のサービス手段３１０は、受信したユーザＩＤとパスワードの組み合わせが顧客テーブル８００に存在するか否かを確認し、存在する場合は、取引テーブル９００に新規レコードを生成して、受信したユーザＩＤと認証日時情報、そして、ログイン接続要求を受け付けたシステム日時を接続日時項目に記録する。さらに、サービス手段１１０は、顧客テーブル８００から受信ＩＤに対応するユーザ氏名および住所を取り出し、認証日時情報と併せて照会要求を、認証仲介装置１００へ送信する。

Ｓ３１で、サービス装置３００からの照会要求を受信した認証仲介装置１００の認証仲介手段１１０は、個人情報テーブル５００に照らして、受信したユーザ氏名および住所の組み合わせに該当するユーザＩＤを特定し、次に、認証履歴テーブル７００に特定したユーザＩＤと受信した認証日時情報の組み合わせが存在するか否か確認する。そして、存在する場合は、認証仲介手段１１０は、認証履歴テーブル７００の該当レコードのサービス名称項目に照会元のサービス装置３００のサービス名称を記録し、かつ、認証結果項目が「ＯＫ」（本人認証成功）であれば照会項目に「ＯＫ」を設定する。一方、特定したユーザＩＤと認証日時情報の組み合わせが存在しない場合、あるいは、組み合わせが存在するが認証結果項目が「ＮＧ」（本人認証失敗）である場合は、サービス名称項目に照会要求元のサービス名称を記録するが、照会項目には「ＮＧ」を設定する。

Ｓ３２で、認証仲介装置１００の認証仲介手段１１０は、認証履歴テーブル７００に基づいて、照会項目が「ＯＫ」ならば、サービス装置３００に対して静脈認証成功を示す照会結果を送信し、一方、照会項目が「ＮＧ」ならば、照会エラーを示す照会結果を送信する。照会結果には、Ｓ３１で受信したユーザ氏名、住所、認証日時情報が付される。

Ｓ３３で、サービス装置３００のサービス手段３１０は、認証仲介装置１００からの照会結果を受信し、照会結果がＯＫならば、取引テーブル９００内で該当するレコードについて、その認証結果項目に「ＯＫ」を記録し、一方、照会結果がエラーならば「ＮＧ」を記録する。

Ｓ３４で、サービス装置３００のサービス手段３１０は、取引テーブル９００の該当レコードの認証結果項目を識別し、「ＯＫ」ならば、Ｓ３５へ進み、サービスメニュー画面を携帯端末４００へ送信し、Ｓ３６で携帯端末４００の閲覧手段４１０はサービスメニュー画面を表示し、それ以降、ユーザの入力指示に応じて、取引のための一連の表示処理、要求指示や入力情報の送信処理を行う。

一方、取引テーブル９００の該当レコードの認証結果項目が「ＮＧ」ならば、サービス手段３１０は、Ｓ３７へ進みログインエラー画面を携帯端末４００に送信し、Ｓ３８で携帯端末４００の閲覧手段４１０は、ログインエラー画面を表示し、以下はユーザの指示に従って、終了処理あるいは本発明には関連しない処理を実施する。

Ｓ３５〜Ｓ３８の処理は、第一の実施例におけるＳ１３〜Ｓ１６の該当部分の処理と同じである。

以上が、本発明における第二の実施例の説明である。

次に、本発明における第三の実施例を説明する。システム構成図、データテーブル構造、画面例のうち、第一の実施例と同一のものは重複を避けるため新たに図示しない。

第三の実施例の特徴は、第一および第二の実施例が、静脈認証を行った上で各サービスの取引処理を開始するのに対して、第三の実施例は、先に取引処理を行った後、その取引を確定させるための最終確認として静脈認証を行う点である。これにより、最終的に注文を行うかどうかわからないにもかかわらず、ユーザが認証端末２００で静脈認証しなければならないという無駄を省ける。この結果、認証端末２００を利用するユーザの待ち行列を短くすることが可能となる。

図１５を用いて、第三の実施例の処理フローを説明する。

Ｓ４１で、携帯端末４００の閲覧手段４１０は、サービス装置３００へログイン接続する。Ｓ４２で、サービス装置３００のサービス手段３１０は、ユーザＩＤおよびパスワードでユーザ認証できれば、サービスメニュー画面を携帯端末４００へ送信し、これ以降、Ｓ４３で、閲覧手段４１０はサービス装置３００から送信される画面を表示し、ユーザが入力した情報を送信し、Ｓ４４で、サービス手段は携帯端末４００からの要求で画面送信し、あるいは、受信情報を蓄積する。また、サービス手段３１０は、Ｓ４２でユーザ認証できない場合は、ログインエラー画面を携帯端末４００へ送信する。

これらの処理は、例えば、商品販売サイトで既に一般的に行われている処理であるので、詳細な説明は省略する。

Ｓ４５で、サービス装置３００のサービス手段３１０は、携帯端末４００からの注目確定指示を受信すると、図１７に示すような取引テーブル３１００に新規レコードを生成し、ユーザＩＤと仮注文日時を記録するとともに、該注文を識別する一意の注文番号を生成し、これも併せて記録する。

そして、サービス手段３１０は、図１６に示すような顧客テーブル３０００からこのユーザＩＤに対応するメールアドレスを送信先に設定し、図１９に示すような静脈認証依頼画面３４００を携帯端末４００に送信する。静脈承認依頼画面３４００には、注文内容とともに該注文を識別するための注文番号が示される。

Ｓ４６で、携帯端末４００の閲覧手段４１０が、サービス装置３００から静脈承認依頼画面３４００を受信し画面表示する。この時ユーザはこの注文番号を適当なファイルに保存するか、あるいは、他の方法により注文番号を保存する。その後、ユーザの指示に従い閲覧手段４１０は終了処理を行う。この処理は、例えば、商品販売サイトを閲覧する時に既に一般的に行われている処理と変わらない。

Ｓ４７で、認証端末２００はユーザの静脈認証を行う。

すなわち、認証端末２００の表示手段２１０は、メニュー選択画面から静脈認証処理が選択されると、図２０に示すような認証受付画面３５００を表示する。表示手段２１０は、予め認証仲介装置１００のシステム管理テーブル６００に登録されるサービス名称を受信し、そのサービス名称を画面表示する。また、認証受付画面３５００には、ユーザが注文番号を入力できる備考欄を設けておく。

ユーザは、認証受付画面３５００で、静脈認証用のユーザＩＤを入力し、表示サービス名称から注文先のサービス名称を選択し、注文番号を入力した上で、静脈認証実行ボタンを押下する。ここで表示手段２１０は静脈認証手段２２０に認証処理を依頼する。

静脈認証手段２２０は、静脈認証による本人認証処理を実行する。静脈認証の方法は、第一の実施例のＳ１と同じである。静脈認証処理の完了を受けて、表示手段２１０は、静脈認証の処理が完了したことのみを告げる終了画面を表示した上で、再びメニュー画面を表示して次ユーザの入力に備える。

Ｓ４８で、認証端末２００の静脈認証手段２２０は、Ｓ４７で行った認証処理に基づき、認証仲介装置１００に対して、ユーザＩＤ、サービス名称、注文番号、および、認証結果を送信する。

Ｓ４９で、認証仲介装置１００の認証仲介手段１１０は、認証端末２００から受信した情報に基づき、図１８に示すような認証履歴テーブル３３００の該当レコードに基づき、ユーザＩＤ、サービス名称、注文番号、認証結果を記録する。そして、認証結果が本人認証成功であれば、この情報を受信した日時を、本人認証済みであることを示す情報として認証日時項目に記録する。

そして、認証仲介手段１１０は、個人情報テーブル５００からユーザＩＤに該当するメールアドレスを送信先に設定し、認証履歴テーブル３３００に新たに記録した情報に基づき、図２１に示すような本人認証に成功した旨を通知する認証結果メール３６００、あるいは、図２２に示すような本人認証エラーを通知する認証結果メール３７００を生成して、携帯端末４００へ送信する。

Ｓ５０で、携帯端末４００のメール手段４２０は、認証仲介装置１００から認証結果メール３６００あるいは認証結果メール３７００を受信し、ユーザの指示に応じて、当メールを画面表示する。

Ｓ５１で、認証仲介装置１００の認証仲介手段１１０は、個人情報テーブル５００からユーザＩＤに対応するユーザ氏名および住所を識別した上で、システム管理テーブル６００からサービス名称に対応する接続先を送信先に設定し、ユーザの指定したサービス装置３００に対して、ユーザ氏名、住所、それに、認証履歴テーブル３３００に基づく注文番号、および、認証結果を送信する。この際、本人認証が成功した認証結果であれば、さらに、認証日時情報も付加して送信する。

Ｓ５２で、サービス装置３００のサービス手段３１０は、認証仲介装置１００から、静脈認証結果を受信し、ユーザ氏名および住所を顧客テーブル３０００に照らしてユーザＩＤを識別し、取引テーブル３１００から対応するユーザＩＤおよび注文番号を含むレコードを特定し、その認証結果を認証結果項目に、そして、受信内容に認証日時情報が含まれていれば、その認証日時情報を認証日時項目に記録する。

Ｓ５３で、サービス装置３００のサービス手段３１０は、取引テーブル３１００に記録した認証結果項目を識別し、その項目が「ＯＫ」（本人認証成功）であれば、携帯端末４００に対して、仮注文を本注文として処理する旨の仮注文最終結果メールを送信し、一方、「ＮＧ」（本人認証失敗）であれば、静脈認証による本人認証ができないため仮注文を取り消す旨の仮注文最終結果メールを送信する。

メールの送信先は、顧客テーブル３０００から、該当ユーザＩＤに対応するメールアドレスを特定することで、設定する。

Ｓ５４で、携帯端末４００のメール手段４２０は、サービス装置３００から仮注文最終結果メールを受信し、ユーザの指示に応じて、当メールを画面表示する。

Ｓ５５で、サービス装置３００のサービス手段３１０は、取引テーブル３１００に新たに更新されたレコードの認証結果項目を識別し、その項目が「ＯＫ」であれば、Ｓ５６に進み、サービス手段３１０は、仮注文を本注文として認識し、発送処理や決裁処理など商品販売に関する一連の処理を実行して、この取引の処理を終了する。

一方、認証結果項目が「ＮＧ」ならば、サービス手段３１０は、注文番号に対応する注文について注文を取り消す処理を行い、また、在庫品情報の更新などこの注文取消しに影響される諸処理を実行して、この取引の処理を終了する。

以上が、本発明における第三の実施例である。

第一から第三の実施例において、認証端末２００の認証受付画面１０００・２１００・３５００で、ユーザがユーザＩＤを入力するようにしているが、ユーザＩＤは入力させず、静脈認証によって本人認証されれば、静脈認証手段２２０が、挿入されたＩＣカード内に記憶されたユーザＩＤを読出し、これを認証仲介装置１００に送るようにしてもよい。あるいは、ユーザＩＤの代わりに静脈認証用または特定サービス用のパスワードを入力させ、入力された静脈情報およびパスワードが、ＩＣカードに記憶された静脈情報およびパスワードとそれぞれ一致すれば、ＩＣカードに記憶されたユーザＩＤを静脈認証手段２２０が読み出すようにしてもよい。

また、第一から第三の実施例では、ＩＣカード内に基準となる静脈情報を記憶しておき、認証端末２００の静脈認証手段２２０がユーザ入力された静脈情報と照合している。これを、基準となる静脈情報をＩＣカード内ではなく認証仲介装置１００に保存し、静脈認証手段２２０は、ユーザ入力された静脈情報を認証仲介装置１００に送信するのみで、認証仲介装置１００の照合手段が、両者の静脈照合を実施するようにしてもよい。

また、第一から第三の実施例において、本人であることを認証済みであることを示す認証済み情報を、認証日時情報としたが、認証済みであることを示すことができればこれ以外でもどのような情報を認証済み情報としても構わない。
（付記１）ユーザの本人認証を行う認証装置であって、
各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、
ユーザからユーザ識別情報および認証情報を受け付ける受付手段と、
ユーザから入力された認証情報と、認証するための基準となる基準認証情報と比較し、その比較結果に基づき本人認証を行う認証手段と、
前記認証テーブルを参照し、前記ユーザに対応する前記ユーザ端末に対して、本人認証の結果を通知する通知手段と
を備えることを特徴とする認証装置。
（付記２）付記１記載の認証装置であって、
前記認証手段は、本人を認証済みであることを示す認証済み情報を生成し、
前記通知手段は、本人認証の結果とともに、前記認証済み情報を通知する
ことを特徴とする認証装置。
（付記３）付記１記載の認証装置であって、
前記認証手段は、前記認証済み情報および前記本人認証の結果を前記認証テーブルに管理し、前記ユーザ端末にサービスを提供するサービス装置から、前記認証済み情報、前記ユーザの個人情報を含む照会要求を受信すると、前記認証テーブルに基づき、該認証済み情報に対応する本人認証の結果をサービス装置へ送信する
ことを特徴とする認証装置。
（付記４）付記１記載の認証装置であって、さらに、
各サービスを示すサービス識別情報に対応してサービス装置の連絡先を管理するサービス管理テーブルを備え、
前記受付手段は、ユーザが利用を希望するサービス識別情報も併せて受け付け、
前記認証手段は、前記管理テーブルに基づき、前記サービス識別情報に対応するサービス装置へ、前記ユーザが該サービス装置に登録されているか否かを照会する照会要求を送信し、サービス装置からの本人を認証済みであることを示す認証済み情報を含む照会結果を受信し、
前記通知手段は、前記サービス装置から受信した認証済み情報を前記ユーザ端末へ送信する
ことを特徴とする認証装置。
（付記５）ユーザの本人認証を行う認証装置であって、
各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、
各サービスを示すサービス識別情報に対応してサービス装置の連絡先を管理するサービス管理テーブルと、
ユーザからユーザ識別情報、認証情報、特定のサービス識別情報、および、該特定のサービスにおいて前記ユーザに対して発行された発行情報を受け付ける受付手段と、
ユーザから入力された認証情報と、認証するための基準となる基準認証情報と比較し、その比較結果に基づき本人認証を行う認証手段と、
前記認証手段で本人認証が成功した場合は、前記サービス管理テーブルを参照し、前記受信したサービスの識別情報に対応するサービス装置に対して、認証結果、前記ユーザの識別情報、前記発行情報を通知するとともに、前記認証テーブルを参照し、前記ユーザに対応するユーザ端末に対して認証結果および前記発行情報を通知する通知手段と
を備えることを特徴とする認証装置。

本発明の第一の実施例における、システム構成例を示す図である。本発明の第一の実施例における、処理フローを示す図である。本発明の第一の実施例における、個人情報テーブルを示す図である。本発明の第一の実施例における、システム管理テーブルを示す図である。本発明の第一の実施例における、認証履歴テーブルを示す図である。本発明の第一の実施例における、顧客テーブルを示す図である。本発明の第一の実施例における、取引テーブルを示す図である。本発明の第一の実施例における、認証受付画面（認証端末）を示す図である。本発明の第一の実施例における、認証結果メール（携帯端末）を示す図である。本発明の第一の実施例における、認証結果メール（携帯端末）を示す図である。本発明の第一の実施例における、サービスログイン画面（携帯端末）を示す図である。本発明の第二の実施例における、処理フローを示す図である。本発明の第二の実施例における、認証受付画面（認証端末）を示す図である。本発明の第二の実施例における、認証結果メール（携帯端末）を示す図である。本発明の第三の実施例における、処理フローを示す図である。本発明の第三の実施例における、顧客テーブルを示す図である。本発明の第三の実施例における、取引テーブルを示す図である。本発明の第三の実施例における、認証履歴テーブルを示す図である。本発明の第三の実施例における、静脈認証依頼画面（携帯端末）を示す図である。本発明の第三の実施例における、認証受付画面（認証端末）を示す図である。本発明の第三の実施例における、認証結果メール（携帯端末）を示す図である。本発明の第三の実施例における、認証結果メール（携帯端末）を示す図である。

符号の説明

１００認証仲介装置
１１０認証仲介手段
１２０システムＤＢ（データベース）
１３０個人情報ＤＢ（データベース）
１４０認証履歴ＤＢ（データベース）
２００認証端末
２１０閲覧手段
２１０メール手段
３００・３０１サービス装置
３１０・３１１サービス手段
３２０・３２１取引ＤＢ（データベース）
３３０・３３１顧客ＤＢ（データベース）
５００個人情報テーブル
６００システム管理テーブル
７００・３３００認証履歴テーブル
８００・３０００顧客テーブル
９００・３１００取引テーブル
１０００・２１００・３５００認証受付画面（認証端末）
１２００・１３００・２２００・３６００・３７００認証結果通知メール（携帯端末）
１４００サービスログイン画面（携帯端末）
３４００静脈認証依頼画面（携帯端末）

Claims

ユーザの本人認証を行う認証装置であって、
各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、
ユーザからユーザ識別情報および認証情報を受け付ける受付手段と、
ユーザから入力された認証情報と、認証するための基準となる基準認証情報と比較し、その比較結果に基づき本人認証を行う認証手段と、
前記認証テーブルを参照し、前記ユーザに対応する前記ユーザ端末に対して、本人認証の結果を通知する通知手段と
を備えることを特徴とする認証装置。
請求項１記載の認証装置であって、
前記認証手段は、本人を認証済みであることを示す認証済み情報を生成し、
前記通知手段は、本人認証の結果とともに、前記認証済み情報を通知する
ことを特徴とする認証装置。
ユーザの本人認証を行う認証装置であって、
各ユーザの識別情報、および、ユーザが所有するユーザ端末の連絡先を含む個人情報を対応づけて管理する認証テーブルと、
各サービスを示すサービス識別情報に対応してサービス装置の連絡先を管理するサービス管理テーブルと、
ユーザからユーザ識別情報、認証情報、特定のサービス識別情報、および、該特定のサービスにおいて前記ユーザに対して発行された発行情報を受け付ける受付手段と、
ユーザから入力された認証情報と、認証するための基準となる基準認証情報と比較し、その比較結果に基づき本人認証を行う認証手段と、
前記認証手段で本人認証が成功した場合は、前記サービス管理テーブルを参照し、前記受信したサービスの識別情報に対応するサービス装置に対して、認証結果、前記ユーザの識別情報、前記発行情報を通知するとともに、前記認証テーブルを参照し、前記ユーザに対応するユーザ端末に対して認証結果および前記発行情報を通知する通知手段と
を備えることを特徴とする認証装置。