JP2020512713A - 共有インフラストラクチャにアクセスするためのシステム、装置、及び方法 - Google Patents

Abstract

１つ以上の電子装置へのアクセスを提供するためのコンピュータ処理装置が提供される。装置は、ユーザログインイベントに関連付けられたロケーション識別子を判定し、ロケーション識別子をユーザセッション識別子に関連付け、ロケーション識別子及び関連付けられたユーザセッション識別子をアプリケーション（１０９）に通信する（３０１３）、ように構成された処理手段（１０３）を備える。【選択図】図３

Description

本発明は、一般に、コンピュータ実装装置などの、共有インフラストラクチャへのアクセスを提供するためのシステム、方法、及び装置に関する。共有インフラストラクチャは、搭乗券又は手荷物タグを印刷するプリンタ、ドキュメントを読み取るスキャナ、或いは搭乗券又は手荷物タグを印刷するキオスクなどの、装置であってもよい。システムは、例えば、顧客、乗客、及び顧客又は乗客にサービスを提供する職員によって使用されてもよい。

通常、航空会社は乗客を処理するために、一般に空港から提供されるコンピューティング装置などの共通のインフラストラクチャを共有する。既知の共有される共通のインフラストラクチャソリューションは、柔軟性がなく、コストがかかり、配備及び動作が困難であり、そして、モバイル装置の使用などの最新技術に容易に対応できない。これは、既知のソリューションが航空会社に最小公分母環境での作業を強いているためである。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（商標）の特定のバージョン、Ａｄｏｂｅ（商標）Ｆｌａｓｈ（商標）の特定のバージョン、又はＪＡＶＡ（商標）の特定のバージョンなど、空港環境の共有装置で一般的に使用されるものは、既知のソリューションが特定のサービスとやり取り又はアクセスする方法を判定し得る。これにより、共有装置へのアクセスを提供する際に技術的な問題が生じることがある。

共有装置上で動作し得るＭｉｃｒｏｓｏｆｔ（商標）Ｗｉｎｄｏｗｓ（商標）プラットフォームなどの既知のプラットフォームは、閉じられたプラットフォームであることも理解されよう。これにより、ユーザは、プラットフォームと通信するためのローカルインターフェースを介してローカル空港環境の装置にアクセスする必要がある。このため、ローカル空港環境の１つ以上の装置とリモートで通信できるようにする手段はない。

したがって、既知のソリューションはアプリケーションインターフェースを介して（プリンタ、スキャナなどの）末端の周辺機器の機能にリンクしており、これにより、アプリケーションに影響を与えることなく、周辺機器を進化させ、乗客の使いやすさを追加することが妨げられていることは理解されよう。

更に、バーチャルプライベートネットワーク（ＶＰＮ）システムには、単に通信が送信されるトンネルと考えられるＶＰＮを介して、リモートシステムにアクセスした後、ユーザが更なるログオン資格情報などの追加データを入力する必要があるという問題がある。

本発明は、１つ以上の電子装置へのアクセスを提供するためのコンピュータ処理装置を提供することにより、これらの問題に対処することを目的とする。本装置は、ユーザログインイベントに関連付けられたロケーション識別子を判定し、ロケーション識別子をユーザセッション識別子に関連付け、ロケーション識別子と関連付けられたユーザセッション識別子とをアプリケーションに通信するように構成された処理手段を備える。

更に、本発明の実施形態では、１つ以上のトークンを１つ以上の装置に提供するメカニズムを提供する。装置が特定のトークンを使用することで、介入なしに通信が容易になる。

これは、データが機能コンポーネント間で受け渡される際にデータコンテンツを変換する、様々な機能コンポーネントを持たないＶＰＮシステムとは対照的である。

このため、システムにより、航空会社は、共通のインフラストラクチャを共有する別の航空会社によって課される制限なしに、独自の環境で動作できる。本発明は、コストを削減し、効率的な配備及び動作モデルを提供する、クラウドベースのサービスを提供する。本発明は、空港環境を航空会社環境から分離することを可能にし、これによって、すべてのエンティティがそれぞれのビジネスニーズに基づいて進化することを可能にする。本発明は、最新のＷｅｂ技術を使用した重要なデータ交換に基づいて、航空会社のアプリケーションに時代を超越したインターフェースを提供する。インターフェースは、クライアント装置の影響を取り除く。本発明は、空港の装置プロバイダーが航空会社のユーザから独立した環境をセットアップできるようにする使いやすいポータルを備えていてもよい。ポータルは、航空会社が、利用可能な空港及び場所でサードパーティに依存せずに即座にアプリケーションをアクティベートすることを可能にする。

本ソリューションのコア機能は、航空会社のアプリケーションが世界規模で利用可能な、空港の任意のロケーションで共有又は専用のインフラストラクチャに動的に加入（subscribe）することを可能にする共通ＡＰＩを提供する。共有又は専用のインフラストラクチャは、空港に限定されず、駐車場、ホテル、駅、コンベンションセンタ、市内中心部、クルーズ船などを含んでいてもよい。ＡＰＩは、ロケーション識別を使用して航空会社のユーザセッションを共有インフラストラクチャに関連付けることができる。ロケーション識別は、空港及び空港以外のロケーションのインフラストラクチャを一意に識別する簡単に作成可能な命名規則に基づいている。クライアントアプリケーションは、ＱＲラベル、ビーコン、ＮＦＣなど、様々な方法でロケーション識別を取得できる。

ソリューションのアーキテクチャは、搭乗券の取得、荷物の預け入れ、書類のスキャン、支払い、及び搭乗ゲートなど、ユーザの操作を必要とする物理的な装置からユーザインターフェースを分離することによるものである。これは、２つの通信チャネルによって実現でき、これにより、ワークステーション、タブレット、スマートフォンなどのユーザインターフェース装置に柔軟性をもたらすことができ、パスポートスキャナ、支払い用のチップ及びＰＩＮ、セルフ手荷物ドロップなどの装置の独立性を進化させ得る。

本発明の実施形態は、バックワードの互換性の必要性に対する解決策も提供する。本プラットフォームは、新しいプラットフォームが提供する柔軟性を活用しつつ、航空会社に、わずかな変更により、或いはまったく変更せずに従来のソフトウェアを使い続ける手段を提供する。これは、フィールドゲートウェイ機能によって実現され得る。

本発明の実施形態は、分散フレームワーク内の共有インフラストラクチャへのアクセスを提供することができるアーキテクチャを採用してもよい。この実装は、Ｍｉｃｒｏｓｏｆｔ（商標）Ｗｉｎｄｏｗｓ（商標）又はＬｉｎｕｘ（商標）又はＣｉｓｃｏ（商標）ＩＯｘ（商標）又はＡｎｄｒｏｉｄ（商標）アプリケーションの特定のバージョンに限定されない。

本発明の実施形態は、これらのシステムのいずれかで実行可能なアーキテクチャを採用する。これは、インターネットブラウザを使用することで実現できる。通常、ブラウザにはｈｔｍｌ５標準が提供される。これにより、ｈｔｍｌ５標準に従って、次世代ポータル（ＮＧＰ）分散ネットワーク、又は装置のフレームワークへのアクセスが可能になる。これには、ブラウザを実行するのに必要なリソースが求められる唯一のローカルリソースであるという利点がある。したがって、かなりの処理能力を必要とするプロセスの多くは、データセンタ又はクラウドの、航空会社のバックエンドシステム、オープンサーバシステム、出発管理システムなどのホスト環境に保存され或いは実行され得る。つまり、使用する必要があるローカルリソースは、ブラウザで使用されるものだけある。これにより、例えばデータベースをローカルにダウンロードする必要がないため、特定のアプリケーションを既知のソリューションよりも高速に実行させることができる。

本発明の第１の態様によれば、１つ以上の装置（１０８）へのユーザアクセスを提供するデータ処理システムが提供される。本システムは、ユーザのロケーション識別子を判定し、ロケーション識別子をユーザのユーザ識別子に関連付け、そして、ロケーション識別子及び関連付けられたユーザ識別子をアプリケーション（３０１）に通信する（３０１３）、ように構成された処理手段（１０３）を含む。

本発明の更なる態様によれば、１つ以上の電子装置へのアクセスを提供するためのコンピュータ処理装置が提供される。本装置は、ｉ）ユーザログインイベントに関連付けられたロケーション識別子を判定し、ｉｉ）ロケーション識別子をユーザセッション識別子に関連付け、そして、ｉｉｉ）ロケーション識別子及び関連付けられたユーザセッション識別子をアプリケーション（１０９）に通信する（３０１３）ように構成された、処理手段（１０３）を備える。

本発明の更なる態様によれば、リモート環境との認証を容易にするためのフィールドゲートウェイコンポーネントを備える電子装置が提供される。

本発明の更なる態様によれば、１つ以上の電子装置へのアクセスを提供する方法が提供される。本方法は、ａ）ユーザログインイベントに関連付けられたロケーション識別子を判定するステップと、ｂ）ロケーション識別子をユーザセッション識別子に関連付けるステップと、そして、ｃ）ロケーション識別子及び関連付けられたユーザセッション識別子をアプリケーション（１０９）に通信する（３０１３）ステップと、を含む。

本発明の更なる態様によれば、１つ以上の電子装置へのアクセスを提供するためのコンピュータプログラム製品が提供される。本製品は、実行されると、ユーザログインイベントに関連付けられたロケーション識別子を判定するステップと、ロケーション識別子をユーザセッション識別子に関連付けるステップと、そして、ロケーション識別子及び関連付けられたユーザセッション識別子をアプリケーションに通信する（３０１３）ステップと、を実行する。

アプリケーションはリモートデータセンタで提供されていてもよく、これによりデータセンタに対して追加のリソースを提供することができる。これにより、必要に応じてパフォーマンスを向上させることができる。言い換えれば、本発明の実施形態は、例えば、必要に応じてリモートデータセンタに追加のメモリ又はサーバを追加することにより、簡単に垂直的なスケーリング能力をもたらす。

ｈｔｍｌ５対応ブラウザを使用することの更なる利点は、アプリケーションの追加の認定が必要ないことである。新しい機能は、空港環境で新しいアプリケーションを使用して配備されるのではなく、ｈｔｍｌ５対応のブラウザを介して提供されるために、認証の必要がなく、これにより航空会社に大きな利益がもたらされる。更に、アプリケーションが他のベンダのアプリケーションと環境を共有する必要がないため、他のベンダのアプリケーションに対する責任が回避される。

更に、本発明の実施形態を実行するシステムにとって、環境が多くの異なるアプリケーション間で共有されないため、ＰＣＩコンプライアンスを達成することはより容易になる。

本発明の実施形態は、周辺機器のユーザビリティに関連する機能からドキュメントの印刷又は読み取りに必要なデータを分離することができる。データ交換はアプリケーションインターフェースの一部であり、周辺機器のユーザビリティ部分は設定により制御され、これにより、周辺機器は、アプリケーションに影響を与えることなくユーザビリティ機能を追加でき、インターフェースの寿命を維持することができる。

本発明の実施形態は、次世代ポータル（ＮＧＰ）ソリューションと呼ばれるソリューションを使用する。本ソリューションは、２つの異なるチャネルを提供することで実装され得る。これらのチャネルは、装置チャネル、及びグラフィカルユーザインターフェース（ＧＵＩ）チャネルと呼ばれ得る。これは、ｈｔｍｌ５が有効になっているインターネットブラウザと相まって、前述したように多くの利点を提供する。

したがって、本ソリューションは、異なる機能コンポーネント間の純粋なデータ交換に基づいている。その他の機能は、構成設定により管理されてもよい。したがって、変更が必要な場合は、構成機能設定を使用してこれらの変更を実行してもよい。したがって、いくつかの実施形態では、アプリケーションインターフェースは純粋なデータのみによって駆動される。アプリケーションのユーザビリティは、構成設定によって構成される。

装置側では、同様のアーキテクチャが採用されてもよい。例えば、これによって、装置インターフェースのルックアンドフィールに関連する可能性のある、データ交換サービスと構成サービスとの論理的な分離に焦点が当てられる。

例えば、空港環境は、サービスを利用可能にしてもよく、或いは、換言すると、ユーザが使用するＡＰＩ環境にサービスを公開してもよい。航空会社などのアプリケーション環境の加入者は、公開されたサービスを表示してもよい。これにより、ユーザは公開されている多数のサービスのいずれか１つ以上に加入することができる。公開及び加入サービスは、独立して提供されてもよい。

既知のＶＰＮシステムとは対照的に、本発明では、データコンテンツは、双方向通信及びエンドツーエンド認証も使用して、複数の機能コンポーネントによって変換される。データは、ルールエンジンに基づいて変換されてもよい。もちろん、データ変換の性質は、システムのユーザごとに、ニーズに応じて異なってもよい。

このため、本発明の実施形態は、Ｍｉｃｒｏｓｏｆｔ（商標）ＡＺＵＲＥ（商標）技術などのクラウドプラットフォームに基づいてもよく、具体的にはＩｏＴハブ、サービスファブリック、ＡＰＩゲートウェイ、ストリーム分析及び機械学習の使用に基づいてもよい。本ソリューションは、多面的なセキュリティを使用して、具体的にはストリーム分析、機械学習、ディープラーニングを使用して構築され、ユーザとシステムの動作をプロファイルして、異常の特定及び適応を行う。

本発明の一態様によれば、１つ以上の更なる装置（１０８）へのユーザアクセスを提供するためのデータ処理システム又は装置が提供される。本装置は、ユーザログインイベントに関連付けられたロケーション識別子を判定し、ロケーション識別子を、好ましくはユーザログインイベントに関連付けられた、ユーザセッション識別子に関連付け、そして、ロケーション識別子及び関連付けられたユーザセッション識別子をアプリケーション（３０１）に通信する（３０１３）ように構成された処理手段（１０３）を含む。

本発明の更なる態様によれば、１つ以上の電子装置へのアクセスを提供する方法が提供される。本方法は、ａ）ユーザログインイベントに関連付けられたロケーション識別子を判定するステップと、ｂ）ロケーション識別子をユーザセッション識別子に関連付けるステップと、そして、ｃ）ロケーション識別子及び関連付けられたユーザセッション識別子をアプリケーション（１０９）に通信する（３０１３）ステップと、を含む。

本発明の実施形態は、添付の図面を参照して、一例として説明する。
図１は、本発明を実施する主要な機能コンポーネントの概略図である。 図２は、本発明の一実施形態のシステムアーキテクチャを示す概略図である。 図３は、本発明の実施形態に係る様々な異なる機能コンポーネントのシーケンスフローを示すフロー図である。

以下の説明は、航空産業で使用されるシステムについてのものであるが、これは例示的なものであり、本発明の他の用途についても説明する。例えば、システムは、インフラストラクチャが共有されている任意の環境で使用されてもよい。システムは、予約システム又は出発制御システムなどの外部システムと通信するためにＡＰＩ通信プロトコルを使用することができるホストされたシステムで用いられてもよい。

この特定の実施形態では、アプリケーションプログラミングインターフェース（ＡＰＩ）サービス又はモジュールは、Ｍｉｃｒｏｓｏｆｔ ＡＺＵＲＥプラットフォーム上に構築される。ただし、アマゾンウェブサービス（ＡＷＳ）、クラウドプラットフォーム、ＩＢＭクラウドプラットフォーム、Ｇｏｏｇｌｅクラウドプラットフォームなど、当業者に知られている他のプラットフォームが使用されてもよい。

更に、機能は、任意のプログラミング言語で実装されていてもよく、例えば、ｈｔｍｌ５、Ｃ＋＋（商標）、ＪＡＶＡ（商標）、及び．ｘｍｌが、当業者に知られている他のプログラミング言語と同様に使用されてもよいことは理解されよう。例えば、本発明の実施形態は、これらのプログラミング言語の１つを使用して、Ｗｅｂベースのサービスを提供してもよい。

図１を参照すると、これは、本発明を具現化するシステムのアーキテクチャを示す概略図と考えることができる。このシステムは、次世代プロトコル（ＮＧＰ）システムの一部として提供されていてもよい。

この特定の実施形態では、システムは、ＡＰＩ環境１０３、アプリケーション環境１０９、及び空港環境１０５の、３つの異なるゾーンを含む。

通常、これらのゾーンの１つ以上は異なる物理的なロケーションにある。例えば、ＡＰＩ環境１０３は、米国のカリフォルニアなどの特定の州に物理的に配置され、ローカル空港環境１０５は、例えば米国のボヘミアに配置されていてもよい。１つ以上のアプリケーション１４１、１４３、１４５をホストする、特定の航空会社アプリケーション環境１０９も米国にあってもよい。アプリケーション環境は、例えば、ドイツなど、異なるリージョン、ロケーション、又は国でホストされ得る、出発制御システムに通信可能に結合されていてもよい。

