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

Description

本発明は、生体認証システム及び生体認証方法に関する。

現状、サーバ認証（１：Ｎ認証）時は、生体ＰＩＮ（生年月日、電話番号等）と口座暗証番号を入力しているため、他人がなりすます可能性は低い。利便性の観点から、生体ＰＩＮや口座暗証番号の入力も無くしたいとのニーズ（生体データのみの照合で取引を可能にする手ぶら決済）もあり、その際の不正検知方法を考える必要がある。ここで、生体データとは、主に、手のひらの静脈パターンを念頭に置くが、他の生体データでも良い。

従来、金融機関での生体認証は、ＩＣキャッシュカード内に生体データを格納し、ＡＴＭ等において読み取ったデータとＩＣカード内の生体データとで１：１認証（Match On Card方式）を実施している。また、口座暗証番号も入力することで二要素認証でのセキュリティとなっている。

最近は、カードレスでのサーバやクラウド側での生体認証（１：Ｎ認証）を行うシステムが導入されてきている。その際にも、従来の口座の暗証番号と、生体認証用のＰＩＮ（生年月日や電話番号等）を入力している。

先行技術には、特許文献１のように、ＩＣカードによる生体認証が連続して失敗した場合、失敗回数が規定値に達するとそれ以降生体認証を利用不可とするものがある。また、特許文献２のように、特定人物の生体データを含むブラックリストが格納された顧客データベースを備え、生体データがブラックリストに含まれる特定人物の生体データと一致しないとき、特定人物への出金を許可するものがある。また、特許文献３のように、挟み込まれた画像を記録し、その画像をブラックリストに登録し、再度同じ画像を入力したときにリジェクトするものがある。

特開２００９−２０５４５０号公報 特開２００７−１８８２５８号公報 特開２００５−２０４６８１号公報

カードレスでの取引時、暗証番号や生体認証用ＰＩＮも入力せず、生体データのみでの認証の手ぶら決済の要望も出てきており、その際の不正検知方法が望まれている。つまり、暗証番号や生体認証ＰＩＮの入力をなしとすると、生体データのみの認証での取引となるため、生体データを登録していない人が不正にお金を引き出せてしまう可能性が発生しうる。

生体データの照合のみで認証を行い、取引を実施させる場合、生体データを登録していない人の生体データが、生体データを登録している人の生体データと照合一致する可能性がある。

例えば、照合装置の照合精度の誤差等に起因して、誤って、上記の生体データの照合が一致することが考えられる。誤って照合データが一致した場合、不正な取引（出金等）が可能となる。従って、該不正な取引を防止することが必要である。

そこで、本発明は、生体データの照合のみで行われる認証に基づく取引を実施する際の不正な取引を防止することを目的とする。

本発明の一側面による生体認証システムは、ユーザとの取引を行うサービスを提供可能であって且つ前記取引時に前記ユーザの生体データを取得可能な無人取引端末とネットワークで接続された生体認証システムであって、生体認証が失敗した生体データのうち所定の基準を満たす生体データを登録するブラックリストと、認証を行うための生体データを格納する生体データデータベースとを格納する記憶部と、前記無人取引端末において生体データのみの認証に基づく取引が前記ユーザによって選択された場合、該認証のために前記無人取引端末で取得された生体データと前記生体データデータベースに格納されている生体データとを照合する前に、前記取得された生体データと前記ブラックリストに登録されている生体データとを照合する照合部と、前記照合部により、前記取得された生体データと前記ブラックリストに登録されている生体データとの照合一致があった場合には、前記照合一致があったユーザについて所定の本人確認手続を行うことを指示する画面を前記無人取引端末に表示させる制御部と、を備える。

本発明の他の側面による生体認証方法は、ユーザとの取引を行うサービスを提供可能であって且つ前記取引時に前記ユーザの生体データを取得可能な無人取引端末とネットワークで接続されたコンピュータが実行する生体認証方法であって、
生体認証が失敗した生体データのうち所定の基準を満たす生体データを登録するブラックリストと、認証を行うための生体データを格納する生体データデータベースとを格納する記憶部を参照し、
前記無人取引端末において生体データのみの認証に基づく取引が前記ユーザによって選択された場合、該認証のために前記無人取引端末で取得された生体データと前記生体データデータベースに格納されている生体データとを照合する前に、前記取得された生体データと前記ブラックリストに登録されている生体データとを照合する照合部を参照し、前記取得された生体データと前記ブラックリストに登録されている生体データとの照合一致があった場合には、前記照合一致があったユーザについて所定の本人確認手続を行うことを指示する画面を前記無人取引端末に表示させる。

本発明の実施形態によれば、生体データの照合のみで行われる認証に基づく取引を実施する際の不正な取引を防止することができる。

