特許 7589865 サーバ装置、システム、サーバ装置の制御方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-18

(45)【発行日】2024-11-26

(54)【発明の名称】サーバ装置、システム、サーバ装置の制御方法及びプログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20241119BHJP

【ＦＩ】

G06Q50/10

【請求項の数】 4

(21)【出願番号】P 2024521808

(86)(22)【出願日】2022-11-01

(86)【国際出願番号】 JP2022040921

(87)【国際公開番号】W WO2024095377

(87)【国際公開日】2024-05-10

【審査請求日】2024-04-10

【早期審査対象出願】

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100168310

【弁理士】

【氏名又は名称】▲高▼橋 幹夫

(72)【発明者】

【氏名】四分一 大助

(72)【発明者】

【氏名】新宮 由久

(72)【発明者】

【氏名】柳澤 一精

(72)【発明者】

【氏名】太田 知秀

【審査官】青柳 光代

(56)【参考文献】

【文献】特開２０２２－００１９８８（ＪＰ，Ａ）

【文献】特開２０２０－０５２５７４（ＪＰ，Ａ）

【文献】特開２０２１－１３５９０１（ＪＰ，Ａ）

【文献】特開２０２２－１４５７９３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

複数の利用者それぞれのシステムＩＤとログイン情報を記憶する、記憶手段と、
前記ログイン情報を用いて自装置の第１のアカウントにログインする利用者を認証する、アカウント管理手段と、
生体認証を用いたサービスを提供する複数のサービス提供者それぞれに対応するアイコンの一覧を含み、前記利用者が一覧表示された複数のサービス提供者に対応する複数のアイコンのなかから一のアイコンを選択するＧＵＩ（Graphical User Interface）を前記利用者が所持する端末に表示し、前記ＧＵＩを用いて前記利用者がサービスの提供を受けたいサービス提供者を特定する、サービス選択制御手段と、
前記特定されたサービス提供者が、顧客を管理するための第２のアカウントを有し、且つ、前記顧客にサービスを提供する際、被認証者を特定するための認証情報とサービスの提供に伴う決済に必要な業務情報用いて前記生体認証を行うサービス提供者の場合、前記利用者が所持する端末に、前記第１のアカウントにログインした前記利用者に対応する前記システムＩＤを含むＵＲＬ（Uniform Resource Locator）であって、前記利用者が前記特定されたサービス提供者の第２のアカウントにログインするためのリダイレクト用ＵＲＬを送信し、前記利用者の前記第２のアカウントを管理する前記サービス提供者のサーバであって、前記利用者が前記特定されたサービス提供者の第２のアカウントに前記リダイレクト用ＵＲＬに従ってログインしたサービスサーバから前記リダイレクト用ＵＲＬに含まれる前記システムＩＤを含む生体情報提供要求を受信したことに応じて、前記生体情報提供要求に含まれる前記システムＩＤに対応する前記利用者が所持する端末に対し、前記特定されたサービス提供者が前記認証情報を生成する際の原本となる原本生体情報を送信するように要求することで、前記利用者が所持する端末から前記利用者が所持する端末に予め記憶された前記利用者の前記原本生体情報を受信し、前記受信した原本生体情報を前記特定されたサービス提供者の前記サービスサーバに送信する、利用者登録制御手段と、
を備える、サーバ装置。

【請求項2】

利用者が所持する端末と、
サーバ装置と、
複数のサービス提供者それぞれにより管理される、複数のサービスサーバと、
を含み、
前記サーバ装置は、
複数の利用者それぞれのシステムＩＤとログイン情報を記憶し
前記ログイン情報を用いて自装置の第１のアカウントにログインする利用者を認証し、
生体認証を用いたサービスを提供する複数のサービス提供者それぞれに対応するアイコンの一覧を含み、前記利用者が一覧表示された複数のサービス提供者に対応する複数のアイコンのなかから一のアイコンを選択するＧＵＩ（Graphical User Interface）を前記利用者が所持する端末に表示し、前記ＧＵＩを用いて前記利用者がサービスの提供を受けたいサービス提供者を特定し、
前記特定されたサービス提供者が、顧客を管理するための第２のアカウントを有し、且つ、前記顧客にサービスを提供する際、被認証者を特定するための認証情報とサービスの提供に伴う決済に必要な業務情報を用いて前記生体認証を行うサービス提供者の場合、前記利用者が所持する端末に、前記第１のアカウントにログインした前記利用者に対応する前記システムＩＤを含むＵＲＬ（Uniform Resource Locator）であって、前記利用者が前記特定されたサービス提供者の第２のアカウントにログインするためのリダイレクト用ＵＲＬを送信し、
前記利用者が所持する端末は、受信した前記リダイレクト用ＵＲＬに従って前記特定されたサービス提供者に対応する前記サービスサーバにアクセスし、
前記特定されたサービス提供者に対応する前記サービスサーバは、前記第２のアカウントにログインした前記利用者が所持する端末から前記システムＩＤを取得し、前記取得したシステムＩＤを含む生体情報提供要求を前記サーバ装置に送信し、
前記サーバ装置は、受信した前記生体情報提供要求に含まれる前記システムＩＤに対応する前記利用者が所持する端末に対し、前記特定されたサービス提供者が前記認証情報を生成する際の原本となる原本生体情報を送信するように要求し、
前記利用者が所持する端末は、予め記憶された前記利用者の前記原本生体情報を前記サーバ装置に送信し、
前記サーバ装置は、受信した前記原本生体情報を前記特定されたサービス提供者に対応する前記サービスサーバに送信する、システム。

【請求項3】

サーバ装置において、
複数の利用者それぞれのシステムＩＤとログイン情報を記憶し、
前記ログイン情報を用いて自装置の第１のアカウントにログインする利用者を認証し、
生体認証を用いたサービスを提供する複数のサービス提供者それぞれに対応するアイコンの一覧を含み、前記利用者が一覧表示された複数のサービス提供者に対応する複数のアイコンのなかから一のアイコンを選択するＧＵＩ（Graphical User Interface）を前記利用者が所持する端末に表示し、前記ＧＵＩを用いて前記利用者がサービスの提供を受けたいサービス提供者を特定し、
前記特定されたサービス提供者が、顧客を管理するための第２のアカウントを有し、且つ、前記顧客にサービスを提供する際、被認証者を特定するための認証情報とサービスの提供に伴う決済に必要な業務情報を用いて前記生体認証を行うサービス提供者の場合、前記利用者が所持する端末に、前記第１のアカウントにログインした前記利用者に対応する前記システムＩＤを含むＵＲＬ（Uniform Resource Locator）であって、前記利用者が前記特定されたサービス提供者の第２のアカウントにログインするためのリダイレクト用ＵＲＬを送信し、前記利用者の前記第２のアカウントを管理する前記サービス提供者のサーバであって、前記利用者が前記特定されたサービス提供者の第２のアカウントに前記リダイレクト用ＵＲＬに従ってログインしたサービスサーバから前記リダイレクト用ＵＲＬに含まれる前記システムＩＤを含む生体情報提供要求を受信したことに応じて、前記生体情報提供要求に含まれる前記システムＩＤに対応する前記利用者が所持する端末に対し、前記特定されたサービス提供者が前記認証情報を生成する際の原本となる原本生体情報を送信するように要求することで、前記利用者が所持する端末から前記利用者が所持する端末に予め記憶された前記利用者の前記原本生体情報を受信し、前記受信した原本生体情報を前記特定されたサービス提供者の前記サービスサーバに送信する、サーバ装置の制御方法。

【請求項4】

