JP2022537588A - 相互運用性に対してプログラムを適合させるための方法およびシステム、ならびにそのためのアダプタ - Google Patents

Abstract

実施形態による方法およびシステムは、相互運用性をプログラミングするための一般化されたプログラムを可能にする。この方法およびシステムは、プログラムとの２方向通信のための所与の交換標準を用いるために、自動または実質的に自動の変換アダプタを使用する。アダプタが交換標準を使用するために、ディスカバリマネージャはプログラムのデータ通信構造および／またはフォーマットを学習してもよく、かつプログラムからのデータ意味情報を学習してもよい。アダプタクリエータは、プログラムのデータ通信構造およびデータ意味を交換標準に転換する変換を導出してもよい。この変換をアダプタが用いて、同様にその所与の交換標準を使用する任意のアダプタおよび／またはプログラムとの２方向通信を可能にすることで相互運用性を達成してもよい。【選択図】図１

Description

本発明は一般的に、相互運用性（ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）に対してソフトウェアプログラムを適合させるための方法およびシステムに関する。本発明はさらに、異なるプログラムが相互運用性を達成することを可能にするためのアダプタに関する。

このセクションに開示される背景技術が法律的に先行技術を構成することは認められていない。

現在、たとえばデータベースプログラムなどのプログラムは、さまざまな異なるデータモデル、インターフェース言語、命名規則、データ意味論、スキーマ、およびデータ表現を使用している。よって基本的な問題点は、さまざまなリソース間での異種情報の共有である。異なるプログラムからのデータの多様性は深刻な障壁を生じることがあり、ここではこうした多様なプログラム間の相互運用性が非常に望ましいかもしれないが、それは今まで達成不可能であった。

異種データベースに向けて多くの試みが行われてきたが、効率的かつ効果的な方式でデータに容易にアクセスしてインポートし得るアプリケーションの設計、エンジニアリング、および製造に対する顕著な要求が存在し続けている。グローバルクエリ言語を開発する努力は、外部データの世界をあたかも自身の既存のシステムおよびその特殊化された表現の延長であるかのように見たいであろう多数のユーザに満足のいく対処を行っていない。これらのユーザは異なるグローバル表現を学習することを望まないかもしれず、より重要なことに、彼らの高価な設計ツールは自身の１つの特殊化された表現のみを扱う働きをするのかもしれない。

データベースゲートウェイ、コモンオブジェクトリクエストブローカ（ＣＯＢＲＡ：Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ）、およびオープンデータベースコネクティビティ（ＯＤＢＣ：Ｏｐｅｎ Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ）インターフェースは異種性への対処を試みるものであるが、その対処は比較的表面的なレベルのものでしかない。よって、普遍的なプログラム相互運用性を達成するには最初から深刻な欠点が存在する。

これらすべての場合に、プログラム間のインターフェースにおいて設計されたいくつかの機能を呼び出して、それらが何らかの方法で相互運用できるようにするために、プログラマはなおもアプリケーションコードを書く必要があるため、余分な望ましくない費用および時間の遅延が生じる。アプリケーションプログラミングインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）のソース側か、ＡＰＩのターゲット側か、またはしばしばその両側で、データ変換および再フォーマットが必要となり得る。これはすべてプログラマに委ねられており、プログラマはケースバイケースでこの相互運用性の機能性を実装する必要があるため、所望の実装のためには多大な費用がかかる。残念ながら、これらの変換手段を構築できるような既存のソフトウェアはほとんどまたはまったくなく、各々の努力は通常一から始まる。複数の販売者がいくつかの共通フォーマットからのインポート変換手段を提供しているが、概してこれらは十分な相互運用性を提供するものではない。

さらに、データのターゲット使用が非リレーショナルデータ（例、リンク、ネスト化、またはその他のフォーマット）を予期しているとき、付加的なデータ変換が必要なことがある。通常はこれも顕著なきわめて高価なプログラミング労力と、余分な時間のかかる要件とを伴い得る。たとえリレーショナルデータモードであっても、リレーショナルテーブルの設計には通常いくつかの異なるやり方がある。すなわち、データを正規化するためのやり方は通常２通り以上ある。もしＡＰＩが提供するものと異なるデータをアプリケーションが要求するならば、通常はデータ変換が必要である。よって、ある組織が自身の特定の要件のために高価で時間のかかる特殊化された変換手段を書くことがしばしば必要となる。

近年の大企業においては、その他の相互運用性の欠点がしばしば生じる。組織の異なる一部が、自身の重要なデータを生成、記憶、および検索するために異なるシステムを用い得ることは避けられない。このデータソースの多様性は、会社単位内の調整不足、新たな技術の採用速度の相違、合併および買収、ならびに協働グループの地理的分離を含む多くの要因によってもたらされることがある。しかし、これらのさまざまなシステムからの情報を組み合わせなければ、企業はそこに含まれるデータ全体の価値を認識できないかもしれない。よって、近年の大企業において、プログラム相互運用性はより複雑になってきている。

たとえば金融またはヘルスケア産業などにおいて、合併はかなりありふれた出来事である。合併によって生じた会社は、元の単独または複数の機関のデータストアを受け継ぐ。それらのデータストアの多くは、しばしば異なる製造者からのものであり得る。取得者およびターゲットはどちらも、テキストドキュメントを記憶するための１つ以上のドキュメント管理システムを有していたかもしれない。その各々が、たとえば所与の顧客に融資を提供するリスク、または顧客の購買パターンに関する情報源などの重要な情報を計算するアプリケーションを有していたかもしれない。

合併後の新たな会社は、両方のデータストアのセットからの顧客情報にアクセスして、既存のアプリケーションおよび新たなアプリケーションを用いてその新たなポートフォリオを分析したり、一般的には共通のインターフェースを通じて両方の機関のリソースの組み合わせを使用したりする必要があるだろう。加えてその会社は、たとえ顧客データが異なるデータベースに異なるフォーマットで記憶されていたとしても、共通の顧客を識別し、それらのアカウントを統合する能力を必要とするだろう。これらはすべてプログラム相互運用性の態様であり、すべてが実装プロセスにおいて大きく過度に費用のかかる課題をもたらし得る。加えて、この実装には通常、所望の相互運用性を達成するために余分な長期にわたる遅延が必要となる。

相互運用性に対する別の試みはデータウェアハウスを確立することであり、データウェアハウスは通常、１つ以上のデータソースからのデータを、ウェアハウスデータベース内の新たに定義されたスキーマにロードすることによって構築される。このロードプロセスにおいて、データはしばしば洗浄および変換される。この基礎であるソースにおける変更はロードプロセスに変更をもたらすことがあり、データ分析に取り組むアプリケーションの部分は保護される必要がある。新たなデータソースはスキーマに変更を導入することがあり、新たなデータに対する新たなロードプロセスを定義することが必要となる。しかし、ウェアハウスデータベース管理システムの標準的な部分ではない新たなデータソースの任意の機能は通常、ウェアハウスデータベースシステム内で、またはアプリケーションの一部として再実装される必要があり、しばしばインストールのための余分な費用および無駄な時間がかかる。