他の特定の例では、ＡＰＩ環境１０３は、オランダに物理的に配置され、１つ以上のユーザ装置１０７及び装置上で実行される関連付けられたＧＵＩは、ドイツのフランクフルトに配置され、１つ以上の共有装置１０８は、アメリカのボヘミアに配置されていてもよい。アプリケーション環境及び関連付けられたアプリケーション１４１、１４３、１４５も米国に配置されていてもよく、一方で、出発制御システム又は他のバックエンドシステム１０２がドイツに配置されていてもよい。

＜ユーザ装置１０７、共有装置１０８、ローカル及びリモート環境の説明＞

通常、空港環境は、１つ以上のコンピューティング装置１０７、１０８を備えている。これらのコンピューティング装置は２つのグループに分割されてもよい。コンピューティング装置１０７の第１のグループは、航空会社の職員がチェックイン又は搭乗機能などの１つ以上の機能を実行するために空港に持ち込み得る、共有ワークステーション又はタブレットのいずれか１つ以上を含んでいてもよい。コンピューティング装置の第１のグループは、乗客が、搭乗券又は手荷物タグを印刷し、或いは超過重量の手荷物の費用の支払いを実行する等のために空港環境に持ち込み得る、スマートフォン又はタブレット又はその他の任意のコンピューティング装置を含んでいてもよい。これらのコンピューティング装置は、ユーザ装置１０７と呼ばれる。本質的に、これらのコンピューティング装置１０７は、コンピューティング装置１０８の第２のグループ等の、共有インフラストラクチャへのアクセスを提供する。

コンピューティング装置１０８の第２のグループは、プリンタ又はスキャナ又はリーダー、チェックインカウンター装置、搭乗カウンター装置、キオスク（搭乗券又は手荷物タグを印刷するためのキオスクなど）、手荷物ドロップカウンター装置、セキュリティスクリーニング装置、又はセルフ搭乗ゲート装置のいずれか１つ以上を含んでいてもよい。言い換えれば、コンピューティング装置１０８の第２のグループは、共有インフラストラクチャコンピューティング装置に関連する。スキャナ又はリーダーは、通常、搭乗券又は手荷物タグ、パスポート又は身分証明書又はその他の機械が可読なドキュメントを読み取るように構成されている。これは、通常、当業者に知られている、光学式文字認識（ＯＣＲ）アルゴリズムを使用した搭乗券又は手荷物タグの光学スキャンを使用して実行される。

図１は、一例として空港環境を示しているが、もちろん、このゾーン１０５は、共有インフラストラクチャが提供され得る、鉄道駅、ホテル、コンベンションセンタ、クルーズ船などの、任意の環境であってもよいことは理解されよう。このゾーン１０５は、ローカル環境１０５と呼ばれる。

アプリケーション環境１０９は、通常、リモートゾーン１０９と呼ばれる。アプリケーション環境は、例えば航空会社によって使用される、データセンタ又は１つ以上のコンピュータサーバを含んでいてもよい。更に、アプリケーション環境機能は、ホスト環境で提供されていてもよい。

＜主な機能コンポーネントの説明＞

システム１００は、１つ以上のサービスを提供するための１つ以上のモジュール又はインターフェース１１１である、機能コンポーネントのうちのいずれか１つ以上を備えてもよい。モジュールは、通常、それぞれ１つ以上のアプリケーション１４１、１４３、１４５に通信可能に結合されている。更に、モジュール又はインターフェースのそれぞれは、１つ以上の装置１０８に通信可能に結合されていてもよい。ＡＰＩ環境１０３内の機能コンポーネントのいずれかが、１つ以上の異なる機能動作を実行するためのモジュールとして、参照され得る。

例えば、サーバ又はコンピュータ１０１は、アプリケーションプログラミングインターフェース（ＡＰＩ）を、ＡＰＩ環境１０３で実行するように構成されていてもよい。コンピュータサーバは、通常、当業者に知られている有線又は無線の伝送手段を介して、図面の図１、図２、及び図３に示す、１つ以上の異なる機能コンポーネントに通信可能に結合されている。

アプリケーション環境１０９及び空港環境１０５は、サードパーティによって提供されていてもよく、これらの環境１０５及び１０９のそれぞれは、通常、公開されたインターフェースを介して、１つ以上のＡＰＩサービスに通信可能に結合されている。前述のとおり、アプリケーション環境１０９は、通常、１つ以上のコンピュータ又はコンピュータサーバ上に構築されている。

通常、ローカル環境１０５は、当業者に知られている有線又は無線の通信プロトコルを介して、ＡＰＩ環境１０３に通信可能に結合されている。同様に、リモート環境１０９は、通常、当業者に知られている有線又は無線の通信プロトコルを介して、ＡＰＩ環境１０３に通信可能に結合されている。

＜データベース１０４及びビーコン１１０の説明＞

図面の図１に示されるように、データベース１０４は、システムの一部として提供されていてもよい。通常、データベースに関連付けられたデータは、リードオンリーメモリ又はランダムアクセスメモリなどのストレージ手段又はメモリに保存される。しかしながら、データベースがＡＰＩ環境内にあることは必須ではない。例えば、データベースは、ＡＰＩ Ａｚｕｒｅ環境に通信可能に結合されていれば、任意のロケーションで提供されていてもよい。データベースは、通常、ＡＰＩ１０６によって検索される。データベースは、通常、ＵＵＩＤなどの１つ以上の異なるビーコン識別子及び１つ以上の異なるロケーション識別子（ＩＤ）を含む。各ビーコン識別子と各ロケーション識別子との間の関連付けが提供され、データベース、その構造、及び図１に示される他の機能コンポーネントとのやり取りは、以下で更に詳しく説明される。

システムは、通常、１つ以上のビーコン１１０を更に備えている。各ビーコンは、通常、空港環境で使用され得るユーザ装置１０７の任意の１つ以上に近接して配置されている。明確化のために、図１では、１つのビーコン１１０が示されている。しかしながら、通常、複数のビーコンが異なるロケーションに提供される。各ビーコンは、通常、１つの共有インフラストラクチャ１０８に関連付けられる。

複数の共有装置１０８が特定のロケーションに提供されていてもよい。各共有装置は、通常、装置識別子などの一意の識別子を有する。装置識別子は、通常、英数字文字列の形式である。装置識別子の特定の例は次のとおりである。
装置識別子：「４１３ｄｃ６ｃ０ａ０３ｄ４ｄ６ａ９ｃｄ２ｃ１＝＝」。

更に、特定のロケーションにある複数の共有装置１０８の異なる機能を区別するために、各共有装置１０８は、関連付けられた装置タイプ又は一般的な装置ラベル定義を持っていてもよい。

例えば、ＬＳＲの装置タイプは、搭乗券又は手荷物タグのスキャンに使用されるバーコードスキャナを示していてもよい。ＭＳＲの装置タイプ又はラベルは、装置がクレジットカード又はポイントカードの読み取りに使用される磁気スワイプリーダーであることを示していてもよい。他の装置タイプ又はラベルは、装置が搭乗券プリンタであることを示すＡＴＰ（自動チケット及び搭乗プリンタ）のように、手荷物タグプリンタ又は搭乗券プリンタであることを示す、ＢＴＰであってもよい。装置タイプとロケーション識別子の組み合わせにより、特定の装置を空港の特定のリージョンで一意に識別することができる。

＜ユーザセッション識別データと認証サービスの説明１１４＞

認証サービスモジュール１１４がＡＰＩ環境１０３に提供されていてもよい。これにより、ユーザはシステムに加入することができ、ユーザログイン及びパスワードを用いて、システムへの後続のアクセスも提供される。

ユーザがログインすると、ログインイベントが作成される。これにより、ロケーション識別子（ＩＤ）及びユーザセッション識別子（ＩＤ）が生成される。ロケーション識別子は、異なるユーザに関連付けられた、以前に保存されたロケーション識別子のデータベース（１１２）を検索することにより判定されてもよい。ロケーション識別子は、データベース（１１２）に保存されたユーザログインとのマッチング及びユーザログインと関連付けられたロケーション識別子とのマッチングに基づいて、選択されてもよい。ユーザがログオンしているロケーション（例えば、経度又は緯度の座標、国、州、又はリージョン）などの追加情報を使用して、データベース（１１２）からユーザのロケーション識別子を一意に判定することもできる。

＜公開されたインターフェースの説明＞

図面の図１に示された、１つ以上のインターフェース又は機能的コンポーネントは、公開され又はＡＰＩ環境１０３外部のサードパーティに利用可能にされるインターフェースであってもよい。例えば、構成ポータル１１５、Ｗｅｂプロキシサービス１１３、及びＡＰＩサービス１１１及び特定の装置サービスインターフェース１１７は、公開されたインターフェースと考えることができる。公開されたインターフェースには、２つの明確な役割がある。

まず、ＡＰＩ又はサービス１１１は、リモート環境１０９で実行される１つ以上のアプリケーション１４１、１４３、１４５と、ローカル空港環境で実行される１つ以上の装置１０７、１０８との間のデータ交換を提供する。

次に、特定の装置機能とエンドユーザエクスペリエンスに関連付けられた詳細は、図１に示される構成ポータル１１５を介して提供される。構成ポータル１１５は、ＡＰＩデータを、装置サービスインターフェース１１７を空港環境の１つ以上の共有装置１０８と組み合わせる、装置インターフェースとシームレスに結合する。これにより、システムは、装置１０８の全機能を利用できるようになる。各共有装置１０８に関連付けられた、構成ポータル１１５及び関連付けられた構成設定は、以下で更に詳細に説明される。

＜ＡＰＩ１１１の機能説明：通知及びルーティング機能＞

ＡＰＩ環境で提供される１つ以上のＡＰＩ１１１は、２つの主要な機能を有していてもよい。まず、それらは、リモートアプリケーション環境１０９の１つ以上のアプリケーション１４１、１４３、１４５からのメッセージ１２１、１２２の受信に応答して、通知メッセージを送信する。次に、それらは、装置サービスＡＰＩインターフェース１１７内の正しい装置サービスにメッセージをルーティングする機能を備えている。通常、これは多くの異なる装置サービスが装置サービスインターフェース１１７内で提供されるために必要とされる。例えば、装置サービスインターフェース１１７内のサービスは、搭乗券の印刷又は手荷物タグの印刷、搭乗券又は手荷物タグのスキャン、又は磁気スワイプリーダーなどを使用したクレジットカード又はポイントカードの読み取りに関するものであってもよい。

したがって、ＡＰＩサービス１１１は、装置サービスインターフェース１１７内の正しいサービスにメッセージをルーティングする機能と、リモートアプリケーション環境のアプリケーション１４１、１４３、１４５からの要求がＡＰＩサービス１１１によって正しく受信されたことを通知する通知メッセージを送信する機能との両方を実行してもよい。

＜ＣＵＴＥラッパーＡＰＩ３０１＞

図面の図３に示されるＡＰＩ３０１も、ＡＰＩ環境１０３に提供され、配置されていてもよい。これは、ＣＵＴＥラッパーＡＰＩと呼ばれる。アプリケーション３０１の機能の１つは、使用される異なるプロトコル間の変換を行うことである。更に、アプリケーション３０１は、ＡＰＩ環境１０３とリモートアプリケーション環境１０９との間でコマンドを変換することもできる。更に、ＡＰＩは、リモートアプリケーション環境から受信したメッセージ１２２が正規のユーザに関連付けられていることを確認するための認証機能を実行する。ＣＵＴＥラッパーＡＰＩは、従来の航空会社アプリケーションをＮＧＰシステムに統合して使用する場合に特に役立つ。しかしながら、これはもちろんオプションであり、航空会社アプリケーションは、ＣＵＴＥラッパーＡＰＩ３０１からの要求内で、ＮＧＰシステムからメッセージを直接受信するように構成されていてもよい。

＜機能コンポーネント間のデータ交換の説明＞

図１では、異なる機能コンポーネント間のデータ交換は、１２１、１２２、１２３、１２４、１２５、１２６、１２７、１２８、及び１２９のラベルが付いた矢印で示されている。もちろん、明確性の観点から、異なる機能コンポーネント間の通信のすべては表示していない。しかしながら、これらの詳細は、以下で詳しく説明される。

ある特定の例では、ＡＰＩサービス１１１と、図１に示されるリモートアプリケーション環境の、通常は関連付けられている、それぞれのアプリケーション１４１、１４３との間のメッセージング１２１、１２２は、Ｊａｖａ Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｊｏｔａｔｉｏｎ、ＪＳＯＮ（商標）ｘｍｌメッセージを使用して実装されてもよい。これは、Ｊａｖａ（商標） Ｓｃｒｉｐｔプログラミング言語に基づいたデータ交換形式である。これらは、以下に添付された図面の図３を参照して、更に詳細に説明される。もちろん、当業者に知られている他のメッセージングプロトコルが使用されてもよい。

＜ビーコンの配置及び機能の詳細な説明＞

前述のとおり、ビーコン１１０は、通常、ユーザ装置１０７の１つが使用され得るロケーションに近接して配置されている。あるいは、１次元バーコード、クイックレスポンス（ＱＲ）コード、又は２次元バーコードなどの、マトリックスバーコードを使用されてもよい。この場合、ロケーション識別子は、ＱＲコード内又は２次元バーコード内に符号化される。これらのコードにより、情報をコード内に符号化することができる。これは、以下で更に詳しく説明される。

ビーコン識別子の値は、各ビーコンに関連付けられてもよい。これは、ビーコン管理ツールなどの支援アプリケーションで設定されていてもよい。ユーザ装置１０７は、ブルートゥースなどの無線信号を使用して、ビーコン１１０と通信することができる。

通常、ユーザ装置１０７のそれぞれは、共有インフラストラクチャへのアクセスを許可するためのアプリケーションを備える。このアプリケーションは、例えばＡＰＩの形態であるが、ユーザ、航空会社の職員又は乗客によって、共有インフラストラクチャ１０８に近づいたときに実行されてもよい。

アプリケーションは、通常、ブルートゥースなどの無線通信プロトコルによって１つ以上のビーコン１１０を検出するように構成されている。アプリケーションがビーコンのＵＵＩＤを検出すると、これはＡＰＩ環境１０３に送信される。

ビーコン識別子又はＵＵＩＤデータは、例えば３２桁の英数字コードであってもよい。コードは、例えば、ビーコンに関連付けられている、１ＡＥ１８Ｃ１Ｃ−６Ｃ７Ｂ−４ＡＥＤ−Ｂ１６６−４４６２６３４ＤＡ８５５の形式であってもよい。ＡＰＩは、ｍａｊｏｒＩｄ＝１４、ｍｉｎｏｒＩｄ＝２の１つ以上を返してもよい。他の特定の例では、ＡＰＩ１０６は、ＵＵＩＤ＝１１４Ａ４ＤＤ８−５Ｂ２Ｆ−４８００−Ａ０７９−ＢＤＣＢ２１３９２ＢＥ９、ｍａｊｏｒＩｄ＝１１００、ｍｉｎｏｒＩｄ＝１２９２の１つ以上を返してもよい。ｍａｊｏｒＩｄとｍｉｎｏｒＩｄを使用して、共通のＵＵＩＤを持つ特定のエリアのビーコンを区別してもよい。ＡＰＩ１０６は、１つ以上のビーコンに関連付けられたデータを返してもよい。

＜ロケーション識別子にマッピングされた、データベース１０４に保存されたＵＵＩＤの説明＞

ＡＰＩ環境１０３内で、ビーコン１１０の識別子からロケーション識別子（ＩＤ）へのマッピングをサービスとして実行されてもよい。したがって、初期構成プロセスの一部として、ビーコン識別子とロケーション識別子がＡＰＩ環境に受け渡される。ロケーション識別子は、「ＪＦＫＴ５ＣＫ０１」などの英数字文字列の形式であってもよく、これは、ビーコン、つまりユーザ装置１０８が、ジョンＦケネディ空港のターミナル５のチェックインデスク０１にあることを示している。

各ビーコン識別子とロケーション識別子の間のマッピングが実行され、関連付け又はマッピングがデータベースに保存される。

したがって、データベースは、少なくとも１つの、ロケーション識別子に関連付けられたビーコン識別子を含む。これにより、ビーコン識別子とユーザ装置１０７との間にリンクが作成され得る。

データベースには、ローカルの空港環境マップが含まれていてもよい。これにより、ビーコン１１０、ならびに各ビーコン１１０の近くにある関連付けられたユーザ装置１０７の、物理的ロケーションの視覚的表現が可能になる。

特定の一実施形態では、データベース１０４は、空港のマップと、マップ内のビーコン及び関連付けられた共有装置１０８のロケーションを定義するデータを含んでいてもよい。

＜ロケーション識別子の詳細説明＞

前述のとおり、ロケーション識別子（ＩＤ）は、図１に示された装置通信チャネル１２４とＧＵＩ通信チャネル１２５との間の関連付け又はリンクと考えることができる。

