JP7711820B2 - プログラム、サービスサーバ、端末の制御方法及びサービスサーバの制御方法 - Google Patents

Description

本発明は、端末、システム、端末の制御方法及び記憶媒体に関する。

生体認証に関する技術が存在する。

例えば、特許文献１には、複数の認証端末を含む認証システムにおける利便性を向上させるサーバ装置を提供する、と記載されている。特許文献１のサーバ装置は、取得部と、認証部と、を備える。取得部は、認証成功と判定するための条件を含む認証ルールを取得する。認証部は、第１の端末から送信された第１の認証要求に応じて第１の生体認証を行い、第２の端末から送信された第２の認証要求に応じて、認証ルールを用いる第２の生体認証を行う。

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

国際公開第２０２２／１７６０４２号 特開２００６－１４６４５６号公報

近年、生体認証を用いた様々なサービスの提供が始まっている。ここで、個人情報保護、プライバシー保護の観点から生体認証に用いる認証情報や認証結果等を利用者自身が管理したいという要望がある。具体的には、利用者が、複数のサービス提供者のなかから生体認証を受けるサービス提供者を選択し、当該選択したサービス提供者における認証履歴等を管理、確認したいという要望がある。

なお、当該要望は、特許文献１や特許文献２に開示された技術を適用しても実現されない。特許文献１や特許文献２は、利用者が複数のサービス提供者のなかからサービス提供者を選択するような認証システムを開示していない。

本発明は、利用者が選択したサービス提供者における認証履歴の管理等を実現することに寄与する、端末、システム、端末の制御方法及び記憶媒体を提供することを主たる目的とする。

本発明の第１の視点によれば、複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信する、受信手段と、前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う、認証履歴制御手段と、を備える、端末が提供される。

本発明の第２の視点によれば、複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバと、前記利用者が所持する端末と、を含み、前記端末は、前記サービスサーバから、認証成功通知を受信する、受信手段と、前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う、認証履歴制御手段と、を備える、システムが提供される。

本発明の第３の視点によれば、端末において、複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信し、前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う、端末の制御方法が提供される。

本発明の第４の視点によれば、端末に搭載されたコンピュータに、複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信する処理と、前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

本発明の各視点によれば、利用者が選択したサービス提供者における認証履歴の管理等を実現することに寄与する、端末、システム、端末の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

図１は、一実施形態の概要を説明するための図である。 図２は、一実施形態の動作の一例を示すフローチャートである。 図３は、第１の実施形態に係る認証システムの概略構成の一例を示す図である。 図４は、第１の実施形態に係る認証システムの動作を説明するための図である。 図５は、第１の実施形態に係る認証システムの動作を説明するための図である。 図６は、第１の実施形態に係る認証システムの動作を説明するための図である。 図７は、第１の実施形態に係る認証システムの動作を説明するための図である。 図８は、第１の実施形態に係る制御サーバの処理構成の一例を示す図である。 図９は、第１の実施形態に係るアカウント管理データベースの一例を示す図である。 図１０は、第１の実施形態に係る端末の表示の一例を示す図である。 図１１は、第１の実施形態に係るサービスサーバの処理構成の一例を示す図である。 図１２は、第１の実施形態に係る利用者管理データベースの一例を示す図である。 図１３は、第１の実施形態に係る認証部の動作の一例を示すフローチャートである。 図１４は、第１の実施形態に係る認証端末の処理構成の一例を示す図である。 図１５は、第１の実施形態に係る端末の処理構成の一例を示す図である。 図１６は、第１の実施形態に係る端末の表示の一例を示す図である。 図１７は、第１の実施形態に係る認証履歴管理データベースの一例を示す図である。 図１８は、第１の実施形態に係る端末の表示の一例を示す図である。 図１９は、第１の実施形態に係る端末の表示の一例を示す図である。 図２０は、第１の実施形態に係る端末の表示の一例を示す図である。 図２１は、第１の実施形態に係る認証システムの動作の一例を示すシーケンス図である。 図２２は、本願開示に係る制御サーバのハードウェア構成の一例を示す図である。 図２３は、本願開示の変形例に係る端末の表示の一例を示す図である。 図２４は、本願開示の変形例に係る端末の表示の一例を示す図である。

はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

一実施形態に係る端末１００は、受信手段１０１と、認証履歴制御手段１０２と、を備える（図１参照）。受信手段１０１は、複数のサービス提供者のなかから利用者が選択したサービス提供者であって、当該利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信する（図２のステップＳ１）。認証履歴制御手段１０２は、認証成功通知の受信に応じて、サービス提供者において成功した生体認証の履歴に関する制御を行う（ステップＳ２）。

利用者は、複数のサービス提供者のなかからサービスの提供を受けたいサービス提供者を選択する。当該選択に応じて、生体認証に使われる認証情報の原本が上記選択されたサービス提供者に提供される。サービス提供者のサービスサーバは、認証情報を使って利用者の認証に成功すると、当該認証成功の事実及び詳細を通知する認証成功通知を端末１００に送信する。端末１００は、当該認証成功通知の受信に応じて、生体認証の履歴に関する制御を行う。例えば、端末１００は、利用者による認証履歴の閲覧を可能にする。このように、端末１００は、利用者が複数のサービス提供者のなかから選択したサービス提供者における認証履歴の管理等を実現する。認証履歴等を確認することで、利用者は、身に覚えのない不正な生体認証の実施等を発見できる。

以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

［システムの構成］
図３は、第１の実施形態に係る認証システム（情報処理システム）の概略構成の一例を示す図である。図３に示すように、認証システムには、複数のサービス提供者Ａ～Ｃ、認証センターが含まれる。

サービス提供者は、生体認証を用いて利用者にサービスを提供する事業者である。本願開示に係る認証システムは、様々な業種、業界に属するサービス提供者が生体認証を用いてサービスを提供することを前提とする。なお、サービス提供者により提供されるサービスは、有償無償を問わない。

例えば、マンション等の賃貸住宅サービスを提供する事業者、従業員の勤務先である事業者（利用者の勤務先）、コンサート等のイベントを提供する事業者、航空機等の交通手段を運営する事業者等がサービス提供者として例示される。あるいは、宿泊サービスを提供する事業者、小売店等の事業者、金融サービスを提供する事業者、教育事業者等も本願開示のサービス提供者に含まれる。また、サービス提供者は、民間事業者に限らない。自治体等の公的機関がサービス提供者であってもよい。

認証センターは、複数のサービス提供者それぞれの生体認証に関する制御、管理等を行う。利用者（一般消費者）に対して生体認証を用いたサービスを提供する事業者（サービス提供者）は、認証センターと契約を締結する必要がある。

認証センターは、制御サーバ１０を備える。制御サーバ１０は、認証センターの主たる機能を実現する。制御サーバ１０は、認証センターの建物内に設置されていてもよいし、ネットワーク（クラウド）上に設置されたサーバであってもよい。

上述のように、サービス提供者は、生体認証を用いたサービスを利用者に提供する。例えば、利用者がオフィスに出勤する際やマンションに帰宅する際に生体認証が行われ、正当な資格を有する利用者（社員、住民）がオフィス等に入ることができる。あるいは、イベント会場等におけるチケット確認、ホテルにおけるチェックイン手続き、空港における出入国手続き等において生体認証が行われる。このようなサービス（手続き）においても正当な資格を有する利用者にサービスが提供される。あるいは、小売店等での決済手続きが生体認証を用いて行われる。

図３に示すように、各サービス提供者は、サービスサーバ２０と、少なくとも１以上の認証端末３０と、を備える。サービス提供者が備える装置（サービスサーバ２０、認証端末３０）は相互に通信可能に接続される。具体的には、サービスサーバ２０と認証端末３０は、有線又は無線の通信手段により接続される。

サービスサーバ２０は、ネットワークを介して制御サーバ１０と接続されている。サービスサーバ２０は、サービス提供者の建物に設置されていてもよいし、クラウド上に設置されていてもよい。

