KR20080070801A - 거래 시스템 - Google Patents

Abstract

증권 거래에서의 1개의 주문 정보에 대해서, 수신, 거래 조건 확인, 거래 성립, 결과 송신의 각 처리를 시리얼로 실행하고 있다. 이 때문에, 특허 문헌 1에서는, 특정의 종목의 주문이 집중한 경우 등 거래량이 증가한 경우, 거래 처리가 스무스하게 흐르지 않는, 경우에 따라서는 시스템이 다운한다고 하는 문제가 발생하였다. 소위 트랜잭션(복수의 거래 요구)을, 소정의 단위로 분할하여 각각 각 처리(처리를 위한 서브 업무 단위를 포함함)를 병행 처리로 실행하도록 구성하였다. 또한, 본 발명에는, 이와 같이 분할한 경우에, 순서성을 보증하는 것도 포함된다. 예를 들면, 처리, 스텝마다 데이터베이스에 처리의 진척 상황을 저장해 두는 것이 포함된다. 또한, 소정의 단위로서는, 종목, 단말기, 시장, 서버 등이 포함된다.

거래 단말기, 유저 단말기, 데이터베이스, 서버, 트랜잭션

Description

거래 시스템{TRADING SYSTEM}

본 발명은, 주식 등의 유가 증권을 포함하는 상품의 거래를 포함하는 업무를 실현하기 위한 기술에 관한 것이다. 그 중에서도 거래, 특히 소위 증권 시장이라고 불리는 거래처에서 이용되는 증권 거래 시스템, 그 방법 및 그를 위한 프로그램에 관한 것이다.

종래, 증권 거래를 포함하는 거래에서는, 주문 정보를 수신하고, 주문 정보끼리를 비교하여 거래 조건을 충족시키는지의 여부에 의해 거래를 성립시키고 있었다(특허 문헌 1). 보다 구체적으로는, 입력 장치(32)로부터 입력된 증권 매매의 주문 정보, 거래 정보는, 제어 장치(33)를 통하여, 거래 기억 장치(34), 약정 기억 장치(36)에 기억된다. 주문 정보, 거래 정보는 주문 정보 송신부(35)를 통하여 각고객(10, 20)에게 송신되고, 표시 장치(12)에 표시된다. 거래가 성립한 경우에는, 거래 성립 정보 송신부(37)를 통하여, 거래 성립 정보가 송신되고, 표시 장치(12)에 표시되고, 스피커(13)로부터 경고음이 발해진다. 거래 내용이 확인된 경우에는, 주문 정보, 거래 성립 정보가 삭제되고, 약정 기억 장치(36)에 고객 식별 정보, 주문 정보, 거래 정보가 기억된다.

또한, 종래, 증권 거래 등의 업무를 실행하는 경우, 복수의 처리 장치를 제휴하여 업무를 실현하는 것이 실행되고 있다. 이와 같은 처리를 실행하기 위해서, 소위 큐를 이용하여 처리가 행해지고 있다. 예를 들면, 특허 문헌 2에서는, 이하의 구성이 개시되어 있다. 업무 프로세스 트랙킹 장치에 관한 것으로, 상이한 업무 시스템 간을 걸쳐서 행해지는 복수의 어플리케이션으로 이루어지는 업무 프로세스의 흐름을, 기존 시스템을 변경하지 않고 추적하는 것을 가능하게 하는 것을 목적으로 한다. 이 목적을 달성하기 위해서, 특허 문헌 2에서는, 이벤트 관리 장치(1)는, 각 업무 시스템 A3∼C5의 이벤트 추출부(32∼52)가 이벤트 추출 정의에 기초하여 추출한 이벤트 데이터를 수집하고, 이벤트 큐(12)에 큐잉한다. 이벤트 관련 지음부(13)는, 이벤트 데이터를 업무 데이터 단위로 통합하고, 업무 데이터 간의 관련 지음을 행하여 이벤트 관리 DB(14)에 축적한다. 유저 단말기(6)로부터 검색 조건이 입력되면, 출력부(16)가 검색 조건에 따라서 이벤트 관리 DB(14)를 검색하고, 업무 데이터 간의 관련을 트리 형식으로 유저 단말기(6)에 출력하여 표시한다.

[특허 문헌 1] 일본 특개 2001-297195호 공보

[특허 문헌 2] US 2005-0076059

그러나, 특허 문헌 1에서는, 1개의 주문 정보에 대해서, 수신, 거래 조건 확인, 거래 성립, 결과 송신의 각 처리를 시리얼로 실행하고 있다. 이 때문에, 특허 문헌 1에서는, 특정 종목의 주문이 집중한 경우 등 거래량이 증가한 경우, 거래 처리가 스무스하게 흐르지 않는, 경우에 따라서는 시스템이 다운한다고 하는 문제가 발생하였다.

또한, 특허 문헌 2에서는, 워크 플로우를 대상으로 하고 있고, 업무 프로세스를 어떻게 하여 파악(추적)할지를 목적으로 하고 있다. 즉, 특허 문헌 2에서는, 각 처리 장치가 실행할 처리가 행해지고 있지 않은 경우, 어떻게 리커버리(회복)시킬지에 관해서는, 특별히 고려되어 있지 않다. 이 때문에, 특허 문헌 2에서는, 처리 장치에서의 처리가 멈춘 경우, 소정의 업무를 효율적으로 회복시킬 수 없었다. 특히, 임의의 장치로부터 처리 의뢰(시한식의 소정 시간 등으로 그 효력이 소멸하는 것)를 발행하고, 그것을 트리거로 처리를 실행하는 것인 경우, 미처리의 안건이 축적되게 된다고 하는 문제가 발생한다. 또한, 이와 같이 미처리의 안건이 축적되면, 기억 장치 등의 하드웨어 자원이 낭비로 될 뿐만 아니라, 나아가서는 이들 하드웨어 자원을 포함하는 시스템이 정지하고, 거래를 포함하는 업무 자체가 중지되는 경우도 발생하게 된다.

따라서, 본 발명에서는, 소위 트랜잭션(복수의 거래 요구)을, 소정의 단위로 분할하여 각각 각 처리(처리를 위한 서브 업무 단위를 포함함)를 병행 처리로 실행하도록 구성하였다. 또한, 본 발명에는, 이와 같이 분할한 경우에, 순서성을 보증하는 것도 포함된다. 예를 들면, 처리, 스텝마다 데이터베이스에 처리의 진척 상황을 저장해 두는 것이 포함된다. 또한, 소정의 단위로서는, 종목, 단말기, 시장, 서버 등이 포함된다.

보다 구체적으로는, 각각이 복수의 그룹 중 어느 하나에 속하는 복수의 거래 단말기로서, 거래 요구를 송신하는 거래 단말기와 접속되고, 상기 거래 요구에 따른 증권 거래 처리를 행하는 거래 시스템에서, 상기 그룹마다, 거래 종목을 포함하는 거래 요구를 접수하는 수단과, 접수된 거래 요구를 정상적으로 수신하였는지의 여부를 확인하여, 정상적인 수신인 경우, 그 거래 요구를 송신한 거래 단말기에 수신 결과를 송신하여, 상기 거래 요구를 요건 데이터베이스에 저장하는 수단을 갖는 접수 장치(서버)와, 각각이 증권의 거래 종목에 대응하고 있는 복수의 거래 처리 장치(서버)로서, 상기 요건 데이터베이스로부터 자신의 거래 종목에 대응하는 거래 요구를 추출하는 수단과, 추출한 상기 거래 요구를, 거래 접수 가능한 상태로서 상기 요건 데이터베이스에 등록하는 수단을 갖는 복수의 거래 처리 장치(서버)와, 각각이 증권의 거래 종목에 대응하고 있는 복수의 약정 처리 장치(서버)로서, 상기 요건 데이터베이스에 등록된 거래 요구 중, 자신의 거래 종목에 따른 거래 요구에 대해서, 상기 거래 접수 가능한 상태로서 등록되어 있는 거래 요구에 따른 제2 거래 요구를 접수하는 수단과, 상기 거래 요구와 상기 제2 거래 요구로 약정 처리가 가능한지를 판단하는 수단과, 상기 약정의 결과를 반영한 거래 요구를 상기 요건 데이터베이스에 등록하는 수단을 갖는 복수의 약정 처리 장치(서버)를 포함하고, 복수의 증권 거래를 병행하여 실행 가능한 거래 시스템이다. 또한, 본 발명에는, 이 시스템을 구성하는 각 장치(서버), 방법, 이것을 실현하기 위한 프로그램도 포함된다.