更に、通信チャネル１２４と、通信チャネル１２５と、リモートアプリケーション環境１０９で実行されるアプリケーション１４１、１４３、１４５のうちの１つとの間の、いくつかの異なる関連付けが提供されていてもよい。これにより、ユーザは複数のロケーションを使用できる。

前述したように、ロケーションは、ビーコン、ＮＦＣ、又はラベルを使用して判定されてもよい。ロケーション識別子（ＩＤ）は、バックエンドサービスによって解析されてもよい。

以下の説明では、ロケーション識別子（ＩＤ）コンセプトの詳細に焦点を当てている。ロケーション識別子は、次の例のいずれかの１つの形式に従ってもよい。
１． ＢＯＨ−ＰＲＥＰＲＯＤ−Ｔ０１−ＧＡＴＥ０１−ＷＫＳ−００１
２． ＪＦＫ−Ｔ０１−ＧＡＴＥ０３−ＷＫＳ−００２
３． ＭＩＡ−ＡＤＭ−ＦＬＲ１−ＣＯＮＦ１−ＷＫＳ−００１
例１
本例では、空港＝ＢＯＨ、エリア＝プリプロダクション、ターミナル＝１、ゲート＝１、ワークステーション＝１である。
例２
本例では、空港＝ＪＦＫ、ターミナル＝１、ゲート＝０３、ワークステーション＝２である。
例３
本例では、空港＝ＭＩＡ、エリア＝管制、フロア＝１、会議室＝１、ワークステーション＝００１である。

これらの例は、相対的なロケーション、又は１つ以上の所定のエリア内の任意のロケーションを定義する。ロケーション識別子は、２次元又は３次元空間内のエリア、リージョン、又はボリュームを定義してもよい。２次元又は３次元空間は、各エリア又は空間に関連付けられた１つ以上のｘ、ｙ又はｚ座標によって定義されてもよい。各エリア又は空間を定義する座標は、各エリア又は空間を定義する関連付けられたロケーション識別子とともに、データベース１１２などのデータベースに保存されてもよい。

前述の例では、ロケーション識別子は異なるリージョンを定義する。通常、異なるリージョンの少なくともいくつかは、互いに重なってもよく、或いは他のリージョン内に完全に含まれていてもよい。したがって、空港はリージョン１と見なされ、管制エリアはサブリージョン２と見なされ、会議室はサブリージョン２のサブリージョン３と見なされる。サブリージョン３はサブリージョン２に完全に含まれていてもよい。同様に、サブリージョン２は、サブリージョン１に完全に含まれていてもよい。

ロケーション識別子は、階層の一部としてワークステーションなどの特定の装置１０７のロケーションを定義していてもよい。特定の例では、実際のワークステーションは、キオスク又はこれらの１つ以上の手荷物ドロップワークステーションであってもよい。
この階層構造は、非常に柔軟で、人間が可読なテキスト形式で提供される。
更に、リージョンの頭字語のデータベース及び関連付けられたそれらの頭字語の説明が提供されていてもよい。

ロケーション識別子が単一の原点を基準にロケーションを定義しないことは理解されよう。これは、すべてのロケーションが単一の原点を基準に定義されている経度及び緯度座標系などの座標系とは対照的である。むしろ、各ロケーション識別子は、所定のロケーションに関連付けられている。各所定のロケーションに関連付けられたロケーションを定義する階層ツリーが提供される。これには、頭字語のデータベースを参照する必要なく、ロケーション識別子が当業者によって解釈され、階層構造が理解されるという利点がある。これにより、階層構造を必要に応じて簡単に拡張できる。

例えば、キオスクのチェックがニューヨークのタイムズスクエアに配備されているとする。
ロケーション識別子は、ＮＹＣ−ＴＳＱ−・・・・・で定義されてもよい。

ロケーション識別子は、異なる機能コンポーネント間でテキスト文字列として通信されてもよい。

文字列は検索され得る。ロケーション識別子の論理構造は、通常、ツリーが作成されたときにのみ走査される。ツリーは、ワークステーションのＧＵＩを使用して表示され得る。ＧＵＩは、ロケーション識別子がネスト構造をどのように定義しているかを示す。

このため、ロケーション識別子は、通常、ＪＦＫ、ＬＧＡ、ＬＡＸなどのロケーションを指定するＩＡＴＡ定義コード、又はＮＹＣなどのロケーションのよく知られている略語で始まる。

階層が構築されると、各ステップがロケーション識別子（ＩＤ）に追加され、人間が読みやすく理解しやすくされる。これにより、ワークステーションの物理的なロケーションが非常に正確に表示される。ワークステーションが実際に配置されている十分な精度で、ロケーション識別子が定義されている場合、マーカーが追加され得る。マーカーはＷＫＳマーカーと呼ばれ、ワークステーション番号を定義する識別子が追加され得る。このスキームは、世界のほぼすべてのロケーションを表すために使用されることができる。

＜異なるタイプの共有装置１０８を区別するための装置タイプ又は汎用装置ラベルの説明＞

ロケーションＩＤが複数の共有装置１０８に関連付けられている場合、前述の装置タイプを使用して、特定のロケーションの異なる装置を区別することができる。あるいは、一意の装置識別子を使用して、異なる共有装置１０８を区別してもよい。

これは、共有装置１０８のうちの１つを特定のロケーション識別子と装置タイプラベルに関連付けることによって行われ得る。装置タイプラベルの例は、前述のＡＴＰ、ＢＴＰ、ＬＳＲ、ＭＳＲである。

したがって、例えば手荷物タグプリンタ又は手荷物タグスキャナなどの各装置１０８は、そのロケーション識別子及び装置タイプラベルによって識別され得る。前述のとおり、ラベルは通常汎用的なものであるが、ロケーション識別子とラベルとの組み合わせにより、特定のロケーションにある複数の異なる共有装置１０８から１つの装置を識別する方法が提供される。

特定のメッセージがどの共有装置１０８に送信されるかを一意に判定する特定の方法は、２つの異なる方法で実行され得る。

第１のオプションとして、共有装置１０８は、ロケーション識別子と、ＡＴＰ、ＢＴＰ、ＬＳＲなどの装置タイプラベルとに基づいて、一意に判定されてもよい。

第２のオプションとして、共有装置１０８は、ロケーション識別子ＪＦＫＴ５ＣＫ０１及びラベルＡＴＰにマッピングされるビーコンＵＵＩＤを使用して、一意に識別される。これは、共有装置１０８のロケーションがユーザ装置１０７のロケーションと同じ又は類似していることを意味する。ビーコンＵＵＩＤなどのビーコン識別子は、共有装置識別子又はラベルとロケーション識別子との間のリンク又は関連付けを提供する。

図面の図２は、アダプタ２０１が提供される特定の実施形態の概略図を示している。このアダプタは、クラウド２０３ＩｏＴハブに直接接続できない空港１０７の現在の装置のために提供されている。したがって、アダプタサービスを使用して、従来の装置をＩｏＴ装置として機能させることができる。このアダプタと装置インターフェースが公開されることにより、装置ベンダが、ＩｏＴにネイティブサポートした装置を開発できる。図２に示されるアダプタ２０１は、図面の図１に示されるフィールドゲートウェイ（ＦＧ）とも呼ばれ得る。

ロケーションＩＤは、接続されているワークステーション又はＩＴレイアウトの知識がなくても、装置のロケーションを、チェックインデスク、ホテルのロビーなどの論理的な配置に抽象化する。ロケーション識別子は、以下で更に詳しく説明される。

装置から航空会社／空港アプリケーションへ、及び航空会社／空港アプリケーションから装置へのメッセージルーティングは、独自の内部ルーティングメカニズムとＡｚｕｒｅルーティングメカニズムによって処理される。ルーティングメカニズムは、本発明の実施形態のシーケンスフロー図を示す図面の図３を参照して、以下で更に詳細に説明される。

ＩｏＴアダプタ、ロケーション抽象化及び機能サービスは、クラウドアプリケーション内の装置ハードウェア、機能、及びメッセージルーティングの複雑さを制限しながら、グローバル規模で装置を管理及び操作するための独特のソリューションを提供する。

＜装置サービスインターフェースＡＰＩ１１７の詳細な説明＞

装置サービスインターフェースＡＰＩ１１７が、ＡＰＩサービス内で提供され得る。

装置サービスインターフェースＡＰＩ１２７は、任意の１つ以上の共有装置１０８とのインターフェースを提供する。これにより、任意の１つ以上の共有ローカル装置が実行できるサービスが、リストアップされ、ユーザ装置１０７の任意の１つにより使用可能となる。

例えば、共有装置１０８がネットワーク化されたワークステーションに単に結合されたプリンタであると仮定する。装置サービスＡＰＩ１１７は、装置が印刷を実行できることを示す。

印刷の性質に関する詳細は、装置サービスＡＰＩによって提供されていてもよい。例えば、プリンタが乗客の荷物に取り付けられる手荷物タグを印刷できることが示されていてもよい。同様に、装置サービスＡＰＩは、プリンタが搭乗券を特定の形式又はサイズで印刷できること、又は特定のスタイルシート又はテーブルに従って印刷できることを示してもよい。例えば、搭乗券プリンタは、ＰＥＣＴＡＢ印刷言語を使用して搭乗券を印刷してもよい。この場合、搭乗券に印刷されるデータは、１つ以上のテーブルに従ってフォーマットされる。

いずれにしても、構成ポータル１１５は、装置サービスインターフェース１１７に通信可能に結合されている。これは、図１において１２８とラベル付けされた矢印で概略的に示されている。構成ポータル１１５は、機能サービスインターフェースとも通信可能に結合されている。

＜ワークステーション及び関連付けられた周辺機器の構成＞

図３のシーケンスフロー図を詳細に説明する前に、ワークステーション及び手荷物タグプリンタ又は搭乗券プリンタなどの関連付けられた周辺機器のオプションの構成について説明する。

ワークステーションに接続された周辺機器を備えるワークステーションは、次の手順を使用して配備されてもよい。これは、ワークステーションが例えばＷｉｎｄｏｗｓ１０で実行されており、必要な装置ドライバーがイメージにプリロードされていることを前提としている。

ステップ３０１０において、ワークステーション又はポータブル装置が起動した後、インストールエンジニアはブラウザを起動し、ＮＧＰのＵＲＬを入力してＮＧＰポータルに接続する。インストーラは、通常、インストールプロセスを開始するためにセキュリティ資格情報の入力を要求される。ＮＧＰのポータルは、周辺機器を接続して設定するようにインストーラを導くために、直感的なＧＵＩを提供する。このプロセスは、ステップ３０１１においてインストーラによって提供されたロケーションＩＤに基づいて、ワークステーションに必要なすべてのソフトウェアを自動的にインストール及び構成する。通常、ＮＧＰインストールポータルＧＵＩでは、インストーラが、インストールが成功したことを検証するために、すべての周辺機器をテストする。周辺機器は、原則として、搭乗券プリンタ又は手荷物タグプリンタなどの任意の共有装置１０８であってもよい。

次に、ユーザは、ユーザ装置１０７で実行されているブラウザに特定のＵＲＬを入力して、ＮＧＰシステムにアクセスする。通常、各航空会社は、システムにアクセスするための異なるＵＲＬを有する。

次に、図面の図１及び図３を参照して、メッセージングシーケンスフローについて説明する。ステップの特定の順序は例示的なものであり、ステップは図３に示すものとは異なる順序で実行され得ることは理解されよう。

以下の説明では、ユーザが事前にＮＧＰシステムでアカウントを作成し、システムにアクセスするためのユーザ名及びパスワードを、ユーザがシステムに保存していることを前提としている。更に、装置１０７は、ブラウザで、ＡＰＩ環境へのアクセスを提供するＮＧＰポータルに接続することができる。通常、ＡＰＩ環境１０３という用語は、ＮＧＰポータル又はシステムという用語と交換可能に使用される。また、手荷物タグプリンタ及び搭乗券プリンタなどの１つ以上の周辺機器が前述のとおり構成されているものとする。

＜ポータブル装置ソリューション＞

いくつかの例では、航空会社の職員は、タブレットなどのポータブルコンピューティング装置を空港カウンター、キオスク、又は手荷物ドロップのロケーションに持ち込んで、例えばチェックイン又は搭乗券発行機能を実行し得る。同様に、スマートフォン／タブレットを使用する乗客は、キオスク又は他のロケーションに近づいて搭乗券、手荷物タグを印刷し、自分の装置から直接支払いを行うことができる。乗客は、通常、特定の航空会社アプリケーションを実行してこれらの機能を実行する。これにより、乗客は空港でシームレスな体験をすることができる。

前述のとおり、ビーコンは、例えばＮＦＣ技術を使用して、装置１０７を、カウンター及びキオスク内及び手荷物ドロップの共有装置１０８と関連付けることができる。

特定のビーコンと、共有コンピューティング装置、つまり共有コンピューティング装置１０８に関連付けられたロケーション識別子（ＩＤ）との関連付けは、前述のとおりである。

ロケーション識別子（ＩＤ）は、又は２つのチャネル１２４、１２５をリンクし、或いは関連付ける。これにより、ローカル空港環境１０７のどのプリンタとリモート環境のアプリケーション１４１、１４３、１４５が通信する必要があるのかがプラットフォームに通知される。

ユーザがタブレット又は他の装置１０７からログインすると、所定のロケーション識別子がＡＰＩ環境１０３に送信される。あるいは、ユーザがログインするとき、ユーザは自分のロケーションを手動で選択してもよい。前述のように、ロケーションは、ビーコン又は近距離無線通信（ＮＦＣ）、又はＱＲラベルを使用して、特定されてもよい。このようにして、航空会社の職員は、自分のタブレットを持ち込み、空港のカウンター、キオスク、手荷物ドロップ及び他のロケーションに簡単にアクセスして、チェックイン及び搭乗の機能を実行し得る。

タブレットは、例えばビーコン又はＮＦＣを使用して、カウンターの（例えば、キオスク又は手荷物ドロップの）装置の１つに関連付けられてもよい。これにより、装置はロケーション識別子（ＩＤ）を受信し、ポータブル装置がロケーション識別子をＡＰＩ環境１０３に渡すことができる。

したがって、ユーザは、ポータブルコンピューティング装置１０７をローカル空港環境１０５に持ち込んで、ＡＰＩ環境１０３にアクセスすることができる。

ユーザは、装置１０７でアプリケーションを起動し、それがＮＦＣなどの無線通信プロトコルを使用してユーザの近くにあるビーコン１１０を検出し、ＵＵＩＤなどのビーコン識別子を検出する。

ユーザ装置１０７で実行されているアプリケーションは、ＡＰＩ環境にある検索ＡＰＩ１０６への要求を無線で送信してもよい。要求はＵＵＩＤを含み、そして、要求は、ユーザ装置１０７で実行されているＡＰＩによって検出されたビーコン識別子と一致するデータベースに保存されているビーコン識別子をデータベース１０４で検索するようＡＰＩ１０６に指示するコマンドを含む。

ＡＰＩ１０７が、検出されたビーコンに関連付けられたＵＵＩＤ識別子とデータベースに保存されたビーコン識別子との間の一致を判定すると、ＡＰＩ１０６は、ロケーションデータ、すなわちデータベースに保存された一致するビーコン識別子に関連付けられたロケーション識別子（ＩＤ）をデータベースで検索する。ロケーション識別子（ＩＤ）の特定の形式は、以下で更に詳しく説明される。

＜固定カウンタソリューション＞

ポータブル装置ソリューションの代替として、ユーザは、図１で１０７のラベルが付けられた、ワークステーションを使用して、ＡＰＩ環境にアクセスしてもよい。これは、固定カウンタソリューションと呼ばれる。この例では、ロケーションＩＤは航空会社のバックエンドサービスに透過的に受け渡される。ユーザは、ロケーションＩＤを取得するためにアクションを実行する必要はない。

したがって、固定カウンタソリューションは、以下の手順を実行してもよい。
１．固定ロケーションのワークステーションがインストールされ、フィールドゲートウェイが配備されると、ワークステーションは識別子を付与される。通常、この識別子はロケーションＩＤである。
２．ユーザが、ＮＧＰシステムにログインして彼／彼女のアプリケーションにアクセスすると、ロケーションＩＤがログイン資格情報の一部として渡される。
３．ＮＧＰシステムは、ユーザに表示されるアプリケーションアイコンを使用してメニューを動的に構築してもよい。各アイコンは、バックエンド航空会社のアプリケーションサービス１４１、１４３、１４５に関連付けられたＵＲＬである。ＵＲＬは、ロケーションＩＤ、ユーザセッションＩＤ、及びＮＧＰのＵＲＬの、３つの関連付けられたパラメータを有する。

これらのパラメータは、航空会社のバックエンドアプリケーションサービス１４１、１４３、１４５が必要とするすべての情報を提供し、ユーザのログインに必要なロケーションに加入する。

