特表 2023-540449 分散型システムでの受入時のローカル及びグローバルなサービス品質シェーパ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-09-25

(54)【発明の名称】分散型システムでの受入時のローカル及びグローバルなサービス品質シェーパ

(51)【国際特許分類】

   H04L 47/263 20220101AFI20230915BHJP

【ＦＩ】

H04L47/263

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023508091

(86)(22)【出願日】2021-08-05

(85)【翻訳文提出日】2023-04-03

(86)【国際出願番号】 US2021044591

(87)【国際公開番号】W WO2022031880

(87)【国際公開日】2022-02-10

(31)【優先権主張番号】16/988,212

(32)【優先日】2020-08-07

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＨＤＭＩ

２．ＦＩＲＥＷＩＲＥ

３．イーサネット

(71)【出願人】

【識別番号】519435991

【氏名又は名称】ハイアニス・ポート・リサーチ・インコーポレーテッド

【氏名又は名称原語表記】ＨＹＡＮＮＩＳ ＰＯＲＴ ＲＥＳＥＡＲＣＨ，ＩＮＣ．

(74)【代理人】

【識別番号】100087941

【弁理士】

【氏名又は名称】杉本 修司

(74)【代理人】

【識別番号】100112829

【弁理士】

【氏名又は名称】堤 健郎

(74)【代理人】

【識別番号】100142608

【弁理士】

【氏名又は名称】小林 由佳

(74)【代理人】

【識別番号】100155963

【弁理士】

【氏名又は名称】金子 大輔

(74)【代理人】

【識別番号】100150566

【弁理士】

【氏名又は名称】谷口 洋樹

(74)【代理人】

【識別番号】100213470

【弁理士】

【氏名又は名称】中尾 真二

(74)【代理人】

【識別番号】100220489

【弁理士】

【氏名又は名称】笹沼 崇

(74)【代理人】

【識別番号】100187469

【弁理士】

【氏名又は名称】藤原 由子

(74)【代理人】

【識別番号】100225026

【弁理士】

【氏名又は名称】古後 亜紀

(72)【発明者】

【氏名】アミカンギオーリ・アンソニー・ディー

(72)【発明者】

【氏名】バスト・アレン

(72)【発明者】

【氏名】ローゼン・ビー・ジョシュア

【テーマコード（参考）】

5K030

【Ｆターム（参考）】

5K030GA02

5K030HB13

5K030HD03

5K030JT09

5K030LC03

5K030MB06

5K030MB09

(57)【要約】

【課題】電子取引システムを実現するのに用いられ得るような、インバウンドメッセージのフローレートを制御する分散型コンピューティングシステムを提供する。
【解決手段】クライアント毎またはコネクション毎にインバウンドメッセージレートを制限し、コンピューティングリソースの公平なプロビジョニングを確実に支援することで、あるクライアントによるリソースの過剰利用によって本分散型システムが圧倒され、その他のクライアントが本システムとの間で相互にやり取りを行うことができないようになるのも阻止する。また、全てのクライアントコネクションを通じた総合的なインバウンドメッセージレートを、システム全体で制御することが望ましい。このようなシステム全体の制御により、本分散型システム全体として、期待されるレベルのアクセスを全てのクライアントに対して提供することを含め、必要なサービスレベルを確実に維持することができる。
【選択図】図４

【特許請求の範囲】

【請求項1】

複数のゲートウェイノードから複数のコンピュートノードおよびシステムレベルノードへのインバウンドメッセージフローを制御するように分散型データ処理システムを動作させる方法であって、
前記複数のゲートウェイノードのそれぞれにおける、
１つ以上のクライアントコネクションからメッセージを受信する過程、
クライアント毎またはコネクション毎に、前記メッセージの持続フローレートおよび／またはバーストフローレートを制御する過程、および、
前記メッセージを前記システムレベルノードに転送する過程と、
前記システムレベルノードにおける、
前記複数のゲートウェイノードのそれぞれから、前記メッセージを受信する過程、
システム全体のメッセージフローレートを制御する過程であって、前記システム全体のメッセージフローレートを制御する同過程は、さらに、前記複数のゲートウェイノードのそれぞれについて、ゲートウェイノード毎に持続フローレートおよび／またはバーストフローレートを制御することを含む、過程、および、
メッセージを前記コンピュートノードに転送する過程と、
前記複数のコンピュートノードのそれぞれにおける、
前記システムレベルノードから、前記メッセージを受信する過程、および、
前記メッセージの処理を行う過程と、
を備える、方法。

【請求項2】

請求項１に記載の方法において、前記メッセージは、複数のアプリケーション層メッセージが下位層プロトコルのパケットに含められたアプリケーション層メッセージであり、
前記持続フローレートおよび／またはバーストフローレートを制御する１つ以上の前記過程が、さらに、前記下位層プロトコルに対してフィードバックを行うことを含む、方法。

【請求項3】

請求項２に記載の方法において、前記下位層プロトコルが、トランスポート層プロトコルであり、前記フィードバックが、トランスポート層のウィンドウサイズを制御することによって行われる、方法。

【請求項4】

請求項１に記載の方法において、前記分散型データ処理システムが、電子取引システムであり、前記メッセージが、電子取引メッセージであり、前記システムレベルノードが、シーケンサノードであり、当該方法が、さらに、
前記コンピュートノードのそれぞれにおける、
前記ゲートウェイノードおよび前記シーケンサノードから、前記電子取引メッセージを受信する過程、
前記電子取引メッセージの処理を行い、電子取引機能を実行する過程、
応答メッセージを生成する過程、および、
前記応答メッセージを、１つ以上の前記ゲートウェイノードを介して、前記１つ以上のクライアントコネクションのうちの少なくとも１つによって返送する過程、
を備える、方法。

【請求項5】

請求項１に記載の方法において、持続フローレートおよび／またはバーストフローレートを制御する１つ以上の前記過程が、さらに、前記メッセージを複数のキューでキューイングすること、前記メッセージを前記キューから複数のトークンバケットに出力すること、および前記トークンバケットからメッセージを選出すること、を含む、方法。

【請求項6】

請求項５に記載の方法において、前記キューがＦＩＦＯである、方法。

【請求項7】

請求項５に記載の方法において、前記選出が、ラウンドロビン方式である、方法。

【請求項8】

請求項１に記載の方法において、前記持続フローレートおよび／またはバーストフローレートが、さらに、クライアントの要求に応答してクライアント毎またはコネクション毎に制御される、方法。

【請求項9】

請求項１に記載の方法において、前記システム全体のメッセージフローレートが、さらに、１つ以上の前記ゲートウェイノードに対してフィードバックを行うことによって制御される、方法。

【請求項10】

請求項９に記載の方法において、フィードバックを適用する前記過程は、さらに、
前記システムレベルノードから前記ゲートウェイノードへの全てのコネクションについて、コネクション毎にＴＣＰのウィンドウサイズを下げること、
前記システムレベルノードから前記ゲートウェイノードへの全てのコネクションについて、コネクション毎のトークンバケットの少なくとも１つのパラメータを調節することにより、前記持続フローレートとバーストフローレートの両方を低下させること、および、
１つ以上の前記ゲートウェイノードにメッセージを送信すること、
のうちの少なくとも１つを含む、方法。

【請求項11】

請求項１に記載の方法において、前記システム全体のメッセージフローレートが、さらに、所定の前記ゲートウェイノードを停止させることによって制御される、方法。

【請求項12】

請求項１１に記載の方法において、前記所定のゲートウェイノードを停止させる前記過程は、さらに、
前記所定のゲートウェイノードの少なくとも１つのクライアントコネクションについて、ＴＣＰのウィンドウサイズをゼロに設定すること、
前記所定のゲートウェイノードのコネクション毎ＦＩＦＯキューの１つ以上に、新しいメッセージを追加しないこと、
前記所定のゲートウェイノードのコネクション毎ＦＩＦＯキューの１つ以上からのメッセージを処理しないこと、ならびに、
前記所定のゲートウェイノードの少なくとも１つのコネクションについて、前記持続フローレートおよび／またはバーストフローレートのうちの少なくとも一方をゼロに設定すること、
のうちの少なくとも１つを含む、方法。

【請求項13】

請求項１に記載の方法において、クライアント毎またはコネクション毎に前記持続フローレートおよび／またはバーストフローレートを制御する過程が、さらに、少なくとも所定の前記ゲートウェイから所定のクライアントおよび／またはコネクションへのフローを制御すること、を含む、方法。

【請求項14】

請求項１３に記載の方法において、前記持続フローレートおよび／またはバーストフローレートを制御する前記過程が、さらに、
クライアント毎またはコネクション毎に、ＴＣＰのウィンドウサイズを下げること、ならびに、
クライアント毎またはコネクション毎のトークンバケットの少なくとも１つのパラメータを調節することにより、前記持続フローレートおよび／またはバーストフローレートを低下させること、
のうちの少なくとも１つ、を含む、方法。

【請求項15】

請求項１に記載の方法において、クライアント毎またはコネクション毎の前記持続フローレートおよび／またはバーストフローレートが、さらに、少なくとも１つのクライアントまたはコネクションを停止することによってクライアント毎またはコネクション毎に制御される、方法。

【請求項16】

請求項１５に記載の方法において、少なくとも１つのクライアントまたはコネクションを停止する前記過程は、さらに、
クライアント毎またはコネクション毎に、ＴＣＰのウィンドウサイズをゼロに設定すること、
１つ以上の前記ゲートウェイノードの、クライアント毎またはコネクション毎ＦＩＦＯに、新しいメッセージを追加しないこと、
クライアント毎またはコネクション毎ＦＩＦＯキューからのメッセージを処理しないこと、ならびに、
少なくとも１つのクライアントまたはコネクションについて、前記持続フローレートおよび／またはバーストフローレートのうちの少なくとも一方をゼロに設定すること、
のうちの少なくとも１つを含む、方法。

【請求項17】

請求項１に記載の方法において、さらに、
前記システムレベルノードにて、前記ゲートウェイノードから、完全なメッシュ型のポイントトゥポイントの一連のダイレクトコネクションによってメッセージを受信する過程、
を備える、方法。

【請求項18】

請求項１に記載の方法において、さらに、
前記システムレベルノードにおける、
前記コンピュートノードからメッセージを受信する過程、および、
前記コンピュートノードからの前記メッセージが所定のレートよりも高いレートで受信された場合、前記ゲートウェイノードからメッセージが受信されるレートを遅らせる過程、
を備える、方法。

【請求項19】

請求項１に記載の方法において、さらに、
前記コンピュートノードのそれぞれにおける、
前記コンピュートノードから受信するか又は前記コンピュートノードから前記ゲートウェイノードへと送信される前記メッセージが所定のレートよりも高いレートを上回った場合、前記ゲートウェイノードからメッセージが受信されるレートを遅らせる過程、
を備える、方法。

【請求項20】

複数のゲートウェイノードを備える、分散型データ処理システムであって、
前記複数のゲートウェイノードが、
１つ以上のクライアントコネクションからメッセージを受信し、
クライアント毎またはコネクション毎に、前記メッセージの持続フローレートおよび／またはバーストフローレートを制御し、
前記メッセージをシステムレベルノードに転送する、
ように構成されており、
前記システムレベルノードが、
前記ゲートウェイノードのそれぞれから、前記メッセージを受信し、
当該システムについてのシステム全体のメッセージフローレートを制御するように、さらに、前記ゲートウェイノードのそれぞれについて、ゲートウェイノード毎に持続フローレートおよび／またはバーストフローレートを制御し、
前記メッセージを１つ以上のコンピュートノードに転送する、
ように構成されており、
前記コンピュートノードのうちの少なくとも１つが、
前記システムレベルノードから、前記メッセージを受信し、
前記メッセージの処理を行う、
ように構成されている、分散型データ処理システム。

【請求項21】

メッセージフローを制御するようにゲートウェイノードを動作させる方法であって、
１つ以上のクライアントから、インバウンドメッセージを、１つ以上のコネクションによって受信する過程と、
前記インバウンドメッセージをシステムレベルノードに転送する過程と、
前記システムレベルノードから、フロー制御メッセージを受信する過程と、
前記フロー制御メッセージを受信すると、クライアント毎またはコネクション毎に、前記インバウンドメッセージの転送の持続レートおよび／またはバーストレートを制御する過程と、
を備える、方法。

【請求項22】

メッセージフローを制御するようにシステムレベルノードを動作させる方法であって、
複数のゲートウェイノードにて１つ以上のクライアントコネクションから受信済みのインバウンドメッセージを、当該ゲートウェイノードから受信する過程と、
前記インバウンドメッセージを複数のコンピュートノードに転送する過程と、
前記複数のゲートウェイノードにフロー制御メッセージを送信することにより、ゲートウェイノード毎に持続レートおよび／またはバーストレートを制御する過程と、
これにより、システム全体のメッセージフローレートを制御する過程と、
を備える、方法。

【請求項23】

請求項１に記載の方法において、さらに、
前記システム全体のメッセージフローレートを制御する過程が、さらに、前記システムレベルノードからフロー制御メッセージを前記複数のゲートウェイノードに送信すること、を含む、方法。

【請求項24】

請求項１に記載の方法において、前記メッセージを前記システムレベルノードに転送する過程が、さらに、階層プロトコルを用いて前記メッセージを転送することを含み、前記複数のゲートウェイノードのそれぞれから前記メッセージを受信する過程が、さらに、階層プロトコルを用いて前記メッセージを受信することを含む、方法。

【請求項25】

請求項１に記載の方法において、前記メッセージを前記コンピュートノードに転送する過程が、さらに、階層プロトコルを用いて前記メッセージを転送することを含み、前記システムレベルノードから前記メッセージを受信する過程が、さらに、階層プロトコルを用いて前記メッセージを受信することを含む、方法。

【発明の詳細な説明】

【関連出願】

【0001】

本願は、「Ｌｏｃａｌ ａｎｄ Ｇｌｏｂａｌ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｓｈａｐｅｒ ｏｎ Ｉｎｇｒｅｓｓ ｉｎ ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍ」と題する２０２０年８月７日付出願の同時係属中の米国特許出願第１６／９８８，２１２号に対する優先権を主張し、その全内容は参照をもってこれにより取り入れたものとする。

【技術分野】

【0002】

本願は、コネクテッドデバイスに関し、より詳細には、持続メッセージレートとバーストメッセージレートの双方の制御に関する。

【背景技術】

【0003】

現在、主要な証券取引所で広く使われている金融商品取引システムは、トレーダが通信ネットワークによって電子的に注文を出したり、確認通知や市場データやその他の情報を受信したりすることができる。典型的な電子取引システムは、典型的に中央サーバ内に存在するマッチングエンジンや、マッチングエンジンへのアクセスを行う複数のゲートウェイ、そして、分散型プロセッサを備える。典型的な注文過程は、次のようなものになり得る：クライアントデバイス（例えば、実人間ユーザによって操作されるトレーダ端末や自動取引アルゴリズムを実行するサーバ等）から、注文を示す要求メッセージ（例えば、買値注文および／または売値注文等）が送信されて、これが受信される。そして、典型的には、注文受付確認が、該要求を転送したゲートウェイを経由してクライアントデバイスに返送される。取引所がさらなる処理を実行したのち、注文処理確認が、クライアントデバイスへと返送され得る。

【0004】

また、取引所システムは、注文メッセージに関する情報を、受信したそのままで又は別の形式で別のシステムに流布することにより、市場データ出力を生成し得る。

【0005】

通信やデータ処理の場面において「キュー」は、一時的な格納装置と捉えられることができる。データ元は、キューにデータをプッシュする。該データは、データ消費者がキューからデータをポップする用意ができるまで、そのキュー内に何もせず居座り続ける。

【0006】

データ通信において、「フロー制御」とは、２つのノード間のデータ伝送速度を管理する処理のことである。フロー制御は、高速送信者が低速受信者を圧倒する（overwhelming）ようなことをなくす目的で利用される。これは、受信ノードがデータで圧倒されることがないように受信側で伝送速度を制御するための仕組みを供するものである。フロー制御は、長期にわたって平均的なデータ量が送信される場合のような「持続レート」や、短期的に発生する所与のピークデータレートのような「バーストレート」を制御することを含み得る。

【0007】

"Configuring Queuing and Flow Control", in Cisco Nexus 5000 Series NX-OS Quality of Service Configuration Guide, Release 5.2(1)N1(1) April 3, 2016（非特許文献１）は、「コネクション毎」のフロー制御の一例である。指定されたトラフィック種別の帯域幅を確保するために、受入品質サービス（ＱｏＳ）ポリシーが、イーサネットインターフェースに適用され得る。コネクション毎に、バッファ空間、「ノードロップ（no drop）」閾値、及びその他のフロー制御パラメータが設定され得る。

【0008】

"Hierarchy Virtual Queue Based Flow Control in LTE/SAE", 2010 Second International Conference on Future Networks, IEEE March 30, 2010（非特許文献２）は、「仮想キュー」の階層構造を「実キュー」に関連付ける無線ネットワークでの、フロー制御のアプローチの一つである。なお、フロー制御は、ＵＥ（携帯電話機）、セル、及びｅＮＢの３つの「レベル」で実施され得る。仮想キューでは、それらの各レベルにおいてフローが制御されるものの、どのメッセージトラフィックもコンピュートノード一式に到達する前に通過することになるデバイスを使った「グローバル」制御については、何の示唆もされていないように見受けられる。

【0009】

Pre-grant Publication US2012/0195203（Ｊｕｎｉｐｅｒ社）（特許文献１）には、多段キューを用いたフロー制御の技術が記載されている。しかし、この「多段キュー」は特定の（given）ネットワークデバイス内に位置しているため、レイテンシに厳しい設計にとって良くない影響を及ぼしがちであり得る。

【先行技術文献】

【特許文献】

【0010】

【特許文献1】米国特許出願公開第２０１２／１９５２０３号明細書

【非特許文献】

【0011】

【非特許文献1】"Configuring Queuing and Flow Control", in Cisco Nexus 5000 Series NX-OS Quality of Service Configuration Guide, Release 5.2(1)N1(1) April 3, 2016

【非特許文献2】"Hierarchy Virtual Queue Based Flow Control in LTE/SAE", 2010 Second International Conference on Future Networks, IEEE March 30, 2010

【発明の概要】

【発明が解決しようとする課題】

【0012】

本明細書で説明するように、電子取引システムなどの分散型コンピューティングシステムの好適な実施形態は、インバウンドメッセージのフローレートを制御するものである。

【課題を解決するための手段】

【0013】

詳細に述べると、一部の分散型コンピューティング環境では、特定の（given）クライアント（あるいは、所与のコネクション）からのメッセージが前記システムで受信されることのできるレートを制限することが所望される。これは、例えば、分散型システムと１つ以上の外部クライアントとの間の１つ以上の通信リンクの飽和阻止、および／または、分散型システムの過負荷防止に役立ち得る。また、クライアント毎にインバウンドメッセージレートを制限するという構成は、コンピューティングリソースの公平なプロビジョニングも確実に支援することで、ある一人のクライアントによるリソースの過剰利用によって前記分散型システムが圧倒できなくなり、その他のクライアントが同システムとの間で相互にやり取りを行うことができないようになるのを阻止する。

【0014】

また、クライアント毎（あるいは、コネクション毎）にメッセージ受入レートを制御することに加えて、全てのクライアントコネクションを通じた前記分散型システム内への総合的な受入レートを、システム全体で制御することも望ましくあり得る。このようなシステム全体の制御により、前記分散型システム全体として、期待される（predictable）レベルのアクセスを全てのクライアントに対して提供することを含め、必要なサービスレベルを確実に維持することができる。

【0015】

そのため、分散型データ処理システム又はこれに対応する方法として、複数のコンピュートノードおよびシステムレベルノードへのインバウンドメッセージフローの制御を行うシステム又は方法を提供し得る。該システムでは、複数のゲートウェイノードのそれぞれが、１つ以上のクライアントコネクションからメッセージを受信し、クライアント毎またはコネクション毎に該メッセージの持続レートおよび／またはバーストレートを制御した後、該メッセージを１つ以上のコンピュートノードに転送する。システムレベルノードは、前記ゲートウェイノードから該メッセージを受信し、ゲートウェイノード毎に持続フローおよび／またはバーストレートを制御した後、該メッセージをコンピュートノードに転送する。つまり、結果としては、前記システムレベルノードがシステム全体のメッセージフローレートを制御することにもなる。

【0016】

前記システムは、前記メッセージが電子取引メッセージである電子取引システムを実現するように用いられるものであり得る。このような実施形態では、前記コンピュートノードが、前記ゲートウェイノードおよびシーケンサノードから前記電子取引メッセージを受信した後、前記電子取引メッセージの処理を行い、電子取引機能を実行して、応答メッセージを生成するものとされ、当該応答メッセージは、１つ以上のゲートウェイを介して１つ以上のクライアントへと返送される（in turn returned）。

【0017】

他の態様において、前記メッセージフローレートは、さらに、１つ以上の前記ゲートウェイに対してフィードバックを行うことにより、システム全体での制御が行われ得る。フィードバックが与えられる方法には、前記システムレベルノードから前記ゲートウェイノードへの全てのコネクションについてコネクション毎にウィンドウサイズを下げること、前記システムレベルノードから前記ゲートウェイノードへの全てのコネクションについてコネクション毎のトークンバケットに構成されたバーストレート及び持続レートを低下させること、各ゲートウェイを停止させることなどといった、数多くのものがあり得る。

【0018】