또한 본 발명에는, 이하의 구성도 포함된다.

각 거래 단말기와 그룹의 대응 관계가 취해지도록, 접수 장치에서 이 쌍으로 되는 정보를 부가하여 이것을 이용하는 것이 포함된다. 여기서, 쌍으로 되는 정보로서는, 각 종목을 식별하는 정보와 종목 그룹의 대응 관계를 나타내는 정보도 포함된다.

또한, 본 발명에서는, 이하의 구성도 더 포함된다. 즉, 자신에 대한 처리 의뢰에 관한 정보가 없고, 실태로서는 처리할 것(안건, 요건 정보)이 존재하는 경우에는, 자신에 대하여 의뢰 정보를 발행하여 처리를 개시한다. 여기서, 본 발명에서는, 처리 의뢰에 관한 정보와 이것에 대응하고, 처리를 실행하기 위해서 필요한 요건 정보를 별도로 취급하는 것도 포함되고, 이 요건 정보의 유무에 의해 실체로서 처리할 것이 존재하는지를 판단하여도 된다.

보다 구체적으로는, 본 발명은 이하와 같이 구성된다.

각각이 복수의 그룹 중 어느 하나에 속하는 복수의 거래 단말기로서, 거래 요구를 송신하는 거래 단말기와 접속되고, 복수의 처리 장치로 구성되고 상기 거래 요구에 따른 증권 거래 처리를 행하는 거래 시스템으로서, 상기 복수의 처리 장치는, 적어도 상기 증권 거래 처리의 일부를 실행하기 위한 처리 의뢰로서 발행 후에 효력이 소멸하는 경우가 있는 처리 의뢰를 발행하는 제1 처리 장치 및 상기 의뢰 정보에 따른 처리를 실행하는 제2 처리 장치를 포함하고, 상기 제1 처리 장치가, 상기 처리 의뢰를 발행하고, 상기 처리 의뢰에 대응하는 상기 처리 의뢰에서 실행할 처리를 실행하기 위한 요건 정보를 요건 데이터베이스에 저장하고, 상기 제2 처 리 장치가, 발행된 처리 의뢰의 유무를 확인하고, (1) 상기 처리 의뢰가 있는 경우에는, 대응하는 요건 정보를 상기 요건 데이터베이스로부터 검색하여, 대응하는 처리를 실행하고, (2) 상기 처리 의뢰가 없는 경우에는, 상기 요건 데이터베이스를 검색하여, 자신이 실행할 처리 중, 미처리의 요건 정보를 검색하고, 미처리의 요건 정보가 있는 경우에는, 자신에 대하여 미처리의 요건 정보의 존재에 대응하는 의뢰 정보를 발행하고, 상기 의뢰 정보를 받아서 상기 요건 데이터베이스로부터, 대응하는 요건 정보를 취득하여, 해당하는 처리를 실행한다. 여기서, 발행 후 일정 기간 후에 효력이 소멸하는 처리 의뢰란, 머신의 장애 시 등에 회복되지 않는, 비영속적인 메시지를 포함한다. 또한, 일정 기간 후에 효력 혹은 자신이 소멸하는 것이어도 된다.

여기서, 발행된 처리 의뢰의 유무의 확인은, 유효한 처리 의뢰의 유무를 확인하는 것도 포함한다. 예를 들면, 발행된 처리 의뢰가 무효화(효력의 소멸 및 자신의 소멸을 포함하는 예를 들면, 타임아웃)되는 것을 검지하는 것도 포함된다. 또한, 제1 처리 장치는, 이 처리 의뢰를 소정의 데이터베이스(각 처리 장치로부터 액세스 가능한)에 기입한다. 또한, 이 데이터베이스는, 요건 데이터베이스로 하여도 된다. 또한, 제2 처리 장치의 처리 의뢰의 유무의 확인은, 상기 데이터베이스에 액세스함으로써 실행한다. 이 때, 요건 정보에 처리·미처리를 나타내는 플래그를 설치하고, 이 내용을 이용하여 유무의 확인을 실행하여도 된다. 단, 처리 의뢰를 제2 처리 장치에 송신하고, 요건 정보를 요건 데이터베이스에 저장하는 구성으로 하여도 된다.

또한, 제2 처리 장치가 발행하는 의뢰 정보는, 「의사」 처리 의뢰이어도 된다. 즉, 내용적으로, 처리 의뢰와 동일한 항목으로 하고, 대상의 요건 정보(처리 대상)를 요건 데이터베이스에 저장된 요건 정보에 따라서 입력한다. 즉, 요건 데이터베이스에 저장된 요건 정보 중, 자신이 처리할 것으로서, 미처리의 요건 정보를 추출하고, 그 요건 정보에 대응하는 식별 정보를 기입한다. 여기서, 타임 스탬프 기능을 이용하여 순서성을 유지하도록 구성하여도 된다. 즉, 추출된 요건 정보에는, 타임 스탬프 기능에 의해 기록된 의뢰 시를 나타내는 정보가 포함되어 있고, 이것을 이용하여 순서성을 유지하도록 제어한다.

또한, 의뢰 정보는, 타임아웃한(무효화) 것을 검지한 경우에, 발행하는 것도 본 발명에 포함된다.

또한, 상기에서, 이하의 처리를 실행하는 것도 본 발명에 포함된다. 상기 제2 처리 장치는, 상기 미처리의 처리 의뢰가 있는 경우(예를 들면, 타임아웃 등의 무효화를 검출한 경우), 그 미처리의 요건 정보의 건수를 계수하여, 상기 해당하는 처리를 실행한 경우 혹은 상기 대응하는 요건 정보를 취득한 경우, 상기 건수를 1 감산하여, 이 건수가 0을 나타낼 때까지 자신에의 의뢰 정보의 발행을 반복하는 것을 가능하게 한다.

여기서, 건수의 계수는, 이하와 같이 하여도 된다. 우선, 요건 정보에 자신이 처리 완료인지 미처리인지를 나타내는 정보를 포함시켜 두고, 이 중 미처리의 요건 정보로서, 자신이 처리할 것을 식별 정보 등에 의해 계수한다. 보다 구체적으로는, 이하와 같이 한다. 「그룹 코드」를 검색 조건으로 하는 경우는 그 프로 세스가 담당하는 「그룹 코드(그 그룹을 식별하는 식별자)」로의 집계, 「키」를 검색 조건으로 하는 경우는 그 프로세스가 담당하는 「그룹 코드」를 검색 조건으로 하여 「키」 단위로의 집계를 행하여, 재송용 MQ(의뢰 정보)로 그 건수를 설정한다(「키」의 경우에는, MQ는 미처리 요건이 있는 키의 종류만큼, 송신한다). 여기서, 미처리의 건수를 요건 데이터베이스의 내용으로부터 계수해 두고, 이것을 기록해 두어도 된다(즉, 이 기록 내용을 미처리의 건수로 한다).