本発明の実施形態における生体認証システムの概要を示す図である。 本実施形態の生体認証システムの例の概要を更に説明する図である。 業務端末のブロック図である。 登録・管理端末のブロック図である。 認証サーバ／クラウドのブロック図である。 認証サーバ／クラウドのデータベースに格納される各種データの例（その１）を示す図である。 認証サーバ／クラウドのデータベースに格納される各種データの例（その２）を示す図である。 認証サーバ／クラウドのデータベースに格納される各種データの例（その３）を示す図である。 認証サーバ／クラウドのデータベースに格納される各種データの例（その４）を示す図である。 認証サーバ／クラウドのデータベースに格納される各種データの例（その５）を示す図である。 認証サーバ／クラウドのデータベースに格納される各種データの例（その６）を示す図である。 本実施形態の処理のフロー図（その１）である。 本実施形態の処理のフロー図（その２）である。 本実施形態の処理のフロー図（その３）である。 本実施形態の処理のフロー図（その４）である。 本実施形態の処理のフロー図（その５）である。 本実施形態の処理のフロー図（その６）である。 本実施形態の処理のフロー図（その７）である。 本実施形態の処理のフロー図（その８）である。 本実施形態の処理のフロー図（その９）である。 本実施形態の処理のフロー図（その１０）である。 本実施形態の処理のフロー図（その１１）である。 本実施形態の処理のフロー図（その１２）である。 本実施形態の処理のフロー図（その１３）である。 業務端末（生体センサー搭載端末）、登録・管理端末、及び、生体認証サーバ／クラウドに共通のコンピュータのハードウェア構成を示す図である。

本発明の実施形態においては、生体認証において不正の可能性のある（照合ＮＧが多い）場合、生体データを取集/保持し、ブラックリスト化しておき、次回以降の認証において、通常の生体データとの突き合わせ前に、ブラックリストの生体データと突き合わせすることで不正な可能性がある取引を認識し、本人確認等の確認を促すことで被害を低減させる。

以上の構成により、照合ＮＧが一定期間（1取引、1日、1か月等）で連続した場合など、所定の閾値を超過した際に、不正アクセスの可能性を検知し、カード等での本人確認を実施したり、一時的に該当口座を凍結させたりし、被害を拡大させないものである。なお、各種閾値情報はサービス事業者のセキュリティポリシーに応じて設定される。

図１は、本発明の実施形態における生体認証システムの概要を示す図である。

本実施形態の生体認証システムは、ＡＴＭ（Automated Teller Machine）やキオスク端末などの無人取引装置（業務端末：主に、銀行、保険、証券、クレジット等の金融端末）を含み、サーバ認証タイプのシステムで、生体認証のみで取引を行えるサービスを行うシステムである。

本実施形態の生体認証システムの生体センサー搭載端末は、生体センサーを搭載した各種業務端末であり、手のひらの静脈などを取得する生体センサーを搭載し、認証サーバと通信を行える取引装置である。

銀行、保険会社、証券会社などの金融機関店舗の場合、上記取引装置は、ＡＴＭ、窓口端末、渉外端末などであってもよい。

百貨店、量販店、スーパー、専門店、ショッピングモールのサービスカウンタ、バックヤード等の流通店舗においては、上記取引装置は、ＰＯＳ（Point Of Sales system）端末、モバイルＰＯＳ端末、キオスク端末などであってもよい。その他、ホテルの受付・清算機、医療機関における診察受付機などが、上記取引装置であってもよい。

登録・管理端末は、生体データの登録／削除や照合履歴の参照などを行う、取引装置や認証サーバの情報を参照できる端末であり、ＰＣやモバイル端末等である。金融機関の場合、上記登録・管理端末は、サービスカウンタ、バックヤードなどに存在する管理端末であってもよい。

流通店舗の場合、上記登録・管理端末は、サービスカウンタやバックヤードなどに存在する管理端末であってもよい。その他、ホテルや医療機関などでは、各種サービス事業者店舗などに存在する管理端末などが上記登録・管理端末であってもよい。

認証サーバ／クラウドは、登録された生体データを保有し、取引時の読み取った生体データと照合を行うなど生体認証を行うサーバもしくはクラウドシステムである。

図１の例の場合、登録・管理端末と生体認証サーバ／クラウドとの間には、既存システムが存在する。金融機関においては、既存システムは、勘定系システム、情報系システムなどであてもよい。

流通店舗においては、既存システムは、販売／売上管理システム、決済管理システム、ポイント管理システムなどであってもよい。その他、ホテル、医療機関などにおいては、既存システムは、チェックイン管理システム、電子カルテシステムなどであってもよい。

なお、登録・管理端末は、生体認証サーバに直接アクセスしてもよいが、この既存システムを介して生体認証サーバ／クラウドにアクセスすることも可能である。

図２は、本実施形態の生体認証システムの例の概要を更に説明する図である。

図２（ａ）は、銀行の例であり、店舗のフロントにおいては、ＡＴＭ、窓口端末、登録端末が設けられる。登録端末は、生体データを登録するための端末である。店舗のバックエンドにおいては、ＡＴＭサーバ、営業店サーバ、管理端末が設けられる。これらは、ネットワーク（不図示）を介して、センターの勘定系システムや情報系システムにアクセスすると共に、認証クラウドにもアクセスする。なお、上記したように、認証クラウドへのアクセスは、センターの勘定系システムや情報系システムを介して行われてもよい。認証クラウドは、生体データや付随情報などを所定の記憶装置に格納する。