さらなる他の実施形態において、前記持続レートおよび／またはバーストレートは、さらに、各ゲートウェイから各クライアントまたはコネクションに対してフィードバックを行うことによってクライアント毎またはコネクション毎に制御され得る。システムレベルの前記制御と同様に、フィードバックの適用は、前記ゲートウェイノードへの全てのクライアントコネクションについてクライアント毎またはコネクション毎にウィンドウサイズを下げることや、前記ゲートウェイノードへの全てのクライアントコネクションについてクライアント毎またはコネクション毎のトークンバケットに構成されたバーストレート及び持続レートを低下させることや、前記クライアントまたはコネクションを停止させることを伴い得る。

【0019】

コネクションの停止は、その（respective）ゲートウェイへの全てのクライアントまたはコネクションについて、ウィンドウサイズをゼロに設定することや、その（respective）ゲートウェイのクライアント毎またはコネクション毎のＦＩＦＯに、新しいメッセージを追加しないことや、クライアント毎またはコネクション毎のＦＩＦＯキューからのメッセージを処理しないことを含み得る。

【0020】

さらなる他の態様において、持続フローレートまたはバーストレートは、前記メッセージを複数のキューでキューイングした後、前記メッセージを前記キューから複数のトークンバケットに出力し、前記トークンバケットからメッセージを選出することによって制御され得る。

【0021】

本明細書で述べるアプローチのその他の新規構成や利点については、下記の内容および添付の図面から明らかとなる。

【図面の簡単な説明】

【0022】

【図1A】分散型電子取引システムの高次ブロック図である。

【図1B】ゲートウェイからコンピュートノードへと直接の経路で移動するメッセージ、およびシーケンサノード経由で移動するメッセージを示す図である。

【図1C】メッセージのフォーマットの一例を示す図である。

【図2】ゲートウェイやコンピュートノードなどのシステムコンポーネントの詳細図である。

【図3】クライアントコネクションの、ゲートウェイ内などの場所でのフロー制御の一例を示す図である。

【図4】グローバル（システムレベル）フロー制御の一例を示す図である。

【図5】ゲートウェイ内でのフロー制御の詳細図である。

【図6】グローバル（システム）レベルでのフロー制御の詳細図である。

【図7】ＴＣＰのウィンドウサイズを使ってゲートウェイのバックプレッシャーを制御する一例を示す図である。

【図8】ＴＣＰのウィンドウサイズを使ってシステムレベルのバックプレッシャーを制御する一例を示す図である。

【発明を実施するための形態】

【0023】

（システムの概要）

【0024】

本明細書で開示する例示的な実施形態は、（株式、債券、商品、先物、オプションなどの）金融商品の売買注文が（トレーダやブローカなどの）市場参加者間で取引される市場の提供を行う高速電子取引システムに関する。該電子取引システムは、低レイテンシ、公平性、フォールトトレランス、サービス品質シェーピング、および後で詳しく述べるその他の特長を奏する。

【0025】

前記電子取引システムは、主に、取引注文を互いに「マッチング」させる役割を担っている。一例として、ある商品を「買う」というオファーが、それに対応する「売る」という逆オファーとマッチングさせられる。マッチングしたオファーと逆オファーは、少なくとも部分的に希望価格を満たしている必要があり、満たしていない残りの分の数量については、別の適切な逆注文に回される。そして、マッチングした注文のペアが成立し、取引が約定される。

【0026】

全く満たしていない注文や部分的にしか満たしていない注文は、「注文ブック」と言われるデータ構造内に維持される。未マッチの取引注文に関して保持された情報は、マッチングエンジンによって後続の取引注文に応えるのに利用され得る。典型的に、注文ブックは、商品ごとに維持され、一般にその特定の商品の市場状況を規定又は象徴したものとなる。注文ブックには、例えば、市場参加者が売買の意思を表明している最新の価格や数量などが含まれ得る。

【0027】

また、マッチングの結果は、市場データフィードと言われるストリーミングデータサービスを介して市場参加者に可視化され得る。典型的に、市場データフィードには、各取引商品の価格（pricing）や、量やその他の統計値といった関連情報を運ぶ個々のメッセージが含まれる。

【0028】

図１Ａに、多数のゲートウェイ１２０－１，１２０－２，．．．，１２０－ｇ（まとめてゲートウェイ１２０と言う）、一連のコアコンピュートノード１４０－１，１４０－２，．．．，１４０－ｃ（まとめてコアコンピュートノード１４０、あるいは、コンピュートノード１４０）、および１つ以上のシーケンサ１５０－１，１５０－２，．．．，１５０－ｓ（まとめてシーケンサ１５０）を備えた電子取引システム１００の一例を示す。つまり、一部の実施形態では、ゲートウェイ１２０、コアコンピュートノード１４０、およびシーケンサ１５０が、電子取引システム１００内のノードであると見なされる。後で詳しく述べるが、一実施形態において、ゲートウェイ１２０、コンピュートノード１４０、およびシーケンサ１５０は、互いに直接、好ましくは低レイテンシの専用コネクション１８０で接続されている。

【0029】

システム１００の説明に関して「ピア」という用語は、電子取引システム１００の中で（例えば「ゲートウェイ」対「コアコンピュートノード」対「シーケンサ」のように）共通の、または同じ機能を一般的に果たす他のデバイスのことを言う。例えば、ゲートウェイ１２０－２，．．．，１２０－ｇはゲートウェイ１２０－１のピアであり、コアコンピュートノード１４０－２，．．．，１４０－ｃはコアコンピュートノード１４０－１のピアであり、シーケンサ１５０－２，．．．，１５０－ｓはシーケンサ１５０－１のピアである。

【0030】

システム１００の説明に関して「アクティブ」と「スタンバイ」という用語は、システム／コンポーネントの高可用性（ＨＡ）役割／状態／モードのことを言う場合がある。一般的に言って、スタンバイのシステム／コンポーネントとは、アクティブなシステム／コンポーネントで実行されていた機能を引き継ぐことが可能で且つ電源が入っている冗長（バックアップ）システム／コンポーネントのことである。本発明を限定しない例であるが、このようなスイッチオーバー／フェイルオーバー、すなわち、スタンバイの役割／状態／モードからアクティブな役割／状態／モードへの移行は、現行アクティブなシステム／コンポーネントの障害に応じて自動的に行われ得る。

【0031】

電子取引システム１００は、１つ以上の参加者コンピューティングデバイス１３０－１，１３０－２，．．．，１３０－ｐ（まとめて参加者デバイス１３０）からの取引注文を処理したり該デバイスに関連情報を提供したりする。参加者デバイス１３０は、システム１００との間で相互にやり取りを交わす（interact）デバイスであって、取引注文情報を表示したり受信したりするように構成された１つ以上のパーソナルコンピュータ、タブレット、スマートフォン、サーバまたはその他のデータ処理デバイスであり得る。参加者デバイス１３０は、グラフィカルユーザインターフェース（ＧＵＩ）を介して人間によって操作され得るものであるか、あるいは、何らかの物理的又は仮想的なデータ処理プラットフォーム上で動作する高速自動取引手法によって操作され得るものである。

【0032】

参加者デバイス１３０は、それぞれ、ゲートウェイ１２０との間で確立されたコネクションを介して電子取引システム１００とメッセージをやり取り（すなわち、メッセージを送信したり受信したり）し得る。図１Ａでは参加者デバイス１３０がそれぞれゲートウェイ１２０への一つのコネクションを介して電子取引システム１００に接続されているものとして描かれているが、所与の参加者デバイス１３０は、１つ又は複数のゲートウェイ装置１２０との間の複数のコネクションを介して電子取引システム１００に接続されるものであってもよいという点を理解されたい。

【0033】

なお、各ゲートウェイ１２０－１は一つの参加者デバイス１３０だけに従事する場合もあるが、典型的には、多数の参加者デバイス１３０に従事している。

【0034】

コンピュートノード１４０－１，１４０－２，．．．，１４０－ｃ（本明細書ではマッチングエンジン１４０やコンピュートエンジン１４０とも言う）は、上述のマッチング機能を提供するほか、１つ以上の参加者デバイス１３０に配信される下りメッセージまたは送信メッセージまたは出力メッセージ（outgoing message）を生成するものであり得る。各コンピュートノード１４０は、高性能データプロセッサであり、典型的には、１つ以上の注文ブック１４５－１，１４５－２，．．．，１４５－ｂを検索したり維持したりするための１つ以上のデータ構造を維持する。注文ブック１４５－１は、例えば、コアコンピュートノード１４０－１が取り扱う（responsible）商品毎に維持され得る。また、１つ以上のコンピュートノード１４０および／または１つ以上のゲートウェイ１２０は、市場データフィード１４７を提供し得る。市場データフィード１４７も、参加者デバイス１３０や任意の他の適切なコンピューティングデバイスであり得る加入利用者に（例えば、マルチキャストで）配信され得る。

【0035】

コアコンピュートノード１４０により生成される一部の下りメッセージは、同期的なもの、すなわち、１つ以上の参加者デバイス１３０から受信した１つ以上の上りメッセージまたは受信メッセージまたは入力メッセージ（incoming message）に応答してコアコンピュートノード１４０により直接生成されるもの（例えば、上り方向の「新規注文」メッセージを受けての、これに対応した下り方向の「受付確認メッセージ」や「約定メッセージ」等）であり得る。しかし、一部の実施形態において、少なくとも一部の下りメッセージは、例えば、特定の「一方的（unsolicited）」取消メッセージや「トレードブレーク（trade break）」メッセージ又は「トレードバスト（trade bust）」メッセージなどといった、取引システム１００で発生する（initiated）非同期的なものであり得る。

【0036】

電子取引システム１００のような分散型コンピューティング環境は、複数のコンピュートノード１４０上で並行して動作する複数のマッチングエンジンによって構成され得る。

【0037】

シーケンサ１５０は、あらゆる順序依存型処理の適切なシーケンスが確実に維持されるようにするものである。上りメッセージに対する処理が誤った順序で実行されることが確実になくなるようにするため、典型的に、１つ以上のゲートウェイ１２０で受信された上りメッセージ（例えば、所与の参加者デバイス１３０からの新規取引注文メッセージ等）は、少なくとも１つのシーケンサ１５０（例えば、現行アクティブな単一のシーケンサのほか、場合によっては、スタンドバイの１つ以上のシーケンサ等）を通過し、これにより（複数のシーケンサが存在するとして、現行アクティブな単一のシーケンサによる）シーケンス識別子によってマークされ得る。同識別子は、分散型システム１００（例えば、電子取引システム１００等）全体の後続処理の過程でメッセージ間の相対的な順序付けを決定したり電子取引システム１００全体でメッセージを一意的に識別したりするのに用いられる一意的な単調増加値であり得る。一部の実施形態において、前記シーケンス識別子は、メッセージがシーケンサに到着した順序（すなわち、シーケンス）を表すものであり得る。例えば、前記シーケンス識別子は、到着したメッセージごとに前記シーケンサによって一定間隔で単調に漸増又は漸減させられる値であってもよく、例えば、前記シーケンス識別子は、到着したメッセージごとに１ずつ漸増させられるものであり得る。しかしながら、前記シーケンス識別子は、一意的なものであれば、単調増加又は単調減少する値に限定されないという点を理解されたい。一部の実施形態では、マーク付きバージョンのメッセージのほうにシーケンス識別子の値が含まれているという点を除き、マークが付いていない元のメッセージとシーケンスマーク付きメッセージが本質的に同一であり得る。シーケンス化が済むと、典型的に、上り方向のマーク付きメッセージ、すなわち、シーケンスマーク付きメッセージは、１つ以上のシーケンサ１５０によって他の下流コンピュートノード１４０へと転送されて処理を、場合によっては、順序依存型の処理を受ける。このようにして、シーケンサ１５０によって割り振られたシーケンス識別子は、電子取引システム１００全体でメッセージを一意的に識別するほか、電子取引システム１００内での他のマーク付きメッセージに対する各マーク付きメッセージの相対的な順序付けについても定め得る。

【0038】

このように、本明細書で開示する一意的なシーケンス識別子は、他でのシーケンス識別子の利用用途と異なり、電子取引メッセージ処理の確定的な順序（すなわち、シーケンス）を確保する目的で利用され得る。前記一意的なシーケンス識別子は、電子取引システム内での所与の電子取引メッセージの処理の、それ以外の取引メッセージに対する一意的な確定的順序付け（すなわち、シーケンス）指令を表す。本発明を限定する例ではないが、例示的な一実施形態において、前記シーケンス識別子は、図１Ｃに関して後でさらに開示するようにメッセージのシーケンスＩＤフィールド１１０－１４に入力され得る。

【0039】

一部の実施形態において、メッセージは、別の方向、すなわち、コアコンピュートノード１４０から１つ以上のゲートウェイ１２０を通過して１つ以上の参加者デバイス１３０へと流れるものである場合もある。コアコンピュートノード１４０によって生成されたこのような下りメッセージも、順序依存型（すなわち、シーケンス順序依存型）のものであり得て、これに応じて、典型的に、まずシーケンサ１５０を通過することによってシーケンス識別子でマークされ得る。その後、シーケンサ１５０はマーク付き応答メッセージをゲートウェイ１２０に転送し、適切な確定的順序で参加者デバイス１３０に受け渡されるようにし得る。

【0040】

シーケンサ１５０を使って一意的なシーケンス番号を生成してメッセージ又は同メッセージの表現物に該シーケンス番号をマークする、すなわち、シーケンスマーク付きメッセージを生成するという構成により、どのコンピュートノードやコンピュートノード１４０一式で同メッセージが処理されるのかにかかわらず、分散型システム、すなわち、電子取引システム１００全体で、正しい処理順序付けが確実に維持される。このアプローチは、「状態確定性」を提供し、例えば、システム全体の状態が確定的かつ再現可能（場合によっては、災害復旧サイトのように別の場所で再現可能）なものとなり、フォールトトレランス、高可用性および災害復旧性をもたらす。

【0041】

そのほか、生成ノード（すなわち、例えば、新規メッセージの生成及び／又は参加者デバイス１３０から受信したメッセージの転送などによって電子取引システム１００中に新規メッセージを導入するノード）やそのピアノードが、同メッセージに振り当てられたシーケンス番号を受け取るという点も、重要な点として挙げられ得る。自身が生成したメッセージのシーケンス番号を受け取るという構成は、生成ノードやそのピアノードにとって、シーケンス番号に従って順番にメッセージを処理するという点だけでなく、自身のノードが生成したメッセージを電子取引システム１００の残り全体で使用される同メッセージのシーケンス識別子と関連付けるという点でも有用であり得る。図１Ｃとの関連でさらに後述するように、生成ノードまたはノード生成（generating node）によって電子取引システム中に導入されるマークが付いていないバージョンのメッセージと前記シーケンサにより出力されるシーケンスマーク付きバージョンの同メッセージとの間のこのような関連付けは、両バージョンのメッセージ内の識別情報を使って行われ得る。電子取引システム１００内で生成される後続のメッセージは、それ自身のシーケンス番号が振り当てられる一方で、関連する先行メッセージの１つ以上のシーケンス番号を参照している場合もある。つまり、ノードは、例えば自ノードが生成したメッセージのシーケンス番号が後続メッセージで参照されることになるので、自ノードがそれより前に生成したメッセージの（シーケンス番号による）参照を素早く行う必要性があり得る。

【0042】

一部の実施形態において、前記生成ノードは、まずシーケンサ１５０にメッセージを送信し、該シーケンサから同メッセージのシーケンス番号を受信するまで待機してから、電子取引システム１００内の別のノードに同メッセージを転送し得る。

【0043】

例示的な別の実施形態では、電子取引システム１００内での不所望なレイテンシ増の追加となり得る１回又は複数回のホップを避けるため、シーケンサ１５０は、生成ノードからシーケンス化前のメッセージを受信した後、シーケンス化されたバージョンのメッセージ（例えば、シーケンスマーク付きメッセージ等）を宛先ノードに送信し得るだけでなく、送信側ノード及びそのピアに対しても、シーケンス化されたバージョンのメッセージをほぼ同時に返信し得る。例えば、シーケンサ１５０は、ゲートウェイ１２０－１からコアコンピュートノード１４０に送信される上りメッセージにシーケンス番号を割り当てた後、シーケンス化されたバージョンのメッセージをコアコンピュートノード１４０に転送し得るだけでなく、シーケンス化されたバージョンの同メッセージをゲートウェイ１２０－１やその他のゲートウェイ１２０にも返信し得る。これにより、任意のゲートウェイ１２０は、コアコンピュートノード１４０で生成された後続のいずれかのメッセージがそのシーケンス番号を参照していた場合、そのシーケンス番号によって、ゲートウェイ１２０－１で生じた対応する元のメッセージを容易に特定し得る。

【0044】

同様に、さらなる一部の実施形態では、コアコンピュートノード１４０によって生成されてゲートウェイ１２０に対して送信されると共にシーケンサ１５０によってシーケンス化されたシーケンス化後バージョンの下りメッセージが、該シーケンサ１５０により、ゲートウェイ１２０とコアコンピュートノード１４０の両方に転送／返送され得る。

【0045】

一部の実施形態は、例えば、第１シーケンサが故障した場合でも別のシーケンサが確実に利用可能であるようにするために、高可用性目的で複数のシーケンサ１５０を備え得る。複数のシーケンサ１５０（例えば、現行アクティブなシーケンサ１５０－１およびスタンバイの１つ以上のシーケンサ１５０－２，．．．，１５０－ｓ等）を備える実施形態では、現行アクティブなシーケンサ１５０－１が、シーケンサ１５０－１を通過した全てのメッセージ及び同メッセージの対応シーケンス番号についてのシステム状態ログ（図示せず）を維持し得る。このシステム状態ログは、スタンバイのシーケンサに継続的又は定期的に送信されることで、当該スタンバイのシーケンサに対し、必要に応じてアクティブなシーケンサを引き継ぐことできるようになるのに必要となるシステム状態を与えるようにし得る。あるいは、前記システム状態ログは、複数のシーケンサ１５０がアクセスすることのできるデータストアに記憶されてもよい。

【0046】

また、前記システム状態ログは、災害復旧サイト１５５にある電子取引システムのスタンバイレプリカ（詳細は図示せず）内の１つ以上のシーケンサへと継続的又は定期的に複製されてもよく、これにより、システム１００のプライマリサイトが壊滅的障害を受けたとしても、災害復旧サイト１５５において全く同じ状態で電子取引を続行することが可能となる。

【0047】

例示的な一実施形態では、複数のシーケンサのうちの現行アクティブなシーケンサが、前記システム状態ログをデータストア（図示せず）に記憶し得る。該データストアは、図１Ａに関して後でさらに開示するシーケンサ全体共有ネットワーク１８２－ｓなどの共有シーケンサネットワークを介して複数のシーケンサがアクセス可能なものであり得る。当該複数のシーケンサのうちの所与のシーケンサの役割（状態）がスタンバイからアクティブに移り変わった場合、該シーケンサは、前記データストアから前記システム状態ログを取得することで、状態が元のアクティブなシーケンサの状態と同期したものとなり得る。

【0048】

また、一部の実施形態では、前記システム状態ログが、１つ以上の前記シーケンサおよび／または電子取引システム１００内の１つ以上の他のノードにより実現され得るドロップコピーサービス１５２にも提供され得る。ドロップコピーサービス１５２は、電子取引システム１００を介した日々の取引活動の記録を提供するものであり得て、当該記録は、例えば参加者デバイス１３０を介して接続され得る規制機構及び／又はクライアントへと配信され得る。代替的な実施形態では、ドロップコピーサービス１５２が、１つ以上のゲートウェイ１２０で実現され得る。また、ドロップコピーサービス１５２は、前記システム状態ログを参照することに加えて又はその代わりに、電子取引システム１００中で送信される上りメッセージや下りメッセージの内容に基づいて取引活動を記録するものであってもよい。例えば、一部の実施形態では、ドロップコピーサービス１５２を実現するゲートウェイ１２０が、シーケンサ１５０から（かつ／あるいはコアコンピュートノード１４０やその他のゲートウェイ１２０から）電子取引システム１００中でやり取りされる全メッセージを受信するものとされ得る。ドロップコピーサービス１５２から日々の取引活動の記録を受信するように構成されている参加者デバイス１３０は、必ずしも、電子取引システム１００に取引注文を送信したり電子取引システム１００のマッチング機能を利用したりする参加者デバイスであるとは限らない。

【0049】

参加者デバイス１３０とゲートウェイ１２０との間でやり取りされるメッセージは、金融取引に利用され得る任意の適切なプロトコル（便宜上、「金融取引プロトコル」と言う）に準拠したものであり得る。例えば、同メッセージは、（ＮａｓｄａｑＯＵＣＨ、ＮＹＳＥ ＵＴＰなどの）バイナリプロトコルや（ＮＹＳＥ ＦＩＸ ＣＣＧなどの）テキストベースプロトコルの双方を含め、カスタムプロトコルや確立された標準プロトコルに準じてやり取りされるメッセージであり得る。一部の実施形態において、電子取引システム１００は、同じゲートウェイ１２０上での同時複数のプロトコルを含め、同時複数の金融取引プロトコルに準拠したメッセージのやり取りをサポートし得る。例えば、参加者デバイス１３０－１，１３０－２，１３０－３は、同時複数の取引コネクションを確立し得ると共に、ＮａｓｄａｑＯｕｃｈ、ＮＹＳＥ ＵＴＰ、ＮＹＳＥ ＦＩＸ ＣＣＧにそれぞれ準じたメッセージをゲートウェイ１２０－１との間でやり取りし得る。

【0050】

