JP2021508097A - データ処理用のシステム、装置、及び方法 - Google Patents

Abstract

データ処理用のコンピュータ処理装置を開示する。装置は、次のステップをなすように構成されている：データ要求主体と関連付けられている信頼レベルを決定するステップ；１つ以上のデータ要素と関連付けられているデータ区分を決定するステップであって各データ区分は関連付けられている信頼レベルを有しているステップ；データ要求主体のために１つ以上のデータ要素に基づいてデータ要素のセットを構築するステップであって該構築は、各データ区分と関連付けられている決定されたランキングと、データ要求主体と関連付けられている決定された信頼レベルとに基づいているステップ。

Description

本発明は、データ処理用のシステム、機器、方法又はコンピュータプログラムに関する。より具体的には、本発明は、セキュアなデータ共有のためのシステム、装置及び方法に関する。

排他的な意味合いを伴わせずに特に言及すると、本発明は、空港や海港や鉄路や他の大量輸送地点における荷捌きに関連するデータの処理に関する。

もっとも、本発明の諸々の実施形態は任意のデータエコシステム分野に適用可能であり、それ故に空港輸送業界に限定はされないことに留意されたい。

特に荷物データ処理システム等の従来のデータ処理システムは、規則（rule）を定立してデータがどのように（how）誰によって（by whom）使用されるのかを制御するプラットフォームを提供するには至っていない。

このため、私的且つ機密且つ商業的且つオペレーショナルな性質のデータが同じデータベーステーブル内にて一緒に格納されることになり、同じイベントを受けて送信されることとなる。このせいで、オペレーショナルなデータについてのアクセスを他者（other parties）に授与する権能が制約されるのである。なぜならば、例えばこれらの第三者（third parties）は個人データや他の機密データへのアクセスを有し得るからである。

空港や、航空会社やオペレーショナルデータの他のユーザとのデータコラボレーションを達成するためには、特定のデータ区分のオペレーショナルデータについては他のデータ区分とは異なる扱いをなすことを要することを発明者らは悟ったのである。

本発明の実施形態は、区分に従ってデータ要素を管理することによって上述の問題を克服しようとする。これによって、異なるタイプのデータを、例えば航空輸送業界内にて、共有できるようになる。

さらに、本発明の実施形態は、データへのアクセスを管理し、また、遵守すべきアクセス規則を提供するための信頼性フレームワークを提供することによって上述の問題を克服しようとする。

さらに、本発明の実施形態は、製品不依存的フレームワークの作成を支援するアーキテクチャに基づいており、これによって、顧客、ユーザ、又はデータ要求主体は、自分達の個人的に識別可能な情報データを保護しつつ規則に従って自分達のメッセージデータを選ばれしパートナーらと共有できる。

したがって、本発明の実施形態は、例えば航空会社や空港等のユーザに自分達のデータを、オペレーションズ及び顧客サービス向上のために共有する自信を与えるシステムを提供する。

アーキテクチャ構造の核心部にアプリケーション前モジュールを配することによって、本発明の実施形態は、特注のアプリケーション前モジュールの必要性をなくすのであり、また、認証及び承認トークン化を統合する。ＡＰＩゲートウェイからのマイクロサービス要求全ては信頼性レイヤ（Trust Layer）（換言するに信頼ＡＰＩ１２３（trust API））を通して自動的に構文解析される。これによって、アプリケーション１２５を用いて、アプリケーション１２５によって受信されたデータ、乃至はアプリケーション１２５によって送信されたデータ（着信、発信、又は双方）についてのより粒度の細かいフィルタリングが可能となる。アプリケーション１２５は、次の機能を備えていることができる：発呼側が特定の要素を閲覧することについて承認を得ていないとアプリケーション１２５が決定した場合に、返されたデータから１つ以上のデータ要素をフィルタリングアウトすること。

本発明の実施形態は、階層型データ分類手法を用い得る。当該階層型データ分類手法を用いることの１つの利点は、それがとても拡張可能性に富むということである。仮に新たなデータ要素が作成されて既存の区分に割り当てられた場合、信頼性フレームワークは、システム管理者又は顧客から何らの介入を受けずにして顧客の既存選好を用いて、自動的且つシームレスな態様で新たなデータ要素を適用できる。

本発明の第１の態様によれば、データ処理用コンピュータ処理装置を開示するのであり、該装置は、データ要求主体を識別するデータを受信するため、且つ、データ要求主体を識別する受信されたデータと関連付けられている検索キーを受信するための受信手段又は受信機を備えるのであり、処理装置は、データ要求主体と関連付けられている信頼レベルを決定するステップと、検索キーと関連付けられている１つ以上のデータ要素を受信するステップと、各データ要素と関連付けられているデータ区分を決定するステップであって各データ区分は関連付けられているランキングを有している、ステップと、データ要求主体のためのデータ要素セットを、受信された１つ以上のデータ要素から、各データ要素又はデータ区分と関連付けられている決定されたランキングと、データ要求主体と関連付けられている決定された信頼レベルとに基づいて、構築するステップとをなすように構成されている。

さらなる態様によれば、データ処理用コンピュータ処理装置を提供する。該装置は１つ以上のイベントと関連付けられているデータを記憶するための記憶手段を備えており、各イベントは１つ以上のデータ区分によって定義されており、好適には各データ区分は関連データ所有者又はデータ源フィールドを有している。

したがって、本発明の実施形態はデータ要素とランキングとの間ではなく、むしろデータ区分とランキングとの間で直接的関連を提供し得る。これによって、細微な粒度レベルでのデータフィルタリングがもたらされる。

例示にすぎないが、以下において本発明の実施形態について述べるのであり、添付の図面を参照しつつ述べるのであり、図面については次のとおりである。