＜詳細なシーケンスフローのステップ及びメッセージ＞

特に指定のない限り、図１及び３に示す様々な機能コンポーネントは、ＨＴＴＰプロトコルを使用したレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ＡＰＩ呼び出しなどのＡＰＩ呼び出しを使用して実装されてもよい。

したがって、図３に示されるメッセージ内のデータは、通常、英数字の文字列と、データのタイプを定義する関連付けられたフィールドとの形式であり、これも英数字文字列形式である場合がある。更に、ＡＰＩ環境１０３内及びアプリケーション環境１０９内に示されている異なる機能コンポーネントは、異なるモジュール間で必要に応じてデータを交換するために互いに結合された異なるモジュールとして実装されてもよい。

ここで再び図３のシーケンスフロー図を参照すると、ユーザはＮＧＰシステムにログインするために、ユーザ名又はユーザＩＤ及びパスワード（ユーザログイン）を入力するように要求される。そして、ユーザログインメッセージ３０１２は、ユーザ装置１０７からＡＰＩ環境１０３に送信される。ユーザログイン要求は、通常、前述のとおり、ブラウザに特定のＵＲＬを入力することに応答する。

ＮＧＰ ＡＰＩ環境がクラウドサービスの一部として提供されている場合、クラウドサービスプロバイダーが必要とする認証手順が使用されてもよい。通常、多くのユーザにシステムへのアクセスが提供され、ユーザのグループは、特定の航空会社などの特定の団体又は企業に属していると定義されてもよい。

特定のＵＲＬにアクセスするために、ユーザ装置にはセキュリティ証明書が提供されてもよい。セキュリティ証明書は、他のチャネルを介して提供されてもよく、そして、証明書はいつの時点で失効してもよい。ＮＧＰシステムへのアクセスは、通常、適切なセキュリティ証明書が提供されない限り、許可されない。

次に、認証サービス１１４は、ユーザが入力した資格情報に基づいてユーザを認証する。

ユーザのログイン後、構成ポータル１１５又は認証サービスアプリケーション１１４は、ユーザが、特定の航空会社に属するユーザなど、特定のユーザのグループに関連付けられているか否かを判断する。これは、航空会社識別子などの特定の会社又はグループ識別子に関連付けられた、ログオン資格情報のデータベース１１２を検索することにより実行され得る。

ユーザがポータブル装置を使用している場合、この段階でポータブル装置のロケーションが判定されてもよい。これは、前述のとおり、クライアントタブレット又は装置１０７で実行されるアプリケーションが、例えば近距離無線通信プロトコルを使用して、装置に関連付けられたスキャナ又はリーダーにビーコン識別子をスキャン又は読み取るように指示することで実行されてもよい。あるいは、モバイル装置にインストールされたアプリケーションが、ＱＲバーコードの読み取り又はスキャンを行う、カメラなどの読み取り手段と組み合わせて使用されてもよい。ビーコン又はＱＲバーコードは、通常、ユーザが共有インフラストラクチャを使用したい空港内の所定の位置に配置される。ＱＲバーコードの場合、バーコードは、その中に符号化されたロケーションＩＤを定義するデータを備えている。或いは、ユーザが、単に、入力を求められた場合にロケーション識別子を手入力で入力してもよい。

モバイル装置がビーコン識別子を読み取る場合、ビーコン識別子は、有線又は無線接続を介してユーザ装置１０７からＡＰＩ環境に送信される。次に、アプリケーション１０６は、データベース１０４を検索して、ビーコン１１０から読み取られたビーコン識別子に対応する又は一致するビーコン識別子を見つける。ＡＰＩ１０６は、次いで、ビーコンに一致するロケーション識別子に関連付けられたデータベース１０４に保存されたロケーション識別子を判定する。このようにして、ＡＰＩ１０６は、ビーコンに関連付けられたロケーション識別子を判定することができる。通常、図面の図１に示されているすべての機能コンポーネントは、必要に応じて、特定のビーコンＩＤに関連付けられたロケーション識別子（ＩＤ）にアクセスできる。次に、判定されたロケーションＩＤは、ユーザ装置１０７に送り返されてもよい。

したがって、ＮＧＰシステム、及び通常、アプリケーション環境で実行されるＡＰＩ１０６は、固定ワークステーションからロケーションＩＤを受信し、或いは、ＡＰＩ環境１０３内で実行されるＡＰＩ１０６は、特定のビーコン識別子に一致するロケーション識別子をデータベース１０４で検索することによりロケーションＩＤを判定する。これは、通常、ＡＰＩ１０６がユーザ装置１０７からビーコン識別子を受信することに応答する。

いずれの場合も、ロケーションＩＤと、共有インフラストラクチャ１０８にアクセスする特定のユーザ装置１０７との関連付けが行われる。ユーザ装置１０７は、関連付けられた識別子を有し得る。

ユーザがＡＰＩ環境１０３に正常にログインした後、ステップ３０１２において、ログインイベントメッセージ３０１３がＮＧＰポータル内の認証サービスインターフェース１１４からＣＵＴＥラッパーＡＰＩ３０１に送信される。通常、ログインイベントメッセージ３０１３は、ロケーションＩＤとユーザセッションＩＤと呼ばれるユーザセッション識別子の形式で、ユーザロケーションを一意に識別するデータを含む。ユーザセッションＩＤは、認証サービスＡＰＩ１１４によって生成され得る。当業者に知られているように、ユーザセッションＩＤは、ユーザセッションを識別する、英数字の文字列であってもよい。

ログインイベントメッセージは、オプションの航空会社ＩＤ又はユーザグループ識別子（ＩＤ）を含んでいてもよい。「ＵＳ」、「Ｅａｓｔ−ＵＳ」、「Ｗｅｓｔ−ＵＳ」、「Ｎｅｔｈｅｒｌａｎｄｓ」、「Ｉｒｅｌａｎｄ」、及び「Ａｓｉａ」などのリージョン識別子もまた使用されてもよい。これは、例えば、ＡＰＩ環境の複数の異なるインスタンスが、異なるロケーションで提供される必要がある場合に役立ち、これによって、グローバルソリューションが提供される。イベントメッセージ内のデータは、英数字の文字列形式であってもよい。

特定の一例では、ユーザセッションＩＤには、ユーザを定義するデータと、ユーザが関連付けられている関連付け又はグループとを定義するデータが組み込まれている。例えば、関連付けを定義するデータは、航空会社としてそれぞれ「ブリティッシュ・エアウェイズ（商標）」又は「アメリカン・エアライン（商標）」を定義し得る「ＢＡ」又は「ＡＡ」などの文字列であってもよい。例えばグラウンドハンドリング会社の組織などの、他の組織がユーザにリンクされていてもよい。通常、ＮＧＰシステムへのアクセスに使用されるＵＲＬは、ロケーションＩＤ、ユーザセッションＩＤ、及び航空会社ＩＤ間の接続のマッピング、関連付け、又は提供に使用される。

ステップ３０１４において、ユーザには、ログオン資格情報及び判定されたロケーションＩＤに基づいて、アプリケーションメニューと呼ばれるメニューが提供される。これは、（認証サービスＡＰＩ１１４などの）ユーザ装置１０７に呼び出しを送信するＡＰＩ環境１０３内のＡＰＩの１つによって行われてもよい。通常、アプリケーションメニューは、リモート航空会社のアプリケーション環境１０９のアプリケーション１４１、１４３、１４５の対応付けを示すＵＲＬ（英数字の文字列であってもよい）として提供される。したがって、メニューは、特定のローカル空港環境において、ユーザが、ユーザ装置を使用して、１つ以上の異なる機能を実行できる機能を提供する。ローカル空港環境１０５でユーザ装置を使用してユーザによって実行される機能の２つの特定の例は、１つ以上の共有装置１０８を使用した手荷物タグ又は搭乗券の印刷であってもよい。

したがって、ユーザは、ユーザ装置１０７の１つを使用して、メニューアイテムの１つをクリックすることができる。これにより、リモート航空会社環境のアプリケーションへの接続が可能になる。ＣＩＴＲＩＸ（商標）アプリケーションを使用してこのステップが実行されてもよく、他のアプリケーションを使用して、ローカル空港環境１０５の装置１０７の１つからアプリケーション１４１、１４３、１４５の１つがリモートで起動されてもよい。

アプリケーション１４１、１４３、１４５のうちの１つのリモート起動を可能にするアイテム及び機能のメニューを表示するステップは、ＡＰＩ環境１０３内のアプリケーションを使用して（例えば、ＡＰＩ１１１の１つを使用して）実行されてもよく、これはＮＧＰポータルアプリケーションと呼ばれ、特定のロケーションでユーザが利用できるアプリケーションのタイプを定義する、事前構成された設定を保存したデータベース１１２を検索する。このアプリケーションは、最初にユーザを認証し、その次に、特定のローカル環境１０５でクライアント装置１０７を使用してログオンするときに、ユーザに使用可能とされるべきアプリケーションを判定する。

したがって、ＮＧＰポータルアプリケーション１０３は、ロケーションに基づいて、このユーザに対して事前に構成されているアプリケーションを判定することができる。同様の方法で、航空会社は、ユーザＩＤ及びロケーションに基づいて、ユーザのアプリケーションを削除してもよい。

これは、ステップ３０１１において、例えば構成ポータル１１５を使用して、特定のロケーションのユーザ向けに、手荷物タグプリンタ又は搭乗券プリンタなどの、特定の装置を最初に構成する方法に類似している。これにより、ローカル空港環境内の特定の装置１０８が特定のユーザ用に構成され、それらのデバイス及びサービスが公開され得る。

航空会社は、構成ポータル１１５にログオンすることにより、特定のユーザが特定のロケーションで利用可能な所望のアプリケーション１４１、１４３、１４５を構成してもよい。構成ポータルＡＰＩ１１５に関連付けられたデータベース１１２は、ユーザＩＤで識別された特定のユーザが、その特定のロケーションでログオンするときに利用可能である、アプリケーションのタイプを定義する、設定を保存してもよい。例えば、ユーザは、ログオン時に利用可能になるように設定された、搭乗券を印刷し、或いは手荷物タグを印刷するアプリケーションを有してもよい。これは、ユーザＩＤ及びロケーションに基づいて、実行されてもよい。

したがって、例示的なアプリケーションは、職員又は乗客が搭乗券又は手荷物タグを印刷又は処理することを可能にする、搭乗券アプリケーション又は手荷物タグアプリケーションであってもよい。

アプリケーションメニューは、ユーザがリモートアプリケーション環境１０９（ＬＨアプリケーション）で利用可能なアプリケーション１４１、１４３、１４５の１つを選択することを可能にする。これは、図面の図３に示される、ＮＧＰ ＡＰＩシステム１０３とＣＵＴＥラッパーアプリケーション３０１との間の公開及び加入された通信により実行されてもよい。

通常、ＣＵＴＥラッパーアプリケーションは、リモートアプリケーション環境１０９に配置されている。ＣＵＴＥラッパークライアントアプリケーション３０１は、航空会社の従来のアプリケーション１３１、１３４、１４５とＡＰＩ環境内のアプリケーション１１１との間の仲介役として機能し得る。

アプリケーション３０１の機能の１つは、使用される異なるプロトコル間で変換することである。更に、アプリケーション３０１は、ＡＰＩ環境１０３とリモートアプリケーション環境１０９との間のコマンドを変換することもできる。したがって、ＣＵＴＥラッパーアプリケーション３０１は、リモートエアライン環境で使用されるアプリケーションタイプに応じてオプションとされてもよい。それにもかかわらず、ＮＧＰ ＡＰＩ環境１０３とリモート航空会社環境１０９のアプリケーションとの間で交換されるコアデータは、通常、ＣＵＴＥラッパーアプリケーションが使用されるか否かによらず同じである。

メニューに示されたアプリケーション１４１、１４３、１４５のいずれかのユーザによる選択に応答して、ユーザ装置１０７は、リモートアプリケーション環境１０９のアプリケーション１４１、１４３、１４５の１つと通信し、メッセージ３０１５を使用して、アプリケーション１４１、１４３、１４５の１つを開始させる。前述のように、ステップ３０１５は、リモート航空会社環境１０９のアプリケーションへのリンクを使用して実行される。したがって、リモート空港環境のアプリケーション１４１、１４３、１４５の１つは、クライアント又はユーザＩＤなどの、受信したメッセージ３０１５内の情報に基づいて起動される。

通常、リンク又はメッセージ３０１５は、ＵＲＬ以外の、関連付けられたパラメータの送信を許容しない。したがって、ステップ３０２０において、リモート航空会社環境１０９の特定のアプリケーション１４１、１４３、１４５がＵＲＬを使用して開始されると、リモート航空会社アプリケーションの１つは、通常、ローカルＣＩＴＲＩＸ環境へのローカル呼び出しをも実行して、特定のユーザセッションを開始した装置１０７を識別し得るクライアント識別子を判定する。

したがって、ＣＵＴＥラッパー機能が使用される場合、通常、以前に判定されたロケーションＩＤは、リモートアプリケーション環境内のアプリケーション１４１に送信されない。

更に、リモート環境１０９内のアプリケーション１４１、１４３、１４５のうちの１つが起動されると、アプリケーションインスタンスはポートフォワードを開始する。これにより、ローカルＣＩＴＲＩＸ環境がリモートアプリケーション環境で実行されているアプリケーション１４１にクライアント識別子を渡すため、アプリケーション１４１の１つがクライアントＩＤを受信することができる。これは、通常、ユーザ装置１０７がリモートアプリケーション環境１０９のアプリケーション又はＣＩＴＲＩＸインターフェースからそのような要求を受信することに応じて、ＣＩＴＲＩＸインターフェースを介してユーザ装置１０７からアプリケーション１４１に送信される。

例えば、クライアントＩＤは、特定のユーザを名前で識別し、リモートアプリケーション１４１、１４３、１４５を起動するために使用されている装置のタイプを識別する。したがって、クライアントＩＤは「ＮＡＭＥ＿ＴＡＢＬＥＴ＿１」の形式である。クライアント又はユーザ装置１０７は、例えば通信手段１２９により、クライアントＩＤを（通常はリモートアプリケーション環境内にある）ＣＩＴＲＩＸ環境に通信する。前述のユーザログインは、通常、特定のクライアント識別子ＩＤに関連付けられる。

ステップ３０３０において、アプリケーション１４１は、装置リスト取得メッセージ３０３０をＣＵＴＥラッパーＡＰＩ３０１に送信する。装置リストメッセージは、判定されたクライアントＩＤを、通常は英数字の文字列として含む。

次に、ＣＵＴＥラッパーＡＰＩ３０１は、以前に判定されたロケーションＩＤへ、受信したクライアントＩＤをマッピングする。通常、受信したクライアントＩＤは、特定のユーザに一意に関連付けられ、そして、そのユーザに使用される装置に関連付けられている。

リモートアプリケーション環境のアプリケーション１４１、１４３、１４５の１つによってＣＵＴＥラッパーＡＰＩ３０１に送信された、装置リスト取得メッセージ３０３０は、起動された特定のアプリケーション１４１に関連付けられた装置リストを提供するように、ＣＵＴＥラッパーＡＰＩに指示する。

通常、メッセージ３０３０は、判定されたクライアントＩＤと、搭乗券又は手荷物タグなど、処理されるドキュメントのタイプを定義するデータとを含む。したがって、メッセージ３０３０は、それぞれ処理される搭乗券又は手荷物タグを示す「ＢＰ」又は「ＢＴ」の形式の英数字テキストなどのテキストを含み得る。

ＣＵＴＥラッパーＡＰＩ３０１がメッセージ３０３０を受信すると、メッセージの内容を調べて、要求されたクライアントＩＤ及びドキュメントのタイプを判定する。更に、ユーザセッションＩＤが、ＣＵＴＥラッパーＡＰＩ３０１による使用のためにＡＰＩ環境内の記憶手段に記憶され得るため、ＣＵＴＥラッパーＡＰＩ３０１は、その特定のロケーションＩＤに関連付けられたユーザセッションＩＤの知識をも有する。

＜クライアントＩＤをロケーションＩＤへマッピングするＣＵＴＥ機能＞

ＣＵＴＥラッパーＡＰＩは、クライアントＩＤのロケーションＩＤへのマッピングを実行してもよい。

マッピングを実行するために、ＣＵＴＥラッパーＡＰＩ３０１は、ログインイベントメッセージ３０１３で受信した情報を使用する。したがって、ＣＵＴＥラッパーは、メッセージ３０１３で受信したロケーションＩＤ及びセッションＩＤを使用して、受信したクライアントＩＤを関連付けられたロケーションＩＤにマッピングし得る。

これは、メッセージ３０３０で受信されたクライアントＩＤと一致するクライアントＩＤを（構成ポータルに関連付けられたデータベース１１２などの）データベースで検索することで実行され得る。データベースに保存された一致するクライアントＩＤは、ロケーションＩＤ又は特定のユーザのユーザセッションＩＤと関連付けられる。同様に、ワークステーションソリューションを修正するために、クライアントＩＤのロケーションＩＤへのマッピングが実行され得る。

