JP7663148B2 - サーバ装置、システム、サーバ装置の制御方法及びプログラム - Google Patents

Description

本発明は、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体に関する。

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

例えば、特許文献１には、入場受付けを自動化し、確実に本人認証を実現する、と記載されている。特許文献１の入場受付端末は、ＩＣチップを内蔵する個人識別カードを使用して、当該個人識別カードを携帯している外来者の入場を受け付ける。ＩＣチップ内には、アクセス許可番号と個人情報と個人認証情報とが予め格納されている。入場受付端末は、アクセス許可番号の入力を受け付ける入力手段と、個人識別カードから、ＩＣチップに格納されている個人情報と個人認証情報とを読み取る読取手段と、外来者の生体認証情報を取得する取得手段と、認証手段と、発行手段と、を備える。認証手段は、読み取った個人認証情報と取得した生体認証情報とを照合して、本人認証を実施する。発行手段は、本人認証が確認された場合に、入場許可証を発行する。

特開２０１８－１２４６２２号公報

近年、生体認証を用いた様々なサービスの提供が始まっている。例えば、特許文献１に示されるような施設への入場制御だけでなく、購入商品の代金決済が生体認証により可能な状況にある。ここで、利用者のなかには、生体認証による最大限のサービスを享受したいと考える利用者と、手軽に生体認証によるサービスを享受したいと考える利用者とが、含まれる。

即ち、利用者の希望に沿った多様な利用者登録の実現が求められている。なお、当該要望は特許文献１に開示された技術を適用しても実現されない。特許文献１は、本人確認の強化に関する技術を開示するためのである。

本発明は、利用者の希望を満たす多様な利用者登録を実現することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体を提供することを主たる目的とする。

本発明の第１の視点によれば、通常ユーザよりも多くのサービスの提供を受けることができる認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を前記通常ユーザとして管理する、本人確認制御手段と、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、前記利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と前記利用者種別を通知する、利用者登録制御手段と、を備える、サーバ装置が提供される。

本発明の第２の視点によれば、利用者が所持する端末と、生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより管理される、複数のサービスサーバと、サーバ装置と、を含み、前記サーバ装置は、通常ユーザよりも多くのサービスの提供を受けることができる認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を前記通常ユーザとして管理する、本人確認制御手段と、前記複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、前記利用者の端末から、生体認証に用いる認証情報の原本となる原本生体情報を取得し、前記利用者により選択されたサービス提供者のサービスサーバに、前記原本生体情報と前記利用者種別を含む利用者登録要求を送信する、利用者登録制御手段と、を備える、システムが提供される。

本発明の第３の視点によれば、サーバ装置において、通常ユーザよりも多くのサービスの提供を受けることができる認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を前記通常ユーザとして管理し、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とし、前記利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と前記利用者種別を通知する、サーバ装置の制御方法が提供される。

本発明の第４の視点によれば、サーバ装置に搭載されたコンピュータに、通常ユーザよりも多くのサービスの提供を受けることができる認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を前記通常ユーザとして管理する処理と、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする処理と、前記利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と前記利用者種別を通知する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

本発明の各視点によれば、利用者の希望を満たす多様な利用者登録を実現することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

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

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

一実施形態に係るサーバ装置１００は、本人確認制御手段１０１と、サービス選択制御手段１０２と、利用者登録制御手段１０３と、を備える（図１参照）。本人確認制御手段１０１は、通常ユーザよりも多くのサービスの提供を受けることができる認証ユーザとしてシステム登録を希望する利用者の本人確認を行う（図２のステップＳ１）。本人確認制御手段１０１は、本人確認に成功した利用者の利用者種別を認証ユーザとして管理する（ステップＳ２）。なお、本人確認制御手段１０１は、本人確認に成功していない利用者の利用者種別を通常ユーザとして管理する（利用者種別の初期値は通常ユーザである）。サービス選択制御手段１０２は、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする（ステップＳ３）。利用者登録制御手段１０３は、利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と利用者種別を通知する（ステップＳ４）。

サーバ装置１００は、認証ユーザとしてシステム登録を希望する利用者の本人確認を実行し、本人確認に成功した利用者を認証ユーザとして管理する。対して、サーバ装置１００は、本人確認を希望しない利用者は通常ユーザとして管理する。サーバ装置１００は、利用者の種別を原本生体情報と共にサービス提供者に通知する。サービス提供者は、取得した原本生体情報と利用者種別を用いて生体認証を用いたサービスを利用者に提供する。その際、サービス提供者は、利用者種別に応じて提供するサービスを変更する。その結果、認証ユーザに対しては生体認証を用いた多くのサービスが提供され、本人確認を望まず、手軽に生体認証を使ったサービスの提供を受けたい利用者に対しては限られたサービスが提供される。このように、サーバ装置１００は、利用者の希望を満たす多様な利用者登録を実現する。

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

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

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

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

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

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

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

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

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

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

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

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

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

