JP2003514277A

JP2003514277A - 大域商取引ウェブ用の商業コミュニティのスキーマ

Info

Publication number: JP2003514277A
Application number: JP2001535796A
Authority: JP
Inventors: バートアランメルツァー; アンドリューイーディヴィッドソン; ラムシャンカーヴェンカト; トマスアールミューラー; カレンローゼンタル; ケリーシュワーズホフ; ザヒドアーメド
Original assignee: カマースワンオペレイションズインコーポレイテッド
Priority date: 1999-11-02
Filing date: 2000-11-01
Publication date: 2003-04-15
Also published as: EP1228435A4; WO2001033369A1; AU1450501A; EP1228435A1; WO2001033369A8; CA2389323A1

Abstract

(57)【要約】機械読み取り可能な文書が、ビジネスを、顧客（１０１）と、サプライヤ（１０３）と、取引相手（１０２）とに接続する。エンティティが加入するマーケット（１０２）に亘ってエンティティを接続するためには、文書を定義するためのインターフェース（１０４）が必要である。本発明は、共通の定義と語彙に関する拡張可能なインターフェース（１０４）を含んでおり、マーケット（１０２）が、一般的に理解されていてマーケットに依存しない定義に従って、その取引文書を別の参加者に示すことができるようにしている。

Description

【発明の詳細な説明】

【０００１】（版権）本特許書類の開示の一部には、版権保護に関わるものが含まれている。版権の
所有者は、特許商標局の特許出願又は記録に含まれる特許書類又は特許開示であ
る限り、何人がファクシミリ複製しようとも異を唱えるものではないが、そうで
ない場合は何であれ、全ての版権を留保するものである。

【０００２】（発明の属する技術分野）本発明は、ネットワークに連結されている多様な顧客の間における取引をサポ
ートするシステム及びプロトコルに関し、厳密には、１つの商業コミュニティ内
の参加者の間の、及び複数の商業コミュニティの間の、電子データ交換のための
拡張可能なスキーマに関する。

【０００３】（従来技術の説明）インターネット及びその他の通信ネットワークは、人々の間の通信と、参加者
が商品及びサービスを売買する商取引を含め多種多様な取引に使用されているコ
ンピュータプラットフォームとに、手段を提供している。インターネット上での
商取引をやり易くするために、多くの努力が払われつつある。しかし、多くの標
準が競合しているため、取引を実行するためには、取引に参加する当事者間で、
使用するプロトコルに関して予め同意しておかねばならず、しばしば、そのよう
な取引をサポートするために、プラットフォームのアーキテクチャを特注仕様で
統合しなければならないこともある。了解に達した標準と互換性のない特定のノ
ード内の商業的処理が、他のノードと統合するために相当な仕事のやり直しを必
要とすることになる場合もある。更に、ある会社が、ある標準或いは他の標準を
コミットすると、その会社は、部外者を排除する、所与の標準化された取引当事
者のグループに拘束されることになる。

【０００４】１９９７年５月のコンピューター誌４８−５５頁記載の、テナンバウム他によ
る「エコシステム：インターネット商取引アーキテクチャ」には、インターネッ
ト商取引開発に関する挑戦が要領よく総括されている。

【０００５】インターネット上での商取引を開始するためには、アーキテクチャ・フレーム
ワークの標準化が望まれている。そのような商業用のフレームワークをサポート
するために開発されたプラットフォームとしては、ＩＢＭのコマース・ポイント
や、マイクロソフトのインターネット・コマース・フレームワークや、ネットス
ケープＯＮＥ（オープン・ネットワーク・エンバイロメント）や、オラクルＮＣ
Ａ（ネットワーク・コンピューティング・アーキテクチャ）や、サン／ＪＡＶＡ
ソフトのＪＥＣＦ（ＪＡＶＡ電子コマース・フレームワーク）等が挙げられる。

【０００６】このような占有権の設定されているフレームワークに加えて、ＣＯＲＢＡＩＩ
ＯＰ（コモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ・イン
ターネットＯＲＢプロトコル）に基づく、一般に流通しているオブジェクトモデ
ルのようなプログラミング技法が押し進められている。企業のシステムを、電子
商取引用のビジネスアプリケーションのレベルで相互作動するシステムに簡単に
移送できるようにするため、一般流通オブジェクトモデルの使用が試みられてい
る。しかし、１つのフレームワークを使用している消費者又はビジネスは、異な
るフレームワーク上で取引を実行することはできない。このことが、電子商取引
システムの成長を制限している。

【０００７】１つのフレームワークを実装している会社は、ＡＰＩがサポートしている他の
フレームワークとは異なる、アプリケーション・プログラミング・インタフェー
スＡＰＩを持っていることが多い。而して、会社が、共通ビジネスシステムイン
タフェースを適用する必要無しに、互いのビジネスサービスにアクセスするのは
非常に難しい。ＡＰＩレベルでそのようなビジネスシステムインタフェースを開
発するには、当事者間で相当な共同作業が必要であり、しばしばそれは現実的で
はない。

【０００８】従って、通信ネットワーク内の多様なプラットフォームの間での対話をやり易
くするようなフレームワークを提供することが望ましい。そのようなシステムが
できれば、取引当事者の間で、特注仕様統合や企業標準についての事前の合意無
しで、自然な商取引がやり易くなる。更に、そのようなシステムができれば、ビ
ジネス自動化への道が着実に開け、時間、コスト、及び取引システム統合に関わ
るリスクが省ける。

【０００９】総体的に、占有権のある標準に基づく閉じられた取引当事者ネットワークを開
かれた市場に置き換える、電子商取引システムを提供することが望ましい。

【００１０】（発明の要約）本発明は、ビジネスを、顧客、サプライヤ、取引当事者に接続するためのイン
フラの一部である。本発明のインフラが整えば、会社は、ＸＭＬ（拡張可能マー
クアップ言語）に基づく文書のような、当事者間で容易に理解できる、自己定義
の機械読み取り可能な文書を使って情報とサービスの交換ができるようになる。
ビジネスインタフェース定義（以下ＢＩＤと称す）と呼ばれる、交換対象の文書
を記述する文書が、インターネット上に掲示され、或いはネットワークの参加者
に伝達される。ビジネスインタフェース定義は、取引の可能性のある相手に、会
社の提供するサービスと、そのようなサービスと通信する際に使用する文書を通
告する。このように、通常のビジネスインタフェース定義を使えば、顧客は、購
入注文を受け取る当事者のＢＩＤに公開されている文書定義に従って、購入注文
を提出することによって注文することができる。サプライヤは、ビジネスシステ
ム管理商品目録データのＢＩＤに公開されている文書定義に従って、商品目録状
態レポートをダウンロードすることによって、入手性をチェックすることができ
る。事前定義された、機械読み取り可能な文書を使用すれば、企業アプリケーシ
ョンにアクセスする、より直感的且つ柔軟性のある方法が提供される。大域商取
引インフラによって維持されている一貫したスキーマは、インフラ参画が現実で
あれ仮想であれ、市場間で文書と文書コンテナが確実に交換できるよう保証する
。

【００１１】（好適な実施例の詳細な説明）本発明を具現化する実施の形態について、図面に基づき詳しく説明する。当業
者にとっては、本発明を具現化する他の実施の形態についても自明であろう。図
１は、大域商取引ウェブアーキテクチャ全体をサポートしている大域商取引ウェ
ブのインフラを示している。買い手１０１は、サプライヤ１０３と交信するため
に市場ポータル１０２と対話する。市場ポータル又はノードを介して対話をする
買い手やサプライヤ等をひとまとめにしてトレイダーと呼ぶ。各市場ポータルは
ＵＲＬから操作され、プラットフォームがホストとなっているが、それは、Wind
ows NT（登録商標）、Linux（登録商標）、UNIX（登録商標）、又はVMなどのオ
ペレーティングシステムを実行するワークステーション、ミニコンピュータ、又
はメインフレーム等である。各プラットフォームは局所レジストリへのアクセス
を有しており、このレジストリは、市場ポータルに参加しているビジネス、それ
らビジネスが提供するサービス、ビジネス間の対話や取引、対話を指揮する文書
、及びそれら文書内の情報項目、を表すスキーマを保有している。買い手又はサ
プライヤの観点から見ると、市場ポータルは、カタログ、文書の移送、買い手と
サプライヤとの取引及びマーケット同士の取引、及び取引を支援するサービス、
をサポートしている。大域商取引ウェブ・インフラ１０４は、これと通信する市
場ポータルをサポートする。インフラは、フォーマットとプトロコルを受信し、
記憶し、そして示す。インフラは、それがなければ互換性の成立しない市場ポー
タル同士のインタフェースをサポートする。インフラは、買い手と売り手双方の
市場ポータル間の収入分配契約を記憶して実行を支援し、またプライバシーポリ
シーを記憶してその実行を支援する。インフラをサポートするサーバーをプラッ
トフォームが１つ又はそれ以上備えていることから、市場ポータルとインフラと
の通信は確保されている。

【００１２】大域商取引ウェブ・インフラを介して接続されている市場ポータルは、Commer
ceOne TM MarketSite製品ライン、及びeCo相互運用仕様準拠型マーケット、又は
Chemdex TMや他の非MarketSite使用可能型マーケットのような相互運用性に適合
させた顧客マーケットソリューション上に構築されたサーバーを基礎とすること
ができる。インフラは一般的には、プログラムビジネスコミュニティサービス、
ビジネス文書用の経路指定インフラ、及び経路指定インフラとサービスにアクセ
スするためのウェブポータル、を提供する。このインフラは、単体のMarketoSit
e TM用に実施される構造とよく似ている。しかし、提供されるビジネスコミュ
ニティサービスが、１つのコミュニティ内での取引ではなくて大域的な取引をや
り易くしている点で異なっている。文書の経路指定と追跡では、１つのポータル
内よりむしろマーケッ間の取引を考慮している。ウェブポータルは世界中の他の
市場ウェブポータルとつながるように仕立てられている。文書の経路指定を行う
場合、インフラは、現実のものでも仮想のものでもよい。現実のものである場合
には、文書は実際にそのインフラを経由することになる。つまり、インフラはメ
ッセージ伝達スイッチとして働き、文書コンテナや文書を１つの市場ポータルか
ら受信し、別の市場ポータルへ転送する。仮想のものである場合、文書はピア対
ピア形式で転送されるので、局所レジストリは大域レジストリから更新され、サ
ポートされている市場ポータルが現在のスキーマとプロトコル上で作動している
ことを保証されるという利点がある。インフラには、文書がピア対ピアで転送さ
れる場合は追跡のために、相互接続と転送について通知されることが望ましい。

【００１３】インフラは、マーケット同士の相互接続を設定する場合に有用である。収入分
配契約は、インフラが供給する形式に基づいて行うことができる。収入分配契約
をサポートするために請求書発送能力が存在する。請求書が発送されるべきイベ
ントは、インフラの当事者の一人に対して請求されるべきイベントが発生する都
度ログすることができる。インフラは、取引相手（トレーダーとも称する）と相
互接続を登録する。大域ネームスペースは、取引相手プロフィールを介して取引
相手を独自に識別する。プライバシーポリシーは、取引コミュニティ参加者のプ
ロフィールを、参加者がプライバシーの利益であると言明する範囲で保護する。
インフラは、支払いと商品の発送を保証する条項及び条件に準拠して匿名の取引
をサポートすることができる。身分を明かされることに関心のある取引相手は、
取引相手のスーパーディレクトリに現れる。各取引相手に関する情報は、ブラウ
ジングインタフェース及び照会機構を介して入手可能である。スーパーディレク
トリ或いは他の手段の何れかを介して、取引相手になる可能性のある者が互いを
見つけ合う場合には、取引関係を確立したいと望むものである。インフラはエン
ティティ同士の会話を容易にするものであり、両者間の商売をサポートするため
にどのような契約に到ろうともその契約を登録するのに利用することができる。
インフラは、大域商取引で対象となるビジネス、市場コミュニティ、及びコンテ
キストサービスを提供することにより、マッピングや相互接続に関連する問題を
調停する際に援助する。

【００１４】作動上、インフラは相互接続の起動と構成を提供し、時間経過に伴う相互接続
を維持し、相互接続に亘る関係を管理し、請求書発送及び確認目的の活動を追跡
する。これら作動上の能力は、フォーマット、プロトコル、ポリシー（例：プラ
イバシー）、プロセス、及びインタフェース、のインフラにより提供される一貫
性により異なる。インフラは、信頼でき、利用可能で、スケーラブル且つ管理可
能であることが望ましい。別々のマーケットからの取引相手即ちトレーダーの情
報を、単一の、取引相手のスーパーディレクトリ・ビューに集めるには、少なく
とも３つの方法がある。キャッシュは、インフラ内のマーケット同士間で取引相
手情報を交換することにより更新することができる。取引相手情報を、１つのマ
ーケットから別のマーケットに複製することもできる。或いは、１つの場所又は
各マーケットインスタンス内で入手可能な取引相手に関するメタデータをもとに
して、関心のある当事者が、より完全なデータが利用できるようになる場所に辿
り着けるようにすることもできる。

【００１５】図１は、インフラが、フォーマットとプロトコル、インタフェース、収入分配
契約、プライバシーポリシー等のライブラリとしての役目以上のサービス１０５
を提供することにより、どのように市場ポータルに付加価値を与えるのかを示し
ている。提供されるサービス１０５としては、請求書発送、トラフィック管理、
取引の支払い、否認防止、認証局、商品スポット市場、総合証券サービス、サプ
ライヤ及び物品についての大域ディレクトリ、等が挙げられる。当該サービスは
インタフェーススキーマにより実行される。レジストリ及びリポジトリ１０６は
インフラとサービスをサポートする。

【００１６】図２は、大域商取引インフラ・トポロジー全体を示しており、例として５つの
マーケットを挙げている。大域商取引・ウェブのインフラ２０１は、大域レジス
トリ及びリポジトリ２０２、大域コミュニティサービス２０３、大域商取引サー
ビス２０４、及びバックオフィスサービス２０５を備えている。これらサービス
のグループに割り当てられた名前には任意的な側面がある。本図ではマーケット
の例として、地域的なMarketSite相手（ＢＴ）２１１、Promous TM２１２のよう
な商標付き又は仮想のMarketSite、CommerceOne's自身のMarketSite.net２１３
、BellSouth TM２１４により操業されているマーケット、及び第２の地域的Mark
etSite相手（ＮＴＴ）を挙げている。買い手とサプライヤが各マーケットと通信
している状態を示している。様々なマーケットの間の収入分配契約の存在を、BT
２１１とNTT２１５の間の収入分配契約矢印２２０で示している。