サービスサーバ２０は、利用者にサービスを提供する際に必要な情報を記憶する。具体的には、サービスサーバ２０は、各サービス提供者が生体認証を用いたサービスを提供する際に必要な業務情報と、生体認証に必要な情報と、を記憶する。サービスサーバ２０は、利用者管理データベースを用いて、業務情報と生体認証に必要な情報を記憶する。利用者管理データベースの詳細は後述する。

例えば、利用者が勤務する企業のサービスサーバ２０は、利用者（従業員）の氏名、生年月日、社員番号、所属部署、勤務地等の情報を業務情報として記憶する。また、イベントを主催するイベント会社のサービスサーバ２０は、イベント参加者が購入したチケットに関する情報を業務情報として記憶する。さらに、小売店等のサービスサーバ２０は、代金決済に必要なクレジットカード情報（決済情報）等を業務情報として記憶する。

サービスサーバ２０が記憶する生体認証に必要な情報の詳細は後述する。

認証端末３０は、サービスの提供を受ける利用者のインターフェイスとなる装置である。認証端末３０は、各サービス提供者それぞれのサービス提供場所に設置される。より具体的には、認証端末３０は、利用者が実際に訪れる店舗等に設置される。

認証端末３０は、サービス提供者の業種等に応じた機能、形態を備える。例えば、職場やイベント会場に設置された認証端末３０は、利用者（被認証者）の通行を制限するゲートを備えたゲート装置とすることができる。また、小売店に設置された認証端末３０には、タブレット型の端末を用いることができる。

なお、図３は例示であって、本願開示の認証システムの構成等を限定する趣旨ではない。例えば、認証センターには２台以上の制御サーバ１０が含まれていてもよい。また、認証システムには、少なくとも１以上のサービス提供者が参加していればよい。さらに、各サービス提供者は、少なくとも１台以上のサービスサーバ２０と、少なくとも１台以上の認証端末３０と、を備えていればよい。

［概略動作］
続いて、第１の実施形態に係る認証システムの概略動作について説明する。

＜アカウント生成＞
サービス提供者からサービスの提供を希望する利用者は、システムにアカウントを生成する必要がある。具体的には、利用者は、所持する端末４０を操作して、制御サーバ１０にアクセスする（図４参照）。

利用者は、制御サーバ１０が提供するＷＥＢ（ウェブ）ページ等において、ログイン情報（例えば、ログインＩＤ、パスワード）、氏名、生年月日、連絡先等を入力する。制御サーバ１０は、ログイン情報等を取得すると、当該利用者を識別するためのＩＤを生成する。なお、以降の説明において、制御サーバ１０が生成したＩＤを「システムＩＤ」と表記する。制御サーバ１０は、生成したシステムＩＤ、ログイン情報等を対応付けてアカウント管理データベースに記憶する。アカウント管理データベースの詳細は後述する。

＜生体情報登録＞
生体認証を用いてサービスの提供を受けることを希望する利用者は、自身の生体情報を端末４０に登録する必要がある。

ここで、生体認証を用いたサービスの提供には、生体情報から生成された認証情報が事前にサービス提供者に登録されている必要がある。例えば、顔認証を用いてサービスが提供される際には、顔画像から生成された特徴量（特徴ベクトル）が認証情報として事前に登録されている必要がある。あるいは、指紋認証を用いてサービスが提供される際には、指紋画像から生成された特徴量が認証情報として事前に登録されている必要がある。

以降の説明において、顔画像や指紋画像のように、認証情報を生成する際の原本（基礎）となる情報を「原本生体情報」と表記する。また、原本生体情報から生成され、事前に登録される特徴量を「登録認証情報」と表記する。

システムアカウント生成を完了した利用者は、原本生体情報（例えば、顔画像）を所持する端末４０に登録する必要がある。端末４０は、ＧＵＩ（Graphical User Interface）等を用いて原本生体情報を取得する。端末４０は、取得した原本生体情報（例えば、顔画像）を内部に記憶する。このように、端末４０は、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する。

＜サービスの選択＞
システム登録（システムアカウント作成）及び原本生体情報の登録を行った利用者は、生体認証サービスの提供を受けたいサービス提供者を選択する。利用者は、認証システムに参加している複数のサービス提供者（認証センターと契約しているサービス提供者）のなかからサービスの提供を受けたいサービス提供者を選択する。

制御サーバ１０は、認証システムに参加しているサービス提供者の情報を記憶する。例えば、制御サーバ１０は、サービス提供者の名称、業種、所在地等を記憶する。制御サーバ１０は、複数のサービス提供者それぞれの情報を保持すると共に、利用者によるサービス提供者の選択を可能とする。

利用者が端末４０を操作してポータルサイト上にて所定の動作を行うと、制御サーバ１０は、利用者が希望するサービス（サービス提供者）の選択を可能とするＧＵＩ等を端末４０に表示する。制御サーバ１０は、ＧＵＩを用いて利用者が希望するサービス（生体認証サービス）を取得する。

＜利用者登録＞
利用者が選択したサービス提供者を取得すると、制御サーバ１０は、当該選択されたサービス提供者が、生体認証を用いたサービスを利用者に提供可能とする「利用者登録」に関する制御を実行する。

具体的には、制御サーバ１０は、利用者の端末４０に格納された原本生体情報を上記選択されたサービス提供者が取得するための制御を行う。サービス提供者は、取得した原本生体情報から登録認証情報を生成し、当該生成した登録認証情報と業務情報を対応付けることで利用者にサービスを提供する準備が整う。

利用者は、端末４０を操作して制御サーバ１０にアクセスし、当該利用者のポータルサイトにログインする。利用者がポータルサイト上で所定の操作（例えば、サービス提供者の選択ボタンの押下）を行うと、制御サーバ１０は、サービス提供者の一覧を含むＧＵＩを端末４０に表示する。

サービス提供者が選択されると、制御サーバ１０は、利用者に対して原本生体情報の提供を要求する。具体的には、制御サーバ１０は、「原本提供要求」を利用者の端末４０に送信する（図５のステップＳ０１参照）。

原本提供要求を受信すると、端末４０は、利用者の原本生体情報（例えば、顔画像）を制御サーバ１０に送信する（ステップＳ０２）。

制御サーバ１０は、利用者のシステムＩＤ、取得した原本生体情報、個人特定情報等を利用者が選択したサービス提供者に通知する。なお、個人特定情報は、利用者を特定するための情報である。個人特定情報として、利用者の氏名、又は、氏名と生年月日の組み合わせが例示される。

制御サーバ１０は、システムＩＤ、原本生体情報及び個人特定情報等を含む「利用者登録要求」を利用者が選択したサービス提供者のサービスサーバ２０に送信する（ステップＳ０３）。

利用者登録要求を受信したサービスサーバ２０は、取得した個人特定情報を用いて利用者管理データベースを検索し、利用者登録（生体認証を用いたサービスの提供）を希望する利用者を特定する。サービスサーバ２０は、特定された利用者のエントリにシステムＩＤ、原本生体情報から得られる登録認証情報（例えば、特徴量）を記憶する。

サービスサーバ２０は、利用者登録の結果（利用者登録に成功、失敗）を含む応答を制御サーバ１０に送信する（ステップＳ０４）。

なお、制御サーバ１０は、利用者登録要求をサービスサーバ２０に送信したタイミング、又は当該要求に対する応答を受信したタイミングにおいて、利用者から取得した原本生体情報（例えば、顔画像）を削除する。また、サービスサーバ２０は、登録認証情報（例えば、特徴量）を生成すると、制御サーバ１０から取得した原本生体情報を削除する。

＜サービスの提供＞
サービスの選択を完了した利用者は、サービスの提供を受けるためサービス提供者を訪れる。例えば、利用者は、オフィス、遊園地、イベント会場、小売店等自身で選択したサービスの提供を受けるサービス提供者の施設、店舗等を訪れる。

