(57)【特許請求の範囲】
【請求項１】
通信ネットワークによってアクセス可能な少なくとも２つの要求整合サーバを備える要求整合システムにおいて使用する要求整合サーバであって、
前記各要求整合サーバは、
前記通信ネットワークによってユーザ要求定義と応答コンタクトの識別子とを含むユーザ要求メッセージを受信するための入力手段と、
通信ネットワークによってアクセス可能であり、且つ受信したユーザ要求定義を他の要求整合サーバを介して選択的に１以上の宛先へ送信すること決定して送信するルート設定手段と、を備え、
前記ルート設定手段は、
前記ルート設定手段を制御するための少なくとも１のルート設定規則であって、ルート設定される要求定義と１以上の対応する宛先の識別子とを含むルート設定規則を記憶するメモリと、
受信したユーザ要求メッセージによって伝えられたユーザ要求定義を、記憶されたルート設定規則にて規定されるようにルート設定される要求定義と比較し、前記比較結果に依存して、前記ユーザ要求定義の送信に関する１以上の対応する宛先を識別する比較手段と、
前記通信ネットワークによって、前記比較手段によって識別された宛先へユーザ要求定義を伝えるメッセージを送信するための送信手段とを備える、
要求整合サーバ。
【請求項２】
前記ルート設定手段は、前記ルート設定規則を伝えるメッセージを受け取ると、前記メモリに前記ルート設定規則を記憶するように構成された登録手段をさらに含む請求項１に記載の要求整合サーバ。
【請求項３】
前記登録手段が、ルート設定規則を含むメッセージを生成して、生成されたメッセージを他の要求整合サーバへ送るようにさらに構成された請求項２に記載の要求整合サーバ。
【請求項４】
ユーザ要求定義を該ルート設定手段によって送信する前に、受取ったユーザ要求メッセージから所定のタイプの情報を抽出し、抽出された情報を記憶する情報抽出手段と、
前記抽出された情報を供給する要求を伝えるメッセージを受け取る際に、抽出された情報要求メッセージの送信者に前記抽出された情報を含むメッセージを送る応答手段と、を含む請求項１ないし請求項３の何れか１項に記載の要求整合サーバ。
【請求項５】
前記所定のタイプの情報は受取られたユーザ要求メッセージによって伝えられるユーザ要求定義の応答コンタクトに関する識別子である請求項４に記載の要求整合サーバ。
【請求項６】
各要求の送信者に関して抽出された情報を供給する料金を徴収するための請求手段を含む請求項４または請求項５に記載の要求整合サーバ。
【請求項７】
複数の要求整合サーバを含む要求整合システムであって、
各要求整合サーバはシステムの他の要求整合サーバと通信できるように通信ネットワークへのインタフェースを含み、
各要求整合サーバは、受取ったユーザ要求メッセージによって伝えられたユーザ要求定義を、前記ユーザ要求定義に記載された要求のカテゴリーに従って選択された１以上の所定の宛先へ他の要求整合サーバを介して選択的に送信するルート設定手段を含み、
該カテゴリーはカテゴリーの所定の組の１つである、要求整合システム。
【請求項８】
該システムの各要求整合サーバが、請求項１に記載の要求整合サーバである請求項７に記載の要求整合システム。
【請求項９】
該システムの少なくとも１の要求整合サーバへアクセスするように構成された少なくとも１のユーザアクセスサーバを含み、前記少なくとも１のユーザアクセスサーバはユーザ要求定義を受領するためのユーザインタフェースと、受取ったユーザ要求定義と応答コンタクトの識別子とを含むユーザ要求メッセージを生成し、該生成されたメッセージを前記少なくとも１の要求整合サーバへ送信する手段とを有する、請求項７または請求項８に記載の要求整合システム。
【請求項１０】
ユーザが前記システムの１以上の要求整合サーバから要求の所定のカテゴリーに関するユーザ要求の定義を伝えるユーザ要求メッセージを受領できるようにユーザインターフェースを提供する少なくとも１のサーバを含む請求項７ないし請求項９のいずれか１項に記載の要求整合システム。
【請求項１１】
各前記要求定義が所定の要求表示方式にしたがって規定される請求項７ないし請求項１０のいずれか１項に記載の要求整合システム。
【請求項１２】
通信ネットワークへのアクセスをもつように構成された少なくとも２つの要求整合サーバを有する要求整合システムであって、
前記各要求整合サーバは、
前記通信ネットワークによってユーザ要求定義と応答コンタクトの識別子とを含むユーザ要求メッセージを受信するための入力手段と、
前記通信ネットワークによってアクセス可能であり、且つ受信したユーザ要求定義を他の要求整合サーバを介して選択的に１以上の宛先へ送信することを決定して、送信するルート設定手段と、を含み、
前記ルート設定手段は、
前記ルート設定手段を制御するための少なくとも１のルート設定規則であって、ルート設定される要求定義と１以上の対応する宛先の識別子とを含むルート設定規則を記憶するためのメモリと、
受信したユーザ要求メッセージによって伝えられたユーザ要求定義を、記憶されたルート設定規則にて規定されるようにルート設定される要求定義と比較し、前記比較結果に依存して、前記ユーザ要求定義の送信に関する１以上の対応する宛先を識別する比較手段と、
前記通信ネットワークによって、前記比較手段によって識別された各宛先へユーザ要求定義を伝えるメッセージを送信するための送信手段とを備える、
要求整合システム。
【請求項１３】
複数の要求整合サーバを備える要求整合システムと共に使用するための電子購買装置であって、
要求整合システムの各要求整合サーバは、要求整合システムの他の要求整合サーバと通信できるように通信ネットワークへのインタフェースを含み、
各要求整合サーバは、受取ったユーザ要求メッセージによって伝えられたユーザ要求定義を、前記ユーザ要求定義に記載された要求のカテゴリーに従って選択された１以上の所定の宛先へ他の要求整合サーバを介して選択的に送信するルート設定手段を含み、
前記カテゴリーは所定のカテゴリーの組の１であり、
該装置は、
前記要求整合システムの少なくとも１の要求整合サーバとの通信を可能にする通信ネットワークインタフェースと、
ユーザ要求定義を受領するためのユーザインタフェースと、
受取ったユーザ要求定義と応答コンタクトの識別子とを含むユーザ要求メッセージを生成し、該生成されたユーザ要求メッセージを前記要求整合システムの要求整合サーバへ送信するメッセージ生成器と、
を備える電子購買装置。
【請求項１４】
請求項１ないし請求項６のいずれか１項に記載の少なくとも１の要求整合サーバを含む電子取引システム。
【請求項１５】
複数の要求整合サーバを含む電子取引システムであって、
各要求整合サーバはシステムの他の要求整合サーバと通信できるように通信ネットワークへのインタフェースを含み、
各要求整合サーバは、受取ったユーザ要求メッセージによって伝えられたユーザ要求定義を、前記ユーザ要求定義に記載された要求のカテゴリーに従って選択された１以上の所定の宛先へ他の要求整合サーバを介して選択的に送信するルート設定手段を含み、
前記カテゴリーは所定のカテゴリーの組の１である、電子取引システム。
【請求項１６】
ユーザ要求定義をユーザから潜在的な供給者へルート設定する方法であって、
該方法は、
前記ユーザ要求定義を伝える要求メッセージを要求整合サーバで受け取る段階と、
前記要求整合サーバを動作させて、
前記受け取った要求メッセージによって伝えられる前記要求定義と、少なくとも１のルート設定規則の組の各規則に規定された供給者引渡可能物の定義とを比較し、ここで、前記ルート設定規則は供給者引渡可能物の定義及び１以上の対応する送信先の識別子とを含み、
前記比較結果に依存して、前記ユーザ要求定義に対応する１以上の送信先を識別し、
前記ユーザ要求定義を含むメッセージを他の要求整合サーバに送信する、
方法。
【請求項１７】
前記受取った要求メッセージから１以上の所定のタイプの情報を抽出し、抽出された情報を記憶する段階を含む請求項１６に記載の方法。
【請求項１８】
ユーザ要求と供給者引渡可能物の各前記定義が、同じ所定の表示方式にしたがって規定される請求項１６または請求項１７に記載の方法。
【請求項１９】
該システムの要求整合サーバは、受領したユーザ要求メッセージによって伝えられた要求の特定のカテゴリーを記述するユーザ要求定義を、該システムの所定の各要求整合サーバへ送信するように構成された請求項７に記載の要求整合システム。
【請求項２０】
該システムの要求整合サーバは、受領したユーザ要求メッセージによって伝えられた要求の特定のカテゴリーを記述するユーザ要求定義を、該システムの所定の各要求整合サーバへ送信するように構成された請求項１５に記載の電子取引システム。
【発明の詳細な説明】
【０００１】
発明の属する技術分野
本発明は、エレクトロニックコマース（electronic commerce）に関し、とくに潜在的な供給者へ向けた送信元の要求を整合させる特定の応用に関する。
【０００２】
従来の技術
インターネットは、世界的な電話およびデータネットワーク上に構築されたマルチメディアコンピュータの通信ネットワークである。１０万を越える種々のタイプのサーバがインターネットに接続されて、公衆にとってアクセス可能な分散形データメモリを用意している。“ハイパーテキスト転送プロトコル”（ＨＴＴＰ）と呼ばれるインターネット通信プロトコルを使用してアクセス可能なデータとして情報のファイルを保持しているサーバは、“ＨＴＴＰサーバ”として知られている。ＨＴＴＰサーバ上に記憶され、ＨＴＴＰによってアクセス可能なデータファイルは“ウエブページ”として知られており、合せて“ワールドワイドウエブ”または単に“ウエブ”を形成している。ウエブページは、ハイパーテキストマークアップ言語（ＨＴＭＬ）と呼ばれる特定のＷＥＢ言語を使用して書込まれ、適切にウエブ上で他のページへリンクを生成し、ウエブ上で情報を通してナビゲートする手段を用意する。インターネットに接続されたコンピュータをもち、このような情報にアクセスすることに関心のある人は、ウエブ上に保持され、公衆のアクセスを意図した情報にアクセスできる。一定の情報へのアクセスは、例えば閉じたユーザグループによって制限することができる。ＨＴＴＰユニフォームリソースロケータ（ＵＲＬ）をＷＥＢ標準（規格）として採用して、一貫した国際的な命名規則を用意して、例えばドキュメント、プログラム、サウンド、およびビデオクリップを含むウエブ資源の位置を独特に識別する。ＨＴＴＰは、ＵＲＬの識別されたファイル（ウエブページ）を位置付けて、インターネットに接続されたユーザ装置において再生成するために転送することを可能とする。基礎となるトランスポートプロトコルは、主としてＴＣＰ／ＩＰであり、これを使って、インターネットユーザと、利用できるインターネットへのアクセス点との間に、一般的にインターネットサービスプロバイダを介してネットワーク接続を設定することができる。ローカルのインターネットサービスプロバイダに登録して、インターネット通信インフラストラクチャへのアクセスを得て、独特のインターネットのネットワークアドレスを割り当てることができる。インターネットサービスプロバイダはサーバキャパシティを賃借して、登録したユーザがインターネット上に独特のＵＲＬによって識別可能なユーザ自身の“サイト”を設定して、ユーザ自身のウエブページを記憶し、他のインターネットユーザが使用できるようにすることもできる。商業用のインターネットユーザはこの目的のために自分自身のサーバを用意して維持してもよい。
【０００３】
インターネットユーザは、インターネットにリンクされたパーソナルコンピュータ（ＰＣ）またはワークステーション上で実行される所有権を主張できるウエッブブラウザ製品を使用してウエッブ上で情報にアクセスすることができる。ウエッブブラウザは、標準のインターネットプロトコルを使用してウエブ資源と通信し、選定されたウエブページをダウンロードし、ウエブページの作成者（オーサ）によって書き入れられた（マークアップされた）時間に挿入された埋め込まれたＨＴＭＬ命令を変換して、適切であれば、そのページをグラフィック表示する。インターネット上で転送されるマルチメディアファイルを再生するのに、ブラウザを使用することができる。
【０００４】
製品供給者が、インターネット上に自分自身の“サイト”を設定して、“ストアフロント（storefront、店先）”のユーザインターフェイスを用意して、インターネットへのアクセスをもつ予測される購入者が、供給者の製品の範囲を検索できることが知られている。いくつかの場合には、購入者は、供給者のユーザインターフェイスにおいて与えられたテンプレートを使用して製品の要求を特定でき、応答して、製品の選択は供給者の製品の範囲から、とくにユーザの述べた要求に整合を報告することができる。しかしながらこのような場合に与えられたフレキシビリティは要求定義（仕様）においてとくに制限される。購入者は、各サイトが他の製品供給者のインターネットサイトを個々に識別および訪問し、所定の要求定義を満たす代わりの製品を調べなければならない。
【０００５】
第３の当事者のインターネットユーザは、管理されたフロントエンドを所定のタイプの製品または情報の供給者のコミュニティへ供給することも知られている。予測される購入者は、例えばユーザインターフェイスによって与えられるテンプレートを使用して第３の当事者の管理されたフロントエンドに向けて製品要求を特定し、製品を整合させるために各コミュニティの製品の供給者のデータベースのサーチを自動的にトリガすることができる。次に購入者は、同じ管理されるフロントエンドを使用して選定された供給者から製品を注文することができる。例えば、インターネット上で現在使用可能な管理されるフロントエンドは、例えば、書籍に対してはhttp://amazon.com/で、“Auto-By-Tel”によって供給される自動車に対してはhttp://www.auto-by-tel.com/.である。しかしながら管理されたフロントエンドは特定の製品タイプ（形式）のみに関係し、制限された範囲の供給者をカバーする傾向がある。しばしば管理されるフロントエンドは、相補的な製品の範囲(complementary product range)をもっている範囲の供給者へのアクセスを提供して、外で使用可能なものよりも、これらの供給者間の価格の競合を緩和することができることになる。より競合して価格設定される製品を見付けるには、購入者は別の製品の供給者のサイトを個々に位置決めして、訪問することが必要である。
【０００６】
関係する製品情報のローカルなデータベースにインターロゲートして、情報の特定のアイテムの位置を報告することも知られている。サーチアルゴリズムがより効果的になり、ローカルデータベースがより大きくなると、得られる結果はより正確になる。しかしながら製品情報をサーチする際に、全てのユーザの必要を満たすユーザインターフェイスを用意することは困難であり、これは現在使用可能な無数のサーチエンジンによって強調されている。サーチの結果から多数の期待される供給者を発見しても、ユーザは依然として個々に各サイトを訪問しなければならない。より知られている供給者は、このようなサーチにおいて小規模または中規模の企業（ＳＭＥ）よりも目立ち易く、ユーザは有名な名前に惹きつけられ易い。
【０００７】
発明が解決しようとする課題
本発明にしたがって要求整合システムにおいて使用する要求整合ブローカであって：
メッセージの送受信用の通信ネットワークインターフェイスと；
要求定義および関係するネットワークの送信先の識別子を含む少なくとも1つのメッセージルート設定規則を記憶するようにされている記憶手段と；
ネットワークインターフェイスにおいて受け取られるメッセージ内に含まれる要求定義と、記憶されたメッセージルート設定規則内に含まれる要求定義とを比較する比較手段と；
前記比較に依存して、記憶されたメッセージルート設定規則によって識別される関係するネットワーク識別子へ向けて受け取ったメッセージを送る送信手段とを含む要求整合ブローカを提供する。
【０００８】
本発明は、好ましくはシステムへの標準のインターフェイスによって、ユーザが要求を提出できる先となる１以上の要求と整合をとるブローカをもつ要求整合システムを提供することができ、これらの要求はブローカのシステムを通ってルート設定され、このような要求を受け取ることについてシステムに関心を“登録”しているどの供給者へも伝達される。このやり方では、どの“登録した”供給者もユーザの要求に応答する機会をもっており、ユーザが幅広い範囲の関心全般について最良の情報源または商業取引き（トランザクション）における最良の取り引きを見付ける可能性が高くなる。
【０００９】
本発明の要求整合ブローカのシステムは“分散形のコンピュータ処理構成”において動作し、したがって多数のブローカがネットワーク全体に用意されていて、各ブローカは、特殊化されるか、または共同して異なるタイプのユーザ要求を整合したり、ルート設定する。しかしながら本発明では、単一のブローカを使用して、潜在的な供給者に対する全てのユーザ要求を整合およびルート設定するように構成されていてもよい。
【００１０】
要求整合システムのユーザは、通信ネットワーク上で、メッセージ内に含められて伝えられる要求定義をシステムへ提出することができる。要求定義は標準のフォーマットで表わすことができ、合意された要求分類方式から選定される要求定義を含むことができる。供給者は、システム内の特定のブローカに記憶されたルート設定規則によって要求メッセージを受け取ることについての関心を登録することができる。供給者は、同じ合意されたフォーマットおよび分類方式にしたがって表現された要求定義によってその者の特定の関心を規定し、要求定義が通信システム内の供給者のネットワークアドレスを含んでいるルート設定規則の形で、ブローカに記憶されるようにすることができる。ブローカがユーザから要求メッセージを受け取るとき、ブローカは、類似の要求定義を含んでいるルート設定規則をもつ何れかの供給者へユーザの要求メッセージを送る。
【００１１】
ブローカは、メッセージルート設定規則を伝えるメッセージを受け取ると、前記メッセージルート設定規則を記憶するようにされた登録手段を含むことが好ましい。このやり方では、供給者はシステム内の特定のブローカにメッセージを送り、その者の特定の関心を規定するルート設定規則を記憶してもよい。
【００１２】
ブローカの登録手段はさらに、メッセージルート設定規則を含むメッセージを生成し、生成されたメッセージを別の要求整合ブローカへ送るようにされていてもよい。このやり方では、ブローカ、それら自体はメッセージを送って、システム内の他のブローカに関するルート設定規則を記憶して、特定のタイプの要求メッセージの送受信のためにシステム内のブローカの専門化を創成することができる。このやり方では、種々の供給者のドメインは管理可能な部分に分割されることが好都合である。ブローカが、特別にではあるが、しかし好ましくは幅広いカテゴリの要求タイプを特定するシステムでは、供給者が記憶する必要があるルート設定規則数を最小にすることができる。言い換えると、特別の関心をもつ供給者は、システム内の1つブローカのみに関するルート設定規則を知識として記憶する必要があり、このブローカは最終的に全ての関連する要求メッセージをユーザから受け取る。
【００１３】
ブローカは：
受け取ったメッセージを送信手段によって送信する前に、要求定義を伝える受け取ったメッセージから所定のタイプの情報を抽出し、抽出された情報を記憶する情報抽出手段と；
前記抽出された情報を供給する要求を伝えるメッセージを受け取る際に、要求メッセージの送信者に前記抽出された情報を含むメッセージを送る応答手段とを含むことが好ましい。
【００１４】
システムのユーザからメッセージ内で伝えられるある種の情報は、供給者に対する値であると考えられる。例えば、ユーザの識別子および応答に対する戻りアドレスは情報アイテムであってもよく、供給者はユーザの要求メッセージに応答できるように、この情報アイテムの料金をシステムプロバイダへ支払うことを望む。受け取ったメッセージから一定の情報を抽出し、受け取ったメッセージの残りを供給者へ送る前にその情報を記憶することができるようにするブローカの能力は、多数の可能な支払いシステムおよびビジネスモデルについてのエネーブラ(enabler)である。
【００１５】
出願人の未決欧州特許出願第97310097.7号（連合王国同時出願第9726484.0号）は、データ通信システムにおいてユーザに内容を提供する方法および内容に対して課金する方法に関係する。このような方法は、本発明の要求整合システム内でのブローカによる情報の供給および課金に応用できる。ここでは上述で参照した等価の出願の主題を参考文献として取り上げる。
【００１６】
ブローカは、抽出された情報を供給する要求メッセージを受け取った際に、前記抽出された情報の供給を考慮して、料金の支払いにおいて前記要求メッセージの送信者に対する課金を増加するようにされている請求書発行手段を含んでもよい。請求書発行手段は、特定の供給者に対する口座を保持して、合意した間隔で照合した請求書を供給者へ提出できるようにするか、または抽出された情報の供給を要求している供給者からの各メッセージが、既知の電子支払いシステムによる電子支払いを伴っていてもよい。
【００１７】
別の態様では、通信ネットワークへのアクセスをもつように構成された少なくとも1つの要求整合ブローカをもつ要求整合システムであって、前記少なくとも１つの要求整合ブローカが：
メッセージの受信および送信用の通信ネットワークに対するインターフェイスと；
要求定義および１以上の関係するネットワークの送信先の識別子とを含む少なくとも1つのメッセージルート設定規則を記憶するようにされたメモリ手段と；
ネットワークインターフェイスにおいて受け取られたメッセージ内に含まれる要求定義を、記憶されたメッセージルート設定規則内に含まれる要求定義と比較する比較手段と；
前記比較に依存して、記憶されたメッセージルート設定規則によって識別される関係するネットワークの送信先へ受け取ったメッセージを送る送信手段とを含む要求整合システムを提供する。
要求整合システムは、各々が前記通信ネットワークへのインターフェイスをもつ第１および第２のアクセス供給手段を含み、前記第１のアクセス供給手段は、第１のユーザが前記通信ネットワーク上で前記少なくとも1つの要求整合ブローカへ所定の表示方式にしたがって規定された要求定義を含むメッセージを送ることができるようにする手段を含み、前記第２のアクセス供給手段は、第２のユーザが、要求整合ブローカによって送られるメッセージであって、前記第１のユーザによって送られた要求定義を含むメッセージを受け取ることができるようにする手段を含む第１および第２のアクセス供給手段を含むことが好ましい。
【００１８】
別の態様では、要求定義を伝えるメッセージをルート設定する方法であって：
要求定義を伝えるメッセージを受け取る段階と；
前記受け取ったメッセージによって伝えられる要求定義と、メッセージルート設定規則のメモリ内に記憶された要求定義とを比較する段階であって、前記メッセージルート設定規則の各々が要求定義および１以上の関係する送信先の識別子とを含んでいる段階と；
前記比較結果に依存して、前記受取ったメッセージによって伝えられる要求定義と関係付けられている送信先を識別する段階と；
前記受取ったメッセージによって伝えられる要求定義を含むメッセージを前記識別された送信先へ送る段階とを含む方法を提供する。
【００１９】
さらに別の態様では、品物またはサービスに対する購入者の要求を、電子支払いシステムにおける前記品物またはサービスの潜在的な供給者と整合させる方法であって：
（ｉ）各ルート設定規則が、所定の供給者に対して、前記供給者および前記供給者のアドレスから得られ、かつ各々が所定の表示方式にしたがって規定される品物またはサービスの定義を含むルート設定規則を記憶する段階と：
（ii）同じ前記所定の表示方式を使用して前記購入者によって要求される品物またはサービスの使用を規定する段階と；
（iii）段階（ii）からの購入者の明細と、前記ルート設定規則内に含まれる供給者の明細とを比較する段階と；
(iv)前記比較に依存して供給者のアドレスを識別する段階と；
(ｖ)段階（iv）において識別された供給者のアドレスへ前記購入者の明細を送る段階とを含む方法を提供する。
【００２０】
ここで本発明を添付の図面を参照してさらに詳しく例示的に記載することにする。
【００２１】
発明の実施の形態
最初に、本発明の実施形態にしたがう要求整合システムの機能的構成要素を、各構成要素を含めて記述する。次に、本発明の実施形態による典型的な動作構成でこの要求整合システムが電子トレーディング（売買）システム応用という情況（コンテキスト）において一般的にどのように使用されるかの概要を記述する。システムの主要な構成要素の動作をより詳しく記述する前に、好ましい要求分類方式、最上レベルのメッセージプロトコル、およびＳＯＲ定義とＳＯＲメッセージ伝送に対する応用を記述する。次に好ましい要求分類方式および最上レベルのメッセージプロトコルのコンテキストにおいてより詳しい記述を始める。
【００２２】
要求整合システムの概要
図１を参照すると、本発明の実施形態の一般的な応用にしたがって使用する要求整合システムの構成要素を概観して示すダイヤグラムが与えられている。図１は、ユーザ装置との論理的な通信経路を示し、本発明の応用に含まれる３つの主要なタイプの装置を示している。最も重要なこととして最上レベルでは、本発明の‘中核（コア）’の機能を実現するのは、１以上の“要求ブローカ”120をもつネットワークであって、この“要求ブローカ”120は、例えば電子データメッセージ内でテキストとして表わされる要求を、ブローカ120によって実行される所定のルート設定条件にしたがって、システムへエントリする地点から、システムから配信される1以上の地点へルート設定するようにされている。システムへエントリする地点およびシステムから配信される地点は、それぞれ“サービスアクセスプロバイダ（ＳＡＰ）”110および115から与えられる。システムへの全てのユーザアクセスは、ＳＡＰから与えられる。ＳＡＰには２つのタイプがあり：一方のタイプは要求メッセージを生成して、送り出すユーザへのアクセスを用意し、他方のタイプは要求メッセージを受け取ることを意図しているユーザへのアクセスを用意する。前者は“購入者（Buyer）”ＳＡＰ−すなわちＢＳＡＰ110と呼ばれ、後者は“供給者（Supplier）”ＳＡＰ−すなわちＳＳＡＰ115と呼ばれる。この“購入者−供給者”という用語は、エレクトロニックコマースアプリケーション、とくに電子トレーディングシステムのコンテキスト、すなわち本発明の実施形態の典型的なアプリケーションで使用されている。このようなコンテキストでは、特定の記述の製品またはサービスを得ることを目的とする購入者（100）は、求めていた製品またはサービスを特定する“要求ステートメント”（Statement of Requirements, ＳＯＲ）を生成して、ＢＳＡＰ110によって提供される機能を使用して、ＳＯＲを含むメッセージを、ブローカ120のトレーディングシステムへ特定の製品またはサービスを提供（テンダ）するために潜在的な供給者に向けた勧誘として送り出すことができる。本発明の実施形態では、その製品またはサービスに関係するＳＯＲを受け取る１以上の潜在的な供給者（105）の前もって定義した関心にしたがってサービスしているＳＳＡＰ115を経由して、購入者のＳＯＲメッセージをこれらの供給者へルート設定して伝えるようにされている。ユーザ端末装置100、105は通常の端末装置100、例えば適切なネットワークインターフェイスを備えていて、適切なＳＡＰへのアクセスを用意している通信ネットワークにリンクされたパーソナルコンピュータ（ＰＣ）を含む。
【００２３】
ブローカ120は、各ブローカ120によって構成される所定のルート設定条件にしたがって、ＢＳＡＰ110から1以上のＳＳＡＰ115へＳＯＲメッセージをルート設定することができる。所定のルート設定条件には、とくに、特定のタイプのＳＯＲを受け取る際の供給者の前もって定義した関心を含むことが好ましい。ブローカ120は、その“タイプ”、例えばＳＯＲが特定している製品またはサービスのタイプにしたがってルート設定する目的でＳＯＲを区別することができる。ブローカ120によって認識される製品またはサービスのタイプは、所定のＳＯＲ分類システムにしたがって規定することができる。既知のオブジェクト分類システムは、例えばDun & Bradstreet（商標）によるシステムを含む。したがってブローカ120によって実行される各所定のルート設定条件は、認識可能な製品またはサービスタイプの用語で表現され、その特定のタイプの製品またはサービスを特定するＳＯＲメッセージのブローカによってルート設定する送信先を規定する。各ブローカ120は、典型的な場合は、異なる組のルート設定条件に対して動作することができる。したがってブローカ120またはＳＳＡＰ115は、他のブローカ120によって構成されるルート設定条件によって、１以上の特定のタイプのＳＯＲメッセージのみの受け取りを専門に扱う。
【００２４】
図２を参照すると、本発明の第１の実施形態にしたがってブローカ120を採用する要求整合システムを示しており、図中のブローカ120はシステムに参加している類似のブローカのネットワークの１つであり、共通の通信ネットワーク205、例えば公共の（パブリック）インターネットによってリンクされている。ブローカ120は、メッセージを送受信する通信ネットワーク205へのアクセスを備えるようにされているネットワークインターフェイス200をもつことが好ましい。ネットワークインターフェイス200は、ＴＣＰ／ＩＰおよびＨＴＴＰのような適切な通信プロトコルを構成して、ネットワーク接続を設定し、通信ネットワーク205におけるメッセージを送るようにすることが好ましい。ネットワークインターフェイス200は、通信ネットワーク205への接続に関してブローカ120へ割り当てられたアドレス指定用情報の記録、例えばＩＰアドレス、を維持することもできる。
【００２５】
図２に示したように、ブローカ120はさらに要求の整合およびルート設定モジュール210、登録されたＳＯＲルート設定選択（Routing Preferences, ＲＰ）215、ルート設定選択登録および更新モジュール225をもち、要求分類基準（規格）220の参照メモリをもつか、このメモリへのアクセスを備えるようにされている。登録されたＲＰ215のメモリは、受け取ったＳＯＲメッセージをルート設定する際にブローカによって構成される所定のルート設定条件を含む。とくに要求整合およびルート設定モジュール210は、ＳＯＲメッセージを受け取った際にネットワークインターフェイス200を介して、受け取ったＳＯＲによって特定された要求タイプを識別し、識別された要求タイプに対して登録されたＲＰ（215）から、ＳＯＲメッセージをルート設定する１以上の送信先を判断するようにされている。受け取ったＳＯＲメッセージに対する1以上の意図された送信先を判断すると、整合およびルート設定モジュール210はＳＯＲメッセージを通信ネットワーク205上でネットワークインターフェイス20を介して各所定の送信先へ送るようにすることができる。
【００２６】
整合およびルート設定モジュール210は、より高いレベルのプロトコルを構成し、ＨＴＴＰおよび他のトランスポートまたはアプリケーションレベルのプロトコルを実行して、要求整合システム内の要求に関係するメッセージの送信を制御することが好ましい。より高いレベルで使用するための“オープンメッセージングプロトコル”（ＯＭＰ）は、本明細書において後で規定し、開示する。要求整合システム内の各参加ノードは、各々がＯＭＰによって使用するためにシステム内で独特であるような、識別子に対して割り当てられていることが好都合である。このような識別子は、基礎となるネットワークアドレスよりも変化し難い。
【００２７】
整合およびルート設定モジュール210は、有効な要求タイプを含む要求分類基準220の参照メモリにアクセスして、受け取ったＳＯＲメッセージによって伝えられる要求のタイプを識別し、認識することができる。参照メモリ220のローカルに制御されたコピー220は、ブローカ120内に保持されていていもよいが、選択的に遠隔の参照メモリは要求にしたがってブローカ120によって通信ネットワーク205を経由してアクセスできることが好ましい。
【００２８】
図３を参照すると、本発明の実施形態で使用するルート設定選択の好ましいフォーマットを示した。図３に示したＲＰは、指標（インデックス）付きデータベースファイル内のテキスト記録として、例えばＲＰ登録および更新モジュール225によって、登録されたＳＯＲ  ＲＰ215のメモリ内に記憶および維持することができる。図３のルート設定選択（ルーティングプレファレンス）フォーマットは：ＲＰメモリ215内でＲＰを独特に識別する参照基準（レファレンス）を含むフィールド（ＲＰ−ＩＤ）300；ＲＰの送信者の識別子、すなわち整合しているＳＯＲメッセージを送るための送信先アドレスを含むフィールド305；発信元（送信先）を識別するフィールド305内で特定されたアドレスタイプを示して、例えば“ＯＭＰ”識別子を“ＤＮＳ”（ドメイン名サービス部）のドメイン名または“ＩＰ”（インターネットプロトコル）アドレスから区別するフィールド310；ＲＰの送信元によって規定されたＲＰの期限切れの日付けを含むフィールド315；ＲＰの送信元によって規定されるようにＲＰの妥当性を最後に確認した日付を含むフィールド320；およびＲＰの送信元が受け取ることを望む要求の形式の定義を含むフィールド325を含む。
【００２９】
要求定義フィールド325は、基準メモリ220内に記憶された有効な要求定義をから選んだものを使用して要求を規定する。送信元（送信先）フィールド305は、ＲＰの送信元のＯＭＰの割り当てられた識別子を含むことが好ましい。その代わりに、ブローカ120によってＯＭＰが実行されないときは、より低いレベルのネットワークアドレスが要求整合システム内でＳＯＲメッセージを送る送信先を独特に識別するのに十分である限り、これを記憶してもよい。
【００３０】
ＲＰメモリ215内に記憶されるＲＰは、他のブローカ120またはＳＳＡＰ115の専門を本質的に規定して、そのブローカ120から特定のタイプの要求を送るＳＯＲメッセージを受け取る。要求の整合およびルート設定モジュール210は、比較プロセスによってＲＰメモリ215内に記憶されるＲＰの要求定義フィールド325内に記録された要求タイプと、受け取ったＳＯＲとを整合することを試行する。整合要求定義（325）を見付けると、要求整合およびルート設定モジュール210は受け取ったＳＯＲメッセージをネットワークインターフェイス200を経由して整合ＲＰの送信元（305）へルート設定するのを制御する。しかしながら特定の送信先へルート設定するのに成功したＳＯＲメッセージにおいて、整合およびルート設定モジュール210は、ＲＰメモリ（215）内に記憶された登録されたＲＰ間の要求定義と、ＲＰの要求定義フィールド325内で特定された少なくとも詳細なレベルとの整合を見付けなければならない。ＲＰ内に含まれる要求定義（325）が、受け取ったメッセージ内のＳＯＲタイプよりも特定的で、詳しいとき、整合を直接的な比較によって見付けることはできず、整合およびルート設定モジュール210は要求整合システム内のデフォルトの送信先、例えば一般的な目的のブローカ120へ受け取ったＳＯＲをルート設定することができる。しかしＳＯＲの意図された送信先を識別すると、整合およびルート設定モジュール210は、ＳＯＲを構成する受け取ったメッセージを含む整合ＲＰの送信者（305）へ送るＯＭＰメッセージをアセンブルし、ネットワークインターフェイス200を経由するネットワーク接続を開始して、ＳＯＲメッセージを送り出し、ＨＴＴＰまたはＥメール内に適切なものとして封入する。
【００３１】
図２のブローカ120内のルート設定選択登録および更新モジュール225は、登録されたＳＯＲ  ＲＰ215のブローカメモリ内のストレージを制御してもよい。とくにＲＰ登録および更新モジュール225は、他のブローカ120およびＳＳＡＰ115と共通のメッセージング方式を構成して、それ自身のメモリ215内の特定のＲＰを登録、修正、または削除する要求を受け取り、そのＲＰメモリ内のＲＰを登録、修正、または削除する要求を他のブローカ120へ送るようにすることができる。このメッセージング方式によって、ブローカは要求整合システム全体のルート設定条件を採用して、それが他のブローカから特定のタイプのＳＯＲメッセージのみを受け取ることを保証することができる。ＲＰの登録および修正に関係する好ましいメッセージング方式は、本明細書内で後で記述する。
【００３２】
図６を参照すると、本発明の第２の実施形態にしたがってブローカ600の主要な構成要素を示すダイヤグラムが示されている。ブローカ600は、上述で概要を記載した第1の実施形態と同じやり方で動作するが、課金可能な情報の抽出および支払いモジュール605および受け取ったＳＯＲメッセージから抽出する課金可能な情報に対するメモリ610を追加している。通信ネットワークインターフェイス200によるＳＯＲメッセージを受け取ると、課金可能な情報抽出および支払いモジュール605は、受け取ったメッセージ内に含まれる所定のタイプの有用な情報を抽出し、メモリ610内にその情報を記憶することができる。有用な情報には、例えばメッセージに応答できる供給者（105）に要求されるＳＯＲメッセージ送信者の詳細を含んでもよい。受け取ったメッセージの残りの部分は、整合およびルート設定モジュール210によって送られるが、抽出された情報はない。送られたメッセージは、ブローカ600によって保持されている情報のタイプの表示と、その情報の購入価格と共に含む。次に抽出された情報は要求に応じてブローカ600によって特定の供給者（105）へ送られるが、このような情報の送信は既知の支払い方式にリンクしてもよい。例えば、課金はブローカ600によって供給者の口座に記録され、ブローカ600によって、または第３の当事者のサーバによって、有用な情報に対する供給者（105）の各要求に対して維持されてもよい。その代わりに、供給者（105）による各要求は、既知の電子支払い方法を使用して送信ブローカ600への電子支払いを伴う。
【００３３】
このような情報抽出の特徴は、要求整合システムを供給する多数の可能な方法の１つのベースとして使用してもよい。
【００３４】
次の段落における“ブローカ120”に対する全ての参照基準は、ブローカ600内の相当する機能に対する参照基準を含むと考えられる。
【００３５】
一般的な動作構成
図４を参照すると、本発明の好ましい実施形態にしたがって動作要求整合フレームワークの参加者およびユーザを示すダイヤグラムを示した。一般的なＢＳＡＰ110および一般的なＳＳＡＰ115の主要な構成要素は、“購入者”の端末装置100、“供給者”の端末装置105、およびブローカ120と一緒に示され、これらは全て共通の通信ネットワーク205にリンクされる。ＢＳＡＰ110は、ブローカのネットワークインターフェイス内に含まれている類似の機能をもつネットワークインターフェイス400を含む。とくにＢＳＡＰのネットワークインターフェイス400は類似のネットワークプロトコルを構成し、通信ネットワーク205へのアクセスを備えて、ブローカ110のユーザによって生成される要求メッセージの移送に対してネットワーク接続を設定することができる。ネットワークインターフェイス400はさらに、ユーザ端末装置100からＢＳＡＰ110への通信アクセスを用意してもよい。ＢＳＡＰ110はユーザインターフェイス405を含み、ＢＳＡＰ110によって用意された機能へのアクセスをユーザに与えることができる。とくに、要求規定および送り出しモジュール410では、ユーザ（100）は、例えばテンプレートを使用して、ユーザインターフェイス400を介して所定の基準（規格）に一致するＳＯＲを生成し、封入したＳＯＲメッセージを要求整合システムへ送り出すことができる。規定および送り出しモジュール410では、要求分類基準415のメモリへのアクセスを備えて、ＢＳＡＰ110に生成されたＳＯＲが要求整合システムに適合した要求の記述、フォーマット、および分類の基準と一致することを保証するようにしてもよい。基準メモリ415はＢＳＡＰ110内でローカルなコピーとして保持されるか、または遠隔の基準メモリは要求にしたがってネットワークインターフェイス400を経由してアクセスすることができる。
【００３６】
ＢＳＡＰ110は、そのユーザによって生成された全てのＳＯＲメッセージを特定のブローカ120へ、ＳＯＲメッセージによって伝えられる要求タイプとは無関係にルート設定するように構成して、ＢＳＡＰ110内の整合およびルート設定機能に対する必要をなくすことが好ましい。特定のブローカは、ＢＳＡＰの地理的位置、ブローカ容量（キャパシティ）のアベーラビリティ（利用可能性）、または他の基準に基いて予め選定することができる。
【００３７】
図４を参照すると、一般的なＳＳＡＰ115は主要な構成要素としてネットワークインターフェース420を含んでおり、ネットワークインターフェイス420は、ブローカ120およびＢＳＡＰ110が通信ネットワーク205を介してＳＳＡＰ115への通信アクセスを行うのに使用されるものに類似したタイプであり、ブローカ120とメッセージを交換するためのネットワーク接続を設定することに加えて、ユーザ端末105との通信も可能にしている。ＳＳＡＰ115は、ＳＳＡＰ115によって提供される機能に対する所有権を主張できる（proprietary）ユーザインターフェイス425を含む。とくに、ユーザ（105）はユーザインターフェイス425を介して所有権を主張できるユーザ登録モジュール430によって与えれる機能を使用してＳＳＡＰ115を介して要求整合システムへのアクセスを登録する。ユーザ登録モジュール430によって実行される登録プロセスでは、ユーザがＳＳＡＰ115を介して受け取ることを選択するＳＯＲメッセージのタイプを特定し、ＳＳＡＰ115内でその選択を記録することを選択する。ユーザ（105）は、要求整合システムにおいて使用する分類方式によって定められる要求タイプに関係して好ましいＳＯＲメッセージタイプを規定することができる。したがってユーザ登録モジュール430は、ローカルに保持されたコピーとしてか、またはユーザインターフェイス420によって通信ネットワーク205上でアクセスできる遠隔のメモリの何れかとして、要求分類基準445のメモリへのアクセスを備えるようにしてもよい。
【００３８】
ＳＳＡＰ115は、ルート設定参照登録および更新モジュール440を含んでもよく、このルート設定参照登録および更新モジュール440は本明細書内で後に規定されるＲＰの登録および更新用の要求整合システムの好ましいメッセージング方式を実行するようにされている。とくに、ＲＰ登録および更新モジュール440ではＳＳＡＰの登録されたユーザの選択を表わすＲＰを登録するメッセージを生成し、これらのメッセージを1以上の適切なブローカ120へ送ることができる。ユーザインターフェイス425はさらにユーザ（105）へのアクセスを用意して、ブローカ120によってＳＳＡＰ115へ伝えられた適切なＳＯＲメッセージを検索する。
【００３９】
ＳＳＡＰ115はさらに、ネットワークインターフェイス42を介してブローカ120からＳＯＲを受け取る所有権を主張できる要求受取りおよび配信モジュール435、および受け取ったＳＯＲをユーザインターフェイス425を介して登録されたユーザ（105）にアクセス可能な形態で記憶する手段を含んでもよい。
【００４０】
実際には、要求整合システムの供給者は、上述の概要において記載したように、システムに対してアプリケーションプログラマインターフェイス（ＡＰＩ）をレリース（release）して、ＳＡＰ供給者がシステムメッセージの取り扱い上の特徴、要求分類方式、および選択的にシステムの要求整合技術を実行できるようにしてもよい。後者がＢＳＡＰの供給者に対して使用可能であるとき、ブローカ内に用意されたものと類似した要求をルート設定する機能を含むＢＳＡＰ110の別の形態として、登録されたルート設定選択のメモリ、およびこれらの選択にしたがった個々のブローカ120に対する要求のルート設定に用意してもよい。このような構成は、ＳＯＲをルート設定する第１の段階において、ＢＳＡＰ110における生成から、最も可能性の高いルート設定が別のより関連したブローカになる単一の所定のブローカ120ではなく、適切な潜在的に専門のブローカ120へ方向付けられるという長所をもつ。ＢＳＡＰから方向付けられるルート設定はホップ数を低減し易く、メッセージはＳＳＡＰ115へ到達する前にブローカのシステム内を占める必要がある。
【００４１】
電子トレーディングシステムの各構成要素は、公共のインターネットによって与えられるような通信ネットワーク205へリンクされることが好ましい。システムの潜在的なユーザは、適切なインターネットインターフェイスおよびインターネット接続をもち、既知のインターネットブラウザ製品を実行するパーソナルコンピュータ（100，105）を備えていてもよい。ＢＳＡＰ110およびＳＳＡＰ115の実現は、既知のコンピュータを使用して、通信ネットワーク205（例えば、インターネット）に対する標準のインターフェイスを備えたサーバの役割を実行し、ネットワークレベルのプロトコルと、要求の整合およびルート設定に対して採用されるより高いレベルのプロトコルとを構成するソフトウエアを、システムＡＰＩの一部としてレリースされるソフトウエアを使用して実行することによってもよい。ＢＳＡＰ110およびＳＳＡＰ115の機能は、各サーバコンピュータ上で実行されるコンピュータプログラムを使用して実行および制御され、ＣおよびＣ＋＋のような既知のコンピュータプログラミング言語を使用して書込まれる。ブローカの要求整合システムとの対話を含むＢＳＡＰおよびＳＳＡＰ機能の要素は、システムＡＰＩの一部として用意されたソフトウエアを使用して実行することによってもよい。しかしながらネットワーク205およびブローカ120との対話に対して要求される態様に加えて、ＳＡＰによってユーザに与えられた機能は、ＳＡＰの所有者により変化してもよい。
【００４２】
ブローカ120は、同様に、共通の基準インターフェイスを使用し、かつ適合したプロトコルおよびメッセージ構造を実行する通信ネットワーク205へリンクされた既知のサーバを使用して実現されてもよい。ブローカの機能は、ＣおよびＣ＋＋のような既知のコンピュータプログラミング言語を使用して書込まれたコンピュータプログラムを使用して実行および制御することができる。ＲＰメモリ215および要求分類基準メモリ220は、オラクル社によって提供されている既知のデータベース管理システムを使用して実行してもよい。適切なときは、ブローカサーバは１以上の論理的に異なるブローカに対するコンピュータ処理プラットフォームとしてサービスすることができる。要求ブローカの機能は、例えばＣまたはＣ＋＋を使用して書込まれ、ブローカサーバコンピュータ内のプロセッサ上で実行されるコンピュータプログラムとして構成することができる。
【００４３】
動作構成（オペレーショナルコンフィギュレーション）の使用
ここで図２、３、および４を参照して、好ましい実施形態にしたがって電子トレーディングシステムのコンテキスト（情況）の中でより詳しく記載することにする。しかしながら要求整合システムは、他のアプリケーションのコンテキストでも後述のやり方と類似したやり方で使用することもできる。とくに、“供給者”は、製品またはサービスにおける販売担当者（commercial trader）ではなく、単に情報源であってもよい。情報の供給者は、“購入者”、すなわち登録されたＲＰによって、これから開示することになるシナリオの中の供給者と同じやり方で送られる情報に対する特定の要求を捕捉してもよい。
【００４４】
好ましい電子トレーディングシステムでは、購入者は端末装置105における受領について供給者への要求を端末装置100から送ることができて、購入者の特定の記述についての製品またはサービスの供給に対して申し入れ（テンダー）をすることができる。全ての供給者が、購入者の要求に応答できる均等な機会をもつことを保証するために、このトレーディングシステムは、特定のタイプの製品またはサービスに関係する要求を受け取ることについて登録した関心をもっている供給者（105）に向けてＳＯＲメッセージの配信に目標を定めるように構成してもよい。上述のように、“目標を定められた配信（ターゲットデリバリイ）”は、登録されたＲＰ（215）にしたがって、ＢＳＡＰ110から１以上のＳＳＡＰ115へ向け、ＳＯＲメッセージをルート設定するようにされた要求ブローカ120のシステムを使用して達成することができる。
【００４５】
ＳＳＡＰ115は特定のタイプの製品またはサービスを専門に扱うことが好ましい。したがって、特定の製品またはサービスの供給者（105）は、類似の製品またはサービスの取り引きを専門に扱うことが分かっているＳＳＡＰ115を通してトレーディングシステムへアクセスするようにされている。例えばトレーディングシステムに参加しているＳＳＡＰ115は、自動車を供給することを専門に扱う（スぺシフィックディスクリプション）ことができる。自動車の供給者は、ＳＯＲから一般的な自動車または特別に記述された車のいずれかを受け取る端末装置105からこのようなＳＳＡＰ115へのアクセスを得るようにしてもよい。供給者（105）によるＳＳＡＰ115へのアクセスは、商業上の協定に関してＳＳＡＰ115によって供給者へ与えることができる。ＳＳＡＰ115経由のアクセスを得る特定の供給者の専門は、トレーディングシステムの合意された分類方式（220）において既に規定された製品またはサービスタイプという条項で表わすことができることが好ましい。
【００４６】
実際には、トレーディングシステム内部のブローカ120は、特定のタイプの製品またはサービスに関係するＳＯＲメッセージの受け取りを専門に扱ってもよい。ブローカの専門は、トレーディングシステムの供給者によって判断され、メッセージング方式において自動的に、または手動手段によってトレーディングシステム内の参加者間で広告してもよい。ＳＳＡＰ115と関係する管理者は、ＳＳＡＰのルート設定選択登録および更新モジュール440によって与えられる機能によって、適切なメッセージを生成し、関係するタイプの製品またはサービスを専門に扱うように広告されたブローカへ送って、個々の供給者の選択を表わすＲＰを記憶してもよい。その後、ブローカ120はＳＯＲメッセージを受け取って、供給者の登録したＲＰにおいてそれに整合する要求を特定すると、ブローカはＳＯＲメッセージをＳＳＡＰ115へ送り、供給者へ配送する。
【００４７】
後述するように、メッセージング方式は要求整合システム内部で特定のブローカによって記憶されるＲＰの詳細を得るためのメッセージを含んでもよい。このようなメッセージを使用して、ＳＳＡＰ115はブローカ120の専門を自動的に推測し、供給者の選択に適したＲＰを記憶する適切なブローカを自動的に選定する情報を使用してもよい。
【００４８】
より大きい範囲の製品またはサービスを取扱うトレーディングシステムにおいて、ブローカ120は、ＳＳＡＰ115の製品またはサービスのより高いレベルのカテゴリに関係するＳＯＲの受取りおよびルート設定を専門に扱ってもよい。例えばＳＳＡＰ115は自動車を供給することを専門に扱う一方で、ブローカ120は、一般に自動車に関係する全てのＳＯＲをルート設定することを専門に扱ってもよい。それが全ての自動車のＳＯＲを受け取ることを保証するために、自動車のブローカ120は、このようなＳＯＲを受け取り易い高い他のブローカ120のルート設定選択メモリ215において、全ての“車輌（Vehicle）”のＳＯＲメッセージを受け取るルート設定選択を登録するようにしてもよい。この機構を適用することによって、全てのブローカの専門はトレーディングシステムにおいて登録され、理解されることになる。ＳＳＡＰ115レベルにおいて、自動車を専門に取扱うシステム内にブローカ120があることが識別されると、自動車を供給することを専門に扱うＳＳＡＰ115は自動車ブローカ120で適切なＲＰ（215）を登録して、特定の自動車に関係するＳＯＲを受け取るようにしてもよい。トレーディングシステムのブローカ120間でＲＰを登録するメッセージは、ＳＳＡＰ115とブローカ120との間におけるように、ＲＰ登録によって与えられる機能を使用してアドミニストレータによって開始され、各ブローカ内のモジュール225を更新してもよい。
【００４９】
参加しているＢＳＡＰ110は、要求タイプとは無関係に、購入者（100）によって生成された全てのＳＯＲを特定の指名されたブローカ120へ送ることが好ましい。指名されたブローカ120は、例えば特定の地理的領域内で、トレーディングシステム内の最初の契約点（出発点）をＢＳＡＰ110を使用して全ての購入者（100）を与えてもよい。要求タイプの解析およびＳＯＲの次のルート設定は、ＢＳＡＰ110内でこのような機能を構成するのではなく、ブローカ120内のみで行なうことができる。
【００５０】
ブローカ120、とくに専門のブローカを使用すると、代わりの要求整合およびルート設定システムおよび電子トレーディングシステムよりも好都合になる。例えば、通信ネットワーク205によって接続されたＳＳＡＰ115およびＢＳＡＰ110、またはこれらに相当するもののみを含むシステムにおいては、ＳＳＡＰ115によって特定のタイプのＳＯＲを受け取る選択は、各ＢＳＡＰ110内でいくらか実現されることが必要である。どのＳＳＡＰ115も、各ＢＳＡＰ110に関する情報を維持して、その関心が各ＳＯＲ源に登録されることを保証することが必要である。その理由は、購入者（100）は有効なタイプの製品またはサービスを購入することを選び、有効なタイプのＳＯＲをシステムへ潜在的に導入（導入可能に）できるからである。しかしながら本発明では、比較的少数のブローカ120と協働して、ＢＳＡＰ110からＳＳＡＰ115へ要求をルート設定するトレーディングシステムは、相当に簡素化された関心登録システムを使用して動作することができる。ＳＳＡＰ115は製品またはサービスの関連するカテゴリを専門に扱うブローカ120のみに気付き、関心がＲＰ（215）としてブローカのみに登録されることを保証することが必要である。ブローカ120、それら自体に関して、各ブローカ120は特定の関心をＲＰ（215）として他のブローカの一部または全てに登録することが必要である。ブローカ120がＳＳＡＰ115よりもより高いカテゴリを専門に扱うようにされているとき、システム内に登録されたルート設定選択の総数は著しく低減され、登録を相当に簡単にすることができる。しかしながら要求整合およびルート設定モジュール210は、より精巧なＳＯＲ整合アルゴリズムを含んで、ルート設定選択（215）として登録されたレベルよりもより特定的に表現されたＳＯＲの正しいルート設定を保証することが必要である。
【００５１】
ブローカ120がないとき、各ＢＳＡＰ110におけるＳＳＡＰルート設定選択の登録の代わりは、各ＳＳＡＰ115が、ＢＳＡＰ110によって通信ネットワーク205への各要求メッセージのブロードキャストを個々にモニタして、ユーザ（205）に対する関心のメッセージを解析して選定する。しかしながら非常に少数ではあろうが、どのシステムでも、ＳＳＡＰ115によって解析されるデータ量が多いことは禁止されてよい。
【００５２】
要求定義および分類
ブローカ120が要求整合システム内でＳＯＲをルート設定できるようにするために、要求の分類および表示の共通の方式はシステム全体で一致し、かつ実行されることが重要である。ＳＯＲの整合およびルート設定の成功を保証するために、分類方式は、システム内で要求のルート設定が規定される少なくとも最低レベルの要求定義に一致している。要求整合システムＡＰＩは、システムブローカによって実行される予め規定された要求分類方式メモリに対するインターフェイスを含み、ＳＡＰの供給者が一貫性およびコンプライアンスを保証するのに使用することが好ましい。次に要求の分類および特定に対する好ましい方式を記述するが、他の既知の分類方式を本発明のアプリケーションで使用するのに適するように採り入れることができる。
【００５３】
要求は資源の“資源”および“属性”に関して特定することができる。“資源”は、サービスに対する日常的なオブジェクトから、本発明の応用に適していると考えられるものであってもよい。トレーディングシステムにおいて、“資源”とは、製品、サービス、あるいは購入者が潜在的に関心をもっている製品またはサービスの特徴であってもよい。オブジェクト指向のアプローチは、ＳＯＲ内のユーザによって特定され易い資源および資源の属性の規定および分類のために採り入れてもよい。例えば“自動車”のような資源はオブジェクト指向の意味で“オブジェクト”として規定してもよい。自動車資源の特徴−すなわち“属性”は、エンジンサイズ、ボディのカラー、空調の有無、などを含んでもよい。“自動車”オブジェクトを特定するのに使用できる属性の全ては、分類システム内で規定できる。“自動車”オブジェクトの規定は、それ自身の組の有効な属性をもつ他のオブジェクトを含んでもよい。特定の“自動車”オブジェクトは、有効な自動車の属性（特徴）の個々の選定に関して特定してもよい。既知のテキスト応用マークアップ言語はオブジェクトおよび属性の規定の表示、すなわちインターネット上でのWorld Wide Web Consortium（http://www.w3.orq/TR）によって規定および公開された“拡張マークアップ言語”（“Extensible Markup Language”, XML）に適用すると便利である。
【００５４】
要求整合システム内では、全ての適用可能な資源は、オブジェクトおよび属性に関して、システムによってルート設定するのに要求される少なくとも詳細なレベルに予め適用してもよい。システム内での使用に適合した各オブジェクト規定では、要求分類基準の参照メモリ内に記憶してもよい。上述のように、要求分類基準のメモリは、ＢＳＡＰ110およびブローカ120によって遠隔から、またはローカルにアクセスすることができる。ローカルコピー415は、ＳＯＲを生成する際にユーザ（100）によって使用するＢＳＡＰ110内に保持してもよく、コピー220をブローカ120内に保持して、要求の妥当性およびルート設定を補助することができる。
【００５５】
電子トレーディングシステムに応用される本発明の好ましい実施形態において、システム内で使用される全てのオブジェクトは、本明細書の目的において、“Global Trader(グローバルトレーダ)または“ＧＴ”オブジェクトと呼ばれると考えられる。要求定義言語の種々の要素は、ＸＭＬ表記を使用してＧＴオブジェクトおよびその属性を記述および分類するように工夫される。例えば、ルート設定する要求のために、オブジェクトタイプの分類はとくに重要になり易い。したがって<GT OBJECT TYPE>のようなタグは、システム全体でオブジェクトタイプを宣言する言語要素として認識することができる。例えばＸＭＬ表記において、“VEHICLE（車輌）”オブジェクトタイプは次のように表わすことができる：
【表１】
0004522583.tif 000002
【００５６】
なお、<GT DESCRIPTION>は、“VEHICLE（車輌）”オブジェクトの短い“テキスト記述”を囲ったタグである。
【００５７】
オブジェクトタイプの階層は、<GT OBJECT TYPE>内の<GT OBJECT PARENT>タグを使用して規定することができる。例えば“CAR(自動車)”オブジェクトは“CAR（自動車）”オブジェクトタイプ規定内に、その親オブジェクトとして“VEHICLE（車輌）”をもつように規定することができる。したがって、次のように表わすことができる：
【表２】
0004522583.tif 000003
【００５８】
オブジェクト、または他の属性で使用できる属性は、<GT OBJECT PARENT>タグを使用して規定でき、<GT OBJECT PARENT>タグには、各々が<GT OBJECT PARENT>タグによって囲まれている有効な属性値の範囲を含んでいる。例えば、“COLOUR（色彩）”属性タイプを次のように規定することができる：
【表３】
0004522583.tif 000004
【００５９】
この例では、３つの別の区別属性値は色彩属性値“WHITE（白）”に対して特定できることに注意すべきである。
【００６０】
自動車に適用可能な他の属性は、例えば次に示すものを含んでいると規定することができる：
【表４】
0004522583.tif 000005
【００６１】
“ユニットセット”は、ユニットセットの名前を明らかにした‘id’パラメータを使って、<GT UNIT SET>タグによって規定することができる。この中ではタグは、許容可能なユニットの範囲内で各ユニットを特定する1組の<GET UNIT>に囲まれている。各ユニットは、適切な変換要素を宣言して、<GET REFERENCE UNIT>によて特定される参照ユニットへ変換することができる。例を次に記載する：
【表５】
0004522583.tif 000006
【００６２】
ＳＯＲ内で同報通信される要求を特定する際に、ユーザ（100）は要求分類基準415のメモリから有効なオブジェクトおよび属性タイプを選定することができる。例えば“自動車（car）”を購入したいユーザ（100）は、そのタイプのオブジェクトに適用可能な属性から選定される特定の属性をもつＳＯＲ内の自動車のオブジェクトを特定することができる。ユーザ（100）は、次のようにＸＭＬ表記法を使用して自動車(car)オブジェクトを特定することができる。
【００６３】
【表６】
0004522583.tif 000007
【００６４】
この例では、<GT OBJECT>タグが選定したオブジェクト、この場合は”CAR(自動車)”を既に宣言した有効なオブジェクトタイプから特定し、一方で<GT ATT>は既に宣言した属性タイプから選定された車輌オブジェクトの属性を特定し、各属性タイプから個々の値を特定する。上述の例で使用する別の表記表デバイスは、有効な属性値をそのタイプに関係して適用するために”*”を含み、例えば自動車は“”は“SUNROOF”のタイプを含み、”opp”パラメータは特定の属性値がとくに要求されないことを知らせる。この例ではopp=”-”は”*”と組合せて使用され、”*”は“AIR CONDITIONING（エアーコンディショニング）”属性値は特定の”CAR(自動車)”オブジェクト内に含まれる、すなわちエアーコンディショニングは特定の自動車にはいずれの形態でも要求されないことを示す。
【００６５】
トレーディングシステムにおいて、それぞれブローカ120およびＢＳＡＰ110によってアクセスされる要求分類基準220および415のメモリは、例えば”VEHICLE（車輌）”、”CAR（自動車）”、および”BUS（バス）”に対するオブジェクトタイプの規定を含んでもよい。ブローカ120は、”VEHICLE（車輌）”に関係するＳＯＲを受け取ることを専門に取扱い、ＳＳＡＰ115は、”CAR（自動車）”および”BUS（バス）”のようなより低いレベルのオブジェクトタイプを専門に取り扱うことが好都合である。”VEHICLE（車輌）”オブジェクトタイプの上述の規定を与えると、ルート設定選択(215)はブローカ120において記録され、自動車に関係する全てのＳＯＲを、例えば”Vehicle”ブローカへルート設定する。その代わりにルート設定選択は、意図された受信者の専門レベルで表現されてよく、要求の整合およびルート設定モジュール210を出て、関係する親オブジェクト、したがって適切なブローカを要求分類基準メモリ220、415に記憶されたオブジェクトタイプの規定から論理的に推測することができる。言い換えると、ルート設定選択215は、この例では（１）高級オブジェクトタイプ”VEHICLE”によるか、（２）”CAR”もしくは”BUS”でその親オブジェクトとして”VEHICLE”を有するような低級オブジェクトタイプの何れかの条項で定義できる。第１の場合には、ルート設定選択215は高級”VEHICLE”オブジェクトタイプの条項でのみ定義され、次にもしブローカ120が”CAR”を特定しているＳＯＲを受領するときは、要求整合およびルート設定モジュール210は要求分類基準メモリ220、415内に記憶されたオブジェクトタイプ定義を用いて、”CAR”が”VEHICLE”の例であって、それ故に”VEHICLE”条項で定義されたルート設定選択215によりルート設定されるべきことの結論に達することが必要になる。第２の場合は、もし別のルート設定選択が、例えば”CAR”オブジェクトタイプ条項で定義されるときは、もしブローカ120が”CAR”を特定するＳＯＲを受領すると、応用可能なルート設定選択で"CAR"条項で定義されるものが直ちに識別されることになる。この例では、アルゴリズムは要求整合モジュール210内で実行されて、自動車に関係するＳＯＲが、どのブローカも”CAR（自動車）”レベルにおいて特定されないことを条件に、”VEHICLE（車輌）”に関係するＳＯＲを専門に扱うブローカにルート設定されてよいような”CAR（自動車）”オブジェクトタイプから推測してもよい。さらに、車輌を供給するビジネスのユーザを登録したＳＳＡＰ115は、標準の”VEHICLE”オブジェクトタイプの定義から、”VEHICLE”のＳＯＲを専門に扱うブローカ120が、”VEHICLE”オブジェクト階層内に入る他のＳＯＲ間で、自動車に関係するＳＯＲを受け取ることを認識するようにすることができる。したがってこのＳＳＡＰ115、またはその管理者は、ルート設定選択（215）が”Vehicle”ブローカで登録されて、ブローカが自動車に関係するＳＯＲをＳＳＡＰ115へ送ることを保証するようにしてもよい。別のＳＳＡＰ115は類似の、またはより特定された要求ルート設定選択（215）を、ユーザ（105）の選択に適した”Vehicle”ブローカに登録してもよい。
【００６６】
ＳＯＲのルート設定は、ＳＯＲ内で識別可能な適切なタイプのオブジェクトタイプ規定または属性タイプ規定が適切なレベルを用いて行われてよいが、その条件は、これらの規定がルート設定を矛盾なく行うことができるようにするために要求整合システム内部で十分に幅広く適合されていることとするのが好ましい。例えば、２つのブローカが車輌(Vehicle)を専門に扱っていて、一方のブローカが自動車(Car)を専門に扱っているが、他方のブローカが残りの車輌タイプの全てを専門に扱っているとき、有効なレベルの専門を規定する機能はとくに重要である。さらにより低いレベルでは、ＳＳＡＰ115が赤い自動車のみを供給することを専門に扱っているとすると、ＳＳＡＰ115によって車輌（Vehicle）を専門に扱っているブローカに登録されたルート設定選択（215）は、属性値レベル、すなわち”RED（赤）”を専門に扱ってもよい。いくつかの個々に特定された供給者（105）は、ＳＳＡＰ115を経由して相当に詳しいルート設定選択に登録して、これらの供給者がおそらく満足しないＳＯＲを受け取るのを避ける必要がある。
【００６７】
オープンメッセージプロトコル（ＯＭＰ）
上述のオープンメッセージプロトコル（ＯＭＰ）は多数の使用特徴を含むが、要求整合システムの動作にとって本質的でなくてもよい。とくに、ＯＭＰ識別子、
要求整合システム内でそれぞれ独特のものは、システム、すなわち各ブローカ120、ＢＳＡＰ110、およびＳＳＡＰ115に参加しているかまたはリンクされた各ノードに割り当てられていてもよい。ＯＭＰ構成は、変換表を維持して、ＯＭＰ識別子を基礎となるネットワークアドレス−インターネットドメイン名、またはインターネットの場合はＩＰアドレスに変換する手段を含んでいてもよい。これは、より安定していて、より記述的な識別システムが、ＩＰアドレスまたはドメイン名を変更する可能性をもつのではなく、ＯＭＰ内で使用してもよいという長所をもつ。理想的には、第３の当事者はＯＭＰ識別子の割り当ておよび変換表の維持を制御してもよい。もちろん、このシステムは、例えばインターネットドメイン名またはＩＰアドレスのみを使用して動作できるが、これらは変更されることになる。ＯＭＰがないときにルート設定選択メモリ215内の各エントリを不便なことに、変更する必要がある。
【００６８】
ＯＭＰメッセージは、テキスト応用であってもよく、ＸＭＬ表記を使用して、所定の階層およびメッセージ構造内でメッセージパラメータを宣言してもよい。ＯＭＰメッセージは２つの部分−すなわち多くのメッセージ（例えばノード識別子およびルート設定情報）に共通の情報、および特定のブローカへ送られるＳＯＲのような個々のメッセージに特定の情報をもっていてもよい。共通の情報は、次に示すような適切なＸＭＬタグによってメッセージに特定の内容(Message-specific Content, ＭＳＣ)から分離されたＯＭＰメッセージ内の共通のメッセージブロック（ＭＳＣ）として保持することができる：
【表７】
0004522583.tif 000008
【００６９】
メッセージのＣＭＢ部分は<CMB>によって囲んでもよく、一方でＯＭＰメッセージのＭＳＣ部分は<MSC>タグで囲んでもよい。ＭＳＣ部分は、例えばベース64（base64）として囲まれてもよいが、通信システムを通って次のノードへＯＭＰメッセージを伝えるのに使用されるより低いレベルのプロトコルタイプを考慮して、他のコードを必要なときに使用してもよい。例えば、Ｅメールを使用して、要求に関係するメッセージを次のブローカ120へ伝えるとき、対応するＯＭＰメッセージの全体をベース64としてコード化してもよい。
【００７０】
ＯＭＰプロトコル層を構成するシステムの個々の実施形態において、ＯＭＰメッセージのＣＭＢ部分を使用して、メッセージ源と、既知のものであるときは、メッセージの通信経路内の次の段の識別子とを識別する。ＯＭＰメッセージがシステム内のノードからノードへ、さらにメッセージ内の特定の送信先または各ノードに記憶された要求のルート設定選択215にしたがって移動するとき、各参加しているノードにおいて実行されるＯＭＰ構成はそれ自身のＯＭＰノード識別子をデータを伴うメッセージのＣＭＢ部分およびメッセージの受領および送信に対する日付けおよび時間エントリに加える。したがって監査トレールは、メッセージ内に含まれるＳＯＲに応答して戻り通信路を選択するとき、メッセージの最後の受領に対する潜在的な使用に対してＯＭＰメッセージ内に累積される。ＯＭＰメッセージの例として、共通のメッセージブロック（Common Message Block, ＣＭＢ）を次に示す：
【表８】
0004522583.tif 000009
【００７１】
この例では、<ROUTING>は、送信元のノードによって割り当てられた独特のＯＭＰメッセージ識別子”OMP-M-GUID”を規定する。<MESS SUPPLIER>はメッセージ（ＳＯＲ）の源ノード（ＢＳＡＰ）のＯＭＰ識別子を宣言する。<MESS CONSUMER>は、既知のものであるときは最後のメッセージ受領のＯＭＰ識別子か、または既知のものであるときは送信経路の次の段階を宣言する。<MESS CONSUMER>は空白のまま残されると、ルート設定は存在するノードに記録された要求ルート設定選択215にしたがって方向付けられてもよい。<MESS PATH>タグが、初めは特定されていない経路を囲み、メッセージを処理する各<NODE>が、メッセージが通るときにそれ自身のＯＭＰを加えてもよい。システムによって処理されるメッセージの監査トレールを与えるとき、<AUDIT>および<TRAIL>タグは、メッセージが送受信されるときに日付および時間情報をネットワーク経路内の各参加ノードによって加えることができるようにする。
【００７２】
システム内の各ノードにおいて展開されるＯＭＰ構成では、使用されている通信ネットワーク205に適したより低いレベルプロトコルと対話することができる。ＯＭＰは、多数の異なるプロトコルの１つと対話して、各参加しているノードにおいて展開される要求整合機能の実行を変更する必要なくメッセージのルート設定を達成することが好都合である。例えばＨＴＴＰはいくつかのブローカ120間のメッセージ移動に使用することができ、一方でＥメールまたはＣＯＲＢＡは他の場合に適している。ＯＭＰは、要求整合システムとこれらのより低いレベルのプロトコルとの間に共通のインターフェイスを用意して、ノード識別およびＯＭＰメッセージ構造の共通の方式を維持することができる。
【００７３】
ＳＯＲ構造およびＳＯＲメッセージ
ＢＳＡＰ110は、要求整合システムＡＰＩによって用意されるか、または規定される機能を組込んだ要求定義および送り出しモジュール410を用意して、ユーザ（100）は上述で自動車の例に対して示したような要求定義を含むＳＯＲと、ＳＯＲの源および有効期間を含むいくつかの別のパラメータとを生成および同報通信することができる。
【００７４】
ＳＯＲメッセージのパラメータの各々は、予め規定されたオブジェクトおよびその属性に関してＸＭＬ表記法を使用して規定および表示することができる。これらのオブジェクトおよび属性の規定は、システムのＡＰＩに与えられた機能によって、要求整合システムに参加している各ブローカ120およびＢＳＡＰ110にアクセス可能な参照メモリ内に記憶される。ＳＯＲパラメータの規定は、例えば要求分類基準メモリ220、415内に含んでもよい。次の要素の規定を使用して、ＳＯＲに関係するオブジェクトおよび属性を特定してもよい：
【表９】
0004522583.tif 000010
【００７５】
【表１０】
0004522583.tif 000011
【００７６】
要素‘親’および‘子’は、ＳＯＲ内で使用されるオブジェクト階層を規定する。ＳＯＲび‘ｉｄ’は、ＳＯＲが生成されたときにＢＳＡＰ110およびブローカ120によって割り当てられることが好ましい。ＳＯＲの’ORIGINATOR’は送信元のＢＡＳＰまたはブローカと、送信元のユーザ（100）の詳細を規定するのに使用される他のオブジェクトに関係して規定することができる。送信元のＢＳＡＰまたはブローカの識別子は、独特の識別子属性’guid（グード、グッド）’によって’BROKER（ブローカ）’オブジェクトを使用して特定することができる。ここでは既に記載したようにＯＭＰ内で使用するのに割り当てられるブローカおよびＢＳＡＰの識別子を使用してもよい。ＳＯＲを生成した個人のユーザ（100）の個人の詳細を特定するのに規定されたオブジェクトおよび属性は、アドレスおよび他の接触情報を適切に含むことができる。
【００７７】
ＳＯＲの送信元の詳細の可用性（使用可能性）はブローカ120によって’ORIGINATOR（送信元）’オブジェクトの’DetailStatus’属性によって制御することができる。したがって、ブローカは供給者（105）から送信元ＳＯＲ内で送信元の詳細が使用可能である’DetailsState’属性を示す送信元の詳細を引き出すことができる。既知の支払いシステムは要求整合システム内で実行され、供給者（105）は、使用可能であれば、選定したＳＯＲに関係して送信元の詳細を有料で受け取ることができる。電子トレーディングシステムの進行中の提供および管理は供給者によって支払いシステム、例えばインターネット上で実行されるマイクロ支払いシステムへ投資（fund）できることが好ましい。ＳＯＲの送信元の詳細の要求および供給に関係するメッセージタイプの詳細については、本明細書内で後でさらに詳しく記載することにする。
【００７８】
‘SOR SPECIFICATION’は、要求定義に関係して既に記載したオブジェクトおよび属性に関係して規定することができる。この要素は、適合した分類システムにしたがって所定のオブジェクトおよび属性タイプに関係するユーザ（100）の詳細な要求の表現を含み、例として上述で”CAR（自動車）”オブジェクトを規定した。‘SOR SPECIFICATION’要素は‘application(アプリケーション)’属性を含み、ユーザ（100）によってＳＯＲを“同報通信（ブロードカースト）”するためのＳＯＲとブローカ120においてルート設定選択（215）の一部として要求定義を登録するＳＯＲとの間で区別されるＳＯＲの定義の使用を区別することができる。
【００７９】
例えば購入者の要求の同報通信として使用する完全なＳＯＲは、<SOR SPECIFICATION>タグ内に囲まれたユーザ要求として上述で特定したcar（自動車）オブジェクトを含んでおり、これを次に示す：
【表１１】
0004522583.tif 000012
【００８０】
【表１２】
0004522583.tif 000013
【００８１】
上述の構造にしたがってＢＡＳＰ110においてＳＯＲを生成すると、ユーザ（100）は通信システム205上で適切なメッセージ内でＳＯＲを同報通信するようにしてもよい。ＳＯＲを囲んでいるメッセージタイプは、次のように規定した別のメッセージ要素”GT MESSAGE”を使用して規定することができる：
【表１３】
0004522583.tif 000014
【００８２】
‘GT MESSAGE’要素は、メッセージタイプを規定することができ、送信元のノード、一般的にＢＡＳＰ110によってメッセージに割り当てられる独特の識別子を特定する。割り当てられるメッセージ識別子は、メッセージが要求整合システムを通して伝えられるので、変更されないままであることが意図される。例えばＯＭＰによって‘GT MESSAGE’より上のレベルで割り当てられたメッセージ識別子は、（例えばＯＭＰ構成によって）、システムを通ってメッセージをルート設定することに関係する各ノードにおいて、別々に割り当ててもよい。
【００８３】
既に記載したように、いくつかのプロトコル層は要求整合システム内で参加しているノード間でＳＯＲメッセージを移動することに関係することが好ましい。例えば送信元のＢＳＡＰ110において、すなわち要求整合システム（トレーディングシステム）層において、要求定義および送り出しモジュール410は、ＯＭＰメッセージのＭＳＣ部分に含まれるＳＯＲをコード化するＯＭＰ構成を含み、ＯＭＰメッセージのＣＭＢ部分内に<MESS CONSUMER>としてこのＢＳＡＰ110からＳＯＲを受け取るように選定されたブローカ120を指名する。適切に規定および送り出しモジュール410またはＢＳＡＰのネットワークインターフェイス400は、通信ネットワーク205、例えばインターネット上で、ＳＯＲを指名されたブローカ120へ移動するために、ＨＴＴＰまたはＥメールメッセージ内のＯＭＰメッセージを適切に囲んでもよい。ターゲットブローカのＯＭＰ識別子から対応するインターネットドメイン名またはＩＰアドレスへの変換はＢＳＡＰ110内のＯＭＰとＨＴＴＰ／Ｅメール構成ととの間のインターフェイスにおいて、好ましくは適切なネットワークサーバ、例えばドメイン名サーバ（Domain Name Server, ＤＮＳ）上に常駐している第３の当事者が維持している変換表へのアクセスで実行することができる。類似のプロセスは送信方向のブローカにおいて実行するが、一方でＯＭＰ構成は要求整合システム全体で一貫しているが、異なるトランスポートレベルプロトコルを使用して、必要なときにシステム内の異なる対のノード間でメッセージを転送することができる。
【００８４】
指名されたブローカ120に到達するとき、ＳＯＲメッセージはブローカのネットワークインターフェイス200によって受け取られ、ＥメールまたはＨＴＴＰメッセージから“アンラップ(unwrap)”され、必要であれば、デコードされてもよい。ネットワークインターフェイス200および／またはブローカの要求整合およびルート設定モジュール210は、囲っている（エンクロージング）ＯＭＰメッセージから”GT MESSAGE”および“SOR”から抽出してもよい。次に整合およびルート設定モジュール210は、次の段落で詳しく記載するように、整合およびルート設定機能を実行してもよい。“ＳＯＲ”を送る送信先を識別するとき、ブローカは送信元のＢＳＡＰ110に関係して既に記載した動作の類似のトレーンを実行して、通信ネットワークにおいて次の指名された送信先へ移動する準備のできたＯＭＰおよびより低いレベルのメッセージフォーマットでＳＯＲを囲むことができる。
【００８５】
コード化する前に上述のＳＯＲのルート設定選択に対する整合に応答してブローカ120から生成されたＯＭＰメッセージのＭＳＣ部分を例示的に次に示す：
【表１４】
0004522583.tif 000015
【００８６】
【表１５】
0004522583.tif 000016
【００８７】
この例では、２つのＲＰ識別子はシステムを通るメッセージ経路を規定するように記載されている。
【００８８】
キーブローカ構成要素による詳細な記述
メッセージプロトコルおよびメッセージ通知の好ましい環境を規定して、ブローカ120のＲＭ＆Ｒモジュール210をより詳しく開示する。
【００８９】
ここで図２と図５のフローチャートとを参照して、要求整合およびルート設定モジュール210の動作における主要な機能段階を開示する。
【００９０】
段階505では、要求整合およびルート設定（ＲＭ＆Ｒ）モジュール210は、ネットワークインターフェイス200を介してＳＯＲを伝える到来メッセージを待機する。段階505においてメッセージを受け取ると、段階510においてＲＭ＆Ｒモジュールは１以上の検査を行って、メッセージが有効であることを保証する。例えばＲＭ＆Ｒモジュールは、（要求分類基準メモリ220が必要であるとき）有効な要求のタイプに関係してＳＯＲが特定されているメッセージ内に含まれていることを検査する。ＲＭ＆Ｒモジュールは、メッセージタイプが有効であること、特定のメッセージ源および特定の送信先がシステム内で知られており、メッセージヘッダの他の内容が有効であることも検査する。段階515において、段階510で行われた検査の結果としてメッセージが無効であることが分かると、段階565においてＲＭ＆Ｒモジュールは適切なエラーメッセージを生成し、段階505において新しいメッセージを待機する戻りを処理する前に、必要であれば、ネットワークインターフェイス200を介して特定のメッセージの送信元へそれを送ることができる。
【００９１】
段階515において受け取ったＳＯＲメッセージが有効であるとき、ＲＭ＆ＲモジュールはＳＯＲメッセージによって特定された要求と、ブローカのＲＰメモリ215内に記憶された登録されたルート設定選択内で特定された要求とを比較するように処理を進めることができる。段階525において整合しているＲＰが見付からないとき、段階570ではＲＭ＆Ｒモジュールは受け取ったＳＯＲメッセージをネットワークインターフェイス200を介して、所定のデフォルトの送信先−好ましくは雑多なＳＯＲメッセージの収集点として認識される別のブローカへ送ることができる。
【００９２】
段階525において整合しているＲＰが見付かると、段階530では整合している要求定義とＲＰの識別子とをもつＲＰ内で特定された送信先をＲＰメモリ215から読み取る。この情報を得ると、ＲＭ＆Ｒモジュール210は識別された送信先へ送る用意のできた受け取ったＳＯＲメッセージを更新しはじめることができる。とくに段階535では、ＲＭ＆Ｒモジュールは整合しているＲＰの識別子をメッセージ内の<RP id>リストへ加えることができ、新しいメッセージの受領者は、ブローカからメッセージの受領に成功することに責務を負うＲＰ登録を認識するようになる。さらに段階540では、ブローカのＯＭＰ識別子をＯＭＰメッセージ内の<MESS PATH>リストへ加えて、システムを通るメッセージの完全な経路を、メッセージが進むのにしたがってメッセージ内に記録することができる。最後に、段階545では、整合しているＲＰから読み取られ、好ましくはＯＭＰ識別子として表わされる送信先は、ＯＭＰメッセージの<MESS CONSUMER>要素内のメッセージに対する次の送信先として書込むことができる。受け取ったＳＯＲメッセージを更新すると、ＲＭ＆Ｒモジュールはメッセージを送り、段階550ではネットワークインターフェイス200を介して、特定の送信先へ送ることができる。段階555ではＲＭ＆Ｒモジュールは、要求されている別の整合に対してＲＰメモリ215をサーチし続ける。段階560では、別のＲＰが整合要求定義をもつことが分かると、ＲＭ＆Ｒモジュールは別の整合しているＲＰに対して段階530ないし555を繰り返し、更新されたＳＯＲメッセージを生成し、それをネットワークインターフェイス200を介して各送信先へ送ることができる。
段階560において、受け取ったＳＯＲメッセージに対して別の整合しているＲＰが見付からないとき、ＲＭ＆Ｒモジュール内の処理は段階505へ戻り、新しいＳＯＲメッセージの受領を検査する。
【００９３】
ルート設定選択の登録および修正
このルート設定選択の登録および修正では、他のブローカ120でＲＰを登録、修正、および削除する際に、ＲＰ登録によって使用するメッセージング方式を参照する。このルート設定選択の登録および修正では、このメッセージング方式に対するルート設定選択メッセージフォーマットを規定および記述する。このようなＲＰメッセージはＳＯＲを受け取るＳＳＡＰ115またはブローカ120によってＳＳＡＰに関しては、ユーザ（105）のそれに送ることができる。
【００９４】
ルート設定選択（ＲＰ）に関係するメッセージは、ＸＭＬ表記法を使用して他のメッセージタイプおよび上述のＳＯＲフォーマットと一緒に規定できることが好ましい。全てのメッセージはシステムの参加者間で、例えばＲＰ登録および更新モジュール225および440によって生成される適切なＯＭＰメッセージのメッセージに特定の内容（ＭＳＣ）として、特定のＲＰメッセージタイプを識別するための囲んでいる‘GT MESSAGE’要素によって特定される適切なメッセージタイプと一緒に伝えることができる。ＲＰを登録または更新するときに使用されるＳＯＲの明細は、例えばＳＯＲの’SOR SPECIFICATION’要素によって特定される適切な‘application(アプリケーション)’属性、すなわち”GT RP”によってＳＯＲを同報通信するものにおいて同様に区別することができる。
【００９５】
登録されたＳＯＲ  ＲＰ（215）は、参加者の関心を表わしている。ブローカ120はＳＯＲをＲＰに整合して、参加者に対して関心をもっているＳＯＲのみがその参加者に対して同報通信されることを保証する。関心をもっている参加者のポートフォリオは動的であってもよく、ブローカ120は変化と共に更新しなければならない。ＳＳＡＰ115およびブローカ120はユーザ（105）の必要にしたがって、通信ネットワーク205上で適切なＲＰメッセージを生成および送信することによって、自動的にＲＰを更新するようにイネーブルされることが好ましい
ＲＰメッセージを生成する能力を実行しないＳＳＡＰ115をサポートする際に、ブローカ120は、ＲＰ登録および更新モジュール225の制御のもとで、システムアドミニストレータによる管理機能として、ＲＰメモリ215におけるＲＰのマニュアルの登録および更新に対する手段を含むことが好ましい。
【００９６】
次のタイプのＲＰメッセージはＲＰ登録および更新モジュール225および440によって構成することができる：
メッセージ          コメント
RegisterNewRP        ブローカ上に新しいＳＯＲルート設定選択を登録する。
DeleteRP            ブローカ上に登録された既存のＲＰを削除する。
UpdateRP            ブローカ上に登録された既存のＲＰを変更する。
既存のＳＯＲの明細を新しいものと置換してもよい。
QueryRPs            ブローカから、要求者によって登録された全てのＲＰの
リストを要求する。
RPsAvailable        要求者にブローカ上の要求者によって登録された全ての
ＲＰのリストを送る。これはQueryRPsに対する応答である。
QueryRPDetails      ブローカから、要求者によって登録されたＲＰの詳細を
要求する。
RPDetails            要求者に対して、ブローカ上の要求者によって登録され
た
ＲＰの詳細を送る。これはQueryRPDetailsに対する応答
である。
Error                メッセージ内にエラーが発見されたときを、メッセージ
の
送信元へ送る。
次に上記の表に載せた各メッセージタイプの例を示す。各場合において、ＲＰ更新モジュール225および440は、ＯＭＰメッセージのＭＳＣ部分内のメッセージをコード化して、ブローカのＯＭＰ識別子を<MESS CONSUMER>として特定することができる。ＯＭＰは、<MESS CONSUMER>としての“ワイルドカード”識別子の使用をサポートして、囲まれたメッセージを個々のブローカ120へ特定的に方向付けるのではなく、ＳＳＡＰ115またはブローカ120によって、望むのであればシステム内の全てのブローカ120へ同報通信できることが好ましい。同報通信のRegisterNewRPメッセージを受け取ると、例えばブローカのＲＰ更新モジュール225は、“同報通信”メッセージに関係する所定の状況にしたがって、メッセージ内に含まれるＲＰを記憶するか否かを判断することができる。例えばＲＰ更新モジュール225は、そのブローカに特別に方向付けられたRegisterNewRPメッセージ内に囲まれたＲＰのみを記憶する方法を実行することができる。その代わりに、ＲＰ更新モジュール225は、より高度な判断方法を実行してもよい。例えば、ＲＰ更新モジュール225は同報通信のRegisterNewRPメッセージ内で伝えられる<SOR SPECIFICATION>と、ブローカ120の専門を規定する所定の<SOR SPECIFICATION>との比較を行ない、伝えられた<SOR SPECIFICATION>が整合しないメッセージ、または要求タイプの同じ階層内に少なくとも当てはまるメッセージを無視してもよい。このやり方では、ブローカがＳＯＲメッセージ内のブローカによって受け取られ難い要求に関係するとき、ブローカは特定のＲＰを記憶せず、したがって使用されていないＲＰでＲＰメモリ215を埋めてしまう潜在的な問題を避けることができる。
【００９７】
次の例では、囲んでいるＯＭＰメッセージの完全な構造が削除されている。
【００９８】
【表１６】
0004522583.tif 000017
【００９９】
【表１７】
0004522583.tif 000018
【０１００】
各”RequestNewRP”メッセージは、要求整合システム内の全てのメッセージに関係して、それを生成するＲＰ更新モジュール225または440によってシステム内の独特のメッセージ識別子M-GUIDに割り当てることができる。ＲＰ更新モジュール225または440は、唯一の参照RP-GUIDを、ブローカに登録される各新しいルート設定選択へ割り当てることができる。システム内で唯一であることを保証するために、M-GUIDおよびRP GUIDは各々、送信ノード（例えば、B GUID）の独特の識別子、次に各ＲＰモジュール225または440によって割り当てられた適切なシーケンス番号を含む。メッセージは、識別子B-GUID、好ましくはＯＭＰ識別子を特定し、登録を要求するブローカまたはＳＳＡＰへ割り当てることができる。メッセージはさらにルート設定選択として登録されているＳＯＲに対する識別子S-GUIDを特定することができ、これは例えばルート設定選択が１以上のＳＯＲを含むときに必要とされる。ＳＯＲ識別子は、ＲＰを生成するＲＰ更新モジュール225または440によって割り当てられることができ、例えば要求ノードのＯＭＰ識別子、およびこの後に適切なシーケンス番号を含んでもよい。ＳＯＲの妥当性およびＳＯＲの有効期限日を最後に確認した日付をメッセージ内に特定されたＳＯＲ内に含んでもよい。例えば中古車の供給者がＲＰによって現在在庫になっている個々の車を効果的に広告するとき、確認の日付が車の可用性を最後に確認した日付であるであるので、確認の日付は重要である。
【０１０１】
【表１８】
0004522583.tif 000019
【０１０２】
登録されたＲＰを削除するために、ＲＰ更新モジュール225または440は、削除されることになる前もって登録したＲＰの（独特の）識別子RP-GUIDを特定する。
【０１０３】
【表１９】
0004522583.tif 000020
【０１０４】
UpdateRPメッセージを受け取ると、ブローカのＲＰ更新モジュール225は、識別子RP-GUIDの現在登録されているルート設定選択が識別子S-GUIDのＳＯＲを含まないことが分かるとき、ＲＰ更新モジュール225はエラーメッセージをメッセージの送信元へ戻すか、または特定のＳＯＲをルート設定選択RP GUIDへ加えることができる。さもなければブローカは現在登録されているＳＯＲの定義を新しいものと置換してもよい。
【０１０５】
【表２０】
0004522583.tif 000021
【０１０６】
QueryRPメッセージを受け取ると、ブローカのＲＰ更新モジュール225は、要求者の識別子B-GUIDを含むルート設定選択に対してルート設定選択メモリ215を照会し、現在登録されているＲＰを含むRPAvailableメッセージをアセンブルすることができる。
【０１０７】
【表２１】
0004522583.tif 000022
【０１０８】
QueryRPsメッセージに応答して、ブローカの更新ＲＰモジュール225は、例えばＲＰメモリ215において要求者に対して現在登録されている４つのＲＰの識別子を含む上述のメッセージをアセンブルし、それを各QueryRPsメッセージの送信元へ送ることができる。各含まれているＲＰの完全な詳細を得るために、要求者は各ＲＰごとにQueryRPDetailsを提出することができる。RPsAvailableメッセージは、QueryRPDetailsメッセージと関係して、ＳＳＡＰ115および他のブローカ120、600によって使用されて、特定のブローカの専門を自動的に発見することができる。とくに、ＳＳＡＰ115は次のQueryRPDetailsメッセージに応答して戻される情報を使用して、そのユーザ（供給者）（105）の利益のために、ＲＰを登録する場所を自動的に判断することができる。
【０１０９】
【表２２】
0004522583.tif 000023
【０１１０】
QueryRPDetailsメッセージを受け取ると、ブローカの更新ＲＰモジュール225は識別子RP-GUIDの登録されたＲＰに対してルート設定選択215のメモリを照会して、そのＲＰの詳細を載せているRPDetailsメッセージをアセンブルして、要求者へ送ることができる。その識別子のＲＰが見付からないときは、ＲＰ更新モジュール225がエラーメッセージを要求者へ送ってもよい。
【表２３】
0004522583.tif 000024
【０１１１】
QueryRPDetailsメッセージを受け取ると、ブローカの更新ＲＰモジュール225は、例えばルート設定選択RP-GUIDに対してＲＰ215のブローカのメモリ内に現在記憶されている詳細を含む上述のメッセージをアセンブルすることができる。
【０１１２】
【表２４】
0004522583.tif 000025
【０１１３】
ブローカによって受け取られるメッセージ内にエラーが発見されると、受信モジュールによってエラーメッセージが生成され、メッセージの送信者へ戻すことができる。エラーメッセージは、検出されたエラーの性質にしたがって多数の所定のエラータイプの1つの識別子’UID’を特定することができる。エラータイプは、例えば要求分類基準メモリ220、415において、要求整合システム内の全ての参加しているノードにアクセス可能な参照メモリに記憶することができる。エラータイプは、所定のエラーオブジェクトおよび属性規定にしたがってＸＭＬフォーマットで表わされることが好ましい。
【０１１４】
その他のメッセージタイプ
別のメッセージタイプは、有用な情報に対して課金する方式を個々に使用するために規定することができる。
メッセージ          コメント
RequestDetails      供給者／購入者の詳細を送ることをブローカに要求する
UserDetails          供給者／購入者の接触の詳細
Receipt              メッセージの送信者へ送って、受信者によってメッセージ
の受領を知らせる
既に記載したメッセージと一緒に、上述のメッセージタイプの各々はＸＭＬ表記法を使用して、アクセス可能な参照メモリ内に記憶された全ての規定を定めることができる。特定のメッセージは、本発明に関係して記載した他の全てのメッセージタイプと類似のやり方で、適切なＯＭＰメッセージのＭＳＣ部分内のシステムの参加者間で伝えることができる。
【０１１５】
次の例は、上の表中の各メッセージに対して規定されたオブジェクトおよび属性の一般的なフォーマットおよび使用を示している。
【０１１６】
【表２５】
0004522583.tif 000026
【０１１７】
【表２６】
0004522583.tif 000027
【０１１８】
【表２７】
0004522583.tif 000028
【０１１９】
【表２８】
0004522583.tif 000029
【０１２０】
【表２９】
0004522583.tif 000030
【０１２１】
要求整合システム内で送られた’Receipt’以外の、好ましくは全てのメッセージは、対応する’Receipt’メッセージによって各メッセージの受領者によって知らせることができる。’Receipt’メッセージは、送信元のメッセージが到達したことを送信者に保証し、メッセージングの監査トレールを設定できるようにする。’Receipt’メッセージが戻されないときは、送信元のメッセージの送信者は送信元のメッセージを再び送ることができる。
【０１２２】
本発明の第２の実施形態に関係して、図６を参照して既に記載したように、ブローカ600は課金可能な情報抽出および支払いモジュール（Chargeable Information & Payment module）605および受け取ったＳＯＲメッセージから抽出された課金可能な情報を記憶するメモリ610を含んでもよい。供給者（105）は、上述の例で示したものに類似した’RequestDtails’メッセージを構成し、ブローカ600へ送ることによって、例えばブローカ600によって前もって引き出されたＳＯＲの送信元の詳細を要求することができる。ブローカ600は、送られたＳＯＲを囲っているＯＭＰメッセージ内に含まれている情報を使用して供給者（105）によって識別でき、例えば最後のブローカはＯＭＰメッセージの<MESS PATH>タグ内で識別される。ブローカのネットワークインターフェイス200によって’RequestDetails’を受け取ると、課金可能な情報抽出および支払いモジュール605ではメモリ610から抽出された送信元の詳細を読取り、上述の例で示したものと類似したやり方で、’UserDetails’メッセージを構成し、ネットワークインターフェイス200を経由して要求している供給者（105）へメッセージを送ることができる。既に記載したように、ブローカ600による’RequestDetails’メッセージの受領は、このような情報要求の各々に関係する供給者（105）による支払いをするための既知のシステムとリンクすることができる。
【図面の簡単な説明】
【図１】  本発明の好ましい実施形態にしたがってフレームワークを整合する要求をもつユーザおよび構成要素を示すダイヤグラム。
【図２】  本発明の第１の実施形態にしたがって要求を整合するブローカをもつネットワーク内で動作する要求を整合するブローカの主要な構成要素を示すダイヤグラム。
【図３】  本発明の実施形態において使用する好ましいルート設定選択のフォーマットを示すダイヤグラム。
【図４】  一般的なオペレーショナル要求整合フレームワークを示すダイヤグラム。
【図５】  本発明の実施形態の要求整合ブローカ内の要求整合およびルート設定モジュールの実行における主要な機能段階を示すフローチャート。
【図６】  本発明の第２の実施形態にしたがう要求を整合するブローカの主要な構成要素を示すダイヤグラム。
【図１】
0004522583.tif 000031
【図２】
0004522583.tif 000032
【図３】
0004522583.tif 000033
【図４】
0004522583.tif 000034
【図５】
0004522583.tif 000035
【図６】
0004522583.tif 000036