【００１７】図３は、ビジネスインタフェース定義の使用に基づく市場参加者及び市場メー
カーのネットワークと、そのようなインタフェース記述により指定された入出力
文書の取引のサポートについて示している。ネットワークは、Internet３９のよ
うな通信ネットワーク又は他の遠隔通信又はデータ通信ネットワークを通して相
互接続されている複数のノード３１−３８を含んでいる。各ノード３１−３８は
、ポータブルコンピュータ、デスクトップパーソナルコンピュータ、ワークステ
ーション、システムのネットワーク、又は他のデータ処理リソースのようなコン
ピュータから構成されている。ノードは、ビジネスインタフェース定義を記憶す
るためのメモリ、ネットワーク内の他のノードとの商業取引をサポートする取引
処理を実行するプロセッサ、及びそのようなサービスのサポートに当たりプロセ
ッサが実行するコンピュータプログラムを含んでいる。さらに、各ノードは、In
ternet３９又は他の通信ネットワークにまたがる通信に備えたネットワークイン
タフェースを含んでいる。

【００１８】図３の環境では、ノード３１、３２、３３、３４、３６、３８は市場参加者を
指している。市場参加者には、本発明により確立された商業取引に則り取引され
るべき商品又はサービスの消費者用又はサプライヤ用のリソースが含まれる。

【００１９】本例では、ノード３５と３７は市場メーカーノードである。市場メーカーノー
ドとしては、ＢＩＤレジストリと呼ばれる、ビジネスインタフェース定義を登録
するためのリソースが挙げられる。参加者は、文書を市場メーカーに送ることが
でき、そのノードにおいて文書は識別されて、そのような文書を入力として受信
するように登録されている該当参加者に経路指定される。市場メーカーは、更に
、ビジネスインタフェース定義を構築する際に使用される共通ビジネスライブラ
リを作り上げる標準形式のリポジトリを維持することによって、商業ネットワー
クを使い易くしている。

【００２０】本例では、市場参加者３８は市場メーカー３７に、Internet３９を介せずに直
接接続されている。このように市場メーカーへ直接接続されていることは、商業
取引をサポートするネットワークの構成が、非常に多岐に亘っていること、つま
りInternet３９のような公共のネットワーク、及びローカルエリアネットワーク
又はノード３７と３８の間に示すようなポイント対ポイント接続のような私的接
続を受け入れるようになっていることを例証している。実際の通信ネットワーク
は、極めて多種多様で、本発明による商業取引ネットワークを設定する場合の使
用に向いている。

【００２１】図４は、大域商取引インフラを実施する場合のオプションを示している。参照
番号は図２に準拠している。現実及び仮想双方の場合の文書経路指定について示
している。文書４２０は、大域商取引ウェブ・インフラ４０１を介してマーケッ
トにより経路決めされる。文書４２１は、マーケット間で、ピア対ピアで交換さ
れ、大域商取引ウェブ・インフラ４０１とマーケット４１１及び４１５の間のレ
ジストリ及びリポジトリ情報交換によりサポートされている。

【００２２】図５に、レジストリ及びリポジトリのハイレベルアーキテクチャを示す。イン
タフェースは、ウェブ５０１を介しての通信及び文書５０２の交換に備えて提供
されている。各種リポジトリサービスが示されている。情報編成サービス５１０
には、デフォルト分類学、分類学マップ、及び商業コミュニティスキーマが含ま
れている。一般的には、ブラウジング及び探索５１１用のサービスが提供される
。情報交換サービス５１２は、大域取引ウェブに対する取引相手の公表又は申込
み、及び他のマーケットに対する取引相手の公表又は申込みを含んでいる。付加
サービス５１３は、文書インタフェースを通過する文書の有効期限、転換、及び
管理を含んでいる。リポジトリサービス５１１の拡張性は設計によって決まる。
アーキテクチャ的観点からすると、本発明の一層は文書マッピング５２０に対す
る文書記憶用に設けられている。データの型が異なれば異なる文書記憶スキーム
が適用される。例えば、市場取引相手情報の記憶にはＸ．５００が使用される。
ＸＭＬは、Javaオブジェクトに記憶されるデータをマップすることができる。レ
ジストリはメタデータ５３０を記憶する。Oasis及びDublin Coreを翻訳した標準
はレジストリ用として使用できる。レジストリの存在によって、市場に対して、
市場参加者にとって、更にサービス、文書、情報項目、取引相手関係、経路指定
、申込みと公表に対して、付加価値が生まれる。データの実際の記憶装置は、情
報型式５４０に基づくデータ記憶装置により実行される。このアーキテクチャに
より全層５５０に亘って提供される機能には、保全性、信頼性、利用可能性、ス
ケーラビリティ、及び管理機能が含まれる。

【００２３】図６は、エンティティ及び商業コミュニティスキーマの関係を示す概念的ブロ
ック図である。ネットワーク層６０１は、ルート、即ちCommerceOneにより提供
されるインフラのような大域商取引インフラである。コミュニティ層６０２は、
ネットワーク層のルートと連通する地域的又は垂直的相手に相当する。相手は、
それぞれ、マーケット定義層６０３に依存して地域的又は垂直的マーケットのイ
ンスタンスをサポートしている。マーケットの詳細については、マーケット特定
の層６０４で提供される。

【００２４】図７は、本発明の実施の形態を具現化しているデータスキーマの階層図である
。最上層即ちルート７０１は、各種マーケット７１１−１３と接している。ルー
トには、所有者、オペレータ、技術上の接点、及び管理上の接点が含まれている
。各マーケットには、非所有者、オペレータ、及び技術上及び管理上の接点が含
まれている。マーケットは何れも市場情報レジストリ７２１を有している。例え
ば、CommerceOne用の市場情報レジストリは、MarketSite.net.用のサーバ上で保
守されている。単一マーケット用のサーバは、認証局認定書７３１、マーケット
を通して適用可能な取引について「履行」「不履行」「期限切れ」を表現する取
引用の条項及び条件７３２、市場参加者レジストリ７３３、ＣＢＬ、ＸＭＬスキ
ーマ言語又は文書ガイドの形式で書かれた基幹ビジネス文書７３４、及び基幹サ
ービスの登録用の論理７３５、を含んでいるレジストリ保護モデルを保守する。

【００２５】市場参加者のレジストリは、レジストリ７４１−４２の、取引相手とサービス
の両方を反映している。取引相手には、買い手、サプライヤ、サービスプロバイ
ダ等が含まれる。買い手レジストリ・ポインタ７５１は、独自の汎用リソース名
として保守される。同様に、サプライヤレジストリはサプライレジストリ・ポイ
ンタ７５２を含み、サービスプロバイダレジストリはポインタ７５３を含み、編
成レジストリはポインタ７５２を含んでおり、これらは全て汎用リソース名であ
る。例えば、買い手レジストリ・ポインタは、仕入れマネジャ、仕入れ管理者、
システム管理者及びデスクトップ徴用者７７１、及び名前とバージョン番号によ
り識別することのできる買いアプリケーション７７２を含む、買い手側の構成を
参照するようになっている。同様に、サプライレジストリ・ポインタ７５２は、
販売マネジャ、販売管理者、カタログマネジャ、システム管理者、及びITマネジ
ャを含む、売り手側の構成を参照する。サプライレジストリ・ポインタ７５２は
、名前とバージョン番号とによって識別できる売りアプリケーションも参照でき
る。

【００２６】サービスのレジストリには、システムサービス７６１、ビジネスサービス７６
２、ポータルサービス７６３、コミュニティサービス７６４が含まれている。各
サービスは、汎用リソース名としての、レジストリからレジストリへのポインタ
である。これらサービスグループの命名法として代替的なものを、大域コミュニ
ティサービス、大域商取引サービス、及びバックオフィスサービスとして図２に
示している。

【００２７】本発明の更に別の態様は、CommerceOne Soxコンパイラにより一連のJavaオブ
ジェクトにコンパイルできるＸＭＬ言語スキーマである。オブジェクトのスーパ
ークラスとクラスが定義されている。以下の定義は、アルファベット順に並んで
おり、ある特定の論理的順序に沿っているのではない。これらの定義は、ＸＭＬ
プログラミングに精通している方には容易にご理解いただけよう。スキーマの構
文解析は例で示すことができる。GtwCoreBusinessDocs.soxのSox定義は、図７の
基幹ビジネス文書７３４に対応している。それは、ＸＭＬバージョン１．０で書
かれている。それは、汎用リソース名に関連付けられているスキーマの"system"
文書型式であり、x-commerceone : document : com : commerceone : xdk : xml
: schema. dtd$1.0となる。スキーマは実際にはタグ"scheme"で始まる。スキー
マ用の均一なリソース識別子は、ボールド体のルーチン名に対応しており、本例
では、x-commerceone : document : gtw : GtwCoreBusinessDocs.sox$1.0である
。このスキーマのコメントはタグにより表示される。コメントはタグ"comment"
で始まり、タグ"/comment"で終了する。この定義を拡張するために、エレメント
型式が使われる。エレメント型式には、ルーチン名に対応している名前があり、
モデルを有している。モデルでは、各データエレメントは、"+"として1回だけ現
れるか、オプション"?"となるか、或いは"*"として何度も現れる場合がある。本
例では、汎用リソースインジケータは、1回しか現れないポインタである。

【００２８】以下に示す本例の各部分では、型式の名前はボールド体であり、その内容は次
の通りである。

【００２９】

【数１】

【００３０】

【数２】

【００３１】

【数３】

【００３２】

【数４】

【００３３】

【数５】

【００３４】

【数６】

【００３５】

【数７】

【００３６】

【数８】

【００３７】

【数９】

【００３８】

【数１０】

【００３９】

【数１１】

【００４０】

【数１２】

【００４１】

【数１３】

【００４２】

【数１４】

【００４３】

【数１５】

【００４４】

【数１６】

【００４５】

【数１７】

【００４６】

【数１８】

【００４７】

【数１９】

【００４８】

【数２０】

【００４９】

【数２１】

【００５０】

【数２２】

【００５１】

【数２３】

【００５２】

【数２４】

【００５３】

【数２５】

【００５４】

【数２６】

【００５５】

【数２７】

【００５６】

【数２８】

【００５７】

【数２９】

【００５８】

【数３０】

【００５９】

【数３１】

【００６０】

【数３２】

【００６１】

【数３３】

【００６２】本スキーマでは、GtwPortalService.soxは、GtwService.soxを特殊化したもの
である。Java（登録商標）プログラミング言語では、GtwPortalService.Soxは、
クラスGtwPortalService.soxを含むスーパークラスを表している。このスキーマ
では、ネームスペース接頭語を使って参照を短縮させている。汎用リソース名は
、ネームスペース接頭語に関連付けられている。エレメント型"GtwService"のモ
デルは、図７に示すような所有者、オペレータ、技術上の接点及び管理上の接点
を含んでいる。さらに、文書交換用のエレメント型式が定義されている。文書交
換エレメント型式に使用されるデータ型式も、スキーマの一部として定義される
。このスキーマが定義されると、"GtwPortalService.sox"のスキーマとして特定
化することができる。これら例を示すことにより、ＸＭＬプログラミングに精通
している方には、合わせて図７を参照することにより、本発明の１つの実施例で
ある図８のスキーマを追って説明を進めることができよう。

【００６３】図８は、本発明によるネットワーク内の市場参加者のために設定されたビジネ
スインタフェース定義ＢＩＤに組み込まれている構造の、発見に役立つ図解であ
る。図８に示すビジネスインタフェース定義は、ＸＭＬ文書型定義ＤＴＤのよう
な、文書構造の形式的定義に従って配列された論理構造及び記憶単位から構成さ
れているデータ構造である。図８の構造には、当事者を識別するための第１論理
構造８００が含まれている。論理構造８００には、名前８０１、物理アドレス８
０２、ネットワークアドレス又は場所８０３、及びサービスに関する取引のセッ
ト８０４を保有するための組み込み型論理構造が付帯している。サービスセット
内の各取引には、取引ＢＩＤ８０５、取引ＢＩＤ８０６、取引ＢＩＤ８０７を含
むインタフェース定義が与えられている。取引ＢＩＤ８０５のような各取引ＢＩ
Ｄ内には、名前８０８、サービスが実行されるネットワーク上の場所８０９、サ
ービスにより実行されるオペレーション８１０、及びタグにより示される入力文
書のセット８１１を含む、論理構造が設けられている。また、取引ＢＩＤ８０５
は、タグ８１２により示される出力文書のセットも含んでいる。入力文書のセッ
ト８１１には、入力文書ビジネスインタフェース定義８１３、８１４、及び８１
５を含め、サービスが応答するようになっている各入力文書についてのビジネス
インタフェース定義が含まれている。入力文書の各ビジネスインタフェース定義
には、名前８１６、文書の内容を見つけることのできるネットワーク上の場所８
１７、フィールドにより表示され文書内に保有されているモジュール８１８が含
まれている。同様に、出力文書のセット８１２は、出力文書ＢＩＤ８１９、出力
文書ＢＩＤ８２０、及び出力文書ＢＩＤ８２１を含む出力文書のインタフェース
定義を含んでいる。各出力文書ＢＩＤに対し、名前８２２、ネットワーク上又は
他の場所８２３、及び文書のモジュール８２４が指定されている。図８に示すよ
うに、参加者のためのビジネスインタフェース定義には、各サービスの文書の入
出力に使用される論理構造の実際の定義、或いは、これらの定義を見つけること
のできる場所に対するポインタ又はその他の参照符号が含まれている。

