JP2005509953A6 - 情報の収集、処理、および分配システム - Google Patents

Abstract

本発明のシステムは、機密データの完全性を維持しながら、共同作業主題に関する複数ネットワーク・ユーザ間の共同作業を容易にする。１実施態様では、システム（２００）には、Radiant Collaboration サブシステム（２０２）およびRadiant Sanitizer/Guard サブシステム（２０６）が含まれる。ガード（２０２）は、入力情報（２０６）を受信し、必要に応じて入力情報（２０６）を再フォーマットし、特定の受信者への機密情報の配布に関する事前定義規則に基づいて入力情報を処理および入力情報（２０６）を無害化する。無害化された出力が、受信者に特有な方式でガード（２０４）によって提供される。共同作業サブシステム（２０２）は、会議に含まれる１つまたは複数のドキュメントを識別するコラボレータの会議を確立し、および、機密情報の分配を管理する留意規則に従ってそのような１つまたは複数のドキュメントを個々のコラボレータに表示することを可能にする。このようにして、機密データへのアクセスに関して異なる制限を有する可能性があるコラボレータ間での共同作業が容易になる。システム（２００）は、自国セキュリティに関係する公的および民間のセクタ団体間における情報の共有を含めた、様々な状況において有用である。

Description

本発明は、一般に、複数情報ソースおよび複数の情報受信者を含むネットワークにおける情報の使用および交換の管理に関する。具体的には、本発明は、事実上リアルタイムで、ネットワーク内の情報の交換を管理し、かつ事前定義規則に基づいて複数ソースからの情報を処理することに関する。本発明は、機密データを含む情報の配布および使用の管理に関して特に利点がある。

様々な状況において、共同作業研究、問題解決、および共通分析ツールの共有などのために、ネットワーク環境内における様々なソースからの情報にアクセスして該情報を処理することを可能にすることが望ましい。そのような状況において生じる可能性がある問題のいくつかには、レガシー・ソースおよび対象システムに関連する複数のフォーマット、データ構造、およびプロトコルにいかに対応するか、秘密の（classified）、極秘の（confidential）、専有の（proprietary ）、またはその他の機密の（sensitive ）情報へのアクセスをいかに管理するか、および個人のプライバシーおよび他の公民権をいかに保護するか、ということが含まれる。

テロリスト容疑者を追跡する場合を例にとる。テロリストを識別および追跡するのに有用な情報が、多くのソースに存在する可能性がある。たとえば、様々な国の情報団体内の様々なデータ・レポジトリは、テロリスト容疑者のみならず、既知の偽名やテロリスト容疑者に関する他の情報を識別し得る。そのような情報は、通信傍受、情報共有、現場作業などに基づく可能性がある。他の潜在的に関連する情報ソースには、旅行予約データベース、電話記録、国境往来記録、インターネット使用パターン、兵器購入記録、金融取引記録、警察接触記録、組織加入を反映した記録、例えば航空学校記録のような対象分野における特殊訓練を示す記録、試行または実際のネットワーク・セキュリティ違反記録、特定の化学薬品または生物薬品にアクセスする個人の記録などが含まれ得る。

多くの様々な受信者は、そのような情報またはその分析結果にアクセスすることから利益を得ることができる。そのような受信者には、容疑人をより良好に識別および追跡するためにそのような情報を収集して処理することを望む情報機関、航空会社、兵器販売者、国境役人、警察、ビザおよびパスポートの発行の役割を担う政府機関が含まれ得る。

情報を処理および共有しようという試みは、現在、多くの要因によって阻害されていることが理解されるであろう。まず、情報は、様々なレガシー・システムに関連する多くのソースに存在する。それらのシステムは、しばしば、閉じたデータ構造、データ・フォーマット、およびメッセージ・プロトコルを有する専有システムである。たとえば、航空機予約データベースおよび情報機関データベースは、相互運用性のための開いたシステムとしては必ずしも設計されていない。したがって、そのようなシステム間における直接的な情報交換は、通常は支援されていない。さらに、情報ソースは、政府団体および民間団体によって制御される。その結果、情報の共有は、プライバシーおよび他の市民の自由の問題に拘わる。ソースは、国境を越える可能性があり、セキュリティの問題を生じる。国内の境界内や１つの団体内においてでさえ、異なる受信者は、異なるレベルの機密情報へのアクセスを可能にする異なる安全許可または内部権限を有することがある。

そのような要因はすべて、情報の処理および交換について十分に慎重なことが必要であ
ることを示す。しかし、リアルタイムの処理および交換の必要性は、より逼迫している。
同様の必要性が、別の状況においても当てはまる。たとえば、会社は、所有情報に関するポリシーの準拠を保証するために、会社のネットワーク・ノードから電子通信を自動的に遮蔽し、一方でプライバシーの問題に対処することを望む可能性がある。団体内では、電子通信は、電子メール内容ポリシーおよびある情報に対するアクセスの制限に関して管理し得る。独自のセキュリティ問題を有する金融機関および他の団体も、事前定義規則に従った慎重であるが迅速な情報交換の処理と伝送の監査から、利益を得ることが可能である。同様に、医療研究も、プライバシーの問題に適切に対処し得ることを条件として、様々なレガシー・ソースから患者の記録にアクセスすることから利益を得ることが可能である。そのような必要性が、そのような状況で利用可能な従来のシステムによって、完全には対処されていないことは明らかである。

本発明は、複数の情報ソースおよび複数の受信者が関与する状況内での情報交換を管理する方法および装置（「ユーティリティ」）を対象とする。具体的には、本発明は、対象となる問題に対処するために利用可能な情報およびツールの範囲を拡大するように、異種ソースからの情報を共有すること、および様々な受信者間において情報を共有することを可能にすることに関する。これには、技術的および社会的な問題が含まれる。技術的には、そのような情報交換を可能にすることには、様々なレガシー・システムに関連する様々なデータ・フォーマット、データ構造、およびメッセージ・プロトコルに対応することが含まれる。社会的には、そのような交換を容易にすることには、リソースの供給を促進する信頼環境を構築するように、機密情報、プライバシー、および市民の自由の利益を保護することが含まれる。本発明は、実質的にリアルタイムの情報交換の状況において、ならびに共同作業の状況において、そのような問題に対処するツールを提供する。これに関して、本発明は、警告を生成するために広範な相互作用を監視することを可能にし、かつ情報交換の監査を提供する。したがって、本発明は、テロリスト容疑者の識別および追跡を含む多くの非常に重要な状況において有利に使用され得る。

本発明の１態様によれば、マシンベースのユーティリティが、メッセージから機密主題を選択的に無害化にして、再送信用の無害化メッセージを生成するように動作する。すなわち、ユーティリティは、単に２進送信を作成したり、決定を送信したりするだけでなく、機密主題を除去するかその他の方法で保護して、送信用にメッセージを無害化にする。関連する方法には、事前定義無害化規則に基づいてメッセージを無害化にするコンピュータベースの無害化ツールを確立する工程と；第１外部システムに対してメッセージを受信するようにツールを動作する工程と、該第１メッセージが識別された受信者に対する機密情報およびクリーン情報を含むことと；メッセージ内の機密情報を識別して、機密情報に関してメッセージを無害化し、それにより、クリーン情報を含む無害化メッセージを生成するように、コンピュータベース無害化ツールを動作する工程と；識別された受信者に無害化メッセージを送信するように、コンピュータベース無害化ツールを動作する工程と；が含まれる。このユーティリティによって、識別された受信者がクリーン情報にアクセスし得るように、メッセージを迅速に無害化し得る。

１実施態様では、ユーティリティは、様々なユーザに対する情報の分配を管理するために、複数の規則集合にアクセスし得る。規則集合は、受信者の識別事項、ユーザ受信者の所属もしくは国籍、公的もしくは民間のセクタ団体など受信者の状況、または他のパラメータに基づくことが可能である。関連する無害化工程には、複数の規則集合を含むデータベースにアクセスすることと、識別された受信者に関連するパラメータを使用して規則集合を選択することと、メッセージに対して該規則集合を適用してメッセージを無害化することとが含まれる。情報配布に関する複数レベルのセキュリティを維持しながら、複数の受信者に情報を分配することを可能にすることが目的であるシステムに関して、このユー
ティリティは特に有利であることが理解されるであろう。

本発明の関係する態様によれば、無害化ユーティリティが、所与のメッセージの複数のバージョンを複数の受信者に送信するように動作する。関連する方法には、分配のためにメッセージを受信することと；情報分配に関する第１ポリシーおよび第２ポリシーに関連付けられた少なくとも第１および第２の受信者をそれぞれ識別することと；入力メッセージを無害化して、第１受信者に送信される第１無害化メッセージを生成することと；入力メッセージを無害化して、第２受信者に伝送される、第１無害化メッセージとは異なる第２無害化メッセージを生成することと；が含まれる。本発明によれば、これに関して、ほぼ無限の数の受信者に対応し得る。したがって、本発明は、多面的防衛／警備活動または情報協力および複数当事者を含む公的または民間のセクタ活動など、迅速かつ広範な情報の配布が重要である状況において特に有利である。

上述した無害化ユーティリティを使用して、ネットワーク・ユーザ間の共同作業を、それらのユーザが機密情報に関して異なる規則を受ける場合でさえ、可能にし得る。これに関して、共同作業には、１）複数ユーザにほぼ同時に処理されるように情報を複数のネットワーク・ユーザに利用可能とすること（「複数ユーザ並行処理」）、２）複数ソースからの情報を共通のツールまたはツールセットによって処理するように利用可能とすること（「複数ソース集合」）、および３）共通のツールまたはツールセットを複数ユーザによって使用するように利用可能とすること（「ツール共有」）の少なくとも１つが含まれる。そのような共同作業は、本発明により容易になり、一方、共同作業主題の提供者は、主題の完全な所有権および制御を維持することが可能になり、それにより、共同作業者間の信頼をさらに増強することが促進され、共同作業の程度がさらに増強される。この共同作業は、共同作業システムと無害化ユーティリティとをインタフェースすることによって達成される。無害化ユーティリティは、たとえば、共同作業主題の複数の例を複数ユーザに提供することが可能であり、その場合、各そのような例は、ユーザに特有の規則に従って無害化される。共同作業システムは、特定の処理ツールを共同作業「会議」またはすべてのシステム・ユーザに利用可能とし、かつ追加の情報を提供して、共同作業主題をコラボレータの様々なシステム上に提示することを補助するようにさらに動作し得る。

本発明の別の態様によれば、ユーザのそれぞれに特有のコンテンツベースの規則に従って、情報を共同作業環境の複数ユーザに利用可能とするユーティリティが提供される。たとえば、このユーティリティを使用して、複数ユーザ並行処理型共同作業を容易にすると共に、機密データの完全性も維持し得る。ユーティリティは、第１ユーザ・システムおよび第２ユーザ・システムが、入力情報に基づいて、共同作業主題にほぼ同時にアクセスするのを可能にする共同作業システムを含む。入力情報は、第１システムおよび第２システムの一方によって、および／または他の１つまたは複数のソースによって、提供し得る。共同作業システムは、入力情報を受信して、第１ユーザ・システムおよび第２ユーザ・システムを識別するように動作する。ユーザ・システムは、たとえば、共同作業主題の以前に確立された分配リスト、入力ソースからの１つまたは複数のメッセージに含まれているアドレス情報、または第１ユーザ・システムおよび第２ユーザ・システムによるもしくはその代わりのアクセス要求に基づいて、識別し得る。共同作業システムは、識別されたユーザ・システムのそれぞれに関連するコンテンツベース規則にアクセスし、コンテンツベース規則に基づいて入力情報を処理し、第１ユーザ・システムおよび第２ユーザ・システムについてそれぞれ第１出力および第２出力を確立し、かつ出力へのアクセスを可能にするようにさらに動作する。このようにして、第１システムおよび第２システムを、コンテンツベース規則に従う共同作業主題に関する共同作業に使用し得る。

１実施態様では、共同作業システムを使用して、機密データを保護するために、複数の受信者に配布される情報をろ過する。したがって、たとえば、コンテンツベース規則を使
用して、機密情報の送信に関するポリシー（たとえば、特定のユーザ、共同作業グループ、もしくは画定エンクレーブによって確立された、または所与のソースと受信者との関係に基づいて確立された）を実施することや、異なる国籍、安全許可、状況（公的または民間のセクタなど）、もしくは機密情報に対する権限を有するユーザ間の共同作業を容易にし得る。したがって、たとえば、コンテンツベース規則を、受信者、またはその受信者の国籍、安全許可、タイトル、所属、もしくは他の属性の識別事項に基づいて、特定の意図した受信者に関連付けることが可能である。ろ過は、情報を保護する規則に準拠するように機密情報を除去または修正することを含む可能性がある。たとえば、プライバシーまたはセキュリティ関連事項を保護するために、名前を削除もしくは変更（一般化など）することが可能であり、または、機密データを削除することが可能であり、または、特定の意図した受信者のアクセス制限に対応するように、データの精度を変更し得る。複数ユーザに関連する複数規則を使用することによって、共同作業主題への個々のユーザのアクセスが制限される可能性がある環境においてさえ、共同作業が容易になる。

本発明の別の態様によれば、コンテンツベース規則に従って、複数のソースからの情報を共同作業環境のユーザ・システムに利用可能とするユーティリティが提供される。たとえば、このユーティリティを使用して、複数ソース集合型の共同作業を容易にすると共に、機密データの完全性を維持し得る。ユーティリティは、第１ソース・システムおよび第２ソース・システムから第１共同作業主題および第２共同作業主題をそれぞれ受信して、出力を受信するユーザ・システムを識別するように共同作業システムを動作することを含む。共同作業システムは、識別ユーザ・システムに関連するコンテンツベース規則に基づいて入力のそれぞれを処理して、第１入力およびコンテンツベース規則集合を使用して確立された第１出力と、第２入力およびコンテンツベース規則集合を使用して確立された第２出力とへのユーザ・システム・アクセスを提供するようにさらに動作する。

ユーティリティは、様々な状況において使用し得る。たとえば、複数の構成要素プロバイダおよびシステム・インテグレータが関与する製品開発工程に関連して、参加者によって定義された規則によって管理される開発工程に必要な程度まで、共同作業システムを介して構成要素プロバイダのそれぞれからの仕様情報をシステム・インテグレータまたは他の構成要素プロバイダに提供し得る。法執行、情報収集、および規制準拠の状況では、プライバシー、市民の自由、および他のポリシー、または法的保護を実施する規則に基づいて、民間および／または公的のセクタ・ソースからの情報を適切な政府団体に提供し得る。このようにして、共同作業を促進する信頼環境が助長される。ユーティリティは、たとえば、追跡されている個人の複数の目撃例に関する情報を組み合わせて改善された位置情報を提供するなど、複数の入力を組み合わせてまたは融合して、向上されたデータを生成するように動作することも可能である。

本発明の別の態様によれば、無害化ユーティリティが、セキュリティのためにメッセージの高分解能分析を可能にするように、帰納的パース・ツールと共に実施される。これに関して、ユーティリティは、メッセージを受信し、メッセージが所望のサイズのトークンへとパースされるようにメッセージを帰納的にパースし、パース済みトークンに対して無害化規則を適用して少なくとも１つの汚染トークンを識別し、汚染トークンに関してメッセージを無害化して、識別受信者へ送信される無害化メッセージを生成するように動作する。トークンのサイズは、無害化規則に基づいて決定することが可能であり、または、主題の性質、処理上の制限、もしくは他の基準に基づいて決定し得る。したがって、所望であれば、セキュリティ対象を同時に保護しつつクリーンな情報の送信を最大限にするように、ユーティリティは高度の分解能でメッセージを分析し得る。

本発明の別の態様によれば、無害化ユーティリティが、様々なフォーマットに関するメッセージに対応するように適合される。上記のように、ある安全な送信環境は、メッセー
ジ・フォーマットの拡大を特徴とする。したがって、複数のシステム間で情報を効率的に取得して共有するためには、複数のメッセージ・フォーマットに効果的に対応することがしばしば必要である。本発明によれば、自動情報サニタイザには、インタフェース・エンジンと無害化エンジンが含まれる。インタフェース・エンジンは、複数の外部フォーマットの仕様情報を記憶するデータベースにアクセスし得る一般的な処理モジュールを有する。特定のメッセージまたは複数のメッセージの集合について、インタフェース・エンジンは、データベースにアクセスして、対応する仕様を得て、それにより、そのメッセージ・アプリケーションに合わせてインタフェース・エンジンを構成し得る。無害化エンジンは、記憶されている無害化規則に基づいて、所与のメッセージを無害化するように動作する。インタフェース・エンジンは、無害化エンジンが複数の外部システムのいずれかとインタフェースするのを可能にするように、無害化エンジンに関連付けられる。