図２（ｂ）は、小売店の例であり、店舗のフロントには、ＰＯＳ端末、モバイルＰＯＳ端末、及び、登録端末などが設けられる。登録端末は、同様に、生体データを登録するための端末である。店舗のバックエンドには、店舗サーバ、クレジットサーバ、管理端末が設けられる。バックエンドは、ネットワークを介して、本部の業務管理システムや、クレジット、ポイントなどや決済処理を管理する決済管理システムにアクセスする。また、同様に、バックエンドからは、認証クラウドにアクセスする。なお、バックエンドから認証クラウドにアクセスする場合、該アクセスは、本部の業務管理システムや決済管理システムを介してなされても良い。認証クラウドの所定の記憶装置には、生体データや付随情報などが格納される。

図３は、業務端末のブロック図である。

業務端末では、業務アプリケーション１０が実行される。業務アプリケーション１０は、ミドルウェア１１上で動作する。ミドルウェア１１は、生体認証制御部１２−１、ＩＣカード制御部１３−１、磁気カード制御部１４−１、テンキー制御部１５−１、及び現金制御部１６−１等を含む。

生体認証制御部１２−１は、ドライバを介して生体センサーユニット１２−２を駆動して、生体データを取得する。ＩＣカード制御部１３−１は、ドライバを介して、ＩＣカードリーダ／ライタ１３−２を駆動する。磁気カード制御部１４−１は、ドライバを介して、磁気カードリーダ／ライタ１４−２を駆動する。テンキー制御部１５−１は、ドライバを介して、テンキーユニット１５−２を駆動する。現金制御部１６−１は、ドライバを介して現金リサイクルユニット１６−２を駆動する。

図４は、登録・管理端末のブロック図である。

登録・管理端末においては、管理アプリケーション２０が設けられている。管理アプリケーション２０は、ミドルウェア２１に搭載されている、生体認証制御部２２−１、ＩＣカード制御部２３−１、磁気カード制御部２４−１、テンキー制御部２５−１を駆動する。生体認証制御部２２−１は、ドライバを介して、生体センサーユニット２２−２を駆動する。ＩＣカード制御部２３−１は、ドライバを介して、ＩＣカードリーダ／ライタ２３−２を駆動する。磁気カード制御部２４−１は、ドライバを介して、磁気カードリーダ／ライタ２４−２を駆動する。テンキー制御部２５−１は、ドライバを介して、テンキーユニット２５−２を駆動する。

図５は、認証サーバ／クラウドのブロック図である。

認証サーバ／クラウドでは、生体認証アプリケーション３０が実行され、該生体認証アプリケーション３０は、登録部３１、検索／照合部３２、履歴管理部３３、閾値管理部３４、不正リスク管理部３５を制御する。

登録部３１は、生体データの登録を行う。検索／照合部３２は、生体データの照合を行う。履歴管理部３３は、認証履歴を管理する。閾値管理部３４は、不正を検出するための閾値を管理する。不正リスク管理部３５は、不正アクセスのあったと判断された情報を管理する。

生体認証制御部３６は、生体認証するために、業務端末から送信されてきた生体データとデータベースに格納されている生体データとの照合を行い、生体データを業務端末から入力したユーザを認証する。データベースには、生体データ３７、付随情報３８、照合履歴３９、閾値情報４０、ネガティブ生体データ４１、及びアクション情報４２が格納される。ここで、ネガティブ生体データ４１は、上記のブラックリストであり、認証を拒絶する生体データを格納する。アクション情報４２は、どのような照合結果のときに、どのようなアクションを行うかをリストアップした情報である。

図６〜図１１は、認証サーバ／クラウドのデータベースに格納される各種データの例を示す。

図６は、生体データの例である。図６の生体データには、顧客ＩＤ、登録日、生体種別、登録データ１〜Ｎ、登録パスフレーズ、登録顔データが格納される。生体種別は、例えば、「０１」が静脈、「０２」が顔、「０３」が指紋、「０４」が虹彩、「０５」が嘗紋などと規定されている。登録パスフレーズは、本人確認時に使用する任意のフレーズが登録される。登録顔データは、生体認証ＮＧ時の確認用顔写真を登録する。

図７は、付随情報の例である。付随情報には、顧客ＩＤと、カード情報１〜Ｎが登録される。図６の生体データと、図７の付随情報を用いると、顧客ＩＤをキーとして、生体データとカード情報が関連付けられ、ユーザがカード情報を入力しなくても、生体認証のみで、取引が可能になる。カード情報は、ＭＳ（magnetic strip)やＩＣ内の情報、券面情報などを示す。氏名、性別、年齢、住所地などの顧客の属性情報は、顧客ＩＤをキーとして、顧客マスター（既存システムのデータベース）から識別する。

図８は、照合履歴の例である。照合履歴には、図８（ａ）の総履歴と、図８（ｂ）の顧客単位の履歴とが設けられる。図８（ａ）の総履歴には、日付、時間、取引通番、取引種別、金額、顧客ＩＤ、取引場所、生体種別、照合結果、リトライ回数、ブラックリスト化の欄が設けられている。ブラックリスト化の欄は、リトライ回数が、例えば、所定回数（例えば、３回）以上になった場合に、その顧客の生体データをブラックリストに登録することを示す情報である。このブラックリスト化の欄に情報が書き込まれた顧客は、ブラックリストに登録されることになる。