【００６４】他の文書定義アーキテクチャを使用してもよいが、本例のシステムでは、図８
の文書はＸＭＬ文書型定義ＤＴＤで指定されており、当該文書のインスタンスの
解釈に使用される論理構造の解釈情報を含んでいる。更に、各取引ＢＩＤ、入力
文書ＢＩＤ、及び出力文書ＢＩＤは、ＸＭＬ文書型定義に従って指定される。Ｘ
ＭＬ型文書は、マークアップデータ又はキャラクタデータを含む解析済みデータ
に基づくシステムの一例である。マークアップデータは、文書内の論理構造を識
別し、キャラクタデータのセットは論理構造の内容を識別する。更に、未解析の
データが様々な用途の文書内に含まれている。例えば、ＷＣ３ＸＭＬワーキング
グループにより出版された「拡張可能マークアップ言語ＸＭＬ１．０」REC-ＸＭ
Ｌ-19980210を、WWW.W3.ORG/TR/1998/REC-XML-19980210で参照されたい。

【００６５】こうして、代表的なシステムでは、ネットワーク内の参加者ノードは、ビジネ
スシステムとサービスを、ビジネスが受け入れて生成するＸＭＬでエンコードさ
れた文書と相互接続することにより仮想企業を設立する。例えば、特定サービス
のビジネスインタフェース定義は、カタログエントリに対するリクエストのＢＩ
Ｄに一致する文書が受信されるとカタログエントリのＢＩＤに一致する文書が戻
される、という設定を行う。また、仮に購入注文のＢＩＤに一致する文書が受信
され、それが受信ターミナルにとって受諾できるものであれば、インボイスのＢ
ＩＤに一致する文書が戻されることになる。ネットワーク内のノードは、局所ビ
ジネスシステムを入力する前にＸＭＬ文書を処理するが、これはネットワーク内
のあらゆる所与のシステムの可変取引処理アーキテクチャに従って設定される。
こうして、システムは、ＭＩＭＥでエンコードされたＸＭＬ文書のセットのよう
な関連文書をアンパックし、それらを解析して「マークアップメッセージ」のス
トリームを創造する。メッセージは、適切なアプリケーションに経路指定され、
例えば、以下に説明するようなイベントリスナモデルを使ってサービスする。

【００６６】ビジネスサービスの間で交換される文書は、より複雑な文書定義が創造される
構築ブロックのリポジトリから構築されたＸＭＬ言語（共通ビジネス言語）を使
ってエンコードされる。リポジトリは、ビジネスドメインに共通する関数と情報
に焦点をあわせた解釈情報のモジュールを記憶するが、これには、会社やサービ
ス及び製品などのビジネス記述基本要素、カタログや購入注文書及びインボイス
のようなビジネス形態、時間や期日や場所といった標準測定事項、ＸＭＬ文書の
論理構造についての解釈情報を提供する分類コード等、が含まれる。

【００６７】ビジネスインタフェース定義は、本発明により文書をやりとりするインタフェ
ースを設計するのに使用されるスキーマとして働く、より上位の文書である。こ
うして、ビジネスインタフェース定義は、ＸＭＬにより規定された文書と、特定
のノードにおいて取引処理サービスのフロントエンド上で実行されるプログラム
の間のギャップに橋を架ける。このようなフロントエンドは、ＪＡＶＡ仮想マシ
ン、又はネットワークをまたぐシステムの相互接続に備えた他の共通アーキテク
チャにより実行される。こうして、ビジネスインタフェース定義は、ビジネスイ
ンタフェース定義文書を使って取引プロトコルをプログラムできる技術を提供す
る。取引のプロトコル用のプログラムは文書型の詳細な形式仕様により設定され
る。

【００６８】ＸＭＬフォーマットに従う市場参加者文書に基づく一例的なビジネスインタフ
ェース定義ＢＩＤを以下に示す。市場参加者ＤＴＤは、市場参加者についてのビ
ジネス情報をグループ化し、接点とアドレス情報を、サービス及び財務情報の記
述と結びつける。このビジネス情報は、名前、コード、アドレス、ビジネス編成
を記述するための専用分類機構、及びビジネス項目に対するポインタから構成さ
れている。更に、市場参加者ＤＴＤにより識別されるサービスは、参加者が応答
したり作り出すと予想される入出力文書を指定することになる。このように、市
場参加者ＤＴＤ、サービスＤＴＤ、及び取引文書ＤＴＤのための代表的な共通ビ
ジネス言語を使ってスキーマを定義する文書は、ＸＭＬ内で以下の説明的コメン
トによって指定される。

【００６９】 CMRC1000-2

【数３４】

【００７０】

【数３５】

【００７１】

【数３６】

【００７２】

【数３７】

【００７３】

【数３８】

【００７４】

【数３９】

【００７５】

【数４０】

【００７６】

【数４１】

【００７７】

【数４２】

【００７８】サービスＤＴＤスキーマは、以下のように共通のビジネス言語リポジトリ内の
サービス型エレメントで拡張される。

【００７９】

【数４３】

【００８０】上記サービス型エレメントは、ビジネスインタフェース定義により伝えられる
解釈情報、即ち本例では、有効なサービス型式のリストにあるあらゆるものを識
別できるようにしている内容形式を示している。他の解釈情報は、例えば、内容
形式"url"を含んでおり、データ型式"string"によって表されるエレメント<H3>I
nternet Address</H3>のような、データタイピングを含んでいる。更に他の解釈
情報は、例えば、ファイル"COUNTRY.US.SUBENTITY"の状態についてマッピングを
行うコードを含んでいるエレメント<H3>State</H3>のような、リストのエレメン
トに対するコードのマッピングを含んでいる。

【００８１】市場参加者ＤＴＤにより参照されるサービス記述は、サービスの競合時に当該
サービスが受諾し生成する文書を定義する。基本的なサービス記述は、以下に、
ＸＭＬ文書 transact.dtdとして以下に指定される。

【００８２】 Transact.dtdは、インボイスなどの取引記述、又は値のやりとりの記述をモデ
ル化する。この文書型式は多数の用途をサポートし、よって、取引記述エレメン
トは、ユーザーが、インボイス、パフォーマンス、販売へのオッファー、見積要
求などを区別できるようにする属性を備えている。３人以上の当事者間でやり取
りが発生することも考えられるが、呼び出されるのは２当事者だけ、即ち申込者
とそれに対する相手側当事者だけであり、それぞれ、上で概要を説明した市場参
加者ＤＴＤに合致する文書に向けられたポインタによって表現される。販売への
オッファーに対応するための、相手側当事者ポインタは随意的である。やりとり
の記述は、以下に掲載したモジュールtranprim.modに記述され、価格付けと小計
を含んでいる。やりとり記述に続き、取引全体に適用される手数料が設けられる
と、合計手数料が供給されねばならない。よって、本例についての取引記述スキ
ーマ文書transact.dtdは以下のように示される。

【００８３】

【数４４】

【００８４】上記定義により作成される代表的な市場参加者ＤＴＤ及びサービスＤＴＤは以
下の通りである。

【００８５】

【数４５】

【００８６】 transact.dtdによって作られた文書の一例を以下に示す。

【００８７】

【数４６】

【００８８】

【数４７】

【００８９】従って、本発明は、市場参加者が自身の身分を明らかにでき、市場参加者がビ
ジネスを処理しようとする手段となる入力文書の型式及び出力文書の型式を識別
できる技術を提供する。取引に対する他方側の当事者が、又はローカルな当事者
が、そのような文書で伝えられる内容を処理する特定の方法は、ビジネス関系を
設定する際にも取引を実行する際にも関与しない。

【００９０】図９は、本発明の態様を実施しているネットワーク内の参加者ノードを単純化
した図である。図９に示すノードは、ポート９０１上の通信ネットワークに連結
されているネットワークインタフェース９００を含んでいる。ネットワークイン
タフェース９００は、文書構文解析系９０１に連結されている。構文解析系９０
１は、入ってくる文書からの論理構造を翻訳系モジュール９０２に提供し、翻訳
系モジュール９０２は、入ってくる文書をホストの取引システムにより使用可能
な形式へ翻訳することと、その逆で、ホストが処理する出力を、宛先へ送信する
ためのビジネスインタフェース定義の出力文書形式に一致する文書のフォーマッ
トへ翻訳することを行う。構文解析系９０１及び翻訳系９０２は、参加者モジュ
ール９０３に記憶されているビジネスインタフェース定義に応答するようになっ
ている。

【００９１】翻訳系９０２からの出力データ構造は、構文解析系９０１が信号送信したイベ
ントと共に取引処理フロントエンド９０４に供給される。ある実施形態における
フロントエンド９０４は、ＪＡＶＡ仮想マシン、又はネットワーク内の多岐にわ
たるノード間の通信に合わせて適合化された他の同種のインタフェースから構成
されている。取引処理用フロントエンド９０４は、構文解析系９０１と翻訳系９
０２により表されるイベントに応答し、入ってくるデータを、参加者が連結され
ている企業システム及びネットワーク内の該当する機能に経路指定する。こうし
て、図９の例における取引処理フロントエンド９０４は、商業機能９０５、デー
タベース機能９０６、会計及び請求書発送のような他の企業機能９０７、及び構
文解析系により示されるイベントに応答するようになっている特定のイベントリ
スナ及びプロセッサ９０８に連結されている。

【００９２】構文解析系９０１は、ビジネスインタフェース定義により特定された、上記例
中のもののような購入注文又は他の文書を取り込んで、ＪＡＶＡ仮想マシン用の
ＪＡＶＡイベントのセットのような、局所取引処理アーキテクチャにより認識さ
れるイベントのセットを創造する。

【００９３】本発明の構文解析系は、受信文書に基づきイベントに耳を傾けるプログラムか
ら切り離されている。受信文書又はある規定に当てはまる完全な文書中の様々な
マークアップは、リスニング機能が処理を開始するための命令として働く。この
ように、リスニングプログラムは、文書情報に関連付けられたビジネス論理を実
行する。例えば、アドレスエレメントに関連付けられたプログラムは、データベ
ースを調べることにより郵便番号を確認するコードであってもよい。これらリス
ナは、文書ルータを使って登録することによりイベントに申し込み、文書ルータ
は関連イベントをそれに関心のある全契約者に送る。

【００９４】例えば、先に指定された購入注文は、構文解釈系により生成されたイベントを
聞くプログラムによりモニターされ、構文解釈系は文書又はその内容を注文入力
プログラムに接続する。購入注文内の製品記述の受信によって、プログラムが呼
び出され在庫目録を調べる。購入注文内のアドレス情報の受信により、プログラ
ムが呼び出され出荷用のサービスの利用可能性を調べる。文書内の買い手情報フ
ィールドは、処理を実行して、信用度に関して注文履歴を調べ、或いは販売促進
又は消費者の身元を知ることに基づく同様の処理を提供する。

【００９５】複雑なリスナを、初期リスナの構成として作成することができる。例えば、購
入注文リスナは、前のパラグラフで準備されたリストリスナに含まれているかも
しれず、これを呼び出してもよいし、又はリストメンバーが自身で呼び出される
ようにしてもよい。なお、リスナが実行するアプリケーションは、固有ＸＭＬ処
理又は固有ＪＡＶＡ処理である見込みは少ない。これらの場合、オブジェクトは
受信側の取引アプリケーションにより要求されるフォーマットに変換される。ア
プリケーションが処理を終えると、その出力は、ネットワーク内の他のノードに
対する通信用のＸＭＬフォーマットに変換し直される。

【００９６】市場参加者文書型記述、及び上に概略を説明した取引文書型式記述は、文書内
の論理エレメント用の概略マッピングを含み、また自然言語を基礎とするマーク
アップ言語を含んでいることが分かる。自然言語マークアップ、及びＸＭＬの他
の自然言語属性は、ビジネスインタフェース定義、サービスの記述、及び入出力
文書の記述の仕様に関するＸＭＬ型マークアップ言語の使用をやり易くする。

【００９７】ビジネスインタフェース定義を記憶することに加えて、参加者モジュール９０
３は更に、入ってくる文書の論理構造に対応する取引処理フロントエンド９０４
により使用されるオブジェクト又は他のデータ構造をコンパイルするために、及
び翻訳系９０２をコンパイルするために使用されるコンパイラを含んでいる。こ
のように、ビジネスインタフェース定義は、参加者が関系する取引が変化する度
に、参加者により変更又は更新されるので、翻訳系９０２と構文解釈系９０１は
自動的に最新に維持される。

【００９８】本発明の態様を実施している１つのシステムでは、ＪＡＶＡイベントのセット
は、ＳＧＭＬのグローブモデル、主として各エレメントの"property set"により
増強される標準的な「エレメント構造情報セット」に対応するコンパイラにより
作成される。国際標準ISO/IEC１０１７９：１９９６(E)、情報技術処理言語−文
書様式意味論及び指定言語（ＤＳＳＳＬ）を参照されたい。ＸＭＬ文書をイベン
トのセットに変換することにより、世界は、構文解析系の出力が内部データ構造
として保守される構文解析の普通モデルとの対照を処理できるようになる。ＸＭ
Ｌ文書のエレメントを、ＪＡＶＡイベント、又は各ノードの取引処理用フロント
エンドによる使用に適する他のプログラミング構造に変換することにより、やり
とりされている文書を利用してノードの豊富な機能性を可能にする。

【００９９】こうして、取引処理フロントエンド９０４は、システム内の他のリスニングプ
ログラムの知識無しに又はこれに影響を与えること無く、新しいリスナプログラ
ムの追加を可能にする公表及び申込み構造で作動することができる。図９の各リ
スナ９０５、９０６、９０７、９０８は、フロントエンド９０４がイベントを導
くキューを保守する。これにより、多数のリスナがそれら自身のペースで並行し
てイベントを取り扱うことができるようになる。

【０１００】更には、本発明によれば、リスナが実行するアプリケーションは固有のＸＭＬ
機能も、入ってくる文書のフォーマットと合う固有機能も必要としない。むしろ
これらリスナは、取引処理フロントエンド９０４がＪＡＶＡインタフェースであ
れば、ＪＡＶＡ機能であってもよいし、或いは独自の取引処理アーキテクチャに
従って実行する機能であってよい。その場合には、オブジェクトは受信側アプリ
ケーションが要求するフォーマットへと変換される。リスナのアプリケーション
が終了すると、その出力は、モジュール９０３のビジネスインタフェース定義に
より指定された文書のフォーマットに変換し直される。このように、翻訳系９０
２は、組み立てられた文書を出力として提供するために、ネットワークインタフ
ェース９００に直接連結される。