또한, 요건 정보로서는, 처리 완료의 것을 소거하고, 미처리의 것을 요건 데이터베이스에 남기는 구성으로서, 남은 요건 정보의 건수를 카운트함으로써 실현하는 것이 가능하게 된다.

또한, 상기한 구성에서, 상기 처리 의뢰 및 상기 의뢰 정보 중 적어도 한쪽은, 일정 시간 후에 자신의 효력이 소멸(무효화, 타임아웃)하는 정보인 것도 본 발명에 포함된다. 또한, 상기 처리 의뢰 및 상기 의뢰 정보는, 전송 큐이어도 된다.

또한, 본 발명에서는, 소위 트랜잭션(복수의 거래 요구)을, 소정의 단위로 분할하여 각각 각 처리(처리를 위한 서브 업무 단위를 포함함)를 병행 처리로 실행하도록 구성한 것에 적용하는 것도 포함된다.

본 발명의 일 양태에 따르면, 서브 업무 단위를 포함하는 각 처리에서의 병행 처리가 가능하게 되고, 시스템의 확장성을 보다 높이는 것이 가능하게 된다. 또한, 본 발명의 별도의 양태에 따르면, 처리의 회복을 보다 용이하게 실현하는 것이 가능하게 된다.

본 발명의 실시 형태에 대해서, 도면을 이용하여 설명한다. 본 실시 형태는, 증권(주식)의 거래를 예로 설명하지만, 본 발명은 이것에 한정되는 것은 아니다.

우선, 도 6을 이용하여 본 실시 형태의 기본적인 내용에 대해서 설명한다. 도 6에 도시한 바와 같이 트랜잭션을, 서브 업무 단위로 분할하고, 이것을 도 6 하방에 도시한 바와 같이, 파이프라인 처리와 같은(의사적인) 병행 처리를 실현한다. 또한, 각 서브 업무에 관해서는, 도 6 상방에 도시된 것이, 그 일례이다.

다음으로, 도 12∼도 14를 이용하여, 본 실시 형태의 개요(사고 방식)에 대해서 설명한다. 본 실시 형태의 처리의 전제로서, 이하의 항목이 있다. 거래는 종목마다 순서성을 보증할 필요, 주문 접수나 접수/약정 통지는 단말기마다 관리할 필요. 이는, 도 12에 도시한 바와 같음. 상기 요건으로부터, 도 13과 같이 각 처리의 처리 단위로 하기로 하였다.

또한, 상기 사고 방식에서, 프로세스 대기가 발생하는 요인에 대해서는 이하가 있다고 생각하고 있다. 처리 단위가 상이한 처리 간(예:주문 접수∼거래 처리 제어 1 등). 다음으로, 도 13을 이용하여, 처리 단위가 상이한 처리 간에서의 대기의 사고 방식을 설명한다. 처리 단위가 상이한 처리로서, 예로서 주문 접수로부터 거래 처리 제어 1을 들어, 설명한다. 주문 접수 처리는 단말기 단위, 거래 처리 제어 1은 종목 단위의 처리일 필요가 있기 때문에, 이하의 처리 내용을 생각하였다.

주문 접수:복수의 프로세스가 동시에 동일 단말기로부터의 처리를 하는 경우가 없도록, 그 단말기가 주문 접수 중인지를 체크한다.

각 단말기 그룹마다의 프로세스 수(처리 다중도)를 설정 가능으로 한다.

거래 처리 제어 1:종목 그룹마다의 프로세스 수를 1로 하고, 종목 그룹마다 시리얼 처리를 행한다.

이 제어에 의해, 주문 접수는 단말기마다, 거래 처리 제어 1은 종목마다 순서성을 보증하고 있다.

도 13과 같이, 주문 접수와 거래 처리 제어 1은 각각 단말기, 종목과 처리 단위가 상이하다. 따라서, 이하의 경우에 대기가 발생하게 된다.

도 14에 도시한 바와 같이, 단말기 A와 단말기 B로부터, 동일 종목 C(종목 그룹 1)에 대하여 주문을 행한 경우를 생각한다. 거래 처리 제어 1은 종목마다 시리얼 처리할 필요가 있기 때문에, 예를 들면, 거래 처리 제어 1에 대하여, 단말기 A의 주문이 빨리 도착하고, 단말기 B의 주문이 나중에 도착한 경우, 단말기 A로부터의 주문의 거래 처리 제어 1이 종료할 때까지, 단말기 B로부터의 주문의 처리는 기다리게 된다. 이와 같이 거래 처리 제어 1의 MQ로부터의 취출 시에 대기가 발생한다.

상기 대기 시간은, 단말기로부터의 주문의 도착이 푸아송 분포에 따르는 것으로 하고, 거래 처리 제어 1의 처리 시간, 프로세스 이용률, 및 창구수(상기 예에서는 1)로부터, 대기 행렬 이론을 이용하여 산출한다. 리스판스 시간 산출 시에는 이 대기 시간을 고려하여, 평가하고 있다. 이 내용에 관해서는, 도 8∼도 11을 이 용하여 제2 실시 형태로서 설명한다.

다음으로, 본 실시 형태에서의 시스템 구성도를 도 1에 도시한다. 각 컴퓨터는, 네트워크를 통하여 상호 접속되어 있다. 또한, 각 컴퓨터는, 메모리, 하드디스크를 포함하는 기억 장치, CPU 등의 처리 장치를 갖고, 기억 장치에 저장된 프로그램에 따라서, 처리 장치가 정보 처리를 실행하는 것이다. 도 1에 도시한 바와 같이, 본 실시 형태에서의 시스템은, 거래 단말기(1), 접수 장치(2), 거래 처리 장치(3), 약정 처리 장치(4)와, 거래에 관한 정보가 저장된 기억 장치군(5)으로 구성된다. 이들 구성 요건의 각각은, 복수로 구성되는 것이지만, (1) 거래 단말기(1)는 그룹으로서 복수의 거래 단말기를 통합하여 두어도 되고, (2) 또한, 접수 장치(2), 거래 처리 장치(3), 약정 처리 장치(4)는, 하드웨어로서 일체의 서버 장치로서 구성되고, 각각은 그 기능을 갖는 소프트웨어로서 구성하여도 된다. 또한, (2)의 경우, 접수 장치(2), 거래 처리 장치(3)를 일체, 거래 처리 장치(3), 약정 처리 장치(4)를 일체 등으로 하여도 된다. 본 실시 형태에서는, 도 2에 도시한 바와 같이 약정 처리 장치(4)와 거래 처리 장치(3)를 일체로 한 예로 설명한다. 이 도 1, 도 2의 구성에서는, 각 접수 장치(2(21,22))는, 거래 단말기의 그룹마다(증권 회사 등) 대응지어져 있다. 또한, 각 거래 처리 장치(3), 각 약정 처리 장치(4)(혹은 이들이 일체화된 처리 장치(31, 32))는, 처리할 종목마다 대응지어져 있고, 이 대응 관계의 거래 요구에 관한 처리를 실행한다. 이 대응 관계는, 장치 즉 하드웨어가 아니라, 소프트웨어가 갖도록 하여도 된다. 또한, 이 대응 관계는, 거래량 등의 조건에 기초하여 동적으로 변경하여도 된다. 즉, 임의의 그룹으로부 터의 거래 요구나 임의의 종목의 거래 요구가(증가하여) 소정 수(양)로 된 경우, 소정의 장치(예를 들면, 거래 요구가 가장 적은 동일한 종류의 장치, 컴퓨터 자원)를 그 그룹(혹은 종목)의 처리를 실행하도록 하여도 된다. 또한, 동일한 종류의 장치에서, 거래 요구(혹은 그것에 수반하는 계산량)의 관계가 일정한 관계(차분이 임계값 이상이나 1:10 등의 소정의 관계)를 충족시키는지를 검지하여, 이 내용에 따라서 대응 관계를 변경하는(적은 거래 요구의 장치를 많은 거래 요구의 장치로 바꾸는) 것도, 본 실시 형태에 포함된다.

