特許 7525049 システム及び方法

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

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

(11)【特許番号】

(24)【登録日】2024-07-22

(45)【発行日】2024-07-30

(54)【発明の名称】システム及び方法

(51)【国際特許分類】

   G06Q 30/06 20230101AFI20240723BHJP

   G06Q 20/40 20120101ALI20240723BHJP

   G06F 21/32 20130101ALI20240723BHJP

【ＦＩ】

G06Q30/06

G06Q20/40

G06F21/32

【請求項の数】 10

(21)【出願番号】P 2023505033

(86)(22)【出願日】2021-03-12

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

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

(87)【国際公開日】2022-09-15

【審査請求日】2023-08-23

(73)【特許権者】

【識別番号】000004237

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

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100149618

【弁理士】

【氏名又は名称】北嶋 啓至

(72)【発明者】

【氏名】藤田 直毅

(72)【発明者】

【氏名】奥山 嘉昭

【審査官】鈴木 和樹

(56)【参考文献】

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

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

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

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

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

Ｇ０６Ｆ ２１／３２

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

【請求項1】

第１のサービス提供者に設置された、第１の端末及び第２の端末と、
前記第１及び第２の端末と接続された第１の管理サーバと、
利用者の生体情報と、前記利用者と前記第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する、認証サーバと、
を含み、
前記第１の管理サーバは、サービス利用予定者のサービス提供情報と前記サービスユーザＩＤを対応付けて記憶し、
前記第１の端末は、第１の利用者の生体情報を含むサービス利用開始手続き要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第１の利用者の生体情報を含む第１の認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第１の認証要求に応じて生体認証を実行し、認証に成功した場合、前記第１の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記第１の管理サーバは、前記通知されたサービスユーザＩＤに対応する前記サービス提供情報に基づいて前記第１の利用者のサービス利用開始手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶し、
前記第２の端末は、第２の利用者が商品又はサービスを購入する際、前記第２の利用者の生体情報を含む判定要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第２の利用者の生体情報を含む第２の認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第２の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第２の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記第１の管理サーバは、前記通知されたサービスユーザＩＤを用いて前記第２の利用者がサービス利用開始手続きを完了しているか否か判定し、前記第２の利用者がサービス利用開始手続きを完了している場合に、前記第２の利用者による前記商品又はサービスの購入を許可することを示す肯定応答を前記第２の端末に送信する、システム。

【請求項2】

前記第１の端末は、第３の利用者の生体情報を含むサービス利用終了手続き要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第３の利用者の生体情報を含む第３の認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第３の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第３の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記第１の管理サーバは、前記通知されたサービスユーザＩＤを用いて、前記第３の利用者のサービス利用終了手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用終了手続きの結果を前記データベースに反映する、請求項１に記載のシステム。

【請求項3】

決済代行サーバをさらに含み、
前記第２の端末は、前記第２の利用者の決済情報を含む決済要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第２の利用者の前記決済情報を含む決済代行要求を前記決済代行サーバに送信し、
前記決済代行サーバは、
口座開設を希望する利用者から口座情報を取得し、前記利用者を識別するための顧客ＩＤを生成し、前記顧客ＩＤと前記口座情報を紐づけるための紐づけ情報を生成する、口座情報管理部と、
外部装置から取得した前記紐づけ情報に基づき前記顧客ＩＤを特定し、前記特定された顧客ＩＤに基づき前記口座情報を特定すると共に、前記特定された口座情報と前記決済代行要求に含まれる決済情報を用いて決済処理を行う、決済処理部と、
を備える、請求項２に記載のシステム。

【請求項4】

前記決済代行サーバは、
前記顧客ＩＤを前記口座情報に変換するための第１の変換テーブルと、
前記紐づけ情報を前記顧客ＩＤに変換するための第２の変換テーブルと、をさらに備え、
前記決済処理部は、
前記第２の変換テーブルを参照し、前記紐づけ情報から前記顧客ＩＤを取得し、
前記第１の変換テーブルを参照し、前記取得された顧客ＩＤから前記口座情報を取得する、請求項３に記載のシステム。

【請求項5】

前記第１の管理サーバは、前記第３の利用者のサービス利用料金を計算し、前記サービス利用終了手続きの結果と共に前記計算されたサービス利用料金を前記第１の端末に通知し、
前記第１の端末は、前記第３の利用者の前記サービス利用料金を前記決済情報とする前記決済要求を前記第１の管理サーバに送信する、請求項３又は４に記載のシステム。

【請求項6】

前記第１の管理サーバは、前記サービス利用終了手続きに成功した前記第３の利用者のエントリを前記データベースから削除する、請求項２乃至５のいずれか一項に記載のシステム。

【請求項7】

前記第１の管理サーバは、前記第２の端末から取得した前記決済情報を前記第１の端末から決済要求を受信するまで蓄積し、前記第１の端末から前記決済要求を受信すると、前記蓄積した決済情報と前記第１の端末から取得した前記決済情報を含む前記決済代行要求を前記決済代行サーバに送信する、請求項５に記載のシステム。

【請求項8】

前記口座情報管理部は、前記生成された紐づけ情報を前記認証サーバに送信し、
前記認証サーバは、
前記利用者の生体情報と、前記サービスユーザＩＤと、前記紐づけ情報と、を対応付けて記憶する、請求項３に記載のシステム。

【請求項9】

前記認証サーバは、前記生体認証により前記サービスユーザＩＤを特定し、前記特定したサービスユーザＩＤを前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記決済要求を受信すると、前記サービスユーザＩＤを含む紐づけ情報送信要求を前記認証サーバに送信し、
前記認証サーバは、前記紐づけ情報送信要求に含まれるサービスユーザＩＤに対応する紐づけ情報を含む紐づけ情報通知と前記サービスユーザＩＤを前記決済代行サーバに送信し、
前記第１の管理サーバは、前記サービスユーザＩＤと前記決済情報を含む前記決済代行要求を前記決済代行サーバに送信し、
前記決済代行サーバは、前記サービスユーザＩＤが共通する前記紐づけ情報通知と前記決済代行要求を受信すると、前記決済処理を実行する、請求項８に記載のシステム。

【請求項10】

第１のサービス提供者に設置された、第１の端末及び第２の端末と、
前記第１及び第２の端末と接続された第１の管理サーバと、
利用者の生体情報と、前記利用者と前記第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する、認証サーバと、
を含むシステムにおいて、
サービス利用予定者のサービス提供情報と前記サービスユーザＩＤを対応付けて記憶し、
第１の利用者の生体情報を含むサービス利用開始手続き要求を前記第１の管理サーバに送信し、
前記第１の利用者の生体情報を含む第１の認証要求を前記認証サーバに送信し、
前記第１の認証要求に応じて生体認証を実行し、認証に成功した場合、前記第１の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記通知されたサービスユーザＩＤに対応する前記サービス提供情報に基づいて前記第１の利用者のサービス利用開始手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶し、
第２の利用者が商品又はサービスを購入する際、前記第２の利用者の生体情報を含む判定要求を前記第１の管理サーバに送信し、
前記第２の利用者の生体情報を含む第２の認証要求を前記認証サーバに送信し、
前記第２の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第２の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記通知されたサービスユーザＩＤを用いて前記第２の利用者がサービス利用開始手続きを完了しているか否か判定し、前記第２の利用者がサービス利用開始手続きを完了している場合に、前記第２の利用者による前記商品又はサービスの購入を許可することを示す肯定応答を前記第２の端末に送信する、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、システム及び方法に関する。

【背景技術】

【0002】

近年、生体情報を利用した各種サービスの普及が始まっている。

【0003】

例えば、特許文献１には、施設内における利用者の行為によって発生するイベントごとに顔認証を実行する場合に、そのイベントに関する情報を有効活用することができる顔認証管理サーバおよび顔認証管理方法を提供する、と記載されている。特許文献１の顔管理サーバは、利用者管理部と、機器管理部と、画面生成部と、を備える。利用者管理部は、利用者の顔画像を登録する登録装置により取得された利用者ごとの登録用の顔画像およびその顔画像以外の情報であって各利用者の特定に用いられる特定情報を関連づけて管理する。機器管理部は、利用者の認証用の顔画像を取得する顔認証機に関する情報を管理する。画面生成部は、利用者管理部および機器管理部による情報の管理状態を確認または変更するための管理用画面を生成する。

【先行技術文献】

【特許文献】

【0004】

【文献】国際公開第２０２０／１７９３３４号

【発明の概要】

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

【0005】

複数の事業者が共同し、同じ施設等で活動することがある。例えば、ホテルとその系列のテナント店舗や、自治体等のイベント開催者とその参加店舗等が上記同じ施設等で活動する事業者（主体）として例示される。このように、親子関係（親事業者とその管理下の事業者）が存在する状況において、管理下の事業者（子事業者）が親事業者との契約に基づくサービスを提供する場合、子事業者のサービスに関するアクセス管理は適切に行われる必要がある。

【0006】

上記ホテルの例では、ホテルの宿泊サービスに付随するサービスとして、宿泊者は、テナント店舗のサービスが受けられるのが通例である。上述のように、生体に認証を用いたサービスの普及が始まっているが、生体認証、とりわけ、生体認証を用いた決済サービスのより一層の普及が求められる。より具体的には、親事業者（例えば、ホテルを運営する事業者）だけでなく子事業者（例えば、ホテルで営業するテナント店舗）がより簡単に生体認証（生体認証を用いた決済サービス）を利用できる必要がある。

【0007】

一方で、子事業者の無制限な営業は親事業者にも影響し、親事業者が子事業者の活動を制限する必要もある。例えば、宿泊事業者（親事業者）は、ホテル内の治安（セキュリティ）を確保する目的で、ホテル内で営業するテナント店舗の利用は宿泊者に限るといったポリシを設定することもある。

【0008】

本発明は、サービス事業者の設定したポリシを実現することに寄与する、システム及び方法を提供することを主たる目的とする。

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

【0009】

本発明の第１の視点によれば、第１のサービス提供者に設置された、第１の端末及び第２の端末と、前記第１及び第２の端末と接続された第１の管理サーバと、利用者の生体情報と、前記利用者と前記第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する、認証サーバと、を含み、前記第１の管理サーバは、サービス利用予定者のサービス提供情報と前記サービスユーザＩＤを対応付けて記憶し、前記第１の端末は、第１の利用者の生体情報を含むサービス利用開始手続き要求を前記第１の管理サーバに送信し、前記第１の管理サーバは、前記第１の利用者の生体情報を含む第１の認証要求を前記認証サーバに送信し、前記認証サーバは、前記第１の認証要求に応じて生体認証を実行し、認証に成功した場合、前記第１の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、前記第１の管理サーバは、前記通知されたサービスユーザＩＤに対応する前記サービス提供情報に基づいて前記第１の利用者のサービス利用開始手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶し、前記第２の端末は、第２の利用者が商品又はサービスを購入する際、前記第２の利用者の生体情報を含む判定要求を前記第１の管理サーバに送信し、前記第１の管理サーバは、前記第２の利用者の生体情報を含む第２の認証要求を前記認証サーバに送信し、前記認証サーバは、前記第２の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第２の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、前記第１の管理サーバは、前記通知されたサービスユーザＩＤを用いて前記第２の利用者がサービス利用開始手続きを完了しているか否か判定し、前記第２の利用者がサービス利用開始手続きを完了している場合に、前記第２の利用者による前記商品又はサービスの購入を許可することを示す肯定応答を前記第２の端末に送信する、システムが提供される。

