JP2003536170A

JP2003536170A - アノニマス・トレーディング・システムのためのアーキテクチャ

Info

Publication number: JP2003536170A
Application number: JP2002503741A
Authority: JP
Inventors: エドワード・アール・ホワーカ; ウラジミール・ネイマン; スティーブン・イアチェオ; ニーナ・ジャイン; ジェイムズ・シュ
Original assignee: エレクトロニック・ブローキング・サービシーズ・リミテッド
Priority date: 2000-06-23
Filing date: 2001-06-22
Publication date: 2003-12-02
Also published as: GB0101424D0; ZA200202210B; US8027895B2; US7937306B2; US20080120223A1; WO2001098968A2; EP1358598A2; US7366690B1; GB2366020B; GB2366020A; WO2001098968A8; US20080120377A1; GB2366020A8; CA2383130A1; AU8434201A

Abstract

(57)【要約】アノニマス・トレーディング・システムは、ブローカー・ノードのネットワークで構成される。各ブローカー・ノードは、同じ状態にあり、注文、初期取引、および分配価格にマッチできる。取引エージェントは、一部または全てのブローカー・ノードに接続されている。ネットワークは、一連のルールに従うように構成されており、好ましい具体例においては、ブローカーはクリーク・ツリーとして構成されている。

Description

【発明の詳細な説明】

【０００１】（技術分野）本発明は、外国為替や金融商品等の取引対象についての電子的なブローキング
・サービスを提供するコンピュータ・トレーディング・システムに関する。さらに
詳しくは、本発明は、入札(ビッド)、申込(オファー)、買注文、売注文に対して
サブミッションおよびマッチングを行なうネットワークに接続された複数のトレ
ーダー端末を有するコンピュータ・トレーディング・システムに関する。

【０００２】（背景技術）アノニマス・トレーディング・システムは、例えば、ヨーロッパ特許出願公報の
ＥＰ―Ａ−０，３９９，８５０、ＥＰ−A−０，４０６，０２６，ＥＰ−Ａ−０
，４１１，７４８において知られている。これらの公報は、外国通貨(または他
の金融商品)のアノニマス・トレーディングのための自動化されたマッチング・シ
ステムを開示する。このシステムにおいては、１つのホストコンピュータが、取
引、クレジット情報、および入札と申込に利用できるすべての取引情報の中央デ
ータベースを維持している。これらの取引等は、コンピュータネットワークを介
してホストに接続された端末から送信されたものである。ホストコンピュータは
、中央データベース内の情報を使用して、マッチング基準に基いて、入札と申込
、売注文と買注文とのマッチングを行なう。マッチング基準は、カウンター・パ
ーティのクレジット限度を含む。

【０００３】カウンター・パーティのクレジット限度は、各取引フロアで設定されて、ホス
トコンピュータに記録される。そして、ホストコンピュータは、カウンター・パ
ーティとなり得る各ペアに対して大まかな(gross) カウンター・パーティのクレ
ジット限度を設定する。このクレジット限度は、第１パーティから第２パーティ
、あるいは第２パーティから第１パーティへの残余クレジットの最低額である。
ホストコンピュータに接続された多様なトレーダー端末は、ホストコンピュータ
において利用できる情報の限られた一部分(例えば、最良の入札および申込)のみ
の維持および表示を行なう。

【０００４】このシステムにおいて問題が見つかった。それは、ホストコンピュータは、ク
レジット情報のみを使用して、潜在的なマッチングが確認された後で取引を進め
得るかどうかをチェックしていたことである。したがって、トレーダーは、潜在
的なカウンターパーティに対して自分がクレジットを有しているかどうかを、取
引に入る前に知ることができない。このような問題が発見され、それに対する解
決は、米国特許公報(ＵＳ−Ａ−５,３７５,０５５)において開示された。

【０００５】この米国特許公報に開示されたシステムにおいては、クレジット・マトリクス
が作成され、分配されたネットワーク内の複数の局地ノードに記憶されている。
各局地ノードは、特定セットのトレーダー端末にマーケット情報を送る。局地ノ
ードは、アクセスノードを介して、トレーダー端末に接続されている。この局地
ノードは、Market Distributorとして知られており、Market Access Nodeとして
知られたアクセスノードを介して接続されたトレーダー端末へと、取引可能な価
格情報を提供する。入札、申込、買注文、売注文の実際のマッチングは、Arbitr
atorとして知られた個別のノードによって提供される。

【０００６】我々は、上述した第１のホストシステム、および第２の分配システムのいずれ
についても問題を認識している。特に、コンピュータ・トレーディング・システム
は、トレーダーが異なる国に存在するグローバルな環境において、メッセージフ
ローを取り扱うことができるべきだと認識している。上述のホストシステムにお
いては、トレーダー端末間のメッセージは、１つのホストコンピュータに届ける
ために、不必要に大きな距離を伝達しなければならない。このようなことは、取
引がしばしば破断する場合に顕著である。取引が破断するのは、トレーダーが、
自分がクレジットを有しない他のトレーダーが送信したクォート(quote)から引
き出された表示価格を"ヒット(hit)"しようとするからである。第２の分配シス
テムでは、クレジット適合性のために価格を予めスクリーニングすることで、メ
ッセージ伝達の負担が減じられている。しかしながら、それでもメッセージは、
ArbitratorノードとMarket Distributorとの間を流れなければならず、これによ
って、利用できるマーケットに対するトレーダーの視野と、マッチングのために
現実に利用できるマーケットと、を一致させなければならない。

【０００７】メッセージがシステム内を通過するのに要する時間という観点では、より完全
に分配されたシステムへと移行するのが望ましいと我々は認識している。そのシ
ステムにおいては、マッチングは、１つの中央ロケーション、または少数の中央
ロケーションのうちの１つにおいては、行なわれない。そのような分配システム
においては、ネットワーク内でのメッセージフローが非常に重要となり、余分な
メッセージ送信を減じることが必須となる。

【０００８】分配システムにおけるストリームライン化されたメッセージフローの必要性を
我々は特に認識している。

【０００９】（発明の概要）広い意味において、本発明は、１セットの規則に従ってノードが互いにメッセ
ージを通過させ、情報の流れの重複を防ぐコンピュータ・トレーディング・システ
ムを提供する。

【００１０】特に、代替可能商品を取引するためのコンピュータ・トレーディング・システム
が提供される。このシステムは、取引に関する情報を含む取引情報メッセージを
伝達するためのコミュニケーション・ネットワークと、上記ネットワークに接続
されていて、オーダーを含む価格クォーテーション・メッセージを発生する、複
数のオーダー入力装置と、ある配信構成において上記ネットワークに接続されて
おり、ネットワーク全体に渡って取引情報メッセージを配信するように構成され
た複数のノードと、を備えている。ノード間でのメッセージ配信は、当該ノード間のカノニカル・パスを通して行
なわれる。カノニカル・パスとは、一対のノード間における最良の経路である。このシステムにおいては、 i) 与えられた２つのノード間のカノニカル・パスは、可換性である。 ii) 与えられた２つのノード間のカノニカル・パスは、１または２以上のさらな
るノードを含んでおり、当該さらなるノードと前記２つのノードのそれぞれとの
間におけるカノニカル・パスは、与えられたノードとさらなるノードとの間にお
けるサブパスと同一であって、それが与えられたノード間におけるカノニカル・
パスの一部を構成している。 iii) 各ノードとそれ自身との間のカノニカル・パスは、エンプティである。

【００１１】上記ノードは、複数のクリークとして構成されていて、各クリークは、論理接
続された複数のノードを含んでいて、１つのクリークにおける各ノードは、その
クリーク内の他の全てのノードと接続されていて、すべての２つのクリークは、
単一のパスで接続されていて、その結果、複数のノードがクリーク・ツリーを構
成している、ことが好ましい。

【００１２】クリーク・ツリーを使用すると、ノード間のカノニカル・パスに関する３つの条
件に適合する素晴らしいネットワーク・ソリューションを提供できる。与えられ
た１つのノードは、隣接する２つのクリーク内に存在してもよいが、単一のパス
が２つのクリークを接続する。

【００１３】各ノードは、オーダーのマッチング、取引の実行、およびプライス・ディスト
リビューションを行なう機能を備えたブローカーであることが好ましい。

【００１４】（好ましい具体例の説明）具体化されたシステムの目的は、トレーダーがクォート(quote、値付け、相場
、見積もり)およびオーダー(order、注文)をエンターすることを可能にし、これ
らのクォートおよびオーダーのマッチングをシステム内で行なうことである。こ
のシステムは、少なくとも次の商品：FX Spot、FRA、Forward(FX Forwardを含む
)、CFDs、短期政府および(または)中央バンクペーパー、商業手形、CDs、銀行間
預金、コマーシャルペーパー、repos、金利先物、スワップ、オプション、およ
びこれらを基本とするテーラーメイド商品；を取引するためのプラットフォーム
を提供する。これら全てを金融商品と呼ぶ。

【００１５】トレーダー端末に向かうトレーダーは、クォートとヒット(hit)を送信する。
これらは、システム全体に渡って、複数のブローカー・ノードのそれぞれに対し
て送られる。クォートとは、トレーダーがマーケットを作るために送信した入札
(ビッド)または申込(オファー)であって、マーケット・ビューとして他のトレー
ダーに配信される。

【００１６】このように、クォートは、他のトレーダーに見える注文(オーダー)である。ヒ
ットとは、売注文または買注文であって、それらは、マーケット・ビューに表示
された１または２以上のクォートに由来する価格に基いて取引を行なうことを希
望するトレーダーによって送信されたものである。ヒットは、他のトレーダーに
は見えない注文である。図１のコンピュータ・トレーディング・システムは、複数
の取引エージェント１０を含む。各取引エージェント１０は、複数のブローカー
・ノード１２のうちの少なくとも１つに接続されている。各取引エージェントは
、トレーダー端末がトレーディング・システムにアクセスするための手段であっ
て、オーダー入力装置の一具体例である。

【００１７】具体化されたシステムにおいて、各ノードは、後述する機能を有するブローカ
ー・ノードである。しかしながら、疑いを避けるべく注意すべきことは、すべて
のノードがブローカー・ノードとしての機能を備える必要はない、ということで
ある。１または２以上のノードがメッセージ配信ノードとして機能してもよい。

【００１８】トレーダー端末(図示せず)は、クォートおよびオーダーを送信でき(通常は、
特別なキーパッドが使用される)、マーケット・ビュー・データを表示できる、ワ
ークステーションまたは他のコンピュータ端末であってもよい。マーケット・ビ
ュー・データには、取引される金融商品について有効な、価格および数量が含ま
れる。一般的に、トレーダーは、例えば銀行等の金融機関の一部としてグループ
化され、これにより、トレーダーはトレーディング・フロアの一部とされる。ト
レーディング・フロアは、共通の管理者の統制下にあるトレーダーのグループで
ある。トレーディング・フロア管理者は、トレーディング・フロアに対して、他の
トレーディング・フロアに対する貸出限度(クレジットライン)を割り当てる。ト
レーダーまたはトレーダーグループのためのマーケット・ビューは、マーケット
情報(価格、量、その他)であって、トレーダーはマーケットを反映したものとし
て理解している。マーケット・ビューは、クレジット適合性のために、予めスク
リーニングされていることが好ましい。

【００１９】具体化されたシステムは、アノニマス・トレーディング・システムである。ブロ
ーカーによって作成されるマーケット・ビューは、価格および量の情報を含むが
、その価格の根拠は示されていない。有効な入札(ビッド)および申込(オファー)
に対して表示された価格、およびその価格において有効な量が集まって、１また
は２以上のクォートとなる。予めスクリーニングされたクレジット基準を満たす
パーティのクォートだけが、表示される価格に含まれる。このように、ブローカ
ー・ノードによって作成されたマーケット・ビューは、クレジット割当に応じて、
トレーディング・フロア毎に異なる。

【００２０】取引エージェント・ノードは、特定のトレーディング・フロアまたはトレーダー
グループに対してサービスを提供する。これらのサービスは、各取引ワークステ
ーションによるネットワークへのアクセスを提供すること、取引を完結させるこ
と、取引チケットを作成すること、およびトレーダーのために取引情報の履歴を
維持すること、を含んでいる。トレーディング・システムにアクセスするために
、各取引エージェント・ノードは、少なくとも１つのブローカー・ノードに接続さ
れていなければならない。こうして、トレーダー端末のグループが取引エージェ
ント１０に接続されて、システムにアクセスする。