また、一部の実施形態において、ゲートウェイ１２０は、参加者デバイス１３０から受信した金融取引プロトコル準拠のメッセージを、電子取引システム１００内のノード間でメッセージをやり取りするのに利用される正規化（例えば、標準化）メッセージフォーマットへと変換し得る。この正規化取引フォーマットは、既存のプロトコルであってもよいが、一般的には、参加者デバイス１３０との間でメッセージをやり取りするのに利用される任意の金融取引プロトコルとは異なるサイズ及びデータフォーマットのものであり得る。例えば、前記正規化取引フォーマットは、参加者デバイス１３０からゲートウェイ１２０で受信した元の上りメッセージの金融取引プロトコルと比べると、１つ以上の追加のフィールド又はパラメータを含んでいる場合や１つ以上のフィールド又はパラメータを省略している場合があり、かつ／あるいは、前記正規化フォーマットのメッセージの各フィールド又はパラメータは、参加者デバイス１３０からゲートウェイ１２０で受信した対応するメッセージと異なるデータ型又はサイズのものであり得る。同様に、逆方向では、ゲートウェイ１２０が、電子取引システム１００により前記正規化フォーマットで生成された下りメッセージを、参加者デバイス１３０がゲートウェイ１２０とやり取りするのに利用される１つ以上の金融取引プロトコルのフォーマットのメッセージへと変換し得る。次に開示する図１Ｂでは、そのような上り／下りメッセージ（例えば、上りメッセージ１０３、下りメッセージ１０５等）が、ゲートウェイ１２０－１と参加者デバイス１３０との間でやり取りされている。

【0051】

図１Ｂは、先に開示した図１Ａの電子取引システム１００の例示的な一実施形態のブロック図である。具体的な同実施形態において、電子取引システム１００は、アクティベーションリンク１８０－１－１と順序付け（すなわち、シーケンス化）パス（経路）１１７とを介してコアコンピュートノード１４０－１に接続されたゲートウェイ１２０－１を備えている。電子取引システム１００は、さらに、順序付けパス１１７内に電子的に設けられたシーケンサ１５０－１を備えている。ゲートウェイ１２０－１は、上りメッセージ１０３の受信に応じて、アクティベーションリンク１８０－１－１及び順序付けパス１１７を介してコアコンピュートノード１４０－１にメッセージ（図示せず）を送信するように構成されている。コアコンピュートノード１４０－１は、ゲートウェイ１２０－１からの同メッセージ（非シーケンス化メッセージとも言う）、さらには、シーケンサ１５０－１からのシーケンスマーク付きバージョンのメッセージ（図示せず）を受信するように構成されている。

【0052】

本発明を限定する例ではないが、シーケンスマーク付きバージョンは、図１Ｃに関して後でさらに開示するように、シーケンスマーク付きメッセージのシーケンスＩＤフィールド１１０－１４に含まれ得るようなシーケンス識別子（ＩＤ）を含む。同シーケンスＩＤは、アクティベーションリンク１８０－１－１を介して通信済みのその他複数のメッセージや順序付けパス１１７を介してシーケンサ１５０－１で受信済みのシーケンスマーク付きバージョンの同その他複数のメッセージの中での、そのシーケンスマーク付きバージョンのメッセージの確定的位置を示す。同シーケンスＩＤが確定的位置を示す対象となっている該複数のメッセージには、順序付けパス１１７経由でコアコンピュートノード１４０－１にて受信されたシーケンスマーク付きバージョンのその他のメッセージも含まれている。前記メッセージ（例えば、シーケンス化されていないメッセージ等）やそのシーケンスマーク付バージョンは、共通のメタデータ（図示せず）を含む。当該共通のメタデータを使ってメッセージとそのシーケンスマーク付きバージョンとを関連付けることにより、同メッセージのシーケンスＩＤが特定される。前記シーケンスＩＤは、さらに、同メッセージの、電子取引システム１００中でやり取りされる、シーケンサ１５０－１通過済みの（つまり、シーケンサ１５０－１でシーケンスマークが付けられた後の）全メッセージの中での確定的位置も表す。

【0053】

電子取引システム１００の構成要素に通信されたメッセージは、該構成要素によってタイムスタンプが押され得るが、これに対し、シーケンサ１５０－１により決定されるシーケンスＩＤは、電子取引システム１００中でやり取りされるメッセージの位置（順序／優先順位）を決めるものであるという点を理解されたい。複数のシステムが同じタイムスタンプをメッセージに付けるという可能性があり、すると、そのようなメッセージ同士の順序／優先順位を該メッセージの受信側で解決する必要がある。電子取引システム１００では、シーケンサ１５０－１が電子取引システム１００中でやり取りされるメッセージの順序／優先順位の唯一の決定者になり得ることから、そのようなことが起こらない。

【0054】

コアコンピュートノード１４０－１は：（ｉ）アクティベーションリンク１８０－１－１を介したメッセージの受信に応じて電子取引用のマッチング機能活動を開始し；（ｉｉ）順序付けパス１１７を介したシーケンスマーク付きバージョンの受信に応じて、前記シーケンス識別子を使い、前記マッチング機能活動を完了させて電子取引のサービスを提供することを優先させる；ように構成され得る。

【0055】

コアコンピュートノード１４０－１は、メッセージ（すなわち、シーケンス化されていないメッセージ）を受信することで、電子取引機能（すなわち、マッチング機能活動）を開始して、シーケンス化されていない同メッセージの処理を開始し得るものである一方、シーケンスマーク付きの同メッセージを受信するまでは、該処理を完了しない且つ／或いは同メッセージの処理結果をコミットしないものとされ得る。シーケンスマーク付きメッセージのシーケンス識別子で定まる、同メッセージの処理のための確定的順序付けが分からないと、例えば、コンピュートノード１４０－１によるメッセージ処理は予測不可能なものになり得る。本発明を限定する例ではないが、起こり得る（possible）予測不可能な結果の例として、金融証券取引では、コントラ側のマッチ候補となる非シーケンス化の未処理（outstanding）メッセージが複数生じている場合がある。コントラ側の取引注文については、恐らく、マッチ候補のうちの一部しか成立し得ないことから、複数のマッチ候補同士のなかでその解決を行うための確定的方法が存在することは有益である。

【0056】

一部の実施形態では、コンピュートノード１４０－１が、シーケンス化されていないメッセージとシーケンスマーク付きメッセージの両方を受信した後、図１Ｃとの関連で後述するように両バージョンのメッセージ内の識別情報を使って、シーケンス化されてないメッセージをシーケンスマーク付きメッセージと関連付けし得る。コンピュートノード１４０－１は、順序付けパス１１７を介してシーケンスマーク付きメッセージを受信すると、同メッセージ（すなわち、シーケンスマーク付きバージョンのメッセージ）の、電子取引システム１００中のその他のメッセージに対しての適切な処理シーケンスを求め得る。その後、コンピュートノード１４０－１は、適切な応答メッセージの送出を含めたメッセージ処理を、シーケンサ１５０－１によって割り当てられてシーケンスマーク付きメッセージ内に含められた前記シーケンス識別子を場合によって参照して完了させ得る。金融証券取引においてコントラ側のマッチ候補となるメッセージが複数生じている本発明を限定しない先程の例に戻るが、マッチ候補であるシーケンスマーク付きバージョンのメッセージを受信したコンピュートノード１４０－１は、マッチ発生のシーケンスを正確に決定し、電子取引マッチング機能を完了させ得る。

【0057】

例示的な一実施形態では、シーケンサ１５０－１が、シーケンスマーク付きメッセージを第３のダイレクトコネクション１８０－ｃ１－ｓ１を介してコンピュートノード１４０－１に送信するのに加えて、同シーケンスマーク付きメッセージを（順序付けパス１１７の）第２のダイレクトコネクション１８０－ｇｗ１－ｓ１を介してゲートウェイ１２０－１にも送信し得る。シーケンスマーク付きメッセージをメッセージの送信側に供給することにより、この送信者側（すなわち、ゲートウェイ１２０－１）は、（同メッセージに割り当てられた）シーケンス番号を（図１Ｃとの関連で後述するように）同メッセージ内の別の識別情報と関連付けることが可能となり、これにより、その送信側は、該シーケンス番号を参照した後続メッセージの処理を簡単に行うことができるようになる。

【0058】

先程は、コンピュートノード１４０－１が、アクティベーションリンク１８０－１－１を介して受信したメッセージに基づいて処理をアクティベート（開始）する様子を開示したが、これと同様に、ゲートウェイ１２０－１は、アクティベーションリンク１８０－１－１を介してコンピュートノード１４０－１から受信したシーケンス化されていない応答メッセージを受信すると、シーケンスマーク付きバージョンの該応答メッセージを受信する前にもかかわらず、該応答メッセージの処理をアクティベートし得る。本発明を限定する例ではないが、処理のアクティベートは、ゲートウェイ１２０－１のオープン取引注文データベースの状態を更新すること、および／または、参加者デバイス１３０への送信準備が整った下りメッセージ１０５を蓄積することを含み得る。しかしながら、一部の実施形態では、ゲートウェイ１２０－１が、下りメッセージ１０５を参加者デバイス１３０に送信することを含めた応答メッセージの処理を、電子取引システム１００中のその他のメッセージを含めたメッセージシーケンス内における同応答メッセージの確定的位置を示すシーケンス識別子が含まれたシーケンスマーク付きの応答メッセージを受信するまで、完了させないものとされ得る。

【0059】

一部の実施形態において、ゲートウェイ１２０－１は、シーケンス化されていない応答メッセージ及びシーケンスマーク付き応答メッセージの両方を受信した後、図１Ｃとの関連で後述するように両バージョンの応答メッセージ内の識別情報を使って、該シーケンス化されていない応答メッセージを該シーケンスマーク付き応答メッセージと関連付け得る。これにより、同応答メッセージの確定的位置が、シーケンスマーク付き応答メッセージの受信時に定まる。一部の実施形態では、その後に、図１Ａの参加者デバイス１３０などの参加者デバイスに送信される下りメッセージ１０５のコミットを含めた応答メッセージの処理が完了させられ得る。

【0060】

引き続き図１Ｂを参照するが、アクティベーションパス１８０－１－１を介して送信されたメッセージと、順序付けパス１１７を介して送信されたシーケンスマーク付きバージョンのメッセージは、共通のメタデータを含み得る。コアコンピュートノード１４０－１は、順序付けパス１１７を介したシーケンスマーク付きバージョンの受信に応じて、同メッセージを該シーケンスマーク付きバージョンと前記共通のメタデータに基づいて関連付けるようにさらに構成され得る。

【0061】

図１Ｂの例示的な実施形態では、メッセージが、アクティベーションリンク順方向（すなわち、ａｃｔ－ｌｉｎｋ－ｆｗｄ－ｄｉｒ１１３ａ）にアクティベーションリンク１８０－１－１経由でコアコンピュートノード１４０－１へと送信されると共に、順序付けパス順方向（すなわち、ｏｒｄｅｒ－ｐａｔｈ－ｆｗｄ－ｄｉｒ１１５ａ）に順序付けパス１１７経由でコアコンピュートノード１４０－１へと送信される。コアコンピュートノード１４０－１は、マッチング機能活動を完了させること以外にも、応答（図示せず）を、アクティベーションリンク１８０－１－１経由でアクティベーションリンク逆方向（すなわち、ａｃｔ－ｌｉｎｋ－ｒｅｖ－ｄｉｒ１１３ｂ）にゲートウェイ１２０－１へと、かつ、順序付けパス１１７経由で順序付けパス逆方向（すなわち、ｏｒｄｅｒ－ｐａｔｈ－ｒｅｖ－ｄｉｒ１１５ｂ）に送信し得る。

【0062】

アクティベーションリンク１８０－１－１は単一のダイレクトコネクションであるのに対し、順序付けパス１１７は複数のダイレクトコネクションを含む。例えば、例示的な本実施形態の順序付けパス１１７は、ダイレクトコネクション１８０－ｇｗ１－ｓ１とダイレクトコネクション１８０－ｃ１－ｓ１の両者を含む。

【0063】

ゲートウェイ１２０－１、シーケンサ１５０－１、およびコアコンピュートノード１４０－１は、ポイントトゥポイントメッシュシステム１０２と称されるポイントトゥポイントメッシュトポロジー内に配置されている。コアコンピュートノード１４０－１は、参加者デバイス１３０から受信されてゲートウェイ１２０－１を介して前記ポイントトゥポイントメッシュトポロジー内へ導入された取引要求に対するサービス提供に向けてマッチング機能（すなわち、電子取引マッチング機能）を実行するように構成され得る。図１Ｂの例示的な実施形態において、ポイントトゥポイントメッシュシステム１０２は、第１のダイレクトコネクション（すなわち、１８０－１－１）、第２のダイレクトコネクション（すなわち、１８０－ｇｗ１－ｓ１）、および第３のダイレクト（direction）コネクション（すなわち、１８０－ｃ１－ｓ１）を有する。シーケンサ１５０－１は、（ｉ）第１のダイレクトコネクションを介してゲートウェイ１２０－１とコアコンピュートノード１４０－１との間でやり取りされるメッセージ、およびゲートウェイ１２０－１、コアコンピュートノード１４０－１から第２のダイレクトコネクション、第３のダイレクトコネクションをそれぞれ介してシーケンサ１５０－１で受信されるメッセージについて、確定的順序（すなわち、シーケンス）を決定するように構成され得る。シーケンサ１５０－１は、（ｉｉ）シーケンスマーク付きバージョンの同メッセージを第２、第３のダイレクトコネクションを介してゲートウェイ１２０－１、コアコンピュートノード１４０－１にそれぞれ送信することで確定的順序内での同メッセージの位置を伝えるようにさらに構成され得る。同メッセージは、本明細書に開示されるような取引要求又はそれに対する応答をなすものである。このようなメッセージのメッセージフォーマットについては、図１Ｃに関して後でさらに開示する。

【0064】

シーケンス化されていないメッセージに対して行われ得る前処理の量や、その前処理の結果が破棄又はロールバックされる必要があり得るか否かについては、後でさらに開示する図１Ｃの実施形態でのメッセージタイプフィールド１１０－１、記号フィールド１１０－２、サイドフィールド１１０－３、価格フィールド１１０－４などのメッセージ内フィールドに左右され得る。また、その量は、メッセージ内の銘柄記号が同一であるかなどのように共通パラメータについて同じ値を参照しているシーケンス化されていない（すなわち、対応するシーケンスマーク付きメッセージが未受信である）未処理のメッセージが現在他にも存在しているか否かにも左右され得る。

【0065】

例えば、コアコンピュートノード１４０－１は、メッセージタイプが「新規注文」であるシーケンス化されていないメッセージを受信した場合、注文ブックのうちのこれに関連した部分に関する記号情報を高速メモリに読み込み得る。コンピュートノード１４０－１は、同新規注文が該注文ブック内のオープン注文とマッチするものである場合、それに応じて「成立」メッセージの生成を開始し得る一方、シーケンスマーク付きバージョンの同メッセージを受信するまでは、注文ブックの更新のコミットと「成立」メッセージの送出を保留し得る。

【0066】

しかしながら、同じ銘柄記号、サイド、価格などを参照したシーケンス化されていない未処理の「新規注文」メッセージをコンピュートノード１４０－１が他にも受け取っており、これも前記注文ブック内の同じオープン注文に対するマッチ候補となる場合には、該コアコンピュートノード１４０－１で実行される前処理が違ったものとなり得る。一部の実施形態では、コアコンピュートノード１４０－１が、オープン注文のマッチとなり得る２つのシーケンス化されていない未処理の「新規注文」メッセージのそれぞれに対し、競合する「成立」メッセージ候補を生成し得る。シーケンス化後バージョンのメッセージに基づき、該「成立」メッセージ候補のうちの一方が廃棄され得るのに対し、他方については前記注文ブックへとコミットされると共にゲートウェイ１２０へと送出される。他の実施形態において、コンピュートノード１４０－１は、シーケンス化されていない未処理のメッセージが複数同じオープン注文に対するマッチ候補となり得る場合、破棄又はロールバックされる必要が生じる可能性のある前処理を実行しない（例えば、「成立」メッセージ候補を生成しない）ものとされ得るか、あるいは、シーケンス化されていない未処理のメッセージに対するそのようなあらゆる前処理を中断又は停止するものとされ得る。

【0067】

別の例では、シーケンス化されていない未処理の「新規注文」メッセージが前記注文ブック上のオープン注文に対するマッチ候補となっている場合に、これが、該「新規注文」メッセージのマッチ候補となっている前記注文ブック上の同じオープン注文を取り換えようとしているか又は取り消そうとしているシーケンス化されていない未処理の「注文取換」メッセージ又は「注文取消」メッセージと競合する可能性がある。このような場合、前記シーケンサにより振り当てられた該「新規注文」メッセージと該「注文取換／取消」メッセージの互いのシーケンス（順番）次第で、最終的な結果として、前記注文ブック上のオープン注文と「新規注文」メッセージとのマッチに落ち着くか、同オープン注文が取り消されるか又は別の価格や数量の新規注文に取り換えられるかの、いずれかになり得る。コンピュートノード１４０－１は、シーケンス化されていない競合する未処理のメッセージのシーケンスマーク付きのバージョンをシーケンサ１５０－１から受信するまで、これら２種類の結果のうちのいずれにするのかを決めることができない。

【0068】

そのような場合にコンピュートノード１４０－１で実行される前処理には、様々なものが有り得る。一部の実施形態において、コンピュートノード１４０－１は、複数の競合する未処理のシーケンス化されていないメッセージが存在する場合、競合する両メッセージ内で参照されている記号に関する前記注文ブックの関連部分を高速メモリに読み込むなどといった、ロールバックや破棄される必要がない前処理を単に実行し得る。他の実施形態では、コンピュートノード１４０－１が、それぞれ複数の競合シナリオの一つに対応する１つ以上の暫定的な応答候補を形成するなどといった、追加の前処理を実行し得る。例えば、コンピュートノード１４０－１は、「成立」メッセージ候補及び／又は「取換受付確認」メッセージ候補もしくは「取消受付確認」メッセージ候補を生成し得ると共に、場合によっては、前記注文ブックへの、複数の結果候補のうちの１つ以上に対応した暫定的更新も行い得る。一部の実施形態ではコンピュートノード１４０－１がそのような競合する全シナリオに対してこの追加の前処理を実行し得る一方で、他の実施形態ではコンピュートノード１４０－１が一つ又は一部の競合シナリオでのみ追加の前処理を実行し得る。例えば、コンピュートノード１４０－１は、未処理のシーケンス化されていない競合メッセージが他に存在しない場合にのみ、シーケンス化されていない未処理のメッセージに対して前記追加の前処理を実行し得る。これに代えて又はこれに加えて、コンピュートノード１４０－１は、前処理の結果のロールバック又は破棄に伴う時間量及び／又は演算（complexity）量に応じて、シーケンス化されていない未処理の競合メッセージに対する追加の前処理の実行に優先順位を付けてもよい。コンピュートノード１４０－１は、シーケンス化されていない未処理メッセージのシーケンスマーク付きバージョンを受信すると、該シーケンス化されていない未処理メッセージの（シーケンサ１５０－１により割り当てられた）処理シーケンス（順番）を求めて該シーケンスで同メッセージの処理を完了し得る。一部の実施形態において、当該処理には、前処理の１つ以上の結果のロールバック又は破棄が含まれ得る。

【0069】

既に上述した種類の前処理のほかに、一部の実施形態では、コンピュートノード１４０－１が、上記の構成に加えて又は上記の構成に代えて（additionally or alternatively）、メッセージを受け入れるか拒否するかを決めるメッセージ検証に関する前処理を実行し得る。例えば、同前処理には、メッセージで指定された価格や数量が上限値を超えていないことの確認（すなわち、「価格上限確認」や「数量上限確認」）、メッセージ内の記号が既知の記号であることの確認（すなわち、「不明記号確認」）、該記号の取引が現在許可されていることの確認（すなわち、「記号停止確認」）、価格が正しい小数位数で適切に指定されているかの確認（すなわち、「サブペニーチェック」）などといった、メッセージのリアルタイムリスクチェックの実行が含まれ得る。一部の実施形態では、同前処理の種類に、さらに、特定のクライアントや取引注文に対する「自己取引防止」が有効化（enabled）されている場合に、取引クライアントが自身に対してマッチ候補となる自己取引に特定のマッチ候補がなってしまうのを阻止するための、「自己取引防止」検証チェックが含まれ得る。電子取引システム１００は、取引注文がこれらの１種以上の検証チェックに失敗した場合、適切な拒否メッセージをもって応答し得る。このような検証チェックがコンピュートノード１４０－１によって実行されると上記の実施形態では説明しているが、一部の実施形態では、それに代えて又はそれに加えて、これらの種類の検証チェックの少なくとも一部がゲートウェイ１２０または電子取引システム１００内の他のノードによって実行されてもよいという点を理解されたい。

【0070】

さらなる実施形態では、クライアントから発信されたメッセージに対応付けられた一意的なシステム全体シーケンス識別子がゲートウェイ１２０－１に知らされることが有益となり得るか又は必要となり得る。この情報により、ゲートウェイ１２０－１は、元々の上りメッセージを、電子取引システム１００中のメッセージ同士が確実に適切に順序付けされるようにするために用いられる一意的なシーケンス番号とペアリングする（match up）ことが可能となり得る。前記ゲートウェイでのこのような構成は、電子取引システム１００が状態確定性を達成して前記ゲートウェイの活動に関するフォールトトレランス、高可用性および災害復旧性を提供するうえで必要なことであり得る。上りメッセージに対応付けられたシーケンス識別子に関する情報を維持するようにゲートウェイ１２０－１を構成するための解決策の一つは、該ゲートウェイ１２０－１に、前記シーケンス識別子を含んだ応答がシーケンサ１５０－１から戻ってくるのを待ってからコンピュートノード１４０－１へのメッセージの転送を行わせるというものである。このようなアプローチは、メッセージ処理のレイテンシの追加に繋がる可能性がある。さらなる例では、シーケンサ１５０－１が、ゲートウェイ１２０－１から最初に受信したメッセージのシーケンスマーク付きのものをコンピュートノード１４０－１に転送すると共に、これに並行して該シーケンスマーク付きメッセージをゲートウェイ１２０－１にも送信し得る。これならば、ゲートウェイ１２０－１が、電子取引システム１００でのレイテンシを最小限に抑えながらもシーケンス識別子に関する情報を維持するものとなり得る。