これに関して、ユーティリティは、複数外部ソースと関連する複数の入力フォーマットおよび／または複数の意図した受信者に関連する複数の出力フォーマットに対処し得る。複数の入力フォーマットの場合、インタフェース・エンジンは、入力メッセージのフォーマットを識別し、データベースにアクセスして対応する仕様を得て、無害化エンジンによって分析するためにメッセージをトークンにパースするように動作する。様々なテキストおよび画像フォーマットを含めた、多くの入力フォーマットをこれに関してサポートし得る。画像フォーマットに関して、インタフェース・エンジンは、撮像情報をパースして、無害化エンジンによって処理するために理解可能な要素を識別し得る。複数の出力フォーマットについて、インタフェース・エンジンは、無害化エンジンから少なくとも１つの無害化メッセージを受信し、識別受信者に関連付けられたフォーマットを識別し、データベースにアクセスして対応する仕様を得て、得られた仕様に従って無害化メッセージをフォーマットするように動作する。かくして、自動情報サニタイザは、複数の入力および／または出力のフォーマットを多くの無害化応用例に望ましいように支援し得る。

本発明およびそのさらなる利点をより完全に理解するために、ここで図面と関連づけながら以下の詳細な説明を参照する。
以下の詳細な説明では、テロリストの追跡、事前飛行乗客スクリーニング、および国境警備ならびに多国間警備活動など、様々な自国警備および防衛の応用例に関して、様々なユーザ間の共同作業を促進するための、Radiant Trust システムと表記する字訳、無害化、および共同作業システムに関して、本発明を説明する。これらは、本発明の特に有利な応用例を示すが、上記で留意したように、本発明は、民間セクタ用途、公的セクタ用途、および公的／民間セクタ用途を含む様々な状況において適用可能である。したがって、本発明の様々な態様は、以下で詳細に説明する状況に限定されるものではない。

以下の説明は、システムのアーキテクチャおよびネットワーク環境を記述するRadiant Trust システムの概述から開始する。その後、Radiant Sanitizer Guard サブシステムについてより詳細に説明する。以下の最終セクションは、Radiant Collaboration サブシステムの詳細な記述を含む。

Ｉ．Radiant Trust システムの概述
図１は、本発明のRadiant Trust システムの関係、利害関係者、および参加者のサイクル１００を示す。Radiant Trust システムの目的の１つは、ユーザ間に信頼環境を作成することである。情報ソースに関して、信頼のこの環境は、機密情報を保護し、かつプライバシーと他の市民の自由の問題を尊重することによって促進される。このようにして得られる信頼は、情報の共有を促進し、したがって、システム・パートナは、より完全な情報を有し、かつデータのより良好な分析を実施し得る。そのような分析に基づいて、より有用な警告をシステム・ユーザおよび他のユーザに提供することが可能であり、これにより
情報の共有がさらに促進される。

この工程の循環的性質を図１に示す。Radiant Trust システムの図示した実施態様において対処されるリスク１０２には、逃走中のテロリスト１０２ａ、化学、生物学、核、および他の放射能攻撃１０２ｂ、サイバー・テロリスト攻撃１０２ｃ、危険物質の輸送および窃盗１０２ｄ、窃盗、損傷、および汚染を含む物理的攻撃１０２ｅ、ならびに内部者による窃盗および攻撃１０２ｆが含まれる。そのようなリスク１０２は、利害関係者１０４に対して攻撃の脅威を提示する。Radiant Trust システムの図示した実施態様における利害関係者には、政府１０４ａ、重要なインフラストラクチャ１０４ｂ、民間産業１０４ｃ、および一般市民１０４ｄが含まれ得る。そのような利害関係者１０４は、リスク１０２の分析に関連する様々な情報を所有し得る。そのような情報には、攻撃および試行攻撃に関する情報、ならびに、必ずしもリスクを示す可能性がない個々に考慮される情報が含まれ得る。たとえば、旅行産業データベースの記録は、特定の飛行の予約をしているジョン・ドウ（Ｊｏｈｎ Ｄｏｅ）およびジェーン・ドウ（Ｊａｎｅ Ｄｏｅ）について、ジョン・ドウおよびジェーン・ドウの両方をテロリスト容疑者として識別する政府情報機関のテロリスト容疑者監視リストとその情報が関連付けられない限り、リスクを提示しない可能性がある。そのような分析で有用であり得る情報のタイプは、考案され、かつ経験と共に進歩することが予期される分析のタイプと同様に、変化することが理解されるであろう。Radiant Trust システムは、そのような適応性に対応し、かつ、実際、有効性が以前は完全には調査されていなかった可能性のある情報ソースの使用を促進するように設計される。これに関して、Radiant Trust システムは、異なる政府機関間、潜在的に競合する民間団体間、および公的セクタ団体と民間のセクタ団体との間の調整を以前は阻害していた多くの問題に対処することに留意することが重要である。

そのような情報は、利害関係者１０４によって、１つまたは複数の信頼情報交換部１０６に提供される。そのような情報交換部は、情報の共有を管理するRadiant Trust 機能を実施すると共に、機密情報を保護し、かつプライバシーおよび他の市民の自由の問題に対処する。示した実施態様では、そのようなシステムは、情報機関１０６ａ、民間機関および法執行機関１０６ｂ、政府特別許可ＩＳＡＣ１０６ｃ、および民間産業ＩＳＡＣ１０６ｄによって動作される。以下でより詳細に議論するように、ある実施態様では、たとえば民間産業ソースから政府受信者に渡される情報は、民間セクタ団体によって動作される第１交換部と政府団体によって動作される第２交換部を通過する可能性がある。情報交換部は、データ・フォーマットの字訳や、その他の方法による技術的な適合性の保証、ならびにあるデータ処理および共同作業機能の提供に関するいくつかの機能を実施することも可能である。結果として得られる情報は、機密情報に関して無害化し、かつ再フォーマットすることが可能であり、ミッション・パートナー１０８に利用可能とされる。これに関して、そのような情報は、継続問合わせもしくは配布を管理するコンテンツベース規則に応答して、連続的または定期的に利用可能とすることが可能であり、または、そのような情報は、ミッション・パートナー１０８からの特定の問合わせに応答して提供し得る。

示した実施態様では、ミッション・パートナーには、情報機関１０８ａ、民間機関ならびに法執行機関１０８ｂ、国際機関ならびに外国政府１０８ｃ、および民間産業パートナー１０８ｄが含まれる。そのようなミッション・パートナー１０８は、様々な異なる分析を実施して、様々な異なる出力を提供し得る。実際に、これに関して創造性を促進することが、Radiant Trust システム１００の目的である。図示したように、そのような分析の１つの結果は、リスク１０２を直接低減または排除する防止および禁止努力であってよい。さらに、ミッション・パートナー１０８は、分析、警告、および報告を利害関係者１０４に提供し得る。たとえば、報告されたサイバー攻撃に関する分析を提供して、サイバーテロリストによって使用された方法に関するいくつかの情報を提供し得る。この情報は、ファイアウォールをパッチするか、それ以外の方法でネットワーク・セキュリティに対処
するために、利害関係者が使用し得る。潜在的なテロリスト活動の警告を、地方自治体や、航空会社などの前線の民間産業団体に提供し得る。セキュリティ情報に基づく報告を利害関係者１０４に提供して、利害関係者により良好に情報を提供し続ける、および／または利害関係者がリスクを評価するのを補助し得る。

同様の情報を、ミッション・パートナー１０８が情報交換部１０６に提供することも可能である。たとえば、そのような情報を情報交換部１０６に報告して、利害関係者に中継することが可能であり、関連する利害関係者はプライバシーの問題のためミッション・パートナーには知られないようにする。さらに、そのような情報は、他のミッション・パートナー１０８が関心を抱く可能性がある、データ融合または他の処理を経て決定された強化セキュリティ情報を包含し得る。したがって、システム１００は、関与する参加者に関して閉じたシステムの状況においてさえ、情報の共有および処理の程度の一層の強化が達成されるように、自己増長することが理解されるであろう。以下で議論するように、そのようなシステムは、一般に閉じていないことが予期される。実際、信頼が得られ、かつ利益が実証された時には、システムが連結されて、国境および公的／民間セクタの境界を超える信頼の四方八方に延びる（radiating ）ウエブが作成されることが予期される。

図２Ａは、Radiant Trust システム２００の構成要素の図を示す。図示したように、システム２００には、一般に、Radiant Collaboration サブシステム２０２およびRadiant Sanitizer/Guard サブシステム２０４が含まれる。そのようなサブシステムのそれぞれについては、本説明の後のそれ自体のセクションにおいてより詳細に説明する。図２に示すRadiant Sanitizer Guard ２０４は、フォーマット・データおよび自由フォーマット・データを含み得る入力情報２０６を受信する。これに関して、フォーマット・データとは、Radiant Trust システム２００の所望の内部フォーマットで既にフォーマットされたデータである。自由フォーマット・データは、関連するソースのレガシー・システムに従ってフォーマットし得る。Radiant Trust システム２００の威力の１つは、様々なフォーマットに対応する能力である。これにより、より広範なソースからの情報を利用可能となる。これに関して、そのような自由フォーマット・データは、入力モジュール２０８によって受信し得る。以下でより詳細に説明するように、次いで、この自由フォーマット・データを、変換モジュール２１０によって内部フォーマットに変換または字訳して、ＸＭＬタグに関連付け、それ以外にＸＭＬマークアップ・モジュール２１２によって処理し得る。次いで、結果として得られるフォーマット・データは、フォーマット・データ入力モジュール２１４に提供され、そこで、事前にフォーマットされたデータと同じ方式で処理される。

入力モジュール２１４は、サニタイザ２１３の入力ポートを構成する。サニタイザ２１３は、入力に含まれている機密情報を保護する自動工程を実施する。これに関して、入力は、特定の情報ソースと意図した受信者とに関係するコンテンツベース規則を実行するように、自動的に処理される。具体的には、Radiant Trust システムの参加者は、どの情報を誰と共有し得るかを決定する規則を開発し得る。そのような規則の性質と規則を実行する方式については、以下でより詳細に議論する。しかしながら、機密情報の無許可の配布を防止すると共に、できる限り多くの情報をRadiant Trust システムにおける使用および外部ユーザに利用可能とすることが望ましいことに留意されたい。これは、望ましいサイズまたは分解能のＭＡＧを使用して入力情報を情報オブジェクトにパースし、各情報オブジェクトに関してコンテンツベース規則を適用することによって達成される。各情報オブジェクトは、選択的に削除、修正、または出力ストリームに渡すことが可能である。したがって、示した実施態様では、パース規則データベース２１６が、入力情報をＭＡＧＳにパースする工程を管理する規則を記憶する。次いで、ポリシー・プロセッサ２１８が、ポリシー・データベース２２２に記憶されているコンテンツベース規則を適用して、事前に定義されたコンテンツベース規則に準拠して、受信者に特有の出力を構築する。この出力
は、再フォーマット・プロセッサ２２４に提供され、再フォーマット・プロセッサ２２４は、意図した受信者のシステムによって使用される形態にデータを再フォーマットする。そのようなフォーマットを定義する情報は、フォーマット・データベース２２６の表に記憶される。最終検査モジュール２２８は、出力に関する最終検査を実施して、コンテンツベース規則によって示されたポリシーに準拠していることを保証し、結果として得られる出力は、意図した受信者の１つまたは複数のシステムに送信するために、出力モジュール２３０に提供される。

サニタイザ２１３には、監査ログ２２０と保全ツール２３２も含まれる。監査ログ・データベース２２０は、受信した入力を識別する完全な記録と、コンテンツベース規則を実施するために入力に対して施された修正と、サニタイザ２１３によって送信される出力とを情報ソースおよび受信者を識別する情報と共にコンパイルするように、モジュール２１４、２１８、２２８、および２３０とインタフェースされる。このようにして、ユーザは、情報が事前定義規則のみに従って配布されたことを確認することが可能であり、それにより、信頼がさらに増す。さらに、情報の根拠を提供し、かつ情報のあらゆる誤使用に対処するのに適切であるとき、情報の送信を検査し得る。保全ツール２３２は、Radiant Sanitizer/Guard サブシステム２０４の更新、修復、そうでない場合は保全に必要な機能を提供する。これに関して、システム２００の確実な動作が、システム２００の目的の達成に必須であることが理解されるであろう。

したがって、Radiant Sanitizer/Guard サブシステム２０４は、それ自体で、内容と、ソースおよび受信者の識別事項とに基づいてそのような情報交換を管理する事前定義規則に従って、ネットワーク内の複数ソース間およびネットワーク内の複数の受信者間における情報をほぼリアルタイムで共有することを可能にする。これは、システム２００の目標を達成することに対する著しい前進を意味する。しかし、場合によっては、複数のシステム受信者間の場合のように、特定のドキュメントまたは主題に関する共同作業を可能にすることが望ましいことがある。これはRadiant Collaboration サブシステム２０２によって容易になる。具体的には、サブシステム２０２は、コラボレータの会議を確立し、会議に含まれる１つまたは複数のドキュメントを識別し、そのようなドキュメントならびに共同作業工程から得られるそのようなドキュメントに対する変更を、コンテンツベース規則および表示などに関するシステム特定のパラメータに従って、個々のコラボレータに表示されるようにし、会議またはシステム２００に共通のツールを使用して、ドキュメントに含まれる情報を処理する。

具体的には、環境マネジャ・モジュール２３６は、管理される共同作業環境を定義する入力２３４を受信する。そのような入力は、たとえば、会議の参加者、共同作業の主題となるドキュメント、および参加者システムの特定のパラメータを定義し得る。共同作業のドキュメントまたは他の主題は、共同作業データベース２３８に記憶することができる。

共同作業データの表示が、共同作業を可能にするように、インタフェース２３４を介して会議参加者の各々に提供される。会議参加者へのそのような出力をコンテンツベース規則に従って管理するために、Radiant Collaboration サブシステム２０２は、Radiant Sanitizer/Guard システム２０４とインタフェースされる。このインタフェースは、無害化データベース同期化アプリケーション２４０によって管理される。具体的には、このアプリケーション２４０は、フォーマット・データまたは自由フォーマット・データを入力ポート２０８または２１４に提供し、かつ出力ポート２３０から無害化データを受信するのに必要なすべての動作に対応する。そのような動作には、サニタイザ２１３への会議参加者を識別することと、複数の出力を意図した会議参加者と関連付けることが含まれる。そのような無害化された出力は、アプリケーション２４０によって環境マネジャ２３６に提供され、環境マネジャ２３６は、インタフェース２３４を介した参加者に対する特定の参
加者システム・パラメータに従って情報の出力を管理する。これに関して、環境マネジャ２３６は、ある処理ツールをすべての会議参加者に利用可能とするように、あるアプリケーション２４２を呼び出して、データが自己記述となるように、可視化特性および制御特性をそのデータと関連付けることが可能である。可視化特性および制御特性のデータとのそのような関連付けは、知覚ネットワーク・アプリケーションによって実施し得る。

会議に利用可能とし得るツールの例は、強化データを生成するように複数ソースからデータを収集する融合アプリケーションを含む。Radiant Collaboration サブシステム２０２は、共同作業努力の結果に基づいてシステム２００の参加者にとって関心のある通知を発行する、通知マネジャ・モジュール２４４を含む。たとえば、会議参加者が共同作業してテロリズムのリスクを識別する場合、Radiant Sanitizer/Guard サブシステム２０４を介して適切な通知をシステムのユーザに利用可能とし得る。保全および管理ツール２４６も、増強された信頼性についてサブシステム２０２を更新および修復するために、サブシステム２０２の一部として提供される。Radiant Trust システム２００は、システム・ユーザを認証する管理認証サービス２４８をさらに使用し得ることが理解されるであろう。

図２Ｂは、Radiant Trust Sanitizer ／Guard サブシステムの処理構成２５０を示す。示した実施態様では、サニタイザは、複数の入力チャネル２５２を介して入力を受信する。アクセス許可の確認、再フォーマット、および所望の分解能への入力情報のパースなど、様々な異なる入力チャネル特有の機能を実施するために、スクリーン２５４が各入力チャネルに提供される。入力情報の例示も、情報の各宛先人について生成し得る。次いで、プロセッサ２５６が、宛先人プロファイルに基づく処理を含めて、宛先人特有の処理を実施する。出力ガード２５８が、例えば十分な交換レベルを有していないチャネルまたは個人への機密情報の提供などの、不適切な情報配布から保護するために、各宛先人およびチャネルに提供される。次いで、情報が、複数の出力チャネル２６０を介して出力される。図示したように、構成は、各入力チャネルに関連する宛先人の数と各入力チャネルに関連する出力チャネルの数に応じて、大きく変化し得る。図２Ｂには示されていないが、異なる入力チャネル２５２からの情報を１つの出力チャネル２６０に向けてもよいことが理解されるであろう。

１つの入力チャネル・システム２６２に関連する処理構成要素を、図２Ｃにより詳細に示す。具体的には、第１チャネル２６４上で受信される入力は、まず、入力を望ましいパース分解能にパースするように、パーサ２６６によって処理され、次いで、パース済み入力は、作業キュー２６８に記憶される。次いで、チャネル特有入力スクリーン２７０が、入力をろ過して、多くの他のチャネル特有タスクを実施する。次いで、プロセッサ２７２が、フィルタ、タスク、および情報の再分類などを含む宛先人プロファイルを適用し、入力情報は、分類ステータスを低減するように修正される。次いで、ガード２７４が、宛先人特有およびチャネル特有のガードすなわち保護機能を実施し、結果として得られる情報は、チャネル２７６に出力される。

