(57)【要約】匿名トレーディングシステムは、接続されているトレーディングエンジンを介してトレーダー端末から買い注文と売り注文を受信し、永続的な注文、実行された取引をマッチングし、トレーダー端末に価格情報を分配するクリーク内に配列される仲介ｎｏｔｅｄの相互接続ネットワークを備える。２つの注文がマッチングされる場合、提案される取引メッセージはマッチングブローカーによって送信される。別のブローカーが、マッチングされた呼び値を使用不可能にするイベントを処理すると、一致は失敗し、再一致が発生してよい。再一致は、それが一致の片側を所有するか、あるいはそれが異なるクリーク内のブローカーから一致の両側を受信したならば、中間ブローカーによって試みられてよい。中間ブローカーは、待ち行列内の次に使用可能な呼び値のマッチングを試みる。
2004501454.tif 000002
【特許請求の範囲】
【請求項１】
各仲介ノードが仲介機能を実行し、ノードがともに分配ネットワーク、及び該分配ネットワークに接続される複数のトレーダー端末を備える、第１仲介ノード、第２仲介ノード、及び該第１仲介ノードと該第２仲介ノードの間で接続される少なくとも１つの中間マッチングノードとを備え、
証券を取り引きするためのコンピュータトレーディングシステムであって、そこではノードのそれぞれが、
取引に使用可能な注文の記憶装置と、
複数のトレーディングエージェントのそれぞれによって提出される融和性のある注文をマッチングするためのマッチング機構とを備え、
さらに中間マッチングノードが、
第１仲介ノードから第２仲介ノードへ伝送された取引を要求するメッセージを傍受するための手段と、
第１仲介ノードによって提案された取引が失敗することを検出するための手段と、
取引に使用可能な注文の記憶装置からの呼び値との代替一致を提案するための手段とを含む、コンピュータトレーディングシステム。
【請求項２】
中間ノードが仲介ノードである、請求項１に記載のコンピュータトレーディングノード。
【請求項３】
代替一致が、取引に使用可能な注文の記憶装置内の第２の注文である、請求項１または２に記載のコンピュータトレーディングシステム。
【請求項４】
ノードがクリーク内で配列され、中間ノードが異なるクリークのノードから一致の両側についての情報を受信した場合にのみ再一致を提案する、請求項１、２または３に記載のコンピュータトレーディングシステム。
【請求項５】
中間ノードが、一致の少なくとも片側のオーナーである場合にのみ再一致を提案する、請求項１、２または３に記載のコンピュータトレーディングシステム。
【請求項６】
仲介ノードが、各クリークが複数の論理的に接続されている仲介ノードを備え、前記クリークの内の任意の２つが単一経路によって連結されるように、クリークツリー内で並べられる、前述の請求項のいずれかに記載のコンピュータトレーディングシステム。
【請求項７】
２つのクリークを連結する単一経路が、両方のクリークに共通の１つの仲介ノードを備える、請求項６に記載のコンピュータトレーディングシステム。
【請求項８】
各ノードが、経路選択プロトコルに従って取引情報を分配するように配列される、請求項６または７に記載のコンピュータトレーディングシステム。
【請求項９】
経路選択プロトコルが、
取引情報を備える取引情報メッセージを発するノードが、その隣人ノードのすべてに送信するように、かつ、
取引情報を備える取引情報メッセージを受信する各ノードが、発信側ブローカーと同じクリーク内のそれらの隣人ノード以外のその隣人ノードのすべてに、取引情報を備える追加取引情報メッセージを送信するように構成される、請求項８に記載のコンピュータトレーディングシステム。
【請求項１０】
取引情報メッセージが呼び値使用可能メッセージであり、情報が金融証券についての呼び値である、請求項８または９に記載のコンピュータトレーディングシステム。
【請求項１１】
取引情報メッセージが、ＰｒｏｐｏｓｅｄＤｅａｌメッセージまたは市場更新メッセージであり、情報が既存の注文に対する変更である、請求項８、９または１０に記載のコンピュータトレーディングシステム。
【請求項１２】
情報のある特定の部分についての取引情報メッセージを発するノードが該情報の特定の部分が受信されたノードにそれを送信するように、経路選択プロトコルが構成される、請求項８に記載のコンピュータトレーディングシステム。
【請求項１３】
発しなかった情報のある特定の部分についての取引情報メッセージを受信するノードが、元の情報を受信したノードに該メッセージを送信するように、プロトコルがさらに構成される、請求項１２に記載のコンピュータトレーディングシステム。
【請求項１４】
取引情報メッセージがＰｒｏｐｏｓｅｄＤｅａｌ失敗メッセージであり、情報の特定の部分が金融証券に対する注文である、請求項１２または１３に記載のコンピュータトレーディングシステム。
【発明の詳細な説明】
【０００１】
【技術分野】
本発明は、スポットＦＸ及びＦＲＡの金利スワップ、マネー、マーケット、オプション、地金（ｍｅｔａｌｓ）、コールマネー、国債、及びその他の短期金利証券を含むが、それらの制限されないその他の金融証券などの取り引きできる証券に、電子仲介サービスを提供するためのコンピュータトレーディングシステムに関する。特に、発明は、入札、オファー、買い注文及び売り注文の提出及びマッチングのために、ネットワークに接続されている複数のトレーダー端末を有するコンピュータトレーディングシステムに関する。
【０００２】
【発明の背景】
匿名トレーディングシステムは、例えば、外国通貨（またはその他の金融証券）用の自動マッチングシステムを開示するＥＰ−Ａ−第０，３９９，８５０号、ＥＰ−Ａ−第０，４０６，０２６号、及びＤＰ−Ａ−第０，４１１，７４８号で既知である。このシステムにおいて、単一ホストコンピュータが、取引、信用度情報、及びコンピュータネットワークを介してホストに接続される端末によって提出される入札とオファーに使用可能なすべての金融証券の中央データベースを維持する。ホストコンピュータは、対向する関係者（ｃｏｕｎｔｅｒ ｐａｒｔｙ）信用限度を含むマッチング基準に基づき、入札とオファー及び買い注文と売り注文をマッチングするためにその中央データベース内の情報を使用する。
【０００３】
対向関係者信用限度は、各取引所で設定され、ホストコンピュータに記憶され、それがそれぞれの考えられる対向関係者の組の総対向関係者信用限度を確立する。該総対向関係者信用限度は、第１関係者から第２関係者へ、及び第２関係者から第１関係者の残りの貸し金の最小額である。ホストコンピュータに接続される多様なトレーダー端末は、最良入札とオファーなどの、ホストコンピュータで入手可能な情報の制限された部分集合だけを維持、表示する。
【０００４】
ホストコンピュータが、潜在的な一致が特定された後に取引が先に進むことができるかチェックするために、信用度情報だけを使用していたという点で、このシステムについて問題点が特定された。トレーダーは、このようにして、取り引きしようと試みる前に、自分が潜在的な対向関係者に信用があるかどうかを知ることができなかった。この問題が特定され、米国−Ａ−第５，３７５，０５５号に開示されるシステムで解決策が提供された。
【０００５】
米国−Ａ−第５，３７５，０５５号に開示されるシステムでは、信用度マトリックスは分配ネットワークの複数の領域ノードで引き出され、記憶され、各領域ノードが、該領域ノードがアクセスノードを介して接続されるトレーダー端末の集合に市場情報を分配する。地域ノードは、市場分配者として知られており、取引可能な価格情報を、マーケットアクセスノードとして知られているアクセスノードを介して接続されるトレーダー端末に提供する。入札、オファー、買いコマンド及び売りコマンドの実際のマッチングは、仲裁人として知られている別個のノードによって提供される。
【０００６】
しかしながら、私達は、さらに、単一マッチングコンピュータを有することにまつわる問題点があることを理解した。ホストコンピュータトレーディングシステムを使用するトレーダーは、多くの場合、トレーダーからホストコンピュータへのメッセージフローの変化する遅延につながる地理学的に別々の場所にいる。その結果、ある地理学上の場所にいるトレーダーは、別のトレーダーと比較して、ホストへのメッセージの時間遅延という点で不利な立場に置かれることがある。
【０００７】
一例として、物理的に別個の場所にいる二人のトレーダーが同時に注文を提出すると、ホストコンピュータに最初に到着するトレーダーのメッセージは、第２の前に呼び値とマッチングするだろう。これは、ホストに地理学的に近いトレーダーに優位点を提供し、より遠く離れたトレーダーにとってはいらだたしい。さらに、より遠く離れたトレーダーは、一致が不成功であった旨を報告するメッセージを受信し、ネットワーク上のメッセージトラフィックを増大させる可能性がある。
【０００８】
この状況を改善するために、米国−Ａ−第５，３７５，０５５号に開示されるさらに分配されたシステムは、別々の物理的な場所にマッチングエンジンを有し、それによって異なる場所のトレーダー間の同位性（ｐａｒｉｔｙ）を増し、ネットワークトラフィックを削減する。そのシステムでは、ホストシステムでの場合のように、価格をヒットするトレーダー（買い手）は、価格を言うトレーダー（作り手）から物理的に遠くにいるだろう。ネットワークトラフィックは削減されるが、依然として、２人のトレーダーがほぼ同時に価格をヒットするが、一方の買い手トレーダーが、他方の買い手トレーダーからのメッセージが最初に到着したために、最終的にある特定の作り手と取引を行うことができない可能性がある。
【０００９】
私達は、分配システムは、マッチングを増加するために有利に配列することができることを理解した。
【００１０】
【発明の要約】
発明は、第１仲介ノード、第２仲介ノード、及び該第１仲介ノードと該第２仲介ノードの間で接続される少なくとも１つの中間マッチングノードを備える金融証券を取り引きするためのコンピュータトレーディングシステムを提供し、各仲介ノードは、仲介機能を実行し、ノードはともに、分配ネットワーク及び該分配ネットワークに接続される複数のトレーダー端末を備え、そこではノードのそれぞれが、取引のために使用できる呼び値の記憶装置、融和性のある呼び値と複数のトレーディングエージェントのそれぞれによって提出される注文をマッチングするためのマッチング機構を備え、そこでは中間マッチングノードが、第１仲介ノードから第２仲介ノードに伝送された取引を要求するメッセージを傍受するための手段と、第１仲介ノードによって提案される取引が失敗することを検出するための手段と、取引に使用可能な呼び値の記憶装置から呼び値との代替一致を提案するための手段とを含む。
【００１１】
中間ノードがマーケットビューをトレーダーに提供する仲介機能を提供する要件はないため、中間ノードが仲介ノードである必要はない。それにもかかわらず、ネットワークは、好ましくは、任意の中間ノードが仲介ノードでもあるように配列される。これは、分配ネットワークが単に１種類のノード、つまり仲介ノードを備え、新規に接続されるトレーダーが、仲介機能を提供できる任意の選ばれたノードに接続できるようにするという点で配備に柔軟性を与える。
【００１２】
再一致のために選ばれる呼び値は、公正さを提供するために呼び値の記憶装置内で第２呼び値でなければならない。
【００１３】
複数の中間ノードが再一致を試し、実行し、競合を引き起こす可能性を回避するために、中間ノードは、それが一致の少なくとも片側のオーナーである場合にだけ再一致を提案する。注文のオーナーは、その注文をトレーダーから最初に受信する仲介ノードである。これにより、複数の再一致が発生するのを防ぐ。
【００１４】
分配ネットワークのための選ばれた構造は、クリーク内にノードを配置させ、その場合、中間ノードは、それが別のクリーク内のノードから一致の両側についての情報を受信した場合にだけ再一致を提案する。
【００１５】
発明の実施態様が、ここでれいによってだけ、及び添付図面に関して説明されるだろう。
【００１６】
【好ましい実施態様の説明】
実現するシステムの目的は、トレーダーが、その後システム内でマッチングされる呼び値及び注文を入力できるようにすることである。システムは、少なくとも以下の証券を取り引きするためのプラットホームを提供する。つまり、ＦＸスポット、ＦＲＡ、及び先物とやはりＦＸ先物、ＣＦＤ、短期政府及び／または中央銀行券、商業手形、ＣＤ、銀行間預金、商業手形、レポート、金利先物、スワップ、オプション、及びこれらの基本商品の注文変形の寄せ集めである。これらはすべて金融証券と呼ばれる。
【００１７】
トレーダー端末にいるトレーダーは、その後、システム全体での複数の仲介ノードのそれぞれに渡される呼び値及びヒットを提出する。呼び値とは、「市場を作る」ためにトレーダーによって提出される入札またはオファー注文であり、マーケットビューの一部としてその他のトレーダーに分配される。呼び値はこのようにしてその他のトレーダーの目に見える注文である。ヒットは、１つまたは複数の呼び値から引き出された自分のマーケットビューに表示される価格に基づいて取引を生じさせることを希望するトレーダーによって提出される買いまたは売りである。ヒットは、その他のトレーダーの目には見えない注文である。図１のコンピュータトレーディングシステムは、それぞれが複数の仲介ノードの少なくとも１つの接続される複数のトレーディングエージェント１０を備える。各トレーディングエージェントは、トレーダー端末がそれによってトレーディングシステムにアクセスする手段である。
【００１８】
トレーダー端末（図示されていない）は、取り引きされる金融証券について、（通常特殊キーパッドを使用して）呼び値及び注文を提出し、使用可能な価格と額を含むマーケットビューデータを表示するように構成されるワークステーションまたはそれ以外のコンピュータ端末であってよい。トレーダーは、典型的には、トレーダーを取引所の一部として配置する銀行などの金融機関の一部として分類される。取引所は、その他の取引所に対して取引所の信用枠を割り当てる取引所管理者の共通管理の元にあるトレーダーのグループである。トレーダー、またはトレーダーのグループ向けのマーケットビューは、トレーダーが市場を反映することが分かる市場情報（価格、量等）である。マーケットビューは、好ましくは市場融和性のために試写される。
【００１９】
実施するシステムは、ブローカーによって作成されるマーケットビューが、価格の出所を特定しないで価格及び額の情報を備える匿名トレーディングシステムである。使用可能な入札とオファーに表示される価格及びそれらの価格で使用可能な総額は、このようにして１つまたは複数の呼び値の総額である。試写信用基準を満たした関係者の呼び値だけが、表示される総額価格に含まれる。仲介ノードによって作成されるマーケットビューは、このようにして、信用割当に応じてある取引所から別の取引所で異なる。
【００２０】
トレーディングエージェントノードは、特定の取引所またはトレーダーのグループにサービスを提供する。これらのサービスは、トレーディングワークステーションごとにネットワークへのアクセスを提供することと、取引を完了すること、取引チケットを作成することと、トレーダー向けに履歴取引情報を維持することとを含む。各トレーディングエージェントノードは、トレーディングシステムにアクセスするために少なくとも１つの仲介ノードと接続しなければならない。トレーダー端末のグループは、このようにして、システムにアクセスするためにトレーディングエージェント１０に接続する。
【００２１】
各仲介ノード１２は、基本注文マッチングサービス及び価格分配サービスを提供する。仲介ノードは、より高速な通信経路選択を可能にするクリークツリー（Ｃｌｉｑｕｅ Ｔｒｅｅ）と呼ばれる構造内に配列され、非常に特殊であるが単純な規則に従う。クリークツリーは、個々のノードがクリークの中に分類されるネットワーク構造であり、クリークはそれからツリー構造に配列される。各ブローカーは、論理的に、その隣人ブローカーと呼ばれる、数多くのブローカーにリンクすることができる。ブローカー間の通信は平等なレベルにあり、ネットワーク内に「アップ」または「ダウン」方向はない。
【００２２】
トレーディングエージェントは、少なくとも１つの仲介ノードに接続されなければならないが、彼ら自体は、クリークツリーの構成要素ではないが、構造の外にとどまる。複数の仲介ノードに接続されるトレーディングエージェントは、市場価格の複数の集合を受け取るだろう。異なる仲介ノードからの価格情報が実質的には同じであっても、情報は異なる間隔で受信されてよい。トレーディングエージェントは、指定の取引注文を１つの仲介ノードだけに送信するだろう。
【００２３】
用語仲介ノードは、仲介機能を提供するコンピュータネットワーク内の物理的なノードまたは論理的なノードとして配列されるコンピュータを記述するために使用される。基本的な仲介機能は、呼び値の記憶、該呼び値をマーケットビューという形でトレーダーに提供すること、及び呼び値と注文をマッチングすることである。記述された実施態様の仲介ノードは、追加機能も実行するが、これらは仲介ノードとして定義される内容の本来の特徴ではない。
【００２４】
仲介ノードは互いに等しく、同じ機能を実行する。ネットワークの配列またはその中でのそれらの位置は、仲介ノードにはトランスペアレントである。それらは、自分達の隣人について知ってさえいればよい。各仲介ノードは、市場内のすべての注文に関する知識を有し、注文が提出されるとすぐにそれらをマッチングできるようにする。各仲介ノードが市場内の注文の完全なリストを維持するという事実の結果として、それは、トレーディングエージェントによって必要とされるようにマーケットビューをカスタマイズすることができ、それが受信されるとすぐに市場情報により高速に反応することができる。
【００２５】
分配仲介ノード配列の目的を理解するために、価格分配及び取引実行が、図２に関してここに説明されるだろう。
【００２６】
取引プロセスは、一人または複数のトレーダーがトレーダー端末の中に注文を注文して、開始する。注文は、価格及び額などの特定の制限付きで購入または販売するための命令による、トレーダーからの取引要求である。呼び値は、システム内で使用可能なままとなる永続的な注文であり、市場価格情報の一部として分配される。呼び値は、「市場を作る」ために使用され、トレーダーにとっては入札またはオファーとして知られる。ヒットは、「目に見えない」及び「満たすか殺す（ｆｉｌｌ ｏｒ ｋｉｌｌ）」特性を有する注文である。ヒットは、市場価格の一部として分配されない。ヒットは、システムに留まらない。それが入力時に取り引きできない場合には、それは削除される。
【００２７】
注文帳は、市場で使用可能なすべての注文のリストである。呼び値は唯一使用可能な注文であるため、該帳は、呼び値のリストから成り立つ。呼び値は、正しいディーリング順序で待ち行列内に配列される。待ち行列の並べ替え順序は、異なる取引証券について変わる可能性がある。デフォルトの並べ替え順序は、価格及び時刻単位である。システム内では、各仲介ノードは、すべての使用可能な呼び値の完全なリストを維持する。
【００２８】
システム内でのメッセージフローは、それぞれがネットワーク全体で適切なパラメータを付けている名前が指定されたメッセージによって記述される。呼び値（永続的な注文）を提出するプロセスは、トレーディングエージェントが、トレーダーが入札またはオファーを発行したとレーダーワークステーションから情報を受信すると開始する。それから、トレーディングエージェントは呼び値提出プロセスを開始する。トレーディングエージェントがトレーダーワークステーションから呼び値情報を受信すると、それは呼び値についてのコンテキストを作成し、維持するだろう。それから、それは、呼び値提出メッセージを、それが接続されている仲介ノードに送信するだろう。仲介ノードは呼び値を実証し、有効である場合にはそれを受け入れるだろう。呼び値を受信するこの第１仲介ノードが、この呼び値の「オーナー」仲介ノードになる。図２に図示される例では、これは仲介ノード５である。これが、取引に呼び値をコミットできる唯一の仲介ノードである。仲介ノードは、コンテキスト、つまり「呼び値オブジェクト」を作成し、正しい取り引きできる証券のその待ち行列の中にそれを分類するだろう。
【００２９】
呼び値がその待ち行列に格納された後、オーナー仲介ノードは、ＱｕｏｔｅＡｖａｉｌａｂｌｅメッセージをその他の仲介ノードに送信することによってネットワーク全体で呼び値を分配するだろう。この例では、仲介ノード５は、ＱｕｏｔｅＡｖａｉｌａｂｌｅメッセージを仲介ノード２と６に送信する。各仲介ノードがメッセージを受信すると、それはコンテキスト（呼び値オブジェクト）を作成し、それをその待ち行列（注文帳）の中に分類する。それは、仲介ノードがそれにメッセージを送信したコンテキストで注をつける。それを待ち行列の中に格納した後、仲介ノードは、ＱｕｏｔｅＡｖａｉｌａｂｌｅメッセージを、一斉送信経路選択規則を使用して、その他のクリーク内のすべての隣人に送信する。したがって、仲介ノード２はそれを１、３及び４に送信する。それから、仲介ノード４は、それを仲介ノード７に送信する。この時点で、すべての仲介ノードは呼び値について知っており、その注文帳を相応して更新する。
【００３０】
一斉送信経路選択規則は、ネットワークトラフィックが効率的に取り扱われることを保証するため、及びメッセージフローの重複を削減するために適用される。
【００３１】
一斉送信規則は以下のとおりである。
１．情報を発信する仲介ノードは、それをその隣人仲介ノードのすべてに送信するだろう。
２．該情報を受信する仲介ノードは、該情報を送信した仲介ノードと同じクリーク内にある仲介ノードを除くその隣人仲介ノードのすべてにそれを送信するだろう。
３．メッセージが、呼び値などの永続的な情報を含む場合、情報は、情報が受信された仲介ノードの識別子とともに記憶されるだろう。
【００３２】
これらの規則が情報を含むメッセージではなく、情報を参照することに注意する。例えば、呼び値についての情報は、ＰｒｏｐｏｓｅＤｅａｌメッセージ中である仲介ノードに、ＭａｒｋｅｔＵｐｄａｔｅメッセージの中で別の仲介ノードに送信されてよい。しかしながら、同じ情報が両方の仲介ノードに送信されるため、前記規則が適用する。
【００３３】
価格分配は、市場情報をトレーダー端末にいるトレーダーに提供するプロセスである。この情報は、仲介ノードで作成され、トレーダーへの分配のためにトレーディングエージェントに送信される。このプロセスは、図３に示される。
【００３４】
各仲介ノードは、その呼び値の待ち行列（注文帳）を調べ、それに接続されているトレーディングエージェントごとに市場のビューを計算するだろう。このビューは、具体的にはエージェントが表す取引所について構築される。ビューは、信用度またはそれ以外の要因に基づいて異なってよい。マーケットビューを決定するための正確なプロセスは、取引証券に基づいて変わるだろう。ビュー情報は、ＭａｒｋｅｔＶｉｅｗメッセージの中でトレーディングエージェントに送信される。
【００３５】
呼び値をヒットするのは、二人のトレーダー間で取引を生じさせる基本的なプロセスである。あるとレーダーからのヒットは、別のトレーダーからの呼び値にマッチングされる。このプロセスは、図４に図示される。自分のマーケットビューディスプレイに表示される価格をヒットするトレーダー端末のトレーディングエージェントは、ＨｉｔＳｕｂｍｉｔメッセージを仲介ノードに送信する。このメッセージは、特定の呼び値ではなく価格を目標にする。仲介ノードは、その呼び値を走査し、ヒットにマッチングできる待ち行列内の第１呼び値を見つけ出すだろう。マッチング規則は、取引証券に基づいて変化してよい。
【００３６】
ヒットが呼び値にマッチングされると、仲介ノードは、該呼び値についてのそのコンテキストを修正し、マッチングされた総額を「使用可能」から「予約済み未決額」に移動する。これによって、同額の呼び値が別のヒットとマッチングされるのが防がれるだろう。それから、仲介ノードは、それが呼び値をそこから受信した仲介ノードにＰｒｏｐｏｓａｌＤｅａｌメッセージを送信するだろう。このメッセージは特定の呼び値を目標とするだろう。この例では、ブローカー７はメッセージをブローカー４に送信するだろう。
【００３７】
各仲介ノードがＰｒｏｐｏｓａｌＤｅａｌメッセージを受信すると、それはその待ち行列内の呼び値をチェックする。提案された取引の総額が依然として待ち行列で使用可能である場合には、仲介ノードは、マッチング仲介ノードと類似したプロセスを実行する。提案された取引の総額は「使用可能」から「予約済み未決額」に移動されるだろう。その後、ＰｒｏｐｏｓｅＤｅａｌメッセージが、それが呼び値を受信した仲介ノードに送信される。例では、仲介ノード４は、それを仲介ノード２に送信する。仲介ノード２は、それを仲介ノード３に送信するだろう。
【００３８】
ＰｒｏｐｏｓｅＤｅａｌメッセージの経路選択は、目標とされた経路選択規則に従う。目標とされた経路選択は、ある特定の仲介ノードに情報を送達するために使用される。特定の仲介ノードの知識はシステムの中に組み込まれないため、目標はある特定の仲介ノードではなく、情報発信元の仲介ノードである。例えば、メッセージは「仲介ノード７１４」に送信されないが、「呼び値４２を発する仲介ノード」として送信される。目標とされる規則は以下のとおりである。
１．情報のある特定の部分についてのメッセージを発する仲介ノードは、それがそこから元の情報を受信した仲介ノードに該メッセージを送信するだろう。
２．情報のある特定の部分についてのメッセージを受信する仲介ノードは、それがそこから元の情報を受信した仲介ノードに該メッセージを送信するだろう。
【００３９】
メッセージは、このようにして元の情報の経路をその出処まで遡るだろう。例では、これは、仲介ノード２と４を直接経由して、仲介ノード７から仲介ノード２へである。
【００４０】
呼び値を最初に作成した仲介ノードがＰｒｏｐｏｓｅＤｅａｌメッセージを受信すると、それは他のブローカーと同じチェック及び総額予約を実行する。この仲介ノードが呼び値を所有するため、それが呼び値を取引に対しコミットする権限を有する。ＰｒｏｐｏｓｅＤｅａｌメッセージは、該取引に対してヒットをコミットする権限を表す。仲介ノードは、その後、呼び値を提出したトレーディングエージェントにＨｉｔＡｍｏｕｎｔメッセージを送信することにより取引プロセスを開始するだろう。取引実行プロセスは、後述される。
【００４１】
取引マッチングプロセスが起こるので、各仲介ノードで維持される呼び値のリストが最新にされていることが必要である。これは、図５に示されるように、それが呼び値に変更を加えるときに、各仲介ノードが他に通知することによって達成される。
【００４２】
各仲介ノードがその待ち行列で呼び値を変更すると、それは、それがそこから変更を受信したクリーク内のノードを除きすべての隣人仲介ノードに通知する。前記例では、仲介ノード４は、ＰｒｏｐｏｓｅＤｅａｌメッセージの中で仲介ノード７からの呼び値の変化について通知を受信した。それは、ＰｒｏｐｏｓｅＤｅａｌメッセージを送信することによって仲介ノード２に通知する。仲介ノード４は、ここで仲介ノード１と３に通知しなければならない。これは、これらの仲介ノードにＭａｒｋｅｔＵｐｄａｔｅメッセージを送信することによって行われる。
【００４３】
通常の経路選択規則に従い、呼び値についての情報は、ネットワーク内の各仲介ノードに分配される。ＭａｒｋｅｔＵｐｄａｔｅメッセージを受信する任意の仲介ノードは、それがそこから受信されたのではないクリークの中のすべての隣人にそれを渡すだろう。ＰｒｏｐｏｓｅＤｅａｌメッセージを送信する仲介ノードが、ＭａｒｅｋｅｔＵｐｄａｔｅメッセージを同じ仲介ノードに送信してはならないことに注意する。この結果、重複情報が受信され、取引総額が２度予約されることになるだろう。
【００４４】
取引実行プロセス自体は本発明の中心ではないが、ここで完全性のために説明されるだろう。前述したように、取引マッチングプロセスが完了すると、取引実行プロセスが開始する。このプロセスは、取引を完了し、トレーダーを取引にコミットする。プロセスは図６に示されている。マッチングが行われ、取引が開始すると、情報はトレーダーが入手できるようになる。この情報は、トレーダーに、取引が未決であることを知らせるために使用できる。指定されるトレーディングアプリケーションは、トレーダーに知らせるべきかどうかを決定できる。いずれにせよ、情報は入手できる。
【００４５】
買い手のトレーディングエージェントは、初期マッチング行われ、ＰｒｏｐｏｓｅＤｅａｌメッセージが送信されるとすぐに通知されるだろう。このエージェントは、この時点でトレーダーワークステーションに通知することができる。この未決取引情報は、マッチングプロセスが続行するにつれて変化してよい。作り手ワークステーションは、作り手のトレーディングエージェントが信用度をチェックし、ＤｅａｌＳｔａｔｕｓＭａｋｅｒメッセージを送信すると、未決取引について知らされる。
【００４６】
作り手のトレーディングエージェントがその仲介ノードからＨｉｔＡｍｏｕｎｔメッセージを受信すると、取引実行プロセスが開始する。このメッセージは、エージェントに、その呼び値の１つについてマッチングが行われたことを知らせる。メッセージは、ヒットの総額、対向関係者及びヒットのアイデンティティだけではなく、呼び値も特定する。エージェントは、呼び値が依然として使用できることを確認するために、トレーダーワークステーションとチェックするだろう。エージェントは、ワークステーションにＨｉｔＡｍｏｕｎｔＷＳメッセージを送信するだろう。ワークステーションは、ワークステーションが依然として作動中であり、トレーダーが呼び値を中断しなかたことを示すためにＨｉｔＡｍｏｕｎｔＡＣＫメッセージで応答するだろう。この時点で、トレーダーは、もはや取引を中断することはできない。
【００４７】
トレーディングエージェントは、次に対向関係者との使用可能な貸し金をチェックするだろう。貸し金チェックは、取引を可能にするか、取引の総額を減額するか、あるいは取引を禁じてよい。それから、エージェントは、取引に必要とされる総額分、使用可能な貸し金を減額するだろう。使用可能な貸し金のこの減額は、将来の取引に影響を及ぼす可能性がある。作り手のトレーディングエージェントは、ここで、ＤｅａｌＳｔａｔｕｓＭａｋｅｒメッセージをその仲介ノードに送信することによって、買い手のトレーディングエージェントに取引を知らせるだろう。メッセージは、ヒットのアイデンティティに向けられる。ネットワーク仲介ノードは、ヒットのオーナー仲介ノードにメッセージを送り、その仲介ノードがそれを買い手のエージェントに送達するだろう。いったんこのメッセージが送信されると、作り手のエージェントは、取引が実行された可能性があるが、取引が応答まで不確かであることを知る。買い手のトレーディングエージェントは、取引実行プロセスを完了する。プロセスのこの部分は、エージェントが作り手からＤｅａｌＳｔａｔｕｓＭａｋｅｒメッセージを受信すると起こる。メッセージが有効な取引を示す場合には、プロセスは続行する。
【００４８】
買い手のトレーディングエージェントは、次に、作り手と同様に対向関係者との使用可能な貸し金についてチェックするだろう。貸し金チェックは、取引を可能にするか、取引の総額を減額するか、あるいは取引を禁じてよい。それから、エージェントは、取引に必要とされる総額分、使用可能な貸し金を削減するだろう。使用可能な貸し金のこの減額は、将来の取引に影響を及ぼす可能性がある。買い手のトレーディングエージェントは、ここで、取引をそのディスクにログ記録するだろう。情報が永続記憶にコミットされるとすぐに、取引は実行される。取引ステータスについてのあらゆるチェックは、ここで拘束力のある取引を示すだろう。エージェントはここでトレーダーに通知し、取引チケットを印刷し、それ以外の取引後処理を実行するだろう。この時点で取引は実行されるが、作り手はまだ知らない。取引が実行されるとすぐに、買い手のトレーディングエージェントは、その仲介ノードにＤｅａｌＳｔａｔｕｓＴａｋｅｒメッセージを送信することによって作り手に通知するだろう。このメッセージは呼び値に向けられ、作り手のエージェントに送られるだろう。
【００４９】
ＤｅａｌＳｔａｔｕｓＴａｋｅｒメッセージは、取引についての最終的な情報、したがって呼び値に対する最終変更を含む。この情報がネットワーク仲介ノード及びトレーディングエージェントによって使用される。ＤｅａｌＳｔａｔｕｓＴａｋｅｒメッセージが仲介ノードを通って送られると、それぞれの送る側の仲介ノードが情報を使用し、その呼び値コンテキストを更新するだろう。取引の総額は「予約済み」から「完了」に移される。呼び値が依然としてアクティブである場合には、実行されていない部分は「予約済み」から「使用可能」に移される。それは、その後、ネットワーク経路選択規則を使用して、ＭａｒｋｅｔＵｐｄａｔｅメッセージを他のすべての仲介ノードに送信することによって、他の仲介ノードに変更及び取引を知らせるだろう。
【００５０】
ＤｅａｌＳｔａｔｕｓＴａｋｅｒメッセージが呼び値のオーナー仲介ノードに到達すると、それは、それをトレーディングエージェントに送信するだろう。エージェントは、取引をディスクに記録するだろう。この時点で、取引はもはや不確かではない。エージェントは、トレーダーに通知し、チケットを印刷し、必要とされる他の処理を実行するだろう。いくつかの取引証券は、取引のために交換される追加情報を必要とすることがある。この例は、ＥＢＳスポットＦ／Ｘの決済証券である。この種の情報は、ＤｅａｌＩｎｆｏｒｍａｔｉｏｎメッセージの中で送信される。取引が処理された後、エージェントはこの情報を作成できる。ｄｅａｌＩｎｆｏｒｍａｔｉｏｎメッセージは、仲介ノードに送信される。それから、ネットワーク仲介ノードは、情報が証券によって必要とされるとして処理される他のエージェントに、メッセージを送るだろう。取引は、このようにして完了される。
【００５１】
ここで再一致プロセスが図７と図８に関して説明されるだろう。前述されたように、マッチング仲介ノードが、専用の待ち行列に基づいて一致を作成する。しかしながら、呼び値の変更が進行中である場合がある。したがって、マッチングされている呼び値は所有仲介ノードでは使用できない可能性がある。アーキテクチャは、効率的に検出及び再一致に対処する。
【００５２】
この例では、第２呼び値は、元の呼び値と同じ価格について仲介ノード３に接続されるエージェントから提出された。この新しい呼び値は分配され、第２にそれぞれのノードの待ち行列に入る。
【００５３】
２つまたは３つの競合するイベントがほぼ同時に起こるときに、一致の失敗が発生するらしい。よい価格が入力され、多くのトレーダーがそれを一度にヒットしようと試みるとき、これは一般的である。第１ヒットによって、価格は市場から採取され、その後ヒットは失敗する。
【００５４】
前記例では、仲介ノード７が、一致を実行し、ＰｒｏｐｏｓｅＤｅａｌメッセージを送信する。同時に、仲介ノード５が、呼び値を使用不能にするイベントを処理する。それはＭａｒｋｅｔＵｐｄａｔｅメッセージを送信する。これらのメッセージはともに仲介ノード２に出現する。
【００５５】
仲介ノードが一致に適していない呼び値についてＰｒｏｐｏｓｅＤｅａｌメッセージを受信すると、一致失敗状況が発生する。再一致が起こらない場合、仲介ノードは、それがそこからＰｒｏｐｏｓｅＤｅａｌメッセージを受信した仲介ノードにＰｒｏｐｏｓｅＤｅａｌＦａｉｌメッセージを送り返すだろう。アーキテクチャは、情報が既知となる第１点でこれが起こるように対処する。これが効率的な処理の手立てとなる。
【００５６】
この例では、仲介ノード２が、最初に、ＭａｒｋｅｔＵｐｄａｔｅメッセージを受信し、処理する。これによって、第１呼び値が使用不能と記される。それから、それはＰｒｏｐｏｓｅＤｅａｌメッセージを受信する。メッセージを処理するとき、それは呼び値をこのヒットにマッチングできないと判断する。そこでＰｒｏｐｏｓｅＤｅａｌは失敗する。ＰｒｐｏｓｅＤｅａｌメッセージはマッチング仲介ノードの側でのコミットメントを表すため、失敗側仲介ノードは、可能であるならば取引を再マッチングすることができる。中間仲介ノードで再一致を可能にすると、ネットワークの追及は妨げられ、効率的なマッチングの手立てとなる。これは、失敗を最初に検出した仲介ノードによって、または初期一致を行った仲介ノードに戻る経路の中の別の仲介ノードによって行うことができる。
【００５７】
再一致プロセスは、これらの規則に従う。
１．再一致は、優先順位待ち行列上の次に使用可能な呼び値とだけ実行される。
２．再一致は、それが一致の少なくとも一方の側（ヒットまたは呼び値）の所有者である場合にだけ仲介ノードによって実行できる、あるいは
３．再一致は、それが異なるクリークのブローカーから一致の両側を受信した場合だけ仲介ノードによって実行できる。
【００５８】
規則は、以下の理由からこのように並べられている。買い手の仲介ノードに提出される初期注文は、買い手の側の取引を行うというコミットメントを表す。したがって、呼び値を注文にマッチングする権限は、ネットワークを通してＰｒｏｐｏｓｅＤｅａｌメッセージとともに渡される。ＰｒｏｐｏｓｅＤｅａｌメッセージは、マッチング及び再マッチングを行う権限も伝えられるように、ある中間ノードから別の中間ノードに渡される。ＰｒｏｐｏｓｅＤｅａｌメッセージを渡す仲介ノード以外の仲介ノードに、再一致を行う権限が与えられないことは、これが重複マッチングにつながり、競合を解くためのネットワーク内のメッセージフローを増やすために重要である。
【００５９】
規則は、任意の一時に、ただ１つの仲介ノードだけが再一致を試みる権限を有し、メッセージの不必要な重複が発生しないことを確実にする。これらの規則が満たされると、仲介ノードは、再一致プロセスを開始できる。満たされない場合には、一致は失敗する。
【００６０】
このケースでは、ＰｒｏｐｏｓｅＤｅａｌＦａｉｌメッセージが送信される。例では、仲介ノード２は、元の一致が失敗したと判断する。それは、その待ち行列をチェックし、ＰｒｏｐｏｓｅＤｅａｌのヒットが待ち行列の第２呼び値と一致できることが分かる。それは、仲介ノード４からのＰｒｏｐｏｓｅＤｅａｌメッセージ中でヒットを受信した。仲介ノード３と４は、同じクリークにいるので、規則は満たされず、仲介ノード２は再一致を実行する権限を有さない。ＰｒｏｐｏｓｅＤｅａｌＦａｉｌメッセージが仲介ノード４に送信される。
【００６１】
規則が従われず、仲介ノード２が再一致を実行すると、ＰｒｏｐｏｓｅＤｅａｌメッセージが仲介ノード２から仲介ノード３に送信され、ＭａｒｋｅｔＵｐｄａｔｅメッセージがクリーク内のそれ以外のブローカーに送信されるだろう。しかしながら、その結果、仲介ノード３は仲介ノード２による一致を通知されず、それ以降、仲介ノード２を介して仲介ノード７に取引完了メッセージを送信するだろう。その結果、いま、通常の経路選択規則を使用するそれ以降の情報の経路選択で余分な経路がある。これが第３の規則によって妨げられる。
【００６２】
再一致規則が満たされると、ブローカーは再一致を実行するだろう。最初に、ブローカーは呼び値についてのそのコンテキスト（呼び値オブジェクト）を修正し、一致の総額を「使用可能」から「未決取引予約」に移動するだろう。それから、それは、それがそこから呼び値を受信したブローカーにＰｒｏｐｏｓｅＤｅａｌメッセージを送信するだろう。このメッセージは、元のＰｒｏｐｏｓｅＤｅａｌメッセージからヒットを参照するだろう。ブローカーは、それが元のＰｒｏｐｏｓｅＤｅａｌメッセージを受信したブローカーにＰｒｏｐｏｓｅＤｅａｌＵｐｄａｔｅメッセージも送信するだろう。
【００６３】
前記例では、仲介ノード４はＰｒｏｐｏｓｅＤｅａｌＦａｉｌメッセージを受信する。それは待ち行列をチェックし、第２呼び値と再マッチングすることができる。それから、それは仲介ノード３に、それにヒットについて通知するためにＰｒｏｐｏｓｅＤｅａｌメッセージを送信する。それは、仲介ノード７に、それにヒットの一致の変化について通知するためにＰｒｏｐｏｓｅＤｅａｌＵｐｄａｔｅメッセージも送信する。
【００６４】
再一致プロセスの間、ネットワーク内のすべての仲介ノードは、呼び値のすべての変更について知っている。一致失敗または再一致は、他の仲介ノードに分配されなければならない呼び値のステータスの変更を生じさせる結果となる。通知プロセスは、見失われた通知または重複通知の容易な可能性を回避するために慎重な経路選択制御を必要とする。通知を必要とする複数の状況がある。それぞれが、一貫した信頼できる方法で取り扱われなければならない。異なる通知種類は以下のとおりである。
１．取引失敗の場合、元のマッチング仲介ノードに戻る経路に沿って呼び値予約を解除する（ｕｎｗｉｎｄｉｎｇ）。
２．新規取引の場合、呼び値予約の元のマッチングブローカーに戻る経路に沿って仲介ノードに通知する。
３．新規取引の場合、呼び値予約について、新しい所有ブローカーへの前方経路に従って仲介ノードに通知する。
４．両方の取引の場合、取引経路上にないクリーク内の仲介ノードに通知する。
【００６５】
このプロセスの一部は図８に示される。これは、前述の例で仲介ノード４によって行われる通知を示す。仲介ノードは、それが２つの簡略な規則に従う場合は、別の仲介ノードによって加えられた変更を解除する変更を加える。
１．変更中である元の情報を送信した仲介ノードに通知する。
２．元の情報を使用することによって通知されるだろうあらゆる仲介ノードに通知する。
【００６６】
このようにして、ネットワーク経路選択規則は、元の情報のフローという観点から辿られる。規則は、解除する変更の観点から見られる場合は適用しないように見える。この一貫性は、重複する通知または見失われた通知を回避するために必要とされる。
【００６７】
前述の例では、仲介ノード２は、ＰｒｏｐｏｓｅＤｅａｌメッセージの中で仲介ノード４から呼び値変更の通知を受信する。それから、それは呼び値変更を解除する一致に失敗する。それは、ＰｒｏｐｏｓｅＤｅａｌＦａｉｌメッセージを送信することによって、情報の発信者、仲介ノード４に通知する。仲介ノード２が元の呼び値の変更を他のブローカーに通知しなかったため、それは追加通知を送信しない。
【００６８】
仲介ノード４はＰｒｏｐｏｓｅＤｅａｌＦａｉｌメッセージを受信する。これにより、それはその元の呼び値変更を解除する。それは仲介ノード７から元の情報を受信したので、それはそのブローカーに通知する。それは元の情報を仲介ノード１と３に送信したので、それはこれらのブローカーにＭａｒｋｅｔＵｐｄａｔｅメッセージの中で新しい情報を送信する。
【００６９】
再一致の第２部分は、新しい呼び値変更を生じさせる。この新しい情報は、解除と同様に分配される。呼び値の所有仲介ノードへの経路での前方への分配のため、通常のマッチング規則が適用する。各仲介ノードは、ＰｒｏｐｏｓｅＤｅａｌメッセージの中で呼び値の出所に情報を送信する。それは、ＭａｒｋｅｔＵｐｄａｔｅメッセージの中で、同じクリーク内の他の仲介ノードに、あるいは関係のないクリークにそれを送信する。元のマッチング仲介ノードへの経路で情報を送り返す場合はプロセスはわずかに異なる。情報は、ＰｒｏｐｏｓｅＵｐｄａｔｅメッセージの中で、元のＰｒｏｐｏｓｅＤｅａｌメッセージを送信した仲介ノードに送信される。この同じクリークの他の仲介ノードにはメッセージは送信されず、それらは、情報を受信する仲介ノードによって通知されるだろう。取引の経路上にいないクリーク内のすべての仲介ノードについては、通常の規則が適用する。これらは、ＭａｒｋｅｔＵｐｄａｔｅメッセージによって両方の変更について通知されるだろう。これらのブローカーは、指定された変更が別のものを解除することも知らない。
【図面の簡単な説明】
【図１】発明を実現するトレーディングシステムの概要である。
【図２】新しい呼び値がシステム内で提出されるときのメッセージのフローを示す。
【図３】トレーダーに対するマーケットビューの作成を描く。
【図４】トレーダーが買い注文または売り注文を提出するときのメッセージのフローを示す。
【図５】買い注文または売り注文の後に仲介ノードを更新するためのメッセージのフローを示す。
【図６】取引実行プロセスを示す。
【図７】中間ノードでの失敗した一致の検出を示す。
【図８】再一致に続く市場更新分配を示す。
【図１】
2004501454.tif 000003
【図２】
2004501454.tif 000004
【図３】
2004501454.tif 000005
【図４】
2004501454.tif 000006
【図５】
2004501454.tif 000007
【図６】
2004501454.tif 000008
【図７】
2004501454.tif 000009
【図８】
2004501454.tif 000010
【国際公開パンフレット】
2004501454.tif 000011
2004501454.tif 000012
2004501454.tif 000013
2004501454.tif 000014
2004501454.tif 000015
2004501454.tif 000016
2004501454.tif 000017
2004501454.tif 000018
2004501454.tif 000019
2004501454.tif 000020
2004501454.tif 000021
2004501454.tif 000022
2004501454.tif 000023
2004501454.tif 000024
2004501454.tif 000025
2004501454.tif 000026
2004501454.tif 000027
2004501454.tif 000028
2004501454.tif 000029
2004501454.tif 000030
2004501454.tif 000031
2004501454.tif 000032
2004501454.tif 000033
2004501454.tif 000034
2004501454.tif 000035
2004501454.tif 000036
2004501454.tif 000037
2004501454.tif 000038
2004501454.tif 000039
2004501454.tif 000040
2004501454.tif 000041
2004501454.tif 000042
2004501454.tif 000043
2004501454.tif 000044
2004501454.tif 000045
【国際公開パンフレット（コレクトバージョン）】
2004501454.tif 000046
2004501454.tif 000047
2004501454.tif 000048