이하, 본 실시 형태의 처리 내용에 대해서, 설명한다.

우선, 도 3을 이용하여, 본 실시 형태의 기본 처리를 설명한다. 스텝 101에서, 접수 장치(21, 22)가 대응하는 거래 장치로부터 주문 접수 처리를 한다. 여기 서는, 거래 장치로부터 지정 종목, 매매별, 희망 금액, 주수, 요구자(거래 단말기(그룹))를 식별하는 정보를 포함하는 거래 요구를, 접수 장치(21)가 수신한다. 대응하는 거래 요구를 수신하기 위해서, 도시한 바와 같이 물리적으로 상호 대응하는 거래 단말기(그룹)를 접속하여도 되고, 거래 단말기로부터 대응하는 접수 장치를 특정하여, 특정된 접수 장치 앞으로, 거래 요구를 송신하도록 하여도 된다. 또한, 접수 장치측에서, 대응하는 거래 단말기(그룹)만을 수신하도록 필터링 처리를 실시하여도 된다.

그리고, 동일한 스텝 101에서, 입력 전문 즉 거래 요구의 체크를 행한다. 이 체크는, 통신 경로 상에서의 장애 발생 상황에 의해, 정상적으로 수신할 수 있었는지를 판단하는 것이다.

또한, 접수 장치(2)는, 스텝 101에서, 이하의 처리를 행하는 것도 본 실시 형태에 포함된다. 우선, 전제로서 거래 요구에 포함되는 요구자를 식별하는 정보는, 거래 단말기를 특정하는 정보이다. 여기서, 접수 장치(2)는, 이 정보를 키에 대응하는 단말기 그룹을 특정하는 정보를 단말기-단말기 그룹 특정 테이블로부터 검색한다. 그리고, 검색된 정보를 거래 요구에 포함시켜, 그 후의 처리를 실행한다. 또한, 각 거래 장치 중 어느 하나에서, 지정 종목을 키로, 도 7에 도시한 종목-종목 그룹 특정 테이블로부터 종목 그룹을 특정하는 정보를 검색하고, 거래 요구에 검색된 정보를 포함시키는 것도 본 실시 형태에 포함된다. 또한, 이와 같이 하여 새롭게 추가된 정보는, 각 처리 등에서 그룹(혹은 종목, 단말기)을 특정할 때에 사용된다.

그리고, 스텝 102로 진행하고, 접수 장치의 각각은 스텝 101의 체크 결과를, 거래 요구를 송신한 거래 단말기에 송신한다. 정상적으로 수신할 수 있었다고 판단한 경우에는, 정상 접수 응답을 거래 단말기에 송신한다. 그리고, 수신한 거래 요구를 요건 DB(51)에 저장한다. 이 경우, 각 거래 요구에 거래 상황을 대응지어서 기억해 둔다. 여기서, 「접수」를 나타내는 정보를 기억해 둔다. 또한, 거래 요구에 포함되는 「거래 종목」마다 대응하는 요건 DB에 저장하여도 된다. 예를 들면, 「a」 종목의 거래 요구는 요건 DB(51-a)에 저장된다. 또한, 요건 DB는, 기억 장치군(51)에 저장되어 있다. 또한, 각 요건 DB(51(51-a, 51-b))는 물리적으로 동일한 매체에 저장하여도 된다.

다음으로, 스텝 103에서, 거래 장치(31, 32)의 각각은(거래 처리 프로그램을 이용하여), 요건 DB(51)로부터 거래 상황이 「접수」이고, 자신에 대응하는 「종목」의 거래 요구를 추출한다. 이 추출은, 접수 장치측이, 요건 DB(51)에의 등록에 더불어서(포함하는 동일 종목이 일정 수 이상 등록한 경우), 「거래 종목」마다 대응하는 처리 장치(31, 32)에 전송 큐 송신함으로써 실현하여도 된다. 또한, 처리 장치(31, 32)가 일정 시간마다를 포함하는 소정 타이밍으로 자신에 대응하는 요건 DB(51)에 대하여 「접수」의 거래 요구가 없는지 검색하여 행해도 되고, 접수 장치로부터 등록한 것을 나타내는 정보를 수신하는 것을 트리거로 요건 DB를 검색하여도 된다. 또한, 이 트리거는, 동일 「종목」의 거래 요구가 일정 수 이상으로 된 것을 검지하여, 실행하여도 된다. 또한, 요건 DB에의 등록은 「종목」마다의 요건 DB에 등록하여도 된다(이하 마찬가지).

그리고, 추출한 거래 요구를 소위 판에 올리는, 처리를 실행한다. 즉, 거래 가능한 상태로 천이시킨다. 이 처리의 상세에 대해서는, 도 4, 도 5를 이용하여 후술한다. 이 처리를 실행한 경우, 요건 DB 거래 상황을 「접수」로부터 「거래」로 변경하도록 등록한다.

다음으로, 스텝 104에서, 거래 장치(31, 32)의 각각은, 거래 요구를 식별하는 주문 접수 번호를 부가하여, 요건 DB에 저장한다. 그리고, 이 등록 혹은 시간, 등록의 수 등을 트리거로, 각 접수 장치는, 요건 DB로부터 자신에 대응하는 「거래 단말기(그룹)」로서 「거래」의 거래 요구에 대해서, 그 거래 요구를 송신한 거래 단말기에 이 주문 접수 번호를 통지한다.

다음으로, 스텝 105에서, 거래 장치(31, 32)의 각각은, (약정 처리 프로그램 을 이용하여), 요건 DB(51)로부터 거래 상황이 「거래」이고, 자신에 대응하는 「종목」의 거래 요구를 추출한다. 이 추출은, 스텝 103과 마찬가지의 처리에 의해 실행하여도 된다. 그리고, 추출한 거래 요구에 대해서, 「약정 처리」를 실행한다. 즉, 추출한 거래 요구에 대응하는(매매가 반대인 것을 나타내고, 가격, 주수가 대응하는) 거래 요구가 없는지를 검출한다. 이 처리는, 통상 행해지고 있는 것이므로, 그 상세한 설명은 생략한다.

다음으로, 스텝 106으로 진행하여, 스텝 105에서의 약정 처리에서 약정이 성립하는지(대응하는 거래 요구를 검출할 수 있었는지)를, 거래 처리 장치(31, 32)의 각각은, (약정 처리 프로그램을 이용하여) 실행한다. 그 결과를, 대응하는 거래 요구에 관련 지어서 요건 DB에 저장한다. 그리고, 약정이 성립한 경우에는, 스텝 107로 진행하고, 약정이 성립하지 않은 경우에는, 스텝 108로 진행한다. 또한, 스텝 106에서, 약정이 성립한 경우에는, 요건 DB의 「거래」를 「약정」으로 변경한다. 또한, 약정이 성립하지 않은 경우에는, 「거래」를 「미약정」으로 변경한다.

다음으로, 스텝 107에서는, 이 등록 혹은 시간, 등록의 수 등을 트리거로, 각 접수 장치는, 요건 DB로부터 자신에 대응하는 「거래 단말기(그룹)」로서 「약정」의 거래 요구에 대해서, 그 거래 요구를 송신한 거래 단말기에 약정을 특정하는 약정 번호를 포함하는 약정 통지를 송신한다. 그리고, 스텝107로 진행한다.