本発明を実体化する主要な機能的コンポーネントについての概略図である。 本発明の実施形態によって行われる諸ステップを示す流れ図である。 様々な異なる機能的コンポーネントの間でなされる様々なメッセージ又はコールを示すシーケンス流れ図である。

以下には航空業界にて用いるためのシステムについてのシステムについての説明がされているが、これは例示的説明に過ぎず、本発明の他の用途についても論じられる。例えば、システムは鉄路やcoachや自動車等の他の輸送業界にて用いられ得るのであり、実のところデータに対してのアクセスを管理すべき任意の環境又は業界にて用いられ得るのである。

また、説明される以下の実施形態は、例えばOpenCVライブラリ等を用いてＣ＋＋プログラミング言語にて実装され得る。もっとも、これは例示に過ぎず、ＪＡＶＡや．ｘｍｌ等の当業者が知る他のプログラミング言語も用いられ得る。

図１に転じるに、該図は異なる機能的コンポーネントについての論理レベルでの図解であると理解されたい。本発明の実施形態が、図１に示す異なる機能的コンポーネントの全てを要しているわけではないことに留意されたい。例えば、本発明の実施形態は、機能的コンポーネント１００の中、又は、機能的アプリケーション若しくはコンポーネント１２０の中、又は、ユーザアプリケーション１２１の中に存していることができる。機能的コンポーネント１００は通常は、コンピュータ又はサーバである。図１の例示的構成中においては、アプリケーション１２１は機能的コンポーネント１２０の外部に示されているが、代替的には、アプリケーション１２１は機能的コンポーネント１２０内にて統合されていることができる。

ラベル１００内に示される機能的コンポーネントの１つ以上は、通常は、仮想プライベートクラウド内において実装されている。クラウドへのアクセスは、ユーザ名とパスワードとによって確保され得る。通常は、クラウドは、１つ以上のコンピュータ又はサーバ上で提供されている。図１の実施形態においては、アプリケーション１２０は通常はコンピュータ又はサーバ内にて実装されており、これはコンポーネント１００内に示されている信頼性機能を提供しているさらなるコンピュータ又はサーバと通信可能に接続されている。さらに、ユーザ又はデータ要求主体によって用いられているコンピューティング装置上で実行されているアプリケーション１２１は、図１００内にて示される機能的コンポーネントの１つ以上の任意のものと通信可能に接続されているが、図１に示されている例示的実施形態では、アプリケーションはアプリケーション前モジュール１２２と通信可能に接続されており、該通信はアプリケーションプログラミングインターフェース（ＡＰＩ１２３）を介してなされ得る。

本発明の機能的側面を具現化できるクラウドの１つの具体的な例を挙げるならば、ＡＷＳ（Amazon（登録商標） Web Services）クラウド乃至は仮想プライベートクラウドを挙げることができる。この環境においては、異なるＩＰアドレス範囲を選択でき、サブネットを作成でき、ルーティングテーブル及びネットワークゲートウェイを構成できる。

以下の説明では、荷物旅程データベース１３３内に格納されたデータ要素は所有者に（即ち、データ源及び区分に）関して割り当てられていると仮定する。換言するに、各データ要素は所有者と関連付けられていることができ、随意的には区分と関連付けられていることができる。

疑念払拭のために述べておくが、データ所有者データ（data owner data）及び区分は随意的には荷物旅程データベース１３３内にて格納されていることができるも、それらは通常は別個の信頼性ストアデータベース１１５内にて格納されているのであり、これによって信頼性管理者１０１がデータを個別管理できるようにしている。

データ所有者は、データを提供する当事者又はシステムであると考えて頂ければ宜しい。所有者は、例えば「Airline DCS」や「Airport Scanner」等のアルファニューメリック型ストリング又は別の当事者若しくはイベントステーションとして定義され得る。

同様に、各データ要素と関連付けられている区分を定義することができる。４つの異なるデータ区分を定義できる：
１． クラウドサービス顧客データ（顧客コンテンツデータとも称する）；
２． クラウドサービス派生データ（派生コンテンツデータとも称する）；
３． クラウドサービス提供者データ（サービス提供者データとも称する）；及び
４． アカウントデータ

アカウントデータは通常は（例えばヒースロー空港（ＬＨＲ））空港等の顧客に属するデータであり、サービスの提供に関する請求用途等に関するデータである。

これらの区分の各々は、関連データオブジェクトのサブセット定義によってさらにサブ分割できる。さらなるサブ分割も可能である。さらなる区分も定義できる。例えば、空港情報区分等の航空輸送特有の追加の区分も定義できる。

データ区分は単一の承継／サブタイプ関係を有する階層型構造中で定義されることができる。換言すれば、データ区分は、ツリー型データ構造に従って定義できる。

１つの具体的な例では、下記の表１に従って、荷物メッセージデータは以下の態様で区分され得る：

通常は、これらの区分はＩＳＯ１９９４４規格にマッピングするのであり、該規格は情報技術、クラウドコンピューティング、クラウドサービス及び装置、データフロー、データ区分並びにデータ使用に関する。

新たに定義されたデータ区分を定義することもでき、例えばゲート番号又は情報即ちGateNumber等を定義することもできる。これは通常はアルファニューメリック型のストリング（例、「Ｂ４３」）で定義されており、空港における特定の物理的位置に関連付けられていることができ、そこから航空機が出発するものとされる。表１によれば、このデータは「AirportInformaiton（空港情報）」の区分によって区分されており、そのサブ区分は「General（一般）」である。

同様の態様で、特定の荷物イベントと関連付けられている個別のデータ要素を以下の表２に従って区分できる。表２から分かるように、１つのデータ要素が荷物イベントを定義するかそれと関連付けられているのであり、このことは特定のフライトに関するのであり、故にある荷物が該フライトの貨物室内へと搬入されたことを示すのであり、該フライトが特定の空港から出発したことが示される。これはデータ要素又はキーたる「BagItinerary\Departed_from（荷物旅程＼出発地）」によって定義されている。このイベントと関連付けられている値は、例えば「ＬＨＲ」等のアルファニューメリック型ストリングで定義されることができ、これはロンドンヒースロー等の空港から荷物が出発したことを示す：