【0071】

図１Ｃは、先に開示した電子取引システム１００内のノード間でやり取りされる取引メッセージなどといった取引メッセージの、メッセージフォーマット１１０のフィールドの例示的な一実施形態についての一覧である。図１Ｃの例示的な実施形態において、メッセージフォーマット１１０は、電子取引システム１００内のノード間でやり取りされる際の取引メッセージの内的（すなわち、電子取引システム１００内での）表現に利用されるように意図された正規化メッセージフォーマットである。例示的な本実施形態において、ゲートウェイ１２０は、参加者１３０と電子取引システム１００との間でのメッセージのやり取りを行うと共に、参加者１３０が利用する１つ以上の金融取引プロトコルにより指定される１つ以上のフォーマットと電子取引システム１００内のノード間で使用される正規化取引フォーマットとの間で該メッセージの変換を行う。フィールド１１０－１～１１０－１７は本発明を限定する例ではなく、メッセージフォーマット１１０のフィールドの数が増えても減ってもよいし、別のフィールドが含まれていてもよいし、また、該フィールドの順序が図１Ｃに示したものに限定されないという点も理解されたい。

【0072】

本例のメッセージフォーマット１１０のフィールドは１種類のメッセージフォーマット内にしか描かれていないが、複数のメッセージフォーマットに分散されたり、層状プロトコルにカプセル化させれたりしてもよい。例えば、他の実施形態では、メッセージフォーマット１１０内の一部のフィールドが層状プロトコルのヘッダ、トレーラ又は１つ以上の拡張フィールドの一部として含められると共に、同メッセージフォーマット１００のその他のフィールドについては該層状プロトコルのメッセージペイロード内にカプセル化させるようにしてもよい。例示的な一部の実施形態において、メッセージフォーマット１１０は、ＩＰデータグラム、ＵＤＰデータグラム又はＴＣＰパケットの各ペイロード部分や、イーサネットデータフレームフォーマットやＩｎｆｉｎｉＢａｎｄ、ユニバーサルシリアルバス（ＵＳＢ）、ＰＣＩＥｘｐｒｅｓｓ（ＰＣＩ－ｅ）及び高精細マルチメディアインターフェース（ＨＤＭＩ）を含む（但し、これらに限定されない）その他のデータフレームフォーマットなどのメッセージデータフレームフォーマットの各ペイロード部分を含め（但し、これらに限定されない）、別のメッセージフォーマットのペイロード（データ）部分にカプセル化された１つ以上のデータフィールドを規定したものであり得る。

【0073】

メッセージフォーマット１１０は、１つ以上の参加者デバイス１３０との通信用に金融取引プロトコルに準拠して送信又は受信されるメッセージ内に含められ得る情報に対応したフィールド１１０－１．．．１１０－６を有する。本発明を限定する例ではないが、メッセージタイプフィールド１１０－１は、取引メッセージの種類を表す。一部の取引メッセージタイプ（「新規注文」、「注文取換」、「注文取消」などのメッセージタイプ）は参加者デバイス１３０から受信したメッセージに対応するものであるのに対し、他のメッセージタイプ（例えば、「新規注文受付確認」、「注文取換受付確認」、「注文取消受付確認」、「成立」、「約定報告」、「一方的（unsolicited）取消」、「トレードバスト」、各種拒否メッセージなど）は、電子システム１００で生成されて参加者デバイス１３０に送信される取引メッセージ内に含められるメッセージに対応するものである。

【0074】

また、メッセージフォーマット１１０は、記号フィールド１１０－２を有し、記号フィールド１１０－２には、銘柄記号や株式ティッカーなどといった、取引される金融証券の識別子が含められる。例えば、「ＩＢＭ」は、「ＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ」の銘柄記号である。メッセージフォーマット１１０内のサイドフィールド１１０－３は、取引メッセージが「買い」、「売り」、それとも「空売り」であるのかなどといった、取引メッセージの「サイド」を表すのに用いられ得る。同様に、価格フィールド１１０－４は証券の購入や売却の希望価格を表すのに用いられ得て、数量フィールド１１０－５は証券の希望数量（例えば、株数等）を表すのに用いられ得る。また、メッセージフォーマット１１０は、注文トークンフィールド１１０－６を有し得て、注文トークンフィールド１１０－６には、参加者デバイス１３０と前記電子取引システムとの間でゲートウェイ１２０を介して確立された特定の取引セッション（すなわち、「コネクション」または「フロー」）の場面で新規注文を一意的に識別するために参加者デバイス１３０によって最初に提供される「注文トークン」や「クライアント注文ＩＤ」が入力され得る。

【0075】

フィールド１１０－１・・・１１０－６は大半の金融取引プロトコルによる大半のメッセージタイプに通常含められている代表的なフィールドであるが、メッセージフォーマット１１０には、特に、特定のメッセージタイプや特定の金融取引プロトコルをサポートするための、追加の又は代替的なフィールドが含められてもよいという点を理解されたい。例えば、多くの金融取引プロトコルによる「注文取換」や「注文取消」といったメッセージタイプでは、最初の注文と区別するため、取換対象又は取消対象の注文を表すための追加の注文トークンを入力する（supply）ことが参加者１３０に求められる。同様に、「注文取換」や「注文取消」は取換／取消数量フィールドも典型的に有し得て、「注文取換」は取換価格フィールドを有し得る。また、このような追加の注文取換／取消トークンフィールドや取換価格フィールドや取換／取消数量フィールドは、電子取引システム１００によって送信される対応する受付確認メッセージにも含められ得る。

【0076】

また、メッセージフォーマット１１０は、電子取引システム１００内部で内的に使用され得るものであって参加者デバイス１３０とやり取りされるメッセージ内のフィールドに必ずしも対応するとは限らないフィールド１１０－１１．．．１１０－１７を有する。例えば、ノード識別子フィールド１１０－１１は、電子取引システム１００内の各ノードを一意的に識別するものであり得る。一部の実施形態において、生成ノードは、電子取引システム１００中に自身が導入するメッセージ内に自身のノード識別子を含め得る。例えば、各ゲートウェイ１２０は、参加者デバイス１３０からコンピュートノード１４０及び／又はシーケンサ１５０へと自身が転送するメッセージ内に自身のノード識別子を含め得る。同様に、各コンピュートノード１４０は、電子取引システム１００内の別のノードへと送信されるように自身が生成したメッセージ（例えば、受付確認や、約定や、１つ以上の参加者デバイス１３０へと転送されることが最終的に意図されている種類非同期メッセージ等）内に自身のノード識別子を含め得る。したがって、電子取引システム１００中に導入される各メッセージは、同メッセージ内のノード識別子フィールド１１０－１１によって同メッセージの生成ノードと関連付けられ得る。

【0077】

また、メッセージフォーマット１１０は、フロー識別子フィールド１１０－１２を有し得る。一部の実施形態では、参加者デバイス１３０とゲートウェイ１２０との間に確立された各取引セッション（すなわち、「コネクション」または「フロー」）が、電子取引システム１００全体をとおして一意的であるように意図されているフロー識別子によって識別され得る。参加者デバイス１３０は、１つ又は複数のゲートウェイ１２０を介して１つ又は複数のフローによって電子取引システム１００に接続され得る。そのような実施形態では、特定のフローで参加者デバイス１３０と電子取引システム１００との間でやり取りされる全メッセージの、（電子取引システム１００内のノード間で利用される）正規化メッセージフォーマット１１０に準拠したバージョンのメッセージのフロー識別子フィールド１１０－１２に、そのフローに対する一意的な識別子が含められる。一部の実施形態では、フロー識別子フィールド１１０－１２が、メッセージの生成ノードにより入力される。例えば、ゲートウェイ１２０は、自身が参加者１３０から受信して電子取引システム１００中へと導入するメッセージのフロー識別子フィールド１１０－１２に、それに対応したフローの識別子を入力し得る。同様に、コアコンピュートノード１４０は、自身が生成するメッセージ（すなわち、受付確認メッセージ、成立などの応答メッセージや、非同期メッセージを含むその他の下りメッセージ）のフロー識別子フィールド１１０－１２に、それに対応したフロー識別子を入力し得る。

【0078】

一部の実施形態では、フロー識別子フィールド１１０－１２に、高可用性目的のために実際には複数の（場合によっては、複数のゲートウェイによる）冗長的な取引セッションコネクションとして実現され得る所与の論理フローを一意的に識別する値が含められる。すなわち、一部の実施形態では、同じフローＩＤが、１つ以上の参加者デバイス１３０と１つ以上のゲートウェイ１２０との間の２つ以上の冗長フローに割り当てられ得る。そのような実施形態において、該冗長フロー同士は、アクティブ／スタンバイ構成、あるいは、アクティブ／アクティブ構成のいずれかとなり得る。アクティブ／アクティブ構成では、複数の冗長フローにより、機能的に等価なメッセージが並行して１つ以上の参加者デバイス１３０と１つ以上のゲートウェイ１２０との間で同時にやり取りされ得る。すなわち、取引クライアントは、電子取引システム１００に対して複数の冗長フローにより機能的に等価なメッセージを並行して同時に送信すると共に該複数の冗長フローにより電子取引システム１００から複数の機能的に等価な応答を並行して受信し得るのに対し、電子取引システム１００は、このような機能的に等価なメッセージのうちの一つにしか処理を行わないものとされ得る。アクティブ／スタンバイ構成では、一度に複数の冗長フローのうちの一つのフローのみがアクティブフローとして指定され得る一方、複数の冗長フローのうちの残りのフローについてはスタンバイフローであると指定され得て、取引メッセージは、現行のアクティブフローでのみ実際にやり取りされ得る。冗長フローがアクティブ／アクティブとアクティブ／スタンバイのどちらの構成で構成されるのかにかかわらず、任意の冗長フローでやり取りされるメッセージ同士は、同メッセージの生成ノードによって正規化メッセージフォーマット１１０のフロー識別子フィールド１１０－１２に格納された同じまたは共通のフロー識別子を使って識別され得る。

【0079】

上述したように、一部の実施形態において、電子システム１００内のノード間でやり取りされるメッセージはシーケンサ１５０に送信されてシーケンス識別子でマークされる。そのため、メッセージフォーマット１１０は、シーケンス識別子フィールド１１０－１４を有する。一部の実施形態において、「マークが付いていないメッセージ」は、シーケンス識別子フィールド１１０－１４が空の空白（例えば、ゼロ等）の値の状態で送信されるものであり得る。他の実施形態において、マークの付いていないメッセージのシーケンス識別子フィールド１１０－１４は、前記シーケンサがメッセージに決して割り当てないような特定の所定値、あるいは、無効な値に設定され得る。さらなる他の実施形態では、メッセージにマークが付いていないことが、メッセージがシーケンス化されているか否かを表すブーリアン値、フラグ値などといった、同メッセージの別のフィールド（図示せず）内の表示によって指定され得る。そして、シーケンサ１５０は、マークが付いていないメッセージを受信すると、該マークが付いていないメッセージのシーケンス識別子フィールド１１０－１４に有効シーケンス識別子値を入力することで「シーケンスマーク付きメッセージ」を生成し得る。シーケンスマーク付きメッセージのシーケンス識別子フィールド１１０－４内の有効なシーケンス識別子値は、メッセージを一意的に識別すると共に、該マーク付きのメッセージの、電子取引システム１００中のその他のマーク付きメッセージとの相対順序付け内での確定的位置を特定する。本例では、シーケンサ１５０により送信される「シーケンスマーク付きメッセージ」と該シーケンサで受信するマークの付いていない対応するメッセージとが、シーケンスマーク付きのメッセージのほうのシーケンス識別子フィールド１１０－１４に有効なシーケンス識別子値が含まれているという点を除き、同一のものとなり得る。

【0080】

一部の実施形態において、メッセージフォーマット１１０は、さらに、参照シーケンス識別子フィールド１１０－１５を有し得る。生成ノードは、自身が生成する新規メッセージの参照シーケンス識別子フィールド１１０－１５に、生成中の該メッセージと関係する過去のメッセージのシーケンス番号の値を入力し得る。参照シーケンス識別子フィールド１１０－１５内の値により、電子取引システム１００内のノードは、メッセージを過去の関連メッセージと関連付けることができるようになる。

【0081】

参照シーケンス識別子フィールド１１０－１５で参照される過去の関連メッセージは、同じ「注文関連（chain）」（すなわち、「取引注文関連」）の過去のメッセージであり得る。大半の金融取引プロトコルでは、メッセージが、共通のメッセージを参照するか又は共通のメッセージに「由来する」同一フロー上の一連のメッセージである所与の「注文関連」へと論理的にグループ分けされ得る。所与の注文関連は、典型的に、参加者デバイス１３０が送信する「新規注文メッセージ」で始まる。注文関連の次のメッセージは、典型的に、電子取引システムによる応答（例えば、前記取引システムがメッセージを受け付けた場合の「新規注文受付確認」メッセージや、（本発明を限定しない例であるが）無効な価格などの恐らくフォーマットやパラメータが無効であるといった理由から前記取引システムがメッセージを拒否した場合の「新規注文拒否」メッセージのいずれか）である。所与の注文関連には、以前に受付確認がなされた（しかし、未だオープン状態のままの、つまり、取り消されていない且つ／或いは成立していない数量が少なくとも一部含まれている）新規注文のうちの少なくとも一部の数量を取り消す、参加者デバイス１３０により送信された「注文取消」メッセージも含まれ得る。「注文取消」メッセージについても、同じく（also）該注文関連の一部となる「注文取消受付確認」、「注文取消拒否」メッセージのいずれかを使って、前記電子取引システムによる受付確認又は拒否が行われ得る。また、所与の注文関連には、以前に受付確認がなされた（しかし、未だオープン状態のままの）新規注文の数量および／または価格を取り替える、参加者デバイス１３０により送信された「注文取換」メッセージも含まれ得る。「注文取換」メッセージについても、同じく（also）該注文関連の一部となる「注文取換受付確認」、「注文取換拒否」メッセージのいずれかを使って、前記電子取引システムによる受付確認又は拒否が行われ得る。以前に受付確認がなされた未だオープン状態のままの注文は、反対側の１つ以上の逆注文（つまり、一方のサイドが「買い」であるときの、他方のサイドの「売り」又は「空売り」）とマッチングする可能性があり、すると、電子取引システム１００は、（一つのマッチでオープン注文の全数量が成立した場合の）完全「成立」メッセージや（一つのマッチでオープン注文の数量の一部しか成立しなかった場合の）１つ以上の部分「成立」メッセージを生成し得るが、これらの「成立」注文も該注文関連の一部となる。一般的には、上述のように、前記参照シーケンス識別子によって、同じ注文関連内の別の先行メッセージが識別され得る。

【0082】

例えば、参照シーケンス識別子フィールド１１０－１５の話題に戻るが、参照シーケンス番号の値は、参加者デバイス１３０から発信されてゲートウェイ１２０によって電子取引システム１００中に導入された「上り」メッセージに対して前記シーケンサが割り当てられたシーケンス番号であり得て、コンピュートノード１４０により生成される応答メッセージなどといった、それに対応する「下り」メッセージは、応答対象となる前記上りメッセージのシーケンス番号値を参照するものとなり得る。この例では、コンピュートノード１４０で生成された「新規注文受付確認」メッセージや「成立」メッセージの参照シーケンス識別子フィールド１１０－１５内に、該コンピュートノード１４０が「新規注文受付確認」メッセージによる応答や「成立」メッセージによる注文成立で対処しようとしている対応する「新規注文」メッセージに割り当てられたシーケンス識別子の値が、含められる。しかしながら、一般的に言って、参照シーケンス識別子フィールド１１０－１５の値は、必ずしも、電子取引システム１００が直接応答しようとしているメッセージのものである必要はなく、同じ注文関連の一部である先行メッセージのもの、例えば、「新規注文」や「新規注文受付確認」のシーケンス番号であってもよい。

【0083】

また、少なくとも一部のメッセージタイプになるが、一部の実施形態において、ゲートウェイ１２０は、自身が電子取引システム１００中に導入するメッセージの参照シーケンス識別子フィールド１１０－１５に、先行する関連メッセージのシーケンス識別子の値を入力し得る。例えば、ゲートウェイ１２０は、「注文取消」や「注文取換」メッセージ内の参照シーケンス識別子フィールド１１０－１５に、それ以前の対応する「新規注文」や「新規注文受付確認」メッセージに割り当てられたシーケンス識別子の値を入力し得る。また、同様に、コアコンピュートノード１４０も、対応する「注文取消受付確認」メッセージや「注文取換受付確認」メッセージのシーケンス識別子フィールド１１０－１５に、該コンピュートノード１４０が直接応答しようとしているメッセージのシーケンス識別子の値ではなく（例えば、「注文取消」や「注文取換」メッセージのシーケンス識別子ではなく）「新規注文」や「新規注文受付確認」のシーケンス識別子の値を入力するものとされてよい。再び述べるが（Again）、参照シーケンス識別子フィールド１１０－１５により、電子取引システム１００内のノード全般が、メッセージを同じ注文関連の１つ以上の過去のメッセージと関連付けることができるようになる。

【0084】

また、生成ノードは、自身が電子取引システム１００中に導入するメッセージ内に、ノード固有タイムスタンプフィールド１１０－１３を含め得る。シーケンサ１５０によって出力されたシーケンスマーク付きメッセージのシーケンス識別子フィールド１１０－１４に含まれているシーケンス識別子は電子取引システム１００全体で一意的なものとなるように意図されているのに対し、ノード固有タイムスタンプフィールド１１０－１３内の値は、一部のメッセージ同士、すなわち、特定の生成ノードによって電子取引システム１００中に導入されるメッセージ同士の中でのみ一意的なものとなり得る。本明細書では「タイムスタンプ」と称しているものの、ノード固有タイムスタンプフィールド１１０－１３に配される値は、そのノードで生成されるメッセージ同士の中で一意的となる適切な値であれば、どのような値であってもよい。実際には、前記ノード固有タイムスタンプは、例えば、タイムスタンプであってもよいし単調増加又は単調減少する任意の適切な値であってもよい。

【0085】

一部の実施形態は、前記メッセージフォーマット内に、別のタイムスタンプフィールドを有し得る。例えば、メッセージフォーマットは、参照タイムスタンプフィールドを有すし得る。該参照タイムスタンプフィールドは、過去の関連メッセージの生成ノードによって割り当てられたタイムスタンプ値であり得る。このような実施形態において、コンピュートノード１４０は、自身が生成するメッセージのノード固有タイムスタンプフィールド１１０－１３に新たなタイムスタンプ値を含め得ると共に、自身が生成する同メッセージの参照タイムスタンプフィールドに関連メッセージのタイムスタンプ値を含め得る。例えば、前記コンピュートノードにより生成される「新規注文受付確認」メッセージは、該「新規注文受付確認メッセージ」の参照タイムスタンプフィールドに、自身が応答しようとしている「新規注文」のタイムスタンプ値を含め得る。また、一部の実施形態において、コンピュートノード１４０は、自身が生成するメッセージのノード固有タイムスタンプフィールド１１０－１３に新たなタイムスタンプ値を含め得ることなく、該ノード固有タイムスタンプフィールド１１０－１３に過去の関連メッセージのタイムスタンプ値を単に入力し得る。

【0086】

また、メッセージフォーマット１１０は、エンティティタイプフィールド１１０－１６およびエンティティカウントフィールド１１０－１７を有し得る。メッセージのエンティティタイプは、それがゲートウェイ１２０、コンピュートノード１４０のどちらで電子取引システム１００中に導入されるものであるのか、すなわち、該メッセージが参加者デバイス１３０からゲートウェイ１２０で受信される上りメッセージであるのか、それとも、コンピュートノード１４０によって生成されて参加者デバイス１３０へと送信される下りメッセージであるのかに左右され得る。例えば、一部の実施形態では、上りメッセージのエンティティタイプが「フロー」であると見なされる（そして、上りメッセージのエンティティタイプフィールド１１０－１６には、ゲートウェイ１２０により、タイプ「フロー」を表す値が入力される）のに対し、下りメッセージのエンティティタイプが「記号」であると見なされる（そして、下りメッセージのエンティティタイプフィールド１１０－１６には、コンピュートノード１４０により、タイプ「記号」を表す値が入力される）。このような実施形態では、タイプ「フロー」のエンティティのカウントがゲートウェイ１２０によって維持されると共に、タイプ「記号」のエンティティのカウントがコンピュートノード１４０によって維持される。

【0087】

エンティティタイプ「フロー」について考える。ゲートウェイ１２０は、該ゲートウェイ１２０上のアクティブな各フローで該ゲートウェイ１２０により受信される上りメッセージをカウントすることで、各フローごとの上りメッセージのカウントを維持し得る。例えば、ゲートウェイ１２０上で４つの非冗長フローがアクティブとなっている場合、前述したように、それぞれのフローに対して一意的なフロー識別子が割り当てられれて、該ゲートウェイ１２０は、それら４つの各フローで受信される上りメッセージの数をカウントすることにより、各フローごとの上りメッセージのカウントを維持する。このような実施形態では、ゲートウェイ１２０が、上りメッセージのエンティティカウントフィールド１１０－１７に、（該メッセージのフロー識別子フィールド１１０－１２に入力されたフロー識別子値によって電子取引システム１００全体をとおして識別される）該上りメッセージのフローに対応した、各フローごとの上りメッセージのカウントを入力する。