図８（ｂ）の顧客単位の照合履歴では、顧客を特定する顧客ＩＤそれぞれに対し、日単位と月単位での取引回数、日単位と月単位での取引金額、日単位と月単位での取引ＮＧ回数、日単位と月単位での照合ＮＧ回数、日単位と月単位での平均照合ＮＧ回数が登録される。取引ＮＧ回数は、手ぶら取引単位でのＮＧ回数を示し、照合ＮＧ回数は、リトライ回数を含めた照合単位でのＮＧ回数を示す。これらのＮＧ回数が所定の基準を満たしたとき、その顧客はブラックリストに登録される。

図９は、閾値情報の例である。図９の閾値情報においては、照合ＮＧリトライ回数、連続照合ＮＧ間隔、日単位の照合ＮＧ回数、月単位の照合ＮＧ回数、日単位の平均照合ＮＧ回数、月単位の照合ＮＧ回数、日単位の取引金額、月単位の取引回数等が登録される。照合ＮＧリトライ回数は、サーバ側で実施する照合ＮＧ時のリトライ回数であり、端末側から照合ＮＧ通知が来た際に、再度、照合指示を出す回数である。連続照合ＮＧ間隔は、照合ＮＧ取引の間隔であり、照合ＮＧ後の再照合を許容する間隔である。日単位、月単位の照合ＮＧ回数は、１日、あるいは、１ヶ月での照合ＮＧ許容回数であり、照合ＮＧ回数の累積値の上限を表す。日単位、月単位での平均照合ＮＧ回数は、１日、あるいは、１ヶ月での平均の照合ＮＧ許容回数である、平均の照合ＮＧ回数の上限値を定める。日単位、月単位の取引金額は、１日、あるいは、１ヶ月での手ぶら取引可能金額を示す。

図１０は、アクション情報の例である。アクション情報は、生体データがブラックリストの生体データと一致した場合の後処理を規定する。アクションの例としては、カード挿入にて本人確認する（暗証番号入力を含む）、店員に通知して本人確認する（メールやメッセージ通知等）、窓口誘導（窓口での取引に誘導する）、生体データ登録者であるか否かの画面確認（パスフレーズ確認）、カメラ撮影（顔認証で本人確認）、及び、該当口座凍結（口座凍結に加え、保有者へ確認メールを通知する）などがある。これらは、どれを優先しても良く、また、相互に組み合わせて実行してもよい。さらに、アクション情報には、図１０の例以外の情報が含まれてもよい。

図１１は、ブラックリストの例である。図１１のブラックリストには、管理ＩＤ，収集日、収集時間、取引通番、生体種別、及び認証に失敗した生体データの登録データ１〜Ｎが登録される。生体種別の番号の例は、図６で説明したものと同じものを使うことができる。

図１２〜図２０Ｂは、本実施形態の処理のフロー図である。

図１２は、通常の場合の、出金取引の例である。最初、業務端末の表示画面に取引選択画面が表示される。ユーザが手ぶら出金を選択したとする。すると、業務端末の表示画面に、生体認証画面が表示される（S1)。ユーザが、例えば、生体センサーに手をかざと、生体データの照合が行われる。業務端末は、生体データを取得し、認証サーバ／クラウドに生体認証依頼を行う（S2)。より詳細には、業務端末は、認証サーバ／クラウドに、手ぶら出金、取得生体データを通知する。

認証サーバ／クラウドは、業務端末から送信されてきた生体データと、ブラックリストの生体データとの照合を行う。ここでは、照合一致がないものとする。

次に、ブラックリストではない生体データと送信されてきた生体データとを照合する。ここでは、照合一致があったとする。次に、認証サーバ／クラウドは、業務端末に、生体照合結果を通知する。ここでは、照合結果がＯＫであることと、該当者の口座情報等を業務端末に送信する（S3)。

この生体照合結果を受信した業務端末は、表示画面に、取引口座選択画面を表示する。ユーザが口座選択をすると、業務端末は、表示画面に、金額入力画面を表示する。ユーザが金額を入力すると、業務端末は、勘定系などの既存システムに対し、取引許可の確認を行う。この場合には、既存システムに、手ぶら出金であること、口座番号、金額等を送信する（S４)。既存システムは、取引許可確認を受信すると、元帳を確認し、残高が出金金額より多くあるか等を確認する。確認結果がＯＫである場合、認証サーバ／クラウドは、業務端末に、取引を許可する旨の取引許可応答を送信する（S5)。業務端末は、取引を許可する旨の取引許可応答を受信すると、表示画面に、現金計数画面を表示し、更に、現金／レシートを排出し、その旨の画面を表示する。ユーザが、現金とレシートを業務端末から抜き取ると、業務端末は、表示画面に、取引終了画面を表示して処理を終了する（S6)。

図１３Ａ及び図１３Ｂは、通常時の初回の生体データ登録時のフロー図である。