【０１０１】取引処理フロントエンドに連結されたリスナは、入力文書用のリスナ、入力文
書の特定のエレメント用のリスナ、及び入力文書の特定リスナに記憶された属性
用のリスナを含んでいてもよい。これにより、入ってくる文書をフィルタに掛け
これに応答するため、参加者ノードで、取引処理を多種多様且つ柔軟に実行でき
るようになる。

【０１０２】図１０は図９のシステムについて、入ってくる文書を受信し処理する過程を示
している。このように、処理は、ネットワークインタフェースで文書を受信する
（ステップ１０００）ことにより開始される。構文解釈系は、ビジネスインタフ
ェース定義に応答して文書型を識別（ステップ１００１）する。ＸＭＬフォーマ
ットの文書用のＤＴＤを記憶しているビジネスインタフェース定義を使って、文
書は構文解析（ステップ１００２）される。次に、文書のエレメント及び属性が
ホストのフォーマットに翻訳（ステップ１００３）される。本例では、ＸＭＬ論
理構造は、機能を取得し設定するというようなデータに結び付けられた方法と共
に、ＸＭＬエレメントのデータを伝えるＪＡＶＡオブジェクトへと翻訳される。
次に、ホストオブジェクトは、ホスト処理フロントエンドに転送（ステップ１０
０４）される。これらのオブジェクトは、構文解釈系及び翻訳系により表示され
たイベントに応答して処理の経路指定を行う。文書のエレメントを受信する処理
が実行され出力が生成（ステップ１００５）される。出力は、ビジネスインタフ
ェース定義により定義される出力文書のフォーマットに翻訳（ステップ１００６
）される。本例では、取引は、ＪＡＶＡオブジェクトの形式からＸＭＬ文書の形
式に進む。最終的には、出力文書は、ネットワークインタフェースを介して宛先
に送信（ステップ１００７）される。

【０１０３】図１１は、図９のシステムについてのイベント生成系／イベントリスナ機構を
示す、より詳細な図である。概括的には、図１１に示す取り組みはＪＡＶＡ JDK
１．１イベントモデルの改良品である。このモデルでは、３種類のオブジェクト
が考えられる。第1種類のオブジェクトは、イベントの発生についての情報を保
有しているイベントオブジェクトである。イベントオブジェクトの種類は発生し
うるイベントの異なる種類全部に対応して幾つあってもよい。第２種類のオブジ
ェクトはEvent生成系であり、これは活動を監視し、何かが起きたときにイベン
トオブジェクトを生成する。３番目は、イベントリスナであり、これはイベント
生成系により生成されたイベントオブジェクトを聞く。イベントリスナは、通常
は、特定のウインドウ上でのマウスクリックの場合のような、特定のイベント生
成系を聞く。イベントリスナは、イベント発生プログラム上で"ADD event listn
er"法を呼び出す。このモデルは、ＸＭＬ文書により表現されるような、オブジ
ェクトのグラフを構文解析してウォークすることに応答してオブジェクトが生成
される図９の環境に適合することができる。

【０１０４】図１１に示すシステムは、総称的なＸＭＬ構文解析系１１００を含んでいる。
このような構文解析系は、標準コールバックモデルを使って実行することができ
る。構文解析イベントが発生すると、構文解析系は、パラメータ内の適切な情報
に通じるアプリケーションオブジェクト内の特定方法を呼び出す。このようにし
て、１つのアプリケーション１１０１が構文解析系と共に存在する。アプリケー
ションは、ブロック１１０２により示すように、ＸＭＬイベントオブジェクトの
構文解析系により提供される情報をパッケージ化して、それを、身元が明確にな
っているできる限り多くのイベントリスナに送信する。イベントのセット１１０
２は完全に構文解釈非依存型である。イベント１１０２は、任意数のリスナ及び
任意数のマシン上の任意数のスレッドに提供することができる。イベントは、１
つの代替例では、エレメント構造情報セットＥＳＩＳに基づいている。このよう
に、それらは、エレメントの開始と終わりのような文書構造の重要な態様の、又
は属性の認識の、リストから構成されている。ＸＭＬ（及びＳＧＭＬ）構文解釈
は、通常、構文解釈系がそのアプリケーションに戻るための情報のデフォルトセ
ットとして、ＥＳＩＳ構造を使う。

【０１０５】特殊化されたＥＳＩＳリスナ１１０３が、イベント１１０２のセットに連結さ
れている。このリスナ１１０３は、ＥＳＩＳリスナＡＰＩを実行し、１つ又はそ
れ以上の生成系から全ＸＭＬイベントを聞く。エレメントイベント生成系１１０
４は、ＸＭＬイベント生成系でもある特殊化されたＥＳＩＳリスナである。例え
ば、ＨＴＭＬ環境では、リスナは順序づけられたリストにしか、即ち、<OL>タグ
と</OL>タグの間の文書の部分にしか興味を持たない。また別の実施例では、リ
スナは、上記の文書例から、共通ビジネス言語による"party.name"エレメント又
は"service.name"エレメントを聞き、エレメントが確実に、エレメントの概略マ
ッピングに合うデータを伝えるようにイベントを処理し、そして受信側ノードで
必要とされる処理に則って反応する。

【０１０６】これにより、システムは、価格を合計するだけというような文書の特定部分を
聞く小さなオブジェクトを持てるようになる。リスナは、生成系に加わることも
そこから外れることもできるので、例えばＨＴＭＬ文書の<HEAD>部分しか聞かな
いリスナもありうる。このことにより、そしてＸＭＬ文書の再帰性が強いことに
より、かなり目標にかなったコードを書き、同時に複数のリスナに書き込むこと
が可能である。例えば、<OL>リスナは、<UL>（注文されていないリスト）リスナ
がその<LI>リスナを設定するやり方とは全く違ったやり方で、<LI>リスナを設定
することができる。別の方法としては、それはグラフィックユーザーインタフェ
ースを生成するリスナ、及び同じ入力を使ってデータベースを探索する別のリス
ナを創造することができる。このように、アプリケーションが一度に1つずつ検
査する完成型データ構造とは対峙的に、文書は、リスナによって実行されるプロ
グラムとして取り扱われる。アプリケーションがこのように書き込まれれば、ア
プリケーションを実行するために文書全体をメモリ内に保持する必要はない。

【０１０７】イベントのセット１１０２に連結されている次のリスナは、属性フィルタ１１
０５である。属性フィルタ１１０５は、エレメントフィルタ１１０４同様、ＥＳ
ＩＳリスナモデルに則した属性イベント生成系である。属性フィルタ用のリスナ
は、自身が興味を持っている属性を指定し、指定した属性を有するエレメントの
イベントであれば全て受信する。従って、例えば、フォントマネジャなら、<P F
ONT="Times Roman"/P>というようなフォント属性を有するエレメントについての
イベントしか受信しないことになる。

【０１０８】エレメントイベント発生系１１０４は、エレメントリスナ１１０４Aを特殊化
するために、そのようなエレメントオブジェクトを提供する。

【０１０９】属性イベント発生系１１０５は、属性イベントオブジェクトを属性リスナ１１
０５Aに供給する。同様に、属性オブジェクトは、属性を使って１つの文書型式
から別の文書型式へのSGML/ＸＭＬ変換という意味において、"architecture"に
供給される。こうして、１１０５Bのアーキテクチャは、特定の名前を持った特
定の属性が区別できるようにしている。定義された属性を備えたエレメントだけ
が出力文書の一部となり、出力文書のエレメントの名前は、入力文書中の属性の
値である。例えば、アーキテクチャ１１０５BがHTMLであれば、ストリング： <PURCHASE SHTML="OL"><ITEM HTML="LI"><NAME HTML="B">STUFF</NAME><PRICE HTML="B">123</PRICE></ITEM></PURCHASES> は、 <OL><LI><B>STUFF</B><B>123</B></LI></OL> と翻訳され、これが正確なＨＴＭＬである。

【０１１０】イベントのセット１１０２に連結されている次のモジュールは、ツリービルダ
１１０６である。ツリービルダは、ＸＭＬイベントのストリームを取り込み、下
層文書のツリー表現を生成する。ツリービルダ１１０６の１つの好ましいバージ
ョンは、Ｗ３Ｃの定義に従って、文書オブジェクトモデルＤＯＭオブジェクト１
１０７を生成する。（http://www.w3.org/TR/1998/WD-DOM-19980720/introduction.html参照）。しかしながら、イベントストリーム内のリスナを使って殆どの要求を処理するこ
とができるので、ツリーバージョンは、文書周辺のキューのサポート、ノードの
記録、新規文書の作成、及び、例えば文書を何回も構文解釈するというような同
一のイベントストリームを多数回生成できるメモリ内のデータ構造のサポート、
に有用である。特定の実行形態にあわせて、文書の部分用の特別なサブツリーを
構築するために、特殊化されたビルダ１１０８をツリービルダ１１０６に連結す
ることもできる。

【０１１１】入ってくる文書への応答に加えて、ＸＭＬイベント１１０２の他のソースを提
供することもできる。こうして、イベントストリーム１１１０は、ＤＯＭオブジ
ェクトのツリー上をウォークし、文書の構文解析中に作り出された元のイベント
ストリームを再生することにより生成される。これにより、システムは、文書が
何度も構文解析されている状況を提示することができる。

【０１１２】ツリーをウォークしイベントのストリームを生成するオブジェクトの思想は、
ＤＯＭオブジェクトのツリーを越え、照会できるオブジェクトのツリー何れに対
しても一般化することができる。このように、ＪＡＶＡウォーカー１１１２は、
ＪＡＶＡビーンコンポーネント１１１３のツリーをウォークするアプリケーショ
ンであってもよい。ウォーカーは、公にアクセス可能な全フィールドと方法上を
ウォークする。ウォーカーは、エンドレスサイクルに入ってしまわないようにす
るために、既に訪ねたことのあるオブジェクトの軌跡を保持している。ＪＡＶＡ
イベント１１１４は、ＪＡＶＡウォーカー１１１２により生成されたイベントの
型式である。これは、オブジェクトから導き出せる殆どの種類の情報を同時に含
んでいる。これはＥＳＩＳのＪＡＶＡに匹敵するものであり、ＸＭＬに適用され
るものと同じプログラミングアプローチを、具体的にはＪＡＶＡビーンズではあ
るが、概ねＪＡＶＡオブジェクトに適用できるようにしている。

【０１１３】ＪＡＶＡ対ＸＭＬイベント発生系１１１５は、ＪＡＶＡリスナ及びＪＡＶＡイ
ベント発生系を構成している。これは、ＪＡＶＡウォーカー１１１２からイベン
トのストリーム１１１４を受信して、選択されたイベントを翻訳し、ＪＡＶＡオ
ブジェクトをＸＭＬ文書として表す。１つの好適な実施例では、イベント発生系
１１１５はＪＡＶＡビーンズＡＰＩを利用する。見られた各オブジェクトはエレ
メントになり、クラス名と同じエレメント名を持つ。そのエレメント内では、各
組み込み型方法も、その内容がその方法を呼び出すことにより戻された値である
エレメントにもなる。それがオブジェクト又はオブジェクトのアレイであれば、
これらは順にウォークされる。

【０１１４】図１２は、図１１のフレームワーク上に構築される特定のアプリケーションの
概要を示している。このアプリケーションは、ＸＭＬ文書１２００を取り込み、
それを構文解析系／発生系１２０１に適用する。ＥＳＩＳイベント１２０２が生
成され、属性発生系１２０３及びツリービルダ１２０４に供給される。属性発生
系は図５の発生系５０５に対応する。それは、例えばＸＭＬ入力をＨＴＭＬ出力
に翻訳する場合に"architecture"５０５Bにイベントを供給する。これらイベン
トは、ブロック１２０５により表示されるように並行処理され、そしてリスナに
より処理される。リスナの出力は、文書ライタ５０６に供給され、その後出力用
のＸＭＬフォーマットに翻訳し戻される。このように、例えは、図１２に示すこ
のアプリケーションは、ＸＭＬ文書を取り込み、ある形式を保有しているＨＴＭ
Ｌ文書を出力する。当該形式はブラウザに送信され、その結果がＸＭＬに変換し
戻される。この実行に関し、アーキテクチャコンセプトは、ＸＭＬからＨＴＭＬ
へのマッピングを提供する。図１２に含まれる３つのアーキテクチャは、第1に
表やリストのような、ＨＴＭＬ文書の構造を提供するためのアーキテクチャ、第
２にはブラウザ文書上の入力フィールド用のラベルのような、表示されるテキス
トを指定するアーキテクチャ、第３には入力フィールド自体を記述するアーキテ
クチャを含んでいる。ＸＭＬ文書構造を維持するために必要なＸＭＬ文書のエレ
メントは、ＨＴＭＬ形式では見えないフィールドとなる。これは、サーバに送り
返されるＨＴＴＰ通知メッセージにクライアントが入れる情報から、ＸＭＬ文書
の再構築をするのに使用する際に役に立つ。各アーキテクチャは、入力文書を取
り込み、それをＨＴＭＬのサブセットに基づいてアーキテクチャに変換する。こ
れらイベントを聞いているリスナは、ＨＴＭＬ文書用のイベントを出力し、これ
らイベントが次に文書ライタオブジェクトに行く。文書ライタオブジェクトは、
ＸＭＬイベントを聞き、それらをＸＭＬ文書に戻す。文書ライタオブジェクトは
、本例ではアーキテクチャを聞くエレメント生成系全てに対するリスナである。

【０１１５】図１１及び１２に示す処理モジュールの編成は、図９のシステムに関する構文
解析系及び取引処理フロントエンドの１つの実施例を表している。見て分かるよ
うに、非常にフレキシブルなインタフェースが提供されており、これにより多種
多様な取引処理を、入ってくるＸＭＬ文書又は他の構造の文書フォーマットに応
じて、実行することができる。