【0088】

アクティブ／アクティブ構成の冗長フローの場合（すなわち、前述のように、１つ以上のゲートウェイ１２０を介して接続された１つ以上の参加者デバイス１３０から並行して同じメッセージ又は少なくとも機能的に等価なメッセージを複数のフローが受信する場合）、各基礎冗長フローに同じフロー識別子が割り当てられ得るが、特に、該冗長フロー同士が別々のゲートウェイ１２０上に実現されている場合には、各冗長フローごとのフロー別の上りメッセージのカウントが各基礎冗長フローごとに個別に維持されることになり得る。参加者デバイス１３０は同じ順序（すなわち、シーケンス）で同じ一連のメッセージを各々の冗長フローを介して電子取引システム１００に送信するものと予想されるので、別々の冗長フローで受信した機能的に等価なメッセージに振り当てられるエンティティカウントも同一になると予想される。

【0089】

機能的に等価なこれらの上りメッセージは、１つ以上のゲートウェイ１２０によってシーケンサ１５０及びコンピュートノード１４０へと転送され得る。つまり、このような実施形態において、シーケンサ１５０およびコンピュートノード１４０は、同じフロー識別子が対応付けられた機能的に等価な上りメッセージを複数受信することになり得るが、該シーケンサ１５０および該コンピュートノード１４０は、同じフロー識別子を有する複数のメッセージのエンティティカウントが同一である場合、該メッセージ同士が機能的に等価であると識別することができる。

【0090】

一部の実施形態において、シーケンサ１５０およびコンピュートノード１４０は、各フローに対応した上りメッセージのエンティティカウントフィールド１１０－１７に含められたエンティティカウントの最大値を、各フローごとに追跡し得る。これにより、シーケンサ１５０およびコンピュートノード１４０は、各ノードが受信した複数の機能的に等価な上りメッセージのうちの最初に到着したメッセージに対してのみ処理を行い、その他の後から到着した機能的に等価な上りメッセージを無視することができる。一部の実施形態では、例えば、シーケンサ１５０が、最初に到着した該機能的に等価な上りメッセージのみをシーケンス化し得ると共に、コンピュートノード１４０が、最初に到着した該機能的に等価なメッセージに対してのみ処理を開始し得る。ノード（すなわち、シーケンサ１５０またはコンピュートノード１４０）が受信した上りメッセージのエンティティカウントが、そのノードで同フローについて確認されたエンティティカウントの最大値と同じ又はそれを下回る場合、該ノードは、その上りメッセージが、過去に受信した別の上りメッセージと機能的に等価であると判定し得ると共に、後続受信の機能的に等価な上りメッセージを単に無視し得る。

【0091】

次に、エンティティタイプ「記号」の場合について考える。コンピュートノード１４０は、該コンピュートノード１４０が取り扱う（serviced by）各記号について、該コンピュートノード１４０により生成されて該コンピュートノード１４０から送信される下りメッセージをカウントすることで、各記号ごとの下りメッセージのカウントを維持し得る。例えば、コンピュートノード１４０が４種類の記号（例えば、ＭＳＦＴ、ＧＯＯＧ、ＩＢＭ、ＯＲＣＬ等）を取り扱うものである場合、それぞれの記号に対し、前述のように、メッセージの記号フィールド１１０－２に入力される記号識別子が割り当てられると共に、該コンピュートノード１４０は、自身が生成・送信する、それら４種類の各記号を取り扱った下りメッセージの数をカウントすることで、各記号ごとの下りメッセージのカウントを維持する。このような実施形態では、コンピュートノード１４０が、上りメッセージのエンティティカウントフィールド１１０－１７に、下りメッセージの（該メッセージの記号識別子フィールド１１０－２に入力された値によって電子取引システム１００全体をとおして識別される）記号に対応付けられた、各記号ごとの下りメッセージカウントを入力する。

【0092】

後でさらに説明するように、一部の実施形態において、コンピュートノードは、高可用性の理由から複数のコンピュートノードが並行して特定の記号を取り扱うものとなるように構成され得る。複数のコンピュートノードが同じ（given）記号を取り扱う場合も、シーケンサ１５０によって電子取引システム１００全体をとおしてメッセージ同士が確定的に順序付けされていることから、どのコンピュートノードであっても、同一記号を参照した上りメッセージ同士を同じ順序（すなわち、シーケンス）かつ同じ様式で処理し、これにより、機能的に等価な応答メッセージを確実に並行して生成することが可能となる。特定の記号についての下りメッセージを複数のコンピュートノード１４０をとおして送出する場合について考えるが、その記号を参照した各下りメッセージと機能的に等価なメッセージが、その記号を取り扱うその他のアクティブな（actively）各コンピュートノード１４０からも送出されているはずである。これらの下りメッセージは、いずれも、コンピュートノード１４０からシーケンサ１５０やゲートウェイ１２０へと送信され得る。したがって、このような実施形態でのシーケンサ１５０やゲートウェイ１２０は、同じ記号に関する複数の機能的に等価な上りメッセージを受信することになり得るが、該シーケンサ１５０および該ゲートウェイ１２０は、同じ記号識別子を有する複数のメッセージの前記エンティティカウントが同一である場合に、該メッセージ同士が機能的に等価であると識別することができる。一部の実施形態において、シーケンサ１５０およびゲートウェイ１２０は、各記号ごとに、同記号に関する下りメッセージのエンティティカウントフィールド１１０－１７に含められたエンティティカウントの最大値を追跡し得る。これにより、シーケンサ１５０およびゲートウェイ１２０は、各ノードが受信した機能的に等価な複数の下りメッセージのうちの最初に到着したメッセージに対してのみ処理を行い、機能的に等価な後から到着したその他の下りメッセージを無視することができる。一部の実施形態では、例えば、シーケンサ１５０が、最初に到着した該機能的に等価な下りメッセージのみをシーケンス化し得る。同様に、ゲートウェイ１２０は、最初に到着した該機能的に等価なメッセージに対してのみ処理を開始し得る。ノード（すなわち、シーケンサ１５０またはゲートウェイ１２０）が受信した下りメッセージのエンティティカウントが、そのノードで同記号についてこれまでに確認されたエンティティカウントの最大値と同じ又はそれを下回る場合、該ノードは、その下りメッセージが、過去に受信した別の下りメッセージと機能的に等価であると判定し得ると共に、後続受信の機能的に等価な下りメッセージを単に無視し得る。

【0093】

複数の機能的に等価なメッセージのうちのシーケンサ１５０に最初に到着したメッセージのみを該シーケンサ１５０がシーケンス化する実施形態において、該シーケンサがこれを行う方法には、様々なものが有り得る。一例では、最初に到着した該機能的に等価なメッセージと機能的に等価な、後から到着したその他の到着メッセージが、前記シーケンサによって単に無視され得る（その場合、機能的に等価な一連のメッセージについては、シーケンスマーク付きの一つのメッセージのみが前記シーケンサによって出力され得る）。別の可能性として、前記シーケンサは、例えば、機能的に等価な最初のメッセージの（エンティティタイプ「フロー」や「記号」を有するメッセージである場合の）エンティティカウント、フロー識別子又は記号識別子と、そのシーケンス番号との関連付けを行うことにより、自身が該メッセージに割り当てたシーケンス番号の追跡を行う。これにより、前記シーケンサ１５０は、該シーケンサで受信した機能的に等価なメッセージのうち最初に到着したメッセージに該シーケンサが割り当てた値と、シーケンス化後のバージョンの機能的に等価な全メッセージのシーケンス識別子フィールド１１０－１４の値が同じになるようにして、シーケンス化後のバージョンの機能的に等価な各メッセージを出力し得る。

【0094】

他の実施形態において、シーケンサ１５０は、メッセージ同士が機能的に等価であるか否かを追跡せず、該シーケンサ１５０に到着するシーケンス化されていない各メッセージに対し、同メッセージが機能的に等価な複数のメッセージのうちの一つであるか否かにかかわらず、一意的なシーケンス番号を割り当て得る。このような実施形態では、機能的に等価な複数のメッセージのうちのシーケンス化後のバージョンの各メッセージに対し、相異なるシーケンス識別子が、シーケンサ識別子フィールド１１０－１４の値として前記シーケンサによって割り当てられる。このような実施形態において、シーケンス化された機能的に等価なメッセージの受信ノードは、シーケンス化された機能的に等価なメッセージ同士の中で該ノードに最初に到着したシーケンス化後のバージョンのメッセージのシーケンス識別子を用いて、機能的に等価な一連のメッセージ同士の中での実効シーケンス識別子を求め得る。電子取引システム１００内のノード間にポイントトゥポイント型のダイレクトコネクションが存在する実施形態では、シーケンス化後のバージョンのメッセージがシーケンサ１５０によってシーケンス化順に送出されることから、それに応じて、該シーケンサに直接接続されたどのノードでも、シーケンス化後のバージョンのメッセージが同じシーケンス化順に受信されるはずである。したがって、シーケンス化されたメッセージを前記シーケンサとのポイントトゥポイント型のダイレクトコネクションによって各自受信するどのノードでも、シーケンス化された機能的に等価な複数のメッセージのうちの最初に到着するシーケンス化メッセージのシーケンス識別子フィールド１１０－１４の値は同じになるはずである。

【0095】

これからの説明から明白かもしれないが、メッセージフォーマット１１０のようなメッセージフォーマットを備える実施形態では、メッセージのシーケンス識別子以外にも、電子取引システム１００全体をとおしてメッセージを一意的に識別するための方法が他に複数存在し得る。例えば、メッセージがノード識別子とノード固有タイムスタンプの両方を有する実施形態では、メッセージ内にこれら２種類の識別子が存在するだけで、電子取引システム１００全体をとおして該メッセージを一意的に識別するのに十分であり得る。これらのようなフィールドは、メタデータを含んでいると解釈され得て、該メタデータが同一である複数のメッセージは、共通のメタデータを含んでいると解釈され得る。同様に、電子取引システム１００全体をとおしてフロー識別子が一意的なものとなる実施形態では、メッセージのフロー識別子とノード固有タイムスタンプとの組合せだけで、電子取引システム１００全体をとおしてメッセージを一意的に識別するのに十分であり得る。また、フロー識別子とエンティティカウントの組合せだけで、エンティティタイプ「フロー」のメッセージを一意的に十分識別することが可能であり、記号識別子とエンティティカウントの組合せだけで、エンティティタイプ「記号」のメッセージを一意的に十分識別することが可能である。

【0096】

しかし、メッセージに割り当てられたシーケンス識別子以外に電子取引システム１００全体をとおしてメッセージを一意的に識別する方法が有り得たとしても、シーケンス識別子は、電子取引システム１００中のその他のノードによって生成されるその他のメッセージ同士の中での該メッセージの相対順序付けを公平的かつ確定的に指定するのに依然として必要となるという点に留意されたい。例えば、ノード固有タイムスタンプが実際にタイムスタンプ値として実現されている場合、ノード間のシステムクロックが完璧に同期していたとしても、別々のノードによって各自生成された２つの異なる各メッセージに対し、各々の生成ノードによって同一のタイムスタンプ値が割り当てられるという可能性があり、その場合、これら２つのメッセージの相対順序は曖昧になってしまう。たとえメッセージを一意的に識別することが可能であるしても、両メッセージの受信ノードは、メッセージに対して何らかの（possible）処理を行う前に、何らかの方法によってこれら２つのメッセージの相対順序付けを求める必要がある。

【0097】

この曖昧さを受信ノードが解決するための方法の一候補として、例えば、所与のメッセージをランダムに選び出して該メッセージが電子取引システム１００全体のメッセージの相対順序付けの中で別の所与のメッセージよりも先行していると見なすというランダム性を利用した方法が有り得る。しかしながら、ランダム性を使って曖昧さを解決するという構成は、電子取引システム１００全体の「状態確定性」をサポートしない。共通の一連のメッセージに対して別々の受信ノードが別々の相対順序付けをランダムに決定した場合、電子取引システム１００内の動作（behavior）が予測不可能かつ非確定的なものとなってフォールトトレランス、高可用性、災害復旧性などの重要機能の適切（correct）な実現を妨げる可能性がある。

【0098】

順序付けの曖昧さを受信ノードが解決するための別の方法として、例えば、メッセージに対応付けられたノード識別子を基にして所定の優先順位付けを行うという方法によるものが挙げられる。しかしながら、このような方法は、電子取引システム１００中にメッセージを導入したノードのノード識別子に単純に基づいて一部のメッセージに高い優先順位を与えるため、公平性という重要な目標に反することになる。例えば、たまたま所定の優先順位付方法でより高い優先順位であると見なされているゲートウェイ１２０を介して電子取引システム１００に接続されているという理由だけで、所与の参加者装置１３０がより有利に扱われる（favored）ことになり得る。

【0099】

エンティティカウントと（メッセージのエンティティタイプが「記号」、「フロー」のどちらであるのかに応じて）記号識別子又はフロー識別子とによってメッセージが一意的に識別される場合には、（エンティティタイプが「記号」であるメッセージの場合は）同記号又は（エンティティタイプが「フロー」であるメッセージの場合は）同フローに関するその他のメッセージ同士との間で、順序付けが確定的なものとなり得る。しかし、別の記号やフローに関するその他のメッセージとの間では、依然として順序付けが非確定的なままである。

【0100】

したがって、メッセージフォーマット１００内の、シーケンサ１５０によってメッセージに割り当てられたシーケンス識別子以外のフィールドだけでも、電子取引システム１００全体をとおしてメッセージを一意的に識別するのに十分かもしれないが、該シーケンス識別子は、電子取引システム１００内のその他のメッセージに対する所与のメッセージの順序付けを公平的かつ確定的に特定するのに依然として必要になり得る。このような実施形態において、シーケンサ１５０（あるいは、シーケンサ１５０が複数存在する場合であれば現行アクティブな一つのシーケンサ）は、電子取引システム１００全体でのシーケンスマーク付きメッセージ同士の純粋に（truly）確定的な順序付けを行う権限を有する権限元（authoritative source）として機能する。

【0101】

一部の実施形態において、電子取引システム１００内のノードは、生成ノードによって電子取引システム１００中に導入されたシーケンス化されていない（マークが付いていない）バージョンのメッセージと、シーケンサ１５０によってシーケンス識別子が割り当てられた（マークが付いた）バージョンのメッセージの、２種類のバージョンのメッセージを受け取り得る。これは、生成ノードが、マークの付いていないメッセージを１つ又は複数の受信ノードだけでなくシーケンサ１５０にも送信する実施形態で起こり得る。その後、シーケンサ１５０は、それと同じ受信ノードを含む一連のノードに対して、シーケンスマークが付いたバージョンの同メッセージを送信し得る。

【0102】

前述したように、シーケンスマーク付きバージョンのメッセージが電子取引システム１００におけるその他のマーク付きメッセージ同士の中での該メッセージの相対処理順序（すなわち、シーケンス内での位置）を決定するのに役立つ一方、マークが付いていないバージョンのメッセージを受信ノードに受信させるという構成も有用であり得る。例えば、マーク付きバージョンのメッセージは、シーケンサ１５０という仲介ホップを介して送信されることから、（例えばノード間にダイレクトコネクションが存在する実施形態では）マークの付いていないバージョンのメッセージがマーク付きバージョンのメッセージよりも先に受信されることが、想定外ではあるものの十分に起こり得る。つまり、一部の実施形態において、受信ノードは、その他のマーク付きメッセージ同士の中での相対順序付けを決める権限を有するマーク付きバージョンのメッセージを受信するよりも先にマークが付いていないメッセージを受信することで、該マークが付いていないメッセージの処理をアクティベートするという機会を享受することになる。

【0103】

同じメッセージについてマーク付きのバージョンとマークが付いていないバージョンの両方を受信したノードは、双方のバージョンのメッセージ内の共通の識別情報又は「共通のメタデータ」を使って、これら２つのバージョンのメッセージを互いに関連付け得る。例えば、生成ノードは、前述したように、自身が生成するメッセージ（すなわち、マークが付いていないメッセージ）に、電子取引システム１００全体での各メッセージの一意的な識別を協力して行い得るノード識別子とノード固有タイムスタンプとを含め得る、シーケンサ１５０によって割り当てられたシーケンス識別子を除いてメッセージのマーク付きバージョンとマークの付いていないバージョンが本質的に同一である実施形態では、マーク付きメッセージにも、対応するマークが付いていないほうのメッセージにも含まれているものと同じノード識別子およびノード固有タイムスタンプが含められ得ることから、両方のバージョンのメッセージの受信ノードは、マークが付いたバージョンとマークが付いていないバージョンとを関連付けることが可能となる。これにより、マーク付きメッセージは、そのままでも（directly）電子取引システム１００中のその他のマーク付きメッセージに対する自身の相対順序付けが定まるようになっているが、同じメッセージのマークが付いていないバージョンとマーク付きバージョンとの間でなされ得る前記関連付けにより、（前述したその関連付けを少なくとも使って）電子取引システム１００中の（マークが付いたもの、マークが付いていないものにかかわらず）その他のメッセージに対する同マーク付きメッセージの相対順序付けが定まるようになる。また、電子取引システム１００内のノードは、メッセージを一意的に識別する前述のその他の方法によって、シーケンスマーク付きのものをマークの付いていないバージョンのメッセージと関連付けるものであってもよいという点を理解されたい。例えば、シーケンスマーク付きメッセージとマークが付いていないメッセージとの関連付けが、フロー識別子とノード固有タイムスタンプとの組み合わせによって行われてもよい。これに加えて又はこれに代えて、エンティティタイプ「記号」、「フロー」を各自有するメッセージの場合、そのような関連付けは、メッセージのエンティティカウントと該メッセージ内の記号識別子又はフロー識別子とによって行われてもよい。

【0104】

マイクロ秒、さらには、ナノ秒さえも必然的である高速取引の時代では、電子取引システム１００とメッセージをやり取りする参加者デバイス１３０がレイテンシの影響を極めて受け易い場合が多く、予測可能な低レイテンシが好まれる。図１Ａに示す配置構成は、少なくとも各ゲートウェイ１２０と各コンピュートノード１４０との間にポイントトゥポイントメッシュ１７２のアーキテクチャを設けることで、この要件に応えている。一部の実施形態では、メッシュ１７２内の各ゲートウェイ１２０が、コンピュートノード１４０およびシーケンサ１５０への専用の高速ダイレクトコネクション１８０を有するものとされ得る。

【0105】

例えば、第１ゲートウェイ１２０－１と第１コアコンピュートノード１４０－１との間に専用コネクション１８０－１－１が、第１ゲートウェイ１２０－１と第２コアコンピュートノード１４０－２との間に専用コネクション１８０－１－２が…というように設けられていくことにより、ゲートウェイ１２０－ｇと第ｃコアコンピュートノード１４０－ｃとの間にコネクション例１８０－ｇ－ｃが、そして、シーケンサ１５０と第ｃコアコンピュートノード１４０－ｃとの間にコネクション例１８０－ｓ－ｃが設けられる。

【0106】

一部の実施形態では、ポイントトゥポイントメッシュ１７２の専用コネクション１８０のそれぞれが、共有スイッチを利用しないポイントトゥポイント型のダイレクトコネクションになるという点を理解されたい。本明細書では、専用コネクション又はダイレクトコネクションのことをダイレクト「リンク」や専用「リンク」といった風に、互換可能に称する場合があるが、これは、２つのエンドポイント間での通信専用（例えば、非共有）のダイレクトコネクションのことである。このような専用／ダイレクトリンクは、後でさらに開示するような適切な相互接続部やインターフェースであれば、どのようなものであってもよく、有線イーサネットネットワーク接続やその他の種類の有線又は無線ネットワークリンクのようなネットワークリンクに限定されない。本明細書では、専用／ダイレクトコネクション／リンクが、２つのエンドポイント間のエンドトゥエンドパスと称される場合がある。このようなエンドトゥエンドパスは、単一のコネクション／リンクであってもよいし、一連のコネクション／リンクからなるものであってもよい。ただし、専用／ダイレクトコネクション／リンクの帯域幅は、その全体、つまり、１つのエンドポイントから別のエンドポイントにかけて非共有であり、専用／ダイレクトコネクション／リンクの帯域幅もレイテンシも、トラバース対象の１つ以上の要素のリソース利用の影響を受け得ないものとされる。例えば、専用／ダイレクトコネクション／リンクは、１つ以上のバッファや、利用によって帯域幅やレイテンシに影響が出ないその他の要素をトラバースしている場合がある。ただし、該専用／ダイレクトコネクション／リンクは、利用の共有によって帯域幅および／またはレイテンシに影響を及ぼし得る共有ネットワークスイッチをトラバース対象としない。

【0107】

例えば、一部の実施形態において、ポイントトゥポイントメッシュ１７２における専用コネクション１８０は、１０ギガビットイーサネット（ＧｉｇＥ）、２５ＧｉｇＥ、４０ＧｉｇＥ、１００ＧｉｇＥ、ＩｎｆｉｎｉＢａｎｄ、ＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ－Ｅｘｐｒｅｓｓ（ＰＣＩｅ）、ＲａｐｉｄＩＯ、スモールコンピュータシステムインターフェース（ＳＣＳＩ）、ＦｉｒｅＷｉｒｅ、ユニバーサルシリアルバス（ＵＳＢ）、高精細マルチメディアインターフェース（ＨＤＭＩ）、カスタムシリアル又はパラレルバスなどの数多くの方法で行われ得る。

【0108】

したがって、コンピュートエンジン１４０、ゲートウェイ１２０、シーケンサ１５０、およびその他のコンポーネントは、本明細書において「ノード」と称している場合があるものの、それ以外の種類の相互接続やインターフェースも可能であることから、「コンピュートノード」や「ゲートウェイノード」や「シーケンサノード」や「メッシュノード」といった用語を使っているからといって、特定のコンポーネントの接続がネットワークリンクを利用して行われる必要があるという意味に解釈されるべきでない。また、本明細書で開示する「ノード」とは、該ノードについて説明した各機能を実行するように構成された適切なハードウェア、ソフトウェア、ファームウェアコンポーネント、またはこれらの組合わせであれば、どのようなものあってもよい。詳細に後述するように、ノードは、プログラムされた汎用プロセッサであり得るが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、その他のハードウェアデバイスやデバイス群などといった専用のハードウェアデバイスであってもよいし、ハードウェアデバイス内、プリント回路基板（ＰＣＢ）内またはその他のハードウェアコンポーネント内の論理であってもよい。

【0109】

本明細書で開示するノード同士は、別々の要素であってもよいし、単一の要素内、例えば、本明細書で説明する該ノードの機能を実行するための論理を実装するように構成された単一のＦＰＧＡ、ＡＳＩＣまたはその他の要素内に一緒に集積されたものであってもよいという点を理解されたい。また、ノードは、汎用コンピュータ及び／又は前述した任意のデバイスにより実行される論理を実装したソフトウェアのインスタンス化であってもよい。

【0110】

コンピュートエンジン１４０、ゲートウェイ１２０、シーケンサ１５０などのコンポーネントを１つ以上の共有スイッチを介して接続するという従来のアプローチでは、レイテンシが最小限のものにならない。また、このような従来のアプローチでは、メッセージトラフィックの重い期間中に、レイテンシの予測不可能なスパイクも生じる。

【0111】

また、例示的な一実施形態において、専用コネクション１８０は、各ゲートウェイ１２０と各シーケンサ１５０との間、および各シーケンサ１５０と各コアコンピュートノード１４０との間に直接設けられている。また、一部の実施形態では、専用コネクション１８０が全シーケンサ間にも設けられており、これにより、シーケンサ例１５０－１はその他の各シーケンサ１５０－２，．．．，１５０－ｓとの間に専用コネクション１８０を有する。図１Ａには描かれていないが、一部の実施形態では、専用コネクション１８０が、全ゲートウェイ１２０間にも設けられ得て、これにより、各ゲートウェイ１２０－１はその他の各ゲートウェイ１２０－２，．．．，１２０－ｇとの間に専用コネクション１８０を有する。同様に、一部の実施形態では、専用コネクション１８０が全コンピュートノード１４０間にも設けられており、これにより、コアコンピュートノード例１４０－１はその他の各コアコンピュートノード１４０－２，．．．，１４０－ｃとの間に専用コネクション１８０を有する。

【0112】

また、一部の実施形態において、２つのノード間（例えば、任意の２つのノード１２０，１５０，１４０間）の専用コネクション１８０は、冗長性および信頼性を高めるため、同じ２つのノード間の複数の冗長的な専用コネクションとして実現されてもよいという点を理解されたい。例えば、ゲートウェイ１２０－１とコアコンピュートノード１４０－１（例えば、第１コア）との間の専用コネクション１８０－１－１は、一対の専用コネクションとして実際には実現され得る。

【0113】

また、一部の実施形態において、所与のノードによって送出される全メッセージは、ポイントトゥポイントメッシュ１７２内で該ノードに直接接続されている全ノードに並行して送出される。ポイントトゥポイントメッシュ１７２内の各ノードは、メッセージの受信時に何らかの処理を行うべきか否か、あるいは、そうではなく単に同メッセージを無視すべきか否かを、例えば該ノードの構成に基づいて自分自身で判断し得る。一部の実施形態において、ノードは、自身の構成がメッセージの受信時に実質何の処理も行わないような構成であったとしても、同メッセージを完全に無視し得るのではなく、シーケンサ１５０によって同メッセージに割り当てられた任意のシーケンス番号を利用する（consuming）などといった、少なくとも最小限の処理を行うものとされ得る。すなわち、このような実施形態において、該ノードは、受信した最新シーケンス番号を追跡するものとされ得る。これにより、もっと具体的な（substantial）処理を該ノードがメッセージに対して行う際に、同処理が適切なシーケンス順で行われることが確実となり得る。

【0114】

例えば、「マイクロソフト社株を１９０ドルで１０株売る」という取引注文を含むメッセージが、トレーダのパーソナルコンピュータといった参加者デバイス１３０－１から発信されてゲートウェイ１２０－１（すなわち、第１ＧＷ）に到着したとする。同メッセージは、たとえコアコンピュートノード１４０－２だけが現在マイクロソフト社の注文についてのマッチングを実行しているとしても、全コアコンピュートノード１４０－１，１４０－２，．．．，１４０－ｃに送信される。１４０－２以外の（other）全てのコアコンピュートノード１４０－１，１４０－３，．．．，１４０－ｃは、受信時に同メッセージを無視するか、あるいは、同メッセージに対して最小限の処理しか行わないものとされ得る。例えば、１４０－１，１４０－３，．．．，１４０－ｃが行う唯一の処理は、シーケンサ１５０－１によって同メッセージに割り当てられたシーケンス番号を利用する（consume）ことであり得る。さらに、同メッセージは、メッシュに従事する現行アクティブなシーケンサが一つ（本例では、シーケンサ１５０－１）だけであったとしても、全てのシーケンサ１５０－１，１５０－２，．．．，１５０－ｓに送信される。１５０－１以外の（other）シーケンサ１５０－２，．．．，１５０－ｓも同メッセージを受信するという構成により、シーケンサ１５０－１（現行アクティブなシーケンサ）が故障した場合や、別のアクティブなシーケンサに換えたほうが電子取引システム１００の総合的な信頼性が向上するような場合に、該シーケンサ１５０－２，．．．，１５０－ｓが現行アクティブなシーケンサを引き継ぐという機会が得られる。また、１５０－１以外の（other）１つ以上のシーケンサ（例えば、シーケンサ１５０－２）は、システム状態の災害復旧サイト１５５への継承を担うものであり得る。災害復旧サイト１５５は、電子取引システム１００の個々のコンポーネントの一部又は全ての物理的又は仮想的なインスタンス化を含んだ該電子取引システム１００のレプリカを別の物理的な場所に備えたものであり得る。

【0115】

各メッセージを直接接続された全ノードに並行して送出するという構成により、システム１００は、複雑性を抑えると共に冗長性と高可用性を促す。直接接続された全ノードが初期設定で全メッセージを受信するようになっている場合、複数のノード同士が、同じメッセージを冗長的に処理するように構成され得る。Ｍｉｃｒｏｓｏｆｔ社株を１９０ドルで１０株売る」という前述の注文例に戻ると、一部の実施形態では、複数のコアコンピュートノード１４０が、Ｍｉｃｒｏｓｏｆｔ社の注文についてのマッチングを同時に実行することになり得る。例えば、コアコンピュートノード１４０－１とコアコンピュートノード１４０－２の両方が、Ｍｉｃｒｏｓｏｆｔ社のメッセージについてのマッチングを同時に行い得るほか、前記「売り」注文の上りメッセージを受信した後、それぞれ独立して受付確認メッセージ、約定メッセージなどの応答メッセージを生成し、コアコンピュートノード１４０－１とコアコンピュートノード１４０－２の各々がそれを１つ以上のシーケンサ１５０を介してゲートウェイ１２０へと送信し、１つ又は複数の参加者デバイス１３０へと受け渡させ得る。

【0116】

１つ以上のシーケンサ１５０により厳密な順序付けおよび状態確定性が確保されていることから、コアコンピュートノード１４０－１，１４０－２によってそれぞれ独立して生成・送信される対応するどの応答メッセージも、実体的かつ機能的に確実に等価なものとなることができる。このように、電子取引システム１００のアーキテクチャは、メッセージの冗長処理を簡単にサポートして該システムの可用性とレジリエンスを高める。このような実施形態において、ゲートウェイ１２０は、コアコンピュートノード１４０から、対応する同じ上りメッセージについての複数の対応する下りメッセージを受信し得る。これら複数の対応する応答メッセージ同士は、確実に等価なものとなることができるため、ゲートウェイ１２０は、同じ上りメッセージに対応する下りメッセージのうちの最初に受信したものだけを単純に処理し、後続のものについては無視し得る。一部の実施形態において、「最初」と「後続」のメッセージは、シーケンスマーク付きのメッセージの可能性があり、対応付けられたシーケンス番号によって識別が行われ得る。しかし、シーケンサ１５０が複数の機能的に等価なメッセージ同士で一つのシーケンス識別子しか割り当てないような他の実施形態では、図１Ｃとの関連で詳しく先述したように、エンティティタイプフィールド１１０－１６の値やエンティティカウントフィールド１１０－１７の値などのメッセージ内の別の識別情報に基づいて、メッセージ同士が機能的に等価なものであることが識別され得る。

【0117】

また、これにより、複数の機能的に等価な対応するメッセージのうちの最初にゲートウェイ１２０に到着したメッセージにのみ該ゲートウェイ１２０が処理を行うことが可能となるので、電子取引システム１００の全体的なレイテンシが改善し得る。また、任意の上りメッセージに対して複数のコンピュートノード１４０が処理を行って、該複数のコンピュートノード１４０のそれぞれが等価な応答メッセージを生成し、最初に到着した応答メッセージがゲートウェイ１２０によって処理され得るように電子取引システム１００を構成するということも簡単に行われる。このようなアーキテクチャであれば、あるコンピュートノード１４０が（システム障害、ノードの再構成、保守作業のいずれの原因にしろ）上りメッセージに一定期間対処しなかった場合でも、認識できる程度の影響がレイテンシに生じるようなことにならず、高可用性がもたらされる。

【0118】

システム１００のこのようなポイントトゥポイントメッシュ１７２アーキテクチャは、メッセージの予測可能な低レイテンシと冗長処理をサポートすることに加えて、複数の冗長パスがそれ自体に組み込まれている。一目瞭然であるが、任意のゲートウェイ１２０と任意のコンピュートノード１４０との間には、複数の経路が存在している。たとえゲートウェイ１２０－１とコンピュートノード１４０－１との間のダイレクトコネクション１８０－１－１が利用できなくなったとしても、代わりにシーケンサ１５０のうちの一つをトラバースするなどといった別の経路により、それら２つの要素間でのやり取りが引き続き可能となる。つまり、より一般的に言うならば、ポイントトゥポイントメッシュ１７２内の任意のノードと任意のその他のノードとの間に複数の経路が存在している。

【0119】

さらに、このポイントトポイントメッシュ型のアーキテクチャは、その性質上（inherently）、金融取引システムの別の重要な目標、すなわち、公平性についてもサポートしている。ノード同士のダイレクトコネクションを備えたポイントトゥポイント型の同アーキテクチャにより、任意のゲートウェイ１２０と任意のコアコンピュートノード１４０との間の経路のレイテンシやシーケンサ１５０と任意のその他のノードとの間の経路のレイテンシが、どれも確実に同一または少なくとも極めて類似したものになる。これにより、２つの異なるゲートウェイ１２０から同時にシーケンサ１５０へと送出された２つの上りメッセージが、実質同時に該シーケンサ１５０に到達するはずである。同様に、コアコンピュートノード１４０から送出される下りメッセージは全ゲートウェイ１２０へと同時に送られ、実質同時に各ゲートウェイで受信されるはずである。ポイントトゥポイントメッシュ型のトポロジーは、どれか一つのゲートウェイ１２０だけを有利に扱う（favor）ことがないので、特定のゲートウェイ１２０に接続された参加者デバイス１３０が不当に有利又は不利な立場になるという可能性が最小限になる。

【0120】

また、システム１００のポイントトゥポイントメッシュ型のアーキテクチャによれば、ノードの機能、すなわち、ノードを現在ゲートウェイ１２０として機能させるのか、コアコンピュートノード１４０として機能させるのか、それとも、シーケンサ１５０として機能させるのかを容易に再構成することが可能になる。ポイントトゥポイントメッシュ内の各ノードとそれ以外の各ノードとの間がダイレクトコネクションである実施形態では、そのような再構成の実行が極めて簡単になる。ポイントトゥポイントメッシュ１７２内で各ノードがその他の各ノードとダイレクトコネクションによって接続されている場合、同メッシュ内のノードの機能を変更する（例えば、ノードの機能をコアコンピュートノード１４０からゲートウェイ１２０に、あるいは、ゲートウェイ１２０からシーケンサ１５０に変更等する）のに、配線やケーブルで同メッシュ内の（物理的、仮想的なものを問わず）コネクション１８０の再接続を行う必要がない。このような実施形態では、ポイントトゥポイントメッシュ１７２内部で必要な再構成が、遠隔的に実施するコンフィギュレーション変更によって容易に達成され得る。ノードが新たにゲートウェイ１２０として機能するように再構成されたりゲートウェイ１２０としての機能から別の機能へと再構成されたりする場合には、ポイントトゥポイントメッシュ１７２外部である程度の補助的なネットワーク変更が必要となる場合があるが、同メッシュの内部配線は何もせずにそのまま維持され得る。

【0121】

そのため、一部の実施形態では、ノードの機能の再構成が、取引時間中に実時間で（live）、さらには、動的に達成され得る。例えば、電子取引システム１００の負荷の特性の変化や新たな需要により、コアコンピュートノード１４０－１のうちの一つを再構成によって追加のゲートウェイ１２０として代わりに機能させたほうが役立つ場合がある。別のコンピュートノード１４０への状態又は構成（設定）の何らかの再配分後、この新たなゲートウェイ１２０は、参加者デバイス１３０からの新たなコネクションの受付け開始が可能な状態となり得る。

【0122】

一部の実施形態では、ゲートウェイ１２０間および／またはコアコンピュートノード１４０間を含むシステムコンポーネント間に、より低速で潜在的に高レイテンシの共有コネクション１８２が設けられ得る。これらの共有コネクション１８２は、保守、制御操作、管理操作、かつ／あるいは、ポイントトゥポイントメッシュ１７２内の専用コネクション１８０を介して運ばれる取引活動関連のメッセージのようにまたは該メッセージとは対照的に超低レイテンシの通信を必要としないその他諸々の（similar）操作に利用され得る。取引活動に関するトラフィックを運ぶ第１ダイレクトコネクション１８０－１－１、第２ダイレクトコネクション１８０－ｇｗ１－ｓ１、及び第３ダイレクトコネクション１８０－ｃ１－ｓ１とは対照的に、共有コネクション１８２－ｇ，１８２－ｃは、取引活動以外の種類のトラフィックを運ぶ。取引活動以外のトラフィックを運ぶ共有コネクション１８２は、１つ以上の共有ネットワークおよび１つ以上のネットワークスイッチを介したものであり得て、これら共有ネットワーク間では、前記メッシュ内のノードが様々な分布様式を呈し得る。例えば、一部の実施形態では、全ゲートウェイ１２０がゲートウェイ間（gateway-wide）共有ネットワーク１８２－ｇ内にあり得て、コンピュートノード１４０同士がそれら自身のコンピュートノード間（computer node-wide）共有ネットワーク１８２－ｃ内にあり得て、シーケンサ１５０同士がそれら自身の別のシーケンサ間（sequencer-wide）共有ネットワーク１８２－ｓ内にあり得る。一方で、他の実施形態では、レイテンシの影響を受け難い上記のような（these）操作処理（operation）の場合、前記メッシュ内の全てのノードが同じ共有ネットワーク上で通信を行い得る。

【0123】

電子取引システム１００のような分散型コンピューティング環境は、各コンポーネント同士の厳密な同期を維持するため、高分解能クロックを利用する（rely on）場合がある。この目的のために、一部の実施形態において、１つ以上のノード１２０，１４０，１５０には、高分解能グローバルポジショニング（ＧＰＳ）クロック１９５などのクロックへのアクセスが設けられ得る。

【0124】

図１Ａを参照するが、以降の説明上の目的から、メッシュ１７２内で接続されたゲートウェイ１２０、コンピュートノード１４０およびシーケンサ１５０のことを「メッシュノード」と称する場合がある。図２に、電子取引システム１００のポイントトゥポイントメッシュ１７２型アーキテクチャにおけるメッシュノード２００の例示的な一実施形態を示す。メッシュノード２００とは、例えばゲートウェイ１２０、シーケンサ１５０、コアコンピュートノード１４０等のことを表し得る。本例ではメッシュノード２００の機能がハードウェアとソフトウェアの両方に分散したものとなっているものの、該メッシュノード２００は、純粋なハードウェア実装や純粋なソフトウェア実装を含め、ハードウェアとソフトウェアとのあらゆる適切な組合せで実現されてよく、一部の実施形態では、ゲートウェイ１２０及び／又はコンピュートノード１４０及び／又はシーケンサ１５０のいずれか又は全てが、商用オフザシェルフのコンポーネントで実現され得る。

【0125】

図２により示される実施形態では、低レイテンシを達成するため、一部の機能が固定論理デバイス（Fixed Logic Device）２３０のハードウェアで実現されると共に、他の機能はデバイスドライバ２２０及びメッシュソフトウェアアプリケーション２１０のソフトウェアで実現されている。固定論理デバイス２３０は、特定用途向け集積回路（ＡＳＩＣ）や組み込みプロセッサやフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、任意の適切な様式で実現されたものであり得る。メッシュソフトウェアアプリケーション２１０およびデバイスドライバ２２０は、中央演算処理装置（ＣＰＵ）などの１つ以上のプログラマブルデータプロセッサ上で実行される命令として実現され得る。メッシュノード２００には、その役割に応じて、メッシュソフトウェアアプリケーション２１０の異なるバージョン又は構成のものがインストールされ得る。例えば、メッシュノード２００がゲートウェイ１２０として機能するのか、シーケンサ１５０として機能するのか、それとも、コアコンピュートノード１４０として機能するのかに基づいて、メッシュソフトウェアアプリケーション２１０の異なるバージョン又は構成のものがインストールされ得る。

【0126】

（ファイバや銅ケーブルによるＵＳＢ、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）－Ｅｘｐｒｅｓｓ、高精細マルチメディアインターフェース（ＨＤＭＩ）、１０ギガビットイーサネット（ＧｉｇＥ）、２５ＧｉｇＥ、４０ＧｉｇＥ、１００ＧｉｇＥ、又はＩｎｆｉｎｉＢａｎｄ（ＩＢ）を含む）適切なあらゆる物理通信リンク層が採用されてもよいが、本例のメッシュノード２００は、複数の低レイテンシ１０ギガビットイーサネットＳＦＰ＋コネクタ（インターフェース）２７０－１，２７０－２，２７０－３，・・・，２７０－ｎ（これらをまとめたものは、コネクタ２７０として知られる）を具備したものとされる。コネクタ２７０は、例えば、前記ポイントトゥポイントメッシュ内の別のノードに対し、専用コネクション１８０で直接接続され得て、かつ／あるいは、共有コネクション１８２を介して接続され得て、かつ／あるいは、ゲートウェイ１２０を介して参加者デバイス１３０に接続され得る。本例では、これらのコネクタ２７０が、１０ＧｉｇＥＭＡＣコア２６０－１，２６０－２，２６０－３，．．．，２６０－ｎ（これらをまとめたものは、ＧｉｇＥコア２６０として知られる）にそれぞれ電子的に結合されている。この実施形態において、１０ＧｉｇＥＭＡＣコア２６０は、レイテンシが確実に最小限になるように固定論理デバイス２３０により実現されたものである。他の実施形態では、１０ＧｉｇＥＭＡＣコア２６０が、固定論理デバイス２３０外部の機能、例えば、ＰＣＩ－Ｅネットワークインターフェースカードアダプタの機能により実現されたものであり得る。

【0127】

一部の実施形態では、固定論理デバイス２３０が、それ以外の構成要素も含み得る。図２の例の固定論理デバイス２３０は、さらに、固定論理２４０コンポーネントを含む。一部の実施形態において、固定論理コンポーネント２４０は、メッシュノード２００の役割に応じて、例えば、該メッシュノード２００がゲートウェイ１２０であるのか、シーケンサ１５０であるのか、それとも、コアコンピュートノード１４０であるのかに応じて、異なる機能を実現し得る。固定論理デバイス２３０には、その他にも、固定論理２４０によって最小限のレイテンシでアクセスされるメモリであり得る固定論理メモリ２５０が含まれる。固定論理デバイス２３０は、さらに、ＰＣＩＥｘｐｒｅｓｓ機能を実現し得るＰＣＩ－Ｅコア２３５を含む。本例では、ＰＣＩ Ｅｘｐｒｅｓｓが、ハードウェアとソフトウェアとの間、具体的には、固定論理デバイス２４０とメッシュソフトウェアアプリケーション２１０との間で、デバイスドライバ２２０によってＰＣＩＥｘｐｒｅｓｓバス２３３を介してデータを転送するための導通機構として用いられる。しかしながら、ダイレクトメモリアクセス（ＤＭＡ）や共有メモリバッファやメモリマッピングを含め、ハードウェアとソフトウェアとの間のあらゆる適切なデータ転送機構が用いられてよい。

【0128】

一部の実施形態では、メッシュノード２００が、それ以外のハードウェアコンポーネントも含み得る。例えば、一部の実施形態において、メッシュノード２００は、電子取引システム１００におけるその役割に応じて、該電子取引システム１００内のノード間の高分解能クロック同期実施に用いられる高分解能クロック１９５（図１Ａに図示；図１Ａとの関連で説明済み）も含み得る。また、メッシュノード２００内には、固定論理メモリ２５０と連動する追加メモリとして、動的ランダムアクセスメモリ（ＤＲＡＭ）２８０も含まれ得る。ＤＲＡＭ２８０は、１つ以上のランダムアクセスメモリバンクや１つ以上のハードディスクや１つ以上のソリッドステートディスクを含め、あらゆる適切な揮発性又は不揮発性メモリであってもよく、任意の適切なメモリインターフェース又はストレージインターフェースを介してアクセスされ得る。

