はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号(データ)の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
一実施形態に係るサーバ装置100は、管理部101と、処理部102と、を備える(図1参照)。管理部101は、複数の利用者それぞれの生体情報を記憶するデータベースを管理する。処理部102は、一連の手続きにおける最終段のゲート装置を含む複数の端末それぞれからの認証要求を、データベースを参照して処理する。管理部101は、認証に成功した第1の利用者がゲート装置を通過すると、データベースに記憶された第1の利用者のエントリを無効にする。
サーバ装置100は、最後のゲート装置を通過した利用者のエントリを無効にする。その結果、サーバ装置100が生体認証対象とするエントリの数が減少し、生体認証の精度が向上する。
以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。
[第1の実施形態]
第1の実施形態について、図面を用いてより詳細に説明する。
[システムの構成]
図2は、第1の実施形態に係る搭乗手続きシステムの概略構成の一例を示す図である。第1の実施形態に係る搭乗手続きシステムは、空港における一連の手続き(荷物預け入れ、セキュリティチェック等)を生体認証にて実現するシステムである。図2に示す搭乗手続きシステムは、例えば、入出国の管理局等の公的機関や当該公的機関から業務の委託を受けた受託者により運営される。
なお、本願開示において、「搭乗手続き」は、チェックインから航空機に搭乗するまでに行われる一連の手続きを示す。
図2を参照すると、搭乗手続きシステムには、チェックイン端末10、手荷物預け機11、旅客通過システム12、ゲート装置13、搭乗ゲート装置14と、サーバ装置20、が含まれる。
チェックイン端末10、手荷物預け機11、旅客通過システム12、ゲート装置13及び搭乗ゲート装置14は空港に設置された端末(タッチポイント)である。これらの端末は、ネットワークを介してサーバ装置20と接続されている。図2に示すネットワークは、空港の構内通信網を含むLAN(Local Area Network)、WAN(Wide Area Network)、移動体通信網等により構成されている。接続方式は、有線方式に限らず、無線方式でもよい。
サーバ装置20は、空港会社等の施設内に設置されている。あるいは、サーバ装置20はネットワーク上のクラウドに設置されたサーバであってもよい。
なお、図2に示す構成は例示であって、搭乗手続きシステムの構成を限定する趣旨ではない。搭乗手続きシステムには、図示していない端末等が含まれていてもよい。
利用者の搭乗手続きは、図2に示す各端末により行われる。具体的には、利用者が出国する際の一連の手続きは、5か所に設置された端末にて順次実施される。図2に示す搭乗手続きシステムでは、利用者の搭乗手続きは生体情報を用いた認証(生体認証)により実現される。
本願開示における生体情報は、顔画像、指紋画像、虹彩画像、指の静脈画像、掌紋画像、手のひらの静脈画像等である。生体情報は、1つであっても複数であってもよい。なお、本願開示における「生体情報」の文言は、生体の全部又は一部を含む画像及び当該画像から抽出される特徴量を意味するものとする。
生体認証による搭乗手続きを希望する利用者(システム利用者)は、空港に到着すると、チェックイン端末10を操作して「チェックイン手続き」を行う。システム利用者は、紙の航空券、搭乗情報が記載された二次元バーコード、eチケットの控えを表示する携帯端末等をチェックイン端末10に提示する。チェックイン端末10は、チェックイン手続きが終了すると、搭乗券を出力する。なお、搭乗券には、紙媒体の搭乗券と電子媒体の搭乗券が含まれる。
チェックイン手続きが終了した利用者であって、生体認証による搭乗手続きを希望するシステム利用者は、チェックイン端末10を用いてシステム登録を行う。具体的には、システム利用者は、取得した搭乗券とパスポートをチェックイン端末10に読み込ませる。また、チェックイン端末10は、システム利用者の生体情報(例えば、顔画像)を取得する。
チェックイン端末10は、これら(搭乗券、パスポート、生体情報)に関する情報をサーバ装置20に送信する。
サーバ装置20は、チェックイン端末10から取得した情報の正当性を確認する。具体的には、サーバ装置20は、提示されたパスポートの正当性を確認する。当該確認を終了すると、サーバ装置20はシステム利用者の登録を行う。具体的には、サーバ装置20は、当該システム登録された利用者の搭乗手続きに用いられるトークンを発行する。
発行されたトークンは、トークンID(Identifier)により識別される。搭乗手続きに必要な情報(例えば、生体情報、搭乗手続きに必要な業務情報等)はトークンIDを介して対応付けられる。即ち、「トークン」は、システム利用者の登録と共に発行され、当該登録されたシステム利用者が生体情報を利用した搭乗手続きを受けるための識別情報である。トークン(トークンID)が発行されると、システム利用者は、生体認証を用いた搭乗手続きを利用することができる。
トークンの生成に応じて、サーバ装置20は、トークンID情報データベースと業務情報データベースのそれぞれにエントリを追加する。
トークンID情報データベースは、生成されたトークンの詳細情報を記憶するデータベースである。当該データベースは、少なくともトークンIDと生体情報(顔画像、特徴量)を対応付けて記憶する。サーバ装置20は、トークンID情報データベースを参照し生体認証を実行する。
業務情報データベースは、業務情報を記憶するデータベースである。業務情報データベースは、トークンIDと業務情報を対応付けて記憶する。
トークンが発行されたシステム利用者が、端末(タッチポイント;例えば、手荷物預け機11等)に到着すると、当該端末にて生体情報(例えば、顔画像)が取得される。端末は、顔画像を含む認証要求をサーバ装置20に送信する。
サーバ装置20は、端末から取得した生体情報とシステム登録された生体情報を用いた照合処理(1対N照合;Nは正の整数、以下同じ)によりトークンIDを特定する。サーバ装置20は、当該特定されたトークンID及び業務情報を含む認証結果を端末に送信する。利用者の搭乗手続きは、当該業務情報に基づき実施される。
一連の搭乗手続きが終了し、利用者が出国すると(利用者が搭乗ゲート装置14を通過すると)、トークンIDは無効にされる。具体的には、サーバ装置20は、搭乗ゲート装置14を通過した利用者に対応するトークンIDのエントリを無効化する。
無効化されたエントリは、以後発生する認証処理(1対N照合処理)において参照されない。即ち、サーバ装置20は、トークンID情報データベースのエントリのうち無効にされていない有効なエントリを対象として照合処理を行う。
チェックイン端末10は、空港内のチェックインロビーに設置されている。上述のように、利用者は、チェックイン端末10を用いて生体認証を用いた搭乗手続きを実現するためのシステム登録を行う。また、システム利用者は、チェックイン端末10を操作してチェックイン手続きを行う。即ち、チェックイン端末10は、利用者が操作することによって、チェックイン手続を行うためのセルフ端末でもある。チェックイン端末10は、CUSS(Common Use Self Service)端末とも称される。利用者は、チェックイン手続を完了すると、手荷物の預け場所あるいは保安検査場へ移動する。
手荷物預け機11は、空港内の手荷物カウンタ(有人カウンタ)の隣接領域あるいはチェックイン端末10の近傍領域に設置されている。手荷物預け機11は、利用者が操作することにより、航空機内に持ち込まない手荷物を預ける手続(手荷物預け手続)を行うためのセルフ端末である。手荷物預け機11は、CUBD(Common Use Bag Drop)端末とも称される。利用者は、手荷物預け手続を完了すると、保安検査場へ移動する。なお、利用者が、手荷物を預けない場合には、手荷物預け手続は省略される。
旅客通過システム12は、空港内の保安検査場の入口に設置されているゲート装置である。旅客通過システム12は、PRS(Passenger Reconciliation System)とも称され、保安検査場の入口において利用者の通過可否を判定するシステムである。利用者は、旅客通過システム12を通過した後に保安検査手続を完了すると、出国審査場へ移動する。
ゲート装置13は、空港内の出国審査場に設置されている。ゲート装置13は、利用者の出国審査手続を自動的に行う装置である。利用者は、出国審査手続を完了すると、免税店や搭乗ゲートが設けられている出国エリアに移動する。
搭乗ゲート装置14は、出国エリアの搭乗ゲートごとに設置された通行制御装置である。
搭乗ゲート装置14は、出国審査(生体情報を用いた審査)の一連の手続きにおける最終段のゲート装置である。搭乗ゲート装置14は、ABG(Automated Boarding Gates)端末とも称される。搭乗ゲート装置14は、利用者が搭乗ゲートから搭乗可能な航空機の搭乗者であることを確認する。利用者は、搭乗ゲート装置14を通過すると、航空機に搭乗し、第2国へ向けて出国する。
なお、図2に示す各装置(チェックイン端末10、手荷物預け機11、旅客通過システム12、ゲート装置13、搭乗ゲート装置14)による生体認証を用いた搭乗手続きは一例であって、手続きに使用される装置を限定する趣旨ではない。例えば、上記装置とは異なる装置が搭乗手続きに使用されてもよいし、上記各装置のうち一部の装置が手続きに使用されてなくともよい。例えば、ゲート装置13が搭乗手続きシステムに含まれていなくともよい。
サーバ装置20は、上記搭乗手続きを支援、管理するためのサーバ装置である。サーバ装置20は、トークンIDを管理する。具体的には、サーバ装置20は、トークンIDの発行や無効化を行う。また、サーバ装置20は、空港内の各種端末からの認証要求を処理する。
続いて、第1の実施形態に係る搭乗手続きシステムに含まれる各装置の詳細について説明する。以降の説明では、生体情報として利用者の「顔画像」を例にとり説明を行う。
[チェックイン端末]
上述のように、チェックイン端末10は、システム利用者に対して、チェックイン手続とシステム登録に関する操作を提供する装置である。
図3は、第1の実施形態に係るチェックイン端末10の処理構成(処理モジュール)の一例を示す図である。図3を参照すると、チェックイン端末10は、通信制御部201と、システム登録部202と、トークン発行要求部203と、メッセージ出力部204と、チェックイン実行部205と、記憶部206と、を含む。
通信制御部201は、他の装置との間の通信を制御する手段である。例えば、通信制御部201は、サーバ装置20からデータ(パケット)を受信する。また、通信制御部201は、サーバ装置20に向けてデータを送信する。通信制御部201は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部201は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部201を介して他の装置とデータの送受信を行う。
システム登録部202は、生体認証による搭乗手続きを希望する利用者のシステム登録を行う手段である。例えば、システム登録部202は、チェックイン手続きの終了後に、利用者が「顔画像を用いた搭乗手続き」を希望するか否かを確認するためのGUI(Graphical User Interface)を当該利用者に提供する(図4参照)。
利用者が顔画像を用いた搭乗手続きを希望すると、システム登録部202は、3つの情報(搭乗券に記載された情報、パスポートに記載された情報、生体情報)を取得するためのGUIを用いて当該3つの情報を取得する。
システム登録部202は、3つのサブモジュールを備える。図5は、第1の実施形態に係るシステム登録部202の処理構成(処理モジュール)の一例を示す図である。図5に示すように、システム登録部202は、搭乗券情報取得部211と、パスポート情報取得部212と、生体情報取得部213と、を備える。
搭乗券情報取得部211は、システム利用者が所持する搭乗券に記載された情報(以下、搭乗券情報と表記する)を取得する手段である。搭乗券情報取得部211は、スキャナー等の読取機(図示せず)を制御し、搭乗券情報を取得する。
搭乗券情報には、氏名(姓、名)、エアラインコード、便名、搭乗日、出発地(搭乗空港)、目的地(到着空港)、シート番号、搭乗時間、到着時間等が含まれる。
パスポート情報取得部212は、システム利用者が所持するパスポートに記載された情報(以下、パスポート情報と表記する)を取得する手段である。パスポート情報取得部212は、スキャナー等の読取機を制御し、パスポート情報を取得する。
パスポート情報には、顔画像(以下、パスポート顔画像と表記する)、氏名、性別、国籍、パスポート番号、パスポート発行国等が含まれる。
生体情報取得部213は、システム利用者の生体情報を取得する手段である。生体情報取得部213は、カメラを制御し、システム利用者の顔画像を取得する。例えば、生体情報取得部213は、常時又は定期的に撮影する画像中に顔を検出すると、利用者の顔を撮影してその顔画像を取得する。
生体情報取得部213は、顔画像を撮影する前に、メッセージ出力部204を介して顔画像の撮影に関する案内メッセージを表示するのが望ましい。例えば、生体情報取得部213は、「お客様の顔画像を撮影し、システムに登録いたします。登録された顔画像は、搭乗完了後にシステムから削除されます」といったメッセージを表示する。
システム登録部202は、取得した3つの情報(搭乗券情報、パスポート情報、生体情報)をトークン発行要求部203に引き渡す。
図3に示すトークン発行要求部203は、サーバ装置20に対してトークンの発行を要求する手段である。トークン発行要求部203は、搭乗券情報、パスポート情報及び生体情報(顔画像)を含むトークン発行要求を生成する。例えば、トークン発行要求部203は、自装置の識別子(以下、チェックイン端末識別子と表記する)、上記搭乗券情報等を含むトークン発行要求を生成する(図6参照)。チェックイン端末識別子には、チェックイン端末10のMAC(Media Access Control)アドレスやIP(Internet Protocol)アドレスを用いることができる。トークン発行要求部203は、生成したトークン発行要求をサーバ装置20に送信する。
トークン発行要求部203は、サーバ装置20から取得した応答(トークン発行要求に対する応答)をメッセージ出力部204に引き渡す。
メッセージ出力部204は、種々のメッセージを出力する手段である。例えば、メッセージ出力部204は、サーバ装置20から取得した応答に応じたメッセージを出力する。
トークンの発行に成功した旨の応答(肯定応答)を受信した場合には、メッセージ出力部204は、その旨を出力する。例えば、メッセージ出力部204は、「今後の手続きは顔認証により行うことができます」といったメッセージを出力する。
トークンの発行に失敗した旨の応答(否定応答)を受信した場合には、メッセージ出力部204は、その旨を出力する。例えば、メッセージ出力部204は、「申し訳ありません。顔認証による手続きは行えません。有人のブースに向かってください」といったメッセージを出力する。
チェックイン実行部205は、利用者のチェックイン手続きを行う手段である。チェックイン実行部205は、利用者が提示した航空券に基づいて座席の選択等のチェックイン手続きを実行する。例えば、チェックイン実行部205は、航空券に記載された情報をDCS(Departure Control System)に送信し、当該DCSから搭乗券に記載する情報を取得する。なお、チェックイン実行部205の動作は既存のチェックイン端末の動作と同一とすることができるのでより詳細な説明を省略する。
記憶部206は、チェックイン端末10の動作に必要な情報を記憶する手段である。
[搭乗ゲート装置]
図7は、第1の実施形態に係る搭乗ゲート装置14の処理構成(処理モジュール)の一例を示す図である。図7を参照すると、搭乗ゲート装置14は、通信制御部301と、生体情報取得部302と、認証要求部303と、機能実現部304と、記憶部305と、を含む。
通信制御部301は、他の装置との間の通信を制御する手段である。例えば、通信制御部301は、サーバ装置20からデータ(パケット)を受信する。また、通信制御部301は、サーバ装置20に向けてデータを送信する。通信制御部301は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部301は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部301を介して他の装置とデータの送受信を行う。
生体情報取得部302は、カメラ(図示せず)を制御し、利用者の生体情報を取得する手段である。生体情報取得部302は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。生体情報取得部302は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。
なお、生体情報取得部302による顔画像の検出処理や顔画像の抽出処理には既存の技術を用いることができるので詳細な説明を省略する。例えば、生体情報取得部302は、CNN(Convolutional Neural Network)により学習された学習モデルを用いて、画像データの中から顔画像(顔領域)を抽出してもよい。あるいは、生体情報取得部302は、テンプレートマッチング等の手法を用いて顔画像を抽出してもよい。
生体情報取得部302は、抽出した顔画像を認証要求部303に引き渡す。
認証要求部303は、サーバ装置20に対して面前の利用者に関する認証を要求する手段である。認証要求部303は、自装置の識別子(以下、搭乗ゲート装置識別子と表記する)、上記取得した顔画像等を含む認証要求を生成する(図8参照)。搭乗ゲート装置識別子にはIPアドレス等を用いることができる。認証要求部303は、生成した認証要求をサーバ装置20に送信する。
認証要求部303は、認証要求に対するサーバ装置20からの応答を受信する。
認証要求部303は、認証結果が「認証失敗」であれば、その旨を訪問者に通知する。
認証要求部303は、認証結果が「認証成功」であれば、その旨を機能実現部304に通知する。また、認証要求部303は、サーバ装置20から取得したトークンID、業務情報を機能実現部304に引き渡す。
機能実現部304は、搭乗ゲート装置14の機能を実現する手段である。機能実現部304は、取得した業務情報から利用者(認証成功者)が搭乗可能な航空機の便番号を特定する。機能実現部304は、当該特定された便番号と自装置に割り当てられた便番号が一致する場合に、上記認証成功者のゲート通過を許可する。なお、機能実現部304の動作は既存の搭乗ゲート装置の動作と同一とすることができるので詳細な説明を省略する。また、当該搭乗ゲート装置14から搭乗する航空機の航空会社に勤務する職員が、搭乗ゲート装置14に必要な便番号を割り当て(入力)すればよい。
機能実現部304は、認証成功者のゲート通過を許可した場合には、その旨をサーバ装置20に通知する。具体的には、機能実現部304は、ゲートを通過した利用者のトークンIDを含む「ゲート通過通知」をサーバ装置20に送信する。
記憶部305は、搭乗ゲート装置14の動作に必要な情報を記憶する手段である。
[他の端末]
搭乗手続きシステムに含まれる他の端末(手荷物預け機11、旅客通過システム12、ゲート装置13)の基本的な処理構成は、図7に示す搭乗ゲート装置14の処理構成と同一とすることができるので詳細な説明を省略する。いずれの端末も、システム利用者の生体情報(顔画像)を取得し、当該取得した生体情報を用いた認証をサーバ装置20に要求する。認証に成功すると、各端末に割り当てられた機能が実行される。なお、ゲート装置13等は、上記ゲート通過通知に相当する情報をサーバ装置20に送信してもよいし送信しなくともよい。
[サーバ装置]
図9は、第1の実施形態に係るサーバ装置20の処理構成(処理モジュール)の一例を示す図である。図9を参照すると、サーバ装置20は、通信制御部401と、トークン生成部402と、データベース管理部403と、認証要求処理部404と、記憶部405と、を含む。
通信制御部401は、他の装置との間の通信を制御する手段である。例えば、通信制御部401は、チェックイン端末10からデータ(パケット)を受信する。また、通信制御部401は、チェックイン端末10に向けてデータを送信する。通信制御部401は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部401は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部401を介して他の装置とデータの送受信を行う。
トークン生成部402は、チェックイン端末10からのトークン生成要求に応じてトークンを生成する手段である。その際、トークン生成部402は、利用者が提示したパスポートの正当性に関する判定を行う。
具体的には、トークン生成部402は、チェックイン端末10にパスポートを提示した人物と、当該パスポートの発行を受けた人物と、が同一人物か否かを判定する。当該判定を実行するため、トークン生成部402は、トークン生成要求に含まれる顔画像(システム利用者の顔画像)とパスポート情報に含まれるパスポート顔画像を抽出する。トークン生成部402は、これら2つの顔画像が実質的に一致するか否かを判定する。
トークン生成部402は、上記2枚の顔画像の照合(1対1照合)を実行する。トークン生成部402は、2つの画像それぞれから特徴ベクトルを算出する。トークン生成部402は、当該2つの画像の類似度(例えば、ユークリッド距離)を算出し、当該算出した類似度に対する閾値処理の結果に基づき、2つの画像が同一人物の顔画像か否かを判定する。例えば、類似度が所定の値よりも大きければ(距離が所定の値よりも短ければ)、トークン生成部402は、2つの顔画像は同一人物によるものと判定する。
トークン生成部402は、生体情報を用いたパスポートの正当性判定に成功すると、トークンを発行する。例えば、トークン生成部402は、処理時の日時やシーケンス番号等に基づいて固有な値をトークンIDとして生成する。
トークン生成部402は、トークン(トークンID)を生成すると、チェックイン端末10に対して肯定応答(トークン発行)を送信する。トークン生成部402は、トークンIDの生成に失敗すると、チェックイン端末10に対して否定応答(トークン非発行)を送信する。
トークン生成部402は、トークンIDの生成(発行)に成功すると、生成したトークンID、搭乗券情報、パスポート情報、顔画像(システム利用者の顔画像)をデータベース管理部403に引き渡す。
データベース管理部403は、サーバ装置20に構築された各種データベースを管理する手段(管理部)である。
サーバ装置20は、トークンID情報データベースと業務情報データベースと、を備える。
トークンID情報データベースは、少なくともトークンIDと利用者の生体情報を対応付けて記憶する。図10は、トークンID情報データベースの一例を示す図である。図10を参照すると、トークンID情報データベースは、トークンID、登録顔画像、特徴量、トークン発行時刻、トークン発行デバイス名、無効フラグ及び無効化時刻等を記憶するフィールドを有する。
上述のように、トークンIDは一時的に発行される識別子である。利用者が搭乗ゲート装置14での手続きを終えると、当該トークンIDは無効にされる。即ち、トークンIDは、永続的に使用される識別子ではなく、有効期間(ライフサイクル)を有するワンタイムIDである。
登録顔画像は、システム利用者の顔画像である。例えば、登録顔画像は、チェックイン端末10が撮像した利用者の顔画像であってもよいし、パスポート顔画像であってもよい。特徴量は、顔画像から生成される特徴ベクトルである。トークン発行時刻は、サーバ装置20がトークンIDを発行した時刻である。デバイス名は、トークンIDの発行の契機となった登録顔画像の取得元のデバイス名(チェックイン端末10)である。
無効フラグは、トークンIDが現時点で有効であるか否かを示すフラグ情報である。無効フラグは、トークンIDが有効であれば「0」にクリアされ、無効であれば「1」にセットされる。無効化時刻は、トークンIDが無効にされたときのタイムスタンプである。
業務情報データベースは、利用者の搭乗手続きを行う際に必要な情報(業務情報)を管理するデータベースである。図11は、業務情報データベースの一例を示す図である。図11を参照すると、業務情報データベースは、トークンID、搭乗者名、出発地、目的地、エアラインコード、便番号、運行年月日等を記憶するフィールドを有する。業務情報データベースは、上記フィールドに加え、シート番号、国籍、旅券番号、姓、名、生年月日及び性別等を記憶するフィールドを有していてもよい。業務情報データベースは、所定の業務(各タッチポイントで行われる手続き業務)に関する業務情報をトークンIDごとに記憶している。
業務情報データベースに格納される上記情報は、搭乗券情報及びパスポート情報から取得される。
データベース管理部403は、トークン生成部402からトークンIDを取得すると(トークンIDが発行されると)、上記2つのデータベースに新規エントリを追加する。データベース管理部403は、各データベースのフィールドに設定値を設定する。例えば、データベース管理部403は、登録顔画像から特徴量を生成し、当該生成した特徴量をトークンID情報データベースに登録する。なお、設定値を設定できないフィールドに関しては、データベース管理部403は、初期値(デフォルト値)を設定してもよい。
データベース管理部403は、搭乗ゲート装置14からゲート通過通知を受信すると、当該通知に含まれるトークンIDを抽出する。データベース管理部403は、当該抽出されたトークンIDをキーとしてトークンID情報データベースを検索し、対応するエントリを特定する。データベース管理部403は、特定したエントリの無効フラグフィールドに「1」を設定し当該エントリを無効化する。データベース管理部403は、エントリを無効にした時刻を無効化時刻フィールドに設定する。図10の例では、2行目の「ID02」を持つエントリが無効化されている。
なお、業務情報データベースに関しては、トークンID情報データベースと同様に搭乗ゲート装置14を通過した利用者のエントリが無効化されてもよいし、無効化されてなくともよい。サーバ装置20の認証処理(照合処理)において、データベースの参照順序はトークンID情報データベースが先であり、業務情報データベースの状態(エントリが有効、無効)は認証処理に無関係なためである。
上記説明したように、データベース管理部403は、複数の利用者それぞれの生体情報を記憶するデータベース(トークンID情報データベース)を管理する。データベース管理部403は、認証に成功した利用者(第1の利用者)が搭乗ゲート装置14を通過すると、トークンID情報データベースに記憶された当該利用者のエントリを無効にする。より具体的には、データベース管理部403は、認証成功者が搭乗ゲート装置14を通過したことを示すゲート通過通知を搭乗ゲート装置14から受信した場合に、対応するエントリを無効にする。即ち、データベース管理部403は、利用者が搭乗ゲート装置14からゲート通過通知を受信したことにより当該利用者が搭乗ゲート装置14を通過したことを把握する。その後、データベース管理部403は、搭乗ゲート装置14を通過した利用者に対応するエントリを無効にする。
認証要求処理部404は、端末から取得する認証要求を処理する手段(処理部)である。認証要求処理部404は、一連の手続きにおける最終段の搭乗ゲート装置14を含む複数の端末それぞれからの認証要求を、トークンID情報データベースを参照して処理する。認証要求には、被認証者の生体情報が含まれる。認証要求処理部404は、認証要求に含まれる生体情報とトークンID情報データベースに含まれる生体情報を用いた照合処理(1対N照合)を実行する。
認証要求処理部404は、端末から取得した顔画像から特徴量を生成する。認証要求処理部404は、顔画像から特徴点を抽出する。なお、特徴点の抽出処理に関しては既存の技術を用いることができるのでその詳細な説明を省略する。例えば、認証要求処理部404は、顔画像から目、鼻、口等を特徴点として抽出する。その後、認証要求処理部404は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算し、複数の特徴量からなる特徴ベクトルを生成する。
認証要求処理部404は、当該生成した特徴量(特徴ベクトル)を照合側の特徴量、トークンID情報データベースに登録された特徴量であって有効な特徴量(無効化されていないエントリの特徴量)を登録側の特徴量にそれぞれ設定する。図10の例では、無効フラグに「0」が設定されている1行目、3行目のエントリに含まれる特徴量が登録側の特徴量として選択される。
認証要求処理部404は、照合側の特徴量と登録側の複数の特徴量それぞれとの間の類似度を計算する。当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。なお、距離が離れているほど類似度は低く、距離が近いほど類似度が高い。
認証要求処理部404は、トークンID情報データベースに登録された複数の特徴量(有効な特徴量)のうち、照合対象の特徴量との間の類似度が所定の値以上の特徴量が存在すれば認証に成功したと判断する。
認証に成功すると、認証要求処理部404は、類似度の最も高い特徴量に対応するトークンIDを特定する。認証要求処理部404は、特定されたトークンIDをキーとして業務情報データベースを検索し、対応するエントリを特定する。
認証要求処理部404は、認証結果を端末に送信する(認証要求に応答する)。認証に成功した場合には、認証要求処理部404は、その旨(認証成功)と上記業務情報データベースから特定されたエントリ(トークンID、業務情報)を含む応答を端末に送信する。認証に失敗した場合には、認証要求処理部404は、その旨(認証失敗)を含む応答を端末に送信する。
記憶部405は、サーバ装置20の動作に必要な各種情報を記憶する。記憶部405には、トークンID情報データベース、業務情報データベースが構築される。
[システム動作]
続いて、第1の実施形態に係る搭乗手続きシステムの動作を説明する。図12は、第1の実施形態に係る搭乗手続きシステムの動作の一例を示すシーケンス図である。図12を用いて利用者の認証処理を実行する際の動作を説明する。システム登録に関する動作の説明は省略する。
搭乗ゲート装置14は、利用者(被認証者)の顔画像を取得し、認証要求をサーバ装置20に送信する(ステップS01)。
サーバ装置20は、認証要求に含まれる顔画像から特徴量を生成し、トークンID情報データベースを用いた認証処理を実行する(ステップS02)。その際、サーバ装置20は、トークンID情報データベースに記憶された特徴量のうち、無効フラグフィールドに「0」が設定されたエントリの特徴量(有効な特徴量)を登録側に設定する。
認証に成功すると(ステップS03、Yes分岐)、サーバ装置20は、照合処理により得られたトークンIDをキーとして業務情報データベースを検索(ステップS04)する。
認証に失敗すると(ステップS03、No分岐)、サーバ装置20は、ステップS05以降の処理を実行する。
サーバ装置20は、認証結果(認証成功、認証失敗)を搭乗ゲート装置14に送信する(ステップS05)。認証に成功した場合には、サーバ装置20は、ステップS04の検索にて特定されたエントリの内容(トークンID、業務情報)を含む応答を搭乗ゲート装置14に送信する。
認証結果を受信した搭乗ゲート装置14は、その内容に応じた処理を行う。認証成功を受信した場合は、搭乗ゲート装置14は、利用者(認証成功者)が航空機に搭乗する資格を有しているか否かを判定する(ステップS06)。具体的には、搭乗ゲート装置14は、自装置に割り当てられた便番号(フライトナンバー)と業務情報に含まれる便番号が一致するか否かを判定する。
なお、搭乗ゲート装置14は、認証要求をサーバ装置20に送信する際、自装置に割り当てられた便番号を当該認証要求に含めてもよい。サーバ装置20は、認証要求から抽出した便番号を使って利用者の搭乗可否を判定してもよい。即ち、便番号を用いた照合は搭乗ゲート装置14ではなく、サーバ装置20により行われてもよい。
利用者が航空機に搭乗可能と判定された場合(ステップS06、Yes分岐)、搭乗ゲート装置14は、ゲート通過通知をサーバ装置20に送信する(ステップS07)。
利用者が航空機に搭乗不可と判定された場合(ステップS06、No分岐)、搭乗ゲート装置14は、サーバ装置20に対して何らの動作を行わない。
ゲート通過通知を受信したサーバ装置20は、当該通知に含まれるトークンIDのエントリを無効化する(ステップS08)。サーバ装置20は、トークンID情報データベースの無効フラグフィールドに「1」を設定することで、搭乗ゲート装置14を通過した利用者のエントリ(トークンID)を無効にする。
トークンID情報データベースは、複数の利用者それぞれのエントリが無効か否かを示す無効フラグフィールドを含む。サーバ装置20のデータベース管理部403は、搭乗ゲート装置14からゲート通過通知を受信すると搭乗ゲート装置14を通過した利用者に対応する無効フラグフィールドにエントリが無効であることを示す値「1」をセットする。
以上のように、第1の実施形態では、一連の手続きにおける最終段の搭乗ゲート装置14を通過した利用者のエントリ(トークンID)を無効にする。その結果、サーバ装置20が認証処理の対象とするエントリの数が減少し、顔画像又は顔画像から生成された特徴量を用いた生体認証の精度が向上する。即ち、第1の実施形態に係る搭乗手続きシステムは、一連の生体認証手続きにおける最後の手続きが終了したことを契機として、当該最後の生体認証以降に参照されることのないエントリを無効にする。その結果、生体認証を記憶するデータベースのデータ量が削減され十分な認証精度を確保できる。また、検索対象となるエントリが減少するので、生体認証の処理速度も向上する。
[第2の実施形態]
続いて、第2の実施形態について図面を参照して詳細に説明する。
第1の実施形態では、搭乗ゲート装置14を通過した利用者に関しては、トークンID情報データベースのエントリを無効にすることで、当該データベースのデータ量を軽量化している。しかし、第1の実施形態による対応では、「他人受け入れ」に係る誤認証により正当な資格を持った利用者の認証に失敗するという問題が生じ得る。例えば、トークンID情報データベースに登録された利用者の中に似た顔を持つ人物が存在する場合に、上記問題が生じ得る可能性が高まる。
例えば、図13に示すように、トークンID情報データベースには5人の利用者A~Eに関する情報が登録されている場合を考える。なお、図13を含む図面において、利用者A~Eのそれぞれから生成されたトークンIDは、ID_A~ID_Eである。また、理解の容易のため、図13を含む図面に示すトークンID情報データベースでは一部のフィールドに関する記載を省略すると共に、照合側及び登録側の特徴量間の類似度を記載している。類似度フィールドの括弧書きは、照合側の特徴量を示す。
利用者Aが搭乗ゲート装置14に到着すると、利用者Aの特徴量Faと、データベースに登録された特徴量Fv11~Fv15のそれぞれとの間の類似度が計算される。例えば、図13(a)のように類似度が計算される。なお、図13を含む以降の図面において、類似度を便宜上10段階で表現し、認証成功と判断する閾値は「7」とする。図13(a)では、特徴量FaとFv11の間の類似度が「9」であり閾値よりも大きいので利用者Aの認証は成功する。
また、利用者A(トークンIDがID_A)が搭乗ゲート装置14を通過すると、当該利用者Aのエントリは無効化される(図13(b)の1行目参照)。なお、図13において無効とされたエントリは灰色に着色されている。
その後、利用者Bが搭乗ゲート装置14に到着すると、利用者Bの特徴量Fbと、データベースに登録された特徴量Fv12~Fv15のそれぞれとの間の類似度が計算される。例えば、図13(b)のように類似度が計算される。この場合、特徴量FbとFv13との間の類似度が「9」であり閾値よりも大きいので利用者Bの認証は成功する。また、最も類似度が高い特徴量を持つエントリは無効化される(図13(c)の3行目参照)。
ここで、利用者Bに対応するエントリは「ID_B」のエントリであり、図13(b)では他人受け入れの誤認証が発生している。即ち、特徴量Fbと特徴量Fv12の間の類似度と、特徴量Fbと特徴量Fv13の間の類似度は共に閾値よりも大きい。これらの類似度は近接し後者の方が、値が大きいため利用者Bは利用者Cと判定されている。利用者Bと利用者Cの顔が似ている場合、顔画像の撮影環境等の条件によっては、このような誤認証が稀に生じることがある。誤認証が生じた結果、上述のように、利用者Cのエントリは無効化される。
次に、利用者Cが搭乗ゲート装置14に到着すると、利用者Cの特徴量Fcと、データベースに登録された特徴量Fv12、Fv14、Fv15のそれぞれとの間の類似度が計算される。例えば、図13(c)のように類似度が計算される。この場合、閾値「7」を超える類似度は得られないので、利用者Cの認証は失敗する。
しかし、利用者CのトークンはトークンID情報データベースに登録されており、利用者Cの認証は成功するのが期待される結果である。第2の実施形態では、上記説明したような不都合を解消する搭乗手続きシステムについて説明する。
第2の実施形態に係る搭乗手続きシステムの構成は第1の実施形態と同一とすることができるので図2に相当する説明を省略する。また、第2の実施形態に係るサーバ装置20等の処理構成も第1の実施形態と同一とすることができるのでその説明を省略する。
以下、第1及び第2の実施形態の相違点について説明する。
サーバ装置20の認証要求処理部404は、複数の端末のうち一の端末(例えば、搭乗ゲート装置14)から既にエントリが無効にされている利用者(第1の利用者)とは異なる第2の利用者に関する認証要求を受信する。認証要求処理部404は、トークンID情報データベースに登録された特徴量のうち有効な特徴量を登録側の特徴量に設定し、照合処理を実行する。
認証に成功した場合、サーバ装置20は、第1の実施形態と同様にその後の処理を実行する。
認証に失敗した場合、認証要求処理部404は、トークンID情報データベースに登録された複数の特徴量それぞれを登録側の特徴量に設定し、照合処理を実行する。図13の例では、利用者Cの認証に失敗すると、認証要求処理部404は、無効フラグフィールドの設定に関わらず、特徴量Fv11~Fv15を登録側の特徴量に設定し、認証処理を実行する。即ち、認証要求処理部404は、第2の利用者に関する最初の認証に失敗した場合、先に無効にされたエントリを含めて当該第2の利用者に関する2回目の認証を行う。
被認証者(第2の利用者)がトークンID情報データベースに登録されていなければ、2回目の照合処理においても認証に失敗する。この場合、認証要求処理部404は、被認証者の認証結果を「認証失敗」に設定する。認証要求処理部404は、第2の利用者に関する2回目の認証に失敗した場合には、認証要求の送信元である端末に対して認証失敗を通知する。
しかし、被認証者がトークンID情報データベースに登録されていれば、2度目の照合処理において当該被認証者の認証は成功する。例えば、図13の例では、無効なエントリを含めて照合処理をした結果、図14に示すような結果が得られる。この場合、無効フラグが設定されていた利用者C本人のエントリも照合処理の対象となるので、類似度は閾値を超え、且つ、最も高い値が得られる。
最初の照合処理において認証に失敗し、2回目の照合処理において認証に成功したという事実は、既に他人受け入れのエラーが発生している可能性が高いことを示す。そこで、認証要求処理部404は、「他人受け入れ」の発生を外部に通知する。即ち、第2の利用者に関する2回目の認証に成功した場合には、認証要求処理部404は、当該第2の利用者に関する最初の認証前に誤認証が発生していることを示す「誤認証発生通知」を外部に送信する。
例えば、認証要求処理部404は、航空会社の職員が使用する端末(スマートフォン、タブレット、パーソナルコンピューター)に誤認証発生通知を送信する。誤認証発生通知は、先に発生した可能性のある誤認証に起因し認証に失敗した端末の識別情報(例えば、搭乗ゲート装置識別子)と、誤認証の関係者に関する情報と、を含む。
誤認証の関係者に関する情報として、先に誤認証された利用者の情報(先の例では利用者B)及び誤認証に起因して認証に失敗した利用者の情報(先の例では利用者C)の少なくとも一方が例示される。
なお、誤認証に起因して認証に失敗した利用者は、最初の認証に失敗し2回目の認証で成功した利用者である。先に誤認証された利用者は、2回目の照合処理において計算された類似度のうち2番目に類似度が高い利用者である。先の例では、利用者Bと利用者Cの顔が似ていることから誤認証が発生しているので、図14に示すように利用者Cの照合処理における利用者Bの類似度は高く計算される。従って、利用者Bが先に誤認証された利用者に相当する。
認証要求処理部404は、誤認証の関係者に関する情報として、該当する利用者の氏名、便番号、目的地等を航空会社の職員が使用する端末に送信する。なお、これらの情報はトークンIDをキーとして業務情報データベースを検索することで得られる。あるいは、認証要求処理部404は、誤認証の関係者に関する顔画像、国籍、年齢、性別、フライト情報等を「誤認証の関係者に関する情報」として航空会社の職員が使用する端末に送信してもよい。この場合、航空会社の職員が使用する端末は、図15に示すような表示を行ってもよい。
先の誤認証に起因して認証に失敗した利用者の情報に接した職員は、誤認証発生通知に含まれる端末の識別子により特定される端末(タッチポイント)に向かい当事者のパスポートや搭乗券等に基づき誤認証の発生有無を確かめる。また、職員等は、必要に応じてDCSに登録された情報の修正、再入力等を行う。
また、先に誤認証された利用者の情報に接した職員は、当該利用者の元(座席)に向かい手続きの再実施を依頼してもよい。この場合、職員は、端末を操作してサーバ装置20に登録された当該利用者のエントリを有効にしてもよい。あるいは、職員が、当該利用者のパスポート等を確認し、当該利用者が航空機への搭乗資格を有している場合には、DCSに登録された情報を修正してもよい。
最初の認証処理に失敗し、2回目の認証処理に成功した場合には、認証要求処理部404は、認証要求の送信元に対して「認証失敗」を通知してもよいし、「誤認証発生通知」を送信してもよい。
誤認証発生通知を受信した端末(タッチポイント)は、利用者に対して、その場で待機するように指示してもよいし、有人のブースに向かうように指示してもよい。あるいは、端末(タッチポイント)は、認証結果の調査中であることを利用者に通知してもよい。即ち、最初の認証処理にて認証に成功した場合に端末(タッチポイント)に表示されるメッセージと2回目の認証にて認証に成功した場合に端末に表示されるメッセージが異なっていてもよい。例えば、最初の認証処理で認証に成功した場合には、「認証に成功しました」といったメッセージが出力され、2回目の認証処理で認証に成功した場合には「調査中です」といったメッセージが出力されてもよい。即ち、認証要求処理部404は、利用者の最初の認証に成功した場合には、端末が認証成功のメッセージを表示できるように、当該端末に認証成功を通知する。さらに、認証要求処理部404は、当該利用者の2回目の認証に成功した場合には、当該端末が認証結果の調査中であることを示すメッセージを表示できるように、当該端末に誤認証発生通知を送信する。
第2の実施形態に係る認証要求処理部404の動作をまとめると図16に示すフローチャートのとおりとなる。
搭乗ゲート装置14等の端末(タッチポイント)から認証要求を受信すると、サーバ装置20は、トークンID情報データベースの有効なエントリを対象として最初の認証処理を実行する(第1の認証処理の実行;ステップS101)。
認証に成功すると(ステップS102、Yes分岐)、サーバ装置20は、認証成功をタッチポイントに送信する(ステップS103)。
認証に失敗すると(ステップS102、No分岐)、サーバ装置20は、2回目の認証処理を実行する(第2の認証処理の実行;ステップS104)。
2回目の認証に成功すると(ステップS105、Yes分岐)、サーバ装置20は、航空会社の職員等が使用する端末に誤認証発生通知を送信する(ステップS106)。
2回目の認証に失敗すると(ステップS105、No分岐)、サーバ装置20は、認証失敗をタッチポイントに送信する(ステップS107)。
以上のように、第2の実施形態に係る搭乗手続きシステムは、利用者の生体認証に失敗するとトークンID情報データベースの無効にされたエントリを有効なエントリとして扱い2回目の認証処理を実行する。2回目の認証処理でも利用者の生体認証に失敗すれば、当該利用者の認証要求は「認証失敗」で確定する。対して、2回目の認証処理で利用者の生体認証に成功すれば、既に行われた認証にエラーが発生している可能性が高いと判断される。そこで、サーバ装置20は、誤認証の関係者(誤認証された利用者、誤認証の結果により認証が失敗した利用者)の情報を航空会社の職員等に通知し、誤りの是正を要求する。その結果、先に生じた誤認証により、正当な資格を持つ利用者が拒否されるといった不都合を解消することができる。
[第3の実施形態]
続いて、第3の実施形態について図面を参照して詳細に説明する。
第2の実施形態では、サーバ装置20が無効にしたエントリを含めて2回目の照合処理を実行することで誤認証の発生を検出している。第3の実施形態では、エントリが無効にされた際、サーバ装置20がその旨を認証成功者(搭乗ゲート装置14の通過者)に通知することで誤認証発生を検出する場合について説明する。
図17は、第3の実施形態に係る搭乗手続きシステムの概略構成の一例を示す図である。図17に示すように、利用者は利用者端末30を所持している。利用者端末30には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置が例示される。
図18は、第3の実施形態に係る利用者端末30の処理構成(処理モジュール)の一例を示す図である。図18を参照すると、利用者端末30は、通信制御部501と、エントリ無効通知処理部502と、記憶部503と、を含む。
通信制御部501は、他の装置との間の通信を制御する手段である。例えば、通信制御部501は、サーバ装置20からデータ(パケット)を受信する。また、通信制御部501は、サーバ装置20に向けてデータを送信する。通信制御部501は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部501は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部501を介して他の装置とデータの送受信を行う。
エントリ無効通知処理部502の詳細は後述する。
記憶部503は、利用者端末30の動作に必要な情報を記憶する。
第3の実施形態に係るサーバ装置20等の処理構成は第1の実施形態と同一とすることができるのでその説明を省略する。
以下、第1乃至第3の実施形態の相違点について説明する。
第3の実施形態に係るトークンID情報データベースには、利用者の連絡先(例えば、利用者端末30が送受信可能なメールアドレス等)が登録されている。例えば、サーバ装置20は、当該連絡先を利用者のシステム登録時に取得する。
サーバ装置20のデータベース管理部403は、搭乗ゲート装置14からゲート通過通知を受信し、対応するエントリを無効にした際、当該無効にしたエントリの連絡先フィールドに記載された連絡先に「エントリ無効通知」を送信する。
エントリ無効通知処理部502は、当該通知を受信すると、例えば、「搭乗ゲート装置を通過したので顔認証による手続きが完了しました」といった内容のメッセージを表示する(図19参照)。利用者が真に搭乗ゲート装置14を通過していれば、上記メッセージに接したとしても利用者はなにも行動をする必要がない。当該利用者が不審に思う点はないからである。
対して、搭乗ゲート装置14を通過していない利用者が、上記メッセージに接すると、その内容は間違いであることを認識する。当該利用者は、搭乗ゲート装置14を通過しておらず、自身の搭乗手続きは完了していないためである。この場合、利用者は、「修正依頼」ボタンを押下する。
修正依頼ボタンが押下されると、エントリ無効通知処理部502は、サーバ装置20に対して「エントリ有効化要求」を送信する。
なお、データベース管理部403は、エントリ無効通知に手続き終了者の顔画像を含めてもよい。この場合、利用者端末30のエントリ無効通知処理部502は、図20に示すような表示を行うことができる。利用者は、表示された顔画像が自分の顔画像か確認することで、より的確に「修正依頼」ボタンを押下するか否かを判断できる。
当該エントリ有効化要求を受信したデータベース管理部403は、利用者端末30の送信元アドレス(連絡先)をキーとしてトークンID情報データベースを検索し、対応するエントリを特定する。データベース管理部403は、特定したエントリの無効フラグフィールドを「1」から「0」にクリアする。
一度無効にされたエントリが有効にされることで、搭乗手続きが完了していない利用者の認証に失敗することはない。
エントリ有効化要求に従いエントリを有効にした場合には、データベース管理部403は、その旨を航空会社の職員等に通知する。即ち、サーバ装置20は、他人受け入れによるエラー発生の可能性を航空会社等に通知する。具体的には、サーバ装置20は、エントリを有効にした乗客の氏名、便番号、顔画像等を航空会社の職員(職員が使用する端末)に通知する。航空会社の職員等は、上記情報(とりわけ、乗客の顔画像)を手掛かりに誤認証された利用者を特定する。航空会社の職員等は、該当する航空機の各乗客について、搭乗券、パスポート等を確認してDCS等の情報を修正する。
以上のように、第3の実施形態では、エントリが無効にされると、サーバ装置20がその旨を利用者(利用者端末30)に通知する。搭乗ゲート装置14を通過した覚えのない利用者が、無効にされたエントリを有効にすることで当該利用者を正しく認証することができる。また、サーバ装置20は、利用者からの通知に基づき誤認証発生の可能性を航空会社に通知するので、誤認証による誤りは正しく修正される。
続いて、搭乗手続きシステムを構成する各装置のハードウェアについて説明する。図21は、サーバ装置20のハードウェア構成の一例を示す図である。
サーバ装置20は、情報処理装置(所謂、コンピュータ)により構成可能であり、図21に例示する構成を備える。例えば、サーバ装置20は、プロセッサ311、メモリ312、入出力インターフェイス313及び通信インターフェイス314等を備える。上記プロセッサ311等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。
但し、図21に示す構成は、サーバ装置20のハードウェア構成を限定する趣旨ではない。サーバ装置20は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス313を備えていなくともよい。また、サーバ装置20に含まれるプロセッサ311等の数も図21の例示に限定する趣旨ではなく、例えば、複数のプロセッサ311がサーバ装置20に含まれていてもよい。
プロセッサ311は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、DSP(Digital Signal Processor)等のプログラマブルなデバイスである。あるいは、プロセッサ311は、FPGA(Field Programmable Gate Array)、ASIC(Application Specific Integrated Circuit)等のデバイスであってもよい。プロセッサ311は、オペレーティングシステム(OS;Operating System)を含む各種プログラムを実行する。
メモリ312は、RAM(Random Access Memory)、ROM(Read Only Memory)、HDD(Hard Disk Drive)、SSD(Solid State Drive)等である。メモリ312は、OSプログラム、アプリケーションプログラム、各種データを格納する。
入出力インターフェイス313は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
通信インターフェイス314は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス314は、NIC(Network Interface Card)等を備える。
サーバ装置20の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ312に格納されたプログラムをプロセッサ311が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント(non-transitory)なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。
なお、チェックイン端末10、搭乗ゲート装置14、利用者端末30等もサーバ装置20と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成はサーバ装置20と相違する点はないので説明を省略する。チェックイン端末10等は、カメラ等を備えていればよい。
サーバ装置20は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることでサーバ装置20の機能が実現できる。また、サーバ装置20は、当該プログラムによりサーバ装置の制御方法を実行する。
[変形例]
なお、上記実施形態にて説明した搭乗手続きシステムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。
上記実施形態では、利用者のチェックイン手続きの後にシステム登録がされることを説明したが、チェックイン手続きの前にシステム登録がなされてもよい。この場合、チェックイン手続きの前に搭乗券は発行されていないので、サーバ装置20は、搭乗券に替えて航空券の情報を用いてシステム登録すればよい。
上記実施形態では、チェックイン端末10にてシステム登録(生体認証を用いた搭乗手続きを実現するための登録)を行う場合について説明した。しかし、システム登録は、チェックイン端末10以外の装置、端末にて行われてもよい。例えば、システム登録専用の装置が空港に設置されてもよいし、手荷物預け機11、旅客通過システム12等の端末(タッチポイント)でシステム登録が行われてもよい。
上記実施形態では、一連の搭乗手続きが生体認証により行われる場合について説明したが、一部の手続きが生体認証により行われてもよい。例えば、図2において、手荷物預け機11にてシステム登録がされ、手荷物預け入れ以降の手続き(保安検査等)が生体認証により行われてもよい。換言するならば、一連の搭乗手続きのうち一部の手続きに関しては有人のブース等にて実施されてもよい。
上記実施形態では、サーバ装置20が2つのデータベースを備える場合について説明した。しかし、サーバ装置20に構築される、トークンID情報データベースや業務情報データベースは、サーバ装置20とは異なるデータベースサーバに構築されていてもよい。即ち、搭乗手続きシステムには、上記実施形態にて説明した各種手段(例えば、トークン生成手段)等が含まれていればよい。
上記実施形態では、認証要求には顔画像が含まれる場合について説明したが、認証要求には顔画像から生成された特徴量が含まれていてもよい。この場合、サーバ装置20は、認証要求から取り出した特徴量とトークンID情報データベースに登録された特徴量を用いて認証要求を処理すればよい。
サーバ装置20は、エントリが無効にされてから所定期間経過後に当該無効にされたエントリを削除してもよい。より具体的には、データベース管理部403は、トークンID情報データベースの無効化時刻フィールドを定期的に参照し、エントリの無効から所定期間(例えば、24時間)経過したエントリを削除してもよい。
第2の実施形態では、2回目の認証処理では、トークンID情報データベースに記憶されたエントリは有効、無効の区別なく照合対象とすることを説明した。しかし、2回目の認証処理では、既に無効にされたエントリに限り照合の対象としてもよい。最初の認証処理の結果(有効なエントリを対象とした類似度)と2回目の認証処理の結果(無効なエントリを対象とした類似度)が統合され、上記第2の実施形態で説明した2回目の認証結果(類似度;スコア)が算出されてもよい。図13(c)の例では、最初の認証処理において、2、4、5行目のエントリを対象とした類似度が計算され、2回目の認証処理において1、3行目のエントリを対象とした類似度が計算される。2度の認証処理により得られた類似度を統合すれば、図14に示す類似度が得られる。即ち、2回目の認証処理において無効にされたエントリを対象にした照合処理では、誤認証された利用者Bが特定されないため2度の認証処理により得られた類似度の統合が必要となる。
チェックイン端末10等とサーバ装置20の間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。搭乗券情報やパスポート情報には個人情報が含まれ、当該個人情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。
上記実施形態では、エントリを無効にする場合について説明したが、サーバ装置20は、エントリは無効にせず、且つ、認証処理(照合処理)にて計算された類似度(スコア)の履歴を記憶してもよい。サーバ装置20は、当該対応により、誤認証の発生を検出してもよい。具体的には、サーバ装置20は、認証処理の実行のたびに、類似度の履歴を確認する。その際、事後的に類似度の高い利用者の認証に成功した場合、サーバ装置20は、誤認証が発生した可能性が高いと判断する。この場合、サーバ装置20は、その旨及び類似度の履歴から特定された人物(先に誤認証された人物)の情報を航空会社の職員等に通知し、適切な対応を依頼する。
上記説明で用いた流れ図(フローチャート、シーケンス図)では、複数の工程(処理)が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。
上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。
上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、空港等における搭乗手続きシステムなどに好適に適用可能である。但し、本願開示の適用先は空港の手続きに限定されず、本願開示は複数の手続きを要するシステムに適用可能である。
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
[付記1]
複数の利用者それぞれの生体情報を記憶するデータベースを管理する、管理部と、
一連の手続きにおける最終段のゲート装置を含む複数の端末それぞれからの認証要求を、前記データベースを参照して処理する、処理部と、
を備え、
前記管理部は、認証に成功した第1の利用者が前記ゲート装置を通過すると、前記データベースに記憶された前記第1の利用者のエントリを無効にする、サーバ装置。
[付記2]
前記管理部は、前記第1の利用者が前記ゲート装置を通過したことを示すゲート通過通知を前記ゲート装置から受信したことにより前記第1の利用者が前記ゲート装置を通過したことを把握する、付記1に記載のサーバ装置。
[付記3]
前記データベースは、前記複数の利用者それぞれのエントリが無効か否かを示す無効フラグフィールドを含み、
前記管理部は、前記ゲート通過通知を受信すると前記第1の利用者に対応する前記無効フラグフィールドにエントリが無効であることを示す値をセットする、付記2に記載のサーバ装置。
[付記4]
前記処理部は、前記複数の端末のうち一の端末から第2の利用者に関する認証要求を受信し、前記第2の利用者に関する最初の認証に失敗した場合には、前記無効にされたエントリを含めて前記第2の利用者に関する2回目の認証を行う、付記1乃至3のいずれか一に記載のサーバ装置。
[付記5]
前記処理部は、前記第2の利用者に関する2回目の認証に成功した場合には、前記第2の利用者に関する最初の認証前に誤認証が発生していることを示す誤認証発生通知を外部に送信する、付記4に記載のサーバ装置。
[付記6]
前記誤認証発生通知は、前記第2の利用者に関する情報を含む、付記5に記載のサーバ装置。
[付記7]
前記ゲート装置が空港に設置されるABG(Automated Boarding Gates)端末である場合には、
前記誤認証発生通知は、前記第2の利用者の氏名、便番号を含む、付記6に記載のサーバ装置。
[付記8]
前記処理部は、前記第2の利用者に関する2回目の認証に失敗した場合には、前記一の端末に対して認証失敗を通知する、付記4乃至7のいずれか一に記載のサーバ装置。
[付記9]
前記生体情報は、顔画像又は顔画像から生成された特徴量である、付記1乃至8のいずれか一に記載のサーバ装置。
[付記10]
前記管理部は、
前記ゲート通過通知を受信した場合に、前記第1の利用者のエントリを無効にすると共に、前記第1の利用者が所持する利用者端末にエントリ無効通知を送信し、
前記利用者端末からエントリ有効化要求を受信すると、前記無効にされた第1の利用者のエントリを有効にする、付記2又は3に記載のサーバ装置。
[付記11]
前記処理部は、
前記第2の利用者の最初の認証に成功した場合には、前記一の端末が認証成功のメッセージを表示できるように、前記一の端末に認証成功を通知し、
前記第2の利用者の2回目の認証に成功した場合には、前記一の端末が認証結果の調査中であることを示すメッセージを表示できるように、前記一の端末に前記誤認証発生通知を送信する、付記5又は6に記載のサーバ装置。
[付記12]
一連の手続きにおける最終段のゲート装置を含む複数の端末と、
前記複数の端末と接続されたサーバ装置と、
を含み、
前記サーバ装置は、
複数の利用者それぞれの生体情報を記憶するデータベースを管理する、管理部と、
前記複数の端末それぞれからの認証要求を、前記データベースを参照して処理する、処理部と、
を備え、
前記管理部は、認証に成功した第1の利用者が前記ゲート装置を通過すると、前記データベースに記憶された前記第1の利用者のエントリを無効にする、システム。
[付記13]
複数の利用者それぞれの生体情報を記憶するデータベースを備えるサーバ装置において、
一連の手続きにおける最終段のゲート装置を含む複数の端末それぞれから認証要求を受信すると、前記データベースを参照して生体認証を実行し、
認証に成功した第1の利用者が前記ゲート装置を通過すると、前記データベースに記憶された前記第1の利用者のエントリを無効にする、サーバ装置の制御方法。
[付記14]
複数の利用者それぞれの生体情報を記憶するデータベースを備えるサーバ装置に搭載されたコンピュータに、
一連の手続きにおける最終段のゲート装置を含む複数の端末それぞれから認証要求を受信すると、前記データベースを参照して生体認証を実行する処理と、
認証に成功した第1の利用者が前記ゲート装置を通過すると、前記データベースに記憶された前記第1の利用者のエントリを無効にする処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。
なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。