表２は、本発明の具体的な実施形態による荷物イベントの例示的な区分化である。

所有者、データ要素、区分、ＰＩＩ、及びＣＳの各々は、キー・バリューのペアで定義され得る。

表１及び表２の両方から分かるように、各データ要素については関連付けられている随意的フィールドを提供することができ、該フィールドはデータ要素が個人的識別情報（ＰＩＩ、Personally Identifiable Information）に関するものであるか否かを定義する。さらに、各データ要素については、関連する随意的な更なるフィールドを提供できるのであり、該フィールドはデータ要素が機密（ＣＳ、sensitive）であるか否かを定義する。

したがって、データ要素は１つ以上の異なるデータ要素サブ区分へと分類できることに留意されたいのであり、例えば、オペレーショナルデータ、一般データ、又はエンドユーザ識別可能情報（ＥＵＩＩ（End User Identifiable Information））データ等を含め得る。インターネット上でトラッキングイベントを記録するための無線装置が次のことを行えるようにするために類似の区分をデータ要素に割り当てることができ、荷物及びそれらに関するイベントをトラッキングできるようにし得る。

幾つかの異なる主体又は当事者がシステムを用いることができる。表３はこれらの異なる当事者を示し、幾つかの例と共に簡潔な説明を提供している：

以下の説明では、各データ要素がデータ機関に割り当てられているものと仮定する。データ機関は、各データ要素が第三者と共有できるか否かを決定するためのデータアクセス規則を、決定することができる。

したがって、通常は、各データ要素は、１つ以上のデータ機関に属するかこれと関連付けられている。データ機関は通常は１つ以上の例えばデータベース内に規則を記憶しているのであり、該規則は、誰がデータにアクセスできるか、彼等が何にアクセスできるか、いつにアクセスが可能とされるか、彼等がどのような態様でデータにアクセスできるか、及び、アクセスの目的等を決定する。データベースは、データ機関によって更新され得る。

さらに、データ機関はデータ要素の所有割当をなし得る。換言するに、各データ要素は例えばデータを提供するシステム又は装置等の特定のソースと通常は関連付けられている。また、通常は、データ機関は各データ要素を区分化する。

データ所有者又はソースは次のことを指定できる：誰が自己のデータを使用できるか、どのチャンネルを介して良いか、いつそれを用いて良いか、及び、どのような目的のために用いて良いか。例えば、データ所有者は、個人データはセキュアなチャンネルを介してのみアクセス可能とでき、他方でオペレーショナルデータはセキュア化されていないインターネット接続を介してアクセス可能とすることができる。そして、データ機関は適切な規則を指定してデータの使用態様について実装することができる。

データへのアクセスを要求している当事者は、データ要求主体、データユーザ、又は顧客と呼ばれることができる。例えば、データにアクセスする当事者はLondon Heathrow やLondon Gatwick等の空港とすることができるも、原理上は、任意の当事者がシステムを用いてデータにアクセスすることができ、許可済みである限り個々の航空会社や他のユーザ等もアクセスすることができる。システムにアクセスする当事者はuserid又はcustomer ID等によって（一意的に）識別されていることができ、これは空港や航空会社以外の主体（例えば、地上荷捌き人）と関連付けることができる。

有線や無線インターネット等のセキュアチャンネルがデータ伝達に用いられた場合、セキュアチャンネルが用いられたこと又はこれから用いられることを示すための識別子又は手段を提供する。最後に、以下の説明においては、データ所有者が次のことについて制限を課せないものと仮定する：データ機関がデータにアクセスすること。

通常、信頼性データベースと称されるデータベースは、情報又はデータの記録のために提供される。通常、データベースはＲＡＭ等の記憶手段内に格納される。データベースは次のような構造を有していることができる：
１． データ機関は、航空会社や空港等の幾つかの異なるユーザを有している；
２． 各ユーザは、データ機関によって、信頼レベルを割り当てられている。信頼レベルは例えば低位、中位、又は高位とすることができる；
３． 各信頼レベルは、それに関連付けられている１つ以上の区分を有している；
４． 区分はデータ要素の名称を含む。データ要素は、荷物イベント等のイベント内に含まれる情報の粒度的単位として認識できよう。一部の例示的荷物イベントは上述の表２にて示されている。

信頼レベルは共有レベルとも呼ばれることができる。ユーザ又は顧客は、自己の最も信頼されたパートナーと共有したいと所望する区分又はイベントを、選択することができ、それらを「高位」レベルにグルーピングすることができる。また、これらの者は、中間レベルでの共有を所望し得るのであり、この場合には「中位」を選択できる。既定では、「高位」又は「中位」に割り当てられていない区分／イベントについては、これらは最低の共有レベル（「低位」）に割り当てられる。

高位／中位／低位についての同じプロセスを用いて、顧客、又は、ユーザのパートナーに関して区分グルーピング（categories grouping）の適用をなす。ユーザは自己のスタッフを同じ高位／中位／低位共有レベルへとグループ化することもできる。応答データセットに対しては個人識別可能情報及び機密データについてのさらなるフィルタリングを適用することができる。

システム運用
本発明の実施形態について、図１のアーキテクチャ図を参照して、且つ、図２の流れ図を参照して、且つ、図３のメッセージシーケンス流れ図を参照して、以下説明する。以下の説明では、コンポーネント１２９，１３１，１３３として示されている例示的な荷物旅程機能は、図１のＳＩＴＡ信頼性機能１００とは別個のコンピュータ又はサーバ１２０上で実装されているものと仮定する。勿論ではあるが、コンポーネント１２９，１３１，１３３の機能は信頼性機能１００内にて提供され得るのであり、つまり、ＡＰＩ１２９を要さずにデータを荷物旅程アプリケーション１３１へと伝達される。