認証端末３０は、サービスの提供を受ける利用者のインターフェイスとなる装置である。認証端末３０は、各サービス提供者それぞれのサービス提供場所に設置される。より具体的には、認証端末３０は、利用者が実際に訪れる店舗等に設置される。なお、認証端末３０は、サービス提供者と契約関係等にある事業者に設置されていてもよい。例えば、利用者が自治体からサービスを受ける際のインターフェイスとなる認証端末３０は、コンビニエンスストア等に設置されていてもよい。

認証端末３０は、サービス提供者の業種等に応じた機能、形態を備える。例えば、職場やイベント会場に設置された認証端末３０は、利用者（被認証者）の通行を制限するゲートを備えたゲート装置とすることができる。あるいは、市役所等に設置された認証端末３０は、住民の操作を受け付けるタッチパネルや住民票等を印刷するプリンター等を備える。また、小売店に設置された認証端末３０には、タブレット型の端末を用いることができる。

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

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

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

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

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

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

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

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

＜本人確認＞
ここで、認証システムには、２種類の利用者が存在する。

第１の利用者は、システムによる本人確認を経ずにサービス提供者からサービスの提供を受ける利用者である。以降の説明において、第１の利用者を「通常ユーザ」と表記する。

第２の利用者は、システムによる本人確認を経た後にサービス提供者からサービスの提供を受ける利用者である。以降の説明において、第２の利用者を「認証ユーザ」と表記する。認証ユーザは、通常ユーザよりも多くのサービスの提供を受けることができる。

利用者は、通常ユーザとしてのアカウントを生成するか、認証ユーザとしてのアカウントを生成するかを選択できる。

利用者が認証ユーザとしてアカウントを生成することを希望した場合、制御サーバ１０は、当該利用者の本人確認を行う。例えば、制御サーバ１０は、ＧＵＩ等を用いて上記利用者の希望（認証ユーザとしてアカウント生成）を取得すると、当該利用者の本人確認に関する制御を実行する。

利用者の本人確認は、公的機関から発行された証明書を用いて行われる。具体的には、制御サーバ１０は、マイナンバーカード、運転免許証、パスポート等の証明書を用いて本人確認を行う。第１の実施形態では、マイナンバーカードを本人確認書類として用いる場合について説明する。なお、運転免許証等を用いて本人確認を実行する場合には、制御サーバ１０は、運転免許証等から得られる顔画像と撮影により得られる顔画像を用いた１対１認証を実行すればよい。

利用者が認証ユーザとしてサービスの提供を受けることを希望すると、制御サーバ１０は、当該利用者が所持する端末４０に対して本人確認のために必要な情報の提供を要求する。具体的には、制御サーバ１０は、端末４０に対して「本人確認情報提供要求」を送信する（図５のステップＳ０１）。

当該本人確認情報提供要求の受信に応じて、端末４０は、利用者のマイナンバーカードから情報を読み込む。具体的には、端末４０は、マイナンバーカードのＩＣ（Integrated Circuit）チップに格納された電子証明書（署名用電子証明書、利用者証明証電子証明書）を取得する。

その際、端末４０は、マイナンバーカードから電子証明書を読み出すためのパスワード（４桁のパスワード、又は、６桁～１６桁のパスワード）を利用者から取得し、当該パスワードを使って電子証明書を取得する。以下、端末４０は署名用電子証明書をマイナンバーカードから取得した場合について説明する。また、以降の説明において、特段の釈明がない場合には、電子証明書は署名用電子証明書を示す。

端末４０は、上記取得した電子証明書を「本人確認情報」として制御サーバ１０に送信する（ステップＳ０２）。

制御サーバ１０は、取得した電子証明書を認証局（Ｊ－ＬＩＳ；Japan Agency for Local Authority Information Systems）により運営される認証局サーバ５０に送信する（ステップＳ０３）。制御サーバ１０は、取得した電子証明書を送信することで、電子証明書の検証を認証局サーバ５０に依頼する。

制御サーバ１０は、認証局サーバ５０から電子証明書の検証結果を受信する（ステップＳ０４）。制御サーバ１０は、認証局サーバ５０から電子証明書は有効である旨の応答を受信すると、本人確認に成功したと判定する。

本人確認に成功すると、制御サーバ１０は、当該本人確認に成功した利用者を「認証ユーザ」として管理する。なお、制御サーバ１０は、本人確認を受けていない利用者を「通常ユーザ」として管理する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

認証端末３０は、サービスの提供を受ける利用者（被認証者）の生体情報を取得する。例えば、認証端末３０は、被認証者を撮影し、原本生体情報に対応する生体情報（例えば、顔画像）を取得する。

また、認証端末３０は、利用者（被認証者）が提供を望むサービスに関する情報（以下、提供サービス情報と表記する）を取得する。例えば、利用者がオフィスへ入場する場合、「施設入場」が提供サービス情報として取得される。あるいは、利用者が住民票の発行を希望した場合、「住民票発行」が提供サービス情報として取得される。

認証端末３０は、利用者が希望するサービスの種類や自装置の形態等に応じて、自動的に提供サービス情報を決定してもよいし、ＧＵＩ等を用いて利用者から提供サービス情報を取得してもよい。例えば、上記の例では、認証端末３０は、「施設入場」を自動的に取得する。また、認証端末３０は、利用者の操作に応じて「住民票発行」を取得する。