したがって、ＣＵＴＥラッパーＡＰＩ３０１は、メッセージ３０３０で受信した（特定のユーザ又は装置と関連付けられ得る）クライアントＩＤを、（特定のユーザ又は装置に関連付けられ得る）ロケーションＩＤに変換する。

ステップ３０４０において、ＣＵＴＥラッパーＡＰＩ３０１は、ＣＵＴＥラッパーＡＰＩ３０１によって判定されたロケーションＩＤを使用して、ＡＰＩ環境１０３内の構成ポータル１１５にロケーション加入メッセージ３０４０を送信し、ＡＰＩサービス１１１の１つを介して特定のロケーションに加入する。通常、ロケーション加入メッセージは、ロケーションＩＤ及びユーザセッションＩＤを定義するパラメータを含む。

ＡＰＩ構成ポータルサービス１１５は、ロケーション加入メッセージ３０４０の受信に応答して通知を送信し得るが、このメッセージは、そのオプションとして性質のために図３には示されていない。

通常、システムを使用するために登録されている航空会社及びユーザは、装置の動作が要求され得る前にロケーションに加入している必要があるため、ステップ３０４０が実行される。以下の点に注意されたい。
・ 加入は、ユーザセッションに暗黙的にリンクされる。言い換えれば、構成プロセス中に、航空会社のアプリケーションがロケーションに加入又は関連付けられたとき、航空会社の職員が当該アプリケーション１４１を使用していると想定される。したがって、加入要求は、通常、対応するユーザセッションＩＤを有する必要である。
・ １人のユーザは、通常、ロケーションごとに１つのみのアクティブな加入を持つことができる。しかしながら、ユーザは航空会社アプリケーションを介して複数のロケーションで複数の加入を開始できる。
・ １つの航空会社は、航空会社アプリケーション１４１、１４３、１４５を介して、複数のユーザ又は職員にロケーションを加入させることができる。
・ 加入は、そのロケーションへのアクセスを有する航空会社によって制御される。１つ以上のルールに基づいてこれを強制するために、スケジューラが使用されてもよい。

ロケーション加入メッセージ３０４０は、通常、ロケーションＩＤ及びユーザセッションＩＤ情報、及びオプションで航空会社ＩＤパラメータを含む。前述のとおり、ロケーションＩＤパラメータは、使用されているワークステーション又はポータブル装置１０７のロケーション識別子を定義し、ユーザセッションＩＤはログインユーザセッションＩＤを定義し、航空会社ＩＤはＩＡＴＡ航空会社コードなどの航空会社コードを定義してもよく、通常、これらは英数字の文字列で定義される。オプションで、以下に示される、サンプルのＪＳＯＮロケーション加入要求メッセージ３０４０には、タイムスタンプが含まれていてもよい。

ＮＧＰ ＡＰＩ環境１０３内のＡＰＩサービス１１１は、メッセージ３０４０を受信し、メッセージ１３１及び１３２を介して装置サービスインターフェース１１７と通信して、特定のロケーションに関連付けられた特定の装置と各装置の関連付けられた機能とを判定する。１以上のＡＰＩサービス１１１が提供されている場合、図１に示されているＡＰＩ１１１の１つにルーティングさせる情報がメッセージに含まれていてもよい。

したがって、装置サービスインターフェースＡＰＩ１１７及び構成ポータル１１５は、ＡＰＩ１０３環境内のＡＰＩサービス１１１の１つと通信して、特定のロケーションＩＤに関連付けられた装置のリスト、及びそれらに関連付けられた機能を判定する。

これは、特定のアプリケーションを使用してデータベース１１２を検索することで実行されてもよい。データベース１１２は、特定のユーザロケーション、より正確にはロケーション識別子に関連付けられた装置１０８の詳細を含む。

装置機能は、通常はＡＰＩ環境１０３の一部であるＣＵＴＥラッパーＡＰＩ３０１に返信される。

ＣＵＴＥラッパーＡＰＩ３０１は、受信した装置機能を、図１の１２１及び１２２と、図３のメッセージ３０５とに示されるＪＳＯＮメッセージタイプに変換する。

例示的なＪＳＯＮロケーション加入応答メッセージ３０５０を以下に示す。

通常、装置機能応答メッセージ３０５０は、搭乗券リーダー（ＢＰＲ）、手荷物タグプリンタ（ＢＴＰ）、搭乗券プリンタ（ＡＴＢ）などの利用可能な共有装置のタイプを定義し、各装置にはロケーションＩＤが関連付けられている。

次に、ＣＵＴＥラッパーＡＰＩ３０１は、応答メッセージ３０５０で受信した情報を使用して、特定のロケーションで利用可能な装置を定義する装置リストメッセージ３０６０を生成する。

装置リストメッセージ３０６０は、印刷されるドキュメントのタイプ、より一般的にはドキュメントタイプを印刷するのに必要なプリンタのタイプを定義するデータを含んでいてもよい。例えば、ＡＴＰは、搭乗券を印刷するには搭乗券プリンタが必要であることを示していてもよい。ＢＴＰは、手荷物タグを印刷するには手荷物タグプリンタが必要であることを示していてもよい。ＬＳＲは、搭乗券を読むために搭乗券リーダーが必要であることを示していてもよい。

したがって、リモート航空会社環境１０９で実行されるアプリケーションは、リモートロケーションで利用可能な装置のリストを受信することができる。この利用可能な装置のリストは、通信手段１２９、１２３、又は１２５を介して、例えばＡＰＩ環境内のＷｅｂプロキシ機能１１３を介して送信される。ユーザは、ユーザ装置１０７を使用して、特定のドキュメントタイプを印刷するために利用可能な装置の１つを選択することができる。

ユーザが特定のドキュメントタイプを印刷する装置の１つを選択することに応答して、リモート環境のアプリケーション１４１は、装置オープンメッセージ３０７０をＣＵＴＥラッパーアプリケーション３０１に送信して、装置のリストの装置の１つを開く。装置リストメッセージ３０６０で１つの装置のみが返される場合、ＣＵＴＥラッパーＡＰＩ３０１は、所望の装置に関連付けられた１つのＰＭハンドルを生成する。通常、ＰＭハンドルは、特定のユーザセッション内で、特定の装置を一意に識別する。

ＣＵＴＥラッパーＡＰＩ３０１は、リモートアプリケーション環境１０９内のアプリケーション１４１にＰＭハンドルパラメータを返す。

装置リストメッセージ３０６０が１以上の装置１０８を識別する場合、通常、異なる装置ごとに異なるＰＭハンドルパラメータが生成され、通常、各パラメータは特定のセッションに固有である。

したがって、ＬＨ＿ＡＰＰ１０９から来る装置要求のそれぞれは、ＰＭハンドルによって識別された個別のセッションとして管理される。

メッセージ３０７０は、受信した装置構成リスト（３０６０）に基づいて、各装置のＸＳＰＭＯｐｅｎ呼び出しの形式とされてもよい。これにより、装置とのセッションが作成され、ＰＭハンドルが返される。呼び出しの要素には、１つ以上の
PMRET PMENTRY XSPMOpen (PSZ DevName, PPMHANDLE PPMHandle, ULONG OpenOption, PSZ AirilineID, SHORT DataWaitTime, ULONG Reserved)
が含まれていてもよい。

ＣＵＴＥラッパーＡＰＩ３０１は、通常、特定のセッションに固有のＰＭハンドルを作成する。ＰＭハンドルは、共有装置１０８の１つを一意に識別することができる。ＰＭハンドルは、通常、メッセージ３０８０を使用してリモートＡＰＩ１０９に返される。

メッセージ３０８０は、通常、ＸＳＰＭＯｐｅｎ呼び出しへの応答として送信される。

メッセージは、以下のコード要素のいずれか１つ以上を含んでいてもよい。
PMSaveHandle、ChangedDataFlag、RequestType、Length、CRC、SequenceNumber、AppPMHandle、SaveAppBuffer、ChangedDataFlag、ActivityFlag、NotifySem、IPCHandle、AppBufferAddr、Command、PMHandle、ReturnCode、Status、LocalFlags、Version、DeviceName、AirlineID、UserName、OpenOption、WksName、ExtStatus、DevDwnFlushTime、DataWaitTime、Reserved。

＜特定のＰＭハンドルを装置識別子（ＩＤ）にマッピングするＣＵＴＥ機能＞

特定の印刷要求を処理する場合、ＣＵＴＥラッパーＡＰＩ３０１には、アプリケーション１４１が使用するように構成されている特定の装置を定義するＰＭハンドルを、装置識別子（ＩＤ）に変換する機能が含まれている。ある特定の例では、装置ＩＤは、判定されたロケーションＩＤと関連付けられたラベルを含んでいてもよい。マッピングは、特定の装置に関連付けられた保存されたＰＭハンドルを、ロケーションＩＤ及び装置ラベルを定義する保存されたデータと比較することで実行されてもよい。

前述したように、メッセージフロー３０３０、３０６０、３０７０、３０８０は、１つのユーザセッションの一部を形成してもよい。したがって、保存されたＰＭハンドルは、通常、新しいユーザセッションが開始されるたびに更新される。

メッセージ３０８１及び３０８２は、以下の後続のステップが、通常、特定の搭乗券又は乗客用の手荷物タグを印刷する、或いは特定の乗客の乗車券を読み取る、ユーザ装置１０７からの特定の要求に応じてのみ発生することを示している点で概略的である。したがって、後続のステップは、特定のアクションの実行をユーザが要求することによって開始されてもよい。

メッセージ３０８３も概略的であり、リモート航空会社環境で実行されているアプリケーションがリモート予約又は出発制御システムにログインする方法を示している。これは、特定の乗客に関連付けられたＰＮＲデータなどの乗客データがシステム１００内に保存され得るため、オプションである。

＜搭乗券又は手荷物タグの印刷例＞

以下の例では、職員又は乗客が、装置１０７で実行されているアプリケーションを使用して、ＡＰＩ環境１０３を介してローカル空港環境１０５と通信する、リモートアプリケーション環境１０９で実行されているアプリケーション１４１、１４３、１４５を使用して、共有装置１０８で搭乗券又は手荷物タグを印刷する機能を実行する、特定の例に焦点が当てられている。

これは、特定の乗客の名前などの特定の乗客データが、例えばパスポートから読み取られること、或いは、ユーザ装置の１つで実行されているアプリケーションに入力されることを前提としている。

この情報により、予約又は出発制御システムＤＣＳ１０２は、乗客の予約を一意に識別し、アプリケーション１４１、１４３、又は１４５に返信するデータを識別できる。

通常、特定の予約を一意に識別するために、ＤＣＳ１０２は、予約に使用されたクレジットカード番号と乗客の名前との組み合わせを使用する。

例えば、クレジットカード番号の最初の４桁及び最後の６桁と、関連付けられた名前とを使用して、特定の予約が識別され得る。あるいは、名前及び生年月日などのパスポートデータを使用して、乗客の予約が一意に識別され得る。更に、参照番号などの予約ロケーターを使用して、乗客の予約が一意に識別され得る。

特定の乗客の予約がバックエンドＤＣＳ１０２で識別されると、これにより、特定の乗客のＰＮＲに関連付けられたデータが判定され得る。したがって、システムは、例えば空港識別子、飛行時間、フライト番号、及び発行された座席を使用して、乗客が飛行機で向かう空港を特定することができる。このデータにより、搭乗券が、特定の乗客に対して発行され得る。

更に、乗客が手荷物をチェックインした場合、ＤＣＳは、ライセンス・プレート・ナンバー（ＬＰＮ）の形式で、その手荷物の識別子を作成する。ＤＣＳは、手荷物情報、空港識別子、フライト番号、及び関連付けられた又はリンクされた手荷物のＬＰＮを航空会社のアプリケーション環境１０９に返信する。

このため、リモートアプリケーション１４１、１４３、１４５は、データベースに保存された乗客名記録（ＰＮＲ）予約を取得してもよい。これは、通常、乗客の予約が作成されるときに作成される。多数のＰＮＲがデータベースに保存され得るため、各ＰＮＲはレコードロケーターによって識別される。

通常、各ＰＮＲは、乗客の名前、チケット番号などのチケットの詳細、旅行の少なくとも１つの区間の旅程、及び情報提供者又は予約者の名前のいずれか１つ以上を含む。旅程は、（ニューヨーク、ＮＹＣなどの）出発空港コード、（ロンドンヒースロー、ＬＨＲなどの）到着空港コード、出発予定日時、到着予定日時によって定義されてもよい。

これにより、出発予定時刻及び出発空港のロケーションなどを使用して、出発管理システムによって搭乗券又は手荷物タグが発行される。

手荷物タグ及び搭乗券は、手荷物タグＩＡＴＡ決議７４０及びＲＰ１７４０ａ、並びに搭乗券ＩＡＴＡ決議７２２ｅ及びＲＰ１７２３などの、ＩＡＴＡ決議などのＩＡＴＡ ＲＰＳドキュメント、及びＲＰ（推奨プラクティス）、で定義され得ることは理解されよう。

特定の乗客レコードの位置が特定されたことの通知は、通常、ユーザ装置１０７で実行されているＧＵＩに提供される。更に、出発制御システム１０２から取得されたデータは、アプリケーション環境内のアプリケーション１４１の１つに返信される。ＡＰＩサービス１１１は、アプリケーション１４１の１つにデータが正常に受信されたことの通知を提供し、データを装置サービスインターフェース内の正しいサービスにルーティングするルーティング機能を実行する。

ステップ３０９０において、ユーザ装置１０７をユーザが使用するために選択された、特定のアプリケーション１４１は、プリント搭乗券又は手荷物タグメッセージ３０９０を送信する。これは、ＸＳＰＭＡＰＩメッセージング／通信を使用して行われ得る。これは、従来のアプリケーションで使用されているライブラリ及び通信を定義する。

通常、プリント搭乗券又は手荷物タグメッセージ３０９０に含まれるデータは、ＡＥＡ形式に基づいている。

通常、メッセージ３０９０は、搭乗券又は手荷物タグの印刷など、実行される動作のタイプを定義する。更に、メッセージは、搭乗券又は手荷物タグを印刷するためのデータを含む。通常、このデータは乗客名を含むが、搭乗券又は手荷物タグの定義に関して前述した情報の１つ以上を含んでいてもよい。

通常、搭乗券又は手荷物タグを印刷するためのメッセージ３０９０は、ＰＥＣＴＡＢに基づく従来のプロトコルを使用して、搭乗券及び手荷物タグのレイアウトを提供する。メッセージ３０９０は、Ｃ言語構造に基づいたＴＣＰ／ＩＰソケット通信を使用して送信される。

メッセージのペイロード構造は、搭乗券又は手荷物タグを印刷するために必要なデータ要素を含む。例えば、メッセージは、英数字形式の、乗客名、フライト番号、ゲート及び座席番号を含んでいてもよい。メッセージは、ＰＥＣＴＡＢテンプレートにマッピングされる。データメッセージ３０９０は、フィールドを識別する必要がないように構成されている。メッセージは、使用される特定のＰＥＣＴＡＢテンプレートを定義するフィールドを含んでいてもよい。

メッセージ３０９０は、ＸＳＰＭＷｒｉｔｅ呼び出しの形式であってもよい。呼び出しには、搭乗券又は手荷物タグなど、印刷されるドキュメントの詳細を含んでいてもよい。呼び出しは、以下のような、当業者には周知である、欧州航空コマンド協会などの、１つ以上のコマンドを含んでいてもよい。
PMRET PMENTRY XSPMWrite (PMHANDLE PMHandle, PPMDATABUFFER PPMBuf, ULONG WriteOption, HEV Semaphore, ULONG Reserved)

次に、ＣＵＴＥラッパーＡＰＩは、メッセージ３０９０をＮＧＰシステムによる処理に適した形式に変換して、メッセージ３１００を生成する。

メッセージ３１００は、ｈｔｍｌテンプレート、搭乗券又は手荷物タグデータ及びテンプレートに基づいており、ＣＵＴＥラッパーＡＰＩ３０１は、例えば、画像印刷メッセージ３１００を生成する。

メッセージ３１００は、通常、キーバリューペアを使用するＪＳＯＮに基づいており、Ｗｅｂ ＡＰＩを使用して通信される。ＣＵＴＥラッパーは、メッセージ３０９０を分析して、ゲート番号又は座席を定義するフィールドなどの特定のフィールドを識別し、これらのフィールドを区別することができる。