ウェアハウジングのみに基づく解決策は、さまざまな他の理由から実際的でないか、または費用対効果が低いことがある。たとえば、データを元の位置からデータウェアハウスに移動させることは常に実行可能であるわけではなく、上述のとおり、ウェアハウジングにはそれ自体の維持および実装の費用がかかる。

データベースフェデレーションシステムを使用することは、普遍的な相互運用性を達成するためのさらに別の試みである。「データベースフェデレーション」という用語は、データベース管理システムがいくつかの異種データソースへの均一なアクセスを提供するアーキテクチャを示す。しかし、こうしたシステムを設計および実装する時間および費用は、通常は望ましくない余分なものである。実現される場合にもこのシステムは通常リレーショナルデータベースのみに限定されており、たとえば階層形またはその他の形などの他のフォーマットには限定されない。よってこうした限定的なアーキテクチャは、普遍的な相互運用性に対してまったく適していない。これまで既知でなかった投入データソースを加えることによるスケールアップは、いくつかの適用に対しては全く非実用的なものというわけではないにしても、せいぜい外面的な挑戦であり得る。

一般的に、たとえば異種データソースの大きなグループが使用される場合など、プログラム相互運用性の何らかの方策を達成するためのインターフェースを作成するためには、余分な費用および時間が必要である。プログラマによるこうした手動の作業は、困難ではないとしても通常は全く望ましくない余分なものである。

自動または実質的に自動の、非常に効率的かつ効果的な方式で任意の数の異なるプログラムの相互運用性を可能にするシステムおよび方法を有することは極めて望ましいであろう。こうしたシステムおよび方法は、人的エラーに対する保護を行うはずである。加えて、異なるプログラム間の普遍的な相互運用性の促進を助けるためのプログラムアダプタを有することは非常に望ましいであろう。このアダプタは自動または実質的に自動の方式で動作することで、プログラマがこれまで未知だったプログラムのためのインターフェースを開発する必要をなくすか、大きく低減させるだろう。このアダプタはこれまで未知だったデータ配置および意味を有するプログラム間でも相互運用性を可能にできるべきであり、この実装は実質的に人的介入なしに完了してもよい。よって、これまで未知だったプログラムに、相互運用性の目的のために他のプログラムが容易にアクセスして、システムを本質的に無制限の方式および高速かつ効率的なアプローチでグローバルに拡張することができる。

アダプタは、アクセス中のデータベースが他のプログラムとのアクセスを達成することを助けるために用いられてきた。たとえば、以下の米国特許（特許文献１、特許文献２、特許文献３、特許文献４、特許文献５、および特許文献６）が参照されてもよい。

加えて、非特許文献１および非特許文献２は非特許出版物である。

たとえば、特許文献６にはデータベースアダプタが開示されており、これは「アプリケーションがアクセスするよう設計された第１のデータベースとは異なる第２のデータベースと動作するようにアプリケーションプログラムを適合させることに関連する時間および費用」を低減すると主張している。しかし、第１にこうしたアダプタは、２つの異なるデータベースプログラムの各々に対して手動でカスタマイズされる必要がある。特に、効率的かつ効果的な方式で相互運用させるべき多数の異なる可能な異種プログラムが存在し得るときは、もちろんこうしたカスタマイズを実装するために過度の費用および望ましくないほどの時間がかかる。第２に、開示されるアダプタは両方のデータベースをインスタンス化するように設計されており、これはほとんどのアプリケーションにとって望ましくないおそれがある。

タンボリ（Ｔａｍｂｏｌｉ）の特許文献４およびシペルスキー（Ｓｚｙｐｅｒｓｋｉ）の特許文献１は、相互運用性を助けるための情報のデータマッピングのためのアダプタおよび技術を開示している。タンボリ特許には、データ統合に用いられるアダプタが開示されている。ユーザワークステーションによって識別属性が表示される。それらの属性は「実際にはカタログに保存される」。（第１２欄、４３～４９行。）次いでユーザは「特定の識別されたデータをソースネイティブリポジトリからデスティネーションネイティブリポジトリに転送するための転送の実行」を可能にできる。「こうした実施形態におけるユーザインターフェースは、そのように指示されたときには、ユーザによって転送された指示されたすべてのネイティブ記録に対して識別属性からのカタログキーを転送カートに書込み得る。…典型的な実施形態において、ユーザインターフェースは次いでカタログキーを転送カート（２４２）に書込み、各転送記録に対して１つのキーを書込む。」（第１３欄、１～２６行。）この動作を可能にするために、プログラマは「アダプタ機能またはメンバ方法に対するコードを書込み、このコードはネイティブリポジトリに対するデータベース管理システムの言語で書かれているか、またはネイティブリポジトリもしくはそのデータベース管理システムによってサポートされるアプリケーションプログラミングインターフェース（「ＡＰＩ」）を呼び出すものである」。（第２３欄、８～１２行。）マッピングに誤りがあったとき、「マッピングに修正が必要な範囲では、プログラミングは必要なく、テキスト編集のみが必要である。アダプタに修正が必要な範囲では、少量のプログラムのみが関与し、現在の例では１つの除外データエレメントを追加するだけで十分である。…人的エラーまたは人的選択により、実際問題として、完全結合の定義せずにデータエレメントを除外されてしまい、『修正が必要である』、という…事実。」（第２５欄、２９～４０行。）

よってマッピングは、ワークステーションにおいて情報を手動入力するときの人的エラーが原因で修正を必要とすることが明らかである。こうした人的エラーおよび手動の訂正は、費用がかかって非常に望ましくないものであろう。「典型的な実施形態において、ユーザインターフェースは次いでカタログキーを転送カート（２４２）に書込み、各転送レジスタに対して１つのキーを書込む」ことを必要とするタンボリの技術は、システム内のすべての記録に対して人的エラーを受ける。したがって、深刻な精度の問題が容易かつ予測可能にもたらされ得る。