サーバ装置に搭載されたコンピュータに、
複数の利用者それぞれのシステムＩＤとログイン情報を記憶する処理と、
前記ログイン情報を用いて自装置の第１のアカウントにログインする利用者を認証する処理と、
生体認証を用いたサービスを提供する複数のサービス提供者それぞれに対応するアイコンの一覧を含み、前記利用者が一覧表示された複数のサービス提供者に対応する複数のアイコンのなかから一のアイコンを選択するＧＵＩ（Graphical User Interface）を前記利用者が所持する端末に表示し、前記ＧＵＩを用いて前記利用者がサービスの提供を受けたいサービス提供者を特定する処理と、
前記特定されたサービス提供者が、顧客を管理するための第２のアカウントを有し、且つ、前記顧客にサービスを提供する際、被認証者を特定するための認証情報とサービスの提供に伴う決済に必要な業務情報を用いて前記生体認証を行うサービス提供者の場合、前記利用者が所持する端末に、前記第１のアカウントにログインした前記利用者に対応する前記システムＩＤを含むＵＲＬ（Uniform Resource Locator）であって、前記利用者が前記特定されたサービス提供者の第２のアカウントにログインするためのリダイレクト用ＵＲＬを送信し、前記利用者の前記第２のアカウントを管理する前記サービス提供者のサーバであって、前記利用者が前記特定されたサービス提供者の第２のアカウントに前記リダイレクト用ＵＲＬに従ってログインしたサービスサーバから前記リダイレクト用ＵＲＬに含まれる前記システムＩＤを含む生体情報提供要求を受信したことに応じて、前記生体情報提供要求に含まれる前記システムＩＤに対応する前記利用者が所持する端末に対し、前記特定されたサービス提供者が前記認証情報を生成する際の原本となる原本生体情報を送信するように要求することで、前記利用者が所持する端末から前記利用者が所持する端末に予め記憶された前記利用者の前記原本生体情報を受信し、前記受信した原本生体情報を前記特定されたサービス提供者の前記サービスサーバに送信する処理と、
を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

例えば、特許文献１には、商品およびサービスの購入における電子マネー決済の安全性と利便性を両立させる、と記載されている。特許文献１の生体認証装置は、ユーザを識別するＣＩＤと顔画像を取得する。当該生体認証装置は、在店者の顔画像群をあらかじめダウンロードしておき、これらの顔画像群と得られた顔画像を照合することにより、ユーザを認証する。認証に成功したとき、生体認証装置は、ユーザが購入する商品の料金の決済を決済装置に要求し、決済装置により決済許可されたとき、商品の購入を許可する。

【0004】

特許文献２には、顔認証を用いた利便性の高い情報処理システムを提供する、と記載されている。特許文献２の情報処理システムは、来店者の顔を含む画像を取得する第１のインターフェイスと、第１のプロセッサと、第２のインターフェイスと、第２のプロセッサとを有する。第１のプロセッサは、第１のインターフェイスにより取得した画像から抽出する来店者の顔情報と会員データベースに登録済みの各会員の登録顔情報とを顔認証する。第１のプロセッサは、来店者の顔情報との認証が成功した登録顔情報に対応する会員の登録情報を来店者の顔情報に対応づけて来店者データベースに記憶する。第２のプロセッサは、第２のインターフェイスにより取得した画像から抽出する決済対象者の顔情報と来店者データベースが記憶する来店者の顔情報とを顔認証する。第２のプロセッサは、決済対象者の顔情報との認証が成功した来店者の顔情報に対応する会員の登録情報を用いて決済処理を行う。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１９－０６７０７５号公報

【文献】特開２０１８－１０１４２０号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

近年、生体認証を用いた様々なサービスの提供が始まっている。利用者は、生体認証を用いたサービスを受ける前に、自身の生体情報（例えば、顔画像）をサーバに登録する必要がある。その際、複数のサービス提供者（例えば、小売業者、交通事業者）それぞれからサービスの提供を受けるためには、利用者は、サービス提供者ごとに生体情報を登録する必要がある。

【0007】

ここで、サービス提供者のそれぞれは、その業態により顧客を管理するためのアカウントの有無や顧客にサービスを提供する際の業務情報の種類等が異なる。そのため、各サービス提供者のタイプに適した生体情報の登録方法（登録方式）が求められる。

【0008】

本発明は、サービス提供者のタイプに適した生体情報の登録を実現することに寄与する、サーバ装置、システム、サーバ装置の制御方法及び記憶媒体を提供することを主たる目的とする。

【課題を解決するための手段】

【0009】

本発明の第１の視点によれば、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う、利用者登録制御手段と、を備える、サーバ装置が提供される。

【0010】

本発明の第２の視点によれば、利用者が所持する端末と、サーバ装置と、を含み、前記サーバ装置は、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う、利用者登録制御手段と、を備え、前記利用者登録制御手段は、前記利用者の端末に対し、前記利用者により選択されたサービス提供者のアカウントにログインするための情報を送信し、前記利用者のアカウントを管理するサーバから生体情報提供要求を受信したことに応じて、前記端末に対し、生体認証に用いられる認証情報の原本となる原本生体情報の提供を要求することで前記原本生体情報を前記端末から取得し、前記取得された原本生体情報を前記サーバに送信する、システムが提供される。

【0011】

本発明の第３の視点によれば、サーバ装置において、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とし、前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う、サーバ装置の制御方法が提供される。

【0012】

本発明の第４の視点によれば、サーバ装置に搭載されたコンピュータに、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする処理と、前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

【発明の効果】

【0013】

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

【図面の簡単な説明】

【0014】

【図1】図１は、一実施形態の概要を説明するための図である。

【図2】図２は、一実施形態の動作の一例を示すフローチャートである。

【図3】図３は、第１の実施形態に係る認証システムの概略構成の一例を示す図である。

【図4】図４は、第１の実施形態に係る認証システムの動作を説明するための図である。

【図5】図５は、第１の実施形態に係る認証システムの動作を説明するための図である。

【図6】図６は、第１の実施形態に係る認証システムの動作を説明するための図である。

【図7】図７は、第１の実施形態に係る制御サーバの処理構成の一例を示す図である。

【図8】図８は、第１の実施形態に係るアカウント管理データベースの一例を示す図である。

【図9】図９は、第１の実施形態に係る端末の表示の一例を示す図である。

【図10】図１０は、第１の実施形態に係る端末の表示の一例を示す図である。

【図11】図１１は、第１の実施形態に係る制御サーバの動作の一例を示すフローチャートである。

【図12】図１２は、第１の実施形態に係るサービスサーバの処理構成の一例を示す図である。

【図13】図１３は、第１の実施形態に係る利用者管理データベースの一例を示す図である。

【図14】図１４は、第１の実施形態に係る認証端末の処理構成の一例を示す図である。

【図15】図１５は、第１の実施形態に係る端末の処理構成の一例を示す図である。

【図16】図１６は、第１の実施形態に係る端末の表示の一例を示す図である。

【図17】図１７は、第１の実施形態に係る認証システムの動作の一例を示すシーケンス図である。

【図18】図１８は、第２の実施形態に係る認証システムの動作を説明するための図である。

【図19】図１９は、第２の実施形態に係る端末の表示の一例を示す図である。

【図20】図２０は、第２の実施形態に係る認証システムの動作を説明するための図である。

【図21】図２１は、第３の実施形態に係る認証システムの動作を説明するための図である。

【図22】図２２は、第３の実施形態に係る認証システムの動作を説明するための図である。

【図23】図２３は、第３の実施形態に係る認証システムの動作を説明するための図である。

【図24】図２４は、第３の実施形態に係る認証システムの動作の一例を示すシーケンス図である。

【図25】図２５は、第４の実施形態に係る認証システムの動作を説明するための図である。

【図26】図２６は、第４の実施形態に係る端末の表示の一例を示す図である。

【図27】図２７は、本願開示に係る制御サーバのハードウェア構成の一例を示す図である。

【図28】図２８は、本願開示の変形例に係る端末の表示の一例を示す図である。

【図29】図２９は、本願開示の変形例に係る認証システムの概略構成の一例を示す図である。

【図30】図３０は、本願開示の変形例に係る認証システムの概略構成の一例を示す図である。

【発明を実施するための形態】

【0015】

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

【0016】

一実施形態に係るサーバ装置１００は、サービス選択制御手段１０１と、利用者登録制御手段１０２と、を備える（図１参照）。サービス選択制御手段１０１は、生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする（サービス提供者の選択制御；図２のステップＳ１）。利用者登録制御手段１０２は、利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う（利用者登録制御の実行；ステップＳ２）。

【0017】