다음으로, 스텝 108에서는, 거래 장치(31, 32)의 각각은 (거래 처리 프로그램을 이용하여), 도시하지 않은 시세 시스템 등에 송신하는 외부 출력 정보를 작성하여 송신한다. 여기서는, 전술한 바와 같이, 자신에 대응하는 「종목」의 거래 요구로서 「약정」 혹은 「미약정」인 것을 추출하여, 이들에 대해서 이 처리를 실행한다.

다음으로, 도 4 및 도 5를 이용하여, 스텝 101∼103(특히 103)의 상세에 대해서 설명한다. 우선, 도 4를 이용하여, 정상적으로 처리할 수 있었던 경우의 예를 설명한다.

우선, 스텝 101과 102의 상세에 대해서 설명한다. 또한, 스텝 101, 102(즉 하기의 상세 처리)는, 「그룹」 단위로 실행하는 것이다. 이는, 앞에 기술한 바와 같다.

스텝 1011에서는, 송신된 거래 요구를 수신하고, 스텝 1012에서는 앞에 설명한 바와 같이, 입력 전문 즉 거래 요구의 체크를 행한다. 이 체크는, 통신 경로 상에서의 장애 발생 상황에 의해, 정상적으로 수신할 수 있었는지를 판단하는 것이다. 정상이 아니라고 판정된 경우에는 스텝 1021로 진행하고, 정상이라고 판정된 경우에는 스텝 1022로 진행한다.

스텝 1021에서는, 송신한 거래 단말기에 에러(정상적으로 수신할 수 없었다는 취지)의 통지를 행한다. 그리고, 스텝 1022에서는, 수신한 거래 요구, 「종목」 마다 설치된 요건 DB에 대하여, 등록을 행한다. 즉, 수신한 거래 요구의 「종목」에 대응하는 요건 DB에 등록한다. 이 때, 「접수」를 「거래」로 변경하여 등록한다.

다음으로, 스텝 1023에서는, 수신이 정상으로 행해진 것을, 거래 단말기에 송신한다. 그리고, 스텝 1024에서, 전송 큐(MQ)를 발생시켜, 거래 장치(31) 등에 서의 처리 트리거로 한다. 여기서는, 「종목」마다 발생하도록 하여도 된다. 이 전송 큐의 발생(혹은 처리 장치에 통지)은 전술한 바와 같고, 일정 시간마다를 포함하는 소정 타이밍, 접수 장치에서의 요건 DB에의 등록(포함하는 동일 「종목」의 거래 요구가 일정수 이상)으로 된 것을 검지하여, 실행하여도 된다.

다음으로, 스텝 103의 상세에 대해서 설명한다. 또한, 스텝 103(즉 하기의 상세 처리)은, 「종목」 단위로 실행하는 것이다. 이는, 전술한 바와 같다. 스텝 1031에서, 자신에 대응하는 「종목」의 거래 정보를 요건 DB로부터 추출한다. 그리고, 스텝 1032에서, 추출된 거래 요구의 각 항목에 누락이 없는지, 수량에 대해서 발행수와 대응이 취해져 있지 않은지 등의 확인 처리를 실행한다.

그리고, 스텝 1033에서, 에러인(즉 올바르지 않다고 판단된) 경우, 스텝 1034로 진행하여 에러 처리를 행한다. 즉, 거래 단말기에 에러의 취지의 통지를 실행한다.

또한, 정상이라고 판정된 경우, 스텝 1035로 진행한다. 그리고, 스텝 1035에서, 「판 등록 처리」를 행한다. 판 등록 처리의 양태로서는, 요건 DB에서, 거래 가능하다는 플래그를 세우는 것이 포함된다. 또한, 주문 접수·판 DB에 등록하는 것도 본 실시 형태의 일 양태에 포함된다. 또한, 이들의 조합이어도 된다.

다음으로, 스텝 1036에서, 판 등록 처리를 실행한 것을, 대응하는 「종목」의 요건 DB에 등록한다. 그리고, 스텝 1037로 진행하여 거래 단말기에 대하여 주문이 정상으로 접수된 취지의 통지를 실행한다. 그리고, 스텝 1039에서, 스텝 1024와 마찬가지로, 전송 큐(MQ)를 발생시켜, 거래 장치(31) 등에서의 처리 트리거 로 한다. 여기서는, 「종목」마다 발생하도록 하여도 된다. 이 전송 큐의 발생(혹은 처리 장치에 통지)은 전술한 바와 같이, 일정 시간마다를 포함하는 소정 타이밍, 접수 장치로의 요건 DB에의 등록(포함하는 동일 「종목」의 거래 요구가 일정 수 이상)으로 된 것을 검지하여, 실행하여도 된다.

다음으로, 도 5를 이용하여, 이상 종료한 경우의 처리에 대해서 설명한다(스텝 103의 도중에 이상 종료한 경우). 기본적으로는, 도 4와 마찬가지의 처리를 실행한다. 이상 종료를 검지한 경우, 그 처리 요구를 재실행한다. 구체적으로는, 이상 종료한 거래 요구와 동일한 데이터를 요건 DB로부터 판독함으로써 실현한다.

또한, 요건 DB는 전술한 바와 같이, 종목마다, 그룹마다 등 복수 종류 준비하여도 된다. 이 경우, 처리 상황이 변하는 것(임의의 요건 DB의 「접수」로부터 「거래」에 등)을 트리거로, 서로의 정보의 정합이 얻어지도록, 다른 요건 DB의 거래 상황을 변경하도록 제어한다.

또한, 데이터베이스군으로서는, 도 4, 도 5에서의 각 처리의 제휴를 행하기 위한 데이터베이스를 설치하여도 된다. 요건 DB나 이들에는, 이하의 것이 포함된다.

요건 DB:기반 APP의 트랜잭션 제휴용으로 데이터를 저장하는 데이터베이스

요건 DB(접수→거래):「접수 처리→거래 처리」 사이에서의 데이터 제휴용 DB

요건 DB(거래→약정):「거래 처리→약정 처리」 사이에서의 데이터 제휴용 DB

요건 DB(약정→거래):「약정 처리→거래 처리」 사이에서의 데이터 제휴용 DB

요건 DB(거래→접수):「거래 처리→접수 처리」 사이에서의 데이터 제휴용 DB

업무 DB:업무에서 필요로 되는 데이터베이스.

주문 접수·판 DB:거래 처리 장치의 결과를 저장

주문 이력 DB:약정 처리 장치의 결과를 저장

또한, 이상의 본 발명의 실시 형태에 의해, 파이프라인 처리와 같은(의사적인) 병행 처리에 의해 스루풋 향상하는 것도 가능하게 된다.

또한, 이상과 같은 실시 형태(그루핑화에 의한 분산 처리)를 원용함으로써, 각 처리 장치(거래 처리 장치(3), 약정 처리 장치(4))를 증설하는 수직 확장에 의해, 거래(연산)량의 증대에도 대응이 가능하게 된다. 또한, 접수 장치(2)는 처리 장치(CPU)의 추가(증강)에 의한 수평 확장에 의해, 거래(연산)량의 증대에도 대응이 가능하게 된다. 또한, 본 발명에서는, 이와 같은 확장에 한정되지 않고, 예를 들면, 각 거래 장치를 소위 수직 확장으로 하고, 접수 장치를 수평 확장으로 하여도 된다. 또한, 각각 모두 수직 확장, 수평 확장으로 하여도 된다.

다음으로, 본 발명의 제2 실시 형태에 대해서, 도 8∼도 11을 이용하여 설명한다.

본 제2 실시 형태에서는, 상기한 실시 형태에서의 분산 처리를 행한 경우의 리스판스 시간의 산출을 행한다. 즉, 상기한 실시 형태와 같이, 분산 처리를 행한 경우, 각 거래 요구에 관한 리스판스 시간은 곧 바로는 알 수 없다. 이는, 도 10, 도 11에 도시한 바와 같이, 각 서브 업무 처리가 1개의 장치로 실시하는 것은 아니기 때문에, 시간의 산출이 어려워지기 때문이다. 또한, 리스판스 시간이란, 도 8에 도시한 바와 같이 주문 접수로부터 수신 통지나 약정 통지까지의 시간을 가리킨다.