シペルスキー特許では、「共通の形状または構造の最小限のセットに基づいて、異なる公称型をともに相関させる」ことが試みられる。「１つの実装において、開発者は目的とするいくつかの異なる公称型（ソース型）を識別し、アプリケーションプログラムによってアクセスされる共通型の形状の最小限のセットを識別する。次いで、その共通型の形状の最小限のセットを用いて中間型（ターゲット型）を作成でき、他の異なるソース型の各々は、その中間型に対してマップされ得る。たとえば、１つ以上のソース型の形状を作成されたターゲット型の対応する形状にマップする１つ以上のプロキシが作成され得る。その後、開発者によって作成されたアプリケーションプログラムは、単一のターゲット型を通じて各々の異なるソース型のマップされたデータに対するアクセス、動作、または別様での使用を行い得る。」（要約、２～１５行。）

しかし、データマッピングの目的のために、開発者は目的とする異なる公称型（ソース型）を識別し、アプリケーションプログラムによってアクセスされる共通型の形状の最小限のセットを識別する必要がある。こうしたプログラミングには過度の費用および時間がかかり得る。加えて、開発者は、彼または彼女がいくつかの異なる公称型を識別でき、さらに共通型の形状の最小限のセットを識別し得るより前に、それらの型をすでに知っている必要があることが明らかである。よってシペルスキーは、マッピングが行われ得るより前に特定のプログラムの予備知識を必要とする。

特定の実施形態をより良く理解し、それが実際にどのように実行され得るかを見るために、ここで添付の図面を参照して本発明の非限定的な好ましい実施形態を説明することとする。

米国特許第９，２０１，８７４（Ｂ２）号 米国特許第９，１３５，２９７（Ｂ２）号 米国特許第６，８８０，１５１（Ｂ２）号 米国特許第６，７９２，４３１（Ｂ２）号 米国特許第５，９７０，４９０号 米国特許出願公開第２０１４／００３２６０８（Ａ１）号

フレイル（Ｆｒｅｉｒ）、アンドレアス（Ａｎｄｒｅａｓ）、ホフェスタット（Ｈｏｆｅｓｔａｄｔ）、ラルフ（Ｒａｌｆ）、ランゲ（Ｌａｎｇｅ）、マティアス（Ｍａｔｔｈｉａｓ）、ショルツ（Ｓｃｈｏｌｚ）、ウヴェ（Ｕｗｅ）、ステファニク（Ｓｔｅｐｈａｎｉｋ）、アンドレアス（Ａｎｄｒｅａｓ）、「バイオデータサーバ；ライフサイエンスデータのオンライン統合のためのＳＱＬベースのサービス（ＢｉｏＤａｔａＳｅｒｖｅｒ；Ａ ＳＱＬ－ｂａｓｅｄ Ｓｅｒｖｉｃｅ ｆｏｒ ｔｈｅ Ｏｎｌｉｎｅ Ｉｎｔｅｇｒａｔｉｏｎ ｏｆ Ｌｉｆｅ Ｓｃｉｅｎｃｅ Ｄａｔａ）」、イン・シリコ・バイオロジー（Ｉｎ Ｓｉｌｉｃｏ Ｂｉｏｌｏｇｙ）２、０００５ バイオインフォメーション・システムズ（Ｂｉｏｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ）（２００２） デヴィ（Ｄｅｖｉ）、Ｃ．プニタ（Ｐｕｎｉｔｈａ）、ヴェンカテサン（Ｖｅｎｋａｔｅｓａｎ）、Ｖ．プラサナ（Ｐｒａｓａｎｎａ）、ディワハール（Ｄｉｗａｈａｒ）、Ｓ．、シャンムガスンダラム（Ｓｈａｎｍｕｇａｓｕｎｄａｒａｍ）、Ｇ．、「サービス指向アーキテクチャを用いた情報統合のためのモデル（Ａ Ｍｏｄｅｌ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ Ｕｓｉｎｇ Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）」、Ｉ．Ｊ．インフォメーション・エンジニアリング・アンド・エレクトロニック・ビジネス（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｎｇｉｎｅｅｒｉｎｇ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｂｕｓｉｎｅｓｓ）（ＭＥＣＳ ｗｗｗ．ｍｅｃｓ－ｐｒｅｓｓ．ｏｒｇ／２０１４年６月にてオンライン公開）

さまざまな実施形態による、異なるプログラムとともに用いて、当該異なるプログラムム間の相互運用性を可能にするためのアダプタの作成を示す象徴的なブロック図である。 さまざまな実施形態による、一対の異なるプログラムに接続されて、当該一対の異なるプログラムが相互運用を行うためのアダプタを示す象徴的なブロック図である。 さまざまな実施形態による、異なるプログラムが相互運用を行うことを促進するためのアダプタを作成する方法を示す流れ図である。 現在好ましい実施形態によるアダプタを示す、より詳細な象徴的ブロック図である。 一実施形態による、所与の交換標準データからのデータプロファイルを示す図である。 好ましい実施形態による、図３の流れ図のプロファイル整合性判定ステップのソフトウェア実装を示す図である。

ここで、添付の図面を参照して、本発明の特定の実施形態をより完全に以下に説明するが、当該図面においては、本発明のすべてではなく、いくつかの実施形態を示す。実際には本発明のこれらの実施形態は多くの異なる形になってもよく、よって本発明は本明細書に示される実施形態に限定されると解釈されるべきではない。むしろこれらの実施形態は単なる例示的な実施例として提供されているため、この開示は適用可能な法的要件を満たすだろう。全体にわたり、類似の番号は類似の構成要素を示す。

本明細書の図面に一般的に記載および図示されている実施形態のコンポーネントは、多様な異なる構成で配置および設計され得ることが容易に理解されるだろう。よって、図面に表されている本発明の装置システム、コンポーネント、および方法の特定の実施形態の以下のより詳細な説明は、請求される本発明の範囲を限定することは意図されず、本発明の１つ以上の実施形態の単なる代表例である。

実施形態によると、システムは第１および第２の異なるプログラム間の相互運用性を促進する。プログラムは、以前の未知のデータ意味およびデータ配置を有してもよい。このシステムは第１および第２の双方向交換標準アダプタを含み、各々の双方向交換標準アダプタは第１および第２のデータ関数変換を含む。この変換は、第１および第２のプログラムと、共通の交換標準との間のデータ構造およびデータフォーマットの変換関数であってもよい。加えて第１および第２のアダプタの各々は、それぞれの第１および第２のプログラムに対するデータの読取りおよび書込みを行う通信転送を含む。交換標準情報を双方向に伝達するために、通信リンクが第１および第２のアダプタを接続してもよい。

さまざまな実施形態によるデータ関数変換は、人的介入なしに作成されてもよく、かつプログラムの相互運用を可能にする。データ構造およびデータフォーマット、ならびに各プログラムに対する読取り／書込みデータは、ディスカバリマネージャによって学習される。よって、各アダプタに対するデータ変換および読取り／書込みデータは、アダプタクリエータがアダプタを作成することを可能にし、これらはすべて人的介入なしに行われてもよい。