上述のように、利用者に生体認証を用いたサービスを提供するサービス提供者には様々なタイプが存在する。例えば、顧客を関するためのアカウント（顧客がログインするポータルサイト）の有無や、生体認証を用いたサービスを提供する際に使用する業務情報の使われ方によりサービス提供者のタイプを分けることができる。また、個人情報保護に対する利用者の意識の変化から、スマートフォン等の端末に生体認証に認証情報の原本となる原本生体情報（例えば、顔画像）が格納され、利用者自身が原本生体情報を管理する認証システムが存在する。このような認証システムにおいて、顧客を管理するためのアカウントを有し、且つ、顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が利用者により選択された場合、サーバ装置１００は、当該サービス提供者が利用者の原本生体情報を取得し登録するための利用者登録制御を実行する。例えば、上記サービス提供者として、決済のためのクレジットカード情報を業務情報として使用する小売店等が想定される。例えば、サーバ装置１００は、利用者の端末に対し、自身のアカウントにアクセスするためのリダイレクト用のＵＲＬ（Uniform Resource Locator）を送信する。サーバ装置１００は、利用者がアカウント（ポータルサイト）にログインしたサーバから原本生体情報の提供を要求されると、利用者の端末から原本生体情報を取得し、上記サーバに送信する。即ち、サービス提供者のタイプに適した生体情報の登録を実現するサーバ装置１００が提供される。

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

ここで、上述のように、サービス提供者は、その業種、業態により様々なタイプが存在する。本願開示では、認証システムに参加する各サービス提供者を４つのタイプに分類する。

【0047】

第１のタイプに属するサービス提供者は、サービスを提供する利用者を管理するためのアカウント（ポータルサイト）を持たず、且つ、同じ業務情報を繰り返し使用する事業者である。例えば、小規模な企業（利用者の勤務先企業）やマンション管理会社等のサービス提供者が第１のタイプに属する。

【0048】

第２のタイプに属するサービス提供者は、サービスを提供する利用者を管理するためのアカウント（ポータルサイト）を持たず、且つ、認証に必要な業務情報を原則として１回に限り使用する事業者である。例えば、他社（チケット販売会社等）にチケットの販売を委託し、遊園地、テーマパーク等を運営する事業者や、コンサート等のイベントを開催するイベント会社等が第２のタイプに属する。

【0049】

第３のタイプに属するサービス提供者は、サービスを提供する利用者（顧客）を管理するためのアカウント（ポータルサイト）を持ち、且つ、同じ業務情報を繰り返し使用する事業者である。例えば、商品を販売する小売事業者等のサービス提供者が第３のタイプに属する。

【0050】

第４のタイプに属するサービス提供者は、サービスを提供する利用者を管理するためのアカウント（ポータルサイト）を持ち、且つ、認証に必要な業務情報を原則として１回に限り使用する事業者である。例えば、自社でチケットを販売し、遊園地、テーマパーク等を運営する事業者や、コンサート等のイベントを開催するイベント会社等が第４のタイプに属する。

【0051】

制御サーバ１０は、利用者が選択したサービス提供者のタイプに応じた、利用者登録制御を実行する。第１の実施形態では、上記第１のタイプに関する「利用者登録」について説明する。

【0052】

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

【0053】

利用者が端末４０に一覧表示されたサービス提供者のなかから１つのサービス提供者を選択すると、制御サーバ１０は、必要に応じて、利用者登録の対象となるサービス提供者を指定する情報を取得する。例えば、制御サーバ１０は、ＧＵＩ等を用いて、利用者が勤務する企業や居住しているマンションの管理会社を指定する「管理コード」を利用者から取得する。即ち、利用者は、端末４０を操作して、管理コードを入力する。

【0054】

管理コードにより利用者登録の対象となるサービス提供者が特定されると、制御サーバ１０は、当該特定されたサービス提供者のタイプを判定する。第１の実施形態では、制御サーバ１０は、第１のタイプのサービス提供者が選択されたと判定する。

【0055】

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

【0056】

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

【0057】

制御サーバ１０は、利用者のシステムＩＤ、取得した原本生体情報、個人特定情報等を利用者が選択したサービス提供者（第１のタイプのサービス提供者）に通知する。なお、個人特定情報は、利用者を特定するための情報である。個人特定情報として、利用者の氏名、又は、氏名と生年月日の組み合わせが例示される。あるいは、社員番号やマンションの居室番号等が個人特定情報として用いられてもよい。

【0058】

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

【0059】

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

【0060】

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

【0061】

このように、利用者は、スマートフォン等の端末４０に格納された原本生体情報（生体情報のマスターデータ）を認証センターの制御サーバ１０を介してサービス提供者に提供する。その際、端末４０は、利用者の原本生体情報（マスターデータ）を内部に保持し続ける。

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

事業者管理部２０３は、認証システムに参加するサービス提供者（サービス事業者）を管理する手段である。事業者管理部２０３は、各サービス提供者の職員等からシステム登録する事業者情報（サービス提供者の名称、業種、所在地、管理コード、サービスサーバ２０のアドレス等）を取得する。事業者情報には、各サービス提供者のタイプ（上述の第１乃至第４のサービス提供者のタイプ）が含まれていてもよい。

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

ここで、利用者の勤務先となる企業やマンション管理会社は数多く存在し、これらの企業や管理会社を一覧表示するのは現実的ではない。そこで、サービス選択制御部２０４は、複数のサービス提供者を代表するようなアイコンを表示してもよい。図９の例では、複数の企業（勤務先）は「オフィス」として表示され、複数のマンション管理会社は「マンション」として表示されている。

【0086】

サービス選択制御部２０４は、複数のサービス提供者を代表するアイコンが選択された場合（図９の例では「オフィス」又は「マンション」のアイコンが押下された場合）、利用者登録の対象となるサービス提供者の管理コードを取得する。具体的には、サービス選択制御部２０４は、図１０に示すようなＧＵＩを用いて管理コードを取得する。なお、利用者は自社や自宅マンションの管理コードを勤務先又は管理会社等から取得する。

【0087】

サービス選択制御部２０４は、管理コードから利用者が選択したサービス提供者を特定する。このように、サービス選択制御部２０４は、必要に応じて、利用者がサービスの提供を受けたいサービス提供者に対応する管理コードを端末４０から取得することで当該利用者が選択（指定）したサービス提供者を特定する。

【0088】

なお、複数のサービス提供者を代表していないアイコン（サービス提供者を直接示すアイコン；図９の例では小売店Ａ～Ｃのアイコン）が押下された場合、サービス選択制御部２０４は、管理コードを用いずに利用者が選択したサービス提供者を特定できる。

【0089】

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

【0090】

また、サービス選択制御部２０４は、利用者により既に選択されているサービス提供者の解除（当該サービス提供者からサービスを受けることを終了）を可能とする。具体的には、利用者がポータルサイト上で所定の操作を行うと、サービス選択制御部２０４は、図９に示すようなＧＵＩを表示する。

【0091】

図９において既に利用者登録がされているサービス提供者（図９の例では右上にチェックが入っているサービス提供者）が選択されると、サービス選択制御部２０４は、当該選択されたサービス提供者の利用者登録を解除する制御を行う。なお、サービス選択制御部２０４は、必要に応じて、利用者登録を解除するサービス提供者の管理コードを取得する。

【0092】

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

【0093】

利用者登録制御部２０５は、制御サーバ１０による「利用者登録」を制御する手段である。例えば、利用者登録制御部２０５は、所定のコード（管理コード）を用いて利用者が選択したサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う。

【0094】

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

【0095】

利用者登録制御部２０５は、利用者登録が希望されたサービス提供者のタイプに応じた利用者登録制御を実行する。利用者登録制御部２０５は、選択されたサービス提供者のタイプを事業者情報から取得する。第１の実施形態では、第１のタイプのサービス提供者が選択された場合について説明する。即ち、利用者登録制御部２０５は、利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有さないサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための利用者登録制御を行う。

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

利用者登録の解除が希望された場合、利用者登録制御部２０５は、解除が希望されたサービス提供者のサービスサーバ２０に対して、利用者のシステムＩＤを含む「登録解除要求」を送信する。

【0103】

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

【0104】

具体的には、肯定応答（登録解除成功）を受信した場合、利用者登録制御部２０５は、その旨を利用者に通知する。例えば、利用者登録制御部２０５は、図９に示すアイコンのチェックを外すことで、利用者が選択したサービス提供者の利用者登録が解除されたことを通知する。あるいは、登録解除が成功した場合、利用者登録制御部２０５は、サービス提供者（サービスサーバ２０）から登録認証情報（例えば、特徴量）が削除された旨のメッセージ等を表示してもよい。即ち、端末４０は、登録解除によってサービスサーバ２０に登録された特徴量が削除されたことを利用者に報告してもよい。否定応答（登録解除失敗）を受信した場合、利用者登録制御部２０５は、その旨を利用者に通知する。