先ず図３に転じるに、該図は異なる機能的コンポーネントがどのようにして互いに通信するかを示しており、通信は当業者に知られている有線又は無線の通信プロトコルによっている。プロトコルはサービスコール即ち情報をこれらのコンポーネント間でデータ又は情報を送ることができ、これらのコールは通常は矢印で表され、その矢印の方向がコールの仕向けられる機能的コンポーネントを指し示すものとなっている。具体的な例を挙げるに、図１及び図３の図式化における異なる機能的コンポーネント間のコールは、REST\JASON型のＡＰＩコールである。もっとも、図１の特定の用途又は機能的コンポーネント内においては、データ交換を許す通信可能な接続で足り得るということに留意されたいのであり、この場合にはＡＰＩコールは不要となる。図３には、信頼性フィルタと呼ばれる別個の機能的コンポーネントが示されているが、該フィルタの機能は通常はモジュールアプリケーション１２５内でなされるのであり、故にアプリケーション１２５及びフィルタについては同じ参照符号たる１２５が与えられていることに留意されたい。

図１の図式化を参照するに、航空会社やデータにアクセスすることを望むユーザ等のアクセス主体は先ず、例えば電話若しくはラップトップ機等のモバイル型通信機器等のコンピューティング装置上で、アプリケーション１２１を起動する。図２の流れ図においては、アプリケーションの起動行為はステップ２０１によって示されている。アプリケーションは通常はアプリケーションプログラミングインターフェース（ＡＰＩ）を含む。

そして、ユーザは、顧客ＩＤ（CustomerID）又はユーザＩＤ（user ID）と呼ばれる顧客識別子並びにパスワードを、アプリケーション１２１内へと入力し、ローカルに或いはリモートに認証がなされる。

例えば、アプリケーション１２１上で実行されているＡＰＩは、ＲＥＳＴ／ＪＳＯＮＡＰＩ認証コール（REST＼JSON API authentication call）を、ＨＴＴＰＳ上で、認証モジュールを実行しているリモートなコンピュータ又はサーバに対して通すのであり、該コールは通常はＡＰＩエンドポイント１２３を介してなされる。代替的には、ＳＯＡＰ ＸＭＬウェブサービスコール（SOAP XML Web Service call）を用いることができる。

ユーザのコンピューティング装置又はモバイル機器１２１からアプリケーション前モジュール１２２への認証コールは、ＡＰＩ認証キートークンによって保護され得るのであり、このトークンは通常は認証コールの一部としてアプリケーション前モジュールに追加される。次の擬似コードは例示的な認証トークンについて示す：

この例示的なトークンはアルファニューメリック型データ等の情報やデータを含む。この例では、データはキーバリューペアで定義されておりこれは．ＸＭＬフォーマットとされているが、当業者はたのフォーマットについても知っているであろう。データは上述の任意の１つ以上のキーバリューペアを備えていることができ、例えばユーザ、アクセス主体、又はデータ要求主体を識別するデータ（useridと称する）を含み得る。

この具体的な例では、ユーザ又は顧客識別子はＬＨＲとされていることが分かり、換言するに、ユーザ識別子はLondon Heathrow等の空港と関連付けられている一意的な識別子である。

さらに、上述の例示的トークンにおいては、データ機関は、次のいずれかであることが分かる：Air Canada（登録商標） (AC)、British Airways（登録商標） (BA)、 Air Europa（登録商標） (UX)。勿論、原理的には、キー内において１つ或いは２つ以上のデータ機関が指し示されていることができる。

このようにして、トークンはデータ機関に関連している。例えば、Air Canadaがデータ機関であれば、Air Canadaが自社のデータ閲覧者又はユーザとしてHeathrowを設定することができる。したがって、トークンはユーザを識別するのみならず、データ機関をも識別するのであり、故にどの規則を適用すべきかについてシステムが決定できるようにする。例えば、Heathrowは、データ機関との関係性について集合体を伴うトークンを有しているかもしれない。以下においてさらに詳述する規則は、トークン内に埋め込まれていることができるが、これは上述はされていない。したがって、キーをトークン内に埋め込んでおくことができる（即ち、LHR.GroundStaff（ロンドンヒースロー．地上職員））。キーを用いてデータベースを検索して閲覧に関する特定の許可を決定することができる。

したがって、ログオン時においては、ユーザは通常は、データとの関係でどのデータ機関が関連付けられているか又は戻されたデータからどのデータ機関が推測されるかについて述べる。

ユーザが認証されたらば、ユーザのモバイルシステム上で実行されているアプリケーション１２１は、ユーザがデータを要求することを許す。

これを達成するために、マスタ荷物識別子（MasterBagID）等の幾らかの追加データを、アプリケーション１２１を実行している装置に提供するか入力する。MasterBagIDの別称としては、master_bag_idもある。master_bag_idキーは通常は関連付けられている値を有している。これは次の例示的フォーマットによるアルファニューメリック型ストリングたり得る：

他のフォーマット、例えば識別子＝12555も用いられ得る。ライセンスプレート番号（ＬＰＮ）を荷物アイテムと関連付けることができる。したがって、master_bag_idは通常はＬＰＮと関連付けられている。各荷物アイテム又はＬＰＮは通常は、旅客と関連付けられている。

そして、顧客若しくはユーザ識別子並びにマスタ荷物識別子等のデータは、ユーザアプリケーション１２１からＡＰＩエンドポイント１２３へとサービスコール３０３を介して伝達される。

