はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号(データ)の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。
一実施形態に係るシステムは、共用サーバ101と、専用サーバ102と、制御サーバ103と、を含む(図1参照)。共用サーバ101は、複数の空港によって認証処理を行うサーバとして共用される。専用サーバ102は、1つの空港における認証処理を行う。制御サーバ103は、利用者が利用する空港を判定する(利用空港を判定;図2のステップS1)。制御サーバ103は、当該利用者が利用する空港に応じて、搭乗手続きを生体認証により進めるために必要な情報を共用サーバ101又は専用サーバ102のいずれかに送信する(搭乗手続き情報を送信;ステップS2)。
上記システムには、複数の空港会社等により共用される、クラウド等に設置された共用サーバ101と、空港会社等が自社で運用する専用サーバ102と、が含まれる。利用者は、搭乗手続きを生体認証により進めようとする場合、空港における搭乗手続きを生体認証により進めるための情報(搭乗手続き情報)をサーバに登録する必要がある。その際、利用者は、利用空港が採用するサーバの方式を意識することなく、当該搭乗手続き情報を制御サーバ103に送信すればよい。制御サーバ103が、利用者の利用空港を判定し、当該利用空港が用いるサーバ(共用サーバ101、専用サーバ102)に対して必要な情報提供を行うためである。換言すれば、利用者は、利用空港が採用するサーバの方式等を意識する必要はないので負担が増加することはない。また、利用者の負担が増加しないので、空港会社は、クラウド等に構築された共用サーバ101を用いることについて支障がない。
以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。
[第1の実施形態]
第1の実施形態について、図面を用いてより詳細に説明する。
[システムの構成]
図3は、第1の実施形態に係る情報処理システム(空港管理システム、認証システム)の概略構成の一例を示す図である。図3に示す情報処理システムには、管理センター、複数の空港A~Cが含まれる。
管理センターは、生体認証を活用した本人確認プラットフォーム(Biometrics Hub)を各空港に提供する。管理センターは任意の団体等により運営される。例えば、空港会社、複数の空港会社による合弁会社、国や自治体等の公的機関、空港会社や公的機関等から委託を受けた民間企業等が管理センターを運営する。
管理センターは、制御サーバ10を備える。制御サーバ10は、管理センターの主たる機能を実現する装置である。制御サーバ10は、管理センターの施設内に設置されていてもよいし、ネットワーク上のクラウドに設置されていてもよい。
情報処理システムに含まれる複数の空港A~Cは、2つのタイプに分類される。
第1のタイプに属する空港は、利用者(乗客)の出入国手続きを生体認証により進めるために必要な装置、機材を自空港で管理、運営する空港である。図3の例では、空港Aが第1のタイプの空港に相当する。以降の説明において、第1のタイプに属する空港を「オンプレミス型空港」と表記する。
オンプレミス型空港は、出入国手続きを生体認証により進める利用者を認証する専用サーバ30と、利用者が出入国手続きを生体認証で進める際のインターフェイスとなる認証端末40(タッチポイント)と、を含む。専用サーバ30は、1つの空港における認証処理を行う。オンプレミス型空港のより詳細な構成は後述する。
第2のタイプに属する空港は、利用者の出入国手続きを生体認証により進めるために必要な装置のうち、サーバを他の空港と共用する空港である。図3の例では、空港B及び空港Cが第2のタイプの空港に相当する。以降の説明において、第2のタイプに属する空港を「クラウド型空港」と表記する。
上述のように、クラウド型空港は、利用者を認証するサーバを持たない。クラウド型空港は、少なくとも1以上の認証端末40(タッチポイント)を含む。クラウド型空港では、クラウドに設置された共用サーバ50が、利用者を認証する。共用サーバ50は、複数の空港によって認証処理を行うサーバとして共用される。クラウド型空港のより詳細な構成は後述する。
以降の説明において、専用サーバ30及び共用サーバ50を「認証サーバ」と総称して表記する。
図3に示すように、情報処理システムは、DCS(Departure Control System)20を含む。DCS20は、チェックイン処理、搭乗券の発行、手荷物の受け入れ等を管理するシステムである。DCS20は、各航空会社それぞれのサーバ(エアラインホスト、DCSサーバ)により構成されている。DCS20は、複数のDCSサーバからなる集合体である。各航空会社のDCSサーバは、制御サーバ10、専用サーバ30、共用サーバ50からアクセス可能に構成されている。
利用者は、端末60を所持する。利用者は、端末60を用いて航空機の利用に関する手続きをする。例えば、利用者は、端末60を操作して、航空券を購入したり、チェックイン手続きを行ったりする。端末60には、航空機の利用に関するアプリケーションがインストールされている。以降の説明において、端末60にインストールされたアプリケーションを「モバイルアプリ」と表記する。
図3に示す情報処理システムに含まれる各装置(制御サーバ10、専用サーバ30、共用サーバ50等)は、ネットワークを介して相互に通信可能に構成されている。例えば、制御サーバ10と専用サーバ30は、有線又は無線の通信手段により接続され、相互に通信が可能となるように構成されている。
図3は例示であって、本願開示の情報提供システムの構成等を限定する趣旨ではない。例えば、管理センターには2台以上の制御サーバ10が含まれていてもよい。また、情報処理システムに含まれる空港の数は3に限定されない。情報処理システムには、少なくとも1以上のオンプレミス型空港と少なくとも1以上のクラウド型空港が含まれていればよい。
[オンプレミス型空港の構成]
図4は、オンプレミス型空港の構成の一例を示す図である。図4に示されるように、オンプレミス型空港には、専用サーバ30と、複数のタッチポイント(認証端末40;チェックイン端末41、手荷物預け機42、旅客通過システム43、ゲート装置44、搭乗ゲート装置45)が含まれる。
利用者の搭乗手続きは、図4に示す各タッチポイントにより行われる。具体的には、利用者が出国する際の一連の手続きは、5つのタッチポイントにて順次実施される。利用者は、図4に示す5つのタッチポイントを用いて搭乗手続きを生体認証により進めることができる。
搭乗手続き(出国手続き)を生体認証により進めるためには、利用者は、生体認証に必要な情報をシステムに登録する必要がある。
なお、利用者は、生体認証によらず搭乗手続きを進めることもできる。その場合、利用者は有人のカウンタ、ブース等で手続きを行う。生体認証によらない搭乗手続きは本願開示の趣旨とは異なるので詳細な説明を省略する。
航空機に搭乗するため、利用者は、チェックイン手続きを行う。利用者は、チェックイン端末41を用いてチェックイン手続きを行う。具体的には、利用者は、航空券及びパスポートをチェックイン端末41に提示する。チェックイン手続きが終了すると、チェックイン端末41は、搭乗券を発行する。なお、搭乗券には、紙媒体の搭乗券と電子媒体の搭乗券が含まれる。
チェックイン手続きが完了すると、利用者は、上記システム登録(生体認証に必要な情報をシステムに登録)を行うことができる。利用者は、空港に設置されたいずれかのタッチポイント(例えば、チェックイン端末41、手荷物預け機42)を用いてシステム登録を行う。
システム登録を行う場合、タッチポイント(認証端末40)は、顔画像、パスポート及び搭乗券それぞれに関する情報と、これらの情報を提供することについての利用者の同意を取得する。タッチポイントにより取得された情報が専用サーバ30に送信されることで、システム登録が行われる。
なお、利用者は、端末60(端末60にインストールされたモバイルアプリ)を用いてチェックイン手続きを行うこともできる。また、利用者は、端末60(モバイルアプリ)を用いてシステム登録を行うこともできる。端末60を用いたチェックイン手続きやシステム登録については後述する。
チェックイン端末41は、空港内のチェックインロビーに設置されている。チェックイン端末41は、CUSS(Common Use Self Service)端末とも称される。利用者は、チェックイン手続きを完了すると、手荷物の預け場所あるいは保安検査場へ移動する。
手荷物預け機42は、空港内の手荷物カウンタ(有人カウンタ)の隣接領域あるいはチェックイン端末41の近傍領域に設置されている。手荷物預け機42は、利用者が操作することにより、航空機内に持ち込まない手荷物を預ける手続き(手荷物預け手続き)を行うためのセルフ端末である。手荷物預け機42は、CUBD(Common Use Bag Drop)端末とも称される。利用者は、手荷物預け手続を完了すると、保安検査場へ移動する。なお、利用者が、手荷物を預けない場合には、手荷物預け手続は省略される。
旅客通過システム43は、空港内の保安検査場の入口に設置されているゲート装置である。旅客通過システム43は、PRS(Passenger Reconciliation System)とも称され、保安検査場の入口において利用者の通過可否を判定するシステムである。利用者は、旅客通過システム43を通過した後に保安検査手続きを完了すると、出国審査場へ移動する。
ゲート装置44は、空港内の出国審査場に設置されている。ゲート装置44は、利用者の出国審査手続を自動的に行う装置である。利用者は、出国審査手続きを完了すると、免税店や搭乗ゲートが設けられている出国エリアに移動する。
搭乗ゲート装置45は、出国エリアの搭乗ゲートごとに設置された通行制御装置である。搭乗ゲート装置45は、ABG(Automated Boarding Gates)端末とも称される。搭乗ゲート装置45は、利用者が搭乗ゲートから搭乗可能な航空機の搭乗者であることを確認する。利用者は、搭乗ゲート装置45を通過すると、航空機に搭乗し、第1国から第2国へ向けて出国する。
図4に示すように、オンプレミス型空港は、原則として、空港内における各手続き(出国手続き)を生体認証により進める。ただし、オンプレミス型空港は、5つの手続きのうち一部の手続きを生体認証とは異なる手続きで進めてもよい。例えば、出国審査は、出国審査を担当する審査官により行われてもよい。
[クラウド型空港の構成]
図5は、クラウド型空港の構成の一例を示す図である。図5に示すように、クラウド型空港には、専用サーバ30に相当するサーバは含まれていない。また、クラウド型空港には、利用者の出国手続きに必要な5つのタッチポイントのうち一部のタッチポイント(認証端末40)が設置されている。クラウド型空港は、自空港における旅客数や規模に適した認証端末40を選択し、空港内に設置する。
図5の例では、空港Bには手荷物預け機42と旅客通過システム43が設置され、空港Cには搭乗ゲート装置45が設置されている。クラウド型空港に含まれる認証端末40(タッチポイント)は、ネットワークを介して共用サーバ50と接続されている。
なお、クラウド型空港であっても、上記出国手続きに必要な5つのタッチポイントを備えることもある。また、クラウド型空港であっても、生体認証により搭乗手続きを進めるためのシステム登録は必要である。
なお、図4に示すオンプレミス型空港の構成及び図5に示すクラウド型空港の構成は例示であって、各空港の構成を限定する趣旨ではない。オンプレミス型空港及びクラウド型空港には、図示した認証端末40とは異なる種類の端末、デバイスが設置されていてもよい。例えば、トークン発行の有無(生体認証で手続きを進めることができるか否か)の判別をするデバイスが空港内に設置されていてもよい。あるいは、搭乗手続きの詳細やトークン発行(システム登録)を利用者に案内する案内用の端末(案内用サイネージ)が空港内に設置されていてもよい。あるいは、空港会社やクレジットカード情報会社が運営するラウンジへの入場可否を判定する端末が空港内に設置されていてもよい。また、利用者は、これらの端末(トークン有無を判定する端末、案内用サイネージ、ラウンジに設置された端末)を用いてシステム登録を行ってもよい。
[システムの概略動作]
続いて、情報処理システムの概略動作について説明する。
<事前準備>
利用者は、航空機を予約(航空券を購入)する前に事前準備を行う。利用者は、端末60にインストールされたモバイルアプリを用いて航空機を利用するための事前準備を行う。具体的には、利用者は、モバイルアプリを用いて、生体情報、パスポート情報を予め端末60に登録する。
生体情報には、例えば、顔、指紋、声紋、静脈、網膜、瞳の虹彩の模様(パターン)といった個人に固有の身体的特徴から計算されるデータ(特徴量)が例示される。あるいは、生体情報は、顔画像、指紋画像等の画像データであってもよい。生体情報は、利用者の身体的特徴を情報として含むものであればよい。本願開示では、人の「顔」に関する生体情報(顔画像又は顔画像から生成された特徴量)を用いる場合について説明する。
パスポート情報は、パスポートの券面に記載された全部又は一部の情報である。パスポート情報には、利用者の顔画像(以下、パスポート顔画像と表記する)、氏名、生年月日、住所、性別、旅券番号等が含まれる。
生体情報の取得に関し、利用者は、端末60を操作して自身の顔を撮影する。端末60は、所謂、自撮りにより顔画像を取得する。
パスポート情報の取得に関し、端末60は、パスポートを撮影することで得られる画像データを解析してパスポート情報を取得する。あるいは、端末60は、パスポートに搭載されたIC(Integrated Circuit)チップからパスポート情報を取得する。
生体情報(例えば、顔画像)とパスポート情報が得られると、端末60(モバイルアプリ)は、利用者を撮影することで得られた顔画像(以下、撮影顔画像と表記する)とパスポートから得られパスポート顔画像を用いた本人確認を実行する。
具体的には、端末60は、2つの顔画像を用いた1対1認証を実行する。1対1認証に成功すると、端末60は、利用者による事前準備が完了したと判定する。換言すれば、1対1認証が成功しなければ(パスポートを用いた本人確認に成功しなければ)、端末60は、モバイルアプリによるシステム登録(生体認証により出国手続きを進めるための情報登録)等に関する制御を実行しない。
本人確認に成功すると、利用者は、旅行代理店や航空会社等のWEB(ウェブ)ページ等を介して航空券を購入する。航空券を購入した利用者には、紙の航空券、搭乗情報が記載された2次元バーコード、eチケットの控え等が発行される。また、航空会社のDCSサーバは、航空券購入者のパスポートの情報と予約情報(航空券の情報)を対応付けて記憶する。
端末60は、航空券情報(航空券に記載された全部又は一部の情報)を取得する。例えば、端末60は、航空券を撮影することで得られる画像データを解析し、航空券情報を取得する。あるいは、端末60は、上記2次元バーコードやeチケットから航空券情報を取得する。航空券情報には、出発空港、到着空港、便名(フライトナンバー)、航空機を運航する航空会社のエアラインコード等が含まれる。
予約された航空機が出発する所定時間前(例えば、24時間前)になると、DCSサーバは、航空券の購入者に対してチェックイン手続きに関する通知を行う。具体的には、DCSサーバは、事前に登録された航空券購入者のメールアドレスに「チェックイン要求」を送信する。
チェックイン要求を受信すると、利用者は、端末60を操作してチェックイン手続きを行う。例えば、利用者は、DCSサーバから受信したメールに含まれる案内に従いチェックイン手続きを行う。当該チェックイン手続きは、モバイルアプリにより行われてもよいし、航空会社から提供されるアプリケーション等により行われてもよい。
チェックインが完了すると、利用者には搭乗券が発行される。DCSサーバは、チェックインが終了した利用者のパスポートと搭乗券を対応付けて記憶する。
<事前登録>
また、チェックインが完了すると、利用者は、搭乗手続きを生体認証により進めるための事前登録(システム登録)を行う必要がある。具体的には、利用者は、出発空港(オンプレミス型空港、クラウド型空港)が生体認証を実行するために必要な情報をシステムに登録する必要がある。
上述のように、利用者は、当該システム登録を、空港に設置された認証端末40(タッチポイント)から行うこともできるが、所持する端末60から行うこともできる。利用者は、チェックインが完了した搭乗券に対応する搭乗手続きを生体認証により進めるためのシステム登録を行う。
端末60を用いてシステム登録に関する手続きを行う場合、利用者は、端末60を操作してモバイルアプリを起動する。利用者は、モバイルアプリにおいて所定の操作(例えば、システム登録ボタンの押下)を行う。当該利用者の操作に応じて、端末60は、上記生体認証の実行のために必要な情報を外部に提供することに対する利用者の同意を取得する。
なお、端末60は、利用者の所在国における個人情報提供に関する規則、法律に従った方法、態様により上記情報提供に対する利用者の同意を取得する。
具体的には、端末60(モバイルアプリ)は、パスポート情報及び航空券情報を参照して、図6に示すようなGUI(Graphical User Interface)を生成する。図6に示すように、端末60は、外部に情報提供される内容(図6の例では生体情報等)と、情報提供先(図6の例では空港A)を明示しつつ、情報提供に対する利用者の同意を取得する。情報提供に対する利用者の同意が得られると、端末60(モバイルアプリ)は、取得した同意内容を含む「コンセント情報」を生成する。
なお、図6に示す同意取得画面は例示であって、端末60は、種々の情報を利用者に提示しながら情報提供に対する同意を取得することができる。例えば、端末60は、外部に提供される個人情報(生体情報)の利用目的、利用用途を表示してもよい。あるいは、外部に提供される生体情報が空港外におけるサービス提供に利用される場合には、端末60は、その旨を利用者に通知しつつ、利用者が受けたいサービス(空港会社等と連携したサービス)を選択可能としてもよい。即ち、端末60は、生体情報等の個人情報が空港外(オフエアポート)で利用されることについての同意(利用者の同意)を取得してもよい。また、生体情報等が空港外で使用される場合には、端末60は、当該生体情報の使用に関する利用規約を利用者に提示してもよい。
例えば、コンセント情報には、情報提供先となる空港に関する情報、搭乗予定の航空機に関する情報(例えば、フライトナンバー)、航空機を運航する航空会社に関する情報(例えば、エアラインコード)、利用者の個人情報(例えば、生体情報等)等が含まれる。コンセント情報は、生体情報を含む情報が端末60からみた外部(共用サーバ50、専用サーバ30)に提供されることに対する利用者の同意に関する情報である。
その後、端末60(モバイルアプリ)は、生体情報、パスポート情報及びコンセント情報を制御サーバ10に送信する。具体的には、端末60は、生体情報、パスポート情報及びコンセント情報を含む「システム登録要求」制御サーバ10に送信する(図7のステップS01)。
システム登録要求を受信した制御サーバ10は、当該システム登録要求に含まれるパスポート情報をDCSサーバに送信する。具体的には、制御サーバ10は、システム登録要求に含まれるコンセント情報に基づいて利用者が搭乗予定の航空機を運航する航空会社を特定する。制御サーバ10は、当該特定された航空会社のDCSサーバに向けて、パスポート情報を含む「搭乗券情報提供要求」を送信する(ステップS02)。
DCSサーバは、取得したパスポート情報に対応する搭乗券の特定を試みる。DCSサーバは、対応する搭乗券が存在すれば、搭乗券情報を含む肯定応答を制御サーバ10に送信する(ステップS03)。取得したパスポート情報に対応する搭乗券が存在しなければ、DCSサーバは、その旨を示す否定応答を制御サーバ10に送信する。
搭乗券情報を取得すると、制御サーバ10は、認証サーバ(専用サーバ30、共用サーバ50)に対してトークンの発行を要求する。具体的には、制御サーバ10は、トークン発行に必要な4つの情報(生体情報、パスポート情報、搭乗券情報、コンセント情報)を認証サーバ(専用サーバ30、共用サーバ50)に送信する。制御サーバ10は、上記4つの情報を含む「トークン発行要求」を認証サーバに送信する(ステップS04)。
なお、トークン発行要求を認証サーバに送信する際、制御サーバ10は、コンセント情報又は搭乗券情報に基づいて、トークン発行要求の送信先(専用サーバ30又は共用サーバ50)を決定する。具体的には、コンセント情報又は搭乗券情報から得られる出発空港がオンプレミス型空港であれば、制御サーバ10は、当該オンプレミス型空港の専用サーバ30にトークン発行要求を送信する。コンセント情報等から得られる出発空港がクラウド型空港であれば、制御サーバ10は、共用サーバ50にトークン発行要求を送信する。
図3の例では、利用者が空港Aから航空機に搭乗する場合には、空港Aの専用サーバ30に、生体情報、パスポート情報、搭乗券情報、コンセント情報が送信される。対して、利用者が空港B又は空港Cから航空機に搭乗する場合には、上記4つの情報が共用サーバ50に送信される。
なお、空港内に設置された認証端末40(タッチポイント)からシステム登録される場合、認証端末40は、上記4つの情報(生体情報、パスポート情報、搭乗券情報、コンセント情報)を取得する。認証端末40は、取得した4つの情報と後述する端末IDを含むトークン発行要求を認証サーバに送信する。
<トークンの発行>
認証サーバ(専用サーバ30、共用サーバ50)は、取得した4つの情報からトークンを発行する。認証サーバは、生体情報、パスポート情報、搭乗券情報及びコンセント情報を対応付けてトークン管理データベースに登録する(トークンを発行する)。なお、共用サーバ50は、空港ごとに用意されたトークン管理データベースを用いてトークンを管理する。
トークン発行処理を終了すると、認証サーバは、トークン発行要求に対する応答(肯定応答、否定応答)を制御サーバ10に送信する(ステップS05)。
トークン発行要求に対する応答を受信したことに応じて、制御サーバ10は、システム登録要求に対する応答(肯定応答、否定応答)を端末60に送信する(ステップS06)。
肯定応答(システム登録成功、トークン発行成功)を受信した場合には、端末60は、空港内の手続きを生体認証(所謂、顔パス)で進めることが可能な旨を利用者に通知する。否定応答(システム登録失敗、トークン発行失敗)を受信した場合には、端末60は、システム登録に失敗した旨を利用者に通知する。
<生体認証による搭乗手続き>
システム登録を完了した利用者は、搭乗日に空港を訪れる。空港内の全部又は一部の手続きは生体認証により行われる。生体認証に対応した手続きでは、利用者は、認証端末40の前に移動する。認証端末40は、利用者(被認証者)の生体情報を取得し、当該取得した生体情報(例えば、顔画像)を含む認証要求を認証サーバに送信する(図8参照)。
図3の例では、空港Aに設置された認証端末40は、専用サーバ30に認証要求を送信する。空港B又は空港Cに設置された認証端末40は、共用サーバ50に認証要求を送信する。
認証サーバ(専用サーバ30、共用サーバ50)は、取得した生体情報とトークン管理データベースに記憶された生体情報を用いた照合処理により対応する利用者(エントリ、トークン)を特定する。認証サーバは、特定されたトークンのパスポート情報や搭乗券情報を用いて利用者を認証する。認証サーバは、認証結果(認証成功、認証失敗)を認証端末40に送信する。認証端末40は、認証結果に応じた処理(例えば、利用者のゲート通行を許可または拒否)を行う。
<トークンの削除>
認証サーバ(専用サーバ30、共用サーバ50)は、航空機が出発してから所定時間経過後に当該出発した航空機の乗客に関するトークンを削除する。
このように、第1の実施形態に係る情報処理システムは、制御サーバ10と、複数の空港によって認証処理を行うサーバとして共用される共用サーバ50と、1つの空港における認証処理を行う専用サーバ30と、を含む。制御サーバ10は、利用者が搭乗手続きを生体認証により進めるために必要な情報を認証サーバ(共用サーバ50、専用サーバ30)に送信する。制御サーバ10は、利用者が利用する空港に応じて、搭乗手続きを生体認証により進めるために必要な情報を共用サーバ50又は専用サーバ30のいずれかに送信する。
また、認証サーバ(専用サーバ30、共用サーバ50)は、制御サーバ10を介して端末60から取得した情報を用いて、利用者が生体認証により搭乗手続きを進めるためのトークンを生成し、生成されたトークンを記憶する。認証サーバは、認証処理に用いるトークン(利用者の生体情報等)が不要になったタイミングで当該トークンを削除する。具体的には、共用サーバ50や専用サーバ30は、利用者が搭乗した航空機が出発してから所定時間経過後に当該利用者のトークンを削除する。
続いて、第1の実施形態に係る情報処理システムに含まれる各装置の詳細について説明する。
[制御サーバ]
図9は、第1の実施形態に係る制御サーバ10の処理構成(処理モジュール)の一例を示す図である。図9を参照すると、制御サーバ10は、通信制御部201と、システム登録制御部202と、記憶部203と、を備える。
通信制御部201は、他の装置との間の通信を制御する手段である。例えば、通信制御部201は、専用サーバ30からデータ(パケット)を受信する。また、通信制御部201は、専用サーバ30に向けてデータを送信する。通信制御部201は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部201は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部201を介して他の装置とデータの送受信を行う。通信制御部201は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
システム登録制御部202は、利用者のシステム登録を制御する手段である。システム登録制御部202は、利用者が利用する空港を判定する、「判定部」としての機能を備える。さらに、システム登録制御部202は、利用者が利用する空港に応じて、利用者が搭乗手続きを生体認証により進めるために必要な情報を共用サーバ50又は専用サーバ30のいずれかに送信する、「登録部」としての機能を備える。システム登録制御部202は、端末60(モバイルアプリ)から受信するシステム登録要求を処理する。図10を参照し、システム登録制御部202の動作を説明する。
システム登録制御部202は、システム登録要求に含まれるコンセント情報を確認する。コンセント情報には、個人情報の提供が許可された空港、搭乗する航空機、利用する航空会社等に関する情報が含まれる。システム登録制御部202は、航空会社に関する情報(例えば、エアラインコード)を参照し、利用者が利用する航空会社を特定する。
システム登録制御部202は、特定した航空会社のDCSサーバに対し、システム登録要求から得られるパスポート情報を含む搭乗券情報提供要求を送信する(ステップS101)。
システム登録制御部202は、航空会社のDCSサーバから応答(肯定応答、否定応答)を受信する。DCSサーバから送信される肯定応答には搭乗券情報が含まれる。
否定応答を受信した場合(ステップS102、No分岐)、システム登録制御部202は、利用者の搭乗券はDCS20に登録されていないと判定する。この場合、システム登録制御部202は、システム登録要求に対する応答として否定応答(システム登録失敗)を端末60に送信する(ステップS103)。
肯定応答を受信した場合(ステップS102、Yes分岐)、システム登録制御部202は、当該肯定応答から搭乗券情報を取り出す。その後、システム登録制御部202は、利用者が利用する出発空港に関する判定を行う(ステップS104)。
具体的には、システム登録制御部202は、コンセント情報に含まれる空港に関する情報(例えば、空港コード)に基づいて利用者が利用する空港がオンプレミス型空港かクラウド型空港か判定する。
システム登録制御部202は、特定した空港の認証サーバ(専用サーバ30、共用サーバ50)にトークン発行要求を送信する。
具体的には、システム登録制御部202は、出発空港がオンプレミス型空港であれば(ステップS105、Yes分岐)、出発空港の専用サーバ30に対してトークン発行要求を送信する(ステップS106)。
出発空港がクラウド型空港であれば(ステップS105、No分岐)、システム登録制御部202は、共用サーバ50に対してトークン発行要求を送信する(ステップS107)。
なお、システム登録制御部202が送信するトークン発行要求には、認証サーバがトークンを発行するために必要な4つの情報(生体情報、パスポート情報、搭乗券情報、コンセント情報)が含まれる。
システム登録制御部202は、トークン発行要求に対する応答(肯定応答、否定応答)を受信する。
否定応答(トークン生成失敗)を受信した場合(ステップS108、No分岐)、システム登録制御部202は、端末60に対してシステム登録に失敗した旨を示す否定応答を送信する(ステップS103)。
肯定応答(トークン生成成功)を受信した場合(ステップS108、Yes分岐)、システム登録制御部202は、端末60に対してシステム登録に成功した旨を示す肯定応答を送信する(ステップS109)。
上述のように、コンセント情報には、利用者が利用する空港に関する情報と、利用者が搭乗予定の航空機を運航する航空会社に関する情報と、が含まれる。制御サーバ10は、コンセント情報に含まれる航空会社に関する情報に対応する航空会社のDCSサーバにパスポート情報を送信することで、利用者に発券された搭乗券に関する搭乗券情報を取得する。また、制御サーバ10は、コンセント情報に含まれる空港に関する情報に基づいて、トークン発行要求の送信先を決定する。制御サーバ10は、利用者の生体情報と、利用者のパスポートに関するパスポート情報と、利用者に発行された搭乗券に関する搭乗券情報と、コンセント情報と、を含むトークン発行要求を上記決定された送信先(認証サーバ)に送信する。
記憶部203は、制御サーバ10の動作に必要な情報を記憶する。例えば、記憶部203は、各空港のタイプ(オンプレミス型空港、クラウド型空港)や、各認証サーバのアドレス、各航空会社のDCSサーバのアドレス等を記憶する。
[DCS(DCSサーバ)]
DCS20に関する詳細な説明は省略する。DCS20に含まれるDCSサーバは、自社(航空会社)の旅客に関する予約情報を保持し、チェックイン手続きを完了した利用者に搭乗券を発行する。また、DCSサーバは、制御サーバ10から受信する搭乗券情報提供要求を処理する。DCSサーバは、当該受信した搭乗券情報提供要求に含まれるパスポート情報に対応する搭乗券が記憶されていれば、当該搭乗券の搭乗券情報を含む肯定応答を制御サーバ10に送信する。
[専用サーバ]
図11は、第1の実施形態に係る専用サーバ30の処理構成(処理モジュール)の一例を示す図である。図11を参照すると、専用サーバ30は、通信制御部301と、トークン制御部302と、認証部303と、記憶部304と、を備える。
通信制御部301は、他の装置との間の通信を制御する手段である。例えば、通信制御部301は、制御サーバ10からデータ(パケット)を受信する。また、通信制御部301は、制御サーバ10に向けてデータを送信する。通信制御部301は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部301は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部301を介して他の装置とデータの送受信を行う。通信制御部301は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
トークン制御部302は、生体認証により搭乗手続きを進める利用者のトークンを制御する手段である。トークン制御部302は、認証端末40や制御サーバ10からトークン発行要求を受信する。
トークン発行要求の受信に応じて、トークン制御部302は、トークンを発行する。具体的には、トークン制御部302は、処理時の日時やシーケンス番号等に基づいて固有な値をトークンIDとして生成する。
また、トークン制御部302は、トークン発行要求に含まれる生体情報(顔画像)から特徴量を生成する。
なお、特徴量の生成処理に関しては既存の技術を用いることができるので、その詳細な説明を省略する。例えば、トークン制御部302は、顔画像から目、鼻、口等を特徴点として抽出する。その後、トークン制御部302は、特徴点それぞれの位置や各特徴点間の距離を特徴量として計算する(複数の特徴量からなる特徴ベクトルを生成する)。
特徴量が生成されると、トークン制御部302は、トークンID、生体情報(特徴量)、パスポート情報、搭乗券情報及びコンセント情報を対応付けてトークン管理データベースに記憶する(図12参照)。なお、図12に示すトークン管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。例えば、生体情報として「顔画像」がトークン管理データベースに登録されていてもよい。
トークンが生成されると(4つの情報をデータベースに登録すると)、トークン制御部302は、トークン発行要求の送信元(認証端末40、制御サーバ10)に対して肯定応答(トークン発行成功)を送信する。トークン制御部302は、トークンIDの生成に失敗すると、トークン発行要求の送信元に対して否定応答(トークン発行失敗)を送信する。
トークン制御部302は、定期的又は所定のタイミングでトークン管理データベースにアクセスする。トークン制御部302は、当該データベースの各エントリ(トークン)の搭乗券情報等を参照し、航空機が出発してから所定時間経過(例えば、24時間経過)しているエントリを削除する。あるいは、トークン制御部302は、DCS20から出発した航空機に関する情報を取得してもよい。
認証部303は、搭乗手続きを生体認証により進める利用者(被認証者)を認証する手段である。認証部303は、空港内に設置された各認証端末40(タッチポイント)から受信する認証要求を処理する。
認証要求には、被認証者の生体情報と端末IDが含まれる。端末IDは、空港に設置された認証端末40を識別するためのIDである。端末IDには、認証端末40のMAC(Media Access Control)アドレスやIP(Internet Protocol)アドレスを用いることができる。
なお、端末IDは、認証サーバと認証端末40の間において任意の方法によって共有される。例えば、システム管理者が端末IDを決定し、当該決定された端末ID及び認証端末40の詳細な情報(例えば、認証端末40の種類、設置空港、認証端末40を管理する航空会社等の情報)を認証サーバに設定する。また、システム管理者は、当該決定された端末IDを認証端末40に設定する。
認証部303は、端末IDを用いて認証要求の送信元である認証端末40の種類(チェックイン端末41、手荷物預け機42、旅客通過システム43、ゲート装置44、搭乗ゲート装置45)を特定する。
認証部303は、認証要求に含まれる生体情報とトークン管理データベースに記憶された生体情報を用いた照合処理(1対N照合;Nは正の整数、以下同じ)を実行する。
認証部303は、認証端末40から取得した顔画像から特徴量を生成する。認証部303は、当該生成した特徴量(特徴ベクトル)を照合側の特徴量、トークン管理データベースに登録された特徴量を登録側の特徴量にそれぞれ設定する。
認証部303は、照合側の特徴量と登録側の複数の特徴量それぞれの間の類似度を計算する。なお、当該類似度には、カイ二乗距離やユークリッド距離等を用いることができる。距離が離れているほど類似度は低く、距離が近いほど類似度が高い。
認証部303は、トークン管理データベースに登録された複数の特徴量のうち、照合対象の特徴量との間の類似度が所定の値以上の特徴量が存在すれば、照合処理に成功したと判断する。そのような特徴量が存在しなければ、認証部303は、照合処理に失敗したと判断する。
照合処理に失敗すると、認証部303は、被認証者の認証に失敗した旨を示す否定応答を認証端末40に送信する。
照合処理に成功すると、認証部303は、類似度の最も高い特徴量に対応するエントリのパスポート情報、搭乗券情報を使って被認証者の認証を行う。その際、認証部303は、端末IDから特定される認証端末40の種類に応じた処理を実行することで被認証者を認証する。
例えば、搭乗ゲート装置45(ABG)から認証要求を受信した場合、認証部303は、被認証者が搭乗ゲートの先に駐機している航空機に搭乗する資格を備えていれば認証成功と判定する。認証部303は、被認証者が当該航空機に搭乗する資格を備えていなければ認証失敗と判定する。
なお、各認証端末40に関する認証処理についての詳細な説明を省略する。個別の認証端末40に関する認証処理は本願開示の趣旨とは異なると共に当業者にとって明らかなためである。
認証部303は、認証結果を認証端末40に送信する(認証要求に応答する)。認証に成功した場合、認証部303は、肯定応答(認証成功を示す応答)を認証端末40に送信する。認証に失敗した場合には、認証部303は、その旨(認証失敗)を示す否定応答を認証端末40に送信する。
記憶部304は、専用サーバ30の動作に必要な各種情報を記憶する。記憶部304には、トークン管理データベースが構築される。
[共有サーバ]
図13は、第1の実施形態に係る共用サーバ50の処理構成(処理モジュール)の一例を示す図である。図13を参照すると、共用サーバ50は、通信制御部401と、トークン制御部402と、認証部403と、記憶部404と、を備える。
共用サーバ50の主たる機能は専用サーバ30と同一とすることができる。そのため、共用サーバ50と専用サーバ30の相違点について説明する。
共用サーバ50のトークン制御部402は、生成したトークンを空港ごとのデータベースに記憶する。例えば、空港Bから航空機に搭乗する利用者のトークンは、空港Bのために用意されたトークン管理データベースに記憶される(図14A参照)。また、空港Cから航空機に搭乗する利用者のトークンは、空港Cのために用意されたトークン管理データベースに記憶される(図14B参照)。
共用サーバ50の認証部403は、認証要求を処理する際、当該認証要求を送信した認証端末40が設置された空港に対応するトークン管理データベースを使って被認証者を認証する。
例えば、空港Bに設置された認証端末40から認証要求を受信した場合、認証部403は、図14Aに示されるトークン管理データベースの生体情報を使って認証処理を行う。また、空港Cに設置された認証端末40から認証要求を受信した場合、認証部403は、図14Bに示されるトークン管理データベースの生体情報を使って認証処理を行う。
認証部403は、端末IDと設置空港等を対応付けて記憶するテーブル情報等を参照し、認証端末40の設置空港を特定すればよい。
[認証端末]
図15は、第1の実施形態に係る認証端末40の処理構成(処理モジュール)の一例を示す図である。図15を参照すると、認証端末40は、通信制御部501と、生体情報取得部502と、認証要求部503と、機能実現部504と、記憶部505と、を備える。
通信制御部501は、他の装置との間の通信を制御する手段である。例えば、通信制御部501は、専用サーバ30からデータ(パケット)を受信する。また、通信制御部501は、専用サーバ30に向けてデータを送信する。通信制御部501は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部501は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部501を介して他の装置とデータの送受信を行う。通信制御部501は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
生体情報取得部502は、カメラ(図示せず)を制御し、利用者の生体情報を取得する手段である。生体情報取得部502は、定期的又は所定のタイミングにおいて自装置の前方を撮像する。生体情報取得部502は、取得した画像に人の顔画像が含まれるか否かを判定し、顔画像が含まれる場合には取得した画像データから顔画像を抽出する。
なお、生体情報取得部502による顔画像の検出処理や顔画像の抽出処理には既存の技術を用いることができるので詳細な説明を省略する。例えば、生体情報取得部502は、CNN(Convolutional Neural Network)により学習された学習モデルを用いて、画像データの中から顔画像(顔領域)を抽出してもよい。あるいは、生体情報取得部502は、テンプレートマッチング等の手法を用いて顔画像を抽出してもよい。
生体情報取得部502は、抽出した顔画像を認証要求部503に引き渡す。
認証要求部503は、認証サーバに対して面前の利用者に関する認証を要求する手段である。認証要求部503 は、取得した顔画像及び端末IDを含む認証要求を生成し、認証サーバに送信する。
オンプレミス型空港に設置された認証端末40の認証要求部503は、対応する専用サーバ30に認証要求を送信する。クラウド型空港に設置された認証端末40の認証要求部503は、共用サーバ50に認証要求を送信する。
認証要求部503は、認証要求に対する応答(肯定応答、否定応答)を認証サーバから受信する。認証要求部503は、受信した応答を機能実現部504に引き渡す。
機能実現部504は、各認証端末40に割り当てられた機能を実現する手段である。例えば、搭乗ゲート装置45の機能実現部504は、被認証者の認証が成功の場合、ゲートを開き当該被認証者の通過を許可する。対して、被認証者の認証が失敗の場合、搭乗ゲート装置45の機能実現部504は、ゲートを閉じ当該被認証者の通過を拒否する。
各認証端末40の機能実現部504に関する詳細な動作の説明は省略する。各認証端末40の動作は当業者にとって明らかであると共に本願開示の趣旨とは異なるためである。
記憶部505は、認証端末40の動作に必要な情報を記憶する手段である。
なお、利用者のシステム登録(トークン発行)に関する認証端末40の処理モジュールは図15において図示を省略している。認証端末40は、端末60と同様に、システム登録のための手続きを実行すればよい。認証端末40は、トークン発行のために必要な4つの情報を含むトークン発行要求を認証サーバに送信すればよい。
[端末]
端末60には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ(パーソナルコンピュータ、ノートパソコン)等が例示される。
図16は、第1の実施形態に係る端末60の処理構成(処理モジュール)の一例を示す図である。図16を参照すると、端末60は、通信制御部601と、生体情報取得部602と、パスポート情報取得部603と、本人確認部604と、航空券情報取得部605と、同意取得制御部606と、システム登録制御部607と、記憶部608と、を備える。
通信制御部601は、他の装置との間の通信を制御する手段である。例えば、通信制御部601は、制御サーバ10からデータ(パケット)を受信する。また、通信制御部601は、制御サーバ10に向けてデータを送信する。通信制御部601は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部601は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部601を介して他の装置とデータの送受信を行う。通信制御部601は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。
なお、生体情報取得部602、パスポート情報取得部603、本人確認部604、航空券情報取得部605、同意取得制御部606及びシステム登録制御部607は、モバイルアプリを構成する処理モジュールである。
生体情報取得部602は、利用者の生体情報(例えば、顔画像)を取得する手段である。生体情報取得部602は、利用者による所定の操作(例えば、事前準備ボタンの押下)を検出すると、GUI等を用いて当該利用者の生体情報(例えば、顔画像)を取得する。
顔画像を取得する際、生体情報取得部602は、生体認証に適した顔画像を取得するための技術を活用してもよい。例えば、生体情報取得部602は、正面の顔画像を取得するための正面顔撮影技術や写真等を用いた不正を防止するライブネス撮影技術を用いてもよい。
顔画像を取得すると、生体情報取得部602は、その旨をパスポート情報取得部603に通知する。
パスポート情報取得部603は、利用者が所持するパスポートからパスポート情報を取得する手段である。顔画像の取得が完了した旨の通知を受けると、パスポート情報取得部603は、GUI等を用いてパスポート情報を取得する。
例えば、利用者は、端末60を操作して、パスポートの券面を撮影する。パスポート情報取得部603は、パスポートの券面が撮影されたことで得られる画像データから顔領域を抽出し、顔画像(パスポート顔画像)を取得する。また、パスポート情報取得部603は、OCR(Optical Character Recognition)技術を用いて券面に記載された氏名等を取得する。
あるいは、パスポート情報取得部603は、パスポートに搭載されたIC(Integrated Circuit)チップからパスポート情報を読み出してもよい。ICチップから情報を読み出す場合には、パスポート情報取得部603は、パスポートの券面に記載された機械読取領域(Machine Readable Zone;MRZ)に記載されたMRZ情報を読み取る。MRZ情報には、氏名、国籍、性別、生年月日等が含まれる。パスポート情報取得部603は、取得したMRZ情報をパスワードとして用いてICチップから顔画像、氏名等の情報を読み出す。
パスポート情報を取得すると、パスポート情報取得部603は、その旨を本人確認部604に通知する。なお、端末60は、パスポート情報を取得した後に生体情報(顔画像)を取得してもよいことは勿論である。この場合、パスポート情報取得部603がパスポート情報を取得した後、生体情報取得部602が顔画像(生体情報)を取得する。
本人確認部604は、利用者の本人確認を実行する手段である。生体情報及びパスポート情報が取得されると、本人確認部604は、利用者を撮影することで得られた顔画像(撮影顔画像)とパスポートから読み出された顔画像(パスポート顔画像)を用いた本人確認を実行する。
本人確認部604は、2つの顔画像を用いた1対1認証を実行する。本人確認部604は、当該2つの顔画像が実質的に一致するか否かを判定し本人確認を行う。
具体的には、本人確認部604は、2つの画像それぞれから特徴量を生成する。本人確認部604は、2つの特徴量の類似度を計算する。2つの特徴量の類似度が所定の値よりも大きければ、本人確認部604は、2つの顔画像は同一人物によるものと判定する(本人確認成功と判定する)。類似度が所定の値以下であれば、本人確認部604は、2つの顔画像は同一人物の顔画像ではないと判定する(本人確認失敗と判定する)。
本人確認(1対1認証)が完了することで、利用者は、モバイルアプリの各機能を利用できる。
航空券情報取得部605は、利用者が購入した航空券から航空券情報を取得する手段である。航空券情報取得部605は、利用者による所定の動作(例えば、航空券登録ボタンの押下)を検出すると、航空券情報を取得するためのGUI等を表示する。
なお、航空券情報取得部605は、パスポート情報の取得と同様に、航空券を撮影して得られる画像データから航空券情報を取得する。あるいは、航空券情報取得部605は、利用者が航空券を購入したWEBページ(WEBページを提供するサーバ)等から航空券情報を取得してもよい。
同意取得制御部606は、生体情報を含む個人情報を外部に提供することに対する、利用者の同意を取得する手段である。より具体的には、同意取得制御部606は、搭乗手続きを生体認証により進めるための情報(例えば、生体情報、パスポート情報)を搭乗空港に提供することに対する利用者の同意を取得する。同意取得制御部606は、本人確認に成功した後に、搭乗空港に情報提供することに対する利用者の同意を取得する。
購入した航空券に関するチェックイン手続きが終了すると、利用者は、モバイルアプリにおいて「システム登録」ボタンを押下する。当該システム登録ボタンの押下に応じて、同意取得制御部606は、システム登録のために必要な個人情報を外部に提供することに対する利用者の同意を取得する。
例えば、同意取得制御部606は、図6に示すようなGUIを用いて、情報提供に対する利用者の同意を取得する。情報提供に対する利用者の同意が得られると、同意取得制御部606は、取得した同意内容を含む「コンセント情報」を生成する。コンセント情報を生成すると、同意取得制御部606は、その旨をシステム登録制御部607に通知する。
システム登録制御部607は、利用者のシステム登録に関する制御を行う手段である。システム登録制御部607は、外部(搭乗空港)に提供することに対する同意が得られた情報(搭乗手続きを生体認証により進めるための情報)を、認証サーバに登録するための制御を行う。
情報提供に対する利用者の同意が得られると(コンセント情報が生成されると)、システム登録制御部607は、生体情報(顔画像)、パスポート情報及びコンセント情報を含む「システム登録要求」制御サーバ10に送信する。
システム登録制御部607は、システム登録要求対する応答(肯定応答、否定応答)を制御サーバ10から受信する。システム登録制御部607は、受信した応答に応じてシステム登録の可否(生体認証を用いて搭乗手続きを進めることができるか否か)を利用者に通知する。
このように、システム登録制御部607は、生体情報、パスポート情報及びコンセント情報を含むシステム登録要求を、制御サーバ10に送信する。制御サーバ10は、認証サーバと接続されたサーバであって、コンセント情報に含まれる航空会社に関する情報に対応する航空会社のDCSサーバにパスポート情報を送信することで、利用者に発行された搭乗券に関する搭乗券情報を取得する。また、制御サーバ10による搭乗券情報の取得を可能にするため、同意取得制御部606は、利用者から情報提供に対する同意が得られると、少なくとも利用者が搭乗予定の航空機を運航する航空会社に関する情報を含むコンセント情報を生成する。
記憶部608は、端末60の動作に必要な情報を記憶する手段である。記憶部608には、空港における搭乗手続きを生体認証により進めるための情報が記憶される。例えば、利用者の生体情報、パスポート情報、コンセント情報等が記憶部608に記憶される。
[システム動作]
続いて、第1の実施形態に係る情報処理システムの動作を説明する。図17は、第1の実施形態に係る情報処理システムの動作の一例を示すシーケンス図である。図17を参照して、利用者のシステム登録に関する動作を説明する。
端末60は、利用者の操作に応じて、生体情報等の個人情報を外部に提供することに対する利用者の同意を取得する(ステップS11)。
利用者の同意を取得すると(コンセント情報を生成すると)、端末60は、生体情報、パスポート情報及びコンセント情報を含むシステム登録要求を制御サーバ10に送信する(ステップS12)。
システム登録要求の受信に応じて、制御サーバ10は、パスポート情報をDCS20に送信することで対応する搭乗券情報を取得する(ステップS13)。
搭乗券情報を取得すると、制御サーバ10は、生体情報、パスポート情報、搭乗券情報及びコンセント情報を含むトークン発行要求を認証サーバに送信する(ステップS14)。利用者がオンプレミス型空港を利用する場合、制御サーバ10は、専用サーバ30にトークン発行要求を送信する。利用者がクラウド型空港を利用する場合、制御サーバ10は、共用サーバ50にトークン発行要求を送信する。
認証サーバは、受信した4つの情報をトークン管理データベースに登録することでトークンを発行する(ステップS15)。とりわけ、共用サーバ50は、制御サーバ10から受信したトークン発行要求に応じて、利用者のトークンを発行し、当該発行されたトークンを、複数の空港ごとに用意されたトークン管理データベースに記憶する。
続いて、第1の実施形態に係る変形例について説明する。
<第1の実施形態に係る変形例1>
上記第1の実施形態では、制御サーバ10がDCS20から搭乗券情報を取得する場合について説明した。しかし、端末60がDCS20から搭乗券情報を取得してもよい。具体的には、端末60のシステム登録制御部607は、航空券情報から得られる航空会社のDCSサーバにパスポート情報を送信することで搭乗券情報を取得してもよい。
この場合、システム登録制御部607は、生体情報、パスポート情報、搭乗券情報及びコンセント情報を含むシステム登録要求を制御サーバ10に送信する。制御サーバ10は、コンセント情報又は搭乗券情報に基づいて利用者が利用する空港を特定する。制御サーバ10は、当該特定された空港に応じてトークン発行要求を認証サーバ(専用サーバ30、共用サーバ50)に送信する。
あるいは、端末60(モバイルアプリ)は、チェックイン端末41等から発行された搭乗券を撮影することで搭乗券情報を取得してもよい。この場合、情報提供に対する利用者の同意が取得されると、システム登録制御部607は、利用者の操作に応じて搭乗券を撮影する。システム登録制御部607は、搭乗券を撮影することで得られる画像データから搭乗券情報を生成(抽出)する。その後、システム登録制御部607は、生体情報、パスポート情報、搭乗券情報及びコンセント情報を含むシステム登録要求を制御サーバ10に送信する。あるいは、端末60は、搭乗券に記載された2次元バーコードから搭乗券情報を取得してもよい。即ち、端末60は、搭乗券に記載されたバーコードを読み取る機能を備えていてもよい。
あるいは、モバイルアプリとは異なるアプリケーションが取得した搭乗券情報が制御サーバ10に送信されてもよい。
例えば、図18Aに示すように、モバイルアプリ(システム登録制御部607)は、航空会社が利用者に提供するエアラインアプリから搭乗券情報を取得してもよい。利用者は、エアラインアプリを用いてチェックイン手続きを完了する。チェックイン手続きの完了と共にエアラインアプリは、DCSサーバから搭乗券情報を取得する。エアラインアプリは、取得した搭乗券情報をモバイルアプリに引き渡す。端末60のシステム登録制御部607は、取得した搭乗券情報を含むシステム登録要求を制御サーバ10に送信する。
あるいは、図18Bに示すように、エアラインアプリにモバイルアプリの機能が実装されていてもよい。この場合にも、システム登録制御部607は、取得した搭乗券情報を含むシステム登録要求を制御サーバ10に送信する。
あるいは、図18Cに示すように、モバイルアプリは、クレジットカード、交通系ICカード、コンサートのチケット等を管理するウォレットアプリから搭乗券情報を取得してもよい。このように、モバイルアプリは、他社のアプリケーションと連携して搭乗券情報を取得してもよい。
このように、システム登録制御部607は、パスポート情報を、利用者が搭乗する航空機を運航する航空会社のDCSサーバに送信することで、搭乗券情報を取得してもよい。その場合、システム登録制御部607は、生体情報、パスポート情報、搭乗券情報及びコンセント情報を含むシステム登録要求を、認証サーバと接続された制御サーバ10に送信してもよい。
<第1の実施形態に係る変形例2>
上記第1の実施形態では、利用者からの同意取得の対象は、チェックイン手続きが完了した1枚の搭乗券に対応する搭乗手続きに関する情報提供であることを前提としている。しかし、航空機に搭乗するタイミングによっては複数の搭乗券に対応する搭乗手続きが同意取得の対象となることもある。
例えば、第1国から第2国に移動する際の搭乗手続きと、第2国から第3国に移動する際の搭乗手続きそれぞれがシステム登録(空港等に情報提供)の対象となることもある。この場合、端末60の同意取得制御部606は、複数の同意取得の対象となっている搭乗手続き(航空券)を表示し、利用者が同意を与える手続きを選択可能としてもよい。
例えば、同意取得制御部606は、図19に示すように、同意取得の対象となる手続き(航空券)の一覧を表示し、当該一覧表示された航空券のなかから、情報提供に対する同意を与える対象を利用者が選択可能としてもよい。
同意取得制御部606は、図19に示すようなGUIを用いて同意取得の対象手続きを取得する。同意取得制御部606は、取得した対象手続きに関し、図6に示すようなGUIを用いて利用者の同意を取得する。システム登録制御部607は、利用者が選択した航空券(搭乗手続き)に関してシステム登録を制御サーバ10に要求すればよい。
このような端末60の構成により、利用者は、フライトの内容(情報提供先の空港や利用する航空会社)を考慮して個人情報の提供可否を個別に判断できる。例えば、図19において、下段のフライトで利用する空港A3の情報管理等に不安がある場合には、利用者は、当該フライトに関する情報提供を拒否するといった選択が可能になる。
<第1の実施形態に係る変形例3>
管理センター(制御サーバ10)は、利用者の端末60からシステム登録要求を受信するだけでなく、他の管理センターからのシステム登録要求を受信してもよい。あるいは、管理センター(制御サーバ10)は、利用者の端末60から受信したシステム登録要求を他の管理センターに送信してもよい。
例えば、図20に示すように、第1の本人確認プラットフォーム(Biometrics Hub)の制御サーバ10-1から第2の本人確認プラットフォームの制御サーバ10-2にシステム登録要求が送信されてもよい。
この場合、制御サーバ10-1のシステム登録制御部202は、端末60から受信したシステム登録要求が自システムで管理する空港宛てではないと判定した場合、自システムに接続された他の制御サーバ10-2にシステム登録要求を送信(転送)する。
他の制御サーバ10からシステム登録要求を受信したシステム登録制御部202は、当該システム登録要求を自システムに含まれる空港宛てのシステム登録要求と判定した場合、上記説明したトークン発行要求を認証サーバに送信する。
このように、制御サーバ10は、他のシステムからシステム登録要求(トークン生成に必要な4情報を含む要求)を受信した場合、自システムで管理する空港の認証サーバにトークン発行要求を送信してもよい。即ち、制御サーバ10は、他のシステムから受信したシステム登録要求に応じて、トークン発行要求を共用サーバ50又は専用サーバ30に送信してもよい。
<第1の実施形態に係る変形例4>
個人情報の外部提供に関する規則、法律等は国によって異なる。情報提供に関する法律等は利用者の所在国により判断されるのが原則である。例えば、利用者の所在国がA国であれば、端末60から外部に情報提供される際に適用される法律はA国の法律である。換言すれば、B国に滞在する利用者がA国の空港を利用する場合、当該B国に滞在する利用者の情報提供に適用される法律はB国の法律である。
ここで、B国における個人情報の提供に関する法律等が、他国に個人情報を提供することを禁止している場合、上記B国に滞在する利用者の端末60は当該利用者の個人情報を外部に提供できないし、制御サーバ10も当該利用者の個人情報を取得できない。
そこで、端末60(モバイルアプリ)及び/又は制御サーバ10は、利用者の所在国の法律等を遵守するための制御を行う。
具体的には、端末60の同意取得制御部606は、GPS(Global Positioning System)等を用いて自装置の位置情報を取得する。同意取得制御部606は、利用者の利用空港の所在国と利用者の所在国が異なる場合、システム登録できない旨(生体認証のための情報提供ができない旨)を利用者に通知する。
あるいは、同意取得制御部606は、国ごとに個人情報の外部提供可否等を記憶し、システム登録(個人情報の外部提供)が当該利用者の所在国の法律等に抵触すると判定した場合に、上記システム登録ができない旨を利用者に通知してもよい。
このように、端末60(モバイルアプリ)の同意取得制御部606は、利用者の所在国と利用者が利用する空港の所在国が異なる場合、搭乗手続きを生体認証により進めるための情報を外部に提供することに対する利用者の同意を取得しない。
また、制御サーバ10のシステム登録制御部202は、端末60のIPアドレス等に基づいて利用者の所在国を判定してもよい。利用者が利用空港の所在国と異なる国に滞在していると判定された場合、システム登録制御部202は、利用者のシステム登録要求を拒否してもよい。あるいは、システム登録制御部202は、国ごとのシステム登録要求の受入可否を記載したリストを用いてもよい。
上記国ごとのリストが適宜更新されること、又は、モバイルアプリのバージョンが更新されることにより、個人情報提供に関する法律遵守と利用者の利便性向上の両立が実現される。
以上のように、第1の実施形態に係る端末60は、トークンを発行するために必要な情報(生体認証により搭乗手続きを進めるために必要な情報)である、生体情報、パスポート情報及びコンセント情報を取得し、内部に記憶する。端末60は、空港における搭乗手続き前に、上記情報を制御サーバ10に送信する。制御サーバ10は、パスポート情報及びコンセント情報に基づいて、搭乗券情報を取得する。制御サーバ10は、生体情報、パスポート情報、搭乗券情報及びコンセント情報を認証サーバに送信する。認証サーバ(専用サーバ30、共用サーバ50)は、これら4情報を用いてトークンを生成し、トークン管理データベースに記憶する。共用サーバ50は、利用者の搭乗手続きが終了すると(航空機が出発すると)、上記4つの情報からなるトークンを削除する。その結果、認証サーバは、必要最低限な期間において利用者の生体情報、パスポート情報等を記憶すればよく、個人情報の管理負担が低減する。即ち、生体情報等の個人情報は、当該個人情報が使用される期間に限り有効となり、当該情報の利用が終了すると共に削除される。換言すれば、システムが個人情報(生体情報等)を必要としない期間は、当該個人情報は中央のサーバ(認証サーバ)に保持されない。また、認証サーバは、コンセント情報を記憶することで、利用者の明確な同意の下、生体情報等の個人情報を記憶できる。また、認証サーバに構築されたトーク管理データベースのエントリ数(トークン数)が減少するので、認証精度が向上する。
さらに、利用者は、端末60にインストールされたモバイルアプリを用いることで、航空機の利用者に関する種々の操作、手続きを行える。利用者は、事前に、所持する端末60に必要な情報を登録しておくことで、航空機の利用日に搭乗手続きのための情報(搭乗手続き情報)を簡単な操作でシステムに登録することができる。モバイルアプリは、生体認証による手続きに必要なトークン(生体情報、パスポート情報、コンセント情報等)を取得、管理する機能を備える。モバイルアプリは、生体情報管理機能、パスポート情報管理機能、搭乗券情報(航空券情報)管理機能、コンセント情報管理機能等を備える。
さらに、制御サーバ10は、トークンを生成するために必要な情報(顔画像、パスポート情報、搭乗券情報、コンセント情報)を認証サーバ(専用サーバ30、共用サーバ50)に送信する。ここで、自社で生体認証を行うためのサーバ(専用サーバ30)を用意できない空港であっても、当該空港は、共用サーバ50を活用することで生体認証を用いた搭乗手続きを利用者に提供できる。空港会社は、自社のニーズに沿った認証端末40を空港内に設置するだけで生体認証システムを容易且つ低コストで構築できる。また、システムに、既に生体認証システムに対応している空港が含まれる場合、制御サーバ10は、トークン生成に必要な情報を当該空港の専用サーバ30に送信する。制御サーバ10が、利用者の利用空港に応じてトークン生成に必要な情報の送信先を変更することで、既に生体認証システムに対応している空港と、新規に生体認証システムに対応する空港の併存が可能になる。
[第2の実施形態]
続いて、第2の実施形態について図面を参照して詳細に説明する。
第2の実施形態では、利用者がモバイルアプリを用いてシステム登録をした後、出発空港において座席が変更された場合(搭乗券情報が変更された場合)のトークン更新について説明する。
なお、第2の実施形態に係る情報処理システムの構成は第1の実施形態と同一とすることができるので図3に相当する説明を省略する。
以下、第1の実施形態と第2の実施形態の相違点を中心に説明する。
搭乗しようとしている航空機の座席の変更が行われたことを航空会社の職員から伝えられた利用者は、端末60を操作してトークン(システム登録された情報)の更新を行う。
例えば、利用者は、モバイルアプリにおいて所定の操作(例えば、シートチェンジボタンの押下)を行う。当該操作に応じて、端末60のシステム登録制御部607は、少なくとも直前に送信したパスポート情報及びコンセント情報を含む「システム再登録要求」を制御サーバ10に送信する(図21参照)。
システム再登録要求を受信すると、制御サーバ10のシステム登録制御部202は、当該システム再登録要求に含まれるパスポート情報を、利用者が利用する航空会社のDCSサーバに送信することで搭乗券情報を取得する。
当該取得された搭乗券情報は、既に行われたシートチェンジが反映されている。制御サーバ10は、少なくとも再取得した搭乗券情報及びパスポート情報を含む「トークン更新要求」を認証サーバに送信する。
専用サーバ30のトークン制御部302や共用サーバ50のトークン制御部402は、トークン更新要求に含まれるパスポート情報からトークンを更新する対象者(エントリ、トークン)を特定する。トークン制御部302等は、特定したトークンの搭乗券情報をトークン更新要求に含まれる搭乗券情報に置き換える。
このように、端末60のシステム登録制御部607は、利用者に発行された搭乗券が変更になった場合、パスポート情報及びコンセント情報を含むシステム再登録要求を制御サーバ10に送信する。制御サーバ10は、システム再登録要求に含まれるパスポート情報を、コンセント情報に含まれる航空会社に関する情報に対応する航空会社のDCSサーバに送信することで、変更後の搭乗券に関する搭乗券情報を取得する。制御サーバ10は、取得した変更後の搭乗券情報及びパスポート情報を含むトークン更新要求を認証サーバに送信する。
<第2の実施形態に係る変形例>
シートチェンジが行われた際、DCSサーバが、シートチェンジ後の搭乗券(搭乗券情報)とパスポート情報を制御サーバ10や認証サーバに送信してもよい。
具体的には、DCSサーバは、シートチェンジ後の搭乗券情報とパスポート情報を含むトークン更新要求を制御サーバ10に送信してもよい。この場合、制御サーバ10は、搭乗券情報に基づいて更新対象となるトークンを保有する認証サーバ(専用サーバ30、共用サーバ50)を特定する。制御サーバ10は、特定した認証サーバに対して、上記変更後の搭乗券情報とパスポート情報を含むトークン更新要求を送信すればよい。
あるいは、DCSサーバは、シートチェンジ後の搭乗券情報及びパスポート情報を含むトークン更新要求を、直接認証サーバに送信してもよい。
このように、DCS20からシートチェンジ後の搭乗券情報が認証サーバに送信されることで認証サーバのトークンが更新されてもよいし、利用者がトークン再発行(トークン更新)の手続きをモバイルアプリで行うことでトークンが更新されてもよい。
以上のように、第2の実施形態に係る情報処理システムは、航空会社により行われたシートチェンジに対応する。シートチェンジに対応することで、利用者は引き続き、生体認証により搭乗手続きを進めることができる。
[第3の実施形態]
続いて、第3の実施形態について図面を参照して詳細に説明する。
第3の実施形態では、認証サーバがトークン発行に関する履歴を記憶し、当該トークン発行履歴が航空会社等に提供される場合について説明する。
なお、第3の実施形態に係る情報処理システムの構成は第1の実施形態と同一とすることができるので図3に相当する説明を省略する。
以下、第1の実施形態乃至第3の実施形態の相違点を中心に説明する。
第3の実施形態に係る制御サーバ10は、トークン生成要求を認証サーバに送信する際、当該トークン生成要求の送信がモバイルアプリからシステム登録要求を受信したことに起因することを当該認証サーバに通知する。
例えば、制御サーバ10(システム登録制御部202)は、モバイルアプリを仮想的なタッチポイントに見立て、当該モバイルアプリに仮想的なIDを付与する。具体的には、システム登録制御部202は、受信したシステム登録要求に含まれる4情報と共に、上記モバイルアプリに付与した仮想的なID(以下、仮想端末IDと表記する)を含むトークン発行要求を認証サーバに送信する。
なお、仮想端末IDは、航空会社ごとに設定される。例えば、同じ端末60のモバイルアプリからシステム登録要求を受信した場合であっても、航空会社A宛てのトークン発行要求に含まれる仮想端末IDと航空会社B宛てのトークン発行要求に含まれる仮想端末IDは異なる。
ここで、上述のように、利用者は、認証端末40(タッチポイント)からシステム登録をすることもできる。その際、認証端末40は、トークン発行に必要な4情報(生体情報、パスポート情報、搭乗券情報、コンセント情報)と共に端末IDを認証サーバに送信する。
認証サーバは、トークン発行要求に含まれるID(端末ID、仮想端末ID)を用いて、トークンを発行する航空会社を把握できる。
専用サーバ30のトークン制御部302や共用サーバ50のトークン制御部402は、トークン発行要求の受信に従いトークンを発行すると、当該トークン発行に関する履歴をデータベースに記憶する。
具体的には、トークン制御部302等は、トークン発行要求に含まれるID(端末ID、仮想端末ID)に基づいて、トークン発行が要求された航空会社とトークン発行要求の送信元(タッチポイント、システム登録要求を送信したモバイルアプリ)を特定する。
トークン制御部302は、トークンを発行した日時、上記特定した航空会社及び送信元をトークン発行履歴データベースに記憶する(図22参照)。なお、図22に示すトークン発行履歴データベースは例示であって、記憶する項目等を限定する趣旨ではない。
図23は、第3の実施形態に係る専用サーバ30の処理構成(処理モジュール)の一例を示す図である。図23を参照すると、第1の実施形態に係る専用サーバ30の構成に情報提供制御部305が追加されている。
図24は、第3の実施形態に係る共用サーバ50の処理構成(処理モジュール)の一例を示す図である。図24を参照すると、第1の実施形態に係る共用サーバ50の構成に情報提供制御部405が追加されている。
情報提供制御部305及び情報提供制御部405の動作は、同一とすることができる。情報提供制御部305等は、認証サーバの情報を外部に提供する制御を行う手段である。
例えば、情報提供制御部305等は、航空会社の職員等の要求に応じて、トークン発行履歴に関する情報提供を行う。例えば、図22の例において、航空会社A1のトークン発行履歴の提供を要求された場合、情報提供制御部305は、図22に示すトークン発行履歴データベースの1、3~5行目のエントリを抽出し、当該抽出したエントリを航空会社A1に提供する。
情報提供を受けた航空会社は、空港に設置されたタッチポイントからのトークン発行率、モバイルアプリからのトークン発行率等を算出することができる。例えば、上述の例では、モバイルアプリからのトークン発行率は75%(3/4)と計算される。
なお、情報提供制御部305は、航空会社が必要とする情報を入力可能とするインターフェイスを航空会社等に提供してもよい。例えば、情報提供制御部305は、航空会社の職員等がトークン発行履歴を抽出する期間を指定できるようなインターフェイスを用意してもよい。また、情報提供制御部305は、トークン発行履歴を航空会社のサーバに送信してもよいし、職員が操作する端末に送信してもよい。
このように、共用サーバ50及び専用サーバ30のそれぞれは、空港に設置されたタッチポイントからトークン発行要求を受信したことに応じて、トークンを発行する。当該タッチポイントから送信されるトークン発行要求には、タッチポイントを識別する端末IDが含まれる。また、制御サーバ10は、端末60からシステム登録要求を受信すると、端末60(モバイル端末)に仮想端末IDを付与し、仮想端末IDを含むトークン発行要求を共用サーバ50又は専用サーバ30に送信する。共用サーバ50又は専用サーバ30は、端末ID及び仮想端末IDに基づいてトークン発行要求の送信元を含むトークン発行履歴を生成する。共用サーバ50又は専用サーバ30は、生成されたトークン発行履歴に関する情報提供を行う。
<第3の実施形態に係る変形例1>
認証サーバは、図22に示すトークン発行履歴データベースに、トークン発行を要求した利用者の属性情報(例えば、年齢、性別、国籍等)を記憶してもよい。また、情報提供制御部305は、トークン発行履歴データベースに記憶された利用者の属性情報を用いて航空会社等に提供する情報を生成してもよい。例えば、情報提供制御部305は、属性(年齢、性別、国籍等)ごとのモバイルアプリを使ったトークン発行率を計算してもよい。
<第3の実施形態に係る変形例2>
情報提供制御部305等は、トークン管理データベースから得られる情報を空港会社の職員等が閲覧可能としてもよい。即ち、情報提供制御部305は、空港会社にダッシュボード機能を提供してもよい。
<第3の実施形態に係る変形例3>
モバイルアプリによるトークン生成率を向上させるため、モバイルアプリを用いてシステム登録を行った利用者に対して特典が付与されてもよい。例えば、モバイルアプリを用いてシステム登録を行った利用者に対して所定数のマイルポイントが付与されてもよい。その結果、モバイルアプリを用いたシステム登録が促進され、チェックイン端末41等の設置台数の削減が可能になる。即ち、モバイルアプリを用いる利用者を増やすことで航空会社等のコストダウンが実現される。
以上のように、第3の実施形態に係る情報処理システムは、トークン生成に関する情報提供を行う。とりわけ、認証サーバは、トークン発行の要求元(タッチポイント、モバイルアプリ)に関する情報を航空会社等に提供する。ここで、航空会社等は、生体認証をより積極的に活用したいと考えている。しかし、航空会社等は、トークン生成のための装置を数多く空港に設置することをコストの観点から躊躇する。そこで、航空会社は、モバイルアプリを活用したシステム登録を希望し、モバイルアプリによるトークン生成率(生体認証利用率)を向上させるための取り組み等を検討する。当該取り組みの成果を把握するため、航空会社には、モバイルアプリによるトークン生成率を把握したいというニーズが存在する。制御サーバ10は、モバイルアプリからのトークン生成要求に仮想端末IDを設定することで、トークン発行の要求元を区別可能とし、モバイルアプリによるトークン生成率の算出を可能とする。
続いて、情報処理システムを構成する各装置のハードウェアについて説明する。図25は、制御サーバ10のハードウェア構成の一例を示す図である。
制御サーバ10は、情報処理装置(所謂、コンピュータ)により構成可能であり、図25に例示する構成を備える。例えば、制御サーバ10は、プロセッサ311、メモリ312、入出力インターフェイス313及び通信インターフェイス314等を備える。上記プロセッサ311等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。
但し、図25に示す構成は、制御サーバ10のハードウェア構成を限定する趣旨ではない。制御サーバ10は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス313を備えていなくともよい。また、制御サーバ10に含まれるプロセッサ311等の数も図25の例示に限定する趣旨ではなく、例えば、複数のプロセッサ311が制御サーバ10に含まれていてもよい。
プロセッサ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)等を備える。
制御サーバ10の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ312に格納されたプログラムをプロセッサ311が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント(non-transitory)なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。
なお、専用サーバ30、認証端末40等も制御サーバ10と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は制御サーバ10と相違する点はないので説明を省略する。
情報処理装置である制御サーバ10は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることで制御サーバ10の機能が実現できる。また、制御サーバ10は、当該プログラムにより制御サーバ10の制御方法を実行する。
[変形例]
なお、上記実施形態にて説明した情報処理システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。
上記実施形態では、端末60は、航空券情報を取得することで、利用者から同意を得る内容(例えば、情報提供先となる空港名、利用する航空会社)を自動的に表示することを説明した。しかし、端末60は、情報提供先となる空港名や利用する航空会社を取得するためのGUI等を利用者に提供してもよい。即ち、端末60は、航空券情報を取得することに代えて、情報提供先の空港や利用する航空会社を利用者が入力するインターフェイスを当該利用者に提供してもよい。
上記認証サーバが生成したトークンは、搭乗手続きだけではなく、入国手続きに用いられてもよい。具体的には、税関手続き、入国審査、検疫手続き等にトークンが使用されてもよい。
管理センター(制御サーバ10)は、システム使用料に関する管理機能、集計機能を備えていてもよい。制御サーバ10は、モバイルアプリによるトークン生成量や他のシステムによるトークン生成量を管理し、各航空会社に対してトークン生成量に応じた手数料の支払いを要求してもよい。
上記実施形態では、制御サーバ10と共用サーバ50は異なる装置として説明した。しかし、制御サーバ10が、共用サーバ50の機能を備えていてもよい。即ち、制御サーバ10及び共用サーバ50は、クラウド上に構築されたサーバであってもよい。
上記実施形態では、認証サーバが利用者のゲート通行可否等を判定する場合について説明した。しかし、認証端末40が、当該判定を実行してもよい。例えば、認証サーバが照合処理により特定されたエントリのパスポート情報及び搭乗券情報を認証端末40に送信する。認証端末40は、取得したパスポート情報及び搭乗券情報を用いて被認証者のゲート通行可否等を判定してもよい。
上記実施形態では、顔画像に係る生体情報が認証サーバと認証端末40の間で送受信される場合について説明した。しかし、顔画像から生成された特徴量が上記装置間で送受信されてもよい。この場合、受信側の認証サーバが、受信した特徴量を利用し、その後の処理に活用してもよい。あるいは、トークン管理データベースに記憶される生体情報は特徴量であってもよいし顔画像であってもよい。顔画像が記憶されている場合には、必要に応じて顔画像から特徴量が生成されればよい。あるいは、顔画像と特徴量の両方がトークン管理データベースに記憶されていてもよい。
上記実施形態では、制御サーバ10の内部にトークン管理データベースが構成される場合について説明したが、当該トークン管理データベースは外部のデータベースサーバ等に構築されてもよい。即ち、制御サーバ10等の一部の機能は別のサーバに実装されていてもよい。より具体的には、上記説明した「システム登録制御部(システム登録制御手段)」等がシステムに含まれるいずれかの装置に実装されていればよい。
各装置(制御サーバ10、端末60等)間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、パスポート情報等が送受信され、個人情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。
上記説明で用いた流れ図(フローチャート、シーケンス図)では、複数の工程(処理)が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。
上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。
上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、航空機等を利用する利用者に関する情報処理システムなどに好適に適用可能である。
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
[付記1]
複数の空港によって認証処理を行うサーバとして共用される、共用サーバと、
1つの空港における認証処理を行う、専用サーバと、
制御サーバと、
を含み、
前記制御サーバは、利用者が利用する空港を判定し、前記利用者が利用する空港に応じて、前記利用者が搭乗手続きを生体認証により進めるために必要な情報を前記共用サーバ又は前記専用サーバのいずれかに送信する、システム。
[付記2]
前記制御サーバは、前記利用者の生体情報と、前記利用者のパスポートに関するパスポート情報と、前記利用者に発行された搭乗券に関する搭乗券情報と、前記生体情報を含む情報が前記共用サーバ又は前記専用サーバに提供されることに対する利用者の同意に関するコンセント情報と、を含むトークン発行要求を前記共用サーバ又は前記専用サーバのいずれかに送信する、付記1に記載のシステム。
[付記3]
前記コンセント情報には、前記利用者が利用する空港に関する情報が含まれ、
前記制御サーバは、前記コンセント情報に含まれる空港に関する情報に基づいて、前記トークン発行要求の送信先を決定する、付記2に記載のシステム。
[付記4]
前記コンセント情報には、前記利用者が搭乗予定の航空機を運航する航空会社に関する情報が含まれ、
前記制御サーバは、
前記利用者が所持する端末から、前記生体情報、前記パスポート情報及び前記コンセント情報を含むシステム登録要求を受信し、
前記コンセント情報に含まれる航空会社に関する情報に対応する航空会社のDCS(Departure Control System)サーバに前記パスポート情報を送信することで前記利用者に発券された搭乗券に関する搭乗券情報を取得する、付記3に記載のシステム。
[付記5]
前記共用サーバは、前記制御サーバから受信したトークン発行要求に応じて、前記利用者のトークンを発行し、前記発行されたトークンを、前記複数の空港ごとに用意されたトークン管理データベースに記憶する、付記4に記載のシステム。
[付記6]
前記制御サーバは、他のシステムから受信した前記システム登録要求を前記共用サーバ又は前記専用サーバに送信する、付記5に記載のシステム。
[付記7]
前記共用サーバ及び前記専用サーバのそれぞれは、空港に設置されたタッチポイントから前記トークン発行要求を受信したことに応じて、前記トークンを発行する、付記6に記載のシステム。
[付記8]
前記タッチポイントから送信される前記トークン発行要求には、前記タッチポイントを識別する端末IDが含まれ、
前記制御サーバは、前記端末から前記システム登録要求を受信すると、前記端末に仮想端末IDを付与し、前記仮想端末IDを含む前記トークン発行要求を前記共用サーバ又は前記専用サーバに送信する、付記7に記載のシステム。
[付記9]
前記共用サーバ又は前記専用サーバは、前記端末ID及び前記仮想端末IDに基づいてトークン発行の要求元を含むトークン発行履歴を生成し、前記生成されたトークン発行履歴に関する情報提供を行う、付記8に記載のシステム。
[付記10]
前記生体情報は、顔画像又は前記顔画像から生成された特徴である、付記9に記載のシステム。
[付記11]
前記共用サーバは、クラウドに設置されたサーバである、付記1乃至10のいずれか一項に記載のシステム。
[付記12]
複数の空港によって認証処理を行うサーバとして共用される共用サーバと、1つの空港における認証処理を行う専用サーバと、通信を行う、サーバであって、
利用者が利用する空港を判定する、判定部と、
前記利用者が利用する空港に応じて、前記利用者が搭乗手続きを生体認証により進めるために必要な情報を前記共用サーバ又は前記専用サーバのいずれかに送信する、登録部と、
を備える、サーバ装置。
[付記13]
複数の空港によって認証処理を行うサーバとして共用される、共用サーバと、1つの空港における認証処理を行う、専用サーバと、通信を行う、サーバ装置において、
利用者が利用する空港を判定し、
前記利用者が利用する空港に応じて、前記利用者が搭乗手続きを生体認証により進めるために必要な情報を前記共用サーバ又は前記専用サーバのいずれかに送信する、サーバ装置の制御方法。
[付記14]
複数の空港によって認証処理を行うサーバとして共用される、共用サーバと、1つの空港における認証処理を行う、専用サーバと、通信を行う、サーバ装置に搭載されたコンピュータに、
利用者が利用する空港を判定する処理と、
前記利用者が利用する空港に応じて、前記利用者が搭乗手続きを生体認証により進めるために必要な情報を前記共用サーバ又は前記専用サーバのいずれかに送信する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。
なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。