【0010】

本発明の第２の視点によれば、第１のサービス提供者に設置された、第１の端末及び第２の端末と、前記第１及び第２の端末と接続された第１の管理サーバと、利用者の生体情報と、前記利用者と前記第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する、認証サーバと、を含むシステムにおいて、サービス利用予定者のサービス提供情報と前記サービスユーザＩＤを対応付けて記憶し、第１の利用者の生体情報を含むサービス利用開始手続き要求を前記第１の管理サーバに送信し、前記第１の利用者の生体情報を含む第１の認証要求を前記認証サーバに送信し、前記第１の認証要求に応じて生体認証を実行し、認証に成功した場合、前記第１の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、前記通知されたサービスユーザＩＤに対応する前記サービス提供情報に基づいて前記第１の利用者のサービス利用開始手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶し、第２の利用者が商品又はサービスを購入する際、前記第２の利用者の生体情報を含む判定要求を前記第１の管理サーバに送信し、前記第２の利用者の生体情報を含む第２の認証要求を前記認証サーバに送信し、前記第２の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第２の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、前記通知されたサービスユーザＩＤを用いて前記第２の利用者がサービス利用開始手続きを完了しているか否か判定し、前記第２の利用者がサービス利用開始手続きを完了している場合に、前記第２の利用者による前記商品又はサービスの購入を許可することを示す肯定応答を前記第２の端末に送信する、方法が提供される。

【発明の効果】

【0011】

本発明の各視点によれば、サービス事業者の設定したポリシを実現することに寄与する、システム及び方法を提供することに寄与する、システム及び決済代行方法が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

【図面の簡単な説明】

【0012】

【図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】第１の実施形態に係る顧客ＩＤ変換テーブルの一例を示す図である。

【図31】第１の実施形態に係る紐づけ情報変換テーブルの一例を示す図である。

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

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

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

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

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

【図37】第１の実施形態に係る変形例１の紐づけ情報変換テーブルの一例を示す図である。

【図38】第１の実施形態に係る変形例１の認証情報データベースの一例を示す図である。

【図39】第１の実施形態に係る変形例２の仮決済データベースの一例を示す図である。

【図40】第１の実施形態に係る変形例３の認証システムを説明するための図である。

【図41】第２の実施形態に係る管理サーバの動作を説明するための図である。

【図42】第２の実施形態に係る利用者情報データベースの一例を示す図である。

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

【図44】第３の実施形態に係る認証サーバが保持するテーブル情報の一例を示す図である。

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

【図46】第３の実施形態に係るチェックインデータベースの一例を示す図である。

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

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

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

【図50】本願開示に係る決済代行サーバのハードウェア構成の一例を示す図である。

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

【0013】

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

【0014】

一実施形態に係るシステムは、第１の端末１０１と、第２の端末１０２と、第１の管理サーバ１０３と、認証サーバ１０４と、を含む（図１参照）。第１の端末１０１及び第２の端末１０２は、第１のサービス提供者に設置された端末である。第１の管理サーバ１０３は、第１の端末１０１及び第２の端末１０２と接続されたサーバである。認証サーバ１０４は、利用者の生体情報と、利用者と第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する。第１の管理サーバ１０３は、サービス利用予定者のサービス提供情報とサービスユーザＩＤを対応付けて記憶する。第１の端末１０１は、第１の利用者の生体情報を含むサービス利用開始手続き要求を第１の管理サーバ１０３に送信する。第１の管理サーバ１０３は、第１の利用者の生体情報を含む第１の認証要求を認証サーバ１０４に送信する。認証サーバ１０４は、第１の認証要求に応じて生体認証を実行し、認証に成功した場合、第１の利用者に対応するサービスユーザＩＤを第１の管理サーバ１０３に通知する。第１の管理サーバ１０３は、通知されたサービスユーザＩＤに対応するサービス提供情報に基づいて第１の利用者のサービス利用開始手続き可否を判定し、判定結果を第１の端末１０１に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶する。第２の端末１０２は、第２の利用者が商品又はサービスを購入する際、第２の利用者の生体情報を含む判定要求を第１の管理サーバ１０３に送信する。第１の管理サーバ１０３は、第２の利用者の生体情報を含む第２の認証要求を認証サーバ１０４に送信する。認証サーバ１０４は、第２の認証要求に応じて生体認証を実行し、認証に成功した場合、第２の利用者に対応するサービスユーザＩＤを第１の管理サーバ１０３に通知する。第１の管理サーバ１０３は、通知されたサービスユーザＩＤを用いて第２の利用者がサービス利用開始手続きを完了しているか否か判定する。第１の管理サーバ１０３は、第２の利用者がサービス利用開始手続きを完了している場合に、第２の利用者による商品又はサービスの購入を許可することを示す肯定応答を第２の端末１０２に送信する。

【0015】

上記システムでは、第１の管理サーバ１０３は、利用者が第１の端末１０１を用いてサービス利用開始手続き（チェックイン手続き）が完了したことを管理、記憶する。第１の管理サーバ１０３は、利用者が第２の端末を用いて商品等を購入する場合、当該利用者がサービス利用開始手続き（チェックイン）の完了した宿泊者の場合に、商品等の購入を許可する。このようにして、上記システムでは、事業者（ホテル）の設定したポリシ（運営方針；宿泊者に限り商品等を購入できる）を実現できる。

【0016】

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

【0017】

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

【0018】

［システムの構成］
図２は、第１の実施形態に係る認証システムの概略構成の一例を示す図である。図２に示すように、認証システムには、認証センター、決済事業者及び複数のサービス提供者が含まれる。

【0019】

認証システムに参加する各サービス提供者は、生体認証を用いて利用者に各種のサービス提供を行う。サービス提供者により提供されるサービスとして、宿泊サービスの提供が例示される。

【0020】

認証センターには、認証サーバ１０が設置されている。認証サーバ１０は、生体情報を用いた生体認証の認証局として動作する。認証サーバ１０は、認証センターの敷地に設置されたサーバであってもよいし、クラウド上に設置されたサーバであってもよい。

【0021】

利用者の生体情報には、例えば、顔、指紋、声紋、静脈、網膜、瞳の虹彩の模様（パターン）といった個人に固有の身体的特徴から計算されるデータ（特徴量）が例示される。あるいは、利用者の生体情報は、顔画像、指紋画像等の画像データであってもよい。利用者の生体情報は、利用者の身体的特徴を情報として含むものであればよい。第１の実施形態では、生体情報は、顔画像又は当該顔画像から生成された特徴量とする。

【0022】

認証サーバ１０は、生体認証によるサービスを実現するためのサーバ装置である。認証サーバ１０は、各サービス提供者から送信される「認証要求」を処理し、認証処理の結果をサービス提供者に送信する。

【0023】

サービス提供者は、顧客にサービスを提供する事業者である。サービス提供者として、宿泊事業者が例示される。サービス提供者は、管理サーバと端末（認証端末）を有する。

【0024】

例えば、サービス提供者Ｓ１には、管理サーバ２０と、複数の端末３０が設置されている。サービス提供者Ｓ２には、管理サーバ２１と、複数の端末３１が設置されている。各サービス提供者に含まれる各装置の動作等は同一とすることができるので、以降の説明は、サービス提供者Ｓ１を中心に説明する。

【0025】

管理サーバ２０は、サービス提供者の業務全般を制御、管理するサーバである。例えば、サービス提供者がホテル事業者であれば、管理サーバ２０は、宿泊客の予約情報の管理等を行う。

【0026】

管理サーバ２０は、上記サービス提供に係る機能に加え、利用者の生体認証に関する制御機能、管理機能を備える。

【0027】

端末３０は、サービス提供者を訪れた利用者（利用客）のインターフェイスとなる装置である。利用者は、端末３０を介して種々のサービス提供を受ける。

【0028】

ここで、端末３０は、設置場所や設置の目的に応じて機能が異なる。例えば、図３に示すように、受付端末３０－１はホテルのカウンタに設置される。利用者は、受付端末３０－１を用いてチェックイン手続き、チェックアウト手続きを行う。

【0029】

また、支払端末３０－２は、ホテル内の売店やレストラン等に設置される。例えば、支払端末３０－２は、所謂、セルフレジスタである。利用者は、支払端末３０－２を用いて商品等を購入する。

【0030】

決済事業者は、サービス提供者に代わり決済処理を行う事業者である。とりわけ、決済事業者は、銀行振替やクレジットカード払い等の決済処理を行う。決済事業者は、決済代行サーバ４０を管理、運営する。決済代行サーバ４０は、サービス事業者に生じた決済を代行する装置である。決済代行サーバ４０は、決済事業者の敷地に設置されたサーバであってもよいし、クラウド上に設置されたサーバであってもよい。

【0031】

サービス提供者は、決済代行サーバ４０に対して「決済代行要求」を送信し、決済処理の代行を依頼する。決済代行サーバ４０は、「決済代行要求」を処理し、処理結果をサービス提供者に送信する。

【0032】

図２に示す各装置は相互に接続されている。例えば、認証サーバ１０と管理サーバ２０は、有線又は無線の通信手段により接続され、相互に通信が可能となるように構成されている。

【0033】

図２は例示であって、本願開示の認証システムの構成等を限定する趣旨ではない。例えば、認証センターには２台以上の認証サーバ１０が含まれていてもよい。同様に、決済事業者は、２台以上の決済代行サーバ４０を運用、管理してもよい。

【0034】

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

【0035】

第１の実施形態では、サービス提供者は「宿泊事業者」として説明する。当該宿泊事業者は、チェックイン手続きが終了した利用者（宿泊客）が売店等の設備を使用できるという経営方針を備えるとする。即ち、ホテルの宿泊客は、チェックインからチェックアウトまでの間は売店等を利用できるが、チェックイン前又はチェックアウト後は当該売店等を利用できない。

【0036】

なお、「チェックイン手続き」は、事業者（宿泊事業者）がサービスを開始する契機となることから「サービス利用開始手続き」に相当する。「チェックアウト手続き」は、事業者（宿泊事業者）がサービス提供を終了する契機となることから「サービス利用終了手続き」に相当する。また、ホテルの宿泊客は「サービス利用予定者」に相当する。このように、以下の実施形態において「チェックイン」の文言は「サービス利用開始」又は「サービス利用開始手続き」と読み替えること可能であり、「チェックアウト」の文言は「サービス利用終了」又は「サービス利用終了手続き」と読み替えることが可能である。

【0037】

また、後述する「チェックイン通知」は「サービス利用開始通知」に、「チェックイン登録要求」は「サービス利用開始登録要求」に、「チェックインデータベース」は「サービス利用中データベース」に、それぞれ相当する。また、「チェックイン状況問合せ」は「サービス利用開始手続き状況問合せ」に相当する。

