JP2020522770A - 乗客またはユーザ情報を提供するためのシステム、デバイス、および方法 - Google Patents

Abstract

デバイスに関連付けられたデータベースへのアクセスの許可または拒否を決定するためのコンピュータ処理デバイス（１１９、１２１、１２３、１３１、１３３、１３５）が提供される。デバイスは、キーを、前記データベースまたは更なるデータベースに格納されている１つ以上のキーと比較することによって、第１のキー（１２５）により署名されたデータの出所を決定して、データのソースを特定し、データベースを検索して、データのソースに関連付けられた１つ以上のアクセスルールであって、そのデータについてのデータベースへの書き込みアクセスの許可または拒否を規定するアクセスルールを決定し、決定されたルールに基づいて、データベースへの書き込みアクセスを許可または拒否するように構成されている。【選択図】図１

Description

本発明は、乗客またはユーザの情報またはデータを提供するためのシステム、装置、方法またはコンピュータプログラムに関する。より具体的には、本発明は、いくつかの異なるソースからのデータを集約するためのシステム、デバイス、および方法に関する。この情報は、通常、乗客、警備員、航空会社職員、または空港あるいは鉄道駅やバスの停留所等のその他の交通結節点におけるその他の職員に提供される。

航空輸送業界では、フライトのステータスは常に流動的であり、フライトのステータスを正確に特定するには複数のデータソースが必要である。フライトのステータスには、
−出発／到着予定時刻
−予測および実際の出発／到着時刻
−空港の出発ゲートおよびターミナル
−空港の到着ゲートおよびターミナル
−到着空港の手荷物受け取りターンテーブル番号
−「ＤＥＬＡＹＥＤ」、「ＧＯ ＴＯ ＧＡＴＥ」、「ＢＯＡＲＤＩＮＧ」、「ＣＬＯＳＩＮＧ」等、空港の画面表示に表示される英数字データ
−航空機タイプおよびテールナンバー
が含まれ得る。

空港Ａから空港Ｂに行くどのフライトについても、このデータの一部は航空会社によってのみ提供され、このデータの一部は空港Ａによってのみ提供され、このデータの一部は空港Ｂによってのみ提供される。これに加えて、航空交通管制等の他の機関がこのデータの更新に関与し得る。

通常、各航空会社および各空港は、運航データに関する独自のデータベースを有している。これらは常に一貫しているとは限らず、結果的に一貫性のないデータをもたらし、「唯一の真実（ｓｉｎｇｌｅ ｖｅｒｓｉｏｎ ｏｆ ｔｈｅ ｔｒｕｔｈ）」は存在しない。全フライトの全データの単一の一貫したビューを有することが業界にとって重要である。これなしでは、空港運営や航空会社運営の管理時、および顧客とのコミュニケーション時に混乱が生じる。

本発明は、参照すべき添付の特許請求の範囲に定義されている。

本発明の実施形態は、デバイスに関連付けられたデータベースまたは格納手段へのアクセスの許可または拒否を決定するためのコンピュータ処理デバイスを提供することにより、上記の問題に対処しようとするものであり、デバイスは、特定のステータス情報のデータを受信するための受信手段を含み、データはキーにより署名されている。デバイスは、このキーを、データベースまたは格納手段に格納されている１つ以上のキーと比較することによって、データの出所を決定してデータのソースを特定し、データベースまたは格納手段を検索して、データのソースに関連付けられた１つ以上のアクセスルールを決定するための手段を含むか、または、そのように構成される。ここでは、アクセスルールにより、そのデータについてのデータベースまたは格納手段への書き込みアクセスの許可または拒否を規定する。デバイスは、決定された１つ以上のルールに基づいて、データベースまたは格納手段への書き込みアクセスを許可または拒否することが好ましい。通常、受信手段は受信機である。

本発明の実施形態は、出発地Ａと目的地Ｂとの間の旅行に関連するステータス情報を決定するためのコンピュータ処理デバイスを提供することにより、上記の問題に対処しようとする。デバイスは、セキュリティキーを決定し、データのソース、出発地、または目的地に関連付けられた第１のステータス情報を受信するように構成された第１のアダプタを含む。出発地は、例えばロンドンのヒースロー（ＬＨＲ）等の空港である一方、目的地は、例えばマイアミ国際空港等の空港であり得る。

本発明の実施形態は、第１のデータソースに関連する第１のデータセットであって、複数の異なる第１のデータ要素を含む第１のデータセットから、第１のデータソースに関連する第１のユニークキーを決定し、第２のデータソースに関連する第２のデータセットであって、複数の異なる第２のデータ要素を含む第２のデータセットから、第２のデータソースに関連する第２のユニークキーを決定するように構成された処理手段を含むデータ処理のためのシステムを提供することにより、上記の問題に対処しようとするものである。ここで、第１のデータセットおよび第２のデータセットは、少なくとも１つの共通データ要素を共有しており、第１のデータ要素の少なくとも一部は第２のデータ要素とは異なる。好ましくは、第１のデータソースおよび第２のデータソースは、キーに基づいて確認される。より好ましくは、各データソースがデータのソースとして確認された場合、システムは、第１のデータセットと第２のデータセットとを集約データセットに結合する。

本発明の実施形態は、データベースからデータを検索し、そのデータはユニークキーによって識別される。データベース内のデータは、１つ以上の書き込み許可ルールに基づいてアップデートされ得る。通常、ステータス情報が出発空港あるいは到着空港または航空会社から発信されたか否か、またはそれらに関連付けられているか否かに基づいて、異なるルールが提供される。各アダプタは、プライベートキーでデータに署名するコードを含むスマートコントラクトを実行するノードまたは処理デバイスにデータをプッシュすることができる。

本発明の実施形態は、全フライトに関する全データを集約し、この時折対立するデータをフライトごとに単一のデータセットに合理化し、これを分散型台帳技術（ＤＬＴ）に格納する、業界の中心的なフライト情報サービスを提供する。システム内の全ての参加者は、ＤＬＴのノードを操作することができる故、システム上に正確なデータを継続的に複製することができる。

これは、単一の空港中心のビューだけでなく、信頼できるソースからのフライト情報のビューも含む、フライトの完全な視野を提供するという利点を有する。また、スマートコントラクトを使用してデータをマージし、ＤＬＴを使用してデータを分散することにより、システム上の全てのユーザが同じ情報を見ていることを確信することができる。

次に、本発明の実施形態を、単なる例示として、添付の図面を参照して説明する。

本発明を実施する主要な機能コンポーネントの概略図である。 例示的なステータス情報およびデータのソースを示す説明図である。 例示的なステータス情報およびデータのソースを示す説明図である。 例示的なステータス情報およびデータのソースを示す説明図である。 例示的なステータス情報およびデータのソースを示す説明図である。 例示的なステータス情報およびデータのソースを示す説明図である。 例示的なステータス情報およびデータのソースを示す説明図である。 本発明の一実施形態によって実行されるステップを示すフロー図である。 本発明の更なる実施形態によって実行されるステップを示すフロー図である。

以下の説明は、航空産業で使用するためのシステムに関するが、これは例示的なものであり、本発明の他の用途についても検討する。例えば、本システムは、鉄道、コーチ、自動車等の他の旅行業界、またはいくつかの異なるソースからの情報を集約する必要がある環境にて使用され得る。