【００２１】上述したクリーク（相場操縦仲間）ツリーは、マルチ・ブローカー・トレーディ
ング・システムを構成するための一般的原理の一具体例である。

【００２２】１セットのブローキング・ノードから始まって、そのノードの幾つかの間にリ
ンクが作られ、グラフが形成される。このグラフにおいて、ブローキング・ノー
ドが頂点であり、リンクはグラフの端部である。グラフは、連結されるものと考
えられる。すなわち、ノードの各ペア間にはパスが存在すべきである。

【００２３】上述のグラフは、"カノニカル・パス(canonical path)"と呼ばれる追加的な構
造を有する。より厳密には、ノードＡとノードＢとの各ペアに対して、ＡとＢと
の間に１つのパスが選択され、これが"カノニカル・パス"と呼ばれる。"カノニカ
ル・パス"は、メッセージを送信するために、おそらく最良の通路であると説明さ
れるであろう。説明されるメッセージフローのパターンは、ルートメッセージへ
のカノニカル・パスを常に使用しているであろう。

【００２４】上述のカノニカル・パスは、次の条件を満たすことが要求される。（ａ）（Ａ_１、Ａ_２、・・・、Ａ_ｎ）がＡ_１とＡ_ｎの間のカノニカル・パスである
ならば、（Ａ_ｎ、・・・、Ａ_２、Ａ_１）は、Ａ_ｎとＡ_１の間のカノニカル・パスであ
る。（ｂ）（Ａ、・・・、Ｂ、・・・、Ｃ）がＡとＣの間のカノニカル・パスであるなら
ば、そのサブパス（Ａ、・・・、Ｂ）および（Ｂ、・・・、Ｃ）は、それぞれ、（Ａお
よびＢ）および（ＢおよびＣ）の間のカノニカル・パスである。（ｃ）各ノードおよびそれ自身の間のカノニカル・パスはエンプティ(empty)で
ある。（この規則は、(ｂ)と相俟って、カノニカル・パスはループを含まないと
いうことを保証する。）

【００２５】別例として、カノニカル・パスは、次のようにして定義できる。すなわち、リ
ンク上での第１の幾つかの距離(例えば、リンク・レーテンシー)を定義し、次に
、リンクの距離値の最小の和を有するパスとして(レーテンシーを伴なう例にお
いては、それは、最小のトータルレーテンシーを有するパスであろう)、カノニ
カル・パスを定義する。最小和の値が同一である幾つかのパスが存在する場合に
は、やや注意を要する。すなわち、さらに１つを選択しなければならず、この選
択は、すべてのパスについて、条件(ａ)および(ｂ)が満たされるように、一貫し
て行なわなければならない。

【００２６】以下の議論は、カノニカル・パスを定義する特別の方法のいかなるものにも基
いてはいない。それらは、定義されたものと仮定しておけば十分であって、それ
らが上述の条件(ａ)、(ｂ)、および(ｃ)を満足していれば十分である。

【００２７】ノードＡおよびノードＢがリンクによって接続されているが、そのリンクがＡ
とＢ間におけるカノニカル・パスではない場合、そのリンクは、メッセージを送
信するのには使用されない。カノニカル・パスは、メッセージを送る最良の通路
であると常に仮定されているからである。このように、カノニカル・パスではな
いリンクを有することに優位性はない。そのようなリンクは、いかなるメッセー
ジ通路の変更をも伴なうことなく、グラフから削除することができる。各リンク
はそれが連結するノード間のカノニカル・パスでなければならないという追加的
な条件は、カノニカル・パスに関する上述の条件のリストには含まれていなかっ
た。そのような条件は、必要ないからである。しかしながら、実際には、その条
件は、多分満足されているであろう。

【００２８】ノードＡについて考え、そしてノードＡから他のすべてのノードへのすべての
カノニカル・パス、およびこれらのカノニカル・パスとして使用されるすべてのリ
ンクについて考える場合、これらのリンクがツリーを構成することは簡単に証明
できる。我々は、このツリーをＡによって生成されるツリーと呼び、ツリー(Ａ)
と表示することができるだろう。Ａへの、またはＡからの、すべてのメッセージ
は、このツリーに属するリンクを通して送られる。

【００２９】図１に戻ると、説明される論理アーキテクチャは、クリーク・ツリー(clique t
ree)であること、および各ノード間のパスは、カノニカル・パスであるように選
択されていること、が理解できるだろう。このようなクリーク・ツリー構造は、
上述のグラフ上でノード間のカノニカル・パスに関する３つの条件を満足する。

【００３０】各ブローカー・ノード１２は、基本的なオーダー・マッチングおよびプライス・
ディストリビューション・サービスを提供する。ブローカー・ノードは、クリーク
・ツリー内において、非常に特殊でしかもシンプルな規則に従って、迅速なコミ
ュニケーションの循環を可能とするように構成されている。クリーク・ツリーは
、ネットワーク構造であって、そこでは、各ノードがクリーク毎にグループ化さ
れていて、複数のクリークがツリー構造を構成している。各ブローカーは、多数
のブローカーと論理的にリンクすることができる。それらのブローカーは、その
隣接ブローカーと呼ばれる。ブローカー間のコミュニケーションは、ネットワー
ク内において"上"または"下"の方向性なく、同一レベルで行なわれる。

【００３１】取引エージェントは、少なくとも１つのブローカー・ノードに接続されていな
ければならないが、それら自身は、クリーク・ツリーの要素ではなく、その構造
の外側に在る。複数のブローカー・ノードに接続された取引エージェントは、複
数セットのマーケットプライスを受け取る。異なるブローカー・ノードからの価
格情報は実質的に同一であろうが、情報は異なるインターバルで受け取られる。
取引エージェントは、与えられた取引オーダーをただ１つのブローカー・ノード
に送る。

【００３２】図１に示したシステムにおいては、３つのクリークＡ、Ｂ、およびＣが存在す
る。クリークＢは、３つのブローカー・ノード２、５、６を含む。クリークＡは
、４つのブローカー・ノード１、２、３、４を含む。クリークＣは、２つのブロ
ーカー・ノード４、７を含む。１つのブローカー・ノードが２つのクリークに所属
できることが分かるであろう。ブローカー・ノード２は、クリークＡおよびクリ
ークＢの一部分であり、ブローカー・ノード４は、クリークＡおよびクリークＣ
の一部分である。図１の構造がカノニカル・パスに関して上述した条件(ａ)、(ｂ
)、および(ｃ)に従っていることは容易に理解できる。

【００３３】いずれの２つのクリーク間にもただ１つのパスが存在することとなるように、
クリークがツリー構造内に配置されている。そして、隣接するクリークは、共通
するノードをただ１つ有していることが分かるであろう。このように、ノード２
およびノード４は、それぞれ、クリークＡとＢとにおける、あるいはクリークＡ
とＣとにおける、唯一の共通ノードである。

【００３４】ブローカー・ノードがクリーク内に配置されているので、ツリーを上るコミュ
ニケーション、あるいはツリーを下るコミュニケーション、といった概念は存在
しない。ブローカー・ノードは、１または２以上の隣接ブローカー・ノードとの間
に論理リンクを有していて、これらの隣接ブローカー・ノードのぞれぞれと同一
ベースでコミュニケーションを行なう。あるブローカー・ノードがその隣接ブロ
ーカー以外のあらゆるブローカー・ノードについて知る必要はない、ということ
が本システムの重要な特徴である。これにより、ブローカー・ノードをシステム
に追加したり、システムから除去したりすることが、非常に簡単にできる。ブロ
ーカー・ノードが１または２以上のクリークの要素であるので、隣接ブローカー
が自身のクリークの要素であるかどうかを知ることが必要となる。１つのブロー
カーが１以上のクリークの要素となり得るが、与えられた隣接ブローカーとの間
ではただ１つのクリークを共有するのであろう。

【００３５】ブローカー・ノードなる語は、ブローキング機能を提供するコンピュータネッ
トワークにおいて、物理的または論理的ノードとして配置されたコンピュータを
説明するのに使用される。基本的なブローキング機能は、クォートを記憶するこ
と、クォートをトレーダーにマーケット・ビューの形態で提供すること、および
クォートとオーダーとをマッチングさせることである。説明した具体例における
ブローカー・ノードは、さらに別の機能も実行するが、それらはブローカー・ノー
ドを規定するための本質的な特徴ではない。

【００３６】各ブローカー・ノードは、互いに同等で、同一の機能を実行する。ネットワー
クの構成またはネットワーク中での位置は、ブローカー・ノードに対してトラン
スペアレントである。ブローカー・ノードは、自身に対する隣接ブローカーにつ
いてだけ知っていればよい。各ブローカー・ノードは、そのマーケットにおける
すべてのオーダーを把握していて、オーダーが送信されるとすぐにそのマッチン
グを行なうことができる。各ブローカー・ノードがそのマーケットにおけるオー
ダーの完全なリストを維持しているので、取引エージェントが必要としている場
合にマーケット・ビューをカスタマイズすることができ、マーケット情報を受け
取るとすぐに、それに迅速に反応することができる。

【００３７】ノード間でメッセージをやり取りする方法を説明する。情報交換の単位は、メ
ッセージである。１つのメッセージは、常に、多数の配信パターンのうちの１つ
を用いて送られる。

【００３８】各メッセージは、次のルーティング情報を記憶していなければならない。（ａ）そのメッセージが送られた配信パターン。受信ノード上でのそのメッセー
ジのプロセッシングは、ターゲット・メッセージおよびブロードキャスト(一斉送
信)・メッセージによって異なるであろう。しかしながら、複合配信パターンの一
部としてシンプルなパターンが呼び出された場合、受信ノード上のプロセッシン
グは、その複合パターンには依存しないし、その複合パターンについての情報は
、メッセージの一部である必要はない。さらに、シンプルなパターンの"ブロー
ドキャスト"および"排除(exclusion)を伴なうブロードキャスト"は、排除された
ノードのほとんどについて、受信ノード上での同一のメッセージ・プロセッシン
グを有する。このように、排除メッセージを伴なうブロードキャストは、ブロー
ドキャスト・メッセージとして出現する。そのメッセージは、それがターゲット・
メッセージまたはブロードキャスト・メッセージであるかどうかを記憶しておく
だけでよい。

【００３９】（ｂ）１つのノードは、送信されたリクエスト中で特定されたものであった。タ
ーゲット・メッセージに対して、それは、目的地ノードである。また、ブロード
キャスト・メッセージに対して、それは、ブロードキャストのルート(root)であ
る。この情報は、必要に応じてさらにメッセージを送るために、受信ノード上で
も必要とされる。

【００４０】（ｃ）さらに、各メッセージは、次の３つのルーティング・フラグのうちの１つ
を含んでいなければならない。

【００４１】バイパス(bypass) これは、そのメッセージが最終目的地に対してのみ配信されるべきことを意味
している。

【００４２】インスペクション(inspection) これは、そのメッセージがソースから目的地までのパス上にある各ノードに対
して配信されるべきことを意味している。"インスペクション"なる語は、途中に
ある各ノード上のアプリケーションがそのメッセージを検閲する機会を有するも
のとして使用される。

【００４３】インターセプション(interception) これは、そのメッセージが実際には、ソースから目的地までのパス上において
最初のノードに対してのみ配信されたことを意味している。そのメッセージは、
アプリケーションに渡され、さらに送信する必要がある場合には、再度送信され
る。そのアプリケーションは、必ずしもそのようにする必要はない。インターセ
プション(中断)・ルーティング・フラグとともに送られたメッセージは、途中にあ
るノードのうちの１つのアプリケーションがそれを送信しないことを選択した場
合には、その目的地までは送信されない。

【００４４】アルゴリズムの説明それぞれの配信パターンは、送信ノード（シンプルパターンのみ）及び受け取
りノードのメッセージ・プロセッシング・アルゴリズムで説明される。アルゴリ
ズムの記述は、通常多くのステップを備えている。確実なステップが「イグジッ
ト」でなければ、アルゴリズムのすべてのステップのそれぞれのメッセージにつ
いては、シーケンス内で実行され得るべきである。「イグジット」は、シーケン
スステップがこのメッセージのために実行されないことを意味する。

【００４５】例えば、Ｄが現在のノードではない場合に、以下のような単純なアルゴリズム
がＭからノードＤにメッセージを送る。・Ｄが現在のノードでない場合はイグジットする。・ＭからＤにメッセージを送る。

