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

Description

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

近年、生体情報を利用した各種サービスの普及が始まっている。例えば、空港内で行われる各種手続き（チェックイン、手荷物預け入れ等）やホテルのチェックイン等に顔認証が用いられている。

例えば、特許文献１には、民泊サービスシステムにおいて、モバイル端末で撮影した本人映像を利用して宿泊者の本人確認を行い、部屋の鍵の開錠を行う民泊管理サーバが開示されている。

特開２０１８－１０１２３５号公報

上述のように、生体認証を用いたサービスの普及が始まっている。ここで、生体認証を用いたサービスを受けるためには、利用者は、自身の生体情報（顔画像）を認証サーバ等に登録する必要がある。しかし、利用者は、どのような方法で生体情報を登録すればよいのかわからず、生体情報を用いたサービスの普及を阻害する要因の一つとなっている。

本開示は、利用者による生体情報の登録を容易とすることに寄与する、サーバ、システム、サーバの制御方法及び記憶媒体を提供することを主たる目的とする。

本開示の第１の視点によれば、利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得する、取得部と、前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する、予約管理部と、を備える、サーバが提供される。

本開示の第２の視点によれば、利用者が使用する端末と、生体情報を用いた生体認証を行う、認証サーバと、前記認証サーバと接続された、サーバと、を含み、前記サーバは、 前記端末から、前記生体認証を用いて提供されるサービスの予約に関する予約情報を取得する、取得部と、前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する、予約管理部と、を備える、システムが提供される。

本開示の第３の視点によれば、サーバにおいて、利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得し、前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する、サーバの制御方法が提供される。

本開示の第４の視点によれば、サーバに搭載されたコンピュータに、利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得する処理と、前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

本開示の各視点によれば、利用者による生体情報の登録を容易とすることに寄与する、サーバ、システム、サーバの制御方法及び記憶媒体が提供される。なお、本開示の効果は上記に限定されない。本開示により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

一実施形態の概要を説明するための図である。 第１の実施形態に係る認証システムの概略構成の一例を示す図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証システムの動作を説明するための図である。 第１の実施形態に係る認証サーバの処理構成の一例を示す図である。 第１の実施形態に係る認証情報データベースの一例を示す図である。 第１の実施形態に係るホテルサーバの処理構成の一例を示す図である。 第１の実施形態に係る予約情報データベースの一例を示す図である。 第１の実施形態に係る認証端末の処理構成の一例を示す図である。 第１の実施形態に係る端末の処理構成の一例を示す図である。 第１の実施形態に係る認証システムの動作の一例を示すフローチャートである。 第２の実施形態に係る認証システムの動作の一例を示すフローチャートである。 ホテルサーバのハードウェア構成の一例を示す図である。 本願開示の変形例に係る認証システムの概略構成の一例を示す図である。

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

一実施形態に係るサーバ１００は、取得部１０１と、予約管理部１０２と、を備える（図１参照）。取得部１０１は、利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得する。予約管理部１０２は、予約情報に基づいてサービスの予約を受け入れるか否か判定する。予約管理部１０２は、サービスの予約を受け入れる場合、生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を端末に送信する。

サーバ１００は、利用者の予約を受け付けると、生体認証に必要な情報を登録するためのアプリケーションに関する情報を利用者に通知する。利用者は、当該通知された情報（例えば、上記アプリケーションのダウンロードサイトに関するＵＲＬ）に従いアプリケーションを端末にインストールすることができる。即ち、利用者は、生体情報を登録するためのアプリケーションを探す必要がなく、容易に、生体情報を認証局に登録できる。

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

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

［システム構成］
図２は、第１の実施形態に係る認証システムの概略構成の一例を示す図である。図２を参照すると、認証システムには、認証センター、アプリケーション（ＡＰＰ；Application）ダウンロードサイト、複数のサービス事業者が含まれる。

サービス事業者は、生体認証を用いて利用者にサービスを提供する事業者である。以下、サービス事業者として宿泊事業者を例にとり説明を行う。

認証センターは、システムに参加する宿泊事業者（ホテル）に認証サービスを提供する。認証センターには、少なくとも１台以上の認証サーバ１０が設置されている。認証サーバ１０は、生体情報を用いた生体認証の認証局として動作する。認証サーバ１０は、認証センターの敷地に設置されたサーバであってもよいし、クラウド上に設置されたサーバであってもよい。

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

認証サーバ１０は、各ホテルから送信される「認証要求」を処理し、認証処理の結果を当該認証要求の送信元に返信する。

アプリケーションダウンロードサイトは、スマートフォンやパーソナルコンピュータ上で動作するアプリケーションを提供するサイトである。アプリケーションダウンロードサイトは、ＩＴ（Information Technology）企業により運営されていてもよいし、認証センターの運営主体により運営されていてもよい。

利用者は、アプリケーションダウンロードサイトにアクセスすることで、種々のアプリケーション（ソフトウェア）を入手することができる。

アプリケーションダウンロードサイトは、少なくとも１台以上のＷＥＢ（ウェブ）サーバ２０を備える。ＷＥＢサーバ２０は、種々のアプリケーションプログラムを記憶し、利用者が要求するアプリケーションプログラムのダウンロードを可能に構成されている。

図２に示されるホテルは、生体認証に対応したホテルである。具体的には、利用者は生体認証により特定され、宿泊サービス等の提供を受ける。

システムに参加する各ホテルは、ホテルサーバ３０と少なくとも１台以上の認証端末３１を備える。なお、認証システムに含まれる複数のホテルそれぞれの構成は同一することができる。そのため、以降の説明では、ホテルＡの構成について説明し、他のホテルの構成に関する説明を省略する。

ホテルサーバ３０は、宿泊事業者の業務全般を制御、管理するサーバである。例えば、ホテルサーバ３０は、利用者の宿泊予約に関する処理や、チェックイン、チェックアウトに関する処理を行う。

ホテルサーバ３０は、上記チェックイン等に係る機能に加え、利用者の生体認証に関する制御機能、管理機能を備える。

認証端末３１は、ホテルを訪れた利用者（宿泊客）のインターフェイスとなる装置である。利用者は、認証端末３１を介して種々のサービス提供を受ける。例えば、認証端末３１は、ホテルのロビー等に設置される。利用者は、認証端末３１を使ってチェックインやチェックアウトの手続き行う。あるいは、認証端末３１は、客室の前に設置され、各部屋への入退室の管理に使用されてもよい。

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

図２の構成は例示であって、本願開示の認証システムの構成等を限定する趣旨ではない。例えば、認証センターには２台以上の認証サーバ１０が含まれていてもよい。あるいは、各ホテルには少なくとも１台以上の認証端末３１が含まれればよい。あるいは、ホテルサーバ３０と認証端末３１の機能が統合され、当該統合された１台の装置により宿泊サービスが提供されてもよい。あるいは、各ホテルにおいて、図２に示すように１台のホテルサーバ３０に複数の認証端末３１が接続されていてもよいし、１台のホテルサーバ３０に１台の認証端末３１が接続されていてもよい。

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