更に、説明される以下の実施形態は、例えばＯｐｅｎＣＶライブラリを使用するＣ＋＋プログラミング言語を使用して実施されてもよい。しかしながら、これは例示的なものであり、ＪＡＶＡや．ｘｍｌ等、当業者に公知の他のプログラミング言語を使用することもできる。

図１に戻ると、通常、図１のラベル１００内に示されている機能コンポーネントは、仮想プライベートクラウド内にて具現化される。クラウドへのアクセスは、ユーザ名およびパスワードで保護されている。通常、クラウドは１台以上のコンピュータまたはサーバ上に提供される。本発明の機能的態様を実施することができるクラウドの特定の一例として、Ａｍａｚｏｎ（商標）のＷｅｂ Ｓｅｒｖｉｃｅｓ ｃｌｏｕｄまたはＶｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｃｌｏｕｄが挙げられる。ここでは、異なるＩＰアドレス範囲を選択し、サブネットを作成し、ルートテーブルやネットワークゲートウェイを構成することができる。

システムは、１つ以上のアダプタ１０１、１０３、１０５のうちの任意の１つ以上を備えることができる。各アダプタ１０１、１０３、１０５は、各データベース１０７、１０９、１１１に通信可能に連結される。通常、各アダプタは、定期的に、例えば毎分、データベースのうちの１つをポーリングする。あるいは、データベースは各アダプタ１０１、１０３、１０５にデータをプッシュする。

通常、各データベースへのアクセスは、ＡＰＩセキュリティキー１０２、１０４、１０６等のキーによって提供される。通常、キー１０２、１０４、および１０６は同じキーであるが、原則的にこれらは異なってもよい。通常、１０１等の各アダプタのデータベース１０７への結合は、ＨＴＴＰＳ等の、当業者に公知の有線または無線通信手段１１３、１１５、１１７を介して行われる。

更に、各アダプタ１０１、１０３、１０５は、分散型台帳技術（ＤＬＴ）ノード１１９、１２１、１２３に通信可能に結合される。ここでもまた、アダプタ１０１等の各アダプタの各ＤＬＴノードへの結合は、一般的には、当業者に公知の有線または無線通信手段を介して行われる。通常、各ノード１１９、１２１、１２３へのアクセスは、各キー１２５、１２７、１２９によって保護されている。キー１２５、１２７、１２９は、公開暗号化キーまたは秘密暗号化キーのいずれかである。通常、キー１２５、１２７、１２９はそれぞれ異なり、それぞれを特定の航空会社または空港に関連付けることができる。各キーにより、特定の航空会社または空港、または、換言するとデータのソースを一意に識別および／または確認することができる。このようにして、各データソースは本物であると判断されるか、または認証される。図１の矢印１５１、１５３、１５５は、各ピアまたはノード１１９、１２１、１２３と各アダプタ１０１、１０３、１０５との間の有線または無線通信チャネルを表す概略的な矢印である。これは、ハイパーテキストトランスファープロトコルセキュア（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）（ＨＴＴＰＳ）に従い得る。

フライト情報、ＦＬＩＦＯ、データ構造
フライトステータスに対するデータ要素は十分に確立されており、利用可能な多様な標準が存在する。本発明の実施形態は、ＡＣＩＴ（商標）、ＩＡＴＡ（商標）、およびＳＩＴＡ（商標）等の団体によって合意された標準であるＡＣＲＩＳ(商標)Ｓｅａｍｌｅｓｓ Ｔｒａｖｅｌデータ標準を使用することができる。

この標準は、以下に列挙されている要素のうちの任意の１つ以上を含むことができ、この情報にアップデートを送信することができるエンティティごとに分類される。通常、このデータは、構文要素またはデータ型を定義するフィールドを有する英数字形式と、一般的には英数字形式または文字列の関連値とである。
・航空会社データ（航空会社のみが定義可能なデータ）
・運航航空会社
・運航便名
・マーケティング航空会社
・マーケティング便名
・出発空港
・到着空港
・出発／到着予定時刻
・空港データ（空港のみが決定可能なデータ）
・出発ゲート
・到着ゲート
・チェックインデスク
・手荷物受け取りターンテーブル
・ＦＩＤＳ表示テキスト（ＢＯＡＲＤＩＮＧ、ＣＬＯＳＩＮＧ、ＧＯ ＴＯ ＧＡＴＥ、ＷＡＩＴ ＩＮ ＬＯＵＮＧＥ等）
・航空会社／空港データ（航空会社と空港との両方が決定可能なデータ要素）
・予測される出発／到着時刻
・実際の出発／到着時間

これらのデータ要素の一部は、図面の図２〜図７に示されている。

ＦＬＩＦＯイベント
これらは、フライトのライフサイクル中のイベントの一部であり、フライト情報データに影響を与え得る。
・航空会社によるスケジュールの公開
・出発空港によるチェックインデスクおよび出発ゲートの割り当て
・到着空港による到着ゲートおよび手荷物受け取りターンテーブルの割り当て

更に、以下のイベントの任意の組み合わせは、フライト情報に影響し得る。
・乗務員がフライトに遅刻している、または病気であり交代要員の乗組員が必要である
・乗客の搭乗が遅延しており、荷物を降ろす必要がある
・出発空港または到着空港が混雑している
・到着時にゲートが利用不能である
・航空交通管制がフライトを遅延させる

これは、フライトステータスの更新をトリガーし得るイベントの種類のほんの一例であり、フライトステータスデータはフライトの全期間を通じて継続的に更新可能である点に留意することが重要である。

システム運用
次に、本発明の実施形態を、図面の図１のアーキテクチャ図並びに図８および図９のフローチャートを参照して説明する。

図１の概略図では、ＡＯＤＢシステム（空港／航空会社オペレーションデータベース）は、各航空会社／空港に既知のフライト情報を含む。更に、アダプタ１０１、１０３、１０５は、信頼できる空港および航空会社のシステムを分散型台帳技術に接続する役割を果たし得る。これらは、多くの場合「Ａｎ Ｏｒａｃｌｅ」として知られており、ＤＬＴに保存される正式な信頼できる情報源である。

パブリックまたはプライベート（例えば、ユーザ名およびパスワードを使用してアクセスを許可する）ＤＬＴまたはブロックチェーンを使用して、デジタル記録を保存し（スキャンされたバッグタグ等）、デジタルアセットを移送し（フライトの移送やバッグの移送等）、かつ、スマートコントラクト（ＷＴＲレコード、ＰＡＸへの支払い、または航空会社への請求）を実行することができる。

このデータは、ＤＬＴで実行されるスマートコントラクトを介して集約され得る。データは既存のデータにマージされ（データが既に存在する場合）、ブロックチェーン上の全てのノードにわたって複製される。トークン（またはクレジット）は、更新をシステムにプッシュする参加航空会社／空港ごとに生成される。

データ収集
第１または第２または第３のアダプタは、第１のステータス情報、または第２のステータス情報、または第３のステータス情報に関連する１つ以上の構文要素を読み取るように構成される。通常、ステータス情報は第１の形式に従って構成され、アダプタは構文要素を第１の形式とは異なる第２の形式にマッピングまたは解析する。