【０１１６】図１３は、ビジネスインタフェース定義ビルダモジュール１３００を含んでい
る点を除けば、図9のものと同様のノードを示している。このように、図１３の
システムは、ネットワークインタフェース１３０１、文書構文解析系１３０２、
及び文書翻訳系１３０３を含んでいる。翻訳系１３０３は、自身の出力を取引処
理フロントエンド１３０４に提供し、このフロントエンドは、商業機能１３０５
のようなリスニング機能、データベース１３０６、企業機能１３０７、及び他の
一般的なリスナ及びプロセッサ１３０８に連結されている。図１３に示すように
、ビジネスインタフェース定義ビルダ１３００は、ユーザーインタフェース、共
通のビジネスライブラリＣＢＬリポジトリ、相補的ビジネスインタフェース定義
を読むためのプロセス、及びコンパイラを含んでいる。ユーザーインタフェース
は、共通のビジネスライブラリリポジトリに依存しているビジネスインタフェー
ス定義の構築の際に企業を援助し、相補的なビジネスインタフェース定義を読む
能力を支援するために使われる。こうして、相補的なビジネスインタフェース定
義の入力文書を、特定の取引の出力文書として指定し、相補的なビジネスインタ
フェース定義の出力文書を、そのような取引処理への入力として指定することが
できる。同様の方法で、取引ビジネスインタフェース定義を、ＣＢＬリポジトリ
から選択されたコンポーネントを使って構成することができる。ＣＢＬリポジト
リを使えば、上記例のスキーマ（bid1）文書のような標準化された文書フォーマ
ット、論理構造、及びネットワーク上の他の人々によって容易に適合化できるビ
ジネスインタフェース構築時の解釈情報の使用が奨励される。

【０１１７】ビジネスインタフェース定義ビルダモジュール１３００は、翻訳系１３０３即
ちホスト取引処理アーキテクチャに従って翻訳系により作成されるオブジェクト
の生成に、そして構文解析機能１３０２の管理に利用されるコンパイラも含んで
いる。

【０１１８】図１４は、ビジネスインタフェース定義ビルダ１３００のリポジトリに記憶さ
れている論理構造を示す、発見に役立つ概要図である。このように、リポジトリ
は、例えば、消費者ＢＩＤ１４０１、カタログショップＢＩＤ１４０２、倉庫Ｂ
ＩＤ１４０３、競売場ＢＩＤ１４０４を含む、代表的当事者ビジネスインタフェ
ース定義１４００を保有している。こうして、オンライン市場の新規参加者は、
基本的なインタフェース記述として、自身のビジネスに最も整合する標準化され
たＢＩＤの1つを選択できるようになっている。更に、リポジトリは、サービス
ビジネスインタフェース定義のセット１４０５を記憶する。例えば、注文入力Ｂ
ＩＤ１４０６、注文追跡ＢＩＤ１４０７、注文成就ＢＩＤ１４０８、及びカタロ
グサービスＢＩＤ１４０９が記憶されることになる。市場の新規参加者がビジネ
スインタフェース定義を構築する際には、リポジトリ内に記憶されている標準化
されたサービスのビジネスインタフェース定義を選択することになる。

【０１１９】当事者及びサービスＢＩＤに加えて、入出力文書ＢＩＤが、フィールド１４１
０で示されるリポジトリに記憶される。このように、購入注文ＢＩＤ１４１１、
インボイスＢＩＤ１４１２、見積もり要求ＢＩＤ１４１３、製品入手可能性報告
ＢＩＤ１４１４、及び注文状態ＢＩＤ１４１５がリポジトリに記憶されることに
なる。

【０１２０】リポジトリは、ある好適なシステムではＸＭＬによる文書型式定義として指定
されるビジネスインタフェース定義に加えて、フィールド１４１６で示される意
味論的マップの形態で解釈情報を記憶している。こうして、本例では、重量１４
１７、通貨１４１９、大きさ１４１９、製品識別子１４２０、及び製品特性１４
２１を指定するために使用される意味論的マップが、リポジトリに記憶されるこ
とになる。更に、解釈情報は、文書の論理構造内のデータ構造のタイピングに備
えている。

【０１２１】更に、ビジネスインタフェース定義の構成に使用される論理構造は、ブロック
１４２２で示されるリポジトリに記憶されることにる。このように、アドレス情
報を提供するフォーム１４２３、価格付け情報を提供するフォーム１４２４、及
び契約関系の条項を提供するフォーム１４２５、が提供されることになる。ネッ
トワークが拡張するにつれ、ＣＢＬリポジトリも、新規参加者の追加とビジネス
インタフェース定義の変更をより容易にする傾向を拡張し標準化する。

【０１２２】図１５は、図１３のシステムを用いてビジネスインタフェース定義を構築する
プロセスを示す。このプロセスは、ＢＩＤビルダーグラフィカルインタフェース
をユーザーに表示する（ステップ１５００）ことにより開始される。システムは
、参加者、サービス、及びグラフィカルインタフェースにより生成される文書情
報を特定するユーザー入力を受け取る（ステップ１５０１）。

【０１２３】次に、関連する論理構造、説明情報、文書定義及び／又はサービスの定義全て
が、グラフィカルユーザーインタフェースを介して行われるユーザー入力に応じ
てリポジトリから検索（ステップ１５０２）される。次の段階で、相補的ビジネ
スインタフェース定義又はビジネスインタフェース定義の構成要素の全てが、特
別仕様のサーチエンジン、ウェブブラウザ等によって、ユーザー入力を通して選
択されたネットワーク内の別の参加者からアクセス（ステップ１５０３）される
。参加者のための文書定義は、集められた情報を使って作成（ステップ１５０４
）される。文書対ホスト及びホスト対文書のマッパのための翻訳系は、コンパイ
ラによって作成（ステップ１５０５）される。定義に対応するホストアーキテク
チャデータ構造は、コンパイラによって作成（ステップ１５０６）され、既に作
成されていたビジネスインタフェース定義は、ウェブサイト等に掲示するなど、
ネットワーク上に掲載され、ネットワーク内の別のノードへアクセスできるよう
にする（ステップ１５０７）。

【０１２４】ビジネスインタフェース定義は、可能性のある取引相手に、会社が提供するオ
ンラインサービス、及びそれらのサービスを呼び出すために用いる文書について
通告する。従って、サービスは、ビジネスインタフェース定義内で、彼らが受け
取って作成した文書によって定義される。これを、ＸＭＬサービス定義に関する
下記のフラグメントに示す。

【０１２５】

【数４８】

【０１２６】このＸＭＬのフラグメントは、注文を取るための取引と、それを追跡するため
の取引の、２つの取引から構成されるサービスを定義する。各定義は、指定され
たウェブアドレスに有効な要求が提出される場合に、サービスを実行するための
契約又は約定を示す。注文のサービスは、ここでは、ローカルなものであっても
よいがリポジトリ内に配置されているか、又はネットワーク上のある企業の範囲
で記憶されている、標準的な"po.dtd"文書形式定義に従った入力文書を必要とす
る。ノードが注文を満たすことができれば、ノードは、定義がローカルである特
別仕様の"invoice.dtd"に従った文書を戻す。基本的に、会社は、会社が指定す
るＸＭＬ仕様に従った購入注文書を提出できる人なら誰とでもビジネスを行うこ
とを約束している。事前の契約書は必要ない。

【０１２７】ＤＴＤは、所定の型式の文書に関する公式の仕様又はグラマーであり、エレメ
ント、その属性、及びそれが出現する順序について記載している。例えば、購入
注文書は、一般的に、買い手及び売り手の名前とアドレス、製品説明書一式、価
格及び発送日のような付属する条項及び条件を含んでいる。例えば電子データ交
換ＥＤＩでは、購入注文に関して一般的に用いられているモデルはＸ１２８５０
仕様である。

【０１２８】リポジトリは、多くのビジネスの領域で一般的である再使用可能な意味構成要
素からＸＭＬ文書モデルを展開するよう促す。そのような文書は、非常に異なる
ように見えたとしても、一般的なメッセージエレメントから理解することができ
る。これは、共通ビジネスライブラリリポジトリの役目である。

【０１２９】共通ビジネスライブラリリポジトリは、・会社、サービス及び製品のようなビジネス記述プリミティブと、・カタログ、購入注文書及びインボイスのようなビジネスフォームと、・標準的尺度、日付及び時間、場所、分類コードと、を含む総称的なビジネス概
念に関する情報モデルから成る。

【０１３０】この情報は、ＸＭＬのアプリケーションを迅速に展開するために、会社が特注
して組み立てることができる、拡張可能な公共のＸＭＬビルディングブロックの
セットとして示される。原子的ＣＢＬエレメントは、国、通貨、アドレス及び時
間に関する標準的なＩＳＯコードのような企業メッセージ送信標準及び協定を実
行する。低レベルＣＢＬのセマンティックスも、ダブリンコアのようなインター
ネットリソースに対して提案されたメタデータフレームワークの分析から生まれ
ている。

【０１３１】次のレベルのエレメントは、Ｘ１２ＥＤＩ取引で用いられているような基本的
なビジネスフォーム、並びに、ＯＰＴ（公開取引プロトコル）及びＯＢＩ（イン
ターネット上での公開購入）のような新規のインターネット標準に用いられてい
る様式を実行するために、これらのビルディングブロックを用いる。

【０１３２】ＣＢＬの焦点は、全ビジネスドメイン（会社、サービス及び製品のようなビジ
ネス記述プリミティブと、カタログ、購入注文書、及びインボイスのようなビジ
ネスフォームと、標準的な尺度、日付及び時間、場所、分類コードと）に共通な
機能及び情報にある。ＣＢＬは、セマンティックスに関して、考えられる標準又
は企業協定上に構築される（例えば、欧州では「日／月／年」であるのに対し、
米国では「月／日／年」と指定する規定が、それぞれのＣＢＬモジュール内にエ
ンコードされている）。

【０１３３】ＣＢＬは、アプリケーションを設計するために用いられる言語である。ＣＢＬ
は、ＸＭＬの「文書ワールド」と、ＪＡＶＡ又は別の取引処理アーキテクチャの
「プログラミングワールド」との間のギャップを橋渡しするように設計されてい
る。スキーマは「文書によるプログラミング」の理念を具体化しており、その中
では文書タイプの詳細で正式な仕様がマスターソースであり、そこから様々な関
連様式を作り出すことができる。これらの様式は、ＣＢＬのためのＸＭＬＤＴＤ
と、ＪＡＶＡオブジェクトと、ＸＭＬインスタンスを対応するＪＡＶＡオブジェ
クトへ変換したり、その逆に変換するためのプログラムと、サポート文書とを含
んでいる。

【０１３４】ＣＢＬは１つのソースを作り、そこからシステムの全ピースがコンパイラによ
り自動的に生成される。ＣＢＬは、一般的には特定の文書型式の構造を正式に定
義するのに用いられているＳＧＭＬ／ＸＭＬを拡張することにより、各情報エレ
メント及び属性と関連するセマンティックスの仕様を含むように作用する。ＳＧ
ＭＬ／ＸＭＬにおける（殆ど）キャラクタ型式の限定されたセットは、どのよう
な種類のデータ形式であれ宣言するために拡張することができる。

【０１３５】「日時」モジュールに関するＣＢＬ定義からのフラグメントは以下のようにな
る。

【０１３６】

【数４９】

【０１３７】このフラグメントでは、ＥＬＥＭＥＮＴ"year"はキャラクタデータとして定義
されており、関連する"schema"属性もキャラクタデータであるが、これは"year"
に関するスキーマをＩＳＯ８６０１標準の３．８項と定義する。

【０１３８】この"datetime"ＣＢＬモジュールが、実際に、スキーマＤＴＤの例として定義
される。先ず、モジュール名が定義される。すると"datetime"要素“ＹＥＡＲ”
は、ＩＳＯ８６０１のセマンティックスに限定される。

【０１３９】

【数５０】

【０１４０】上記の、例である市場参加者及びサービスモジュールも、ＣＢＬリポジトリに
記憶される。

【０１４１】図１６では、エアビル１６００が、一般的な購入注文書ＤＴＤ１６０１をカス
タマイズし、出荷重量に関するより具体的な情報１６０２を加えることによって
定義されている。一般的な購入注文書１６０１は、最初は、住所、日時、通貨、
販売元及び製品の記述に関するＣＢＬモジュールから組み立てられていた。ＣＢ
Ｌを利用すると、このようにＸＭＬの商業用アプリケーションの開発と実施を著
しく早めることができる。更に重要なことは、ＣＢＬが、商業用アプリケーショ
ンを相互接続され易いようにするということである。

【０１４２】ＣＢＬでは、ＸＭＬはスキーマと共に拡張される。拡張の際には、内容を容易
に確認できるように、ＸＭＬエレメントに強力なタイピングが加えられる。例え
ば、<CPU_clock_speed>と呼ばれるエレメントは、一式の有効値｛１００、１３
３、１６６、２００、２３３、２６６Ｍｈｚ｝による整数として定義できる。更
にスキーマは、クラス―サブクラスの階層を追加するので、情報はクラス定義か
ら容易に例示できる。例えば、ラップトップは、ディスプレイの型式及びバッテ
リーの寿命のような特徴に関する追加タグを備えたコンピュータとして記述する
ことができる。上記及びその他の拡張によって、ＸＭＬと伝統的なオブジェクト
指向のリレーショナルデータモデルとの間の自動翻訳、並びにデータエントリが
容易になる。

【０１４３】こうして、出来上がったＢＩＤはコンパイラに通され、コンパイラは、上に概
要を述べた参加者及びサービスの現実の事例に関するＤＴＤと、ＤＴＤ事例の論
理的構成に対応するＪＡＶＡビーンズと、ＸＭＬからＪＡＶＡへ、ＪＡＶＡから
ＸＭＬへ変換するための変換コードとを作る。別のシステムでは、ユーザーイン
タフェース上での表示又はユーザーによる印刷のために文書化が行われ、オブジ
ェクトを利用し易くする。この例は「取引相手ネットワークでの商取引のための
文書と、その文書に基づくインタフェース定義」と題する米国特許出願番号第０
９／１７３，８５８号に見られ、参考文献としてここに援用する。

【０１４４】本発明のＣＢＬ及びＢＩＤプロセッサの、ＸＭＬ／ＪＡＶＡ環境内でのアプリ
ケーションについては、購入注文の処理に関する次の説明により、更に理解され
るであろう。

【０１４５】会社Ａは、ＣＢＬＤＴＤのライブラリと、データ型式及びその他の翻訳情報を
含むように全て共通ビジネス言語エレメントを使って定義されたモジュールとを
含む仮想プログラミング環境を使って、その購入注文の文書形式を定義する。会
社ＡのＰＯは、ＣＢＬライブラリと共に来るより包括的な「取引文書」仕様を僅
かにカスタマイズするだけのものでもよいし、或いは、アドレス、日時、通貨な
とに関して、ＣＢＬモジュールから新に組み立てるものでもよい。

