(57)【要約】【課題】通信ネットワーク内の多様なプラットフォーム間での対話（インタラクション）を促進するフレームワークを提供する。【解決手段】ビジネスをカストマーや供給業者や商業パートナーにつなぐためのインフラを提供する。本発明のインフラストラクチャの下では、複数の会社は相互に、自己定義のマシン読取り可能なドキュメント（例えば、ＸＭＬ系のドキュメント）を用いて情報及びサービスを交換する。交換されるべきドキュメントを記述するドキュメント（ＢＩＤ）が、インターネット上で送られ、あるいは、ネットワークのメンバーに通信される。ビジネスインタフェース定義（ＢＴＤ）は、潜在的な商業パートナーに、会社が提供するサービスとそのサービスに通信する時に使用するためのドキュメントとを告げる。従って、代表的なビジネスインタフェース定義によって、カストマーは購買オーダを提出することによってオーダを行うことができる。【選択図】図１
2008084328.tif 000002
【特許請求の範囲】
【請求項１】
トランザクション（ｔｒａｎｓａｃｔｉｏｎ）に関連する処理を実行する複数のノード（ｎｏｄｅｓ）を含むネットワークにおけるノード間のトランザクションのためのインターフェース（ｉｎｔｅｒｆａｃｅ）であって、
入力ドキュメント（ｄｏｃｕｍｅｎｔ）の定義及び出力ドキュメントの定義を供給する翻訳情報を含む、ネットーワークにおける少なくとも一つのノードによってアクセス可能なメモリに記録されたトランザクション処理へのインターフェースの機械可読仕様（ｍａｃｈｉｎｅ  ｒｅａｄａｂｌｅ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）であり、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の記述と、及び前記記録装置の組に対する論理構造を具備する前記仕様を具備することを特徴とするインターフェース。
【請求項２】
前記翻訳情報は、前記入力及び出力ドキュメントの定義における少なくとも一つの論理構造に対するデータ・タイプ（ｄａｔａ  ｔｙｐｅ）仕様を含むことを特徴とする請求項１に記載のインターフェース。
【請求項３】
前記翻訳情報は、前記入力及び出力ドキュメントの定義における特定の論理構造に対する予め決められた組の記録装置を、リスト（ｌｉｓｔ）の個別のエントリ（ｅｎｔｒｉｅｓ）にマッピング（ｍａｐｐｉｎｇ）する少なくとも一つのデータ構造を含むことを特徴とする請求項１に記載のインターフェース。
【請求項４】
論理構造のライブラリと、及び論理構造に対する翻訳情報を記録する、ネットワークにおける少なくとも一つのノードによってアクセス可能であるメモリにおけるリポジトリを含むことを特徴とする請求項１に記載のインターフェース。
【請求項５】
前記機械可読仕様は、特定のトランザクションの識別子を記録するための論理構造と、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項１に記載のインターフェース。
【請求項６】
前記機械可読仕様は、インターフェースの識別子を記録するための、及び前記インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項１に記載のインターフェース。
【請求項７】
前記機械可読仕様は、特定のトランザクションの仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項６に記載のインターフェース。
【請求項８】
前記記録装置はパースされた（ｐａｒｓｅｄ）データを具備することを特徴とする請求項１に記載のインターフェース。
【請求項９】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタ（ｔｅｘｔ  ｃｈａｒａｃｔｅｒ）をコード化するキャラクタ・データ（ｃｈａｒａｃｔｅｒ  ｄａｔａ）と；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項８に記載のインターフェース。
【請求項１０】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項９に記載のインターフェース。
【請求項１１】
前記入力及び出力ドキュメントの少なくとも一つの特定の論理構造によって識別される前記記録装置の組の少なくとも一つに対する前記翻訳情報は、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項８に記載のインターフェース。
【請求項１２】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項８に記載のインターフェース。
【請求項１３】
複数のトランザクションにおける使用のためのドキュメント・タイプのネットワークにおいて、少なくとも一つのノードによってアクセス可能であるメモリに記録されたレポジトリを含み、及び前記入力及び出力ドキュメントの一つの定義は、前記レポジトリにおけるドキュメント・タイプへの参照を含むことを特徴とする請求項１に記載のインターフェース。
【請求項１４】
ドキュメント・タイプの前記レポジトリは、ネットワークにおける参加者処理（ｐａｒｔｉｃｉｐａｎｔ  ｐｒｏｃｅｓｓｅｓ）を識別するためのドキュメント・タイプを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項１に記載のインターフェース。
【請求項１６】
翻訳情報を含む前記機械可読データ構造は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義に従って編成されたドキュメントを具備することを特徴とする請求項１に記載のインターフェース。
【請求項１７】
ネットワーク・インターフェースと、及びトランザクション処理アーキテクチャに従って、トランザクションのトランザクション処理を実行するデータ処理リソースを含むシステム上で実行されるトランザクションに対する参加者インターフェース（ｐａｒｔｉｃｉｐａｎｔ  ｉｎｔｅｒｆａｃｅ）を設定するための装置であって：
前記システムによって実行され、前記システムによってアクセス可能な媒体に記録され、特定のトランザクションにおける参加者に対する参加者インターフェースの定義を構築するためのツールを供給する命令のプログラムであって、前記参加者インターフェースの定義は、前記参加者に対する入力ドキュメントの定義と、及び前記参加者に対する出力ドキュメントの定義とを含み、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の機械可読記述と、及び前記記録装置の組に対する論理構造とを具備する前記プログラムと；及び
前記システムによって実行可能であり、前記システムによってアクセス可能な媒体に記録され、前記記録装置の組に対応するデータ構造と、及び前記トランザクション処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造とをコンパイルするために、前記入力ドキュメントを、前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令をコンパイルするために、及び前記トランザクション処理の出力を、前記記録装置の組と及び前記出力ドキュメントの論理構造に翻訳するために、前記システムによって実行可能な命令をコンパイルするために、前記入力及び出力ドキュメントの定義に応答するプログラムとを具備することを特徴とする装置。
【請求項１８】
参加者インターフェースの定義を構築するための前記ツールは、レポジトリからの前記定義のエレメント（ｅｌｅｍｅｎｔ）にアクセスするために前記システムによって実行可能である命令を含み、前記レポジトリは、論理構造のライブラリと、及びインターフェース記述を構築するために使用される論理構造に対する翻訳情報とを記録することを特徴とする請求項１７に記載の装置。
【請求項１９】
前記レポジトリは、論理構造を具備するドキュメントの定義を記録することを特徴とする請求項１８に記載の装置。
【請求項２０】
参加者インターフェースの定義を構築するための前記ツールは、
相補トランザクションに対する他の参加者インターフェースの定義にアクセスするためであり、前記アクセスされた定義は、前記相補トランザクションに対する入力ドキュメントの定義と、及び前記相補トランザクションに対する出力ドキュメントの定義を含む前記アクセスのために；及び
構築されている前記インターフェースの入力ドキュメントの定義のように、前記相補トランザクションの前記出力ドキュメントの定義を含むことによって、前記参加者インターフェースの定義を設定するために、前記システムによって実行可能な命令を含むことを特徴とする請求項１７に記載の装置。
【請求項２１】
参加者インターフェースの定義を構築するための前記ツールは、
構築されているインターフェースの前記出力ドキュメントの定義のように、前記相補トランザクションの入力ドキュメントの定義を含むために、
前記システムによって実行可能である命令を含むことを特徴とする請求項２０に記載の装置。
【請求項２２】
参加者インターフェースの定義を構築するための前記ツールは、特定のトランザクションの識別子を記録するための論理構造を含む参加者インターフェース・ドキュメントの定義に従ったドキュメントと、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つとを構築するために、前記システムによって実行可能である命令を含むことを特徴とする請求項１７に記載の装置。
【請求項２３】
参加者インターフェースの定義を構築するための前記ツールは、前記参加者インターフェースの識別子を記録するため、及び前記参加者インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含む参加者インターフェース・ドキュメントの定義に従ったドキュメントを構築するために、前記システムによって実行可能な命令を含むことを特徴とする請求項１７に記載の装置。
【請求項２４】
参加者インターフェース・ドキュメントの定義に従った前記ドキュメントは、特定のトランザクションの機械可読仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項２３に記載の装置。
【請求項２５】
前記記録装置は、パースされたデータを具備することを特徴とする請求項１７に記載の装置。
【請求項２６】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタ（ｔｅｘｔ  ｃｈａｒａｃｔｅｒ）をコード化するキャラクタ・データ（ｃｈａｒａｃｔｅｒ  ｄａｔａ）と；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項２５に記載の装置。
【請求項２７】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項２６に記載の装置。
【請求項２８】
前記仕様は、前記入力及び出力ドキュメントのうち少なくとも一つの前記論理構造によって識別される前記記録装置の組のうち少なくとも一つに対する翻訳情報を含み、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項２５に記載の装置。
【請求項２９】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項２５に記載の装置。
【請求項３０】
前記記録装置の組に対応するデータ構造及び前記入力及び出力ドキュメントの論理構造は、可変トランザクション処理アーキテクチャに従った変数及び方法を含むプログラミング・オブジェクトを含むことを特徴とする請求項１７に記載の装置。
【請求項３１】
前記トランザクション処理の前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を具備することを特徴とする請求項１７に記載の装置。
【請求項３２】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項１７に記載の装置。
【請求項３３】
前記入力及び出力ドキュメントの一つの前記定義は、レポジトリにおけるドキュメント・タイプへの参照を含むことを特徴とする請求項１９に記載の装置。
【請求項３４】
前記レポジトリは、トランザクションの製品サブジェクトの測定を特定する翻訳情報を含むことを特徴とする請求項１８に記載の装置。
【請求項３５】
前記レポジトリは、トランザクションの製品サブジェクトのコスト（ｃｏｓｔ）を特定する翻訳情報を含むことを特徴とする請求項１８に記載の装置。
【請求項３６】
前記レポジトリは、トランザクションの製品サブジェクトの特性を特定する翻訳情報を含むことを特徴とする請求項１８に記載の装置。
【請求項３７】
前記レポジトリは、トランザクションの金融ターム（ｆｉｎａｎｃｉａｌ  ｔｅｒｍｓ）を特定する翻訳情報を含むことを特徴とする請求項１８に記載の装置。
【請求項３８】
前記レポジトリは、トランザクションの製品サブジェクトに対する出荷（ｓｈｉｐｍｅｎｔ）のタームを特定する翻訳情報を含むことを特徴とする請求項１８に記載の装置。
【請求項３９】
システム上で実行されるトランザクションに対する参加者インターフェースを設定するための装置であって：
命令のデータ及びプログラムを記録するメモリと；
命令の前記プログラムを実行するメモリに接続されたデータ・プロセッサであって；前記命令のプログラムは、
特定のトランザクションにおける参加者のための参加者インターフェースの定義を構築するためのツールであって、参加者インターフェースの前記定義は、前記参加者に対する入力ドキュメントの定義及び前記参加者に対する出力ドキュメントの定義を含み、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の機械可読記述と、及び前記記録装置の組に対する論理構造とを具備する前記ツールと；及び
前記入力及び出力ドキュメントの定義に応答し、前記記録装置の組と及び前  記トランザクション処理アーキテクチャに従った前記入力及び出力ドキュメン  トの論理構造とに対応したデータ構造をコンパイルするため、前記入力ドキュ  メントを前記対応するデータ構造に翻訳するために、前記システムによって実  行可能な命令をコンパイルし、及び前記トランザクション処理の出力を、前記  記録装置の組と及び前記出力ドキュメントの論理構造とに翻訳するために、前  記システムによって実行可能な命令をコンパイルするためのコンパイラとを含  む前記データ・プロセッサとを具備することを特徴とする装置。
【請求項４０】
前記データ・プロセッサによってアクセス可能なメモリに記録されたレポジトリを含み、参加者インターフェースの定義を構築するための前記ツールは、レポジトリからの前記定義のエレメントにアクセスするために前記システムによって実行可能である命令を含み、前記レポジトリは、論理構造のライブラリと、及びインターフェース記述を構築するために使用される論理構造に対する翻訳情報とを記録することを特徴とする請求項３９に記載の装置。
【請求項４１】
前記レポジトリは、論理構造を具備するドキュメントの定義を記録することを特徴とする請求項４０に記載の装置。
【請求項４２】
参加者インターフェースの定義を構築するための前記ツールは、
相補トランザクションに対する他の参加者インターフェースの定義にアクセスするためであり、前記アクセスされた定義は、前記相補トランザクションに対する入力ドキュメントの定義と、及び前記相補トランザクションに対する出力ドキュメントの定義を含む前記アクセスのために；及び
構築されている前記インターフェースの入力ドキュメントの定義のように、前記相補トランザクションの前記出力ドキュメントの定義を含むことによって、前記参加者インターフェースの定義を設定するために、前記システムによって実行可能な命令を含むことを特徴とする請求項３９に記載の装置。
【請求項４３】
参加者インターフェースの定義を構築するための前記ツールは、
構築されているインターフェースの前記出力ドキュメントの定義のように、前記相補トランザクションの入力ドキュメントの定義を含むために、前記システムによって実行可能である命令を含むことを特徴とする請求項４２に記載の装置。
【請求項４４】
参加者インターフェースの定義を構築するための前記ツールは、特定のトランザクションの識別子を記録するための論理構造を含む参加者インターフェース・ドキュメントの定義に従ったドキュメントと、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つとを構築するために、前記システムによって実行可能である命令を含むことを特徴とする請求項３９に記載の装置。
【請求項４５】
参加者インターフェースの定義を構築するための前記ツールは、前記参加者インターフェースの識別子を記録するため、及び前記参加者インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含む参加者インターフェース・ドキュメントの定義に従ったドキュメントを構築するために、前記システムによって実行可能な命令を含むことを特徴とする請求項３９に記載の装置。
【請求項４６】
参加者インターフェース・ドキュメントの定義に従った前記ドキュメントは、特定のトランザクションの機械可読仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項４５に記載の装置。
【請求項４７】
前記記録装置は、パースされたデータを具備することを特徴とする請求項２５に記載の装置。
【請求項４８】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタをコード化するキャラクタ・データと；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項４７に記載の装置。
【請求項４９】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項４８に記載の装置。
【請求項５０】
前記仕様は、前記入力及び出力ドキュメントのうち少なくとも一つの前記論理構造によって識別される前記記録装置の組のうち少なくとも一つに対する翻訳情報を含み、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項４７に記載の装置。
【請求項５１】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項４７に記載の装置。
【請求項５２】
前記記録装置の組に対応するデータ構造及び前記入力及び出力ドキュメントの論理構造は、可変トランザクション処理アーキテクチャに従った変数及び方法を含むプログラミング・オブジェクトを含むことを特徴とする請求項３９に記載の装置。
【請求項５３】
前記トランザクション処理の前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を具備することを特徴とする請求項３９に記載の装置。
【請求項５４】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項３９に記載の装置。
【請求項５５】
前記入力及び出力ドキュメントの一つの前記定義は、レポジトリにおけるドキュメント・タイプへの参照を含むことを特徴とする請求項４１に記載の装置。
【請求項５６】
前記レポジトリは、トランザクションの製品サブジェクトの測定を特定する翻訳情報を含むことを特徴とする請求項４０に記載の装置。
【請求項５７】
前記レポジトリは、トランザクションの製品サブジェクトのコストを特定する翻訳情報を含むことを特徴とする請求項４０に記載の装置。
【請求項５８】
前記レポジトリは、トランザクションの製品サブジェクトの特性を特定する翻訳情報を含むことを特徴とする請求項４０に記載の装置。
【請求項５９】
前記レポジトリは、トランザクションの金融タームを特定する翻訳情報を含むことを特徴とする請求項４０に記載の装置。
【請求項６０】
前記レポジトリは、トランザクションの製品サブジェクトに対する出荷のタームを特定する翻訳情報を含むことを特徴とする請求項４０に記載の装置。
【請求項６１】
ネットワークにおいて商業トランザクションをプログラミングするための方法であって：
前記トランザクションにおける処理を実行するためのリソースを含むネットワークにおけるノードに対する入力ドキュメントの機械可読定義と、及び前記ノードに対する出力ドキュメントの機械可読定義を定義する段階であって、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の記述と及び前記記録装置の組に対する論理構造とを具備する前記段階と；及び
前記論理構造に対する翻訳情報を前記ノードに供給する段階とを具備することを特徴とする方法。
【請求項６２】
前記翻訳情報は、前記入力及び出力ドキュメントの定義における少なくとも一つの論理構造に対するデータ・タイプ仕様を含むことを特徴とする請求項６１に記載の方法。
【請求項６３】
前記翻訳情報は、前記入力及び出力ドキュメントの定義における特定の論理構造に対する予め決められた組の記録装置を、リストの個別のエントリにマッピングする少なくとも一つのデータ構造を含むことを特徴とする請求項前記翻訳情報は、前記入力及び出力ドキュメントの定義における少なくとも一つの論理構造に対するデータ・タイプの仕様を含むことを特徴とする請求項６１に記載の方法。
【請求項６４】
翻訳情報を供給する前記段階は、論理構造のライブラリと、及び論理構造に対する翻訳情報を記録する、ネットワークにおける少なくとも一つのノードによってアクセス可能であるメモリにおけるリポジトリを供給する段階を含むことを特徴とする請求項６１に記載の方法。
【請求項６５】
特定のトランザクションの識別子を記録するための論理構造と、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むインターフェース・ドキュメントの定義に従ったドキュメントを含むインターフェースの機械可読仕様を定義する段階を含むことを特徴とする請求項６１に記載の方法。
【請求項６６】
前記記録装置はパースされたデータを具備することを特徴とする請求項６１に記載の方法。
【請求項６７】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタをコード化するキャラクタ・データと；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項６６に記載の方法。
【請求項６８】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項６７に記載の方法。
【請求項６９】
前記入力及び出力ドキュメントの少なくとも一つの特定の論理構造によって識別される前記記録装置の組の少なくとも一つに対する前記翻訳情報は、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項６７に記載の方法。
【請求項７０】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項６６に記載の方法。
【請求項７１】
前記組の記録装置の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項６７に記載の方法。
【請求項７２】
前記入力及び出力ドキュメントの少なくとも一つの特定の論理構造によって識別される前記組の記録装置の少なくとも一つに対する前記翻訳情報は、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項６７に記載の方法。
【請求項７３】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項６６に記載の方法。
【請求項７４】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項６１に記載の方法。
【請求項７５】
前記入力ドキュメントの定義において、論理構造に応答してイベント信号（ｅｖｅｎｔ  ｓｉｇｎａｌ）を生成するためのパーサ（ｐａｒｓｅｒ）を供給する段階と；及び
前記処理を実行するために、前記イベント信号に応答するイベント・リスナ・プログラム（ｅｖｅｎｔ  ｌｉｓｔｅｎｅｒ  ｐｒｏｇｒａｍｓ）を供給する段階とを含むことを特徴とする請求項６１に記載の方法。
【請求項７６】
トランザクションに関連する処理を実行する複数のノードを含むネットワークにおけるノード間のトランザクションを実行するための方法であって：
トランザクションに対するインターフェースの機械可読仕様を記録する段階であって、前記仕様は入力ドキュメントの定義及び出力ドキュメントの定義を含み、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の記述と及び前記記録装置の組に対する論理構造とを具備する前記段階と；
通信ネットワークを通してドキュメントを具備するデータを受信する段階と；  入力ドキュメントを識別するための前記仕様に従って前記ドキュメントをパースする段階と；
機械可読形式での前記入力ドキュメントの少なくとも一部分を、出力を生成するトランザクション処理に供給する段階と；
前記仕様に基づいて、出力ドキュメントの前記定義に従った前記出力を具備する出力ドキュメントを形成する段階と；及び
前記通信ネットワーク上で前記出力ドキュメントを転送する段階とを具備することを特徴とする方法。
【請求項７７】
前記トランザクションに対するネットワークにおける他のノードに供給される相補インターフェースの仕様にアクセスする段階であって、前記アクセスされた仕様は、前記相補インターフェースに対する入力ドキュメントの定義と、及び前記相補インターフェースに対する出力ドキュメントの定義とを含む前記段階と；及び
前記記録された仕様におけるインターフェースの前記入力ドキュメントの前記定義における前記相補インターフェースの前記出力ドキュメントの前記定義の少なくとも一部を含むことによって、前記インターフェースの前記記録された仕様を設定する段階とを含むことを特徴とする請求項７３に記載の方法。
【請求項７８】
ネットワークにおいて前記相補インターフェースを見つける段階を含むことを特徴とする請求項７４に記載の方法。
【請求項７９】
前記記録された仕様を設定する前記段階は、レポジトリからの機械可読仕様のエレメントにアクセスする段階であって、前記レポジトリは、論理構造のライブラリと、論理構造に対する模式図マップ（ｓｃｈｅｍａｔｉｃ  ｍａｐ）と、及びインターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義とを記録する前記段階を含むことを特徴とする請求項７４に記載の方法。
【請求項８０】
前記記録された仕様におけるインターフェースの前記出力ドキュメントの前記定義における前記相補インターフェースの前記入力ドキュメントの前記定義の少なくとも一部を含むことによって、前記インターフェースの前記記録された仕様を設定する段階とを含むことを特徴とする請求項７４に記載の方法。
【請求項８１】
通信ネットワークを通した前記仕様へのアクセスを、ネットーワークにおける他のノードに供給する段階を含むことを特徴とする請求項７３に記載の方法。
【請求項８２】
前記インターフェースの仕様をネットワークにおける他のノードに送信する段階を含み、前記ネットワークにおいては、前記仕様へのアクセスはネットワークにおける他のノードに対して供給される前記段階を含むことを特徴とする請求項７３に記載の方法。
【請求項８３】
前記機械可読仕様は、特定のトランザクションの識別子を記録するための論理構造と、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項７３に記載の方法。
【請求項８４】
前記機械可読仕様は、インターフェースの識別子を記録するための、及び前記インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項７３に記載の方法。
【請求項８５】
前記機械可読仕様は、特定のトランザクションの仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項８１に記載の方法。
【請求項８６】
前記記録装置はパースされた（ｐａｒｓｅｄ）データを具備することを特徴とする請求項７３に記載の方法。
【請求項８７】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタをコード化するキャラクタ・データと；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項８３に記載の方法。
【請求項８８】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項８４に記載の方法。
【請求項８９】
前記仕様は、前記入力及び出力ドキュメントのうち少なくとも一つの論理構造によって識別される前記記録装置の組のうち少なくとも一つに対する前記翻訳情報を含み、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項８３に記載の方法。
【請求項９０】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項８３に記載の方法。
【請求項９１】
前記トランザクション処理は、可変トランザクション処理アーキテクチャを有し、及び前記入力ドキュメントの少なくとも一部分を、前記トランザクション処理の前記可変トランザクション処理アーキテクチャに従って読み取り可能な形式に翻訳する段階を含むことを特徴とする請求項７３に記載の方法。
【請求項９２】
前記翻訳段階は、前記トランザクション処理の前記可変トランザクション処理アーキテクチャに従った変数及び方法を含むプログラミング・オブジェクトを生成する段階を含むことを特徴とする請求項８８に記載の方法。
【請求項９３】
前記トランザクション処理の前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を具備することを特徴とする請求項８８に記載の方法。
【請求項９４】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項７３に記載の方法。
【請求項９５】
複数のトランザクションにおける使用のためのドキュメント・タイプのレポジトリを供給する段階を含み、及び前記入力及び出力ドキュメントの一つの前記定義は、前記レポジトリにおけるドキュメント・タイプへの参照を含むことを特徴とする請求項７３に記載の方法。
【請求項９６】
ドキュメント・タイプの前記レポジトリは、ネットワークにおける参加者処理を識別するためのドキュメント・タイプを含むことを特徴とする請求項９２に記載の方法。
【請求項９７】
論理構造に対する翻訳情報のレポジトリを供給する段階を含み、トランザクションのパラメータを識別する翻訳情報を含むことを特徴とする請求項９２に記載の方法。
【請求項９８】
前記トランザクション処理は、可変トランザクション処理アーキテクチャを有し、及び：
相補インターフェースの仕様にアクセスする段階であって、前記アクセスされた仕様は前記相補インターフェースに対する入力ドキュメントの定義と及び前記相補インターフェースに対する出力ドキュメントの定義とを含む前記段階と；
記録された仕様におけるインターフェースの前記入力ドキュメントの定義のように、前記相補インターフェースの前記出力ドキュメントの定義を含むことによって、インターフェースの記録された仕様を設定する段階と；及び
前記入力及び出力ドキュメントの定義に応答して、記録装置の組に対応したデータ構造及び前記トランザクション処理の前記トランザクション処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造と、前記入力ドキュメントを前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令と、及び前記トランザクション処理の出力を前記出力ドキュメントの定義に従った形式に翻訳するために、前記システムによって実行可能な命令とをコンパイルする段階とを含むことを特徴とする請求項７３に記載の方法。
【請求項９９】
記録された仕様におけるインターフェースの前記出力ドキュメントの定義のように、前記相補インターフェースの前記入力ドキュメントの定義を含むことによって、インターフェースの記録された仕様を設定する段階を含むことを特徴とする請求項９５に記載の方法。
【請求項１００】
前記トランザクション処理は、可変トランザクション処理アーキテクチャを有し、及び前記記録された仕様を設定する段階は、レポジトリからの前記機械可読仕様のエレメントにアクセスする段階を含み、前記レポジトリは論理構造のライブラリと、論理構造に対する模式図マップと、及びインターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義とを記録し、及び；
前記入力及び出力ドキュメントの定義に応答して、記録装置の組に対応したデータ構造及び前記トランザクション処理の前記トランザクション処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造と、前記入力ドキュメントを前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令と、及び前記トランザクション処理の出力を前記出力ドキュメントの定義に従った形式に翻訳するために、前記システムによって実行可能な命令とをコンパイルする段階とを含むことを特徴とする請求項７３に記載の方法。
【請求項１０１】
トランザクションに関連する処理を実行する複数のノードを含むネットワークにおけるノード間のトランザクションを管理するための装置であって：
ネットワーク・インターフェースと；
命令のデータ及びプログラムを記録するメモリであって、トランザクションに対するインターフェースの機械可読仕様を含み、前記仕様は入力ドキュメントの定義と及び出力ドキュメントの定義とを含み、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の記述と及び前記記録装置の組に対する論理構造とを具備する前記メモリと；
前記メモリと及び命令のプログラムを実行する前記ネットワーク・インターフェースとに接続されたデータ・プロセッサであって；前記命令のプログラムは、    ネットワーク・インターフェースを通してドキュメントを具備するデータを  受信するための論理と；
入力ドキュメントを識別するための前記仕様に従って、前記ドキュメントを  パースするための論理と；
機械可読形式での前記入力ドキュメントの少なくとも一部分を、出力を生成  するトランザクション処理に供給するための論理と；
前記仕様に基づいて、出力ドキュメントの定義に従って、前記出力を具備す  る出力ドキュメントを形成するための論理と；及び
ネットワーク・インターフェース上で前記出力ドキュメントを転送するため  の論理とを含む前記データ・プロセッサとを具備することを特徴とする装置。
【請求項１０２】
相補インターフェースの仕様にアクセスするための論理であって、前記アクセスされた仕様は前記相補インターフェースに対する入力ドキュメントの定義と及び前記相補インターフェースに対する出力ドキュメントの定義とを含む前記論理と；及び
記録された仕様における前記インターフェースの前記入力ドキュメントの定義のように、前記相補インターフェースの前記出力ドキュメントの定義を含むことによって、前記インターフェースの前記記録された仕様を設定するための論理とを含むことを特徴とする請求項９８に記載の装置。
【請求項１０３】
前記記録された仕様を設定するための前記論理は、レポジトリからの前記機械可読仕様のエレメントにアクセスするための論理を含み、前記レポジトリは論理構造のライブラリと、論理構造に対する模式図マップと、及びインターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義とを記録することを特徴とする請求項９９に記載の装置。
【請求項１０４】
記録された仕様における前記インターフェースの前記出力ドキュメントの定義のように、前記相補インターフェースの前記入力ドキュメントの定義を含むことによって、前記インターフェースの前記記録された仕様を設定するための論理を含むことを特徴とする請求項９９に記載の装置。
【請求項１０５】
通信ネットワークを通した前記仕様へのアクセスを、ネットーワークにおける他のノードに供給する論理を含むことを特徴とする請求項９８に記載の装置。
【請求項１０６】
前記インターフェースの仕様をネットワークにおける他のノードに送信するための論理を含み、前記ネットワークにおいては、前記仕様へのアクセスはネットワークにおける他のノードに対して供給される前記論理を含むことを特徴とする請求項９８に記載の装置。
【請求項１０７】
前記機械可読仕様は、特定のトランザクションの識別子を記録するための論理構造と、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項９８に記載の装置。
【請求項１０８】
前記機械可読仕様は、インターフェースの識別子を記録するための、及び前記インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項９８に記載の装置。
【請求項１０９】
前記機械可読仕様は、特定のトランザクションの仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項１０５に記載の装置。
【請求項１１０】
前記記録装置はパースされたデータを具備することを特徴とする請求項９８に記載の装置。
【請求項１１１】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタをコード化するキャラクタ・データと；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項１０７に記載の装置。
【請求項１１２】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード
化することを特徴とする請求項１０８に記載の装置。
【請求項１１３】
前記仕様は、前記入力及び出力ドキュメントのうち少なくとも一つの論理構造によって識別される前記記録装置の組のうち少なくとも一つに対する前記翻訳情報を含み、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項１０７に記載の装置。
【請求項１１４】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項１０７に記載の装置。
【請求項１１５】
前記トランザクション処理は、可変トランザクション処理アーキテクチャを有し、及び前記入力ドキュメントの少なくとも一部分を、前記トランザクション処理の前記可変トランザクション処理アーキテクチャに従って読み取り可能な形式に翻訳する論理を含むことを特徴とする請求項９８に記載の装置。
【請求項１１６】
前記翻訳するための論理は、前記トランザクション処理の前記可変トランザクション処理アーキテクチャに従った変数及び方法を含むプログラミング・オブジェクトを生成する論理を含むことを特徴とする請求項１１２に記載の装置。
【請求項１１７】
前記トランザクション処理の前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を含むことを特徴とする請求項１１２に記載の装置。
【請求項１１８】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項９８に記載の装置。
【請求項１１９】
複数のトランザクションにおける使用のためのドキュメント・タイプのレポジトリを記録するプロセッサによってアクセス可能なメモリを含み、及び前記入力及び出力ドキュメントの一つの前記定義は、前記レポジトリにおけるドキュメント・タイプへの参照を含むことを特徴とする請求項９８に記載の装置。
【請求項１２０】
ドキュメント・タイプの前記レポジトリは、ネットワークにおける参加者処理を識別するためのドキュメント・タイプを含むことを特徴とする請求項１１６に記載の装置。
【請求項１２１】
論理構造に対する翻訳情報のレポジトリを供給する段階を含み、トランザクションのパラメータを識別する翻訳情報を含むことを特徴とする請求項１１６に記載の装置。
【請求項１２２】
前記トランザクション処理は、可変トランザクション処理アーキテクチャを有し、及び：
相補インターフェースの仕様にアクセスするための論理であって、前記アクセスされた仕様は前記相補インターフェースに対する入力ドキュメントの定義と及び前記相補インターフェースに対する出力ドキュメントの定義とを含む前記論理と；
記録された仕様におけるインターフェースの前記入力ドキュメントの定義のように、前記相補インターフェースの前記出力ドキュメントの定義を含むことによって、インターフェースの記録された仕様を設定する論理と；及び
前記入力及び出力ドキュメントの定義に応答して、記録装置の組に対応したデータ構造及び前記トランザクション処理の前記トランザクション処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造とをコンパイルするためと、前記入力ドキュメントを前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令をコンパイルするためと、及び前記トランザクション処理の出力を前記出力ドキュメントの定義に従った形式に翻訳するために、前記システムによって実行可能な命令をコンパイルするための論理を含むことを特徴とする請求項９８に記載の装置。
【請求項１２３】
記録された仕様におけるインターフェースの前記出力ドキュメントの定義のように、前記相補インターフェースの前記入力ドキュメントの定義を含むことによって、インターフェースの記録された仕様を設定するための論理を含むことを特徴とする請求項１１９に記載の装置。
【請求項１２４】
前記トランザクション処理は、可変トランザクション処理アーキテクチャを有し、及びレポジトリからの前記機械可読仕様のエレメントにアクセスすることによって、前記記録された仕様を設定するための論理を含み、前記レポジトリは論理構造のライブラリと、論理構造に対する模式図マップと、及びインターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義とを記録し、及び；
前記入力及び出力ドキュメントの定義に応答して、記録装置の組に対応したデータ構造及び前記トランザクション処理の前記トランザクション処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造とをコンパイルするためと、前記入力ドキュメントを前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令をコンパイルするためと、及び前記トランザクション処理の出力を前記出力ドキュメントの定義に従った形式に翻訳するために、前記システムによって実行可能な命令をコンパイルする論理を含むことを特徴とする請求項９８に記載の装置。
【請求項１２５】
トランザクションに関連する処理を実行する複数のノードを含むネットワークにおけるノード間のトランザクションを管理するための装置であって：
複数の参加者インターフェースの機械可読仕様を記録する段階であって、前記参加者インターフェースはトランザクションを識別し、前記個別のトランザクションは入力ドキュメントの定義及び出力ドキュメントの定義によって識別され、前記入力及び出力ドキュメントの前記定義は、記録装置の組の個別の記述と及び前記記録装置の組に対する論理構造とを具備する前記段階と；
通信ネットワークを通してドキュメントを具備するデータを受信する段階と；  入力ドキュメントを識別するための前記仕様と、及び前記識別された入力ドキュメントを受信する一つ以上のトランザクションに従って、前記ドキュメントをパースする段階と；
機械可読形式での前記入力ドキュメントの少なくとも一部分を、前記一つ以上の識別されたトランザクションと関連したトランザクション処理に供給する段階とを具備することを特徴とする方法。
【請求項１２６】
論理構造のライブラリと、論理構造に対する模式図マップと、及び参加者インターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義とを記録するレポジトリを供給する段階を含むことを特徴とする請求項１２２に記載の方法。
【請求項１２７】
通信ネットワークを通した前記レポジトリへのアクセスを、ネットーワークにおける他のノードに供給する段階を含むことを特徴とする請求項１２３に記載の方法。
【請求項１２８】
前記機械可読仕様は、特定のトランザクションの識別子を記録するための論理構造と、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つとを含む参加者インターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項１２２に記載の方法。
【請求項１２９】
前記機械可読仕様は、参加者インターフェースの識別子を記録するための、及び前記参加者インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項１２２に記載の方法。
【請求項１３０】
参加者インターフェース・ドキュメントの定義に従った前記ドキュメントは、特定のトランザクションの仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項１２６に記載の方法。
【請求項１３１】
前記記録装置はパースされたデータを具備することを特徴とする請求項１２２に記載の方法。
【請求項１３２】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタをコード化するキャラクタ・データと；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項１２８に記載の方法。
【請求項１３３】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項１０９に記載の方法。
【請求項１３４】
前記仕様は、前記入力及び出力ドキュメントのうち少なくとも一つの論理構造によって識別される前記記録装置の組のうち少なくとも一つに対する前記翻訳情報を含み、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項１３０に記載の方法。
【請求項１３５】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項１３０に記載の方法。
【請求項１３６】
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の識別されたトランザクションと関連するトランザクション処理に供給する段階は、処理アーキテクチャに従ってルーティング処理を実行する段階を含み、及び：
前記参加者インターフェースにおける前記入力及び出力ドキュメントの定義に応答して、記録装置の前記組に対応するデータ構造及び前記トランザクション処理の処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造と、及び前記入力ドキュメントを前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令とをコンパイルする段階を含むことを特徴とする請求項１２２に記載の方法。
【請求項１３７】
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の識別されたトランザクションと関連するトランザクション処理に供給する段階は、処理アーキテクチャに従ってルーティング処理を実行する段階と、及び前記入力ドキュメントの少なくとも一部分を、前記処理アーキテクチャに従って読み取り可能である形式に翻訳する段階を含むことを特徴とする請求項１２２に記載の方法。
【請求項１３８】
前記翻訳段階は、前記ルーティング処理の前記処理アーキテクチャに従った変数及び方法を含むプログラミング・オブジェクトを生成する段階を含むことを特徴とする請求項１３４に記載の方法。
【請求項１３９】
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の識別されたトランザクションと関連するトランザクション処理に供給する段階は、前記入力ドキュメントの前記部分を前記識別されたトランザクションにルーティングする段階を含むことを特徴とする請求項１２２に記載の方法。
【請求項１４０】
前記ルーティング段階は、通信ネットワーク上の前記入力ドキュメントを、前記識別されたトランザクションの一つを実行するノードに送信する段階を含むことを特徴とする請求項１３６に記載の方法。
【請求項１４１】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項１２２に記載の方法。
【請求項１４２】
参加者インターフェースの仕様は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義に従ってドキュメントの定義を具備することを特徴とする請求項１３８に記載の方法。
【請求項１４３】
前記レポジトリは複数のトランザクションにおける使用のための標準化されたドキュメント・タイプを含み、及び前記入力及び出力ドキュメントの一つの前記定義は、レポジトリにおける標準化されたドキュメント・タイプへの参照を含むことを特徴とする請求項１２２に記載の方法。
【請求項１４４】
前記レポジトリは、ネットワークにおける参加者処理を識別するための標準化されたドキュメント・タイプを含むことを特徴とする請求項１４０に記載の方法。
【請求項１４５】
論理構造に対する翻訳情報のレポジトリを供給する段階を含み、トランザクションのパラメータを識別する翻訳情報を含むことを特徴とする請求項１４０に記載の方法。
【請求項１４６】
前記トランザクション処理は、複数の可変トランザクション処理アーキテクチャの一つを各々有し、及び前記入力ドキュメントの少なくとも一部分を、前記個別のトランザクション処理の前記可変トランザクション処理アーキテクチャに従って読み取り可能な形式に翻訳する段階と、及び前記翻訳された部分を前記個別のトランザクション処理にルーティングする段階とを含むことを特徴とする請求項１２２に記載の方法。
【請求項１４７】
前記翻訳段階は、前記個別のトランザクション処理の可変トランザクション処理アーキテクチャに従って変数及び方法を含むプログラミング・オブジェクトを生成する段階を含むことを特徴とする請求項１４３に記載の方法。
【請求項１４８】
前記トランザクション処理の前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を具備することを特徴とする請求項１４４に記載の方法。
【請求項１４９】
トランザクションに関連する処理を実行する複数のノードを含むネットワークにおけるノード間のトランザクションを管理するための装置であって：
ネットワーク・インターフェースと；
命令のデータ及びプログラムを記録するメモリであって、複数の参加者インターフェースの機械可読仕様を含み、前記参加者インターフェースはトランザクションを識別し、前記個別のトランザクションは、入力ドキュメントの定義及び出力ドキュメントの定義によって識別され、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の記述と及び前記記録装置の組に対する論理構造とを具備する前記メモリと；
前記メモリと及び命令のプログラムを実行する前記ネットワーク・インターフェースとに接続されたデータ・プロセッサであって；前記命令のプログラムは、    ネットワーク・インターフェースを通してドキュメントを具備するデータを  受信するための論理と；
入力ドキュメントを識別するための仕様及び識別された入力ドキュメントを  受信する一つ以上のトランザクションに従って、前記ドキュメントをパースす  るための論理と；及び
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の  識別されたトランザクションと関連するトランザクション処理に供給するため  の論理とを含む前記データ・プロセッサとを具備することを特徴とする装置。
【請求項１５０】
論理構造のライブラリと、論理構造に対する模式図マップと及び参加者インターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義を記録する前記データ・プロセッサによってアクセス可能なメモリに記録されたレポジトリを含むことを特徴とする請求項１４６に記載の装置。
【請求項１５１】
論理構造のライブラリと、論理構造に対する模式図マップと及び参加者インターフェース記述を構築するために使用される論理構造を具備するドキュメントの定義を記録するネットワーク・インターフェースを通してメモリに記録されるレポジトリへアクセスするための論理を含むことを特徴とする請求項１４６に記載の装置。
【請求項１５２】
前記機械可読仕様は、特定のトランザクションの識別子を記録するための論理構造と、及び前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つとを含む参加者インターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項１４６に記載の装置。
【請求項１５３】
前記機械可読仕様は、参加者インターフェースの識別子を記録するための、及び前記参加者インターフェースによってサポートされる一組の一つ以上のトランザクションの仕様及び仕様への参照のうち少なくとも一つを記録するための論理構造を含むインターフェース・ドキュメントの定義に従ったドキュメントを含むことを特徴とする請求項１４６に記載の装置。
【請求項１５４】
参加者インターフェース・ドキュメントの定義に従った前記ドキュメントは、特定のトランザクションの仕様への参照を含み、及び前記特定のトランザクションの仕様は、前記特定のトランザクションに対する入力及び出力ドキュメントの定義及び定義への参照のうち少なくとも一つを記録するための論理構造を含むドキュメントを含むことを特徴とする請求項１５０に記載の装置。
【請求項１５５】
前記記録装置はパースされたデータを具備することを特徴とする請求項１４６に記載の装置。
【請求項１５６】
前記入力及び出力ドキュメントの少なくとも一つにおける前記パースされたデータは：
前記入力及び出力ドキュメントの一つにおけるテキスト・キャラクタをコード化するキャラクタ・データと；及び
記録装置の組を、前記入力及び出力ドキュメントの一つの論理構造に従って識別するマーク付けデータとを具備することを特徴とする請求項１５２に記載の装置。
【請求項１５７】
前記記録装置の組の少なくとも一つは、自然言語の単語を供給する複数のテキスト・キャラクタをコード化することを特徴とする請求項１５３に記載の装置。
【請求項１５８】
前記仕様は、前記入力及び出力ドキュメントのうち少なくとも一つの論理構造によって識別される前記記録装置の組のうち少なくとも一つに対する前記翻訳情報を含み、パースされたキャラクタの組に対する個別の定義をコード化することを特徴とする請求項１５４に記載の装置。
【請求項１５９】
前記記録装置は、パースされていないデータを具備することを特徴とする請求項１５４に記載の装置。
【請求項１６０】
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の識別されたトランザクションと関連するトランザクション処理に供給するための論理は、処理アーキテクチャに従ったルーティング処理を含み、及び：
前記参加者インターフェースにおける前記入力及び出力ドキュメントの定義に応答して、記録装置の前記組に対応するデータ構造及び前記トランザクション処理の処理アーキテクチャに従った前記入力及び出力ドキュメントの論理構造とをコンパイルするためと、及び前記入力ドキュメントを前記対応するデータ構造に翻訳するために、前記システムによって実行可能な命令とをコンパイルするためのコンパイラを含むことを特徴とする請求項１４６に記載の装置。
【請求項１６１】
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の識別されたトランザクションと関連するトランザクション処理に供給するための論理は、処理アーキテクチャに従ったルーティング処理を含み、及び：前記入力ドキュメントの少なくとも一部分を、前記処理アーキテクチャに従って読み取り可能である形式に翻訳するための論理を含むことを特徴とする請求項１４６に記載の装置。
【請求項１６２】
前記翻訳するための論理は、前記ルーティング処理の処理アーキテクチャに従った変数及び方法を含むプログラミング・オブジェクトを生成する段階を含むことを特徴とする請求項１５８に記載の装置。
【請求項１６３】
機械可読形式での前記入力ドキュメントの少なくとも一部分を、一つ以上の識別されたトランザクションと関連するトランザクション処理に供給するための論理は、前記入力ドキュメントの前記部分を前記識別されたトランザクションにルーティングするためのルータ（ｒｏｕｔｅｒ）を含むことを特徴とする請求項１４６に記載の装置。
【請求項１６４】
前記ルータは、ネットワーク・インターフェース上の前記入力ドキュメントを、前記識別されたトランザクションの一つを実行するノードに送信するための論理を含むことを特徴とする請求項１６０に記載の装置。
【請求項１６５】
前記入力及び出力ドキュメントの定義は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義を具備することを特徴とする請求項１４６に記載の装置。
【請求項１６６】
参加者インターフェースの仕様は、標準拡張可能マーク付け言語ＸＭＬに従ったドキュメント・タイプ定義に従ってドキュメントの定義を具備することを特徴とする請求項１６２に記載の装置。
【請求項１６７】
前記レポジトリは複数のトランザクションにおける使用のための標準化されたドキュメント・タイプを含み、及び前記入力及び出力ドキュメントの一つの前記定義は、レポジトリにおける標準化されたドキュメント・タイプへの参照を含むことを特徴とする請求項１４７に記載の装置。
【請求項１６８】
前記レポジトリは、ネットワークにおける参加者処理を識別するための標準化されたドキュメント・タイプを含むことを特徴とする請求項１４７に記載の装置。
【請求項１６９】
前記トランザクション処理は、複数の可変トランザクション処理アーキテクチャの一つを各々有し、及び前記入力ドキュメントの少なくとも一部分を、前記個別のトランザクション処理の前記可変トランザクション処理アーキテクチャに従って読み取り可能な形式に翻訳するため、及び前記翻訳された部分を前記個別のトランザクション処理にルーティングするための論理を含むことを特徴とする請求項１４６に記載の装置。
【請求項１７０】
前記翻訳するための論理は、前記個別のトランザクション処理の前記可変トランザクション処理アーキテクチャに従って変数及び方法を含むプログラミング・オブジェクトを生成することを特徴とする請求項１６６に記載の装置。
【請求項１７１】
前記トランザクション処理の前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を具備することを特徴とする請求項１６６に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された多様なクライアントの間でのトランザクション（取引）をサポートするシステム及びプロトコルに関し、詳細には、いろいろなアーキテクチャを有するプラットフォームの間での商取引をサポートするシステム及びプロトコルに関する。
【背景技術】
【０００２】
インターネットやその他の通信ネットワークは、参加者が商品やサービスを売買する商取引を含む幅広く多様なトランザクションに使用されつつあるコンピュータプラットフォームと人との間の通信のための手段を提供している。インターネット上での商取引を促進させるために多くの努力がなされつつある。しかしながら、多くの競合する標準があるので、トランザクションを実行するためには、そのトランザクションへの関係者は、前もって、用いられるプロトコルに同意しなければならないし、しばしば、かかるトランザクションをサポートするためプラットフォームアーキテクチャのカスタムインテグレーション（専用の統合）を必要とする。同意した標準にコンパチブルでない特定のノード内への商業的プロセスは、他のノードとのインテグレーションのために相当の手直しを必要とするかも知れない。更に、一つの会社（Ｃｏｍｐａｎｙ）が１つの標準又は他の標準にコミットすると、その会社は標準化グループのトランザクション関係者に固定され、それ以外を排除する。
【０００３】
インターネット商取引の開発に遭遇した挑戦の概要が、「Ｅｃｏ  Ｓｙｓｔｅｍ：Ａｎ  Ｉｎｔｅｒｎｅｔ  Ｃｏｍｍｅｒｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ」  Ｔｅｎｅｎｂａｕｍ  外著：Ｃｏｍｐｕｔｅｒ，Ｍａｙ  １９９７；４８〜５５ページに記載されている。
【０００４】
インターネット上での商取引を開放するため、アーキテクチャフレームワークの標準化が望ましい。かかる商業フレームワークをサポートするために開発されたプラットフォームは、ＩＢＭのＣｏｍｍｅｒｃｅ  Ｐｏｉｎｔ；Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｃｏｍｍｅｒｃｅ  Ｆｒａｍｅｗｏｒｋｓ；ＮｅｔｓｃａｐｅのＯＮＥ（Ｏｐｅｎ  Ｎｅｔｗｏｒｋ  Ｅｎｖｉｒｏｎｍｅｎｔ）；ＯｒａｃｌｅのＮＣＡ（Ｎｅｔｗｏｒｋ  Ｃｏｍｐｕｔｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ）；及びＳｕｎ／ＪＡＶＡ（登録商標）のソフトＪＥＣＦ（ＪＡＶＡ  Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｅｒｃｅ  Ｆｒａｍｅｗｏｒｋ）を包含する。
【０００５】
これらの専有のフレームワークに加えて、ＣＯＲＢＡ  ＩＩＯＰ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｉｎｔｅｒｎｅｔ  ＯＲＢ  Ｐｒｏｔｏｃｏｌ）に基づく、共通に配布されたオブジェクトモデルのようなプログラム技術が遂行されつつある。その共通配布のオブジェクトモデルの使用は、企業のシステムを、電子商取引のためのビジネスアプリケーションレベルで共同利用できるシステムにマイグレーション（交換）するのを簡単にしようとするためのものである。しかしながら、１つのフレームワークを用いる消費者又はビジネスは、異なるネットワーク上でトランザクションを実行することはできない。これが電子商取引システムの成長を制限している。
【０００６】
１つのフレームワークを実施する会社は、アプリケーションプログラミングインタフェース（ＡＰＩ）をもつであろうし、このＡＰＩは他のフレームワークをサポートするＡＰＩとは異なるものであろう。従って、会社にとって、共通のビジネスシステムインタフェースの採用を必要とせずに、相互にビジネスサービスにアクセスするのは大変に困難である。かかるＡＰＩレベルでのビジネスシステムインタフェースの開発は、関係者間でのかなりの協力が必要であるが、それはしばしば実際にはできない。
【０００７】
従って、通信ネットワーク内の多様なプラットフォーム間での対話（インタラクション）を促進するフレームワークを提供することが望ましい。かかるシステムは、カスタムインテグレーションや産業上でのワイドな標準に事前同意を必要とせずに、取引のパートナー間での自発的な商売を促進するであろう。更に、かかるシステムは、ビジネスオートメーションへの前進を促進して、伝統的なシステムインテグレーションの時間やコストやリスクの多くを排除するであろう。
【０００８】
全般的に、専有の標準に基づいた、閉じた商業パートナーネットワークを、開放マーケットに置き換えられる電子商取引システムを提供するのが望ましい。
【発明の開示】
【課題を解決するための手段】
【０００９】
本発明は、ビジネスをカストマーや供給業者や商業パートナーにつなぐためのインフラストラクチャ（基盤＝インフラ）を提供する。本発明のインフラストラクチャの下では、複数の会社は相互に、自己定義のマシン読取り可能なドキュメント（例えば、パートナーの間で容易に理解できるＸＭＬ（拡張マークアップ言語）系のドキュメント）を用いて情報及びサービスを交換する。交換されるべきドキュメントを記述するドキュメント（本書ではビジネスインタフェース定義すなわちＢＩＤと呼ぶ）が、インターネット上で送られ、あるいは、ネットワークのメンバーに通信される。ビジネスインタフェース定義（ＢＴＤ）は、潜在的な商業パートナーに、会社が提供するサービスとそのサービスに通信する時に使用するためのドキュメントとを告げる。従って、代表的なビジネスインタフェース定義によって、カストマーは購買オーダ（その購買オーダを受取るパーティのＢＩＤで発行されたドキュメント定義に従う購買オーダ）を提出することによってオーダを行うことができる。供給業者は、ビジネスシステム管理在庫データのＢＩＤで発行されたドキュメント定義に従った在庫状況報告をダウンロードすることによってその有効性をチェックすることが可能になる。予め定義したマシン読取り可能なビジネスドキュメントの使用によって、エンタプライズ（企業）のアプリケーションにアクセスするためのより直観的な柔軟な方法が提供される。
【００１０】
商業ネットワーク内でのノードは、インタフェースのマシン読取り可能なスペシフィケーションから成る本発明によるトランザクションのためのインタフェースを、そのインタフェースのマシン読取り可能なスペシフィケーションのための解釈情報を含むマシン読取り可能なデータ構造とともに確立する。インタフェースのマシン読取り可能なスペシフィケーションは、入力ドキュメントの定義と出力ドキュメントの定義とを含んでおり、これらは、前記のノードがインタフェースとして動作するトランザクションプロセッサによって受入れられ、作られる。入力ドキュメントの定義及び出力ドキュメントの定義は、例えば、標準ＸＭＬ系ドキュメントに従った、記憶ユニットのセットの記述及び記憶ユニットのセットのためのロジック構造をそれぞれ包含する。本発明の種々の観点に従った解釈情報を含むマシン読取り可能なデータ構造は、入力及び出力ドキュメントの定義におけるロジック構造のためのデータタイプのスペシフィケーション（例えば、ストリングやアレイ等）、ロジック構造のためのコンテントモデル（例えば、可能な値のリスト）、及び／又は、オーダのリストの各エントリへの特定のロジック構造のための記憶ユニットの予め定義したセットをマップするデータ構造を含み、ロジック構造のセマンティック定義（例えば、ネームを生成するためのマッピングコード）を提供する。
【００１１】
本発明の他の観点によれば、インタフェースは、ネットワークの少なくとも１つのノードによってアクセスできるメモリ内のリポジトリ（これはロジック構造のライブラリ及びロジック構造の解釈情報を記憶する）を含む。このリポジトリは入力及び出力ドキュメントの定義のライブラリとインタフェースのスペシフィケーションのライブラリとネットワークの参加者のインタフェースノードのスペシフィケーションのライブラリを含むように拡張され得る。
【００１２】
従って、本発明のトランザクションフレームワークの参加者は、トランザクションに包含される複数のノード実行プロセスを含む、ネットワークの複数のノード間でトランザクションを実行する。本発明の方法は、トランザクションのためのインタフェースのマシン読取り可能なスペシフィケーションを記憶することを含み、スペシフィケーションは、入力ドキュメントの定義と出力ドキュメントの定義とを含む。入力及び出力ドキュメントの定義は、それぞれ、記憶ユニットのセットの記述と記憶ユニットのセットロジック構造とを包含する。好ましいシステムでは、それらの定義は、標準のＸＭＬドキュメントタイプの定義、すなわちＤＴＤに従うやり方で、セマンティックマッピングとコンテントモデリングといくつかのエレメントデータタイピングとによって拡張されて、表現される。トランザクションの参加者は、通信ネットワークを通してドキュメントを含むデータを受取る。参加者は、トランザクションのために記憶されたスペシフィケーションに従ってそのドキュメントを解析して、そのトランザクションのための入力ドキュメントを識別する。ドキュメントの解析後、入力ドキュメントの少なくとも一部は、出力を提供するトランザクションプロセスへマシン読取り可能なフォーマットで提供される。出力ドキュメントは、記憶されたスペシフィケーションの出力ドキュメントの定義に基づいて、トランザクションプロセスの出力を構成するように形成される。出力ドキュメントは、通信ネットワーク上に送られて、代表的には、入力ドキュメントのソースに戻され、あるいは、トランザクションの特定のタイプのニーズに合わせた他のところに送られる。
【００１３】
したがって、ビジネスインターフェースの定義は、例えばＸＭＬによって特定されるドキュメント及び特別のノードにおけるトランザクション処理サービスのフロントエンド上で実行するプログラム間のギャップをブリッジする。これらのフロントエンドは、例えば、ＪＡＶＡ仮想マシンによって、或いはネットワークの両端のシステムの相互接続に対して与える他の共通のアーキテクチャによって実現される。ビジネスインターフェースの定義は、トランザクションプロトコルがビジネスインターフェースの定義書を用いてプログラムされる技術を提供する。このトランザクションのプロトコルに対するプログラムはドキュメント形式の詳細な公式仕様書によって与えられる。
【００１４】
トランザクションのインターフェースの機械読み取り仕様書はネットワークにおける他のプラットフォームにアクセス可能にされる。参加者のプラットフォームは、補完的なノードにおいて特定されるトランザクションインターフェースによる入力ドキュメント及び出力ドキュメントを設計する資源を含む。したがって、参加者のノードは、補完的インターフェースのための入力ドキュメントの定義、及び補完的インターフェースのための出力ドキュメントの定義にアクセスする資源を含む。アクセスしている参加者ノードのためにストアされた仕様書は、その仕様書にストアされたインターフェースの入力ドキュメントの定義にある補完的なインターフェースの出力ドキュメントの定義の少なくとも一部を含むことによって確立される。
【００１５】
本発明の他の特徴によるインターフェースのストアされた仕様書を確立するプロセスは、リポジトリから機械読み取り可能な仕様書のエレメントにアクセスすることを含む。このリポジトリは論理構造、コンテントモデル、および論理構造のための概略マップのライブラリ、およびインターフェース記述書を構築するために用いられる論理構造を有するドキュメントの定義をストアする。ネットワークにおいてアクセス可能なリポジトリは、容易に共有されることができるインターフェースの記述の構築を容易にする。特別なプロセスに対して形成された入力ドキュメント及び補完的なプロセスによって、リターンとして期待される出力ドキュメント間のあらゆる相違は、ネットワーク上の通信及び特別な情報を表現する共通の論理構造に同意することによって容易に交渉される。
【００１６】
本発明の一つの特徴によるトランザクションのインターフェースの機械読み取り可能な仕様書は、ネットワークのメンバー間で共有されるインターフェースドキュメントの定義に従うドキュメントを含む。インターフェースドキュメントの定義は特別なトランザクションの識別子、及び定義の少なくとも一つ及び特別なトランザクション用の入出力ドキュメントの定義に対するレファレンスをストアするための論理構造を有する。すなわち、特別なサービスに対するインターフェース記述書は入出力ドキュメントの定義を実際に含む。代わりに、それはこのような定義のリポジトリにおける位置、またはネットワークのどこかへのポインタを含むことができる。
【００１７】
本発明の他の代替方法によると、機械読み取り可能な仕様書は、インターフェースの識別子をストアするため、および仕様書の少なくとも１つとインターフェースによってサポートされる１以上のトランザクションの組の仕様書に対するレファレンスをストアするための論理構造を含むインタフェースドキュメントの定義に従うビジネスインターフェース定義ＢＩＤドキュメントを含む。各々のサポートされたトランザクションに対して、ドキュメントは定義の少なくとも１つ及び特別なトランザクションに対する入出力ドキュメントの定義に対するレファレンスを含む。
【００１８】
本発明の他の特徴によると、入出力ドキュメントの定義書に定義された記憶ユニットは文字データをエンコードするテキスト文字を含む分析されたデータ、および入出力ドキュメントの論理構造による記憶ユニットの組を識別するマークアップデータを有する。本発明の他の特徴によると、記憶ユニットの組の少なくとも１つは、自然言語を与える複数のテキスト文字をエンコードする。これは、これらのドキュメントの人間の読者や開発者によって入出力ドキュメントの定義の使用を容易にする。
【００１９】
本発明の他の特徴によると、入出力ドキュメントの仕様書は論理構造によって識別される記憶ユニットの組の少なくとも１つに対する翻訳情報を含む。１つの例における翻訳情報は、分析された文字の組に対する定義書をエンコードする。他の例では、翻訳情報はコンテントモデル仕様書のために提供する。例えば、カタログにおける記述を作るためにマップされたコードの多くのリストを載せるように特定の論理構造に要求する。あるシステムでは、ドキュメントの論理構造における記憶ユニットは特別な実効の必要性を満足するように分析されていないデータのセットを含む。
【００２０】
本発明の他の特徴によると、特別なプラットフォームにおけるトランザクションプロセスは、複数の変形トランザクション処理アーキテクチャの１つであるトランザクション処理アーキテクチャを有する。したがって、参加者ノードは、入力ドキョメントの少なくとも一部を、情報を利用するトランザクションの変形トランザクション処理アーキテクチャに読取り可能なフォーマットに変換するための資源を含む。ドキュメント定義のエレメントは、トランザクションプロセスの変形トランザクション処理アーキテクチャによる変数及び方法を含む。トランザクションプロセスのフロントエンドとして働くＪＡＶＡ仮想マシンを有する参加者に対して、ドキュメントにおける特別なフィールドは、データを含むＪＡＶＡオブジェクトに翻訳されるばかりでなく、ＪＡＶＡオブジェクトに関連した機能を得て、設定する。本発明によってサポートすることができる他のトランザクション処理アーキテクチャは、Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ＣＯＲＢＡ，Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ  ＣＯＭ，Ｏｎ−ｌｉｎｅ  Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  ＯＬＴＲ，およびＥｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ  ＥＤＩの意味におけるインターフェース記述言語に従う処理を含む。
【００２１】
本発明の他の特徴によると、複数のトランザクションにおいて使用されるドキュメント形式をストアするリポジトリが設けられる。特別なトランザクションのための機械読み取り可能な仕様書は、リポジトリにおけるドキュメント形式を参照することによって入出力ドキュメントの少なくとも１つを定義する。他の特徴によると、リポジトリに含まれるドキュメント形式は、ネットワークにおける参加者を識別するためのドキュメント形式を有する。このようなドキュメント形式は、参加者を識別し、その参加者によって支持されるサービスを特定し、且つこれらのサービスの各々に対する入出力ドキュメントを特定するため構造を提供する。
【００２２】
上述の方法に加えて、本発明は、ネットワークインターフェース、上述したように、トランザクションのためのインターフェースの機械読み取り可能な仕様書を含むデータと命令のプログラムをストアするためのメモリ、およびメモリとネットワークインターフェースに接続されたデータプロセッサを含むノード間のトランザクションを管理する装置を提供する。本装置にストアされた命令のプログラムは、トランザクションにおける参加者のための、上述したプロセスを実行するロジックを含む。
【００２３】
本発明は、更に、トランザクション処理アーキテクチャによるトランザクション処理を実行するネットワークとデータ処理資源を含むシステム上で実行されるトランザクションのための参加者インタフェースを確立するための装置を提供する。本装置は、システムによって実効可能であり、特別のトランザクションにおける参加者のための参加者インターフェースの定義を構築するツールを提供するシステムによって、アクセス可能な媒体にストアされた命令のプログラムを含む。参加者インターフェースの定義は、入力ドキュメントの定義及び出力ドキュメント定義を含む。入出力ドキュメント定義は、記憶ユニットのセットのための論理構造における記憶ユニットのセットのそれぞれの機械読み取り可能な記述書を有し、そしてそれは、本発明の１つの特徴として、ＸＭＬドキュメント形式の定義に従うことができる。
【００２４】
また、本発明のこの形態による参加者インタフェースを設定する装置は、データ処理システムによってアクセス可能な媒体に記憶された命令のプログラムを含み、かつを入力されたドキュメントを対応するデータ構造に変換するためにシステムによって実行可能な命令をコンパイルすべく、かつトランザクション処理の出力を出力ドキュメントの記憶部及びロジック構造のセットに変換するためにシステムによって実行可能な命令をコンパイルすべくトランザクション処理アーキテクチャに順応する入力及び出力ドキュメントの論理構造及び記憶部のセットに対応しているデータ構造をコンパイルするために入力及び出力ドキュメントの定義に応答する。
【００２５】
好ましいシステムにおける参加者インタフェースの定義を構築するためのツールは、インタフェース記述を構築するために用いられる論理構造及び論理構造に対する解釈情報のライブラリを記憶するリポジトリからの及び／又は相補的ノードからの定義の構成要素をアクセスするためにシステムによって実行可能な命令を含む。本発明の種々の形態によれば、リポジトリは、論理構造のライブラリだけでなく論理構造、及び参加者インタフェースを特定するためのフォーマットを備えているドキュメントの定義も含む。本発明のこの形態によれば、ツールは、参加者ノードの記述に関連して上述した技術によるビジネス・インタフェースの仕様を構築するために設けられる。本発明のこの形態によるインタフェースを構築するためのツール及びインタフェースをトランザクション処理アーキテクチャとの通信のために必要なリソースにコンパイルするためのツールは、ｌ好ましいシステムにおける参加者ノードで実施され、かつ入力及び出力ドキュメントを定義するインタフェース記述に基づいてネットワークの使用が成長するときにインタフェース記述の開発及び最適化に利用される。
【００２６】
従って、本発明の別の形態は、参加者インタフェースの定義を構築するためのツール及びを上述した機能を実行するコンパイラを含む、メモリ及びにメモリに記憶された命令を実行するデータ・プロセッサを含む装置を提供する。
【００２７】
本発明の更に別の形態によれば、参加者インタフェース記述の使用は、マーケット・メーカ・ノードの動作を可能にする。そのようなノードにおいて、インタフェースによって支援されたトランザクション、及びそのようなトランザクションの各々の入力及び出力ドキュメントを識別する複数の参加者インタフェースの機械可読仕様を記憶することを具備する、トランザクションを管理する方法が提供される。上述したように、入力及び出力ドキュメントは、ＸＭＬ標準によるような、記憶部及び記憶部に対する論理構造のセットの各々の記述を備えている。更に、トランザクションの定義及び参加者インタフェースの定義は、全て、ＸＭＬ又は他の標準化ドキュメント表現言語に順応する技術により特定されたドキュメントを備えている。そのようなマーケット・メーカ・ノードでは、ドキュメントを備えているデータは、通信ネットワークで受信される。ドキュメントは、識別された入力ドキュメントを受入れる一つ以上のトランザクションにおいて入力ドキュメントを識別するために仕様書によりパーズされる。入力ドキュメントの少なくとも一部は、一つ以上の識別されたトランザクションに関連付けられるトランザクション処理に対して機械可読フォーマットで供給される。トランザクション処理に入力ドキュメントの少なくとも一部を供給する方法は、マーケット・メーカ・ノードにおける処理アーキテクチャによりルーティング処理を実行することを含む。本発明の一つの形態におけるルーティング処理は、特定の処理アーキテクチャにより実行され、かつ入力ドキュメントの少なくとも一部は、ルーティング処理の処理アーキテクチャのフォーマットに変換される。好ましい形態による変換は、ルーティング処理の処理アーキテクチャによる変数及び方法を含むプログラミング・オブジェクトを生成することを含む。
【００２８】
本発明の別の形態によれば、マーケット・メーカ・ノードは、また、リポジトリ構造を支持する。そこで、処理は、マーケット・メーカ・ノードに記憶されるリポジトリへのネットワークの参加者によるアクセスを許容するためにマーケット・メーカ・ノードに含まれる。上述したように、リポジトリは、トランザクション・インタフェース・ドキュメントを構築するために論理構造の定義、解釈情報、及び参加者ノード用ドキュメント定義を含みかつ参加者を識別するビジネス・インタフェース定義のインスタンス、及び各々の参加者によって実行されるトランザクションを含む。
【００２９】
ルーティング処理は、種々の代替により、ドキュメントが送られる処理の可変処理アーキテクチャへの入力ドキュメントの変換、遠隔処理ノードにネットワークでその最初のドキュメント・フォーマットで入力ドキュメントを送ること（ルーティング）、又はそのような処理の組合せを含む。代替において、ルーティング処理は、また、一つの入力ドキュメント定義により定義された入力ドキュメントを、入力ドキュメントを待機するために登録されている処理に対する異なるドキュメント仕様により定義された異なるドキュメントに変換するための技術を含む。
【００３０】
また、マーケット・メーカ・ノードは、ネットワーク・インタフェース、参加者インタフェースの仕様を含んでいる命令のプログラム及びデータを記憶しているメモリ、及びデータ・プロセッサを含む装置として本発明により提供される。ロジックは、上述したようなマーケット・メーカ処理を実行するために命令のプログラム等の形でデータ・プロセッサにより供給される。
【００３１】
従って、本発明は、入力及び出力ドキュメンテーションの仕様の共有化に基づぐ電子コマースに対する基礎を提供する。ドキュメントは、ＡＰＩｓをプログラム作成するよりも実施することがより簡単なビジネス・サービスをアクセスするための直感的かつ柔軟性のある方法を提供する。会社が既に大筋で同意しているならば、交換されるドキュメントによりそのような会社を相互接続することは、いつも異なるビジネス・システム・インタフェースよりも、更に容易である。加えて、そのようなドキュメントは、好ましい実施例ではヒューマン・リーダブル（人間が読取り可能な）・フォーマットで特定される。本発明によれば、ビジネス・インタフェースは、人間並びにコンピュータによって容易に解釈可能であるＸＭＬドキュメントのようなドキュメントで特定される。
【００３２】
本発明のドキュメント・ベース・トランザクション・アーキテクチャの利用は、ドキュメントのあらゆるソースと基本的には同じ方法で動作するパーズの使用を含み、ネットワークの各参加者から情報を抽出しかつ統合するためのカスタム・プログラムに対する多くの必要性を取り除く。そこで、会計、購入、製造、配送及び他の機能からの事業情報を統合することは、まず、各ソースを本発明によるアーキテクチャを有するドキュメントに変換し、次いでパーズされたデータ・ストリームを処理することによって達成することができる。マーケットに参加するシステムの各ノードは、その内部システムのフォーマット、並びにトランザクションにより交換のために特定されるドキュメントのフォーマットについて知ることが必要なだけである。そこで、電子コマース・ネットワークに参加することを希望する全ての他のノードのネイティブ（固有）・フォーマットを生成できることの必要性がない。
【００３３】
完全なビジネス統合のために、本発明は、ＸＭＬ構成要素、属性又はメタデータのような標準化論理構造のリポジトリを提供し、特定のコマース・コミュニティに対するセマンティック（意味）言語、異なるメタデータ記述間をマップするための手段、及びドキュメントを処理しかつ適切なアプリケーション及びサービスを呼出すためのサーバを設定する。本発明によるネットワークの基本的構築ブロックは、潜在的なトレーディング・ビジネス・パートナーにどのようなオンライン・サービスを会社が提供しかつサービスを呼出すためにどのドキュメントを用いるかを通告するインタフェース定義；及びトレーディング・コミュニティを生成するために内部及び外部ビジネス・サービスのセットを互いに結合するためにブリッジを供給するサーバを含む。サーバは、入力ドキュメントをパーズしかつ適切なサービスを呼出すために動作する。また、本発明によるサーバは、各々のホスト・システムのフォーマットへの及びそれらのフォーマットからの、受信しかつ送信するドキュメントのフォーマットからの変換タスクを取り扱う。そこで、トレーディング・パートナーは、交換したビジネス・ドキュメントの構造、内容及びシーケンシングだけに同意することが必要であり、アプリケーション・プログラマー・インタフェースの詳細に同意する必要はない。ドキュメントが処理される方法及びドキュメントの受信の結果としてもたらされるアクションは、まったくサービスを提供するビジネスによる。これは、システム・レベルからビジネス・レベルに統合を向上させる。それは、その内部技術実施、組織又は処理における変化にも係わらず、ビジネスにそのパートナーに対する明瞭かつ安定したインタフェースを提示させることができる。
【００３４】
ビジネス・インタフェース定義を構築しかつそのような記述によりサーバにコマースを管理させることができる全ての処理は、会社、サービス及び製品のようなビジネス記述プリミティブ、カタログ、購入注文、及びインボイスのようなビジネス・フォーム、並びに時間及び日付、場所及び商品の分類を含む、標準測定を含んでいる一般的なビジネス概念に対する情報モデルの共通のビジネス・ライブラリ、又はリポジトリによって容易に行われる。
【００３５】
本発明の他の形態は、以下に説明する図面、詳細な説明、及び特許請求の範囲を考慮することにより理解することができるであろう。
【発明を実施するための最良の形態】
【００３６】
図面との関連で本発明について詳細に説明する。図１は、ビジネスインタフェース定義の使用に基づくマーケットメーカー及びマーケット参加者のネットワーク、該インタフェースの既述にしたがって特定された入力及び出力ドキュメントのやり取りのサポートを説明するものである。該ネットワークは、インターネット１９などの通信ネットワーク、あるいはその他のテレコミュニケーションまたはデータコミュニケーションネットワークを介して相互に接続されている、複数のノード１１〜１８を含む。ノード１１〜１９の各々は、ポータブルコンピュータ、デスクトップパーソナルコンピュータ、ワークステーション、システムのネットワーク、あるいは他のデータプロセシングリソースなどのコンピュータで構成されている。該ノードは、ビジネスインタフェース定義を記憶しておくためのメモリ、ネットワーク中の他のノードとの商取引トランザクションをサポートするトランザクションプロセスを実行するためのプロセッサ、及びそのようなサービスをサポートするために該プロセッサにより実行されるコンピュータプログラムを含んでいる。さらに、各ノードは、インターネット１９あるいは他のコミュニケーションネットワークを渡るコミュニケーションを提供するための、ネットワークインタフェースを含む。
【００３７】
図１の環境においては、ノード１１、１２、１３、１４、１６及び１８は、指定されたマーケット参加者である。マーケット参加者は、本発明にしたがって確立された商取引トランザクションにしたがって取引される商品またはサービスの需要者または供給者についてのリソースを含んでいる。
この例では、ノード１５及び１７は、マーケットメーカーノードである。マーケットメーカーノードは、ＢＩＤレジストリと呼ばれるビジネスインタフェース定義を登録するためのリソースを含んでいる。参加者は、ドキュメントをマーケットメーカーに送ることが可能であり、そこで該ドキュメントは識別され、そのようなドキュメントを入力として受け取るように登録されている適切な参加者に発送される。マーケットメーカーはまた、ビジネスインタフェース定義の構築において使用するための共通ビジネスライブラリを構成する、標準フォームのリポジトリを維持することにより、商取引ネットワークを促進する。
【００３８】
この例では、マーケット参加者１８は、インターネット１９を介することなく、マーケットメーカー１７に直接接続されている。このマーケットメーカーへの直接接続は、インターネット１９などの公衆ネットワーク、及び、ローカルエリアネットワークのような私設接続あるいはノード１７と１８との間に示されているようなポイント−トゥ−ポイント接続を実際の導入することにより、商取引トランザクションをサポートするネットワークの形態が極めて多様なものになり得る、ということを示すものである。実際のコミュニケーションネットワークはかなり多様であり、本発明による商取引トランザクションネットワークを確立するために使用するのに好適である。
【００３９】
図２は、本発明によるネットワークにおけるマーケット参加者のために確立されたビジネスインタフェース定義（ＢＩＤ）における、繰り込まれた構造の発見的なダイアグラムである。図２に示されているビジネスインタフェース定義は、ＸＭＬドキュメントタイプ定義ＤＴＤなどのドキュメント構造の形式定義にしたがって配列された記憶ユニット及び論理構造からなる、データ構造である。図２の構造は、バーティを識別するための第１の論理構造２００を含んでいる。論理構造２００と関連付けられているのは、名前を搬送するための繰り込まれた論理構造２０１、物理的アドレス２０２、ネットワークのアドレスあるいは位置２０３、及び一組のサービスのためのトランザクション２０４である。サービスセット中の各トランザクションについて、トランザクションＢＩＤ２０５、トランザクションＢＩＤ２０６、及びトランザクションＢＩＤ２０７を含む、インタフェース定義が提供されている。トランザクションＢＩＤ２０５などの各トランザクションＢＩＤの中には、名前２０８、サービスが実行されるネットワーク上の位置２０９、サービスにより実行される操作２１０、及び一組のタグにより示される入力ドキュメント２１１を含むための論理構造が提供されている。また、サービスＢＩＤ２０５は、一組のタグにより示される出力ドキュメント２１２を含んでいる。一組の入力ドキュメント２１１は、入力ドキュメントビジネスインタフェース定義２１３、２１４、及び２１５を含む、サービスが応答するよう指示された、各入力ドキュメントについてのビジネスインタフェース定義を含んでいる。入力ドキュメントについてのビジネスインタフェース定義は、名前２１６、ドキュメントの記述を見出し得るネットワーク上の位置２１７、及びフィールドにより示された通りドキュメントにおいて搬送されるべきモジュール２１８を含んでいる。同様に、出力ドキュメントセット２１２は、出力ドキュメントＢＩＤ２１９、出力ドキュメントＢＩＤ２２０、及び出力ドキュメントＢＩＤ２２１を含む、出力ドキュメントについてのインタフェース定義を含んでいる。各出力ドキュメントＢＩＤについて、名前２２２、ネットワーク上または他の場所の位置２２３、及びドキュメントのモジュール２２４が特定されている。図２に示されている参加者についてのビジネスインタフェース定義は、各サービスの入力及び出力ドキュメントについて利用されるべき論理構造の実際の定義、あるいは、定義を見出し得る位置へのポインタまたは他のリファレンスを含んでいる。
【００４０】
好ましいシステムにおいては、図２のドキュメントは、ＸＭＬドキュメントタイプ定義ＤＴＤにおいて特定されるが、他のドキュメント定義アーキテクチャを使用することもでき、またドキュメントの依頼の翻訳に使用される論理構造についての翻訳情報を含んでいる。また、トランザクションＢＩＤ、入力ドキュメントＢＩＤ及び出力ドキュメントＢＩＤの各々は、ＸＭＬドキュメントタイプ定義にしたがって特定される。ＸＭＬタイプドキュメントは、マークアップデータ及びキャラクタデータを含む解析されたデータに基づくシステムの例である。マークアップデータは、ドキュメント内の論理構造を識別し、キャラクタデータの組は、論理構造の内容を識別する。さらに、解析されないデータは、様々な目的でドキュメント中を搬送され得る。例えば、ＷＷＷ．Ｗ３．ＯＲＧ／ＴＲ／１９９８／ＲＥＣ−ＸＭＬ−１９９８０２１０においてＷＣ３  ＸＭＬワーキンググループにより発行されたＥｘｔｅｎｓｉｂｌｅ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ  ＸＭＬ  １．０  ＲＥＣ−ＸＭＬ−１９９８０２１０の仕様書を参照のこと。
【００４１】
かくして、例示したシステムにおいては、ネットワーク中の参加者ノードは、ビジネスシステム及びサービスを、ビジネスが受容し発生するＸＭＬコード化されたドキュメントと相互接続することにより、仮想企業を設立する。例えば、特定のサービスのビジネスインタフェース定義は、カタログ記入に対する要求のＢＩＤに合致するドキュメントを受け取った場合には、カタログ記入のＢＴＤに合致するドキュメントを返送することを確立する。また、購入注文のＢＩＤに合致するドキュメントを受け取り、それが受け取った端末にとって受け入れ可能なものである場合には、請求書のＢＩＤに合致するドキュメントを返送する。ネットワーク中のノードは、ネットワーク中の任意の所定のシステムの様々なトランザクションプロセシングアーキテクチャにしたがって確立されたローカルビジネスシステムにＸＭＬドキュメントが入る前に、ＸＭＬドキュメントを加工する。かくして、システムは、ＭＩＭＥ−コード化されたＸＭＬドキュメントの組などの関連するドキュメントの組を解読し、これを解析して“マークアップメッセージ”のストリームを創作する。このメッセージは、例えば下記のようなイベントリスナーモデルを使用して、適切な用途及びサービスに発送される。
【００４２】
ビジネスサービス間で交換されるドキュメントは、より複雑なドキュメント定義が生成されうるビルディングブロックのリポジトリから生成されるＸＭＬ言語（共通のビジネス言語）を使用してエンコードされる。リポジトリは、会社、サービス、製品のようなビジネスディスクリプションプリミティブ、カタログ、購入注文、インボイスのようなビジネスフォーム、時間、日、位置のような標準の測定値、分類コード、および、ＸＭＬドキュメントの論理構造の解釈情報を与えるようなものを含む、ビジネスドメインに共通のファンクションおよび情報に焦点をあてた解釈情報のモジュールを記憶する。
【００４３】
ビジネスインターフェイス定義は、本発明に従うドキュメントを交換するインターフェイスを設計するために使用されるスキーマとしての役割を果たす更に高レベルのドキュメントである。そうして、ビジネスインターフェイスは、ＸＭＬに従って記述されるドキュメントと、特定のノードにおいてトランザクション処理サービスのフロントエンドで実行されるプログラムとの間のギャップを埋める。このようなフロントエンドはＪＡＶＡ仮想マシーン、またはネットワーク中のシステムの内部接続を規定する他の共通アーキテクチャによって実施される。そうして、ビジネスインターフェイス定義は、ビジネスインターフェイス定義ドキュメントを使用してトランザクションプロトコルをプログラムするのに用いられる技術を提供する。トランザクションのプロトコルのためのプログラムは、ドキュメントタイプの詳細な公式の仕様によって規定されている。
【００４４】
ＸＭＬフォーマットに従うマーケット関係者のドキュメントに基づく一例のビジネスインターフェイス定義ＢＩＤは、以下に与えられる。マーケット関係者ＤＴＤは、連絡先および住所情報をサービスおよび財政情報のディスクリプションと関連付けて、マーケット関係者に関するビジネス情報を分類する。このビジネス情報は、名前、コード、住所、ビジネス組織を示すための専用分類法、ビジネスのタームへのポインタから成る。加えて、マーケット関係者ＤＴＤによって識別されるサービスは、その関係者が応答し、生成する入力及び出力ドキュメントを記載する。そうして、説明に役立つ注釈付きのＸＭＬで記述されるマーケット関係者ＤＴＤ、サービスＤＴＤ、トランザクションドキュメントＤＴＤのために一例の共通ビジネス言語を使用するスキーマを規定するドキュメントは、以下に続く。
【００４５】
2008084328.tif 000003
2008084328.tif 000004
2008084328.tif 000005
2008084328.tif 000006
2008084328.tif 000007
2008084328.tif 000008
2008084328.tif 000009
2008084328.tif 000010
2008084328.tif 000011
2008084328.tif 000012
サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプエレメントで以下のように拡張されうる。
2008084328.tif 000013
2008084328.tif 000014
上記のサービスタイプエレメントは、ビジネスインターフェイス定義によって保有される解釈情報、この例では、有効なサービスタイプのいずれか１つの識別を可能にするコンテントフォームを例示する。別の解釈情報は、例えばコンテントフォーム「ｕｒｌ」を含み、データタイプ「ｓｔｒｉｎｇ」で表されるエレメント＜Ｈ３＞Ｉｎｔｅｒｎｅｔ  Ａｄｄｒｅｓｓ＜／Ｈ３＞のような、データタイピングを含む。さらに別の解釈情報は、例えばファイル「ＣＯＵＮＴＲＹ．ＵＳ．ＳＵＢＥＮＴＩＴＹ」中の国に対するコードマッピングを含むエレメント＜Ｈ３＞Ｓｔａｔｅ＜／Ｈ３＞のような、リストのエレメントへのコードのマッピングを含む。
マーケット関係者ＤＴＤによって照会されるサービスディスクリプションは、サービスのコンペティションについてサービスが認めて生成するドキュメントを規定する。ベーシックサービスディスクリプションは、ＸＭＬドキュメントｔｒａｎｓａｃｔ．ｄｔｄとして以下に記載される。
ｔｒａｎｓａｃｔ．ｄｔｄは、インボイスのようなトランザクションディスクリプション、または値の交換のディスクリプションをモデル化する。このドキュメントタイプは、多くの用途を支援し、従って、トランザクションディスクリプションエレメントは、ユーザーがインボイス、業績、売りの申し出、取引価格の要望等を区別するのを可能にする属性を有する。交換は２人以上の関係者間で行われうるが、申し出人と相手の２人のみを登場させる。その各人は、上記に概説したマーケット関係者ＤＴＤに合致するドキュメントへのポインタによって表される。相手のポインタが、売りの申し出を受け入れるのは任意である。交換ディスクリプションは以下に挙げるｔｒａｎｐｒｉｍ．ｍｏｄに記述され、価格および小計を含む。交換ディスクリプションに続いて、全体としてトランザクションに適用される料金が備えられ、全体の料金が与えられなければならない。従って、この例のトランザクションディスクリプションスキーマドキュメントｔｒａｎｓａｃｔ．ｄｔｄは以下に表される。
2008084328.tif 000015
代表マーケット関係者およびサービスＤＴＤは、上記の定義に従って生成され、以下の通りである。
マーケット関係者ＤＴＤ
2008084328.tif 000016
2008084328.tif 000017
サービスＤＴＤ
2008084328.tif 000018
ｔｒａｎｓａｃｔ．ｄｔｄによって生成されるドキュメントの一例が続く。
2008084328.tif 000019
2008084328.tif 000020
2008084328.tif 000021
【００４６】
したがって、本発明は、マーケット参加者がそれ自身を識別し、入力ドキュメントのタイプおよび取引を行おうとしている出力ドキュメントのタイプを識別できるようにする技術を提供する。この種のドキュメントに担持された内容がこの取引での他のパーティーまたはローカルパーティーによって処理される特定の仕方は、ビジネス関係の確立には関係しないし、取引を行うことにも関係しない。
【００４７】
図３は、本発明によるネットワークにおける参加者ノードの概略図である。図３に例示されたノードは、ポート３０１にて通信ネットワークに結合されるネットワークインターフェイス３００を含む。このネットワークインターフェイスは、ドキュメントパーサー３０１に結合される。パーサー３０１は、入力ドキュメントからのロジカルストラクチャーをトランスレータモジュール３０２へ供給し、トランスレータモジュール３０２は、入力ドキュメントをホスト取引システムによって使用できるようなフォームへと変換し、また、その逆に、ホストプロセッサの出力を送り先への送信のためにビジネスインターフェイス定義での出力ドキュメントフォームへと変換するためのものである。パーサー３０１およびトランスレータ３０２は、参加者モジュール３０３に記憶されたビジネスインターフェイス定義に応答する。
【００４８】
トランスレータ３０２からの出力データストラクチャーは、パーサー３０１によってシグナリングされるエベントと共に取引プロセスフロントエンド３０４へ供給される。１つの実施例におけるフロントエンド３０４は、ネットワークにおける種々なノードの間で通信するに適したＪＡＶＡバーチャルマシンまたはその他の類似のインターフェイスからなる。取引プロセスフロントエンド３０４は、パーサー３０１およびトランスレータ３０２によって指示されたエベントに応答して、入力データを、その参加者が結合されたエンタープライズシステムおよびネットワークにおける適当なファンクションへルーティングする。こうして、図３の例における取引プロセスフロントエンド３０４は、コマーシャルファンクション３０５、データベースファンクション３０６、アカウンティングおよびビリング３０７の如きその他のエンタープライズファンクションに結合され、また、パーサーによって指示されたエベントに応答するように設計された特定のエベントリスナーおよびプロセッサ３０８に結合される。
【００４９】
パーサー３０１は、ビジネスインターフェイス定義にしたがって特定される前述の例におけるような購入注文またはその他のドキュメントを受け取り、ＪＡＶＡバーチャルマシンのためのＪＡＶＡエベントのセットの如きローカル取引処理アーキテクチャによって認識されるエベントのセットを生成する。
【００５０】
本発明のパーサーは、受信ドキュメントに基づくエベントをリスニングするプログラムから切り離される。受信ドキュメントにおける種々なマークアップピースまたは特定の仕様を満たす完全ドキュメントは、処理を開始させるリスニングファンクションのための命令として働く。こうして、リスニングプログラムは、ドキュメント情報に関連したビジネスロジックを実施する。例えば、アドレスエレメントに関連したプログラムは、データベースをチェックすることによってポスタルコードを確証するコードでありうる。これらのリスナーは、ドキュメントルーターで登録することによりエベントに加入する。ドキュメントルーターは、適切なエベントを、それらに興味のあるすべての加入者へと差し向けるものである。
【００５１】
例えば、前述したように特定された購入注文は、ドキュメントまたはその内容を注文エントリプログラムへ接続するであろうパーサーによって発生されるエベントをリスニングするプログラムによって監視されうる。その購入注文内のプロダクト記述の受領によりあるプログラムを使ってインベントリをチェックする。購入注文内のアドレス情報の受領により、あるプログラムを使ってデリバリのためのサービスの利用性をチェックする。ドキュメントにおけるバイヤー情報フィールドは、種々なプロセスを使って、クレジット価値について注文ヒストリをチェックし、または、プロモーションまたは消費者のアイデンティティを知ることに基づくような類似の処理をオファーすることができる。
【００５２】
コンプレックスリスナーは、プリミチブなリスナーのコンフィギュレーションとして生成されうる。例えば、ある購入注文リスナーは、前述したリストリスナーを含み、そのリストリスナーを使いうるし、また、リストメンバーは、それら自身に関して使われうる。リスナーがランするようなアプリケーションは、ネーチブＸＭＬプロセスまたはネーチブＪＡＶＡプロセスではないようであることに注意すべきである。これらの場合において、オブジェクトは、受信トランスアプリケーションによって必要とされるフォーマットへ変換される。そのアプリケーションが処理を完了するとき、その出力は、ネットワークにおける他のノードへの通信のためにＸＭＬフォーマットへと変換し戻される。
【００５３】
前述したようなマーケット参加者ドキュメントタイプ記述および取引ドキュメントタイプ記述としては、ドキュメントにおけるロジックエレメントのためのスキマチックマッピングがあり、また、自然言語に基づくマークアップ言語がある。自然言語マークアップおよびＸＭＬのその他の自然言語属性は、ビジネスインターフェイス定義、サービス記述および入力および出力ドキュメントの記述の仕様のためのＸＭＬタイプマークアップ言語の使用を容易とする。
【００５４】
ビジネスインターフェイス定義を記憶することに加えて、参加者モジュール３０３は、入力ドキュメントにおけるロジカルストラクチャーに対応する取引プロセスフロントエンド３０４によって使用されるオブジェクトまたはその他のデータストラクチャーを編集したり、トランスレータ３０２を編集したりするのに使用されるコンパイラーを含む。こうして、ビジネスインターフェイス定義が参加者の関係する取引の変化につれて参加者によって変更されまたは更新されるとき、トランスレータ３０２およびパーサー３０１は、自動的にアップデートに保たれる。
【００５５】
好ましいシステムにおいては、ＪＡＶＡエベントのセットは、ＳＧＭＬのグローブモデル、主として、各エレメントについてプロパティセットによって拡張された標準のエレメントストラクチャーインフォーメーションセットに対応するコンパイラによって生成される（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄ  ＩＳＯ／ＩＥＣ  １０１７９：１９９６（Ｅ），Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ−−Ｐｒｏｃｅｓｓｉｎｇ  Ｌａｎｇｕａｇｅ−−Ｄｏｃｕｍｅｎｔ  Ｓｔｙｌｅ  Ｓｅｍａｎｔｉｃ  ａｎｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＤＳＳＳＬ））。ＸＭＬドキュメントをプロセスのためエベントのセットへと戻すのは、パーサー出力がインターナルデータストラクチャーとして維持されるような構文解析の通常モデルとは異なる。各ノードの取引処理フロントエンドによって使用するのに適したＪＡＶＡエベントまたはその他のプログラミングストラクチャーへＸＭＬドキュメントのエレメントを変換することにより、トレードされるドキュメントを利用するノードでのリッチファンクショナリティが可能とされる。
【００５６】
こうして、取引プロセスフロントエンド３０４は、システムにおける他のリスニングプログラムの知識なしにまたはインパクトなしに新しいリスナープログラムを加えることができるようにするパブリッシュおよびサブスクライブアーキテクチャーにて作動することができる。図３における各リスナー３０５、３０６、３０７、３０８は、フロントエンド３０４がエベントを指揮するキューを維持する。これにより、多数のリスナーがそれら自身のペースで併行してエベントを取り扱うことができるようになる。
【００５７】
さらにまた、本発明によれば、リスナーがランするようなアプリケーションは、入力ドキュメントのフォーマットに整合するネーチブＸＭＬファンクションまたはネーチブファンクションである必要はない。むしろ、これらのリスナーは、取引プロセスフロントエンド３０４がＪＡＶＡインターフェイスである場合には、ＪＡＶＡファンクションでありうし、または、独特な取引処理アーキテクチャーにしたがってランするファンクションでありうる。これらの場合において、オブジェクトは、受信アプリケーションによって必要とされるフォーマットへ変換されうる。リスナーのアプリケーションが終わるとき、その出力は、モジュール３０３におけるビジネスインターフェイス定義によって特定されるようなドキュメントのフォーマットへと変換し戻される。こうして、トランスレータ３０２は、組み合わせたドキュメントを出力として供給するため直接的にネットワークインターフェイス３００に結合される。
【００５８】
取引処理フロントエンドに結合されたリスナーは、入力ドキュメントのためのリスナー、入力ドキュメントの特定エレメントのためのリスナーおよび入力ドキュメントの特定のエレメントに記憶されている属性のためのリスナーを含みうる。これにより、入力ドキュメントをフィルタリングしそれに応答するための特定のノードでの取引プロセスの種々な融通性のある実施が可能となる。
【００５９】
図４は、図３のシステムのための入力ドキュメントを受信して処理するためのプロセスを例示している。こうして、プロセスは、ネットワークインターフェイスでドキュメントを受信することで始まる（ステップ４００）。パーサーは、ビジネスインターフェイス定義に応答してドキュメントタイプ（４０１）を識別する。ＸＭＬフォーマットにてドキュメントのためのＤＴＤを記憶しているビジネスインターフェイス定義を使用して、ドキュメントは構文解析される（ステップ４０２）。次に、ドキュメントのエレメントおよび属性は、ホストのフォーマットへと変換される（ステップ４０３）。この例では、ＸＭＬロジックストラクチャーは、ゲットおよびセットファンクションの如きデータに関連した方法とともにＸＭＬエレメントのデータを担持するＪＡＶＡオブジェクトへと変換される。次に、ホストオブジェクトは、ホスト取引処理フロントエンドへ転送される（ステップ４０４）。これらのオブジェクトは、パーサーおよびトランスレータによって指示されるエベントに応答してプロセスへルーティングされる。ドキュメントのエレメントを受け取るプロセスは、実行され、出力を発生する（ステップ４０５）。その出力は、ビジネスインターフェイス定義によって定められるような出力ドキュメントのフォーマットへと変換される（ステップ４０６）。この例では、トランスレーションは、ＪＡＶＡオブジェクトのフォームからＸＭＬドキュメントのフォームへと進む。最後に、出力ドキュメントは、ネットワークインターフェイスを通して送り先へと送信される（ステップ４０７）。
【００６０】
図５は、図３のシステムのためのイベント発生器／イベントリスナー機構の詳細な図である。一般に、図５に示されている手法はＪＡＶＡ  ＪＤＫ１．１イベントモデルの改良である。このモデルにおいて、３種類のオブジェクトが考慮される。第１種類のオブジェクトはイベントの発生に関する情報を含むイベントオブジェクトである。発生できるイベントの異なる全種類に対応して、イベントオブジェクトの種類の数が有る。第２種類のオブジェクトは、何かが起こった時に活動を監視しイベントオブジェクトを発生するイベント発生器である。第３は、イベント発生器により発生されたイベントオブジェクトを聞くイベントリスナーである。イベントリスナーは一般に、特定のウインドウ上のマウスクリックなどのような特定のイベント発生器を聞く。イベントリスナーはイベント発生器上に「イベントリスナーを加える」方法を呼ぶ。このモデルは図３の環境に適合させることができ、ＸＭＬドキュメントにより代表されるようなオブジェクトのグラフを歩きそして構文解析することに応答してオブジェクトが発生される。
【００６１】
図５に示されるシステムは一般的なＸＭＬパーサー５００を有する。このようなパーサーは標準の呼び戻しモデルを使用して実現できる。構文解析イベントが発生する時に、パーサーはアプリケーションオブジェクト内で特定の方法を呼出し、パラメータ内の適当な情報を渡す。従って、単一のアプリケーション５０１がパーサーと共に存在する。アプリケーションはパーサーが提供する情報をＸＭＬイベントオブジェクト内にパッケージし、そしてブロック５０２により示されるように、それを自身により識別された数だけのイベントリスナーに送る。イベント５０２の組は完全にパーサーから独立している。イベント５０２はどんな数のマシン上のどんな数のリスナーおよびどんな数のスレッドへにも供給されることができる。イベントは１つの代替形式においては、エレメント構造情報セット（ＥＳＩＳ）に基づいている。従って、これらはエレメントの開始および終了などのようなドキュメント構造または属性の認識のような重要な観点のリストからなる。ＸＭＬ（そしてＳＧＭＬ）パーサーは一般にＥＳＩＳ構造をパーサーがそのアプリケーションに戻るための情報のデフォルトセットとして使用する。
【００６２】
専門化されたＥＳＩＳリスナー５０３は、イベント５０２の組に結合される。
このリスナー５０３はＥＳＩＳリスナーＡＰＩを実現し、そして１または複数からの発生器からの全てのＸＭＬイベントを聞く。１つのエレメントイベント発生器５０４は専門化されたＥＳＩＳリスナーで、ＸＭＬイベント発生器でもある。そのリスナーは特定のタイプのエレメントに対するイベントにのみ興味があるオブジェクトである。例えば、ＨＴＭＬ環境においては、リスナーは指示されたリストのみ、すなわち、＜ＯＬ＞と＜／ＯＬ＞タグの間のドキュメントの部分のみに興味を有する。他の例では、リスナーは上の例のドキュメントから共通ビジネス言語に従って「ｐａｒｔｙ．ｎａｍｅ」エレメントまたは「ｓｅｒｖｉｃｅ．ｎａｍｅ」エレメントのみを聞き、エレメントのための図式的マッピングに一致するデータをエレメントが運ぶことを確実にするためにエレメントを処理し、そして受取ノードにおいて必要とされるプロセスに従って反応する。
【００６３】
これは、システムが、価格を合計するだけのようなドキュメントの特定部分のみを聞く小さいオブジェクトを有することを可能にする。リスナーが発生器からそれら自身を加えるまたは取除くことができるから、ＨＴＭＬドキュメントの例えば＜ＨＥＡＤ＞部分のみを聞くリスナーも存在できる。この理由およびＸＭＬドキュメントの高い反復性の理由により、高い目標的なコードを書くことおよび併発的なリスナーを書くことができる。例えば、＜ＯＬ＞リスナーは＜ＵＬ＞（指示されていないリスト）リスナーがその＜ＬＩ＞リスナーを設定する方法とは完全に分離して＜ＬＩ＞リスナーを設定することができる。代替方法として、図形ユーザインターフエイスを発生するリスナーおよび同じ入力を使用するデータベースを探索する別のリスナーを作成できる。従って、アプリケーションが一度に１つずつ検査する完成されたデータ構造とは反対に、ドキュメントはリスナーにより実行されるプログラムとして取扱われる。もし、アプリケーションがこの方法で書かれると、アプリケーションを実行するために全ドキュメントをメモリ内に持つ必要が無い。
【００６４】
イベント５０２の組に結合された次のリスナーは、属性フィルター５０５である。エレメントフィルタ５０４に似て属性フィルタ５０５はＥＳＩＳリスナーモデルに従い属性イベント発生器である。属性フィルタのためのリスナーはそれが興味を持つ属性を指定し、そして、指定された属性を持ついかなるエレメントのためのイベントを受取る。例えば、フォントマネージャは例えば＜Ｐ  ＦＯＮＴ＝“Ｔｉｍｅｓ  Ｒｏｍａｎ”／Ｐ＞のようなフォント属性を持つエレメントのためだけのイベントを受取るだろう。
【００６５】
エレメントイベント発生器５０４は、エレメントリスナー５０４Ａを専門化するためにそのようなエレメントオブジェクトを供給する。
【００６６】
属性イベント発生器５０５は属性イベントオブジェクトを属性リスナー５０５Ａへ供給する。同様に、属性オブジェクトは一のドキュメント形式から別へ属性を使用してＳＧＭＬ／ＸＭＬ変形する意味で「アーキテクチュア」に供給される。従って、５０５Ｂのアーキテクチュアは特定の名前を持った特定の属性を識別できるようにする。その定義された属性を持ったエレメントのみが出力ドキュメントの部分になり、そして出力ドキュメント内のエレメントの名前は、入力ドキュメント内の属性の値である。例えば、もしアーキテクチュア５０５ＢがＨＴＭＬであり、ストリングを、
＜ＰＵＲＣＨＡＳＥＳ  ＨＴＭＬ＝“ＯＬ”＞＜ＩＴＥＭ  ＨＴＭＬ＝“ＬＩ”＞＜ＮＡＭＥ  ＨＴＭＬ＝“Ｂ”＞ＳＴＵＦＦ＜／ＮＡＭＥ＞＜ＰＲＩＣＥ  ＨＴＭＬ＝“Ｂ”＞１２３＜／ＰＲＩＣＥ＞＜／ＩＴＥＭ＞＜／ＰＵＲＣＨＡＳＥ＞
翻訳すると、
＜ＯＬ＞＜ＬＩ＞ＳＴＵＦＦ＜／Ｂ＞＜Ｂ＞１２３＜／Ｂ＞＜／ＬＩ＞＜／ＯＬ＞
になり、正しいＨＴＭＬである。
【００６７】
イベント５０２の組に結合された次のモジュールはツリー（木）ビルダー５０６である。ツリービルダーはＸＭＬイベントのストリームを取り、下にあるドキュメントのツリー（木）表現を発生する。ツリービルダー５０６の一つの好ましい形式は、Ｗ３Ｃ（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／１９９８／ＷＤ−ＤＯＭ−１９９８０７２０／ｉｎｔｒｏｄｕｃｔｉｏｎ．ｈｔｍｌ）の仕様に従ってドキュメントオブジェクトモデルＤＯＭオブジェクト５０７を発生する。イベントストリーム内のリスナーは大部分の要求を処理するのに使用できるが、ツリー形式はドキュメント回りの質問を支援するため、ノードを再順序付けるため、新ドキュメントの作成、例えばドキュメントを多数回構文解析するような、そこから同じイベントストリームを複数回発生できるメモリ内のデータ構造を支援するのに役立つ。専門化されたビルダー５０８は、特定の実施に適合するようなドキュメントの部分の特別なサブツリーを作るために、ツリービルダー５０６に結合できる。
【００６８】
入力するドキュメントに応答するのに加えて、ＸＭＬイベント５０２の他の源も供給されることができる。従って、イベントストリーム５１０はＤＯＭオブジェクトのツリー上を歩くことにより、そしてドキュメントが構文解析されいた時に作成された元のイベントストリームを再発生することにより発生される。これは、システムがドキュメントが数回構文解析されている外観を与えることを可能にする。
【００６９】
ツリーを歩きそしてイベントのストリームを発生するオブジェクトの観念は、ＤＯＭオブジェクトのツリーを越えて質問できるオブジェクトのいかなるツリーに一般化できる。従って、ＪＡＶＡウォーカー５１２は、ＪＡＶＡビーンコンポーネント５１３のツリーを歩くアプリケーションでもよい。ウォーカーは全ての公開されているフイールドおよび方法上を歩く。ウォーカーは終わりの無いサイクルに入り込まないことを確保するために既に訪問したオブジェクトの軌跡を記憶する。ＪＡＶＡイベント５１４はＪＡＶＡウォーカー５１２により発生されるイベントのタイプである。これは現在、オブジェクトから引き出すことのできる情報の種類の大部分を含む。これは、ＥＳＩＳのＪＡＶＡ等価物であり、そして、ＸＭＬに適用されたのと同じプログラム手法をＪＡＶＡオブジェクト一般に適用すること、特にＪＡＶＡビーンズにであるが、を可能にする。
【００７０】
ＪＡＶＡからＸＭＬイベント発生器５１５は、ＪＡＶＡリスナーとＪＡＶＡイベント発生器から構成される。これは、ＪＡＶＡウォーカー５１２からイベントのストリーム５１４を受取り、そしてＸＭＬドキュメントとしてＪＡＶＡオブジェクトを供給するために選択されたものを翻訳する。好ましい実施例において、イベント発生器５１５はＪＡＶＡビーンズＡＰＩを利用する。見られた各オブジェクトはエレメントとなり、エレメント名はクラス名とおなじである。そのエレメント内で、各埋め込まれた方法もまたエレメントとなり、その内容は方法を呼び起こすことにより戻された値である。もしそれがオブジェクトまたはオブジェクトの配列であると、これらは交互に歩かれる。
【００７１】
図６は、図５のフレームワーク上に構築された特定のアプリケーションの概略図である。このアプリケーションは、ＸＭＬドキュメント６００を取り込み、これをパーサ／発生器（構文解析ルーチン発生システム）６０１に適用する。ＥＳＩＳイベント６０２が発生され、且つ属性発生器６０３及びツリービルダー６０４に供給される。属性発生器は図５の発生器に対応する。この発生器５０５は、イベントを、例えば、ＸＭＬ入力からＨＴＭＬ出力に翻訳するための“アーキテクチャー”５０５Ｂに送る。これらのイベントは、ブロック６０５によって示される様に並列で処理され、且つリスナーによって処理される。リスナーの出力はドキュメントライター６０６に供給され、出力のためにＸＭＬフォーマットに戻し翻訳される。従って、例えば、図６に示されるこのアプリケーションは、ＸＭＬドキュメントを取り入れ、或るフォームを有するＨＴＭＬドキュメントを出力する。このフォームは次にブラウザに送られ、その結果がＸＭＬに戻し変換される。この運用のために、アーキテクチャコンセプトは、ＸＭＬからＨＴＭＬへのマッピングを提供する。図６に含まれる３つのアーキテクチャーは、テーブル及びリストの様なＨＴＭＬドキュメントの構造を与えるためのもの、ブラウザドキュメント上の入力フィールド用のラベルの様な表示されるべきドキュメントを特定する第２のもの、及び入力フィールド自体を記述する第３のものを含む。ＸＭＬドキュメント構造を維持するのに必要となるＸＭＬドキュメントのエレメントは、ＨＴＭＬフォーム内で不可視のフィールドとなる。このことは、サーバに送り戻されるＨＴＴＰポストメッセージにクライアントが入れる情報からＸＭＬドキュメントを再構成する際に使用するのに有用である。これらのイベントを聴取するリスナーが、ＨＴＭＬドキュメント用のイベントを出力する。このドキュメントは、ドキュメントライターオブジェクトへ行く。ドキュメントライターオブジェクトはＸＭＬイベントを聴取し、それらをＸＭＬドキュメントに戻す。ドキュメントライターオブジェクトは、この例におけるアーキテクチャーを聴取している全てのエレメント発生器に対するリスナーである。
【００７２】
図５及び６に図示される処理モジュールの構成は、図３のシステム用のパーサ及びトランザクションプロセスフロントエンドの或る実施の形態を表している。理解できる様に、極めて柔軟性のあるインタフェースが与えられ、これによってダイバース（変更）トランザクションプロセスを、入力するＸＭＬドキュメント、又は他の構造化ドキュメントフォーマットに応答して、実行することができる。
【００７３】
図７は、ビジネスインタフェース定義ビルダーモジュール７００を含むことを除いて図３と類似のノードを図示している。従って、図７のシステムは、ネットワークインタフェース７０１、ドキュメントパーサ７０２、及びドキュメントトランスレータ７０３を含む。トランスレータ７０３は、その出力をトランザクション処理フロントエンド７０４へ出力する。このフロントエンドは、商業上の機能７０５、データベース７０６、企業機能７０７、及び他の一般リスナー及びプロセッサ７０８のようなリスニング機能に結合される。図７に図示される様に、ビジネスインタフェースビルダー７００は、ユーザインタェース、共通ビジネスライブラリＣＢＬリポジトリ、相補的ビジネスインタフェース定義をを読むためのプロセス、及びコンパイラを含む。ユーザインタフェースは、ビジネスインタフェース定義の構築における企てを、共通ビジネスライブラリリポジトリ及び相補的ビジネスインタフェースの定義を読み出す能力に依存して、補助するのに使用される。従って、相補的ビジネスインタフェースの定義の入力ドキュメントは、特定のトランザクションの出力ドキュメントとして特定することが出来、相補的ビジネスインタフェースの定義の出力ドキュメントがトランザクションプロセスの様な入力として特定することができる。同様な仕方で、トランザクションビジネスインタフェースの定義がＣＢＬレポジトリから選択された成分を使用して構成することがてきる。ＣＢＬリポジトリの使用が、上述の例示案（ｂｉｄ１）ドキュメントの様な標準化されたドキュメントフォーマット、及びネットワーク内の他の人間によって直ぐに採用することの出来るビジネスインタフェースの定義の構築に於ける論理構造及び解釈情報の使用を促進する。
【００７４】
ビジネスインタフェース定義ビルダー７００は、トランスレータ７０３、ホストトランザクション処理アーキテクチャに従ってトランスレータによって処理されるべきオブジェクトを発生し、パーシング機能７０２を管理するために使用されるコンパイラーも含む。
【００７５】
図８は、ビジネスインタフェース定義ビルダー７００内のリポジトリ内に記憶される論理構造を示す発見的図式である。従って、パーティビジネスインタフェース定義８００を表すリポジトリ記憶は、例えば、消費者ＢＩＤ８０１、カタログハウスＢＩＤ８０２、ウェアハウスＢＩＤ８０３、及びアクションハウスＢＩＤ８０４を含む。従って、オンラインマーケットにおける新たな参加者は、そのビジネスと最もよく適合する標準化されたＢＩＤの一つを、ベーシックインタフェース定義として、選択する。更に、リポジトリは一組のサービスビジネスインタフェース定義８０５を記憶する。例えば、注文エントリＢＴＤ８０６、注文トラッキングＢＩＤ８０７、注文履行ＢＩＤ８０８、及びカタログサービスＢＩＤ８０９を記憶することができる。マーケットにおける新たな参加者がビジネスインタフェースの定義を構築する際に、リポジトリ内に記憶される標準化されたサービスのビジネスインタフェース定義を選択することができる。
【００７６】
パーティ及びサービスＢＩＤに加えて、入力及び出力ドキュメントＢＩＤが、フィールド８１０によって指示されるリポジトリに記憶される。従って、購入注文ＢＩＤ８１１、請求書ＢＩＤ８１２、見積り要求ＢＩＤ８１３、製品入手可能リポートＢＩＤ８１４、及び注文状態ＢＩＤ８１５をリポジトリに記憶することが出来る。
【００７７】
リポジトリは、好適なシステムにおいては、ＸＭＬに従ったドキュメント形態の定義として特定されるビジネスインタフェースの定義に加えて、フィールド８１６によって指示される様なセマンティックマップの形態で解釈情報を記憶する。従って、重量８１７、通貨８１８、サイズ８１９、製品識別８２０、及び製品特徴８２１を特定するために使用されるセマンティックマップをリポジトリ内に記憶することができる。更に、解釈情報は、ドキュメントの論理構造内のデータ構造を分類分けすることに備える。
【００７８】
更に、ビジネスインタフェースの定義を構成する際に使用される論理構造は、ブロック８２２によって指摘されるリポジトリに記憶される。従って、アドレス情報８２３を与えるためのフォーム、価格情報８２４を与えるためのフォーム、契約上関係の期間８２５を与えるためのフォームを提供することができる。ネットワークが拡張される時、ＣＢＬリポジトリも同様に拡張し、標準化は、新たな参加者が加わること及びビジネスインタフェースの定義をより容易にする。
【００７９】
図９は、図７のシステムを使用するビジネスインタフェース定義を構築するプロセスを図示している。プロセスは、ＢＩＤビルダーグラフィカルインタフェースをユーザに表示することによって開始される（ステップ９００）。システムは、グラフィカルインタフェース（ステップ９０１）によって発生された参加者、サービス及びドキュメント情報を識別するユーザ入力を受け入れる。
【００８０】
次に、如何なる参照論理構造、解釈情報、ドキュメント定義、及び／又はサービス定義は、ユーザ入力に応答してグラフィカルユーザーインタフェースを介してリポジトリから検索される（ステップ９０２）。次のステップで、相補的ビジネスインタフェース定義又はビジネスインタフェースの定義の成分が、カスタム化された検索エンジン、ウェブブラウザ、又は他の方法によって、ユーザー入力を介して選択されたネットワーク内の他の参加者からアクセスされる（ステップ９０３）。参加者に対するドキュメントの定義は、集められた情報を使用して発生される（ステップ９０４）。ドキュメントからホストへ及びホストからドキュメントへの各マッパーに対するトランスレータが、コンパイラによって発生される（ステップ９０５）。定義に対応するホストアーキテクチャデータ構造はコンパイラによって発生される（ステップ９０６）。そして発生されたビジネスインタフェースの定義は、ウェブサイト又は他の場所にポスト送付することにより、ネットワーク上にポスト送付され、ネットワーク内の他のノードにアクセス可能となるされる。（ステップ９０７）。
【００８１】
ビジネスインタフェースの定義は潜在的な商業パートナーに対して会社がオファーしたオンラインサービスを告げ、且つこれらのサービスを実施するのに使用するドキュメントを告げる。従って、サービスは、サービスが受け取り且つ発生するドキュメントによってビジネスインタフェースの定義で定められる。このことは、ＸＭＬサービスの定義の以下のフラグメントに例示されている。
【００８２】
2008084328.tif 000022
2008084328.tif 000023
【００８３】
このＸＭＬフラグメント（ｆｒａｇｍｅｎｔ）は、２つの処理からなるサービス、すなわち、１つは注文（ｏｒｄｅｒ）を取得する処理及びもう１つはそれに追従する処理を定義する。それぞれの定義は、もし正当な要求が特定のＷｅｂアドレスに提示されたなら、サービスを実行するための契約（ｃｏｎｔｒａｃｔ）又は約束（ｐｒｏｍｉｓｅ）を表現する。ここで注文サービスは、ローカルであるか、あるいはネットワーク上の産業全体のレジストリ中に記憶されたものでよいリポジトリ（ｒｅｐｏｓｉｔｏｒｙ）中に置かれている、標準の「ｐｏ．ｄｔｄ」ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）に適合する、入力されるドキュメント（ｄｏｃｕｍｅｎｔ）を必要とする。もし１つのノードがその注文を実行できるなら、そのノードは、定義がローカルである、カスタマイズされた「ｉｎｖｏｉｃｅ．ｄｔｄ」に適合するドキュメントを返すであろう。実際には、会社は、それが宣言するＸＭＬ仕様に適合する購入注文を提出できる誰とでも、ビジネスを行う約束をしている。事前の調整は不要である。
【００８４】
ＤＴＤは、所定の型のドキュメントのための公式の仕様すなわち文法であり、それは、要素、それらの属性、及びそれらが表示されなければならない状態を記述する。例えば、購入注文は、購入者及び販売者の名前及び住所、一組の製品説明、及び価格及び配達日のような関連する売買条件を典型的には含む。エレクトロニック・データ・インターチェンジ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ，ＥＤＩ）では、例えばＸ１２  ８５０仕様は、購入注文のために普通に使用されるモデルである。
【００８５】
リポジトリによって、多くのビジネス領域で共通の、再使用可能な意味の成分（ｒｅｕｓａｂｌｅ  ｓｅｍａｎｔｉｃ  ｃｏｍｐｏｎｅｎｔｓ）から、ＸＭＬドキュメントモデルを開発することが促進される。そのようなドキュメントは、たとえそれらの見かけが全く異なっていたとしても、それらの共通のメッセージ要素から理解することができる。これは、コモン・ビジネス・ライブラリ・リポジトリ（Ｃｏｍｍｏｎ  Ｂｕｓｉｎｅｓｓ  Ｌｉｂｒａｒｙ  ｒｅｐｏｓｉｔｏｒｙ）の役割である。
【００８６】
コモン・ビジネス・ライブラリ・リポジトリは、以下を含む、一般的なビジネス概念のための情報モデルからなる。
・会社、サービス、及び製品のような、ビジネス記述プリミティブ（ｂｕｓｉｎｅｓｓ  ｄｅｓｃｒｉｐｔｉｏｎ  ｐｒｉｍｉｔｉｖｅ）、
・カタログ、購入注文、及びインボイスのようなビジネス形態、
・標準の測定値（ｓｔａｎｄａｒｄ  ｍｅａｓｕｒｅｍｅｎｔｓ）、日時、位置、分類コード、である。
【００８７】
この情報は、会社がＸＭＬアプリケーションを迅速に開発するためにカスタマイズしかつ組み立てることができる、拡張可能で公開されたＸＭＬ構成ブロック（ＸＭＬ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）として表現される。微少の（ａｔｏｍｉｃ）ＣＢＬ要素は、国、通貨、住所（ａｄｄｒｅｓｓ）、及び時間のための標準ＩＳＯコードのような、産業界のメッセージング規格及び慣習（ｉｎｄｕｓｔｒｙ  ｍｅｓｓａｇｉｎｇ  ｓｔａｎｄａｒｄｓ  ａｎｄ  ｃｏｎｖｅｎｔｉｏｎｓ）を実行する。低レベルのＣＢＬセマンティクス（ｓｅｍａｎｔｉｃｓ）は、ダブリン・コア（Ｄｕｂｌｉｎ  Ｃｏｒｅ）のような、インターネット・リソースのための、提示されたメタデータ構成（ｍｅｔａｄａｔａ  ｆｒａｍｅｗｏｒｋ）の分析からも得られる。
【００８８】
次のレベルの要素は、これらの構成ブロックを使用して、ＯＴＰ（Ｏｐｅｎ  Ｔｒａｄｉｎｇ  Ｐｒｏｔｏｃｏｌ）及びＯＢＩ（Ｏｐｅｎ  Ｂｕｙｉｎｇ  ｏｎ  ｔｈｅ  Ｉｎｔｅｒｎｅｔ）のような、出現したインターネット規格で使用されるビジネス形態だけでなく、Ｘ１２  ＥＤＩ処理で使用されるもののような基本的なビジネス形態も実行する。
【００８９】
ＣＢＬの主眼は、全てのビジネス領域（会社、サービス、及び製品のような、ビジネス記述プリミティブ；カタログ、購入注文、及びインボイスのようなビジネス形態；標準の測定値、日時、位置、分類コード）に共通の機能及び情報にある。ＣＢＬは、可能な場合の意味論のための規格又は産業界の慣習に依存している（例えば、ヨーロッパでの「日／月／年」に対してアメリカでの「月／日／年」を指定する規則は、別個のＣＢＬモジュール中にコード化される）。
【００９０】
ＣＢＬは、アプリケーションを設計するために使用される言語である。それは、ＸＭＬの「ドキュメント・ワールド」と、ＪＡＶＡの「プログラミング・ワールド」又は他の処理プロセスアーキテクチャとの間のギャップを橋渡しするように設計されている。スキーマ（ｓｃｈｅｍａ）は、ドキュメントタイプの詳細な公式の仕様が種々の関連する形態がそこから生成されるようなマスター・ソース（ｍａｓｔｅｒ  ｓｏｕｒｃｅ）である、「ドキュメントによるプログラミング」の思想を具体化する。これらの形態は、ＣＢＬ、ＪＡＶＡオブジェクト、ＸＭＬのインスタンスと対応するＪＡＶＡオブジェクトとの間の変換プログラム、及びサポート・ドキュメントのためのＸＭＬ  ＤＴＤを含む。
【００９１】
ＣＢＬは、そこからシステムのほとんど全ての部分が自動的にコンパイラによって生成されるような単一のソースを作り出す。ＣＢＬは、それぞれの情報の要素及び属性と関連するセマンティクスの仕様を含むように、特定のドキュメントタイプの構造を公式に定義するために通常使用されるＳＧＭＬ／ＸＭＬを拡張することによって機能する。ＳＧＭＬ／ＸＭＬでの（ほとんどの）限られた組のキャラクタタイプを、任意の種類のデータタイプを宣言するために拡張することができる。
【００９２】
これは、「ｄａｔｅｔｉｍｅ」モジュールのためのＣＢＬ定義からのフラグメントである。
2008084328.tif 000024
2008084328.tif 000025
【００９３】
このフラグメントでは、ＥＬＥＭＥＮＴ”ｙｅａｒ”は、キャラクタデータ及び関連する”ｓｃｈｅｍａ”属性として定義され、キャラクタデータも、ＩＳＯ８６０１規格のセクション３．８になるように”ｙｅａｒ”のためのスキーマを定義する。
【００９４】
この”ｄａｔｅｔｉｍｅ”ＣＢＬモジュールは、実際は、スキーマＤＴＤのインスタンスとして定義される。最初に、モジュール名が定義される。次に、”ｄａｔｅｔｉｍｅ”要素の”ＹＥＡＲ”は、ＩＳＯ８６０１規格のセマンティクスに結合させられる。
【００９５】
2008084328.tif 000026
2008084328.tif 000027
【００９６】
例のマーケットの参加者及び上記のサービスモジュールも、ＣＢＬリポジトリ中に記憶される。
【００９７】
図１０では、航空貨物受取証（Ａｉｒｂｉｌｌ）１０００が、一般的な購入注文ＤＴＤ１００１をカスタマイズし、出荷重量１００２についてのより具体的な情報を追加することによって定義されているところである。一般的な購入注文１００１は、住所、日時、通貨、及び販売者及び製品説明のためのＣＢＬモジュールから、広範囲にわたって、最初に組み立てられた。このように、ＣＢＬを使用することにより、ＸＭＬ商用アプリケーションのインプリメンテーションはかなり促進される。より重要なことに、ＣＢＬによって、商用アプリケーションを相互接続することが簡単になる。
【００９８】
ＣＢＬでは、ＸＭＬはスキーマにより拡張される。拡張によって、内容を簡単に確認できるように、ＸＭＬ要素に強調タイピング（ｓｔｒｏｎｇ−ｔｙｐｉｎｇ）が追加される。例えば、＜ＣＰＵ ｃｌｏｃｋ ｓｐｅｅｄ＞と呼ばれる要素は、一組の正当な値（ｖａｌｉｄ  ｖａｌｕｅ）：｛１００，１３３，１６６，２００，２３３，２６６  Ｍｈｚ｝を有する整数として定義されることができる。スキーマは、情報をクラスの定義から簡単にインスタンス生成することができるように、クラス−サブクラスの階層も追加する。例えば、ラップトップを、ディスプレイのタイプ及びバッテリの寿命のような特徴のための追加のタグを有するコンピュータとして記述することができる。これら及び他の拡張により、ＸＭＬと伝統的なオブジェクト指向及び関係データモデルの間の自動翻訳だけでなく、データ入力も容易になる。
【００９９】
このようにして、完成されたＢＴＤは、参加者及び上記に概説したサービスの実際のインスタンス、ＤＴＤインスタンスの論理的構造に対応するＪＡＶＡビーンズ（ｂｅａｎｓ）、及びＸＭＬからＪＡＶＡに及びＪＡＶＡからＸＭＬに変換する変換コードのためのＤＴＤを作り出すコンパイラを通して実行される。他のシステムでは、オブジェクトを使用しやすくするために、ドキュメントも、ユーザインターフェース上のディスプレイのために、又はユーザによる印刷のために生成される。
【０１００】
例えば、市場参加者及び前述のサービスＤＴＤ、コンパイラによって生成されたＪＡＶＡビーンズは、（簡潔のためいくつかの修正を加えて）以下のように示される。
2008084328.tif 000028
2008084328.tif 000029
2008084328.tif 000030
2008084328.tif 000031
2008084328.tif 000032
2008084328.tif 000033
2008084328.tif 000034
2008084328.tif 000035
2008084328.tif 000036
2008084328.tif 000037
2008084328.tif 000038
2008084328.tif 000039
2008084328.tif 000040
2008084328.tif 000041
2008084328.tif 000042
2008084328.tif 000043
2008084328.tif 000044
2008084328.tif 000045
2008084328.tif 000046
2008084328.tif 000047
2008084328.tif 000048
2008084328.tif 000049
2008084328.tif 000050
2008084328.tif 000051
2008084328.tif 000052
2008084328.tif 000053
2008084328.tif 000054
2008084328.tif 000055
2008084328.tif 000056
2008084328.tif 000057
2008084328.tif 000058
2008084328.tif 000059
2008084328.tif 000060
2008084328.tif 000061
2008084328.tif 000062
2008084328.tif 000063
2008084328.tif 000064
2008084328.tif 000065
2008084328.tif 000066
2008084328.tif 000067
2008084328.tif 000068
2008084328.tif 000069
2008084328.tif 000070
2008084328.tif 000071
2008084328.tif 000072
上記したＪＡＶＡビーンに加えて、変換コードは以下に示されているように、ＪＡＶＡからＸＭＬへ、及びＸＭＬからＪＡＶＡへ翻訳するため作られる。
2008084328.tif 000073
2008084328.tif 000074
2008084328.tif 000075
2008084328.tif 000076
2008084328.tif 000077
2008084328.tif 000078
2008084328.tif 000079
2008084328.tif 000080
2008084328.tif 000081
2008084328.tif 000082
2008084328.tif 000083
2008084328.tif 000084
【０１０１】
ドラッグ、ドロップ及び形を編集するユーサインターフェースを提供する、ＢＩＤコンポーザ（ｃｏｍｐｏｓｅｒ）アプリケーションと一緒にツールを使用して、開発者は、ビジネスインターフェースの定義を作り出すことができ、及び、良好に形成された、有効なビジネスインターフェースの定義をＸＭＬドキュメントの形態で生産することができる。このように、例のランタイム・インスタンスは、ＩＢＭからラップトップコンピュータを注文するために、イングラム・マイクロ（Ｉｎｇｒａｍ  Ｍｉｃｒｏ）によって使用される、ＩＢＭのためのサービスを注文するためのビジネスインターフェースの定義である。（出願人と、ＩＢＭ又はイングラム・マイクロの間には関係はない。）これらのプロセスを利用すると、ユーザは、本発明に従って定義されたドキュメントを使用して、ビジネスインターフェースのプログラムができるシステムを構築することができる。
【０１０２】
ＸＭＬ／ＪＡＶＡ環境における本発明のＣＢＬ及びＢＩＤプロセッサの役割は購入注文の処理の以下の説明によりさらに理解できるであろう。
【０１０３】
会社ＡはＣＢＬ  ＤＴＤ及びモジュールのライブラリを含む視覚プログラム環境を使用するその購入注文ドキュメントを定義し、全ては共通のビジネス言語エレメントを使用して定義され、それらがデータタイプ及び他の翻訳情報を含むようになっている。会社ＡのＰＯはＣＢＬライブラリに付属しているより一般的なトランザクションドキュメント仕様に対してマイナなカスタマイゼイションを含むかもしれないし、或いは、アドレス、データ及び時間、電流等のためＣＢＬモジュールからのグランドから作られるかもしれない。
【０１０４】
（上記したｔｒａｎｓａｃｔ．ｄｔｄのような）一般的なトランザクションドキュメント仕様のドキュメントはＣＢＬ仕様がモジュールから作られ、他のＣＢＬ  ＤＴＤと連結される方法を類型化する。
【０１０５】
コンパイラは購入注文の定義を取り、幾つかの異なるターゲット形式を発生する。これらのターゲット形式のすべては元の仕様の「ツリーツーツリー（ｔｒｅｅ  ｔｏ  ｔｒｅｅ）」変形を介して得ることができる。この例にとって最も重要なのは、
（ａ）購入注文のためのＸＭＬ  ＤＴＤ
（ｂ）購入注文のためのデータ構造を含むＪＡＶＡビーン（Ｂｅａｎ）（ＪＡＶＡクラス、引数、データタイプ、方法、及び例外構造は購入注文のスキーマ定義の情報に対応して作り出される。）
（ｃ）購入注文ＤＴＤに従う購入注文を購入注文ＪＡＶＡビーンに変換し、又は、それらをデータベースにロードし、又は、ブラウザに購入注文を表示するためＨＴＭＬ（又はＸＳＬスタイル集）を作り出す整列プログラム
（ｄ）購入注文ＪＡＶＡビーンからデータ値を引き出し、それらを購入注文ＤＴＤに従うＸＭＬドキュメントに変換する整列しないプログラム
今、シナリオに戻ると、購入の申し込みは購入注文を発生し、該購入注文は購入注文を受け入れる供給者のためのサービスインターフェースとして明記されたＤＴＤに従う。
【０１０６】
パーサは購入注文ＤＴＤを使用し、エレメント及びそれが含む属性値についての情報ストリームへの購入注文インスタンスを分解する。その後、これらのプロパティセットはそれらをＪＡＶＡコードと重ねることにより対応するＪＡＶＡイベントオブジェクトに変換される。事実上、この変換は文法がＤＴＤにより定義される顧客プログラム言語の命令として印を付けたＸＭＬドキュメントの部分を処理する。これらのＪＡＶＡイベントはコンパイラにより生成された整列しているアプリケーションにより処理され、ＪＡＶＡビーンのデータ構造をロードすることができる。
【０１０７】
ＸＭＬドキュメントをＪＡＶＡアプリケーションのための１セットのイベントに変換し、処理することは、解析をする正常なモデルとは異なり、解析が完了するまで内部データ構造及び処理は開始しないので、パーサ出力は維持される。ＢＩＤ定義に応じたイベントベースの処理は、最初のイベントが発せられると直ぐに同時に発生のドキュメントアプリケーション処理を始めさせるので、、プロセッサの非常に優れた機能を可能にする鍵である。
【０１０８】
各種タイプのイベントに聞くＪＡＶＡプログラムはそれらのイベントのスキーマ定義から形成される。これらのリスナーはＣＢＬのＸＭＬ定義と関連するビジネス論理を実行するために作り出されたプログラムであり、例えば、アドレスエレメントと関連し、データベースをチェックすることにより郵便番号を確認するコードであってもよい。これらのリスナーはドキュメントルータで登録することによりイベントに応募し、それらに興味を示したすべての応募者に関連したイベントを割り当てる。
【０１０９】
新規のリスナーがプログラムするこの公表し、応募したアーキテクチャ手段は現存のものの知識なしに、またはそれに影響を与えることなく付加されることができる。各リスナーはルータがそのイベントを割り当てるキューを有し、複数のリスナーはそれら自身のペースで並行してイベントを取扱うことができる。
【０１１０】
ここの例示の購入注文にとって、
・注文入力プログラムにそれをつなげるであろう購入注文
・在庫をチェックするであろう製品説明書
・Ｆｅｄ  Ｅｘ又は引き渡しの有効性のための他のサービスをチェックすることができるであろうアドレス情報
・（信用貸しの価値のため、又は公告を提供するため、又は顧客が誰であるかを知ることに基づく同様の処理のため）注文の履歴をチェックすることができるであろう買い手の情報
のためのリスナーであるかもしれない。
【０１１１】
複合したリスナーは初期のものの形状として作り出されることができる。（例えば、購入注文のリスナーがここのこれらのリスナーを含み、引き合いに出してもよく、又は、それらはそれら自身で引き合いに出されてもよい。）
【０１１２】
図１１は図１のネットワークでのマーケットマーカのノードを示している。マーケットマーカのノードは図３のシステムの基本構造を含み、ネットワークインターフェース１１０１、ドキュメントパーサ１１０２、ホストへのドキュメント及びドキュメント翻訳機へのホスト１１０３、フロントエンド１１０４を有し、この例ではルータと呼ばれている。この例でのマーケットマーカモジュール１１０５は１セットのビジネスインターフェース定義、又はマーケットの参加者のためマーケットマーカの機能を支援するのに十分な他の識別子、ＣＢＬリポジトリ、及びマーケットの参加者の要求をすべて満たすコンパイラを備えている。ルータ１１０４は参加者のレジストリ及びドキュメントフィルタを備え、翻訳機の出力でパーサにより生成されたイベントに応答し、参加者のレジストリにより、及びＸＭＬイベント発生器に対するリスナーの間のエレメント及び属性フィルタにより、入力ドキュメントの経路を定める。したがって、マーケットの一定の参加者は登録し、予め特定したパラメータに合うドキュメントを受け取ってもよい。
例えば、特定のＤＴＤによる入力ドキュメントは、閾値以上の購入製品数、又は購入されるドキュメント要求の最大価格等の属性を含み、ルータ１１０４でフィルタドキュメントに使用されることができる。その後、ルータ１１０４で参加者のレジストリに登録された情報に合致するようなドキュメントは登録された参加者に送られる。
【０１１３】
ルータ１１０４はまたローカルホストサービス１１０５及び１１０６の要求を満たし、例えば、マーケットマーカと同様にマーケットの参加者のように作動する。通常、ルータ１１０４により受け取られたドキュメントはトラバースされ、宛先を決定し、そのようなドキュメントは送られ、そこで再度、翻訳機１１０３を介して、必要であれば、ネットワークインターフェース１１０１からそれぞれの宛先に送られる。
【０１１４】
マーケットマーカは１セットの内部及び外部のビジネスサービスと一緒に結び付けるサーバであり、仮想の計画又はトレーディングコミュニティを作り出す。
サーバは入力ドキュメントを解析し、例えば、製品データのためのリクエストをカタログサーバに渡すことにより、又は、購入注文をＥＲＰシステムに送ることにより、適当なサービスを引き合いに出す。サーバはまた翻訳タスクを取扱い、トレーディングパートナにより使用されるドキュメント書式及びそのレガシーシステムにより要求されるデータ書式に会社のＸＭＬドキュメントからの情報をマッピングする。
【０１１５】
上記サービスの定義に関して、会社が購入注文を提示したとき、サーバのＸＭＬパーサは購入注文ＤＴＤを使用し、購入注文インスタンスを情報イベントのストリームに変換する。その後、これらのイベントは所定のタイプのイベントを取扱うためにプログラムされたアプリケーションに送られ、幾つかの場合には、情報はインターネットを介して異なるビジネスに完全に送られる。購入注文の例では、幾つかのアプリケーションはパーサから来る情報で作動してもよい。
・注文入力プログラムは完全なメッセージとして購入を処理する。
・ＥＲＰシステムは購入注文に記述された製品のための在庫をチェックする。
・顧客データベースは顧客のアドレスを証明し、又は更新する。
・運送会社はアドレス情報を使用し、搬送をスケジュールする。
・銀行はクレジットカードを使用し、トランザクションを許可する。
【０１１６】
トレーディングパートナーは、彼らが交換するビジネスドキュメントの構造、内容及び順序について同意するだけでよく、ＡＰＩの詳細について同意する必要はない。ドキュメントがどのように処理されるか及びどのようなアクション結果が生じるかは、厳密にサービスを提供するビジネス次第である。これは、システムレベルからビジネスレベルへの統合を高める。それは、ビジネスが、その内部技術の履行、組織化、又はプロセスにおける変更にもかかわらず、明瞭で安定なインターフェイスをそのビジネスパートナーに提供することを可能にする。
【０１１７】
図１２、１３及び１４は、図１１のシステムのマーケットメーカーノードにおいて実行されるプロセスを示している。図１２において、入力ドキュメントが、発信参加者ノードからのネットワークインターフェイスにおいて受け取られる（ステップ１２００）。ドキュメントがパースされる（ステップ１２０１）。ドキュメントが、ホストのフォーマットへ、例えば、ＸＭＬからＪＡＶＡへ変換される（ステップ１２０２）。ホストフォーマット化されたイベント及びオブジェクトが、その後、ルータサービスへ送られる（ステップ１２０３）。ドキュメントのタイプ及びドキュメントの内容に従ってドキュメントを受け入れるように記憶されたサービスが識別される（ステップ１２０４）。ドキュメント及びドキュメントの一部が、識別されたサービスに送られる（ステップ１２０５）。ドキュメントの内容に応じてサービスが実行される（ステップ１２０６）。サービスの出力データが発生される（ステップ１２０７）。出力が、ドキュメントフォーマットへ、例えば、ＪＡＶＡフォーマットからＸＭＬフォーマットへ変換される（ステップ１２０８）。最後に、出力ドキュメントが参加者ノードへ送られる（ステップ１２０９）。
【０１１８】
レジストレーションサービスは、ルータにより管理されるそのような機能の一つである。従って、マーケット参加者ドキュメントが図１３に示されるネットワークインターフェイスにおいて受け入れられる（ステップ１３００）。マーケット参加者ドキュメントがマーケットメーカーノードについてのビジネスインターフェイス定義リポジトリに記憶される（ステップ１３０１）。加えて、ドキュメントがパースされる（ステップ１３０２）。パースされたドキュメントが、ホストのフォーマットへ変換される（ステップ１３０３）。次に、ドキュメントがルータサービスへ送られる（ステップ１３０４）。ルータサービスは、レジストレーションサービスをドキュメントのタイプ及びドキュメントの内容に従ってドキュメントの宛先であると識別するリスナーを含む（ステップ１３０５）。ドキュメント及びドキュメントのエレメントが、レジストレーションサービスに送られる（ステップ１３０６）。レジストレーションサービスにおいて、必要とされるサービス仕様がビジネスインターフェイス定義に応じてリトリーブされる（ステップ１３０７）。ステップ１３０８において、サービス仕様が集められる場合には、ビジネスインターフェイス定義及びサービス仕様に従ってルータサービスフィルタがセットされる（ステップ１３０９）。レジストレーションアクノリッジメントデータが発生される（ステップ１３１０）。レジストレーションアクノリッジメントデータが、ドキュメントフォーマットへ変換される（ステップ１３１１）。最後に、アクノリッジメントドキュメントが参加者ノードへ送られてマーケットメーカーで成功裏にレジスタされた参加者に通知する（ステップ１３１２）。
【０１１９】
必要とされるサービス仕様を集めるステップ１３０７におけるプロセスは、図１４の１つの例について示されている。このプロセスは、マーケット参加者によりサポートされるサービスビジネスインターフェイス定義を探し出すことにより始まる（ステップ１４００）。サービス定義が例えば、リポジトリノードへのＥメールトランザクション又はウェブアクセスによりリトリーブされる（ステップ１４０１）。サービス仕様がＢＩＤリポジトリに記憶される（ステップ１４０２）。サービスビジネスインターフェイス定義ドキュメントがパースされる（ステップ１４０３）。パースされたドキュメントが、ホストのフォーマットへ変換される（ステップ１４０４）。次に、ホストのオブジェクトがルータサービスへ送られる（ステップ１４０５）。レジストレーションサービスがドキュメントのタイプ及び内容に従って識別される（ステップ１４０６）。最後に、サービスビジネスインターフェイス定義ドキュメントの情報がレジストレーションサービスに送られて（ステップ１４０７）、図１３のプロセスに従って使用される。
【０１２０】
図１５は、本発明に従ってマーケットメーカーノードに入力するデータを処理するプロセッサ、コンポーネント及びシーケンスを示している。マーケットメーカーノードは、ネットワークインターフェイスにおいて通信エージェント１５００を有する。通信エージェントはＸＭＬパーサ１５０１と接続され、ＸＭＬパーサ１５０１は、イベントをＸＭＬプロセッサ１５０２に供給する。ＸＭＬプロセッサ１５０２は、イベントをドキュメントルータに供給する。ドキュメントルータは、ドキュメントサービス１５０４にフィードし、ドキュメントサービス１５０４は、受け取ったドキュメントをホストシステムのエンタープライズソルーションソフトウェア１５０５に供給するインターフェイスとなる。通信エージェント１５００は、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ又は他のプロトコルのようなプロトコルを支持する適当なプロトコルスタックを有するインターネットインターフェイスである。従って、入力するデータは、特定の通信チャンネルに適合するようにＸＭＬ構文法、ＡＳＣＩＩデータ構文法又は他の構文法で入力してもよい。非ＸＭＬ構文法で受け取ったドキュメントは全てＸＭＬに変換されてＸＭＬパーサに送られる。非ＸＭＬ形式からＸＭＬ形式への変換をサポートするために変換テーブル１５０６が使用される。
【０１２１】
変換されたドキュメントはパーサ１５０１に供給される。ＸＭＬパーサは、受け取ったＸＭＬドキュメントを、それとマッチするドキュメントタイプ定義に従ってパースする。エラーが見つかった場合には、パーサがドキュメントを通信エージェント１５００へ送り返す。ビジネスインターフェイス定義コンパイラＢＩＤＣ１５０７は、ビジネスインターフェイス定義データのためのコンパイラとして働く。ＸＭＬパーサのためのＤＴＤファイル、ＤＴＤファイルに対応するＪＡＶＡビーンズ及びＤＴＤファイルをＪＡＶＡビーンズへ変換する変換ルールは、ＢＩＤデータをコンパイルすることにより作られる。これらのツールを参照することにより、ＸＭＬインスタンスがＪＡＶＡインスタンスへ変換される。そこで、ＢＩＤコンパイラ１５０７は、ＤＴＤドキュメント１５０８を記憶して１５０９に対応するＪＡＶＡドキュメントを発生する。ＸＭＬドキュメントはプロセッサ１５０２に送られ、プロセッサ１５０２は、そのドキュメントをＪＡＶＡフォーマットに変換する。好ましいシステムでは、ＸＭＬフォーマットで受け取ったドキュメントタイプ定義と同じステータスを有するＪＡＶＡドキュメントが発生される。ＪＡＶＡビーンズがドキュメントルータ１５０３に送られる。ドキュメントルータ１５０３がＪＡＶＡビーンズを受け取り、受け取ったクラスをレジストリプログラムを使用して、例えば、上述したイベントリスナーアーキテクチャを使用して、適当なドキュメントサービスに送る。ルータ１５０３からＪＡＶＡビーンズの形式でドキュメントを受け取ったドキュメントサービス１５０４は、エンタプライズソルーションソフトウェアとして働く。これは、ＸＭＬイベントのリスナーを入力するデータ流れと結合するレジストリサービス１５１０と、入力するドキュメントの適当なサービスへのルーティングを管理するサービスマネージャ１５１１とを有する。ドキュメントサービスマネージャ１５１１は、レジストリサービスの管理及びドキュメントの一貫性の維持等を行う。
【０１２２】
ドキュメントサービスは、任意のプロプラエタリＡＰＩを使用して、又は、ＣＯＲＢＡ／ＣＯＭインターフェイスその他のアーキテクチャのようなより共通な形式を使用してバックエンドシステムと通信する。
【０１２３】
図１６は、本発明に係るマーケットメーカー及びマーケット参加者構造のヒューリスティックダイアグラムである。従って、本発明に係るＥコマーストランザクションマーケットは、図１６に示されているように論理的に組織化できる。その組織の最上部において、マーケットメーカーノード１６００が設定される。マーケットメーカーノードは、マーケットプレイス１６０１を設定するリソースを含む。このようなリソースは、マーケットレジストリサービス等を含む。ビジネス１６０２は、ビジネスインターフェイス定義をパブリッシュすることによりマーケットプレイスにレジスタする。ビジネスインターフェイス定義は、ビジネスが参加するコマーシャルトランザクションについてサービス１６０３を定義する。トランザクション１６０４及びサービス１６０３は、ドキュメント１６０５を使用して入力及び出力を定め、トランザクションにおける参加者の間の商業上の関係をアウトラインする。ドキュメントは各トランザクションの詳細を含むコンテント１６０６を有する。コンテントがマーケットの参加者により及びマーケットメーカーにより処理される方法は、本発明に従って設立されるＥコマーストランザクションネットワークに基づくドキュメントに完全に依存する。全体として、通信ネットワーク上でＥコマーストランザクション可能とするように頑強性、拡張性及び直観力に富む構造が提供される。
【０１２４】
従って、本発明は、例示のシステムにおいて、ＸＭＬプロセッサに基づくプラットフォームを提供し、疎結合されたビジネスシステムの間のインターフェイスとしてＸＭＬドキュメントを使用している。ドキュメントは、ビジネスの間で転送され、会社のビジネスシステムに入る前に特定のノードによって処理される。
従って、プラットフォームは、各ビジネスシステムが異なる内部コマースプラットフォーム、処理及び意味論を使用している場合に、共通の組のビジネスドキュメント及び形式を特定することによりビジネス間のＥコマースアプリケーションを可能にする。
【０１２５】
本発明によれば、ビジネスシステムとサービスを相互接続することによりバーチャルエンタプライズが形成され、主に、ビジネスが受け入れて発生するドキュメント（ＸＭＬコード化された）に間して次のとおり定義される。
「貴社が当社にカタログを請求される場合には、貴社にカタログを送ります。」「貴社が購入の注文をされ当社がそれを受け入れことができる場合には、貴社に送り状を送ります。」
上述した本発明の好ましい実施例の説明は、本発明の解説するためになされたものである。これは、包括的であること又は発明を開示した厳密な形式に限定することを意図するものではない。当業者にとって多くの修正及び変更は明らかである。本発明の範囲は、以下の請求の範囲及びそれと等価なものによって定められるものである。
【図面の簡単な説明】
【０１２６】
【図１】本発明によるビジネスインタフェース定義（ＢＩＤ）を含む電子商取引ネットワークの概略図である。
【図２】本発明によるビジネスインタフェース定義ドキュメントの概略図である。
【図３】本発明によるネットワーク中の参加者ノードのためのサーバの概念的なブロックダイアグラムである。
【図４】本発明による参加者ノードで受け取られたドキュメントのプロセシングを説明するフローチャートである。
【図５】ＸＭＬベースのシステムについての構文解析プログラム及びトランザクションプロセスフロントエンドのブロックダイアグラムである。
【図６】構文解析プログラム機能のフローの概念的なダイアグラムである。
【図７】本発明によるビジネスインタフェース定義に使用されるサーバにおけるリソースの概略図である。
【図８】ビジネスインタフェース定義の構築のために使用する、本発明によるリポジトリの概略図である。
【図９】本発明によるビジネスインタフェース定義を構築するプロセスを説明するフローチャートである。
【図１０】本発明によるリポジトリの発見的概要を提供するものである。
【図１１】ビジネスインタフェース定義に基づく本発明のネットワークのためのマーケットメーカー機能を提供するサーバにおけるリソースの概略図である。
【図１２】受け取られたドキュメントのマーケットメーカーノードプロセシングのフローチャートである。
【図１３】本発明によるマーケットメーカーノードにおける参加者の登録のプロセスを説明するフローチャートである。
【図１４】図９のプロセスによるマーケットメーカーノードにおけるサービスの仕様書の提供のプロセスを説明するフローチャートである。
【図１５】本発明によるマーケットメーカーまたは参加者における操作のシーケンスを説明するダイアグラムである。
【図１６】本発明によるＢＩＤに基づく商取引ネットワークの要素の概念的なダイアグラムである。
【図１】
2008084328.tif 000085
【図２】
2008084328.tif 000086
【図３】
2008084328.tif 000087
【図４】
2008084328.tif 000088
【図５】
2008084328.tif 000089
【図６】
2008084328.tif 000090
【図７】
2008084328.tif 000091
【図８】
2008084328.tif 000092
【図９】
2008084328.tif 000093
【図１０】
2008084328.tif 000094
【図１１】
2008084328.tif 000095
【図１２】
2008084328.tif 000096
【図１３】
2008084328.tif 000097
【図１４】
2008084328.tif 000098
【図１５】
2008084328.tif 000099
【図１６】
2008084328.tif 000100
【手続補正書】
【提出日】平成19年11月2日(2007.11.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
トランザクション（ｔｒａｎｓａｃｔｉｏｎ）に関連する処理を実行する複数のノード（ｎｏｄｅｓ）を含むネットワークにおけるノード間のトランザクションのためのインターフェース（ｉｎｔｅｒｆａｃｅ）であって、
入力ドキュメント（ｄｏｃｕｍｅｎｔ）の定義及び出力ドキュメントの定義を供給する翻訳情報を含む、ネットーワークにおける少なくとも一つのノードによってアクセス可能なメモリに記録されたトランザクション処理へのインターフェースの機械可読仕様（ｍａｃｈｉｎｅ  ｒｅａｄａｂｌｅ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）であり、前記入力及び出力ドキュメントの定義は、記録装置の組の個別の記述と、及び前記記録装置の組に対する論理構造を具備する前記仕様を具備することを特徴とするインターフェース。
【手続補正書】
【提出日】平成20年1月22日(2008.1.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのバックエンドプロセッサ上で実行される少なくとも１つのオペレーションと１以上のクライアントコンピュータ(11)とをネットワークを介して接続し、且つ処理サーバ上で動作するフロントエンド・トランザクションプロセッサの部分を構築するシステムであって、
前記処理サーバ上で実行されるトランザクション処理フロントエンドモジュール(704)を構築する前記ネットワークに接続されたビルダー・サーバ(700)が、当該ビルダー・サーバで実行される、
(1)前記バックエンドプロセッサによって実行されるオペレーションを記述するとともに、記憶装置の組のデータマップ及び前記オペレーション用の入力ビジネスドキュメント(211)/出力ビジネスドキュメント(212)に用いられる前記記憶装置の論理構造の選択又は記述の指示を、前記ネットワークを介して端末から受信する当該設計ツール手段(901)と、
(2)前記ネットワークを介して前記クライアントコンピュータにアクセスするためのインタフェースを定義したインタフェース定義データ構造を生成するために、前記バックエンドプロセッサによって実行されるオペレーションの記述と、前記データマップ又は前記入力/出力ビジネスドキュメント用のデータマップに対するポインタとを組み合わせるインタフェース定義構築手段と、
(3)
(a)前記入力ビジネスドキュメントからの未体系化データに対するアクセスを提供し、且つ体系化データを前記出力ビジネスドキュメントに移動させる前記フロントエンド・トランザクションプロセッサが用いる内部用データオブジェクトクラス定義を生成するために、
(b)前記入力ビジネスドキュメントを解析し、その内容及び論理構造へのアクセスを提供する構文解析器（パーサ）を管理するために、
(c)当該ビルダー・サーバ上で実行する入力/出力トランスレータが、前記入力/出力ビジネスドキュメントを前記内部用データオブジェクトクラスに合致する内部用データオブジェクトに変換し、またこれとは逆に内部用データオブジェクトを入力/出力ビジネスドキュメントに変換し、更に前記入力トランスレータが前記構文解析器からの入力ドキュメントの内容及び論理構造を受信するよう、当該入力/出力トランスレータをアセンブルするために、
前記データマップを使用するコンパイラ手段(906)と、
(4)前記クライアントコンピュータに向けて前記インタフェース定義データ構造を送信する情報提供手段(907)と、
を含むことを特徴とするシステム。
【請求項２】
処理サーバ上で機能するプロバイダーサービスにアクセス可能な消費者端末上で動作する消費者サービスモジュールの部分を構築するシステムであって、
消費者端末上で実行するための消費者サービスモジュール(704)を構築するビルダー・サーバ(700)と、
ネットワークを介して前記消費者端末にアクセス可能なインタフェースを定義するプロバイダーサービスのインタフェース定義データ構造を構築するために組み合わされる、データマップ（DTD)或いは記憶装置のデータマップに対するポインタ及びビジネスドキュメント用の記憶装置の論理構造を記憶する少なくとも１つのディレクトリサーバー(700)を備え、
前記ビルダー・サーバ(700)が、
(1)前記処理サーバー上で実行されるべきオペレーションを選択し、且つ前記ディレクトリサーバーをアクセスすることによって、前記プロバイダーサービスのインタフェース定義データ構造に含まれる入力／出力ビジネスドキュメントのデータマップを検索する指示を、前記ネットワークを介して端末から受信する設計ツール手段(901)と、
(2)(a)体系化データを前記入力ビジネスドキュメントにもたらし、且つ前記出力ビジネスドキュメントからの未体系化データに対してのアクセスを提供する前記消費者サービスのための内部用データオブジェクトクラス定義を生成するために、
(b)前記プロバイダーサービスからの出力ビジネスドキュメントを解析し、その内容及び論理構造へのアクセスを提供する構文解析器（パーサ）を管理するために、
(c)前記消費者端末上で実行し、前記入力／出力ビジネスドキュメントを前記内部用データオブジェクトクラスに合致する内部用データオブジェクトに変換し、そして入力トランスレータによって前記構文解析器からの出力ビジネスドキュメントの内容及び論理構造を受信する入力/出力トランスレータをアセンブルするために、前記データマップを使用する相補的コンパイラ手段(906)と、
を有していることを特徴とするシステム。
【請求項３】
再使用可能なビジネスドキュメントのデータマップを記憶する少なくとも１つのリポジトリサーバを更に含み、前記設計ツール手段が前記リポジトリサーバにアクセスする端末からの指示を受け入れ、そして前記再使用可能なビジネスドキュメントの少なくとも１つを前記記憶装置の記述及び論理構造と組み合わせて、少なくとも１つの入力／出力ビジネスドキュメントを形成することを特徴とする請求項１又は２に記載のシステム。
【請求項４】
再使用可能なセマンティック(意味的な）構成要素を記憶する少なくとも１つのリポジトリサーバを更に含み、前記設計ツール手段が前記リポジトリサーバにアクセスする端末からの指示を受け入れ、そして前記再使用可能なセマンティック構成要素の少なくとも１つを前記記憶装置の記述及び論理構造と組み合わせて、少なくとも１つの入力／出力ビジネスドキュメントを形成することを特徴とする請求項１〜３の何れか１項に記載のシステム。
【請求項５】
前記ビルダー・サーバによってアクセス可能なリポジトリ記憶手段に記憶されたリポジトリを更に含み、前記設計ツール手段が前記リポジトリから得られるオペレーションインタフェース仕様で使用するための要素にアクセスし、前記リポジトリは論理構造のライブラリを記憶し、その論理構造のための解釈情報が前記オペレーションインタフェース仕様を構築するために使用される、ことを特徴とする請求項１〜４の何れか１項に記載のシステム。
【請求項６】
前記オペレーションの記述は前記オペレーションのタイトル及び概要を含む、請求項１〜５の何れか１項に記載のシステム。
【請求項７】
前記情報提供手段は、前記インタフェース定義データ構造が、前記クライアントコンピュータにアクセス可能な少なくとも１つのリポジトリサーバ上へ提供されるように、前記クライアントコンピュータに向けて前記インタフェースデータ構造を送信する、ことを特徴とする請求項１に記載のシステム。
【請求項８】
前記インタフェース定義データ構造が、前記入力／出力ビジネスドキュメントの論理構造用の解釈情報又はその解釈情報に対するポインタを更に含む、請求項１〜７の何れか１項に記載のシステム。
【請求項９】
消費者サーバ上で動作する消費者サービスによってリクエストされたオペレーションをネットワークを介して実行する方法であって、
プロバイダーサーバ上で実行可能であり、且つ処理サーバ上で実行中のオペレーションに対するアクセスを提供するオペレーションインタフェースを、前記ネットワークを介して少なくとも１つの消費者サービスに呈示する処理を含み、
前記オペレーションインタフェースは、インタフェース記憶手段上のオペレーションインタフェース定義データ構造に記憶されたインタフェース定義を実装し、そして前記インタフェース定義データ構造は入力／出力ビジネスドキュメントの定義を含み、そして前記定義は記憶装置の記述及び論理構造を含み、
前記ネットワークを介し、前記プロバイダーサーバで、前記消費者サーバからの入力ビジネスドキュメントを受信し、
前記入力ビジネスドキュメントの内容及び論理構造に対するアクセスを提供するため、前記プロバイダーサーバで、前記入力ビジネスドキュメントの定義に従って前記入力ビジネスドキュメントを構文解析し、そして前記構文解析された入力ビジネスドキュメントの少なくとも部分を内部用入力データオブジェクトに変換し、
前記内部用入力データオブジェクトを、前記プロバイダーサーバから前記処理サーバ上で実行されるオペレーションに送信し、
前記ネットワークを介して、前記出力ビジネスドキュメントの定義に合致する出力ビジネスドキュメントを前記消費者サーバに転送する、
ことを特徴とする方法。
【請求項１０】
前記プロバイダーサーバは、前記処理サーバから内部用出力データオブジェクトを受信し、
前記プロバイダーサーバで、前記内部用出力データオブジェクトを、前記消費者サーバに送信される前記出力データオブジェクトに変換する、ことを特徴とする請求項９に記載の方法。
【請求項１１】
ネットワークを介して、消費者サーバ上で動作する消費者サービスから、プロバイダーサーバのオペレーションインタフェースに送信されるリクエストに応じて実行されるオペレーションを生じさせる方法であって、
前記オペレーションインタフェースは、インタフェース記憶手段上のオペレーションインタフェース定義データ構造に記憶されたオペレーションインタフェース定義を実装し、そして前記オペレーションインタフェース定義データ構造は入力／出力ビジネスドキュメントの定義を含み、そして前記定義は記憶装置の記述及び論理構造を含み、
前記消費者サーバ上のデータを、第１の内部用データオブジェクトから、入力ビジネスドキュメントの前記オペレーションインタフェース定義に合致する入力ビジネスドキュメントに体系化し、
前記入力ビジネスドキュメントを、前記消費者サーバから前記プロバイダーサーバに前記ネットワークを介して送信し、
前記消費者サーバで、出力ビジネスドキュメントの前記オペレーションインタフェース定義に合致する前記出力ビジネスドキュメントを、前記プロバイダーサーバから受信し、
前記出力ビジネスドキュメントの内容及び論理構造に対するアクセスを提供するため、前記消費者サーバで、前記出力ビジネスドキュメントの定義に従って前記出力ビジネスドキュメントを構文解析し、そして前記構文解析された出力ビジネスドキュメントの少なくとも部分を、第２の内部用データオブジェクトに変換する、
ことを特徴とする方法。
【請求項１２】
ネットワークを介して、クライアントコンピュータから受信された入力ビジネスドキュメントを、処理サーバ上で実行される１以上のオペレーションに送信する方法であって、
オペレーションインタフェース仕様を含む複数のオペレーションインタフェース仕様データ構造をインタフェース記憶手段に記憶し、ここで、前記オペレーションインタフェース仕様はオペレーションの記述及び入力／出力ビジネスドキュメントの定義を含み、前記入力／出力ビジネスドキュメントの定義は記憶装置の記述及び論理構造を含んでおり、
サーバで、クライアントコンピュータからのドキュメントを含むデータをネットワークを介して受信し、
前記サーバで、入力ビジネスドキュメントを識別するために前記オペレーションインタフェース仕様に従い当該入力ビジネスドキュメントを構文解析し、そして前記識別された入力ビジネスドキュメントを受け入れ可能な処理サーバで実行されるオペレーションを識別し、
前記サーバからの入力ビジネスドキュメントの少なくとも部分を、前記サーバから、前記識別された入力ビジネスドキュメントを受け入れ可能な処理サーバで実行される１以上のオペレーションに送信する、ことを特徴とする方法。
【請求項１３】
前記入力／出力ビジネスドキュメントは、標準拡張マークアップ言語のＸＭＬフォーマットに合致する、請求項９〜１２の何れか１項に記載の方法。
【請求項１４】
前記記憶装置は構文解析されたデータを含む、請求項９〜１３の何れか１項に記載の方法。
【請求項１５】
前記記入力／出力ビジネスドキュメントの少なくとも１つにある前記構文解析されたデータは、
前記入力／出力ビジネスドキュメントの一つにおいて、テキスト文字をエンコードするキャラクタ・データと、
前記入力／出力ビジネスドキュメントの一つの論理構造に従い、前記記憶装置を識別するマークアップデータとを含む、請求項１４に記載の方法。
【請求項１６】
処理サーバ上で機能するトランザクション処理フロントエンドのオペレーションを含むドキュメントを送信し、そしてネットワークを介して、１以上のクライアントコンピュータを少なくとも１つのバックエンドプロセッサで実行される少なくとも１つのオペレーションと結びつけるシステムであって、
オペレーションインタフェース仕様を含むインタフェース記憶手段に記憶された複数のオペレーションインタフェース仕様データ構造であって、ここで、前記オペレーションインタフェース仕様は、オペレーションの記述及び入力／出力ビジネスドキュメントの定義を含み、前記入力／出力ビジネスドキュメントの定義は、記憶装置の記述及び論理構造を含んでいることを特徴とする当該オペレーションインタフェース仕様データ構造と、
前記インタフェース記憶手段に接続された前記処理サーバ上で実行される前記トランザクション処理フロントエンドが、
(1)前記ネットワークを介して前記クライアントコンピュータからドキュメントを受け入れるネットワークインタフェースと、
(2)前記オペレーションインタフェース仕様に従い前記ドキュメントを解析し、前記入力ビジネスドキュメントを識別し、そして前記識別された入力ビジネスドキュメントを受け入れ可能な処理サーバで実行される１以上のオペレーションを識別する、前記処理サーバ上で動作する構文解析器と、
(3)前記処理サーバから、前記識別された入力ビジネスドキュメントを受け入れ可能なバックエンドサーバで実行される１以上のオペレーションに対して、前記入力ビジネスドキュメントの少なくとも部分を送信する、前記処理サーバ上で動作可能なドキュメントルーターと、を備えたことを特徴とするシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された多様なクライアントの間でのトランザクション（取引）をサポートするシステム及びプロトコルに係り、詳細には、異なるアーキテクチャを有するプラットフォームの間での商取引をサポートするシステム及びプロトコルに関する。
【背景技術】
【０００２】
インターネットやその他の通信ネットワークは、コンピュータシステムと人との間の通信のための手段を提供し、それは、例えば参加者によって商品やサービスの売買が行われる商取引などの広範囲な種々のトランザクションに使用されている。インターネット上での商取引を促進させるために多くの努力がなされている。しかしながら、取引を実行するにあたって競合する規格が沢山あることから、その取引の関係者は、用いられるプロトコルに事前に同意しておかなければならないし、かかる取引をサポートするためにはシステム・アーキテクチャをその都度、統合再編することの要求が頻繁に生じていた。合意された規格に適合せず、特定ノードに内在してしまっている商業プロセスは、他のノードとの統合再編のために相当の手直しを必要とするかも知れない。更に、一企業が１つの規格又は他の規格にかかわると、その企業はすでに存在する規格グループの取引集団に固定化され、他の者を排除してしまうことになる。
【０００３】
インターネット商取引の開発に関する挑戦の概要が、「Ｅｃｏ  Ｓｙｓｔｅｍ：Ａｎ  Ｉｎｔｅｒｎｅｔ  Ｃｏｍｍｅｒｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ」  Ｔｅｎｅｎｂａｕｍ他著：Ｃｏｍｐｕｔｅｒ，Ｍａｙ  １９９７；４８〜５５ページに記載されている。
【０００４】
インターネット上での商取引をオープンなものにするため、アーキテクチャのフレームワークを標準化することが望ましい。そのような商業的フレームワークをサポートするために開発されたプラットフォームとして、ＩＢＭのＣｏｍｍｅｒｃｅ  Ｐｏｉｎｔ；Ｍｉｃｒｏｓｏｆｔ（Ｒ）  Ｉｎｔｅｒｎｅｔ  Ｃｏｍｍｅｒｃｅ  Ｆｒａｍｅｗｏｒｋｓ；ＮｅｔｓｃａｐｅのＯＮＥ（Ｏｐｅｎ  Ｎｅｔｗｏｒｋ  Ｅｎｖｉｒｏｎｍｅｎｔ）；ＯｒａｃｌｅのＮＣＡ（Ｎｅｔｗｏｒｋ  Ｃｏｍｐｕｔｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ）；及びＳｕｎ／ＪＡＶＡ（Ｒ）のソフトＪＥＣＦ（ＪＡＶＡ  Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｅｒｃｅ  Ｆｒａｍｅｗｏｒｋ）がある。
【０００５】
これら専有フレームワークに加えて、ＣＯＲＢＡ  ＩＩＯＰ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｉｎｔｅｒｎｅｔ  ＯＲＢ  Ｐｒｏｔｏｃｏｌ）をベースとした、共通分散オブジェクトモデルなどのプログラミング技術が推進されている。共通分散オブジェクトモデルの使用は、企業システムの移行を、電子商取引をビジネスアプリケーションレベルで相互利用できるシステムにまで単純化させることを意図したものである。しかしながら、１つのフレームワークしか用いない消費者又はビジネスにとっては、異なるフレームワーク上にある取引（トランザクション）を実行することができない。このことが、電子商取引システムが成長する上での阻害要因となっている。
【０００６】
１つのフレームワークを実行している企業は、他のフレームワークをサポートしているＡＰＩとは異なるアプリケーション・プログラミング・インタフェース（ＡＰＩ）をもつであろう。従って、企業は、共通のビジネス・システム・インタフェースを採用することを要求することなく、ビジネス・サービスを相互にアクセスするのは非常に困難である。ビジネス・システム・インタフェースをＡＰＩレベルで開発することは、関係者間で実際上実現不可能な程の相当の協力を要求してしまうことがある。
【０００７】
したがって、通信ネットワークにおける多様なプラットフォーム間での対話（インタラクション）を容易にするフレームワークを提供することが望まれている。そのようなシステムは、個別の統合再編や産業界の広範囲な規格に前もって同意することなく、取引パートナー間で自発的な取引がなされることを容易にしなければならない。更に、かかるシステムは、ビジネスの自動化に向けて前進する道を切り開き、従来のシステム統合で要されていた多大な時間やコストやリスクを排除するものでなければならない。
【０００８】
全体としては、専有規格をベースとする閉鎖的な商取引相手とのネットワークを、開放されたマーケットに置き換える電子商取引システムを提供することが望ましい。
【発明の開示】
【課題を解決するための手段】
【０００９】
本発明は、消費者、供給業者（サプライヤー）、及び取引相手とビジネス上の繋がりをもつためのインフラストラクチャ（基盤＝インフラ）を提供する。本発明のインフラストラクチャの下では、取引相手との間で容易に理解可能なことを特徴とするＸＭＬ（拡張マークアップ言語）ベースのドキュメント等の自己定義型でマシン読取り可能なドキュメントを用いて、企業間で情報及びサービスの交換を行う。交換されるべき事項が記述されたドキュメント（以下、ビジネス・インタフェース定義、即ち“ＢＩＤ”と称する）が、インターネット上に送られ、或いは、ネットワークのメンバーに通信される。ビジネス・インタフェース定義（ＢＩＤ）は、潜在的な取引相手に対して、企業が提供するサービスやそのサービスのやりとりの時に使用するドキュメントを知らせる。したがって、典型的なビジネス・インタフェース定義というのは、消費者が購買注文を提出することによって発注することができるようにさせるものであって、当該購買注文は、その購買注文を受取る取引相手のＢＩＤに表れるドキュメント定義に従っていることになる。供給業者は、在庫データを管理するビジネスシステムのＢＩＤに表れるドキュメント定義に従った在庫状況報告をダウンロードすることによって、注文の可能性を確認することが可能である。予め定義された、マシン読取り可能なビジネスドキュメントの使用によって、企業のアプリケーションにアクセスするためのより直観的で柔軟な方法が提供されることになる。
【００１０】
商業ネットワークにおけるノードは、本発明による取引（トランザクション）のためのインタフェースを確立する。この場合、本発明には、インタフェースの仕様のみならず、当該インタフェースを解釈するのに必要な情報をもつマシン読取り可能なデータ構造をも含んでいる。このインタフェースの仕様は入力ドキュメントの定義及び出力ドキュメントの定義を含む。トランザクションプロセッサはその仕様を受け入れ且つ生成し、前記ノードはインタフェースとして動作する。入力及び出力ドキュメントの両定義は、例えば、標準ＸＭＬ系ドキュメントに従い、記憶装置の記述や記憶装置の論理構造の記述のそれぞれを含む。本発明の様々な態様によれば、解釈情報を含むマシン読取り可能なデータ構造は、論理構造の意味定義（例えば、製品名に対するマッピングコード）を提供するために、リスト内の各エントリに対して、入力及び出力ドキュメントの定義における論理構造用のデータ・タイプ仕様（例えば、ストリングやアレイ等）、論理構造用のコンテンツモデル（例えば、取り得る値のリスト）、及び／又は特定の論理構造用の記憶装置をマップするデータ構造を含む。
【００１１】
本発明の他の態様によれば、インタフェースは、ネットワークの少なくとも１つのノードによってアクセス可能なメモリにリポジトリ（これは論理構造のライブラリ及び論理構造の解釈情報を記憶する）を含んでいる。このリポジトリは、入力及び出力ドキュメント定義のライブラリ、インタフェース仕様のライブラリ、及びネットワークにおける参加者インタフェースノードのための仕様のライブラリを含むように拡張することができる。
【００１２】
従って、本発明のトランザクション・フレームワークの参加者は、トランザクションに関係する複数のノード実行プロセスを含むネットワークにおいて、ノード間でのトランザクションを実行する。本発明の方法は、トランザクションのために、インタフェースのマシン読取り可能な仕様を記憶することを含む。その仕様は、入力ドキュメントの定義及び出力ドキュメントの定義を有する。入力及び出力ドキュメントの定義は、それぞれ、記憶装置の記述、及び記憶装置用の論理構造を含む。好ましいシステムでは、それらの定義は、標準ＸＭＬドキュメントタイプ定義であるＤＴＤに準拠したやり方で表現され、セマンティック（意味的）マッピング、コンテンツモデリング、及び幾つかのエレメントのデータタイピングによって拡張される。トランザクションの参加者は、通信ネットワークを通じたドキュメントを含むデータを受信する。参加者は、トランザクションのために記憶された仕様に従いドキュメントを構文解析し、トランザクションのための入力ドキュメントを識別する。ドキュメントの構文解析後、出力を生み出すトランザクションプロセスに、マシン読取り可能なフォーマットの入力ドキュメントの少なくとも一部が提供される。出力ドキュメントは、記憶された仕様の出力ドキュメントの定義に基づき、トランザクションプロセスの出力を含むように形成される。出力ドキュメントは、通信ネットワーク上に送信され、通常は入力ドキュメントのソースに戻されるか、そうでなければ特定のタイプのトランザクションのニーズに合わせられる。
【００１３】
したがって、ビジネス・インタフェースの定義は、例えばＸＭＬによって特定されるドキュメントと、特別のノードにおけるトランザクション処理サービスのフロントエンドで実行されるプログラムとの間のギャップを埋める。そのようなフロントエンドは、例えば、ＪＡＶＡ仮想マシンによって、或いはネットワークを越えて存在するシステム間の相互接続のために提供される他の共通のアーキテクチャによって実現される。ビジネス・インタフェース定義は１つの技術を提供し、この技術により、トランザクション・プロトコルがビジネス・インタフェースを定義したドキュメントを用いてプログラミングされる。トランザクション・プロトコルのためのプログラムは、ドキュメント形式の詳細な正式によって確立される。
【００１４】
トランザクション・インタフェースのマシン読取り可能な仕様は、ネットワークの他のプラットフォームに対してアクセス可能にする。参加者のプラットフォームは、相補的ノードで特定されるトランザクション・インタフェースに従った、入力ドキュメント及び出力ドキュメントを設計するためのリソースを含む。したがって、参加者のノードは、相補的インタフェース用の入力ドキュメント定義、及び相補的インタフェース用の出力ドキュメント定義にアクセスするリソースを含む。アクセスする参加者ノード用に記憶された仕様は、その仕様で記憶した入力ドキュメント定義に、相補的インタフェースの出力ドキュメント定義の少なくとも一部を含むことによって確立される。
【００１５】
本発明の他の態様によれば、インタフェースの仕様を確立するプロセスは、リポジトリから機械読取り可能な仕様の要素にアクセスすることを含む。このリポジトリは論理構造、コンテンツモデル、および論理構造のための概略マップのライブラリ、並びにインタフェース記述を構築するために用いられる論理構造を含んだドキュメント定義を記憶する。ネットワーク上アクセス可能なリポジトリは、容易に共有され得るインタフェース記述の構築を簡単にさせる。特別なプロセス用として生成された入力ドキュメントと、相補的プロセスによるリターンとして期待される出力ドキュメントとの間の相違は、ネットワーク上の通信や、特別な情報を表現するための共通論理構造に同意することによって、乗り越えられる。
【００１６】
本発明の一つの態様によれば、トランザクションのインタフェースのマシン読取り可能な仕様は、ネットワークのメンバー間で共有されるインタフェース・ドキュメントの定義に従うドキュメントを有する。インタフェース・ドキュメントの定義は、特別なトランザクションの識別子、少なくとも一つの定義、そして特別なトランザクションのための入力及び出力ドキュメント定義に対する参照を記憶するための論理構造を有する。すなわち、実際には、特別なサービスに関するインタフェース記述が、入力及び出力ドキュメントの定義を網羅する。あるいはまた、このようなドキュメントの定義に対するリポジトリにおける位置へのポインタであったり、ネットワークのどこかへのポインタを含むことができる。
【００１７】
本発明の他の代替方法によれば、マシン読取り可能な仕様は、インタフェース・ドキュメントの定義に準拠したビジネス・インタフェース定義ＢＩＤドキュメントを含み、前記インタフェース・ドキュメントには、インタフェース識別子を記憶するため、そして少なくとも１つの仕様や、インタフェースによってサポートされる１以上のトランザクションの組の仕様に対する参照を記憶するための、複数の論理構造を有する。サポートされた各トランザクションについて、ドキュメントは、少なくとも１つの定義、並びに特別なトランザクションに対する入力及び出力ドキュメント定義への参照を含む。
【００１８】
本発明の他の態様によれば、入出力ドキュメントの定義で規定された記憶装置は、テキスト文字をエンコードするキャラクタ・データを含む構文解析データ、および入出力ドキュメントの論理構造に従って記憶装置を識別するマークアップデータを含む。本発明の他の態様によれば、記憶装置の組の少なくとも１つは、自然言語をもたらす複数のテキスト文字をエンコードする。これは、ドキュメントの開発者や読み手が、入出力ドキュメントの定義をたやすく使用できるようにする。
【００１９】
本発明の他の態様によれば、入出力ドキュメントの仕様は、論理構造によって識別された記憶装置の組のうちの少なくとも１つに関する解釈情報を含む。この解釈情報は、例えば、構文解析された文字用の定義をエンコードする。別の例では、解釈情報は、コンテンツモデル仕様のために提供される。例えば、カタログの記述を作るためにマップされたコードの多数のリストを扱うために、特定の論理構造を要求したりする。あるシステムの場合、ドキュメントの論理構造にある記憶装置は、特定の実施の必要性にあわせて構文解析されたデータのセットを含む。
【００２０】
本発明の他の態様によれば、特定のプラットフォームでのトランザクションプロセスは、多数の変形トランザクション処理アーキテクチャの１つを有する。したがって、参加者ノードは、情報を用いて、入力ドキョメントの少なくとも一部を、変形トランザクション処理アーキテクチャに従って読み出し可能なフォーマットに変換するためのリソースを含む。ドキュメント定義の要素は、変形トランザクション処理アーキテクチャに従い、変数及び方法を含むプログラミング・オブジェクトに変換される。トランザクションプロセスのフロントエンドとして機能するＪＡＶＡ仮想マシンを有する参加者に対して、ドキュメントの特定のフィールドがＪＡＶＡオブジェクトに変換される。それは、データのみならず、ＪＡＶＡオブジェクトと対応付けられた関数を設定することを含んでいる。本発明に従いサポート可能な他のトランザクション処理アーキテクチャは、Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ＣＯＲＢＡ，Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ  ＣＯＭ，Ｏｎ−ｌｉｎｅ  Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  ＯＬＴＲ，およびＥｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ  ＥＤＩという意味で、インタフェース記述言語に従う処理を含む。
【００２１】
本発明の他の態様によれば、複数のトランザクションにおいて使用されるドキュメント形式を記憶するリポジトリが提供される。特別なトランザクション用のマシン読取り可能な仕様は、リポジトリのドキュメント形式を参照することによって、入出力ドキュメントの少なくとも１つを定義する。他の態様によれば、このリポジトリのドキュメント形式は、ネットワークの参加者を識別するためのドキュメント形式を含む。このようなドキュメント形式は、参加者を識別し、その参加者によってサポートされるサービスを特定し、そしてそのようなサービスの各々に対する入出力ドキュメントを特定するため構造を提供する。
【００２２】
上述の方法に加えて、本発明はノード間のトランザクションを管理する装置を提供し、前記ノードには、ネットワーク・インタフェース、トランザクション用インタフェースのマシン読取り可能な仕様を含んだ命令のプログラムやデータを記憶するためのメモリ、およびメモリとネットワーク・インタフェースとに接続されたデータ・プロセッサが含まれている。本装置に記憶された命令のプログラムは、トランザクションの参加者のために、上述したプロセスを実行するロジックを含む。
【００２３】
本発明は、更に、トランザクション処理アーキテクチャに従いトランザクション処理を遂行するデータ処理リソースとネットワーク・インタフェースを備えたシステム上で実行されるトランザクション用の参加者インタフェースを確立するための装置を提供する。本装置は、システムによって実効可能なプログラム命令を含む。そのプログラム命令は、特別のトランザクションの参加者用インタフェース定義を構築するツールを提供するシステムがアクセス可能な媒体に記憶される。参加者インタフェースの定義は、入力ドキュメントの定義及び出力ドキュメント定義を含む。この入出力ドキュメント定義は、記憶装置のための論理構造内で各記憶装置のマシン読取り可能な記述を有し、本発明の１つの態様では、それはＸＭＬドキュメント形式の定義に準拠する。
【００２４】
また、本発明の本態様によれば、参加者インタフェースを確立する装置は、データ処理システムによってアクセス可能な媒体に記憶された命令のプログラムを含み、入出力ドキュメントの定義に応答して、記憶装置の組及びトランザクション・アーキテクチャに準拠した入出力ドキュメントの論理構造に対応するデータ構造をコンパイルする。また、入力ドキュメントを対応のデータ構造に変換するために、システムによって実行可能な命令をコンパイルする。そして、トランザクション処理の出力を、出力ドキュメントの記憶装置の組及び論理構造に変換するために、システムによって実行可能な命令をコンパイルする。
【００２５】
好ましいシステムにおいて、参加者インタフェースの定義を構築するためのツールは、システムによって実行可能な命令を含み、論理構造やインタフェース記述を構築するのに用いられる解釈情報のライブラリを記憶したリポジトリからの、及び/又は相補ノードからの定義要素にアクセスする。本発明の様々な態様によれば、リポジトリは、論理構造のライブラリだけでなく、論理構造を含むドキュメント定義や参加者インタフェースを特定するフォーマットを有している。本発明のこの特徴によって、ビジネス・インタフェースの仕様を構築するためのツールが、参加者ノードの記述に関連する上述の技術に基づき提供される。インタフェースを構築するためのツール、及びこのインタフェースをトランザクション処理アーキテクチャとの通信のために必要とされるリソースにコンパイルするツールが、本発明の好ましいシステムの参加者ノードで実施される。そして、ネットワークの使用が入出力ドキュメントを定義するインタフェース記述に基づいて増大するとき、インタフェース記述の開発及び最適化のために用いられる。
【００２６】
したがって、本発明の別の態様は、メモリと、このメモリに記憶された命令であって参加者インタフェースの定義を構築するツールを含んだ命令を実行するデータ・プロセッサと、上述した機能を達成するコンパイラとを備えた装置を提供する。
【００２７】
本発明の更に別の態様によれば、参加者インタフェース記述の使用は、マーケットメーカー(market maker)のノードが動作することをもたらす。そのようなノードで、インタフェースによってサポートされたトランザクション、及びそのようなトランザクションの各入出力ドキュメントを識別する複数の参加者インタフェースのマシン読取り可能な仕様を記憶することを含むトランザクション管理方法が提供される。上述したように、入出力ドキュメントの定義は、例えばＸＭＬ標準に従い、記憶装置及び記憶装置のための論理構造の各記述を含んでいる。加えて、トランザクションの定義及び参加者インタフェースの定義の全ては、ＸＭＬに準拠した技術或いは他の標準化ドキュメントの表現言語に従って特定されたドキュメントを含んでいる。そのようなマーケットメーカーのノードで、ドキュメントを含むデータが、通信ネットワークを介して受信される。ドキュメントは、仕様に従い構文解析され、入力ドキュメントを受入れる一以上のトランザクションで入力ドキュメントを識別する。識別された一以上のトランザクションに関連するトランザクション処理に対し、入力ドキュメントの少なくとも一部がマシン読取り可能なフォーマットで提供される。入力ドキュメントの少なくとも一部をトランザクション処理に提供するステップは、マーケットメーカーのノードで、処理アーキテクチャに従いルーティング処理を実行することを含む。本発明の一態様の場合、このルーティング処理は、特定の処理アーキテクチャにより実行され、そして入って来るドキュメントの少なくとも一部を、ルーティング処理の処理アーキテクチャのフォーマットに変換する。好ましい態様によると、この変換は、ルーティング処理の処理アーキテクチャに基づいた変数及び方式を有するプログラミング・オブジェクトを生成することを含む。
【００２８】
本発明の別の態様によれば、マーケットメーカーのノードは、リポジトリ構造をサポートする。その結果、マーケットメーカーのノードで記憶されたリポジトリに対して、ネットワークの参加者がアクセスすることができるプロセスを含んでいる。上述したように、リポジトリは、トランザクション・インタフェース・ドキュメントを構築するために、論理構造の定義、解釈情報、及び各参加者ノードが使用するドキュメント定義を含み、そして、参加者を識別するビジネス・インタフェース定義のインスタンス、及び各参加者によって実行されるトランザクションを含む。
【００２９】
様々な代替に基づき、ルーティング処理は、入力ドキュメントを、そのドキュメントの送信先である様々な処理アーキテクチャにあわせて変換することや、元々のドキュメントフォーマットにある入力ドキュメントを、ネットワークを介して遠隔処理ノードに送信すること、或いはそれら変換処理や送信処理の両方を含む。代替として、ルーティング処理は、一つの入力ドキュメント定義に従って定義された入力ドキュメントを、入力ドキュメントを注視する処理のための異なるドキュメント仕様に従って定義される別のドキュメントに変換するための技術を含む。
【００３０】
また、ネットワーク・インタフェース、参加者インタフェース仕様を含む命令のプログラム及びデータを記憶しているメモリ、並びにデータ・プロセッサを含む装置として、マーケットメーカーのノードが本発明に従い提供される。その論理は、命令プログラムの形でデータ・プロセッサによって提供され、そうでなければ上述したようなマーケットメーカーの処理を実行する。
【００３１】
したがって、本発明は、入出力ドキュメントの仕様を共有することに基づき、電子商取引のための基礎を提供する。ドキュメントは、ビジネス・サービスをアクセスするための直感的かつ柔軟性のあるやり方をもたらすものであって、ＡＰＩをプログラミングするよりもより簡単に実施できる。企業間で既に大筋で同意しているならば、企業間の相互接続をドキュメント交換で行おうとする企業の方が、いつも異なるビジネス・システム・インタフェースの構築で実現する企業よりも格段に容易に実施可能である。加えて、好ましい実施例の場合、そのようなドキュメントは、人間が読取りることができるフォーマットで特定される。本発明によれば、ビジネス・インタフェースは、人間並びにコンピュータによって容易に解釈可能なＸＭＬドキュメントなどのドキュメントで特定される。
【００３２】
本発明によるドキュメントをベースとしたトランザクション・アーキテクチャの利用は、ネットワークの各参加者からの情報を抽出しかつ統合・編集するためのカスタム・プログラムに求められる要求を取り除きながら、ドキュメントのあらゆるソースのために基本的には同様の方法で動作する構文解析の使用を含んでいる。よって、会計、購入、製造、配送及び他の機能からの事業情報を統合・編集することは、まず、各ソースを本発明のアーキテクチャを有するドキュメントに変換し、次に、構文解析されたデータ・ストリームを処理することによって達成することができる。マーケットに参加するシステムの各ノードは、その内部システムのフォーマット、並びにトランザクションにあわせてドキュメント変換のために特定される筈のドキュメント・フォーマットについて知ることが要求されるにすぎない。それゆえ、電子商取引ネットワークに参加することを希望する全ての他のノードに固有なフォーマットを生成できるようにする必要性がない。
【００３３】
完全なビジネス統合のために、本発明は、ＸＭＬ要素、属性又はメタデータなどの標準論理構造のリポジトリを提供し、特定の商取引コミュニティのためのセマンティック（意味）言語、異なるメタデータ記述間をマップするための手段、及びドキュメントを処理しかつ適切なアプリケーションやサービスを呼出すためのサーバを設定する。本発明によるネットワークの基本的構築ブロックは、潜在的な取引ビジネスパートナーにどのようなオンライン・サービスを会社が提供し、かつサービスを呼出すためにどのドキュメントを用いるかを通告するビジネス・インタフェース定義と、そして取引コミュニティを生成するために内部／外部のビジネス・サービスの組を互いに結びつける橋渡しを供給するサーバを含む。このサーバは、入力ドキュメントを構文解析し、そして適切なサービスを呼出すよう動作する。また、本発明によるサーバは、各ホスト・システムのフォーマットへ、そして各ホスト・システムのフォーマットから、受信されたり送信されたりするドキュメントのフォーマットの変換タスクを取り扱う。それゆえ、取引パートナーは、交換されるビジネス・ドキュメントの構造や内容や順序のみに同意すればよいのであって、アプリケーションのプログラム・インタフェースの詳細にまで同意する必要はない。サービスを提供するビジネス次第で、ドキュメントがどのように処理されたかが決まり、そしてドキュメントの受信の結果としてもたらされる行動が厳しくにもなる。これは、統合・編集をシステム・レベルからビジネス・レベルへと向上させる。それは、その内部的な技術実装、組織又は処理が変化するにも係わらず、パートナーに対して明瞭かつ安定したインタフェースを提示することができる。
【００３４】
ビジネス・インタフェース定義を構築し、且つ上記記述に従ってサーバが取引を何とかやる全ての処理は、共通のビジネス・ライブラリ、即ちリポジトリによって容易に実現され、リポジトリには、例えば、企業、サービス及び製品、カタログ・購入注文書・請求書などのビジネス形式、日時・場所・商品分類を含む標準指標など、基本的なビジネス記述を含む汎用的なビジネス概念のための情報モデルが記憶されている。
【００３５】
本発明の他の特徴は、以下に説明する図面、詳細な説明、及び特許請求の範囲を考慮することにより理解することができるであろう。
【発明を実施するための最良の形態】
【００３６】
図面との関連で本発明について詳細に説明する。図１は、ビジネス・インタフェース定義の使用に基づき、マーケットメーカー及びマーケット参加者のネットワークを示し、上記インタフェースに従って特定される入出力ドキュメントのやり取りをサポートしている。ネットワークは、インターネット１９などの通信ネットワーク、あるいは他の通信手段またはデータ通信ネットワークを介して相互接続された複数のノード１１〜１８を含む。ノード１１〜１９の各々は、ポータブルコンピュータ、デスクトップパーソナルコンピュータ、ワークステーション、システムネットワーク、あるいは他のデータ処理リソースなどのコンピュータで構成されている。ノードは、ビジネス・インタフェース定義を記憶しておくためのメモリ、ネットワークにおける他のノードとの商取引トランザクションをサポートするトランザクションプロセスを実行するためのプロセッサ、及びそのようなサービスをサポートするために上記プロセッサにより実行されるコンピュータプログラムを含んでいる。さらに、各ノードは、インターネット１９あるいは他の通信ネットワークにわたり通信を提供するためのネットワーク・インタフェースを含む。
【００３７】
図１に示す環境の場合、ノード１１、１２、１３、１４、１６及び１８は、指定されたマーケット参加者である。マーケット参加者は、本発明に基づき確立された商取引トランザクションに従って取引されるべき商品またはサービスの需要者または供給者についてのリソースを含んでいる。
この例では、ノード１５及び１７は、マーケットメーカーノードである。マーケットメーカーノードは、ＢＩＤレジストリと呼ばれるビジネス・インタフェース定義を登録するためのリソースを含む。参加者は、ドキュメントをマーケットメーカーに送ることが可能であり、そこで該ドキュメントは識別され、そのようなドキュメントを入力として受け取るように登録されている適切な参加者に転送される。マーケットメーカーは、ビジネス・インタフェース定義を構築するのに使用する共通ビジネス・ライブラリを構成するための標準形式のリポジトリをもつことにより、商取引ネットワークを手助けする。
【００３８】
この例では、マーケット参加者１８は、インターネット１９を介するよりはむしろ、マーケットメーカー１７に直接接続されている。このマーケットメーカーへの直接接続は、インターネット１９などの公衆ネットワーク、及びローカルエリアネットワークのような私設接続、あるいはノード１７と１８との間に示されているようなポイント−トゥ−ポイント接続を組み入れることにより、商取引トランザクションをサポートするネットワーク構成を極めて多様にし得るということを示す。実際の通信ネットワークはかなり多様であることから、本発明による商取引トランザクションネットワークを確立する上で使用するのが適していると言えよう。
【００３９】
図２は、本発明によるネットワークのマーケット参加者のために確立されたビジネス・インタフェース定義（ＢＩＤ）において、ネスト(nested)構造のヒューリスティックダイアグラムを示す。図２に示されたビジネス・インタフェース定義は、ＸＭＬドキュメントタイプ定義（ＤＴＤ）などのドキュメント構造の形式定義にしたがって整えられた論理構造と記憶装置とで構成されるデータ構造である。図２の構造は、パーティ(party)を識別するための第１の論理構造２００を含む。論理構造２００と関連付けられているのは、名前を送信するためのネスト論理構造２０１と、物理的アドレス２０２と、ネットワークのアドレス又は位置２０３と、一組のサービス・トランザクション２０４とである。サービスセット中の各トランザクションのためには、トランザクションＢＩＤ２０５、２０６、２０７を含むインタフェース定義が提供される。トランザクションＢＩＤ２０５などの各トランザクションＢＩＤの中には、名前２０８と、サービスが実行されるネットワーク上の位置２０９と、サービスにより実行される操作２１０と、及びタグにより示される一組の入力ドキュメント２１１とを含むための論理構造が提供される。また、サービスＢＩＤ２０５は、タグにより示される一組の出力ドキュメント２１２を含む。一組の入力ドキュメント２１１は、入力ドキュメント・ビジネス・インタフェース定義２１３、２１４、２１５など、サービスが応答するよう指定された各入力ドキュメントのためのビジネス・インタフェース定義を含む。入力ドキュメントのための各ビジネス・インタフェース定義は、名前２１６と、ドキュメントの記述を見出し得るネットワーク上の位置２１７と、フィールドにより示されるようなドキュメントにおいて送信されるべきモジュール２１８とを含む。同様の方法で、出力ドキュメントセット２１２は、出力ドキュメントＢＩＤ２１９、２２０、２２１を含む出力ドキュメントのためのインタフェース定義を含む。各出力ドキュメントＢＩＤのために、名前２２２と、ネットワーク上または他の場所の位置２２３と、ドキュメントのモジュール２２４とが特定されている。図２に示されている参加者についてのビジネス・インタフェース定義は、各サービスの入出力ドキュメントのために使用される論理構造の実際の定義や、あるいはその定義を見出し得る位置へのポインタまたは他の参照を含んでいる。
【００４０】
好ましいシステムにおいて、図２のドキュメントは、ＸＭＬドキュメントタイプ定義（ＤＴＤ）で特定されるが、他のドキュメント定義アーキテクチャを使用することもでき、またドキュメントのインスタンスの解釈のために使用する論理構造についての解釈情報を含んでいる。また、トランザクションＢＩＤ、入力ドキュメントＢＩＤ、出力ドキュメントＢＩＤの各々は、ＸＭＬドキュメントタイプ定義に従って特定される。ＸＭＬタイプドキュメントは、マークアップデータ及びキャラクタ・データを含む構文解析データに基づいたシステムの一例である。マークアップデータは、ドキュメント内の論理構造を識別し、そしてキャラクタ・データの組は、論理構造の内容を識別する。加えて、非構文解析データが、様々な目的で、ドキュメントにおいて送信され得る。例えば、ＷＷＷ．Ｗ３．ＯＲＧ／ＴＲ／１９９８／ＲＥＣ−ＸＭＬ−１９９８０２１０において、ＷＣ３  ＸＭＬワーキンググループにより発行されたＥｘｔｅｎｓｉｂｌｅ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ  ＸＭＬ  １．０  ＲＥＣ−ＸＭＬ−１９９８０２１０の仕様書を参照することができる。
【００４１】
したがって、例示したシステムにおいては、ネットワーク中の参加者ノードは、ビジネスシステム及びサービスを、ビジネス上了解され且つ生成されるＸＭＬコード化ドキュメントと相互接続することにより、仮想企業を確立する。例えば、特定のサービスのビジネス・インタフェース定義は、カタログ記入に関する要求のＢＩＤに合致したドキュメントが受信された場合、カタログ記入のＢIＤに合致するドキュメントが返信されることを確立する。また、購入注文のＢＩＤに合致するドキュメントが受信された場合であって、且つそれが受信端末にとって受け入れ可能なものであれば、請求書のＢＩＤに合致するドキュメントが返信されるだろう。本ネットワーク中のノードは、ネットワークにおける任意の所与のシステムの様々なトランザクション処置アーキテクチャに従って確立されたローカルビジネスシステムにＸＭＬドキュメントが入る前に、そのＸＭＬドキュメントを処理する。その結果、本システムは、ＭＩＭＥコード化されたＸＭＬドキュメントの組などの関連するドキュメントの組を復号化し、これを構文解析して、“マークアップメッセージ”のストリームを生成する。このメッセージは、例えば後述するイベント・リスナー・モデルを用いて、適切なアプリケーション及びサービスに送信される。
【００４２】
ビジネス・サービス間で交換されるドキュメントは、より複雑なドキュメント定義が生成されるビルディング(building)・ブロック（共通のビジネス言語）のリポジトリから構築されたＸＭＬ言語を使用して、エンコードされる。このリポジトリは、ビジネス領域に共通な機能および情報に焦点があてられた解釈情報のモジュールを記憶する。なお、ビジネス領域には、例えば、企業・サービス・製品、カタログ・購入注文書・請求書などのビジネス形式、日時・場所などの標準指標、分類コード、及びＸＭＬドキュメントの論理構造のために解釈情報を与えるような基本的なビジネス記述を含む。
【００４３】
ビジネス・インタフェース定義は、本発明に従ってドキュメントを取引するインタフェースを設計するために使用されるスキーマとして機能するより高レベルのドキュメントである。したがって、ビジネス・インタフェース定義は、ＸＭＬに従って特定されるドキュメントと、特定のノードにあるトランザクション処理サービスのフロントエンドで実行されるプログラムとの間のギャップを埋める。このようなフロントエンドは、ＪＡＶＡ仮想マシンよって、或いはネットワークにわたりシステムの内部接続を提供する他の共通アーキテクチャによって実行される。ゆえに、ビジネス・インタフェース定義は、ビジネス・インタフェース定義ドキュメントを用いてトランザクション・プロトコルがプログラムされる技術を提供する。トランザクションのプロトコルのためのプログラムは、ドキュメントタイプの詳細な正式仕様によって確立される。
【００４４】
ＸＭＬフォーマットに適合するマーケット参加ドキュメントに基づいたビジネス・インタフェース定義ＢＩＤの一例は、以下に与えられる。マーケット参加者ＤＴＤは、連絡先および住所情報を、サービスおよび財政情報の記述と関連付けながら、マーケット参加者に関するビジネス情報にグループ分けする。このビジネス情報は、名前、コード、住所、ビジネス組織を示すための専用分類メカニズム、及びビジネス用語へのポインタとから成る。加えて、マーケット参加者ＤＴＤによって識別されるサービスは、参加者がそれに応答し且つ生成することを期待される入出力ドキュメントを特定する。その結果、注釈的なコメントをもつＸＭＬ内で特定されたマーケット参加者ＤＴＤ、サービスＤＴＤ、及びトランザクションドキュメントＤＴＤのための典型的な共通ビジネス言語を用いた、スキーマを定義するドキュメントは、以下のとおりである。
【００４５】
2008084328.tif 000101
2008084328.tif 000102
2008084328.tif 000103
2008084328.tif 000104
2008084328.tif 000105
2008084328.tif 000106
2008084328.tif 000107
2008084328.tif 000108
2008084328.tif 000109
2008084328.tif 000110
サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプ要素によって、以下のように拡張される。
2008084328.tif 000111
2008084328.tif 000112
【００４６】
上記のサービスタイプ要素は、ビジネス・インタフェース定義によってもたらされる解釈情報を示し、本例の場合、有効なサービスタイプのいずれか１つの識別を可能にする内容形式を表す。別の解釈情報はデータ型定義を含み、例えば、内容形式“ｕｒｌ”を含む要素、＜Ｈ３＞Ｉｎｔｅｒｎｅｔ  Ａｄｄｒｅｓｓ＜／Ｈ３＞）を、データ型“ｓｔｒｉｎｇ”で表したりする。さらに別の解釈情報は、リスト要素へのコードマッピングを含み、例えば、ファイル「ＣＯＵＮＴＲＹ．ＵＳ．ＳＵＢＥＮＴＩＴＹ」に存在する州に対してのコードマッピングを含む要素、＜Ｈ３＞Ｓｔａｔｅ＜／Ｈ３＞がある。
マーケット参加者ＤＴＤによって照会されるサービス記述は、サービスとしてその競合が受容され、且つ生成されるためのドキュメントを定義することである。基本的なサービス記述は、ＸＭＬドキュメントのｔｒａｎｓａｃｔ．ｄｔｄとして以下で詳述する。
ｔｒａｎｓａｃｔ．ｄｔｄは、請求書等のトランザクション記述、或いは値を交換する記述をモデル化する。このドキュメント型は多くの用途をサポートし、従ってトランザクション記述要素は、請求書、性能、販売の申し出、見積もりの要望等がある中でユーザが他のものと区別して特定できそうな属性を有する。２人以上の関係者間で交換が行われるが、二人のみが申込者とその相手として対象となり、その各人は、上述したマーケット参加者ＤＴＤに一致するドキュメントへのポインタによって表される。販売の申し出を承諾するための相手のポインタは任意である。交換のための記述は、以下に挙げるｔｒａｎｐｒｉｍ．ｍｏｄにおいて示されるように、価格および小計を含んでいる。交換のための記述に続き、取引全体に適用される課金が提供されるようにしてもよく、そして全体の課金を与えなれなければならない。従って、本例におけるトランザクション記述のスキーマドキュメントｔｒａｎｓａｃｔ．ｄｔｄは、以下のように示される。
【００４７】
2008084328.tif 000113
上記の定義に従って生成される典型的なマーケット参加者およびサービスＤＴＤは、以下の通りである。
＜マーケット参加者ＤＴＤ＞
2008084328.tif 000114
2008084328.tif 000115
＜サービスＤＴＤ＞
2008084328.tif 000116
ｔｒａｎｓａｃｔ．ｄｔｄに従って生成されたドキュメントの一例は次のように示される。
2008084328.tif 000117
2008084328.tif 000118
2008084328.tif 000119
【００４８】
したがって、本発明は、マーケット参加者が自分自身を識別し、そしてビジネスを取引したいと思っている入出力ドキュメントのタイプを識別できるようにする技術を提供する。この取引に対する他の関係者によって或いは一部の関係者によってドキュメントにもたらされた内容が処理されるといった特定のやり方は、ビジネス関係の確立にも取引を行う上でも影響を及ぼさない。
【００４９】
図３は、本発明によるネットワークの参加者ノードの概略図を示している。図３に例示されたノードは、ポート３０１で、通信ネットワークに結合されるネットワーク・インタフェース３００を含む。このネットワーク・インタフェースは、ドキュメントの構文解析器（パーサー）３０１と結合する。パーサー３０１は、入力ドキュメントからの論理構造を変換モジュール（トランスレータ）３０２に供給し、変換モジュール３０２は、入力ドキュメントをホスト取引システムによって使用できる形式へ変換するとともに、その逆のホストプロセッサの出力を、送り先への送信のために、ビジネス・インタフェース定義に規定された出力ドキュメントフォームに一致するドキュメント形式へ変換する。パーサー３０１およびトランスレータ３０２は、参加者モジュール３０３に記憶されたビジネス・インタフェース定義に応答する。
【００５０】
トランスレータ３０２からの出力データ構造は、パーサー３０１によって合図されたイベントと一緒に、取引プロセス・フロントエンド３０４へ供給される。一実施例におけるフロントエンド３０４は、ネットワークの様々なノードの間で通信するのに適したＪＡＶＡ仮想マシン、またはその他の同様のインタフェースから構成される。取引処理フロントエンド３０４は、パーサー３０１およびトランスレータ３０２によって示されたイベントに応答し、企業システムや参加者を結合するネットワークの適当な機能に対して入力データを転送する。その結果、図３に示す取引処理フロントエンド３０４が、コマーシャル・ファンクション３０５、データベース・ファンクション３０６、会計／請求書作成等の他の企業ファンクション３０７と結合し、パーサーが示したイベントに応答するように設計された特定のイベントリスナー／プロセッサ３０８と結合する。
【００５１】
パーサー３０１は、上述したような購入注文、又はビジネス・インタフェース定義に従って特定された他のドキュメントを受け取り、そしてＪＡＶＡ仮想マシン用ＪＡＶＡイベント等のローカル取引処理アーキテクチャによって認識されるイベントを生成する。
【００５２】
本発明のパーサーは、受信されたドキュメントに基づくイベントを知ろうとするリスニングプログラムとは非結合である。受信ドキュメント又はある仕様に適合する完全ドキュメントに存在するマークアップ言語の構成一つ一つは、処理を開始させるリスニング機能のための命令として作用する。したがって、リスニングプログラムは、ドキュメント情報に関連したビジネス論理を実行する。例えば、アドレス要素に関連したプログラムは、データベースをチェックすることによって、郵便コードを認証するコードである。これらのリスナーは、ドキュメントルータに登録しておくことによりエベントに加入し、ドキュメントルータは、関連エベントを興味のあるすべての加入者に差し向ける。
【００５３】
例えば、上述した購入注文は、パーサーが生成したイベントをリスニングするプログラムによってモニタされるものであり、パーサーは、ドキュメントまたはその内容を注文エントリプログラムに接続させる。購入注文の製品記述を受信することは、在庫をチェックするためのプログラムと関係がある。購入注文のアドレス情報を受信することは、配送サービスの可能性をチェックするためのプログラムと関係する。ドキュメントにおける購入者情報フィールドは、注文経緯をチェックしてクレジットを無価値にしているかどうかや、消費者のＩＤを把握していることに基づいて宣伝や同様の処理を申し出るプロセスを呼び出すことができる。
【００５４】
複雑なリスナーは、基本的なリスナーの構成として生成される。例えば、ある購入注文のリスナーは、前段落で述べたリスト・リスナーを含んでいたり呼び出すことができるし、リスト・メンバーは、かれら自身を呼び出すこともできる。リスナーが実行するアプリケーションは、本来のＸＭＬプロセスまたは本来のＪＡＶＡプロセスの可能性が低いことに注意すべきである。これらの場合、オブジェクトは、受信する取引アプリケーションが要求する形式に変換されるであろう。そのアプリケーションが処理を完了するとき、その出力は、ネットワークの他のノードに対する通信のためにＸＭＬフォーマットに変換し直される。
【００５５】
上述したような、マーケット参加者ドキュメントタイプ記述および取引ドキュメントタイプ記述には、ドキュメントの論理要素のための概略マッピングを含むとともに、自然言語に基づくマークアップ言語を含む。自然言語マークアップ、およびＸＭＬの他の自然言語属性は、ビジネス・インタフェース定義・サービス記述・入出力ドキュメント記述の仕様について、ＸＭＬ型マークアップ言語の使用を容易にする。
【００５６】
参加者モジュール３０３は、ビジネス・インタフェース定義を記憶することに加えて、入力ドキュメントの論理構造に一致する取引プロセス・フロントエンド３０４が使用するオブジェクトや他のデータ構造をコンパイルしたり、トランスレータ３０２をコンパイルするために用いるコンパイラを含む。その結果、参加者が関係する取引の変遷に応じて、ビジネス・インタフェース定義がその参加者によって変更されたり更新されたりするとき、トランスレータ３０２及びパーサー３０１は、自動的にアップデートに保たれる。
【００５７】
好ましいシステムにおいては、ＪＡＶＡイベントは、ＳＧＭＬのグローブモデル(grove model)、主として、各エレメント（要素）の“property set”によって拡張された標準のエレメント・ストラクチャー・インフォーメーション・セットに対応するコンパイラによって生成される−Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄ  ＩＳＯ／ＩＥＣ  １０１７９：１９９６（Ｅ），Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ−−Ｐｒｏｃｅｓｓｉｎｇ  Ｌａｎｇｕａｇｅ−−Ｄｏｃｕｍｅｎｔ  Ｓｔｙｌｅ  Ｓｅｍａｎｔｉｃ  ａｎｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＤＳＳＳＬ）。
ＸＭＬドキュメントをプロセスのためイベントに変えることは、パーサーの出力が内部データ構造として維持される構文解析の通常モデルとは異なる。ＪＡＶＡイベント又は、各ノードの取引処理フロントエンドが使用するのに適した他のプログラミング構造に、ＸＭＬドキュメント要素を変換することにより、取引されるべきドキュメントを用いるノードで、豊富な機能性を利用できるようになる。
【００５８】
よって、取引プロセス・フロントエンド３０４は、システムの他のリスニングプログラムについての知識やインパクトが無くても、新たなリスナープログラムを加えることを可能にするパブリッシュ(publish)及び加入者アーキテクチャにおいて動作できる。図３の各リスナー３０５、３０６、３０７、３０８は、フロントエンド３０４がイベントを指揮するキュー(queue)を保持する。これは、多数のリスナーがそれら自身のペース(pace)で併行してイベントを取り扱うことができるようにする。
【００５９】
さらにまた、本発明によれば、リスナーが実行するアプリケーションは、本来のＸＭＬ機能（ファンクション）、または入力ドキュメント形式に一致する本来の機能である必要はない。むしろ、取引プロセス・フロントエンド３０４がＪＡＶＡインタフェースである場合には、これらのリスナーは、ＪＡＶＡ機能であり、或いは固有の取引処理アーキテクチャに従って実行する機能である。これらの場合において、オブジェクトは、受信アプリケーションが必要とする形式に変換されるであろう。リスナーのアプリケーションが完了するとき、その出力は、モジュール３０３におけるビジネス・インタフェース定義が特定するようなドキュメント形式に変換し直される。その結果、トランスレータ３０２は、合成されやドキュメントを出力として提供するために、ネットワーク・インタフェース３００に直接的に結合される。
【００６０】
取引処理フロントエンドに結合されたリスナーは、入力ドキュメントのためのリスナー・入力ドキュメントの特定要素（エレメント）のためのリスナー・入力ドキュメントの特定のエレメントに記憶された属性のためのリスナーを含む。これは、入力ドキュメントをフィルタリングしたり応答するための特定のノードで、取引プロセスの実行を多様化し且つフレキシブルにするものである。
【００６１】
図４は、図３のシステムのための入力ドキュメントを受信し処理するためのプロセスを例示している。したがって、本プロセスは、ネットワーク・インタフェースでドキュメントを受信することで始まる（ステップ４００）。パーサーは、ビジネス・インタフェース定義に応答してドキュメントタイプ（４０１）を識別する。ＸＭＬフォーマットでドキュメントのためのＤＴＤを記憶するビジネス・インタフェース定義を使用して、ドキュメントは構文解析される（ステップ４０２）。次に、ドキュメントの要素（エレメント）および属性は、ホストのフォーマットに変換される（ステップ４０３）。この例では、ＸＭＬ論理構造は、getおよびset関数などのデータに関連した方法とともに、ＸＭＬエレメントのデータをもたらすＪＡＶＡオブジェクトに変換される。次に、ホストオブジェクトは、ホスト取引処理フロントエンドへ転送される（ステップ４０４）。これらのオブジェクトは、パーサーおよびトランスレータによって示されるイベントに応答して、プロセスに送信される。ドキュメント要素を受信するプロセスが実行され且つある出力を生成する（ステップ４０５）。その出力は、ビジネス・インタフェース定義によって定められる出力ドキュメントのフォーマットに変換される（ステップ４０６）。この例では、トランスレーションは、ＪＡＶＡオブジェクト形式からＸＭＬドキュメント形式に遷移する。最後に、出力ドキュメントは、ネットワーク・インタフェースを介して送信先に転送される（ステップ４０７）。
【００６２】
図５は、図３のシステムのためのイベント発生器／イベントリスナーのメカニズムの詳細図をあらわす。一般に、図５に示された手法は、ＪＡＶＡ  ＪＤＫ１．１イベントモデルの改良である。このモデルにおいて、３種類のオブジェクトが考慮される。第１のオブジェクトは、イベントの生成に関する情報を含むイベントオブジェクトである。生じ得る異なるイベントの全種類に対応して、任意の数の種類のイベントオブジェクトが有る。第２のオブジェクトは、何かが起こった時に活動をモニタし、イベントオブジェクトを生成するイベント発生器である。第３は、イベント発生器により生成されたイベントオブジェクトを聞くイベントリスナーである。イベントリスナーは一般に、特定のウインドウ上でマウスクリックなどの特定のイベント発生を知ろうとする。イベントリスナーは、イベント発生器上に「イベントリスナーを加える」方法をコールする。このモデルは、図３の環境に適合させることができ、ＸＭＬドキュメントにより代表されるようなオブジェクトのグラフを辿りそして構文解析することに応答して、オブジェクトを発生する。
【００６３】
図５に示されるシステムは、一般的なＸＭＬパーサー５００を有する。このようなパーサーは、標準の呼び戻し(call back)モデルを使用して実現できる。構文解析イベントが発生する時に、パーサーはアプリケーションオブジェクト内で特定の方法を呼出し、パラメータ内の適当な情報を渡す。従って、単一のアプリケーション５０１がパーサーと共に存在する。アプリケーションは、パーサーが提供する情報をＸＭＬイベントオブジェクト内にパッケージし、そしてブロック５０２により示されるように、それを自身により識別された数だけのイベントリスナーに送る。イベント５０２の組は完全にパーサーから独立している。イベント５０２は、どんな数のマシン上のどんな数のリスナーおよびどんな数のスレッドにも供給されることができる。イベントは１つの代替形式においては、エレメント構造情報セット（ＥＳＩＳ）に基づいている。従って、これらはエレメントの開始および終了などのようなドキュメント構造または属性の認識のような重要な観点のリストからなる。ＸＭＬ（そしてＳＧＭＬ）パーサーは一般にＥＳＩＳ構造をパーサーがそのアプリケーションに戻るための情報のデフォルトセットとして使用する。
【００６４】
特定ＥＳＩＳリスナー５０３は、イベント５０２の組に結合される。このリスナー５０３はＥＳＩＳリスナーＡＰＩを実現し、そして１または複数からの発生器からの全てのＸＭＬイベントを聞く。１つのエレメントイベント発生器５０４は特定ＥＳＩＳリスナーで、ＸＭＬイベント発生器でもある。そのリスナーは、特定のタイプのエレメントに対するイベントにのみ興味があるオブジェクトである。例えば、ＨＴＭＬ環境においては、リスナーは指示されたリストのみ、すなわち、＜ＯＬ＞と＜／ＯＬ＞タグの間のドキュメントの部分のみに興味を有する。他の例では、リスナーは上の例のドキュメントから共通ビジネス言語に従って「ｐａｒｔｙ．ｎａｍｅ」エレメントまたは「ｓｅｒｖｉｃｅ．ｎａｍｅ」要素のみを聞き、要素のための図式的マッピングに一致するデータを要素がもたらすことを確実にするために要素を処理し、そして受取ノードにおいて必要とされるプロセスに従って反応する。
【００６５】
これは、システムが、価格を合計するだけのようなドキュメントの特定部分のみを聞く小さいオブジェクトを有することを可能にする。リスナーが発生器からそれら自身を加えるまたは取除くことができるから、ＨＴＭＬドキュメントの例えば＜ＨＥＡＤ＞部分のみを聞くリスナーも存在できる。この理由およびＸＭＬドキュメントの高い反復性の理由により、高い目標的なコードを書くことおよび併発的なリスナーを書くことができる。例えば、＜ＯＬ＞リスナーは＜ＵＬ＞（指示されていないリスト）リスナーがその＜ＬＩ＞リスナーを設定する方法とは完全に分離して＜ＬＩ＞リスナーを設定することができる。代替方法として、図形ユーザインタフェースを発生するリスナーおよび同じ入力を使用するデータベースを探索する別のリスナーを作成できる。従って、アプリケーションが一度に１つずつ検査する完成されたデータ構造とは反対に、ドキュメントはリスナーにより実行されるプログラムとして取扱われる。もし、アプリケーションがこの方法で書かれると、アプリケーションを実行するために全ドキュメントをメモリ内に持つ必要が無い。
【００６６】
イベント５０２の組に結合された次のリスナーは、属性フィルタ５０５である。エレメントフィルタ５０４に似て属性フィルタ５０５は、ＥＳＩＳリスナーモデルに従い属性イベント発生器である。属性フィルタのためのリスナーは、それが興味を持つ属性を指定し、そして、指定された属性を持つあらゆる要素のためのイベントを受取る。例えば、フォントマネージャは例えば＜Ｐ  ＦＯＮＴ＝“Ｔｉｍｅｓ  Ｒｏｍａｎ”／Ｐ＞のようなフォント属性を持つエレメントのためだけのイベントを受取るだろう。
【００６７】
エレメントイベント発生器５０４は、エレメントリスナー５０４Ａを特殊化するためにそのようなエレメントオブジェクトを供給する。
【００６８】
属性イベント発生器５０５は属性イベントオブジェクトを属性リスナー５０５Ａへ供給する。同様に、属性オブジェクトは一のドキュメント形式から別へ属性を使用してＳＧＭＬ／ＸＭＬ変形する意味で「アーキテクチュア」に供給される。従って、５０５Ｂのアーキテクチュアは、特定の名前を持った特定の属性を識別できるようにする。その定義された属性を持ったエレメントのみが出力ドキュメントの部分になり、そして出力ドキュメント内の要素（エレメント）の名前は、入力ドキュメント内の属性の値である。例えば、もしアーキテクチュア５０５ＢがＨＴＭＬであり、ストリングを、
＜ＰＵＲＣＨＡＳＥＳ  ＨＴＭＬ＝“ＯＬ”＞＜ＩＴＥＭ  ＨＴＭＬ＝“ＬＩ”＞＜ＮＡＭＥ  ＨＴＭＬ＝“Ｂ”＞ＳＴＵＦＦ＜／ＮＡＭＥ＞＜ＰＲＩＣＥ  ＨＴＭＬ＝“Ｂ”＞１２３＜／ＰＲＩＣＥ＞＜／ＩＴＥＭ＞＜／ＰＵＲＣＨＡＳＥ＞
変換（翻訳）すると、
＜ＯＬ＞＜ＬＩ＞ＳＴＵＦＦ＜／Ｂ＞＜Ｂ＞１２３＜／Ｂ＞＜／ＬＩ＞＜／ＯＬ＞
となり、正しいＨＴＭＬである。
【００６９】
イベント５０２の組に結合された次のモジュールはツリー（木）ビルダー５０６である。ツリービルダーはＸＭＬイベントのストリームを取り、下部のドキュメントのツリー（木）表現を発生する。ツリービルダー５０６の一つの好ましい形式は、Ｗ３Ｃ（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／１９９８／ＷＤ−ＤＯＭ−１９９８０７２０／ｉｎｔｒｏｄｕｃｔｉｏｎ．ｈｔｍｌ）の仕様に従ってドキュメントオブジェクトモデルＤＯＭオブジェクト５０７を発生する。イベントストリーム内のリスナーは大部分の要求を処理するのに使用できるが、ツリー形式はドキュメント回りの質問をサポートするため、ノードを再順序付けるため、新ドキュメントの作成、例えばドキュメントを多数回構文解析するような、そこから同じイベントストリームを複数回発生できるメモリ内のデータ構造をサポートするのに役立つ。特定ビルダー５０８は、特定の実施に適合するようなドキュメントの部分の特別なサブツリーを作るために、ツリービルダー５０６に結合できる。
【００７０】
入力するドキュメントに応答するのに加えて、ＸＭＬイベント５０２の他のソースも供給することができる。従って、イベントストリーム５１０は、ＤＯＭオブジェクトのツリー上を歩くことにより、そしてドキュメントが構文解析されていた時に作成された元のイベントストリームを再発生することにより発生される。これは、システムにより、ドキュメントが数回構文解析されている外観を与えることを可能にする。
【００７１】
ツリーを辿りそしてイベントのストリームを発生するオブジェクトの観念は、ＤＯＭオブジェクトのツリーを越えて質問できるオブジェクトのいかなるツリーにも一般化できる。したがって、ＪＡＶＡウォーカー５１２は、ＪＡＶＡビーン(bean)コンポーネント５１３のツリーを辿るアプリケーションでもよい。ウォーカーは全ての公開されているフィールドおよび方法上を辿る。ウォーカーは終わりの無いサイクルに入り込まないことを確保するために、既に訪問したオブジェクトの軌跡を記憶する。ＪＡＶＡイベント５１４は、ＪＡＶＡウォーカー５１２により発生されるイベントのタイプである。これは現在、オブジェクトから引き出すことのできる情報の種類の大部分を含む。これは、ＥＳＩＳのＪＡＶＡの均等物であり、そして、特にＪＡＶＡビーンズであるのだけれども、ＸＭＬに適用されたのと同じプログラム手法をＪＡＶＡオブジェクト一般に適用することを可能にする。
【００７２】
ＸＭＬイベント発生器５１５に対するＪＡＶＡは、ＪＡＶＡリスナーとＪＡＶＡイベント発生器から構成される。これは、ＪＡＶＡウォーカー５１２からイベントのストリーム５１４を受取り、そしてＸＭＬドキュメントとしてＪＡＶＡオブジェクトを供給するために選択されたものを変換（翻訳）する。好ましい実施例において、イベント発生器５１５はＪＡＶＡビーンズＡＰＩを利用する。見られた各オブジェクトはエレメントとなり、エレメント名はクラス名とおなじである。そのエレメント内で、各埋め込まれた方法もまたエレメントとなり、その内容は方法を呼び起こすことにより戻された値である。もしそれがオブジェクトまたはオブジェクトの配列であると、これらは交互に辿られることになる。
【００７３】
図６は、図５のフレームワーク上に構築された特定のアプリケーションの概略図である。このアプリケーションは、ＸＭＬドキュメント６００を取り込み、これをパーサー／発生器（構文解析ルーチン発生システム）６０１に適用する。ＥＳＩＳイベント６０２を発生し、且つ属性発生器６０３及びツリービルダー６０４に供給される。属性発生器は図５の発生器に対応する。この発生器５０５は、イベントを、例えば、ＸＭＬ入力からＨＴＭＬ出力に変換（翻訳）するための“アーキテクチャ”５０５Ｂに送る。これらのイベントは、ブロック６０５によって示される様に並列で処理され、且つリスナーによって処理される。リスナーの出力はドキュメントライター６０６に供給され、出力のためにＸＭＬフォーマットに戻し変換（翻訳）される。従って、例えば、図６に示されるこのアプリケーションは、ＸＭＬドキュメントを取り入れ、或るフォームを有するＨＴＭＬドキュメントを出力する。このフォームは次にブラウザに送られ、その結果がＸＭＬに戻し変換される。この運用のために、アーキテクチャコンセプトは、ＸＭＬからＨＴＭＬへのマッピングを提供する。図６に含まれる３つのアーキテクチャは、テーブル及びリストなどのＨＴＭＬドキュメントの構造を与えるためのもの、ブラウザドキュメント上の入力フィールド用のラベルなどの表示されるべきドキュメントを特定する第２のもの、及び入力フィールド自体を記述する第３のものを含む。ＸＭＬドキュメント構造を維持するのに必要となるＸＭＬドキュメントのエレメントは、ＨＴＭＬフォーム内では不可視のフィールドとなる。このことは、サーバに送り戻されるＨＴＴＰポストメッセージにクライアントが入れる情報からＸＭＬドキュメントを再構成する際の使用に有用である。これらのイベントを聴取するリスナーが、ＨＴＭＬドキュメント用のイベントを出力する。このドキュメントは、ドキュメントライターオブジェクトへと進む。ドキュメントライターオブジェクトはＸＭＬイベントを聴取し、それらをＸＭＬドキュメントに戻す。ドキュメントライターオブジェクトは、この例におけるアーキテクチャを聴取している全てのエレメント発生器に対するリスナーである。
【００７４】
図５及び６に図示される処理モジュールの構成は、図３のシステム用のパーサー及びトランザクションプロセスフロントエンドの或る実施の形態を表している。理解できる様に、極めて柔軟性のあるインタフェースが与えられ、これによってダイバース（変更）トランザクションプロセスを、入力するＸＭＬドキュメント、又は他の構造化ドキュメントフォーマットに応答して、実行することができる。
【００７５】
図７は、ビジネス・インタフェース定義ビルダーモジュール７００を含むことを除いて、図３と類似のノードを図示している。従って、図７のシステムは、ネットワーク・インタフェース７０１、ドキュメントパーサー７０２、及びドキュメントトランスレータ７０３を含む。トランスレータ７０３は、その出力をトランザクション処理フロントエンド７０４へ出力する。このフロントエンドは、コマーシャル機能部７０５、データベース７０６、エンタープライズ機能部７０７、及び他の一般リスナー及びプロセッサ７０８のようなリスニング機能に結合される。図７に図示される様に、ビジネス・インタフェースビルダー７００は、ユーザインタェース、共通ビジネス・ライブラリＣＢＬリポジトリ、相補的ビジネス・インタフェース定義を読むためのプロセス、及びコンパイラを含む。ユーザインタフェースは、ビジネス・インタフェース定義の構築における計画を、共通ビジネスライブラリリポジトリ及び相補的ビジネス・インタフェースの定義を読み出す能力に依存して、補助するのに使用される。従って、相補的ビジネス・インタフェース定義の入力ドキュメントは、特定のトランザクションの出力ドキュメントとして特定することができ、相補的ビジネス・インタフェース定義の出力ドキュメントがトランザクションプロセス等の入力として特定することができる。同様なやり方で、トランザクションビジネス・インタフェース定義は、ＣＢＬリポジトリから選択された構成要素を使用して構成することができる。ＣＢＬリポジトリの使用は、上述の例示スキーマ（ｂｉｄ１）ドキュメントなどの標準ドキュメント形式、及びネットワーク内の他の人間によって容易に採用されることのできるビジネス・インタフェース定義を構築することにおける論理構造及び解釈情報の使用を容易くする。
【００７６】
ビジネス・インタフェース定義ビルダー７００は、トランスレータ７０３、ホストトランザクション処理アーキテクチャに従って、トランスレータによって処理されるべきオブジェクトを発生し、構文解析機能７０２を管理するために使用されるコンパイラも含む。
【００７７】
図８は、ビジネス・インタフェース定義ビルダー７００のリポジトリ内に記憶される論理構造を示すヒューリスティックダイアグラムである。したがって、パーティビジネス・インタフェース定義８００を表すリポジトリ記憶は、例えば、消費者ＢＩＤ８０１、カタログハウスＢＩＤ８０２、ウェアハウスＢＩＤ８０３、及びアクションハウスＢＩＤ８０４を含む。したがって、オンラインマーケットにおける新たな参加者は、そのビジネスと最もよく適合する標準化されたＢＩＤの一つを、基本インタフェース定義として選択する。更に、リポジトリは一組のサービスビジネス・インタフェース定義８０５を記憶する。例えば、注文エントリＢＩＤ８０６、注文トラッキングＢＩＤ８０７、注文履行ＢＩＤ８０８、及びカタログサービスＢＩＤ８０９を記憶することができる。マーケットにおける新たな参加者がビジネス・インタフェースの定義を構築する際に、リポジトリ内に記憶される標準化されたサービスのビジネス・インタフェース定義を選択することができる。
【００７８】
パーティ及びサービスＢＩＤに加えて、入力及び出力ドキュメントＢＩＤを、フィールド８１０によって指示されるリポジトリに記憶する。したがって、購入注文ＢＩＤ８１１、請求書ＢＩＤ８１２、見積り要求ＢＩＤ８１３、製品入手可能リポートＢＩＤ８１４、及び注文状態ＢＩＤ８１５をリポジトリに記憶することができる。
【００７９】
リポジトリは、好ましいシステムにおいては、ＸＭＬに従ったドキュメント形態の定義として特定されるビジネス・インタフェースの定義に加えて、フィールド８１６によって指示されるようなセマンティック（意味）マップの形態で解釈情報を記憶する。したがって、重量８１７、通貨８１８、サイズ８１９、製品識別８２０、及び製品特徴８２１を特定するために使用されるセマンティックマップをリポジトリ内に記憶することができる。更に、解釈情報は、ドキュメントの論理構造内のデータ構造を分類分けを提供する。
【００８０】
更に、ビジネス・インタフェースの定義を構成する際に使用される論理構造は、ブロック８２２によって指摘されるリポジトリに記憶される。したがって、アドレス情報８２３を与えるためのフォーム、価格情報８２４を与えるためのフォーム、契約上関係の期間８２５を与えるためのフォームを提供することができる。ネットワークが拡張される時、ＣＢＬリポジトリも同様に拡張し、標準化は、新たな参加者が加わること及びビジネス・インタフェースの定義をより容易にする。
【００８１】
図９は、図７のシステムを使用するビジネス・インタフェース定義を構築するプロセスを図示している。プロセスは、ＢＩＤビルダー・グラフィカルインタフェースをユーザに表示することによって開始する（ステップ９００）。システムは、グラフィカルインタフェースによって発生させた参加者、及びサービス／ドキュメント情報を識別するユーザ入力を受信する（ステップ９０１）。
【００８２】
次に、ユーザ入力に応答して、参照論理構造、解釈情報、ドキュメント定義、及び／又はサービス定義が、グラフィカルユーザーインタフェースを介してリポジトリから検索される（ステップ９０２）。次のステップで、相補的ビジネス・インタフェース定義又はビジネス・インタフェースの定義の構成要素が、カスタム化された検索エンジン、ウェブブラウザ、又は他の方法によって、ユーザ入力を介して選択されたネットワーク内の他の参加者からアクセスされる（ステップ９０３）。参加者に対するドキュメントの定義を、集められた情報を使用して発生させる（ステップ９０４）。コンパイラは、ドキュメントからホストへ、及びホストからドキュメントのマッパー(mappers)に対するトランスレータを発生させる（ステップ９０５）。また、コンパイラは、定義に対応するホスト・アーキテクチャデータ構造を発生させる（ステップ９０６）。そして発生されたビジネス・インタフェースの定義は、ウェブサイト又は他の場所にポスト送付することによりネットワーク上にポスト送付され、ネットワーク内の他のノードにアクセス可能とされる。（ステップ９０７）。
【００８３】
ビジネス・インタフェースの定義は、潜在的な商業パートナーに対して企業が提示したオンライン・サービスを伝え、且つこれらのサービスを実施するのに使用するドキュメントを伝える。したがって、ビジネス・インタフェースの定義で定義したサービスが、ドキュメントによって定められる。このことは、ＸＭＬサービス定義の以下に示す部分に例示されている。
【００８４】
2008084328.tif 000120
2008084328.tif 000121
【００８５】
このＸＭＬ部分（ｆｒａｇｍｅｎｔ）は、２つの処理からなるサービス、すなわち、１つは注文（ｏｒｄｅｒ）を取得する処理、及びもう１つはそれに追従する処理を定義する。それぞれの定義は、もし正当な要求が特定のＷｅｂアドレスに提示されたなら、サービスを実行するための契約（ｃｏｎｔｒａｃｔ）又は約束（ｐｒｏｍｉｓｅ）を表現する。ここで注文サービスは、リポジトリに置かれた標準の“ｐｏ．ｄｔｄ”ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）に一致する入力されるドキュメントを必要とする。それは、ローカルであっても、或いはネットワーク上の産業に関係する広範囲なレジストリ内に記憶されたものでもよい。もし１つのノードがその注文を実行できるなら、そのノードは、その定義がローカルなカスタマイズされた「ｉｎｖｏｉｃｅ．ｄｔｄ」に一致するドキュメントを返すであろう。実際には、企業は、宣言されたＸＭＬ仕様に一致する購入注文を提出できる誰とでも、ビジネスを行う約束をしている。事前の調整は不要である。
【００８６】
ＤＴＤは、所定のタイプのドキュメントのための正式仕様すなわち文法であり、それは、要素、属性、及び表示されなければならない状態を記述する。例えば、購入注文は、典型的には、購入者及び販売者の名前や住所、一組の製品説明、並びに価格や配達日などの関連する売買条件を含む。電子データ交換（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ，ＥＤＩ）は、例えばＸ１２  ８５０仕様では、購入注文のために普通に使用されるモデルである。
【００８７】
リポジトリは、多くのビジネス領域に対し、再使用可能であって且つ共通のセマンティック（意味的な）構成要素から、ＸＭＬドキュメントモデルを開発することを容易にする。そのようなドキュメントは、たとえそれらが全く異なっていると見えても、共通のメッセージ要素から理解することができる。これは、共通ビジネスライブラリリポジトリの役割を果たしている。
【００８８】
共通ビジネスライブラリリポジトリは、以下のものを含む汎用的ビジネス概念のための情報モデルからなる。即ち、
・企業、サービス、及び製品のようなビジネス記述プリミティブ、
・カタログ、購入注文、及び請求書のようなビジネス形式、
・日時、位置、分類コードなどの標準の指標、
である。
【００８９】
この情報は、企業がＸＭＬアプリケーションを迅速に開発するためにカスタマイズ化し且つ組み立てができる拡張可能な公式のＸＭＬ構成ブロックとして表わされる。アトミック（ａｔｏｍｉｃ）なＣＢＬ要素は、国・通貨・住所・時間に関する標準ＩＳＯコードなどのメッセージ規格及び協定を実装する。低レベルのＣＢＬセマンティクス（意味論）は、Ｄｕｂｌｉｎ  Ｃｏｒｅ等のインターネット・リソースのメタデータ構成を分析することからも得られる。
【００９０】
次のレベルの要素は、これらの構成ブロックを使用して、ＯＴＰ（Ｏｐｅｎ  Ｔｒａｄｉｎｇ  Ｐｒｏｔｏｃｏｌ）及びＯＢＩ（Ｏｐｅｎ  Ｂｕｙｉｎｇ  ｏｎ  ｔｈｅ  Ｉｎｔｅｒｎｅｔ）等の既にあるインターネット規格で使用されるビジネス形態だけでなく、Ｘ１２  ＥＤＩ取引で使用されるような基本的なビジネス形態も実装する。
【００９１】
ＣＢＬの焦点は、全てのビジネス領域（企業・サービス・製品などの基本的なビジネス記述；カタログ・購入注文・請求書などのビジネス形式；標準指標・日時・位置・分類コード）に共通の機能及び情報にある。ＣＢＬは、意味論のための規格又は業界協定上に構築されている（例えば、ヨーロッパでの「日／月／年」に対してアメリカでの「月／日／年」を特定するルールは、別個のＣＢＬモジュールでエンコードされてしまう）。
【００９２】
ＣＢＬは、アプリケーションを設計するために使用される言語である。それは、ＸＭＬの“ドキュメント世界”と、ＪＡＶＡの“プログラミング世界”或いは他の取引処理アーキテクチャとの間のギャップを埋めるように設計されている。スキーマは、“ドキュメントを備えたプログラミング”の思想を具体化する。その思想においては、ドキュメントタイプの詳細な正式仕様は主なソースであり、当該ソースから多くの関連する形式が生成される。これらの形式は、ＣＢＬ、ＪＡＶＡオブジェクト、対応のＪＡＶＡオブジェクトへ／対応のＪＡＶＡオブジェクトからＸＭＬインスタンスを変換するためのプログラム、及びサポート・ドキュメントのためのＸＭＬ  ＤＴＤを含む。
【００９３】
ＣＢＬは単一のソースを生成し、そこからシステムのほとんど全ての部分が自動的にコンパイラによって生成される。ＣＢＬはＳＧＭＬ／ＸＭＬを拡張することによって機能し、それは、特定のドキュメントタイプの構造を正式に定義するため、そしてそれぞれの情報の要素及び属性と関連するセマンティクス（意味的な）仕様を含むために、使用されるのが通常である。任意の種類のデータ型を宣言するために、ＳＧＭＬ／ＸＭＬにおける（ほとんどの）制限キャラクタタイプを拡張することができる。
【００９４】
以下は、“ｄａｔｅｔｉｍｅ”モジュール用のＣＢＬ定義からの一部である。
2008084328.tif 000122
2008084328.tif 000123
【００９５】
この一部には、要素“ｙｅａｒ”が、キャラクタ・データとして定義され、“ｓｃｈｅｍａ”属性と関連する。また、キャラクタ・データは、ＩＳＯ８６０１規格の３．８章である”ｙｅａｒ”用のスキーマを定義する。
【００９６】
この“ｄａｔｅｔｉｍｅ”ＣＢＬモジュールは、実際にはスキーマＤＴＤのインスタンスとして定義される。最初に、モジュール名が定義される。次に、“ｄａｔｅｔｉｍｅ”要素の“ＹＥＡＲ”は、ＩＳＯ８６０１規格の意味に結びつけられる。
【００９７】
2008084328.tif 000124
2008084328.tif 000125
【００９８】
また、上述した例示のマーケット参加者及びサービスモジュールは、ＣＢＬリポジトリ中に記憶される。
【００９９】
図１０では、航空貨物受取証（Ａｉｒｂｉｌｌ）１０００が、一般的な購入注文ＤＴＤ１００１をカスタマイズし、出荷重量１００２についての具体的な情報を追加することによって定義されている。一般的な購入注文１００１は、当初、住所、日時、通貨、販売者及び製品記述のためのＣＢＬモジュールから徹底的に組み立てられるものだった。ＣＢＬを使用することにより、ＸＭＬ商用アプリケーションの実現は格段にスピードアップされる。より重要なことは、ＣＢＬによって、商用アプリケーションを相互接続することが簡単になるということである。
【０１００】
ＣＢＬでは、ＸＭＬはスキーマにより拡張される。この拡張は、内容を簡単に認証できるようにするため、ＸＭＬ要素に対する強い型付けを追加する。例えば、＜ＣＰＵ ｃｌｏｃｋ ｓｐｅｅｄ＞と呼ばれる要素（エレメント）は、一組の有効値｛１００，１３３，１６６，２００，２３３，２６６Ｍｈｚ｝を有する整数として定義することができる。また、スキーマは、情報をクラスの定義から簡単にインスタンス生成化できるようにするため、クラス−サブクラスの階層化を追加する。例えば、ラップトップは、ディスプレイのタイプ及びバッテリ寿命等の特徴のための追加タグを有するコンピュータとして記述されることができる。これらの拡張及び他の拡張により、ＸＭＬと伝統的なオブジェクト指向及びリレーショナルデータモデルの間の自動変換だけでなく、データ入力も容易になる。
【０１０１】
その結果、上述したように、完成されたＢＩＤは、参加者及びサービスの実際のインスタンス、ＤＴＤインスタンスの論理構造に一致するＪＡＶＡビーンズ（ｂｅａｎｓ）、及びＸＭＬからＪＡＶＡ／ＪＡＶＡからＸＭＬに変換する変換コードのためのＤＴＤを作り出すコンパイラを介して実行される。他のシステムでは、オブジェクトを使用しやすくするために、ユーザインタフェース上のディスプレイのために、或いはユーザによる印刷のために、ドキュメントが生成される。
【０１０２】
上述した例示のマーケット参加者及びサービスＤＴＤについて、コンパイラが生成したＪＡＶＡビーンズは、（簡潔のためいくつかの修正を加えて）以下のように示される。
2008084328.tif 000126
2008084328.tif 000127
2008084328.tif 000128
2008084328.tif 000129
2008084328.tif 000130
2008084328.tif 000131
2008084328.tif 000132
2008084328.tif 000133
2008084328.tif 000134
2008084328.tif 000135
2008084328.tif 000136
2008084328.tif 000137
2008084328.tif 000138
2008084328.tif 000139
2008084328.tif 000140
2008084328.tif 000141
2008084328.tif 000142
2008084328.tif 000143
2008084328.tif 000144
2008084328.tif 000145
2008084328.tif 000146
2008084328.tif 000147
2008084328.tif 000148
2008084328.tif 000149
2008084328.tif 000150
2008084328.tif 000151
2008084328.tif 000152
2008084328.tif 000153
2008084328.tif 000154
2008084328.tif 000155
2008084328.tif 000156
2008084328.tif 000157
2008084328.tif 000158
2008084328.tif 000159
2008084328.tif 000160
2008084328.tif 000161
2008084328.tif 000162
2008084328.tif 000163
2008084328.tif 000164
2008084328.tif 000165
2008084328.tif 000166
2008084328.tif 000167
2008084328.tif 000168
2008084328.tif 000169
上記したＪＡＶＡビーンに加えて、変換コードは以下に示されているように、ＪＡＶＡからＸＭＬへ、及びＸＭＬからＪＡＶＡへ変換するため作られる。
2008084328.tif 000170
2008084328.tif 000171
2008084328.tif 000172
2008084328.tif 000173
2008084328.tif 000174
2008084328.tif 000175
2008084328.tif 000176
2008084328.tif 000177
2008084328.tif 000178
2008084328.tif 000179
2008084328.tif 000180
2008084328.tif 000181
【０１０３】
ドラッグ(drag)、ドロップ(drop)、及びフォーム編集のユーザインタフェースを提供するＢＩＤ構成アプリケーションと一緒にツールを使用して、開発者は、ビジネス・インタフェース定義を作り出したり、その上手く生成された有効なビジネス・インタフェース定義を、ＸＭＬドキュメント形式で生み出すことができる。したがって、例示の実行インスタンスは、ＩＢＭからラップトップコンピュータを注文するために、イングラム・マイクロ（Ｉｎｇｒａｍ  Ｍｉｃｒｏ）及びその他が使用するＩＢＭのための注文サービス用のビジネス・インタフェース定義である。（出願人と、ＩＢＭ又はイングラム・マイクロの間には関係はない。）これらのプロセスを利用すると、ユーザは、本発明に従って定義されたドキュメントを使用して、ビジネス・インタフェースのプログラミングを可能とするシステムを構築することができる。
【０１０４】
ＸＭＬ／ＪＡＶＡ環境における本発明のＣＢＬ及びＢＩＤプロセッサの役割は、購入注文の以下に示す処理の説明によりさらに理解できるであろう。
【０１０５】
会社Ａは、ＣＢＬ  ＤＴＤ及びモジュールのライブラリを含む可視化プログラム環境を使用してその購入注文ドキュメントを定義する。共通のビジネス言語エレメントを使用してすべて定義され、データ型及び他の解釈情報が含まれるようになっている。会社Ａの購入注文は、ＣＢＬライブラリに付属する一般的な取引ドキュメント仕様に対して僅かなカスタマイズを含むかもしれないし、或いは、住所、日時、通貨等のためのＣＢＬモジュールから徹底的に構築することもできる。
【０１０６】
（上述したｔｒａｎｓａｃｔ．ｄｔｄのような）一般的な“取引ドキュメント”仕様のためのドキュメントは、ＣＢＬ仕様がモジュールから作られ、そして他のＣＢＬ  ＤＴＤと内部連結されるやり方の特徴をあらわしている。
【０１０７】
コンパイラは購入注文の定義を受取り、幾つかの異なる目標形式を発生させる。これらの目標形式のすべては、本来の仕様の“ツリー対ツリー（ｔｒｅｅ  ｔｏ  ｔｒｅｅ）”変換を介して得ることができる。この例にとって最も重要なのは、
（ａ）購入注文のためのＸＭＬ  ＤＴＤ、
（ｂ）購入注文のためのデータ構造を含むＪＡＶＡビーン（ＪＡＶＡクラス、引数、データ型、メソッド、及び購入注文のスキーマ定義における情報に一致して作り出された例外の構造。）、
（ｃ）購入注文ＤＴＤに準拠する購入注文を、購入注文ＪＡＶＡビーンに変換したり、或いはそれらをデータベースにロードしたり、或いはブラウザに購入注文を表示するＨＴＭＬ（又はＸＳＬスタイルシート）を作り出す“マーシャリング(marshaling)”プログラム、
（ｄ）購入注文ＪＡＶＡビーンからデータ値を抽出し、それらを購入注文ＤＴＤに準拠したＸＭＬドキュメントに変換する“アンマーシャリング(unmarshaling)”プログラム、である。
今、シナリオに戻ると、購入アプリケーションは、購入注文を受け入れる供給者のためのサービスインタフェースとして特定されたＤＴＤに従う購入注文を発生させる。
【０１０８】
パーサーは購入注文ＤＴＤを使用して、購入注文インスタンスを、エレメント及びそれが含む属性値についての情報ストリームに分解する。次に、これらの“property sets”は、ＪＡＶＡコードと重ねることにより、対応のＪＡＶＡイベントオブジェクトに変換される。実際、この変換は、ＤＴＤによってその文法が定義される顧客プログラム言語にある命令として、マークアップＸＭＬドキュメントの一部を取り扱う。これらのＪＡＶＡイベントは、コンパイラにより生成されたマーシャリングアプリケーションにより処理することができ、ＪＡＶＡビーンのデータ構造を“ロード”する。
【０１０９】
ＸＭＬドキュメントをＪＡＶＡアプリケーションのための一組のイベントに変換し処理することは、パーサーの出力が内部データ構造として維持され、且つ構文解析が完了するまで処理が開始しない通常のモデルの構文解析とは異なるものである。ＢＩＤ定義に応じて、イベントをベースとした処理が、プロセッサの非常に優れた機能性を利用可能にする鍵となる。なぜなら、最新のドキュメントアプリケーション処理が、最初のイベントが発せられるとすぐに開始できるからである。
【０１１０】
様々なタイプのイベントを“聞く”ＪＡＶＡプログラムは，それらのイベントのスキーマ定義から形成される。これらのリスナーは，ＣＢＬのＸＭＬ定義と関連するビジネス論理を実行するために作り出されたプログラムであり、例えば、“アドレス”エレメントと関連し、データベースをチェックすることにより郵便コードを認証するコードであってもよい。これらのリスナーは、ドキュメントルータによって登録することによりイベントに“加入”し、それらに興味を示したすべての加入者に対して関連のイベントを差し出す。
【０１１１】
この情報提供（パブリッシュ：publish)及び加入アーキテクチャは、新規のリスナープログラムが既存のプログラムに対して何の知識もなく、或いはインパクトを与えることもなく加えられることができる。各リスナーは、ルータがそのイベントを指揮するキュー(queue)を有し、複数のリスナーがそれら自身のペース(pace)で併行してイベントを取り扱うことができるようにする。
【０１１２】
例示の購入注文に関し、以下に示すもののためのリスナーがある。
・注文入力プログラムに接続する購入注文、
・在庫をチェックする製品説明書、
・宅配便又は他の配送サービスの可能性をチェックするアドレス情報、
・注文経緯をチェックすることができる購入者情報（クレジットを無価値にしているかどうかや、誰が消費者であるかを把握していることに基づいて宣伝や同様の処理を申し出ることのために）。
【０１１３】
複雑なリスナーは、基本的なリスナーの構成として生成される。例えば、ある購入注文のリスナーは、これらのリスナーを含んでいたり呼び出すことができるし、彼らはかれら自身を呼び出すこともできる。）
【０１１４】
図１１は、図１のネットワークにおけるマーケットマーカのノードを示している。マーケットマーカのノードは、図３のシステムの基本構造を含み、ネットワーク・インタフェース１１０１、ドキュメントパーサー１１０２、ドキュメントからホストへ／ホストからドキュメントへのトランスレータ１１０３、この例ではルータと称されるフロントエンド１１０４を有する。この例でのマーケットマーカモジュール１１０５は、一組のビジネス・インタフェース定義、又はマーケットの参加者のためマーケットマーカの機能をサポートするのに十分な他の識別子、ＣＢＬリポジトリ、及びマーケットの参加者の要求をすべて満たすコンパイラを備えている。ルータ１１０４は、参加者のレジストリ及びドキュメントフィルタを備え、それらはトランスレータの出力及びパーサーが生成したイベントに応答し、参加者のレジストリに従って且つＸＭＬイベント発生器に対するリスナーの間のエレメント及び属性フィルタに従って、入力ドキュメント転送する。したがって、マーケットのある参加者は所定のパラメータに適合するドキュメントを受信するよう登録することができる。例えば、特定のＤＴＤに従う入力ドキュメントは、ある閾値以上に購入された製品数、又は購入されるドキュメント要求の最大価格等の属性を含み、ルータ１１０４でドキュメントをフィルタするために使用される。次に、ルータ１１０４で参加者レジストリに登録された情報に合致するドキュメントだけが、登録された参加者に送られる。
【０１１５】
また、ルータ１１０４は、ローカルホストサービス１１０５,１１０６の要求を満たし、例えば、マーケットマーカのみならずマーケットの参加者として動作する。通常、ルータ１１０４により受信されたドキュメントは、送信先を決定するために追跡され、追跡されるべきそのようなドキュメントはその送信先に送られる。そして、再度、必要であれば、トランスレータ１１０３を経由して戻され、ネットワーク・インタフェース１１０１からそれぞれの送信先に送られる。
【０１１６】
マーケットマーカは一組の内部及び外部ビジネス・サービスを一緒に結びつけるサーバであり、仮想企業又は取引コミュニティを作り出す。サーバは入力ドキュメントを解析し、例えば、製品データのための要求をカタログサーバに渡すことにより、又は購入注文をＥＲＰシステムに送ることにより、適切なサービスを呼び出す。また、サーバは変換（翻訳）タスクを処理し、企業のＸＭＬドキュメントからの情報を、取引パートナーが使用するドキュメント形式に、そしてそのレガシーシステムが要求するデータ形式にマッピングする。
【０１１７】
上記サービスの定義に関して、企業が購入注文を提示したとき、サーバのＸＭＬパーサーは、購入注文ＤＴＤを使用して購入注文インスタンスを情報イベントのストリームに変換する。次に、これらのイベントは所与のタイプのイベントを処理するようプログラムされた任意のアプリケーションに送られる。ある場合に、インターネットを介して異なるビジネスに情報を完全に送る。購入注文の例では、幾つかのアプリケーションはパーサーからやってくる情報で機能する。
・注文入力プログラムは、完全なメッセージとして購入注文を処理する。
・ＥＲＰシステムは、その購入注文に記述された製品の在庫をチェックする。
・顧客データベースは、顧客のアドレスを検証したり更新したりする。
・運送会社はアドレス情報を使用し、配送を計画する。
・銀行はクレジットカード情報を使用し、トランザクションを許可する。
【０１１８】
取引パートナーは、彼らが交換するビジネスドキュメントの構造、内容及び順序について同意するだけでよく、ＡＰＩの詳細について同意する必要はない。ドキュメントがどのように処理されるか、どのようなアクションが結果として生じるかは、完全にサービスを提供するビジネス次第である。これは、システム・レベルからビジネス・レベルへの統合・編集を向上させる。それは、内部的な技術の遂行上、組織化上、又はプロセス上でビジネス変更があるにもかかわらず、明瞭で安定したインタフェースをそのビジネスパートナーに提供することを可能にする。
【０１１９】
図１２、１３及び１４は、図１１のシステムのマーケットメーカーノードで実行されるプロセスを示している。図１２において、ネットワーク・インタフェースで、発信参加者ノードからの入力ドキュメントを受信する（ステップ１２００）。ドキュメントがパースされる（ステップ１２０１）。そのドキュメントをホストのフォーマットに変換する。例えば、ＸＭＬからＪＡＶＡへと変換する（ステップ１２０２）。次に、ホストのフォーマット化されたイベント及びオブジェクトをルータサービスに送信する（ステップ１２０３）。ドキュメントのタイプや内容に従いドキュメントを受入れるために登録されたサービスを識別する（ステップ１２０４）。ドキュメント及びドキュメントの一部が、その識別されたサービスに送られる（ステップ１２０５）。ドキュメントの内容に応じてサービスを実行する（ステップ１２０６）。そのサービスの出力データが作られる（ステップ１２０７）。その出力データをドキュメントフォーマットに変換する。例えば、ＪＡＶＡフォーマットからＸＭＬフォーマットへ変換する（ステップ１２０８）。最後に、出力ドキュメントを参加者ノードに送る（ステップ１２０９）。
【０１２０】
登録サービスは、ルータが管理する機能の一つである。したがって、図１３に示すように、マーケット参加者ドキュメントがネットワーク・インタフェースで受入れられる（ステップ１３００）。マーケット参加者ドキュメントは、マーケットメーカーノードのためにビジネス・インタフェース定義リポジトリに記憶される（ステップ１３０１）。加えて、ドキュメントが構文解析される（ステップ１３０２）。構文解析されたドキュメントをホストのフォーマットに変換する（ステップ１３０３）。次に、そのドキュメントをルータサービスに送る（ステップ１３０４）。ルータサービスは、ドキュメントのタイプ及びドキュメントの内容に従い、上記登録サービスをドキュメントの宛先であるとして識別するリスナーを含む（ステップ１３０５）。ドキュメント及びドキュメントの要素（エレメント）を登録サービスに送る（ステップ１３０６）。登録サービスにおいて、ビジネス・インタフェース定義に従い、必要とされるサービス仕様を検索する（ステップ１３０７）。ステップ１３０８で、サービス仕様が集められた場合には、ビジネス・インタフェース定義及びサービス仕様に従ってルータサービスフィルタがセットされる（ステップ１３０９）。登録に対する肯定応答のデータが生成される（ステップ１３１０）。この肯定応答のデータをドキュメントフォーマットに変換する（ステップ１３１１）。最後に、マーケットメーカーで登録が上手くいったことを参加者に通知するために、肯定応答のドキュメントを参加者ノードに送信する（ステップ１３１２）。
【０１２１】
ステップ１３０７で、必要なサービス仕様を集めるプロセスが図１４の一例として示されている。このプロセスは、マーケット参加者によりサポートされるサービスビジネス・インタフェース定義を探し出すことにより開始する（ステップ１４００）。例えば、リポジトリノードに対するＥメールトランザクション又はウェブアクセスにより、サービス定義を検索する（ステップ１４０１）。サービス仕様がＢＩＤリポジトリに記憶される（ステップ１４０２）。サービスビジネス・インタフェース定義ドキュメントが構文解析される（ステップ１４０３）。構文解析されたドキュメントをホストのフォーマットに変換する（ステップ１４０４）。次に、ホストのオブジェクトがルータサービスへ送られる（ステップ１４０５）。ドキュメントのタイプ及び内容に従い、登録サービスを識別する（ステップ１４０６）。最後に、図１３のプロセスによる使用のために、サービスビジネス・インタフェース定義ドキュメントの情報が、登録サービスに送られる（ステップ１４０７）。
【０１２２】
図１５は、本発明により、マーケットメーカーノードでの入力データを処理するプロセッサ、コンポーネント及びシーケンスを示した図である。マーケットメーカーノードは、ネットワーク・インタフェースで通信エージェント１５００を有する。通信エージェントはＸＭＬパーサー１５０１と接続し、ＸＭＬパーサー１５０１は、イベントをＸＭＬプロセッサ１５０２に供給する。ＸＭＬプロセッサ１５０２は、イベントをドキュメントルータに供給する。ドキュメントルータは、ドキュメントサービス１５０４にそれを入力する。このドキュメントサービス１５０４は、受け取ったドキュメントをホストシステムのエンタープライズソルーションソフトウェア１５０５に供給するインタフェースを提供するものである。通信エージェント１５００は、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ又は他のプロトコル等のプロトコルをサポートする適切なプロトコルスタックを有するインターネットインタフェースである。したがって、入力するデータは、特定の通信チャンネルに適合するようにＸＭＬ構文、ＡＳＣＩＩデータ構文、又は他の構文で受け入れ可能である。非ＸＭＬ構文で受信されたすべてのドキュメントは、ＸＭＬに変換され、ＸＭＬパーサー（構文解析器）に転送される。非ＸＭＬ形式からＸＭＬ形式への変換をサポートするために、変換テーブル１５０６が使用される。
【０１２３】
変換されたドキュメントは、パーサー１５０１に供給される。ＸＭＬパーサーは、受信されたＸＭＬドキュメントに一致するドキュメントタイプ定義に従って、当該ＸＭＬドキュメントを構文解析する。エラーが見つかった場合には、パーサーはドキュメントを通信エージェント１５００へ送り返す。ビジネス・インタフェース定義コンパイラＢＩＤＣ１５０７は、ビジネス・インタフェース定義データのためのコンパイラとして機能する。ＸＭＬパーサーのためのＤＴＤファイル、ＤＴＤファイルに対応するＪＡＶＡビーンズ、及びＤＴＤファイルをＪＡＶＡビーンズへ変換する変換ルールは、ＢＩＤデータをコンパイルすることにより作られる。これらのツールを参照することにより、ＸＭＬインスタンスがＪＡＶＡインスタンスに変換される。したがって、ＢＩＤコンパイラ１５０７は、ＤＴＤドキュメント１５０８を記憶し、対応のＪＡＶＡドキュメントを生成する１５０９。ＸＭＬドキュメントはプロセッサ１５０２に送られ、プロセッサ１５０２は、そのドキュメントをＪＡＶＡフォーマットに変換する。好ましいシステムでは、ＸＭＬフォーマットで受取ったドキュメントタイプ定義と同じステータスを有するＪＡＶＡドキュメントが生成される。ＪＡＶＡビーンズをドキュメントルータ１５０３に送る。ドキュメントルータ１５０３がＪＡＶＡビーンズを受け取り、その受取ったクラスを、レジストリプログラムを使用して（例えば、上述したイベントリスナーアーキテクチャを使用して）、適切なドキュメントサービスに送る。ルータ１５０３からＪＡＶＡビーンズの形式でドキュメントを受取ったドキュメントサービス１５０４は、エンタプライズソルーションソフトウェアとして機能する。これは、ＸＭＬイベントに対するリスナーを入力データ・ストリームと結合するレジストリサービス１５１０と、適切なサービスに入力ドキュメントの送信がなされるよう管理するサービスマネージャ１５１１とを有する。ドキュメントサービスマネージャ１５１１は、レジストリサービスの管理及びドキュメントの一貫性の維持等を提供する。
【０１２４】
ドキュメントサービスは、任意の専有ＡＰＩを使用して、或いはＣＯＲＢＡ／ＣＯＭインタフェース又はその他のアーキテクチャ等の共通形式を使用して、バックエンドシステムと通信する。
【０１２５】
図１６は、本発明に係るマーケットメーカー及びマーケット参加者構造のヒューリスティック（発見的）ダイアグラムである。従って、本発明に係る電子商取引マーケットは、図１６に示されているように論理的に組織化できる。その組織の最上部において、マーケットメーカーノード１６００が設定される。マーケットメーカーノードは、マーケットプレイス１６０１を設定するリソースを含む。このようなリソースは、マーケット登録サービス等を含む。ビジネス１６０２は、ビジネス・インタフェース定義をパブリッシュ(publish)することによりマーケットプレイスに登録する。ビジネス・インタフェース定義は、ビジネスが参加する商取引についてサービス１６０３を定義する。トランザクション１６０４及びサービス１６０３は、ドキュメント１６０５を使用して入力及び出力を定め、トランザクションにおける参加者の間の商業上の関係をアウトラインする。ドキュメントは各トランザクションの詳細を含むコンテンツ１６０６を有する。コンテンツがマーケットの参加者により及びマーケットメーカーにより処理される方法は、本発明に従って確立される電子商取引ネットワークに基づくドキュメントに完全に依存する。全体として、通信ネットワーク上で電子商取引が可能となるように頑強性、拡張性及び直観力に富む構造が提供される。
【０１２６】
したがって、本発明は、例示のシステムにおいて、ＸＭＬプロセッサに基づくプラットフォームを提供し、疎結合されたビジネスシステムの間のインタフェースとしてＸＭＬドキュメントを使用している。ドキュメントは、ビジネスの間で転送され、企業のビジネスシステムに入る前に特定のノードによって処理される。したがって、プラットフォームは、各ビジネスシステムが異なる内部的なコマースプラットフォーム、処理及びセマンティック（意味論）を使用している場合に、共通の組のビジネスドキュメント及び形式を特定することによりビジネス間の電子商取引アプリケーションを利用可能にする。
【０１２７】
本発明によれば、ビジネスシステムとサービスを相互接続することによりバーチャルエンタプライズが形成され、主に、ビジネスが受入れて生成するドキュメント（ＸＭＬコード化された）に関し、次のとおり定義される。
「貴社が当社にカタログを請求される場合には、貴社にカタログを送ります。」「貴社が購入の注文をされ当社がそれを受け入れことができる場合には、貴社に送り状を送ります。」
上述した本発明の好ましい実施例の説明は、本発明の解説するためになされたものである。これは、包括的であること又は発明を開示した厳密な形式に限定することを意図するものではない。当業者にとって多くの修正及び変更は明らかである。本発明の範囲は、特許請求の範囲及びそれと等価なものによって定められるものである。
【図面の簡単な説明】
【０１２８】
【図１】本発明によるビジネス・インタフェース定義（ＢＩＤ）を含む電子商取引ネットワークの概略図である。
【図２】本発明によるビジネス・インタフェース定義ドキュメントの概略図である。
【図３】本発明によるネットワーク中の参加者ノードのためのサーバの概念的なブロックダイアグラムである。
【図４】本発明に係る参加者ノードで受取られたドキュメントの処理を説明するフローチャートである。
【図５】ＸＭＬベースのシステムについての構文解析プログラム及びトランザクション処理フロントエンドのブロックダイアグラムである。
【図６】構文解析プログラム機能フローの概念的なダイアグラムである。
【図７】本発明に係るビジネス・インタフェース定義に使用される、サーバにおけるリソースの概略図である。
【図８】ビジネス・インタフェース定義の構築のために使用する、本発明に係るリポジトリの概略図である。
【図９】本発明に係るビジネス・インタフェース定義を構築するプロセスを説明するためのフローチャートである。
【図１０】本発明に係るリポジトリのヒューリスティックな概要を提供するものである。
【図１１】ビジネス・インタフェース定義に基づく本発明のネットワークのためのマーケットメーカー機能を提供するサーバのリソースについての概略図である。
【図１２】受取られたドキュメントのマーケットメーカーノードの処理に関するフローチャートである。
【図１３】本発明に係るマーケットメーカーノードの参加者の登録プロセスを説明するためのフローチャートである。
【図１４】図９のプロセスに従った、マーケットメーカーノードにおけるサービスの仕様を提供するプロセスを説明するためのフローチャートである。
【図１５】本発明に係るマーケットメーカーまたは参加者における操作シーケンスを説明するダイアグラムである。
【図１６】本発明に係るＢＩＤに基づく商取引ネットワークの要素の概念的なダイアグラムである。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008084328.tif 000182
【図２】
2008084328.tif 000183
【図３】
2008084328.tif 000184
【図４】
2008084328.tif 000185
【図５】
2008084328.tif 000186
【図６】
2008084328.tif 000187
【図７】
2008084328.tif 000188
【図８】
2008084328.tif 000189
【図９】
2008084328.tif 000190
【図１０】
2008084328.tif 000191
【図１１】
2008084328.tif 000192
【図１２】
2008084328.tif 000193
【図１３】
2008084328.tif 000194
【図１４】
2008084328.tif 000195
【図１５】
2008084328.tif 000196
【図１６】
2008084328.tif 000197