始めに、ユーザが本人確認のために、身分証、その他の書類等を持参する。登録・管理端末の表示画面には、メニュー画面が表示される（S10)。ユーザが初回登録を選択し、パスフレーズを入力すると、登録・管理端末は、表示画面に、カード読み取り画面を表示する（S11)。ユーザが登録・管理端末に、キャッシュカード等のカードを挿入すると、登録・管理端末はカードデータを取得し、更に、ユーザから生体データを取得するための画面を表示する（S12)。ユーザは生体データの登録を行う。この場合、左右両手の生体データを取得するとしているので、右手と左手のそれぞれについて、登録・管理端末は、生体データを取得する（S13)。

登録・管理端末は、照合確認画面を表示し、確認のため、ユーザに再度生体データを入力させる（S14)。生体データの取得が終わると、登録・管理端末は、生体データ登録画面を表示し、既存システムに対し、顧客ＩＤと口座の確認を行う（S15)。既存システムは、カード情報から、顧客ＩＤと口座を検索し、顧客ＩＤと口座の有無等の結果通知を登録・管理端末に送信する（S16)。登録・管理端末は、結果通知を受信すると、認証サーバ／クラウドに対し、顧客ＩＤ、カード情報、生体種別、生体データ、パスフレーズ、顔写真等を登録する（S17)。認証サーバ／クラウドは、二重登録がないか確認し、情報を登録して、登録が完了した旨を登録・管理端末に通知する(S18)。登録・管理端末は、表示画面に、生体データ登録完了画面を表示して、処理を終了する。

図１４は、通常時の追加情報登録のフロー図である。

ユーザが本人確認のため、身分証、その他の書類等を持参する。登録・管理端末は、メニュー画面を表示する(S20)。ユーザが追加登録を選択すると、登録・管理端末は、カードの読み取り画面を表示する(S21)。ユーザが、キャッシュカード等の追加で登録するカードを挿入すると、登録・管理端末はカードデータを取得する(S22)。登録・管理端末は、照合画面を表示し、生体センサーに手をかざすなどして、生体照合確認を行う(S23)。登録・管理端末は、生体データを取得すると、取得した生体データで生体照合依頼を認証サーバ／クラウドに依頼する(S24)。認証サーバ／クラウドでは、登録済みの生体データと、受信した生体データとを照合し、照合結果を登録・管理端末に送信する(S25)。ここでは、正しく照合できたとする。すると、認証サーバ／クラウドは、登録・管理端末に、顧客ＩＤ等の情報を送信する。登録・管理端末は口座番号を確認し(S26)、既存システムに口座番号等を送信して、口座検索を行なわせる。この口座検索は、カード情報から検索する。そして、既存システムは、検索結果を登録・管理端末に送信する(S27)。検索結果通知は、顧客ＩＤ、口座の有無等を含む。口座が正しく見つかった場合には、登録・管理端末は、情報追加登録画面を表示する。登録・管理端末は、認証サーバ／クラウドに対し、顧客ＩＤ、追加カード情報を送信する(S28)。認証サーバ／クラウドは、二重登録がないか確認し、追加カード等の情報を登録して、登録が完了した旨を登録・管理端末に送信する(S29)。登録・管理端末は、情報追加登録完了画面を表示して、処理を終了する。

図１５は、ネガティブ生体データを収集した場合の出金取引の例のフロー図である。なお、ここで、ネガティブ生体データとは、生体認証でＮＧとなる生体データのことである。

業務端末に取引選択画面が表示されている状態で、ユーザは、手ぶら出金を選択したとする。業務端末は、生体認証画面を表示する(S30)。ユーザは、生体センサーに手をかざすなどして、生体認証を行う(S31)。生体データを取得した業務端末は、認証サーバ／クラウドに対し、手ぶら出金であること、取得生体データなどを通知し、生体認証を依頼する(S32)。認証サーバ／クラウドは、受信した生体データとブラックリストの生体データとを照合する。ここでは、受信した生体データは、ブラックリストの生体データとは一致はしなかったとする。次に、認証サーバ／クラウドは、データベースにある通常の生体データと、受信した生体データとを照合する。ここでも、格納されていた生体データと受信した生体データとは一致しなかったとする。

すると、認証サーバ／クラウドは、照合ＮＧリトライ回数等の閾値情報を確認する。つまり、生体照合が失敗に終わっているので、ユーザがリトライを何回したかを、閾値情報と比較する。ユーザが行ったリトライの回数が何れかの閾値情報より少ない場合、認証サーバ／クラウドは、業務端末に、生体認証がＮＧであったこと、及び、リトライ指示を送信する(S33)。業務端末は、生体認証画面に、リトライ画面を表示し、ユーザに生体認証のリトライを行わせる(S34)。ここで、フローは、(S31)の段階に戻る。ユーザの行ったリトライ回数が閾値情報より多い場合には、ネガティブ生体データを収集し、ブラックリストに登録する。そして、認証サーバ／クラウドは、業務端末に取引中止を指示する(S35)。業務端末は、生体認証不一致画面を表示し、取引終了画面を表示して、処理を終了する。

図１６Ａ及び図１６Ｂは、受信生体データがブラックリストに一致するものがあった場合の、出金取引、カード挿入による本人確認の例のフロー図である。

