(57)【要約】【解決手段】  データ統合環境を構築する方法が提供される。コンピュータ・ネットワークに適用される本発明の一実施形態によれば、本方法は以下の３つのステップを含んでいる。（１）データ統合環境およびそれに適用されるポリシーを特定する(200)、（２）環境と協定する(202)、（３）新たなルール・セットを生成し(204)、それに基づいて統合環境の一部とされるシステムと統合環境との間で情報がやり取りされることを可能にする。有利なことに、本方法は、固定センサのネットワークだけでなく、ＵＡＶネットワーク、ロボット・ネットワークに有用に適用されることが可能である。本発明は、ネットワーク対応能力およびシステムの迅速な統合のような様々な重要な適用形態に用途がある。【選択図】      図２ａ【特許請求の範囲】
【請求項１】
複数のデータ通信システムを具備するデータ通信システム・ネットワークを使用する企業の集合において、データ統合環境を構築する方法であって、
（ａ）データ・フレームワーク、階層状分類（またはオントロジー）ルール・セット、および前記ネットワークの各システムについての属性ルールに基づいてデータについての所定のルール・セットを確立するステップと、
（ｂ）前記システムの１つを代表する少なくとも１つのルール・セットを複製し、前記複製されたルール・セットを前記ネットワークの１つ以上の別のシステムに転送するステップと、
（ｃ）複数の前記システムと関連付けられたデータについてのルールを、複数の前記システムの処理能力に基づいた所定の協定手続きに従って併合し、共通のルール・セットが前記統合環境と複数の前記システムとの間で協定されることを可能にするステップと、
（ｄ）前記併合されたルールを統合環境ルール・ベースにロードし、前記データ統合環境を実現するデータ・ストアを複数の前記システムの１つ以上からのルール・データと共に投入する（populate）ステップと、
（ｅ）前記新たに確立されたルール・セットに従って、複数の前記システムのうちの１つ以上と前記統合環境との間でデータ交換を実行するステップと、
を具備する方法。
【請求項２】
前記属性ルールを、前記ルール・セットが用いられて属性の意味、属性の形態、属性の使用法の全てまたはいずれかを定義できるように、階層状分類ルールにリンクするステップを含む、請求項１のデータ統合環境を構築する方法。
【請求項３】
前記階層状分類ルールがその階層状構造と共に用いられて複数の前記システムの全てまたはいずれかに特有の属性ルールの意味を定義し、
前記属性ルールが、属性タイプ、属性値、属性タイプと属性値の組合せ、の全てまたはいずれかを記述する、
請求項１または２のデータ統合環境を構築する方法。
【請求項４】
前記階層状分類ルールがその階層状構造と共に用いられて、複数の前記システムの１つ以上に特有の振る舞いルールの意味を定義し、
前記振る舞いルールが、属性タイプ、属性値、属性タイプと属性値の組合せ、の全てまたはいずれかと共に用いられる、
【請求項５】
アジャイル・データ・モデルの構築方法であって、
（ａ）状態セットを表現するフレームワーク・データ・モデルを確立するステップであって、前記状態の各々は前記モデルを記述する概念変数と関連付けられており、
（ｂ）前記モデルに適用可能な属性および属性ロールに対応する状態セットを確立するステップと、
（ｃ）（ａ）の前記概念変数、前記属性、および前記属性ロールに対応する状態の階層状分類を定義するステップと、
（ｄ）前記ステップ（ａ）、（ｂ）、および（ｃ）の前記確立された状態セットに基づき、またそれらから具体的な属性を具体的な属性ルールにある具体的なフレームワーク概念に対して関連付けるルール・セットを作成することによって、前記データ・モデルを構築するステップと、
を具備する方法。
【請求項６】
コンピュータ上で実行されると請求項１乃至５のいずれか１項の方法ステップ群を実行するためのプログラム・コード手段を具備するコンピュータ・プログラム。
【請求項７】
コンピュータ上で実行されると請求項１乃至５のいずれか１項の方法ステップ群を実行するための、コンピュータ読み取り可能媒体に格納された、プログラム・コード手段を具備するコンピュータ・プログラム製品。
【請求項８】
ＵＡＶネットワークに適用される先行するいずれかの請求項の方法。
【請求項９】
ロボット・ネットワークに適用される先行するいずれかの請求項の方法。
【請求項１０】
固定センサに適用される先行するいずれかの請求項の方法。
【請求項１１】
添付の図面の図２ａ、図２、図３乃至図１０のいずれかを参照して、実質的に上に記述されている、データ統合方法の構築方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ統合環境を構築する方法に関する。より詳しくは（しかし排他的でない）、本発明は、２つ以上の組織の人員が、処理される情報の意味に関心を有する別の組織の情報を処理することが可能な情報システムを介して協働可能にされているデータ統合環境を迅速に構築する方法に関する。
【背景技術】
【０００２】
情報統合
コンピュータに基づいたアプリケーションは、皆、現実世界のモデルを組み込んでいる。その中においては、ユーザの概念は、新たな事実が推定されることを可能にする計算的振る舞い（computational behaviour）とともにデータのシステムとしてモデル化される（動的モデル）。情報に対する可能な振る舞いは、情報の実世界での意味によって制限される。例えば、納品書の細目の費用を加えて全費用を計算するこことは有効であるが、１組の人々の年齢を加えて「ある部署の年齢」を計算することは有効でない。
【０００３】
情報統合はデータ・モデル（静的モデル）を用いて、情報を転送することに関係がある。その結果、受信システムは正確な計算的振る舞い（正確な動的モデル）を適用することができる。このことは、推定された事実がユーザによって正確に理解されることを意味する。例えば、３Ｄ  ＣＡＤモデルがデザイナーからメーカーへ移されると、メーカーは求められている部品を製造できる。
【０００４】
情報統合は、エンド・ユーザが自身のアプリケーションを用いて別の人の情報を読むディスプレイ統合とは異なる。ディスプレイ統合は、情報アプリケーションが新たな事実を推定することを可能にせず、既存の事実を表示する。ワールド・ワイド・ウェブの第一世代によって、人々は、世界中のあらゆる場所からの情報を表示することが可能になった。しかし、ウェブ・ブラウザがその情報から何かしらを計算することはできなかった。
【０００５】
本発明はディスプレイ統合ではなく、情報統合を可能にする。
【０００６】
情報統合基準
組織間の情報統合は、従来、コンピュータに基づいたシステムにおける情報規格のスタックに基づいてきた。この情報規格のスタックには、以下が含まれる。
【０００７】
・データの転送時に用いられるアルファベットを定義するデータ符号化規格、例としてＡＳＣＩＩまたはユニコード。
【０００８】
・交換の「単語」およびその記号を定義する記号的規格、例としてファイル交換用のＳＴＥＰのパート２１（ＩＳＯ  １０３０３−２１）またはウェブ・サーバを介した転送用のＸＭＬ。
【０００９】
各データ要素が何を意味するかを定義する意味的規格、例としてＳＴＥＰアプリケーション・プロトコル（ＩＳＯ  １０３０３−２０１〜２９９）またはＸＭＬスキーマ。例えば、エンティティ・アドレスでは、これは、アドレスの国の名前を述べる部分を保持するものとしてフィールド“国”を特定する。
【００１０】
・参照データ規格、例として国の省略名の標準的リスト。その要素は交換の内容の一部を形成し得る。
【００１１】
概して、規格はそれぞれ互いに独立している。したがって、規格の積み重ね体における１つの規格はその上の、およびそれより下の他の規格を交換する必要なしに、等価なものと取り替えることができる。
【００１２】
コンピュータ志向のグループ（例えばコンピュータ・メーカー）によって開発された規格は記号的規格に焦点を当てている。記号的規格によって、あらゆるユーザがソフトウェア・システム間の情報を転送することができるからである。しかしながら、協働するためには、エンド・ユーザがデータが何を意味するかを理解する必要がある。エンド・ユーザが意味的規格および参照データを必要とするからである。例えれば、ユーザは、自身の話し相手を理解することを望む一方で、電話会社は、自身のシステムが、ユーザが中国内の誰かを電話で呼び出すことを可能にすることで満足しているかもしれない。
【００１３】
本発明は意味的規格のレベルで統合を可能にし、どのような具体的な意味的規格またはデータ符号化規格の使用に依存しない。
【００１４】
参照データの階層状システム
階層の最も単純な既知の形式は木である。この木は有向グラフの形式である。数理モデルでは、図は、ノードを接続するラインを伴った１組のノードである。有向グラフでは、関連線はあるノードから別のノードまで関連を持った方向を有している。木の中で、自身に入って来るラインを有さないが外に出て行くラインを有するノード（根ノード）が１つある。他の全てのノードは、これに入ってくるラインを１本だけ有しており、１つ以上の出て行くラインを有しているか全く有していない。出て行くラインを有さないノードは、葉ノードと呼ばれる。これらの制約の結果、木が根から枝を出すように見え、根から全ての葉まで経路があるように見える。取り決めによって、根は線図の一番上に示されている。代替的な命名規則は、親と呼ばれる、ラインの開始点においてノードを有している。また、終点でのノードは子と呼ばれる。木の中では、根以外の全てのノードはただ１つの親を有しており、多数の子が存在し得る。根は全てのノードの先祖である。
【００１５】
階層は、多数の木の併合として見ることができる。したがって、階層は、複数の根を有し得る。また、１つのノードは複数の親を有し得る。しかしながら、階層の規則は、後ろへとループすることを禁止する。その結果、どのようなノードも、その階層中のその上のノードの親になり得ない（なるとすれば、潜在的には自身の先祖になり得る）。
【００１６】
参照データ階層では、ノードは用語（term）を有しており、接続線は下位クラス関係を示している。その結果、子ノードは常にその親の下位クラスである。すなわち、親に対して適用可能などんな有効な推論（または計算的振る舞い）も、そのノード自体に適用可能である。例えば、自動車が「乗客を運ぶことができる、自己推進型の地上用乗り物」として定義され、ミニが一種の自動車であと断言されるならば、ミニが「乗客を運ぶことができる、自己推進型の地上用乗り物」であることが推論され得る。したがって、ノードを理解するために、ノードの存在の予備的知識を持つ必要はないが、代わりに、下位クラスおよびその譜系の名前を与えられさえすればよい。すると、下位クラスを有効に使用することができる。これは、また、遺伝と呼ばれ、遺伝においては、子ノードは親ノードの特性を継承する。
【００１７】
この概念を人工知能の世界で形式化したものは、オントロジーである。この技術および支持ツールは実現のための有用な基礎を提供するが、この形式化論が本発明の固有の部分でないことが認識されるべきである。
【００１８】
情報統合に関するこれまでの経験
情報統合は一般に２ステップのプロセスである。第１ステップは共通の意味的情報モデルについて一致を取ることである。第２ステップはモデルを実現することである。
【００１９】
従来、第１ステップとして、有意義な統合が起こるために、意味的なモデル全体（データ・モデルと参照データ）は完全に一致されなければならなかった。この一致の外にあるものは、皆、参加するシステムによって無視されなければならなかった。次いで、第２ステップは、必要なソフトウェアが実現され検査されるのに典型的には数か月かかり、複雑な交換については、製品内での使用が可能になるまでに典型的には１年超の試験がかかり得る。
【００２０】
本明細書のために、用語「統合」はデータ交換、トランザクションまたはデータ共有メカニズムによる実現を指す。データ交換メカニズムにおいては、データ統合は、情報の一式の転送（例えば電子保守マニュアル送信）を通じて生じる。トランザクション機構においては、データ統合は、例えばタスクのための新たな見積工数を送ることによって保守マニュアルを更新することによって、情報の（首尾一貫した）下位集合の転送を通じて生じる。データ共有では、複数のアプリケーションが、データベースのようなデータの１つのデータ源を読み取り、更新する。本発明は、そのような実現方式の全てに適用可能である。
【００２１】
規格の最新世代は、参照データが階層状に組み立てられることを可能にするための新技術を使用してきた。統合の第１ステップにおいては、意味的データの全ておよび参照データ階層の上位レベルは、前もって一致されていなければならない。参照データの下位クラスの詳細は後回しでもよく、このことが、参照データが完成する前に実装が開始することを可能にしている。しかしながら、参照データはソフトウェア実装の最終段階および次に進むための検査には完全でなければならない。
【００２２】
本発明では、意味的データ・モデルのフレームワークおよび参照データ階層の上位レベルだけが、前もって意見が一致していればよい。本発明は、ソフトウェア実装終了後の、意味的データ・モデルおよび参照データ階層の拡張および新たな計算的振る舞いの追加を可能にする。ソフトウェアが拡張された機能に対処するために自身を再構成するからである。
【００２３】
従来、意味的データ・モデルおよび参照データが一旦一致させられ且つソフトウェアが実装されると、意味的データ・モデルへのどんな変更によっても各実装内容が更新されることが必要であった。実際問題として、再実装段階は数か月かかる場合がある。したがって、全ての関係者が意味的規格の同じバージョンの完全に同じ統合インターフェースを実行していない限り、再実装段階は、典型的に、新たなデータ統合環境を構築するのに数ヶ月（またはそれ以上）かかり、環境を更新するのに数か月かかる。
【００２４】
規格の最新世代においては、意味的データ・モデルの実装は参照データ・モデルの実装に依存しない。このことは、第２ステップにおいて、最初の実装は従来と同じ期間がかかるが、意味的データ・モデルが不変であれば、参照データ・ライブラリへの変更は迅速に（数時間で）行なうことができることを意味する。さらに、たった１人の関係者だけが参照データを先延ばしにしている場合、参照データを下位タイプ化する（subtype）ことによって、データ交換プロセスの範囲を自動的に拡張することが可能になることが分かった。
【００２５】
本発明は、さらに、上記の２つの段階を取る。最初に、実装ステップは、意味的データ・モデル、振る舞い、および参照データが、制限つきで自動的に拡張することを可能にする。第２に、本発明は、変更が２人以上の関係者によって行なわれる場合、交換の範囲の自律的協定を可能にする。すなわち、既知のアプリケーションに対する本発明の１つの具体的な利点は、統合環境のための準備時間が数か月から数秒まで著しく縮小され得ることである。本発明の別の具体的な利点は、関係者が相違する時点で変わった場合、統合環境の更新を追加的に行うことができるということである。
【００２６】
データ・モデル対インスタンス
データ・モデルはシステムが保持し得るデータのタイプの記述である。例えば、dateは月について３文字のフィールドを有し得る。dateの実例は月フィールドに値「５月」を有し得る。システムは、一般に、dateの多くのインスタンスを有するであろう。
【００２７】
一般に、データ・モデルはシステムでのソフトウェアの一部として表現され、他方、インスタンスは、システムによって、そのデータ・ファイルまたはデータベース内で保持されている値である。
【００２８】
データのモデリングに慣れていない読み手は、この区別を覚えていていられたい。とりわけ、全てのシステムはインスタンスの上で動作するのであるが、動作のタイプはデータ・モデルの点から記述されているからである。
【００２９】
背景技術
意味的データ・モデルを含んだデータ交換規格のスタックの使用は、ＳＴＥＰ（ＩＳＯ  １０３０３）のようなデータ交換規格において、少なくとも１９８０年代以降確立されている。
【００３０】
参照データを使用してデータ交換において定義されている概念を拡張することは、Ｅｐｉｓｔｌｅ（ＩＳＯ  １５９２６）によって、少なくとも１９９０年代以降確立されている。
【００３１】
意味的データ規格と参照データの階層状システムとを組み合わせることは、ＰＬＣＳ規格によって、少なくとも２００４年以降確立されている。意味的データ・モデルについてはＩＳＯ  １０３０３−２３９を参照し、参照データの使用については、http://www.oasis-open.org/apps/org/workgroup/plcsを参照されたい。ＰＬＣＳは、意味的ウェブ技術ＯＷＬを使用して、その参照データをオントロジーとして定義する。
【００３２】
ソフトウェア・エージェントによる自動協定を用いることは１９９０年代以来知られている。
【００３３】
データベースに新たな表を加える機能はＳＱＬの標準的な特徴である。しかしながら、ＳＱＬは記号的規格であり、したがって、実世界での意味は、データベース・ソフトウェアが書き直されるまで、そのようにして作成された表および列に直接的に付加されることが不能である。
【００３４】
データ・モデルを構築する基礎としてのデータ・モデル・パターンの使用は、１９９０年代にMatthew Westによって実証された。再使用可能な断片から構築されたデータ・モデルは、ｃ．２０００以来、ＳＴＥＰ環境内で実証された。ユーザ・ガイダンスを通じて属性を加えるアプローチは、２００３年以降ＰＬＣＳにおいて確立されている。パターン・オントロジーを用いて交互のデータ・パターンを分類し且つそれらを互いに翻訳することは、２００３年に特許出願人ＢＡＥ  ＳＹＳＴＥＭＳ、およびロールスロイスによってＯＦＦＡプロジェクトの中で実証された。
【発明の概要】
【００３５】
本発明は、情報インフラを構築し、迅速なパターニングの可能性を生み出す方法を提供することを目的とする。
【００３６】
以下に記述されるように、本発明の特徴は、異種のシステムがそれらの交換データ・モデルの協定を通じて相互動作（interoperate）することを可能にする手段を提供することである。このことは、システムが新たな機能性を育てることを可能にするようなモジュラー・データ・モデル、データ・モデル・パターン、オントロジー、エージェント協定、人工知能技術、を含む革新的な技術のシーケンスを組み合わせることによって上手く達成される。この新たな機能性は、ラベルに基づいたものではなく、意味に基づいていることが理解されるべきである。このことは、データが、システムが更新されるまで「死んでいる」のではなく、オペレーション・システムおよびそのユーザによって理解されることを意味している。
【００３７】
広い意味では、本発明は、属性ステートメントを、技術的な手段を使用して、ルールとして上手く作り直すという概念に属している。その後、このルールは、ルール・ベースの（rule-based）システムによって操作されることが可能であり、次いで、新たな属性が新たなルールを使用して付加されることが可能である。この革新的なアプローチは、階層状オントロジー内でデータ・モデルを繋げることと組み合わせられており、（エンティティとされる）親概念、属性ロール、属性パターンによる意味の遺伝を可能にする。対照的に、確立済みのデータ・モデル化技術では、所与のエンティティについての属性のリストはモデルへと固定されており、したがって、属性へのどんな変更であっても、モデルの変更が必要になる。したがって、従来のアプローチでは、データ・モデルの新バージョンに対応させるために既存のインターフェースを書き直さなければならないのに対して、本発明は、ある具体的な属性をある具体的な属性ロールにおける特定のフレームワーク概念へと関連付けることにより、データ・モデルが適切に拡張されることを可能にする。
【００３８】
本発明の最初の態様によれば、複数のデータ通信システムを具備するデータ通信システム・ネットワークを使用する企業の集合において、データ統合環境を構築する方法であって、（ａ）データ・フレームワーク、階層状分類（またはオントロジー）ルール・セット、および前記ネットワークの各システムについての属性ルールに基づいてデータについての所定のルール・セットを確立するステップと、（ｂ）前記システムの１つを代表する少なくとも１つのルール・セットを複製し、前記複製されたルール・セットを前記ネットワークの１つ以上の別のシステムに転送するステップと、（ｃ）複数の前記システムと関連付けられたデータについてのルールを、複数の前記システムの処理能力に基づいた所定の協定手続きに従って併合し、共通のルール・セットが前記統合環境と複数の前記システムとの間で協定されることを可能にするステップと、（ｄ）前記併合されたルールを統合環境ルール・ベースにロードし、前記データ統合環境を実現するデータ・ストアを複数の前記システムの１つ以上からのルール・データと共に投入する（populate）ステップと、（ｅ）前記新たに確立されたルール・セットに従って、複数の前記システムのうちの１つ以上と前記統合環境との間でデータ交換を実行するステップと、を具備する方法が提供される。本方法のステップ（ａ）は、有利なことに、システム間の違いが容易に確立されることを可能にし、また、当該モデルが低コストで維持されることが可能である。便利なことに、ステップ（ｃ）は、手動の介在によってではなく、併合されたルール・セットが自動的に確立されることを可能にする。便利なことに、ステップ（ｅ）は、統合が迅速に実現できるという明確な利点を提供し、また、このことは、低コストで本方法を実現／維持できることを意味する。データ統合環境を築くことにおける人間に関連するエラーの可能性も著しく減少する。
【００３９】
随意的に、本方法は、前記属性ルールを、前記ルール・セットが用いられて属性の意味、属性の形態、属性の使用法の全てまたはいずれかを定義できるように、階層状分類ルールにリンクするステップを含んでいる。このことは、（例えば、データ・モデルまたはリレーショナル・データベース原理ベースの）既存のデータ定義アプローチをルール・ベース・システムへと変換する必要なしに、協定技術を適用する利点を複数のデータ・システムに与える。それによって、既存ソフトウェアを書き直す必要を除去する。
【００４０】
随意的に、本方法では、前記階層状分類ルールがその階層状構造と共に用いられて複数の前記システムの全てまたはいずれかに特有の属性ルールの意味を定義し、前記属性ルールが、属性タイプ、属性値、属性タイプと属性値の組合せ、の全てまたはいずれかを記述する。このことは、要素を全て同時に再構成する必要なしに、データ統合環境への追加的な変化を可能にする。また、このことは、１つのシステムが、同様の範囲の複数のデータ統合環境に参加し、ひいては、他の全ての環境に変更を強要する必要なしに任意の１つの環境への変更に適合することを可能にする。
【００４１】
随意的に、本方法では、前記階層状分類ルールがその階層状構造と共に用いられて、複数の前記システムの１つ以上に特有の振る舞いルールの意味を定義し、前記振る舞いルールが、属性タイプ、属性値、属性タイプと属性値の組合せ、の全てまたはいずれかと共に用いられる
本発明の別の態様によれば、アジャイル・データ・モデルの構築方法であって、（ａ）状態セットを表現するフレームワーク・データ・モデルを確立するステップであって、前記状態の各々は前記モデルを記述する概念変数と関連付けられており、（ｂ）前記モデルに適用可能な属性および属性ロールに対応する状態セットを確立するステップと、（ｃ）（ａ）の前記概念変数、前記属性、および前記属性ロールに対応する状態の階層状分類を定義するステップと、（ｄ）前記ステップ（ａ）、（ｂ）、および（ｃ）の前記確立された状態セットに基づき、またそれらから具体的な属性を具体的な属性ルールにある具体的なフレームワーク概念に対して関連付けるルール・セットを作成することによって、前記データ・モデルを構築するステップと、を具備する方法が提供される。
【００４２】
したがって、この本発明の方法は、データ・モデルを構築するものの間の有効なコミュニケーション機構を提供する利点を有している。この機構は、モデルに対する異なるアプローチ同士が協定されることが可能な領域を定義する。この機構は、モデルに対する変更が迅速であるとともに低コストで実行されることが可能であるというさらなる利点を有している。たとえば、モデルに属性を加えることは、新たなルールが加えられることを要求するであろう。このことは、既知のＩＳＯ  １０３０３モデルにとって典型的な１時間から半日（使用されるモデル化方法に典型的には依存する）と比較して、典型的には５分未満しかかからない。
【００４３】
本発明は、プログラムがコンピュータ上で実行されると上記の方法ステップを行なうためのむプログラム・コード手段を備えるコンピュータ・プログラムまで及ぶ。本発明は、さらに、プログラムがコンピュータ上で実行されると上記の方法ステップを行なうための、コンピュータ読取り可能媒体に格納された、プログラム・コード手段を備えるコンピュータ・プログラム製品まで及ぶ。
【００４４】
本発明は、互いに通信するとともにデータを交換することを望み得る多数のコンピュータを含んでいるネットワークでの使用によく適している。有利なことに、本発明の方法は、有用にＵＡＶネットワーク、ロボット・ネットワークに対して、固定センサのネットワークと同様に、適用されることが可能である。この接続においては、本発明の方法は、対象のネットワークの再構成の必要なしに、新たなＵＡＶ、新たなロボットおよび（または）センサをネットワークに付加し、また（所望により）既存のＵＡＶ、ロボット、センサアップグレードすることを可能にする。本発明の方法が、ロボット・ネットワークに適用されれば、新たなロボットがネットワークから情報を迅速に受け取ることを可能にし、ひいては、ロボットがネットワーク内の他のロボットと効果的に協力することを可能にすることが認識されるべきである。さらに、本発明の方法が固定センサのネットワークに適用されれば、既存のセンサが、たとえ旧式のインターフェースを使用することに依存せざるを得ないとしても引き続き作動することを可能にすることが認識されるべきである。
【００４５】
本発明は、様々な重要な適用形態、例としてネットワーク対応能力および（運用上のプラットフォームを配置するという点と、それらを市場に速く安く出すことが求められている、機敏（agile）なオンライン（virtual）企業を構築するという点で）システムの迅速な統合において用途を有していることが理解されるべきである。
【００４６】
本発明の上記の特徴およびさらなる特徴は、添付の請求項において述べられ、また、添付の図面を参照しながら以下に記述される。
【図面の簡単な説明】
【００４７】
【図１】従来のデータ・モデルの例を概略的に示している。
【図２ａ】本発明の実施形態に係る創造性を有するツールによって実行されるステップを概略的に例示している。
【図２】本発明の実施形態に従って使用され得るデータ属性モデルを概略的に示している。
【図３】本発明の実施形態に従って使用され得る２つの属性パターンを概略的に示している。
【図４】本発明の実施形態に従って使用され得るデータ・モデルの例を概略的に示している。
【図５】本発明の方法と共に使用される３つの異なるアーキテクチャの選択肢、すなわち、（ａ）共通の統合環境アーキテクチャ、（ｂ）複製された統合環境アーキテクチャ、（ｃ）仮想統合環境アーキテクチャ、を示している。
【図６】本発明の実施形態に従って使用され得る、異なる階層の合併を概略的に示している。
【図７】本発明の実施形態に従って使用され得る、データ・モデルのさらなる例を概略的に示している。
【図８】本発明の実施形態に従って使用され得る、データ・モデルのさらなる例を概略的に示している。
【図９】サプライ・チェーンにおける本発明の使用法の例を概略的に示している。
【図１０】危機管理における本発明の使用法を概略的に示している。
【発明を実施するための形態】
【００４８】
本明細書のために、以下の用語の定義を適用する。
【００４９】
企業：エリア企業統合における目的を有するまたは勤勉な事業を意味する。
【００５０】
企業は、多くの場合、特定の製品（ここで製品とは、自動車または船のような最終製品とは対照的に、鋼板または車体のような配送されるものである）に向けられた資源の集合であるという意味で、ビジネスと区別される。対照的に、ビジネスは普通特定の所有権モデルを伴った、１つの法律上の実体である。本明細書中で使用される次の用語が、さらに、区別されることが求められている。
【００５１】
拡張企業：均質なソフトウェア・システムの組を使用する幾つかのビジネスに跨る企業を意味する。
【００５２】
電子商取引専門企業（virtual enterprise）：相互動作する(しかし不均質な)ソフトウェア・システムを有する、幾つかのビジネスに跨る企業を意味する。
【００５３】
アジャイル（agile）ビジネス：電子商取引専門企業に迅速に結合可能なビジネスを意味する。
【００５４】
アジャイル企業：自身が基づいているビジネスの会員の変更に迅速に適合可能な企業を意味する。
【００５５】
フラクタル・ビジネス（fractal business）：幾つかのより小さな独立企業から構築された１つのビジネスを意味する。
【００５６】
理解されるように、本発明は、異種のソフトウェアを有しているにも関わらず互いに相互動作することを必要とする１組の資源に適用可能なデータ統合環境を築くことを目指すものであり、それらは、１つのビジネスまたは複数のビジネスにおける個別の資源であるか、１つの企業または複数の企業に跨る資源であるかによらない。本明細書では、用語「企業の集合」はあらゆるレベルの大きさの１つ以上の企業の集合を意味するために使用されている。
【００５７】
用語「データ統合環境」は、企業同士が協働できるように（すなわち、コンピュータ同士が相互に通信し、ソフトウェア・システム同士が相互動作し、人々が相互に協働できるように）企業間でデータを共有および交換する能力に焦点を当てた企業の集合の見方である。ここで、見方という用語が用いられているのは、データ統合環境の中で使用される資源が、そのような使用に対して専用ではないかも知れないからであることに留意されたい。
【００５８】
用語「アジャイル・データ・モデル」は、モデルの変更された機能性が使用システムにとって即座に大なり小なり利用可能にされることが可能なように迅速に再構成されることが可能なデータ・モデルを意味するために使用されている。これは、引き続き使用できるためにはモデルのあらゆる変更もが参加している全システムに組み入れられねばならない脆弱（brittle）データ・モデルや、改変されたシステムに対して参加しているシステムが引き続き動作可能ではあるがこの変更された機能性と相互動作はできない柔軟データ・モデルと対比されているものである。
【００５９】
以下の記述では、まず、本発明の概要が提供される。その後、詳細な説明が、本発明が様々な形で実行されることが可能であるかが提示されている。また、その実施形態が、あくまで例として、添付の図面を参照しながら記述される。
【００６０】
本発明：概要
統合のための本発明のシステムは、最初に、フレームワーク・データ・モデルおよび参照データの上位のオントロジー（または他の階層状システム）を使用して構築される必要がある。本システムはルール・ベースおよび要求される計算的振る舞いを含んでいる。
【００６１】
フレームワーク・データ・モデルは、エンティティに適用可能な属性についてのデータ・モデルとともに、モデルが表わすべき１組のエンティティから構成されている。上位のオントロジーは、各エンティティ、各属性、属性の各使用法に対応する根クラスから成る。
【００６２】
本発明のシステムが具体的なデータ・モデルをインスタンス化する（データ・モデルのインスタンスを作成する（instantiate））ために、すなわち特定のユーザ要件をサポートするために、十分な意味的データ・モデルが定義されねばならない。これは、フレームワーク・モデルに属性を適用することにより行われる。例えば、本システムは、予想重量を持つものとして、ある製品の部品を表わすことができた。この例において、ルール・ベースは、エンティティpartがpredicted_weightのロール（role）において属性weight_property（特性の下位クラス）を有しているというルールを含んでいる。本システムはさらに、部品の組立品が、共に付加される任意の１つのweight_propertyを有していてもよいという振る舞い上のルールを有している。その結果、組立品のpredicted_weightが計算されることが可能となっている。
【００６３】
図２ａを参照すると、本発明の一実施形態によれば、本システムがデータ統合環境の一部になる場合、本システムは３つのステップを辿る。第１ステップ２００はデータ統合環境およびそれに適用されるポリシーを確認する。第２ステップ２０２は、環境と協定を行ない、フレームワークおよび上位のオントロジーが一致することを確認し、次に、共通のルール・セットを協定する。この実施形態では、参照データの階層状構造が用いられて新たなタイプのデータがデータ構造全体の中のどこに位置するかを識別する。このことは、新たなインターフェース・ルール・セットを生成するという望ましい効果を有している。３番目のステップ２０４は、合併されたルールを統合環境ルール・ベースへとロードし、次に、統合データ環境を実現するデータ・ストアを、様々なシステムからのデータと共に、投入する（populate）。その後、情報は、インターフェース・ルール・セットに従って、システムと統合環境の間を移動する。主要なルール・ベースへの追加は、システムが以前はシステムの一部ではなかったデータに対して作用することを可能にする。例えば、エンティティpartが、measured weightのロールにおいて属性weightを有するというルールが付加されてもよい（図２ａでは示されていない）このことは、その後、組立品のmeasured weightを見つけるのに、weight propertyについての振る舞い上のルールが用いられることが可能であることを意味する。
【００６４】
フレームワーク・データ・モデル
モデル表現およびインスタンス化
データ・モデルは、システムにおいて適用可能なユーザ概念の静的モデルである。例えば、システムは、在庫のある部品のリストを記録していれば、少なくとも属性ｐart_numberおよびquantity_in_stockを有するエンティティpartから構成されるデータ・モデルを有するだろう。
【００６５】
演算においては、データ・モデルを定義するための多くの技術および方法がある。その技術には、エンティティ関係（ＥＲ）モデリング、拡張エンティティ関係モデリング（ＥＥＲ）、およびオブジェクト・モデリングが含まれる。データ・モデルを記録する方法には、ＩＤＥＦ１ｘ、ＥＸＰＲＥＳＳ（ＩＳＯ  １０３０３−１１）およびＵＭＬ（Universal Modelling Language）が含まれる。本発明の記述は、ＥＥＲモデリング言語ＥＸＰＲＥＳＳ、およびそれに関連する作図言語（diagramming language）を使用する。しかしながら、本発明はどのような具体的なモデリング技術または方法にも依存しない。
【００６６】
演算においては、プログラム内のデータ・モデルを宣言またはインスタンス化する多くの方法があり、配列、記録、リスト、ネットワーク、表（データベース表を含む）、およびオブジェクトが含まれる。この記述は記録の表の点から提示されている。しかしながら、本発明がデータ・モデルをインスタンス化するどのような具体的な方法にも依存しないことが理解されるべきである。
【００６７】
フレームワーク・モデル
フレームワーク・データ・モデルでは、基本的なユーザ概念が、それら同士の関係とともに表わされる。しかしながら、従来のデータ・モデルと異なり、エンティティの属性の全てが明示的に表わされるとは限らない。協定されることが可能であって、ひいては迅速な統合の基盤となるのが、これらの付加的な属性である。例えば、図１に示されているような従来のデータ・モデル１０では、Activity１１は属性start_date１２およびend_date１３を有する。しかし、フレームワーク・データ・モデルについては、これらの属性はActivityの一部としてモデリングされない。従来のモデル１０においては、Date１４をインスタンス化するためには、day１５、month１６、およびyear１７についての値が設定されねばならないことに留意されたい。
【００６８】
フレームワーク・データ・モデルは属性モデルの組を含んでいる。図２は、本発明の実施形態に従って使用され得る具体的なケース属性モデル２０を概略的に示している。図に示されているように、各属性モデル２０は、date２７のような具体的なデータ・タイプを、このデータ・タイプとフレームワーク・モデルのエンティティとの関連の仕方とともに、定義する。この例においては、ＥＸＰＲＥＳＳは強いタイプ制約を有するので、関連付けは、関連エンティティ２６を導入することによって行われる。（図２に示されているように）関連エンティティ２６は、次いで、拡張可能選択タイプ２５を介して標的のエンティティ２９に接続する。関連が定義される方法は本発明の一部ではない。また、ＯＦＦＡプロジェクトで実証されているように、等価な方法が使用されてもよい。この実施形態にとって必須なのは、関連が、それに付加されたロールを有していなければならないことである。その結果、属性のロールが確認されることが可能である。図２に示されている例において、これは関連にattribute role２８を付加することにより行われる。このrole２８は、（図１に示されているような）従来のデータ・モデルにおける属性名に代わる。
【００６９】
各属性モデルは、データ・モデルの断片（fragment）と見なされ得る。しかし、方法体系によっては、このように表現することはできないかもしれない。多くのデータ・タイプにとって、別の属性モデルを定義することが可能である。このような属性モデルは、属性を異なるやり方でインスタンス化することが可能である。ある具体的な属性モデルは、属性についての属性パターンと呼ばれる。属性をインスタンス化するために、パターンの複製が、システムによって使用されるデータ・モデルのインスタンス化に付加されるからである。
【００７０】
図３は、本発明の実施形態に従って使用され得る、２つの別の属性パターン４０を示している。図に示されているように、下側のパターン（図３ｂ）は、ロール４３と呼ばれるString属性を、外部クラスのライブラリ５０から取り出されたExternal_class４９であるClass_association.class４８で置き換えている。図示のように、この具体的なパターンは階層状クラス構造を使用し、Class_association.role４５はClass_association.class４８のスーパータイプ(上位クラス)と呼ばれる。したがって、ユーザの視点では、２つのパターンの図３は全く同じ情報を提供する。しかしながら、計算上の視点では、第２のパターン（図３ｂ）は、階層状分類システムを用いてロールを定義していることを明確に表わしている。
【００７１】
属性パターン４０および４１はそれぞれ、これらのパターンをインスタンス化するために設定されねばならない１組のパラメータを暗示している。例えば、Date（５１、５１´）をインスタンス化するために、day（５２、５２´）、month月（５３、５３´）、year（５４、５４´）に対して値が設定されねばならない。代替パターン同士は、パターンがパラメータの同じ組によってインスタンス化されることが可能である場合、等価である。図３に示されている２つのパターン４０および４１がそうである(パターン１におけるDate_association４６のロール４３およびパターン２におけるClass_association４８のクラスが属性のロールを定義し、したがって、これらは、属性の値を設定するためのパラメータではないことに留意されたい)。
【００７２】
本発明が等価なパターンを使用可能であることが認識されるべきである。ただし、このような具体例においては、その実行にはあるパターンを別のパターンへと変換するための手段を提供する必要がある。パターン・オントロジーを用いてパターンを記述し、および（パターンの対に基づいて）コードを生成して、この変換を行なうことは、ＯＦＦＡプロジェクトにおいて実証済みである。
【００７３】
便利なことに、本発明は、非等価な属性パターン、すなわち異なるパラメータの組を使用することができる。この場合、その実行には、あるパターンから別のパターンへと変換するための手段と、データ内容の差に対処するための手段を提供する必要がある。例えば、パラメータday_of_weekを要求する日付についてのパターン３がある場合、パターン１または２からの変換には、カレンダーを使用してその曜日を見つけることができる。または、変形処理は、値が定義されないことを示すために「／ＮＵＬＬ」に値を設定することができる。
【００７４】
属性定義ルール
理解されるように、属性定義ルールは、ある具体的なロールにあるエンティティに属性を関連させるルールである。例えば、あるルールは、ActivityがロールStart_dateにあるDate属性を有する、ということを要求するかもしれない。また、別のルールは、ActivityがEnd_dateのロールにあるDate属性を有する、ということ要求するかもしれない。属性のロールは、それがコンピュータ・システムがサポートしている実世界の活動での用いられ方によって定義される。
【００７５】
上記のように、本発明の核心は技術的手段を使用して、ルールによって属性を定義する能力である。図１のような従来のシステムにおいては、データ・モデルは固定されているとともにエンティティが有するべき属性のリストを規定し、これらの規定はモデル内にプログラムされる、すなわち、ライフ・サイクルの設計段階において埋め込まれる。現世代のデータ規格（特にＰＬＣＳ）では、データ・モデルは、データ・モデルが有し得る属性を定義するという点で、一部記述的なものである。このことは、その後、エンティティが所与の状況において有していなければならない属性について記述するユーザ・ガイダンス規格、例としてＰＬＣＳデータ交換セット（ＤＥＸの）、によって補われる。やはり、これらは、システム内にプログラムされ、このため、ライフ・サイクルの設計段階において関与する。本発明では、属性はルールによって定義され、システムの運用段階において付加または削除されてもよい。このことは、設定時間を除去し、統合環境を実現ための時間を数週から数秒まで減少することができる。
【００７６】
図４は、本発明の実施形態に従って使用され得る別のデータ・モデル例６０を概略的に示している。図において示されているように、各エンティティと関連付けられている各属性タイプおよび各ロールが参照データの要素である。エンティティおよび属性は明示的に下位タイプ化されていないが、対応する参照データ要素は下位タイプされ、実際のエンティティの下位タイプは、関連する参照下位タイプによる分類を通じて定義されている。例えば、エンティティActivity６４に対応しているのは、参照データ要素_activityである。この参照データ要素_activity自身、下位タイプ_predicted_activityおよび_actual_activityを有している。
【００７７】
Date属性６１も、相違するタイプのデータについての参照データの組、すなわち、下位タイプcalendar_date６２およびyear_day_date６３（すなわち、日付が日と年のみによって参照される（例えば、２００６年２月６日が２００６の３７日目として記録される）システムである）を有する_dateを有している。この例では、calendar_date６２およびyear_day_date６３は異なる実装パターンである。
【００７８】
ActivityへのDateの関連付けも、１組の関連する参照データ、すなわち、_action_predicted_date、_action_prediction_date(つまり予測が行なわれた日付)、および_activity_actual_dateを有している。さらに、さらに、_activity_predicted_dateおよび_activity_actual_dateは両方とも、開始日と終了日の下位タイプ、すなわち、_activity_predicted_start_date６７等を有している。_activity_predicted_start_dateは、_start_dateおよび_end_dateから遺伝を受けている。
【００７９】
フレームワーク・モデル、属性パターン、および参照データの構造基盤が与えられると、データ・モデル６０は、ルールの点から、例えば以下のように特定され得る。
【００８０】
・(「PA_has_start」、_predicted_activity、_calendar_date、_action_predicted_start_date)６７
・(「PA_has_end」、_predicted_activity、_calendar_date、_action_predicted_end_date)６８
・(「PA_has_date_set」、_predicted_activity、_calendar_date、_action_predication_date)６９
・(「AA_has_start」、_actual_activity、_calendar_date、_action_actual_start_date)６７´
・(「AA_has_end」、_actual_activity、_calendar_date、_action_actual_end_date)６８´
特にこの具体例の形成においては、各ルールは４つのパラメータを有している。ルール名(その結果、ルールは他のルールから参照されることが可能になっている)、影響を受けるフレームワーク・モデル・エンティティ、適用される属性タイプ、および属性のロールである。上記のように、これは、図４に示されているように、本発明の実施形態に従って使用され得る、概略的なデータ・モデル６０と等価である。ただし、実際の実装には下位タイプActual_activityおよびPredicted_activityは無く、日付は、図３に示されているように日付パターン４０および４１によって実現される。
【００８１】
拡張属性定義ルール
上のセクションは、１つの要求された属性を適用する場合について記述している。本発明はこれに制限されず、濃度および構造を随意的に表現可能な拡張ルール（例えば属性、属性の組、複数の属性、等のリスト）を含んでいる。本発明を具体化するシステムは、少なくとも以前のセクションに記述された基礎的なルールを定義できねばならない。このシステムは、また、自身がサポートする拡張属性定義が何であるかを特定するメタルール（ルールに関するルール）の組を含んでいるべきである。これらのメタルールも参照データの階層状システムとして表現される。それは、最低でも「拡張属性定義ルール無し」についてのクラスを含んでいるべきである。そして、この階層状システムは、最低限、このメタルール階層からの１つ以上のインスタンスを含んでいるべきである。その結果、システムは、使用しているメタルールのシステムを知る。
【００８２】
ドメイン・ルールおよび制約
ドメイン・ルールは属性の値を制限するものである。例えば、パターン_calendar_dateを使用するDateは、Date.dayを１乃至３１の範囲に制限し、Date.monthを１乃至１２の範囲に制限する。
【００８３】
ドメイン制約は、属性相互間の関係に基づいて属性が取り得る値にさらなる制約を課す。例えば、開始日が終了日に先行することが要求され得る。
【００８４】
システムは、また、自身がサポートするドメイン・ルールおよびドメイン制約のタイプを特定するメタルールの組を含んでいる。これらのメタルールも参照データの階層状システムとして表現される。この階層状システムは、最低限、「ドメイン・ルール無し」についてのクラスを含んでいるべきである。
【００８５】
振る舞いルール
振る舞いルールは１つ以上の属性に適用可能な振る舞いを特定する。例えば、-date_difference振る舞いは、２つの日付の間の期間を計算する。そして、振る舞いルールは、その振る舞いが当てはまる２つのエンティティまたはエンティティ属性を特定する。例えば、
(「predicted start to actual start」、-date_difference、「PA_has_start」、「AA_has_start」、_predicted_to_actual)
は、ルール「predicted start to actual start」を定義する。このルールは、日付差振る舞いを使用して_predicted_to_actualとして記述される概念によって定義されている意味を有している情報を作成する。パラメータ、「PA_has_start」および「AA_has_start」は、ルール名であって、これらのルールによって定義される属性を振る舞いロールfirst_date、second_dateへと制約するルール名である。
【００８６】
振る舞いロールは、サブルーチンまたは手続きに対する入力、またはサービス通話、オブジェクト・ブローカー・リクエストおよびウェブ・サービスのパラメータに対する入力、または知識ベース・システムに対する入力について定義されているロールに対する入力として単に言い換えられ得る。本発明の範囲は、振る舞いルールを定義する能力を含んでいるが、これらのルールのデザインは、発明を使用する具体的なシステムによって決定される。
【００８７】
システムは、また、自身がサポートする振る舞いルールのタイプを特定するメタルールの組を含んでいる。これらのメタルールも参照データの階層状システムとして表現される。この階層状システムは、最低限、「振る舞いルール無し」についてのクラスを含んでいるべきである。
【００８８】
要約
このように、本発明は、ルールを使用して静的フレームワーク・データ・モデルを属性パターンと結合しており、参照データの階層状ネットワークを使用して関連付けを促進するとともにこの関連の意味を定義する。このことは、本発明がデータ・モデルを「自己認識的（self-aware）」にすると言うことによって、表現されることが可能である。
【００８９】
本発明は、有利なことに、拡張ルールが、例えば属性の濃度を決定し、属性のドメインを制限し、２つ以上の属性間のドメイン制約を定義することを可能にしている。本発明は、また、有利なことに、振る舞いルールの交換を可能にしている。
【００９０】
自動システム調整
自動調整の目標
自動調整の目標は相違する複数の組織が互いのデータを使用して協働することを可能にすることである。これに対する２つの著しい障害がある。非互換的なデータ・システムおよび非互換的なデータ意味である。本発明は、１つ目の問題を自動的に解決し、２つ目によって引き起こされる障害を最小限にすることを目標とする。
【００９１】
言葉の意味についての２つの哲学的な見方が本質的にある。１つ目は、抽象的観念の具象化である言葉を有している。ある具体的な青りんごは観念的な「青りんご」が生起したものである。２つ目は、言葉を、ある具体的な振る舞いへの合図として見る。例えば、「３つの青りんごを取って」は、ロボット店員が、「りんご」とコード化されている物体を容器から取って、その色をカラー・チャートと照合し、制御コンピュータ内の計数機能を使用してこれを３回行なう合図であるかもしれない。この記述は、当該第２のアプローチの観点から表現されたものである。これは、コンピュータが抽象的観念を持つことを要求しないからである。
【００９２】
単に記号レベルで非互換的なデータ・システムの問題を解決するシステムは、ユーザを誤解させる危険な状態にある。例えば、果物を買おうとしている際に、「３個の青りんご（apple）」を求める要求をコンピュータ店員に送った場合に、システムはマッキントッシュ（登録商標）・コンピュータでその要求を解決しようとするかも知れない。
【００９３】
コンピュータ・システム内のデータの意味は、そのコンピュータ・システムがサポートするシステム全体（組織）の振る舞いによって推進される。本発明は、本発明がデータ統合を提供している場合に、コンピュータを使用して組織の実際の世界での振る舞いを特定したり変更したりしようとしない。しかしながら、コンピュータ・システムの振る舞いを階層状参照データのシステムに結び付けて参照データが組織の振る舞いの観点から定義されるようにすることによって、本発明は、組織が他の互いのデータを誤解釈せずに協働することを可能にすることを目指す。
【００９４】
自動調整の用途
自動調整は、第１に組織の分散型の柔軟に結合されたネットワークでの使用を意図されている。これらは次のものを含んでいる：
（供給業者が多くの上位のタイヤ供給業者に品物を供給し、下位のタイヤ供給業者から品物を得る）サプライ・チェーン。ここで、自動調整が用いられて、ネットワークを通じてあらゆる具体的なサプライ・チェーンを調整させる。その結果、チェーン内の組織が皆、協働できる。さらに、ある供給業者が複数のサプライ・チェーンに参加している場合、これらのサプライ・チェーンは、この供給業者が自身が属する全てのサプライ・チェーンに対して１つの支援コンピュータ・システムだけで済むように、統合されることが可能である。あらゆる具体的なサプライ・チェーンが長期間に亘って存続するであろうが、ネットワークは新たなサプライ・チェーンを加え古いサプライ・チェーンを失いながら絶えず変化すると思われる。したがって、供給業者が、ネットワークの残りの部分と再調整を行なう必要なしにシステムを更新できるということは決してない。
【００９５】
（ユーザ組織が長い運用期間に亘って非常に多くの相違するシステムおよび製品をサポートしなければならない）大規模ロジスティク：その例は、航空会社を含んでいる。航空会社は、航空機を運用し、工場に予備品および検査装置を提供し、食事および制服を賄う等する。調達される製品の性質が多岐に亘り別々の寿命を有しているので、このような組織は、各々が支援コンピュータ・システムに対する異なる変化頻度を有する多くの他の組織と取引する必要がある。
【００９６】
（多くの組織（警察、消防署等）が各自のコンピュータ・システムで災害に合わせた特別組織を作る必要がある）災害対応。この場合、１つの環境が、迅速に構築されねばならないが、比較的短期間、存続すればよい。
【００９７】
（関係は、１回の取引の間だけ存続すればよいが、各々が自身のシステムを有する多数の供給者および購入者が存在し、および利用可能なシステムが絶えず変化している）電子ビジネス。
【００９８】
自動調整についての前提
本発明を用いた自動調整法についての必要な前提は、参照データの階層の上位レベルが構造と意味の両方の点で調整が取れていること、およびフレームワーク・データ・モデルの調整が取れているということである。
【００９９】
参照データの階層の上位レベルの調整なしでは、協定のための共通の出発点を見つけることは不可能であろう。さらに、もし参照データの意味の調整が取れていなければ、システムは、その後、誤解釈される情報を転送することになるだろう。参照データも、メタルールのための参照データを含んでおり、したがって、統合環境の設計のされ方は調整についての前提の一部である。本発明は統合環境のどのような具体的な設計法にも依存しない。
【０１００】
フレームワーク・データ・モデル同士は、協定のための共通点を形成しているのであって協定はされていないので、調整される必要がある。本発明はどのような具体的なフレームワーク・データ・モデルにも依存しない。フレームワークは、ＩＳＯ  １０３０３−２３９によって例示されているように、非常に広範囲なものであるかもしれないし、ＩＳＯ  １５９２６のように、参照データによって推進される縮約されたものであるかもしれない。参照データを徹底して利用することによって、どのようなシステムであっても３つのエンティティのフレームワーク・モデルへと縮約されることが可能であることが見出された。ただし、実際のデータのモデル化を参照データへと遅延し、次いで曖昧なモデルを生成するという犠牲は生じる。
【０１０１】
自動的調整環境アーキテクチャ
統合データ環境は、ユーザのシステムからデータを与えられ、また、多くの場合、それらへデータをフィード・バックすることが意図されている。本質的にアーキテクチャについての３つの選択肢がある。
【０１０２】
・１つの統合データ・ソース
・複製された統合データ・ソース
・仮想統合データ・ソース
これら選択肢７０、７５、７８は図５に例示されている。図５（ａ）乃至図５（ｃ）の要素は、以下の通りである。
【０１０３】
・組織（Ａ１乃至Ａ３、Ｂ１乃至Ｂ３、Ｃ１乃至Ｃ３）に特有の機能性を提供するユーザ・システム
・統合環境についての定義およびデータを保持する統合リポジトリ
・他の組織（Ａ８、Ａ９、Ｂ９、Ｂ１０、Ｃ５、Ｃ６）のシステムへのリンク
・統合環境からユーザ・システムへのインターフェース（Ａ４乃至Ａ６、Ｂ４乃至Ｂ６、Ｃ４）。
【０１０４】
図においてラベルを付されている各要素が自身のコンピュータ・システム上でホストされる（host（ストレージサービス提供される））ことが可能であり、または、いくつかがまとめて１つのコンピュータ・システム上でホストされることが可能であることに留意されたい。好ましい実行形態においては、１つのシステムがインターフェースと同じノード上でホストされていると捉えられることである（例えば、Ａ４を伴ったＡ１）。
【０１０５】
ユーザ・システムは自身の（データを複製する）データ・リポジトリを有していてもよいし、統合環境から直接供給されもよい。インターフェースは、データを、統合環境において使用される構造からユーザ・システムによって使用される構造へと変換する。他のユーザのシステムへのリンクは、以下に述べる３つの実行アーキテクチャのうちの何れかを使用してよい。
【０１０６】
図示されているような共通の統合環境７０においては、ユーザ・システムは共通ソースＡ７からの情報にアクセスする。したがって、共通ソースは、統合環境内の全てのユーザのための一致の取れたデータを表わす。
【０１０７】
図示されているような複製された統合環境７５においては、ユーザのデータは共通の統合環境Ｂ８へと複製され、および逆方向に複製される。しかしながら、ユーザの複製のデータ・モデルは共通の統合環境のものと同じである必要はない。ユーザの環境は、アプリケーションによって必要とされるさらなるデータ、または異なる属性パターンのデータを含んでいるかもしれないし、ユーザ組織とインターフェースを取っている複数の統合環境のための共通の記憶装置でさえあるかもしれない。必要な変換を実行するのがインターフェースの機能である。
【０１０８】
図示されているような仮想統合環境７８においては、環境は記憶装置を提供しない。このことは、エンド・ユーザのアプリケーションにおいて行なわれる。代わりに、インターフェースは、共通の環境の影響をシミュレートし、等価なトランザクションがユーザのアプリケーションによって提供されるように情報および具体的な振る舞いを求める要求を変換する。
【０１０９】
本発明の実施形態は共通の統合環境７０の点から記述される。複製された統合環境および仮想統合環境を用いることは、発明の原理を変えはしないが、実現を複雑なものにする。
【０１１０】
統合段階１−−統合環境を設定する
データ統合の第１ステップは、使用する組織が統合環境およびこれに適用するポリシーを特定することである。システムを使用する組織は、自身が他のどの組織と協働したいか、どのレベルの協働および信頼で行なうか、どれくらいの期間行なうかを決定しなければならない。これらの決定は、その下で統合環境が確立される政治的またはビジネスの土台を形成する。
【０１１１】
システムの実現は、さらなる制限を課し得る。例えば、基本的なシステムは値属性を１つだけしか付加できないかもしれない。一方、より高性能のシステムは、ドメイン制約および振る舞いを定義する能力はないが、別の実行パターンを用いて複雑な属性を提供し得るかもしれない
統合段階２−−参照データ調整、最初のサブステップ
統合環境の構築の段階２においては、様々なシステムが相互にリンクし、環境の詳細な定義を協定する。自動化された協定は、「エージェント」の概念に多くの場合結び付けられた広範な論文の主題になっている。以下の記述は、環境のパラメータがどのように定められるかを例示する。しかしながら、当業者が認識するように、本発明の主題は、統合環境を定義するためにそれらのパラメータを使用することに関する。
【０１１２】
環境を構築する最初のサブステップは、環境の参加者および参照データ・ネットワークの上位レベルを確認することである。フレームワーク・データ・モデル、属性パターン、メタルールおよび様々な協定ルールも確認を必要とする。しかしながら、該要素に対して参照データで名前をつけることによって、これらの問題は参照データを確かめることに簡略化する。
【０１１３】
参加者の確認は、セキュリティ上の目的のために必要とされ、無許可の参加者とデータを共有することや、無許可の参加者がデータを破損させることを回避するためのものである。セキュリティ機構は環境上の設定の一部であって、本発明の範囲外である。このことの２番目の態様は、参加者が環境に参加するかしないかについてのポリシーである。その選択肢は、共有データが設定の際に定義される静的な環境と、新たな参加者の追加が環境を変更し得る動的環境のいずれかである。本発明の視点から見て、これらのポリシーは、環境についての管理ルールが相違する。動的環境は、より複雑なルール、ひいてはより複雑なソフトウェアを要求するからである。これらのポリシーは、本発明の原理に影響せず、より単純な静的環境についてのみ記述される。
【０１１４】
参加者および参加ポリシーの確認の後には、参加者が参照データ・システムの共通の上位レベルを用いていることを確認することが続く。この「上位参照ネットワーク」は、単なるコンピュータが認識可能な用語体系ではなく、これらの用語に対して具体的なやり方で応答するための組織の約束事（commitment）の組である。よって、これらの用語は、これらの用語の詳細で完全で首尾一貫していて明瞭な定義を提供する公表の共通点（common point of publication）を有していなければならない。組織は、自身がこれらの用語を正しく使用していること、または、適合していることの外部監査対策の対象になっていることおよびこのような外部監査を含んでいることを主張するだけでよい。この適合の信頼度とその情報の誤解釈による危険性は、参加者が他の参加者に与える信頼度を規定する。
【０１１５】
よって、上位参照ネットワークを確認することは、公表の共通点を確認することを含んでいる。公表の共通点は、参照書類から、全参加者がアクセスするネットワーク・サービスまで、何でもよい。各用語が公表の共通点を有していなければならないが、このことは、各用語が同じ公表の共通点を使用することを意味せず、ネットワークが複数のソースから構成されていてもよいことに留意されたい。また、公表の共通点には、一連の引用を通じて到達され、例えば組織Ｘの参照ネットワークは、産業部門の規格Ｙの参照ネットワークから導出され、産業部門の規格Ｙは、統一資源識別子（ＵＲＩ）Ｚから導出される。
【０１１６】
統合段階２−−参照データ調整のためのサブステップ
先行するサブステップは、上位参照ネットワークが共通ソースに由来していることを確認した。その次のサブステップは、個々の参加者のネットワークを巡って統合環境用の共通ネットワークを作成することを含んでいる。
【０１１７】
上記のように、階層状ネットワークは木または幾つかの木の接合個所のいずれかである。したがって、ネットワーク中の各ノードには、各根の木々を下に辿っていくことによって到達する。よって、上位参照ネットワークを確認することは、最低でも、各根が公表の共通点を有していることを証明する。したがって、ネットワークを辿っていくことは、木を根から辿っていくことを含んでいる。木および階層状ネットワークを辿っていくための数多くの公知の技術があり、その利用法は何らの革新をも必要としない。木を辿っていくための再帰的アプローチが、以下に記述される。木を辿ることは、１つの公表の出所から別のものへと通じる。
【０１１８】
根ノードから開始して、所与のノードについて、参加システムは自身が使用している各子ノードをその公表の出所とともに特定し、それらを統合システム内の該ノードについての子のリストに加える。その後、統合システムは、レスポンスを照合し、各システムがある特定のノード、すなわちある特定の公表の出所に由来する所与の名前のノードを有しているかを検査する。各参加者が、その子ノードを有しているならば、そのノードは、参照データの統合システム・セットに付加されることが可能である。
【０１１９】
あるノードが各使用者によって使用されていない場合、そのクラスの使用は、参加システムの協定ポリシーによって決定される。ポリシーの選択肢には、最大性原則（maximalist policy）および最小性原則（minimalist policy）が含まれる。最大性原則では、システムは別のシステムが要求しているあらゆるクラスを取り扱い、最小性原則では、システムはシステムが既に有しているクラスのみを受け入れる。参加システムは、各ルートの子孫についての相違するポリシーを有しているかもしれない。例えば、１つのシステムは、属性ロールについてのさらなるクラスを受け付けるが、new+属性パターンに対応するクラスは拒否するかもしれない。
【０１２０】
さらに複雑なのは、図６に示されているような階層の衝突である。ここでは、１つのシステムがあるノードに対して、ある子の組と異なる子の組を有している。この図では、あるシステムはＰＱＲを使用する一方で、別のシステムはＷＸＹＺを使用する。この場合、何らかの形態の衝突解決法が必要である。例えば、子のソースを表わす中間ノード（Ａ１、Ａ２）を作製する。こうすれば、協定は、以前と同様に継続できる。
【０１２１】
統合段階３（ステップ１）−−属性ルール調整
階層状参照データの調整済みの組が得られると、次のステップは、ルール・ベースを調整することである。これは、フレームワーク・データ・モデルのエンティティに対応する参照データ・ノードを巡ることによって行われる。このための可能なアルゴリズムのうちの１つは、フレームワーク・データ・モデル内のエンティティに相当する木についての根ノードを選択し、これら根ノードを木を巡っていく際の出発点として使用することである。代替的なアルゴリズムは、ルール・ベースを合併し、それらをエンティティのタイプによって分類し、次いで、各ルールについて協定することである。
【０１２２】
エンティティ・タイプまたは下位タイプに対応する各ノードについて、様々なルール・ベースが検索されて、そのノードを参照するルールを見つける。すると、そのルールは、環境の参加者の協定ポリシーに応じて統合ルール・ベースに付加されることが可能である。以前と同様に、方策には、最大性原則「各ルールを含める」および最小性原則「システムが既に有しているものではない各ルールを拒否する」が含まれる。協定の方策は、階層状参照データ・ネットワークによって制約される。剪定される参照データに対応するあらゆるルールが、それ自体、剪定されねばならなく、それが、除去された参照データ・ネットワークにおいて未定義の用語を含んでいるからである。
【０１２３】
本発明は、調整済みのルールから統合データ・モデルを作成する能力にある。
【０１２４】
統合段階３（ステップ２）−−他のルール調整
統合環境を定義する最終ステップは、残りのルール、すなわちドメイン・ルール、ドメイン制約、振る舞いルールを協定することである。本発明は、これを行なうためのどのような具体的なアルゴリズムも指定しない。
【０１２５】
統合段階３（ステップ３）−−インターフェース・ルール・セット
各システムは、協定の結果を受け取り、この結果を自身の元の状態と比較する必要がある。各システムは、参照データ・ネットワークをノードごとに比較し、ノードに以下のいずれかのフラグを立てる。
【０１２６】
・元のセット（starting set）および統合セットの両方の中にある
・元のセットの中のみにある
・統合セットの中のみにある。
【０１２７】
各システムは、ルール・ベースについて同様の比較を行なう。
【０１２８】
統合段階４−−データ・ストアの構築（技術背景）
このセクションは、データが共通の統合環境のためにどのように構築されるかを特定する。代替的なアーキテクチャは等価な方法で作動する。
【０１２９】
各エンティティおよび各属性パターンは、データ・ストアに対応する構造を有している。エンティティまたは属性をデータ・ストアにマッピングすることは、システム・コードに埋め込まれている。例えば、プログラム言語Ｊａｖａ（登録商標）で書かれたシステムでは、各エンティティまたは属性パターンは、対応するオブジェクトを有する。各オブジェクトは、状態、すなわち、記録される必要のある値に相当する設定値を有している。例えば、Dateオブジェクトは日、月、および年についての３つの整数の組を有する。さらに、それは、日付が他のエンティティから参照されることを可能にするキーを提供する。
【０１３０】
すると、システムは、各タイプのオブジェクトの各組の永続性記憶機構を定義する必要がある。例えば、システムは、日付についてのデータベース表を作成することができる。永続性のインターフェース方法が定義されて、オブジェクトを永続性記憶装置に転送し、また別のものが定義されてオブジェクトを記憶装置から取り出す。例えば、基礎となっている永続的方法がリレーショナル・データベースである場合は、記憶方法は、データ状態要素を付加するための、データベース内のDateの表へのキーを含んでいるＳＱＬコマンドである。
【０１３１】
統合段階５４−−データの付加
エンティティをデータ・ストアに加えるために、データを加えようとしているシステムは、自身が該エンティティに適用しているルールを検査して自身が知得しているデータが何であるかを突き止め、次いで、インターフェース・ルールを検査して、統合データ環境が知得しているデータが何であるかを突き止める。このシステムの動作は、図７および図８を参照して、以下の例を通じて例示される。
【０１３２】
この例はエンティティActivityに関し、特に、その下位タイプPredicted_activityに関する。ユーザ・システムは属性predicted_start_date、predicted_end_date、およびactivity_prediction_dateを適用する。統合環境は、activity_prediction_dateを含んでいないが、activity_prediction_personを含んでいる。この例において、ユーザ・システムは、統合環境にPredicted_activityのコピーを作成する。ユーザ・システムについての完全なデータ・モデル９０は図７に示されており、統合環境１００についての完全なデータ・モデル１００は図８に示されている。
【０１３３】
１．ユーザ・システムは具体的なActivityインスタンスの転送を始動される。
【０１３４】
２．ユーザ・システムは、Activityのインスタンスを参照するために「分類」割り当て表を検査する。実際には、効率性のため、Activityエンティティは、各分類を指し示す逆向きの属性を保持していてもよい。
【０１３５】
３．ユーザ・システムは、_activityの子孫であるクラスについて発見された分類をフィルタする。この場合、_predicted_activityが見つかり、ActivityインスタンスをPredicted_activityとして分類する
４．ユーザ・システムは、ActivityおよびPredicted_activityのための属性についてのルール・ベースを検査する。ユーザ・システムは、次のルールを見つける。
【０１３６】
ａ．各Activityは、NameのロールにあるDescriptorを有している
ｂ．各Predicted_activityは、predicted_start_dateのロールにあるCalendar_dateを有している
ｃ．各Predicted_activityは、predicted_end_dateのロールにあるCalendar_dateを有している
ｄ．各Predicted_activityは、activity_prediction_dateのロールにあるCalendar_dateを有している
５．次いで、ユーザ・システムは、該ActivityのインスタンスにリンクされているDescriptorの表内のNameのインスタンスを見つける。ユーザ・システムは３つのDateについて同じことを行なう。
【０１３７】
６．次いで、ユーザ・システムは、インターフェース参照データを検査して、クラス_predicted_activity、_descriptor、および_calendar_dateの注釈を見る。これらは、ユーザ・システムおよび統合環境の両方に共通のものとして注釈付けされているので、ユーザ・システムは、この情報を転送することができる。
【０１３８】
７．次いで、ユーザ・システムは、統合環境内でActivityのインスタンスを作成し、これを_predicted_activityとして分類する。詳細は、以下の通りである。
【０１３９】
ａ．ユーザ・システムは、その下位タイプをパラメータとして取るActionについての作成法を呼び出す。
【０１４０】
ｂ．統合環境は、Activityのインスタンスを作成する。
【０１４１】
ｃ．統合環境は、_predicted_activityについての既存のClassオブジェクトをActivityの新たなインスタンスにリンクするClassification assignmentインスタンスを作成する。統合環境は、Classification_assignment.role属性をClassオブジェクトActivity（これは実行に特有な詳細であって、探索を単純化するために使用される）にリンクする。
【０１４２】
８．次いで、ユーザ・システムは、Name、Predicted_start_date、Predicted_end_dateについての属性を加える。詳しくは、Predicted_start_dateについて、以下を行なう（他の属性についての詳細は同様である）。
【０１４３】
ａ．ユーザ・システムは、Dateの作成法を呼び出し、下位タイプCalendar_dateを指定し、要求される状態パラメータ（年、月、日）を提供する。統合環境は、新たなCalendar_dateインスタンスを作成する。
【０１４４】
ｂ．次いで、ユーザ・システムは、統合環境内でActivityのインスタンスをDateのインスタンスに関連付けるための方法を呼び出す。データベースの用語においては、このことは、エントリをDateのインスタンスおよびActivityのインスタンスのためのデータベース・インデックスを含んでいるリンク表に加えることであってよい。ただし、実際上、効率上の理由から、このことは、Activityの記録名でのエントリを通じて行なわれ得る。
【０１４５】
ｃ．次いで、ユーザ・システムは、統合環境内に、Date to the Activityの割り当てを_predicted_start_dateとして分類するClassification_assignmentインスタンスを作成する。
【０１４６】
９．次いで、統合システムはActivityに関係のあるその他のルールを検査し、そのルールが属性activity_predicted_personを要求していることを見つける。この属性は、ユーザ・システムにおいて存在しないものとしてタグを付されているので、それは、Activityについてのデフォルトの人間特性の詳細についてのユーザ・システムへの問合せを作成する。
【０１４７】
１０．次いで、ユーザ・システムはそのデフォルトのPersonの定義を見つける。ユーザ・システムが、Personを可能な属性として受け入れた協定ポリシーを有していたからである。システムは、必要が生じた際にデフォルトのPersonを作成する付帯的方法を必要とする。このデフォルトは相違するコンテキストを識別し、相違するデフォルトを作成し得る。次いで、ユーザ・システムはそのデータを総合システムに返信する。
【０１４８】
１１．次いで、総合システムはPersonのインスタンスを作成し、それをactivity_predicted_personのロールにあるActivityのインスタンスに割り当てる。
【０１４９】
この創造性を有する出願の要諦は、このように、ルールを使用してエンティティおよびその属性を構築することであ。したがって、属性のリストが実行時間で決定されることを可能にする。上の拡張された例は、そのようなシステムを構築するのに十分詳細に、本発明が実際にどのように構築されることが可能かを示している。本例は、様々な決定事項、例としてオブジェクト指向の方法を使用すること、物事が行なわれる順番およびクラスの名前、を組み込んでいる。別の選択肢が本発明の使用に著しく影響しないことが認識されるべきである。
【０１５０】
自動調整のアプリケーション
次の拡張例は、さらに具体的な適用領域における本発明の使用法を示す。
【０１５１】
中間タイヤ供給業者
組織の設定
図９は、サプライ・チェーン内での本発明の使用に役に立つ具体例を示す概略図である。図示のように、中間タイヤ供給業者（図９の２００´）は、幾つかの下位供給業者２０２´、２０３から部品を買い込み、且つそれらを用いて上位供給業者またはエンド末端顧客２０５、２０６向けのより高価値の構成部品を作製する業者である。例えば、自動車産業では、ホイール供給業者は、鋼帯、ハブ用プレッシング（pressing）、トリム用の鋳型、およびタイヤを買い込むだろう。そして、ホイール供給業者は、専用機械を使用して鋼帯からホイール・リムを作り、かつリム、ハブ・トリム、およびタイヤを組み立てて、組立ライン上で車に取り付けられる準備の整ったタイヤを完成する。
【０１５２】
下位供給業者から中央タイヤ供給業者へ、および中間タイヤ供給業者から顧客までの物質の移動をサポートするために、システム内の各代理業者は電子注文管理システムを有している。電子注文管理システムは、タイヤ供給業者間の要求を送信する。図では、これは上記の、複製された統合環境アーキテクチャを使用して表わされている（２０１）。このシステムにとって基礎的なものは部品タイプ（part type）識別コードである。中間タイヤ供給業者は、ハブおよびホイール・トリムの供給業者と同様に、自身が製造している全部品についての在庫コード（stock code）および部品コードを有している。在庫コードはタイヤの具体的な仕様を特定し、部品コードはタイヤの具体的なデザインを識別する。各部品コードは一意的であるが、同じ在庫コードがタイヤのいくつかのデザイン（トレッド・パターン、強化材、および価格が異なっているかもしれない）に当てはまり得る。鋼帯供給業者は（幅、厚さ、鋼の仕様を特定する）在庫番号（stock number）および量（供給される帯の長さ）のみを扱う。
【０１５３】
自動車組立工場は各タイプのホイールに自身の在庫番号を割り当てる。中間タイヤ・メーカーは、それを把握していなければならない。このことは、組立工場が、複数のホイール供給業者から注文することを可能にする。ホイール・トリムはオプションとみなされるので、ホイールの注文は、ホイール在庫番号と、ホイール・トリム部品番号とによって特定される。したがって、中間タイヤ供給業者も、特定されたあらゆる部品オプションを記録する。
【０１５４】
したがって、中間タイヤ供給業者は、いくつかの供給ラインが交わる、関連体の集合体（nexus）である。実際上、鋼帯供給業者のような下位タイヤ供給業者のうちのいくつかは、多くのサプライ・チェーンの一部である。一方で、ホイール・トリム・メーカーのような別の業者はある具体的な自動車組立工場まで通ずるチェーンを供給する。
【０１５５】
これまでのところ、このことは、識別子タイプについて以下のタイプの階層を与える：
・Identifier_code
○part_type_identifier
○stock_number
各識別子コード（identifier code）に関連付けられているのは、コードの出所か所有者である。その結果、コードは、それらを、これを一意的に定める背景ともに、持ち運んでいる。
【０１５６】
変更を容易にするための本発明の使用
この例においては、自動車組み立て業者は、共通（universal）カタログを使用して、自身の在庫を管理することを決定する。共通カタログは専門家カタログ代理業者によって管理されている。この代理業者は、部品の明細事項を与えられると、その明細事項に対応する既存の共通カタログ番号（universal catalogue number）を見つけるか、新たな番号を割り当てる。このことは、メーカーが、新たな工場位置を捜す際に、可能な供給源を見つけることを可能にする。
【０１５７】
自動車組み立て業者は、変化をインクリメント的に展開していくことを決定する。この結果、自動車組み立て業者は、別個の部品の供給業者に対して共通カタログ番号および部品番号を提供するよう要求することから開始する。ホイールの場合、このことは、オプションとして指定されるホイール・トリムのみに当てはまる。
【０１５８】
したがって、自動車組み立て業者およびホイール・トリム供給業者は、自身の識別子タイプ階層に追加のエントリを加える。
【０１５９】
・Identifier_code
○part_type_identifier
○stock_number
○universal_catalogue_number
さらに、これらの業者は、部品が０または１の共通カタログ番号を有するというルールを加える。
【０１６０】
その結果、中間タイヤ供給業者のシステム２０１は、ホイール・トリム供給業者および自動車組み立て業者へのインターフェースを再協定することを求める要求を受け取る。公表点が１つしかないので、２つの要求が同じ定義を参照することが保証されている。したがって、それは、自身のタイプ階層およびルール・セットを拡張して、その共通カタログ番号を取り込む。属性の濃度が０または１であるので、そのデフォルトの振る舞いは、共通カタログ番号が交換の一部として供給される場合にこれを記録することだけである。このポリシーは、その後に自動車組立業者がホイール・メーカーを含む他の供給業者へとカタログ・プログラムを展開する際に変化するであろうことに留意されたい。
【０１６１】
自動車組立業者からホイールの注文を受けった場合、オプション要素はpart_type_identifierまたはuniversal_catalogue_numberになるだろう。その後、システムは、その部品についての注文を作成しなければならない。識別子コードの適切なクラスに対する探索を行なうことによって、システムは、自身が所与のオプションのことを知っているか否かと要求された注文を出すことができるか否かを判断することができる。さらに、それは、システムを使用して、在庫レベルおよび進行中の処理についての問い合わせを行なう
発明の結果
この例においては、中間タイヤ供給業者は、そのシステムを再プログラムする必要およびその他のサプライ・チェーンを乱す必要なしに、自身が動作するサプライ・チェーンのうちの１つに対する変更に対処することができた。このことは、再プログラミングの際の数週間または数か月の遅れを回避し、自動車組立業者がサプライ・チェーン全体に沿ったシステム更新を調整する必要性を回避する。さらに、他の下位供給業者および自動車組立業者は、さらなる努力なく共通カタログ番号に対する要件を加えることができた。
【０１６２】
中間タイヤ供給業者が自身のシステムを更新する必要がある唯一の点は、自らが、自身の共通カタログ番号を加える能力のようなさらなる機能性を必要とした場合である。この場合、中間タイヤ供給業者は、自身の基本的な識別子階層を拡張してuniversal_catalogue_numberを含める必要、ルール・ベースを拡張して属性ルールを含める必要、この番号を加えるための入力ダイアログを書く必要があるだろう。
【０１６３】
主なエンド・ユーザ−−国防軍
組織の設定
国防軍は、相違するタイプの多数の資産、つまり人員のための、飛行機および船から、組立橋梁および軍需品を経て、衣服および食料まで、を維持する。それらについての維持されている情報は、それらの大きさおよび重量についての一般的な情報から、軍需品の口径または貨車の軌間のような軍事行動上重要な詳細までに亘る。資産の範囲は、新たな装置が配備されるとともに古い装置が使用停止されるに連れ、絶えず変化している。そのような組織はさらに多くのサプライ・チェーンの終点であり、それぞれが、その産業または製品に合わせた、個別の経緯のコンピュータ・システムを有している。したがって、装置に関して供給された情報は大いに変化し、時間とともに変化し続ける。
【０１６４】
さらに、保管、トレーニングでの使用、基地内での軍事行動および基地外での軍事行動を含めて、軍需品の用途は多様である。ＩＴシステムは、在庫管理、使用法監視、船積、軍事行動計画および軍事行動報告に関与している。
【０１６５】
この状況で、そのような大組織が、全ての軍需品について全ての用途について適切なデータ規格を定義できるということ、および従来技術を使用してそのような規格を最新状態に保つことができるということはありそうにない。
【０１６６】
発明の結果
この例において、本発明の結果は２重である。第１に、本発明は、例えば国防軍とその供給業者との間に統合インターフェースを提供することができ、異なるインターフェース規格が主な軍需品管理システムと供給業者のシステムとの間で協定されることを可能にする。そのようなシステムは、新たな利用可能な情報が生じるとすぐに、その新たな情報を捉え、パターン変換技術を用いて、全てのデータを同じ方法でフォーマットすることができた。
【０１６７】
第２の結果は、現存システムによる機能が統合環境内の全てのデータに適用されることが可能であったことである。機能がルールによって特別の下位タイプに結び付けられるからである。
【０１６８】
迅速な災害管理応答
組織の設定
災害の特徴は、通常の応答パターンを圧倒する出来事が発生するということである。主な最近の例はインド洋津波や、例えば世界貿易センターまたはロンドン地下鉄に対するテロリストの攻撃や、チェルノブイリでのメルトダウンを含んでいる。
【０１６９】
現在の要求の１つは、様々な応答機関（警察、消防署、病院など）が、効果的に通信できる必要があることであり、ますます、このことは情報の交換を意味する（図１０を参照）。図１０は危機管理状況で本発明の具体的な実際例を示す概略図であることに注意されたい。
【０１７０】
これらの組織は、通常業務用のＩＴシステム（図１０内の基礎システムＢＳ）を既に維持しており、警察用乗り物と警官の配備、消防署の活動上の準備度または医療用品の利用可能性を確認する。これらは、運用システムであるので、最新情報の主たる出所である。さらに、これらの運用システムは、これらを使用する組織向けに絶えず調整されており、組織は、自身の必要事項に応じて相違するアプリケーションを選択しており、アプリケーションは、運用上および財務上の制約の両方によって決定される予定表に沿って展開されている。災害の際、共通インターフェースの一致が取られたとしても、全ての組織がそのインターフェースと互換性を持っているバージョンを実行するであろうことがとてもありそうにない。
【０１７１】
発明の結果
この例においては、本発明の機能は、運用上の必要事項を満たす時間スケール（典型的には、月単位ではなく分単位である）内で利用可能なインターフェースに基づいた有用な統合環境を構築することである。
【０１７２】
例えば、様々な部隊が、実行部隊（図１０内のＯＵ）に対する乗り物タイプの自身の分類、例として消防隊クラス、泡車クラス、はしご車隊クラス、事故応答隊を有する緊急配備隊クラスを、有している。各乗り物タイプは、自身の特性、例として無線タイプ、乗組員数、重量、を有している。本発明の機能は全システムの間の相互運用性を提供することである。最小性原則を使用するシステムでは、これらの分類は消防用乗り物まで簡略化され、単なる乗り物までさえ簡略化される。一方、最大性原則を使用するシステムでは、詳細な分類が全てのユーザにとって利用可能とされる。
【０１７３】
次に、自身の基本線として乗り物属性crew_numberを有しており、且つ乗り物属性に対して最大性原理を有している調整システムの具体例について検討する。システムの機能のうちの１つは、ある具体的な領域（通常、ある出来事についての内側の非常線）におけるサービス提供人員の数を、その領域の中または縁における乗り物の台数に基づいて推定することである。その動作の第１段階は該領域内の全ての乗り物を探索することである。次いで、第１段階は、各乗り物を、crew_numberとして分類された特性について検査しなければならない。このことは、あるソース・システムは該属性について値無しと報告し、あるものは該属性を提供し、あるものは下位クラスdefault_crew_numerを提供し、あるものはtypical_crew_numbeおよびactual_crew_numberの両方を提供することによって、複雑になる。該システムが下位クラスを理解せずに、クラスcrew_numberだけを理解することに留意されたい。
【０１７４】
この例においては、極度に単純化したアルゴリズムが、クラスcrew_numberまたはその下位クラスのあらゆる属性のいずれかを探索し、最初に見つかったものの値を採用する。属性が全く見つからなかった場合、アルゴリズムは、デフォルト値２を使用する。本アルゴリズムは、乗組員の全人数を、情報無しの乗り物の台数および詳細名クラスを有する数とともに、報告する。このアルゴリズムは、精巧でも殊更正確でもなく、typical_crew_numberおよびactual_crew_numberを伴った乗り物の場合、最初に見つかった値を採用する。しかしながら、このアルゴリズムは、推定値無しとしたり、または人間のオペレータが各乗り物および乗組員数を手動で数えることを要求したりする（これは、典型的には、数分を要する）のではなく数秒以内での評価を提供する。
【０１７５】
インターネット商取引
組織設定
ビジネス対ビジネスのインターネット商取引のうちの１つの目的は、買い手を売り手と迅速に合わせることである。このことの利点は、もし買いシステムおよび売りシステムの各々に対してトランザクション・データを手動で入力しなければならないならば、失われてしまうだろう。交換される情報は、買い手および売り手の名前および住所、支払いの詳細、トランザクションの規約および条件を含むであろう。このことは、共通のＸＭＬの仕組みを用いて自動で行なうことができる一方、２つの組織が同一の仕組みを使用する可能性は、現在のところ低い。
【０１７６】
発明の結果
この具体例においては、創造性を有するアプリケーションは３つの別個の概念を分離させる。基本的エンティティが交換されること、エンティティの（抽象的）属性、および属性の実行パターンである。
【０１７７】
協定の過程では、２者は、２者の各システムが共通に有しているエンティティを比較し、２者が自動で進行するのに十分な共通のエンティティを有しているかを、または２者が使用している下位タイプがトランザクションを実行できるかを特定ことによって、進行する。公表の共通点を使用することは、エンティティが各組織にとって同じものであることを保証する。共通点が無い場合、トランザクションは手動で処理される必要があるだろう。
【０１７８】
第２の段階では、２者は、適切な属性が、交換されるのに利用可能であることを検査する。やはり、該属性が利用可能でない場合、トランザクションは手入力へと戻る。
【０１７９】
第３の段階では、２者は、各属性に対する実行パターンを比較する。該パターンが同じである場合、トランザクションは進行することができ、同じでない場合、２者は、自身のリソースからまたはウェブ上のサービスとして、適切なパターン変換を見つける必要がある。このことは、ＸＭＬ出力を１つのシステムから別のシステムが要求ものへと変換するためのＸＳＬ要求の形態を取り得る。
【０１８０】
したがって、本発明の結果は、本発明がトランザクションに関与する２つのシステム間の臨時のインターフェースを迅速に構築することができるということである。ただし、該２つのシステムが同じ基本的な出発点を有していることが条件である。本発明は、２つのシステムが同一のインターフェースを有していることを要求しない（上記のように、ＯＦＦＡの実験が、１つのエンティティ／属性の組合せの約３０の異なる実現形態（これは、システム相互間の多様性の広さの指標である）相互間のインターフェースを自動的に生成できたことに留意されたい。
【０１８１】
本発明は、上に記述されている一方で、上記のおよび／または以下に述べられている特徴のあらゆる創造性ある組合せにまで及ぶ。本発明の例示的な実施形態は添付の図面を参照して本明細書に詳細に記述されているが、本発明がまさにそれらの実施形態に制限されはしないことを理解されたい。そのため、多くの改良および変形が当業者にとって明白であろう。さらに、他の特徴および実施形態が特定の特徴に言及しなくても、個別にまたは実施形態の一部として記述されている具体的な特徴は、別個に記述された別の特徴または別の実施形態の一部として、組み合わせられることが可能であることが理解される。したがって、本発明はまだ記述されないそのような具体的な組合せにまで及ぶ。
【０１８２】
略語
ＣＡＤ：コンピュータ支援設計
ＥＥＲ：拡張エンティティ関係（モデル化技術）
ＯＷＬ：ウェブ・オントロジー言語（Ｗ３Ｃ規格）
ＰＬＣ：製品ライフ・サイクル支援、ＩＳＯ１０３０３−２３９
ＳＴＥＰ：製品モデル・データ交換規格
ＳＱＬ：構造化問い合わせ言語（ＡＮＳＩ／ＩＳＯ規格）
ＵＡＶ：無人自律性乗物
ＵＲＩ：統一資源識別子
ＵＭＬ：統一モデリング言語（ＩＳＯ／ＩＥＣ  １９５０１）
ＸＭＬ：拡張可能マークアップ言語（Ｗ３Ｃ規格）
ＸＳＬ：拡張可能スタイルシート言語（Ｗ３Ｃ規格）
【図１】
2010509667.tif 000002
【図２】
2010509667.tif 000003
【図２ａ】
2010509667.tif 000004
【図３】
2010509667.tif 000005
【図４】
2010509667.tif 000006
【図５】
2010509667.tif 000007
【図６】
2010509667.tif 000008
【図７】
2010509667.tif 000009
【図８】
2010509667.tif 000010
【図９】
2010509667.tif 000011
【図１０】
2010509667.tif 000012
【国際調査報告】
2010509667.tif 000013
2010509667.tif 000014
2010509667.tif 000015