図３に示すＣＵＴＥラッパーＡＰＩ３０１は、メッセージ３０９０の従来のプロトコルからメッセージ３１００のプロトコルにデータをマッピングする。言い換えると、ＣＵＴＥラッパーＡＰＩ３０１は、メッセージ３０９０をキーバリューペアに変換し、システム１０３によって保存された情報を追加してもよい。ＣＵＴＥラッパーＡＰＩは、例えば搭乗券のレイアウトのためのｈｔｍｌテンプレートを使用して、メッセージ３０９０を変換する。

次に、ＣＵＴＥラッパーサービス３０１は、例えばＪＳＯＮメッセージを使用してＡＰＩ環境１０３に送信される、プリント搭乗券又は手荷物タグメッセージ３１００を作成する。これは、従来の印刷コマンドを新しいＮＧＰ印刷コマンド及びファイルに変換することと考えることができる。

印刷ＢＰ／ＢＴメッセージ３１００の例示的なフォーマットが以下に示される。

したがって、ＣＵＴＥラッパーＡＰＩによって生成されたメッセージ３１００は、ロケーション識別子（ＩＤ）（ＬｏｃａｔｉｏｎＩＤ）及び装置ラベルを含み得ることは理解されよう。前述のとおり、ロケーション識別子は、「ＬＡＸ−Ｔ１−ＧａｔｅＢ２１−ＷＫＳ−００１」又は「ＪＦＫ−Ｔ０１−ＧＡＴＥ０３−ＷＫＳ−００２」などの英数字データを含み得る。前述の例示的な印刷メッセージ３１００では、装置ラベルは「ｌｏｃａｔｏｒ」フィールドに含まれている。このことから、共有装置プリンタ１０８は、実際には手荷物タグプリンタ（ＢＴＰ）であることがわかる。しかしながら、例えばキーバリューペアとして、別個の装置ラベルフィールド及び関連付けられた値がメッセージ３１００で提供されていてもよい。更に、メッセージ３１００は、例えば、手荷物タグ又は搭乗券を印刷するために必要なデータのいずれかなど、前述のメッセージに示されるフィールドのいずれか１つ以上を含んでいてもよい。

例示的なドキュメント印刷通知メッセージ３１３０が以下に示される。通知メッセージ３１３０は、ＡＰＩ環境１０３内のアプリケーションのうちの１つにより、ＣＵＴＥラッパーＡＰＩ３０１に送信されてもよい。

ＡＰＩ環境１０３内のＡＰＩ１３１、１３２、１１７の１つによって生成された例示的なドキュメント印刷要求メッセージ３１１０が以下に示される。メッセージ３１１０は、ＡＰＩ環境１０３内のアプリケーションの１つによってメッセージ３１００で受信された情報に基づいて生成される。メッセージ３１１０の例では、フィールド「ＤｅｖｉｃｅＩＤ」によって特定の装置を一意に識別することができる、一意の装置ＩＤが提供される。印刷メッセージ３１１０に関連付けられたデータもまた「ＣｏｍｍａｎｄＤａｔａ」として以下に含まれ、例えば搭乗券又は手荷物を印刷するために、当該のドキュメントを印刷又は処理するために必要なメッセージ３１００に含まれる１つ以上のデータを含んでいてもよい。ロケーション識別子（ＩＤ）及び装置ラベルの組み合わせを使用して、ドキュメント印刷要求の送信先である特定の装置が一意に識別されてもよい。

グローバル一意識別子は、印刷メッセージ３１１が送信される共有装置１０８を一意に識別するために、ロケーションＩＤ及び装置ラベルを使用することの代替として使用されてもよい。

例えば、初期システムセットアップ中に、構成ポータル１１５内のアプリケーションは、ＧＵＩＤ（グローバル一意識別子）又は言い換えればｄｅｖｉｃｅＩＤ：「４１３ｄｃ６ｃ０ａ０３ｄ４ｄ６ａ９ｃｄ２ｃ１＝＝」を作成する。「４１３ｄｃ６ｃ０ａ０３ｄ４ｄ６ａ９ｃｄ２ｃ１＝＝」をロケーションＩＤ及び装置ラベルにマッピングするＮＧＰシステム１０３内のＡＰＩが提供されていてもよい。ロケーションＩＤ及び装置ラベルへの装置ＩＤのマッピングは、ＡＰＩを使用して、データベースに保存されているデータの検索することによって実行されてもよい。

したがって、前述したＧＵＩＤに代えて、又はＧＵＩＤに加えて、ロケーションＩＤ及び装置ラベルの組み合わせを使用して、プリント搭乗券又は手荷物タグメッセージ３１１０がルーティングされるべき共有装置を一意に識別することができる。これによって、このメッセージは、装置ＩＤの形式で印刷要求を送信する装置を定義する。ＡＴＰなどのロケーションＩＤ及びラベルは、特定の装置ＩＤにマッピングされてもよい。

以下で更に詳しく説明されるフィールドゲートウェイコンポーネントは、このようにして、ロケーションＩＤ及びラベルなどの装置ＩＤを定義するデータを格納し得る。フィールドゲートウェイコンポーネントは、この情報を特定のポート番号にマップすることもでき、これにより、印刷メッセージ３１１０を送信する装置を正しく判定することができる。

装置サービスインターフェース１１７は、搭乗券又は手荷物タグの印刷などの、正しい装置サービスを選択する。これは、印刷されるドキュメントを定義する情報に基づいて行われる。１１７内の選択されたサービスは、ＰＥＣＴＡＢ形式で定義された搭乗券又は手荷物タグなどの形式に従ってデータを印刷するために必要なテンプレートを選択し、受信したデータを形式に従って符号化する。したがって、共有装置に送信されたＡＭＱＰメッセージは、ｐｄｆ形式に符号化されたデータとともに送信され、搭乗券又は手荷物タグなどのドキュメントタイプを定義してもよい。

従来の搭乗券プリンタ及び手荷物タグプリンタの場合、図１にＦＲとして示された、オプションのフィールドゲートウェイは、ＡＴＰなどの、ロケーション識別子と装置ラベルとに基づいて、共有ロケート装置の１つにメッセージをルーティングする。証明書も使用される。これにより、ＡＴＰなどのロケーションＩＤ及びラベルが、一意の装置識別子に変換される。

搭乗券又は手荷物タグを印刷するための要求メッセージ３１１０の受信に応じて、共有装置１０８は、オプションの通知メッセージ３１２０を送信してもよい。前述したように、ＡＰＩ１１１は、要求が正しく受信されたことの通知メッセージ３１３０を、１つ以上の共有航空会社環境で実行されているアプリケーション１４１、１４３、１４５に返送してもよい。通知メッセージは、ＡＰＩ環境のアプリケーション１１１から通知メッセージ３１３０を受信するフィールドゲートウェイを介してルーティングされてもよい。

前述のとおり、ＡＰＩサービス１１１は、アプリケーション環境のアプリケーション１４１から受信した要求のタイプを判定する機能を実行し（例えば搭乗券又は手荷物タグを印刷し）、装置サービスインターフェース１１７のどのサービスが要求を処理するかを判定する。

最後に、ドキュメントは、装置がメッセージ３１１０を受信することに応答して、共有装置１０８の１つで印刷される。乗客又は職員は、以降の使用のためにドキュメントを収集する。

装置サービスインターフェース１１７内に異なる装置サービスを有するこのアプローチにより、システムに影響を与えることなく、支払い装置などの追加の装置を追加することが可能になる。

搭乗券及び手荷物タグの印刷に加えて、ＯＣＲ、ＬＳＲ、ＭＳＲ、及び搭乗ゲートなどの他の装置も同じ方法によってサポートされる。この例では、メッセージ構造は、図面の図３に、３１５０、３１６０、及び３１７０として示されている。

＜アプリケーションの終了＞

航空会社の職員は、彼らのＤＣＳにサインオフして、ＬＨ＿ＡＰＰを閉じる。これが、ＣＵＴＥラッパーサービスとのＬＨ＿ＡＰＰ ＣＩＴＲＩＸセッションを終了させる。航空会社の職員がＮＧＰからログアウトし、クライアント装置がログイン画面に戻る。ＮＧＰのシステムは、その後、ログアウトイベントをＣＵＴＥラッパーサービスに発行して、ＣＵＴＥラッパーサービスにユーザセッション及びＬＨ＿ＡＰＰに関連付けられているすべてのリソースを解放させる。

＜ルータ１１８及びＡＭＱＰプロトコルメッセージの詳細な説明＞

ＡＰＩ環境１０３内で、ルータＡＰＩ１１８が提供されてもよい。これは、ＡＰＩサービス１１１と同様の機能を実行し得る。ルータは、装置サービスインターフェース１１７の１つから受信したメッセージを検査する機能を有する。これは、ローカル環境内の正しい装置１０８にメッセージ１２４をルーティングする機能を有する。

ルータ１１８は、装置サービスインターフェース１１７から受信したメッセージ１２４を検査する。これは、装置タイプを定義するヘッダー情報レベルでメッセージを検査することにより行われてもよい。ヘッダーは、どの共有装置１０８に特定のメッセージが通信されるべきかを一意に識別し得る。

共有装置１０８のそれぞれは、ＡＰＩ環境で登録プロセスを受ける。登録プロセスの一部として、各装置１０８にトークンが発行される。トークンにより、共有装置１０８はクラウド１１９に接続することができる。

トークンは、メッセージ１２４のメッセージヘッダに含まれ、トークンを調べることにより、ルータＡＰＩ１１８は、ローカル空港環境１０８内のどの装置にメッセージが送信されるべきかを判定し得る。

装置サービスインターフェース１１７はまた、メッセージ１３１によって受信された情報を処理し、データをｐｄｆメッセージフォーマットに変換する。特定の装置サービスインターフェース１１７は、受信したデータを、例えばＰＥＣＴＡＢフォーマットに従って定義された搭乗券又は手荷物タグのいずれかを定義するｐｄｆメッセージフォーマットに変換する。

更に、特定の例では、アドバンスト・メッセージ・キュー・プロトコル（ＡＭＱＰ）メッセージプロトコルを使用して、メッセージが、装置サービスインターフェース１１７からルータ１１８を介して、そして、通常は、クラウドインターフェース１１９をも介して、共有装置１０８に送信される。図面の図３を参照して以下に更に詳細が説明される。ＡＭＱＰは、アプリケーション間でメッセージを受け渡すためのオープンスタンダードである。ＡＭＱＰのデータ単位はフレームと呼ばれる。メッセージの転送を開始、制御、及び終了するために、９つの異なるフレームが定義されている。メッセージは、転送フレームを使用してリンクを介して送信される。リンク上のメッセージは、通常、一方向にのみ流れる。

図面の図１に示され例では、Ｗｅｂプロキシサービス１１３は、ＡＰＩ環境内で提供されている。Ｗｅｂプロキシサービスは、通常、リモートアプリケーション環境１０９（即ち、リモートアプリケーション環境１０９のアプリケーション１４５又は１４３又は１４１の１つ）と、ローカル空港環境１０５に表示されている１つ以上のユーザ装置１０７との両方に通信可能に結合されている。Ｗｅｂプロキシ機能は、航空会社アプリケーションへのＧＵＩ接続を提供し得る。また、Ｗｅｂプロキシサービスは、空港環境のタブレット、ワークステーション、及びキオスクディスプレイ１０７へのＧＵＩ接続を提供する。

しかしならが、Ｗｅｂプロキシ機能１１３は、実際にはオプションであり、実際にはユーザ装置１０７が、リモートアプリケーション環境１０９に直接接続されてもよく、ローカル空港が、通信手段１２９を介して、当業者に知られた有線又は無線インターネットプロトコルを使用してリモートアプリケーション１０９にアクセス可能とされもよい。

＜機能サービスインターフェースの説明＞

図面の図１には示されていない機能サービスインターフェースが提供されてもよい。通常、この機能は、装置サービスインターフェース１１７内で提供される。あるいは、機能サービスインターフェースは、装置サービスＡＰＩ １１７に通信可能に結合された別個のＡＰＩサービスとして提供されてもよい。

搭乗券スキャナには、多くの場合、光を表示して音を出す機能が含まれている。これにより、搭乗券が受け付けられたか否かに関して、航空会社の職員に視覚的、聴覚的な表示が提供される。これは、発光ダイオードなどの任意の照明手段、及びスピーカー手段の配置によって行われ得る。スキャナが光を出すか音を出すか、或いは両方を出すか、ビープ音及びフラッシュの回数などの、放射される光又は音の特定の形式に関する、特定の選択は、通常、各装置のメーカーによって判断される。いずれの場合でも、これらの設定は、構成ポータルを介して定義及び変更され得る。

したがって、航空会社は、依然として共有装置の構成設定を完全に制御できるが、これはインターフェースではなく、構成ポータル１１５を介して行われる。

これにより、航空会社が、特定のユーザについて、特定の空港について、リモートで構成を実施できるため、搭乗券が受け付けられたときの通知信号の数を制御できる。これにより、装置の機能がインターフェースを介さずに機能できるようになる。したがって、航空会社は、構成インターフェースを介して共有インフラストラクチャの構成設定をセットアップできる。これにより、構成設定をインターフェースに配置する必要がなくなり、共有インフラストラクチャインターフェースがどのように機能するかをアプリケーションが知る必要もなくなる。

更なる例では、共有インフラストラクチャの使用に関して、航空会社の職員が搭乗券をスキャンするとき、構成設定を選択することによって、スキャン装置が搭乗券の有効性に関するバックエンドシステムからの応答を受信するまで、装置にロックさせることができる。

したがって、構成設定を選択することによって、搭乗券がスキャンされた後、搭乗券の追加スキャンが実行されないことを示す視覚的な表示が提供される。例えば、ＬＥＤライトが使用されている場合、これは赤色に変わり、追加のスキャンが実行されないことを示す。

機能サービスインターフェースは、共有装置１０８のそれぞれによって必要とされるデータのタイプ及びデータ構成を判定する。通常、各装置に関連付けられた機能設定及び構成設定を保存するデータベース１１２が提供される。

したがって、装置インターフェース１１７は、物理的な装置のデータベース、すなわち、物理的な装置１１２のマスターリスト並びにそれらに関連付けられた機能及び構成設定を検索することにより、共有装置のそれぞれと対話するように適切に構成され得る。機能又は／及び構成の設定は、航空会社の設定に応じて、そして、オプションで場所に応じて異なってもよい。

加入航空会社は、装置機能のデータベースを照会し、構成ポータル１１５を介してデータベースを変更できる。

前述したものを説明するために、特定の例では、航空会社の職員が共有搭乗券リーダーを使用して、乗客が航空機に搭乗するときに乗客の搭乗券をスキャン又は読み取ると仮定する。

乗客名などの特定のデータが搭乗券から読み取られる。このデータは、搭乗券データと呼ばれる。乗客名は、現在の日時及び空港コードのいずれか１つ以上と併せて、出発制御システム１０２などの１つ以上のバックエンドシステムが、乗客名レコード（ＰＮＲ）データベースの乗客に対応するデータが搭乗券に含まれていることをチェックするのに十分となり得る。

職員によってスキャンされた搭乗券が受け付けられると、出発制御システム１０２は、搭乗券受け付けメッセージをリモートアプリケーション環境１０９に送信する。これは、リモートアプリケーション環境のアプリケーション１４１、１４３、１４５の１つによって受信され、１２１を介してＡＰＩサービス１１１に渡され、次いでＡＰＩサービスから１３１を介して装置サービスインターフェース１１７に送信される。装置サービスインターフェース１１７は、１２４を介してこのメッセージを共有スキャナ１０８装置に渡す。

スキャナ装置は、１つ以上のインジケータを提供することにより、スキャンされた搭乗券が出発管理システムによって受け付けられたことを示してもよい。装置メーカー及び航空会社が独自の設定に基づいてデフォルト設定を構成し得るため、これらのインジケータは原則として任意の形式を取り得る。しかしながら、例えばスキャナは、緑色のＬＥＤを点灯すること、及び／又はオプションで一連のビープ音又は音声インジケータを生成することにより、搭乗券が受け付けられたことを示してもよい。

データベースからこの装置機能データを取得するのは、図１でＣＳとラベル付けされた機能サービスＡＰＩである。機能サービスＡＰＩは、通常、装置サービス１１７内に配置される。

通常、装置のリストが提供される。リストは特定の装置を識別し得る。例えば、装置が搭乗券又は手荷物タグを読み取れることを示す、装置の機能を定義する関連情報が提供され得る。構成設定は、通常、各装置に対して定義される。これらは、特定の搭乗券がバックエンド出発管理システムによって受け入れられたか否かを示す特定の構成設定に関連していてもよい。具体的な一例では、設定は、搭乗券が受け付けられたことを通知するために、スピーカーのＬＥＤの数及びＬＥＤの点滅の数、又はスピーカー装置から発せられる音の数を定義することができる。通常、特定の加入航空会社は、使用したい特定の構成設定を定義する。

機能サービスは、通常、共有装置１０８が共有使用のために構成されている場合、通常、初期システム構成の一部として構成される。構成プロセスの一部は、ローカル環境１０５で使用可能な物理的な共有装置１０８をリストアップすることである。