本明細書で用いられる「データ関数変換」という用語は、本明細書において「ＥＳデータ変換」、「変換」、または「ＥＳプログラムデータ変換」など、さまざまに呼ばれることがあることが理解されるべきである。

別の実施形態は、双方向交換標準アダプタを作成する方法に関する。この方法は、所与のプログラムからプログラムデータ意味および対応するデータ位置を受信することを含む。次いで、受信されたプログラム意味が交換標準の所望の意味と等価かどうかが判定される。所与のプログラムの受信されたデータ位置からのデータが、交換標準の対応するデータと整合するかどうかに関するさらなる判定が行われてもよい。

よって、データ意味が入手可能であり得るとき、それらの意味に対するデータは、関連データを分析することによって検証されてもよい。もし入手可能な意味がなければ、未知のプログラムに含まれるデータのいずれかが目的のものであり得るかどうかを判定するためにデータ自体が分析されてもよく、これはすべて人的介入なしに高速かつ効率的な方式で完了されてもよい。

等価性および／または整合性が判定されるとき、次いで２方向関数変換が作成されてもよい。関数変換は、所与のプログラムと対応する交換標準との間のデータ転換のためのデータ構造およびデータフォーマットの関数であってもよい。関数変換は、所与のプログラムと、別の双方向交換標準アダプタを有する異なるプログラムとの相互運用性を促進するために、所与の双方向交換標準アダプタに対して提供される。

作成する方法はディスカバリマネージャを含んでもよく、ディスカバリマネージャは所与のプログラムに記憶されたデータに対するデータ意味の検索を促進する。検索は、ディスカバリマネージャを介してアプリケーションプログラミングインターフェース（ＡＰＩ）を受信することを含んでもよい。

作成する方法はディスカバリマネージャを含んでもよく、ディスカバリマネージャはメタデータの形で所与のプログラムに記憶されたデータに対するデータ意味の検索を促進する。

ディスカバリマネージャを用いて作成する方法は、受信されたプログラムデータ意味によって所望の交換標準意味を定めて、その交換標準意味が、対応するプログラムデータ意味と等価であるか否かを判定することを含んでもよい。

ディスカバリマネージャを用いて作成する方法は、プログラムデータプロファイルが存在するかどうか、および交換データプロファイルが存在するかどうかを判定することを含んでもよい。もしそれらが存在すれば、次いでディスカバリマネージャを介して、プログラムデータプロファイルと交換標準データプロファイルとの間に整合性が存在するかどうかが判定されてもよい。

作成する方法は、ディスカバリマネージャがデータ意味の等価性および／またはデータプロファイルの整合性のいずれかが存在すると判定したかどうかの判定を含んでもよく、次いで、（１）プログラムデータ意味が交換標準データ意味と等価でないとき、または（２）プログラムデータプロファイルが交換標準データプロファイルと整合していないときを除いて、アダプタクリエータによってアダプタが作成されてもよい。

作成する方法は、読取りおよび書込みコマンドと、関数データ変換とを定義する規則を作成することを含んでもよい。

さらに別の実施形態は、所与のプログラムが別の双方向交換標準アダプタを有する異なるプログラムと相互運用を行うことを可能にする双方向交換標準アダプタに関する。このアダプタは、２方向関数データ変換を定義する１つ以上の規則を含む１つ以上のハイパーオブジェクトを含んでもよい。関数変換は、所与のプログラムおよび所与の交換標準に対するデータ構造およびデータフォーマットのデータ変換関数であってもよい。この１つ以上のハイパーオブジェクトは、所与のプログラムに対すデータ読取りおよびデータ書込みに対する規則も定義してもよい。結果として、別の双方向交換標準アダプタとの相互通信が促進されて、所与のプログラムと異なるプログラムとの相互運用性が提供される。

双方向交換標準アダプタは、２方向交換標準情報を伝達するための、アダプタと別の双方向交換標準アダプタとの通信のための通信リンクをさらに含んでもよい。

一実施形態において、アダプタのハイパーオブジェクト規則は、周知の受容されたハイパーオブジェクトフレームワークにおける高速かつ効率的な実装を可能にする。加えてこの規則は、動的に修正されるか、または別様に変更されてもよい。

ここで図面、より具体的には図１を参照すると、たとえばプログラムのグループ１３のうちのプログラム１２などの所与のプログラムが、たとえばプログラム１４などの異なる未知のプログラムと相互運用を行うことを可能にするための双方向交換標準アダプタ１０が示されている。プログラムのグループ１３はたとえばデータベース、アプリケーション、およびその他の型および種類のプログラムなどの、さまざまな異なるプログラムであってもよい。加えて、データ意味は、さまざまなプログラム１３の間でこれまで既知でなくてもよい。さまざまな実施形態によると、プログラム１３の各々がアダプタ１０と類似の交換標準アダプタを備えることによって、たとえプログラム１３の各々のデータの構造および配置が異なっていてこれまで未知であり得るときでも、プログラム１３はなおも互いに相互運用して互いにデータを共有できてもよい。

プログラム１２に対するアダプタ１０を作成するために、プログラム１２において使用または記憶される特定の所望のデータの意味を発見するためのディスカバリマネージャ１５が使用されてもよい。この目的のために、１６で示される特定の受信プログラム情報がディスカバリマネージャ１５に、データ意味および対応するデータ位置をどのように見つけ出すかを通知し、それはディスカバリマネージャ１５のサーバ１７に提供されてもよい。

さまざまな実施形態によると、こうしたデータ意味およびデータ位置を入手できない可能性があるときは、データ自体からデータ意味およびデータ位置を学習するために、たとえばプログラムデータ（Ｐ－ＤＡＴＡ：ｐｒｏｇｒａｍ ｄａｔａ）などが自動的または半自動的に分析されてもよい。

実施形態によると、１８で汎用的に示された所与の交換標準（ＥＳ：ｅｘｃｈａｎｇｅ ｓｔａｎｄａｒｄ）は、ディスカバリマネージャ１５によって受信される。交換標準データＥＳ－ＤＡＴＡは、所望のデータ意味、データ構造およびフォーマット、データプロファイル、ならびにその他のものを含むがそれに限定されない、所望の所与の情報を表すデータを含んでもよい。

所与の交換標準ＥＳに対応する所与の所望のデータ意味およびそれらの位置が発見されたこと、および／またはプログラムデータＰ－ＤＡＴＡが交換標準データＥＳ－ＤＡＴＡと整合することをディスカバリマネージャ１５が学習するとき、サーバ２１を有するアダプタクリエータ１９は、次いでデータ構造およびデータフォーマットに対するデータ関数変換ならびに読取り－書込みプログラムコマンドを作成してもよい。