따라서, 본 실시 형태에서는, 복수의 처리 장치에서, 분산 실행하고 있는 서브 업무를 1개의 주문 수신 통지 업무로서 서로 연결하고, 업무 리스판스 정보로서 작성하도록 제어하는 것이다. 즉, 각 서브 업무 중, 최초의 서브 업무의 개시 시간과 최후의 서브 업무의 종료 시간을 기록하고, 이것의 차분을 리스판스 시간으로서 산출한다. 또한, 시간의 기록 시에는, 거래를 식별하는 정보(접수 NO)를 대응지어서 기록해 둔다.

또한, 도 8에 도시한 바와 같이, 각 서브 업무의 개시 시간과, 최후의 서브 업무에서는 종료 시간을 기록하여 구성하여도 된다. 이 경우, 필요한 서브 업무를 지정에 기초하여 추출하여, 서브 업무(포함하는 복수의 서브 업무로 이루어지는 것)의 리스판스 시간을 산출하는 것이 가능하게 된다. 보다 구체적으로는, 이하의 처리를 실행한다. 주문 접수의 서브 업무 개시 시각과 접수 번호를, DB에 등록한다. 이후의 처리에서도, 서브 업무 개시 시각과 접수 번호를 DB에 등록한다. 1개의 주문 수신 통지 업무의 최후에 해당하는 서브 업무 「수신 통지 처리」에서는, 서브 업무 개시 시각과 접수 번호 외에, 거래 단말기로의 응답 후인 서브 업무 종료 시각을 DB에 등록한다. 1개의 주문 수신 통지 업무에 대응한 접수 번호를 키로 하여, 선두의 서브 업무 「주문 접수」의 개시 시각과, 최후의 서브 업무 「수신 통지 처리」의 종료 시각의 차분으로부터, 주문 수신 통지 업무의 리스판스를 산출한다.

본 발명의 제3 실시 형태에 대해서, 도면을 이용하여 설명한다. 본 실시 형태는, 증권(주식)의 거래를 예로 설명하지만, 본 발명은 이것에 한정되는 것은 아니다(타 업무 등에 적용하는 것도 본 발명에 포함됨).

우선, 본 실시 형태의 기본적인 내용에 대해서 설명한다.

(1) 통상은, 연락원 프로세스(예를 들면, 도 1이나 도 2의 접수 장치(2))로부터 연락처 프로세스(예를 들면, 도 1, 도 2의 거래 처리 장치(3))도에 대하여, 처리 의뢰(예:MQ 「전송 큐」)를 송신한다. 여기서는, 보낼 곳을 장치 즉 하드웨어로 하였지만, 본 실시 형태에서는, 하드는 상이한 경우도 있고 동일한 경우도 포함한다. 어디까지나, 임의의 프로세스(처리 프로그램)로부터, 처리 의뢰처의 프로세스에, 요건 데이터베이스의 등록과 처리 의뢰(MQ)를 송신할 수 있으면 된다. 예를 들면, 「주문 접수」라고 하는 프로세스는 단말기 그룹수분 있고, 「거래 처리 제어 1」이라고 하는 프로세스는 종목 그룹수분 동작하고 있다. 「거래 처리 제어 1」은 복수의 종목 키의 집합인 「종목 그룹」으로 묶고 있다. 「거래 처리 제어 1」이라고 하는 기능 명칭과, 종목 그룹의 조합으로 1개의 프로세스가 특정된다. 서버와 그룹이 1대1이어도 되고, 서버에 복수의 그룹이 배치되어 있어도 된다.

(2) 연락처 프로세스에서는, MQ를 수신하면, 그 MQ에 대응하는 요건 DB로부터 요건 정보(레코드)를 1건 취득(SELECT)한다. 여기서, 이 취득의 방법으로서는, (a) 자신의 「그룹」(혹은 자신)을 식별하는 식별자(예를 들면, 그룹 코드)를 이용하여 행하고(MQ와 요건 정보에는, 각각 그룹 코드를 포함시키도록 하고), (b) 거래 대상의 종목를 식별하는 식별자를 이용하여 행한다(MQ와 요건 정보에는, 각각 종목을 식별하는 식별자를 포함시키도록 한다). 또한, 요건 정보에는, 연락원 프로세스가 처리 의뢰를 발행(혹은 송신 등 소정의 처리이고, 요건 정보에 대한 처리이어도 된다)을 실행한 시간의 시간 정보를, 타임 스탬프 기능을 이용하여 포함시켜 둔다. 그리고, 이 시간 정보의 순에 따라서, 취득하는 순서를 결정한다. 예를 들면, 오래된 순으로 취득하도록 한다.

여기서, MQ가 무효(타임아웃)로 되는 등 하여 무효화한 경우(혹은 무효화를 검출한 경우), 연락처 프로세스에서는, 요건 데이터베이스를 검색하여, 미처리의 안건(예를 들면, 요건 정보)이 없는지를 검지한다. 이 검지는, 상기 (2)에 기재한 방법과 마찬가지로 검색 등을 행한다. 보다 상세하게는, 이하와 같다. 요건 데이터베이스와 처리 의뢰(MQ) 쌍방에, 처리 의뢰처의 「그룹 코드」 및 「큐」를 부여하고 있다. 연락처 프로세스는, MQGET에서 메시지(MQ)를 취득하면, 자 프로세스용의 메시지인 것을 체크하고 나서 「그룹 코드」 또는 「키」가 동일, 또한 미처리인 것을 검색 조건으로 하여, 등록 시각이 가장 오래된 요건 레코드를 요건 데이터베이스로부터 검색한다.

또한, MQ는 요건 데이터베이스를 검색하기 위한 트리거이다. 즉, MQ에는 「무엇을 행할 것인가」라고 하는 정보가 나타나 있지 않아도 된다. 「무엇을 행할 것인가」는, 요건 데이터베이스(의 요건 정보)에 등록되어 있다. 요건 데이터베이 스에는, 「무엇을 행할 것인가」로서 예를 들면 대응하는 주문 데이터(주문 수신 데이터베이스 등에 기록) 등을 특정하는 정보가 설정되어 있기 때문에, 요건 데이터베이스를 취득하는 순서로 주문 수신 데이터베이스의 처리를 행하는 것이 가능하게 된다(예;거래처에서 필요한 동일 종목 내에서의 주문의 처리 순서성을 확보하고 있다).

(3) 다음으로, 연락처 프로세스에서는, 취득한 요건 정보에 대응하는 처리를 실행하는 프로그램을 기동하고, 처리를 실행한다. 그리고, 다음 프로세스(예를 들면, 약정 처리 장치)에의 통지를 행한다.

본 실시 형태에서의 시스템 구성은, 도 1, 도 2와 마찬가지이다. 또한, 본 실시 형태에 대해서, 분산화 처리와 조합함으로써 이하의 효과를 달성하는 것이 가능하게 된다.

(1) 업무 요건인 「처리 순서성 보증」을 하는 것이 가능하게 된다. 「단말기 그룹:n→종목 그룹:m→단말기 그룹:n」과 같은 흐름으로, 서브 업무를 분할하고 있기 때문에, 처리 순서성 확보가 문제로 되지만, 요건 DB 내의 가장 오래된 미처리의 것부터 차례로 처리하기 때문에, 처리 순서성 보증(종목 그룹 단위)이 가능하게 된다(종목 그룹 1의 요건 DB에 대하여, n개의 단말기 그룹으로부터 처리 요구가 발생한다).