上記で留意したように、複数のRadiant Trust システムをネットワーク内において使用して、ユーザ・ドメインにわたる情報の交換に関するポリシーまたはピア・ポリシーの階層を実施し得る。これを図３のネットワーク３００によって示す。このネットワーク３００には、第１のRadiant Trust システム３０２および第２のRadiant Trust システム３０４が含まれる。たとえば、第１Radiant Trust システム３０２は、民間セクタ団体によって動作され、ドメイン３ ３０６およびドメイン４ ３０８などの民間セクタ・ドメイン間の情報交換を管理するように動作し得る。第２Radiant Trust システム３０４は、公的セクタ団体によって動作され、ドメイン１ ３１０およびドメイン２ ３１２など公的団体領域間の情報交換を管理するように動作し得る。Radiant Trust システム３０２および３０４のそれぞれは、情報交換を管理し、かつ関連するドメイン間の共同作業を可能にす
るために、上記で議論したように完全に動作し得る。これに関して、各システム３０２または３０４は、上記で議論したように、情報交換に関するそれ自体のドメイン・ポリシーを実行し、情報交換を連続的に監査し、様々なサービスを提供し得る。

さらに、第１Radiant Trust システム３０２は、第２Radiant Trust システム３０４とインタフェースして、その間における情報交換を可能にし得る。したがって、たとえば、サイバー攻撃に関する情報を、インターネット・サービス・プロバイダなど、ドメイン３
３０６の民間セクタ参加者によって、情報機関などドメイン２ ３１２の政府セクタ参加者に提供し得る。公的セクタ受信者の状況において、またはドメイン２ ３１２の特定の受信者の識別事項に基づいて、領域３のユーザ名が「インターネット・サービス・プロバイダ」などの一般的な名称によって置き替えられることを必要とするコンテンツベース規則を実行するために、ドメイン３ ３０６からの情報を第１Radiant Trust システム３０２によって処理し得る。次いで、第１Radiant Trust システム３０２からの出力が、第２Radiant Trust システム３０４に提供される。第２システム３０４は、情報をドメイン２ ３１２に出力したり、および／または情報をドメイン１ ３１０およびドメイン２ ３１２を含む会議における使用に利用可能としたりし得る。ドメイン２ ３１２内における処理の結果として、または共同作業会議に関連して、警告または報告をドメイン３ ３０６のユーザ、またはドメイン３ ３０６およびドメイン４ ３０８のユーザなどのいくつかのシステム・ユーザに発行することが望ましい可能性がある。たとえば、第１Radiant Trust システム３０２および第２Radiant Trust システム３０４を介して、ドメイン３
３０６のユーザに転送される報告を、ドメイン２ ３１２のユーザによって生成し得る。このようにして、ドメイン２ ３１２の公的セクタ・ユーザは、Radiant Trust システム３０２および３０４によって作成された信頼環境の外部では利用可能でないサイバー攻撃に関する情報へのアクセスを得る。ドメイン３ ３０６のユーザは、サイバー攻撃に関する有用な分析およびフィードバックを受信する。さらに、ドメイン３ ３０６のユーザは、識別事項が、第１Radiant Trust システム３０２およびその関連するドメイン３０６ならびに３０８によって定義された民間セクタ環境を決して離れなかったことを理解して、快適に感じる可能性がある。このようにして、多くの信頼のエンクレーブを画定し得る。

そのようなエンクレーブは、図４に示すように、ピア・グループ、ピア・グループの階層、ピア階層、および階層の階層に構成し得る。示したネットワーク４００には、エンクレーブ４０２ａ〜ｅの第１階層４０２、エンクレーブ４０４ａ〜ｃの第２階層４０４、エンクレーブ４０６ａ〜ｃの第３階層４０６、および独立した緊急サービスエンクレーブ４０８が含まれる。そのようなエンクレーブ４０２ａ〜ｅ、４０４ａ〜ｃ、４０６ａ〜ｃ、および４０８のそれぞれを、Radiant Trust システムを中心とするピア団体のリングとして図４に示す。階層４０２には、民間産業エンクレーブ４０２ａ、法執行エンクレーブ４０２ｂ、情報エンクレーブ４０２ｃ、テロリズム対抗エンクレーブ４０２ｄ、および自国セキュリティ・エンクレーブ４０２ｅが含まれる。階層４０４には、自治体エンクレーブ４０４ａ、州エンクレーブ４０４ｂ、および連邦エンクレーブ４０４ｃが含まれる。階層４０６には、民間産業エンクレーブ４０６ａ、ＩＳＡＣエンクレーブ４０６ｂ、およびインフラストラクチャ保護エンクレーブ４０６ｃが含まれる。この階層は、任意選択の国際エンクレーブを含むことも可能である。

示した階層は、関連するRadiant Trust システムによって実施される機能の特定のシーケンスまたは重要性を必ずしも示すものではないことが理解されるであろう。たとえば、階層４０２の場合、階層構造は、民間産業エンクレーブ４０２ａから自国セキュリティ・エンクレーブ４０２ｅへの一方向の情報の流れを示唆しない。そのような階層規則は、たとえば参加者の合意によって、階層に構築し得るが、示した階層は、単に、好都合な概念的フレームワークを提供しているにすぎない。さらに、示した階層は、参加者間において
定義される可能性がある関係のタイプを限定することを意図していない。したがって、たとえば、階層４０６内に、副階層を画定し得る。たとえば、エンクレーブ４０６ｂのバンキングＩＳＡＣまたはテレコムＩＳＡＣをエンクレーブ４０６ａの特定の民間産業参加者に関連付けることが可能である。

さらに、Radiant Trust システムの図示した拡大は、計算プラットフォームの直接対応する拡大を必ずしも必要としないことを理解されたい。これに関して、所与のシステムの機能を複数のプラットフォーム上で分配することが可能であり、異なるシステムの機能を共通プラットフォーム上で実施し得る。図４に示すように、Radiant Trust ネットワーク４００は、エンクレーブ内、エンクレーブ間、階層間、または階層とエンクレーブとの間の情報交換を適応して可能にする。そのような情報交換は、一般に、少なくとも１つのRadiant Trust システムを含むが、特定の階層に関連付けられたRadiant Trust システムの事前定義シーケンスを必ずしも必要としない。

図５および６は、航空安全の応用例の状況においてRadiant Trust システムを使用して実施されるある処理スレッドを示す。具体的には、図５は、情報機関テロリスト監視リストについて航空機予約システムの記録をクロス・チェックするために使用し得るクロス・チェック・スレッド５００を示す。図６は、テロリスト監視リストを更新するために使用し得る更新スレッドを示す。まず図５を参照すると、産業Radiant Trust システム５０２が、航空産業予約システム５０４から入力を受信する。この場合、入力は、少なくとも乗客名および飛行情報を含む乗客記録である。示した実施態様の産業Radiant Trust システム５０２は、産業ベース団体によって動作される。上記で留意したように、このシステム５０２は、入力フォーマットの変動に対処し、かつあらゆる機密情報を保護するように動作する。

第１のRadiant Trust システム５０２は、少なくとも乗客名を含む情報をクロス・チェック・アプリケーション５０６に転送し、クロス・チェック・アプリケーション５０６は、既存のテロリスト監視リストについて乗客名をチェックする。アプリケーション５０６は、少なくとも乗客名を含む情報と、クロス・チェックの結果合致したか、または合致しなかったという指摘とで、産業Radiant Trust システム５０２に応答する。合致した場合、産業Radiant Trust システム５０２は、たとえば政府団体によって動作される第２のRadiant Trust システム５０８に警告を転送し得る。警告は、航空産業の同業者に転送することも可能である。これに関して、市民の自由の問題または競合の問題に対処するように、機密情報を削除または修正し得る。政府Radiant Trust システム５０８は、識別された警告受信者５１０に警告を分配する。そのような受信者は、法執行局、情報機関、および外国の情報機関または政府を含むことが可能である。

図６は、クロス・チェック・アプリケーション５０６をコンパイルおよび更新し得るスレッド６００を示す。図示したように、監視リスト情報は、様々な情報機関、法執行機関、および外国ソースを含む様々なソースから来る可能性がある。この情報は、政府Radiant Trust システム５０８に提供され、政府Radiant Trust システム５０８は、情報をログおよび確認し、情報を収集して、無害化統合監視リストを生成する。この監視リストは、産業Radiant Trust システム５０２に提供され、産業Radiant Trust システム５０２は、情報をクロス・チェック・アプリケーション５０６に転送する。図示したように、政府Radiant Trust システム５０８は、関連するポリシー規則に応じて、統合リストを再び未処理または無害化の形態で個々のソースに配布するように動作し得る。

ＩＩ．Radiant Sanitizer/Guard
上記で留意したように、Radiant Trust システムには、Radiant Sanitizer/Guard サブシステムおよびRadiant Collaboration サブシステムが含まれる。Radiant Sanitizer/Gu
ard サブシステムについて、このセクションにおいてより詳細に説明し、Radiant Collaboration サブシステムについては、次のセクションにおいて説明する。

図７は、上述したRadiant Trust システムに組み込むことが可能なSanitizer/Guard サブシステムの概観を提供する概略図である。この場合、サブシステムは、様々な防衛状況において必要とされる可能性がある機密情報に対処する応用例と関連して示されている。図示したように、複数の入力ソース７０２が、様々な機密種別すなわち分類レベルにおいて、情報をシステム７００に提供する。示した例では、そのような分類には、「機密」、「最高機密」、ならびに機密区分情報（ＳＣＩ）が含まれる。この情報は、様々な通信チャネル７０６、７０８、および７１０上で、かつこの場合は指定フォーマットＡ〜Ｄである異なるメッセージ・フォーマットで、報告される。システム７００は、そのデータを、より低いレベルのチャネル７１２および７１４上で宛先人７０４に配布するために必要な分類レベルまで無害化する。宛先人の少なくともいくつかは、入力情報のすべてを受信するのに十分な許可を有していない。すなわち、データの無害化バージョンを見ることのみを許可された宛先人である。示した場合では、出力チャネル７１２および７１４は、分類レベル「機密」および「ＮＡＴＯに関する機密」に関連付けられる。システム７００は、理解または処理し得るフォーマットでデータを報告することによって、様々な宛先人消費者に対応する。フォーマットは、当初の報告フォーマットと同じとするか、またはしないことが可能である。示した実施形態では、出力チャネル７１２および７１４は、フォーマットＣおよびＥのデータに対処するように示されている。すなわち、フォーマットの一方（Ｃ）は入力フォーマットと重複し、他方（Ｅ）は重複しない。

システム７００は、そのような応用例において以前に使用されていた従来の手動サニタイザ端末を補足するか、またはそれに置き換わり、標準的な情報データ通信インタフェースを提供する。システム７００は、手動の無害化によって必要とされる人間の相互作用を除去するシステム概念の範囲内において、十分に信頼性のあるソフトウエアおよびハードウエアを実施する。人間の介入は、各メッセージの解放に必要とされないので、これにより、時間に依存する情報の配信が加速される。また、コンピュータは、同じタスクを全く同じ方式で反復して実施するために依拠することが可能であり、人間のオペレータが被る可能性のある実施のタイプの注意散漫によって影響を受けないので、システム７００は、信頼のレベルも増大させる。

米国の区分セキュリティ・システム内における「必知」主義の適用は、様々なユーザが、選択された情報の副集合および情報コミュニティによって生成された産物のみを受信することを意味する。この情報情報の収集者および情報産物の作成者は、当初、出力のセキュリティ・レベルを決定する責任がある。示したシステム７００を含めて、この情報をその後分配およびさらに処理するシステムは、セキュリティ分類の完全性が維持されることを保証する責任がある。

個々の接触報告などのメッセージの分類は、報告フォーマット内のデータ・フィールドにおける情報の機密性によって定義される。メッセージ情報の全分類を減らし、それにより、メッセージにより広範な解放性を与えるために、接触報告内の特定分野の情報を修正（たとえば変更または削除）し得る。これまで、この行為は、産物配布がより高レベルのアクセスまたは区分を損なわないことを保証するために、オペレータ／分析者よる決定を必要とした。これにより、コマンドおよび制御の戦術意思決定者または視界外兵器システムなど、最終戦術ユーザにとってしばしば時間的に決定的である接触データに、処理遅延時間が追加された。

場合によっては、データおよびデータの分配に使用されるメッセージ・フォーマットの性質により、システム７００は、無害化、劣化、またはスクリーニングが適切に迅速に達
成されることを保証することが可能になる。これは、以下の場合に特に当てはまる：メッセージ・フォーマットが十分に定義かつ制御され、自由テキスト・フィールドを含む場合；そのような自由テキスト・フィールドを結果として得られる外出産物から簡単に排除し得る場合；情報分類およびフォーマット・データ・フィールドを管理する規則が、十分に定義かつ理解されている場合。

示したシステム７００には、一般に、自動データ・サニタイザ（ＡＤＳ）・モジュール７１６ならびにメッセージ分析および生成（ＭＡＧ）モジュール７１０が含まれる。それらのモジュールは、上述した様々な構成要素の機能と同様の機能を含み、分類スクリーニング状況に特有の、特定の機能を提供する。ＡＤＳモジュール７１６は、ＳＣＩを含めて、フォーマットしたマルチレベル分類データを無害化し異なる分類レベルにおいて迅速に配布する自動手段を提供する。モジュール７１６は、ＭＡＧモジュール７１８と共動して、指定通信チャネルから分類データを受け取り、データを無害化し、次いで、ユーザ指定規則に従って再分類して、データが以前に定義されかつ厳密に制御された解放基準の集合を満たすことを確認する。ＡＤＳモジュール７１６は、通常は一般サービス（ＧＥＮＳＥＲ）レベルである、様々なレベルの分類または区分において情報を解放する。システム７００は、分類および／または区分のそのレベルにクリアとされたユーザにのみ情報を配布する。システム７００は、無許可の消費者にはデータを開示または解放しない。

ＭＡＧモジュール７１８は、様々なデータ・フォーマットに対応することに関する問題に対処する。上記で留意したように、機密情報の入力ソースおよび出力宛先人／消費者を定義する様々な外部システムは、データ送信フォーマットの拡大を特徴とする。ＭＡＧモジュール７１８は、これに関して、一般に、２つの変換機能を実施する。まず、モジュール７１８は、入力データを様々な外部フォーマットからＡＤＳモジュール７１６の内部データ表示に変換する。次いで、ＭＡＧモジュール７１８は、内部表示においてＡＤＳモジュールから無害化情報を受信し、そのような情報を宛先人システムの様々な外部フォーマットに変換する。したがって、ＭＡＧモジュール７１８は、様々な外部フォーマットに対処し得ることが理解されるであろう。以下でより詳細に説明するように、ＭＡＧモジュール７１８は、不当に遅延せずにそのような変換機能を実施するように、表構造に記憶された複数の外部フォーマット仕様にアクセスし得る、表駆動サブシステムである。

以下の説明は、一般に２つのサブセクションに分割される。第１に、ＭＡＧモジュール１１８によって実施される様々なインタフェース機能について記述する。そのような機能には、入力データのパースおよび出力データのフォーマットが含まれる。第２に、以下の説明は、ＡＤＳモジュール１１６によって実施される様々な無害化に関係する機能の詳細な議論を含む。

Ａ．ＭＡＧモジュール
図８〜１４は、ＭＡＧモジュールの様々な構造および工程を示す。ＭＡＧモジュールは機密情報の無害化および分配に関する使用について説明され、これに関して特に有利であるが、ＭＡＧモジュールの様々な態様が、他の応用例に関する他の状況においても有用であることが理解されるであろう。これに関して、多くのアプリケーションが、メッセージ・データをパースおよびフォーマットすることを必要とする。そのような機能は、一般に、情報の外部表示と内部（アプリケーション特有）表示との間の変換である。ＭＡＧモジュールは、両方の変換について、簡単に呼び出され、かつ強力なユーティリティを提供する。

図８は、ＭＡＧモジュール機能の概略図である。示した例では、ＭＡＧモジュール８０２は、図７の機密情報処理・分配システムなどの処理システム８００に組み込まれ、処理システム８００によって呼び出すことが可能である。システム８００は、複数の外部フォ
ーマットのいずれかでメッセージ８０４を受信する。モジュール８０２は、受信メッセージ８０４に基づいて入力２０６を受信し、入力８０６を処理して、アプリケーション特有データ表示を反映した変換入力８０８を提供する。次いで、処理済み入力８０８は、再び、アプリケーション特有データ表示を反映した出力８１０を生成するように、システム８００によってさらに処理される。この出力８１０は、次いで、識別宛先人システムの外部フォーマットを反映した処理済み出力８１２を生成するように、ＭＡＧモジュール８０２によって処理される。次いで、システム８００は、処理済み出力８１２に基づいて、出力メッセージ８１４を提供し、たとえば送信するか、そうでない場合は送信に利用可能とする。