【0038】

以下、上記宿泊事業者の経営方針（ポリシ；運営方針）を実現する認証システムについて説明する。

【0039】

［利用者登録］
図４は、第１の実施形態に係る認証システムの利用者登録を説明するための図である。

【0040】

認証システムの利用を希望する利用者は、事前に利用者登録を行う。利用者は、認証システムにて利用者自身を特定するための情報（ユーザＩＤ（Identifier）、パスワード（ＰＷ；Pass Word））を決定し、システムに登録する。なお、図４を含む図面において、ユーザＩＤを「ｕＩＤ」と表記する。

【0041】

また、利用者は、自身の生体情報（例えば、顔画像）をシステムに登録する。利用者は、任意の手段を用いて上記３つの情報（ユーザＩＤ、パスワード、生体情報）をシステムに登録する。例えば、利用者は、上記３つの情報が記載された書類を認証センターに郵送し、認証センターの従業員が上記３つの情報を認証サーバ１０に入力してもよい。あるいは、利用者は、上記３つの情報が格納された、ＵＳＢ（Universal Serial Bus）等の外部記憶装置を認証センターに郵送してもよい。

【0042】

あるいは、利用者は、所有する端末５０を操作して撮像した自身の顔画像と、ユーザＩＤ、パスワードを認証サーバ１０に入力してもよい。端末５０には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ（パーソナルコンピュータ、ノートパソコン）等が例示される。

【0043】

認証サーバ１０は、取得した顔画像から特徴量（複数の特徴量からなる特徴ベクトル）を生成し、当該特徴量とユーザＩＤ、パスワードを対応付けて記憶する。具体的には、認証サーバ１０は、認証情報データベースに新規なエントリを追加し、上記３つの情報を対応付けて記憶する。認証情報データベースの詳細は後述する。

【0044】

このように、利用者登録にて、システムにおいて利用者を一意に定めるＩＤ（例えば、ユーザＩＤ）と利用者の認証に用いられる生体情報がシステムに登録される。なお、第１の実施形態では、システム利用者を一意に定める識別子としてユーザＩＤとパスワードを用いる例を説明するが、利用者間でユーザＩＤの重複がなければ、上記識別子としてユーザＩＤを用いることも可能である。

【0045】

［サービス提供者登録］
図５は、第１の実施形態に係る認証システムのサービス提供者登録を説明するための図である。

【0046】

利用者登録を終えた利用者は、生体認証によりサービスを受けたいサービス提供者を選択し、当該選択したサービス提供者をシステムに登録する。例えば、図２において、利用者がサービス提供者Ｓ１からサービスの提供を希望する場合には、サービス提供者Ｓ１をシステムに登録する。

【0047】

利用者は、選択したサービス提供者からサービスを受けるために必要な個人情報（例えば、氏名等）をシステムに登録する。上記個人情報として、氏名、生年月日、性別、住所等が例示される。また、第１の実施形態のように、サービス提供者が宿泊事業者であれば、上記個人情報としてホテルの予約情報（宿泊日、宿泊期間、客室のグレード等）もシステムに登録される。さらに、利用者は、上記個人情報と併せて、利用者登録にて決定されたユーザＩＤ、パスワードをシステムに登録する。予約情報は、利用者にサービスを提供するために必要な「サービス提供情報」に相当する。

【0048】

なお、本願開示において、個人情報は、利用者（被認証者）の生体情報を含まない情報と定義される。即ち、生体情報及び当該生体情報から生成された特徴量は、本願開示の「個人情報」から除外される。

【0049】

利用者は、上記３つの情報（個人情報、ユーザＩＤ、パスワード）を任意の手段を用いてサービス提供者に入力する。例えば、利用者は、上記３つの情報を記載した媒体（紙媒体、電子媒体）を、選択したサービス提供者に郵送する。サービス提供者の従業員が上記３つの情報を管理サーバ２０に入力する。利用者は、サービス提供者に設置された端末３０を操作して、上記３つの情報を管理サーバ２０に入力してもよい。

【0050】

あるいは、図５に示すように、利用者は端末５０を操作して上記３つの情報を管理サーバ２０に入力してもよい。この場合、利用者は、サービス提供者が管理、運営するＷＥＢ（ウェブ）ページ上にて上記３つの情報を入力する。

【0051】

管理サーバ２０は、上記３つの情報（個人情報、ユーザＩＤ、パスワード）を取得すると、認証サーバ１０に対して「サービス登録要求」を送信する。具体的には、管理サーバ２０は、サービス提供者ＩＤ、ユーザＩＤ及びパスワードを含むサービス登録要求を認証サーバ１０に送信する。

【0052】

サービス提供者ＩＤは、認証システムに含まれるサービス提供者（生体認証を利用する認証基盤に参加している宿泊事業者等）を一意に識別するための識別情報である。図２の例では、サービス提供者Ｓ１、Ｓ２のそれぞれに異なるサービス提供者ＩＤが割り当てられている。

【0053】

なお、サービス提供者ＩＤは、サービス提供者ごとに割り当てられるＩＤであって、サービスごとに割り当てられるＩＤではない。例えば、図２において、サービス提供者Ｓ１とＳ２が同じ種類のサービスを提供する事業者であっても、経営主体が異なればこれらのサービス提供者には異なるＩＤが割り当てられる。

【0054】

認証サーバ１０と管理サーバ２０は、任意の方法によりサービス提供者ＩＤを共有する。例えば、サービス提供者が認証基盤に参加する際、認証サーバ１０がサービス提供者ＩＤを生成し、当該生成したサービス提供者ＩＤをサービス提供者に配布（通知）すればよい。図５を含む図面において、サービス提供者ＩＤを「ｓｐＩＤ」と表記する。

【0055】

サービス登録要求を受信すると、認証サーバ１０は、当該要求に含まれるユーザＩＤとパスワードをキーとして認証情報データベースを検索し、対応する利用者を特定する。その後、認証サーバ１０は、「サービスユーザＩＤ」を生成する。

【0056】

サービスユーザＩＤは、利用者とサービス提供者の対応関係（組み合わせ）を一意に定める識別情報である。例えば、図２の例では、利用者Ｕ１とサービス提供者Ｓ１の組み合わせから定まるサービスユーザＩＤと、利用者Ｕ１とサービス提供者Ｓ２の組み合わせから定まるサービスユーザＩＤには、それぞれ異なる値が設定される。

【0057】

認証サーバ１０は、ユーザＩＤ、パスワード、特徴量、サービス提供者ＩＤ、上記生成されたサービスユーザＩＤを対応付けて記憶する。図５を含む図面において、サービスユーザＩＤを「ｓｕＩＤ」と表記する。

【0058】

認証サーバ１０は、上記生成したサービスユーザＩＤを、サービス登録要求の送信元に送信する。認証サーバ１０は、サービスユーザＩＤを含む応答を管理サーバ２０に送信し、サービスユーザＩＤの払い出しを行う。

【0059】

管理サーバ２０は、認証サーバ１０から取得したサービスユーザＩＤと利用者の個人情報（予約情報）を対応付けて記憶する。管理サーバ２０は、利用者情報データベースに新規なエントリを追加し、上記情報（個人情報、サービスユーザＩＤ）を格納する。

【0060】

利用者は、生体認証を用いたサービスの提供を受けたいサービス提供者ごとに上記のような登録動作を繰り返す。換言すれば、利用者は、サービスの提供が不要なサービス提供者についての利用登録を行う必要はない。

【0061】

このように、サービス提供者登録において、利用者が利用を希望するサービスのサービス提供者から、ユーザＩＤとサービス提供者ＩＤを含むサービス登録要求が認証サーバ１０に送信される。認証サーバ１０は、当該サービス登録要求を処理する際、利用者とサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤを生成する。認証サーバ１０は、サービスユーザＩＤをサービス提供者に送信する。サービス提供者（管理サーバ２０）は、利用者の個人情報とサービスユーザＩＤを対応付けて記憶する。

【0062】

［口座情報登録］
図６は、第１の実施形態に係る認証システムの口座情報登録を説明するための図である。

【0063】

サービス提供者に支払う対価を銀行口座からの引き落としやクレジットカード払いを希望する利用者は、口座情報（銀行口座情報、クレジットカード情報）を決済代行サーバ４０に登録する。

【0064】

はじめに、利用者は、端末５０を操作し、ユーザＩＤ、パスワードを用いて認証サーバ１０にログインする。その後、利用者は、認証サーバ１０に口座情報を入力する。

【0065】

口座情報を取得すると、認証サーバ１０は、当該口座情報の登録を決済代行サーバ４０に要求する。認証サーバ１０は、利用者のユーザＩＤ及び口座情報を含む「口座情報登録要求」を決済代行サーバ４０に送信する。例えば、認証サーバ１０は、決済代行サーバ４０が提供するＡＰＩ（Application Programming Interface）により口座情報等を決済代行サーバ４０に口座情報を引き渡す。

【0066】

口座情報登録要求を受信した決済代行サーバ４０は、当該利用者を識別するためのＩＤ（以下、顧客ＩＤと表記する）を生成する。決済代行サーバ４０は、当該生成した顧客ＩＤと口座情報（銀行口座情報、クレジットカード情報）を対応付けて「顧客ＩＤ変換テーブル」に記憶する。顧客ＩＤ変換テーブルは、顧客ＩＤを口座情報に変換するための第１の変換テーブルである。

【0067】

決済代行サーバ４０は、顧客ＩＤと口座情報を紐づける「紐づけ情報」を生成する。決済代行サーバは、生成した紐づけ情報と顧客ＩＤを対応付けて「紐づけ情報変換テーブル」に記憶する。紐づけ情報変換テーブルは、紐づけ情報を顧客ＩＤに変換するための第２の変換テーブルである。

【0068】

決済代行サーバ４０は、生成した紐づけ情報と対応する利用者のユーザＩＤを含む応答（口座情報登録要求に対する応答）を認証サーバ１０に送信する。

【0069】

認証サーバ１０は、ユーザＩＤから利用者を特定し、認証情報データベースの対応するエントリに上記取得した紐づけ情報を登録する。

【0070】

このように、口座情報登録において、決済代行サーバ４０は、口座開設を希望する利用者の顧客ＩＤと口座情報を紐づける「紐づけ情報」を生成し、当該生成された紐づけ情報を認証サーバ１０に送信する。認証サーバ１０は、利用者の生体認証に用いる生体情報と、利用者と管理サーバ２０が設置されたサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、紐づけ情報と、を対応付けて認証情報データベースに記憶する。

【0071】

［チェックイン手続き］
図７は、宿泊事業者におけるチェックイン手続きを説明するための図である。

【0072】

サービス提供者登録（予約情報のシステム登録）を終了した利用者は、ホテルを訪れる。利用者は、受付端末３０－１の前に移動する。管理サーバ２０（第１の管理サーバ）は、当該利用者予約情報とサービスユーザＩＤを予め対応付けて記憶している。

【0073】