【0105】

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

【0106】

利用者登録に関し、上記説明した制御サーバ１０の動作を纏めると図１１に示すフローチャートのとおりとなる。

【0107】

制御サーバ１０は、利用者が希望する生体認証サービス（サービス提供者）を取得する（選択サービスを取得；ステップＳ１０１）。その際、制御サーバ１０は、必要に応じて、サービス提供者の管理コードを取得する。

【0108】

制御サーバ１０は、利用者が所持する端末４０に「原本提供要求」を送信することで、原本生体情報を取得する（ステップＳ１０２）。

【0109】

制御サーバ１０は、システムＩＤ、取得した原本生体情報（例えば、顔画像）と個人特定情報（例えば、氏名）を含む利用者登録要求をサービスサーバ２０に送信する（ステップＳ１０３）。

【0110】

制御サーバ１０は、サービスサーバ２０から利用者登録要求に対する応答を受信する（ステップＳ１０４）。

【0111】

制御サーバ１０は、利用者登録の成否を利用者に通知する（ステップＳ１０５）。

【0112】

このように、制御サーバ１０は、利用者が所持する端末４０に対し、原本生体情報の提供を要求することで当該原本生体情報を取得し、取得された原本生体情報を利用者により選択されたサービス提供者のサービスサーバ２０に送信する。その際、制御サーバ１０は、少なくとも自装置で利用者を管理するためのシステムＩＤと、取得された原本生体情報と、をサービスサーバ２０に送信する。

【0113】

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

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

さらに、利用者登録制御部３０３は、制御サーバ１０から受信した登録解除要求を処理する。

【0129】

登録解除要求を受信すると、利用者登録制御部３０３は、当該登録解除要求に含まれるシステムＩＤをキーとして利用者管理データベースを検索し、対応する利用者を特定する。利用者登録制御部３０３は、当該特定された利用者の少なくともシステムＩＤと登録認証情報（例えば、特徴量）を削除する。あるいは、利用者登録制御部３０３は、必要に応じて特定された利用者のエントリ（利用者管理データベースのエントリ）を削除する。

【0130】

システムＩＤ等の削除に成功すると、利用者登録制御部３０３は、利用者登録の解除が成功した旨を示す肯定応答を制御サーバ１０に送信する。制御サーバ１０から取得したシステムＩＤが利用者管理データベースに存在しない等の理由により利用者登録の解除に失敗した場合、利用者登録制御部３０３は、その旨を示す否定応答を制御サーバ１０に送信する。

【0131】

認証部３０４は、被認証者の生体認証を行う手段である。認証部３０４は、認証端末３０から認証要求を受信する。認証部３０４は、認証要求から生体情報（例えば、顔画像）を取り出す。

【0132】

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

【0133】

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

【0134】

類似度が所定の値以上の特徴量が存在しなければ、認証部３０４は、認証結果を「認証失敗」に設定する。

【0135】

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

【0136】

例えば、利用者の勤務先の認証部３０４は、照合処理により特定された利用者が自社の社員であってオフィスに入場する資格を備えていれば「認証成功」と判定する。あるいは、認証部３０４は、特定された利用者が自社の社員であっても当該社員が認証端末３０の設置場所に入場する資格がなければ「認証失敗」と判定する。

【0137】

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

【0138】

認証部３０４は、認証結果（認証成功、認証失敗）を認証端末３０に送信する。

【0139】

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

【0140】

なお、第１のタイプに属するサービス提供者は、原則として、利用者の認証に使用した業務情報を記憶し続ける。例えば、サービスサーバ２０は、社員が退職するまで、あるいは住民が引っ越しをするまで業務情報を記憶し続ける。換言すれば、サービスサーバ２０は、社員の退職等を契機として業務情報を削除してもよい。

【0141】

［認証端末］
図１４は、第１の実施形態に係る認証端末３０の処理構成（処理モジュール）の一例を示す図である。図１４を参照すると、認証端末３０は、通信制御部４０１と、生体情報取得部４０２と、認証要求部４０３と、機能実現部４０４と、記憶部４０５と、を備える。

【0142】

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

【0143】

生体情報取得部４０２は、カメラを制御し、被認証者の生体情報（例えば、顔画像）を取得する手段である。生体情報取得部４０２は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。生体情報取得部４０２は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。

【0144】

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

【0145】

生体情報取得部４０２は、抽出した顔画像を認証要求部４０３に引き渡す。

【0146】

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

【0147】

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

【0148】

機能実現部４０４は、認証端末３０に割り当てられた機能を実現する手段である。例えば、利用者の勤務先に設置された認証端末３０の機能実現部４０４は、認証成功を受信すると、ゲートを開き被認証者の入場を許可する。

【0149】

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

【0150】

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

【0151】

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

【0152】

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

【0153】

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

【0154】

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

【0155】

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

【0156】

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

【0157】

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

【0158】

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

【0159】

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

【0160】

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

【0161】

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

【0162】

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

【0163】

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

【0164】

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

【0165】

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

【0166】

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

【0167】

＜第１の実施形態に係る変形例＞
上記実施形態では、利用者が入力する管理コードは、複数のサービス提供者のなかから利用者が選択したサービス提供者を特定するために使用される場合について説明を行った。しかし、当該管理コードは、利用者が、サービス提供者を選択する資格を有するか否かの情報として用いられてもよい。具体的には、管理コードは、利用者がサービス提供者（勤務先、マンションの管理会社等）を登録する資格を有することの証明として使用されてもよい。

【0168】

例えば、制御サーバ１０は、利用者が勤務先やマンション管理会社等をサービス提供者として選択すると、認証センターと契約している勤務先等の一覧を端末４０に表示する。制御サーバ１０は、一覧表示のなかから利用者が勤務先やマンション管理会社等を選択すると、当該勤務先等の管理コードの入力を利用者に求める。

【0169】

制御サーバ１０は、利用者が選択したサービス提供者の管理コードと当該利用者が入力した管理コードが一致する場合、当該利用者はサービス提供者からサービスの提供を受ける資格を有すると判定する。一方、制御サーバ１０は、利用者が選択したサービス提供者の管理コードと当該利用者が入力した管理コードが不一致な場合、当該利用者はサービス提供者からサービスの提供を受ける資格を有さないと判定する。制御サーバ１０は、利用者がサービス提供者からサービスの提供を受ける資格を備えている場合、当該利用者に関する利用者登録（サービス提供者の選択）を受け入れる。このように、サービス選択制御部２０４は、利用者がサービスの提供を受けたいサービス提供者を選択すると、第１の管理コードの入力を前記利用者に要求する。サービス選択制御部２０４は、当該利用者が入力した第１の管理コードと、利用者により選択されたサービス提供者に対応する予め定められた第２の管理コードと、が一致した場合に、利用者によるサービス提供者の選択を受け入れる。

【0170】

例えば、利用者が勤務先Ａを選択し、当該利用者が勤務先Ａの正しい管理コードを入力すると、制御サーバ１０は、当該利用者は勤務先Ａに利用者登録をする資格を備えていると判定する。このように、制御サーバ１０は、管理コードをパスワードとして用いることもできる。管理コードをパスワードとして用いることで、制御サーバ１０は、サービス提供者とは無関係な利用者の利用者登録を防止できる。

【0171】

以上のように、第１の実施形態に係る制御サーバ１０は、第１のタイプに属するサービス提供者が生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う。第１のタイプに属するサービス提供者は、顧客を管理するためのアカウントを持たず、且つ、顧客にサービスを提供するための業務情報を繰り返し使用するサービス提供者である。このようなサービス提供者が利用者（顧客）の原本生体情報を取得可能とするため、制御サーバ１０は、利用者の原本生体情報と共に個人特定情報（例えば、氏名）をサービス提供者のサービスサーバ２０に送信する。サービスサーバ２０は、個人特定情報を用いて利用者を特定し、特定された利用者の登録認証情報と業務情報を対応付けて記憶する。当該対応付けが完了することで、サービス提供者は、利用者に対して生体認証を用いたサービスの提供が可能となる。

【0172】

