IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電気株式会社の特許一覧

特許7188660システム、制御サーバ、制御サーバの制御方法、方法及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-12-05
(45)【発行日】2022-12-13
(54)【発明の名称】システム、制御サーバ、制御サーバの制御方法、方法及びプログラム
(51)【国際特許分類】
   G06F 21/32 20130101AFI20221206BHJP
【FI】
G06F21/32
【請求項の数】 17
(21)【出願番号】P 2022557686
(86)(22)【出願日】2022-06-23
(86)【国際出願番号】 JP2022025195
【審査請求日】2022-09-22
【早期審査対象出願】
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100168310
【弁理士】
【氏名又は名称】▲高▼橋 幹夫
(72)【発明者】
【氏名】四分一 大助
(72)【発明者】
【氏名】新宮 由久
(72)【発明者】
【氏名】柳澤 一精
(72)【発明者】
【氏名】太田 知秀
【審査官】行田 悦資
(56)【参考文献】
【文献】特開2005-293544(JP,A)
【文献】特開2007-172308(JP,A)
【文献】特開2020-077421(JP,A)
【文献】特許第5940186(JP,B1)
【文献】特開2011-134030(JP,A)
【文献】国際公開第2015/068694(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/32
(57)【特許請求の範囲】
【請求項1】
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される、複数の第1のサーバと、
前記複数のサービス提供者それぞれの生体認証に関する管理を行う、第2のサーバと、
生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、端末と、
を含み、
前記端末は、前記第2のサーバからの要求に応じて前記原本生体情報を前記第2のサーバに送信し、
前記第2のサーバは、前記複数のサービス提供者のなかから利用者が選択したサービス提供者の前記第1のサーバに、前記原本生体情報を送信し、
前記第1のサーバは、前記原本生体情報から登録用の認証情報を生成する、システム。
【請求項2】
前記第2のサーバは、前記複数のサービス提供者それぞれの情報を保持すると共に、前記利用者による前記サービス提供者の選択を可能とする、請求項1に記載のシステム。
【請求項3】
前記第2のサーバは、前記利用者が前記サービス提供者を選択した後に、前記端末に対して前記原本生体情報の提供を要求する、請求項2に記載のシステム。
【請求項4】
前記端末は、前記サービス提供者に前記原本生体情報が提供されることに対する前記利用者の同意が得られた場合に、前記原本生体情報を前記第2のサーバに送信する、請求項3に記載のシステム。
【請求項5】
前記複数のサービス提供者それぞれのサービス提供場所に設置された、複数の認証端末をさらに含み、
前記複数の認証端末のうち被認証者が訪れたサービス提供場所に設置された認証端末は、前記被認証者の生体情報を含む認証要求を、前記被認証者が訪れたサービス提供場所に対応する前記第1のサーバに送信する、請求項4に記載のシステム。
【請求項6】
前記認証要求を受信した第1のサーバは、前記認証要求に含まれる生体情報から照合用の認証情報を生成し、前記生成された照合用の認証情報と前記登録用の認証情報を用いた認証処理を行う、請求項5に記載のシステム。
【請求項7】
前記複数の第1のサーバのそれぞれは、各サービス提供者が前記生体認証を用いたサービスを提供する際に必要な業務情報と、前記登録用の認証情報と、を対応付けて記憶する、請求項6に記載のシステム。
【請求項8】
前記認証要求を受信した第1のサーバは、前記登録用の認証情報と前記照合用の認証情報を用いた照合処理により特定された被認証者の前記業務情報が有効な場合に、認証成功と判定する、請求項7に記載のシステム。
【請求項9】
前記生体情報は、人の顔画像である、請求項1乃至8のいずれか一項に記載のシステム。
【請求項10】
前記端末は、前記利用者の指示がなければ前記記憶された原本生体情報を削除しない、請求項9に記載のシステム。
【請求項11】
前記複数の第1のサーバ及び前記第2のサーバは、前記利用者の指示がなければ前記受信した原本生体情報を削除する、請求項10に記載のシステム。
【請求項12】
前記原本生体情報は、人の顔画像又は指紋画像である、請求項1に記載のシステム。
【請求項13】
端末から認証情報の原本となる原本生体情報を取得する、取得部と、
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者が選択した前記サービス提供者に対して、前記原本生体情報を前記サービス提供者により運営されるサーバに送信する送信部と、
を備える、制御サーバ。
【請求項14】
制御サーバにおいて、
端末から認証情報の原本となる原本生体情報を取得し、
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者が選択した前記サービス提供者に対して、前記原本生体情報を前記サービス提供者により運営されるサーバに送信する、制御サーバの制御方法。
【請求項15】
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される、複数の第1のサーバと、
前記複数のサービス提供者それぞれの生体認証に関する管理を行う、第2のサーバと、
生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、端末と、
を含むシステムにおいて、
前記端末は、前記第2のサーバからの要求に応じて前記原本生体情報を前記第2のサーバに送信し、
前記第2のサーバは、前記複数のサービス提供者のなかから利用者が選択したサービス提供者の前記第1のサーバに、前記原本生体情報を送信し、
前記第1のサーバは、前記原本生体情報から登録用の認証情報を生成する、方法。
【請求項16】
制御サーバに搭載されたコンピュータに、
端末から認証情報の原本となる原本生体情報を取得する処理と、
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者が選択した前記サービス提供者に対して、前記原本生体情報を前記サービス提供者により運営されるサーバに送信する処理と、
を実行させるためのプログラム。
【請求項17】
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される、複数の第1のサーバ、
前記複数のサービス提供者それぞれの生体認証に関する管理を行う、第2のサーバ、
生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、端末のそれぞれに搭載されたコンピュータのいずれかに、
前記第2のサーバからの要求に応じて前記原本生体情報を前記第2のサーバに送信する処理と、
前記第2のサーバは、前記複数のサービス提供者のなかから利用者が選択したサービス提供者の前記第1のサーバに、前記原本生体情報を送信する処理と、
前記第1のサーバは、前記原本生体情報から登録用の認証情報を生成する処理と、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、システム、端末、端末の制御方法及び記憶媒体に関する。
【背景技術】
【0002】
近年、生体認証を用いたサービスの普及が始まっている。
【0003】
特許文献1には、商品およびサービスの購入における電子マネー決済の安全性と利便性を両立させる、と記載されている。特許文献1に記載の生体認証装置は、ユーザを識別するCIDと顔画像を取得する。生体認証装置は、在店者の顔画像群をあらかじめダウンロードしておき、これらの顔画像群と得られた顔画像を照合することにより、ユーザを認証する。認証に成功したとき、生体認証装置はユーザが購入する商品の料金の決済を決済装置に要求し、決済装置により決済許可されたとき、商品の購入を許可する。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2019-067075号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上述のように、生体認証を用いた様々なサービスの提供が始まっている。生体認証を用いたシステムでは、小売店等に生体認証用の端末を設置し、当該端末から生体情報がサーバに送信される。サーバは、取得した生体情報とデータベースに記憶された生体情報を用いた照合処理を実行し、利用者の特定を行う。
【0006】
利用者は、生体認証を用いたサービスを受ける前に、自身の生体情報(例えば、顔画像)をサーバに登録する必要がある。その際、複数のサービス提供者(例えば、小売業者、交通事業者)それぞれからサービスの提供を受けるためには、利用者は、サービス提供者ごとに生体情報を登録する必要がある。
【0007】
具体的には、利用者は、サービス提供者からサービスの提供を希望するたびに、所謂、自撮り等により生体情報(例えば、顔画像)を取得し、当該取得した生体情報をサーバに登録する必要がある。このような何度も繰り返される登録作業は利用者の大きな負担となっている。
【0008】
本発明は、複数の生体認証サービスを利用する利用者の負担を軽減することに寄与する、システム、端末、端末の制御方法及び記憶媒体を提供することを主たる目的とする。
【課題を解決するための手段】
【0009】
本発明の第1の視点によれば、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される、複数の第1のサーバと、前記複数のサービス提供者それぞれの生体認証に関する管理を行う、第2のサーバと、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、端末と、を含み、前記端末は、前記第2のサーバからの要求に応じて前記原本生体情報を前記第2のサーバに送信し、前記第2のサーバは、前記複数のサービス提供者のなかから利用者が選択したサービス提供者の前記第1のサーバに、前記原本生体情報を送信し、前記第1のサーバは、前記原本生体情報から登録用の認証情報を生成する、システムが提供される。
【0010】
本発明の第2の視点によれば、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、記憶部と、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバからの要求に応じて、前記原本生体情報を前記管理サーバに送信する、送信部と、を備える、端末が提供される。
【0011】
本発明の第3の視点によれば、端末において、生体認証に用いられる認証情報の原本となる原本生体情報を記憶し、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバからの要求に応じて、前記原本生体情報を前記管理サーバに送信する、端末の制御方法が提供される。
【0012】
本発明の第4の視点によれば、端末に搭載されたコンピュータに、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する処理と、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバからの要求に応じて、前記原本生体情報を前記管理サーバに送信する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。
【発明の効果】
【0013】
本発明の各視点によれば、複数の生体認証サービスを利用する利用者の負担を軽減することに寄与する、システム、端末、端末の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。
【図面の簡単な説明】
【0014】
図1図1は、一実施形態の概要を説明するための図である。
図2図2は、一実施形態の動作の一例を示すフローチャートである。
図3図3は、第1の実施形態に係る認証システムの概略構成の一例を示す図である。
図4図4は、第1の実施形態に係る認証システムの動作を説明するための図である。
図5図5は、第1の実施形態に係る端末の表示の一例を示す図である。
図6図6は、第1の実施形態に係る認証システムの動作を説明するための図である。
図7図7は、第1の実施形態に係る端末の表示の一例を示す図である。
図8図8は、第1の実施形態に係る認証システムの動作を説明するための図である。
図9図9は、第1の実施形態に係る管理サーバの処理構成の一例を示す図である。
図10図10は、第1の実施形態に係るアカウント管理データベースの一例を示す図である。
図11図11は、第1の実施形態に係る管理サーバの動作の一例を示すフローチャートである。
図12図12は、第1の実施形態に係るサービスサーバの処理構成の一例を示す図である。
図13図13は、第1の実施形態に係る利用者管理データベースの一例を示す図である。
図14図14は、第1の実施形態に係る認証端末の処理構成の一例を示す図である。
図15図15は、第1の実施形態に係る端末の処理構成の一例を示す図である。
図16図16は、第1の実施形態に係る端末の表示の一例を示す図である。
図17図17は、第1の実施形態に係る認証システムの動作の一例を示すシーケンス図である。
図18図18は、第1の実施形態の変形例に係る端末の表示の一例を示す図である。
図19図19は、第1の実施形態の変形例に係る端末の表示の一例を示す図である。
図20図20は、本願開示に係る管理サーバのハードウェア構成の一例を示す図である。
図21図21は、本願開示の変形例に係る管理サーバの処理構成の一例を示す図である。
図22図22は、本願開示の変形例に係る端末の表示の一例を示す図である。
図23図23は、本願開示の変形例に係る端末の表示の一例を示す図である。
【発明を実施するための形態】
【0015】
はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号(データ)の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
【0016】
一実施形態に係るシステムは、複数の第1のサーバ101と、第2のサーバ102と、端末103と、を含む(図1参照)。複数の第1のサーバ101は、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される。第2のサーバ102は、前記複数のサービス提供者それぞれの生体認証に関する管理を行う。端末103は、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する。端末103は、第2のサーバ102からの要求に応じて原本生体情報を第2のサーバ102に送信する(図2のステップS1)。第2のサーバ102は、複数のサービス提供者のなかから利用者が選択したサービス提供者の第1のサーバ101に、原本生体情報を送信する(ステップS2)。第1のサーバ101は、原本生体情報から登録用の認証情報を生成する(ステップS3)。
【0017】
上記システムにおいて、利用者の端末103に当該利用者の生体情報(認証情報の原本となる生体情報)が記憶されている。当該原本となる生体情報は、利用者が生体認証サービスの享受を希望し、サービス提供者を選択すると、当該原本生体情報を必要とするサービス提供者の第1のサーバ101に対し、第2のサーバ102を介して端末103から原本生体情報が提供される。即ち、利用者は、原本生体情報(例えば、顔画像)を端末103に登録すれば、生体認証サービスの選択(生体認証サービスの追加)のたびに原本生体情報を取得する必要がなくなる。また、第2のサーバ102から第1のサーバ101に原本生体情報(例えば、顔画像)が送信されて、第1のサーバ101が認証情報(特徴量)を生成することで、利用者がサービスを利用する際の、認証のたびに同意を得る必要がない場合もある。その結果、複数の生体認証サービスを利用する利用者の負担が軽減する。
【0018】
以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。
【0019】
[第1の実施形態]
第1の実施形態について、図面を用いてより詳細に説明する。
【0020】
[システムの構成]
図3は、第1の実施形態に係る認証システム(情報処理システム)の概略構成の一例を示す図である。図3に示すように、認証システムには、複数のサービス提供者A~C、管理センターが含まれる。
【0021】
サービス提供者は、生体認証を用いて利用者にサービスを提供する事業者である。本願開示に係る認証システムは、様々な業種、業界に属するサービス提供者が生体認証を用いてサービスを提供することを前提とする。
【0022】
鉄道、航空機等の交通手段を運営する事業者、宿泊サービスを提供する事業者、小売店等の事業者、コンサート等のイベントを提供する事業者、金融サービスを提供する事業者、教育事業者、利用者の勤務先事業者等がサービス提供者として例示される。また、サービス提供者は、小売店等の民間事業者に限らない。自治体等の公的機関がサービス提供者であってもよい。
【0023】
管理センターは、複数のサービス提供者それぞれの生体認証に関する管理を行う。生体認証を用いたサービスの提供を希望する事業者(サービス提供者)は、管理センターを運営する企業、団体等と契約を締結する必要がある。
【0024】
管理センターは、管理サーバ10を備える。管理サーバ10は、管理センターの主たる機能を実現する。管理サーバ10は、管理センターの建物内に設置されていてもよいし、ネットワーク(クラウド)上に設置されたサーバであってもよい。
【0025】
上述のように、サービス提供者は、生体認証を用いたサービスを利用者に提供する。例えば、小売店等での決済手続きが生体認証を用いて行われる。あるいは、イベント会場等におけるチケット確認、ホテルにおけるチェックイン手続き、オフィスにおける勤怠管理、空港における出入国手続き等が生体認証を用いたサービスとして例示される。
【0026】
図3に示すように、各サービス提供者は、サービスサーバ20と、少なくとも1以上の認証端末30と、を備える。サービス提供者が備える装置(サービスサーバ20、認証端末30)は相互に通信可能に接続される。具体的には、サービスサーバ20と認証端末30は、有線又は無線の通信手段により接続される。
【0027】
サービスサーバ20は、ネットワークを介して管理サーバ10と接続されている。サービスサーバ20は、サービス提供者の建物に設置されていてもよいし、クラウド上に設置されていてもよい。
【0028】
サービスサーバ20は、利用者にサービスを提供する際に必要な情報を記憶する。具体的には、サービスサーバ20は、各サービス提供者が生体認証を用いたサービスを提供する際に必要な業務情報と、生体認証に必要な情報と、を記憶する。サービスサーバ20は、利用者管理データベースを用いて、利用者の氏名、生年月日等を含む業務情報と生体認証に必要な情報を記憶する。利用者管理データベースの詳細は後述する。
【0029】
例えば、小売業者のサービスサーバ20は、代金決済に必要な口座情報を記憶する。イベントを主催する事業者のサービスサーバ20は、利用者が購入したチケットに関するチケット情報を記憶する。あるいは、交通事業者のサービスサーバ20は、利用者の定期券に関する情報(例えば、定期券を特定するためのID)を記憶する。あるいは、社員の勤怠管理を行うサービスサーバ20は、社員の社員番号等を記憶する。
【0030】
サービスサーバ20が記憶する生体認証に必要な情報の詳細は後述する。
【0031】
認証端末30は、サービスの提供を受ける利用者のインターフェイスとなる装置である。認証端末30は、各サービス提供者それぞれのサービス提供場所に設置される。より具体的には、認証端末30は、利用者が実際に訪れる店舗等に設置される。
【0032】
認証端末30は、サービス提供者の業種等に応じた機能、形態を備える。例えば、決済サービスを提供するサービス提供者に設置された認証端末30には、タブレット型の端末を用いることができる。あるいは、イベント会場に設置された認証端末30は、利用者の通行を制限するゲートを備えたゲート装置とすることができる。
【0033】
なお、図3は例示であって、本願開示の認証システムの構成等を限定する趣旨ではない。例えば、管理センターには2台以上の管理サーバ10が含まれていてもよい。また、サービス提供者は、少なくとも1台以上のサービスサーバ20と、少なくとも1台以上の認証端末30と、を備えていればよい。
【0034】
[概略動作]
続いて、第1の実施形態に係る認証システムの概略動作について説明する。
【0035】
<アカウント生成>
認証システムに含まれるサービス提供者からサービスの提供を希望する利用者は、システムにアカウントを生成する必要がある。具体的には、利用者は、所持する端末40を操作して、管理サーバ10にアクセスする(図4参照)。
【0036】
利用者は、管理サーバ10が提供するWEB(ウェブ)ページ等において、ログイン情報(例えば、ログインID、パスワード)、氏名、生年月日等を入力する。管理サーバ10は、ログイン情報等を取得すると、当該利用者を識別するためのユーザIDを生成する。管理サーバ10は、生成したユーザID、ログイン情報等を対応付けてアカウント管理データベースに記憶する。アカウント管理データベースの詳細は後述する。
【0037】
<生体情報登録>
生体認証を用いてサービスの提供を受けることを希望する利用者は、自身の生体情報を端末40に登録する必要がある。
【0038】
ここで、生体認証の実行には、生体情報から生成された認証情報の事前登録が必要である。例えば、顔認証の実行時には、顔画像から生成された特徴量(特徴ベクトル)が認証情報として事前に登録されている必要がある。あるいは、指紋認証の実行時には、指紋画像から生成された特徴量が認証情報として事前に登録されている必要がある。
【0039】
以降の説明において、顔画像や指紋画像のように、認証情報を生成する際の原本(基礎)となる情報を「原本生体情報」と表記する。また、原本生体情報から生成され、事前に登録される特徴量を「登録認証情報」と表記する。
【0040】
利用者登録を完了した利用者は、原本生体情報(例えば、顔画像)を所持する端末40に登録する必要がある。端末40は、GUI(Graphical User Interface)等を用いて原本生体情報を取得する。端末40は、取得した原本生体情報(例えば、顔画像)を内部に記憶する。このように、端末40は、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する。
【0041】
<サービスの選択>
システム登録(アカウント作成)及び原本生体情報の登録を行った利用者は、管理サーバ10が提供するポータルサイトにおいて、生体認証サービスの提供を受けたいサービス提供者を選択する。
【0042】
ここで、管理サーバ10は、認証システムに参加しているサービス提供者の情報を記憶する。例えば、管理サーバ10は、サービス提供者の名称、業種、所在地等を記憶する。管理サーバ10は、複数のサービス提供者それぞれの情報を保持すると共に、利用者によるサービス提供者の選択を可能とする。
【0043】
利用者が端末40操作してポータルサイト上にて所定の動作を行うと、管理サーバ10は、利用者が希望するサービス(サービス提供者)の選択を可能とするGUI等を端末40に表示する。
【0044】
例えば、管理サーバ10は、図5に示すようなGUIを用いて利用者が希望するサービス(生体認証サービス)を取得する。
【0045】
<利用者登録>
利用者の選択したサービス提供者を取得すると、管理サーバ10は、端末40に対して原本生体情報の提供を要求する。具体的には、管理サーバ10は、原本提供要求を端末40に送信する(図6のステップS01参照)。
【0046】
原本提供要求を受信すると、端末40は、利用者の原本生体情報(例えば、顔画像)をサービス提供者に提供することについての同意を取得する。例えば、端末40は、図7に示すようなGUIを用いて原本生体情報(例えば、顔画像)を提供することに関する利用者の事前同意(オプトイン)を取得する。即ち、利用者による同意は、提供を希望するサービスの申込をする際に、自身の原本生体情報(例えば、顔画像)を当該希望するサービスを提供する事業者に提供することに対する事前同意(オプトイン)である。
【0047】
端末40は、利用者の同意が得られると、当該利用者の原本生体情報(例えば、顔画像)を管理サーバ10に送信する(図6のステップS02)。
【0048】
管理サーバ10は、取得した原本生体情報、個人特定情報等を利用者が選択したサービスに対応するサービス提供者に通知する。個人特定情報は、利用者を特定するための情報である。個人特定情報として、利用者の氏名、又は、氏名と生年月日の組み合わせが例示される。
【0049】
管理サーバ10は、原本生体情報及び個人特定情報等を含む「利用者登録要求」を利用者が選択したサービス提供者のサービスサーバ20に送信する(ステップS03)。
【0050】
このように、利用者は、スマートフォン等の端末40に格納された原本生体情報(生体情報のマスターデータ)を管理センターの管理サーバ10を介してサービス提供者に提供する。その際、端末40は、利用者の原本生体情報(マスターデータ)は内部に保持し続ける。
【0051】
なお、管理サーバ10は、利用者登録要求をサービスサーバ20に送信したタイミング、又は、当該要求に対する応答を受信したタイミングにおいて、原本生体情報(例えば、顔画像)を削除する。
【0052】
利用者登録要求を受信すると、サービスサーバ20は、生体認証サービスの提供を希望する利用者を特定する。サービスサーバ20は、取得した個人特定情報(例えば、氏名等)をキーとして利用者管理データベースを検索し、対応するエントリ(利用者)を特定する。
【0053】
利用者が特定されると、サービスサーバ20は、取得した原本生体情報から登録認証情報を生成する。例えば、サービスサーバ20は、顔画像を原本生体情報として取得した場合、自社で採用する顔認証アルゴリズムに対応した特徴量(特徴ベクトル)を登録認証情報として生成する。
【0054】
このように、各サービス提供者のサービスサーバ20は、利用者の原本生体情報(例えば、顔画像)から、各サービス提供者が採用する顔認証アルゴリズム(顔認証エンジン、顔認証プログラム)を用いて、登録認証情報を算出する。
【0055】
登録認証情報を生成すると、サービスサーバ20は、当該生成された登録認証情報(例えば、特徴量)を利用者管理データベースに記憶する。
【0056】
なお、サービスサーバ20は、登録認証情報(例えば、特徴量)を生成すると、管理サーバ10から取得した原本生体情報を削除する。
【0057】
利用者登録が正常に終了すると、サービスサーバ20は、その旨を示す肯定応答を管理サーバ10に送信する(ステップS04)。
【0058】
このように、認証システムは、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される、複数のサービスサーバ20(第1のサーバ)を含む。さらに、認証システムは、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバ10(第2のサーバ)を含む。利用者が所持する端末40は、管理サーバ10からの要求に応じて原本生体情報を当該管理サーバ10に送信する。管理サーバ10は、複数のサービス提供者のなかから利用者が選択したサービス提供者のサービスサーバ20に、取得した原本生体情報を送信する。サービスサーバ20は、原本生体情報から登録用の認証情報(登録認証情報)を生成する。
【0059】
<サービスの提供>
サービスの選択を完了した利用者は、サービスの提供を受けるためサービス提供者を訪れる。例えば、利用者は、小売店、イベント会場等自身で選択したサービスの提供を受ける施設、店舗等を訪れる。
【0060】
認証端末30は、サービスの提供を受ける利用者(被認証者)の生体情報を取得する。例えば、認証端末30は、被認証者を撮影し、原本生体情報に対応する生体情報(顔画像)を取得する。認証端末30は、取得した顔画像を含む認証要求をサービスサーバ20に送信する(図8参照)。なお、認証端末30は、必要に応じて、生体情報と共に他の情報(例えば、購入商品に関する代金等の決済情報)をサービスサーバ20に送信する。
【0061】
サービスサーバ20は、取得した顔画像から照合用の認証情報を生成する。例えば、サービスサーバ20は、照合用の顔画像から特徴量を生成する。サービスサーバ20は、当該生成された照合用の認証情報(以下、照合認証情報と表記する)と、利用者管理データベースに登録された登録認証情報と、を用いた照合処理(1対N照合;Nは正の整数、以下同じ)を実行する。
【0062】
サービスサーバ20は、照合処理により利用者管理データベースに登録された利用者(被認証者)を特定する。
【0063】
サービスサーバ20は、特定された利用者の業務情報を用いて当該利用者の認証を行う。例えば、サービスサーバ20は、特定された利用者の口座情報を用いて代金の決済に成功すると「認証成功」と判定する。あるいは、サービスサーバ20は、特定された利用者に対応付けられたチケットが有効であれば「認証成功」と判定する。
【0064】
サービスサーバ20は、認証結果(認証成功、認証失敗)を認証端末30に送信する。
【0065】
認証端末30は、認証結果に応じた処理を実行する。例えば、認証成功を受信すると、小売店に設置された認証端末30は、商品の決済が終了した旨を被認証者に通知する。あるいは、認証成功を受信すると、イベント会場に設置された認証端末30は、被認証者のゲート通過を許可する。
【0066】
このように、認証システムに含まれる複数の認証端末30のうち被認証者が訪れたサービス提供場所に設置された認証端末30は、被認証者の生体情報を含む認証要求を、被認証者が訪れたサービス提供場所に対応するサービスサーバ20に送信する。認証要求を受信したサービスサーバ20は、認証要求に含まれる生体情報から照合用の認証情報を生成し、当該生成された照合用の認証情報と登録用の認証情報を用いた認証処理を行う。より具体的には、認証要求を受信したサービスサーバ20は、登録用の認証情報と照合用の認証情報を用いた照合処理により特定された被認証者の業務情報が有効な場合に、認証成功と判定する。
【0067】
続いて、第1の実施形態に係る認証システムに含まれる各装置の詳細について説明する。
【0068】
[管理サーバ]
図9は、第1の実施形態に係る管理サーバ10の処理構成(処理モジュール)の一例を示す図である。図9を参照すると、管理サーバ10は、通信制御部201と、アカウント管理部202と、事業者管理部203と、サービス選択制御部204と、記憶部205と、を備える。
【0069】
通信制御部201は、他の装置との間の通信を制御する手段である。例えば、通信制御部201は、サービスサーバ20からデータ(パケット)を受信する。また、通信制御部201は、サービスサーバ20に向けてデータを送信する。通信制御部201は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部201は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部201を介して他の装置とデータの送受信を行う。通信制御部201は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0070】
アカウント管理部202は、利用者のアカウントを管理する手段である。アカウント管理部202は、利用者が端末40を操作して、所定のホームページ等にアクセスすると、当該利用者のアカウントを生成するために必要な情報を取得する。
【0071】
具体的には、アカウント管理部202は、ログイン情報、氏名、生年月日等の個人情報を取得する。ログイン情報等を取得すると、アカウント管理部202は、当該利用者を識別するためのユーザIDを生成する。ユーザIDは、利用者を一意に識別できる情報であればどのような情報であってもよい。例えば、アカウント管理部202は、アカウント生成のたびに一意な値を採番しユーザIDとしてもよい。
【0072】
アカウント管理部202は、生成されたユーザID、ログイン情報、氏名等を対応付けてアカウント管理データベースに記憶する(図10参照)。なお、図10に示すアカウント管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、アカウント生成日時等がアカウント管理データベースに記憶されていてもよい。
【0073】
アカウント管理部202は、利用者の端末40から所定のポータルサイトにログインするためのログイン情報を取得する。アカウント管理部202は、ログイン情報を使った認証を行う。
【0074】
事業者管理部203は、認証システムに参加するサービス提供者(サービス事業者)を管理する手段である。事業者管理部203は、各サービス提供者の職員等からシステム登録する事業者情報(サービス提供者の名称、業種、所在地、サービスサーバ20のアドレス等)を取得する。
【0075】
例えば、事業者管理部203は、事業者情報等を入力するためのインターフェイスを各サービス提供者に提供してもよい。あるいは、各サービス提供者は、事業者情報等が格納されたUSB(Universal Serial Bus)メモリ等を管理センターに送付してもよい。事業者管理部203は、管理センターの職員等から事業者情報等を取得してもよい。
【0076】
事業者管理部203は、事業者情報等を取得したサービス提供者についてのID(事業者ID)を生成する。事業者管理部203は、当該生成された事業者ID、取得した事業者情報等を対応付けて記憶する。
【0077】
サービス選択制御部204は、利用者による生体認証サービス(サービス提供者)の選択を制御する手段である。
【0078】
利用者が端末40を操作してポータルサイトにログインし、当該ポータルサイト上で所定の動作を行うと、サービス選択制御部204は、当該利用者が希望するサービスの選択を可能とするGUI等を端末40に表示する。例えば、サービス選択制御部204は、図5に示すようなGUIを端末40に表示する。
【0079】
サービス選択制御部204は、図5に示すようなGUIを表示するために事業者管理部203が取得した事業者情報を用いる。サービス選択制御部204は、事業者情報を参照し、管理センターと契約を締結しているサービス提供者の情報(サービス提供者の一覧)を端末40に表示する。
【0080】
サービス選択制御部204は、サービス提供者の情報を利用者に提供する際、各サービス提供者のより詳細な情報(例えば、業種、提供するサービス、店舗の場所等)も併せて利用者に提供してもよい。
【0081】
利用者が選択したサービス提供者を取得すると、サービス選択制御部204は、利用者が所持する端末40に「原本提供要求」を送信する。サービス選択制御部204は、端末40から利用者の原本生体情報(例えば、顔画像)を受信する。
【0082】
サービス選択制御部204は、利用者のユーザID、取得した原本生体情報及び個人特定情報等を含む利用者登録要求を、利用者が選択したサービスに対応するサービス提供者のサービスサーバ20に送信する。
【0083】
サービス選択制御部204は、利用者登録要求に対する応答(肯定応答、否定応答)を受信する。
【0084】
肯定応答(利用者登録に成功)を受信した場合、サービス選択制御部204は、利用者が選択したサービス提供者の事業者IDをアカウント管理データベースに登録する。即ち、サービス選択制御部204は、利用者によるサービス選択をアカウント管理データベースに反映する。また、肯定応答を受信した場合、サービス選択制御部204は、利用者登録に成功した旨を利用者に通知する。
【0085】
否定応答(利用者登録に失敗)を受信した場合、サービス選択制御部204は、その旨を利用者に通知する。
【0086】
記憶部205は、管理サーバ10の動作に必要な情報を記憶する手段である。
【0087】
利用者登録に関する上記説明した管理サーバ10の動作を纏めると図11に示すフローチャートのとおりとなる。
【0088】
管理サーバ10は、利用者が提供を希望する生体認証サービス(サービス提供者)を取得する(選択サービスを取得;ステップS101)。
【0089】
管理サーバ10は、利用者が所持する端末40に「原本提供要求」を送信することで、原本生体情報を取得する(ステップS102)。その際、端末40により、利用者の同意(原本生体情報がサービス提供者に提供されることの同意)が取得される。
【0090】
管理サーバ10は、取得した原本生体情報(例えば、顔画像)と個人特定情報(例えば、氏名)を含む利用者登録要求をサービスサーバ20に送信する(ステップS103)。
【0091】
管理サーバ10は、サービスサーバ20から利用者登録要求に対する応答を受信する(ステップS104)。
【0092】
管理サーバ10は、利用者登録の成否を利用者に通知する(ステップS105)。
【0093】
[サービスサーバ]
図12は、第1の実施形態に係るサービスサーバ20の処理構成(処理モジュール)の一例を示す図である。図12を参照すると、サービスサーバ20は、通信制御部301と、業務情報管理部302と、利用者登録制御部303と、認証部304と、記憶部305と、を備える。
【0094】
通信制御部301は、他の装置との間の通信を制御する手段である。例えば、通信制御部301は、管理サーバ10からデータ(パケット)を受信する。また、通信制御部301は、管理サーバ10に向けてデータを送信する。通信制御部301は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部301は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部301を介して他の装置とデータの送受信を行う。通信制御部301は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0095】
業務情報管理部302は、サービス提供者が業務の提供に必要な業務情報に関する管理、制御を行う手段である。
【0096】
業務情報管理部302は、任意の手段を用いて自社のサービス提供に必要な業務情報を取得する。例えば、業務情報管理部302は、利用者の氏名、生年月日等の情報に加え、自社のサービス提供に特有な情報を取得する。例えば、小売業者の業務情報管理部302は、クレジットカード情報、銀行口座等の口座情報を取得する。イベント事業者の業務情報管理部302は、利用者が購入したチケットの情報(チケット番号、イベント開催日、イベント開催場所等)を取得する。
【0097】
業務情報管理部302は、サービス提供者の職員等から上記業務情報を取得してもよいし、ホームページ等の手段を用いて利用者から直接、取得してもよい。即ち、利用者は、端末40を操作して、各サービス提供者のサービスサーバ20に個別にアクセスし、サービス提供者がサービスの提供に必要な業務情報を当該サービスサーバ20に登録してもいい。また、業務情報管理部302は、サービスの提供時期に応じて、サービス提供に必要な情報を取得する。例えば、感染症が流行している時期には、業務情報管理部302は、当該感染症に関するワクチン接種証明書や陰性証明書等を業務情報として取得してもよい。
【0098】
業務情報管理部302は、取得した業務情報を、利用者管理データベースを用いて管理する。
【0099】
なお、業務情報管理部302のより詳細な説明は省略する。個別のサービスにおける業務情報の詳細やその取得方法は、本願開示の趣旨とは異なるためである。
【0100】
利用者登録制御部303は、サービス提供者による生体認証サービスの提供対象となる利用者の登録を制御する手段である。利用者登録制御部303は、管理サーバ10から受信した利用者登録要求を処理する。
【0101】
利用者登録要求を受信すると、利用者登録制御部303は、当該利用者登録要求に含まれる個人特定情報(例えば、氏名)をキーとして利用者管理データベースを検索し、対応する利用者(エントリ)を特定する。
【0102】
対応する利用者が利用者管理データベースに登録されていると、利用者登録制御部303は、取得した原本生体情報(例えば、顔画像)から登録認証情報を生成する。例えば、顔画像を取得した場合、利用者登録制御部303は、自社で採用する顔認証アルゴリズムに対応した特徴量(特徴ベクトル)を登録認証情報として生成する。
【0103】
特徴量の生成処理に関しては既存の技術を用いることができるので、その詳細な説明を省略する。例えば、利用者登録制御部303は、顔画像から目、鼻、口等を特徴点として抽出する。その後、利用者登録制御部303は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算し、複数の特徴量からなる特徴ベクトル(顔画像を特徴づけるベクトル情報)を生成する。
【0104】
登録認証情報(例えば、特徴量)を生成すると、利用者登録制御部303は、利用者のユーザID、生成された登録認証情報(特徴量)及び業務情報を対応付けて利用者管理データベースに記憶する(図13参照)。
【0105】
なお、図13に示す利用者管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、利用者登録の日時等が利用者管理データベースに登録されていてもよい。また、図13に示すユーザIDは、管理サーバ10により生成されたIDである。業務情報管理部302は、自社で独自に利用者を管理するためのIDを生成し、当該生成されたIDを利用者管理データベースに記憶してもよい。
【0106】
利用者登録が正常に終了すると、利用者登録制御部303は、利用者登録に成功した旨を示す肯定応答を管理サーバ10に送信する。
【0107】
利用者登録が正常に終了しなければ、利用者登録制御部303は、利用者登録に失敗した旨を示す否定応答を管理サーバ10に送信する。例えば、管理サーバ10から受信した個人特定情報(例えば、氏名)が利用者管理データベースに登録されていない場合や原本生体情報から有効な登録認証情報が生成できない場合等に、否定応答が管理サーバ10に送信される。
【0108】
認証部304は、被認証者の生体認証を行う手段である。認証部304は、認証端末30から認証要求を受信する。認証部304は、認証要求から生体情報(例えば、顔画像)を取り出す。
【0109】
認証部304は、取得した生体情報から照合認証情報を生成する。例えば、顔画像を取得すると、認証部304は、自社で採用している顔認証アルゴリズムに対応した特徴量を生成する。認証部304は、生成した照合認証情報(特徴量)と、利用者管理データベースに登録された登録認証情報(特徴量)と、を用いた照合処理を実行する。
【0110】
具体的には、認証部304は、照合対象の特徴量(特徴ベクトル)と登録側の複数の特徴量それぞれとの間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。
【0111】
類似度が所定の値以上の特徴量が存在しなければ、認証部304は、認証結果を「認証失敗」に設定する。
【0112】
類似度が所定の値以上の特徴量が存在すれば、認証部304は、利用者管理データベースに登録された複数のエントリのうち最も類似度が高い特徴量(登録認証情報)を持つエントリ(利用者)を特定する。認証部304は、特定された利用者の業務情報を用いて被認証者の認証を行う。
【0113】
例えば、小売業者の認証部304は、認証端末30から取得した決済情報と利用者管理データベースに登録された口座情報を用いて商品代金の決済に成功すると「認証成功」と判定する。対して、認証部304は、商品代金の決済に失敗すると「認証失敗」と判定する。
【0114】
あるいは、イベント事業者の認証部304は、利用者管理データベースに登録された被認証者のチケット情報が有効であれば「認証成功」と判定する。対して、認証部304は、利用者管理データベースに登録された被認証者のチケット情報が無効であれば「認証失敗」と判定する。
【0115】
なお、各サービス提供者における業務情報を用いた認証処理に関するより詳細な説明を省略する。各サービス提供者に特有な処理は本願開示の趣旨とは異なるためである。
【0116】
認証部304は、認証結果(認証成功、認証失敗)を認証端末30に送信する。
【0117】
記憶部305は、サービスサーバ20の動作に必要な情報を記憶する手段である。
【0118】
[認証端末]
図14は、第1の実施形態に係る認証端末30の処理構成(処理モジュール)の一例を示す図である。図14を参照すると、認証端末30は、通信制御部401と、生体情報取得部402と、認証要求部403と、機能実現部404と、記憶部405と、を備える。
【0119】
通信制御部401は、他の装置との間の通信を制御する手段である。例えば、通信制御部401は、サービスサーバ20からデータ(パケット)を受信する。また、通信制御部401は、サービスサーバ20に向けてデータを送信する。通信制御部401は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部401は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部401を介して他の装置とデータの送受信を行う。通信制御部401は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0120】
生体情報取得部402は、カメラを制御し、被認証者の生体情報(例えば、顔画像)を取得する手段である。生体情報取得部402は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。生体情報取得部402は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。
【0121】
なお、生体情報取得部402による顔画像の検出処理や顔画像の抽出処理には既存の技術を用いることができるので詳細な説明を省略する。例えば、生体情報取得部402は、CNN(Convolutional Neural Network)により学習された学習モデルを用いて、画像データの中から顔画像(顔領域)を抽出してもよい。あるいは、生体情報取得部402は、テンプレートマッチング等の手法を用いて顔画像を抽出してもよい。
【0122】
生体情報取得部402は、抽出した顔画像を認証要求部403に引き渡す。
【0123】
認証要求部403は、サービスサーバ20に対して被認証者の認証を要求する手段である。認証要求部403は、被認証者の認証が必要になると、被認証者(認証端末30の面前の利用者)の生体情報を含む認証要求をサービスサーバ20に送信する。
【0124】
認証要求部403は、サービスサーバ20から認証結果(認証成功、認証失敗)を受信する。認証要求部403は、受信した認証結果を機能実現部404に引き渡す。
【0125】
機能実現部404は、認証端末30に割り当てられた機能を実現する手段である。例えば、小売業者に設置された認証端末30の機能実現部404は、認証成功を受信すると、決済が完了した旨を被認証者に通知する。あるいは、イベント会場に設置された認証端末30の機能実現部404は、認証成功を受信すると、ゲートを開き被認証者の入場を許可する。
【0126】
なお、各サービス提供者の認証端末30に含まれる機能実現部404に関するより詳細な説明は省略する。機能実現部404による認証端末30の機能実現は、本願開示の趣旨とは異なるためである。
【0127】
記憶部405は、認証端末30の動作に必要な情報を記憶する手段である。
【0128】
[端末]
図15は、第1の実施形態に係る端末40の処理構成(処理モジュール)の一例を示す図である。図15を参照すると、端末40は、通信制御部501と、アカウント生成制御部502と、原本情報取得部503と、サービス選択部504と、記憶部505と、を備える。
【0129】
通信制御部501は、他の装置との間の通信を制御する手段である。例えば、通信制御部501は、管理サーバ10からデータ(パケット)を受信する。また、通信制御部501は、管理サーバ10に向けてデータを送信する。通信制御部501は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部501は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部501を介して他の装置とデータの送受信を行う。通信制御部501は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
【0130】
アカウント生成制御部502は、利用者によるアカウント生成を制御する手段である。アカウント生成制御部502は、利用者の操作に応じて、管理サーバ10が提供する所定のWEBページ等にアクセスする。
【0131】
アカウント生成制御部502は、利用者の操作に応じて、当該WEBページに、ログイン情報、氏名、生年月日等を入力する。
【0132】
原本情報取得部503は、利用者の生体情報(原本生体情報)を取得する手段である。原本情報取得部503は、利用者の操作に応じて、原本生体情報(例えば、顔画像)を取得するためのGUI等を表示する。例えば、原本情報取得部503は、図16に示すようなGUIを用いて原本生体情報を取得する。
【0133】
原本情報取得部503は、取得した原本生体情報(例えば、顔画像)を記憶部505に格納する。その際、原本情報取得部503は、取得した原本生体情報に暗号化、コード化等を施し、当該暗号化された原本生体情報を記憶部505に記憶してもよい。即ち、利用者が所持する端末40は、暗号化された原本生体情報を保持してもよい。暗号化された原本生体情報は、原本生体情報が管理サーバ10に送信される際に復号されてもよい。あるいは、暗号化された原本生体情報を復号するための情報(例えば、共通鍵)が端末40と管理サーバ10の間で共有され、管理サーバ10が暗号化された原本生体情報を復号してもよい。
【0134】
なお、端末40は、原則として、利用者の原本生体情報(例えば、顔画像)を削除(破棄)しない。即ち、端末40は、利用者からの明確な指示がなければ記憶部505に記憶された原本生体情報を削除しない。
【0135】
サービス選択部504は、利用者による生体認証サービスの選択を可能とする手段である。サービス選択部504は、利用者の操作に応じて、管理サーバ10が提供するポータルサイトにログインする。サービス選択部504は、管理サーバ10が提供するGUIを用いて利用者が選択したサービス提供者の情報を管理サーバ10に送信する。
【0136】
サービス選択部504は、管理サーバ10から原本提供要求を受信する。当該要求を受信すると、サービス選択部504は、自装置の内部に格納された原本生体情報(例えば、顔画像)をサービス提供者に提供することに関する利用者の同意を取得する。例えば、サービス選択部504は、図7に示すようなGUIを用いて原本生体情報(例えば、顔画像)の提供可否を取得する。
【0137】
サービス選択部504は、利用者の同意が得られると、原本生体情報を管理サーバ10に送信する。
【0138】
記憶部505は、端末40の動作に必要な情報を記憶する手段である。
【0139】
[システムの動作]
続いて、第1の実施形態に係る認証システムの動作について説明する。なお、アカウント生成等に関する動作の説明は省略する。図17は、第1の実施形態に係る認証システムの動作の一例を示すシーケンス図である。
【0140】
端末40は、利用者が選択したサービスの情報(利用者が生体認証サービスの提供を受けたいサービス提供者の情報)を管理サーバ10に送信する(サービスの情報を送信;ステップS10)。
【0141】
利用者が提供を受けたいサービスを選択すると、管理サーバ10は、原本提供要求を当該利用者の端末40に送信する(ステップS11)。即ち、管理サーバ10は、利用者がサービス提供者を選択した後に、当該利用者が所持する端末40に対して原本生体情報の提供を要求する。
【0142】
原本提供要求を受信した端末40は、原本生体情報を提供する前に、利用者の同意を取得する(ステップS12)。
【0143】
利用者の同意が得られると、端末40は、原本生体情報(例えば、顔画像)を管理サーバ10に送信する(ステップS13)。即ち、利用者が所持する端末40は、サービス提供者に原本生体情報が提供されることに対する利用者の同意が得られた場合に、原本生体情報を管理サーバ10に送信する。
【0144】
管理サーバ10は、取得した原本生体情報、利用者のユーザID及び個人特定情報等を含む利用者登録要求を、利用者が選択したサービス提供者のサービスサーバ20に送信する(ステップS14)。
【0145】
サービスサーバ20は、取得した原本生体情報から登録用の認証情報(登録認証情報)を生成する(ステップS15)。生成された登録認証情報は、利用者管理データベースに登録される。
【0146】
続いて、第1の実施形態に係る変形例について説明する。
【0147】
<変形例1>
サービスサーバ20は、被認証者の認証に必要な情報を当該被認証者の端末40から取得してもよい。例えば、イベント会場に入場する際、入場者の健康情報(感染症に関するワクチン接種の有無、陰性証明)の確認が必要な場合、サービスサーバ20は、認証端末30を介して当該健康情報を端末40から取得してもよい。あるいは、サービスサーバ20は、チケットの情報や商品の決済に必要な業務情報を、認証端末30を介して取得してもよいし、これらの業務情報を端末40及び管理サーバ10を介して取得してもよい。
【0148】
この場合、認証端末30は、端末40に対して「付随情報提供要求」を送信する。当該付随情報提供要求の受信に応じて、端末40は、認証端末30から指定された情報(例えば、ワクチン接種証明書や陰性証明書)を認証端末30に送信する。
【0149】
認証端末30は、被認証者の生体情報と共に取得したワクチン接種証明書等をサービスサーバ20に送信する。
【0150】
サービスサーバ20は、被認証者の業務情報(例えば、チケット情報)と取得したワクチン接種証明書等を用いて被認証者を認証する。例えば、サービスサーバ20は、被認証者が有効なチケットを購入しており、且つ、ワクチン接種証明書が有効な場合に、認証成功と判定する。
【0151】
このように、サービスサーバ20は、被認証者の端末40から取得した付随情報を用いて被認証者を認証してもよい。
【0152】
<変形例2>
サービス提供者(サービスサーバ20)は、利用者から明示的な同意が得られていれば、登録認証情報を一時的又は恒久的に記憶しておいてもよい。
【0153】
例えば、利用者は、サービス選択時に、サービス提供者による登録認証情報等の取り扱いを当該サービス提供者に指示してもよい。具体的には、端末40は、利用者がサービス提供者を選択した際、「登録認証情報の保持に関する可否」を問い合わせるGUI等を表示してもよい(図18参照)。あるいは、端末40は、サービス提供者が登録認証情報を保持できる期間や保持できる期限を利用者に問い合わせるようなGUI等を表示してもよい。
【0154】
利用者の認証情報の取り扱いに関する指示は、利用者登録要求と共にサービスサーバ20に送信される。サービスサーバ20は、当該指示に従い、登録認証情報の取り扱いを定める。
【0155】
また、端末40は、利用者の利便性を考えて、登録認証情報等の取り扱いに関する提案を行ってもよい。例えば、ホテルでのチェックイン手続き、イベント会場への入場、航空機への搭乗手続きといった一度の手続きが終了と共に業務情報も不要となる手続きに関しては、端末40は、登録認証情報の削除を利用者に提案する。対して、オフィスへの勤怠管理に関しては、同じ業務情報が繰り返し用いられる。この場合、端末40は、少なくとも登録認証情報をサービスサーバ20に残すような提案を利用者に行う。
【0156】
このように、サービス提供者の業種、業態により、登録認証情報はサービスサーバ20に保持されていてもよいし、認証処理の完了と共に削除されてもよい。即ち、サービス提供者ごとに、登録認証情報(特徴量)は恒久的に保持されるか否か(登録認証情報の利用が終わると(認証に成功すると)削除されるか否か)定められていてもよい。
【0157】
<変形例3>
上記説明したように、管理センター(管理サーバ10)及びサービス提供者(サービスサーバ20)は、原則として、利用者の原本生体情報(例えば、顔画像)を削除する。ただし、管理サーバ10、サービスサーバ20は、利用者から明示的な同意が得られていれば、原本生体情報(例えば、顔画像)を一時的又は恒久的に記憶しておいてもよい。
【0158】
また、原本生体情報を記憶する場合、管理サーバ10は、利用者により選択されたサービス提供者からの要求に応じて、原本生体情報を当該サービス提供者に提供してもよい。
【0159】
例えば、サービス提供者が原本生体情報を記憶しておらず、自社で採用する認証アルゴリズムを変更した場合を考える。この場合、サービス提供者(サービスサーバ20)は、利用者のユーザIDを含む原本生体情報を管理サーバ10に送信する。管理サーバ10は、取得したユーザIDに対応する原本生体情報をサービスサーバ20に送信する。
【0160】
サービスサーバ20は、取得した原本生体情報を用いて新たに採用した認証アルゴリズムに適合する登録認証情報を生成する。
【0161】
なお、管理サーバ10は、原本生体情報をサービスサーバ20に提供する前に、利用者から当該原本生体情報の提供に関する同意を取得してもよい。管理サーバ10は、利用者から同意が得られた場合に限り、原本生体情報をサービスサーバ20に送信する。
【0162】
また、サービスサーバ20が、原本生体情報を保持している場合、自社で採用する認証アルゴリズムが変更となった際、当該保持している原本生体情報を用いて新たに採用する認証アルゴリズム用の登録認証情報(特徴量)を生成してもよい。このように、サービスサーバ20は、原則として、登録認証情報(特徴量)を算出した後に原本生体情報(顔画像)を削除する。しかし、サービスサーバ20は、利用者の同意あれば、原本生体情報(顔画像)を保持していてもよい。
【0163】
なお、管理サーバ10が原本生体情報(例えば、顔画像)を保持しておらず、サービス提供者が採用する認証アルゴリズムの変更などでサービスサーバ20から原本生体情報の提供に関する要求を受信した場合、端末40に原本生体情報の提供を依頼してもよい。即ち、管理サーバ10が顔画像を保持していない場合、管理サーバ10は、サービスサーバ20からの要求を受信するたびに、利用者の端末40に問い合わせて、顔画像を取得し、当該取得した顔画像をサービスサーバ20に送信してもよい。
【0164】
<変形例4>
本願開示の認証システムは、利用者がサービス提供者を選択した際、当該選択されたサービス提供者が必要とする業務情報を取得してもよい。例えば、利用者が小売業者からサービスの選択を希望した場合、端末40は、当該小売業者に提供する業務情報(例えば、クレジットカード情報)を取得してもよい。この場合、端末40は、図19に示すようなGUIを用いてクレジットカード情報を取得する。
【0165】
端末40は、利用者の原本生体情報と共に取得した業務情報(例えば、クレジットカード情報)を管理サーバ10に送信する。
【0166】
あるいは、利用者がイベント事業者を選択した場合、端末40は、当該イベント事業者が提供するチケット販売サイトに接続してもよい。利用者がチケットを購入すると、端末40は、当該利用者が購入したチケットのチケット情報をチケット販売サイトから取得する。
【0167】
端末40は、利用者の原本生体情報と共に、上記取得したチケット情報を管理サーバ10に送信する。管理サーバ10は、利用者の原本生体情報、チケット情報等を含む利用者登録要求をサービスサーバ20に送信する。
【0168】
このように、端末40は、利用者が選択したサービス提供者に関する業務情報を取得し、当該取得した業務情報を原本生体情報と共に管理サーバ10に送信してもよい。
【0169】
以上のように、第1の実施形態に係る認証システムでは、生体認証に必要な原本生体情報(例えば、顔画像)は利用者の端末40に格納されている。利用者が、生体認証サービスの享受を希望すると、当該利用者がサービス提供者を選択した後に、端末40に格納された原本生体情報は、上記選択されたサービス提供者(登録認証情報を必要とするサービス提供者)に提供される。利用者は、一度、自身の生体情報(例えば、顔画像)を端末40に登録することで、各サービス(様々なサービス提供場所)それぞれに生体情報を登録することなく、各サービスを享受できる。即ち、利用者は、一度、自身の顔を撮影すれば、当該顔画像を用いて様々な場所(サービス)において再び顔登録を行わず、顔認証サービスを利用することができる。換言すれば、一度の生体情報の登録で、生体認証を用いた様々なソリューションに当該生体情報が適用可能である。
【0170】
また、上記構成により、サービス提供者が生体認証サービスを提供する際に生じる種々の問題が解決される。既存のシステムでは、サービス提供者は、サービス提供場所(サービス)ごとに利用者に顔画像の登録をして貰う必要があった。しかし、第1の実施形態に係るシステムでは、利用者が1回の顔登録を行えば十分であり、顔登録誘導の負担が大幅に減少する。また、サービス提供者は、原本生体情報(顔画像)を保持する必要がなく、サービス提供者の情報漏洩等に対する負担が軽減する。とりわけ、同じサービス提供者が、複数の顔認証アルゴリズムを採用している場合、各顔認証アルゴリズムに対応した顔画像を所持する必要がなくなるので、当該サービス提供者の経営リスクが低減する。また、利用者の同意の下、管理センターが原本生体情報を記憶することで、サービス提供者は、自社で採用する顔認証エンジンを変更したり、提供サービスに適した顔認証エンジンを新たに採用したりすることができる。即ち、サービス提供者は、特定ベンダーの顔認証エンジンに限定されず、用途に適した様々なベンダーの顔認証エンジンを採用することができる。その結果、サービス提供者は、1社のベンダー(1つの顔認証エンジン)に過度に依存する事業リスクを回避できる。即ち、本願開示の認証システムに参加するサービス提供者は、マルチベンダー対応が容易に可能である。
【0171】
また、利用者側の観点では、同じサービス(同じサービス提供者)にも関わらず、何度も顔画像を登録する必要がないので、利用者の利便性が向上する。また、原本生体情報(顔画像)は自身の端末40に留め置かれ、外部の会社等に自身の顔画像が保持されることがないので、情報漏洩等に対する不安が低減する。即ち、利用者は、安心して生体認証サービスを享受できる。
【0172】
続いて、認証システムを構成する各装置のハードウェアについて説明する。図20は、管理サーバ10のハードウェア構成の一例を示す図である。
【0173】
管理サーバ10は、情報処理装置(所謂、コンピュータ)により構成可能であり、図20に例示する構成を備える。例えば、管理サーバ10は、プロセッサ311、メモリ312、入出力インターフェイス313及び通信インターフェイス314等を備える。上記プロセッサ311等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。
【0174】
但し、図20に示す構成は、管理サーバ10のハードウェア構成を限定する趣旨ではない。管理サーバ10は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス313を備えていなくともよい。また、管理サーバ10に含まれるプロセッサ311等の数も図20の例示に限定する趣旨ではなく、例えば、複数のプロセッサ311が管理サーバ10に含まれていてもよい。
【0175】
プロセッサ311は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、DSP(Digital Signal Processor)等のプログラマブルなデバイスである。あるいは、プロセッサ311は、FPGA(Field Programmable Gate Array)、ASIC(Application Specific Integrated Circuit)等のデバイスであってもよい。プロセッサ311は、オペレーティングシステム(OS;Operating System)を含む各種プログラムを実行する。
【0176】
メモリ312は、RAM(Random Access Memory)、ROM(Read Only Memory)、HDD(Hard Disk Drive)、SSD(Solid State Drive)等である。メモリ312は、OSプログラム、アプリケーションプログラム、各種データを格納する。
【0177】
入出力インターフェイス313は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
【0178】
通信インターフェイス314は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス314は、NIC(Network Interface Card)等を備える。
【0179】
管理サーバ10の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ312に格納されたプログラムをプロセッサ311が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント(non-transitory)なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。
【0180】
なお、サービスサーバ20、認証端末30、端末40等も管理サーバ10と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は管理サーバ10と相違する点はないので説明を省略する。例えば、認証端末30は、被認証者を撮影するためのカメラ装置を備えていればよい。
【0181】
情報処理装置である管理サーバ10は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで管理サーバ10の機能が実現できる。また、管理サーバ10は、当該プログラムにより管理サーバ10の制御方法を実行する。同様に、情報処理装置である端末40は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで端末40の機能が実現できる。また、端末40は、当該プログラムにより端末40の制御方法を実行する。
【0182】
[変形例]
なお、上記実施形態にて説明した認証システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。
【0183】
上記実施形態では、人の「顔」を生体情報の例にとり認証システムの動作を説明した。しかし、本願開示の認証システムは、他の種類の生体情報を用いることもできる。例えば、指紋、声紋、静脈、網膜、瞳の虹彩の模様(パターン)といった個人に固有の身体的特徴を備えるデータが用いられてもよい。即ち、利用者の生体情報は、利用者の身体的特徴を情報として含むものであればよい。
【0184】
サービスサーバ20は、利用者を認証することで得られたデータを管理サーバ10に提供してもよい。具体的には、サービスサーバ20は、利用者のユーザID、生体認証から得られる行動情報(例えば、認証成功日時、認証成功場所、購入商品等)を管理サーバ10に送信する。管理サーバ10は、利用者のユーザIDに基づいて各サービス提供者から得られる行動情報を統合し、当該利用者の行動履歴を生成してもよい。生成された行動履歴は、管理サーバ10が活用してもよいし、匿名化処理等が施された状態で他の事業者に販売されてもよい。管理センターの運営主体や他の事業者は、自社単独では得ることができない利用者の行動履歴を解析し、当該利用者の嗜好、位置、時間等を考慮した情報提供(情報配信)を行うことができる。即ち、利用者の行動履歴は広告ビジネスに活用されてもよい。
【0185】
管理センターは、サービス提供者から認証システムのサービス利用料を得ることができる。当該サービス利用料は、サービス提供者に利用者登録された利用者の数に応じて決定されてもよい。あるいは、サービス利用料は、サービス提供者における認証回数に応じて決定されてもよい。
【0186】
上記実施形態では、端末40は、利用者からの明確な指示がなければ当該利用者の原本生体情報(例えば、顔画像)を保持し続けることを説明した。ただし、端末40は、定期的又は所定のタイミングで当該保持された原本生体情報の更新を利用者に依頼(指示)してもよい。即ち、子供等に顕著であるが、時間の経過と共に人の顔(人相)が変化する。端末40は、当該顔の変化を考慮して、定期的又は所定のタイミングで、登録生体情報の更新を利用者に依頼する。
【0187】
あるいは、端末40は、利用者がSNS(Social Networking Service)等のために撮影した顔画像と、生体認証サービスの登録のための原本生体情報(顔画像)と、を比較し、2つの顔画像の類似度が低下していれば、登録顔画像の更新を依頼してもよい。この場合、端末40は、2枚の顔画像の類似度を計算し、当該計算された類似度に対する閾値処理の結果に応じて、上記原本生体情報の更新を依頼(指示)してもよい。
【0188】
管理サーバ10は、端末40から提供された原本生体情報(例えば、顔画像)の品質を検証する機能を備えていてもよい(図21参照)。例えば、図21に示す品質検証部206は、利用者がサービス提供者に提供しようとしている顔画像の品質をチェックする。例えば、品質検証部206は、顔画像の明るさや特徴量の生成に必要な特徴点(例えば、目、鼻等)が映っているか否か等に基づいて顔画像の品質を検証する。品質検証部206は、取得した顔画像の品質が所定の基準を満たしていなければ、端末40に顔画像の再送信を要求する。当該要求を受けた端末40は、顔画像の再取得を利用者に要求する。品質検証部206は、取得した顔画像の品質が所定の基準を満たしていれば、サービス提供者のサービスサーバ20に顔画像(原本生体情報)を送信する。このような構成により、管理サーバ10の後段のサービスサーバ20が、登録処理(特徴量の生成処理)に失敗する可能性を減らすことができる。
【0189】
利用者の端末40は、利用者が、原本生体情報や登録認証情報に対する各サービス提供者の扱い(例えば、恒久的に保持、所定期間保持、直ぐに削除)を即座に把握できるような一覧情報を表示してもよい。例えば、端末40は、図22に示すように、各事業者(例えば、管理センター、サービス提供者)の原本生体情報に対する扱いを一覧表示してもよい。あるいは、端末40は、図23に示すように、各サービス提供者の登録認証情報(例えば、特徴量)に対する扱いを一覧表示してもよい。
【0190】
上記実施形態では、管理サーバ10の内部にアカウント管理データベースが構成される場合について説明したが、当該データベースは外部のデータベースサーバ等に構築されてもよい。即ち、管理サーバ10の一部の機能は別のサーバに実装されていてもよい。より具体的には、上記説明した「サービス選択制御部(サービス選択制御手段)」等がシステムに含まれるいずれかの装置に実装されていればよい。
【0191】
管理サーバ10は、アカウント生成の際、利用者の身元を確認してもよい。具体的には、管理サーバ10は、利用者のログイン情報等と共に、生体情報が記載された身元確認書類(例えば、パスポート、免許証等)及び生体情報を取得する。管理サーバ10は、身元確認書類の生体情報と利用者から取得した生体情報を用いた1対1照合を実行する。管理サーバ10は、当該照合に成功した場合に、当該本人確認に成功した利用者の利用者登録(システム登録)を行ってもよい。
【0192】
各装置(管理サーバ10、サービスサーバ20、認証端末30)間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、生体情報等が送受信され、これらの情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。
【0193】
上記説明で用いた流れ図(フローチャート、シーケンス図)では、複数の工程(処理)が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。
【0194】
上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。
【0195】
上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、生体認証サービスを提供する情報処理システムなどに好適に適用可能である。
【0196】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
[付記1]
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される、複数の第1のサーバと、
前記複数のサービス提供者それぞれの生体認証に関する管理を行う、第2のサーバと、
生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、端末と、
を含み、
前記端末は、前記第2のサーバからの要求に応じて前記原本生体情報を前記第2のサーバに送信し、
前記第2のサーバは、前記複数のサービス提供者のなかから利用者が選択したサービス提供者の前記第1のサーバに、前記原本生体情報を送信し、
前記第1のサーバは、前記原本生体情報から登録用の認証情報を生成する、システム。
[付記2]
前記第2のサーバは、前記複数のサービス提供者それぞれの情報を保持すると共に、前記利用者による前記サービス提供者の選択を可能とする、付記1に記載のシステム。
[付記3]
前記第2のサーバは、前記利用者が前記サービス提供者を選択した後に、前記端末に対して前記原本生体情報の提供を要求する、付記2に記載のシステム。
[付記4]
前記端末は、前記サービス提供者に前記原本生体情報が提供されることに対する前記利用者の同意が得られた場合に、前記原本生体情報を前記第2のサーバに送信する、付記3に記載のシステム。
[付記5]
前記複数のサービス提供者それぞれのサービス提供場所に設置された、複数の認証端末をさらに含み、
前記複数の認証端末のうち被認証者が訪れたサービス提供場所に設置された認証端末は、前記被認証者の生体情報を含む認証要求を、前記被認証者が訪れたサービス提供場所に対応する前記第1のサーバに送信する、付記4に記載のシステム。
[付記6]
前記認証要求を受信した第1のサーバは、前記認証要求に含まれる生体情報から照合用の認証情報を生成し、前記生成された照合用の認証情報と前記登録用の認証情報を用いた認証処理を行う、付記5に記載のシステム。
[付記7]
前記複数の第1のサーバのそれぞれは、各サービス提供者が前記生体認証を用いたサービスを提供する際に必要な業務情報と、前記登録用の認証情報と、を対応付けて記憶する、付記6に記載のシステム。
[付記8]
前記認証要求を受信した第1のサーバは、前記登録用の認証情報と前記照合用の認証情報を用いた照合処理により特定された被認証者の前記業務情報が有効な場合に、認証成功と判定する、付記7に記載のシステム。
[付記9]
前記生体情報は、人の顔画像である、付記1乃至8のいずれか一項に記載のシステム。
[付記10]
前記端末は、前記利用者の指示がなければ前記記憶された原本生体情報を削除しない、付記9に記載のシステム。
[付記11]
前記複数の第1のサーバ及び前記第2のサーバは、前記利用者の指示がなければ前記受信した原本生体情報を削除する、付記10に記載のシステム。
[付記12]
生体認証に用いられる認証情報の原本となる原本生体情報を記憶する、記憶部と、
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバからの要求に応じて、前記原本生体情報を前記管理サーバに送信する、送信部と、
を備える、端末。
[付記13]
端末において、
生体認証に用いられる認証情報の原本となる原本生体情報を記憶し、
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバからの要求に応じて、前記原本生体情報を前記管理サーバに送信する、端末の制御方法。
[付記14]
端末に搭載されたコンピュータに、
生体認証に用いられる認証情報の原本となる原本生体情報を記憶する処理と、
生体認証を用いたサービスを提供する、複数のサービス提供者それぞれの生体認証に関する管理を行う、管理サーバからの要求に応じて、前記原本生体情報を前記管理サーバに送信する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。
【0197】
なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。
【符号の説明】
【0198】
10 管理サーバ
20 サービスサーバ
30 認証端末
40 端末
101 第1のサーバ
102 第2のサーバ
103 端末
201 通信制御部
202 アカウント管理部
203 事業者管理部
204 サービス選択制御部
205 記憶部
206 品質検証部
301 通信制御部
302 業務情報管理部
303 利用者登録制御部
304 認証部
305 記憶部
311 プロセッサ
312 メモリ
313 入出力インターフェイス
314 通信インターフェイス
401 通信制御部
402 生体情報取得部
403 認証要求部
404 機能実現部
405 記憶部
501 通信制御部
502 アカウント生成制御部
503 原本情報取得部
504 サービス選択部
505 記憶部
【要約】
複数の生体認証サービスを利用する利用者の負担を軽減するシステムを提供する。システムは、複数の第1のサーバと、第2のサーバと、端末と、を含む。複数の第1のサーバは、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより運営される。第2のサーバは、前記複数のサービス提供者それぞれの生体認証に関する管理を行う。端末は、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する。端末は、第2のサーバからの要求に応じて原本生体情報を第2のサーバに送信する。第2のサーバは、複数のサービス提供者のなかから利用者が選択したサービス提供者の第1のサーバに、原本生体情報を送信する。第1のサーバは、原本生体情報から登録用の認証情報を生成する。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23