利用者がチェックイン手続きを希望すると、受付端末３０－１は、面前の利用者から生体情報を取得する。具体的には、受付端末３０－１は、利用者を撮像し、顔画像を取得する。受付端末３０－１は、取得した顔画像を含む「チェックイン要求」を管理サーバ２０に送信する。

【0074】

管理サーバ２０は、チェックイン要求に含まれる顔画像から特徴量を生成する。管理サーバ２０は、当該生成した特徴量とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する。

【0075】

このように、受付端末３０－１は、第１の利用者の生体情報を含むチェックイン要求を管理サーバ２０に送信する。管理サーバ２０は、第１の利用者の生体情報を含む第１の認証要求を認証サーバ１０に送信する。

【0076】

認証サーバ１０は、認証要求から特徴量を取り出し、当該取り出した特徴量と認証情報データベースに登録された特徴量を用いた照合処理（１対Ｎ照合；Ｎは正の整数、以下同じ）を実行する。

【0077】

認証サーバ１０は、照合処理により利用者を特定し、当該特定した利用者に対応付けられている複数のサービスユーザＩＤのうち認証要求に含まれるサービス提供者ＩＤに対応するサービスユーザＩＤを特定する。

【0078】

認証サーバ１０は、特定したサービスユーザＩＤを認証要求の送信元に送信する。認証サーバ１０は、特定したサービスユーザＩＤを含む応答（認証要求に対する応答）を管理サーバ２０に送信する。

【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】

利用者登録部２０２は、任意の手段を用いて上記３つの情報（ユーザＩＤ、パスワード、生体情報）を取得する。例えば、利用者登録部２０２は、ユーザＩＤ、パスワードを決定するためのＧＵＩ（Graphical User Interface）や入力フォームを端末５０に表示する。例えば、利用者登録部２０２は、図１２に示すようなＧＵＩを端末５０に表示する。

【0125】

利用者登録部２０２は、ＧＵＩ等により取得したユーザＩＤ、パスワードが既に登録されているユーザＩＤ、パスワードと重複していないことを検証する。当該重複が発生していなければ、利用者登録部２０２は、利用者の生体情報を取得するためのＧＵＩを端末５０に表示する。

【0126】

例えば、利用者登録部２０２は、図１３に示すようなＧＵＩを端末５０に表示する。例えば、利用者は、図１３に示す「ファイル選択」ボタンを押下し、システムに登録する顔画像の画像データを指定する。指定された顔画像は、プレビュー領域に表示される（図１３では選択顔画像として表示されている）。プレビューされた顔画像を登録する際には、利用者は「決定」ボタンを押下する。

【0127】

利用者登録部２０２は、例えば、図１２、図１３に示すようなＧＵＩによりユーザＩＤ、パスワード、生体情報（顔画像）を取得すると、顔画像から特徴量（複数の特徴量からなる特徴ベクトル）を生成する。

【0128】

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

【0129】

利用者登録部２０２は、ユーザＩＤ、パスワード及び上記生成した特徴量をデータベース管理部２０３に引き渡す。

【0130】

データベース管理部２０３は、認証情報データベースを管理する手段である。認証情報データベースは、システム利用者を特定する情報（ユーザＩＤ、パスワード）、当該利用者の生体情報（特徴量）を記憶する。さらに、認証情報データベースは、利用者の紐づけ情報、サービス提供者を特定するサービス提供者ＩＤ、各サービスにおいて利用者を特定するサービスユーザＩＤを対応付けて記憶する。

【0131】

データベース管理部２０３は、利用者登録部２０２から上記３つの情報（ユーザＩＤ、パスワード、特徴量）を取得した場合、認証情報データベースに新規エントリを追加する。例えば、利用者Ｕ１に関する上記３つの情報を取得した場合には、データベース管理部２０３は、図１４の最下段に示されるエントリを追加する。なお、利用者登録の段階では、紐づけ情報、サービス提供者ＩＤ、サービスユーザＩＤは生成されていないのでこれらのフィールドには何も設定されない。

【0132】

サービス登録部２０４は、システム利用者による個別のサービス登録（サービス提供者登録）を実現する手段である。サービス登録部２０４は、サービス提供者の管理サーバ２０から取得するサービス登録要求を処理する。

【0133】

サービス登録部２０４は、取得したサービス登録要求に含まれるユーザＩＤ、パスワードをキーとして認証情報データベースを検索する。サービス登録部２０４は、特定した利用者（ユーザＩＤ、パスワードの組から特定される利用者）のサービス提供者ＩＤフィールドを確認する。

【0134】

サービス登録部２０４は、サービス提供者ＩＤフィールドに、管理サーバ２０から取得したサービス登録要求に含まれるサービス提供者ＩＤが設定されているか否かを判定する。管理サーバ２０から取得したサービス提供者ＩＤが既にデータベースに登録されていれば、サービス登録部２０４は、その旨を管理サーバ２０に通知する。この場合、認証情報データベースには、利用者が登録しようとしているサービス（サービス提供者）は既に登録されているので、サービス登録部２０４は、サービス登録要求に対する応答として「否定応答」を送信する。

【0135】

対して、特定された利用者のサービス提供者ＩＤフィールドに、サービス登録要求に含まれるサービス提供者ＩＤが設定されていなければ、サービス登録部２０４は、当該利用者とサービス提供者に対応するサービスユーザＩＤを生成する。

【0136】

上述のように、サービスユーザＩＤは、利用者とサービス提供者の組み合わせから一意に定まる識別情報である。例えば、サービス登録部２０４は、ユーザＩＤ、パスワード及びサービス提供者ＩＤを用いてハッシュ値を計算し、当該計算されたハッシュ値をサービスユーザＩＤとする。具体的には、サービス登録部２０４は、ユーザＩＤ、パスワード及びサービス提供者ＩＤの連結値を計算し、当該計算された連結値のハッシュ値を計算することで、サービスユーザＩＤを生成する。

【0137】

なお、上記ハッシュ値を用いたサービスユーザＩＤの生成は例示であって、サービスユーザＩＤの生成方法を限定する趣旨ではない。サービスユーザＩＤは、システム利用者とサービス提供者の組み合わせを一意に識別できる情報であればどのような情報であってもよい。例えば、サービス登録部２０４は、サービス登録要求を処理するたびに一意な値を採番しサービスユーザＩＤとしてもよい。

【0138】

サービスユーザＩＤを生成すると、サービス登録部２０４は、ユーザＩＤ及びパスワードと共に、サービス提供者ＩＤとサービスユーザＩＤをデータベース管理部２０３に引き渡す。データベース管理部２０３は、２つのＩＤ（サービス提供者ＩＤ、サービスユーザＩＤ）を認証情報データベースに登録する。例えば、利用者Ｕ１がサービス提供者Ｓ１についてサービス登録をすると、図１５の最下段に示されるエントリに上記２つのＩＤが追加される。

【0139】

サービス登録はサービス提供者ごとに行われるため、１人の利用者に複数のサービス提供者、サービスユーザＩＤが設定されることがある。例えば、利用者Ｕ１がサービス提供者Ｓ１、Ｓ２のそれぞれに関してサービス登録を行った場合には、図１６の２行目、３行目のエントリが生成される。なお、利用者Ｕ２がサービス提供者Ｓ１に関してサービス登録を行った場合には、図１６の最下段のエントリが生成される。

【0140】

図１６等に示す認証情報データベースは例示であって、認証情報データベースが記憶する情報を制限する趣旨ではない。例えば、認証用の特徴量に代えて又は加えて顔画像が認証情報データベースに登録されていてもよい。例えば、認証の都度、認証情報データベースに登録された顔画像から特徴量が生成されてもよい。

【0141】

サービス提供者ＩＤ、サービスユーザＩＤが認証情報データベースに登録されると、サービス登録部２０４は、サービス登録要求が正常に処理されたことを管理サーバ２０に通知する。サービス登録部２０４は、サービス登録要求に対する応答として「肯定応答」を送信する。その際、サービス登録部２０４は、サービスユーザＩＤを含む応答を管理サーバ２０に送信する。

【0142】

口座情報登録部２０５は、利用者の口座情報の登録を決済代行サーバ４０に要求する手段である。認証サーバ１０にログインした利用者が、メニュー表示等から口座情報の登録を希望すると、口座情報登録部２０５は、図１７に示すようなＧＵＩや入力フォームを端末５０に表示し、口座情報を取得する。

【0143】

口座情報登録部２０５は、取得した口座情報と利用者のユーザＩＤを含む口座情報登録要求を決済代行サーバ４０に送信する。

【0144】

口座情報登録部２０５は、口座情報登録要求に対する応答（肯定応答、否定応答）を受信する。

【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】

決済代行要求部３０７は、要求処理部３０５から取得したサービスユーザＩＤを含む「紐づけ情報送信要求」を認証サーバ１０に送信する。また、決済代行要求部３０７は、当該紐づけ情報送信要求の送信に前後して、要求処理部３０５から取得したサービスユーザＩＤ、決済情報を含む「決済代行要求」を決済代行サーバ４０に送信する。

【0199】

決済代行要求部３０７は、決済代行要求に対する応答を決済代行サーバ４０から受信する。決済代行要求部３０７は、受信した応答（決済処理の結果）を要求処理部３０５に引き渡す。

【0200】

記憶部３０８は、管理サーバ２０の動作に必要な情報を記憶する。利用者情報データベース及び宿泊者情報データベースは記憶部３０８に構築される。

【0201】

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

【0202】

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

【0203】

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

【0204】

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

【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】

図３３は、第１の実施形態に係る認証システムのチェックイン手続きに関する動作の一例を示すシーケンス図である。

【0250】

受付端末３０－１は、利用者の顔画像（生体情報）を取得し、当該取得した顔画像を含む「チェックイン要求」を管理サーバ２０に送信する（ステップＳ１１）。

【0251】

管理サーバ２０は、取得した顔画像から特徴量を生成する（ステップＳ１２）。

【0252】

管理サーバ２０は、当該生成された特徴量とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する（ステップＳ１３）。

【0253】

認証サーバ１０は、認証要求に含まれる特徴量とサービス提供者ＩＤを用いた認証処理を実行し、対応するサービスユーザＩＤを特定する（ステップＳ１４）。

【0254】

認証サーバ１０は、特定したサービスユーザＩＤを含む応答（認証要求に対する応答）を管理サーバ２０に送信する（ステップＳ１５）。

【0255】

管理サーバ２０は、取得したサービスユーザＩＤを用いて利用者情報データベースを検索し、対応する個人情報、予約情報を特定する（ステップＳ１６）。

【0256】

管理サーバ２０は、特定した予約情報を用いて、利用者のチェックイン可否を判定する（ステップＳ１７）。例えば、生体認証により特定された利用者が、事前に予約した宿泊日に訪れた場合に、チェックイン可と判定される。

【0257】

管理サーバ２０は、チェックイン要求に対する応答を受付端末３０－１に送信する（ステップＳ１８）。

【0258】

受付端末３０－１は、受信した応答（肯定応答、否定応答）に応じたメッセージ等を出力する（ステップＳ１９）。

【0259】

図３４は、第１の実施形態に係る認証システムの商品購入に関する動作の一例を示すシーケンス図である。図３４を参照して、支払端末３０－２が送信する判定要求を処理する際の動作を説明する。