［ホテルの予約］
ホテルの利用を希望する利用者は、端末４０を用いて事前にホテルの予約を行う（図３参照）。なお、端末４０には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ（パーソナルコンピュータ、ノートパソコン）等が例示される。

端末４０は、利用者の操作に応じて予約するホテルを選択可能とするＧＵＩ（Graphical User Interface）を表示する。例えば、端末４０は、図４に示すようなＧＵＩを表示し、利用者が予約を希望するホテルの情報を取得する。

端末４０は、利用者により選択されたホテルのホテルサーバ３０にアクセスする。例えば、図２に示すホテルＡの予約を行う場合には、端末４０は、ホテルサーバ３０にアクセスする。

利用者は、端末４０を操作してホテルサーバ３０に予約情報を入力する。具体的には、端末４０は、図５に示すようなＧＵＩを用いて、予約情報を取得する。予約情報には、氏名、住所、連絡先（電話番号、メールアドレス）、宿泊期間、客室の希望（客室の等級）等の情報が例示される。端末４０は、取得した予約情報をホテルサーバ３０に送信する。

このように、端末４０は、レジストレーションカードに記載するような氏名、住所等を含む予約情報をホテルサーバ３０に登録する。

ホテルサーバ３０は、取得した予約情報に基づいて、予約の受け入れ可否を判定する。具体的には、ホテルサーバ３０は、希望する宿泊期間の空き室状況等に基づいて、利用者の予約を受け入れるか否かを判定する。

利用者の予約を受け入れる場合には、ホテルサーバ３０は、利用者から取得した予約情報を予約情報データベースに記憶する（図３参照）。さらに、ホテルサーバ３０は、利用者が入力した連絡先に「予約完了通知」を送信する。より具体的には、ホテルサーバ３０は、利用者が使用する端末４０が受信可能なメールアドレスに予約完了メールを送信する。

利用者は、端末４０を用いて予約完了通知（予約完了メール）を受信する。

予約完了通知には、予約に関する詳細な情報（予約者の氏名、宿泊期間等）に加え、利用者登録アプリに関する情報が含まれる。

利用者登録アプリは、生体認証によりサービスを受けるために必要な情報（生体情報、利用者情報）を認証センターに登録するためのアプリケーションである。

利用者登録アプリに関する情報は、当該アプリを端末４０に導入（インストール）するための情報である。以降の説明において、利用者登録アプリに関する情報を「利用者登録アプリ導入情報」と表記する。

端末４０は、予約完了通知に基づく表示を生成し、利用者に提示する。例えば、端末４０は、図６に示すような表示を行う。

利用者は、表示された内容を確認する。また、利用者登録アプリのインストールを希望する場合には、利用者は、図６に表示された「インストール」ボタンを押下する。

［利用者登録アプリのインストール］
インストールボタンの押下を検出することで、端末４０は、利用者登録アプリのインストールに関する処理を実行する。

具体的には、端末４０は、利用者登録アプリ導入情報に基づいて、利用者登録アプリをインストールする。利用者登録アプリ導入情報には、利用者登録アプリを提供するダウンロードサイト（ランディングページ）の位置を示すＵＲＬ（Uniform Resource Locator）が例示される。

利用者が利用者登録アプリのインストールを選択すると、端末４０は、ホテルサーバ３０から通知されたＵＲＬにアクセスする。当該ＵＲＬは、ＷＥＢサーバ２０のダウンロードサイトのアドレスに対応するので、端末４０は、ＷＥＢサーバ２０から利用者登録アプリを取得できる。その後、端末４０は、利用者登録アプリをインストールする。

［利用者登録］
利用者登録アプリのインストールを完了すると、利用者は、生体認証によりサービスを受けるための手続きを行う。具体的には、利用者は、端末４０にインストールされた利用者登録アプリを起動する。利用者は、利用者登録アプリを用いて、ホテルを予約した利用者に関する情報（利用者情報、又は、予約者情報）を認証サーバ１０に入力する。

利用者情報として、利用者の氏名、住所、電話番号、性別、生年月日、メールアドレス、パスワード、生体情報（顔画像；顔写真、顔認証データ）、パスポート情報、領収書宛名等が例示される。利用者は、端末４０を操作し、予約したホテルに関する情報（ホテル情報；例えば、ホテルの名称）及び利用者情報（顔画像、氏名等）を認証サーバ１０に登録する（図７参照）。メールアドレス、パスワードはシステム利用者のアカウントにアクセスする際に必要な情報である。例えば、メールアドレスは会員ＩＤとして扱われる。なお、システム利用者のアカウント生成等は当業者にとって明らかであるので説明を省略する。

利用者登録アプリを起動すると、端末４０は、図８に示すようなＧＵＩを表示する。図８に示すようなＧＵＩに接した利用者は、端末４０を操作して、予約を完了したホテルを選択する。

ホテルが選択されると、端末４０は、図９に示すようなＧＵＩを表示する。利用者は、端末４０を操作し、利用者情報（氏名、住所、メールアドレス、顔画像等）を認証サーバ１０に登録する。なお、利用者が認証サーバ１０に登録する利用者情報には、認証システムにて利用者（予約者）を特定するための利用者特定情報が含まれるものとする。例えば、利用者特定情報として、予約者の氏名、メールアドレスが例示される。以下、登録されたメールアドレスを利用者特定情報として扱い説明する。

顔画像を取得した認証サーバ１０は、当該顔画像から特徴量（特徴ベクトル）を生成し、氏名、住所、メールアドレス、ホテルＩＤ等と対応付けて記憶する。認証サーバ１０は、生体情報（特徴量）、氏名、住所、メールアドレス、ホテルＩＤ等を対応付けて認証情報データベースに記憶する。

ホテルＩＤは、ホテル（宿泊事業者）を一意に識別する識別子である。ホテルＩＤは上述の事業者ＩＤに相当する。認証サーバ１０は、図８に示すＧＵＩにより利用者が選択したホテルのホテルＩＤと、氏名、住所、メールアドレス及び生体情報等を対応付けて記憶する。

［ホテルの利用］
利用者登録アプリを用いて利用者登録を終了すると、利用者は、予約したホテルから生体認証を用いたサービスの提供を受けることができる。ここでは、図１０を参照しつつ、利用者がホテルを訪れ、チェックイン手続きが生体認証により行われる場合について説明する。

利用者は、予約したホテルに設置された認証端末３１の前に移動する。

認証端末３１は、面前の利用者から生体情報を取得する。具体的には、認証端末３１は、利用者を撮像し、顔画像を取得する。認証端末３１は、取得した顔画像をホテルサーバ３０に送信する。