認証端末３０は、サービスの提供を受ける利用者（被認証者）の生体情報を取得する。例えば、認証端末３０は、被認証者を撮影し、原本生体情報に対応する生体情報（例えば、顔画像）を取得する。認証端末３０は、取得した顔画像を含む認証要求をサービスサーバ２０に送信する（図６参照）。なお、認証端末３０は、必要に応じて、生体情報と共に他の情報（例えば、購入商品名、購入商品の代金等）をサービスサーバ２０に送信する。あるいは、認証端末３０は、生体情報（個人を特定するための情報、ＩＤ）と共に認証処理に使用される情報（例えば、クレジットカード情報）をサービスサーバ２０に送信してもよい。

サービスサーバ２０は、取得した顔画像から照合用の認証情報を生成する。例えば、サービスサーバ２０は、照合用の顔画像から特徴量を生成する。サービスサーバ２０は、当該生成された照合用の認証情報（以下、照合認証情報と表記する）と、利用者管理データベースに登録された登録認証情報と、を用いた照合処理（１対Ｎ照合；Ｎは正の整数、以下同じ）を実行する。

サービスサーバ２０は、照合処理により利用者管理データベースに登録された利用者（被認証者）を特定する。

サービスサーバ２０は、特定された利用者の業務情報を用いて当該利用者の認証を行う。例えば、社員の勤務先企業のサービスサーバ２０は、被認証者が自社の社員であってオフィスに入場する資格を備えていれば「認証成功」と判定する。あるいは、イベント会場に設置されたサービスサーバ２０は、被認証者が購入したチケットが有効であれば「認証成功」と判定する。あるいは、小売店に設置されたサービスサーバ２０は、被認証者が購入した商品等の代金決済に成功すると「認証成功」と判定する。

なお、サービス提供者には、２種類のサービス事業者が存在する。

第１のサービス提供者は、原則として、被認証者の認証に成功しても登録認証情報（特徴量）等を保持し続けるサービス提供者である。例えば、利用者の勤務先企業やマンション管理会社等が第１のサービス提供者として例示される。これらのサービス提供者は、利用者の認証（オフィス、マンション等への入退場）に成功しても利用者管理データベースに記憶された登録認証情報等を削除しない。あるいは、事前登録されたクレジットカード情報等を用いて商品代金の顔決済に関するサービスを提供する小売店も第１のサービス提供者として例示される。当該小売店は、クレジットカード情報と登録認証情報を対応付けて記憶し続ける。

第２のサービス提供者は、原則として、被認証者の認証に成功すると登録認証情報（特徴量）等を削除するサービス提供者である。例えば、イベントを開催するイベント会社等が第２のサービス提供者として例示される。当該イベント会社は、利用者の認証に成功すると（購入チケットを用いて利用者がイベント会場に入場すると）、利用者管理データベースに記憶された登録認証情報を削除する。

なお、同じサービス提供者であっても、利用者に提供するサービスの内容によっては登録認証情報を記憶し続けたり、登録認証情報を削除したりする。例えば、遊園地等を運営する事業者は、１日の使用に限定されるチケットを販売する。この場合、当該事業者は、第２のサービス提供者となる。上記事業者が、所定期間に亘り遊園地等に入場できるチケット（例えば、年間チケット）も販売する場合、第１のサービス提供者となる。この場合、事業者は、年間チケットの期限が到来するまで登録認証情報を保持し続ける。

サービスサーバ２０は、認証結果（認証成功、認証失敗）を認証端末３０に送信する。

認証端末３０は、認証結果に応じた処理を実行する。例えば、認証成功を受信すると、オフィスに設置された認証端末３０は、ゲートを開き被認証者の通行を許可する。あるいは、イベント会場に設置された認証端末３０は、認証成功を受信すると、被認証者のゲート通過を許可する。あるいは、小売店に設置された認証端末３０は、認証成功を受信すると、商品の決済が終了した旨を被認証者に通知する。

＜認証成功の通知＞
また、サービスサーバ２０は、被認証者の認証に成功すると、その旨を利用者に通知する。サービスサーバ２０は、認証結果の詳細を、制御サーバ１０を介して利用者が所持する端末４０に通知する。具体的には、被認証者の認証に成功すると、サービスサーバ２０は、認証成功者（認証成功と判定された被認証者）のシステムＩＤ、認証処理の詳細情報及び認証情報の状態を含む認証成功通知を制御サーバ１０に送信する（図７参照）。

認証処理の詳細情報には、例えば、認証日時、認証場所、提供サービスの詳細（例えば、購入商品名、支払金額等）が含まれる。

例えば、被認証者の勤務先のサービスサーバ２０は、認証成功者の出勤日時、オフィス名を提供サービスの詳細として生成する。あるいは、例えば、小売店のサービスサーバ２０は、認証成功者の来店日時、店舗、購入商品、支払金額等を提供サービスの詳細として生成する。

認証情報の状態には、認証処理後における認証成功者の登録認証情報（特徴量）の状態（保持、削除）が設定される。

例えば、被認証者の勤務先のような第１のサービス提供者のサービスサーバ２０は、認証情報の状態に「認証情報保持」を設定する。あるいは、イベント会社のような第２のサービス提供者のサービスサーバ２０は、認証情報の状態に「認証情報削除」を設定する。

制御サーバ１０は、認証成功通知を受信する。制御サーバ１０は、認証成功通知に含まれるシステムＩＤをキーとしてアカウント管理データベースを検索し、対応するエントリ（利用者）を特定する。制御サーバ１０は、特定した利用者の端末４０にサービスサーバ２０から受信した認証成功通知を送信（転送）する。

端末４０は、受信した認証成功通知に基づいて認証履歴を生成する。また、端末４０は、認証成功通知を受信するたびに、当該通知の受信事実を利用者に通知する。例えば、端末４０は、ポップアップ等の手段により認証成功通知に含まれる内容（認証処理の詳細、認証情報の状態）を表示する。

あるいは、端末４０は、所定のボタン（履歴確認ボタン）が押下されると、認証履歴を表示する。利用者は、認証履歴を確認することで、不正利用の有無等を確認できる。

このように利用者が事前に選択したサービス提供者が当該利用者の認証に成功すると、当該認証成功の事実が利用者に通知される。なお、サービスサーバ２０は、上記説明したように、制御サーバ１０を介して認証成功通知を端末４０に送信してもよいし、制御サーバ１０を介さずに直接、認証成功通知を端末４０に送信してもよい。この場合、サービスサーバ２０は、業務情報を取得する際、利用者の連絡先（端末４０が受信可能なメールアドレス等）を取得すればよい。

続いて、第１の実施形態に係る認証システムに含まれる各装置の詳細について説明する。

［制御サーバ］
図８は、第１の実施形態に係る制御サーバ１０の処理構成（処理モジュール）の一例を示す図である。図８を参照すると、制御サーバ１０は、通信制御部２０１と、アカウント管理部２０２と、事業者管理部２０３と、サービス選択制御部２０４と、利用者登録制御部２０５と、記憶部２０６と、を備える。

通信制御部２０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部２０１は、サービスサーバ２０からデータ（パケット）を受信する。また、通信制御部２０１は、サービスサーバ２０に向けてデータを送信する。通信制御部２０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部２０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部２０１を介して他の装置とデータの送受信を行う。通信制御部２０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

アカウント管理部２０２は、利用者のアカウントを管理する手段である。アカウント管理部２０２は、利用者が端末４０を操作して、所定のホームページ等にアクセスすると、当該利用者のアカウントを生成するために必要な情報を取得する。

具体的には、アカウント管理部２０２は、ログイン情報、氏名、生年月日、連絡先（例えば、端末４０が受信可能なメールアドレス）等の個人情報を取得する。ログイン情報等を取得すると、アカウント管理部２０２は、当該利用者を識別するためのシステムＩＤを生成する。システムＩＤは、利用者を一意に識別できる情報であればどのような情報であってもよい。例えば、アカウント管理部２０２は、アカウント生成のたびに一意な値を採番しシステムＩＤとしてもよい。