【0260】

支払端末３０－２は、利用者の顔画像（生体情報）を取得し、当該取得した顔画像を含む「判定要求」を管理サーバ２０に送信する（ステップＳ２１）。

【0261】

管理サーバ２０は、取得した顔画像から特徴量を生成する（ステップＳ２２）。

【0262】

管理サーバ２０は、当該生成された特徴量とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する（ステップＳ２３）。

【0263】

認証サーバ１０は、認証要求に含まれる特徴量とサービス提供者ＩＤを用いた認証処理を実行し、対応するサービスユーザＩＤを特定する（ステップＳ２４）。

【0264】

認証サーバ１０は、特定したサービスユーザＩＤを含む応答（認証要求に対する応答）を管理サーバ２０に送信する（ステップＳ２５）。

【0265】

管理サーバ２０は、取得したサービスユーザＩＤを用いて利用者情報データベースを検索し、対応する個人情報（氏名）を特定する（ステップＳ２６）。

【0266】

管理サーバ２０は、特定した予約情報を用いて、利用者の商品購入に関する資格の有無を判定する（ステップＳ２７）。例えば、生体認証により特定された利用者が、チェックインを完了している場合に、「資格あり」と判定される。

【0267】

管理サーバ２０は、判定要求に対する応答を支払端末３０－２に送信する（ステップＳ２８）。

【0268】

支払端末３０－２は、受信した応答（肯定応答、否定応答）に応じたメッセージ等を出力する（ステップＳ２９）。

【0269】

図３５は、第１の実施形態に係る認証システムの代金決済に関する動作の一例を示すシーケンス図である。図３５を参照して、支払端末３０－２が送信する決済要求を処理する際の動作を説明する。

【0270】

利用者が、クレジットカード払い等を希望すると、支払端末３０－２は、当該利用者のサービスユーザＩＤと決済情報を含む決済要求を管理サーバ２０に送信する（ステップＳ３１）。

【0271】

管理サーバ２０は、サービスユーザＩＤを含む「紐づけ情報送信要求」を認証サーバ１０に送信する（ステップＳ３２）。

【0272】

紐づけ情報送信要求を受信すると、認証サーバ１０は、サービスユーザＩＤをキーとして認証情報データベースを検索し、対応するエントリ（利用者）の紐づけ情報を取得する。認証サーバ１０は、サービスユーザＩＤと取得した紐づけ情報を含む「紐づけ情報通知」を決済代行サーバ４０に送信する（ステップＳ３３）。

【0273】

管理サーバ２０は、上記紐づけ情報送信要求の送信に前後して、サービスユーザＩＤと決済情報を含む「決済代行要求」を決済代行サーバ４０に送信する（ステップＳ３４）。

【0274】

決済代行サーバ４０は、サービスユーザＩＤに基づいて紐づけ情報通知と決済代行要求の対応関係を明らかとし、紐づけ情報変換テーブルを参照して、紐づけ情報通知に含まれる紐づけ情報に対応する顧客ＩＤを取得する（ステップＳ３５）。

【0275】

決済代行サーバ４０は、顧客ＩＤ変換テーブルを参照し、上記取得した顧客ＩＤに対応する口座情報を取得する（ステップＳ３６）。

【0276】

決済代行サーバ４０は、決済代行要求に含まれる決済情報と、上記取得した口座情報を用いて決済処理を実行する（ステップＳ３７）。

【0277】

決済代行サーバ４０は、決済処理の結果を管理サーバ２０に送信する（ステップＳ３８）。

【0278】

管理サーバ２０は、受信した決済処理の結果を支払端末３０－２に送信する（ステップＳ３９）。

【0279】

支払端末３０－２は、決済処理の結果に応じたメッセージ等を出力する（ステップＳ４０）。

【0280】

図３６は、第１の実施形態に係る認証システムのチェックアウト手続きに関する動作の一例を示すシーケンス図である。

【0281】

受付端末３０－１は、利用者の顔画像（生体情報）を取得し、当該取得した顔画像を含む「チェックアウト要求」を管理サーバ２０に送信する（ステップＳ４１）。

【0282】

管理サーバ２０は、取得した顔画像から特徴量を生成する（ステップＳ４２）。

【0283】

管理サーバ２０は、当該生成された特徴量とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する（ステップＳ４３）。

【0284】

認証サーバ１０は、認証要求に含まれる特徴量とサービス提供者ＩＤを用いた認証処理を実行し、対応するサービスユーザＩＤを特定する（ステップＳ４４）。

【0285】

認証サーバ１０は、特定したサービスユーザＩＤを含む応答（認証要求に対する応答）を管理サーバ２０に送信する（ステップＳ４５）。

【0286】

管理サーバ２０は、取得したサービスユーザＩＤを用いて利用者情報データベースを検索し、対応する個人情報（氏名）を特定する（ステップＳ４６）。

【0287】

管理サーバ２０は、特定した個人情報（氏名）を用いて、チェックアウト手続きを行う（ステップＳ４７）。具体的には、管理サーバ２０は、利用者の状態が「チェックイン済」であれば、チェックアウト手続き可能と判断する。この場合、管理サーバ２０は、宿泊者情報データベースを参照し、宿泊料金等を計算する。

【0288】

管理サーバ２０は、チェックアウト要求に対する応答を受付端末３０－１に送信する（ステップＳ４８）。チェックアウト手続きを正常に終了した場合には、管理サーバ２０は、利用者のサービスユーザＩＤと宿泊料金を含む肯定応答を受付端末３０－１に送信する。

【0289】

受付端末３０－１は、受信した応答（肯定応答、否定応答）に応じたメッセージ等を出力する（ステップＳ４９）。

【0290】

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

【0291】

＜第１の実施形態に係る変形例１＞
第１の実施形態では、決済代行サーバ４０は、１人の利用者に対して１つの紐づけ情報を生成する場合について説明した。しかし、決済代行サーバ４０は、１人の利用者に対してサービス提供者ごとに紐づけ情報を生成してもよい。

【0292】

この場合、認証サーバ１０は、口座情報登録要求を送信する際、利用者のユーザＩＤ、口座情報に加え、サービス提供者ＩＤ又はサービスユーザＩＤを含む口座登録要求を決済代行サーバ４０に送信する。決済代行サーバ４０は、サービス提供者ごとに紐づけ情報を生成し、紐づけ情報変換テーブルにより管理すればよい（図３７参照）。

【0293】

決済代行サーバ４０は、生成した紐づけ情報と、対応するサービス提供者ＩＤ又はサービスユーザＩＤと、を含む応答を認証サーバ１０に送信する。認証サーバ１０は、取得した紐づけ情報をサービス提供者ごとに認証情報データベースを用いて記憶する（図３８参照）。

【0294】

なお、この場合、代金決済の動作は、上記説明と同一とすることができるので詳細な説明を省略する。認証サーバ１０は、サービスユーザＩＤによって紐づけ情報を特定し、当該特定した紐づけ情報を決済代行サーバ４０に送信する。決済代行サーバ４０は、紐づけ情報変換テーブルから顧客ＩＤを特定すればよい。

【0295】

このように、決済代行サーバ４０は、複数のサービス提供者ごとに紐づけ情報を生成する。認証サーバ１０は、利用者の生体情報と、サービス提供者ごとの紐づけ情報と、サービス提供者ごとのサービスユーザＩＤと、を対応付けて認証情報データベースに記憶する。

【0296】

＜第１の実施形態に係る変形例２＞
上記実施形態では、利用者がホテル内で商品等を購入すると、都度、その決済をする場合について説明した。しかし、利用者がホテルに宿泊している期間内の決済情報を蓄積し、利用者がチェックアウトする際にまとめて決済が行われてもよい。

【0297】

この場合、管理サーバ２０は、支払端末３０－２から決済要求を取得すると、当該取得した決済要求に含まれる決済情報を「仮決済データベース」に記憶する。仮決済データベースは、利用者ごと（サービスユーザＩＤごと）に決済情報を記憶するデータベースである（図３９参照）。

【0298】

管理サーバ２０は、支払端末３０－２から決済要求を取得すると、当該要求に含まれるサービスユーザＩＤに対応するエントリ（仮決済データベースのエントリ）に決済要求に含まれる決済情報を記憶、追記する。

【0299】

管理サーバ２０は、受付端末３０－１からチェックアウトに伴う決済要求を受信すると、当該決済要求に含まれるサービスユーザＩＤをキーとして仮決済データベースを検索し、対応するエントリを特定する。

【0300】

管理サーバ２０は、特定したエントリの決済情報及び受付端末３０－１から取得した決済情報を含む決済代行要求を決済代行サーバ４０に送信する。

【0301】

決済代行サーバ４０は、決済代行要求に含まれる少なくとも１以上の決済情報を用いた決済処理を行う。決済代行サーバ４０は、利用者がホテルに宿泊している期間に発生した決済と宿泊料金をまとめて決済する。

【0302】

このように、管理サーバ２０は、支払端末３０－２（第２の端末）から取得した決済情報を受付端末３０－１（第１の端末）から決済要求を受信するまで蓄積する。管理サーバ２０は、受付端末３０－１から決済要求を受信すると、当該蓄積した決済情報と受付端末３０－１から取得した決済情報を含む決済代行要求を決済代行サーバ４０に送信する。その結果、決済代行サーバ４０への決済代行要求が抑制され、手数料の削減が実現できる。

【0303】

＜第１の実施形態に係る変形例３＞
上記実施形態では、管理サーバ２０は、宿泊者情報データベースの状態フィールドを参照し、利用者の商品購入資格を判定する場合について説明した。しかし、商品購入資格の有無を判定する機能は、管理サーバ２０ではなく決済代行サーバ４０に持たせることも可能である。

【0304】

図４０は、第１の実施形態に係る変形例３の動作を説明するための図である。

【0305】

受付端末３０－１は、チェックイン要求を管理サーバ２０に送信する（Ａ１）。

【0306】

管理サーバ２０は、生体情報とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する（Ａ２）。

【0307】

認証サーバ１０は、生体認証に成功すると、サービスユーザＩＤを含む肯定応答を管理サーバ２０に送信する（Ａ３）。

【0308】

管理サーバ２０は、チェックインの可否を判定し、チェックイン可の場合には、サービスユーザＩＤを含む「チェックイン通知」を認証サーバ１０に送信する（Ａ４）。

【0309】

当該通知を受けた認証サーバ１０は、サービスユーザＩＤと紐づけ情報を含む「チェックイン登録要求」を決済代行サーバ４０に送信する（Ａ５）。

【0310】

決済代行サーバ４０は、サービスユーザＩＤと紐づけ情報を対応付けてチェックインデータベースに記憶する。

【0311】

また、管理サーバ２０は、チェックイン要求に対する応答を受付端末３０－１に送信する（Ａ６）。

【0312】

利用者が売店等で商品を購入する際、支払端末３０－２は、判定要求を管理サーバ２０に送信する（Ａ７）。

【0313】

