(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-13
(45)【発行日】2024-06-21
(54)【発明の名称】チケット所有者とセルフサービス機能とのインタラクションシステムおよび方法
(51)【国際特許分類】
G06Q 50/40 20240101AFI20240614BHJP
A45C 13/22 20060101ALI20240614BHJP
H04M 1/00 20060101ALI20240614BHJP
【FI】
G06Q50/40
A45C13/22 Z
H04M1/00 R
(21)【出願番号】P 2019539782
(86)(22)【出願日】2018-11-02
(86)【国際出願番号】 EP2018080053
(87)【国際公開番号】W WO2019086630
(87)【国際公開日】2019-05-09
【審査請求日】2021-11-02
(32)【優先日】2017-11-03
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2017-11-06
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】519260603
【氏名又は名称】シータ イペンブルグ ビー ブイ
【氏名又は名称原語表記】SITA YPENBURG B.V.
(74)【代理人】
【識別番号】100147485
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100163511
【氏名又は名称】辻 啓太
(72)【発明者】
【氏名】アンドリュー イー マリノフスキー
(72)【発明者】
【氏名】レインアウト ヴァンダー ミューレン
(72)【発明者】
【氏名】バート ルネ イヴォンヌ ホウレバース
(72)【発明者】
【氏名】リコ アンドレアス バランドゥン
【審査官】小原 正信
(56)【参考文献】
【文献】国際公開第2017/030799(WO,A1)
【文献】特表2013-543153(JP,A)
【文献】米国特許出願公開第2015/0095254(US,A1)
【文献】米国特許出願公開第2010/0078475(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
A45C 13/22
H04M 1/00
(57)【特許請求の範囲】
【請求項1】
チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法であって、
前記チケットに関するチケット情報および当該チケットに関連する前記セルフサービス機能に関する情報が格納されているモバイルデバイスによ
り、
前記セルフサービス機能
を有するユニットの付近に設置されたビーコンと通信することで、前記セルフサービス機能を有するユニットへの近接を検出
し、該検出を示す情報をクラウドブローカサービスを提供するサーバに送信するステップと、
前記チケット情報を照会し、当該チケット情報を前記サーバに通信するステップと、
前記モバイルデバイスが該セルフサービス機能
を有するユニットへの近接を検出したら、前記モバイルデバイス上で、前記セルフサービス機能に関連するアプリケーション
又はウェブセッションを起動するステップと、
前記サーバにより、
前記モバイルデバイスを介して
前記ビーコンと通信し、前記セルフサービス機能
を有するユニットの識別子を取得するステップと、
前記モバイルデバイスと
前記クラウドブローカサービスとの間に第1の接続セッションを確立するステップと、
前記セルフサービス機能
を有するユニットと前記クラウドブローカサービスとの間に第2の接続セッションを確立するステップと、
前記クラウドブローカサービスを介して、
前記モバイルデバイスから取得した、前記モバイルデバイスの識別子と前記セルフサービス機能
を有するユニットの
識別子とを対応付けることにより、前記第1の接続セッション及び前記第2の接続セッションを介したエンドツーエンドセッションを生成するステップと、
前記クラウドブローカサービスを通じて、前記セルフサービス機能
を有するユニットから前記モバイルデバイスの前記アプリケーションへと通信するステップと、
前記モバイルデバイスからの前記チケット情報の受信に応答して、前記チケット所有者に提示するために、前記セルフサービス機能に関する情報を前記アプリケーションに提供するステップと、を含み、
前記チケット所有者と前記セルフサービス機能との間のインタラクションに関する情報に
前記チケット所有者に対し、次に進むべき方向を前記モバイルデバイス上で提示するための方向情報が含まれており、前記クラウドブローカサービスは、前記エンドツーエンドセッションを介して前記モバイルデバイスと前記セルフサービス機能
を有するユニットとの間の通信用の単一の接続エンドポイントを公開する、方法。
【請求項2】
前記モバイルデバイスは、前記セルフサービス機能
を有するユニットへの近接を示すジオロケーションデバイスを検出する、請求項1に記載の方法。
【請求項3】
前記セルフサービス機能
を有するユニットがバッグドロップ
を前記チケット所有者から受け付けるバッグドロップユニットであり、
前記チケット情報が搭乗券であり、
前記モバイルデバイスにより、当該搭乗券の乗客情報を出発管理システムに通信するステップを含む、請求項1に記載の方法。
【請求項4】
前記出発管理システムによって、前記搭乗券に関連する手荷物が前記バッグドロップに適格であるかどうかを判定し、その適格性を前記モバイルデバイスに通信するステップを含む、請求項
3に記載の方法。
【請求項5】
前記バッグドロップ
ユニットでバッグを預け入れる際に、
前記バッグドロップユニットにより前記バッグの重量を測定し、当該重量が許容重量を超えているかどうかを判定し、当該重量が許容重量を超えている場合は、
前記モバイルデバイスにより、前記アプリケーションを介して超過手荷物料金の支払いを手配するステップを含む、請求項
3に記載の方法。
【請求項6】
前記バッグドロップ
ユニットでバッグタグを印刷し、当該バッグタグをバッグに固定する指示を、ユーザに提示するために、
前記サーバにより、前記アプリケーションを介して前記モバイルデバイスに通信するステップを含む、請求項
3に記載の方法。
【請求項7】
前記バッグドロップ
ユニットによるバッグの受領時に、搭乗および出発ゲートへのルートに関する情報を、
前記サーバにより、前記アプリケーションに通信するステップを含む、請求項
3に記載の方法。
【請求項8】
チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法であって、
クラウドブローカサービスを提供するサーバと通信するモバイルデバイスであって、前記チケットに関するチケット情報が格納されているモバイルデバイスにより、
前記チケットに関連するセルフサービス機能
を有するユニットに近接する位置において、
前記セルフサービス機能に関連付けられた機械読み取り可能なコードをスキャン又は撮像して前記セルフサービス機能を有するユニットの識別子を取得し、前記モバイルデバイス上で、前記セルフサービス機能に関連するアプリケーション
又はウェブセッションを起動するステップと、
前記チケット情報を照会し、当該チケット情報を前記サーバに通信するステップと、
前記サーバにより、
前記モバイルデバイスと
前記クラウドブローカサービスとの間に第1の接続セッションを確立するステップと、
前記セルフサービス機能
を有するユニットと前記クラウドブローカサービスとの間に第2の接続セッションを確立するステップと、
前記クラウドブローカサービスを介して、
前記モバイルデバイスから取得した、前記モバイルデバイスの識別子と前記セルフサービス機能
を有するユニットの
識別子とを対応付けることにより、前記第1の接続セッション及び前記第2の接続セッションを介したエンドツーエンドセッションを生成するステップと、
前記クラウドブローカサービスを通じて、前記セルフサービス機能
を有するユニットから前記モバイルデバイスの前記アプリケーションへと通信するステップと、
前記モバイルデバイスからの前記チケット情報の受信に応答して、前記チケット所有者に提示するために、前記セルフサービス機能に関する情報を前記アプリケーションに提供するステップと、を含み、
前記チケット所有者と前記セルフサービス機能との間のインタラクションに関する情報に
前記チケット所有者に対し、次に進むべき方向を前記モバイルデバイス上で提示するための方向情報が含まれており、前記クラウドブローカサービスは、前記エンドツーエンドセッションを介して前記モバイルデバイスと前記セルフサービス機能
を有するユニットとの間の通信用の単一の接続エンドポイントを公開する、方法。
【請求項9】
前記
機械読み取り可能なコードは、一次元バーコードまたは二次元バーコードである、請求項
8に記載の方法。
【請求項10】
前記機械読み取り可能なコードは、QRコードである、請求項8に記載の方法。
【請求項11】
チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にするためのシステムであって、
セルフサービス機能
を有するユニットと、
前記チケットに関するチケット情報が格納されているモバイルデバイスと、
クラウドブローカサービスを提供する少なくとも1つのサーバとを備え、
前記モバイルデバイスが、
前記セルフサービス機能
を有するユニットに近接する位置
において、前記セルフサービス機能に関連付けられた機械読み取り可能なコードをスキャン又は撮像して前記セルフサービス機能を有するユニットの識別子を取得し、前記モバイルデバイス上で、前記セルフサービス機能に関連するアプリケーション又はウェブセッションを起動するステップと、
前記チケット情報を照会し、当該チケット情報を前記少なくとも1つのサーバに通信するステップとを実行するように構成され、
前記少なくとも1つのサーバが、
前記モバイルデバイスと
前記クラウドブローカサービスとの間に第1の接続セッションを確立するステップと、
前記セルフサービス機能
を有するユニットと前記クラウドブローカサービスとの間に第2の接続セッションを確立するステップと、
前記クラウドブローカサービスを介して、
前記モバイルデバイスから取得した、前記モバイルデバイスの識別子と前記セルフサービス機能
を有するユニットの
識別子とを対応付けることにより、前記第1の接続セッション及び前記第2の接続セッションを介したエンドツーエンドセッションを生成するステップと、
前記クラウドブローカサービスを通じて、前記セルフサービス機能
を有するユニットから前記モバイルデバイスの前記アプリケーションへと通信するステップと、
前記モバイルデバイスからの前記チケット情報の受信に応答して、前記チケット所有者に提示するために、前記セルフサービス機能に関する情報を前記アプリケーションに提供するステップと、を実行
するように構成され、
前記チケット所有者と前記セルフサービス機能との間のインタラクションに関する情報に
前記チケット所有者に対し、次に進むべき方向を前記モバイルデバイス上で提示するための方向情報が含まれており、前記クラウドブローカサービスは、前記エンドツーエンドセッションを介して前記モバイルデバイスと前記セルフサービス機能
を有するユニットとの間の通信用の単一の接続エンドポイントを公開する、システム。
【請求項12】
前記
機械読み取り可能なコードは、一次元バーコードまたは二次元バーコードである、請求項
11に記載のシステム。
【請求項13】
前記機械読み取り可能なコードは、QRコードである、請求項11に記載のシステム。
【請求項14】
出発管理システムを備え、前記セルフサービス機能
を有するユニットが、手荷物取扱いシステムとバッグドロップコントローラとを備えるバッグドロップ
ユニットであり、前記チケット情報が搭乗券であり、
前記モバイルデバイスが、前記搭乗券の乗客情報を
前記出発管理システムに通信することを
さらに実行するように構成されている、請求項1
1に記載のシステム。
【請求項15】
前記出発管理システムは、前記搭乗券に関連する手荷物が
バッグドロップに適格であるかどうかを判定し、その適格性を前記モバイルデバイスに通信するように構成されている、請求項1
4に記載のシステム。
【請求項16】
前記手荷物取扱いシステムは、前記バッグドロップ
ユニットでバッグが預けられた際に当該バッグの重量を測定し、当該重量が許容重量を超えていないかどうかを判定し、当該重量が許容重量を超えている場合には、前記アプリケーションを介して超過手荷物料金の支払いを手配するための計量装置を備える、請求項1
5に記載のシステム。
【請求項17】
前記手荷物取扱いシステムは、バッグタグを印刷するためのプリンタを備え、前記バッグドロップコントローラは、前記バッグタグをバッグに固定する指示を、ユーザに提示するために、前記アプリケーションを介して前記モバイルデバイスに通信するように構成されている、請求項1
5に記載のシステム。
【請求項18】
前記バッグドロップ
ユニットによるバッグの受領時に、前記
少なくとも1つのサーバが、搭乗および出発ゲートへのルートに関する情報を前記アプリケーションに通信する
ことをさらに実行するように構成されている、請求項14に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、手荷物の取扱いなどの旅客サービスとの自動化されたインタラクションに関する。特に、排他的ではないが、空港、港、鉄道、その他の大量輸送施設、会場、スタジアムおよびアリーナでの手荷物の取扱いに関する。
【背景技術】
【0002】
空港の環境において、手荷物のチェックインは、乗客にとって時間のかかるストレスの多い経験になる可能性がある。グランドスタッフが手荷物ごとにバッグタグ(バッグ用のタグ)を印刷し、それらのタグを手荷物に固定することを含む、手作業での低速なチェックインプロセスに起因して、混雑時には長い行列が形成され得る。
【0003】
手荷物のチェックインプロセスは、チェックインプロセスおよびメンテナンスに関連する人件費とともに、バッグのタグ付け機器の断続的な運用およびメンテナンス費用のために、空港および航空会社にとって高額の間接諸経費を必要とする。
【発明の概要】
【発明が解決しようとする課題】
【0004】
近年、これらの費用を削減し、チェックインプロセスを能率化し、かつ乗客の行列待ち時間を短縮するために、いくつかの措置が講じられている。例えば、現在、多くの航空会社は、乗客が空港に到着したときにバッグを預け入れるだけで済む、オンラインチェックインサービスを提供している。より最近では、一部の航空会社は、搭乗券をスキャンするとバッグタグが作成されて乗客によって貼り付けられる、半自動のセルフサービスのバッグドロップ(バッグの預け入れ)を導入している。一部の航空会社は、セルフサービスとグランドスタッフの支援とを組み合わせた設備を使用した、ハイブリッドアプローチを採用している。これらの手段は、上述の問題を軽減するために何らかの方法を講じているが、これらはすべて、乗客と、グランドエージェント、キオスク、またはその他のコンピュータ化された機器と、の間の何らかのインタラクションが必要である。これらの解決策は、空港のチェックインカウンタの大幅な変更およびセルフサービス機器への多大な投資を必要とするため、さらなる問題が生じる。どちらも、費用が高額であり、運用が複雑である。
【0005】
上述の問題に加えて、障害のある乗客のニーズに対する意識が高まっている。多くの国では、障害のある乗客および身体の不自由な乗客が空港で適切にサポートされるように法律が制定されている。例としては、EU規則1 107/2006があり、この規則において、チェックインならびに手荷物の登録および預け入れのプロセスは、障害のある乗客や身体の不自由な乗客への支援について空港が責任を負う領域として特定されている。既存の、あるいは将来の法律では、自動またはセルフサービスのバッグドロップによる問題解決策へのアクセスが必要であり、また、例えば、車椅子用に指定されたタッチアクセスの最大高さや、視覚障害のある乗客のための特定の追加の制御装置が必要になる場合がある。
【0006】
本発明は、これらの問題に対処し、これらの問題を改善することを目的とする。
【課題を解決しようとする手段】
【0007】
本発明の一態様によれば、チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法が提供され、当該方法は:チケットに関するチケット情報および当該チケットに関連するセルフサービス機能に関する情報が格納されているモバイルデバイスによって、セルフサービス機能への近接を検出するステップと、モバイルデバイスが該セルフサービス機能への近接を検出したら、モバイルデバイス上で、セルフサービス機能に関連するアプリケーションを起動するステップと、モバイルデバイスを介してビーコンと通信し、セルフサービス機能の識別子を取得するステップと、モバイルデバイスとクラウドブローカサービスとの間に第1の接続セッションを確立するステップと、セルフサービス機能とクラウドブローカサービスとの間に第2の接続セッションを確立するステップと、クラウドブローカサービスを介して、モバイルデバイスの識別子とセルフサービス機能の識別子とを対応付けることにより、第1の接続セッション及び第2の接続セッションを介したエンドツーエンドセッションを生成するステップと、クラウドブローカサービスを通じて、セルフサービス機能からモバイルデバイスのアプリケーションへと通信するステップと、を含み、チケット所有者とセルフサービス機能との間のインタラクションに関する情報にユーザに提示するための方向情報が含まれており、クラウドブローカサービスは、エンドツーエンドセッションを介してモバイルデバイスとセルフサービス機能との間の通信用の単一の接続エンドポイントを公開する。
【0008】
本発明はまた、チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にするためのシステムを提供し、当該システムは:セルフサービス機能と、チケットに関するチケット情報が格納されているモバイルデバイスと、少なくともジオロケーションデバイスであって、モバイルデバイスが、セルフサービス機能に近接する位置で当該ジオロケーションデバイスを検出し、ジオロケーションデバイスと通信してセルフサービス機能の識別子を取得するように構成されている、ジオロケーションデバイスと、少なくとも1つのサーバであって、モバイルデバイスが、該位置に近接するジオロケーションデバイスを検出したら、モバイルデバイス上で、セルフサービス機能に関連するアプリケーションを起動するステップと、モバイルデバイスとクラウドブローカサービスとの間に第1の接続セッションを確立するステップと、セルフサービス機能とクラウドブローカサービスとの間に第2の接続セッションを確立するステップと、クラウドブローカサービスを介して、モバイルデバイスの識別子とセルフサービス機能の識別子とを対応付けることにより、第1の接続セッション及び第2の接続セッションを介したエンドツーエンドセッションを生成するステップと、クラウドブローカサービスを通じて、セルフサービス機能からモバイルデバイスのアプリケーションへと通信するステップと、を実行するためのコンピュータソフトウェアが格納されている少なくとも1つのサーバと、を備え、チケット所有者とセルフサービス機能との間のインタラクションに関する情報にユーザに提示するための方向情報が含まれており、クラウドブローカサービスは、エンドツーエンドセッションを介してモバイルデバイスとセルフサービス機能との間の通信用の単一の接続エンドポイントを公開する。
【0009】
本発明の第2の態様は、チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法を提供し、当該方法は:チケットに関連するセルフサービス機能に近接する位置において、チケットに関するチケット情報が格納されているモバイルデバイス上で、セルフサービス機能に関連するアプリケーションを起動するステップと、モバイルデバイスを介してビーコンと通信し、セルフサービス機能の識別子を取得するステップと、モバイルデバイスとクラウドブローカサービスとの間に第1の接続セッションを確立するステップと、セルフサービス機能とクラウドブローカサービスとの間に第2の接続セッションを確立するステップと、クラウドブローカサービスを介して、モバイルデバイスの識別子とセルフサービス機能の識別子とを対応付けることにより、第1の接続セッション及び第2の接続セッションを介したエンドツーエンドセッションを生成するステップと、クラウドブローカサービスを通じて、セルフサービス機能からモバイルデバイスのアプリケーションへと通信するステップと、を含み、チケット所有者とセルフサービス機能との間のインタラクションに関する情報にユーザに提示するための方向情報が含まれており、クラウドブローカサービスは、エンドツーエンドセッションを介してモバイルデバイスとセルフサービス機能との間の通信用の単一の接続エンドポイントを公開する。
【0010】
本発明の実施形態は、チケット所有者とセルフサービス機能とのインタラクションを単純化するという利点を有し得る。好ましい一実施形態では、セルフサービス機能は、例えば空港で使用される、バックドロップシステムである。本発明の実施形態は、バッグドロップとのインタラクションをより単純化し、航空会社または他のサービスプロバイダが、バッグドロップおよび他のセルフサービスプロセスに必要とされる対人のインタラクション量を減らすことを可能にし、したがってコストおよび間接諸経費を削減できるという利点を有し得る。
【0011】
本発明の一実施形態において、チケットは、乗客の旅に関するものであり、乗客および旅の識別を含んでいる。チケット情報には、搭乗券が含まれていてもよい。一実施形態において、その位置におけるモバイルデバイスの存在は、例えばBluetoothビーコンなどのジオロケーションデバイスを使用して検出され得る。
【0012】
一実施形態では、アプリケーションは、モバイルデバイスに格納されているチケット情報を照会し、チケット情報をリモートサーバに通信する。リモートサーバは、チケット情報の受信に応答して、モバイルデバイスのユーザに提示するために、セルフサービス機能に関する情報をアプリケーションに提供する。
【0013】
一実施形態では、セルフサービス機能がバッグドロップであり、チケットに関する情報が搭乗券であり、搭乗券の乗客情報は出発管理システムに通信される。出発管理システムは、搭乗券に関連する手荷物がバッグドロップに適格であるかどうかを判定し、その適格性をモバイルデバイスに通信する。
【0014】
本発明の一実施形態では、バッグドロップでバッグを預け入れる際に、バッグの重量が測定され、当該重量が許容重量を超えているかどうかが判定され、当該重量が許容重量を超えている場合は、アプリケーションを介して超過手荷物料金の支払いが手配される。
【0015】
一実施形態では、バッグドロップでバッグタグが印刷され、当該バッグタグをバッグに固定する指示は、ユーザに提示されるように、アプリケーションを介してモバイルデバイスに通信される。
【0016】
一実施形態では、バッグドロップによるバッグの受領時に、搭乗および出発ゲートへのルートに関する情報がアプリケーションに通信される。
【0017】
つぎに、本発明の実施形態を、単なる例として、添付の図面を参照して説明する。
【図面の簡単な説明】
【0018】
【
図2】本発明の一実施形態におけるステップを示すフローチャートである。
【
図4】システムの論理アーキテクチャを示す図である。
【
図5】クラウドサービスの論理アーキテクチャを示す図である。
【
図6】利用可能なインタフェースを示すサービスモデルを示すクラス図である。
【
図7】バッグユニットコントローラの概略図である。
【
図8】モバイルデバイスアプリケーションで生じるハイレベルなインタラクションを示す図である。
【
図9】モバイルアプリケーションのプロセスフローを示す図である。
【発明を実施するための形態】
【0019】
以下の例において、バッグドロップのシーケンスは、乗客のスマートフォン、タブレット、ノートパソコンまたは同様のモバイルコンピューティングデバイスから開始される。Bluetoothビーコンまたは他の位置センサなどのジオロケーション技術を使用して、モバイルデバイス上のアプリが特定のビーコンまたは他のデバイスの近くにあることを検出できるようにする。しかしながら、自動位置検出は、本発明に必須ではない。バッグドロップに関連して説明しているが、本発明の実施形態は、バッグタグや搭乗券の印刷、パスポートのスキャンまたは他の機能のための乗客処理キオスクなどの、他の乗客インタラクション、乗客のスマートフォンまたは他のデバイスを介したモバイル対応支払いとのインタラクション、セルフサービスのチェックポイントおよびゲート(自動の入出国審査ゲートまたはバリアなど)を含むがこれらに限定されない他の空港設備とのインタラクションと組み合わせて使用することもできる。実施形態は、特に空港に関連して説明されているが、本発明は、乗客がチェックインまたは手荷物の預け入れを要求されるあらゆる旅行環境への広範な適用性を有し、したがって海港および鉄道も含まれる。本発明の実施形態は、スポーツ会場やコンサートおよびフェスティバルなどのエンターテイメントなど、大量のチケットが発券されるイベントで、見物人および観客を導くのを助けるために使用することもできる。
【0020】
特に、空港での解決策に関連する図示の実施形態では、空港の周辺に配置されたBluetoothビーコンなどの位置特定技術を使用して、スマートフォン、タブレット、ノートパソコンまたは他のデバイスなどの乗客のモバイルデバイスが、特定のビーコンの存在を識別できるようにしている。他の屋内または屋外のジオロケーション技術を使用して、デバイスがその相対位置を識別できるようにする。しかしながら、明らかになるように、Bluetoothビーコンまたは他の位置特定技術は、好ましいが本発明に必須ではない。モバイルデバイスは、乗客がダウンロードするバッグドロップアプリケーションを有する。このアプリケーションは、独自のバッグドロップアプリであるか、あるいは航空会社または空港アプリのバッグドロップモジュールである。モバイルデバイス10は、例えば、それが空港に入って第1のビーコン12の近くを通過するときに、位置装置の存在を検出する。乗客が空港を通過してバッグドロップエリアに向かうと、デバイス10によって第2のビーコン14が検出され、該デバイスでバッグ預け入れアプリケーションが開始される。空港への進入時に乗客のモバイルデバイスが第1のビーコンを検出することは必須ではないが、デバイスによるビーコンの検出により、空港で提供される他のサービスとのインタラクションが可能になるため有利である。
【0021】
ビーコン検出を使用して、空港または同様の環境を通過する乗客の動きを追跡することは、国際公開第2013/117723号に記載されている。
【0022】
アプリケーションが開始されると、該アプリは、例えばApple(登録商標)ウォレットまたは同様のアプリを使用して、電話に格納されている乗客の搭乗券から該乗客の予約の詳細を照会するか、搭乗券が格納されていない場合、乗客のデバイスのカメラまたはバッグドロップにあるスキャナを使用して、印刷された搭乗券をスキャンするように乗客に求める。
【0023】
モバイル搭乗券がデバイスに格納されている場合、アプリは、格納された乗客関連データから、該乗客がバッグをチェックインしたかどうかを識別し、チェックインしていれば個数を識別する。バッグがチェックインされている場合、次に、アプリは、バッグドロッププロセスを進め方についての指示を乗客に表示する。バッグのチェックインが検出されない場合、アプリは、チェックインを許可するために、予約を修正するオプションを乗客に提供する。
【0024】
そのインタラクションが他のセルフサービス機能とのものである場合、プロセスは同様の方法で機能する。例えば、その機能がセルフサービスの入出国審査である場合、同様に、アプリは一意的なアプリまたは航空会社もしくは空港のアプリのモジュールであり、パスポートチェックエリアでデバイスを検出し、パスポートスキャナの進め方およびその通過方法について、デバイスを介してユーザに指示を提示する。
【0025】
このように、一実施形態において、システムは、乗客のスマートフォンまたは他のモバイルデバイス、ならびに任意選択で、Bluetoothビーコンまたは他のタイプのセンサおよびマッピングアプリケーションなどの任意の屋内または屋外のジオロケーション技術を使用して、バッグドロッププロセス、または空港もしくは他の関連する場所でシステムとのインタラクションを必要とする任意の他の乗客プロセスを自動化する。バッグドロップエリア、乗客処理キオスクまたはステーション、チェックポイントまたはe-gateの近くにいると、乗客のスマートフォンまたは他のモバイルデバイスのモバイルアプリがアクティブになり、乗客および該乗客の予約の詳細が識別される。乗客のデバイスは、バッグドロップユニットと「ペアリング」され、バッグドロップの処理方法に関する詳細な手順は、すべてスマートフォンまたはモバイルデバイスを介して電子的に/無線で実行される。このシステムは、例えば、スマートフォン上のモバイルアプリケーション、バッグドロップユニットに接続された処理ユニット(コントローラ)、および以下に詳述されるモバイルアプリケーションとバッグドロップユニットとの間のインタラクションを仲介または「プロキシ」するクラウドベースのAPIサーバを備えている。
【0026】
以下に説明する実施形態では、モバイルデバイスを手荷物システムとペアリングするためのトリガ機構としてBluetoothを使用しているが、他の方法も可能である。例えば、別の近距離無線通信(NFC),WIFIまたはBLEビーコンなどの別の種類の自動ペアリングを使用することができ、あるいはモバイルデバイスの所有者がスキャンしてアプリケーションを起動するQRコードもしくは別のバーコードなどの手動の方法、またはAmazon Alexa(登録商標)などの音声アクティベーションコマンドを使用することができる。バーコードを使用する場合、乗客は、チェックインデスクでステッカー上の2次元バーコードをスキャンするか、既知の方法でコードを撮影する。セキュリティ上の懸念に対処するために、バーコードはe-inkを使用して作成され、定期的に変更される。明確にするために、モバイルデバイスと手荷物取扱いシステムとの間の通信は、WIFIまたは別の通信プロトコルを使用して、以下で説明するAPIサービスを介して行われる。
【0027】
バッグドロップに関するプロセスは、乗客の視点から提示されている
図2により詳細にしてされている。プロセスは、概して100で示されている。ステップ102では、乗客は、彼らのスマートフォンまたは他のモバイルデバイスを介してオンラインでチェックインする。上述したように、これは、特定のアプリケーションを介して、あるいは航空会社のウェブサイトのチェックインモジュールを介して行うことができる。チェックインプロセスの一環として、乗客IDおよび手荷物許可量などの様々な乗客情報を含むモバイル搭乗券が作成される。搭乗券は、モバイルデバイスの適切な保管場所に格納されている。適切な保管場所の例は、Apple IOSを実行しているデバイス上のAppleウォレットアプリケーションまたはAndroidを実行しているデバイス上のGoogle PassWalletである。他のストレージオプションも可能である。
【0028】
各航空会社は、ツーストップのセルフバッグドロッププロセスと、ワンストップのプロセスと、のどちらを提供するのかを決定することができる。
図2の例は、ツーストップのプロセスであり、ステップ106で、乗客はバッグタグを印刷し、そのタグを手荷物に貼り付ける。この印刷は、ユーザの自宅またはオフィス環境または空港のキオスクで行うことができる。キオスクは、バッグタグの印刷専用とすることもできるし、オンラインチェックインなどの他の機能を提供することもできる。ワンステップのプロセスでは、ステップ106が省略され、乗客はバッグドロップに直行する。
【0029】
空港に入ると、乗客のモバイルデバイスは、空港の入口近くに配置されたビーコンを検出する(
図1の12)。乗客が空港のドロップバッグエリアに入って第2のビーコン14に近づくと、モバイルデバイスは再び第2のビーコンを検出する。この検出により、ユーザのモバイルデバイスアプリケーションのインテントがインスタンス化される。APIコールは、ビーコンによって表されるバッグドロップの詳細を取得するために行われ、APIコールからのバッグドロップIDおよびモバイルデバイスIDを使用してクラウドサービスに対して行われたセッションリクエストを取得する。これについては、以下で詳述する。
【0030】
乗客のスマートデバイスを介したメッセージングに代えて、空港の関連部分に、バッグドロップアプリを開くか、ウェブサイトにアクセスするように乗客に指示する標識を提示することができる。QRコードまたは他のバーコードが提供されて、それがデバイスのカメラでスキャンされると、アプリまたはウェブサイトが自動的に開くか、あるいはそのアプリが既に開いている場合はバッグドロッププロセスが開始される。このオプションには、航空会社にとって、バーコードには空港内の場所に広く対応する個々のコードが含まれ得るため、特定の乗客がどのセルフバッグドロップ(SBD)を使用しているのかを知れる、という利点がある。これは、航空会社が使用状況を監視し、乗客の流れを制御するのに役立つ。
【0031】
推奨されるオプションの1つでは、乗客のデバイスへのメッセージとサイネージ(標識)の両方を使用して、信頼性を向上させ、また、乗客がBluetoothのスイッチを入れ忘れた場合などに、システムを使用できるようにする。
【0032】
一実施形態では、サイネージには、視覚障害のある乗客のための点字指示が含まれ、アプリには、音声指示が含まれるものとすることができる。
【0033】
ステップ110において、乗客は、バッグドロップアプリを開いた状態で、指定されたバッグドロップに進む。アプリは、特定の1つの、またはグループのセルフバッグドロップターミナルにいるように乗客に指示することができる。この段階で、バッグドロップアプリケーションまたはモジュールは、デバイスに格納されている搭乗券データを取得している。これには、手荷物許容量の情報が含まれている場合があり、あるいは乗客IDを使用して航空会社の出発管理システム(DCS)からその情報を取得することができる。適格性チェックを実行して、例えば、乗客が荷物を預け入れるには早すぎる、遅すぎるか、あるいはモバイルデバイスのバッグドロップオプションが特定のフライトでは利用できないかどうかを判断することができる。
【0034】
ステップ112では、乗客はバッグドロップエリアに現れ、アプリケーションは、乗客に彼らのバッグを手荷物ベルトまたは静止スケール上に置くように求めるメッセージを表示する。従来のバッグドロップと同様に、許容重量内にあることを確認するためにバッグの重量が測定される。重量はアプリに通知され、受信した重量を、搭乗券の一部として格納されているか、あるいはDCSから取得できる許容重量と照合することができる。
【0035】
バッグが重量チェックに合格しなかった場合、乗客は超過手荷物の支払いを求められる。これは、航空会社のアプリケーションに事前に保存されているクレジットカードまたはデビットカードで、あるいは通常のオンライントランザクションで行われる。このトランザクションは、「Card not present」タイプであり、各航空会社に固有のものであり、各航空会社には独自の超過手荷物料金がある。
【0036】
重量が許容限度内にあるか、あるいは超過分が支払われたと仮定すると、ステップ114でバッグタグが印刷される。上記のツーステップのプロセスの場合、バッグタグは既にあるため、このステップは不要である。その後、アプリは、バッグタグをバッグに貼り付ける方法に関する情報を乗客に表示する。
【0037】
バッグタグが貼り付けられると、デバイスカメラを介してLPCバーコードが読み取られることが可能になる。これは、バッグが意図した目的地に到着していない場合、または乗客がフライトに出向かない場合、または補償請求が行われる場合に役立つ。一実施形態において、バッグの3Dスキャンを実行して、バッグが許容寸法内にあり、運搬されるのに適切な厳密さで構築されていることを確認することができる。
【0038】
ステップ116で、乗客確認ステップが実行される。アプリは、航空会社のDCSにアクセスできるため、PNR(passenger name record:旅客予約記録)を取得し、タグ上のデータをその記録と比較することができる。アプリは、セルフィを撮るか、あるいは生体認証や指紋認証などのモバイルデバイスによって提供される1つまたは複数の他の形式の確認を使用するように、乗客に指示することができる。この方法で収集されたデータは、後で参照するために格納しておくことができる。乗客の確認は、バッグタグを印刷する前に実行されてもよい。
【0039】
ステップ118では、乗客の身元が確認されると、バッグは出発管理システム(DCS)によって受け取られ、手荷物預かり証(クレームタグ)がスマートフォンで乗客に示される。この手荷物預かり証は、アプリケーションに保存され、かつ/あるいはモバイルデバイス上に保存される。次に、バッグは、手荷物取扱いシステムに引き渡されるが、このステップは、自動的に、あるいは航空会社のエージェントの支援を受けて実行される。
【0040】
バッグが引き渡されると、アプリは、これに限定されないが、搭乗時間やゲートなどの乗客のフライトに関する詳細情報を乗客に提供することができる。この時点で、アプリは自動的に閉じるか、あるいは国際公開第2013/117723号に開示されているタイプのアプリケーション、すなわち空港周辺に配置された近距離ビーコンを使用して乗客を出発ゲートに誘導するタイプのアプリケーションを見つける方法に乗客を戻すことができる。
【0041】
図3は、上記のプロセスで使用される重要なハードウェアコンポーネントを示している。乗客のモバイルデバイスは、200で示されており、乗客のバッグをチェックインするためのロジックで構成されたアプリがロードされている。前述したように、アプリは、例えば、航空会社のアプリのモジュールまたはスタンドアローンのアプリとすることができる。デバイス200は、航空会社の出発管理システム(DCS)と、APIおよび関連するロジックのセットをホストするクラウドサービス220と通信する。手荷物チェックインシステムには、手荷物チェックインユニット230と、BCIU230と通信するソフトウェアおよび/またはファームウェアを含む、手荷物チェックインユニット(BCIU)230に関連するハードウェアコントローラであるか、あるいは同じことを行うCUTE/CUSSモジュールであり得る、コントローラ235と、が含まれる。CUTE(Common Use Terminal Equipment)およびCUSS(Common Use Self Service)。CUTEおよびCUSSは、複数の航空会社またはサービス会社がハードウェアを使用できるようにする、周知の規格である。また、コントローラもクラウドサービス220と通信する。必須ではないが、ビーコン240は、Bluetooth(登録商標)または別の通信プロトコルを介して、モバイルデバイスと通信するバッグドロップエリアを自動で識別するために提供される。ビーコンが使用される場合、モバイルデバイス220は、ビーコンレジストリ250とも通信してバッグドロップ識別子を取得する。ビーコンが使用される場合でも、そのサービスがクラウドサービス220によってサポートされるため、ビーコンレジストリ250が必須ではない場合がある。
【0042】
図4は、システムの論理アーキテクチャを示している。一般に、クラウドサービス(
図3の220)は、モバイルデバイス200と手荷物ユニットコントローラとの間のブローカとして機能する。このサービスは、単一の接続エンドポイントをモバイルデバイスに公開し、ネットワーク関連の複雑さを緩和し、無線プロトコルを介した複数のデバイスを許可し、バッグドロップサービスの可用性を管理し、そしてコントローラ固有のメッセージングのアブストラクトを作成する。ウェブソケット(Websocket)接続400は、モバイルデバイス200とクラウドサービスとの間、およびクラウドサービスと手荷物ユニットコントローラとの間に確立されている。後者の接続は、手荷物ユニットコントローラによって確立され、該コントローラの使用時間中維持される。接続が確立されていることを保証するのは、コントローラ側の責任である。接続が終了した場合、コントローラは接続を再度確立する必要がある。クラウドサービスは、ウェブソケット接続がアクティブでない場合、バッグドロップユニットが利用できないものとみなす。ウェブソケットとして説明しているが、他の非同期メソッドまたは双方向同期メソッドを使用することができる。
【0043】
同様に、モバイルデバイス200は、クラウドサービス220との通信を確立し、セッションの存続中は接続を維持する役割を果たす。コントローラと同様に、各モバイルデバイスからのサービスの検出により、プロセスが合理化される。エンドツーエンドセッションは、モバイルデバイスおよびバッグユニットコントローラの両方のIDをバインドすることでマッピングされる。
【0044】
図5には、クラウドサービス220の論理アーキテクチャが示されている。クラウドサービスは、分散型リアクティブプラットフォームでホストされる一連のマイクロサービスで構成されている。各サービスエンドポイントは、演算子(op)に基づくイベントがイベントバスを介してルーティングされるアドレスを登録している。ウェブソケットサービスは、コントローラやモバイルデバイスと直接通信する外部向けサービスである。
【0045】
図6は、利用可能なインタフェースを反映するサービスモデルを示すクラス
図600であり、本質的にサービスプラットフォームモデルよりもざっくりしたものである。サービスは以下の通りである。
【0046】
[バッグドロップサービス602]
このサービスは、モバイルデバイスとコントローラとの間のセッションで使用されるインテフェースを含む。一部のインタフェースは、セッションなどの追加のサービスに“パススルー”する場合があるが、すべてではないにしても、ほとんどの基本インタフェースがここで管理される。これらには、バッグ導入サービス、バッグタグ印刷サービス、スケールサービスなどが含まれる。
【0047】
[バッグドロップマネジメントサービス604]
このサービスは、コントローラの管理を操作する。コントローラが始めて起動されると、登録依頼が送信される。このサービスは、構成サービス606とインタラクションして、その依頼を検証し、コントローラの新しい構成を保存する。また、コントローラの利用可能ステータスも操作する。
【0048】
[タイマーサービス608]
セッションには、事前に定義された非アクティブ期間がある。タイマーサービスはこれを管理し、セッションサービスとインタラクションして、セッション状態全体を操作する。
【0049】
[構成サービス606]
上述したように、このサービスは、バッグドロップマネジメントサービスとインタラクションして、コントローラを登録および登録解除する。さらに、各コントローラには、アップロードして保存することができる固有の属性がある。インタフェースを介して、コントローラを有効または無効にすることができる。
【0050】
[セッションサービス610]
このサービスは、モバイルデバイスとコントローラとの間のセッションを管理する。認証サービスとインタラクションして、start_session上でユーザを認証し、トークンを検証する。また、タイマーサービスとインタラクションして、一定の非アクティブ期間の後にセッションを無効にする。
【0051】
[認証サービス612]
このサービスインタフェースは、認証および承認の1つまたは複数の実装に対するファサードとして機能する。最初の実装では、ローカルユーザID/パスワード認証スキームと、認証用のJWT(JSON Web Tokens)と、が提供される。
【0052】
図7は、
図3のバッグユニットコントローラ235の論理アーキテクチャを示す。
任意の適切なコンピューティングデバイスホストとすることができるワークステーション702は、ハードウェアサービス704およびバッグドロップコントローラサービス706をホストする。ワークステーションは、好ましい実施形態では、例えば、上述したようにWindows(登録商標)オペレーティングシステムを実行する一般的な使用端末として構成される。バッグドロップコントローラサービスは、ウェブソケット708およびハードウェア通信レイヤ710を介して、クラウドサービスとハードウェアサービスとの間の通信レイヤとして機能する。また、マシンの状態を管理し、クラウドサービスに登録する。ハードウェアサービス704は、IOサーバ710および他のハードウェア周辺機器に接続している。あるいは、ハードウェアサービスは、一般的に使用されるセルフサービスモジュール(Common Use Self-Service module)に接続していてもよい。
【0053】
IOサーバ710は、1つまたは複数の手荷物ベルトセットアップ714および他のハードウェア716を制御するために、プログラマブル論理制御装置(PLC)712を含む。それは、空港の手荷物処理システムに接続されているか、あるいはハードウェアに直接接続されている。
【0054】
図8は、モバイルデバイスアプリケーション(アプリ)800のアーキテクチャを示す。このアプリには、ソフトウェア開発キット(SDK)802と、ユーザ作成イベントハンドラ804と、の2つの主要コンポーネントがある。モバイルデバイスのアーキテクチャは、適用可能な処理の多くをSDK802にプッシュするように設計されている。これにより、特定の航空会社または外部ベンダーであるアプリ開発者がサービスを実装し易くなる。適用可能な処理には、モバイルデバイスとクラウドサービスとの間のソケット通信だけでなく、ワークフローも含まれる。
【0055】
これを実現するために、アプリ開発者は、文書化されたイベントリスナ、またはハンドラ804のセットを実装する。これらのリスナ、またはオブザーバは、SDKからのコールバックを受け入れるように登録され、この時点で、ハンドラは、特定の結果を得るために事前に定義されたロジックを実行する。ハンドラ804は、結果とともにSDK802をコールすること、あるいは単にその完了をSDK802に通知することも要求され得る。
図8は、UX(ユーザエクスペリエンスレイヤ)806、アプリケーションロジック808、およびSDK802間のハイレベルなインタラクションを示している。
【0056】
以下の表1は、アプリ開発者が実装するイベントハンドラのリストである。
【0057】
【0058】
表2は、アプリによって実装されるSDKのメソッドコールのリストである。
【0059】
【0060】
図9は、SDK802、航空会社のモバイルアプリコンポーネント、およびUX806間のエンドツーエンドのインタラクションを示すプロセスフロー図である。
図9の例では、バッグタグはまだ印刷されていない。バッグタグが既に印刷されている場合は、これをサポートするために別のパスが使用される。
【0061】
図10は、主要なシステムアクター、モバイルデバイスアプリ、クラウドサービス、およびセルフバッグドロップユニット間のエンドツーエンドのインタラクションを示す。DCS(Departure Control System:出発管理システム)のアプリとのインタラクションも示されている。
図9の例と同様に、バッグタグはまだ印刷されていない。バッグタグが既に印刷されている場合、別のパスが使用される。
【0062】
セキュリティは、全てのセッションについて、モバイルデバイスとクラウドサービスとの間、およびクラウドサービスとバッグドロップユニットコントローラとの間のすべての通信が、安全な暗号化プロトコル上にあることを確実にすることによって実現される。
現在、安全なウェブソケットプロトコル(WSS)が好ましい。JSONウェブトークン(JWT)は、すべてのレイヤにわたるトランザクションを認証および承認するために使用される。JWTは、デジタル署名または暗号化が可能なJSONオブジェクトとしてエンコードすることにより当事者間のクレームを表す、コンパクトでURLセーフな手段である。
【0063】
モバイルデバイスアプリでは、モバイルデバイスとクラウドサービスとの間で、HMAC(Hash-based Message Authentication Code)アルゴリズムが使用される。各クライアント(例えば、航空会社)は、単一のユーザIDとパスワードの組み合わせを受け取る。session_startにおいて、これらの資格情報は、クラウドサービスに渡され、クラウドサービスによって検証される。秘密鍵を使用してJWTが生成される。モバイルデバイスは、各リクエストでJWTを送信する責任がある。新しいJWTは、クラウドサービスによっていつでも生成することができる。モバイルクライアントは、クラウドサービスから受信した各イベントでJWTを保存し、後続のリクエストで最新バーションを返す責任がある。
【0064】
HMACアルゴリズムは、バッグドロップユニットコントローラと、クラウドサービスとの間でも使用される。各バッグドロップユニットコントローラには、一意のID、ユーザネームおよびパスワードが事前に設定されている。モジュールが初めて起動すると、コントローラはクラウドサービスに登録し、登録リクエストでその一意の資格情報を渡す。登録が成功すると、クラウドサービスの応答にはJWTが含まれるが、これは、コントローラからクラウドサービスへの各メッセージで必要になるものである。
【0065】
代わりに、RSA公開/秘密鍵暗号化を使用することができる。
【0066】
APIは、クラウドサービス220とコントローラ235との間、クラウドサービス220とモバイルデバイス200との間、ならびにクラウドサービス220とコントローラおよびモバイルデバイスとの間のインタラクションを(プロキシモードで)処理する。
【0067】
各APIイベント、または操作は、安全なウェブソケット接続(wss)を介してJSONペイロードで伝達され、イベント演算子(op)を含む。type演算子は、メッセージを適切なハンドラにルーティングするために使用される。
【0068】
モバイルアプリとバッグドロップユニットとの間のセッションは、start_session中に開始され、Jsonウェブトークンを使用して伝播され、セッション終了コールまたはタイムアウトで終了する。モバイルアプリのクライアントには、クラウドサービスへの呼び出しごとにトークンを渡す必要がある。ウェブソケット接続を介してクラウドサービスとのみ通信するときには、これはSDKの責任である。
【0069】
1.クラウドサービス-モバイルデバイス
基本的なコマンドは、次の形式で送信される:
[数1]
{
"token": "<service-supplied token>",
"op": "<command>",
"txid": "<generated transaction id>",
"args": [{
"key1": "val1",
"key2": "val2",
"key3": "val3"
}]
}
【0070】
この形式は、アプリケーションのユーザIDおよびパスワードが送信される、start_sessionを除くすべてのAPIコールに有効である。結果として返されるトークンは、認証の成功、およびバッグドロップユニットとのアクティブセッションを示す。リクエスタのトランザクションIDは任意選択である。トランザクションIDを受信した場合、応答ペイロードで返すことが推奨されるが、必須ではない。
【0071】
[reply]
replyは、クラウドサービスまたはモバイルデバイスのいずれかによって送信される一般的な応答である。メッセージには、以前のリクエストに関する情報と、(任意選択の)トランザクションIDと、が含まれている。これは、特定の応答ペイロードのないリクエストを確認するために使用することができる。このAPIは双方向である。
【0072】
【0073】
例
[数2]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "reply",
"txid": "<generated transaction id>",
"args": [{
"for": "mark_available",
"result": "ok",
}]
}
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "reply",
"txid": "<generated transaction id>",
"args": [{
"for": "mark_available",
"result": "failed",
"reason_code": "NO_RESPONSE"
}]
}
【0074】
【0075】
[Start_session]
Start_sessionは、IDで示されるバッグドロップとのセッションがクライアントで開始されることをリクエストする。資格情報は、リクエストで渡される。システムの各クライアントは、固有の資格情報のセットを有することになる。資格情報は、各アプリユーザに固有ではない。これは、一方向の、非同期リクエストである。クライアントは、このコールの結果として、session_readyまたはno_sessionイベントを受け取ることになる。一般的に、方向は、モバイルアプリからクラウドサービスである。
【0076】
【0077】
例
[数3]
{
"op": "start_session",
"args": [{
"uid": "myClientId",
"pwd": "myClientPwd",
"bagdrop_id": "ID105211"
}]
}
【0078】
[session_ready]
session_readyは、start_sessionリクエストから生じる2つのイベントのうちの1つである。これは、バッグドロップユニットとのセッションが開始されたことをクライアントに通知する。応答には、例えば、バッグタグおよびレシートの印刷が可能かどうかといったバッグドロップユニットの機能が含まれる。一般に、方向は、クラウドサービスからモバイルアプリである。
【0079】
【0080】
例
[数4]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "session_ready",
"args": [{
"bagdrop_id": "ID105211"
"config": [{
"print_bagtag": true,
"print_receipt": true
}],
}]
}
【0081】
[no_session]
no_sessionは、start_sessionリクエストから生じる2つのイベントのうちの1つである。これは、バッグドロップユニットとのセッションが正常に開始されなかったことをクライアントに通知する。理由コードが応答に添付される。一般に、方向は、クラウドサービスからモバイルアプリである。
【0082】
【0083】
例
[数5]
{
"op": "no_session",
"args": [{
"bagdrop_id": "ID105211",
"reason_code": "OUT_OF_SERVICE"
}]
}
【0084】
【0085】
[end_session]
end_sessionは、いずれかの当事者によって送信されて、該送信者がセッションの終了を希望していることを示すものである。通常は、モバイルアプリから送信されるが、双方がクリーンアップするために、いくつかの理由でクラウドサービスによって送信される場合がある。一般的に、方向は、モバイルアプリからクラウドサービスであるが、クラウドサービスから送信される場合もある。
【0086】
【0087】
例
[数6]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "end_session",
"args": [{
"bagdrop_id": "ID105211",
"reason_code": "PROCESS_COMPLETE"
}]
}
【0088】
【0089】
[scale_result]
scale_resultは、クラウドサービスによって送信され、バッグドロップユニットから転送され、バッグドロップユニットのスケールによるバッグの計量結果を中継する。応答には、空港または手荷物処理システムの重量/サイズに関する制限が含まれる。方向は、クラウドサービスからモバイルアプリである。
【0090】
【0091】
例
[数7]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "scale_result",
"args": [{
"bagdrop_id": "ID105211",
"weight": 20,
"dimension": 10,
"weight_unit": "K",
"dimension_unit": "I",
"bhs_rules": [{
"weight": 50,
"dimension": 20,
"weight_unit": "K",
"dimension_unit": "I"
}],
"result": "PASSED"
}]
}
【0092】
【0093】
[print_bagtag]
print_bagtagは、モバイルデバイスからクラウドサービスに送信される。リクエストはバッグドロップユニットに配信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれている。方向は、モバイルアプリからクラウドサービスである。
【0094】
【0095】
例
[数8]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_bagtag",
"args": [{
"bagdrop_id": "ID105211",
"image": "<image to print>",
"format": "PECTAB"
}]
}
【0096】
【0097】
[induct_bag]
induct_bagは、モバイルデバイスからクラウドサービスに送信される。リクエストがバッグドロップユニットに配信されるため、プロキシコールとみなされる。リクエストは、暗示されているように、バッグドロップユニットがバッグを手荷物取扱いシステムに導入することを開始することである。このコールは、構成に基づいて任意選択とすることができる。例えば、一部の構成では、特にバッグタグが事前に印刷されていてバッグに取り付けられている場合、特定のステップの後にバッグを自動的に導入することが必要になる場合がある。方向は、モバイルアプリからクラウドサービスである。
【0098】
【0099】
例
[数9]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "induct_bag",
"args": [{
"bagdrop_id": "ID105211"
}]
}
【0100】
[print_receipt]
Print_receiptは、モバイルデバイスからクラウドサービスに送信される。リクエストがバッグドロップユニットに配信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれる。
【0101】
方向は、モバイルアプリからクラウドである。リプライが期待される。
【0102】
【0103】
例
[数10]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_receipt",
"args": [{
"bagdrop_id": "ID105211",
"image": "<image to print>",
"format": "PECTAB"
}]
}
【0104】
【0105】
2.クラウドサービス-コントローラ基本的なコマンドは、以下の形式で送信される:
[数11]
{
"token": "<server-supplied token>",
"op": "<command>",
"txid": "<generated transaction id>",
"args": [{
"key1": "val1",
"key2": "val2",
"key3": "val3"
}]
}
【0106】
この形式は、手荷物処理ユニットの固有のID、ユーザ名およびパスワードが送信される、registerを除くすべてのAPIコールに有効である。リクエスタのトランザクションIDは任意選択である。トランザクションIDを受信した場合、応答ペイロードで返すことが推奨されるが、必須ではない。
【0107】
[reply]
replyは、クラウドサービスまたはコントローラのいずれかによって送信される一般的な応答である。メッセージには、以前のリクエストに関する情報と、(任意選択の)トランザクションIDと、が含まれている。これは、特定の応答ペイロードのないリクエストを確認するために使用することができる。このAPIは双方向である。
【0108】
【0109】
例
[数12]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "reply",
"txid": "<generated transaction id>",
"args": [{
"for": "mark_available",
"result": "ok",
}]
}
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "reply",
"txid": "<generated transaction id>",
"args": [{
"for": "mark_available",
"result": "failed",
"reason_code": "NO_RESPONSE"
}]
}
【0110】
【0111】
[register]
registerは、バッグドロップコントローラ(CUTE,CUSSモジュールなど)からクラウドサービスに送信される。これは、コントローラが初めてオンラインになったときに送信される1回限りのメッセージである。コントローラは、登録リクエストの結果として、2つのイベントregisteredまたはregistration_failedのうちのいずれかを受け取る。方向は、コントローラからクラウドサービスである。
【0112】
【0113】
例
[数13]
{
"op": "register",
"args": [{
"bagdrop_id": "ID105211",
"username": "9e83a024-c374-4c3e-bd4e-ead758282513",
"password": "bfdfdcb7-4cd2-4b33-ae17-a11c45ae1802"
}]
}
【0114】
[registered]
registerdは、クラウドサービスからコントローラに送信される。このメッセージは、登録が成功し、セッションが開始されたことを示している。方向は、クラウドサービスからコントローラである。
【0115】
【0116】
例
[数14]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "registered"
}
【0117】
[registration_failed]
registration_failedは、クラウドサービスからコントローラに送信される。このメッセージは、コントローラを登録しようとしたときに問題が発生したことを示している。方向は、クラウドサービスからコントローラである。
【0118】
【0119】
例
[数15]
{
"op": "registration_failed",
"reason_code": "BAD_CREDENTIALS"
}
【0120】
【0121】
[deregister]
deregisterは、バッグドロップコントローラ(CUTE,CUSSなど)によってクラウドサービスに送信される。APIリクエストは、コントローラがデコミットされたことをクラウドサービスに通知し、その記録をシステムから削除する。方向は、コントローラからクラウドサービスである。
【0122】
【0123】
例
[数16]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "register",
"args": [{
"bagdrop_id": "ID105211",
"username": "9e83a024-c374-4c3e-bd4e-ead758282513",
"password": "bfdfdcb7-4cd2-4b33-ae17-a11c45ae1802"
}]
}
【0124】
[mark_available]
mark_availableは、バッグドロップコントローラ(CUTE,CUSSなど)によってクラウドサーバに送信される。APIリクエストは、コントローラがセッションを受け入れることができるようになったことをクラウドサービスに通知する。コントローラがすでに使用可能である場合、リクエストはクラウドサービスによって無視される。すべての場合において、確認応答が返送される。方向は、コントローラからクラウドサービスである。
【0125】
【0126】
例
[数17]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "mark_available",
}
【0127】
[mark_unavailable]
mark_unavailableは、バッグドロップコントローラ(CUTE,CUSSなど)によってクラウドサービスに送信される。APIリクエストは、コントローラがセッションを受け入れることができないことをクラウドサービスに通知する。コントローラが既に使用不可とマークさえている場合、このリクエストはクラウドサービスによって無視される。すべての場合において、確認応答が返送される。方向は、コントローラからクラウドサービスである。
【0128】
【0129】
例
[数18]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "mark_unavailable",
"args": [{
"reason_code": "MAINTENANCE"
}]
}
【0130】
【0131】
[scale_result]
scale_resultは、バッグドロップユニットによってクラウドサービスに送信される。応答には、空港または手荷物処理システムの重量/サイズに関する制限が含まれる。方向は、コントローラからクラウドサービスである。
【0132】
【0133】
例
[数19]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "scale_result",
"args": [{
"weight": 20,
"dimension": 10,
"weight_unit": "K",
"dimension_unit": "I",
"bhs_rules": [{
"weight": 50,
"dimension": 20,
"weight_unit": "K",
"dimension_unit": "I"
}],
"result": "PASSED"
}]
}
【0134】
【0135】
[print_bagtag]
print_bagtagは、クラウドサービスからからコントローラに送信される。リクエストはモバイルデバイスから発信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれている。方向は、クラウドサービスからクラウドコントローラである。コントローラからの応答が期待される。
【0136】
【0137】
例
[数20]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_bagtag",
"args": [{
"bagdrop_id": "ID105211",
"image": "<image to print>",
"format": "PECTAB"
}]
}
【0138】
【0139】
[induct_bag]
induct_bagは、クラウドサービスによってコントローラに送信される。リクエストがモバイルデバイスで発信されるため、プロキシコールとみなされる。リクエストは、暗示されているように、バッグドロップユニットがバッグを手荷物処理システムに導入することを開始することである。このコールは、構成に基づく任意選択であるとみなされる場合がある。例えば、一部の構成では、特にバッグタグが事前に印刷されていてバッグに取り付けられている場合、特定のステップの後にバッグを自動的に誘導することが必要になる場合がある。方向は、クラウドサービスからコントローラである。応答が期待されている。
【0140】
【0141】
例
[数21]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "induct_bag"
}
【0142】
[print_receipt]
print_receiptは、クラウドサービスからコントローラに送信される。リクエストがモバイルデバイスから発信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれる。方向は、モバイルアプリからクラウドサービスである。応答が期待される。
【0143】
【0144】
例
[数22]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_receipt",
"args": [{
"image": "<image to print>",
"format": "PECTAB"
}]
}
【0145】
【0146】
説明してきたように、このシステムは、独自のアプリケーションまたは航空会社/空港のウェブサイト上のモジュールのいずれかである、フロントエンドアプリケーションを含む。これは、航空会社および/または空港が乗客にバッグドロップ(手荷物預け入れ)サービスを提供するためのインタフェースである。バックエンドのソフトウェアエンジンは、セルフサービスのバッグドロッププロセスのロジックをホストし、プロセスを駆動する。APIは、アプリ、バックエンドのソフトウェアエンジンおよび手荷物処理システムのハードウェア、ならびにプリンタおよび計量機などのセルフサービスのバッグドロップ周辺機器間の通信を可能にした。他の迅速な周辺機器には、自動読み取り機および手荷物査定装置が含まれる場合がある。例えば、BHSハードウェアは、新規または既存のコンベアベルトおよび計量機を含む場合がある。
【0147】
本発明の実施形態は、モバイル搭乗券の代わりに、乗客が使用するために印刷された搭乗券が必要であり、一時的および永続的なバッグタグを含む任意のバッグタグ、タグなしの手荷物処理システム、およびセルフサービスで印刷されたバッグタグを伴う場合にも使用することができる。
【0148】
本発明の実施形態には多くの利点がある。既存のチェックインシステムおよびパスポートゲートなどの他のシステムに比較的小さな変更を加えるだけで、乗客にとっては、乗客とセルフサービスロケーションとの間のインタラクションがより簡潔になり、オペレータは、従来のチェックインおよび他の施設の人員配置などの一般費用を削減することが可能となる。乗客の観点からみると、利便性が提供されて時間が節約されるので、乗客の空港でのエクスペリエンスが向上する。本明細書では、バッグドロップシステムに関して説明してきたが、本発明の実施形態は、電子ゲートなどの空港の他のセルフサービス機能とともに使用することができ、電子パスポートおよび/または搭乗券チェック、最終搭乗チェック、ならびにチェックイン用および/またはバッグタグの生成および印刷用のキオスクを提供する。一実施形態において、乗客のモバイルデバイスは、空港に到着すると手荷物処理システムに接続し、乗客は正しいカルーセル(手荷物受け取り用の回転コンベア)に誘導されるとともに、乗客の荷物も該カルーセルに誘導される。
【0149】
本発明の実施形は、他の港、鉄道の大量輸送場所、ならびに個人がチケットチェックなどのサービスと対話する会場、競技場などで使用することができる。
【0150】
本発明の実施形態は、特定の障害を持つ乗客にとっても有利であり得る。例えば、スマートデバイスのオーディオ機能を使用することにより、視覚障害のある乗客の荷物の預け入れ、入出国審査およびその他の空港機能のエクスペリエンスを大幅に改善することができる。本発明の実施形態はまた、スマートデバイス上の乗客情報と、航空会社または空港が既存のモバイルアプリケーションを介して既に提供している場合がある支払いサービスと、の統合を可能にする。