(2) 장애 복구 대상 리소스를 DBMS만으로 하는 것이 가능하게 된다. 트랜잭션과, DBMS의 양방에서, 회복 대상 리소스를 갖는 XA 제휴(2상 코미트)에서는, Commit 처리 성능이 길어지기 때문에, 회복 대상 리소스를 DBMS만으로 하고, 비XA 제휴로 하여 commit 성능을 확보하는 것이 가능하게 된다. 또한, 본 발명은, XA 제휴한 경우라도 적용 가능한 것은 물론이다.

(3) 회복 시의 순서성 확보가 가능하게 된다. (1)의 기능(요건 데이터베이스 내의 가장 오래된 미처리의 것부터 차례로 처리한다)에 의해, 장애 회복 후에도, 순서성을 확보하는 것이 가능하게 된다.

또한, 서브 업무 단위로 분산화하지 않은 것도 본 발명에 포함된다.

다음으로, 도 15를 이용하여 본 실시 형태의 처리 플로우에 대해서, 설명한다. 우선, 초기 처리로서, 스텝 200에서, 프로세스를 기동한다. 이하의 스텝도 포함하며 여기서는, 거래 처리 장치(3)에서의 처리를 예로 설명한다. 예를 들면, 본 장치에서 이용하는 프로그램을 기동시킨다.

다음으로, 스텝 201에서, MQGET, 즉, 처리 의뢰를 취득한다. MQ는, 접수 장치(2)로부터 송신된 것으로, 소정의 기억 장치에 저장되어 있다. 그리고, MQ 기억 장치에 존재하지 않는 경우에는, MQGET의 동작이 타임아웃으로 된다. 여기서, MQ는 미리 정한 시간으로 되면 타임아웃이라고 칭하여 무효화하도록 제어하여도 된다. 이 미리 정한 시간으로서는, 프로세스의 기동 시에는, 그 이외의 경우와 비교하여 짧은 시간으로 타임아웃으로 되도록 설정하여도 된다. 이와 같이 설정함으로써, 계 전환 등에 의해 저장되어 있는 MQ가 소멸하는 것을 방지하는 것이 가능하게 된다. 또한, 기동 시란, 기동하고 나서 최초로 기억 장치에 액세스하는 것을 포함한다.

다음으로, 스텝 202에서, MQGET(혹은 MQ)가 타임아웃으로 되었는지를 검지한 다. 타임아웃으로 된 경우(검지한 경우)는, 스텝 103으로 진행하고, 자신에 대한 MQ 송신을 행한다. 또한, 여기서, MQ는, 요건 데이터베이스를 검색하기 위한 트리거이면 되고, 「무엇을 행할 것인가」라고 하는 정보가 나타나 있지 않아도 된다. 「무엇을 행할 것인가」는, 요건 데이터베이스(의 요건 정보)에 등록되어 있다. 요건 데이터베이스에는 「무엇을 행할 것인가」로서 예를 들면 대응하는 주문 데이터(주문 수신 데이터베이스 등에 기록) 등을 특정하는 정보가 설정되어 있다. 이와 같이, 트리거로 되는 것(또한 소정의 조건으로 무효화되는 것이라면 더 바람직하다)이면 되고, MQ 이외의 것이어도 상관없다.

여기서, 스텝 203의 상세에 대해서, 도 16을 이용하여 설명한다.

우선, 스텝 2031에서, 도 17에 도시한 요건 데이터베이스로부터 미처리의 안건(즉 요건 정보)의 수를 계수한다. 즉, 각 요건 정보 중, 처리 완료 플래그가 미처리를 나타내는 것을 추출하고, 그 중 그 거래 처리 장치가 처리할 것을 나타내는 정보(그 거래 처리 장치의 식별 정보이어도 됨)의 요건 정보의 수를 계수한다. 또한, 우선, 상기 거래 처리 장치가 처리할 것을 나타내는 정보(그 거래 처리 장치의 식별 정보이어도 됨)의 요건 정보를 추출하고, 그 중으로부터 처리 완료 플래그가 미처리를 나타내는 것을 검지하여도 된다.

다음으로 스텝 2032에서, 스텝 2031에서 미처리의 안건이 있는지의 여부를 판단한다. 그 결과, 없는 경우에는 그대로 스텝 215로 진행하고, 본 스텝 203을 종료한다. 있는 경우에는, 스텝 2033으로 진행한다.

스텝 2033에서, 자신에게 송신하는 즉 재송의 MQ를 편집(생성)한다. 전술한 바와 같이, MQ는 트리거로 되면 되기 때문에, 자신(거래 처리 장치)인 것을 식별하는 정보가 포함되면 된다. 단, 보다 바람직하게는, MQ에는 상기 거래 처리 장치가 속하는 그룹(혹은 거래 처리 장치 자신)을 식별하는 그룹 코드 혹은 대응하는 요건 정보의 등록 등의 처리 시간 등의 키 정보를 포함시켜도 된다. 또한, 여기서는, 스텝 2031에서 계수된 미처리의 건수 이하의 수의 MQ를 생성한다. 보다 바람직하게는, 미처리의 건수 미만으로 하면 된다. 이는, 이 재송 MQ에 의해 트랜잭션의 증가나 큐 넘침을 방지하기 위한 것으로, 그 수는 이들을 고려하여 적당하게 정해도 된다.

그리고, 스텝 2034로 진행하고, 재송 MQ를 자 프로세스(거래 처리 장치)를 향하여 송신한다. 그리고, 본 처리를 종료하고(스텝 2035), 스텝 115로 진행한다.

다음으로, 스텝 215로 진행하고, 본 트랜잭션에 결착이 지어진 것으로 되고, 스텝 204로 진행한다. 스텝 204에서, 스텝 201과 마찬가지로, 처리 의뢰를 취득한다. 그리고, 스텝 205에서는, 스텝 202와 마찬가지로 타임아웃하였는지의 여부를 검지한다. 여기서의 타임아웃 값은, 스텝 202에서의 그것과 비교하여 길게 하여도 된다. 그 결과, 타임아웃으로 된 경우에는, 스텝 206으로 진행하여 스텝 203과 마찬가지의 처리를 실행한다.

다음으로, 스텝 202나 스텝 205에서, 타임아웃이 없다고 판단된 경우에 대해서, 설명한다. 이와 같이 판단된 경우, 스텝 207로 진행한다. 스텝 207에서는, 스텝 203이나 206에서 재송된 MQ를 포함하여 자신에게 송신된 MQ를 기억 장치로부터 취득한다. 여기서, 취득된 MQ를 저장하고 있던 기억 장치로부터 삭제한다.

다음으로, 스텝 208에서, MQ의 취득에 대응하여, 요건 데이터베이스(요건 DB)로부터 1건의 요건 정보를 취득한다. 여기서, 1건의 요건 정보의 취득의 방법은, MQ에 포함되는 키 정보와, 도 17에 도시한 요건 데이터베이스의 내용(키 정보, 시간 정보(도시 생략))을 이용하여 행한다. 즉, 요건 정보에 포함되는 요건 정보 중, 처리 완료 플래그가 미처리이고, 상기 거래 처리 장치에서 등록이 가장 오래된 요건 정보를 선택한다(키 정보나 UAP 정보에 이들 정보를 포함시켜서 구성하는 것이 가능하다). 이와 같이 하여, 요건 정보를 선택할 수 없는 경우에는 스텝 215로 진행하고, 선택한 경우에는 스텝 210으로 진행한다.

다음으로, 스텝 210에서, 선택된 요건 정보에 대응하는 거래 처리를, 그 요건 정보를 이용하여 어플리케이션 프로그램에 따라서 실행한다.