ホテルサーバ３０は、取得した顔画像から特徴量を生成する。ホテルサーバ３０は、当該生成した特徴量とホテルＩＤを含む認証要求を認証サーバ１０に送信する。

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

認証サーバ１０は、照合処理により特定された利用者が予約したホテルと被認証者（認証端末３１が生体情報を取得した利用者）が訪れたホテルが一致する場合に、認証成功と判定する。

換言すれば、認証サーバ１０は、照合処理により利用者が特定されない場合（認証情報データベースに被認証者の生体情報が記憶されていない場合）やホテルが一致しない場合（２つのホテルＩＤが不一致の場合）には、認証失敗と判定する。

認証サーバ１０は、認証に成功すると、被認証者の利用者特定情報（メールアドレス）を含む肯定応答をホテルサーバ３０に送信する。

認証サーバ１０は、認証に失敗すると、その旨を示す否定応答をホテルサーバ３０に送信する。

ホテルサーバ３０は、取得した利用者特定情報（メールアドレス）に基づき予約情報を特定する。ホテルサーバ３０は、特定した予約情報に基づき利用者のチェックイン手続きを行う。なお、図１０では、チェックイン手続きが生体認証により行われる場合について説明したが、チェックアウト手続きや客室の開錠、施錠の制御等が生体認証により行われてもよい。

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

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

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

利用者登録部２０２は、ホテル予約者の利用者登録を実現する手段である。利用者登録部２０２は、予約されたホテルに関するホテル情報（ホテル名）、ホテル予約者の生体情報（顔画像）、氏名、住所、メールアドレス等を取得する。

利用者登録部２０２は、利用者登録アプリが認証サーバ１０にアクセスしたことに応じて、利用者が予約先のホテルを選択可能とするＧＵＩや入力フォームを端末４０に表示する。例えば、利用者登録部２０２は、図８に示すようなＧＵＩを端末４０に表示する。

ＧＵＩを介して予約したホテルの情報を取得すると、利用者登録部２０２は、利用者の生体情報、氏名、住所、メールアドレス等を取得する。例えば、利用者登録部２０２は、上記情報を取得するためのＧＵＩや入力フォームを端末４０に表示する。例えば、利用者登録部２０２は、図９に示すようなＧＵＩを端末４０に表示する。

利用者登録部２０２は、例えば、図９に示すようなＧＵＩにより利用者情報（顔画像、氏名、住所、メールアドレス等）を取得すると、顔画像から特徴量（複数の特徴量からなる特徴ベクトル）を生成する。

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

利用者登録部２０２は、予約されたホテルの名称、予約者の氏名、住所、メールアドレス及び上記生成した特徴量等をデータベース管理部２０３に引き渡す。また、正しく利用者登録が行えた場合には、利用者登録部２０２は、肯定応答を端末４０に送信する。正しく利用者登録が行えない場合には、利用者登録部２０２は、否定応答を端末４０に送信する。例えば、利用者から取得した顔画像から所定の基準を満たした特徴量を抽出できない場合などに、否定応答が端末４０に送信される。

データベース管理部２０３は、認証情報データベースを管理する手段である。認証情報データベースは、氏名、住所、メールアドレス、利用者の生体情報（特徴量）、予約されたホテルのホテルＩＤ等を対応付けて記憶する。

データベース管理部２０３は、ホテルの名称とホテルＩＤを対応付けたテーブル情報を参照することで、ホテルＩＤを得ることができる。ホテルＩＤは、予めシステム管理者等が決定してもよいし、ホテルサーバ３０のＩＰ（Internet Protocol）アドレスやＭＡＣ（Media Access Control）アドレスがホテルＩＤとして用いられてもよい。

システム管理者は、上記テーブル情報（ホテル名称とホテルＩＤを対応付けたテーブル情報）を生成し、認証サーバ１０に登録する。ホテルＩＤは、各ホテルのホテルサーバ３０にも登録される。即ち、認証サーバ１０とホテルサーバ３０は、ホテルＩＤを共有する。

データベース管理部２０３は、利用者登録部２０２から上記情報（ホテルの名称、氏名、住所、メールアドレス、特徴量等）を取得した場合、認証情報データベースに新規エントリを追加する。例えば、利用者Ｕ１に関する上記情報を取得した場合には、データベース管理部２０３は、図１２の最下段に示されるエントリを追加する。

このように、認証情報データベースは、利用者が予約を行ったホテル（サービス事業者）の第１の事業者ＩＤ（第１のホテルＩＤ）、生体情報、氏名、住所、メールアドレス（利用者特定情報）等を対応付けて記憶する。

図１２に示す認証情報データベースは例示であって、認証情報データベースが記憶する情報を制限する趣旨ではない。例えば、認証用の特徴量に替えて顔画像が認証情報データベースに登録されていてもよい。即ち、認証の都度、認証情報データベースに登録された顔画像から特徴量が生成されてもよい。あるいは、認証情報データベースは、ホテルの予約を識別する予約ＩＤ等を記憶してもよい。

認証部２０４は、利用者の認証処理を行う手段である。認証部２０４は、ホテルサーバ３０から受信する認証要求を処理する。認証部２０４ｈは、認証要求に含まれる生体情報を用いて生体認証を行うと共に、認証に成功した場合には、認証成功者の利用者特定情報（メールアドレス）をホテルサーバ３０に通知する。

認証部２０４は、認証要求に含まれる特徴量とホテルＩＤを取り出す。即ち、ホテルサーバ３０は、自装置を管理する事業者（宿泊事業者）の第２の事業者ＩＤ（第２のホテルＩＤ）と被認証者の生体情報を含む認証要求を認証サーバ１０に送信するので、認証部２０４は、これらの情報を認証要求から取り出す。

認証部２０４は、認証要求から取り出した特徴量を照合側の特徴量、データベースに格納された特徴量を登録側の特徴量にそれぞれ設定し、１対Ｎ照合を実行する。具体的には、認証部２０４は、照合側と複数の登録側それぞれの特徴量との間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。

認証部２０４は、データベースに登録された複数の特徴量のうち、照合対象の特徴量との間の類似度が所定の値以上の特徴量が存在するか否か判定する。そのような特徴量が存在しない場合、認証部２０４は、認証に失敗したと判定する。

上記のような特徴量が存在する場合、認証部２０４は、最も類似度の高いエントリ（認証情報データベースのエントリ）を特定する。認証部２０４は、当該特定されたエントリのホテルＩＤフィールドからホテルＩＤを読み出す。

認証部２０４は、当該読み出したホテルＩＤと認証要求に含まれるホテルＩＤが一致するか否かを判定する。

上記データベースから読み出されたホテルＩＤと認証要求のホテルＩＤが一致しない場合、認証部２０４は、被認証者の認証に失敗したと判定する。例えば、利用者の生体情報は認証サーバ１０に登録されているが、当該利用者が予約をしていないホテルを訪問した場合など、ホテルＩＤが不一致となる。この場合、認証部２０４は、被認証者の認証に失敗したと判断する。