以下でより詳細に議論するように、ＭＡＧモジュール８０２は、フォーマット仕様によって帰納的に呼び出され、駆動される。そのような帰納的呼出しにより、モジュール８０２は、特定のパース工程に対処するように、選択可能なパース分能を提供することが可能になる。これに関して、ユーティリティは、メッセージ全体、メッセージ内のデータ集合、データ集合内のデータ項目、およびデータ項目内の副項目をパースし得る。したがって、呼出しアプリケーションが要求するように精確に適応した方式で、データを分析し得る。モジュール８０２は、それにより、メッセージの各そのようなレベルにおいて、様々なメッセージ処理機能の１つの事象を実施し得る（たとえば、抽出、内容確認、検査、および確認）。この機能のすべては、様々な計算環境においてＭＡＧモジュール８０２を再使用することを可能にするプラットフォームおよびアプリケーション非依存ライブラリに基づく。さらに、モジュール８０２によって使用されるデータの内部表示の共通形態により、メッセージ変換が簡単になる。

上記で留意したように、示したＭＡＧ機能は、２つの別々のデータ変換を必要とする。モジュール８０２は、文字指向（ＡＳＣＩＩ）メッセージおよびビット指向（２進）メッセージを含む様々なメッセージ・フォーマットに対処し得る。可能な変換工程は、様々なソースおよび宛先人フォーマットの順列と同様に変更される。図９および１０は、それぞれ、文字メッセージ変換および２進メッセージ変換を概略的に示す。具体的には、それらの図は、ＭＡＧモジュール８０２を組み込んでいる無害化システムを流れる例示的な情報フローを示す。この場合、入力テキストは、文字ベース入力フォーマットで受信され、無害化データは、ビットベース・フォーマットで出力される。

まず図９を参照すると、ボックス９００は、フォーマット・文字ベース・メッセージ入力を示す。入力９００は、有用なデータを抽出し得るいくつかのデータ・フィールドを含んでいる。そのようなデータを抽出する工程は、フォーマット仕様にアクセスすることと、フォーマット仕様を使用してメッセージを様々なフィールドにパースすることと、様々なフィールドから情報を読み出すこととを含む。ボックス９０２は、呼出しアプリケーションによって理解し得る内部データ表示を示す。この場合、内部表示９０２は、データ・フィールドを識別するいくつかのタグ９０４と、ならびに各そのようなタグに関連する内容９０６とを含む。したがって、図９は、外部フォーマットから内部データ表示への入力変換工程を示す。

図１０は、出力変換を示す。ボックス１０００は内部データ表示を表す。このメッセージの内容は、入力メッセージと同じであってもよいし、異なっていてもよい。示した例では、メッセージ１０００は無害化メッセージである（少なくとも傍受の時間（ＴＯＩ）フィールドは、図９に示した入力メッセージから除去されている）。示した例では、メッセージ１０００は、２進メッセージ出力１００２に変換される。２進メッセージ１００２は、識別宛先人システムによって理解されるフォーマットで構成されたメッセージ１０００についてのすべてのデータを含む。同様に、この変換は、対応する外部フォーマットを定義するフォーマット仕様に基づいて実施される。

したがって、ＭＡＧモジュールは、メッセージ逆アセンブリおよび再アセンブリのエンジンを提供する。そのようなモジュール１１００の好ましいアーキテクチャを、図１１に全体的に示す。図示したように、モジュール１１００は、記憶仕様ファイル１１０２にアクセスすることによって、様々な変換工程について構成可能である。仕様ファイル１１０２は、各表がフォーマット仕様およびそのフォーマットの識別子またはリンクを含む関係データベースなど、フォーマットに特有の表に記憶し得る。したがって、様々なフォーマットの詳細は、モジュール１１００の実行可能なソフトウエアの外部、および呼出しアプリケーションの外部にある。モジュール１１００が新しいメッセージ・フォーマット（入力フォーマットまたは出力フォーマット）を処理するために必要とされるとき、ソフトウエアの修正は、一般に必要ではない。そうではなく、新しいフォーマット仕様を仕様ファイル１１０２に簡単に追加し得る。同様に、既存のメッセージ・フォーマットが変更されたとき、またはソース・システムが事前定義規則に違反したとき、ソフトウエアを書き直すことは一般に必要ではない。そのような問題は、一般に、仕様ファイル１１０２のファイルを修正することによって対処し得る。

フォーマットおよび関連する仕様は、標準フォーマットであってもカスタムフォーマットであってもよい。モジュール１１００によって支援し得るフォーマットの例には、ＯＴＨＴ−Ｇｏｌｄ、ＯＩＬＳＴＯＣＫ、ＫＬＩＥＧＬＩＧＨＴ、ＴＡＣＥＬＩＮＴ、ＴＡＣＲＥＰ、ＴＩＢＳ２進、ＥＮＳＣＯＲＥ−ＥＬＤ、ＮＩＴＦ、ＳＥＮＳＯＲＥＰ、ＳＡＲ、ＴＲＥタビュラ、様々なデータベース間フォーマット、および多くの特別フォーマットが含まれる。モジュール１１００は、そのようなフォーマットについて線ごとに、または同様に処理および字訳し得る。米国仮特許出願第６０／２１５，１１４号明細書に記載されているように、特定のアプリケーションについて支援されるフォーマットを選択および定義するために、簡単なユーザ・インタフェースを提供し得る。

したがって、仕様は、コンパイルしたソフトウエアの外部にある。その結果、処理フォーマットが変更されるたびに、ソフトウエアを再コンパイルする必要はない。また、仕様は一般に階層的でもある。すなわち、仕様は、メッセージ全体、データ・グループ、データ項目、およびデータ副項目について定義し得る。したがって、以下で議論するように、モジュール１１００は、ほぼ無制限の深さの分解能およびテキスト分析を実施し得る。さらに、仕様の属性の多くは、継承可能である。すなわち、多くの仕様は、共通系列から発展する。たとえば、２つの仕様は、共通の親から発展した可能性がある。そのような場合、仕様の属性の多くは、親から継承することが可能であり、したがって、仕様の定義を簡単にし、かつ必要な記憶空間を低減する。同様に、様々な仕様の属性の多くは、再使用可能である。たとえば、メッセージが参照するたびに、一年の既知の月を再指定する必要はない。

ＭＡＧモジュールを実施するシステムの基本的なパラダイムは、パース−工程−再アセンブル・パラダイムである。中間工程ステップの例を、この詳細な説明の後のセクションにおいて説明する。パース、パース分解能、継承などの関連する概念は、図１２のパース・ツリー１２００を参照することによってより良く理解し得る。この例では、簡単なドキュメント１２０２を構成する構成要素について考慮する。この場合、ドキュメント１２０２は、セクションのマーキングによって分離されたテキストのセクションからなる。定義されたセクションは、導入１２０４、有効範囲１２０６、参照１２０８、記述１２１０、および勧告１２１２のセクションを含むことが可能である。各記述セクション１２１０は、導入パラグラフ１２１４、一連のセクション本体パラグラフ１２１６、および要旨パラグラフ１２１８にさらに分割することが可能であり、それぞれは、空白行によって分離される。各パラグラフは、ピリオド、疑問符、または感嘆符によって分離された文１２２０に分割し得る。各文は、空白によって分離されたワード１２２２にさらに分割し得る。Ｍ
ＡＧモジュールのパース機能は、帰納的である。すなわち、モジュールは、パース・ツリー１２００の様々なレベルの内容を構成する「トークン」に反復してアクセスし、パースし得る。そのような様々なトークンを記述する仕様は、本明細書では「ＭＡＧ」と呼ばれる。したがって、示した例では、ドキュメントを記述する仕様は、最高レベルのＭＡＧである。導入、有効範囲、参照、記述、および勧告のセクションのＭＡＧは、すべて、ドキュメントＭＡＧの子（children）であり、それぞれは、互いに同胞ＭＡＧである。同様に、各記述セクションＭＡＧは、導入パラグラフＭＡＧ、反復可能本体パラグラフＭＡＧ、および要旨パラグラフＭＡＧの親(parent)である（または、からなる）。親および子の階層は、この例では、文の個々のワードの最低レベルまで続く。したがって、ＭＡＧモジュールは、実質的にあらゆるレベルの処理分解能を提供するために、反復して呼び出すことが可能である。たとえば、メッセージは、「禁句(dirty words) 」を検索するために、ワード・レベルまでパースし得る。そのような状況では、無害化工程は、保護情報の配布について慎重に保護するように適応させることが可能であり、一方、クリーン情報の最大限の送信を可能にする。

また、図１２のパース・ツリーから、ＭＡＧの属性の多くは、関係するＭＡＧから継承することが可能であり、それにより、ＭＡＧの定義および必要な記憶が簡単になることが観察されるであろう。関連するＭＡＧ仕様ツリーは、代替、構成要素、デリミタなどのすべての仕様を含み、テキスト・メッセージをトラバースするために必要なロードマップを提供する。メッセージのテキストを順次パースする際に、メッセージの内容を完全に理解することを可能にするように、仕様ツリーの利用可能なブランチが後に続き、または拒絶される。受容されたブランチに関係するテキストは、分離されて、より高い分解能（構成要素）仕様に提供される。テキストの線が、そのデリミタと長さに基づいて分離および抽出され、次いで、同様の機能を実施する構成要素フィールド仕様に渡され、構成要素サブ・フィールド仕様によって処理されるテキストが分離および抽出される。

仕様は、様々なＭＡＧパラメータを定義する。ＭＡＧパラメータは、ＭＡＧの振舞いの一部を制御するＭＡＧ定義の可変態様である。ＭＡＧ仕様のほとんどのパラメータは、定義する必要がない。通常、これは、そのパラメータ仕様に関連する確認および構築は、実施されないことを意味する。パラメータは、親ＭＡＧから継承することも可能であり、したがって、子ＭＡＧは、親のパラメータの仕様を反復する必要はない。各パラメータについて、仕様のパースおよびフォーマットへの適用可能性によって、要求をグループ化し得る。

パラメータ・タイプの詳細なリストが、米国仮特許出願第６０／２１５，１１４号明細書、ならびにそれに関するユーザ・インタフェース実施態様において提供されている。そのようなパラメータのいくつかには、パラメータの構成要素または親の関係ならびに継承性の仕様、およびフォーマット・タイプ（ＴＡＣＥＬＩＮＴなど）またはフィールド・タイプ（ＯＲＩＧＩＮＡＴＯＲなど）などのＭＡＧのタイプの仕様を含めて、ＭＡＧの識別を可能にする識別パラメータ；デリミタ記号、最大長、および最小長の定義を含めて、ＭＡＧに関連する内容またはテキスト・ドメインを識別し、またはそれを囲むテキストから分離する手段を提供するデリミタおよび長さパラメータ；許可された文字の確認および非データ識別子の検出などの内容制約パラメータ；およびより高レベルのＭＡＧ自体をパースする工程と関連してパースしなければならない構成要素のリストを、各ＭＡＧが指定し得る構成要素パラメータ；がある。この最後のパラメータのタイプは、以下の工程フローの議論を考慮すると、よりよく理解されるであろう。

ＭＡＧモジュールによって実施される工程には、パースおよびフォーマットが含まれる。本発明の示した実施態様の状況では、パースは、入力テキスト・ドメインから内部データ・ドメインへの情報の変換であり、フォーマットは、内部データ・ドメインから出力テ
キスト・ドメインへの情報の変換である。パースは、ＭＡＧ仕様がメッセージにどの程度良好に適応するかに基づいてＭＡＧ仕様が選択される、メッセージ駆動活動であり、一方、フォーマットは、内部データをポピュレートするために、内部データの利用可能性に基づいてテキストが生成される、仕様駆動行為である。

図１３は、ＭＡＧパース機能１３００を示すフローチャートである。機能１３００は、仕様ファイルからＭＡＧモジュールのパース・エンジン構成要素を初期化して（１３０２）、パース・エンジンの初期焦点を最高レベルＭＡＧに設定することから開始される。これには、仕様表から対応する仕様にアクセスする情報ソースの外部フォーマットを識別することと、その仕様を使用してパース・エンジンを構成することとが含まれる。仕様は、最高レベルＭＡＧをも定義する。このＭＡＧは、後続処理の「焦点」ＭＡＧとなる。次いで、ＭＡＧモジュールは、焦点ＭＡＧを使用してパース・エンジンによって処理されるテキストを周囲のテキストから抽出する（１３０４）。具体的には、パース機能１３００の主な目的は、メッセージを外部フォーマットから内部表示に変換することである。これは、外部フォーマットの仕様に基づいて実施される。パース・ツリーの各トークンについて、関連するテキストは、そのＭＡＧに基づいて処理される。

変換前に、ＭＡＧモジュールは、テキストが、内容、長さ、検査合計などについて焦点ＭＡＧ基準を満たすことを確認する（１３０６）。次いで、焦点ＭＡＧがテキストからデータを作成することを要求するかについて判定する（１３０８）。そうである場合、テキストは、内部表示に適切なタイプのデータに変換される（１３１０）。そうでない場合、さらにパースすることが必要である可能性がある。これに関して、ＭＡＧモジュールは、次に、焦点ＭＡＧが子を有するかについて判定する（１３１２）。そうである場合、パース・エンジンの焦点は、現在の焦点ＭＡＧの第１子に設定され（１３１４）、ブロック１３０４、１３０６、１３０８、および１３１０によって定義される工程は、新しい焦点ＭＡＧを使用して反復される。したがって、ループ１３０４、１３０６、１３０８、１３１０、１３１２、および１３１４が、考慮しているアプリケーションに必要なパース分解能を達成するように、特定の系統に沿って反復してパースする工程（「系統内パース工程」）を定義することが理解されるであろう。ブロック１３１２におけるあらゆるそのような反復中に、焦点ＭＡＧが子を有していないと判定された場合、ＭＡＧモジュールは、焦点ＭＡＧが同胞を有するかについて判定する（１３１６）。そうである場合、パース・エンジンの焦点は、現在の焦点ＭＡＧの次の同胞に設定され（１３１８）、系統内パース工程は、この同胞に関して反復される。このようにして、パース・ツリーの様々な系統ブランチを、特定のアプリケーションに必要な分解能にパースし得る。

ブロック１３１６において、現在の焦点ＭＡＧがもはや同胞を有していないと判定された場合、ＭＡＧモジュールは、焦点ＭＡＧが最高レベルＭＡＧであるかについて判定する（１３２０）。そうでない場合、ＭＡＧモジュールは、親が同胞を有するかを調べるために、焦点を現在の焦点ＭＡＧの親に設定する（１３２２）。そのように定義されたループは、最高レベルＭＡＧまでパース・ツリーを通って戻って作業するように、反復し得る。このようにして、ツリーを通って下に作業する際に失われた可能性があるＭＡＧ関係を識別し得る。最高ＭＡＧに到達した後、工程は完了する。

図１４は、ＭＡＧフォーマット機能１４００のフローチャートである。工程は、仕様ファイルからパース・エンジンを初期化（１４０２）して、エンジンの初期焦点を最高レベルＭＡＧに設定することによって開始される。上述した工程と同様に、これには、外部宛先人システムのフォーマットを識別することと、対応する仕様表にアクセスしてパース・エンジンを構成することとが含まれる。メッセージを内部アプリケーション特有表示（たとえばデータ・フォーマットにおける）から外部宛先人フォーマットに変換するために、目標フォーマットに変換するのに必要なパース分解能にメッセージをパースすることが必
要である。したがって、ＭＡＧモジュールは、次に、焦点ＭＡＧが現在の焦点ＭＡＧの子によるテキスト作成を定義するかについて判定する（１４０４）。そうである場合、焦点は、現在の焦点ＭＡＧの第１子に設定される（１４０６）。次いで、ブロック１４０４および１４０６によって定義されたループは、焦点ＭＡＧが子によるテキスト作成を定義しないことをＭＡＧモジュールがブロック１４０４において判定するまで、反復される。この時点で、必要な処理分解能は、焦点ＭＡＧに関して達成されている。この場合、ＭＡＧモジュールは、焦点ＭＡＧによって定義されたパラメータに従って、焦点ＭＡＧに関連する内容を内部表示（データなど）から目標フォーマット（テキストなど）に変換する（１４０８）。次いで、結果として得られるテキストを分析して、テキストが、内容、長さ、検査合計などについて焦点ＭＡＧ基準を満たすかを確認し（１４１０）、あらゆる適切なデリミタが、結果として得られるテキストに適用される（１４１２）。

次に、ＭＡＧモジュールは、焦点ＭＡＧが同胞を有するかについて判定する（１４１４）。そうである場合、焦点は、現在の焦点ＭＡＧの次の同胞に設定され（１４２０）、先行パースおよび変換工程が反復される。焦点ＭＡＧが同胞を有していない場合、ＭＡＧモジュールは、焦点ＭＡＧが最高レベルＭＡＧであるかについて判定する（１４１６）。そうでない場合、焦点は、現在の焦点ＭＡＧの親に設定され（１４１８）、結果として得られるループは、パース・ツリーを経て戻って機能して、下に作業した際に失われた可能性があるあらゆるＭＡＧ関係を識別するように反復される。ブロック１４１６において、焦点ＭＡＧが最高レベルＭＡＧであると判定されたとき、工程は完了する。

図７のシステム７００の状況において、上述したＭＡＧモジュール７１８は、ＡＤＳモジュール７１６を様々なソース・システムおよび宛先人とインタフェースさせるように動作する。ＡＤＳモジュール７１６の動作について、ここで記述する。