一旦作成されると、たとえばＥＳプログラムデータ変換などの変換は、２０に示されるようにアダプタ１０にアセンブルされてもよい。加えて、ディスカバリマネージャ１５によって通信転送読取り／書込みデータも定められてもよく、この通信転送読取り／書込みデータは、所与のプログラム１２に対する読取りおよび書込みコマンドを提供するためにアダプタクリエータ１９がプログラム１２にアクセスするために用いられてもよく、かつ２２に示されるようにアダプタ１０にアセンブルされてもよい。

ここで図２を参照すると、アダプタ１０が完成すると、所与のプログラム１２は自身のアダプタ１０を介し、ＥＳデータ通信リンク２６を通じて、たとえばアダプタ２７などの異なる双方向交換標準アダプタに接続されてもよく、このアダプタ２７がリンク２５を介してたとえばプログラム１４などの異なるプログラムに結合されることで、プログラム１２および１４の相互運用が促進されてもよい。アダプタ２７は、ディスカバリマネージャ１５およびアダプタクリエータ１９によって作成されたか、または独自の同様の専用ディスカバリマネージャ（図示せず）およびアダプタクリエータ（図示せず）によって作成されたかもしれないものと想定する。アダプタ２７はＥＳプログラムデータ変換２９を含み、このＥＳプログラムデータ変換２９は、プログラム１２とともに用いるためのアダプタ１０の変換２０と同様の方式で、プログラム１４内のプログラム情報および交換標準ＥＳの間の転換を双方向的に行う。同様に、アダプタ２７は通信転送読取り／書込みデータ２８を含んでもよく、この通信転送読取り／書込みデータ２８はアダプタ１０の通信転送データ２２と類似の機能を有し、プログラム１４に対する読取りおよび書込みコマンドを提供する。

例として、所与のプログラム１２はイタリア語の情報を含み、異なるプログラム１４は中国語の情報を含むものと想定する。さらに、交換標準ＥＳは英語であるものと想定する。プログラム１２は、異なるプログラム１４に、たとえばイタリア語のクエリなどのメッセージを、リンク１１、アダプタ１０、ＥＳデータ通信リンク２６、アダプタ２７、およびリンク２５を介してプログラム１４に送信することによって、情報を要求してもよい。それを行うときに、プログラム１２からのイタリア語のプログラム要求は、読取り／書込みコマンド２２を用いて送信され、２０においてＥＳデータ変換を介して英語に変換され、リンク２６およびアダプタ２７によって伝達されて英語の要求を提供する。次にアダプタ２７は、プログラム１４への提供のために、データ変換２９によって英語の要求を中国語に転換する。中国語の要求は、プログラム１４に対する読取り／書込みデータ２８を用いることによって、リンク２５を介してプログラム１４に伝達される。

次いでプログラム１４は、そのデータ２８に準拠した読取り／書込みコマンドを用いて、リンク２５を介してアダプタ２７に中国語で応答してもよい。アダプタ２７は、データ変換２９によって中国語の情報を英語に転換して、英語の応答をＥＳデータ通信リンク２６を介してアダプタ１０に提供する。次いでアダプタ１０は、データ変換２０を介して英語のデータ応答をイタリア語に転換して、読取り／書込みデータ２２を用いてイタリア語の情報をリンク１１を介してプログラム１２に供給する。結果として、プログラム１２および１４の間で２方向通信が行われ、これら２つのプログラムは異なっていて異なる言語で通信するか、またはその他の違いがあり得るにもかかわらず、相互運用性が提供されてもよい。

ここで図１および図３を参照して、さまざまな実施形態による双方向交換アダプタ１０を作成する方法またはプロセスをここでより詳細に説明する。プログラム１２はデータベースプログラムであり、これまで未知だったデータ意味を使用するものと想定する。しかし、たとえば図１のプログラムのグループ１３などの他のプログラムは、たとえばアプリケーションなどの異なるプログラムであってもよく、異なる未知のデータ配置を有してもよい。プログラムのグループ１３は、たとえばアダプタ１０と同様のやり方で作成されたアダプタ２７などの、その他の異なるアダプタを有してもよい。

ボックス３１において、プログラム情報および交換標準ＥＳは、ディスカバリマネージャ１５によって受信される。たとえば特定の患者情報などの所望のヘルスケア情報が望ましいことがある。プログラム情報は、プログラム１２に含まれるデータ意味（Ｐ－ＤＭ）およびその位置をどのように見つけ出すかをディスカバリマネージャ１５に通知してもよいものと想定する。ディスカバリマネージャ１５が受信するプログラム情報は、たとえばアプリケーションプログラミングインターフェース（ＡＰＩ）、メタデータ、またはデータ意味およびデータ位置などの形であってもよいし、プログラム１２に対する手動で受信する情報であってもよい。

判断ボックス３２において、ディスカバリマネージャ１５は、プログラム１２から任意のプログラムデータ意味（Ｐ－ＤＭ：ｐｒｏｇｒａｍ ｄａｔａ ｍｅａｎｉｎｇｓ）を入手可能であり得るか否かを判定する。もし入手可能であれば、判断ボックス３４において、プログラム１２の入手可能なプログラムデータ意味（Ｐ－ＤＭ）が、対応する交換標準データ意味（ＥＳ－ＤＭ）と等価であるか否かが判定される。たとえば、プログラム１２のプログラムデータ意味（Ｐ－ＤＭ）は、所与の患者に対して記録された体温についての「体温（ｔｅｍｐｅｒａｔｕｒｅ）」または「体温（ｔｅｍｐ）」を含んでもよい。交換標準データ意味の少なくとも１つが「体温」であると想定すると、次いでディスカバリマネージャ１５によって等価性が判定される。等価性の判定とは、プログラム１２が、この本例における「体温」などの交換標準データ意味ＥＳ－ＤＭと等価のプログラムデータ意味Ｐ－ＤＭを含むことを意味する。この動作は、比較またはマッチング関数を処理することによって達成されてもよい。

本例においては、交換標準データ意味ＥＳ－ＤＭが対応するプログラムデータ意味Ｐ－ＤＭと等価であるか、またはプログラムデータ意味が入手可能でないことが想定されるため、判断ボックス３８において、ディスカバリマネージャ１５は、プログラムデータＰ－ＤＡＴＡおよび交換標準データＥＳ－ＤＡＴＡが入手可能か否かを判定する。