事実について述べるならば、コール３０３の一部として、任意のデータベースキー及び関連付けられたバリューを、コール３０３内にて伝達することができるということに留意されたい。荷物に関連付けられているデータに関する上述の具体的な例においては、master_bag_idがデータベースキーであり、これが特定の荷物についてのデータに対してアクセスを与えることになる。サービスコールはBagSearchByPassenger service call（旅客による荷物検索サービスコール）３０３と呼ばれることができ、これは、サービスコール３０５によってＡＰＩ１２３からモジュールアプリケーション１２５（荷物旅程信頼性アプリケーション（bag journey trust application）１２５とも呼ばれる）へと伝達される。

図１に示す例においては単一のプレアプリケーション１２２のみが示されているが、実際には幾つかの異なるアプリケーション前モジュールを提供できる。例えば、ユーザアプリケーションから受信された異なるタイプの要求について、１つのアプリケーション前モジュール又は内部ＡＰＩを提供することができる。コンピュータ又はサーバ１００内には、要求内で定義されているデータのタイプに基づいて、ユーザアプリケーションから受信中の要求のタイプを決定するモジュールを、提供できる。そして、要求は、以下においてさらに詳述するように、処理のために適切なアプリケーションモジュールへと転送され得る。

図２の流れ図においては、荷物情報を要求するステップはステップ２０３と称される。

そして、モジュールアプリケーション１２５は、データを送るのであり、該データは通常はユーザ識別子又はデータ要求主体識別子及び関連付けられている検索キーを含み、送る行為はデータパススルーとしてなされ、送る行為は先述の認証トークンを伴ってなされ、送る行為は荷物旅程ＡＰＩエンドポイント１２９へと仕向けられており、送る行為はＲＥＳＴ／ＪＳＯＮコール３０７等のサービスコールを介してなされている。認証トークンは随意的である。

図１に不図示であるも、通常は、コンピュータ若しくはサーバ、又は機能的コンポーネント１２０によって受信されたトークンは、図３に示されているトークン検証器１３０を用いて検証される。

通常はユーザ若しくは要求主体識別子並びに関連する検索キー若しくは荷物識別子を備えるデータは、コール３２２を介して、荷物旅程アプリケーション１３１へと、ＡＰＩエンドポイント１２９から伝達される。

トークン検証が成功したと仮定すると、ユーザ若しくは要求主体識別子並びに関連する検索キーを受信したことに応答して、荷物旅程アプリケーション１３１は、通常はサービスコールを用いて（このことは図３では不図示であるが）、データベース１３３に対してクエリを発する。そして、通常は、認証トークンはもはや不要となる。

データベース１３３へのクエリは通常はCassandra型クエリと呼ばれ、ＣＱＬ言語にて実装され得るのであり、当業者ならば知っているであろう。クエリは、通常は供されたmaster_bag_IDについてEventDataを抽出するのであり、換言すれば、master_bag_IDに関連するEventDataが抽出される。マスタ荷物識別子は通常は一意的であることに留意されたい。つまり、BagjourneyデータベースをクエリするためにはcustomerIDを要さないということである。

合致するキーがデータベース内で見つかったならば、データベース内に格納された合致するキーに関連付けられているデータは、通常はサービスコールを介して荷物旅程アプリケーションへと戻される。

原理上では、荷物旅程アプリケーションへたった１つのデータピース又はデータ要素が返される場合もあるが、通常は複数のデータ要素が返されるのであり、各データ要素はイベントと関連付けられており、表２との関係で上述したようなもの等であり、通常はキーバリューペアとして返される。

荷物旅程アプリケーション１３１は、顧客識別子又は／及びマスタ荷物識別子と関連付けられているデータを、bagjourneyＡＰＩ１２９コールへと、コール３２３によって戻す。そして、bagjourneyＡＰＩ１２９は、コール内のデータを荷物旅程モジュールアプリケーション１２５へと渡すのであり、これは更なるサービスコール３２５によってなされる。コール３２３，３２５は、トークンを有さないパススルーコールである点でコール３０５，３０７と似ている。これらの機能的コンポーネントはデータを伝える。なぜならば、モジュールアプリケーション１２５（換言すればフィルタリングモジュール）がコール間に配置されているからである。

以下の擬似コードは荷物タグイベントデータ（bag tag event data）３２３，３２５等の例示的データを示すのであり、これは荷物旅程アプリケーション（bag journey application）１３１によって戻され得るのであり、通常これはREST\JSON APIコールによってＡＰＩ１２９へと戻されるのであり、そして該ＡＰＩはデータをモジュールアプリケーション１２５へとデータを渡す：

このデータは．ＸＭＬフォーマットであることに留意されたいのであり、該フォーマットではアルファニューメリック型のデータを用いてキー／バリューペアを定義している。通常、受信されたデータはアプリケーション１２５によってローカルキャッシュ１２７内にて格納される。

そして、（アプリケーション前モジュール１２２内の）モジュールアプリケーション１２５は、受信データに関連付けられているデータ機関を決定する。このことは、受信されたトークン内にて以前定義されたデータ機関に基づいてなされ得る。例えば、トークン内に埋め込まれたデータ機関を読み出し得る。

以下においてさらに詳細に説明されるように、トークン情報は荷物信頼性データベース（bag trust database）へのキーとして用いられるのであり、換言すれば、これは次のことを可能とする：信頼性データベース若しくはストア１１５又はキャッシュされた規則１２７を検索することを可能とすること。

この段階では、図２の流れ図のステップ２０５にて、アクセス主体又はデータ要求主体識別子（即ち、顧客ＩＤ（customer ID））を決定又は識別できるものの、該ステップは原理的にはより早期の段階においても行い得る。

そして、（例えば、荷物タグイベントデータ等の）コール３２５にて受信されたデータ要素又はアイテムの各々は、ステップ２０７にて、識別される。

そして、アプリケーション１２５はGetRules（規則取得）サービスコール３２７を信頼性アプリケーション（trust application）１０７に対して行うのであり、データ機関又は／及び（or/and）ユーザ識別子たるUser IDを定義する決定されたデータが含まれている。該コールは先述の認証トークンを含み得るのである。なぜならば、該トークンは、データ機関情報及びユーザ識別情報若しくはデータ要求主体を識別するデータ、の両方を含むからである。