【００４６】分布したブローカー・ノードの配布、値段分布、配信実行の目的を理解するた
めに、図２を参照して説明する。

【００４７】配信プロセスは、１又はそれ以上のトレーダーがトレーダーターミナル内へ注
文の送信を行うことから開始する。注文は、トレーダーからの配信要求であり、
価格や量などの特定の制限を有した売買の指示である。相場は、システム内で用
いられつづける永続的な注文であり、市場価格情報の一部として分布される。相
場は、「市場を作る」ために用いられ、ビッド又はオファーとしてトレーダーに
通知される。ヒットは、「隠れた」及び「充填した」又は「消された」プロパテ
ィを有する注文である。日とは、市場価格の一部として配布されない。ヒットは
、もしそれが配信できなければシステム内に残らず、もし入ればリムーブされる
。

【００４８】注文控え帳は、市場内で用いられる注文のすべてのリストである。相場が用い
られるだけの注文であるから、控え帳はクォートのリストを構成する。クォート
は、現在の取引注文内で配列する。待ち行列の注文のソートは、異なる取引の指
示によって変化する。デフォルトのソートの順は価格及び時間に従う。システム
内では、それぞれのブローカー・ノードは使用可能なクォートのすべての完全な
リストを持続する。

【００４９】システム内のメッセージフローは、メッセージと呼ばれて記述され、それぞれ
実行される適当なパラメータはネットワークを通して実行される。取引エージェ
ントがトレーダーのワークステーションからトレーダーがビッド又はオファーを
行なったという情報を受け取ったとき、クォートの送信のプロセス（永続的なプ
ロセス）が開始する。次いで、取引エージェントは、クォート送信プロセスを開
始する。取引エージェントはトレーダーのワークステーションからクォートの情
報を受信したとき、クォートのためにコンテクストを創作し、これを維持する。
次いで、クォート送信メッセージが接続されたブローカー・ノードに送られる。
それが妥当なものであれば、ブローカー・ノードはクォートを有効にし、受け入
れる。クォートを受け取ったこの第１のブローカーはこのクォートについて「オ
ーナー」ブローカーとなる。図２に示す例では、これはブローカー・ノード５で
ある。これは配信のクォートを委託することができるブローカー・ノードに限ら
れる。ブローカー・ノードはコンテクスト又は「クォート対象」を創作し現在の
取引可能な注文のためにそれを待ち行列内に組み込む。

【００５０】クォートが配列内に配置されたあと、オーナーブローカー・ノードは、次にネ
ットワークを通じてクォート利用メッセージを他のブローカー・ノードに送るこ
とによってクォートを配信する。この例では、ブローカー・ノード５はクォート
利用可能もうメッセージをブローカー・ノード２及び６に送る。それぞれのブロ
ーカー・ノードは、当該メッセージを受信し、コンテクスト（クォート対象）を
作成し、これをその配列（注文控え帳）内にソートする。それは、ブローカー・
ノードがメッセージを送ったコンテクスト内に書きとめられる。メッセージが配
列内に配置されたあと、次いでブローカー・ノードはクォート利用可能メッセー
ジを一斉送信配達ルールを利用することにより他のクリーク内のすべての隣接者
に送付する。したがって、ブローカー・ノード２はメッセージを１、３及び４に
送付する。次いで、ブローカー・ノード４はメッセージをブローカー・ノード７
に送付する。この点において、すべてのブローカー・ノードはクォートについて
知ることができ、結果的にそれぞれの注文控え帳を更新することができる。

【００５１】メッセージ配信ルールはネットワークの混雑を効果的な方法で処理し、メッセ
ージの流れの重なりを減少させることができる。以下、シンプルなメッセージパ
ターン及び複合的なメッセージパターンについて説明する。

【００５２】シンプルメッセージパターン標的配信パターン標的配信は、メッセージが特定のネットワークノードに送られる必要がある場
合に用いられる。

【００５３】用法：ｔａｒｇｅｔＳｅｎｄ（Ｍ，Ｄ）

【００５４】パラメータＭは送信されるメッセージである。Ｄは例えば、メッセージの目的地などの標的ノードである。

【００５５】前提条件：Ｄは送信ノードと異なる。

【００５６】送信ノードにおけるアクション：Ａが送信ノードである場合及び（Ａ，Ｂ・・・，Ｄ）がＡからＤのカノニカル
・パスである場合，すなわち、Ｂは、このパス上の最初のノードにおいてＡの後
の最初のノードである場合は、アクションはＭからＢに送られる。

【００５７】受け取りノードにおけるアクション：このノードがメッセージの標的である場合は、適用するメッセージを配送しイ
グジットする。メッセージが中断フラグを有している場合は、適用するメッセージを配送しイ
グジットする。メッセージが閲覧フラグを有している場合は、適用するメッセージを配送する
。ｔａｒｇｅｔＳｅｎｄ（Ｍ，Ｄ）を実行する。

【００５８】これにより、メッセージがソースから目的地までのカノニカル・パスにより最
終目的地まで送信される。このパターンを実行するために、送信ノードは目的地
までのカノニカル・パス上の第１のリンクを知らなければならない。この相関関
係の効果的な実行のために、送信ノードは送信ノードの隣接者の１つに含まれる
それぞれの潜在的なこの目的地へのカノニカル・パスにおける第１の目的地ノー
ドの位置を示したテーブルを保持する。

【００５９】一斉送信配信パターン一斉送信配信パターンは、メッセージがネットワーク内のすべてのノードに配
信される必要があるときに用いられる。これは、メッセージを明確なノードの部
分集合に配信するときにも使用可能である。

【００６０】用法：ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）

【００６１】パラメータ：Ｍは送信されるメッセージである。Ｒは一斉送信のルートである。メッセージはツリーに属するリンク上に送信さ
れる。

【００６２】前提条件：なし

【００６３】送信ノードにおけるアクション：Ａは送信ノードである場合は、アクションは以下の条件を双方ともに満足する
すべてのノードＮに送信することである。ＮはＡの隣接者である。ＮからＲヘのカノニカル・パスはリンク（Ｎ，Ａ）とともに開始する。

【００６４】受け取りノードにおけるアクション：適用するメッセージを送信する。メッセージが中断フラグを有しているときは、その後イグジットする。ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）を実行する。

【００６５】一斉送信配信のためには、明確に特定された目的地は存在せず、メッセージが
常にメッセージを受けるすべてのノードに配送される。ゆえに、バイパスルーテ
ィングフラグは一斉送信の配信には用いられるべきではない。中断フラグはメッ
セージを一斉送信するために許容される。中断ルーティングフラグとともに送ら
れるメッセージは、閲覧ルーティングフラグとともに送られるメッセージを到達
されるすべてのノードに到達する必要がない。このパターンの実行のために送信
ノードＡは、ノードＲへのカノニカル・パス上のノードＡを有するすべての隣接
者リストを知る必要がある。ＮからＲまでのカノニカル・パスがリンク（Ｎ，Ａ
）とともに開始されるＡの隣接者（Ｎ）のリスト中のノード（Ｒ）を示したテー
ブルが保持されることが好ましい。

【００６６】多くの場合、Ｒは情報の発信源である。しかし、これは必要とされるものでは
なく、ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）はＲを起源とする物ではなく情報のために
用いられる。ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）がＲ上で実行され、メッセージが閲
覧ルーティングフラグを有している場合は、その後メッセージはネットワーク中
のすべてのノードに配送され、それぞれのノードへ一度に配送される。ｂｒｏａ
ｄｃａｓｔ（Ｍ，Ｒ）がＲと異なるノードＡ上で実行される場合は、一斉送信は
、ツリー（Ｒ）中の明確な下位のツリーにのみ到達される。より厳密には、ツリ
ー（Ｒ）中のＢからＲまでのパスに属するＡのようなすべてのノードＢを構成す
るツリー（Ｒ）中の「サブルート」を有する下位のツリーである。メッセージは
それでも一度にそれぞれのノードに配送される。

【００６７】排除を伴なった一斉送信配信パターン配信排除を伴なった一斉送信パターンはいくつかのメッセージが、ツリー（Ｒ
）中の明確な下位のツリーを除くネットワーク中のすべてのノードに配送される
必要がない場合に利用される。

【００６８】用法：ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ，Ｓ）

【００６９】パラメータ：Ｍは送信されるメッセージである。Ｒは一斉送信のルートである。メッセージは、ツリー（Ｒ）に属するリンク上
に送信される。Ｓは一斉送信が送られる特定の方向のノード又は無効である

【００７０】前提条件：Ｓは送信ノードと異なるノードであるか又は無効である。

【００７１】送信ノードにおけるアクションＡが送信ノードである場合は、アクションは以下の条件を満たすすべてのノー
ドにＭを送ることである。ＮはＡの隣接者である。ＮからＲへのカノニカル・パスはリンク（Ｎ，Ａ）とともに開始する。Ｓが無効でない場合は、ＡからＳへのカノニカル・パスは、リンク（Ａ，Ｎ）
とともに開始しない。

【００７２】受け取りノードにおけるアクション：適用されるメッセージを配送する。メッセージが中断フラグを有している場合はその後イグジットする。ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）を実行する。

【００７３】一斉送信配信パターンは排除を伴なった一斉送信配信パターンの特別なケース
である。いいかえれば、ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）はｂｒｏａｄｃａｓｔ（
Ｍ，Ｒ，ゼロ）と等価である。すなわち、一斉送信パターンに関してしたコメン
トは、一斉送信が到達するネットワークの一部に関してのコメントを除いて、排
除を伴なった一斉送信パターンにもあてはまる。

【００７４】排除を伴なった一斉送信は、最初のレグにおける一斉送信と異なるのみである
。２次的なレグについては、排除を伴なった一斉送信は通常の一斉送信パターン
を用いる。双方のケースにおいて受け取りノードは同じであるから、メッセージ
が一斉送信又は排除を伴なった一斉送信を用いて送信されるかどうかについての
メッセージの情報を含む必要がない。ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ，Ｓ）のメッ
セージは、ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）とＡ（送信ノード）がＳからＲのカノ
ニカル・パスに属することのみにおいて異なる。ＡがＳからＲへのカノニカル・
パス上にない場合は、排除を伴なわない一斉送信ですらメッセージをＳに向けて
送信するものではないから、他のすべての点では、ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ
，Ｓ）は、ｂｒｏａｄｃａｓｔ（Ｍ，Ｒ）と同じである。

【００７５】複合的なメッセージパターンいくつかの複合的なメッセージパターンについて説明する。

【００７６】複合的なメッセージパターンは、いくつかのメッセージについて、上述したシ
ンプルメッセージパターンの一つにしたがった配信で、それぞれの同時に配信す
ることと説明できる。複合的なパターンは、メッセージをより正確で有益な記述
で配信することができる。例えば、取引申し込みのメッセージは、単独で標的配
信パターンに従う。しかし、それは常にマーケット更新一斉送信を発生させる。
複合的なパターンが存在することにより、「一斉送信を伴なった標的配信」は、
取引申し込みメッセージだけでなく一斉送信メッセージの発生の流れとしても捕
らえるような後述するこのパターンとして取引申し込みメッセージとして説明す
ることができる。

【００７７】複合的なパターンの説明は、受け取りノードにおけるアクションを除いてシン
プルパターンの説明としての同じ要素を含む。これは、メッセージが、特別な複
合−パターン−関連プロセッシングが受取ノードにおいて発生しないであろう送
信する複合的なパターンについて情報を保持しないからである。すべての受け取
りノードプロセッシングはそれぞれのシンプル配信パターンによって決定される
。

【００７８】複合的なパターンにおける送信ノードのプロセスは常にいくつかのシンプル配
信パターンの呼び出しを必要とする。プロセッシングの説明においてそれらは確
かな注文中に呼び出されるであろうが、注文は重要ではなくシンプルパターンの
呼び出しが同時に行なわれる。

【００７９】ルートに向けた一斉送信を伴なった標的配信パターンルートに向けた一斉送信を伴なった標的配信パターンは、従の一斉送信の発生
を伴なった標的情報が用いられる。標的メッセージはルート、一斉送信のルート
であるノードＲに向けて送信される。このパターンは標的パターン及び排除を伴
なった一斉送信配信パターンの組み合わせである。

【００８０】用法：ＴａｒｇｅｔＡｎｄＢｒｏａｄｃａｓｔＴｏＲｏｏｔ（Ｍ_１，Ｍ_２，Ｒ，Ｓ）