ボックス４１に示されるように、Ｐ－ＤＡＴＡおよびＥＳ－ＤＡＴＡは入手可能であるため、ディスカバリマネージャ１５は、データプログラムＰ－ＤＡＴＡが交換標準データＥＳ－ＤＡＴＡと整合するか否かを判定してもよい。データは対応するＥＳ－ＤＡＴＡと類似していてもよいが、必ずしも同じではない。整合性は、類似、適合性、可能性、またはその他を含むがそれに限定されないさまざまなやり方で定められてもよい。Ｐ－ＤＡＴＡが交換標準に記載されるデータ範囲外にあるとき、プログラムデータは整合しないかもしれない。たとえば、プログラムデータと、生理学的に可能な体温の範囲の交換標準データとを比較することによって、プログラムデータ「１０００」は人間の患者の「体温」ではないと判定され得る。他の整合性をチェックする技術を以下に説明する。

Ｐ－ＤＡＴＡおよびＥＳ－ＤＡＴＡは入手可能であると想定する。次いで判断ボックス４１において、プログラムデータＰ－ＤＡＴＡは、ディスカバリマネージャ１５によって、対応する交換標準データＥＳ－ＤＡＴＡと整合すると判定されてもよい。整合するとき、次いでアダプタクリエータ１９はアダプタ１０に対する変換を作成してもよい。

ボックス３４および３６に示されるように、プログラムデータ意味Ｐ－ＤＭが交換標準データ意味ＥＳ－ＤＭと等価でないとき、次いで停止ボックス３６において、ディスカバリマネージャ１５は、ディスカバリマネージャ１５によるこのデータ意味のさらなる発見は行われないと判定してもよく、他のデータ意味が処理されてもよいし、プロセス全体が終了してもよい。

ボックス４１においてディスカバリマネージャ１５が、プログラムデータＰ－ＤＡＴＡと交換標準データＥＳ－ＤＡＴＡとの間に整合性がないと判定するとき、次いで停止ボックス４５に示されるように、ディスカバリマネージャ１５は、ディスカバリマネージャ１５によるこのデータ意味のさらなる発見は行われないと判定してもよく、他のデータ意味が処理されてもよいし、プロセス全体が終了してもよい。

ディスカバリマネージャ１５は、（１）ボックス３４において、プログラムデータ意味Ｐ－ＤＭが交換標準データ意味ＥＳ－ＤＭと等価であると判定し、かつ（２）ボックス３８において、プログラムデータＰ－ＤＡＴＡおよび交換標準データＥＳ－ＤＡＴＡが入手可能でないと判定してもよい。次いで、たとえばＡＮＤゲートなどのＡＮＤ関数４３、またはたとえばソフトウェア関数などのその他の技術によって、次いでアダプタクリエータ１９は、ボックス４７に示されるように、アダプタ１０に対する関数変換を提供してもよい。加えて、ボックス４１に示されるように、ディスカバリマネージャ１５が、データＰ－ＤＡＴＡとデータＥＳ－ＤＡＴＡとが整合すると判定するとき、停止ボックス４５におけるプログラムデータが交換標準データプロファイルと整合しないときを除いて、次いでアダプタクリエータ１９によってＥＳデータ変換が作成されてもよい。

さまざまな実施形態によると、プログラムデータを分析することによって、たとえ任意のデータ意味が入手可能でなくても、プログラム１２のプログラムデータが目的のものであり得るかどうかを判定できる。よって、実施形態によるたとえばプログラム１２などの未知のプログラムがそのデータのみによって分析されることによって、そのデータが交換標準ＥＳに必要とされる目的のものかどうかが判定されてもよい。

ボックス４７に示されるように、アダプタクリエータ１９は、交換標準データ構造／フォーマット（ＥＳ－ＤＳＦ：ｅｘｃｈａｎｇｅ ｓｔａｎｄａｒｄ ｄａｔａ ｓｔｒｕｃｔｕｒｅ／ｆｏｒｍａｔ）およびプログラムデータ構造／フォーマット（Ｐ－ＤＳＦ：ｐｒｏｇｒａｍ ｄａｔａ ｓｔｒｕｃｔｕｒｅ／ｆｏｒｍａｔ）の両方の関数である関数データ変換Ｔを開発する。このデータ構造は、いくつかのアプリケーションに対してはデータ単位に関係してもよい。たとえば、交換標準データ意味ＥＳ－ＤＭが「体温」である場合、ＥＳ－ＤＳＦは交換標準データに対する尺度の単位として摂氏度を使用してもよく、Ｐ－ＤＳＦは華氏度で表されてもよい。次いでアダプタクリエータ１９は、摂氏度と華氏度とを変換するために、変換Ｔの少なくとも一部分として従来の変換式を使用してもよい。一般的なデータ変換は、任意の数学関数および／または論理演算であってもよい。

交換標準に対するデータフォーマット（ＥＳ－ＤＳＦ）はバイナリフォーマットであってもよく、一方でプログラムデータフォーマット（Ｐ－ＤＳＦ）はＡＳＣＩＩ形式で表されてもよい。たとえばアダプタクリエータ１９は、バイナリおよびＡＳＣＩＩフォーマットを変換するために、変換Ｔの一部分として変換式を使用してもよい。

ボックス４９に示されるように、アダプタクリエータ１９は、プログラム１２との通信のためのデータ読取りおよびデータ書込みコマンドも提供する。

その後、ボックス５２に示されるように、アダプタ１０はアダプタクリエータ１９から、２０においてＥＳデータ変換Ｔを受信し、２２において読取りおよび書込みデータを受信する。

ここで図４を参照すると、アダプタ１０がより詳細に記載されている。好ましい実施形態によるアダプタ１０は、たとえばハイパーオブジェクト５４および５６などのハイパーオブジェクトの読取りグループ５３を含んでもよい。ハイパーオブジェクトの読取りグループ５３は、プログラム１２に結合された双方向リンク１１から情報を受信し、かつ読取り／書込みデータ２２の一部を形成する。読取りグループ５３は、たとえばハイパーオブジェクト６１およびハイパーオブジェクト６３などのハイパーオブジェクトのプログラムデータグループ５８に情報を伝達する。プログラムデータグループ５８はＥＳデータ変換２０の一部を形成し、続いて変換されたデータを双方向リンク２６およびたとえばアダプタ２７などの別のアダプタに伝達する。よって情報は、プログラム１２から双方向リンク１１ならびにハイパーオブジェクトグループ５３および５８を介して、アダプタ２７に結合された双方向リンク２６に伝達されてもよい。

反対方向では、たとえばハイパーオブジェクト６８およびハイパーオブジェクト７１などのハイパーオブジェクトのプログラムデータグループ６６は、ＥＳデータ変換２０の一部を形成し、かつアダプタ２７からの双方向リンク２６からの情報を伝達する。プログラムデータグループ６６からの情報は、たとえばハイパーオブジェクト５７およびハイパーオブジェクト５９などのハイパーオブジェクトの書込みグループ５５に伝達されてもよく、書込みグループ５５は読取り／書込みデータ２２の一部を形成する。読取り／書込みデータ２２は、プログラム１２に結合された双方向リンク１１に情報を伝達する。よって情報は、アダプタ２７からリンク２６ならびにハイパーオブジェクトグループ５５および６６を介して、プログラム１２に結合された双方向リンク１１に伝達されてもよい。