認証端末３０は、取得した生体情報及び提供サービス情報を含む認証要求をサービスサーバ２０に送信する（図７参照）。なお、認証端末３０は、必要に応じて、提供サービス情報に付随する情報をサービスサーバ２０に送信する。例えば、「商品購入」に係る提供サービス情報が取得された場合、当該提供サービス情報と共に、商品名称や商品代金等の情報が提供サービス情報の付随情報としてサービスサーバ２０に送信される。

サービスサーバ２０は、認証要求に含まれる生体情報及び提供サービス情報と、利用者管理データベースに登録された生体情報、利用者種別及び業務情報と、を用いて利用者（被認証者）を認証する。

ここで、サービス提供者が通常ユーザに提供可能なサービスと認証ユーザに提供可能なサービスは異なる。認証ユーザには、通常ユーザに提供されるサービスに加え、本来、利用者の身元確認等が必要なサービスも提供される。即ち、認証ユーザに提供されるサービスは、通常ユーザに提供されるサービスを包含する。

上記の例では、オフィスへの「施設入場」に係るサービスは利用者種別に関わりなく被認証者に提供可能である。対して、「住民票発行」に係るサービスは認証ユーザに限り提供可能である。

認証要求を受信すると、サービスサーバ２０は、生体情報を用いた照合処理により利用者管理データベースに登録された被認証者を特定する。

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

サービスサーバ２０は、照合処理に失敗すると、認証結果に「認証失敗」を設定する。照合処理に成功すると、サービスサーバ２０は、認証要求に含まれる提供サービス情報と被認証者の利用者種別を用いて、当該被認証者が希望するサービスを被認証者に提供可能か否か判定する。

サービスサーバ２０は、提供サービス情報及び利用者種別を用いて、被認証者にサービスの提供ができないと判定した場合、認証結果に「認証失敗」を設定する。この場合、通常ユーザにはサービスが提供されない。なお、サービスサーバ２０は、その後の処理において、認証ユーザに対するサービス提供可否を判定する。

提供サービス情報及び利用者種別を用いて、被認証者にサービスの提供ができると判定した場合、サービスサーバ２０は、照合処理により特定された利用者の業務情報を用いて当該利用者にサービスの提供が可能か否か判定する。

例えば、提供サービス情報が「施設入場」の場合を考える。この場合、社員の勤務先企業のサービスサーバ２０は、被認証者が自社の社員であってオフィスに入場する資格を備えていれば、認証結果に「認証成功」を設定する。対して、当該サービスサーバ２０は、被認証者が自社の社員であってもオフィスに入場する資格を備えていなければ、認証結果に「認証失敗」を設定する。

あるいは、住民票発行の依頼を受けた市役所のサービスサーバ２０は、被認証者の住民票が発行可能であれば、認証結果に「認証成功」を設定する。対して、当該サービスサーバ２０は、被認証者が既に転出済等の理由により住民票の発行が不可であれば、認証結果に「認証失敗」を設定する。

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

認証端末３０は、認証結果に応じた処理を実行する。例えば、認証成功を受信すると、オフィスに設置された認証端末３０は、ゲートを開き被認証者の通行を許可する。あるいは、認証成功を受信すると、市役所等に設置された認証端末３０は、住民票を発行する。

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

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

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

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

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

また、アカウント管理部２０２は、利用者種別（通常ユーザ、認証ユーザ）に関する希望を利用者から取得する。利用者が認証ユーザとしてアカウントを生成することを希望した場合、アカウント管理部２０２は、その旨を本人確認制御部２０４に通知する。

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

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

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

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

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

本人確認制御部２０４は、利用者の本人確認を制御する手段である。本人確認制御部２０４は、認証ユーザとしてシステム登録を希望する利用者の本人確認を行う。本人確認制御部２０４は、本人確認に成功した利用者の利用者種別を「認証ユーザ」として管理する。本人確認制御部２０４は、本人確認に成功していない利用者（本人確認を受けていない利用者）の利用者種別を「通常ユーザ」として管理する。

本人確認制御部２０４は、アカウント管理部２０２から利用者が認証ユーザとしてアカウント生成を希望している旨の通知を受ける。当該通知により、利用者の希望（認証ユーザとして登録されることに関する希望）を認識すると、本人確認制御部２０４は、当該利用者の端末４０に対して、「本人確認情報提供要求」を送信する。

本人確認制御部２０４は、本人確認情報提供要求に対する応答（肯定応答、否定応答）を受信する。

否定応答を受信した場合（本人確認情報としての電子証明書が得られない場合）、本人確認制御部２０４は、認証ユーザとして登録できない旨を利用者に通知する。

肯定応答を受信した場合（本人確認情報としての電子証明書が得られた場合）、本人確認制御部２０４は、利用者のマイナンバーカードから読み出された電子証明書を認証局サーバ５０に送信する。

本人確認制御部２０４は、認証局サーバ５０から電子証明書の検証結果を受信する。