通常、信頼性アプリケーション１０７は、信頼性ストアデータベース１０７に問合せを発して、データ機関及びユーザ識別子と関連付けられている１つ以上の規則を決定する。

規則は戻されてコール３２４にてアプリケーション１２５によって受信されるのであり、これらは規則データベース１２７又は１１５から着信する。随意的な規則キャッシングはメモリ又は記憶手段内においてなされ得る。

どうであれ、取得されたアクセス規則については図２のステップ２０９にて検索をなすことができ、荷物イベントデータ（bag event data）と関連付けられている各データ要素について適切な規則を決定できる。ステップ２１１にて次のことに関して決定がなされる：アクセス主体（accessing entity）又は顧客識別子（customer identifier）又はデータ要求主体（data requestor）について規則が存するか否か。何も規則が見つからなかった場合、ステップ２１９にて、アクセス拒否メッセージを返し得る。

代替的に、アプリケーション１２５が、アクセス主体又はデータ要求主体と関連付けられている規則があると決定した場合、ステップ２１３にて、該規則に従ってデータがフィルタリングされる（ステップ２１３）。ステップ２１５にて、荷物情報（baggage information）等のフィルタリング済みデータ要素は、（例えば、信頼性ＡＰＩエンドポイント（trust API endpoint）１２３とされ得る）コールを介して荷物旅程ユーザアプリケーション（bag journey user application）１２１へと戻されることができる。処理はステップ２１７にて終わるのであるが、同じ又は異なるデータ要求主体によって該処理を反復し得ることに留意されたいのであり、この主体は荷物識別子（bag identifier）と関連付けられているデータを要求するか要求しないかすることができる。

以下の説明は規則及びフィルタリングについてさらなる詳細事項を提供する。

モジュール又はアプリケーション１２５内においては、以下の機能が定義されており、先述されかつ上述された完全荷物タグイベントデータ（full bag tag event data）は、データ機関によって定義された規則であって取り出された規則に従って処理される。

以下の表４はデータ共有規則についての幾つかのパラメータを示す。

規則は、共有可能な区分コレクション（collection of categories）を備えている。各データ要素には、階層構造内での区分が割り当てられる。データ要素たる「PNRAddress（ＰＮＲアドレス）」についての例は「CustomerContent\Credentials（顧客コンテンツ＼クレデンシャル）」である。好適には、データ要素の全部又は一部は、階層構造のなるべく根幹部側に区分されるのであり、これによって複雑な構造を予防する。規則は、イベント及び区分の両側面からのフィルタリングを可能とし得る。

個別のデータ要素と関連付けられているデータ区分の間でマッピングがなされて各データ区分についてランキングをもたらす。

規則は、ユーザ信頼レベル（user trust level）及び各データ区分についてのランキングに応じてデータを処理することを定義していることができる。代替的に又は追加的には、規則は、各データ要素と関連付けられている定義済み区分に従ってデータを処理する定義していることができる。通常は、規則はデータベース又はメモリ１２７内に格納されている。

１つの例では、規則は次のようにデータを処理できる：データ要求主体が「高位」の信頼レベルを有している場合、「高位」、「中位」、又は「低位」の関連ランキングを有しているデータ要素の全てがデータ要求主体に戻されるかこれが利用可能とされる。

さらなる例では、規則はデータを次のように処理できる：データ要求主体が「低位」の信頼レベルを有している場合、「低位」の関連ランキングを有しているデータ要素のだけがデータ要求主体に戻されるかこれが利用可能とされる。「中位」又は「高位」の関連ランキングを有しているデータ要素は、データ要求主体に戻されないのであり又はこれが利用可能とはされない。

選択可能なデータが膨大な量で存在している故に、使いやすさは大事であるということに留意されたい。したがって、データを別のユーザ又はデータ要求主体へと提供するユーザ又はデータ提供者は、機能的なコンピュータ若しくはサーバ１２０並びに関連データベース１３３を用いて、自己にとって最高に信頼しているパートナーやグループ等と共有したいと所望する区分又はイベントを定義でき、或いはそれらを「高位」レベルで関連付けることができる。代替的に又は追加的には、データ所有者又はデータ源は、各データ区分と関連付けられている信頼レベル又はランキングを定義できる。

同様に、データ提供者は、共有についての中間的なレベルを定義でき、その場合「中位」を選択し得る。既定では、「高位」又は「中位」に割り当てられていない区分／イベントは、最下位の共有レベル（即ち、「低位」）に割り当てられる。

「高位」、「中位」、又は「低位」とする類似の区分化プロセスは、データ提供者関連の顧客パートナーをグループ化するために、区分グルーピングの適用に用いることができる。

同様に、ユーザ又はデータ提供者は、自己のスタッフを類似の「高位」、「中位」、又は「低位」の共有レベルにグループ化又は関連付けできる。

応答データセット（response data set）については、ＰＩＩ及び顧客機密データに関してのさらなるフィルタリングをも適用できる

先述のように、ユーザがアプリケーション１２１を用いてログインしてデータを要求した場合、信頼性アプリケーション１０７は、信頼性ストア１１５から、アプリケーション１２１へのサービスコール３２４を介して、要求されたデータのデータ機関によって定義されたランキング規則を、取得する。

そして、アプリケーション１３１からコール３２３，３２５によって返されたデータと関連付けられているデータ要素の各々は、各データ要素と関連付けられている先述の定義済み区分に従って高位、中位、又は低位として区分化される。

サービスコールによって信頼性ストア１１５から読み出されたランキング規則は、任意の所与の区分済みフィールドについて、ユーザが該フィールドのデータにアクセスすることが許されるか許されないかについてアプリケーション１２５が決することを可能とする。