ハイパーオブジェクトのグループはサーバ６５の制御下で実行されてもよく、かつアダプタ１０とプログラム１２との通信を管理するための、たとえばＡＰＩまたはたとえばプログラム１２などのプログラムの類似の情報などに従って生成された読取り／書込みコマンド規則によってプログラムされてもよい。その規則またはアルゴリズムは、たとえば変換Ｔに関連して説明したものなどの、規則を実装するための複雑な関数公式または等式を単純な表現方式で含んでいてもよい。たとえば構造化クエリ言語（ＳＱＬ：Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）およびその他のより複雑なものなどの情報を規則として書込むための実装は、比較的容易である。ハイパーオブジェクトフレームワークは周知であるため、特定の適用において必要とされる動的更新のために、規則が比較的迅速かつ容易に動的に変更されてもよい。ハイパーオブジェクトはデータを含まない。たとえば、その全体が引用により援用される米国特許第８，３８６，４４２号などを参照されたい。

したがって、プログラムの相互運用性は、たとえそれらのプログラムが異なることがあり、その中のデータ配置がこれまで未知であっても、さまざまな実施形態によるアダプタの使用によって達成されてもよい。さらに、交換標準を使用することによって、単に交換標準を更新することによって動的更新が達成されてもよい。さまざまな実施形態によるディスカバリマネージャおよびアダプタクリエータを使用することによって、高価かつ時間のかかるプログラミングを必要とせずに、アダプタを作成して動的に更新してもよい。さまざまな実施形態によって使用されるこうした技術は、近代産業における大きなデータ規格および要件の対処を可能にし、柔軟性およびスケーリングの要件を容易にする。

ここで、プログラムデータＰ－ＤＡＴＡのみから、それが交換標準データＥＳ－ＤＡＴＡにおいて指定される所望のデータを含み得るか否かを判定する、さまざまな実施形態による技術を考える。特定の実施形態によると、ディスカバーマネージャ１５によって特定のデータプロファイルが認識されてもよい。さまざまな実施形態によるデータプロファイルは、たとえばデータ自体に対するデータ値範囲、データ階層構造、データの統計学的分布、およびその他のものなどの、プログラムデータＰ－ＤＡＴＡの固有の特徴を記述してもよい。交換標準ＥＳのデータプロファイルは、好ましくは高品質サンプルである。

交換標準ＥＳからの高品質サンプルデータ曲線は、プログラム１２からの入力データ曲線と比較されてもよい。２つのデータ曲線の整合性を判定するために、さまざまな方法が用いられてもよい。たとえば、２つのデータ曲線の整合性を算出するために、「２サンプルコルモゴロフ－スミルノフ検定（Ｔｗｏ－Ｓａｍｐｌｅ Ｋｏｌｍｏｇｏｒｏｖ－Ｓｍｉｒｎｏｖ Ｔｅｓｔ）」アルゴリズムに基づく相互相関法が用いられてもよい。

図５には、基礎となるデータから導出され得る交換標準データプロファイルの非限定的な説明の目的のみの例が示されている。図５に示されるデータ図４０は、データプロファイルを形成する１次元ヒストグラムである。図３のボックス４１を特に参照して、プログラム１２はヘルスケア向けのデータベースプログラムであり、交換標準ＥＳはヘモグロビン検査を受けた患者に関する所望のデータにアクセスするように設計されたものであると想定する。図５の図４０のデータプロファイルは、データプロファイルのフィンガープリントを定めるための、さまざまな患者記録に対するヘモグロビン値に対する（ｖｅｒｓｅｓ）、検査されたサンプル数を示している。

図４０のＸ軸には、さまざまな患者に対するヘモグロビン検査結果の検査値が示されている。Ｙ軸には、Ｘ軸において特定された各々の値に対応するヘモグロビンサンプルの数が挙げられている。検査サンプルに対する値の総数は７１５，５１１であった。その結果が、データの分布パターンを示す特徴的な曲線４０である。よってこのパターンは、ヘモグロビン臨床検査の結果に対するデータプロファイルであり、交換標準データプロファイルとして用いられてもよい。さまざまな実施形態に従って用いられ得る多くの異なる型および種類のデータプロファイルが存在してもよいことが理解されるべきである。データプロファイルの例は、心電図（ＥＣＧ：ｅｌｅｃｔｒｏ ｃａｒｄｉｏｇｒａｍｓ）、画像、ヒストグラム、および多くのその他のものを限定なしに含んでもよい。ここで図６を参照すると、図３の方法のステップ４１に対する好ましい実施形態によると、従来の畳み込みニューラルネットワーク（ＣＮＮ：Ｃｏｎｖｏｌｕｔｉｏｎａｌ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）４２が用いられてもよい。ＣＮＮは、データ曲線の不変表現（固有形状）を捕捉するようにトレーニングされてもよい。トレーニング済みのＣＮＮは、２つのデータ曲線間の整合性スコアを計算するためにも用いられてもよい。図６に示されるヒストグラム曲線４０の本例において、ＣＮＮは最初にデータ曲線４０の固有形状を捕捉するようにトレーニングされ、加えて交換標準としての曲線４０に基づいて２つの曲線間の所望の整合性スコアを計算するようにトレーニングされる。次いで、プログラム１２からのＰ－ＤＡＴＡおよび交換標準ＥＳ－ＤＡＴＡの両方が、処理の目的のためにＣＮＮに流される。整合性判定の結果は、図示のように「ｙｅｓ」または「ｎｏ」のいずれかであってもよい。

前述の図面および特定の実施形態の詳細な説明に鑑みて、開示される実施形態およびその他の実施形態は、プログラムがこれまで未知だったデータを有し得るという事実にもかかわらず、異なるプログラムの中および間のプログラム相互運用性を達成するための新規の技術に関するものであることが当業者に明らかになるだろう。少なくとも部分的に、そのプログラムが所望のデータを含むか否かを学習することによって、所望の相互運用性を達成することを助けるためのアダプタが作成されてもよい。