Ｂ．ＡＤＳモジュール
図１５は、ＡＤＳモジュール１５００の概略図である。モジュール１５００は、外部宛先システム１５０４に解放するために、無害化規則に従って、外部ソース・システム１５０２からのフォーマット・データを自動的に修正または無害化し、それにより、宛先システムは、アクセスを許可された元のデータの部分のみを受信する。モジュール１５００には、一般に、入力コムズ・モジュール１５０６、メッセージ・プロセッサ１５０８、出力ガード１５１０、ダウングレーダ１５１４、および出力コムズ１５１２が含まれる。入力モジュール１５０６は、外部ソース・システム１５０２によって指図される通信プロトコルを支援し、外部システム１５０２によって入力モジュールに提供されたメッセージ・セグメントから完全なメッセージを形成する。次いで、結果として得られる完全入力メッセージ１５０７は、プロセッサ１５０８に提供され、プロセッサ１５０８は、考慮中の特有の外部システム１５０４について書かれた規則に従って、メッセージを無害化する。次いで、無害化されたメッセージ１５０９は、ガード１５１０に渡され、ガード１５１０は、プロセッサ１５０８によって実施された修正が適切であることを確認する。次いで、ガード１５１０は、確認メッセージ１５１１をダウングレーダ１５１４に渡し、ダウングレーダ１５１４は、出力メッセージ１５１５を出力モジュール１５１２の出力ディレクトリに渡す。出力ディレクトリは、ＡＤＳモジュール１５００から出力メッセージ１５１３の通信を実施するように、外部宛先システム１５０４によって指図された通信プロトコルを支援する。

図１６および１７は、画像を含むメッセージに対処するＡＤＳモジュールのある修正を示す。図１５の構成要素に対応する図１６および１７に示したモジュールの構成要素は、同じ符合によって識別される。戦術情報の配布を含む様々な応用例では、画像を含むメッセージを無害化して分配し得ることが望ましい。しかし、そのような画像メッセージの処理は、ある課題を提示する。まず、画像メッセージは、従来の無害化規則を使用する分析
を容易には受けない画像要素を含む。さらに、テキストおよび他のデータ構成要素が画像と共に含まれているとき、理解可能なデータを画像構成要素から分離する必要がある。画像メッセージは、また、たとえば２ギガバイトを超えることもある非常に大きなファイルをしばしば構成する。現在、多くの戦術システムは、この多くのＲＡＭを有していない。したがって、図１６および１７のモジュール構造は、画像メッセージを処理する必要性に対処するために、ある修正を含む。

まず図１６を参照すると、無害化モジュール１６００が、１つの標準的な画像メッセージ・フォーマット、すなわちＮＩＴＦにおいて画像メッセージを処理する例示的な応用例について示されている。モジュール１６００の目的は、簡単なテキスト・メッセージと同様に可能な限り多くのＮＩＴＦメッセージを処理することである。主な修正は、ファイル管理に関する。これに関して、メッセージ・テキストは、外部ファイルに維持される。したがって、入力ファイル１６０２は、まず、入力ファイル・データベース・ディレクトリ１６０４に記憶される。以下で議論するように、メッセージ・プロセッサ１５０８および出力ガード１５１０による処理を完了する際に、ファイルは、ダウングレーダ作業ディレクトリ１６０６に転送される。ダウングレーダ１５１４によって送信するために準備されたメッセージは、最終的に送信出力ファイル・ディレクトリ１６０８に記憶され、このディレクトリから、出力メッセージ・ファイル１６１０は、宛先人システムに利用可能とされる。したがって、不可解な画像構成要素を含む大きなメッセージ・ファイルは、決して実行メモリにロードされないことが観察されるであろう。そうではなく、メッセージは、不可解な画像構成要素および理解可能データ構成要素に分離され、プロセッサ１５０８、ガード１５１０、およびダウングレーダ１５１４の処理能力は、一般に管理可能サイズである理解可能データ構成要素に関してのみ動作することが可能になる。したがって、初期パースまたは処理規則が、データを扱うために使用される様々なパースおよび処理規則に追加される。この初期規則は、プロセッサ１５０８、ガード１５１０、およびダウングレーダ１５１４によって処理される作業ファイルから、ある不可解構成要素を識別して、削除する。たとえば、そのような構成要素は、サイズに基づいて識別され得る。これに関して、すべてのテキストおよび他のデータの処理を可能にするように十分大きいが、画像データを実行メモリにロードするのを回避するように十分に小さい属性サイズ閾値が、確立され得る。そのような規則は、容易に実行され、したがって、処理のために残存するデータ構成要素は、上記で議論した無害化規則を使用して処理し得る。

より具体的には、入力ファイル１６０２に関して、スクリプトを使用して、外部上流システムからＮＩＴＦファイルにアクセスし、ＮＩＴＦファイルを入力コムズ作業ディレクトリ１６０４に書き込むことが可能である。入力コムズ１５０６は、理解可能データを画像構成要素から分離するために、上記で留意した初期規則を実施するように動作する。入力コムズ１５０６は、また、メッセージの長さおよび他の構成要素を確認して、抽出入力メッセージをメッセージ・プロセッサ１５０８に渡す。メッセージ・プロセッサ１５０８は、抽出入力メッセージをパースし、無害化規則をパース済み抽出入力メッセージに適用して、抽出出力メッセージを生成し、この抽出出力メッセージは、出力ガード１５１０に渡される。次いで、出力ガード１５１０は、解放制約について抽出出力メッセージを確認し、ＮＩＴＦファイルをダウングレーダ作業ディレクトリ１６０６に移動させ、抽出出力メッセージをダウングレーダ１５１４に渡す。ダウングレーダ１５１４は、ＮＩＴＦファイルを出力コムズ作業ディレクトリに移動させ、ＮＩＴＦ抽出出力メッセージを出力コムズ１５１２に渡す。最後に、出力コムズ１５１２は、出力スクリプトを呼び出して、ＮＩＴＦファイルを、外部アドレス・システムによってＮＩＴＦファイルにアクセスし得る領域に移動させる。

図１７は、画像メッセージを扱うためにさらに修正されたＡＤＳモジュール１７００を示す。この場合、再び、スクリプトを使用して、外部ソース・システムからＮＩＴＦファ
イル１７０２にアクセスし、ファイルを入力コムズ作業ディレクトリ１７０４に書き込む。入力コムズ１５０６は、再び、メッセージの長さおよび他のパラメータを確認するように動作する。しかし、この場合、入力コムズは、理解可能データを抽出するように入力メッセージをパースすることを試行しない。そうではなく、メッセージ・プロセッサ１５０８は、ＮＩＴＦファイルを理解可能要素（文字および数値の属性）と理解不能要素（当初ＮＩＴＦファイルのセグメントを指摘するファイルの属性）にパースする。次いで、メッセージ・プロセッサ１５０８は、すべてのタイプの属性を含むパース済みＮＩＴＦファイルに無害化規則を適用し、属性を使用して完全に新しいＮＩＴＦファイル１７０６を指摘する出力メッセージを生成する。最後に、メッセージ・プロセッサ１５０８は、出力メッセージを出力ガードに渡す。出力ガード１５１０は、この場合やはり、ＮＩＴＦファイルを理解可能要素と理解不能要素にパースし、パース済みＮＩＴＦファイル１７０６を解放制約ごとに確認して、ＮＩＴＦファイル１７０６をダウングレーダ作業ディレクトリ１７０８に移動させる。ダウングレーダ１５１４は、ＮＩＴＦファイル１７０６を出力コムズ作業ディレクトリ１７１０に移動させて、ＮＩＴＦファイルを指摘する出力メッセージを出力コムズ１５１２に渡す。最後に、出力コムズ１５１２は、スクリプトを呼び出して、ＮＩＴＦファイルを、外部宛先人システムによってアクセス可能な領域１７１２に移動させる。

図１８は、図１７の構造に従って画像メッセージに対処する無害化モジュール処理を示すフローチャート１８００である。工程は、外部上流（ソース）システムからＮＩＴＦ入力ファイルを受信する（１８０２）ことによって開始される。次に、ＮＩＴＦ入力ファイルのシールおよび長さを確認し（１８０４）、入力ファイルを理解可能要素と理解不能要素にパースする（１８０６）。これに関して、理解可能要素は、実行メモリに移動させることが可能であり、一方、画像、記号などを含む理解不能要素は、ディスク上にのみ存在し続ける。次いで、モジュールは、適切な規則をパース済みＮＩＴＦファイルに適用し（１８０８）、宛先人に必要とされるのと同数のコピーを含めて、１つまたは複数の新しいＮＩＴＦファイルをフォーマットする（１８１０）。次いで、新しい出力ＮＩＴＦファイルは、規則を確認するためにパースされ（１８１２）、ＮＩＴＦファイルに適用されるすべての規則が確認される（１８１４）。ＮＩＴＦ出力ファイルは、ダウングレードされて、出力コムズ・ディレクトリに渡される。最後に、ＮＩＴＦ出力ファイルは、下流（アドレス）システムによってアクセス可能なファイル・システムに送信される（１８１８）。

以上の説明では、規則の２つの重要なカテゴリを参照していた。そのような規則を図１９に示す。規則１９００は、無害化規則１９０２および解放制約規則１９０４を含む。そのような規則は、共に、無害化ガイダンス１９０６によって制御される。規則のそのようなタイプのそれぞれについて、以下で議論する。

ＡＤＳモジュールのメッセージ・プロセッサ構成要素が、パース済みメッセージを得たとき、メッセージは、一般に、特定の通信ネットワーク上でまたは特定のソースからシステムに入るすべてのメッセージに共通な無害化タスクを使用して処理される。この工程において、メッセージ・プロセッサは、入ってくるデータを遮蔽して、データのスループットを対象のメッセージにのみ（対象の現在の領域に関連するデータなど）限定するか、またはこのメッセージを受信するすべてのアディーに関係するデータに対する変更を実施する（たとえば、特定のフィールド値のスペリングを訂正する）ことが可能である。

次いで、プロセッサは、特定の「アディー（addees）」について無害化を実施し得る。アディーは、ＡＤＳモジュールによって処理されるメッセージについて同じ無害化要件を有するチャネル上にある宛先人または宛先人のグループを指す。たとえば、同じチャネルにあるすべてのトマホーク船舶は、それぞれが機密ＧＥＮＳＥＲレベル・メッセージを受信することのみを許可されているので、１つのアディー名の元でグループ化し得る。次い
で、メッセージ・プロセッサは、各アディーについてメッセージをコピーし得る。各特定のアディーについて設計された１組の固有の無害化タスクを使用して、特定のアディーについて情報をダウングレードまたは処理するために必要なセキュリティ・ガイダンスを満たすように、データを除去または置き換える。図１９に示すそのような無害化タスクは、特定の使用サイトおよび動作の局所セキュリティ概念について設計されたセキュリティ・ガイダンスから直接導出される。このガイダンスは、そのサイトによって処理されたメッセージを特定の機密レベルにおいて解放するために無害化する方式を指図する。

入力メッセージ全体は、セキュリティ・リスクを構成するワードまたはフレーズもしくは他のストリングの１つまたは複数の定義可能な表を含む「禁句」検索タスクに備えて遮蔽し得る。禁句は、メッセージを適切に無害化するために除去されなければならないコード・ワードまたは他の機密名および／または局所的に定義された禁句を含み得る。

一般に、１つまたは複数の「規則」無害化タスクが、メッセージのフィールド上で特定の行為を実行するために、オペレータによって開発されている。規則は、属性値を追加、置換、削除、概数化、調節、コピー、記憶、または取出しし得る。規則は、メッセージをオペレータが閲覧したり、メッセージ中のフリー・テキストを削除したりするために送信することも可能である。

そのような無害化タスクは、局所的に開発するか、または他のシステムからインポートし得る。無害化タスクのシーケンスまたはフローは、オペレータによって定義され、一般に、１人が行為を開始し、２人目が行為を承認する２人の制御下にある。起動された後、無害化モジュールは、オペレータによって設計された計画に従って、受信メッセージに自動的に対処する。

無害化規則は、if／thenステートメントと通常呼ばれる行為ステートメントと対になっている条件ステートメントに基づいて、パース済みデータを処理する。ある条件がメッセージに存在する場合、システムは、ある行為を実施する。そのようなif／thenステートメントのそれぞれは、規則と呼ばれる。規則、ならびに規則を選択、定義、および実施するユーザ・インタフェースの様々な例が、米国仮特許出願第６０／２１５，１１４号明細書に記載されている。いくつかのそのようなタイプの規則として、以下が含まれる。

図２０は、オペレータが規則に基づく無害化の展開において実施し得る工程を示すフローチャートである。関連する工程を以下に列挙する。

１．メッセージおよび構成要素の接触を無害化するために使用される１組の規則を定義する（２００２）。
２．メッセージ・レベルの属性およびメッセージに含まれている接触の属性に対する条件を定義する（２００４）。

３．属性の存在を検査する条件を定義する（２００６）。
４．ワイルドカード（任意の文字を表す記号）を含む可能性がある所与のストリングの出現を検索するテキストまたは文字の属性について条件を定義する（２００８）。

５．関係オペレータ（等しい、より小さい、より大きい）またはその否定を使用して、所与の値との比較としての数値属性の条件を定義する（２０１０）。
６．接触位置が対象の指定領域（たとえば座標について事前に画定された幾何学的領域）内にある条件を定義する（２０１２）。

７．ブール論理コネクタを使用して、条件を１組に組み合わせる（２０１４）。
８．処理されているメッセージをエラー・キューに経路指定する規則行為を作成する（２０１６）。

９．接触削除行為を定義する（２０１８）。
１０．属性削除行為を定義し、削除される属性を指定する（２０２０）。
１１．フリー・テキストを含むすべての属性を削除する行為を定義する（２０２２）。

１２．保持される属性を指定する規則行為を作成して、列挙されていないすべての属性を削除する（２０２４）。
１３．指定された数値属性（整数、浮動点数、位置、または時間）が概数化される精度を指定する規則行為を作成する（２０２６）。

１４．属性値を供給値と置き換える規則行為を作成する（２０２８）。
１５．条件付きで実施される規則の追加の組を提供する規則行為を定義する（２０３０）。

１６．１つの属性値を他の属性値にコピーする（２０３２）。
１７．供給量によって属性値を調節する（２０３４）。
１８．以前に定義されたメッセージ・カウンタ定義に基づいて、指定量だけ属性値を増大させる規則行為を作成する（２０３６）。

１９．関連するキー属性の存在に基づいて、属性値を記憶する規則行為を作成する（２０３８）。

２０．関連するキー属性の存在に基づいて、記憶属性値を取り出す規則行為を作成する（２０４０）。
規則に基づく無害化に加えて、ＡＤＳモジュールは、メッセージの機密レベルを読み取ることによって受信メッセージの分類レベルを決定する。入力および出力通信チャネル・パラメータは、たとえば最高機密／機密区分情報（ＴＳ／ＳＣＩ）から最高機密／ＮＡＴＯ解放可能（ＴＳ／ＮＡＴＯ）へ、またはＴＳ／ＳＣＩから機密（Ｓ）へ、ローカル・サイト・セキュリティ要件に従ってオペレータによって定義される。そのような定義を使用して、ＡＤＳモジュールは、無許可のチャネルおよび宛先人に解放されることからデータが保護されることを保証するために、内部検査および確認工程を開始する。無害化された後、メッセージは、再フォーマットされる。

上記で議論したＡＤＳモジュールは、別個のガードをも含む。ガードは、解放制約規則（ＲＣＲ）と呼ばれる規則を含む。ＲＣＲは、２人の制御下にあるオペレータによって、かつ再び、図１９に示すように、無害化規則の展開を管理する同じ無害化ガイダンスに従って定義される。ＲＣＲは、各メッセージが無害化規則によって適切に無害化されたことを確認するように設計される。ガードは、また、適切な分類マーキングが存在し、かつメッセージ・ヘッダおよび本体のフォーマットが適切であることを確認する。ガードは、メッセージの解放に対する適切な制約が実施され、かつ、メッセージが、送信のためにメッセージを出力チャネルに渡す前に、チャネルおよび宛先人に解放されるのに適切な分類レベルにあることを確認する。

以上の説明は、様々なＭＡＧおよびＡＤＳの構成要素および工程の議論を含んでいた。これに関するさらなる詳細、ならびに特定の産物実施態様の動作のユーザ・ガイド・レベル命令は、米国仮出願第６０／２１５，１１４号明細書において提供されている。

ＩＩＩ．Radiant Collaboration
上記で議論したように、Sanitizer/Guard サブシステムは、Radiant Trust システムの共同作業（collaboration ）サブシステムと共に動作する。図２１〜２９を全体的に参照すると、本発明のコンピュータ実施共同作業サブシステム２１０１は、高度な能力を開発するか新システムまたはレガシー・システムに組み込むかの少なくとも一方を行うためのアーキテクチャ機能を提供する構成要素ベースのインフラストラクチャを組み込む。インフラストラクチャは、データ中心的な方法を組み込み、ドメイン情報は制御および可視化の属性で拡張され、自己記述オブジェクトとして提示される。データ・アクセスは、産業標準インタフェースを経て提供され、レガシー・アプリケーションと商用アプリケーションの統合をより容易にする。共同作業システムは、データ・アクセス、共同作業、および構成要素の統合について重要な基礎フレームワークを提供するために、データ中心原理に基づいて構築される。

