JP5940186B1 - 生体認証プラットフォームシステム、生体認証情報管理装置、生体認証情報管理方法、及び生体認証情報管理プログラム - Google Patents

Abstract

【課題】経済性、普及性、及び安全性を兼ね備えた生体認証サービスを提供する。【解決手段】生体認証ＰＦシステム３００は、複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する原本情報管理部３３１、複数のサービスから受信するユーザの生体情報及び原本情報管理部３３１が管理する原本対応情報に基づいて認証処理を実行する認証部３４１、複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて原本対応情報を登録する登録部３１４を備える。登録部３１４は、受信したユーザの生体情報及び原本情報管理部３３１に管理されている原本対応情報に基づいて、同一ユーザの同一の生体情報を原本対応情報として２重登録しない。【選択図】図７

Description

本発明は、生体認証プラットフォームシステム、生体認証情報管理装置、生体認証情報管理方法、及び生体認証情報管理プログラムに関する。

従前のＩＤ（例えば、ＩＣカードに登録されているＩＤ）とパスワード方式とによるセキュリティー方式では、盗難、成りすまし、情報漏洩等の被害が防げないケースが多く、その被害件数は年々増加傾向にある。加えて、今後は超高齢化社会に急速に向かっており、高齢化していく中で要介護者人口、認知症人口の増加が検討課題として示唆されている（厚生労働省 平成２６年６月１１日 第１０２回社会保障審議会介護給付分科会「認知症への対応について」）。

また、近年、生体認証システムは、技術の進歩により認識精度が向上し、銀行のＡＴＭ端末等において商用導入事例が多くなってきている。この生体認証システムは、ＩＣカードやパスワードのように忘れてしまうことが無く、偽造も困難であるという利点がある。例えば、特許文献１には、生体認証システムに関する技術が開示されている。

特開２０１１−１５４４１５号公報

セキュリティー被害の増大や超高齢化社会によるデジタルデバイド（情報格差）の増加を考慮すると、生体認証システムが社会のプラットフォームシステムとなる要望が急速に具体化してくると考えられる。しかしながら、現状の生体認証システムでは、企業等が提供するサービス毎にシステムが完結しており、単一目的指向の所謂サイロ型の個別最適化形態を呈している。そのため、社会システム全体を俯瞰すると、不経済であり、社会プラットフォームシステムとして普及させることの阻害要因となっている。また、さらに、個人同定情報としての生体認証用の原本情報が多重に散在してしまう状況が生じるため、安全性に課題がある。このように、現状の生体認証システムでは、普及の促進を図り、社会プラットフォームシステムとして認知され、安全に運用される状況を実現することが困難である。

本発明は、上記した事情に鑑みてなされたもので、経済性、普及性、及び安全性を兼ね備えた生体認証サービスを提供する生体認証プラットフォームシステム、生体認証情報管理装置、生体認証情報管理方法、及び生体認証情報管理プログラムを提供することを目的の一つとする。

本発明の一態様は、複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理部と、前記複数のサービスから受信するユーザの生体情報と、前記管理部が管理する前記原本対応情報とに基づいて、認証処理を実行する認証部と、前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記管理部が管理する前記原本対応情報を登録する登録部と、を備え、前記登録部は、受信したユーザの生体情報と、前記管理部に管理されている前記原本対応情報とに基づいて、同一ユーザの同一の生体情報を前記原本対応情報として２重登録しない、生体認証プラットフォームシステムである。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、受信した生体情報が、前記管理部に管理されている前記原本対応情報のいずれとも同一性がないと判定された場合には、受信したユーザの生体情報に基づく前記原本対応情報を登録し、受信した生体情報が、前記管理部が管理する前記原本対応情報のいずれかと同一性があると判定された場合には、受信したユーザの生体情報に基づく前記原本対応情報を登録しない。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、前記複数のサービスから受信するユーザの生体情報を取得するとともに、あるサービスから取得した生体情報を前記原本対応情報として登録した場合、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報として別のサービスから取得した場合でも、前記別のサービスから取得した生体情報を前記原本対応情報として登録しない。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、あるサービスから取得した生体情報を前記原本対応情報として登録してから予め定めた期間以上経過後に、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報としていずれかのサービスから取得した場合には、取得した生体情報を前記原本対応情報として再登録する。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、あるサービスから取得した生体情報を前記原本対応情報として登録した場合であって、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報としていずれかのサービスから取得した場合、取得した生体情報を該生体情報の種別に応じて前記原本対応情報として再登録する。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、前記管理部が管理する前記原本対応情報と、当該原本対応情報による前記認証処理の実行を許可するサービスを示す許可サービス情報とを関連付ける。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、前記ユーザのユーザ情報、生体情報、及び、前記許可サービス情報を取得し、前記ユーザ情報と当該ユーザの与信情報とを照合して、当該ユーザの生体情報に基づいて前記原本対応情報を登録し、当該原本対応情報と前記許可サービス情報を関連付ける。

また、本発明の一態様は、上記生体認証プラットフォームシステムにおいて、前記登録部は、前記ユーザのユーザ情報、生体情報、及び、前記許可サービス情報を取得し、前記ユーザ情報と当該ユーザの通信契約情報とを照合して、当該ユーザの生体情報に基づいて前記原本対応情報を登録し、当該原本対応情報と前記許可サービス情報を関連付ける。

また、本発明の一態様は、複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理部と、前記複数のサービスから受信するユーザの生体情報と、前記管理部が管理する前記原本対応情報とに基づいて、認証処理を実行する認証部と、前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記管理部が管理する前記原本対応情報を登録する登録部と、を備え、前記登録部は、受信したユーザの生体情報と、前記管理部に管理されている前記原本対応情報とに基づいて、同一ユーザの同一の生体情報を前記原本対応情報として２重登録しない、生体認証情報管理装置である。

また、本発明の一態様は、生体認証情報管理装置における生体認証情報管理方法であって、管理部が、複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理過程と、認証部が、前記複数のサービスから受信するユーザの生体情報と、前記管理部が管理する前記原本対応情報とに基づいて、認証処理を実行する認証過程と、登録部が、前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記管理部が管理する前記原本対応情報を登録するとともに、受信したユーザの生体情報と、前記管理部に管理されている前記原本対応情報とに基づいて、同一ユーザの同一の生体情報を前記原本対応情報として２重登録しない登録過程と、を有する生体認証情報管理方法である。

また、本発明の一態様は、生体認証情報管理装置としてのコンピュータに、複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理手順と、前記複数のサービスから受信するユーザの生体情報と、前記原本対応情報とに基づいて、認証処理を実行する認証手順と、前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記原本対応情報を登録するとともに、受信したユーザの生体情報と、前記原本対応情報とに基づいて、同一ユーザの同一の生体情報を前記原本対応情報として２重登録しない、登録手順と、を実行させるための生体認証情報管理プログラムである。

本発明によれば、経済性、普及性、及び安全性を兼ね備えた生体認証サービスを提供することができる。

本実施形態に係る生体認証ＰＦシステムの位置付けを説明する説明図。 本実施形態に係る生体認証ＰＦシステムの位置付けをより具体した説明図。 本実施形態に係る生体認証ＰＦシステムの利用事例を示す図。 本実施形態に係る生体認証ＰＦシステムの接続構成の特徴を説明する説明図。 本実施形態に係る生体認証ＰＦシステムの接続構成例を説明する説明図。 本実施形態に係る生体認証ＰＦシステムの構成の特徴を説明する説明図。 本実施形態に係る生体認証ＰＦシステムの構成の一例を示すブロック図。 ユーザ情報テーブルの一例を示す図。 原本情報テーブルの一例を示す図。 生体認証機能テーブルの一例を示す図。 生体認証原本情報の登録処理の一例を示す動作図。 生体認証処理における前半の処理の一例を示す動作図。 生体認証処理における後半の処理の一例を示す動作図。 認証処理のイメージ図である。 生体認証ＰＦシステムの独立性及び安全性を説明する説明図。 生体認証ＰＦシステムの利用シーンの概要を説明する第１の説明図。 認証処理の目的外の利用を禁止する例を説明する説明図。 認証処理の目的外の利用を禁止する他の例を説明する説明図。 利用目的に応じて認証処理の実行を許可するか否かを制御する処理の一例を示すフローチャート。 生体認証原本情報の２重登録禁止処理を説明する説明図。 生体認証原本情報の２重登録禁止処理の一例を示すフローチャート。 生体認証原本情報の管理方法を説明する説明図。 ２分割方式の分割断片化の一例を説明する説明図。 ３分割方式の分割断片化の一例を説明する説明図。 生体認証原本情報の３重化による高安全性について説明する説明図。 生体認証ＰＦシステムの利用シーンの概要を説明する第２の説明図。 原本登録時のなりすまし及び生体情報の差し替えの防止処理の流れを説明する説明図。

以下、図面を参照して、本発明の一実施の形態について説明する。
[生体認証プラットフォームシステムの概要]
本実施形態に係る生体認証プラットフォームシステムは、企業等が提供するサービス毎に完結するシステムではなく、複数のサービスで共用可能な社会プラットフォームシステムとして提供される。ここで、プラットフォームシステムとは、基盤的機能を備えた共用利用型のシステムのことである。プラットフォームシステムは、システム内では各種情報及び機能を共用利用できるが、当該システムに登録された登録者以外の他者や、当該システムに対応していない他のシステムから独立性を担保でき影響を受けないようにすることができる。また、プラットフォームシステムは、当該システムに対応した前置システムや上位システムから利用のための接続アクセスを受け、所定の機能やサービスを安定して提供することができる。例えば、このプラットフォームシステムは、ＩＣＴ（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）システムの１つとして構築されることがある。社会プラットフォームシステムは、複数の組織、企業、個人、団体、コミュニティ、自治体などが情報の共有やサービスの利用を提供可能な基盤的機能を備えたプラットフォームシステムであり、例えば「社会ＩＴ−ＰＦシステム（社会情報技術プラットフォームシステム）」が含まれる。

本実施形態に係る生体認証プラットフォームシステムは、社会プラットフォームシステムとして、複数のサービスにおいて生体情報の共用利用を行い、生体認証サービスを提供する。例えば、本実施形態に係る生体認証プラットフォームシステムは、以下のような特徴を有する。
（１）複数の企業等から共用可能とするため、生体認証機能の個別最適化指向から一元化指向へ、また単一目的指向から多目的指向へ変わることができ、経済性の向上が図れる（経済性及び多目的利用）。
（２）認証用の生体情報の原本に対応する原本対応情報を利用システム毎に持つ必要がなく、原本単一性の保証ができる。即ち、生体認証機能の一元化、多目的指向に変わることができ、原本単一性の保証の実現が図れる（原本単一性保証）。ここで、原本対応情報とは、原本となる生体情報のベア情報（例えば、コード化されていない画像情報）であってもよいし、原本となる生体情報がコード化された情報であってもよいし、原本となる生体情報と対応付けがされた他の情報に変換された情報であってもよい。以下の説明において、この原本対応情報のことを、「生体認証原本情報」、又は、単に「原本」もしくは「原本情報」ともいう。
（３）利用システムから分離独立したプラットフォームシステムであり、複層の安全施策を搭載し、原本保管の安全性を担保する（原本保管の安全性）。
（４）資本力の無い企業や組織体が、より安全なシステム運用に改善したい場合、本生体認証プラットフォームシステムと接続すれば、容易に生体認証機能の運用が実現できる。また、顔認証、指紋認証、静脈認証等認証種類を問わず、一元的に取り扱いが可能であり、社会普及性を備える（社会普及性）。なお、以下の説明において、生体認証プラットフォームシステムのことを、「生体認証ＰＦシステム」とも略して記述する。

図１は、本実施形態に係る生体認証ＰＦシステムの位置付けを説明する説明図である。この図では、ユーザ（利用者）の層と、個別サービスの層と、社会プラットフォームシステムの層とに分けて示している。個別サービスは、ユーザが利用する複数の組織、企業、個人、団体、コミュニティ、自治体などがそれぞれ提供するサービス（以下、「個別サービス」ともいう）である。例えば、個別サービスは、官公庁（国、地方公共団体等）、産業界（民間企業等）、学校（教育、研究機関等）、及びその他（個人、コミュニティ等）のそれぞれが提供する個別サービスに分けられる。本実施形態に係る生体認証ＰＦシステムは、社会プラットフォームシステムの一部の位置付けであり、各個別サービスを、同一とすることないしは同一と見なすことができる。例えば、生体認証ＰＦシステムでは、官公庁、産業界、学校、及びその他のいずれかに属する個別サービスのいずれに対しても同様に生体認証サービスを提供可能なように、各個別サービスから生体認証サービスを共用利用するために必要な機能（横通しの機能）等を有する。

なお、社会プラットフォームシステムは、広くは、社会ＩＴ−ＰＦシステム、社会行動システム、及び社会制度、の３つが揃い調和することにより、有用性を発揮するが、ここでいう生体認証ＰＦシステムの位置付けとなる社会プラットフォームシステムは、社会ＩＴ−ＰＦシステムのことを指す。例えば、ユーザが個別サービスを介して、生体認証原本情報の事前登録を社会ＩＴ−ＰＦシステム（生体認証ＰＦシステム）に対して行う機能が提供される。また、ユーザが個別サービスにおいて生体認証を行ったときに、そのユーザに対して社会ＩＴ−ＰＦシステム（生体認証ＰＦシステム）から個別サービスを介して認証結果を通知する機能が提供される。なお、プラットフォームシステムであるが故、ユーザとの間に個別サービスが存在するビジネスモデルである。言い換えると、プラットフォームシステムとエンドユーザの間に個別サービスが仲介してエンドユーザが利用するケースと、プラットフォームシステムを直接にエンドユーザが利用するケースとの両方がある（詳細は後述する）。

図２は、本実施形態に係る生体認証ＰＦシステムの位置付けをより具体的に示した説明図である。この図では、ユーザの層と、個別サービスの層と、プラットフォームの層と、ネットワークの層と、端末の層と、に分けて示している。ネットワークの層は、本構成における情報伝達の基盤（インフラ）となる通信ネットワークＮＷを示している。端末の層は、ユーザが利用する端末５０を示している。

プラットフォームの層は、ビジネス領域別のビジネスプラットフォームシステム２００（第１プラットフォームシステムの一例。以下、「ビジネスＰＦシステム２００」とも略して記述する。）が含まれるビジネスプラットフォームの層と、本実施形態に係る生体認証ＰＦシステム３００が含まれる生体認証プラットフォームの層と、の２層に更に分けられる。ビジネスＰＦシステム２００は、対象となる市場又は対象となる個別サービスに特化した必要なビジネスサービス機能を搭載する。一方、生体認証ＰＦシステム３００は、市場及び個別サービスに特化せず、汎用的な機能、所謂縁の下的な機能を搭載する。例えば、生体認証ＰＦシステム３００は、クラウドコンピューティングを利用して複数のコンピュータ装置の組合せにより一つの論理的なサーバ装置（生体認証情報管理装置の一例）として構成されている。なお、生体認証ＰＦシステム３００は、一つのコンピュータ装置により一つの論理的なサーバ装置（生体認証情報管理装置の一例）として構成されてもよい。