通常、各アダプタは航空会社または空港のデータソースに固有である。通常、アダプタが呼び出す各データソースは、異なるエンドポイント、異なるデータ形式、およびサービスを呼び出すための異なるメカニズムを有する。通常、アダプタは、航空会社または空港のデータソースに特定の呼び出しを行うように構成されている。アダプタは、このデータソースからのデータを解析し、標準のＡＣＲＩＳ ｊｓｏｎデータ形式に変換することもできる。

例えば、ＬＨＲアダプタは、ＨＴＴＰＳを介してＬＨＲエンドポイントにＳＯＡＰ ＸＭＬ Ｗｅｂサービスコールを行うことができる。ＷｅｂサービスコールはＡＰＩキートークンによって保護されており、このトークンは、通常、サービスコールの一部として追加される。ＬＨＲサービスは、１つ以上のフライトに関連付けられた情報をＸＭＬ形式で返す。通常、ＬＨＲアダプタは、このＸＭＬデータをＡＣＲＩＳ標準データ形式に変換する。次に、ブロックチェーン上のスマートコントラクトによりＬＨＲがこのデータのソースであることを確認することができるように、アダプタはＬＨＲキーでデータにスタンプする。各アダプタは、航空会社または空港を識別する固有のキーを有する。

固有の旅行の識別子
出発地から、または目的地まで運航される特定の数のフライトに応じて、次のフィールドのうち任意の１つ以上を追加することで、フライトを一意に識別することができる。
・構文要素「ｏｒｉｇｉｎＤａｔｅ」で表すことができる、出発予定日
・構文要素「ｄｅｐａｒｔｕｒｅＡｉｒｐｏｒｔ」で表すことができる、出発空港
・構文要素「ｏｐｅｒａｔｉｎｇＡｉｒｌｉｎｅ．ｉａｔａＣｏｄｅ」で表すことができる、運航航空会社
・構文要素「ｆｌｉｇｈｔＮｕｍｂｅｒ．ｔｒａｃｋＮｕｍｂｅｒ」で表すことができる、運航便名

例えば、識別子「２０１７−０４−０１ＬＨＲＢＡ０１２２」は、ＬＨＲから２０１７−０４−０１に出発するＢＡフライト１２２を識別する。更なる例では、英数字文字列「２０１７−０５−０５ＬＨＲＢＡ０７３４」は、２０１７年５月５日にロンドンのヒースロー空港から出発し、ブリティッシュエアウェイズが運航する便名０７３４を一意に識別することができる。従って、キーは、出発空港または旅行の出発地を定義するデータ、好ましくは旅行に関連する出発日を定義するデータ、更に好ましくは旅行のオペレータまたはプロバイダ並びにオプションの便名または旅行番号を定義するデータによって定義することができる。

これは、フライトのユニークキーとして知られているが、ユニークキーは図１には示されていない。アダプタ１０１、１０３、１０５のうちの１つがフライトをブロックチェーンにプッシュすると、本発明の実施形態は、コンピュータ、サーバまたはシステムに機能を提供することで、フライトのユニークキーを生成し、一致するフライトのブロックチェーンを検索する。この機能は、図１に示す機能コンポーネントのいずれかによって実施され得る。フライトが存在しない場合、ＡＣＲＩＳデータはそのままブロックチェーンに公開され、新しいフライトレコードが作成される。フライトが存在する場合、フライトデータはブロックチェーンから取得され、データマージプロセスが開始される。

マージプロセスの説明
前述したように、システム内の各エンティティ（航空会社、出発空港、到着空港）は、単一のビューに結合する必要がある、各ソースからのデータおよび情報の部分的なビューのみを有する。いくつかの例として、以下が挙げられる。
−航空会社は最初にフライトスケジュールを公開する。これは、出発／到着空港、出発および到着予定時刻、並びに便名等の基本情報を含む。
−出発時刻が近づくと（一般的には２４時間以内）、出発空港はチェックインデスクおよび出発ゲートを割り当てる。到着空港は、到着ゲートおよび手荷物受け取りターンテーブル情報も割り当てる。
−フライトが存在している間、この情報には多くの更新があり、両方の空港および航空会社（および航空管制ストライキ等の外的なソース）内での運航に関するイベントの変化を反映する。

本発明を実施するコンピュータ、サーバ、またはシステムは、スマートコントラクトにおいて、これらの異なるソースからの部分データを単一の信頼できるフライト情報データセットに結合することができる。システムは、通常、スマートコントラクトのルールが適用され、無効な更新を排除し、競合する可能性のある更新間の調停を行う。無効な更新の例として、航空会社が運航していないフライトのフライトステータスを更新しようと試みる場合が挙げられる。例えば、ブリティッシュエアウェイズは、ライアンエアフライトのフライト情報を更新することはできない。

別の例として、空港がその空港を通過しないフライトのデータを更新しようと試みる場合が挙げられる。ヒースローからダブリン空港へのフライトでは、アムステルダム空港はその特定のフライトの更新を送信することができない。本発明を実施するコンピュータ、サーバ、またはシステムは、スマートコントラクト機能がこれらの更新を識別し、必要に応じてブロックチェーンに書き込まれるのを防ぐ機能を実装してもよい。

調停を必要とする他のデータ更新が存在する。これは、競合する更新がフライトのデータを更新する資格のあるエンティティから来る場合に生じる。例えば、航空会社および空港は、予測出発時刻の更新が競合するサイクルに陥る可能性があり、この場合、スマートコントラクト機能により、どれが正しく、どれを信頼できる更新としてＤＬＴに書き込むべきかを決定する。本発明の実施形態は、これに対して以下の機能的解決策を提供し得る。
−ラストイン（Ｌａｓｔ ｉｎ）が信頼できる。これは、正確性を判断しようとせず、最新の更新が最も信頼できると単純に判断するアルゴリズムである。
−重み付き権限。このアルゴリズムは、ソースに応じて、いくつかのフィールドにより高い重みを付ける。例えば、空港によるゲート情報の更新は、同じ情報に対する航空会社の更新よりも優先される。

コンピュータ処理デバイスに実装されたノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１３５のうちの１つによって実施されるルールは、以下のうちの任意の１つ以上に従って定義することができる。
１．どのエンティティ（航空会社または空港）も、ブロックチェーン上に新しいフライトを公開することができる。このエンティティは、フライトに関する全てのデータを公開することができ、フライトの作成段階では、更新を制限するためのロジックルールを適用すべきではない。
２．乗客オブジェクトはクリアテキストで送信され、通常はブロックチェーンに保存される前に暗号化され、フライトに関連するエンティティのみが閲覧可能とすべきである。
３．特定の例では、次のフィールドは誰からも変更不能である。
・起点の日付
・出発空港
・運航航空会社
・便名
・出発．予定
・到着．予定
４．航空会社は任意のフィールドを更新することができる（＃３に列挙されているフィールドを除く）
５．フライトの作成後、出発空港は以下を除くどのフィールドも更新可能である。
・＃３に列挙されているフィールド
・到着オブジェクト
６．フライトの作成後、到着空港は以下を除くどのフィールドも更新可能である。
・＃３に列挙されているフィールド
・出発オブジェクト

クレジット／トークン
どのエンティティ（航空会社、空港）がフライトにとって最も価値のあるデータを提供したかを追跡するという概念がある。エンティティが有効なフライト更新をシステムにプッシュするたびに、そのエンティティはトークンでクレジットされる。これにより、システムは、フライトデータを最新の状態に保持するために最も寄与している者を追跡することができる。データへのアクセスが収益化されるシナリオでは、これらのトークンを後の段階で使用することで、誰が支払われるべきか、およびそのエンティティが支払われるべき総額を特定することができる。