共同作業サブシステムのインフラストラクチャは、Net Meeting 、Sun Forum 、CVW 、InfoWorkspace 、およびPlaceware などの既存の共同作業製品と統合され、かつ既存のツールによって提供されない追加の共同作業能力を利用可能とするように設計される。具体的には、共同作業システム・インフラストラクチャは、複数のドメイン・データ・ソースへのアクセスを提供し、可視化、処理、およびエージェント・アプリケーションが共同作業する複数のユーザが分散する環境内において、それらのソースからのデータを分析および処理することを可能にする。

共同作業サブシステムは、ネットワーク内のあらゆる位置で各サービスを構成および実行することを可能にする、完全分散アーキテクチャである。共同作業サブシステムは、ＣＯＲＢＡおよびＪａｖａを含むアークテクチャ・フレームワークに基づいて構築される。インフラストラクチャは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ９ｘ、ＷｉｎｄｏｗｓＮＴ、Ｗｉｎｄｏｗｓ２０００、およびＵｎｉｘ（Ｓｏｌａｒｉｓ２．ｘなど）からなるヘテロジニアス・オペレーティング環境下で実証された動作に依存しないプラットフォームである。共同作業サブシステムは、地理空間情報アクセス仕様（ＧＩＡＳ）、オープンＧＩＳ、およびドキュメント・オブジェクト・モデル（ＤＯＭ）を含めて、確立されたおよび新たな政府および商用のオープン規格に基づく。共同作業サブシステム・インフラストラクチャへのすべてのインタフェースは、Ｊａｖａ、Ｃ、Ｃ＋＋、Ａｄａで書かれたレガシー・システムへの適応性を保証する標準的なインタフェース定義言語（ＩＤＬ）、またはＩＤＬ結合を有するあらゆる他の言語により提供される。

さらに図２１〜２９を全体的に参照すると、共同作業サブシステム・データ・アクセス・フレームワークは、データ・ソースに固有なアクセス方法によりドメイン・データにアクセスする適応レポジトリ層を組み込む。これにより、あらゆるデータ・ソース（リアルタイムデータ供給、オブジェクト・データベース、関係データベース、ファイル・システムなど）由来のデータにインフラストラクチャからアクセスすることが可能になる。レポジトリの方法は、ドメイン・データ・ソースを全く修正する必要がないように、非中断式である。レポジトリは、固有データへのゲートウエイとして作用する。レポジトリは、データを記述し、かつ産業標準インタフェースを経てデータを利用可能とする役割を担う。これにより、クライアント・アプリケーションが、データ位置の知識またはデータ・ソースに固有の特定のアクセス論理を有する必要性が軽減される。

拡張性および適応性は、共同作業システム・インフラストラクチャのキー属性である。クライアント・アプリケーションが、固有構造のあらゆる演繹的な知識を必要とせずに、データについて学習し、かつデータを処理し得るように、データは、自己記述フォーマットにおいて利用可能とされる。その後、クライアント・ビューワが、専用ソフトウエアを必要とせずに、様々な異なる領域ソースからのデータを処理し得る。したがって、新しいデータ・ソースの追加や、または既存のデータ・ソースの構造の変更には、インフラストラクチャまたはクライアント・アプリケーションを変更することを必要としない。さらに、たとえばあらゆる利用可能なデータ・ソース内のデータを処理するために、クライアント・アプリケーションを追加することにより、拡張能力を提供し得る。

より具体的に図２１を参照すると、本発明のコンピュータ実施共同作業サブシステム２１０１によって提供される共同作業相互運用可能状況２９００の概観が示されている。共同作業相互運用可能状況２９００内では、１つまたは複数の会議２９０２が提供され、そこでは複数の参加者２９０４が、問題を解決するために、同時に１つまたは複数のデータ・ソースからデータに共同でアクセスして、それを処理し得る。参加者２９０４は、地理的に互いに離れている可能性があり、データ・ネットワーク２９０８に接続されたユーザ端末２９０６を介して会議２９０２にアクセスする。会議２９０２の参加者２９０４は、データ・ソースを表す１つまたは複数のドキュメント２９１０を経てデータにアクセスして、それを処理し得る。たとえば、図示したように、情報収集および分析動作に関する状況２９００の会議２９０２内では、物流データ、信号情報データ、地形データ、マップ・データ、画像データなどを表すドキュメント２９１０が存在する可能性があり、まとめて共通動作ピクチャを提供する。示した状況２９００は、情報に関係する性質を有するが、共同作業相互運用可能状況２９００は、多くの他の非軍事的事項に関し得ることが理解されるであろう。

状況２９００は、会議２９０２について、より高次の構成を提供する。状況２９００は、建物のフロア、国内の領域、または会議室であってよい。室に入る際に参加者２９０４が状況２９００に入ることが可能であり、会議２９０２を確立し得る。会議２９０２は、共同作業のためのドキュメント２９１０をドロップするように、状況２９００を提供する。会議２９０２内でドロップされたドキュメント２９１０は、ドキュメント２９１０によって表された情報の集合ならびにあらゆる拡張された可視化特性または制御特性を維持し、かつ利用可能とする関連データ・チャネルを有する。

ここで図２１〜２３を参照すると、各ドキュメント２９１０は、対応するデータ・ソース２９１２からのデータを表す。ドキュメント２９１０は、対応するデータ・ソース２９１２に対して問合わせを実施することによって作成することが可能であり、または、相互作用ツールを使用してポピュレートされる空ドキュメント２９１０として作成し得る。前者の場合、問合わせは、継続または静止の２つのタイプのいずれかであってよい。継続問合わせは、エージェントとして作用し、ドキュメント２９１０によって表されたデータの集合が問合わせ仕様に対して最新であることを保証するために、常時評価される。対応するデータ・ソース２９１２に対して変更が行われる際に、ドキュメント２９１０は更新され、それらの更新は、ドキュメント２９１０を表示している可能性があるあらゆるビューワに伝達される。静止問合わせは、問合わせが呼び出された時点における対応するデータ・ソース２９１２のデータのスナップショットを表す。対応するデータ・ソース２９１２を表すドキュメント２９１０は、データ・ソース２９１２が変更されるが、ドキュメント２９１０と直接相互作用する他のソフトウエア・エージェントまたは個人によって操作し得るとき、更新されない。

作成された後、１つまたは複数のドキュメント２９１０は、参加者２９０４によって会議２９０２の中に配置することが可能であり（たとえば、ドキュメント２９１０をドラッ
グして、それを会議２９０２の中にドロップすることによって）、次いで、表示／処理ツール（たとえばマップ・ビューワ、リスト・ビューワ、分析パッケージ）など、様々なクライアント・アプリケーションによって開いて、作用させることが可能である。各会議２９０２内では、ドメイン・データ（すなわち、ドキュメント２９１０において表された対応するデータ・ソース２９１２からのデータ）は、たとえば、データを表示する関連する色および／または記号、もしくはクライアント・アプリケーションを使用して参加者２９０４によってどの色が選択されたかの指摘など、可視化特性および制御特性の追加により拡張される。可視化特性および制御特性は、ドキュメント２９１０において表されたデータの一部となり、会議２９０２の参加者２９０４間の共同作業に対処するデータまたは論理にアクセスする複雑な論理を必要とするのではなく、クライアント・アプリケーションが情報の提示を中心とすることを可能にする。ドキュメント２９１０は、異なるデータ・ソース２９１２からのデータ間の関係を示すために、およびデータを別々に見ることによって抽出し得ない情報を抽出するために、地理的に重複するか、またはテキストが組み合わされる可能性がある。ドキュメント２９１０は、タスクに添付することが可能であり、工程の後で場所から場所または個人から個人に渡すことが可能である。

ここで図２４を参照すると、本発明のコンピュータ実施共同作業システム２１０１は、単一ユーザ共同作業に備える。単一ユーザ共同作業は、共同作業状況２９００内において１つまたは複数のドキュメント２９１０に対して複数の可視化またはデータ処理ツールと相互作用する単一ユーザを記述するために使用される概念である。共同作業システム２９１０を経て利用可能なすべてのドメイン、制御、および可視化の特性を有することによって、共同作業ツールは、共に作業して、データから情報を抽出し、問題を解決するために共同作業する。本発明によれば、ツール間に直接通信が存在しないことに留意することが重要である。

ここで図２５を参照すると、本発明のコンピュータ実施共同作業システム２１０１は、複数ユーザの共同作業にも備える。複数ユーザ共同作業は、複数の参加者２９０４を含むように、単一ユーザ共同作業環境を拡張したものである。共同作業システム２１０１の共同作業フレームワークは、クライアント・アプリケーションが共同作業して作用するために専用の論理が必要ないという点で、固有の複数ユーザ共同作業である。複数ユーザは、会議に入り、様々な人間の知識、エージェント／アプリケーション処理、およびデータ・リソースを組み合わせ、適用して、問題を解決する。本発明のコンピュータ実施共同作業システム２１０１により、複数ユーザが同じデータについて共同作業するために、画像を共通の「ホワイトボード」上にペーストすることを必要とせずに、複数ユーザ間で共同作業することが可能になる。代わりに、共同作業は、ツール内において直接達成される。さらに、ツール内において特別な論理を組み込むことを必要とせずに、複数ユーザ間で共同作業し得る。人間の共同作業者に加えて、共同作業工程に関与するソフトウエア・エージェントが存在する可能性があることが理解されるであろう。

ここで図２８を参照すると、本発明による共同作業システム２１０１の１実施形態の構成要素のブロック図が示されている。共同作業システム２１０１には、１つまたは複数のレポジトリ・サーバ２８１２、１つまたは複数のデータ・チャネル・サーバ２８１４、ライブラリ・サーバ２８１６、１つまたは複数のクライアント・データ・ビューイング・ツール２８１８（リスト・ビューワ・ツール、マップ・ビューワ・ツール、またはＸ−Ｙビューワ・ツールなど）、問合わせビューワ・ツール２８２０、および会議マネジャ・ツール２８２２が含まれる。各レポジトリ・サーバ２８１２は、対応するデータ・ソース２９１２に固有のデータ・アクセス方法を使用して、対応するデータ・ソース２９１２内のデータにアクセスするようにイネーブルとされる。レポジトリ・サーバ２８１２がデータ・ソース２９１２へのアクセスを提供するので、クライアント・データ・ビューイング・ツール２８１８は、データ・ソース２９１２内のデータにアクセスするためにイネーブルと
する必要がなく、したがって、データ・ソース２９１２内のデータの性質の特有の知識を必要としないことが理解されるであろう。データ・チャネル・サーバ２８１４は、拡張データ特性（可視化特性および制御特性）が内部で維持されるデータ中心チャネルを管理する。クライアント・データ・ビューワ・ツール２８１８内ではなく、データ・チャネル・サーバ２８１４内でデータの拡張特性を維持することにより、単一ユーザおよび複数ユーザの共同作業を見込み、クライアント・データ・ビューイング・ツール２８１８を互いに直接通信するようにイネーブルとするか、またはクライアント・データ・ビューイング・ツール２８１８が互いの知識を有することを必要としない。

共同作業システムは、ＪＣＳ参加者サーバ２８２４、ＪＣＳ状況サーバ２８２６、およびＪＣＳドキュメント・サーバ２８２８など、ジョイント共同作業サービス（ＪＣＳ）・プロジェクトの一部としてＭＩＴＲＥ社によって供給される追加の管理構成要素を含むことが可能である。参加者サーバ２８２４は、すべての許可参加者２９０４のリスト、ならびに参加者２９０４および参加者が入った会議２９０２の処理状態を維持する。ドキュメント・サーバ２８２８は、フォルダ内のドキュメント２９１０を処理するためにインタフェースを提供する。インタフェースは、ドキュメント２９１０を階層記憶構造で構成することを可能にするように、ドキュメント２９１０の作成および削除、ならびにフォルダ管理に備える。状況サーバ２８２６は、共同作業状況２９００およびそれらの状況２９００内の会議２９０２を管理するためにインタフェースを提供する。共同作業システム２１０１は、名称付けサービス２８３０、ファクトリ・ファインダ・サービス２８３２、およびシステム・サービス起動デーモン２８３４などの標準的なＣＯＲＢＡサービスを含むことも可能である。

図２９を参照すると、共同作業システム２１０１の構成要素は、データ管理ティア２９５０、情報アクセス・ティア２９５２、サービス・ティア２９５４、およびユーザ・インタフェース・ティア２９５６を含むＮティア・インフラストラクチャに構成される。各ティアは、定義インタフェースを経てアクセスおよび処理される構成要素から作成される。共同作業システム２１０１のインフラストラクチャは、ＣＯＲＢＡ通信フレームワーク上にある。データ管理ティア２９５０は、データ・ソース２０１２（市データベース、空輸データベースなど）を含む。データ管理ティア２９５０は、データベース管理システムによって通常供給されるデータ管理能力を提供する。

レポジトリ・ティア２９５２は、レポジトリ・サービス２８１２（信号レポジトリ、市レポジトリ、空輸レポジトリ、空輸信号レポジトリなど）からなる。レポジトリ・ティア２９５２は、データ・ソース２９１２内に維持されているデータをサービス・ティア２９５４のサービスおよびユーザ・インタフェース・ティア２９５６のクライアント・ツールに利用可能とする適応性サービスを提供する。レポジトリ・ティア２９５２の各レポジトリ・サーバ２８１２は、データ・ソース２９１２の固有アクセス方法を使用して、その関連するデータ・ソース２９１２と相互作用する。これにより、インフラストラクチャ・サービスまたはクライアント・ツールの残りを修正することを必要とせずに、事実上あらゆるデータ・ソース２９１２をインフラストラクチャに統合することが可能になる。レポジトリ・ティア２９５２のレポジトリ・サーバ２８１２は、２つの機能を実施する。この機能は、関連するデータ・ソース２９１２の固有アクセス方法を使用してサービス要求を実行するプロキシとして作用し、要求されたデータを自己記述構造でインフラストラクチャに提供する。

要求は、レポジトリ・サーバ２８１２に対して、継続問合わせおよび静止問合わせの２つの方式で作成される。初期化の際に、各レポジトリ・サーバ２８１２は、関連するデータ・ソース２９１２に質問して、その内部に維持されているデータの構造を抽出する。この定義は、フィーチャ・タイプとして記述される。次いで、各レポジトリ・サーバ２８１
２は、ライブラリ・サーバ２８１６に登録して、支援されたフィーチャ・タイプおよびレポジトリが実施し得る問合わせのタイプ（空白、継続、静止）を提供する。問合わせが実行されたとき、問合わせの結果は、「フィーチャ集合」と呼ばれる構成要素を経てアクセス可能とし得る自己記述データ構造に変換される。

レポジトリ・サーバ２８１２は、情報の要求を受信して、それらの要求を実行し、次いで、結果として得られる情報の集合を管理する役割を担う。問合わせから得られる情報の集合は、「フィーチャ集合」と呼ばれ、自己記述フォーマットにおいて利用可能とされる。集合を処理する情報およびアクセス方法は、Ｏｐｅｎ ＧＩＳ Ｃｏｎｓｏｒｔｉｕｍによって開発された「簡単フィーチャ仕様」を模範とする。図５４は、「フィーチャ集合」を作成する構成要素を示す。

「フィーチャ集合」の各フィーチャは、非循環有向グラフ（ＤＡＧ）の形式態で管理される。ＤＡＧ構造を使用して、問合わせから得られる情報を記述し、その後ＤＡＧ構造を使用して、クライアントとサーバとの間でオブジェクト情報を伝達（値渡し）する。図５５〜５６に示すＤＡＧ構造は、３つの部分を有する：（１）属性情報のみを含む特性のアレイ；（２）属性のリスト（要素ノード）または他のノードのリスト（ノード・リスト）を含むノードのアレイ；および（３）２つのノードを接続するエッジのアレイ。ＤＡＧ構造は、ＤＯＭオブジェクトに／から容易に変換されることが理解されるであろう。

サービス・ティア２９５４は、データ・チャネル・サーバ２８１４、ライブラリ・サーバ２８１６、参加者サーバ２８２４、状況サーバ２８２６、およびドキュメント・サーバ２８２８、ならびに他のサーバからなる。サービス・ティア２９５４は、あらゆる他のサービス、クライアント・ツール、またはレポジトリにアクセス可能なサービスを提供する。サービス・ティア２９５４は、特有のドメイン問題に適用されるビジネス論理の大部分を維持する。サービス・ティア２９５４は、拡張されるように設計され、ドメイン特有のビジネス論理を追加して、企業システムに利用可能とすることを可能にする。新しいサービスは、その存在を名称付けサービス２８３０に登録し（図２８）、クライアント・ツールおよび他のサービスが新しいサービスの能力を学習および使用し得るように、ホーム・インタフェースを提供する。

ユーザ・インタフェース・ティア２９５６は、ユーザがデータと相互作用することを可能にするシン・クライアント・アプリケーション／アプレット／サーブレット（クライアント・ツール２８１８）からなる。各クライアント・ツール２８１８は、集合と直接インタフェースする（共同作業が望ましくない場合）、またはデータ・チャネル２８１４と直接インタフェースする（共同作業フィーチャを提供する）。