２つのホテルＩＤが一致した場合、認証部２０４は、被認証者の認証に成功したと判断する。このように、認証部２０４は、２つのホテルＩＤが一致し、且つ、認証要求に含まれる生体情報と端末４０から取得した生体情報（認証情報データベースに記憶された生体情報）を用いた照合処理に成功した場合に、生体認証に成功したと判定する。

認証部２０４は、認証結果をホテルサーバ３０に送信する。認証に失敗した場合には、認証部２０４は、その旨を示す否定応答をホテルサーバ３０に送信する。

認証に成功した場合には、認証部２０４は、認証成功者（認証に成功したと判定された被認証者）のメールアドレスを認証情報データベースから読み出し、当該メールアドレスを含む肯定応答をホテルサーバ３０に送信する。

記憶部２０５は、認証サーバ１０の動作に必要な情報を記憶する。記憶部２０５には、認証情報データベースが構築される。

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

通信制御部３０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部３０１は、認証サーバ１０からデータ（パケット）を受信する。また、通信制御部３０１は、認証サーバ１０に向けてデータを送信する。通信制御部３０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部３０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部３０１を介して他の装置とデータの送受信を行う。通信制御部３０１は、端末４０から、生体認証を用いて提供されるサービス（例えば、宿泊サービス）の予約に関する予約情報を取得する、取得部として機能する。あるいは、通信制御部３０１は、情報を受信する受信部、情報を送信する送信部として機能する。

予約管理部３０２は、利用者の予約情報を管理する手段である。端末４０からのアクセスに応じて、予約管理部３０２は、予約情報を取得するためのＧＵＩ、入力フォーム等を端末４０に表示する。

例えば、予約管理部３０２は、図５に示すようなＧＵＩを用いて予約情報を取得する。

予約管理部３０２は、取得した予約情報と、予約情報データベースに登録された予約情報に基づき、利用者の予約を受け入れるか否か判定する。例えば、利用者の宿泊希望日や希望客室に空きがあれば、予約管理部３０２は、予約を受け入れる。例えば、利用者の宿泊希望日や客室に空きがなければ、予約管理部３０２は、予約を拒否する。

予約を受け入れた場合、予約管理部３０２は、取得した予約情報を予約情報データベースに新規なエントリを追加する。

図１４は、予約情報データベースの一例を示す図である。図１４に示すように、予約情報データベースは、予約ＩＤ、予約者の個人情報（例えば、氏名、住所、メールアドレス）、宿泊期間、客室等を記憶するフィールドを含む。予約ＩＤは、予約情報データベースに新規なエントリが追加される際に採番される。利用者の予約情報は、予約ＩＤにより一意に識別される。

図１４に示す予約情報データベースは例示であって、予約情報データベースが記憶する情報を制限する趣旨ではない。例えば、チェックアウト時の精算処理に必要となるクレジット情報（利用者の銀行口座やクレジットカードの情報）が予約情報データベースに登録されていてもよい。

予約管理部３０２は、予約の審査結果（受入の可否）を端末４０に通知する。予約を拒否する場合には、予約管理部３０２は、その旨を端末４０に通知する。

予約を受け入れる場合には、予約管理部３０２は、利用者登録アプリ導入情報（ダウンロードサイトのＵＲＬ）を含む予約完了通知を端末４０に送信する。上述のように、利用者登録アプリ導入情報は、利用者登録アプリを端末４０にインストールに関する情報である。

なお、ホテルの従業員は、予め利用者登録アプリ導入情報（ＵＲＬ）をホテルサーバ３０に設定する。あるいは、予約管理部３０２は、定期的又は所定のタイミングでＷＥＢサーバ２０に利用者登録アプリのダウンロードサイトのＵＲＬを問い合わせてもよい。このような問い合わせによりＵＲＬを取得することで、予約管理部３０２は、最新の正しいＵＲＬを得ることができる。

上記説明したように、予約管理部３０２は、端末４０から取得した予約情報に基づいて利用者からのサービスの予約を受け入れるか否か判定する。サービスの予約を受け入れる場合、予約管理部３０２は、アプリケーションの導入情報（生体認証に必要な情報を登録するための利用者登録アプリケーションのインストールに関する導入情報）を含む予約完了通知を端末４０に送信する。

認証要求部３０３は、認証サーバ１０に対して利用者の認証を要求する手段である。

認証要求部３０３は、認証端末３１から生体情報（顔画像）を取得すると、当該顔画像から特徴量を生成する。認証要求部３０３は、生成した特徴量とホテルＩＤを含む認証要求を認証サーバ１０に送信する。

認証サーバ１０からの応答が「否定応答」の場合（認証失敗の場合）には、認証要求部３０３は、その旨を、認証端末３１を介して利用者に通知する。例えば、この場合、認証要求部３０３は、認証失敗者が有人のカウンターに向かうようなメッセージを認証端末３１から出力する。

認証サーバ１０からの応答が「肯定応答」の場合（認証成功の場合）には、認証要求部３０３は、認証サーバ１０からの応答に含まれる利用者特定情報（メールアドレス）を取り出す。認証要求部３０３は、当該取り出した利用者特定情報をサービス提供部３０４に引き渡す。

サービス提供部３０４は、利用者にサービスを提供する手段である。サービス提供部３０４は、認証要求部３０３から取得した利用者特定情報（メールアドレス）に基づいて、予約情報データベースに記憶された予約情報を特定する。

サービス提供部３０４は、特定した予約情報を用いて、チェックイン手続きやチェックアウト手続きを行う。あるいは、サービス提供部３０４は、客室（予約された客室）の開錠、施錠に係る制御を行ってもよい。なお、サービス提供部３０４によるチェックイン手続き等は、既存の処理と同様とすることができ、且つ、当業者にとって明らかであるので詳細な説明を省略する。

記憶部３０５は、ホテルサーバ３０の動作に必要な情報を記憶する。予約情報データベースは記憶部３０５に構築される。

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

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

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

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

生体情報取得部４０２は、抽出した顔画像をホテルサーバ３０に送信する。

メッセージ出力部４０３は、利用者に対して種々のメッセージを出力する手段である。例えば、メッセージ出力部４０３は、利用者の認証結果に関するメッセージや、サービス提供に関するメッセージを出力する。メッセージ出力部４０３は、液晶モニタ等の表示デバイスを用いてメッセージを表示してもよいし、スピーカー等の音響機器を用いて音声メッセージを再生してもよい。メッセージ出力部４０３は、出力するメッセージの内容をホテルサーバ３０から取得すればよい。

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

［端末］
図１６は、第１の実施形態に係る端末４０の処理構成（処理モジュール）の一例を示す図である。図１６を参照すると、端末４０は、通信制御部５０１と、予約部５０２と、登録部５０３と、記憶部５０４と、を備える。

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