複数のソースからのデータマッピング
以下の開示は、異なるデータソースのサンプルと、本発明の実施形態による、それらのマージ方法とを提供する。
１．以下の表１は、航空会社からのサンプルデータを示す。このデータには、出発ゲート／ターミナル情報、または到着ゲート／ターミナル情報が含まれていないことに留意すべきである。これは、航空会社がこの情報を管理しておらず、多くの場合、出発が近づくまで（２４時間以内）割り当てられないからである。一方、予定されている航空会社は１２か月前までに指定される。
{
"MarketingCarrierCode": "BA",
"FlightNumber": 1476,
"Sector": {
"DepartureStatus": "Estimated",
"ArrivalStatus": "Estimated",
"DepartureAirport": "GLA",
"ArrivalAirport": "LHR",
"ScheduledDepartureDateTime": "2017-04-24T10:00:00",
"ScheduledArrivalDateTime": "2017-04-24T11:30:00",
"ReportedDepartureDateTime": "2017-04-24T10:00:00",
"ReportedArrivalDateTime": "2017-04-24T11:33:00",
"OperatingCarrierCode": "BA",
"AircraftTypeCode": 319,
"MatchesRequest": true
}
}
表１：キー／値ペアまたは構文要素として定義され得る航空会社からのサンプルＪＳＯＮデータおよび関連するデータ値。

２．以下の表２は、到着空港からのサンプルデータを示す。このデータは、（航空会社からのｊｓｏｎデータとは対照的に）ＸＭＬ形式である。また、これは到着空港である故、フライトの出発時刻（予定、予測、または実際）に関する情報がない。到着空港は、フライトの着陸予定時刻と、どのゲート／ターミナルであるかのみを認識している。また、空港は航空会社とは異なる機器タイプ（３１９対３２０）を有していることに留意すべきである。これにより、マージに際して特別な処理を必要とする（フェーズ３）。
<flight>

<flightIdentifier>BA1476</flightIdentifier>

<flightNumber>1476</flightNumber>

<airlineIataRef>BA</airlineIataRef>

<aircraftEquipmentIataRef>320</aircraftEquipmentIataRef>

<origin>

<airportIataRef>GLA</airportIataRef>

</origin>

<destination>

<airportIataRef>LHR</airportIataRef>

<terminalCode>5</terminalCode>
<terminalCode>22</terminalCode>

<status code="LD" statusTime="2014-07-11:30:00.000Z">

<interpretedStatus>Landed 11:30</interpretedStatus>

<category>INFO</category>

<messages>

<message>

<text>Landed</text>

<data>11:28</data>

</message>

</messages>

</status>

<scheduledDateTime>

<utc>2017-04-24T11:30:00.000</utc>

<local>2017-04-24T11:30:00.000</local>

<utcOffset>0</utcOffset>

</scheduledDateTime>

</destination>

<stops count="0"/>

<isHadacabCancelled>false</isHadacabCancelled>

</flight>

表２：キー／値ペアまたは構文要素として定義され得る到着空港からのサンプルＸＭＬおよび関連するデータ値。

３．以下の表３は、結果として得られたマージされたデータセットを示す。これは、到着データおよび出発データの要素を含む、ＡＣＲＩＳデータ標準にある。このｊｓｏｎデータは、この特定のフライトに対する航空会社および到着空港からのマージされたデータを含む。更に、データをマージするロジックは、特定の要素（この場合は航空機の機器）についてデータに違いがある場合、航空会社が使用される航空機を管理しており、かつ空港が知らない変更を後に加えなければならなかった可能性もある故に、航空会社のデータが優先されることが想定される。また、データには他の外部データセットが追加されている。上記のデータには航空会社のＩＡＴＡコードのみが含まれているが、マージプロセスでは他のコード標準（この場合はＩＣＡＯ）を検索し、航空会社用に使用可能な名前を取得することも可能である。これにより、データの品質が更に向上する。

{

operatingAirline: {

iataCode: "BA",

icaoCode: "BAW",

name: "British Airways"

},

aircraftType: {

icaoCode: "A319",

modelName: "319",

registration: ""

},

flightNumber: {

airlineCode: "BA",

trackNumber: "1476"

},

departureAirport: "GLA",

arrivalAirport: "LHR",

originDate: "2017-04-24",

arrival: {

scheduled: "2017-04-24T10:30",

actual: "2017-04-24T10:30",

terminal: "5",

gate: "22",

baggageClaim: {

carousel: ""

}

},

flightStatus: "Landed",

via: []

}
表３：マージされたＪＳＯＮデータセットのサンプル。これは、キー／値ペアまたは構文要素および関連するデータ値として定義することができる。

ノード１１９、１２１、１２３の機能
これらは、通常、スマートコントラクトの機能等、特定の機能を実行するように構成された追加のコードまたはロジックを備える。通常、ノード１１９、１２１、１２３のうち１つ以上は、ＨＴＴＰＳ等の有線または無線のセキュアリンクを介してアダプタ１０１、１０３、１０５の１つから受信した書き込み要求を許可すべきか、または拒否すべきかを決定するコードを備える。この機能は、ゲートウェイ、ゲートキーパー、またはルールエンジンと呼ばれる場合があり、図面の図１には示されていないが、データベースにデータを書き込む要求を許可すべきタイミングと、データベースにデータを書き込む要求を拒否すべきタイミングとを決定する。

各ゲートウェイ１３１、１３３、１３５は、以下の機能を実行するように構成され得る。本発明の実施形態のこの説明は、ゲートウェイ１３１、１３３、１３５のうちの１つの機能に焦点を当てている。通常、各ノード１１９、１２１、および１２３は、以下で説明するものと同じまたは類似の機能をゲートウェイに採用する。従って、各ゲートウェイ１３１、１３３、１３５の機能は、各ノード１１９、１２１、１２３上で実装され得る。

各アダプタ１０１、１０３、１０５は、ＨＴＴＰＳ等の有線または無線リンク１５１、１５３、１５５を介して、各ノード１１９、１２１、１２３に決定されたステータス情報を定期的にプッシュすることができる。これは、通常、アダプタ１０１、１０３、１０５のうちの１つによる、各アダプタに関連付けられた各データベース１０７、１０９、１１１のうちの１つのポーリングに応じている。アダプタ１０１、１０３、１０５のうちの１つからノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１３５のうちの１つにプッシュされるステータス情報データは、通常、図１に示すキー１２５、１２７、１２９のうちの１つを使用して暗号化される。データは、前述したように、キーの１つを含み得るＲＥＳＴ ＡＰＩコールを使用してプッシュすることができる。通常、データの署名に使用されるキー１２５、１２７、１２９はそれぞれ、公開キーまたは秘密キーである。更に、キー１２５、１２７、１２９はそれぞれ、異なるのが一般的である。更に、各キー１２５、１２７、１２９を使用して、データのソースまたは出所を識別することができる。キーは、データベース１０７、１０９、１１１に保存されているデータの出所またはソースを一意に識別することができる。特定の一例では、各アダプタは特定のデータベース１０７、１０９、１１１を特定の頻度でポーリングするように構成される。