実施形態による方法およびシステムは、相互運用性をプログラミングするための一般化されたプログラムを可能にする。この方法およびシステムは、プログラムとの２方向通信のための所与の交換標準を用いるために、自動または実質的に自動の変換アダプタを使用する。アダプタが交換標準を使用するために、ディスカバリマネージャはプログラムのデータ通信構造および／またはフォーマットを学習してもよく、かつプログラムからのデータ意味情報を学習してもよい。アダプタクリエータは、プログラムのデータ通信構造およびデータ意味を交換標準に転換する変換を導出してもよい。この変換をアダプタが用いて、同様にその所与の交換標準を使用する任意のアダプタおよび／またはプログラムとの２方向通信を可能にすることで相互運用性を達成してもよい。

上記の例を参照して本発明を説明したが、本明細書において開示される実施形態の真の趣旨および範囲内で多くの修正形および変形が予期されることが理解されるだろう。前述の説明および添付の図面において提供される教示の利益を有する本発明に関連する技術分野の当業者には、多くの修正形およびその他の実施形態が考えられるであろう。したがって、本発明は本明細書において開示される特定の実施形態またはその修正形にいかなるやり方でも限定されず、その修正形およびその他の実施形態は添付の請求項の範囲に含まれることが意図および予期されていることが理解されるべきである。本明細書においては特定の用語が使用されているが、それらの用語は一般的な説明の意味のみで用いられており、限定の目的では用いられていない。

Claims (17)

1. 異なるプログラムが相互運用を行うことを可能にするためのアダプタを作成する方法であって、
   所与のプログラムに対するプログラムデータ意味および対応するデータ位置を受信するステップと、
   前記受信されたプログラム意味が交換標準の所望のデータ意味と等価かどうかを判定するステップと、
   前記所与のプログラムの前記受信されたデータ位置からのデータが前記交換標準の対応するデータと整合するかどうかを判定するステップと、
   等価性および／または整合性が判定されるときに、２方向関数データ変換を作成するステップであって、前記関数データ変換は、前記所与のプログラムと前記対応する交換標準との間のデータの転換のためのデータ構造およびデータフォーマットの関数である、前記作成するステップと、
   前記所与のプログラムと、別の双方向交換標準アダプタを有する異なるプログラムとの相互運用性を促進するために、所与の双方向交換標準アダプタに対して前記関数変換を提供するステップとを含む、方法。
2. ディスカバリマネージャを提供するステップをさらに含む、請求項１に記載の方法。
3. 第１に言及された前記判定するステップは、前記ディスカバリマネージャを介して、前記所与のプログラムに記憶されたデータに対するデータ意味を検索するステップを含む、請求項２に記載の方法。
4. 前記受信するステップは、前記ディスカバリマネージャを介してアプリケーションプログラミングインターフェース（ＡＰＩ）を受信するステップを含む、請求項３に記載の方法。
5. 前記検索するステップは、前記ディスカバリマネージャを介して前記所与のプログラムからメタデータを受信するステップを含む、請求項３に記載の方法。
6. 第１に言及された前記判定するステップは、前記ディスカバリマネージャを介して前記所望の交換標準意味と前記受信されたプログラムデータ意味とを比較して、前記交換標準意味が対応するプログラムデータ意味と等価であるか否かを判定するステップを含む、請求項３に記載の方法。
7. 第２に言及された前記判定するステップは、畳み込みニューラルネットワークを含む前記ディスカバリマネージャを介して、プログラムデータプロファイルが存在するかどうか、および交換データプロファイルが存在するかどうかを判定するステップを含む、請求項１に記載の方法。
8. 第２に言及された前記判定するステップは、前記ディスカバリマネージャを介して、前記プログラムデータプロファイルと前記交換標準データプロファイルとの前記整合性を判定するステップを含む、請求項７に記載の方法。
9. アダプタクリエータを提供するステップをさらに含む、請求項７に記載の方法。
10. 前記ディスカバリマネージャが前記データ意味の前記等価性および／または前記データプロファイルの前記整合性のいずれかが存在すると判定したとき、次いで、（１）前記プログラムデータ意味が前記交換標準データ意味と等価であるとき、および（２）前記プログラムデータプロファイルが前記交換標準データプロファイルと整合していないときを除いて、前記アダプタクリエータによって前記変換が作成される、請求項９に記載の方法。
11. データ読取りおよび／またはデータ書込みに対する規則を含む２方向通信転送変換を作成するステップをさらに含む、請求項７に記載の方法。
12. 前記データ変換および前記通信転送変換は、前記所与の交換標準アダプタに対する前記アダプタクリエータによってアセンブルされる、請求項１１に記載の方法。
13. 所与のプログラムが別の双方向交換標準アダプタを有する異なるプログラムと相互運用を行うことを可能にするための双方向交換標準アダプタであって、
    ２方向関数変換を定義する１つ以上の規則を含む１つ以上のハイパーオブジェクトを含み、
    前記関数変換は、前記所与のプログラムおよび交換標準に対するデータ構造およびデータフォーマットのデータ変換関数であり、
    前記１つ以上のハイパーオブジェクトは、前記所与のプログラムに対するデータ読取りおよびデータ書込みに対する規則を定義し、
    それによって前記別の双方向交換標準アダプタとの相互通信が促進されて、前記所与のプログラムと前記異なるプログラムとの相互運用性が提供される、双方向交換標準アダプタ。
14. 前記規則は前記関数変換と、前記データ読取りと、前記データ書込みとを含む、請求項１３に記載の双方向交換標準アダプタ。
15. ２方向交換標準情報を伝達するための、前記アダプタと別の双方向交換標準アダプタとの通信のための通信リンクをさらに含む、請求項１３に記載の双方向交換標準アダプタ。
16. 第１および第２の異なるプログラム間の相互運用性を促進するためのシステムであって、
    第１のデータ関数変換を含む第１の双方向交換標準アダプタを含み、前記第１のデータ関数変換は、前記第１のプログラムと交換標準との間のデータ構造およびデータフォーマットの変換関数であり、
    前記第１の双方向交換標準アダプタは、前記第１のプログラムに対するデータ読取りおよびデータ書込みのための第１の通信転送変換をさらに含み、前記システムはさらに、
    第２のデータ関数変換を含む第２の双方向交換標準アダプタを含み、前記第２のデータ関数変換は、前記第２のプログラムと前記交換標準との間のデータフォーマットにおけるデータ構造の変換関数であり、
    前記第２の双方向交換アダプタは、前記第２のプログラムに対するデータ読取りおよびデータ書込みのための第２の通信転送変換標準を含み、前記システムはさらに、
    交換標準情報を双方向に伝達するために前記第１および前記第２のアダプタの間に通信的に接続された共通の通信リンクを含む、システム。
17. 前記第１および第２のアダプタの各々は、各々が規則を有する１つ以上のハイパーオブジェクトを含み、前記規則は前記第１および第２のデータ関数変換と、前記第１および第２の通信転送変換とを定義する、請求項１６に記載のシステム。
    

Images