予約部５０２は、ホテルの予約を行う手段である。予約部５０２は、利用者の操作に応じて、システムに参加しているホテルのリストを表示する（図４参照）。

利用者は、表示されたリストを参照し、予約したいホテルを選択する。予約部５０２は、予約先のホテルに関する情報（ホテルの名称）を取得する。

予約部５０２は、予約先のホテルが運営、管理するホテルのサーバにアクセスする。例えば、ホテルＡが予約先のホテルとして選択された場合には、予約部５０２はホテルサーバ３０にアクセスする。

予約部５０２は、ホテルサーバ３０と協働し、利用者から予約情報を取得する。例えば、予約部５０２は、図５に示すようなＧＵＩにより予約情報を取得する。予約部５０２は、取得した予約情報をホテルサーバ３０に送信する。

予約が受け入れられると、予約部５０２は、ホテルサーバ３０から予約完了通知（予約完了メール）を受信する。予約部５０２は、予約完了通知の内容を表示する（図６参照）。

図６に示すようなＧＵＩに接した利用者が、利用者登録アプリのインストールを希望すると、予約部５０２は、利用者登録アプリ導入情報（ダウンロードサイトのＵＲＬ）に従って当該アプリのダウンロードサイトにアクセスする。

予約部５０２は、アプリケーションダウンロードサイト（ＷＥＢサーバ２０）にアクセスし、利用者登録アプリを取得する。予約部５０２は、取得した利用者登録アプリをインストールする。

このように、予約部５０２は、利用者が利用者登録アプリのインストールを希望した場合、予約完了通知に含まれる当該アプリの導入情報を用いて利用者登録アプリケーションを取得し、インストールする。

登録部５０３は、生体認証によりサービスを受けるために必要な情報を認証サーバ１０に登録（入力）する手段である。登録部５０３は、利用者登録アプリが起動することにより動作を開始する。利用者登録アプリが起動されると、登録部５０３は、認証サーバ１０にアクセスする。

登録部５０３は、認証サーバ１０と協働して、利用者が予約したホテルのホテルＩＤ、生体情報（顔画像）、氏名、住所、メールアドレス等を取得する。

例えば、登録部５０３は、図８に示すようなＧＵＩを表示し、利用者が予約したホテルの情報を取得する。その後、登録部５０３は、図９に示すようなＧＵＩを表示し、生体情報、氏名、住所、メールアドレス等を取得する。

登録部５０３は、取得したホテル名称、生体情報、氏名、住所、メールアドレス等を認証サーバ１０に送信する。

登録部５０３は、認証サーバ１０からの応答（肯定応答、否定応答）に応じたメッセージ等を出力する。肯定応答を受信した場合には、登録部５０３は、利用者登録が正常に行われたことを利用者に通知する。否定応答を受信した場合には、登録部５０３は、利用者登録が正常に処理されなかったことを利用者に通知する。

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

［ＷＥＢサーバ］
ＷＥＢサーバ２０の処理構成は当業者にとって明らかであるので、その説明は省略する。ＷＥＢサーバ２０は、端末４０がダウンロードサイト（ダウンロードページ）にアクセスすると、利用者登録アプリを端末４０に送信するように構成されていればよい。

［システムの動作］
続いて、第１の実施形態に係る認証システムの動作について説明する。なお、動作の説明は、利用者に生体認証を用いたサービスを提供する場合について行う。ホテルの予約、利用者登録アプリのインストール等に関するシステム動作の説明は省略する。

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

認証端末３１は、利用者の顔画像（生体情報）を取得し、当該取得した顔画像をホテルサーバ３０に送信する（ステップＳ０１）。

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

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

認証サーバ１０は、認証要求に含まれる特徴量とホテルＩＤを用いた照合処理を実行し、対応するエントリを特定する。具体的には、認証サーバ１０は、認証要求に含まれる特徴量と認証情報データベースに登録された特徴量を用いた照合処理を実行する（ステップＳ０４）。

照合処理に成功すると（ステップＳ０５、Ｙｅｓ分岐）、認証サーバ１０は、照合処理により特定されたエントリのホテルＩＤと認証要求から取り出したホテルＩＤが一致するか否か判定する（ステップＳ０６）。

２つのホテルＩＤが一致すると（ステップＳ０６、Ｙｅｓ分岐）、認証サーバ１０は、認証に成功したと判断する（ステップＳ０７）。

照合処理に失敗した場合（ステップＳ０５、Ｎｏ分岐）や２つのホテルＩＤが一致しない場合（ステップＳ０６、Ｎｏ分岐）の場合には、認証サーバ１０は、認証に失敗したと判断する（ステップＳ０８）。

認証サーバ１０は、認証結果をホテルサーバ３０に送信する（ステップＳ０９）。認証成功を通知する場合には、認証サーバ１０は、被認証者を特定するための利用者特定情報（メールアドレス）を含む肯定応答をホテルサーバ３０に送信する。

認証に成功した場合には、ホテル（ホテルサーバ３０、認証端末３１）は、被認証者にサービスを提供する（ステップＳ１０）。

以上のように、第１の実施形態に係る認証システムでは、利用者がホテルの予約を完了すると、生体情報を登録するためのアプリケーション（利用者登録アプリ）に関する導入情報が利用者に通知される。利用者は、当該導入情報に従い、必要なアプリケーションを端末４０にインストールすることができる。即ち、利用者は、上記アプリケーションをネットワーク上で探したり、間違ったアプリケーションをインストールしたりすることがなくなる。

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

第１の実施形態では、認証サーバ１０に利用者登録をする際、利用者は、自身が予約したホテルをリストのなかから選択する必要がある。具体的には、利用者は、端末４０を操作して図８に示すＧＵＩから自ら予約したホテルを選択する必要がある。

第２の実施形態では、上記利用者による予約ホテルの選択を不要とする場合について説明する。即ち、第２の実施形態では、利用者が予約したホテルの情報を入力しなくとも、システムが当該利用者により予約されたホテルの情報を自動的に判別する場合について説明する。

第２の実施形態に係る認証システムの構成は、第１の実施形態に係る認証システムの構成と同一することができるので図２に相当する説明を省略する。また、第２の実施形態に係る認証サーバ１０、ＷＥＢサーバ２０、ホテルサーバ３０、認証端末３１、端末４０の処理構成は、第１の実施形態と同一とすることができるのでその説明を省略する。

以下、第１及び第２の実施形態の相違点について説明する。

第２の実施形態に係るホテルサーバ３０の予約管理部３０２は、利用者の予約を受け入れると、予約内容及び利用者登録アプリ導入情報に加え、自ホテルのホテルＩＤを含む予約完了通知を端末４０に送信する。

第２の実施形態に係る端末４０の登録部５０３は、認証サーバ１０にアクセスする際、ホテルサーバ３０から取得したホテルＩＤを認証サーバ１０に通知する。