第１のアダプタ１０１は、第１の頻度で第１のデータベースをポーリングするように構成することができる。第２のアダプタ１０３は、第２の頻度で第２のデータベース１０９をポーリングするように構成することができる。第３のアダプタ１０５は、第３の頻度で第３のデータベース１１１をポーリングするように構成することができる。実装に応じて、第３の頻度は、第１の頻度または第２の頻度よりも頻繁でも、またはより少なくてもよい。第１の頻度は、第２の頻度に対応するか、または実質的に等しくてもよい。

続いて、各アダプタにより、データソースの１つからステータス情報データを受信する。データは、前述したように、各ノードにＸＭＬまたはＪＳＯＮデータ形式に従って送信することができる。

これに応じて、ノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１２３はそれぞれ、ペイロードの一部としても送信可能な書き込みコマンドを生成し、ステータス情報に定義された構文要素がデータベースまたはノード１１９、１２１、１２３の１つに書き込まれることを要求する。通常、データは、例えば約１分の頻度で、各アダプタ１０１、１０３、１０５から各ノード１１９、１２１、１２３に定期的に送信される。

従って、ステップ８０１にて、ノード１１９、１２１、１２３またはゲートウェイ１１９、１２１、１２３のうちの１つ以上は、各アダプタ１０１、１０３、１０５からデータを受信する。通常、データはキーにより署名されている。次に、ステップ８０３にて、ノード１１９、１２１、１２３またはゲートウェイ１１９、１２１、１２３のうちの１つ以上により、データに関連付けられたアイデンティティを、換言するとデータの出所を決定する。これは、キーを使用して実行され得る。

例えば、図１の実施形態では、データベース１０７に格納されたデータは、ロンドンのヒースロー（ＬＨＲ）等の空港から発信されるか、または空港に関連付けられている。データベース１０９に格納されたデータは、ブリティッシュエアウェイズ（商標）等の航空会社から発信されるか、または航空会社に関連付けられている。データベース１１１に格納されているデータは、フライトステータス情報データの提供者から発信されるか、または提供者に関連付けられている。

各ノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１３５は、データに署名するためにアダプタによって使用されるキー１２５、１２７、１２９に基づいて、データに関連付けられたアイデンティティを決定することができる。以下で更に詳しく説明するように、ゲートキーパーにより、各ノードに保存されている１つ以上のルールに基づいて、ノードまたはデータベースへの書き込み要求をブロックまたは許可する。通常、単一のルールセットが提供され、これが各ノードにわたって複製される。しかしながら、原則として、データソースごとに異なるルールを提供することができる。

従って、各ノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１３５は、データの署名方法の特徴からデータに関連付けられたアイデンティティを決定することができる。各キーは異なる場合がある故に、各ノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１３５は、例えばブリティッシュエアウェイズに関連付けられたキー、またはダブリン空港に関連付けられたキー、またはロンドンのヒースロー空港に関連付けられたキー等、データの署名にどのキーが使用されたかを判定することができる。

通常は、一意にデータのソースが決定されると、各ノード１１９、１２１、１２３またはゲートウェイ１３１、１３３、１３５は、データベースまたはノードへのデータの書き込み要求を許可すべきか、または拒否すべきかを定義するルールを格納する前記データベースまたは更なるデータベースを検索する。

データベースまたはノード１１９、１２１、１２３またはゲートウェイ１１９、１２１、１２３に保存されている特定の詳細ルールに関しては、以下で更に詳しく説明するが、通常、ステータス情報またはデータが出発空港あるいは到着空港または航空会社に関連付けられているか否かに応じて、異なるルールが提供される。

ルールは、アダプタ１０１、１０３、１０５のうちの１つからノード１１９、１２１、１２３またはゲートウェイ１１９、１２１、１２３のうちの１つによって受信されたステータス情報に定義された構文要素の何れを書き込むか、またはノードの１つに格納されている既存の構文要素にマージするかを規定する。

決定されたルールに基づいて、異なる各構文要素とデータの出所とがルールによりチェックされる。ステップ８０５にて、ノードに格納されている各構文要素を更新する書き込みアクセスが、ルールに基づいて許可または拒否される。

更なる態様では、図１に示されている機能コンポーネントのいずれかに送信される、またはいずれかから送信される１つ以上のフィールドまたは構文要素を暗号化することができる。

特定の一例では、予測される出発スケジュールに関連付けられた構文要素またはデータは公開されており、公開キーで署名することができる。従って、図１に示される仮想ネットワーク１００へのアクセス権を有する全関係者が、この情報を解読することができる。

しかしながら、ステータス情報に関連付けられた特定のフィールドまたは構文要素は、秘密キーで暗号化されてもよい。例えば、構文要素「航空機の乗客数」は、３ｗａｙ暗号化によって保護されてもよい。

これの特定の用途として、例えば、フライトごとに、または特定の日にちの所定の期間に到着する乗客の総数を空港が判定する必要がある場合が挙げられる。更に、空港は、到着する乗客のうち何人が車椅子を必要とするかを決定する必要があるかもしれない。

このデータは、アダプタ１０３等のアダプタの１つを使用する航空会社のソースによって提供され、データベース１０９から検索されるステータス情報に含まれ、例えば送信手段または送信機を使用してノード１２１に送信される。従って、例えばロンドンのヒースロー等の出発空港、ＢＡ等の航空会社、およびダブリン等の到着空港の間に秘密キーまたは３ｗａｙロックを提供することで、乗客数および／または車椅子ユーザの数のような、データベース１０７、１０９から検索されたステータス情報における１つ以上のフィールドまたは構文要素を、これらの三者のみが閲覧することができるようにする。

即ち、第三者がノードのうちの１つに格納されているデータベースを照会するアプリケーションを構築した場合でさえも、特定の構文要素またはフィールドは３ｗａｙロックによってビューから保護されている故に、それらにより特定の構文要素またはフィールドを解読することはできないであろう。特定のデータまたは構文要素の秘密キーを使用した３ｗａｙロックまたは暗号化は、機密データに関連する他の構文要素にも適用することができる。

前述したように、本発明の実施形態は、空港１０７、航空会社１０９、およびフライト情報データベース１１１等の複数のソースからフライトデータを引き出す。その後、データは、ブロックチェーンまたはＤＬＴに格納される。データは、完全なフライトオブジェクト、または図面の図２〜図７に示すデータ要素のうちの任意の１つ以上のような、フライトの任意の１つ以上の部分的要素であり得る。

更に、ブロックチェーンに格納された、マージされたデータセットへのアクセスを可能にする、データベース１１１に関連付けられたＡＰＩ等のプログラミングインタフェースが提供されてもよい。ＡＰＩは、上述したように、特定のフライトまたは旅行を一意に識別する任意の１つ以上のデータ等の１つ以上の入力データフィールドに基づいて、旅行またはフライトに関連する第１のキーを決定することができる機能を備え得る。これは、図面の図９のステップ９０１として示されている。ステップ９０３にて、（ユニーク）キーを使用して、第１のキーに関連付けられた第１のステータス情報が、ブロックチェーンデータベースまたは他のデータベースから検索される。続いて、ＡＰＩは、データベースの１つから図２〜図７に示すデータフィールドのうちの任意の１つ以上を検索する。通常、図２〜図７に示す１つ以上のデータ要素は、システムのユーザへ、モニタ、ディスプレイ、またはディスプレイ手段に出力される。