また、第１の実施形態に係る認証システムでは、生体認証に必要な原本生体情報（例えば、顔画像）は利用者の端末４０に格納されている。利用者が、生体認証サービスの享受を希望すると、当該利用者がサービス提供者を選択した後に、端末４０に格納された原本生体情報は、上記選択されたサービス提供者（登録認証情報を必要とするサービス提供者）に提供される。利用者は、一度、自身の生体情報（例えば、顔画像）を端末４０に登録することで、各サービス（様々なサービス提供場所）それぞれに生体情報を登録することなく、各サービスを享受できる。即ち、利用者は、一度、自身の顔を撮影すれば、当該顔画像を用いて様々な場所（サービス）において再び顔登録を行わず、顔認証サービスを利用することができる。換言すれば、一度の生体情報の登録で、生体認証を用いた様々なソリューションに当該生体情報を適用可能である。

【0173】

また、上記構成により、サービス提供者が生体認証サービスを提供する際に生じる種々の問題が解決される。既存のシステムでは、サービス提供者は、サービス提供場所（サービス）ごとに利用者に顔画像の登録をして貰う必要があった。しかし、第１の実施形態に係るシステムでは、利用者が１回の顔登録を行えば十分であり、サービス提供者による顔登録誘導の負担が大幅に減少する。また、サービス提供者は、原本生体情報（顔画像）を保持する必要がなく、サービス提供者の情報漏洩等に対する負担が軽減する。とりわけ、同じサービス提供者が、複数の顔認証アルゴリズムを採用している場合、各顔認証アルゴリズムに対応した顔画像を所持する必要がなくなるので、当該サービス提供者の経営リスクが低減する。また、利用者の同意の下、認証センターが原本生体情報を記憶することで、サービス提供者は、自社で採用する顔認証エンジンを変更したり、提供サービスに適した顔認証エンジンを新たに採用したりすることができる。即ち、サービス提供者は、特定ベンダーの顔認証エンジンに限定されず、用途に適した様々なベンダーの顔認証エンジンを採用することができる。その結果、サービス提供者は、１社のベンダー（１つの顔認証エンジン）に過度に依存する事業リスクを回避できる。即ち、本願開示の認証システムに参加するサービス提供者は、容易に、マルチベンダー対応が可能である。

【0174】

また、利用者側の観点では、同じサービス（同じサービス提供者）にも関わらず、何度も顔画像を登録する必要がないので、利用者の利便性が向上する。また、原本生体情報（顔画像）は自身の端末４０に留め置かれ、外部の会社等に自身の顔画像が保持されることがないので、情報漏洩等に対する不安が低減する。即ち、利用者は、安心して生体認証サービスを享受できる。

【0175】

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

【0176】

第２の実施形態では、第２のタイプのサービス提供者に関する利用者登録について説明する。

【0177】

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

【0178】

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

【0179】

上述のように、第２のタイプに属するサービス提供者（例えば、遊園地等の運営会社、コンサート等のイベント会社）は、利用者に対してポータルサイトを提供しない。イベント会社は、利用者がチケット販売サイト等で購入したチケットの情報を業務情報として記憶し、当該業務情報を用いて利用者を認証する。

【0180】

利用者は、端末４０を操作してチケット販売サイトにアクセスし、当該チケット販売サイトにおいて目的とするチケットを購入する。具体的には、図１８に示すように、利用者は、端末４０を操作してチケット管理サーバ５０にアクセスし、チケットを購入する。端末４０は、購入チケットの情報を取得する。例えば、端末４０は、購入したチケットを一意に識別するためのＩＤ（チケットＩＤ）をチケット管理サーバ５０から取得する。

【0181】

なお、チケット管理サーバ５０の構成等に関する詳細な説明、チケットの購入やチケットＩＤ等の取得に関する詳細な説明は省略する。チケットの購入等は本願開示の趣旨とは異なると共に当業者にとって明らかなためである。

【0182】

利用者は、図９に示すようなＧＵＩにおいて、第２のタイプに属するサービス提供者を選択する。例えば、利用者は、遊園地、テーマパーク等を運営するイベント会社を選択する。即ち、利用者は、端末４０を操作して、制御サーバ１０にアクセスし、利用者登録の対象となるサービス提供者を選択する。なお、制御サーバ１０は、必要に応じてサービス提供者を指定する管理コードを利用者から取得する。

【0183】

制御サーバ１０は、選択されたサービス提供者の事業者ＩＤに基づいて当該選択されたサービス提供者のタイプを判定する。ここでは、第２のタイプに属するサービス提供者が選択される。第２のタイプに属するサービス提供者の事業者情報には、当該サービス提供者が必要とする業務情報に関する情報が記載されている。上記の例では、チケットの情報（チケットＩＤ）が必要なことが事業者情報に記載されている。

【0184】

第２のタイプのサービス提供者が選択されると、制御サーバ１０の利用者登録制御部２０５は、サービス提供者が必要とする業務情報を取得する。例えば、利用者登録制御部２０５は、図１９に示すようなＧＵＩを端末４０に表示することでチケットＩＤを取得する。

【0185】

チケットＩＤを取得すると、利用者登録制御部２０５は、第１の実施形態と同様に、原本提供要求を端末４０に送信することで、利用者の端末４０から原本生体情報を取得する（図１８のステップＳ２１、Ｓ２２）。

【0186】

原本生体情報を取得すると、利用者登録制御部２０５は、システムＩＤ、上記取得したチケットＩＤ（業務情報）と原本生体情報を含む利用者登録要求を利用者が選択したサービス提供者のサービスサーバ２０に送信する（ステップＳ２３）。

【0187】

サービスサーバ２０の利用者登録制御部３０３は、取得した生体情報から登録認証情報を生成する。また、利用者登録制御部３０３は、利用者管理データベースに新規なエントリを追加し、当該追加されたエントリにシステムＩＤ、登録認証情報及び業務情報（チケットＩＤ）を記憶する。

【0188】

サービスサーバ２０は、認証端末３０から受信する認証要求を処理する。具体的には、サービスサーバ２０の認証部３０４は、照合処理により特定された被認証者のチケットＩＤをチケット販売サイトのチケット管理サーバ５０に送信する（図２０参照）。

【0189】

チケット管理サーバ５０は、取得したチケットＩＤの有効性を判定する。具体的には、チケット管理サーバ５０は、チケットＩＤにより特定されるチケットのイベント開催場所、開催日時等に基づきチケットの有効性を判定する。チケット管理サーバ５０は、判定結果をサービスサーバ２０に送信する。認証部３０４は、チケットが有効であれば認証成功と判定する。認証部３０４は、チケットが無効であれば認証失敗と判定する。

【0190】

なお、第２のタイプに属するサービス提供者は、原則として、利用者の認証に使用した業務情報を削除する。第２のタイプに属するサービス提供者が用いる業務情報（サービス提供者が顧客にサービスを提供するために必要な業務情報；例えば、チケットＩＤ）は、生体認証の際に実質的に１度使用される情報だからである。例えば、チケット購入者がイベント会場に入場すると、当該チケット購入者を再び認証成功と判定することはないので、対応する業務情報は削除される。あるいは、イベント会場への再入場が許可されている場合には、サービスサーバ２０は、イベント終了後（イベント終了予定時刻から所定時間経過後）に、対応する業務情報を削除してもよい。

【0191】

また、上記説明では、遊園地、コンサート等のチケットを例にとり説明を行ったが、チケットの種類を限定する趣旨ではないことは勿論である。例えば、交通機関の搭乗券、乗車券等のチケットに関しても同様に処理される。さらに、本願開示が対象とするチケットには、一度の使用に限られるチケットだけではなく、複数回利用されるチケットも含まれる。例えば、周遊券（例えば、所定期間の間、交通手段が乗り放題となるチケット）、定期券等の有効期間が存在するチケットも本願開示の対象である。

【0192】

以上のように、第２の実施形態の制御サーバ１０は、システムＩＤ及び原本生体情報に加え、利用者により選択されたサービス提供者が当該利用者に生体認証を用いたサービスを提供するために必要な業務情報（チケットＩＤ等）をサービスサーバ２０に送信する。その結果、第２のタイプに属するサービス提供者は、利用者を認証するために必要な業務情報（例えば、チケットＩＤ）を取得できる。

【0193】

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

【0194】

第３の実施形態では、第３のタイプのサービス提供者に関する利用者登録について説明する。

【0195】

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