どの共有装置１０８がローカル環境１０８で利用可能であるかが判定されると、各装置の物理的な機能が判定される。したがって、各装置１０８について、関連付けられた物理的な機能のリストが定義される。各装置に関連付けられている機能設定及び構成設定は、通常、データベース１１２に保存される。

例えば、共有装置１０８がＤＥＳＣＯ（商標）ＶＧＲ装置であると仮定する。この装置は、パスポートの読み取り／スキャン、搭乗券の読み取り／スキャン、クレジットカード又はデビットカードの読み取り／スキャン、又はゲート機能、のいずれか１つ以上の機能を有し得る。

ゲート機能とは、通常、航空会社の職員によって実行される、乗客の搭乗券をリーダーでスキャンし、搭乗券に関連付けられたデータを出発管理システムなどのバックエンドシステムに送信することで、乗客の搭乗券をチェックするプロセスを意味する。このため、名前及び座席番号などのデータは、ＤＣＳから読み取られ、共有装置に送り返されてもよい。職員は、ＤＣＳから判定された情報が搭乗券の情報と一致することを手動で確認してもよい。

前述のとおり、このＶＧＲ装置には４つの機能が設定されていることが理解されよう。
したがって、このようなＶＧＲ装置を持つ特定のロケーションに加入しているアプリケーションの場合、前述の全ての機能がリストアップされる。

ゲート機能は、飛行機の搭乗へのアクセスを制御することが理解されよう。

ゲート機能の一部として、以下のステップが発生し得る。
・ 搭乗券のスキャン又は読み取り。
・ 装置は、装置がロックされていることを示す赤いライトを点灯するように構成されている。これにより、バックエンドＤＣＳがデータベースにアクセスできるようになるまで、他がスキャンできなくなる。
・ 搭乗券から読み取られたデータが有効に発行された搭乗券に対応することをＤＣＳがチェックすると、（例えば、搭乗券から読み取った乗客名及び座席番号がＤＣＳに保存されたデータに対応すると）、受け付けコマンドがＤＣＳによって発行され、装置に通信され得る。受け付けコマンドの受け付けは、緑色のライト又は１つ以上のオーディオインジケータによって通知され得る。
・ これらは、特定の乗客名及び座席番号を持つ有効な搭乗券が発行されたことをＤＣＳが確認したことを職員に通知してもよい。
・ 職員は、搭乗券に表示されている搭乗券情報がパスポート又は身分証明書に表示されている乗客データと一致することを確認するために、クロスチェックを実行してもよい。

２番目の例では、装置はＡＣＣＥＳＳ（商標）ＶＧＲ装置である。この装置には、ゲート機能として機能する、１つの機能のみを有し、パスポート又はクレジットカードの読み取りはできない。したがって、リモートアプリケーション１４１、１４３、１４５環境内の特定のアプリケーションが特定のロケーションでこの装置に加入している場合、この１つの機能がこの装置に対してリストアップされる。

各装置について、共有装置１０８に関連付けられた構成情報が保存される。例えば、構成設定は、搭乗券が受け付けられたことを示す１、２、又は３などの通知音の回数に関する特定の選択など、受け付けメッセージの音声又は視覚の通知を提供するために選択された特定の設定に関連し得る。

この構成情報は、メッセージ１２４を介して通信される。これは、これらの装置構成情報がメッセージ１２５、１２３、１２１、及び１３１を経由して、すべての機能コンポーネントを渡す必要がある既知のシステムとは対照的である。

機能サービスインターフェースは、装置のメーカー及びモデルではなく、装置機能によって定義された個々の装置サービスを提供する。これにより、装置の管理と、航空会社／空港アプリケーションからの物理的な装置の知識が抽象化される。これには、膨大な数の装置機能の列挙及び分割、並びに物理的な装置のマスターリストへの個別の割り当てが含まれる。したがって、（空港環境で共有装置１０８の１つとして配備できる）装置のデータベース又はリスト機能が提供されてもよい。リスト又はデータベースは、ストレージ装置１１２に格納されてもよい。同様に、データベース１０４はストレージ装置に格納されてもよい。

したがって、提供される主要な機能は、アプリケーションを変更したり、ユーザに豊かな体験を提供するために未来の装置の機能を利用したりすることなく、未来の装置をＡＰＩデータと統合することであると理解されよう。

ＡＰＩ１１１は、インターフェース及び構成設定に基づいて、リモート空港環境１０９内のアプリケーション１４１、１４３、１４５への空港装置１０７、１０８の管理及び制御されたアクセスを提供する。空港管理者は、ＡＰＩ構成ポータルで装置１０７、１０８及び空港アプリケーション１４１、１４３、１４５を個別に構成し、空港でローカル又はリモートで動作する、航空会社、地上ハンドラー、及びその他のエンティティで使用できるようにする。航空会社の管理者は、ユーザ及びアプリケーションを個別に構成し、それらを空港の装置に割り当てて、すぐに動作できるようにすることができる。航空会社及び空港の管理者は、追加の管理者を作成し、責任の一部又はすべてを委任できる。

＜同じ共有インフラストラクチャを共有する同じロケーションにいる複数の異なるユーザの説明＞

本発明の実施形態は、同じ又は同様のロケーションにあり、同じ共有装置の使用を望む異なるユーザ装置の複数の異なるユーザを扱うことができる。これは、複数のユーザ間で装置を共有する方法に関する一連のルールを提供することで実現される。プリンタの場合、ルールは、単に複数の異なるユーザがプリンタに接続することを許可し、印刷ジョブが受け取られた順にスケジュールされる。

スキャナ又はクレジット／デビットカードリーダーなどの共有インフラストラクチャについては、ルールはより正確に定義される必要があり得る。例えば、それらのスキャナ又はリーダーの使用を要求するアプリケーションは、装置が使用可能であれば確立するためにリーダーに要求を送信することを要求され得る。

複数の異なるユーザはそれぞれ、図１に示される、データチャネル１２４及びグラフィカルユーザインターフェース、ＧＵＩチャネル１２５を共有し得る。

したがって、ルールエンジンを使用して、異なる航空会社及び航空会社間、並びに同じ又は異なる航空会社に属する異なるユーザ間の装置を共有するルールを管理し得ることは理解されよう。例えば、チェックイン装置は様々な航空会社で共有し得るが、共有キオスクにユーザがアクセスするには、装置がアイドル状態になっている必要があることは理解されよう。

＜下位互換性への対処＞

前述したソリューションの独自の機能は、航空会社の従来のアプリケーションと、従来の装置を取り巻く標準とに対応し、更に前述した顧客に多くの利点を提供する機能である。これは、プラットフォーム内の個別のパスに従って、周辺機器の通信及び航空会社のアプリケーションの配信を行うことで実現される。
・ 既存の航空会社アプリケーションは、ローカルインストールを必要とせずに、サーバベースのコンピューティングテクノロジーを使用して、Ｍｉｃｒｏｓｏｆｔ（商標）Ａｚｕｒｅ（商標）クラウドから端末に配信される。
・ 従来のアプリケーションから以前のシステムのＡＰＩへの呼び出しは、新しいプラットフォームにメッセージを注入し、正しい形式で応答を配信するソフトウェア変換レイヤーを介してルーティングされる。これにより、大幅な変更なしに従来のアプリケーションが使用され得る。
・ したがって、周辺トラフィックはそれを生成するアプリケーションから分離され、より柔軟な配信／配備モデルが可能になる。
・ 従来の周辺機器は、大抵、動作をサポートするためにオンサイトで配備された複雑なＰＣハードウェアを必要とする。我々のプラットフォームは、サービス地点で配備された追加の機器に依存するのではなく、Ａｚｕｒｅベースのシステムからこれらの端末を管理する。
・ 顧客は、従来の固定空港ロケーションから、或いはインターネットに接続されたリモートのロケーションから、彼らの従来のアプリケーションにアクセスできる。

このデータは受信されると、解析されてもよい。

＜ＮＧＰインターフェース＞

プラットフォームは、（航空会社、空港、オペレータなどの）顧客の視点と装置／ロケーションの視点という、２つの論理的な視点からコア機能を公開する。これらのインターフェースは、動作及び実装は既存のシステムに比べてはるかに単純であるのに、すべてのプロセスを実行するための完全なアクセスをエンティティに提供するという点で独自である。

＜航空会社／空港インターフェース＞

本発明の実施形態は、非常に単純な航空会社インターフェース、この単純なインターフェースを通じて公開される完全な装置機能、ローミング及びモバイル機能、単純なユビキタスＷｅｂアプリケーション、非常に柔軟で強力な構成、スマートに直接接続された装置、ワークステーション不要、及び高セキュリティという利点を有し得る

航空会社及び空港のインターフェースは、顧客がアクセスして利用できるコアサービスを形成する。このインターフェースは、抽象化により、航空会社と空港が、装置、セキュリティ、構成、及びモニタリングサービスにアクセスするためのシンプルなレイヤーを提供する。プラットフォームサービスは、多くのチェック及びバランスを実装し、その一部は、航空会社、空港によって構成され、その他は、プラットフォームによって構成される。インターフェースは、シンプルであるが、プラットフォームとの複雑なインタラクションのいくつかのレイヤーを隠し、ユーザ、要求、及びデータの、承認、認証、及び検証を保証する。また、インテリジェントプラットフォームは、予想される動作を理解するために、機械学習技術を介してそれ自身をモニタリングし、逸脱をモニタリングし、そして修正アクションを実行できる。

＜機械学習モジュールの説明＞

特定の一実施形態では、機械学習モジュール又はディープラーニングモジュールはＡＰＩ環境１０３内で提供されていてもよい。機械学習モジュールは、ストリーム分析を実行することができる。これは、リモートアプリケーション環境１０９又はローカル空港環境１０５又はその両方の間の通信をモニタリングし得る。例えば、共有装置１０８のうちの１つによって、１分あたりに読み取られるパスポートドキュメントの数などの特定の行動が判定され得る。数が所定の閾値よりも大きい場合、フラグが提供されてもよい。これにより、オペレータは動作を確認し、動作が許可されるべきか否かを判定することができる。１分あたりの読み取り回数が閾値を超えていると判定されると、ＡＰＩ環境へのアクセスが拒否され得る。同様に、機械学習モジュールは、ＡＰＩ環境からメッセージを受信するリーダー又はスキャナの数をモニタリングするように構成されていてもよい。同様に、この値が所定の閾値よりも大きい場合、これはシステムのセキュリティ違反を示している可能性がある。ＡＰＩ環境１０３へのアクセスは、この判定に基づいて拒否され得る。したがって、許容可能な行動パターンのライブラリは、各共有装置１０８及びユーザ装置１０７に対して生成され得る。

すべての装置機能は、独自に設計されたハイレベルのインターフェースを介して公開される。これらのインターフェースは、通常、シリアルなどの古いインターフェース、及び厳密なレイテンシ及びメッセージ要件（リンク層）を有する業界全体で使用される従来の装置のために設計されている。

＜プラットフォームインターフェース＞

プラットフォームは、装置サービス、ロケーションサービス、セキュリティサービス、モニタリングサービス、ロギングサービス、管理サービス、構成サービスなどのプラットフォーム機能を実装するために使用されるいくつかの内部インターフェースを公開する。独自のメッセージング構造が、クラウドから装置（航空会社から装置）又は装置からクラウド（装置から航空会社）のいずれかの方向で、プラットフォームとの間で必要なデータをやり取りするために、設計されている。組み込みのメカニズムが、パフォーマンス測定としてメッセージ遅延を計算し、遅延がパフォーマンス制限に達した場合に修正アクションを提供するために、作成される。プラットフォームインターフェースは、その下に構築された複雑なモニタリングソリューションも抽象化し、動作、機能、及びビジネスプロセスに関するプラットフォーム全体の情報へのアクセスを提供する。この情報は、プラットフォームを利用するすべてのパートナー及び顧客が世界中でリアルタイムに利用できる。このプラットフォームにより、航空会社は既存のビジネスプロセス、ソフトウェア、及びハードウェアを引き続き利用しながら、この環境で常に望まれるすべての柔軟性、管理、及び保守機能を獲得することができる。

＜フィールドゲートウェイサービス＞

図面の図１にＦＧとして示されている、フィールドゲートウェイサービスでは、ダウンロードパッケージが、通常、構成ポータル１１５への接続に応じて、トリガーされる。パッケージのダウンロードの一部として、関連付けられたセキュリティ証明書もパッケージとともにダウンロードされる。ロケーション識別子（ＩＤ）が前述したように判定されると、ロケーションＩＤはフィールドゲートウェイサービスに渡される。フィールドゲートウェイサービスは、ＡＰＩ環境１０３に接続する。フィールドゲートウェイは、ダウンロードされた証明書及び以前に判定されたロケーションＩＤを使用する。したがって、フィールドゲートウェイは、証明書及び判定されたロケーションＩＤを使用して、構成ポータルに接続する。これにより、構成ポータルは、このロケーションの装置に必要な特定の構成を判定できる。

構成サービス１１５は、フィールドゲートウェイから要求を受信し、判定されたロケーションＩＤを使用して、どの装置が特定のロケーションに関連付けられているか、及びそれらの装置に必要な特定の構成を判定する。

すべての装置ラベルはＩｏＴハブに登録され、トークンは各ラベル、つまり装置に関連付けられる。

フィールドゲートウェイサービスでは、従来の手荷物タグプリンタ及び搭乗券プリンタをリモートで接続できる。プリンタが割り当てられているポートは、プリンタが搭乗券プリンタであるか又は手荷物タグプリンタであるかを判定する。例えば、手荷物タグプリンタは、通常ポート０７に割り当てられる。

したがって、フィールドゲートウェイサービスは、プリンタがどの印刷ポートに割り当てられているかに基づいて、プリンタのタイプを判定し得る。

＜カスタムされた手荷物タグ及び搭乗券などの従来の装置に使用されるフィールドゲートウェイ＞

フィールドゲートウェイ、装置証明書、ロケーションＩＤ、及び装置ラベルの組み合わせにより、共有装置１０８の１つを一意に選択できる。

以下では、例えば搭乗券又は手荷物タグプリンタなどの特定の装置を、ロケーションＩＤ及び装置ラベル（ＬｏｃａｔｉｏｎＩＤ．Ｄｅｖｉｃｅ＿Ｌａｂｅｌ）を使用して一意に識別する方法について詳しく説明する。これは、共有インフラストラクチャ又は装置へのアクセスを提供するためのシステム、方法、及び装置との互換性が必要な場合がある、古い従来のプリンタ又は装置に特定の用途がある。

この例では、図面の図１にＦＧとして示されているフィールドゲートウェイ機能は、図面の図１に示されている共有装置１０８の１つであるか、或いはそれに結合されているワークステーションにインストールされ得るモジュール又はＡＰＩを含んでいてもよい。

構成中に、適切な資格情報を持つ職員は、通常はワークステーション上の、ポータルを起動する。ワークステーションは、有線又は無線通信プロトコルを介してＡＰＩ環境１０３と通信可能に結合されている。データベース１０４から取得された可能なロケーション識別子のリストは、ポータルに通信される。リストは、通常、ロケーション識別子の要求に応じて返信される。通常、ロケーション識別子は特定のリージョン、エリア、又はより具体的には特定の空港内のゾーンに関連付けられている。

次に、ユーザは、現在のロケーションに一致する特定のロケーション識別子を選択する。例えば、ロケーション識別子「ＭＵＭ−Ｔ１−ＳＢＤ−００１」は、ムンバイ空港、ターミナル１、セルフ手荷物ドロップエリア００１に関連付けられているとユーザに認識される。

ロケーション識別子の別の例は、「ＪＦＫ−Ｔ１−ＧＡＴＥ１−ＷＫＳ−００１」であり、これは、米国の空港であるジョンＦケネディ、ターミナル１、ゲート１、ワークステーション００１に関連付けられているとユーザに認識され得る。

あるいは、ユーザは、ワークステーション及び関連付けられた共有装置１０８が配置されているロケーションに近接して配置されたビーコン１１０をスキャンしてもよい。

装置ラベルは、装置がクレジットカード又はポイントカードの読み取りに使用される磁気スワイプリーダーであることを示す「ＭＳＲ」の形式を取り得る。他の装置タイプ又はラベルは、装置が手荷物タグプリンタ又は搭乗券プリンタであることを示すＢＴＰであってもよく、前述のとおり、装置が搭乗券プリンタであることを示すＡＴＰ（自動発券及び搭乗プリンタ）と呼ばれる。

次に、選択されたロケーション識別子は、ＡＰＩ環境１０３に通信される。次いで、ＡＰＩ環境は、以下のフィールドのうちのいずれか１つ以上を含み得る初期化ファイルを生成する。