検証失敗（電子証明書は無効）を受信した場合、本人確認制御部２０４は、認証ユーザとして登録できない旨を利用者に通知する。この場合、本人確認制御部２０４は、利用者は通常ユーザとして登録され、受けられるサービスに制限があることを当該利用者に通知する。

検証成功（電子証明書は有効）を受信した場合、本人確認制御部２０４は、認証ユーザとして登録された旨を利用者に通知する。この場合、本人確認制御部２０４は、利用者は認証ユーザとして登録され、通常ユーザより多くのサービスが受けられることを当該利用者に通知する。

また、本人確認制御部２０４は、本人確認に成功した利用者を認証ユーザとして管理する。本人確認制御部２０４は、本人確認成功と判定された利用者を認証ユーザとしてアカウント管理データベースに登録する。

なお、アカウント管理データベースに記憶される利用者種別の初期値は「通常ユーザ」である。

このように、本人確認制御部２０４は、利用者の第１の証明書（マイナンバーカード）から得られる電子証明書を用いて、認証ユーザとしてシステム登録を望む利用者の本人確認を行う。

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

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

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

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

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

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

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

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

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

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

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

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

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

このように、利用者登録制御部２０６は、利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と利用者種別を通知する。より具体的には、利用者登録制御部２０６は、利用者の端末４０に対し、原本生体情報の提供を要求することで原本生体情報を取得する。利用者登録制御部２０６は、少なくとも取得された原本生体情報及び利用者種別を含む利用者登録要求を、利用者により選択されたサービス提供者のサービスサーバ２０に送信する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

照合処理に成功すると（ステップＳ１０２、Ｙｅｓ分岐）、認証部３０４は、認証要求に含まれる提供サービス情報と照合処理により特定された被認証者の利用者種別を用いて、当該被認証者にサービスの提供が可能か否か判定する。なお、認証部３０４は、必要に応じて、提供サービス情報の付随情報も用いて当該判定を実行する。認証部３０４は、利用者種別によるサービス提供可否の判定を行う（ステップＳ１０３）。

例えば、認証部３０４は、サービスごとに認証ユーザとして登録が必要か否かを記憶したテーブル情報を参照する。

被認証者が希望するサービスが通常ユーザ及び認証ユーザに提供可能なサービスであれば、認証部３０４は、サービス提供可と判定する。

被認証者が希望するサービスが認証ユーザに限り提供可能なサービスであれば、認証部３０４は、照合処理により特定された利用者が認証ユーザの場合に、サービス提供可と判定する。対して、照合処理により特定された利用者が通常ユーザの場合には、認証部３０４は、サービス提供不可と判定する。例えば、認証部３０４は、「住民票発行」のようなサービスに関し、認証ユーザに限りサービス提供可と判定する。

このように、認証部３０４は、利用者が選択した利用者種別（通常ユーザ、認証ユーザ）に応じて、被認証者が希望するサービスの提供可否を判定する。

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

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

例えば、社員の勤務先企業のサービスサーバ２０の認証部３０４は、被認証者が自社の社員であってオフィスに入場する資格を備えていれば、サービスの提供が可能と判定する。あるいは、住民票発行の依頼を受けた市役所のサービスサーバ２０の認証部３０４は、被認証者の住民票が発行可能であれば、サービスの提供が可能と判定する。あるいは、小売店等のサービスサーバ２０の認証部３０４は、クレジットカード情報等を用いた商品代金の決済に成功した場合に、サービスの提供が可能と判定する。

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

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

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

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

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

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

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

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

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

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

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

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

さらに、提供サービス制御部４０２は、提供サービス情報を生成する、又は、提供サービス情報を取得する。提供サービス制御部４０２は、認証端末３０に割り当てられた機能や利用者が選択したサービス等に応じた提供サービス情報を取得する。

例えば、オフィスの出入口に設置された認証端末３０の提供サービス制御部４０２は、自装置の面前に利用者を検出すると、「施設入場」を提供サービス情報として生成する。あるいは、市役所等に設置された認証端末３０の提供サービス制御部４０２は、ＧＵＩ等を用いて利用者が住民票発行の希望していることを認識すると、「住民票発行」を提供サービス情報として生成する。

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

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

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

例えば、利用者の勤務先に設置された認証端末３０の提供サービス制御部４０２は、認証成功を受信すると、ゲートを開き被認証者の入場を許可する。あるいは、市役所に設置された認証端末３０の提供サービス制御部４０２は、「住民票発行」に関する認証要求の応答として肯定応答を受信すると、当該肯定応答に含まれる情報（住民票を発行するための情報）を用いて住民票を発行する。

また、利用者は、認証ユーザとしてシステム登録することで、例えば、カジノのようなマイナンバーカードを用いた本人確認が必要な施設に生体認証で入場できる（所謂、顔パスで入場できる）。

認証失敗を受信した場合、提供サービス制御部４０２は、予め定められたメッセージ等を出力してもよい。例えば、市役所に設置された認証端末３０の提供サービス制御部４０２は、住民票発行について認証失敗を受信した場合、職員が待機するブース等の案内を行ってもよい。

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

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

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

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

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

