JP6682514B2 - 半公開市場のためのシステム及び方法 - Google Patents
半公開市場のためのシステム及び方法 Download PDFInfo
- Publication number
- JP6682514B2 JP6682514B2 JP2017515239A JP2017515239A JP6682514B2 JP 6682514 B2 JP6682514 B2 JP 6682514B2 JP 2017515239 A JP2017515239 A JP 2017515239A JP 2017515239 A JP2017515239 A JP 2017515239A JP 6682514 B2 JP6682514 B2 JP 6682514B2
- Authority
- JP
- Japan
- Prior art keywords
- order
- trading
- market
- tll
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 102
- 238000004891 communication Methods 0.000 claims description 112
- 238000003860 storage Methods 0.000 claims description 33
- 230000033228 biological regulation Effects 0.000 claims description 12
- 230000001105 regulatory effect Effects 0.000 claims description 4
- 230000001276 controlling effect Effects 0.000 claims 1
- 238000012360 testing method Methods 0.000 description 78
- 230000005540 biological transmission Effects 0.000 description 71
- 230000015654 memory Effects 0.000 description 64
- 230000008569 process Effects 0.000 description 54
- 238000012545 processing Methods 0.000 description 42
- 230000008901 benefit Effects 0.000 description 29
- 238000010586 diagram Methods 0.000 description 27
- 238000005516 engineering process Methods 0.000 description 24
- 230000007246 mechanism Effects 0.000 description 17
- 230000008859 change Effects 0.000 description 16
- 239000000872 buffer Substances 0.000 description 15
- 230000006870 function Effects 0.000 description 14
- 230000009471 action Effects 0.000 description 13
- 230000002093 peripheral effect Effects 0.000 description 13
- 230000004044 response Effects 0.000 description 13
- 238000009826 distribution Methods 0.000 description 11
- 238000013515 script Methods 0.000 description 11
- 238000012937 correction Methods 0.000 description 10
- 239000000835 fiber Substances 0.000 description 9
- 238000013459 approach Methods 0.000 description 8
- 230000002349 favourable effect Effects 0.000 description 8
- 238000003780 insertion Methods 0.000 description 8
- 230000037431 insertion Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 8
- 238000011161 development Methods 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 5
- 239000002131 composite material Substances 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000005192 partition Methods 0.000 description 5
- 239000000047 product Substances 0.000 description 5
- 230000002829 reductive effect Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- PCTMTFRHKVHKIS-BMFZQQSSSA-N (1s,3r,4e,6e,8e,10e,12e,14e,16e,18s,19r,20r,21s,25r,27r,30r,31r,33s,35r,37s,38r)-3-[(2r,3s,4s,5s,6r)-4-amino-3,5-dihydroxy-6-methyloxan-2-yl]oxy-19,25,27,30,31,33,35,37-octahydroxy-18,20,21-trimethyl-23-oxo-22,39-dioxabicyclo[33.3.1]nonatriaconta-4,6,8,10 Chemical compound C1C=C2C[C@@H](OS(O)(=O)=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H]([C@H](C)CCCC(C)C)[C@@]1(C)CC2.O[C@H]1[C@@H](N)[C@H](O)[C@@H](C)O[C@H]1O[C@H]1/C=C/C=C/C=C/C=C/C=C/C=C/C=C/[C@H](C)[C@@H](O)[C@@H](C)[C@H](C)OC(=O)C[C@H](O)C[C@H](O)CC[C@@H](O)[C@H](O)C[C@H](O)C[C@](O)(C[C@H](O)[C@H]2C(O)=O)O[C@H]2C1 PCTMTFRHKVHKIS-BMFZQQSSSA-N 0.000 description 4
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 239000000344 soap Substances 0.000 description 4
- 239000000243 solution Substances 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000000052 comparative effect Effects 0.000 description 3
- 238000013480 data collection Methods 0.000 description 3
- 238000013467 fragmentation Methods 0.000 description 3
- 238000006062 fragmentation reaction Methods 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 239000013307 optical fiber Substances 0.000 description 3
- 230000036961 partial effect Effects 0.000 description 3
- 239000002957 persistent organic pollutant Substances 0.000 description 3
- 238000000275 quality assurance Methods 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 241000288673 Chiroptera Species 0.000 description 2
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 2
- 241000196324 Embryophyta Species 0.000 description 2
- WHXSMMKQMYFTQS-UHFFFAOYSA-N Lithium Chemical compound [Li] WHXSMMKQMYFTQS-UHFFFAOYSA-N 0.000 description 2
- 241001275944 Misgurnus anguillicaudatus Species 0.000 description 2
- 244000299461 Theobroma cacao Species 0.000 description 2
- 235000009470 Theobroma cacao Nutrition 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000013478 data encryption standard Methods 0.000 description 2
- 238000003066 decision tree Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000001976 improved effect Effects 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000001902 propagating effect Effects 0.000 description 2
- APTZNLHMIGJTEW-UHFFFAOYSA-N pyraflufen-ethyl Chemical compound C1=C(Cl)C(OCC(=O)OCC)=CC(C=2C(=C(OC(F)F)N(C)N=2)Cl)=C1F APTZNLHMIGJTEW-UHFFFAOYSA-N 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- FMFKNGWZEQOWNK-UHFFFAOYSA-N 1-butoxypropan-2-yl 2-(2,4,5-trichlorophenoxy)propanoate Chemical compound CCCCOCC(C)OC(=O)C(C)OC1=CC(Cl)=C(Cl)C=C1Cl FMFKNGWZEQOWNK-UHFFFAOYSA-N 0.000 description 1
- 240000001436 Antirrhinum majus Species 0.000 description 1
- 241000180579 Arca Species 0.000 description 1
- 241000010972 Ballerus ballerus Species 0.000 description 1
- 102100026816 DNA-dependent metalloprotease SPRTN Human genes 0.000 description 1
- 101710175461 DNA-dependent metalloprotease SPRTN Proteins 0.000 description 1
- 101001094649 Homo sapiens Popeye domain-containing protein 3 Proteins 0.000 description 1
- 101000608234 Homo sapiens Pyrin domain-containing protein 5 Proteins 0.000 description 1
- 101000578693 Homo sapiens Target of rapamycin complex subunit LST8 Proteins 0.000 description 1
- 101000771640 Homo sapiens WD repeat and coiled-coil-containing protein Proteins 0.000 description 1
- HBBGRARXTFLTSG-UHFFFAOYSA-N Lithium ion Chemical compound [Li+] HBBGRARXTFLTSG-UHFFFAOYSA-N 0.000 description 1
- 241001025261 Neoraja caerulea Species 0.000 description 1
- 208000003251 Pruritus Diseases 0.000 description 1
- 102100027802 Target of rapamycin complex subunit LST8 Human genes 0.000 description 1
- 241000289674 Vombatidae Species 0.000 description 1
- 102100029476 WD repeat and coiled-coil-containing protein Human genes 0.000 description 1
- 101100162169 Xenopus laevis adrm1-a gene Proteins 0.000 description 1
- MKUXAQIIEYXACX-UHFFFAOYSA-N aciclovir Chemical compound N1C(N)=NC(=O)C2=C1N(COCCO)C=N2 MKUXAQIIEYXACX-UHFFFAOYSA-N 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 229910052797 bismuth Inorganic materials 0.000 description 1
- OJIJEKBXJYRIBZ-UHFFFAOYSA-N cadmium nickel Chemical compound [Ni].[Cd] OJIJEKBXJYRIBZ-UHFFFAOYSA-N 0.000 description 1
- 238000013329 compounding Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 239000004020 conductor Substances 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 239000013078 crystal Substances 0.000 description 1
- 230000002354 daily effect Effects 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 238000013524 data verification Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 210000003128 head Anatomy 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 239000012464 large buffer Substances 0.000 description 1
- 239000007788 liquid Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 229910052744 lithium Inorganic materials 0.000 description 1
- 229910000103 lithium hydride Inorganic materials 0.000 description 1
- 229910001416 lithium ion Inorganic materials 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003472 neutralizing effect Effects 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 229920000642 polymer Polymers 0.000 description 1
- 238000003825 pressing Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 210000001525 retina Anatomy 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000003892 spreading Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/06—Asset management; Financial planning or analysis
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Technology Law (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Marketing (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
本願は、著作権、マスクワーク、及び／又は知的財産保護による保護を受ける内容を含む。この知的財産権の所有者は、本開示を特許庁ファイル／レコードにおける公開公報において、ファクシミリコピーすることにつき異議はない。その他の場合においては、全ての権利を留保する。
関連出願に対する相互参照
本出願は、米国仮出願番号第６１／７００，０９４号（２０１２年９月１２日出願）、第６１／７５３，８５７号（２０１３年１月１７日出願）、第６１／７５８，５０８号（２０１３年１月３０日出願）及び第６１／８７６，２００号（２０１３年９月１１日出願）の優先権を主張して２０１３年９月１２日に出願されたＰＣＴ国際出願第ＰＣＴ／ＵＳ１３／５９５５８号「TRANSMISSION LATENCY LEVELING APPARATUSES, METHODS AND SYSTEMS」に関連している。これらの特許出願の全ては、参照により全体が本明細書に組み込まれる。
本出願は、米国仮出願番号第６１／７００，０９４号（２０１２年９月１２日出願）、第６１／７５３，８５７号（２０１３年１月１７日出願）、第６１／７５８，５０８号（２０１３年１月３０日出願）及び第６１／８７６，２００号（２０１３年９月１１日出願）の優先権を主張して２０１３年９月１２日に出願されたＰＣＴ国際出願第ＰＣＴ／ＵＳ１３／５９５５８号「TRANSMISSION LATENCY LEVELING APPARATUSES, METHODS AND SYSTEMS」に関連している。これらの特許出願の全ては、参照により全体が本明細書に組み込まれる。
本明細書に開示される本発明は、包括的には、電子取引及び／又はオークションのための装置、方法、及びシステムに関する。詳しくは、本発明は、半公開市場のためのシステム及び方法に関する。
消費者は、オークションに基づくシステムを使用して、価値のある商品の売買を行う。このようなオークションベースのシステムは、オンラインショッピングサイト、オンラインチケット予約システム、電子市場、又は他の取引交換所を含むことができる。
金融投資の分野において、個人投資家及びトレーダは、電子取引プラットフォーム上で有価証券（株式及び債券等）、外貨及び金融派生商品を売買することができる。ＮＡＳＤＡＱ、ＮＹＳＥ Ａｒｃａ、Ｇｌｏｂｅｘ、ロンドン証券取引所、ＢＡＴＳ Ｄｉｒｅｃｔ Ｅｄｇｅ、Ｃｈｉ−ＸＧｌｏｂａｌ、ＴｒａｄｅＷｅｂ、ＩＣＡＰ、シカゴ商品取引所等のよく知られた電子取引プラットフォームは、買い手及び売り手が金融商品を売買するための情報技術インフラを有する。典型的には、トレーダは、パーソナルコンピュータユーザインタフェース等の電子端末を介して電子取引プラットフォームにビッドを提出し、電子取引プラットフォームは、通信ネットワークを介して、異なる取引エンティティのコンピュータ端末に金融商品のリアルタイム価格付けを反映するビッド及びアスク情報を送信する。
金融業界では、買い側投資家が、高頻度トレーダ（high frequency traders）のような市場の他のプレイヤによって利用されることなく、取引注文をルーティングし、約定できるように、市場センタ及び／又は取引所での電子取引システムの効率性と公正性を向上させる努力が行われている。多くの投資家は、証券市場における略奪的取引行為について十分な知識を有しておらず、ブローカまたはブローカ会社に完全に委託されている取引注文に対して何らかの支配権を行使できることを自覚していない場合がある。
更に、既存の私的及び公的市場センタ又は取引所が市場参加者に配信する取引情報は、少なすぎたり多すぎたりする傾向がある。この結果、幾つかの市場では、透明性が失われ、他の市場では、市場データが過剰供給され、何れの場合も投資家に対して不公正取引行為の機会が生じ、マーケットプレイスの信頼性が揺らぐ可能性がある。
また、既存の電子取引プラットフォームは、ブローカ又は証券会社が、顧客投資家にサービスを提供する際に、リスクがあるポジションを引き受けなくてはならない特定の状況において、リスクを緩和するのに役立つ効率的なメカニズムを欠いている。このようなサービス及び／又は関連する取引の多くは、手作業で及び／又は場当たり的に処理されるため、ブローカ及び／又は証券会社が不要に長く市場リスクに晒される可能性がある。
以上のように、電子取引のための現在のツール及び方法に関連する重大な問題及び欠点が存在することは、明らかである。
先行技術における上述及びこの他の問題及び欠点を克服するために、本出願は、電子取引を改善するための多くの技術を開示する。
本発明の幾つかの実施形態によれば、電子取引システムは、各参加者の取引注文が所定の閾値価格及び／又は閾値サイズ、又は他のパラメータを満たすか否かに応じて、取引参加者にオーダブックを選択的に開示し、又は隠すことができる。
以下、添付の図面を参照して本発明の実施の形態を説明する。以下では、本発明を実施形態に基づいて説明するが、本発明は、これに限定されるものではない。当業者は、本明細書の教示によって、更なる実施例、修正及び実施形態、並びに他の使用分野を想到でき、これらは、本明細書に記載された本発明の範囲内にあり、これらに関して、本発明は、重要な有用性を有する。
本発明をより明瞭にするために、添付の図面を参照して説明を行い、これらの図面において、同様の要素には、同様の符合を付している。これらの図面は、本発明を限定するものと解釈されるべきではなく、単なる例示であることが意図される。
通信レインテンシー平準化（ＴＬＬ）及びＴＬＬポータル
通信レインテンシー平準化（transmission latency leveling）技術（以下、「ＴＬＬ」）の実施形態は、「ポイントオブプレゼンス（point-of-presence：ＰＯＰ）」等の電子取引注文管理インフラを提供し、同インフラは、ネットワークアクセスポイントにおいて、通信媒体を介して、異なる取引エンティティからの電子取引注文を受信及びルーティングし、取引注文が電子市場センタに到着し、約定される前に、ある程度の通信レインテンシーを生じさせ、これにより、高頻度取引参加者が利用する可能性があるオーダブックアービトラージを抑制する。ＴＬＬ／ＰＯＰインフラは、レインテンシーアービトラージ等の不公正取引を抑制するために、発信される市場データの更新にある程度の通信レインテンシーを課してもよい。
通信レインテンシー平準化（transmission latency leveling）技術（以下、「ＴＬＬ」）の実施形態は、「ポイントオブプレゼンス（point-of-presence：ＰＯＰ）」等の電子取引注文管理インフラを提供し、同インフラは、ネットワークアクセスポイントにおいて、通信媒体を介して、異なる取引エンティティからの電子取引注文を受信及びルーティングし、取引注文が電子市場センタに到着し、約定される前に、ある程度の通信レインテンシーを生じさせ、これにより、高頻度取引参加者が利用する可能性があるオーダブックアービトラージを抑制する。ＴＬＬ／ＰＯＰインフラは、レインテンシーアービトラージ等の不公正取引を抑制するために、発信される市場データの更新にある程度の通信レインテンシーを課してもよい。
幾つかの実施例では、ＴＬＬにより、投資家は、アプリケーション（ウェブサイト、デスクトップ等）から様々な注文処理命令を選択でき、アプリケーションは、（例えば、電子取引のためのＦｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ ｅＸｃｈａｎｇｅ（ＦＩＸ）プロトコルにしたがって）選択された命令を、任意の媒体を介してブローカ（又はベンダ）に送ることができる。安全なログインの後に表示される（ログインを省略してもよい）指示ビデオは、注文処理の選択のコンテキストを提供する。選択のタイプ及び／又は注文処理指示は、広範囲に及ぶ場合があるが、少なくとも、注文ルーティングの優先傾向（preference）及びシーケンスを含み、所与の取引地に対する未約定注文フローの割当の割合の優先傾向を含む。
幾つかの実施例では、ＴＬＬは、シーケンサ、メモリ管理、回復性／冗長性（resiliency/redundancy）に関する取引システム内の技術的機能を提供する。幾つかの実施形態では、ＴＬＬは、ウェブフォームと共に、以下を補助するための一連の教育用ビデオを提供する。（Ａ）投資家に対して、包括的に市場における特定のプラクティスに関する通知を行う。（Ｂ）一連のオプションから投資家にオプションを選択させて、ブローカからの注文ルーティングとアルゴリズムの設定を調整することを要求するための指示セットを生成することを補助する。
一実施例では、Ｐｏｉｎｔ−ｏｆ−Ｐｒｅｓｅｎｃｅ（ＰＯＰ）アクセスポイントがインストールされ、マーケット参加者からの取引注文を受け取り、この注文をデータ取引所に渡して約定させるように構成される。ＰＯＰに対する又はＰＯＰからの送信により、通信レインテンシーが更に増える可能性がある。これは、市場参加者の場所（例えば、伝送距離等）、通信媒体（例えば、ケーブル、マイクロ波等）、回路抵抗、その他の情報技術インフラ及び／又は他の送信速度等による。例えば、ＰＯＰとデータ取引所又は市場参加者端末を接続するために必要なケーブル長は、通信レインテンシーを生じさせるために利用することができる。このような通信レインテンシーは、通信ケーブル長を調整することによって制御できる。
一実施例において、ＰＯＰは、非インテリジェントネットワークハードウェアを備える。同ハードウェアは、注文を受け取る入力ポートに接続する少なくとも１つの通信リンク、及び受信した注文をデータ取引所及び／又はこの他のエンティティへ送信する出力ポートに接続する通信リンクを含む。他の実施例において、ＰＯＰは、プロセッサが命令セットを実施するためのコンピュータ実行可能命令を格納したコンピュータ読取可能媒体を備える。
なお、本明細書で説明する実施例は、金融商品取引のための市場データセンタ及びデータ取引所を含んでいるが、ＴＬＬは、任意のオークションベースシステム又は電子市場に対して適用することができる。例えば、証券、通貨、この他の金融商品の取引所又はダークプール、代替取引システム、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋｓ（ＥＣＮｓ）、マッチングエンジン、アドエクスチェンジ（ディスプレイ、モバイル、ラジオ、検索、ビデオ等）、オンライン航空チケット／ホテル予約システム、オンラインオークションショッピングシステム、電子市場、ＭＭＯＲＧ内におけるバーチャルワールドゲーム内市場等に対して適用することができるが、これらに限らない。
更に、ＴＬＬは、レインテンシー及び／又はリソースアクセスを考慮する必要がある任意の電子メッセージングシステムに対して適用することができる。例えば、プレイヤがメッセージを送受信する速度によって、ゲームの状況を理解し反応することができる速度が決定されるオンラインビデオゲームにおいては、他のプレイヤよりも先に反応して、アクションを登録することができるプレイヤが有利になり、ゲームに勝つことができる。したがって、ＴＬＬは、オークションベースのシステムにおいて、情報及びリソースへの画一化された公平なアクセスを提供することができる。
ＴＬＬ／ＰＯＰインフラによって提供される市場センタ又は電子取引所は、通常、取引注文や約定指示を投資家から直接受け取ることはないが、ブローカ又は証券会社を介して注文／命令を受け取る必要がある。これらブローカは、投資家に対して、注文ルーティングや取引ストラテジの柔軟性を提供することに関心がないか、又はその能力を有していない場合がある。ＴＬＬ／ＰＯＰインフラの効率性及び公平性の利点を全て享受するためには、情報及び教育的なポータルを投資家に提供することが有用である。このポータルは、略奪的な取引行為からのリスクを説明するのみならず、投資家がルーティング及び取引優先傾向を調整することを補助する。幾つかの実施形態によれば、ＴＬＬポータルは、投資家の取引優先傾向を収集し、投資家が取引を実行するブローカに対して伝える指示を生成する。これに代えて、他の実施形態によれば、投資家は、ＴＬＬシステムに対して取引ルーティング及び約定設定を直接送信する。これを図４Ｂに示す。ＴＬＬシステムは、これを当該投資家の注文と取引に対して適用する。
図１Ａ〜図１Ｂは、ＴＬＬの実施形態における未約定注文再割当の例を表す。幾つかの実施例では、市場参加者（例えば、投資家）は、ブローカに対して注文を出し、ブローカは、参加者に対して取引アルゴリズム及び市場に関する幾つかの選択肢を提供する。これら取引アルゴリズムと市場についての市場参加者の選択又は優先傾向は、例えば、ＴＬＬポータル上で直接設定してもよく、生成された指示に基づきＴＬＬポータルからブローカに提供してもよい。
投資家の設定は、注文ルーティングと取引優先傾向及び／又はシーケンスを含むことができる。例えば、公開（lit）市場対ダークプール、注文ピング対注文未約定対分割未約定（バランス再割当）、所与の取引ベニューに対する未約定注文フローの割当割合、注文ルーティング前に未約定注文充足の市場チェックを行うか否か等を含む。
例えば、取引市場は、公開市場及び／又はダークプール等の取引所である。参加者が取引アルゴリズムを優先傾向にしたがってカスタマイズする場合もある。例えば、市場参加者は、取引市場における注文のピング及び／又は未約定のストラテジを選択する。幾つかの実施例では、市場をピングすることを参加者が選択すると、注文は、取引を発見するために、市場に対して暗黙的に送信される。但し、これら実施形態において、参加者の注文は、サイズ取引しようとしている及び／又は取引シグナルをおびき寄せるため複数株式（例えば、１００株）の略奪的ストラテジを用いている他の投資家に直面することがある。殆どの市場における平均取引サイズは、２００株未満なので（Ｆｉｎａｎｃｉａｌ Ｉｎｄｕｓｔｒｙ Ｒｅｇｕｌａｔｏｒｙ Ａｕｔｈｏｒｉｔｙ（ＦＩＮＲＡ）、ＡＴＳ Ｔｒａｎｓｐａｒｅｎｃｙ Ｄａｔａ、ＦＩＮＲＡ、２０１４年８月１８日による）、これら実施形態においては、他の投資家は、上述の略奪的（高頻度取引）ストラテジを採用する傾向を有する。幾つかの実施例では、参加者は、市場における注文を未約定とし、すなわち市場に注文を出しながら、取引の約定を待機することを選択することができる。幾つかの実施形態では、ＴＬＬは、略奪的ストラテジの影響が減少した高信頼市場を提供することができる。幾つかの実施形態において、投資家及び／又はブローカ等の他の市場参加者が高信頼市場において、注文を未約定とすると、通常の取引参加者（例えば、略奪的ストラテジを採用していない参加者）が互いを発見する可能性が増し、略奪的ストラテジに晒される可能性が減少する。
幾つかの実施形態では、注文は、複数の異なる市場間で分割未約定状態（split-rested）になる。例えば、投資家のブローカは、ブローカが未約定注文を出す優先市場を有し、注文は、ＴＬＬによって提供されるような信頼できる市場及びブローカの優先市場との間で分割してもよい。幾つかの実施例では、市場参加者は、未約定注文が約定されていない市場から約定されている市場へ注文を再割当することにより、最良市場から利益を得ることができる。例えば、バランス再割当法（balanced re-allocation method）を利用して、注文を２以上の取引市場へ分割未約定とすることができ、選択した市場の何れかで注文が完全に充足され約定されると、残りの市場取引可能な株は、即座に当該市場に対して送信され、取引が試みられる。幾つかの実施例では、実施例において、妥当な時間が経過した後、未約定注文は、選択した市場間でバランスして再配信される。他の例として、未約定注文を等分割し、選択した市場間で割り当ててもよく、ある市場における未約定注文を充足してもよい。これら実施形態において、残株は、市場間で均等に再割当される。
図１Ｂ（ｃ）及び図１０Ａのフローチャートに示すように、投資家が注文ルーティング／取引優先傾向を調整し、これをブローカに対して伝えることを補助することが望ましい。
ステップ１００２において、ＴＬＬポータルを訪問又はログインした投資家に対して教育コンテンツを提示する。教育コンテンツは、対話型ユーザインタフェースを介して提示することができる。教育コンテンツは、ＴＬＬプラットフォームの公平性と透明性の利点を説明すると共に、略奪的取引行為とＨＦＴプレイヤの危険性を説明する１以上のテキスト、オーディオ、及び／又はビデオ教材を含むことができる。例えば、ＴＬＬポータルは、ＴＬＬ／ＰＯＰ手法と利用可能なルーティング及び取引ストラテジを説明するユーザガイド、ホワイトペーパ、証明、図画、ビデオクリップを提示し、又はこれらに対するリンクを有することができる。
ステップ１００４において、ＴＬＬシステムは、ルーティング優先傾向及び／又は取引ストラテジについての一連の質問に対する投資家の回答を収集する。一連の質問は、相互的なＱ＆Ａセッションにおいて提示し、又は相互性の低い質問フォームのリストによって提示することができる。例えば、投資家は、ＴＬＬ対応市場センタにおいて、未約定状態とする受動非表示注文の割合を選択するよう促される。投資家は、更に、自身の元の注文指値と整合する指値を用いて、注文を未約定状態にするか否かを指定してもよい。投資家は、更に、２以上のプールにおける注文の分割未約定のバランス再割当手法を用いるか否かを決定することを促される。投資家は、選択した何れかのプールにおける注文が完全充足すると、残り全ての市場取引可能株を当該プールに即座に送信して、取引を試みるような設定を要求することができる。投資家は、更に、図１Ｃで詳細説明する市場チェック機能を用いることを選択できる。
次に、ステップ１００６において、投資家の回答（及び選択）を取引設定セットに統合する。この取引設定セットは、ＴＬＬシステムがステップ１０１０において、投資家及び／又は投資家の取引注文と関連付けて自身のデータベース内に記録することができる。ＴＬＬポータルユーザインタフェース上の質問と回答は、口語体であってもよいが、統合された取引設定は、通常、より正確で投資プロが用いるやや技術的な用語によって形成されている。例えば、設定は、ＦＩＸ（Ｆｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ ｅＸｃｈａｎｇｅ）プロトコル又はその他のデジタルデータ交換フォーマットにしたがって形成してもよい。
ステップ１００８において、当該投資家のための１以上の指示シート又は仕様文書が生成され、これにより当該投資家のブローカ又はブローカファームに対して取引設定を提供する。例えば、画面上のボタンをクリックすることにより、投資家は、指示シート又は仕様書を生成させることができる。指示シート又は仕様書は、例えば、Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ（ＰＤＦ）形式、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）形式、又はその他の形式であってもよい。図１０Ｂは、本発明の一実施形態に基づく取引設定の指示シート例を示す。本例において、指示は、ＩＥＸグループの取引システムによってコンパイルされ、投資家の取引注文を出すブローカに向けられる。図示するように、この指示シートは、「非表示未約定について」、「ＩＥＸチェック」ｆｉｌｌ−ｏｒ−ｋｉｌｌ（ＦＯＫ）注文タイプ、「ブローカルーティングストラテジを含む」といった投資家の優先傾向を含む。これら指示により、投資家は、（ブローカを介して）取引注文が約定される場所と方法を制御することができる。
上述のように、投資家とＴＬＬポータルとのやり取りにより、当該投資家固有の取引設定をデータベースに記録することができる。その後、記録した設定に基づき、ＴＬＬシステムは、ステップ１０１２において、投資家の取引がプリセット取引設定にしたがってルーティングされ、及び／又は約定されたか否かを確認することができる。
図１Ｃは、ＴＬＬの実施形態において、注文ルーティング前の未約定注文充足に対する市場チェックの例を示す。幾つかの実施形態では、高信頼市場において、未約定注文を出す投資家とブローカからのネットワーク効果により、当該市場において、利用可能な取引の受動的流動性を高めることができる。但し、幾つかの実施例では、市場参加者は、即座に充足すべき積極的注文を出すことを望む場合がある。また、注文を未約定状態にしないことを選択する場合がある。これにより、高信頼市場において、利用可能な受動的流動性を逃す可能性がある。幾つかの実施形態では、ＴＬＬは、市場のチェックを提供することができる。このチェックは、例えば、ａｌｌ−ｏｒ−ｎｏｎｅ注文タイプ又はｉｍｍｅｄｉａｔｅ−ｏｒ−ｃａｎｃｅｌ注文タイプである。この実施形態において、市場参加者の注文は、完全充足されるか全く充足されないかの何れかである。これにより、一部充足が略奪的取引ストラテジに対してシグナルを送信するリスクを排除することができる。幾つかの実施形態において、注文が高信頼市場で充足されない場合、ＴＬＬによりブローカは、待機又は遅延なく自身のルーティングプロセスを継続することができる。
幾つかの実施例では、市場参加者のルーティングストラテジは、ダークマーケットと公開市場のルーティングの組み合わせを含む場合がある。幾つかの実施例では、投資家及び／又はブローカは、通常ルーティングプロセスをＴＬＬによりチェックすることを含む場合があり、これにより自身がＴＬＬによって利用可能となった流動性に対してアクセスできるようにする。例えば、ブローカ及び／又は投資家は、積極注文を公開市場及び任意の外部流動性宛先に対してルーティングする前にＴＬＬによるチェックを利用することができる。この宛先は、利用可能であればブローカ自身のプールを含む。幾つかの実施例では、ブローカは、ブローカ自身の計らい（discretion）でＴＬＬを用いることができる。幾つかの実施形態において、投資家やブローカ等の他の市場参加者がＴＬＬを介して受動注文や積極注文をルーティングすると、自然取引参加者（例えば、略奪的ストラテジを採用していない参加者）の注文が合致する可能性が上がり、略奪的ストラテジに対して晒される可能性が減少する。幾つかの実施形態では、ＴＬＬスマート注文ルータ（Smart Order Router）を公開取引所（例えば、利用可能な１１箇所）のみに接続し、公開市場における流動性を積極的に利用するために使用する。他の実施形態は、非表示流動性ソースに対してアクセスすることを含む。
図１Ｄは、ＴＬＬの実施形態において、最小量注文取引を示す例である。幾つかの実施形態では、一部のトレーダは、反対側取引について選択できるようにするため、取引の最小量注文条件を用いることができる。例えば、取引シグナルを誘起するためある個数の株（例えば、１００株）を用いる略奪的ストラテジを回避しようとしている取引者は、そのストラテジを回避するため最小量注文指示を希望する場合がある。幾つかの実施例では、ＴＬＬは、略奪的取引からトレーダの注文を保護し、取引機会を最大化するように設計され、最小数量注文命令の処置を含む対策を組み込んだシステムを提供することができる。例えば、ＴＬＬは、限られたティアセットにおいて、利用可能な最小量を作成する。幾つかの実施形態において、これにより所与のティア内に収まる注文間の干渉可能性が高まる。幾つかの実施例では、注文が現在の最小数量ティアを下回ると、注文は、次の下位のティアに組み込まれる。
幾つかの実施例では、ＴＬＬは、複合プロセスを提供する。これは、到着注文よりも小さい未約定注文を複合して到着注文の最小量要件を充足させることにより、到着注文を充足させることができるものである。幾つかの実施形態では、小注文の組み合わせは、注文干渉を促し、小注文を用いて取引シグナルを探索する略奪的ストラテジから市場を保護することができる。
幾つかの実施形態において、ＴＬＬは、参加者プロセスで未約定注文を最小量指示とマッチングさせることにより、注文干渉を増やすことができる。例えば、１，０００株最小量買い注文が、その１，０００株に対して時間優先を有する２００株買い注文と同じプール内にある場合がある。この例において、１，０００株売り注文がプールに到着すると、到着した１，０００株売り注文は、初めに２００株買い注文と取引し、８００株が残る。幾つかの実施例では、ＴＬＬは、その８００株売り注文を未約定１，０００株買い注文と取引することができる。８００株売り注文は、１，０００株買い注文の最小量要件を充足するからである。この実施形態では、ＴＬＬは、取引者の希望を反対側取引に対して選択的にしつつ、取引機会を増やすことができる。
図１Ｅは、ＴＬＬの実施形態におけるレインテンシーアービトラージを抑制する例を示す。一実施例において、一部の金融商品取引市場の参加者は、情報技術インフラを利用してマーケットデータフィードを他の市場参加者よりも速く取得することができ、これにより他の市場参加者が市場変化に対して反応する前に取引ストラテジを形成して注文を約定させることができる。
例えば、一実施例において、市場参加者からの注文が約定される場所は、注文が受け付けられる場所でもあり、ここから相場レポート、約定済取引、その他の市場データが一般に配信される。同じ場所及び／又は市場センタ近傍において、取引エンティティの位置を確定する（例えば、同一場所に配置する）ことにより、市場参加者は、市場データ更新を、データ配信時間がより長くかかるその他の市場参加者よりも先に受け取ることができる。一実施例において、この市場データ送信アドバンテージは、様々な要因によって生じる。例えば、位置的アドバンテージ（例えば、送信距離がより短い）、送信媒体（例えば、ケーブル、マイクロ波等）、回路抵抗、その他の情報技術インフラのアドバンテージ、及び／又は送信速度アドバンテージ等であるが、これに限られない。
一実施例において、市場データは、相場、最終取引フィード、及び／又はその他の市場情報を含む。一実施例において、市場センタ１２０は、任意種類の取引所、市場データ配信者、代替取引システム、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋ（ＥＣＮ）、データプール等を含む。一実施例において、市場センタは、取引注文を約定させるデータ取引所を備える。別実施例において、市場センタは、マッチングエンジンとスマートルータを備える。スマートルータは、１以上のデータ取引所と注文をマッチングし、１以上のデータ取引所に注文をルーティングし、及び／又は再ルーティングする。このデータ取引所は、市場センタと提携しているものであってもよく、又は他の市場センタに位置しているものであってもよい。
高頻度取引（high frequency trading：ＨＦＴ）参加者等であるが、これに限定されない市場参加者は、高速データ通信のアドバンテージにより、「レインテンシーアービトラージ」として知られるストラテジを取ることができる。図１Ｅに示すように、一実施例において、例えば、取引システムを市場センタ１２０近くに配置する等により、ＨＦＴ参加者１０２ｃは、市場データ（例えば、「Ｃｏｃａ Ｃｏｌａ株」の価格更新１０３等）を、取引システムが市場センタ１２０からより離れている他の市場参加者１０２ａ〜ｂよりも早く受け取ることができる。ＨＦＴ参加者１０２ｃは、次に、他の参加者がＣｏｃａ Ｃｏｌａ株価の市場データ１０３を受け取るよりも前に、新たに受け取った市場データに基づき取引を約定させ、例えば、Ｃｏｃａ Ｃｏｌａ株を購入する（１０４）。この結果、市場センタ１２０と同じ位置にいない又は取引システムを市場センタ１２の近くに設けていない参加者１０２ａ〜ｂは、古くなったデータに対して取引を行うことを余儀なくされ、例えば、参加者１０２ａ〜ｂは、Ｃｏｃａ Ｃｏｌａ株価変化１０３に基づき注文を生成及び約定させることになり、一方でＨＦＴ参加者１０３ｃは、既にＣｏｃａ Ｃｏｌａ株の取引１０４を送信しているので、新たな価格変化が生じる可能性がある。一実施例において、ＨＦＴ参加者以外の市場参加者、例えば、ブローカ、個人投資家、その他の自身の取引端末でデータ送信アドバンテージを享受する取引エンティティは、意図するか否かを問わずレインテンシーアービトラージのアドバンテージを得ることができる場合がある。
一実施例において、ＴＬＬインフラは、「ｐｏｉｎｔ ｏｆ ｐｒｅｓｅｎｃｅ（ＰＯＰ）」構造１１０を提供し、レインテンシーアービトラージを緩和し、より多くの参加者が浩平な市場にアクセスできるようにする。例えば、図１Ｅに示すように、ＴＬＬは、市場の約定センタ１２０から、注文受付と市場データフィードの公開ソースを分離する。一実施例において、ＴＬＬは、注文を市場センタ１２０へ直接送信することを許可せず、取引注文をＰＯＰ１１０へ送信又は再ルーティングすることを要求する。一実施例において、相場価格（例えば、１０３）を受け取り又は取引が約定されると、そのデータは、市場センタ１２０からＰＯＰ１１０へ送信され、ＰＯＰ１１０は、これを公開配信する。同様に取引注文は、ＰＯＰ１１０において、再ルーティングされる（例えば、１０５）。
一実施例において、ＰＯＰ１１０は、ハードウェアアクセスポイントを備える。このハードウェアアクセスポイントは、プロセッサ、メモリユニット、１以上のデータＩ／Ｏポート等を備え（図６等を参照）、ケーブル、無線、マイクロ波等様々な通信媒体を介して市場センタ１２０及び／又は市場参加者、取引データ端末等に接続される。一実施例において、ＰＯＰアクセスポイントは、市場センタ１２０のマッチングエンジンから物理的に分離してもよく、分離しなくてもよい。マッチングエンジンは、注文を約定させ、及び／又はマッチングと他の市場センタへのルーティングを実施する。例えば、ＰＯＰアクセスポイントが市場センタの外に配置されている場合、ＰＯＰアクセスポイント１１０と市場センタ１２０との間の距離は、データ信号を通信する余分な通信時間を生じさせる。他の実施例において、ＰＯＰアクセスポイントは、市場センタ内に配置され、ＰＯＰアクセスポイント周りに追加ケーブルが取り付けられ、これによりＰＯＰアクセスポイントから市場センタへデータ信号が到着するための余分な通信時間を生じさせる。図２は、ＰＯＰアクセスポイント１１０のその他の物理的仕様（例えば、通信媒体タイプ（例えば、ケーブル、無線、マイクロ波等）、ケーブル長、抵抗等の電気回路パラメータ、通信時間測定）を示している。
別実施例において、ユーザインタフェース等を介して、ＰＯＰアクセスポイントのケーブル長、回路抵抗、及び／又はその他のハードウェアパラメータを調整することができる。これにより、ＰＯＰアクセスポイントが生じさせる通信レインテンシーを調整することができる。
一実施例において、ＴＬＬ／ＰＯＰ構造は、ＨＦＴ参加者１０２ｃが同一場所に存在することによるアドバンテージを減少させる。取引システムをＰＯＰに配置しているＨＦＴ参加者１０２ｃは、ＰＯＰ１１０から市場センタ１２０への往復レインテンシーによって遅延したデータフィードを受け取る。したがって、低レインテンシーフィードのアドバンテージに基づくＨＦＴストラテジ（例えば、１０４）を用いようとしても、他の参加者１０２ａ〜ｂが市場データを受け取る前の市場データに基づき約定されるとは限らない（例えば、１０８）。
別実施例において、図１Ｈに示すように、データ取引所１２２ｂは、取引注文を第２のベニュー（他の取引所、ＥＣＮ等）へルーティングする。この場合、市場センタ１２０からＰＯＰ１１０へのレインテンシー（例えば、市場センタ１２０がＰＯＰを介して最終取引フィードを含む市場データを公開するよう要求することにより生じる追加レインテンシー）と、ＰＯＰから第２のベニューへのレインテンシー（例えば、ＨＦＴ参加者がＰＯＰを介して注文を送信するよう要求することにより生じる追加レインテンシー）との合計が、市場センタ１２０から第２のベニューへのレインテンシーを超過していれば、市場センタからの注文は、ＨＦＴ参加者による干渉なしで安全に第２のベニューへルーティングされる。システムに追加のレインテンシーを導入することによって、レインテンシーアービトラージの不公平な利点が低減される。
図１Ｆは、ＴＬＬの実施形態において、オーダブックアービトラージを抑制する例を示す。一実施例において、図１Ｅで説明したように、ＨＦＴ参加者１０２ｃは、市場データフィードを他の参加者１０２ｂよりも速く受け取り、他の市場参加者１０２ｂが市場フィードに対して反応し又はこれを受け取ることができるよりも前にＨＦＴ参加者１０２ｃが取引を約定できるようにしようとする。このようなＨＦＴ取引ストラテジの例として、オーダブックアービトラージストラテジがある。オーダブックアービトラージは、市場情報を伝搬する際の遅延によるアドバンテージを利用して、市場センタが市場情報を処理する前に市場情報を処理して市場情報に反応し、これによって、市場センタがより新しい情報を有していれば約定させなかったはずの取引を約定させる。
例えば、多くの市場センタは、参加者が「ミッドポイントペッグ」で注文できるようにしている。その指値は、市場センタによって動的に調整され、常に全米最良気配（national best bid and offer：ＮＢＢＯ）価格の中間となる（例えば、１２１）。ミッドポイントペッグ注文は、現在のＮＢＢＯの中間価格でのみ約定するよう意図されている。例えば、注文が古いＮＢＢＯに基づき値付けされている場合、注文価格は、最新ＮＢＢＯの中間価格ではなく、注文は、取引されないか又は最新ミッドポイント価格よりも劣る価格で取引されることになる。
例えば、市場Ａにおいて、ＮＢＢＯは、＄０．１０×＄０．１２で計算され（すなわちＮＢＢは、＄０．１０、ＮＢＯは、＄０．１２）、ミッドポイントは、＄０．１１となる。市場が新たなＮＢＢＯ＄０．１１×＄０．１３へ移動した場合、新たなミッドポイントは、＄０．１２となり、取引注文データをこれにしたがって更新して有効なミッドポイントペッグストラテジとなるようにする必要がある。市場Ａが必要な更新時間よりも前にＨＦＴ参加者が新たなミッドポイント（＄０．１２）を取得すると、ＨＦＴ参加者は、市場Ａにおいて、株式を＄０．１１で購入し、即座に／同時にこれを他の市場において、＄０．１２で売却する可能性がある。これは、＄０．０１の「リスクなし」アービトラージである。このシナリオは、市場Ａにおいて、ＮＢＢＯが＄０．１０×＄０．１２で計算されると共に、市場Ａが＄０．０９におけるビッドを有する再値付けされる注文（例えば、Ｕ．Ｓ．Ｓｅｃｕｒｉｔｉｅｓ ａｎｄ Ｅｘｃｈａｎｇｅ Ｃｏｍｍｉｓｓｉｏｎ’ｓ Ｒｅｇｕｌａｔｉｏｎ ＮＭＳ（Ｒｅｇｕｌａｔｉｏｎ ＮＭＳ）等の法規に基づくもの）とは異なる。市場が動いて新たなＮＢＢＯが＄０．０９×＄０．１１となり、市場Ａにおける更新が間に合わない場合、市場Ａは、未約定の＄０．０９の買い注文と＄０．０９の売り注文のマッチングを許可しない（Ｒｅｇｕｌａｔｉｏｎ ＮＭＳが＄０．１０ビッドを禁止するため）。これに代えて、市場Ａのビッドに対してペッグされた注文があり、ＮＢＢＯが＄０．１０×＄０．１２で計算される場合、市場が動いてＮＢＢＯが＄０．０９×＄０．１１となり市場Ａが更新するのが間に合わなければ、ビッド＄０．１０にペッグされた注文を有していることになる。このようにＨＦＴ参加者は、＄０．１０で売り、即座に他の市場において、＄０．０９で買うことを試みる。
一実施例において、ペッグされている指値は、市場センタがアクセス可能な市場データを参照して定める。市場センタが連結市場データフィードを用いてＮＢＢＯを判定すると共に、例えば、市場センタと同じ位置にいるＨＦＴ参加者１０２ｃが専用市場データフィード（例えば、専用又はサードパーティのティッカプラント（ticker plants）、例えば、Ｅｘｅｇｙ、Ｒｅｄｌｉｎｅ、Ｗｏｍｂａｔ等）を用いる場合、ＨＦＴ参加者１０２ｃは、市場センタがＮＢＢＯ更新を処理し終える前に、ＮＢＢＯ更新を処理し、注文を送信し、ミッドポイントペッグ注文を約定させることができる（例えば、１１４参照）。
例えば、ＮＢＢＯが＄０．１０×＄０．１２から＄０．０８×＄０．１０に変化した場合、ＨＦＴ参加者１０２ｃは、ミッドポイント指値売り注文を即座に送信して＄０．１１（元のＮＢＢＯのミッドポイント）で約定させることを試みることにより、そのオーダブックストラテジ１３０を実行する。データフィードが遅い市場センタがＮＢＢＯ変化を未だ知らない場合、ＨＦＴ１０２ｃミッドポイント売り注文に対してミッドポイントペッグ買い注文を取引する可能性がある。このときの価格は、最新ＮＢＢＯよりも劣っている。したがって、ペッグ注文は、現在のＮＢＢＯの外で約定され、注文の意図から外れることになる。市場センタがＨＦＴ参加者と同じ更新されたＮＢＢＯを有していれば、ペッグ注文は、新たなＮＢＢＯのミッドポイント（＄０．０９）に再値付けされ、ＨＦＴ参加者は、ペッグ注文を約定させることができない。このアービトラージストラテジは、その他の注文タイプのアドバンテージを得るため同様に用いられる場合もある。例えば、更新後ＮＢＢＯよりも積極的に値付けされるが、従前はＮＢＢＯの範囲内であった「ｈｉｄｄｅｎ」注文である。
一実施例において、ＴＬＬは、図１Ｅと同様のインフラを採用し、オーダブックアービトラージを抑制することができる。例えば、取引注文は、市場センタに対して直接送信されない。これに代えて、取引注文は、ＰＯＰ１１０に対して送信され、ここから市場センタに対して送信される。一方、市場センタは、直接専用データフィードを用いて自身の市場データを更新する。このように全ての市場参加者１０２ｂは、ＮＢＢＯ更新１１７を受け取ることができ、自身の取引端末インタフェース１１９を介して最新のミッドポイントペッグデータに基づきビッド／オファー要求を約定させることができる。
例えば、ＨＦＴ参加者１２１が市場データ更新１３５を受け取り処理する時間をｔａとし、ＨＦＴ参加者１２１がアービトラージストラテジ注文を市場センタに対して送信する時間をｔｂとし、市場センタが市場データ更新を受け取り処理する時間をｔｃとすると、ＨＦＴ参加者１０２ｃは、不等式ｔａ＋ｔｂ＜ｔｃが成り立つ限りアービトラージを実施できる。ＨＦＴ参加者１０２ｃがｔｃに対してｔａ及びｔｂを減少させる手法は、様々ある。例えば、市場データは、全市場センタからのデータを含む連結市場データフィードを介して配信されるが、多くの市場センタは、自身の取引と値付けデータの専用データフィードも提供している。連結プロセスの性質により、連結市場データフィードは、一般に専用フィードと比較して遅延する。したがって、市場センタが連結市場データフィードを用い、ＨＦＴ参加者１０２ｃが専用フィードを用いる場合、ｔａは、遅延がなくｔｃよりも遥かに小さくなる。第３項ｔｂも「同一場所（co-location）」によって減少させることができる。例えば、ＨＦＴ参加者１０２ｃは、自身のサーバを市場センタに対して物理的に近い場所に配置し、送信時間の遅延を抑制することができる。
一実施例において、市場センタは、専用フィードとより高速な技術を用いることによってｔｃを減少させてアービトラージストラテジが起こり得る不等式を反転させることを試みるが、技術の進歩速度は、速く、結果として参加者と市場センタがレインテンシーを相手方の最新進歩よりも小さくすることを続ける、終わりのない「せめぎ合い」が起こるに過ぎない。したがって、これは、市場センタにとってコスト効率のよいビジネスストラテジではない。したがって多くは、ＨＦＴ参加者の技術と競争することを試みることはない。これに代えて、ＴＬＬは、ｔｃを抑制する高コストな技術競争ではなく、ｔｂを増やすことによりアービトラージ機会をなくすインフラを、例えば、ＰＯＰを介して提供する。
一実施例において、ｔｂは、ＰＯＰ１１０から市場センタへのレインテンシーにより増え、ｔａ＋ｔｂ＞ｔｃとなる。これにより、図１Ｆで説明したオーダブックアービトラージストラテジのようなアービトラージストラテジは、このインフラにおいては、有効性が格段に低くなる。ＨＦＴ参加者がデータ更新を処理して市場センタに対し注文を送信するのにかかる時間は、少なくとも専用データフィードからＰＯＰ１１０までのレインテンシーと、ＰＯＰ１１０から市場センタまでのレインテンシーとの合計となる。これら２つのレインテンシーの合計は、専用データフィードから市場センタへの直接ルートのレインテンシーよりも大きいので、市場センタは、同じデータに基づきＨＦＴ参加者から注文を受け取る前に、新たなデータを受け取り処理することができる。このようにして、市場センタは、ＨＦＴ参加者とシステム速度で競争することなしに、ＨＦＴ参加者がオーダブックアービトラージを実施する能力を大幅に減殺することができる。
図１Ｇは、ＴＬＬの実施形態において、アービトラージを抑制するＴＬＬ ＰＯＰメカニズムのインフラ例を示す比較図である。一実施例において、図１Ｇ（ａ）に示すように、ＴＬＬ／ＰＯＰインフラがない場合、ＨＦＴ参加者１２１は、市場データが生成され配信されるデータ取引所１２２ａ〜ｂに近いか又は同じ場所に位置しており、取引注文は、例えば、取引所Ａ１２２ａ及び取引所Ｂ１２２ｂで約定される。
例えば、ブローカ１２５が、クライアント１３０（例えば、ＨＦＴではない取引エンティティ）に代わって取引注文１３１をデータセンタ１ １２０ａにおける取引所１２２ａに対して送信し、第２注文１３２をデータセンタ２ １２０ｂにおける取引所１２２ｂに対して送信したとする。物理的位置のアドバンテージにより、ＨＦＴ１２１は、ブローカ１２５が送信した注文１３１に関する注文約定情報１３１を含む市場データ１３５を、取引所１２２ａから受け取ることができる。ＨＦＴ１２１は、内部的にこの情報と同期し、市場データに対して反応することができる。例えば、ＨＦＴ１２１は、注文１３１の約定に関して取得した情報に基づき、注文３を生成し、及び／又は取引所Ｂ１２２ｂにおけるペンディング注文をキャンセル（１３３）する。したがって、ブローカ１２５とデータセンタ２ １２０ｂとの間の距離に起因して、ＨＦＴ１２１は、注文１ １３１が約定された後、注文２ １３２が取引所Ｂ１２２ｂに到着する前に、更新後の市場情報に対して行動することができる。これにより注文２ １３２は、古くなった（例えば、注文１が約定される前の）市場データに基づく不利益な取引注文となる。
他の実施例において、図１Ｇ（ｂ）に示すＴＬＬ ＰＯＰインフラにより、ＴＬＬは、注文受領と市場データフィードの公開ソースを、市場の約定センタ１２２ａから分離することができる。一実施例において、全ての取引注文は、ＰＯＰアクセスポイント１１０に対して送信しなければならず、ＰＯＰは、取引注文を約定のための取引所ＴＬＬに送信し（１２２ａ）、例えば、ブローカ１２５は、注文１ １３１をＰＯＰ１１０に送信し、ＴＬＬにおいて、注文１３１を約定させる。一実施例において、ＴＬＬは、市場データ１３５（例えば、注文１の約定を反映した更新後データを含む）をＰＯＰ１１０経由で配信し、ＰＯＰ１１０は、その市場データ１３５をＨＦＴ１２１に対して引き渡す。
一実施例において、注文１ １３１の約定を反映した更新後市場データ１３５をＨＦＴ１２１がＰＯＰ１１０経由で取得すると、ＨＦＴ１２１が市場変化に対して即座に反応したとしても、ＨＦＴ１２１は、注文をデータセンタ２ １２０ｂにおける取引所１２２ｂに対してルーティングすることになる。このように、余剰送信時間、例えば、データセンタ１におけるＨＦＴ１２１からデータセンタ２におけるＨＦＴ１２１までの送信時間により、ＨＦＴ注文のレインテンシーが増加する。注文１の約定１３１を反映した市場データ１３５に基づきデータセンタ２ １２０ｂにおけるＨＦＴ１２１が注文３ １３３を送信及び／又はキャンセルすることができる時刻までに、ブローカ１２５の注文２ １３２は、データセンタ２ １２０ｂに到着し（例えば、注文２ １３２は、ＴＬＬにおいて約定することを意図してないので、データセンタ１２０ｂに対して直接送信される）、取引所Ｂ１２２ｂにおいて、約定されている。したがって、注文３は、注文２ １３２に対して、更新後市場データに関連するアドバンテージを何ら有さない。
例えば、ブローカ１２５からデータセンタ２ １２０ｂまで注文２ １３２を送信する時間は、８９ｍｓであるとする。一方、ＰＯＰアクセスポイント１１０によって生じる送信時間レインテンシー（例えば、追加ケーブル長、回路抵抗等）は、市場データ１３５をＴＬＬ１２２ａからＰＯＰ１１０、更にＨＦＴ１２１へ送信する時間３０ｍｓを含み、ＨＦＴ１２１からデータ取引所Ｂ １２２ｂへの送信時間が６０ｍｓであるとすると、合計レインテンシーは、９０ｍｓとなる。一実施例において、ＰＯＰ及び／又はＴＬＬは、注文が送信され及び／又は受信されたタイミングを推測し、測定し、及び／又はシグナリングする必要はない。これに代えて、ＰＯＰの物理構成が上述の追加レインテンシーを生じさせてもよい。したがって、注文３は、注文２が到着した後に取引所Ｂへ到着する。
図１Ｈは、ＴＬＬの実施形態において、注文予測におけるレインテンシーアービトラージを抑制する別実施例を示す。一実施例において、ＴＬＬ１２２ａは、最新市場に基づき注文を動的にルーティングする。ＴＬＬ１２２ａから取得した市場データ１３５は、最終取引フィードを含む。ＨＦＴ１２１は、これを利用して注文を予測する。例えば、図１Ｈ（ｂ）に示すように、ＨＦＴ１２１がＴＬＬ１２２ａから市場データ１３５を取得して最新約定注文を得たとき、ＴＬＬ１２２ａは、注文１３４を他のデータセンタ（例えば、データセンタ２ １２０ｂ）へルーティングするので、ＨＦＴ１２１は、データセンタ２ １２０ｂにおけるデータ取引所１２２ｂにルーティングされ約定される注文１３４を予測することができる。ＰＯＰアクセスポイント１１０がない場合、図１Ｈ（ａ）に示すように、ＨＦＴ１２１は、ルーティングされた注文１３４に対して有利な注文１３３を即座に生成し、その注文１３３をデータ取引所１２２ｂに対して送信する。これによりルーティングされた注文１３４は、不利となる。例えば、注文１３４に含まれているビッド／オファーは、成功せず、不利な価格で約定される。
他の実施例において、図１Ｈ（ｂ）に示すように、ＰＯＰアクセスポイント１１０がある場合、注文１の約定による更新を含む市場データ１３５は、ＰＯＰ１１０に対して送信され、ＰＯＰ１１０は、市場データ１３５をＨＦＴ１２１に対して送信する。ルーティングされた注文１３４に対して有利となるようにＨＦＴが生成した注文１３３は、データ取引所１２２ｂに対してルーティングする必要がある。ＰＯＰ１１０を介してＨＦＴ１２１に対して最新市場データ１３５を配信するレインテンシー及び／又は注文１ １３３の送信時間により、注文１３３がデータ取引所１２２ｂに到着する時刻までに、注文１３４は、データ取引所１２２ｂに到着して約定され、したがって、不利にならない。
なお、図１Ｅ〜図１Ｈで説明した例は、ＨＦＴ市場参加者と非ＨＦＴ市場参加者を示しているが、これらレインテンシーアービトラージ及び／又はオーダブックアービトラージは、ＨＦＴ参加者及び／又は非ＨＦＴ参加者の任意の組み合わせ間で生じ得る。ＰＯＰハードウェアアクセスポイントは、様々な市場参加者に対して適用することができる。レインテンシーアービトラージとオーダブックアービトラージを管理する例と様々なシナリオについては、図６Ａ〜図６Ｈで説明する。
図２は、ＴＬＬの実施形態におけるＴＬＬサーバ２２０とＰＯＰ２１０との間のデータフロー、ＴＬＬ市場データ配信及び取引注文約定の提携取引エンティティを示すデータフロー図である。幾つかの実施形態において、ＴＬＬサーバ２２０、その提携及び／又は独立ＰＯＰ２１０、市場センタ２４０、市場参加者２０２ａ〜ｎ、ＨＦＴ参加者２０２ｘ、ＴＬＬデータベース２１９等は、通信ネットワーク（例えば、インターネット、通信ネットワーク、決済処理ネットワーク、電話ネットワーク、携帯ネットワーク、無線ローカルエリアネットワーク、３Ｇ／４Ｇネットワーク等）を介して市場データ更新及び／又は取引注文要求を相互通信する。
一実施例において、様々な市場参加者２０２ａ〜ｎは、市場センタ２４０と通信し、例えば、ビッド要求及び／又はオファー要求２０１ａ〜ｂ等の取引注文を約定させる。一実施例において、市場参加者は、個人投資家、ブローカ、ポートフォリオマネージャ等を含むが、これに限らない。一実施例において、注文データ２０１ａ〜ｂは、市場参加者２０２ａ〜ｂから市場センタ２４０に対して直接送信されず、以下に説明するようにＰＯＰ２１０を介してルーティングされる。
一実施例において、市場センタ２４０は、１以上の集中及び／又は分散電子取引プラットフォーム及び／又は市場取引所を備える。例えば、ＮＡＳＤＡＱ、ＮＹＳＥ、ＢＡＴＳ、Ｄｉｒｅｃｔ Ｅｄｇｅ、Ｅｕｒｏｎｅｘｔ、ＡＳＸ等を含むが、これに限らない。一実施例において、市場センタ２４０は、ビッド／オファーデータフィード２０４を取得及び更新し、その市場データ更新２０６を参加者に対して提供する。一実施例において、市場データ更新２０６は、ＨＦＴ参加者２０２ｘに対して直接提供される専用フィードを含む。リアルタイム市場データフィードは、ＣＳＶファイルフォーマット、ＩＴＣＨプロトコルを介したもの、及び／又はその他の電子取引プロトコルによるものを含む。これは、様々な金融データベンダからのデータフィードを含む。例えば、Ｇｏｏｇｌｅ、Ｋｎｏｅｍａ、Ｎｅｔｆｏｎｄｓ、Ｏａｎｄａ、Ｑｕａｎｄｌ、Ｙａｈｏｏ、Ｘｉｇｎｉｔｅ等を含むが、これに限らない。一実施例において、ＨＦＴ参加者２０２ｘは、ＣＳＶファイルをパースして市場データ情報を取得する。ＱｕａｎｄｌからのＣＳＶファイルをテストする疑似コードセグメントは、例えば、以下のようなものである。
他の実施例において、市場センタ２４０は、ＸＭＬ形式でフォーマットされたＨＦＴ参加者２０２ｘのための市場データフィードを含む（Ｓｅｃｕｒｅ）Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ（Ｓ））ＰＯＳＴメッセージを生成する。ＸＭＬ形式データを含むＨＴＴＰ（Ｓ）ＰＯＳＴメッセージの形態の市場データフィード２０６のリスト例を、以下に示す。
一実施例において、ＨＦＴ参加者２０２ｘは、市場データフィード２０６を取得すると、自身の取引ストラテジに基づき取引注文２０７を生成する。例えば、最新のビッド／オファー価格に基づくビッド要求等である。そして注文を送信するためＰＯＰを検索／照会する。例えば、一実施例において、ＴＬＬは、参加者の地理的位置、意図する取引交換タイプ等に基づき、取引注文をＰＯＰに対してルーティングする。例えば、ＨＦＴ参加者２０２ｘは、データベーステーブル（例えば、図６のＰＯＰ９１９ｃ）に対してＰＨＰ／ＳＱＬコマンドを発行してＰＯＰをクエリする。ＨＦＴ参加者の位置と意図する取引交換に基づきＰＯＰ２１０をクエリするＰＯＰクエリ２０７の例を、ＰＨＰ／ＳＱＬコマンドの形態で以下に示す。
ＨＦＴ参加者２０２ｘは、ビッド／オファー要求２０９を送信し、その要求は、ＰＯＰ２１０に配信される。例えば、ビッド／オファー要求２０９を含む取引注文は、図４Ｂのような電子取引ユーザインタフェースを介して個人によって入力される。他の実施例において、取引注文は、ブラックボックス取引システム、注文エントリ（例えば、ＦＩＸプロトコル）、自動データ取引センタ等を介して入力される。ビッド／オファー要求メッセージ２０９のリスト例を、ＸＭＬ形式データの形態で以下に示す。
一実施例において、ＰＯＰ２１０は、例えば、地理的近さに基づき市場センタ２４０と同じ場所に収容される。他の実施例において、ＰＯＰ２１０は、集中ＴＬＬサーバ２２０に統合される。例えば、全ての取引注文は、市場センタ２４０に対してルーティングされ約定される前に、リモートのＰＯＰ／ＴＬＬサーバに対してルーティングされる。
一実施例において、ＰＯＰ２１０は、ＨＦＴ参加者２０２ｘ（及び／又はその他の参加者）からビッド／オファー要求２０９を受け取ると、その注文要求２１１をＴＬＬ２２０に対して引き渡す。ＴＬＬ２２０は、その注文要求を市場センタ２４０に対して約定のためルーティングする。一実施例において、他の市場参加者２０２ａ〜ｎは、例えば、物理的位置が市場センタ２４０から離れており、及び／又は比較的遅い連結市場フィードを受け取る。他の市場参加者２０２ａ〜ｎは、市場データ更新２１２ａ〜ｂを受け取る。一実施例において、市場参加者２０２ｎは、同様にビッド／オファー要求２１４を送信する。これら要求は、ＰＯＰ２１０に対してルーティングされる。
一実施例において、ＰＯＰ２１０は、ケーブル接続等の通信リンクを介して受信したビッド／オファー要求（例えば、２０９、２１４等）を受け取り、ビッド／オファーデータ２１５を含むその取引注文をＴＬＬ２２０に対して送信し、及び／又はその取引注文は、約定のためにＴＬＬから市場センタ２４０（例えば、他の取引所）に対してルーティングされる。一実施例において、取引注文２１５は、例えば、疑似同期してバッチ送信される。他の実施例において、ＰＯＰ２１０は、ビッド／オファーデータ２１５を市場センタ２４０に対して送信する「時間」を「ホールド」及び／又は予測する必要はない。ＰＯＰ２１０における通信媒体（例えば、ケーブル、マイクロ波等）を介した再ルーティングは、本質的にレインテンシーを生じさせ、ＨＦＴ参加者２０２ｘからの取引注文２０９は、他の参加者２０２ａ〜ｎからの取引注文２１４に対してアービトラージを実施できないからである。
一実施例において、ＴＬＬ２２０及び／又は市場センタ２４０は、受信した注文２１６を約定させ、ビッド／オファーがマッチングすれば取引を進める。一実施例において、ＴＬＬは、ＴＬＬサーバ２２０がＴＬＬデータベース２１９に格納する取引レコード２１８（例えば、ＴＬＬ２２０が約定させた取引、及び／又は他の市場センタ２４０において約定された取引に関する情報）を生成する。一実施例において、ＰＯＰ２１０は、取引注文がＰＯＰを介して引き渡されると取引レコード２１８にタイムスタンプを付与する。例えば、取引レコード２１８は、アービトラージを抑制することに成功したか否かをＴＬＬサーバ２２０が分析するための、ＨＦＴ注文及びその他の市場参加者２０２ａ〜ｎからの注文に関するタイミングパラメータを含む。レコード２１８は、周期的に生成してもよく、間欠的及び継続的に生成してもよく、及び／又はＴＬＬサーバ２２０からの要求により生成してもよい。
取引レコード２１８のリスト例を、ＸＭＬ形式のデータで以下に示す。
図３は、ＴＬＬの実施形態において、ＰＯＰルーティングによりレインテンシーアービトラージを抑制するロジックフローである。幾つかの実施形態において、様々な市場参加者は、注文要求を市場センタに対して送信する（例えば、３０１）。この注文要求は、市場センタに対して直接送信され、及び／又は図２で説明したようにＰＯＰに対して送信された後にＴＬＬへ引き渡される。一実施例において、市場センタは、注文要求３０２を受け取ると、現在のビッド／オファー価格リストを更新する（３０４）。別実施例において、市場センタは、ビッド／オファー価格リストデータをデータ取引所から取得する（例えば、ＮＢＢＯ）。
一実施例において、市場センタは、様々な市場参加者に対してデータフィードを提供する。この市場参加者は、ＨＦＴ参加者及び／又は非ＨＦＴ参加者を含む。一実施例において、図１Ｆで説明したように、ＨＦＴ参加者は、専用フィードを受け取るとき市場更新を速く受け取り（３０６）、受け取った専用フィードに基づき取引注文を生成する（３０７）。そして、ＨＦＴ参加者は、取引要求を送信する（３０９）。ＰＯＰアクセスポイントは、これを受け取り、ＨＦＴ参加者の物理的位置、取引要求に含まれる金融商品タイプ、所望する取引所等に基づき、レインテンシーを生じさせる（３１０）。一実施例において、ＰＯＰは、取引要求をＴＬＬに引き渡し、ＴＬＬは、注文を受け取ってルーティングし（３１１）、ＨＦＴ参加者からの注文要求を保持する必要はない。一実施例において、ＴＬＬは、取引注文を約定させ、及び／又は約定のために他のデータセンタへルーティングすべきか否かを判定する（３１２）。ルーティングしない場合は、注文を約定させる（３１９）。
別実施例において、他の市場参加者（例えば、非ＨＦＴ参加者）は、例えば、連結市場データフィードを介して市場更新を受け取る（３１３）。この市場更新は、相対的にレインテンシーを有している。一実施例において、市場参加者は、ビッド／オファー要求を含む取引注文を生成してこれをＴＬＬ ＰＯＰに対し送信する（３１４）。別実施例において、市場センタの物理的近くにない非ＨＦＴ市場参加者のため、ＴＬＬは、取引注文をＰＯＰに対して送信するよう要求してもよく、しなくてもよい。
一実施例において、ＴＬＬ／ＰＯＰが取引注文を手放すと（３１２）、市場センタは、これを受け取り約定させる（３１５）。例えば、市場センタは、注文をパースして金融商品ＩＤ、ビッド／オファー価格を取得し、ビッドが成功するか否かを判定する（３１６）。成功である場合、市場センタは、取引を進め、新取引に基づき現在のビッド／オファー価格リストを更新する（３１７）。
一実施例において、ＴＬＬ／ＰＯＰは、ＰＯＰレコードを生成する（３１８）（例えば、図２の２１８参照）。ＰＯＰレコードは、注文ルーティングとレインテンシーのタイミングパラメータを記録し、アービトラージ抑制性能を分析するために用いることができる。
図４Ａ〜図４Ｂは、ＴＬＬの実施形態におけるＴＬＬ ＰＯＰルーティングシステム設定及び／又は顧客設定を示すＵＩの例である。図４Ａは、ＰＯＰ割当の管理ＵＩである。例えば、一実施例において、ＴＬＬ管理者は、例えば、ｚｉｐコード及び／又はエリアコード４１２によって構成されているＰＯＰエンティティ４１１の分布を見ることができる。一実施例において、図４Ａに示すように、ＴＬＬダッシュボードは、当該領域における各ＰＯＰの位置、及びＰＯＰに関する詳細を提示する。例えば、サーバＩＰ、住所、取引所／市場までの距離（送信時間）等である。一実施例において、ＴＬＬ管理者は、ＨＦＴ参加者４１６を１以上のＰＯＰエンティティに対して割り当てる。この割り当ては、例えば、ＨＦＴ参加者の地理的位置、取引量、取引パターン、所望する取引所等に基づく。幾つかの実施例において、ＴＬＬとその他の市場参加者との間の距離は、ＰＯＰ位置を定める要因になり得る。他の実施例において、この距離は、考慮しないこともできる。ＰＯＰ「距離」は、ケーブル長等によって較正できるからである。ＰＯＰが他の市場センタから遠くレインテンシーが過大に増え参加者の取引体験が過剰に不利になる可能性がある場合、他の市場センタに対するＰＯＰの位置は、重要である。
例えば、ＴＬＬは、ＴＬＬ管理者毎に異なるＰＯＰエンティティをセットアップすることができる。例えば、ＴＬＬは、ＮＹＳＥに対して向けられる注文に関してＮｅｗ Ｊｅｒｓｅｙに配置されたＰＯＰをＨＦＴ参加者に対し割り当てることができる（４１７）。またＮＡＳＤＡＱに対して向けられる注文に関してＮｅｗ Ｙｏｒｋに配置されたＰＯＰを割り当てることができる（４１８）。一実施例において、ＴＬＬは、管理者にテスト配置させることができる。これは、例えば、割り当てたＰＯＰから所望するデータ取引所までの推定送信時間を提示することにより実施する。
図４Ｂに示す実施例において、ブローカの顧客は、ウェブベースダッシュボードアプリケーションにログインし、ポートフォリオをレビューする。例えば、顧客は、ビッド／オファーフィード４０１のリストを目視確認し、又は顧客投資プロファイル４０５を見て設定４０６〜４０７を変更する。
例えば、顧客は、ブローカが設けた注文の約定に関する設定をセットしようとする場合がある。ブローカは、一般に顧客の指示を順守する必要があるが、現在の市場において、ブローカは、顧客の注文をどのように約定させるかについてある程度の計らいを行う権利を有しており、ブローカの計らいにより、顧客の最終指示とは異なる注文を市場で約定させる場合がある。
一実施例において、ＴＬＬは、ＵＩを提供し、ブローカの顧客が市場に対して直接的に計らい設定できるようにする（４０７）。これら設定は、以下の要因の１以上に基づき顧客がいつ取引を所望するかを示す：シンボル、市場資本、過去のスプレッドと比較した現在のスプレッド、提示されている流動性、関連商品価格、ストラテジタイプ、平均日中取引量、平均日中取引量と比較した注文サイズ、最小フィルサイズ、想定元本、価格、最少取引サイズ、オープン価格、及び／又は注文タイプ等。
一実施例において、顧客は、ブローカに対して、顧客ＩＤと共に注文を市場へルーティングするよう指示する。市場は、その指示を認識し、顧客が先に設定した計らい設定と注文をマッチングし、注文を約定させる際に顧客の計らい設定を順守する。これによりブローカが顧客の注文指示から逸脱する権限を除去できる。すなわち、専門用語が不明確でありその結果注文が顧客のブローカに対する指示又は顧客の利益に反することを回避できる。
例えば、顧客は、設定４１６〜４１８において、「Ｓｙｎｔｈｅｔｉｃ ａｌｌ ｏｒ ｎｏｎｅ」注文タイプを設定する。一実施例において、電子取引注文は、「ａｌｌ−ｏｒ−ｎｏｎｅ」（ＡＯＮ）で実行してもよく、これは、注文全体の要求を満たすだけの十分な流動性がある場合のみ約定させてもよい。注文の一部のみを満たす流動性しかない場合、ＡＯＮ注文は、その全体が約定されない。ＡＯＮではない注文は、その流動性の下でも約定され、一部が充足されない場合がある。一実施例において、この注文タイプの制約は、単一市場における流動性に対してのみ約定されることである。例えば、ＡＯＮ注文は、２以上の市場からの流動性を満たすように約定されることはない。
一実施例において、ＴＬＬは、「Ｓｙｎｔｈｅｔｉｃ ＡＯＮ」注文タイプを実行する。例えば、この注文タイプの場合、市場参加者は、最小約定量と注文約定価格を指定することができる。ＴＬＬは、当該ＴＬＬ自身に対して提示されている流動性と提示されていない流動性、及び当該ＴＬＬが注文をルーティングするその他の全ての取引ベニューに対して提示されている流動性に対して、この最小量を約定可能か否か判定する。市場参加者が指定した価格よりも不利ではない価格で注文を約定できるだけの連結流動性がある場合、ＴＬＬは、注文を部分的に約定させ、一部を他の取引ベニューへルーティングする。これにより、注文の約定された部分とルーティングされた部分が、指定された最小量を満たすようにする。ルーティングされた注文のうち１以上は、部分的に充足され、又は全く充足されない場合がある。したがって、従来のＡＯＮ注文タイプとは異なり、Ｓｙｎｔｈｅｔｉｃ ＡＯＮ注文は、「ベストエフォート」で実行される。ＴＬＬが最初に約定させた取引がルーティングされた注文の約定に対して与える影響を最小化し、ＴＬＬ約定をシグナルとして用いてＴＬＬがルーティングした注文を他の市場センタに急がせることにより他の参加者がＳｙｎｔｈｅｔｉｃ ＡＯＮ注文タイプのアドバンテージを得る可能性を最小化するため、ＴＬＬは、注文をルーティングするとき、ルーティングされた注文が十分遠くまで伝搬してその宛先に急がされる可能性が排除されるまで、ＴＬＬ注文約定に関する情報を市場参加者が受信できないようにする。このプロセスは、上述のＰＯＰ設備を用いることを含む。一実施例において、完全に充足される保証はないものの、ＰＯＰ構造は、Ｓｙｎｔｈｅｔｉｃ ＡＯＮ注文の有効性を高める。
別実施例において、ＴＬＬは、様々な要因に基づき注文をマッチング及び／又は優先付けする。この要因は、例えば、価格、ディスプレイ、ブローカ、時間優先等である。オーダブックにおける最良価格注文は、その他の全ての注文に優先される場合がある。同一価格であれば、表示注文は、非表示注文よりも優先される。価格と表示状態が同じである場合、当該ブローカの注文がオーダブックに対してテスト中であれば、ブローカの未約定注文は、他のブローカの注文よりも優先される。ブローカ自身の注文のなかで、Ａｇｅｎｃｙマークされた注文は、Ｐｒｉｎｃｉｐａｌマークされた注文よりも優先される。同一優先度レベルにおける全ての競合注文のなかで、最も古い注文が優先される。所与の価格で表示される注文のなかで、まずＡｇｅｎｃｙマークされた注文が時間優先され、注文が処理されると、次に同一サブスクライバに属するＰｒｉｎｃｉｐａｌマークされた注文が時間優先され、次にその価格における他の表示注文が時間優先される。最古注文は、高い優先度を有する。所与の価格における非表示注文のなかで、まずＡｇｅｎｃｙマークされた注文が時間優先され、次に同一サブスクライバに属するＰｒｉｎｃｉｐａｌマークされた注文が時間優先され、次にその価格における他の非表示注文が時間優先される。最古注文は、高い優先度を有する。一実施例において、最小量（Minimum Quantity）等の特定の注文条件パラメータが、非表示注文やＩｍｍｅｄｉａｔｅ Ｏｒ Ｃａｎｃｅｌ（ＩＯＣ）注文に対して選択される。ＴＬＬのオーダブックにおいて、優先度を有する未約定注文がその条件に起因して約定されない場合、その未約定注文は、オーダブックにおけるそのプロセスサイクル時間に関する優先度を放棄する。
一実施例において、ＴＬＬがオーダブック上の未約定注文に対して再値付け、表示更新、ブック再チェック、又はルーティング動作（まとめて「ブック動作」）を実施する毎に、価格／時間優先度において、これを実施する。このときのタイムスタンプは、時間優先度を決定するためのアクションを実施したときにおける注文の一部のタイムスタンプであり、このときの未約定価格は、価格優先度を決定するための当該注文又はその一部のオーダブック上における未約定価格である。
一実施例において、ＴＬＬが表示注文又は予約注文の表示部分を再値付けする毎に、オーダブックの価格／時間優先度における時間を判定するため、ＴＬＬは、注文（又は注文の一部）に対して新たなタイムスタンプを割り当てる。
図５Ａ〜図５Ｃは、ＴＬＬの実施形態におけるＴＬＬネットワークインフラを示すデータ図である。一実施例において、ＴＬＬサブスクライバ５１０（例えば、個人投資家、取引エンティティ、及び／又は市場参加者）は、ＰＯＰアクセスポイントに接続されている。ＰＯＰアクセスポイントは、例えば、ＦＩＸプロトコルを実施してＦＩＸエンジン５０７と通信するアクセスポイントである。一実施例において、ＰＯＰ ＦＩＸ／ＣＵＳＴアクセスポイントは、取引エンジン５１５と同じデータセンタ及び／又は別のデータセンタに配置されたハードウェア構造を備える。一実施例において、ＦＩＸエンジン５０７は、ＦＩＸプロトコルを介してデータを送受信するロジック部品を備える。図５Ｃは、データメッセージパケット構造５１９ｄの例を示す。
例えば、ＴＬＬサブスクライバ５１０は、ＦＩＸ ＡＰＩを通じて（例えば、データ取引所そのものとして動作する）ＴＬＬ上で取引される商品を購入又は売却する注文を電子送信する。一実施例において、サブスクライバは、ＴＬＬが提供するＦＩＸ ＡＰＩに準拠する通信を介して、あるインターネットプロトコル（Internet Protocol：ＩＰ）アドレスにおいて、ＴＬＬに対するダイレクトアクセスを利用することができる。
一実施例において、シーケンサ５０６は、データをパースし、取引エンジン５１５に対してデータを送信する。データメッセージパケット構造５１９ｃの例を図５Ｃに示す。一実施例において、取引データ（例えば、ビッド／オファー要求）は、取引ゲートウェイ５０５に対して送信され、取引所５０２において約定される。取引所５０２は、例えば、ＮＹＳＥ５０２ａ、ＢＴＬＬ５０２ｂ、ＥＤＧＥ、ＣＨＳＸ、ＮＳＸ５０２ｃ、ＮＡＳＤＡＱ５０２ｄ等である。一実施例において、ＴＬＬは、取引データをデータベース５１９のストレージに対して送信する。一実施例において、ＴＬＬは、内部ウェブ５１１を介してデータフィードを配信するＣＮＣを介して取引データを配信し、及び／又はＤＭＺを介して外部ウェブ５１２において、データフィードを配信する。図５Ｂは、データメッセージパケット構造５１９ａ〜ｂの例を示す。
別実施例において、ＴＬＬは、注文を他の市場センタ（例えば、図１Ｈの１３４）へルーティングする際の様々なルーティングオプションを提供する。ルーティングオプションは、様々な注文タイプ及びＴＩＦと組み合わせることができる。但し、ルーティングオプションの条件と整合しない注文タイプ及びＴｉｍｅ ｉｎ Ｆｏｒｃｅ（ＴＩＦ）を除く。幾つかの実施例において、ＴＬＬは、１以上のシステムルーティングテーブルを保持する。このテーブルは、システムが注文をルーティングする宛先となる取引ベニューを決定するためのものである。この注文は、遠隔取引ベニューに留まることを意図してルーティングされるものを含む。システムルーティングテーブルは、システムが注文をルーティングする手順も記述している。ＴＬＬは、複数のルーティングオプションについて複数のシステムルーティングテーブルを保持することができ、事前の通知なしでシステムルーティングテーブルを変更することができる。
例えば、ＴＬＬは、Ｒｏｕｔｅ ｔｏ Ｔａｋｅプロトコルを実装することができる。例えば、そのルーティングオプションにおいて、利用可能な取引をオーダブック上でシステムがチェックし、未約定取引をｉｍｍｅｄｉａｔｅ−ｏｒ−ｃａｎｃｅｌ注文としてシステムルーティングテーブル上の宛先へルーティングする。ルーティング後も取引が未約定のままである場合、これらは、オーダブック上に留め置かれる。オーダブック上において、注文が他のアクセス可能な市場センタによりロックされ又は干渉された場合、システムは、その注文がサブスクライバ（例えば、クライアント、投資家等）によって再ルーティング可能である旨をマークされていれば、その注文又はその一部をロック又は干渉した市場センタへルーティングする。
他の実施例として、ＴＬＬは、Ｒｏｕｔｅ ｔｏ Ｒｅｓｔプロトコルを実装することができる。このプロトコルにおいて、ＴＬＬシステムは、利用可能な取引をオーダブック上でチェックし、未約定取引をｉｍｍｅｄｉａｔｅ−ｏｒ−ｃａｎｃｅｌ注文としてシステムルーティングテーブル上の宛先へルーティングする。ルーティング後も取引が未約定のままである場合、システムは、ＴＬＬルーティングテーブルの定義にしたがって、その注文の表示サイズをオーダブックと他の取引ベニューとの間で分割する。Ｐｒｅ−Ｍａｒｋｅｔ Ｓｅｓｓｉｏｎ又はＰｏｓｔ−Ｍａｒｋｅｔ Ｔｒａｄｉｎｇ Ｓｅｓｓｉｏｎの間にＴＬＬ上で約定される任意の取引について、適用可能注文価格は、最高自動値付けビッド又は最低自動値付けオファー（ＮＢＢＯ）と同額又はより有利でなければならない。但し、注文がＩＳＯマークされ、又は自動値付けビッドが自動値付けオファーとクロスしている場合は除く（或いは、取引約定が他の条件に合致する場合、例えば、Ｒｅｇｕｌａｔｉｏｎ ＮＭＳ 規則６１１（ｂ）の例外に相当するような場合）。
一実施例において、サブスクライバ注文指示が反対指示しない限り、到着する注文は、まず、オーダブックにおいて、約定マッチングされる。約定されない取引は、キャンセルされ、オーダブックに留め置かれる。或いは、買い注文と売り注文がオーダブック上でマッチングし、又は遠隔ベニューにルーティングされた注文がそのベニューにおいてマッチングする場合は、ルーティング約定される。システムは、到着する注文を受け取った順に処理する。この注文は、ルーティング先の遠隔ベニューから戻ってきた未約定注文又はその一部を含む。注文又はその一部が遠隔ベニューにルーティングされている間、その注文又はその一部は、システムの到着注文処理キューの一部ではなくなり、後続の注文が優先処理される。
オーダブックに対して送信された注文を約定させる際、システムは、サブスクライバが自身のアカウントから送信した注文と、サブスクライバがその顧客のために送信した注文との間の区別ができない場合がある。但し、ブローカ優先機能を除く。ブローカ優先において、未約定のＡｇｅｎｃｙ注文は、未約定のＰｒｉｎｃｉｐａｌ注文よりも優先される。
一実施例において、サブスクライバは、リモートからシステムに対して注文を送信し、オーダブック上にある注文に対して同等のアクセスを有する。同様に、ＴＬＬ上の注文は、自動約定されるので、サブスクライバは、約定のタイミングを制御することができず、約定前に注文を変更又はキャンセルできるに過ぎない。オーダブックに対して送信された買い注文は、オーダブックに対して送信された同一商品の売り注文と同額又は超える価格に値付けされ、注文を送信したサブスクライバが選択した条件が満たされるまで、システムにより自動的に約定される。この買い注文は、オーダブック上において優先権を有する最低価格の売り注文の価格で約定される。
一実施例において、オーダブックに対して送信された売り注文は、オーダブックに対して送信された同一商品の買い注文と同量又はそれ以下の量で値付けされ、注文を送信したサブスクライバが選択した条件が満たされるまで、システムにより自動約定される。この売り注文は、オーダブック上において、優先権を有する最高価格の買い注文と約定される。未約定注文のフルサイズ以下が約定される場合、表示注文か非表示注文かによらず、注文の未約定サイズ部分は、サブスクライバの指示に整合した状態でオーダブック上に残り、表示する場合は、その価格で再表示される。この部分的に約定された注文は、同じ価格で優先権を保持する。オーダブック又はＮＢＢＯが変更されたとき、又は到着メッセージの処理の一部として、システムは、注文を市場の片側又は両側において、オーダブックの反対側に対してテストし、ＴＬＬの変化の結果として新たに注文をｉｎｓｉｄｅ ｍａｒｋｅｔ又はＮＢＢＯで約定できるか否かを判定する。最小量条件を有する非表示未約定注文、及び／又は現在オーダブック上にある価格よりも積極的な指値は、最初にオーダブックに記載されたときには約定不能又は注文条件を満たしていなかった更新後のオーダブックにおける注文に対して取引可能となる。未約定注文は、それぞれの予約された価格／時間優先度に基づいて再チェックされる。オーダブックを再チェックする注文は、保護された値付け（Protected Quotations）又はオーダブックの反対側の未約定注文を通じて取引されることはない。
ＴＬＬがＮＢＢＯと同額又はより有利な価格の適格な株を有していない場合、又はこの適格な株が品切れであり、未約定の株のみが残っている場合、システムは、到着した注文をルーティング適格性に基づいて処理する。ルーティングに適格とマークされ、ＮＢＢＯに対して取引可能な注文について、システムは、これをより有利な価格の保護値付けを表示する遠隔取引センタへルーティングする。このとき、サブスクライバ注文指示、注文タイプ、ルーティングストラテジ定義、「ＴＬＬルーティングテーブル」に準拠する。
図６Ａ〜図６Ｈは、ＥＢＯＭの実施形態において、余剰データ送信レインテンシーを生じさせるネットワークアクセスポイントを通じてレインテンシーアービトラージとオーダブックアービトラージを管理する様々なシナリオを示す。一実施例において、市場参加者は、代替可能証券を取引する取引所（及び／又は他の市場センタ）間のデータ送信レインテンシー差のアドバンテージを得る。一実施例において、ブローカが投資家に代わってＢｒｏｋｅｒ Ｓｍａｒｔ Ｏｒｄｅｒ Ｒｏｕｔｅｒ（ＢＳＯＲ）を介して市場間で注文をルーティングする場合、又は取引所がブローカと投資家に代わってＥｘｃｈａｎｇｅ Ｓｍａｒｔ Ｏｒｄｅｒ Ｒｏｕｔｅｒ（ＥＳＯＲ）を介して市場間で注文をルーティングする場合、レインテンシーアービトラージが適用される。但し、これに限らない。
図６Ａは、ＢＳＯＲを介して生じるレインテンシーアービトラージの例を示す。例えば、取引所１ ６０５ａは、＄１０．００におけるＸＹＺ株の売り注文１，０００株を有し、取引所２ ６０５ｂは、＄１０．００におけるＸＹＺ株の売り注文２，０００株を有する（取引所２ ６０５ｂのオファーは、ＨＦＴ６０６によって先に入力されたものである。全米最良売り気配（national best offer）は、＄１０．００におけるＸＹＺ３，０００株の連結オファーとなる）。
一実施例において、投資家６１４は、ＸＹＺ３，０００株を＄１０．００で購入しようとし、ブローカ６１５に対してＸＹＺ３，０００株を＄１０．００で購入する注文を送信する。投資家の注文を受け取ると、ブローカ６１５は、買い注文Ａ６１３ａを取引所１ ６０５ａに対してルーティングしてＸＹＺ１，０００株を＄１０．００で購入すると共に、買い注文Ｄ６１３ｄを取引所２ ６０５ｂに対してルーティングしてＸＹＺ２，０００株を＄１０．００で購入する。注文Ａ６１３ａと注文Ｄ６１３ｄは、ブローカ６１４から取引所１ ６０５ａまでの物理的距離とブローカ６１４から取引所２ ６０５ｂまでの物理的距離に起因して、異なるレインテンシーを有する（よって、ケーブル、マイクロ波等の物理通信媒体に沿って異なる通信時間を有する）。接続性、ネットワーク機器、情報技術インフラ、ネットワーク回路抵抗、その他の様々な要因によっても、送信時間の異なるレインテンシーが生じ得る。
一実施例において、ブローカ注文Ａ６１３ａは、取引所１ ６０５ａと投資家６１４（例えば、ブローカ６１４を通じて）に到着し、取引所Ａにおいて、１，０００株を＄１０．００で購入したことを示す。一実施例において、ＨＦＴは、取引レポートＢ６１３ｂを取引所１ ６０５ａから受け取る。一実施例において、ＨＦＴが同一場所に配置されることにより、取引レポート６１３ｂを「数十マイクロ秒」で受け取ることができる。一実施例において、ＨＦＴは、取引所２ ６０５ｂに対して注文訂正Ｃ６１３ｃ（先に入力した＄１０．００におけるＸＹＺ２，０００株に対する訂正）を送信する。ＨＦＴは、取引所１ ６０５ａにおいて、ＸＹＺ株が＄１０．００で取引された知識から利益を得ることを試みる。例えば、他の買い注文（Ｄ）が取引所２ ６０５ｂへルーティングされることを予測し、注文Ｃ６１３ｃを＄１０．０１まで調整する。この例において、買い指値＄１０．００の注文Ｄ６１３ｄは約定されず、ブローカは、＄１０．０１で別注文を送信しなければならない。最終的に、取引所２ ６０５ｂにおいて、新たな買い注文が約定されると、投資家６１４は、ＸＹＺの残り２，０００株を購入するために＄２０．００を更に支払うことになる（＄０．０１＊２，０００＝＄２０．００）。注文Ｃ６１３ｃのレインテンシーは、接続性と情報伝送方法（例えば、マイクロ波ｖｓファイバ）によって定まる。このように、レインテンシー（Ａの送信時間＋Ｂの送信時間＋Ｃの送信時間）＜Ｄの送信時間であれば、ブローカ６１５（投資家６１４の代理）は、取引所２ ６０５ｂにおいて、＄１０．００でＸＹＺ２，０００株の買い注文を約定させることができない。その結果、注文は、その時点において、充足されず、或いは、投資家６１４は、残り２，０００株を購入するためにより高い価格を支払わなければならない。
図６Ｂは、ＥＢＯＭの実施形態において、ＰＯＰアクセスポイントを設置することによりレインテンシーアービトラージを管理する例を示す。一実施例において、取引所１ ６０５Ａは、＄１０．００におけるＸＹＺ１，０００株の売り注文を有し、取引所２ ６０５ｂは、＄１０．００におけるＸＹＺ２，０００株の売り注文を有している（取引所２ ６０５ｂにおけるものは、ＨＦＴ６０６によって先に入力されたものである。全米最良売り気配は、＄１０．００におけるＸＹＺ３，０００株の連結オファーとなる）。投資家６１４は、ＸＹＺ３，０００株を＄１０．００で購入しようとし、ブローカ６１５に対してＸＹＺ３，０００株を＄１０．００で購入する注文を送信する。ブローカ６１５は、投資家６１４の注文を受け取り、買い注文Ａを取引所１ ６０５Ａに対してルーティングしてＸＹＺ１，０００株を＄１０．００で購入すると共に、買い注文Ｄを取引所２ ６０５ｂに対してルーティングしてＸＹＺ２，０００株を＄１０．００で購入する。注文Ａと注文Ｄは、ブローカ６１４から取引所１ ６０５ａまでとブローカ６１４から取引所２ ６０５ｂまでの物理的距離、接続性、ネットワーク機器、その他の様々な要因に起因して、異なるレインテンシーを有する。接続性、ネットワーク機器、情報技術インフラ、ネットワーク回路抵抗、その他の様々な要因により、送信時間の異なるレインテンシーが生じ得る。
ブローカ６１５の注文Ａ６１３ａは、取引所１ ６０５Ａに到着し、投資家６１４は、（ブローカ６１５を通じて）取引所１ ６０５Ａにおいて、＄１０．００で１，０００株を購入する。ＨＦＴ６０６は、ＰＯＰ６１０から取引レポートＢ６１３ｂを受け取る。ＥＢＯＭ ＰＯＰアーキテクチャ ＰＯＰ６１０により、ＥＢＯＭサブスクライバ（ＨＦＴ６０６を含む）は、取引情報（Ａｉｉの送信時間＋Ｂの送信時間）を「数百マイクロ秒」で受け取る。
一実施例において、ＨＦＴ６０６は、先に入力した＄１０．００におけるＸＹＺ２，０００株の売り注文の注文訂正Ｃ６１３ｃを、取引所２ ６０５ｂに対して送信する。ＨＦＴは、取引所１ ６０５ａにおいて、ＸＹＺ株が取引された知識から利益を得ることを試みる。例えば、他の買い注文（Ｄ）が取引所２ ６０５ｂへルーティングされることを予測し、注文Ｃを＄１０．０１まで調整する。この例において、買い指値＄１０．００の注文Ｄは、約定されず、ブローカ６１５は、別の買い注文＄１０．０１を送信しなければならない。最終的に、新たな買い注文が取引所２ ６０５ｂにおいて約定されると、投資家は、ＸＹＺ２，０００株を購入するために＄２０．００を余分に支払うことになる（＄０．０１＊２，０００＝＄２０．００）。注文Ｃのレインテンシーは、接続性や情報送信方法（例えば、マイクロ波ｖｓファイバ）によって定まる。
但し、ＥＢＯＭ ＰＯＰアーキテクチャＰＯＰ ６１０により、ＢＳＯＲは、レインテンシーアービトラージからクライアントの注文を保護する機会を得ることができる。これは、ＨＦＴ６０６が取引レポートＢを受け取ってシグナルとして用いる前に時間量に対してレインテンシー（距離又は媒体により）を追加することによってなされる。（Ａの送信時間＋Ａｉの送信時間＋Ａｉｉの送信時間＋Ｂの送信時間＋Ｃの送信時間）＞Ｄの送信時間となるからである。この場合ブローカ６１５（投資家６１４の代理）は、ＨＦＴ６０６の注文訂正Ｃ６１３ｃが取引所２ ６０５ｂに到着する前に、取引所２ ６０５ｂにおいて、＄１０．００でＸＹＺ２，０００株の買い注文Ｄ６１３ｄを約定させるだけの十分な時間を有する。その結果、注文Ａ６１３ａは、指値で完全に充足され、投資家６１４は、図６Ａに示すように新たな買い注文を通じて残り２，０００株を購入するためにより高い価格を支払う必要はない。
図６Ｃは、ＥＢＯＭの実施形態において、ＥＳＯＲによって生じるレインテンシーアービトラージを示す図である。一実施例において、取引所１ ６０５ａは、＄１０．００のＸＹＺ１，０００株の売り注文を有し、取引所２ ６０５ｂは、＄１０．００のＸＹＺ２，０００株の売り注文を有している（取引所２ ６０５ｂにおける注文は、ＨＦＴ６０６によって先に入力されたものである。全米最良売り気配は、＄１０．００のＸＹＺ３，０００株の連結売り価格である）。投資家６１４は、ＸＹＺ３，０００株を＄１０．００で購入しようとし、ブローカ６１５に対して＄１０．００でＸＹＺ３，０００株の買い注文を送信する。ブローカ６１５は、取引所１ ６０５ａのＳｍａｒｔ Ｏｒｄｅｒ Ｒｏｕｔｅｒ（ＥＳＯＲ）を使おうとし、注文を受け取った後、＄１０．００でＸＹＺ３，０００株を購入する注文Ａ６１３ａ全体を取引所１ ６０５ａに対してルーティングする。取引所１ ６０５ａは、このとき、ブローカ６１５に代わって（投資家６１４のために）２，０００株の買い注文Ｄ６１３ｄを取引所２ ６０５ｂに対してルーティングする役割を担う。
一実施例において、ブローカ６１５の注文Ａ６１３ａは、取引所１ ６０５ａに到着し、投資家６１４は、（ブローカ６１５を通じて）取引所１ ６０５ａにおいて、＄１０．００で１，０００株を購入する。注文を約定させた後、取引所１ ６０５ａは、取引所１ ６０５ａのＥＳＯＲを用いて、残り２，０００株の買い注文Ｄ６１３ｄを取引所２ ６０５ｂに対してルーティングする。
一実施例において、ＨＦＴ６０６は、取引所１ ６０５ａから取引レポートＢ６１３ｂを受け取る。一実施例において、同一場所に配置されていることにより、ＨＦＴ６０６は、取引レポートＢ６１３ｂを「数十マイクロ秒」で受け取ることができる。ＨＦＴ６０６は、取引所２ ６０５ｂに対して注文訂正Ｃ６１３ｃ（先に入力した、＄１０．００でＸＹＺ２，０００株を売る注文に対する訂正）を送信する。ＨＦＴ６０６は、取引所１ ６０５ａにおいて、ＸＹＺ株が取引された知識から利益を得ることを試みる。例えば、他の買い注文（Ｄ）が取引所２ ６０５ｂへルーティングされることを予測し、注文Ｃを＄１０．０１まで調整する。この例において、買い指値＄１０．００の注文Ｄ６１３ｄは、約定されず、ブローカ６１５は、別の買い注文＄１０．０１を送信しなければならない。最終的に、新たな買い注文が取引所２ ６０５ｂにおいて約定されると、投資家は、残りのＸＹＺ２，０００株を購入するために＄２０．００を余分に支払うことになる（＄０．０１＊２，０００＝＄２０．００）。注文Ｃ６１３ｃのレインテンシーは、接続性や情報送信方法（例えば、マイクロ波ｖｓファイバ）によって定まる。
一実施例において、レインテンシー（Ａの送信時間＋Ｂの送信時間＋Ｃの送信時間）＜Ｄの送信時間である場合、ブローカ６１５（投資家６１４の代理）は、取引所２ ６０５ｂにおいて、＄１０．００でＸＹＺ２，０００株の買い注文を約定させることができない。その結果、注文は、その時点で充足されず、又は投資家６１４は、新たな買い注文を通じて残り１，０００株を購入するためにより高い価格を支払わなければならない。
図６Ｄは、ＰＥＢＯＭの実施形態において、ＰＯＰアクセスポイントを備えるＥＳＯＲを介してレインテンシーアービトラージを管理する例を示す。一実施例において、取引所１ ６０５ａは、＄１０．００のＸＹＺ１，０００株の売り注文を有し、取引所２ ６０５ｂは、＄１０．００のＸＹＺ２，０００株の売り注文を有する（取引所２ ６０５ｂにおける注文は、ＨＦＴ６０６によって先に入力されたものである。全米最良売り気配は、＄１０．００のＸＹＺ３，０００株の連結売り価格である）。
一実施例において、投資家６１４は、ＸＹＺ３，０００株を＄１０．００で購入しようとし、ブローカ６１５に対して＄１０．００でＸＹＺ３，０００株の買い注文を送信する。一実施例において、ブローカ６１５は、取引所１ ６０５ａのＳｍａｒｔ Ｏｒｄｅｒ Ｒｏｕｔｅｒ（ＥＳＯＲ）を使おうとし、注文を受け取った後、＄１０．００でＸＹＺ３，０００株を購入する注文Ａ６１３ａ全体を取引所１ ６０５ａに対してルーティングする。取引所１ ６０５ａは、このとき、ブローカ６１５に代わって残り２，０００株の買い注文Ｄ６１３ｄをルーティングする役割を担う。
一実施例において、ブローカ６１５の注文Ａ６１３ａは、取引所１ ６０５ａに到着し、投資家６１４は、（ブローカ６１５を通じて）取引所１ ６０５ａにおいて、＄１０．００で１，０００株を購入する。注文を約定させた後、取引所１ ６０５ａは、取引所１ ６０５ａのＥＳＯＲを用いて、注文Ｄ６１３ｄを取引所２ ６０５ｂに対してルーティングする。ＨＦＴ６０６は、取引所１ ６０５ａから取引レポートＢ６１３ｂを受け取る。一実施例において、同一場所に配置されていることにより、ＨＦＴ６０６は、取引レポートＢ６１３ｂを「数十マイクロ秒」で受け取ることができる。ＨＦＴ６０６は、取引所２ ６０５ｂに対して注文訂正Ｃ６１３ｃ（先に入力した、＄１０．００でＸＹＺ２，０００株を売る注文に対する訂正）を送信する。ＨＦＴ６０６は、取引所１ ６０５ａにおいて、ＸＹＺ株が取引された知識から利益を得ることを試みる。例えば、他の買い注文（Ｄ）が取引所２ ６０５ｂへルーティングされることを予測し、注文Ｃを＄１０．０１まで調整する。この例において、買い指値＄１０．００の注文Ｄ６１３ｄは、約定されず、ブローカ６１５は、＄１０．０１で別の買い注文を送信しなければならない。このように、投資家６１４は、残りのＸＹＺ株を購入するために＄２０．００を余分に支払うことになる（＄０．０１＊２，０００＝＄２０．００）。注文Ｃ６１３ｃのレインテンシーは、接続性や情報送信方法（例えば、マイクロ波ｖｓファイバ）によって定まる。
但し、ＥＢＯＭ ＰＯＰアーキテクチャＰＯＰ ６１０により、ＥＳＯＲは、レインテンシーアービトラージからクライアントの注文を保護する機会を得ることができる。これは、ＨＦＴ６０６が取引レポートＢを受け取ってシグナルとして用いる前に時間量に対してレインテンシー（距離又は媒体により）を追加することによってなされる。（Ａの送信時間＋Ａｉの送信時間＋Ａｉｉの送信時間＋Ｂの送信時間＋Ｃの送信時間）＞Ｄの送信時間となるからである。この場合ブローカ６１５（投資家６１４の代理）は、ＨＦＴ６０６の注文訂正Ｃ６１３ｃが取引所２ ６０５ｂに到着する前に、取引所２ ６０５ｂにおいて、＄１０．００でＸＹＺ２，０００株の買い注文Ｄ６１３ｄを約定させるだけの十分な時間を有する。その結果、注文は、完全に充足され、投資家６１４は、図６Ａに示すように新たな買い注文を通じて残り２，０００株を購入するためにより高い価格を支払う必要はない。
図６Ｅ〜図６Ｈは、オーダブックアービトラージの管理に関する例である。実施例において、市場参加者は、オーダブックアービトラージのアドバンテージを得る。このストラテジは、代替可能証券を取引する取引所間（又は市場センタ間）のレインテンシー差から仲介者が利益を得ることができるようにするものである。オーダブックアービトラージは、受動的に実行されることもあり、積極的に実行されることもある。例えば、受動的オーダブックアービトラージは、仲介者が最新の市場データを有しており、先に送信された注文を劣った価格でそのまま取引所（又は他の市場センタ）に留め置く場合に生じ、これにより、積極的注文を入力した古くなった市場データに基づき、その注文がより低速な参加者によって約定されることを期待するものである。一方、積極的オーダブックアービトラージは、取引所（又は他の市場センタ）が自身のオーダブック上に残っている注文を再値付けし、他の取引所（又は他の市場センタ）における市場データ変化を処理する速度が仲介者よりも遅い場合に、生じるものである。最新市場データを有する仲介者は、古くなった市場データに基づき低速取引所上で取引を約定させ、これは、その取引所（又は他の市場センタ）のオーダブック上の注文にとって不利益となる。
図６Ｅは、ＥＢＯＭの実施形態における受動的オーダブックアービトラージの例を示す。例えば、一実施例において、ブローカ６１５、ＨＦＴ６０６、取引所１ ６０５ａ、及び取引所２ ６０５ｂは、ＸＹＺのＮＢＢＯが＄１０．００×＄１０．０２であることを知っている。ＨＦＴ６０６は、取引所１ ６０５ａにおいて、ＸＹＺ１，０００株を＄１０．００で購入する注文Ａ６１３ａを入力する。注文Ａ６１３ａの約定に続き、取引所２ ６０５ｂにおける＄１０．０１×＄１０．０２への市場更新、値付け更新Ｂ６１３ｂ、Ｂｉ、及びＢｉｉは、ＨＦＴ６０６、取引所１ ６０５ａ、及びブローカ６１５に対してそれぞれ送信される。新たなＮＢＢＯは、＄１０．０１×＄１０．０２となる。距離差に起因して、取引所１ ６０５ａと取引所２ ６０５ｂは、異なるＮＢＢＯを有していることになる。すなわち、それぞれの取引ブックの価格が異なっている。すなわち、取引所１ ６０５ａでは、＄１０．００×＄１０．０２、取引所２ ６０５ｂでは、＄１０．０１×＄１０．０２である。
一実施例において、ＨＦＴ６０６は、値付け更新Ｂ６１３ｂを受け取り、よって取引所２ ６０５ｂにおける新たなＮＢＢＯ（＄１０．０１×＄１０．０２）を知る。ＨＦＴ６０６は、また、自身の＄１０．００の１，０００株買い注文Ａ６１３ａが取引所１ ６０５ａに留まっていることを知っている。低速な市場参加者（例えば、ブローカ６１５）は、最新市場情報Ｂｉｉを受け取っていないので、取引所１ ６０５ａにおいて、ＸＹＺ株を＄１０．００で売ろうとすることを期待して、ＨＦＴ６０６は、その買い注文Ａ６１３ａを＄１０．００に留めておく。
１０００一実施例において、ブローカ６１５は、前のＮＢＢＯ（＄１０．００×＄１０．０２）に基づき＄１０．００のＸＹＺ１，０００株売り注文Ｃ６１３ｃを取引所１ ６０５ａに対して入力する。この後、ブローカ６１５がＢｉｉを受け取る前に値付け変更Ｂ、Ｂｉ、Ｂｉｉが続く。取引所１ ６０５ａがＢｉを受け取る前に、注文Ｃ６１３ｃは、不利な価格による約定（＄１０．００×＄１０．０２）を受け取る。取引所１ ６０５ａが他の市場において値付けされた不利な価格による取引から自身のオーダブック上における注文を保護する義務がある場合（例えば、ＵＳにおいては、Ｒｅｇｕｌａｔｉｏｎ ＭＳに準拠する必要がある）、取引所１ ６０５ａが値付け更新Ｂ６１３ｂを受け取り、より有利なビッド価格（＄１０．０１）が存在することを知ると、売り注文Ｃ６１３ｃを＄１０．００で取引することを許可しない（＄１０．００における約定は、Ｒｅｇｕｌａｔｉｏｎ ＭＳの下では、「ｔｒａｄｅ ｔｈｒｏｕｇｈ」とみなされる）。
但し、値付け更新Ｂ６１３ｂを受け取る前に取引所１ ６０５ａが売り注文Ｃ６１３ｃを受け取る場合、取引所１ ６０５ａは、売り注文Ｃ６１３ｃを＄１０．００で約定させることを許可する（値付け変化に気づかないため）。これは、現在の最良買い気配＄１０．０１よりも不利な価格である。この場合投資家６１４は、ＸＹＺ株売りにおいて、受取額が＄１０．００少なくなる（１，０００×＄０．０１＝＄１０．００）。
このように、ＨＦＴ６０６が値付け更新Ｂ６１３ｂを受け取った後、注文Ａ６１３ａを変化させないままにしておけば、ＨＦＴ６０６は、ＸＹＺ株を＄１０．００で購入し、即座に取引所２ ６０５ｂにおいて、＄１０．０１で売却し、投資家６１４を犠牲にして利益を得ることができる。
図６Ｆは、ＥＢＯＭの実施形態において、受動的オーダブックアービトラージをＰＯＰアクセスポイントによって中立化することにより管理する例を示す。例えば、一実施例において、ブローカ６１５、ＨＦＴ６０６、取引所１ ６０５ａ、及び取引所２ ６０５ｂは、ＸＹＺのＮＢＢＯが＄１０．００×＄１０．０２であることを知っている。ＨＦＴ６０６は、取引所１ ６０５ａにおいて、ＸＹＺ１，０００株を＄１０．００で購入する注文Ａ６１３ａを入力する。取引所２ ６０５ｂにおける＄１０．０１×＄１０．０２への市場更新、値付け更新Ｂ６１３ｂ、Ｂｉ、及びＢｉｉは、ＨＦＴ６０６、取引所１ ６０５ａ、及びブローカ６１５に対してそれぞれ送信される。新たなＮＢＢＯは、＄１０．０１×＄１０．０２となる。距離差に起因して、取引所１ ６０５ａと取引所２ ６０５ｂは、異なるＮＢＢＯを有していることになる。すなわち、取引所１ ６０５ａでは、＄１０．００×＄１０．０２、取引所２ ６０５ｂでは、＄１０．０１×＄１０．０２である。
一実施例において、ＨＦＴ６０６は、値付け更新Ｂ６１３ｂを受け取り、よって取引所２ ６０５ｂにおける新たなＮＢＢＯ（＄１０．０１×＄１０．０２）を知る。ＨＦＴ６０６は、また、自身の＄１０．００の１，０００株買い注文Ａ６１３ａが取引所１ ６０５ａに留まっていることを知っている。低速な市場参加者（例えば、ブローカ６１５）は、最新市場情報Ｂｉｉを受け取っていないので、取引所１ ６０５ａにおいて、ＸＹＺ株を＄１０．００で売ろうとすることを期待して、ＨＦＴ６０６は、その買い注文Ａ６１３ａを取引所１ ６０５ａにおいて、＄１０．００に留めておく。
一実施例において、ブローカ６１５は、投資家６１５に代わって取引所１ ６０５ａに対して１，０００株の売り注文Ｃ６１３ｃを入力する。取引所１ ６０５ａが他の市場において値付けされた不利な価格による取引から自身のオーダブック上における注文を保護する義務がある場合（例えば、ＵＳにおいては、Ｒｅｇｕｌａｔｉｏｎ ＭＳに準拠する必要がある）、取引所１ ６０５ａが値付け更新Ｂｉ６１８ａを受け取り、より有利なビッド価格（＄１０．０１）が存在することを知ると、売り注文Ｃ６１３ｃを＄１０．００で取引することを許可しない。
一実施例において、ＥＢＯＭ ＰＯＰアーキテクチャＰＯＰ６１０により、取引所１ ６０５ａは、ブローカ６１５の注文Ｄ６１３ｄが取引所１ ６０５ａに到着する前に、値付け変化Ｂｉ６１８ａを受け取ることができる。したがって取引所１ ６０５ａは、最新市場データが＄１０．０１×＄１０．０２であることを知り、注文Ｃ６１３ｃを＄１０．００で取引することを許可しない。
このように、ＨＦＴ６０６が値付け更新Ｂ６１３ｂを受け取った後、注文Ａ６１３ａを変化させないままにする場合、ＥＢＯＭ ＰＯＰアーキテクチャＰＯＰ６１０は、投資家６１４が古い値付け情報で取引することを防ぎ、ＨＦＴ６０６が投資家６１４を犠牲にして利益を得ることを防ぐ。
図６Ｇは、ＥＢＯＭの実施形態における積極的オーダブックアービトラージの例を示す。図６Ｇに示すように、この例は、古い値付けアービトラージｖｓミッドポイントペッグ注文で取引する。但し、メカニズムは、同じである。したがって、全米最良買い気配（National Best Bid：ＮＢＢ）又は全米最良売り気配（National Best Offer：ＮＢＯ）において、同じアービトラージ機会が古い値付けに対して適用される可能性がある。
一実施例において、ブローカ６１５、ＨＦＴ６０６、取引所１ ６０５ａ、及び取引所２ ６０５ｂは、ＸＹＺのＮＢＢＯが＄１０．０１×＄１０．０３であることを知っている。ブローカ６１５は、投資家６１４に代わり、取引所１ ６０５ａに対して注文Ａ６１３ａを入力する。注文Ａ６１３ａは、ＸＹＺ１，０００株を購入するものであり、ＮＢＢＯミッドポイント（＄１０．０２）にペッグされている。取引所２ ６０５ｂにおける＄１０．００×＄１０．０２の市場更新、値付け更新Ｂ６１３ｂ、Ｂｉ６１８ａ、及びＢｉｉ６１８ｂは、ＨＦＴ６０６、取引所１ ６０５ａ、及びブローカ６１５に対してそれぞれ送信される。新たなＮＢＢＯは、＄１０．００×＄１０．０２になり、新たなミッドポイントは、＄１０．０１になる。距離差に起因して、取引所１ ６０５ａと取引所２ ６０５ｂは、異なるＮＢＢＯとミッドポイントを有していることになる。すなわち、取引所１ ６０５ａでは、＄１０．０１×＄１０．０３でミッドポイントは、＄１０．０２、取引所２ ６０５ｂでは、＄１０．００×＄１０．０２でミッドポイントは、＄１０．０１である。
一実施例において、ＨＦＴ６０６は、値付け更新Ｂ６１３ｂを受け取り、よって新たなＮＢＢＯとミッドポイント（＄１０．００×＄１０．０２と＄１０．０１）を知っている。ＨＦＴ６０６は、また、取引所１ ６０５ａにおけるミッドポイントが未だ以前のＮＢＢＯ（＄１０．０１×＄１０．０３と＄１０．０２）に基づき値付けされていることを知っている。ＨＦＴ６０６は、古いミッドポイント＄１０．０２において、売り注文Ｃ６１３ｃを取引所１ ６０５ａに対して送信し、ブローカ６１５の注文Ａ６１３ａを不利なミッドポイント価格で取引する。これにより投資家６１４に対して＄１０．００のコスト負担をかけることになる（１，０００＊０．０１＝＄１０．００）。
したがって、（Ｂの送信時間＋Ｃの送信時間）＜Ｂｉの送信時間であれば、ＨＦＴ６０６は、取引所１ ６０５ａにおいて、即座にＸＹＺ株を＄１０．０２で売り、取引所２ ６０５ｂにおいて、即座にＸＹＺ株をミッドポイント＄１０．０１で購入する。これにより投資家６１４を犠牲にして利益を得ることになる。
図６Ｈは、ＥＢＯＭの実施形態において、ＰＯＰアクセスポイントにより積極的オーダブックアービトラージを管理する例を示す。図６Ｇの古い値付けアービトラージに続いてＰＯＰ６１０が設置されると、ＨＦＴ６０６の注文Ｃ６１３ｃは、ＥＢＯＭ ＰＯＰアーキテクチャＰＯＰ６１０を通過する必要がある。（Ｂの送信時間＋Ｃの送信時間＋Ｃｉの送信時間）＞Ｂｉの送信時間であれば、取引所１ ６０５ａは、値付け更新Ｂｉをタイミングよく受け取ることができ、ミッドポイントを最新情報（＄１０．００×＄１０．０２と＄１０．０１）に更新する。ブローカ６１５の注文Ａ６１３ａは、不利なミッドポイント価格で約定されない。
ＴＬＬの別実施形態は、以下を含む。
実施形態において、ＴＬＬは、買い手及び売り手からの売買注文をマッチングし、約定させる市場である。ＴＬＬは、また、当該ＴＬＬ上でマッチングできない場合、これら注文を他の市場へルーティングする。ＴＬＬは、買い手及び売り手に対して米国内で流通する現金等価商品を提供する義務がある場合がある。但し、システム組織の原則は、米国その他の国家規制、地理的規制、及び／又は規制地域と同様に、その他の商品、金融商品、その他の有価物の売買に対して適用することができる。
ＴＬＬは、コンピュータハードウェア上で動作する複数のコンポーネントを備えることができる。これは、以下を含むが、これらに限らない：クライアントＦＩＸゲートウェイ、マッチングエンジン、ルーティングエンジン、取引所／ベニューＦＩＸゲートウェイ、市場データティッカープラント、注文取引データベース、決済、請求、調査システム及びインタフェース等。これらは、内部メッセージバスを介して相互通信し、他の取引所、ベンダ、商品ブローカ等と外部通信する。以下に、新規かつ有用なコンポーネントとシステムの要素を説明する。
ＴＬＬは、既存の取引ベニューの取引において、「高頻度取引」（high-frequency trading：ＨＦＴ）として知られる手法を用いた取引ストラテジによるアドバンテージに対抗する。
＜信頼性＞
ＴＬＬは、クライアント／サーバモデルを採用することができる。「クライアント」は、例えば、他のプログラムが提供するサービスを用いるプログラムである。このサービスを提供するプログラムは、「サーバ」と呼ばれる。サーバは、クライアント要求に対して、データ、ステータス情報等を返信することにより機能する。幾つかの実施形態において、クライアントは、他のバックエンドサービスやストレージとやり取りする前にビジネスプロセスロジックを実施するサーバに接続し、及び／又はサーバに対して応答し、サーバは、クライアントに対して返信する。
ＴＬＬは、クライアント／サーバモデルを採用することができる。「クライアント」は、例えば、他のプログラムが提供するサービスを用いるプログラムである。このサービスを提供するプログラムは、「サーバ」と呼ばれる。サーバは、クライアント要求に対して、データ、ステータス情報等を返信することにより機能する。幾つかの実施形態において、クライアントは、他のバックエンドサービスやストレージとやり取りする前にビジネスプロセスロジックを実施するサーバに接続し、及び／又はサーバに対して応答し、サーバは、クライアントに対して返信する。
ＴＣＰ−ｔｏ−Ｍｕｌｔｉｃａｓｔ（Ｔ２Ｍ）は、メッセージが単一のフロントエンドサーバから複数のバックエンドサーバに対して配信されるものである。幾つかの実施形態において、これによりリソース使用を最適化し、スループットを最大化し、フォールトトレランスを向上させ、その他のセキュリティ及び品質保証（ＱＡ）を実現することができる。
Ｔ２Ｍは、外部クライアントがバックエンドサービスにアクセスするため接続するポートに接続するコンポーネントである。プログラムは、クライアントからの通信をＴＣＰプロトコルで保持し、マルチキャスト（ＵＤＰプロトコル）配信によりバックエンドサービスに対してデータペイロードを送信する。ＴＣＰプロトコルは、一対一通信を提供する一方で、マルチキャストは、一対多通信を提供する。これにより、複数のバックエンドサービスは、データを処理し及び／又は別のバックエンド／ダウンストリームサービスに対して送信する前に、単一ソースからの元のデータペイロードを同時に受け取ることができる。
Ｔ２Ｍを介した一対多通信により、クライアントは、単一ＴＣＰ接続を生成することができる。このＴＣＰ接続は、Ｎ個のバックエンドリソースに対する接続として広がる。この一対多通信は、クライアントにとって見えないが、多くの利点を提供する。具体的には、以下のうち少なくとも１つを実現する：アーキテクチャロジックからビジネスロジックを抽象化することに起因する配信リスクを最小化する；複数サーバに対してクライアント通信セッションを複製する；フロントエンドサービスから独立してバックエンドサービスをスケーリングする；クライアントは、バックエンドサービスに対して直接接続せず、これにより内部ネットワーク構造とカーネルネットワークスタックを隠蔽し、システムセキュリティを向上させる；クライアントポート接続に負担をかけることなく日中キャパシティスケーリングとロードバランシングを実現する；データセンタ内又はデータセンタ間におけるクライアント通信のリアルタイムシームレスフェイルオーバを実現し、フォールトトレランス、レジリエンス、災害復帰性能を向上させる；元のデータペイロードを用いたリアルタイムＱＡ分析のための個別のパラレルストリーム；等。
＜物理ハードウェアとネットワーク＞
＜地理的に異なるシステムに対する確実な同時情報配信＞
異なる地理的場所から中央ポイントに対してデータを送信するためには、通信時間及び通信距離に応じて異なる時間長が必要である。その結果、２つの地理的場所から中央ポイントに対して同時に送信されたデータは、異なる時刻に到着する。幾つかの実施形態において、この補正は、ソフトウェアを用いてなされるが、そのようなシステムは、複雑であり、エラーを生じ易く、不正確である。
＜地理的に異なるシステムに対する確実な同時情報配信＞
異なる地理的場所から中央ポイントに対してデータを送信するためには、通信時間及び通信距離に応じて異なる時間長が必要である。その結果、２つの地理的場所から中央ポイントに対して同時に送信されたデータは、異なる時刻に到着する。幾つかの実施形態において、この補正は、ソフトウェアを用いてなされるが、そのようなシステムは、複雑であり、エラーを生じ易く、不正確である。
様々なチャネルによるデータ送信は、様々な制約により制限される。例えば、一実施例において、これは、光ファイバチャネルによりなされる。この場合、通信速度は、チャネル媒体を介して光速度により制限される。この実施形態において、伝搬時間は、伝搬距離を媒体の光速度で除算することにより求められる。したがって伝搬時間は、媒体に距離を追加するか又は媒体を変更することにより、平準化することができる。短いチャネルに距離を追加することにより送信媒体の長さを平準化すると、情報を同時配信することができる。幾つかの実施形態において、これは、ナノ秒以内の同時配信を保証する。
＜地理的に異なる取引システムに対する確実な同時情報配信＞
多くの取引システムは、地理的に異なる場所に物理的に配置された取引システムに対して、光技術を用いて情報を送信する。少なくとも部分的には、取引システムの地理的違いに起因して、更に現行通信手法と規制の組み合わせにより、全ての取引システムから完全に等しい距離にある点はない。その結果、多くの取引システムは、情報配信を時間平面上で実施し、このタスクを実施するためには、複雑でエラーを生じ易く不正確なソフトウェア駆動の手法を用いなければならない。
多くの取引システムは、地理的に異なる場所に物理的に配置された取引システムに対して、光技術を用いて情報を送信する。少なくとも部分的には、取引システムの地理的違いに起因して、更に現行通信手法と規制の組み合わせにより、全ての取引システムから完全に等しい距離にある点はない。その結果、多くの取引システムは、情報配信を時間平面上で実施し、このタスクを実施するためには、複雑でエラーを生じ易く不正確なソフトウェア駆動の手法を用いなければならない。
先に述べたように、情報は、光通信を介して光ファイバに沿って各場所に対して送信される。受信確認応答は、同じ経路の別の光ファイバチャネルに沿って送信される。これらは、何れも、光ファイバチャネルが使用する媒体に起因して、光速度の制約を受ける。幾つかの実施形態において、光ファイバチャネルの送信距離（ｄ）をチャネルの媒体の光速度で除算すると、情報を送信元から宛先に対して送信するのに必要な送信時間（ｔ）を求めることができる。全ての取引システムから完全に等しい距離にある点は存在しないので、距離が異なる光ファイバチャネル（但し、媒体は、同じ）上の送信距離は異なり、したがって送信元システムから送信される情報は、各宛先システムに異なる時刻に到着する。
情報の同時配信は、各送信側光ファイバチャネルの光チャネルケーブルに対して距離を追加し、及び／又はチャネル媒体を変更する等により、情報が伝搬する距離を平準化することによって可能となる。すなわち、情報の配信時間（ｄ／ｓ＝ｔ）が全てのチャネルにおいて、等価となるようにすることである。一実施形態において、通信プロバイダが提供するチャネルセットの距離を測定し、短いチャネルに対して長さを追加して長さを平準化することにより、情報配信は、実質的に同時となる。すなわち、例えば、ナノ秒範囲内となる。これに対し、ソフトウェア駆動手法を用いた場合では、ミリ秒範囲となる。
＜ネットワークアプリケーションにおける混雑通知及び回避のためのアプリケーションバッファ利用率レポート＞
バッファブロート（bufferbloat）は、過剰に大きいバッファを用いることによりネットワーク化されたアプリケーションに対して非決定的レインテンシーを導入するものとみなすことができる。幾つかの実施形態において、これは、レインテンシーターゲットをセットすると共に、特定のレインテンシー測定について、これらのターゲットを維持するように動作することによって達成される。これら技術は、ＴＣＰソケットを利用するシステムにおいてのみ用いられ、２つの重要な制約を有する：（１）大きく広がったアプリケーションを効率的に取り扱うことができない、（２）アプリケーションに対して非透過的である。
バッファブロート（bufferbloat）は、過剰に大きいバッファを用いることによりネットワーク化されたアプリケーションに対して非決定的レインテンシーを導入するものとみなすことができる。幾つかの実施形態において、これは、レインテンシーターゲットをセットすると共に、特定のレインテンシー測定について、これらのターゲットを維持するように動作することによって達成される。これら技術は、ＴＣＰソケットを利用するシステムにおいてのみ用いられ、２つの重要な制約を有する：（１）大きく広がったアプリケーションを効率的に取り扱うことができない、（２）アプリケーションに対して非透過的である。
これら２つの制約（非透過性と非効率な広がり）により、ＣｏＤｅｌアルゴリズムを用いるＴＣＰは、広範囲に分散したシステムにおいて、バッファブロートの課題を取り扱うのに不十分となる。分散システムは、通常、プライベートネットワーク上にホストされており、プライベートネットワークは、専用アプリケーションに対してオペレータが完全にコントロールすることができるので、各アプリケーションのバッファ利用に関する情報を上下流アプリケーションに対して特定のデータパス内において、直接的に配信する方がより効率的である。
バッファ利用に関する情報を例えば、０〜２５５の単一数値で配信することにより、各アプリケ−ションは、そのすぐ隣における負荷を把握し、更にデータ送信するか否かをスマートに決定することができる。例えば、バッファ利用に関する情報が規定閾値に達すると、アプリケーションは、配線上で更にデータを送信することを停止する。この「一時停止」により、停止したアプリケーションのバッファ利用は、増加する。この情報が上流アプリケーションに対して配信される。以下同様である。アプリケーションに対してバッファ利用情報を明示的に通知することにより、アプリケーションは、送信を停止でき、下流アプリケーションのバッファが飽和して新たにデータを受け取ることができなくなった後にアプリケーションがデータ送信を続けたとき起こるパケットロスを防止することができる。またこれにより、アプリケーションがロストパケットを再送信しようとするとき生じる過剰な再送信遅延を回避することができる。更に、バッファ利用情報を明示的に通知することにより、分散システムの末端間レインテンシーは、単一アプリケーションバッファを枯渇させる遅延の５０％近辺で振動する。
＜アクティブ／パッシブフェイルオーバシステムのアクティブメンバを確実かつ効果的に停止させる自動化方法＞
ＴＬＬは、パッシブシステムメンバが新たなアクティブシステムメンバになるため幾つかの動作セットが必要な特徴を備えた、アクティブ／パッシブシステムである場合がある。アクティブ／パッシブシステムの一実施例において、１つのメンバのみがアクティブであり、所与の時刻において、データを処理しており、他のメンバは、アクティブになるのを待っているものとする。アクティブ／パッシブシステムの特性に起因して、ＴＬＬは、フェイルオーバを実施する間に「アクティブ」システムによる動作を停止させる。この停止は、一般に、「ｓｈｏｏｔ ｔｈｅ ｏｔｈｅｒ ｎｏｄｅ ｉｎ ｔｈｅ ｈｅａｄ」又はＳＴＯＮＩＴＨとして知られている。これにより、フェイルオーバ後にアクティブであるメンバが１つのみとなることを保証する。これにより、以前のマスタは、システムの制御を再アサートしようとすることはなくなり、或いは、２つ目のマスタとして動作し続けることはなくなる。このような動作は、アクティブ／パッシブシステムの性質に起因して、メッセージを不正確に多重化する可能性がある。
ＴＬＬは、パッシブシステムメンバが新たなアクティブシステムメンバになるため幾つかの動作セットが必要な特徴を備えた、アクティブ／パッシブシステムである場合がある。アクティブ／パッシブシステムの一実施例において、１つのメンバのみがアクティブであり、所与の時刻において、データを処理しており、他のメンバは、アクティブになるのを待っているものとする。アクティブ／パッシブシステムの特性に起因して、ＴＬＬは、フェイルオーバを実施する間に「アクティブ」システムによる動作を停止させる。この停止は、一般に、「ｓｈｏｏｔ ｔｈｅ ｏｔｈｅｒ ｎｏｄｅ ｉｎ ｔｈｅ ｈｅａｄ」又はＳＴＯＮＩＴＨとして知られている。これにより、フェイルオーバ後にアクティブであるメンバが１つのみとなることを保証する。これにより、以前のマスタは、システムの制御を再アサートしようとすることはなくなり、或いは、２つ目のマスタとして動作し続けることはなくなる。このような動作は、アクティブ／パッシブシステムの性質に起因して、メッセージを不正確に多重化する可能性がある。
ＳＴＯＮＩＴＨは、第２ノードがプライマリシステムとシャットダウンについてやり取りすることにより、自動的に実現することができる。或いは、管理者が現在のアクティブ（マスタ）ノードにログインし、アクティブノードの動作を終了させるコマンドを実行することにより、手動で実現することもできる。但し、この方法が失敗する状況が幾つかある。
アクティブノードを適切に終了させるため、ＴＬＬは、ノードが動作しているハードウェア（例えば、サーバ）に対する接続を遠方側の接続において、遠隔終了させる。厳密なケーブル規格と組み合わせると、アクティブ／パッシブシステムのアクティブメンバの位置は、パッシブメンバによりアルゴリズム的に決定される。このときアクティブメンバの状態は、関係ない。パッシブメンバがアクティブノードの不具合を検出すると、パッシブノードは、アクティブノードが接続されているネットワークデバイスと直接通信し、アクティブノードが接続しているネットワークポートを無効化する。アクティブノードも必要であれば、ネットワーク接続された電力供給装置に直接接続し、同様に以前のアクティブノードから電力を除去する。これら２つの動作により、以前アクティブノードであったものが自身をシステムのアクティブメンバとして再アサートすることを防止できる。
＜演算効率／テスト／メッセージング＞
＜クライアントゲートウェイにおけるＩＤマッピング及び管理（ｌｕｇｇａｇｅ＋ＩｅｘＩＤ）＞
外部ＦＩＸクライアントを有する多くの取引システムインタフェースは、取引システムに対して送信される注文ＩＤ（ＦＩＸフィールドＣｌＯｒｄＩｄ）を処理するのが困難である。これらＩＤは、外部システムに対してのみ一意的であり（例えば、システム１とシステム２は、共に取引システムに対してｉｄ＝ＡＢＣＤの注文を送信する）、その長さと内容は、外部システム間で大幅に異なる。‘幾つかの実施形態において、これら注文を一意に識別するための解決手段は、顧客ＩＤ（ＦＩＸフィールドＳｅｎｄｅｒＣｏｍＩＤ）と注文ＩＤ（例えば、システム１の注文Ａ＝‘Ｃｕｓｔｏｍｅｒ１−ＡＢＣＤ’）を連結することにより、外部システムの注文に対して内部的にアドレスを付与することである。これは、有効なアプローチであるが、性能問題が生じる可能性がある。システム内において、外部システムを一意に識別するために長い文字列を使用しなければならず、クロスレファレンスを生成して各データベース、ファイルシステム、キャッシュメモリ内に格納しなければならないからである。これにより、そのＩＤへアクセスする必要があるプロセスにとって多大なオーバヘッドが生じ、失敗したプロセスから復元する必要がある場合に技術的な課題が生じる。
＜クライアントゲートウェイにおけるＩＤマッピング及び管理（ｌｕｇｇａｇｅ＋ＩｅｘＩＤ）＞
外部ＦＩＸクライアントを有する多くの取引システムインタフェースは、取引システムに対して送信される注文ＩＤ（ＦＩＸフィールドＣｌＯｒｄＩｄ）を処理するのが困難である。これらＩＤは、外部システムに対してのみ一意的であり（例えば、システム１とシステム２は、共に取引システムに対してｉｄ＝ＡＢＣＤの注文を送信する）、その長さと内容は、外部システム間で大幅に異なる。‘幾つかの実施形態において、これら注文を一意に識別するための解決手段は、顧客ＩＤ（ＦＩＸフィールドＳｅｎｄｅｒＣｏｍＩＤ）と注文ＩＤ（例えば、システム１の注文Ａ＝‘Ｃｕｓｔｏｍｅｒ１−ＡＢＣＤ’）を連結することにより、外部システムの注文に対して内部的にアドレスを付与することである。これは、有効なアプローチであるが、性能問題が生じる可能性がある。システム内において、外部システムを一意に識別するために長い文字列を使用しなければならず、クロスレファレンスを生成して各データベース、ファイルシステム、キャッシュメモリ内に格納しなければならないからである。これにより、そのＩＤへアクセスする必要があるプロセスにとって多大なオーバヘッドが生じ、失敗したプロセスから復元する必要がある場合に技術的な課題が生じる。
代替実施形態においては、ＴＬＬは、内部システムフォーマット（ＩｅｘＩＤ）に基づいて、外部システムの注文ＩＤ（ＣｌＯｒｄＩｄ）を一意生成したＩＤと置き換え、クロスレファレンス情報をマルチキャストメッセージストリームに公開する。幾つかの実施形態においては、「ｌｕｇｇａｇｅ」と呼ばれる別のメッセージを用いて外部システムの元のＣｌＯｒｄＩｄを保存し、これにより、外部システムＩＤとＩｅｘＩＤとの間のマッピングがＴＬＬに保存される。ＴＬＬは、非クリティカルな「ｌｕｇｇａｇｅ」データをメインデータパス外で送信する。ＦＩＸゲートウェイ自身又は他のレポーティングシステム等の宛先エンドポイントも、必要に応じて「ｌｕｇｇａｇｅ」メッセージを収集し、ＩｅｘＩＤをＣｌＯｒｄＩｄへデコード（アンマップ）する。但し、多くの場合、システムは、元の外部システム注文ＩＤを見る必要はない。幾つかの実施形態において、これによりシステムのデータ処理効率を高めることができる。一意生成したＩｅｘＩＤは、マルチキャストメッセージストリーム上における全リスナが知っている既知の効率的なフォーマットで生成することができる。これにより、処理の一貫性を保つと共に、必要に応じてメッセージストリームとやり取りする全システムに対してＩｅｘＩＤを公開することができる。
図７は、実施例のサンプルデータフローを示す。顧客１ ７０２は、注文情報を入力し（７０５）、注文ＡＢＣＤを送信する（７１０）。注文ＩＤは、Ｃｕｓｔｏｍｅｒ１−ＡＢＣＤである。クライアントＦＩＸゲートウェイは、注文を受け取り、ＩＤをマッピングし（７１５）、システムに対して情報を送信する。ＴＬＬは、内部注文ＩＤ１００１等の一意的ＩＤを生成する（７１５）。ＴＬＬは、「ｌｕｇｇａｇｅ」メッセージをＴＬＬに対して送信し（７２０）、これは、関連するコンポーネントのために保存される（Ｌｕｇｇａｇｅ［Ｃｕｓｔｏｍｅｒ＝１，ＣｌＯｒｄＩｄ＝ＡＢＣＤ，ＩｅｘＩＤ＝１００１］）。ＴＬＬは、注文メッセージをＩｅｘＩＤ＝１００１で送信する。次に注文は、充足され又はマッチングされる（７２５）。この情報は、マッチングエンジンクライアントゲートウェイによってＩＤ＝１００１で送信される。クライアントゲートウェイは、顧客１についてＩｅｘＩＤ＝１００１をＡＢＣＤに復元し（７３０）、顧客に対して元のＩＤでフィルインディケータを送信する（７３５）。取引レポートアプリケーションも、適切なポスト取引システムのために「ｌｕｇｇａｇｅ」に基づきフィルインディケータを変換すると共に、ＩＤをアンマップする。
＜メッセージの一意的識別子としてのシーケンス番号の使用＞
マルチプロセスマルチマシンシステムにおいて、一意的ＩＤを生成することは、困難な課題である。カウンタを用いるシンプルなアプローチは、有用でない場合がある。複数の場所において、同一ＩＤが生成される可能性があり、状態の種類によっては、プロセスが再スタートするとき重複ＩＤが生成されないように保存しておかなければならないからである。一実施形態において、生成された場所を示す記述子をＩＤに対して追加することにより、これを解決することができる。例えば、ｍａｃｈｉｎｅ０１．ｐｒｏｃｅｓｓ０２．ｓｅｓｓｉｏｎ０１．［ｃｏｕｎｔｅｒ］である。これは、比較的簡易であり集中的な障害点（centralized point of failure）が存在しないが、ＩＤは、本来必要なものよりも長くなり、再起動するときセッションをトラッキングすることが困難になる。またマシンとプロセスを一意的に名付ける必要がある。他の実施形態においては、集中的ＩＤ生成を用いてもよく、この場合、ＩＤは、サービス、データベース等の専用プロセスによって作成される。これは、シンプルであり集中制御することができるが、ＩＤを取得するオーバヘッドと集中的な障害点が問題となる可能性がある。
マルチプロセスマルチマシンシステムにおいて、一意的ＩＤを生成することは、困難な課題である。カウンタを用いるシンプルなアプローチは、有用でない場合がある。複数の場所において、同一ＩＤが生成される可能性があり、状態の種類によっては、プロセスが再スタートするとき重複ＩＤが生成されないように保存しておかなければならないからである。一実施形態において、生成された場所を示す記述子をＩＤに対して追加することにより、これを解決することができる。例えば、ｍａｃｈｉｎｅ０１．ｐｒｏｃｅｓｓ０２．ｓｅｓｓｉｏｎ０１．［ｃｏｕｎｔｅｒ］である。これは、比較的簡易であり集中的な障害点（centralized point of failure）が存在しないが、ＩＤは、本来必要なものよりも長くなり、再起動するときセッションをトラッキングすることが困難になる。またマシンとプロセスを一意的に名付ける必要がある。他の実施形態においては、集中的ＩＤ生成を用いてもよく、この場合、ＩＤは、サービス、データベース等の専用プロセスによって作成される。これは、シンプルであり集中制御することができるが、ＩＤを取得するオーバヘッドと集中的な障害点が問題となる可能性がある。
他の実施形態において、システムの専用マルチキャストミドルウェアが提供するメッセージシーケンス番号を、一意的ＩＤとして用いることができる。ＴＬＬが受信する全てのメッセージは、日単位で一意であることを保証され、単調増加する番号である。集中ＩＤシステム（データベース、ファイル、メモリ等）を呼び出す必要はない。またＩＤは、現在のシステム状態に対する参照も提供する。この技術は、ＴＬＬの複数の場所において、利用することができるが、特に一意的顧客注文チェーンＩＤを生成するときに利用することができる。
例えば、ＴＬＬを介して設定１〜１０を送信し、このときシーケンス番号＝１０であり、ＴＬＬを介して市場データ値付け１〜３を送信し、このときシーケンス番号＝１３である。顧客注文１が到着するとき、シーケンス番号＝１４である。ＴＬＬは、システム一意的ＩＤが必要な注文チェーンを生成する。ＴＬＬは、これを生成し、又は中央サービスに対して新ＩＤを生成するよう要求する一方で、ＴＬＬは、注文チェーンを生成する契機となった顧客注文メッセージのシーケンス番号を用いる。注文チェーンＩＤ＝シーケンス番号＝１４である。これにより、ＩＤは、一意的かつコンパクトとなり、更なる演算は不要である。このシーケンス番号は、システムのそのときの状態に対応する時刻点も表しているため、ＴＬＬは、注文が生じた時刻における最新市場データを判定することができる。
＜順番付けされた市場データ＞
取引システムにおける金融市場データのスピードと量は、困難な課題である。毎日数億件のデータ更新があり、データは、即座に消費されるときに最も価値が高いからである。古いデータは、価値が低い。取引システムは、複数のプロセスと機能の間でプロセスを分割するように設計することができる。例えば、取引エンジン１に対して「Ａ」で開始するシンボルのみを見るように指示する。或いは、市場データを個別に使用するアプリケーションを有している場合もある。市場データを分割することにより、決定に関する課題が生じる。市場データに関心があるプロセスは、互いに異なる状態を有している場合があるからである。これらプロセスは、データを個別に見ており、システム状態は、プロセス間で不整合となる可能性があるからである。以下に例を示す。
取引システムにおける金融市場データのスピードと量は、困難な課題である。毎日数億件のデータ更新があり、データは、即座に消費されるときに最も価値が高いからである。古いデータは、価値が低い。取引システムは、複数のプロセスと機能の間でプロセスを分割するように設計することができる。例えば、取引エンジン１に対して「Ａ」で開始するシンボルのみを見るように指示する。或いは、市場データを個別に使用するアプリケーションを有している場合もある。市場データを分割することにより、決定に関する課題が生じる。市場データに関心があるプロセスは、互いに異なる状態を有している場合があるからである。これらプロセスは、データを個別に見ており、システム状態は、プロセス間で不整合となる可能性があるからである。以下に例を示す。
市場データ（ＭＳＦＴ）→プロセス１→注文＃２を処理しているプロセス１は、ＭＳＦＴ＠＄１０．０１を知っている。
市場データ（ＭＳＦＴ）→プロセス２→注文＃２を処理しているプロセス２は、ＭＳＦＴ＠＄１０．０２を知っている。
ＴＬＬは、代わりに、順番付け／シリアライズする全ての市場データをミドルウェア経由で送信する。これにより、市場の状態は、任意の時刻において、システム全体にわたって各アプリケーションにおいて、同一となる。以下に例を示す。
市場データ（ＭＳＦＴ）→シーケンサ→プロセス１→注文＃２を処理しているプロセス１は、ＭＳＦＴ＠＄１０．０１を知っている。
プロセス２→注文＃２を処理しているプロセス２は、ＭＳＦＴ＠＄１０．０１を知っている。
ＴＬＬ全体にわたって市場データが同一状態であることは、複数の利点がある。例えば、ある取引において、ＴＬＬは、その取引についての市場データ状態更新のメッセージＩＤ（シーケンス番号）をノートすることにより、取引メッセージ上の市場データ状態にラベル付けする。（例えば、取引１５が発生し、値付け５２は、現在の市場状態を表す）これは、特定時刻における市場状態を識別する便利かつ効率的な手法である。市場データを順番付けしない場合、その他の解決策は、顧客毎に現在の市場状態を書きだすことになり、或いは、市場状態を時刻ベースで引き出すことになる（これは、不完全及び／又は不正確である）。
＜トリガフレームワーク＞
ＴＬＬトリガフレームワークにより、厳密に制御され、透過性が高く、均一な態様で、複雑なビジネスロジックを配置することができる。一実施形態において、目的は、モジュール化されたロジックを構築することである。これにより、開発者は、特定のタスクに専念することができ、多くのアプリケーションがロジックを再利用することができる。トリガフレームワークは、２タイプのコンポーネントを有する：条件（Ｃｏｎｄｉｔｉｏｎ）とアクション（Ａｃｔｉｏｎ）である。
ＴＬＬトリガフレームワークにより、厳密に制御され、透過性が高く、均一な態様で、複雑なビジネスロジックを配置することができる。一実施形態において、目的は、モジュール化されたロジックを構築することである。これにより、開発者は、特定のタスクに専念することができ、多くのアプリケーションがロジックを再利用することができる。トリガフレームワークは、２タイプのコンポーネントを有する：条件（Ｃｏｎｄｉｔｉｏｎ）とアクション（Ａｃｔｉｏｎ）である。
これら２つのコンポーネントは、条件が本体でありアクションがブランチであるバイナリデシジョンツリーとして構成することができる。
条件は、アプリケーション内のオブジェクトの現在状態を評価すると共に、その条件が満たされるか否かを示すｔｒｕｅ又はｆａｌｓｅを戻す個々のクラスである。オブジェクトは、例えば、ＦＩＸプロトコルのＮｅｗＯｒｄｅｒＳｉｎｇｌｅ要求のような一時的メッセージ、又はＰａｒｅｎｔＯｒｄｅｒオブジェクトのような状態ベースデータ構造である。
アクションは、条件が満たされたときビジネスロジックを実行する個々のクラスである。一般にアクションクラスは、特定の状態変化が生じたときメッセージを生成する。アクションは、評価されているオブジェクト及び／又は他のオブジェクトやアプリケーションとやり取りしているオブジェクトを変更する。
条件とアクションは、モジュール化されたコンポーネントとして記述することができ、設定ファイル（例えば、ＪＳＯＮフォーマット）を通じてデシジョンツリー内で連結させることができる。このフレームワークにより、コンポーネントの再利用性、デバッグ、メンテナンス、ロジックの視覚的理解を高めて効率化することができる。
ワークフローの例において、アプリケーションにメッセージを入力してもよい。そのメッセージは、トリガキューに追加され、及び／又はそのメッセージにより他のオブジェクトがトリガキューに追加される。オブジェクトは、トリガキューから１つずつ引き出され評価される。オブジェクトが評価されるとき、そのオブジェクトが状態ベースオブジェクトである場合、関連する状態ツリーがその状態に基づき引き出されるか、或いは、そうでなければそのオブジェクトタイプに対応するデフォルトツリーが読み出される。関連ツリー内の条件がトップから開始して評価される。例えば、条件がｔｒｕｅと評価された場合、ｉｆＴｒｕｅ分岐が続き、或いは、その反対も同様である。条件ツリーは、アクションに到達し実施されるまで横断される。アクションを実施すると：トリガされたオブジェクト又は他のオブジェクトに対して状態変化が実施され；他のオブジェクトを生成し；トリガキューに他のオブジェクトを追加し；１以上のメッセージを配信し；又はこれらの組み合わせが実施される。トリガキューが完全に評価されると、アプリケーションは、次に入力されたメッセージを処理する。
条件は、多くの異なるオブジェクトタイプに対して評価することができる。例えば、オブジェクトの関連商品シンボルが中止されているか否かをチェックする条件は、ＮｅｗＯｒｄｅｒＳｉｎｇｌｅ ＦＩＸメッセージ、市場データ更新メッセージ、ＰａｒｅｎｔＯｒｄｅｒオブジェクト、ルータオブジェクト等に対して評価することができる。
＜テストハーネス＞
テストハーネスにより、テスト担当者は、アプリケーションの自動テストを実施することができる。テストハーネスは、テストするアプリケーションを読み出し、ハーネスをアプリケーションの入出力バルブに接続する。予め例えば、ＪＳＯＮフォーマットで記述したインジェクトメッセージ及び期待メッセージを読み出す。インジェクトメッセージは、アプリケーションに対して入力され、これにより出力メッセージが得られる。メッセージは、アプリケーションによって出力され、出力メッセージは、予め読み出した期待メッセージリストと比較される。幾つかの実施形態において、出力メッセージが期待メッセージに合致しない場合、出力メッセージが範囲外である場合、又はテストハーネスが期待した出力メッセージを出力しない場合、テストは、失敗する。それ以外であればテストは、通過する。
テストハーネスにより、テスト担当者は、アプリケーションの自動テストを実施することができる。テストハーネスは、テストするアプリケーションを読み出し、ハーネスをアプリケーションの入出力バルブに接続する。予め例えば、ＪＳＯＮフォーマットで記述したインジェクトメッセージ及び期待メッセージを読み出す。インジェクトメッセージは、アプリケーションに対して入力され、これにより出力メッセージが得られる。メッセージは、アプリケーションによって出力され、出力メッセージは、予め読み出した期待メッセージリストと比較される。幾つかの実施形態において、出力メッセージが期待メッセージに合致しない場合、出力メッセージが範囲外である場合、又はテストハーネスが期待した出力メッセージを出力しない場合、テストは、失敗する。それ以外であればテストは、通過する。
幾つかの実施形態において、テストハーネスは、メッセージテンプレートを実装する。ユーザは、テスト間にまたがって再利用できるメッセージテンプレートを生成する。テストを生成するとき、各メッセージは、テスト生成者により指定されて使用するテンプレートを単純参照し、テストハーネスは、メッセージをパースして呼び出したテンプレートフィールドの全ての値を自動的に読み出す。またテストにおいて、フィールド値が指定された場合、その指定値は、テンプレートからコピーされた値を上書きする。これによりテストの生成と変更が簡単になる。テストに関連するメッセージ上の関連フィールドのみを指定／修正すればよいからである。その他のフィールドは、テンプレート設計のときデフォルト値を割り当て、これにより時間と負担を節約できる。
幾つかの実施形態において、テストハーネスにより期待メッセージに対して選択的にフィールド検証を実施することができる。テストにおいて、検証のため用いる期待メッセージは、完全に整形したメッセージである必要はない。任意個数のフィールドを備えることができる。指定したフィールドのみが検証され、出力メッセージ上のその他の全フィールドは、無視される。この機能により、期待テストは、特定フィールドを検証することに専念でき、メッセージ全体を検証するよりも効率的である。また、効果的に予測することができないタイムスタンプのような動的フィールドを取り扱う際に特に有用である。
幾つかの実施形態において、テストハーネスにより期待メッセージに対して選択的メッセージ検証を実施することができる。ユーザは、テストにおいて、検証するメッセージタイプのリストを指定する。アプリケーションが出力するその他のメッセージタイプは、全て無視される。これにより、テストに関連しないメッセージ、例えば、ハートビートメッセージをフィルタリングすることができる。
幾つかの実施形態において、テストハーネスによりケースを生成することができる。テストハーネスは、インジェクトメッセージのリストのみを使用するモードを有し、アプリケーションに対してそのメッセージを１つずつ投入する。アプリケーションが出力する全メッセージが収集され、新たなテストケースファイルが両リストから生成される。
幾つかの実施形態において、テストハーネスによりケースをマス生成することができる。テストハーネスは、設定したインジェクトメッセージのリストと個別メッセージのリストを使用するモードを有する。テストハーネスは、テストするアプリケーションを読み出し、アプリケーションに対して設定したメッセージを投入し、個別メッセージリストから１つのメッセージを投入する。テストハーネスは、アプリケーションから全ての出力を収集し、完全整形したテストケースを生成する。次にテストハーネスは、アプリケーションを再スタートし、個別メッセージリストの次メッセージに対して以下のサイクルを繰り返す：読み出し＞設定したメッセージを投入する＞個別メッセージを投入する＞収集する。このプロセスは、個別メッセージリスト内の各メッセージについてテストファイルが生成されるまで繰り返される。このようにテストハーネスは、例えば、顧客が送信した注文のフィールドの全ての順列をテストする等、多数の類似テストを自動生成することができる。
幾つかの実施形態において、テストハーネスにより複数アプリケーションをテストすることができる。テストハーネスは、複数アプリケーションを読み出し、その個々の機能と共に、他のアプリケーションとやり取りする各アプリケーションの機能をテストすることができる。テストハーネスは、指定された順序で指定されたアプリケーションセットを読み出す。幾つかの実施形態において、これは、順次やり取りするアプリケーションセットを通過するメッセージフローに基づく。テストハーネスは、セット内の最初のアプリケーションに対してインジェクトメッセージを入力し、出力メッセージを検証し、その出力メッセージを次のアプリケーションに対して投入し、検証し、以下同様である。
テストハーネスは、テストを個別に実施してもよく、同時に複数のテストを実施してもよい。幾つかの実施形態において、テスト間でアプリケーションを再スタートしてもよい。テストハーネスは、自動ビルドプロセスに組み込み、テストケースの全リストを実施し、開発者がコードをコミットする毎にレポートを生成することができる。
＜テストケースを動的構築するウェブユーザインタフェース＞
テストビルダユーザインタフェース（test builder user interface）は、任意のＪＳＯＮデータスキーマに基づきテストケースを動的構築する手段を提供する。幾つかの実施形態において、テストＵＩは、ＪＳＯＮフォーマットで読み出すスキーマファイルを特定する。このスキーマファイルは、システムメッセージセットを定義する。スキーマのフォーマットに基づき、ユーザは、生じ得るメッセージリストの提示を受ける。ユーザがメッセージを選択すると、メッセージのフォーマットに基づきフォームが動的に構築される。これは、特定のデータ検証ルールと共にスキーマにおいて定義することができる。ユーザは、次に、規定のメッセージテンプレートリストの提示を受ける。このテンプレートを選択してフォームを埋めることができる。ユーザがメッセージフォームの入力を完了すると、これは、ソート可能リストに追加される。ユーザは、各メッセージアイテムをテストフレームワークに対して投入する順序でソートする。完了したメッセージ集合は、テンプレートとして保存することができ、テンプレートを組み合わせて複雑なテストケースを形成することができる。ユーザは、テストハーネスがメッセージをインジェクトメッセージとして又は期待メッセージとして取り扱うべきか否かを指定する。期待すべきメッセージが何であるかをユーザが確信していない場合、ＵＩは、全ケースを完了する前にテストケースの一部を投入することを許可する。部分テストケースは、ＲＥＳＴによりサーバに対して供給することができる。サーバは、テストハーネスのインスタンスを呼び出し、テストメッセージの部分セットを投入する。テストハーネスが生成する出力メッセージは、ＵＩに戻され、ユーザに対して表示される。ユーザは、各メッセージを検証する。ユーザがメッセージを承認する場合、テストケース完了ボタンをクリックすることにより、メッセージが現在のテストケースに追加される。このメッセージは、テンプレートとして保存される。テストケースが完了すると、ボタンをクリックしてＪＳＯＮ形式のテストケースファイルを生成する。このテストケースは、テストハーネスによって実行され、継続ビルドプロセス内で実装される。
テストビルダユーザインタフェース（test builder user interface）は、任意のＪＳＯＮデータスキーマに基づきテストケースを動的構築する手段を提供する。幾つかの実施形態において、テストＵＩは、ＪＳＯＮフォーマットで読み出すスキーマファイルを特定する。このスキーマファイルは、システムメッセージセットを定義する。スキーマのフォーマットに基づき、ユーザは、生じ得るメッセージリストの提示を受ける。ユーザがメッセージを選択すると、メッセージのフォーマットに基づきフォームが動的に構築される。これは、特定のデータ検証ルールと共にスキーマにおいて定義することができる。ユーザは、次に、規定のメッセージテンプレートリストの提示を受ける。このテンプレートを選択してフォームを埋めることができる。ユーザがメッセージフォームの入力を完了すると、これは、ソート可能リストに追加される。ユーザは、各メッセージアイテムをテストフレームワークに対して投入する順序でソートする。完了したメッセージ集合は、テンプレートとして保存することができ、テンプレートを組み合わせて複雑なテストケースを形成することができる。ユーザは、テストハーネスがメッセージをインジェクトメッセージとして又は期待メッセージとして取り扱うべきか否かを指定する。期待すべきメッセージが何であるかをユーザが確信していない場合、ＵＩは、全ケースを完了する前にテストケースの一部を投入することを許可する。部分テストケースは、ＲＥＳＴによりサーバに対して供給することができる。サーバは、テストハーネスのインスタンスを呼び出し、テストメッセージの部分セットを投入する。テストハーネスが生成する出力メッセージは、ＵＩに戻され、ユーザに対して表示される。ユーザは、各メッセージを検証する。ユーザがメッセージを承認する場合、テストケース完了ボタンをクリックすることにより、メッセージが現在のテストケースに追加される。このメッセージは、テンプレートとして保存される。テストケースが完了すると、ボタンをクリックしてＪＳＯＮ形式のテストケースファイルを生成する。このテストケースは、テストハーネスによって実行され、継続ビルドプロセス内で実装される。
テストＵＩは、スタンドアロンテストハーネスが実行するテストケースを構築するための、完全動的なウェブベースインタフェースを提供する。テストＵＩは、ＪＳＯＮ形式データスキーマにのみ基づき、完全データ検証するフォームを生成する。できる限り少ない単一メッセージを有する部分テストケースは、スタンドアロンテストハーネスに対してオンザフライ形式で投入され、ユーザに対してシステム出力メッセージを提示する。ボタンクリックにより完全動作するテストケースが生成され、テストハーネスは、これを用いる。個々のテストケースを組み合わせて、新しいより複雑なテストケースを生成することもできる。
＜単一ＵＩ要素を用いて複雑なデータクエリを生成する方法＞
ウェブアプリケーションのなかには、マルチカラムデータをクエリする手段をユーザに対して提供するものがある。幾つかの実施形態において、インタフェースは、フォーム要素を提供する。ユーザは、これにより、データ要素タイプ毎に検索語を入力することができる。これに代えて、単一検索ボックスを提供し、複数データタイプにまたがって適用される検索語をユーザが入力できるようにしてもよい。
ウェブアプリケーションのなかには、マルチカラムデータをクエリする手段をユーザに対して提供するものがある。幾つかの実施形態において、インタフェースは、フォーム要素を提供する。ユーザは、これにより、データ要素タイプ毎に検索語を入力することができる。これに代えて、単一検索ボックスを提供し、複数データタイプにまたがって適用される検索語をユーザが入力できるようにしてもよい。
別実施形態において、構造化検索フィールドを用いることができる。ユーザは、単一入力ボックスの提示を受ける。これは、規定スキーマに基づき構造化入力にしたがう。
一実施形態において、ユーザは、入力ボックスを選択し、ボックスの現在のコンテキストを示唆するツールティップの提示を受ける。入力ボックスは、複数データタイプを含む場合もある。各データタイプは、スペース等の文字で区切ることができ、注文ＩＤ、ベニュー、ブローカ、価格、シンボル等を含む。
幾つかの実施形態において、例えば、スペースボタンを押下することによりユーザが選択ボックスを進めると、入力ボックスのコンテキストは、次の検索語に進む。新たなツールティップが提示され、ユーザに対して検索語を示す。
幾つかの実施例では、ユーザは、検索ボックスを進め、コンテキストがこれにともなって変わると、ボックスは、可能性のある検索語をドロップダウンリストとして表示するように構成されている。
幾つかの実施形態において、ユーザが検索ボックスを進める毎に、データベース、データビュー、及び／又はファイルに対して動的クエリが実施され、最終結果がユーザに対して速やかに表示される。
別実施形態において、構造化検索フィールドは、：規定スキーマに準じた単一入力ボックスにおいて、複数の検索語を使用する；スキーマをその場でスイッチし、これにより検索語のタイプ又は検索語を入力する順番を変更する；ユーザが検索ボックスを進めると各検索語についてオートコンプリート検索語を表示する；ユーザがスペースバーをヒットすると検索ボックスを進めることができるようにし、検索ワイルドカードを自動入力できるようにする；ユーザが検索ボックスを前方又は後方にナビゲートできるようにする；ユーザによる先の検索語入力を利用して、後の検索語として可能性のあるものを得る；ユーザが検索ボックスを進めるとツールティップを表示して、カーソル位置において、検索語を示唆する；複数カラムにまたがる複雑なクエリに対する応答を動的に改善及び最適化する；等。
＜取引ロジック発明＞
＜ミッドポイント制約＞
株取引約定の価格付けは、パッシブ注文がオーダブックに対して投入された（及び価格優先のためランク付けされた）ときの価格を用いてなされる。積極的に値付けされた２つの注文が互いに対して約定される場合、オーダブックに対して最初に到着し入力された注文の価格で約定される。具体的には、早い方の注文は、自身の積極的な価格を支払い、遅い方の注文は、「より有利な価格」を得る。別手法において、ＴＬＬオーダブックは、約定価格を変更しない。これに代えて、ＴＬＬオーダブックに対して積極的に入力することができる限度を設定する。
＜ミッドポイント制約＞
株取引約定の価格付けは、パッシブ注文がオーダブックに対して投入された（及び価格優先のためランク付けされた）ときの価格を用いてなされる。積極的に値付けされた２つの注文が互いに対して約定される場合、オーダブックに対して最初に到着し入力された注文の価格で約定される。具体的には、早い方の注文は、自身の積極的な価格を支払い、遅い方の注文は、「より有利な価格」を得る。別手法において、ＴＬＬオーダブックは、約定価格を変更しない。これに代えて、ＴＬＬオーダブックに対して積極的に入力することができる限度を設定する。
ＴＬＬは、ミッドポイント制約と呼ばれるコンセプトを用いる。ＴＬＬオーダブックにおいて、積極的隠れ注文又は非表示注文は、全米最良気配（national best bid/offer：ＮＢＢＯ）のミッドポイント以上に積極的な価格で投入されることはない。２つの積極的に値付けされた隠れ注文がブックに投入され、ミッドポイントに再値付けされると、ミッドポイント価格で約定される。購入者は、より高い価格を支払う意図を有しており、売却者は、より低い価格で売却する意図を有しているので、何れもよりよい約定価格（すなわち価格が改善される）を得ることができる。これにより、ＴＬＬブックに到着した注文によらず、２つの反対売買者の間でスプレッド（ビッド価格とオファー価格との間の差分）を公平に分配することができる。
ミッドポイント制約は、その他の利点も提供する。ブックに入力された注文が価格優先のためにランキングされるときの価格を制約することにより、ミッドポイント制約は、隠れキューにおける価格優先のための不必要な競争を抑制する。これは、「ｐｅｎｎｙｉｎｇ」の形態でなされる。すなわち、僅かに積極的な指値で注文を送信することにより、一方が他方に対して優先権を得ようと試みることである。ミッドポイント制約は、実効価格による方向性の情報リークも抑制する。ビッド価格とオファー価格との間のミッドポイントで約定すると、方向性がない取引履歴となる。したがって、この時点においては、価格が何れの方向に動くか（高値に動くか、それとも安値に動くか）、また新たな注文が供給増加又は需要増加の何れを表しているかを識別することが難しい。また、ＴＬＬオーダブックにおける積極的に値付けされた条件注文の公平なランキングを維持することができる。
ミッドポイント制約は、隠れ注文がＴＬＬオーダブックに投入されることを試みる毎にその指値が約定できるか否か反対側の未約定注文と比較されるように実装することができる。約定することができない場合、注文の指値は、ＮＢＢＯミッドポイントと比較される。注文価格がミッドポイントよりも積極的に値付けされている場合、ミッドポイントでオーダブックに格納される。注文価格がミッドポイントと比較して積極的ではない場合、注文は、指値でオーダブックに格納される。このプロセスは、ミッドポイント制約価格を先行処理することにより高速化することができる。これは、市場データ変化によりミッドポイントが変化したときＮＢＢＯのミッドポイントを計算することによりなされる。幾つかの実施形態において、これは、制約ミッドポイントを先行計算してＴＬＬオーダブックに投入しようとする注文に対しその計算結果を適用することにより実施される。
＜最小量＞
最小量注文は、インバウンド（新規）である場合、反対側単一注文そのもの又は集約した多数注文が集合的にインバウンド注文の最小量条件を満たす限り、反対側の単一注文又は多数注文に対する取引に適格である。但し、インバウンド注文の最小量条件を満たす単一注文又は多数注文がない場合、そのインバウンド注文は約定されず、代わりにオーダブックに格納される。この注文がオーダブックに格納されると、合計して最小量条件を満たす新たな反対側インバウンド注文に対してのみ受動的に約定される。インバウンド最小量注文がオーダブックに挿入された場合、将来の何れかの時点において、市場条件が変化し及び／又は新たな反対側注文がオーダブックに入力されると、その最小量注文は、最小量条件を満たす多数注文に対する取引について適格ではなくなることがある。
最小量注文は、インバウンド（新規）である場合、反対側単一注文そのもの又は集約した多数注文が集合的にインバウンド注文の最小量条件を満たす限り、反対側の単一注文又は多数注文に対する取引に適格である。但し、インバウンド注文の最小量条件を満たす単一注文又は多数注文がない場合、そのインバウンド注文は約定されず、代わりにオーダブックに格納される。この注文がオーダブックに格納されると、合計して最小量条件を満たす新たな反対側インバウンド注文に対してのみ受動的に約定される。インバウンド最小量注文がオーダブックに挿入された場合、将来の何れかの時点において、市場条件が変化し及び／又は新たな反対側注文がオーダブックに入力されると、その最小量注文は、最小量条件を満たす多数注文に対する取引について適格ではなくなることがある。
＜ブック再チェック＞
ブック再チェックにより、最小量注文は、より利便性が増す。これは、ＴＬＬオーダブックに格納した後、複数の反対側注文に対して最小量条件を満たす機会を改めて付与することによりなされる。ＴＬＬオーダブックにおける適格な市場取引可能注文をブック優先度順で繰り返し、何れかがブックの反対側に対して取引可能であるか否かチェックし、ブックの反対側の注文が新たなインバウンド注文であれば注文を処理することにより、ブック再チェックは動作する。これは、オーダブックのマッチングロジックにとって演算負荷が高く、コスト高なプロセスである。
ブック再チェックにより、最小量注文は、より利便性が増す。これは、ＴＬＬオーダブックに格納した後、複数の反対側注文に対して最小量条件を満たす機会を改めて付与することによりなされる。ＴＬＬオーダブックにおける適格な市場取引可能注文をブック優先度順で繰り返し、何れかがブックの反対側に対して取引可能であるか否かチェックし、ブックの反対側の注文が新たなインバウンド注文であれば注文を処理することにより、ブック再チェックは動作する。これは、オーダブックのマッチングロジックにとって演算負荷が高く、コスト高なプロセスである。
オーダブックのマッチングロジックに対する演算コストを緩和するため、外部プロセスは、再チェックした注文をキャンセルし、マッチングエンジンに対して新たなものとして戻す。これにより、再チェックが注文を完全に約定しない場合、キャンセルされた注文は、時間優先度を失う。
ＴＬＬは、再チェックされた注文に対する参照を保持する。これにより、オーダブック内の注文を削除又は再注文することなくブック再チェックを実施できるようにする。これにより再チェックされた注文は、完全充足されなかった場合でも時間優先度を完全に維持できる。これら注文参照を更新し、成功した再チェックと失敗した再チェックの双方に適用し、これによりブック優先度がプロセス全体を通じて維持されるようにする。
成功するブック再チェックプロセスは、任意個数のイベントによってトリガされる。このイベントは、以下を含むがこれに限らない：サブスクライバからの新注文指示；全米最良気配の変化；その他の市場データ変数の変化。これらデータは、コンパイル及びプリプロセスされ、集約株数等の数値と様々な規制取引制約に変換される。これにより、再チェック動作を実際に実施する前に、約定することができそうか、できなさそうか、或いは、保証されているかを確定する。このように、プリプロセスによりブック再チェックの演算コストを更に抑制することができる。
＜最小量ティア＞
最小量指示は、０から注文総数までの任意の丸め数値取引数を認めることができる（注文の取引数に等しい最小量は、ａｌｌ−ｏｒ−ｎｏｎｅ注文条件として取り扱う）。理論的に無限数の最小量条件を認めることによりサブスクライバにとっては、最も柔軟性が高まるが、これは、非現実的である。多数の注文を有し最小量条件をともなう注文が散在しているオーダブックにおいて、注文が約定可能であるか否か比較するプロセスは、理論的に無限となる。換言すると、注文ペア又は複数注文を組み合わせて注文の最小量条件を満たし約定できるか否かを判定するため、ブック内において、理論的に無限個数の注文組み合わせの比較が生じ得る。最小量指示は、オーダブック全体にわたって無限に変化し得るので、ブック全体にわたって各未約定注文が充足された最小量指示を有しているか否かを判定することなしに、所与のインバウンド注文に対して何株が利用可能であるかを判定する手段はない。また、インバウンド注文に対して取引したくない（すなわち、充足されてない最小量指示を有している）多数の注文をオーダブックが有している場合、各注文を個別にチェックしてスキップすることなしに、それら注文を分離する効率的な手段はない。
最小量指示は、０から注文総数までの任意の丸め数値取引数を認めることができる（注文の取引数に等しい最小量は、ａｌｌ−ｏｒ−ｎｏｎｅ注文条件として取り扱う）。理論的に無限数の最小量条件を認めることによりサブスクライバにとっては、最も柔軟性が高まるが、これは、非現実的である。多数の注文を有し最小量条件をともなう注文が散在しているオーダブックにおいて、注文が約定可能であるか否か比較するプロセスは、理論的に無限となる。換言すると、注文ペア又は複数注文を組み合わせて注文の最小量条件を満たし約定できるか否かを判定するため、ブック内において、理論的に無限個数の注文組み合わせの比較が生じ得る。最小量指示は、オーダブック全体にわたって無限に変化し得るので、ブック全体にわたって各未約定注文が充足された最小量指示を有しているか否かを判定することなしに、所与のインバウンド注文に対して何株が利用可能であるかを判定する手段はない。また、インバウンド注文に対して取引したくない（すなわち、充足されてない最小量指示を有している）多数の注文をオーダブックが有している場合、各注文を個別にチェックしてスキップすることなしに、それら注文を分離する効率的な手段はない。
ＴＬＬは、有効最小量及び最小量ティアを備えることができる。有効な最小量ティアのセットにより、順列の個数を制限し、最も一般的に選択されている最小量値を把握する（例えば、２００、３００、５００、１，０００、５，０００、１０，０００株）。サブスクライバの注文に対する最小量指示がティアと整合していない場合、ＴＬＬマッチングエンジンとオーダブックは、有効最小量を用いて動作し、その値を次に低いティアに対してルーティングする。サブスクライバの従前の値を維持し、マッチングロジックについては有効値を用いるようにしてもよい。
最小量指示を有限組の共通に使用される値にまとめることにより、最小量注文の約定をよりスムーズにすることができる。標準値を用いることにより、最小量指示が僅かな差でニアミスする可能性が低くなるからである。例えば、最小量５７５株の注文は、最小量５５０株や５２５株等の注文とは、マッチングされない。このようなニアミスは、過剰に細かい最小量を用いることにより生じる。この場合、注文を入力したサブスクライバが、サイズが非常に近い反対側注文があることを知れば、取引を望んだと考えられる状況でも、２つの注文は、マッチングされない。ティアに対する最小量オプションを制約することにより、この課題を減殺することができる。例えば、ティアに１００株ずつ１００〜１，０００株（１００、２００、３００、４００、５００等）まで増やすことを強制することにより、先の例の注文は、全て最小量条件５００に丸められ、互いに取引に適格になる。これにより、最少取引サイズ制約を設定する注文目的がバランスされ、同様のサイズの反対側注文と取引をすることを妨げて不利益とならないようにする。
ＴＬＬオーダブックは、ティアによる最小量注文を管理及び格納する。ＴＬＬオーダブックは、最小量ティアにより有限個数の個々にソートされたオーダブックへパーティショニングされる。最小量でパーティショニングした結果、ブック内の最小量指示は、全注文について同一となる。よってマッチングロジックは、より高速に、インバウンド注文又は再チェック注文に対して利用可能なオーダブック内の株数を評価することができる。ブック内の全注文は、インバウンド注文又は再チェック注文に対して均一に、取引を所望し又は所望しないからである。このコンセプトをＴＬＬオーダブックの各パーティションに対して適用することにより、ＴＬＬは、インバウンド注文又は再チェック注文に対して利用可能な株数を一定時間内で評価することができる。
最小量ティアは、約定途中においても有用である。約定のためにブック全体の優先度に基づいてパーティションを再結合する際、あるパーティションがインバウンド注文に対して最小量を満たさない場合、ＴＬＬマッチングエンジンは、そのパーティションから注文を一切引き出さない。取引を所望するパーティションのみを結合することにより、どの注文がインバウンド注文に対して取引を所望するかに基づき、オーダブック全体をフィルタリングすることができる。これにより、最小量指示に基づき個々の注文を確認してスキップする必要がなくなり、演算効率を向上させることができる。
＜最小量参加＞
未約定の最小量注文が注文キューの前面にない場合、最小量の実装を制限してもよい。十分に大きい積極的値付けした反対側注文が到着したとしても、その注文は、ブック優先度に基づいて、当該注文に先だって未約定注文に対して約定され、当該最小量注文に到達するときまでに十分な株数が残らない可能性がある。例えば、最小量５００株の１，０００株注文よりも先に、１００株の買い注文がオーダブック内にあるものとする。５００株のインバウンド売り注文が到着すると、最初の買い注文と１００株取引し、４００株は、残る。最小量注文は、５００株未満では、取引しないので、元の売り注文のサイズが最小量条件５００株を満たすとしても、残り４００株のインバウンド売り注文とは、取引しないことになる。極端な例として、単元未満買い注文７５株の後に最小量条件１００，０００株のブロック買い注文１００，０００株がオーダブック内にあるものとする。インバウンド売り注文１００，０００株が到着すると、７５株買い注文が約定され、９９，９２５株が残る。９９，９２５株は、ブック内の未約定買い注文の最小量条件１００，０００株を満たさないので、２つのブロック注文は、マッチングされない。
未約定の最小量注文が注文キューの前面にない場合、最小量の実装を制限してもよい。十分に大きい積極的値付けした反対側注文が到着したとしても、その注文は、ブック優先度に基づいて、当該注文に先だって未約定注文に対して約定され、当該最小量注文に到達するときまでに十分な株数が残らない可能性がある。例えば、最小量５００株の１，０００株注文よりも先に、１００株の買い注文がオーダブック内にあるものとする。５００株のインバウンド売り注文が到着すると、最初の買い注文と１００株取引し、４００株は、残る。最小量注文は、５００株未満では、取引しないので、元の売り注文のサイズが最小量条件５００株を満たすとしても、残り４００株のインバウンド売り注文とは、取引しないことになる。極端な例として、単元未満買い注文７５株の後に最小量条件１００，０００株のブロック買い注文１００，０００株がオーダブック内にあるものとする。インバウンド売り注文１００，０００株が到着すると、７５株買い注文が約定され、９９，９２５株が残る。９９，９２５株は、ブック内の未約定買い注文の最小量条件１００，０００株を満たさないので、２つのブロック注文は、マッチングされない。
ＴＬＬは、新たな最小量挙動を用いる。これは、Ｐａｒｔｉｃｉｐａｔｉｏｎ（参加）と呼ばれる。ＴＬＬの最少量注文の挙動は、インバウンドの場合、上記実施例と同一である。但し、オーダブック内に留まっている場合、注文の最少量条件は、約定プロセスの開始時に、最少量注文に対して約定を試みるとき、残り株数ではなくインバウンド注文の株数に対して評価される。これにより、最初の時点で最少量指示が存在した目的に寄与することができる。すなわち、約定する株と約定を断念するシグナル／取引情報との間のバランスを維持すること、及び十分大きい注文とやり取りすることである。
上記ブロック注文の例において、１００，０００株のインバウンド売り注文は、７５株の買い注文と取引されると共に、元の注文サイズ１００，０００株は、残買い注文１００，０００株の最少量注文に合致するため、未約定の１００，０００株の買い注文が取引に「参加」し、９９，９２５株を約定させる。
参加をパーティション化したオーダブックと組み合わせることによって、マッチングロジックは、オーダブック内のオーダ数によらず、インバウンド注文又は再チェック注文の最少量指示を満たすだけの十分な取引株をオーダブックが含んでいるか否かを高速に評価することができる。これにより、約定しない場合の演算負荷と時間を最小化することができる。
＜ＴＬＬ＋１＞
ＴＬＬ＋１は、取引ベニューを選択し、投入する注文を取引ベニューに対してルーティングする。ＴＬＬ＋１は、注文を送信するベニューを選択し、約定手数料等の明確なコストをバランスしつつ約定できる機会を最大化し、特定のベニューにおける注文の一部を常に表そうとするときの値付けによる影響を回避する。
ＴＬＬ＋１は、取引ベニューを選択し、投入する注文を取引ベニューに対してルーティングする。ＴＬＬ＋１は、注文を送信するベニューを選択し、約定手数料等の明確なコストをバランスしつつ約定できる機会を最大化し、特定のベニューにおける注文の一部を常に表そうとするときの値付けによる影響を回避する。
ＴＬＬ＋１は、以下のように機能する：ＴＬＬ Ｓｍａｒｔ Ｏｒｄｅｒ Ｒｏｕｔｅｒは、注文を分割して複数のベニューに留める決定をし、優先ベニューを選択し、場合によっては、少なくとも１つの追加的ベニューを選択する。１つのベニューを優先させる理由は、幾つかある。例えば、ＴＬＬが市場ベニュー自体である場合、遠隔ベニューに注文を送信して約定させるよりもＴＬＬ上で注文を約定させる方が望ましい。追加的ベニューを選択する理由は、優先取引ベニューが、必ずしもブローカが注文を送信するベニューとして最初に選択するベニューではない可能性があり、よい追加的引ベニューを選択して注文の価格を広告することにより、約定を受け取る可能性が増すからである。追加的ベニューは、市場状態と、各ベニューにおいて注文が部分的に約定されるとき反対側のブローカに対して課金される可能性がある料金とに基づいて選択することができる。ＴＬＬ Ｓｍａｒｔ Ｏｒｄｅｒ Ｒｏｕｔｅｒは、現在の市場（全米最良気配）内で表されているベニューのなかからベニューを選択することができる。既に全米最良気配を提示する市場のオーダブックに参加する注文を送信することによって、値付け内部に新たなベニューを導入することが避けられ、すなわち値付けに対する影響を回避できる。これらベニューのなかで最もコスト効果が高いものが反対側のブローカのために選択され、取引が生じる。殆どのブローカは、少なくとも部分的に経済状況に基づきルーティングを決定し、ＴＬＬによって遠隔ベニューにルーティングされた注文が市場価格内で流動性を有する最もコスト効果の高い注文となる場合、ＴＬＬ注文は、他のベニューにおける注文よりも先に、遠隔ベニューにおいて約定される。
注文が準備流動性を有している場合、すなわち注文の一部が表示され一部が隠れている場合、準備流動性は、優先ベニューに留まる。これにより、注文の隠れた部分を最もよく制御することができる。
準備注文の表示部分が充足されると、すなわち優先ベニューにおけるもの又は追加的ベニューにおけるものが充足されると、優先ベニューにおける準備流動性は減少し、元の注文が充足された取引ベニューに対して新たな表示注文が送信される。ロジックは、一般的な準備注文の更新方法と同様に機能する。但し、１つの市場センタではなく異なる市場センタにおいて、注文が２つの（又は多数の）表示部分を有する点を除く。
最終的に、残りの準備流動性がないとき何れかの公開部分が完全に充足されると、他のベニューに残っている公開株は、注文が完全充足されたベニューに再ルーティングされる。
＜バイナリサーチツリー＞
本システムは、汎用目的コンピュータの揮発性メモリ内に実装され、又は物理コンピュータ読取可能媒体上に実装された、ツリーデータ構造に関する。ツリーは、複数のデータノードを有する。各データノードは、数値キーと、そのキーに対応するゼロ以上のデータ値（ｎｕｌｌ値であってもよい）と、子ノードとして指定された他の２つのデータノード、すなわち左子ノード及び右子ノードへの参照とを含む。各参照は、ｎｕｌｌ参照であってもよい。親ノードの子ノード、その子ノードの子ノード等は、親ノードの下位ノードである。親ノードがｎｕｌｌではない左子ノードを有している場合、その左子ノードの数値キーとその左子ノードの各下位ノードは、親ノードの数値キー未満でなければならない。同様に、右子ノードがｎｕｌｌでない場合、その右子ノードの数値キーとその右子ノードの各非ｎｕｌｌ下位ノードは、親ノードの数値キー超でなければならない。ツリーは、ルートノードとして指定されたノードを有し、これは、他のノードの子ノードではない。
本システムは、汎用目的コンピュータの揮発性メモリ内に実装され、又は物理コンピュータ読取可能媒体上に実装された、ツリーデータ構造に関する。ツリーは、複数のデータノードを有する。各データノードは、数値キーと、そのキーに対応するゼロ以上のデータ値（ｎｕｌｌ値であってもよい）と、子ノードとして指定された他の２つのデータノード、すなわち左子ノード及び右子ノードへの参照とを含む。各参照は、ｎｕｌｌ参照であってもよい。親ノードの子ノード、その子ノードの子ノード等は、親ノードの下位ノードである。親ノードがｎｕｌｌではない左子ノードを有している場合、その左子ノードの数値キーとその左子ノードの各下位ノードは、親ノードの数値キー未満でなければならない。同様に、右子ノードがｎｕｌｌでない場合、その右子ノードの数値キーとその右子ノードの各非ｎｕｌｌ下位ノードは、親ノードの数値キー超でなければならない。ツリーは、ルートノードとして指定されたノードを有し、これは、他のノードの子ノードではない。
全ての数値キーは、有限範囲内に収まる。ノードの子ノード及び下位ノードのそれぞれの数値キーが取り得る範囲は、当該ノード自身が取り得る値範囲により定まる。このデータ構造内において、親ノードの各子ノードの値は、当該ノードが取り得る値範囲から計算により生成される。キーとこれに対応するデータ値がツリーに追加されると、ツリーは、ルートノードからキーが配置されている場所まで横断される。この横断によって子ノードに対するｎｕｌｌ参照に到達すると、当該キーについて計算生成した値、ゼロデータ値、及び左右子ノードに対するｎｕｌｌ参照によって新データノードが生成され、横断されたノードにおけるｎｕｌｌ参照は、新ノードへの参照によって置き換えられる。追加するキーを有するノードに到達すると、対応するデータへの参照が、到達したノードに追加される。このように、ツリー構造は、各場所において、キーを決定的に生成することにより、予め定義される。キー生成のために用いる方法の選択により、ツリーに対してキーを挿入する順番に関係なく、既知の最大ノード深度を有する自動バランスされたツリーが正確に生成される。最大ノード深度は、固定され、ツリーは、再バランスされないので、最悪の挿入時間は、再バランスが必要なツリーと比較して非常に小さい。したがって、このツリーは、金融取引システムのように高信頼性が求められるアプリケーションに適している。
本発明の望ましい実施形態において、キー値を事前定義する方法は、ノードが取り得るキー値範囲の中央値を選択することである。但し、その他の方法も本発明の範囲内で用いることができる。オプションとして、ルートノードとその下の子ノードのレイヤは、手動で定めたキー値により初期的に作成してもよく、これらの下位ノードは、上述の所定のキー値を有するようにしてもよい。
他のオプションとして、非ｎｕｌｌデータを有する全ノードが、ルートノード以外のノードが取り得る値範囲内のキーを有する場合、そのルートノード以外のノードを「一時的ルートノード」として指定することができ、元のルートノードに代えて全ツリーを横断する開始点として用いることができる。一時的ルートノードの範囲外のキーがツリーに対して追加されると、一時的ルートノード指定は削除され、元のルートノード又は新たに指定された一時的ルートノードを開始点としてツリーを横断することができる。
別実施例は、値を有する可能性があるノードに対する参照アレイによってツリーを補うことである。例えば、金融商品取引ベニューのオーダブックの場合において、アレイは、商品の前日のクローズ価格範囲内のビッド／オファー価格を含む。可能性があるノードアレイに対するインデックスは、数値キー値から計算される。ノードが「可能性のある」キーによってアクセスされる場合、ツリーに優先してアレイを用いる。ツリーは、新規挿入するときと、アレイの範囲外の「可能性がなさそうな」キーの場合のみ用いられる。
上記発明は、金融商品の売買注文を価格順で整理するために用いることができる。この目的のため、注文価格を数値キーとして用い、注文に関するその他の情報は、関連データとして格納される。ツリーは、価格順で整列された全ノードのリンクリストと共に用いられる。このリンクは、現在の最高価格買い注文と最低価格売り注文（最良買い／売り気配）を有するノードへの特別なリンクを有する。このツリーは、リンクリストを横断することなく新規注文を高速に挿入することを補助する。約定済注文の削除は、リンクリストを用いて実現される。約定は、最良買い／売り気配において、最も多く発生するからである。注文や子ノードを有していないノードは、ツリーとリンクリストから削除される。
但し、本発明のアプリケーションは、この特定のアプリケーションよりも広く適用できる。本発明の範囲は、全ての可能な実施形態を包含するものと解釈すべきである。
図８Ａは、ツリー構造におけるノードとその内容を示す。すなわち、数値キー、ノード配下に配置することができるキー範囲、値アレイ、左右子ノードへの参照である。
図８Ｂは、ツリーの固定スケルトンを示す。取り得るキーは、１〜１２の整数である。各ノードの値を生成するルールは、取り得る値範囲のミッドポイントを取り、ミッドポイントが取り得るキーでない場合は、端数を切り捨てることである。各位置におけるノードのキー値は、予め定められているが、必要なノードのみが割り当てられ、ツリーにおいて、インスタンス化される。これにより、アレイのような事前割り当てするデータ構造と比較して、メモリを節約することができる。
図８Ｃ〜図８Ｄは、１〜１２の範囲で新たなツリーを生成する様子、図８Ｂのミッドポイントルール、及びキー値７を挿入する様子を示す。最初に３ａに示すようにルートはｎｕｌｌであり、ルートの範囲は、ツリーのフルレンジ１〜１２である。図８Ｄにおいて、ルートが生成されキー６が割り当てられる。これは、レンジ１〜１２のミッドポイントを切り捨てたものである。７は、キー値６よりも大きいので、ルートノードの右子ノード下に挿入される。３ｃにおいて、ルートの右子ノードがレンジ７〜１２で生成され、中央値９に切り捨てられる。ここで、７は、９よりも小さいので、９の左子ノード下に配置される。最終的に図８Ｄにおいて、ノード９の左子ノードがレンジ７〜８で生成され、中央値７に切り捨てられる。このキーが挿入しようとしているものなので、関連値がキーノードに対して追加され、操作が完了する。ノード６と９がツリー内に存在しているが、関連値は、割り当てられておらず、関連値を有するノード７とは、異なる形式で表示されている。
図８Ｄは、３ｄに示すツリーに対してキー５を挿入する様子を示す。図８Ｄ．ａにおいて、キー６のルートノードから横断を開始する。５は、６よりも小さいので、左子ノードが選択される。以下の図面において、図面を明確にするためｎｕｌｌ子ポインタは、省略する。図８Ｄ．ｂにおいて、新ノードとして左子ノードが生成され、レンジ１〜５と値３を有する。キー５は、このノードの右子ノード下に配置される。図８Ｄ．ｃは、右子ノード３を生成する様子を示す。レンジは、４〜５、値は、４である。図８Ｄ．ｄは、ノード５の生成、ノード４の右子ノードの生成（レンジは、５〜５）、及びそのノードの挿入を示す。ツリーには、６ノードが存在し、そのうち２つが値を有し、４つは、値を有していない。ノード配置は、２のスケルトンツリーにおける配置と正確に対応しており、ツリーにより全てのキーとノードが同じ位置を有することを保証する。ツリーに対して挿入する順序は、関係ない。
＜無限メモリアドレス空間（ＩＭＡＳ）＞
ＩＥＸメッセージバスマルチキャスト送信コンポーネントは、以下の部分を含む：
１．ストレージ／メモリ又はファイルバックアップ
２.ネットワークＩＯ
３．ＪＮＩインタフェース
４.パフォーマンス
ＩＥＸメッセージバスマルチキャスト送信コンポーネントは、以下の部分を含む：
１．ストレージ／メモリ又はファイルバックアップ
２.ネットワークＩＯ
３．ＪＮＩインタフェース
４.パフォーマンス
＜ストレージ＞
メッセージバスは、メモリマップアプローチを用いて、「無限」メモリアドレス空間を実現する。これは、マシンの物理メモリとディスクストレージの合計容量と同じ大きさである。具体的には、既存ＯＳの仮想アドレス空間−物理メモリ変換機能を利用する。したがって、もう１つのオプションであるリングバッファアプローチに関する限界／課題を回避することができる。リングバッファの限界／課題は、リングバッファ境界を交差するときのストリームフラグメンテーション、メッセージングマイクロバーストにおけるメッセージ消失、所与のサーバ上における固定／スタティックメモリ構成である。
メッセージバスは、メモリマップアプローチを用いて、「無限」メモリアドレス空間を実現する。これは、マシンの物理メモリとディスクストレージの合計容量と同じ大きさである。具体的には、既存ＯＳの仮想アドレス空間−物理メモリ変換機能を利用する。したがって、もう１つのオプションであるリングバッファアプローチに関する限界／課題を回避することができる。リングバッファの限界／課題は、リングバッファ境界を交差するときのストリームフラグメンテーション、メッセージングマイクロバーストにおけるメッセージ消失、所与のサーバ上における固定／スタティックメモリ構成である。
無限メモリアドレス空間は、スタート時は、仮想メモリ４テラバイトを有し、進行するスライドウィンドウを用いる。アプリケーションから見ると、アドレス空間は、連続しているように見える。したがってＩＭＡＳは、メッセージフラグメンテーション、ラップアラウンド、メッセージ消失、一般的な設計における複雑なロジックに関する不要なオーバヘッドを回避することができる。要するに、スライドウィンドウにより、常時使用されるメモリブロックは、現在利用可能なメモリ内に配置され、不要となったメモリは、自動的に破棄及び再利用される。アプリケーションから見ると、１つの巨大な連続メモリを用いることができる。この設計は、本システムのようなストリームベースメッセージシステムにおいて、好適に動作する。
＜ゼロコピーとマルチキャストデータストリーミングを実現する線形メモリバッファメカニズム＞
従来のネットワークＩ／Ｏは、小バッファのリストを用い、これらを固定サイズメモリページへコピーする。或いは、アプリケーションが消費する固定サイズを用いる。このアプローチは、以下のような幾つかの欠点がある。
１．メッセージの大バーストを吸収できない
２．ゼロコピーではなく、レインテンシーが生じる
３．複数ページ又はリングバッファを用いる場合、メッセージフラグメンテーションを生じさせる
別アプローチは、論理上の巨大仮想メモリピース（１６テラバイト）を割り当て、ネットワークＩ／Ｏがこの仮想メモリに対して直接ストリーミングすることである。メモリは、ＭＭＡＰを用いて割り当てられる。ストリームが進行すると、消費されたメモリ空間は、ＭＡＤＶＩＳＥを用いて自動的に削除される。これにより、シンプルで論理的に進行し続ける非常にシンプルなカーソルが実現する。
従来のネットワークＩ／Ｏは、小バッファのリストを用い、これらを固定サイズメモリページへコピーする。或いは、アプリケーションが消費する固定サイズを用いる。このアプローチは、以下のような幾つかの欠点がある。
１．メッセージの大バーストを吸収できない
２．ゼロコピーではなく、レインテンシーが生じる
３．複数ページ又はリングバッファを用いる場合、メッセージフラグメンテーションを生じさせる
別アプローチは、論理上の巨大仮想メモリピース（１６テラバイト）を割り当て、ネットワークＩ／Ｏがこの仮想メモリに対して直接ストリーミングすることである。メモリは、ＭＭＡＰを用いて割り当てられる。ストリームが進行すると、消費されたメモリ空間は、ＭＡＤＶＩＳＥを用いて自動的に削除される。これにより、シンプルで論理的に進行し続ける非常にシンプルなカーソルが実現する。
＜アプリケーション同期及びフェイルオーバ＞
システムは、所与のアプリケーションのｎ個のインスタンスを実行する。１つのインスタンスは、プライマリであり、他のインスタンスは、バックアップである。プライマリとバックアップとの間で同一レコードを保持するため、バックアップアプリケーションは、プライマリアプリケーションと同じコードパスを用いる。但し、バックアップアプリケーションにおいて、１ステップが省略される。すなわち、バックアップは、メッセージを出力しない。バックアップアプリケーションによるメッセージ処理は、出力点までのフル実行パスを介して実行される。フルパスを実行し書き込みを短停止する利点は、プライマリアプリケーションとバックアップアプリケーションの状態ができる限り同一に保たれることである。これは、ｊａｖａ登録商標で記述されたシステムにおいて、特に有用である。バックアップアプリケーションがメッセージ処理を介して一部処理し、出力メッセージがパスのｊａｖａセグメントを出る前に停止する設計においては、メッセージストリームが完了し、プライマリと同期していても、正確に同じ状態ではない。
システムは、所与のアプリケーションのｎ個のインスタンスを実行する。１つのインスタンスは、プライマリであり、他のインスタンスは、バックアップである。プライマリとバックアップとの間で同一レコードを保持するため、バックアップアプリケーションは、プライマリアプリケーションと同じコードパスを用いる。但し、バックアップアプリケーションにおいて、１ステップが省略される。すなわち、バックアップは、メッセージを出力しない。バックアップアプリケーションによるメッセージ処理は、出力点までのフル実行パスを介して実行される。フルパスを実行し書き込みを短停止する利点は、プライマリアプリケーションとバックアップアプリケーションの状態ができる限り同一に保たれることである。これは、ｊａｖａ登録商標で記述されたシステムにおいて、特に有用である。バックアップアプリケーションがメッセージ処理を介して一部処理し、出力メッセージがパスのｊａｖａセグメントを出る前に停止する設計においては、メッセージストリームが完了し、プライマリと同期していても、正確に同じ状態ではない。
Ｊａｖａは、特定パスを最適化する際のｊｕｓｔ−ｉｎ−ｔｉｍｅコンパイル機能の一部として「ウォームアップ」期間を必要とする。ｊｕｓｔ−ｉｎ−ｔｉｍｅコンパイルにおいて、ｊａｖａは、無関係なコードパスを除去することによりアプリケーションを「優先付け」し、使用中のパスをより効率的に最適化する。例えば、パスが１０，０００回実行されると、高い優先権を得る。ｊａｖａステップを含む処理パスを実行するがｊａｖａ内で書き込みステップを実行しないバックアップアプリケーションの場合、「書き込み」コードは、アクティブにならない。バックアップがプライマリになる必要がある場合、例えば、プライマリがダウンしたとき、書き込みコードがアクティブではなければ（すなわち最適化されていなければ）、ｊａｖａランスルーにおけるコード実行速度を低下させることによりｊａｖａパフォーマンスに影響する。例えば、書き込みパスを１０，０００回繰り返すことによる「ウォームアップ」が必要である。これにより、ウォームアップ期間の時間のためにアプリケーション速度が低下する可能性がある。
別設計としては、メッセージ処理パスをｊａｖａセグメントの終端まで実行し、ｊａｖａがメッセージ出力を次ステップに対して書き込むことができるようにすると共に、次ステップ開始前にパスを停止することが挙げられる。これにより、フルｊａｖａパスが実行され、プライマリアプリケーションとバックアップアプリケーションは、共に同一状態を維持する。これらは、ｊａｖａと「ウォームアップ」によって共に最適化されるので、プライマリがバックアップへフェイルオーバするイベントにおいて、バックアップは、即座にプライマリがダウンした箇所をピックアップするため、性能は低下しない。
＜ストリームセグメントリピータノードを介したメッセージ再送信＞
通常システム動作において、全アプリケーションは、アクションを実施し又は外部イベントに対して応答すると、ジャーナルに対してメッセージを書き込む。これは、外部サードパーティからメッセージを受信し処理することを含む（例えば、ＦＩＸ注文入力メッセージ、市場データメッセージ）。
通常システム動作において、全アプリケーションは、アクションを実施し又は外部イベントに対して応答すると、ジャーナルに対してメッセージを書き込む。これは、外部サードパーティからメッセージを受信し処理することを含む（例えば、ＦＩＸ注文入力メッセージ、市場データメッセージ）。
アプリケーションは、全アプリケーションがジャーナルに対して書き込んだ全メッセージを読み込み保持するように設計されるが、ネットワーク層における送信問題の結果としてメッセージを消失する場合がある。アプリケーションがジャーナルメッセージを処理する際にギャップを発見すると、消失したメッセージを復元する手段が必要になる。-これは、困難な課題である。アプリケーションは、定期的に消失メッセージに対して再アクセスしなければならず、ジャーナルにこれを要求すると、各要求は、他のアプリケーションからの要求と競合する可能性があるからである。これにより、ジャーナルにおいて、アプリケーション待ちキューが生じ、待機中において、更に遅れが生じることになる。これは、更に多くのメッセージを復元しなければならないことを意味する。これは、復元アプリケーションの復帰時間を増加させ、チェーンリアクションがキュー待ちを増やして後続アプリケーションの復帰時間を増加させることにより、問題を更に悪化させる。
１つの解決手法は、複数ジャーナルによってアプリケーションに対して２以上の復帰ソースを与えることである。すなわち、負荷分散プロセスを増やしてより短いキューを増やすことである。但し、アプリケーションが新規起動し、及び／又は大量メッセージを消失した場合（例えば、アプリケーションが１日の遅くに起動し、処理済みの全メッセージに追いつかなければならない場合）、全消失メッセージを復元し処理するために長時間を要する。この場合、アプリケーションがメッセージを復元する際に用いるジャーナルは、アプリケーション復元完了まで他のアプリケーションが利用できないことになる。
システムは、アプリケーションが消失メッセージを復元することができる完全メッセージジャーナルのコピーを有するｎ個のジャーナルを有する。１つのジャーナルがあるアプリケーションによって占有された場合、他のアプリケーションは、その他の利用可能ジャーナルから消失メッセージを復元することができる。但し、ジャーナルリソースを長時間消費して他のアプリケーションの長いキューを生じさせるアプリケーションの影響を最小化するため、別解決手法として、全メッセージジャーナルをセグメントへ分割し、特定のセグメントを特定のジャーナルに対して割り当てる。このように、各ジャーナルセグメントは、復元アプリケーションに対して記録したメッセージセグメントを提供し、アプリケーションを移動させて、待機中の次アプリケーションがより速く順番を得ることができるようにする。切断したアプリケーションが依然としてメッセージギャップを有する場合、関連するストリームセグメントを有するジャーナルに対して接続し、別メッセージに対してアクセスする等することができる。これにより、アプリケーションがジャーナルキューにおいて、消費する時間制約を解消し、メッセージギャップをより速く充足させることができる。
＜ＴＬＬコントローラ＞
図９は、ＴＬＬコントローラ９０１のブロック図である。この実施形態において、ＴＬＬコントローラ９０１は、様々な技術及び／又はその他の関連データを介して、コンピュータとのやり取りを集約し、処理し、格納し、検索し、補助し、識別し、指示し、生成し、マッチングし、及び／又は促進する。
図９は、ＴＬＬコントローラ９０１のブロック図である。この実施形態において、ＴＬＬコントローラ９０１は、様々な技術及び／又はその他の関連データを介して、コンピュータとのやり取りを集約し、処理し、格納し、検索し、補助し、識別し、指示し、生成し、マッチングし、及び／又は促進する。
ユーザ９３３ａは、人及び／又は他のシステムであり、情報技術システム（例えば、コンピュータ）を操作して、情報処理を実施する。コンピュータは、情報を処理するプロセッサを用いる。プロセッサ９０３は、中央演算装置（ＣＰＵ）と呼ばれる場合もある。プロセッサの１形態は、マイクロプロセッサである。ＣＰＵは、通信回路を用いて、命令として動作するバイナリ符号化信号を送信し、様々な動作を実施する。これら命令は、動作命令及び／又はデータ命令であり、他の命令を含み及び／又は参照し、様々なプロセッサがアクセスして動作することができるメモリ領域９２９（例えば、レジスタ、キャッシュメモリ、ランダムアクセスメモリ等）に格納される。通信命令は、プログラムとして及び／又はデータコンポーネントとしてバッチで（例えば、バッチ命令で）格納され及び／又は送信され、所望の動作を実施する。これら格納されている命令コード（例えば、プログラム）は、ＣＰＵ回路部品やその他のマザーボード及び／又はシステムに組み込まれ、所望の動作を実施する。プログラムのタイプとしては、例えば、コンピュータオペレーティングシステムがあり、ＣＰＵがコンピュータ上でこれを実行する。オペレーティングシステムにより、ユーザは、コンピュータ情報技術とリソースにアクセスし動作させることができる。情報技術システムが使用するリソースとしては、以下が挙げられる：データがコンピュータに対して入力され又はコンピュータから出ていく入出力メカニズム；データを保存するメモリストレージ；情報を処理するプロセッサ。これら情報技術システムを用いてデータを収集し、その後に取得し、分析し、操作する。これら動作は、データベースプログラムによりなされる。これら情報技術システムは、ユーザが様々なシステムコンポーネントにアクセスして操作するインタフェースを提供する。
一実施形態において、ＴＬＬコントローラ９０１は、以下に限定されるわけではないが、以下のようなエンティティと接続し、及び／又は通信することができる：ユーザ入力デバイス９１１からの１以上のユーザ；周辺デバイス９１２；予備暗号プロセッサデバイス９２８；及び／又は通信ネットワーク９１３。例えば、ＴＬＬコントローラ９０１は、ユーザ９３３ａ、クライアント操作デバイス９３３ｂと接続し、及び／又は通信することができる。クライアント操作デバイス９３３ｂは、以下を含むが、これに限られない：パーソナルコンピュータ、サーバ、及び／又は様々なモバイルデバイス。モバイルデバイスは、以下を含むが、これに限られない：携帯電話、スマートフォン（例えば、ｉＰｈｏｎｅ（登録商標）、Ｂｌａｃｋｂｅｒｒｙ（登録商標）、ＡｎｄｒｏｉｄＯＳベース携帯電話等）、タブレットコンピュータ（例えば、Ａｐｐｌｅ ｉＰａｄ(登録商標)、ＨＰ Ｓｌａｔｅ、Ｍｏｔｏｒｏｌａ Ｘｏｏｍ等）、ｅＢｏｏｋリーダ（例えば、Ａｍａｚｏｎ Ｋｉｎｄｌｅ、Ｂａｒｎｅｓ ａｎｄ ＮｏｂｌｅのＮｏｏｋ ｅＲｅａｄｅｒ等）、ラップトップコンピュータ、ノートブックコンピュータ、ネットブック、ゲーム端末（例えば、ＸＢＯＸ Ｌｉｖｅ、Ｎｉｎｔｅｎｄｏ（登録商標）ＤＳ、Ｓｏｎｙ ＰｌａｙＳｔａｔｉｏｎ（登録商標）Ｐｏｒｔａｂｌｅ等）、携帯スキャナ等。
ネットワークは、一般に、グラフトポロジーにおけるクライアント、サーバ、及び中間ノードの相互接続と相互動作を備えるように構成される。本願における「サーバ」という用語は、包括的に、コンピュータ、その他のデバイス、プログラム、或いは、これらの組み合わせを指し、これらは、通信ネットワークを介したリモートユーザの要求を処理し、これに応答する。サーバは、要求側「クライアント」に情報を提供する。本願における「クライアント」という用語は、一般に、コンピュータ、プログラム、その他のデバイス、ユーザ、及び／又はこれらの組み合わせを指す。これらは、要求を処理及び作成し、通信ネットワークを介してサーバからの応答を取得し処理することができる。情報と要求を処理し、及び／又は送信元ユーザから宛先に対して情報を引き渡す、コンピュータ、その他のデバイス、プログラム、又はこれらの組み合わせは、「ノード」と呼ぶ。ネットワークは、一般に、送信元から宛先に対して情報を伝搬する。送信元から宛先に対して情報を引き渡すタスクを実施するノードは、「ルータ」と呼ばれる。ネットワークの形態としては、例えば、ローカルエリアネットワーク（ＬＡＮ）、Ｐｉｃｏネットワーク、広域ネットワーク（ＷＡＮ）、無線ネットワーク（ＷＡＮ）等がある。例えば、インターネットは、一般に、複数ネットワークの相互接続として受け入れられている。これによりリモートクライアントとサーバは、互いにアクセスし相互動作することができる。
ＴＬＬコントローラ９０１は、コンピュータシステムに基づく。このコンピュータシステムは、例えば、メモリ９２９に接続されたコンピュータシステム９０２のようなコンポーネントを備えるが、これに限らない。
＜コンピュータシステム＞
コンピュータシステム９０２は、クロック９３０、中央演算装置（ＣＰＵ及び／又はプロセッサ（これら用語は、本明細書において、明示しない限り相互交換可能である））９０３、メモリ９２９（例えば、読取専用メモリ（ＲＯＭ）９０６、ランダムアクセスメモリ（ＲＡＭ）９０５等）、及び／又はインタフェースバス９０６を備える。これらは全て、必ずしも必要ではないが、多くの場合、相互接続され及び／又はシステムバス９０４を介して通信を行う。システムバス９０４は、１以上のマザーボード９０２上に設けられている。マザーボード９０２は、導電及び／又は伝搬回路経路を有する。この回路経路を通じて、命令（例えば、バイナリ符号化信号）が伝搬し、通信、動作、記憶等を実現する。コンピュータシステムは、電源９８６に接続することができる。電源は、内部のものであってもよい。オプションとして、暗号プロセッサ９２６及び／又はトランシーバ（例えば、ＩＣ）９６４をシステムバスに接続してもよい。他の実施形態において、暗号プロセッサ及び／又はトランシーバは、内部及び／又は外部周辺デバイス９１２としてインタフェースバスＩ／Ｏを介して接続することができる。トランシーバは、アンテナ９６５に接続され、これにより無線通信と様々な通信及び／又はセンサプロトコルの受信を可能にする。例えば、アンテナは、以下に接続することができる：Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ ＷｉＬｉｎｋ ＷＬ１２８３ トランシーバチップ（例えば、８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ（登録商標）３．０、ＦＭ、ＧＰＳ（これによりＴＬＬコントローラは、位置を判定できる）を提供する）；Ｂｒｏａｄｃｏｍ ＢＣＭ４３２９ＦＫＵＢＧ トランシーバチップ（例えば、８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ２．１＋ＥＤＲ、ＦＭ等を提供する）、ＢＣＭ２８１５０（ＨＳＰＡ＋）、及びＢＣＭ２０６６（Ｂｌｕｅｔｏｏｔｈ４．０、ＧＰＳ等）；Ｂｒｏａｄｃｏｍ ＢＣＭ４６５０ＩＵ８８レシーバチップ（例えば、ＧＰＳ）；Ｉｎｆｉｎｅｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｘ−Ｇｏｌｄ６１８−ＰＭＢ９８００（例えば、２Ｇ／３Ｇ ＨＳＤＰＡ／ＨＳＵＰＡ通信を提供する）；Ｉｎｔｅｌ ＸＭＭ６１６０（ＬＴＥ＆ＤＣ−ＨＳＰＡ）、Ｑｕａｌｃｏｍ ＣＤＭＡ（２，０００）、Ｍｏｂｉｌｅ Ｄａｔａ／Ｓｔａｔｉｏｎ Ｍｏｄｅｍ，Ｓｎａｐｄｒａｇｏ等。システムクロックは、水晶発振器を有し、コンピュータシステムの回路経路を介してベース信号を生成する。クロックは、システムバス及び様々なクロック増幅器に接続される。クロック増幅器は、コンピュータシステムに相互接続された他のコンポーネントのベース動作周波数を増減させる。クロックとコンピュータシステム内の各コンポーネントは、システム全体にわたって情報を格納する信号を駆動する。コンピュータシステム全体にわたって情報を格納した命令を送受信することは、通信と呼ばれる。これら通信命令は、更に送受信され、本コンピュータシステムから通信ネットワーク、入力デバイス、他のコンピュータシステム、周辺デバイス等に対する応答を生じさせる。他の実施形態において、上記各コンポーネントは、互いに直接接続し、ＣＰＵに接続し、及び／又は多様なコンピュータシステムが採用する様々な変形物内に構成できることは明らかである。
コンピュータシステム９０２は、クロック９３０、中央演算装置（ＣＰＵ及び／又はプロセッサ（これら用語は、本明細書において、明示しない限り相互交換可能である））９０３、メモリ９２９（例えば、読取専用メモリ（ＲＯＭ）９０６、ランダムアクセスメモリ（ＲＡＭ）９０５等）、及び／又はインタフェースバス９０６を備える。これらは全て、必ずしも必要ではないが、多くの場合、相互接続され及び／又はシステムバス９０４を介して通信を行う。システムバス９０４は、１以上のマザーボード９０２上に設けられている。マザーボード９０２は、導電及び／又は伝搬回路経路を有する。この回路経路を通じて、命令（例えば、バイナリ符号化信号）が伝搬し、通信、動作、記憶等を実現する。コンピュータシステムは、電源９８６に接続することができる。電源は、内部のものであってもよい。オプションとして、暗号プロセッサ９２６及び／又はトランシーバ（例えば、ＩＣ）９６４をシステムバスに接続してもよい。他の実施形態において、暗号プロセッサ及び／又はトランシーバは、内部及び／又は外部周辺デバイス９１２としてインタフェースバスＩ／Ｏを介して接続することができる。トランシーバは、アンテナ９６５に接続され、これにより無線通信と様々な通信及び／又はセンサプロトコルの受信を可能にする。例えば、アンテナは、以下に接続することができる：Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ ＷｉＬｉｎｋ ＷＬ１２８３ トランシーバチップ（例えば、８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ（登録商標）３．０、ＦＭ、ＧＰＳ（これによりＴＬＬコントローラは、位置を判定できる）を提供する）；Ｂｒｏａｄｃｏｍ ＢＣＭ４３２９ＦＫＵＢＧ トランシーバチップ（例えば、８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ２．１＋ＥＤＲ、ＦＭ等を提供する）、ＢＣＭ２８１５０（ＨＳＰＡ＋）、及びＢＣＭ２０６６（Ｂｌｕｅｔｏｏｔｈ４．０、ＧＰＳ等）；Ｂｒｏａｄｃｏｍ ＢＣＭ４６５０ＩＵ８８レシーバチップ（例えば、ＧＰＳ）；Ｉｎｆｉｎｅｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｘ−Ｇｏｌｄ６１８−ＰＭＢ９８００（例えば、２Ｇ／３Ｇ ＨＳＤＰＡ／ＨＳＵＰＡ通信を提供する）；Ｉｎｔｅｌ ＸＭＭ６１６０（ＬＴＥ＆ＤＣ−ＨＳＰＡ）、Ｑｕａｌｃｏｍ ＣＤＭＡ（２，０００）、Ｍｏｂｉｌｅ Ｄａｔａ／Ｓｔａｔｉｏｎ Ｍｏｄｅｍ，Ｓｎａｐｄｒａｇｏ等。システムクロックは、水晶発振器を有し、コンピュータシステムの回路経路を介してベース信号を生成する。クロックは、システムバス及び様々なクロック増幅器に接続される。クロック増幅器は、コンピュータシステムに相互接続された他のコンポーネントのベース動作周波数を増減させる。クロックとコンピュータシステム内の各コンポーネントは、システム全体にわたって情報を格納する信号を駆動する。コンピュータシステム全体にわたって情報を格納した命令を送受信することは、通信と呼ばれる。これら通信命令は、更に送受信され、本コンピュータシステムから通信ネットワーク、入力デバイス、他のコンピュータシステム、周辺デバイス等に対する応答を生じさせる。他の実施形態において、上記各コンポーネントは、互いに直接接続し、ＣＰＵに接続し、及び／又は多様なコンピュータシステムが採用する様々な変形物内に構成できることは明らかである。
ＣＰＵは、ユーザ及び／又はシステムが生成した要求を実行するプログラムコンポーネントを実行するのに適した少なくとも１つの高速データプロセッサを備える。プロセッサ自身は、様々な専用処理ユニットを備える場合もある。例えば、浮動点演算ユニット、整数演算ユニット、統合システム（バス）コントローラ、論理演算ユニット、メモリ管理制御ユニット等を含むが、これらに限らない。また、グラフィック処理ユニット、デジタル信号処理ユニット等の専用サブユニットを含む場合もある。更に、プロセッサは、内部高速アクセスアドレスメモリを備える場合もあり、メモリ９２９のマッピングやアドレシングをプロセッサ自身が実施することができる。内部メモリは、以下に限定されるわけではないが、高速レジスタ、様々なレベルのキャッシュメモリ（レベル１、２、３等）、ＲＡＭ等を含む。プロセッサは、メモリアドレス空間を介してこのメモリにアクセスする。メモリアドレス空間は、命令アドレスを介してアクセスすることができる。命令アドレスは、プロセッサが構築しデコードするものであり、これにより、回路パスにアクセスしてメモリ状態／値を有する特定メモリアドレス空間にアクセスすることができる。ＣＰＵは、例えば、以下のようなマイクロプロセッサでもよい：ＡＭＤ Ａｔｈｌｏｎ、Ｄｕｒｏｎ、及び／又はＯｐｔｅｒｏｎ；従前のＡＲＭ（例えば、ＡＲＭ６／９／１１）、ｅｍｂｅｄｄｅｄ（Ｃｏｒｔｅｘ−Ｍ／Ｒ）、ａｐｐｌｉｃａｔｉｏｎ（Ｃｏｒｔｅｘ−Ａ）、ｅｍｂｅｄｄｅｄ及びｓｅｃｕｒｅプロセッサ；ＩＢＭ及び／又はＭｏｔｏｒｏｌａ ＤｒａｇｏｎＢａｌｌ及びＰｏｗｅｒＰＣ；ＩＢＭ及びＳｏｎｙ Ｃｅｌｌプロセッサ；Ｉｎｔｅｌ Ａｔｏｍ、Ｃｅｌｅｒｏｎ（Ｍｏｂｉｌｅ）、Ｃｏｒｅ（２／Ｄｕｏ／ｉ３／ｉ５／ｉ６）、Ｉｔａｎｉｕｍ、Ｐｅｎｔｉｕｍ、Ｘｅｏｎ、及び／又はＸＳｃａｌｅ；等。ＣＰＵは、命令を通過させる導体及び／又は伝搬経路（例えば、（プリント）電子及び／又は光回路）を介してメモリと通信し、格納されている命令（すなわち、プログラムコード）を実行する。この命令引き渡しにより、ＴＬＬコントローラ内及び各インタフェースを介した通信を実施する。処理要件が多大な速度及び／又は性能を必要とする場合、分散プロセッサ（例えば、Ｄｉｓｔｒｉｂｕｔｅｄ ＴＬＬ）、メインフレーム、マルチコア、パラレル、及び／又はスーパーコンピュータアーキテクチャを同様に用いることができる。これに代えて、配置要件が可搬性を必要とする場合、小型モバイルデバイス（例えば、スマートフォン、携帯個人端末（ＰＤＡ）等）を採用することができる。
実装によっては、ＴＬＬの機能は、マイクロコントローラを実装することによって実現できる。マイクロコントローラは、例えば、ＣＡＳＴ Ｒ８０５１ＸＣ２マイクロコントローラ、Ｉｎｔｅｌ ＭＣＳ５１（すなわち８０５１マイクロコントローラ）等である。ＴＬＬの機能を実装するため、組込コンポーネントを用いることもできる。例えば、特定用途集積回路（ＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ（ＦＰＧＡ）、及び／又は同様の組込技術である。例えば、ＴＬＬのコンポーネントコレクション（分散配置されているものであってもよく、以外であってもよい）及び／又は機能は、マイクロプロセッサ及び／、又は組込コンポーネントを用いて実装することができる。例えば、ＡＳＩＣ、コプロセッサ、ＤＳＰ、ＦＰＧＡ等である。これに代えて、幾つかの実施例では、ＴＬＬの機能は、多様な機能や信号処理を実現するように構成された組込コンポーネントにより実装することができる。
実装によっては、組込コンポーネントは、ソフトウェア、ハードウェア、及び／又はハードウェア／ソフトウェアの組み合わせを含むことができる。例えば、ＴＬＬ機能は、ＦＰＧＡを実装することにより実現できる。ＦＰＧＡは、「論理ブロック」というプログラム可能論理部品とプログラム可能相互接続を含む半導体デバイスである。ＦＰＧＡの例は、Ｘｉｌｉｎｘが製造する高性能ＦＰＧＡ Ｖｉｒｔｅｘシリーズ及び／又はＳｐａｒｔａｎシリーズである。論理ブロックと相互接続は、ＦＰＧＡが製造された後、顧客や設計者によってプログラムすることができる。これにより、ＴＬＬ機能を実装する。プログラム可能相互接続の階層により、論理ブロックは、ＴＬＬシステム設計者／管理者が必要であれば相互接続することができる。これは、１チッププログラム可能ｂｒｅａｄｂｏａｒｄに似ている。ＦＰＧＡの論理ブロックをプログラムして、ＡＮＤ、ＸＯＲ等の基本論理ゲートの動作、又はデコーダや簡易数式等のより複雑な演算子の組み合わせを実施することができる。多くのＦＰＧＡにおいて、論理ブロックもメモリを備える。このメモリは、例えば、回路フリップフロップ又はより複雑なメモリブロックである。状況によっては、ＴＬＬを通常のＦＰＧＡ上に開発し、ＡＣＩＣにより近い固定バージョンに移行することもできる。代替又は協調実装は、ＴＬＬコントローラ機能をＦＰＧＡに代えて又はＦＰＧＡに加えて最終ＡＳＩＣに移行することができる。実装によっては、上記組込コンポーネントの全て及びマイクロプロセッサは、ＴＬＬの「ＣＰＵ」及び／又は「プロセッサ」とみなすことができる。
＜電源＞
電源９８６は、小型電子回路基板デバイスに電源を供給する如何なる標準的な形式を有していてもよく、例えば、アルカリ、水素化リチウム、リチウムイオン、リチウムポリマ、ニッケルカドミウム、太陽電池等の電池であってもよい。他のタイプのＡＣ又はＤＣ電源も同様に使用することができる。一実施形態において、太陽電池の場合、太陽電池が光エネルギを捕捉するための開口をケースに設けてもよい。パワーセル９８６は、相互接続されたＴＬＬコンポーネントの少なくとも１つに接続され、これによって、これらに相互接続された全ての部品に電流を供給する。一例において、電源９８６は、システムバスコンポーネント９０４に接続される。代替実施形態において、Ｉ／Ｏインタフェース９０８をまたがる接続を介して、外部電源９８６を提供することもできる。例えば、ＵＳＢ及び／又はＩＥＥＥ１３９４接続は、接続を介してデータ及び電力の両方を伝送し、したがって、適切な電源となる。
電源９８６は、小型電子回路基板デバイスに電源を供給する如何なる標準的な形式を有していてもよく、例えば、アルカリ、水素化リチウム、リチウムイオン、リチウムポリマ、ニッケルカドミウム、太陽電池等の電池であってもよい。他のタイプのＡＣ又はＤＣ電源も同様に使用することができる。一実施形態において、太陽電池の場合、太陽電池が光エネルギを捕捉するための開口をケースに設けてもよい。パワーセル９８６は、相互接続されたＴＬＬコンポーネントの少なくとも１つに接続され、これによって、これらに相互接続された全ての部品に電流を供給する。一例において、電源９８６は、システムバスコンポーネント９０４に接続される。代替実施形態において、Ｉ／Ｏインタフェース９０８をまたがる接続を介して、外部電源９８６を提供することもできる。例えば、ＵＳＢ及び／又はＩＥＥＥ１３９４接続は、接続を介してデータ及び電力の両方を伝送し、したがって、適切な電源となる。
＜インタフェースアダプタ＞
インタフェースバス９０６は、複数のインタフェースアダプタに対して、受信し、接続し、及び／又は通信する。必須ではないが、アダプタカードの形態をとることができる。例えば、以下を含むが、これらに限らない：入出力インタフェース（Ｉ／Ｏ）９０８、ストレージインタフェース９０９、ネットワークインタフェース９１０等。暗号プロセッサインタフェース９２６も同様に、インタフェースバスに接続することができる。インタフェースバスは、インタフェースアダプタ同士の接続のために提供してもよく、コンピュータステムの他のコンポーネントのために提供してもよい。インタフェースアダプタは、適合するインタフェースバスのために調整することができる。インタフェースアダプタは、拡張及び／又はスロットアーキテクチャを介してインタフェースバスに接続する。使用できる様々な拡張及び／又はスロットアーキテクチャは、例えば、以下に限定されるわけではないが、アクセラレーテッドグラフィックポート（Accelerated Graphics Port：ＡＧＰ）、カードバス、ＥｘｐｒｅｓｓＣａｒｄ、（拡張：Extended）業界標準アーキテクチャ（：（Ｅ）ＩＳＡ）、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）、ＮｕＢｕｓ、周辺コンポーネントインターコネクト（拡張）（（Extended）：ＰＣＩ（Ｘ））、ＰＣＩＥｘｐｒｅｓｓ、ＰＣＭＣＩＡ（Personal Computer Memory Card International Association）、Ｔｈｕｎｄｅｒｂｏｌｔ等を含む。様々な拡張及び／又はスロットアーキテクチャを採用することができる。例えば、以下を含むがこれに限らない：Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）、Ｃａｒｄ Ｂｕｓ、ＥｘｐｒｅｓｓＣａｒｄ、（Ｅｘｔｅｎｄｅｄ）Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（（Ｅ）ＩＳＡ）、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）、ＮｕＢｕｓ、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（Ｅｘｔｅｎｄｅｄ）（ＰＣＩ（Ｘ））、ＰＣＩ Ｅｘｐｒｅｓｓ、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ（ＰＣＭＣＩＡ）、Ｔｈｕｎｄｅｒｂｏｌｔ等。
インタフェースバス９０６は、複数のインタフェースアダプタに対して、受信し、接続し、及び／又は通信する。必須ではないが、アダプタカードの形態をとることができる。例えば、以下を含むが、これらに限らない：入出力インタフェース（Ｉ／Ｏ）９０８、ストレージインタフェース９０９、ネットワークインタフェース９１０等。暗号プロセッサインタフェース９２６も同様に、インタフェースバスに接続することができる。インタフェースバスは、インタフェースアダプタ同士の接続のために提供してもよく、コンピュータステムの他のコンポーネントのために提供してもよい。インタフェースアダプタは、適合するインタフェースバスのために調整することができる。インタフェースアダプタは、拡張及び／又はスロットアーキテクチャを介してインタフェースバスに接続する。使用できる様々な拡張及び／又はスロットアーキテクチャは、例えば、以下に限定されるわけではないが、アクセラレーテッドグラフィックポート（Accelerated Graphics Port：ＡＧＰ）、カードバス、ＥｘｐｒｅｓｓＣａｒｄ、（拡張：Extended）業界標準アーキテクチャ（：（Ｅ）ＩＳＡ）、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）、ＮｕＢｕｓ、周辺コンポーネントインターコネクト（拡張）（（Extended）：ＰＣＩ（Ｘ））、ＰＣＩＥｘｐｒｅｓｓ、ＰＣＭＣＩＡ（Personal Computer Memory Card International Association）、Ｔｈｕｎｄｅｒｂｏｌｔ等を含む。様々な拡張及び／又はスロットアーキテクチャを採用することができる。例えば、以下を含むがこれに限らない：Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧＰ）、Ｃａｒｄ Ｂｕｓ、ＥｘｐｒｅｓｓＣａｒｄ、（Ｅｘｔｅｎｄｅｄ）Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（（Ｅ）ＩＳＡ）、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）、ＮｕＢｕｓ、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（Ｅｘｔｅｎｄｅｄ）（ＰＣＩ（Ｘ））、ＰＣＩ Ｅｘｐｒｅｓｓ、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ（ＰＣＭＣＩＡ）、Ｔｈｕｎｄｅｒｂｏｌｔ等。
ストレージインタフェース９０９は、複数のストレージデバイスに対して、受信し、通信し、及び／又は接続する。ストレージデバイスは、例えば、以下のようなものであるが、これに限らない：ストレージデバイス９１４、リムーバブルディスクデバイス等。ストレージインタフェースは、通信プロトコルを採用することができる。通信プロトコルは、例えば、以下のものを含むが、これに限らない：（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ（Ｐａｃｋｅｔ Ｉｎｔｅｒｆａｃｅ）（（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）ＡＴＡ（ＰＩ））、（Ｅｎｈａｎｃｅｄ）Ｉｎｔｅｇｒａｔｅｄ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ（（Ｅ）ＩＤＥ）、Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）１３９４、Ｅｔｈｅｒｎｅｔ、ファイバチャネル、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）、Ｔｈｕｎｄｅｒｂｏｌｔ、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）等。
ネットワークインタフェース９１０は、通信ネットワーク９１３に対して、受信し、通信し、及び／又は接続する。通信ネットワーク９１３を介して、ユーザ９３３ａは、リモートクライアント９３３ｂ（例えば、ウェブブラウザを備えるコンピュータ）経由でＴＬＬコントローラにアクセスすることができる。ネットワークインタフェースは、通信プロトコルを採用することができる。通信プロトコルは、例えば、以下のものがあるが、これに限らない：直接接続、Ｅｔｈｅｒｎｅｔ（ｔｈｉｃｋ、ｔｈｉｎ、ｔｗｉｓｔｅｄ ｐａｉｒ １０／１００／１，０００Ｂａｓｅ Ｔ等）、トークンリング、ＩＥＥＥ８０２．１１ａ−ｘ等の無線接続等。処理要件が多大な速度及び／又は性能を必要とする場合、分散ネットワークコントローラ（例えば、分散ＴＬＬ）アーキテクチャを同様に採用して、ＴＬＬコントローラが必要とする通信帯域幅をプールし、負荷分散し、及び／又は増加させることができる。通信ネットワークは、以下の何れか又は組み合わせを用いることができる：直接相互接続；インターネット；ローカルエリアネットワーク（ＬＡＮ）；メトロポリタンエリアネットワーク（ＭＡＮ）；Ｏｐｅｒａｔｉｎｇ Ｍｉｓｓｉｏｎｓ ａｓ Ｎｏｄｅｓ ｏｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ（ＯＭＮＩ）；セキュアカスタム接続；Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）；無線ネットワーク（例えば、Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＷＡＰ）、Ｉ−ｍｏｄｅ等のプロトコルを採用したものが挙げられるが、これらに限らない）；等。ネットワークインタフェースは、入出力インタフェースの特殊形態とみなすことができる。更に複数のネットワークインタフェース９１０を用いて、様々な通信ネットワークタイプ９１３に接続することができる。例えば、複数のネットワークインタフェースを用いて、ブロードキャスト、マルチキャスト、及び／又はユニキャストネットワーク上で通信することができる。
入出力インタフェース（Ｉ／Ｏ）９０８は、ユーザ入力デバイス９１１、周辺デバイス９１２、暗号プロセッサデバイス９２８等に対して、受信し、通信し、及び／又は接続する。Ｉ／Ｏは、以下のような通信プロトコルを用いることができるが、これに限らない：オーディオ：アナログ、デジタル、モノラル、ＲＣＡ、ステレオ等；データ：Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｂｕｓ（ＡＤＢ）、Ｂｌｕｅｔｏｏｔｈ、ＩＥＥＥ１３９４ａ〜ｂ、シリアル、ＵＳＢ；赤外線；ジョイスティック；キーボード；ｍｉｄｉ；光；ＰＣ ＡＴ；ＰＳ／２；パラレル；無線；ビデオインタフェース：Ａｐｐｌｅ Ｄｅｓｋｔｏｐ Ｃｏｎｎｅｃｔｏｒ（ＡＤＣ）、ＢＮＣ、同軸、コンポーネント、コンポジット、デジタル、ＤｉｓｐｌａｙＰｏｒｔ、Ｄｉｇｉｔａｌ Ｖｉｓｕａｌ Ｉｎｔｅｒｆａｃｅ（ＤＶＩ）、ｈｉｇｈ−ｄｅｆｉｎｉｔｉｏｎ ｍｕｌｔｉｍｅｄｉａ ｉｎｔｅｒｆａｃｅ（ＨＤＭＩ(登録商標)）、ＲＣＡ、ＲＦ ａｎｔｅｎｎａ、Ｓ−Ｖｉｄｅｏ、ＶＧＡ等；無線トランシーバ：８０２．１１ａ／ｂ／ｇ／ｎ／ｘ；Ｂｌｕｅｔｏｏｔｈ；携帯（例えば、ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ（ＣＤＭＡ）、ｈｉｇｈ ｓｐｅｅｄ ｐａｃｋｅｔ ａｃｃｅｓｓ（ＨＳＰＡ（＋））、ｈｉｇｈ−ｓｐｅｅｄ ｄｏｗｎｌｉｎｋ ｐａｃｋｅｔ ａｃｃｅｓｓ（ＨＳＤＰＡ）、ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ(登録商標)）、ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、ＷｉＭａｘ等）；等。出力デバイスは、例えば、ビデオディスプレイである。ビデオディスプレイは、以下の形態をとることができる：Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ（ＣＲＴ）、Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ（ＬＣＤ）、Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ（ＬＥＤ）、Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ（ＯＬＥＤ）、プラズマ等。ビデオディスプレイは、ビデオインタフェースから信号を受け取るインタフェース（例えば、ＶＧＡ、ＤＶＩ回路及びケーブル）を備える。ビデオインタフェースは、コンピュータシステムが生成した情報を複合し、複合した情報に基づきビデオメモリフレーム内でビデオ信号を生成する。他の出力デバイスは、例えば、テレビセットである。テレビセットは、ビデオインタフェースから信号を受け取る。ビデオインタフェースは、ビデオディスプレイインタフェース（例えば、ＲＣＡコンポジットビデオケーブルを接続するＲＣＡコンポジットビデオコネクタ；ＤＶＩディスプレイケーブルを接続するＤＶＩコネクタ、ＨＤＭＩ等）を接続するビデオ接続インタフェースを介して複合ビデオ情報を提供する。
ユーザ入力デバイス９１１は、周辺デバイス９１２（下記参照）のタイプである場合もあり、以下を含む：カードリーダ、ドングル、指紋リーダ、グローブ、グラフィックタブレット、ジョイスティック、キーボード、マイクロフォン、マウス、リモコン、網膜リーダ、タッチスクリーン（容量型、抵抗型等）、トラックボール、センサ（例えば、加速度計、環境光、ＧＰＳ、ジャイロスコープ、近接センサ等）、スタイラス等。
周辺デバイス９１２は、Ｉ／Ｏ及び／又は、ネットワークインタフェース、ストレージインタフェース、インタフェースバス直接、システムバス、ＣＰＵ等のその他のデバイスと接続し、及び／又は通信することができる。周辺デバイスは、外部デバイス、内部デバイス、及び／又はＴＬＬコントローラの一部である。周辺デバイスは、以下を含む：アンテナ、オーディオデバイス（例えば、ｌｉｎｅ−ｉｎ、ｌｉｎｅ−ｏｕｔ、マイクロフォン入力、スピーカ等）、カメラ（例えば、静止カメラ、ビデオカメラ、ｗｅｂｃａｍ等）、ドングル（例えば、デジタル署名で安全な通信を保証するコピー保護したもの等）、外部プロセッサ（例えば、暗号デバイス９２８等の追加機能のためのもの）、力フィードバックデバイス（例えば、振動モータ）、近接場通信（ＮＦＣ）デバイス、ネットワークインタフェース、プリンタ、無線ＩＤ（ＲＦＩＤ）、スキャナ、ストレージデバイス、トランシーバ（例えば、携帯、ＧＰＳ等）、ビデオデバイス（例えば、ゴーグル、モニタ等）、ビデオソース、ｖｉｓｏｒｓ等。周辺デバイスは、入力デバイスタイプを含む（例えば、マイクロフォン、カメラ等）。
ユーザ入力デバイスと周辺デバイスを採用してもよいが、ＴＬＬコントローラは、組込デバイス、専用デバイス、及び／又はモニタなし（すなわちヘッドなし）デバイスとして実装することもできる。この場合アクセスは、ネットワークインタフェース接続を介してなされる。
マイクロコントローラ、プロセッサ９２６、インタフェース９２６、及び／又はデバイス９２８等の暗号ユニットをＴＬＬに取り付け、及び／又はＴＬＬと通信することができる。Ｍｏｔｏｒｏｌａ製のＭＣ６８ＨＣ１６マイクロコントローラを暗号ユニット内で用いることができる。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚ設定で１６ビット積和演算命令を利用し、５１２ビットＲＳＡプライベートキー動作を１秒以下で実施する。暗号ユニットは、通信エージェントからの通信認証をサポートし、匿名通信も許可する。暗号ユニットは、ＣＰＵの一部として構成することができる。同等のマイクロコントローラ及び／又はプロセッサを用いることもできる。その他の商用利用可能な専用暗号プロセッサとして以下が含まれる：Ｂｒｏａｄｃｏｍ ＣｒｙｐｔｏＮｅｔＸその他のセキュリティプロセッサ；ｎＣｉｐｈｅｒ ｎＳｈｉｅｌｄ（例えば、Ｓｏｌｏ、 Ｃｏｎｎｅｃｔ等）、ＳａｆｅＮｅｔ Ｌｕｎａ ＰＣＩ（例えば、６１００）シリーズ；Ｓｅｍａｐｈｏｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ４０ＭＨｚ Ｒｏａｄｒｕｎｎｅｒ１８４；ｓＭＩＰ（例えば、２０８９５６）；Ｓｕｎ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａｃｃｅｌｅｒａｔｏｒ（例えば、Ａｃｃｅｌｅｒａｔｏｒ６０００ ＰＣＩｅボード、Ａｃｃｅｌｅｒａｔｏｒ５００ Ｄａｕｇｈｔｅｒｃａｒｄ）；５００＋ＭＢ／ｓの暗号命令を実施できるＶｉａ Ｎａｎｏ Ｐｒｏｃｅｓｓｏｒ（例えば、Ｌ２１００、Ｌ２２００、Ｕ２４００）ライン；ＶＬＳＩ Ｔｅｃｈｎｏｌｏｇｙ ３３ＭＨｚ ６８６８；等。
＜メモリ＞
一般に、プロセッサがストレージに影響を及ぼし、及び／又は情報を取得できるようにするデバイスは、メモリ９２９とみなすことができる。但し、メモリは、代替可能な技術及びリソースであり、よって任意個数のメモリを代わりに又は連携して用いることができる。ＴＬＬコントローラ及び／又はコンピュータシステムは、様々な形態のメモリ９２９を採用できることは明らかである。例えば、コンピュータシステムは、オンチップＣＰＵメモリ、ＲＡＭ、ＲＯＭ、その他のストレージデバイスが紙パンチテープ又は紙パンチカードによって提供されるように構成することができる。但し、そのような実施形態は、動作レートが非常に遅い。一実施例において、メモリ９２９は、ＲＯＭ９０６、ＲＡＭ９０５、ストレージデバイス９１４を含む。ストレージデバイス９１４は、任意個数のコンピュータストレージデバイス／システムを採用することができる。ストレージデバイスは、以下を含む：ドラム；（固定及び／又はリムーバブル）磁気ディスクドライブ；光磁気ドライブ；光ドライブ（すなわちＢｌｕｅｒａｙ、ＣＤ ＲＯＭ／ＲＡＭ／ＲｅｃｏＴＬＬｂｌｅ（登録商標）／ＲｅＷｒｉｔａｂｌｅ（ＲＷ）、ＤＶＤ Ｒ／ＲＷ、ＨＤ ＤＶＤ Ｒ／ＲＷ等）；デバイスアレイ（例えば、ＲＡＩＤ）；固体メモリデバイス（ＩＳＢメモリ、ｓｏｌｉｄ ｓｔａｔｅドライブ（ＳＳＤ）等）；その他のプロセッサ読取可能記憶媒体；等。したがって、コンピュータシステムは、一般に、メモリを利用する。
一般に、プロセッサがストレージに影響を及ぼし、及び／又は情報を取得できるようにするデバイスは、メモリ９２９とみなすことができる。但し、メモリは、代替可能な技術及びリソースであり、よって任意個数のメモリを代わりに又は連携して用いることができる。ＴＬＬコントローラ及び／又はコンピュータシステムは、様々な形態のメモリ９２９を採用できることは明らかである。例えば、コンピュータシステムは、オンチップＣＰＵメモリ、ＲＡＭ、ＲＯＭ、その他のストレージデバイスが紙パンチテープ又は紙パンチカードによって提供されるように構成することができる。但し、そのような実施形態は、動作レートが非常に遅い。一実施例において、メモリ９２９は、ＲＯＭ９０６、ＲＡＭ９０５、ストレージデバイス９１４を含む。ストレージデバイス９１４は、任意個数のコンピュータストレージデバイス／システムを採用することができる。ストレージデバイスは、以下を含む：ドラム；（固定及び／又はリムーバブル）磁気ディスクドライブ；光磁気ドライブ；光ドライブ（すなわちＢｌｕｅｒａｙ、ＣＤ ＲＯＭ／ＲＡＭ／ＲｅｃｏＴＬＬｂｌｅ（登録商標）／ＲｅＷｒｉｔａｂｌｅ（ＲＷ）、ＤＶＤ Ｒ／ＲＷ、ＨＤ ＤＶＤ Ｒ／ＲＷ等）；デバイスアレイ（例えば、ＲＡＩＤ）；固体メモリデバイス（ＩＳＢメモリ、ｓｏｌｉｄ ｓｔａｔｅドライブ（ＳＳＤ）等）；その他のプロセッサ読取可能記憶媒体；等。したがって、コンピュータシステムは、一般に、メモリを利用する。
＜コンポーネントコレクション＞
メモリ９２９は、プログラム及び／又はデータベースコンポーネント及び／又はデータのコレクションを含む。例えば、以下を含むがこれに限らない：ＯＳコンポーネント９１５（オペレーティングシステム）；情報サーバコンポーネント９１６（情報サーバ）；ユーザインタフェースコンポーネント９１６（ユーザインタフェース）；ウェブブラウザコンポーネント９１８（ウェブブラウザ）；データベース９１９；メールサーバコンポーネント９２１；メールクライアントコンポーネント９２２；暗号サーバコンポーネント９２０（暗号サーバ）；ＴＬＬコンポーネント９３５；等（すなわちまとめてコンポーネントコレクション）。これらコンポーネントは、ストレージデバイスに格納し、ストレージデバイスからアクセスし、及び／又はインタフェースバスを介してアクセスできるストレージデバイスからアクセスすることができる。上記コンポーネントコレクションのようなプログラムコンポーネントは、ローカルストレージデバイス９１４に格納することができるが、メモリに読み出し、及び／又は格納することができる。メモリは、例えば、以下を含む：周辺デバイス、ＲＡＭ、通信ネットワークを介したリモートストレージ、ＲＯＭ、様々なメモリ等。
メモリ９２９は、プログラム及び／又はデータベースコンポーネント及び／又はデータのコレクションを含む。例えば、以下を含むがこれに限らない：ＯＳコンポーネント９１５（オペレーティングシステム）；情報サーバコンポーネント９１６（情報サーバ）；ユーザインタフェースコンポーネント９１６（ユーザインタフェース）；ウェブブラウザコンポーネント９１８（ウェブブラウザ）；データベース９１９；メールサーバコンポーネント９２１；メールクライアントコンポーネント９２２；暗号サーバコンポーネント９２０（暗号サーバ）；ＴＬＬコンポーネント９３５；等（すなわちまとめてコンポーネントコレクション）。これらコンポーネントは、ストレージデバイスに格納し、ストレージデバイスからアクセスし、及び／又はインタフェースバスを介してアクセスできるストレージデバイスからアクセスすることができる。上記コンポーネントコレクションのようなプログラムコンポーネントは、ローカルストレージデバイス９１４に格納することができるが、メモリに読み出し、及び／又は格納することができる。メモリは、例えば、以下を含む：周辺デバイス、ＲＡＭ、通信ネットワークを介したリモートストレージ、ＲＯＭ、様々なメモリ等。
＜オペレーティングシステム＞
ＯＳコンポーネント９１５は、実行可能プログラムコンポーネントであり、ＴＬＬコントローラの動作を実施する。オペレーティングシステムは、Ｉ／Ｏ、ネットワークインタフェース、周辺デバイス、ストレージデバイス等へのアクセスを実施する。オペレーティングシステムは、フォールトトレランスが高くスケーラブルでセキュアなシステムである。例えば、以下を含む：Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ Ｘ（サーバ）；ＡＴ＆Ｔ Ｐｌａｎ ９；Ｂｅ ＯＳ；Ｕｎｉｘ（登録商標）及びＵｎｉｘライクなシステム（例えば、ＡＴ＆Ｔ ＵＮＩＸ；Ｂｅｒｋｌｅｙ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＢＳＤ）系列、例えば、ＦｒｅｅＢＳＤ、ＮｅｔＢＳＤ、ＯｐｅｎＢＳＤ等；Ｌｉｎｕｘ(登録商標)ディストリビューション、例えば、ＲｅｄＨａｔ、Ｕｂｕｎｔｕ等）；その他の同様のＯＳ。但し、より限定的及び／又はセキュリティの低いＯＳを採用することもできる。例えば、ＡｐｐｌｅＭａｃｉｎｔｏｓｈ ＯＳ、ＩＢＭ ＯＳ／２、Ｍｉｃｒｏｓｏｆｔ ＤＯＳ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ２，０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ＮＴ／Ｖｉｓｔａ／ＸＰ（サーバ）、ＰａｌｍＯＳ等。また、モバイルＯＳを採用することもできる。例えば、Ａｐｐｌｅ ｉＯＳ、Ｇｏｏｇｌｅ Ａｎｄｒｏｉｄ、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ ＷｅｂＯＳ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ等である。これらＯＳは、ＮＩＣＫコントローラのハードウェアに組み込み、及び／又はメモリ／ストレージに格納／ロードすることができる。ＯＳは、自らを含むコンポーネントコレクションの他のコンポーネント等と通信することができる。多くの場合、ＯＳは、他のプログラムコンポーネント、ユーザインタフェース等と通信する。例えば、ＯＳは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを含み、通信し、生成し、取得し、及び／又は提供する。ＣＰＵがＯＳを実行すると、通信ネットワーク、データ、Ｉ／Ｏ、周辺デバイス、プログラムコンポーネント、メモリ、ユーザ入力デバイス等との通信が可能になる。ＯＳは、通信プロトコルを提供する。通信プロトコルにより、ＴＬＬコントローラは、通信ネットワーク９１３を介して他のエンティティと通信することができる。ＴＬＬコントローラは、サブスクライバ通信メカニズムとして様々な通信プロトコルを使用することができる。例えば、マルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャスト等を含むが、これに限らない。
ＯＳコンポーネント９１５は、実行可能プログラムコンポーネントであり、ＴＬＬコントローラの動作を実施する。オペレーティングシステムは、Ｉ／Ｏ、ネットワークインタフェース、周辺デバイス、ストレージデバイス等へのアクセスを実施する。オペレーティングシステムは、フォールトトレランスが高くスケーラブルでセキュアなシステムである。例えば、以下を含む：Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ Ｘ（サーバ）；ＡＴ＆Ｔ Ｐｌａｎ ９；Ｂｅ ＯＳ；Ｕｎｉｘ（登録商標）及びＵｎｉｘライクなシステム（例えば、ＡＴ＆Ｔ ＵＮＩＸ；Ｂｅｒｋｌｅｙ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＢＳＤ）系列、例えば、ＦｒｅｅＢＳＤ、ＮｅｔＢＳＤ、ＯｐｅｎＢＳＤ等；Ｌｉｎｕｘ(登録商標)ディストリビューション、例えば、ＲｅｄＨａｔ、Ｕｂｕｎｔｕ等）；その他の同様のＯＳ。但し、より限定的及び／又はセキュリティの低いＯＳを採用することもできる。例えば、ＡｐｐｌｅＭａｃｉｎｔｏｓｈ ＯＳ、ＩＢＭ ＯＳ／２、Ｍｉｃｒｏｓｏｆｔ ＤＯＳ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ２，０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ＮＴ／Ｖｉｓｔａ／ＸＰ（サーバ）、ＰａｌｍＯＳ等。また、モバイルＯＳを採用することもできる。例えば、Ａｐｐｌｅ ｉＯＳ、Ｇｏｏｇｌｅ Ａｎｄｒｏｉｄ、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ ＷｅｂＯＳ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ等である。これらＯＳは、ＮＩＣＫコントローラのハードウェアに組み込み、及び／又はメモリ／ストレージに格納／ロードすることができる。ＯＳは、自らを含むコンポーネントコレクションの他のコンポーネント等と通信することができる。多くの場合、ＯＳは、他のプログラムコンポーネント、ユーザインタフェース等と通信する。例えば、ＯＳは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを含み、通信し、生成し、取得し、及び／又は提供する。ＣＰＵがＯＳを実行すると、通信ネットワーク、データ、Ｉ／Ｏ、周辺デバイス、プログラムコンポーネント、メモリ、ユーザ入力デバイス等との通信が可能になる。ＯＳは、通信プロトコルを提供する。通信プロトコルにより、ＴＬＬコントローラは、通信ネットワーク９１３を介して他のエンティティと通信することができる。ＴＬＬコントローラは、サブスクライバ通信メカニズムとして様々な通信プロトコルを使用することができる。例えば、マルチキャスト、ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャスト等を含むが、これに限らない。
＜情報サーバ＞
情報サーバコンポーネント９１６は、ＣＰＵが実行するプログラムコンポーネントである。情報サーバは、例えば、インターネット情報サーバであり、以下を含むがこれに限らない：Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ ＦｏｕｎｄａｔｉｏｎのＡｐａｃｈｅ、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ等。情報サーバにより、プログラムコンポーネントを実行することができる。例えば、以下のような機能を介して実行する：Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅ（ＡＳＰ）、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、及び／又は．ＮＥＴ、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）スクリプト、ｄｙｎａｍｉｃ（Ｄ）ｈｙｐｅｒｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ（ＨＴＭＬ）、ＦＬＡＳＨ、Ｊａｖａ（登録商標）)、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｒａｃｔｉｃａｌ Ｅｘｔｒａｃｔｉｏｎ Ｒｅｐｏｒｔ Ｌａｎｇｕａｇｅ（ＰＥＲＬ）、Ｈｙｐｅｒｔｅｘｔ Ｐｒｅ−Ｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、パイプ、Ｐｙｔｈｏｎ、ｗｉｒｅｌｅｓｓ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ（ＷＡＰ）、ＷｅｂＯｂｊｅｃｔｓ等。情報サーバは、セキュア通信プロトコルをサポートする。例えば、以下を含むがこれに限らない：Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＦＴＰ）；ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）；Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）、メッセージングプロトコル（例えば、Ａｍｅｒｉｃａ Ｏｎｌｉｎｅ（ＡＯＬ）Ｉｎｓｔａｎｔ Ｍｅｓｓｅｎｇｅｒ（ＡＩＭ）、Ａｐｐｌｅ ｉＭｅｓｓａｇｅ、Ａｐｐｌｉｃａｔｉｏｎ Ｅｘｃｈａｎｇｅ（ＡＰＥＸ）、ＩＣＱ、Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ（ＩＲＣ）、Ｍｉｃｒｏｓｏｆｔ Ｎｅｔｗｏｒｋ（ＭＳＮ）Ｍｅｓｓｅｎｇｅｒ Ｓｅｒｖｉｃｅ、Ｐｒｅｓｅｎｃｅ ａｎｄ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ（ＰＲＩＭ）、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）、ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ（ＳＩＭＰＬＥ）、ｏｐｅｎ ＸＭＬ−ｂａｓｅｄ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ）（すなわち、Ｊａｂｂｅｒ ｏｒ Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｓｅｒｖｉｃｅ（ＩＭＰＳ））、Ｙａｈｏｏ！ Ｉｎｓｔａｎｔ Ｍｅｓｓｅｎｇｅｒ Ｓｅｒｖｉｃｅ等。情報サーバは、ウェブブラウザに対してウェブページの形態で結果を提供し、他のプログラムコンポーネントとのやり取りを通じてウェブページの生成を操作する。ＨＴＴＰ要求のうちＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ （ＤＮＳ）が解決する部分が情報サーバに対して提供されると、情報サーバは、ＨＴＴＰ要求の残部分に基づきＴＬＬコントローラ上の特定場所における情報要求を取得する。例えば、要求ｈｔｔｐ：／／１２３．１２４１２５．１２６／ｍｙＩｎｆｏｒｍａｔｉｏｎｈｔｍｌは、ＤＮＳサーバが解決して情報サーバに対して提供するＩＰ部分「１２３．１２４.１２５．１２６」を有する。情報サーバは、次に、ｈｔｔｐ要求をパースして「／ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌ」部分を取得し、「ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌ」を含むメモリ位置を特定する。その他の情報提供プロトコルを様々なポートで用いることもできる。例えば、ポート２１のＦＴＰ通信等である。情報サーバは、コンポーネントコレクションの他のコンポーネントと通信する。情報サーバは、多くの場合、ＴＬＬデータベース９１９、ＯＳ，他のプログラムコンポーネント、ユーザインタフェース、ウェブブラウザ等と通信する。
情報サーバコンポーネント９１６は、ＣＰＵが実行するプログラムコンポーネントである。情報サーバは、例えば、インターネット情報サーバであり、以下を含むがこれに限らない：Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ ＦｏｕｎｄａｔｉｏｎのＡｐａｃｈｅ、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ等。情報サーバにより、プログラムコンポーネントを実行することができる。例えば、以下のような機能を介して実行する：Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅ（ＡＳＰ）、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、及び／又は．ＮＥＴ、Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ（ＣＧＩ）スクリプト、ｄｙｎａｍｉｃ（Ｄ）ｈｙｐｅｒｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ（ＨＴＭＬ）、ＦＬＡＳＨ、Ｊａｖａ（登録商標）)、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｒａｃｔｉｃａｌ Ｅｘｔｒａｃｔｉｏｎ Ｒｅｐｏｒｔ Ｌａｎｇｕａｇｅ（ＰＥＲＬ）、Ｈｙｐｅｒｔｅｘｔ Ｐｒｅ−Ｐｒｏｃｅｓｓｏｒ（ＰＨＰ）、パイプ、Ｐｙｔｈｏｎ、ｗｉｒｅｌｅｓｓ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ（ＷＡＰ）、ＷｅｂＯｂｊｅｃｔｓ等。情報サーバは、セキュア通信プロトコルをサポートする。例えば、以下を含むがこれに限らない：Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＦＴＰ）；ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）；Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）、メッセージングプロトコル（例えば、Ａｍｅｒｉｃａ Ｏｎｌｉｎｅ（ＡＯＬ）Ｉｎｓｔａｎｔ Ｍｅｓｓｅｎｇｅｒ（ＡＩＭ）、Ａｐｐｌｅ ｉＭｅｓｓａｇｅ、Ａｐｐｌｉｃａｔｉｏｎ Ｅｘｃｈａｎｇｅ（ＡＰＥＸ）、ＩＣＱ、Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ（ＩＲＣ）、Ｍｉｃｒｏｓｏｆｔ Ｎｅｔｗｏｒｋ（ＭＳＮ）Ｍｅｓｓｅｎｇｅｒ Ｓｅｒｖｉｃｅ、Ｐｒｅｓｅｎｃｅ ａｎｄ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ（ＰＲＩＭ）、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）、ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ（ＳＩＭＰＬＥ）、ｏｐｅｎ ＸＭＬ−ｂａｓｅｄ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ）（すなわち、Ｊａｂｂｅｒ ｏｒ Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｓｅｒｖｉｃｅ（ＩＭＰＳ））、Ｙａｈｏｏ！ Ｉｎｓｔａｎｔ Ｍｅｓｓｅｎｇｅｒ Ｓｅｒｖｉｃｅ等。情報サーバは、ウェブブラウザに対してウェブページの形態で結果を提供し、他のプログラムコンポーネントとのやり取りを通じてウェブページの生成を操作する。ＨＴＴＰ要求のうちＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ （ＤＮＳ）が解決する部分が情報サーバに対して提供されると、情報サーバは、ＨＴＴＰ要求の残部分に基づきＴＬＬコントローラ上の特定場所における情報要求を取得する。例えば、要求ｈｔｔｐ：／／１２３．１２４１２５．１２６／ｍｙＩｎｆｏｒｍａｔｉｏｎｈｔｍｌは、ＤＮＳサーバが解決して情報サーバに対して提供するＩＰ部分「１２３．１２４.１２５．１２６」を有する。情報サーバは、次に、ｈｔｔｐ要求をパースして「／ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌ」部分を取得し、「ｍｙＩｎｆｏｒｍａｔｉｏｎ.ｈｔｍｌ」を含むメモリ位置を特定する。その他の情報提供プロトコルを様々なポートで用いることもできる。例えば、ポート２１のＦＴＰ通信等である。情報サーバは、コンポーネントコレクションの他のコンポーネントと通信する。情報サーバは、多くの場合、ＴＬＬデータベース９１９、ＯＳ，他のプログラムコンポーネント、ユーザインタフェース、ウェブブラウザ等と通信する。
ＴＬＬデータベースに対するアクセスは、データベースブリッジメカニズムを介して実現することができる。例えば、以下に列挙するスクリプト言語（例えば、ＣＧＩ）や、以下に列挙するアプリケーション間通信チャネル（例えば、ＣＯＲＢＡ、ＷｅｂＯｂｊｅｃｔｓ等）を用いることができる。ウェブブラウザを介したデータ要求は、ブリッジメカニズムを介してパースされ、ＴＬＬが要求する適切な文法に変換される。一実施形態において、情報サーバは、ウェブブラウザがアクセス可能なウェブフォームを提供することができる。ウェブフォーム上で提供するフィールドに対する入力は、入力した旨をタグ付され、そのようにパースされる。入力された語句は、フィールドタグと共に引き渡され、適当なテーブル及び／又はフィールドへのクエリを生成するようパーサに対して指示する。一実施形態において、パーサは、タグ付けされたテキスト入力に基づき適当なｊｏｉｎ／ｓｅｌｅｃｔコマンドを含む検索文字列を有する標準ＳＱＬクエリを生成する。得られたコマンドは、ブリッジメカニズムを通じてＴＬＬに対してクエリとして提供される。クエリから結果を生成すると、その結果は、ブリッジメカニズムを介して引き渡され、ブリッジメカニズムによってフォーマット化及び新たな結果ウェブページを生成するためにパースしてもよい。新たな結果ウェブページは、情報サーバに提供され、情報サーバは、これを要求元のウェブブラウザへ提供する。
情報サーバは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。
＜ユーザインタフェース＞
コンピュータインタフェースは、幾つかの点で自動車運転インタフェースと類似する。自動車運転インタフェース要素、例えば、操作ハンドル、ギアシフト、及び速度計は、自動車リソース及び状態のアクセス、操作及び表示を実現する。コンピュータインタラクションインタフェース要素、例えば、チェックボックス、カーソル、メニュー、スクローラ及びウィンドウ（集合的に及び一般的にウィジェットと呼ばれる）は、同様に、データ及びコンピュータハードウェア及びオペレーティングシステムリソース、並びに状態のアクセス、能力、操作及び表示を実現する。操作インタフェースは、一般的に、ユーザインタフェースと呼ばれる。グラフィカルユーザインタフェース（graphical user interface：ＧＵＩ）は、基本機能及び情報にアクセスしグラフィカル表示する手段をユーザに対して提供する。ＧＵＩの例は、以下である：Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ ＡｑｕａとｉＯＳ Ｃｏｃｏａ Ｔｏｕｃｈ、ＩＢＭ ＯＳ／２、Ｇｏｏｇｌｅ Ａｎｄｒｏｉｄ Ｍｏｂｉｌｅ ＵＩ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ２，０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／Ｍｏｂｉｌｅ／ＮＴ／ＸＰ／Ｖｉｓｔａ／６／８（すなわちＡｅｒｏ、Ｍｅｔｒｏ）、Ｕｎｉｘ Ｘ−Ｗｉｎｄｏｗｓ（例えば、以下のようなＵｎｉｘグラフィックインタフェースライブラリを含む：Ｋ Ｄｅｓｋｔｏｐ Ｅｎｖｉｒｏｎｍｅｎｔ（ＫＤＥ）、ｍｙｔｈＴＶ、ＧＮＵ Ｎｅｔｗｏｒｋ Ｏｂｊｅｃｔ Ｍｏｄｅｌ Ｅｎｖｉｒｏｎｍｅｎｔ（ＧＮＯＭＥ））、ウェブインタフェースライブラリ（例えば、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ等、以下のようなインタフェースライブラリ（但し、これらに限らない）：Ｄｏｊｏ、ｊＱｕｅｒｙ（ＵＩ）、ＭｏｏＴｏｏｌｓ、Ｐｒｏｔｏｔｙｐｅ、ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ、ＳＷＦＯｂｊｅｃｔ、Ｙａｈｏｏ！ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）。
コンピュータインタフェースは、幾つかの点で自動車運転インタフェースと類似する。自動車運転インタフェース要素、例えば、操作ハンドル、ギアシフト、及び速度計は、自動車リソース及び状態のアクセス、操作及び表示を実現する。コンピュータインタラクションインタフェース要素、例えば、チェックボックス、カーソル、メニュー、スクローラ及びウィンドウ（集合的に及び一般的にウィジェットと呼ばれる）は、同様に、データ及びコンピュータハードウェア及びオペレーティングシステムリソース、並びに状態のアクセス、能力、操作及び表示を実現する。操作インタフェースは、一般的に、ユーザインタフェースと呼ばれる。グラフィカルユーザインタフェース（graphical user interface：ＧＵＩ）は、基本機能及び情報にアクセスしグラフィカル表示する手段をユーザに対して提供する。ＧＵＩの例は、以下である：Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ ＡｑｕａとｉＯＳ Ｃｏｃｏａ Ｔｏｕｃｈ、ＩＢＭ ＯＳ／２、Ｇｏｏｇｌｅ Ａｎｄｒｏｉｄ Ｍｏｂｉｌｅ ＵＩ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ２，０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／Ｍｏｂｉｌｅ／ＮＴ／ＸＰ／Ｖｉｓｔａ／６／８（すなわちＡｅｒｏ、Ｍｅｔｒｏ）、Ｕｎｉｘ Ｘ−Ｗｉｎｄｏｗｓ（例えば、以下のようなＵｎｉｘグラフィックインタフェースライブラリを含む：Ｋ Ｄｅｓｋｔｏｐ Ｅｎｖｉｒｏｎｍｅｎｔ（ＫＤＥ）、ｍｙｔｈＴＶ、ＧＮＵ Ｎｅｔｗｏｒｋ Ｏｂｊｅｃｔ Ｍｏｄｅｌ Ｅｎｖｉｒｏｎｍｅｎｔ（ＧＮＯＭＥ））、ウェブインタフェースライブラリ（例えば、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ等、以下のようなインタフェースライブラリ（但し、これらに限らない）：Ｄｏｊｏ、ｊＱｕｅｒｙ（ＵＩ）、ＭｏｏＴｏｏｌｓ、Ｐｒｏｔｏｔｙｐｅ、ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ、ＳＷＦＯｂｊｅｃｔ、Ｙａｈｏｏ！ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）。
ユーザインタフェースコンポーネント９１６は、ＣＰＵが実行する保存されたプログラムコンポーネントである。ユーザインタフェースは、ＯＳ及び／又は上記動作環境が提供し、これらと共に提供され、及び／又はこれら上に提供されるグラフィックユーザインタフェースである。ユーザインタフェースは、テキスト及び／又はグラフィック情報によってプログラムコンポーネント及び／又はシステム設備の表示、実行、インタラクション、操作及び／又は演算を実現する。ユーザインタフェースにより、ユーザは、コンピュータシステムに影響を与え、コンピュータシステムとインタラクトし及び／又はコンピュータシステムを操作できる。ユーザインタフェースは、コンポーネントコレクションの他のコンポーネントと通信する。ユーザインタフェースは、それ自体及び／又は設備等を含むコンポーネントコレクション内で他のコンポーネントに及び／又は他のコンポーネントと通信してもよい。ユーザインタフェースは、ＯＳ、他のプログラムコンポーネント等と通信する。ユーザインタフェースは、プログラムコンポーネント、システム、ユーザ及び／又はデータ通信、要求及び／又は応答を含み、これらと通信し、これらを生成、取得及び／又は提供する。
＜ウェブブラウザ＞
ウェブブラウザコンポーネント９１８は、ＣＰＵによって実行される保存されたプログラムコンポーネントである。ウェブブラウザは、例えば、グーグルの（モバイル）Ｃｈｒｏｍｅ、マイクロソフトＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ、アップル（モバイル）Ｓａｆａｒｉ、例えば、アップルのＣｏｃｏａ（Ｔｏｕｃｈ）オブジェクトクラスを介する埋め込みウェブブラウザオブジェクト等のハイパーテキスト閲覧アプリケーションであってもよい。安全なウェブブラウジングのために、ＨＴＴＰＳ、ＳＳＬ等によって１２８ビット（又はこれ以上）の暗号化を提供してもよい。ウェブブラウザは、例えば、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ウェブブラウザプラグインＡＰＩ（例えば、Ｃｈｒｏｍｅ、ＦｉｒｅＦｏｘ、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｓａｆａｒｉ Ｐｌｕｇ−ｉｎ及び／又はこれらに類するＡＰＩ）等を介してプログラムコンポーネントの実行を実現してもよい。ウェブブラウザ及び同様の情報アクセスツールは、ＰＤＡ、携帯電話、スマートフォン及び／又は他のモバイル機器に統合してもよい。ウェブブラウザは、それ自体及び／又は設備等を含むコンポーネントコレクション内で他のコンポーネントに及び／又は他のコンポーネントと通信してもよい。ウェブブラウザは、情報サーバ、ＯＳ、統合プログラムコンポーネント（例えば、プラグイン）等と通信する。ウェブブラウザは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。ウェブブラウザと情報サーバに代えて、組み合わせアプリケーションを開発し、これら双方と同様の動作を実施することもできる。組み合わせアプリケーションは、同様に、ＴＬＬ実装ノードからユーザやユーザエージェントに対して情報取得又は提供を実施する。組み合わせアプリケーションは、標準ウェブブラウザを採用したシステムにとっては、無用である。
ウェブブラウザコンポーネント９１８は、ＣＰＵによって実行される保存されたプログラムコンポーネントである。ウェブブラウザは、例えば、グーグルの（モバイル）Ｃｈｒｏｍｅ、マイクロソフトＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ、アップル（モバイル）Ｓａｆａｒｉ、例えば、アップルのＣｏｃｏａ（Ｔｏｕｃｈ）オブジェクトクラスを介する埋め込みウェブブラウザオブジェクト等のハイパーテキスト閲覧アプリケーションであってもよい。安全なウェブブラウジングのために、ＨＴＴＰＳ、ＳＳＬ等によって１２８ビット（又はこれ以上）の暗号化を提供してもよい。ウェブブラウザは、例えば、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ウェブブラウザプラグインＡＰＩ（例えば、Ｃｈｒｏｍｅ、ＦｉｒｅＦｏｘ、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｓａｆａｒｉ Ｐｌｕｇ−ｉｎ及び／又はこれらに類するＡＰＩ）等を介してプログラムコンポーネントの実行を実現してもよい。ウェブブラウザ及び同様の情報アクセスツールは、ＰＤＡ、携帯電話、スマートフォン及び／又は他のモバイル機器に統合してもよい。ウェブブラウザは、それ自体及び／又は設備等を含むコンポーネントコレクション内で他のコンポーネントに及び／又は他のコンポーネントと通信してもよい。ウェブブラウザは、情報サーバ、ＯＳ、統合プログラムコンポーネント（例えば、プラグイン）等と通信する。ウェブブラウザは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。ウェブブラウザと情報サーバに代えて、組み合わせアプリケーションを開発し、これら双方と同様の動作を実施することもできる。組み合わせアプリケーションは、同様に、ＴＬＬ実装ノードからユーザやユーザエージェントに対して情報取得又は提供を実施する。組み合わせアプリケーションは、標準ウェブブラウザを採用したシステムにとっては、無用である。
＜メールサーバ＞
メールサーバコンポーネント９２１は、ＣＰＵ９０３が実行するプログラムコンポーネントである。メールサーバは、以下のようなインターネットメールサーバであるが、これらに限らない：Ａｐｐｌｅ Ｍａｉｌ Ｓｅｒｖｅｒ（３）、ｄｏｖｅｃｔ、ｓｅｎｄｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ等。メールサーバにより、以下のような機能を介してプログラムコンポーネントを実行することができる：ＡＳＰ、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、及び／又は．ＮＥＴ、ＣＧＩスクリプト、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ＰＥＲＬ、ＰＨＰ、パイプ、Ｐｙｔｈｏｎ、ＷｅｂＯｂｊｅｃｔｓ等。メールサーバは、以下のような通信プロトコルをサポートするが、これらに限らない：Ｉｎｔｅｒｎｅｔ ｍｅｓｓａｇｅ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ（ＩＭＡＰ）、Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＭＡＰＩ）／Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ｐｏｓｔ ｏｆｆｉｃｅ ｐｒｏｔｏｃｏｌ（ＰＯＰ３）、ｓｉｍｐｌｅ ｍａｉｌ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）等。メールサーバは、ＴＬＬに対して送信され、リレーされ、及び／又は通過する発着メールメッセージをルーティングし、転送し、処理する。
メールサーバコンポーネント９２１は、ＣＰＵ９０３が実行するプログラムコンポーネントである。メールサーバは、以下のようなインターネットメールサーバであるが、これらに限らない：Ａｐｐｌｅ Ｍａｉｌ Ｓｅｒｖｅｒ（３）、ｄｏｖｅｃｔ、ｓｅｎｄｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ等。メールサーバにより、以下のような機能を介してプログラムコンポーネントを実行することができる：ＡＳＰ、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃、及び／又は．ＮＥＴ、ＣＧＩスクリプト、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ＰＥＲＬ、ＰＨＰ、パイプ、Ｐｙｔｈｏｎ、ＷｅｂＯｂｊｅｃｔｓ等。メールサーバは、以下のような通信プロトコルをサポートするが、これらに限らない：Ｉｎｔｅｒｎｅｔ ｍｅｓｓａｇｅ ａｃｃｅｓｓ ｐｒｏｔｏｃｏｌ（ＩＭＡＰ）、Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＭＡＰＩ）／Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ｐｏｓｔ ｏｆｆｉｃｅ ｐｒｏｔｏｃｏｌ（ＰＯＰ３）、ｓｉｍｐｌｅ ｍａｉｌ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）等。メールサーバは、ＴＬＬに対して送信され、リレーされ、及び／又は通過する発着メールメッセージをルーティングし、転送し、処理する。
ＴＬＬメールへのアクセスは、個々のウェブサーバコンポーネント及び／又はＯＳが提供するＡＰＩを通じて実現できる。
メールサーバは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。
＜メールクライアント＞
メールクライアントコンポーネント９２２は、ＣＰＵ９０３が実行するプログラムコンポーネントである。メールクライアントは、以下のようなメールを見るアプリケーションである：Ａｐｐｌｅ（Ｍｏｂｉｌｅ）Ｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ Ｅｎｔｏｕｒａｇｅ、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ、Ｍｏｚｉｌｌａ、Ｔｈｕｎｄｅｒｂｉｒｄ等。メールクライアントは、以下のような通信プロトコルをサポートする：ＩＭＡＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ＰＯＰ３、ＳＭＴＰ等。メールクライアントは、コンポーネントコレクションの他のコンポーネントと通信することができる。メールクライアントは、メールサーバ、ＯＳ、他のメールクライアント等と通信する。メールクライアントは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。一般にメールクライアントは、電子メールメッセージを編集し送信する機能を提供する。
メールクライアントコンポーネント９２２は、ＣＰＵ９０３が実行するプログラムコンポーネントである。メールクライアントは、以下のようなメールを見るアプリケーションである：Ａｐｐｌｅ（Ｍｏｂｉｌｅ）Ｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ Ｅｎｔｏｕｒａｇｅ、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ、Ｍｏｚｉｌｌａ、Ｔｈｕｎｄｅｒｂｉｒｄ等。メールクライアントは、以下のような通信プロトコルをサポートする：ＩＭＡＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ＰＯＰ３、ＳＭＴＰ等。メールクライアントは、コンポーネントコレクションの他のコンポーネントと通信することができる。メールクライアントは、メールサーバ、ＯＳ、他のメールクライアント等と通信する。メールクライアントは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。一般にメールクライアントは、電子メールメッセージを編集し送信する機能を提供する。
＜暗号サーバ＞
暗号サーバコンポーネント９２０は、ＣＰＵ９０３、暗号プロセッサ９２６、暗号プロセッサインタフェース９２６、暗号プロセッサデバイス９２８等が実行するプログラムコンポーネントである。暗号プロセッサインタフェースにより、暗号コンポーネントは、暗号及び／又は復号要求を実行する。但し、暗号コンポーネントは、これに代えて、ＣＰＵ上で動作することもできる。暗号コンポーネントにより、提供されたデータを暗号化し及び／又は復号化することができる。暗号コンポーネントにより、対称／非対称（例えば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＰ））暗号及び／又は復号を実施することができる。暗号コンポーネントは、以下のような暗号技術を採用できるが、これらに限らない：デジタル証明書（例えば、Ｘ．５０９認証フレームワーク）、デジタル署名、デュアル署名、ｅｎｖｅｌｏｐｉｎｇ署名、パスワードアクセス保護、公開鍵管理等。暗号コンポーネントにより、以下のようなセキュリティプロトコル（暗号化及び／又は復号化）を実施することができるが、これらに限らない：ｃｈｅｃｋｓｕｍ、Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＤＥＳ）、Ｅｌｌｉｐｔｉｃａｌ Ｃｕｒｖｅ Ｅｎｃｒｙｐｔｉｏｎ（ＥＣＣ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｌｇｏｒｉｔｈｍ（ＩＤＥＡ）、Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５（ＭＤ５、１方向ハッシュ）、パスワード、Ｒｉｖｅｓｔ Ｃｉｐｈｅｒ（ＲＣ５）、Ｒｉｊｎｄａｅｌ、ＲＳＡ（１９６６年にＲｏｎ Ｒｉｖｅｓｔ、Ａｄｉ Ｓｈａｍｉｒ、Ｌｅｏｎａｒｄ Ａｄｌｅｍａｎが開発したアルゴリズムを用いるインターネット暗号及び認証システム）、Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ（ＳＨＡ）、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）、Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）等。これら暗号セキュリティプロトコルを用いて、ＴＬＬは、全ての発着通信を暗号化し、より広い通信ネットワークを有する仮想プライベートネットワーク（ＶＰＮ）内のノードとして動作する。暗号コンポーネントは、「セキュリティ認証」プロセスを実施し、ソースに対するアクセスは、セキュリティプロトコルによって禁止される。暗号コンポーネントは、セキュアリソースに対するアクセス認証を実施する。また暗号コンポーネントは、コンテンツの一意的ＩＤを提供する。例えば、ＭＤ５ハッシュを採用してデジタルオーディオファーイルの一意的ＩＤを取得する。暗号コンポーネントは、コンポーネントコレクションの他のコンポーネントと通信することができる。暗号コンポーネントは、通信ネットワーク上で情報を安全に送信する暗号方式をサポートし、ＴＬＬコンポーネントは、これによりセキュア通信を実施できる。暗号コンポーネントは、ＴＬＬ上のリソースに対するセキュアアクセスを実現し、リモートシステム上のリソースに対するセキュアアクセスを実現する。すなわち、セキュアリソースのクライアント及び／又はサーバとして動作する。暗号コンポーネントは、情報サーバ、ＯＳ，他のプログラムコンポーネント等と通信する。暗号コンポーネントは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。
暗号サーバコンポーネント９２０は、ＣＰＵ９０３、暗号プロセッサ９２６、暗号プロセッサインタフェース９２６、暗号プロセッサデバイス９２８等が実行するプログラムコンポーネントである。暗号プロセッサインタフェースにより、暗号コンポーネントは、暗号及び／又は復号要求を実行する。但し、暗号コンポーネントは、これに代えて、ＣＰＵ上で動作することもできる。暗号コンポーネントにより、提供されたデータを暗号化し及び／又は復号化することができる。暗号コンポーネントにより、対称／非対称（例えば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＰ））暗号及び／又は復号を実施することができる。暗号コンポーネントは、以下のような暗号技術を採用できるが、これらに限らない：デジタル証明書（例えば、Ｘ．５０９認証フレームワーク）、デジタル署名、デュアル署名、ｅｎｖｅｌｏｐｉｎｇ署名、パスワードアクセス保護、公開鍵管理等。暗号コンポーネントにより、以下のようなセキュリティプロトコル（暗号化及び／又は復号化）を実施することができるが、これらに限らない：ｃｈｅｃｋｓｕｍ、Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＤＥＳ）、Ｅｌｌｉｐｔｉｃａｌ Ｃｕｒｖｅ Ｅｎｃｒｙｐｔｉｏｎ（ＥＣＣ）、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｌｇｏｒｉｔｈｍ（ＩＤＥＡ）、Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５（ＭＤ５、１方向ハッシュ）、パスワード、Ｒｉｖｅｓｔ Ｃｉｐｈｅｒ（ＲＣ５）、Ｒｉｊｎｄａｅｌ、ＲＳＡ（１９６６年にＲｏｎ Ｒｉｖｅｓｔ、Ａｄｉ Ｓｈａｍｉｒ、Ｌｅｏｎａｒｄ Ａｄｌｅｍａｎが開発したアルゴリズムを用いるインターネット暗号及び認証システム）、Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ（ＳＨＡ）、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）、Ｓｅｃｕｒｅ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰＳ）等。これら暗号セキュリティプロトコルを用いて、ＴＬＬは、全ての発着通信を暗号化し、より広い通信ネットワークを有する仮想プライベートネットワーク（ＶＰＮ）内のノードとして動作する。暗号コンポーネントは、「セキュリティ認証」プロセスを実施し、ソースに対するアクセスは、セキュリティプロトコルによって禁止される。暗号コンポーネントは、セキュアリソースに対するアクセス認証を実施する。また暗号コンポーネントは、コンテンツの一意的ＩＤを提供する。例えば、ＭＤ５ハッシュを採用してデジタルオーディオファーイルの一意的ＩＤを取得する。暗号コンポーネントは、コンポーネントコレクションの他のコンポーネントと通信することができる。暗号コンポーネントは、通信ネットワーク上で情報を安全に送信する暗号方式をサポートし、ＴＬＬコンポーネントは、これによりセキュア通信を実施できる。暗号コンポーネントは、ＴＬＬ上のリソースに対するセキュアアクセスを実現し、リモートシステム上のリソースに対するセキュアアクセスを実現する。すなわち、セキュアリソースのクライアント及び／又はサーバとして動作する。暗号コンポーネントは、情報サーバ、ＯＳ，他のプログラムコンポーネント等と通信する。暗号コンポーネントは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを、含み、通信し、生成し、取得し、及び／又は提供する。
＜ＴＬＬデータベース＞
ＴＬＬデータベースコンポーネント９１９は、データベースとそのデータ内に実装することができる。データベースは、プログラムコンポーネントであり、ＣＰＵが実行する。プログラムコンポーネントは、格納されているデータをＣＰＵに処理させる。データベースは、任意個数のフォールトトレラント、関係、スケーラブル、セキュアデータベースであり、例えば、ＤＢ２、ＭｙＳＱＬ、Ｏｒａｃｌｅ、Ｓｙｂａｓｅ等である。リレーショナルデータベースは、フラットファイルの拡張である。リレーショナルデータベースは、関係テーブルによって構成される。テーブルは、キーフィールドによって相互接続される。キーフィールドを用いて、キーフィールドに対してインデックスすることにより、テーブルを組み合わせることができる。キーフィールドは、複数のテーブルからの情報を組み合わせる次元ピボットポイントとして動作する。関係は、一般に、プライマリキーをマッチングすることにより、テーブル間で維持されたリンクを識別する。プライマリキーは、リレーショナルデータベース内のテーブルの行を一意に識別するフィールドを表す。より正確には、プライマリキーは、一対多関係における「一方の」テーブルの行を一意に識別する。
ＴＬＬデータベースコンポーネント９１９は、データベースとそのデータ内に実装することができる。データベースは、プログラムコンポーネントであり、ＣＰＵが実行する。プログラムコンポーネントは、格納されているデータをＣＰＵに処理させる。データベースは、任意個数のフォールトトレラント、関係、スケーラブル、セキュアデータベースであり、例えば、ＤＢ２、ＭｙＳＱＬ、Ｏｒａｃｌｅ、Ｓｙｂａｓｅ等である。リレーショナルデータベースは、フラットファイルの拡張である。リレーショナルデータベースは、関係テーブルによって構成される。テーブルは、キーフィールドによって相互接続される。キーフィールドを用いて、キーフィールドに対してインデックスすることにより、テーブルを組み合わせることができる。キーフィールドは、複数のテーブルからの情報を組み合わせる次元ピボットポイントとして動作する。関係は、一般に、プライマリキーをマッチングすることにより、テーブル間で維持されたリンクを識別する。プライマリキーは、リレーショナルデータベース内のテーブルの行を一意に識別するフィールドを表す。より正確には、プライマリキーは、一対多関係における「一方の」テーブルの行を一意に識別する。
これに代えて、ＴＬＬデータベースは、様々な標準データ構造を用いて実装することができる。例えば、アレイ、ハッシュ（リンク）リスト、構造、構造化テキストファイル（例えば、ＸＭＬ）、テーブル等である。このデータ構造は、メモリ及び／又は（構造化）ファイルに格納することができる。他の実施例において、オブジェクト指向データベースを用いることもできる。例えば、Ｆｒｏｎｔｉｅｒ、ＯｂｊｅｃｔＳｔｏｒｅ、Ｐｏｅｔ、Ｚｏｐｅ等である。オブジェクトデータベースは、共通属性によりグループ化され及び／又はリンクされたオブジェクトコレクションを含む。オブジェクトコレクションは、共通属性により他のオブジェクトコレクションに関連付けることができる。オブジェクト指向データベースは、リレーショナルデータベースと同様に動作する。但し、オブジェクトは、単なるデータではなくそのオブジェクトにカプセル化された機能タイプを有する点を除く。ＴＬＬデータベースがデータ構造として実装されている場合、ＴＬＬデータベース９１９をＴＬＬコンポーネント９３５等の他のコンポーネントと統合して用いることができる。またデータベースは、データ構造、オブジェクト、関係構造の組み合わせとして実装することができる。データベースは、標準データ処理技術を通じて様々なバリエーションで統合し及び／又は分散させることができる。データベースの一部（例えば、テーブル）は、エクスポート及び／又はインポートすることができ、したがって、分割及び／又は統合することができる。
一実施形態において、データベースコンポーネント９１９は、複数のテーブル９１９ａ〜ｋを含む。ユーザテーブル９１９ａは、以下のようなフィールドを含むが、これらに限らない：ｕｓｅｒ＿ｉｄ、ｕｓｅｒ＿ｄｅｖｉｃｅ＿ｉｄ、ｕｓｅｒｎａｍｅ、ｐａｓｓｗｏｒｄ、ｄｏｂ、ｆｉｒｓｔ＿ｎａｍｅ、ｌａｓｔ＿ｎａｍｅ、ａｇｅ、ｓｔａｔｅ、ａｄｄｒｅｓｓ＿ｆｉｒｓｔｌｉｎｅ、ａｄｄｒｅｓｓ＿ｓｅｃｏｎｄｌｉｎｅ、ｚｉｐｃｏｄｅ、ｄｅｖｉｃｅｓ＿ｌｉｓｔ、ｃｏｎｔａｃｔ＿ｉｎｆｏ、ｃｏｎｔａｃｔ＿ｔｙｐｅ、ａｌｔ＿ｃｏｎｔａｃｔ＿ｉｎｆｏ、ａｌｔ＿ｃｏｎｔａｃｔ＿ｔｙｐｅ等。ユーザテーブルは、ＴＬＬ上の複数要素のアカウントをサポート及び／又はトラッキングする。データソーステーブル９１９ｂは、以下のようなフィールドを含むが、これに限らない：ｓｏｕｒｃｅ＿ＩＤ、ｓｏｕｒｃｅ＿ｎａｍｅ、ｓｏｕｒｃｅ＿ｓｅｒｖｅｒ＿ＩＤ、ｄｅｖｉｃｅ＿ｄｏｍａｉｎ、ｓｏｕｒｃｅ＿ｕｒｌ、ｓｏｕｒｃｅ＿ｓｅｃｕｒｉｔｙ＿ｐｒｏｔｏｃｏｌ、ｓｏｕｒｃｅ＿ｆｔｐ、ｄｅｖｉｃｅ＿ｓｅｃｕｒｅｋｅｙ等。ＰＯＰテーブル９１９ｃは、以下のようなフィールドを含むが、これに限らない：ｐｏｐ＿ｉｄ、ｐｏｐ＿ａｄｄｒｅｓｓ、ｐｏｐ＿ｓｅｒｖｅｒ＿ｉｐ、ｐｏｐ＿ｅｘｃｈａｎｇｅ、ｐｏｐ＿ｔｒａｎｓｍｉｔｔｉｏｎ＿ｔｉｍｅ、ｐｏｐ＿ｈｉｓｔｏｒｙ等。インデックステーブル９１９ｄは、以下のようなフィールドを含むが、これに限らない：ｉｎｄｅｘ＿ｉｄ、ｉｎｄｅｘ＿ｎａｍｅ、ｉｎｄｅｘ＿ａｔｔｒｉｂｕｔｅ、ｉｎｄｅｘ＿ｖａｌｕｅ、ｉｎｄｅｘ＿ｒａｔｅ、ｉｎｄｅｘ＿ｖｏｌｕｍｅ、ｉｎｄｅｘ＿ｔｉｍｅｓｔａｍｐ、ｉｎｄｅｘ＿ｓｏｕｒｃｅ等。属性テーブル９１９ｅは、以下のようなフィールドを含むが、これに限らない：ｇｅｏ−ｌｏｃａｔｉｏｎ、ｉｎｄｕｓｔｒｙ、ｓｉｚｅ、ｄａｉｌｙ＿ｖｏｌｕｍｅ、ｓｔｒａｔｅｇｙ＿ｔｙｐｅ、ｍａｘ＿ｓｉｚｅ、ｍｉｎ＿ｓｉｚｅ、ｔｒａｄｅ＿ｏｒｄｅｒ＿ｉｄ等。ビッドテーブル９１９ｆは、以下のようなフィールドを含むが、これに限らない：ｂｉｄ＿ｉｄ、ｂｉｄ＿ｔｉｍｅ、ｂｉｄ＿ａｔｔｒｉｂｕｔｅ、ｂｉｄ＿ａｄ＿ｔｙｐｅ、ｂｉｄ＿ａｄ＿ｎａｍｅ、ｂｉｄ＿ａｄ＿ｄｅｓｃｒｉｐｔｉｏｎ、ｂｉｄ＿ｒａｔｅ、ｂｉｄ＿ｒｅｓｕｌｔ等。注文テーブル９１９ｇは、以下のようなフィールドを含むが、これに限らない：ｏｒｄｅｒ＿ｉｄ、ｏｒｄｅｒ＿ｎａｍｅ、ｏｒｄｅｒ＿ｐａｒｔｉｃｉｐａｎｔ、ｏｒｄｅｒ＿ｕｓｅｒ＿ｉｄ、ｏｒｄｅｒ＿ｖｏｌｕｍｅ、ｏｒｄｅｒ＿ｂｉｄ＿ｉｄ、ｏｒｄｅｒ＿ｓｔａｔｕｓ、ｏｒｄｅｒ＿ｐｏｐ＿ｉｄ、ｏｒｄｅｒ＿ｌａｔｅｎｃｙ、ｏｒｄｅｒ＿ｒｏｕｔｉｎｇ等。金融商品テーブル９１９ｈは、以下のようなフィールドを含むが、これに限らない：ｉｎｓｔｒｕｍｅｎｔ＿ｉｄ、ｉｎｓｔｒｕｍｅｎｔ＿ｔｙｐｅ、ｉｎｓｔｒｕｍｅｎｔ＿Ｒｅｇ、ｉｎｓｔｒｕｍｅｎｔ＿ｓｔｒｕｃｔｕｒｅ、ｉｎｓｔｒｕｍｅｎｔ＿ａｓｓｅｔ＿ｉｄ、ｉｎｓｔｒｕｍｅｎｔ＿ｉｎｄｅｘ、ｉｎｓｔｒｕｍｅｎｔ＿ｉｎｄｅｘ＿ｖａｌｕｅ、ｉｎｓｔｒｕｍｅｎｔ＿ｅｘｃｈａｎｇｅ＿ｉｄ等。分析テーブル９１９ｉは、以下のようなフィールドを含むが、これに限らない：Ａｎａｌｙｔｉｃｓ＿ｉｄ、ａｎａｌｙｔｉｃｓ＿ｔｉｍｅ、ａｎａｌｙｓｔｉｃｓ＿ａｄ＿ｉｄ、ａｎａｌｙｔｉｃｓ＿ｓｏｕｒｃｅ＿ｉｄ、ａｎａｌｙｔｉｃｓ＿ｐｌｏｔ、ａｎａｌｙｔｉｃｓ＿ｐｒｅｊｅｃｔｉｏｎ、ａｎａｌｙｔｉｃｓ＿ｍａｐ、ａｎａｌｙｔｉｃｓ ＵＩ＿ｔｅｍｐｌａｔｅ、ａｎａｌｙｔｉｃｓ＿ｂｕｙ＿ｐｏｉｎｔ等。ニューステーブル９１９ｊは、以下のようなフィールドを含むが、これに限らない：ｎｅｗｓ＿ｉｄ、ｎｅｗｓ＿ｔｉｍｅ、ｎｅｗｓ＿ｄａｔｅ、ｎｅｗｓ＿ｔｉｔｌｅ、ｎｅｗｓ＿ｓｏｕｒｃｅ、ｎｅｗｓ＿ｇｅｏ、ｎｅｗｓ＿ｚｉｐｃｏｄｅ、ｎｅｗｓ＿ｔｙｐｅ、ｎｅｗｓ＿ｉｎｄｕｓｔｒｙ、ｎｅｗｓ＿ｔａｒｇｅｔ＿ａｕｄｉｅｎｃｅ、ｎｅｗｓ＿ｉｍｐａｃｔ＿ａｕｄｉｅｎｃｅ、ｎｅｗｓ＿ｄｅｓｃｒｉｐｔｉｏｎ、ｎｅｗｓ＿ｔａｇ等。市場データテーブル９１９ｋは、以下のようなフィールドを含むが、これに限らない：ｍａｒｋｅｔ＿ｄａｔａ＿ｆｅｅｄ＿ＩＤ、ａｓｓｅｔ＿ＩＤ、ａｓｓｅｔ＿ｓｙｍｂｏｌ、ａｓｓｅｔ＿ｎａｍｅ、ｓｐｏｔ＿ｐｒｉｃｅ、ｂｉｄ＿ｐｒｉｃｅ、ａｓｋ＿ｐｒｉｃｅ等。一実施形態において、市場データテーブルは、市場データフィードによって埋めることができる（例えば、Ｂｌｏｏｍｂｅｒｇ ＰｈａｔＰｉｐｅ、Ｄｕｎ ＆ Ｂｒａｄｓｔｒｅｅｔ、Ｒｅｕｔｅｒ Ｔｉｂ、Ｔｒｉａｒｃｈ等）。これは、例えば、Ｍｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ｔｅｍｐｌａｔｅ Ｌｉｂｒａｒｙ ａｎｄ Ｄｅａｌｉｎｇ Ｏｂｊｅｃｔ Ｔｅｃｈｎｏｌｏｇｙ リアルタイムツールキットＲｔｔ．Ｍｕｌｔｉを通じて実施できる。
一実施形態において、ＴＬＬデータベースは、他のデータベースシステムと通信する。例えば、ＴＬＬコンポーネントが分散データベース、クエリ、データアクセスを採用すると、ＴＬＬデータベースの組み合わせを単一データベースの統合データセキュリティレイヤとして取り扱うことができる。
一実施形態において、ユーザプログラムは、様々なユーザインタフェースを含むことができる。これらは、ＴＬＬを更新することができる。またアカウントは、環境やＴＬＬがサービスを提供する必要があるクライアントタイプに応じて、カスタムデータベーステーブルを必要とする場合がある。一意フィールドは、キーフィールドとして指定することができる。代替実施形態において、これらテーブルは、自身のデータベース及びデータベースコントローラ（すなわち各テーブルのデータベースコントローラ）に分離することができる。標準データ処理技術を用いて、何れかを更に複数のコンピュータシステム及び／又はストレージデバイスに分散することができる。同様に分散データベースコントローラの構成は、データベースコンポーネント９１９ａ〜ｋを統合し及び／又は分散させることにより、変更することができる。ＴＬＬは、データベースコントローラを介して、様々な設定、入力、パラメータをトラッキングするように構成することができる。
ＴＬＬデータベースは、コンポーネントコレクションの他のコンポーネントと通信することができる。ＴＬＬデータベースは、ＴＬＬコンポーネント、他のプログラムコンポーネント等と通信することができる。データベースは、他のノード及びデータに関する情報を含み、保持し、提供することができる。
＜ＴＬＬ＞
ＴＬＬコンポーネント９３５は、ＣＰＵが実行するプログラムコンポーネントである。一実施形態において、ＴＬＬコンポーネントは、先の図面で説明したＴＬＬ機能の任意及び／又は全組み合わせを備えることができる。ＴＬＬは、通信ネットワークを介して、情報、サービス、トランザクションにアクセスし、取得し、提供することができる。ＴＬＬの機能及び実施形態は、データ送信要求を減少させてより効率的なデータ構造とメカニズムを用いて送信及び格納することにより、ネットワーク効率を向上させる。その結果、より多くのデータをより短い時間で送信することができ、トランザクションに関するレインテンシーが減少する。多くの場合、ストレージ、送信時間、帯域幅要件、レインテンシー等の減少は、ＴＬＬの機能をサポートするため必要な性能と構造インフラを減少させ、更に多くの場合、コスト、エネルギ消費／要件を減少させ、ＴＬＬの基盤インフラの寿命を延ばす。これは、ＴＬＬの信頼性を高める追加的利点である。同様に多くの機能及びメカニズムは、ユーザが使用しアクセスし易いように設計され、これによりＴＬＬの機能セットを利用する対象者を広げることができる。この使いやすさにより、ＴＬＬの信頼性を高めることができる。また機能セットは、暗号コンポーネント９２０、９２６、９２８を通じて述べたように、向上したセキュリティを備えており、機能とデータに対するアクセスをより信頼性高くかつ安全にしている。
ＴＬＬコンポーネント９３５は、ＣＰＵが実行するプログラムコンポーネントである。一実施形態において、ＴＬＬコンポーネントは、先の図面で説明したＴＬＬ機能の任意及び／又は全組み合わせを備えることができる。ＴＬＬは、通信ネットワークを介して、情報、サービス、トランザクションにアクセスし、取得し、提供することができる。ＴＬＬの機能及び実施形態は、データ送信要求を減少させてより効率的なデータ構造とメカニズムを用いて送信及び格納することにより、ネットワーク効率を向上させる。その結果、より多くのデータをより短い時間で送信することができ、トランザクションに関するレインテンシーが減少する。多くの場合、ストレージ、送信時間、帯域幅要件、レインテンシー等の減少は、ＴＬＬの機能をサポートするため必要な性能と構造インフラを減少させ、更に多くの場合、コスト、エネルギ消費／要件を減少させ、ＴＬＬの基盤インフラの寿命を延ばす。これは、ＴＬＬの信頼性を高める追加的利点である。同様に多くの機能及びメカニズムは、ユーザが使用しアクセスし易いように設計され、これによりＴＬＬの機能セットを利用する対象者を広げることができる。この使いやすさにより、ＴＬＬの信頼性を高めることができる。また機能セットは、暗号コンポーネント９２０、９２６、９２８を通じて述べたように、向上したセキュリティを備えており、機能とデータに対するアクセスをより信頼性高くかつ安全にしている。
ＴＬＬコンポーネントは、ＴＬＬコンポーネントを介してビッド／取引要求（例えば、図２の２０３参照）を変換する。例えば、市場データコレクション９４２、ＰＯＰ割当９４３、ＰＯＰルーティング９４４、注文約定９４５等を、取引レコード（例えば、図２の２１８参照）等に変換し、ＴＬＬの使用は、レインテンシーアービトラージ及び／又はオーダブックアービトラージを抑制する。
ノード間の情報アクセスを可能にするＴＬＬコンポーネントは、標準開発ツール及び言語により開発することができる。例えば、以下を含むがこれらに限らない：Ａｐａｃｈｅコンポーネント、アセンブリ、ＡｃｔｉｖｅＸ、バイナリ実行ファイル、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋），Ｃ＃、及び／又は．ＮＥＴ、データベースアダプタ、ＣＧＩスクリプト、Ｊａｖａ，ＪａｖａＳｃｒｉｐｔ、マッピングツール、手続型及びオブジェクト指向開発ツール、ＰＥＲＬ，ＰＨＰ，Ｐｙｔｈｏｎ、シェルスクリプト、ＳＱＬコマンド、ウェブアプリケーションサーバ拡張、ウェブ開発環境及びライブラリ（例えば、Ｍｉｃｒｏｓｏｆｔ ＡｃｔｉｖｅＸ、Ａｄｏｂｅ ＡＩＲ、ＦＬＥＸ＆ＦＬＡＳＨ；ＡＪＡＸ；（Ｄ）ＨＴＭＬ；Ｄｏｊｏ、Ｊａｖａ；ＪａｖａＳｃｒｉｐｔ；ｊＱｕｅｒｙ（ＵＩ）；ＭｏｏＴｏｏｌｓ；Ｐｒｏｔｏｔｙｐｅ；ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ；Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）；Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）；ＳＷＦＯｂｊｅｃｔ；Ｙａｈｏｏ！ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ；等）、ＷｅｂＯｂｊｅｃｔｓ等。一実施形態において、ＴＬＬサーバは、暗号サーバを採用し、通信を暗号化及び復号化する。ＴＬＬコンポーネントは、コンポーネントコレクションの他のコンポーネント等と通信する。ＴＬＬコンポーネントは、多くの場合、ＴＬＬデータベース、ＯＳ、他のプログラムコンポーネント等と通信する。ＴＬＬは、プログラムコンポーネント、システム、ユーザ、及び／又はデータ通信、要求、及び／又はレスポンスを含み、通信し、生成し、取得し、及び／又は提供する。
＜分散型ＴＬＬ＞
ＴＬＬノードコントローラコンポーネントの構造及び／又は動作は、任意の方法で組み合わせ、連結し、及び／又は分散させて、開発及び／又は配置を進めることができる。同様にコンポーネントコレクションは、任意の方法で組み合わせて、配置及び／又は開発を進めることができる。これを実現するため、コンポーネントを共通コードベースに統合し、又はオンデマンドでコンポーネントを動的に読みだして統合することができる。
ＴＬＬノードコントローラコンポーネントの構造及び／又は動作は、任意の方法で組み合わせ、連結し、及び／又は分散させて、開発及び／又は配置を進めることができる。同様にコンポーネントコレクションは、任意の方法で組み合わせて、配置及び／又は開発を進めることができる。これを実現するため、コンポーネントを共通コードベースに統合し、又はオンデマンドでコンポーネントを動的に読みだして統合することができる。
コンポーネントコレクションは、標準データ処理及び／又は開発技術を介して、様々な態様で統合し及び／又は分散させることができる。プログラムコンポーネントコレクション内のプログラムコンポーネントの複数のインスタンスは、単一ノード上及び／又は複数ノードにまたがってインスタンス化し、ロードバランス及び／又はデータ処理技術を通じてパフォーマンスを向上させることができる。更に単一インスタンスを複数コントローラ及び／又はストレージデバイス、例えば、データベースに分散させることができる。全てのプログラムコンポーネントインスタンス及び連動するコントローラは、標準データ処理通信技術を介してこれを実施できる。
ＴＬＬコントローラの構成は、システム配置に依拠する。予算、性能、位置、及び／又はハードウェアリソース等の要因は、配置要件と構成に影響する。構成がより統合され及び／又は統合プログラムコンポーネントになるか否かによらず、より分散したプログラムコンポーネントになるか否かによらず、及び／又は統合コンポーネントと分散コンポーネントの組み合わせになるか否かによらず、データを通信し、取得し、及び／又は提供することができる。プログラムコンポーネントコレクションから共通コードベースへ統合したコンポーネントのインスタンスは、データを通信し、取得し、及び／又は提供することができる。これは、アプリケーション内データ処理通信技術を通じて実現できる。例えば、以下のようなものであるが、これに限らない：データ参照（例えば、ポインタ）、内部メッセージング、オブジェクトインスタンス変数通信、共有メモリ空間、変数引き渡し等。
コンポーネントコレクションコンポーネントが離散し、分割され、及び／又は互いに外部コンポーネントである場合、他のコンポーネントに対するデータ通信、取得、及び／又は提供は、アプリケーション間データ処理通信技術を介して実現できる。例えば、以下を含むがこれに限らない：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）情報引き渡し；（Ｄｉｓｔｒｉｂｕｔｅｄ）Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ（（Ｄ）ＣＯＭ）、（Ｄｉｓｔｒｉｂｕｔｅｄ）Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ（（Ｄ）ＯＬＥ）等）、Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＯＲＢＡ）、Ｊｉｎｉ ｌｏｃａｌ ａｎｄ ｒｅｍｏｔｅ ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）、Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ）、ＳＯＡＰ、プロセスパイプ、共有ファイル等。アプリケーション間通信又は単一コンポーネントのメモリ空間内でアプリケーション間通信として分離コンポーネント間で送信されたメッセージは、文法を生成しパースすることにより実施される。文法は、ｙａｃｃ、ＸＭＬ等の開発ツールを用いて開発できる。これにより、文法生成とパース機能を実現し、コンポーネント間の通信メッセージの基盤を形成することができる。
例えば、文法は、以下のようなＨＴＴＰ ｐｏｓｔコマンドのトークンを認識するように、構成することができる：
ｗ３ｃ −ｐｏｓｔ ｈｔｔｐ：／／．．．Ｖａｌｕｅ１
Ｖａｌｕｅ１は、パラメータとして認識される。「ｈｔｔｐ：／／」は、文法シンタックスの一部であり、その後は、ｐｏｓｔ値とみなすことができるからである。同様にこの文法において、変数「Ｖａｌｕｅ１」は、「ｈｔｔｐ：／／」ｐｏｓｔコマンドに挿入して送信することができる。文法シンタックスそのものは、構造化データとして提示することができる。この構造化データを解釈及び／又は用いて、パースメカニズムを生成することができる（例えば、ｌｅｘ、ｙａｃｃ等が処理するシンタックス記述テキストファイル）。パースメカニズムを生成及び／又はインスタンス化すると、パースメカニズムは、構造化データを処理し、及び／又はパースする。構造化データは、例えば、以下のようなものであり、これらに限らない：文字（例えば、タブ）区切りテキスト、ＨＴＭＬ、構造化テキストストリーム、ＸＭＬ等。別実施形態において、アプリケーション間処理プロトコル自身が、統合された及び／又は容易に利用できるパーサ（例えば、ＪＳＯＮ，ＳＯＡＰ等のパーサ）を備え、これらを用いてデータをパース（例えば、通信）できる。更にパース文法は、メッセージパースに用いてもよく、データベース、データコレクション、データストア、構造化データ等のパースに用いてもよい。所望する構成は、コンテキスト、環境、システム配置要件に依拠する。
ｗ３ｃ −ｐｏｓｔ ｈｔｔｐ：／／．．．Ｖａｌｕｅ１
Ｖａｌｕｅ１は、パラメータとして認識される。「ｈｔｔｐ：／／」は、文法シンタックスの一部であり、その後は、ｐｏｓｔ値とみなすことができるからである。同様にこの文法において、変数「Ｖａｌｕｅ１」は、「ｈｔｔｐ：／／」ｐｏｓｔコマンドに挿入して送信することができる。文法シンタックスそのものは、構造化データとして提示することができる。この構造化データを解釈及び／又は用いて、パースメカニズムを生成することができる（例えば、ｌｅｘ、ｙａｃｃ等が処理するシンタックス記述テキストファイル）。パースメカニズムを生成及び／又はインスタンス化すると、パースメカニズムは、構造化データを処理し、及び／又はパースする。構造化データは、例えば、以下のようなものであり、これらに限らない：文字（例えば、タブ）区切りテキスト、ＨＴＭＬ、構造化テキストストリーム、ＸＭＬ等。別実施形態において、アプリケーション間処理プロトコル自身が、統合された及び／又は容易に利用できるパーサ（例えば、ＪＳＯＮ，ＳＯＡＰ等のパーサ）を備え、これらを用いてデータをパース（例えば、通信）できる。更にパース文法は、メッセージパースに用いてもよく、データベース、データコレクション、データストア、構造化データ等のパースに用いてもよい。所望する構成は、コンテキスト、環境、システム配置要件に依拠する。
例えば、幾つかの実施例では、ＴＬＬコントローラは、ＰＨＰスクリプトを実行する。ＰＨＰスクリプトは、情報サーバを通じてＳｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ（ＳＳＬ）ソケットサーバを実装する。情報サーバは、クライアントがデータを送信するサーバポート上で到着する通信を待ち受ける。フォーマットは、例えば、ＪＳＯＮ形式である。到着した通信を識別すると、ＰＨＰスクリプトは、クライアントデバイスから到着メッセージを読み取り、ＪＳＯＮエンコードされたテキストデータをパースし、ＪＳＯＮエンコードされたテキストデータから情報を抽出してＰＨＰスクリプト変数に格納し、そのデータ（例えば、クライアント識別情報等）を保存、及び／又は抽出された情報は、リレーショナルデータベースに格納されＳｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ（ＳＱＬ）を用いてアクセスできる。ＰＨＰ／ＳＱＬコマンドの形式で記述され、ＪＳＯＮエンコード入力データをクライアントデバイスからＳＳＬ経由で受け取り、そのデータを抽出して変数に格納し、データベースに格納するプログラムリストを、以下に示す。
以下のリソースを用いて、ＳＯＡＰパーサに関する実施形態を提供することができる： ｈｔｔｐ：／／ｗｗｗ．ｘａｖ．ｃｏｍ／ｐｅｒｌ／ｓｉｔｅ／ｌｉｂ／ＳＯＡＰ／Ｐａｒｓｅｒ．ｈｔｍｌ ｈｔｔｐ：／／ｐｕｂｌｉｃｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｔｉｖｉｈｅｌｐ／ｖ２ｒ１／ｉｎｄｅｘ．ｊｓｐ？ｔｏｐｉｃ＝／ｃｏｍ．ｉｂｍ．ＩＢＭＤＩ．ｄｏｃ／ｒｅｆｅｒｅｎｃｅｇｕｉｄｅ２９５．ｈｔｍ 他のパーサ実施例は、以下である： ｈｔｔｐ：／／ｐｕｂｌｉｃｌｉｂ．ｂｏｕｌｄｅｒ．ｉｂｍ．ｃｏｍ／ｉｎｆｏｃｅｎｔｅｒ／ｔｉｖｉｈｅｌｐ／ｖ２ｒ１／ｉｎｄｅｘ．ｊｓｐ？ｔｏｐｉｃ＝／ｃｏｍ．ｉｂｍ．ＩＢＭＤＩ．ｄｏｃ／ｒｅｆｅｒｅｎｃｅｇｕｉｄｅ２５９．ｈｔｍ。 これら全ては、参照により本願に組み込まれる。
＜ファシリテーションクロスオーダ＞
一部の投資家、特に大規模な機関投資家又は資産家は、比較的短期間に多数の証券を買い又は売る必要があることがある。しかしながら、市場では、このような大規模な取引を直ちに充足させるために十分な反対側注文が存在しない場合がある。このような大規模な取引が市場に直接的に送信された場合、少なくとも短期的な価格の動きが取引投資家にとって不利になることがある。例えば、大規模な売り注文は、売り価格を引き下げ、大規模な買い注文は、価格を押し上げる。
一部の投資家、特に大規模な機関投資家又は資産家は、比較的短期間に多数の証券を買い又は売る必要があることがある。しかしながら、市場では、このような大規模な取引を直ちに充足させるために十分な反対側注文が存在しない場合がある。このような大規模な取引が市場に直接的に送信された場合、少なくとも短期的な価格の動きが取引投資家にとって不利になることがある。例えば、大規模な売り注文は、売り価格を引き下げ、大規模な買い注文は、価格を押し上げる。
このため、資本市場業界において、ブローカは、顧客投資家へのサービスとして、ブローカの顧客投資家から証券を買い又は顧客投資家に証券を売ることがある。証券を急いで売買する必要がある典型的な状況では、顧客投資家は、取引を速やかに完了する代償として、割増金（マークアップ）を支払い又は割引価格（ディスカウント）で売ることに同意する。ブローカは、通常、自らの在庫から顧客投資家に証券を売り（又はショートポジションを引き受け）、或いは顧客から証券を買い、ロングポジションとして自己の在庫に追加する。ブローカが新しいショート／ロング証券ポジションを取っている場合、ポジションがクローズされるまで、ブローカは、市場リスクに晒される。
このようなリスクを軽減するために、新しいポジションを取るブローカ内の取引オペレーション（「リスクデスク」とも呼ばれる）は、可能な限り速やかにポジションをヘッジし及び／又は解消することによって、損失の可能性を最小限に抑え及び／又は証券を売買するために顧客が支払ったマークアップ／ディスカウントによって得られた利益を保存しようとする。しかしながら、従来の手法では、ブローカは、（ａ）まず、顧客と取引し、（ｂ）可能な限り新しいポジションをクローズするために取引機会を求めて公開市場を回り、（ｃ）残りのポジションについては、市場におけるプリンシパル取引（principal trade：相対取引）をプリントする。このような複数ステップのプロセスは、時間がかかり、市場がブローカにとって不利な方向に急速に動いた場合、ブローカに遅れが生じる可能性がある
例えば、顧客投資家がＭＳＦＴ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐ．）の購入を望んだとする。ＭＳＦＴの現在の売値は、＄３４．１０の相場が付いているとする。ブローカは、ＭＳＦＴの１００，０００株を＄３４．１５、すなわち５セントのマークアップで直ちに売ることに同意する。ブローカは、ＭＳＦＴの株式を保有していないので、１００，０００株を売る必要がある。ブローカは、ショート１００，０００ＭＳＦＴ＠＄３４．１５を顧客投資家に売る取引を約定させたため、後に市場で１００，０００株のＭＳＦＴを買うことによってショートポジションをカバーする必要がある。価格が＄３４．１０の現在の売値が上昇した場合、ブローカの５セントのサービス手数料（マークアップ）が損なわれ、ブローカの利益は、減少する。最悪の場合、価格が＄３４．１５を超えると、ブローカは、顧客投資家に売った価格よりも高い価格で株式を買うことになり、ブローカは、損失を被る可能性がある。典型的には、顧客投資家は、取引が大規模であり、市場リスクがより大きくなるため、ブローカのリスクサービスを利用し、マークアップ／マークダウンを支払う。ブローカは、損失を回避し利益を確保するために十分な余地を有するマークアップ／マークダウンの価格を設定する必要がある。
本発明の実施形態によれば、ファシリテーションクロスオーダ（Facilitation Cross Order：ＦＣＯ）タイプは、リスクトレーダが顧客投資家の取引要求を実現する一方で、同時に、市場のオーダブックにおける利用可能な相殺流動性（offsetting liquidity）、及び潜在的に遠隔市場の相殺流動性に対して約定を行うことにより、リスクトレーダ自身のリスクを同時に減少させることを可能にする。リスクトレーダは、顧客投資家との取引条件を交渉し、単一のステップで、ＦＣＯを使用することによって、上述した３ステップのプロセスを完了することができる上に、リスクトレーダのリスクを低めることができる。すなわち、リスクトレーダは、顧客投資家から受信した売買注文指示に基づいて、売買クロス（buy/sell cross）を入力する。例えば、顧客投資家が株式を買う／売ることを望む場合、ブローカは、全ての取引パラメータと共に売買ＦＣＯ（buy/sell FCO）を市場に入力する。ＦＣＯが入力されると、市場は、まず、売買ＦＣＯを使用して市場のオーダブック（及び／又は他の市場のオーダブック）をテストし、顧客投資家の指値まで高め／低めて、オーダブック内の適格な株式に対して自動的に注文を約定させる。エージェントベースで（すなわち、顧客投資家に代わって取引を行い）市場で入手可能な全ての株式を完全に枯渇させると、ＦＣＯは、未約定株式の残高のプリンシパル取引を直ちに自動的にプリントする。ＦＣＯは、オプションとして、残存する株式を他の市場に引き渡して、これらの市場のオーダブック上の相殺可能な株式との約定を試みてもよい。
図１１Ａ〜図１１Ｃは、本発明の一実施形態に基づくファシリテーションクロスオーダの例を示す。
ブローカの顧客投資家が１００，０００株のＭＳＦＴの購入を望む上述のシナリオと同じシナリオを使用する。ＭＳＦＴの現在の売値は、公開市場で＄３４．１４の相場が付いているとする。ブローカは、ＭＳＦＴの１００，０００株を＄３４．１５、すなわち５セントのマークアップで直ちに売ることに同意する。図１１Ａに示すように、ステップ１１０１では、Ｆｉｒｍ ＡＢＣ（すなわち、顧客投資家）の注文が、取引日等の一定期間にわたって取引の記録及び取引の詳細を追跡し管理するブローカの注文控え帳（order blotter）に到着する。これは、ＭＳＦＴの１００，０００株を＄３４．１５で直ちに買う買い側の注文である。
ブローカは、ＭＳＦＴの株式を在庫として保有していないので、潜在的に１００，０００株を売る必要がある。図１１Ｂに示すように、ステップ１１０２において、ブローカは、取引端末上の買いＦＣＯのパラメータを記入する。取引端末は、上述のＴＬＬ／ＰＯＰインフラ及び市場取引所の電子取引システムに接続してもよい。特に、電子取引システムは、ファシリテーションクロスオーダタイプのための一連の動作を行うように構成又はプログラムしてもよい。ここでは、図１１Ｂは、ＦＣＯの注文パラメータを入力するための例示的なユーザインタフェース（ＵＩ）の一部を示す。例えば、図１１Ｂの左から右へ、ブローカが第１のメニューをクリックして所望の動作として「約定」（すなわち取引約定）を選択すると、第２のメニューが表示され、ブローカが注文をクロスすることを示す「ブローカ約定」を選択することができる。次に、「ファシリテーションクロス」ウィンドウがポップアウト又はその他の手法で表示される。このウィンドウには、関連する注文パラメータが入力される幾つかのデータフィールド、例えば、（ａ）買いＦＣＯ又は売りＦＣＯのどちらを希望するか、（ｂ）取引の数量、（ｃ）取引される証券シンボル、（ｄ）指値、（ｅ）クロスタイプ、及び（ｆ）ブローカが取引注文を約定するキャパシティ等が含まれる。ここでは、ブローカは、Ｘ−タイプフィールドで「ＩＥＸ」を選択し、キャパシティフィールドで「Ｐｒｉｎｃｉｐａｌ（プリンシパル取引）」を選択する。これらは、単なる例示的な注文パラメータであることは、当業者にとって明らかである。必要な全てのパラメータを入力すると（又はデフォルト値を選択すると）、ブローカは、「クロス」ボタンをクリックしてＦＣＯ注文設定を完了する。
次に、ステップ１１０３（図１１Ｃ）において、ＩＥＸグループが提供する取引プラットフォーム等の市場に買いＦＣＯ注文が提出される。図１１Ｃは、例示的なＭＳＦＴの仮想ＩＥＸオーダブックの一部も示している。ここでは、市場は、自らのオーダブックにおいて、１株あたり＄３４．１４で、２５，０００株の売りを有している。買いＦＣＯに応じて、市場は、直ちに、そのオーダブック上の「エージェント」キャパシティ内の株に対して、１株あたり＄３４．１４で、ＭＳＦＴの２５，０００株の買いを約定し、１株あたり＄３４．１５で、ＭＳＦＴの５０，０００株のショートを売る「プリンシパル」取引を即座にプリントする。これにより、ブローカは、＄３４．１５における７５，０００株のプリンシパル取引と共に、エージェント取引を通じて投資家により有利な価格（＄３４.１４対＄３４.１５）を提供でき、現時点で、１００，０００株ではなく、７５，０００株のみのショートポジションをカバーすればよく、市場リスクに晒される危険性が低下している。
＜半公開市場＞
買い手及び売り手が取引される資産に対する買い及び提供を行う既存の市場は、通常、２つの基本的な構造を有する。「公開（lit）」市場では、利用可能なビッド及びオファーは、コンピュータネットワークを介して自動的に相場及び取引情報を配信するウェブページ及び取引ソフトウェアユーザインタフェース等のチャネルを介して、全ての参加者に開示される。市場の他の形態は、買い情報又は提供情報が公開されていない「非公開（dark）」市場である。「非公開」市場では、有効な反対側注文に対してこの参加者の注文が約定されるまでは、参加者は、潜在的な反対側当事者の利用可能な注文（例えば、価格及びサイズ）に関する情報を受け取らない。金融市場では、これらの非公開市場は、「ダークプール」と呼ばれ、一部は、公開株、オプション、先物取引所等の伝統的な公開市場に匹敵する取引の主要な中心になっている。
買い手及び売り手が取引される資産に対する買い及び提供を行う既存の市場は、通常、２つの基本的な構造を有する。「公開（lit）」市場では、利用可能なビッド及びオファーは、コンピュータネットワークを介して自動的に相場及び取引情報を配信するウェブページ及び取引ソフトウェアユーザインタフェース等のチャネルを介して、全ての参加者に開示される。市場の他の形態は、買い情報又は提供情報が公開されていない「非公開（dark）」市場である。「非公開」市場では、有効な反対側注文に対してこの参加者の注文が約定されるまでは、参加者は、潜在的な反対側当事者の利用可能な注文（例えば、価格及びサイズ）に関する情報を受け取らない。金融市場では、これらの非公開市場は、「ダークプール」と呼ばれ、一部は、公開株、オプション、先物取引所等の伝統的な公開市場に匹敵する取引の主要な中心になっている。
但し、何れのモデルも欠点を有する。公開市場では、参加者の注文の表示は、市場への需要／供給に関する情報を提供し、反対側当事者がこれに反応して価格を変更すること（「情報漏洩」とも呼ばれる）を行う可能性があり、最初の参加者が取引できる価格が不利になる場合がある。例えば、投資家がＸＹＺ株を＄１０．００で１００，０００株を買う注文を入力すると、現在＄１０．０１で１０，０００株をオファーしている売り手は、１０，０００株の供給より遙かに大きい１００，０００株の需要を有する大規模な買い手が存在することを知る。この結果、売り手は、買い手が自らの要求を満たすために更に支払う意思を有することを見越して、提示価格を＄１０．０５に引き上げることができる。一方、非公開市場では、投資家の１００，０００株の買いは、売り手には知られず、同様に、売り手の売り注文も買い手には知られない。この結果、非公開市場の参加者は、反対側の関心の程度を判断することが難しく、このため、情報漏洩が低減し、潜在的な反対側当事者の売り／買いの関心に関する知識ではなく、買い手／売り手自身の「公正な価値評価」における売買の意思に応じた注文の価格設定が促される。
ここに開示する本発明の実施形態は、市場における各参加者の現在の有効な注文に基づいて、オーダブックデータが参加者に選択的に配信される「半公開（semi-lit）」市場を構築するためのモデルを提案する。
図１２は、本発明の一実施形態に基づく半公開市場を実現するための例示的な方法を示すフローチャートである。
ステップ１２０２において、確定注文のみを許可する電子取引の半公開市場を設定することができる。市場は、参加者がネットワークを介して接続されている電子取引システムとして実現することができ、ここには、取引されるアイテムのセットがある。これらのアイテムは、金融商品（証券、商品、デリバティブ等）又は電子的に取引可能な他のアイテム（スポーツ及び／又はエンターテインメントイベントのチケット及び／又はオンラインゲームの仮想アイテム等）であってもよい。市場における特定の商品の各注文は、単位あたり所与の価格（「注文価格」）で複数単位（「オーダサイズ」）のアイテムを買うためのビッド又は売るためのオファーである。
全ての注文は、注文の入力によって、注文がキャンセルされるか期限切れになるまで、注文価格で注文サイズを取引することが約束される確定注文であることが好ましい。取引は、価格及びサイズに基づいて２つの注文がマッチングした場合、すなわち、「関心の表示（indications of interest）」、「オープン注文（discretionary orders）」、「交渉可能な注文（negotiable orders）」、「不確定相場（non-firm quotations）」又はこの他の不確定注文が市場にない場合、直ちに約定され、注文をキャンセル又は期限切れにできる唯一の場合は、注文サイズ及び注文価格が一致する反対側注文とマッチングされる以前のみである。
ステップ１２０４において、各アイテムについて、市場は、注文がこの参加者に反対側注文に関する特定の情報にアクセスする資格を与えることができる「閾値価格」を設定することができる。
本発明の好ましい実施形態では、閾値価格は、１又は複数の公開市場（これは、注文が提出されている現在の半公開市場を含んでもよく、含まなくてもよい）から受信した相場に基づいて決定される。例えば、各アイテムについて、閾値価格は、何れかの公開市場（又は公開市場の集合体）で表示されたこのアイテムの最高価格の買い注文と、何れかの公開市場（又は公開市場の集合体）で表示されたこのアイテムの最低価格の売り注文との平均としてもよい。この実施形態は、基準価格を必要とするので、アイテムの閾値価格の算出については、公開市場の使用が好ましい場合がある。
本発明の他の実施形態によれば、公開市場が存在しない場合、又は半公開市場が有益な結果を得るための他の方法を発見した場合、他の方法によって閾値価格を設定してもよい。例えば、市場で約定された取引の最後に報告された取引価格を参照して、閾値価格を設定してもよい。
本発明の更なる実施例によれば、取引当事者のための閾値価格は、当事者の有効注文のサイズの関数としてもよい。例えば、当事者の注文の規模が大きいほど、当事者が取引情報をフィッシングしたり、不公正取引戦略を取ったりする可能性が低くなる。したがって、当事者のための閾値価格要件をより緩和してもよい。逆に、注文が小規模である市場参加者については、閾値価格要件をより厳しくしてもよい
次に、ステップ１２０６において、半公開市場において参加者から新規注文が受注された場合、又は基準価格の変化に応じて閾値価格が変化した場合、注文が有効であるか否か、及び有効であれば注文価格が閾値価格要求を満たすか否かを判定してもよい。すなわち、注文価格は、対応する閾値価格と比較される。
注文価格が閾値価格よりも「劣っている」（又は積極的でない）場合、すなわち、買いの有効注文については、この価格が閾値価格よりも低い場合、又は売りの有効注文については、この価格が基準価格よりも高い場合、注文価格は、閾値価格要求を満たさない。この場合、ステップ１２０８において、この注文を提出した参加者は、反対側注文のデータを受け取るためのアクセスが拒否される。
一方、注文価格が閾値価格よりも「優れている」（又は積極的である）場合、すなわち、買いの有効注文については、この価格が閾値価格よりも高い場合、又は売りの有効注文については、この価格が基準価格よりも低い場合、注文価格は、閾値価格要求を満たす。この場合、ステップ１２１０において、注文を行った参加者には、半公開市場において、反対側注文に関するデータを受け取る資格が与えられる。換言すれば、以前は、公開されていなかった注文が参加者に公開されることになる。資格が与えられた参加者は、自らの注文の反対側の注文であってサイズがこの参加者の注文サイズ以下である全ての注文の価格とサイズを受け取る（すなわち、買い注文を行った参加者は、売り注文に関するデータを受け取り、売り注文を行った参加者は買い注文に関するデータを受け取る）。受注データの更新は、注文の約定又はキャンセル、若しくは閾値価格の変化により、参加者の注文が適格ではなくなるまで、継続的に参加者に配信される。
このようにして、参加者が表明し、約束した取引の意思に基づいて、又はこれらの意思に比例して、参加者に情報が提供される。注文サイズが大きくなり、注文価格がより積極的になるほど、参加者に提供される情報及び取引への露出が増え、したがって、反対側注文に関する詳細な情報へのアクセスによって報われる。反対側の取引意思に関する情報を得るために、情報を提示し、取引の意思を表明させるこの要求は、情報の非対称性及び需給不均衡の知識に基づく取引行為を低減させる。
本発明の幾つかの実施形態によれば、買い注文及び売り注文の両方に同じ閾値価格を設定することに代えて、買い注文及び売り注文に対してそれぞれ異なる閾値価格を設定することができる。
図１３は、本発明の一実施形態に基づく半公開市場における情報の選択的配信を説明するための例示的なオーダブックを示している。このオーダブックは、バンクオブアメリカ（Bank of America）の普通株式（ティッカシンボル：ＢＡＣ）の仮想取引のためのものである。既に存在しているＮＢＢは、＄１４．９８であり、ＮＢＯは、＄１５．０２であるため、ミッドポイントは、＄１５．００であり、これを閾値価格として使用することができる。
トレーダＡが＄１５．００で１，０００株の売り注文を提出すると、この注文は、（＄１５．００の閾値価格と同じであるため）＄１５．００でオーダブックに記載され、トレーダＡには、１，０００株以下の全ての買い注文を見る権利が与えられる（ここでは、＄１４．８５における２，０００株の買い注文を除く全ての買い注文、又はこれに代えて、＄１４．８５の買い注文のうち１，０００株のみが他の適格な買い注文と共にトレーダＡに表示される）。
同様に、トレーダＢが２，０００株のＢＡＣについて＄１４．９９で更に積極的な売り注文を提出した場合、この注文は、（＄１５．００の閾値価格よりも積極的であるため）＄１４．９９でオーダブックに記載され、トレーダＢは、２，０００株以下の全ての買い注文を見る資格を得る（ここでは、リストされた全ての買い注文が表示される）。
他の例として、トレーダＣが＄１５．０２で２，０００株のＢＡＣについて買い注文を提出した場合、９００株の買い注文が＄１５．０２における８００株の売り注文と約定する。残りの１，２００株は、＄１５．０２でオーダブックに記載される。そして、トレーダＣは、１，２００株（又はオプションとして２，０００株）以下の全てのアスクを見る資格が与えられる。幾つかの実施形態によれば、１，２００株（又は２，０００株）以上の株式のアスク注文がある場合、トレーダＣが最大１，２００株（又は２，０００株）までのアスク注文を見られるようにしてもよく、これに代えて、又はトレーダＣが見ることができる注文は、トレーダＣが１，２００株（又は２，０００株）より大きなサイズのアスクが存在することを推定できないように変更してもよい。
本発明の他の実施形態によれば、異なる売買注文に対して異なる閾値価格をそれぞれ設定することができる。例えば、ここでは、買い注文の第１の閾値価格を＄１４．９９に設定し、売り注文の第２の閾値価格を＄１５．０１に設定してもよい。この結果、＄１４．９９以上の有効なビッド又は＄１５．０１以下の有効なアスクを行っている取引参加者には、（注文サイズ制限の対象となる）反対側注文へのアクセス権が付与される。
様々な課題を解決し技術を進めるため、本願（カバーページ、タイトル、ヘッダ、技術分野、背景技術、概要、図面の簡単な説明、発明を実施するための形態、特許請求の範囲、要約、図面、添付書類等）は、特許請求する発明を実施する様々な形態を説明するためのものである。本発明の利点及び特徴は、実施形態の代表例のみを示しており、それ以外を排除するものではない。これらは、特許請求範囲の原理の理解を促し教示するためのみのものである。これらは、特許請求する発明の全てを表しているものではないことは明らかである。したがって、本発明の一部は、本明細書には、記載されていない。本発明の特定部分の代替実施形態は、記載していない場合もあり、その代替実施形態は、特許請求範囲から除外されたものと解釈すべきではない。それら実施形態は、本発明と同じ原理を備え等価なものである。したがって、その他の実施形態を利用でき、本発明の範囲及び／又は原理から逸脱することなく機能的、論理的、動作的、組織的、構造的、及び／又はトポロジー的変更が可能であることは明らかである。全ての実施例及び／又は実施形態は、本明細書全体を通じて非限定的なものである。
また、実施形態の説明の省略は、紙面を節約し繰返しを避けるため以外のものとみなすべきではない。例えば、図面等に記載したデータフローシーケンス、プログラムコンポーネント（コンポーネントコレクション）、他のコンポーネント、及び／又は機能セットの組み合わせの論理及び／又はトポロジー構造は、固定された動作順序及び／又は配置に限定されるものではなく、説明した順序は、例示的であり等価で順序に関係しないものも本開示に含まれると解釈すべきである。更に、これら特徴は、順次実行のみに限定されるものではなく、非同期、一斉、平行、同時、同期等で実行する任意個数のスレッド、プロセス、プロセッサ、サービス、サーバ等も本開示の範囲内であることは明らかである。これらのうちの幾つかの特徴は、単一実施形態において同時に存在できないという意味において、相互矛盾することもある。同様に、幾つかの特徴は、本発明の一側面に対して適用できるものもあり、他の側面に対して適用できないものもある。出願人は、それら特許請求していない発明の全権利を留保する。これは、その発明を特許請求し、別出願し、継続出願し、一部継続出願し、及び／又は分割出願する権利を含む。本発明の利点、実施形態、実施例、機能、特徴、論理、動作、組織、構造、トポロジーに関する側面は、特許請求範囲が定義する本発明の限定、又は特許請求範囲の等価物に対する限定とみなすべきではないことは明らかである。ＴＬＬのニーズ及び／又は特徴に応じて、個人及び／又は企業ユーザ、データベース構成及び／又は関係モデル、データタイプ、データ通信及び／又はネットワークフレームワーク、シンタックス構造、すなわちＴＬＬの実施形態は、柔軟にカスタマイズ実装できることは明らかである。例えば、ＴＬＬの側面は、データネットワーク帯域幅管理に合わせることができる。ＴＬＬの様々な実施形態は、電子取引プラットフォームに関するものであるが、本実施形態は、様々な他のオークションベースシステム、アプリケーション、及び／又は実装のために容易に構成及び／又はカスタマイズできることは明らかである。
Claims (15)
- 半公開市場環境における電子取引のためのコンピュータ実装した方法であって、
電子取引システム内でオーダブックを維持するステップであって、前記電子取引システムは、（ａ）通信インタフェースを介してまたはクライアントゲートウェイを介して取引注文を受信して前記取引注文を実行するように構成されたマッチングエンジン、（ｂ）前記オーダブックを記録するように構成された記憶媒体、（ｃ）電子データを取引参加者との間で送受信するインタフェース、を備える、ステップ、
少なくとも１つのコンピュータプロセッサにより、前記オーダブックの電子情報を前記取引参加者に対して条件付きで配信することを規制するステップであって、
取引参加者によって提出されたオーダの少なくとも１つの価格パラメータと、規定の閾値価格点との比較に基づいて、前記取引参加者が前記オーダブックの選択された部分にアクセスすることを許可するか否かを判定するステップ、
取引参加者との間で電子データを送受信する前記インタフェース上で、前記判定に基づいて、前記取引参加者にオーダブックデータを選択的に開示し又は前記オーダブックデータを隠すことにより、前記電子取引システムにおいて新たな半公開市場を実装するステップ、
により前記規制を実施するステップ、
を有する方法。 - 前記方法はさらに、前記取引参加者によって提出された前記注文の前記価格が前記閾値価格点と同じか又はこれよりも積極的である場合、前記取引参加者が前記オーダブックの反対側部分にアクセスすることを可能にするステップを有し、
前記オーダブックの反対側部分は、前記取引参加者によって提出された前記注文と同じ対象に関するものである、
請求項１記載の方法。 - 前記取引参加者によって提出された前記注文のサイズ以下のサイズの反対側取引のみが前記取引参加者によるアクセスを可能にされる請求項２記載の方法。
- 前記閾値価格は、前記同じ対象について公表されたビッド価格及びアスク価格に基づいて予め決定される請求項３記載の方法。
- 前記閾値価格は、前記同じ対象について公表された最高ビッド価格と、最低アスク価格との平均である請求項４記載の方法。
- 前記閾値価格点は、買い注文のための第１の閾値価格と、売り注文のための第２の閾値価格とを含む請求項２記載の方法。
- 前記方法はさらに、
前記取引参加者によって提出された前記注文が有効な確定注文であるか否かを判定するステップ、
前記注文が有効な確定注文である場合にのみ、前記取引参加者が前記オーダブックの前記選択された部分にアクセスすることを可能にするステップ、
を有する請求項１記載の方法。 - 半公開市場環境における電子取引のためのコンピュータ実装した装置であって、
取引参加者から取引注文を受信し前記取引注文を実行するように構成されたマッチングエンジン、
オーダブックを維持するように構成された少なくとも１つのコンピュータプロセッサ、
前記オーダブックを記録するように構成された記憶媒体、
前記取引参加者との間で電子データを送受信するように構成された通信インタフェース、
を備え、
前記少なくとも１つのコンピュータプロセッサは、前記オーダブックの電子情報を前記取引参加者に対して条件付きで配信することを規制するステップであって、
取引参加者によって提出されたオーダの少なくとも１つの価格パラメータと、規定の閾値価格点との比較に基づいて、前記取引参加者が前記オーダブックの選択された部分にアクセスすることを許可するか否かを判定するステップ、
取引参加者との間で電子データを送受信する前記インタフェース上で、前記判定に基づいて、前記取引参加者にオーダブックデータを選択的に開示し又は前記オーダブックデータを隠すことにより、電子取引システムにおいて新たな半公開市場を実装するステップ、
により前記規制を実施するように構成されている、
装置。 - 前記装置はさらに、前記取引参加者によって提出された前記注文の前記価格が前記閾値価格点と同じか又はこれよりも積極的である場合、前記取引参加者が前記オーダブックの反対側部分にアクセスすることを可能にするように構成されており、
前記オーダブックの反対側部分は、前記取引参加者によって提出された前記注文と同じ対象に関するものである、
請求項８記載の装置。 - 前記取引参加者によって提出された前記注文のサイズ以下のサイズの反対側取引のみが前記取引参加者によるアクセスを可能にされる請求項９記載の装置。
- 前記閾値価格は、前記同じ対象について公表されたビッド価格及びアスク価格に基づいて予め決定される請求項１０記載の装置。
- 前記閾値価格は、前記同じ対象について公表された最高ビッド価格と、最低アスク価格との平均である請求項１１記載の装置。
- 前記閾値価格点は、買い注文のための第１の閾値価格と、売り注文のための第２の閾値価格とを含む請求項９記載の装置。
- 前記装置はさらに、
前記取引参加者によって提出された前記注文が有効な確定注文であるか否かを判定し、
前記注文が有効な確定注文である場合にのみ、前記取引参加者が前記オーダブックの前記選択された部分にアクセスすることを可能にする、
ように構成されている請求項８記載の装置。 - 半公開市場環境における電子取引システムであって、
通信インタフェースまたはクライアントゲートウェイを介して取引注文を受信し前記取引注文を実行するように構成された少なくとも１つのコンピュータプロセッサを備えるマッチングエンジン、
前記マッチングエンジンに接続された記憶媒体、
前記マッチングエンジンと接続して取引参加者との間で電子データを送受信するように構成された通信インタフェース、
を備え、
前記電子取引システムは、オーダブックの電子情報を前記取引参加者に対して条件付きで配信することを規制するステップであって、
前記電子取引システムの前記記憶媒体に前記オーダブックを維持するステップ、
取引参加者によって提出されたオーダの少なくとも１つの価格パラメータと、規定の閾値価格点との比較に基づいて、前記取引参加者が前記オーダブックの選択された部分にアクセスすることを許可するか否かを判定するステップ、
取引参加者との間で電子データを送受信する前記インタフェース上で、前記判定に基づいて、前記取引参加者にオーダブックデータを選択的に開示し又は前記オーダブックデータを隠すことにより、前記電子取引システムにおいて新たな半公開市場を実装するステップ、
により前記規制を実施するようにプログラムされている、
システム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/488,886 US10311515B2 (en) | 2014-09-17 | 2014-09-17 | System and method for a semi-lit market |
| US14/488,886 | 2014-09-17 | ||
| PCT/US2015/050719 WO2016044608A1 (en) | 2014-09-17 | 2015-09-17 | System and method for a semi-lit market |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2017534962A JP2017534962A (ja) | 2017-11-24 |
| JP2017534962A5 JP2017534962A5 (ja) | 2018-10-25 |
| JP6682514B2 true JP6682514B2 (ja) | 2020-04-15 |
Family
ID=55455164
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2017515239A Active JP6682514B2 (ja) | 2014-09-17 | 2015-09-17 | 半公開市場のためのシステム及び方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US10311515B2 (ja) |
| JP (1) | JP6682514B2 (ja) |
| KR (1) | KR20170057345A (ja) |
| CA (1) | CA2961770A1 (ja) |
| SG (2) | SG10202001295TA (ja) |
| WO (1) | WO2016044608A1 (ja) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SG10201706072PA (en) | 2012-09-12 | 2017-09-28 | Iex Group Inc | Transmission latency leveling apparatuses, methods and systems |
| SG11201608606WA (en) * | 2014-04-16 | 2016-11-29 | Iex Group Inc | Systems and methods for providing up-to-date information for transactions |
| CA2944925C (en) * | 2014-10-08 | 2017-04-25 | Tsx Inc. | Selective delayed and undelayed database updating |
| EP3197098B1 (en) * | 2014-10-29 | 2019-04-10 | Huawei Technologies Co., Ltd. | Heartbeat cycle setting method and terminal |
| US11416912B2 (en) * | 2016-05-13 | 2022-08-16 | Digital River, Inc. | High volume transaction queueing with machine learning |
| US20170330211A1 (en) * | 2016-05-13 | 2017-11-16 | International Business Machines Corporation | Modeling inventory performance for omni-channel fulfillment in retail supply networks |
| US10812613B2 (en) * | 2016-12-19 | 2020-10-20 | Chicago Mercantile Exchange Inc. | Optimization of encoding cycles for object recovery feed |
| US11004010B2 (en) * | 2016-12-30 | 2021-05-11 | eSentire, Inc. | Processing real-time processing requests using machine learning models |
| US20180197241A1 (en) * | 2017-01-09 | 2018-07-12 | Michael Chapman | Systems and methods of sequencing or combining multiple related, but different, transaction requests into a single transaction |
| US11216874B2 (en) * | 2017-03-09 | 2022-01-04 | Jpmorgan Chase Bank, N.A. | Method and system for aggregating foreign exchange measures |
| US11176585B2 (en) * | 2017-04-27 | 2021-11-16 | Nasdaq, Inc. | Method, system, and computer-readable medium for distributed transaction processing |
| US20180330438A1 (en) * | 2017-05-11 | 2018-11-15 | Vipul Divyanshu | Trading System with Natural Strategy Processing, Validation, Deployment, and Order Management in Financial Markets |
| US20190325515A1 (en) | 2017-10-08 | 2019-10-24 | David Marc Weisberger | Filtered, Consolidated, Cryptocurrency Best Bid and Offer (FCCBBO) data feed and historical data server |
| US11158001B2 (en) * | 2017-10-09 | 2021-10-26 | Nasdaq Technology Ab | Systems and methods for simultaneous placement of an order object in multiple order books of an automated exchange system |
| US10936598B2 (en) | 2017-11-21 | 2021-03-02 | Gto Llc | Systems and methods for targeted exchange emulation |
| US20210125278A1 (en) * | 2018-01-18 | 2021-04-29 | Coinroutes Inc. | System and method for calculating the executable price of a crypto-currency product pair |
| US11037241B2 (en) * | 2018-04-25 | 2021-06-15 | Ubs Business Solutions Ag | Dynamic dissemination of information to network devices |
| US11037243B2 (en) * | 2018-04-25 | 2021-06-15 | Ubs Business Solutions Ag | Dynamic dissemination of information to network devices |
| US10511520B1 (en) * | 2018-05-29 | 2019-12-17 | Ripple Labs Inc. | Multi-hop path finding |
| AU2018256664A1 (en) * | 2018-11-02 | 2020-05-21 | Australian Bond Exchange Holdings Limited | System and Computer Implemented Method for Facilitating the Transaction and Settlement of a Financial Instrument |
| US11654635B2 (en) | 2019-04-18 | 2023-05-23 | The Research Foundation For Suny | Enhanced non-destructive testing in directed energy material processing |
| JP6664726B1 (ja) * | 2019-09-11 | 2020-03-13 | アカメディア・ジャパン株式会社 | オークション管理システム、オークション管理方法、およびコンピュータプログラム |
| CA3164417A1 (en) * | 2020-01-31 | 2021-08-05 | Aleksey SOLODOVNIK | System and method for managing and processing sequenced events in a distributed network |
| US11088959B1 (en) | 2020-08-07 | 2021-08-10 | Hyannis Port Research, Inc. | Highly deterministic latency in a distributed system |
| US11303389B2 (en) | 2020-08-07 | 2022-04-12 | Hyannis Port Research, Inc. | Systems and methods of low latency data communication for physical link layer reliability |
| US11683199B2 (en) | 2020-08-07 | 2023-06-20 | Hyannis Port Research, Inc. | Distributed system with fault tolerance and self-maintenance |
| US11483087B2 (en) | 2020-08-07 | 2022-10-25 | Hyannis Port Research, Inc. | Systems and methods for clock synchronization using special physical layer clock sync symbols |
| US11328357B2 (en) * | 2020-08-07 | 2022-05-10 | Hyannis Port Research, Inc. | Sequencer bypass with transactional preprocessing in distributed system |
| US11228529B1 (en) | 2020-08-07 | 2022-01-18 | Hyannis Port Research, Inc. | Local and global quality of service shaper on ingress in a distributed system |
| US11315183B2 (en) | 2020-08-07 | 2022-04-26 | Hyannis Port Research, Inc. | Electronic trading system and method based on point-to-point mesh architecture |
| US20240070491A1 (en) * | 2022-08-31 | 2024-02-29 | Maplebear Inc. (Dba Instacart) | Simulating an application of a treatment on a demand side and a supply side associated with an online system |
Family Cites Families (60)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4736294A (en) | 1985-01-11 | 1988-04-05 | The Royal Bank Of Canada | Data processing methods and apparatus for managing vehicle financing |
| EP1208412A2 (en) | 1999-02-26 | 2002-05-29 | Reveo, Inc. | Globally time-synchronized systems, devices and methods |
| JP2001125993A (ja) * | 1999-10-28 | 2001-05-11 | Ntt Pc Communications:Kk | オークション方法、オークションシステム及びオークションプログラムを記録した記録媒体 |
| US7685052B2 (en) | 2000-06-01 | 2010-03-23 | Pipeline Financial Group, Inc. | Confidential block trading system and method |
| US8069106B2 (en) * | 2000-06-01 | 2011-11-29 | Pipeline Financial Group, Inc. | Block trading system and method providing price improvement to aggressive orders |
| US7860806B2 (en) * | 2002-03-12 | 2010-12-28 | Nokia Corporation | System and method for charging for data reception |
| US8595121B2 (en) | 2003-03-24 | 2013-11-26 | Bgc Partners, Inc. | Midprice trading within a spread market |
| GB2411492B (en) | 2004-02-25 | 2006-06-07 | Patsystems | Electronic trading system |
| US7529707B2 (en) * | 2004-08-04 | 2009-05-05 | Bgc Partners, Inc. | System and method for managing trading using alert messages for outlying trading orders |
| WO2006121691A2 (en) | 2005-05-06 | 2006-11-16 | Archipelago Holdings, Inc. | Passive liquidity order |
| JP2007109020A (ja) * | 2005-10-13 | 2007-04-26 | Central Tanshi Shoken Kk | サーバー装置、取引端末、コンピュータプログラム及び記憶媒体 |
| WO2008132420A1 (en) | 2007-05-01 | 2008-11-06 | Instinet Europe Limited | Anonymous block trade matching system |
| US20090099952A1 (en) * | 2007-10-12 | 2009-04-16 | Lars Wahlberg | Trading System for Handling an Order Matrix |
| WO2010077376A1 (en) | 2008-12-29 | 2010-07-08 | Openmatch Llc | Trading system |
| CA2681251A1 (en) | 2009-09-30 | 2011-03-30 | Royal Bank Of Canada | System and method for monitoring securities compliance for related entities |
| US9979589B2 (en) | 2009-12-10 | 2018-05-22 | Royal Bank Of Canada | Coordinated processing of data by networked computing resources |
| US9959572B2 (en) | 2009-12-10 | 2018-05-01 | Royal Bank Of Canada | Coordinated processing of data by networked computing resources |
| US10057333B2 (en) | 2009-12-10 | 2018-08-21 | Royal Bank Of Canada | Coordinated processing of data by networked computing resources |
| BR112012013891B1 (pt) | 2009-12-10 | 2020-12-08 | Royal Bank Of Canada | Sistema para efetuar processamento sincronizado de dados através de múltiplos recursos de computação em rede, método, dispositivo e meio legível por computador |
| US9940670B2 (en) | 2009-12-10 | 2018-04-10 | Royal Bank Of Canada | Synchronized processing of data by networked computing resources |
| EP2628142A4 (en) | 2010-10-12 | 2014-04-09 | Thomson Reuters Markets Llc | METHOD AND SYSTEM FOR PROVIDING INDICATIONS OF INTEREST (IOI) AND EXCHANGE ORDERS |
| EP2656293B1 (en) | 2010-12-22 | 2019-10-09 | HyannisPort Research, Inc. | Data capture and real time risk controls for electronic markets |
| KR101229162B1 (ko) | 2011-02-14 | 2013-02-01 | 주식회사 케이티 | 온라인 게임 제어 방법 및 시스템 |
| US8531983B2 (en) | 2011-02-28 | 2013-09-10 | Tellabs Operations, Inc. | System and method for identifying a length of an installed fiber cable |
| US20140019323A1 (en) | 2011-05-19 | 2014-01-16 | Royal Bank Of Canada | Processing of electronically traded fixed-income security based funds |
| US10127612B2 (en) | 2012-05-03 | 2018-11-13 | Tamer Trading Technologies Llc | System, method, and computer-readable medium for improving the efficiency and stability of financial markets |
| US8612323B1 (en) | 2012-06-07 | 2013-12-17 | Chicago Board Options Exchange, Incorporated | Methods and systems for trade fee and rebate computation and order routing |
| US20160019536A1 (en) | 2012-10-17 | 2016-01-21 | Royal Bank Of Canada | Secure processing of data |
| US11210648B2 (en) | 2012-10-17 | 2021-12-28 | Royal Bank Of Canada | Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments |
| US9082119B2 (en) | 2012-10-17 | 2015-07-14 | Royal Bank of Canada. | Virtualization and secure processing of data |
| US11080701B2 (en) | 2015-07-02 | 2021-08-03 | Royal Bank Of Canada | Secure processing of electronic payments |
| CA2844318A1 (en) | 2013-03-01 | 2014-09-01 | Royal Bank Of Canada | Guarantor mortgages |
| CA3012609A1 (en) | 2013-06-24 | 2014-12-31 | Aequitas Innovations Inc. | System and method for automated trading of financial interests |
| EP3201856A4 (en) | 2014-09-29 | 2018-06-06 | Royal Bank Of Canada | Secure processing of data |
| AU2015330644A1 (en) | 2014-10-10 | 2017-04-20 | Royal Bank Of Canada | Systems for processing electronic transactions |
| CA2913700A1 (en) | 2014-12-09 | 2016-06-09 | Royal Bank Of Canada | Synchronized processing of data by networked computing resources |
| US11165714B2 (en) | 2014-12-15 | 2021-11-02 | Royal Bank Of Canada | Verification of data processes in a network of computing resources |
| EP4242957A3 (en) | 2014-12-15 | 2023-11-22 | Royal Bank Of Canada | Verification of data processes in a network of computing resources |
| CA2916284C (en) | 2014-12-24 | 2023-11-21 | Gaurav Nagla | Systems and methods for presenting vehicular transaction information in a data communication network |
| CA2974151C (en) | 2015-01-19 | 2023-11-21 | Royal Bank Of Canada | Secure processing of electronic payments |
| CN107534584B (zh) | 2015-02-27 | 2020-12-01 | 加拿大皇家银行 | 通过网络化计算资源对数据进行协调处理 |
| US10783116B2 (en) | 2015-03-10 | 2020-09-22 | Royal Bank Of Canada | Systems and methods for managing data |
| WO2016149807A1 (en) | 2015-03-20 | 2016-09-29 | Royal Bank Of Canada | System and methods for message redundancy |
| KR102619230B1 (ko) | 2015-07-02 | 2023-12-28 | 로얄 뱅크 오브 캐나다 | 전자 지불의 보안 처리 |
| US11599879B2 (en) | 2015-07-02 | 2023-03-07 | Royal Bank Of Canada | Processing of electronic transactions |
| US11461359B2 (en) | 2015-10-01 | 2022-10-04 | Royal Bank Of Canada | System and method for duplicating an application state |
| WO2017054094A1 (en) | 2015-10-01 | 2017-04-06 | Royal Bank Of Canada | System and method for presenting dynamic visualizations |
| US20170124494A1 (en) | 2015-10-29 | 2017-05-04 | Royal Bank Of Canada | Systems, methods and devices for modelling operational risk |
| CA2910754C (en) | 2015-10-29 | 2023-08-22 | Royal Bank Of Canada | Systems, methods and devices for modelling operational risk |
| US20170186085A1 (en) | 2015-12-23 | 2017-06-29 | Royal Bank Of Canada | System and method for dynamic monitoring of credit parameters |
| EP3414713B1 (en) | 2016-02-12 | 2023-07-26 | Royal Bank Of Canada | Methods and systems for digital reward processing |
| CN115599978A (zh) | 2016-02-22 | 2023-01-13 | 加拿大皇家银行（Ca） | 电子文件平台 |
| AU2017231106B2 (en) | 2016-03-08 | 2023-01-19 | Royal Bank Of Canada | Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments |
| EP3260979B1 (en) | 2016-06-14 | 2022-03-09 | Royal Bank Of Canada | Verification of data processes in a network of computing resources |
| WO2018010009A1 (en) | 2016-07-13 | 2018-01-18 | Royal Bank Of Canada | Processing of electronic transactions |
| US10755327B2 (en) | 2016-07-18 | 2020-08-25 | Royal Bank Of Canada | Distributed ledger platform for vehicle records |
| US20180047065A1 (en) | 2016-08-15 | 2018-02-15 | Royal Bank Of Canada | System and method for predictive digital profiles |
| CA2976618A1 (en) | 2016-08-16 | 2018-02-16 | Royal Bank Of Canada | System for network incident management |
| WO2018049523A1 (en) | 2016-09-14 | 2018-03-22 | Royal Bank Of Canada | Credit score platform |
| CA2963767A1 (en) | 2016-09-22 | 2018-03-22 | Royal Bank Of Canada | System and method for electronic communications |
-
2014
- 2014-09-17 US US14/488,886 patent/US10311515B2/en active Active
-
2015
- 2015-09-17 CA CA2961770A patent/CA2961770A1/en not_active Abandoned
- 2015-09-17 SG SG10202001295TA patent/SG10202001295TA/en unknown
- 2015-09-17 WO PCT/US2015/050719 patent/WO2016044608A1/en active Application Filing
- 2015-09-17 JP JP2017515239A patent/JP6682514B2/ja active Active
- 2015-09-17 SG SG11201702152VA patent/SG11201702152VA/en unknown
- 2015-09-17 KR KR1020177010106A patent/KR20170057345A/ko not_active Application Discontinuation
-
2019
- 2019-04-11 US US16/381,537 patent/US11030692B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| KR20170057345A (ko) | 2017-05-24 |
| WO2016044608A1 (en) | 2016-03-24 |
| US10311515B2 (en) | 2019-06-04 |
| US11030692B2 (en) | 2021-06-08 |
| US20190259099A1 (en) | 2019-08-22 |
| CA2961770A1 (en) | 2016-03-24 |
| SG10202001295TA (en) | 2020-04-29 |
| JP2017534962A (ja) | 2017-11-24 |
| SG11201702152VA (en) | 2017-04-27 |
| US20160078538A1 (en) | 2016-03-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6682514B2 (ja) | 半公開市場のためのシステム及び方法 | |
| JP6757781B2 (ja) | 通信レイテンシー平準化装置、方法、およびシステム | |
| JP6619801B2 (ja) | ファシリテーションクロスオーダのためのシステム及び方法 | |
| JP6634019B2 (ja) | 電子取引を促進する技術 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7426 Effective date: 20170817 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20170817 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180914 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180914 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190704 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190723 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20191015 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20200310 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200325 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6682514 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |