(57)【要約】      （修正有）【課題】“Ｐｏｉｎｔ−ｏｆ−Ｐｒｅｓｅｎｃｅ”のような電子取引注文管理インフラを提供する。【解決手段】通信レイテンシー平準化システム（ＴＬＬ）は、ネットワークアクセスポイントにおいて送信媒体を介して異なる取引主体から電子取引注文を受け取りルーティングする。これらインフラは、取引注文が電子市場センタへ到着し執行される前に、ある程度の通信レイテンシーを生じさせる。これにより、高速取引参加者が利用するレイテンシーアービトラージおよび／またはオーダブックアービトラージを抑制する。【選択図】図１Ａ
2020205075.tif 000002
【特許請求の範囲】
【請求項１】
フロントエンドサーバと複数のバックエンドサービスとを有するコンピュータネットワークにおけるＴＣＰ対マルチキャスト（Ｔ２Ｍ）通信のためのコンピュータシステムであって、
電子ネットワーク内のフロントエンドサーバの一部として構成された少なくとも１つのコンピュータプロセッサ；
伝送制御プロトコル（ＴＣＰ）に基づいて１つ以上のクライアントコンピュータの各々と１対１通信するために構成された少なくとも１つの第１通信インターフェース；
ユーザデータグラムプロトコル（ＵＤＰ）に基づいて、前記１つ以上のクライアントコンピュータのうちの１つから受信した情報の少なくとも一部が前記複数のバックエンドサービスに対して同時に送信される、１対多通信のために構成された少なくとも１つの第２通信インターフェース；
を備える、
コンピュータシステム。
【請求項２】
前記少なくとも１つの第１通信インターフェースは、単一の通信ポートを介して前記１つ以上のクライアントコンピュータのそれぞれとのＴＣＰ接続を維持するように構成される、
請求項１記載のコンピュータシステム。
【請求項３】
前記複数のバックエンドサービスは、複数のバックエンドサーバによって提供される、
請求項１記載のコンピュータシステム。
【請求項４】
前記複数のバックエンドサービスのうちの少なくとも１つは、前記情報の少なくとも一部を少なくとも１つの別のバックエンドサービスに対して送信するように構成される、
請求項１記載のコンピュータシステム。
【請求項５】
前記複数のバックエンドサービスとの前記１対多通信は、前記１つ以上のクライアントコンピュータから遮蔽される、
請求項１記載のコンピュータシステム。
【請求項６】
前記複数のバックエンドサービスは、前記フロントエンドサーバから独立してスケーリングされるように構成される、
請求項５記載のコンピュータシステム。
【請求項７】
前記情報の少なくとも一部は、リアルタイム品質分析のために独立して並列にストリーミングされる、
請求項５記載のコンピュータシステム。
【請求項８】
フロントエンドサーバと複数のバックエンドサービスとを有するコンピュータネットワークにおけるＴＣＰ対マルチキャスト（Ｔ２Ｍ）通信のための方法であって、
前記フロントエンドサーバによって、伝送制御プロトコル（ＴＣＰ）に基づいて１対１通信を介して１つ以上のクライアントコンピュータの各々から情報を受信するステップ；
１対多通信を介して、ユーザデータグラムプロトコル（ＵＤＰ）に基づいて前記複数のバックエンドサービスに対して前記情報の少なくとも一部を同時に送信するステップ；
を有する方法。
【請求項９】
前記方法はさらに、
１つの通信ポートを介して、前記１つ以上のクライアントコンピュータのそれぞれとＴＣＰ接続を維持するステップを有する、
請求項８記載の方法。
【請求項１０】
前記複数のバックエンドサービスは、複数のバックエンドサーバによって提供される、
請求項８記載の方法。
【請求項１１】
前記方法はさらに、
前記複数のバックエンドサービスのうちの少なくとも１つによって、前記情報の少なくとも一部を少なくとも１つの別のバックエンドサービスに対して送信するステップを有する、
請求項８記載の方法。
【請求項１２】
前記複数のバックエンドサービスとの前記１対多通信は、前記１つ以上のクライアントコンピュータから遮蔽される、
請求項８記載の方法。
【請求項１３】
前記方法はさらに、
前記フロントエンドサーバから独立して前記複数のバックエンドサービスをスケーリングするステップを有する、
請求項１２記載の方法。
【請求項１４】
前記方法はさらに、
リアルタイム品質分析のために、前記情報の少なくとも一部を独立して並列にストリーミングするステップを有する、
請求項１２記載の方法。
【請求項１５】
フロントエンドサーバと複数のバックエンドサービスとを有するコンピュータネットワークにおいて、少なくとも１つのコンピュータプロセッサにＴＣＰ対マルチキャスト（Ｔ２Ｍ）通信を実装させるためのコードを有する非一時的コンピュータ可読媒体であって、
フロントエンドサーバによって、伝送制御プロトコル（ＴＣＰ）に基づいて１対１通信を介して１つ以上のクライアントコンピュータの各々から情報を受信するためのコード；
１対多通信を介して、ユーザデータグラムプロトコル（ＵＤＰ）に基づいて前記複数のバックエンドサービスに対して前記情報の少なくとも一部を同時に送信するためのコード；
を備える、
コンピュータ可読媒体。
【請求項１６】
前記コンピュータ可読媒体はさらに、
単一の通信ポートを介して前記１つ以上のクライアントコンピュータのそれぞれとＴＣＰ接続を維持するためのコードを備える、
請求項１５記載のコンピュータ可読媒体。
【請求項１７】
前記複数のバックエンドサービスは、複数のバックエンドサーバによって提供される、
請求項１５記載のコンピュータ可読媒体。
【請求項１８】
前記複数のバックエンドサービスのうちの少なくとも１つは、前記情報の少なくとも一部を少なくとも１つの別のバックエンドサービスに対して送信するように構成される、
請求項１５記載のコンピュータ可読媒体。
【請求項１９】
前記複数のバックエンドサービスとの前記１対多通信は、前記１つ以上のクライアントコンピュータから遮蔽される、
請求項１５記載のコンピュータ可読媒体。
【請求項２０】
前記複数のバックエンドサービスは、前記フロントエンドサーバから独立してスケーリングされるように構成される、
請求項１５記載のコンピュータ可読媒体。
【請求項２１】
前記情報の少なくとも一部は、リアルタイム品質分析のために独立して並列にストリーミングされる、
請求項１５記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、通信レイテンシー平準化方法（ＴＲＡＮＳＭＩＳＳＩＯＮ  ＬＡＴＥＮＣＹ  ＬＥＶＥＬＩＮＧ）および技術（以下「ＴＬＬ」）の様々な新規イノベーションおよび発明を開示および記載する。本願は、著作権、マスクワーク、および／または知的財産保護による保護を受ける内容を含む。この知的財産権の所有者は、本開示を特許庁ファイル／レコードにおける公開公報においてファクシミリコピーすることにつき異議はない。その他の場合においては全ての権利を留保する。
【０００２】
＜優先権＞
本願は非仮出願であり、３５  Ｕ．Ｓ．Ｃ  １１９およびパリ条約に基づき以下の出願の優先権を主張する：米国仮出願第６１／７００，０９４号、２０１２年９月１２日出願、発明の名称“Ｐｒｏｖｉｓｉｏｎｓ  ｆｏｒ  Ｒｅｄｕｃｉｎｇ  ｔｈｅ  Ａｄｖａｎｔａｇｅｓ  ｏｆ  Ｈｉｇｈ−Ｆｒｅｑｕｅｎｃｙ  Ｔｒａｄｉｎｇ  ｉｎ  Ｆｉｎａｎｃｉａｌ  Ｍａｒｋｅｔｓ”；米国仮出願第６１／７５８，５０８号、２０１３年１月３０日出願、発明の名称“Ｐｒｏｖｉｓｉｏｎｓ  ｆｏｒ  Ｒｅｄｕｃｉｎｇ  Ｅｆｆｅｃｔｉｖｅｎｅｓｓ  ｏｆ  Ｏｒｄｅｒ  Ｂｏｏｋ  Ａｒｂｉｔｒａｇｅ  ｏｎ  ａ  Ｓｅｃｕｒｉｔｉｅｓ  Ｔｒａｄｉｎｇ  Ｖｅｎｕｅ”；米国仮出願第６１／８７６，２００号、２０１３年９月１１日出願、発明の名称“ＣＯＮＧＥＳＴＩＯＮ  ＦＡＩＬＯＶＥＲ  ＡＮＤ  ＲＥＬＩＡＢＬＩＴＹ  ＥＮＨＡＮＣＥＤ  ＯＲＤＥＲ  ＰＬＡＴＦＯＲＭ  ＡＰＰＡＲＡＴＵＳＥＳ，ＭＥＴＨＯＤＳ  ＡＮＤ  ＳＹＳＴＥＭＳ”；米国仮出願第６１／７５３，８５７号、２０１３年１月１７日出願、発明の名称“Ｂｉｎａｒｙ  Ｓｅａｒｃｈ  Ｔｒｅｅ  ｗｉｔｈ  Ｗｏｒｓｔ−Ｃａｓｅ−Ｏｐｔｉｍｉｚｅｄ，  Ｔｉｍｅ−Ｄｅｔｅｒｍｉｎｉｓｔｉｃ  Ｉｎｓｅｒｔ  ａｎｄ  Ｓｅａｒｃｈ  Ｏｐｅｒａｔｉｏｎｓ  ｆｏｒ  ａ  Ｆｉｎｉｔｅ  Ｋｅｙ  Ｓｐａｃｅ”。
【０００３】
上記全出願は、参照により本願に組み込まれる。
【０００４】
本発明は一般に、電子取引プラットフォームの装置、方法、およびシステムに関するものである。具体的には、通信レイテンシー平準化装置、方法、およびシステム（ＴＬＬ）を含む。
【背景技術】
【０００５】
消費者は、オークションベースシステムを用いて商品を売買する。このオークションベースまたは交換ベースシステムは、オークションベースオンラインショッピングサイト、オンラインチケット予約システム、電子マーケット、その他取引所を含む。
【０００６】
個人投資家およびトレーダは、証券（例えば株や債券）、外国為替、その他金融派生商品を電子取引プラットフォーム上で売買する。ＮＡＳＤＡＱ、ＮＹＳＥ、Ａｒｃａ、Ｇｌｏｂｅｘ、Ｌｏｎｄｏｎ  Ｓｔｏｃｋ  Ｅｘｃｈａｎｇｅ、ＢＡＴＳ、Ｃｈｉ−Ｘ  Ｅｕｒｏｐｅ、ＴｒａｄｅＷｅｂ、ＩＣＡＰ、Ｃｈｉｃａｇｏ’ｓ  Ｂｏａｒｄ  ｏｆ  Ｔｒａｄｅなどの電子取引プラットフォームは、仮想市場を提供する。この仮想市場は、売買者が金融商品を売買する情報技術インフラを備える。トレーダは、例えばパーソナルコンピュータユーザインターフェースなどの電子端末を介して電子取引プラットフォームに対してビッドを送信する。電子取引プラットフォームは、金融商品の値付け情報を反映するリアルタイムのアスク情報とビッド情報を、他の取引主体のコンピュータ端末に対して通信ネットワークを介して送信する。
【発明の概要】
【課題を解決するための手段】
【０００７】
通信レイテンシー平準化技術（ＴＬＬ）は、例えば“Ｐｏｉｎｔ−ｏｆ−Ｐｒｅｓｅｎｃｅ”または“ＰＯＰ”のような電子取引注文管理インフラを提供する。これらインフラは、ネットワークアクセスポイントにおいて送信媒体を介して異なる取引主体から電子取引注文を受け取りルーティングする。これらインフラは、取引注文が電子市場センタへ到着し執行される前に、ある程度の通信レイテンシーを生じさせる。これにより、高速取引参加者が利用するレイテンシーアービトラージおよび／またはオーダブックアービトラージを抑制する。
【０００８】
添付する図面は、本明細書に基づき、非限定的な発明の側面、実施形態、特徴の様々な例を示す。
【図面の簡単な説明】
【０００９】
【図１Ａ】ＴＬＬの実施形態においてレイテンシーアービトラージを抑制する例を示す。
【００１０】
【図１Ｂ】ＴＬＬの実施形態においてオーダブックアービトラージを抑制する例を示す。
【００１１】
【図１Ｃ】ＴＬＬの実施形態においてアービトラージを抑制するＴＬＬ  Ｐｏｉｎｔ  ｏｆ  Ｐｒｅｓｅｎｃｅ（ＰＯＰ）メカニズムのインフラ例を示す比較図である。
【図１Ｄ】ＴＬＬの実施形態においてアービトラージを抑制するＴＬＬ  Ｐｏｉｎｔ  ｏｆ  Ｐｒｅｓｅｎｃｅ（ＰＯＰ）メカニズムのインフラ例を示す比較図である。
【００１２】
【図２】ＴＬＬの実施形態においてＴＬＬビッドデータ収集のためのＴＬＬプラットフォームと提携主体との間のデータフローを示すデータフロー図である。
【００１３】
【図３】ＴＬＬの実施形態においてレイテンシーアービトラージを抑制するＰＯＰルーティングを示すロジックフローである。
【００１４】
【図４Ａ】ＴＬＬの実施形態におけるＴＬＬのユーザインターフェース例である。
【図４Ｂ】ＴＬＬの実施形態におけるＴＬＬのユーザインターフェース例である。
【００１５】
【図５Ａ】ＴＬＬの実施形態におけるＴＬＬネットワークインフラを示すデータ図の例である。
【図５Ｂ】ＴＬＬの実施形態におけるＴＬＬネットワークインフラを示すデータ図の例である。
【図５Ｃ】ＴＬＬの実施形態におけるＴＬＬネットワークインフラを示すデータ図の例である。
【００１６】
【図６Ａ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｂ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｃ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｄ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｅ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｆ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｇ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【図６Ｈ】ＴＬＬの実施形態において、通信レイテンシーを生じさせるネットワークアクセスポイントを介してレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す図である。
【００１７】
【図７】ＴＬＬの別実施形態を示すデータフロー図である。
【００１８】
【図８Ａ】ＴＬＬの実施形態における、最悪ケースに最適化した、時間決定的インサートの、有限キー空間において検索を実施する、バイナリサーチツリーの実施形態を示す図である。
【図８Ｂ】ＴＬＬの実施形態における、最悪ケースに最適化した、時間決定的インサートの、有限キー空間において検索を実施する、バイナリサーチツリーの実施形態を示す図である。
【図８Ｃ】ＴＬＬの実施形態における、最悪ケースに最適化した、時間決定的インサートの、有限キー空間において検索を実施する、バイナリサーチツリーの実施形態を示す図である。
【図８Ｄ】ＴＬＬの実施形態における、最悪ケースに最適化した、時間決定的インサートの、有限キー空間において検索を実施する、バイナリサーチツリーの実施形態を示す図である。
【００１９】
【図９】ＴＬＬコントローラの例を示すブロック図である。
【発明を実施するための形態】
【００２０】
１実施例において、Ｐｏｉｎｔ−ｏｆ−Ｐｒｅｓｅｎｃｅ（ＰＯＰ）アクセスポイントがインストールされ、市場参加者から取引注文を受け取り、その注文をデータ取引所に引き渡して執行させるように構成される。ＰＯＰに対するまたはＰＯＰからの送信により、通信レイテンシーがさらに増える可能性がある。これは市場参加者の場所（送信距離など）、送信媒体（例えばケーブル、マイクロ波など）、回路、その他情報技術インフラおよび／または送信速度などによる。例えば、ＰＯＰとデータ取引所または市場参加者端末を接続するために必要なデータケーブル長は、通信レイテンシーを生じさせるために利用することができる。この通信レイテンシーは、通信ケーブル長を調整することにより制御できる。
【００２１】
１実施例において、ＰＯＰは非インテリジェントネットワークハードウェアを備える。同ハードウェアは、注文を受け取る入力ポートに接続する少なくとも１つの通信リンク、および受け取った注文をデータ取引所および／またはその他主体へ送信する出力ポートに接続する通信リンクを含む。他実施例においてＰＯＰは、プロセッサが命令セットを実施するためのコンピュータ実行可能命令を格納したコンピュータ読取可能媒体を備える。
【００２２】
図１Ａ〜図６Ｈで説明する実施例は、金融商品取引のための市場データセンタとデータ取引所を含んでいる。しかしＴＬＬは、任意のアクションベースシステムまたは電子市場に対して適用することができる。例えばアドエクスチェンジ（ディスプレイ、モバイル、ラジオ、検索、ビデオ、など）、オンライン航空チケット／ホテル予約システム、オンラインオークションショッピングシステム、ＭＭＯＲＧ内におけるバーチャルワールドゲーム内市場、などに対して適用することができるが、これらに限らない。ＴＬＬは、レイテンシーおよび／またはリソースアクセスを考慮する必要がある任意の電子メッセージングシステムに対して適用することができる。例えばオンラインビデオゲームにおいては、プレイヤがメッセージを送受信する速度がゲームの状況を理解し反応することができる速度を決定し、プレイヤが他のプレイヤよりも先に反応することができる。ＴＬＬにより、プレイヤはゲームに勝つことができる。このようにＴＬＬは、オークションベースシステムにおいて、情報やリソースに対して画一的にフェアアクセスする機能を提供できる。
【００２３】
図面内の各参照番号の先頭部分は、参照番号を導入および／または詳細説明する図面を示す。例えば参照番号１０１は、図１に記載されおよび／または導入される。参照番号２０１は、図２において導入される。以下同様である。
【００２４】
＜通信レイテンシー平準化（ＴＬＬ）＞
図１Ａは、ＴＬＬの実施形態におけるレイテンシーアービトラージを抑制する例を示す。１実施例において、金融商品取引市場の参加者は、情報技術インフラを利用してマーケットデータフィードを他の市場参加者よりも速く取得することができ、これにより他の市場参加者が市場変化に対して反応する前に取引戦略を形成して実行することができる。
【００２５】
例えば１実施例において、市場参加者からの注文が実施される場所は、注文が受け付けられる場所でもあり、ここから相場レポート、執行済取引、その他市場データが一般に配信される。同じ場所および／または市場センタ近傍において取引主体の位置を確定する（例えば同一場所に配置する）ことにより、市場参加者は市場データアップデートを、データ配信時間がより長くかかるその他市場参加者よりも先に受け取ることができる。１実施例において、この市場データ送信アドバンテージは、様々な要因によって生じる。例えば、位置的アドバンテージ（例えば送信距離がより短い）、送信媒体（例えばケーブル、マイクロ波など）、回路抵抗、その他情報技術インフラのアドバンテージ、および／または送信速度アドバンテージなどであるが、これに限られない。
【００２６】
１実施例において市場データは、相場、最終取引フィード、および／またはその他市場情報を含む。１実施例において市場センタ１２０は、任意種類の取引所、市場データ配信者、代替取引システム、Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋ（ＥＣＮ）、データプール、などを含む。１実施例において市場センタは、取引注文を実施するデータ取引所を備える。別実施例において市場センタは、マッチングエンジンとスマートルータを備える。スマートルータは、注文をマッチングし、ルーティングし、および／または１以上のデータ取引所へ再ルーティングする。このデータ取引所は、市場センタと提携しているもの、または他の市場センタである。
【００２７】
市場参加者は、高速取引（ＨＦＴ）参加者を含むが、これに限られない。市場参加者は高速データ通信のアドバンテージにより、“レイテンシーアービトラージ”として知られるストラテジを取ることができる。図１Ａに示すように、１実施例において、例えば取引システムを市場センタ１２０近くに配置するなどにより、ＨＦＴ参加者１０２ｃは市場データ（例えば“Ｃｏｃａ  Ｃｏｌａ株”の価格更新１０３など）を、取引システムが市場センタ１２０からより離れている他の市場参加者１０２ａ−ｂよりも早く受け取ることができる。ＨＦＴ参加者１０２ｃは次に、他参加者がＣｏｃａ  Ｃｏｌａ株価の市場データ１０３を受け取るよりも前に、新たに受け取った市場データに基づき取引を実行する。例えばＣｏｃａ  Ｃｏｌａ株を購入する（１０４）。その結果、参加者１０２ａ−ｂはＣｏｃａ  Ｃｏｌａ株価変化１０３に基づき注文を生成および実行することになり、一方でＨＦＴ参加者１０３ｃはすでにＣｏｃａ  Ｃｏｌａ株の取引１０４を送信しているので、新たな価格変化が生じる可能性がある。１実施例において、ＨＦＴ参加者以外の市場参加者（例えばブローカ、個人投資家、その他自身の取引端末でデータ送信アドバンテージを享受する取引主体）は、意図するか否かを問わずレイテンシーアービトラージのアドバンテージを得ることができる。
【００２８】
１実施例において、ＴＬＬインフラは“ｐｏｉｎｔ  ｏｆ  ｐｒｅｓｅｎｃｅ（ＰＯＰ）”構造１１０を提供し、レイテンシーアービトラージを緩和し、より多くの参加者がフェアな市場にアクセスできるようにする。例えば図１Ａに示すように、ＴＬＬは市場の執行センタ１２０から、注文受付と市場データフィードの公開ソースを分離する。１実施例において、ＴＬＬは注文を市場センタ１２０へ直接送信することを許可せず、取引注文をＰＯＰ１１０へ送信または再ルーティングすることを要求する。取引注文はＰＯＰ１１０から市場センタ１２０へ送信される。１実施例において、相場価格（例えば１０３）を受け取りまたは取引が実行されると、そのデータは市場センタ１２０からＰＯＰ１１０へ送信される。ＰＯＰ１１０はこれを公開配信する。同様に取引注文は、ＰＯＰ１１０において再ルーティングされる（例えば１０５）。
【００２９】
１実施例においてＰＯＰ１１０は、ハードウェアアクセスポイントを備える。このハードウェアアクセスポイントは、プロセッサ、メモリユニット、１以上のデータＩ／Ｏポート、などを備え（図６などを参照）、ケーブル、無線、マイクロ波など様々な通信媒体を介して市場センタ１２０および／または市場参加者、取引データ端末などに接続される。１実施例においてＰＯＰアクセスポイントは、市場センタ１２０のマッチングエンジンから物理的に分離することもできるし、分離しないこともできる。マッチングエンジンは注文を実行し、および／またはマッチングと他市場センタへのルーティングを実施する。例えばＰＯＰアクセスポイントが市場センタの外に配置されている場合、ＰＯＰアクセスポイント１１０と市場センタ１２０との間の距離はデータ信号を通信する余分な時間を生じさせる。他実施例においてＰＯＰアクセスポイントは市場センタ内に配置され、ＰＯＰアクセスポイント周りに追加ケーブルが取り付けられ、これによりＰＯＰアクセスポイントから市場センタへデータ信号が到着するための余分な通信時間を生じさせる。図２において、ＰＯＰアクセスポイント１１０のその他物理的仕様（例えば通信媒体タイプ（例えばケーブル、無線、マイクロ波など）、ケーブル長、抵抗などの電気回路パラメータ、通信時間測定）を示す。
【００３０】
別実施例において、ユーザインターフェースなどを介して、ＰＯＰアクセスポイントのケーブル長、回路抵抗、および／またはその他ハードウェアパラメータを調整することができる。これにより、ＰＯＰアクセスポイントが生じさせる通信レイテンシーを調整することができる。
【００３１】
１実施例においてＴＬＬ／ＰＯＰ構造は、ＨＦＴ参加者１０２ｃが同一場所に存在することによるアドバンテージを減少させる。取引システムをＰＯＰに配置しているＨＦＴ参加者１０２ｃは、ＰＯＰ１１０から市場センタ１２０への往復レイテンシーによって遅延したデータフィードを受け取る。よって低レイテンシーフィードのアドバンテージに基づくＨＦＴストラテジ（例えば１０４）は、必ずしもその他参加者１０２ａ−ｂが市場データを受け取る前の市場データに基づき実行されるとは限らない（例えば１０８）。
【００３２】
別実施例において、図１Ｄに示すように、データ取引所１２２は取引注文を第２場所（他の取引所、ＥＣＮなど）へルーティングする。この場合、市場センタ１２０からＰＯＰ１１０へのレイテンシー（例えば市場センタ１２０がＰＯＰを介して最終取引フィードを含む市場データを公開するよう要求することにより生じる追加レイテンシー）と、ＰＯＰから第２場所へのレイテンシー（例えばＨＦＴ参加者がＰＯＰを介して注文を送信するよう要求することにより生じる追加レイテンシー）との合計が、市場センタ１２０から第２場所へのレイテンシーを超過していれば、市場センタからの注文はＨＦＴ参加者による干渉なしで安全に第２場所へルーティングされる。システムに追加レイテンシーを導入することにより、レイテンシーアービトラージの不公平なアドバンテージは減殺される。
【００３３】
図１Ｂは、ＴＬＬの実施形態においてオーダブックアービトラージを抑制する例を示す。１実施例において、図１Ａで説明したように、ＨＦＴ参加者１０２ｂは市場データフィードを他の参加者１０２ｂよりも速く受け取り、他市場参加者１０２ｂが市場フィードに対して反応しまたはこれを受け取ることができるよりも前にＨＦＴ参加者１０２ｃが取引を実行できるようにしようとする。このようなＨＦＴ取引ストラテジの例として、オーダブックアービトラージ戦略がある。オーダブックアービトラージは、市場情報を伝搬する際に市場センタが市場情報を処理する前にこれを処理して動作することにより、遅延によるアドバンテージを利用する。よって市場センタがより新しい情報を有している場合、未実行の取引を実行させる。
【００３４】
例えば多くの市場センタは、参加者が“ミッドポイントペッグ”で注文できるようにしている。そのリミット価格は市場センタによって動的調整され、常に全米最良気配（ＮＢＢＯ）価格の中間となる（例えば１２１）。ミッドポイントペッグ注文は、現在のＮＢＢＯの中間価格でのみ実行するよう意図されている。例えば注文が古いＮＢＢＯに基づき値付けされている場合、注文価格は最新ＮＢＢＯの中間価格ではなく、注文は取引されないかまたは最新ミッドポイント価格よりも劣る価格で取引されることになる。
【００３５】
例えば市場Ａにおいて、ＮＢＢＯは．１０×．１２で計算され、ミッドポイントは．１１となる。市場が新たなＮＢＢＯ．１１×．１３へ移動した場合、新たなミッドポイントは．１２となり、取引注文データをこれにしたがって更新して有効なミッドポイントペッグストラテジとなるようにする必要がある。市場Ａが必要な更新時間よりも前にＨＦＴ参加者が新たなミッドポイント（．１２）を取得すると、ＨＦＴ参加者は市場Ａにおいて．１１で購入し、即座に／同時にこれを他の市場において．１２で売却する可能性がある。これは．０１の“リスクなし”アービトラージである。このシナリオは、再値付けされる注文とは異なる（例えばＵ．Ｓ．Ｓｅｃｕｒｉｔｉｅｓ  ａｎｄ  Ｅｘｃｈａｎｇｅ  Ｃｏｍｍｉｓｓｉｏｎ’ｓ  Ｒｅｇｕｌａｔｉｏｎ  ＮＭＳ（Ｒｅｇｕｌａｔｉｏｎ  ＮＭＳ）などの法規に基づくもの）。すなわち市場Ａにおいて、ＮＢＢＯは．１０×．１２で計算されるとともに、市場Ａは．０９でビッドを受け付ける。市場が動いて新たなＮＢＢＯが．０９×．１１となり、市場Ａが更新するのが間に合わない場合、残りの．０９の買い注文とマッチングするため、．０９の売り注文を許可しない（Ｒｅｇｕｌａｔｉｏｎ  ＮＭＳは．１０ビッドを禁止するため）。これに代えて、市場Ａのビッドに対してペッグされた注文があり、ＮＢＢＯが．１０×．１２で計算される場合、市場が動いてＮＢＢＯが．０９×．１１となり市場Ａが更新するのが間に合わなければ、ビッド．１０にペッグされた注文を有していることになる。このようにＨＦＴ参加者は、．１０で売り、即座に他市場において．０９で買うことを試みる。
【００３６】
１実施例において、ペッグされているリミット価格は、市場センタがアクセス可能な市場データを参照して定める。市場センタが連結市場データフィードを用いてＮＢＢＯを決定するとともに、ＨＦＴ参加者１０２ｃが市場センタと同じ位置に配置され専用市場データフィード（例えば専用のもの、またはＥｘｅｇｙ、Ｒｅｄｌｉｎｅ、Ｗｏｍｂａｔなどの３ｒｄパーティーｔｉｃｋｅｒ  ｐｌａｎｔｓのもの）を用いる場合、ＨＦＴ参加者１０２ｃは市場センタがＮＢＢＯアップデートを処理する前に、ＮＢＢＯアップデートを処理し、注文を送信し、ミッドポイントペッグ注文を実行（例えば１１４参照）することができる。
【００３７】
例えばＮＢＢＯが．１０×．１２から．０８×．１０に変化した場合、ＨＦＴ参加者１０２ｃはミッドポイントリミット売り注文を即座に送信して．１１（元のＮＢＢＯのミッドポイント）で実行することを試みることにより、そのオーダブックストラテジ１３０を実行する。データフィードが遅い市場センタがＮＢＢＯ変化を未だ知らない場合、ＨＦＴ１０２ｃミッドポイント売り注文に対してミッドポイントペッグ買い注文を取引する可能性がある。このときの価格は最新ＮＢＢＯよりも劣っている。よってペッグ注文は、現在のＮＢＢＯの外で実行され、注文の意図から外れることになる。市場センタがＨＦＴ参加者と同じＮＢＢＯアップデートを有していれば、ペッグ注文は新たなＮＢＢＯのミッドポイント（．０９）に再値付けされ、ＨＦＴ参加者はペッグ注文を実行できない。このアービトラージストラテジは、その他注文タイプのアドバンテージを得るため同様に用いられる場合もある。例えば更新後ＮＢＢＯよりも積極的に値付けされるが従前はＮＢＢＯの範囲内であった“ｈｉｄｄｅｎ”注文である。
【００３８】
１実施例において、ＴＬＬは図１Ａと同様のインフラを採用し、オーダブックアービトラージを抑制することができる。例えば取引注文は市場センタに対して直接送信されない。代わりに取引注文はＰＯＰ１１０に対して送信され、ここから市場センタに対して送信される。一方で市場センタは、直接専用データフィードを用いて自身の市場データを更新する。このように全ての市場参加者１０２ｂはＮＢＢＯアップデート１１７を受け取ることができ、自身の取引端末インターフェース１１９を介して最新のミッドポイントペッグデータに基づきビッド／オファー要求を実行することができる。
【００３９】
例えばＨＦＴ参加者１２１が市場データアップデート１３５を受け取り処理する時間がｔａであり、ＨＦＴ参加者１２１がアービトラージストラテジ注文を市場センタに対して送信する時間がｔｂであり、市場センタが市場データアップデートを受け取り処理する時間がｔｃである場合、ＨＦＴ参加者１０２ｃはｔａ＋ｔｂ＜ｔｃが成り立つ限りアービトラージを実施できる。ＨＦＴ参加者１０２ｃがｔａとｔｂをｔｃに対して減少させる手法は様々ある。例えば市場データは、全市場センタからのデータを含む連結市場データフィードを介して配信されるが、各市場センタは自身の取引と値付けデータの専用データフィードも提供する。連結プロセスの性質により、連結市場データフィードは一般に専用フィードと比較して遅延する。よって市場センタが連結市場データフィードを用い、ＨＦＴ参加者１０２ｃが専用フィードを用いる場合、ｔａは遅延がなくｔｃよりも遥かに小さい。ｔｂも“同一場所”によって減少させることができる。例えばＨＦＴ参加者１０２ｃは、自身のサーバを市場センタに対して物理的に近い場所に配置し、送信時間の遅延を抑制することができる。
【００４０】
１実施例において市場センタは、ｔｃを減少させてアービトラージストラテジが起こり得る不均衡性を反転させることを試みる。これは専用フィードとより高速な技術を用いて実施される。しかし技術の進歩速度は速いので、結果として参加者と市場センタがレイテンシーを相手方の最新進歩よりも小さくすることを続ける、終わりのない“せめぎ合い”が起こるに過ぎない。よってこれは市場センタにとってコスト効率のよいビジネス戦略ではない。したがって多くはＨＦＴ参加者の技術と競争することを試みることはない。代わりにＴＬＬは、ｔｃを抑制するコスト高な技術競争ではなくｔｂを増やすことによりアービトラージ機会をなくすインフラを、例えばＰＯＰを介して提供する。
【００４１】
１実施例において、ｔｂはＰＯＰ１１０から市場センタへのレイテンシーにより増え、ｔａ＋ｔｂ＞ｔｃとなる。よって図１Ｂで説明したオーダブックアービトラージストラテジのようなアービトラージ戦略は、このインフラにおいては有効性が格段に低い。ＨＦＴ参加者がデータアップデートを処理して市場センタに対し注文を送信するのにかかる時間は、少なくとも専用データフィードからＰＯＰ１１０までのレイテンシーと、ＰＯＰ１１０から市場センタまでのレイテンシーとの合計となる。これら２つのレイテンシーの合計は、専用データフィードから市場センタへの直接ルートのレイテンシーよりも大きいので、市場センタは同じデータに基づきＨＦＴ参加者から注文を受け取る前に、新たなデータを受け取り処理することができる。よって市場センタは、ＨＦＴ参加者とシステム速度で競争することなしに、ＨＦＴ参加者がオーダブックアービトラージを実施する能力を大幅に減殺することができる。
【００４２】
図１Ｃは、ＴＬＬの実施形態においてアービトラージを抑制するＴＬＬ  ＰＯＰメカニズムのインフラ例を示す比較図である。１実施例において、図１Ｃ（ａ）に示すように、ＴＬＬ／ＰＯＰインフラがない場合、ＨＦＴ参加者１２１は、市場データが生成され配信されるデータ取引所１２２ａ−ｂに近いかまたは同じ場所に位置しており、取引注文は取引所Ａ１２２ａや取引所Ｂ１２２ｂで実行される。
【００４３】
例えばブローカ１２５が、クライアント１３０（例えばＨＦＴではない取引主体）に代わって取引注文１３１をデータセンタ１  １２０ａにおける取引所１２２ａに対して送信し、第２注文１３２をデータセンタ２  １２０ｂにおける取引所１２２ｂに対して送信したものとする。物理的位置のアドバンテージにより、ＨＦＴ１２１はブローカ１２５が送信した注文１３１に関する注文実行情報１３１を含む市場データ１３５を、取引所１２２ａから受け取ることができる。ＨＦＴ１２１は内部的にこの情報と同期し、市場データに対して反応することができる。例えばＨＦＴ１２１は、注文１３１の実行に関して取得した情報に基づき、注文３を生成し、および／または取引所Ｂ１２２ｂにおけるペンディング注文をキャンセル（１３３）する。したがって、ブローカ１２５とデータセンタ２  １２０ｂとの間の距離に起因して、ＨＦＴ１２１は注文１  １３１が実行された後、注文２  １３２が取引所Ｂ１２２ｂに到着する前に、更新後の市場情報に対して行動することができる。これにより注文２  １３２は、古くなった市場データに基づく不利益な取引注文（例えば注文１が実行される前）となる。
【００４４】
他実施例において、図１Ｃ（ｂ）に示すＴＬＬ  ＰＯＰインフラにより、ＴＬＬは注文受領と市場データフィードの公開ソースを、市場の実行センタ１２２ａから分離することができる。１実施例において、全ての取引注文はＰＯＰアクセスポイント１１０に対して送信しなければならず、ＰＯＰは取引注文を取引所実行ＴＬＬ１２２ａに対して送信する。例えばブローカ１２５は、注文１  １３１をＰＯＰ１１０に対して送信し、ＴＬＬにおいて注文１３１を実行する。１実施例においてＴＬＬは、市場データ１３５（例えば注文１の実行を反映した更新後データを含む）をＰＯＰ１１０経由で配信し、ＰＯＰ１１０はその市場データ１３５をＨＦＴ１２１に対して引き渡す。
【００４５】
１実施例において、注文１  １３１の実行を反映した更新後市場データ１３５をＨＦＴ１２１がＰＯＰ１１０経由で取得すると、ＨＦＴ１２１が市場変化に対して即座に反応したとしても、ＨＦＴ１２１は注文をデータセンタ２  １２０ｂにおける取引所１２２ｂに対してルーティングすることになる。このように、余剰送信時間、例えばデータセンタ１におけるＨＦＴ１２１からデータセンタ２におけるＨＦＴ１２１に対する送信時間により、ＨＦＴ注文のレイテンシーが増加する。注文１の実行１３１を反映した市場データ１３５に基づきデータセンタ２  １２０ｂにおけるＨＦＴ１２１が注文３  １３３を送信および／またはキャンセルすることができる時刻までに、ブローカ１２５の注文２  １３２はデータセンタ２  １２０ｂに到着し（例えば注文２  １３２は、ＴＬＬにおいて実行することを意図してないので、データセンタ１２０ｂに対して直接送信される）、取引所Ｂ１２ｂにおいて実行される。よって注文３は、注文２  １３２に対する更新後市場データの観点から何らアドバンテージを有さない。
【００４６】
例えばブローカ１２５からデータセンタ２  １２０ｂまで注文２  １３２を送信する時間は８９ｍｓであり；ＰＯＰアクセスポイント１１０によって生じる送信時間レイテンシー（例えば追加ケーブル長、回路抵抗など）は、市場データ１３５をＴＬＬ１２２ａからＰＯＰ１１０、さらにＨＦＴ１２１へ送信する時間３０ｍｓを含み；ＨＦＴ２１からデータ取引所Ｂ  １２２ｂへの送信時間は６０ｍｓであるとすると、合計レイテンシーは９０ｍｓとなる。１実施例において、ＰＯＰおよび／またはＴＬＬは、注文が送信されおよび／または受信されたタイミングを推測し、測定し、および／またはシグナリングする必要はない。代わりにＰＯＰの物理構成は、上述の追加レイテンシーを生じさせる。したがって注文３は、注文２が到着した後に取引所Ｂへ到着する。
【００４７】
図１Ｄは、ＴＬＬの実施形態において注文予測におけるレイテンシーアービトラージを抑制する別実施例を示す。１実施例において、ＴＬＬ１２２ａは最新市場に基づき注文を動的にルーティングする。ＴＬＬ１２２ａから取得した市場データ１３５は、最終取引フィードを含む。ＨＦＴ１２１はこれを利用して注文を予測する。例えば図１Ｄ（ｂ）に示すように、ＨＦＴ１２１がＴＬＬ１２２ａから市場データ１３５を取得して最新実行済注文を得たとき、ＴＬＬ１２２ａは注文１３４を他のデータセンタ（例えばデータセンタ２  １２０ｂ）へルーティングするので、ＨＦＴ１２１はデータセンタ２  １２０ｂにおけるデータ取引所１２２ｂにルーティングされ実行される注文１３４を予測することができる。ＰＯＰアクセスポイント１１０がない場合、図１Ｄ（ａ）に示すように、ＨＦＴ１２１はルーティングされた注文１３４に対して有利な注文１３３を即座に生成し、その注文１３３をデータ取引所１２２ｂに対して送信する。これによりルーティングされた注文１３４は不利益となる。例えば注文１３４に含まれているビッド／オファーは成功せず、不利な価格で実行される。
【００４８】
他実施例において、図１Ｄ（ｂ）に示すように、ＰＯＰアクセスポイント１１０がある場合、注文１の実行によるアップデートを含む市場データ１３５はＰＯＰ１１０に対して送信され、ＰＯＰ１１０は市場データ１３５をＨＦＴ１２１に対して送信する。ルーティングされた注文１３４に対して有利となるようにＨＦＴが生成した注文１３３は、データ取引所１２２ｂに対してルーティングする必要がある。ＰＯＰ１１０を介してＨＦＴ１２１に対して最新市場データ１３５を配信するレイテンシーおよび／または注文１  １３３の送信時間により、注文１３３がデータ取引所１２２ｂに到着する時刻までに、注文１３４はデータ取引所１２２ｂに到着し実行され、よって不利益とはならない。
【００４９】
図１Ａ〜図１Ｄで説明した例は、ＨＦＴ市場参加者と非ＨＦＴ市場参加者を示しているが、これらレイテンシーアービトラージおよび／またはオーダブックアービトラージは、ＨＦＴ参加者および／または非ＨＦＴ参加者の任意の組み合わせ間で生じ得ることに留意されたい。ＰＯＰハードウェアアクセスポイントは、様々な市場参加者に対して適用することができる。レイテンシーアービトラージとオーダブックアービトラージを管理する例と様々なシナリオについては、図６Ａ〜図６Ｈで説明する。
【００５０】
図２は、ＴＬＬの実施形態におけるＴＬＬサーバ２２０とＰＯＰ２１０との間のデータフロー、ＴＬＬ市場データ配信および取引注文実行の提携取引主体を示すデータフロー図である。実施形態において、ＴＬＬサーバ２２０、その提携および／または独立ＰＯＰ２１０、市場センタ２４０、市場参加者２０２ａ−ｎ、ＨＦＴ参加者２０２ｘ、ＴＬＬデータベース２１９、などは、通信ネットワーク（例えばインターネット、通信ネットワーク、決済処理ネットワーク、電話ネットワーク、携帯ネットワーク、無線ローカルエリアネットワーク、３Ｇ／４Ｇネットワークなど）を介して市場データアップデートおよび／または取引注文リクエストを相互通信する。
【００５１】
１実施例において、様々な市場参加者２０２ａ−ｎは、市場センタ２４０と通信して例えばビッドリクエストおよび／またはオファーリクエスト２０１ａ−ｂなどの取引注文を実施する。１実施例において、市場参加者は個人投資家、ブローカ、ポートフォリオマネージャ、などを含むが、これに限らない。１実施例において、注文データ２０１ａ−ｂは市場参加者２０２ａ−ｂから市場センタ２４０に対して直接送信されず、上述のようにＰＯＰ２１０を介してルーティングされる。
【００５２】
１実施例において、市場センタ２４０は１以上の集中および／または分散電子取引プラットフォームおよび／または市場取引所を備える。例えばＮＡＳＤＡＱ、ＮＹＳＥ、ＢＡＴＳ、Ｄｉｒｅｃｔ  Ｅｄｇｅ、Ｅｕｒｏｎｅｘｔ、ＡＳＸなどを含むが、これに限らない。１実施例において、市場センタ２４０はビッド／オファーデータフィード２０４を取得およびアップデートし、その市場データアップデート２０６を参加者に対して提供する。１実施例において、市場データアップデート２０６は、ＨＦＴ参加者２０２ｘに対して直接提供される専用フィードを含む。リアルタイム市場データフィードは、ＣＳＶファイルフォーマット、ＩＴＣＨプロトコルを介したもの、および／またはその他電子取引プロトコルによるものを含む。これは様々な金融データベンダからのデータフィードを含む。例えば、Ｇｏｏｇｌｅ、Ｋｎｏｅｍａ、Ｎｅｔｆｏｎｄｓ、Ｏａｎｄａ、Ｑｕａｎｄｌ、Ｙａｈｏｏ、Ｘｉｇｎｉｔｅなどを含むが、これに限らない。１実施例において、ＨＦＴ参加者２０２ｘはＣＳＶファイルをパースして市場データ情報を取得する。ＱｕａｎｄｌからのＣＳＶファイルをテストする疑似コードセグメントは、例えば以下のようなものである：
【数１】
2020205075.tif 000003
【００５３】
他実施例において市場センタ２４０は、ＨＦＴ参加者２０２ｘのための市場データフィードを含む（Ｓｅｃｕｒｅ）Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ（Ｓ））ＰＯＳＴメッセージを、ＸＭＬ形式でフォーマットしたデータの形態で生成する。ＸＭＬ形式データを含むＨＴＴＰ（Ｓ）ＰＯＳＴメッセージの形態の市場データフィード２０６のリスト例を、以下に示す：
【数２】
2020205075.tif 000004
【００５４】
１実施例においてＨＦＴ参加者２０２ｘは、市場データフィード２０６を取得すると、自身の取引ストラテジに基づき取引注文２０７を生成する。例えば最新のビッド／オファー価格に基づくビッドリクエストなどである。そして注文を送信するためＰＯＰを検索／照会する。例えば１実施例において、ＴＬＬは、参加者の地理的位置、意図する取引交換タイプなどに基づき、取引注文をＰＯＰに対してルーティングする。例えばＨＦＴ参加者２０２ｘは、データベーステーブル（例えば図６のＰＯＰ９１９ｃ）に対してＰＨＰ／ＳＱＬコマンドを発行してＰＯＰをクエリする。ＨＦＴ参加者の位置と意図する取引交換に基づきＰＯＰ２１０をクエリするＰＯＰクエリ２０７の例を、ＰＨＰ／ＳＱＬコマンドの形態で以下に示す：
【数３】
2020205075.tif 000005
【００５５】
ＨＦＴ参加者２０２ｘは、ビッド／オファーリクエスト２０９を送信し、そのリクエストはＰＯＰ２１０に配信される。例えばビッド／オファー六エスト２０９を含む取引注文は、図４Ｂのような電子取引ユーザインターフェースを介して個人によって入力される。他実施例において取引注文は、ブラックボックス取引システム、注文エントリ（例えばＦＩＸプロトコル）、自動データ取引センタなどを介して入力される。ビッド／オファーリクエストメッセージ２０９のリスト例を、ＸＭＬ形式データの形態で以下に示す：
【数４】
2020205075.tif 000006
【００５６】
１実施例において、ＰＯＰ２１０は例えば地理的近さに基づき市場センタ２４０と同じ場所に収容される。他実施例においてＰＯＰ２１０は、集中ＴＬＬサーバ２２０に統合される。例えば全ての取引注文は、市場センタ２４０に対してルーティングされ実行される前に、リモートのＰＯＰ／ＴＬＬサーバに対してルーティングされる。
【００５７】
１実施例において、ＰＯＰ２１０はＨＦＴ参加者２０２ｘ（および／またはその他参加者）からビッド／オファーリクエスト２０９を受け取ると、その注文リクエスト２１１をＴＬＬ２２０に対して引き渡す。ＴＬＬ２２０はその注文リクエストを市場センタ２４０に対して実行のためルーティングする。１実施例において、他の市場参加者２０２ａ−ｎは例えば物理的位置が市場センタ２４０から離れており、および／または比較的遅い連結市場フィードを受け取る。他の市場参加者２０２ａ−ｎは、市場データアップデート２１２ａ−ｂを受け取る。１実施例において、市場参加者２０２ｎは同様にビッド／オファーリクエスト２１４を送信する。これらリクエストはＰＯＰ２１０に対してルーティングされる。
【００５８】
１実施例においてＰＯＰ２１０は、ケーブル接続などの通信リンクを介して受信したビッド／オファーリクエスト（例えば２０９、２１４など）を受け取り、ビッド／オファーデータ２１５を含むその取引注文をＴＬＬ２２０に対して送信し、および／またはその地取引注文はＴＬＬから市場センタ２４０（例えば他の取引所）に対してルーティングされる。１実施例において、取引注文２１５は例えば疑似同期してバッチ送信される。他実施例においてＰＯＰ２１０は、ビッド／オファーデータ２１５を市場センタ２４０に対して送信する“時間”を“ホールド”および／または予測する必要はない。ＰＯＰ２１０における通信媒体（例えばケーブル、マイクロ波など）を介した再ルーティングは本質的にレイテンシーを生じさせ、ＨＦＴ参加者２０２ｘからの取引注文２０９は他の参加者２０２ａ−ｎからの取引注文２１４に対してアービトラージを実施できないからである。
【００５９】
１実施例において、ＴＬＬ２２０および／または市場センタ２４０は、受信した注文２１６を実行し、ビッド／オファーがマッチングすれば取引を進める。１実施例においてＴＬＬは、ＴＬＬサーバ２２０がＴＬＬデータベース２１９に格納する取引レコード２１８（例えばＴＬＬ２２０が実行した取引、および／または他の市場センタ２４０において実行された取引に関する情報）を生成する。１実施例においてＰＯＰ２１０は、取引注文がＰＯＰを介して引き渡されると取引レコード２１８にタイムスタンプを付与する。例えば取引レコード２１８は、アービトラージを抑制することに成功したか否かをＴＬＬサーバ２２０が分析するための、ＨＦＴ注文およびその他市場参加者２０２ａ−ｎからの注文に関するタイミングパラメータを含む。レコード２１８は周期的に生成することもできるし、間欠的および継続的に生成することもできるし、および／またはＴＬＬサーバ２２０からのリクエストにより生成することもできる。
【００６０】
取引レコード２１８のリスト例を、ＸＭＬ形式のデータで以下に示す：
【数５】
2020205075.tif 000007
【００６１】
図３は、ＴＬＬの実施形態においてＰＯＰルーティングによりレイテンシーアービトラージを抑制するロジックフローである。実施形態において、様々な市場参加者は注文リクエストを市場センタに対して送信する（例えば３０１）。この注文リクエストは市場センタに対して直接送信され、および／または図２で説明したようにＰＯＰに対して送信された後にＴＬＬへ引き渡される。１実施例において、市場センタは注文リクエスト３０２を受け取ると、現在のビッド／オファー価格リストを更新する（３０４）。別実施例において市場センタは、ビッド／オファー価格リストデータをデータ取引所から取得する（例えばＮＢＢＯ）。
【００６２】
１実施例において市場センタは、様々な市場参加者に対してデータフィードを提供する。この市場参加者は、ＨＦＴ参加者および／または非ＨＦＴ参加者を含む。１実施例において、図１Ｂで説明したように、ＨＦＴ参加者は専用フィードを受け取るとき市場アップデートを速く受け取り（３０６）、受け取った専用フィードに基づき取引注文を生成する（３０７）。ＨＦＴ参加者は取引リクエストを送信する（３０９）。ＰＯＰアクセスポイントはこれを受け取り、ＨＦＴ参加者の物理的位置、取引リクエストに含まれる金融商品タイプ、所望する取引所などに基づき、レイテンシーを生じさせる（３１０）。１実施例においてＰＯＰは、取引リクエストをＴＬＬに引き渡し、ＴＬＬは注文を受け取ってルーティングし（３１１）、ＨＦＴ参加者からの注文リクエストを保持する必要はない。１実施例においてＴＬＬは、取引注文を実行し、および／または他のデータセンタへルーティングすべきか否かを判定する（３１２）。ルーティングしない場合は注文を実行する（３１９）。
【００６３】
別実施例において、他の市場参加者（例えば非ＨＦＴ参加者）は、例えば連結市場データフィードを介して市場アップデートを受け取る（３１３）。この市場アップデートは相対的にレイテンシーを有している。１実施例において市場参加者は、ビッド／オファーリクエストを含む取引注文を生成してこれをＴＬＬ  ＰＯＰに対し送信する（３１４）。別実施例において、市場センタの物理的近くにない非ＨＦＴ市場参加者のため、ＴＬＬは取引注文をＰＯＰに対して送信するよう要求することもできるし、しないこともできる。
【００６４】
１実施例において、ＴＬＬ／ＰＯＰが取引注文を手放すと（３１２）、市場センタはこれを受け取り実行する（３１５）。例えば市場センタは、注文をパースして金融商品ＩＤ、ビッド／オファー価格を取得し、ビッドが成功するか否かを判定する（３１６）。成功である場合、市場センタは取引を進め、新取引に基づき現在のビッド／オファー価格リストを更新する（３１７）。
【００６５】
１実施例において、ＴＬＬ／ＰＯＰはＰＯＰレコードを生成する（３１８）（例えば図２の２１８参照）。ＰＯＰレコードは、注文ルーティングとレイテンシーのタイミングパラメータを記録し、アービトラージ抑制性能を分析するために用いることができる。
【００６６】
図４Ａ〜図４Ｂは、ＴＬＬの実施形態におけるＴＬＬ  ＰＯＰルーティングシステム設定および／または顧客設定を示すＵＩの例である。図４Ａは、ＰＯＰ配置の管理ＵＩである。例えば１実施例において、ＴＬＬ管理者はＰＯＰの分布４１１を目視確認する。これは例えばｚｉｐコードおよび／またはエリアコード４１２によって配置されている。１実施例において、図４Ａに示すように、ＴＬＬダッシュボードは当該領域における各ＰＯＰの位置、およびＰＯＰに関する詳細を提示する。例えばサーバＩＰ、住所、取引所／市場までの距離（送信時間）、などである。１実施例において、ＴＬＬ管理者はＨＦＴ参加者４１６を１以上のＰＯＰに対して割り当てる。この割り当ては例えば、ＨＦＴ参加者の地理的位置、取引量、取引パターン、所望する取引所、などに基づく。実施例において、ＴＬＬとその他市場参加者との間の距離は、ＰＯＰ位置を定める要因になり得る。他実施例において、この距離は考慮しないこともできる。ＰＯＰ“距離”はケーブル長などによって較正できるからである。ＰＯＰが他市場センタから遠くレイテンシーが過大に増え参加者の取引体験が過剰に補正される可能性がある場合、他市場センタに対するＰＯＰの位置は重要である。
【００６７】
例えばＴＬＬは、ＴＬＬ管理者ごとに異なるＰＯＰをセットアップすることができる。例えばＴＬＬは、ＮＹＳＥに対して向けられる注文に関してＮｅｗ  Ｊｅｒｓｅｙに配置されたＰＯＰをＨＦＴ参加者に対し割り当てることができる（４１７）。またＮＡＳＤＡＱに対して向けられる注文に関してＮｅｗ  Ｙｏｒｋに配置されたＰＯＰを割り当てることができる（４１８）。１実施例においてＴＬＬは、管理者にテスト配置させることができる。これは例えば、割り当てたＰＯＰから所望するデータ取引所までの推定送信時間を提示することにより実施する。
【００６８】
図４Ｂに示す実施例において、ブローカの顧客はｗｅｂベースダッシュボードアプリケーションにログインし、ポートフォリオをレビューする。例えば顧客は、ビッド／オファーフィードのリストを目視確認し（４０１）、または顧客投資プロファイル４０５を見て設定４０６〜４０７を変更する。
【００６９】
例えば顧客は、ブローカが設けた注文の執行に関する設定をセットしようとする場合がある。ブローカは一般に顧客の指示を順守する必要があるが、現在の市場においてブローカは顧客の注文をどのように実行するかについてある程度の裁量を有している。よってブローカの裁量により、顧客の最終指示とは異なる注文を市場に実行させる場合がある。
【００７０】
１実施例において、ＴＬＬはＵＩを提供し、ブローカの顧客が市場に対して直接的に裁量設定できるようにする（４０７）。これら設定は、以下の要因の１以上に基づき顧客がいつ取引を所望するかを示す：シンボル、市場資本、過去のスプレッドと比較した現在のスプレッド、提示されている流動性、関連商品価格、ストラテジタイプ、平均日中取引量、平均日中取引量と比較した注文サイズ、最小フィルサイズ、想定元本、価格、最少取引サイズ、裁量価格、および／または注文タイプ、など。
【００７１】
１実施例において、顧客はブローカに対して、顧客ＩＤとともに注文を市場へルーティングするよう指示する。市場はそのＩＤを認識し、顧客が先にセットした裁量設定と注文をマッチングし、注文を実行する際に顧客の裁量設定を順守する。これによりブローカが顧客の注文指示から逸脱する権限を除去できる。すなわち、専門用語が不明確でありその結果注文が顧客のブローカに対する指示または顧客の関心事に反することを回避できる。
【００７２】
例えば顧客は、設定４１６〜４１８において“Ｓｙｎｔｈｅｔｉｃ  ａｌｌ  ｏｒ  ｎｏｎｅ”注文タイプを設定する。１実施例において、電子取引注文は“ａｌｌ−ｏｒ−ｎｏｎｅ”（ＡＯＮ）で実行される。すなわち、注文全体のリクエストを満たすだけの十分な流動性がある場合のみ実行される。注文の一部のみ満たす流動性しかない場合、ＡＯＮ注文はその全体が実行されない。ＡＯＮではない注文はその流動性の下でも実行され、一部が充足されない場合がある。１実施例において、この注文タイプの制約は、単一市場における流動性に対してのみ実行されることである。例えばＡＯＮ注文は、２以上の市場からの流動性を満たすように実行されることはない。
【００７３】
１実施例において、ＴＬＬは“Ｓｙｎｔｈｅｔｉｃ  ＡＯＮ”注文タイプを実行する。例えばこの注文タイプの場合、市場参加者は最小実行量と注文実効価格を指定することができる。ＴＬＬは、当該ＴＬＬ自身に対して提示されている流動性と提示されていない流動性、および当該ＴＬＬが注文をルーティングするその他全ての取引場所に対して提示されている流動性に対して、この最小量を実行可能か否か判定する。市場参加者が指定した価格よりも不利益ではない価格で注文を実行できるだけの連結流動性がある場合、ＴＬＬは注文を部分的に実行し、一部を他の取引場所へルーティングする。これにより、注文の実行した部分とルーティングされた部分が、指定された最小量を満たすようにする。ルーティングされた注文のうち１以上は、部分的に充足され、またはまったく充足されない場合がある。したがって、従来のＡＯＮ注文タイプとは異なり、Ｓｙｎｔｈｅｔｉｃ  ＡＯＮ注文は“ベストエフォート”で実行される。ＴＬＬが最初に実行した取引がルーティングされた注文の実行に対して与える影響を最小化し、ＴＬＬ実行をシグナルとして用いてＴＬＬがルーティングした注文を他の市場センタに急がせることにより他の参加者がＳｙｎｔｈｅｔｉｃ  ＡＯＮ注文タイプのアドバンテージを得る可能性を最小化するため、ＴＬＬは注文をルーティングするとき、ルーティングされた注文が十分遠くまで伝搬してその宛先に急がされる可能性が排除されるまで、ＴＬＬ注文実行に関する情報を市場参加者が受信できないようにする。このプロセスは、上述のＰＯＰ設備を用いることを含む。１実施例において、完全に充足される保証はないものの、ＰＯＰ構造はＳｙｎｔｈｅｔｉｃ  ＡＯＮ注文の有効性を高める。
【００７４】
別実施例において、ＴＬＬは様々な要因に基づき注文をマッチングおよび／または優先付けする。この要因は例えば、価格、ディスプレイ、ブローカ、時間優先、などである。オーダブックにおける最良価格注文は、その他全ての注文に優先される場合がある。同一価格であれば、表示注文は非表示注文よりも優先される。価格と表示状態が同じである場合、当該ブローカの注文がオーダブックに対してテスト中であれば、ブローカの残注文は他のブローカの注文よりも優先される。ブローカ自身の注文のなかで、Ａｇｅｎｃｙマークされた注文はＰｒｉｎｃｉｐａｌマークされた注文よりも優先される。同一優先度レベルにおける全ての競合注文のなかで、最も古い注文が優先される。所与の価格において表示される注文のなかで、まずＡｇｅｎｃｙマークされた注文が時間優先され、注文が処理されると次に同一サブスクライバに属するＰｒｉｎｃｉｐａｌマークされた注文が時間優先され、次にその価格における他の表示注文が時間優先される。最古注文は高い優先度を有する。所与の価格における非表示注文のなかで、まずＡｇｅｎｃｙマークされた注文が時間優先され、次に同一サブスクライバに属するＰｒｉｎｃｉｐａｌマークされた注文が時間優先され、次にその価格における他の非表示注文が時間優先される。最古注文は高い優先度を有する。１実施例において、最小量などの特定の注文条件パラメータが、非表示注文やＩｍｍｅｄｉａｔｅ  Ｏｒ  Ｃａｎｃｅｌ（ＩＯＣ）注文に対して選択される。ＴＬＬのオーダブックにおいて優先度を有する残注文がその条件に起因して実行されない場合、その残注文はオーダブックにおけるそのプロセスサイクル時間に関する優先度を放棄する。
【００７５】
１実施例において、ＴＬＬがオーダブック上の残注文に対して再値付け、表示更新、ブック再チェック、またはルーティング動作（まとめて“ブック動作”）を実施するごとに、価格／時間優先度においてこれを実施する。このときのタイムスタンプは、時間優先度を決定するためのアクションを実施したときにおける注文の一部のタイムスタンプであり、このときの残価格は、価格優先度を決定するための当該注文またはその一部のオーダブック上における残価格である。
【００７６】
１実施例において、ＴＬＬが表示注文または予約注文の表示部分を再値付けするごとに、オーダブックの価格／時間優先度における時間を判定するため、ＴＬＬは注文（または注文の一部）に対して新たなタイムスタンプを割り当てる。
【００７７】
図５Ａ〜図５Ｃは、ＴＬＬの実施形態におけるＴＬＬネットワークインフラを示すデータ図である。１実施例において、ＴＬＬサブスクライバ５１０（例えば個人投資家、取引主体、および／または市場参加者）は、ＰＯＰアクセスポイントに接続されている。ＰＯＰアクセスポイントは例えば、ＦＩＸプロトコルを実施してＦＩＸエンジン５０７と通信するアクセスポイントである。１実施例において、ＰＯＰ  ＦＩＸ／ＣＵＳＴアクセスポイントは、取引エンジン５１５と同じデータセンタおよび／または別のデータセンタに配置されたハードウェア構造を備える。１実施例においてＦＩＸエンジン５０７は、ＦＩＸプロトコルを介してデータを送受信するロジック部品を備える。図５Ｃは、データメッセージパケット構造５１９ｄの例を示す。
【００７８】
例えばＴＬＬサブスクライバ５１０は、ＦＩＸ  ＡＰＩを通じてＴＬＬ（例えばデータ取引所そのものとして動作する）上で取引される商品を購入または売却する注文を電子送信する。１実施例において、サブスクライバはＴＬＬが提供するＦＩＸ  ＡＰＩに準拠する通信を介して、あるＩＰアドレスにおいてＴＬＬに対するダイレクトアクセスを利用することができる。
【００７９】
１実施例において、シーケンサ５０６はデータをパースし、取引エンジン５１５に対してデータを送信する。データメッセージパケット構造５１９ｃの例を図５Ｃに示す。１実施例において、取引データ（例えばビッド／オファーリクエスト）は取引ゲートウェイ５０５に対して送信され、取引所５０２において実行される。取引所５０２は例えば、ＮＹＳＥ５０２ａ、ＢＴＬＬ５０２ｂ、ＥＤＧＥ、ＣＨＳＸ、ＮＳＸ５０２ｃ、ＮＡＳＤＡＱ５０２ｄ、などである。１実施例において、ＴＬＬは取引データをデータベース５１９のストレージに対して送信する。１実施例において、ＴＬＬは内部ｗｅｂ５１１を介してデータフィードを配信するＣＮＣを介して取引データを配信し、および／またはＤＭＺを介して外部ｗｅｂ５１２においてデータフィードを配信する。図５Ｂは、データメッセージパケット構造５１９ａ−ｂの例を示す。
【００８０】
別実施例において、ＴＬＬは注文を他の市場センタ（例えば図１Ｄの１３４）へルーティングする際の様々なルーティングオプションを提供する。ルーティングオプションは、様々な注文タイプおよびＴＩＦと組み合わせることができる。ただし、ルーティングオプションの条件と整合しない注文タイプおよびＴｉｍｅ  ｉｎ  Ｆｏｒｃｅ（ＴＩＦ）を除く。実施例において、ＴＬＬは１以上のシステムルーティングテーブルを保持する。このテーブルは、システムが注文をルーティングする宛先となる取引場所を決定するためのものである。この注文は、他の取引場所に留まることを意図してルーティングされるものを含む。システムルーティングテーブルは、システムが注文をルーティングする手順も記述している。ＴＬＬは、複数のルーティングオプションについて複数のシステムルーティングテーブルを保持することができ、事前の通知なしでシステムルーティングテーブルを変更することができる。
【００８１】
例えばＴＬＬは、Ｒｏｕｔｅ  ｔｏ  Ｔａｋｅプロトコルを実装することができる。例えばそのルーティングオプションにおいて、利用可能な取引をオーダブック上でシステムがチェックし、未実行取引をｉｍｍｅｄｉａｔｅ−ｏｒ−ｃａｎｃｅｌ注文としてシステムルーティングテーブル上の宛先へルーティングする。ルーティング後も取引が未実行のままである場合、これらはオーダブック上に留め置かれる。オーダブック上において注文が他のアクセス可能な市場センタによりロックされまたは干渉された場合、システムはその注文がサブスクライバ（例えばクライアント、投資家など）によって再ルーティング可能である旨をマークされていれば、その注文またはその一部をロックまたは干渉した市場センタへルーティングする。
【００８２】
他実施例として、ＴＬＬはＲｏｕｔｅ  ｔｏ  Ｒｅｓｔプロトコルを実装することができる。このプロトコルにおいて、ＴＬＬシステムは利用可能な取引をオーダブック上でチェックし、未実行取引をｉｍｍｅｄｉａｔｅ−ｏｒ−ｃａｎｃｅｌ注文としてシステムルーティングテーブル上の宛先へルーティングする。ルーティング後も取引が未実行のままである場合、システムはＴＬＬルーティングテーブルの定義にしたがって、その注文の表示サイズをオーダブックと他取引場所との間で分割する。Ｐｒｅ−Ｍａｒｋｅｔ  ＳｅｓｓｉｏｎまたはＰｏｓｔ−Ｍａｒｋｅｔ  Ｔｒａｄｉｎｇ  Ｓｅｓｓｉｏｎの間にＴＬＬが実行する任意の取引について、適用可能注文価格は最高自動値付けビッドまたは最低自動値付けオファー（ＮＢＢＯ）と同額またはより有利でなければならない。ただし、注文がＩＳＯマークされ、または自動値付けビッドが自動値付けオファーとクロスしている場合は除く（あるいは、取引実行が他の条件に合致する場合、例えばＲｅｇｕｌａｔｉｏｎ  ＮＭＳ  規則６１１（ｂ）の例外に相当するような場合）。
【００８３】
１実施例において、サブスクライバ注文指示が反対指示しない限り、到着する注文はまずオーダブックにおいて実行マッチングされる。実行されない取引は、キャンセルされ、オーダブックに留め置かれる。あるいは、買い注文と売り注文がオーダブック上でマッチングし、または他取引場所にルーティングされた注文がその取引場所においてマッチングする場合は、ルーティング実行される。システムは、到着する注文を受け取った順に処理する。この注文は、ルーティング先の取引場所から戻ってきた注文またはその一部を含む。注文またはその一部が他の取引場所へルーティングされている間、その注文またはその一部はシステムの到着注文処理キューの一部ではなくなり、後続の注文が優先処理される。
【００８４】
オーダブックに対して送信された注文を実行する際、システムはサブスクライバが自身のアカウントから送信した注文と、サブスクライバがその顧客のために送信した注文との間の区別ができない場合がある。ただしブローカ優先機能を除く。ブローカ優先において、残りのＡｇｅｎｃｙ注文は残りのＰｒｉｎｃｉｐａｌ注文よりも優先される。
【００８５】
１実施例において、サブスクライバはリモートからシステムに対して注文を送信し、オーダブック上にある注文に対して同等のアクセスを有する。同様に、ＴＬＬ上の注文は自動実行されるので、サブスクライバは実行時刻を制御することができず、実行前に注文を変更またはキャンセルできるに過ぎない。オーダブックに対して送信された買い注文は、オーダブックに対して送信された同一商品の売り注文と同額または超える価格に値付けされ、注文を送信したサブスクライバが選択した条件が満たされるまで、システムにより自動実行される。この買い注文は、オーダブック上において優先権を有する最低価格の売り注文の価格で実行される。
【００８６】
１実施例において、オーダブックに対して送信された売り注文は、オーダブックに対して送信された同一商品の買い注文と同量またはそれ以下の量で値付けされ、注文を送信したサブスクライバが選択した条件が満たされるまで、システムにより自動実行される。この売り注文は、オーダブック上において優先権を有する最高価格の買い注文の価格で実行される。残注文のフルサイズ以下が実行されるとき、表示注文か非表示注文かによらず、注文の未実行サイズ部分はサブスクライバの指示に整合した状態でオーダブック上に残り、表示する場合はその価格で再表示される。この一部実行された注文は、同じ価格で優先権を保持する。オーダブックまたはＮＢＢＯが変更されたとき、または到着メッセージの処理の一部として、システムは注文を市場の片側または両側においてオーダブックの相殺側に対してテストし、ＴＬＬの変化の結果として新たに注文をｉｎｓｉｄｅ  ｍａｒｋｅｔまたはＮＢＢＯで実行できるか否かを判定する。最小量条件を有する非表示残注文、および／または現在オーダブック上にある価格よりも積極的なリミットは、最初に記録されたときは実行不能または注文条件を満たしていなかった更新後のオーダブックにおいて、取引可能となる。残注文は、それぞれの記録された価格／時間優先度にしたがって再チェックされる。オーダブックを再チェックする注文は、保護された値付けまたはオーダブックの相殺側の残注文を通じて取引されることはない。
【００８７】
ＴＬＬがＮＢＢＯと同額またはより有利な価格の商品を有していない場合、またはその実行可能な商品が品切れで未実行の商品のみが残っている場合、システムは到着した注文をルーティング適格に基づき処理する。ルーティングに適している旨がマークされ、ＮＢＢＯに対して取引可能な注文について、システムはこれをより有利な価格の保護値付けを表示する他の取引センタへルーティングする。このとき、サブスクライバ注文指示、注文タイプ、ルーティングストラテジ定義、“ＴＬＬルーティングテーブル”に準拠する。
【００８８】
図６Ａ〜図６Ｈは、ＥＢＯＭの実施形態において余剰データ送信レイテンシーを生じさせるネットワークアクセスポイントを通じてレイテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す。１実施例において市場参加者は、代替商品を取引する取引所（および／または他市場センタ）間のデータ送信レイテンシー差のアドバンテージを得る。１実施例において、ブローカが投資家に代わってＢｒｏｋｅｒ  Ｓｍａｒｔ  Ｏｒｄｅｒ  Ｒｏｕｔｅｒ（ＢＳＯＲ）を介して市場間で注文をルーティングする場合；または取引所がブローカと投資家に代わってＥｘｃｈａｎｇｅ  Ｓｍａｒｔ  Ｏｒｄｅｒ  Ｒｏｕｔｅｒ（ＥＳＯＲ）を介して市場間で注文をルーティングする場合、レイテンシーアービトラージが適用される。ただしこれに限らない。
【００８９】
図６Ａは、ＢＳＯＲを介して生じるレイテンシーアービトラージの例を示す。例えば取引所１  ６０５ａは、＄１０．００におけるＸＹＺ株の売り注文１０００株を有し、取引所２  ６０５ｂは＄１０．００におけるＸＹＺ株の売り注文２０００株を有する（取引所２  ６０５ｂのオファーは、ＨＦＴ６０６によって先に入力されたものである。全米最良価格は＄１０．００におけるＸＹＺ３０００株の連結オファーとなる）。
【００９０】
１実施例において、投資家６１４はＸＹＺ３０００株を＄１０．００で購入しようとし、ブローカ６１５に対してＸＹＺ３０００株を＄１０．００で購入する注文を送信する。投資家の注文を受け取ると、ブローカ６１５は買い注文Ａ６１３ａを取引所１  ６０５ａに対してルーティングしてＸＹＺ１０００株を＄１０．００で購入するとともに、買い注文Ｄ６１３ｄを取引所２  ６０５ｂに対してルーティングしてＸＹＺ２０００株を＄１０．００で購入する。注文Ａ６１３ａと注文Ｄ６１３ｄは、ブローカ６１４から取引所１  ６０５ａまでの物理的距離とブローカ６１４から取引所２  ６０５ｂまでの物理的距離に起因して、異なるレイテンシーを有する（よって、ケーブル、マイクロ波などの物理通信媒体に沿って異なる通信時間を有する）。接続性、ネットワーク機器、情報技術インフラ、ネットワーク回路抵抗、その他様々な要因により、送信時間の異なるレイテンシーが生じ得る。
【００９１】
１実施例において、ブローカ注文Ａ６１３ａは、取引所１  ６０５ａと投資家６１４（例えばブローカ６１４を通じて）に到着し、取引所Ａにおいて１０００株を＄１０．００で購入したことを示す。１実施例において、ＨＦＴは取引レポートＢ６１３ｂを取引所１  ６０５ａから受け取る。１実施例において、ＨＦＴが同一場所に配置されることにより、取引レポート６１３ｂを“数１０マイクロ秒”で受け取ることができる。１実施例においてＨＦＴは、取引所２  ６０５ｂに対して注文訂正Ｃ６１３ｃ（先に入力した＄１０．００におけるＸＹＺ２０００株に対する訂正）を送信する。ＨＦＴは、取引所１  ６０５ａにおいてＸＹＺ株が＄１０．００で取引された知識から利益を得ることを試みる。例えば他の買い注文（Ｄ）が取引所２  ６０５ｂへルーティングされることを予測し、注文Ｃ６１３ｃを＄１０．０１まで調整する。この例において、買いリミット＃１０．００の注文Ｄ６１３ｄは実行されず、ブローカは＄１０．０１で別注文を送信しなければならない。最終的に、取引所２  ６０５ｂにおいて新たな買い注文が実行されると、投資家６１４はＸＹＺの残り２０００株を購入するために＄２０．００をさらに支払うことになる（＄。０１＊２０００＝＄２０．００）。注文Ｃ６１３ｃのレイテンシーは、接続性と情報伝送方法（例えばマイクロ波ｖｓファイバ）によって定まる。このように、レイテンシー（Ａの送信時間＋Ｂの送信時間＋Ｃの送信時間）＜Ｄの送信時間であれば、ブローカ６１５（投資家６１４の代理）は取引所２  ６０５ｂにおいて＄１０．００でＸＹＺ２０００株の買い注文を実行できない。その結果、注文はその時点において充足されず、あるいは投資家６１４は残り２０００株を購入するためにより高い価格を支払わなければならない。
【００９２】
図６Ｂは、ＥＢＯＭの実施形態においてＰＯＰアクセスポイントを設置することによりレイテンシーアービトラージを管理する例を示す。１実施例において、取引所１  ６０５Ａは＄１０．００におけるＸＹＺ１０００株の売り注文を有し、取引所２  ６０５ｂは＄１０．００におけるＸＹＺ２０００株の売り注文を有している（取引所２  ６０５ｂにおけるものはＨＦＴ６０６によって先に入力されたものである。全米最良価格は＄１０．００におけるＸＹＺ３０００株の連結オファーとなる）。投資家６１４はＸＹＺ３０００株を＄１０．００で購入しようとし、ブローカ６１５に対してＸＹＺ３０００株を＄１０．００で購入する注文を送信する。ブローカ６１５は投資家６１４の注文を受け取り、買い注文Ａを取引所１  ６０５Ａに対してルーティングしてＸＹＺ１０００株を＄１０．００で購入するとともに、買い注文Ｄを取引所２  ６０５ｂに対してルーティングしてＸＹＺ２０００株を＄１０．００で購入する。注文Ａと注文Ｄは、ブローカ６１４から取引所１  ６０５ａまでとブローカ６１４から取引所２  ６０５ｂまでの物理的距離、接続性、ネットワーク機器、その他様々な要因に起因して、異なるレイテンシーを有する。接続性、ネットワーク機器、情報技術インフラ、ネットワーク回路抵抗、その他様々な要因により、送信時間の異なるレイテンシーが生じ得る。
【００９３】
ブローカ６１５の注文Ａ６１３ａは取引所１  ６０５Ａに到着し、投資家６１４は（ブローカ６１５を通じて）取引所１  ６０５Ａにおいて＄１０．００で１０００株を購入する。ＨＦＴ６０６は、ＰＯＰ６１０から取引レポートＢ６１３ｂを受け取る。ＥＢＯＭ  ＰＯＰアーキテクチャ  ＰＯＰ６１０により、ＥＢＯＭサブスクライバ（ＨＦＴ６０６を含む）は取引情報（Ａｉｉの送信時間＋Ｂの送信時間）を“数１００マイクロ秒”で受け取る。
【００９４】
１実施例において、ＨＦＴ６０６は先に入力した＄１０．００におけるＸＹＺ２０００株の売り注文の注文訂正Ｃ６１３ｃを、取引所２  ６０５ｂに対して送信する。ＨＦＴは、取引所１  ６０５ａにおいてＸＹＺ株が取引された知識から利益を得ることを試みる。例えば他の買い注文（Ｄ）が取引所２  ６０５ｂへルーティングされることを予測し、注文Ｃを＄１０．０１まで調整する。この例において、買いリミット＄１０．００の注文Ｄは実行されず、ブローカ６１５は別の買い注文＄１０．０１を送信しなければならない。最終的に、新たな買い注文が取引所２  ６０５ｂにおいて実行されると、投資家はＸＹＺ２０００株を購入するために＄２０．００を余分に支払うことになる（＄．０１＊２０００＝＄２０．００）。注文Ｃのレイテンシーは、接続性や情報送信方法（例えばマイクロ波ｖｓファイバ）によって定まる。
【００９５】
ただしＥＢＯＭ  ＰＯＰアーキテクチャＰＯＰ  ６１０により、ＥＳＯＲはレイテンシーアービトラージからクライアントの注文を保護する機会を得ることができる。これは、ＨＦＴ６０６が取引レポートＢを受け取ってシグナルとして用いる前に時間量に対してレイテンシー（距離または媒体により）を追加することによってなされる。（Ａの送信時間＋Ａｉの送信時間＋Ａｉｉの送信時間＋Ｂの送信時間＋Ｃの送信時間）＞Ｄの送信時間となるからである。この場合ブローカ６１５（投資家６１４の代理）は、ＨＦＴ６０６の注文訂正Ｃ６１３ｃが取引所２  ６０５ｂに到着する前に、取引所２  ６０５ｂにおいて＄１０．００でＸＹＺ２０００株の買い注文Ｄ６１３ｄを実行するだけの十分な時間を有する。その結果、注文Ａ６１３ａはリミット価格で完全に充足され、投資家６１４は図６Ａに示すように新たな買い注文を通じて残り２０００株を購入するためにより高い価格を支払う必要はない。
【００９６】
図６Ｃは、ＥＢＯＭの実施形態においてＥＳＯＲによって生じるレイテンシーアービトラージを示す図である。１実施例において、取引所１  ６０５ａは＄１０．００のＸＹＺ１０００株の売り注文を有し、取引所２  ６０５ｂは＄１０．００のＸＹＺ２０００株の売り注文を有している（取引所２  ６０５ｂにおける注文は、ＨＦＴ６０６によって先に入力されたものである。全米最良価格は＄１０．００のＸＹＺ３０００株の連結売り価格である）。投資家６１４は、ＸＹＺ３０００株を＄１０．００で購入しようとし、ブローカ６１５に対して＄１０．００でＸＹＺ３０００株の買い注文を送信する。ブローカ６１５は取引所１  ６０５ａのＳｍａｒｔ  Ｏｒｄｅｒ  Ｒｏｕｔｅｒ（ＥＳＯＲ）を使おうとし、注文を受け取った後、＄１０．００でＸＹＺ３０００株を購入する注文Ａ６１３ａ全体を取引所１  ６０５ａに対してルーティングする。取引所１  ６０５ａはこのとき、ブローカ６１５に代わって（投資家６１４のために）２０００株の買い注文Ｄ６１３ｄを取引所２  ６０５ｂに対してルーティングする役割を担う。
【００９７】
１実施例において、ブローカ６１５の注文Ａ６１３ａは取引所１  ６０５ａに到着し、投資家６１４は（ブローカ６１５を通じて）取引所１  ６０５ａにおいて＄１０．００で１０００株を購入する。注文を実行した後、取引所１  ６０５ａは取引所１  ６０５ａのＥＳＯＲを用いて、残り２０００株の買い注文Ｄ６１３ｄを取引所２  ６０５ｂに対してルーティングする。
【００９８】
１実施例においてＨＦＴ６０６は、取引所１  ６０５ａから取引レポートＢ６１３ｂを受け取る。１実施例において、同一場所に配置されていることにより、ＨＦＴ６０６は取引レポートＢ６１３ｂを“数１０マイクロ秒”で受け取ることができる。ＨＦＴ６０６は取引所２  ６０５ｂに対して注文訂正Ｃ６１３ｃ（先に入力した、＄１０．００でＸＹＺ２０００株を売る注文に対する訂正）を送信する。ＨＦＴ６０６は、取引所１  ６０５ａにおいてＸＹＺ株が取引された知識から利益を得ることを試みる。例えば他の買い注文（Ｄ）が取引所２  ６０５ｂへルーティングされることを予測し、注文Ｃを＄１０．０１まで調整する。この例において、買いリミット＄１０．００の注文Ｄ６１３ｄは実行されず、ブローカ６１５は別の買い注文＄１０．０１を送信しなければならない。最終的に、新たな買い注文が取引所２  ６０５ｂにおいて実行されると、投資家は残りのＸＹＺ２０００株を購入するために＄２０．００を余分に支払うことになる（＄．０１＊２０００＝＄２０．００）。注文Ｃ６１３ｃのレイテンシーは、接続性や情報送信方法（例えばマイクロ波ｖｓファイバ）によって定まる。
【００９９】
１実施例において、レイテンシー（Ａの送信時間＋Ｂの送信時間＋Ｃの送信時間）＜Ｄの送信時間である場合、ブローカ６１５（投資家６１４の代理）は取引所２  ６０５ｂにおいて＄１０．００でＸＹＺ２０００株の買い注文を実行できない。その結果、注文はその時点で充足されず、または投資家６１４は新たな買い注文を通じて残り１０００株を購入するためにより高い価格を支払わなければならない。
【０１００】
図６Ｄは、ＰＥＢＯＭの実施形態においてＯＰアクセスポイントを備えるＥＳＯＲを介してレイテンシーアービトラージを管理する例を示す。１実施例において、取引所１  ６０５ａは＄１０．００のＸＹＺ１０００株の売り注文を有し、取引所２  ６０５ｂは＄１０．００のＸＹＺ２０００株の売り注文を有する（取引所２  ６０５ｂにおける注文は、ＨＦＴ６０６によって先に入力されたものである。全米最良価格は＄１０．００のＸＹＺ３０００株の連結売り価格である）。
【０１０１】
１実施例において、投資家６１４は、ＸＹＺ３０００株を＄１０．００で購入しようとし、ブローカ６１５に対して＄１０．００でＸＹＺ３０００株の買い注文を送信する。１実施例において、ブローカ６１５は取引所１  ６０５ａのＳｍａｒｔ  Ｏｒｄｅｒ  Ｒｏｕｔｅｒ（ＥＳＯＲ）を使おうとし、注文を受け取った後、＄１０．００でＸＹＺ３０００株を購入する注文Ａ６１３ａ全体を取引所１  ６０５ａに対してルーティングする。取引所１  ６０５ａはこのとき、ブローカ６１５に代わって残り２０００株の買い注文Ｄ６１３ｄをルーティングする役割を担う。
【０１０２】
１実施例において、ブローカ６１５の注文Ａ６１３ａは取引所１  ６０５ａに到着し、投資家６１４は（ブローカ６１５を通じて）取引所１  ６０５ａにおいて＄１０．００で１０００株を購入する。注文を実行した後、取引所１  ６０５ａは取引所１  ６０５ａのＥＳＯＲを用いて、注文Ｄ６１３ｄを取引所２  ６０５ｂに対してルーティングする。ＨＦＴ６０６は、取引所１  ６０５ａから取引レポートＢ６１３ｂを受け取る。１実施例において、同一場所に配置されていることにより、ＨＦＴ６０６は取引レポートＢ６１３ｂを“数１０マイクロ秒”で受け取ることができる。ＨＦＴ６０６は取引所２  ６０５ｂに対して注文訂正Ｃ６１３ｃ（先に入力した、＄１０．００でＸＹＺ２０００株を売る注文に対する訂正）を送信する。ＨＦＴ６０６は、取引所１  ６０５ａにおいてＸＹＺ株が取引された知識から利益を得ることを試みる。例えば他の買い注文（Ｄ）が取引所２  ６０５ｂへルーティングされることを予測し、注文Ｃを＄１０．０１まで調整する。この例において、買いリミット＄１０．００の注文Ｄ６１３ｄは実行されず、ブローカ６１５は＄１０．０１で別の買い注文を送信しなければならない。このように、投資家は残りのＸＹＺ株を購入するために＄２０．００を余分に支払うことになる（＄．０１＊２０００＝＄２０．００）。注文Ｃ６１３ｃのレイテンシーは、接続性や情報送信方法（例えばマイクロ波ｖｓファイバ）によって定まる。
【０１０３】
ただしＥＢＯＭ  ＰＯＰアーキテクチャＰＯＰ  ６１０により、ＥＳＯＲはレイテンシーアービトラージからクライアントの注文を保護する機会を得ることができる。これは、ＨＦＴ６０６が取引レポートＢを受け取ってシグナルとして用いる前に時間量に対してレイテンシー（距離または媒体により）を追加することによってなされる。（Ａの送信時間＋Ａｉの送信時間＋Ａｉｉの送信時間＋Ｂの送信時間＋Ｃの送信時間）＞Ｄの送信時間となるからである。この場合ブローカ６１５（投資家６１４の代理）は、ＨＦＴ６０６の注文訂正Ｃ６１３ｃが取引所２  ６０５ｂに到着する前に、取引所２  ６０５ｂにおいて＄１０．００でＸＹＺ２０００株の買い注文Ｄ６１３ｄを実行するだけの十分な時間を有する。その結果、注文は完全に充足され、投資家６１４は図６Ａに示すように新たな買い注文を通じて残り２０００株を購入するためにより高い価格を支払う必要はない。
【０１０４】
図６Ｅ〜図６Ｈは、オーダブックアービトラージに関する例である。実施例において、市場参加者はオーダブックアービトラージのアドバンテージを得る。このストラテジは、代替商品を取引する取引所間（または市場センタ間）のレイテンシー差から仲介者が利益を得ることができるようにするものである。オーダブックアービトラージは、受動的に実行することもできるし積極的に実行することもできる。例えば受動的オーダブックアービトラージは、仲介者が最新の市場データを有しており、先に送信された注文を不利な価格でそのまま取引所（または他市場センタ）に留め置く場合に、生じるものである。これにより、積極的注文を入力した古くなった市場データでその注文がより低速な参加者によって実行されることを期待する。一方で積極的オーダブックアービトラージは、取引所（または他市場センタ）が自身のオーダブック上に残っている注文を再値付けし、他取引所（または他市場センタ）における市場データ変化を処理する速度が仲介者よりも遅い場合に、生じるものである。最新市場データを有する仲介者は、古くなった市場データに基づき低速取引所上で取引を実行する。これはその取引所（または他市場センタ）のオーダブック上の注文にとって不利益となる。
【０１０５】
図６Ｅは、ＥＢＯＭの実施形態における受動的オーダブックアービトラージの例を示す。例えば１実施例において、ブローカ６１５、ＨＦＴ６０６、取引所１  ６０５ａ、および取引所２  ６０５ｂは、ＸＹＺのＮＢＢＯが＄１０．００×＄１０．０２であることを知っている。ＨＦＴ６０６は、取引所１  ６０５ａにおいてＸＹＺ１０００株を＄１０．００で購入する注文Ａ６１３ａを入力する。注文Ａ６１３ａの実行に続き、取引所２  ６０５ｂにおける＄１０．０１×＄１０．０２への市場アップデート、値付けアップデートＢ６１３ｂ、Ｂｉ、およびＢｉｉは、ＨＦＴ６０６、取引所１  ６０５ａ、およびブローカ６１５に対してそれぞれ送信される。新たなＮＢＢＯは＄１０．０１×＄１０．０２となる。距離差に起因して、取引所１  ６０５ａと取引所２  ６０５ｂは異なるＮＢＢＯを有していることになる。すなわち、それぞれの取引ブックの価格が異なっている。取引所１  ６０５ａ（＄１０．００×＄１０．０２）、取引所２  ６０５ｂ（＄１０．０１×＄１０．０２）である。
【０１０６】
１実施例において、ＨＦＴ６０６は値付けアップデートＢ６１３ｂを受け取り、よって取引所２  ６０５ｂにおける新たなＮＢＢＯ（＄１０．０１×＄１０．０２）を知っている。ＨＦＴ６０６はまた、自身の＄１０．００の１０００株買い注文Ａ６１３ａが取引所１  ６０５ａに留まっていることを知っている。低速な市場参加者（例えばブローカ６１５）は最新市場情報Ｂｉｉを受け取っていないので取引所１  ６０５ａにおいてＸＹＺ株を＄１０．００で売ろうとすることを期待して、ＨＦＴ６０６はその買い注文Ａ６１３ａを＄１０．００に留めておく。
【０１０７】
１実施例においてブローカ６１５は、前のＮＢＢＯ（＄１０．００×＄１０．０２）に基づき＄１０．００のＸＹＺ１０００株売り注文Ｃ６１３ｃを取引所１  ６０５ａに対して入力する。この後、ブローカ６１５がＢｉｉを受け取る前に値付け変更Ｂ、Ｂｉ、Ｂｉｉが続く。取引所１  ６０５ａがＢｉを受け取る前に、注文Ｃ６１３ｃは不利な価格による実行（＄１０．００×＄１０．０２）を受け取る。取引所１  ６０５ａが他市場において値付けされた不利な価格による取引から自身のオーダブック上における注文を保護する義務がある場合（例えばＵＳにおいてはＲｅｇｕｌａｔｉｏｎ  ＭＳに準拠する必要がある）、取引所１  ６０５ａが値付けアップデートＢ６１３ｂを受け取り、より有利なビッド価格（＄１０．０１）が存在することを知ると、売り注文Ｃ６１３ｃを＄１０．００で取引することを許可しない（＄１０．００で実行することは、Ｒｅｇｕｌａｔｉｏｎ  ＭＳの下では“ｔｒａｄｅ  ｔｈｒｏｕｇｈ”とみなされる）。
【０１０８】
ただし、値付けアップデートＢ６１３ｂを受け取る前に取引所１  ６０５ａが売り注文Ｃ６１３ｃを受け取る場合、取引所１  ６０５ａは売り注文Ｃ６１３ｃを＄１０．００で実行することを許可する（値付け変化に気づかないので）。これは現在の最良ビッド＄１０．０１よりも不利な価格である。この場合投資家６１４は、ＸＹＺ株売りにおいて受け取るのが＄１０．００少なくなる（１０００×．０１＝＄１０．００）。
【０１０９】
このように、ＨＦＴ６０６が値付けアップデートＢ６１３ｂを受け取った後、注文Ａ６１３ａを変化させないままにしておく間、ＨＦＴ６０６はＸＹＺ株を＄１０．００で購入し、即座に取引所２  ６０５ｂにおいて＄１０．０１で売却し、投資家６１４を犠牲にして利益を得ることができる。
【０１１０】
図６Ｆは、ＥＢＯＭの実施形態において受動的オーダブックアービトラージをＰＯＰアクセスポイントによって中立化することにより管理する例を示す。例えば１実施例において、ブローカ６１５、ＨＦＴ６０６、取引所１  ６０５ａ、および取引所２  ６０５ｂは、ＸＹＺのＮＢＢＯが＄１０．００×＄１０．０２であることを知っている。ＨＦＴ６０６は、取引所１  ６０５ａにおいてＸＹＺ１０００株を＄１０．００で購入する注文Ａ６１３ａを入力する。取引所２  ６０５ｂにおける＄１０．０１×＄１０．０２への市場アップデート、値付けアップデートＢ６１３ｂ、Ｂｉ、およびＢｉｉは、ＨＦＴ６０６、取引所１  ６０５ａ、およびブローカ６１５に対してそれぞれ送信される。新たなＮＢＢＯは＄１０．０１×＄１０．０２となる。距離差に起因して、取引所１  ６０５ａと取引所２  ６０５ｂは異なるＮＢＢＯを有していることになる。すなわち、取引所１  ６０５ａ（＄１０．００×＄１０．０２）、取引所２  ６０５ｂ（＄１０．０１×＄１０．０２）である。
【０１１１】
１実施例において、ＨＦＴ６０６は値付けアップデートＢ６１３ｂを受け取り、よって取引所２  ６０５ｂにおける新たなＮＢＢＯ（＄１０．０１×＄１０．０２）を知っている。ＨＦＴ６０６はまた、自身の＄１０．００の１０００株買い注文Ａ６１３ａが取引所１  ６０５ａに留まっていることを知っている。低速な市場参加者（例えばブローカ６１５）は最新市場情報Ｂｉｉを受け取っていないので取引所１  ６０５ａにおいてＸＹＺ株を＄１０．００で売ろうとすることを期待して、ＨＦＴ６０６はその買い注文Ａ６１３ａを取引所１  ６０５ａにおいて＄１０．００に留めておく。
【０１１２】
１実施例においてブローカ６１５は、投資家６１５に代わって取引所１  ６０５ａに対して１０００株の売り注文Ｃ６１３ｃを入力する。取引所１  ６０５ａが他市場において値付けされた不利な価格による取引から自身のオーダブック上における注文を保護する義務がある場合（例えばＵＳにおいてはＲｅｇｕｌａｔｉｏｎ  ＭＳに準拠する必要がある）、取引所１  ６０５ａが値付けアップデートＢｉ６１８ａを受け取り、より有利なビッド価格（＄１０．０１）が存在することを知ると、売り注文Ｃ６１３ｃを＄１０．００で取引することを許可しない。
【０１１３】
１実施例において、ＥＢＯＭ  ＰＯＰアーキテクチャＰＯＰ６１０により、取引所１  ６０５ａはブローカ６１５の注文Ｄ６１３ｄが取引所１  ６０５ａに到着する前に、値付け変化Ｂｉ６１８ａを受け取ることができる。したがって取引所１  ６０５ａは、最新市場データが＄１０．０１×＄１０．０２であることを知り、注文Ｃ６１３ｃを＄１０．００で取引することを許可しない。
【０１１４】
このように、ＨＦＴ６０６が値付けアップデートＢ６１３ｂを受け取った後、注文Ａ６１３ａを変化させないままにする場合、ＥＢＯＭ  ＰＯＰアーキテクチャＰＯＰ６１０は投資家６１４が古い値付け情報で取引することを防ぎ、ＨＦＴ６０６が投資家６１４を犠牲にして利益を得ることを防ぐ。
【０１１５】
図６Ｇは、ＥＢＯＭの実施形態における積極的オーダブックアービトラージの例を示す。図６Ｇに示すように、この例は古い値付けアービトラージｖｓミッドポイントペッグ注文で取引する。ただしメカニズムは同じである。したがって、全米最良ビッド（ＮＢＢ）または全米最良オファー（ＮＢＯ）において、同じアービトラージ機会が古い値付けに対して適用される可能性がある。
【０１１６】
１実施例において、ブローカ６１５、ＨＦＴ６０６、取引所１  ６０５ａ、および取引所２  ６０５ｂは、ＸＹＺのＮＢＢＯが＄１０．０１×＄１０．０３であることを知っている。ブローカ６１５は投資家６１４に代わり、取引所１  ６０５ａに対して注文Ａ６１３ａを入力する。注文Ａ６１４は、ＸＹＺ１０００株を購入するものであり、ＮＢＢＯミッドポイントに（＄１０．０２）ペッグされている。取引所２  ６０５ｂにおける＄１０．００×＄１０．０２の市場アップデート、値付けアップデートＢ６１３ｂ、Ｂｉ６１８ａ、およびＢｉｉ６１８ｂは、ＨＦＴ６０６、取引所１  ６０５ａ、およびブローカ６１５に対してそれぞれ送信される。新たなＮＢＢＯは＄１０．００×＄１０．０２になり、新たなミッドポイントは＄１０．０１になる。距離差に起因して、取引所１  ６０５ａと取引所２  ６０５ｂは異なるＮＢＢＯとミッドポイントを有していることになる：取引所１  ６０５ａ（＄１０．０１×＄１０．０３でミッドポイントは＄１０．０２）、取引所２  ６０５ｂ（＄１０．００×＄１０．０２でミッドポイントは＄１０．０１）である。
【０１１７】
１実施例において、ＨＦＴ６０６は値付けアップデートＢ６１３ｂを受け取り、よって新たなＮＢＢＯとミッドポイント（＄１０．００×＄１０．０２と＄１０．０１）を知っている。ＨＦＴ６０６はまた、取引所１  ６０５ａにおけるミッドポイントが未だ以前のＮＢＢＯ（＄１０．０１×＄１０．０３と＄１０．０２）に基づき値付けされていることを知っている。ＨＦＴ６０６は、古いミッドポイント＄１０．０２において売り注文Ｃ６１３ｃを取引所１  ６０５ａに対して送信し、ブローカ６１５の注文Ａ６１３ａを不利なミッドポイント価格で取引する。これにより投資家６１４に対して＄１０．００のコスト負担をかけることになる（１０００＊＄．０１＝＄１０．００）。
【０１１８】
したがって、（Ｂの送信時間＋Ｃの送信時間）＜Ｂｉの送信時間であれば、ＨＦＴ６０６は取引所１  ６０５ａにおいて即座にＸＹＺ株を＄１０．０２で売り、取引所２  ６０５ｂにおいて即座にＸＹＺ株をミッドポイント＄１０．０１で購入する。これにより投資家６１４を犠牲にして利益を得ることになる。
【０１１９】
図６Ｈは、ＥＢＯＭの実施形態においてＰＯＰアクセスポイントにより積極的オーダブックアービトラージを管理する例を示す。図６Ｇの古い値付けアービトラージに続いてＰＯＰ６１０が設置されると、ＨＦＴ６０６の注文Ｃ６１３ｃはＥＢＯＭ  ＰＯＰアーキテクチャＰＯＰ６１０を通過する必要がある。（Ｂの送信時間＋Ｃの送信時間＋Ｃｉの送信時間）＞Ｂｉの送信時間であれば、取引所１  ６０５ａは値付けアップデートＢｉをタイミングよく受け取ることができ、ミッドポイントを最新情報（＄１０．００×＄１０．０２と＄１０．０１）に更新する。ブローカ６１５の注文Ａ６１３ａは、不利なミッドポイント価格で実行されない。
【０１２０】
ＴＬＬの別実施形態は以下を含む：
【０１２１】
実施形態において、ＴＬＬは売買者からの売買注文をマッチングし実行する市場である。ＴＬＬはまた、当該ＴＬＬ上でマッチングできない場合、これら注文を他市場へルーティングする。ＴＬＬは、売買者に対して米国内で流通する現金等価商品を提供する義務がある場合がある。ただしシステム組織の原則は、米国その他国家規制、地理的規制、および／または規制地域と同様に、その他商品、金融商品、その他価値の売買に対して適用することができる。
【０１２２】
ＴＬＬは、コンピュータハードウェア上で動作する複数のコンポーネントを備えることができる。これは以下を含むが、これらに限らない：クライアントＦＩＸゲートウェイ、マッチングエンジン、ルーティングエンジン、取引所ＦＩＸゲートウェイ、市場データティッカープラント、注文取引データベースクリアリング、請求、調査システムおよびインターフェース、など。これらは内部メッセージバスを介して相互通信し、他取引所、ベンダ、商品ブローカなどと外部通信する。以下に、新規かつ有用なコンポーネントとシステムの要素を説明する。
【０１２３】
ＴＬＬは、既存の取引場所の取引において、“拘束取引”（ＨＦＴ）として知られる手法を用いた取引戦略によるアドバンテージに対抗する。
【０１２４】
＜信頼性＞
ＴＬＬは、クライアント／サーバモデルを採用することができる。“クライアント”は例えば、他のプログラムが提供するサービスを用いるプログラムである。このサービスを提供するプログラムは、“サーバ”と呼ばれる。サーバは、クライアントリクエストに対して、データ、ステータス情報などを返信することにより機能する。実施形態において、クライアントは他のバックエンドサービスやストレージとやり取りする前にビジネスプロセスロジックを実施するサーバに接続し、および／またはサーバに対して応答し、サーバはクライアントに対して返信する。
【０１２５】
ＴＣＰ−ｔｏ−Ｍｕｌｔｉｃａｓｔ（Ｔ２Ｍ）は、メッセージが単一のフロントエンドサーバから複数のバックエンドサーバに対して配信されるものである。実施形態において、これによりリソース使用を最適化し、スループットを最大化し、フォールトトレランスを向上させ、その他セキュリティおよび品質保証（ＱＡ）を実現することができる。
【０１２６】
Ｔ２Ｍは、外部クライアントがバックエンドサービスにアクセスするため接続するポートに接続するコンポーネントである。プログラムは、クライアントからの通信をＴＣＰプロトコルで保持し、マルチキャスト（ＵＤＰプロトコル）配信によりバックエンドサービスに対してデータペイロードを送信する。ＴＣＰプロトコルは１：１通信を提供する一方で、マルチキャストは１：多通信を提供する。これにより複数のバックエンドサービスは、データを処理しおよび／または別のバックエンド／ダウンストリームサービスに対して送信する前に、単一ソースからの元のデータペイロードを同時に受け取ることができる。
【０１２７】
Ｔ２Ｍを介した１：多通信により、クライアントは単一ＴＣＰ接続を生成することができる。このＴＣＰ接続は、Ｎ個のバックエンドリソースに対する接続として広がる。この１：多通信はクライアントにとって見えないが、多くの利点を提供する。具体的には、以下のうち少なくとも１つを実現する：アーキテクチャロジックからビジネスロジックを抽象化することに起因する配信リスクを最小化する；複数サーバに対してクライアント通信セッションを複製する；フロントエンドサービスから独立してバックエンドサービスをスケーリングする；クライアントはバックエンドサービスに対して直接接続せず、これにより内部ネットワーク構造とカーネルネットワークスタックを隠蔽し、システムセキュリティを向上させる；クライアントポート接続に負担をかけることなく日中キャパシティスケーリングとロードバランシングを実現する；データセンタ内またはデータセンタ間におけるクライアント通信例やのリアルタイムシームレスフェイルオーバを実現し、フォールトトレランス、レジリエンス、災害復帰性能を向上させる；元のデータペイロードを用いたリアルタイムＱＡ分析のための個別のパラレルストリーム；など。
【０１２８】
＜物理ハードウェアとネットワーク＞
＜地理的に異なるシステムに対する確実な同時情報配信＞
異なる地理的場所から中央ポイントに対してデータを送信するためには、通信時間および通信距離に応じて異なる時間長が必要である。その結果、２つの地理的場所から中欧ポイントに対して同時に送信されたデータは、異なる時刻に到着する。実施形態において、この補正はソフトウェアを用いてなされるが、そのようなシステムは複雑であり、エラーを生じ易く、不正確である。
【０１２９】
様々なチャネルによるデータ送信は、様々な制約により制限される。例えば１実施例において、これは光ファイバチャネルによりなされる。この場合、通信速度はチャネル媒体を介して光速度により制限される。この実施形態において、伝搬時間は伝搬距離を媒体の光速度で除算することにより求められる。したがって伝搬時間は、媒体に距離を追加するかまたは媒体を変更することにより、平準化することができる。短いチャネルに対して距離を追加することにより送信媒体の長さを平準化すると、情報を同時配信することができる。実施形態において、これはナノ秒以内の同時配信を保証する。
【０１３０】
＜地理的に異なる取引システムに対する確実な同時情報配信＞
多くの取引システムは、地理的に異なる場所に物理的に配置された取引システムに対して、光技術を用いて情報を送信する。少なくとも部分的には取引システムの地理的違いに起因して、さらに現行通信手法と規制の組み合わせにより、全て取引システムから完全に等しい距離にある点はない。その結果多くの取引システムは、情報配信を時間平面上で実施し、このタスクを実施するためには複雑でエラーを生じ易く不正確なソフトウェア駆動の手法を用いなければならない。
【０１３１】
先に述べたように、情報は光通信を介して光ファイバに沿って各場所に対して送信される。受信確認応答は、同じ経路の別の光ファイバチャネルに沿って送信される。これらはいずれも、光ファイバチャネルが使用する媒体に起因して、光速度の制約を受ける。実施形態において、光ファイバチャネルの送信距離（ｄ）をチャネルの媒体の光速度で除算すると、情報を送信元から宛先に対して送信するのに必要な送信時間（ｔ）を求めることができる。全ての取引システムから完全に等しい距離にある点は存在しないので、距離が異なる光ファイバチャネル（ただし媒体は同じ）上の送信距離は異なり、したがって送信元システムから送信される情報は宛先システムに対して異なる時刻に到着する。
【０１３２】
情報の同時配信は、各送信側光ファイバチャネルの光チャネルケーブルに対して距離を追加し、および／またはチャネル媒体を変更するなどにより、情報が伝搬する距離を平準化すると、可能となる。すなわち、情報の配信時間（ｄ／ｓ＝ｔ）が全てのチャネルにおいて等価となるようにすることである。１実施形態において、通信プロバイダが提供するチャネルセットの距離を測定し、短いチャネルに対して長さを追加して長さを平準化することにより、情報配信は実質的に同時となる。すなわち例えば、ナノ秒範囲内となる。これに対しソフトウェア駆動手法を用いた場合は、ミリ秒範囲となる。
【０１３３】
＜混雑通知のためのアプリケーションバッファ利用率レポートおよびネットワークアプリケーションｎ回避＞
ｂｕｆｆｅｒｂｌｏａｔは、非常に大きいバッファを用いることによりネットワーク化されたアプリケーションに対して非決定的レイテンシーを導入するものとみなすことができる。実施形態においてこれは、レイテンシーターゲットをセットするとともにそのターゲットをレイテンシー測定の対象として動作し続けることにより実現される。これら技術はＴＣＰソケットを利用するシステムにおいてのみ用いられ、２つの重要な制約を有する：（１）大きく広がったアプリケーションを効率的に取り扱うことができない、（２）アプリケーションに対して非透過的である。
【０１３４】
これら２つの制約（非透過性と非効率な広がり）により、ＣｏＤｅｌアルゴリズムを用いるＴＣＰは、広範囲に分散したシステムにおいてｂｕｆｆｅｒｂｌｏａｔの課題を取り扱うのに不十分となる。分散システムは通常、プライベートネットワーク上にホストされており、プライベートネットワークは専用アプリケーションに対してオペレータが完全にコントロールすることができるので、各アプリケーションのバッファ利用に関する情報を上下流アプリケーションに対して特定のデータパス内において直接的に配信するほうがより効率的である。
【０１３５】
バッファ利用に関する情報を例えば０〜２５５の単一数値で配信することにより、各アプリケ−ションはそのすぐ隣における負荷を把握し、さらにデータ送信するか否かをスマートに決定することができる。例えばバッファ利用に関する情報が規定閾値に達すると、アプリケーションは配線上でさらにデータを送信することを停止する。この“一時停止”により、停止したアプリケーションのバッファ利用は増加する。この情報が上流アプリケーションに対して配信される。以下同様である。アプリケーションに対してバッファ利用情報を明示的に通知することにより、アプリケーションは送信を停止し、下流アプリケーションのバッファが満杯になって新たにデータを受け取ることができなくなった後にアプリケーションがデータ送信を続けたとき起こるパケットロスを防止する。またこれにより、アプリケーションがロストパケットを再送信しようとするとき生じる過剰な再送信遅延を回避することができる。さらにバッファ利用情報を明示的に通知することにより、分散システムの末端間レイテンシーは単一アプリケーションバッファを枯渇させる遅延の５０％近辺で前後する。
【０１３６】
＜アクティブ／パッシブフェイルオーバシステムのアクティブメンバを確実かつ効果的に停止させる自動化方法＞
ＴＬＬは、パッシブシステムメンバが新たなアクティブシステムメンバになるためいくつかの動作セットが必要な特徴を備えた、アクティブ／パッシブシステムである場合がある。アクティブ／パッシブシステムの１実施例において、１つのメンバのみがアクティブであって所与の時刻においてデータを処理しており、他メンバはアクティブになるのを待っているものとする。アクティブ／パッシブシステムの特性に起因して、ＴＬＬはフェイルオーバを実施する間に“アクティブ”システムによる動作を停止させる。この停止は一般に、“ｓｈｏｏｔ  ｔｈｅ  ｏｔｈｅｒ  ｎｏｄｅ  ｉｎ  ｔｈｅ  ｈｅａｄ”またはＳＴＯＮＩＴＨとして知られている。これにより、フェイルオーバ後にアクティブであるメンバが１つのみとなることを保証する。これにより、以前のマスタはシステムの制御を再アサートしようとすることはなくなり、あるいは２つ目のマスタとして動作し続けることはなくなる。このような動作は、アクティブ／パッシブシステムの性質に起因して、メッセージを不正確に多重化する可能性がある。
【０１３７】
ＳＴＯＮＩＴＨは、第２ノードがプライマリシステムとシャットダウンについてやり取りすることにより、自動的に実現することができる。あるいは、管理者が現在のアクティブ（マスタ）ノードにログインし、アクティブノードの動作を終了させるコマンドを実行することにより、手動で実現することもできる。ただしこの方法が失敗する状況がいくつかある。
【０１３８】
アクティブノードを適切に終了させるため、ＴＬＬはノードが動作しているハードウェア（例えばサーバ）に対する接続を遠方側の接続において遠隔終了させる。厳密なケーブル規格と組み合わせると、アクティブ／パッシブシステムのアクティブメンバの位置はパッシブメンバによりアルゴリズム的に決定される。このときアクティブメンバの状態は関係ない。パッシブメンバがアクティブノードの不具合を検出すると、パッシブノードはアクティブノードが接続されているネットワークデバイスと直接通信し、アクティブノードが接続しているネットワークポートを無効化する。アクティブノードも必要であれば、ネットワーク接続された電力供給装置に直接接続し、同様に以前のアクティブノードから電力を除去する。これら２つの動作により、以前アクティブノードであったものが自身をシステムのアクティブメンバとして再アサートすることを防止できる。
【０１３９】
＜演算効率／テスト／メッセージング＞
＜クライアントゲートウェイにおけるＩＤマッピングおよび管理（ｌｕｇｇａｇｅ＋ＩｅｘＩＤ）＞
外部ＦＩＸクライアントを有する多くの取引システムインターフェースは、取引システムに対して送信される注文ＩＤ（ＦＩＸフィールドＣｌＯｒｄＩｄ）を処理するのが困難である。これらＩＤは、外部システムに対してのみユニークであり（例えばシステム１とシステム２はともに取引システムに対してｉｄ＝ＡＢＣＤの注文を送信する）、その長さと内容は外部システム間で大幅に異なる。実施形態において、これら注文を一意に識別するための解決手段は、顧客ＩＤ（ＦＩＸフィールドＳｅｎｄｅｒＣｏｍＩＤ）と注文ＩＤ（例えばシステム１の注文Ａ＝‘Ｃｕｓｔｏｍｅｒ１−ＡＢＣＤ’）を連結することにより、外部システムの注文に対して内部的にアドレスを付与することである。これは有効なアプローチであるが、性能問題が生じる可能性がある。システム内において外部システムを一意に識別するために長い文字列を使用しなければならず、クロスレファレンスを生成して各データベース、ファイルシステム、キャッシュメモリ内に格納しなければならないからである。これにより、そのＩＤへアクセスする必要があるプロセスにとって多大なオーバヘッドが生じ、失敗したプロセスから復元する必要がある場合に技術的な壁がある。
【０１４０】
代替実施形態において、ＴＬＬは外部システムの注文ＩＤ（ＣｌＯｒｄＩｄ）を一意生成したＩＤと置き換える。これは、内部システムフォーマット（ＩｅｘＩＤ）に基づいて実施し、クロスレファレンス情報をマルチキャストメッセージストリームに公開する。外部システムの元のＣｌＯｒｄＩｄは保存され、外部システムＩＤとＩｅｘＩＤとの間のマッピングはＴＬＬに保存される。実施形態において、これは別のメッセージ“ｌｕｇｇａｇｅ”を用いて実施される。ＴＬＬは、非クリティカルな“ｌｕｇｇａｇｅ”データをメインデータパス外で送信する。ＦＩＸゲートウェイ自身または他のレポーティングシステムなどの宛先エンドポイントも、必要に応じて“ｌｕｇｇａｇｅ”メッセージを収集し、ＩｅｘＩＤをＣｌＯｒｄＩｄへデコード（アンマップ）する。ただし多くの場合、システムは元の外部システム注文ＩＤを見る必要はない。実施形態において、これによりシステムのデータ処理効率を高めることができる。一意生成したＩｅｘＩＤは、マルチキャストメッセージストリーム上における全リスナが知っている既知の効率的なフォーマットで生成することができる。これにより、処理の一貫性を保つとともに、必要に応じてメッセージストリームとやり取りする全システムに対してＩｅｘＩＤを公開することができる。
【０１４１】
図７は、実施例のサンプルデータフローを示す。顧客１  ７０２は注文を入力し（７０５）、注文ＡＢＣＤを送信する（７１０）。注文ＩＤはＣｕｓｔｏｍｅｒ１−ＡＢＣＤである。クライアントＦＩＸゲートウェイは注文を受け取り、ＩＤをマッピングし（７１５）、システムに対して情報を送信する。ＴＬＬは、内部注文ＩＤ１００１などのユニークＩＤを生成し（７１５）。ＴＬＬは、“ｌｕｇｇａｇｅ”メッセージをＴＬＬに対して送信し（７２０）、これは関連するコンポーネントのために保存される（Ｌｕｇｇａｇｅ［Ｃｕｓｔｏｍｅｒ＝１，ＣｌＯｒｄＩｄ＝ＡＢＣＤ，ＩｅｘＩＤ＝１００１］）。ＴＬＬは注文メッセージをＩｅｘＩＤ＝１００１で送信する。次に注文は、充足されまたはマッチングされる（７２５）。この情報はマッチングエンジンクライアントゲートウェイによってＩＤ＝１００１で送信される。クライアントゲートウェイは、顧客１についてＩｅｘＩＤ＝１００１をＡＢＣＤに復元し（７３０）、顧客に対して元のＩＤでフィルインディケータを送信する（７３５）。取引レポートアプリケーションも、適切なポスト取引システムのために“ｌｕｇｇａｇｅ”に基づきフィルインディケータを変換するとともにＩＤをアンマップする。
【０１４２】
＜シーケンス番号をメッセージのユニークＩＤとして用いる＞
マルチプロセスマルチマシンシステムにおいて、ユニークＩＤを生成することは、チャレンジングなことである。カウンタを用いるシンプルなアプローチは、有用でない場合がある。複数の場所において同一ＩＤが生成される可能性があり、状態の種類によってはプロセスが再スタートするとき重複ＩＤが生成されないように保存しておかなければならないからである。１実施形態において、生成された場所を示す記述子をＩＤに対して追加することにより、これを解決することができる。例えばｍａｃｈｉｎｅ０１．ｐｒｏｃｅｓｓ０２．ｓｅｓｓｉｏｎ０１．［ｃｏｕｎｔｅｒ］である。これは比較的簡易でありｐｏｉｎ  ｏｆ  ｆａｉｌｕｒｅが存在しないが、ＩＤは本来必要なものよりも長くなり、再起動するときセッションをトラッキングすることが困難になる。またｍａｃｈｉｎｅとｐｒｏｃｅｓｓを一意に名付ける必要がある。他実施形態において、中央でＩＤを生成することもできる。この場合、ＩＤはサービス、データベースなどの専用プロセスによって作成される。これはシンプルであり中央制御することができるが、ＩＤを取得するオーバヘッドと中央のｐｏｉｎｔ  ｏｆ  ｆａｉｌｕｒｅが問題となる可能性がある。
【０１４３】
他実施形態において、システムの専用マルチキャストミドルウェアが提供するメッセージシーケンス番号を、ユニークＩＤとして用いることができる。ＴＬＬが受信する全てのメッセージは日単位で一意であることを保証され、単調増加する番号である。中央ＩＤシステム（データベース、ファイル、メモリなど）を呼び出す必要はない。またＩＤは、現在のシステム状態に対する参照も提供する。この技術はＴＬＬの複数の場所において利用することができるが、特にユニーク顧客注文チェーンＩＤを生成するときに利用することができる。
【０１４４】
例えばＴＬＬを介して設定１〜１０を送信し、このときシーケンス番号＝１０であり、ＴＬＬを介して市場データ値付け１〜３を送信し、このときシーケンス番号＝１３である。顧客注文１が到着するとき、シーケンス番号＝１４である。ＴＬＬは、システムユニークＩＤが必要な注文チェーンを生成する。ＴＬＬはこれを生成し、または中央サービスに対して新ＩＤを生成するよう要求する一方で、ＴＬＬは注文チェーンを生成する契機となった顧客注文メッセージのシーケンス番号を用いる。注文チェーンＩＤ＝シーケンス番号＝１４である。これにより、ＩＤはユニークかつコンパクトとなり、さらなる演算は必要ない。このシーケンス番号は、システムのそのときの状態に対応する時刻点を表す。ＴＬＬは注文が生じた時刻における最新市場データを決定することができる。
【０１４５】
＜順番付けされた市場データ＞
取引システムにおける金融市場データのスピードと量は、チャレンジングである。毎日数１００ミリオン件のデータ更新があり、データは即座に消費するとき最も価値が高いからである。古いデータは価値が低い。取引システムは、複数のプロセスと機能の間でプロセスを分割するように設計することができる。例えば取引エンジン１に対して“Ａ”で開始するシンボルのみを見るように指示する。あるいは市場データを個別に使用するアプリケーションを有している場合もある。市場データを分割することにより、決定に関する課題が生じる。市場データに関心があるプロセスは互いに異なる状態を有している場合があるからである。これらプロセスはデータを個別に見ており、システム状態はプロセス間で不整合となる可能性があるからである。例えば：
【０１４６】
市場データ（ＭＳＦＴ）→プロセス１→注文＃２を処理しているプロセス１は、ＭＳＦＴ＠＄１０．０１を知っている；
【０１４７】
市場データ（ＭＳＦＴ）→プロセス２→注文＃２を処理しているプロセス２は、ＭＳＦＴ＠＄１０．０２を知っている；
【０１４８】
ＴＬＬは代わりに、順番付け／シリアライズする全ての市場データをミドルウェア経由で送信する。これにより、市場の状態は任意の時刻においてシステム全体にわたって各アプリケーションにおいて同一となる。例えば：
【０１４９】
市場データ（ＭＳＦＴ）→シーケンサ→プロセス１→注文＃２を処理しているプロセス１は、ＭＳＦＴ＠＄１０．０１を知っている
【０１５０】
プロセス２→注文＃２を処理しているプロセス２は、ＭＳＦＴ＠＄１０．０１を知っている
【０１５１】
ＴＬＬ全体にわたって市場データが同一状態であることは、複数の利点がある。例えばある取引においてＴＬＬは、その取引における市場データ状態アップデートのメッセージＩＤ（シーケンス番号）をノートすることにより、取引メッセージ上の市場データ状態にラベル付けする。（例えば、取引１５が発生し、値付け５２は現在の市場状態を表す）これは、特定時刻における市場状態を識別する便利かつ有用な手法である。市場データを順番付けしない場合、その他の手段は顧客毎に現在の市場状態を書きだすことになり、あるいは市場状態を時刻ベースで引き出すことになる（これは不正確である）。
【０１５２】
＜トリガフレームワーク＞
ＴＬＬトリガフレームワークにより、厳密に制御され、透過性が高く、均一な態様で、複雑なビジネスロジックを配置することができる。１実施形態において、目的はモジュール化されたロジックを構築することである。これにより開発者は特定のタスクに専念することができ、多くのアプリケーションが再利用することができる。トリガフレームワークは、２タイプのコンポーネントを有する：ＣｏｎｄｉｔｉｏｎとＡｃｔｉｏｎである。
【０１５３】
これら２つのコンポーネントは、条件が本体でありアクションがブランチであるバイナリデシジョンツリーとして配置することができる。
【０１５４】
条件は、アプリケーション内のオブジェクトの現在状態を評価するとともに、その条件が満たされるか否かを示すｔｒｕｅまたはｆａｌｓｅを戻す、個々のクラスである。オブジェクトは、例えばＦＩＸプロトコルのＮｅｗＯｒｄｅｒＳｉｎｇｌｅリクエストのような一時的メッセージ、またはＰａｒｅｎｔＯｒｄｅｒオブジェクトのような状態ベースデータ構造である。
【０１５５】
アクションは、条件が満たされたときビジネスロジックを実行する個々のクラスである。一般にアクションクラスは、特定の状態変化が生じたときメッセージを生成する。アクションは、評価および／または他のオブジェクトやアプリケーションとやり取りしているオブジェクトを変更する。
【０１５６】
条件とアクションは、モジュール化されたコンポーネントとして記述することができ、設定ファイル（例えばＪＳＯＮフォーマット）を通じてデシジョンツリー内で連結させることができる。このフレームワークにより、コンポーネントの再利用性、デバッグ、メンテナンス、ロジックの視覚的理解を高めて効率化することができる。
【０１５７】
ワークフローの例において、メッセージはアプリケーションに対して入力される。そのメッセージはトリガキューに追加され、および／またはそのメッセージにより他のオブジェクトがトリガキューに追加される。オブジェクトはトリガキューから１つずつ引き出され評価される。オブジェクトが評価されるとき、そのオブジェクトが状態ベースオブジェクトである場合、関連する状態ツリーがその状態に基づき引き出されるか、あるいはそうでなければそのオブジェクトタイプに対応するデフォルトツリーが読み出される。関連ツリー内の条件がトップから開始して評価される。例えば条件がｔｒｕｅと評価された場合、ｉｆＴｒｕｅ分岐が続き、あるいはその反対も同様である。条件ツリーは、アクションに到達し実施されるまでクロスされる。アクションを実施すると：トリガされたオブジェクトまたは他オブジェクトに対して状態変化が実施され；他オブジェクトを生成し；トリガキューに他オブジェクトを追加し；１以上のメッセージを配信し；またはこれらの組み合わせが実施される。トリガキューが完全に評価されると、アプリケーションは次に入力されたメッセージを処理する。
【０１５８】
条件は多くの異なるオブジェクトタイプに対して評価することができる。例えばオブジェクトの関連商品シンボルが中止されているか否かをチェックする条件は、ＮｅｗＯｒｄｅｒＳｉｎｇｌｅ  ＦＩＸメッセージ、市場データアップデートメッセージ、ＰａｒｅｎｔＯｒｄｅｒオブジェクト、ルータオブジェクト、などに対して評価することができる。
【０１５９】
＜テストハーネス＞
テストハーネスにより、テスト担当者はアプリケーションの自動テストを実施することができる。テストハーネスは、テストするアプリケーションを読み出し、ハーネスをアプリケーションの入出力バルブに接続する。あらかじめ例えばＪＳＯＮフォーマットで記述したインジェクトメッセージおよび期待メッセージを読み出す。インジェクトメッセージはアプリケーションに対して入力され、これにより出力メッセージが得られる。メッセージはアプリケーションによって出力され、出力メッセージはあらかじめ読み出した期待メッセージリストと比較される。実施形態において、出力メッセージが期待メッセージに合致しない場合、出力メッセージが範囲外である場合、またはテストハーネスが期待した出力メッセージを出力しない場合、テストは失敗する。それ以外であればテストは通過する。
【０１６０】
実施形態において、テストハーネスはメッセージテンプレートを実装する。ユーザは、テスト間にまたがって再利用できるメッセージテンプレートを生成する。テストを生成するとき、各メッセージはテスト生成者により指定されて使用するテンプレートを単純参照し、テストハーネスはメッセージをパースして呼び出したテンプレートフィールドの全ての値を自動的に読み出す。またテストにおいてフィールド値が指定された場合、その指定値はテンプレートからコピーされた値を上書きする。これによりテストの生成と変更が簡単になる。テストに関連するメッセージ上の関連フィールドのみを指定／修正すればよいからである。その他フィールドは、テンプレート設計のときデフォルト値を割り当て、これにより時間と負担を節約できる。
【０１６１】
実施形態において、テストハーネスにより期待メッセージに対して選択的にフィールド検証を実施することができる。テストにおいて検証のため用いる期待メッセージは、完全に整形したメッセージである必要はない。任意個数のフィールドを備えることができる。指定したフィールドのみが検証され、出力メッセージ上のその他全フィールドは無視される。この機能により、期待テストは特定フィールドを検証することに専念でき、メッセージ全体を検証するよりも効率的である。また、効果的に予測することができないタイムスタンプのような動的フィールドを取り扱う際に特に有用である。
【０１６２】
実施形態において、テストハーネスにより期待メッセージに対して選択的メッセージ検証を実施することができる。ユーザは、テストにおいて検証するメッセージタイプのリストを指定する。アプリケーションが出力するその他メッセージタイプは全て無視される。これにより、テストに関連しないメッセージ（例えばハートビートメッセージ）をフィルタリングすることができる。
【０１６３】
実施形態において、テストハーネスによりケースを生成することができる。テストハーネスは、インジェクトメッセージのリストのみを使用するモードを有し、アプリケーションに対してそのメッセージを１つずつ投入する。アプリケーションが出力する全メッセージが収集され、新たなテストケースファイルが両リストから生成される。
【０１６４】
実施形態において、テストハーネスによりケースをマス生成することができる。テストハーネスは、設定したインジェクとメッセージのリストと個別メッセージのリストを使用するモードを有する。テストハーネスは、テストするアプリケーションを読み出し、アプリケーションに対して設定したメッセージを投入し、個別メッセージリストから１つのメッセージを投入する。テストハーネスは、アプリケーションから全ての出力を収集し、完全整形したテストケースを生成する。次にテストハーネスは、アプリケーションを再スタートし、個別メッセージリストの次メッセージに対して以下のサイクルを繰り返す：読み出し＞設定したメッセージを投入する＞個別メッセージを投入する＞収集する。このプロセスは、個別メッセージリスト内の各メッセージについてテストファイルが生成されるまで繰り返される。このようにテストハーネスは、多数の類似テストを自動生成することができる。例えば顧客が送信した注文のフィールドを並び替えるテストがこれに相当する。
【０１６５】
実施形態において、テストハーネスにより複数アプリケーションをテストすることができる。テストハーネスは、複数アプリケーションを読み出し、その個々の機能とともに、他アプリケーションとやり取りする各アプリケーションの機能を、テストすることができる。テストハーネスは、指定された順序で指定されたアプリケーションセットを読み出す。実施形態において、これは順次やり取りするアプリケーションセットを通過するメッセージフローに基づく。テストハーネスは、セット内の最初のアプリケーションに対してインジェクトメッセージを入力し、出力メッセージを検証し、その出力メッセージを次のアプリケーションに対して投入し、検証し、以下同様である。
【０１６６】
テストハーネスは、テストを個別に実施することもできるし、同時に複数のテストを実施することもできる。実施形態において、テスト間でアプリケーションを再スタートすることもできる。テストハーネスは、自動ビルドプロセスに組み込み、テストケースの全リストを実施し、開発者がコードをコミットする毎にレポートを生成することができる。
【０１６７】
＜テストケースを動的構築するＷｅｂユーザインターフェース＞
テストビルダユーザインターフェースは、任意のＪＳＯＮデータスキーマに基づきテストケースを動的構築する手段を提供する。実施形態においてテストＵＩは、ＪＳＯＮフォーマットで読み出すスキーマファイルを特定する。このスキーマファイルは、システムメッセージセットを定義する。スキーマのフォーマットに基づき、ユーザは生じ得るメッセージリストの提示を受ける。ユーザがメッセージを選択すると、メッセージのフォーマットに基づきフォームが動的に構築される。これは特定のデータ検証ルールとともにスキーマにおいて定義することができる。ユーザは次に、規定のメッセージテンプレートリストの提示を受ける。このテンプレートを選択してフォームを埋めることができる。ユーザがメッセージフォームを入力完了すると、これはソート可能リストに追加される。ユーザは各メッセージアイテムを、テストフレームワークに対して投入する順序でソートする。完了したメッセージ集合は、テンプレートとして保存することができ、テンプレートを組み合わせて複雑なテストケースを形成することができる。ユーザは、テストハーネスがメッセージをインジェクトメッセージとしてまたは期待メッセージとして取り扱うべきか否かを指定する。期待すべきメッセージが何であるかをユーザが確信していない場合、ＵＩは全ケースを完了する前にテストケースの一部を投入することを許可する。部分テストケースは、ＲＥＳＴによりサーバに対して供給することができる。サーバはテストハーネスのインスタンスを起動し、テストメッセージの部分セットを投入する。テストハーネスが生成する出力メッセージはＵＩに戻され、ユーザに対して表示される。ユーザは各メッセージを検証する。ユーザがメッセージを承認する場合、テストケース完了ボタンをクリックすることによりメッセージは現在のテストケースに追加される。このメッセージはテンプレートとして保存される。テストケースが完了すると、ボタンをクリックしてＪＳＯＮ形式のテストケースファイルを生成する。このテストケースはテストハーネスによって実行され、継続ビルドプロセス内で実装される。
【０１６８】
テストＵＩは、スタンドアロンテストハーネスが実行するテストケースを構築するための、完全動的なｗｅｂベースインターフェースを提供する。テストＵＩは、ＪＳＯＮ形式データスキーマにのみ基づき、完全データ検証するフォームを生成する。できる限り単一メッセージを有する部分テストケースは、スタンドアロンテストハーネスに対して即座に投入され、ユーザに対してシステム出力メッセージを提示する。ボタンクリックにより完全動作するテストケースが生成され、テストハーネスはこれを用いる。個々のテストケースを組み合わせて、新たに複雑なテストケースを生成することもできる。
【０１６９】
＜単一ＵＩ要素を用いて複雑なデータクエリを生成する方法＞
ｗｅｂアプリケーションのなかには、マルチカラムデータをクエリする手段をユーザに対して提供するものがある。実施形態において、インターフェースはフォーム要素を提供する。ユーザはこれにより、データ要素タイプ毎に検索語を入力することができる。これに代えて、単一検索ボックスを提供し、複数データタイプにまたがって適用される検索語をユーザが入力できるようにしてもよい。
【０１７０】
別実施形態において、構造化検索フィールドを用いることができる。ユーザは、単一入力ボックスの提示を受ける。これは規定スキーマに基づき構造化入力にしたがう。
【０１７１】
１実施形態において、ユーザは入力ボックスを選択し、ボックスの現在のコンテキストを示唆するツールティップの提示を受ける。入力ボックスは、複数データタイプを含む場合もある。各データタイプは、スペースなどの文字で区切ることができ、ＯｒｄｅｒＩｄ、取引場所、ブローカ、価格、シンボルなどを含む。
【０１７２】
実施形態において、例えばスペースボタンを押下することによりユーザが選択ボックスを進めると、入力ボックスのコンテキストは次の検索語に進む。新たなツールティップが提示され、ユーザに対して検索語を示す。
【０１７３】
実施例において、ユーザは検索ボックスを進め、コンテキストがこれにともなって変わると、ボックスは可能性のある検索語をドロップダウンリストとして表示するように構成されている。
【０１７４】
実施形態において、ユーザが検索ボックスを進める毎に、データベース、データビュー、および／またはファイルに対して動的クエリが実施され、最終結果がユーザに対して速やかに表示される。
【０１７５】
別実施形態において、構造化検索フィールドは：規定スキーマに準じた単一入力ボックスにおいて複数の検索語を使用する；スキーマをその場でスイッチし、これにより検索語のタイプまたは検索語を入力する順番を変更する；ユーザが検索ボックスを進めると各検索語についてオートコンプリート検索語を表示する；ユーザがスペースバーをヒットすると検索ボックスを進めることができるようにし、検索ワイルドカードを自動入力できるようにする；ユーザが検索ボックスを前方または後方にナビゲートできるようにする；ユーザによる先の検索語入力を利用して、後の検索語として可能性のあるものを得る；ユーザが検索ボックスを進めるとツールティップを表示して、カーソル位置において検索語を示唆する；複数カラムにまたがる複雑なクエリに対する応答を動的に改善および最適化する；など。
【０１７６】
＜取引ロジック発明＞
＜ミッドポイント制約＞
株取引実行の価格付けは、パッシブ注文がオーダブックに対して投入された（および価格優先のためランク付けされた）ときの価格を用いてなされる。積極的に値付けされた２つの注文が互いに対して実行する場合、オーダブックに対して最初に到着し入力された注文の価格で実行される。具体的には、早い方の注文は自身の積極的な価格を支払い、遅い方の注文はよりよい価格を得る。別手法において、ＴＬＬオーダブックは実行価格を変更しない。これに代えて、ＴＬＬオーダブックに対して積極的に入力することができる限度を設定する。
【０１７７】
ＴＬＬは、ミッドポイント制約と呼ばれるコンセプトを用いる。ＴＬＬオーダブックにおいて、積極的隠れ注文または非表示注文は、全米最良ビッド／オファー（ＮＢＢＯ）のミッドポイント以上に積極的な価格で投入されることはない。２つの積極的に値付けされた隠れ注文がブックに投入され、ミッドポイントに再値付けされると、ミッドポイント価格で実行される。購入者はより高い価格を支払う意図を有しており、売却者はより低い価格で売却する意図を有しているので、いずれもよりよい実行価格（すなわち価格が改善される）を得ることができる。これにより、ＴＬＬブックに到着した注文によらず、２つの相対者の間でスプレッド（ビッド価格とオファー価格との間の差分）を公平に配信することができる。
【０１７８】
ミッドポイント制約は、その他の利点も提供する。ブックに入力された注文が価格優先のためにランキングされるときの価格を制約することにより、ミッドポイント制約は隠れキューにおける価格優先のための不必要な競争を抑制する。これは“ｐｅｎｎｙｉｎｇ”の形態でなされる。すなわち、より積極的なリミット価格で注文を送信することにより、一方が他方に対して優先権を得ようと試みることである。ミッドポイント制約は、実効価格による方向性の情報リークも抑制する。ビッド価格とオファー価格との間のミッドポイントで実行すると、方向性がない取引履歴となる。したがって実行時点においては、価格がいずれの方向に動くか（高値に動くか、それとも安値に動くか）、また新たな注文が供給増加または需要増加のいずれを表しているか、を識別することが難しい。また、ＴＬＬオーダブックにおける積極的に値付けされた条件注文の公平なランキングを維持することができる。
【０１７９】
ミッドポイント制約は、隠れ注文がＴＬＬオーダブックに投入されることを試みる毎にそのリミット価格が実行できるか否か相殺側の残注文と比較されるように実装することができる。実行することができない場合、注文のリミット価格はＮＢＢＯミッドポイントと比較される。注文価格がミッドポイントよりも積極的に値付けされている場合、ミッドポイントでオーダブックに格納される。注文価格がミッドポイントと比較して積極的ではない場合、注文はリミット価格でオーダブックに格納される。このプロセスは、ミッドポイント制約価格を先行処理することにより高速化することができる。これは、市場データ変化によりミッドポイントが変化したときＮＢＢＯのミッドポイントを計算することによりなされる。実施形態において、これは制約ミッドポイントを先行計算してＴＬＬオーダブックに投入しようとする注文に対しその計算結果を適用することにより、実施される。
【０１８０】
＜最小量＞
最小量注文は、インバウンド（新規）である場合、相対側単一注文そのものまたは集約した多数注文がインバウンド注文の最小量条件を満たす限り、相対側の単一注文または多数注文に対して取引するのに適している。ただし、インバウンド注文の最小量条件を満たす単一注文または多数注文がない場合、そのインバウンド注文は実行されず、代わりにオーダブックに格納される。この注文がオーダブックに格納されると、合計して最小量条件を満たす新たな相対側インバウンド注文に対してのみパッシブ実行される。インバウンド最小量注文がオーダブックに挿入された場合、将来のいずれかの時点において市場条件が変化しおよび／または新たな相対側注文がオーダブックに入力されると、その最小量注文は最小量条件を満たす多数注文に対して取引するのに適していないことになる。
【０１８１】
＜ブック再チェック＞
ブック再チェックにより、最小量注文はより利便性が増す。これは、ＴＬＬオーダブックに格納した後、複数の相対注文に対して最小量条件を満たす機会を改めて付与することによりなされる。ＴＬＬオーダブックにおける適当な市場取引可能注文をブック優先度順で繰り返し、いずれかがブックの相対側に対して取引可能であるか否かチェックし、ブックの反対側の注文が新たなインバウンド注文であれば注文を処理することにより、ブック再チェックは動作する。これはオーダブックのマッチングロジックにとって演算負荷が高く、コスト高なプロセスである。
【０１８２】
オーダブックのマッチングロジックに対する演算コストを緩和するため、外部プロセスは再チェックした注文をキャンセルし、マッチングエンジンに対して新たなものとして戻す。これにより、キャンセルされた注文は時間優先度を失い、再チェックは注文を完全実行しない。
【０１８３】
ＴＬＬは、再チェックされた注文に対する参照を保持する。これにより、オーダブック内の注文を削除または再注文することなくブック再チェックを実施できるようにする。これにより再チェックされた注文は、完全充足されなかったとき時間優先度を完全に維持できる。これら注文参照をアップデートし、成功した再チェックと失敗した再チェックの双方に適応し、これによりブック優先度がプロセス全体を通じて維持されるようにする。
【０１８４】
成功するブック再チェックプロセスは、任意個数のイベントによってトリガされる。このベントは以下を含むがこれに限らない：サブスクライバからの新注文指示；全米最良ビッドおよびオファーの変更；その他市場データ変数の変化。これらデータはコンパイルおよびプリプロセスされ、集約株数などの数値と様々な規制取引制約に変換される。これにより、再チェック動作を実際に実施する前に、実行することができそうか、できなさそうか、あるいは保証されているかを確定する。このように、プリプロセスによりブック再チェックの演算コストをさらに抑制することができる。
【０１８５】
＜最小量ティア＞
最小量指示は、０から注文総数までの任意の丸め数値取引数を認めることができる（注文の取引数に等しい最小量は、ａｌｌ−ｏｒ−ｎｏｎｅ注文条件として取り扱う）。理論的に無限数の最小量条件を認めることによりサブスクライバにとっては最も柔軟性が高まるが、これは非現実的である。多数の注文を有し最小量条件をともなう注文が散在しているオーダブックにおいて、注文が実行可能であるか否か比較するプロセスは、理論的に無限となる。換言すると、注文ペアまたは複数注文を組み合わせて注文の最小量条件を満たし実行できるか否かを判定するため、ブック内において理論的に無限個数の注文組み合わせの比較が生じ得る。最小量指示はオーダブック全体にわたって無限に変化し得るので、ブック全体にわたって各残注文が充足された最小量指示を有しているか否かを判定することなしに、所与のインバウンド注文に対して何株が利用可能であるかを判定する手段はない。また、インバウンド注文に対して取引したくない（すなわち、充足されてない最小量指示を有している）多数の注文をオーダブックが有している場合、各注文を個別にチェックしてスキップすることなしに、それら注文を分離する効率的な手段はない。
【０１８６】
ＴＬＬは、有効最小量および最小量ティアを備えることができる。有効な最小量ティアのセットにより、並び替えの個数を制限し、最も一般的に選択されている最小量値を把握する（例えば２００、３００、５００、１０００、５０００、１００００株）。サブスクライバの注文に対する最小量指示がティアと整合していない場合、ＴＬＬマッチングエンジンとオーダブックは有効最小量を用いて動作し、その値を次に低いティアに対してルーティングする。サブスクライバの従前の値は保持されるが、マッチングロジックのため有効値が用いられる。
【０１８７】
一般に使用されている値の有限セットに対する連結最小量指示により、最小量注文の実行をよりスムーズにすることができる。標準値を用いることにより、あとわずかなところで最小量指示がニアミスする可能性が低くなるからである。例えば最小量５７５株の注文は、最小量５５０株や５２５株などの注文とはマッチングされない。ニアミスは、過剰に細かい最小量を用いることにより生じる。この場合、２つの注文はマッチングされず、注文を入力したサブスクライバはサイズが非常に近い取引を所望する相対注文があることを知っていることになる。ティアに対する最小量オプションを制約することにより、この課題を減殺することができる。例えばティアに１００株ずつ１００〜１０００株（１００、２００、３００、４００、５００など）まで増やすことを強制することにより、先の例の注文は全て最小量条件５００に丸められ、互いに取引するのに適していることになる。これにより、最少取引サイズ制約を設定する注文目的がバランスされ、同様のサイズの相対側注文と取引をすることを妨げて不利益とならないようにする。
【０１８８】
ＴＬＬオーダブックは、ティアによる最小量注文を管理および格納する。ＴＬＬオーダブックは、最小量ティアにより有限個数の個々にソートされたオーダブックへパーティショニングされる。最小量でパーティショニングした結果、ブック内の最小量指示は全注文について同一となる。よってマッチングロジックはより高速に、インバウンド注文または再チェック注文に対して利用可能なオーダブック内の株数を評価することができる。ブック内の全注文は、インバウンド注文または再チェック注文に対して均一に、取引を所望しまたは所望しないからである。このコンセプトをＴＬＬオーダブックの各パーティションに対して適用することにより、ＴＬＬはインバウンド注文または再チェック注文に対して利用可能な株数を一定時間内で評価することができる。
【０１８９】
最小量ティアは、実行途中においても有用である。ブック全体の優先度でパーティションを再結合して実行する途中において、あるパーティションがインバウンド注文に対して最小量を満たさない場合、ＴＬＬマッチングエンジンはそのパーティションから注文を一切引き出さない。取引を所望するパーティションのみを結合することにより、どの注文がインバウンド注文に対して取引を所望するかに基づき、オーダブック全体をフィルタリングすることができる。これにより、最小量指示に基づき個々の注文を確認してスキップする必要がなくなり、演算効率を向上させることができる。
【０１９０】
＜最小量参加＞
残っている最小量注文が注文キューの前面にない場合、最小量の実装は制約される。十分に大きい積極的値付けした相対注文が到着したとしても、その注文はブック優先度において当該注文に先だって残注文に対して実行され、当該最小量注文に到達するときまでに十分な株数が残らない可能性がある。例えば、最小量５００株の１０００株注文よりも先に、１００株の買い注文がオーダブック内にあるものとする。５００株のインバウンド売り注文が到着すると、最初の買い注文と１００株取引し、４００株は残る。最小量注文は５００株未満では取引しないので、元の売り注文のサイズが最小量条件５００株を満たすとしても、残り４００株のインバウンド売り注文とは取引しないことになる。極端な例として、単元未満買い注文７５株の後に最小量条件１０００００株のブロック買い注文１０００００株がオーダブック内にあるものとする。インバウンド売り注文１０００００株が到着すると、７５株買い注文が実行され、９９９２５株が残る。９９９２５株はブック内の残買い注文の最小量条件１０００００株を満たさないので、２つのブロック注文はマッチングされない。
【０１９１】
ＴＬＬは、新たな最小量動作を用いる。これはＰａｒｔｉｃｉｐａｔｉｏｎ（参加）と呼ばれる。ＴＬＬの最少量注文の動作は、インバウンドの場合、上記実装と同一である。ただしオーダブック内に留まっている場合、注文の最少量条件は、実行プロセスの開始時に、最少量に対して実行を試みるとき、残り取引数ではなくインバウンド注文の取引数に対して評価される。これにより、最初の時点で最少量指示が存在した目的に寄与することができる。すなわち、実行する株と実行しないシグナル／取引情報との間のバランスを維持すること、および十分大きい株とやり取りすることである。
【０１９２】
上記ブロック注文の例において、１０００００株のインバウンド売り注文は、７５株の買い注文と取引される。元の注文サイズ１０００００株は、残買い注文１０００００株の最少量注文に合致するからである。残り１０００００株の買い注文は取引に“参加”し、９９９２５株を実行する。
【０１９３】
参加をパーティション化したオーダブックと組み合わせると、マッチングロジックはオーダブック内のオーダ数によらず、インバウンド注文または例チェック注文の最少量指示を満たすだけの十分な取引株をオーダブックが含んでいるか否かを高速に評価することができる。これにより、実行しない場合の演算負荷と時間を最小化することができる。
【０１９４】
＜ＴＬＬ＋１＞
ＴＬＬ＋１は、取引場所を選択し、投入する注文を取引場所に対してルーティングする。ＴＬＬ＋１は、注文を送信する場所を選択し、実行料金などのコストをバランスしつつ実行できる機会を最大化し、特定場所における注文の一部を常に表そうとするときの値付けによる影響を回避する。
【０１９５】
ＴＬＬ＋１は以下のように機能する：ＴＬＬ  Ｓｍａｒｔ  Ｏｒｄｅｒ  Ｒｏｕｔｅｒは、注文を分割して複数場所に留める決定をし、所望の場所を選択し、場合によっては少なくとも１つの追加場所を選択する。１つの場所が望ましい理由はいくつかある。例えばＴＬＬ自身が市場である場合、遠隔の取引場所に注文を送信して実行するよりもＴＬＬ上で注文を実行するほうが望ましい。追加場所を選択する理由は、望ましい取引場所はブローカが注文を送信する場所として最も選択する場所ではない可能性があり、よい追加取引場所を選択して注文を広告することにより実行を受け取る可能性が増すからである。追加取引場所は、市場状態と、各取引場所において注文が部分実行されるとき相殺側のブローカに対して課金される可能性がある料金と、に基づき選択することができる。ＴＬＬ  Ｓｍａｒｔ  Ｏｒｄｅｒ  Ｒｏｕｔｅｒは、現在ｉｎｓｉｄｅ  ｍａｒｋｅｔ（全米最良ビッドおよびオファー）で表されている取引場所のなかから選択することができる。注文を送信して既に全米最良ビッドまたはオファーで存在する市場のオーダブックに参加することにより、ｉｎｓｉｄｅで新たな取引場所を導入することが避けられ、すなわち値付けに対する影響を回避できる。これら取引場所の中で最もコスト効果が高いものが相殺側のブローカのために選択され、取引が生じる。ほとんどのブローカは、少なくとも部分的に経済状況に基づきルーティングを決定し、ＴＬＬによって他の取引場所にルーティングされた注文が市場価格内で流動性を有する最もコスト効果の高い注文となるようにする。ＴＬＬ注文は、他方の取引場所における注文よりも先に、他取引場所において実行される。
【０１９６】
注文が準備流動性を有している場合、すなわち注文の一部が表示され一部が隠れている場合、準備流動性は望ましい取引場所に留まる。これにより、注文の隠れた部分を最もよく制御することができる。
【０１９７】
準備注文の表示部分が充足されると、すなわち望ましい取引場所におけるものまたは追加取引場所におけるものが充足されると、望ましい取引場所における準備流動性は減少され、元の注文が充足された取引場所に対して新たな表示注文が送信される。ロジックは、一般的な準備注文の更新方法と同様に機能する。ただし、１つの市場センタではなく異なる市場センタにおいて注文が２つの（または多数の）表示部分を有する点を除く。
【０１９８】
最終的に、残りの準備流動性がないときいずれかの部分が完全に充足されると、他方の取引場所で残っている株は注文が完全充足される取引場所に対して再ルーティングされる。
【０１９９】
＜バイナリサーチツリー＞
本システムは、汎用目的コンピュータの揮発性メモリ内に実装され、または物理コンピュータ読取可能媒体上に実装された、ツリーデータ構造に関する。ツリーは複数のデータノードを有する。各データノードは、数値キー、そのキーに対応するゼロ以上のデータ値、および子ノードとして指定された他データノードに対する参照（すなわち左子ノードと右子ノード）、を含む。各参照はｎｕｌｌ参照でもよい。親ノードの子ノード、その子ノードの子ノード、などは親ノードの下位ノードである。親ノードがｎｕｌｌではない左子ノードを有している場合、その左子ノードの数値キーとその左子ノードの各下位ノードは、親ノードの数値キー未満でなければならない。同様に右子ノードがｎｕｌｌでない場合、その右子ノードの数値キーとその右子ノードの各非ｎｕｌｌ下位ノードは、親ノードの数値キー超でなければならない。ツリーはルートノードとして指定されたノードを有し、これは他ノードの子ノードではない。
【０２００】
全ての数値キーは、有限範囲内に収まる。各ノードの下位ノードの数値キーが取り得る範囲は、当該ノード自身が取り得る値範囲により定まる。親データ構造内において、各子ノードの値は、当該ノードが取り得る値範囲から計算により生成される。キーとこれに対応するデータ値がツリーに追加されると、ツリーはルートノードからキーが配置されている場所までスキャンされる。子ノードに対するｎｕｌｌ参照に到達すると、当該キーについて計算生成した値とともに新データノードが生成され、ゼロデータ値、左右子ノードに対するｎｕｌｌ参照、スキャンしたノードにおけるｎｕｌｌ参照は、新ノードに対する参照によって置き換えられる。追加するキーを有するノードに到達すると、対応するデータに対する参照が、到達したノードに対して追加される。このようにツリー構造は、各場所においてキーを決定的に生成することにより、あらかじめ定義される。キー生成のために用いる方法の選択により、既知の最大ノード深度を有する自動バランスされたツリーが正確に生成される。このとき、ツリーに対してキーを挿入する順番は関係ない。最大ノード深度は固定され、ツリーは再バランスされないので、最悪の挿入時間は再バランスが必要なツリーと比較して非常に小さい。よってこのツリーは、金融取引システムのように高信頼性が求められるアプリケーションに適している。
【０２０１】
本発明の望ましい実施形態において、キー値を事前定義する方法は、ノードが取り得るキー値範囲の中央を選択することである。ただしその他方法も本発明の範囲内で用いることができる。オプションとして、ルートノードとその下のルートノードレイヤは、手動で定めたキー値と、上述の規定キー値を有する下位ノードとを最初に有するようにしてもよい。
【０２０２】
他オプションとして、非ｎｕｌｌデータを有する全ノードが、ルートノード以外のノードが取り得る値範囲内のキーを有する場合、そのノードは“一時的ルートノード”として指定することができ、元のルートノードに代えて全ツリーをスキャンする開始点として用いることができる。一時的ルートノードの範囲外のキーがツリーに対して追加されると、一時的ルートノード指定は削除され、元のルートノードまたは新たに指定された一時的ルートノードを開始点としてツリーをスキャンすることができる。
【０２０３】
別実施例は、値を有する可能性があるノードに対する参照アレイによってツリーを補うことである。例えば金融商品取引場所のオーダブックの場合において、アレイは前日のクローズ価格範囲内のビッド／オファー価格を含む。可能性があるノードアレイに対するインデックスは、数値キー値から計算される。ノードが“可能性のある”キーによってアクセスされる場合、ツリーに優先してアレイを用いる。ツリーは、新規挿入するときと、アレイの範囲外の“可能性がなさそうな”キーの場合のみ用いられる。
【０２０４】
上記発明は、金融商品の売買注文を価格順で整理するために用いることができる。この目的のため、注文価格を数値キーとして用い、注文に関するその他情報は関連データとして格納される。ツリーは、価格順で整列された全ノードのリンクリストとともに用いられる。このリンクは、現在の最高価格買い注文と最低価格売り注文（最良ビッド／オファー）を有するノードに対するリンクを有する。ツリーを用いて、リンクリストをスキャンすることなく新規注文を高速に挿入することを補助する。実行済注文の削除は、リンクリストを用いて実現される。実行は最良ビッド／オファーにおいて最も多く発生するからである。注文や子ノードを有していないノードは、ツリーとリンクリストから削除される。
【０２０５】
ただし本発明のアプリケーションは、この特定のアプリケーションよりも広く適用できる。本発明の範囲は、全ての可能な実施形態を包含するものと解釈すべきである。
【０２０６】
図８Ａは、ツリー構造におけるノードとその内容を示す。すなわち、数値キー、ノード配下に配置することができるキー範囲、値アレイ、左右子ノードに対する参照、である。
【０２０７】
図８Ｂは、ツリーの固定スケルトンを示す。取り得るキーは１〜１２の整数である。各ノードの値を生成するルールは、取り得る値範囲のミッドポイントを取り、ミッドポイントが取り得るキーでない場合は端数を切り捨てることである。各位置におけるノードのキー値はあらかじめ定められているが、必要なノードのみが割り当てられ、ツリーにおいてインスタンス化される。これにより、アレイのような事前割り当てするデータ構造と比較して、メモリを節約することができる。
【０２０８】
図８Ｃ〜図８Ｄは、１〜１２の範囲で新たなツリーを生成する様子、図８Ｂのミッドポイントルール、およびキー値７を挿入する様子を示す。最初に図３ａに示すようにルートはｎｕｌｌであり、ルートの範囲はツリーのフルレンジ１〜１２である。図８Ｄにおいて、ルートが生成されキー６が割り当てられる。これはレンジ１〜１２のミッドポイントを切り捨てたものである。７はキー値６よりも大きいので、ルートノードの右子ノード下に挿入される。図３ｃにおいて、ルートの右子がレンジ７〜１２で生成され、中央値９に切り捨てられる。７は９よりも小さいので、９の左子ノード下に配置される。最終的に図８Ｄにおいて、ノード９の左子ノードがレンジ７〜８で生成され、中央値７に切り捨てられる。このキーが挿入しようとしているものなので、関連値がキーノードに対して追加され、操作が完了する。ノード６と９がツリー内に存在しているが、関連値は割り当てられておらず、関連値を有するノード７とは異なる形式で表示されている。
【０２０９】
図８Ｄは、図３ｄに示すツリーに対してキー５を挿入する様子を示す。図８Ｄ．ａにおいて、キー６のルートノードからスキャンが開始する。５は６よりも小さいので、左子ノードが選択される。以下の図面において、図面を明確にするためｎｕｌｌ子ポインタは省略する。図８Ｄ．ｂにおいて、新ノードとして左子ノードが生成され、レンジ１〜５と値３を有する。キー５はこのノードの右子ノード下に配置される。図８Ｄ．ｃは、右子ノード３を生成する様子を示す。レンジは４〜５、値は４である。図８Ｄ．ｄは、ノード５の生成、ノード４の右子ノードの生成（レンジは５〜５）、およびそのノードの挿入を示す。ツリーには６ノードが存在し、そのうち２つが値を有し、４つは値を有していない。ノード配置は、図２のスケルトンツリーにおける配置と正確に対応しており、ツリーにより全てのキーとノードが同じ位置を有することを保証する。ツリーに対して挿入する順序は関係ない。
【０２１０】
＜ＴＬＬコントローラ＞
図９は、ＴＬＬコントローラ９０１のブロック図である。この実施形態において、ＴＬＬコントローラ９０１は、様々な技術および／またはその他関連データを介して、コンピュータとのやり取りを集約し、処理し、格納し、検索し、補助し、識別し、指示し、生成し、マッチングし、および／または促進する。
【０２１１】
ユーザ９３３ａは、人および／または他システムであり、情報技術システム（例えばコンピュータ）を備え、情報処理を実施する。コンピュータは、情報を処理するプロセッサを用いる。プロセッサ９０３は、中央演算装置（ＣＰＵ）と呼ばれる場合もある。プロセッサの１形態は、マイクロプロセッサである。ＣＰＵは通信回路を用いて、命令として動作するバイナリ符号化信号を送信し、様々な動作を実施する。これら命令は、動作命令および／またはデータ命令であり、他命令を含みおよび／または参照し、様々なプロセッサがアクセスして動作することができるメモリ領域９２９（例えばレジスタ、キャッシュメモリ、ランダムアクセスメモリなど）に格納される。通信命令は、プログラムとしておよび／またはデータコンポーネントとしてバッチで（例えばバッチ命令で）格納されおよび／または送信され、所望の動作を実施する。これら格納されている命令コード（例えばプログラム）は、ＣＰＵ回路部品やその他マザーボードおよび／またはシステムに組み込まれ、所望の動作を実施する。プログラムのタイプとしては例えばコンピュータオペレーティングシステムがあり、ＣＰＵがコンピュータ上でこれを実行する。オペレーティングシステムにより、ユーザはコンピュータ情報技術とリソースにアクセスし動作させることができる。情報技術システムが使用するリソースとしては以下が挙げられる：データがコンピュータに対して入力されまたはコンピュータから出ていく入出力メカニズム；データを保存するメモリストレージ；情報を処理するプロセッサ。これら情報技術システムを用いてデータを収集し、その後に取得し、分析し、操作する。これら動作はデータベースプログラムによりなされる。これら情報技術システムは、ユーザが様々なシステムコンポーネントにアクセスして操作するインターフェースを提供する。
【０２１２】
１実施形態において、ＴＬＬコントローラ９０１は以下のような構成要素と接続し、および／または通信することができる：ユーザ入力デバイス９１１からの１以上のユーザ；周辺デバイス９１２；予備暗号プロセッサデバイス９２８；および／または通信ネットワーク９１３。例えばＴＬＬコントローラ９０１は、ユーザ９３３ａ、クライアント操作デバイス９３３ｂと接続し、および／または通信することができる。クライアント操作デバイス９３３ｂは以下を含むが、これに限られない：パーソナルコンピュータ、サーバ、および／または様々なモバイルデバイス。モバイルデバイスは以下を含むが、これに限られない：携帯電話、スマートフォン（例えばｉＰｈｏｎｅ（登録商標）、Ｂｌａｃｋｂｅｒｒｙ（登録商標）、ＡｎｄｒｏｉｄＯＳベース携帯電話、など）、タブレットコンピュータ（例えばＡｐｐｌｅ  ｉＰａｄ（登録商標）、ＨＰ  Ｓｌａｔｅ、Ｍｏｔｏｒｏｌａ  Ｘｏｏｍ、など）、ｅＢｏｏｋリーダ（例えばＡｍａｚｏｎ  Ｋｉｎｄｌｅ、Ｂａｒｎｅｓ  ａｎｄ  ＮｏｂｌｅのＮｏｏｋ  ｅＲｅａｄｅｒ、など）、ラップトップコンピュータ、ノートブックコンピュータ、ネットブック、ゲーム端末（例えばＸＢＯＸ（登録商標）  Ｌｉｖｅ、Ｎｉｎｔｅｎｄｏ（登録商標）ＤＳ、Ｓｏｎｙ  ＰｌａｙＳｔａｔｉｏｎ（登録商標）Ｐｏｒｔａｂｌｅ、など）、携帯スキャナ、など。
【０２１３】
ネットワークは一般に、グラフトポロジーにおけるクライアント、サーバ、および中間ノードの相互接続と相互動作を備えるように構成される。本願における“サーバ”という用語は一般に、コンピュータ、その他デバイス、プログラム、あるいはこれらの組み合わせを指し、これらは通信ネットワークを介したリモートユーザのリクエストを処理し、これに応答する。サーバは、“クライアント”に対してリクエストするため情報を提供する。本願における“クライアント”という用語は一般に、コンピュータ。プログラム、その他デバイス、ユーザ、および／またはこれらの組み合わせを指す。これらはリクエストを処理および作成し、通信ネットワークを介してサーバからの応答を取得し処理することができる。情報とリクエストを処理し、および／または送信元ユーザから宛先に対して情報を引き渡す、コンピュータ、その他デバイス、プログラム、またはこれらの組み合わせは、“ノード”と呼ぶ。ネットワークは一般に、送信元から宛先に対して情報を伝搬しようとする。送信元から宛先に対して情報を引き渡すタスクを実施するノードは、“ルータ”と呼ばれる。ネットワークの形態としては例えば：ローカルエリアネットワーク（ＬＡＮ）、Ｐｉｃｏネットワーク、広域ネットワーク（ＷＡＮ）、無線ネットワーク（ＷＡＮ）などがある。例えばインターネットは一般に、複数ネットワークの相互接続として受け入れられている。これによりリモートクライアントとサーバは、互いにアクセスし相互動作することができる。
【０２１４】
ＴＬＬコントローラ９０１は、コンピュータシステムに基づく。このコンピュータシステムは、例えばメモリ９２９に接続されたコンピュータシステム９０２のようなコンポーネントを備えるが、これに限らない。
【０２１５】
＜コンピュータシステム＞
コンピュータシステム９０２は、クロック９３０、中央演算装置（ＣＰＵおよび／またはプロセッサ（これら用語は本明細書において明示しない限り相互交換可能である））９０３、メモリ９２９（例えば読取専用メモリ（ＲＯＭ）９０６、ランダムアクセスメモリ（ＲＡＭ）９０５など）、および／またはインターフェースバス９０６を備える。さらに必ずしも必要ではないが最もよく備えられているのは、相互接続されおよび／または通信可能なシステムバス９０４である。システムバス９０４は１以上のマザーボード９０２上に設けられている。マザーボード９０２は、導電および／または伝搬回路経路を有する。この回路経路を通じて、命令（例えばバイナリ符号化信号）が伝搬し、通信、動作、記憶などを実現する。コンピュータシステムは、電力ソース９８６に接続することができる。電力ソースは内部のものであってもよい。暗号プロセッサ９２６および／またはトランシーバ（例えばＩＣ）９６４は、システムバスに接続することができる。他実施形態において、暗号プロセッサおよび／またはトランシーバは、内部および／または外部周辺デバイス９１２としてインターフェースバスＩ／Ｏを介して接続することができる。トランシーバはアンテナ９６５に接続され、これにより無線通信と様々な通信および／またはセンサプロトコルの受信を可能にする。例えばアンテナは以下に接続することができる：Ｔｅｘａｓ  Ｉｎｓｔｒｕｍｅｎｔｓ  ＷｉＬｉｎｋ  ＷＬ１２８３  トランシーバチップ（例えば８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ（登録商標）３．０、ＦＭ、ＧＰＳ（これによりＴＬＬコントローラは位置を判定できる）を提供する）；Ｂｒｏａｄｃｏｍ  ＢＣＭ４３２９ＦＫＵＢＧ  トランシーバチップ（例えば８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ２．１＋ＥＤＲ、ＦＭなどを提供する）、ＢＣＭ２８１５０（ＨＳＰＡ＋）、およびＢＣＭ２０６６（Ｂｌｕｅｔｏｏｔｈ４．０、ＧＰＳなど）；Ｂｒｏａｄｃｏｍ  ＢＣＭ４６５０ＩＵ８８レシーバチップ（例えばＧＰＳ）；Ｉｎｆｉｎｅｏｎ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｘ−Ｇｏｌｄ６１８−ＰＭＢ９８００（例えば２Ｇ／３Ｇ  ＨＳＤＰＡ／ＨＳＵＰＡ通信を提供する）；Ｉｎｔｅｌ  ＸＭＭ６１６０（ＬＴＥ＆ＤＣ−ＨＳＰＡ）、Ｑｕａｌｃｏｍ  ＣＤＭＡ（２０００）、Ｍｏｂｉｌｅ  Ｄａｔａ／Ｓｔａｔｉｏｎ  Ｍｏｄｅｍ，Ｓｎａｐｄｒａｇｏ、など。システムクロックは水晶発振器を有し、コンピュータシステムの回路経路を介してベース信号を生成する。クロックは、システムバスおよび様々なクロック増幅器に接続される。クロック増幅器は、コンピュータシステムに相互接続された他コンポーネントのベース動作周波数を増減させる。クロックとコンピュータシステム内の各コンポーネントは、システム全体にわたって情報を格納する信号を駆動する。コンピュータシステム全体にわたって情報を格納した命令を送受信することは、通信と呼ばれる。これら通信命令は、さらに送受信され、本コンピュータシステムから通信ネットワーク、入力デバイス、他コンピュータシステム、周辺デバイス、などに対する応答を生じさせる。他実施形態において、上記各コンポーネントは互いに直接接続し、ＣＰＵに接続し、および／または多��なコンピュータシステムが採用する様々な変形物内に構成できることを理解されたい。
【０２１６】
ＣＰＵは、ユーザおよび／またはシステムが生成したリクエストを実行するプログラムコンポーネントを実行するのに適した少なくとも１つの高速データプロセッサを備える。プロセッサ自身は、様々な専用処理ユニットを備える場合もある。例えば浮動点演算ユニット、整数演算ユニット、統合システム（バス）コントローラ、論理演算ユニット、メモリ管理制御ユニット、などを含むが、これらに限らない。また、グラフィック処理ユニット、デジタル信号処理ユニット、などの専用サブユニットを含む場合もある。プロセッサは、内部高速アクセスアドレスメモリを備える場合もあり、メモリ９２９のマッピングやアドレシングをプロセッサ自身が実施することができる。内部メモリは以下を含むが、これらに限らない：高速レジスタ、様々なレベルのキャッシュメモリ（レベル１、２、３など）、ＲＡＭ、など。プロセッサは、メモリアドレス空間を介してこのメモリにアクセスする。メモリアドレス空間は、命令アドレスを介してアクセスすることができる。命令アドレスは、プロセッサが構築しデコードするものである、これにより、回路パスにアクセスしてメモリ状態／値を有する特定メモリアドレス空間に到達することができる。ＣＰＵは、例えば以下のようなマイクロプロセッサでもよい：ＡＭＤ  Ａｔｈｌｏｎ、Ｄｕｒｏｎ、および／またはＯｐｔｅｒｏｎ；従前のＡＲＭ（例えばＡＲＭ６／９／１１）、ｅｍｂｅｄｄｅｄ（Ｃｏｒｔｅｘ−Ｍ／Ｒ）、ａｐｐｌｉｃａｔｉｏｎ（Ｃｏｒｔｅｘ−Ａ）、ｅｍｂｅｄｄｅｄおよびｓｅｃｕｒｅプロセッサ；ＩＢＭおよび／またはＭｏｔｏｒｏｌａ  ＤｒａｇｏｎＢａｌｌおよびＰｏｗｅｒＰＣ；ＩＢＭおよびＳｏｎｙ  Ｃｅｌｌプロセッサ；Ｉｎｔｅｌ  Ａｔｏｍ、Ｃｅｌｅｒｏｎ（Ｍｏｂｉｌｅ）、Ｃｏｒｅ（２／Ｄｕｏ／ｉ３／ｉ５／ｉ６）、Ｉｔａｎｉｕｍ、Ｐｅｎｔｉｕｍ（登録商標）、Ｘｅｏｎ、および／またはＸＳｃａｌｅ；など。ＣＰＵは、命令を通過させる導体および／または伝搬経路（例えば（プリント）電子および／または光回路）を介してメモリと通信し、格納されている命令（すあんわちプログラムコード）を実行する。この命令引き渡しにより、ＴＬＬコントローラ内および各インターフェースを介した通信を実施する。処理要件が多大な速度および／または性能を必要とする場合、分散プロセッサ（例えばＤｉｓｔｒｉｂｕｔｅｄ  ＴＬＬ）、メインフレーム、マルチコア、パラレル、および／またはスーパーコンピュータアーキテクチャを同様に用いることができる。これに代えて、配置要件が可搬性を必要とする場合、小型モバイルデバイス（例えばスマートフォン、携帯個人端末（ＰＤＡ）など）を採用することができる。
【０２１７】
実装によっては、ＴＬＬの機能はマイクロコントローラを実装することによって実現できる。マイクロコントローラは例えば、ＣＡＳＴ  Ｒ８０５１ＸＣ２マイクロコントローラ、Ｉｎｔｅｌ  ＭＣＳ５１（すなわち８０５１マイクロコントローラ）、などである。ＴＬＬの機能を実装するため、組込コンポーネントを用いることもできる。例えば：特定用途集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ（ＦＰＧＡ）、および／または同様の組込技術である。例えばＴＬＬのコンポーネント集合（分散配置されているものでもよいしそれ以外でもよい）および／または機能は、マイクロプロセッサおよび／、または組込コンポーネントを用いて実装することができる。例えば：ＡＳＩＣ、コプロセッサ、ＤＳＰ、ＦＰＧＡ、など。これに代えてＴＬＬの機能は、多様な機能や信号処理を実現するように構成された組込コンポーネントにより実装することができる。
【０２１８】
実装によっては、組込コンポーネントは、ソフトウェア、ハードウェア、および／またはハードウェア／ソフトウェアの組み合わせを含むことができる。例えばＴＬＬ機能は、ＦＰＧＡを実装することにより実現できる。ＦＰＧＡは、“論理ブロック”というプログラム可能論理部品とプログラム可能相互接続を含む半導体デバイスである。ＦＰＧＡの例は、Ｘｉｌｉｎｘが製造する高性能ＦＰＧＡ  Ｖｉｒｔｅｘシリーズおよび／またはＳｐａｒｔａｎシリーズである。論理ブロックと相互接続は、ＦＰＧＡが製造された後、顧客や設計者によってプログラムすることができる。これにより、ＴＬＬ機能を実装する。プログラム可能相互接続の階層により、論理ブロックはＴＬＬシステム設計者／管理者が必要であれば相互接続することができる。これは１チッププログラム可能ｂｒｅａｄｂｏａｒｄに似ている。ＦＰＧＡの論理ブロックをプログラムして、ＡＮＤ、ＸＯＲなどの基本論理ゲートの動作、またはデコーダや簡易数式などのより複雑な演算子の組み合わせを実施することができる。多くのＦＰＧＡにおいて、論理ブロックもメモリを備える。このメモリは例えば、回路フリップフロップまたはより複雑なメモリブロックである。状況によっては、ＴＬＬを通常のＦＰＧＡ上に開発し、ＡＣＩＣにより近い固定バージョンに移行することもできる。代替または協調実装は、ＴＬＬコントローラ機能をＦＰＧＡに代えてまたはＦＰＧＡに加えて最終ＡＳＩＣに移行することができる。実装によっては、上記組込コンポーネントの全ておよびマイクロプロセッサは、ＴＬＬの“ＣＰＵ”および／または“プロセッサ”とみなすことができる。
【０２１９】
＜電力ソース＞
電力ソース９８６は、小型電子回路ボードデバイスに電力を供給する任意の標準形式のものを用いることができる。例えば以下のようなパワーセルである：アルカリ、リチウム水化物、リチウムイオン、リチウムポリマ、ニッケルカドミウム、太陽電池、など。その他タイプのＡＣまたはＤＣ電力ソースを用いることもできる。太陽電池の場合、１実施形態において、ケースは太陽電池が光エネルギーを取り込む開口を有する。パワーセル９８６は、相互接続されたＴＬＬコンポーネントの少なくとも１つと接続され、これにより相互接続された全コンポーネントに対して電流を提供する。１例において、電力ソース９８６はシステムバスコンポーネント９０４に接続される。代替実施形態において、Ｉ／Ｏインターフェース９０８をまたがる接続を介して、外部電力ソース９８６を提供することもできる。例えばＵＳＢおよび／またはＩＥＥＥ１３９４接続は、接続を通じてデータと電力をともに搬送し、したがって安定した電力ソースである。
【０２２０】
＜インターフェースアダプタ＞
インターフェースバス９０６は、複数のインターフェースアダプタに対して、受信し、接続し、および／または通信する。必須ではないが、アダプタカードの形態をとることができる。例えば以下を含むが、これらに限らない：入出力インターフェース（Ｉ／Ｏ）９０８、ストレージインターフェース９０９、ネットワークインターフェース９１０、など。暗号プロセッサインターフェース９２６も同様に、インターフェースバスに接続することができる。インターフェースバスは、インタ−フェースアダプタ同士の接続のために提供することもできるし、コンピュータステムの他コンポーネントのために提供することもできる。インターフェースアダプタは、適合するインターフェースバスのために調整することができる。インターフェースアダプタは、拡張および／またはスロットアーキテクチャを介してインターフェースバスに接続する。様々な拡張および／またはスロットアーキテクチャを採用することができる。例えば以下を含むがこれに限らない：Ａｃｃｅｌｅｒａｔｅｄ  Ｇｒａｐｈｉｃｓ  Ｐｏｒｔ（ＡＧＰ）、Ｃａｒｄ  Ｂｕｓ、ＥｘｐｒｅｓｓＣａｒｄ、（Ｅｘｔｅｎｄｅｄ）Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（（Ｅ）ＩＳＡ）、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）、ＮｕＢｕｓ、Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（Ｅｘｔｅｎｄｅｄ）（ＰＣＩ（Ｘ））、ＰＣＩ  Ｅｘｐｒｅｓｓ、Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ（ＰＣＭＣＩＡ）、Ｔｈｕｎｄｅｒｂｏｌｔ、など。
【０２２１】
ストレージインターフェース９０９は、複数のストレージデバイスに対して、受信し、通信し、および／または接続する。ストレージデバイスは例えば以下のようなものであるが、これに限らない：ストレージデバイス９１４、リムーバブルディスクデバイス、など。ストレージインターフェースは、通信プロトコルを採用することができる。通信プロトコルは例えば以下のものを含むが、これに限らない：（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）Ａｄｖａｎｃｅｄ  Ｔｅｃｈｎｏｌｏｇｙ  Ａｔｔａｃｈｍｅｎｔ（Ｐａｃｋｅｔ  Ｉｎｔｅｒｆａｃｅ）（（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）ＡＴＡ（ＰＩ））、（Ｅｎｈａｎｃｅｄ）Ｉｎｔｅｇｒａｔｅｄ  Ｄｒｉｖｅ  Ｅｌｅｃｔｒｏｎｉｃｓ（（Ｅ）ＩＤＥ）、Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）１３９４、Ｅｔｈｅｒｎｅｔ（登録商標）、ファイバチャネル、Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）、Ｔｈｕｎｄｅｒｂｏｌｔ、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）、など。
【０２２２】
ネットワークインターフェース９１０は、通信ネットワーク９１３に対して、受信し、通信し、および／または接続する。通信ネットワーク９１３を介して、ユーザ９３３ａはリモートクライアント９３３ｂ（例えばｗｅｂブラウザを備えるコンピュータ）経由でＴＬＬコントローラにアクセスすることができる。ネットワークインターフェースは、通信プロトコルを採用することができる。通信プロトコルは例えば以下のものがあるが、これに限らない：直接接続、Ｅｔｈｅｒｎｅｔ（ｔｈｉｃｋ、ｔｈｉｎ、ｔｗｉｓｔｅｄ  ｐａｉｒ  １０／１００／１０００Ｂａｓｅ  Ｔ、など）、トークンリング、ＩＥＥＥ８０２．１１ａ−ｘなどの無線接続、など。処理要件が多大な速度および／または性能を必要とする場合、分散ネットワークコントローラ（例えば分散ＴＬＬ）アーキテクチャを同様に採用して、ＴＬＬコントローラが必要とする通信帯域幅をプールし、負荷分散し、および／または増加させることができる。通信ネットワークは、以下のいずれかまたは組み合わせを用いることができる：直接相互接続；インターネット；ローカルエリアネットワーク（ＬＡＮ）；メトロポリタンエリアネットワーク（ＭＡＮ）；Ｏｐｅｒａｔｉｎｇ  Ｍｉｓｓｉｏｎｓ  ａｓ  Ｎｏｄｅｓ  ｏｎ  ｔｈｅ  Ｉｎｔｅｒｎｅｔ（ＯＭＮＩ）；セキュアカスタム接続；Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＷＡＮ）；無線ネットワーク（例えばＷｉｒｅｌｅｓｓ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＷＡＰ）、Ｉ−ｍｏｄｅなどのプロトコルを採用したものが挙げられるが、これらに限らない）；など。ネットワークインターフェースは、入出力インターフェースの特殊形態とみなすことができる。さらに複数のネットワークインターフェース９１０を用いて、様々な通信ネットワークタイプ９１３に接続することができる。例えば複数のネットワークインターフェースを用いて、ブロードキャスト、マルチキャスト、および／またはユニキャストネットワーク上で通信することができる。
【０２２３】
入出力インターフェース（Ｉ／Ｏ）９０８は、ユーザ入力デバイス９１１、周辺デバイス９１２、暗号プロセッサデバイス９２８、などに対して、受信し、通信し、および／または接続する。Ｉ／Ｏは、以下のような通信プロトコルを用いることができるが、これに限らない：オーディオ：アナログ、デジタル、モノラル、ＲＣＡ、ステレオ、など；データ：Ａｐｐｌｅ  Ｄｅｓｋｔｏｐ  Ｂｕｓ（ＡＤＢ）、Ｂｌｕｅｔｏｏｔｈ、ＩＥＥＥ１３９４ａ−ｂ、シリアル、ＵＳＢ；赤外線；ジョイスティック；キーボード；ｍｉｄｉ；光；ＰＣ  ＡＴ；ＰＳ／２；パラレル；無線；ビデオインターフェース：Ａｐｐｌｅ  Ｄｅｓｋｔｏｐ  Ｃｏｎｎｅｃｔｏｒ （ＡＤＣ）、ＢＮＣ、同軸、コンポーネント、コンポジット、デジタル、ＤｉｓｐｌａｙＰｏｒｔ、Ｄｉｇｉｔａｌ  Ｖｉｓｕａｌ  Ｉｎｔｅｒｆａｃｅ （ＤＶＩ）、ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ  ｍｕｌｔｉｍｅｄｉａ  ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ（登録商標））、ＲＣＡ、ＲＦ  ａｎｔｅｎｎａ、Ｓ−Ｖｉｄｅｏ、ＶＧＡ、など；無線トランシーバ：８０２．１１ａ／ｂ／ｇ／ｎ／ｘ；Ｂｌｕｅｔｏｏｔｈ；携帯（例えばｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ（ＣＤＭＡ）、ｈｉｇｈ  ｓｐｅｅｄ  ｐａｃｋｅｔ  ａｃｃｅｓｓ（ＨＳＰＡ（＋））、ｈｉｇｈ−ｓｐｅｅｄ  ｄｏｗｎｌｉｎｋ  ｐａｃｋｅｔ  ａｃｃｅｓｓ（ＨＳＤＰＡ）、ｇｌｏｂａｌ  ｓｙｓｔｅｍ  ｆｏｒ  ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、ＷｉＭａｘ、など）；など。出力デバイスは、例えばビデオディスプレイである。ビデオディスプレイは、以下の形態をとることができる：Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ（ＣＲＴ）、Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ（ＬＣＤ）、Ｌｉｇｈｔ  Ｅｍｉｔｔｉｎｇ  Ｄｉｏｄｅ（ＬＥＤ）、Ｏｒｇａｎｉｃ  Ｌｉｇｈｔ  Ｅｍｉｔｔｉｎｇ  Ｄｉｏｄｅ（ＯＬＥＤ）、プラズマ、など。ビデオディスプレイは、ビデオインターフェースから信号を受け取るインターフェース（例えばＶＧＡ、ＤＶＩ回路およびケーブル）を備える。ビデオインターフェースは、コンピュータシステムが生成した情報を複合し、複合した情報に基づきビデオメモリフレーム内でビデオ信号を生成する。他の出力デバイスは、例えばテレビセットである。テレビセットは、ビデオインターフェースから信号を受け取る。ビデオインターフェースは、ビデオディスプレイインターフェース（例えば、ＲＣＡコンポジットビデオケーブルを接続するＲＣＡコンポジットビデオコネクタ；ＤＶＩディスプレイケーブルを接続するＤＶＩコネクタ、ＨＤＭＩ（登録商標）など）を接続するビデオ接続インターフェースを介して複合ビデオ情報を提供する。
【０２２４】
ユーザ入力デバイス９１１は周辺デバイス９１２（下記参照）のタイプである場合もあり、以下を含む：カードリーダ、ドングル、指紋リーダ、グローブ、グラフィックタブレット、ジョイスティック、キーボード、マイクロフォン、マウス、リモコン、網膜リーダ、タッチスクリーン（容量型、抵抗型など）、トラックボール、センサ（例えば加速度計、環境光、ＧＰＳ、ジャイロスコープ、近接センサ、など）、スタイラス、など。
【０２２５】
周辺デバイス９１２は、Ｉ／Ｏおよび／または、ネットワークインターフェース、ストレージインターフェース、インターフェースバス直接、システムバス、ＣＰＵなどのその他デバイスと接続し、および／または通信することができる。周辺デバイスは、外部デバイス、内部デバイス、および／またはＴＬＬコントローラの一部である。周辺デバイスは以下を含む：アンテナ、オーディオデバイス（例えばｌｉｎｅ−ｉｎ、ｌｉｎｅ−ｏｕｔ、マイクロフォン入力、スピーカなど）、カメラ（例えば静止カメラ、ビデオカメラ、ｗｅｂｃａｍなど）、ドングル（例えばデジタル署名で安全な通信を保証するコピー保護したものなど）、外部プロセッサ（例えば暗号デバイス９２８などの追加機能のためのもの）、力フィードバックデバイス（例えば振動モータ）、近接場通信（ＮＦＣ）デバイス、ネットワークインターフェース、プリンタ、無線ＩＤ（ＲＦＩＤ）、スキャナ、ストレージデバイス、トランシーバ（例えば携帯、ＧＰＳなど）、ビデオデバイス（例えばゴーグル、モニタなど）、ビデオソース、など。周辺デバイスは、入力デバイスタイプを含む（例えばマイクロフォン、カメラなど）。
【０２２６】
ユーザ入力デバイスと周辺デバイスを採用してもよいが、ＴＬＬコントローラは組込デバイス、専用デバイス、および／またはモニタなし（すなわちヘッドなし）デバイスとして実装することもできる。この場合アクセスは、ネットワークインターフェース接続を介してなされる。
【０２２７】
マイクロコントローラ、プロセッサ９２６、インターフェース９２６、および／またはデバイス９２８などの暗号ユニットをＴＬＬに取り付け、および／またはＴＬＬと通信することができる。Ｍｏｔｏｒｏｌａ製のＭＣ６８ＨＣ１６マイクロコントローラを暗号ユニット内で用いることができる。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚ設定で１６ビット関和演算命令を利用し、５１２ビットＲＳＡプライベートキー動作を１秒以下で実施する。暗号ユニットは、通信エージェントからの通信認証をサポートし、匿名通信も許可する。暗号ユニットは、ＣＰＵの一部として構成することができる。同等のマイクロコントローラおよび／またはプロセッサを用いることもできる。その他商用利用可能な専用暗号プロセッサとして以下が含まれる：Ｂｒｏａｄｃｏｍ  ＣｒｙｐｔｏＮｅｔＸその他セキュリティプロセッサ；ｎＣｉｐｈｅｒ  ｎＳｈｉｅｌｄ （例えばＳｏｌｏ、 Ｃｏｎｎｅｃｔ、など）、ＳａｆｅＮｅｔ  Ｌｕｎａ  ＰＣＩ（例えば６１００）シリーズ；Ｓｅｍａｐｈｏｒｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ４０ＭＨｚ  Ｒｏａｄｒｕｎｎｅｒ１８４；ｓＭＩＰ（例えば２０８９５６）；Ｓｕｎ  Ｃｒｙｐｔｏｇｒａｐｈｉｃ  Ａｃｃｅｌｅｒａｔｏｒ（例えばＡｃｃｅｌｅｒａｔｏｒ６０００  ＰＣＩｅボード、Ａｃｃｅｌｅｒａｔｏｒ５００  Ｄａｕｇｈｔｅｒｃａｒｄ）；５００＋ＭＢ／ｓの暗号命令を実施できるＶｉａ  Ｎａｎｏ  Ｐｒｏｃｅｓｓｏｒ（例えばＬ２１００、Ｌ２２００、Ｕ２４００）ライン；ＶＬＳＩ  Ｔｅｃｈｎｏｌｏｇｙ  ３３ＭＨｚ  ６８６８；など。
【０２２８】
＜メモリ＞
一般に、プロセッサがストレージに影響を及ぼし、および／または情報を取得できるようにするデバイスは、メモリ９２９とみなすことができる。ただしメモリは代替可能な技術およびリソースであり、よって任意個数のメモリを代わりにまたは連携して用いることができる。ＴＬＬコントローラおよび／またはコンピュータシステムは、様々な形態のメモリ９２９を採用できることを理解されたい。例えばコンピュータシステムは、オンチップＣＰＵメモリ、ＲＡＭ、ＲＯＭ、その他ストレージデバイスが紙パンチテープまたは紙パンチカードによって提供されるように構成することができる。ただしそのような実施形態は、動作レートが非常に遅い。１実施例においてメモリ９２９は、ＲＯＭ９０６、ＲＡＭ９０５、ストレージデバイス９１４を含む。ストレージデバイス９１４は、任意個数のコンピュータストレージデバイス／システムを採用することができる。ストレージデバイスは以下を含む：ドラム；（固定および／またはリムーバブル）磁気ディスクドライブ；光磁気ドライブ；光ドライブ（すなわちＢｌｕｅｒａｙ、ＣＤ  ＲＯＭ／ＲＡＭ／ＲｅｃｏＴＬＬｂｌｅ（登録商標）／ＲｅＷｒｉｔａｂｌｅ（ＲＷ）、ＤＶＤ  Ｒ／ＲＷ、ＨＤ  ＤＶＤ  Ｒ／ＲＷなど）；デバイスアレイ（例えばＲＡＩＤ）；固体メモリデバイス（ＩＳＢメモリ、ｓｏｌｉｄ  ｓｔａｔｅドライブ（ＳＳＤ）など）；その他プロセッサ読取可能記憶媒体；など。よってコンピュータシステムは一般に、メモリを利用する。
【０２２９】
＜コンポーネントコレクション＞
メモリ９２９は、プログラムおよび／またはデータベースコンポーネントおよび／またはデータのコレクションを含む。例えば以下を含むがこれに限らない：ＯＳコンポーネント９１５（オペレーティングシステム）；情報サーバコンポーネント９１６（情報サーバ）；ユーザインターフェースコンポーネント９１６（ユーザインターフェース）；Ｗｅｂブラウザコンポーネント９１８（Ｗｅｂブラウザ）；データベース９１９；メールサーバコンポーネント９２１；メールクライアントコンポーネント９２２；暗号サーバコンポーネント９２０（暗号サーバ）；ＴＬＬコンポーネント９３５；など（すなわちまとめてコンポーネントコレクション）。これらコンポーネントは、ストレージデバイスに格納し、ストレージデバイスからアクセスし、および／またはインターフェースバスを介してアクセスできるストレージデバイスからアクセスすることができる。上記コンポーネントコレクションのようなプログラムコンポーネントはローカルストレージデバイス９１４に格納することができるが、メモリに読み出し、および／または格納することができる。メモリは例えば以下を含む：周辺デバイス、ＲＡＭ、通信ネットワークを介したリモートストレージ、ＲＯＭ、様々なメモリ、など。
【０２３０】
＜オペレーティングシステム＞
ＯＳコンポーネント９１５は、実行可能プログラムコンポーネントであり、ＴＬＬコントローラの動作を実施する。オペレーティングシステムは、Ｉ／Ｏ、ネットワークインターフェース、周辺デバイス、ストレージデバイス、などへのアクセスを実施する。オペレーティングシステムは、フォールトトレランスが高くスケーラブルでセキュアなシステムである。例えば以下を含む：Ａｐｐｌｅ  Ｍａｃｉｎｔｏｓｈ  ＯＳ  Ｘ（サーバ）；ＡＴ＆Ｔ  Ｐｌａｎ  ９；Ｂｅ  ＯＳ；Ｕｎｉｘ（登録商標）およびＵｎｉｘライクなシステム（例えばＡＴ＆Ｔ  ＵＮＩＸ；Ｂｅｒｋｌｅｙ  Ｓｏｆｔｗａｒｅ  Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＢＳＤ）系列、例えばＦｒｅｅＢＳＤ、ＮｅｔＢＳＤ、ＯｐｅｎＢＳＤなど；Ｌｉｎｕｘ（登録商標）ディストリビューション、例えばＲｅｄＨａｔ、Ｕｂｕｎｔｕなど）；その他同様のＯＳ。ただしより限定的および／またはセキュリティの低いＯＳを採用することもできる。例えば：Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ  ＯＳ、ＩＢＭ  ＯＳ／２、Ｍｉｃｒｏｓｏｆｔ  ＤＯＳ、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）２０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ＮＴ／Ｖｉｓｔａ／ＸＰ（サーバ）、ＰａｌｍＯＳ、など。また、モバイルＯＳを採用することもできる。例えば：Ａｐｐｌｅ  ｉＯＳ、Ｇｏｏｇｌｅ  Ａｎｄｒｏｉｄ、Ｈｅｗｌｅｔｔ  Ｐａｃｋａｒｄ  ＷｅｂＯＳ、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  Ｍｏｂｉｌｅ、など。これらＯＳは、ＮＩＣコントローラのハードウェアに組み込み、および／またはメモリ／ストレージに格納／読み出すことができる。ＯＳは、コンポーネントコレクションの他コンポーネントと通信することができる。ＯＳは他プログラムコンポーネント、ユーザインターフェースなどと通信する。例えばＯＳは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを含み、通信し、生成し、取得し、および／または提供する。ＣＰＵがＯＳを実行すると、通信ネットワーク、データ、Ｉ／Ｏ、周辺デバイス、プログラムコンポーネント、メモリ、ユーザ入力デバイスなどとの通信が可能になる。ＯＳは、通信プロトコルを提供する。通信プロトコルにより、ＴＬＬコントローラは通信ネットワーク９１３を介して他構成要素と通信することができる。ＴＬＬコントローラは、サブスクライバ通信メカニズムとして様々な通信プロトコルを使用することができる。例えばマルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャストなどを含むが、これに限らない。
【０２３１】
＜情報サーバ＞
情報サーバコンポーネント９１６は、ＣＰＵが実行するプログラムコンポーネントである。情報サーバは例えばインターネット情報サーバであり、以下を含むがこれに限らない：Ａｐａｃｈｅ  Ｓｏｆｔｗａｒｅ  ＦｏｕｎｄａｔｉｏｎのＡｐａｃｈｅ、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒ、など。情報サーバにより、プログラムコンポーネントを実行することができる。例えば以下のような機能を介して実行する：Ａｃｔｉｖｅ  Ｓｅｒｖｅｒ  Ｐａｇｅ（ＡＳＰ）、ＡｃｔｉｖｅＸ、 （ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、および／または．ＮＥＴ、Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）スクリプト、ｄｙｎａｍｉｃ（Ｄ） ｈｙｐｅｒｔｅｘｔ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ（ＨＴＭＬ）、ＦＬＡＳＨ（登録商標）、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｒａｃｔｉｃａｌ  Ｅｘｔｒａｃｔｉｏｎ  Ｒｅｐｏｒｔ  Ｌａｎｇｕａｇｅ（ＰＥＲＬ）、Ｈｙｐｅｒｔｅｘｔ  Ｐｒｅ−Ｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、パイプ、Ｐｙｔｈｏｎ、ｗｉｒｅｌｅｓｓ  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ（ＷＡＰ）、ＷｅｂＯｂｊｅｃｔｓ、など。情報サーバは、セキュア通信プロトコルをサポートする。例えば以下を含むがこれに限らない：Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＦＴＰ）；ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）；Ｓｅｃｕｒｅ  Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）、メッセージングプロトコル（例えばＡｍｅｒｉｃａ  Ｏｎｌｉｎｅ（ＡＯＬ）Ｉｎｓｔａｎｔ  Ｍｅｓｓｅｎｇｅｒ（ＡＩＭ）、Ａｐｐｌｅ  ｉＭｅｓｓａｇｅ、Ａｐｐｌｉｃａｔｉｏｎ  Ｅｘｃｈａｎｇｅ（ＡＰＥＸ）、ＩＣＱ、Ｉｎｔｅｒｎｅｔ  Ｒｅｌａｙ  Ｃｈａｔ（ＩＲＣ）、Ｍｉｃｒｏｓｏｆｔ  Ｎｅｔｗｏｒｋ（ＭＳＮ）Ｍｅｓｓｅｎｇｅｒ  Ｓｅｒｖｉｃｅ、Ｐｒｅｓｅｎｃｅ  ａｎｄ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ（ＰＲＩＭ）、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ（ＳＩＰ）、ＳＩＰ  ｆｏｒ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｌｅｖｅｒａｇｉｎｇ  Ｅｘｔｅｎｓｉｏｎｓ（ＳＩＭＰＬＥ）、ｏｐｅｎ  ＸＭＬ−ｂａｓｅｄ  Ｅｘｔｅｎｓｉｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ） （すなわち、Ｊａｂｂｅｒ  ｏｒ  Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ（ＯＭＡ）Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｓｅｒｖｉｃｅ（ＩＭＰＳ））、Ｙａｈｏｏ！  Ｉｎｓｔａｎｔ  Ｍｅｓｓｅｎｇｅｒ  Ｓｅｒｖｉｃｅ、など。情報サーバは、Ｗｅｂブラウザに対してＷｅｂページの形態で結果を提供し、他プログラムコンポーネントとのやり取りを通じてＷｅｂページの生成を操作する。ＨＴＴＰリクエストのうちＤｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ  （ＤＮＳ）が解決する部分が情報サーバに対して提供されると、情報サーバはＨＴＴＰリクエス���の残部分に基づきＴＬＬコントローラ上の特定場所における情報リクエストを取得する。例えばリクエストｈｔｔｐ：／／１２３．１２４.１２５．１２６／ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌは、ＤＮＳサーバが解決して情報サーバに対して提供するＩＰ部分“１２３．１２４.１２５．１２６”を有する。情報サーバは次に、ｈｔｔｐリクエストをパースして“／ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌ”部分を取得し、“ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌ”を含むメモリ位置を特定する。その他情報提供プロトコルを様々なポートで用いることもできる。例えばポート２１のＦＴＰ通信などである。情報サーバは、コンポーネントコレクションの他コンポーネントと通信する。情報サーバは、ＴＬＬデータベース９１９、ＯＳ，他プログラムコンポーネント、ユーザインターフェース、Ｗｅｂブラウザ、などと通信する。
【０２３２】
ＴＬＬデータベースは、データベースブリッジメカニズムを介して実現することができる。例えば以下に列挙するスクリプト言語（例えばＣＧＩ）や、以下に列挙するアプリケーション間通信チャネル（例えばＣＯＲＢＡ、ＷｅｂＯｂｊｅｃｔｓなど）を用いることができる。Ｗｅｂブラウザを介したデータリクエストは、ブリッジメカニズムを介してパースされ、ＴＬＬが要求する適切な文法に変換される。１実施形態において情報サーバは、Ｗｅｂブラウザがアクセス可能なＷｅｂフォームを提供することができる。Ｗｅｂフォーム上で提供するフィールドに対する入力は、入力した旨をタグ付され、そのようにパースされる。入力された語句はフィールドタグとともに引き渡され、適当なテーブルおよび／またはフィールドへのクエリを生成するようパーサに対して指示する。１実施形態においてパーサは、タグ付けされたテキスト入力に基づき適当なｊｏｉｎ／ｓｅｌｅｃｔコマンドを含む検索文字列を有する標準ＳＱＬクエリを生成する。得られたコマンドは、ブリッジメカニズムを通じてＴＬＬに対してクエリとして提供される。クエリから結果を生成するとき、その結果はブリッジメカニズムを介して引き渡され、ブリッジメカニズムは整形パースして新たな結果Ｗｅｂページを生成する。新たな結果Ｗｅｂページは情報サーバに対して提供され、情報サーバはこれをリクエスト元のＷｅｂブラウザへ提供する。
【０２３３】
情報サーバは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを、含み、通信し、生成し、取得し、および／または提供する。
【０２３４】
＜ユーザインターフェース＞
コンピュータインターフェースは、自動車操作インターフェースに似ている。ステアリングホイール、ギアシフト、スピードメータなどの自動車操作インターフェース要素は、自動車リソースとステータスに対してアクセスし、操作し、表示する。チェックボックス、カーソル、メニュー、スクローラ、ウィンドウ（まとめてウィジェット）などのコンピュータ操作インターフェース要素も同様に、データ、コンピュータハードウェア、ＯＳリソース、ステータスに対するアクセス、性能、操作、表示を実施する。操作インターフェースは一般にユーザインターフェースと呼ばれる。グラフィカルユーザインターフェース（ＧＵＩ）は、基本機能および情報にアクセスしグラフィカル表示する手段をユーザに対して提供する。ＧＵＩの例は以下である：Ａｐｐｌｅ  Ｍａｃｉｎｔｏｓｈ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  ＡｑｕａとｉＯＳ  Ｃｏｃｏａ  Ｔｏｕｃｈ、ＩＢＭ  ＯＳ／２、Ｇｏｏｇｌｅ  Ａｎｄｒｏｉｄ  Ｍｏｂｉｌｅ  ＵＩ、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ２０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ Ｍｏｂｉｌｅ／ＮＴ／ＸＰ／Ｖｉｓｔａ／６／８（すなわちＡｅｒｏ、Ｍｅｔｒｏ）、 Ｕｎｉｘ  Ｘ−Ｗｉｎｄｏｗｓ（例えば、以下のようなＵｎｉｘグラフィックインターフェースライブラリを含む：Ｋ  Ｄｅｓｋｔｏｐ  Ｅｎｖｉｒｏｎｍｅｎｔ（ＫＤＥ）、ｍｙｔｈＴＶ、ＧＮＵ  Ｎｅｔｗｏｒｋ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ  Ｅｎｖｉｒｏｎｍｅｎｔ（ＧＮＯＭＥ））、ｗｅｂインターフェースライブラリ（例えばＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔなど、以下のようなインターフェースライブラリ（ただしこれらに限らない）：Ｄｏｊｏ、ｊＱｕｅｒｙ（ＵＩ）、ＭｏｏＴｏｏｌｓ、Ｐｒｏｔｏｔｙｐｅ、ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ、ＳＷＦＯｂｊｅｃｔ、Ｙａｈｏｏ！  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）。
【０２３５】
ユーザインターフェースコンポーネント９１６は、ＣＰＵが実行するプログラムコンポーネントである。ユーザインターフェースは、ＯＳおよび／または上記動作環境が提供し、これらとともに提供され、および／またはこれら上に提供されるグラフィックユーザインターフェースである。ユーザインターフェースは、テキストおよび／またはグラフィカル機能を介して、プログラムコンポーネントおよび／またはシステム機能を表示し、実行し、相互やり取りし、操作し、および／または動作させる。ユーザインターフェースは、ユーザがコンピュータシステムに接触し、やり取りし、および／または操作する機能を提供する。ユーザインターフェースは、コンポーネントコレクションの他コンポーネントと通信する。ユーザインターフェースは、ＯＳ、他プログラムコンポーネント、などと通信する。ユーザインターフェースは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを、含み、通信し、生成し、取得し、および／または提供する。
【０２３６】
＜Ｗｅｂブラウザ＞
Ｗｅｂブラウザコンポーネント９１８は、ＣＰＵが実行するプログラムコンポーネントである。Ｗｅｂブラウザは、ハイパーテキストを見るアプリケーションであり、例えば以下のようなものである：Ｇｏｏｇｌｅ  （Ｍｏｂｉｌｅ）Ｃｈｒｏｍｅ、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ、Ａｐｐｌｅ  （Ｍｏｂｉｌｅ）Ｓａｆａｒｉ、Ａｐｐｌｅ  Ｃｏｃｏａ（Ｔｏｕｃｈ）オブジェクトクラスなどの組込ｗｅｂブラウザオブジェクト、など。１２８ビット（またはそれ以上）暗号をＨＴＴＰＳ、ＳＳＬなどにより提供し、セキュアＷｅｂブラウズを実施することができる。Ｗｅｂブラウザは、以下のような機能を介してプログラムコンポーネントを実行する：ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ｗｅｂブラウザプラグインＡＰＩ（例えばＣｈｒｏｍｅ、ＦｉｒｅＦｏｘ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ、Ｓａｆａｒｉ  Ｐｌｕｇ−ｉｎ、などのＡＰＩ）、など。Ｗｅｂブラウザおよび同様の情報アクセスツールは、ＰＤＡ、携帯電話、スマートフォン、および／またはモバイルデバイスに統合することができる。Ｗｅｂブラウザは、コンポーネントコレクションの他コンポーネントと通信することができる。Ｗｅｂブラウザは、情報サーバ、ＯＳ、統合プログラムコンポーネント（例えばプラグイン）などと通信する。Ｗｅｂブラウザは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを、含み、通信し、生成し、取得し、および／または提供する。Ｗｅｂブラウザと情報サーバに代えて、組み合わせアプリケーションを開発し、これら双方と同様の動作を実施することもできる。組み合わせアプリケーションは同様に、ＴＬＬ実装ノードからユーザやユーザエージェントに対して情報取得または提供を実施する。組み合わせアプリケーションは、標準Ｗｅｂブラウザを採用したシステムにとっては無用である。
【０２３７】
＜メールサーバ＞
メールサーバコンポーネント９２１は、ＣＰＵ９０３が実行するプログラムコンポーネントである。メールサーバは、以下のようなインターネットメールサーバであるが、これらに限らない：Ａｐｐｌｅ  Ｍａｉｌ  Ｓｅｒｖｅｒ（３）、ｄｏｖｅｃｔ、ｓｅｎｄｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ、など。メールサーバにより、以下のような機能を介してプログラムコンポーネントを実行することができる：ＡＳＰ、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、および／または．ＮＥＴ、ＣＧＩスクリプト、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ＰＥＲＬ、ＰＨＰ、パイプ、Ｐｙｔｈｏｎ、ＷｅｂＯｂｊｅｃｔｓ、など。メールサーバは、以下のような通信プロトコルをサポートするが、これらに限らない：Ｉｎｔｅｒｎｅｔ  ｍｅｓｓａｇｅ  ａｃｃｅｓｓ  ｐｒｏｔｏｃｏｌ（ＩＭＡＰ）、Ｍｅｓｓａｇｉｎｇ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＭＡＰＩ）／Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ、ｐｏｓｔ  ｏｆｆｉｃｅ  ｐｒｏｔｏｃｏｌ（ＰＯＰ３）、ｓｉｍｐｌｅ  ｍａｉｌ  ｔｒａｎｓｆｅｒ  ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）、など。メールサーバは、ＴＬＬに対して送信され、リレーされ、および／または通過する発着メールメッセージをルーティングし、転送し、処理する。
【０２３８】
ＴＬＬメールへのアクセスは、個々のＷｅｂサーバコンポーネントおよび／またはＯＳが提供するＡＰＩを通じて実現できる。
【０２３９】
メールサーバは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを、含み、通信し、生成し、取得し、および／または提供する。
【０２４０】
＜メールクライアント＞
メールクライアントコンポーネント９２２は、ＣＰＵ９０３が実行するプログラムコンポーネントである。メールクライアントは、以下のようなメールを見るアプリケーションである：Ａｐｐｌｅ（Ｍｏｂｉｌｅ）Ｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ  Ｅｎｔｏｕｒａｇｅ、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ  Ｅｘｐｒｅｓｓ、Ｍｏｚｉｌｌａ、Ｔｈｕｎｄｅｒｂｉｒｄ、など。メールクライアントは、以下のような通信プロトコルをサポートする：ＩＭＡＰ、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ、ＰＯＰ３、ＳＭＴＰ、など。メールクライアントは、コンポーネントコレクションの他コンポーネントと通信することができる。メールクライアントは、メールサーバ、ＯＳ、他メールクライアントなどと通信する。メールクライアントは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを、含み、通信し、生成し、取得し、および／または提供する。一般にメールクライアントは、電子メールメッセージを編集し送信する機能を提供する。
【０２４１】
＜暗号サーバ＞
暗号サーバコンポーネント９２０は、ＣＰＵ９０３、あんふぉうプロセッサ９２６、暗号プロセッサインターフェース９２６、暗号プロセッサデバイス９２８などが実行するプログラムコンポーネントである。暗号プロセッサインターフェースにより、暗号コンポーネントは暗号および／または復号リクエストを実行する。ただし暗号コンポーネントはこれに代えて、ＣＰＵ上で動作することもできる。暗号コンポーネントにより、提供されたデータを暗号化しおよび／または復号化する。暗号コンポーネントにより、対称／非対称（例えばＰｒｅｔｔｙ  Ｇｏｏｄ  Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＰ））暗号および／または復号を実施することができる。暗号コンポーネントは、以下のような暗号技術を採用できるが、これらに限らない：デジタル証明書（例えばＸ．５０９認証フレームワーク）、デジタル署名、デュアル署名、ｅｎｖｅｌｏｐｉｎｇ署名、パスワードアクセス保護、公開鍵管理、など。暗号コンポーネントにより、以下のようなセキュリティプロトコル（暗号化および／または復号化）を実施することができるが、これらに限らない：ｃｈｅｃｋｓｕｍ、Ｄａｔａ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ（ＤＥＳ）、Ｅｌｌｉｐｔｉｃａｌ  Ｃｕｒｖｅ  Ｅｎｃｒｙｐｔｉｏｎ（ＥＣＣ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｄａｔａ  Ｅｎｃｒｙｐｔｉｏｎ  Ａｌｇｏｒｉｔｈｍ（ＩＤＥＡ）、Ｍｅｓｓａｇｅ  Ｄｉｇｅｓｔ  ５（ＭＤ５、１方向ハッシュ）、パスワード、Ｒｉｖｅｓｔ  Ｃｉｐｈｅｒ（ＲＣ５）、Ｒｉｊｎｄａｅｌ、ＲＳＡ（１９６６年にＲｏｎ  Ｒｉｖｅｓｔ、Ａｄｉ  Ｓｈａｍｉｒ、Ｌｅｏｎａｒｄ  Ａｄｌｅｍａｎが開発したアルゴリズムを用いるインターネット暗号および認証システム）、Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｈｍ（ＳＨＡ）、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）、Ｓｅｃｕｒｅ  Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）、など。これら暗号セキュリティプロトコルを用いて、ＴＬＬは全ての発着通信を暗号化し、より広い通信ネットワークを有する仮想プライベートネットワーク（ＶＰＮ）内のノードとして動作する。暗号コンポーネントは、“セキュリティ認証”プロセスを実施し、ソースに対するアクセスはセキュリティプロトコルによって禁止される。暗号コンポーネントは、セキュアリソースに対するアクセス認証を実施する。また暗号コンポーネントは、コンテンツのユニークＩＤを提供する。例えばＭＤ５ハッシュを採用してデジタルオーディオファイルのユニークＩＤを取得する。暗号コンポーネントは、ンポーネントコレクションの他コンポーネントと通信することができる。暗号コンポーネントは、通信ネットワーク上で情報を安全に送信する暗号方式をサポートし、ＴＬＬコンポーネントはこれによりセキュア通信を実施できる。暗号コンポーネントは、ＴＬＬ上のリソースに対するセキュアアクセスを実現し、リモートシステム上のリソースに対するセキュアアクセスを実現する。すなわち、セキュアリソースのクライアントおよび／またはサーバとして動作する。暗号コンポーネントは、情報サーバ、ＯＳ，他プログラムコンポーネントなどと通信する。暗号コンポーネントは、プログラムコン���ーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを、含み、通信し、生成し、取得し、および／または提供する。
【０２４２】
＜ＴＬＬデータベース＞
ＴＬＬデータベースコンポーネント９１９は、データベースとそのデータ内に実装することができる。データベースはプログラムコンポーネントであり、ＣＰＵが実行する。プログラムコンポーネントは、格納されているデータをＣＰＵに処理させる。データベースは、任意個数のフォールトトレラント、関係、スケーラブル、セキュアデータベースであり、例えばＤＢ２、ＭｙＳＱＬ、Ｏｒａｃｌｅ、Ｓｙｂａｓｅなどである。関係データベースは、フラットファイルの拡張である。関係データベースは、関係テーブルによって構成される。テーブルは、キーフィールドによって相互接続される。キーフィールドを用いて、キーフィールドに対してインデックスすることにより、テーブルを組み合わせることができる。キーフィールドは、複数のテーブルからの情報を組み合わせる次元ピボットポイントとして動作する。関係は一般に、プライマリキーをマッチングすることにより、テーブル間で維持されたリンクを識別する。プライマリキーは、関係データベース内のテーブルの行を一意に識別するフィールドを表す。より正確には、プライマリキーは１：多関係における“一方の”テーブルの行を一意に識別する。
【０２４３】
これに代えてＴＬＬデータベースは、様々な標準データ構造を用いて実装することができる。例えば、アレイ、ハッシュ（リンク）リスト、構造、構造化テキストファイル（例えばＸＭＬ）、テーブル、などである。このデータ構造は、メモリおよび／または（構造化）ファイルに格納することができる。他実施例において、オブジェクト指向データベースを用いることもできる。例えばＦｒｏｎｔｉｅｒ、ＯｂｊｅｃｔＳｔｏｒｅ、Ｐｏｅｔ、Ｚｏｐｅなどである。オブジェクトデータベースは、共通属性によりグループ化されおよび／またはリンクされたオブジェクトコレクションを含む。オブジェクトコレクションは、共通属性により他オブジェクトコレクションに関連付けることができる。オブジェクト指向データベースは、関係データベースと同様に動作する。ただし、オブジェクトは単なるデータではなくそのオブジェクトにカプセル化された機能タイプを有する点を除く。ＴＬＬデータベースがデータ構造として実装されている場合、ＴＬＬデータベース９１９をＴＬＬコンポーネント９３５などの他コンポーネントと統合して用いることができる。またデータベースは、データ構造、オブジェクト、関係構造の組み合わせとして実装することができる。データベースは、標準データ処理技術を通じて様々なバリエーションで統合しおよび／または分散させることができる。データベースの一部（例えばテーブル）は、エクスポートおよび／またはインポートすることができ、よって分割および／または統合することができる。
【０２４４】
１実施形態において、データベースコンポーネント９１９は、複数のテーブル９１９ａ−ｋを含む。ユーザテーブル９１９ａは、以下のようなフィールドを含むが、これらに限らない：ｕｓｅｒ＿ｉｄ、ｕｓｅｒ＿ｄｅｖｉｃｅ＿ｉｄ、ｕｓｅｒｎａｍｅ、ｐａｓｓｗｏｒｄ、ｄｏｂ、ｆｉｒｓｔ＿ｎａｍｅ、ｌａｓｔ＿ｎａｍｅ、ａｇｅ、ｓｔａｔｅ、ａｄｄｒｅｓｓ＿ｆｉｒｓｔｌｉｎｅ、ａｄｄｒｅｓｓ＿ｓｅｃｏｎｄｌｉｎｅ、ｚｉｐｃｏｄｅ、ｄｅｖｉｃｅｓ＿ｌｉｓｔ、ｃｏｎｔａｃｔ＿ｉｎｆｏ、ｃｏｎｔａｃｔ＿ｔｙｐｅ、ａｌｔ＿ｃｏｎｔａｃｔ＿ｉｎｆｏ、ａｌｔ＿ｃｏｎｔａｃｔ＿ｔｙｐｅ、など。ユーザテーブルは、ＴＬＬ上の複数要素のアカウントをサポートおよび／またはトラッキングする。データソーステーブル９１９ｂは、以下のようなフィールドを含むが、これに限らない：ｓｏｕｒｃｅ＿ＩＤ、ｓｏｕｒｃｅ＿ｎａｍｅ、ｓｏｕｒｃｅ＿ｓｅｒｖｅｒ＿ＩＤ、ｄｅｖｉｃｅ＿ｄｏｍａｉｎ、ｓｏｕｒｃｅ＿ｕｒｌ、ｓｏｕｒｃｅ＿ｓｅｃｕｒｉｔｙ＿ｐｒｏｔｏｃｏｌ、ｓｏｕｒｃｅ＿ｆｔｐ、ｄｅｖｉｃｅ＿ｓｅｃｕｒｅｋｅｙ、など。ＰＯＰテーブル９１９ｃは以下のようなフィールドを含むが、これに限らない： ｐｏｐ＿ｉｄ、ｐｏｐ＿ａｄｄｒｅｓｓ、ｐｏｐ＿ｓｅｒｖｅｒ＿ｉｐ、ｐｏｐ＿ｅｘｃｈａｎｇｅ、ｐｏｐ＿ｔｒａｎｓｍｉｔｔｉｏｎ＿ｔｉｍｅ、ｐｏｐ＿ｈｉｓｔｏｒｙ、など。インデックステーブル９１９ｄは以下のようなフィールドを含むが、これに限らない：ｉｎｄｅｘ＿ｉｄ、ｉｎｄｅｘ＿ｎａｍｅ、ｉｎｄｅｘ＿ａｔｔｒｉｂｕｔｅ、ｉｎｄｅｘ＿ｖａｌｕｅ、ｉｎｄｅｘ＿ｒａｔｅ、ｉｎｄｅｘ＿ｖｏｌｕｍｅ、ｉｎｄｅｘ＿ｔｉｍｅｓｔａｍｐ、ｉｎｄｅｘ＿ｓｏｕｒｃｅ、など。属性テーブル９１９ｅは以下のようなフィールドを含むが、これに限らない：ｇｅｏ−ｌｏｃａｔｉｏｎ、ｉｎｄｕｓｔｒｙ、ｓｉｚｅ、ｄａｉｌｙ＿ｖｏｌｕｍｅ、ｓｔｒａｔｅｇｙ＿ｔｙｐｅ、ｍａｘ＿ｓｉｚｅ、ｍｉｎ＿ｓｉｚｅ、ｔｒａｄｅ＿ｏｒｄｅｒ＿ｉｄ、など。ビッドテーブル９１９ｆは以下のようなフィールドを含むが、これに限らない：ｂｉｄ＿ｉｄ、ｂｉｄ＿ｔｉｍｅ、ｂｉｄ＿ａｔｔｒｉｂｕｔｅ、ｂｉｄ＿ａｄ＿ｔｙｐｅ、ｂｉｄ＿ａｄ＿ｎａｍｅ、ｂｉｄ＿ａｄ＿ｄｅｓｃｒｉｐｔｉｏｎ、ｂｉｄ＿ｒａｔｅ、ｂｉｄ＿ｒｅｓｕｌｔ、など。注文テーブル９１９ｇは以下のようなフィールドを含むが、これに限らない：ｏｒｄｅｒ＿ｉｄ、ｏｒｄｅｒ＿ｎａｍｅ、ｏｒｄｅｒ＿ｐａｒｔｉｃｉｐａｎｔ、ｏｒｄｅｒ＿ｕｓｅｒ＿ｉｄ、ｏｒｄｅｒ＿ｖｏｌｕｍｅ、ｏｒｄｅｒ＿ｂｉｄ＿ｉｄ、ｏｒｄｅｒ＿ｓｔａｔｕｓ、ｏｒｄｅｒ＿ｐｏｐ＿ｉｄ、ｏｒｄｅｒ＿ｌａｔｅｎｃｙ、ｏｒｄｅｒ＿ｒｏｕｔｉｎｇ、など。金融商品テーブル９１９ｈは以下のようなフィールドを含むが、これに限らない：ｉｎｓｔｒｕｍｅｎｔ＿ｉｄ、ｉｎｓｔｒｕｍｅｎｔ＿ｔｙｐｅ、ｉｎｓｔｒｕｍｅｎｔ＿Ｒｅｇ、ｉｎｓｔｒｕｍｅｎｔ＿ｓｔｒｕｃｔｕｒｅ、ｉｎｓｔｒｕｍｅｎｔ＿ａｓｓｅｔ＿ｉｄ、ｉｎｓｔｒｕｍｅｎｔ＿ｉｎｄｅｘ、ｉｎｓｔｒｕｍｅｎｔ＿ｉｎｄｅｘ＿ｖａｌｕｅ、ｉｎｓｔｒｕｍｅｎｔ＿ｅｘｃｈａｎｇｅ＿ｉｄ、など。分��テーブル９１９ｉは以下のようなフィールドを含むが、これに限らない： Ａｎａｌｙｔｉｃｓ＿ｉｄ、ａｎａｌｙｔｉｃｓ＿ｔｉｍｅ、ａｎａｌｙｓｔｉｃｓ＿ａｄ＿ｉｄ、ａｎａｌｙｔｉｃｓ＿ｓｏｕｒｃｅ＿ｉｄ、ａｎａｌｙｔｉｃｓ＿ｐｌｏｔ、ａｎａｌｙｔｉｃｓ＿ｐｒｅｊｅｃｔｉｏｎ、ａｎａｌｙｔｉｃｓ＿ｍａｐ、ａｎａｌｙｔｉｃｓ  ＵＩ＿ｔｅｍｐｌａｔｅ、ａｎａｌｙｔｉｃｓ＿ｂｕｙ＿ｐｏｉｎｔ、など。ニューステーブル９１９ｊは以下のようなフィールドを含むが、これに限らない：ｎｅｗｓ＿ｉｄ、ｎｅｗｓ＿ｔｉｍｅ、ｎｅｗｓ＿ｄａｔｅ、ｎｅｗｓ＿ｔｉｔｌｅ、ｎｅｗｓ＿ｓｏｕｒｃｅ、ｎｅｗｓ＿ｇｅｏ、ｎｅｗｓ＿ｚｉｐｃｏｄｅ、ｎｅｗｓ＿ｔｙｐｅ、ｎｅｗｓ＿ｉｎｄｕｓｔｒｙ、ｎｅｗｓ＿ｔａｒｇｅｔ＿ａｕｄｉｅｎｃｅ、ｎｅｗｓ＿ｉｍｐａｃｔ＿ａｕｄｉｅｎｃｅ、ｎｅｗｓ＿ｄｅｓｃｒｉｐｔｉｏｎ、ｎｅｗｓ＿ｔａｇ、など。市場データテーブル９１９ｋは以下のようなフィールドを含むが、これに限らない： ｍａｒｋｅｔ＿ｄａｔａ＿ｆｅｅｄ＿ＩＤ、ａｓｓｅｔ＿ＩＤ、ａｓｓｅｔ＿ｓｙｍｂｏｌ、ａｓｓｅｔ＿ｎａｍｅ、ｓｐｏｔ＿ｐｒｉｃｅ、ｂｉｄ＿ｐｒｉｃｅ、ａｓｋ＿ｐｒｉｃｅ、など。１実施形態において、市場データテーブルは市場データフィードによって埋めることができる（例えばＢｌｏｏｍｂｅｒｇ  ＰｈａｔＰｉｐｅ、Ｄｕｎ  ＆  Ｂｒａｄｓｔｒｅｅｔ、Ｒｅｕｔｅｒ  Ｔｉｂ、Ｔｒｉａｒｃｈなど）。これは例えば、Ｍｉｃｒｏｓｏｆｔ  Ａｃｔｉｖｅ  Ｔｅｍｐｌａｔｅ  Ｌｉｂｒａｒｙ  ａｎｄ  Ｄｅａｌｉｎｇ  Ｏｂｊｅｃｔ  Ｔｅｃｈｎｏｌｏｇｙ  リアルタイムツールキッＲｔｔ．Ｍｕｌｔｉを通じて実施できる。
【０２４５】
１実施形態において、ＴＬＬデータベースは他データベースシステムと通信する。例えばＴＬＬコンポーネントが分散データベース、クエリ、データアクセスを採用すると、ＴＬＬデータベースの組み合わせを単一データベースの統合データセキュリティレイヤとして取り扱うことができる。
【０２４６】
１実施形態において、ユーザプログラムは様々なユーザインターフェースを含むことができる。これらはＴＬＬを更新することができる。またアカウントは、環境やＴＬＬがサービスを提供する必要があるクライアントタイプに応じて、カスタムデータベーステーブルを必要とする場合がある。ユニークフィールドは、キーフィールドとして指定することができる。代替実施形態において、これらテーブルは自身のデータベースおよびデータベースコントローラ（すなわち各テーブルのデータベースコントローラ）に分離することができる。標準データ処理技術を用いて、いずれかをさらに複数のコンピュータシステムおよび／またはストレージデバイスに分散することができる。同様に分散データベースコントローラの構成は、データベースコンポーネント９１９ａ−ｋを統合しおよび／または分散させることにより、変更することができる。ＴＬＬは、データベースコントローラを介して、様々な設定、入力、パラメータをトラッキングするように構成することができる。
【０２４７】
ＴＬＬデータベースは、コンポーネントコレクションの他コンポーネントと通信することができる。ＴＬＬデータベースは、ＴＬＬコンポーネント、他プログラムコンポーネント、などと通信することができる。データベースは、他ノードおよびデータに関する情報を含み、保持し、提供することができる。
【０２４８】
＜ＴＬＬ＞
ＴＬＬコンポーネント９３５は、ＣＰＵが実行するプログラムコンポーネントである。１実施形態において、ＴＬＬコンポーネントは先の図面で説明したＴＬＬ機能の任意および／または全組み合わせを備えることができる。ＴＬＬは通信ネットワークを介して、情報、サービス、トランザクションにアクセスし、取得し、提供することができる。ＴＬＬの機能および実施形態は、データ送信要求を減少させてより効率的なデータ構造とメカニズムを用いて送信および格納することにより、ネットワーク効率を向上させる。その結果、より多くのデータをより短い時間で送信することができ、トランザクションに関するレイテンシーが減少する。多くの場合、ストレージ、送信時間、帯域幅要件、レイテンシーなどの減少は、ＴＬＬの機能をサポートするため必要な性能と構造インフラを減少させ、多くの場合はコスト、エネルギー消費／要件を減少させ、ＴＬＬの基盤インフラの寿命を延ばす。これはＴＬＬの信頼性を高める追加的利点である。同様に多くの機能およびメカニズムは、ユーザが使用しアクセスし易いように設計され、これによりＴＬＬの機能セットを利用する対象者を広げることができる。この使いやすさにより、ＴＬＬの信頼性を高めることができる。また機能セットは暗号コンポーネント９２０、９２６、９２８を通じて述べたように、向上したセキュリティを備えており、機能とデータに対するアクセスをより信頼性高くかつ安全にしている。
【０２４９】
ＴＬＬコンポーネントは、ＴＬＬコンポーネントを介してビッド／取引リクエスト（例えば図２の２０３参照）を変換する。例えば、市場データコレクション９４２、ＰＯＰ配置９４３、ＰＯＰルーティング９４４、注文実行９４５などを、取引レコード（例えば図２の２１８参照）などに変換し、ＴＬＬの使用はレイテンシーアービトラージおよび／またはオーダブックアービトラージを抑制する。
【０２５０】
ノード間の情報アクセスを可能にするＴＬＬコンポーネントは、標準開発ツールおよび言語により開発することができる。例えば以下を含むがこれらに限らない：Ａｐａｃｈｅオｋンぽー年と、アセンブリ、ＡｃｔｉｖｅＸ、バイナリ実行ファイル、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋），Ｃ＃、および／または．ＮＥＴ、データベースアダプタ、ＣＧＩスクリプト、Ｊａｖａ，ＪａｖａＳｃｒｉｐｔ、マッピングツール、手続型およびオブジェクト指向開発ツール、ＰＥＲＬ，ＰＨＰ，Ｐｙｔｈｏｎ、シェルスクリプト、ＳＱＬコマンド、ｗｅｂアプリケーションサーバ拡張、ｗｅｂ開発環境およびライブラリ（例えばＭｉｃｒｏｓｏｆｔ  ＡｃｔｉｖｅＸ、Ａｄｏｂｅ  ＡＩＲ、ＦＬＥＸ＆ＦＬＡＳＨ；ＡＪＡＸ；（Ｄ）ＨＴＭＬ；Ｄｏｊｏ、Ｊａｖａ；ＪａｖａＳｃｒｉｐｔ；ｊＱｕｅｒｙ（ＵＩ）；ＭｏｏＴｏｏｌｓ；Ｐｒｏｔｏｔｙｐｅ；ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ；Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）；Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ  Ｓｔａｔｅ  Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）；ＳＷＦＯｂｊｅｃｔ；Ｙａｈｏｏ！  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ；など）、ＷｅｂＯｂｊｅｃｔｓ、など。１実施形態において、ＴＬＬサーバは暗号サーバを採用し、通信を暗号化および復号化する。ＴＬＬコンポーネントは、コンポーネントコレクションの他コンポーネントなどと通信する。ＴＬＬコンポーネントは、ＴＬＬデータベース、ＯＳ、他プログラムコンポーネント、などと通信する。ＴＬＬは、プログラムコンポーネント、システム、ユーザ、および／またはデータ通信、リクエスト、および／またはレスポンスを含み、通信し、生成し、取得し、および／または提供する。
【０２５１】
＜分散ＴＬＬ＞
ＴＬＬノードコントローラコンポーネントの構造および／または動作は、任意の方法で組み合わせ、連結し、および／または分散させて、開発および／または配置を進めることができる。同様にコンポーネントコレクションは、任意の方法で組み合わせて、配置および／または開発を進めることができる。これを実現するため、コンポーネントを共通コードベースに統合し、またはオンデマンドでコンポーネントを動的に読みだして統合することができる。
【０２５２】
コンポーネントコレクションは、標準データ処理および／または開発技術を介して、様々な態様で統合しおよび／または分散させることができる。プログラムコンポーネントコレクション内のプログラムコンポーネントの複数のインスタンスは、単一ノード上および／または複数ノードにまたがってインスタンス化し、ロードバランスおよび／またはデータ処理技術を通じてパフォーマンスを向上させることができる。さらに単一インスタンスを複数コントローラおよび／またはストレージデバイス（例えばデータベース）に分散させることができる。全てのプログラムコンポーネントインスタンスおよび連動するコントローラは、標準データ処理通信技術を介してこれを実施できる。
【０２５３】
ＴＬＬコントローラの構成は、システム配置に依拠する。予算、性能、位置、および／またはハードウェアリソースなどの要因は、配置要件と構成に影響する。構成がより統合されおよび／または統合プログラムコンポーネントになるか否かによらず、より分散したプログラムコンポーネントになるか否かによらず、および／または統合コンポーネントと分散コンポーネントの組み合わせになるか否かによらず、データを通信し、取得し、および／または提供することができる。プログラムコンポーネントコレクションから共通コードベースへ統合したコンポーネントのインスタンスは、データを通信し、取得し、および／または提供することができる。これはアプリケーション内データ処理通信技術を通じて実現できる。例えば以下のようなものであるが、これに限らない：データ参照（例えばポインタ）、内部メッセージング、オブジェクトインスタンス変数通信、共有メモリ空間、変数引き渡し、など。
【０２５４】
コンポーネントコレクションコンポーネントが離散し、分割され、および／または互いに外部コンポーネントである場合、他コンポーネントに対するデータ通信、取得、および／または提供は、アプリケーション間データ処理通信技術を介して実現できる。例えば以下を含むがこれに限らない：Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）情報引き渡し；（Ｄｉｓｔｒｉｂｕｔｅｄ）Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ（（Ｄ）ＣＯＭ）、（Ｄｉｓｔｒｉｂｕｔｅｄ）Ｏｂｊｅｃｔ  Ｌｉｎｋｉｎｇ  ａｎｄ  Ｅｍｂｅｄｄｉｎｇ（（Ｄ）ＯＬＥ）、など）、Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＯＲＢＡ）、Ｊｉｎｉ  ｌｏｃａｌ  ａｎｄ  ｒｅｍｏｔｅ  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍ  ｉｎｔｅｒｆａｃｅ、ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、Ｒｅｍｏｔｅ  Ｍｅｔｈｏｄ  Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）、ＳＯＡＰ、プロセスパイプ、共有ファイル、など。アプリケーション間通信または単一コンポーネントのメモリ空間内でアプリケーション間通信として分離コンポーネント間で送信されたメッセージは、文法を生成しパースすることにより実施される。文法は、ｙａｃｃ、ＸＭＬなどの開発ツールを用いて開発できる。これにより、文法生成とパース機能を実現し、コンポーネント間の通信メッセージの基盤を形成することができる。
【０２５５】
例えば文法は、以下のようなＨＴＴＰ  ｐｏｓｔコマンドのトークンを認識するように、構成することができる：
ｗ３ｃ  −ｐｏｓｔ  ｈｔｔｐ：／／．．．Ｖａｌｕｅ１
【０２５６】
Ｖａｌｕｅ１はパラメータとして認識される。“ｈｔｔｐ：／／”は文法シンタックスの一部であり、その後はｐｏｓｔ値とみなすことができるからである。同様にこの文法において、変数“Ｖａｌｕｅ１”うぃ“ｈｔｔｐ：／／”ｐｏｓｔコマンドに挿入して送信することができる。文法シンタックスそのものは、構造化データとして提示することができる。この構造化データを解釈および／または用いて、パースメカニズムを生成することができる（例えばｌｅｘ、ｙａｃｃなどが処理するシンタックス記述テキストファイル）。パースメカニズムを生成および／またはインスタンス化すると、パースメカニズムは構造化データを処理し、および／またはパースする。構造化データは例えば以下のようなものであり、これらに限らない：文字（例えばタブ）区切りテキスト、ＨＴＭＬ、構造化テキストストリーム、ＸＭＬ、など。別実施形態において、アプリケーション間処理プロトコル自身が、統合されたおよび／または容易に利用できるパーサ（例えばＪＳＯＮ，ＳＯＡＰなどのパーサ）を備え、これらを用いてデータをパース（例えば通信）できる。さらにパース文法は、メッセージパースに用いることもできるし、以下のようなもののパースに用いることもできる：データベース、データコレクション、データストア、構造化データ、など。所望する構成は、コンテキスト、環境、システム配置要件に依拠する。
【０２５７】
例えば実施例において、ＴＬＬコントローラはＰＨＰスクリプトを実行する。ＰＨＰスクリプトは、情報サーバを通じてＳｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）ソケットサーバを実装する。情報サーバは、クライアントがデータを送信するサーバポート上で到着する通信を待ち受ける。フォーマットは例えばＪＳＯＮ形式である。到着した通信を識別すると、ＰＨＰスクリプトはクライアントデバイスから到着メッセージを読み取り、ＪＳＯＮエンコードされたテキストデータをパースし、ＪＳＯＮエンコードされたテキストデータから情報を抽出してＰＨＰスクリプト変数に格納し、そのデータ（例えばクライアント識別情報など）を保存、および／または抽出された情報は関係データベースに格納されＳｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ（ＳＱＬ）を用いてアクセスできる。ＰＨＰ／ＳＱＬコマンドの形式で記述され、ＪＳＯＮエンコード入力データをクライアントデバイスからＳＳＬ経由で受け取り、そのデータを抽出して変数に格納し、データベースに格納するプログラムリストを、以下に示す：
【数６】
2020205075.tif 000008
【０２５８】
以下のリソースを用いて、ＳＯＡＰパーサに関する実施形態を提供することができる：  ｈｔｔｐ：／／ｗｗｗ．ｘａｖ．ｃｏｍ／ｐｅｒｌ／ｓｉｔｅ／ｌｉｂ／ＳＯＡＰ／Ｐａｒｓｅｒ．ｈｔｍｌ
ｈｔｔｐ：／／ｐｕｂｌｉｃｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｔｉｖｉｈｅｌｐ／ｖ２ｒ１／ｉｎｄｅｘ．ｊｓｐ？ｔｏｐｉｃ＝／ｃｏｍ．ｉｂｍ．ＩＢＭＤＩ．ｄｏｃ／ｒｅｆｅｒｅｎｃｅｇｕｉｄｅ２９５．ｈｔｍ
【０２５９】
他のパーサ実施例は以下である：
ｈｔｔｐ：／／ｐｕｂｌｉｃｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｔｉｖｉｈｅｌｐ／ｖ２ｒ１／ｉｎｄｅｘ．ｊｓｐ？ｔｏｐｉｃ＝／ｃｏｍ．ｉｂｍ．ＩＢＭＤＩ．ｄｏｃ／ｒｅｆｅｒｅｎｃｅｇｕｉｄｅ２５９．ｈｔｍ
【０２６０】
これら全ては、参照により本願に組み込まれる。
【０２６１】
様々な課題を解決し技術を進めるため、本願“通信レイテンシーを平準化する装置、方法、およびシステム”（カバーページ、タイトル、ヘッダ、フィールド、背景技術、概要、図面の簡単な説明、発明を実施するための形態、特許請求の範囲、要約、図面、付録、など）は、特許請求する発明を実施する様々な形態を説明するためのものである。本願の進歩性および機能は、実施形態の代表例のみを示しており、それ以外を排除するものではない。これらは特許請求範囲の原理の理解を促し教示するためのみのものである。これらは特許請求する発明の全てを表しているものではないことを理解されたい。よって本発明の一部は本明細書には記載されていない。本発明の特定部分の代替実施形態は記載していない場合もあり、その代替実施形態は特許請求範囲から除外されたものと解釈すべきではない。それら実施形態は本発明と同じ原理を備え、等価なものである。よって、その他実施形態を利用でき、本発明の範囲および／または原理から逸脱することなく機能的、論理的、動作的、組織的、構造的、および／またはトポロジー的変更が可能であることを理解されたい。全ての実施例および／または実施形態は、本明細書全体を通じて非限定的なものである。記載していない実施形態は、スペースと繰り返しを避けるため以外のものとしてみなすべきではない。例えば、図面などに記載したデータフローシーケンス、プログラムコンポーネント（コンポーネントコレクション）、他コンポーネント、および／または機能セットの組み合わせの論理および／またはトポロジー構造は、固定された動作順序および／または配置に限定されるものではない。むしろ説明した順序は例示であり、等価で順序に関係しないものも本開示に含まれると解釈すべきである。さらに、これら機能は順次実行のみに限定されるものではなく、非同期、一斉、平行、同時、同期、などで実行する任意個数のスレッド、プロセス、プロセッサ、サービス、サーバ、なども本開示の範囲内であることを理解されたい。単一実施形態において同時に存在できない場合、これら機能は相互矛盾することもある。同様に機能のなかには、本発明の１側面に対して適用できるものもあり、他側面に対して適用できないものもある。出願人は、それら特許請求していない発明の全権利を留保する。これは、その発明を特許請求し、別出願し、継続出願し、一部継続出願し、および／または分割出願する権利を含む。本発明の利点、実施形態、実施例、機能、特徴、論理、動作、組織、構造、トポロジーに関する側面は、特許請求範囲が定義する本発明の限定、または特許請求範囲の等価物に対する限定とみなすべきではないことを理解されたい。ＴＬＬのニーズおよび／または特徴に応じて、個人および／または企業ユーザ、データベース構成および／または関係モデル、データタイプ、データ通信および／またはネットワークフレームワーク、シンタックス構造、すなわちＴＬＬの実施形態は、柔軟にカスタマイズ実装できることを理解されたい。例えばＴＬＬの側面は、データネットワーク帯域幅管理に合わせることができる。ＴＬＬの様々な実施形態は電子取引プラットフォームに関するものであるが、本実施形態はさまざまな他のアクションベースシステム、アプリケーション、および／または実装のために容易に構成および／またはカスタマイズできることを理解されたい。
【図１Ａ】
2020205075.tif 000009
【図１Ｂ】
2020205075.tif 000010
【図１Ｃ】
2020205075.tif 000011
【図１Ｄ】
2020205075.tif 000012
【図２】
2020205075.tif 000013
【図３】
2020205075.tif 000014
【図４Ａ】
2020205075.tif 000015
【図４Ｂ】
2020205075.tif 000016
【図５Ａ】
2020205075.tif 000017
【図５Ｂ】
2020205075.tif 000018
【図５Ｃ】
2020205075.tif 000019
【図６Ａ】
2020205075.tif 000020
【図６Ｂ】
2020205075.tif 000021
【図６Ｃ】
2020205075.tif 000022
【図６Ｄ】
2020205075.tif 000023
【図６Ｅ】
2020205075.tif 000024
【図６Ｆ】
2020205075.tif 000025
【図６Ｇ】
2020205075.tif 000026
【図６Ｈ】
2020205075.tif 000027
【図７】
2020205075.tif 000028
【図８Ａ】
2020205075.tif 000029
【図８Ｂ】
2020205075.tif 000030
【図８Ｃ】
2020205075.tif 000031
【図８Ｄ】
2020205075.tif 000032
【図９】
2020205075.tif 000033