個別サービスの層は、各個別サービスの提供者から個別アプリケーションシステム１００（以下、「個別ＡＰシステム１００」とも略して記述する。）により提供される各個別サービスを示している。個別ＡＰシステム１００は、「医療、介護、及びヘルスケア（高齢者及び後期高齢者向け）」、「テーマパーク向け」、「教育機関向け」、「電子行政向け」、「ＩＴ操作者認証」、「ロボット向け」、「身元確認」、「日用品、食料品等の通販（高齢者及び後期高齢者向け）」等といったような、官公庁、産業界、学校、及びその他による個別サービスを提供する。

ユーザの層は、上述の個別サービスを利用するユーザを示しており、例えば、行政サービスを受ける方、介護を受ける方、医療を受ける方、高齢な方、ヘルスケアを受ける方、健康な方、学問を受ける方、身元不明な方、等様々である。なお、ユーザは、本実施形態に係る生体認証サービスを利用するために、生体認証ＰＦシステム３００に対してユーザ登録が必要であるため、以下では、生体認証ＰＦシステム３００を利用するユーザを「登録者」ともいうことがある。

生体認証ＰＦシステム３００からみると、ビジネスＰＦシステム２００も個別ＡＰシステム１００も、同様な上位層のシステムとして扱われ、差異はない。生体認証ＰＦシステム３００は、多種類の生体認証情報を一元的に取り扱うとともに、生体認証情報に関するオペレーションを担う。

図３は、本実施形態に係る生体認証ＰＦシステムの利用事例を示す図である。生体認証ＰＦシステム３００を利用可能な個別サービスは多岐に渡る。この図では、横軸が「官公利用（官公庁による利用）」又は「民間利用（民間企業による利用）」を示し、縦軸が「安全社会の追及」又は「便利な優しい社会の追及」を示しており、横軸及び縦軸のそれぞれに対応する位置に１１の利用事例とそれぞれの利用ケースとを示している。なお、これらの１１事例に限定されるものではなく、市場動向、サービスの進展、技術進展の相互作用等により、この他の数多くの個別サービスで生体認証ＰＦシステム３００を利用することができる。

図４は、本実施形態に係る生体認証ＰＦシステムの接続構成の特徴を説明する説明図である。例えば、「Ａ−１システム、Ａ−２システム、・・・Ａ−ｎシステム」、「Ｂ−１システム、Ｂ−２システム、・・・Ｂ−ｎシステム」、「Ｚ−１システム、Ｚ−２システム、・・・Ｚ−ｎシステム」（ｎは正の整数。なお、システムによってｎは異なってもよい。）が複数の個別サービスとしてあり、各個別サービスで生体認証を行う場合、従前では、個別サービス毎に、各生体認証原本情報を登録し各生体認証機能（顔認証機能、掌静脈認証機能など）を備える必要があった。本実施形態では、生体認証ＰＦシステム３００は、生体認証原本情報と各生体認証機能とを一元化して備え、各個別サービスに対して共通に生体認証サービスを提供する。つまり、本実施形態では、生体認証ＰＦシステム３００は、特定の人物の特定の生体認証原本情報について、利用する個別サービス（利用するシステム）が複数あった場合においても、各生体認証原本情報と各生体認証機能とを重複せずに一元化して管理することができる。また、本実施形態では、生体認証ＰＦシステム３００は、プラットフォームシステムとして生体認証を提供しているため、官公利用と民間利用との別や、便利性の追求と安全性の追及との別を問わず、多目的に利用することが出来る。

図５は、本実施形態に係る生体認証ＰＦシステムの接続構成例を説明する説明図である。例えば、生体認証ＰＦシステム３００は、プラットフォームシステムであるが故、縁の下の力持ち的な立場であり、ビジネスＰＦシステム２００と連携する。ビジネスＰＦシステム２００は、あるビジネス領域及びある市場の中で共用されるためのビジネス機能を担う。個別ＡＰシステム１００は、特定の企業が、ビジネスＰＦシステム２００の上で企業の事業目的遂行するための機能を担う。以下に接続構成例として、形態１、形態２、形態３の３つの例を説明する。

形態１では、生体認証ＰＦシステム３００は、通信ネットワークＮＷを介してビジネスＰＦシステム２００に接続し、さらに、通信ネットワークＮＷを介して個別ＡＰシステム１００に接続される。形態２では、生体認証ＰＦシステム３００は、通信ネットワークＮＷを介して個別ＡＰシステム１００に接続される。なお、形態１及び形態２のいずれの場合も、個別ＡＰシステム１００に通信ネットワークＮＷを介して接続される端末５０において、個別ＡＰシステム１００から提供される個別サービスがユーザに利用される（例えば、生体認証原本情報の登録、生体認証結果の通知等）。形態３では、生体認証ＰＦシステム３００は、通信ネットワークＮＷを介して直接にユーザの端末５０に接続される。この場合、端末５０には個別サービスを提供するためのアプリケーションプログラムが搭載されていることが前提になる。

端末５０は、ユーザ個人が所有する装置であってもよいし、個別ＡＰシステム１００の施設に設置されている装置であってもよい。また、端末５０は、認証の際の生体情報を入力可能な入力装置、生体認証原本情報を登録可能な登録装置、及び認証結果を表示する表示装置を含む構成である。なお、端末５０は、これら入力装置、登録装置、及び表示装置が一体となって構成された一つの装置であってもよいし、各々の装置が別体で構成された装置であってもよい。