アカウント管理部２０２は、生成されたシステムＩＤ、ログイン情報、氏名等を対応付けてアカウント管理データベースに記憶する（図９参照）。なお、図９に示すアカウント管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、アカウント生成日時等がアカウント管理データベースに記憶されていてもよい。

また、アカウント管理部２０２は、利用者の端末４０からポータルサイトにログインするためのログイン情報を取得する。アカウント管理部２０２は、ログイン情報を使った認証を行う。

事業者管理部２０３は、認証システムに参加するサービス提供者（サービス事業者）を管理する手段である。事業者管理部２０３は、各サービス提供者の職員等からシステム登録する事業者情報（サービス提供者の名称、業種、所在地、サービスサーバ２０のアドレス等）を取得する。

例えば、事業者管理部２０３は、事業者情報等を入力するためのインターフェイスを各サービス提供者に提供してもよい。あるいは、各サービス提供者は、事業者情報等が格納されたＵＳＢ（Universal Serial Bus）メモリ等を認証センターに送付してもよい。事業者管理部２０３は、認証センターの職員等から事業者情報等を取得してもよい。

事業者管理部２０３は、事業者情報等を取得したサービス提供者についてのＩＤ（事業者ＩＤ）を生成する。事業者管理部２０３は、当該生成された事業者ＩＤ、取得した事業者情報等を対応付けて記憶する。

サービス選択制御部２０４は、利用者による生体認証サービス（サービス提供者）の選択を制御する手段である。サービス選択制御部２０４は、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする。

利用者が端末４０を操作してポータルサイトにログインし、当該ポータルサイト上で所定の動作を行うと、サービス選択制御部２０４は、例えば、図１０に示すようなＧＵＩを端末４０に表示する。

上記ＧＵＩを表示する際、サービス選択制御部２０４は、利用者が選択済のサービス提供者と未選択なサービス提供者を区別可能な表示を行う。図１０の例では、サービス事業者を示すアイコンの右上にチェックが入ったサービス提供者は既に選択されたサービス提供者を示し、チェックが入っていないサービス提供者は未選択なサービス提供者を示す。

なお、サービス選択制御部２０４は、図１０に示すようなＧＵＩを表示するために事業者情報及びアカウント管理データベースに登録された情報を用いる。具体的には、サービス選択制御部２０４は、事業者情報を参照し、認証センターと契約を締結しているサービス提供者の一覧を生成する。また、サービス選択制御部２０４は、アカウント管理データベースの選択サービスフィールドを参照し、利用者が選択済のサービス提供者（サービス提供者の事業者ＩＤ）を取得する。

また、サービス選択制御部２０４は、サービス提供者の一覧を表示する際、各サービス提供者のより詳細な情報（例えば、業種、提供するサービス、店舗の場所等）も併せて利用者に提供してもよい。

サービス選択制御部２０４は、利用者が選択したサービス提供者の情報（例えば、利用者登録が希望されたサービス提供者の事業者ＩＤ）を利用者登録制御部２０５に引き渡す。

利用者登録制御部２０５は、制御サーバ１０による「利用者登録」を制御する手段である。利用者登録制御部２０５は、利用者により選択されたサービス提供者が生体認証を用いたサービスを当該利用者に提供可能とする「利用者登録」を制御する。

利用者がサービス提供者を選択すると、利用者登録制御部２０５は、利用者が所持する端末４０に「原本提供要求」を送信する。利用者登録制御部２０５は、端末４０から利用者の原本生体情報（例えば、顔画像）を受信する。

利用者登録制御部２０５は、利用者のシステムＩＤ、原本生体情報及び個人特定情報等を含む利用者登録要求を、利用者が選択したサービスに対応するサービス提供者のサービスサーバ２０に送信する。

なお、利用者登録制御部２０５は、アカウント管理データベースからシステムＩＤ及び個人特定情報（例えば、氏名又は氏名と生年月日の組み合わせ）を取得する。

利用者登録制御部２０５は、利用者登録要求に対する応答（肯定応答、否定応答）を受信する。

肯定応答（利用者登録に成功）を受信した場合、利用者登録制御部２０５は、利用者が選択したサービス提供者の事業者ＩＤをアカウント管理データベースに登録する。また、肯定応答を受信した場合、利用者登録制御部２０５は、選択されたサービス提供者に関する利用者登録に成功した旨を利用者に通知する。

否定応答（利用者登録に失敗）を受信した場合、利用者登録制御部２０５は、その旨を利用者に通知する。

記憶部２０６は、制御サーバ１０の動作に必要な情報を記憶する手段である。

［サービスサーバ］
図１１は、第１の実施形態に係るサービスサーバ２０の処理構成（処理モジュール）の一例を示す図である。図１１を参照すると、サービスサーバ２０は、通信制御部３０１と、業務情報管理部３０２と、利用者登録制御部３０３と、認証部３０４と、記憶部３０５と、を備える。

通信制御部３０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部３０１は、制御サーバ１０からデータ（パケット）を受信する。また、通信制御部３０１は、制御サーバ１０に向けてデータを送信する。通信制御部３０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部３０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部３０１を介して他の装置とデータの送受信を行う。通信制御部３０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

業務情報管理部３０２は、サービス提供者が業務の提供に必要な業務情報に関する管理、制御を行う手段である。

業務情報管理部３０２は、任意の手段を用いて自社、自組織のサービス提供に必要な業務情報を取得する。例えば、利用者の勤務先企業の業務情報管理部３０２は、従業員の氏名、生年月日、社員番号、所属部署、勤務地等の情報を業務情報として取得する。

業務情報管理部３０２は、サービス提供者の職員等から上記業務情報を取得してもよいし、ホームページ等の手段を用いて利用者から直接、業務情報を取得してもよい。

業務情報管理部３０２は、利用者管理データベースを用いて業務情報を管理する。

なお、業務情報管理部３０２のより詳細な説明は省略する。個別のサービスにおける業務情報の詳細やその取得方法は、本願開示の趣旨とは異なるためである。

利用者登録制御部３０３は、サービス提供者による利用者登録を制御する手段である。利用者登録制御部３０３は、制御サーバ１０から受信した利用者登録要求を処理する。

利用者登録要求を受信すると、利用者登録制御部３０３は、当該利用者登録要求に含まれる個人特定情報（例えば、氏名）をキーとして利用者管理データベースを検索し、対応する利用者（エントリ）を特定する。

対応する利用者が利用者管理データベースに登録されていると、利用者登録制御部３０３は、取得した原本生体情報（例えば、顔画像）から登録認証情報を生成する。例えば、顔画像を取得した場合、利用者登録制御部３０３は、自社で採用する顔認証アルゴリズムに対応した特徴量（特徴ベクトル）を登録認証情報として生成する。

特徴量の生成処理に関しては既存の技術を用いることができるので、その詳細な説明を省略する。例えば、利用者登録制御部３０３は、顔画像から目、鼻、口等を特徴点として抽出する。その後、利用者登録制御部３０３は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算し、複数の特徴量からなる特徴ベクトル（顔画像を特徴づけるベクトル情報）を生成する。

登録認証情報（例えば、特徴量）が生成されると、利用者登録制御部３０３は、システムＩＤ、生成された登録認証情報（特徴量）及び業務情報を対応付けて利用者管理データベースに記憶する（図１２参照）。

なお、図１２に示す利用者管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、利用者登録の日時等が利用者管理データベースに登録されていてもよい。

利用者登録が正常に終了すると、利用者登録制御部３０３は、利用者登録に成功した旨を示す肯定応答を制御サーバ１０に送信する。なお、利用者登録制御部３０３は、登録認証情報（例えば、特徴量）を生成し、当該生成された登録認証情報を利用者管理データベースに登録すると、制御サーバ１０から取得した原本生体情報を削除する。