図３０〜４２を参照すると、本発明の共同作業サブシステム２１０１は、レガシー・システムの能力と共同作業システム２１０１によって提供される能力とを統合するインフラストラクチャを提供する。共同作業サブシステム２１０１のインフラストラクチャは、迅速に変化する技術に遅れずに付いていく基盤を提供し、かつシステムが発展する際に、新しい能力の適応を支援する。共同作業サブシステム２１０１は、オープン・アーキテクチャを有し、レガシー・システムを統合する複数の選択肢を提供する。各レガシ構成要素について選択された統合のレベルは、使用されるインフラストラクチャの能力およびシステム拡張計画に依存する。長期移行計画がレガシー・ソフトウエア構成要素の広範な使用を含む場合、アーキテクチャの利点を完全に使用するために、より高レベルの統合が必要とされる。計画が、他の能力が開発されるまで、レガシ構成要素を一時的に使用する場合、より低レベルの統合が適切である可能性がある。１つの推奨される方法は、３レベルの統合に備える。この方法により、所望のシステム能力を達成する必要性に応じて、レガシー・システムの各構成要素（データ・ソース、処理構成要素、ユーザ・インタフェース）を
統合することが可能になる。

図３０は、共同作業サブシステム２１０１とレガシー・システムとの第１（または最小限）レベル統合を示す。第１レベル統合は、レガシー・システムに対する変更を必要としない。情報アクセス・ティア２９５２のレポジトリ２８１２が、レガシー・データ・ソース３０００へのアクセスを提供するために開発される。この統合レベルにより、共同作業システム２１０１インフラストラクチャによって提供される既存ツール２８１８によるドメイン・データのアクセスおよび処理が可能になる。この統合レベルは、問合わせへの完全アクセスを可能にし、新しいデータ・ソースおよびレガシー・データ・ソースからドキュメントを作成し、既存のビューイング・ツール２８１８（共同作業サブシステムの２１０１のインフラストラクチャからなるもの）が、レガシー・アプリケーション３００２ソフトウエアを変更することを必要とせずに、データに共同作業して作用することを可能にする。

図３１は、共同作業システム２１０１とレガシー・システムとの第２（または中間レベル）レベル統合を示す。第２レベル統合は、共同作業サブシステム２１０１インフラストラクチャを経てレガシー・データ３０００にアクセスするために、レガシー・クライアント・ビューワおよび／または工程の１つまたは複数を修正することを含む。レガシー・データ・ソース３０００に関連付けられた情報アクセス・ティア２９５２に新しいレポジトリ・サーバ２８１４を有することに加えて、レガシー・アプリケーション３００２は、固有言語（native language ）ＡＰＩを経てサービス・ティア２９５４に接続される。これにより、レガシー・アプリケーション３００２（ユーザ・インタフェースと処理アプリケーションの組み合わせ）の選択部分が、共同作業環境において動作し、かつレガシー・データ・ソース３０００ならびにインフラストラクチャに利用可能とされた他のデータ・ソース２９１２を処理することが可能になり、一方、レガシー・アプリケーション３００２を使用してレガシー・データ・ソース３０００と直接相互作用する能力は、依然として維持される。

図３２は、共同作業サブシステム２１０１とレガシー・システムとの第３（または完全）レベル統合を示す。第３レベル統合は、共同作業システム２１０１の基本となる構成要素アーキテクチャを使用して、レガシー・システムの構成要素（データ・ビューワ、処理）を書き直すことを含む。これは、構成要素分配、システム管理、ウエブ・イネーブルのビューワの利点を提供し、ライフサイクル管理（起動、パシベーション、および永続性）を支援する。第１レベル統合および第２レベル統合と同様に、新しいレポジトリ２８１４が、レガシー・データ・ソース３０００と関連付けられた情報アクセス・ティア２９５２において提供される。しかし、完全統合の場合、レガシー・アプリケーションは、ユーザ・インタフェース・ティア２９５６に含まれている１つまたは複数のシン・ビューワ３００４およびサービス・ティア２９５４に含まれている処理サービス３００６として書き直される。シン・ビューワ３００４は、たとえば、Ｊａｖａで書き直すことが可能であり、それらをウエブ・イネーブルにし、かつマシン非依存性とする。レガシー・ユーザ・インタフェースおよび処理サービスをユーザ・インタフェース・ティア２９５６およびサービス・ティア２９５４にそれぞれ組み込むことにより、それらを企業の使用に利用可能なシステム構成要素とする。共同作業サブシステム２０１０とレガシー・システムとの完全統合により、システムの保全コストが下がり、企業全体での複製機能が排除され、各改良が企業全体に利用可能となる。さらに、選択された統合技法、および対応する利点は、本発明を使用して、プロジェクトの要求に従って、コストおよびリスクの両方について段階的に管理される。

図３３を参照すると、本発明の共同作業サブシステム２１０１は、共同作業処理の複雑さをインフラストラクチャに移行させる。可視化特性および制御特性（色、選択、記号体
系）は、単にクライアント・ビューイング・ツール２８１８のハードコード特性であるのではなく、インフラストラクチャ内のデータの拡張部分となる。この方法では、クライアント・アプリケーション（ユーザ・インタフェース、処理エージェント）は、専用データ・アクセス方法または共同作業実施論理の必要性を排除することによって簡単になる。ビューイング・ツール２８１８は、インフラストラクチャを経てデータに簡単にアクセスし、ツール２８１８に適切であるようにデータを表示または処理し、あらゆる更新を再びインフラストラクチャに提供する。可視化特性の処理を含めて、データとのあらゆる相互作用は、同じ会議２９０２内で相互作用するすべてのツール２８１８によって共同作業して見られる。可視化特性および制御特性のすべては、ドメイン・データの拡張として扱われるので、インフラストラクチャは、問題を解決するために作用する「共同作業エージェント」として適用されるソフトウエア・エージェント技術の自然環境を提供する。エージェントは、人間の参加者によって実施される行為を監視し、かつそれに作用することが可能であり、または、制御情報に基づいて行為を実施するように構成することが可能である。

ここで図３４〜４１を参照すると、共同作業サブシステム２１０１の例示的なユーザ・インタフェースおよびそのいくつかの構成要素が示されている。図３４〜３５は、共同作業サブシステム２１０１のユーザ・インタフェース２８６０の例示的な実施形態を示す。共同作業システム・ユーザ・インタフェース２８６０は、ウエブ・ブラウザなどの他のアプリケーション内において、または、ユーザ端末２９０６のオペレーティング・システム環境内の別のアプリケーションとして、実行されるように構成し得る。共同作業システム・ユーザ・インタフェース２８６０は、会議２９０２および会議２９０２内の情報に容易にアクセスすることに備える。これに関して、状況２９００内の様々な会議室２９０２が共同作業システム・ユーザ・インタフェース２８６０の左側パネルに表示され得る。様々なクライアント・ツール２８１８に関連付けられたウィンドウが、共同作業システム・ユーザ・インタフェース２８６０の右側パネル内に表示される。共同作業システム・ユーザ・インタフェース２８６０は、会議２９０２およびツール１８１８からなる複数の保存作業空間を可能にする。また、ドキュメント２９１０を様々なビューイング・ツール２８１８にドラッグおよびドロップすることを可能にする。さらに、共同作業システム・ユーザ・インタフェース２８６０は、会議２９０２間の簡単なナビゲーションを可能にする。ドキュメント２９１０、参加者２９０４、およびツール２８１８を含む複数の活動会議２９０２が存在する可能性がある。会議２９０２内では、参加者または参加者のグループ２９０４が、問題を解決するために、情報を分析して、相互作用する。

図３６は、問合わせビューイング・ツール２８２０のインタフェースおよびＪＣＳドキュメント・サーバ２８２８内へのビューを示す。問合わせビューイング・ツール２８１８は、レポジトリ２８１２について動的に学習し、レポジトリ２８１２から属性メタデータを得る。問合わせビューイング・ツール２８１８は、継続問合わせを表すエージェントを作成する。問合わせの結果は、共同作業のためにその後使用し得るドキュメント２９１０となる。ドキュメント自体は、結果を表すトークンであり、この行為によってユーザのビューワにドキュメント・データは伝達されない。継続問合わせエージェントによって作成されたドキュメント２９１０は、ＪＣＳドキュメント・サーバ２８２８インタフェース内に表示される。

図３７は、マップ・ビューイング・ツール２８１８のインタフェースを示す。マップ・ビューイング・ツール２８１８は、階層化および標準ベース・インタフェースを支援するＢＢＮＯｐｅｎマップ・ビューワなどのオープン・ソース構成要素からなることが可能である。マップ・ビューイング・ツール２８１８は、選択投影（たとえば、図示したメルカトル投影）でマップを表示し、データ項目がマップの上にオーバーレイされ、データ・モデルの拡張特性に従って着色されている。マップ・ビューイング・ツール２８１８は、ユーザがデータ項目を表所するために可視化属性（線のタイプ、線の色、塗り色など）を編
集し得る構成可能ポップアップ「層エディタ」・メニューを含む。

図３８は、拡張特性エディタ２８３６のインタフェースを示す。拡張特性エディタ２８３６は、拡張特性（色、ハイライト、可視性、ラベル、記号など）をデータ・チャネル２８１４のデータ項目に添付することに備える。拡張特性エディタ２８３６は、レポジトリ２８１２から情報方式を動的に学習する。拡張特性エディタ２８３６を経て適用される規則は、データ・チャネル２８１４内においてエージェントとして実行される。

図３９は、Ｘ−Ｙデータ・ビューイング・ツール２８１８のインタフェースを示す。Ｘ−Ｙデータ・ビューイング・ツール２８１８は、ユーザが、１つまたは複数のプロット内に表示するためにレポジトリ２８１２によって提供されたリストからＸおよびＹの属性を選択し、プロットの再配置に備え、あらゆるプロットにおけるズーミングおよびパニングを依存的にまたは非依存的に可能にする。

図４０は、リスト・ビューワ・ツール２８１８のインタフェースを示す。リスト・ビューワ・ツール２８１８のインタフェースは、表フォーマットでデータ・ソース２９１２からのデータ項目を見て、処理することに備える。これに関して、データ項目は、記憶し得る。データ表内の特定の行を選択、着色、および隠すことが可能である。さらに、参加者２９０４は、データ項目の様々な属性を見るために選択し得る。

図４１は、チャット・ツール２８１８のインタフェースを示す。チャット・ツール２８１８は、複数状況２９００における複数会議２９０２からの複数ユーザの会話を支援する。チャット・ツール２８１８インタフェース内の例示的なテキストによって示すように、参加者２９０４は、ドキュメント２９１０に接続して、互いに通信する。同じ会議２９０２の参加者２９０４は、参加者入力の色および可視性など同じ可視化特性を見る。

以前に記述した共同作業サブシステム２１０１インフラストラクチャは、システムを構築および改良する方式に対する変更を提供する。共同作業サブシステム２１０１インフラストラクチャを使用して、インフラストラクチャを経て相互作用する小さなクライアント・アプリケーションとして、新しい能力をシステムに追加し得る。結果として得られるシステムは、多くの小さなアプリケーションから構築され、システム全体を形成するように共に機能する独自の能力を提供する。各クライアント・ユーザ・インタフェース、処理構成要素、またはデータ・レポジトリは、各構成要素能力が他の構成要素の能力を拡張するデータ中心共同作業環境において相互作用する。その結果、全能力が各能力の追加により指数関数的に増強されたシステムとなる。共同作業サブシステム２１０１インフラストラクチャにより、各ユーザは、データ・ソース２９１２が何であっても、データを分析および処理するのに最も効果的であるように、適切なツール２８１８を自由に選択する。これにより、変動する背景（エンジニアリング、分析、数学、動作など）を有する人間リソースが、問題を解決するために、多様な技能を最も効果的に適用するのを可能にする専用ツールを使用することが可能になる。これに関して、本発明によるコンピュータ実施共同作業サブシステム２１０１の１実施形態の性能メトリックを図４２にまとめる。

ここで、図４３〜４６を参照すると、本発明の共同作業サブシステム２１０１は、情報アクセス・サービスを提供する（ライブラリ・サービスとも呼ばれる）。情報アクセス・サービス（ＩＡＳ）は、ファクトリ構成要素、管理構成要素、ライブラリ構成要素、および利用可能なデータ・ソース２９１２を見つけ、それらのデータ・ソース２９１２から情報の要求を作成する方法を提供する要求構成要素の組からなる。そのような構成要素は、米国画像および地理的空間サービス（Ｕｎｉｔｅｄ Ｓｔａｔｅ Ｉｍａｇｅｒｙ ａｎｄ Ｇｅｏｓｐａｔｉａｌ Ｓｅｒｖｉｃｅｓ）（ＵＳＩＧＳ）地理的および画像アクセス・サービス（Ｇｅｏｓｐａｔｉａｌ ａｎｄ Ｉｍａｇｅｒｙ Ａｃｃｅｓｓ Ｓｅｒ
ｖｉｃｅｓ）（ＧＩＡＳ）仕様に基づく。図４３は、ライブラリ、マネジャ、および要求間の高レベル相互作用を示す。図４４〜４６は、データ・ソース２９１２に関する問合わせを実施して、その後クライアント・ツール２８１８によって使用されるデータを取り出す（ＩＡＳ）構成要素間のより低いレベルの相互作用を示す。

図４３〜４６の様々なインタフェース構成要素の特徴を以下の表にまとめる。
・ライブラリ：情報アクセス能力を支援する生産ドメイン内の「名称付き」オブジェクト。ライブラリ・オブジェクトを経てアクセス可能なすべてのＩＡＳサービス。データベース位置、データ表示（スキーマ、オブジェクト・モデル）、およびタイプ（ＲＤＢＭＳ、ＯＯＤＢＭＳ、ファイル）は、ＩＡＳのユーザに対して透過的である。
・継続問合わせマネジャ：クライアント要求を開始して、その後、トランザクションの持続期間にわたって要求オブジェクトを管理する役割を担う。他のタイプのマネジャ（問合わせマネジャ、エージェント・マネジャなど）が、情報アクセスの異なる形態を支援する。
・継続問合わせ要求：クライアント問合わせトランザクションが、要求オブジェクトの作成となる。要求は、クライアント可視性を情報アクセス工程に提供する。クライアントは、情報が利用可能であるとき通知される３つの方法を有する：非同期通知のコールバックを提示する；情報が利用可能となるまで、同期的に遮断する；または要求状況を周期的にポーリングする。
・フィーチャ：共通のアダプタ（インタフェース）をドメイン・オブジェクトに提供する。フィーチャを経て、クライアントは、ドメイン・オブジェクトの情報にアクセスし得る。フィーチャおよびレポジトリ・オブジェクトは、様々なデータベース記憶装置およびアクセス機構からクライアント・プログラムを遮蔽するアダプタ層を提供する。
・特性：特性の非循環有向グラフ（ＤＡＧ）を使用して、特定のドメイン・オブジェクトに関する情報を取り出す／更新する。２つのフィーチャ間の関連（設備→機器）が、フィーチャ関連構造のシーケンスを含むＤＡＧ特性として表示される。この特性から（設備内）、クライアントは、表示し得るフィーチャ（機器）の第２集合を作成し得る。
・フィーチャのタイプ：ＳＩＧＩＮＴオブジェクト・モデル（ＳＯＭ）および融合オブジェクト・モデル（ＦＯＭ）は、ドメインを作成する１組のコア・クラス（フィーチャ−インストレーション、設備、機器、ユニット、信号など）を識別した。フィーチャ・タイプにより、クライアントは、問合わせを構築するために使用されるメタデータを得て、取り出し得る。
・特性定義：特性定義（ＤＡＧ定義）の非循環有向グラフを使用して、特定のドメイン・オブジェクトの定義を通す。
・レポジトリ：問合わせを評価および管理するために、共通インタフェースを記憶サーバに提供する。データベース内の各フィーチャ・タイプは、関連するレポジトリ・オブジェクトを有する。問合わせマネジャによって作成された問合わせ要求は、評価のためにレポジトリに進む。レポジトリは、ドメイン項にある問合わせを特定の言語およびデータベースのスキーマに変換する役割を担う。レポジトリは、問合わせを実施して、フィーチャ集合をフィーチャ・オブジェクト内にポピュレートさせる。
・ファクトリ：事象オブジェクトを構築するサービスを提供する。各クラスに特有のファクトリが存在する。ファクトリに応じて、複数の構築方法を提供し得る。
様々なＩＡＳ構成要素の継承構造を図４７〜５１に示す。