図６は、本実施形態に係る生体認証ＰＦシステムの構成の特徴を説明する説明図である。生体認証ＰＦシステム３００は、認証サービスマネジメント機能部３１０と、ユーザマネジメント機能部３２０と、認証データマネジメント機能部３３０と、認証機能ライブラリ機能部３４０と、を備えている。
認証サービスマネジメント機能部３１０は、生体認証ＰＦシステム３００全体を管理する位置付けであり、ユーザマネジメント機能部３２０、認証データマネジメント機能部３３０、及び認証機能ライブラリ機能部３４０の動作を制御及び管理する。また、認証サービスマネジメント機能部３１０は、通信ネットワークＮＷを介してビジネスＰＦシステム２００、個別ＡＰシステム１００、又は端末５０に接続する通信インターフェースの機能を備えており、通信ネットワークＮＷを介して、ユーザの生体情報を受信したり、生体認証結果を送信したりする。通信インターフェースとしては、例えば、個別ＡＰシステム１００及びビジネスＰＦシステム２００との通信に用いるＡＰＩ(アプリケーションインタフェース）、生体情報の受け渡しに用いるＤＩ（データインタフェース）、エンドユーザの端末５０へ直接に通信授受を行う場合に用いるＵＩ（ユーザインタフェース）などについて必要最小限のインターフェースが規定される。但し、搭載される生体認証機能が持つインターフェースについて、変更をしないことを原則とする。言い換えると、規定対象外とするか、カプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）の手段をとるかのいずれかを採用する。

ユーザマネジメント機能部３２０は、生体認証ＰＦシステム３００に登録されたユーザ（即ち、登録者）の登録者情報として、個人情報（住所、氏名、年齢、性別、勤務先企業名等）、通信接続ＩＤ(ＩＰアドレス等)、契約情報、サービス情報等を管理する。認証データマネジメント機能部３３０は、登録された生体認証原本情報を複数の仕組みにより安全に管理する。認証機能ライブラリ機能部３４０は、各種の生体認証機能のベンダの製品をライブラリとして搭載し、認証リクエストの内容に応じて、ライブラリの中の該当する認証機能を選択する。この搭載される各種の生体認証機能は、生体認証ＰＦシステム３００で独自に用意して搭載されるものであってもよいが、生体認証機能の開発及び提供元の各ベンダの最新の機能が複数種類搭載されることにより、システムの汎用性、利便性、経済性、社会普及性、認証精度の向上等を図ることができる。

［生体認証ＰＦシステムの構成］
次に、図７を参照して、本実施形態に係る生体認証ＰＦシステム３００の具体的な構成について詳しく説明する。図７は、本実施形態に係る生体認証ＰＦシステム３００の構成の一例を示すブロック図である。図６で説明したように、生体認証ＰＦシステム３００は、認証サービスマネジメント機能部３１０と、ユーザマネジメント機能部３２０と、認証データマネジメント機能部３３０と、認証機能ライブラリ機能部３４０と、を備えている。

認証サービスマネジメント機能部３１０は、通信処理部３１１と、登録部３１４と、認証許可部３１５と、認証結果取得部３１６と、制御情報記憶部３１８と、を備えている。通信処理部３１１は、受信部３１２と、送信部３１３と、を備え、規定の通信インターフェースに従って、端末５０、個別ＡＰシステム１００、及びビジネスＰＦシステム２００と情報の送受信を行う。

例えば、受信部３１２は、複数の個別サービスのいずれかから生体認証ＰＦシステム３００を利用するためのユーザ登録情報を受信する。ユーザ登録情報には、ユーザの識別情報、ユーザの個人情報（住所、氏名、年齢、性別等）、その他ユーザに関連する情報が含まれる。また、受信部３１２は、生体認証原本情報の登録の際、及び生体認証を行う際に、複数の個別サービスのそれぞれから送信されるユーザの生体情報とそのユーザの識別情報とを受信する。また、受信部３１２は、個別サービスを提供する個別ＡＰシステム１００を示す情報（以下、「個別ＡＰｓｙｓＩＤ」ともいう）、及び複数の個別ＡＰシステム１００が接続されたビジネスＰＦシステム２００を示す情報（以下、「ビジネスＰＦｓｙｓＩＤ」ともいう）を受信する。なお、受信部３１２は、これらの情報を、端末５０、個別ＡＰシステム１００、又はビジネスＰＦシステム２００から受信する。送信部３１３は、受信部３１２が受信したユーザの生体情報に対する認証結果を送信する。例えば、送信部３１３は、認証処理を行ったユーザの生体情報を受信した端末５０、個別ＡＰシステム１００、又はビジネスＰＦシステム２００に、認証結果を送信する。

登録部３１４は、受信部３１２がユーザ登録情報を受信すると、当該ユーザ登録情報を取得してユーザマネジメント機能部３２０に受け渡す。例えば、登録部３１４は、取得したユーザ登録情報に不備があるか否かに基づいて登録許可判定を行い、登録許可したユーザ登録情報をユーザマネジメント機能部３２０に受け渡す。このユーザ登録情報は、ユーザマネジメント機能部３２０に記憶されて管理される。ユーザ登録情報には、ユーザの識別情報、個人情報等が含まれている。

また、登録部３１４は、受信部３１２が原本登録用のユーザの生体情報を受信すると、当該原本登録用生体情報を取得して認証データマネジメント機能部３３０に受け渡す。ここで、以下の説明において、原本登録用のユーザの生体情報を「原本登録用生体情報」ともいうこととする。これに対し、各個別サービスで生体認証をする際に入力される生体情報を「認証用生体情報」ともいうこととする。なお、原本登録用生体情報及び認証用生体情報のそれぞれには、ユーザの識別情報と、生体情報の種類を示す種別情報とが関連付けられている。

認証許可部３１５は、複数の個別サービスのそれぞれに対して、生体認証処理の実行を許可するか否かを制御する。例えば、生体認証ＰＦシステム３００では、ユーザ毎かつ生体認証の種類毎に生体認証処理の利用目的（換言すると、生体認証原本情報の利用目的）が管理されており、目的外の利用が禁止される。認証許可部３１５は、個別サービスからの認証処理の要求が目的内の利用であれば生体認証処理の実行を許可し、目的外の利用の場合には生体認証処理の実行を禁止する。この目的外の利用を禁止する処理については詳しくは後述する。例えば、認証許可部３１５は、目的内の利用であると判定した場合、生体認証処理の実行を許可し、受信部３１２が受信した認証用生体情報を、生体認証処理の実行要求とともに認証データマネジメント機能部３３０に受け渡す。
制御情報記憶部３１８は、認証サービスマネジメント機能部３１０が備える各部の処理に必要な情報を記憶する。例えば、制御情報記憶部３１８には、通信インターフェースに関する情報、ユーザ毎の生体認証の利用目的に関する管理情報等が記憶されている。

ユーザマネジメント機能部３２０は、ユーザ情報管理部３２１と、ユーザ情報記憶部３２２と、を備えている。ユーザ情報管理部３２１は、認証サービスマネジメント機能部３１０からユーザマネジメント機能部３２０に受け渡されたユーザ登録情報を取得する。そして、ユーザ情報管理部３２１は、取得したユーザ登録情報を、生体認証ＰＦシステム３００に登録されたユーザ（登録者）のユーザ情報としてユーザ情報記憶部３２２に記憶して管理する。

図８は、ユーザ情報記憶部３２２に記憶されるユーザ情報テーブルＴＢＬ３２１の一例を示す図である。図示するユーザ情報テーブルＴＢＬ３２１には、ユーザＩＤ（外部）と、ユーザＩＤ（内部）と、個人情報と、原本情報ポインタと、契約情報ポインタと、与信情報ポインタと、が関連付けられて格納される。ユーザＩＤ（外部）は、ユーザ登録情報に含まれるユーザの識別情報である。ユーザＩＤ（内部）は、ユーザＩＤ（外部）が、ユーザＩＤ（外部）とは異なるＩＤに変換されたもの、又は、ユーザＩＤ（外部）に対応付けて払い出されたものである。以下では、ユーザＩＤ（外部）から変換されたユーザＩＤ（内部）、及びユーザＩＤ（外部）に対応付けて払い出されたユーザＩＤ（内部）のことを、ユーザＩＤ（外部）に対応するユーザＩＤ（内部）ともいう。図示する例では、「Ｕ１」のユーザＩＤ（外部）に対応するユーザＩＤ（内部）は、「Ｘ１」である。生体認証ＰＦシステム３００内では、ユーザＩＤ（内部）を用いて生体認証原本情報の管理や認証処理を行うことで、安全性を高めている。個人情報は、そのユーザの住所、氏名、年齢、性別等の情報である。原本情報ポインタは、そのユーザの生体認証原本情報の保存場所を示す情報である。契約情報ポインタは、そのユーザの通信契約における契約情報の保存場所を示す情報である。与信情報ポインタは、そのユーザの与信情報の保存場所を示す情報である。

図７に戻り、認証データマネジメント機能部３３０は、原本情報管理部３３１（管理部の一例）と、認証管理部３３２と、原本情報記憶部３３３と、を備えている。
原本情報管理部３３１は、認証サービスマネジメント機能部３１０から認証データマネジメント機能部３３０へ受け渡された原本登録用生体情報を取得する。そして、原本情報管理部３３１は、取得した原本登録用生体情報を生体認証原本情報として、生体情報の種類毎かつユーザ毎に区別可能に原本情報記憶部３３３に記憶して管理する。原本情報記憶部３３３は、生体情報の種類毎かつユーザ毎の生体認証原本情報を、原本情報として記憶して管理する。

図９は、原本情報記憶部３３３に記憶される原本情報テーブルＴＢＬ３３１の一例を示す図である。原本情報テーブルＴＢＬ３３１では、認証種別毎（生体情報の種類毎）に生体認証原本情報が管理される。例えば、原本情報テーブルＴＢＬ３３１には、原本マスタポインタテーブルＴＢＬ３３１１と、認証種別毎の生体認証原本テーブル（顔認証原本テーブルＴＢＬ３３１２Ａ、指紋認証原本テーブルＴＢＬ３３１２Ｂ、・・・）とが含まれる。原本マスタポインタテーブルＴＢＬ３３１１には、生体情報種別ＩＤと、認証種別と、テーブルポインタと、が関連付けられて格納される。生体情報種別ＩＤは、生体情報の種類を示す種別情報である。認証種別は、認証処理の種類を示す情報である。図示する例では、顔認証、指紋認証、指静脈認証、掌静脈認証、虹彩認証、歯型認証、声紋認証、及びＤＮＡ（デオキシリボ核酸）認証のそれぞれの生体情報種別ＩＤとして、Ｓ１、Ｓ２、Ｓ３、Ｓ４、Ｓ５、Ｓ６、Ｓ７、及びＳ８が予め定められている。テーブルポインタは、各認証種別（生体情報の種類）の認証処理で利用する生体認証原本テーブルを示す情報である。例えば、顔認証のテーブルポインタ「Ｐｏｉｎｔｅｒ−１」には顔認証原本テーブルＴＢＬ３３１２Ａを示す情報が含まれ、指紋認証のテーブルポインタ「Ｐｏｉｎｔｅｒ−２」には指紋認証原本テーブルＴＢＬ３３１２Ｂを示す情報が含まれる。

生体認証原本テーブル（顔認証原本テーブルＴＢＬ３３１２Ａ、指紋認証原本テーブルＴＢＬ３３１２Ｂ、・・・）には、ユーザＩＤ（内部）と、シーケンスＩＤと、原本番号と、生体認証原本情報と、が関連付けられて格納される。原本番号は、生体認証原本情報毎にユニークに付与された管理番号である。生体認証原本情報には、認証種別毎の各ユーザの生体認証原本情報が格納される。図示する例では、顔認証原本テーブルＴＢＬ３３１２Ａにおいて、ユーザＩＤ（内部）「Ｘ１」が示すユーザの顔認証原本情報が原本番号「Ｓ１ＯＲＧ１０１」が付与されて格納されている。例えば、このテーブルの生体認証原本情報には各生体認証原本情報のファイル名が格納され、各生体認証原本情報の実体のデータは、各ファイル名が付されて原本情報記憶部３３３に別途記憶されている。また、シーケンスＩＤは、複数の異なる生体認証原本情報を用いて認証処理が行われる場合に、その複数の異なる生体認証原本情報を区別可能な情報である。例えば、指紋認証原本テーブルＴＢＬ３３１２Ｂは、指紋認証において指３本が登録されている場合の例を示しており、各ユーザの指３本のそれぞれの生体認証原本情報に対して、シーケンスＩＤ「１」、「２」、「３」が関連付けられて格納される。
なお、上述の全ての種類の生体認証原本情報が格納されていなくともよい。つまり、登録された生体認証原本情報のみが格納され、登録されていない生体認証原本情報は格納されていない。

図７に戻り、認証管理部３３２は、認証サービスマネジメント機能部３１０から認証データマネジメント機能部３３０に受け渡された生体認証処理の実行要求と認証用生体情報とを取得すると、認証機能ライブラリ機能部３４０に対して生体認証処理の実行を指示する。具体的には、認証管理部３３２は、生体認証処理の実行要求と認証用生体情報とを取得すると、認証用生体情報に関連付けられているユーザＩＤ（外部）に対応するユーザＩＤ(内部)をユーザマネジメント機能部３２０から取得する。そして、認証管理部３３２は、原本情報記憶部３３３の原本情報テーブルＴＢＬ３３０を参照して、取得したユーザＩＤ(内部)に関連付けられている原本登録用生体情報を抽出し、抽出した原本登録用生体情報と上記認証用生体情報とを、認証機能ライブラリ機能部３４０に受け渡す。また、認証管理部３３２は、認証機能ライブラリ機能部３４０から認証結果を取得すると、取得した認証結果を認証サービスマネジメント機能部３１０の認証結果取得部３１６に受け渡す。

認証機能ライブラリ機能部３４０は、認証部３４１と、認証機能記憶部３４２と、を備えている。認証部３４１は、認証データマネジメント機能部３３０から認証機能ライブラリ機能部３４０に受け渡された原本登録用生体情報と認証用生体情報とを取得すると、認証処理を実行する。具体的には、認証部３４１は、認証機能記憶部３４２に記憶されている生体認証機能のライブラリの中からいずれかの生体認証機能を選択し、選択した生体認証機能を用いて、取得した原本登録用生体情報と認証用生体情報とを比較及び照合する。

認証機能記憶部３４２は、各ベンダから提供される生体認証機能のライブラリを記憶する。例えば、各ベンダから生体認証ＰＦシステム３００に対して、生体認証機能を実行可能な生体認証機能プログラムが提供されており、その提供された各生体認証機能プログラムが認証機能記憶部３４２に記憶されている。ここで、提供される生体認証機能プログラムは、各ベンダから認証機能ライブラリ機能部３４０に登録されてもよいし、各ベンダから認証サービスマネジメント機能部３１０を介して認証機能ライブラリ機能部３４０に登録されてもよい。なお、各ベンダから提供される各生体認証機能プログラムは、各ベンダの各生体認証機能を実現するアルゴリズムに基づいて作成されたプログラムである。また、ある生体認証機能プログラムの一部が変更（例えば、アルゴリズムの一部が変更）された場合、変更前の生体認証機能プログラムと変更後の生体認証機能プログラムとは、異なる製品バージョン番号（バージョン情報の一例）により区別可能に管理される。例えば、認証機能記憶部３４２には、各ベンダから提供される各生体認証機能プログラム毎（換言すると、生体認証機能アルゴリズム毎）、さらには、各生体認証機能プログラムのバージョン毎（換言すると、生体認証機能アルゴリズム毎）、に区別可能なように記憶される。

図１０は、認証機能記憶部３４２に記憶される生体認証機能テーブルＴＢＬ３４１の一例を示す図である。生体認証機能テーブルＴＢＬ３４１には、生体情報種別ＩＤと、ベンダＩＤと、ライブラリＩＤと、認証機能プログラムと、が関連付けられて格納されている。生体情報種別ＩＤは、各認証機能プログラムが生体認証を行う生体情報の種類を示す種別情報である。ベンダＩＤは、認証機能プログラムの開発及び提供元のベンダの識別情報である。ライブラリＩＤは、各認証機能プログラムに個別に付された管理ＩＤである。例えば、このライブラリＩＤは、認証機能プログラム毎にユニークに付与される番号であり、例えば、「製品番号＋製品バージョン番号」等である。このライブラリＩＤにより、各認証機能プログラムを識別することが可能である。認証機能プログラムには、各認証機能プログラムのファイル名が格納されている。なお、各認証機能プログラムの実体のデータは、各ファイル名が付されて認証機能記憶部３４２に別途記憶されている。

例えば、各個別サービス毎に適用する生体認証機能が予め定められており、認証部３４１は、いずれの個別サービスからの生体認証であるかと生体認証の種別とに応じて生体認証機能を選択して認証処理を実行する。例えば、いずれのベンダの生体認証機能を用いるかは、認証サービスマネジメント機能部３１０が受信する認証用生体情報にライブラリＩＤ、又はベンダＩＤ及び生体情報種別ＩＤが関連付けられていることにより特定できる。なお、認証機能ライブラリ機能部３４０内に、各個別サービスで適用するベンダの情報が記憶されていてもよい。その場合には、いずれのベンダの生体認証機能を用いるかは、認証サービスマネジメント機能部３１０が受信する認証用生体情報に個別ＡＰｓｙｓＩＤ及び認証用生体情報が関連付けられていることにより特定できる。また、認証部３４１は、認証結果を認証データマネジメント機能部３３０の認証管理部３３２へ返す。

［生体認証ＰＦシステムの動作］
次に、生体認証ＰＦシステム３００における処理の動作について説明する。
（生体認証原本情報の登録処理）
まず、図１１を参照して、生体認証ＰＦシステム３００へ生体認証原本情報を登録する登録処理について説明する。図１１は、生体認証原本情報の登録処理の一例を示す動作図である。なお、ここでは、ユーザ登録処理と生体認証原本情報の登録処理とを同時に行う場合の処理の例を説明するが、ユーザ登録処理を先に行い、その後、生体認証原本情報の登録処理を行ってもよい。また、ここでは、端末５０と生体認証ＰＦシステム３００との間で個別ＡＰシステム１００又はビジネスＰＦシステム２００が情報を仲介する場合を例として示している。

ステップＳ１００において、端末５０においてユーザがユーザ登録情報（例えば、ユーザＩＤ（外部）、パスワード、個人情報等）と、原本登録用生体情報と、を入力すると、端末５０は、入力されたユーザ登録情報及び原本登録用生体情報を個別ＡＰシステム１００又はビジネスＰＦシステム２００へ送信する。

ステップＳ１０２において、個別ＡＰシステム１００又はビジネスＰＦシステム２００は、端末５０から送信されたユーザ登録情報及び原本登録用生体情報を受信し、受信したユーザ登録情報及び原本登録用生体情報を生体認証ＰＦシステム３００へ送信する。

ステップＳ１０４において、生体認証ＰＦシステム３００の認証サービスマネジメント機能部３１０は、個別ＡＰシステム１００又はビジネスＰＦシステム２００から送信されたユーザ登録情報及び原本登録用生体情報を受信する。このとき、認証サービスマネジメント機能部３１０は、接続される個別ＡＰシステム１００又はビジネスＰＦシステム２００のサーバや端末５０、及び通信回線（通信ネットワークＮＷ）の正当性を確認する。また、認証サービスマネジメント機能部３１０は、受信したユーザ登録情報及び原本登録用生体情報の本人性及び妥当性の確認を行う。例えば、認証サービスマネジメント機能部３１０は、生体情報の撮影日時と送信日時との差、ユーザの与信情報や契約情報等に基づいて、本人性及び妥当性の確認を行う。この本人性及び妥当性の確認について詳しくは後述する。

認証サービスマネジメント機能部３１０は、本人性及び妥当性の確認が取れたユーザ登録情報を、ユーザマネジメント機能部３２０に受け渡す。また、認証サービスマネジメント機能部３１０は、本人性及び妥当性の確認が取れた原本登録用生体情報を、認証データマネジメント機能部３３０に受け渡す。

ステップＳ１０６において、ユーザマネジメント機能部３２０は、認証サービスマネジメント機能部３１０からユーザ登録情報を取得すると、取得したユーザ登録情報を、生体認証ＰＦシステム３００に登録されたユーザ（登録者）のユーザ情報として記憶して管理する（図８参照）。ここで、ユーザマネジメント機能部３２０は、取得したユーザ登録情報に含まれるユーザＩＤ（外部）をユーザＩＤ（内部）に変換（外部ＩＤから内部ＩＤに変換）し、変換したユーザＩＤをカプセル化等の安全化処理を施して記憶する。

ステップＳ１０８において、認証データマネジメント機能部３３０は、認証サービスマネジメント機能部３１０から原本登録用生体情報を取得すると、取得した原本登録用生体情報を生体認証原本情報として、生体情報の種類毎かつユーザ毎に区別可能に記憶して管理する（図９参照）。認証データマネジメント機能部３３０は、取得した原本登録用生体情報に対してコード化、暗号化、カプセル化等を行い生体認証原本情報として記憶して管理する。なお、端末５０から送信される際に既に暗号化されている場合には、認証データマネジメント機能部３３０は、２重に暗号化してもよいし、ここでは、暗号化せず一重のままでもよい。また、端末５０から送信される際に既にコード化されている場合には、認証データマネジメント機能部３３０は、２重にコード化は実施しなくてもよい。ここでいうコード化には、所謂ベクトル化も含まれる。また、端末５０又は認証機能ライブラリ機能部３４０が管理する認証機能にコード化の機能が搭載されている場合、端末５０又は認証機能ライブラリ機能部３４０の機能を利用してコード化されてもよい。また、認証データマネジメント機能部３３０は、分割断片化して生体認証原本情報を記憶して管理してもよい。また、認証データマネジメント機能部３３０は、生体認証原本情報を多重化（例えば、３重化）して記憶して管理してもよい。これらの生体認証原本情報の管理方法について詳しくは後述する。

（生体認証処理）
次に、図１２及び図１３を参照して、生体認証ＰＦシステム３００における生体認証処理について説明する。図１２は、生体認証処理における前半の処理（端末５０から生体認証ＰＦシステム３００へ認証用生体情報を送信して認証処理が行われる前までの処理）の一例を示す動作図である。

ステップＳ２００において、端末５０において、ユーザ認証を行うためのユーザ認証画面に対してユーザがユーザＩＤ（外部）と、認証用生体情報と、を入力すると、端末５０は、入力されたユーザＩＤ（外部）及び認証用生体情報を個別ＡＰシステム１００又はビジネスＰＦシステム２００へ送信する。

ステップＳ２０２において、個別ＡＰシステム１００又はビジネスＰＦシステム２００は、端末５０から送信されたユーザＩＤ（外部）及び認証用生体情報を受信し、受信したユーザＩＤ（外部）及び認証用生体情報を生体認証ＰＦシステム３００へ送信する。

ステップＳ２０４において、生体認証ＰＦシステム３００の認証サービスマネジメント機能部３１０は、個別ＡＰシステム１００又はビジネスＰＦシステム２００から送信されたユーザＩＤ（外部）及び認証用生体情報と、当該個別ＡＰシステム１００の個別ＡＰｓｙｓＩＤ又はビジネスＰＦシステム２００のビジネスＰＦｓｙｓＩＤと、を受信する。認証サービスマネジメント機能部３１０は、この認証処理が目的内の利用であるか否かを判定し、目的外の利用であると判定した場合には認証処理の実行を禁止して、認証禁止を示す情報を個別ＡＰシステム１００又はビジネスＰＦシステム２００を介して端末５０に送信する。一方、認証サービスマネジメント機能部３１０は、目的内の利用であると判定した場合には、受信したユーザＩＤ（外部）及び認証用生体情報を認証データマネジメント機能部３３０に受け渡す。

ステップＳ２０６において、認証データマネジメント機能部３３０は、認証サービスマネジメント機能部３１０からユーザＩＤ（外部）及び認証用生体情報を取得すると、取得したユーザＩＤをユーザマネジメント機能部３２０に受け渡し、ユーザＩＤ（外部）に対応するユーザＩＤ（内部）をユーザマネジメント機能部３２０から取得する。このとき、認証データマネジメント機能部３３０は、カプセル化等の安全化処理を解除し、元のユーザＩＤ（内部）を取得する。なお、ユーザＩＤ（外部）からユーザＩＤ（内部）への変換は、認証サービスマネジメント機能部３１０がユーザマネジメント機能部３２０にユーザＩＤ（外部）を受け渡すことにより行ってもよい。その場合には、認証データマネジメント機能部３３０は、認証サービスマネジメント機能部３１０からユーザＩＤ（内部）及び認証用生体情報を取得する。そして、認証データマネジメント機能部３３０は、ユーザＩＤ（内部）に基づいて、登録されている生体認証原本情報の中から認証処理に用いる生体認証原本情報を特定する。なお、認証データマネジメント機能部３３０は、複数種類の生体認証用の生体認証原本情報を管理している場合には、認証用生体情報に関連付けられている生体情報種別ＩＤと、ユーザＩＤ（内部）とに基づいて、登録されている生体認証原本情報の中から認証処理に用いる生体認証原本情報を特定する。また、認証データマネジメント機能部３３０は、特定した生体認証原本情報を、コード化、カプセル化、暗号化、分割断片化等された状態から復元する。
そして、認証データマネジメント機能部３３０は、取得した認証用生体情報との認証処理を認証機能ライブラリ機能部３４０の認証機能を用いて実行させる。具体的には、認証データマネジメント機能部３３０は、特定した生体認証原本情報と、取得した認証用生体情報とを、認証機能ライブラリ機能部３４０に受け渡す。

図１３は、生体認証処理における後半の処理（生体認証ＰＦシステム３００において認証処理が行われ、認証結果が端末５０へ送信される処理）の一例を示す動作図である。
ステップＳ３００において、認証機能ライブラリ機能部３４０は、生体認証機能のライブラリの中の生体認証機能を用いて、取得した原本登録用生体情報と認証用生体情報とを比較及び照合する。なお、生体認証ＰＦシステム３００では、生体認証機能として、１対１比較の認証方式と１対Ｎ比較（Ｎは正の整数）の認証方式とをサポートしている。１対１比較の認証方式とは、一つの認証用生体情報と一つの生体認証原本情報とが合致するか否かを比較して照合する認証方式である。１対Ｎ比較の認証方式とは、一つの認証用生体情報をＮ個の生体認証原本情報と比較し、Ｎ個の生体認証原本情報の中に合致する生体認証原本情報があるか否かを照合する認証方式である。これらの認証方式は、提供される認証機能によっていずれかの認証方式が用いられている。そして、認証機能ライブラリ機能部３４０は、認証結果を認証データマネジメント機能部３３０に受け渡す。

ここで、認証処理について具体的に説明する。例えば、認証機能ライブラリ機能部３４０は、認証処理において、認証用生体情報と生体認証原本情報との同一性の確率を検証し、同一性の確率を示す情報を認証結果として認証データマネジメント機能部３３０に受け渡す。図１４は、認証処理のイメージ図である。複数の個別サービスから生体認証ＰＦシステム３００に対して生体認証原本情報の登録、追加、抹消が行われ、生体認証ＰＦシステム３００は、この生体認証原本情報を管理する。そして、生体認証ＰＦシステム３００は、複数の個別サービスのうちのいずれか一のサービスから受信するユーザの認証用生体情報と、管理する生体認証原本情報との同一性の確率を検証して認証結果情報を、当該位置のサービスに対して送信する。なお、同一性の確率の検証は、一種類の生体情報の検証としてもよいし、複数種類の生体情報の組合せによる検証としてもよい。複数種類の生体情報の組合せ（例えば、顔認証と掌静脈認証との組合せ等）による検証では、認証精度を高めることができ、認証の安全性を高めることができる。また、同一性の確率は、例えば、パーセント、Ｌ段階中Ｍ段階目（例えば、１０段階中９段階目）、高中低、等のいずれであってもよく、認証機能の仕様や個人サービスからの要求に依存する。

例えば、顔認証と掌静脈認証との組合せによる同一性の確率の検証の具体例を説明する。顔認証による本人性認証受入確率＝９８％、本人性誤認拒否確率＝２％とし、掌静脈認証による本人性認証受入確率＝９９％、本人性誤認拒否確率＝１％として、以下のケース１〜５を説明する。ここで、本人性認証受入確率とは、本人を正しく受け入れる割合を示し、本人性誤認拒否確率とは、本人が誤って拒否される割合、即ちＦＲＲ（Ｆａｌｓｅ Ｒｅｊｅｃｔｉｏｎ Ｒａｔｅ）を示す。また、顔認証及び掌静脈認証のそれぞれにおいて、認証用生体情報と同一の生体認証原本情報が存在すると判定した場合を「正」と表し、認証用生体情報と同一の生体認証原本情報が存在しないと判定した場合を「誤」と表す。
ケース１：顔認証が正及び掌静脈認証が正では、「０．９８×０．９９＝０．９７０２」となり本人性認証受入確率が９７．２％となる。
ケース２：顔認証が誤及び掌静脈認証が正では、「０．０２×０．９９＝０．０１９８」となり本人性認証受入確率が１．９８％となる。
ケース３：顔認証が正及び掌静脈認証が誤では、「０．９８×０．０１＝０．００９８」となり本人性認証受入確率が０．９８％となる。
ケース４：顔認証が誤及び掌静脈認証が誤では、「０．０２×０．０１＝０．０００２」となり本人性認証受入確率が０．０２％となる。
ケース５：顔認証と掌静脈認証とのいずれか一方が正であれば正とする場合では、「１−０．０２×０．０１＝０．９９９８」となり本人性認証受入確率９９．９８となる。

図１３に戻り、ステップＳ３０２において、認証データマネジメント機能部３３０は、認証結果を認証機能ライブラリ機能部３４０から取得する。また、認証データマネジメント機能部３３０は、多重化（例えば、３重化）して管理している生体認証原本情報と多重比較（例えば、３重比較）させ、それぞれの認証結果を認証機能ライブラリ機能部３４０から取得する。そして、認証データマネジメント機能部３３０は、認証結果を認証サービスマネジメント機能部３１０に受け渡す。

また、ステップＳ３０４において、ユーザマネジメント機能部３２０は、認証処理が行われたユーザのユーザ情報を抽出し、認証サービスマネジメント機能部３１０に受け渡す。このユーザ情報は、認証処理が行われた認証用生体情報に関連付けられているユーザＩＤ（外部）のユーザ情報であり、例えば、ユーザ名である。

次に、ステップＳ３０６において、認証サービスマネジメント機能部３１０は、認証データマネジメント機能部３３０から取得した認証結果と、ユーザマネジメント機能部３２０から取得したユーザ情報とに基づいて、端末５０に対して認証結果を通知するための認証結果情報を生成する。そして、認証サービスマネジメント機能部３１０は、生成した認証結果情報を個別ＡＰシステム１００又はビジネスＰＦシステム２００へ送信する。

ステップＳ３０８において、個別ＡＰシステム１００又はビジネスＰＦシステム２００は、認証サービスマネジメント機能部３１０から送信された認証結果情報を受信し、受信した認証結果情報を端末５０へ送信する。

ステップＳ３１０において、端末５０は、個別ＡＰシステム１００又はビジネスＰＦシステム２００から送信された認証結果情報を受信し、受信した認証結果情報に基づいて認証結果を表示するとともに、認証結果に応じた処理を行う。例えば、認証結果が認証ＯＫである場合には、認証ＯＫを示す情報とユーザ名とが表示され、個別サービスが開始される。一方、認証結果が認証ＮＧである場合には、認証ＮＧを示す情報が表示され、個別サービスが開始されずにユーザ認証画面が再び表示される。

以上のように、生体認証ＰＦシステム３００は、複数の個別サービスのそれぞれから送信されるユーザの生体情報を受信し、受信した生体情報に対する認証処理結果情報をそれぞれの個別サービスへ送信する。そして、生体認証ＰＦシステム３００が備える各機能構成（認証サービスマネジメント機能部３１０、ユーザマネジメント機能部３２０、認証データマネジメント機能部３３０、及び認証機能ライブラリ機能部３４０）は、複数の個別サービスの端末５０や個別ＡＰシステム１００、及びビジネスＰＦシステム２００に対して独立して構成されている。

図１５は、生体認証ＰＦシステム３００の独立性及び安全性を説明する説明図である。生体認証ＰＦシステム３００は、個別サービスと従属関係になく、独立関係にある。前述したように、生体認証ＰＦシステム３００と、端末５０や個別ＡＰシステム１００、及びビジネスＰＦシステム２００との間の通信に関するインターフェース仕様（ＡＰＩ、ＤＩ、及びＵＩの仕様）が規定されており、個別サービスに対して提供される。また、ユーザＩＤを、生体認証ＰＦシステム３００の外部と内部とでそれぞれ異なる２つのＩＤに分けている。従って、生体認証ＰＦシステム３００は、生体認証サービスを利用する個別サービス（端末１０、個別ＡＰシステム１００）の変化に影響を受けない構成である。
よって、生体認証ＰＦシステム３００は、端末５０や個別ＡＰシステム１００、及びビジネスＰＦシステム２００に変更、不具合、故障が発生した場合においても、独立関係にあるため影響を殆ど受けないため、安全性が高い。

このように、生体認証ＰＦシステム３００は、ユーザが利用する個別サービス（端末１０、個別ＡＰシステム１００）、及び個別サービスと中継する生体認証ＰＦシステム３００と分離独立しており、技術方式、制御方式、データ形式、オペレーション、投資、利用企業経営等に非依存であり影響を受けない。従って、生体認証ＰＦシステム３００は、独立性及び安全性を兼ね備えた生体認証サービスをプラットフォームシステムにより提供することができる。

［利用シーンの概要］
次に、生体認証ＰＦシステム３００の利用シーンの概要を説明する。
図１６は、生体認証ＰＦシステム３００の利用シーンの概要を説明する説明図である。
（１）生体認証原本情報の登録時
ユーザ本人の自発的意思に基づいて、生体認証原本情報を生体認証ＰＦシステム３００に登録することを原則とする。生体情報は、不変化の個人情報および個人同定情報であるから、この原則が重要である。なお、認知症による徘徊者等の身元不明者の確認等、社会通念上妥当性がある場合は、家族又は行政機関の判断で生体認証原本情報の登録を実施する場合も例外的に許容する。
（２）生体認証サービスの利用時
生体認証の事由（商取引、医療介護ヘルスケア、身元不明者の確認、電子行政における証明書発行等）が発生すると、生体認証ＰＦシステム３００は、事前に登録された生体認証原本情報と、事由が発生した時点で認証要求元から送信された認証用生体情報（ユーザ本人の生体情報）を照合し、同一性の確率もしくは不一致性の確率を求め、求めた確率（評価結果情報）を認証要求元に通知する。受信した確率値をどのように扱うかは、受信したビジネスＰＦシステム２００、個別ＡＰシステム１００、又は端末５０で定められた内容（ビジネスモデル、契約、法律等により定められた内容）次第である。

［目的外の利用の禁止］
上述したように、原則はユーザ本人の自発的意思に基づいて生体認証原本情報が登録される。ここで、本実施形態に係る生体認証ＰＦシステム３００では、登録した生体認証原本情報による認証処理の利用目的をユーザ本人の希望により限定することができる。また、登録した生体認証原本情報による認証処理をユーザ本人の希望により複数の個別サービスで利用可能とすることもできる。例えば、生体認証ＰＦシステム３００は、ユーザ毎かつ生体情報の種類毎に認証処理の利用目的を管理し、目的外の利用を禁止する。

具体的には、認証サービスマネジメント機能部３１０の認証許可部３１５は、複数の個別サービスのそれぞれに対して、認証処理の実行を許可するか否かを制御する。ここで、制御情報記憶部３１８には、ユーザ毎の生体認証処理の利用目的に関する管理情報が記憶されており、この管理情報を参照することにより、認証許可部３１５は、認証処理の実行を許可するか否かを制御する。例えば、この管理情報には、利用目的内の認証処理については認証処理の実行を許可することが予め登録されている。

例えば、ユーザは、自身の生体認証原本情報を登録する際に、又は登録した後に利用目的として、その生体認証原本情報を利用した認証処理の実行を許可する個別サービスを登録する。認証サービスマネジメント機能部３１０の登録部３１４は、生体認証原本情報と、当該生体認証原本情報による認証処理の実行を許可する個別サービスを示す情報（許可サービス情報）とを関連付ける管理情報を制御情報記憶部３１８に記憶させる。

認証許可部３１５は、制御情報記憶部３１８を参照して、認証処理の実行を許可することが予め登録されている場合に、認証処理の実行を許可する。一方、認証許可部３１５は、認証処理の実行を許可することが予め登録されていない場合に、認証処理の実行を許可しない。例えば、制御情報記憶部３１８には、認証処理の実行を許可する個別ＡＰシステム１００を示す個別ＡＰｓｙｓＩＤ、及びビジネスＰＦシステム２００を示すビジネスＰＦｓｙｓＩＤが予め登録されている。そして、認証許可部３１５は、認証用生体情報を送信する個別ＡＰシステム１００を示す個別ＡＰｓｙｓＩＤ、及びビジネスＰＦシステム２００を示すビジネスＰＦｓｙｓＩＤ毎に、認証処理の実行を許可するか否かを制御する。

また、制御情報記憶部３１８には、さらに認証処理の実行を許可する生体認証原本情報の種類が予め登録されている。そして、認証許可部３１５は、認証用生体情報を送信する個別ＡＰシステム１００を示す個別ＡＰｓｙｓＩＤ、ビジネスＰＦシステム２００を示すビジネスＰＦｓｙｓＩＤ、及び生体認証原本情報の種類毎に、認証処理の実行を許可するか否かを制御してもよい。
なお、制御情報記憶部３１８には、認証処理の実行を許可しないことが予め登録されていてもよい。その場合、認証許可部３１５は、認証処理の実行を許可しないことが予め登録されている場合に、認証処理の実行を許可しない。

図１７は、認証処理の目的外の利用を禁止する例を説明する説明図である。この図では、一つの生体認証原本情報による認証処理が一つの個別サービスの利用に限定されている例を説明する。認証サービスマネジメント機能部３１０の制御情報記憶部３１８には、利用目的設定テーブルＴＢＬ３１８Ａが記憶されている。利用目的設定テーブルＴＢＬ３１８Ａには、ユーザを識別するユーザＩＤ（内部）と、認証処理の実行を許可する個別ＡＰシステム１００を示す個別ＡＰｓｙｓＩＤと、認証処理の実行を許可するビジネスＰＦシステム２００を示すビジネスＰＦｓｙｓＩＤと、認証処理の実行を許可する生体認証原本情報の種類を示す生体情報種別ＩＤと、が関連付けられて格納される。この利用目的設定テーブルＴＢＬ３１８Ａに格納される情報は、上述したユーザ毎の生体認証処理の利用目的に関する管理情報であって、例えば、ユーザ本人からの指示により、生体認証原本情報の登録時に設定され、その後、追加や削除などの変更が可能である。

この図に示す例では、ユーザＩＤ（内部）が「Ｘ１」のユーザ（以下、「ユーザＸ１」ともいう）の顔認証原本情報（生体情報種別ＩＤが「Ｓ１」）による顔認証処理が、個別ＡＰｓｙｓＩＤが「Ｅ２」の個別ＡＰシステム１００（以下、「個別ＡＰシステムＥ２」ともいう）にのみ実行を許可することが示されている。即ち、ユーザＸ１についての顔認証処理は、個別ＡＰシステムＥ２に対して利用が許可されており（契約関係が成立）、その他の個別サービスに対する利用が制限されている。これにより、生体認証ＰＦシステム３００は、ユーザＸ１の顔認証処理の実行を、個別ＡＰシステムＥ２に対しては許可し（認証実行）、その他の個別ＡＰシステム１００に対しては禁止する（認証拒否）。

図１８は、認証処理の目的外の利用を禁止する他の例を説明する説明図である。この図では、一つの生体認証原本情報による認証処理が複数（ここでは、二つ）の個別サービスで利用可能に設定されている例を説明する。この例では、認証サービスマネジメント機能部３１０の制御情報記憶部３１８には、利用目的設定テーブルＴＢＬ３１８Ｂが記憶されている。この利用目的設定テーブルＴＢＬ３１８Ｂでは、図１７の利用目的設定テーブルＴＢＬ３１８Ａと同様に、ユーザＸ１の顔認証原本情報による顔認証処理が、個別ＡＰシステムＥ２に実行を許可することが示されている。さらに、この利用目的設定テーブルＴＢＬ３１８Ｂでは、ユーザＸ１の顔認証原本情報による顔認証処理が、個別ＡＰｓｙｓＩＤが「Ｅ３」の個別ＡＰシステム１００（以下、「個別ＡＰシステムＥ３」ともいう）と、ビジネスＰＦｓｙｓＩＤが「Ｆ３」のビジネスＰＦシステム２００（以下、「ビジネスＰＦシステムＦ３」ともいう）に実行を許可することが示されている。即ち、ユーザＸ１についての顔認証処理は、個別ＡＰシステムＥ２と、ビジネスＰＦシステムＦ３を介した個別ＡＰシステムＥ３との両方に対して利用が許可されており（契約関係が成立）、その他の個別サービスに対する利用が制限されている。これにより、生体認証ＰＦシステム３００は、ユーザＸ１の顔認証処理の実行を、個別ＡＰシステムＥ２及び個別ＡＰシステムＥ３に対しては許可し（認証実行）、その他の個別ＡＰシステム１００に対しては禁止する（認証拒否）。

図１９は、認証許可部３１５が、利用目的に応じて認証処理の実行を許可するか否かを制御する処理の一例を示すフローチャートである。この図に示す処理は、図１２に示すステップＳ２０４で行われる処理の一部である。
ステップＳ１０１０において、認証許可部３１５は、個別サービスからの生体認証要求として、受信部３１２が受信した認証用生体情報を取得する。この認証用生体情報には、ユーザＩＤ（外部）と、生体情報種別ＩＤと、個別ＡＰｓｙｓＩＤと、ビジネスＰＦｓｙｓＩＤと、が関連付けられている。なお、ビジネスＰＦシステム２００を経由しない場合には、ビジネスＰＦｓｙｓＩＤは認証用生体情報に関連付けられていない。また、端末５０から直接に受信部３１２が受信する場合も、その端末５０において生体認証サービスを利用する個別サービスに対応する個別ＡＰｓｙｓＩＤが認証用生体情報に関連付けられている。

ステップＳ１０１２において、認証許可部３１５は、原本情報テーブルＴＢＬ３３１を参照し、認証用生体情報に関連付けられているユーザＩＤと生体情報種別ＩＤとに基づいて、該当する生体認証原本情報の登録があるか否かを判定する。該当する生体認証原本情報の登録がない場合（ステップＳ１０２１：ＮＯ）、ステップＳ１０１８に進み、認証許可部３１５は、認証処理の実行を禁止する。一方、該当する生体認証原本情報の登録がある場合（ステップＳ１０２１：ＹＥＳ）、ステップＳ１０１４に進み、認証許可部３１５は、認証用生体情報に対する認証処理の実行が許可されているか否か（即ち、利用目的内であるか否か）を判定する。具体的には、認証許可部３１５は、制御情報記憶部３１８に記憶されているユーザ毎の生体認証処理の利用目的に関する管理情報（例えば、利用目的設定テーブルＴＢＬ３１８Ａ、ＴＢＬ３１８Ｂ）を参照して、取得した認証用生体情報に関連付けられているユーザＩＤ（外部）（対応するユーザＩＤ（内部））、生体情報種別ＩＤ、個別ＡＰｓｙｓＩＤ、ビジネスＰＦｓｙｓＩＤ、等に基づいて、その認証用生体情報に対する認証処理の実行が許可されているか否かを判定する。

認証許可部３１５は、認証処理の実行が許可されていると判定した場合（ステップＳ１０１４：ＹＥＳ）、目的内の利用であると判定し、ステップＳ１０１６に進み、認証処理の実行を許可する。一方、認証許可部３１５は、認証処理の実行が許可されていないと判定した場合（ステップＳ１０１４：ＮＯ）、目的外の利用であると判定し、ステップＳ１０１８に進み、認証許可部３１５は、認証処理の実行を禁止する。例えば、認証許可部３１５は、認証禁止を示す情報を生体認証要求元の個別サービスに対して送信部３１３を介して送信して通知する。

このように、本実施形態に係る生体認証ＰＦシステム３００は、ユーザが登録した生体認証原本情報を用いての認証処理を目的外の利用には禁止することにより、目的内の利用に制限することができる。例えば、生体認証ＰＦシステム３００と事前に契約されている個別サービスのみ生体認証を受け付けるため、不通知、不承知、不許可のうちに、自己の生体認証情報が参照されることがなく安全である。また、生体認証ＰＦシステム３００は、ユーザ本人の希望に基づいて、一つの生体認証原本情報を複数の個別サービスにおける生体認証で利用できる。例えば、生体認証ＰＦシステム３００は、ユーザが複数の生体認証原本情報を登録しなくとも、一つの生体認証原本情報を、生体認証に利用する個別ＡＰシステム１００又はビジネスＰＦシステム２００に関連付けすることにより、一つの生体認証原本情報を複数の個別サービスにおける生体認証で利用できるため、生体認証原本情報の複数登録を回避することができる。

［生体認証原本情報の２重登録の禁止］
上述したように、本実施形態に係る生体認証ＰＦシステム３００は、一つの生体認証原本情報を登録することで、その一つの生体認証原本情報を複数の個別サービスにおける生体認証に利用することが可能である。そこで、生体認証ＰＦシステム３００は、同一ユーザの同一種類の生体情報を生体認証原本情報として２重登録しないように制御する。

図２０は、生体認証原本情報の２重登録禁止処理を説明する説明図である。生体認証ＰＦシステム３００は、原本登録用生体情報と、既に原本登録されている複数の生体認証原本情報のうち同一種類の生体認証原本情報（生体認証原本情報−１、生体認証原本情報−２、・・・、生体認証原本情報―ｍ）との同一性の確率を検証する処理（同一情報性検査）を、認証機能ライブラリ機能部３４０の生体認証機能を用いて実施する。生体認証ＰＦシステム３００は、高確率で同一の生体認証原本情報が存在すると判定した場合には、その原本登録用生体情報を生体認証原本情報として登録しない（原本登録不可）。一方、生体認証ＰＦシステム３００は、高確率で同一の生体認証原本情報が存在しないと判定した場合には、その原本登録用生体情報を生体認証原本情報として登録することを許可する（原本登録可）。ここで、生体認証ＰＦシステム３００は、例えば、同一性の確率が第１の閾値（例えば、９５％）以上の場合に、高確率で同一の生体認証原本情報であると判定する。また、生体認証ＰＦシステム３００は、例えば、同一性の確率が第２の閾値（例えば、１０％）未満の場合に、高確率で同一の生体認証原本情報ではないと判定する。これにより、生体認証ＰＦシステム３００は、同一ユーザの同一の生体認証原本情報が２重登録されてしまうことを回避することができる。

図２１は、生体認証原本情報の２重登録禁止処理の一例を示すフローチャートである。この図に示す処理は、図１１に示すステップＳ１０４及びステップＳ１０８で行われる処理の一部である。
ステップＳ２０１０において、認証サービスマネジメント機能部３１０の登録部３１４は、受信部３１２が原本登録用生体情報を受信した場合、受信した原本登録用生体情報を取得する。原本登録用生体情報には、ユーザＩＤ（外部）と、生体情報種別ＩＤとが関連付けられている。

ステップＳ２０１２において、登録部３１４は、取得した原本登録用生体情報と、ユーザＩＤ（外部）と、生体情報種別ＩＤとを、認証データマネジメント機能部３３０に受け渡す。認証データマネジメント機能部３３０は、認証機能ライブラリ機能部３４０の生体認証機能を用いて、その原本登録用生体情報と、管理している登録済みの生体認証原本情報のうちユーザＩＤ（外部）に対応するユーザＩＤ（内部）及び生体情報種別ＩＤに関連付けられている生体認証原本情報とを比較して同一性の検証をする（１対１比較）。なお、認証データマネジメント機能部３３０は、その原本登録用生体情報と、管理している登録済み生体認証原本情報のうち生体情報種別ＩＤに関連付けられている全てのユーザの生体認証原本情報とを比較して同一性の検証をしてもよい（１対Ｎ比較）。例えば、認証データマネジメント機能部３３０は、同一性の検証結果として、同一性の確率を示す情報を認証サービスマネジメント機能部３１０の登録部３１４に受け渡す。

ステップＳ２０１４において、登録部３１４は、認証データマネジメント機能部３３０からの同一性の検証結果に基づいて、その原本登録用生体情報が、認証データマネジメント機能部３３０に管理されている登録済みの生体認証原本情報のいずれかと同一性がある（高確率で同一）と判定された場合（ステップＳ２０１４：ＹＥＳ）、ステップＳ２０１６に進み、その原本登録用生体情報に基づく生体認証原本情報を登録しない（原本登録不可）。一方、登録部３１４は、その原本登録用生体情報が、認証データマネジメント機能部３３０に管理されている登録済みの生体認証原本情報のいずれとも同一性がないと判定された場合、ステップＳ２０１８に進み、その原本登録用生体情報に基づく生体認証原本情報を登録する（原本登録可）。

このように、本実施形態に係る生体認証ＰＦシステム３００において、認証サービスマネジメント機能部３１０は、ユーザの原本登録用生体情報を受信部３１２が受信した場合、受信した原本登録用生体情報と、認証データマネジメント機能部３３０で管理している登録済み生体認証原本情報とに基づいて、同一ユーザの同一の生体情報を生体認証原本情報として２重登録しないため、安全性の高い認証システムを提供することができる。

また、登録部３１４は、複数の個別サービスから受信するユーザの原本登録用生体情報を取得する。例えば、登録部３１４は、ある個別サービスから取得した原本登録用生体情報を生体認証原本情報として登録したとする。その場合、登録部３１４は、同一ユーザの同一の原本登録用生体情報（生体認証原本情報として登録するための情報）を、別の個別サービスから取得した場合でも、この別の個別サービスから取得した原本登録用生体情報を生体認証原本情報として登録しない。
これにより、生体認証ＰＦシステム３００は、ある個別サービスから既に登録済みの生体認証原本情報が、別の個別サービスからの登録により２重登録されてしまうことを回避することができる。

なお、登録部３１４は、ある個別サービスから取得した原本登録用生体情報を生体認証原本情報として登録してから予め定めた期間以上経過後に、同一ユーザの同一の原本登録用生体情報（生体認証原本情報として登録するための情報）をいずれかの個別サービスから取得したとする。その場合、登録部３１４は、取得した原本登録用生体情報を生体認証原本情報として再登録してもよい。これにより、生体認証ＰＦシステム３００は、登録から長時間（例えば、２０年）経過してユーザの生体情報に変化が現れた場合には、ユーザが生体認証原本情報を再登録することができるため、適切に認証処理を実行することができる。

例えば、登録部３１４は、ある個別サービスから取得した原本登録用生体情報を生体認証原本情報として登録した場合であって、同一ユーザの同一の原本登録用生体情報（生体認証原本情報として登録するための生体情報）をいずれかの個別サービスから取得したとする。その場合、登録部３１４は、取得した原本登録用生体情報を生体認証原本情報として再登録する。これにより、生体認証ＰＦシステム３００は、登録から長時間経過した場合に生体認証原本情報を再登録可能な生体認証の種類を特定の生体認証（例えば、顔認証）に限定することができ、安全性を高めることができる。

なお、生体認証ＰＦシステム３００は、ユーザＩＤ（内部）、生体情報種別ＩＤ、ベンダＩＤ、ライブラリＩＤ、バージョン情報、シーケンスＩＤ等の一又は複数の重複チェックにより原本登録用生体情報の２重登録を禁止する処理を加えてもよい。この場合、生体認証ＰＦシステム３００は、原本登録用生体情報と登録済みの生体認証原本情報との同一性の確率を検証する処理を省略してもよい。

[生体認証原本情報の管理方法（コード化、暗号化、カプセル化、及び分割断片化）]
生体認証ＰＦシステム３００は、コード化、暗号化、カプセル化、及び分割断片化した生体認証原本情報を管理する。なお、コード化、暗号化、カプセル化、及び分割断片化のうちの一部が適用されてもよい。

図２２は、生体認証原本情報の管理方法を説明する説明図である。
コード化及び暗号化された生体認証原本情報（コード情報）は、カプセル化され、また、分割断片化される。分割断片化された生体認証原本情報（分割断片化されたコード情報）は、原本情報記憶部３３３に記憶されて管理されるが、その管理形態は、例えば、以下の形態１、形態２、及び形態３のいずれであってもよく、具体的な案件の設計条件により任意の形態とすることができる。

（形態１）原本情報記憶部３３３が一つの記憶装置により構成されており、原本情報管理部３３１は、生体認証原本情報を分割断片化した情報のそれぞれを、同一の記憶装置に記憶して管理する。

（形態２）原本情報記憶部３３３が複数の記憶装置により構成されてもよく、原本情報管理部３３１は、生体認証原本情報を分割断片化した情報のそれぞれを、複数の記憶装置に分散して記憶して管理してもよい。

（形態３）原本情報記憶部３３３が複数の記憶装置により構成されており、その複数の記憶装置が複数のデータセンターに分散して設置されてもよい。そして、原本情報管理部３３１は、生体認証原本情報を分割断片化した情報のそれぞれを、複数のデータセンターに分散して記憶して管理してもよい。なお、データセンターとは、各種コンピュータ装置（サーバ等）、インターネットや電話回線等の通信装置、等を設置及び運用する施設のことである。

次に、コード化について説明する。例えば、生体認証ＰＦシステム３００は、受信する原本登録用生体情報がベア情報の場合、生体認証原本情報として登録する際にコード化を実施する。一方、生体認証ＰＦシステム３００は、受信する原本登録用生体情報がコード化されたコード情報である場合、２重にコード化は実施しない。なお、生体認証ＰＦシステム３００は、受信する原本登録用生体情報がコード化及び暗号化された情報である場合も、２重にコード化は実施しない。
ここで、原本登録用生体情報がベア情報の場合、その仕様に応じて復元性のあるコード化を採用する。具体的には、設計時の要求によって決定する。コード化の方式としては、公知の技術（例えば、安定した方式）を用いることができる。なお、コード化の機能は、ベンダにより提供される認証機能が具備していることが多く、その場合にはその機能を利用してもよい。

次に、暗号化について説明する。暗号化については、生体認証ＰＦシステム３００で公知技術を適切に判断し原則全ての原本登録用生体情報に適用する。例えば、生体認証ＰＦシステム３００は、受信する原本登録用生体情報がベア情報の場合、生体認証原本情報として登録する際に暗号化する。また、生体認証ＰＦシステム３００は、受信する原本登録用生体情報がコード化されたコード情報（暗号化されていないコード情報、又は暗号化されているか否か不明のコード情報）である場合も暗号化する。さらに、生体認証ＰＦシステム３００は、受信する原本登録用生体情報がコード化及び暗号化されたコード情報である場合も２重に暗号化する。

なお、生体認証ＰＦシステム３００は、生体認証原本情報として登録する原本登録用生体情報が、いずれの生体認証機能で用いるものであるかに応じて２重暗号化を許可するか否かを判定して、２重暗号化をするか否かを制御してもよい。例えば、生体認証ＰＦシステム３００は、ライブラリＩＤと２重暗号化を許可するか否かを示す情報とを関連付けた２重暗号化許可テーブルを備えている。例えば、通常一般的には２重暗号化を許可することを示す情報が設定され、一方、安全性が十分担保されており、性能目標（例えば、認証速度目標）をクリアしたい場合に、２重暗号化を許可しないことを示す情報が設定されている。そして、生体認証ＰＦシステム３００は、原本登録用生体情報を受信した場合、その２重暗号化許可テーブルを参照して、２重暗号化を許可するか否かを判定し、判定結果に応じて２重暗号化をするか否かを制御する。なお、生体認証ＰＦシステム３００は、受信する原本登録用生体情報に生体情報種別ＩＤとベンダＩＤとが関連付けられている場合には、生体認証機能テーブルＴＢＬ３４１を参照して、その生体情報種別ＩＤとベンダＩＤとに基づいてライブラリＩＤを特定する。また、受信する原本登録用生体情報にライブラリＩＤが関連付けられていてもよく、その場合には、生体認証ＰＦシステム３００は、受信する原本登録用生体情報に関連付けられているライブラリＩＤに基づいて、２重暗号化を許可するか否かを判定する。これにより、生体認証ＰＦシステム３００は、例えば、安全性が十分担保されている場合には、２重暗号化を実施しない事を許容することにより、性能（例えば、認証速度）を向上させることができる。

暗号化の方式としては、公知技術のうちから安全性、安定性、及び性能を見極めた上で適切な方式を採用する。公知の暗号化の方式としては、共通鍵方式（秘密鍵方式）、公開鍵方式、ハイブリッド暗号方式等がある。共通鍵方式（秘密鍵方式）には、ブロック暗号方式とストリーム暗号（逐次暗号）方式とがある。ブロック暗号方式の例としては、ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）、ＦＥＡＬ（Ｆａｓｔ Ｄａｔａ Ｅｎｃｉｐｈｅｒｍｅｎｔ Ａｌｇｏｒｉｔｈｍ）、ＭＵＬＴＩ２等がある。ストリーム暗号（逐次暗号）方式の例としては、ＲＣ４、Ａ５、ＭＵＬＴＩ−Ｓ０１等がある。また、公開鍵方式の例としては、ＲＳＡ方式、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）方式、ＥＣＤＳＡ（楕円曲線ＤＳＡ）方式等がある。また、ハイブリッド暗号方式は、公開鍵方式と共通鍵方式との組合せた方式であり、公開鍵方式の処理オーバーヘッドと共通鍵方式の鍵受け渡し困難性との両者のデメリットを補完する方式である。共通鍵方式により平文を暗号化し、その暗号化に使用した「共通鍵自体」を公開鍵方式により暗号化する方式である。

次に、カプセル化について説明する。上述のコード化及び暗号化された情報がさらにカプセル化される。ベンダにより提供される認証機能にコード化の機能が具備されている場合、仕様が明示化されている可能性を鑑み、安全性を高めるため、カプセル化を施すことが有効である。カプセル化は、特定情報且つ固定長方式、又はＴＬＶ形式（Ｔａｇ＋Ｌｅｎｇｔｈ＋Ｖａｌｕｅ）でもよく、さらに、特定文字＆特定カプセル長方式（文字ＡならＴａｇ長２バイト、文字ＢならＴａｇ長３バイト等）等のいずれの方式でもよい。具体的な実装では、設計時の要求によって決定する。なお、分割断片化の後に、さらにカプセル化が行われてもよい。

次に、分割断片化について説明する。分割断片化は、過度に複雑な方式を採らない。例えば、２分割方式を採用する場合、はじめの定められた固定長（１２８バイト、２５６バイト等）を第１ファイルとし、残りの可変長部分を第２ファイルとするといった再結合処理が簡単な方式を採る。また、３分割方式を採用する場合には、第１ファイルを固定長、第２ファイルを固定長、第３ファイルを可変長といった再結合処理が容易な方式を採る。
また、各分割断片化ファイルもカプセル化する。

以下、図２３及び図２４を参照して、カプセル化及び分割断片化の具体例を説明する。なお、図２３は、２分割方式の分割断片化の一例を説明する説明図である。生体認証ＰＦシステム３００は、原本登録用生体情報として、コード化及び暗号化された生体情報（以下、「コード化／暗号化生体情報」ともいう）を受信すると（第１ｓｔｅｐ）、カプセル情報（ヘッダー及びフッター）を付加して、「コード化／暗号化生体情報」の全体をカプセル化する（第２ｓｔｅｐ）。カプセル情報（ヘッダー）は、「コード化／暗号化生体情報」の先頭に付加され情報であり、タグ（ＴＡＧ）、データ長（Ｌｅｎｇｔｈ）等の情報が含まれる。ここで、タグには、カプセルを識別する識別情報（ここでは、「Ａ１」）、生体情報種別ＩＤ（ここでは、「Ｓ１」）、ベンダＩＤ（ここでは、「Ｂ１」）等が含まれる。また、データ長は、「コード化／暗号化生体情報」のデータ長（ここでは、「Ｌ１」）を示す情報である。一方、カプセル情報（フッター）は、「コード化／暗号化生体情報」の末尾に付加される情報であり、チェックビット、タグ等の情報が含まれる。チェックビットは、ビット誤り検出用のビットである。また、カプセル情報（フッター）のタグには、データの最後を示すフレームエンド識別情報（ここでは、「ＦＥ」）等が含まれる。

次に、生体認証ＰＦシステム３００は、第２ｓｔｅｐで生成したカプセル化されたデータについて、予め定められた固定長となる「カプセル情報(ヘッダー)」及び「コード化／暗号化生体情報の前段」を合わせたデータを第１ファイルとし、残りの可変長となる「コード化／暗号化生体情報の後段」及び「カプセル情報(フッター)」を第２ファイルとして、２つに分割断片化し再カプセル化する（第３ｓｔｅｐ）。
このとき、第１ファイル及び第２ファイルには、それぞれのカプセル情報(ヘッダー及びフッター)が付加される。各ファイルに付加されるカプセル情報(フッター)には、チェックビット、タグ（ここでは、「ＦＥ」）等の情報が含まれる。

第１ファイル及び第２ファイルのそれぞれのカプセル情報(ヘッダー)には、タグ、データ長等の情報が含まれる。各ファイルのタグには、分割断片化された両者を一意に示す情報（ここでは、「Ｙ１」）、分割断片数（ここでは、「２」）、スタートフレームとエンドフレームのいずれであるかを示す情報（ここでは、第１ファイルにスタートフレームを示す情報として「Ｓ」、第２ファイルにエンドフレームを示す情報として「Ｅ」）等が含まれる。また、第１ファイルのデータ長（ここでは、「Ｌ２−１」）は、第２ｓｔｅｐで付加された「カプセル情報（ヘッダー）」と、「コード化／暗号化生体情報の前段」との合計のデータ長（固定長）を示す情報である。また、第２ファイルのデータ長（ここでは、「Ｌ２−２」）は、「コード化／暗号化生体情報の後段」と、「カプセル情報(フッター)」との合計のデータ長（可変長）を示す情報である。

図２４は、３分割方式の分割断片化の一例を説明する説明図である。この図に示す３分割方式では、図２３に示す２分割方式に対して第３ｓｔｅｐのみが異なる。生体認証ＰＦシステム３００は、第２ｓｔｅｐで生成したカプセル化されたデータについて、予め定められた固定長となる「カプセル情報(ヘッダー)」及び「コード化／暗号化生体情報の前段」を合わせたデータを第１ファイルとし、残りのデータのうち予め定められた固定長となる「コード化／暗号化生体情報の中段」を第２ファイルとし、最後に残る可変長となる「コード化／暗号化生体情報の後段」及び「カプセル情報(フッター)」を第３ファイルとして、３つに分割断片化し再カプセル化する（第３ｓｔｅｐ）。第１ファイル、第２ファイル、及び第３ファイルには、それぞれのカプセル情報(ヘッダー及びフッター)が付加される。各ファイルに付加されるカプセル情報(フッター)には、チェックビット、タグ（ここでは、「ＦＥ」）等の情報が含まれる。

第１ファイル、第２ファイル、及び第３ファイルのそれぞれのカプセル情報(ヘッダー)には、タグ、データ長等の情報が含まれる。各ファイルのタグには、分割断片化された両者を一意に示す情報（ここでは、「Ｙ１」）、分割断片数（ここでは、「３」）、スタートフレーム、中間フレーム、またはエンドフレームのいずれであるかを示す情報（ここでは、第１ファイルにスタートフレームを示す情報として「Ｓ」、第２ファイルに中間フレームを示す情報として「Ｍ」、第３ファイルにエンドフレームを示す情報として「Ｅ」）等が含まれる。また、第１ファイルのデータ長（ここでは、「Ｌ２−１」）は、第２ｓｔｅｐで付加された「カプセル情報（ヘッダー）」と、「コード化／暗号化生体情報の前段」の合計のデータ長（固定長）を示す情報である。また、第２ファイルのデータ長（ここでは、「Ｌ２−２」）は、「コード化／暗号化生体情報の中段」のデータ長（固定長）を示す情報である。また、第３ファイルのデータ長（ここでは、「Ｌ２−３」）は、「コード化／暗号化生体情報の後段」と、「カプセル情報(フッター)」との合計のデータ長（可変長）を示す情報である。

なお、分割断片化の方式は、上述の方式に限らず、他に確立された再結合処理速度が高い方式が具体的にあれば、その方式を採用してもよい。具体的な実装では、要求（生体認証原本情報の大きさ、認証処理に許容される処理時間、実装するハードウェア、ソフトウェアの性能等）によって決定する。例えば、上述した例では、カプセル化の際にヘッダー及びフッターのカプセル情報を付加する例を説明したが、カプセル化の際にヘッダーのカプセル情報のみ付加してもよい。また、生体認証ＰＦシステム３００は、カプセル化と分割断片化とのうち、いずれか一方のみを行ってもよいし、両方を行ってもよい。

例えば、生体認証ＰＦシステム３００において、認証データマネジメント機能部３３０の原本情報管理部３３１は、複数種類の生体認証原本情報を、生体情報の種類毎かつユーザ毎にコード化し暗号化したものを、さらにカプセル化または分割断片化のいずれか一方または両方を行って管理する。なお、例えば、複数のベンダから生体認証機能プログラムが提供される場合、アルゴリズムが異なる生体認証機能プログラムをライブラリとして利用することがある。そのため、原本情報管理部３３１は、複数種類の生体認証原本情報を、さらに生体認証機能のアルゴリズム毎にコード化し暗号化したものを、さらにカプセル化または分割断片化のいずれか一方または両方を行って管理してもよい。また、原本情報管理部３３１は、複数種類の生体認証原本情報を、さらに生体認証機能のアルゴリズムのバージョン毎（プログラムのバージョン毎）にコード化し暗号化したものを、さらにカプセル化または分割断片化のいずれか一方または両方を行って管理してもよい。なお、原本情報管理部３３１は、複数種類の生体認証原本情報を、ベンダ毎にコード化し暗号化したものを、さらにカプセル化または分割断片化のいずれか一方または両方を行って管理してもよい。
このように、生体認証ＰＦシステム３００は、生体認証原本情報をベア情報では保持せずに、不可逆性を考慮しコード化し暗号化したものを、さらにカプセル化または分割断片化のいずれか一方または両方を行って保持するので、安全性及び信頼性の高い生体認証原本情報のデータベースを構築することができる。なお、より安全性及び信頼性の高い生体認証原本情報のデータベースを構築するには、例えば、上記コード化、暗号化、カプセル化、及び分割断片化の全てを適用する。

また、原本情報管理部３３１は、生体認証原本情報をコード化、暗号化、及びカプセル化するとともに、カプセル化した情報をさらに分割断片化し、分割断片化した各情報をカプセル化して管理することで、生体認証原本情報の安全性及び信頼性をより高めることができる。

なお、原本情報管理部３３１は、複数の個別サービスから受信する複数種類のユーザの生体情報を取得し、少なくとも一の種類の生体情報について、取得した生体情報と生体認証原本情報とを照合し、照合結果に基づいて、取得した他の種類の生体情報を生体認証原本情報に付加した、新たな生体認証原本情報をコード化し暗号化したものを、さらにカプセル化または分割断片化のいずれか一方または両方を行って管理してもよい。これにより、例えば、ユーザが指紋認証の生体認証原本情報を登録済みであって、その後、そのユーザが指紋認証及び掌静脈認証の生体認証原本情報の登録依頼をした場合、生体認証ＰＦシステム３００は、指紋認証で同一性が確認されることを条件として、掌静脈認証の生体認証原本情報を追加登録することができる。この場合、指紋認証での同一性が確認は、原本情報管理部３３１が認証機能ライブラリ機能部３４０に対して認証処理を実行させてもよい。

[生体認証原本情報の多重化による認証処理]
生体認証原本情報の不具合（例えば、データ破壊、改ざん等）は、ハードウェア、ソフトウェア、オペレーション等により確率的に発生し、発生ゼロとすることは困難である。万一、データ破壊・改ざん等が発生し、認証処理が正しくできない場合、及び破壊、改ざん等を認識できずに正しい認証処理が行われない可能性を回避するため、生体認証ＰＦシステム３００は、生体認証原本情報を多重化して保持してもよい。

例えば、生体認証ＰＦシステム３００において、認証データマネジメント機能部３３０の原本情報管理部３３１は、複数の個別サービスから受信するユーザの原本登録用生体情報に基づいて、複数の同一の生体認証原本情報を管理する。ここで、複数の同一の生体認証原本情報とは、同一ユーザかつ同一種類の生体情報を多重化した複数の生体認証原本情報である。多重化した複数の同一の生体認証原本情報は、一つの認証用生体情報または一つの生体認証原本情報から複製されて生成されてもよいし、同一ユーザから同一種類の認証用生体情報を複数取得して生成されてもよい。認証機能ライブラリ機能部３４０の認証部３４１は、複数の個別サービスから受信するユーザの認証用生体情報と、原本情報管理部３３１が管理する複数の同一の生体認証原本情報に基づいて多数決論理を用いて、当該認証用生体情報と生体認証原本情報との認証処理の認証結果を決定する。例えば、認証部３４１は、複数の個別サービスから受信するユーザの認証用生体情報と、原本情報管理部３３１が管理する複数の同一の生体認証原本情報のそれぞれとに基づいて認証処理を実行し、それぞれの認証結果に対して多数決論理を用いて認証結果を決定する。ここでは、一例として、生体認証原本情報を３重化する場合を例に説明する。

なお、多数決論理を用いて認証結果を決定するとは、多数派の認証結果を採用することである。例えば３重化の例では、認証用生体情報を、３つの生体認証原本情報のそれぞれと比較した３つの認証結果が三者一致の場合にはその認証結果を選択し、二対一の場合には二の方の認証結果を選択する。

図２５は、生体認証原本情報の３重化による高安全性について説明する説明図である。この図では、生体認証原本情報の３重化の例と、比較用に２重化の例を示している。３重化の例では生体認証原本情報「Ａ」、「Ｂ」及び「Ｃ」の３つが、複数の同一の生体認証原本情報として管理され、３の生体認証原本情報のそれぞれとの認証結果を示している。管理されている生体認証原本情報が正常であれば本人性認証受入（正しい認証結果）となり、管理されている生体認証原本情報に不具合があれば本人性誤認拒否（誤った認証結果）となる。そして、正しい認証結果と誤った認証結果のいずれかが多数決論理を用いて選択される。一方、２重化の例では生体認証原本情報「Ａ」及び「Ｂ」の２つが、複数の同一の生体認証原本情報として管理され、２つの生体認証原本情報のそれぞれとの認証結果を示している。２重化では、一方が誤認するといずれが正しいか判断不能となるため、両方とも本人性認証受入した場合のみ本人性認証受入の判断となる。

ここで、本人性認証受入確率＝０．９９９（９９．９％）、本人性誤認拒否確率＝０．００１（０．１％）とすると（所謂Ｔｈｒｅｅ９）、２重化方式の場合、誤った選択を誘導する確率は「１−０．９９９×０．９９９＝１．９９９Ｅ−０３」となる。一方、３重化方式の場合、誤った選択を誘導する確率は「１−０．９９９×０．９９９×０．９９９−３×（０．００１×０．９９９×０．９９９）＝２．９９８Ｅ−０６」となる。また、本人性認証受入確率＝０．９９９９（９９．９９％）、本人性誤認拒否確率＝０．０００１（０．０１％）とすると（所謂Ｆｏｕｒ９）、２重化方式の場合、誤った選択を誘導する確率は、「１−０．９９９９×０．９９９９＝１．９９９９Ｅ−０４」となる。一方、３重化方式の場合、誤った選択を誘導する確率は、「１−０．９９９９×０．９９９９×０．９９９９−３×（０．０００１×０．９９９９×０．９９９９）＝２．９９９８Ｅ−０８」となる。

従って、３重化の場合には、誤った選択を誘導する可能性が２重化の場合に比較して約１／１０００となり、原本の正当性及び認証結果の正当性に有効である。３重化に限らずそれ以上の多重化としてもよい。多重化の数を増やしていくことにより、誤った選択を誘導する可能性がより小さくなり効果が大きくなる。なお、多重化しない場合には、一つの生体認証原本情報に不具合が生じると１００％誤った選択となる。

なお、多重化を行うと認証処理のオーバーヘッドが大きくなる。このオーバーヘッドを低減するため、例えば、認証処理を実行するハードウェア、ソフトウェアの方式及び仕様に関しては処理スピードを重視して選択される。例えば、認証処理を実行するハードウェアには、ＣＰＵは高速、メモリは大容量のものを採用し、データの格納方式は、インメモリデータベースを基本とする。また、記憶装置（ストレージ）は、ＳＳＤ／フラッシュストレージを基本とする。具体的には、多重化の数及び要求される処理スピード等によって、適宜必要な仕様を満足するように選択され、低スペックでよい場合にはそれも可とする。また、原本情報記憶部３３３に記憶される生体認証原本情報の多重化したファイルのそれぞれの搭載場所については、ハードウェアの不具合発生に対する安全性を考慮し、（１）記憶装置を異にする、（２）記憶装置が複数の筐体に分散されている場合には筐体を異にする、（３）記憶装置が一つの筐体内にある場合には筐体内のメモリの部品や部材を異にする、等の方式が考えられる。例えば、（１）、（２）、（３）の優先順でいずれかの方式が選択される。

また、生体認証ＰＦシステム３００は、多重化による認証処理を原則一つのトランザクション毎に実行するが、一定時間毎（１時間毎、１２時間毎、２４時間毎(夜間)等）に実行してもよい。例えば、生体認証ＰＦシステム３００は、認証処理の目的、要求仕様、等によっては、一定時間毎に認証処理を実行してもよい。

このように、本実施形態に係る生体認証ＰＦシステム３００は、生体認証原本情報を多重化（例えば、３重化）して保持し、多数決論理を用いて認証結果を決定するので、原本の正当性及び認証結果の正当性を高め、安全性及び信頼性の高い生体認証サービスを提供することができる。

なお、多重化の数は、上述したように要求仕様やハードウェアの仕様等により３以上の任意の数とすることができるが、多数決論理を用いるため奇数であることが望ましい。しかしながら、例えば、認証結果が「正」と「誤」で同数になった場合には「正」とする等の規定を予め決めておくことで、多重化の数を偶数として多数決論理を用いることも可能である。

また、生体認証ＰＦシステム３００は、生体認証の種類に応じて、多重化した複数の同一の生体認証原本情報、または一つの生体認証原本情報を管理してもよい。そして、生体認証ＰＦシステム３００は、生体認証の種類に応じて、多重化した複数の同一の生体認証原本情報、または一つの生体認証原本情報に基づいて、認証処理を実行してもよい。ここで、生体認証の種類は、生体認証の種類毎の認証精度に基づいてもよい。つまり、生体認証ＰＦシステム３００は、生体認証の種類毎の精度に応じて、多重化した複数の同一の生体認証原本情報、または一つの生体認証原本情報に基づいて、認証処理を実行してもよい。これにより、生体認証ＰＦシステム３００は、生体認証の種類毎に適した認証方式の認証サービスを提供することができる。

なお、生体認証ＰＦシステム３００は、複数の個別サービスからの要求に応じて、多重化した複数の同一の生体認証原本情報、または１つの生体認証原本情報を管理してもよい。そして、生体認証ＰＦシステム３００は、複数の個別サービスからの要求に応じて、多重化した複数の同一の生体認証原本情報、または１つの生体認証原本情報に基づいて、認証処理を実行してもよい。これにより、生体認証ＰＦシステム３００は、個別サービス毎に適した認証方式の認証サービスを提供することができる。

また、生体認証ＰＦシステム３００は、生体認証原本情報を多重化して保持する場合、その多重化した生体認証原本情報間の突合処理を行うことにより、多重化した複数の同一の生体認証原本情報のそれぞれが正常であるか否か（即ち、同一性があるか否か）の原本チェックを行ってもよい。
具体的には、原本情報管理部３３１は、所定の契機で、複数の同一の生体認証原本情報のそれぞれを突合する突合処理を実行し、それぞれの生体認証原本情報について同一性があるか否かを判定する。例えば、原本情報管理部３３１は、認証部３４１による認証機能を利用して上記突合処理を行う。そして、原本情報管理部３３１は、判定結果に対して多数決論理を用いて、多数派の生体認証原本情報を正常と判定し、少数派の生体認証原本情報を異常と判定する。ここで、多重化された生体認証原本情報間の突合処理を実行する所定の契機とは、例えば、１時間毎、１２時間毎、２４時間毎(夜間)、トランザクション毎等である。例えば、トランザクション量、トランザクション頻度、ＩＣＴ装置の性能、ソフトウェアの性能等のバランスを考慮し、突合処理を行う契機が設定される。このように、生体認証ＰＦシステム３００は、多重化した生体認証原本情報の原本チェックを行うことにより、安全性及び信頼性の高い生体認証原本情報のデータベースを構築することができる。

例えば、原本情報管理部３３１は、突合処理において異常と判定された生体認証原本情報、又は異常と判定された生体認証原本情報が含まれる複数の同一の生体認証原本情報の全てを、認証処理に用いることを禁止する。これにより、生体認証ＰＦシステム３００は、原本の正当性及び認証結果の正当性を高め、安全性及び信頼性の高い生体認証サービスを提供することができる。

なお、原本情報管理部３３１は、突合処理による判定結果に基づいて、少数派の生体認証原本情報を多数派の生体認証原本情報に置き換えてもよい。これにより、生体認証ＰＦシステム３００は、突合処理において異常と判定された生体認証原本情報を正常と判定された生体認証原本情報に置き換えることで、生体認証原本情報のデータベースを修復することができる。

なお、原本情報管理部３３１は、生体認証原本情報を比較可能な所定のコードに変換して管理し、所定の契機で、複数の同一の生体認証原本情報のそれぞれについて同一性があるか否かを、比較可能な所定のコードで比較して判定するとともに、判定結果に対して多数決論理を用いて、多数派の生体認証原本情報を正常と判定し、少数派の生体認証原本情報を異常と判定してもよい。この比較可能な所定のコードで比較する機能は、原本情報管理部３３１が備えてもよい。また、比較可能な所定のコードで比較する場合、例えば、バイナリデータの比較でもよいし、各ベンダ独自のアルゴリズムによるデータの比較でもよい。これにより、生体認証ＰＦシステム３００は、認証部３４１による認証機能を利用するよりも、原本チェックの処理速度の高速化を図ることができる。

また、原本情報管理部３３１は、生体認証原本情報のそれぞれにインデックス情報を付与して管理し、複数の同一の生体認証原本情報のそれぞれについて同一性があるか否かを判定する場合、インデックス情報を利用して判定対象の生体認証原本情報を特定してもよい。例えば、図９に示す原本情報テーブルＴＢＬ３３１の例において、生体認証原本情報が多重化して格納された場合、多重化して格納された複数の生体認証原本情報毎に原本番号が付与される。例えば、図９に示す原本番号「Ｓ１ＯＲＧ１０１」の顔認証原本情報として、３つの同一の顔認証原本情報が格納された場合、それぞれの原本番号として「Ｓ１ＯＲＧ１０１―１」、「Ｓ１ＯＲＧ１０１―２」、「Ｓ１ＯＲＧ１０１―３」が付与される。これにより、生体認証ＰＦシステム３００は、各生体認証原本情報のインデックス検索が可能となり、処理速度の高速化を図ることができる。

なお、生体認証ＰＦシステム３００は、生体認証原本情報間の突合処理により原本チェックを行う場合には、複数の同一の生体認証原本情報のうち正常と判定された少なくとも一つの生体認証原本情報と、認証用生体情報との認証処理を実行してもよい。この場合、多重化された生体認証原本情報の一つ一つと認証処理を行う場合に比較して、処理速度の高速化や処理負荷の軽減を図ることができる。
このように、本実施形態に係る生体認証ＰＦシステム３００は、生体認証原本情報を多重化（例えば、３重化）して保持し、多数決論理を直接的もしくは間接的に用いて認証結果を決定するので、原本の正当性及び認証結果の正当性を高め、安全性及び信頼性の高い生体認証サービスを提供することができる。

[生体情報の原本登録の本人性及び妥当性]
次に、生体情報の原本登録の本人性及び妥当性について説明する。
生体情報の原本登録は、登録時のオペレーションのミスや不正登録が生じないように本人性及び妥当性等についての厳密性が求められる。但し、生体認証ＰＦシステム３００の普及性を考えると、生体情報の原本登録が容易であることも重要である。図２６は、生体認証ＰＦシステム３００の利用シーンの概要を説明する第２の説明図である。

（ａ）生体認証ＰＦシステム３００の普及性と原本登録の厳密性とを担保する為、店舗数、便利な立地、信用度、通信設備等の条件を満たす社会的に信用のある場所、店舗等（例えば、全国の通信事業者の店舗、役所等）で、原本登録用生体情報を取得することを原則とする。例えば、通信事業者の店舗、役所等にユーザ本人が赴き、通信事業者の社員、役所の所員等の受付担当者（オペレータ、立会人等）の指示に従って、端末５０で生体情報の原本登録を行う（形態１）。ここで、端末５０で生体情報を取得する場合、それぞれの生体情報を取得するためのセンサにより取得される。例えば、顔認証の場合には登録するユーザの顔を撮影するセンサ（カメラ）により取得される。この生体情報を取得するためのセンサ（センサ機能）は、例えば端末５０に備えられている。なお、このセンサは、端末５０と異なる入力装置に備えられていてもよく、入力装置が取得した生体情報が端末５０に送られてもよい。また、他に原本登録の厳密性を担保する原本登録方法として、関係官庁（国土交通省等）、関係団体（大学等の教育機関等）の許可及び法律に抵触しないことを前提に、運転免許証（形態２）、学生証（形態３）等の顔写真データを原本登録用生体情報としてもよい。形態２及び形態３の場合には、あらためてのユーザの写真撮影が不要である。

例えば、生体認証ＰＦシステム３００は、原本登録用生体情報を取得した端末５０が信用のある場所であるか否かを判定するために、ユーザの原本登録用生体情報を取得した端末５０を識別可能な識別情報に基づいて、当該ユーザの原本登録用生体情報に基づく生体認証原本情報を登録するか否かを判定してもよい。端末５０を識別可能な識別情報とは、端末物理ＩＤ、端末論理ＩＤ等である（以下、「端末ＩＤ」ともいう）。この端末ＩＤは、原本登録用生体情報に関連付けられて端末５０から送信される。ここで、この判定処理の機能は、例えば、登録部３１４が備える機能である。これにより、生体認証ＰＦシステム３００は、原本登録の厳密性（本人性及び妥当性）を担保し、普及性及び安全性の高い認証システムを提供することができる。なお、端末５０がスマートフォン等のモビリティ端末である場合には、物理回線ＩＤ、論理回線ＩＤ（インターネットアドレス等）の一致性を確認することにより、生体認証原本情報を登録するか否かを判定してもよい。

さらに、生体認証ＰＦシステム３００は、端末５０で原本登録用生体情報を取得する際の受付担当者の生体認証を行なってもよい。具体的には、登録部３１４は、ユーザの原本登録用生体情報の入力を複数の個別サービスのそれぞれの端末５０（入力装置の一例）で受け付ける受付担当者の生体情報に基づいて、当該ユーザの原本登録用生体情報に基づく生体認証原本情報を登録するか否かを判定してもよい。例えば、登録部３１４は、受付担当者の認証用生体情報が、原本情報管理部３３１に管理されている受付担当者に対応する生体認証原本情報と同一性があると判定された場合、受付担当者が受け付けたユーザの原本登録用生体情報に基づく生体認証原本情報を登録する。一方、登録部３１４は、同一性がないと判定された場合、受付担当者が受け付けたユーザの原本登録用生体情報に基づく生体認証原本情報を登録しない。これにより、生体認証ＰＦシステム３００は、受付担当者の信用性も確認した上で生体認証原本情報を登録するため、安全性の高い認証システムを提供することができる。なお、原本登録時には、金融機関で実施している本人確認（自動車運転免許証、パスポート等写真付き身分等提示）も原則実施される。

（ｂ）原本登録の厳密性を担保する為、生体認証ＰＦシステム３００は、ユーザＩＤを、外部ＩＤから変換関数を実行し、内部ＩＤに変換する。さらに厳密性を考える場合には、生体認証ＰＦシステム３００は、暗号化を実施する。なお、実質的に変換関数実施が暗号化と同等効果を得ると考えられる場合にはあらためて暗号化は省いて構わない。変換関数及び暗号化は、公知の流布した安定した方式（ハッシュ関数を用いた方式等）を適用することができる。

（ｃ）原本登録の厳密性を担保する為、ユーザ本人の了解および法律に抵触しないことを前提に、原本登録するユーザの個人情報（住所、氏名、年齢（生年月日）、性別等）を、金融機関等で利用する与信情報、通信事業者における通信契約情報等と突合し、なりすまし等でないこと、確かに存在する人物であること等を確認する。

具体的には、登録部３１４は、ユーザの原本登録用生体情報を取得した場合、当該ユーザの与信情報、又は当該ユーザの通信契約情報に基づいて、当該ユーザの原本登録用生体情報に基づく生体認証原本情報を登録するか否かを判定する。例えば、登録部３１４は、ユーザの原本登録用生体情報を取得した場合、当該ユーザのユーザ情報と、当該ユーザの与信情報、又は当該ユーザの通信契約情報とを照合し、当該ユーザの本人性、妥当性等が確認された場合に、当該ユーザの原本登録用生体情報に基づく生体認証原本情報を登録する。これにより、生体認証ＰＦシステム３００は、原本登録の厳密性（本人性及び妥当性）を担保し、安全性の高い認証システムを提供することができる。

なお、登録部３１４は、生体認証原本情報を登録した場合、前述したユーザ毎の生体認証処理の利用目的に関する管理情報（例えば、図１７の利用目的設定テーブルＴＢＬ３１８Ａ、図１８の利用目的設定テーブルＴＢＬ３１８Ｂ）を更新する。具体的には、登録部３１４は、ユーザのユーザ情報、原本登録用生体情報、及び、許可サービス情報を取得すると、ユーザ情報（個人情報）と、当該ユーザの与信情報又は当該ユーザの通信契約情報とを照合して、当該ユーザの原本登録用生体情報に基づいて生体認証原本情報を登録する。また、登録部３１４は、当該生体認証原本情報と上記許可サービス情報を関連付ける。

（ｄ）原本登録の厳密性を担保する為、生体認証ＰＦシステム３００は、原本登録用生体情報の取得日時(顔認証なら顔写真の撮影日時）と、原本登録用生体情報の端末５０からの送信日時との差が、送信手続き等に所用する妥当な時間以内であることを確認する。差異が妥当な時間でない場合には、生体認証ＰＦシステム３００は、原本登録用生体情報が差し替えられた可能性があると判断して、原本登録を拒否する。

図２７は、原本登録時のなりすまし及び生体情報の差し替えの防止処理の流れを説明する説明図である。この図を参照してなりすまし及び生体情報の差し替えの防止処理について説明する。
（１）端末５０は、センサ機能を用いて、原本登録用生体情報を取得する。例えば、顔認証用の原本登録を行う場合には、端末５０は、原本登録用のユーザの顔を撮影して原本登録用生体情報として取得する。
（２）端末５０は、取得した原本登録用生体情報を生体認証ＰＦシステム３００に対して送信する。生体認証ＰＦシステム３００は、端末５０から送信された原本登録用生体情報を受信する。

（３）生体認証ＰＦシステム３００は、原本登録用生体情報を受信すると、なりすまし判定と、差し替え判定を行う。なりすまし判定は、上述したように、ユーザの原本登録用生体情報を取得した端末ＩＤ、当該ユーザの与信情報、当該ユーザの通信契約情報等に基づいて判定が行われる。
また、生体情報の差し替え判定は、原本登録用生体情報の取得日時（例えば、撮影日時）と、その原本登録用生体情報が端末５０から送信された送信日時の差により判定が行われる。生体認証ＰＦシステム３００は、原本登録用生体情報の取得日時と送信日時との差が、予め設定された閾値（所定時間）以上であるか否かにより差し替えの有無を判定する。ここで、この予め設定された閾値のことを、「ＧＡＰ制限値」と称して説明する。

例えば、生体認証ＰＦシステム３００は、原本登録用生体情報の取得日時と送信日時との差が、ＧＡＰ制限値未満（例えば、１分未満）である場合には、原本登録を許可する。一方、生体認証ＰＦシステム３００は、原本登録用生体情報の取得日時と送信日時との差が、ＧＡＰ制限値以上（例えば、１分以上）である場合には、原本登録を拒否する。図示する例では、原本登録用生体情報の取得日時（例えば、撮影日時Ｔ０）に対して、送信日時（ここでは、送信日時Ｔ１）がＧＡＰ制限値未満である場合には、原本登録を許可し、送信日時（ここでは、送信日時Ｔ２）がＧＡＰ制限値以上である場合には、原本登録を許可しない（登録拒否）。なお、原本登録用生体情報の送信日時に代えて、生体認証ＰＦシステム３００が原本登録用生体情報を受信した受信日時を用いてもよい。

具体的には、生体認証ＰＦシステム３００において、登録部３１４は、受信したユーザの原本登録用生体情報のタイムスタンプに基づいて、当該ユーザの原本登録用生体情報に基づく生体認証原本情報を登録するか否かを判定する。ここで、タイムスタンプには、受信したユーザの原本登録用生体情報を、センサ機能が搭載された端末５０にて取得した取得日時を示す情報が少なくとも含まれる。

登録部３１４は、受信したユーザの原本登録用生体情報の取得日時（例えば、撮影日時）と、当該原本登録用生体情報が複数の個別サービスのいずれかから送信された送信日時（例えば、端末５０から送信された送信日時）又は複数の個別サービスのいずれかから受信部３１２が受信した受信日時との差に基づいて、当該原本登録用生体情報に基づく生体認証原本情報を登録するか否かを判定する。

（４）登録部３１４は、受信したユーザの原本登録用生体情報の取得日時（例えば、撮影日時）と、上記送信日時又は上記受信日時との差が、ＧＡＰ制限値未満（所定時間未満）である場合には当該原本登録用生体情報に基づく生体認証原本情報を登録する。
（５）一方、登録部３１４は、原本登録用生体情報の取得日時（例えば、撮影日時）と、上記送信日時又は上記受信日時との差が、ＧＡＰ制限値以上（所定時間以上）である場合には当該原本登録用生体情報に基づく生体認証原本情報を登録しない。この場合、生体認証ＰＦシステム３００は、原本登録を許可しないことを示す通知情報（原本登録拒否通知）を端末５０に対して送信する。

このように、本実施形態に係る、生体認証ＰＦシステム３００は、原本登録時に、なりすまし及び生体情報の差し替えの有無を判定することにより、生体情報の原本登録の厳密性（本人性、妥当性）を担保し、安全性及び信頼性の高い生体認証原本情報のデータベースを構築することができる。

なお、登録部３１４は、特定の生体情報については、当該原本登録用生体情報のタイムスタンプに関わらず生体認証原本情報を登録してもよい。ここで、特定の生体情報とは、例えば、信頼性の高い生体情報である。

以上説明してきたように、本実施形態に係る生体認証ＰＦシステム３００によれば、経済性、普及性、及び安全性を兼ね備えた生体認証サービスを提供することができる。

なお、本実施形態では、生体認証ＰＦシステム３００において、顔認証、指紋認証、指静脈認証、掌静脈認証、虹彩認証、歯型認証、声紋認証、及びＤＮＡ認証等の複数の生体情報による認証サービスを提供する例を説明したが、一つの生体情報による認証サービスを提供する構成としてもよい。また、生体認証ＰＦシステム３００は、顔認証、指紋認証、指静脈認証、掌静脈認証、虹彩認証、歯型認証、声紋認証、及びＤＮＡ認証以外の他の生体認証に適用してもよい。

なお、上述した実施形態における生体認証ＰＦシステム３００の一部または全部の機能をコンピュータで実現するようにしてもよい。その場合、上述の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって上述の機能を実現してもよい。なお、ここでいう「コンピュータシステム」とは、端末装置に内蔵されたコンピュータシステムであって、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

また、上述した実施形態における生体認証ＰＦシステム３００の一部または全部を、ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等の集積回路として実現してもよい。生体認証ＰＦシステム３００の各機能ブロックは個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

５０ 端末、１００ 個別ＡＰシステム、２００ ビジネスＰＦシステム、３００ 生体認証ＰＦシステム、３１０ 認証サービスマネジメント機能部、３１１ 通信処理部、３１２ 受信部、３１３ 送信部、３１４ 登録部、３１５ 認証許可部、３１６ 認証結果取得部、３１８ 制御情報記憶部、３２０ ユーザマネジメント機能部、３２１ ユーザ情報管理部、３２２ ユーザ情報記憶部、３３０ 認証データマネジメント機能部、３３１ 原本情報管理部、３３２ 認証管理部、３３３ 原本情報記憶部、３４０ 認証機能ライブラリ機能部、３４１ 認証部、３４２ 認証機能記憶部、ＴＢＬ３２１ ユーザ情報テーブル、ＴＢＬ３３１ 原本情報テーブル、ＴＢＬ３４１ 生体認証機能テーブル、ＴＢＬ３１８Ａ，ＴＢＬ３１８Ｂ 利用目的設定テーブル

Claims (9)

1. 複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理部と、
   前記複数のサービスから受信するユーザの生体情報と、前記管理部が管理する前記原本対応情報とに基づいて、認証処理を実行する認証部と、
   前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記管理部が管理する前記原本対応情報を登録する登録部と、
   を備え、
   前記登録部は、
   前記複数のサービスから受信するユーザの生体情報を取得するとともに、
   あるサービスから取得した生体情報を前記原本対応情報として登録した場合、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報として別のサービスから取得した場合でも、前記別のサービスから取得した生体情報を前記原本対応情報として登録しない、
   生体認証プラットフォームシステム。
2. 前記登録部は、
   あるサービスから取得した生体情報を前記原本対応情報として登録してから予め定めた期間以上経過後に、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報としていずれかのサービスから取得した場合には、取得した生体情報を前記原本対応情報として再登録する、
   請求項１に記載の生体認証プラットフォームシステム。
3. 前記登録部は、
   あるサービスから取得した生体情報を前記原本対応情報として登録した場合であって、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報としていずれかのサービスから取得した場合、取得した生体情報を該生体情報の種別に応じて前記原本対応情報として再登録する、
   請求項１または請求項２に記載の生体認証プラットフォームシステム。
4. 前記登録部は、
   前記管理部が管理する前記原本対応情報と、当該原本対応情報による前記認証処理の実行を許可するサービスを示す許可サービス情報とを関連付ける、
   請求項１から３のいずれか一項に記載の生体認証プラットフォームシステム。
5. 前記登録部は、
   前記ユーザのユーザ情報、生体情報、及び、前記許可サービス情報を取得し、
   前記ユーザ情報と当該ユーザの与信情報とを照合して、当該ユーザの生体情報に基づいて前記原本対応情報を登録し、当該原本対応情報と前記許可サービス情報を関連付ける、
   請求項４に記載の生体認証プラットフォームシステム。
6. 前記登録部は、
   前記ユーザのユーザ情報、生体情報、及び、前記許可サービス情報を取得し、
   前記ユーザ情報と当該ユーザの通信契約情報とを照合して、当該ユーザの生体情報に基づいて前記原本対応情報を登録し、当該原本対応情報と前記許可サービス情報を関連付ける、
   請求項４に記載の生体認証プラットフォームシステム。
7. 複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理部と、
   前記複数のサービスから受信するユーザの生体情報と、前記管理部が管理する前記原本対応情報とに基づいて、認証処理を実行する認証部と、
   前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記管理部が管理する前記原本対応情報を登録する登録部と、
   を備え、
   前記登録部は、
   前記複数のサービスから受信するユーザの生体情報を取得するとともに、
   あるサービスから取得した生体情報を前記原本対応情報として登録した場合、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報として別のサービスから取得した場合でも、前記別のサービスから取得した生体情報を前記原本対応情報として登録しない、
   生体認証情報管理装置。
8. 生体認証情報管理装置における生体認証情報管理方法であって、
   管理部が、複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理過程と、
   認証部が、前記複数のサービスから受信するユーザの生体情報と、前記管理部が管理する前記原本対応情報とに基づいて、認証処理を実行する認証過程と、
   登録部が、前記複数のサービスのうちのいずれかから受信するユーザの生体情報に基づいて、前記管理部が管理する前記原本対応情報を登録する登録過程と、
   登録部が、前記複数のサービスから受信するユーザの生体情報を取得するとともに、あるサービスから取得した生体情報を前記原本対応情報として登録した場合、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報として別のサービスから取得した場合でも、前記別のサービスから取得した生体情報を前記原本対応情報として登録しない、登録判定過程と、
   を有する生体認証情報管理方法。
9. 生体認証情報管理装置としてのコンピュータに、
   複数のサービスでユーザの生体認証を行う際に用いる生体情報の原本に対応する原本対応情報を管理する管理手順と、
   前記複数のサービスから受信するユーザの生体情報と、前記原本対応情報とに基づいて、認証処理を実行する認証手順と、
   前記複数のサービスから受信するユーザの生体情報を取得するとともに、あるサービスから取得した生体情報を前記原本対応情報として登録した場合、同一ユーザの同一の生体情報を前記原本対応情報として登録するための情報として別のサービスから取得した場合でも、前記別のサービスから取得した生体情報を前記原本対応情報として登録しない登録判定手順と、
   を実行させるための生体認証情報管理プログラム。

Images