業務端末が、取引選択画面を表示しているとする。ユーザが、手ぶら出金を選択し、業務端末が生体認証画面を表示する(S40)。ユーザが生体センサーに手をかざすなどして、生体認証をおこなう(S41)。業務端末は、認証サーバ／クラウドに対し、手ぶら出金であること、取得生体データを通知し、生体認証を依頼する(S42)。認証サーバ／クラウドは、受信した生体データとブラックリストの生体データとを照合する。ここでは、一致するものがあったとする。認証サーバ／クラウドは、アクション情報を確認し、カード挿入による本人確認を選択する。認証サーバ／クラウドは、業務端末に、後処理指示として、カード挿入による本人確認をするように指示する(S43)。後処理指示を受信した業務端末は、照合ＮＧ、カード挿入画面を表示する。カードが挿入されない場合には、業務端末は、取引終了画面を表示して、処理を終了する。カードが挿入された場合には、業務端末は、暗証番号入力画面を表示し、ユーザに暗証番号を入力させる(S44)。更に、業務端末は、金額入力画面を表示し、ユーザに金額を入力させる(S45)。金額が入力されると、業務端末は、既存システムに対し、手ぶら出金であること、口座番号、暗証番号、金額等を通知して、取引可能確認を行う(S46)。

既存システムは、暗証番号と口座を確認する。ここでは、確認結果は、ＯＫであるとする。既存システムは、取引を許可する旨の取引許可応答を業務端末に送信する(S47)。業務端末は、取引許可応答を受信すると、現金計数画面を表示し、更に、現金／レシート排出画面を表示する。ユーザが、現金とレシートを抜き取ると、業務端末は、取引終了画面を表示する(S48)。取引が正常に行えたので、業務端末は、認証サーバ／クラウドに対し、該当するネガティブ生体データの管理ＩＤを送信して、ネガティブ情報削除依頼を行う。認証サーバ／クラウドは、ネガティブ生体データを削除し、削除完了通知を業務端末に送信して、処理を終了する(S49)。

図１７は、ネガティブ情報一致の場合の、出金取引、店員に通知して本人確認を行う例のフロー図である。

最初、業務端末が、取引選択画面を表示している状態で、ユーザが手ぶら出金を選択したとする(S50)。業務端末は、これに応答して、生体認証画面を表示する。ユーザは、生体センサーに手をかざすなどして、生体認証を行う(S51)。業務端末は、生体データを取得すると、手ぶら出金であること、取得生体データを、認証サーバ／クラウドに対し、通知し、生体認証依頼を行う(S52)。認証サーバ／クラウドは、受信した生体データとブラックリストの生体データとを照合する。この場合、一致するものがあったとする。次に、認証サーバ／クラウドは、アクション情報を確認し、店員に通知して本人確認を行うことを選択したとする。認証サーバ／クラウドは、業務端末に対し、店員に通知して本人確認を行うよう、後処理指示を行う(S53)。業務端末は、後処理指示を受信すると、アラームをならすなどして、店員に通知を行い、店員は、該当業務端末に出向く。

業務端末は、店員がやってくるまで照合ＮＧ店員待ち画面を表示する。店員が、該当業務端末まで来ると、店員が、ユーザの身分証明などを確認するなどして、本人確認を行う。本人確認ができない場合には、店員は、該当業務端末の本人確認ＮＧのボタンを押すなどして、本人確認がＮＧであることを業務端末に入力する。業務端末は、本人確認がＮＧとなったことを受けて、取引終了画面を表示して、処理を終了する。本人確認がＯＫの場合には、店員は、本人確認がＯＫのボタンを押すなどして、本人確認がＯＫであることを業務端末に入力する(S54)。業務端末は、表示画面に、「再度、最初から取引を実施してください。」等のメッセージを表示する。そして、ユーザには取引を通常通り実行させる。そして、本人確認が取れたので、業務端末は、認証サーバ／クラウドに対し、該当するネガティブ生体データの管理ＩＤを送信するなどして、ネガティブ情報の削除依頼を行う(S55)。認証サーバ／クラウドは、ネガティブ生体データを削除し、削除完了通知を業務端末に送信する(S56)。業務端末は、取引終了画面を表示して、処理を終了する。

図１８は、ネガティブ情報一致の場合の、出金取引、窓口に誘導して本人確認する例のフロー図である。

最初、業務端末が取引選択画面を表示している状態で、ユーザが手ぶら出金を選択したとする(S60)。すると、業務端末は、表示画面に、生体認証画面を表示する。ユーザが、生体センサーに手をかざすなどして、生体認証を行うと(S61)、業務端末は、生体データを取得し、認証サーバ／クラウドに対し、手ぶら出金であること、及び取得生体データを通知する(S62)。認証サーバ／クラウドは、受信した生体データとブラックリストの生体データを照合する。ここで、一致が得られたとする。そこで、認証サーバ／クラウドは、アクション情報を確認し、窓口に誘導して本人確認することを選択したとする。認証サーバ／クラウドは、業務端末に対し、窓口に誘導して本人確認すべきことを、後処理指示として指示する(S63)。

後処理指示を受信した業務端末は、照合ＮＧ、窓口誘導画面を表示し、取引終了画面を表示して、処理を終了する。ユーザは、窓口誘導画面にしたがって窓口に行き、窓口において本人確認して、取引を行う。窓口での本人確認は、ＩＣカード及び暗証番号の照合や、身分証明の確認などにより行う。