利用者登録が正常に終了しなければ、利用者登録制御部３０３は、利用者登録に失敗した旨を示す否定応答を制御サーバ１０に送信する。例えば、制御サーバ１０から受信した個人特定情報（例えば、氏名）が利用者管理データベースに登録されていない場合や原本生体情報から有効な登録認証情報が生成できない場合等に、否定応答が制御サーバ１０に送信される。

認証部３０４は、被認証者の生体認証を行う手段である。

図１３は、第１の実施形態に係る認証部３０４の動作の一例を示すフローチャートである。図１３を参照して、認証部３０４の動作を説明する。

認証端末３０から認証要求を受信すると、認証部３０４は、生体情報を用いた照合処理を実行する（ステップＳ１０１）。

具体的には、認証部３０４は、認証要求に含まれる生体情報から照合認証情報を生成する。例えば、顔画像を取得すると、認証部３０４は、自社で採用している顔認証アルゴリズムに対応した特徴量を生成する。認証部３０４は、生成した照合認証情報（特徴量）と、利用者管理データベースに登録された登録認証情報（特徴量）と、を用いた照合処理を実行する。

具体的には、認証部３０４は、照合対象の特徴量（特徴ベクトル）と登録側の複数の特徴量それぞれとの間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。

類似度が所定の値以上の特徴量が存在しなければ、認証部３０４は、照合処理に失敗したと判定する。類似度が所定の値以上の特徴量が存在すれば、認証部３０４は、照合処理に成功したと判定する。照合処理に成功すると、利用者管理データベースに登録された複数のエントリのうち最も類似度が高い特徴量（登録認証情報）を持つエントリの利用者が被認証者として特定される。

照合処理に失敗すると（ステップＳ１０２、Ｎｏ分岐）、認証部３０４は、処理を終了する。この場合、認証部３０４は、認証に失敗した旨を認証端末３０に通知してもよい。あるいは、認証部３０４は、顔認証の健全性を確認するため、照合処理に失敗した事実及び照合処理の詳細をログとして記憶してもよい。

照合処理に成功すると（ステップＳ１０２、Ｙｅｓ分岐）、認証部３０４は、照合処理により特定された被認証者の業務情報を用いて当該被認証者にサービスの提供が可能か否か判定する。認証部３０４は、業務情報によるサービス提供可否の判定を行う（ステップＳ１０３）。

例えば、社員の勤務先企業のサービスサーバ２０の認証部３０４は、被認証者が自社の社員であってオフィスに入場する資格を備えていれば、サービスの提供が可能と判定する。あるいは、イベント会社のサービスサーバ２０は、被認証者が購入したチケットが有効であれば、サービスの提供が可能と判定する。あるいは、小売店等のサービスサーバ２０の認証部３０４は、クレジットカード情報等を用いた商品代金の決済に成功した場合に、サービスの提供が可能と判定する。

なお、各サービス提供者における業務情報を用いた認証処理に関するより詳細な説明を省略する。各サービス提供者に特有な処理は本願開示の趣旨とは異なるためである。

サービスの提供が不可な場合（ステップＳ１０４、Ｎｏ分岐）、認証部３０４は、認証結果に「認証失敗」を設定する（ステップＳ１０５）。

サービスの提供が可能な場合（ステップＳ１０４、Ｙｅｓ分岐）、認証部３０４は、認証結果に「認証成功」を設定する（ステップＳ１０６）。

認証部３０４は、認証結果（認証成功、認証失敗）を認証端末３０に送信する（ステップＳ１０７）。

認証失敗の場合には、認証部３０４は、その旨を示す否定応答を認証端末３０に送信する。

認証成功の場合には、認証部３０４は、その旨を示す肯定応答を認証端末３０に送信する。その際、認証部３０４は、必要に応じて、利用者にサービスを提供するために必要な情報を含む肯定応答を認証端末３０に送信する。上記住民票発行の例では、住民票を発行（印刷）するために必要な情報が認証端末３０に送信される。

また、認証成功の場合には、認証部３０４は、必要に応じて利用者管理データベースの更新を行う（データベースの更新；ステップＳ１０８）。より具体的には、認証部３０４は、認証処理の内容に応じて、少なくとも認証成功者の登録認証情報を削除する。

例えば、認証部３０４は、被認証者の入退（オフィスへの出勤、マンションへの帰宅等）に関する認証処理の場合には特段の処理を行わない（登録認証情報を削除しない）。あるいは、クレジットカード情報を使って被認証者が購入した商品の決済を行った場合にも、認証部３０４は、特段の処理を行わない。

このように、認証成功者の登録認証情報を削除しない場合には、認証部３０４は、認証情報の状態に「認証情報保持」を設定する。

被認証者が購入チケットを利用してイベント会場等に入場した場合には、認証部３０４は、当該被認証者の登録認証情報を削除する（対応する利用者管理データベースのエントリを削除する）。この場合、認証部３０４は、認証情報の状態に「認証情報削除」を設定する。

登録認証情報を削除するか否かは、利用者に提供されるサービスに応じて予め定められている。あるいは、業務情報に含まれる情報に基づいて登録認証情報（登録認証情報を含むエントリ）の削除が決定されてもよい。例えば、利用者の購入したチケットが「年間パスポート」のような繰り返し使えるチケットの場合には、認証部３０４は、登録認証情報を削除しない。

認証成功の場合には、認証部３０４は、認証成功通知を制御サーバ１０に送信する（ステップＳ１０９）。

具体的には、認証部３０４は、被認証者（照合処理により特定された利用者）のシステムＩＤ、認証処理の詳細情報及び認証情報の状態を含む認証成功通知を制御サーバ１０に送信する。

認証部３０４は、照合処理により特定されたエントリ（利用者管理データベースのエントリ）から上記システムＩＤを取得する。

認証部３０４は、認証端末３０から受信した認証要求を処理した日時から認証日時を生成し、当該認証端末３０の設置場所から認証場所を生成する。また、認証部３０４は、業務情報を使った認証処理の内容から提供サービスの詳細を生成する。

例えば、被認証者が勤務先に出勤した場合、認証部３０４は、「認証日時＝２０２２年１１月７日、０８：３０」、「認証場所＝本社ビル」、「提供サービスの詳細＝出勤」といった内容を含む認証処理の詳細情報を生成する。あるいは、被認証者が小売店で商品を購入した場合、認証部３０４は、「認証日時＝２０２２年１１月７日、１３：００」、「認証場所＝駅前店」、「提供サービスの詳細＝栄養ドリンク購入、３００円」といった内容の認証処理の詳細情報を生成する。

なお、利用者が退職した、利用者がマンションから退去した、年間パスポートの有効期限が経過した等が発生すると、利用者管理データベースから対応する利用者のエントリが削除される。この場合、当該利用者の認証に成功することはないので、利用者管理データベースの更新や認証成功通知の送信が行われることはない。

記憶部３０５は、サービスサーバ２０の動作に必要な情報を記憶する手段である。

［認証端末］
図１４は、第１の実施形態に係る認証端末３０の処理構成（処理モジュール）の一例を示す図である。図１４を参照すると、認証端末３０は、通信制御部４０１と、提供サービス制御部４０２と、認証要求部４０３と、記憶部４０４と、を備える。

通信制御部４０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部４０１は、サービスサーバ２０からデータ（パケット）を受信する。また、通信制御部４０１は、サービスサーバ２０に向けてデータを送信する。通信制御部４０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部４０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部４０１を介して他の装置とデータの送受信を行う。通信制御部４０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

提供サービス制御部４０２は、利用者に提供するサービスに関する制御を実行する手段である。提供サービス制御部４０２は、認証端末３０に割り当てられた機能を実現する。

提供サービス制御部４０２は、利用者がサービスの享受を希望すると、当該利用者（被認証者）の生体情報（例えば、顔画像）を取得する。例えば、提供サービス制御部４０２は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。提供サービス制御部４０２は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。