管理サーバ２０は、支払端末３０－２から判定要求を取得すると、認証サーバ１０に対して生体情報とサービス提供者ＩＤを含む認証要求を送信する（Ａ２）。

【0314】

認証サーバ１０は、生体認証に成功すると、サービスユーザＩＤを含む肯定応答を管理サーバ２０に送信する（Ａ３）。

【0315】

管理サーバ２０は、認証サーバ１０から取得したサービスユーザＩＤを含む「チェックイン状況問合せ」を決済代行サーバ４０に送信する（Ａ８）。

【0316】

決済代行サーバ４０は、取得したサービスユーザＩＤがチェックインデータベースに記憶されている場合、利用者は「商品購入資格あり」と判断し、肯定応答を管理サーバ２０に送信する（応答の送信；Ａ９）。

【0317】

管理サーバ２０は、決済代行サーバ４０からの応答に応じて支払端末３０－２から取得した判定要求に対する応答を送信する（Ａ１０）。管理サーバ２０は、チェックイン問合せ対する肯定応答を受信した場合に、判定応答に対する肯定応答を支払端末３０－２に送信する。

【0318】

このように、管理サーバ２０は、第１の利用者がチェックイン可と判定された場合、当該第１の利用者のサービスユーザＩＤを含むチェックイン通知を認証サーバ１０に送信する。認証サーバ１０は、チェックイン通知を受信すると、サービスユーザＩＤ及び対応する紐づけ情報を含むチェックイン登録要求を決済代行サーバ４０に送信する。決済代行サーバ４０は、サービスユーザＩＤと紐づけ情報をチェックインデータベースに対応付けて記憶する。管理サーバ２０は、支払端末３０－２（第２の端末）から判定要求を受信すると、決済代行サーバ４０に対して、認証サーバ１０から受信したサービスユーザＩＤを含むチェックイン状況問合せを送信する。決済代行サーバ４０は、チェックイン状況問合せに含まれるサービスユーザＩＤがチェックインデータベースに記憶されている場合、当該第２の利用者の商品購入を許可する肯定応答を管理サーバ２０に送信する。決済代行サーバ４０がサービスユーザＩＤと紐づけ情報を対応付けて記憶することで、管理サーバ２０は、利用者がチェックイン済か否かを管理する必要がない。

【0319】

以上のように、第１の実施形態に係る認証システムは、管理サーバ２０は、利用者が受付端末３０－１を用いてチェックイン手続きが完了したことを管理、記憶する。管理サーバ２０は、利用者が支払端末３０－２を用いて商品等を購入する場合、当該利用者がチェックインの完了した宿泊者の場合に、商品等の購入を許可する。このようにして、認証システムでは、事業者（ホテル）の設定したポリシ（運営方針；宿泊者に限り商品等を購入できる）を実現する。

【0320】

また、宿泊客のチェックイン日時は一定期間（宿泊期間）、管理サーバ２０に保存され、当該一定期間の間で宿泊客は商品購入等が行える。即ち、利用者のチェックインからチェックアウトまでの期間に限り、利用者は商品等を購入することができる。換言すれば、利用者がチェックアウトした後は、当該利用者に関する記録はクリアされ、チェックアウト後の利用者は商品等を購入することはできない。

【0321】

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

【0322】

第１の実施形態では、認証サーバ１０が紐づけ情報を保持する場合について説明した。第２の実施形態では、サービス提供者（管理サーバ２０）が紐づけ情報を保持する場合について説明する。即ち、第２の実施形態に係る認証サーバ１０は、少なくとも利用者の生体認証に用いる生体情報とサービスユーザＩＤと、を対応付けて認証情報データベースに記憶する。

【0323】

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

【0324】

第２の実施形態では、利用者は、認証センター（認証サーバ１０）を介して口座情報を決済代行サーバ４０に登録するのではなく、サービス提供者（管理サーバ２０）を介して口座情報を決済代行サーバ４０に登録する。

【0325】

例えば、管理サーバ２０は、サービス登録時に、利用者の個人情報等を取得し、当該利用者のサービスユーザＩＤを取得すると、図４１に示すようなＧＵＩを表示する。管理サーバ２０は、利用者が口座情報の登録を希望すると、図１７に示すようなＧＵＩ画面に遷移し、口座情報を取得する。

【0326】

その後、管理サーバ２０は、利用者のサービスユーザＩＤ、口座情報を含む「口座情報登録要求」を決済代行サーバ４０に送信する。

【0327】

決済代行サーバ４０は、第１の実施形態にて説明したように、顧客ＩＤを生成し、当該顧客ＩＤと口座情報を顧客ＩＤ変換テーブルに記憶する。また、決済代行サーバ４０は、紐づけ情報を生成し、顧客ＩＤと紐づけ情報を対応付けて紐づけ情報変換テーブルに記憶する。

【0328】

決済代行サーバ４０は、サービスユーザＩＤと紐づけ情報を管理サーバ２０に送信する。管理サーバ２０は、サービスユーザＩＤをキーとして利用者情報データベースを検索し、対応するエントリに紐づけ情報を記憶する（図４２参照）。

【0329】

第２の実施形態において、代金決済では、認証システムは、図４３に示すような動作を行う。

【0330】

支払端末３０－２は、利用者のサービスユーザＩＤ、決済情報を含む決済要求を管理サーバ２０に送信する（Ｂ１）。

【0331】

管理サーバ２０は、取得したサービスユーザＩＤに対応する紐づけ情報を利用者情報データベースから読み出し、当該紐づけ情報と決済情報を含む「決済代行要求」を決済代行サーバ４０に送信する（Ｂ２）。

【0332】

決済代行サーバ４０は、紐づけ情報変換テーブルを参照し、決済代行要求に含まれる紐づけ情報に対応する顧客ＩＤを取得する。決済代行サーバ４０は、顧客ＩＤ変換テーブルを参照し、上記顧客ＩＤに対応する口座情報を取得する。決済代行サーバ４０は、管理サーバ２０から取得した決済情報と口座情報を用いて決済処理を実行する。

【0333】

決済代行サーバ４０は、管理サーバ２０を介して決済処理の結果を支払端末３０－２に送信する（Ｂ３、Ｂ４）。

【0334】

このように、決済代行サーバ４０は、口座情報登録要求に従って生成した紐づけ情報を管理サーバ２０に送信する。管理サーバ２０は、顧客の決済が必要となると、サービスユーザＩＤに対応する紐づけ情報と決済情報を含む決済代行要求を決済代行サーバ４０に送信する。

【0335】

以上のように、第２の実施形態に係る認証システムでは、管理サーバ２０がサービスユーザＩＤと紐づけ情報を対応付けて記憶する。その結果、認証サーバ１０のデータベースを圧迫することがない。

【0336】

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

【0337】

第３の実施形態では、異なるサービス提供者が提携関係にある場合について説明する。例えば、サービス提供者Ｓ１が宿泊事業者、サービス提供者Ｓ２が小売業者であり、サービス提供者Ｓ１が運営するホテル内でサービス提供者Ｓ２が小売店を経営する場合について説明する。なお、この場合であっても、ホテルの宿泊者がホテル内の施設（売店、小売店）を利用できるという経営方針は変わらない。

【0338】

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

【0339】

第３の実施形態では、認証サーバ１０は、提携関係にあるサービス提供者をテーブル情報により管理、記憶する（図４４参照）。図４４に示すように、認証サーバ１０は、主たるサービス提供者と、少なくとも１以上の従たるサービス提供者と、を対応付けて記憶する。システム管理者等は、図４４に示すようなテーブル情報を予め認証サーバ１０に登録する。

【0340】

なお、第３の実施形態では、第１の実施形態に係る変形例１のように、認証サーバ１０は、各サービス提供者のサービスユーザＩＤと紐づけ情報を対応付けて記憶するものとする（図３８参照）。

【0341】

図４５、図４７～図４９は、第３の実施形態に係る認証システムの動作を説明するための図である。図４６は、第３の実施形態に係るチェックインデータベースの一例を示す図である。

【0342】

利用者（利用者Ｕ１とする）は、主たるサービス提供者であるホテルを訪れる。利用者は、受付端末３０－１を用いてチェックイン手続きを行う。

【0343】

ホテル（主たるサービス提供者Ｓ１）の受付端末３０－１は、生体情報を含む「チェックイン要求」を管理サーバ２０に送信する（Ｃ１）。

【0344】

管理サーバ２０は、生体情報とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する（Ｃ２）。

【0345】

認証サーバ１０は、生体認証に成功すると、サービスユーザＩＤを含む肯定応答を管理サーバ２０に送信する（Ｃ３）。

【0346】

管理サーバ２０は、チェックインの可否を判定し、チェックイン可の場合には、チェックイン通知を認証サーバ１０に送信する（Ｃ４）。

【0347】

当該通知に応じて、認証サーバ１０は、認証成功者に関する主従の関係にあるサービス提供者それぞれのサービスユーザＩＤと紐づけ情報を含む「チェックイン登録要求」を決済代行サーバ４０に送信する（Ｃ５）。図３８の例では、利用者Ｕ１に関するサービスユーザＩＤ「Ｕ１Ｓ１」、「Ｕ１Ｓ２」と紐づけ情報「ＣＩ１１」、「ＣＩ１２」を含むチェックイン登録要求が決済代行サーバ４０に送信される。

【0348】

決済代行サーバ４０は、チェックイン登録要求によって取得した情報をチェックインデータベースに記憶する（図４６参照）。

【0349】

決済代行サーバ４０は、紐づけ情報、サービスユーザＩＤをチェックインデータベースに記憶するとその旨を認証サーバ１０に通知する（応答の送信；図４５のＣ６）。

【0350】

管理サーバ２０は、チェックイン要求に対する応答を受付端末３０－１に送信する（Ｃ７）。

【0351】

利用者が商品を購入するため売店を訪れる。当該売店は、従たるサービス提供者Ｓ２によって運営されている。利用者が売店等で商品を購入する際、サービス提供者Ｓ２の支払端末３１－２は、判定要求を管理サーバ２１に送信する（図４７のＤ１）。

【0352】

サービス提供者Ｓ２の管理サーバ２１は、支払端末３１－２から判定要求を取得すると、認証サーバ１０に対して生体情報とサービス提供者ＩＤを含む認証要求を送信する（Ｄ２）。

【0353】

認証サーバ１０は、生体認証に成功すると、サービスユーザＩＤを含む肯定応答を管理サーバ２１に送信する（Ｄ３）。

【0354】

管理サーバ２１は、認証サーバ１０から取得したサービスユーザＩＤを含む「チェックイン状況問合せ」を決済代行サーバ４０に送信する（Ｄ４）。

【0355】

決済代行サーバ４０は、取得したサービスユーザＩＤがチェックインデータベースに記憶されている場合、利用者は「商品購入資格あり」と判断し、肯定応答を管理サーバ２１に送信する（応答の送信；Ｄ５）。

【0356】

図４６の例では、利用者Ｕ１とサービス提供者Ｓ２のサービスユーザＩＤ「Ｕ１Ｓ２」がチェックインデータベースに記憶されているので、肯定応答が管理サーバ２１に送信される。

【0357】

