JP6712551B2 - 生体認証システム及び生体認証方法 - Google Patents

生体認証システム及び生体認証方法 Download PDF

Info

Publication number
JP6712551B2
JP6712551B2 JP2017012450A JP2017012450A JP6712551B2 JP 6712551 B2 JP6712551 B2 JP 6712551B2 JP 2017012450 A JP2017012450 A JP 2017012450A JP 2017012450 A JP2017012450 A JP 2017012450A JP 6712551 B2 JP6712551 B2 JP 6712551B2
Authority
JP
Japan
Prior art keywords
biometric data
biometric
authentication
transaction
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017012450A
Other languages
English (en)
Other versions
JP2018120483A (ja
Inventor
知道 小原
知道 小原
粟津 潔貴
潔貴 粟津
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Frontech Ltd
Original Assignee
Fujitsu Frontech Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Frontech Ltd filed Critical Fujitsu Frontech Ltd
Priority to JP2017012450A priority Critical patent/JP6712551B2/ja
Publication of JP2018120483A publication Critical patent/JP2018120483A/ja
Application granted granted Critical
Publication of JP6712551B2 publication Critical patent/JP6712551B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明は、生体認証システム及び生体認証方法に関する。
現状、サーバ認証(1:N認証)時は、生体PIN(生年月日、電話番号等)と口座暗証番号を入力しているため、他人がなりすます可能性は低い。利便性の観点から、生体PINや口座暗証番号の入力も無くしたいとのニーズ(生体データのみの照合で取引を可能にする手ぶら決済)もあり、その際の不正検知方法を考える必要がある。ここで、生体データとは、主に、手のひらの静脈パターンを念頭に置くが、他の生体データでも良い。
従来、金融機関での生体認証は、ICキャッシュカード内に生体データを格納し、ATM等において読み取ったデータとICカード内の生体データとで1:1認証(Match On Card方式)を実施している。また、口座暗証番号も入力することで二要素認証でのセキュリティとなっている。
最近は、カードレスでのサーバやクラウド側での生体認証(1:N認証)を行うシステムが導入されてきている。その際にも、従来の口座の暗証番号と、生体認証用のPIN(生年月日や電話番号等)を入力している。
先行技術には、特許文献1のように、ICカードによる生体認証が連続して失敗した場合、失敗回数が規定値に達するとそれ以降生体認証を利用不可とするものがある。また、特許文献2のように、特定人物の生体データを含むブラックリストが格納された顧客データベースを備え、生体データがブラックリストに含まれる特定人物の生体データと一致しないとき、特定人物への出金を許可するものがある。また、特許文献3のように、挟み込まれた画像を記録し、その画像をブラックリストに登録し、再度同じ画像を入力したときにリジェクトするものがある。
特開2009−205450号公報 特開2007−188258号公報 特開2005−204681号公報
カードレスでの取引時、暗証番号や生体認証用PINも入力せず、生体データのみでの認証の手ぶら決済の要望も出てきており、その際の不正検知方法が望まれている。つまり、暗証番号や生体認証PINの入力をなしとすると、生体データのみの認証での取引となため、生体データを登録していない人が不正にお金を引き出せてしまう可能性が発生しうる。
生体データの照合のみで認証を行い、取引を実施させる場合、生体データを登録していない人の生体データが、生体データを登録している人の生体データと照合一致する可能性がある。
例えば、照合装置の照合精度の誤差等に起因して、誤って、上記の生体データの照合が一致することが考えられる。誤って照合データが一致した場合、不正な取引(出金等)が可能となる。従って、該不正な取引を防止することが必要である。
そこで、本発明は、生体データの照合のみで行われる認証に基づく取引を実施する際の不正な取引を防止することを目的とする。
本発明の一側面による生体認証システムは、ユーザとの取引を行うサービスを提供可能であって且つ前記取引時に前記ユーザの生体データを取得可能な無人取引端末とネットワークで接続された生体認証システムであって、生体認証が失敗した生体データのうち所定の基準を満たす生体データを登録するブラックリストと、認証を行うための生体データを格納する生体データデータベースとを格納する記憶部と、前記無人取引端末において生体データのみの認証に基づく取引が前記ユーザによって選択された場合該認証のために前記無人取引端末で取得された生体データと前記生体データデータベースに格納されている生体データとを照合する前に、前記取得された生体データと前記ブラックリストに登録されている生体データとを照合する照合部と、前記照合部により、前記取得された生体データと前記ブラックリストに登録されている生体データとの照合一致があった場合には、前記照合一致があったユーザについて所定の本人確認手続を行うことを指示する画面を前記無人取引端末に表示させる制御部と、を備える。
本発明の他の側面による生体認証方法は、ユーザとの取引を行うサービスを提供可能であって且つ前記取引時に前記ユーザの生体データを取得可能な無人取引端末とネットワークで接続されたコンピュータが実行する生体認証方法であって、
生体認証が失敗した生体データのうち所定の基準を満たす生体データを登録するブラックリストと、認証を行うための生体データを格納する生体データデータベースとを格納する記憶部を参照し、
前記無人取引端末において生体データのみの認証に基づく取引が前記ユーザによって選択された場合該認証のために前記無人取引端末で取得された生体データと前記生体データデータベースに格納されている生体データとを照合する前に、前記取得された生体データと前記ブラックリストに登録されている生体データとを照合する照合部を参照し、前記取得された生体データと前記ブラックリストに登録されている生体データとの照合一致があった場合には、前記照合一致があったユーザについて所定の本人確認手続を行うことを指示する画面を前記無人取引端末に表示させる
本発明の実施形態によれば、生体データの照合のみで行われる認証に基づく取引を実施する際の不正な取引を防止することができる。
本発明の実施形態における生体認証システムの概要を示す図である。 本実施形態の生体認証システムの例の概要を更に説明する図である。 業務端末のブロック図である。 登録・管理端末のブロック図である。 認証サーバ/クラウドのブロック図である。 認証サーバ/クラウドのデータベースに格納される各種データの例(その1)を示す図である。 認証サーバ/クラウドのデータベースに格納される各種データの例(その2)を示す図である。 認証サーバ/クラウドのデータベースに格納される各種データの例(その3)を示す図である。 認証サーバ/クラウドのデータベースに格納される各種データの例(その4)を示す図である。 認証サーバ/クラウドのデータベースに格納される各種データの例(その5)を示す図である。 認証サーバ/クラウドのデータベースに格納される各種データの例(その6)を示す図である。 本実施形態の処理のフロー図(その1)である。 本実施形態の処理のフロー図(その2)である。 本実施形態の処理のフロー図(その3)である。 本実施形態の処理のフロー図(その4)である。 本実施形態の処理のフロー図(その5)である。 本実施形態の処理のフロー図(その6)である。 本実施形態の処理のフロー図(その7)である。 本実施形態の処理のフロー図(その8)である。 本実施形態の処理のフロー図(その9)である。 本実施形態の処理のフロー図(その10)である。 本実施形態の処理のフロー図(その11)である。 本実施形態の処理のフロー図(その12)である。 本実施形態の処理のフロー図(その13)である。 業務端末(生体センサー搭載端末)、登録・管理端末、及び、生体認証サーバ/クラウドに共通のコンピュータのハードウェア構成を示す図である。
本発明の実施形態においては、生体認証において不正の可能性のある(照合NGが多い)場合、生体データを取集/保持し、ブラックリスト化しておき、次回以降の認証において、通常の生体データとの突き合わせ前に、ブラックリストの生体データと突き合わせすることで不正な可能性がある取引を認識し、本人確認等の確認を促すことで被害を低減させる。
以上の構成により、照合NGが一定期間(1取引、1日、1か月等)で連続した場合など、所定の閾値を超過した際に、不正アクセスの可能性を検知し、カード等での本人確認を実施したり、一時的に該当口座を凍結させたりし、被害を拡大させないものである。なお、各種閾値情報はサービス事業者のセキュリティポリシーに応じて設定される。
図1は、本発明の実施形態における生体認証システムの概要を示す図である。
本実施形態の生体認証システムは、ATM(Automated Teller Machine)やキオスク端末などの無人取引装置(業務端末:主に、銀行、保険、証券、クレジット等の金融端末)を含み、サーバ認証タイプのシステムで、生体認証のみで取引を行えるサービスを行うシステムである。
本実施形態の生体認証システムの生体センサー搭載端末は、生体センサーを搭載した各種業務端末であり、手のひらの静脈などを取得する生体センサーを搭載し、認証サーバと通信を行える取引装置である。
銀行、保険会社、証券会社などの金融機関店舗の場合、上記取引装置は、ATM、窓口端末、渉外端末などであってもよい。
百貨店、量販店、スーパー、専門店、ショッピングモールのサービスカウンタ、バックヤード等の流通店舗においては、上記取引装置は、POS(Point Of Sales system)端末、モバイルPOS端末、キオスク端末などであってもよい。その他、ホテルの受付・清算機、医療機関における診察受付機などが、上記取引装置であってもよい。
登録・管理端末は、生体データの登録/削除や照合履歴の参照などを行う、取引装置や認証サーバの情報を参照できる端末であり、PCやモバイル端末等である。金融機関の場合、上記登録・管理端末は、サービスカウンタ、バックヤードなどに存在する管理端末であってもよい。
流通店舗の場合、上記登録・管理端末は、サービスカウンタやバックヤードなどに存在する管理端末であってもよい。その他、ホテルや医療機関などでは、各種サービス事業者店舗などに存在する管理端末などが上記登録・管理端末であってもよい。
認証サーバ/クラウドは、登録された生体データを保有し、取引時の読み取った生体データと照合を行うなど生体認証を行うサーバもしくはクラウドシステムである。
図1の例の場合、登録・管理端末と生体認証サーバ/クラウドとの間には、既存システムが存在する。金融機関においては、既存システムは、勘定系システム、情報系システムなどであてもよい。
流通店舗においては、既存システムは、販売/売上管理システム、決済管理システム、ポイント管理システムなどであってもよい。その他、ホテル、医療機関などにおいては、既存システムは、チェックイン管理システム、電子カルテシステムなどであってもよい。
なお、登録・管理端末は、生体認証サーバに直接アクセスしてもよいが、この既存システムを介して生体認証サーバ/クラウドにアクセスすることも可能である。
図2は、本実施形態の生体認証システムの例の概要を更に説明する図である。
図2(a)は、銀行の例であり、店舗のフロントにおいては、ATM、窓口端末、登録端末が設けられる。登録端末は、生体データを登録するための端末である。店舗のバックエンドにおいては、ATMサーバ、営業店サーバ、管理端末が設けられる。これらは、ネットワーク(不図示)を介して、センターの勘定系システムや情報系システムにアクセスすると共に、認証クラウドにもアクセスする。なお、上記したように、認証クラウドへのアクセスは、センターの勘定系システムや情報系システムを介して行われてもよい。認証クラウドは、生体データや付随情報などを所定の記憶装置に格納する。
図2(b)は、小売店の例であり、店舗のフロントには、POS端末、モバイルPOS端末、及び、登録端末などが設けられる。登録端末は、同様に、生体データを登録するための端末である。店舗のバックエンドには、店舗サーバ、クレジットサーバ、管理端末が設けられる。バックエンドは、ネットワークを介して、本部の業務管理システムや、クレジット、ポイントなどや決済処理を管理する決済管理システムにアクセスする。また、同様に、バックエンドからは、認証クラウドにアクセスする。なお、バックエンドから認証クラウドにアクセスする場合、該アクセスは、本部の業務管理システムや決済管理システムを介してなされても良い。認証クラウドの所定の記憶装置には、生体データや付随情報などが格納される。
図3は、業務端末のブロック図である。
業務端末では、業務アプリケーション10が実行される。業務アプリケーション10は、ミドルウェア11上で動作する。ミドルウェア11は、生体認証制御部12−1、ICカード制御部13−1、磁気カード制御部14−1、テンキー制御部15−1、及び現金制御部16−1等を含む。
生体認証制御部12−1は、ドライバを介して生体センサーユニット12−2を駆動して、生体データを取得する。ICカード制御部13−1は、ドライバを介して、ICカードリーダ/ライタ13−2を駆動する。磁気カード制御部14−1は、ドライバを介して、磁気カードリーダ/ライタ14−2を駆動する。テンキー制御部15−1は、ドライバを介して、テンキーユニット15−2を駆動する。現金制御部16−1は、ドライバを介して現金リサイクルユニット16−2を駆動する。
図4は、登録・管理端末のブロック図である。
登録・管理端末においては、管理アプリケーション20が設けられている。管理アプリケーション20は、ミドルウェア21に搭載されている、生体認証制御部22−1、ICカード制御部23−1、磁気カード制御部24−1、テンキー制御部25−1を駆動する。生体認証制御部22−1は、ドライバを介して、生体センサーユニット22−2を駆動する。ICカード制御部23−1は、ドライバを介して、ICカードリーダ/ライタ23−2を駆動する。磁気カード制御部24−1は、ドライバを介して、磁気カードリーダ/ライタ24−2を駆動する。テンキー制御部25−1は、ドライバを介して、テンキーユニット25−2を駆動する。
図5は、認証サーバ/クラウドのブロック図である。
認証サーバ/クラウドでは、生体認証アプリケーション30が実行され、該生体認証アプリケーション30は、登録部31、検索/照合部32、履歴管理部33、閾値管理部34、不正リスク管理部35を制御する。
登録部31は、生体データの登録を行う。検索/照合部32は、生体データの照合を行う。履歴管理部33は、認証履歴を管理する。閾値管理部34は、不正を検出するための閾値を管理する。不正リスク管理部35は、不正アクセスのあったと判断された情報を管理する。
生体認証制御部36は、生体認証するために、業務端末から送信されてきた生体データとデータベースに格納されている生体データとの照合を行い、生体データを業務端末から入力したユーザを認証する。データベースには、生体データ37、付随情報38、照合履歴39、閾値情報40、ネガティブ生体データ41、及びアクション情報42が格納される。ここで、ネガティブ生体データ41は、上記のブラックリストであり、認証を拒絶する生体データを格納する。アクション情報42は、どのような照合結果のときに、どのようなアクションを行うかをリストアップした情報である。
図6〜図11は、認証サーバ/クラウドのデータベースに格納される各種データの例を示す。
図6は、生体データの例である。図6の生体データには、顧客ID、登録日、生体種別、登録データ1〜N、登録パスフレーズ、登録顔データが格納される。生体種別は、例えば、「01」が静脈、「02」が顔、「03」が指紋、「04」が虹彩、「05」が嘗紋などと規定されている。登録パスフレーズは、本人確認時に使用する任意のフレーズが登録される。登録顔データは、生体認証NG時の確認用顔写真を登録する。
図7は、付随情報の例である。付随情報には、顧客IDと、カード情報1〜Nが登録される。図6の生体データと、図7の付随情報を用いると、顧客IDをキーとして、生体データとカード情報が関連付けられ、ユーザがカード情報を入力しなくても、生体認証のみで、取引が可能になる。カード情報は、MS(magnetic strip)やIC内の情報、券面情報などを示す。氏名、性別、年齢、住所地などの顧客の属性情報は、顧客IDをキーとして、顧客マスター(既存システムのデータベース)から識別する。
図8は、照合履歴の例である。照合履歴には、図8(a)の総履歴と、図8(b)の顧客単位の履歴とが設けられる。図8(a)の総履歴には、日付、時間、取引通番、取引種別、金額、顧客ID、取引場所、生体種別、照合結果、リトライ回数、ブラックリスト化の欄が設けられている。ブラックリスト化の欄は、リトライ回数が、例えば、所定回数(例えば、3回)以上になった場合に、その顧客の生体データをブラックリストに登録することを示す情報である。このブラックリスト化の欄に情報が書き込まれた顧客は、ブラックリストに登録されることになる。
図8(b)の顧客単位の照合履歴では、顧客を特定する顧客IDそれぞれに対し、日単位と月単位での取引回数、日単位と月単位での取引金額、日単位と月単位での取引NG回数、日単位と月単位での照合NG回数、日単位と月単位での平均照合NG回数が登録される。取引NG回数は、手ぶら取引単位でのNG回数を示し、照合NG回数は、リトライ回数を含めた照合単位でのNG回数を示す。これらのNG回数が所定の基準を満たしたとき、その顧客はブラックリストに登録される。
図9は、閾値情報の例である。図9の閾値情報においては、照合NGリトライ回数、連続照合NG間隔、日単位の照合NG回数、月単位の照合NG回数、日単位の平均照合NG回数、月単位の照合NG回数、日単位の取引金額、月単位の取引回数等が登録される。照合NGリトライ回数は、サーバ側で実施する照合NG時のリトライ回数であり、端末側から照合NG通知が来た際に、再度、照合指示を出す回数である。連続照合NG間隔は、照合NG取引の間隔であり、照合NG後の再照合を許容する間隔である。日単位、月単位の照合NG回数は、1日、あるいは、1ヶ月での照合NG許容回数であり、照合NG回数の累積値の上限を表す。日単位、月単位での平均照合NG回数は、1日、あるいは、1ヶ月での平均の照合NG許容回数である平均の照合NG回数の上限値を定める。日単位、月単位の取引金額は、1日、あるいは、1ヶ月での手ぶら取引可能金額を示す。
図10は、アクション情報の例である。アクション情報は、生体データがブラックリストの生体データと一致した場合の後処理を規定する。アクションの例としては、カード挿入にて本人確認する(暗証番号入力を含む)、店員に通知して本人確認する(メールやメッセージ通知等)、窓口誘導(窓口での取引に誘導する)、生体データ登録者であるか否かの画面確認(パスフレーズ確認)、カメラ撮影(顔認証で本人確認)、及び、該当口座凍結(口座凍結に加え、保有者へ確認メールを通知する)などがある。これらは、どれを優先しても良く、また、相互に組み合わせて実行してもよい。さらに、アクション情報には、図10の例以外の情報が含まれてもよい。
図11は、ブラックリストの例である。図11のブラックリストには、管理ID,収集日、収集時間、取引通番、生体種別、及び認証に失敗した生体データの登録データ1〜Nが登録される。生体種別の番号の例は、図6で説明したものと同じものを使うことができる。
図12〜図20Bは、本実施形態の処理のフロー図である。
図12は、通常の場合の、出金取引の例である。最初、業務端末の表示画面に取引選択画面が表示される。ユーザが手ぶら出金を選択したとする。すると、業務端末の表示画面に、生体認証画面が表示される(S1)。ユーザが、例えば、生体センサーに手をかざと、生体データの照合が行われる。業務端末は、生体データを取得し、認証サーバ/クラウドに生体認証依頼を行う(S2)。より詳細には、業務端末は、認証サーバ/クラウドに、手ぶら出金、取得生体データを通知する。
認証サーバ/クラウドは、業務端末から送信されてきた生体データと、ブラックリストの生体データとの照合を行う。ここでは、照合一致がないものとする。
次に、ブラックリストではない生体データと送信されてきた生体データとを照合する。ここでは、照合一致があったとする。次に、認証サーバ/クラウドは、業務端末に、生体照合結果を通知する。ここでは、照合結果がOKであることと、該当者の口座情報等を業務端末に送信する(S3)。
この生体照合結果を受信した業務端末は、表示画面に、取引口座選択画面を表示する。ユーザが口座選択をすると、業務端末は、表示画面に、金額入力画面を表示する。ユーザが金額を入力すると、業務端末は、勘定系などの既存システムに対し、取引許可の確認を行う。この場合には、既存システムに、手ぶら出金であること、口座番号、金額等を送信する(S4)。既存システムは、取引許可確認を受信すると、元帳を確認し、残高が出金金額より多くあるか等を確認する。確認結果がOKである場合、認証サーバ/クラウドは、業務端末に、取引を許可する旨の取引許可応答を送信する(S5)。業務端末は、取引を許可する旨の取引許可応答を受信すると、表示画面に、現金計数画面を表示し、更に、現金/レシートを排出し、その旨の画面を表示する。ユーザが、現金とレシートを業務端末から抜き取ると、業務端末は、表示画面に、取引終了画面を表示して処理を終了する(S6)。
図13A及び図13Bは、通常時の初回の生体データ登録時のフロー図である。
始めに、ユーザが本人確認のために、身分証、その他の書類等を持参する。登録・管理端末の表示画面には、メニュー画面が表示される(S10)。ユーザが初回登録を選択し、パスフレーズを入力すると、登録・管理端末は、表示画面に、カード読み取り画面を表示する(S11)。ユーザが登録・管理端末に、キャッシュカード等のカードを挿入すると、登録・管理端末はカードデータを取得し、更に、ユーザから生体データを取得するための画面を表示する(S12)。ユーザは生体データの登録を行う。この場合、左右両手の生体データを取得するとしているので、右手と左手のそれぞれについて、登録・管理端末は、生体データを取得する(S13)。
登録・管理端末は、照合確認画面を表示し、確認のため、ユーザに再度生体データを入力させる(S14)。生体データの取得が終わると、登録・管理端末は、生体データ登録画面を表示し、既存システムに対し、顧客IDと口座の確認を行う(S15)。既存システムは、カード情報から、顧客IDと口座を検索し、顧客IDと口座の有無等の結果通知を登録・管理端末に送信する(S16)。登録・管理端末は、結果通知を受信すると、認証サーバ/クラウドに対し、顧客ID、カード情報、生体種別、生体データ、パスフレーズ、顔写真等を登録する(S17)。認証サーバ/クラウドは、二重登録がないか確認し、情報を登録して、登録が完了した旨を登録・管理端末に通知する(S18)。登録・管理端末は、表示画面に、生体データ登録完了画面を表示して、処理を終了する。
図14は、通常時の追加情報登録のフロー図である。
ユーザが本人確認のため、身分証、その他の書類等を持参する。登録・管理端末は、メニュー画面を表示する(S20)。ユーザが追加登録を選択すると、登録・管理端末は、カードの読み取り画面を表示する(S21)。ユーザが、キャッシュカード等の追加で登録するカードを挿入すると、登録・管理端末はカードデータを取得する(S22)。登録・管理端末は、照合画面を表示し、生体センサーに手をかざすなどして、生体照合確認を行う(S23)。登録・管理端末は、生体データを取得すると、取得した生体データで生体照合依頼を認証サーバ/クラウドに依頼する(S24)。認証サーバ/クラウドでは、登録済みの生体データと、受信した生体データとを照合し、照合結果を登録・管理端末に送信する(S25)。ここでは、正しく照合できたとする。すると、認証サーバ/クラウドは、登録・管理端末に、顧客ID等の情報を送信する。登録・管理端末は口座番号を確認し(S26)、既存システムに口座番号等を送信して、口座検索を行なわせる。この口座検索は、カード情報から検索する。そして、既存システムは、検索結果を登録・管理端末に送信する(S27)。検索結果通知は、顧客ID、口座の有無等を含む。口座が正しく見つかった場合には、登録・管理端末は、情報追加登録画面を表示する。登録・管理端末は、認証サーバ/クラウドに対し、顧客ID、追加カード情報を送信する(S28)。認証サーバ/クラウドは、二重登録がないか確認し、追加カード等の情報を登録して、登録が完了した旨を登録・管理端末に送信する(S29)。登録・管理端末は、情報追加登録完了画面を表示して、処理を終了する。
図15は、ネガティブ生体データを収集した場合の出金取引の例のフロー図である。なお、ここで、ネガティブ生体データとは、生体認証でNGとなる生体データのことである。
業務端末に取引選択画面が表示されている状態で、ユーザは、手ぶら出金を選択したとする。業務端末は、生体認証画面を表示する(S30)。ユーザは、生体センサーに手をかざすなどして、生体認証を行う(S31)。生体データを取得した業務端末は、認証サーバ/クラウドに対し、手ぶら出金であること、取得生体データなどを通知し、生体認証を依頼する(S32)。認証サーバ/クラウドは、受信した生体データとブラックリストの生体データとを照合する。ここでは、受信した生体データは、ブラックリストの生体データとは一致はしなかったとする。次に、認証サーバ/クラウドは、データベースにある通常の生体データと、受信した生体データとを照合する。ここでも、格納されていた生体データと受信した生体データとは一致しなかったとする。
すると、認証サーバ/クラウドは、照合NGリトライ回数等の閾値情報を確認する。つまり、生体照合が失敗に終わっているので、ユーザがリトライを何回したかを、閾値情報と比較する。ユーザが行ったリトライの回数が何れかの閾値情報より少ない場合、認証サーバ/クラウドは、業務端末に、生体認証がNGであったこと、及び、リトライ指示を送信する(S33)。業務端末は、生体認証画面に、リトライ画面を表示し、ユーザに生体認証のリトライを行わせる(S34)。ここで、フローは、(S31)の段階に戻る。ユーザの行ったリトライ回数が閾値情報より多い場合には、ネガティブ生体データを収集し、ブラックリストに登録する。そして、認証サーバ/クラウドは、業務端末に取引中止を指示する(S35)。業務端末は、生体認証不一致画面を表示し、取引終了画面を表示して、処理を終了する。
図16A及び図16Bは、受信生体データがブラックリストに一致するものがあった場合の、出金取引、カード挿入による本人確認の例のフロー図である。
業務端末が、取引選択画面を表示しているとする。ユーザが、手ぶら出金を選択し、業務端末が生体認証画面を表示する(S40)。ユーザが生体センサーに手をかざすなどして、生体認証をおこなう(S41)。業務端末は、認証サーバ/クラウドに対し、手ぶら出金であること、取得生体データを通知し、生体認証を依頼する(S42)。認証サーバ/クラウドは、受信した生体データとブラックリストの生体データとを照合する。ここでは、一致するものがあったとする。認証サーバ/クラウドは、アクション情報を確認し、カード挿入による本人確認を選択する。認証サーバ/クラウドは、業務端末に、後処理指示として、カード挿入による本人確認をするように指示する(S43)。後処理指示を受信した業務端末は、照合NG、カード挿入画面を表示する。カードが挿入されない場合には、業務端末は、取引終了画面を表示して、処理を終了する。カードが挿入された場合には、業務端末は、暗証番号入力画面を表示し、ユーザに暗証番号を入力させる(S44)。更に、業務端末は、金額入力画面を表示し、ユーザに金額を入力させる(S45)。金額が入力されると、業務端末は、既存システムに対し、手ぶら出金であること、口座番号、暗証番号、金額等を通知して、取引可能確認を行う(S46)。
既存システムは、暗証番号と口座を確認する。ここでは、確認結果は、OKであるとする。既存システムは、取引を許可する旨の取引許可応答を業務端末に送信する(S47)。業務端末は、取引許可応答を受信すると、現金計数画面を表示し、更に、現金/レシート排出画面を表示する。ユーザが、現金とレシートを抜き取ると、業務端末は、取引終了画面を表示する(S48)。取引が正常に行えたので、業務端末は、認証サーバ/クラウドに対し、該当するネガティブ生体データの管理IDを送信して、ネガティブ情報削除依頼を行う。認証サーバ/クラウドは、ネガティブ生体データを削除し、削除完了通知を業務端末に送信して、処理を終了する(S49)。
図17は、ネガティブ情報一致の場合の、出金取引、店員に通知して本人確認を行う例のフロー図である。
最初、業務端末が、取引選択画面を表示している状態で、ユーザが手ぶら出金を選択したとする(S50)。業務端末は、これに応答して、生体認証画面を表示する。ユーザは、生体センサーに手をかざすなどして、生体認証を行う(S51)。業務端末は、生体データを取得すると、手ぶら出金であること、取得生体データを、認証サーバ/クラウドに対し、通知し、生体認証依頼を行う(S52)。認証サーバ/クラウドは、受信した生体データとブラックリストの生体データとを照合する。この場合、一致するものがあったとする。次に、認証サーバ/クラウドは、アクション情報を確認し、店員に通知して本人確認を行うことを選択したとする。認証サーバ/クラウドは、業務端末に対し、店員に通知して本人確認を行うよう、後処理指示を行う(S53)。業務端末は、後処理指示を受信すると、アラームをならすなどして、店員に通知を行い、店員は、該当業務端末に出向く。
業務端末は、店員がやってくるまで照合NG店員待ち画面を表示する。店員が、該当業務端末まで来ると、店員が、ユーザの身分証明などを確認するなどして、本人確認を行う。本人確認ができない場合には、店員は、該当業務端末の本人確認NGのボタンを押すなどして、本人確認がNGであることを業務端末に入力する。業務端末は、本人確認がNGとなったことを受けて、取引終了画面を表示して、処理を終了する。本人確認がOKの場合には、店員は、本人確認がOKのボタンを押すなどして、本人確認がOKであることを業務端末に入力する(S54)。業務端末は、表示画面に、「再度、最初から取引を実施してください。」等のメッセージを表示する。そして、ユーザには取引を通常通り実行させる。そして、本人確認が取れたので、業務端末は、認証サーバ/クラウドに対し、該当するネガティブ生体データの管理IDを送信するなどして、ネガティブ情報の削除依頼を行う(S55)。認証サーバ/クラウドは、ネガティブ生体データを削除し、削除完了通知を業務端末に送信する(S56)。業務端末は、取引終了画面を表示して、処理を終了する。
図18は、ネガティブ情報一致の場合の、出金取引、窓口に誘導して本人確認する例のフロー図である。
最初、業務端末が取引選択画面を表示している状態で、ユーザが手ぶら出金を選択したとする(S60)。すると、業務端末は、表示画面に、生体認証画面を表示する。ユーザが、生体センサーに手をかざすなどして、生体認証を行うと(S61)、業務端末は、生体データを取得し、認証サーバ/クラウドに対し、手ぶら出金であること、及び取得生体データを通知する(S62)。認証サーバ/クラウドは、受信した生体データとブラックリストの生体データを照合する。ここで、一致が得られとする。そこで、認証サーバ/クラウドは、アクション情報を確認し、窓口に誘導して本人確認することを選択したとする。認証サーバ/クラウドは、業務端末に対し、窓口に誘導して本人確認すべきことを、後処理指示として指示する(S63)。
後処理指示を受信した業務端末は、照合NG、窓口誘導画面を表示し、取引終了画面を表示して、処理を終了する。ユーザは、窓口誘導画面にしたがって窓口に行き、窓口において本人確認して、取引を行う。窓口での本人確認は、ICカード及び暗証番号の照合や、身分証明の確認などにより行う。
本人確認がOKの場合、窓口にある登録・管理端末から、該当するネガティブ生体データの管理IDなどを、認証サーバ/クラウドに通知して、ネガティブ情報削除依頼を行う(S64)。認証サーバ/クラウドは、ネガティブ生体データを削除し、削除完了通知を登録・管理端末に行う(S65)。以降、該当ユーザは、窓口端末や業務端末での取引が可能となる。
図19A及び図19Bは、ネガティブ情報一致の場合の、出金取引、パスフレーズ入力による本人確認の例のフロー図である。
最初、業務端末が取引選択画面を表示している状態で、ユーザが手ぶら出金を選択すると、業務端末は、生体認証画面を表示する(S70)。ユーザが、生体センターに手をかざすなどして、生体認証を行うと(S71)、業務端末は、生体データを取得する。業務端末は、認証サーバ/クラウドに対し、手ぶら出金であること、及び、取得した生体データを通知して、生体認証依頼を行う(S72)。認証サーバ/クラウドは、受信した生体データと、ブラックリストにある生体データとを照合する。ここで、生体データの一致があったとする。認証サーバ/クラウドは、アクション情報を確認し、パスフレーズによる本人確認を選択するとする。認証サーバ/クラウドは、業務端末に対し、パスフレーズによる本人確認を行う旨の後処理指示を行う(S73)。
後処理指示を受信した業務端末は、照合NG、パスフレーズ入力画面を表示する。ユーザが、登録時のパスフレーズを入力すると(S74)、業務端末は、このパスフレーズを認証サーバ/クラウドに通知し、パスフレーズ確認依頼を行う(S75)。認証サーバ/クラウドは、登録パスフレーズと、受信パスフレーズとの照合を行う。ここで、照合結果がOKであったとする。認証サーバ/クラウドは、照合結果がOKであること、該当者の顧客ID,及び、口座情報等を業務端末に送信して、照合結果通知を行う(S76)。
照合結果通知を受信した業務端末は、取引口座選択画面を表示する。ユーザが口座を選択すると(S77)、入力口座が登録口座と一致するか否かを判定し、一致しない場合には、取引終了画面を表示して処理を終了する。入力口座が登録口座と一致する場合には、業務端末は、金額入力画面を表示する。ユーザが金額を入力すると(S78)、業務端末は、既存システムに対し、手ぶら出金であること、顧客ID、口座情報、金額等を送信し、取引許可確認を行う(S79)。 既存システムは、元帳を確認し、残高が取引金額以上であるかを確認する。残高が取引金額以上である場合には、取引を許可する取引許可応答を業務端末に送信する(S80)。取引許可応答を受信した業務端末は、現金計数画面を表示し、現金/レシート排出画面を表示する。ユーザが、現金とレシートを抜き取ると(S81)、取引終了画面を表示する。そして、業務端末は、認証サーバ/クラウドに対し、該当するネガティブ生体データの管理IDを通知して、ネガティブ情報削除依頼を行う(S82)。認証サーバ/クラウドは、依頼のあったネガティブ生体情報を削除し、削除完了通知を業務端末に送信する(S83)。業務端末は、削除完了通知を受信したら、処理を終了する。
図20A及び図20Bは、ネガティブ情報一致の際の、出金取引、顔認証による本人確認の例のフロー図である。
最初、業務端末が取引選択画面を表示している状態で、手ぶら出金を選択すると、生体認証画面が表示される(S90)。ユーザが、生体センサーに手をかざすなどして、生体認証が行われると(S91)、業務端末は、手ぶら出金であること、及び、取得生体データを、認証サーバ/クラウドに通知して、生体認証確認を依頼する(S92)。認証サーバ/クラウドは、受信した生体データと、ブラックリストにある生体データとを照合する。ここで、照合の結果、一致するものがあるとする。認証サーバ/クラウドは、アクション情報を確認し、顔認証による本人確認を選択したとする。認証サーバ/クラウドは、業務端末に対し、顔認証による本人確認をすべき旨を、後処理指示として指示する(S93)。
後処理指示を受信した業務端末は、照合NG、顔認証画面を表示し、ユーザの顔を撮影する(S94)。業務端末は、認証サーバ/クラウドに対し、撮影した顔データを送信し、顔認証依頼を行う。
認証サーバ/クラウドは、登録顔データと受信した顔データとを照合する。ここでは、一致が得られたとする。すると、認証サーバ/クラウドは、業務端末に対し、認証がOKであること、該当者顧客ID,口座情報等を通知し、照合結果通知を行う(S95)。照合結果通知を受信した業務端末は、取引口座選択画面を表示し、ユーザに口座選択を行わせる(S96)。ユーザが入力した口座と登録口座との一致が得られない場合、取引終了画面を表示して、処理を終了する。一致が得られた場合、業務端末は、金額入力画面を表示する。ユーザが金額を入力すると(S97)、業務端末は、既存システムに対し、手ぶら出金であること、顧客ID,口座情報、金額等を通知し、取引許可確認を行う(S98)。既存システムでは、元帳を確認し、残高が取引金額以上であるかを判断する。残高が取引金額以上である場合には、既存システムは、取引を許可する取引許可応答を、業務端末に送信する(S99)。
取引許可応答を受信した業務端末は、現金計数画面を表示し、現金/レシート排出画面を表示する。ユーザが、現金とレシートを抜き取ると(S100)、業務端末は、取引終了画面を表示する。そして、業務端末は、該当するネガティブ生体データの管理IDを、認証サーバ/クラウドに通知し、ネガティブ情報削除依頼を行う(S101)。認証サーバ/クラウドは、ネガティブ生体データを削除し、削除完了通知を業務端末に送信する(S102)。削除完了通知を受信した業務端末は、処理を終了する。
なお、上記フロー図においては、金融機関における生体認証システムであって、手の静脈を生体データとして用いる場合を示したが、本発明は、これには限定されず、店舗システムや医療機関、ホテル等のシステムにおいても適用でき、生体データも、手の静脈に限られず、顔、指紋、虹彩、嘗紋などの様々な生体データを使用可能である。また、生体認証システムが提供するサービスも、出金取引のみではなく、認証が必要な様々な取引が可能である。
特に、手の静脈認証に加え、顔に代表される手のひら静脈以外の生体認証とのマルチ生体認証として、不正判別(ブラックリスト化)するとより認証精度を上げることができる。
以上述べたように、不正な取引を行う可能性が高い生体データをブラックリスト化しておき、認証のための生体データの照合をする前に、ブラックリストと入力された生体データとを照合し、一致する場合には、本人確認手続を別途行うことで、生体データのみの認証による取引おいて、不正取引が起こりづらくすることができる。
図21は、業務端末(生体センサー搭載端末)、登録・管理端末、及び、認証サーバ/クラウドに共通のコンピュータのハードウェア構成を示す図である。
コンピュータ210は、命令を実行するCPU211、BIOSなどの基本プログラムを格納するROM212、命令を実行可能なように展開するRAM213、ネットワーク215を介してコンピュータ210を他のコンピュータに接続する通信インタフェース214、本実施形態の処理を実行するためのプログラムやデータベースを格納する記憶装置216、同じくプログラムやデータベースを格納する可搬記録媒体218にアクセスするための媒体ドライブ217、及び、コンピュータ210とユーザの間で情報の入力及び出力を行う入出力装置219を備える。これらは、バス220によって通信可能なように接続される。
記憶装置216は、ハードディスクや固体メモリなどの、大容量の主記憶装置である。可搬記録媒体218は、DVD、CDなどの光ディスクや、フロッピーディスクなどの磁気ディスク、磁気テープなどの持ち運び可能な記録媒体などである。可搬記録媒体218は、媒体ドライブ217に挿入され、アクセスされることで、CPU211から読み書きされる。
入出力装置219は、コンピュータ210へ、ユーザから情報を入力したり、コンピュータ210の処理結果をユーザへ提示したりする装置である。入出力装置219の例は、キーボード、マウス、ディスプレイなどの通常のコンピュータが備える入出力装置のほか、生体センサーユニット、ICカードリーダ/ライタ、磁気カードリーダ/ライタ、テンキーユニット、現金リサイクルユニットなどがある。
記憶装置216には、さまざまなデータやプログラムが格納されるが、業務アプリケーションや、管理アプリケーション、生体認証アプリケーションなどのプログラム、生体データ、付随情報、照合履歴、閾値情報、ネガティブ生体データ、アクション情報などのデータを格納する。
10 業務アプリケーション
11、21 ミドルウェア
12−1、22−1 生体認証制御部
12−2、22−2 生体センサーユニット
13−1、23−1 ICカード制御部
13−2、23−2 ICカードリーダ/ライタ
14−1、24−1 磁気カード制御部
14−2、24−2 磁気カードリーダ/ライタ
15−1、25−1 テンキー制御部
15−2、25−2 テンキーユニット
16−1 現金制御部
16−2 現金リサイクルユニット
20 管理アプリケーション
30 生体認証アプリケーション
31 登録部
32 検索/照合部
33 履歴管理部
34 閾値管理部
35 不正リスク管理部
36 生体認証制御部
37 生体データ
38 付随情報
39 照合履歴
40 閾値情報
41 ネガティブ生体データ
42 アクション情報
210 コンピュータ
211 CPU
212 ROM
213 RAM
214 通信インタフェース
215 ネットワーク
216 記憶装置
217 媒体ドライブ
218 可搬記録媒体
219 入出力装置
220 バス

Claims (9)

  1. ユーザとの取引を行うサービスを提供可能であって且つ前記取引時に前記ユーザの生体データを取得可能な無人取引端末とネットワークで接続された生体認証システムであって、
    生体認証が失敗した生体データのうち所定の基準を満たす生体データを登録するブラックリストと、認証を行うための生体データを格納する生体データデータベースとを格納する記憶部と、
    前記無人取引端末において生体データのみの認証に基づく取引が前記ユーザによって選択された場合該認証のために前記無人取引端末で取得された生体データと前記生体データデータベースに格納されている生体データとを照合する前に、前記取得された生体データと前記ブラックリストに登録されている生体データとを照合する照合部と、
    前記照合部により、前記取得された生体データと前記ブラックリストに登録されている生体データとの照合一致があった場合には、前記照合一致があったユーザについて所定の本人確認手続を行うことを指示する画面を前記無人取引端末に表示させる制御部と、
    を備える生体認証システム。
  2. 前記所定の基準は、前記無人取引端末で取得された同一の生体データについて、生体データのみの認証に基づく取引に失敗した回数、或いは、前記生体データデータベースに格納されている生体データとの照合で不一致となった回数又は該不一致後の認証のリトライ回数、所定の閾値を超えることである、請求項1に記載の生体認証システム。
  3. 前記所定の本人確認手続は、カードを前記無人取引端末に挿入して得られたカード情報に基づく本人確認手続である、請求項1に記載の生体認証システム。
  4. 前記所定の本人確認手続は、少なくとも店員による本人確認または窓口における本人確認のいずれか一つである、請求項1に記載の生体認証システム。
  5. 前記所定の本人確認手続は、パスフレーズの前記無人取引端末への入力による本人確認手続である、請求項1に記載の生体認証システム。
  6. 前記所定の本人確認手続は、前記無人取引端末を介したマルチ生体認証による本人確認手続である、請求項1に記載の生体認証システム。
  7. 前記所定の本人確認手続で、本人確認が取れなかった場合には、取引を拒絶する、請求項1に記載の生体認証システム。
  8. 前記無人取引端末は、金融機関の店舗におけるATM、窓口端末、渉外端末、及び、流通店舗におけるPOS端末、モバイルPOS端末、キオスク端末、及び、ホテルにおける受付・清算機、及び、医療機関における診察受付機、からなるグループから選択される、請求項1に記載の生体認証システム。
  9. ユーザとの取引を行うサービスを提供可能であって且つ前記取引時に前記ユーザの生体データを取得可能な無人取引端末とネットワークで接続されたコンピュータが実行する生体認証方法であって、
    生体認証が失敗した生体データのうち所定の基準を満たす生体データを登録するブラックリストと、認証を行うための生体データを格納する生体データデータベースとを格納する記憶部を参照し、
    前記無人取引端末において生体データのみの認証に基づく取引が前記ユーザによって選択された場合該認証のために前記無人取引端末で取得された生体データと前記生体データデータベースに格納されている生体データとを照合する前に、前記取得された生体データと前記ブラックリストに登録されている生体データとを照合する照合部を参照し、前記取得された生体データと前記ブラックリストに登録されている生体データとの照合一致があった場合には、前記照合一致があったユーザについて所定の本人確認手続を行うことを指示する画面を前記無人取引端末に表示させる
    生体認証方法。
JP2017012450A 2017-01-26 2017-01-26 生体認証システム及び生体認証方法 Active JP6712551B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017012450A JP6712551B2 (ja) 2017-01-26 2017-01-26 生体認証システム及び生体認証方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017012450A JP6712551B2 (ja) 2017-01-26 2017-01-26 生体認証システム及び生体認証方法

Publications (2)

Publication Number Publication Date
JP2018120483A JP2018120483A (ja) 2018-08-02
JP6712551B2 true JP6712551B2 (ja) 2020-06-24

Family

ID=63043912

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017012450A Active JP6712551B2 (ja) 2017-01-26 2017-01-26 生体認証システム及び生体認証方法

Country Status (1)

Country Link
JP (1) JP6712551B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7375602B2 (ja) * 2020-02-17 2023-11-08 富士通株式会社 情報処理プログラム、装置、及び方法
WO2022137954A1 (ja) * 2020-12-23 2022-06-30 日本電気株式会社 認証サーバ、認証システム、認証サーバの制御方法及び記憶媒体

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3670062B2 (ja) * 1995-10-11 2005-07-13 沖電気工業株式会社 個人識別システムおよび個人識別方法
JP2006260482A (ja) * 2005-03-18 2006-09-28 Fujitsu Ltd レンタル認証システム
JP5679567B2 (ja) * 2011-03-31 2015-03-04 西日本電信電話株式会社 認証支援装置、認証支援方法
JP5852870B2 (ja) * 2011-12-09 2016-02-03 株式会社日立製作所 生体認証システム

Also Published As

Publication number Publication date
JP2018120483A (ja) 2018-08-02

Similar Documents

Publication Publication Date Title
US11263691B2 (en) System and method for secure transactions at a mobile device
KR100848998B1 (ko) 영업점 시스템에서의 거래 제휴 방법
Al Imran et al. OTP based cardless transction using ATM
JP2020030669A (ja) 承認端末、決済システム及び決済方法
JP6712551B2 (ja) 生体認証システム及び生体認証方法
JP2006092491A (ja) 本人認証装置、本人認証システム、本人認証方法および本人認証プログラム
JP2010049387A (ja) 自動取引システム、サービス管理サーバ、自動取引装置および自動取引方法
JP6790588B2 (ja) 自動取引装置、自動取引システム及び自動取引プログラム
JP4999288B2 (ja) 自動取引装置
WO2021246072A1 (ja) 処理装置、処理方法及びプログラム
JP4952305B2 (ja) 本人確認システム
JP2007179303A (ja) 自動取引システム、装置、及び、方法
RU2479030C2 (ru) Система и способ контроля электронных финансовых операций
JP2021144657A (ja) 情報収集支援プログラム、情報収集支援方法および情報処理装置
JP6907928B2 (ja) 情報処理装置および認証システム
WO2019117011A1 (ja) 端末装置、現金自動預払機、振込処理方法、プログラム
JP2005056157A (ja) カード認証システム、サーバ装置、端末装置、方法、プログラム、及び記録媒体
JP2017049976A (ja) 多機能カード
JP5217450B2 (ja) 自動取引システムおよび自動取引装置
JP5141102B2 (ja) 自動取引装置及び自動取引システム
KR101240730B1 (ko) 아동 정보를 제공하는 금융 자동화 기기 및 이를 이용한아동 정보 제공 방법
JP7494681B2 (ja) 取引装置及び取引プログラム
JP2002149969A (ja) バンキングシステム
JP2011198014A (ja) 自動取引システム、および取引媒体回収方法
JP2006099313A (ja) 取引システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190308

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200122

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200128

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200309

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20200309

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200526

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200601

R150 Certificate of patent or registration of utility model

Ref document number: 6712551

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150