初期化ファイルは、ＰＧＰ署名を使用して暗号化され、Ａｚｕｒｅ Ｂｌｏｂストレージコンテナ（「ＦＧＩｎｉｔＦｉｌｅ」コンテナ）又はストレージ手段又はデータベース１０４の下に格納される。このコンテナの下に、各ロケーション［’ＦＧＩｎｉｔＦｉｌｅ＿＜ＬｏｃａｔｉｏｎＩＤ＞．ｌｃｋ’］のサブコンテナがあってもよい。このファイルは、通常、４時間の有効期限を持つＳＡＳトークンで保存及びアクセスされる。

その後、ユーザは初期化ファイルをダウンロードすることを求められる。初期化ファイルは、通常、ＵＳＢドライブに手動でコピーされる。これは、トークンの有効期限が切れる前に行われる必要がある。

起動後、フィールドゲートウェイコンポーネントは「ＦＧＩｎｉｔＦｉｌｅ＿＊．＊．ｌｃｋ」という名前の初期化ファイルを検索する。フィールドゲートウェイコンポーネントが初期化ファイルを正常に見つけると、それぞれの共有装置１０８、又はワークステーションで実行されているサービスのセキュリティ証明書を取得するＡＰＩ環境１０３の一部であるロケーションサービスに要求を送信する。

セキュリティ証明書を取得するために、フィールドゲートウェイコンポーネント又はサービスは、ＡＰＩ環境１０３の一部であり得るロケーション構成サービスを呼び出して、証明書を取得する。

ロケーションサービスは、セキュリティ証明書の要求を受信すると、トークンを検証する（例えば、トークンが有効で期限切れになっていないことを確認する）。ロケーションサービスは、ロケーションＩＤを検証してもよく、言い換えると、受信されたロケーションＩＤが、データベース１０４に保存された、以前に保存されたロケーションＩＤの１つに対応することを確認することもできる。

通常、トークンとロケーションＩＤの両方が有効な場合、ロケーション構成サービスは、認証局サーバに接続してセキュリティ証明書を取得する。その後、ロケーションサービスは公開キーをフィールドゲートウェイコンポーネントに送信する。

ワークステーションに証明書がインストールされると、フィールドゲートウェイコンポーネントは証明書登録ＡＰＩを呼び出して、この証明書をアクティブディレクトリ又はデータベースに追加する。初期化ファイルをダウンロードして証明書を取得する前述したプロセスは、ワークステーションに接続された各ワークステーションサービス又は共有装置に対して実行され得る。

ＦＧに証明書がインストールされると、それは、構成サービス「ＧｅｔＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ」を呼び出して装置構成を取得する。装置構成には、最初はＩｏＴと通信するためのワークステーション装置ＩＤとそのキーのみを有し、装置のステータスが「未構成」状態にあるため、他の装置の詳細は有さない。

通常、ファイルゲートウェイ機能は、構成サービスへの今後の呼び出しのために、「ＬｏｃａｔｉｏｎＩＤ」をメモリにローカルに格納又はキャッシュする。

前述のとおり、ワークステーション（及びワークステーションに接続された関連付けられた共有装置１０８）のロケーション識別子及び装置ラベルが、特定の共有装置を一意に識別するために使用され得ることは理解されよう。したがって、これを使用して、ロケーションに基づいて特定の印刷要求が送信される装置を判定することができる。

いくつかの実装形態では、手荷物タグプリンタ又は搭乗券プリンタなどの共有装置は、ワークステーションの特定のポートに関連付けられてもよい。例えば、搭乗券プリンタは「ポート１」に関連付けられ、手荷物タグプリンタは「ポート２」に関連付けられてもよい。ある実装では、特定の装置タイプは、常に特定のポート番号に関連付けられる。例えば、搭乗券プリンタは常にポート１に関連付けられ、手荷物タグプリンタは常にポート２に関連付けられてもよい。

したがって、共有装置は、メッセージングプロトコルＭＱテレメトリー・トランスポート又はメッセージ・キュー・テレメトリー・トランスポート（ＭＱＴＴ）などのＩｏＴプロトコルでプラットフォームと対話することを理解されたい。これを、インターネットベースのインターフェース及びハイレベルのメッセージングプロトコルを持たない既存の従来の装置で実現するために、フィールドゲートウェイとインターフェースされる。フィールドゲートウェイは装置レベルの機能を実装し、プラットフォームとの複雑なセキュリティのインタラクションを管理し、暗号化されたトークンを取得して装置通信に適用することにより、検証済み装置がやり取りをできるようにする。フィールドゲートウェイは、また、装置データに基づいていくつかのローカルアクションを実行し、所定の構成に基づいて高速なエクスペリエンスを提供する。

前述のとおり、モバイル通信又はモバイル装置には、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯情報端末、携帯電話、スマートフォン、インターネット対応テレビ、インターネット対応のテレビ受信機、インターネット対応のゲームコンソール、又はポータブルゲーム装置などのコンピューティング装置が含まれることは理解されよう。

また、本発明は、ユーザ又は顧客を処理するシステム、顧客を処理する職員が使用するポータブル装置などの装置、又は乗客が使用するポータブル装置などの装置、並びに顧客又は乗客を処理するための方法又はコンピュータプログラムとしての用途を見出すことも理解されよう。加えて、本発明は、航空会社の職員又は他の輸送サービス提供業者の職員によって使用され得る、顧客又はユーザにサービスを提供するシステムとしての用途を見出す。

サーバは、クライアント装置と通信するための、１つ以上のサーバプロセスを実行するコンピュータプロセッサを備えてもよい。サーバプロセスは、本発明の動作を実行するためのコンピュータ可読プログラム命令を含む。コンピュータ可読プログラム命令は、Ｃなどの手続き型プログラミング言語、Ｃ＃、Ｃ＋＋、Ｊａｖａなどのオブジェクト指向プログラミング言語、スクリプト言語、アセンブリ言語、機械コード命令、命令セットアーキテクチャ（ＩＳＡ）命令、及び状態設定データなどの、適切なプログラミング言語で記述されたソースコード又はオブジェクトコードであってもよい。

前述の有線又は無線の通信ネットワークは、パブリック、プライベート、有線又は無線のネットワークである。通信ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット、携帯電話通信システム、又は衛星通信システムのうちの１つ以上を含み得る。通信ネットワークは、銅ケーブル、光ケーブル又はファイバー、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ及びエッジサーバなど、適切なインフラストラクチャを含んでいてもよい。

前述のシステムは、グラフィカルユーザインターフェースを備えてもよい。

本発明の実施形態は、画面上のグラフィカルユーザインターフェースを含んでいてもよい。ユーザインターフェースは、例えば、Ｗｅｂサイトに埋め込まれたウィジェットの形で、装置のアプリケーションとして、又は専用のランディングＷｅｂページに提供されてもよい。グラフィカルユーザインターフェースを実装するためのコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体から、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）及び／又は無線ネットワークなどのネットワークを介して、クライアント装置にダウンロードされてもよい。命令は、クライアント装置内のコンピュータ可読記憶媒体に保存されてもよい。

当業者によって理解されるように、本明細書に記載される本発明は、方法、データ処理システム、又はコンピュータ可読命令を含むコンピュータプログラム製品として全体的又は部分的に具体化され得る。したがって、本発明は、完全にハードウェアの実施形態、又はソフトウェア、ハードウェア及び任意の他の適切なアプローチ又は装置を組み合わせた実施形態の形をとることができる。

コンピュータ可読プログラム命令は、非一時的な、有形のコンピュータ可読媒体に保存されてもよい。コンピュータ可読記憶媒体は、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、イレーサブルプログラマブルリードオンリーメモリ（ＥＰＲＯＭ又はフラッシュメモリ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）、メモリースティック、フロッピーディスクの１つ以上を含んでいてもよい。

本発明の例示的な実施形態は、ＣＰＵ、バス、ＲＡＭ、フラッシュメモリ、或いはプリンタ、ディスプレイ、キーパッド、センサ及びカメラ、ＲＯＭなどの接続されたＩ／Ｏ装置の動作のための１つ以上のポート、モデムなどの通信サブシステム、及び通信メディアを含み得る回路基板として実装されてもよい。

図３のフローチャートは、本発明の様々な実施形態によるシステム、方法、及びコンピュータプログラム製品の例示的な実装の動作を示している。フローチャート又はブロック図の各ブロックは、ブロックで指定された論理機能を実装するための１つ以上の実行可能なコンピュータ命令又は命令の一部を含むモジュールを表している。ダイアグラム内のブロックの順序は、例示のみを目的としている。代替の実装では、特定のブロックに示されている論理機能は、図に示されている順序以外で発生する場合がある。例えば、互いに隣接するように示された２つのブロックは、同時に実行される場合と、機能に応じて逆の順序で実行される場合がある。フローチャートの各ブロックはソフトウェアで実装され得るが、ハードウェア又はソフトウェア及びハードウェアの組み合わせで実装されてもよい。

Claims (29)

1. １つ以上の装置（１０８）へのユーザアクセスを提供するデータ処理システムであって、
   ｉ）ユーザのロケーション識別子を判定し、
   ｉｉ）前記ロケーション識別子を前記ユーザのユーザ識別子に関連付け、そして、
   ｉｉｉ）前記ロケーション識別子及び関連付けられたユーザ識別子をアプリケーション（３０１）に通信（３０１３）する、
   ように構成されている、処理手段（１０３）を備える、システム。
2. 前記処理手段（１０３）は、前記ユーザに関連付けられたユーザログインイベントメッセージ（３０１２）を受信するように更に構成されている、請求項１に記載のシステム。
3. 前記処理手段（１０３）は、前記ユーザのユーザセッション識別子を生成するように更に構成されており、前記ユーザセッション識別子は、好ましくは、ユーザログインイベントに関連付けられている、請求項１又は２に記載のシステム。
4. 前記処理手段（１０３）は、１つ以上のメッセージ又はデータを送信又は受信するための送信手段又は受信手段に通信可能に結合されている、請求項１から３のいずれか一項に記載のシステム。
5. 前記処理手段（１０３）は、好ましくは、ユーザログインメッセージ（３０１２）の受信に応答して、ログインイベントメッセージ（３０１３）を生成するように更に構成されている、請求項１から４のいずれか一項に記載のシステム。
6. 前記処理手段（１０３）は、前記ユーザログインイベントメッセージを前記アプリケーション（３０１）に送信するように更に構成されている、請求項５に記載のシステム。
7. 前記ロケーション識別子は、英数字の文字列を含む、請求項１から６のいずれか一項に記載のシステム。
8. 前記ロケーション識別子は、機械可読及び人間可読である、請求項１から７のいずれか一項に記載のシステム。
9. 前記ロケーション識別子は、前記１つ以上の装置に関連付けられた所定のエリアを定義する、請求項１から８のいずれか一項に記載のシステム。
10. 前記ロケーション識別子は、交通ハブ、特に空港に関連付けられている、請求項１から９のいずれか一項に記載のシステム。
11. 前記ロケーション識別子は、所定のエリア又はリージョン内の任意の位置におけるロケーションを定義する、請求項１から１０のいずれか一項に記載のシステム。
12. 前記ロケーション識別子は、階層構造によって前記装置のロケーションを定義する、請求項１から１１のいずれか一項に記載のシステム。
13. 前記ロケーション識別子は、複数の異なるリージョン内の前記装置のロケーションのそれぞれを定義し、好ましくは、前記異なるリージョンの少なくともいくつかは、他のリージョンの１つ以上に含まれる、サブリージョンを定義し、更に好ましくは、サブリージョンのそれぞれは、前記１つ以上のリージョンの一部分又は一部を規定する、請求項１から１２のいずれか一項に記載のシステム。
14. 前記ユーザによる要求に応じて、前記装置（１０８）のうちの１つによって処理されるデータを定義する第１のデータを含むメッセージ（３１００）を受信するためのアプリケーション（１０１、１１１）を更に含み、好ましくは、前記第１のデータは、前記ユーザ又は更なるユーザに関連付けられたロケーション識別子を含む、請求項１から１３のいずれか一項に記載のシステム。
15. 前記第１のデータは、前記ロケーション識別子に関連付けられた装置ラベルのいずれか１つ以上を更に含み、好ましくは、前記第１のデータは、前記装置ラベルと連結されている、前記ロケーション識別子又は更なるロケーション識別子を含み、好ましくは、前記第１のデータは、ユーザセッション識別子に関連付けられている、請求項１４に記載のシステム。
16. 前記第１のデータは、前記装置（１０８）の１つによって処理されるドキュメントを定義するデータを含み、好ましくは、前記第１のデータは、前記ユーザ又は更なるユーザに関連付けられたロケーション識別子を含む、請求項１から１５のいずれか一項に記載のシステム。
17. 前記第１のデータは、搭乗券又は手荷物タグを定義するデータを含む、請求項１から１６のいずれか一項に記載のシステム。
18. 前記アプリケーション（１０１、１１１）は、前記第１のデータの少なくともいくつかを処理するための更なるメッセージ（３１１０）を生成するように構成されている、請求項１から１７のいずれか一項に記載のシステム。
19. 前記更なるメッセージ（３１１０）は、搭乗券又は手荷物タグなどのドキュメントを印刷又は処理するためのデータを含み、好ましくは、搭乗券又は手荷物タグを印刷するための前記データは、ポータブルドキュメントファイルフォーマットに従って前記更なるメッセージ（３１１０）内に符号化され、更に好ましくは、前記更なるメッセージ（３１１０）は、フライト番号、出発日、クラス、出発地、目的地、出発ゲート、座席番号、乗客名、座席番号、一意の手荷物識別子、及び出発地と目的地との間の経由地のいずれか１つ以上を定義するデータを含む、搭乗券又は手荷物タグに関連付けられたデータを含み、好ましくは、前記メッセージには搭乗券又は手荷物タグに関連付けられたフォーマットの定義が含まれる、請求項１８に記載のシステム。
20. 前記処理手段（１０３）は、第１の通信チャネル（１２４）及び第２の通信チャネル（１２５）に通信可能に結合され、好ましくは、前記第１の通信チャネル（１２４）は、前記ロケーション識別子を使用して、前記第２の通信チャネルに、リンク又は関連付けられる、請求項１から１９のいずれか一項に記載のシステム。
21. 処理されるドキュメントを定義するデータのみが第１の通信チャネル（１２４）で通信され、好ましくは１つ以上の装置（１０８）に関連付けられた装置機能を定義するデータのみが前記第２の通信チャネル（１２５）で通信される、請求項２０に記載のシステム。
22. 前記処理手段（１０３）は、第３の通信チャネル（１２１、１２２）及び第４の通信チャネル（１２３）に通信可能に結合され、好ましくは、前記第３の通信チャネル（１２４）は、前記ロケーション識別子を使用して、前記第４の通信チャネルに、リンク又は関連付けられる、請求項１から２１のいずれか一項に記載のシステム。
23. 処理されるドキュメントを定義するデータのみが前記第３の通信チャネル（１２１、１２２）で通信され、好ましくは１つ以上の装置（１０８）に関連付けられた装置機能を定義するデータのみが前記第４の通信チャネル（１２３）で通信される、請求項２２に記載のシステム。
24. 前記ロケーション識別子と前記装置に関連付けられた装置ラベルに基づいて、複数の装置（１０８）のうちの１つを一意に識別するためのフィールドゲートウェイモジュール（ＦＧ）又はアプリケーションを更に備え、好ましくは、前記ロケーション識別子及び装置ラベルは、前記メッセージ（３１００）内の連結フィールド内で提供される、請求項１から２３のいずれか一項に記載のシステム。
25. 各装置に関連付けられた一意の装置識別子に基づいて、複数の装置（１０８）のうちのどれがメッセージ（３１１０）を送信するかを一意に判定するモジュール又はアプリケーション（１１７、１１８）を更に含む、請求項１から２４のいずれか一項に記載のシステム。
26. 前記データ又はドキュメントを処理するための１つ以上の装置（１０８）を更に備え、好ましくは、前記ドキュメントは搭乗券又は手荷物タグであって、好ましくは、前記１つ以上の装置（１０８）は更に前記データ又はドキュメントを印刷又は読み取る、請求項１から２５のいずれか一項に記載のシステム。
27. １つ以上の装置（１０８）へのユーザアクセスを提供するためのデータ処理方法であって、
    好ましくはコンピュータプロセッサ上で実行され、
    ｉ）ユーザのロケーション識別子を判定するステップと、
    ｉｉ）前記ロケーション識別子を前記ユーザのユーザ識別子に関連付けるステップと、そして
    ｉｉｉ）前記ロケーション識別子及び関連付けられたユーザ識別子をアプリケーション（３０１）に通信する（３０１３）ステップと、
    を含む、データ処理方法。
28. 請求項２から２６のいずれか一項に記載のステップを実行するステップを更に含む、請求項２７に記載のデータ処理方法。
29. 実行されると、請求項２７又は２８に記載の方法を実行する、コンピュータプログラム製品。