이 스텝 210의 종료 후 혹은 스텝 210과 병행하여, 스텝 211∼스텝 214의 처리를 실행한다. 스텝 211에서, 스텝 200 이후의 재송 MQ의 수를 계수한다. 이는, MQ 내에 건수를 포함시키고, 그것을 카운트함으로써 실현한다. 또한, 발행할 때마다 카운트하고, 기록함으로써 행하여도 실현 가능하다. 그 결과, 재송 MQ가 0건인 경우, 스텝 215로 진행한다. 0건이 아닌 경우에는, 스텝 212로 진행한다.

스텝 212에서는, 재송 MQ의 건수가 저장된 기억 장치로부터 재송 건수를 1 감산하도록 연산한다. 그리고, 일정 시간을 경과했는지를 검지하여(스텝 213), 그 결과 한 경우에는 스텝 214로 진행하고, 스텝 203 등와 마찬가지로 재송 처리를 실행한다. 또한, 스텝 213에서 일정 시간을 경과했다고 검지하지 않은 경우에는, 스텝 215로 진행한다. 여기서, 일정 시간이 경과했는지의 여부의 확인은, 일부 장치 의 장애나 큐 넘침에 대응하기 때문에 감시를 행하기 위해서 실행한다. 여기서는, 재송 건수를 기억 장치에 저장하도록 하였지만, 이하와 같이 구성하여도 된다. 메모리 등에의 일시적인 저장은 하지만, 재송하는 MQ에 재송 건수를 포함시킨다. 즉, 스텝 212에서는, 스텝 211에서 계수한 재송 건수로부터 1 감산한 재송 건수를 포함하는 MQ를 재송한다.

이상의 제3 실시 형태의 처리에 따르면, 도 18 및 이하에 기재되는 효과를 달성하는 것이 가능하게 된다. 요건 DB를 등록할 수만 있으면, 요건 등록 순으로의 업무 처리 속행이 가능하다. 또한, MQ 재송 처리에 의해 대폭적인 지연 없이 처리가 가능하게 된다. 특히, 이하와 같은 경우에 대응이 가능하게 된다. (1) 일부의 참가자(증권 회사 등)로부터의 다량 주문 입력 등에 의해, 처리 의뢰처 서버의 MQ의 큐 넘침이 발생한 케이스, (2) 특정의 종목에 주문이 집중하는 등에 의해, 처리 의뢰처의 MQ의 큐 넘침이 발생한 케이스, (3) 처리 의뢰처 서버의 다운 등에 의해, MQ가 소실한 케이스, (4) 처리 의뢰처 프로세스의 다운 등에 의해 MQ가 삭제되지 않고, 결과적으로 MQ의 큐 넘침이 발생한 케이스.

본 제3 실시 형태와 같이, MQ를 트리거로서 취급함으로써, 데이터베이스에 축적된 주문을 시간 우선순의 원칙에 따라서 처리하는 리스판스의 고속화와 단위 시간 처리 건수의 향상이 가능하게 된다.

그리고, 본 제3 실시 형태에 따른 회복 처리에서는, 특정 종목에의 주문 집중 등에 의해, MQ가 부분적으로 소실한 경우라도, 극력 지체 없이 주문의 처리를 행하는 것이 가능하게 된다. 또한, 본 제3 실시 형태에서는, MQ(장애 시에 회복 대상으로 되지 않음)를 포함하는(영속 MQ가 혼재하여도 상관없는) 경우에 유효하다. 예를 들면 주문 접수 프로세스는 복수의 통신 서버에 배치된다. 이 경우, 임의의 서버에서 MQ의 전송 지연이나, 전송 도중에의 장애가 발생했을 때, 해당하는 주문의 발주원 거래 참가자는, 다른 거래 참가자보다 뒤지는 형태로 되거나, 종목의 거래 상태가 변화함으로써 불리함을 입거나 할 우려가 있는 것을 해소할 수 있다.

도 1은 본 발명의 일 실시 형태에서의 시스템 구성도(1).

도 2는 본 발명의 일 실시 형태에서의 시스템 구성도(2).

도 3은 본 발명의 일 실시 형태에서의 처리의 내용을 나타내는 플로우차트.

도 4는 도 3에서의 스텝 101∼103의 상세 처리를 나타내는 플로우차트(정상).

도 5는 도 3에서의 스텝 101∼103의 상세 처리를 나타내는 플로우차트(이상 종료).

도 6은 본 실시 형태의 기본적인 처리 내용을 설명하기 위한 도면.

도 7은 본 발명의 일 실시 형태의 종목-종목 그룹의 대응 관계를 기록한 테이블을 도시하는 도면.

도 8은 리스판스 정보의 개념을 도시하는 도면.

도 9는 리스판스 정보의 시간 이미지를 도시하는 도면.

도 10은 단말기별의 리스판스 정보 대상 처리를 도시하는 도면.

도 11은 종목별의 리스판스 정보 대상 처리를 도시하는 도면.

도 12는 본 발명의 일 실시 형태에서의 대기의 사고 방식을 도시하는 도면(그 1).

도 13은 실시 형태에서의 대기의 사고 방식을 도시하는 도면(그 2).

도 14는 본 발명의 일 실시 형태에서의 대기의 사고 방식을 도시하는 도면(그 3).

도 15는 본 발명의 일 실시 형태에서의 처리의 내용을 나타내는 플로우차트.

도 16은 도 15에서, 재송 처리의 상세 내용을 설명하는 플로우차트.

도 17은 요건 데이터베이스를 도시하는 도면.

도 18은 본 실시 형태의 효과 및 처리 개요를 설명하는 도면.

<도면의 주요 부분에 대한 부호의 설명>

1:거래 단말기

2:접수 장치

3:거래 처리 장치

4:약정 처리 장치

5:기억 장치군

6:유저 단말기

Claims (1)

1. 증권 거래의 주문을 발행하는 복수의 거래 단말기와 접속되어, 상기 주문의 거래를 실행하는 증권 거래 시스템으로서,

   상기 주문의 접수 처리를 행하고, 접수 처리가 종료된 주문을 요건 데이터베이스에 등록하고, 주문 접수가 종료된 것을 상기 거래 단말기에 송신하는 복수의 접수 수단으로서, 각각이 처리할 주문 처리가 상기 거래 단말기에 기초하여 정해지는 접수 수단과,

   각각이 처리할 종목이 미리 결정된 복수의 등록 처리 수단으로서, 접수 처리가 종료된 주문 중 자(自) 수단에서 처리할 종목의 주문을 상기 요건 데이터베이스로부터 판독하여 거래 가능한 상태로서 상기 요건 데이터베이스에 등록하는 등록 처리 수단과,

   상기 요건 데이터베이스로부터 등록이 완료된 주문을 판독하여, 등록이 완료된 것을 상기 거래 단말기에 통지하는 복수의 등록 통지 수단으로서, 각각이 통지할 주문이 상기 거래 단말기에 기초하여 정해지는 등록 통지 수단과,

   상기 요건 데이터베이스에 거래 가능한 상태로서 등록된 주문에서 거래가 성립하는 주문이 있으면 성립 처리를 행하고, 성립 완료 주문으로서 상기 요건 데이터베이스에 등록하는 약정 처리 수단으로서, 각각이 처리할 종목이 미리 결정된 복수의 약정 처리 수단과,

   약정된 것을 상기 거래 단말기에 통지하는 복수의 약정 통지 수단으로서, 각 각이 통지할 주문이 상기 거래 단말기에 기초하여 정해지는 약정 통지 수단

   을 포함하고,

   상기 복수의 종목 등록 처리 수단 및 복수의 상기 약정 처리 수단 중 하나의 등록 처리 수단 및 약정 처리 수단이 처리할 종목은 중복이 없도록 설정되는 것을 특징으로 하는 증권 거래 시스템.

Images