KR20170041287A - 전송 레이턴시 평준화 장치, 방법 및 시스템 - Google Patents

Abstract

전송 레이턴시 평준화 장치, 방법 및 시스템의 실시예들은, 전송 매체를 통해 상이한 거래 엔티티들로부터의 전자적 거래 주문들을 서버에서 수신 및 라우팅하여 거래 주문들이 전자 거래소들에 도달하여 집행되기 이전에 소정량의 전송 레이턴시를 생성하는, "POP(point-of-presence)"와 같은, 전자적 매수 주문 관리 인프라구조를 제공하여, 고빈도 거래 참가자들이 경험할 수 있는 레이턴시 차익거래 및/또는 주문장 차익거래를 감소시킨다. 유사한 전송 레이턴시가 전자 거래소에 의해 발행된 시장 데이터 업데이트의 송출 전송에 적용될 수 있다. 전자 거래를 용이하게 하기 위한 다른 기술들도 역시 개시된다.

Description

전송 레이턴시 평준화 장치, 방법 및 시스템{TRANSMISSION LATENCY LEVELING APPARATUSES, METHODS AND SYSTEMS}

특허장을 위한 본 출원은 전송 레이턴시 평준화 방법 및 기술(이하에서부터는 "TLL")의 다양한 신규한 혁신 및 발명적 양태들을 개시하고 설명하며, 저작권, 마스크워크(mask work), 및/또는 기타의 지적 재산 보호를 받는 자료를 포함한다. 이러한 지적 재산권의 각 소유자는 본 개시가 공개된 특허청 파일/기록에 나타나 있을 때에는 본 개시의 팩시밀리 복사에 대해 반대하지 않지만, 그 외의 경우에는 모든 권한을 보유한다.

우선권

본 출원은 정식 출원이며, 발명의 명칭이 "Provisions for Reducing the Advantages of High-Frequency Trading in Financial Markets"인 2012년 9월 12일 출원된 미국 가출원 번호 제61/700,094호; 발명의 명칭이 "Provisions for Reducing Effectiveness of Order Book Arbitrage on a Securities Trading Venue"인 2013년 1월 30일 출원된 미국 가출원 번호 제61/758,508호; 발명의 명칭이 "CONGESTION FAILOVER AND RELIABLITY ENHANCED ORDER PLATFORM APPARATUSES, METHODS AND SYSTEMS"인 2013년 9월 11일 출원된 미국 가출원 번호 제61/876,200호; 및 발명의 명칭이 "Binary Search Tree with Worst-Case-Optimized, Time-Deterministic Insert and Search Operations for a Finite Key Space"인 2013년 1월 17일 출원된 미국 가출원 번호 제61/753,857호에 대한 35 U.S.C. 119 및 파리 조약하의 우선권을 주장한다.

위에서 언급된 출원들 모두는 참조에 의해 본 명세서에 명백히 포함된다.

분야

본 혁신들은 일반적으로 전자 거래 플랫폼(Electronic Trading Platform)을 위한 장치, 방법, 및 시스템을 해결하며, 더 구체적으로는, 전송 레이턴시 평준화 장치, 방법 및 시스템(TRANSMISSION LATENCY LEVELING APPARATUSES, METHODS AND SYSTEMS)("TLL")을 포함한다.

소비자들은 유가 상품(goods of value)에 대한 매수와 매도를 위해 경매 기반의 시스템을 이용한다. 이러한 경매 또는 거래 기반의 시스템은, 경매 기반의 온라인 쇼핑 사이트, 온라인 티겟 예약 시스템, 전자 시장, 또는 임의의 거래소를 포함할 수 있다.