【００８１】パラメータ：Ｍ_１は標的配信パターンで送信されるメッセージである。Ｍ_２は一斉送信配信パターンで送信されるメッセージである。Ｒは一斉送信のルート及び標的メッセージの目的地である。標的メッセージは
Ｒ（すなわち、「仕向けルート」とよぶ）に送信され、一斉送信メッセージはツ
リー（Ｒ）に属するリンク上において送信される。Ｓはこの一斉送信（通常この情報の発生源であるかすでに情報が通過したパス
上に存在する）の必要がないノードであるか、無効である。

【００８２】前提条件：Ｒは送信ノードと異なるＳは送信ノードと異なるか又は無効である。Ｓが無効でない場合は、送信ノ
ードはその後ＳからＲｈｅｎｏ標準パス上に存在するであろうノードに送信する
。

【００８３】送信ノードにおけるアクション：ｔａｒｇｅｔＳｅｎｄ（Ｍ_１，Ｒ）を実行する。ｂｒｏａｄｃａｓｔ（Ｍ_２，Ｒ，Ｓ）を実行する。

【００８４】ルートに向けたの一斉送信を伴なった標的配信パターンは図７に記載する。

【００８５】通常、メッセージＭ_２は、メッセージＭ_１（又はその部分集合）と同じ情報を
含んでおり、分離したパラメータは重要な空白として通過する。しかし、メッセ
ージＭ_１からの特定の製品のメッセージＭ_２はメッセージ配信層の責任の範囲の
外側にあり、メッセージＭ_２がこの層を確実に通過する。

【００８６】このパターンにおいては、ツリー（Ｒ）上の一斉送信が用いられ、一斉送信は
ノードＲ上の発生源であるかのように働く。しかし、この場合においては、情報
はＲにおける発生源ではなく、反対にＲに向けて送信される。しかし、それはＲ
を発生源とするためすべてのノードに到達（特に標的メッセージが送信されるノ
ードに到達するものではない）するものではないが、配信パターンは、このケー
スにおいては、同時にＲを発生源とした一斉送信を必要する。

【００８７】一斉送信メッセージＭ_２はルーティングフラグとともに送信され、それはいつ
も一斉送信メッセージの場合のように中断はより典型的である。しかし、ターゲ
ットメッセージＭ_１は、ほとんど常に中断フラグとともに送信される。その理由
は、Ｍ_１は一斉送信のためにメッセージＭ_１からメッセージＭ_２を再創作するこ
とができず、Ｒから送信されるためである。アプリケーションロジック仲介は、
メッセージＭ_１を受信したノード上においてメッセージＭ_２を再創作するために
必要である。

【００８８】ルートからの一斉送信を伴なった標的配信パターンルートからの一斉送信を伴なった標的配信パターンは、標的情報が従の一斉送
信をも発生させるときに用いられる。一斉送信は、標的メッセージを受け取らな
い通常すべてのノードへ配信することが求められる。標的メッセージは、一斉送
信のルートと反対の方向から送信される。このパターンは標的パターンと排除を
伴なった一斉送信配信パターンとの組み合わせである。

【００８９】用法：ＴａｒｇｅｔＡｎｄＢｒｏａｄｃａｓｔＦｒｏｍＲｏｏｔ（Ｍ_１，Ｍ_２，Ｒ，
Ｄ）

【００９０】パラメータ：Ｍ_１は標的配信パターンで送信されるメッセージである。Ｍ_２は一斉送信配信パターンで送信されるメッセージである。Ｒは一斉送信のルートである。すべてのメッセージはツリー（Ｒ）に属するリ
ンク上において送信される。Ｄは標的メッセージの目的地である。

【００９１】前提条件：Ｄは送信ノードと異なる。送信ノードはＲからＤのカノニカル・パス上に存在する。

【００９２】送信ノードにおけるアクション：ｔａｒｇｅｔＳｅｎｄ（Ｍ_１，Ｄ）を実行する。ｂｒｏａｄｃａｓｔ（Ｍ_２，Ｒ，Ｄ）を実行する。

【００９３】ルートからの一斉送信を伴なった標的配信パターンは図８に示される。

【００９４】通常、メッセージＭ_２は、メッセージＭ_１（又はその部分集合）と同じ情報を
含んでおり、分離したパラメータは重要な空白として通過する。しかし、メッセ
ージＭ_１からの特定の製品のメッセージＭ_２はメッセージ配信層責任の範囲の外
側にあり、メッセージＭ_２がこの層を明確に通過する。

【００９５】メッセージＭ_２はメッセージＭ_１が送信されたのと同じノードには送信されな
い。反対方向のみではなく一斉送信のルートに向けたメッセージの送信を通常必
要としない一斉送信としての目標を達成するために特に特別なアクションを取る
必要がない。一斉送信メッセージＭ_２はあらゆるルーティングフラグとともに送
信され、閲覧フラグは、ほぼ典型的であり、常に一斉送信メッセージとともに送
信される。しかし、標的メッセージＭ_１はほぼ常に中断フラグとともに送信され
る。この理由は、一斉送信のためにメッセージＭ_１からメッセージＭ_２を再創作
することができず、配信層はそれ自身でメッセージＭ_１をＲに送信できるからで
ある。アプリケーションロジック仲介は、メッセージＭ_１を受信したノード上に
おいてメッセージＭ_２を再創作するために必要である。

【００９６】このパターンにおいては、標的メッセージはツリーのルートと反対の方向、す
なわち、ツリー一斉送信が通常送信される同じ方向送信される。そして、標的メ
ッセージが送信されたのと同じノードに一斉送信メッセージが送信されるのを防
ぐため、排除を伴なった一斉送信が用いられる。このパターンでは情報の発信源
は、送信ノードよりもルートの近くに位置しており、一斉送信は通常ルートに向
けてメッセージを送信しないため、一斉送信からの情報の発信源を排除するため
に明確な必要はない。

【００９７】価格分布はトレーダーターミナルにあるトレーダーにマーケット情報の提供を
行なうプロセスである。この情報はブローカー・ノードによって創作され、トレ
ーダーに配信されるために取引エージェントに送信される。このプロセスを図３
に示す。

【００９８】それぞれのブローカー・ノードは、クォートの配列（注文控え帳）を吟味しそ
れに接続された取引エージェントそれぞれのためにマーケットビューを計算する
。この見解は、エージェントが存在する取引フロアのために特別に建立される。
見解はクレジット又は他のファクターに基づいて異なる。マーケットビューを決
定するための厳密なプロセスは取引手法により変化する。この情報はマーケット
ビューメッセージとして取引エージェントに送信される。

【００９９】クォートのヒットは２つのトレーダー間の取引の成立プロセスのベースとなる
。１のトレーダーからのヒットは、他のトレーダーからのクォートと一致する。
このプロセスを図４に示す。自身のマーケットビューの表示において示された価
格をヒットしたトレーダーターミナルの取引エージェントはヒットサブミットメ
ッセージをブローカー・ノードに送信する。このメッセージは特定のクォートで
はなく価格を標的とするものである。ブローカー・ノードはその待ち行列を走査
しヒットと一致可能な行列中の第１のクォートを発見する。一致ルールは取り引
き手法に基づいて顕著に変化する。

【０１００】ヒットがクォートとヒットした場合、ブローカー・ノードはクォートのために
そのコンテクストを変更し、額の一致を「利用可能」から「取り引き待ちの予約
」に移動させる。これは他のヒットと一致したクォートの同じ額を発生させるこ
とを防止するためである。その後ブローカー・ノードは取引申込メッセージをク
ォートを受け取ったブローカー・ノードに送信する。このメッセージは、特定の
クォートを標的とするものである。この例では、ブローカー７はブローカー４に
当該メッセージを送信する。

【０１０１】それぞれのブローカー・ノードは取引申込メッセージを受信すると配列中のク
ォートをチェックする。取り引き申し込みの総額が配列中でまだ使用可能である
場合は、ブローカー・ノードは一致したブローカー・ノードと同様のプロセスを
実行する。取り引きの申し込みの額は「利用可能」から「取り引き待ちの予約」
に変更される。取引申込メッセージは、その後クォートを受け取ったブローカー
・ノードに送信される。例えば、ブローカー・ノード４はブローカー・ノード２
に送信する。その後ブローカー・ノード２はブローカー・ノード５にそれを送信
する。

【０１０２】取引き申し込みメッセージのルートは標的ルーティングルールに従う。標的ル
ーティングは特定のブローカー・ノードヘの配送情報が用いられる。特定のブロ
ーカー・ノードの情報はシステム内において建立されていないため、標的は特定
のブローカー・ノードではなく情報の発生源であるブローカー・ノードである。
例えば、メッセージは「ブローカー・ノード７１４」に送信されるのではなく、
「クォートの発生源であるブローカー・ノード４２」に送信される。

【０１０３】よって、メッセージはその発生源へ戻るもとの情報のパスに従う。この例では
、ブローカー・ノード７からブローカー・ノード５へブローカー・ノード２及び
４を経由して直接送られる。

【０１０４】クォートを独自に作成したブローカー・ノードは取引申込メッセージを受け、
他のブローカーと同じチェック及び量を実行する。このブローカー・ノードはク
ォートを有していないため、取り引きのためのクォートを委託することができる
。取引申込メッセージは取り引きのヒット委託するために示される。

【０１０５】その後、ブローカー・ノードは、クォートを送信した取り引きエージェントに
ヒットアマウントメッセージを送信することにより、取り引きプロセスを開始す
る。取り引きの実行プロセスについては後述する。

【０１０６】取り引き一致プロセスが実行されるために、クォートのリストは日付を保持す
るそれぞれのブローカー・ノードに保持される。これは、図５に示すようにクォ
ートを変更するときに、他に通知するそれぞれのブローカー・ノードによって達
成される。

【０１０７】それぞれのブローカーは、その配列内でクォートを変化させるために、ブロー
カーは、変化を受けたクリーク内のものを除くすべての隣接するブローカー・ノ
ードに通知する。上述の例では、ブローカー・ノード４は、取り引き申し込みメ
ッセージ内にブローカー・ノード７からクォートが変化した通知を受ける。それ
は、ブローカー・ノード２に取り引き申し込みメッセージを送ることによって通
知する。ブローカー・ノード４は、ブローカー・ノード１及び３に通知する。こ
れは、これらのブローカー・ノードへのマーケット更新メッセージを送信するこ
とにより行なわれる。

【０１０８】通常のルーティングルールにしたがって、クォートについての情報はネットワ
ーク内のそれぞれのブローカー・ノードに通知される。マーケット更新情報を受
けたいずれかのブローカー・ノードは、それを受信したクリーク内ではないすべ
ての隣接者へそれを通知する。取引申込みメッセージを送信したブローカー・ノ
ードは、同じブローカー・ノードへマーケット更新メッセージを送信するべきで
はないことに注意する。この結果、受信と取引額との情報の２つを２度にわたっ
て受け取ることになる。

【０１０９】取引実行プロセス自身は本発明の中心部分ではないが、完全のために説明する
。取引一致プロセスが完了したとき、上述したように、取引実行プロセスが開始
する。このプロセスは、取引を行なうトレーダーとの取引と委託を完全にする。
当該プロセスを図６に示す。一致がまとまり取引が開始されると、情報はトレー
ダーのために有効にされる。この情報はトレーダーに取引が待ちの状態にあるこ
とを通知するために有効である。あらゆる与えられた取引のアプリケーションは
、トレーダーが通知されたかどうかについて決定することができる。いずれの場
合でも、情報は有効である。

【０１１０】受取人の取引エージェントは、一致の開始が始まり取引申込みメッセージが送
信されるとすぐに通知される。このエージェントはこのときとレーダーのワーク
ステーションによって知ることができる。この待ちの取引情報は一致のプロセス
が続くにつれて変化する。メーカーの取引エージェントがクレジットをチェック
し、メーカー取引状況メッセージを送信するときに、メーカーのワークステーシ
ョンは取引の待ちの通知がされる。

【０１１１】取引実行プロセスは、メーカーの取引エージェントがそのブローカー・ノード
からヒットアマウントメッセージを受け取ったときに開始する。このメッセージ
はエージェントに一致がクォートの１つについて成立したことを通知するもので
ある。メッセージは額のヒット、カウンター・パーティ、ヒットの識別性と同様
にクォートを明確にする。エージェントはトレーダーのワークステーションを確
認し、クォートがまだ利用可能であるかについて確かめる。