１つの簡略された例について論じよう：

管理者主体１０１がイベントたる「SimpleMessage」を「Operational/General」と分類したと仮定する。

データ機関たるＢＡは、区分たる「Operational/General」を高位としてランキングする

データ機関たるＢＡは、ユーザたるＬＨＲを高位としてランキングし、ユーザたるＬＧＷを低位としてランキングした。

ユーザたるＬＨＲがログインしてデータ機関たるＢＡに属するデータを要求した場合について検討するに、該要求に係るデータは区分たる「Operational/General」を含んでおり、ランキング規則が取得され、ランキング規則は次のように述べている：区分たる「Operational/General」は高位のランキングを有しているユーザのみと共有され得ること。ＬＨＲは高位ランキングを有しており、故に、「SimpleMessage」を含む「Operational/General」として区分されたデータが返される。

ユーザたるＬＧＷがログインしてデータ機関たるＢＡに属するデータを要求した場合について検討するに、該要求に係るデータは区分たる「Operational/General」を含んでおり、ランキング規則が取得され、ランキング規則は次のように述べている：区分たる「Operational/General」は高位のランキングを有しているユーザのみと共有され得ること。ＬＧＷは低位ランキングを有しており、故に、「SimpleMessage」を含む「Operational/General」として区分されたデータはマスキングされるか省略される。

この機能をどのようにしてアプリケーション１２５が実装するかについてさらなる詳細事項を提供するのが以下の擬似コードである。該擬似コードにおいては、サービスコールは第１のブラケット括弧を前に伴って示されている一方で、サービスコールの一部として送られたデータ要素は括弧たる（）内に含まれており、各異なるデータ要素はコンマによって区切られており、非機能的なコメントは／／の後に設けられている。角括弧たる［］はデータのアレイが返されることを表している：

１．規則を取得（データ機関，ユーザ）
ａ． データ機関規則＝TrustDB.GetDataAuthorityRules(DataAuthority)
ｂ． データ要素リスト［］＝
TrustDB.DataAuthorityRules.GetViewableDataElements(DataAuthorityRules, User)
ｉ．レベル＝TrustDB.User.Level //TrustDB.UXI.Level= High
ｉｉ．区分［］＝TrustDB.GetCategories(High) //[Operational, General,EUII…….]
ｉｉｉ．要素１［］＝TrustDB.GetElements(Categories[]) //[ utcDateTime,flightNo, destination, ….]
ｉｖ．要素２［］＝TrustDB.GetOwnElements(User) [stowageDevId]
ｖ．要素［］＝Elements1+Elements2 // utcDateTime,flightNo, dest, stowageDevId ….]
ｃ． データ要素リストのリストを返す［］／／これがBagEvent（荷物イベント）の個別フィールドである（即ち、PaxStatus（旅客状態））

このことから分かるのは、ステップａ）にて次のことがなされるということである：要求されるデータ機関についての規則が決定されること。

ステップｂ）では、データ要素リストが構築される。このことは、先ずｉ）でユーザと関連付けられている信頼レベル（trust level）を決定することによってなされる。そして、ステップｉｉ）で信頼ユーザレベル（trust user level）についての区分が決定される。第３番目に、ステップｉｉｉ）にて、Elements1（要素１）と呼ばれるデータ要素についての第１のセットが、以前に決定された区分を用いて構築される。

第４番目に、ステップｉｖ）にて、ユーザについて第２のデータ要素セットが構築される。そして、最後に、DataElementsList（データ要素リスト）と呼ばれる完全な要素セットが構築されるのであって、これは第１のデータ要素セットを第２のデータ要素セットと連結することによってなされる。これによって、特定の信頼レベルを有する特定のユーザに関連付けられている完全なデータ要素セットがもたらされる。

そして、フィルタ１２５が応答を構文解析して当該特定ユーザによって閲覧可能とされていてはならない任意のフィールドを除いておく。この所作は次の擬似コードによってなされ得る：

データ要素リスト＝規則（機関，ユーザ）
各要素について＝BagEvent.element.string() if !DataElementsList[].contains(var)
イベント．要素，値＝““ //FreqFlyerID= !DataElementList FreqFlyerID=”” ;
ＰＮＲ＝!DataElementList pnr=””

したがって、上述の擬似コードによって、信頼区分（trust category）に基づいて特定の値又はデータ要素が除かれることが理解できよう。したがって、ユーザが関連付けられている信頼レベル（trust level）を有し得ることが理解できよう。さらに、各信頼レベルは、１つ以上の関連付けられている区分を有し得る。さらに、各区分は、１つ以上のデータ要素と関連付けられていることができる。

ステップ３３１において、フィルタリングされたデータは、フィルタから外部ＡＰＩ３０３へと戻されるのであり、通常はアプリケーション１２５へのサービスコールを介してこれがなされる。

以下の具体的擬似コードにおいては、特定の旅客と関連付けられているお得意様番号（frequent flyer number）及び旅客氏名記録詳細事項（passenger name record details）は除去されているのであり、これらを容易に識別できるようにするためにこれらは囲い込み線を付したボールド体で示されているのであるが、通常はこのようなボールド体のフォーマッティング及び囲い込み線のフォーマッティングは戻されるデータには含まれていないことに留意されたい。

１． FilteredData（フィルタリングされたデータ）を、ＦＦ及びＰＮＲ詳細事項を除いた上で返す。

したがって、ユーザによってアクセス可能ではない具体的なデータ要素は““で置換されるのであり、これによってより少ないデータが送られることになる。

規則抵触（Rule Clash）
データに幾つかの異なるデータ機関が関連付けられている場合、各データ機関は同じデータ要素について異なる信頼レベルを定義し得る。