【０１４６】（上に述べたtransact.dtdのような）包括的な「取引文書」仕様の文書化は、
ＣＢＬ仕様がモジュールから組み立てられて、他のＣＢＬＤＴＤと相互連結され
る典型的な方法である。

【０１４７】コンパイラは、購入注文書の定義を取り出し、幾つかの異なる目標フォームを
作る。これら全ての目標フォームは、最初の仕様の「ツリートゥツリー」変換を
通して導き出すことができる。この例で最も重要なのは下記事項である。（ａ）購入注文のためのＸＭＬＤＴＤ。（ｂ）購入注文のためのデータ構造をカプセル化するＪＡＶＡビーン（購入注文
書のスキーマ定義の情報に対応するＪＡＶＡクラス、アーギュメント、データ型
式、方法及び例外的造が作られる）。（ｃ）購入注文ＤＴＤに従った購入注文書を、購入注文書ＪＡＶＡビーンに変換
するか、或いは、それらをデータベースにロードするか、又は購入注文をブラウ
ザに表示するためのＨＴＭＬ（又はＸＳＬスタイルシート）を作る「マーシャリ
ング」プログラム。（ｄ）購入注文書ＪＡＶＡビーンズからデータ値を引き出し、それらを、購入注
文ＤＴＤに従ったＸＭＬ文書に変換する「非マーシャリング」プログラム。

【０１４８】さて、シナリオに話を戻す。購入アプリケーションは、購入注文を受けるサプ
ライヤへのサービスインタフェースとして指定されているＤＴＤに従った購入注
文書を作る。

【０１４９】構文解析系は、購入注文ＤＴＤを用いて、購入注文書を、中に含まれているエ
レメントと属性値に関する情報のストリームに分解する。次に、これらの「特性
セット」は、ＪＡＶＡコードでラッピングすることによって、対応するＪＡＶＡ
イベントオブジェクトに変換される。実際に、この変換では、マークアップＸＭ
Ｌ文書を、グラマーがＤＴＤにより定義されているカスタムプログラミング言語
内で命令として取り扱う。これで、これらＪＡＶＡイベントは、ＪＡＶＡビーン
データ構造を「ロードする」ためにコンパイラにより作られたマーシャリングア
プリケーションによって処理することができる。

【０１５０】ＸＭＬ文書をＪＡＶＡアプリケーション用のイベントのセットに変換して処理
するのは、構文解析系の出力が内部データ構造として維持され、構文解析が完了
するまで処理が始まらない通常の構文解析のモデルとは異なっている。ＢＩＤ定
義に応じた、イベントベースの処理は、第１イベントが発せられとすぐに、文書
アプリケーション処理を同時に開始できるようにするので、プロセッサの機能を
より優れたものとするキーである。

【０１５１】様々な型式のイベントに「耳を澄ます」ＪＡＶＡプログラムは、それらのイベ
ントのスキーマ定義から作られる。これらのリスナは、ＣＢＬ内のＸＭＬ定義と
関連するビジネス論理を実行するために作られたプログラムであり、例えば「ア
ドレス」と関連するエレメントは、データベースをチェックすることにより郵便
番号を確認するコードであってもよい。これらのリスナは、文書ルーターに登録
することによってイベントに「申込み」し、文書ルーターは、イベントに関心を
持っている全申込み者に関連イベントを送る。

【０１５２】この公表及び申込みアーキテクチャは、新しいリスナプログラムを、現存のプ
ログラムに関する知識無しに、即ち現存のプログラムに影響を及ぼすこと無く追
加できることを意味している。リスナはそれぞれ、ルーターがイベントを送り込
む待ち行列を有しており、複数のリスナがイベントをそれぞれのペースで並行し
て扱うことができるようになっている。

【０１５３】この購入注文の例では、リスナは以下のことが行える。・購入注文：購入注文を注文エントリプログラムへ接続させる・製品記述：在庫を確認する・アドレス情報：発送の利用に関してFedEx又は別のサービスを確認できる・買い手情報：注文の履歴を確認できる（信用価値のため、プロモーション資料
提供のため、或いは、顧客の身元が判明していることを前提に同様の処理を提案
するため）。

【０１５４】コンプレックスリスナは、プリミティブリスナのコンフィギュレーションとし
て作ることができる（例えば、購入注文リスナは、これらのリスナを含んでおり
ここで呼び出すこともできるし、自分自身上に呼び出してもよい）。

【０１５５】図１７は、図３のネットワーク内の市場メーカーノードを示す。市場メーカー
ノードは、図９のシステムの基本構造を含んでおり、ネットワークインタフェー
ス１７０１と、文書構文解析系１７０２と、文書対ホスト及びホスト対文書翻訳
系１７０３と、この例ではルーターと呼ばれるフロントエンド１７０４とを含ん
でいる。この例における市場メーカーモジュール１７０５は、市場の参加者のた
めのビジネスインタフェース定義のセット又は市場メーカー機能をサポートする
のに十分な他の識別子と、ＣＢＬリポジトリと、コンパイラとを含んでおり、こ
れらは全て市場の参加者にサービスするものである。ルーター１７０４は、参加
者レジストリと、文書フィルターとを含んでおり、文書フィルターは、翻訳系の
出力で構文解析系により作られるイベントに応じて、参加者レジストリと、リス
ナ間のエレメント及び属性のフィルターに従って、入ってくる文書をＸＭＬイベ
ント発生系へ送る。従って、市場のある参加者は、事前指定されたパラメータを
満たす文書を受け取るように登録することができる。例えば、特定のＤＴＤに従
っており、且つ、閾値以上の購入される製品の数のような、或いは文書の要求す
る購入の最高額のような属性を含む入力文書が、ルーター１７０４で文書にフィ
ルターを掛けるのに用いられる。そして、ルーター１７０４で参加者レジストリ
に登録されている情報と一致する文書だけが、登録された参加者に送られる。

【０１５６】更に、ルーター１７０４は、局所ホストサービス１７０５、１７０６をサービ
スし、市場メーカー並びに市場の参加者として行動してもよい。一般的に、ルー
ター１７０４が受信する文書は、その文書を送るべき宛先を決定するために点検
され、そこで必要ならば再び翻訳系１７０３に戻され、そしてネットワークイン
タフェース１７０１から各宛先へ送られる。

【０１５７】市場メーカーは、一式の内部及び外部のビジネスサービスを１つに束ねて仮想
企業又は取引コミュニティを作るサーバーである。サーバーは、入ってくる文書
を構文解析し、例えば、製品データに関する要求をカタログサーバーへ渡すか、
或いは、購入注文書をＥＲＰシステムへ転送することによって、適切なサービス
を実施する。更に、サーバーは、翻訳作業を扱い、会社のＸＭＬ文書からの情報
を、取引相手が使っている文書フォーマットと、その今まで蓄積されてきたシス
テムが求めるデータフォーマットとにマップする。

【０１５８】上記サービス定義によれば、会社が購入注文を提出すると、サーバーのＸＭＬ
構文解析系は、購入注文ＤＴＤを用いて購入注文を情報イベントのストリームに
変換する。次にこれらのイベントは、所与の型式のイベントを扱うようにプログ
ラムされている何れかのアプリケーションに送られ、場合によっては、情報が、
インターネットを通じて全く異なるビジネスに転送される。購入注文の例では、
幾つかのアプリケーションが、構文解析系から入ってくる情報に基づいて以下の
ように行動する。・注文記入プログラムは、購入注文を完全なメッセージとして処理し、・ＥＲＰシステムは、購入注文書に記載されている製品の在庫をチェックし、・顧客データベースは、顧客のアドレスを確認又は更新し、・輸送会社は、配送を計画するためにアドレス情報を用い、・銀行は取引を承認するのにクレジットカード情報を用いる。

【０１５９】取引相手は、ＡＩＰの詳細に同意する必要はなく、交換するビジネス文書の構
造、内容及び順序付けに同意するだけでよい。文書の処理の仕方及び行為の結果
は、全く、サービスを提供するビジネス次第である。このことは、インテグレー
ションをシステムレベルからビジネスレベルへ上げる。そのことにより、内部技
術の実装、編成又は処理における変更に関係なく、ビジネスは、取引相手に偽り
の無い安定したインタフェースを示すことができるようになる。

【０１６０】図１８、１９、２０は、図１７のシステム内の市場メーカーノードで実行され
るプロセスを示す。図１８では、始発参加者ノードから入力された文書が、ネッ
トワークインタフェースで受信（ステップ１８００）される。文書は構文解析（
ステップ１８０１）される。文書は、例えばＸＭＬからＪＡＶＡへというように
、ホストのフォーマットへ翻訳（ステップ１８０２）される。ホストフォーマッ
ト化されたイベント及びオブジェクトは、次にルーターサービスに（ステップ１
８０３）送られる。文書型式及び文書の内容に従って文書を受信するように登録
されているサービスが識別（ステップ１８０４）される。文書又は文書の一部が
、識別されたサービスへ（ステップ１８０５）送られる。文書の内容に応じてサ
ービスが実行（ステップ１８０６）される。サービスの出力データが作成（ステ
ップ１８０７）される。出力は、例えばＪＡＶＡフォーマットからＸＭＬフォー
マットのように、文書フォーマットに変換（ステップ１８０８）される。最後に
、出力文書が参加者ノードへ送られる（ステップ１８０９）。

【０１６１】登録サービスは、ルーターにより管理される機能の１つである。従って、市場
参加者文書は、図１９に示されているようにネットワークインタフェースで受信
（ステップ１９００）される。市場参加者文書は、市場メーカーノードのために
、ビジネスインタフェース定義リポジトリ内に記憶（ステップ１９０１）される
。更に、文書は構文解析（ステップ１９０２）される。構文解析された文書は、
ホストのフォーマットに変換（ステップ１９０３）される。次に、文書はルータ
ーサービスに（ステップ１９０４）送られる。ルーターサービスは、登録サービ
スを、文書型式及び内容に従って文書の宛先として識別するリスナを含んで（ス
テップ１９０５）いる。文書又は文書のエレメントは、登録サービスへ送ら（ス
テップ１９０６）れる。登録サービスでは、必要なサービス仕様が、ビジネスイ
ンタフェース定義に従って検索（ステップ１９０７）される。サービス仕様が集
められると、ステップ１９０８で、ルーターサービスフィルターがビジネスイン
タフェース定義及びサービス仕様に従って設定（ステップ１９０９）される。登
録確認応答データが（ステップ１９１０）作られる。登録確認応答データは、文
書フォーマットに変換（ステップ１９１１）される。最後に、確認応答文書が参
加者ノードへ送られ、市場メーカーと共に順調に登録されたことを参加者に示す
（ステップ１９１２）。

【０１６２】必要なサービス仕様を集めるステップ１９０７のプロセスを、１例として図２
０に示す。このプロセスは、市場参加者によりサポートされているサービスビジ
ネスインタフェース定義を設置することにより開始（ステップ２０００）される
。サービス定義は、例えば、リポジトリノードへのＥメール取引又はウェブアク
セスによって検索（ステップ２００１）される。サービス仕様は、ＢＩＤリポジ
トリ内に記憶（ステップ２００２）される。サービスビジネスインタフェース定
義文書が構文解析（ステップ２００３）される。構文解析された文書は、ホスト
のフォーマットに翻訳（ステップ２００４）される。ホストオブジェクトはルー
ターサービスへ（ステップ２００５）送られる。登録サービスは、文書型式及び
内容に従って識別（ステップ２００６）される。最後に、サービスビジネスイン
タフェース定義文書内の情報は、図１９のプロセスに従って利用するために登録
サービスに送られる（ステップ２００７）。

【０１６３】図２１は、本発明に従って、市場メーカーノードで入ってくるデータの処理を
行う、プロセッサ、構成要素及び順序を示す。市場メーカーノードは、ネットワ
ークインタフェースに通信エージェント２１００を含んでいる。通信エージェン
トは、ＸＭＬ構文解析系２１０１に連結されており、ＸＭＬ構文解析系２１０１
は、イベントをＸＭＬプロセッサ２１０２へ供給する。ＸＭＬプロセッサは、イ
ベントを文書ルーターへ供給する。文書ルーターは、受信した文書をホストシス
テム内の企業ソルーションソフトウェア２１０５へ供給するためのインタフェー
スを提供する文書サービス２１０４に送る。通信エージェント２１００は、ＨＴ
ＴＰ、ＳＭＴＰ、ＦＴＰ又は他のプロトコルのようなプロトコルをサポートする
適切なプロトコルスタックを含むインターネットインタフェースである。従って
、入ってくるデータは、特定の通信チャネルに適する、ＸＭＬ構文、ＡＳＣＩＩ
データ構文、又は他の構文で入ってきてもよい。非ＸＭＬ構文で受信される文書
は全て、ＸＭＬに翻訳され、ＸＭＬ構文解析系へ送られる。翻訳テーブル２１０
６は、非ＸＭＬフォームからＸＭＬフォームへの翻訳をサポートするのに用いら
れる。