【０１１２】エージェントはヒットアマウントＷＳメッセージをワークステーションに送信
する。ワークステーションは、ヒットアマウントＷＳメッセージを繰り返し、ト
レーダーがクォートを中断したのではなく、当該ワークステーションがまだ可動
していることを示す。この点において、トレーダーはもはや取引を中断すること
ができない。

【０１１３】取引エージェントは次にカウンター・パーティについて利用可能なクレジット
をチェックする。クレジットのチェックは取引を許容し、取引の額を減少させ又
は取引を許容しない。

【０１１４】その後、エージェントは、取引のために必要とされる額によって有効なクレジ
ットを減少させる。この有効なクレジットの減少は、さらに取引に影響を与える
。メーカーの取引エージェントは、メーカー取引状況メッセージをそのブローカ
ー・ノードに送信することによって、取引の受取人取引エージェントを通知する
。当該メッセージは、ヒットの識別を目標にする。ネットワークブローカー・ノ
ードはヒットのオーナーブローカー・ノードにメッセージを発送する。一度この
メッセージが送信されると、メーカーの取引エージェントに取引が待ちの応答の
疑いがなく取引が完了したことを通知する。受取人の取引エージェントは取引実
行プロセスを完了する。エージェントがメーカー取引状況メッセージをメーカー
から受け取ったとき、プロセスのこの部分が実行される。このメッセージが正当
な取引であることを示すときは、プロセスは続行する。

【０１１５】受取人取引エージェントは、次いで、メーカーと同様の方法で勘定関係につい
てクレジットの有効性をチェックする。クレジットは取引の許容性、取引の額の
減少、又は取引を許容しないことについてチェックする。エージェントは、その
後、取引のために必要長くによって有効なクレジットを減少させる。この有効な
クレジットの減少はさらに取引に影響を与える。受取人の取引エージェントはそ
のディスクにログを取る。永続的な保存のために情報が委託されるとすぐに、取
引が完了する。取引状況上のあらゆるクレジットは、まとめた取引を表示する。
エージェントは、トレーダーに取引チケットの印刷を通知し、過去の他の取引プ
ロセスを実行する。この点において、取引はまだメーカーが知ることなく行なわ
れる。取引が完了するとすぐに、受取人取引エージェントは、受取人取引状況メ
ッセージをそのブローカー・ノードに送信することによりメーカーに通知する。
このメッセージは、クォートを目標にし、メーカーの代行人ヘ送信される。

【０１１６】受取人取引状況メッセージは、クォートのオーナーブローカー・ノードに対し
て得られ、取引エージェントに対してそれが送信される。エージェントは保存す
るために取引を記録する。この点において、取引はもはや疑いがない。エージェ
ントはトレーダーに対して、チケットの印刷を通知し、必要な他のプロセスを実
行する。いくつかの取引手法においては、取引を取り交わすために追加の情報を
必要とする場合もある。この例は、ＥＢＳＳｐｏｔＦ／Ｘのための生産手法
である。このタイプの情報は、取引情報メッセージとして送信される。取引が実
行されたあと、エージェントはこの情報を展開する。取引情報メッセージはブロ
ーカー・ノードに送信される。ネットワークブローカー・ノードは、その後、該
メッセージを手法によって必要な情報が実行される他のエージェントに転送する
。その後、取引は完了する。

【０１１７】アーキテクチャの説明において、それぞれのブローカーが同じステータスを有
するものとしてブローカーのクリークツリー図が用いられている。取引エージェ
ントは、ブローカーの一部又はすべてに対して添付される。ブローカーは、クリ
ーク内に配置されるが、取引エージェントはそうではない。クリークの配列は、
メッセージの一斉送信及びネットワークを通したメッセージの標的がメッセージ
の流れを最小にするために規定しネットワークを通じたメッセージの通過をでき
るかぎり速くする。メッセージの一斉送信及び標的のルールは、ネットワーク上
の他のすべてのブローカーの存在の通知をブローカーが持たないようにし、メッ
セージがどこからきて次にどこに送信されるのかの通知を確認する。この意味は
、ブローカーの追加又は除去のためのネットワークの選択が、比較的簡単なタス
クであることを意味する。

【０１１８】上述の説明において、多数のメッセージ送信方法の１つによってシステムを通
してメッセージの送信を変化させることについて参照する。

【０１１９】続いてアノニマストレーディングシステムのコンテクストを伴なったメッセー
ジについて説明する。続く説明は、網羅的なリストではなくブローカー・ノード
間に通過する主なメッセージを買い戻すものである。それは、ブローカー−トレ
ーダー間のメッセージを含まない。それぞれのメッセージは、記述、メッセージ
属性、メッセージ配信パターン、及びメッセージを添付する前提条件、メッセー
ジプロセッシング及び送出メッセージの語句で説明する。

【０１２０】注文送信及びキャンセル注文送信及び注文有効性メッセージ

【０１２１】説明注文送信メッセージは、トレーダーが新たな注文を行なうとき、トレーダーワ
ークステーションからブローカーへ送信される。これは視認可能な注文(クォー
ト)又は視認できない注文(ヒット)とすることができる。これがクォートである
場合は、その後このイベントの結果として、ブローカーはすべての他のブローカ
ーに注文有効性メッセージを一斉送信する。

【０１２２】注文送信メッセージをトレーダーのワークステーションから受けたブローカー
は、注文のオーナーに呼ばれる。

【０１２３】メッセージ属性新たな注文

【０１２４】配信パターン注文送信：標的配信パターン。ルーティングフラグは問題とならず、中断フラ
グがより好ましい。注文有効性：一斉送信配信パターン中断フラグが用いられる。

【０１２５】前提条件：注文送信：メッセージの発生源はトレーダーワークステーションであり、送信
先はワークステーションに直接接続されたブローカーである。

【０１２６】注文有効性：なしメッセージプロセッシング注文送信又は注文有効性メッセージのプロセッシングの一部として、受信する
ブローカーＢは少なくとも以下のように行なう。

【０１２７】新たな注文を記憶する。注文を一致させようと試み、明確な状況に従う。一致状況(すべてのビジネス
マッチングルールに対して付加する)が創作され１つのブローカーよりも多数の
ブローカーを生み出すために申し込まれた取引の可能性を防止し、２つのブロー
カーによって自動的に一致する申込みがないようにする。これは、以下の少なく
とも１の条件を満たす場合、ブローカーＢが、注文Ｏの存在を伴なった新たな注
文Ｎを一致することを特定する。Ｎ又はＯのいずれかがＢによるヒットである。ＯはＢによるオファーである。Ｎは注文送信メッセージを経由して到達する(すなわち、トレーダーのワーク
ステーションから直接的に)。

【０１２８】新たな注文がクォートであるときはその後、それを注文有効性メッセージを経
由する他のブローカー(いくつかのマッチクングの有効性及び予約された額の変
更を伴なってもよい)に送信する。

【０１２９】送出メッセージＢが注文送信又は注文有効性メッセージＭを実行するブローカーである場合は
、以下の送出メッセージは、メッセージＭの実行の結果としてＢによって送信さ
れる。

【０１３０】１．新たな注文がクォートであり、ブローカーＢがそれについて存在するクォ
ートとともに自動的に一致した場合は、その後、クォートの１つは、ヒットまた
は、全額について一致しない場合は部分的にヒットに変換される。ブローカーは
所有するクォートについてのみヒットする変換を行なう。質問中の手法のために
ビジネスルールにしたがって、そのような変換はワークステーションを用いたク
ォート確認を必要とする。この場合は、その後注文確認メッセージがワークステ
ーションに送信される。それがクォートを送信したワークステーションでありる
場合は、Ｍ_１が新たな注文確認メッセージである。この場合、ＴａｒｇｅｔＳｅ
ｎｄ（Ｍ_１，Ｗ）が実行される。

【０１３１】２．ブローカーＢがヒット又は部分的ヒットを有するクォートを変換しなけれ
ばならない場合は、新たに注文が送信されず、ビジネスルールは上述のクォート
の確認を必要とせず、その後マーケット更新メッセージの一斉送信を必要とする
。このメッセージの目的は、ヒットに変換されたクォートの額を予約するためで
ある。より詳しくは、Ｍ_１に新たなマーケット更新メッセージをさせる。この場
合，ｂｒｏａｄｃａｓｔ（Ｍ_１，Ｂ）が実行される。

【０１３２】３．Ｂが双方のクォートを有しないのであれば、（２）について説明した場合
において、注文申込みメッセージは、他のクォートのオーナーにも送信されるべ
きである（ヒットに変換されないで）。より詳しくは、Ｒが他のクォートの所有
者であるブローカーである場合は、Ｍ_１は新たな注文の申込みメッセージであり
、Ｍ_１は、Ｍ_１により発生されたマーケット更新メッセージである。この場合、
ＴａｒｇｅｔＡｎｄＢｒｏａｄｃａｓｔｔｏＲｏｏｔ（Ｍ_１，Ｍ_２，Ｒ，ゼロ）
が実行される。

【０１３３】４．ブローカーＢが、存在する注文とともに新たな注文についてマッチし、双
方のオーダーがＢによって所有される場合は、取引確認及びマーケット更新メッ
セージが１又は双方のクォートについて送信される。これらは（１）及び（２）
で説明したように送信される。

【０１３４】５．新たな注文がクォートである場合は、ブローカーＢは他のブローカーに新
たなクォートについての情報を送信しなければならない（可能な場合は変形され
た形でいくつかの一致を実行する場合は、これは有効な額を予約された額に変換
する）。Ｍ_１がさらに送信される必要がある注文有効性メッセージである場合は
、ｂｒｏａｄｃａｓｔ（Ｍ_１，Ｂ）を実行する。

【０１３５】注文取消及び注文中断メッセージ説明注文中断メッセージは、トレーダーが注文を中断したい場合にトレーダーのワ
ークステーションからブローカーに送信される。このイベントの結果として、ブ
ローカーは注文取消メッセージを他のすべてのブローカーに一斉送信する。

【０１３６】メッセージ属性クォートを参照する。

【０１３７】配信パターン注文中断：標的配信パターン。ルーティングフラグは問題とならず、堅実性の
ために中断フラグがより好ましい。注文取消：一斉送信配信パターン。中断ルーティングフラグが用いられる。

【０１３８】前提条件注文中断：メッセージの発生源はトレーダーワークステーションであり、送信
先はワークステーションに直接接続されたブローカーである。注文中断メッセー
ジはあらかじめ注文送信メッセージがＷからＢへ送信されている場合に限りワー
クステーションＷからブローカーＢへ送信される。

【０１３９】注文取消：注文取消メッセージは、あらかじめ同じ注文についての注文有効性
メッセージがＢから一斉送信されている場合に限り、ブローカーＢから送信（一
斉送信）される。

【０１４０】メッセージプロセッシング注文取消又は注文中断メッセージのプロセスの一部として、受信したブローカ
ーＢは少なくとも次のものである。注文が知られたことを証明し、証明されなければエラーを報告する。キャンセルされた注文をマークし、この注文を必要とする新たな取引を禁止す
る。

【０１４１】Ｂへ通知されたこの注文が必要な取引の待ちがなく注文確認の要求が未決着で
はない場合、後者は注文の所有者のみについて可能であり、このクォートについ
ての情報はもはや保存する必要がない。

【０１４２】送出メッセージなし

【０１４３】上述のメッセージとは異なり、注文取消メッセージは中断ルーティングフラグ
を用いる。したがって、それは明確にこのメッセージをさらに再送信することは
アプリケーションの信頼度ではない。配信層は、これを必要とするすべてのブロ
ーカーへこのメッセージを配送する。

【０１４４】取引申込及びマーケット更新取引申込メッセージ非公式説明

【０１４５】取引申込メッセージが、一致を開始したブローカーからクォートを所有するブ
ローカーに送られる。申込まれた取引は、常に、1つのクォート(作り手)と1つの
ヒット(受取人)とで一致する。ヒットは、自動的に一致させている間にヒットに
変換されたクォートである。しかし、それは、取引申込処理のためにヒットとし
て取扱われている。取引申込メッセージは、ヒットのブローカーオーナーからの
ヒットと一致する(また必要ならば再一致する)権限を有する。しかしながら、ク
ォートのブローカー且つオーナーからのクォートと一致する権限を有しない。取
引申込メッセージの主な目的は、取引を委託するためにクォートのブローカー且
つオーナーから許可を得ることである。取引申込は、クォートのある総計が予約
されるべきであることを通知するために、ネットワーク中のすべてのブローカー
に一斉送信されるマーケット更新メッセージを生成する。