管理サーバ２１は、決済代行サーバ４０からの応答に応じて支払端末３１－２から取得した判定要求に対する応答を送信する（Ｄ６）。管理サーバ２１は、チェックイン状況問合せに対する肯定応答を受信した場合に、判定応答に対する肯定応答を支払端末３１－２に送信する。

【0358】

利用者は、商品の対価を支払う。利用者がクレジットカード払い等を希望すると、支払端末３１－２は、当該利用者（利用者Ｕ１）のサービスユーザＩＤと決済情報を含む決済要求を管理サーバ２１に送信する（図４８のＥ１）。

【0359】

管理サーバ２１は、取得したサービスユーザＩＤと決済情報を含む決済代行要求を決済代行サーバ４０に送信する（Ｅ２）。

【0360】

決済代行サーバ４０は、チェックインデータベースを参照し、サービスユーザＩＤに対応する紐づけ情報を取得する。決済代行サーバ４０は、紐づけ情報から顧客ＩＤを特定する。決済代行サーバ４０は、顧客ＩＤから口座情報を特定する。決済代行サーバ４０は、特定された口座情報と取得した決済情報を用いて決済処理を実行する。

【0361】

決済代行サーバ４０は、決済処理の結果を管理サーバ２１に送信する（応答の送信；Ｅ３）。

【0362】

管理サーバ２１は、決済処理の結果を支払端末３１－１に送信する（応答の送信；Ｅ４）。

【0363】

利用者（利用者Ｕ１）は、ホテルをチェックアウトする。利用者は、主たるサービス提供者Ｓ１の受付端末３０－１を用いてチェックアウト手続きを行う。

【0364】

ホテル（主たるサービス提供者Ｓ１）の受付端末３０－１は、生体情報を含む「チェックアウト要求」を管理サーバ２０に送信する（Ｆ１）。

【0365】

管理サーバ２０は、生体情報とサービス提供者ＩＤを含む認証要求を認証サーバ１０に送信する（Ｆ２）。

【0366】

認証サーバ１０は、生体認証に成功すると、サービスユーザＩＤを含む肯定応答を管理サーバ２０に送信する（Ｆ３）。

【0367】

管理サーバ２０は、チェックアウトの可否を判定し、チェックアウト可の場合には、サービスユーザＩＤを含むチャックアウト通知を認証サーバ１０に送信する（Ｆ４）。

【0368】

当該通知に応じて、認証サーバ１０は、認証成功者に関する主従の関係にあるサービス提供者それぞれのサービスユーザＩＤを含む「チェックイン解除要求」を決済代行サーバ４０に送信する（Ｆ５）。

【0369】

決済代行サーバ４０は、チェックイン解除要求によって取得したサービスユーザＩＤに対応するチェックインデータベースのエントリを削除する。図４６の例では、利用者Ｕ１のサービスユーザＩＤ「Ｕ１Ｓ１」、「Ｕ１Ｓ２」を含むチェックイン解除要求を受信すると、決済代行サーバ４０は、１行目、２行目のエントリを削除する。

【0370】

決済代行サーバ４０は、エントリを削除するとその旨を認証サーバ１０に通知する（応答の送信；図４９のＦ６）。

【0371】

管理サーバ２０は、チェックアウト要求に対する応答を受付端末３０－１に送信する（Ｆ７）。

【0372】

このように、第３の実施形態では、認証サーバ１０は、第４の利用者に関するチェックイン通知を受信すると、第１のサービス提供者のサービスユーザＩＤと紐づけ情報を含むチェックイン登録要求を決済代行サーバ４０に送信する。さらに、認証サーバ１０は、第１のサービス提供者の紐づけ情報等に加え、第１のサービス提供者と提携関係にある第２のサービス提供者のサービスユーザＩＤと紐づけ情報を含むチェックイン登録要求を決済代行サーバ４０に送信する。第２のサービス提供者に設置された支払端末３１－２（第３の端末）は、第４の利用者が商品又はサービスを購入する際、第４の利用者の生体情報を含む判定要求を第２のサービス提供者の管理サーバ２１（第２の管理サーバ）に送信する。管理サーバ２１は、支払端末３１－２から判定要求を受信すると、決済代行サーバ４０に対して、認証サーバ１０から受信したサービスユーザＩＤを含むチェックイン状況問合せを送信する。決済代行サーバ４０は、チェックイン状況問合せに含まれるサービスユーザＩＤがチェックインデータベースに記憶されている場合、第４の利用者の商品購入を許可する肯定応答を管理サーバ２１に送信する。このような対応により、運営主体が異なるサービス提供者が同じ施設内に混在している場合であっても、ホテルの運営方針等が実現できる。また、第３の実施形態では、主たるサービス提供者（例えば、ホテルを経営する宿泊事業者）は、従たるサービス提供者（例えば、ホテルで経営するテナント店舗）の決済内容を把握することもできる。

【0373】

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

【0374】

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

【0375】

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

【0376】

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

【0377】

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

【0378】

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

【0379】

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

【0380】

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

【0381】

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

【0382】

決済代行サーバ４０は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで決済代行サーバ４０の機能が実現できる。また、決済代行サーバ４０は、当該プログラムにより決済代行サーバ４０の制御方法を実行する。

【0383】

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

【0384】

上記実施形態では、宿泊事業者とそのテナント店舗を例にとり本願開示のシステムを説明した。しかし、本願開示のサービス提供者は宿泊事業者に限定されない。例えば、イベントの主催者とイベント会場に出店する小売店等が上記説明したサービス提供者であってもよい。

【0385】

上記実施形態では、決済代行サーバ４０は、顧客ＩＤの生成に応じて紐づけ情報を生成することを説明した。決済代行サーバ４０は、当該生成した紐づけ情報を必要に応じて更新してもよい。例えば、認証サーバ１０や管理サーバ２０からの情報漏洩が疑われる場合等、決済代行サーバ４０は、システム管理者や利用者からの明示的な要求に応じて紐づけ情報を更新してもよい。この場合、システム管理者等は、更新前の紐づけ情報を決済代行サーバ４０に提供しつつ、当該紐づけ情報の更新を決済代行サーバ４０に依頼する。あるいは、利用者が認証サーバ１０や管理サーバ２０を介して紐づけ情報の更新を決済代行サーバ４０に要求してもよい。

【0386】

また、上述のように、認証サーバ１０は、サービスユーザＩＤを生成し、管理する。認証サーバ１０は、情報漏洩等が疑われる場合などに、当該生成したサービスユーザＩＤを更新してもよい。このように、本願開示では、紐づけ情報とサービスユーザＩＤをそれぞれ独立して更新可能であり、セキュリティ面の強化とシステム運用の効率化を両立している。

【0387】

上記実施形態では、認証システムは１つの決済代行サーバ４０を含む場合について説明した。しかし、認証システムは、複数の決済代行サーバ４０を含んでいてもよい。この場合、複数の決済代行サーバ４０それぞれに応じて、紐づけ情報が変化するように生成されればよい。

【0388】

第２の実施形態では、管理サーバ２０が顧客の紐づけ情報を保持する場合について説明した。その際、第２の実施形態で説明したように、管理サーバ２０から決済代行サーバ４０に口座情報登録要求が送信されるのではなく、認証サーバ１０から口座情報登録要求が送信されてもよい。即ち、第１の実施形態と同様に、利用者は、認証サーバ１０を介して口座情報を決済代行サーバ４０に入力する。決済代行サーバ４０は、サービス提供者ごと（サービス提供者ＩＤ又はサービスユーザＩＤごと）に顧客ＩＤ、紐づけ情報を生成する。決済代行サーバ４０は、生成した紐づけ情報を認証サーバ１０に送信する。認証サーバ１０は、取得した紐づけ情報を各サービス提供者（各管理サーバ２０）に送信する。

【0389】

上記実施形態では、決済代行サーバ４０は、顧客ＩＤ変換テーブルと紐づけ情報変換テーブルの２つを保持する場合について説明した。しかし、紐づけ情報変換テーブルは、外部装置（例えば、認証サーバ１０、管理サーバ２０）が保持していてもよい。この場合、認証サーバ１０等は、紐づけ情報を決済代行サーバ４０に送信することに代えて、紐づけ情報から得られる顧客ＩＤを決済代行サーバ４０に送信してもよい。即ち、認証センターが、利用者の顧客ＩＤを特定することで、決済代行サーバ４０におけるテーブル管理を低減することができる。

【0390】

上記実施形態では、紐づけ情報の生成は、処理日時と顧客ＩＤを用いて行われることを説明した。しかし、紐づけ情報は他の方法によって生成されてもよい。例えば、特定ビット長のバイナリ乱数を生成し、当該乱数からＢＡＳＥ６４エンコード等でＡＳＣＩＩ文字列に変換することで、紐づけ情報が生成されてもよい。

【0391】

上記実施形態では、利用者がユーザＩＤ、パスワードを決定し、当該ユーザＩＤ、パスワードを用いてシステムに登録された利用者（システム利用者）を特定することを説明した。しかし、認証システムが、システム利用者を一意に特定するＩＤ（識別子）を決定してもよい。例えば、利用者登録において、認証サーバ１０は利用者の生体情報（顔画像、特徴量）を取得する。認証サーバ１０は、当該生体情報に基づき上記ＩＤを生成してもよい。例えば、認証サーバ１０は、顔画像の特徴量からハッシュ値を計算し、当該計算されたハッシュ値を、ユーザＩＤ、パスワードの代わりとして用いてもよい。顔画像の特徴量は利用者ごとに異なり、当該特徴量から生成されたハッシュ値も利用者ごとに異なるため、システム利用者のＩＤとして用いることができる。

【0392】

上記実施形態では、利用者登録とサービス提供者登録が異なるタイミングで実行されることを説明したが、これらの登録は実質的に同タイミングにて実行されてもよい。例えば、利用者がサービスの提供を希望するサービス提供者に設置された端末３０が用いられ、上記２つの登録動作が実行されてもよい。具体的には、利用者は、端末３０を用いて利用者登録（生体情報、ユーザＩＤ、パスワードの入力）を行い、その後、連続して、サービス提供者登録（個人情報、ユーザＩＤ、パスワードの入力）を行ってもよい。この場合、端末３０は、認証サーバ１０の利用者登録機能（利用者登録部２０２）と管理サーバ２０の個人情報取得機能（個人情報取得部３０２）を備えればよい。

【0393】

上記実施形態では、１つのサービス提供者に１つのサービス提供者ＩＤを割り当てることを説明したが、複数のサービス提供者に対して１つのサービス提供者ＩＤが割り当てられてもよい。複数のサービス提供者をグループとしてまとめ、グループごとにサービス提供者ＩＤが発行されてもよい。例えば、サービス提供者Ｓ１とＳ２が連携し、同じサービスを提供するような場合には、これらのサービス提供者Ｓ１、Ｓ２に対して共通のサービス提供者ＩＤが発行されてもよい。

【0394】

上記実施形態では、管理サーバ２０から認証サーバ１０に「顔画像から生成された特徴量」に係る生体情報が送信される場合について説明した。しかし、管理サーバ２０から認証サーバ１０に「顔画像」に係る生体情報が送信されてもよい。この場合、認証サーバ１０は、取得した顔画像から特徴量を生成し、認証処理（照合処理）を実行すればよい。