アカウント生成制御部５０２は、利用者の操作に応じて、当該ＷＥＢページに、ログイン情報、氏名、生年月日等を入力する。また、アカウント生成制御部５０２は、利用者種別に関する利用者の希望（例えば、認証ユーザとしてアカウント登録）をＷＥＢページに入力する。

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

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

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

本人確認制御部５０４は、認証ユーザとしてシステム登録されるために必要な本人確認に関する制御を実行する手段である。本人確認制御部５０４は、制御サーバ１０から受信する「本人確認情報提供要求」を処理する。

制御サーバ１０から本人確認情報提供要求を受信すると、本人確認制御部５０４は、利用者のマイナンバーカードから電子証明書を取得する。その際、電子証明書に対応した暗証番号（パスワード）の入力が必要になる。本人確認制御部５０４は、図１７に示すようなＧＵＩを表示し、暗証番号（６桁から１６桁の英数字が混在した文字列）を取得する。

本人確認制御部５０４は、取得した暗証番号を用いてマイナンバーカードのＩＣチップから電子証明書（署名用電子証明書）の読み出しを試みる。正しい暗証番号が入力されていれば、本人確認制御部５０４は、電子証明書を読み出すことができる。

電子証明書が取得できた場合、本人確認制御部５０４は、当該電子証明書を「本人確認情報」として含む肯定応答を制御サーバ１０に送信する。

電子証明書（本人確認情報）が取得できない場合、本人確認制御部５０４は、その旨を示す否定応答を制御サーバ１０に送信する。

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

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

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

［認証局サーバ］
認証局サーバ５０の構成、動作に関する詳細な説明は省略する。認証局サーバ５０は、取得した電子証明書の有効性を判定し、判定結果（電子証明書は有効、無効）を制御サーバ１０に通知すればよい。

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

端末４０は、利用者が選択したサービスの情報（利用者が生体認証サービスの提供を受けたいサービス提供者の情報）を制御サーバ１０に送信する（サービスの情報を送信；ステップＳ２１）。

利用者が提供を受けたいサービスを選択すると、制御サーバ１０は、原本提供要求を当該利用者の端末４０に送信する（ステップＳ２２）。

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

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

サービスサーバ２０は、取得した原本生体情報から登録用の認証情報（登録認証情報）を生成する（ステップＳ２５）。生成された登録認証情報等は、利用者管理データベースに登録される。

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

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

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

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

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

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

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

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

＜第１の実施形態に係る変形例３＞
上記実施形態では、利用者は、システムアカウントの生成時に利用者種別（通常ユーザ、認証ユーザ）を選択する場合について説明した。しかし、利用者種別は、システムアカウントの生成後に変更されてもよい。

この場合、利用者がシステムアカウントにログインし、所定の操作（例えば、認証ユーザ登録ボタンの押下）を行うと、制御サーバ１０は、当該利用者の本人確認に関する制御を行う。具体的には、制御サーバ１０（本人確認制御部２０４）は、本人確認情報提供要求を端末４０に送信することで、本人確認情報（電子証明書）を取得する。

本人確認制御部２０４は、取得した電子証明書が有効であれば、当該利用者に関して利用者登録が終了している各サービス提供者に利用者種別の変更を通知する。具体的には、本人確認制御部２０４は、アカウント管理データベースの選択サービスフィールドに設定されている各サービス提供者のサービスサーバ２０に、システムＩＤと変更後の利用者種別（認証ユーザ）を含む「利用者種別変更通知」を送信する。

サービスサーバ２０（利用者登録制御部３０３）は、取得したシステムＩＤをキーとして利用者管理データベースを検索し、対応するエントリを特定する。利用者登録制御部３０３は、特定したエントリの利用者種別フィールドに認証ユーザを設定する。

利用者が認証ユーザから通常ユーザに利用者種別を変更することを希望した場合、制御サーバ１０は、システムＩＤと変更後の利用者種別（通常ユーザ）を含む「利用者種別変更通知」を利用者が選択済の各サービス提供者のサービスサーバ２０に送信すればよい。

＜第１の実施形態に係る変形例４＞
制御サーバ１０や端末４０は、利用者種別の状態を利用者に任意の手段によって通知してもよい。即ち、利用者が所持する端末４０は、利用者の利用者種別（通常ユーザ、認証ユーザ）に応じた表示を行ってもよい。

例えば、システムアカウントにログインすると、制御サーバ１０は、当該利用者のポータルサイトに利用者種別の状態を表示してもよい。例えば、制御サーバ１０（アカウント管理部２０２）は、端末４０に図１９に示すような表示を行ってもよい。なお、図１９では、利用者種別を文字により表示しているが、制御サーバ１０は、任意の方法、態様により利用者種別を表示することができる。例えば、制御サーバ１０は、図形（アイコン）、記号、アイコンの点滅等により利用者種別を区別して表示してもよい。

あるいは、端末４０は、制御サーバ１０から利用者種別を取得し、当該取得した利用者種別を記憶する。端末４０は、待ち受け画面やメニュー画面等に利用者種別に応じたアイコン等を表示してもよい。