【０１４６】メッセージ属性新しく申込まれた取引は、少なくとも次の属性を含んでいる。一致したクォートへの参照一致したヒット(恐らくクォートからヒットへの変換から得る) 申込まれた取引の総計

【０１４７】配信パターンルートに向けての一斉送信での標的とされた配信。取引申込メッセージは、一
致(あるいは自動的な一致、あるいは再一致)を実行したブローカーで作られる。
また、その最終目的地はクォートを所有するブローカーである。一斉送信メッセ
ージはこの取引申込によって生成されたマーケット更新である。中断ルーティン
グ・フラグが使用される。

【０１４８】前提条件前もって、クォートQを備えた利用可能な注文メッセージがブローカーＢから
ブローカーＳに送られた場合のみ、クォートQを参照する取引申込メッセージが
ブローカーＳからブローカーＢに送信される。

【０１４９】メッセージ処理取引申込メッセージの処理の一部として、受取ブローカーＢは少なくとも以下
のことを行うべきである。

【０１５０】この取引申込が参照するクォートがＢに知られていることを確認すること。Ｂ
が注文取消メッセージに応じてクォートを最近削除したならば、これが特に真で
ない唯一のケースがある。この場合、Ｂは取引を拒否し、取引申込失敗メッセー
ジにおいて、「取消されたクォート」フラグをセットするべきである。

【０１５１】Ｂのローカルの注文控え帳によれば、申込まれた取引の総計がクォートにおい
てまだ利用可能であることを確認すること。これがそのようでない場合、Ｂは取
引(完全にあるいは部分的に、このクォートにおいて、少なくともある利用可能
な総計があるか否かに依存して)を拒否するべきである。

【０１５２】この取引(取引が完全に拒否された場合は必要でない)を記憶すること。

【０１５３】再一致が成功するならば、1つあるいはいくつかの新しい取引申込メッセージ
を生成して、拒否された総計に再一致させることを試みること。

【０１５４】もしそれが完全に拒否されないか、Ｂがクォートのオーナーでないならば、取
引申込メッセージをさらに送ること。

【０１５５】Ｂがクォートのオーナーである場合、取引完結プロセスを開始すること。(通
常、このプロセスはワークステーションを備えたクォート確認で始まる)。

【０１５６】送出メッセージＢが取引申込メッセージＭを処理するブローカーであり、Ｓがこのメッセージ
をＢに送ったブローカーである場合、次の送出メッセージが、メッセージＭを処
理することの結果として、Ｂによって送信される。

【０１５７】１.ブローカーＢが申込まれた取引を完全に(つまり、それが取引を承認するか
、または、それが取引の部分的な総計を承認する)拒否しないで、Ｂがこの申込
まれた取引で一致したクォートのオーナーでない場合、申込まれた取引メッセー
ジ(おそらく低減された総計で)がさらに送信される。Rがクォートのオーナーで
あるブローカーであり、Ｍ_１が新しい取引申込メッセージであり、Ｍ_２がＭ_１に
よって生成されたマーケット更新メッセージである場合、目標及びルートへの一
斉送信(Ｍ_１、Ｍ_２、R、Ｓ)が実行される。

【０１５８】２.ブローカーＢが申込まれた取引を完全に(つまり、それは少なくとも1つの
部分的な総計の取引を承認する)拒否しないで、Ｂがこの申込まれた取引で一致
したクォートのオーナーであるならば、注文確認メッセージは、この注文を入力
したワークステーションへ送信される。注文確認メッセージが送信され、Ｍ_２が
Ｍ_１によって生成されたマーケット更新メッセージであるならば、目標及びルー
トへの一斉送信(Ｍ_１，Ｍ_２，W，Ｓ)が実行される。

【０１５９】３.ブローカーＢが申込まれた取引を完全に(つまり、総計の少なくとも一部の
取引を拒否する)承認しない場合、取引申込失敗メッセージが送信される。Ｍ_１
が新しい取引申込失敗メッセージであり、Ｉがこの取引を開始したブローカーで
ある場合、目標送信(Ｍ_１，Ｉ)が実行される。

【０１６０】取引申込失敗メッセージは、この場合、マーケット更新の一斉送信を生成しな
い。なぜならば、この申込まれた取引と関係があったＢからのマーケット更新の
一斉送信がないので、解決すべきものは何もない。しかしながら、取引申込失敗
メッセージのその後のログは、通常、ルート・パターンからの一斉送信で標的と
された配信を使用するであろう。

【０１６１】４.ブローカーＢが、拒否された取引(あるいはそれの一部分)を再一致させる
ならば、一つ以上の新しい取引申込メッセージが生成される。Ｍ_１が新しい取引
申込メッセージであり、Ｍ_２がＭ_１によって生成されたマーケット更新メッセー
ジであり、Oが新しく一致したクォートを所有するブローカーであるならば、目
標及びルートへの一斉送信(Ｍ_１，Ｍ_２，O，ゼロ)が実行される。これはそれぞ
れ新しい取引申込メッセージに対して実行される。

【０１６２】取引申込失敗メッセージ説明取引申込失敗メッセージは、申込まれた取引を拒否するか、又はその総計を減
らしたブローカーから、取引を開始したブローカーに送られる。メッセージの目
的は、失敗した(恐らく部分的に)取引が、ヒットを再一致させるために権限を選
択的に戻し、かつ取引申込メッセージによって生成されたマーケット更新を巻き
戻すことを、取引開始者に通知することである。

【０１６３】メッセージ属性失敗の取引への参照失敗の総計再一致していない総計拒絶の理由が取消されたクォートだったかどうか指示するブール・フラグ(
「取消されたクォート」フラグ)。

【０１６４】例１００の最初の取引総計を考えると、その７０だけが、この取引申込失敗メッ
セージを生成したブローカーによって承認された。このブローカーは総計２０に
対して再一致させることができた。この場合、失敗の総計は３０であり、再一致
していない総計は１０である。可能ならば、そのような取引申込失敗メッセージ
は、再一致されていない総計１０に対して、さらなる再一致を実行する権限を有
する。

【０１６５】配信パターン標的とされた配信、あるいはルートからの一斉送信で標的とされた配信。標的
とされた配信は、このメッセージを生成したブローカーによって使用される。ま
た、ルートからの一斉送信で標的とされた配信は、後のブローカーによって通常
使用される。サイドの一斉送信されたメッセージは、最初の取引申込メッセージ
によって生成されたマーケット更新を巻き戻すマーケット更新であり、巻き戻さ
れた総計が取引申込失敗メッセージの「失敗の総計」に等しい。中断ルーティン
グフラグが使用される。

【０１６６】前提条件前もって、取引Dを備えた取引申込メッセージがブローカーＢからブローカー
Ｓに送信された場合のみ、取引Dを参照する取引申込失敗メッセージは、ブロー
カーＳからブローカーＢに送信される。これの一つの結果は、そのブローカーＢ
が取引Dを知る必要がないことである。

【０１６７】再一致していない総計は、失敗の総計より少ないか等しいべきである。失敗の
総計は、最初の申込まれた取引の取引総計より少ないか等しいべきである。再一
致していない総計は、負であるべきでない。また、失敗の総計は正であるべきで
ある。

【０１６８】メッセージ処理取引申込失敗メッセージの処理の一部として、受取ブローカーＢは少なくとも
以下のことを行うべきである。

【０１６９】この取引がＢに知られていることを確認し、そうでなければ、エラーを報告す
ること。

【０１７０】メッセージが「取消されたクォート」フラグ・セットを有するならば、この取
引で一致したクォートがＢに知られていて、取消としてマークされていることを
確認し、そうでなければエラーを報告すること。

【０１７１】取引の再一致していない総計を再一致させることを試みて、再一致が成功する
場合、一つ又はいくつかの新しい取引申込メッセージを生成すること。

【０１７２】もしＢが取引の開始者でなければ、取引申込失敗メッセージをさらに送信する
こと(Ｂがいくつかの再一致を行った場合、恐らく低減された再一致していない
総計で)。

【０１７３】Ｂがヒットのオーナーではなく取引の開始者であり、残っている再一致してい
ない総計が０でない場合には、ヒットのオーナーに不一致ヒットメッセージを送
ること。

【０１７４】この申込まれた取引の最終結果が完全に知られており、すべての取引申込失敗
メッセージの失敗の総計と、この取引に対する取引済みメッセージの総計との合
計が、取引総計に等しいならば、Ｂはこの取引に関する情報をもはや保持する必
要がない。さらに、クォートが取消されたものとしてマークされており、この取
引がＢに既知のこのクォートに対する最後の未決の取引であり、解決された注文
確認の要求がある場合、後者はクォートオーナーのみに対して可能であり、この
クォートに関する情報はもはや必要でない。

【０１７５】送出メッセージＢが取引申込失敗メッセージＭを処理しているブローカーであるならば、Ｓは
このメッセージをＢに送ったブローカーであり、Rは失敗の取引において一致し
たクォートを所有するブローカーである。

【０１７６】次のメッセージは、メッセージＭを処理することの結果として、Ｂによって送
られる。

【０１７７】１.ブローカーＢが、取引（あるいはそれの一部分)の拒否された取引申込失敗
メッセージの再一致されていない総計を再一致させる場合、一つ以上の新しい取
引申込メッセージが生成される。したがって、次に、Ｍ_１が新しい取引申込メッ
セージであり、Ｍ_２がＭ_１によって生成されたマーケット更新メッセージであり
、Oが新しく一致したクォートを所有するブローカーである場合、目標及びルー
トへのｂｒｏａｄｃａｓｔ(Ｍ_１、Ｍ_２、O，ゼロ)が実行される。このことが、
それぞれの新しい取引申込メッセージに対して行われる。

【０１７８】２.ブローカーＢが取引の開始者でなく、「取消されたクォート」フラグがセ
ットされていない場合、取引申込失敗メッセージ(恐らく修正される)が、さらに
送られるべきである。したがって、Ｉがこの申込まれた取引を開始したブローカ
ーであり、Ｍ_１が新しい取引申込失敗メッセージであり、Ｍ_２がＭ_１によって生
成されたマーケット更新メッセージである場合、目標及びルートからのｂｒｏａ
ｄｃａｓｔ(Ｍ_１，Ｍ_２，Ｒ，Ｉ)が実行される。

【０１７９】３.ブローカーＢが取引の開始者でなく、「取消されたクォート」フラグがセ
ットされる場合、取引申込失敗メッセージ(恐らく修正される)がさらに送られべ
きである。しかしながら、前の場合と異なって、取消されたクォートに対するマ
ーケット更新が一斉送信されることを必要としない。したがって、Ｉがこの申込
まれた取引を開始したブローカーであり、Ｍ_１が新しい取引申込失敗メッセージ
である場合、ｔａｒｇｅｔＳｅｎｄ(Ｍ_１，Ｉ)が実行される。

【０１８０】４.ブローカーＢが、取引Dに含まれるヒットのオーナーではなく、取引Dの開
始者であり、再一致していない総計が０でない場合、不一致ヒットメッセージが
ヒットのオーナーに送られる。Oというブローカーが、ヒットのオーナーである
ブローカーであり、Ｍ_１が新しい不一致ヒットメッセージである場合、ｔａｒｇ
ｅｔＳｅｎｄ(Ｍ_１，O)が実行される。不一致ヒットメッセージがバイパス・ル
ーティングフラグで送信されると、中間のノード上のアプリケーションに伝えら
れないことに注意すること。

【０１８１】５.ブローカーＢが取引Dの開始者であり、且つ、取引で一致したヒットのオー
ナーであり、このヒットがクォートからヒットへの変換によって得られている場
合、マーケット更新メッセージを一斉送信する必要がある。このメッセージの目
的は、クォートからヒットへの変換が行われたときに送信されたマーケット更新
メッセージの効果と逆(恐らく部分的に)である。したがって、Ｍ_１が新しいマー
ケット更新メッセージである場合、ｂｒｏａｄｃａｓｔ(Ｍ_１，Ｂ)が実行される
。