なお、提供サービス制御部４０２による顔画像の検出処理や顔画像の抽出処理には既存の技術を用いることができるので詳細な説明を省略する。例えば、提供サービス制御部４０２は、ＣＮＮ（Convolutional Neural Network）により学習された学習モデルを用いて、画像データの中から顔画像（顔領域）を抽出してもよい。あるいは、提供サービス制御部４０２は、テンプレートマッチング等の手法を用いて顔画像を抽出してもよい。

提供サービス制御部４０２は、取得した生体情報（例えば、顔画像）を認証要求部４０３に引き渡す。

認証要求部４０３は、サービスサーバ２０に対して被認証者の認証を要求する手段である。認証要求部４０３は、被認証者の認証が必要になると、被認証者（認証端末３０の面前の利用者）の生体情報を含む認証要求をサービスサーバ２０に送信する。

認証要求部４０３は、サービスサーバ２０から認証結果（認証成功、認証失敗）を受信する。認証要求部４０３は、受信した認証結果を提供サービス制御部４０２に引き渡す。

例えば、利用者の勤務先に設置された認証端末３０の提供サービス制御部４０２は、認証成功を受信すると、ゲートを開き被認証者の入場を許可する。

認証失敗を受信した場合、提供サービス制御部４０２は、予め定められたメッセージ等を出力してもよい。

なお、各サービス提供者の認証端末３０に含まれる提供サービス制御部４０２に関するより詳細な説明は省略する。提供サービス制御部４０２による認証端末３０の機能実現は、本願開示の趣旨とは異なるためである。

記憶部４０４は、認証端末３０の動作に必要な情報を記憶する手段である。

［端末］
図１５は、第１の実施形態に係る端末４０の処理構成（処理モジュール）の一例を示す図である。図１５を参照すると、端末４０は、通信制御部５０１と、アカウント生成制御部５０２と、原本情報取得部５０３と、サービス選択部５０４と、認証履歴制御部５０５と、記憶部５０６と、を備える。

通信制御部５０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部５０１は、制御サーバ１０からデータ（パケット）を受信する。また、通信制御部５０１は、制御サーバ１０に向けてデータを送信する。通信制御部５０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部５０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部５０１を介して他の装置とデータの送受信を行う。通信制御部５０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

通信制御部５０１は、複数のサービス提供者それぞれの生体認証に関する管理を行う、制御サーバ１０からの要求に応じて、記憶部５０６に記憶された原本生体情報を、制御サーバ１０を介して利用者が選択したサービス提供者のサービスサーバ２０に送信する。また、通信制御部５０１は、複数のサービス提供者のなかから利用者が選択したサービス提供者であって、当該利用者の生体認証に成功したサービス提供者のサービスサーバ２０から、直接的又は間接的に認証成功通知を受信する。

アカウント生成制御部５０２は、利用者によるアカウント生成を制御する手段である。アカウント生成制御部５０２は、利用者の操作に応じて、制御サーバ１０が提供する所定のＷＥＢページ等にアクセスする。

アカウント生成制御部５０２は、利用者の操作に応じて、当該ＷＥＢページに、ログイン情報、氏名、生年月日、連絡先等を入力する。

原本情報取得部５０３は、利用者の生体情報（原本生体情報）を取得する手段である。原本情報取得部５０３は、利用者の操作に応じて、原本生体情報（例えば、顔画像）を取得するためのＧＵＩ等を表示する。例えば、原本情報取得部５０３は、図１６に示すようなＧＵＩを用いて原本生体情報を取得する。

原本情報取得部５０３は、取得した原本生体情報（例えば、顔画像）を記憶部５０６に格納する。その際、原本情報取得部５０３は、取得した原本生体情報に暗号化、コード化等を施し、当該暗号化された原本生体情報を記憶部５０６に記憶してもよい。即ち、利用者が所持する端末４０は、暗号化された原本生体情報を保持してもよい。暗号化された原本生体情報は、原本生体情報が制御サーバ１０に送信される際に復号されてもよい。あるいは、暗号化された原本生体情報を復号するための情報（例えば、共通鍵）が端末４０と制御サーバ１０の間で共有され、制御サーバ１０が暗号化された原本生体情報を復号してもよい。

なお、端末４０は、原則として、利用者の原本生体情報（例えば、顔画像）を削除しない。即ち、端末４０は、利用者からの明確な指示がなければ記憶部５０６に記憶された原本生体情報を削除しない。

サービス選択部５０４は、利用者による生体認証サービスの選択を可能とする手段である。サービス選択部５０４は、利用者の操作に応じて、制御サーバ１０が提供するポータルサイトにログインする。サービス選択部５０４は、制御サーバ１０が提供するＧＵＩを用いて利用者が選択したサービス提供者の情報を制御サーバ１０に送信する。

サービス選択部５０４は、制御サーバ１０から原本提供要求を受信する。当該要求を受信すると、サービス選択部５０４は、記憶部５０６に記憶された原本生体情報を制御サーバ１０に送信する。原本生体情報は、制御サーバ１０を介して、利用者が選択したサービス提供者のサービスサーバ２０に送信される。

認証履歴制御部５０５は、利用者の認証履歴に関する制御を実行する手段である。認証履歴制御部５０５は、制御サーバ１０から受信する認証成功通知を処理する。認証履歴制御部５０５は、認証成功通知の受信に応じて、サービス提供者において成功した生体認証の履歴に関する制御を行う。

認証成功通知には、サービス提供者が成功した認証処理の詳細情報と、サービス提供者が生体認証に用いる認証情報の状態と、が含まれる。

認証履歴制御部５０５は、認証成功通知に含まれる認証処理の詳細情報及び認証情報の状態を認証履歴管理データベースに記憶する（図１７参照）。認証履歴制御部５０５は、認証処理の詳細情報及び認証情報の状態を認証履歴管理データベースに記憶することで、利用者の生体認証に関する履歴を生成する。なお、図１７に示す認証履歴管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。

また、認証成功通知を受信すると、認証履歴制御部５０５は、利用者（端末４０の所有者）の認証が行われた事実を当該利用者に通知する。例えば、認証履歴制御部５０５は、認証成功通知を受信するたびに、図１８に示すようなポップアップ通知を用いて利用者の認証に関する情報を表示する。即ち、認証履歴制御部５０５は、認証成功通知を受信するたびに、認証処理の詳細情報及び認証情報の状態を含むメッセージを表示する。

あるいは、認証履歴制御部５０５は、利用者が所定の動作を行うと（例えば、認証履歴ボタンを押下すると）、認証履歴管理データベースに記憶された認証履歴の一覧を表示する（図１９参照）。即ち、認証履歴制御部５０５は、利用者の所定の操作に応じて、認証履歴管理データベースに記憶された生体認証に関する履歴の表示を行う。

なお、認証履歴制御部５０５は、認証履歴の一覧表示を行う際、図１９に示すように、認証処理の詳細情報を表示してもよいし、図２０に示すように認証処理の詳細情報に加えて認証情報の状態を表示してもよい。

記憶部５０６は、端末４０の動作に必要な情報を記憶する手段である。記憶部５０６は、生体認証に用いられる認証情報の原本となる原本生体情報を記憶する。なお、例えば、原本生体情報は顔画像であり、認証情報は顔画像から生成された特徴量である。

［システムの動作］
続いて、第１の実施形態に係る認証システムの動作について説明する。なお、アカウント生成等に関する動作の説明は省略する。図２１は、第１の実施形態に係る認証システムの動作の一例を示すシーケンス図である。

認証端末３０から認証要求を受信すると、サービスサーバ２０は、認証処理を実行する（ステップＳ２１）。

被認証者の認証に成功すると、サービスサーバ２０は、認証成功通知を制御サーバ１０に送信する（ステップＳ２２）。