いくつかの特定の例では、ノード１１９、１２１、１２３またはゲートウェイ１１９、１２１、１２３はそれぞれ、データベースに格納されているいくつかのフィールドを暗号化するように構成されてもよい。３ｗａｙ暗号化アルゴリズムを使用することができる。

例えば、一般的な到着または出発のスケジュール情報に関連する、特に機密事項ではないフィールドは「パブリック」であり、必ずしも暗号化されるとは限らない。

しかしながら、一部のデータは、例えば３ｗａｙ暗号化アルゴリズムを使用して暗号化することにより、プライベートデータとして保存されてもよい。

特定の一例では、到着空港がダブリンであり、ダブリンのデータベースに結合されたアダプタにより出発ゲートを更新しようと試みたとすると、この更新は拒否される。なぜなら、通常、出発空港データベース、または換言すると、出発空港データベースに結合されたアダプタのみが、出発空港だけが更新することを認められているフィールドを更新するためのデータベースへの書き込みアクセスを許可されるからである。これにより、ブロックチェーンに保存されているフィールドの整合性が保たれる。

このようにして、出発空港データベースに結合されたアダプタは、通常、出発に関連する情報の更新のみが許可され、例えば、到着に関連する情報または乗客の手荷物に関連する情報の更新は許可されない。

同様に、到着空港データベースに結合されたアダプタは、通常、到着に関連する情報の更新のみが許可され、例えば、出発便に関連する如何なる情報の更新も許可されない。

このようにして、データベースに保存されたフィールドの異なるサブセットは、定義されたアクセスルールに従って、特定のソースからのデータを使用して特定のアダプタによってのみ更新される。

フライトのライフサイクル
フライトのライフサイクルは、最初のフライトオブジェクトであり、フライトに対する後続の全ての更新である。以下の例は、どの当事者がデータを提供しているかに応じて、本発明の実施形態によって実行され得る更新のタイプを示している。更新は、本発明の実施形態がデータを処理する典型的な順序で提示される。
航空会社ベースのアップデート＃１：
・航空会社は、予定されたフライト情報（便名、出発／到着空港、出発／到着の日付／時刻）を公開する
出発空港ベースのアップデート＃１：
・出発空港は、このフライトのチェックインデスク情報を更新する
・出発空港は、このフライトの出発ターミナル／ゲート情報を更新する
航空会社ベースのアップデート＃２：
・航空会社は、予測出発時刻を更新する
到着空港ベースのアップデート＃１：
・到着空港は、このフライトの到着ゲートを更新する
出発空港ベースのアップデート＃２：
・出発空港は、このフライトの実際の出発時刻を更新する
到着空港ベースのアップデート＃２：
・到着空港は、このフライトを実際の到着時刻を更新する
・到着空港は、このフライトの手荷物受け取りターンテーブルを更新する

データ形式
フライトデータはＡＣＲＩＳデータ構造を使用してブロックチェーンに送信され、この例ではいくつかの更なるフィールドが追加される。
追加フィールド：
−乗客−このデータ構造には、フライトに関するデータが含まれており、各キャビンの乗客数と車椅子の補助が必要な乗客数とを示している。通常、データは暗号化されており、関連する当事者、即ち航空会社、出発空港、および到着空港のみが閲覧可能である。
−フライトデータ変更−このデータ構造には、全ての変更の履歴が含まれる。これは、デバッグを支援し、簡単にアクセスできるフライトの更新履歴を提供するためだけに便利なデータ構造の一部である。

前述のデータフィールドのうち任意の１つ以上をＳＩＴＡデータベース１１１に格納することができる。通常、追加のフィールドデータをデータベース１１１から取得することができるようにデータベースを照会することができるＡＰＩが提供される。

以上から、本発明の実施形態は、スマートコントラクトを使用してデータをマージし、競合するデータがある場合には調停する、許可されたブロックチェーンまたはＤＬＴを使用することができることが理解されよう。航空会社および空港のＡＯＤＢシステムからのデータは、ブロックチェーンにマージされ保存される。通常、ブロックチェーンノードはＳＩＴＡ、ＩＡＧ、およびＬＨＲデータセンターに存在する。

図面の図２〜図７は、ステータス情報等のデータを使用したデータベースまたはブロックチェーンの更新プロセスを示している。この特定の例では、データはロンドンのヒースロー（ＬＨＲ）からジュネーヴ（ＧＶＡ）への特定のフライトＢＡ０７２４に関連付けられており、出発予定時刻は０６：４５、到着予定時刻は０９：２０、またフライトが出発済みであることを示している。

実際の出発時刻は、ターミナル５のゲートＢ：３８から、０６：４３と表示されている。ターミナル１における到着予測時刻０９：３５が表示されており、到着ゲートはまだ割り当てられていない。

図２では、更新ステータスまたは履歴が示されている。例えば、これは、到着空港であるＧＶＡが実際の時刻を更新しようと試みたこと、およびこの更新が認可または許可されなかったことを示している。対照的に、図２の下部には、航空会社が実際の出発時刻０６：４３にデータを更新することを許可または認可されたことが示されている。同様に、図３〜図６は、データベースに格納されているデータを更新しようと試みる特定のデータソースの例と、データの書き込みが許可または拒否された例とを示している。図７は、いくつかの例示的なフィールドまたは構文要素を示している。

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

上記から、システム、デバイス、および方法は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯情報端末、携帯電話、スマートフォン等のコンピュータデバイスを含み得ることが理解されよう。

デバイスは、クライアントデバイスと通信するための１つ以上のサーバプロセスを実行するコンピュータプロセッサを備えてもよい。サーバプロセスは、本発明の動作を実行するためのコンピュータ可読プログラム命令を含む。コンピュータ可読プログラム命令は、Ｃ等の手続き型プログラミング言語や、Ｃ＃、Ｃ＋＋、Ｊａｖａ、スクリプト言語、アセンブリ言語、マシンコード命令、命令セットアーキテクチャ（ＩＳＡ）命令、および状態設定データ等のオブジェクト指向プログラミング言語を含む適切なプログラミング言語、またはそれらの任意の組み合わせで書かれたソースコードまたはオブジェクトコードであり得る。

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

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

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

コンピュータ可読プログラム命令は、非一時的な有形のコンピュータ可読媒体に保存されてもよい。コンピュータ可読記憶媒体は、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリースティック、フロッピーディスクのうちの１つ以上を含み得る。

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

（付記１）
デバイスに関連付けられたデータベースまたは格納手段へのアクセスの許可または拒否を決定するためのコンピュータ処理デバイス（１１９、１２１、１２３、１３１、１３３、１３５）であって、前記デバイスは、
ａ．特定のステータス情報のデータを受信するための受信手段を含み、
前記データがキーにより署名されており、
前記デバイスは、
ｉ．前記キーを、前記データベースまたは格納手段に格納されている１つ以上のキーと比較することによって、前記データの出所を決定して、前記データのソースを特定し、
ｉｉ．前記データベースまたは格納手段を検索して、前記データのソースに関連する１つ以上のアクセスルールであって、前記データについての前記データベースまたは格納手段への書き込みアクセスの許可または拒否を規定するアクセスルールを決定し、
ｉｉｉ．前記決定された１つ以上のルールに基づいて、前記データベースまたは格納手段への書き込みアクセスを許可または拒否する
ように構成されている、コンピュータ処理デバイス。