＜第１の実施形態に係る変形例５＞
制御サーバ１０は、マイナンバーカードとは異なる証明書を用いて本人確認を行ってもよい。例えば、制御サーバ１０（本人確認制御部２０４）は、運転免許証、パスポート等の顔写真が添付された証明書を用いて本人確認を行ってもよい。

端末４０（本人確認制御部５０４）は、制御サーバ１０から本人確認情報提供要求を受信すると、利用者を撮影（所謂、自撮り）することで得られる画像データと、運転免許証等を撮影することで得られる画像データと、を取得する。端末４０は、取得した２つの画像データを本人確認情報として制御サーバ１０に送信する。

制御サーバ１０は、利用者を撮影することで得られた撮影顔画像と証明書に記載されている証明書顔画像を用いた１対１認証を実行する。制御サーバ１０は、１対１認証に成功すれば、本人確認成功と判定する。制御サーバ１０は、１対１認証に失敗すれば、本人確認失敗と判定する。

本人確認に成功すると、制御サーバ１０は、利用者を認証ユーザとして扱う。

以上のように、第１の実施形態では、生体認証を用いたサービスの提供に必要な原本生体情報（例えば、顔画像）を利用者自身が管理する認証システムにおいて、当該利用者の本人確認がマイナンバーカードのような証明書を利用して行われる。本人確認が完了した認証ユーザは、本人確認が完了していない通常ユーザと区別して扱われる。認証ユーザは、通常ユーザが提供を受けるサービス以上のサービスの提供を受けることができる。例えば、認証ユーザは、住民票の発行のように、本来、マイナンバーカード等を用いた本人確認が必要なサービス（職員等による本人確認が必要なサービス）を生体認証により享受できる。その結果、利用者（認証ユーザ）の利便性が向上すると共に、サービス提供者（上記の例では自治体）の業務効率化が向上する。また、マイナンバーカード等を用いた本人確認を躊躇する利用者に対しても、限られた範囲内で生体認証を用いたサービスが提供される。

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

第２の実施形態では、利用者登録の際、制御サーバ１０からサービス提供者（サービスサーバ２０）に認証ユーザの年齢情報（生年月日）が通知される場合について説明する。第２の実施形態に係るサービスサーバ２０は、認証ユーザの年齢に基づいてサービスの提供可否を判定する。

なお、第２の実施形態に係る認証システムの構成は第１の実施形態と同一とすることができるので図３に相当する説明を省略する。また、第２の実施形態に係る制御サーバ１０等の処理構成も第１の実施形態と同一とすることができるので、その説明を省略する。

以下、第１の実施形態と第２の実施形態の相違点を中心に説明する。

利用者が認証ユーザとしてサービスの享受を希望すると、制御サーバ１０（本人確認制御部２０４）は、署名用電子証明書から利用者の生年月日を取得する。なお、署名用電子証明書には、所謂、基本４情報（氏名、性別、住所、生年月日）が含まれる。本人確認制御部２０４は、取得した生年月日をアカウント管理データベースに記憶する。

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

サービスサーバ２０（利用者登録制御部３０３）は、取得したシステムＩＤ、利用者種別、生年月日等を利用者管理データベースに記憶する。

サービスサーバ２０（認証部３０４）は、利用者を認証する際、当該利用者（被認証者）の生年月日（年齢）を用いる。

図２０は、第２の実施形態に係る認証部３０４の動作の一例を示すフローチャートである。なお、図１３と図２０において同一の処理内容とすることができる処理については同じ符号を付与し、説明を省略する。

ここで、利用者に提供されるサービスには、年齢確認が必要なサービスが存在する。例えば、酒やタバコといった商品の購入には年齢による制限が存在する。認証部３０４は、利用者に対するサービス提供可否について、利用者の年齢に基づいて判定する（ステップＳ２０１）。

例えば、認証部３０４は、サービスごとに年齢制限の有無やサービス提供可能な年齢の下限値が記載されたテーブル情報を参照する。

利用者が希望するサービスが年齢確認不要なサービスであれば、認証部３０４は、サービス提供可と判定する。

利用者が希望するサービスが年齢確認の必要なサービスであれば、認証部３０４は、照合処理により特定された生年月日から年齢を算出し、利用者の年齢がサービス提供の要件として定められた所定の年齢に達しているか否か判定する。

利用者（被認証者）の年齢が所定の年齢に達していれば、認証部３０４は、サービス提供可と判定する。対して、利用者（被認証者）の年齢が所定の年齢に達していなければ、認証部３０４は、サービス提供不可と判定する。

利用者の年齢に基づいてサービス提供不可と判定された場合（ステップＳ２０２、Ｎｏ分岐）、認証部３０４は、認証結果に認証失敗を設定する（ステップＳ１０５）。

利用者の年齢に基づきサービス提供可と判定された場合（ステップＳ２０２、Ｙｅｓ分岐）、認証部３０４は、業務情報による判定を行う（ステップＳ１０６）。