【０１６４】変換された文書は、構文解析系２１０１に供給される。ＸＭＬ構文解析系は、
受信したＸＭＬ文書を、適合する文書型式定義に従って解析する。エラーが見つ
かると、構文解析系は文書を通信エージェント２１００へ戻す。ビジネスインタ
フェース定義コンパイラＢＩＤＣ２１０７は、ビジネスインタフェース定義デー
タのためのコンパイラとして活動する。ＸＭＬ構文解析系のためのＤＴＤファイ
ル、ＤＴＤファイルに対応するＪＡＶＡビーンズ、ＤＴＤファイルをＪＡＶＡビ
ーンズへ翻訳するための翻訳ルールは、ＢＩＤデータをコンパイルすることによ
って作られる。ＸＭＬインスタンスは、これらのツールを参照することにより、
ＪＡＶＡインスタンスへ翻訳される。このように、ＢＩＤコンパイラ２１０７は
ＤＴＤ文書２１０８を記憶し、２１０９に対応するＪＡＶＡ文書を作る。ＸＭＬ
文書はプロセッサ２１０２へ送られ、プロセッサ２１０２は、それをＪＡＶＡフ
ォーマットへ翻訳する。ある好適なシステムでは、ＸＭＬフォーマットで受信さ
れた文書型式定義と同じ状態を有するＪＡＶＡ文書が作られる。ＪＡＶＡビーン
ズは文書ルーター２１０３へ送られる。文書ルーター２１０３はＪＡＶＡビーン
ズを受信し、受信したクラスを、例えば上記のイベントリスナアキテクチャのよ
うな登録プログラムを使っている適切な文書サービスへ送る。ルーター２１０３
からＪＡＶＡビーンズのフォームで文書を受信する文書サービス２１０４は、企
業ソルーションスフトウェアへのインタフェースとして活動する。これは、ＸＭ
Ｌイベントへのリスナを入ってくるデータストリームと連結するレジストリサー
ビス２１１０と、入ってくる文書の適切なサービスへの経路指定を管理するサー
ビスマネージャー２１１１とを含んでいる。文書サービスマネージャー２１１１
は、レジストリサービスの管理と、文書の整合性保持を提供する。

【０１６５】文書サービスは、何れかの所有権を主張できるＡＰＩか、或いは、ＣＯＲＢＡ
／ＣＯＭインタフェース又は他のアーキテクチャ等の、より一般的なフォームを
使ってバックエンドシステムと通信する。

【０１６６】図２２は、本発明に従った市場メーカ及び市場参加者構造の、発見に役立つ概
要図である。このモデルは、ｅＣｏにより標準として広く採用されている。従っ
て、本発明による電子商取引市場は、図２２に示されているように論理的に編成
することができる。編成の最上部には、市場メーカーノード２２００が設置され
ている。市場メーカーノードは、マーケット２２０１を設置するリソースを含ん
でいる。そのようなリソースは、市場レジストリサービス等を含んでいる。ビジ
ネス２２０２は、ビジネスインタフェース定義を公表することにより、マーケッ
ト２２０１内に登録される。ビジネスインタフェース定義は、ビジネスが関与す
ることになる商取引に関して、サービス２２０３を定義する。取引２２０４及び
サービス２２０３は、文書２２０５を用いて、入力及び出力を定義し、取引の参
加者の間の商業的関係について概説する。この文書は、各取引の個別項目を伝え
る内容２２０６を有している。市場内の参加者及び市場メーカーが内容を処理す
る方法は、本発明に従って設置されている文書ベースの電子商業ネットワークと
は全く独立している。概括すると、通信ネットワーク上で電子商取引を可能にす
るために示された、頑強で拡張可能な感覚的構造が提供されている。

【０１６７】このように、本発明は、代表的なシステムにおいて、ＸＭＬプロセッサに基づ
いてプラットフォームを提供し、ＸＭＬ文書を、緩く連結されたビジネスシステ
ム間のインタフェースとして用いる。文書は、ビジネス間を移送され、会社のビ
ジネスシステムに入る前に参加者ノードによって処理される。このように、プラ
ットフォームは、各ビジネスシステムが、ビジネス文書及びフォームの一般的な
セットを指定することによって、異なる内部商業プラットフォーム、プロセス及
びセマンティックスを使って作動するビジネスの間の、電子商業アプリケーショ
ンを使用可能とする。

【０１６８】本発明によれば、仮想企業が、ビジネスシステムとサービスを相互接続するこ
とによって作られ、主にビジネスが受け入れる（ＸＭＬエンコードされた）文書
の用語で定義され、・カタログ要求をお送り頂ければ、カタログをお送りします。・購入注文書をお送り頂き、受け取りましたら、インボイスをお送りしますということを作り出す。

【０１６９】本発明の代表的な実施例に関する以上の説明は、わかりやすく説明するために
示したものである。本発明を、開示した形態だけに限定する意図も、制限する意
図もない。当業者には、多くの修正及び変更を加え得ることが自明であろう。本
発明の範囲は、上記特許請求の範囲に述べること、並びにそれと等価なものによ
って定義されるものである。

【図面の簡単な説明】

【図１】ＧＴＷ（大域商取引ウェブ）アーキテクチャの概要である。

【図２】ＧＴＷトポロジーの単純化した線図である。

【図３】本発明によるビジネスインタフェース定義ＢＩＤを含む、電子商取引ネットワ
ークの単純化した線図である。

【図４】ＧＴＷ実装オプションの概念的ブロック線図である。

【図５】レジストリ及びリポジトリアーキテクチャのハイレベルブロック線図である。

【図６】本発明の商業コミュニティスキーマにおけるエンティティと関係のブロック線
図である。

【図７】本発明のコンテキストサービス及びアプリケーション内のツリー構造である。

【図８】本発明によるビジネスインタフェース定義文書の単純化した概要図である。

【図９】本発明のネットワーク内の参加者ノードに対するサーバーの概念的ブロック線
図である。

【図１０】本発明による、参加者ノードにおける受信した文書の処理を示すフローチャー
トである。

【図１１】ＸＭＬに基づくシステムに対する構文解析系及び取引プロセスフロントエンド
のブロック線図である。

【図１２】パース機能のフロー概念的線図である。

【図１３】本発明による、ビジネスインタフェース定義を構築するために使われるサーバ
ーにおけるリソースの単純化した線図である。

【図１４】ビジネスインタフェース定義を構築するために使われる、本発明によるリポジ
トリの単純化した概略図である。

【図１５】本発明による、ビジネスインタフェース定義構築のプロセスを示すフローチャ
ートである。

【図１６】本発明によるリポジトリの発見に役立つ視点を提供する。

【図１７】ビジネスインタフェース定義に基づく本発明のネットワークに市場メーカー機
能を提供するサーバーにおけるリソースの単純化した線図である。

【図１８】受信文書の市場メーカーノード処理に関するフローチャートである。

【図１９】本発明による、市場メーカーノードにおける参加者登録のプロセスを示すフロ
ーチャートである。

【図２０】図１５のプロセスによる、市場メーカーノードにおけるサービス仕様提供のプ
ロセスを示すフローチャートである。

【図２１】本発明による、参加者又は市場メーカーのノードにおけるオペレーションのシ
ーケンスを示す線図である。

【図２２】本発明による、ＢＩＤに基づく商取引ネットワークのエレメントの概念図であ
る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者ディヴィッドソンアンドリューイーアメリカ合衆国カリフォルニア州 95006 ボウルダークリークホプキンスグルチ 1222 (72)発明者ヴェンカトラムシャンカーアメリカ合衆国カリフォルニア州 95035 ミルピタスノースミルピタスブールヴァード 2021−＃318 (72)発明者ミューラートマスアールアメリカ合衆国カリフォルニア州 94588 プリザントンオルソンコート 9140 (72)発明者ローゼンタルカレンアメリカ合衆国カリフォルニア州 94548 ナイトセンパスターレーン 79 (72)発明者シュワーズホフケリーアメリカ合衆国カリフォルニア州 94558 ナパヘイゲンロード 3561 (72)発明者アーメドザヒドアメリカ合衆国カリフォルニア州 95014 クーパティーノパークウッドドライヴ 10145−＃１

Claims

【特許請求の範囲】