本人確認がＯＫの場合、窓口にある登録・管理端末から、該当するネガティブ生体データの管理ＩＤなどを、認証サーバ／クラウドに通知して、ネガティブ情報削除依頼を行う(S64)。認証サーバ／クラウドは、ネガティブ生体データを削除し、削除完了通知を登録・管理端末に行う(S65)。以降、該当ユーザは、窓口端末や業務端末での取引が可能となる。

図１９Ａ及び図１９Ｂは、ネガティブ情報一致の場合の、出金取引、パスフレーズ入力による本人確認の例のフロー図である。

最初、業務端末が取引選択画面を表示している状態で、ユーザが手ぶら出金を選択すると、業務端末は、生体認証画面を表示する(S70)。ユーザが、生体センターに手をかざすなどして、生体認証を行うと(S71)、業務端末は、生体データを取得する。業務端末は、認証サーバ／クラウドに対し、手ぶら出金であること、及び、取得した生体データを通知して、生体認証依頼を行う(S72)。認証サーバ／クラウドは、受信した生体データと、ブラックリストにある生体データとを照合する。ここで、生体データの一致があったとする。認証サーバ／クラウドは、アクション情報を確認し、パスフレーズによる本人確認を選択するとする。認証サーバ／クラウドは、業務端末に対し、パスフレーズによる本人確認を行う旨の後処理指示を行う(S73)。

後処理指示を受信した業務端末は、照合ＮＧ、パスフレーズ入力画面を表示する。ユーザが、登録時のパスフレーズを入力すると(S74)、業務端末は、このパスフレーズを認証サーバ／クラウドに通知し、パスフレーズ確認依頼を行う(S75)。認証サーバ／クラウドは、登録パスフレーズと、受信パスフレーズとの照合を行う。ここで、照合結果がＯＫであったとする。認証サーバ／クラウドは、照合結果がＯＫであること、該当者の顧客ＩＤ，及び、口座情報等を業務端末に送信して、照合結果通知を行う(S76)。

照合結果通知を受信した業務端末は、取引口座選択画面を表示する。ユーザが口座を選択すると(S77)、入力口座が登録口座と一致するか否かを判定し、一致しない場合には、取引終了画面を表示して処理を終了する。入力口座が登録口座と一致する場合には、業務端末は、金額入力画面を表示する。ユーザが金額を入力すると(S78)、業務端末は、既存システムに対し、手ぶら出金であること、顧客ＩＤ、口座情報、金額等を送信し、取引許可確認を行う(S79)。 既存システムは、元帳を確認し、残高が取引金額以上であるかを確認する。残高が取引金額以上である場合には、取引を許可する取引許可応答を業務端末に送信する(S80)。取引許可応答を受信した業務端末は、現金計数画面を表示し、現金／レシート排出画面を表示する。ユーザが、現金とレシートを抜き取ると(S81)、取引終了画面を表示する。そして、業務端末は、認証サーバ／クラウドに対し、該当するネガティブ生体データの管理ＩＤを通知して、ネガティブ情報削除依頼を行う(S82)。認証サーバ／クラウドは、依頼のあったネガティブ生体情報を削除し、削除完了通知を業務端末に送信する(S83)。業務端末は、削除完了通知を受信したら、処理を終了する。

図２０Ａ及び図２０Ｂは、ネガティブ情報一致の際の、出金取引、顔認証による本人確認の例のフロー図である。

最初、業務端末が取引選択画面を表示している状態で、手ぶら出金を選択すると、生体認証画面が表示される(S90)。ユーザが、生体センサーに手をかざすなどして、生体認証が行われると(S91)、業務端末は、手ぶら出金であること、及び、取得生体データを、認証サーバ／クラウドに通知して、生体認証確認を依頼する(S92)。認証サーバ／クラウドは、受信した生体データと、ブラックリストにある生体データとを照合する。ここで、照合の結果、一致するものがあるとする。認証サーバ／クラウドは、アクション情報を確認し、顔認証による本人確認を選択したとする。認証サーバ／クラウドは、業務端末に対し、顔認証による本人確認をすべき旨を、後処理指示として指示する(S93)。

後処理指示を受信した業務端末は、照合ＮＧ、顔認証画面を表示し、ユーザの顔を撮影する(S94)。業務端末は、認証サーバ／クラウドに対し、撮影した顔データを送信し、顔認証依頼を行う。

認証サーバ／クラウドは、登録顔データと受信した顔データとを照合する。ここでは、一致が得られたとする。すると、認証サーバ／クラウドは、業務端末に対し、認証がＯＫであること、該当者顧客ＩＤ，口座情報等を通知し、照合結果通知を行う(S95)。照合結果通知を受信した業務端末は、取引口座選択画面を表示し、ユーザに口座選択を行わせる(S96)。ユーザが入力した口座と登録口座との一致が得られない場合、取引終了画面を表示して、処理を終了する。一致が得られた場合、業務端末は、金額入力画面を表示する。ユーザが金額を入力すると(S97)、業務端末は、既存システムに対し、手ぶら出金であること、顧客ＩＤ，口座情報、金額等を通知し、取引許可確認を行う(S98)。既存システムでは、元帳を確認し、残高が取引金額以上であるかを判断する。残高が取引金額以上である場合には、既存システムは、取引を許可する取引許可応答を、業務端末に送信する(S99)。

