(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023100852
(43)【公開日】2023-07-19
(54)【発明の名称】相互運用性に対してプログラムを適合させるための方法およびシステム、ならびにそのためのアダプタ
(51)【国際特許分類】
G06F 8/30 20180101AFI20230711BHJP
【FI】
G06F8/30
【審査請求】未請求
【請求項の数】20
【出願形態】OL
(21)【出願番号】P 2023076657
(22)【出願日】2023-05-08
(62)【分割の表示】P 2022508889の分割
【原出願日】2020-08-13
(31)【優先権主張番号】16/542,259
(32)【優先日】2019-08-15
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】513084399
【氏名又は名称】クリニコンプ インターナショナル,インコーポレイテッド
【氏名又は名称原語表記】CLINICOMP INTERNATIONAL,INC.
【住所又は居所原語表記】Attention Chris Haudenschild,Chairman of the Board and Chief Executive Officer,9655 Towne Centre Drive,San Diego, California 92121 United States of America
(74)【代理人】
【識別番号】100110559
【弁理士】
【氏名又は名称】友野 英三
(72)【発明者】
【氏名】クリス エー.ハウデンシルド
(57)【要約】 (修正有)
【課題】相互運用性をプログラミングするための一般化されたプログラムを可能にする方法およびシステムを提供する。
【解決手段】プログラムとの2方向通信のための所与の交換標準を用いるために、自動または実質的に自動の変換アダプタを使用する方法であって、アダプタは、交換標準を使用するために、ディスカバリマネージャはプログラムのデータ通信構造および/またはフォーマットを学習し、かつ、プログラムからのデータ意味情報を学習する。アダプタクリエータは、プログラムのデータ通信構造およびデータ意味を交換標準に転換する変換を導出し、この変換をアダプタが用いて、同様にその所与の交換標準を使用する任意のアダプタおよび/またはプログラムとの2方向通信を可能にすることで相互運用性を達成する。
【選択図】
図1
【特許請求の範囲】
【請求項1】
異なるプログラムが相互運用を行うことを可能にするためのアダプタを作成する方法であって、
プログラムに対するプログラムデータ意味および対応するデータ位置を受信するステップと、
前記受信されたプログラムデータ意味が交換標準の所定のデータ意味と実質的に等価かどうかを判定するステップと、
前記プログラムの前記受信されたデータ位置からのデータが前記交換標準の対応するデータと実質的に整合するかどうかを判定するステップと、
実質的な等価性または実質的な整合性が判定される場合には、2方向の関数データ変換を作成するステップと、
自動または実質的に自動の方式で、前記プログラムと、別の双方向交換標準アダプタを有する異なるプログラムとの間の相互運用性を可能にするために、双方向交換標準アダプタに対する前記2方向の関数データ変換を提供するステップと
を含む、方法。
【請求項2】
ディスカバリマネージャを提供するステップをさらに含む、請求項1に記載の方法。
【請求項3】
前記受信されたプログラムデータ意味が交換標準の所望のデータ意味と実質的に等価かどうかを判定するステップは、前記ディスカバリマネージャを介して、前記プログラムに格納されたデータについてのデータ意味を検索するステップを含む、請求項2に記載の方法。
【請求項4】
前記受信するステップは、前記ディスカバリマネージャを介してアプリケーションプログラミングインターフェース(API)を受信するステップを含む、請求項3に記載の方法。
【請求項5】
前記検索するステップは、前記ディスカバリマネージャを介して前記プログラムからメタデータを受信するステップを含む、請求項3に記載の方法。
【請求項6】
前記受信されたプログラムデータ意味が前記交換標準の所望のデータ意味と実質的に等価かどうかを判定するステップは、前記ディスカバリマネージャを介して所定の交換標準意味と前記受信されたプログラムデータ意味とを比較して、前記交換標準意味が対応するプログラムデータ意味と実質的に等価であるか否かを判定するステップを含む、請求項1に記載の方法。
【請求項7】
前記プログラムの前記受信されたデータ位置からのデータが前記交換標準の対応するデータと整合するかどうかを判定するステップは、畳み込みニューラルネットワークを含むディスカバリマネージャを介して、プログラムデータプロファイルが存在するかどうか、および交換標準データプロファイルが存在するかどうかを判定するステップを含む、請求項1に記載の方法。
【請求項8】
前記ディスカバリマネージャを介して、前記プログラムデータプロファイルと前記交換標準データプロファイルとの間の前記整合性を判定するステップをさらに含む、請求項7に記載の方法。
【請求項9】
(1)前記プログラムデータ意味が前記交換標準の前記データ意味と等価であり、かつ(2)前記プログラムデータプロファイルが前記交換標準データプロファイルと整合していない場合を除いて、前記ディスカバリマネージャが前記データ意味の前記等価性および/または前記データプロファイルの前記整合性が存在すると判定する場合には、前記アダプタクリエータによって前記変換が作成される、請求項7に記載の方法。
【請求項10】
データ読取りおよび/またはデータ書込みに対する規則を含む通信転送変換を作成するステップをさらに含む、請求項1に記載の方法。
【請求項11】
前記関数データ変換および前記通信転送変換は、前記交換標準アダプタに対する前記アダプタクリエータによってアセンブルされる、請求項10に記載の方法。
【請求項12】
前記プログラムの前記受信されたデータ位置からのデータが前記交換標準の対応するデータと実質的に整合するかどうかを判定するステップは、交換標準データ意味(ES-DM:exchange standard date meaning)と等しいプログラムデータ意味(P-DM:program data meaning)を含む、請求項1に記載の方法。
【請求項13】
前記プログラムの前記受信されたデータ位置からのデータが前記交換標準の対応するデータと整合するかどうかを判定するステップは、プログラムデータ(P-DATA :program data)が前記交換標準に記載されたデータ範囲から外れているか否かを判定するステップを含む、請求項1記載の方法。
【請求項14】
前記プログラムデータは、固有の特徴としての、データ値範囲、データ階層構造、およびデータの統計学的分布、のうちの1つ以上を含む、請求項13に記載の方法。
【請求項15】
前記実質的な等価性または実質的な整合性が判定される場合に2方向の関数データ変換を作成するステップは、交換標準データ構造/フォーマット(ES-DSF:exchange standard data structure/format)およびプログラムデータ構造/フォーマット(P-DSF:program data structure/format)の両方の関数である関数データ変換(T)を開発するステップを含む、請求項1に記載の方法。
【請求項16】
第1のプログラムと、第2の異なるプログラムとの相互運用性を促進するためのシステムであって、
第1のデータ関数変換を含む第1の双方向交換標準アダプタであって、前記第1のデータ関数変換は第1のプログラムと交換標準との間のデータ構造およびデータフォーマットの変換関数であり、前記第1の双方向交換標準アダプタは前記第1のプログラムに対するデータ読取りおよびデータ書込みのための第1の通信転送変換をさらに含む、第1の双方向交換標準アダプタと、
第2のデータ関数変換を含む第2の双方向交換標準アダプタであって、前記第2のデータ関数変換は第2のプログラムと前記交換標準との間のデータフォーマットにおけるデータ構造の変換関数であり、前記第2の双方向交換標準アダプタは前記第2のプログラムに対するデータ読取りおよびデータ書込みのための第2の通信転送変換標準を含む、第2の双方向交換標準アダプタと、
前記第1の双方向交換標準アダプタおよび前記第2の双方向交換標準アダプタ間に結合され、それらの間で交換標準情報を自動的にまたは実質的に自動的に双方向に伝達する、共通の通信リンクと
を含む、システム。
【請求項17】
前記第1の双方向交換標準アダプタは、各々が規則を有する1以上のハイパーオブジェクトを含み、前記規則は前記第1のデータ関数変換と前記第1の通信転送変換とを定義する、請求項16に記載のシステム。
【請求項18】
前記第2の双方向交換標準アダプタは、各々が規則を有する1以上のハイパーオブジェクトを含み、前記規則は前記第2のデータ関数変換と前記第2の通信転送変換とを定義する、請求項16に記載のシステム。
【請求項19】
前記第1のプログラムは、第1の言語による情報を含み、前記第2のプログラムは、前記第1の言語とは異なる第2の言語による情報を含む、請求項16に記載のシステム。
【請求項20】
前記共通の通信リンクを通じて伝達された前記交換標準情報は、前記第1の言語および前記第2の言語とは異なる第3の言語による情報を含む、請求項19に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は一般的に、相互運用性(interoperability)に対してソフトウェアプログラムを適合させるための方法およびシステムに関する。本発明はさらに、異なるプログラムが相互運用性を達成することを可能にするためのアダプタに関する。
【背景技術】
【0002】
このセクションに開示される背景技術が法律的に先行技術を構成することは認められていない。
【0003】
現在、たとえばデータベースプログラムなどのプログラムは、さまざまな異なるデータモデル、インターフェース言語、命名規則、データ意味論、スキーマ、およびデータ表現を使用している。よって基本的な問題点は、さまざまなリソース間での異種情報の共有である。異なるプログラムからのデータの多様性は深刻な障壁を生じることがあり、ここではこうした多様なプログラム間の相互運用性が非常に望ましいかもしれないが、それは今まで達成不可能であった。
【0004】
異種データベースに向けて多くの試みが行われてきたが、効率的かつ効果的な方式でデータに容易にアクセスしてインポートし得るアプリケーションの設計、エンジニアリング、および製造に対する顕著な要求が存在し続けている。グローバルクエリ言語を開発する努力は、外部データの世界をあたかも自身の既存のシステムおよびその特殊化された表現の延長であるかのように見たいであろう多数のユーザに満足のいく対処を行っていない。これらのユーザは異なるグローバル表現を学習することを望まないかもしれず、より重要なことに、彼らの高価な設計ツールは自身の1つの特殊化された表現のみを扱う働きをするのかもしれない。
【0005】
データベースゲートウェイ、コモンオブジェクトリクエストブローカ(COBRA:Common Object Request Broker)、およびオープンデータベースコネクティビティ(ODBC:Open Database Connectivity)インターフェースは異種性への対処を試みるものであるが、その対処は比較的表面的なレベルのものでしかない。よって、普遍的なプログラム相互運用性を達成するには最初から深刻な欠点が存在する。
【0006】
これらすべての場合に、プログラム間のインターフェースにおいて設計されたいくつかの機能を呼び出して、それらが何らかの方法で相互運用できるようにするために、プログラマはなおもアプリケーションコードを書く必要があるため、余分な望ましくない費用および時間の遅延が生じる。アプリケーションプログラミングインターフェース(API:application programming interface)のソース側か、APIのターゲット側か、またはしばしばその両側で、データ変換および再フォーマットが必要となり得る。これはすべてプログラマに委ねられており、プログラマはケースバイケースでこの相互運用性の機能性を実装する必要があるため、所望の実装のためには多大な費用がかかる。残念ながら、これらの変換手段を構築できるような既存のソフトウェアはほとんどまたはまったくなく、各々の努力は通常一から始まる。複数の販売者がいくつかの共通フォーマットからのインポート変換手段を提供しているが、概してこれらは十分な相互運用性を提供するものではない。
【0007】
さらに、データのターゲット使用が非リレーショナルデータ(例、リンク、ネスト化、またはその他のフォーマット)を予期しているとき、付加的なデータ変換が必要なことがある。通常はこれも顕著なきわめて高価なプログラミング労力と、余分な時間のかかる要件とを伴い得る。たとえリレーショナルデータモードであっても、リレーショナルテーブルの設計には通常いくつかの異なるやり方がある。すなわち、データを正規化するためのやり方は通常2通り以上ある。もしAPIが提供するものと異なるデータをアプリケーションが要求するならば、通常はデータ変換が必要である。よって、ある組織が自身の特定の要件のために高価で時間のかかる特殊化された変換手段を書くことがしばしば必要となる。
【0008】
近年の大企業においては、その他の相互運用性の欠点がしばしば生じる。組織の異なる一部が、自身の重要なデータを生成、記憶、および検索するために異なるシステムを用い得ることは避けられない。このデータソースの多様性は、会社単位内の調整不足、新たな技術の採用速度の相違、合併および買収、ならびに協働グループの地理的分離を含む多くの要因によってもたらされることがある。しかし、これらのさまざまなシステムからの情報を組み合わせなければ、企業はそこに含まれるデータ全体の価値を認識できないかもしれない。よって、近年の大企業において、プログラム相互運用性はより複雑になってきている。
【0009】
たとえば金融またはヘルスケア産業などにおいて、合併はかなりありふれた出来事である。合併によって生じた会社は、元の単独または複数の機関のデータストアを受け継ぐ。それらのデータストアの多くは、しばしば異なる製造者からのものであり得る。取得者およびターゲットはどちらも、テキストドキュメントを記憶するための1つ以上のドキュメント管理システムを有していたかもしれない。その各々が、たとえば所与の顧客に融資を提供するリスク、または顧客の購買パターンに関する情報源などの重要な情報を計算するアプリケーションを有していたかもしれない。
【0010】
合併後の新たな会社は、両方のデータストアのセットからの顧客情報にアクセスして、既存のアプリケーションおよび新たなアプリケーションを用いてその新たなポートフォリオを分析したり、一般的には共通のインターフェースを通じて両方の機関のリソースの組み合わせを使用したりする必要があるだろう。加えてその会社は、たとえ顧客データが異なるデータベースに異なるフォーマットで記憶されていたとしても、共通の顧客を識別し、それらのアカウントを統合する能力を必要とするだろう。これらはすべてプログラム相互運用性の態様であり、すべてが実装プロセスにおいて大きく過度に費用のかかる課題をもたらし得る。加えて、この実装には通常、所望の相互運用性を達成するために余分な長期にわたる遅延が必要となる。
【0011】
相互運用性に対する別の試みはデータウェアハウスを確立することであり、データウェアハウスは通常、1つ以上のデータソースからのデータを、ウェアハウスデータベース内の新たに定義されたスキーマにロードすることによって構築される。このロードプロセスにおいて、データはしばしば洗浄および変換される。この基礎であるソースにおける変更はロードプロセスに変更をもたらすことがあり、データ分析に取り組むアプリケーションの部分は保護される必要がある。新たなデータソースはスキーマに変更を導入することがあり、新たなデータに対する新たなロードプロセスを定義することが必要となる。しかし、ウェアハウスデータベース管理システムの標準的な部分ではない新たなデータソースの任意の機能は通常、ウェアハウスデータベースシステム内で、またはアプリケーションの一部として再実装される必要があり、しばしばインストールのための余分な費用および無駄な時間がかかる。
【0012】
ウェアハウジングのみに基づく解決策は、さまざまな他の理由から実際的でないか、または費用対効果が低いことがある。たとえば、データを元の位置からデータウェアハウスに移動させることは常に実行可能であるわけではなく、上述のとおり、ウェアハウジングにはそれ自体の維持および実装の費用がかかる。
【0013】
データベースフェデレーションシステムを使用することは、普遍的な相互運用性を達成するためのさらに別の試みである。「データベースフェデレーション」という用語は、データベース管理システムがいくつかの異種データソースへの均一なアクセスを提供するアーキテクチャを示す。しかし、こうしたシステムを設計および実装する時間および費用は、通常は望ましくない余分なものである。実現される場合にもこのシステムは通常リレーショナルデータベースのみに限定されており、たとえば階層形またはその他の形などの他のフォーマットには限定されない。よってこうした限定的なアーキテクチャは、普遍的な相互運用性に対してまったく適していない。これまで既知でなかった投入データソースを加えることによるスケールアップは、いくつかの適用に対しては全く非実用的なものというわけではないにしても、せいぜい外面的な挑戦であり得る。
【0014】
一般的に、たとえば異種データソースの大きなグループが使用される場合など、プログラム相互運用性の何らかの方策を達成するためのインターフェースを作成するためには、余分な費用および時間が必要である。プログラマによるこうした手動の作業は、困難ではないとしても通常は全く望ましくない余分なものである。
【0015】
自動または実質的に自動の、非常に効率的かつ効果的な方式で任意の数の異なるプログラムの相互運用性を可能にするシステムおよび方法を有することは極めて望ましいであろう。こうしたシステムおよび方法は、人的エラーに対する保護を行うはずである。加えて、異なるプログラム間の普遍的な相互運用性の促進を助けるためのプログラムアダプタを有することは非常に望ましいであろう。このアダプタは自動または実質的に自動の方式で動作することで、プログラマがこれまで未知だったプログラムのためのインターフェースを開発する必要をなくすか、大きく低減させるだろう。このアダプタはこれまで未知だったデータ配置および意味を有するプログラム間でも相互運用性を可能にできるべきであり、この実装は実質的に人的介入なしに完了してもよい。よって、これまで未知だったプログラムに、相互運用性の目的のために他のプログラムが容易にアクセスして、システムを本質的に無制限の方式および高速かつ効率的なアプローチでグローバルに拡張することができる。
【0016】
アダプタは、アクセス中のデータベースが他のプログラムとのアクセスを達成することを助けるために用いられてきた。たとえば、以下の米国特許(特許文献1、特許文献2、特許文献3、特許文献4、特許文献5、および特許文献6)が参照されてもよい。
【0017】
加えて、非特許文献1および非特許文献2は非特許出版物である。
【0018】
たとえば、特許文献6にはデータベースアダプタが開示されており、これは「アプリケーションがアクセスするよう設計された第1のデータベースとは異なる第2のデータベースと動作するようにアプリケーションプログラムを適合させることに関連する時間および費用」を低減すると主張している。しかし、第1にこうしたアダプタは、2つの異なるデータベースプログラムの各々に対して手動でカスタマイズされる必要がある。特に、効率的かつ効果的な方式で相互運用させるべき多数の異なる可能な異種プログラムが存在し得るときは、もちろんこうしたカスタマイズを実装するために過度の費用および望ましくないほどの時間がかかる。第2に、開示されるアダプタは両方のデータベースをインスタンス化するように設計されており、これはほとんどのアプリケーションにとって望ましくないおそれがある。
【0019】
タンボリ(Tamboli)の特許文献4およびシペルスキー(Szyperski)の特許文献1は、相互運用性を助けるための情報のデータマッピングのためのアダプタおよび技術を開示している。タンボリ特許には、データ統合に用いられるアダプタが開示されている。ユーザワークステーションによって識別属性が表示される。それらの属性は「実際にはカタログに保存される」。(第12欄、43~49行。)次いでユーザは「特定の識別されたデータをソースネイティブリポジトリからデスティネーションネイティブリポジトリに転送するための転送の実行」を可能にできる。「こうした実施形態におけるユーザインターフェースは、そのように指示されたときには、ユーザによって転送された指示されたすべてのネイティブ記録に対して識別属性からのカタログキーを転送カートに書込み得る。…典型的な実施形態において、ユーザインターフェースは次いでカタログキーを転送カート(242)に書込み、各転送記録に対して1つのキーを書込む。」(第13欄、1~26行。)この動作を可能にするために、プログラマは「アダプタ機能またはメンバ方法に対するコードを書込み、このコードはネイティブリポジトリに対するデータベース管理システムの言語で書かれているか、またはネイティブリポジトリもしくはそのデータベース管理システムによってサポートされるアプリケーションプログラミングインターフェース(「API」)を呼び出すものである」。(第23欄、8~12行。)マッピングに誤りがあったとき、「マッピングに修正が必要な範囲では、プログラミングは必要なく、テキスト編集のみが必要である。アダプタに修正が必要な範囲では、少量のプログラムのみが関与し、現在の例では1つの除外データエレメントを追加するだけで十分である。…人的エラーまたは人的選択により、実際問題として、完全結合の定義せずにデータエレメントを除外されてしまい、『修正が必要である』、という…事実。」(第25欄、29~40行。)
【0020】
よってマッピングは、ワークステーションにおいて情報を手動入力するときの人的エラーが原因で修正を必要とすることが明らかである。こうした人的エラーおよび手動の訂正は、費用がかかって非常に望ましくないものであろう。「典型的な実施形態において、ユーザインターフェースは次いでカタログキーを転送カート(242)に書込み、各転送レジスタに対して1つのキーを書込む」ことを必要とするタンボリの技術は、システム内のすべての記録に対して人的エラーを受ける。したがって、深刻な精度の問題が容易かつ予測可能にもたらされ得る。
【0021】
シペルスキー特許では、「共通の形状または構造の最小限のセットに基づいて、異なる公称型をともに相関させる」ことが試みられる。「1つの実装において、開発者は目的とするいくつかの異なる公称型(ソース型)を識別し、アプリケーションプログラムによってアクセスされる共通型の形状の最小限のセットを識別する。次いで、その共通型の形状の最小限のセットを用いて中間型(ターゲット型)を作成でき、他の異なるソース型の各々は、その中間型に対してマップされ得る。たとえば、1つ以上のソース型の形状を作成されたターゲット型の対応する形状にマップする1つ以上のプロキシが作成され得る。その後、開発者によって作成されたアプリケーションプログラムは、単一のターゲット型を通じて各々の異なるソース型のマップされたデータに対するアクセス、動作、または別様での使用を行い得る。」(要約、2~15行。)
【0022】
しかし、データマッピングの目的のために、開発者は目的とする異なる公称型(ソース型)を識別し、アプリケーションプログラムによってアクセスされる共通型の形状の最小限のセットを識別する必要がある。こうしたプログラミングには過度の費用および時間がかかり得る。加えて、開発者は、彼または彼女がいくつかの異なる公称型を識別でき、さらに共通型の形状の最小限のセットを識別し得るより前に、それらの型をすでに知っている必要があることが明らかである。よってシペルスキーは、マッピングが行われ得るより前に特定のプログラムの予備知識を必要とする。
【0023】
特定の実施形態をより良く理解し、それが実際にどのように実行され得るかを見るために、ここで添付の図面を参照して本発明の非限定的な好ましい実施形態を説明することとする。
【先行技術文献】
【特許文献】
【0024】
【特許文献1】米国特許第9,201,874(B2)号
【特許文献2】米国特許第9,135,297(B2)号
【特許文献3】米国特許第6,880,151(B2)号
【特許文献4】米国特許第6,792,431(B2)号
【特許文献5】米国特許第5,970,490号
【特許文献6】米国特許出願公開第2014/0032608(A1)号
【非特許文献】
【0025】
【非特許文献1】フレイル(Freir)、アンドレアス(Andreas)、ホフェスタット(Hofestadt)、ラルフ(Ralf)、ランゲ(Lange)、マティアス(Matthias)、ショルツ(Scholz)、ウヴェ(Uwe)、ステファニク(Stephanik)、アンドレアス(Andreas)、「バイオデータサーバ;ライフサイエンスデータのオンライン統合のためのSQLベースのサービス(BioDataServer;A SQL-based Service for the Online Integration of Life Science Data)」、イン・シリコ・バイオロジー(In Silico Biology)2、0005 バイオインフォメーション・システムズ(Bioinformation Systems)(2002)
【非特許文献2】デヴィ(Devi)、C.プニタ(Punitha)、ヴェンカテサン(Venkatesan)、V.プラサナ(Prasanna)、ディワハール(Diwahar)、S.、シャンムガスンダラム(Shanmugasundaram)、G.、「サービス指向アーキテクチャを用いた情報統合のためのモデル(A Model for Information Integration Using Service Oriented Architecture)」、I.J.インフォメーション・エンジニアリング・アンド・エレクトロニック・ビジネス(Information Engineering and Electronic Business)(MECS www.mecs-press.org/2014年6月にてオンライン公開)
【図面の簡単な説明】
【0026】
【
図1】さまざまな実施形態による、異なるプログラムとともに用いて、当該異なるプログラムム間の相互運用性を可能にするためのアダプタの作成を示す象徴的なブロック図である。
【
図2】さまざまな実施形態による、一対の異なるプログラムに接続されて、当該一対の異なるプログラムが相互運用を行うためのアダプタを示す象徴的なブロック図である。
【
図3】さまざまな実施形態による、異なるプログラムが相互運用を行うことを促進するためのアダプタを作成する方法を示す流れ図である。
【
図4】現在好ましい実施形態によるアダプタを示す、より詳細な象徴的ブロック図である。
【
図5】一実施形態による、所与の交換標準データからのデータプロファイルを示す図である。
【
図6】好ましい実施形態による、
図3の流れ図のプロファイル整合性判定ステップのソフトウェア実装を示す図である。
【発明を実施するための形態】
【0027】
ここで、添付の図面を参照して、本発明の特定の実施形態をより完全に以下に説明するが、当該図面においては、本発明のすべてではなく、いくつかの実施形態を示す。実際には本発明のこれらの実施形態は多くの異なる形になってもよく、よって本発明は本明細書に示される実施形態に限定されると解釈されるべきではない。むしろこれらの実施形態は単なる例示的な実施例として提供されているため、この開示は適用可能な法的要件を満たすだろう。全体にわたり、類似の番号は類似の構成要素を示す。
【0028】
本明細書の図面に一般的に記載および図示されている実施形態のコンポーネントは、多様な異なる構成で配置および設計され得ることが容易に理解されるだろう。よって、図面に表されている本発明の装置システム、コンポーネント、および方法の特定の実施形態の以下のより詳細な説明は、請求される本発明の範囲を限定することは意図されず、本発明の1つ以上の実施形態の単なる代表例である。
【0029】
実施形態によると、システムは第1および第2の異なるプログラム間の相互運用性を促進する。プログラムは、以前の未知のデータ意味およびデータ配置を有してもよい。このシステムは第1および第2の双方向交換標準アダプタを含み、各々の双方向交換標準アダプタは第1および第2のデータ関数変換を含む。この変換は、第1および第2のプログラムと、共通の交換標準との間のデータ構造およびデータフォーマットの変換関数であってもよい。加えて第1および第2のアダプタの各々は、それぞれの第1および第2のプログラムに対するデータの読取りおよび書込みを行う通信転送を含む。交換標準情報を双方向に伝達するために、通信リンクが第1および第2のアダプタを接続してもよい。
【0030】
さまざまな実施形態によるデータ関数変換は、人的介入なしに作成されてもよく、かつプログラムの相互運用を可能にする。データ構造およびデータフォーマット、ならびに各プログラムに対する読取り/書込みデータは、ディスカバリマネージャによって学習される。よって、各アダプタに対するデータ変換および読取り/書込みデータは、アダプタクリエータがアダプタを作成することを可能にし、これらはすべて人的介入なしに行われてもよい。
【0031】
本明細書で用いられる「データ関数変換」という用語は、本明細書において「ESデータ変換」、「変換」、または「ESプログラムデータ変換」など、さまざまに呼ばれることがあることが理解されるべきである。
【0032】
別の実施形態は、双方向交換標準アダプタを作成する方法に関する。この方法は、所与のプログラムからプログラムデータ意味および対応するデータ位置を受信することを含む。次いで、受信されたプログラム意味が交換標準の所望の意味と等価かどうかが判定される。所与のプログラムの受信されたデータ位置からのデータが、交換標準の対応するデータと整合するかどうかに関するさらなる判定が行われてもよい。
【0033】
よって、データ意味が入手可能であり得るとき、それらの意味に対するデータは、関連データを分析することによって検証されてもよい。もし入手可能な意味がなければ、未知のプログラムに含まれるデータのいずれかが目的のものであり得るかどうかを判定するためにデータ自体が分析されてもよく、これはすべて人的介入なしに高速かつ効率的な方式で完了されてもよい。
【0034】
等価性および/または整合性が判定されるとき、次いで2方向関数変換が作成されてもよい。関数変換は、所与のプログラムと対応する交換標準との間のデータ転換のためのデータ構造およびデータフォーマットの関数であってもよい。関数変換は、所与のプログラムと、別の双方向交換標準アダプタを有する異なるプログラムとの相互運用性を促進するために、所与の双方向交換標準アダプタに対して提供される。
【0035】
作成する方法はディスカバリマネージャを含んでもよく、ディスカバリマネージャは所与のプログラムに記憶されたデータに対するデータ意味の検索を促進する。検索は、ディスカバリマネージャを介してアプリケーションプログラミングインターフェース(API)を受信することを含んでもよい。
【0036】
作成する方法はディスカバリマネージャを含んでもよく、ディスカバリマネージャはメタデータの形で所与のプログラムに記憶されたデータに対するデータ意味の検索を促進する。
【0037】
ディスカバリマネージャを用いて作成する方法は、受信されたプログラムデータ意味によって所望の交換標準意味を定めて、その交換標準意味が、対応するプログラムデータ意味と等価であるか否かを判定することを含んでもよい。
【0038】
ディスカバリマネージャを用いて作成する方法は、プログラムデータプロファイルが存在するかどうか、および交換データプロファイルが存在するかどうかを判定することを含んでもよい。もしそれらが存在すれば、次いでディスカバリマネージャを介して、プログラムデータプロファイルと交換標準データプロファイルとの間に整合性が存在するかどうかが判定されてもよい。
【0039】
作成する方法は、ディスカバリマネージャがデータ意味の等価性および/またはデータプロファイルの整合性のいずれかが存在すると判定したかどうかの判定を含んでもよく、次いで、(1)プログラムデータ意味が交換標準データ意味と等価でないとき、または(2)プログラムデータプロファイルが交換標準データプロファイルと整合していないときを除いて、アダプタクリエータによってアダプタが作成されてもよい。
【0040】
作成する方法は、読取りおよび書込みコマンドと、関数データ変換とを定義する規則を作成することを含んでもよい。
【0041】
さらに別の実施形態は、所与のプログラムが別の双方向交換標準アダプタを有する異なるプログラムと相互運用を行うことを可能にする双方向交換標準アダプタに関する。このアダプタは、2方向関数データ変換を定義する1つ以上の規則を含む1つ以上のハイパーオブジェクトを含んでもよい。関数変換は、所与のプログラムおよび所与の交換標準に対するデータ構造およびデータフォーマットのデータ変換関数であってもよい。この1つ以上のハイパーオブジェクトは、所与のプログラムに対すデータ読取りおよびデータ書込みに対する規則も定義してもよい。結果として、別の双方向交換標準アダプタとの相互通信が促進されて、所与のプログラムと異なるプログラムとの相互運用性が提供される。
【0042】
双方向交換標準アダプタは、2方向交換標準情報を伝達するための、アダプタと別の双方向交換標準アダプタとの通信のための通信リンクをさらに含んでもよい。
【0043】
一実施形態において、アダプタのハイパーオブジェクト規則は、周知の受容されたハイパーオブジェクトフレームワークにおける高速かつ効率的な実装を可能にする。加えてこの規則は、動的に修正されるか、または別様に変更されてもよい。
【0044】
ここで図面、より具体的には
図1を参照すると、たとえばプログラムのグループ13のうちのプログラム12などの所与のプログラムが、たとえばプログラム14などの異なる未知のプログラムと相互運用を行うことを可能にするための双方向交換標準アダプタ10が示されている。プログラムのグループ13はたとえばデータベース、アプリケーション、およびその他の型および種類のプログラムなどの、さまざまな異なるプログラムであってもよい。加えて、データ意味は、さまざまなプログラム13の間でこれまで既知でなくてもよい。さまざまな実施形態によると、プログラム13の各々がアダプタ10と類似の交換標準アダプタを備えることによって、たとえプログラム13の各々のデータの構造および配置が異なっていてこれまで未知であり得るときでも、プログラム13はなおも互いに相互運用して互いにデータを共有できてもよい。
【0045】
プログラム12に対するアダプタ10を作成するために、プログラム12において使用または記憶される特定の所望のデータの意味を発見するためのディスカバリマネージャ15が使用されてもよい。この目的のために、16で示される特定の受信プログラム情報がディスカバリマネージャ15に、データ意味および対応するデータ位置をどのように見つけ出すかを通知し、それはディスカバリマネージャ15のサーバ17に提供されてもよい。
【0046】
さまざまな実施形態によると、こうしたデータ意味およびデータ位置を入手できない可能性があるときは、データ自体からデータ意味およびデータ位置を学習するために、たとえばプログラムデータ(P-DATA:program data)などが自動的または半自動的に分析されてもよい。
【0047】
実施形態によると、18で汎用的に示された所与の交換標準(ES:exchange standard)は、ディスカバリマネージャ15によって受信される。交換標準データES-DATAは、所望のデータ意味、データ構造およびフォーマット、データプロファイル、ならびにその他のものを含むがそれに限定されない、所望の所与の情報を表すデータを含んでもよい。
【0048】
所与の交換標準ESに対応する所与の所望のデータ意味およびそれらの位置が発見されたこと、および/またはプログラムデータP-DATAが交換標準データES-DATAと整合することをディスカバリマネージャ15が学習するとき、サーバ21を有するアダプタクリエータ19は、次いでデータ構造およびデータフォーマットに対するデータ関数変換ならびに読取り-書込みプログラムコマンドを作成してもよい。
【0049】
一旦作成されると、たとえばESプログラムデータ変換などの変換は、20に示されるようにアダプタ10にアセンブルされてもよい。加えて、ディスカバリマネージャ15によって通信転送読取り/書込みデータも定められてもよく、この通信転送読取り/書込みデータは、所与のプログラム12に対する読取りおよび書込みコマンドを提供するためにアダプタクリエータ19がプログラム12にアクセスするために用いられてもよく、かつ22に示されるようにアダプタ10にアセンブルされてもよい。
【0050】
ここで
図2を参照すると、アダプタ10が完成すると、所与のプログラム12は自身のアダプタ10を介し、ESデータ通信リンク26を通じて、たとえばアダプタ27などの異なる双方向交換標準アダプタに接続されてもよく、このアダプタ27がリンク25を介してたとえばプログラム14などの異なるプログラムに結合されることで、プログラム12および14の相互運用が促進されてもよい。アダプタ27は、ディスカバリマネージャ15およびアダプタクリエータ19によって作成されたか、または独自の同様の専用ディスカバリマネージャ(図示せず)およびアダプタクリエータ(図示せず)によって作成されたかもしれないものと想定する。アダプタ27はESプログラムデータ変換29を含み、このESプログラムデータ変換29は、プログラム12とともに用いるためのアダプタ10の変換20と同様の方式で、プログラム14内のプログラム情報および交換標準ESの間の転換を双方向的に行う。同様に、アダプタ27は通信転送読取り/書込みデータ28を含んでもよく、この通信転送読取り/書込みデータ28はアダプタ10の通信転送データ22と類似の機能を有し、プログラム14に対する読取りおよび書込みコマンドを提供する。
【0051】
例として、所与のプログラム12はイタリア語の情報を含み、異なるプログラム14は中国語の情報を含むものと想定する。さらに、交換標準ESは英語であるものと想定する。プログラム12は、異なるプログラム14に、たとえばイタリア語のクエリなどのメッセージを、リンク11、アダプタ10、ESデータ通信リンク26、アダプタ27、およびリンク25を介してプログラム14に送信することによって、情報を要求してもよい。それを行うときに、プログラム12からのイタリア語のプログラム要求は、読取り/書込みコマンド22を用いて送信され、20においてESデータ変換を介して英語に変換され、リンク26およびアダプタ27によって伝達されて英語の要求を提供する。次にアダプタ27は、プログラム14への提供のために、データ変換29によって英語の要求を中国語に転換する。中国語の要求は、プログラム14に対する読取り/書込みデータ28を用いることによって、リンク25を介してプログラム14に伝達される。
【0052】
次いでプログラム14は、そのデータ28に準拠した読取り/書込みコマンドを用いて、リンク25を介してアダプタ27に中国語で応答してもよい。アダプタ27は、データ変換29によって中国語の情報を英語に転換して、英語の応答をESデータ通信リンク26を介してアダプタ10に提供する。次いでアダプタ10は、データ変換20を介して英語のデータ応答をイタリア語に転換して、読取り/書込みデータ22を用いてイタリア語の情報をリンク11を介してプログラム12に供給する。結果として、プログラム12および14の間で2方向通信が行われ、これら2つのプログラムは異なっていて異なる言語で通信するか、またはその他の違いがあり得るにもかかわらず、相互運用性が提供されてもよい。
【0053】
ここで
図1および
図3を参照して、さまざまな実施形態による双方向交換アダプタ10を作成する方法またはプロセスをここでより詳細に説明する。プログラム12はデータベースプログラムであり、これまで未知だったデータ意味を使用するものと想定する。しかし、たとえば
図1のプログラムのグループ13などの他のプログラムは、たとえばアプリケーションなどの異なるプログラムであってもよく、異なる未知のデータ配置を有してもよい。プログラムのグループ13は、たとえばアダプタ10と同様のやり方で作成されたアダプタ27などの、その他の異なるアダプタを有してもよい。
【0054】
ボックス31において、プログラム情報および交換標準ESは、ディスカバリマネージャ15によって受信される。たとえば特定の患者情報などの所望のヘルスケア情報が望ましいことがある。プログラム情報は、プログラム12に含まれるデータ意味(P-DM)およびその位置をどのように見つけ出すかをディスカバリマネージャ15に通知してもよいものと想定する。ディスカバリマネージャ15が受信するプログラム情報は、たとえばアプリケーションプログラミングインターフェース(API)、メタデータ、またはデータ意味およびデータ位置などの形であってもよいし、プログラム12に対する手動で受信する情報であってもよい。
【0055】
判断ボックス32において、ディスカバリマネージャ15は、プログラム12から任意のプログラムデータ意味(P-DM:program data meanings)を入手可能であり得るか否かを判定する。もし入手可能であれば、判断ボックス34において、プログラム12の入手可能なプログラムデータ意味(P-DM)が、対応する交換標準データ意味(ES-DM)と等価であるか否かが判定される。たとえば、プログラム12のプログラムデータ意味(P-DM)は、所与の患者に対して記録された体温についての「体温(temperature)」または「体温(temp)」を含んでもよい。交換標準データ意味の少なくとも1つが「体温」であると想定すると、次いでディスカバリマネージャ15によって等価性が判定される。等価性の判定とは、プログラム12が、この本例における「体温」などの交換標準データ意味ES-DMと等価のプログラムデータ意味P-DMを含むことを意味する。この動作は、比較またはマッチング関数を処理することによって達成されてもよい。
【0056】
本例においては、交換標準データ意味ES-DMが対応するプログラムデータ意味P-DMと等価であるか、またはプログラムデータ意味が入手可能でないことが想定されるため、判断ボックス38において、ディスカバリマネージャ15は、プログラムデータP-DATAおよび交換標準データES-DATAが入手可能か否かを判定する。
【0057】
ボックス41に示されるように、P-DATAおよびES-DATAは入手可能であるため、ディスカバリマネージャ15は、データプログラムP-DATAが交換標準データES-DATAと整合するか否かを判定してもよい。データは対応するES-DATAと類似していてもよいが、必ずしも同じではない。整合性は、類似、適合性、可能性、またはその他を含むがそれに限定されないさまざまなやり方で定められてもよい。P-DATAが交換標準に記載されるデータ範囲外にあるとき、プログラムデータは整合しないかもしれない。たとえば、プログラムデータと、生理学的に可能な体温の範囲の交換標準データとを比較することによって、プログラムデータ「1000」は人間の患者の「体温」ではないと判定され得る。他の整合性をチェックする技術を以下に説明する。
【0058】
P-DATAおよびES-DATAは入手可能であると想定する。次いで判断ボックス41において、プログラムデータP-DATAは、ディスカバリマネージャ15によって、対応する交換標準データES-DATAと整合すると判定されてもよい。整合するとき、次いでアダプタクリエータ19はアダプタ10に対する変換を作成してもよい。
【0059】
ボックス34および36に示されるように、プログラムデータ意味P-DMが交換標準データ意味ES-DMと等価でないとき、次いで停止ボックス36において、ディスカバリマネージャ15は、ディスカバリマネージャ15によるこのデータ意味のさらなる発見は行われないと判定してもよく、他のデータ意味が処理されてもよいし、プロセス全体が終了してもよい。
【0060】
ボックス41においてディスカバリマネージャ15が、プログラムデータP-DATAと交換標準データES-DATAとの間に整合性がないと判定するとき、次いで停止ボックス45に示されるように、ディスカバリマネージャ15は、ディスカバリマネージャ15によるこのデータ意味のさらなる発見は行われないと判定してもよく、他のデータ意味が処理されてもよいし、プロセス全体が終了してもよい。
【0061】
ディスカバリマネージャ15は、(1)ボックス34において、プログラムデータ意味P-DMが交換標準データ意味ES-DMと等価であると判定し、かつ(2)ボックス38において、プログラムデータP-DATAおよび交換標準データES-DATAが入手可能でないと判定してもよい。次いで、たとえばANDゲートなどのAND関数43、またはたとえばソフトウェア関数などのその他の技術によって、次いでアダプタクリエータ19は、ボックス47に示されるように、アダプタ10に対する関数変換を提供してもよい。加えて、ボックス41に示されるように、ディスカバリマネージャ15が、データP-DATAとデータES-DATAとが整合すると判定するとき、停止ボックス45におけるプログラムデータが交換標準データプロファイルと整合しないときを除いて、次いでアダプタクリエータ19によってESデータ変換が作成されてもよい。
【0062】
さまざまな実施形態によると、プログラムデータを分析することによって、たとえ任意のデータ意味が入手可能でなくても、プログラム12のプログラムデータが目的のものであり得るかどうかを判定できる。よって、実施形態によるたとえばプログラム12などの未知のプログラムがそのデータのみによって分析されることによって、そのデータが交換標準ESに必要とされる目的のものかどうかが判定されてもよい。
【0063】
ボックス47に示されるように、アダプタクリエータ19は、交換標準データ構造/フォーマット(ES-DSF:exchange standard data structure/format)およびプログラムデータ構造/フォーマット(P-DSF:program data structure/format)の両方の関数である関数データ変換Tを開発する。このデータ構造は、いくつかのアプリケーションに対してはデータ単位に関係してもよい。たとえば、交換標準データ意味ES-DMが「体温」である場合、ES-DSFは交換標準データに対する尺度の単位として摂氏度を使用してもよく、P-DSFは華氏度で表されてもよい。次いでアダプタクリエータ19は、摂氏度と華氏度とを変換するために、変換Tの少なくとも一部分として従来の変換式を使用してもよい。一般的なデータ変換は、任意の数学関数および/または論理演算であってもよい。
【0064】
交換標準に対するデータフォーマット(ES-DSF)はバイナリフォーマットであってもよく、一方でプログラムデータフォーマット(P-DSF)はASCII形式で表されてもよい。たとえばアダプタクリエータ19は、バイナリおよびASCIIフォーマットを変換するために、変換Tの一部分として変換式を使用してもよい。
【0065】
ボックス49に示されるように、アダプタクリエータ19は、プログラム12との通信のためのデータ読取りおよびデータ書込みコマンドも提供する。
【0066】
その後、ボックス52に示されるように、アダプタ10はアダプタクリエータ19から、20においてESデータ変換Tを受信し、22において読取りおよび書込みデータを受信する。
【0067】
ここで
図4を参照すると、アダプタ10がより詳細に記載されている。好ましい実施形態によるアダプタ10は、たとえばハイパーオブジェクト54および56などのハイパーオブジェクトの読取りグループ53を含んでもよい。ハイパーオブジェクトの読取りグループ53は、プログラム12に結合された双方向リンク11から情報を受信し、かつ読取り/書込みデータ22の一部を形成する。読取りグループ53は、たとえばハイパーオブジェクト61およびハイパーオブジェクト63などのハイパーオブジェクトのプログラムデータグループ58に情報を伝達する。プログラムデータグループ58はESデータ変換20の一部を形成し、続いて変換されたデータを双方向リンク26およびたとえばアダプタ27などの別のアダプタに伝達する。よって情報は、プログラム12から双方向リンク11ならびにハイパーオブジェクトグループ53および58を介して、アダプタ27に結合された双方向リンク26に伝達されてもよい。
【0068】
反対方向では、たとえばハイパーオブジェクト68およびハイパーオブジェクト71などのハイパーオブジェクトのプログラムデータグループ66は、ESデータ変換20の一部を形成し、かつアダプタ27からの双方向リンク26からの情報を伝達する。プログラムデータグループ66からの情報は、たとえばハイパーオブジェクト57およびハイパーオブジェクト59などのハイパーオブジェクトの書込みグループ55に伝達されてもよく、書込みグループ55は読取り/書込みデータ22の一部を形成する。読取り/書込みデータ22は、プログラム12に結合された双方向リンク11に情報を伝達する。よって情報は、アダプタ27からリンク26ならびにハイパーオブジェクトグループ55および66を介して、プログラム12に結合された双方向リンク11に伝達されてもよい。
【0069】
ハイパーオブジェクトのグループはサーバ65の制御下で実行されてもよく、かつアダプタ10とプログラム12との通信を管理するための、たとえばAPIまたはたとえばプログラム12などのプログラムの類似の情報などに従って生成された読取り/書込みコマンド規則によってプログラムされてもよい。その規則またはアルゴリズムは、たとえば変換Tに関連して説明したものなどの、規則を実装するための複雑な関数公式または等式を単純な表現方式で含んでいてもよい。たとえば構造化クエリ言語(SQL:Structured Query Language)およびその他のより複雑なものなどの情報を規則として書込むための実装は、比較的容易である。ハイパーオブジェクトフレームワークは周知であるため、特定の適用において必要とされる動的更新のために、規則が比較的迅速かつ容易に動的に変更されてもよい。ハイパーオブジェクトはデータを含まない。たとえば、その全体が引用により援用される米国特許第8,386,442号などを参照されたい。
【0070】
したがって、プログラムの相互運用性は、たとえそれらのプログラムが異なることがあり、その中のデータ配置がこれまで未知であっても、さまざまな実施形態によるアダプタの使用によって達成されてもよい。さらに、交換標準を使用することによって、単に交換標準を更新することによって動的更新が達成されてもよい。さまざまな実施形態によるディスカバリマネージャおよびアダプタクリエータを使用することによって、高価かつ時間のかかるプログラミングを必要とせずに、アダプタを作成して動的に更新してもよい。さまざまな実施形態によって使用されるこうした技術は、近代産業における大きなデータ規格および要件の対処を可能にし、柔軟性およびスケーリングの要件を容易にする。
【0071】
ここで、プログラムデータP-DATAのみから、それが交換標準データES-DATAにおいて指定される所望のデータを含み得るか否かを判定する、さまざまな実施形態による技術を考える。特定の実施形態によると、ディスカバーマネージャ15によって特定のデータプロファイルが認識されてもよい。さまざまな実施形態によるデータプロファイルは、たとえばデータ自体に対するデータ値範囲、データ階層構造、データの統計学的分布、およびその他のものなどの、プログラムデータP-DATAの固有の特徴を記述してもよい。交換標準ESのデータプロファイルは、好ましくは高品質サンプルである。
【0072】
交換標準ESからの高品質サンプルデータ曲線は、プログラム12からの入力データ曲線と比較されてもよい。2つのデータ曲線の整合性を判定するために、さまざまな方法が用いられてもよい。たとえば、2つのデータ曲線の整合性を算出するために、「2サンプルコルモゴロフ-スミルノフ検定(Two-Sample Kolmogorov-Smirnov Test)」アルゴリズムに基づく相互相関法が用いられてもよい。
【0073】
図5には、基礎となるデータから導出され得る交換標準データプロファイルの非限定的な説明の目的のみの例が示されている。
図5に示されるデータ
図40は、データプロファイルを形成する1次元ヒストグラムである。
図3のボックス41を特に参照して、プログラム12はヘルスケア向けのデータベースプログラムであり、交換標準ESはヘモグロビン検査を受けた患者に関する所望のデータにアクセスするように設計されたものであると想定する。
図5の
図40のデータプロファイルは、データプロファイルのフィンガープリントを定めるための、さまざまな患者記録に対するヘモグロビン値に対する(verses)、検査されたサンプル数を示している。
【0074】
図40のX軸には、さまざまな患者に対するヘモグロビン検査結果の検査値が示されている。Y軸には、X軸において特定された各々の値に対応するヘモグロビンサンプルの数が挙げられている。検査サンプルに対する値の総数は715,511であった。その結果が、データの分布パターンを示す特徴的な曲線40である。よってこのパターンは、ヘモグロビン臨床検査の結果に対するデータプロファイルであり、交換標準データプロファイルとして用いられてもよい。さまざまな実施形態に従って用いられ得る多くの異なる型および種類のデータプロファイルが存在してもよいことが理解されるべきである。データプロファイルの例は、心電図(ECG:electro cardiograms)、画像、ヒストグラム、および多くのその他のものを限定なしに含んでもよい。ここで
図6を参照すると、
図3の方法のステップ41に対する好ましい実施形態によると、従来の畳み込みニューラルネットワーク(CNN:Convolutional Neural Network)42が用いられてもよい。CNNは、データ曲線の不変表現(固有形状)を捕捉するようにトレーニングされてもよい。トレーニング済みのCNNは、2つのデータ曲線間の整合性スコアを計算するためにも用いられてもよい。
図6に示されるヒストグラム曲線40の本例において、CNNは最初にデータ曲線40の固有形状を捕捉するようにトレーニングされ、加えて交換標準としての曲線40に基づいて2つの曲線間の所望の整合性スコアを計算するようにトレーニングされる。次いで、プログラム12からのP-DATAおよび交換標準ES-DATAの両方が、処理の目的のためにCNNに流される。整合性判定の結果は、図示のように「yes」または「no」のいずれかであってもよい。
【0075】
前述の図面および特定の実施形態の詳細な説明に鑑みて、開示される実施形態およびその他の実施形態は、プログラムがこれまで未知だったデータを有し得るという事実にもかかわらず、異なるプログラムの中および間のプログラム相互運用性を達成するための新規の技術に関するものであることが当業者に明らかになるだろう。少なくとも部分的に、そのプログラムが所望のデータを含むか否かを学習することによって、所望の相互運用性を達成することを助けるためのアダプタが作成されてもよい。
【0076】
実施形態による方法およびシステムは、相互運用性をプログラミングするための一般化されたプログラムを可能にする。この方法およびシステムは、プログラムとの2方向通信のための所与の交換標準を用いるために、自動または実質的に自動の変換アダプタを使用する。アダプタが交換標準を使用するために、ディスカバリマネージャはプログラムのデータ通信構造および/またはフォーマットを学習してもよく、かつプログラムからのデータ意味情報を学習してもよい。アダプタクリエータは、プログラムのデータ通信構造およびデータ意味を交換標準に転換する変換を導出してもよい。この変換をアダプタが用いて、同様にその所与の交換標準を使用する任意のアダプタおよび/またはプログラムとの2方向通信を可能にすることで相互運用性を達成してもよい。
【0077】
上記の例を参照して本発明を説明したが、本明細書において開示される実施形態の真の趣旨および範囲内で多くの修正形および変形が予期されることが理解されるだろう。前述の説明および添付の図面において提供される教示の利益を有する本発明に関連する技術分野の当業者には、多くの修正形およびその他の実施形態が考えられるであろう。したがって、本発明は本明細書において開示される特定の実施形態またはその修正形にいかなるやり方でも限定されず、その修正形およびその他の実施形態は添付の請求項の範囲に含まれることが意図および予期されていることが理解されるべきである。本明細書においては特定の用語が使用されているが、それらの用語は一般的な説明の意味のみで用いられており、限定の目的では用いられていない。