制御サーバ１０は、認証成功通知を認証成功者の端末４０に転送する（ステップＳ２３）。

端末４０は、認証処理が行われた事実（認証に成功した事実及びその詳細）を利用者に通知する（認証の事実を通知；ステップＳ２４）。

続いて、第１の実施形態に係る変形例について説明する。

＜第１の実施形態に係る変形例１＞
利用者は、所定のコードを用いてサービス提供者を選択してもよい。例えば、数多くのサービス提供者のなかから利用者が容易にサービス選択者を指定可能とする管理コードが使用されてもよい。例えば、制御サーバ１０は、図１０に示されたアイコンの一覧において、利用者が所定のアイコンを選択すると、管理コードの入力を求めるＧＵＩを表示する。制御サーバ１０は、利用者が入力した管理コードに対応するサービス提供者を当該利用者により選択されたサービス提供者として扱う。

あるいは、制御サーバ１０は、利用者が入力する管理コードをパスワードのように扱ってもよい。具体的には、利用者がサービス提供者を選択すると、制御サーバ１０は、当該選択されたサービス提供者の管理コードの入力を利用者に求める。制御サーバ１０は、利用者が入力した管理コードと、選択されたサービス提供者の予め定められた管理コードと、が一致した場合、利用者によるサービス提供者の選択を受け入れてもよい。換言すれば、制御サーバ１０は、上記２つの管理コードが一致しない場合、利用者によるサービス提供者の選択を拒否する。

＜第１の実施形態に係る変形例２＞
上記実施形態では、利用者登録の際、サービス提供者（サービスサーバ２０）は個人特定情報を用いて利用者を特定する場合について説明した。しかし、当該利用者の選択は、サービス提供者が利用者（顧客）を管理するＩＤ（以下、個別ＩＤと表記する）を用いて行われてもよい。

具体的には、利用者がサービス提供者を選択すると、制御サーバ１０は、当該利用者のシステムＩＤが埋め込まれたリダイレクト用ＵＲＬ（Uniform Resource Locator）を端末４０に送信する。当該リダイレクト用ＵＲＬは、利用者が選択したサービス提供者のポータルサイト（アカウント）へログインするためのＵＲＬである。

受信したリダイレクト用ＵＲＬに従って、利用者がサービス提供者のログインページにログインすると、サービスサーバ２０は、当該利用者の個別ＩＤ（ログインＩＤ）とリダイレクト用ＵＲＬに埋め込まれたシステムＩＤを取得する。

サービスサーバ２０は、取得した個別ＩＤを用いて利用者管理データベースを検索し、対応するエントリ（利用者）を特定する。サービスサーバ２０は、特定したエントリにシステムＩＤを記憶する。

このように、システムＩＤが埋め込まれたリダイレクト用ＵＲＬが使用されて、利用者登録が実現されてもよい。

以上のように、第１の実施形態に係る認証システムは、利用者の端末４０に格納された原本生体情報は、当該利用者が選択したサービス提供者のサービスサーバ２０に提供される。サービスサーバ２０は、当該利用者の原本生体情報から登録認証情報を生成し、当該生成した登録認証情報と業務情報を対応付けて記憶することで、利用者に生体認証を用いたサービスの提供を可能とする。利用者がサービス提供者から生体認証サービスを受けると、サービスサーバ２０は、制御サーバ１０を介して認証成功通知を利用者の端末４０に送信する。認証成功通知の受信に応じて、端末４０は、サービス提供者にて生体認証が行われた事実をポップアップ通知したり、過去の認証結果の一覧を表示したりする。利用者は、当該ポップアップ通知や認証履歴の一覧表示により、不正な生体認証が行われていないか検証できる。換言すれば、利用者は、ポップアップ通知や認証履歴の一覧表示により不正な生体認証を発見できる。

続いて、認証システムを構成する各装置のハードウェアについて説明する。図２２は、制御サーバ１０のハードウェア構成の一例を示す図である。

制御サーバ１０は、情報処理装置（所謂、コンピュータ）により構成可能であり、図２２に例示する構成を備える。例えば、制御サーバ１０は、プロセッサ３１１、メモリ３１２、入出力インターフェイス３１３及び通信インターフェイス３１４等を備える。上記プロセッサ３１１等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。

但し、図２２に示す構成は、制御サーバ１０のハードウェア構成を限定する趣旨ではない。制御サーバ１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス３１３を備えていなくともよい。また、制御サーバ１０に含まれるプロセッサ３１１等の数も図２２の例示に限定する趣旨ではなく、例えば、複数のプロセッサ３１１が制御サーバ１０に含まれていてもよい。

プロセッサ３１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）等のプログラマブルなデバイスである。あるいは、プロセッサ３１１は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスであってもよい。プロセッサ３１１は、オペレーティングシステム（ＯＳ；Operating System）を含む各種プログラムを実行する。

メモリ３１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。メモリ３１２は、ＯＳプログラム、アプリケーションプログラム、各種データを格納する。

入出力インターフェイス３１３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。

通信インターフェイス３１４は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス３１４は、ＮＩＣ（Network Interface Card）等を備える。

制御サーバ１０の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３１２に格納されたプログラムをプロセッサ３１１が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transitory）なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。

なお、サービスサーバ２０、認証端末３０、端末４０等も制御サーバ１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は制御サーバ１０と相違する点はないので説明を省略する。例えば、認証端末３０は、被認証者を撮影するためのカメラ装置を備えていればよい。

情報処理装置である制御サーバ１０は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで制御サーバ１０の機能が実現できる。また、制御サーバ１０は、当該プログラムにより制御サーバ１０の制御方法を実行する。同様に、情報処理装置である端末４０は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで端末４０の機能が実現できる。また、端末４０は、当該プログラムにより端末４０の制御方法を実行する。

［変形例］
なお、上記実施形態にて説明した認証システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。

上記実施形態では、利用者によるサービス提供者の選択と、当該選択に伴う原本生体情報の提供（オプトイン）について説明した。制御サーバ１０や端末４０は、当該オプトインしたサービス提供者の情報を図１０に示すように、サービス提供者のアイコンにチェックを入れることで利用者が識別可能としている。制御サーバ１０及び端末４０は、オプトインしたサービス提供者から登録認証情報を削除するオプトアウトを可能としてもよい。この場合、制御サーバ１０は、図１０において、利用者が選択済のサービス提供者（オプトインされたサービス提供者）を選択すると、当該選択されたサービス提供者のサービスサーバ２０に対して、利用者のシステムＩＤを含む利用者登録解除要求を送信する。サービスサーバ２０は、システムＩＤに対応する利用者の登録認証情報等を削除する。

サービスサーバ２０（認証部３０４）は、業務情報を用いたサービス提供可否の判定に失敗した場合には、当該失敗の事実を被認証者（照合処理により特定された被認証者）に通知してもよい。その際、認証部３０４は、認証に失敗した原因も併せて被認証者に通知してもよい。例えば、認証部３０４は、「オフィスに入場する権限がない」、「クレジットカードによる決済に失敗した」、「チケットが無効」等の理由を被認証者に通知してもよい。この場合、認証部３０４は、被認証者のシステムＩＤと認証失敗の理由を含む認証失敗通知を制御サーバ１０に送信する。制御サーバ１０は、システムＩＤを用いて被認証者の端末４０を特定し、当該特定された端末４０に認証失敗通知を送信する。認証失敗通知を受信すると、端末４０は、利用者に認証に失敗した理由を通知する。例えば、端末４０は、図２３に示すようなポップアップ通知により認証に失敗した理由を利用者に通知する。あるいは、端末４０は、認証失敗通知を使って認証履歴を生成してもよい。この場合、端末４０は、利用者の操作に応じて、図２４に示すように認証失敗時の原因を表示してもよい。