第２の実施形態に係る認証サーバ１０の利用者登録部２０２は、取得したホテルＩＤを使って利用者登録を行う。即ち、利用者登録部２０２は、図８に示すようなＧＵＩを用いて予約ホテルの情報（予約ホテルのホテルＩＤ）を取得することなく、利用者の予約ホテルを知ることができる。

上記第２の実施形態に係る認証システムの動作をまとめると図１８に示すフローチャートの通りとなる。

端末４０は、予約情報をホテルサーバ３０に送信する（ステップＳ１１）。

ホテルサーバ３０は、利用者の予約を受け入れるか否かを判定する（ステップＳ１２）。

予約を受け入れる場合、ホテルサーバ３０は、ホテルＩＤを含む予約完了通知を端末４０に送信する（ステップＳ１３）。

利用者登録を行う際、端末４０は、ホテルＩＤを認証サーバ１０に送信する（ステップＳ２１）。また、端末４０は、利用者情報（氏名、顔画像等）を認証サーバ１０に送信する（ステップＳ２２）。

認証サーバ１０は、氏名、住所、メールアドレス、顔画像から生成された特徴量及びホテルＩＤ等を対応付けて記憶する（ステップＳ２３）。

認証サーバ１０は、利用者登録の結果を端末４０に送信する（ステップＳ２４）。

以上のように、第２の実施形態に係る認証システムでは、ホテルサーバ３０がホテルＩＤを利用者に通知するため、利用者は、利用者登録をする際に予約したホテルの情報を入力する必要がない。即ち、第２の実施形態に係る認証システムでは、利用者の利便性がより向上する。

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

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

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

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

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

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

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

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

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

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

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

上記実施形態では、認証サーバ１０が認証情報データベースを備え、ホテルサーバ３０が予約情報データベースを備える場合について説明した。しかし、これらのデータベースは、認証サーバ１０やホテルサーバ３０とは異なるデータベースサーバに構築されていてもよい。即ち、認証システムには、上記実施形態にて説明した各種手段（例えば、予約管理手段）が含まれていればよい。

上記実施形態では、ホテルを運営する宿泊事業者をサービス事業者として扱い認証システムの動作等を説明した。しかし、宿泊事業者は本願開示のサービス事業者の一例であり、サービス事業者は他の業種であってもよう。例えば、予約が必要な飲食店等が認証システムに参加していてもよい。あるいは、宿泊事業者、飲食店等の異なる業種のサービス事業者が認証システムに参加していてもよい。

ホテルサーバ３０から送信される予約完了通知（予約完了メール）には、利用者登録アプリ導入情報に替えて又は加えて、他のアプリケーションに関する導入情報が含まれていてもよい。例えば、利用者の健康情報（体表面温度、感染症に対するワクチン接種の有無等）を入力するためのアプリケーションに関する導入情報（ＵＲＬ）が予約完了メールに含まれていてもよい。利用者は、当該アプリを使って自身の健康情報を入力する。入力された健康情報は、予約ホテルのホテルサーバ３０に送信され、宿泊サービスの提供に利用される。例えば、ホテルサーバ３０は、ワクチンを接種しておらず体表面温度が高い利用者に関しては、認証に成功したとしてもチェックインを拒否する等の対応をしてもよい。

利用者に提供されるアプリケーションは、利用者（予約者）の属性に応じて変化してもよい。例えば、ホテルサーバ３０は、利用者の出身地域や国籍に応じて提供するアプリケーションを変えてもよい。例えば、ホテルサーバ３０は、外国人に対しては日本国に入国する際に必要となるアプリケーションの導入情報を予約管理通知に含めてもよい。例えば、感染症罹患者の追跡を可能とするようなアプリケーションの導入情報がホテル等の予約時に利用者に送信されてもよい。

あるいは、ホテルの立地に応じて利用者に提供されるアプリケーションが異なっていてもよい。例えば、ホテルＡの周辺の観光に便利なアプリケーションの導入情報がホテルＡから端末４０に送信され、ホテルＢの周辺の観光に便利な別のアプリケーションの導入情報がホテルＢから端末４０に送信されてもよい。

上記実施形態では、利用者は宿泊を希望するホテルを選んで予約情報を入力する場合について説明した。しかし、ホテルの予約を引き受ける予約センターが認証システムに含まれていてもよい（図２０参照）。予約センターは、宿泊事業者の組合等による運営されていてもよいし、旅行代理店のような民間企業により運営されていてもよい。利用者は、認証センターを介して図２に示すホテルの予約を行ってもよい。具体的には、利用者は、端末４０を使って、予約サーバ５０にアクセスする。利用者は、予約したいホテルや予約情報（予約者の氏名、宿泊期間等）を予約サーバ５０に入力する。予約サーバ５０は、取得した予約情報を利用者が選択したホテルのホテルサーバ３０に送信する。ホテルサーバ３０は、予約を受け入れるか否かを判定し、その結果を予約サーバ５０に送信する。予約サーバ５０は、利用者登録アプリ導入情報を含む予約完了通知を端末４０に送信する。予約サーバ５０をシステムに導入することで、利用者の予約情報が一元管理される。あるいは、ＷＥＢサーバ２０と予約サーバ５０の機能が統合されていてもよい。この場合、ＷＥＢサーバ２０の機能を含む予約サーバ５０は、利用者登録アプリのインストールファイル、実行ファイルを含む予約完了通知を端末４０に送信することもできる。

上記実施形態では、利用者登録アプリ導入情報として当該アプリを提供するダウンロードサイトのＵＲＬを用いる場合について説明した。しかし、ダウンロードサイトのＵＲＬは例示であって、利用者登録アプリ導入情報を限定する趣旨ではない。例えば、利用者登録アプリの名称が予約完了通知に含まれ、端末４０に送信されてもよい。端末４０は、利用者登録アプリの名称を表示する。利用者は、端末４０を操作し、当該名称をインターネット上の検索サイトに入力することで、当該アプリのダウンロードサイトにたどり着くような態様であってもよい。

上記実施形態で説明したＧＵＩの表示等は例示であって、利用者に提供するインターフェイスを限定する趣旨ではない。例えば、図６において、端末４０は、「インストール」ボタンに替えて、予約完了通知に含まれるＵＲＬをそのまま表示してもよい。この場合、端末４０は、利用者が表示されたＵＲＬにタッチする、クリックする等の操作を行ったことを契機に、ＵＲＬに示されるダウンロードサイトにアクセスしてもよい。

上記実施形態では、利用者が利用者登録アプリのインストールを希望した場合に、端末４０がダウンロードサイトにアクセスする場合について説明した。しかし、端末４０は、自装置に利用者登録アプリがインストールされていなければ、当該アプリを自動的に取得しインストールしてもよい。