【０１８２】マーケット更新メッセージ説明マーケット更新メッセージは、利用可能で予約された総計のクォートの変化に
関して、ネットワーク中のブローカーすべてに通知するために使用される。ほと
んどの場合、このメッセージは、ある取引決定(つまり、取引を申込するか、前
もって申込まれた取引を拒否する)をしたブローカー上で作られて、一斉送信パ
ターンで標的とされた配信のうちの1つにおいて第２メッセージとして送信され
る。マーケット更新メッセージが単独で送信されるいくつかの場合がある。

【０１８３】メッセージ属性クォートへの参照予約総計(正又は負であろう)

【０１８４】配信パターン単独で送信されたとき、配信パターンを一斉送信する。それは、一斉送信パタ
ーンで標的とされた配信の一つにおいて第２メッセージとして送信される。ルー
ティングフラグは検査である。

【０１８５】前提条件同じクォートに対する有効な注文メッセージが前もってAからＢに送られた場
合のみ、マーケット更新メッセージがブローカーAからブローカーＢに送信され
る。マーケット更新メッセージの一斉送信のルートは、常に、クォートのオーナ
ーである。

【０１８６】メッセージ処理マーケット更新メッセージの処理の一部として、受取ブローカーＢは、少なく
とも以下のことを行うべきである。このメッセージが参照するクォートがブローカーに知られていることを確認
すること。予約総計をクォートの予約済み総計に加算して、クォートの利用可能な総計
から予約総計を差し引くこと。

【０１８７】送出メッセージ無。

【０１８８】不一致ヒットメッセージ説明不一致ヒットメッセージは、このヒットに対する申込まれた取引が失敗してい
ることを彼に通知するために、ヒットのブローカー且つオーナーに送られる。取
引申込失敗メッセージと違って、申込まれた取引によってなされたマーケット更
新が既に取り消されており、中間のブローカーに保留取引対象物がない場合、不
一致ヒットが使用される。このメッセージのただ一つの目的は、ヒットが一致し
なかったことをブローカーに通知することである。ヒットのオーナーでないブロ
ーカーによって、ヒットが再一致されるとともに取引が失敗したとき、このメッ
セージが送られる。(取引申込不良の処理における送出メッセージ(３)を参照す
ること)。

【０１８９】メッセージ属性ヒットへの参照ヒットの不一致総計

【０１９０】配信パターン標的とされた配信パターン。ルーティングフラグがバイパスである。

【０１９１】前提条件以下のことが真である場合のみ、不一致ヒットは、ブローカーAからブローカ
ーＢに送信される。Ｂがヒットのオーナーである。 Aが、このヒットに対する再一致を開始した。この取引が失敗した(つまり、
Aが取引申込失敗メッセージを受取る)。

【０１９２】メッセージ処理不一致ヒットメッセージの受信者は、常にヒットのオーナーである。不一致ヒ
ットメッセージの処理の一部として、受取ブローカーＢは少なくとも以下のこと
を行うべきである。

【０１９３】このメッセージが参照するヒットが、Ｂによって所有されているか、クォート
からヒットへの変換の結果であり、Ｂがクォートのオーナーであることを確認す
ること。

【０１９４】問題のヒットがクォートからヒットへの変換の結果であった場合は、クォート
の有効で予約された総計を更新し、クォートに対するマーケット更新メッセージ
を一斉送信して、クォートを再一致させることを試みること。そうでなければ、
ヒットの有効な総計を更新すること。

【０１９５】ビジネス規則に依存して、後の動きは、ヒットが失敗であるかまたはヒットの
再一致を試みていることをトレーダーに通知することを含む。

【０１９６】送出メッセージ。Ｂが不一致ヒットメッセージＭを処理するブローカーである場合、次のメッセ
ージが、メッセージＭを処理することの結果としてＢによって送られる。

【０１９７】１.ブローカーＢがヒット又はクォートの不一致の総計と再一致させる場合、
一つ以上の新しい取引申込メッセージが生成される。Ｍ_１が新しい取引申込メッ
セージであり、Ｍ_２はＭ_１によって生成されたマーケット更新メッセージであり
、Oが新しく一致したクォートを所有するブローカーである場合、目標及びルー
トへの一斉送信(Ｍ_１，Ｍ_２，O，ゼロ)が実行される。このことは、それぞれの
新しい取引申込メッセージに対して行われる。

【０１９８】２.ヒットがクォートからヒットへの変換によって得られた場合、マーケット
更新メッセージが一斉送信される必要がある。このメッセージの目的は、クォー
トからヒットへの変換が行われたときに送信されたマーケット更新メッセージの
効果の逆(恐らく部分的に)である。Ｍ_１が新しいマーケット更新メッセージであ
る場合、一斉送信(Ｍ_１，Ｂ)が実行される。

【０１９９】取引完結注文確認メッセージこのトレーダーによって入力されたクォートがまだ有効であることを確認する
ために、注文確認メッセージがブローカーからトレーダーワークステーションに
送られる。取引を終了させる前にクォートがまだ有効であることのワークステー
ションでの確認をビジネスルールが要求するとき、このメッセージが使用される
。

【０２００】メッセージ属性クォートへの参照。

【０２０１】配信パターン目標配信、あるいはルートに向けた一斉送信で標的とされた配信。ルーティン
グフラグは重要ではないが、整合のために、中断フラグを使用することが好まし
い。

【０２０２】前提条件注文確認メッセージの発信者はブローカーであるべきであり、目的者はこのブ
ローカーに直接接続されたトレーダーワークステーションであるべきである。前
もって、注文送信メッセージがWからAに送信された場合のみ、注文確認メッセー
ジがブローカーAからワークステーションWに送られる。

【０２０３】メッセージ処理注文確認メッセージの処理の一部として、受取ワークステーションWは、クォ
ートがまだ有効か否かを照合するべきであり、注文確認メッセージでブローカー
に返答するべきである。

【０２０４】送出メッセージ Wが注文確認メッセージＭを処理しているワークステーションである場合、注
文確認メッセージは、処理することの結果としてメッセージＭを要求するブロー
カーにWによって送られるべきである。Ｍ_１が新しい注文確認メッセージであり
、Aが注文確認要求を発行したブローカーである場合、ｔａｒｇｅｔＳｅｎｄ(Ｍ_１，Ａ)が実行される。

【０２０５】注文確認メッセージ説明注文確認済みメッセージは、注文確認メッセージに応じて、トレーダーワーク
ステーションからブローカーに送られる。このメッセージは、与えられたクォー
トがまだ有効であるか否かを、ワークステーションから返答することを含んでい
る。取引の処理を行う前にクォートがまだ有効であることをワークステーション
で確認することをビジネス規則が要求する場合、注文確認/注文確認済みメッセ
ージが使用される。

【０２０６】メッセージ属性クォートへの参照クォートが有効であるか否かを指示するブール・フラグ。

【０２０７】配信パターン標的とされた配信パターン。ルーティングフラグは重要ではないが、整合のた
めに、中断フラグを使用することが申込されている。

【０２０８】前提条件注文確認済みメッセージの発信者は、すなわち、受取ブローカーＢは
少なくとも以下のことを行うべきである。

【０２０９】このクォートが知られていることを確認し、そうでなければエラーを報告する
こと。

【０２１０】クォートが有効ではないことをメッセージが指示する場合は、このクォートが
キャンセルされた状態にあることを確認して、そうでなければエラーを報告する
こと。

【０２１１】クォートが有効でないことをメッセージが指示し、注文確認要求の目的が取引
を確認することである場合、取引を取消すプロセスを開始させること。

【０２１２】クォートが有効であることをメッセージが指示し、注文確認要求の目的が取引
を確認する場合、取引完了プロセスを開始させること。

【０２１３】クォートが有効であることをメッセージが指示し、注文確認要求の目的がクォ
ートからヒットへの変換のためのクォートを確認することである場合、可能なら
ば、変換を実行して取引を申込すること。

【０２１４】このことが取引確認での最終ステップ(つまり、取引が潜在的に失敗する他の
ステップが複雑ではない)であり、十分な量のクォートが取引されて、これらの
取引が確認される場合、クォートが取消されるべきである。

【０２１５】送出メッセージＢが注文確認済みメッセージＭを処理しているブローカーである場合、次の送
出メッセージが、メッセージＭを処理することの結果としてＢによって送信され
る。

【０２１６】１.クォートが有効でなく、注文確認メッセージが取引申込メッセージの結果
として送られた場合、取引申込失敗メッセージが送信される。Ｍ_１が新しい取引
申込失敗メッセージであり、Ｉがこの取引を開始したブローカーである場合、ｔ
ａｒｇｅｔＳｅｎｄ(Ｍ_１，Ｉ)が実行される。

【０２１７】２.クォートが有効でなく、ブローカーＢが、このクォートと元々は一致した
ヒットに再一致させた場合、一つ以上の新しい取引申込メッセージが生成される
。Ｍ_１が新しい取引申込メッセージであり、Ｍ_２がＭ_１によって生成されたマー
ケット更新メッセージであり、Oが新しく一致したクォートを所有するブローカ
ーである場合、目標及びルートへのｂｒｏａｄｃａｓｔ(Ｍ_１，Ｍ_２，O，ゼロ)
が実行される。このことは、それぞれの新しい取引申込メッセージに対して行わ
れる。

【０２１８】３.クォートが有効であり、注文確認メッセージが取引申込メッセージの結果
として送られ、ビジネス要求条件が、あらゆる追加的な取引（つまり、今終了し
た取引）の確認ステップを含んでいない場合、取引を申込したブローカーは取引
済みメッセージによって通知される必要がある。Ｍ_１が新しい取引済みメッセー
ジであり、Ｉがこの取引を開始したブローカーである場合、ｔａｒｇｅｔＳｅｎ
ｄ(Ｍ_１，Ｉ)が実行される。

【０２１９】４.クォートが有効であり、クォートからヒットへの変換の目的でクォート、
及び、Ｂが開始することを欲する取引がまだ可能であることを確認するために、
注文確認メッセージが送られる場合、新しいマーケット更新メッセージおよび新
しい取引申込メッセージが生成されます。Ｍ_１がクォートからヒットへの変換を
経験したクォートからの転換された総計を予約する新しいマーケット更新メッセ
ージであり、Ｍ_２が新しい取引申込メッセージであり、Ｍ_３がＭ_１によって生成
されたマーケット更新メッセージであり、Ｏが、クォートからヒットへの変換の
結果と一致可能なクォートを所有するブローカーである場合、一斉送信ｂｒｏａ
ｄｃａｓｔ(Ｍ_１，Ｂ)と、目標及びルートへのｂｒｏａｄｃａｓｔ(Ｍ_２，Ｍ_３
，Ｏ，ゼロ)とが実行される。

【０２２０】５.十分な総計のクォートが取引される場合、注文取消メッセージは、このク
ォートに関する情報をもはや保持する必要がないことをブローカーすべてに通知
するために、一斉送信される必要がある。Ｍ_１が新しい注文取消メッセージであ
る場合、ｂｒｏａｄｃａｓｔ(Ｍ_１，Ｂ)が実行される。

【０２２１】取引済みメッセージ説明取引済みメッセージは、取引を確認したブローカーから取引を申込したブロー
カーに送られる。

【０２２２】メッセージ属性取引への参照行われた総計(最初に申込まれた取引の総計より少ないかもしれない)

【０２２３】配信パターン標的とされた配信パターン。ルーティングフラグは検査である。

【０２２４】前提条件前もって、同じ取引での取引申込メッセージがブローカーＢからブローカーA
に送信された場合のみ、取引済みメッセージがブローカーAからブローカーＢに
送信される。

【０２２５】メッセージ処理取引済みメッセージの処理の一部として、受取ブローカーＢは少なくとも次の
ことを行うべきである。

【０２２６】この取引が知られていることを確認して、そうでなければエラーを報告するこ
と。

【０２２７】このブローカーが、ヒットのオーナーではなく取引の発信者である場合、取引
に関して彼に通知するヒットのオーナーにヒット一致メッセージを送ること。

【０２２８】この取引の最終結果が完全に知られている(つまり、すべての取引申込失敗メ
ッセージ失敗の総計と、この取引に対するすべての取引済みメッセージの総計と
の合計は、取引総計に等しい)場合、Ｂはこの取引に関する情報をもはや保持す
る必要がない。さらに、クォートが取消としてマークされており、この取引はＢ
に知られたこのクォートに対する最後の保留取引であり、未解決の注文確認要求
(後者はクォートオーナーのみが可能である)がない場合、このクォートに関する
情報はもはや必要でない。