【0196】

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

【0197】

利用者は、図９に示すようなＧＵＩにおいて、第３のタイプに属するサービス提供者を選択する。例えば、利用者は、コンビニエンスストアのような小売店を選択する。

【0198】

なお、第３のタイプに属するサービス提供者を選択する利用者は、当該選択するサービス提供者のアカウントを既に所持している。例えば、コンビニエンスストアにて生体認証決済の利用を希望する利用者は、当該コンビニエンスストアの会員であって既にアカウントを有している。また、当該コンビニエンスストアのアカウントにて代金決済のための決済情報が業務情報として記憶されている。決済情報には、クレジットカードに関する情報や、交通系ＩＣ（Integrated Circuit）カードにチャージされた金額に関する情報、２次元バーコードを用いるコード決済のための情報等の任意の決済手段に関する情報が含まれる。

【0199】

制御サーバ１０は、コンビニエンスストアのような小売店等を対象として利用者登録に関する制御を実行することで、利用者による生体認証決済を利用可能とする。制御サーバ１０は、利用者が選択したサービス提供者のアカウントと認証システムのアカウントを連携する。

【0200】

利用者は、端末４０を操作して、制御サーバ１０にアクセスし、利用者登録（アカウント連携）の対象となるサービス提供者を選択する（図２１のステップＳ３１）。

【0201】

制御サーバ１０は、選択されたサービス提供者の事業者ＩＤに基づいて当該選択されたサービス提供者のタイプを判定する。ここでは、第３のタイプに属するサービス提供者が選択される。

【0202】

第３のタイプのサービス提供者が選択されると、制御サーバ１０の利用者登録制御部２０５は、選択されたサービス提供者のアカウントにログインするためのＵＲＬ（Uniform Resource Locator）を端末４０に送信する（ステップＳ３２）。

【0203】

当該端末４０に送信されるＵＲＬは、サービス提供者のログインページに端末４０を接続するためのリダイレクト用ＵＲＬであって、当該リダイレクト用ＵＲＬには利用者のシステムＩＤが埋め込まれている。なお、リダイレクト用ＵＲＬは予め業務情報として制御サーバ１０に提供されている。利用者登録制御部２０５は、業務情報として記憶されているリダイレクト用ＵＲＬにシステムＩＤ（制御サーバ１０が利用者を管理するためのＩＤ）を埋め込み、当該リダイレクト用ＵＲＬを端末４０に送信する。

【0204】

端末４０は、リダイレクト用ＵＲＬを受信すると、当該ＵＲＬに従ってサービス提供者のログインページにアクセスする。その際、リダイレクト用ＵＲＬにはシステムＩＤが含まれているので、サービスサーバ２０の利用者登録制御部３０３は、利用者のシステムＩＤを取得できる。

【0205】

利用者は、端末４０を操作して、サービス提供者のログインページにログイン情報（サービス提供者のアカウントにログインするためのログイン情報）を入力する（ステップＳ３３）。

【0206】

サービスサーバ２０の利用者登録制御部３０３は、取得したログイン情報（利用者のＩＤ）をキーとして利用者管理データベースを検索し、対応する利用者を特定する。利用者登録制御部３０３は、特定された利用者のエントリにリダイレクト用ＵＲＬから取得したシステムＩＤを記憶する。即ち、利用者登録制御部３０３は、自社（サービス提供者）で管理する利用者のＩＤと認証システムが利用者を管理するためのシステムＩＤを対応付けて記憶する。

【0207】

以降の説明において、各サービス提供者が利用者（顧客、会員等）を管理するために発行したＩＤを「個別ＩＤ」と表記する。利用者登録制御部３０３は、リダイレクト用ＵＲＬに従ってポータルサイトにログインした利用者の個別ＩＤとシステムＩＤを対応付けて記憶する（ＩＤを連携する）。

【0208】

個別ＩＤとシステムＩＤの対応付けが完了すると、利用者登録制御部３０３は、利用者のシステムＩＤを制御サーバ１０に通知してもよい。例えば、利用者登録制御部３０３は、システムＩＤを含む「利用者登録完了通知」を制御サーバ１０に送信してもよい（ステップＳ３４）。当該利用者登録完了通知を受信した制御サーバ１０の利用者登録制御部２０５は、利用者登録が完了した旨を利用者に通知してもよい。

【0209】

例えば、制御サーバ１０は、図９に示すような画面において、利用者登録が完了したサービス提供者のアイコンにチェックを付けることで利用者登録の完了を通知してもよい。

【0210】

個別ＩＤとシステムＩＤの対応付けが完了すると、サービスサーバ２０の利用者登録制御部３０３は、利用者のシステムＩＤを含む「生体情報提供要求」を制御サーバ１０に送信する（図２２のステップＳ３５）。

【0211】

生体情報提供要求を受信すると、制御サーバ１０の利用者登録制御部２０５は、当該生体情報提供要求に含まれるシステムＩＤをキーとしてアカウント管理データベースを検索し、対応する利用者を特定する。利用者登録制御部２０５は、特定された利用者の端末４０に対して「原本提供要求」を送信する（ステップＳ３６）。

【0212】

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

【0213】

原本生体情報を取得すると、利用者登録制御部２０５は、当該取得した原本生体情報（例えば、顔画像）をサービスサーバ２０に送信する。具体的には、端末４０から原本生体情報を取得した場合、利用者登録制御部２０５は、取得した原本生体情報を含む肯定応答をサービスサーバ２０に送信する（ステップＳ３８）。なお、端末４０から原本生体情報を取得できない場合、利用者登録制御部２０５は、生体情報提供要求に対する応答として否定応答をサービスサーバ２０に送信する。

【0214】

サービスサーバ２０の利用者登録制御部３０３は、取得した原本生体情報から登録認証情報を生成し、利用者管理データベースに記憶する。利用者登録制御部３０３は、システムＩＤ、個別ＩＤ（ログイン情報）、登録認証情報及び業務情報（例えば、クレジットカード情報）を対応付けて利用者管理データベースに記憶する。

【0215】

利用者が小売店において商品を購入すると、認証端末３０は、当該商品購入者の生体情報と決済情報（購入代金）を含む認証要求をサービスサーバ２０に送信する（図２３参照）。サービスサーバ２０は、取得した生体情報を用いた照合処理により被認証者（商品購入者）を特定する。

【0216】

サービスサーバ２０は、特定した被認証者のクレジットカード情報と決済情報を用いて決済処理を行う。具体的には、サービスサーバ２０は、クレジットカード情報と決済情報をクレジットカード会社の決済サーバ６０に送信することで、商品代金の決済を当該決済サーバ６０に依頼する。決済サーバ６０は、決済処理の結果をサービスサーバ２０に通知する。なお、決済サーバ６０の構成、動作は本願開示の趣旨とは異なると共に当業者にとって明らかであるので詳細な説明を省略する。

【0217】

決済成功が通知されると、サービスサーバ２０は、認証成功と判定する。決済失敗が通知されると、サービスサーバ２０は、認証失敗と判定する。サービスサーバ２０は、認証結果を認証端末３０に通知する。

【0218】

なお、第３のタイプに属するサービス提供者は、利用者を認証するために必要な業務情報（例えば、クレジットカード情報）を繰り返し使用する。従って、サービスサーバ２０は、利用者の認証に成功しても当該業務情報を削除せず記憶し続ける。

【0219】

［システム動作］
図２４は、第３の実施形態に係る認証システムの動作の一例を示すシーケンス図である。図２４を参照し、第３の実施形態に係る認証システムの動作を説明する。

【0220】

端末４０は、利用者の操作に応じてサービス提供者を選択する（ステップＳ４１）。

【0221】

制御サーバ１０は、第３のタイプに属するサービス提供者が選択されると、リダイレクト用ＵＲＬを端末４０に送信する（ステップＳ４２）。

【0222】

端末４０は、利用者の操作に応じて、リダイレクト用ＵＲＬにより示されるログインページにアクセスしポータルサイトにログインする（ステップＳ４３）。その際、サービスサーバ２０は、リダイレクト用ＵＲＬに埋め込まれたシステムＩＤを取得する。

【0223】

サービスサーバ２０は、ログイン情報（サービス提供者が利用者を管理する個別ＩＤ）を用いて利用者を特定し、当該特定された利用者に関する生体情報提供要求を制御サーバ１０に送信する（ステップＳ４４）。