ホテルサーバ３０は、予約が完了した利用者に対して、チェックイン用の２次元バーコード等を送信してもよい。即ち、本願開示のサービス事業者は、２次元バーコードを用いた認証と生体情報を用いた認証の両方に対応していてもよい。

上記実施形態では、予約者のメールアドレスを「利用者特定情報」として用いる場合について説明した。しかし、他の情報が利用者特定情報として用いられてもよい。例えば、パスポート番号や運転免許証番号が利用者特定情報として用いられてもよい。この場合、利用者は、ホテルの予約時にパスポート番号等をホテルサーバ３０に入力する。また、利用者登録時にも、利用者は、パスポート番号を認証サーバ１０に入力する。認証サーバ１０は、被認証者の認証に成功すると、パスポート番号を含む肯定応答をホテルサーバ３０に送信する。ホテルサーバ３０は、パスポート番号に基づいて被認証者（認証成功者）の予約情報を特定してもよい。

あるいは、ホテルサーバ３０は、予約完了通知を端末４０に送信する際、予約ＩＤを当該通知に含めてもよい。利用者は、利用者登録をする際、通知された予約ＩＤを認証サーバ１０に入力する。認証サーバ１０は、認証要求を処理した際の肯定応答に上記予約ＩＤを含めて送信してもよい。ホテルサーバ３０は、取得した予約ＩＤに基づいて利用者の予約情報を特定してもよい。

複数のＷＥＢサーバ２０がシステムに含まれる場合には、ホテルサーバ３０は、当該複数のＷＥＢサーバ２０に対応した複数のＵＲＬを予約完了通知に含めて端末４０に送信してもよい。あるいは、ホテルサーバ３０は、ＷＥＢサーバ２０側の負荷が分散するようにＵＲＬを選択し、当該選択したＵＲＬを含む予約完了通知を端末４０に送信してもよい。

認証サーバ１０は、同じ利用者から取得した利用者情報を再利用してもよい。つまり、利用者は、ホテルの予約のたびに生体情報、氏名等を認証サーバ１０に登録するのではなく、一度、認証サーバ１０に生体情報等を登録すれば上記情報の再入力を不要としてもよい。例えば、利用者登録アプリは、起動時に利用者の顔画像を取得し、認証サーバ１０に送信する。認証サーバ１０は、取得した顔画像と認証情報データベースに登録された特徴量を用いた認証処理を実行する。認証に成功した場合には、認証サーバ１０は、利用者から生体情報や氏名の入力を求めず、予約したホテルの情報を要求する。認証に失敗した場合には、認証サーバ１０は、上記実施形態で説明したように、予約したホテルの名称、生体情報、氏名等の入力を利用者（端末４０）に要求する。

認証サーバ１０やホテルサーバ３０は、利用者の身元を確認し、身元が確認できた利用者に限り利用者登録やホテルの予約を許可してもよい。この場合、端末４０は、ホテル予約時や利用者登録時に、利用者の顔画像と身元確認書類（例えば、パスポート、運転免許証）に記載された顔画像を取得し、認証サーバ１０、ホテルサーバ３０に送信する。認証サーバ１０、ホテルサーバ３０は、２枚の顔画像が実質的に同一人物の顔画像であると判定した場合（１対１照合に成功した場合）、利用者の身元確認に成功したと判定する。

上記実施形態では、認証サーバ１０からホテルサーバ３０に利用者特定情報（メールアドレス）が送信され、当該メールアドレスを用いてホテルを訪れた利用者が特定されることを説明した。しかし、認証に成功した場合、認証サーバ１０は、被認証者のレジストレーションカードに記載する情報をホテルサーバ３０に送信してもよい。具体的には、利用者は、ホテルの予約時に個人情報（氏名、メールアドレス等）をホテルサーバ３０に登録する。利用者は、利用者登録アプリを起動し、当該アプリにレジストレーションカードに記載される情報（会員情報；氏名、メールアドレス等を含む情報）を登録する。その際、ホテル予約時のメールアドレスと利用者登録アプリに登録されたメールアドレスが突合され紐づけされる。認証サーバ１０は、利用者登録アプリに登録された会員情報に基づきレジストレーションカードを生成する。予約者がホテルを訪れると、生体認証により訪問者が特定され、上記生成されたレジストレーションカードがホテルサーバ３０に送信される。ホテルサーバ３０は、受信したレジストレーションカードを記憶（登録）する。

上記実施形態では、認証サーバ１０は、ホテルサーバ３０からの認証要求を処理する際、照合処理に成功し、２つのホテルＩＤが一致している場合に、認証成功と判定している。しかし、認証サーバ１０は、ホテルＩＤを使用せずに、照合処理に成功（被認証者の生体情報が認証情報データベースに登録）されていることに応じて、認証成功と判定してもよい。例えば、システムに参加している宿泊事業者が１社の場合等はこのような対応であってもよい。

サービス事業者（宿泊事業者）が有する複数の認証端末３１は、同じ敷地や建物等に設置されていなくともよい。サービス事業者が共通すれば、各認証端末３１は空間的に離れて場所に設置されていてもよい。

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