上記実施形態では、人の「顔」を生体情報の例にとり認証システムの動作を説明した。しかし、本願開示の認証システムは、他の種類の生体情報を用いることもできる。例えば、指紋、声紋、静脈、網膜、瞳の虹彩の模様（パターン）といった個人に固有の身体的特徴を備えるデータが用いられてもよい。即ち、利用者の生体情報は、利用者の身体的特徴を情報として含むものであればよい。

利用者の端末４０は、制御サーバ１０から原本提供要求を受信するたびに、原本生体情報（例えば、顔画像）をサービス提供者に送信することについての同意を利用者から取得してもよい。具体的には、原本提供要求を受信すると、端末４０のサービス選択部５０４は、ＧＵＩ等を用いて原本生体情報（例えば、顔画像）の提供可否を取得する。サービス選択部５０４は、原本生体情報の提供に関する利用者の同意が得られると、内部に記憶された原本生体情報を制御サーバ１０に送信する。

上記実施形態では、制御サーバ１０の内部にアカウント管理データベースが構成される場合について説明したが、当該データベースは外部のデータベースサーバ等に構築されてもよい。即ち、制御サーバ１０の一部の機能は別のサーバに実装されていてもよい。より具体的には、上記説明した「サービス選択制御部（サービス選択制御手段）」等がシステムに含まれるいずれかの装置に実装されていればよい。

各装置（制御サーバ１０、サービスサーバ２０、認証端末３０）間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、生体情報等が送受信され、これらの情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。

上記説明で用いた流れ図（フローチャート、シーケンス図）では、複数の工程（処理）が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。

上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、生体認証サービスを提供する情報処理システムなどに好適に適用可能である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信する、受信手段と、
前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う、認証履歴制御手段と、
を備える、端末。
［付記２］
前記認証成功通知には、前記サービス提供者が成功した認証処理の詳細情報と、前記サービス提供者が生体認証に用いる認証情報の状態と、が含まれ、
前記認証履歴制御手段は、前記認証処理の詳細情報及び前記認証情報の状態を記憶することで、前記利用者の生体認証に関する履歴を生成する、付記１に記載の端末。
［付記３］
前記認証履歴制御手段は、前記認証成功通知を受信するたびに、前記認証処理の詳細情報及び前記認証情報の状態を含むメッセージを表示する、付記２に記載の端末。
［付記４］
前記認証履歴制御手段は、前記利用者の所定の操作に応じて、前記記憶された生体認証に関する履歴の表示を行う、付記３に記載の端末。
［付記５］
前記生体認証に用いられる前記認証情報の原本となる原本生体情報を記憶する、記憶手段と、
前記複数のサービス提供者それぞれの生体認証に関する管理を行う、制御サーバからの要求に応じて、前記記憶された原本生体情報を、前記制御サーバを介して前記利用者が選択したサービス提供者のサービスサーバに送信する、送信手段と、
をさらに備える、付記２乃至４のいずれか一項に記載の端末。
［付記６］
前記原本生体情報は顔画像であり、前記認証情報は前記顔画像から生成された特徴量である、付記５に記載の端末。
［付記７］
複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバと、
前記利用者が所持する端末と、
を含み、
前記端末は、
前記サービスサーバから、認証成功通知を受信する、受信手段と、
前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う、認証履歴制御手段と、
を備える、システム。
［付記８］
前記複数のサービス提供者それぞれの生体認証に関する管理を行う、制御サーバをさらに含み、
前記受信手段は、前記制御サーバを介して、前記認証成功通知を受信する、付記７に記載のシステム。
［付記９］
端末において、
複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信し、
前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う、端末の制御方法。
［付記１０］
端末に搭載されたコンピュータに、
複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、認証成功通知を受信する処理と、
前記認証成功通知の受信に応じて、前記サービス提供者において成功した生体認証の履歴に関する制御を行う処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。

なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。

１０ 制御サーバ
２０ サービスサーバ
３０ 認証端末
４０ 端末
１００ 端末
１０１ 受信手段
１０２ 認証履歴制御手段
２０１ 通信制御部
２０２ アカウント管理部
２０３ 事業者管理部
２０４ サービス選択制御部
２０５ 利用者登録制御部
２０６ 記憶部
３０１ 通信制御部
３０２ 業務情報管理部
３０３ 利用者登録制御部
３０４ 認証部
３０５ 記憶部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０１ 通信制御部
４０２ 提供サービス制御部
４０３ 認証要求部
４０４ 記憶部
５０１ 通信制御部
５０２ アカウント生成制御部
５０３ 原本情報取得部
５０４ サービス選択部
５０５ 認証履歴制御部
５０６ 記憶部

Claims (8)

1. 端末に搭載されたコンピュータに、
   複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、前記サービス提供者が生体認証に用いる認証情報の状態に関する情報を受信する、受信処理と、
   前記受信した情報に応じて、前記サービス提供者における前記認証情報の状態を前記利用者が閲覧可能に制御する、制御処理と、
   前記生体認証に用いられる前記認証情報の原本となる原本生体情報を記憶する、記憶処理と、
   前記複数のサービス提供者それぞれの生体認証に関する管理を行う、制御サーバからの要求に応じて、前記記憶された原本生体情報を、前記制御サーバを介して前記利用者が選択したサービス提供者のサービスサーバに送信する、送信処理と、
   を実行させるためのプログラム。
2. 前記制御処理は、前記認証情報の状態に関する情報を受信するたびに、前記サービス提供者が成功した認証処理の詳細情報及び前記認証情報の状態を含むメッセージを表示する、請求項１に記載のプログラム。
3. 利用者の生体認証を実行する、認証手段と、
   前記利用者の生体認証に成功すると、前記生体認証に用いられる認証情報の状態に関する情報を前記利用者が所持する端末に送信する、送信手段と、
   を備え、
   前記送信手段は、
   前記生体認証が成功するたびに、認証処理の詳細情報及び前記認証情報の状態を前記端末に送信する、サービスサーバ。
4. 前記利用者が所持する端末が、複数のサービス提供者それぞれの生体認証に関する管理を行う、制御サーバからの要求に応じて、前記端末に記憶された、前記生体認証に用いられる前記認証情報の原本となる原本生体情報を前記制御サーバに送信し、
   前記制御サーバから、前記原本生体情報を受信する、受信手段をさらに備える、請求項３に記載のサービスサーバ。
5. 前記認証情報は、前記利用者に提供されるサービスに応じて、保持又は削除が設定されている、請求項４に記載のサービスサーバ。
6. 端末において、
   複数のサービス提供者のなかから利用者が選択したサービス提供者であって、前記利用者の生体認証に成功したサービス提供者のサービスサーバから、前記サービス提供者が生体認証に用いる認証情報の状態に関する情報を受信し、
   前記受信した情報に応じて、前記サービス提供者における前記認証情報の状態を前記利用者が閲覧可能に制御し、
   前記生体認証に用いられる前記認証情報の原本となる原本生体情報を記憶し、
   前記複数のサービス提供者それぞれの生体認証に関する管理を行う、制御サーバからの要求に応じて、前記記憶された原本生体情報を、前記制御サーバを介して前記利用者が選択したサービス提供者のサービスサーバに送信する、端末の制御方法。
7. サービスサーバにおいて、
   利用者の生体認証を実行し、
   前記利用者の生体認証に成功すると、前記生体認証に用いられる認証情報の状態に関する情報を前記利用者が所持する端末に送信する、サービスサーバの制御方法であって、
   前記生体認証が成功するたびに、認証処理の詳細情報及び前記認証情報の状態を前記端末に送信する、サービスサーバの制御方法。
8. サービスサーバに搭載されたコンピュータに、
   利用者の生体認証を実行する処理と、
   前記利用者の生体認証に成功すると、前記生体認証に用いられる認証情報の状態に関する情報を前記利用者が所持する端末に送信する処理と、
   を実行させるプログラムであって、
   前記コンピュータに、
   前記生体認証が成功するたびに、認証処理の詳細情報及び前記認証情報の状態を前記端末に送信する処理を実行させるプログラム。