なお、サービスサーバ２０は、被認証者の年齢をサービス提供時に活用してよい。サービスサーバ２０は、被認証者が所定の年齢以上（例えば、６０歳以上）であれば、料金の割引を行ってもよい。即ち、サービスサーバ２０は、被認証者の年齢を用いてシルバー割引（シニア割引）等を実現してもよい。

以上のように、第２の実施形態に係る制御サーバ１０は、利用者の本人確認に成功すると、当該本人確認に成功した認証ユーザの電子証明書から生年月日を取得する。制御サーバ１０は、利用者により選択されたサービス提供者に対し、システムＩＤ、利用者種別、原本生体情報等に加え、上記取得された生年月日をさらに通知する。サービス提供者は、マイナンバーカード（署名用電子証明書）から得られる年齢に基づいて、年齢制限のあるサービスの提供可否を判断できるので、安心してサービスの提供を行うことができる。また、利用者は、年齢確認のためにマイナンバーカード等の証明書を小売店の店員等に提示することなく、生体認証により酒、タバコ等を購入できる。即ち、利用者の利便性が向上する。また、小売店等も本人確認のための店員を確保する必要がないので、業務効率が向上する。

［第３の実施形態］
続いて、第３の実施形態について図面を参照して詳細に説明する。

第３の実施形態では、利用者は、認証ユーザとして登録を受けるための第１の証明書（例えば、マイナンバーカード）以外の第２の証明書をシステムに提供する場合について説明する。第３の実施形態に係る制御サーバ１０は、第２の証明書から得られる利用者の地位、立場、状況、状態、技能、資格等の属性情報をサービス提供者に通知する。サービス提供者は、通知された属性情報に基づいて、利用者の認証を行ったりサービスの提供を行ったりする。

なお、第３の実施形態に係る認証システムの構成は第１の実施形態と同一とすることができるので図３に相当する説明を省略する。

以下、第１の実施形態乃至第３の実施形態の相違点を中心に説明する。

制御サーバ１０は、アカウント生成時等において、利用者を認証ユーザとして登録するための証明書（本人確認書類；マイナンバーカード）とは異なる他の証明書から属性情報を取得する。具体的には、制御サーバ１０は、利用者の地位、立場、状況、状態、技能、資格等を証明する証明書から当該属性情報を取得する。

例えば、学生であることを証明する学生証、障害者であることを証明する障害者手帳、自動車等の運転が可能であることを証明する運転免許証、特定の資格（例えば、医師等）を有することの身分証明書が、上記証明書に該当する。あるいは、健康保険証も上記証明書に含まれる。

図２１は、第３の実施形態に係る制御サーバ１０の処理構成（処理モジュール）の一例を示す図である。図２１を参照すると、第１の実施形態に係る制御サーバ１０の構成に属性情報取得部２０８が追加されている。

属性情報取得部２０８は、認証ユーザ登録のための本人確認に用いられる第１の証明書とは異なる第２の証明書から属性情報を取得する手段である。

システムアカウント生成時又はシステムアカウント生成後に、利用者がポータルサイトにおいて学生証、障害者手帳等の登録を希望すると、属性情報取得部２０８は、ＧＵＩ等を用いて当該学生証等が写る画像データを取得する。

属性情報取得部２０８は、取得した画像データから学生証等に記載された氏名、生年月日等の情報を抽出する。例えば、属性情報取得部２０８は、ＯＣＲ（Optical Character Recognition）技術等を用いて、学生証等に記載された氏名、生年月日等を取得する。

属性情報取得部２０８は、第２の証明書（学生証、障害者手帳等）から得られる氏名、生年月日等と、利用者（本人確認が完了している認証ユーザ）の氏名、生年月日等と、を比較し、両者が一致した場合に、正当な証明書が登録されたと判定する。

正当な証明書と判定された場合、属性情報取得部２０８は、第２の証明書（学生証、障害者手帳等）から利用者の地位、立場、状況等の属性情報を取得する。例えば、属性情報取得部２０８は、学習モデルに証明書が写る画像データを入力することで、属性情報を取得する。

なお、当該学習モデルは、画像データにラベル（地位、立場、状況等）が付与された教師データを用いた機械学習の実行により生成される。学習モデルの生成には、サポートベクタマシン、ブースティングやニューラルネットワーク等の任意のアルゴリズムを用いることができる。なお、上記サポートベクタマシン等のアルゴリズムは公知の技術を使用することができるので、その説明を省略する。

第２の証明書から利用者の属性情報を取得すると、属性情報取得部２０８は、当該取得した属性情報をアカウント管理データベースに記憶する。

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

サービスサーバ２０（利用者登録制御部３０３）は、取得したシステムＩＤ、利用者種別、属性情報を利用者管理データベースに記憶する。

サービスサーバ２０（認証部３０４）は、利用者管理データベースに登録された被認証者の属性情報（地位、立場、状況、技能、資格等）を用いて認証処理を行ったり所定の特典を付与したりする。