개인 투자자와 거래자들은 (주식 및 채권 등의) 증권, 외환, 및 기타의 금융 파생 상품을 전자 거래 플랫폼을 통해 매수 또는 매도한다. NASDAQ, NYSE Arca, Globex, 런던 증권 거래소(London Stock Exchange), BATS, Chi-X Europe, TradeWeb, ICAP, 및 시카고 상품 거래소(Chicago's Board of Trade) 등의 전자 거래 플랫폼은, 매수자와 매도자가 금융 상품에 관해 값을 부르기 위한 정보 기술 인프라구조를 포함하는 가상의 시장을 제공한다. 거래자는 개인용 컴퓨터 사용자 인터페이스 등의 전자 단말기를 통해 전자 거래 플랫폼에 호가(bid)를 제출한다; 전자 거래 플랫폼은 통신 네트워크를 통해 금융 상품의 가격 정보를 반영하는 실시간 매도 및 매수 정보(real-time asking and bidding information)를 상이한 거래 엔티티들의 컴퓨터 단말기들에 전송한다.

첨부되는 부록, 도면, 도식, 이미지 등은, 본 개시에 따른, 다양한 예, 비제한적인 발명적 양태, 실시예, 및 피쳐들("예를 들어", 또는 "예(들)")을 나타낸다.
도 1a는 TLL의 실시예 내에서 레이턴시 차익거래(latency arbitrage)를 감소시키는 양태를 도시하는 예시를 제공한다;
도 1b는 TLL의 실시예 내에서 주문장 차익거래(order book arbitrage) 감소의 양태를 도시하는 예시를 제공한다;
도 1c 내지 도 1d는 TLL의 실시예 내에서 차익거래를 감소시키기 위한 TLL POP(Point of Presence) 메커니즘의 예시적 인프라구조를 나타내는 비교도를 제공한다;
도 2는 TLL의 실시예 내에서 TLL 매수 데이터 수집(bidding data collection)을 위한 TLL 플랫폼과 그 연관 엔티티들 사이의 데이터 흐름을 나타내는 데이터 흐름도를 제공한다;
도 3은 TLL의 실시예 내에서 레이턴시 차익거래를 감소시키는 POP 라우팅의 양태를 나타내는 로직 흐름을 제공한다;
도 4a 및 도 4b는 TLL의 실시예 내에서 TLL의 예시적 사용자 인터페이스 도면을 제공한다;
도 5a 내지 도 5c는 TLL의 실시예 내에서 TLL 네트워크 인프라구조의 양태를 나타내는 예시적 데이터 도면을 제공한다;
도 6a 내지 도 6h는 TLL의 실시예 내에서 추가의 데이터 전송 레이턴시를 야기하는 네트워크 액세스 포인트를 통한 레이턴시 차익거래 및 주문장 차익거래를 관리하기 위한 다양한 시나리오를 나타내는 예시적 도면을 제공한다;
도 7은 TLL의 추가 실시예를 나타내는 데이터 흐름도를 제공한다;
도 8a 내지 도 8d는 TLL의 실시예 내에서 유한 키 공간(finite key space)을 위한 최악-상황-최적화된, 시간-결정적 삽입, 및 탐색 동작들을 갖는 2진 검색 트리(binary search tree with worst-case-optimized, time-deterministic insert, and search operations)의 실시예들을 나타내는 예시적 도면을 제공한다;
도 9는 TLL 제어기의 예시적 양태를 나타내는 블록도를 도시한다.
도면들 내의 각 참조 번호의 선두 번호는 그 참조 번호가 도입된 및/또는 상세히 설명된 도면을 나타낸다. 따라서, 참조 번호 101의 상세한 논의는 도 1에서 발견 및/또는 도입될 것이다. 참조 번호 201은 도 2에서 도입되는 등등의 방식이다.

전송 레이턴시 평준화 기술(이하에서부터 "TLL")은, 전송 매체를 통해 네트워크 액세스 포인트에서의 상이한 거래 엔티티들로부터의 전자적 거래 주문을 수신 및 라우팅하여 거래 주문이 전자 마켓 센터에 도달하여 집행되기 이전에 소정량의 전송 레이턴시를 생성하는 "point-of-presence" 또는 "POP" 등의, 전자 거래 주문 관리 인프라구조를 제공하여, 고빈도 거래 참가자에 의해 악용될 수 있는 레이턴시 차익거래 및/또는 주문장 차익거래를 감소시킨다.

한 구현에서, POP(Point-of-Presence) 액세스 포인트는 시장 참가자들로부터 거래 주문을 수신하고 그 주문을 집행하기 위해 데이터 거래소에 전달하도록 설치 및 구성될 수 있다; POP으로의 및 POP으로부터의 전송은, 시장 참가자의 위치(예를 들어, 전송 거리 등), 전송 매체(예를 들어, 케이블, 마이크로파 등), 회로 저항, 기타의 정보 기술 인프라구조 이점 및/또는 기타의 전송 속도 이점, 및/또는 기타 등등에 기인할 수 있는 추가의 전송 레이턴시로 이어질 수 있다. 예를 들어, POP과 데이터 거래소 또는 시장 참가자 단말기를 접속하는데 요구되는 케이블의 길이는 전송 레이턴시를 생성하는데 이용될 수 있다. 이러한 전송 레이턴시는 전송 케이블의 길이를 조절함으로써 제어될 수 있다.

한 구현에서, POP은, 주문을 수신하기 위한 입력 포트와의 적어도 하나의 통신 링크, 및 수신된 주문을 데이터 거래소 및/또는 기타의 엔티티에 전송하기 위한 출력 포트와의 또 다른 통신 링크를 포함하는 비-지능형 네트워크 하드웨어의 단편(a piece of non-intelligent network hardware)을 포함할 수 있다. 또 다른 구현에서, POP은, 프로세서에 의해 일련의 명령어를 수행하기 위해 컴퓨터 실행가능한 명령어들을 저장하고 있는 컴퓨터 판독가능한 매체를 포함할 수 있다.

도 1a 내지 도 6h에서 논의되는 예는 금융 상품 거래를 위한 시장 데이터 센터와 데이터 거래소를 포함하고 있지만, TLL은, 광고 거래소(디스플레이, 모바일, 라디오, 탐색, 비디오, 및/또는 기타 등등), 온라인 항공권/호텔 예약 시스템, 온라인 경매 쇼핑 시스템, 대규모 멀티플레이어 온라인 게이밍 시스템(MMORGs)에서 볼 수 있는 것과 같은 가상 세계 인-게임(in-game) 시장, 및/또는 이와 유사한 것을 포함하지만, 이것으로 제한되지 않는 임의의 경매-기반의 시스템 또는 전자 시장에 적용될 수 있다는 점에 유의해야 한다. 나아가, TLL은, 레이턴시 및/또는 자원에 대한 액세스가 고려사항인 임의의 전자 메시징 시스템에 적용될 수 있다. 예를 들어, 플레이어들이 메시지를 수신하고 제출하는 속도가 플레이어들이 게임 내의 상태를 얼마나 빨리 이해하고 대응할 수 있는지를 결정하고, 플레이어가 다른 플레이어에 앞서 반응하고 행동을 보일 수 있는 온라인 비디오 게임에서, 이러한 이점을 얻는 것은 플레이어가 게임에서 이길 수 있게 할 수 있다. 따라서, TLL은 경매 기반의 시스템에서 정보와 자원에 대한 제도화된 공정한 액세스를 제공할 수 있다.

전송 레이턴시 평준화(TLL; TRANSMISSION LATENCY LEVELING)

도 1a는 TLL의 실시예 내에서 레이턴시 차익거래(latency arbitrage)를 감소시키는 양태를 도시하는 예시를 제공한다. 한 구현에서는, 금융 상품 거래 시장에서, 일부 시장 참가자는 정보 기술 인프라구조를 활용하여 다른 시장 참가자보다 빨리 시장 데이터 공급(market data feeds)을 취득할 수 있어서 다른 시장 참가자가 시장 변화에 대응하기 이전에 거래 전략을 체계화하고 실행할 수 있다.

예를 들어, 한 구현에서, 시장 참가자로부터의 주문이 집행되는 위치는, 가격고시(quotation), 집행된 거래, 및 기타의 시장 데이터의 보고서가 공중에 배포되는, 주문이 수락되는 위치일 수도 있다. 마켓 센터와 동일한 장소에(예를 들어, 동일 장소 소재) 및/또는 이와 근접한 지역 내에 거래 엔티티들을 배치함으로써, 시장 참가자는, 데이터 배포에 더 긴 시간이 걸릴 수 있는 다른 시장 참가자에 앞서 시장 데이터 업데이트를 수신할 수 있다. 한 구현에서, 이러한 시장 데이터 전송 이점은, 위치 이점(예를 들어, 더 짧은 전송 거리 등), 전송 매체(예를 들어, 케이블, 마이크로파 등), 회로 저항, 기타의 정보 기술 인프라구조 이점 및/또는 기타의 전송 속도 이점, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 다양한 인자들에 의해 야기될 수 있다.

한 구현에서, 시장 데이터는, 가격고시, 마지막 거래 공급(last trade feeds), 및/또는 기타의 시장 정보를 포함할 수 있다. 한 구현에서, 마켓 센터(120)는, 임의 종류의 교환, 시장 데이터 게시자(market data publisher), 대체 거래 시스템, 전자 통신 네트워크(ECN; Electronic Communication Network), 다크 풀(dark pool), 및/또는 이와 유사한 것을 포함할 수 있다. 한 구현에서, 마켓 센터는 거래 주문을 집행할 수 있는 데이터 거래소(data exchange)를 포함할 수 있다. 추가의 구현에서, 마켓 센터는, 임의의 주문을, 마켓 센터와 연계되거나 또 다른 마켓 센터에 위치할 수 있는, 하나 이상의 데이터 거래소에 정합, 라우팅 및/또는 재라우팅할 수 있는 정합 엔진 및 스마트 라우터(matching engine and a smart router)를 포함할 있다.

고빈도 거래(HFT; high frequency trading) 참가자(이것으로 제한되지 않음) 등의 시장 참가자들은 더 빠른 데이터 전송 이점을 활용하여 "레이턴시 차익거래"라고 알려진 전략에 참가할 수 있다. 도 1a에 도시된 바와 같이, 한 구현에서, 그들의 거래 시스템을 마켓 센터(120), 및/또는 이와 유사한 것에 더 가깝게 위치시킴으로써, HFT 참가자(102c)는 시스템이 마켓 센터(120)로부터 더 멀리 위치해 있는 다른 참가자(102a-b)보다 더 일찍 시장 데이터(예를 들어, "코카 콜라 주식"의 가격 업데이트(103) 등)를 수신할 수 있다. 그러면, HFT 참가자(102c)는 다른 참가자들이, 코카 콜라 주식 가격에 관한 시장 데이터, 예를 들어, 103을 수신하기도 전에, 예를 들어, 코카 콜라의 주식을 매수하기 위해서, 기타 등등, 새로이 수신된 시장 데이터에 기초하여 거래를 집행할 수 있다(104). 그 결과, 마켓 센터(120)와 동일한 장소에 위치하거나 그들의 거래 시스템이 마켓 센터(120)에 가깝게 위치하지 않은 참가자(102a-b)는, 오래된 데이터에 기초하여 거래를 할 수 밖에 없으며, 예를 들어, 시장 참가자(102a-b)는 코카 콜라 주식 가격 변경(103)에 기초하여, 그러나, HFT 참가자(103c)가 이미 코카 콜라 주식에 관해 거래(104)를 제출한 새로운 가격 변화를 야기할 수 있는 이후에, 주문을 생성 및 집행할 수 있다. 한 구현에서, HFT 참가자 이외의 시장 참가자, 예를 들어, 그들의 거래 단말기 등에서 임의의 데이터 전송 이점을 누리는 임의의 브로커(broker), 개인 투자자, 기타의 거래 엔티티들은 이러한 레이턴시 차익거래를 의도적으로 또는 무의식적으로 이용할 수 있다.

한 구현에서, TLL 인프라구조는 POP(Point of Presence) 구조(110)를 제공하여 레이턴시 차익거래를 경감하고 더 넓은 범위의 참가자들이 공정한 시장에 액세스하는 것을 허용할 수 있다. 예를 들어, 도 1a에 도시된 바와 같이, TLL은 주문 수락과 시장 데이터 공급의 공개 소스를 시장의 집행 센터(120)로부터 분리할 수 있다. 한 구현에서, TLL은 주문이 마켓 센터(120)에 직접 제출되는 것을 허용하지 않을 수 있고, 거래 주문이 POP(110)에 제출되고 POP(110)에서 재라우팅되어 마켓 센터(120)에 전송될 것을 요구할 수 있다. 한 구현에서, 가격 고시(예를 들어, 103)가 수신되거나 거래가 집행될 때, 마켓 센터(120)로부터 POP(point of presence)(110)으로 데이터가 전송되고, 그 다음에 POP(110)으로부터 공중에 배포된다. 마찬가지로, 거래 주문은 POP(110)에서 재라우팅될 수 있다(예를 들어, 105).

한 구현에서, POP(110)은, 프로세서, 메모리 유닛, 하나 이상의 데이터 I/O 포트, 및/또는 이와 유사한 것(예를 들어, 도 6 등을 참조)을 포함할 수 있는 하드웨어 액세스 포인트를 포함할 수 있고, 다양한 전송 매체, 예를 들어, 케이블, 무선, 마이크로파 등을 통해, 마켓 센터(120) 및/또는 임의의 시장 참가자, 거래 데이터 단말기 등에 접속될 수 있다. 한 구현에서, POP 액세스 포인트는, 주문을 집행하고, 및/또는 주문을 정합해서 또 다른 마켓 센터에 라우팅하는, 마켓 센터(120)의 정합 엔진으로부터 물리적으로 분리되거나 분리되지 않을 수도 있다. 예를 들어, POP 액세스 포인트가 마켓 센터 외부에 위치할 때, POP 액세스 포인트(110)와 마켓 센터(120) 사이의 거리는 데이터 신호에 대한 추가의 전송 시간으로 이어질 수 있다. 또 다른 예에서, POP 액세스 포인트는 마켓 센터와 함께 위치할 수도 있고, POP 액세스 포인트 주변에 감긴 추가의 케이블을 가져 데이터 신호가 POP 액세스 포인트로부터 마켓 센터에 도달하기 위한 추가의 전송 시간을 생성할 수 있다. POP 액세스 포인트(110)의 (예를 들어, 전송 매체 타입(예를 들어, 케이블, 무선, 마이크로파 등), 케이블 길이, 저항, 전송 시간 측정치 등의 전기 회로 파라미터 등을 포함하는) 추가의 물리적 규격이 도 2에 제공될 수 있다.

추가의 구현에서, POP 액세스 포인트의 케이블 길이, 회로 저항, 및/또는 기타의 하드웨어 파라미터는, POP 액세스 포인트에 의해 생성된 전송 레이턴시가 조절가능하도록, 예를 들어, 사용자 인터페이스 등을 통해 조절가능할 수 있다.

한 구현에서, TLL/POP 구조는 HFT 참가자(102c)에 의한 동일 장소 소재(colocation)의 이점을 감소시킬 수 있다. 자신의 거래 시스템을 POP(point of presence)에 위치시키는 HFT 참가자(102c)는 POP(point of presence)(110)으로부터 마켓 센터(120)까지의 왕복 레이턴시만큼 지연된 데이터 공급을 수신할 수 있다. 따라서, 더 낮은 레이턴시 공급의 이점에 기초한 HFT 전략(예를 들어, 104)은, 그들이 시장 데이터에 기초하여 다른 참가자(102a-b)가 데이터를 수신하기 이전에(예를 들어, 108 등) 거래를 집행할 것이라고 더 이상 확신시키지 못할 수 있다.

추가의 구현에서, 도 1d에 추가로 나타낸 바와 같이, 데이터 거래소(122b)는 거래 주문을 제2 장소(예를 들어, 또 다른 거래소, ECN 등)에 라우팅할 수 있다. 이 경우, 마켓 센터(120)로부터 POP(110)까지의 레이턴시(예를 들어, 마켓 센터(120)가 POP을 통해 마지막 거래 공급을 포함하는 시장 데이터를 발표할 것을 요구함으로써 도입되는 추가의 레이턴시 등)와 POP(point of presence)으로부터 제2 장소까지의 레이턴시(예를 들어, HFT 참가자가 POP을 통해 주문을 제출할 것을 요구함으로써 도입되는 추가의 레이턴시 등)의 합이 마켓 센터(120)로부터 제2 장소까지의 레이턴시보다 크다면, 마켓 센터로부터의 주문은 HFT 참가자로부터의 간섭없이 안전하게 제2 장소까지 라우팅될 수 있다. 시스템에 추가의 레이턴시를 도입함으로써, 레이턴시 차익거래의 불공정한 이점이 감소된다.

도 1b는 TLL의 실시예 내에서 주문장 차익거래(order book arbitrage) 감소의 양태를 도시하는 예시를 제공한다. 한 구현에서, 도 1a에서 논의된 바와 같이, HFT 참가자(102b)는, 다른 시장 참가자(102b)가 시장 공급(market feed)에 대응하거나 심지어 시장 공급을 수신하기도 전에 HFT 참가자(102c)가 거래를 집행할 수 있도록, 다른 시장 참가자(102b)보다 빨리 시장 데이터 공급을 수신하기를 추구할 수 있다. 이러한 HFT 거래 전략의 한 예는 주문장 차익거래 전략을 포함할 수 있다. 주문장 차익거래는, 마켓 센터가 시장 정보를 처리할 수 있기 이전에 시장 정보를 처리하고 그에 대해 동작하여, 그에 따라 마켓 센터가 더 최신의 정보를 가졌다면 실행하지 않았을 트랜잭션을 실행하게 함으로써, 시장 정보의 전파에서의 필요한 지연을 이용한다.

예를 들어, 많은 마켓 센터는, 참가자가, 제한 가격(limit price)이 마켓 센터에 의해 동적으로 조절되어 항상 전국 최상 매수 및 매도(NBBO; national best bid and offer) 가격, 예를 들어, 121 사이의 중간에 있게 되는, "중간점 고정(midpoint peg)"에 의해 주문을 내는 것을 허용할 수 있다. 중간점 고정 주문은, 현재의 NBBO의 중간점 가격에서만 집행되도록 의도한 것이다. 예를 들어, 주문이 오래된 NBBO 데이터에 기초하여 가격이 정해지면, 그 주문 가격은 가장 최신의 NBBO의 중간점이 아닐 수 있고, 결과적으로 주문이 거래되지 않거나 최신의 중간점 가격보다 열등한 가격에서 거래될 수 있다.

예를 들어, 시장 A에서, NBBO는 .10 x .12로서 계산되고, 중간점은 .11이다. 시장이 새로운 NBBO .11 x .13까지 이동하면, 새로운 중간점은 .12이고 거래 주문 데이터는 유효한 중간점 고정 전략이 되기 위하여 그에 따라 업데이트될 필요가 있을 수 있다. 시장 A가 업데이트될 시간을 갖기 전에 HFT 참가자가 새로운 중간점(.12)을 얻게 되면, HFT 참가자는 .11에 대해 잠재적으로 시장 A에서 주식을 매수할 수 있고, 순간적으로/동시에 주식을 .12에 대해 또 다른 시장에서 매도할 수 있어서 .01의 "무위험" 차익거래를 고정화하게 된다. 이러한 시나리오는 (예를 들어, 미국 증권 거래 위원회의 규정 NMS(U.S. Securities and Exchange Commission's Regulation NMS)("규정 NMS") 또는 유사한 법률하에서) 재-가격책정되는 주문과는 상이할 수 있고, 이 때, 시장 A에서, NBBO는 .10 x .12로서 계산되고, 시장 A는 .09에서 호가(bid)를 가진다. 시장이 이동하여 새로운 NBBO가 .09 x .11이고 시장 A가 제시간에 업데이트되지 않는다면, 이것은 (규정 NMS는 .10 호가를 통한 거래를 금지하므로) 0.09에 대한 매도 주문이 0.09에 대한 레스팅 매수 주문(resting buy order)과 정합되는 것을 허용하지 않을 수 있다. 대안으로서, 시장 A의 호가에 고정된 주문이 있고 NBBO가 .10 x .12에서 계산될 때, 시장이 이동하여 새로운 NBBO가 .09 x .11이고 시장 A가 제시간에 업데이트되지 않는다면, 이것은 여전히 그 주문을 호가 .10에 고정시킬 수 있다; 이런 방식으로, HFT 참가자는 .10에서 매도하고 즉시 또 다른 시장에서 .09에서 매수하려고 할 수 있다.

한 구현에서, 고정된 제한 가격은 마켓 센터가 액세스하는 시장 데이터를 참조하여 마켓 센터에 의해 결정된다. 마켓 센터가 NBBO를 결정하기 위해 통합된 시장 데이터 공급을 이용하는 반면 마켓 센터와 동일한 장소에 있을 수 있는 HFT 참가자(102c)가 (사유 또는 Exegy, Redline, Wombat 등과 같은 제3자 티커 플랜트(ticker plant)로부터의) 사유 시장 데이터 공급을 이용할 때, HFT 참가자(102c)는, 마켓 센터가 NBBO 업데이트를 처리완료하기 이전에 NBBO 업데이트를 처리하고, 주문을 제출하며, 중간점 고정된 주문(예를 들어, 114 참조)에 대해 집행할 수 있다.

예를 들어, NBBO가 .10 x .12로부터 .08 x .10로 변했다면, HFT 참가자(102c)는, .11(원래의 NBBO의 중간점)에서의 실행을 기대하는 중간점 제한 매도 주문(mid-point limit sell order)을 즉시 전송함으로써 그 주문장 전략(130)을 실행할 수 있다. 더 느린 데이터 공급을 갖는 마켓 센터가 NBBO가 변했다는 것을 아직 모른다면, 이것은, HFT(102c) 중간점 매도 주문에 맞서, 가장 최근의 NBBO보다 열등한 가격에서, 중간점 고정 매수 주문(mid-point peg buy order)을 거래할 수 있다. 따라서, 고정된 주문은 현재의 NBBO 외부에서 집행될 수 있어서, 주문의 의도를 훼손할 것이다. 마켓 센터가 HFT 참가자와 동일한 업데이트된 NBBO를 가졌다면, 고정된 주문은 역시 새로운 NBBO(.09)의 중간점으로 재-가격책정되었을 것이고, HFT 참가자는 고정된 주문에 대하여 집행할 수 없었을 것이다. 이러한 차익거래 전략은, 이전에는 NBBO 내에 있었지만 업데이트된 NBBO보다 더욱 공격적으로 가격책정되는 "은닉(hidden)" 주문 등의, 다른 주문 타입을 이용하는데 유사하게 이용될 수 있다.

한 구현에서, TLL은 도 1a에 도시된 것과 유사한 인프라구조를 채택하여 이러한 주문장 차익거래를 감소시킬 수 있으며, 예를 들어, 거래 주문은 마켓 센터에 직접 제출되지 못할 수 있다. 대신에, 이들은 POP(point of presence)(110)에 제출되고, POP(110)으로부터 마켓 센터에 전송될 필요가 있다. 한편, 마켓 센터는 그 자신의 시장 데이터를 업데이트하기 위해 직접적인 사유 데이터 공급을 이용할 수 있다. 이런 방식으로, 모든 시장 참가자(102b)는 NBBO 업데이트(117)를 수신하고, 가장 최신의 중간점 고정 데이터에 기초하여, 그들의 거래 단말 인터페이스(119)를 통해 매수/매도 요청을 집행할 수 있을 것이다.

예를 들어, t_a는, HFT 참가자(121)가 시장 데이터 업데이트(135)를 수신 및 처리하는데 걸리는 시간을 나타내고, t_b는, HFT 참가자(121)가 그 차익거래-전략 주문을 마켓 센터에 제출하기 위한 시간이며, t_c는, 마켓 센터가 시장 데이터 업데이트를 수신 및 처리하기 위한 시간이라면, HFT 참가자(102c)는 부등식 t_a + t_a < t_c가 유효할 때마다 차익거래를 향유할 수 있다. HFT 참가자(102c)가 t_c에 관하여 t_a 및 t_b를 감소시킬 수 있는 다양한 방법이 있다. 예를 들어, 시장 데이터는 모든 마켓 센터로부터의 데이터를 포함하는 통합된 시장 데이터 공급을 통해 배포될 수 있지만, 많은 마켓 센터들은 센터 자신의 거래 및 시세 데이터의 사유 데이터 공급도 역시 제공한다. 통합 프로세스의 성격상, 통합된 시장 데이터 공급은 일반적으로 사유 공급에 비해 지연될 수 있다. 따라서, 마켓 센터가 통합된 시장 데이터 공급을 이용하고 있는 반면 HFT 참가자(102c)가 사유 공급을 이용한다면, t_a는 지연이 부족할 것이고 t_c보다 상당히 작을 수 있다. 제3항 t_b도 역시 "동일 장소 배치"를 통해 감소될 수 있으며, 예를 들어, HFT 참가자(102c)는 그 서버들을 마켓 센터와 물리적으로 가까이 배치하여, 전송 시간에서의 레이턴시를 줄인다.

한 구현에서, 마켓 센터는, 사유 공급과 더 빠른 기술을 이용함으로써 t_c의 감소를 시도하여 차익거래 전략이 발생되는 것을 허용하는 부등식을 반전시킬 수 있지만, 기술 진보의 빠른 속도는 그저, 참가자와 마켓 센터가 상대방의 최신 진보를 넘어서 그들의 레이턴시를 지속적으로 줄이고자 하는 결코 끝나지 않는 "군비 경쟁"을 생성할 수 있다. 따라서, 이것은 마켓 센터에 대한 비용-효율적인 사업 전략이 될 수 없어서, 그렇게 많은 이들이 HFT 참가자의 기술과 경쟁하려고 시도하지 않는다. 대안적 구현에서, TLL은, 예를 들어, POP을 통해, 인프라구조를 제공하여, t_c를 줄이려는 임의의 값비싼 기술 경쟁 대신에 t_b를 증가시킴으로써 차익거래 기회를 제거한다.

한 구현에서, t_b는 POP(point of presence)(110)으로부터 마켓 센터까지의 레이턴시만큼 증가될 수 있어서, t_a+ t_b > t_c이므로 도 1b에서 논의된 주문장 차익거래 전략 등의 차익거래 전략이 이 인프라구조 내에서는 훨씬 덜 효율적일 수 있다. HFT 참가자가 데이터 업데이트를 처리하고 주문을 마켓 센터에 전송하는 데 걸리는 시간은, 최소한, 사유 데이터 공급으로부터 POP(point of presence)(110)까지의 레이턴시와 POP(110)으로부터 마켓 센터까지의 레이턴시의 합일 수 있다. 이들 2개 레이턴시의 합은 사유 데이터 공급으로부터 마켓 센터까지의 직접 경로 상의 레이턴시보다 크기 때문에, 마켓 센터는, 동일한 데이터에 기초하여 HFT 참가자로부터의 임의의 주문을 수신하기 이전에 새로운 데이터를 수신 및 처리할 것이다. 따라서, 마켓 센터는 시스템 속도에 관해 HFT 참가자와 경쟁하려고 시도하지 않고 주문장 차익거래를 수행하는 HFT 참가자의 능력을 상당히 줄인다.

도 1c는 TLL의 실시예 내에서 차익거래를 감소시키기 위한 TLL POP 메커니즘의 예시적 인프라구조를 나타내는 비교도를 제공한다. 한 구현에서, 도 1c(a)에 도시된 바와 같이, TLL/POP 인프라구조없이, HFT 참가자(121)는 시장 데이터가 생성되고 배포되며, 거래 주문이 실행되는 데이터 거래소(122a-b), 예를 들어, 거래소 A(122a) 및 거래소 B(122b)에 가까이 또는 심지어 이와 동일한 장소에 위치할 것을 선택할 수 있다.

예를 들어, 브로커(125)가 그들의 고객(130)(예를 들어, 비-HFT 거래 엔티티)을 위해 데이터 센터1(120a)의 거래소(122a)에 거래 주문(131)을 제출하고, 제2 주문(132)을 데이터 센터2(120b)의 거래소(122b)에 제출한다. 물리적 위치 이점으로 인해, HFT(121)는 브로커(125)에 의해 제출된 거래소 A(122a)로부터의 주문(131)에 관해 주문 실행 정보(131)를 포함하는 시장 데이터(135)를 수신할 수 있다. HFT(121)는 내부적으로 이러한 정보를 동기화하고 시장 데이터에 대응할 수 있으며, 예를 들어, HFT(121)는 주문(131)의 집행에 관련된 획득 정보에 기초하여 주문(3)을 생성하거나 및/또는 거래소 B(122b)의 임의의 계류중인 주문(133)을 취소할 수 있다. 따라서, 브로커(125)와 데이터 센터2(120b) 사이의 물리적 거리로 인해, HFT(121)는 주문1(131)이 집행된 후에 주문2(132)가 거래소 B(122b)에 도달하기 이전에, 업데이트된 시장 정보에 따라 행동할 수 있어서, 주문2(132)를 오래된 시장 데이터(예를 들어, 주문1이 실행되기 이전 등)에 기초하는 경쟁력없는 거래 주문이 되게 한다.

또 다른 구현에서, 도 1c(b)에 도시된 TLL/POP 인프라구조와 더불어, TLL은 주문 수락과 시장 데이터 공급의 공개 소스를 시장의 집행 센터(122a)로부터 분리할 수 있다. 한 구현에서, 모든 거래 주문은 POP 액세스 포인트(110)에 제출될 필요가 있고 POP은 집행(122a)을 위해 거래소 TLL에 거래 주문을 전송할 수 있고, 예를 들어, 브로커(125)는 TLL에서 주문(131)을 집행하기 위하여 주문1(131)을 POP(110)에 제출할 수 있다. 한 구현에서, TLL은, (예를 들어, 주문1 집행을 반영하는 업데이트된 데이터를 포함하는) 시장 데이터(135)를, 이러한 시장 데이터(135)를 HFT(121)에 전달할 수 있는 POP(110)을 통해 발표할 수 있다.

한 구현에서, HFT(121) TLL이 POP(110)을 통해 주문1(131)의 집행을 반영하는 업데이트된 시장 데이터(135)를 취득한다면, HFT(121)가 즉시 시장 변화에 대응하더라도, HFT(121)는 그 주문을 데이터 센터2(120b)의 거래소(122b)에 라우팅할 수 있다. 따라서, 예를 들어, 데이터 센터1의 HFT(121)로부터 데이터 센터2의 HFT(121)까지의 추가의 전송 시간이 HFT 주문의 레이턴시를 증가시킬 수 있다; 데이터 센터2(120b)의 HFT(121)가 주문1 집행(131)을 반영하는 시장 데이터(135)에 기초하여 주문3(133)을 제출 및/또는 취소할 수 있을 쯤에는, 브로커(125)의 주문2(132)는 데이터 센터2(120b)에 도달했을 것이고(예를 들어, 주문2(132)는 TLL에서 집행되기 위한 것이 아니므로 데이터 센터(120b)에 직접 제출될 수 있는 등), 거래소 B(122b)에서 실행되었을 것이다. 따라서, 주문3은 주문2(132)에 비해 업데이트된 시장 데이터의 관점에서 어떠한 이점도 갖지 않을 수 있다.

예를 들어, 브로커(125)로부터 데이터 센터2(120b)까지의 주문2(132)의 전송 시간은 89ms일 수 있고; POP 액세스 포인트(110)에 의해 야기되는 전송 시간 레이턴시(예를 들어, 추가의 케이블 길이, 회로 저항 등)는 TLL(122a)로부터 POP(110)을 거쳐 HFT(121)까지의 시장 데이터(135)의 전송 시간, 예를 들어, 30ms, 및 HFT(121)로부터 데이터 거래소 B(122b)까지의 전송 시간, 예를 들어, 60ms, 그 결과, 총 90ms의 레이턴시를 포함할 수 있다. 한 구현에서, POP 및/또는 TLL은 주문이 전송 및/또는 수신되는 타이밍을 추정, 측정, 및/또는 시그널링할 필요가 없을 수 있다; 대신에, POP의 물리적 구성은 앞서 논의된 바와 같이 추가의 레이턴시를 초래할 수 있다. 따라서, 임의의 주문3은 주문2가 도달한 후에 거래소 B에 도달할 수 있다.

도 1d는 TLL의 실시예 내에서 주문 예측에서의 레이턴시 차익거래를 감소시키는 또 다른 예를 도시한다. 한 구현에서, TLL(122a)은 가장 최신의 시장에 기초하여 주문을 동적으로 라우팅할 수 있고, TLL(122a)로부터 얻어진 시장 데이터(135)는, 주문 예상을 위해 HFT(121)에 의해 이용될 수 있는 마지막 거래 공급을 포함할 수 있다. 예를 들어, 도 1d(b)에 도시된 바와 같이 HFT(121)가 가장 최근에 집행된 주문을 얻기 위해 TLL(122a)로부터 시장 데이터(135)를 얻을 때, TLL(122a)은 주문(134)을 다른 데이터 센터(예를 들어, 데이터 센터2(120b) 등)에 라우팅할 수 있기 때문에, HFT(121)는 아마도 데이터 센터2(120b)의 데이터 거래소B(122b)에 라우팅되어 그에 의해 실행될 주문(134)을 예측할 수 있을 것이다. 도 1d(a)에 도시된 바와 같이 POP 액세스 포인트(110)가 없다면, HFT(121)는 라우팅된 주문(134)과 경쟁하는 주문(133)을 즉시 생성하여, 이러한 주문(133)을 데이터 거래소(122b)에 전송할 수 있으며, 데이터 거래소(122b)는, 라우팅된 주문(134)을 경쟁력없게 할 수 있다, 예를 들어, 주문(134)에 포함된 매수/매도는 성공적이지 않거나, 열등한 가격 등에서 집행될 수 있다.

또 다른 구현에서, 도 1d(b)에 도시된 바와 같이, POP 액세스 포인트(110)와 더불어, 주문1 집행 업데이트를 포함하는 시장 데이터(135)가 POP(110)에 전송될 수 있고, POP(110)은 차례로 시장 데이터(135)를 HFT(121)에 전송할 수 있다; 그리고, 라우팅된 주문(134)과 경쟁하는 HFT가 생성한 임의의 주문(133)은 데이터 거래소(122b)로 라우팅될 필요가 있다. POP(110)을 통해 HFT(121)로의 가장 최근의 시장 데이터(135)의 발표 및/또는 주문1(133)의 전송 시간으로부터의 레이턴시로 인해, 주문(133)이 데이터 거래소(122b)에 도달할 수 있을 쯤에는, 주문(134)은 데이터 거래소(122b)에 도달하여 집행되었으므로, 불리하게 되지 않을 것이다.

도 1a 내지 도 1d에 주어진 예는 HFT 시장 참가자와 비-HFT 시장 참가자를 도시하고 있지만, 이러한 레이턴시 및/또는 주문장 차익거래는 HFT 및/또는 비-HFT 참가자의 임의의 조합간에 발생할 수 있고, POP 하드웨어 액세스 포인트는 다양한 시장 참가자에 적용될 수 있다는 점에 주목할 가치가 있다. 레이턴시 차익거래 및 주문장 차익거래를 관리하는 시나리오들의 추가의 예와 변형들이 도 6a 내지 도 6h에 제공된다.

도 2는 TLL의 실시예 내에서 TLL 시장 데이터 배포 및 거래 주문 실행을 위한 TLL 서버(220)와 POP(210)과 그 연관된 엔티티들 사이의 데이터 흐름을 나타내는 데이터 흐름도를 제공한다. 실시예 내에서, TLL 서버(220), 그 연관된 및/또는 독립된 POP(210), 마켓 센터(240), 시장 참가자(202a-n), HFT 참가자(202x), TLL 데이터베이스(219), 및/또는 이와 유사한 것은, 시장 데이터 업데이트 및/또는 거래 주문 요청을 위해 통신 네트워크(예를 들어, 인터넷, 통신 네트워크, 지불 처리 네트워크, 전화 네트워크, 셀룰러 네트워크, 무선 근거리 통신망, 3G/4G 네트워크 등)를 통해 상호작용할 수 있다.

한 실시예에서, 다양한 시장 참가자들(202a-n)은 매수 및/또는 매도 요청(201a-b) 등의 거래 주문을 위해 마켓 센터(240)와 통신할 수 있다. 한 구현에서, 이러한 시장 참가자들은, 개별 거래자, 브로커, 포트폴리오 관리자, 및/또는 이와 유사한 것을 포함할 수 있지만, 이것으로 제한되지 않는다. 한 구현에서, 이러한 주문 데이터(201a-b)는 시장 참가자(202a-b)로부터 마켓 센터(240)로 직접 제출되지 못하고, 후술되는 바와 같이, POP(210)을 통해 라우팅될 수 있다.

한 구현에서, 마켓 센터(240)는, NASDAQ, NYSE, BATS, Direct Edge, Euronext, ASX, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 하나 이상의 중앙집중형 및/또는 분산형 전자 거래 플랫폼 및/또는 시장 거래소를 포함할 수 있다. 한 구현에서, 마켓 센터(240)는 매수/매도 데이터 공급(204)을 취득 및 업데이트할 수 있고, 이러한 시장 데이터 업데이트(206)를 참가자에 제공할 수 있다. 한 구현에서, 이러한 시장 데이터 업데이트(206)는, HFT 참가자(202x)에 직접 제공되는 사유 공급을 포함할 수 있다. 예시의 실시간 시장 데이터 공급은, ITCH 프로토콜 및/또는 기타의 전자 거래 프로토콜을 통해, Google, Knoema, Netfonds, Oanda, Quandl, Yahoo, Xignite, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 다양한 금융 데이터 벤더로부터의 데이터 공급을 포함하는 CSV 파일 포맷을 포함할 수 있다. 한 구현에서, HFT 참가자(202x)는 시장 데이터 정보를 얻기 위해 CSV 파일을 파싱(parse)할 수 있다. Quandl로부터의 CSV 파일을 테스팅하는 의사-코드 세그먼트의 예는 다음의 것과 유사한 형태를 취할 수 있다:

또 다른 구현에서, 마켓 센터(240)는, XML에 따라 포맷팅된 데이터 형태로 HFT 참가자(202x)에 대한 시장 데이터 공급을 포함하는 HTTP(S)((Secure) Hypertext Transfer Protocol) POST 메시지를 생성할 수 있다. 실질적으로 XML-포맷팅된 데이터를 포함하는 HTTP(S) POST 메시지 형태의 시장 데이터 공급(206)의 예시적 목록이 이하에 제공된다:

한 구현에서, HFT 참가자(202x)는, 시장 데이터 공급(206)의 취득시, 그들의 거래 전략에 기초하여 거래 주문(207)을 생성, 예를 들어, 가장 최신의 매수 및 매도 가격 등에 기초하여 매수 요청(bidding request)을 생성하고, 주문 제출을 위한 POP을 발견/질의할 수 있다. 예를 들어, 한 구현에서, TLL은, 거래 주문을, 참가자의 지리적 위치, 의도된 거래 교환 타입, 및/또는 이와 유사한 것에 기초하여 POP으로 라우팅할 수 있다. 예를 들어, HFT 참가자(202x)는 PHP/SQL 커맨드를 발행하여 POP에 대해 (도 6의 POP(919c) 등의) 데이터베이스 테이블에 질의할 수 있다. 실질적으로 PHP/SQL 커맨드 형태로 된, HFT 참가자의 위치와 의도된 거래 교환에 기초한 POP(210)에 대한 질의를 나타내는 예시의 POP 질의(207)가 이하에 제공된다:

HFT 참가자(202x)는 매수/매도 요청(209)을 제출할 수 있고, 이러한 요청은 POP(210)에 전달된다. 예를 들어, 매수/매도 요청(209)을 포함하는 거래 주문은 전자 거래 사용자 인터페이스를 통해 개인에 의해 입력될 수 있으며, 예를 들어, 도 4b 등을 참조한다. 또 다른 예에서, 거래 주문은, 블랙박스 거래 시스템, 주문 엔트리(예를 들어, FIX 프로토콜 등), 자동 데이터 거래 센터, 및/또는 이와 유사한 것을 통해 입력될 수 있다. 실질적으로 XML-포맷팅된 데이터 형태인, 매수/매도 요청 메시지(209)의 예시적 목록이 이하에 제공된다:

한 구현에서, POP(210)은, 예를 들어, 지리적 위치 근접성 등에 기초하여, 마켓 센터(240)와 동일한 장소에 하우징(house)될 수 있다. 또 다른 구현에서, POP(210)은, 중앙집중형 TLL 서버(220)와 통합될 수 있고, 예를 들어, 모든 거래 주문은 집행을 위해 마켓 센터(240)로 라우팅되기 이전에 원격 POP/TLL 서버에 라우팅될 수 있다.

한 구현에서, POP(210)은, HFT 참가자(202x)(및/또는 기타의 참가자)로부터 매수/매도 요청(209)을 수신하면, 주문 요청(211)을 TLL(220)에 전달할 수 있고, TLL(220)은 그 주문 요청을 집행을 위해 마켓 센터(240)로 라우팅할 수 있다. 한 구현에서, 예를 들어, 그 물리적 위치가 마켓 센터(240)로부터 더 멀리 있거나 및/또는 비교적 느린 통합된 시장 공급을 수신하는 등의 다른 마켓 참가자들(202a-n)은 시장 데이터 업데이트(212a-b)를 수신할 수 있다. 한 구현에서, 시장 참가자(202n)는 유사하게 매수/매도 요청(214)을 제출할 수 있고, 이 요청은 POP(210)으로 라우팅될 수 있다.

한 구현에서, POP(210)은, 예를 들어, 케이블 접속 등과 같은 통신 링크를 통해, 수신된 매수/매도 요청(예를 들어, 209, 214 등)을 수신하여, 매수/매도 데이터(215)를 포함하는 거래 주문을 집행을 위해 TLL(220)에 제출할 수 있고, 및/또는 TLL로부터 집행을 위한 마켓 센터(예를 들어, 또 다른 거래소 등)(240)로 라우팅되는 거래 주문을 제출할 수 있다. 한 구현에서, 이러한 거래 주문(215)은 예를 들어 의사-동기화된 방식(pseudo-synchronized manner) 등으로 일괄적으로 전송될 수도 있다. 또 다른 구현에서, POP(210)은 매수/매도 데이터(215)를 집행을 위한 마켓 센터(240)에 제출하는 "시간"을 "홀드(hold)" 및/또는 추정할 필요가 없는데, 그 이유는, POP(210)에서의 전송 매체(예를 들어, 케이블, 마이크로파 등)를 통한 재-라우팅은 본질적으로 레이턴시를 생성해 HFT 참가자(202x)로부터의 거래 주문(209)이 다른 참가자(202a-n)로부터의 거래 주문(214)에 관해 차익거래를 갖지 못할 것이기 때문이다.

한 구현에서, TLL(220) 및/또는 마켓 센터(240)는, 예를 들어, 임의의 매수/매도가 정합할 경우 트랜잭션을 용이하게 하기 위해, 수신된 주문(216)을 집행할 수 있다. 한 구현에서, TLL은 TLL 서버(220)가 TLL 데이터베이스(219)에 저장하기 위한 트랜잭션 레코드(218)(예를 들어, TLL(220)에서 실행된 거래 및/또는 다른 마켓 센터(240)에서 실행된 거래에 관련된 정보 등)를 생성할 수 있다. 한 구현에서, POP(210)은, 거래 주문이 POP을 통해 전달될 때 트랜잭션 레코드(218)에 타임스탬프를 배치할 수 있다. 예를 들어, 이러한 트랜잭션 레코드(218)는, TLL 서버(220)가 차익거래가 성공적으로 감소했는지를 분석하기 위해 HFT 주문 및 기타의 시장 참가자(202a-n)로부터의 주문에 관한 타이밍 파라미터를 포함할 수 있다. 이러한 레코드(218)는, 주기적으로, 간헐적으로 및 지속적으로, 및/또는 TLL 서버(220)로부터의 요청에 기초하여 생성될 수 있다.

실질적으로 XML-포맷팅된 데이터 형태인, 트랜잭션 레코드(218)의 예시적 목록이 이하에 제공된다:

도 3은 TLL의 실시예 내에서 POP 라우팅을 통한 레이턴시 차익거래 감소의 양태들을 나타내는 로직 흐름을 제공한다. 실시예 내에서, 다양한 시장 참가자는 주문 요청을 마켓 센터에 제출할 수 있다(예를 들어, 301). 이러한 주문 요청은 마켓 센터에 직접 제출되거나, 및/또는 도 2에서 논의된 바와 같이 POP에 제출되어 집행을 위한 TLL에 전달될 수 있다. 한 구현에서, 마켓 센터는 주문 요청(302)을 수신할시 현재의 매수 및 매도 가격 목록(304)을 업데이트할 수 있다. 또 다른 구현에서, 마켓 센터는 데이터 거래소로부터의 매수 및 매도 가격 목록 데이터, 예를 들어, NBBO 등을 획득할 수 있다.

한 구현에서, 마켓 센터는, HFT 참가자, 및/또는 기타의 비-HFT 참가자를 포함한, 다양한 시장 참가자들에게 데이터 공급을 제공할 수 있다. 한 구현에서, 도 1b에서 논의된 바와 같이, HFT 참가자는, 사유 공급에 가입되어 있을시, 시장 업데이트를 더 빠르게 수신(306)할 수 있고, 그에 따라 수신된 사유 공급에 기초하여 거래 주문을 생성(307)할 수 있다. HFT 참가자는, 예를 들어, HFT 참가자의 물리적 위치, 거래 요청에 포함된 금용 상품의 타입, 의도된 교환, 및/또는 이와 유사한 것에 기초하여, 레이턴시를 야기(310)하는 POP 액세스 포인트에서 수신될 수 있는 거래 요청을 제출(309)할 수 있다. 한 구현에서, POP은, 거래 요청을, 주문을 수신 및 라우팅(311)할 수 있는 TLL에 전달할 수 있고, HFT 참가자로부터의 주문 요청을 홀드할 필요가 없을 수 있다(311). 한 구현에서, TLL은 TLL에서 거래 주문을 집행하거나, 및/또는 집행을 위해 또 다른 데이터 센터로 라우팅할지를 결정(312)할 수 있다. 라우팅하지 않는다면, TLL은 주문을 집행(319)할 수 있다.

또 다른 구현에서, 다른 시장 참가자들, 예를 들어, 비-HFT 참가자들은, 상대적 레이턴시를 가질 수도 있는, 예를 들어, 통합된 시장 데이터 공급을 통해 시장 업데이트를 수신(313)할 수 있다. 한 구현에서, 시장 참가자는 거래 주문을 생성하고 매수/매도 요청을 포함하는 이러한 주문을 TLL POP에 제공(314)할 수 있다. 대안적 구현에서, 마켓 센터에 대한 가까운 물리적 위치를 향유하지 못하는 비-HFT 시장 참가자의 경우, TLL은 이러한 참가자들에게 거래 주문을 POP에 제출할 것을 요청하거나 요청하지 않을 수 있다.

한 구현에서, TLL/POP이 거래 주문을 방출할시(312), 마켓 센터는 주문을 수신 및 집행(315)할 수 있다. 예를 들어, 마켓 센터는 주문을 파싱하여 금융 상품 ID, 매수/매도 가격을 검색하고, 성공적인 매수(successful bid)를 구성하는지를 결정(316)한다. 그렇다면, 마켓 센터는, 주문 트랜잭션을 용이하게 하고, 새로운 트랜잭션에 기초하여 현재의 매수 및 매도 가격 목록을 업데이트(317)할 수 있다.

한 구현에서, TLL/POP은, 주문 라우팅 및 레이턴시의 타이밍 파라미터를 기록할 수 있고 차익거래 감소 성능의 분석에 이용될 수 있는 POP 레코드를 생성(318)할 수 있다(예를 들어, 도 2의 218 등 참조).

도 4a 및 도 4b는, TLL의 실시예 내에서 TLL POP 라우팅 시스템 구성 및/또는 고객 설정을 나타내는 예시적 UI 도면을 제공한다. 도 4a는 POP 할당을 위한 예시적 관리 UI를 제공한다. 예를 들어, 한 구현에서, TLL 관리자는, 예를 들어, 우편 번호 및/또는 지역 번호(412)별로 배열된 POP 엔티티(411)의 분포를 보여줄 수 있다. 한 구현에서, 도 4a에 도시된 바와 같이, TLL 대쉬보드는 지역 내의 각 POP의 위치와, POP 엔티티(413)에 관한 상세사항, 예를 들어, 서버 IP, 주소, 서빙 거래소/마켓 센터(serving exchange/market center)까지의 거리(전송 시간) 등을 제공할 수 있다. 한 구현에서, TLL 관리자는 하나 이상의 POP 엔티티에 HFT 참가자(416)를 할당할 수 있다. 예를 들어, 이러한 할당은, HFT 참가자의 지리적 위치, 거래량, 거래 패턴, 의도된 교환, 및/또는 이와 유사한 것에 기초할 수 있다. 구현 내에서, TLL과 기타의 마켓 센터 사이의 거리는 POP 위치 결정에서 인자가 될 수 있다; 다른 구현에서, 이러한 거리는, POP "거리"는 케이블 길이 등에 의해 캘리브레이팅될 수 있기 때문에 고려되지 않을 수도 있다. 다른 마켓 센터에 관한 POP의 위치는, POP이 다른 마켓 센터로부터 멀리 떨어져 있고 그에 따라 거리가 레이턴시를 너무 많이 증가시키고 과잉 보상하여(over compensate) 참가자들에 대한 열악한 거래 경험을 잠재적으로 초래할 수 있다면 중요해질 수 있다.

예를 들어, TLL은 TLL 관리자에 대해 상이한 POP 엔티티를 셋업할 수 있다. 예를 들어, TLL은 NYSE로 향하는 임의의 주문에 대해 New Jersey에 위치한 POP을 HFT 참가자에 할당할 수 있다(417); 또는 NASDAQ으로 향하는 임의의 주문에 대해 New York에 위치한 POP을 할당(418)할 수 있는 등등이다. 한 구현에서, TLL은, 예를 들어, 할당된 POP으로부터 의도된 데이터 거래소까지의 추정된 전송 시간 등을 보여줌으로써, 관리자가 그 할당을 테스팅하는 것을 허용할 수 있다.

도 4b를 참조하면, 일부 구현에서, 브로커의 고객은 포트폴리오를 검토하기 위해 웹-기반의 대쉬보드 애플리케이션에 로그인할 수 있다. 예를 들어, 고객은 라이브 매수 및 매도 공급(401)의 목록을 볼 수 있고, 설정(406-407)을 수정하기 위해 고객 투자 프로파일(405)을 볼 수도 있다.

예를 들어, 고객은 브로커가 내린 주문의 집행에 관한 조건을 설정하기를 원할 수도 있다. 브로커는 일반적으로 그 고객의 지시를 준수할 필요가 있지만, 현재의 시장에서 브로커는 고객의 주문이 어떻게 집행될지에 관해 어느 정도의 재량권을 가질 수 있으므로, 시장이 브로커의 재량에 따라 궁극의 고객 지시와는 상이할 수 있는 주문을 실행하는 것을 허용한다.

한 구현에서, TLL은, 브로커의 고객이 시장에 직접 자유재량 설정(407)을 구성하는 것을 허용하는 UI를 제공할 수 있다. 이들 설정은 다음과 같은 인자들 중 하나 이상에 기초하여 고객이 거래하고자 할 때를 표시할 수 있다: 심볼, 시가 총액, 역사적 스프레드와 비교한 현재의 스프레드, 표시된 유동성, 상관된 상품 가격, 전략 유형, 일일 평균 거래량, 일일 평균 거래량에 비교한 주문 크기, 최소 충족 크기(minimum fill size), 명목 가치(notional value), 최소 거래 크기, 자유재량 가격, 및/또는 긴급성, 주문 유형, 및/또는 이와 유사한 것.

한 구현에서, 고객은 브로커에게 고객을 식별하는 표시와 함께 주문을 시장에 라우팅할 것을 지시할 수 있다. 시장은 그 표시를 인식하고, 주문을 고객에 의해 이전에 설정된 자유재량 설정과 정합하며, 주문을 집행하는데 있어서 고객의 자유재량 설정을 따를 수 있고, 이것은, 세부조항이 모호성을 낳고 결과적인 주문 취급처리가 잠재적으로 브로커에 대한 고객의 지시와 상반되거나 고객의 최상의 이익과 상반되는 경우 브로커가 고객 주문 지시로부터 이탈하는 능력을 제거할 수 있다.

예를 들어, 고객은 설정(416-418)을 통해 "전부 합성 또는 합성없음(synthetic all or none)" 주문 타입을 구성할 수 있다. 한 구현에서, 전자 거래 주문은 "모 아니면 도(all-or-none)"(AON) 방식으로 실행될 수 있고, 이것은 전체 주문을 채우기에 충분한 유동성이 시장에 있을 때에만 집행될 수 있다. 주문의 일부만을 충족시키기에 충분한 유동성만이 있다면, AON으로 마킹된 주문은 전혀 집행되지 않는 반면, AON으로 마킹되지 않은 주문은 유동성에 대하여 실행될 수 있고 부분적으로는 충족되지 않고 남는다. 한 구현에서, 이 주문 타입의 제한은, 이것은 단일 시장의 유동성에 대하여 실행될 수만 있다는 것이다. 예를 들어, 이러한 AON 주문은 하나보다 많은 시장으로부터의 유동성으로 충족되지 않을 수 있다.

한 구현에서, TLL은 "합성 AON(Synthetic AON)" 주문 타입을 실행할 수 있다. 예를 들어, 이 주문 타입에서, 시장 참가자는 집행될 최소량과 참가자가 주문을 집행하는 가격을 명시할 수 있다. TLL은, 최소량이 TLL 자체에서의 디스플레이된 및 비-디스플레이된 유동성과 TLL이 주문을 라우팅하는 다른 모든 거래 장소 상의 표시된 유동성의 총량에 대하여 실행될 수 있다. 명시된 가격보다 시장 참가자에게 덜 우호적이지 않은 가격에서 주문을 집행할 충분한 결합된 유동성이 있다면, 그 주문은 TLL에서 부분적으로 집행되고 부분적으로는 다른 거래 장소로 라우팅되어, 최소량이 주문의 집행된 부분과 주문의 라우팅된 부분에 의해 충족될 것이다. 하나 이상의 라우팅된 주문이 부분적으로 충족되거나, 전혀 충족되지 않는 것이 가능하므로, 전통적인 AON 주문 타입과는 달리, 합성 AON 주문은 "최상의 노력" 기반으로 실행된다. 라우팅된 주문 실행 및 TLL 집행을 신호로서 이용하고 TLL 라우팅된 주문을 다른 마켓 센터에 레이싱(racing)시킴으로써 합성 AON 주문 타입을 이용하는 다른 참가자의 능력에 미치는 TLL에 의해 집행된 초기 거래의 영향을 최소화하기 위해, TLL은, 주문(들)을 라우팅할 때, 라우팅된 주문이 그들의 목적지에 레이싱될 확률을 제거하도록 충분히 멀리 이동할 때까지 어떠한 시장 참가자도 TLL 주문 실행에 관한 정보를 수신하지 않을 것이라는 것을 보장한다. 이 프로세스는 전술된 POP(point of presence) 설비의 이용을 포함할 수 있다. 한 구현에서, POP 구조는 합성 AON 주문의 유효성을 향상시킬 수 있지만, 완전한 충족(full fill)의 임의의 일반적인 보증서가 될 수는 없다.

추가의 구현에서, TLL은, 다양한 인자들, 예를 들어, 가격, 디스플레이(display), 브로커, 시간 우선권 등에 따라 주문을 정합 및/또는 우선순위화할 수 있다. 주문장에서 최상의 가격책정된 주문은 다른 모든 주문에 관해 선행권(precedence)을 가질 수 있다. 동일한 가격에서, 디스플레이된 주문은 비-디스플레이된 주문에 비해 선행권을 가질 수 있다. 동일한 가격 및 디스플레이 상태에서, 브로커의 레스팅 주문들은, 브로커의 주문이 주문장에 대하여 테스팅중일 때, 다른 브로커의 주문들에 비해 선행권을 가질 수 있다. 브로커 자신의 주문들 중에서, Agency로 마킹된 주문은 Principal로 마킹된 주문에 비해 선행권을 가질 수 있다. 동일한 우선권 레벨에서 경쟁하는 모든 주문들 중에서, 가장 오래된 주문이 선행권을 가질 것이다. 주어진 가격의 디스플레이된 모든 주문들 중에서, 시간 우선권에 있어서, 선행권은 먼저 Agency로 마킹된 주문에 주어질 수 있고, 그 다음, 시간 우선권에 있어서, 처리중인 주문과 동일한 가입자에 속하는 Principal로 마킹된 주문에, 그 다음, 시간 우선권에 있어서, 그 가격의 다른 모든 디스플레이된 주문에 주어질 수 있다; 가장 오래된 주문은 더 높은 선행권을 가진다. 주어진 가격의 모든 비-디스플레이된 주문들 중에서, 시간 우선권에 있어서, 선행권은 먼저 Agency로 마킹된 주문에 주어질 수 있고, 그 다음, 시간 우선권에 있어서, 동일한 가입자에 속하는 Principal로 마킹된 주문에, 그 다음, 시간 우선권에 있어서, 그 가격의 다른 모든 비-디스플레이된 주문에 주어질 수 있다; 가장 오래된 주문은 더 높은 선행권을 가진다. 한 구현에서, 비-디스플레이된 주문 및 즉시집행취소(Immediate Or Cancel)("IOC") 주문에 대해, 최소량(Minimum Quantity) 등의 특정한 주문 조건 파라미터가 선택될 수 있다. TLL의 주문장에서 선행권을 갖는 레스팅 주문이 그 특정한 조건 때문에 실행될 수 없는 경우에, 그 레스팅 주문은 그 처리 사이클의 지속기간 동안 주문장에서 선행권을 포기할 것이다.

한 구현에서, TLL이 주문장에 기초하는 주문에 관해 재-가격책정, 디스플레이 리프레시, 주문장 재검사 또는 라우팅 동작(집합적으로 "주문장 행동(Book Action)")을 개시할 때마다, TLL은 가격/시간 우선권에서 이렇게 할 수 있고, 이 때, 행동이 취해지는 주문의 일부의 타임스탬프는 시간 우선권을 결정하는데 이용되며, 주문 또는 주문의 일부의, 주문장 상의 레스팅 가격이 가격 우선권을 결정하는데 이용된다.

한 구현에서, TLL이 디스플레이된 주문, 또는 예약 주문의 디스플레이된 부분을 재-가격책정할 때마다, TLL은, 주문장의 가격/시간 우선권에서의 시간의 결정을 위해, 주문(또는 주문의 일부)에 새로운 타임스탬프를 할당할 것이다.

도 5a 내지 도 5c는 TLL의 실시예 내에서 TLL 네트워크 인프라구조의 양태를 나타내는 예시적 데이터 도면을 제공한다. 한 구현에서, TLL 가입자(510), 예를 들어, 개인 투자자, 거래 엔티티, 및/또는 기타의 시장 참가자는, POP 액세스 포인트, 예를 들어, FIX 프로토콜을 운영하는 액세스 포인트에 접속되어 FIX 엔진(507)과 통신할 수 있다. 한 구현에서, POP FIX/CUST 액세스 포인트는, 거래 엔진(515)을 갖춘 동일한 및/또는 별개의 데이터 센터에 위치한 하드웨어 구조를 포함할 수 있다. 한 구현에서, FIX 엔진(507)은 FIX 프로토콜을 통해 데이터를 수신 및 전송하는 로직 컴포넌트를 포함할 수 있다. 예시의 데이터 메시지 패킷 구조(519d)가 도 5c에서 제공된다.

예를 들어, TLL 가입자(510)는 (예를 들어, 데이터 거래소 그 자체 등으로서 역할하는) TLL 상에서 거래되는 증권을 매수 및 매도하기 위해 FIX API의 이용을 통해 주문을 전자적으로 전송할 수 있다. 한 구현에서, TLL로의 직접적인 액세스는 TLL에 의해 제공된 FIX API를 준수하는 통신을 통해 인터넷 프로토콜("IP") 주소의 가입자들에게 이용가능할 수 있다.

한 구현에서, 시퀀서(506)는 데이터를 파싱하고 거래 엔진(515)에 데이터를 전송할 수 있다. 예시의 데이터 메시지 패킷 구조(519c)가 도 5c에서 제공된다. 한 구현에서, 거래 데이터(예를 들어, 매수/매도 요청 등)는 거래소 게이트웨이(505)에 전송되어 거래소(502), 예를 들어, NYSE(502a), BTLL(502b), EDGE, CHSX, NSX(502c), NASDAQ(502d), 및/또는 이와 유사한 것에서 집행될 수 있다. 한 구현에서, TLL은 거래 데이터를 데이터베이스(519)의 스토리지에 전송할 수 있다; 한 구현에서, TLL은, 내부 웹(511)을 통해 데이터 공급을 발표할 수 있는 CNC를 통해, 및/또는 외부 웹(512)에서 데이터 공급을 발표하는 DMZ 등을 통해 거래 데이터를 발표할 수 있다. 예시의 데이터 메시지 패킷 구조(519a-b)가 도 5b에서 제공된다.

추가의 구현에서, TLL은 주문을 또 다른 마켓 센터로 라우팅하는(도 1d의 134 등을 참조) 다양한 라우팅 옵션을 제공할 수 있다. 라우팅 옵션은 다양한 주문 타입 및 TIF(Time in Force)와 결합될 수 있고, 이에 대해서는, 그 조건이 특정한 라우팅 옵션의 조건과 불일치하는 주문 타입 및 TIF는 예외로 한다. 구현 내에서, TLL은, 시스템이, 먼 거래 장소에 의지할 목적으로 라우팅된 주문을 포함한, 주문들을 라우팅하는 특정한 거래 장소, 및 시스템이 이들을 라우팅하는 순서를 결정하기 위한 하나 이상의 시스템 라우팅 테이블을 유지할 수 있다. TLL은 상이한 라우팅 옵션에 대한 상이한 시스템 라우팅 테이블을 유지하고 통보없이 임의의 시간에 시스템 라우팅 테이블을 수정하는 권한을 보유할 수 있다.

예를 들어, TLL은, 루트 투 테이크(Route to Take) 프로토콜, 예를 들어, 시스템이 가용 주식에 대해 알기 위해 주문장에 대하여 주문을 검사하고 임의의 잔여 미집행된 주식을 즉시집행취소 주문(immediate-or-cancel order)으로서 시스템 라우팅 테이블 상의 목적지에 라우팅하는 라우팅 옵션을 구현할 수 있다. 라우팅 이후에 주식이 미집행되어 남아 있다면, 이들은 주문장에 포스팅된다(posted). 일단 주문장에서 주문이 후속해서 또 다른 액세스가능한 마켓 센터에 의해 락킹되거나(locked) 크로싱된다(crossed)면, 시스템은, 가입자(예를 들어, 고객, 투자자 등)에 의해 재-라우팅가능한 것으로 마킹된 경우 그 주문 또는 주문의 일부를 락킹 또는 크로싱 마켓 센터에 라우팅할 수 있다.

또 다른 예로서, TLL은, TLL 시스템이 가용 주식에 대해 알기 위해 주문장에 대비해 주문을 검사하고 임의의 잔여 미집행된 주식을 즉시집행취소 주문으로서 시스템 라우팅 테이블 상의 목적지에 라우팅하는, 루트 투 레스트(Route to Rest) 프로토콜을 구현할 수 있다. 라우팅 이후에 주식이 미집행되어 남아 있다면, 시스템은, TLL 라우팅 테이블에 의해 결정되는 바와 같이, 주문의 디스플레이 크기를 주문장과 또 다른 장소 사이에서 분할할 것이다. 임의의 집행이 프리-마켓 세션(Pre-Market Session) 또는 포스트-마켓 거래 세션(Post-Market Trading Session) 동안에 TLL에서 발생하기 위해, 적용가능한 주문 가격은, 그 주문이 ISO로 마킹되어 있거나 자동 시세 매수(Automated Quotation Bid)가 자동 시세 매도(Automated Quotation Offer)를 크로싱하지 않는 한(또는 집행이, 예를 들어, 규정 NMS의 규칙 611(b)에 개시된 예외와 유사한, 또 다른 조건 내에 들지 않는 한), 가장 높은 자동 시세 매수(Automated Quotation Bid) 또는 가장 낮은 자동 시세 매도(Automated Quotation Offer)("NBBO")와 같거나 더 양호해야 한다.

한 구현에서, 가입자 주문 지시에 의해 달리 명시되지 않는 한, 인입하는 주문은 먼저 주문장에 대하여 실행 정합을 위해 테스팅될 수 있고, 임의의 미집행된 주식은 취소되거나, 주문장에 포스팅될 것이며, 또는 라우팅된 집행은, 매수 주문과 매도 주문이 주문장에서 정합할 때 발생할 수 있고 먼 장소로 라우팅된 주문이 그 장소에 의해 정합될 때 발생할 수 있다. 시스템은, 미집행된 주문 또는 먼 장소로 라우팅된 주문들로부터 되돌아오는 주문들의 일부를 포함한, 시스템에 인입하는 주문들을 그 주문들이 수신되는 순서로 처리할 것이다. 주문 또는 주문의 일부는 먼 장소로 라우팅되지만, 이들 주문 또는 주문의 일부는 시스템 인입 주문 처리 큐(System incoming order process queue)의 일부가 아니어서, 후속되는 순차적 주문의 처리가 우선권을 갖는 것을 허용한다.

주문장에 제출된 주문들을 실행하는데 있어서, 시스템은, 브로커 우선권(Broker Priority) 기능을 제외하고는, 자신의 계정을 위해 가입자에 의해 제출된 주문과 고객을 위해 가입자에 의해 제출된 주문 사이를 구분하지 않을 수 있다. 브로커 우선권(Broker Priority) 내에서, 주어진 브로커에 대해서 레스팅 Principal 주문들에 비해 레스팅 Agency 주문에 우선권이 주어진다.

한 구현에서, 가입자들은 원격 위치로부터 시스템에 주문을 제출할 수 있고 주문장에 존재하는 주문에 동등한 액세스를 가진다. 마찬가지로, TLL 상의 주문은 자동으로 집행될 수 있고, 어떠한 가입자도 집행 이전에 주문을 변경 또는 취소하는 것 이외의 집행의 타이밍을 제어하는 능력을 갖지 못할 수 있다. 주문장에 제출된 매수 주문은, 주문장에 제출된 동일한 증권에 대한 임의의 매도 주문과 같거나 이를 초과하는 양에서 가격책정되는 범위까지, 및 제출하는 가입자에 의한 이러한 주문에서 선택된 임의의 특정한 조건이 만족되는 범위까지, 시스템에 의해 자동으로 집행될 수 있다. 이러한 매수 주문은 주문장에서 선행권을 갖는 가장 낮은 가격의 매도 주문의 가격에서 집행될 수 있다.

한 구현에서, 주문장에 제출된 매도 주문은, 주문장에 제출된 동일한 증권에 대한 임의의 매수 주문과 같거나 작은 양에서 가격책정되는 범위까지, 및 제출하는 가입자에 의한 이러한 주문에서 선택된 임의의 특정한 조건이 만족되는 범위까지, 시스템에 의해 자동으로 집행될 수 있다. 이러한 매도 주문은 주문장에서 선행권을 갖는 가장 높은 가격의 매수 주문의 가격에서 집행될 수 있다. 레스팅 주문의 전체 크기 미만이 집행되는 경우, 디스플레이되든 비-디스플레이되든, 주문의 미집행된 크기는, 가입자의 지시와 일치하여, 계속 주문장에 존재할 수 있고, 디스플레이된다면, 이러한 가격에서 재디스플레이될 수도 있다. 이러한 부분적으로 집행된 주문은 동일한 가격에서 우선권과 선행권을 유지한다. 주문장 또는 NBBO의 변경시, 인바운드 메시지(inbound message)의 처리의 일부로서, 시스템은 그 시장의 한측 또는 양측상의 주문들을 주문장의 반대측과 대조하여 테스팅해 시장 내부의 TLL이나 NBBO에서의 변경의 결과로서 새로운 집행이 발생할 수 있는지를 결정할 수 있다. 최소량 조건, 및/또는 현재 주문장에 기초하고 있는 가격보다 더욱 공격적인 제한을 갖는 비-디스플레이된 레스팅 주문은, 최초에 예약되었을 때, 자격미달이었거나, 주문의 조건을 만족하지 않았던, 업데이트된 주문장 내의 주문들에 대하여 거래될 자격이 있다. 레스팅 주문들은 각각의 예약된 가격/시간 우선권(booked price/time priority)에 따라 재검사된다. 주문장을 재검사하는 주문은 보호 시세(Protected Quotations) 또는 주문장의 반대측 상의 레스팅 주문을 통해 거래되지 못할 수 있다.

TLL이 NBBO와 같거나 더 양호한 가격의 적격의 주식을 갖지 않는 경우, 또는 모든 이러한 적격의 주식들이 소진되었고 미집행된 주식이 남아 있을 경우, 시스템은 라우팅 적격성에 기초하여 인입 주문들을 처리할 수 있다. 라우팅에 적격인 것으로 마킹되고 NBBO에 대하여 마켓팅가능한 주문의 경우, 시스템은, 가입자 주문 지시, 주문 타입 및 라우팅 전략 정의, 및 "TLL 라우팅 테이블"과 일치하는 방식으로, 우월한 가격의 보호 시세(Protected Quotations)를 디스플레이하고 있는 먼 거래 센터로 라우팅할 수 있다.

도 6a 내지 도 6h는 EBOM의 실시예 내에서 추가의 데이터 전송 레이턴시를 야기하는 네트워크 액세스 포인트를 통한 레이턴시 차익거래 및 주문장 차익거래를 관리하기 위한 다양한 시나리오를 나타내는 예시적 도면을 제공한다. 한 구현에서, 시장 참가자는, 대체가능 증권(fungible securities)을 거래하는 거래소들(및/또는 기타의 마켓 센터들) 사이의 데이터 전송 레이턴시 차이를 이용할 수 있다. 한 구현에서, 레이턴시 차익거래는, 브로커가 투자자를 위해, BSOR(Broker Smart Order Router)을 통해 시장들 사이에서 주문의 라우팅을 책임지는 때; 또는 거래소(또는 기타의 마켓 센터)가, 브로커와 투자자 모두를 위하여, ESOR(Exchange Smart Order Router)을 통해 시장들 사이에서 주문의 라우팅을 책임지는 때, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 시나리오에 적용될 수 있다.

도 6a는 BSOR을 통해 유발되는 레이턴시 차익거래의 양태를 도시하는 예를 나타낸다. 예를 들어, 거래소 1(605a)은 $10.00에서 XYZ 주식의 1000주를 매도하는 오퍼(offer)를 가지고 있을 수 있고 거래소 2(605b)는 $10.00에서 XYZ의 2000주를 매도하는 오퍼를 갖고 있을 수 있다(거래소 2(605b) 상의 오퍼는 이전에 HFT(606)에 의해 입력되었다. 전국 최상 오퍼는 $10.00에서 매도하는 XYZ의 3000주의 결합된 매도 가격이다).

한 구현에서, 투자자(614)는 $10.00에서 XYZ의 3000주를 매수하기를 원할 수 있고 후속해서 $10.00에서 3000주의 XYZ를 매수하기 위해 브로커(615)에 주문을 전송할 수 있다. 투자자의 주문을 수신하면, 브로커(615)는 매수 주문 A(613a)를 거래소 1(605a)에 라우팅하여 $10.00에서 XYZ의 1000주를 매수하고 매수 주문 D(613d)를 거래소 2(605b)에 라우팅하여 $10.00에서 XYZ의 2000주를 매수할 수 있다. 주문 A(613a)와 주문 D(613d)는 브로커(614)로부터의 거래소 1(605a)과 거래소 2(605b)의 물리적 거리(및 그에 따른 케이블, 마이크로파 등과 같은 물리적 전송 매체를 따르는 상이한 전송 시간)로 인해 상이한 레이턴시를 가질 수 있다; 접속성, 네트워크 장비, 정보 기술 인프라구조, 네트워크 회로 저항, 및 다양한 기타의 이유 등의 다른 요인들도 마찬가지로 전송 시간에서의 상이한 레이턴시를 야기할 수 있다.

한 구현에서, 브로커 주문 A(613a)는 거래소 1(605a)에 도달할 수 있고, 투자자(614)는 (예를 들어, 브로커(615)를 통해) 거래소 A 상에서 $10.00에서 1000주의 매수를 나타낸다. 한 구현에서, HFT는 거래소 1(605a)로부터 거래 보고 B(613b)를 수신할 수 있다. 한 구현에서, 동일 장소 소재는 HFT가 "수십 마이크로초"만에 거래 보고 B(613b)를 수신하는 것을 허용한다. 한 구현에서, HFT는, $10.00에서 XYZ에 관해 거래소 1(605a)에서 거래가 발생했다는 지식으로부터 수익을 얻기 위한 시도로서, 예를 들어, 또 다른 매수 주문(D)이 거래소 2(605b)로 라우팅되는 중에 있다고 예상하고 주문 C(613c)를 $10.01의 가격으로 상향 조정함으로써, ($10.00에서 2000주의 XYZ를 매도하는 이전에 입력된 주문의) 주문 개정(order revision) C(613c)를 거래소 2(605b)에 전송할 수 있다. 이 예에서 $10.00에서 매수하는 제한을 갖는 주문 D(613d)는 집행되지 못할 것이고, 브로커는 $10.01에서 매수하기 위해 또 다른 주문을 전송해야만 할 수 있다. 순 결과는, 새로운 매수 주문이 거래소 2(605b) 상에서 집행된다면, 투자자(614)는 XYZ의 나머지 2000주를 매수하기 위해 $20.00($.01*2000 = $20.00)을 더 지불하게 될 수 있다는 것이다. 주문 C(613c)의 레이턴시는 접속성과 정보 수송 방법(예를 들어, 마이크로파 대 섬유)에 의해 결정될 수 있다. 따라서, 레이턴시(A의 전송 시간 + B의 전송 시간 + C의 전송 시간) < D의 전송 시간이면, (투자자(614)를 대신하여) 브로커(615)는 거래소 2(605b)에서 $10.00에서의 XYZ의 2000주의 매수 주문을 집행할 수 없을 수 있다. 그 결과, 주문이 그 순간 미충족으로 되거나, 투자자(614)는 나머지 2000주를 매수하기 위해 더 높은 가격을 지불해야 할 수 있다.

도 6b는 EBOM의 실시예 내에서 POP 액세스 포인트의 예방(inoculation)과 함께 BSOR을 통해 레이턴시 차익거래를 관리하는 양태를 나타내는 예를 도시한다. 한 구현에서, 거래소 1(605a)은 $10.00에서 XYZ 주식의 1000주를 매도하는 오퍼를 가지고 있을 수 있고 거래소 2(605b)는 $10.00에서 XYZ의 2000주를 매도하는 오퍼를 갖고 있을 수 있다(거래소 2(605b) 상의 오퍼는 이전에 HFT(606)에 의해 입력되었다. 전국 최상 오퍼는 $10.00에서 매도하는 XYZ의 3000주의 결합된 오퍼이다). 투자자(614)는 $10.00에서 XYZ의 3000주를 매수하기를 원할 수 있고 $10.00에서 3000주의 XYZ를 매수하기 위해 브로커(615)에 주문을 전송할 수 있다. 브로커(615)는 투자자(614)의 주문을 수신하고 $10.00에서 XYZ의 1000주를 매수하는 매수 주문 A를 거래소 1(605a)에 라우팅하고 $10.00에서 XYZ의 2000주를 매수하는 매수 주문 D를 거래소 2(605b)에 라우팅한다. 주문 A와 주문 D는 브로커(615)로부터 거래소 1(605a)와 거래소 2(605b)까지의 물리적 거리, 접속성, 네트워크 장비, 및 다양한 다른 이유로 인해 상이한 레이턴시를 가진다; 접속성, 네트워크 장비, 정보 기술 인프라구조, 네트워크 회로 저항, 및 다양한 기타의 이유와 같은 다른 요인들은 역시 전송 시간에서의 상이한 레이턴시를 야기할 수 있다.

브로커(615)의 주문 A(613a)는 거래소 1(605a)에 도달하고, 투자자(614)는 (브로커(615)를 통해) 거래소 1(605a) 상에서 $10.00에서 1000주를 매수한다. HFT(606)는 POP(610)으로부터 거래 보고 B(613b)를 수신한다. EBOM POP 아키텍쳐 POP(610)은 임의의 EBOM 가입자(HFT(606)를 포함)가 "수백 마이크로초"만에 거래 정보를 (Aii의 전송 시간 + B의 전송 시간) 수신하는 것을 허용한다.

한 구현에서, HFT(606)는, XYZ에 관해 거래소 1(605a)에서 거래가 발생했다는 지식으로부터 수익을 얻기 위한 시도로서, 예를 들어, 또 다른 매수 주문(D)이 거래소 2(605b)로 라우팅되는 중에 있다고 예상하고 주문 C를 $10.01의 가격으로 상향 조정함으로써, ($10.00에서 2000주의 XYZ를 매도하는 이전에 입력된 주문의) 주문 개정 C(613c)를 거래소 2(605b)에 전송할 수 있다. 이 예에서 $10.00에서 매수하는 제한을 갖는 주문 D는 집행되지 않을 것이고, 브로커(615)는 $10.01에서 매수하기 위해 또 다른 주문을 전송해야만 할 수 있다. 순 결과는, 새로운 매수 주문이 거래소 2(605b) 상에서 집행된다면, 투자자는 XYZ의 나머지 2000주를 매수하기 위해 $20.00($.01*2000 = $20.00)을 더 지불할 수 있다는 것이다. 주문 C의 레이턴시는 접속성과 정보 수송 방법(예를 들어, 마이크로파 대 섬유)에 의해 결정될 수 있다.

그러나, EBOM POP 아키텍쳐 POP(610)은, (A의 전송 시간 + Ai의 전송 시간 + Aii의 전송 시간 + B의 전송 시간 + C의 전송 시간) > D의 전송 시간이므로, HFT(606)가 거래 보고 B를 수신하여 이것을 신호로서 이용할 수 있기 이전의 시간량에 (거리나 매체를 통한) 레이턴시를 추가하는 레이턴시 차익거래로부터 고객의 주문을 보호할 기회를 BSOR에게 허용할 수 있다. 이 경우에, (투자자(614)를 대신하여) 브로커(615)는, HFT(606)의 주문 개정 C(613c)가 거래소 2(605b)에 도달하기 이전에, 거래소 2(605b) 상에서 $10.00로 XYZ의 2000주의 매수 주문 D(613d)를 집행할 충분한 시간을 가질 수 있다. 그 결과, 주문 A(613a)는 제한 가격에서 완전히 충족될 수 있고 투자자(614)는 도 6a에 도시된 바와 같이 새로운 매수 주문을 통해 나머지 2000주를 매수하기 위해 더 높은 가격을 지불해야 할 필요가 없다.

도 6c는 EBOM의 실시예 내에서 ESOR을 통해 유발되는 레이턴시 차익거래를 나타내는 예를 제공한다. 일 구현에서, 거래소 1(605a)은 $10.00에서 XYZ 주식의 1000주를 매도하는 오퍼를 가지고 있을 수 있고 거래소 2(605b)는 $10.00에서 XYZ의 2000주를 매도하는 오퍼를 갖고 있을 수 있다(거래소 2(605b) 상의 오퍼는 이전에 HFT(606)에 의해 입력되었다. 전국 최상 오퍼는 $10.00에서 매도하는 XYZ의 3000주의 결합된 매도 가격이다). 투자자(614)는 $10.00에서 XYZ의 3000주를 매수하기를 원할 수 있고 $10.00에서 3000주의 XYZ를 매수하기 위해 브로커(615)에 주문을 전송할 수 있다. 브로커(615)는 거래소 1(605a)의 스마트 주문 라우터(Smart Order Router)(ESOR)를 이용하기를 원할 수 있고, 주문을 수신한 후에, $10.00에서 XYZ의 3000주를 매수하는 전체 주문 A(613a)를 거래소 1(605a)로 라우팅할 수 있다. 거래소 1(605a)은 이제, (투자자(614)를 위한) 브로커(615)를 대신하여 2000주에 대한 매수 주문 D(613d)를 거래소 2(605b)로 라우팅할 책임을 진다.

한 구현에서, 브로커(615)의 주문 A(613a)는 거래소 1(605a)에 도달할 수 있고, 투자자(614)는 (브로커(615)를 통해) 거래소 1(605a)에서 $10.00에서 1000주를 매수할 수 있다. 주문을 집행한 후에, 거래소 1(605a)은, 거래소 1(605a)의 ESOR을 이용하여 나머지 2000주를 위해 매수 주문 D(613d)를 거래소 2(605b)에 라우팅한다.

한 구현에서, HFT(606)는 거래소 1(605a)로부터 거래 보고 B(613b)를 수신할 수 있다. 한 구현에서, 동일 장소 소재는 HFT(606)가 "수십 마이크로초"만에 거래 보고 B(613b)를 수신하는 것을 허용한다. HFT(606)는, XYZ에 관해 거래소 1(605a)에서 거래가 발생했다는 지식으로부터 수익을 얻기 위한 시도로서, 예를 들어, 또 다른 매수 주문(D)이 거래소 2(605b)로 라우팅되는 중에 있다고 예상하고 주문 C를 $10.01의 가격으로 상향 조정함으로써, ($10.00에서 2000주의 XYZ를 매도하는 이전에 입력된 주문의) 주문 개정 C(613c)를 거래소 2(605b)에 전송할 수 있다. 이 예에서 $10.00에서 매수하는 제한을 갖는 주문 D(613d)는 집행되지 않을 수 있고, 브로커(615)는 $10.01에서 매수하기 위해 또 다른 주문을 전송해야만 할 수 있다. 순 결과는, 새로운 매수 주문이 거래소 2(605b) 상에서 집행된다면, 투자자는 XYZ의 나머지 2000주를 매수하기 위해 $20.00($.01*2000 = $20.00)을 더 지불할 수 있다는 것이다. 주문 C(613c)의 레이턴시는 접속성과 정보 수송 방법(예를 들어, 마이크로파 대 섬유)에 의해 결정될 수 있다.

한 구현에서, 레이턴시(A의 전송 시간 + B의 전송 시간 + C의 전송 시간) < D의 전송 시간이면, (투자자(614)를 대신하여) 브로커(615)는 거래소 2(605b)에서 $10.00로 XYZ의 2000주의 매수 주문을 집행하지 못할 수도 있다. 그 결과, 주문이 그 순간 미충족으로 되거나, 투자자(614)는 새로운 매수 주문을 통해 나머지 1000주를 매수하기 위해 더 높은 가격을 지불해야만 할 수 있다.

도 6d는 EBOM의 실시예 내에서 POP 액세스 포인트의 예방과 함께 ESOR을 통해 레이턴시 차익거래를 관리하는 예를 제공한다. 일 구현에서, 거래소 1(605a)은 $10.00에서 XYZ 주식의 1000주를 매도하는 오퍼를 가지고 있을 수 있고 거래소 2(605b)는 $10.00에서 XYZ의 2000주를 매도하는 오퍼를 갖고 있을 수 있다(거래소 2(605b) 상의 오퍼는 이전에 HFT(606)에 의해 입력되었다. 전국 최상 오퍼는 $10.00에서 매도하는 XYZ의 3000주의 결합된 오퍼이다).

한 구현에서, 투자자(614)는 $10.00에서 XYZ의 3000주를 매수하기를 원하고 $10.00에서 3000주의 XYZ를 매수하기 위해 브로커(615)에 주문을 전송한다. 한 구현에서, 브로커(615)는 거래소 1(605a)의 스마트 주문 라우터(Smart Order Router)(ESOR)를 이용하기를 원할 수 있고, 주문을 수신한 후에, $10.00에서 XYZ의 3000주를 매수하는 전체 주문 A(613a)를 거래소 1(605a)로 라우팅한다. 거래소 1(605a)은 이제, 브로커(615)를 대신하여 나머지 2000주에 대한 매수 주문 D(613d)를 라우팅할 책임을 진다.

한 구현에서, 브로커(615)의 주문 A(613a)는 거래소 1(605a)에 도달하고, 투자자(614)는 (브로커(615)를 통해) 거래소 1(605a)에서 $10.00로 1000주를 매수한다. 주문을 집행한 후에, 거래소 1(605a)은, 거래소 1(605a)의 ESOR을 이용하여 주문 D(613d)를 거래소 2(605b)에 라우팅한다. HFT(606)는 거래소 1(605a)로부터 거래 보고 B(613b)를 수신한다. 한 구현에서, 동일 장소 소재는 HFT(606)가 "수십 마이크로초"만에 거래 보고 B(613b)를 수신하는 것을 허용한다. HFT(606)는, XYZ에 관해 거래소 1(605a)에서 거래가 발생했다는 지식으로부터 수익을 얻기 위한 시도로서, 예를 들어, 또 다른 매수 주문(D)이 거래소 2(605b)로 라우팅되는 중에 있다고 예상하고 주문 C(613c)를 $10.01의 가격으로 상향 조정함으로써, ($10.00에서 2000주의 XYZ를 매도하는 이전에 입력된 주문의) 주문 개정 C(613c)를 거래소 2(605b)에 전송할 수 있다. 이 예에서 $10.00에서 매수하는 제한을 갖는 주문 D(613d)는 집행되지 않을 수 있고, 브로커(615)는 $10.01에서 매수하기 위해 또 다른 주문을 전송해야만 할 수 있다. 따라서, 투자자(614)는 XYZ를 매수하기 위해 결국 $20.00($.01 * 2000 = $20.00)을 더 지불하게 될 수 있다. 주문 C의 레이턴시는 접속성과 정보 수송 방법(예를 들어, 마이크로파 대 섬유)에 의해 결정될 수 있다.

그러나, EBOM POP 아키텍쳐 POP(610)는, (A의 전송 시간 + Ai의 전송 시간 + Aii의 전송 시간 + B의 전송 시간 + C의 전송 시간) > D의 전송 시간이므로, HFT(606)가 거래 보고 B(613b)를 수신하여 이것을 신호로서 이용할 수 있기 이전의 시간량에 (거리나 매체를 통한) 레이턴시를 추가함으로써, 레이턴시 차익거래로부터 고객의 주문을 보호할 기회를 ESOR에게 허용한다. 이 예에서, (투자자(614)를 대신하여) 브로커(615)는, HFT(606)의 주문 개정 C(613c)가 거래소 2(605b)에 도달하기 이전에, 거래소 2(605b) 상에서 $10.00로 XYZ의 2000주의 매수 주문 D(613d)를 집행할 충분한 시간을 가질 수 있다. 그 결과, 주문은 완전히 충족될 수 있고 투자자(614)는 도 6a의 경우에서와 같이 새로운 매수 주문을 통해 나머지 2000주를 매수하기 위해 더 높은 가격을 지불해야 할 필요가 없다.

도 6e 내지 도 6h는 주문장 차익거래를 관리하는 것에 관한 예를 제공한다. 구현 내에서, 시장 참가자는, 중개자가 대체가능 증권을 거래하는 거래소들(또는 다른 마켓 센터들) 사이의 레이턴시 차이로부터 수익을 얻는 것을 허용하는 전략인, 주문장 차익거래를 이용할 수 있다. 주문장 차익거래는 수동적으로(passively) 또는 적극적으로(aggressively) 수행될 수 있다. 예를 들어, 수동적 주문장 차익거래는, 중개자가 가장 최신의 시장 데이터를 갖고 있고, 이전에 제출된 주문을, 그 주문이 공격적 주문을 입력하는 오래된 시장 데이터를 갖는 더 느린 참가자에 의해 집행될 수도 있다고 예상하는 거래소(또는 다른 마켓 센터)에서 열등한 가격으로 수동적으로 레스팅(resting)하게 내버려 둘 때 발생할 수 있다. 반면, 적극적 주문장 차익거래는, 거래소(또는 다른 마켓 센터)가 그 자신의 주문장에 수동적으로 기초하여 주문을 재-가격책정하는 책임을 지고 있고, 다른 거래소(또는 다른 마켓 센터)에서의 시장 데이터 변경을 처리하는데 있어서 중개자보다 더 느릴 때 발생할 수 있다. 가장 최신의 시장 데이터를 갖는 중개자는, 거래소(또는 다른 마켓 센터)의 주문장 상의 주문에 불리하도록, 오래된 시장 데이터에 기초하여 느린 거래소에서 거래를 집행할 수 있다.

도 6e는 EBOM의 실시예 내에서 수동적 주문장 차익거래를 나타내는 예를 제공한다. 예를 들어, 한 구현에서, 브로커(615), HFT(606), 거래소 1(605a) 및 거래소 2(605b)는 XYZ의 NBBO를 $10.00 x $10.02로 알 수 있다. HFT(606)는 거래소 1(605a) 상에서 $10.00에서 XYZ의 1000주를 매수하는 주문 A(613a)를 입력한다. 주문 A(613a)의 집행에 이어, $10.01 x $10.02로의 거래소 2(605b)의 시장 업데이트와 시세 업데이트 B(613b), Bi, 및 Bii가 HFT(606), 거래소 1(605a) 및 브로커(615)에 각각 전송되고, 새로운 NBBO는 $10.01 x $10.02이 된다. 이들간의 거리 때문에 거래소 1(605a) 및 거래소 2(605b)는 이제 상이한 NBBO 계산, 즉, 각각의 거래 장부의 가격 불일치(price dislocation)를 알게 된다: 거래소 1(605a)($10.00 x $10.02) 및 거래소 2(605b)($10.01 x $10.02).

한 구현에서, HFT(606)는 시세 업데이트 B(613b)를 수신할 수 있으므로 거래소 2(605b) 상의 새로운 NBBO($10.01 x $10.02)를 알게 된다. HFT(606)는, $10.00에서 1000주를 매수하는 주문 A(613a)가 거래소 1(605a) 상에 남아 있다는 것도 알게 된다. 더 느린 시장 참가자(예를 들어, 브로커(615))는 가장 최신의 시장 정보 Bii를 아직 수신하지 않았기 때문에 그가 $10.00에서 거래소 1(605a)에서 XYZ를 매도하려고 할 수도 있다고 예상하여, HFT(606)는 그 매수 주문 A(613a)를 $10.00에서 변경시키지 않고 내버려 둔다.

한 구현에서, 브로커(615)가, 시세 변경 B, Bi, Bii에 이어 브로커(615)가 Bii를 수신하기 전에, 및 거래소 1(605a)가 Bi를 수신하기 전에, 이전의 NBBO($10.00 x $10.02)에 기초하여 $10.00에서 XYZ의 1000주를 매도하는 매도 주문 C(613c)를 거래소 1(605a)에 입력한다면, 주문 C(613c)는 열등한 가격의 집행($10.00 대 $10.01)을 수신하는 것이 가능하다. 거래소 1(605a)이 그 주문장 상의 주문이 (예를 들어, 규정 NMS을 준수하는 미국에서의) 다른 시장에서 고시된 주문보다 열등한 가격에서 거래되는 것을 방지하는 의무를 갖는 예에서, 거래소 1(605a)은 시세 업데이트 B(613b)를 수신할 수 있고, 더 나은 가격의 호가($10.01)가 있다는 것을 알게 되며, 그에 따라 매도 주문 C(613c)가 $10.00에서 거래되는 것을 허용하지 않을 수 있다($10.00에서의 집행은 규정 NMS 하에서 "트레이드 쓰루(trade through)"라고 간주될 것이다).

그러나, 거래소 1(605a)이 시세 업데이트 B(613b)를 수신하기 이전에 매도 주문 C(613c)를 수신하는 시나리오에서, 거래소 1(605a)은 (시세 변경을 모르기 때문에) 매도 주문 C(613c)가 현재의 최상의 호가인 $10.01보다 열등한 가격인 $10.00에서 집행되는 것을 허용할 수 있다. 이 경우에 투자자(614)는 XYZ의 판매에 대해 $10.00(1,000 * .01 = $10.00)을 덜 받는다.

따라서, HFT(606)가 시세 업데이트 B(613b)를 수신하고 주문 A(613a)를 변경하지 않고 내버려 둔 이후의 기간 동안에, HFT(606)는 잠재적으로 $10.00에서 XYZ를 매수하여 거래소 2(605b)에서 $10.01에 즉시 매도하여 투자자(614)를 희생하면서 수익을 취할 수 있다.

도 6f는 EBOM의 실시예 내에서 POP 액세스 포인트에 의해 무력화되는 수동적 주문장 차익거래의 관리를 나타내는 예를 제공한다. 예를 들어, 한 구현에서, 브로커(615), HFT(606), 거래소 1(605a) 및 거래소 2(605b)는 XYZ의 NBBO를 $10.00 x $10.02라고 알 수 있다. HFT(606)는 거래소 1(605a) 상에서 $10.00에서 XYZ의 1000주를 매수하는 주문 A(613a)를 입력한다. 거래소 2(605b) 상의 $10.01 x $10.02로의 거래소 2(605b) 상의 시장 업데이트와 시세 업데이트 B(613b), Bi, 및 Bii가 HFT(606), 거래소 1(605a) 및 브로커(615)에 각각 전송되고, 새로운 NBBO는 $10.01 x $10.02이 된다. 이들간의 거리 때문에 거래소 1(605a) 및 거래소 2(605b)는 이제 상이한 NBBO 계산을 알게 된다: 거래소 1(605a)($10.00 x $10.02) 및 거래소 2(605b)($10.01 x $10.02).

한 구현에서, HFT(606)는 시세 업데이트 B(613b)를 수신할 수 있으므로 새로운 NBBO($10.01 x $10.02)를 알게 된다. HFT(606)는, $10.00에서 1000주를 매수하는 주문 A(613a)가 거래소 1(605a) 상에 남아 있다는 것도 알게 된다. 더 느린 시장 참가자(예를 들어, 브로커(615))는 가장 최신의 시장 정보 Bii를 아직 수신하지 않았기 때문에 그 더 느린 시장 참가자가 $10.00에서 거래소 1(605a)에서 XYZ를 매도하려고 할 수도 있다고 예상하여, HFT(606)는 거래소 1(605a)에서 그 매수 주문 A(613a)를 $10.00에서 변경시키지 않고 내버려 둔다.

한 구현에서, 브로커(615)는 투자자(615)를 대신하여 $10.00에서 1000주를 매도하기 위해 매도 주문 C(613c)를 거래소 1(605a)에 입력할 수 있다. 거래소 1(605a)이 그 주문장 상의 주문이 (예를 들어, 규정 NMS을 준수하는 미국에서의) 다른 시장에서 고시된 주문보다 열등한 가격에서 거래되는 것을 방지하는 의무를 갖는 예에서, 거래소 1(605a)은 시세 업데이트 Bi(618a)를 수신하여, 더 나은 가격의 호가($10.01)가 있다는 것을 알게 되며, 그에 따라 매도 주문 C(613c)가 $10.00에서 거래되는 것을 허용하지 않을 수 있다.

한 구현에서, EBOM POP 아키텍쳐 POP(610)은, 브로커(615)의 주문 D(613d)가 거래소 1(605a)에 도달하기이전에, 거래소 1(605a)이 시세 변경 Bi(618a)를 수신할 수 있다는 것을 보장할 수 있다. 따라서, 거래소 1(605a)은 가장 최신의 시장이 $10.01 x $10.02임을 알 수 있고 매도 주문 C(613c)가 $10.00에서 거래되는 것을 허용하지 않을 수도 있다.

따라서, HFT(606)가 시세 업데이트 B(613b)를 수신하고 그 주문 A(613a)를 변경하지 않고 내버려 두면, EBOM POP 아키텍쳐 POP(610)은 잠재적으로 투자자(614)가 오래된 시세 정보에서 거래하여 HFT(606)가 투자자(614)를 희생하면서 수익을 취하는 것을 방지할 수 있다.

도 6g는 EBOM의 실시예 내에서 적극적 주문장 차익거래를 나타내는 예를 제공한다. 도 6g에 도시된 바와 같이, 이 예는 오래된 시세 차익거래 대 중간점 고정된 주문을 다루고 있지만, 동일한 메커니즘 및 그에 따라 동일한 차익거래 기회가 NBB(National Best Bid) 또는 NBO(National Best Offer)에서의 오래된 가격고시에 적용될 수 있다.

한 구현에서, 브로커(615), HFT(606), 거래소 1(605a) 및 거래소 2(605b)는 XYZ의 NBBO가 $10.01 x $10.03인 것으로 알 수 있다. 브로커(615)는, NBBO 중간점($10.02)에 고정된 XYZ의 1000주를 매수하기 위해 투자자(614)를 대신하여 거래소 1(605a)에 주문 A(613a)를 입력한다. $10.00 x $10.02로의 거래소 2(605b) 상의 시장 업데이트와 시세 업데이트 B(613b), Bi(618a), 및 Bii(618b)가 HFT(606), 거래소 1(605a) 및 브로커(615)에 각각 전송된다. 새로운 NBBO는 $10.00 x $10.02이 되고, 새로운 중간점은 $10.01이 된다. 이들간의 거리 때문에 거래소 1(605a) 및 거래소 2(605b)는 이제 상이한 NBBO와 중간점 계산을 알게 된다: 거래소 1(605a)(중간점이 $10.02인 $10.01 x $10.03) 및 거래소 2(605b)(중간점이 $10.01인 $10.00 x $10.02).

한 구현에서, HFT(606)는 시세 업데이트 B(613b)를 수신할 수 있으므로 새로운 NBBO 및 중간점($10.00 x $10.02 및 $10.01)를 알게 된다. HFT(606)는 또한, 거래소 1(605a) 상의 중간점 주문은 여전히 이전의 NBBO($10.01 x $10.03 및 $10.02)에 기초하여 가격책정될 수 있다는 것을 알고 있다. HFT(606)는 $10.02의 구 중간점(old midpoint)에서 매도 주문 C(613c)를 거래소 1(605a)에 전송하고, 열등한 중간점 가격에서 브로커(615)의 주문 A(613a)를 거래함으로써 투자자(614)의 $10.00(1,000 * $.01 = $10.00)을 희생시킨다.

따라서 (B의 전송 시간 + C의 전송 시간) < Bi의 전송 시간이면, HFT(606)는 거래소 1(605a) 상에서 $10.02에서 XYZ를 즉시 매도하고 잠재적으로 거래소 2(605b)에서 $10.01의 중간점에서 XYZ를 즉시 매수할 수 있어서 투자자(614)를 희생시켜 수익을 취할 수 있다.

도 6h는 EBOM의 실시예 내에서 POP 액세스 포인트의 예방에 의한 적극적 주문장 차익거래의 관리를 나타내는 예를 제공한다. 도 6g로부터의 잠재적 오래된 시세 차익거래를 계속하면, POP(610)이 예방될(inoculated) 때, (B의 전송 시간 + C의 전송 시간 + Ci의 전송 시간) > Bi의 전송 시간일 경우 HFT(606)의 주문 C(613c)는 EBOM POP 아키텍쳐 POP(610)를 반드시 통과해야 하기 때문에, 거래소 1(605a)은 시세 변경 Bi를 제시간에 수신하여 그 중간점 계산을 가장 최신의 정보($10.00 x $10.02 및 $10.01)로 업데이트했을 수 있고, 브로커(615)의 주문 A(613a)는 열등한 중간점 가격에서 집행되지 않을 수 있다.

TLL의 추가 실시예들은 다음 사항을 포함할 수 있다:

실시예 내에서, TLL은 매수자 및 매도자로부터의 증권을 매도 및 매수하는 주문을 정합 및 집행하기 위한 시장일 수 있고, TLL 상에서 정합이 이용가능하지 않을 때 집행을 위해 이러한 주문을 다른 시장에 라우팅할 수 있다. TLL은 미국에서 발행된 현금 지분 증권(cash equity securities)의 매수자 및 매도자를 서빙하는 데 중점을 둘 수 있다; 그러나, 시스템 조직의 원리는, 미국 및 다른 국가, 지리적 및/또는 규제 지역 내의 다른 증권, 금융 상품, 유가물, 및/또는 이와 유사한 것의 매수 및 매도에도 적용가능할 것이다.

TLL은, 내부 메시지 버스를 통해 서로 통신할 수 있고 기타의 거래소, 벤더, 증권 브로커 등과 외부적으로 통신할 수 있는, 클라이언트 FIX 게이트웨이, 정합 엔진, 라우팅 엔진, 거래소/장소 FIX 게이트웨이, 시장 데이터 티커 플랜트, 주문 및 거래 데이터베이스(들) 클리어링, 빌링, 감시 시스템 및 인터페이스, 및/또는 이와 유사한 것(이것으로 제한되지 않음)을 포함하는 컴퓨터 하드웨어 상에서 실행되는 수 개의 컴포넌트들을 포함할 수 있다. 이하에서, 신규하고 유용한 컴포넌트 및 시스템의 요소들이 전체적으로 설명될 것이다.

TLL은, 기존의 거래 장소에서 거래하는데 있어서 "고빈도 거래"(HFT; high-frequency trading)라 알려진 방법들 내의 소정의 거래 전략들의 이점들과 직면할 수 있다.

신뢰성

TLL은 클라이언트/서버 모델을 배치할 수 있고, 여기서, "클라이언트"는 다른 프로그램(들)에 의해 제공된 서비스를 이용하는 프로그램일 수 있고, 그 서비스를 제공하는 프로그램들은 "서버들"이라 부를 수 있다. 서버는 데이터, 상태 정보, 및/또는 이와 유사한 것으로 클라이언트 요청에 응답함으로써 기능할 수 있다. 일부 실시예에서, 클라이언트는, 더 많은 처리 또는 저장, 및/또는 이후에 클라이언트에 응답할 수 있는 서버에 응답하기 위해 다른 백-엔드 서비스와 상호작용하기 이전에 비지니스 프로세스 로직을 수행하는 서버에 접속할 수 있다.

T2M(TCP-to-Multicast)은 메시지가 단일의 프론트-엔드 서버로부터 복수의 백-엔드 서버로 배포되는 방식일 수 있다. 일부 실시예에서, 이것은, 자원 이용을 최적화하고, 처리량을 최대화하며, 결함 허용치를 증가시키고, 기타의 보안 및 품질 보장(QA; quality assurance) 혜택 등을 달성할 수 있다.

T2M은, 외부 클라이언트가 백-엔드 상의 서비스에 액세스하기 위해 접속하는 포트에 접속할 수 있는 컴포넌트일 수 있다. 프로그램은 TCP 프로토콜에 따라 클라이언트로부터의 접속을 유지하고 데이터 페이로드를 멀티캐스트(UDP 프로토콜) 전달을 통해 백-엔드 서비스에 전송할 수 있다. TCP 프로토콜이 일대일 통신을 제공할 수 있는 반면, 멀티캐스트는 일대다 통신을 제공하여 복수의 백-엔드 서비스가 처리 및/또는 추가 백-엔드/다운스트림 서비스로의 전송 이전에, 하나의 소스로부터 원래의 데이터 페이로드를, 동시에 수신하는 것을 허용한다.

T2M을 통한 일대다 통신은, 클라이언트가, N개의 백-엔드 자원으로 통신을 팬 아웃(fan out)할 수 있는 단일 TCP 접속을 형성하는 것을 허용할 수 있다. 이러한 일 대 다 통신은 클라이언트에게 보이지 않지만 많은 이점을 달성할 수 있다. 구체적으로는, 이것은 다음 중 적어도 하나를 허용할 수 있다: 아키텍쳐 로직으로부터의 비지니스 로직의 추출로 인한 최소화된 배치 위험, 복수의 서버와의 클라이언트 통신 세션의 중복; 프론트-엔드 서비스와는 독립된 백-엔드 서비스의 스케일링; 클라이언트는 내부 네트워크 구조와 커널 네트워크 스택을 은닉하는 백-엔드 서비스로의 직접적인 접속을 형성하지 않아, 더 높은 시스템 보안을 이룬다는 점; 장중 용량 스케일링(intraday capacity scaling), 및 클라이언트 포트 접속을 훼손하지 않는 부하 밸런싱; 결함 허용치, 복원성 및 재난 복구 능력을 증가시키는 데이터 센터 내의 또는 데이터 센터들에 걸친 클라이언트 통신층의 실시간 원활한 장애복구; 원래의 프로덕션 데이터 페이로드를 이용한 실시간 QA 분석을 위한 독립적인 병렬 스트림, 및/또는 이와 유사한 것.

물리적 하드웨어 및 네트워크

지리적으로 별개의 시스템에 대한 동시 정보 전달의 보장

별개의 지리적 위치로부터 중앙점으로 데이터를 전송하는 것은 전송 시간 및 거리에 따라 상이한 시간 길이를 요구할 수 있다. 그 결과, 2개의 지리적 위치에서 중앙점으로 동시에 제출된 데이터는 상이한 시간에 도달한다. 일부 실시예에서, 이러한 보정은 소프트웨어를 이용하여 행해질 수 있지만, 이러한 시스템은 복잡할 수 있고, 오류가 발생하기 쉬우며, 부정확할 수 있다.

다양한 채널을 통한 데이터의 전송은 다양한 제약에 의해 제한될 수 있다. 예를 들어, 한 실시예에서, 이것은 광섬유 채널에 의해 이루어질 수 있고, 여기서, 전송 속도는 채널의 매체를 통한 빛의 속도에 의해 제한될 수 있다. 이러한 실시예에서, 이동 시간은 이동해야 하는 거리를 매체를 통한 빛의 속도로 나눔으로써 계산된다. 따라서, 이동 시간은, 매체에 추가 길이를 더하거나 매체를 변경함으로써 동등하게 될 수 있다. 더 짧은 채널에 길이를 추가함으로써 전송 매체의 길이를 동등하게 하는 것은 정보의 동시 전달을 허용할 수 있다. 일부 실시예에서, 이것은 나노초 내의 동시 전달을 보장할 수 있다.

지리적으로 별개의 거래 시스템으로의 동시 정보 전달의 보장

많은 거래 시스템은 광학 기술을 이용하여 지리적으로 별개의 위치에 물리적으로 놓인 거래 시스템에 정보를 전송한다. 적어도 부분적으로 현재의 통신 방법 및 법규와 결합된 연계된 거래 시스템들의 지리적 구분성(geographic distinctiveness) 때문에, 모든 타겟 거래 시스템으로부터 완벽하게 동등한 거리의 지점은 존재하지 않는다. 그 결과, 많은 거래 시스템들은 시간 평면(temporal plane) 상에서 정보 전달을 목표로 할 수 있고, 그 결과, 이들은 복잡하고 오류가 발생하기 쉬우며 부정확한 소프트웨어-구동형 방법을 이용하여 이 작업을 완수할 수 밖에 없다.

언급된 바와 같이, 기저 정보는 사실상 복수의 광섬유 채널을 따라 광자적 전송을 통해 각각의 위치로 전송될 수 있고, 수신은 동일한 경로를 따르는 별개의 광섬유 채널을 따라 접수확인될 수 있으며, 이들 양쪽 모두는 광섬유 채널에서 이용되는 매체를 통한 빛의 속도 제한에 종속될 수 있다. 일부 실시예에서, 광섬유 채널을 통해 횡단한 거리(d)를 채널의 매체(들)를 통한 빛의 속도로 나눈 값은 그 소스로부터 그 목적지까지의 정보에 대해 필요한 이동 시간(t)을 결정한다. 모든 타겟 거래 시스템까지의/으로부터의 완벽하게 동등한 거리의 지점이 없다면, 상이한 길이의(그러나 동일한 매체의) 광섬유 채널을 통해 횡단한 거리는 상이할 것이고, 그에 따라, 소스 시스템으로부터 이동하는 정보는 상이한 시간에 목적지 시스템에 도달할 것이다.

정보의 전달 시간(d / s = t)이 모든 채널에 걸쳐 동등하게 되도록 각각의 전송측 광섬유 채널까지 케이블링되는 광섬유의 추가 길이를 더하거나, 채널의 매체를 변경하거나 및/또는 이와 유사한 것에 의해, 정보가 횡단해야 하는 거리를 동등하게 함으로써 정보의 동시 전달은 가능하게 될 수 있다. 한 실시예에서, 통신 제공자에 의해 제공되는 채널 세트의 거리를 측정하고 더 짧은 채널에 케이블 길이를 더하여 그 길이를 동등하게 함으로써, 일부 소프트웨어-구동형 방법에서의 밀리초와는 달리, 정보의 전달이 실질적으로 동시적, 예를 들어, 나노초 이내가 될 수 있다.

네트워킹된 애플리케이션에서 정체 통보 및 회피를 위한 애플리케이션 버퍼 사용 보고

버퍼부풀림(bufferbloat)은 과도하게 큰 버퍼의 이용에 의한 네트워킹된 애플리케이션 내로의 비-결정론적 레이턴시의 도입으로서 볼 수 있다. 일부 실시예에서, 이것은, 레이턴시 타겟을 설정하고 특정한 레이턴시 측정치에 대해 이들 타겟을 유지하도록 동작함으로써 달성될 수 있다. 이들 기술들은 TCP 소켓을 이용하는 시스템에서만 이용될 수 있고, 2가지 중요한 제한을 가진다: 1) 이들은 큰 팬아웃 애플리케이션을 효과적으로 취급할 수 없다, 및 2) 이들은 또한 애플리케이션에게 불투명하다.

이들 2가지 제약 ― 불투명성 및 비효율적인 팬아웃 ― 은 CoDel 알고리즘을 갖는 TCP를 대규모 분산형 시스템 내의 버퍼부풀림 문제를 취급하기에 불충분하게 한다. 이러한 분산형 시스템은 통상적으로, 오퍼레이터가 사유 애플리케이션에 관해 완벽한 제어권을 갖는 사설 네트워크 상에서 호스팅되므로, 특정한 데이터 경로 내의 업스트림 및 다운스트림 애플리케이션 양쪽 모두에 대한 각 애플리케이션의 버퍼 이용률에 관한 정보를 직접 발표하는 것이 더욱 효과적일 수 있다.

예를 들어 0-255의 간단한 숫자로서의 버퍼 이용률을 발표함으로써, 각각의 애플리케이션은 그 바로 이웃의 부하를 알게 될 수 있고, 추가의 데이터 전송에 관해 지능적으로 결정할 수 있다. 예를 들어, 버퍼 이용률이 미리정의된 임계치에 도달할 때, 애플리케이션은 와이어를 통한 추가 데이터의 전송을 중단할 수 있다. 이러한 "잠시멈춤"은 잠시멈춤된 애플리케이션의 버퍼 이용의 증가를 야기할 수 있고, 이것은 차례로 업스트림 애플리케이션에 발표될 수 있는 등등이다. 버퍼 이용률의 명시적 통보를 애플리케이션에 제공함으로써, 이들 애플리케이션들은 전송을 중단하여, 다운스트림 애플리케이션의 버퍼가 가득차서 새로운 데이터를 수신할 수 없게 된 이후에 애플리케이션이 그 다운스트림 애플리케이션에게 계속 데이터를 전송할 때 발생할 수도 있는 패킷 손실을 방지할 수 있다. 이것은 또한, 애플리케이션이 분실된 패킷을 회복하려도 시도할 때 생길 수 있는 과도한 재전송 지연을 피할 수 있다. 나아가, 명시적인 버퍼 이용률 통보는 또한, 분산형 시스템의 엔드-투-엔드 레이턴시 경험(end-to-end latency experience)이 단일 애플리케이션의 버퍼를 비우는데 필요한 지연의 약 50% 정도로 등락할 것임을 보장할 수 있다.

능동/수동 장애복구 시스템의 능동 멤버의 효과적인 중단을 보장하기 위한 자동화된 방법

TLL은, 수동 시스템 멤버를 새로운 능동 시스템 멤버가 되도록 촉진하기 위해 한 세트의 동작이 요구될 수 있는 피쳐를 포함하는 능동/수동 시스템일 수 있다. 능동/수동 시스템의 한 실시예에서, 다른 멤버가 능동이 될 때까지 수동적으로 대기하고 있는 동안 임의의 주어진 시간에 단 하나의 멤버만이 능동이 되고 데이터를 처리할 수 있다. 능동/수동 시스템의 성질로 인해, TLL은 장애복구 동안에 "능동" 시스템에 의한 활동을 성공적으로 종료할 수 있다. 구어체로 "shoot the other node in the head" 또는 STONITH라고 알려진, 이러한 종료는, 장애복구 이후에 단 하나의 멤버만이 능동으로 남아 있도록 보장할 수 있다. 이것은, 능동/수동 시스템의 성질로 인한 메시지의 부정확한 복제 등의 문제를 야기할 수 있는, 이전의 마스타(master)가 시스템 제어의 리-어써팅(re-assert)을 시도하지 않거나 제2 마스타로서 계속 동작하는 것을 보장하는 것을 도울 수 있다.

STONITH는 자동으로 달성될 수 있고, 이 경우, 보조 노드는 1차 시스템과 셧다운을 협상한다; 또는 수동으로 달성될 수 있고, 이 경우, 관리자는 현재의 능동 (마스타) 노드에 로그인하여 능동 노드의 동작을 종료하는 명령을 실행한다. 그러나, 이 방법이 실패할 수 있는 몇 가지 상황이 존재한다.

능동 노드를 적절히 종료하기 위하여, TLL은 문제의 노드가 실행되고 있는 하드웨어(예를 들어, 서버)로의 접속을 그 접속의 먼 쪽에서 원격적으로 종료할 수 있다. 엄격한 케이블링 표준과 결합되면, 능동/수동 시스템의 능동 멤버의 위치는, 능동 멤버의 상태에 관계없이, 수동 멤버들에 의해 알고리즘적으로 결정될 수 있다. 수동 멤버가 능동 노드의 고장을 검출하면, 수동 노드는 능동 노드가 접속되어 있는 네트워크 디바이스들과 직접 통신할 수 있고 능동 노드가 접속되어 있는 임의의 네트워크 포트를 디스에이블할 수 있다. 능동 노드는 또한, 원한다면, 네트워킹된 전력 분배 유닛과 직접 통신할 수도 있고, 마찬가지로, 이전 능동 노드로부터 전력을 제거할 수도 있다. 이들 2가지 동작은 이전 능동 노드가 시스템의 능동 멤버로서 자신을 리어써팅(re-assert)하려고 시도하지 못하게 할 수 있다.

계산 효율성/테스팅/메시징

클라이언트 게이트웨이에서의 ID 맵핑 및 관리(러기지 + IexID)

외부 FIX 클라이언트와의 많은 거래 시스템 인터페이스는 거래 시스템에 전송된 주문 식별자(FIX 필드 ClOrdId)를 취급하는데 어려움을 가질 수 있다. 이들 식별자들은 종종 외부 시스템에 대해서만 고유하고(예를 들어, 시스템 1 및 시스템 2 양쪽 모두는 id=ABCD를 갖는 주문을 거래 시스템에 전송할 수도 있다) 많은 외부 시스템들 사이에서는 길이와 콘텐츠에 있어서 상당히 달라질 수 있다. 일부 실시예에서, 이들 주문들을 고유하게 식별하기 위해, 한 해결책은, 고객에 대한 식별자(FIX 필드 SenderCompID) + 제공된 주문 id를 결합함으로써(예를 들어, 시스템 1의 주문 A = '고객1-ABCD') 외부 시스템의 주문을 내부적으로 어드레싱하는 것일 수 있다. 이것은 유효한 접근법이긴 하지만, 많은 시스템이 시스템에서 외부 시스템 주문을 고유하게 식별하기 위해 큰 스트링을 이용해야만 하고, 데이터베이스, 파일 시스템, 또는 캐쉬된 메모리 중 어느 하나에 저장되는 교차-참조 파일(cross-reference file)을 생성하기 때문에, 잠재적인 성능 문제를 제기한다. 이것은 그 ID로의 액세스를 필요로 하는 프로세스에 대한 상당한 오버헤드를 생성하고 고장난 프로세스로부터 복구되기 위해 필요하다면 기술적인 해결과제를 생성할 수도 있다.

대안적 실시예에서, TLL은 외부 시스템의 주문 식별자(ClOrdId)를 내부 시스템 포맷에 기초하여 고유하게 생성된 식별자(IexID)로 대체할 수도 있고 교차-참조된 정보를 멀티캐스트 메시지 스트림에 노출시킬 수도 있다. 외부 시스템 원래의 ClOrdID는 유지될 수 있으므로, 외부 시스템 id와 IexID 사이의 맵핑은, 일부 실시예에서, "러기지(luggage)"라 불리는 상이한 메시지를 이용하여, TLL 내에 보관될 수 있다. TLL은 비-결정적인 "러기지" 데이터를 메인 데이터 경로 외부로 전송할 수 있다. 클라이언트 FIX 게이트웨이 그 자체 또는 다른 보고 시스템 등의 소정의 목적지 엔드포인트는 또한, "러기지" 메시지를 수집하여 필요하다면 IexID를 다시 ClOrdId로 디코딩(언맵핑(unmap))할 수 있지만, 대개는, 시스템은 원래의 외부 시스템 주문 식별자를 알 수 없을 것이다. 일부 실시예에서, 이것은 시스템 내의 더욱 효율적인 데이터 처리를 허용할 수 있다. 고유하게 생성된 IexID는, 전체에 걸쳐서 일관된 처리를 허용할 수 있고, 필요하다면, IexID를 메시지 스트림과 인터페이싱하는 모든 시스템에 노출시킬 수 있는, 멀티캐스트 메시지 스트림 상의 모든 청취자들에 의해 알려진 공지된 효율적인 포맷으로 이루어질 수 있다.

도 7은 예시적인 실시예의 샘플 데이터 흐름을 도시하며, 여기서, 고객 1(702)은 주문 정보(705)를 입력하여, 주문 식별자 고객1-ABCD를 갖는 주문 ABCD를 전송한다(710). 클라이언트 FIX 게이트웨이는 주문을 수신하고, ID를 맵핑하여(715), 그 정보를 정합을 위해 시스템에 전송할 수 있다. TLL은 내부 주문 식별자(1001) 등의 고유 ID를 생성할 수 있다(715). TLL은 TLL 내에 "러기지" 메시지를 전송할 수 있고(720), 이것은 임의의 관심있는 컴포넌트를 위해 보관될 수 있다(Luggage [Customer=1, CIOrdId=ABCD, IexID=1001]). TLL은 IexID=1001인 주문 메시지를 전송할 수 있다. 그 다음, 주문은 충족(fill)되거나 정합될 수 있다(725). 이것은 ID=1001과 함께 정합 엔진 클라이언트 게이트웨이에 의해 전송될 수 있다. 클라이언트 게이트웨이는 고객 1을 위해 IexID=1001를 ABCD로 되돌릴 수 있고(730), 원래의 식별자와 함께 충족 표시자(fill indicator)를 고객에게 전송할 수 있다(735). 거래 보고 애플리케이션은 또한, 충족을 변환하고 "러기지"에 기초하여 ID를 적절한 포스트 거래 시스템으로 언맵핑할 수 있다.

메시지의 고유 식별자로서 시퀀스 번호를 이용하기

멀티-프로세스, 멀티-머신 시스템에서, 고유 ID를 생성하는 것은 해결과제가 될 수 있다. 카운터를 이용하는 단순한 접근법은, 복수의 장소에서 동일한 ID가 생성되게 할 수 있고, 프로세스가 재시작되는 경우에 중복된 ID가 생성되지 않도록 일부 종류의 상태가 반드시 저장되어야 하기 때문에, 이용할 수 없다. 한 실시예에서, 이것은 ID에 수식어(qualifier)를 추가함으로써 해결될 수 있고, 이로부터 ID들이 생성된다. 예를 들어, machine01.process.02.session01.[counter]. 이것은 비교적 간단하며 중앙집중식 고장점이 없지만, 식별자는 필요한 것보다 클 수 있고, 재시작시 세션의 추적이 어려울 수 있으며, 머신과 프로세스가 고유하게 명명될 필요가 있을 수 있다. 또 다른 실시예에서, 중앙 ID 생성이 이용될 수 있고, 여기서, 식별자는, 서비스, 데이터베이스, 및/또는 이와 유사한 것과 같은 사유 프로세스로부터 나올 수 있다. 이것은 간단하고 중앙집중식 제어를 허용하지만, ID를 회수하는 오버헤드와 중앙 고장점 및 경쟁이 잠재적인 문제이다.

역시 또 다른 실시예에서, 시스템의 사유 멀티캐스트 미들웨어에 의해 제공된 메시지 시퀀스 번호가 고유 식별자로서 이용될 수 있다. TLL에 의해 수신된 모든 메시지들은, 그것들에 대해 보장된 일일-고유성의, 단조 증가하는 번호(guaranteed day-unique, monotonically increasing number)를 가질 수 있다. 중앙집중형 ID 시스템(데이터베이스, 파일 또는 메모리)에 대한 어떠한 추가 콜(call)도 필요하지 않을 수 있다. 추가적으로, ID는 시간적 상태에서 현재의 시스템 상태에 대한 참조를 제공할 수 있다. 이 기술은 TLL이 여러 곳에서 이용되지만, 가장 특별하게는, 고유 고객 주문 체인 ID를 생성할 때 이용된다.

예를 들어, 구성 1 내지 10이 TLL을 통해 전송될 수 있고, 여기서 시퀀스 번호 = 10이고, 시장 데이터 시세 1 내지 3이 TLL을 통해 전송될 수 있고, 여기서 시퀀스 번호 = 13이다. 고객 주문 1이 도달할 수 있고, 시퀀스 번호 = 14이다. TLL은 시스템 고유 ID를 요구할 수 있는 주문 체인을 생성할 수 있다. TLL이 새로운 ID를 생성하거나 중앙 서비스에게 새로운 ID를 요청할 수 있지만, TLL은 TLL이 주문 체인을 생성하게 한 고객 주문 메시지의 시퀀스 번호를 이용한다. 주문 체인 ID = 시퀀스 번호 = 14. 이렇게 함으로써, ID는 고유하고 컴팩트하며, 추가의 계산을 요구하지 않을 수 있다. 이 시퀀스 번호는 또한 시스템 상태의 한 시점을 나타낼 수 있어서, TLL은 주문이 내려진 시점에서의 가장 최근의 시장 데이터를 결정할 수 있다.

시퀀싱된 시장 데이터

임의의 거래 시스템에서의 주식 시장 데이터의 속도와 양은 해결과제가 될 수 있는데, 이것은 매일 수억개의 데이터 업데이트가 있고, 데이터는 즉시 소비될 때 가장 가치가 있기 때문이다 ― 오래된 데이터는 가치가 떨어질 수 있다. 거래 시스템은, 거래 엔진 1은 "A"로 시작하는 심볼만을 주시하거나, 이들은 독립적으로 시장 데이터를 소비하는 애플리케이션을 가질 수 있다고 표시하는 등, 처리를 많은 프로세스와 기능간에 분할하도록 설계될 수 있다. 시장 데이터를 분할하는 것은 결정론적 문제를 도입할 수 있는데, 그 이유는, 시장 데이터 상태에 관심있는 프로세스들은 그들이 데이터를 독립적으로 주시하고 있고 시스템 상태는 프로세스들간에 불일치될 수 있어서 서로 상이한 상태를 가질 수도 있기 때문이다. 예를 들어:

시장 데이터(MSFT) -> 프로세스 1 -> 주문 #2를 처리하는 프로세스 1은 MSFT를 $10.01이라고 안다;

시장 데이터(MSFT) -> 프로세스 2 -> 주문 #2를 처리하는 프로세스 2는 MSFT를 $10.02라고 안다.

TLL은, 대신에, 미들웨어를 통해 모든 시장 데이터를 전송하여 시퀀스화/직렬화시키므로, 시장의 상태는 임의의 주어진 시간에 전체 시스템에 걸쳐 각 애플리케이션에서 동일할 것이다. 예를 들어:

시장 데이터(MSFT) -> 시퀀서 ->

프로세스 1 -> 주문 #2를 처리하는 프로세스 1은 MSFT를 $10.01이라고 안다.

프로세스 2 -> 주문 #2를 처리하는 프로세스 2는 MSFT를 $10.01이라고 안다.

TLL 도처에서 알려진 시장 데이터의 동일한 상태는 여러가지 이점을 가진다. 예를 들어, 거래와 같은 소정의 트랜잭션에서, TLL은 거래시에 시장 데이터 상태 업데이트의 메시지 식별자(시퀀스 번호)를 기재함으로써 거래 메시지 상의 시장 데이터 상태에 라벨을 붙일 수 있다. (예를 들어, 거래 15가 발생했고, 시세 52는 현재의 시장 상태를 나타낸다). 이것은 특정한 시점에서의 시장 상태를 식별하기 위한 편리하고 효율적인 방식일 수 있다. 시장 데이터를 시퀀싱하지 않을시에, 다른 해결책은, 각 소비자측에서 현재 시장 상태를 기재하는 것(비효율적) 또는 시장 상태를 시간-기반으로 유도하는 것(비정밀 및/또는 부정확)을 포함할 수 있다.

트리거 프레임워크

TLL 트리거 프레임워크는 엄격하게 제어된, 고도로 투명하고 균일한 방식으로 복잡한 비지니스 로직을 배치할 수 있게 할 수 있다. 한 실시예에서, 목표는, 개발자가 특정한 태스크에 중점을 두는 것을 허용하고 많은 애플리케이션들에 의해 재사용될 수 있는 모듈화된 로직을 구축하는 것이다. 트리거 프레임워크는 2가지 타입의 컴포넌트: 조건 및 동작을 포함할 수 있다.

이들 두 컴포넌트는 조건이 몸체를 형성하고 동작이 분기인 2진 결정 트리로서 배열될 수 있다.

조건은 애플리케이션 내의 객체의 현재 상태를 평가하여 그 특정한 조건이 만족되었는지를 표현하기 위해 참이나 거짓을 반환하는 개체 클래스(individual class)일 수 있다. 객체는 FIX Protocol NewOrderSingle 요청과 같은 트랜션트 메시지이거나 ParentOrder 객체와 같은 상태-기반의 데이터 구조일 수 있다.

동작은 조건이 만족되는 것에 응답하여 비지니스 로직을 실행하는 개체 클래스일 수 있다. 일반적으로, 동작 클래스는 그 상태에서의 특정한 변화에 응답하여 메시지를 생성할 수 있다. 동작은 평가중이었던 객체를 수정할 수 있고 및/또는 다른 객체나 애플리케이션과 상호작용할 수 있다.

조건과 동작은 모듈화된 컴포넌트로서 기재될 수 있고, 구성 파일을 통해 결정 트리에서 함께 스티치(stitch)될 수 있다(예를 들어, JSON 포맷으로). 이러한 프레임워크는, 컴포넌트의 광범위한 재사용성, 디버깅, 유지보수, 및 로직의 시각적 이해를 통해 효율을 달성한다.

예시의 작업흐름에서, 메시지가 애플리케이션에 진입할 수 있다. 그 메시지는 트리거 큐에 추가될 수 있고, 및/또는 그 메시지는 다른 객체가 트리거 큐에 추가되게 할 수도 있다. 하나씩, 객체들은 트리거 큐로부터 인출되어 평가될 수 있다. 객체가 평가될 때, 객체가 상태-기반의 객체이면, 관련 조건 트리는 그 상태에 기초하여 인출될 수 있다; 그렇지 않다면, 객체의 타입에 대한 디폴트 트리가 로딩될 수 있다. 그 다음, 관련 트리 내의 조건이 최상부로부터 시작하여 평가될 수 있다. 예를 들어, 조건이 참인 것으로 평가되면, ifTrue 분기가 후속되고 그 반대의 경우에도 마찬가지다. 조건 트리는 동작에 도달하여 동작이 수행될 때까지 횡단될 수 있다. 동작을 수행하는 것은 트리거된 객체 또는 다른 객체에 상태 변경이 수행되게 할 수 있다; 이것은 다른 객체를 생성할 수도 있다; 이것은 다른 객체가 트리거 큐에 추가되게 할 수 있다; 이것은 하나 또는 수 개의 메시지가 발표되게 할 수 있다; 또는 상기의 임의의 조합을 가능케 할 수 있다. 일단 트리거 큐가 충분히 평가되고 나면, 애플리케이션은 다음 입력된 메시지를 처리할 수 있다.

조건은 많은 상이한 타입의 객체들에 관해 평가될 수 있다. 예를 들어, 객체의 관련 보안 심볼(object's relevant security symbol)이 중지되어 있는지를 검사하는 조건은, NewOrderSingle FIX 메시지, 시장 데이터 업데이트 메시지, 부모 주문(Parent Order) 객체, 라우터 객체 등에 대해 평가될 수 있다.

테스트 하네스(Test Harness)

테스트 하네스는 테스팅 담당자가 애플리케이션에 관한 자동화된 테스팅을 수행하는 것을 허용할 수 있다. 이것은 테스팅될 애플리케이션을 로딩하고 하네스를 애플리케이션의 입력과 출력 밸브에 접속할 수 있다. 예를 들어, JSON 포맷의 미리-기입된 주입(inject) 및 예상(expect) 메시지들의 목록이 로딩될 수 있다. 그러면, 주입 메시지는 애플리케이션 내에 입력될 수 있고, 이것은 출력 메시지를 야기할 수 있다. 메시지들이 애플리케이션에 의해 출력됨에 따라, 출력 메시지들은 미리-로딩된 목록의 예상 메시지들에 대하여 비교될 수 있다. 일부 실시예에서, 출력 메시지가 예상 메시지와 정합하지 않는 경우, 출력 메시지들이 비순차적(out of order)인 경우, 또는 예상된 출력 메시지가 테스트 하네스에 의해 출력되지 않은 경우, 테스트는 실패했을 수 있다. 그 외의 경우, 테스트는 통과했을 수 있다.

일부 실시예에서, 테스트 하네스는 메시지(Message) 템플릿을 구현할 수 있다. 사용자는 테스트들에 걸쳐 재사용될 수 있는 메시지 템플릿을 생성할 수 있다. 테스트를 생성할 때, 각각의 메시지는 사용할 템플릿을 간단히 참조하기 위해 테스트 생성자에 의해 지정될 수 있고, 테스트 하네스는 그 메시지를 파싱하여 호출된 템플릿의 필드 내의 모든 값들을 자동으로 로딩할 수 있다. 추가적으로, 임의의 필드 값들이 테스트에서 특정된다면, 이들 특정한 값들은 템플릿으로부터 복사된 값들에 우선할 수 있다. 이것은, 오직 주어진 테스트에 관련된 메시지 상의 관련 필드들은 반드시 특정/수정되어야 하기 때문에, 테스트의 생성과 수정을 간소화할 수 있다. 다른 모든 필드들은 템플릿 설계마다 디폴트화될 수 있어서, 시간과 노력을 절감할 수 있다.

일부 실시예에서, 테스트 하네스는 예상 메시지에 관한 선택적 필드 유효성확인(validation)을 허용할 수 있다. 테스트에서 유효성확인에 이용되는 예상 메시지들은 완전-형성된 메시지(full-formed messages)일 필요는 없을 것이다; 이들은 임의 개수의 필드를 포함할 수 있다. 명시된 필드들만이 유효성확인될 것이고, 출력 메시지 상의 다른 모든 필드들은 무시될 수 있다. 이 특징은 예상 테스트가 전체 메시지를 유효성확인하는 것과 대조적으로, 더욱 효율적인 경우에, 특정한 필드를 유효성확인하는 데에 중점을 두는 것을 허용하며, 효과적으로 예측될 수 없는 타임스탬프 등의 동적 필드를 취급하는데 특히 유용할 수 있다.

일부 실시예에서, 테스트 하네스는 예상 메시지에 관한 선택적 메시지 유효성확인을 허용할 수 있다. 사용자는 주어진 테스트에 관해 유효성확인할 메시지 타입의 목록을 명시할 수 있다. 애플리케이션에 의해 출력된 다른 모든 메시지 타입들은 무시될 수 있다. 이것은, 심박 메시지 등의, 테스트와 관련되지 않은 메시지를 필터링 아웃할 수 있다.

일부 실시예에서, 테스트 하네스는 케이스 생성을 허용할 수 있다. 테스트 하네스는, 주입 메시지의 목록만을 소비하고, 이들을 하나씩 애플리케이션 내에 주입하는 모드를 가질 수 있다. 그 다음, 애플리케이션이 출력하는 모든 메시지들은 수집될 수 있고 양쪽 목록으로부터 새로운 테스트 케이스 파일이 생성된다.

일부 실시예에서, 테스트 하네스는 대량 케이스 생성(mass case creation)을 허용할 수 있다. 테스트 하네스는, 셋업 주입 메시지 목록 뿐만 아니라 독립적인 개별 메시지 목록을 소비하는 모드를 가질 수도 있다. 테스트 하네스는 테스팅될 애플리케이션을 로딩할 수 있고, 셋업 메시지를 애플리케이션 내에 주입할 수 있으며, 독립된 메시지 목록으로부터의 하나의 메시지를 주입할 수도 있다. 그러면, 테스트 하네스는 애플리케이션으로부터의 모든 출력을 수집하고 풀-포맷팅된 테스트 케이스를 생성할 수 있다. 그 다음, 테스트 하네스는 애플리케이션을 재시작하고, 로딩 ->셋업 메시지 주입 -> 독립된 메시지 주입 -> 수집 -> 독립된 메시지 목록으로부터의 다음 메시지로 사이클 생성을 반복할 수 있다. 이 프로세스는 독립된 메시지 목록 내의 각 메시지에 대해 테스트 파일이 생성될까지 반복될 수 있다. 이런 방식으로, 테스트 하네스는, 고객-전송된 주문(customer-sent order) 상의 필드들의 모든 순열에 대한 테스트 등의, 많은 수의 유사한 테스트를 자동으로 생성할 수 있다.

일부 실시예에서, 테스트 하네스는 멀티-애플리케이션 테스팅을 허용할 수 있다. 테스트 하네스는 복수의 애플리케이션을 로딩하고 그들 각각의 독립된 기능 뿐만 아니라 다른 애플리케이션과 상호작용하는 각 애플리케이션의 기능들을 테스팅하는 능력을 가질 수 있다. 테스트 하네스는 명시된 애플리케이션 세트를 지정된 순서로 로딩할 수 있다. 일부 실시예에서, 이것은 순차적으로 상호작용하는 애플리케이션 세트를 통한 메시지들의 흐름에 기초할 수 있다. 그러면, 테스트 하네스는, 주입 메시지를 세트 내의 첫 번째 애플리케이션 내에 입력할 수 있고, 출력 메시지를 유효성확인할 수 있으며, 출력 메시지를 시퀀스 내의 다음 애플리케이션 내에 주입할 수 있고, 이것을 유효성확인할 수 있는 등등의 식이다.

테스트 하네스는 개별 테스트 또는 한 번에 많은 테스트를 수행할 수 있고, 일부 실시예에서는, 테스트들 사이에서 애플리케이션을 재시작할 수 있다. 이것은 테스트 케이스의 전체 목록을 통해 실시하고 개발자가 코드를 커밋(commit)하는 때마다 보고서를 생성하기 위해 자동화된 구축 프로세스(automated build process)와 통합될 수도 있다.

테스트 케이스를 동적으로 구축하기 위한 웹 사용자 인터페이스

테스트 구축기 사용자 인터페이스는 임의의 JSON 데이터 스키마(data schema)에 기초하여 테스트 케이스를 동적으로 구축하는 방식을 제공할 수 있다. 일부 실시예에서, 테스트 UI는, JSON 포맷으로 로딩될 수 있고 시스템 메시지 세트를 정의할 수 있는 스키마 파일의 위치를 파악할 수 있다. 스키마의 포맷에 기초하여, 사용자는 잠재적 메시지 목록을 제공받을 수 있다. 사용자가 메시지를 선택하면, 임의의 명시된 데이터 유효성확인 규칙과 함께, 스키마에서 정의될 수 있는, 메시지의 포맷에 기초하여 폼(form)이 동적으로 구축될 수 있다. 그러면, 사용자는 폼을 채우기 위해 선택될 수 있는 미리정의된 메시지 템플릿 목록을 제공받을 수 있다. 메시지 폼들이 사용자에 의해 완성되면, 이들은 분류가능한 목록에 추가될 수 있다. 사용자는, 각각의 메시지 항목을, 테스트 프레임워크 내에 주입되어야 하는 순서로 분류할 수 있다. 완성된 메시지들의 집합은 템플릿으로서 보관될 수 있고, 템플릿들은 결합되어 복합 테스트 케이스를 형성할 수 있다. 사용자는 메시지가 테스트 하네스에 의해 주입 또는 예상 메시지로서 취급되어야 하는지를 명시할 수 있다. 사용자가 예상 메시지가 무엇이어야 하는지를 확신하지 못하면, UI는 전체 케이스를 완성하기 전에 부분적 테스트 케이스가 주입되는 것을 허용할 수 있다. 부분적 테스트 케이스는, 테스트 하네스의 인스턴스(instance)를 호출할 수 있고 부분적 테스트 메시지 세트를 주입할 수 있는, 서버로의 REST를 통해 서빙될 수 있다. 테스트 하네스에 의해 생성된 출력 메시지는 UI로 반환되어 사용자에게 디스플레이될 수 있다. 그러면 사용자는 각 메시지를 검증할 수 있다. 사용자가 메시지를 승인하면, 그 메시지는 원-버튼 클릭(one-button click)에 의해 현재의 테스트 케이스에 추가되어 템플릿으로서 보관될 수 있는 테스트 케이스를 완성할 수 있다. 일단 테스트 케이스가 완성되고 나면, 단일 버튼 클릭은 테스트 하네스에 의해 실행될 수 있고 연속 구축 프로세스에서 구현될 수 있는 JSON 포맷팅된 테스트 케이스 파일을 생성할 수 있다.

테스트 UI는, 단독형 테스트 하네스에 의해 실행되는 테스트 케이스를 구축하기 위한 전적으로 동적인 웹 기반의 인터페이스를 제공할 수 있다. 이것은, 전체 데이터 유효성확인이 JSON 포맷팅된 데이터 스키마에만 기초하는 폼을 생성할 수 있다. 단일의 메시지를 거의 갖지 않는 부분적 테스트 케이스가 단독형 테스트 하네스 내에 주입되어, 그 때마다(on the fly), 사용자에게 시스템 출력 메시지를 제공할 수 있다. 전체 동작 테스트 케이스는, 테스트 하네스에 의해 이용될 수 있는 단일 버튼 클릭에 의해 생성될 수 있다. 추가적으로, 개별 테스트 케이스들은 결합되어 새로운 고도로 복잡한 테스트 케이스를 생성할 수 있다.

단일의 UI 요소를 이용하여 복합 데이터 질의를 생성하는 방법

일부 웹 애플리케이션은 사용자에게 멀티-컬럼 데이터(multi-column data)를 위한 질의 방법을 제공할 수 있다. 일부 실시예에서, 인터페이스는, 사용자가 데이터 요소 타입마다 검색 조건을 입력하는 것을 허용할 수 있는 분별 있는 폼 요소(discreet form element)를 제공할 수 있다. 대안으로서, 단일의 검색 박스가 제공되어 사용자가 상이한 데이터 타입들에 걸쳐 적용될 수 있는 검색 조건을 입력하는 것을 허용할 수 있다.

또 다른 실시예에서, 구조화된 검색 필드가 이용될 수 있다. 사용자는 미리정의된 스키마에 기초하여 구조화된 입력에 후속하는 단일 입력 박스를 제공받을 수 있다.

한 실시예에서, 사용자는 입력 박스를 선택할 수 있고 박스의 현재 컨텍스트를 나타내는 툴팁(tooltip)을 제공받을 수 있다. 입력 박스는, 예를 들어, 주문 Id(Order Id), 장소(Venue), 브로커(Broker), 가격(Price), 심볼(Symbol)과 같은, 스페이스 등의 임의 타입의 문자에 의해 분리된 복수의 데이터 타입을 포함할 수 있다.

일부 실시예에서, 사용자가 예를 들어 스페이스 바를 누름으로써 선택 박스에서 진행할 때, 입력 박스의 컨텍스트는 다음 검색 조건으로 진행될 수 있다. 새로운 툴팁이 제공되어, 사용자에게 검색 조건을 표시할 수 있다.

일부 구현에서, 사용자가 검색 박스를 진행해 가고 컨텍스트가 변함에 따라, 박스는 잠재적 검색값을 박스 아래의 드롭 다운(drop down)으로서 디스플레이하도록 구성될 수 있다.

일부 실시예에서, 검색 박스를 통한 사용자의 각 진행에 따라, 기저 데이터베이스, 데이터베이스 뷰, 및/또는 파일과 대조하여 동적 질의가 수행되어, 최종 결과가 신속하게 사용자에게 디스플레이될 수 있다.

다양한 실시예에서, 구조화된 검색 필드는: 미리정의된 스키마에 따라 단일 입력 박스에서 복수의 검색 조건을 이용할 수 있고; 상황에 따라 스키마를 스위칭하여, 검색 조건의 타입이나 조건이 입력될 수 있는 순서를 변경할 수 있고; 사용자가 검색 박스를 진행함에 따라 각 검색 조건에 대한 자동-완성 검색 값을 디스플레이할 수 있고; 사용자가, 검색 와일드카드를 자동으로 입력할 수 있는 스페이스 바를 누름으로써 검색 박스를 진행하는 것을 허용할 수 있고; 사용자가 검색 박스를 전후로 네비게이트하는 것을 허용할 수 있고; 선행 검색 조건에서의 사용자 입력을 이용하여 나중 조건의 잠재적 검색 값을 구동하고; 사용자가 박스를 진행할 때 툴팁을 디스플레이하여 커서 위치에서 검색 조건을 표시하고; 복수의 컬럼들에 걸친 복합 질의에 대한 응답 시간을 동적으로 개량하고 최적화할 수 있고; 및/또는 이와 유사한 것일 수 있다.

거래 로직 발명

중간점 제약

주식 가격책정 거래 집행(Pricing a stock trading execution)은, 수동 주문이 주문장에 포스팅(및 가격 우선순위를 위해 랭킹)되는 가격을 이용함으로써 이루어질 수 있다. 서로 상반되게 집행되는 2개의 공격적으로 가격책정된 주문의 경우, 그 결과는 도착해서 주문장에 먼저 입력된 주문의 가격에서의 집행일 수 있다 - 구체적으로는, 선행 주문은 그 공격적인 가격을 지불하는 반면 나중의 것은 "가격 개선"을 얻을 것이다. 대안적 방법에서, TLL 주문장은 집행 가격책정 계산을 변경하지 않을 수 있다; 오히려 이것은 TLL 주문장에서 주문이 얼마나 공격적으로 예약되는 것이 허용되는지를 제한할 수 있다.

TLL은 중간점 제약(Midpoint Constraint)이라 불리는 개념을 이용할 수 있다. TLL 주문장에서, 공격적 은닉된, 또는 비-디스플레이된, 주문들은 NBBO(national best bid/offer)의 중간점보다 더 공격적으로 포스팅되지 않을 수 있다. 2개의 공격적으로 가격책정된 은닉된 주문이 장부에 입력되어 중간점으로 재가격책정될 때, 결과적인 집행은 중간점 가격에서 발생할 수 있다. 매수자는 더 높은 가격에서 기꺼이 지불할 의사가 있고, 매도자는 더 낮은 가격에서 매도할 의사가 있었기 때문에, 양쪽 모두 우월한 집행 가격, 즉, 가격 개선을 수신할 수 있어서, 결과적으로 그들의 주문이 TLL 장부에 도달한 순서에 관계없이, 2명의 공격적 당사자들 사이의 스프레드(매수 가격과 매도 가격 사이의 차이)의 더욱 공정한 분배로 이어질 수 있다.

중간점 제약은 또한 몇 가지 다른 혜택을 제공할 수 있다. 예약된 주문(booked order)이 가격 우선순위에 대해 등급화되는 가격을 제한함으로써, 중간점 제약은, 한 당사자가 아주 조금 더 공격적인 제한 가격과 함께 그 자신의 주문을 제출함으로써 상대방에 비해 우선권을 가지려고 시도하는, "페니잉(pennying)" 형태로 은닉된 큐에서 가격 우선순위에 대한 불필요한 경쟁을 제한할 수 있다. 중간점 제약은 집행 가격으로부터 생기는 방향 정보 유출(directional information leakage)을 제한할 수 있다. 매수 가격과 매도 가격 사이의 중간점에서 발생하는 집행은 방향 중립 거래 프린트(direction neutral trade print)일 수 있으므로, 집행시에 가격이 어느 방향으로 (더 높게 또는 더 낮게) 움직일 수 있는지와 새로운 주문이 공급 또는 수요에서 증가를 나타냈는지를 분간하는 것이 더 어려울 수 있다. 이것은 또한 TLL 주문장 내의 공격적으로 가격책정된 조건적 주문들의 공정하고 질서 정연한 등급화를 유지하는 역할을 할 수도 있다.

중간점 제약은, 은닉 주문이 TLL 주문장으로의 포스팅을 추구할 때마다 그 제한 가격이 잠재적 집행을 위해 반대측 레스팅 주문(들)과 비교되도록 구현될 수도 있다. 어떠한 집행도 처리될 수 없다면 주문의 제한 가격은 NBBO 중간점과 비교될 수 있고, 주문 가격이 중간점보다 더 공격적이라면, 이것은 중간점에서 예약될 수 있다. 주문 가격이 중간점보다 덜 공격적이라면, 주문은 그 제한 가격에서 예약될 수 있다. 이 프로세스는, 시장 데이터 변화가 중간점을 변화시킬 때 NBBO의 중간점을 계산하여 중간점 제약 가격을 전처리함으로써 촉진될 수 있다. 일부 실시예에서, 이것은, 제약 중간점 가격을 미리계산한 다음 주문들이 TLL 주문장으로의 포스팅을 추구할 때 주문들에 적용함으로써 이루어질 수 있다.

최소량(Minimum Quantity)

최소량 주문은, 인바운드(신규)시에, 상대방 단일 주문 단독 또는 대량 주문 전체가 인바운드 주문 상의 최소량 조건을 만족하는 한, 단일 주문, 또는 대량의 상대방 주문에 대하여 거래될 자격이 있을 수 있다. 그러나, 어떠한 단일 주문이나 대량 주문도 인바운드 주문의 최소량 조건을 만족하지 않는다면, 인바운드 주문은 집행되지 않을 수 있고 대신에 주문장에 포스팅될 수 있다. 일단 이러한 주문이 주문장에 포스팅되고 나면, 이것은, 총체적으로 최소량 조건을 만족하는 단일의 새로운 인바운드 상대방 주문에 대하여 수동으로 집행될 수만 있다. 일단 인바운드 최소량 주문이 주문장에 삽입되고 나면, 향후의 어떤 시점에서 시장 조건이 변하거나 및/또는 새로운 상대방 주문이 장부에 입력된다면, 최소량 주문은 더 이상 최소량 조건을 만족하는 대량 주문과 함께 거래될 자격이 없을 수 있다.

장부 재검사(Book Recheck)

장부 재검사는, 최소량 주문들에게, TLL 주문장에 포스팅된 후에 그들의 최소량 조건을 복수의 상대방 주문들로 만족시키는 추가의 기회를 허용함으로써, 더 큰 유용성을 부여할 수 있다. 장부 재검사는, TLL 주문장 내의 적격의 마켓팅가능한 주문들에 걸쳐 장부 우선순위 순서로 반복하고, 장부의 반대측에 대하여 현재 거래될 수 있는 것이 있는지를 알기 위해 검사하고, 장부의 반대측 상의 주문들 각각을 마치 이들이 새로운 인바운드 주문인 것처럼 취급함으로써 이루어질 수 있다. 이것은 주문장의 정합 로직에 대한 계산 집약적이고 값비싼 프로세스일 수 있다.

주문장의 정합 로직에 대한 계산 비용의 일부를 경감하기 위하여, 외부 프로세스는 재검사되고 있는 주문을 취소하고 이들을 다시 정합 엔진에 되전송할 수 있다. 이것은 결국, 재검사가 주문(들)의 완전 집행을 시도하지 않는다면, 취소된 주문들에 대한 시간 우선순위에서의 손실로 이어질 수 있다.

TLL 구현은 재검사되고 있는 주문들에 대한 참조를 유지하여, 주문장 내의 주문들을 제거 또는 재정렬하지 않고 장부 재검사가 수행될 수 있게 함으로써, 재검사되는 주문들이 완전히 충족되지 않을 경우에도 시간 우선순위를 완전히 유지하는 것을 허용한다. 이들 주문 참조(order references)는 성공적인 및 실패한 재검사 시도 모두에 적합화되도록 업데이트될 수 있어서, 프로세스를 통틀어 장부 우선순위가 유지되는 것을 항상 보장한다.

성공적인 장부 재검사 프로세스는, 가입자로부터의 새로운 주문 지시, 전국 최상 매수 및 매도에서의 변경, 및 시장 데이터 변수에서의 기타의 변경을 포함하지만 이것으로 제한되지 않는 임의 개수의 이벤트에 의해 트리거될 수 있다. 이들 데이터는 편집 및 전처리되어, 실제의 재검사 동작을 수행하기 이전에, 집행이 발생할 것 같은지, 아닌지, 또는 보장되는지를 확인하기 위한 다양한 규제성 거래 제약 및 집계된 주식 카운트(aggregated share counts) 등의 중요한 메트릭이 될 수 있다. 이런 방식으로, 전처리는 장부 재검사의 계산 비용을 추가로 감소시킬 수 있다.

최소량 계층(Minimum Quantity Tiers)

최소량 지시는 0과 주문의 총 주식 카운트 사이의 임의의 어림수 주식 값(round number share value)을 허용할 수 있다(주문의 주식 카운트와 동등한 최소량은 모 아니면 도(all-or-none) 주문 조건처럼 취급된다). 이론적으로 무한 개수의 최소량 조건을 허용하는 것은 가입자에게 최대의 융통성을 제공하지만, 이것은 또한 비실용적일 수 있다. 최소량 조건을 갖는 주문과 뒤섞인 많은 주문을 갖는 주문장에서, 잠재적 집행을 위한 주문 비교 프로세스는 이론적으로 무제한이 될 수 있다. 즉, 이것은, 임의 쌍의 주문 또는 대량의 주문이 결합되어 비교중에 있는 주문들의 최소량 조건(들)을 만족할 수 있는지를 결정하고 그에 따라 거래가 집행될 수 있는지를 결정하기 위해 이론적으로 무한한 개수의 장부 내의 주문 조합들의 비교를 생성할 수 있다. 최소량 지시는 주문장에 걸쳐 무한하게 변할 수 있기 때문에, 각각의 레스팅 주문이 만족되는 최소량 지시를 갖고 있는지를 결정하기 위해 주문장을 통독하지 않고 주어진 인바운드 주문에 얼마나 많은 주식이 이용가능한지를 결정하는 어떠한 방법도 없을 것이다. 또한, 주문장이 인바운드 주문과 거래하기를 원치 않는(즉, 만족되지 않는 최소량 지시를 갖는) 많은 주문들을 포함한다면, 각각을 독파하여 개별적으로 건너뛰지 않고 이들 주문들을 분리할 효율적인 방법이 없다.

TLL은 효과적인 최소량, 및 최소량 계층을 가질 수 있다. 설정된 개수의 유효한 최소량 계층은 순열수를 제약할 수 있고 값이 매겨진 가장 흔하게 선택된 최소량(예를 들어, 200, 300, 500, 1000, 5000, 10000주)을 포착할 수 있다. 가입자의 주문 상의 최소량 지시가 어떠한 계층과도 정렬하지 않는다면, TLL 정합 엔진 및 주문장은, 그 값을 바로 다음의 가장 낮은 계층으로 라운딩 다운(rounding down)하는 유효 최소량을 이용하여 동작할 수 있다. 가입자의 지정된 값은 유지되고 지속될 수 있지만, 정합 로직 목적을 위해 유효값이 사용된다.

최소량 지시를 유한 세트의 흔히 사용되는 값으로 통합하는 것은, 최소량 지시를 만족하는데 있어서 표준화된 값의 이용으로 인해 니어 미스(near-miss)의 확률이 저하될 수 있기 때문에 최소량 주문에 대한 더 나은 집행 경험을 허용할 수 있다. 예를 들어, 575주의 최소량을 갖는 주문은 550주, 525주 등등의 최소량을 갖는 주문과 정합되지 못할 것이다. 니어 미스는, 2개의 주문이 정합되지 않게 할 수 있는 최소량에 대한 너무 미세한 입도(granularity)의 이용에 의해 야기될 수 있고, 여기서, 주문을 입력하는 가입자는 크기가 매우 근접한 상대방이 있었다는 것을 알았다면, 기꺼이 거래를 했을 수 있다. 최소량 옵션을 계층으로 제약함으로써, 이 문제가 감소된다. 예를 들어, 100-1000(100, 200, 300, 400, 500 등)으로부터 100주의 증분 단위로 계층을 시행함으로써, 이전 예의 주문들은 모두 최소량 조건 500으로 라운딩 다운될 것이고 서로 거래될 자격을 갖게 될 것이다. 이것은, 유사한 크기의 의사가 있는 상대방과의 거래를 부주의하게 방지하지 않으면서 최소 거래 크기 제약을 설정하는 주문의 목적과도 형평성이 있다.

TLL 주문장은 또한, 계층별로 최소량 주문들을 관리 및 저장할 수 있다. TLL 주문장은, 최소량 계층별로 유한 개수의 개별적으로 분류된 주문장들로 분할될 수도 있다. 최소량별 분할(partitioning by minimum quantity)의 결과, 주어진 주문장 내의 주문들의 최소량 지시 모두가 동일하게 되므로, 상기 주문장 내의 모든 주문이 균일하게 인바운드 또는 재검사 주문과 거래할 의사가 있거나 없을 것이므로, 정합 로직은 주어진 인바운드 또는 재검사 주문에 대해 얼마나 많은 주식이 주어진 주문장에서 이용가능한지를 더욱 신속하게 평가할 수 있다. 이러한 개념을 TLL 주문장의 각 파티션(partition)에 적용하는 것은 TLL이 일정한(constant) 시간에 얼마나 많은 주식이 인바운드 또는 재검사 주문에 이용가능한지를 평가하는 것을 허용할 수 있다.

최소량 계층은 또한 집행 과정에도 유용할 수 있다. 전체 장부 우선순위로 집행을 위한 파티션들을 재통합하는 과정에서, 주어진 파티션이 인바운드 주문에 의해 만족되지 않는 최소량을 갖고 있다면, TLL 정합 엔진은 그 파티션으로부터 전혀 정하지 못할 수 있다. 거래할 의사가 있는 파티션들만을 통합하는 것은 본질적으로, 어느 주문이 인바운드 주문과 거래할 의사가 있는지에 기초하여, 전체 주문장을 필터링할 수 있다. 이것은 그들의 최소량 지시에 기초하여 개개의 주문들을 사찰하고 건너뛸 필요성을 제거하여 계산 효율성을 증가시킬 수 있다.

최소량 참가(Minimum Quantity Participation)

레스팅 최소량 주문이 주문 큐의 앞쪽에 있지 않으면 최소량 구현은 제한될 수 있다. 충분히 큰 공격적인 상대방 주문이 도달하더라도, 이 상대방 주문은 장부 우선순위로 대상 주문에 앞서 레스팅 주문과 대조하여 집행되므로, 상기 상대방 주문에는, 대상 최소량 주문에 도착할 때쯤에는 충분한 주식수가 남아 있지 않을 수도 있다. 예를 들어, 100주에 대한 매수 주문이 500주의 최소량을 갖는 1000주 주문에 앞서 주문장에 있을 수 있다. 500주를 매도하는 인바운드 매도 주문이 도달하여 첫 번째 매수 주문과 100주가 거래되어, 400주가 남아 있다. 대상 최소량 주문은 500주 이상의 주식과 거래할 것이기 때문에, 인바운드 매도 주문은, 비록 매도 주문의 원래 크기가 500주 최소량 조건을 만족하더라도, 남은 400주와 거래되지 않을 것이다. 극단적인 예에서, 최소량 조건이 100,000주인 100,000주에 대한 블록 매수 주문이 주문장에서 75주에 대한 단주 매수 주문(odd lot buy order) 뒤에 남아 있을 수 있다. 100,000주에 대한 인바운드 매도 주문이 도달하고 75주 매수 주문과 함께 집행되어 99,925주가 남게 된다. 99,925는 장부에 남아 있는 매수 주문의 100,000주 최소량 조건을 만족하지 않기 때문에, 2개의 블록 주문은 정합하지 않을 것이다.

TLL은 참가(Participation)라 불리는 최소량 거동의 새로운 변형을 이용할 수 있다. TLL 상의 최소량 주문의 거동은, 인바운드시에, 상기 인용한 구현과 동일할 수 있다. 그러나, 주문장에서 레스팅하고 있을 때, 주문의 최소량 조건은, 최소량 주문에 대하여 집행을 시도할 때의 그 남아 있는 주식 카운트가 아니라, 집행 프로세스의 시작시의 인바운드 주문의 주식 카운트에 대하여 평가될 수 있다. 이것은 우선적으로 최소량 지시가 왜 존재하는지의 기저 목적 ― 주식을 집행하는 것과 신호/거래 정보를 포기하는 것 사이의 소정의 균형을 유지하는 개념 및 충분히 큰 관심과 상호작용하는 개념― 을 만족시키는데 도움을 준다.

상기의 블록 주문 예에서, 100,000주의 인바운드 매도 주문은 75주의 매수 주문과 거래되고, 100,000주의 원래 주문 크기가 레스팅 100,000주의 매수 주문의 최소량 주문을 충족하기 때문에, 레스팅 100,000주 매수 주문은 거래에 "참가"할 것이고 99.925주를 집행할 것이다.

참가는, 분할된 주문장과 연계하여, 정합 로직이, 주문장 내의 주문수와는 독립적으로, 주문장이 인바운드 또는 재검사 주문 상의 최소량 지시를 만족하기에 충분한 거래 관심을 포함하는지를 신속하게 평가하는 것을 허용하여, 집행이 없을 경우에 낭비되는 계산 및 시간량을 최소화할 수 있다.

TLL+1

TLL+1은 장소를 선택하고 거래 장소에 포스팅되는 주문들을 라우팅할 수 있다. 따라서, TLL+1은, 집행 요금 등의 명시적 비용을 밸런싱하면서 집행의 기회를 최대화하고, 항상 특정한 장소에서 주문의 일부를 표현하고자 하는 바람을 감안하여 시세 충격(quote impact)을 피하기 위하여 주문을 전송할 장소를 선택할 수 있다.

TLL+1은 다음과 같이 기능할 수 있다: TLL 스마트 주문 라우터가 주문을 분할하여 복수의 장소에 두기로 결정할 때, 이것은 선호하는 장소를 선택할 수 있고, 일부 경우에는, 적어도 하나의 추가 장소를 선택할 수 있다. 하나의 장소를 선호하는데에는 많은 상이한 이유가 있을 수 있다; 예를 들어, TLL이 시장 그 자체일 경우, 주문들을 먼 장소에 전송하여 집행하는 것에 비해 TLL 시장에서 주문들을 집행하는 것이 바람직할 수 있다. 추가의 장소를 선택하는 이유는, 선호되는 장소가 주문을 전송하기 위한 브로커의 최상 선택이 아닐 수도 있으므로, 추가의 매력적인 장소를 선택하여 주문을 알림으로써 집행을 수신할 가능성이 증가될 수 있다는 것이다. 추가의 장소는, 시장의 상태와 주문이 각 장소에서 부분적으로 집행될 경우 반대측 브로커에게 청구되는 잠재적 요금에 기초하여 선택될 수 있다. TLL 스마트 주문 라우터는 시장 내부에서 현재 표현된 장소들(전국 최상 매수 및 매도) 중에서 선택할 수 있다. 전국 최상 매수 또는 매도에 이미 존재하고 있는 장소의 주문장에 합류하도록 주문을 제출함으로써, 내부 시세에 새로운 장소를 도입하는 것이 회피될 수 있다, 즉, 시세 충격이 없다. 이들 장소들 중에서, 거래가 발생한다면 반대측 브로커에 대해 가장 비용-효율적인 장소가 선택될 수 있다. 대부분의 브로커는 적어도 부분적으로 경제성에 기초하여 라우팅 결정을 내리므로, TLL에 의해 먼 장소로 라우팅된 주문들이 내부 가격에서 유동성을 갖는 가장 비용-효율적인 장소에서 나타난다면, TLL 주문은 다른 거래 장소에서의 주문들보다 앞서 먼 장소에서 집행될 수 있다.

주문이 예비 유동성(reserve liquidity)을 가진다면, 즉, 주문의 일부가 디스플레이될 예정이고 일부는 은닉될 것이라면, 예비 유동성은 선호되는 장소에 머물 수 있다. 이것은 주문의 은닉 부분에 대한 대부분의 제어를 제공할 수 있다.

예약 주문(reserve order)의 디스플레이된 부분이 충족된다면, 즉, 선호되는 장소의 일부나, 추가 장소의 일부가 충족된다면, 선호되는 장소에서의 예비 유동성은 감소될 수 있고 새로운 디스플레이어 주문(displayer order)이 원래의 주문이 충족된 장소에 전송될 수 있다. 로직은, 주문이 단 하나 대신에 2개의 상이한 마켓 센터에서 2개(또는 다수)의 디스플레이된 부분을 갖는다는 점을 제외하고는, 예약 주문의 흔한 리프레쉬 방법(refresh methodology)과 유사하게 기능할 수 있다.

마지막으로, 어느 한 쪽의 조명된 부분(lit portion)이 남은 예비 유동성이 없을 때 완전히 충족된다면, 다른 장소에서의 나머지 조명된 주식은 주문이 완전히 충족되었던 장소로 재라우팅될 수 있다.

2진 검색 트리(Binary Search Tree)

여기서 설명된 시스템은 범용 컴퓨터의 휘발성 메모리 또는 물리적 컴퓨터-판독가능한 매체에 구현된 트리 데이터 구조에 관한 것이다. 트리는 복수의 데이터 노드로 구성된다. 각 데이터 노드는, 숫자키, (널 값일 수도 있는) 그 키에 대응하는 제로 이상의 데이터 값, 및 자식 노드로서 지정된 2개의 다른 데이터 노드, 즉, 좌측 자식 노드 및 우측 자식 노드에 대한 참조를 포함한다. 각각의 참조는 널 참조(null reference)일 수 있다. 부모 노드의 자식 노드들, 그 자식 노드의 자식 노드들 등은 부모 노드의 자손(descendant)이라 알려져 있다. 부모 노드가 널이 아닌 좌측 자식 노드를 가진다면, 좌측 자식 노드 및 그 비-널(non-null) 자손들 각각의 숫자키들은 부모 노드의 숫자키보다 작아야 한다. 마찬가지로, 우측 자식 노드가 널이 아니면, 우측 자식 노드 및 그 비-널(non-null) 자손들 각각의 숫자키들은 부모 노드의 숫자키보다 커야 한다. 트리는, 어떠한 다른 노드의 자식 노드가 아닌 루트 노드로서 지정된 노드를 가진다.

모든 숫자키들은 한정된 범위 내에 들 수 있다. 노드의 자식들과 그 자손들 각각에 대한 잠재적 숫자키들의 범위는 노드 그 자체에 대한 잠재적 값들의 범위로부터 결정될 수 있다. 현재의 데이터 구조에서, 부모 노드의 각 자식 노드의 값들은 그 노드의 잠재적 값들의 범위로부터 계산적으로 생성된다. 키와 그 대응하는 데이터 값이 트리에 추가될 때, 트리는 루트 노드로부터 그 키가 위치한 장소까지 순회된다. 순회시에 자식 노드에 대한 널 참조에 도달하면, 그 키에 대한 계산적으로 생성된 값, 제로 데이터 값들, 및 좌측 및 우측 자식 노드들에 대한 널 참조와 함께 새로운 데이터 노드가 생성되고, 순회된 노드 내의 널 참조가 새로운 노드에 대한 참조로 대체된다. 추가될 키를 갖는 노드에 도달하면, 대응하는 데이터에 대한 참조가 도달된 노드에 추가된다. 이런 방식으로, 트리 구조는 각 장소에서의 키들의 결정론적 생성에 의해 미리결정된다. 키 생성에 이용되는 방법의 선택에 의해, 트리 내에 키들이 삽입되는 순서에 관계없이, 알려진 최대 노드 깊이를 갖는 자동으로 밸런싱된 트리가 정확히 생성될 수 있다. 최대 노드 깊이는 고정되고 트리는 결코 리밸런싱되지 않기 때문에, 최악의 삽입 시간은 리밸런싱을 요구하는 트리보다 상당히 낮고, 그에 따라 트리는 금융 거래 시스템 등의 높은 신뢰성을 요구하는 애플리케이션에 적합하게 된다.

본 발명의 바람직한 실시예에서, 키 값이 미리결정되는 방법은 노드의 가능한 키 값들의 범위의 중앙값(median)을 선택하는 것이지만, 본 발명의 범위 내에서 다른 방법들이 이용될 수도 있다. 선택사항으로서, 루트 노드와 그 아래의 자식 노드들의 층들은 초기에 수동으로 결정된 키 값들로 생성될 수 있고, 이들 노드들의 자손들은 전술된 바와 같이 미리결정된 키 값들을 가진다.

또 다른 옵션으로서, 비-널 데이터를 갖는 모든 노드가 루트 노드 이외의 노드에 대해 가능한 값들의 범위 내의 키를 가진다면, 그 다른 노드는 "임시 루트 노드"로서 지정될 수 있고 원래의 루트 노드 대신에 모든 트리 횡단에 대한 소스로서 이용될 수 있다. 임시 루트 노드의 범위 외부의 키가 트리에 추가된다면, 임시 루트 노드 지정이 제거되고 원래의 루트 노드 또는 새로이 지정된 임시 루트 노드가 트리 횡단에 대한 소스로서 이용될 수 있다.

추가의 구현은, 값을 가질 가능성이 큰 노드들에 대한 참조들의 어레이로 트리를 보충하는 것이다. 예를 들어, 증권 거래 장소의 주문장의 경우에, 어레이는 증권의 전일의 종가 범위 내에서 매수 및 매도 가격을 포함할 것이다. 가능성있는 노드 어레이로의 인덱스가 숫자 키 값으로부터 계산될 것이다. 노드가 "가능성있는(likely)" 키로 액세스될 때, 어레이가 트리보다 우선적으로 이용되고, 트리는 어레이의 범위 외부의 "가능성없는(unlikely)" 키들 및 삽입들의 경우에만 이용된다.

설명된 발명은 이러한 주문에 명시된 가격별로 증권에 대한 매수 및 매도 주문을 조직화할 목적에 이용될 수 있다. 이러한 목적을 위해, 주문의 가격은 숫자 키로서 이용되고 주문에 관한 다른 정보는 연관된 데이터로서 저장된다. 트리는, "최상의 매수 및 매도"라 알려진 현재의 가장 높이 가격책정된 매수 주문과 가장 낮게 가격책정된 매도 주문을 갖는 노드들로의 특별한 링크와 함께, 가격별로 정렬된 모든 노드들의 링크된 목록과 연계하여 이용된다. 트리는 링크된 목록을 횡단할 필요성없이 새로운 주문의 신속한 삽입을 보조하는데 이용될 것이다. 집행은 최상의 매수 및 매도에서 가장 빈번하게 발생하기 때문에, 집행된 주문의 제거는 링크된 목록을 이용하여 달성될 것이다. 주문이 없는 노드 또는 남아있는 자식 노드들은 트리 및 링크된 목록으로부터 정리된다.

그러나, 본 발명의 응용은 이 특정한 응용보다 더 넓고, 본 발명의 범위는 본 발명의 모든 가능한 실시예를 포괄하도록 넓게 판독되어야 한다.

도 8a는 트리 구조의 노드와 그 콘텐츠: 숫자 키, 노드 아래에 위치할 수 있는 키들의 범위, 값들의 어레이, 및 좌측 자식 및 우측 자식 노드들에 대한 참조들을 도시한다.

도 8b는 가능한 키들이 1 내지 12(양쪽 끝 범위 포함)의 모든 정수인 트리의 고정된 골격을 도시한다. 각 노드의 값을 생성하는 규칙은 잠재적 값들의 범위의 중간점을 취하여 그 중간점이 가능한 키가 아니면 라운딩 다운(rounding down)하는 것이다. 각 위치 내의 노드들의 키 값들이 미리결정되더라도, 필요한 노드들만이 할당되고 구현시에 트리 내에 인스턴스화(instantiate)된다. 이것은 어레이 등의 미리-할당된 데이터 구조에 관해 메모리를 절감한다.

도 8c 및 도 8d는 1-12 범위를 갖는 새로운 트리의 생성과 도 8b의 중간점 규칙 및 키 7을 갖는 값의 삽입을 도시한다. 도 3a에 도시된 바와 같이 먼저 루트가 널이고, 루트의 범위는 트리의 전체 범위 1-12이다. 8d에서, 루트가 생성되고, 범위 1-12의 라운딩 다운된 중간값인 키 6이 할당된다. 7은 6보다 큰 키 값이므로, 이것은 루트 노드의 우측 자식 아래에 삽입되어야 한다. 도 3c에서, 루트의 우측 자식은 범위 7-12 및 라운딩 다운된 중앙값 9와 함께 생성된다. 여기서, 7은 9보다 작으므로, 노드 9의 좌측 자식 아래에 배치되어야 한다. 마지막으로, 도 8d에서, 노드 9의 좌측 자식은 범위 7-8 및 라운딩 다운된 중앙값 7과 함께 생성된다. 이것이 우리가 삽입하고자 하는 키이므로, 그 연관된 값이 키 노드에 추가되고 동작이 완료된다. 노드 6과 9가 트리에 존재하지만, 이들은 그것들과 연관된 값을 갖지 않으며, 이들은 연관된 값을 갖는 노드 7과는 상이한 음영으로 표현되어 있다.

도 8d는 도 3d에 도시된 트리로의 키 5를 갖는 또 다른 값의 삽입을 도시한다. 도 8d의 a에서, 횡단은 키 6을 갖는 루트 노드에서 시작한다. 5는 6보다 작으므로 좌측 자식이 선택된다. 후속 도면들에서, 널 자식 포인터들은 명료성을 위해 생략된다. 도 8d의 b에서, 좌측 자식은 범위 1-5 및 값 3인 새로운 노드로서 생성된다; 키 5를 갖는 값은 이 노드의 우측 자식 아래에 배치되어야 한다. 도 8d의 c는, 범위 4-5 및 값 4인 노드 3의 우측 자식의 생성을 도시한다. 마지막으로, 도 8d의 d는, 노드 5, 범위 5-5인 노드 4의 우측 자식, 및 그 노드에서의 값의 삽입을 도시한다. 이제 트리에는 6개 노드가 있고, 이들 중 2개는 값을 갖고 4개는 값을 갖지 않는다. 트리는 모든 키들과 노드들이 그들이 트리 내에 삽입되는 순서와 관계없이 동일한 위치를 갖는 것을 보장하기 때문에, 노드들의 배치는 도 2의 골격 트리에서의 그들의 배치와 정확히 대응한다.

TLL 제어기

도 9는 TLL 제어기(901)의 예시적 양태를 나타내는 블록도를 도시한다. 이 실시예에서, TLL 제어기(901)는, 다양한 기술들을 통한 컴퓨터와의 상호작용 및/또는 기타의 관련된 데이터를 집계, 처리, 저장, 탐색, 서빙(serve), 식별, 명령, 생성, 정합, 및/또는 용이하게 하는 역할을 할 수 있다.

사람 및/또는 기타의 시스템일 수 있는, 사용자, 예를 들어, (933a)는 정보 처리를 용이하게 하기 위해 정보 기술 시스템(예를 들어, 컴퓨터)에 관여한다. 차례로, 컴퓨터는 정보를 처리하기 위해 프로세서를 채용한다; 이러한 프로세서(903)는 중앙 처리 유닛(CPU)이라 부를 수 있다. 한 형태의 프로세서는 마이크로프로세서라 부른다. CPU는 명령어로서 작용하는 2진 인코딩된 신호를 전달하여 다양한 동작을 가능케하는 통신 회로를 이용한다. 이들 명령어는, 메모리(929)(예를 들어, 레지스터, 캐쉬 메모리, 랜덤 액세스 메모리 등)의 다양한 프로세서 액세스가능하고 동작가능한 영역 내의 기타의 명령어 및 데이터를 포함 및/또는 참조하는 연산 및/또는 데이터 명령어일 수 있다. 이러한 통신 명령어는 원하는 동작을 가능케하기 위해 프로그램 및/또는 데이터 컴포넌트로서 배치들(batches)(예를 들어, 명령어들의 배치들)로 저장 및/또는 전송될 수 있다. 이들 저장된 명령어 코드, 예를 들어, 프로그램은, 원하는 동작을 수행하기 위해 CPU 회로 컴포넌트 및 기타의 마더보드 및/또는 시스템 컴포넌트에 관여할 수 있다. 한 타입의 프로그램은, 컴퓨터 상의 CPU에 의해 실행될 수 있는 컴퓨터 운영 체제이다; 운영 체제는 사용자가 컴퓨터 정보 기술 및 자원에 액세스하고 작동하는 것을 가능케하고 용이하게 한다. 정보 기술 시스템에서 채용될 수 있는 일부 자원은: 데이터가 컴퓨터 내외로 전달될 수 있는 입력 및 출력 메커니즘; 데이터가 보관될 수 있는 메모리 스토리지; 및 정보를 처리할 수 있는 프로세서를 포함한다. 이들 정보 기술 시스템은, 데이터베이스 프로그램을 통해 용이하게 될 수 있는, 이후의 검색, 분석, 및 조작을 위해 데이터를 수집하는데 이용될 수 있다. 이들 정보 기술 시스템은 사용자가 다양한 시스템 컴포넌트에 액세스하고 작동하는 것을 허용하는 인터페이스를 제공한다.

한 실시예에서, TLL 제어기(901)는: 사용자 입력 장치(911)로부터의 한 명 이상의 사용자; 주변 장치(912); 선택사항적 암호 프로세서 장치(928); 및/또는 통신 네트워크(913)(이것으로 제한되지 않음)와 같은 엔티티들에 접속하거나 및/또는 이들과 통신할 수 있다. 예를 들어, TLL 제어기(901)는, 사용자, 예를 들어, (933a), 개인용 컴퓨터(들), 서버(들), 및/또는, 셀룰러 전화(들), 스마트폰(들)(예를 들어, iPhone®, Blackberry®, Android OS-기반의 전화 등), 태블릿 컴퓨터(들)(예를 들어, Apple iPad™, HP Slate™, Motorola Xoom™ 등), 전자책(eBook) 리더기(들)(예를 들어, Amazon Kindle™, Barnes and Noble의 Nook™ eReader, 등), 랩탑 컴퓨터(들), 노트북(들), 넷북(들), 게이밍 콘솔(들)(예를 들어, XBOX Live™, Nintendo® DS, Sony PlayStation® Portable, 등), 휴대형 스캐너(들), 및/또는 이와 유사한 것을 포함하지만 이것으로 제한되지 않는 다양한 모바일 장치(들)을 포함한, 그러나 이것으로 제한되지 않는, 동작 클라이언트 장치(들), 예를 들어, (933b)에 접속 및/또는 이들과 통신할 수 있다.

네트워크는 흔히, 그래프 토폴로지에서 클라이언트, 서버, 및 중간 노드들의 상호접속 및 연동을 포함하는 것으로 여겨진다. 본 출원 전체에 사용되는 용어 "서버"란, 일반적으로, 통신 네트워크에 걸쳐서 원격 사용자의 요청을 처리하고 이에 응답하는, 컴퓨터, 기타의 장치, 프로그램, 또는 이들의 조합을 말한다는 점에 유의해야 한다. 서버는 요청측 "클라이언트"에게 그들의 정보를 서빙한다. 여기서 사용될 때 용어 "클라이언트"란, 일반적으로, 처리 및 요청을 행하고 통신 네트워크에 걸쳐서 서버로부터의 임의의 응답을 취득 및 처리할 수 있는, 컴퓨터, 프로그램, 기타의 장치, 사용자 및/또는 이들의 조합을 말한다. 정보 및 요청 및/또는 나아가 소스 사용자로부터 목적지 사용자로의 정보의 전달을 가능케하고 처리하는, 컴퓨터, 기타의 장치, 프로그램, 또는 이들의 조합은 흔히 "노드"라 불린다. 네트워크는 일반적으로 소스 포인트로부터 목적지로의 정보의 전달을 가능케하는 것으로 여겨진다. 특별히 소스로부터 목적지로의 정보의 전달을 조장하는 노드는 흔히 "라우터"라 불린다. 근거리 통신망(LAN), 피코 네트워크(Pico network), 광역 네트워크(WAN; Wide Area Network), 무선 네트워크(Wireless Network)(WLAN) 등의 많은 형태의 네트워크가 있다. 예를 들어, 인터넷은 일반적으로, 원격 클라이언트와 서버들이 서로 액세스하여 연동될 수 있는 많은 네트워크들의 상호접속으로 받아들여진다.

TLL 제어기(901)는, 메모리(929)에 접속된 컴퓨터 체계(902) 등의 컴포넌트들을 포함하지만 이것으로 제한되지 않는 컴퓨터 시스템에 기초할 수 있다.

컴퓨터 체계(Computer Systemization)

컴퓨터 체계(902)는, 클록(930), 중앙 처리 유닛("CPU(들)" 및/또는 "프로세서(들)"(이들 용어는 달리 표시하지 않는 한 본 개시 전체를 통해 서로 바꾸어 사용된다)(903), 메모리(929)(예를 들어, 판독 전용 메모리(ROM)(906), 랜덤 액세스 메모리(RAM)(905) 등), 및/또는 인터페이스 버스(906)를 포함할 수 있고, 반드시는 아니지만, 가장 빈번하게, 이들 모두는 상호접속되고 및/또는 명령어(예를 들어, 2진 인코딩된 신호)가 통신, 동작, 저장 등을 실시하기 위해 이동할 수 있는 도전성 및/또는 기타의 수송 회로 경로를 갖는 하나 이상의 (마더)보드(들)(902) 상의 시스템 버스(904)를 통해 통신한다. 컴퓨터 체계는 전원(986)에 접속될 수 있다; 예를 들어, 선택사항으로서 전원은 내부적일 수 있다. 선택사항으로서, 암호 프로세서(926) 및/또는 트랜시버(예를 들어, IC)(964)는 시스템 버스에 접속될 수 있다. 또 다른 실시예에서, 암호 프로세서 및/또는 트랜시버는 인터페이스 버스 I/O를 통해 내부 및/또는 외부 주변 장치(912)로서 접속될 수 있다. 차례로, 트랜시버는 안테나(들)(965)에 접속될 수 있고, 이로써 다양한 통신 및/또는 센서 프로토콜의 무선 전송 및 수신을 실시한다; 예를 들어, 안테나(들)는: (예를 들어, 802.11n, Bluetooth 3.0, FM, 위성 위치확인 시스템(GPS; global positioning system)을 제공하는 (이로써 TLL 제어기가 그 위치를 결정하는 것을 허용하는)) Texas Instruments WiLink WL1283 트랜시버 칩, (예를 들어, 802.11n, Bluetooth 2.1 + EDR, FM, 등을 제공하는) Broadcom BCM4329FKUBG 트랜시버 칩, BCM28150 (HSPA+) 및 BCM2066 (Bluetooth 4.0, GPS, 등); Broadcom BCM4650IUB8 수신기 칩(예를 들어, GPS); (예를 들어, 2G/3G HSDPA/HSUPA 통신을 제공하는) Infineon Technologies X-Gold 618-PMB9800; Intel의 XMM 6160 (LTE & DC-HSPA), Qualcom의 CDMA(2000), 모바일 데이터/스테이션 모뎀(Mobile Data/Station Modem), Snapdragon, 및/또는 이와 유사한 것에 접속될 수 있다. 시스템 클록은 크리스탈 발진기를 가질 수 있고 컴퓨터 체계의 회로 경로를 통해 베이스 신호를 생성한다. 클록은, 시스템 버스, 및 컴퓨터 체계에서 상호접속된 다른 컴포넌트들에 대한 베이스 동작 주파수를 증가 또는 감소시키는 다양한 클록 배수기에 결합될 수 있다. 컴퓨터 체계 내의 클록 및 다양한 컴포넌트들은 시스템 도처에서 정보를 구현하는 신호를 구동한다. 컴퓨터 체계 도처에서 정보를 구현하는 명령어들의 이러한 전송 및 수신은 통신이라 부를 수 있다. 이들 통신 명령어는 더욱 멀리 전송, 수신되어, 당해 컴퓨터 체계를 넘어, 통신 네트워크, 입력 장치, 다른 컴퓨터 체계, 주변 장치, 및/또는 이와 유사한 것으로의 통신의 반환 및/또는 응답을 야기할 수 있다. 대안적 실시예에서, 상기 컴포넌트들 중 임의의 것은 서로 직접 접속되거나, CPU에 접속되거나, 및/또는 다양한 컴퓨터 시스템으로 예증되는 바와 같이 이용된 수많은 변형들로 조직화될 수 있다는 점을 이해해야 한다.

CPU는, 사용자 및/또는 시스템-생성된 요청을 실행하기 위한 프로그램 컴포넌트를 실행하기에 충분한 적어도 하나의 고속 데이터 프로세서를 포함한다. 종종, 프로세서들 자체는: 부동 소수점 유닛, 정수 처리 유닛, 통합된 시스템 (버스) 제어기, 로직 연산 유닛, 메모리 관리 제어 유닛과, 그래픽 처리 유닛, 디지털 신호 처리 유닛, 및/또는 이와 유사한 것과 같은 더욱 전문화된 처리 부-유닛(이것으로 제한되지 않음)과 같은 다양한 전문화된 처리 유닛들을 포함할 것이다. 추가로, 프로세서들은 내부 고속 액세스 어드레싱가능한 메모리를 포함할 수 있고, 프로세서 그 자체를 넘어선 메모리(929)를 맵핑 및 어드레싱할 수 있다; 내부 메모리는, 고속 레지스터, 다양한 레벨의 캐시 메모리(예를 들어, 레벨 1, 2, 3, 등), RAM 등을 포함하지만, 이것으로 제한되지 않는다. 프로세서는, 프로세서가 구성하고 디코딩하여 메모리 상태/값을 갖는 특정한 메모리 어드레스 공간으로의 회로 경로에 액세스하는 것을 허용하는, 명령어 어드레스를 통해 액세스가능한 메모리 어드레스 공간의 이용을 통해 이 메모리에 액세스할 수 있다. CPU는: AMD의 Athlon, Duron 및/또는 Opteron; ARM의 클래식(예를 들어, ARM6/9/11), 임베디드(Coretx-M/R), 애플리케이션(Cortex-A), 임베디드 및 보안 프로세서; IBM 및/또는 Motorola의 DragonBall 및 PowerPC; IBM 및 Sony의 셀(Cell) 프로세서; Intel의 Atom, Celeron (Mobile), Core (2/Duo/i3/i5/i6), Itanium, Pentium, Xeon, 및/또는 XScale; 및/또는 유사한 프로세서(들)와 같은 마이크로프로세서일 수 있다. CPU는 저장된 명령어(즉, 프로그램 코드)를 실행하기 위해 도전성 및/또는 수송성 도관(예를 들어, (인쇄된) 전자 및/또는 광학 회로)을 통과하는 명령어를 통해 메모리와 상호작용한다. 이러한 명령어 전달은 TLL 제어기 내에서 및 다양한 인터페이스를 통과하여 통신을 가능케 한다. 처리 요건이 더 많은 양의 속도 및/또는 용량을 지시한다면, 분산형 프로세서(예를 들어, 분산형 TLL), 메인 프레임, 멀티-코어, 병렬 및/또는 수퍼-컴퓨터 아키텍쳐가 유사하게 채용될 수 있다. 대안으로서, 배치 요건이 더 큰 휴대성을 지시한다면, 더 작은 모바일 장치(예를 들어, 스마트폰, PDA(Personal Digital Assistant) 등)이 채용될 수 있다.

특정한 구현에 따라, TLL의 피쳐들은 CAST의 R8051XC2 마이크로제어기; Intel의 MCS 51 (즉, 8051 마이크로제어기); 및/또는 이와 유사한 것과 같은 마이크로제어기를 구현함으로써 달성될 수 있다. 또한, TLL의 소정 피쳐를 구현하기 위해, 일부 피쳐 구현은, 주문형 집적 회로("ASIC"), 디지털 신호 처리("DSP"), 필드 프로그래머블 게이트 어레이("FPGA") 및/또는 유사한 임베디드 기술과 같은 임베디드 컴포넌트들에 의존할 수 있다. 예를 들어, TLL 컴포넌트 콜렉션 중 임의의 것(분산형이든 기타의 것이든) 및/또는 피쳐들은 마이크로프로세서를 통해 및/또는 임베디드 컴포넌트를 통해; 예를 들어, ASIC, 코프로세서, DSP, FPGA, 및/또는 이와 유사한 것을 통해 구현될 수 있다. 대안으로서, TLL의 일부 구현은 다양한 피쳐 또는 신호 처리를 달성하도록 구성되고 이용되는 임베디드 컴포넌트로 구현될 수 있다.

특정한 구현에 따라, 임베디드 컴포넌트는, 소프트웨어 솔루션, 하드웨어 솔루션, 및/또는 하드웨어/소프트웨어 솔루션 양자의 일부 조합을 포함할 수 있다. 예를 들어, 여기서 논의된 TLL 피쳐들은, "로직 블록"이라 불리는 프로그래머블 로직 컴포넌트, 및 Xilinx사에 의해 제조된 고성능 FPGA Virtex 시리즈 및/또는 저비용 Spartan 시리즈 등의, 프로그래머블 인터커넥트를 포함하는 반도체 장치인 FPGA의 구현을 통해 달성될 수 있다. 로직 블록 및 인터커넥트는, FPGA가 제조된 후에, 임의의 TLL 피쳐를 구현하기 위해, 고객이나 설계자에 의해 프로그램될 수 있다. 프로그래머블 인터커넥트의 계층구조는 1-칩 프로그래머블 브레드보드(breadboard)와 다소 유사하게, 로직 블록들이 TLL 시스템 설계자/관리자에 의해 필요할 때 상호접속되는 것을 허용한다. FPGA의 로직 블록들은 AND 및 XOR와 같은 기본적인 논리 게이트들, 또는 디코더와 같은 더 복잡한 조합 연산자들의 동작이나 간단한 수학 연산을 수행하도록 프로그램될 수 있다. 대부분의 FPGA에서, 로직 블록들은 또한, 회로 플립플롭 또는 메모리의 더 완전한 블록들일 수 있는 메모리 요소들을 포함할 수 있다. 일부 상황에서, TLL은 보통의 FPGA 상에 개발된 다음, 더욱 ASIC 구현을 모방하는 고정된 버전으로 이행(migrate)된다. 대안적인 또는 조율적인 구현은 FPGA 대신에 또는 이에 추가하여 TLL 제어기 피쳐들을 최종 ASIC으로 이행시킬 수 있다. 구현에 따라 앞서 언급된 임베디드 컴포넌트들 및 마이크로프로세서들 모두는 TLL을 위한 "CPU" 및/또는 "프로세서"로 간주될 수 있다.

전원(Power Source)

전원(986)은 다음과 같은 전지 등의 소형 전자 회로 기판 장치들에 전력을 공급하기 위한 임의의 표준 형태일 수 있다: 알칼라인, 수소화 리튬, 리튬 이온, 리튬 폴리머, 니켈 카드뮴, 태양 전지, 및/또는 이와 유사한 것. 다른 타입의 AC 또는 DC 전원도 역시 이용될 수 있다. 태양 전지의 경우, 한 실시예에서, 케이스는 태양 전지가 광자 에너지를 포획할 수 있는 개구(aperture)를 제공한다. 전원(986)은 TLL의 상호접속된 후속 컴포넌트들 중 적어도 하나에 접속됨으로써, 모든 상호접속된 컴포넌트에 전류를 제공한다. 한 예에서, 전원(986)은 시스템 버스 컴포넌트(904)에 접속된다. 대안적 실시예에서, I/O 인터페이스(908)를 통한 접속을 통해 외부 전원(986)이 제공된다. 예를 들어, USB 및/또는 IEEE 1394 접속은 접속을 통해 데이터와 전력 양쪽 모두를 운반하므로 적절한 전원이다.

인터페이스 어댑터들(Interface Adapters)

인터페이스 버스(들)(906)는 흔히, 반드시 어댑터 카드의 형태는 아니지만, 입력 출력 인터페이스(I/O)(908), 스토리지 인터페이스(909), 네트워크 인터페이스(910), 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 다수의 인터페이스 어댑터를 수락, 이에 접속, 및/또는 이에 통신할 수 있다. 선택사항으로서, 암호 프로세서 인터페이스(926)는 유사하게 인터페이스 버스에 접속될 수 있다. 인터페이스 버스는 인터페이스 어댑터들의 서로간의 뿐만 아니라 컴퓨터 체계의 다른 컴포넌트들과의 통신을 제공한다. 인터페이스 어댑터들은 호환 인터페이스 버스용으로 구성된다. 인터페이스 어댑터들은 확장 및/또는 슬롯 아키텍쳐를 통해 인터페이스 버스에 접속할 수 있다. AGP(Accelerated Graphics Port), 카드 버스(Card Bus), ExpressCard, (E)ISA[(Extended) Industry Standard Architecture], MCA(Micro Channel Architecture), NuBus, PCI(X)[Peripheral Component Interconnect (Extended)], PCI Express, PCMCIA(Personal Computer Memory Card International Association), Thunderbolt, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 다양한 확장 및/또는 슬롯 아키텍쳐가 채용될 수 있다.

스토리지 인터페이스(909)는, 스토리지 장치(914), 착탈식 디스크 장치, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 다수의 스토리지 장치를 수락, 이와 통신, 및/또는 이에 접속할 수 있다. 스토리지 인터페이스는, (울트라) (시리얼) ATA(PI)[(Ultra) (Serial) Advanced Technology Attachment (Packet Interface)], (E)IDE[(Enhanced) Integrated Drive Electronics], IEEE(Institute of Electrical and Electronics Engineers) 1394, 이더넷, 섬유 채널, SCSI(Small Computer Systems Interface), Thunderbolt, USB(Universal Serial Bus), 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 접속 프로토콜을 채용할 수 있다.

네트워크 인터페이스(910)는 통신 네트워크(913)를 수락, 이와 통신, 및/또는 이에 접속할 수 있다. 통신 네트워크(913)를 통해, TLL 제어기는 사용자(933a)에 의해 원격 클라이언트(933b)(예를 들어, 웹 브라우저를 갖춘 컴퓨터)를 통해 액세스가능하다. 네트워크 인터페이스는, 직접 접속, 이더넷(두꺼운, 얇은, 꼬인 쌍선 10/100/1000 Base T, 및/또는 이와 유사한 것), 토큰 링(Token Ring), IEEE 802.11a-x와 같은 무선 접속, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 접속 프로토콜을 채용할 수 있다. 처리 요건이 더 많은 양의 속도 및/또는 용량을 지시한다면, 분산형 네트워크 제어기(예를 들어, 분산형 TLL) 아키텍쳐가 유사하게 채용되어, TLL 제어기에 의해 요구되는 통신 대역폭을 푸울(pool), 부하 밸런싱, 및/또는 기타의 방식으로 증가시킬 수 있다. 통신 네트워크는 다음 중 임의의 하나 및/또는 조합일 수 있다: 직접 상호접속; 인터넷; LAN(Local Area Network); MAN(Metropolitan Area Network); OMNI(Operating Missions as Nodes on the Internet); 보안된 맞춤형 접속; WAN(Wide Area Network); (예를 들어, WAP(Wireless Application Protocol), I-mode, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 프로토콜을 채용하는) 무선 네트워크; 및/또는 이와 유사한 것. 네트워크 인터페이스는 입력 출력 인터페이스의 특별한 형태로 간주될 수 있다. 또한, 다양한 통신 네트워크 타입(913)에 관여하기 위해 복수의 네트워크 인터페이스(910)가 이용될 수 있다. 예를 들어, 브로드캐스트, 멀티캐스트, 및/또는 유니캐스트 네트워크를 통한 통신을 허용하기 위해 복수의 네트워크 인터페이스가 채용될 수 있다.

입력 출력 인터페이스(I/O)(908)는, 사용자 입력 장치(911), 주변 장치(912), 암호 프로세서 장치(928), 및/또는 등등을 수락, 이와 통신, 및/또는 이에 접속할 수 있다. I/O는, 오디오: 아날로그, 디지털, 모노, RCA, 스테레오, 및/또는 이와 유사한 것; 데이터: ADB(Apple Desktop Bus), Bluetooth, IEEE 1394a-b, 시리얼, USB(universal serial bus); 적외선; 조이스틱; 키보드; 미디(midi); 옵티컬; PC AT; PS/2; 패러랠; 라디오(radio); 비디오 인터페이스: ADC(Apple Desktop Connector), BNC, 동축, 컴포넌트, 컴포지트, 디지털, 디스플레이포트(DisplayPort), DVI(Digital Visual Interface), 고선명 멀티미디어 인터페이스(HDMI), RCA, RF 안테나, S-Video, VGA, 및/또는 이와 유사한 것; 무선 트랜시버: 802.11a/b/g/n/x; Bluetooth; 셀룰러(예를 들어, CDMA(code division multiple access), 고속 패킷 액세스(HSPA(+)), 고속 다운링크 패킷 액세스(HSDPA), GSM(global system for mobile communications), 롱텀 에볼루션(LTE), WiMax, 등); 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 접속 프로토콜을 채용할 수 있다. 한 출력 장치는, CRT(Cathode Ray Tube), LCD(Liquid Crystal Display), LED(Light Emitting Diode), OLED(Organic Light Emitting Diode), 플라즈마, 및/또는 이와 유사한 것에 기초한 비디오 인터페이스로부터의 신호를 수락하는 인터페이스(예를 들어, VGA, DVI 회로 및 케이블)를 갖춘 모니터의 형태를 취할 수 있는 비디오 디스플레이일 수 있다. 비디오 인터페이스는 컴퓨터 체계에 의해 생성된 정보를 합성하여 비디오 메모리 프레임 내의 합성된 정보에 기초하여 비디오 신호를 생성한다. 또 다른 출력 장치는, 비디오 인터페이스로부터 신호를 수락하는 텔레비전 세트이다. 종종, 비디오 인터페이스는, 비디오 디스플레이 인터페이스를 수락하는 비디오 접속 인터페이스(예를 들어, RCA 컴포지트 비디오 케이블을 수락하는 RCA 컴포지트 비디오 커넥터; DVI 디스플레이 케이블을 수락하는 DVI 커넥터, HDMI 등)를 통해 합성된 비디오 정보를 제공한다.

사용자 입력 장치(911)는 종종 소정 타입의 주변 장치(912)(이하 참조)이고, 카드 리더, 동글, 지문 리더, 장갑, 그래픽 태블릿, 조이스틱, 키보드, 마이크, 마우스(마우스들), 원격 제어, 망막 리더, 터치 스크린(예를 들어, 용량성, 저항성, 등), 트랙볼, 트랙 패드, 센서(예를 들어, 가속도계, 주변 광, GPS, 자이로스코프, 근접성 등), 스타일러스, 및/또는 이와 유사한 것을 포함할 수 있다.

주변 장치(912)는, 네트워크 인터페이스, 스토리지 인터페이스 등의 I/O 및/또는 기타의 유사한 설비들에, 인터페이스 버스, 시스템 버스, CPU 및/또는 이와 유사한 것에 직접, 접속 및/또는 통신할 수 있다. 주변 장치는, TLL 제어기의 외부적, 내부적, 및/또는 그 일부일 수 있다. 주변 장치는: 안테나, 오디오 장치(예를 들어, 라인-인, 라인-아웃, 마이크로폰 입력, 스피커 등), 카메라(예를 들어, 스틸, 비디오, 웹캠, 등), (예를 들어, 복사 방지용, 디지털 서명에 의한 보안 트랜잭션을 보장하기 위한, 및/또는 이와 유사한 것을 위한) 동글, (부가된 기능을 위한; 예를 들어, 암호 장치(928) 등의) 외부 프로세서, 포스-피드백 장치(force-feedback device)(예를 들어, 진동 모터), 근접장 통신(NFC) 장치, 네트워크 인터페이스, 프린터, 무선 주파수 식별자(RFID), 스캐너, 스토리지 장치, 트랜시버(예를 들어, 셀룰러, GPS 등), 비디오 장치(예를 들어, 고글, 모니터 등), 비디오 소스, 바이저(visor), 및/또는 이와 유사한 것을 포함할 수 있다. 주변 장치는 종종 입력 장치 타입들(예를 들어, 마이크로폰, 카메라 등)을 포함한다.

비록 사용자 입력 장치와 주변 장치가 채용될 수 있지만, TLL 제어기는, 임베디드, 전용, 및/또는 모니터없는(즉, 헤드리스) 장치로서 구현될 수 있고, 여기서, 네트워크 인터페이스 접속을 통해 액세스가 제공될 수 있다는 점에 유의해야 한다.

마이크로제어기, 프로세서(926), 인터페이스(926), 및/또는 장치(928)(이것으로 제한되지 않음)와 같은 암호 유닛들이 TLL 제어기와 부착 및/또는 통신할 수 있다. Motorola Inc.에 의해 제조된 MC68HC16 마이크로제어기는 암호 유닛용으로 및/또는 암호 유닛 내에서 이용될 수 있다. MC68HC16 마이크로제어기는, 16 MHz 구성의 16-비트 곱셈-및-누적 명령어(16-bit multiply-and-accumulate instruction)를 이용하며 512-비트 RSA 사설 키 연산을 수행하기 위해 1초 미만을 요구한다. 암호 유닛은, 상호작용하는 에이전트로부터의 통신 인증 뿐만 아니라 익명 트랜잭션의 허용을 지원한다. 암호 유닛은 또한 CPU의 일부로서 구성될 수도 있다. 동등한 마이크로제어기 및/또는 프로세서들도 역시 이용될 수 있다. 다른 시판 중인 전문화된 암호 프로세서로는: Broadcom의 CryptoNetX 및 기타의 보안 프로세서(Security Processors); nCipher의 nShield(예를 들어, Solo, Connect, 등), SafeNet의 Luna PCI(예를 들어, 6100) 시리즈; Semaphore Communications의 40 MHz Roadrunner 184; sMIP(예를 들어, 208956); Sun의 암호 가속기(Cryptographic Accelerators)(예를 들어, Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); 암호 명령어의 500+ MB/s를 수행할 수 있는 Via Nano Processor(예를 들어, L2100, L2200, U2400) 라인; VLSI Technology의 33 MHz 6868; 및/또는 이와 유사한 것이 포함된다.

메모리

일반적으로, 프로세서가 정보의 저장 및/또는 검색을 실시할 수 있게 하는 임의의 기계화(mechanization) 및/또는 실시예는 메모리(929)로서 간주된다. 그러나, 메모리는 대체가능한 기술 및 자원이므로, 임의 개수의 메모리 실시예들이 서로 대체하여 또는 서로 조화하여 채용될 수 있다. TLL 제어기 및/또는 컴퓨터 체계는 다양한 형태의 메모리(929)를 채용할 수 있다는 것을 이해해야 한다. 예를 들어, 컴퓨터 체계는, 온-칩 CPU 메모리(예를 들어, 레지스터), RAM, ROM, 및 기타 임의의 스토리지 장치의 동작이 종이 천공 테이프 또는 종이 천공 카드 메커니즘에 의해 제공되게끔 구성될 수 있다; 그러나, 이러한 실시예는 매우 느린 속도의 동작을 초래할 수 있다. 한 구성에서, 메모리(929)는, ROM(906), RAM(905), 및 스토리지 장치(914)를 포함할 수 있다. 스토리지 장치(914)는 임의 개수의 컴퓨터 스토리지 장치/시스템을 채용할 수 있다. 스토리지 장치는, 드럼; (고정식 및/또는 착탈식) 자기 디스크 드라이브; 광자기 드라이브; 광 드라이브(즉, 블루레이(Blueray), CD ROM/RAM/RecoTLLble (R)/ReWritable(RW), DVD R/RW, HD DVD R/RW 등); 장치들의 어레이(예를 들어, RAID(Redundant Array of Independent Disks)); 고체 상태 메모리 장치(USB 메모리, 솔리드 스테이트 드라이브(SSD) 등); 기타의 프로세서-판독가능한 스토리지 매체; 및/또는 유사한 기타의 장치를 포함할 수 있다. 따라서, 컴퓨터 체계는 일반적으로 메모리를 요구 및 이용한다.

컴포넌트 콜렉션(Component Collection)

메모리(929)는, 운영 체제 컴포넌트(들)(915)(운영 체제); 정보 서버 컴포넌트(들)(916)(정보 서버); 사용자 인터페이스 컴포넌트(들)(916)(사용자 인터페이스); 웹 브라우저 컴포넌트(들)(918)(웹 브라우저); 데이터베이스(들)(919); 메일 서버 컴포넌트(들)(921); 메일 클라이언트 컴포넌트(들)(922); 암호 서버 컴포넌트(들)(920)(암호 서버); TLL 컴포넌트(들)(935); 및/또는 이와 유사한 것(즉, 집합적으로 컴포넌트 콜렉션)(이것으로 제한되지 않음)과 같은 프로그램 및/또는 데이터베이스 컴포넌트 및/또는 데이터의 콜렉션을 포함할 수 있다. 이들 컴포넌트들은 스토리지 장치들 및/또는 인터페이스 버스를 통해 액세스 가능한 스토리지 장치들에 저장되어 그로부터 액세스될 수 있다. 컴포넌트 콜렉션 내의 것들과 같은 비-통상적인 프로그램 컴포넌트들은 로컬 스토리지 장치(914)에 저장될 수 있지만, 이들은, 주변 장치, RAM, 통신 네트워크를 통한 원격 스토리지 설비, ROM, 다양한 형태의 메모리, 및/또는 이와 유사한 것과 같은 메모리에 로딩 및/또는 저장될 수 있다.

운영 체제(Operating System)

운영 체제 컴포넌트(915)는 TLL 제어기의 동작을 용이하게 하는 실행가능한 프로그램 컴포넌트이다. 운영 체제는, I/O, 네트워크 인터페이스, 주변 장치, 스토리지 장치, 및/또는 이와 유사한 것의 액세스를 용이하게 할 수 있다. 운영 체제는: Apple Macintosh OS X(서버); AT&T Plan 9; Be OS; (AT&T의 UNIX; FreeBSD, NetBSD, OpenBSD, 및/또는 이와 유사한 것과 같은 BSD(Berkley Software Distribution) 변형; Red Hat, Ubuntu, 및/또는 이와 유사한 것과 같은 Linux 배포물과 같은) Unix 및 Unix-형 시스템 배포물; 및/또는 유사한 운영 체제 등의, 고도로 결함 내성의, 스케일가능한, 보안 시스템일 수 있다. 그러나, Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP(서버), Palm OS 및/또는 이와 유사한 것과 같은 더 제한된 및/또는 덜 보안된 운영 체제도 역시 채용될 수 있다. 추가로, Apple의 iOS, Google의 Android, Hewlett Packard의 WebOS, Microsofts Windows Mobile 및/또는 이와 유사한 것과 같은 이모바일 운영 체제(emobile operating systems)가 채용될 수 있다. 이들 운영 체제들 중 임의의 것이 NICK 제어기의 하드웨어 내에 임베디드되거나, 및/또는 메모리/스토리지 내에 저장/로딩될 수 있다. 운영 체제는, 그 자신 및/또는 이와 유사한 것을 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게, 운영 체제는, 다른 프로그램 컴포넌트, 사용자 인터페이스, 및/또는 이와 유사한 것과 통신한다. 예를 들어, 운영 체제는, 프로그램 컴포넌트, 시스템, 사용자, 및/또는 데이터 통신, 요청, 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다. 운영 체제는, 일단 CPU에 의해 실행되면, 통신 네트워크, 데이터, I/O, 주변 장치, 프로그램 컴포넌트, 메모리, 사용자 입력 장치, 및/또는 이와 유사한 것과의 상호작용을 가능케 할 수 있다. 운영 체제는, TLL 제어기가 통신 네트워크(913)를 통해 다른 엔티티들과 통신하는 것을 허용하는 통신 프로토콜을 제공할 수 있다. 다양한 통신 프로토콜이 TLL 제어기에 의해, 멀티캐스트, TCP/IP, UDP, 유니캐스트 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 상호작용을 위한 서브캐리어 수송 메커니즘으로서 이용될 수 있다.

정보 서버

정보 서버 컴포넌트(916)는 CPU에 의해 실행되는 저장된 프로그램 컴포넌트이다. 정보 서버는, 아파치 소프트웨어 재단(Apache Software Foundation)의 Apache, Microsoft의 인터넷 정보 서버(Internet Information Server), 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 인터넷 정보 서버일 수 있다. 정보 서버는, ASP(Active Server Page), ActiveX, (ANSI) (Objective-) C (++), C# 및/또는 .NET, CGI(Common Gateway Interface) 스크립트, 동적 (D) 하이퍼텍스트 마크업 언어(HTML), FLASH, Java, JavaScript, PERL(Practical Extraction Report Language), PHP(Hypertext Pre-Processor), 파이프(pipes), Python, 무선 애플리케이션 프로토콜(WAP; wireless application protocol), WebObjects 및/또는 이와 유사한 것과 같은 설비를 통해 프로그램 컴포넌트들의 실행을 허용할 수 있다. 정보 서버는, FTP(File Transfer Protocol); HTTP(HyperText Transfer Protocol); HTTPS(Secure Hypertext Transfer Protocol), SSL(Secure Socket Layer), 메시징 프로토콜(예를 들어, AOL(America Online) 인스턴트 메신저(Instant Messenger)(AIM), Apple의 iMessage, APEX(Application Exchange), ICQ, IRC(Internet Relay Chat), Microsoft Network (MSN) 메신저 서비스, PRIM(Presence and Instant Messaging Protocol), IETF(Internet Engineering Task Force)의 SIP(Session Initiation Protocol), SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions), 오픈 XML 기반의 XMPP(Extensible Messaging and Presence Protocol)(즉, Jabber 또는 Open Mobile Alliance(OMA)의 IMPS(Instant Messaging and Presence Service)), Yahoo! 인스턴트 메신저 서비스, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 보안 통신 프로토콜을 지원할 수 있다. 정보 서버는 웹 페이지 형태의 결과를 웹 브라우저에 제공하고, 다른 프로그램 컴포넌트와의 상호작용을 통해 웹 페이지들의 조작된(manipulated) 생성을 허용한다. HTTP 요청의 DNS(Domain Name System) 해결(resolution) 부분이 특정한 정보 서버에 대해 해결되어진 후에, 정보 서버는 HTTP 요청의 나머지에 기초하여 TLL 제어기 상의 특정된 위치의 정보에 대한 요청을 해결한다.

예를 들어, http://123.124.125.126/myInformation.html과 같은 요청은, 그 IP 어드레스에 있는 정보 서버에 대해 DNS 서버에 의해 해결된 요청의 IP 부분 "123.124.125.126"을 가질 수 있다; 그 정보 서버는 차례로 요청의 "/myInformation.html" 부분에 대한 http 요청을 추가로 파싱하여 그것을 정보 "myInformation.html"을 포함하는 메모리 내의 위치로 해결해 낸다. 추가로, 다양한 포트들을 통해 다른 정보 서빙 프로토콜들, 예를 들어, 포트 21을 통한 FTP 통신, 및/또는 이와 유사한 것이 채용될 수 있다. 정보 서버는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게, 정보 서버는, TLL 데이터베이스(919), 운영 체제, 기타의 프로그램 컴포넌트, 사용자 인터페이스, 웹 브라우저, 및/또는 이와 유사한 것과 통신한다.

TLL 데이터베이스로의 액세스는, 이하에서 열거되는 스크립팅 언어(예를 들어, CGI)를 통해 및 이하에서 열거되는 애플리케이션간 통신 채널(예를 들어, CORBA, WebObjects 등)을 통해서 등과 같은, 다수의 데이터베이스 브릿지 메커니즘을 통해 달성될 수 있다. 웹 브라우저를 통한 임의의 데이터 요청은 브릿지 메커니즘을 통해 TLL에 의해 요구되는 적절한 문법으로 파싱된다. 한 실시예에서, 정보 서버는 웹 브라우저에 의해 액세스가능한 웹 형태를 제공할 수 있다. 웹 형태의 공급된 필드들 내에 형성된 엔트리들은 특정한 필드들 내에 입력이 이루어졌고 그에 따라 파싱된 것으로 태깅된다. 입력된 조건들은, 파서에게 적절한 테이블 및/또는 필드로 향하는 질의어를 생성하게끔 지시하도록 작용하는, 필드 태그들과 함께 전달된다. 한 실시예에서, 파서는 검색 문자열을 태깅된 텍스트 엔트리에 기초하여 적절한 연결/선택 커맨드로 인스턴스화함으로써 표준 SQL로 질의어를 생성할 수 있고, 여기서, 결과 커맨드는 브릿지 메커니즘을 통해 TLL에 질의어로서 제공된다. 질의어로부터 질의어 결과를 생성할 때, 그 결과는 브릿지 메커니즘을 통해 전달되고, 브릿지 메커니즘에 의해 새로운 결과 웹페이지의 생성과 포맷팅을 위해 파싱될 수 있다. 그러면, 이러한 새로운 결과 웹 페이지는 정보 서버에 제공되고, 정보 서버는 이것을 요청측 웹 브라우저에 공급할 수 있다.

또한, 정보 서버는, 프로그램 컴포넌트, 시스템, 사용자 및/또는 데이터 통신, 요청, 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다.

사용자 인터페이스

일부 관점에서 컴퓨터 인터페이스는 자동차 작동 인터페이스와 유사하다. 조향 핸들, 기어 변속기, 및 속도계 등의 자동차 작동 인터페이스 요소들은 자동차 자원 및 상태의 액세스, 동작, 및 디스플레이를 용이하게 한다. 체크박스, 커서, 메뉴, 스크롤러, 및 윈도우와 같은 컴퓨터 상호작용 인터페이스 요소들(집합적으로 및 흔히 위젯이라 불림)은, 유사하게, 데이터와 컴퓨터 하드웨어와 운영 체제 자원 및 상태의 액세스, 능력, 동작, 및 디스플레이를 용이하게 한다. 동작 인터페이스는 흔히 사용자 인터페이스라 불린다. Apple Macintosh 운영 체제의 Aqua 및 iOS의 Cocoa Touch, IBM의 OS/2, Google의 Android Mobile UI, Microsoft의 Windows 2000/2003/3.1/95/98/CE/Millenium/Mobile/NT/XP/Vista/6/8(즉, Aero, Metro), (예를 들어, KDE(K Desktop Environment), mythTV 및 GNOME(GNU Network Object Model Environment) 등의 추가의 Unix 그래픽 인터페이스 라이브러리와 층들을 포함할 수 있는) Unix의 X-Windows, 웹 인터페이스 라이브러리들(예를 들어, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! 사용자 인터페이스(이것으로 제한되지 않음)와 같은 ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, 등 인터페이스 라이브러리들, 이들 중 임의의 것이 이용될 수 있음) 등의 그래픽 사용자 인터페이스(GUI)는 정보에 액세스하여 사용자에게 정보를 그래픽으로 디스플레이하는 베이스라인 및 수단을 제공한다.

사용자 인터페이스 컴포넌트(916)는 CPU에 의해 실행되는 저장된 프로그램 컴포넌트이다. 사용자 인터페이스는, 앞서 논의된 바와 같은 운영 체제 및/또는 동작 환경에 의해, 이와 함께, 및/또는 그 상부에 제공되는 그래픽 사용자 인터페이스일 수 있다. 사용자 인터페이스는, 텍스트 및/또는 그래픽 설비를 통해 프로그램 컴포넌트 및/또는 시스템 설비의 디스플레이, 실행, 상호작용, 조작, 및/또는 작동을 허용할 수 있다. 사용자 인터페이스는, 사용자가 컴퓨터 시스템을 실시, 상호작용, 및/또는 작동할 수 있는 설비를 제공한다. 사용자 인터페이스는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게, 사용자 인터페이스는, 운영 체제, 다른 프로그램 컴포넌트, 및/또는 이와 유사한 것과 통신한다. 사용자 인터페이스는, 프로그램 컴포넌트, 시스템, 사용자, 및/또는 데이터 통신, 요청, 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다.

웹 브라우저

웹 브라우저 컴포넌트(918)는 CPU에 의해 실행되는 저장된 프로그램 컴포넌트이다. 웹 브라우저는, Goofle의 (Mobile) Chrome, Microsoft Internet Explorer, Netscape Navigator, Apple의 (Mobile) Safari 등의 하이퍼텍스트 시청 애플리케이션, Apple의 Cocoa (Touch) 객체 클래스 등의 임베디드 웹 브라우저 객체, 및/또는 이와 유사한 것일 수 있다. 보안 웹 브라우징에는, HTTPS, SSL, 및/또는 이와 유사한 것에 의해 128비트(또는 그 이상의) 암호화가 제공될 수 있다. 웹 브라우저는 ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs(예를 들어, Chrome, FireFox, Internet Explorer, Safari Plug-in, 및/또는 기타 등등의 API들) 및/또는 이와 유사한 것과 같은 설비를 통해 프로그램 컴포넌트의 실행을 허용한다. 웹 브라우저 및 유사한 정보 액세스 툴은, PDA, 셀룰러 전화, 스마트폰, 및/또는 기타의 모바일 장치 내에 통합될 수 있다. 웹 브라우저는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게는, 웹 브라우저는, 정보 서버, 운영 체제, 통합된 프로그램 컴포넌트(예를 들어, 플러그인), 및/또는 이와 유사한 것과 통신한다; 예를 들어, 이것은, 프로그램 컴포넌트, 시스템, 사용자, 및/또는 데이터 통신, 요청, 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다. 또한, 웹 브라우저 및 정보 서버 대신에, 양쪽의 유사한 동작을 수행하도록 결합된 애플리케이션이 개발될 수도 있다. 결합된 애플리케이션은 유사하게, 정보의 취득과, TLL 장착된 노드로부터, 사용자, 사용자 에이전트, 및/또는 이와 유사한 것으로의 정보의 제공을 유사하게 실시할 수 있다. 결합된 애플리케이션은 표준 웹 브라우저를 채용한 시스템에서는 쓸모없을 수도 있다.

메일 서버

메일 서버 컴포넌트(921)는 CPU(903)에 의해 실행되는 저장된 프로그램 컴포넌트이다. 메일 서버는, Apple의 메일 서버(3), dovect, sendmail, Microsoft Exchange, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 인터넷 메일 서버일 수 있다. 메일 서버는, ASP, ActiveX, (ANSI) (Objective-) C (++), C# 및/또는 .NET, CGI 스크립트, Java, JavaScript, PERL, PHP, 파이프(pipes), Python, WebObjects, 및/또는 이와 유사한 것과 같은 설비를 통해 프로그램 컴포넌트의 실행을 허용할 수 있다. 메일 서버는, IMAP(Internet message access protocol), MAPI(Messaging Application Programming Interface)/Microsoft Exchange, POP3(post office protocol), SMTP(simple mail transfer protocol) 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 통신 프로토콜을 지원할 수 있다. 메일 서버는, TLL을 통해 및/또는 TLL로 전송, 중계, 및/또는 기타의 방식으로 횡단된 인입 및 송출 메일 메시지를 라우팅, 포워딩, 및 처리할 수 있다.

TLL 메일로의 액세스는, 개별 웹 서버 컴포넌트 및/또는 운영 체제에 의해 제공된 다수의 API를 통해 달성될 수 있다.

또한, 메일 서버는, 프로그램 컴포넌트, 시스템, 사용자 및/또는 데이터 통신, 요청, 정보 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다.

메일 클라이언트

메일 클라이언트 컴포넌트(922)는 CPU(903)에 의해 실행되는 저장된 프로그램 컴포넌트이다. 메일 클라이언트는, Apple (Mobile) Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, 및/또는 이와 유사한 것과 같은 메일 보기 애플리케이션일 수 있다. 메일 클라이언트는, IMAP, Microsoft Exchange, POP3, SMTP, 및/또는 이와 유사한 것과 같은 다수의 전송 프로토콜을 지원할 수 있다. 메일 클라이언트는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게는, 메일 클라이언트는, 메일 서버, 운영 체제, 기타의 메일 클라이언트, 및/또는 이와 유사한 것과 통신한다; 예를 들어, 이것은, 프로그램 컴포넌트, 시스템, 사용자, 및/또는 데이터 통신, 요청, 정보 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다. 일반적으로, 메일 클라이언트는 전자 메일 메시지를 작성 및 전송하는 설비를 제공한다.

암호 서버

암호 서버 컴포넌트(920)는, CPU(903), 암호 프로세서(926), 암호 프로세서 인터페이스(926), 암호 프로세서 장치(928), 및/또는 이와 유사한 것에 의해 실행되는 저장된 프로그램 컴포넌트이다. 암호 프로세서 인터페이스는 암호 컴포넌트에 의한 암호화 및/또는 암호해독 요청의 촉진을 허용할 것이다; 그러나, 암호 컴포넌트는 대안으로서 CPU 상에서 실행될 수도 있다. 암호 컴포넌트는 제공된 데이터의 암호화 및/또는 암호해독을 허용한다. 암호 컴포넌트는, 대칭 및 비대칭(예를 들어, PGP(Pretty Good Protection)) 암호화 및/또는 암호해독을 둘다 허용한다. 암호 컴포넌트는: 디지털 인증서(예를 들어, X.509 인증 프레임워크), 디지털 서명, 듀얼 서명, 엔빌로핑(enveloping), 패스워드 액세스 보호, 공개키 관리, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 암호 기술을 채용할 수 있다. 암호 컴포넌트는: 체크섬, DES(Data Encryption Standard), ECC(Elliptical Curve Encryption), IDEA(International Data Encryption Algorithm), (일방향 해쉬 동작인) MD5(Message Digest 5), 패스워드, RC5(Rivest Cipher), Rijndael, (Ron Rivest, Adi Shamir, 및 Leonard Adleman에 의해 1966년 개발된 알고리즘을 이용하는 인터넷 암호화 및 인증 시스템인) RSA, SHA(Secure Hash Algorithm), SSL(Secure Socket Layer), HTTPS(Secure Hypertext Transfer Protocol), 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 수많은 (암호화 및/또는 암호해독) 보안 프로토콜을 가능케할 것이다. 이러한 암호화 보안 프로토콜을 채용하여, TLL은 모든 인입 및/또는 송출 통신을 암호화할 수 있고 더 넓은 통신 네트워크를 갖는 가상 사설 네트워크(VPN; virtual private network) 내의 노드로서 역할할 수 있다. 암호 컴포넌트는 "보안 인증" 프로세스를 가능케함으로써 자원으로의 액세스가 보안 프로토콜에 의해 금지되고, 여기서 암호 컴포넌트는 보안된 자원으로의 인증된 액세스를 실시한다. 또한, 암호 컴포넌트는 콘텐츠의 고유 식별자를 제공할 수 있는데, 예를 들어, MD5 해쉬를 채용하여 디지털 오디오 파일에 대한 고유 서명을 취득한다. 암호 컴포넌트는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 암호 컴포넌트는 통신 네트워크를 통한 정보의 보안 전송을 허용하는 암호화 방식을 지원하여 TLL 컴포넌트가 원한다면 보안 트랜잭션에 관여할 수 있게 한다. 암호 컴포넌트는 TLL 상의 자원의 보안 액세싱을 가능케하고 원격 시스템 상의 보안된 자원의 액세스를 가능케한다; 즉, 이것은 보안된 자원의 클라이언트 및/또는 서버로서 역할할 수 있다. 가장 빈번하게, 암호 컴포넌트는, 정보 서버, 운영 체제, 다른 프로그램 컴포넌트, 및/또는 이와 유사한 것과 통신한다. 암호 컴포넌트는, 프로그램 컴포넌트, 시스템, 사용자, 및/또는 데이터 통신, 요청, 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다.

TLL 데이터베이스

TLL 데이터베이스 컴포넌트(919)는 데이터베이스 및 그 저장된 데이터에서 구현될 수 있다. 데이터베이스는, CPU에 의해 실행되는 저장된 프로그램 컴포넌트이다; 저장된 프로그램 컴포넌트 부분은 저장된 데이터를 처리하도록 CPU를 구성한다. 데이터베이스는, DB2, MySQL, Oracle, Sybase 및/또는 이와 유사한 것과 같은 다수의 장애 내성, 관계형, 스케일가능한, 보안된 데이터베이스 중 임의의 것일 수 있다. 관계형 데이터베이스는 플랫 파일(flat file)의 확장이다. 관계형 데이터베이스는 일련의 관련된 테이블로 구성된다. 테이블들은 키 필드를 통해 상호접속된다. 키 필드의 이용은, 키 필드에 대하여 인덱싱함으로써 테이블들의 조합을 허용한다; 즉, 키 필드들은 다양한 테이블로부터의 정보를 조합하기 위한 차원 피봇 포인트(dimensional pivot point)로서 역할한다. 관계는 일반적으로는, 1차 키를 정합함으로써 테이블들 사이에 유지된 링크를 식별한다. 1차 키들은 관계형 데이터베이스에서 테이블의 행들을 고유하게 식별하는 필드들을 나타낸다. 더 정확히는, 이들은 일대다 관계의 "한" 측 상의 테이블의 행들을 고유하게 식별한다.

대안으로서, TLL 데이터베이스는, 어레이, 해쉬, (링크된) 리스트, 구조(struct), 구조화된 텍스트 파일(예를 들어, XML), 테이블, 및/또는 이와 유사한 것과 같은 다양한 표준 데이터 구조를 이용하여 구현될 수 있다. 이러한 데이터 구조는 메모리 및/또는 (구조화된) 파일에 저장될 수 있다. 또 다른 대안에서, Frontier, ObjectStore, Poet, Zope, 및/또는 이와 유사한 것과 같은 객체-지향형 데이터베이스가 이용될 수 있다. 객체 데이터베이스들은, 공통의 속성에 의해 함께 그룹화 및/또는 링크되는 다수의 객체 콜렉션을 포함할 수 있다; 이들은 일부 공통의 속성에 의해 다른 객체 콜렉션에 관련될 수도 있다. 객체-지향형 데이터베이스는, 객체들이 단순한 데이터 조각이 아니고 주어진 객체 내에 캡슐화된(encapsulated) 기타 타입의 능력들을 가질 수도 있다는 점을 제외하고는 관계형 데이터베이스와 유사하게 동작한다. TLL 데이터베이스가 데이터-구조로서 구현된다면, TLL 데이터베이스(919)의 이용은 TLL 컴포넌트(935) 등의 또 다른 컴포넌트 내에 통합될 수 있다. 또한, 데이터베이스는, 데이터 구조, 객체, 및 관계형 구조의 혼합으로서 구현될 수 있다. 데이터베이스는 표준 데이터 처리 기술을 통해 무수한 변형들로 통합 및/또는 분산될 수 있다. 데이터베이스의 일부, 예를 들어, 테이블은 엑스포트(export) 및/또는 임포트(import)될 수 있으므로 분산화(decentralize) 및/또는 통합될 수 있다.

한 실시예에서, 데이터베이스 컴포넌트(919)는 수 개의 테이블(919a-k)을 포함한다. 사용자 테이블(919a)은: user_id, user_device_id, username, password, dob, first_name, last_name, age, state, address_firstline, address_secondline, zipcode, devices_list, contact_info, contact_type, alt_contact_info, alt_contact_type, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 사용자 테이블은 TLL 상의 복수의 엔티티 계정을 지원 및/또는 추적할 수 있다. 데이터 소스 테이블(919b)은, source_ID, source_name, source_server_IP, device_domain, source_url, source_security_protocol, source_ftp, device_securekey, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. POP 테이블(919c)은, pop_id, pop_address, pop_server_ip, pop_exchange, pop_transmittion_time, pop_history, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 인덱스 테이블(919d)은, index_id, index_name, index_attribute, index_value, index_rate, index_volume, index_timestamp, index_source, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 속성 테이블(919e)은, geo-location, industry, size, daily_volume, strategy_type, max_size, min_size, trade_order_id, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 매수 테이블(919f)은, bid_id, bid_time, bid_attribute, bid_ad_type, bid_ad_name, bid_ad_description, bid_rate, bid_result, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 주문 테이블(919g)은, order_id, order_name, order_participant, order_user_id, order_volume, order_bid_id, order_status, order_pop_id, order_latency, order_routing, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 금융 상품 테이블(919h)은, instrument_id, instrument_type, instrument_Reg, instrument_structure, instrument_asset_id, instrument_index, instrument_index_value, instrument_exchange_id, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 분석 테이블(919i)은, Analytics_id, analytics_time, analystics_ad_id, analytics_source_id, analytics_plot, analytics_prejection, analytics_map, analytics UI_template, analytics_buy_point, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 뉴스 테이블(919j)은, news_id, news_time, news_date, news_title, news_source, news_geo, news_zipcode, news_type, news_industry, news_target_audience, news_impact_audience, news_description, news_tag, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함할 수 있다. 시장 데이터 테이블(919k)은, market_data_feed_ID, asset_ID, asset_symbol, asset_name, spot_price, bid_price, ask_price, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 필드들을 포함한다; 한 실시예에서, 시장 데이터 테이블은, 예를 들어, Microsoft의 Active Template Library 및 Dealing Object Technology의 real-time toolkit Rtt.Multi를 통해, 시장 데이터 공급(예를 들어, Bloomberg의 PhatPipe, Dun & Bradstreet, Reuter의 Tib, Triarch, 등)으로 채워진다.

한 실시예에서, TLL 데이터베이스는 다른 데이터베이스 시스템과 상호작용할 수 있다. 예를 들어, 분산형 데이터베이스 시스템을 채용하면, 탐색 TLL 컴포넌트에 의한 질의와 데이터 액세스는, TLL 데이터베이스, 통합된 데이터 보안층 데이터베이스의 조합을 단일의 데이터베이스 엔티티로서 취급할 수 있다.

한 실시예에서, 사용자 프로그램은, TLL을 업데이트하는 역할을 할 수 있는 다양한 사용자 인터페이스 프리미티브(user interface primitive)를 포함할 수 있다. 또한, 다양한 계정은 TLL이 서빙할 필요가 있는 클라이언트의 타입과 환경에 따라 맞춤형 데이터베이스 테이블들을 요구할 수 있다. 시종일관 임의의 고유한 필드가 키 필드로서 지정될 수 있다는 점에 유의해야 한다. 대안적 실시예에서, 이들 테이블들은 그들 자신의 데이터베이스 및 그들 각각의 데이터 제어기들(즉, 상기 테이블들 각각에 대한 개별 데이터베이스 제어기) 내에 분산화될 수 있다. 표준의 데이터 처리 기술을 채용하면, 데이터베이스를 수 개의 컴퓨터 체계 및/또는 스토리지 장치에 걸쳐 추가로 분산시킬 수 있다. 유사하게, 분산화된 데이터베이스 제어기의 구성은 다양한 데이터베이스 컴포넌트(919a-k)를 통합 및/또는 분산시킴으로써 달라질 수 있다. TLL은 데이터베이스 제어기를 통해 다양한 설정, 입력, 및 파라미터를 추적하도록 구성될 수 있다.

TLL 데이터베이스는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게, TLL 데이터베이스는, TLL 컴포넌트, 다른 프로그램 컴포넌트, 및/또는 이와 유사한 것과 통신한다. 데이터베이스는, 다른 노드들 및 데이터에 관한 정보를 포함, 유지, 및 제공할 수 있다.

TLL들

TLL 컴포넌트(935)는 CPU에 의해 실행되는 저장된 프로그램 컴포넌트이다. 한 실시예에서, TLL 컴포넌트는 이전의 도면들에서 논의된 TLL의 양태들의 임의의 및/또는 모든 조합을 포함한다. 따라서, TLL은, 다양한 통신 네트워크를 통해, 정보, 서비스, 트랜잭션, 및/또는 이와 유사한 것의 액세스, 취득, 및 제공에 영향을 미친다. 여기서 논의된 TLL의 피쳐 및 실시예들은, 더욱 효율적인 데이터 구조와 이들의 전송 및 저장을 위한 메커니즘의 이용을 통해 데이터 전송 요건을 감소시킴으로써 네트워크 효율성을 증가시킨다. 결과적으로, 더 많은 데이터가 더 적은 시간에 전송될 수 있고, 트랜잭션에 관한 레이턴시도 역시 감소된다. 많은 경우에, 저장, 전송 시간, 대역폭 요건, 레이턴시 등에서의 이러한 감소는 TLL의 피쳐 및 설비를 지원하기 위한 용량 및 구조적 인프라구조 요건을 감소시킬 것이고, 많은 경우에서, TLL의 기저 인프라구조의 비용, 에너지 소비/요건을 감소시키고, 그의 수명을 연장한다; 이것은 TLL을 더욱 신뢰성 있게 하는 추가의 이점을 가진다. 유사하게, 많은 피쳐들 및 메커니즘들은 사용자가 이용 및 액세스하기에 더욱 쉽도록 설계됨으로써, TLL의 피쳐 세트를 향유/채용, 및 활용할 수 있는 오디언스(audience)를 확장시킨다; 이러한 이용 용이성은 또한 TLL의 신뢰성을 증가시키는 것을 돕는다. 또한, 피쳐 세트들은, 암호 컴포넌트(920, 926, 928)를 통해 언급된 바와 같은 시종일관 강화된 보안을 포함하여, 피쳐들 및 데이터로의 액세스를 더욱 신뢰성 있고 안전하게 한다.

TLL 컴포넌트는, 시장 데이터 콜렉션(942), POP 할당(943), POP 라우팅(944), 주문 집행(945), 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 TLL 컴포넌트들을 통한 매수/거래 요청(bidding/trading request)(예를 들어, 도 2의 203 참조)을 트랜잭션 레코드(예를 들어, 도 2의 218 참조) 및/또는 이와 유사한 것으로 변환할 수 있고, TLL의 이용은 감소된 레이턴시 및/또는 주문장 차익거래를 야기한다.

노드들 사이의 정보의 액세스를 가능케하는 TLL 컴포넌트는: Apache 컴포넌트, Assembly, ActiveX, 2진 실행가능코드(executables), (ANSI) (Objective-) C (++), C# 및/또는 .NET, 데이터베이스 어댑터, CGI 스크립트, Java, JavaScript, 맵핑 툴, 절차적 및 객체 지향적 개발 도구, PERL, PHP, Python, 쉘 스크립트(shell scripts), SQL 커맨드, 웹 애플리케이션 서버 확장판, 웹 개발 환경 및 라이브러리(예를 들어, Microsoft의 ActiveX; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; SOAP(Simple Object Access Protocol); REST(Representational State Transfer); SWFObject; Yahoo! 사용자 인터페이스; 및/또는 이와 유사한 것), WebObjects 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 표준 개발 도구 및 언어를 채용함으로써 개발될 수 있다. 한 실시예에서, TLL 서버는, 통신을 암호화 및 암호해독하기 위해 암호 서버를 채용한다. TLL 컴포넌트는, 자신 및/또는 유사한 설비를 포함한, 컴포넌트 콜렉션 내의 다른 컴포넌트들에 전달 및/또는 이들과 통신할 수 있다. 가장 빈번하게, TLL 컴포넌트는, TLL 데이터베이스, 운영 체제, 다른 프로그램 컴포넌트, 및/또는 이와 유사한 것과 통신한다. TLL은, 프로그램 컴포넌트, 시스템, 사용자, 및/또는 데이터 통신, 요청, 및/또는 응답을 포함, 통신, 생성, 취득, 및/또는 제공할 수 있다.

분산형 TLL

임의의 TLL 노드 제어기 컴포넌트의 구조 및/또는 동작은, 개발 및/또는 배치를 용이하게 하기 위해 임의 개수의 방식으로, 결합, 통합, 및/또는 분산될 수 있다. 유사하게, 컴포넌트 콜렉션은 배치 및/또는 개발을 용이하게 하기 위해 임의 개수의 방식으로 결합될 수 있다. 이를 달성하기 위해, 컴포넌트들을 공통의 코드 베이스 내에 또는 통합된 방식으로 요구시에 컴포넌트들을 동적으로 로딩할 수 있는 설비에 통합할 수도 있다.

컴포넌트 콜렉션은 표준 데이터 처리 및/또는 개발 기술을 통해 무수한 변형들로 통합 및/또는 분산될 수 있다. 프로그램 컴포넌트 콜렉션 내의 임의의 하나의 프로그램 컴포넌트의 복수의 인스턴스들이 단일 노드 상에서 및/또는 수많은 노드들에 걸쳐 인스턴스화되어 부하-밸런싱 및/또는 데이터-처리 기술들을 통해 성능을 향상시킬 수 있다. 또한, 단일 인스턴스도 복수의 제어기 및/또는 스토리지 장치; 예를 들어, 데이터베이스에 걸쳐 분산될 수 있다. 조화하여 동작하는 모든 프로그램 컴포넌트 인스턴스 및 제어기들이 표준의 데이터 처리 통신 기술을 통해 이렇게 할 수도 있다.

TLL 제어기의 구성은 시스템 배치의 정황에 의존할 것이다. 예산, 용량, 위치, 및/또는 기저 하드웨어 자원의 이용(이것으로 제한되지 않음)과 같은 인자들이 배치 요건 및 구성에 영향을 미칠 수 있다. 구성이 더욱 병합 및/또는 통합된 프로그램을 야기하는지, 더욱 분산된 일련의 프로그램 컴포넌트를 야기하는지, 및/또는 통합된 및 분산된 구성 사이의 소정의 조합을 야기하는지에 관계없이, 데이터는 통신, 취득, 및/또는 제공될 수 있다. 프로그램 컴포넌트 콜렉션으로부터 공통의 코드 베이스로 통합된 컴포넌트들의 인스턴스들은 데이터를 통신, 취득, 및/또는 제공할 수 있다. 이것은, 데이터 참조하기(예를 들어, 포인터), 내부 메시징, 객체 인스턴스 변수 통신(object instance variable communication), 공유된 메모리 공간, 가변적 패싱(variable passing), 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 애플리케이션내 데이터 처리 통신 기술을 통해 달성될 수 있다.

컴포넌트 콜렉션 컴포넌트들이 서로 별개의, 분리된, 및/또는 외부적이라면, 다른 컴포넌트들과의 및/또는 다른 컴포넌트들로의 데이터의 통신, 취득, 및/또는 제공은, API(Application Program Interfaces) 정보 전달; (D)COM[(distributed) Component Object Model], (D)OLE[(Distributed) Object Linking and Embedding], 및/또는 이와 유사한 것), CORBA(Common Object Request Broker Architecture), Jini 로컬 및 원격 애플리케이션 프로그램 인터페이스, JSON(JavaScript Object Notation), RMI(Remote Method Invocation), SOAP, 처리 파이프(process pipes), 공유된 파일, 및/또는 이와 유사한 것(이것으로 제한되지 않음)과 같은 애플리케이션간 데이터 처리 통신 기술을 통해 달성될 수 있다. 애플리케이션간 통신을 위한 별개 컴포넌트들 사이에서 또는 애플리케이션내 통신을 위한 한 개 컴포넌트의 메모리 공간 내에서 전송된 메시지는 문법의 생성과 파싱을 통해 용이하게 될 수 있다. 문법은, 컴포넌트들 내의 및 컴포넌트들 사이의 통신 메시지의 기초를 형성할 수 있는, 문법 생성 및 파싱 능력을 허용하는, lex, yacc, XML 및/또는 이와 유사한 것과 같은 개발 도구를 이용하여 개발될 수 있다.

예를 들어, 문법은, 예를 들어, 하기와 같은 HTTP 포스트 커맨드의 토큰들을 인식하도록 구성될 수 있다:

w3c -post http://... Value1

여기서, Value1은 파라미터로서 식별되는데, 이것은 "http://"가 문법 신택스의 일부이고, 그 다음 후속하는 것은 포스트 값의 일부로서 간주되기 때문이다. 유사하게, 이러한 문법에서, 변수 "Value1"은 "http://" 포스트 커맨드 내에 삽입된 다음 전송될 수 있다. 문법 신택스 그 자체는, 파싱 메커니즘(예를 들어, lex, yacc 등에 의해 처리되는 신택스 디스크립션 텍스트 파일)을 생성하기 위해 인터프리트되거나 및/또는 기타의 방식으로 이용되는 구조화된 데이터로서 제시될 수 있다. 또한, 일단 파싱 메커니즘이 생성 및/또는 인스턴스화되고 나면, 그 자체는, 문자(예를 들어, 탭) 구분된 텍스트, HTML, 구조화된 텍스트 스트림, XML, 및/또는 유사한 구조화된 데이터(이것으로 제한되지 않음)와 같은 구조화된 데이터를 처리 및/또는 파싱할 수 있다. 또 다른 실시예에서, 애플리케이션간 데이터 처리 프로토콜들 그 자체는, (예를 들어, 통신) 데이터를 파싱하는데 채용할 수 있는 통합된 및/또는 용이하게 이용가능한 파서(예를 들어, JSON, SOAP, 및/또는 유사한 파서)를 가질 수도 있다. 또한, 파싱 문법은 메시지 파싱을 넘어서 이용될 수 있지만, 또한, 데이터베이스, 데이터 콜렉션, 데이터 스토어, 구조화된 데이터, 및/또는 이와 유사한 것을 파싱하는 데에도 이용될 수 있다. 다시 한번, 원하는 구성은, 정황, 환경, 및 시스템 배치 요건에 의존할 것이다.

예를 들어, 일부 구현에서, TLL 제어기는, 클라이언트가, 데이터, 예를 들어, JSON 포맷으로 인코딩된 데이터를 전송할 수 있는 서버 포트 상의 인입 통신을 리스닝(listen)하는, 정보 서버를 통해 보안 소켓 층("SSL"; Secure Sockets Layer) 소켓 서버를 구현하는 PHP 스크립트를 실행하고 있을 수도 있다. 인입 통신의 식별시에, PHP 스크립트는 클라이언트 장치로부터 인입 메시지를 판독하여, 수신된 JSON-인코딩된 텍스트 데이터를 파싱해 JSON-인코딩된 텍스트 데이터로부터의 정보를 PHP 스크립트 변수로 추출하고, 데이터(예를 들어, 클라이언트 식별 정보, 등) 및/또는 추출된 정보를 구조화된 질의어("SQL"; Structured Query Language)를 이용하여 액세스가능한 관계형 데이터에 저장한다. 클라이언트 장치로부터 SSL 접속을 통해 JSON-인코딩된 입력 데이터를 수락하고, 데이터를 파싱하여 변수들을 추출하고, 데이터를 데이터베이스에 저장하기 위해 실질적으로 PHP/SQL 커맨드의 형태로 씌어진 예시적인 리스트가 이하에 제공된다:

또한, 이하의 자원들은 SOAP 파서 구현:

그리고 다른 파서 구현:

에 관한 예시적인 실시예를 제공하는데 이용될 수 있고, 이들 모두는 여기서 참조에 의해 명시적으로 포함된다.

본 분야에서 다양한 문제와 진보를 다루기 위하여, (커버 페이지, 발명의 명칭, 서두, 분야, 배경기술, 요약, 도면의 간단한 설명, 상세한 설명, 청구항, 요약서, 도면, 부록 및/또는 기타사항을 포함한) TRANSMISSION LATENCY LEVELING APPARATUSES, METHODS AND SYSTEMS를 위한 본 출원의 전체는, 청구되는 혁신이 실시될 수 있는 다양한 예시적인 실시예를 예시에 의해 보여준다. 본 출원의 이점 및 특징들은 실시예들의 대표적인 표본일 뿐이고, 빠짐없이 드러내거나 및/또는 배타적인 것이 아니다. 이들은 청구된 원리의 이해를 돕고 교시를 위해 제시된 것일 뿐이다. 이들은 모든 청구된 혁신들을 나타내는 것은 아니라는 점을 이해해야 한다. 따라서, 본 개시의 소정 양태들은 여기서 논의되지 않았다. 혁신의 특정한 일부에 대해서 대안적 실시예들이 제시되지 않았을 수도 있고, 또는 일부에 이용가능할 수 있는 더 설명되지 않은 대안적 실시예들은 이들 대안적 실시예들의 포기라고 간주되어서는 안 된다. 이들 설명되지 않은 많은 실시예들은 본 혁신과 동일한 원리를 포함하며 다른 실시예들도 균등하다는 것을 이해할 것이다. 따라서, 다른 실시예들이 이용될 수 있으며 본 개시의 범위 및/또는 사상으로부터 벗어나지 않고 기능적, 논리적, 동작적, 조직적, 구조적 및/또는 위상적 수정이 이루어질 수 있다는 것을 이해해야 한다. 따라서, 모든 예들 및/또는 실시예들은 본 개시 전체를 통해 비제한적인 것으로 간주된다. 또한, 여기서 논의되지 않은 것들과 관련한 여기서 논의된 실시예들에 관해 공간과 반복을 줄이기 위한 목적이라는 것 이외의 어떠한 유추도 해서는 안 된다. 예를 들어, 도면 및/또는 전체를 통틀어 설명된 임의의 데이터 흐름 시퀀스(들), 프로그램 컴포넌트(컴포넌트 콜렉션), 기타의 컴포넌트 및/또는 임의의 현존 피쳐 세트들의 임의의 조합의 논리적 및/또는 위상적 구조는 고정된 동작 순서 및/또는 배열로 제한되지 않고, 오히려, 임의의 개시된 순서는 예시이며, 순서에 관계없이, 모든 균등물들이 본 개시에 의해 고려된다는 점을 이해해야 한다. 또한, 이러한 피쳐들은 직렬 실행으로 제한되지 않고, 오히려 비동기적으로, 병렬로, 동시에, 동기적으로, 및/또는 기타 등등으로 실행될 수 있는 임의 개수의 쓰레드, 프로세스, 프로세서, 서비스, 서버, 및/또는 이와 유사한 것도 역시 본 개시에 의해 고려된다는 점을 이해해야 한다. 따라서, 이들 피쳐들 중 일부는, 이들이 단일의 실시예에서 동시에 존재할 수 없다는 점에서, 서로 상충될 수도 있다. 유사하게, 일부 피쳐들은 본 혁신의 한 양태에 적용가능하고, 다른 혁신에는 적용불가하다. 또한, 본 개시는 현재 청구되지 않은 기타의 혁신들을 포함한다. 출원인은, 현재 청구되지 않은 혁신들에 대해, 이러한 혁신을 청구할 권리, 추가의 출원, 연속 출원, 일부 계속 출원, 분할 출원, 및/또는 기타 등등을 제출할 권리를 포함한, 모든 권한을 보유한다. 따라서, 본 개시의 이점, 실시예, 예, 기능, 피쳐, 논리적, 동작적, 조직적, 구조적, 위상적 및/또는 기타의 양태들은 청구항에 의해 정의되는 본 개시에 대한 제한 또는 청구항의 균등물에 대한 제한으로서 간주되어서는 안 된다는 점을 이해해야 한다. TLL 개인 및/또는 기업 사용자, 데이터베이스 구성 및/또는 관계형 모델, 데이터 타입, 데이터 전송 및/또는 네트워크 프레임워크, 신택스 구조, 및/또는 이와 유사한 것의 특정한 필요성 및/또는 특성에 따라, 상당한 정도의 융통성과 맞춤화를 허용하는 TLL의 다양한 실시예들이 구현될 수 있다는 점을 이해해야 한다. 예를 들어, TLL의 양태들은 데이터 네트워크 대역폭 관리를 위해 구성될 수 있다. TLL의 다양한 실시예와 논의들이 전자 거래 플랫폼에 관련하여 설명되었지만, 여기서 설명된 실시예들은 다양한 다른 경매-기반의 시스템, 응용, 및/또는 구현을 위해 용이하게 구성 및/또는 맞춤화될 수 있다는 점을 이해해야 한다.

Claims (1)

1. 제1항에 기재된 장치.

Images