【請求項１】１つ又はそれ以上の市場ノードと、複数の参加者ノードとを
含むネットワーク内で、複数の参加者の間の取引をサポートするレジストリにお
いて、前記参加者ノードを利用するトレーダーと、前記市場ノード上で実行されるサービスプロセスと、前記参加者ノードの間の前記取引の少なくとも一部に適用可能な条項及び条件
と、に対するエントリによって、少なくとも１つの参加者ノードへアクセスでき
る機械読み取り可能なレジストリと、入力文書の定義と出力文書の定義を提供する解釈情報を含む、前記ネットワー
ク内の少なくとも１つの参加者ノードによりアクセス可能なメモリ内に記憶され
ている取引プロセスに対するインタフェースの機械読み取り可能な仕様と、を備
えていることを特徴とするレジストリ。
【請求項２】前記エントリは、記憶ユニットと、前記記憶ユニットのセッ
トに関する論理構造とを備えていることを特徴とする請求項１に記載のレジスト
リ。
【請求項３】前記入力及び出力文書の各定義は、記憶ユニットと、前記記
憶ユニットのセットのための論理構造とを備えていることを特徴とする請求項１
に記載のレジストリ。
【請求項４】前記解釈情報は、前記入力及び出力文書の定義内の特定の論
理構造のための事前定義された記憶ユニットのセットを、リスト内の各エレメン
トへマップする、少なくとも１つのデータ構造を含んでいることを特徴とする請
求項３に記載のレジストリ。
【請求項５】少なくとも１つの参加者ノードによりアクセス可能であり、
論理構造のライブラリと論理構造に関する解釈情報とを記憶する、メモリ内のリ
ポジトリを含んでいることを特徴とする請求項３に記載のレジストリ。
【請求項６】前記機械読み取り可能な仕様は、特定の取引の識別子を記憶
するための論理構造を含むインタフェース文書の定義に従う文書と、前記前記特
定の取引に関する入力及び出力文書の定義と定義へのリファレンスとの内の少な
くとも１つと、を含んでいることを特徴とする請求項３に記載のレジストリ。
【請求項７】前記機械読み取り可能な仕様は、前記インタフェースの識別
子を記憶するための、及び、仕様と、前記インタフェースによりサポートされて
いる１つ又はそれ以上の取引のセットの仕様へのリファレンスとの内の少なくと
も１つを記憶するための論理構造を含む、インタフェース文書の定義に従う文書
を含んでいることを特徴とする請求項３に記載のレジストリ。
【請求項８】前記機械読み取り可能な仕様は、特定の取引の仕様のリファ
レンスを含み、前記特定の取引の前記仕様は、前記特定の取引に関する入力及び
出力文書の定義と定義へのリファレンスとの内の少なくとも１つを記憶するため
の論理構造を含む文書を含んでいることを特徴とする請求項７に記載のレジスト
リ。
【請求項９】前記記憶ユニットは、構文解析済みデータを備えていること
を特徴とする請求項３に記載のレジストリ。
【請求項１０】前記入力及び出力文書の内の少なくとも１つの中の前記構
文解析済みデータは、前記入力及び出力文書の内の１つの中のテキストキャラクタをエンコードする
キャラクタデータと、前記入力及び出力文書の内の１つの前記論理構造に従って前記記憶ユニットの
セットを識別するマークアップデータと、を備えていることを特徴とする請求項
９に記載のレジストリ。
【請求項１１】前記記憶ユニットのセットの内の少なくとも１つは、自然
言語ワードを提供する複数のテキストキャラクタをエンコードすることを特徴と
する請求項１０に記載のレジストリ。
【請求項１２】前記入力及び出力文書の内の少なくとも１つの特定の論理
構造によって識別される、前記記憶ユニットのセットの内の少なくとも１つに関
する前記解釈情報は、構文解析済みキャラクタのセットのための各定義をエンコ
ードすることを特徴とする請求項９に記載のレジストリ。
【請求項１３】前記記憶ユニットは、構文解析されていないデータを備え
ていることを特徴とする請求項９に記載のレジストリ。
【請求項１４】複数の取引で利用するため、文書型式の前記ネットワーク
内の少なくとも１つのノードによってアクセス可能なメモリ内に記憶されている
リポジトリを含んでおり、前記入力及び出力文書の内の１つの前記定義が、前記
リポジトリ内の文書型式へのリファレンスを含んでいることを特徴とする請求項
３に記載のレジストリ。
【請求項１５】前記文書型式のリポジトリは、前記ネットワーク内の参加
者のプロセスを識別するための文書型式を含んでいることを特徴とする請求項１
４に記載のレジストリ。
【請求項１６】前記入力及び出力文書の前記定義は、標準的拡張可能マー
クアップ言語ＸＭＬに従う文書型式定義を備えていることを特徴とする請求項３
に記載のレジストリ。
【請求項１７】解釈情報を含んでいる前記機械読み取り可能なデータ構造
は、標準的拡張可能マークアップ言語ＸＭＬに従う文書型式定義に従って編成さ
れた文書を備えていることを特徴とする請求項３に記載のレジストリ。
【請求項１８】トレーダーへの前記エントリは、買い手、サプライヤ及び
サービスプロバイダを含む役割と関連していることを特徴とする請求項１に記載
のレジストリ。
【請求項１９】トレーダーへの前記エントリは、組織又は自然人の識別子
と関連していることを特徴とする請求項１に記載のレジストリ。
【請求項２０】トレーダーへの前記エントリは、組織又は自然人の識別子
と、前記参加者ノードで実行されるアプリケーションとに関連していることを特
徴とする請求項１に記載のレジストリ。
【請求項２１】トレーダーへの前記エントリは、オペレータ、技術上の接
点、及び管理上の接点を含む役割を有する自然人の識別子と関連していることを
特徴とする請求項１に記載のレジストリ。
【請求項２２】サービスプロセスへの前記エントリは、システムサービス
と、ビジネスサービスと、ポータルサービスと、コミュニティサービスとを含む
役割と関連していることを特徴とする請求項１に記載のレジストリ。
【請求項２３】サービスプロセスへの前記エントリは、システムサービス
と、ビジネスサービスと、ポータルサービスと、コミュニティサービスとを含む
役割と関連しており、前記各サービスは、ユニバーサルリソース名により識別さ
れていることを特徴とする請求項１に記載のレジストリ。
【請求項２４】サービスプロセスへの前記エントリは、システムサービス
と、ビジネスサービスと、ポータルサービスと、コミュニティサービスとを含む
役割と関連しており、前記各サービスは、ユニバーサルリソースロケイターによ
り識別されていることを特徴とする請求項１に記載のレジストリ。
【請求項２５】前記レジストリエントリは、前記参加者ノードから受信さ
れ、メモリ内にキャッシュされているデータを備えていることを特徴とする請求
項１に記載のレジストリ。
【請求項２６】前記レジストリエントリは、データが入手可能な１つ又は
それ以上の場所へのメタデータリファレンスを備えていることを特徴とする請求
項１に記載のレジストリ。
【請求項２７】複数の市場ノード及び複数の参加者ノードを含むネットワ
ーク内の複数の参加者の間の取引をサポートするレジストリにおいて、前記市場ノードと、前記参加者ノードを利用するトレーダーと、前記市場ノードで実行されるサービスプロセスと、前記参加者ノードの間の前記取引の少なくとも一部に適用可能な条項及び条件
と、に対するエントリによって、少なくとも１つの参加者ノードへアクセスでき
る機械読み取り可能なマルチ市場レジストリと、入力文書の定義と出力文書の定義を提供する解釈情報を含む、前記ネットワー
ク内の少なくとも１つの参加者ノードによりアクセス可能なメモリ内に記憶され
ている取引プロセスに対するインタフェースの機械読み取り可能な仕様と、を備
えていることを特徴とするレジストリ。
【請求項２８】前記入力及び出力文書の各定義は、記憶ユニットと、前記
記憶ユニットのセットのための論理構造とを備えていることを特徴とする請求項
２７に記載のレジストリ。
【請求項２９】前記解釈情報は、前記入力及び出力文書の定義内の特定の
論理構造のための事前定義された記憶ユニットのセットを、リスト内の各エレメ
ントへマップする、少なくとも１つのデータ構造を含んでいることを特徴とする
請求項２８に記載のレジストリ。
【請求項３０】ネットワーク内の少なくとも１つのノードによりアクセス
可能であり、論理構造のライブラリと論理構造に関する解釈情報とを記憶する、
メモリ内のリポジトリを含んでいることを特徴とする請求項２８に記載のレジス
トリ。
【請求項３１】前記機械読み取り可能な仕様は、特定の取引の識別子を記
憶するための論理構造を含むインタフェース文書の定義に従う文書と、前記特定
の取引に関する入力及び出力文書の定義と定義へのリファレンスとの内の少なく
とも１つと、を含んでいることを特徴とする請求項２８に記載のレジストリ。
【請求項３２】前記機械読み取り可能な仕様は、前記インタフェースの識
別子を記憶するための、及び、仕様と、前記インタフェースによりサポートされ
ている１つ又はそれ以上の取引のセットの仕様へのリファレンスとの内の少なく
とも１つを記憶するための論理構造を含む、インタフェース文書の定義に従う文
書を含んでいることを特徴とする請求項２８に記載のレジストリ。
【請求項３３】前記機械読み取り可能な仕様は、特定の取引の仕様のリフ
ァレンスを含み、前記特定の取引の前記仕様は、前記特定の取引に関する入力及
び出力文書の定義と定義へのリファレンスとの内の少なくとも１つを記憶するた
めの論理構造を含む文書を含んでいることを特徴とする請求項３２に記載のレジ
ストリ。
【請求項３４】前記記憶ユニットは、構文解析済みデータを備えているこ
とを特徴とする請求項２８に記載のレジストリ。
【請求項３５】前記入力及び出力文書の内の少なくとも１つの中の前記構
文解析済みデータは、前記入力及び出力文書の内の１つの中のテキストキャラクタをエンコードする
キャラクタデータと、前記入力及び出力文書の内の１つの前記論理構造に従って前記記憶ユニットの
セットを識別するマークアップデータと、を備えていることを特徴とする請求項
３４に記載のレジストリ。
【請求項３６】前記記憶ユニットは、構文解析されていないデータを備え
ていることを特徴とする請求項３２に記載のレジストリ。
【請求項３７】複数の取引で利用するため、文書型式の前記ネットワーク
内の少なくとも１つのノードによってアクセス可能なメモリ内に記憶されている
リポジトリを含んでおり、前記入力及び出力文書の内の１つの前記定義が、前記
リポジトリ内の文書型式へのリファレンスを含んでいることを特徴とする請求項
２８に記載のレジストリ。
【請求項３８】前記文書型式のリポジトリは、前記ネットワーク内の参加
者のプロセスを識別するための文書型式を含んでいることを特徴とする請求項３
７に記載のレジストリ。
【請求項３９】前記入力及び出力文書の前記定義は、標準的拡張可能マー
クアップ言語ＸＭＬに従う文書型式定義を備えていることを特徴とする請求項２
８に記載のレジストリ。
【請求項４０】解釈情報を含んでいる前記機械読み取り可能なデータ構造
は、標準的拡張可能マークアップ言語ＸＭＬに従う文書型式定義に従って編成さ
れた文書を備えていることを特徴とする請求項２８に記載のレジストリ。
【請求項４１】トレーダーへの前記エントリは、買い手、サプライヤ及び
サービスプロバイダを含む役割と関連していることを特徴とする請求項２７に記
載のレジストリ。
【請求項４２】トレーダーへの前記エントリは、組織又は自然人の識別子
と関連していることを特徴とする請求項２７に記載のレジストリ。
【請求項４３】トレーダーへの前記エントリは、オペレータ、技術上の接
点、及び管理上の接点を含む役割を有する自然人の識別子と関連していることを
特徴とする請求項２７に記載のレジストリ。
【請求項４４】サービスプロセスへの前記エントリは、システムサービス
と、ビジネスサービスと、ポータルサービスと、コミュニティサービスとを含む
役割と関連していることを特徴とする請求項２７に記載のレジストリ。
【請求項４５】サービスプロセスへの前記エントリは、システムサービス
と、ビジネスサービスと、ポータルサービスと、コミュニティサービスとを含む
役割と関連しており、前記各サービスは、ユニバーサルリソース名により識別さ
れていることを特徴とする請求項２７に記載のレジストリ。
【請求項４６】サービスプロセスへの前記エントリは、システムサービス
と、ビジネスサービスと、ポータルサービスと、コミュニティサービスとを含む
役割と関連しており、前記各サービスは、ユニバーサルリソースロケイターによ
り識別されていることを特徴とする請求項２７に記載のレジストリ。
【請求項４７】前記マルチ市場レジストリエントリは、前記参加者ノード
から受信され、メモリ内にキャッシュされているデータを備えていることを特徴
とする請求項２７に記載のレジストリ。
【請求項４８】前記マルチ市場レジストリエントリは、データが入手可能
な１つ又はそれ以上の場所へのメタデータリファレンスを備えていることを特徴
とする請求項２７に記載のレジストリ。
【請求項４９】前記マルチ市場レジストリエントリは、前記市場ノードか
ら複製されたデータを備えていることを特徴とする請求項２７に記載のレジスト
リ。
【請求項５０】取引に含まれているプロセスを実行するルートノード、複
数の市場ノード及び複数の参加者ノードを含むネットワーク内の参加者ノードの
間の前記取引を実行するための方法において、取引のために、入力文書の定義と出力文書の定義を含むインタフェースの機械
読み取り可能な仕様を、市場ノードへ提出する段階と、通信ネットワークを通して、文書を備えたデータを受信する段階と、入力文書を識別するため、前記仕様に従って前記文書を構文解析する段階と、前記入力文書の少なくとも一部を、機械読み取り可能なフォーマットで、出力
を生成する取引プロセスへ提供する段階と、前記仕様に基づいて、出力文書の前記定義に従った出力を備えている出力文書
を形成する段階と、前記出力文書を前記通信ネットワーク上で送信する段階とを備えていることを
特徴とする方法。
【請求項５１】前記入力及び出力文書の前記定義は、記憶ユニットのセッ
トと、前記記憶ユニットのセットのための論理構造とに関するそれぞれの記述を
備えていることを特徴とする請求項５０に記載の方法。
【請求項５２】前記文書は、追加参加者ノードから参加者ノードに直接に
受信されることを特徴とする請求項５０に記載の方法。
【請求項５３】前記参加者ノードと前記追加参加者ノードとの間の前記文
書の通信を市場ノードへ報告する段階を更に含んでいることを特徴とする請求項
５２に記載の方法。
【請求項５４】前記文書は拘束力のある義務を作り、前記拘束力のある義
務を前記市場ノードへ報告する段階を更に備えていることを特徴とする請求項５
３に記載の方法。
【請求項５５】前記文書は拘束力のある義務を作り、記憶されている条項
及び条件を前記拘束力のある義務へ適用する段階を更に備えていることを特徴と
する請求項５３に記載の方法。
【請求項５６】ルートノードと、複数の市場ノードと、複数の参加者ノー
ドとを含むネットワーク内の複数の参加者の間の取引を実行するための方法にお
いて、場所を含むトレーダーに関するレジストリ情報を得るために、ルートノード又
は複数の市場ノードの内の少なくとも１つにアクセスする段階と、前記ネットワークを通して前記場所へと、取引のためのインタフェースの機械
読み取り可能な仕様に従った文書を備えているデータを前記トレーダーへ送る段
階であって、前記仕様は入力文書の定義と出力文書の定義を含んでおり、前記入
力及び出力文書の定義は、記憶ユニットのセットと、前記記憶ユニットのセット
に関する論理構造のそれぞれの記述を含んでいる、送る段階と、通信ネットワークを通して、追加文書を備えているデータを受信する段階と、前記追加文書を前記仕様に従って構文解析する段階と、前記構文解析済みデータの少なくとも一部を、機械読み取り可能なフォーマッ
トで、出力を生成する取引プロセスへ提供する段階と、前記仕様に基づいて、出力文書の前記定義に従った出力を含んでいる出力文書
を形成する段階と、前記出力文書を前記通信ネットワーク上で送信する段階と、を備えていること
を特徴とする方法。
【請求項５７】前記取引のために、前記ネットワーク内の別のノードに備
えられている相補的インタフェースの仕様にアクセスする段階であって、前記ア
クセスされた仕様は、前記相補的インタフェースに関する入力文書の定義と、前
記相補的インタフェースに関する出力文書の定義とを含んでいる、アクセスする
段階と、前記相補的インタフェースの前記出力文書の前記定義の少なくとも一部を、前
記記憶されている仕様内の前記インタフェースの前記入力文書の前記定義内に含
めることによって、前記インタフェースの前記記憶されている仕様を確立する段
階と、を更に含んでいることを特徴とする請求項５６に記載の方法。
【請求項５８】前記相補的インタフェースを前記ネットワーク内で見つけ
出す段階を含むことを特徴とする請求項５７に記載の方法。
【請求項５９】前記記憶されている仕様を確立する段階は、リポジトリか
らの機械読み取り可能な仕様のエレメントにアクセスする段階を含んでおり、前
記リポジトリは、論理構造のライブラリと、論理構造に関する概略のマップと、
インタフェースの記述を構築するために用いられる論理構造を備えた文書の定義
とを記憶していることを特徴とする請求項５７に記載の方法。
【請求項６０】前記相補的インタフェースの前記入力文書の前記定義の少
なくとも一部を、前記記憶されている仕様内の前記インタフェースの前記出力文
書の前記定義内に含めることによって、前記インタフェースの前記記憶されてい
る仕様を確立する段階を更に含んでいることを特徴とする請求項５７に記載の方
法。
【請求項６１】前記通信ネットワークを通して前記ネットワーク内の別の
ノードへ、前記仕様へのアクセスを提供する段階を更に含んでいることを特徴と
する請求項５６に記載の方法。
【請求項６２】前記インタフェースの前記仕様を前記ネットワーク内のも
う１つのノードへ送り、そこで、前記仕様へのアクセスが前記ネットワーク内の
他のノードに提供される段階を更に含んでいることを特徴とする請求項５６に記
載の方法。
【請求項６３】前記機械読み取り可能な仕様は、特定の取引の識別子を記
憶するための論理構造を含むインタフェース文書の定義に従う文書と、特定の取
引に関する入力及び出力文書の定義と定義へのリファレンスの内の少なくとも１
つと、を含んでいることを特徴とする請求項５６に記載の方法。
【請求項６４】前記機械読み取り可能な仕様は、前記インタフェースの識
別子を記憶するための、そして、前記インタフェースによりサポートされている
１つ又はそれ以上の取引のセットの仕様と仕様へのリファレンスとの内の少なく
とも１つを記憶するための論理構造を含むインタフェース文書の定義に従う文書
を含んでいることを特徴とする請求項５６に記載の方法。
【請求項６５】前記機械読み取り可能な仕様は、特定の取引の仕様へのリ
ファレンスを含んでおり、前記特定の取引の前記仕様は、前記特定の取引に関す
る入力及び出力文書の定義と定義へのリファレンスとの内の少なくとも１つを記
憶するための論理構造を含む文書を含んでいることを特徴とする請求項６４に記
載の方法。
【請求項６６】前記記憶ユニットは、構文解析済みデータを備えているこ
とを特徴とする請求項５７に記載の方法。
【請求項６７】前記入力及び出力文書の内の少なくとも１つの中の前記構
文解析済みデータは、前記入力及び出力文書の内の前記１つの中のテキストキャラクタをエンコード
するキャラクタデータと、前記入力及び出力文書の内の前記１つの前記論理構造に従って記憶ユニットの
セットを識別するマークアップデータと、を備えていることを特徴とする請求項
６６に記載の方法。
【請求項６８】前記記憶ユニットのセットの内の少なくとも１つは、自然
言語ワードを提供する複数のテキストキャラクタをエンコードすることを特徴と
する請求項６７に記載の方法。
【請求項６９】前記仕様は、前記入力及び出力文書の内の少なくとも１つ
の前記論理構造によって識別される前記記憶ユニットのセットの内の少なくとも
１つに関する解釈情報を含んでおり、構文解析済みキャラクタのセット用の各定
義をエンコードすることを特徴とする請求項６６に記載の方法。
【請求項７０】前記記憶ユニットは、構文解析されていないデータを備え
ていることを特徴とする請求項６６に記載の方法。
【請求項７１】前記取引プロセスは様々な取引処理アーキテクチャを有し
ており、前記入力文書の少なくとも一部を、前記取引プロセスの前記様々な取引
処理アーキテクチャに従って読み取り可能なフォーマットに翻訳する段階を含ん
でいることを特徴とする請求項５６に記載の方法。
【請求項７２】前記翻訳する段階は、前記取引プロセスの前記様々な取引
処理アーキテクチャに従った変数と方法とを含むプログラミングオブジェクトを
作成する段階を含んでいることを特徴とする請求項７１に記載の方法。
【請求項７３】前記取引プロセスの前記様々な取引処理アーキテクチャは
インタフェース記述言語に従うプロセスを含んでいることを特徴とする請求項７
１に記載の方法。
【請求項７４】前記入力及び出力文書の前記定義は、標準的拡張可能マー
クアップ言語ＸＭＬに従う文書型式定義を備えていることを特徴とする請求項５
６に記載の方法。