例えば、被認証者が学生であれば、サービスサーバ２０は、当該被認証者に対して学割で定期券等を販売してもよい。あるいは、被認証者が障害者あれば、サービスサーバ２０は、バスや電車等の運賃を割り引いてもよい。あるいは、被認証者がシルバーパスを購入していれば、サービスサーバ２０は、バスや電車等の運賃を割引してもよい。

＜第３の実施形態の変形例＞
制御サーバ１０は、利用者の属性情報を取得するための証明書以外の書類から情報を取得し、当該取得した情報をサービス提供者に通知してもよい。

例えば、制御サーバ１０は、利用者からお薬手帳の登録を受け付け、当該お薬手帳から利用者の服薬に関する情報（服薬情報）を取得してもよい。制御サーバ１０は、利用者登録の際に、原本生体情報等と共に服薬情報をサービス提供者に通知してもよい。

サービス提供者（例えば、病院、薬局）は、取得した服薬情報を利用者（患者）の治療、服薬指導等に役立ててもよい。

以上のように、第３の実施形態に係る制御サーバ１０は、利用者の第２の証明書（例えば、学生証、障害者手帳）から当該利用者の属性情報を取得する。制御サーバ１０は、利用者により選択されたサービス提供者に対し、原本生体情報、利用者種別等に加え、取得された属性情報をさらに通知する。サービス提供者は、学生証や障害者手帳のような証明書から得られる属性情報に基づいて、被認証者を認証したりサービスを提供したりできる。利用者は、証明書を有することで得られる特典等を受けるために、当該証明書をサービス提供者の職員、店員等に提示する必要がない。そのため、利用者の利便性が向上する。また、サービス提供者は、証明書確認のための人員を確保する必要がないので、業務効率が向上する。

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

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

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

プロセッサ３１１は、例えば、ＣＰＵ（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 (13)

1. 認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を通常ユーザとして管理する、本人確認制御手段と、
   生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、
   前記利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と前記利用者種別を通知する、利用者登録制御手段と、
   を備える、サーバ装置。
2. 前記本人確認制御手段は、前記利用者の第１の証明書から得られる電子証明書を用いて、前記本人確認を行う、請求項１に記載のサーバ装置。
3. 前記本人確認制御手段は、前記本人確認に成功すると、前記利用者の生年月日を取得し、
   前記利用者登録制御手段は、前記利用者により選択されたサービス提供者に対し、前記取得された生年月日をさらに通知する、請求項２に記載のサーバ装置。
4. 前記利用者の第２の証明書から前記利用者の属性情報を取得する、属性情報取得手段をさらに備え、
   前記利用者登録制御手段は、前記利用者により選択されたサービス提供者に対し、前記取得された属性情報をさらに通知する、請求項２に記載のサーバ装置。
5. 前記利用者登録制御手段は、前記利用者が所持する端末に対し、前記原本生体情報の提供を要求することで前記原本生体情報を取得し、少なくとも前記取得された原本生体情報及び前記利用者種別を含む利用者登録要求を前記利用者により選択されたサービス提供者のサーバに送信する、請求項１乃至４のいずれか一項に記載のサーバ装置。
6. 前記利用者登録制御手段は、少なくとも、自装置で前記利用者を管理するためのシステムＩＤ、前記取得された原本生体情報及び前記利用者種別を含む前記利用者登録要求を前記サーバに送信する、請求項５に記載のサーバ装置。
7. 前記原本生体情報は、顔画像である請求項６に記載のサーバ装置。
8. 前記第１の証明書は、マイナンバーカードである、請求項２に記載のサーバ装置。
9. 利用者が所持する端末と、
   生体認証を用いたサービスを提供する、複数のサービス提供者それぞれにより管理される、複数のサービスサーバと、
   サーバ装置と、
   を含み、
   前記サーバ装置は、
   認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を通常ユーザとして管理する、本人確認制御手段と、
   前記複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、
   前記利用者の端末から、生体認証に用いる認証情報の原本となる原本生体情報を取得し、前記利用者により選択されたサービス提供者のサービスサーバに、前記原本生体情報と前記利用者種別を含む利用者登録要求を送信する、利用者登録制御手段と、
   を備える、システム。
10. 前記複数のサービスサーバのうち前記利用者登録要求を受信したサービスサーバは、前記利用者種別に応じて、被認証者が希望するサービスの提供可否を判定する、請求項９に記載のシステム。
11. 前記利用者が所持する端末は、前記利用者種別に応じた表示を行う、請求項９又は１０に記載のシステム。
12. サーバ装置において、
    認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を通常ユーザとして管理し、
    生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とし、
    前記利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と前記利用者種別を通知する、サーバ装置の制御方法。
13. サーバ装置に搭載されたコンピュータに、
    認証ユーザとしてシステム登録を希望する利用者の本人確認を行い、前記本人確認に成功した利用者の利用者種別を前記認証ユーザとして管理し、前記本人確認に成功していない利用者の前記利用者種別を通常ユーザとして管理する処理と、
    生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする処理と、
    前記利用者により選択されたサービス提供者に、生体認証に用いる認証情報の原本となる原本生体情報と前記利用者種別を通知する処理と、
    を実行させるためのプログラム。

Images