【0224】

制御サーバ１０は、利用者の端末４０に対して原本提供要求を送信する（ステップＳ４５）。

【0225】

端末４０は、原本生体情報（例えば、顔画像）を制御サーバ１０に送信する（ステップＳ４６）。

【0226】

制御サーバ１０は、取得した原本生体情報をサービスサーバ２０に送信する（ステップＳ４７）。

【0227】

サービスサーバ２０は、取得した原本生体情報（例えば、顔画像）から登録認証情報（例えば、特徴量）を生成し、当該登録認証情報を利用者管理データベースに記憶する（ステップＳ４８）。

【0228】

＜第３の実施形態に係る変形例＞
第３の実施形態において、サービスサーバ２０は、アカウント連携（個別ＩＤとシステムＩＤの対応付け）が完了した後に「利用者登録完了通知」を制御サーバ１０に送信してもよいことを説明した。しかし、サービスサーバ２０は、利用者の登録認証情報を利用者管理データベースに登録した後に、上記利用者登録完了通知を制御サーバ１０に送信してもよい。

【0229】

以上のように、第３の実施形態に係る制御サーバ１０は、第３のタイプに属するサービス提供者が生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う。第３のタイプに属するサービス提供者は、利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者である。制御サーバ１０は、利用者の端末４０に対し、当該利用者により選択されたサービス提供者のアカウントにログインするための情報を送信する。制御サーバ１０は、利用者のアカウントを管理するサービスサーバ２０から生体情報提供要求を受信したことに応じて、端末４０に対し、生体認証に用いられる認証情報の原本となる原本生体情報の提供を要求することで原本生体情報を端末４０から取得する。制御サーバ１０は、取得された原本生体情報をサービスサーバ２０に送信する。

【0230】

第３のタイプに属するサービス提供者は、利用者を管理するためのアカウント（ポータルサイト）を有し、当該利用者を管理するために個別ＩＤを用いている。利用者登録（アカウント連携、ＩＤ連携）の際、利用者が、システムＩＤが埋め込まれたリダイレクト用ＵＲＬに従いポータルサイトにログインすることで、サービスサーバ２０は、利用者のシステムＩＤと個別ＩＤを同じタイミングで取得することができる。換言すれば、サービスサーバ２０は、第１の実施形態とは異なり、個人特定情報を用いずに個別ＩＤを用いて利用者を特定できるので、より確実な利用者登録を実現できる。即ち、個人特定情報（例えば、氏名）は重複する可能性が排除できないが、個別ＩＤはサービスサーバ２０が各利用者に発行するＩＤであるため重複の可能性はない（重複の可能性は極めて低い）。サービスサーバ２０は、個別ＩＤを利用して利用者を特定することで、確実なアカウント連携（ＩＤ連携）を実現できる。このように、第３の実施形態に係る情報処理システムでは、制御サーバ１０を経由してサービスサーバ２０に送信される情報は原本生体情報に限られ、個人特定情報は制御サーバ１０を経由してサービスサーバ２０に送信されない。第３の実施形態では、個人を特定するための情報（個人特定情報）は、リダイレクト用ＵＲＬを取得した端末４０からサービスサーバ２０に送信される。このように、個人情報特定情報が制御サーバ１０からサービスサーバ２０に送信されないので、システムのセキュリティ強度が向上する。

【0231】

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

【0232】

第４の実施形態では、第４のタイプのサービス提供者に関する利用者登録について説明する。

【0233】

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

【0234】

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

【0235】

第４の実施形態に係るシステムの基本的な動作は、第３の実施形態に係るシステムの動作と同一とすることができる。具体的には、第４のタイプに属するサービス提供者が選択されると、認証システムに含まれる各装置は、図２１に示される動作を行う。

【0236】

サービス提供者のＩＤと認証システムのシステムＩＤの連携が完了すると、利用者は、サービスの提供を受けるために必要な業務情報をサービス提供者に提供する（図２５のステップＳ５１）。例えば、利用者は、ログインしたサービス提供者のポータルサイト等において映画、コンサート、遊園地、航空券、乗車券等のチケットを購入する。

【0237】

なお、業務情報の提供（チケットの購入）は、利用者登録の際にサービス提供者のポータルサイトにログインした手続きのなかで行われてもよい。あるいは、利用者登録の完了後、利用者は当該ポータルサイトからログアウトしてもよい。利用者は、後日、改めてチケット購入のためにポータルサイトにログインしてもよい。この場合、利用者は、端末４０を操作して、直接、ポータルサイトにアクセス（ログイン）すればよい。

【0238】

サービスサーバ２０は、利用者が購入したチケットの情報を記憶する。サービスサーバ２０の業務情報管理部３０２は、利用者が提供した業務情報（チケット情報）を利用者管理データベースに記憶する。

【0239】

サービスサーバ２０の利用者登録制御部３０３は、定期的又は所定のタイミングで利用者管理データベースにアクセスし、各利用者の業務情報（チケット情報）を参照する。利用者登録制御部３０３は、参照した業務情報（チケット情報）が有効になる所定時間前（参照した業務情報が認証処理に使われる所定時間前）になると、制御サーバ１０に対して生体情報の提供を要求する。

【0240】

具体的には、利用者登録制御部３０３は、利用者（所定時間後にチケットを使う可能性のある利用者）のシステムＩＤを含む「生体情報提供要求」を制御サーバ１０に送信する（ステップＳ５２）。

【0241】

生体情報提供要求を受信した制御サーバ１０は、原本提供要求を端末４０に送信することで、原本生体情報（例えば、顔画像）を取得する（ステップＳ５３、Ｓ５４）。制御サーバ１０は、取得した原本生体情報をサービスサーバ２０に送信する（ステップＳ５５）。

【0242】

なお、第４の実施形態では、利用者がサービス提供者を選択したタイミングと原本生体情報（顔画像）がサービス提供者に提供されるタイミングは異なることも多い。そのため、端末４０は、原本生体情報を制御サーバ１０に送信した事実を、ポップアップ通知等を用いて利用者に通知してもよい（図２６参照）。

【0243】

第４の実施形態に係るサービスサーバ２０の認証部３０４は、イベント会場等に設置された認証端末３０から認証要求を受信すると、照合処理により特定された利用者のチケットが有効か否かに応じて認証結果を決定する。認証端末３０は、認証成功と判定された利用者（有効なチケットを所持する利用者）のゲート通過を許可する。認証端末３０は、認証失敗と判定された利用者（有効なチケットを所持していない利用者）のゲート通過を拒否する。

【0244】

なお、第４のタイプに属するサービス提供者は、第２の実施形態と同様に、原則として、利用者の認証に使用した業務情報を削除する。ただし、第４の実施形態に係るサービスサーバ２０は、利用者のアカウント（システムＩＤ、個別ＩＤ、登録認証情報）を削除せずに残す。利用者のアカウントを残すことで、利用者が、同じサービス提供者から別のコンサート等のチケットを購入した場合であっても、当該サービス提供者に関する利用者登録（ＩＤ連携、アカウント連携）は不要となる。

【0245】

以上のように、第４の実施形態に係る制御サーバ１０は、第４のタイプに属するサービス提供者が生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う。第４のタイプに属するサービス提供者は、利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、顧客にサービスを提供するために必要な業務情報を生体認証の際に実質的に１度使用するサービス提供者である。制御サーバ１０は、利用者の端末４０に対し、当該利用者により選択されたサービス提供者のアカウントにログインするための情報を送信する。制御サーバ１０は、利用者のアカウントを管理するサービスサーバ２０から生体情報提供要求を受信したことに応じて、端末４０に対し、生体認証に用いられる認証情報の原本となる原本生体情報の提供を要求することで、原本生体情報を端末４０から取得する。制御サーバ１０は、取得された原本生体情報をサービスサーバ２０に送信する。その結果、第４のタイプに属するサービス提供者に関しても確実な利用者登録（アカウント連携、ＩＤ連携）が実現される。即ち、第４の実施形態においても第３の実施形態と同様に、制御サーバ１０を経由してサービスサーバ２０に送信される情報は原本生体情報に限られ、個人特定情報は制御サーバ１０を経由してサービスサーバ２０に送信されない。第４の実施形態では、個人を特定するための情報（個人特定情報）は、リダイレクト用ＵＲＬを取得した端末４０からサービスサーバ２０に送信される。このように、個人情報特定情報が制御サーバ１０からサービスサーバ２０に送信されないので、システムのセキュリティ強度が向上する。