【0129】

（受入時のサービス品質シェーパ）

【0130】

前述したように、システム１００のアーキテクチャは、その性質上（inherently）、分散型処理システムの別の重要な目標、すなわち、上りメッセージが同システムによって受信されることが可能な１種以上のレートの制御をサポートしている。

【0131】

また、クライアント毎にインバウンドメッセージレートを制限し、コンピューティングリソースの公平なプロビジョニングを確実に支援することにより、あるクライアントによるリソースの過剰利用によって同システムが圧倒されず、その他のクライアントが同システムとの間で相互にやり取りを行うことができないようになるのを阻止する。

【0132】

可能ならば、前記制御は、インバウンドメッセージの持続レートとバーストレートの両方に対するものであるのが望ましい。

【0133】

また、クライアント毎にメッセージ受入レートを制御することに加えて、全てのクライアントコネクションを通じた総合的な受入レートをシステム全体で制御することも望ましくあり得る。このようなシステム全体の制御により、前記分散型システム全体として、期待される（predictable）レイテンシレベルを同システムの全てのクライアントに対して提供することを含め、必要なサービスレベルを確実に維持することができる。

【0134】

より具体的に述べると、図３は、図１Ａ及び図２の電子取引システム１００との関連で説明したゲートウェイノード１２０の一例の、フロー制御部３００についての詳細図である。おさらいすると、上りメッセージは、（１つ以上の参加者デバイス１３０などの）クライアントとゲートウェイノード１２０との間に確立されたコネクションによって受入方向で分散型システム１００へと入ってくる。

【0135】

フロー制御３００は、コネクション毎のキュー３１０、コネクション毎のＱｏＳシェーパ３２０、ラウンドロビンアービタ３３０、およびＱｏＳパラメータストア３４０を含む。一部の実施形態において、本明細書で説明するメッセージは、典型的に、電子取引システムにおいて取引を行うための要求などといったアプリケーションレベルメッセージである。よって、複数のアプリケーションメッセージは、ＴＣＰパケットなどの単一のインバウンドデータ構造内に含められ得る。後で詳しく説明するが、トラフィックレートシェーピングはメッセージレベルで行われるが、フロー制御については、（例えば、コネクション毎のＴＣＰのウィンドウサイズを制御すること等による）コネクション毎のレベルなどといった、別の何らかのレベルで実施される。

【0136】

コネクション毎のキュー３１０は、対応するコネクション１３１－１，１３１－２，．．．，１３１－ｎにＦＩＦＯ３１２が関連付けられてなる、一連のＦＩＦＯキュー３１２－１，３１２－２，．．．，３１２－ｎを有し得る。コネクション毎のキュー３１０は、前記分散型システムのそれ以外の部分で処理（serviced）される前の、到着したばかりの上りメッセージを保持しておくという役割を担う。システム１００のそれ以外の部分で処理されるようにコネクション毎のキュー３１０からデキューイングされたメッセージは、ＱＯＳシェーパ３２０に進入する。

【0137】

ＱｏＳシェーパ３２０は、各クライアントコネクション１３１に一つのトークンバケット３２２が関連付けられてなる、対応する一連のトークンバケット３２２－１，３２２－２，．．．，３２２－ｎを提供する。所定のコネクション１３０１に対するトークンバケット３２２は、そのコネクション１３１に構成された持続フローレート及びバーストフローレートを強制するものである。例えば、トークンバケット３２２は、参加者（クライアント）１３０が長らくメッセージを送信していない場合、メッセージがそのまま通過することを許可する。しかし、トークンバケット３２２は、クライアントがあまりにも短時間でメッセージを送信した場合、下記のようにしてクライアントコネクション１３１の減衰を行う。

【0138】

すなわち、クライアントコネクション１３１－１から受信されたメッセージは、ＦＩＦＯ３１２－１に出力された後、トークンバケット３２２－１へと出力される。クライアントコネクション１３１－２から受信されたメッセージは、ＦＩＦＯ３１２－２に出力された後、トークンバケット３２２－２へと出力される。コネクション１３１－ｎからのメッセージは、ＦＩＦＯ３１２－ｎに出力された後、トークンバケット３２２－ｎへと出力される。後で詳しく説明するが、トークンバケット３２２－１，３２２－２，３２２－ｎからのメッセージはラウンドロビンアービタ３３０に集約される。

【0139】

トークンは、ある（single）メッセージがトークンバケット３２２を通過することを許可する「チケット」として機能するものであると考えられ得る。バケット内に１つ以上のトークンがあれば、メッセージは同バケットのトークンを一つ消費して通過し得る。メッセージがトークンバケット３２２を通過するとき、該メッセージによって消費されたトークンは同バケットから取り除かれる。

【0140】

以上から、バーストレートは、トークンバケット３２２が保持することのできるトークンの数によって決まる。持続レートは、トークンがトークンバケットに追加され得る際のレートのことであり、さらに、（バケットをそのまま通過するメッセージが同バケットから「排出」されていると見なした場合の）バケットの最大可能持続「排出」レートにも相当する。

【0141】

本実施形態では、トークンバケット３２２の出力側端にラウンドロビンアービタ３３０があるため、メッセージがトークンバケットを「そのまま通過する」とは、同メッセージがアービタ３３０によって直ちに引き出されることができるということを意味する。言い換えれば、ラウンドロビンアービタ３３０は、コネクション毎の各トークンバケット３２２を見回り（cycle through）続けることで、そのまま通過することのできる（ready to）メッセージが有るのか否かを各トークンバケット３２２ごとに確認しているのである。

【0142】

トークンバケット３２２は、コア１４０で表されるリソースをある一つのコネクション１３１や一連のコネクションが過度に消費しないようにすることで、公平性の確保を支援する。しかし、トークンバケット３２２は、「『良い振る舞い』への報酬」も行うものであり、つまり、クライアント１３０の送信レートがそれに割り当てられたトークンバケット３２２の持続フローレートに一致すれば、同クライアント１３０のメッセージはレイテンシの影響を全く又はほぼ受けずにそのまま通過するはずであることを意味する。

【0143】

したがって、トークンバケット３２２は、次のようにして管理され得る：
ａ）トークンは、数マイクロ秒から１秒の範囲内でのプログラム指定レートによって各バケットに追加される；
ｂ）各間隔ごとに追加されるトークンの数は、例えばプログラム指定等で制御され得る；
ｃ）また、各バケット内のトークンの数の上限もプログラム可能である。
なお、ａ）とｂ）を合わせたものは所望の持続レートに対応し、ｃ）はバーストレートに対応する。

【0144】

総合的な影響としては、
ａ）クライアント毎の期間毎の注文数の上限が、個別に指定され得る；
ｂ）また、注文のバーストレートの上限も、クライアント毎に指定可能となり得る；
ｃ）また、注文の総合的なレートも、クライアント毎に指定可能となり得る；
ｄ）また、システム全体としての注文のレートも、指定可能となり得る。

【0145】

１つ以上のコネクション１３１からやってくるメッセージのフローを遅くする必要に迫られた状況に対処するため手法の候補（possible）の一つとして、これらのパラメータ３４０のうちの１つ以上の調整が行われ得る。具体的に述べると、所与のコネクションに対して著しいバックプレッシャーが検出された場合（例えば、所定のコネクション１３１のＦＩＦＯキュー３２２がある点を超えて充填されている場合等）に、対応するクライアント１３０に対してメッセージの送信レートを遅らせるようにゲートウェイ１２０が通知するというフィードバックの仕組みが用いられ得る。

【0146】

後で図７及び図８を使って詳しく説明するが、一実装例において、クライアントコネクション１３１がＴＣＰで確立されているとして、ゲートウェイ１２０は、同コネクションのＴＣＰの公称（advertised）受信ウィンドウサイズを減少させ得る。ただし、ＴＣＰのウィンドウサイズを明示的に減少させるという構成は、メッセージが受信されるレートを制御するための手法の一つに過ぎない。コネクション１３１の速度を遅らせる（slow down）必要があるときに持続レート及びバーストレートを制御する別の手法としては、トークンバケットパラメータ３４０自体を明示的に調整して同コネクション１３１のバーストレート及び／又は持続レートを指定するというものが挙げられる。バーストレートおよび／または持続レートを下げると、ＴＣＰプロトコル自体の仕組みの影響（artifact）の一つとして、結局は、ＴＣＰのウィンドウサイズが減少することになり得る（例えば、アプリケーションが十分高速なレートでパケットを処理していないことをＴＣＰが検出した場合等にそうなる。いずれのアプローチを利用することも、あるいは、両方のアプローチの組合せを利用することも可能であり得る）。

【0147】

一部の実施形態では、ＴＣＰのウィンドウサイズを調節するよりも、ＱｏＳトークンバケットパラメータ３４０を調整したほうが有利となる場合がある。トークンバケットパラメータを（ＴＣＰのウィンドウサイズと同じく）バイト単位による上限指定ではなくメッセージ単位などで指定することにより、システム１００は「プロトコル非依存（agnostic）」なものとなる。つまり、システム１００がトークンバケットパラメータを直接調節することで、使用するメッセージサイズが他のプロトコルよりも大きく又は小さくなりがちなプロトコルのほうが有利になるようなことがなくなる（not favor）。例えば、ＦＩＸメッセージは、バイナリプロトコルで符号化されたメッセージよりも大型になりがちであり得るが、メッセージ毎に受入フローレートを制御すれば、ＦＩＸコネクション１３１でメッセージを送るクライアント１３０は、全体的なメッセージサイズが大型化するプロトコルの選択によるペナルティを受けるようなことがなくなる。共通のプロトコルの共通のメッセージタイプ同士の中でも、クライアント１３０が任意のタグやパラメータを利用することで、メッセージサイズが変化する可能性があり得る。例えば、ＦＩＸでは、クライアント１３０が任意のタグに追加の情報を含めることで、送信するＦＩＸメッセージが大型化する可能性があり、メッセージに含める情報を増やしたからといって、フロー制御に関してそのようなクライアントがペナルティを受けるようなことは望ましくない場合があり得る。

【0148】

一部の実装では、（それ自体も１つ以上の内部ＦＩＦＯキューを有するものとされ得る）ラウンドロビンアービタ３３０が、ＱＯＳシェーパ３２０の下流側に配置される。アービタ３３０は、一連のトークンバケット３２２－１，３２２－２，．．．，３２２－ｎの出力をラウンドロビン方式で見回って、トークンバケットからメッセージを引き出した後、１つ以上のコア１４０などといった前記分散型システムの残りの部分によって処理されるように同メッセージを転送する。

【0149】

なお、図１の実装例に従い、メッセージは、ゲートウェイにてシーケンサ１５０へも送信され得る。他の実施形態では、ゲートウェイ１２０がメッセージをシーケンサ１５０にのみ送信し得て、この場合、シーケンサ１５０が同メッセージを１つ以上のコア１４０に転送し得る。

【0150】

ＱＯＳパラメータ設定３４０は、コネクション毎のキュー３１０およびＱＯＳシェーパ３２０の動作（behavior）を制御するための入力を行うものである。これらのパラメータ設定３４０は、対応するコネクションのＦＩＦＯ３１２の深さの上限、および／または、それに対応するトークンバケット３２２のサイズを指定し得る。ＱＯＳパラメータ設定３４０は、システム全体につき且つ／或いはゲートウェイ毎に且つ／或いはクライアント毎に且つ／或いはコネクション毎に指定され得るものであったとしても、その適用はコネクション毎に行われ得る。既に説明したが、これらのＱｏＳパラメータは、バーストレート及び持続レートを制御する。

【0151】

詳細に述べると、一部の実施形態において、ＱＯＳシェーパ３２０の持続レートおよびバーストレートは、クライアント毎またはコネクション毎に構成されてもよく、これにより、前記分散型システムのプロバイダは、所与のクライアントコネクション１３１について構成されたインバウンドレートに応じて、別々のクライアントに様々な金額を請求することが可能となる。

【0152】

通常、金融マッチングエンジンへの受入メッセージレートの上限を上げたいと考えたクライアントは、ノード１４０が提供する１つ以上のマッチングエンジンへのアクセスを増やすのに、システム１００にさらなるコネクション１３１を追加する必要がある。このようなコネクションの多数化は、構成に時間がかかる（１日以上になる場合がある）だけでなく、人手による介入や各データセンターサービスプロバイダ間での調整が必要となる場合がしばしばあるので、ヒューマンエラーも起こりがちである。これに対し、コネクションの生成を増やす必要なくマッチングエンジンへの単一のコネクション上でインバウンドメッセージレートの上限をその取引日内で動的に調整することがクライアントにとって可能となるので、クライアントに対して追加の融通性を提供する共に、誤構成のリスクが最小限に抑えられる。

【0153】

とはいっても、各クライアント１３０が複数のコネクション１３１を場合によっては利用してもよいし、任意のコネクション１３１が複数のクライアント１３０に従事していてもよいという点を理解されたい。よって、一部の実施形態では、「コネクション毎」のキュー３１０および「コネクション毎のＱＯＳシェーパ」３２０が、これに代えて「クライアント毎」のキューや「クライアント毎」のシェーパとなり得る。

【0154】

図４に、システム１００の好ましい他の実装態様を示す。ここでは、各ゲートウェイ１２０－１，１２０－２，．．．，１２０－ｎがコネクション毎のそれ自身のフロー制御３００－１，３００－２，．．．，３００－ｎを有すると共に、１つ以上のシーケンサ１５０内にグローバルフロー制御５００が存在したものとされ得る。グローバルフロー制御５００は、ゲートウェイ１２０に対するフィードバックを使って、システム全体としての別のＱｏＳレイヤを提供する。これにより、システム１００が必要に応じてゲートウェイの速度を下げることもできるようになり、同システム全体としての動作を、要求されるサービスレベル内に常に確実に収めるように支援することが可能となる。シーケンサ１５０と、それに対応するグローバルフロー制御５００と、および１つ以上のコア１４０とのことを、本明細書では分散型システムコア４２０と呼称する。

【0155】

一部の実装において、メッセージは、ゲートウェイノード１２０から分散型システムコア４００に進入すると、まず最初に必ず一つのノード（例えば、シーケンサ１５０等）を通過する。このようにシステム全体の視点が提示されることで、シーケンサ１５０は、メッセージが全ゲートウェイ１２０－１，１２０－２，．．．，１２０－ｎ（つまり、全コネクション）を介して分散型システムコア４２０に入ってくる全体的なレートを、必要に応じて制限することが可能となる。つまり、（グローバルＱｏＳパラメータ５４０で操作される）グローバルフロー制御５００により、システム１００全体としての総合的な上り方向メッセージレートが制御され得る。

【0156】

グローバル制御ＱｏＳパラメータ５４０には、システム１００が経験しているその時点のまたは現在のまたは最新の（current）状況に応じて、一時的な調節や動的な調整が行われてもよいという点を理解されたい。例えば、突然の高負荷期間、壊滅的事象、システム障害等においては、それに応じてグローバルパラメータ５４０の調節が行われ得る。

【0157】

図５は、グローバルフロー制御５００の一例の詳細図である。グローバルフロー制御５００は、ゲートウェイ毎の一連のＦＩＦＯ５１２－１，５１２－２，．．．，５１２－ｎを有するメッセージキュー５１０、ゲートウェイ毎の一連のトークンバケット５２２－１，５２２－２，．．．，５２２－ｎを有するグローバルＱｏＳシェーパ５２０、グローバルアービタ５３０、およびグローバルＱＯＳパラメータ５４０を含み得る。これらの構成要素は、ゲートウェイフロー制御部３００についての対応する構成要素と同様の機能を有するが、ゲートウェイ１２０とコア１４０との間のフローを制御するように動作する点が異なる。

【0158】

一部の実施形態では、グローバルフロー５００で行われるレート制限が、単にＦＩＦＯキュー５１２単独の形態のものであり得るのに対し、他の実施形態では、グローバルフローが、トークンバケット５２２を用いて上り方向レートのシェーピングを行うものとされてもよい。

【0159】

グローバルフロー制御５００は、状況によって、本システムにさらなる利点を奏するものとなる。例えば、システム１００を利用する全てのクライアントが自身に割り当てられたメッセージングレート近辺で各個のトークンバケットを超え得ないように動作している傾向にあったとしても、レートの総合計がシステムの処理できる程度を上回ってしまう可能性がある。

【0160】

前述したように、システム１００に入ってくるメッセージは、全てシーケンサに転送されることが想定されているので、グローバルキュー５１０に到着する。この時点で持続レートおよび／またはバーストレートを制御することから、グローバルフロー制御は、全てのインバウンドシステムメッセージ動作（messaging）が制御されることになる単一の「チョークポイント」となる。

【0161】

グローバルフロー制御５００は、自身が過負荷になった場合にゲートウェイとの間でのフロー制御を調節するためのフィードバック経路を有する。システム１００は通常、予想されるピーク数の上りメッセージに対処できる（handle）ように設計されているはずなので、このような事態は通常、起こることがないと考えられている。別の言い方をすると、システム１００の設計者にとって、コアに要求されるプロビジョニングの上限を決定することは、クライアント同士の上り方向メッセージレートの上限を踏まえれば可能である。

【0162】

また、任意のゲートウェイが（輻輳などによって）バックプレッシャーを経験し始めるという徴候が出ると、グローバルフロー制御５００は、過負荷を経験しているゲートウェイだけでなく全てのゲートウェイの速度を低下させることを決定し得る。これは、過負荷のゲートウェイのみを減速させるのとは違って、より公平な結果をもたらし得る。

【0163】

このアプローチに対する見方を変えれば、受入（ingress）トラフィックが受け入れられる際の（allowed）レートは、その性質上（inherently）、逆方向の正味の送出（egress）トラフィック（例えば、コア１４０からクライアント１３０へと流れる応答メッセージ等）にも影響を及ぼす（controls）。これは、受入メッセージが典型的にそれに対応した送出メッセージを生成する取引システムなどのシステムの場面において起こり得ることである。すなわち、取引注文がシステム１００に受け入れられる（allowed to enter）レートを制御することで、当然（inherent）、同注文の処分を表すメッセージをシステム１００が生成する際のレートも制御される。

【0164】

また、コネクション毎とシステム全体の双方でＱＯＳを制御するという構成は、電子取引システムにおけるアクセスの公平性の面でも有益である。このような制御がないシステムでは、ゲートウェイ１２０－１を他の３つの「ヘビートレーダ」と一緒に利用しているクライアント１３０－１は、第２ゲートウェイ１２０－２に接続されている単独のクライアントである別のクライアント１３０－２と同程度のアクセスを与えられない可能性がある。代わりに、コネクションとゲートウェイの双方に対してラウンドロビン方式でサービスを提供するという構成により、各クライアントに公平な割合のアクセスを与えられると共に、あるクライアントが他のクライアントによって「押し出される」ようなことがなくなる。

【0165】

ゲートウェイ１２０へのプロビジョニングが行われる際には、ある任意のゲートウェイによってシステム１００のメッセージ処理能力がオーバーロードされるようなことになり得ないように、該ゲートウェイ１２０の持続レート及びバーストレートの上限が構成され得る。これは、ＱｏＳパラメータ３４０を適切に設定することにより、かつ／あるいは、個々のコネクションがメッセージを送信することのできる速度を制限することによって達成され得る。

【0166】

また、一部の実施形態において、取引システム１００がコア１４０一式の能力のオーバープロビジョニングを行うことで、全クライアント及び全ゲートウェイからのインバウンド取引メッセージの最大数よりも遥かに多くのメッセージが、該コア１４０一式の協働によって常に確実に処理され易くなるようにし得るのが好ましい。これは、アクセスの公平性確保の支援にもなる。

【0167】

一部の実施形態では、シーケンサ１５０での（例えば、グローバルフロー制御５００等による）メッセージレートの制限が、単にＦＩＦＯキュー５３５によって行われる。このような場面において、ゲートウェイ１２０は、シーケンサ１５０のグローバルキュー５１０が一杯になった際に、グローバルレベルでのバックプレッシャー（例えば、輻輳等）を暗示的に検出するものとされ得る。この場面では、ゲートウェイ１２０が、自身のＱＯＳシェーパ３２０をそれに応じて調節することで、分散型システムコア４２０へのメッセージの上り方向フローに対するさらなる制限を、恐らく一時的なものではあるが行い得る。

【0168】

グローバルフロー５００がＦＩＦＯ５１０のみを使用しＱｏＳシェーパ５２０も使用しない別の実施形態では、ＦＩＦＯ５１０の満杯に近い状態が検出されると、グローバルフロー５００からゲートウェイ１２０へとインターフェース１８２などで要求メッセージが送り返されることで速度低下が行われ得る。具体的に述べると、そのようなメッセージは、送信側が一時的にメッセージを受信できないということ又は送信側のキューが間もなく使い果たされるということを知らせるものであり得る。

【0169】

一般的に、システム１００は、受信側が後どれほどのデータ（例えば、取引メッセージ単位、あるいは、バイトやその他の尺度等）を受信することができるのかを示す特別な管理者的メッセージ（すなわち、非取引メッセージ）を、（該システム１００内の任意の１つ以上のノードであり得る）受信ノードが１つ以上の送信ノードに定期的に通信するように構成されてもよい。例えば、シーケンサ１５０のグローバルフロー５００は、ゲートウェイ１２０からのさらなるメッセージを受信するための「余地」がどれほどあるのかという通知を、該ゲートウェイ１２０に定期的に通信し返すものとされ得る。すると、送信ノード（例えば、ゲートウェイ１２０等）のＱＯＳシェーパ３２０は、自身のＱＯＳパラメータ設定３４０を適切に調節する。