上記実施形態では、認証端末３１が顔画像を取得し、ホテルサーバ３０が当該顔画像から特徴量を生成する場合について説明した。しかし、認証端末３１が顔画像から特徴量を生成し、当該生成した特徴量をホテルサーバ３０に送信してもよい。即ち、ホテルサーバ３０が特徴量の生成を行わなくてもよい。

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

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

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

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

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）を含む。さらに、非一時的なコンピュータ可読媒体の例は、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗを含む。さらに、非一時的なコンピュータ可読媒体の例は、半導体メモリを含む。半導体メモリは、例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得する、取得部と、
前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する、予約管理部と、
を備える、サーバ。
［付記２］
前記導入情報は、前記アプリケーションを提供するダウンロードサイトのＵＲＬ（Uniform Resource Locator）である、付記１に記載のサーバ。
［付記３］
前記アプリケーションは、前記生体認証を行う認証サーバに前記利用者の生体情報を登録することに用いられる、付記１又は２に記載のサーバ。
［付記４］
前記予約管理部は、前記サービスを提供する事業者を識別するための事業者ＩＤをさらに含む前記予約完了通知を前記端末に送信する、付記１乃至３のいずれか一に記載のサーバ。
［付記５］
前記生体認証を用いて提供されるサービスは宿泊事業者の宿泊サービスである、付記１乃至４のいずれか一に記載のサーバ。
［付記６］
利用者が使用する端末と、
生体情報を用いた生体認証を行う、認証サーバと、
前記認証サーバと接続された、サーバと、
を含み、
前記サーバは、
前記端末から、前記生体認証を用いて提供されるサービスの予約に関する予約情報を取得する、取得部と、
前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する、予約管理部と、
を備える、システム。
［付記７］
前記利用者が前記アプリケーションのインストールを希望した場合、前記端末は、前記予約完了通知に含まれる導入情報を用いて前記アプリケーションを取得する、付記６に記載のシステム。
［付記８］
前記アプリケーションが起動されると、前記端末は、前記認証サーバにアクセスし、
前記認証サーバは、前記端末から、前記利用者の生体情報と前記利用者を特定するための利用者特定情報を取得する、付記６又は７に記載のシステム。
［付記９］
前記サーバは、被認証者の生体情報を含む認証要求を前記認証サーバに送信し、
前記認証サーバは、前記認証要求に含まれる生体情報を用いて前記生体認証を行うと共に、認証に成功した場合には、前記利用者特定情報を前記サーバに通知し、
前記サーバは、前記通知された利用者特定情報を用いて前記サービスを予約した利用者の前記予約情報を特定する、付記８に記載のシステム。
［付記１０］
前記認証サーバは、前記利用者が予約を行った事業者の第１の事業者ＩＤ、前記生体情報及び前記利用者特定情報を対応付けて記憶し、
前記サーバは、自装置を管理する事業者の第２の事業者ＩＤをさらに含む前記認証要求を前記認証サーバに送信し、
前記認証サーバは、前記第１及び第２の事業者ＩＤが一致し、且つ、前記認証要求に含まれる生体情報と前記端末から取得した生体情報を用いた照合処理に成功した場合に、前記生体認証に成功したと判定する、付記９に記載のシステム。
［付記１１］
前記利用者特定情報は、前記サービスの予約を行った利用者のメールアドレスである、付記６乃至１０のいずれか一に記載のシステム。
［付記１２］
前記生体情報は、顔画像又は前記顔画像から生成された特徴量である、付記６乃至１１のいずれか一項に記載のシステム。
［付記１３］
サーバにおいて、
利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得し、
前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する、サーバの制御方法。
［付記１４］
サーバに搭載されたコンピュータに、
利用者の端末から、生体認証を用いて提供されるサービスの予約に関する予約情報を取得する処理と、
前記予約情報に基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証に必要な情報を登録するためのアプリケーションのインストールに関する導入情報を含む予約完了通知を前記端末に送信する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。

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

１０ 認証サーバ
２０ ＷＥＢサーバ
３０ ホテルサーバ
３１ 認証端末
４０ 端末
５０ 予約サーバ
１００ サーバ
１０１ 取得部
１０２、３０２ 予約管理部
２０１、３０１、４０１、５０１ 通信制御部
２０２ 利用者登録部
２０３ ＤＢ（Data Base）管理部
２０４ 認証部
２０５、３０５、４０４、５０４ 記憶部
３０３ 認証要求部
３０４ サービス提供部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス
４０２ 生体情報取得部
４０３ メッセージ出力部
５０２ 予約
５０３ 登録部

Claims (19)

1. 利用者の端末から、生体認証を用いて提供されるサービスの予約に関する第１の予約情報を取得する、取得部と、
   前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を前記端末に送信する、予約管理部と、を備える、サーバ。
2. 前記利用者の生体情報の登録を促す情報は、前記生体認証に必要な情報を登録するためのアプリケーションを提供するダウンロードサイトのＵＲＬ（Uniform Resource Locator）である、請求項１に記載のサーバ。
3. 前記予約管理部は、前記サービスを提供する事業者を識別するための事業者ＩＤをさらに含む前記予約完了通知を前記端末に送信する、請求項１又は２に記載のサーバ。
4. 前記生体認証を用いて提供されるサービスは宿泊事業者の宿泊サービスである、請求項１乃至３のいずれか一項に記載のサーバ。
5. 前記予約完了通知を二次元コードで前記端末に送信する請求項１乃至４のいずれか一項に記載のサーバ。
6. 利用者が使用する端末と、
   生体情報を用いた生体認証を行う、認証サーバと、
   前記認証サーバと接続された、サーバと、
   を含み、
   前記サーバは、
   前記端末から、生体認証を用いて提供されるサービスの予約に関する第１の予約情報を取得する、取得部と、
   前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を前記端末に送信する、予約管理部と、
   を備える、システム。
7. 前記利用者の生体情報の登録を促す情報は、前記生体認証に必要な情報を登録するためのアプリケーションを提供するダウンロードサイトのＵＲＬ（Uniform Resource Locator）である、請求項６に記載のシステム。
8. 前記予約管理部は、前記サービスを提供する事業者を識別するための事業者ＩＤをさらに含む前記予約完了通知を前記端末に送信する、請求項６又は７に記載のシステム。
9. 前記生体認証を用いて提供されるサービスは宿泊事業者の宿泊サービスである、請求項６乃至８のいずれか１項に記載のシステム。
10. 前記予約完了通知を二次元コードで前記端末に送信する、請求項６乃至９のいずれか１項に記載のシステム。
11. サーバにおいて、
    利用者の端末から、生体認証を用いて提供されるサービスの予約に関する第１の予約情報を取得し、
    前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を前記端末に送信する、サーバの制御方法。
12. サーバに搭載されたコンピュータに、
    利用者の端末から、生体認証を用いて提供されるサービスの予約に関する第１の予約情報を取得する処理と、
    前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れるか否か判定し、前記サービスの予約を受け入れる場合、前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を前記端末に送信する処理と、
    を実行させるためのプログラム。
13. 生体認証を用いて提供されるサービスの予約に関する第１の予約情報をサーバに送信する送信部と、
    前記サーバが前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れると判定した場合、前記サーバから前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を受信する受信部と、を備える、端末。
14. 前記利用者の生体情報の登録を促す情報は、前記生体認証に必要な情報を登録するためのアプリケーションを提供するダウンロードサイトのＵＲＬ（Uniform Resource Locator）である、請求項１３に記載の端末。
15. 前記受信部は、前記サーバから前記サービスを提供する事業者を識別するための事業者ＩＤをさらに含む前記予約完了通知を受信する、請求項１３又は１４に記載の端末。
16. 前記生体認証を用いて提供されるサービスは宿泊事業者の宿泊サービスである、請求項１３乃至１５のいずれか１項に記載の端末。
17. 前記受信部は、前記サーバから前記予約完了通知を二次元コードで受信する請求項１３乃至１６のいずれか１項に記載の端末。
18. 生体認証を用いて提供されるサービスの予約に関する第１の予約情報をサーバに送信し、
    前記サーバが前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れると判定した場合、前記サーバから前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を受信する、端末の制御方法。
19. 端末に搭載されたコンピュータに、
    生体認証を用いて提供されるサービスの予約に関する第１の予約情報をサーバに送信する処理と、
    前記サーバが前記第１の予約情報と、予約情報データベースに登録された既に予約を受け入れられた利用者の第２の予約情報とに基づいて前記サービスの予約を受け入れると判定した場合、前記サーバから前記生体認証を行う認証サーバに前記利用者の生体情報の登録を促す情報を含む予約完了通知を受信する処理と、を実行させるプログラム。

Images