【0246】

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

【0247】

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

【0248】

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

【0249】

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

【0250】

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

【0251】

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

【0252】

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

【0253】

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

【0254】

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

【0255】

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

【0256】

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

【0257】

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

【0258】

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

【0259】

上記実施形態では、サービスサーバ２０が、自社で採用する認証エンジンに対応する認証情報（特徴量）を生成する場合について説明した。しかし、当該認証情報（特徴量）の生成は、制御サーバ１０において行われてもよい。具体的には、制御サーバ１０は、事業者情報の一部としてサービス提供者が採用している認証エンジンの情報を記憶する。制御サーバ１０は、端末４０から取得した原本生体情報から上記認証エンジンに適合する登録認証情報（特徴量）を生成し、当該生成された登録認証情報を含む利用者登録要求を制御サーバ１０に送信してもよい。

【0260】

あるいは、サービスサーバ２０や制御サーバ１０は、図２９や図３０に示される、特徴量の生成に特化したサーバ（特徴量生成サーバ７０）に原本生体情報を送信し、当該サーバから登録認証情報を取得してもよい。制御サーバ１０やサービスサーバ２０が特徴量生成サーバ７０に原本生体情報（例えば、顔画像）を送信する場合、サービス提供者が採用する認証エンジンの情報を併せて特徴量生成サーバ７０に送信してもよい。特徴量生成サーバ７０は、制御サーバ１０やサービスサーバ２０から指定された認証エンジン（認証アルゴリズム）に適合した登録認証情報（例えば、特徴量）を生成し、制御サーバ１０やサービスサーバ２０に返信してもよい。このように、登録認証情報（特徴量）は、クラウド側（制御サーバ１０側）、エッジ側（サービスサーバ２０側）のいずれかで生成されればよい。なお、特徴量生成サーバ７０の構成、動作は上記説明により明らかであるので詳細な説明を省略する。

【0261】

上記実施形態では、制御サーバ１０は、利用者の勤務先等の管理コードを用いて利用者登録の対象となるサービス提供者を特定する場合について説明した。しかし、制御サーバ１０は、他の方法を用いて利用者登録の対象となるサービス提供者を特定してもよい。例えば、制御サーバ１０は、社名等を用いた検索結果から利用者登録の対象となるサービス提供者を選択するようなインターフェイスを用意してもよいし、５０音順で並ぶサービス提供者の一覧を端末４０に表示してもよい。

【0262】

第１の実施形態において、オフィスへの来客者（ゲスト）の情報を利用者（社員）がシステムに登録してもよい。この場合、社員は、端末４０を操作して制御サーバ１０にアクセスし、ゲストの登録手続きを行う。制御サーバ１０は、ゲストの氏名、所属、連絡先等を当該社員から取得する。制御サーバ１０は、取得した連絡先（ゲストの端末）に顔画像登録要求を送信する。例えば、制御サーバ１０は、ＵＲＬを含む顔画像登録要求を送信する。ゲストがＵＲＬをクリックすると、当該ゲストの端末は、制御サーバ１０にアクセスする。制御サーバ１０は、ゲストの顔画像を取得し、オフィスのサービスサーバ２０に送信する。

【0263】

さらに、オフィスのサービスサーバ２０は、ゲストの行動を生体認証により制御してもよい。例えば、サービスサーバ２０は、ゲストが会議室に入室する際、生体認証によりその可否を判定してもよい。あるいは、サービスサーバ２０は、ゲストのドリンク等の利用を生体認証により制御してもよい。例えば、サービスサーバ２０は、オフィスの内の自販機において、１回に限り当該ゲストにフリードリンクを提供するような制御を行ってもよい。

【0264】

選択した第３、第４のタイプに属するサービス提供者においてアカウントを有していない場合、利用者は、リダイレクト用ＵＲＬにより遷移するログインページにてアカウントを生成してもよい。換言すれば、サービスサーバ２０は、ログインページにおいて新規顧客のためのアカウント生成案内等を表示してもよい。

【0265】

制御サーバ１０は、アカウント生成の際、利用者の身元を確認してもよい。具体的には、制御サーバ１０は、利用者のログイン情報等と共に、生体情報が記載された身元確認書類（例えば、パスポート、運転免許証等）及び生体情報を取得する。制御サーバ１０は、身元確認書類の生体情報と利用者から取得した生体情報を用いた１対１照合を実行する。制御サーバ１０は、当該照合に成功した場合に、当該本人確認に成功した利用者の利用者登録（システム登録）を行ってもよい。

【0266】

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

【0267】

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

【0268】

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

【0269】

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

【0270】

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

【0271】

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、
前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う、利用者登録制御手段と、
を備える、サーバ装置。
［付記２］
前記利用者登録制御手段は、
前記利用者の端末に対し、前記利用者により選択されたサービス提供者のアカウントにログインするための情報を送信し、
前記利用者のアカウントを管理するサーバから生体情報提供要求を受信したことに応じて、前記端末に対し、生体認証に用いられる認証情報の原本となる原本生体情報の提供を要求することで前記原本生体情報を前記端末から取得し、
前記取得された原本生体情報を前記サーバに送信する、付記１に記載のサーバ装置。
［付記３］
前記利用者登録制御手段は、自装置で前記利用者を管理するためのシステムＩＤが埋め込まれたリダイレクト用ＵＲＬ（Uniform Resource Locator）を前記利用者がアカウントにログインするための情報として前記端末に送信する、付記２に記載の装置。
［付記４］
前記業務情報は、決済に関する情報である、付記３に記載のサーバ装置。
［付記５］
前記決済に関する情報には、クレジットカードに関する情報、交通系ＩＣ（Integrated Circuit）カードにチャージされた金額に関する情報及び２次元バーコードを用いるコード決済のための情報の少なくとも１つが含まれる、付記４に記載のサーバ装置。
［付記６］
前記原本生体情報は、顔画像である付記１乃至４のいずれか一項に記載のサーバ装置。
［付記７］
利用者が所持する端末と、
サーバ装置と、
を含み、
前記サーバ装置は、
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする、サービス選択制御手段と、
前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う、利用者登録制御手段と、
を備え、
前記利用者登録制御手段は、
前記利用者の端末に対し、前記利用者により選択されたサービス提供者のアカウントにログインするための情報を送信し、
前記利用者のアカウントを管理するサーバから生体情報提供要求を受信したことに応じて、前記端末に対し、生体認証に用いられる認証情報の原本となる原本生体情報の提供を要求することで前記原本生体情報を前記端末から取得し、
前記取得された原本生体情報を前記サーバに送信する、システム。
［付記８］
サーバ装置において、
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とし、
前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う、サーバ装置の制御方法。
［付記９］
サーバ装置に搭載されたコンピュータに、
生体認証を用いたサービスを提供する複数のサービス提供者のなかから、利用者がサービスの提供を受けたいサービス提供者を選択することを可能とする処理と、
前記利用者により選択されたサービス提供者であって、顧客を管理するためのアカウントを有し、且つ、前記顧客にサービスを提供するために必要な業務情報を生体認証の際に繰り返し使用するサービス提供者が、生体認証に用いる認証情報の原本となる原本生体情報を取得するための制御を行う処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。

【0272】

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

【符号の説明】

【0273】

１０ 制御サーバ
２０ サービスサーバ
３０ 認証端末
４０ 端末
５０ チケット管理サーバ
６０ 決済サーバ
７０ 特徴量生成サーバ
１００ サーバ装置
１０１ サービス選択制御手段
１０２ 利用者登録制御手段
２０１ 通信制御部
２０２ アカウント管理部
２０３ 事業者管理部
２０４ サービス選択制御部
２０５ 利用者登録制御部
２０６ 記憶部
３０１ 通信制御部
３０２ 業務情報管理部
３０３ 利用者登録制御部
３０４ 認証部
３０５ 記憶部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０１ 通信制御部
４０２ 生体情報取得部
４０３ 認証要求部
４０４ 機能実現部
４０５ 記憶部
５０１ 通信制御部
５０２ アカウント生成制御部
５０３ 原本情報取得部
５０４ サービス選択部
５０５ 記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】