（付記２） 前記データは、複数の異なるフィールドを含み、前記データベースまたは格納手段は複数の異なるフィールドを含む、付記１に記載のコンピュータ処理デバイス。

（付記３） 前記異なるフィールドのうち少なくとも２つ以上に対して、１つ以上の異なるアクセスルールが提供される、付記２に記載のコンピュータ処理デバイス。

（付記４） 前記データは、出発地Ａと目的地Ｂとの間の旅行またはフライトに関連付けられている、付記１〜３のいずれか一つに記載のコンピュータ処理デバイス。

（付記５） 前記決定された１つ以上のルールに基づいて、前記データベースまたは格納手段に格納されているフィールドのサブセットへのアクセスを許可または拒否するように更に構成されている、付記１〜４のいずれか一つに記載のコンピュータ処理デバイス。

（付記６） 前記データベースまたは格納手段に格納されている１つ以上の暗号化ルールに基づいて、前記受信データに関連する１つ以上のフィールドを暗号化するように更に構成されており、前記暗号化が３ｗａｙ暗号化を使用して実行される、付記１〜５のいずれか一つに記載のコンピュータ処理デバイス。

（付記７） 出発地Ａと目的地Ｂとの間の旅行に関連付けられたステータス情報を決定するためのコンピュータ処理デバイスであって、
前記旅行またはフライトに関連付けられた第１のキーを決定し、
前記第１のキーに関連付けられた第１のステータス情報を受信する
ように構成された
ａ．第１のアダプタを含む、コンピュータ処理デバイス。

（付記８） 前記デバイスは、更に、
ｉ．前記第１のキーに関連付けられた第２のステータス情報であって、前記第１のステータス情報とは異なる第２のステータス情報を受信する
ように構成された
ａ．第２のアダプタを含む、付記１に記載のコンピュータ処理デバイス。

（付記９） 前記デバイスは、更に、
ｉ．前記第１のキーに関連付けられた第３のステータス情報であって、前記第１のステータス情報および前記第２のステータス情報とは異なる第３のステータス情報を受信する
ように構成された
ａ．第３のアダプタを含む、付記２に記載のコンピュータ処理デバイス。

（付記１０） 第１のルールセットは第１のステータス情報に関連付けられており、前記ルールにより、データベースに格納されている１つ以上のフライトステータス情報の構文要素のうちどれを前記第１のアダプタによって更新するかを規定する、付記１〜９のいずれか一つに記載のコンピュータ処理デバイス。

（付記１１） 第２のルールセットは第２のステータス情報に関連付けられており、前記ルールにより、データベースに格納されている１つ以上のフライトステータス情報の構文要素のうちどれを前記第２のアダプタによって更新するかを規定する、付記１〜１０のいずれか一つに記載のコンピュータ処理デバイス。

（付記１２） 第３のルールセットは第３のステータス情報に関連付けられており、前記ルールにより、データベースに格納されている１つ以上のフライトステータス情報の構文要素のうちどれを前記第１のアダプタによって更新するかを規定する、付記１〜１１のいずれか一つに記載のコンピュータ処理デバイス。

（付記１３） 前記第１のキーにより、航空会社または空港に関連付けられたデータベースへのアクセスが可能となる、付記１〜１２のいずれか一つに記載のコンピュータ処理デバイス。

（付記１４） 前記プロセッサは、交通結節点に関連するデータベースへのサービスコールを実行するように更に構成されており、好ましくは、前記サービスコールは、安全な転送プロトコルを使用して通信されるＳＯＡＰ ＸＭＬ Ｗｅｂサービスコールまたはｒｅｓｔ ＡＰＩコールである、付記１〜１３のいずれか一つに記載のコンピュータ処理デバイス。

（付記１５） 前記サービスコールは前記第１のキーを含む、付記１〜１４のいずれか一つに記載のコンピュータ処理デバイス。

（付記１６） 前記第１のステータス情報および第２のステータス情報および第３のステータス情報のうち任意の１つ以上は、特定の出発空港、出発ゲート、到着空港、到着ゲート、航空会社に関連付けられたフライトスケジュール情報におけるステータス情報の異なる側面を定義するデータを含み、前記データはＸＭＬまたはＪＳＯＮデータ形式等の英数字データ形式に従ってフォーマットされていることが好ましい、付記１〜１５のいずれか一つに記載のコンピュータ処理デバイス。

（付記１７） 前記第１または第２または第３のアダプタは、前記第１のステータス情報、または第２のステータス情報または第３のステータス情報に関連する１つ以上の構文要素を読み取るように構成されており、前記ステータス情報は、第１の形式に従って構成され、かつ前記構文要素を前記第１の形式とは異なる第２の形式にマッピングするように構成されている、付記１〜１６のいずれか一つに記載のコンピュータ処理デバイス。

（付記１８） 前記第１のアダプタ、第２のアダプタまたは第３のアダプタのうち任意の１つ以上は、前記第１のキーにより、前記第１のステータス情報、第２のステータス情報および第３のステータス情報のうち任意の１つ以上をスタンプするように構成されている、付記１〜１７のいずれか一つに記載のコンピュータ処理デバイス。

（付記１９） 前記第１、第２または第３のアダプタ１０１、１０３、１０５またはノード１１９、１２１、１２３はそれぞれ、受信された第１のステータス情報および第２のステータス情報および好ましくは第３のステータス情報を集約データにマージするように構成されており、前記集約データは好ましくは英数字形式からなる、付記１〜１８のいずれか一つに記載のコンピュータ処理デバイス。

（付記２０） 前記第１のアダプタ、第２のアダプタまたは第３のアダプタのうち任意の１つ以上は、更に、
出発および／または到着予定時刻、
予測されるおよび実際の出発／到着時刻、
空港に関連する出発ゲートおよび／またはターミナル、
前記またはある空港に関連する到着ゲートおよび／またはターミナル、
到着空港に関連付けられた手荷物受け取りターンテーブル番号、
フライトをｄｅｌａｙｅｄまたはｇｏ ｔｏ ｇａｔｅまたはｂｏａｒｄｉｎｇまたはｃｌｏｓｉｎｇとして定義する特定のデータにおけるフライトステータス情報、並びに
航空機タイプおよびテールナンバー
を画定する、任意の１つ以上の構文要素を含むフライトステータスデータを受信するように構成されている、付記１に記載のコンピュータ処理デバイス。

（付記２１） 前記プロセッサは、前記第１のステータス情報および前記第２のステータス情報および好ましくは前記第３のステータス情報に関連付けられた前記構文要素または更なる構文要素のうち任意の１つ以上が、構文要素の比較に基づいて一致するか否かを決定するように更に構成されている、付記１〜２０のいずれか一つに記載のコンピュータ処理デバイス。

（付記２２） 前記プロセッサは、前記第１または第２または第３のフライトステータス情報の１つに関連付けられた一致する構文要素のうち１つのみを選択し、かつ、好ましくは、他のフライトステータス情報に関連付けられた一致する構文要素を捨てることによって、決定された一致する構文要素のうちの１つ以上を合理化するように更に構成されている、付記１〜２１のいずれか一つに記載のコンピュータ処理デバイス。