各データ機関と関連付けられている規則が抵触する場合、データ機関は先例的規則を用いて抵触を解決することができる。例えば、最厳格規則を適用するということが可能である。例示するに、ロンドンヒースロー（ＬＨＲ）等の空港の場合を想起されたいのであり、例えばＬＨＲはAirCanadaの荷物をスキャンするスキャナの位置に関するデータ等を提供する。この場合、AirCanadaが旅客情報についてのデータ機関である。ＬＨＲは、空港スキャナ（Airport Scanners）に関するデータについてのデータ機関である。AirCanadaは、低位信頼アソシエイトがスキャニングに関する全てのオペレーショナルデータにアクセスすることを許すが、ＬＨＲは地理的位置情報については商業的機密性故にアクセスを制限する。例えばCharles De Gaulle（ＣＤＧ、Air Franceの低位信頼アソシエイト）等の別の空港では、接続するAirCanadaフライトについてＬＨＲ接続荷物についてチェックしようと試み得る。したがって、ＣＤＧはスキャニングデータにアクセスしようとする。より厳格な規則である故に、ＬＨＲの規則が適用されるのであり、このため、ＣＤＧはＬＨＲスキャナ位置に関してはアクセスを得ることができない。

一般に、自社の全旅客旅程に関しては航空会社がデータ機関であり、一般に、空港内のイベントについては空港がデータ機関である。

システム構成
システム構成中に、信頼性管理者１０１は、全てのデータイベント（又はフィールド）を、表１を参照しながら、区分に割り当てることができる。このデータは通常は信頼性ストアデータベース（trust store database）１１５内に格納される。

信頼性管理者（trust administrator）は、次の行為をなして信頼性ストア又はデータベース（１１５，１２７）に対してデータ投入をなし得る。
１． セットアップ
ａ． 管理者によって行われる
ｉ． 航空会社又は空港データ機関（ＤＡ、data authority）及び関連主体を追加
ｉｉ． 例えば上記表１に従ってデータ要素を区分に追加
ｉｉｉ． 例えば上記表２に従って所有者をデータ要素に追加
ｉｖ． 区分を信頼レベルに追加（ＴＢＳ）、信頼レベルは初期的には以下の通り：
１． パートナー
２． 高位
３． 中位
４． 低位
５． スタッフＬ１
６． スタッフＬ２
７． スタッフＬ３
ｂ． 航空会社又は空港管理者又は他の主体は、通常は、信頼レベルを追加することを許されている
ｃ． 航空会社又は空港管理者はデータ機関によって以前設定された既定値を変更することができる（区分内の要素、並びに、各信頼レベルからどの区分が閲覧可能であるかの点について）
２． SetTrustLevels（信頼レベルを設定）
ａ． データ機関は、構成済み関連主体の信頼レベルを、設定する。
ｂ． データ機関は、信頼レベル又はパートナー種別に応じて、「いつ」データが閲覧可能となるかを設定する
ｃ． データ機関は、誰がデータ閲覧をしたかについてのレポートを引き出すことができる。
３． データの閲覧
ａ． 関連主体は、自分達に共有されたデータを、閲覧することができる。
ｂ． 自分達が閲覧することを許されていないデータは、南京錠アイコンで表されており、マウスオーバによってデータ機関に連絡されたいとの案内が与えられる。

さらに、データ機関（例えば航空会社等）は、ユーザを高位、中位、又は低位のランキングに位置付けることによって、アクセスをユーザ又はデータ要求主体（例えば空港等）に与える。このことは、ユーザを識別するデータ及び関連付けられている信頼レベルをデータベース１１５内に格納することによって達成される。通常、異なる複数のユーザを識別するデータはデータベース内に格納されるのであり、各ユーザは関連付けられている区分を有しており、該区分は同じであるか又は異なるものであることができる。

さらに、データベース１１５内には１つ以上のデータ区分を定義するデータも格納されており、各区分は、ユーザに関連付けられている高位・中位・低位ランキングと同じものに従ったランキングに関連付けられているのである。

上述からして、システム・装置・方法は、例えばデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、パーソナルデジタルアシスタント、携帯電話、スマートフォン等のコンピューティング装置を含み得ることを諸兄らならば理解できよう。

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

上述の有線又は無線通信ネットワークは、パブリック、プライベート、有線、又は無線ネットワークたり得る。通信ネットワークは、１つ以上のローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット、モバイルテレフォニ通信システム、又は衛星通信システムを含み得る。通信ネットワークは、任意の適切なインフラストラクチャを備えることができ、これには、銅ケーブル、光ケーブル又はファイバ、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、及びエッジサーバ等が含まれる。

上述のシステムは、グラフィカルユーザインターフェース（ＧＵＩ）を備え得る。本発明の実施形態は、オンスクリーンＧＵＩを含み得る。ユーザインターフェースは、例えば、ウェブサイト内に埋め込まれたウィジェットの形式で、装置用のアプリケーションとして、又は専用のランディングウェブページとして提供され得る。ＧＵＩを実装するためのコンピュータ可読プログラム命令は、例えば次のようなネットワークを介してコンピュータ可読記憶媒体からクライアント装置へとダウンロードされることができる：インターネット、ＬＡＮ、ＷＡＮ、及び／又は無線ネットワーク。命令は、クライアント装置内のコンピュータ可読記憶媒体内に格納され得る。

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

コンピュータ可読プログラム命令は、非一時的かつ有体的なコンピュータ可読媒体上に格納されていることができる。コンピュータ可読記憶媒体は、次の１つ以上を含み得る：電子的記憶装置、磁気的記憶装置、光学的記憶装置、電磁気的記憶装置、半導体記憶装置、可搬型コンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、静的ランダムアクセスメモリ（ＳＲＡＭ）、可搬型コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリスティック、フロッピー（登録商標）ディスク。

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

Claims (28)

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. 実行時に請求項１５〜２７のいずれか１つに記載の方法を行わせるコンピュータ可読製品。