【０２２９】送出メッセージＢが取引済みメッセージＭを処理するブローカーである場合、次の送出メッセ
ージがメッセージＭを処理することの結果としてＢによって送信される。

【０２３０】Ｂがヒットのオーナーではなく取引の発信者である場合、一致ヒットメッセー
ジは、ヒットのオーナーに送られるべきである。したがって、Ｍ_１が新しい一致
ヒットメッセージであり、Oがヒット(あるいはヒットがクォートからヒットへの
変換の結果である場合、このヒットを生み出したクォート)を所有するブローカ
ーである場合、ｔａｒｇｅｔＳｅｎｄ(Ｍ_１，Ｉ)が実行される。

【０２３１】一致ヒットメッセージ説明一致ヒットメッセージは、ヒットが一致していることを彼に通知し、取引の詳
細を提供するために、取引を申込したブローカーからヒットを所有するブローカ
ーに送られる。

【０２３２】メッセージ属性一致したクォートへの参照一致したヒットへの参照一致した総計

【０２３３】配信パターン標的とされた配信パターン。ルーティングフラグはバイパスである。

【０２３４】前提条件以下のことがすべて真である場合のみ、一致ヒットメッセージが、ブローカー
AからブローカーＢに送信される。

【０２３５】Ｂは、取引(あるいはクォートからヒットへの変換を通じてこのヒットを生成
したクォートのオーナー)で一致したヒットのオーナーであること。

【０２３６】申込まれたこの取引、および取引が確認される。

【０２３７】メッセージ処理一致ヒットメッセージの処理の一部として、受取ブローカーＢは少なくとも以
下のことを行うべきである。

【０２３８】取引で一致したこのヒットがＢによって所有されていることを確認し、そうで
なければエラーを報告すること。

【０２３９】ヒットの「予約され」且つ「行われ」た総計のヒットを調整し、取引について
トレーダーに通知すること。

【０２４０】送出メッセージなし。

【０２４１】これらの記載に関して様々な修正や他の構成は、請求の範囲によって規定され
る本発明の範囲内にあるが、当業者には可能であろう。

【図面の簡単な説明】

本発明の具体例を、単なる例示として、添付の図面を参照しながら説明する。

【図１】本発明を具体化したトレーディング・システムの全体図である。

【図２】新しいクォートがシステム内に送信された場合のメッセージフロ
ーを説明する図である。

【図３】トレーダーに対するマーケット・ビューの提供を示す図である。

【図４】トレーダーが買注文または売注文を出した場合におけるメッセー
ジフローを示す図である。

【図５】買注文または売注文に従って、ブローカーノードをアップデート
するメッセージフローを示す図である。

【図６】取引実行プロセスを示す図である。

【図７】ルート複合メッセージ・パターンへ向けた、一斉送信によるター
ゲット配信を示している。

【図８】ルート複合メッセージ・パターンからの、一斉送信によるターゲ
ット配信を示している。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者ウラジミール・ネイマンアメリカ合衆国07052ニュージャージー州ウエスト・オレンジ、ノースフィールド・アベニュー275番 (72)発明者スティーブン・イアチェオアメリカ合衆国07035ニュージャージー州リンカーン・パーク、ウエスト・ウィリアム・ストリート41番 (72)発明者ニーナ・ジャインアメリカ合衆国07080ニュージャージー州サウス・プレインフィールド、ビクトリー・ストリート3756番 (72)発明者ジェイムズ・シュアメリカ合衆国07936ニュージャージー州イースト・ハノーバー、ティルデン・ドライブ42番

Claims

【特許請求の範囲】

【請求項１】代替可能商品を取引するためのコンピュータ・トレーディン
グ・システムであって、取引に関する情報を含む取引情報メッセージを伝達するためのコミュニケーシ
ョン・ネットワークと、上記ネットワークに接続されていて、オーダーを含む価格クォーテーション・
メッセージを発生する、複数のオーダー入力装置と、ある配信構成において上記ネットワークに接続されており、ネットワーク全体
に渡って取引情報メッセージを配信するように構成された複数のノードと、を備えており、ノード間でのメッセージ配信は、当該ノード間のカノニカル・パスを通して行
なわれ、カノニカル・パスとは一対のノード間における最良の経路であり、 i) 与えられた２つのノード間のカノニカル・パスは、可換性であり、 ii) 与えられた２つのノード間のカノニカル・パスは、１または２以上のさらな
るノードを含んでおり、当該さらなるノードと前記２つのノードのそれぞれとの
間におけるカノニカル・パスは、与えられたノードとさらなるノードとの間にお
けるサブパスと同一であって、それが与えられたノード間におけるカノニカル・
パスの一部を構成しており、 iii) 各ノードとそれ自身との間のカノニカル・パスは、エンプティである、システム。
【請求項２】上記ノードは、複数のクリークとして構成され、各クリークは、論理接続された複数のノードを含み、１つのクリークにおける各ノードは、そのクリーク内の他の全てのノードと接
続され、すべての２つのクリークは、単一のパスで接続され、その結果、複数のノードがクリーク・ツリーを構成している、請求項１記載の
システム。
【請求項３】ネットワーク上を伝達されるメッセージは、ルーティング情
報を含んでいる、請求項１記載のシステム。
【請求項４】上記ルーティング情報は、配信パターンを含んでいる、請求
項３記載のシステム。
【請求項５】上記ルーティング情報は、リクエストを送るメッセージ内で
特定されるノードを含んでいる、請求項３記載のシステム。
【請求項６】上記ルーティング情報は、ルーティング・フラグを含んでい
る、請求項３記載のシステム。
【請求項７】上記配信パターンは、標的パターンであって、メッセージが
特定の目的地ノードまで送信される、請求項４記載のシステム。
【請求項８】上記配信パターンは、一斉送信パターンであって、メッセー
ジがネットワーク内の１つのノードまで送信される、請求項４記載のシステム。
【請求項９】上記配信パターンは、排除を伴なうブロードキャストであっ
て、メッセージがネットワーク内において、特定の１つまたは１セットのノード
を除くすべてのノードまで送信される、請求項４記載のシステム。
【請求項１０】上記配信パターンは、上記標的パターン、一斉送信パター
ン、排除を伴なう一斉送信パターンのうちの２つまたは３つ以上を含む複合パタ
ーンである、請求項７、８、または９記載のシステム。
【請求項１１】上記ルーティング・フラグは、メッセージが最終目的地に
対してのみ配信されるべきことを示すバイパス・フラグを含んでいる、請求項６
記載のシステム。
【請求項１２】上記ルーティング・フラグは、メッセージがそのソースか
ら目的地までのパス上にある各ノードに対して配信されるべきことを示す閲覧フ
ラグを含んでいる、請求項６記載のシステム。
【請求項１３】上記ルーティング・フラグは、メッセージがそのソースノ
ードから目的地までのパス上における最初のノードに対してのみ配信されるべき
ことを示す中断フラグを含んでいる、請求項６記載のシステム。
【請求項１４】上記取引情報メッセージは、オーダー入力装置からノード
へと送られた注文送信メッセージを含んでおり、当該取引情報は、新しいオーダーがシステム内に入ったことを表示している、
請求項１記載のシステム。
【請求項１５】上記取引情報メッセージは、新しいオーダーがオーダー入
力装置から送信されたことを表示する注文有効メッセージを含んでおり、注文有効メッセージは、ネットワーク内のノードに受け取られ、当該ノードは
、当該を送信を行なっているオーダー入力装置がそこに接続されて、そこにネッ
トワークを通じた一斉送信が行なわれているノードである、請求項１４記載のシ
ステム。
【請求項１６】上記取引情報メッセージは、オーダー入力装置からノード
へと送られた注文取消メッセージを含んでおり、当該取引情報は、オーダーがもはや有効ではないことを表示している、請求項
１５記載のシステム。
【請求項１７】上記取引情報メッセージは、注文取消メッセージが受領さ
れたとき、ネットワークを通じて一斉送信される、注文中断メッセージを含んで
いる、請求項１６記載のシステム。
【請求項１８】上記取引情報メッセージは、注文がマッチしたノードから
送られた取引申込メッセージを含んでおり、当該取引情報は、２つの注文の間で取引が申し込まれたことを表示している、
請求項１７記載のシステム。
【請求項１９】上記取引情報メッセージは、マッチングするノードに一斉
送信されるマーケット更新メッセージであり、当該取引情報は有効なチャージであり、情報は注文の保有量である、請求項１
記載のシステム。
【請求項２０】上記取引情報メッセージは、申し込まれた取引の片側を所
有するノードによって送信された取引申込失敗メッセージであり、当該取引情報は、取引の拒否または部分的な拒否である、請求項１８記載のシ
ステム。
【請求項２１】上記取引情報メッセージは、ヒット注文を送信されたノー
ドによって送信されたヒット否マッチング・メッセージであり、当該取引情報は、失敗したヒット注文に対して取引が申し込まれたことを示し
ている、請求項１記載のシステム。
【請求項２２】上記取引情報メッセージは、ノードによってオーダー入力
装置へと送信された注文確認メッセージであり、当該取引情報は、そのオーダー入力装置からエンターされた注文がなお有効で
あるか否かを示している、請求項１記載のシステム。
【請求項２３】上記取引情報メッセージは、注文確認メッセージに応答し
て、オーダー入力装置からノードへと送信された注文確認済メッセージであり、当該取引情報はなお有効である、請求項１２記載のシステム。
【請求項２４】上記取引情報メッセージは、取引を確認したノードから取
引を申し込んだノードへと送信された取引実行済メッセージであり、当該取引情報は、申し込まれた取引が実行済であることを示している、請求項
１記載のシステム。
【請求項２５】上記取引情報メッセージは、取引を申し込んだノードから
送信された、リストがマッチングした旨のメッセージであり、当該取引情報は、ヒット注文がマッチングしたことを示している、請求項１記
載のシステム。
【請求項２６】上記ノードがブローカー・ノードであって、各ブローカー・
ノードは、システム内での取引に利用できるオーダーの蓄積と、少なくとも１つのオーダー入力装置に価格を配信する手段と、を含む、請求項１記載のシステム。
【請求項２７】上記ブローカー・ノードがクリーク・ツリーとして構成され
ており、各クリークは、論理接続された複数のブローカー・ノードを含み、任意の２つのクリークが単一のパスで接続されている、請求項２６記載のシス
テム。
【請求項２８】上記単一のパスが連結する２つのクリークは、互いに共通
するブローカー・ノードを１つ有している、請求項２７記載のシステム。
【請求項２９】上記代替可能商品が金融商品である、請求項１記載のシス
テム。
【請求項３０】代替可能商品を取引するためのアノニマス・トレーディン
グ・システムであって、電子メッセージを伝達するコミュニケーション・ネットワークと、コミュニケーション・ネットワークに接続されており、それぞれが、ビッドお
よび(または)オファー・プライスを含む電子プライス・クォーテション・メッセー
ジを発生するとともに、ネットワーク中に存在する他のオーダー入力装置から受
け取ったプライス・クォーテション・メッセージに係るトレーダーとコミュニケー
ションを行なう、複数のオーダー入力装置と、上記ネットワークに接続されており、オーダー入力装置からシステムに入力さ
れたオーダーのマッチングを行ない、オーダーがマッチした取引を実行し、プラ
イス・クォーテション・メッセージおよびオーダーのマッチングに応答して、プラ
イス・クォーテション・メッセージをオーダー入力装置へと配信する、複数のブロ
ーキング・ノードと、を備え、上記ブローキング・ノードは、複数のクリークとして構成され、各クリークは、論理接続された複数のブローキング・ノードを含み、１つのクリークにおける各ブローキング・ノードは、そのクリーク内の他の全
てのブローキング・ノードと接続され、すべての２つのクリークは、単一のパスで接続され、その結果、複数のブローキング・ノードがクリーク・ツリーを構成している、シ
ステム。
【請求項３１】カウンター・パーティによってシステム内にエンターされ
たアノニマスなビッドおよびオファーをマッチングし、マッチしたビッドとオフ
ァーを実行して取引を成立させる、複数のブローキング・ノードを含み、上記ブローキング・ノードは、複数のクリークとして構成され、各クリークは、論理接続された複数のブローキング・ノードを含み、そのクリークにおける各ブローキング・ノードは、そのクリーク内の他の全て
のブローキング・ノードと接続され、すべての２つのクリークは、単一のパスで接続され、その結果、複数のブローキング・ノードがクリーク・ツリーを構成している、電
子トレーディング・システム。