（付記２３） 前記プロセッサは、更に、前記集約データまたは前記第１のステータス情報および第２のステータス情報および第３のステータス情報のうちの任意の１つを１つ以上のノード（１１９、１２１、１２３）または分散型台帳に関連付けられた更なるコンピュータデバイスに送信するように構成されており、前記集約データまたはデータを定期的に送信する、付記１〜２２のいずれか一つに記載のコンピュータ処理デバイス。

（付記２４） 前記コンピュータデバイスまたは更なるコンピュータデバイスまたはノードは、出発予定日、出発空港、運航航空会社、および運航便を定義するデータのうちの任意の１つ以上に基づいて、フライトに対するユニークキーを生成するように構成されている、付記１〜２３のいずれか一つに記載のコンピュータ処理デバイス。

（付記２５） 前記更なるコンピュータデバイスまたはノードは、前記フライトのユニークキーに一致するデータについて、前記データベースまたは更なるデータベースを検索、付記１〜２４のいずれか一つに記載のコンピュータ処理デバイス。

（付記２６） 前記更なるコンピュータデバイスまたはノードは、出発スケジュール、到着スケジュール、運航日付、運航航空会社、便名、出発空港および到着空港を定義するデータのうちの任意の１つ以上を含むフライトレコードを生成し、前記データベースまたはあるデータベースが前記フライトのユニークキーに一致するデータを含まず、前記データベース内の前記フライトレコードに前記集約データを格納する場合にのみ、フライトレコードを作成する、付記１〜２５のいずれか一つに記載のコンピュータ処理デバイス。

（付記２７） 前記プロセッサは、前記集約データを空港のディスプレイに送信するように更に構成されており、前記表示されたステータス情報は、フライトが遅延、搭乗中、または閉鎖中であるか否か、または前記フライトに関連する乗客が所定のゲート番号に行くべきか否かを定義するデータのうちの任意の１つ以上を含む、特定の英数字テキストでフライトのステータスを定義するデータを含む、付記１〜２６のいずれか一つに記載のコンピュータ処理デバイス。

（付記２８） 出発地Ａと目的地Ｂとの間の旅行に関連するステータス情報を決定するための方法であって、付記１〜２７のいずれか一つに記載のステップを含む、方法。

（付記２９） 実行時に、付記１〜２８のいずれか一つに記載の方法を実行する、コンピュータプログラム製品。

（付記３０） 出発地Ａと目的地Ｂとの間の旅行に関連するステータス情報を決定するための装置であって、
ａ．旅行またはフライトに関連する第１のキーを決定する手段と、
ｂ．前記第１のキーに関連する第１のステータス情報を受信するための手段と、
を含む、デバイス。

Claims (45)

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. 各データ要素がキー／値ペアを含む、請求項２６〜２８のいずれか一項に記載のシステム。
30. 前記第１のデータセットおよび前記第２のデータセットが、同一のデータ要素を含むか否かを判定するステップを更に含む、請求項２９に記載のシステム。
31. 前記第１のデータセットおよび第２のデータセットが同一の共通要素を含むと判定された場合、前記第１データセットに関連するデータソースおよび前記第２のデータセットに関連するデータソースに基づいて、前記共通要素に関連付けられた値に重み付けする、請求項３０に記載のシステム。
32. 第１の頻度にて更新された第１のデータセットを受信するステップと、第２の頻度にて更新された第２のデータセットを受信するステップとを更に含む、請求項２６〜３１のいずれか一項に記載のシステム。
33. 前記第２の頻度が前記第１の頻度よりも高い、請求項３２に記載のシステム。
34. 前記第１のデータソースは旅行の出発地に関連付けられており、前記第２のデータソースは旅行の目的地に関連付けられている、請求項１〜３３のいずれか一項に記載のシステムまたはデバイス。
35. データ処理の方法であって、
    ｉ．キーを、前記データベースまたは更なるデータベースに格納されている１つ以上のキーと比較することにより、第１のキー（１２５）により署名されたデータの出所を決定して、前記データのソースを特定するステップと、
    ｉｉ．前記データベースを検索して、前記データのソースに関連付けられた１つ以上のアクセスルールであって、前記データについての前記データベースへの書き込みアクセスの許可または拒否を規定するアクセスルールを決定するステップと、
    ｉｉｉ．前記決定された１つ以上のルールに基づいて、前記データベースへの書き込みアクセスを許可または拒否するステップと、
    を含む、方法。
36. データ処理の方法であって、
    第１のデータソースに関連付けられた第１のデータセットであって、複数の異なる第１のデータ要素を含む第１のデータセットから、前記第１のデータソースに関連付けられた第１のユニークキーを決定するステップと、
    第２のデータソースに関連付けられた第２のデータセットであって、複数の異なる第２のデータ要素を含む第２のデータセットから、前記第２のデータソースに関連付けられた第２のユニークキーを決定するステップであって、前記第１データセットおよび第２データセットは少なくとも１つの共通データ要素を共有しており、前記第１のデータ要素のうちの少なくとも一部が前記第２のデータ要素と異なる、ステップと、
    前記キーに基づいて、前記第１のデータソースおよび第２のデータソースを確認するステップと、
    各データソースが前記データのソースとして確認された場合、前記第１データセットと第２データセットとを集約データセットに結合するステップと、
    を含む、方法。
37. 第３のデータソースに関連付けられた第３のデータセットであって、複数の異なる第３のデータ要素を含む第３のデータセットから、前記第３のデータソースに関連付けられた第３のユニークキーを決定するステップであって、前記第１のデータセットおよび第２のデータセットおよび第３のデータセットが、少なくとも１つの共通データ要素を共有しており、前記第１のデータ要素のうちの少なくとも一部が前記第３のデータ要素とは異なる、ステップと、
    前記第３のキーに基づいて、前記第３のデータソースを確認するステップと、
    前記第３のデータソースが前記第３のデータのソースとして確認された場合、前記集約データセットと前記第３のデータセットとを結合するステップと、
    を更に含む、請求項３６に記載の方法。
38. 前記第１のデータソースから前記第１のデータセットを受信するステップ、および／または前記第２のデータソースから前記第２のデータセットを受信するステップ、および／または前記第３のデータソースから前記第３のデータセットを受信するステップを更に含む、請求項３７に記載のシステムの方法。
39. 各データ要素がキー／値ペアを含む、請求項３６〜３８のいずれか一項に記載の方法。
40. 前記第１のデータセットおよび第２のデータセットが、同一のデータ要素を含むか否かを決定するステップを更に含む、請求項３９に記載のシステムの方法。
41. 前記第１のデータセットおよび第２のデータセットが同一の共通要素を含むと判定された場合、前記第１のデータセットに関連するデータソースおよび前記第２のデータセットに関連するデータソースに基づいて、前記共通要素に関連付けられた値に重み付けする、請求項４０に記載の方法。
42. 第１の頻度にて更新された第１のデータセットを受信するステップと、第２の頻度にて更新された第２のデータセットを受信するステップとを更に含む、請求項３６〜４１のいずれか一項に記載の方法。
43. 前記第２の頻度が前記第１の頻度よりも高い、請求項４２に記載の方法。
44. 前記第１のデータソースは旅行の出発地に関連付けられており、前記第２のデータソースは旅行の目的地に関連付けられている、請求項３６〜４３のいずれか一項に記載の方法。
45. 実行されると、請求項３５〜４４のいずれか一項に記載の方法を実行する、コンピュータプログラム製品。

Images