(57)【要約】航空会社の搭乗券などのチケット情報は、モバイルデバイスに保存することができる。Bluetoothビーコンなどのジオロケーションデバイスの存在は、空港などの出発地にあるモバイルデバイスによって検出される。モバイルデバイスがセルフサービス機能に近接して該モバイルデバイスによって別のジオロケーションデバイスが検出されると、モバイルデバイス上のアプリケーションがトリガされて、モバイルデバイスをバッグドロップなどのセルフサービス機能に誘導し、該セルフサービス機能の使用方法をモバイルデバイスのユーザに指示する。【選択図】図１
2021503108.tif 000002
【特許請求の範囲】
【請求項１】
チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法であって、
前記チケットおよび当該チケットに関連するセルフサービス機能に関する情報が格納されているモバイルデバイスによって、前記セルフサービス機能への近接を検出するステップと、
前記モバイルデバイスが該位置への近接を検出したら、前記モバイルデバイス上で、前記セルフサービス機能に関連するアプリケーションを起動するステップと、
前記アプリケーションを介して前記モバイルデバイスと通信するステップと、を含み、前記セルフサービス機能に関する情報に方向情報が含まれている、方法。
【請求項２】
前記チケットは、乗客の旅に関連するものであり、乗客および旅の識別を含んでいる、請求項１に記載の方法。
【請求項３】
前記チケット情報には搭乗券が含まれている、請求項２に記載の方法。
【請求項４】
前記モバイルデバイスは、前記セルフサービス機能への近接を示すジオロケーションデバイスを検出する、請求項１に記載の方法。
【請求項５】
前記ジオロケーションデバイスがBluetoothビーコンである、請求項５に記載の方法。
【請求項６】
前記アプリケーションは、前記モバイルデバイスに格納されている前記チケット情報を照会し、当該チケット情報をリモートサーバに通信する、請求項１に記載の方法。
【請求項７】
前記リモートサーバは、前記チケット情報の受信に応答して、前記モバイルデバイスの前記ユーザに提示するために、前記セルフサービス機能に関する情報を前記アプリケーションに提供する、請求項６に記載の方法。
【請求項８】
前記セルフサービス機能がバッグドロップであり、前記チケットに関する前記情報が搭乗券であり、当該搭乗券の乗客情報を出発管理システムに通信するステップを含む、請求項１に記載の方法。
【請求項９】
前記出発管理システムによって、前記搭乗券に関連する手荷物がバッグドロップに適格であるかどうかを判定し、その適格性を前記モバイルデバイスに通信するステップを含む、請求項８に記載の方法。
【請求項１０】
バッグドロップでバッグを預け入れる際に、前記バッグの重量を測定し、当該重量が許容重量を超えているかどうかを判定し、当該重量が許容重量を超えている場合は、前記アプリケーションを介して超過手荷物料金の支払いを手配するステップを含む、請求項８に記載の方法。
【請求項１１】
前記バッグドロップでバッグタグを印刷し、当該バッグタグをバッグに固定する指示を、前記ユーザに提示するために、前記アプリケーションを介して前記モバイルデバイスに通信するステップを含む、請求項１に記載の方法。
【請求項１２】
前記バッグドロップによるバッグの受領時に、搭乗および出発ゲートへのルートに関する情報を前記アプリケーションに通信するステップを含む、請求項８に記載の方法。
【請求項１３】
チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法であって、
前記チケットに関連するセルフサービス機能に近接する位置において、前記チケットに関する情報が格納されているモバイルデバイス上で、前記セルフサービス機能に関連するアプリケーションを起動するステップと、
前記アプリケーションを介して前記モバイルデバイスと通信するステップと、を含み、前記セルフサービス機能に関する情報に方向情報が含まれている、方法。
【請求項１４】
前記アプリケーションは、前記モバイルデバイスを使用してバーコードをスキャンまたは撮像することにより起動される、請求項１３に記載の方法。
【請求項１５】
チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にするためのシステムであって、
セルフサービス機能と、
前記チケットに関する情報が格納されているモバイルデバイスと、
少なくともジオロケーションデバイスであって、前記モバイルデバイスが、セルフサービス機能に近接する位置で当該ジオロケーションデバイスを検出するように構成されている、ジオロケーションデバイスと、
少なくとも１つのサーバであって、
前記モバイルデバイスが、該位置に近接するジオロケーションデバイスを検出したら、前記モバイルデバイス上で、前記セルフサービス機能に関連するアプリケーションを起動するステップと、
前記アプリケーションを介して前記モバイルデバイスと通信するステップと、を実行するためのコンピュータソフトウェアが格納されている少なくとも１つのサーバと、を備え、前記セルフサービス機能に関する情報に方向情報が含まれている、システム。
【請求項１６】
前記チケットは、乗客の旅に関するものであり、乗客および旅の識別を含んでいる、請求項１５に記載のシステム。
【請求項１７】
前記チケット情報には搭乗券が含まれている、請求項１５に記載のシステム。
【請求項１８】
前記少なくとも１つのジオロケーションデバイスがBluetoothビーコンである、請求項１７に記載のシステム。
【請求項１９】
前記アプリケーションは、前記モバイルデバイスに格納されている前記チケット情報を照会し、当該チケット情報を前記サーバに通信する、請求項１５に記載のシステム。
【請求項２０】
前記サーバは、前記チケット情報の受信に応答して、前記モバイルデバイスの前記ユーザに提示するために、前記セルフサービス機能に関する情報を前記アプリケーションに提供する、請求項１９に記載のシステム。
【請求項２１】
出発管理システムを備え、前記セルフサービス機能が、手荷物取扱いシステムとバッグドロップコントローラとを備えるバッグドロップであり、前記チケットに関する前記情報が搭乗券であり、前記搭乗券の乗客情報を出発管理システムに通信することを含む、請求項１５に記載のシステム。
【請求項２２】
前記出発管理システムは、前記搭乗券に関連する手荷物がバッグドロップに適格であるかどうかを判定し、その適格性を前記モバイルデバイスに通信するように構成されている、請求項２１に記載のシステム。
【請求項２３】
前記手荷物取扱いシステムは、前記バッグドロップでバッグが預けられた際に当該バッグの重量を測定し、当該重量が許容重量を超えていないかどうかを判定し、当該重量が許容重量を超えている場合には、前記アプリケーションを介して超過手荷物料金の支払いを手配するための計量装置を備える、請求項２２に記載のシステム。
【請求項２４】
前記手荷物取扱いシステムは、バッグタグを印刷するためのプリンタを備え、前記バッグドロップコントローラは、前記バッグタグをバッグに固定する指示を、前記ユーザに提示するために、前記アプリケーションを介して前記モバイルデバイスに通信するように構成されている、請求項２２に記載のシステム。
【請求項２５】
前記バッグドロップによるバッグの受領時に、前記システムは、搭乗および出発ゲートへのルートに関する情報を前記アプリケーションに通信するように構成されている、請求項１５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、手荷物の取扱いなどの旅客サービスとの自動化されたインタラクションに関する。特に、排他的ではないが、空港、港、鉄道、その他の大量輸送施設、会場、スタジアムおよびアリーナでの手荷物の取扱いに関する。
【背景技術】
【０００２】
空港の環境において、手荷物のチェックインは、乗客にとって時間のかかるストレスの多い経験になる可能性がある。グランドスタッフが手荷物ごとにバッグタグ（バッグ用のタグ）を印刷し、それらのタグを手荷物に固定することを含む、手作業での低速なチェックインプロセスに起因して、混雑時には長い行列が形成され得る。
【０００３】
手荷物のチェックインプロセスは、チェックインプロセスおよびメンテナンスに関連する人件費とともに、バッグのタグ付け機器の断続的な運用およびメンテナンス費用のために、空港および航空会社にとって高額の間接諸経費を必要とする。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
近年、これらの費用を削減し、チェックインプロセスを能率化し、かつ乗客の行列待ち時間を短縮するために、いくつかの措置が講じられている。例えば、現在、多くの航空会社は、乗客が空港に到着したときにバッグを預け入れるだけで済む、オンラインチェックインサービスを提供している。より最近では、一部の航空会社は、搭乗券をスキャンするとバッグタグが作成されて乗客によって貼り付けられる、半自動のセルフサービスのバッグドロップ（バッグの預け入れ）を導入している。一部の航空会社は、セルフサービスとグランドスタッフの支援とを組み合わせた設備を使用した、ハイブリッドアプローチを採用している。これらの手段は、上述の問題を軽減するために何らかの方法を講じているが、これらはすべて、乗客と、グランドエージェント、キオスク、またはその他のコンピュータ化された機器と、の間の何らかのインタラクションが必要である。これらの解決策は、空港のチェックインカウンタの大幅な変更およびセルフサービス機器への多大な投資を必要とするため、さらなる問題が生じる。どちらも、費用が高額であり、運用が複雑である。
【０００５】
上述の問題に加えて、障害のある乗客のニーズに対する意識が高まっている。多くの国では、障害のある乗客および身体の不自由な乗客が空港で適切にサポートされるように法律が制定されている。例としては、ＥＵ規則１  １０７／２００６があり、この規則において、チェックインならびに手荷物の登録および預け入れのプロセスは、障害のある乗客や身体の不自由な乗客への支援について空港が責任を負う領域として特定されている。既存の、あるいは将来の法律では、自動またはセルフサービスのバッグドロップによる問題解決策へのアクセスが必要であり、また、例えば、車椅子用に指定されたタッチアクセスの最大高さや、視覚障害のある乗客のための特定の追加の制御装置が必要になる場合がある。
【０００６】
本発明は、これらの問題に対処し、これらの問題を改善することを目的とする。
【課題を解決しようとする手段】
【０００７】
本発明の一態様によれば、チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法が提供され、当該方法は：チケットおよび当該チケットに関連するセルフサービス機能に関する情報が格納されているモバイルデバイスによって、セルフサービス機能への近接を検出するステップと；モバイルデバイスが該位置への近接を検出したら、モバイルデバイス上で、セルフサービス機能に関連するアプリケーションを起動するステップと、アプリケーションを介してモバイルデバイスと通信するステップと、を含み、セルフサービス機能に関する情報には方向情報が含まれている。
【０００８】
本発明はまた、チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にするためのシステムを提供し、当該システムは：セルフサービス機能と；チケットに関する情報が格納されているモバイルデバイスと；少なくともジオロケーションデバイスであって、モバイルデバイスが、セルフサービス機能に近接する位置で当該ジオロケーションデバイスを検出するように構成されている、ジオロケーションデバイスと；少なくとも１つのサーバであって、モバイルデバイスが、該位置に近接するジオロケーションデバイスを検出したら、モバイルデバイス上で、セルフサービス機能に関連するアプリケーションを起動するステップと、アプリケーションを介してモバイルデバイスと通信するステップと、を実行するためのコンピュータソフトウェアが格納されている少なくとも１つのサーバと、を備え、セルフサービス機能に関する情報には方向情報が含まれている。
【０００９】
本発明の第２の態様は、チケット所有者と当該チケットに関連するセルフサービス機能とのインタラクションを容易にする方法を提供し、当該方法は：チケットに関連するセルフサービス機能に近接する位置において、チケットに関する情報が格納されているモバイルデバイス上で、セルフサービス機能に関連するアプリケーションを起動するステップと；アプリケーションを介してモバイルデバイスと通信するステップと、を含み、セルフサービス機能に関する情報には方向情報が含まれている。
【００１０】
本発明の実施形態は、チケット所有者とセルフサービス機能とのインタラクションを単純化するという利点を有し得る。好ましい一実施形態では、セルフサービス機能は、例えば空港で使用される、バックドロップシステムである。本発明の実施形態は、バッグドロップとのインタラクションをより単純化し、航空会社または他のサービスプロバイダが、バッグドロップおよび他のセルフサービスプロセスに必要とされる対人のインタラクション量を減らすことを可能にし、したがってコストおよび間接諸経費を削減できるという利点を有し得る。
【００１１】
本発明の一実施形態において、チケットは、乗客の旅に関するものであり、乗客および旅の識別を含んでいる。チケット情報には、搭乗券が含まれていてもよい。一実施形態において、その位置におけるモバイルデバイスの存在は、例えばBluetoothビーコンなどのジオロケーションデバイスを使用して検出され得る。
【００１２】
一実施形態では、アプリケーションは、モバイルデバイスに格納されているチケット情報を照会し、チケット情報をリモートサーバに通信する。リモートサーバは、チケット情報の受信に応答して、モバイルデバイスのユーザに提示するために、セルフサービス機能に関する情報をアプリケーションに提供する。
【００１３】
一実施形態では、セルフサービス機能がバッグドロップであり、チケットに関する情報が搭乗券であり、搭乗券の乗客情報は出発管理システムに通信される。出発管理システムは、搭乗券に関連する手荷物がバッグドロップに適格であるかどうかを判定し、その適格性をモバイルデバイスに通信する。
【００１４】
本発明の一実施形態では、バッグドロップでバッグを預け入れる際に、バッグの重量が測定され、当該重量が許容重量を超えているかどうかが判定され、当該重量が許容重量を超えている場合は、アプリケーションを介して超過手荷物料金の支払いが手配される。
【００１５】
一実施形態では、バッグドロップでバッグタグが印刷され、当該バッグタグをバッグに固定する指示は、ユーザに提示されるように、アプリケーションを介してモバイルデバイスに通信される。
【００１６】
一実施形態では、バッグドロップによるバッグの受領時に、搭乗および出発ゲートへのルートに関する情報がアプリケーションに通信される。
【００１７】
つぎに、本発明の実施形態を、単なる例として、添付の図面を参照して説明する。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態の概略図である。
【図２】本発明の一実施形態におけるステップを示すフローチャートである。
【図３】本発明を実施するシステムの概略図である。
【図４】システムの論理アーキテクチャを示す図である。
【図５】クラウドサービスの論理アーキテクチャを示す図である。
【図６】利用可能なインタフェースを示すサービスモデルを示すクラス図である。
【図７】バッグユニットコントローラの概略図である。
【図８】モバイルデバイスアプリケーションで生じるハイレベルなインタラクションを示す図である。
【図９】モバイルアプリケーションのプロセスフローを示す図である。
【図１０】システム全体のプロセスフロー図である。
【発明を実施するための形態】
【００１９】
以下の例において、バッグドロップのシーケンスは、乗客のスマートフォン、タブレット、ノートパソコンまたは同様のモバイルコンピューティングデバイスから開始される。Bluetoothビーコンまたは他の位置センサなどのジオロケーション技術を使用して、モバイルデバイス上のアプリが特定のビーコンまたは他のデバイスの近くにあることを検出できるようにする。しかしながら、自動位置検出は、本発明に必須ではない。バッグドロップに関連して説明しているが、本発明の実施形態は、バッグタグや搭乗券の印刷、パスポートのスキャンまたは他の機能のための乗客処理キオスクなどの、他の乗客インタラクション、乗客のスマートフォンまたは他のデバイスを介したモバイル対応支払いとのインタラクション、セルフサービスのチェックポイントおよびゲート（自動の入出国審査ゲートまたはバリアなど）を含むがこれらに限定されない他の空港設備とのインタラクションと組み合わせて使用することもできる。実施形態は、特に空港に関連して説明されているが、本発明は、乗客がチェックインまたは手荷物の預け入れを要求されるあらゆる旅行環境への広範な適用性を有し、したがって海港および鉄道も含まれる。本発明の実施形態は、スポーツ会場やコンサートおよびフェスティバルなどのエンターテイメントなど、大量のチケットが発券されるイベントで、見物人および観客を導くのを助けるために使用することもできる。
【００２０】
特に、空港での解決策に関連する図示の実施形態では、空港の周辺に配置されたBluetoothビーコンなどの位置特定技術を使用して、スマートフォン、タブレット、ノートパソコンまたは他のデバイスなどの乗客のモバイルデバイスが、特定のビーコンの存在を識別できるようにしている。他の屋内または屋外のジオロケーション技術を使用して、デバイスがその相対位置を識別できるようにする。しかしながら、明らかになるように、Bluetoothビーコンまたは他の位置特定技術は、好ましいが本発明に必須ではない。モバイルデバイスは、乗客がダウンロードするバッグドロップアプリケーションを有する。このアプリケーションは、独自のバッグドロップアプリであるか、あるいは航空会社または空港アプリのバッグドロップモジュールである。モバイルデバイス１０は、例えば、それが空港に入って第１のビーコン１２の近くを通過するときに、位置装置の存在を検出する。乗客が空港を通過してバッグドロップエリアに向かうと、デバイス１０によって第２のビーコン１４が検出され、該デバイスでバッグ預け入れアプリケーションが開始される。空港への進入時に乗客のモバイルデバイスが第１のビーコンを検出することは必須ではないが、デバイスによるビーコンの検出により、空港で提供される他のサービスとのインタラクションが可能になるため有利である。
【００２１】
ビーコン検出を使用して、空港または同様の環境を通過する乗客の動きを追跡することは、国際公開第２０１３／１１７７２３号に記載されている。
【００２２】
アプリケーションが開始されると、該アプリは、例えばApple（登録商標）ウォレットまたは同様のアプリを使用して、電話に格納されている乗客の搭乗券から該乗客の予約の詳細を照会するか、搭乗券が格納されていない場合、乗客のデバイスのカメラまたはバッグドロップにあるスキャナを使用して、印刷された搭乗券をスキャンするように乗客に求める。
【００２３】
モバイル搭乗券がデバイスに格納されている場合、アプリは、格納された乗客関連データから、該乗客がバッグをチェックインしたかどうかを識別し、チェックインしていれば個数を識別する。バッグがチェックインされている場合、次に、アプリは、バッグドロッププロセスを進め方についての指示を乗客に表示する。バッグのチェックインが検出されない場合、アプリは、チェックインを許可するために、予約を修正するオプションを乗客に提供する。
【００２４】
そのインタラクションが他のセルフサービス機能とのものである場合、プロセスは同様の方法で機能する。例えば、その機能がセルフサービスの入出国審査である場合、同様に、アプリは一意的なアプリまたは航空会社もしくは空港のアプリのモジュールであり、パスポートチェックエリアでデバイスを検出し、パスポートスキャナの進め方およびその通過方法について、デバイスを介してユーザに指示を提示する。
【００２５】
このように、一実施形態において、システムは、乗客のスマートフォンまたは他のモバイルデバイス、ならびに任意選択で、Bluetoothビーコンまたは他のタイプのセンサおよびマッピングアプリケーションなどの任意の屋内または屋外のジオロケーション技術を使用して、バッグドロッププロセス、または空港もしくは他の関連する場所でシステムとのインタラクションを必要とする任意の他の乗客プロセスを自動化する。バッグドロップエリア、乗客処理キオスクまたはステーション、チェックポイントまたはe-gateの近くにいると、乗客のスマートフォンまたは他のモバイルデバイスのモバイルアプリがアクティブになり、乗客および該乗客の予約の詳細が識別される。乗客のデバイスは、バッグドロップユニットと「ペアリング」され、バッグドロップの処理方法に関する詳細な手順は、すべてスマートフォンまたはモバイルデバイスを介して電子的に／無線で実行される。このシステムは、例えば、スマートフォン上のモバイルアプリケーション、バッグドロップユニットに接続された処理ユニット（コントローラ）、および以下に詳述されるモバイルアプリケーションとバッグドロップユニットとの間のインタラクションを仲介または「プロキシ」するクラウドベースのＡＰＩサーバを備えている。
【００２６】
以下に説明する実施形態では、モバイルデバイスを手荷物システムとペアリングするためのトリガ機構としてBluetoothを使用しているが、他の方法も可能である。例えば、別の近距離無線通信（ＮＦＣ），ＷＩＦＩまたはＢＬＥビーコンなどの別の種類の自動ペアリングを使用することができ、あるいはモバイルデバイスの所有者がスキャンしてアプリケーションを起動するＱＲコードもしくは別のバーコードなどの手動の方法、またはAmazon Alexa（登録商標）などの音声アクティベーションコマンドを使用することができる。バーコードを使用する場合、乗客は、チェックインデスクでステッカー上の２次元バーコードをスキャンするか、既知の方法でコードを撮影する。セキュリティ上の懸念に対処するために、バーコードはe-inkを使用して作成され、定期的に変更される。明確にするために、モバイルデバイスと手荷物取扱いシステムとの間の通信は、WIFIまたは別の通信プロトコルを使用して、以下で説明するＡＰＩサービスを介して行われる。
【００２７】
バッグドロップに関するプロセスは、乗客の視点から提示されている図２により詳細にしてされている。プロセスは、概して１００で示されている。ステップ１０２では、乗客は、彼らのスマートフォンまたは他のモバイルデバイスを介してオンラインでチェックインする。上述したように、これは、特定のアプリケーションを介して、あるいは航空会社のウェブサイトのチェックインモジュールを介して行うことができる。チェックインプロセスの一環として、乗客ＩＤおよび手荷物許可量などの様々な乗客情報を含むモバイル搭乗券が作成される。搭乗券は、モバイルデバイスの適切な保管場所に格納されている。適切な保管場所の例は、Apple IOSを実行しているデバイス上のAppleウォレットアプリケーションまたはAndroidを実行しているデバイス上のGoogle PassWalletである。他のストレージオプションも可能である。
【００２８】
各航空会社は、ツーストップのセルフバッグドロッププロセスと、ワンストップのプロセスと、のどちらを提供するのかを決定することができる。図２の例は、ツーストップのプロセスであり、ステップ１０６で、乗客はバッグタグを印刷し、そのタグを手荷物に貼り付ける。この印刷は、ユーザの自宅またはオフィス環境または空港のキオスクで行うことができる。キオスクは、バッグタグの印刷専用とすることもできるし、オンラインチェックインなどの他の機能を提供することもできる。ワンステップのプロセスでは、ステップ１０６が省略され、乗客はバッグドロップに直行する。
【００２９】
空港に入ると、乗客のモバイルデバイスは、空港の入口近くに配置されたビーコンを検出する（図１の１２）。乗客が空港のドロップバッグエリアに入って第２のビーコン１４に近づくと、モバイルデバイスは再び第２のビーコンを検出する。この検出により、ユーザのモバイルデバイスアプリケーションのインテントがインスタンス化される。ＡＰＩコールは、ビーコンによって表されるバッグドロップの詳細を取得するために行われ、ＡＰＩコールからのバッグドロップＩＤおよびモバイルデバイスＩＤを使用してクラウドサービスに対して行われたセッションリクエストを取得する。これについては、以下で詳述する。
【００３０】
乗客のスマートデバイスを介したメッセージングに代えて、空港の関連部分に、バッグドロップアプリを開くか、ウェブサイトにアクセスするように乗客に指示する標識を提示することができる。ＱＲコードまたは他のバーコードが提供されて、それがデバイスのカメラでスキャンされると、アプリまたはウェブサイトが自動的に開くか、あるいはそのアプリが既に開いている場合はバッグドロッププロセスが開始される。このオプションには、航空会社にとって、バーコードには空港内の場所に広く対応する個々のコードが含まれ得るため、特定の乗客がどのセルフバッグドロップ（ＳＢＤ）を使用しているのかを知れる、という利点がある。これは、航空会社が使用状況を監視し、乗客の流れを制御するのに役立つ。
【００３１】
推奨されるオプションの１つでは、乗客のデバイスへのメッセージとサイネージ（標識）の両方を使用して、信頼性を向上させ、また、乗客がBluetoothのスイッチを入れ忘れた場合などに、システムを使用できるようにする。
【００３２】
一実施形態では、サイネージには、視覚障害のある乗客のための点字指示が含まれ、アプリには、音声指示が含まれるものとすることができる。
【００３３】
ステップ１１０において、乗客は、バッグドロップアプリを開いた状態で、指定されたバッグドロップに進む。アプリは、特定の１つの、またはグループのセルフバッグドロップターミナルにいるように乗客に指示することができる。この段階で、バッグドロップアプリケーションまたはモジュールは、デバイスに格納されている搭乗券データを取得している。これには、手荷物許容量の情報が含まれている場合があり、あるいは乗客IDを使用して航空会社の出発管理システム（ＤＣＳ）からその情報を取得することができる。適格性チェックを実行して、例えば、乗客が荷物を預け入れるには早すぎる、遅すぎるか、あるいはモバイルデバイスのバッグドロップオプションが特定のフライトでは利用できないかどうかを判断することができる。
【００３４】
ステップ１１２では、乗客はバッグドロップエリアに現れ、アプリケーションは、乗客に彼らのバッグを手荷物ベルトまたは静止スケール上に置くように求めるメッセージを表示する。従来のバッグドロップと同様に、許容重量内にあることを確認するためにバッグの重量が測定される。重量はアプリに通知され、受信した重量を、搭乗券の一部として格納されているか、あるいはＤＣＳから取得できる許容重量と照合することができる。
【００３５】
バッグが重量チェックに合格しなかった場合、乗客は超過手荷物の支払いを求められる。これは、航空会社のアプリケーションに事前に保存されているクレジットカードまたはデビットカードで、あるいは通常のオンライントランザクションで行われる。このトランザクションは、「Card not present」タイプであり、各航空会社に固有のものであり、各航空会社には独自の超過手荷物料金がある。
【００３６】
重量が許容限度内にあるか、あるいは超過分が支払われたと仮定すると、ステップ１１４でバッグタグが印刷される。上記のツーステップのプロセスの場合、バッグタグは既にあるため、このステップは不要である。その後、アプリは、バッグタグをバッグに貼り付ける方法に関する情報を乗客に表示する。
【００３７】
バッグタグが貼り付けられると、デバイスカメラを介してＬＰＣバーコードが読み取られることが可能になる。これは、バッグが意図した目的地に到着していない場合、または乗客がフライトに出向かない場合、または補償請求が行われる場合に役立つ。一実施形態において、バッグの３Ｄスキャンを実行して、バッグが許容寸法内にあり、運搬されるのに適切な厳密さで構築されていることを確認することができる。
【００３８】
ステップ１１６で、乗客確認ステップが実行される。アプリは、航空会社のＤＣＳにアクセスできるため、ＰＮＲ（passenger name record：旅客予約記録）を取得し、タグ上のデータをその記録と比較することができる。アプリは、セルフィを撮るか、あるいは生体認証や指紋認証などのモバイルデバイスによって提供される１つまたは複数の他の形式の確認を使用するように、乗客に指示することができる。この方法で収集されたデータは、後で参照するために格納しておくことができる。乗客の確認は、バッグタグを印刷する前に実行されてもよい。
【００３９】
ステップ１１８では、乗客の身元が確認されると、バッグは出発管理システム（ＤＣＳ）によって受け取られ、手荷物預かり証（クレームタグ）がスマートフォンで乗客に示される。この手荷物預かり証は、アプリケーションに保存され、かつ／あるいはモバイルデバイス上に保存される。次に、バッグは、手荷物取扱いシステムに引き渡されるが、このステップは、自動的に、あるいは航空会社のエージェントの支援を受けて実行される。
【００４０】
バッグが引き渡されると、アプリは、これに限定されないが、搭乗時間やゲートなどの乗客のフライトに関する詳細情報を乗客に提供することができる。この時点で、アプリは自動的に閉じるか、あるいは国際公開第２０１３／１１７７２３号に開示されているタイプのアプリケーション、すなわち空港周辺に配置された近距離ビーコンを使用して乗客を出発ゲートに誘導するタイプのアプリケーションを見つける方法に乗客を戻すことができる。
【００４１】
図３は、上記のプロセスで使用される重要なハードウェアコンポーネントを示している。乗客のモバイルデバイスは、２００で示されており、乗客のバッグをチェックインするためのロジックで構成されたアプリがロードされている。前述したように、アプリは、例えば、航空会社のアプリのモジュールまたはスタンドアローンのアプリとすることができる。デバイス２００は、航空会社の出発管理システム（ＤＣＳ）と、ＡＰＩおよび関連するロジックのセットをホストするクラウドサービス２２０と通信する。手荷物チェックインシステムには、手荷物チェックインユニット２３０と、ＢＣＩＵ２３０と通信するソフトウェアおよび／またはファームウェアを含む、手荷物チェックインユニット（ＢＣＩＵ）２３０に関連するハードウェアコントローラであるか、あるいは同じことを行うＣＵＴＥ／ＣＵＳＳモジュールであり得る、コントローラ２３５と、が含まれる。ＣＵＴＥ（Common Use Terminal Equipment）およびＣＵＳＳ（Common Use Self Service）。ＣＵＴＥおよびＣＵＳＳは、複数の航空会社またはサービス会社がハードウェアを使用できるようにする、周知の規格である。また、コントローラもクラウドサービス２２０と通信する。必須ではないが、ビーコン２４０は、Bluetooth（登録商標）または別の通信プロトコルを介して、モバイルデバイスと通信するバッグドロップエリアを自動で識別するために提供される。ビーコンが使用される場合、モバイルデバイス２２０は、ビーコンレジストリ２５０とも通信してバッグドロップ識別子を取得する。ビーコンが使用される場合でも、そのサービスがクラウドサービス２２０によってサポートされるため、ビーコンレジストリ２５０が必須ではない場合がある。
【００４２】
図４は、システムの論理アーキテクチャを示している。一般に、クラウドサービス（図３の２２０）は、モバイルデバイス２００と手荷物ユニットコントローラとの間のブローカとして機能する。このサービスは、単一の接続エンドポイントをモバイルデバイスに公開し、ネットワーク関連の複雑さを緩和し、無線プロトコルを介した複数のデバイスを許可し、バッグドロップサービスの可用性を管理し、そしてコントローラ固有のメッセージングのアブストラクトを作成する。ウェブソケット（Websocket）接続４００は、モバイルデバイス２００とクラウドサービスとの間、およびクラウドサービスと手荷物ユニットコントローラとの間に確立されている。後者の接続は、手荷物ユニットコントローラによって確立され、該コントローラの使用時間中維持される。接続が確立されていることを保証するのは、コントローラ側の責任である。接続が終了した場合、コントローラは接続を再度確立する必要がある。クラウドサービスは、ウェブソケット接続がアクティブでない場合、バッグドロップユニットが利用できないものとみなす。ウェブソケットとして説明しているが、他の非同期メソッドまたは双方向同期メソッドを使用することができる。
【００４３】
同様に、モバイルデバイス２００は、クラウドサービス２２０との通信を確立し、セッションの存続中は接続を維持する役割を果たす。コントローラと同様に、各モバイルデバイスからのサービスの検出により、プロセスが合理化される。エンドツーエンドセッションは、モバイルデバイスおよびバッグユニットコントローラの両方のＩＤをバインドすることでマッピングされる。
【００４４】
図５には、クラウドサービス２２０の論理アーキテクチャが示されている。クラウドサービスは、分散型リアクティブプラットフォームでホストされる一連のマイクロサービスで構成されている。各サービスエンドポイントは、演算子（ｏｐ）に基づくイベントがイベントバスを介してルーティングされるアドレスを登録している。ウェブソケットサービスは、コントローラやモバイルデバイスと直接通信する外部向けサービスである。
【００４５】
図６は、利用可能なインタフェースを反映するサービスモデルを示すクラス図６００であり、本質的にサービスプラットフォームモデルよりもざっくりしたものである。サービスは以下の通りである。
【００４６】
［バッグドロップサービス６０２］
このサービスは、モバイルデバイスとコントローラとの間のセッションで使用されるインテフェースを含む。一部のインタフェースは、セッションなどの追加のサービスに“パススルー”する場合があるが、すべてではないにしても、ほとんどの基本インタフェースがここで管理される。これらには、バッグ導入サービス、バッグタグ印刷サービス、スケールサービスなどが含まれる。
【００４７】
［バッグドロップマネジメントサービス６０４］
このサービスは、コントローラの管理を操作する。コントローラが始めて起動されると、登録依頼が送信される。このサービスは、構成サービス６０６とインタラクションして、その依頼を検証し、コントローラの新しい構成を保存する。また、コントローラの利用可能ステータスも操作する。
【００４８】
［タイマーサービス６０８］
セッションには、事前に定義された非アクティブ期間がある。タイマーサービスはこれを管理し、セッションサービスとインタラクションして、セッション状態全体を操作する。
【００４９】
［構成サービス６０６］
上述したように、このサービスは、バッグドロップマネジメントサービスとインタラクションして、コントローラを登録および登録解除する。さらに、各コントローラには、アップロードして保存することができる固有の属性がある。インタフェースを介して、コントローラを有効または無効にすることができる。
【００５０】
［セッションサービス６１０］
このサービスは、モバイルデバイスとコントローラとの間のセッションを管理する。認証サービスとインタラクションして、start_session上でユーザを認証し、トークンを検証する。また、タイマーサービスとインタラクションして、一定の非アクティブ期間の後にセッションを無効にする。
【００５１】
［認証サービス６１２］
このサービスインタフェースは、認証および承認の１つまたは複数の実装に対するファサードとして機能する。最初の実装では、ローカルユーザＩＤ／パスワード認証スキームと、認証用のＪＷＴ（JSON Web Tokens）と、が提供される。
【００５２】
図７は、図３のバッグユニットコントローラ２３５の論理アーキテクチャを示す。
任意の適切なコンピューティングデバイスホストとすることができるワークステーション７０２は、ハードウェアサービス７０４およびバッグドロップコントローラサービス７０６をホストする。ワークステーションは、好ましい実施形態では、例えば、上述したようにWindows（登録商標）オペレーティングシステムを実行する一般的な使用端末として構成される。バッグドロップコントローラサービスは、ウェブソケット７０８およびハードウェア通信レイヤ７１０を介して、クラウドサービスとハードウェアサービスとの間の通信レイヤとして機能する。また、マシンの状態を管理し、クラウドサービスに登録する。ハードウェアサービス７０４は、ＩＯサーバ７１０および他のハードウェア周辺機器に接続している。あるいは、ハードウェアサービスは、一般的に使用されるセルフサービスモジュール（Common Use Self-Service module）に接続していてもよい。
【００５３】
ＩＯサーバ７１０は、１つまたは複数の手荷物ベルトセットアップ７１４および他のハードウェア７１６を制御するために、プログラマブル論理制御装置（ＰＬＣ）７１２を含む。それは、空港の手荷物処理システムに接続されているか、あるいはハードウェアに直接接続されている。
【００５４】
図８は、モバイルデバイスアプリケーション（アプリ）８００のアーキテクチャを示す。このアプリには、ソフトウェア開発キット（ＳＤＫ）８０２と、ユーザ作成イベントハンドラ８０４と、の２つの主要コンポーネントがある。モバイルデバイスのアーキテクチャは、適用可能な処理の多くをＳＤＫ８０２にプッシュするように設計されている。これにより、特定の航空会社または外部ベンダーであるアプリ開発者がサービスを実装し易くなる。適用可能な処理には、モバイルデバイスとクラウドサービスとの間のソケット通信だけでなく、ワークフローも含まれる。
【００５５】
これを実現するために、アプリ開発者は、文書化されたイベントリスナ、またはハンドラ８０４のセットを実装する。これらのリスナ、またはオブザーバは、ＳＤＫからのコールバックを受け入れるように登録され、この時点で、ハンドラは、特定の結果を得るために事前に定義されたロジックを実行する。ハンドラ８０４は、結果とともにＳＤＫ８０２をコールすること、あるいは単にその完了をSDK８０２に通知することも要求され得る。図８は、ＵＸ（ユーザエクスペリエンスレイヤ）８０６、アプリケーションロジック８０８、およびＳＤＫ８０２間のハイレベルなインタラクションを示している。
【００５６】
以下の表１は、アプリ開発者が実装するイベントハンドラのリストである。
【００５７】
【表１】
2021503108.tif 000003
【００５８】
表２は、アプリによって実装されるＳＤＫのメソッドコールのリストである。
【００５９】
【表２】
2021503108.tif 000004
【００６０】
図９は、ＳＤＫ８０２、航空会社のモバイルアプリコンポーネント、およびＵＸ８０６間のエンドツーエンドのインタラクションを示すプロセスフロー図である。図９の例では、バッグタグはまだ印刷されていない。バッグタグが既に印刷されている場合は、これをサポートするために別のパスが使用される。
【００６１】
図１０は、主要なシステムアクター、モバイルデバイスアプリ、クラウドサービス、およびセルフバッグドロップユニット間のエンドツーエンドのインタラクションを示す。ＤＣＳ（Departure Control System：出発管理システム）のアプリとのインタラクションも示されている。図９の例と同様に、バッグタグはまだ印刷されていない。バッグタグが既に印刷されている場合、別のパスが使用される。
【００６２】
セキュリティは、全てのセッションについて、モバイルデバイスとクラウドサービスとの間、およびクラウドサービスとバッグドロップユニットコントローラとの間のすべての通信が、安全な暗号化プロトコル上にあることを確実にすることによって実現される。
現在、安全なウェブソケットプロトコル（ＷＳＳ）が好ましい。ＪＳＯＮウェブトークン（ＪＷＴ）は、すべてのレイヤにわたるトランザクションを認証および承認するために使用される。ＪＷＴは、デジタル署名または暗号化が可能なＪＳＯＮオブジェクトとしてエンコードすることにより当事者間のクレームを表す、コンパクトでＵＲＬセーフな手段である。
【００６３】
モバイルデバイスアプリでは、モバイルデバイスとクラウドサービスとの間で、ＨＭＡＣ（Hash-based Message Authentication Code）アルゴリズムが使用される。各クライアント（例えば、航空会社）は、単一のユーザＩＤとパスワードの組み合わせを受け取る。session_startにおいて、これらの資格情報は、クラウドサービスに渡され、クラウドサービスによって検証される。秘密鍵を使用してＪＷＴが生成される。モバイルデバイスは、各リクエストでＪＷＴを送信する責任がある。新しいＪＷＴは、クラウドサービスによっていつでも生成することができる。モバイルクライアントは、クラウドサービスから受信した各イベントでＪＷＴを保存し、後続のリクエストで最新バーションを返す責任がある。
【００６４】
ＨＭＡＣアルゴリズムは、バッグドロップユニットコントローラと、クラウドサービスとの間でも使用される。各バッグドロップユニットコントローラには、一意のＩＤ、ユーザネームおよびパスワードが事前に設定されている。モジュールが初めて起動すると、コントローラはクラウドサービスに登録し、登録リクエストでその一意の資格情報を渡す。登録が成功すると、クラウドサービスの応答にはＪＷＴが含まれるが、これは、コントローラからクラウドサービスへの各メッセージで必要になるものである。
【００６５】
代わりに、ＲＳＡ公開／秘密鍵暗号化を使用することができる。
【００６６】
ＡＰＩは、クラウドサービス２２０とコントローラ２３５との間、クラウドサービス２２０とモバイルデバイス２００との間、ならびにクラウドサービス２２０とコントローラおよびモバイルデバイスとの間のインタラクションを（プロキシモードで）処理する。
【００６７】
各ＡＰＩイベント、または操作は、安全なウェブソケット接続（ｗｓｓ）を介してＪＳＯＮペイロードで伝達され、イベント演算子（ｏｐ）を含む。ｔｙｐｅ演算子は、メッセージを適切なハンドラにルーティングするために使用される。
【００６８】
モバイルアプリとバッグドロップユニットとの間のセッションは、start_session中に開始され、Ｊｓｏｎウェブトークンを使用して伝播され、セッション終了コールまたはタイムアウトで終了する。モバイルアプリのクライアントには、クラウドサービスへの呼び出しごとにトークンを渡す必要がある。ウェブソケット接続を介してクラウドサービスとのみ通信するときには、これはＳＤＫの責任である。
【００６９】
１．クラウドサービス−モバイルデバイス
基本的なコマンドは、次の形式で送信される：
[数１]
{
"token": "<service-supplied token>",
"op": "<command>",
"txid": "<generated transaction id>",
"args": [{
"key1": "val1",
"key2": "val2",
"key3": "val3"
}]
}
【００７０】
この形式は、アプリケーションのユーザＩＤおよびパスワードが送信される、start_sessionを除くすべてのＡＰＩコールに有効である。結果として返されるトークンは、認証の成功、およびバッグドロップユニットとのアクティブセッションを示す。リクエスタのトランザクションＩＤは任意選択である。トランザクションＩＤを受信した場合、応答ペイロードで返すことが推奨されるが、必須ではない。
【００７１】
［reply］
replyは、クラウドサービスまたはモバイルデバイスのいずれかによって送信される一般的な応答である。メッセージには、以前のリクエストに関する情報と、（任意選択の）トランザクションＩＤと、が含まれている。これは、特定の応答ペイロードのないリクエストを確認するために使用することができる。このＡＰＩは双方向である。
【００７２】
【表３】
2021503108.tif 000005
【００７３】
例
[数２]
{
"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"
}]
}
【００７４】
【表４】
2021503108.tif 000006
【００７５】
［Start_session］
Start_sessionは、ＩＤで示されるバッグドロップとのセッションがクライアントで開始されることをリクエストする。資格情報は、リクエストで渡される。システムの各クライアントは、固有の資格情報のセットを有することになる。資格情報は、各アプリユーザに固有ではない。これは、一方向の、非同期リクエストである。クライアントは、このコールの結果として、session_readyまたはno_sessionイベントを受け取ることになる。一般的に、方向は、モバイルアプリからクラウドサービスである。
【００７６】
【表５】
2021503108.tif 000007
【００７７】
例
[数３]
{
"op": "start_session", 
"args": [{
"uid": "myClientId",
"pwd": "myClientPwd",
"bagdrop_id": "ID105211"
}]
}
【００７８】
［session_ready］
session_readyは、start_sessionリクエストから生じる２つのイベントのうちの１つである。これは、バッグドロップユニットとのセッションが開始されたことをクライアントに通知する。応答には、例えば、バッグタグおよびレシートの印刷が可能かどうかといったバッグドロップユニットの機能が含まれる。一般に、方向は、クラウドサービスからモバイルアプリである。
【００７９】
【表６】
2021503108.tif 000008
【００８０】
例
[数４]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "session_ready",
"args": [{
"bagdrop_id": "ID105211"
"config": [{
"print_bagtag": true,
"print_receipt": true
}],
}]
}
【００８１】
［no_session］
no_sessionは、start_sessionリクエストから生じる２つのイベントのうちの１つである。これは、バッグドロップユニットとのセッションが正常に開始されなかったことをクライアントに通知する。理由コードが応答に添付される。一般に、方向は、クラウドサービスからモバイルアプリである。
【００８２】
【表７】
2021503108.tif 000009
【００８３】
例
[数５]
{
"op": "no_session",
"args": [{
"bagdrop_id": "ID105211",
"reason_code": "OUT_OF_SERVICE"
}]
}
【００８４】
【表８】
2021503108.tif 000010
【００８５】
［end_session］
end_sessionは、いずれかの当事者によって送信されて、該送信者がセッションの終了を希望していることを示すものである。通常は、モバイルアプリから送信されるが、双方がクリーンアップするために、いくつかの理由でクラウドサービスによって送信される場合がある。一般的に、方向は、モバイルアプリからクラウドサービスであるが、クラウドサービスから送信される場合もある。
【００８６】
【表９】
2021503108.tif 000011
【００８７】
例
［数６]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "end_session",
"args": [{
"bagdrop_id": "ID105211",
"reason_code": "PROCESS_COMPLETE"
}]
}
【００８８】
【表１０】
2021503108.tif 000012
【００８９】
［scale_result］
scale_resultは、クラウドサービスによって送信され、バッグドロップユニットから転送され、バッグドロップユニットのスケールによるバッグの計量結果を中継する。応答には、空港または手荷物処理システムの重量／サイズに関する制限が含まれる。方向は、クラウドサービスからモバイルアプリである。
【００９０】
【表１１】
2021503108.tif 000013
【００９１】
例
[数７]
{
"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"
}]
}
【００９２】
【表１２】
2021503108.tif 000014
【００９３】
［print_bagtag］
print_bagtagは、モバイルデバイスからクラウドサービスに送信される。リクエストはバッグドロップユニットに配信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれている。方向は、モバイルアプリからクラウドサービスである。
【００９４】
【表１３】
2021503108.tif 000015
【００９５】
例
[数８]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_bagtag",
"args": [{
"bagdrop_id": "ID105211",
"image": "<image to print>",
"format": "PECTAB"
}]
}
【００９６】
【表１４】
2021503108.tif 000016
【００９７】
［induct_bag］
induct_bagは、モバイルデバイスからクラウドサービスに送信される。リクエストがバッグドロップユニットに配信されるため、プロキシコールとみなされる。リクエストは、暗示されているように、バッグドロップユニットがバッグを手荷物取扱いシステムに導入することを開始することである。このコールは、構成に基づいて任意選択とすることができる。例えば、一部の構成では、特にバッグタグが事前に印刷されていてバッグに取り付けられている場合、特定のステップの後にバッグを自動的に導入することが必要になる場合がある。方向は、モバイルアプリからクラウドサービスである。
【００９８】
【表１５】
2021503108.tif 000017
【００９９】
例
[数９]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "induct_bag",
"args": [{
"bagdrop_id": "ID105211"
}]
}
【０１００】
［print_receipt］
Print_receiptは、モバイルデバイスからクラウドサービスに送信される。リクエストがバッグドロップユニットに配信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれる。
【０１０１】
方向は、モバイルアプリからクラウドである。リプライが期待される。
【０１０２】
【表１６】
2021503108.tif 000018
【０１０３】
例
[数１０]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_receipt",
"args": [{
"bagdrop_id": "ID105211",
"image": "<image to print>",
"format": "PECTAB"
}]
}
【０１０４】
【表１７】
2021503108.tif 000019
【０１０５】
２．クラウドサービス−コントローラ基本的なコマンドは、以下の形式で送信される：
[数１１］
{
"token": "<server-supplied token>",
"op": "<command>",
"txid": "<generated transaction id>",
"args": [{
"key1": "val1",
"key2": "val2",
"key3": "val3"
}]
}
【０１０６】
この形式は、手荷物処理ユニットの固有のＩＤ、ユーザ名およびパスワードが送信される、registerを除くすべてのＡＰＩコールに有効である。リクエスタのトランザクションＩＤは任意選択である。トランザクションＩＤを受信した場合、応答ペイロードで返すことが推奨されるが、必須ではない。
【０１０７】
［reply］
replyは、クラウドサービスまたはコントローラのいずれかによって送信される一般的な応答である。メッセージには、以前のリクエストに関する情報と、（任意選択の）トランザクションＩＤと、が含まれている。これは、特定の応答ペイロードのないリクエストを確認するために使用することができる。このＡＰＩは双方向である。
【０１０８】
【表１８】
2021503108.tif 000020
【０１０９】
例
[数１２]
{
"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"
}]
}
【０１１０】
【表１９】
2021503108.tif 000021
【０１１１】
［register］
registerは、バッグドロップコントローラ（ＣＵＴＥ,ＣＵＳＳモジュールなど）からクラウドサービスに送信される。これは、コントローラが初めてオンラインになったときに送信される１回限りのメッセージである。コントローラは、登録リクエストの結果として、２つのイベントregisteredまたはregistration_failedのうちのいずれかを受け取る。方向は、コントローラからクラウドサービスである。
【０１１２】
【表２０】
2021503108.tif 000022
【０１１３】
例
[数１３]
{
"op": "register",
"args": [{
"bagdrop_id": "ID105211",
"username": "9e83a024-c374-4c3e-bd4e-ead758282513",
"password": "bfdfdcb7-4cd2-4b33-ae17-a11c45ae1802"
}]
}
【０１１４】
［registered］
registerdは、クラウドサービスからコントローラに送信される。このメッセージは、登録が成功し、セッションが開始されたことを示している。方向は、クラウドサービスからコントローラである。
【０１１５】
【表２１】
2021503108.tif 000023
【０１１６】
例
[数１４]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "registered"
}
【０１１７】
［registration_failed］
registration_failedは、クラウドサービスからコントローラに送信される。このメッセージは、コントローラを登録しようとしたときに問題が発生したことを示している。方向は、クラウドサービスからコントローラである。
【０１１８】
【表２２】
2021503108.tif 000024
【０１１９】
例
[数１５]
{
"op": "registration_failed",
"reason_code": "BAD_CREDENTIALS"
}
【０１２０】
【表２３】
2021503108.tif 000025
【０１２１】
［deregister］
deregisterは、バッグドロップコントローラ（ＣＵＴＥ,ＣＵＳＳなど）によってクラウドサービスに送信される。ＡＰＩリクエストは、コントローラがデコミットされたことをクラウドサービスに通知し、その記録をシステムから削除する。方向は、コントローラからクラウドサービスである。
【０１２２】
【表２４】
2021503108.tif 000026
【０１２３】
例
[数１６]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "register",
"args": [{
"bagdrop_id": "ID105211",
"username": "9e83a024-c374-4c3e-bd4e-ead758282513",
"password": "bfdfdcb7-4cd2-4b33-ae17-a11c45ae1802"
}]
}
【０１２４】
［mark_available］
mark_availableは、バッグドロップコントローラ（ＣＵＴＥ,ＣＵＳＳなど）によってクラウドサーバに送信される。ＡＰＩリクエストは、コントローラがセッションを受け入れることができるようになったことをクラウドサービスに通知する。コントローラがすでに使用可能である場合、リクエストはクラウドサービスによって無視される。すべての場合において、確認応答が返送される。方向は、コントローラからクラウドサービスである。
【０１２５】
【表２５】
2021503108.tif 000027
【０１２６】
例
[数１７]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "mark_available",
}
【０１２７】
［mark_unavailable］
mark_unavailableは、バッグドロップコントローラ（ＣＵＴＥ，ＣＵＳＳなど）によってクラウドサービスに送信される。ＡＰＩリクエストは、コントローラがセッションを受け入れることができないことをクラウドサービスに通知する。コントローラが既に使用不可とマークさえている場合、このリクエストはクラウドサービスによって無視される。すべての場合において、確認応答が返送される。方向は、コントローラからクラウドサービスである。
【０１２８】
【表２６】
2021503108.tif 000028
【０１２９】
例
[数１８]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "mark_unavailable",
"args": [{
"reason_code": "MAINTENANCE"
}]
}
【０１３０】
【表２７】
2021503108.tif 000029
【０１３１】
［scale_result］
scale_resultは、バッグドロップユニットによってクラウドサービスに送信される。応答には、空港または手荷物処理システムの重量／サイズに関する制限が含まれる。方向は、コントローラからクラウドサービスである。
【０１３２】
【表２８】
2021503108.tif 000030
【０１３３】
例
[数１９]
{
"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"
}]
}
【０１３４】
【表２９】
2021503108.tif 000031
【０１３５】
［print_bagtag］
print_bagtagは、クラウドサービスからからコントローラに送信される。リクエストはモバイルデバイスから発信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれている。方向は、クラウドサービスからクラウドコントローラである。コントローラからの応答が期待される。
【０１３６】
【表３０】
2021503108.tif 000032
【０１３７】
例
[数２０]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_bagtag",
"args": [{
"bagdrop_id": "ID105211",
"image": "<image to print>",
"format": "PECTAB"
}]
}
【０１３８】
【表３１】
2021503108.tif 000033
【０１３９】
［induct_bag］
induct_bagは、クラウドサービスによってコントローラに送信される。リクエストがモバイルデバイスで発信されるため、プロキシコールとみなされる。リクエストは、暗示されているように、バッグドロップユニットがバッグを手荷物処理システムに導入することを開始することである。このコールは、構成に基づく任意選択であるとみなされる場合がある。例えば、一部の構成では、特にバッグタグが事前に印刷されていてバッグに取り付けられている場合、特定のステップの後にバッグを自動的に誘導することが必要になる場合がある。方向は、クラウドサービスからコントローラである。応答が期待されている。
【０１４０】
【表３２】
2021503108.tif 000034
【０１４１】
例
[数２１]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "induct_bag"
}
【０１４２】
［print_receipt］
print_receiptは、クラウドサービスからコントローラに送信される。リクエストがモバイルデバイスから発信されるため、プロキシコールとみなされる。リクエストには、例えばpectab形式の、印刷する画像が含まれる。方向は、モバイルアプリからクラウドサービスである。応答が期待される。
【０１４３】
【表３３】
2021503108.tif 000035
【０１４４】
例
[数２２]
{
"token": "eyJpc3MiOiJ0b3B0YWwuY2....",
"op": "print_receipt",
"args": [{
"image": "<image to print>",
"format": "PECTAB"
}]
}
【０１４５】
【表３４】
2021503108.tif 000036
【０１４６】
説明してきたように、このシステムは、独自のアプリケーションまたは航空会社／空港のウェブサイト上のモジュールのいずれかである、フロントエンドアプリケーションを含む。これは、航空会社および／または空港が乗客にバッグドロップ（手荷物預け入れ）サービスを提供するためのインタフェースである。バックエンドのソフトウェアエンジンは、セルフサービスのバッグドロッププロセスのロジックをホストし、プロセスを駆動する。ＡＰＩは、アプリ、バックエンドのソフトウェアエンジンおよび手荷物処理システムのハードウェア、ならびにプリンタおよび計量機などのセルフサービスのバッグドロップ周辺機器間の通信を可能にした。他の迅速な周辺機器には、自動読み取り機および手荷物査定装置が含まれる場合がある。例えば、ＢＨＳハードウェアは、新規または既存のコンベアベルトおよび計量機を含む場合がある。
【０１４７】
本発明の実施形態は、モバイル搭乗券の代わりに、乗客が使用するために印刷された搭乗券が必要であり、一時的および永続的なバッグタグを含む任意のバッグタグ、タグなしの手荷物処理システム、およびセルフサービスで印刷されたバッグタグを伴う場合にも使用することができる。
【０１４８】
本発明の実施形態には多くの利点がある。既存のチェックインシステムおよびパスポートゲートなどの他のシステムに比較的小さな変更を加えるだけで、乗客にとっては、乗客とセルフサービスロケーションとの間のインタラクションがより簡潔になり、オペレータは、従来のチェックインおよび他の施設の人員配置などの一般費用を削減することが可能となる。乗客の観点からみると、利便性が提供されて時間が節約されるので、乗客の空港でのエクスペリエンスが向上する。本明細書では、バッグドロップシステムに関して説明してきたが、本発明の実施形態は、電子ゲートなどの空港の他のセルフサービス機能とともに使用することができ、電子パスポートおよび／または搭乗券チェック、最終搭乗チェック、ならびにチェックイン用および／またはバッグタグの生成および印刷用のキオスクを提供する。一実施形態において、乗客のモバイルデバイスは、空港に到着すると手荷物処理システムに接続し、乗客は正しいカルーセル（手荷物受け取り用の回転コンベア）に誘導されるとともに、乗客の荷物も該カルーセルに誘導される。
【０１４９】
本発明の実施形は、他の港、鉄道の大量輸送場所、ならびに個人がチケットチェックなどのサービスと対話する会場、競技場などで使用することができる。
【０１５０】
本発明の実施形態は、特定の障害を持つ乗客にとっても有利であり得る。例えば、スマートデバイスのオーディオ機能を使用することにより、視覚障害のある乗客の荷物の預け入れ、入出国審査およびその他の空港機能のエクスペリエンスを大幅に改善することができる。本発明の実施形態はまた、スマートデバイス上の乗客情報と、航空会社または空港が既存のモバイルアプリケーションを介して既に提供している場合がある支払いサービスと、の統合を可能にする。
【図１】
2021503108.tif 000037
【図２】
2021503108.tif 000038
【図３】
2021503108.tif 000039
【図４】
2021503108.tif 000040
【図５】
2021503108.tif 000041
【図６】
2021503108.tif 000042
【図７】
2021503108.tif 000043
【図８】
2021503108.tif 000044
【図９】
2021503108.tif 000045
【図１０】
2021503108.tif 000046
【国際調査報告】
2021503108.tif 000047
2021503108.tif 000048
2021503108.tif 000049