より具体的に図４４を参照すると、共同作業サブシステム２１０１のユーザが問合わせビューワ・クライアント・ツール２８２０を起動したとき、問合わせビューワ・クライアント・ツール２８２０は、ライブラリ・サーバ２８１６を介してレポジトリ・フィーチャについて動的に学習する。これに関して、問合わせビューワ・クライアント・ツール２８２０は、ライブラリおよびフィーチャ・タイプ・マネジャを含むライブラリ・サーバ２８１６から問合わせマネジャを得る。フィーチャ・タイプ・マネジャは、レポジトリ・サー
バ２８１２内のフィーチャ・タイプにアクセスする。フィーチャ・タイプは、特性定義およびインストレーション定義を含む。問合わせビューワ・クライアント・ツール２８２０を使用して、ライブラリ・サーバ２８１６を介して問合わせをレポジトリ・サーバ２８１２に提出する。これに関して、レポジトリ・サーバ２８１２が、ライブラリ・サーバ２８１６を経て作成された問合わせ要求を受信したとき、レポジトリ・サーバ２８１２は、継続問合わせ要求を作成する。次いで、レポジトリ・サーバ２８１２は、ドキュメント２９１０（本明細書ではフィーチャ集合とも呼ばれる）を作成し、また、問合わせを実行する。継続問合わせ要求は、レポジトリ・サーバ２８１２に関連付けられたデータ・ソース２９１２内のデータにアクセスするために、レポジトリおよびデータ・ストアを経て実行される。レポジトリ・サーバ２８１２は、定義された問合わせ基準を満たす各ドメイン・データ項目についてフィーチャを作成する。作成された各フィーチャは、拡張された特性を含む。問合わせに応答して作成されたドキュメント２９１０は、非循環有向グラフ（ＤＡＧ）の形態で問合わせビューワ・クライアント・ツール２８２０に戻される。

ここで図５２〜５３を参照すると、データ・チャネルは、ドキュメント２９１０によって提供されるデータへの共同作業インタフェースである。ドキュメント２９１０が会議２９０２内に配置されたとき、データ・チャネル・サーバ２８１４が作成される。初期化の際に、データ・チャネル・サーバ２８１４は、ハイライト、可視性、および色などの可視化特性および制御特性を提供するように拡張される。データ・チャネル・サーバ２８１４は、データ・モデルに追加の共同作業属性を教示するために、拡張特性マネジャに関する方法を呼び出すことによって、リアルタイムでクライアント・アプリケーションまたはエージェントから拡張可能である。図５２は、共同作業サブシステム２１０１アーキテクチャ内の他の構成要素インタフェースに関するデータ・チャネル・サービス・フレームワークを示す。

図５３は、データ・チャネル・サーバ２８１４を作成する構成要素を示し、クライアントとデータ・チャネル・サーバ２８１４との相互作用を記述する。相互作用は、ドキュメント２９１０によって参照されたデータについて学習し、データ・チャネル・サーバ２８１４インタフェースを経て情報を抽出し、ならびに、データ・チャネル・サーバ２８１４が受信し得る更新を登録することを目的とする。図５３に示すように、データ・チャネル・サーバ２８１４は、会議２９０２を含む。各会議２９０２内には、複数のデータ・チャネルが存在する。各データ・チャネルは、データ・モデルを含む。各データ・モデルは、複数の拡張特性を有する複数のデータ項目を表す。各データ・モデルは、そのデータ項目のそれぞれの現在のバージョンを維持する。クライアント・データ・ビューイング・ツール２８１８が開始されたとき、デスクトップ・マネジャは、クライアント・データ・ビューイング・ツール２８１８内のビューワにハンドルを提供する。ビューワは、項目提示を含むビューを含む。ビューは、データ・チャネル・サーバ２８１４からクライアント・データ・ビューイング・ツール２８１８によって得られたごく最近受信したデータ・モデル・バージョンを維持する。これに関して、クライアント・データ・ビューイング・ツール２８１８は、データ・チャネル・サーバ２８１４からデータ・モデルを得て、データ・チャネルがデータ・モデルから受信する事象を通知されるデータ・チャネル・サーバ２８１４に登録する。クライアント・データ・ビューイング・ツール２８１８によって行われる次の工程は、各データ項目の特性のＤＡＧ定義を得ることである。これに関して、クライアント・データ・ビューイング・ツール２８１８は、表示をレンダリングするために必要な情報のみをデータ・チャネル・サーバ２８１４に要求する。次に、クライアント・データ・ビューイング・ツール２８１８は、データ・モデルに対するすべての変更を得る。次いで、事象が受信される際に、クライアント・データ・ビューイング・ツール２８１８は、データ・モデルの最終バージョンがデータ・チャネル・サーバ２８１４から得られたので、データ・モデルに対するあらゆる更新を要求する。

共同作業に必要なネットワーク帯域幅を低減し、かつネットワーク全体でのデータ・コピーを低減するために、本発明のいくつかのフィーチャが適用される。そのような機構により、分散オブジェクト・システムに付随するいくつかの既知の性能の問題が回避される。

まず、レポジトリは、それが管理するデータにアクセスするポリシーを設定する。これにより、問合わせの「遅延評価」が可能になり、データが必要とされるまで、実際の問合わせは延期される。レポジトリは、支援される問合わせの数、更新をまとめる能力、および集合において取り出されるデータ量を制限する能力の制御をも有する。通常、レポジトリは、レポジトリのデータ・ソース間のネットワーク使用を最小限に抑えるように、トポロジ的および計算的に、データ・ソースの近くに配置される。

フィーチャ集合は、ＣＯＲＢＡプロキシ、すなわちトークンとして実施され、したがって、データが表示されるユーザおよび会議がどんなに多くても、集合自体は、１回作成され、かつ精確に管理される。フィーチャ集合は、トポロジ的および計算的にレポジトリの近くに配置することが可能であり、この場合、集合の作成および更新が、ネットワーク通信の帯域幅および待ち時間を最小限に抑える。

データ・チャネルは、特定の集合および会議について最適のデータ・チャネル・マネジャを見つける能力を有する「ファインダ」・サービスを介して選択される。データ・チャネルは、２つの機構を使用して、ビューワに関してその性能を最適化する。第１に、ビューワが、要求したフィーチャのみを受信し、第２に、データ変更は、すべての加入者にすぐには送信されない。代わりに、バージョン変更事象が送信され、この事象は、ビューワが振舞いの仕様に適した最適な方式で管理し得る（たとえば、事象を完全に無視する、最多でも１０秒ごとに１つの事象に応答する、更新の利用可能性を表示するが更新を受信する行為を取ることをユーザに要求する）。

Radiant Trust システムは、様々な異なるフォーマット、データ構造、およびメッセージ・プロトコルと関連付けることが可能である様々なソースから入力を受信し得る。Radiant Trust システムの現在のレポジトリベースの方法は、そのような入力情報について学習する能力を支援する。これに関して、入力情報は合成することが可能であり、ＤＬＭおよびＸＭＬなどの規格を使用することによって自己記述とされる。このようにして、相互運用可能であるように設計されていないシステム間の相互運用性が支援される。レポジトリ層は、特定のデータ空間管理システムおよび記憶方法、ならびにデータ位置の知識の必要性をも排除する。データ・ソースにあったデータは、固有アクセス方法およびレガシー・システムを使用してアクセスされる。それにより、Radiant Trust システムは、エージェントベースのデータ獲得を一体的に支援する。

本発明の様々な実施形態について詳細に説明してきたが、当業者なら、本発明のさらなる修正および適応を思いつくことが可能である。しかし、そのような修正および適応は、本発明の精神および範囲内にあることを明確に理解されたい。

本発明によるRadiant Trust システムのユーザ間の関係のウエブ。 図１のRadiant Trust システムの構成要素を示す図。 図１のRadiant Trust システムのRadiant Sanitizer ／Guard 構成要素の構成の概観を示す図。 １つの入力チャネルに関連付けられた図２Ｂの構成の部分図。 本発明による複数のRadiant Trust システムを使用するネットワークのドメイン図。 本発明のRadiant Trust システムに関して画定された信頼のエンクレーブおよびエンクレーブの階層を示す図。 航空安全の応用例に関連して本発明のRadiant Trust システムによって実施されるクロス・チェック・スレッドを示す図。 航空安全の応用例に関連して本発明によるRadiant Trust システムによって実行される監視リスト更新スレッドを示す図。 本発明による機密情報の処理および分配の概略図。 本発明によるＭＡＧモジュールに関する情報フローを示す概略図。 本発明による入力データ変換を示す図。 本発明による出力データ変換を示す図。 図８のＭＡＧモジュールの高レベル・アーキテクチャを示す図。 図８のＭＡＧモジュールによって実行し得るパース・ツリーを示す図。 本発明によるＭａｇパース機能のフローチャート。 本発明によるＭａｇフォーマット機能のフローチャート。 本発明によるＡＤＳモジュールの概略図。 本発明によるＡＤＳモジュールの代替実施態様の概略図。 本発明によるＡＤＳモジュールの別の代替実施態様の概略図。 本発明による無害化ガイダンス・システムを示す図。 本発明による画像メッセージ処理のフローチャート。 規則に基づく無害化の規則を展開させる工程を示すフローチャート。 共同作業環境のフローチャート。 クライアントがドキュメントと共に参加する方式の概観図。 クライアントがドキュメント上でデータと相互作用する方式を示すフローチャート。 複数のビュー上における共同作業工程を示す図。 適応性および共同作業を示すフローチャート。 クライアントが情報にアクセスする方式を絵でまとめた図。 アーキテクチャ戦略のフローチャート。 サービスに基づくアーキテクチャのフローチャート。 インフラストラクチャを拡張するシステムのフローチャート。 レガシー・システムとの最小レベル統合のフローチャート。 レガシー・システムとの中間レベル統合のフローチャート。 レガシー・システムとの完全統合のフローチャート。 データ中心共同作業ネットワークを有する重要性を概述するチャート。 共同作業アプリケーション管理を示す第１チャート。 共同作業アプリケーション管理を示す第２チャート。 レポジトリ問合わせおよびドキュメント管理のフローチャート。 マップおよびホワイト・ボードの相互作用を示す図。 拡張された特性エディタの機能を示す図。 Ｘ−Ｙプロッタからの出力を示す図。 リスト・ビューワにおける出力を示す図。 チャット・ツール能力を示す図。 性能メトリックを示すフローチャート。 ＵＳＧＩＳによる様々な情報アクセス・サービス（ＩＡＳ）構成要素間の高レベル相互作用を示す図。 ＩＡＳ構成要素間のより低いレベルの相互作用を示す図。 ＩＡＳ構成要素間のより低いレベルの相互作用を示す図。 ＩＡＳ構成要素間のより低いレベルの相互作用を示す図。 図４３〜４６に示した様々なＩＡＳ構成要素の継承構造を示す図。 図４３〜４６に示した様々なＩＡＳ構成要素の継承構造を示す図。 図４３〜４６に示した様々なＩＡＳ構成要素の継承構造を示す図。 図４３〜４６に示した様々なＩＡＳ構成要素の継承構造を示す図。 図４３〜４６に示した様々なＩＡＳ構成要素の継承構造を示す図。 データ・チャネル・サービス・フレームワークを示す図。 データ・チャネルにおけるデータ変更のバージョニングを示す図。 「フィーチャ集合」を作成する構成要素を示す図。 非循環有向グラフ・データ構造フォーマットを示す図。 非循環有向グラフ・データ構造フォーマットを示す図。

Claims (22)

1. 複数のデータ・システムと関連付けられたソースから受信した情報の処理に使用される方法であって、
   第１ソース・システムの第１ソースから第１入力情報に第１アクセスする工程と、前記第１ソースは、データ構造とデータ処理のうちの一方に関係する第１システム依存属性に関連付けられていることと；
   前記第１ソース・システムとは別の第２ソース・システムの第２ソースから第２入力情報に第２アクセスする工程と、前記第２ソースは、データ構造とデータ処理のうちの一方に関係する第２システム依存属性と関連付けられていることと；
   少なくとも１つの受信者システムと前記第１ソース・システムおよび前記第２ソース・システムとの間においてメッセージを制御する、前記第１ソース・システムおよび前記第２ソース・システムとは別の共同作業システムを提供する工程と、前記共同作業システムは、定義されたネットワーク・インタフェースを介して前記第１ソース・システムおよび前記第２ソース・システムのそれぞれと通信するように構成されていることと；
   前記共同作業システムを使用して処理情報にアクセスする工程と、前記処理情報は、前記少なくとも１つの受信者システムと前記第１ソース・システムおよび前記第２ソース・システムの少なくとも一方との間で送信された情報の処理に使用される命令を含むことと；
   前記処理情報と前記第１入力情報および前記第２入力情報の少なくとも一方とを使用して、処理済み情報を得る工程と；
   前記処理済み情報に基づいて前記少なくとも一方の受信者システムに出力を提供する工程と；からなる方法。
2. 前記第１アクセスする工程が、非政府ソースから前記第１情報を得ることからなる、請求項１に記載の方法。
3. 前記第２アクセスする工程が、政府ソースから前記第２情報を得ることからなる、請求項２に記載の方法。
4. 前記処理情報が、前記第１情報および前記第２情報の少なくとも一方を、データ構造に関係付けられた変換形式に変換することに関する、請求項１に記載の方法。
5. 前記変換形式が、前記共同作業システムの内部形式である、請求項４に記載の方法。
6. 前記処理情報が、前記受信者システムに関する、請求項１に記載の方法。
7. 前記処理情報が、前記第１情報および前記第２情報の一方の内容を修正することに関する、請求項１に記載の方法。
8. 前記処理情報が、前記第１入力情報および前記第２入力情報を組み合わせることに関する、請求項１に記載の方法。
9. 前記処理情報が、対象となる条件を識別するために閾値との比較を実施する際に、前記第１情報および前記第２情報を使用することに関する、請求項１に記載の方法。
10. 前記処理情報が、前記受信者システムの識別事項に基づいて前記出力の内容を制御することに関する、請求項１に記載の方法。
11. 前記処理情報が、前記第１ソース・システムおよび前記第２ソース・システムの一方に
    関連付けられた団体のポリシーに基づいて前記出力の内容を制御することに関する、請求項１に記載の方法。
12. 前記処理情報が、市民の自由に関する基準に基づいて前記出力の内容を制御することに関する、請求項１に記載の方法。
13. 前記処理情報が、前記受信者システムに関連付けられた権限および安全許可の一方に基づいて前記出力の内容を制御することに関する、請求項１に記載の方法。
14. 複数情報システム間での情報の共有を容易にするために使用される装置であって、
    システム依存方式で前記複数情報システム間の情報の送信を管理する少なくとも１つの規則の組を記憶する記憶装置と、
    前記規則の組にアクセスし、前記規則の組を使用して、前記複数情報システムの１つにアドレス指定された情報を、前記情報システムの１つの識別事項と前記規則の組とに基づいて、前記情報の形式および内容のうちの一方に関して制御するための処理プラットフォームと、
    定義されたネットワーク・インタフェースに従って、前記処理プラットフォームと前記複数情報システムの各々との間の通信を可能にするインタフェース論理と、からなる装置。
15. ネットワークベース共同作業において使用される方法であって、
    共同作業主題を確立する工程と；
    会議を確立する工程と、第１コラボレータおよび第２コラボレータが、前記会議の期間中に前記共同作業主題にアクセスすることと；
    前記共同作業主題の状態に基づいて、第１内容を有する第１出力を前記第１コラボレータに第１時間に提供するために、前記会議と関連して、前記共同作業主題を第１処理する工程と；
    前記共同作業主題の前記状態に基づいて、前記第１内容とは異なる第２内容を有する第２出力を前記コラボレータに前記第１時間に提供するために、前記会議と関連して、前記共同作業主題を第２処理する工程と；からなる方法。
16. 前記第１処理する工程が、前記第１共同作業と関連付けられた第１コンテンツベース規則の組にアクセスすることと、前記第１コンテンツベース規則に基づいて前記共同作業主題を処理することとからなる、請求項１５に記載の方法。
17. 前記処理することが、前記共同作業主題をいくつかの情報オブジェクトにパースすることと、前記規則の組を前記情報オブジェクトの各々に適用することとからなる、請求項１６に記載の方法。
18. 前記第１処理する工程が、前記共同作業主題をいくつかの情報オブジェクトにパースすることと、前記オブジェクトの１つに関連付けられた機密情報を識別することと、前記識別された機密情報に関して前記共同作業主題を修正することとからなる、請求項１５に記載の方法。
19. 前記修正することが、前記オブジェクトの前記１つの内容を修正することからなる、請求項１８に記載の方法。
20. 前記修正する工程が、前記オブジェクトの前記１つを削除することからなる、請求項１８に記載の方法。
21. 前記第２処理する工程が、前記第２共同作業に関連付けられた第２コンテンツベース規則の組にアクセスすることと、前記第２コンテンツベース規則に基づいて、前記共同作業主題を処理することとからなる、請求項１６に記載の方法。
22. 複数の独立データ・システムに関連付けられたソースから受信した情報の処理に使用される方法であって、
    第１ソース・システムの第１ソースから第１入力情報を受信する工程と、前記第１ソースは、データ構造に関係する第１入力形式に関連付けられていることと；
    前記第１ソース・システムとは別の第２ソース・システムの第２ソースから第２入力情報を受信する工程と、前記第２ソースは、前記第１入力形式とは異なる、データ構造に関係する第２入力形式に関連付けられていることと；
    前記共同作業システムを使用して、前記第１情報の少なくとも一部と前記第２情報の少なくとも一部を組み合わせて、処理済み情報を生成する工程と；
    前記処理済み情報に基づいて、出力を少なくとも１つの受信者システムに提供する工程と；からなり、
    前記出力を組み合わせる工程と前記出力を提供する工程のうちの少なくとも一方が、前記ソースと受信者システム間の情報の共有を管理する前記共同作業システムによって実行される定義規則の組に基づいている、方法。

Images