【0170】

また、１つ以上のゲートウェイ１２０は、同ゲートウェイ１２０上の全コネクション１３１にわたってその情報が適用されるように該情報を伝搬させ得る。前記調節は、例えば、各コネクションのＴＣＰのウィンドウサイズに変更を加えること、および／またはコネクション毎の対応するトークンバケット３１０パラメータを調節することを含み得る。

【0171】

同様の管理者的メッセージは、前記システム内の他の場所、例えば、（参加者１３０からの）インバウンド方向に流れるメッセージの場合には、コア１４０からシーケンサ１５０やゲートウェイ１２０へと、さらに、シーケンサ１５０やコア１４０からゲートウェイ１３０へと流れるメッセージの場合には、逆方向（例えば、アウトバウンド方向等）でもやり取りされ得る。アウトバウンド方向での輻輳の場合についても、ゲートウェイのＱＯＳシェーパ３２０やシーケンサ１５０の（例えば、グローバルフロー制御５００の）ＱＯＳシェーパ５２０が、インバウンド方向での対応するＱＯＳパラメータ５４０の調節を行い得る。

【0172】

ゲートウェイ毎のトークンバケット５２２を有するＱＯＳシェーパ５２０を用いるなどしてシーケンサ１５０のグローバルフロー制御５００のレート制限をより積極的に行う別の実施形態では、同グローバルフロー制御５００が、ゲートウェイノード１３０に対し、該ゲートウェイノード１３０を出るメッセージのフローの一時的な減速又は停止を要求する通信を先回りで返し得る。これは、例えば、１つ以上のゲートウェイのフローをその通常許可レベルの半分に減らすなどして行われ得る。フローの調節が済んだ後、グローバルフロー制御部５００は、ゲートウェイノード１２０に対して通常動作を再開するように指示し得る。

【0173】

図６に、システム１００内で用いられ得るフロー制御メッセージの階層構造の一実施形態を示す。前述したように、ゲートウェイ１２０がメッセージをシーケンサ１５０に出力し、シーケンサ１５０が同メッセージをコア１４０に転送する。前記システム内のうちの、キューイングが可能とされている様々な場所で、（既述した任意の手法による）フロー制御も加えて実施される。よって、例えば、ゲートウェイ１２０のシェーパ３３０がクライアント１３０にフロー制御を適用することになり得て、シーケンサ１５０のシェーパ５２０が１つ以上のゲートウェイ１２０にフロー制御を適用することになり得て、コア１４０がシーケンサ１５０のシェーパ５２０にフロー制御を適用することになり得る。

【0174】

ゲートウェイ１２０は、過負荷を引き起こしている個々のクライアント１３０に対してフロー制御を調節し得るか、あるいは、自身が取り扱う全てのクライアント１３０を減衰し（throttle back）得る。同様に、一部の実施形態では、シーケンサが、過負荷を引き起こしている個々のゲートウェイ１２０に対してフロー制御を調節し得るか、あるいは、システム全体の過負荷が解消されるまで全てのゲートウェイ１２０を減衰し得る。

【0175】

フロー制御の実施には、停止処理などの幾つかの方法がある。これは、各ゲートウェイシェーパ３２０又はグローバルシェーパ５２０の各トークンバケットに出力するクロックを停止させることによって達成され得る。メッセージが十分に片付けば、トークンバケットのクロックを再び有効にすることによって、同フロー制御が緩和され得る。フロー制御は、（現在検出されたフローレートに基づいて）動的に適用され得るか、あるいは、前記システムのプロビジョニングが行われたときに構成パラメータを一定に設定することによって適用され得る。クロックを停止させることができない他の実施形態では、停止処理が、ＴＣＰのウィンドウサイズを０にし、かつ／あるいは、トークンバケットパラメータを０に設定し、かつ／あるいは、各キューからのメッセージの処理を中断するものであり得る。

【0176】

送出処理および受入処理のいずれか、あるいは両方が停止されてもよいという点を理解されたい。つまり、受入処理を停止する一方で、送出が停止されていない場合、前記システムによるクライアントへのアウトバウンドメッセージの送信が依然として行われ得る。

【0177】

図７に、フロー制御３００がゲートウェイ１２０の一例に適用される場合の実装候補を示す。おさらいすると、各クライアントコネクション１３１－１，１３１－２，．．．，１３１－ｎから流入するメッセージは、コネクション毎ＦＩＦＯ３１２－１，３１２－２，．．．３１２－ｎのうちの対応するＦＩＦＯに入れられる。例えば、コネクション「ｃｏｎｎ１」１３１－１で受信されたメッセージは、ＦＩＦＯキュー３１２－１に入れられる。ＦＩＦＯ３１２－１には３つのメッセージがキューイングされているが、満杯になるまで追加のメッセージを所定数（「Ｆ１」）収めることのできる余地がある。メッセージのバーストレート及び持続レートを制御するトークンバケットとして実現され得るコネクション毎ＱＯＳシェーパ３２２－１は、メッセージを新たに通過させる時間になると、ＦＩＦＯキュー３１２－１から次のメッセージを引き出す。その時間は、コネクション毎ＱＯＳシェーパの３２０－１に構成されたレート設定３４０に従って決定され得る。

【0178】

コネクション毎ＱＯＳシェーパ３２２－１からのメッセージは、次に、全てのクライアントコネクション１３１間で共有するアービタ３３０に進入し得る。また、アービタ３３０は、それ自身のＦＩＦＯキュー３３５を有し得る。図示されているように、共有アービタのＦＩＦＯキュー３３５は、現時点でメッセージが４つのキューイングされており、同共有アービタのＦＩＦＯキュー３３５が満杯になるまで追加のメッセージの余地が所定数（「Ａ」）ある。共有アービタ３３０は、例えばラウンドロビン方式で全クライアントコネクションからのメッセージを一度に一つ放出し、分散型システムコア４２０に送信してシーケンサ１５０（及びそれに対応するグローバルフロー制御５００）に進入させ得る。

【0179】

図７で見て取れるように、「ｃｏｎｎ１」１３０－１のコネクション毎ＴＣＰウィンドウサイズは、コネクション毎ＦＩＦＯキュー３２２－１に未だ収めることのできる追加メッセージの数（「Ｆ１」）（つまり、同コネクションについて未だ利用することのできる「送入スペース」がどのくらいあるか）および共有アービタのキュー３３５に未だ収めることができる追加メッセージの数（「Ａ」）（つまり、ゲートウェイ全体として処理することのできるメッセージがどのくらいあるか）の関数（例えば、「ｍｉｎ」関数）として継続的に求められる。コネクション１３１－１がインバウンドメッセージを送信するレートをゲートウェイで減衰させることのできる手法の一つとしては、この点でＴＣＰ「ウィンドウスクイーズ（window squeeze）」を適用すること（例えば、ＴＣＰのウィンドウサイズを減少させる等）が挙げられる。シーケンサ１５０によって求められ得るレート制限入力「Ｓ」は、全てのゲートウェイにとって定数とされてもよいし、ゲートウェイ毎の値とされてもよい。

【0180】

コネクション１３１－１を利用するクライアント１３０－１は、最小値も処理できないような可能性があるので、そのような場合などには、Ｆ１やＡよりも低い値を指定することができる。

【0181】

また、コネクションのフローレートを調節するための仕組みには、前述のもの以外に、別のものが存在していてもよい。例えば、個々のゲートウェイ１３０は、自身が圧倒されていることを検出すると、自身の速度を低下させ得るか、あるいは、シーケンサにメッセージを送信し、該ゲートウェイのクライアントコネクション毎のレートシェーパを最終的に減衰するフィードバックを行わせる複数の仕組みのうちの任意の役割を、同シーケンサに担がせ得る。

【0182】

クライアントコネクションの減衰を行う他の方法やその理由としては、次のものが含まれ得る：コネクション区分やサーバ区分（プレミア、ビギナートライアル、オンボーディングなど）による静的なもの、あるいは、接続中の任意のクライアントからのバックプレッシャーによる動的なもの。

【0183】

また、別の箇所で詳しく説明しているが、シーケンサ１５０のグローバルフロー制御部５００は、グローバル集約部５３０による支援を開始することで、ゲートウェイ１２０のうちの一つ、一部または全て、あるいは、任意の他のノード毎のキューを減速させるためのフィードバックを行い得る。

【0184】

また、シーケンサ１５０は、ゲートウェイからコアへの方向のための一つと、コアからゲートウェイへの方向のためのもう一つとの、２つの集約部を有することも可能であり得る。一部の実施形態では、シーケンサ１５０のグローバルフローが、ゲートウェイからのメッセージとコアからのメッセージの両方を集約する単一のキューを有し得る。しかし、他の実施形態では、シーケンサ１５０のグローバルフロー５００が、ゲートウェイ１２０から受信したメッセージを集約するほうと、コア１４０から受信したメッセージを集約する別のほうとの、２つのキューを有し得る。

【0185】

他の実施形態は、コンピュートノード１４０について、輻輳を助けるように構成したものとされ得る。特定のコンピュートノード１４０は、自身が過度にビジーなると、ゲートウェイフロー制御部３００またはグローバルフロー制御部５００に対し、該コンピュートノード１４０へのインバウンドデータフローを遅くするように求めるメッセージを送信し得る。同メッセージが最初にグローバルフロー制御部５００（あるいは、その他の何らかの一元的権限部）に送られた場合、シーケンサ１５０には、要求側のコンピュートノード１４０の輻輳が送入フローを遅らせるに値するものであるか否かを判断する機会が与えられ、これが肯定である場合（in which case）、１つ以上のゲートウェイに速度を低下させるように指示する同等のメッセージが該１つ以上のゲートウェイに転送され得る。また、シーケンサまたはその他の一元的権限部は、例えば、圧倒を経験中のコンピュートノードと同じ記号を取り扱うコンピュートノードが現在いかなる輻輳も経験していない等の理由から応答レイテンシが現在影響を受けていないか又は現在影響を受けないと予想される場合、受入の減速を行う必要がないと判断し得る（many）。

【0186】

また、システム１００が取引システムである場合、シーケンサは、輻輳中のノード１４０－１の記号を何らかの別の、それほど輻輳していないノード１４０－２に再割当てすることによって、輻輳緩和を要請したコンピュートノード１４０－１の要求に応じ得る。

【0187】

ある場面では、送出時のキューの蓄積（例えば、送出キューが満杯になりつつある等）が、受入時のフロー制御に影響を及ぼす可能性がある。これは、特に、メッセージフローが非対称になる（例えば、送出メッセージの数が受入メッセージの数を上回る）可能性が十分高い電子取引システムなどの一部の実施形態でそうなる。電子取引システムにおいて、これは、次のような場合に発生し得る：
－スイッチが故障し、多くのセッションで切断による取消が起こった場合（これは、大量の非同期取消メッセージを生じさせる）；
－交差注文（crossing orders）：一つの注文で大きい数量が出された場合、大量の相手側当事者とマッチする可能性がある；
－同じ有効期限の注文が大量にある場合；
－取引日の終わり：一日注文が大量に取り消されなければならない。

【0188】

また、コアノード１４０は、例えば、大量の注文「成立」または「切断による取消」が全て発生した場合にも支援を行い得る。後者（Those）は、クライアントとシステム１００との間のスイッチの故障などといった、何らかのインフラストラクチャ障害によって起こり得る。よって、停止または遮断器的な機能で、（「開始から８％の市場ダウン」などの）特定のイベントが発生したときや、日中（例えば、昼休憩時等）や、ＩＰＯや祝休日スケジュールに基づく期間のあいだ、システム１００全体の速度を下げるようにしてもよい。

【0189】

また、図４との関連で前述したように、シーケンサ１５０は、各ゲートウェイ１３０のレート制限のシェーピングを行う役割も担い得て、システム全体で大幅な輻輳が検出された場合に、ゲートウェイ１３０に対してフィードバックを通信し得る。よって、クライアントコネクションのコネクション毎ＴＣＰウィンドウサイズを計算するための図７で説明した機能が、グローバルフロー制御部５００に拡張されてもよい。

【0190】

図８は、例示的なシーケンサ１５０のグローバルフロー制御５００によってフロー制御が適用される一例を示す図である。おさらいすると、各ゲートウェイ１２０－１，１２０－２，．．．，１２０－ｎから流入するメッセージは、ゲートウェイ毎ＦＩＦＯ５１２－１，５１２－２，．．．５１２－ｎのうちの対応するＦＩＦＯに入れられる。例えば、ゲートウェイ１２０－１から受信されたメッセージは、ＦＩＦＯキュー５１２－１に入れられる。ＦＩＦＯ５１２－１には３つのメッセージがキューイングされているが、満杯になるまで追加のメッセージを所定数（「Ｆ１」）収めることのできる余地がある。メッセージのバーストレート及び持続レートを制御するトークンバケットとして実現され得るグローバルＱＯＳシェーパ５２２－１は、メッセージを新たに通過させる時間になると、ＦＩＦＯキュー５１２－１から次のメッセージを引き出す。その時間は、グローバルＱＯＳシェーパ５２２－１に構成されたレート設定に従って決定され得る。しかし、一部の実施形態では、ＱｏＳシェーパ５２２が「許可を与えた」場合、すなわち、対応するバケット５２２－１に少なくとも１つのトークンが存在する場合には、グローバルアービタ５３０がＦＩＦＯキュー５１２－１からメッセージを直接引き出し得る。同様の実装は、ゲートウェイフロー制御レベル３００でのコネクション毎トークンバケット３２２及びアービタ３３０についても可能である。

【0191】

グローバルＱＯＳシェーパ５２２－１からのメッセージは、次に、全てのゲートウェイ１３０間で共有するアービタ５３０に進入し得る。また、アービタ５３０は、それ自身のＦＩＦＯキュー５３５を有し得る。図示されているように、グローバルアービタのＦＩＦＯキュー５３５は、現時点でメッセージが４つのキューイングされており、同グローバルアービタのＦＩＦＯキュー５３５が満杯になるまで追加のメッセージの余地が所定数（「Ａ」）ある。共有アービタ５３０は、例えばラウンドロビン方式で全ゲートウェイからのメッセージを一度に一つ放出し、コア１４０に送信する。

【0192】

一実施形態では、シーケンサ１５０とゲートウェイ１３０との間のコネクションについてのＴＣＰのウィンドウサイズの調節が行われ得ない。その場合の理由としては、メッシュ１７２が、ＴＣＰのようなプロトコルのオーバーヘッドを必要としない、ポイントトゥポイント型のダイレクトコネクションであるというものが恐らく挙げられる。

【0193】

まとめると、グローバルフロー５００は、輻輳を軽減する必要がある場合、次の１つ以上のことを行い得る：
ａ）ゲートウェイ毎のトークンバケットパラメータの調節（可能な場合）；および／または
ｂ）１つ以上のゲートウェイについての、ゲートウェイからシーケンサへのコネクション毎のＴＣＰのウィンドウサイズの調節（可能な場合）；および／または
ｃ）フローの調節を行ってもらうように１つ以上のゲートウェイにメッセージを送信した際の、グローバルフロー５００からの同メッセージに応じての、該１つ以上のゲートウェイによる次に示す：
ｉ．該ゲートウェイ上のクライアントからゲートウェイへの全てのコネクション（例えば、コネクション１３１－１，１３１－２，．．．，１３１－ｎ等）のＴＣＰのウィンドウサイズの調節、かつ／あるいは
ｉｉ． 該ゲートウェイ上のクライアントからゲートウェイへの全てのコネクションのクライアントコネクション毎のトークンバケットパラメータの調節、および／または
ｄ）クライアントからゲートウェイへの１つ以上のコネクションの停止（前述の様々な停止オプションの使用）。

【0194】

一部の実施形態では、クライアントからゲートウェイへのコネクションのうちの、減速の必要があり得る個々のコネクションの特定は、非効率的および／または困難になり得ることから、シーケンサ１５０のグローバルフロー５００の義務とされ得ない。シーケンサ１５０のグローバルフロー制御５００は、（ゲートウェイ１２０－１などの）一つのゲートウェイからの全トラフィックまたは全ゲートウェイ１２０－１，１２０－２，．．．１２０－ｇのうちの一部のゲートウェイからのトラフィックを減速させる可能性が高く、おそらくは、全てのゲートウェイ１２０からのトラフィックを減速させる可能性さえある。このようなフロー制御は、本明細書の別の箇所で説明したどの方法で実現されてもよい。

【0195】

（その他のユースケース）

【0196】

前述のアーキテクチャは、電子取引システム以外の用途に用いられてもよい。例えば、証券取引注文の処理以外の用途として、ネットワークを流れるデータストリームの監視や、パケットのキャプチャや、パケットの生データの復号化や、パケット内容のリアルタイム分析や、応答の提供に利用され得ることが可能である。

【0197】

（その他の実装／実現の選択肢）

【0198】

これまでに述べた例示的な実施形態は、数多くの様々な方法で実現され得るという点を理解されたい。場面にもよるが、各種「データプロセッサ」が、それぞれ、中央処理装置（central processor）と、メモリと、ディスク又はその他の大容量記憶装置と、１つ以上の通信インターフェースと、１つ以上の入出力（Ｉ／Ｏ）装置と、その他の周辺装置とを具備した、物理的又は仮想的な汎用コンピュータによって実現され得る。例えば、前記処理装置にソフトウェア命令を読み込んで同命令の実行によって前述の機能を実行させる等すれば、前記汎用コンピュータがプロセッサへと変容して前述の処理を実行する。

【0199】

当該技術分野で既知のとおり、そのようなコンピュータは、コンピュータ又は処理システムの構成要素間でのデータ伝送に利用される一連のハードウェアラインであるシステムバスを備え得る。１つ以上の該バスは、本質的に、コンピュータシステムの相異なる構成要素（例えば、中央演算処理装置、ディスク、各種メモリ、入出力ポート、ネットワークポート等の１つ以上）同士を接続して当該構成要素間での情報の伝送を可能にする１つ以上の共有の導管である。該システムバスには、１つ以上の中央演算処理装置が取り付けられてコンピュータ命令が実行される。典型的に、該システムバスには、さらに、入出力装置インターフェースが取り付けられて前記ディスク、メモリおよび各種入出力装置の接続を行う。１つ以上のネットワークインターフェースにより、ネットワークに取り付けられた別の様々な装置へのコネクションが可能となる。１つ以上のメモリにより、実施形態を実現するのに用いられるコンピュータソフトウェア命令やデータの揮発性及び／又は不揮発性の記憶が行われる。ディスクやその他の大容量記憶装置により、例えば、本明細書に記載した各種手順を実現するのに用いられるコンピュータソフトウェア命令やデータの不揮発性の記憶が行われる。

【0200】

よって、実施形態は、典型的に、ハードウェア、カスタム設計された半導体論理、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ファームウェア、ソフトウェア、またはこれらの任意の組合せで実現され得る。

【0201】

特定の実施形態において、本明細書に記載した手順、装置及び方法は、コンピュータプログラムプロダクトである。該コンピュータプログラムプロダクトとしては、前記システムのソフトウェア命令の少なくとも一部を提供するコンピュータ読取り可能媒体（例えば、１つ以上のＤＶＤ－ＲＯＭ、ＣＤ－ＲＯＭ、ディスケット、テープなどといった、取外し可能な記憶媒体等）が含まれる。該コンピュータプログラムプロダクトは、当該技術分野で周知のとおり、任意の適切なソフトウェアインストール方法によってインストールされることが可能である。また、他の実施形態では、前記ソフトウェア命令の少なくとも一部が、ケーブル及び／又は通信及び／又は無線接続を介してダウンロードされ得る。

【0202】

また、実施形態は、１つ以上の手順で読み出されて実行され得る、非過渡的なマシン読取り可能媒体に記憶された命令として実現されている場合もある。非過渡的なマシン読取り可能媒体は、マシン（例えば、コンピューティングデバイス等）によって読取り可能な形式で情報を記憶したり送信したりするための任意の仕組みを具備したものであり得る。例えば、非過渡的なマシン読取り可能媒体としては、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体からなるストレージ、光学式の記憶媒体、フラッシュメモリ装置等が含まれ得る。

【0203】

また、本明細書では、ファームウェアやソフトウェアやルーチンや命令が、特定の処理及び／又は機能を実行するかの如く説明されているかもしれない。しかしながら、本明細書に含まれるこのような説明はあくまでも便宜上のものに過ぎず、実際には、コンピューティングデバイス、プロセッサ、コントローラなどの装置が同ファームウェア、ソフトウェア、ルーチン、命令などを実行することによってそのような処理が生じるという点を理解されたい。

【0204】

また、ブロック図やネットワーク図は、構成要素の数が増えても減ってもよいし、配置構成が異なってもよいし、別の表現にもなり得るという点を理解されたい。ただし、実装によってはブロック図やネットワーク図が決まっており、実施形態の実施を表すブロック図やネットワーク図の数も所定数になり得るという点を理解されたい。

【0205】

つまり、様々なコンピュータアーキテクチャ及び／又は物理コンピュータ及び／又は仮想コンピュータ及び／又はクラウドコンピュータ及び／又はこれらの所与の組合せにより、さらなる実施形態が実現され得ることもある。したがって、本明細書に記載したコンピュータシステムは、あくまでも例示目的に意図されたものあり、実施形態を限定するものではない。

【0206】

以上の説明では、例示的な実施形態を具体的に図示説明したが、当業者であれば、添付の特許請求の範囲に包含された本特許の法的範囲を逸脱しない範疇で、形態や細部に様々な変更が施されてもよいことが分かるであろう。

【図1A】

【図1B】

【図1C】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【国際調査報告】