取引許可応答を受信した業務端末は、現金計数画面を表示し、現金／レシート排出画面を表示する。ユーザが、現金とレシートを抜き取ると(S100)、業務端末は、取引終了画面を表示する。そして、業務端末は、該当するネガティブ生体データの管理ＩＤを、認証サーバ／クラウドに通知し、ネガティブ情報削除依頼を行う(S101)。認証サーバ／クラウドは、ネガティブ生体データを削除し、削除完了通知を業務端末に送信する(S102)。削除完了通知を受信した業務端末は、処理を終了する。

なお、上記フロー図においては、金融機関における生体認証システムであって、手の静脈を生体データとして用いる場合を示したが、本発明は、これには限定されず、店舗システムや医療機関、ホテル等のシステムにおいても適用でき、生体データも、手の静脈に限られず、顔、指紋、虹彩、嘗紋などの様々な生体データを使用可能である。また、生体認証システムが提供するサービスも、出金取引のみではなく、認証が必要な様々な取引が可能である。

特に、手の静脈認証に加え、顔に代表される手のひら静脈以外の生体認証とのマルチ生体認証として、不正判別（ブラックリスト化）するとより認証精度を上げることができる。

以上述べたように、不正な取引を行う可能性が高い生体データをブラックリスト化しておき、認証のための生体データの照合をする前に、ブラックリストと入力された生体データとを照合し、一致する場合には、本人確認手続を別途行うことで、生体データのみの認証による取引おいて、不正取引が起こりづらくすることができる。

図２１は、業務端末（生体センサー搭載端末）、登録・管理端末、及び、認証サーバ／クラウドに共通のコンピュータのハードウェア構成を示す図である。

コンピュータ２１０は、命令を実行するＣＰＵ２１１、ＢＩＯＳなどの基本プログラムを格納するＲＯＭ２１２、命令を実行可能なように展開するＲＡＭ２１３、ネットワーク２１５を介してコンピュータ２１０を他のコンピュータに接続する通信インタフェース２１４、本実施形態の処理を実行するためのプログラムやデータベースを格納する記憶装置２１６、同じくプログラムやデータベースを格納する可搬記録媒体２１８にアクセスするための媒体ドライブ２１７、及び、コンピュータ２１０とユーザの間で情報の入力及び出力を行う入出力装置２１９を備える。これらは、バス２２０によって通信可能なように接続される。

記憶装置２１６は、ハードディスクや固体メモリなどの、大容量の主記憶装置である。可搬記録媒体２１８は、ＤＶＤ、ＣＤなどの光ディスクや、フロッピーディスクなどの磁気ディスク、磁気テープなどの持ち運び可能な記録媒体などである。可搬記録媒体２１８は、媒体ドライブ２１７に挿入され、アクセスされることで、ＣＰＵ２１１から読み書きされる。

入出力装置２１９は、コンピュータ２１０へ、ユーザから情報を入力したり、コンピュータ２１０の処理結果をユーザへ提示したりする装置である。入出力装置２１９の例は、キーボード、マウス、ディスプレイなどの通常のコンピュータが備える入出力装置のほか、生体センサーユニット、ＩＣカードリーダ／ライタ、磁気カードリーダ／ライタ、テンキーユニット、現金リサイクルユニットなどがある。

記憶装置２１６には、さまざまなデータやプログラムが格納されるが、業務アプリケーションや、管理アプリケーション、生体認証アプリケーションなどのプログラム、生体データ、付随情報、照合履歴、閾値情報、ネガティブ生体データ、アクション情報などのデータを格納する。

１０ 業務アプリケーション
１１、２１ ミドルウェア
１２−１、２２−１ 生体認証制御部
１２−２、２２−２ 生体センサーユニット
１３−１、２３−１ ＩＣカード制御部
１３−２、２３−２ ＩＣカードリーダ／ライタ
１４−１、２４−１ 磁気カード制御部
１４−２、２４−２ 磁気カードリーダ／ライタ
１５−１、２５−１ テンキー制御部
１５−２、２５−２ テンキーユニット
１６−１ 現金制御部
１６−２ 現金リサイクルユニット
２０ 管理アプリケーション
３０ 生体認証アプリケーション
３１ 登録部
３２ 検索／照合部
３３ 履歴管理部
３４ 閾値管理部
３５ 不正リスク管理部
３６ 生体認証制御部
３７ 生体データ
３８ 付随情報
３９ 照合履歴
４０ 閾値情報
４１ ネガティブ生体データ
４２ アクション情報
２１０ コンピュータ
２１１ ＣＰＵ
２１２ ＲＯＭ
２１３ ＲＡＭ
２１４ 通信インタフェース
２１５ ネットワーク
２１６ 記憶装置
２１７ 媒体ドライブ
２１８ 可搬記録媒体
２１９ 入出力装置
２２０ バス

Claims (9)

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