【0395】

上記実施形態では、端末３０（受付端末３０－１、支払端末３０－２）が顔画像を取得し、管理サーバ２０が当該顔画像から特徴量を生成する場合について説明した。しかし、端末３０が顔画像から特徴量を生成し、当該生成した特徴量を管理サーバ２０に送信してもよい。即ち、管理サーバ２０が特徴量の生成を行わなくてもよい。

【0396】

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

【0397】

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

【0398】

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

【0399】

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、小売店等の顧客を認証する認証システムなどに好適に適用可能である。

【0400】

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
第１のサービス提供者に設置された、第１の端末及び第２の端末と、
前記第１及び第２の端末と接続された第１の管理サーバと、
利用者の生体情報と、前記利用者と前記第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する、認証サーバと、
を含み、
前記第１の管理サーバは、サービス利用予定者のサービス提供情報と前記サービスユーザＩＤを対応付けて記憶し、
前記第１の端末は、第１の利用者の生体情報を含むサービス利用開始手続き要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第１の利用者の生体情報を含む第１の認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第１の認証要求に応じて生体認証を実行し、認証に成功した場合、前記第１の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記第１の管理サーバは、前記通知されたサービスユーザＩＤに対応する前記サービス提供情報に基づいて前記第１の利用者のサービス利用開始手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶し、
前記第２の端末は、第２の利用者が商品又はサービスを購入する際、前記第２の利用者の生体情報を含む判定要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第２の利用者の生体情報を含む第２の認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第２の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第２の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記第１の管理サーバは、前記通知されたサービスユーザＩＤを用いて前記第２の利用者がサービス利用開始手続きを完了しているか否か判定し、前記第２の利用者がサービス利用開始手続きを完了している場合に、前記第２の利用者による前記商品又はサービスの購入を許可することを示す肯定応答を前記第２の端末に送信する、システム。
［付記２］
前記第１の端末は、第３の利用者の生体情報を含むサービス利用終了手続き要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第３の利用者の生体情報を含む第３の認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第３の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第３の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記第１の管理サーバは、前記通知されたサービスユーザＩＤを用いて、前記第３の利用者のサービス利用終了手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用終了手続きの結果を前記データベースに反映する、付記１に記載のシステム。
［付記３］
決済代行サーバをさらに含み、
前記第２の端末は、前記第２の利用者の決済情報を含む決済要求を前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記第２の利用者の前記決済情報を含む決済代行要求を前記決済代行サーバに送信し、
前記決済代行サーバは、
口座開設を希望する利用者から口座情報を取得し、前記利用者を識別するための顧客ＩＤを生成し、前記顧客ＩＤと前記口座情報を紐づけるための紐づけ情報を生成する、口座情報管理部と、
外部装置から取得した前記紐づけ情報に基づき前記顧客ＩＤを特定し、前記特定された顧客ＩＤに基づき前記口座情報を特定すると共に、前記特定された口座情報と前記決済代行要求に含まれる決済情報を用いて決済処理を行う、決済処理部と、
を備える、付記２に記載のシステム。
［付記４］
前記決済代行サーバは、
前記顧客ＩＤを前記口座情報に変換するための第１の変換テーブルと、
前記紐づけ情報を前記顧客ＩＤに変換するための第２の変換テーブルと、をさらに備え、
前記決済処理部は、
前記第２の変換テーブルを参照し、前記紐づけ情報から前記顧客ＩＤを取得し、
前記第１の変換テーブルを参照し、前記取得された顧客ＩＤから前記口座情報を取得する、付記３に記載のシステム。
［付記５］
前記第１の管理サーバは、前記第３の利用者のサービス利用料金を計算し、前記サービス利用終了手続きの結果と共に前記計算されたサービス利用料金を前記第１の端末に通知し、
前記第１の端末は、前記第３の利用者の前記サービス利用料金を前記決済情報とする前記決済要求を前記第１の管理サーバに送信する、付記３又は４に記載のシステム。
［付記６］
前記第１の管理サーバは、前記サービス利用終了手続きに成功した前記第３の利用者のエントリを前記データベースから削除する、付記２乃至５のいずれか一項に記載のシステム。
［付記７］
前記第１の管理サーバは、前記第２の端末から取得した前記決済情報を前記第１の端末から決済要求を受信するまで蓄積し、前記第１の端末から前記決済要求を受信すると、前記蓄積した決済情報と前記第１の端末から取得した前記決済情報を含む前記決済代行要求を前記決済代行サーバに送信する、付記５に記載のシステム。
［付記８］
前記口座情報管理部は、前記生成された紐づけ情報を前記認証サーバに送信し、
前記認証サーバは、
前記利用者の生体情報と、前記サービスユーザＩＤと、前記紐づけ情報と、を対応付けて記憶する、付記３に記載のシステム。
［付記９］
前記認証サーバは、前記生体認証により前記サービスユーザＩＤを特定し、前記特定したサービスユーザＩＤを前記第１の管理サーバに送信し、
前記第１の管理サーバは、前記決済要求を受信すると、前記サービスユーザＩＤを含む紐づけ情報送信要求を前記認証サーバに送信し、
前記認証サーバは、前記紐づけ情報送信要求に含まれるサービスユーザＩＤに対応する紐づけ情報を含む紐づけ情報通知と前記サービスユーザＩＤを前記決済代行サーバに送信し、
前記第１の管理サーバは、前記サービスユーザＩＤと前記決済情報を含む前記決済代行要求を前記決済代行サーバに送信し、
前記決済代行サーバは、前記サービスユーザＩＤが共通する前記紐づけ情報通知と前記決済代行要求を受信すると、前記決済処理を実行する、付記８に記載のシステム。
［付記１０］
前記第１の管理サーバは、前記第１の利用者がサービス利用開始可と判定された場合、前記第１の利用者の前記サービスユーザＩＤを含むサービス利用開始通知を前記認証サーバに送信し、
前記認証サーバは、前記サービス利用開始通知を受信すると、前記サービスユーザＩＤ及び対応する前記紐づけ情報を含むサービス利用開始登録要求を前記決済代行サーバに送信し、
前記決済代行サーバは、前記サービスユーザＩＤと紐づけ情報をサービス利用中データベースに対応付けて記憶し、
前記第１の管理サーバは、前記第２の端末から前記判定要求を受信すると、前記決済代行サーバに対して、前記認証サーバから受信した前記サービスユーザＩＤを含むサービス利用開始手続き状況問合せを送信し、
前記決済代行サーバは、前記サービス利用開始手続き状況問合せに含まれる前記サービスユーザＩＤが前記サービス利用中データベースに記憶されている場合、前記第２の利用者の商品購入を許可する肯定応答を前記第１の管理サーバに送信する、付記９に記載のシステム。
［付記１１］
前記認証サーバは、第４の利用者に関する前記サービス利用開始通知を受信すると、前記第１のサービス提供者の前記サービスユーザＩＤと紐づけ情報に加え、前記第１のサービス提供者と提携関係にある第２のサービス提供者の前記サービスユーザＩＤと紐づけ情報を含む前記サービス利用開始登録要求を前記決済代行サーバに送信し、
前記第２のサービス提供者に設置された第３の端末は、前記第４の利用者が商品又はサービスを購入する際、前記第４の利用者の生体情報を含む判定要求を前記第３の端末と接続された第２の管理サーバに送信し、
前記第２の管理サーバは、前記第３の端末から前記判定要求を受信すると、前記決済代行サーバに対して、前記認証サーバから受信した前記サービスユーザＩＤを含むサービス利用開始手続き状況問合せを送信し、
前記決済代行サーバは、前記サービス利用開始手続き状況問合せに含まれる前記サービスユーザＩＤが前記サービス利用中データベースに記憶されている場合、前記第４の利用者の商品購入を許可する肯定応答を前記第２の管理サーバに送信する、付記１０に記載のシステム。
［付記１２］
前記第３の端末は、前記第４の利用者の決済情報を含む決済要求を前記第２の管理サーバに送信し、
前記第２の管理サーバは、前記第４の利用者の前記決済情報を含む決済代行要求を前記決済代行サーバに送信する、付記１１に記載のシステム。
［付記１３］
前記生体情報は、顔画像又は前記顔画像から生成された特徴量である、付記１乃至１２のいずれか一項に記載のシステム。
［付記１４］
第１のサービス提供者に設置された、第１の端末及び第２の端末と、
前記第１及び第２の端末と接続された第１の管理サーバと、
利用者の生体情報と、前記利用者と前記第１のサービス提供者の組み合わせにより一意に定まるサービスユーザＩＤと、を対応付けて記憶する、認証サーバと、
を含むシステムにおいて、
サービス利用予定者のサービス提供情報と前記サービスユーザＩＤを対応付けて記憶し、
第１の利用者の生体情報を含むサービス利用開始手続き要求を前記第１の管理サーバに送信し、
前記第１の利用者の生体情報を含む第１の認証要求を前記認証サーバに送信し、
前記第１の認証要求に応じて生体認証を実行し、認証に成功した場合、前記第１の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記通知されたサービスユーザＩＤに対応する前記サービス提供情報に基づいて前記第１の利用者のサービス利用開始手続き可否を判定し、判定結果を前記第１の端末に送信すると共に、サービス利用開始手続きの結果をデータベースに記憶し、
第２の利用者が商品又はサービスを購入する際、前記第２の利用者の生体情報を含む判定要求を前記第１の管理サーバに送信し、
前記第２の利用者の生体情報を含む第２の認証要求を前記認証サーバに送信し、
前記第２の認証要求に応じて前記生体認証を実行し、認証に成功した場合、前記第２の利用者に対応する前記サービスユーザＩＤを前記第１の管理サーバに通知し、
前記通知されたサービスユーザＩＤを用いて前記第２の利用者がサービス利用開始手続きを完了しているか否か判定し、前記第２の利用者がサービス利用開始手続きを完了している場合に、前記第２の利用者による前記商品又はサービスの購入を許可することを示す肯定応答を前記第２の端末に送信する、方法。

【0401】

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

【符号の説明】

【0402】

１０、１０４ 認証サーバ
２０、２１、１０３ 管理サーバ
３０、３１ 端末
３０－１ 受付端末
３０－２、３１－２ 支払端末
４０ 決済代行サーバ
５０ 端末
１０１ 第１の端末
１０２ 第２の端末
２０１、３０１、４０１、４１１、５０１ 通信制御部
２０２ 利用者登録部
２０３、３０４ データベース管理部
２０４ サービス登録部
２０５ 口座情報登録部
２０６ 認証部
２０７ 紐づけ情報送信部
２０８、３０８、４０４、４１４、５０４ 記憶部
３０２ 個人情報取得部
３０３ サービス登録要求部
３０５ 要求処理部
３０６ 認証要求部
３０７ 決済代行要求部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０２、４１２ 生体情報取得部
４０３ サービス提供部
４１３ 販売制御部
５０２ 口座情報管理部
５０３ 決済処理部

【図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】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】