JP5018729B2 - 取引システム - Google Patents

Description

本発明は、株式等の有価証券を含む商品の取引を実現するための技術に関する。その中でも特に、いわゆる証券市場と称される取引所で用いられる証券取引システム、その方法およびそのためのプログラムに関する。

従来、証券取引を含む取引においては、注文情報を受信し、注文情報同士を比較して取引条件が満たすか否かにより取引を成立させていた(特許文献１)。より具体的には、入力装置３２から入力された証券売買の注文情報，取引情報は、制御装置３３を介して、取引記憶装置３４、約定記憶装置３６に記憶される。注文情報，取引情報は注文情報送信部３５を通じて各顧客１０，２０に送信され、表示装置１２に表示される。取引が成立した場合には、取引成立情報送信部３７を介して、取引成立情報が送信され、表示装置１２に表示され、スピーカ１３から警告音が発せられる。取引内容が確認された場合は、注文情報、取引成立情報が削除され、約定記憶装置３６に顧客識別情報、注文情報、取引情報が記憶される。

特開２００１−２９７１９５号公報

しかしながら、特許文献１においては、１つの注文情報について、受信、取引条件確認、取引成立、結果送信の各処理をシリアルに実行している。このため、特許文献1においては、特定の銘柄の注文が集中した場合など取引量が増加した場合、取引処理がスムーズに流れない、場合によってはシステムがダウンするとの問題が生じた。

そこで、本発明では、いわゆるトランザクション（複数の取引要求）を、所定の単位で分割してそれぞれ各処理(処理のためのサブ業務単位を含む)を並行処理で実行するように構成した。また、本発明には、このように分割した場合に、順序性を保証するものも含まれる。例えば、処理、ステップごとにデータベースに処理の進捗状況を格納しておくが含まれる。また、所定の単位としては、銘柄、端末、市場、サーバなどが含まれる。

より具体的には、証券取引の注文を発行する複数の取引端末と接続し、前記注文の取引を実行する証券取引システムにおいて、前記注文の受付処理を行い、受付処理が終了した注文を要件データベースに登録し、注文受付が終了したことを前記取引端末に送信する複数の受付手段であって、それぞれが処理すべき注文処理が前記取引端末に基づいて定められる受付手段と、それぞれが処理すべき銘柄が予め定められた複数の登録処理手段であって、受付処理が終わった注文のうち、当該登録処理手段で処理すべき銘柄の注文を前記要件データベースから読み出して、取引可能な状態として前記要件データベースに登録する登録処理手段と、前記要件データベースから登録が済んだ注文を読み出して、読み出した注文の登録が済んだことを前記取引端末に通知する複数の登録通知手段であって、それぞれが通知すべき注文が前記取引端末に基づいて定められる登録通知手段と、前記要件データベースに取引可能な状態として登録された注文で取引が成立する注文があれば成立処理を行い、成立済み注文として前記要件データベースに登録する約定処理手段であって、それぞれが処理すべき銘柄が予め定められた複数の約定処理手段と、前記要件データベースから成立済み注文を読み出して、読み出した注文が成立済みであることを前記取引端末に通知する複数の約定通知手段であって、それぞれが通知すべき注文が前記取引端末に基づいて定められる約定通知手段とを備え、前記複数の銘柄登録処理手段及び複数の前記約定処理手段のうちの一の登録処理手段及び約定処理手段が処理すべき銘柄は重複がないように設定されることを特徴とする証券取引システムである。また、本発明には、このシステムを構成する各装置（サーバ）、方法、これを実現するためのプログラムも含まれる。

さらに本発明には、以下の構成も含まれる。
各取引端末とグループの対応関係が取れるよう、受付装置でこの対になる情報を付加してこれを用いることが含まれる。ここで、対になる情報としては、各銘柄を識別する情報と銘柄グループの対応関係を示す情報も含まれる。

本発明によれば、サブ業務単位を含む各処理での並行処理が可能になり、よりシステムの拡張性をあげることが可能になる。

本発明の実施の形態について、図面を用いて説明する。本実施の形態は、証券(株式)の取引を例に説明するが、本発明はそれに限定されるものではない。

まず、図６を用いて本実施の形態の基本的な内容であるトランザクションの分割処理について説明する。図６に示すようにトランザクションをサブ業務単位に分割し、これを図６下方に示すようにサブ業務単位で並行実行することで、パイプライン処理のような(擬似的な)並行処理を実現する。なお、各サブ業務に関しては、図６上方に示された注文受付処理、取引処理、注文通知処理等が、その一例である。

次に、図１２〜１４を用いて、本実施の形態の概要（考え方）について説明する。本実施の形態の処理の前提として、取引処理は銘柄毎に順序性を保証し、注文受付や受付／約定通知は端末毎に管理する必要がある。これは、図１２に示したとおりである。上記前提から、図１３のように端末と銘柄とを各処理の処理単位とする。

また、この前提において、プロセス待ちが発生する要因については、処理単位が異なる処理間(例：注文受付〜取引処理制御１など)における待ち時間が挙げられる。
次に、図１３を用いて、処理単位が異なる処理間での待ちの考え方を説明する。処理単位が異なる処理として、例として注文受付から取引処理制御１をあげ、説明する。注文受付処理は端末単位、取引処理制御１は銘柄単位の処理である必要があるため、以下の処理を実行する。
注文受付：複数のプロセスが同時に同一端末からの処理をすることが無いよう、該当端末が注文受付中かをチェックする。端末グループ毎のプロセス数(処理多重度)を設定可とする。
取引処理制御１：銘柄グループ毎のプロセス数を1とし、銘柄グループ毎にシリアル処理を行う。

この制御によって、注文受付は端末毎、取引処理制御1は銘柄毎に順序性を保証している。

図１３のように、注文受付と取引処理制御1はそれぞれ端末、銘柄と処理単位が異なる。よって、以下の場合に待ちが発生することになる。

図１４に示すように、端末Ａと端末Ｂから、同一銘柄Ｃ(銘柄グループ1)に対して注文を行った場合を説明する。取引処理制御１は銘柄毎にシリアル処理する必要があるため、例えば、取引処理制御１に対して、端末Ａの注文が早く到着し、端末Ｂの注文があとに到着した場合、端末Ａからの注文の取引処理制御１が終了するまで、端末Ｂからの注文の処理は待つこととなる。このように取引処理制御１のメッセージキュー（ＭＱ）からの取出し時に待ちが発生する
上記待ち時間は、端末からの注文の到着がポアソン分布に従うこととし、取引処理制御１の処理時間、プロセス利用率、および窓口数(上記例では１)より、待ち行列理論を利用して算出する。レスポンス時間算出時はこの待ち時間を考慮し、評価している。この内容に関しては、図８〜１１を用いて第２の実施形態として説明する。

次に、本実施の形態におけるシステム構成図を図1に示す。各コンピュータは、ネットワークを介して互いに接続されている。また、各コンピュータは、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。図１に示すように、本実施の形態におけるシステムは、取引端末１、受付装置２、取引処理装置３、約定処理装置４と、取引に関する情報が格納された記憶装置群５から構成される。これら構成要件のそれぞれは、複数から構成されるものであるが、（１）取引端末１はグループとして複数の取引端末をまとめておいてもよい、（２）また、受付装置２、取引処理装置３、約定処理装置４は、ハードウエアとして一体のサーバ装置として構成され、それぞれはその機能を有するソフトウエアとして構成してもよい。また、（２）の場合、受付装置２、取引処理装置３を一体、取引処理装置３、約定処理装置４を一体などとしてもよい。本実施の形態では、図２に示すように約定処理装置４と取引処理装置３を一体とした例で説明する。この図１，２の構成では、各受付装置２（２１，２２）は、取引端末のグループ毎(証券会社など)に対応付けられている。また、各取引処理装置３、各約定処理装置４は（もしくはこれらが一体化された処理装置３１，３２）、処理すべき銘柄毎に対応付けられており、この対応関係の取引要求についての処理を実行する。この対応関係は、装置すなわちハードウエアでなく、ソフトウエアが有するようにしてもよい。さらに、この対応関係は、取引量などの条件に基づいて動的に変更してもよい。すなわち、あるグループからの取引要求やある銘柄の取引要求が(増加して)所定数(量)になった場合、所定の装置（例えば、取引要求の最も少ない同じ種類の装置、コンピュータ資源）をそのグループ(もしくは銘柄)の処理を実行するようにしてもよい。また、同じ種類の装置において、取引要求（もしくはそれに伴う計算量）の関係が一定の関係（差分が閾値以上や１：１０などの所定の関係）を満たすかを検知して、この内容に応じて対応関係を変更する（少ない取引要求の装置を多い取引要求の装置に変える）ことも、本実施の形態に含まれる。

以下、本実施の形態の処理内容について、説明する。
まず、図３を用いて、本発明における第１の実施形態であるトランザクション処理手順について説明する。ステップ１０１において、受付装置２１，２２は対応する取引処理装置からの注文を受け付ける注文受付処理を実行する。ここでは、取引処理装置から指定銘柄、売買の別、希望金額、株数、要求者（取引端末（グループ））を識別する情報を含む取引要求を、受付装置２１が受信する。対応する取引要求を受信するために、図示するように物理的に互いに対応する取引端末（グループ）を接続してもよいし、取引端末から対応する受付装置を特定して、特定された受付装置宛に、取引要求を送信するようにしてもよい。さらに、受付装置側で、対応する取引端末(グループ)のみを受信するようフィルタリング処理を施してもよい。

そして、同じステップ１０１において、入力電文すなわち取引要求のチェックを行う。このチェックは、通信経路上での障害発生状況により、正常に受信できたかを判断するものである。

なお、受付装置２は、ステップ１０１において、以下の処理を行うことも本実施の形態に含まれる。まず、前提として取引要求に含まれる要求者を識別する情報は、取引端末を特定する情報である。ここで、受付装置２は、この情報をキーに対応する端末グループを特定する情報を端末−端末グループ特定テーブルから検索する。そして、検索された情報を取引要求に含めて、その後の処理を実行する。なお、各取引装置のいずれかで、指定銘柄をキーに、図７に示す銘柄−銘柄グループ特定テーブルから銘柄グループを特定する情報を検索し、取引要求に検索された情報を含ませることも本実施の形態に含まれる。なお、このようにして新たに追加された情報は、各処理などでグループ（もしくは銘柄、欄末）を特定する際に使用される。

そして、ステップ１０２に進み、受付装置のそれぞれはステップ１０１のチェック結果を、取引要求を送信した取引端末に送信する。正常に受信できたと判断した場合には、正常受付応答を取引端末に送信する。そして、受信した取引要求を要件DB５１に格納する。この場合、各取引要求に取引状況を対応付けて記憶しておく。ここで、「受付」を示す情報を記憶しておく。さらに、取引要求に含まれる「取引銘柄」毎に対応する要件ＤＢに格納してもよい。例えば、「ａ」銘柄の取引要求は要件ＤＢ５１−ａに格納される。なお、要件ＤＢは、記憶装置群５１に格納されている。また、各要件ＤＢ５１（５１−ａ、５１−ｂ）は物理的に同一の媒体に格納してもよい。

次に、ステップ１０３において、取引装置３１、３２のそれぞれは（取引処理プログラムを用いて）、要件ＤＢ５１から取引状況が「受付」であり、自身に対応する「銘柄」の取引要求を抽出する。この抽出は、受付装置側が、要件ＤＢ５１への登録に併せて(含む同一銘柄が一定数以上登録した場合)、「取引銘柄」毎に対応する処理装置３１、３２に転送キュー送信することで実現してもよい。また、処理装置３１，３２が一定時間毎を含む所定タイミングで自身に対応する要件ＤＢ５１に対して「受付」の取引要求がないか検索して行ってもよいし、受付装置から登録したことを示す情報を受信することをトリガに要件ＤＢを検索してもよい。また、このトリガは、同一「銘柄」の取引要求が一定数以上になったことを検知して、実行してもよい。なお、要件ＤＢへの登録は「銘柄」毎の要件ＤＢに登録してもよい（以下同様）。

そして、抽出した取引要求をいわゆる板に載せる取引処理を実行する。すなわち、取引可能な状態に遷移させる。この処理の詳細については、図４，５を用いて後述する。この処理を実行した場合、要件ＤＢ取引状況を「受付」から「取引」に変更するよう登録する。

次に、ステップ１０４において、取引装置３１、３２のそれぞれは、取引要求を識別する注文受付番号を取引要求に付加して、要件ＤＢに格納する。そして、この登録もしくは時間、登録の数などをトリガに、各受付装置は、要件ＤＢから、自身に対応する「取引端末（グループ）」であって、取引状況が「取引」を示す取引要求を抽出し、当該取引要求を送信した取引端末にこの注文受付番号を通知する。

次に、ステップ１０５において、取引装置３１、３２のそれぞれは、（約定処理プログラムを用いて）、要件ＤＢ５１から取引状況が「取引」であり、自身に対応する「銘柄」の取引要求を抽出する。この抽出は、ステップ１０３と同様の処理により実行してもよい。そして、抽出した取引要求について、「約定処理」を実行する。すなわち、抽出した取引要求に対応する（売買が逆のものを示し、価格、株数が対応する）取引要求がないかを検出する。この処理は、通常行われているものであるので、その詳細の説明は省く。

次に、ステップ１０６に進み、ステップ１０５での約定処理で約定が成立するか（対応する取引要求が検出できたかを、取引処理装置３１、３２のそれぞれは、（約定処理プログラムを用いて）実行する。この結果を、対応する取引要求に関連付けて要件ＤＢに格納する。そして、約定が成立した場合には、ステップ１０７に進み、約定が成立しなかった場合には、ステップ１０８に進む。なお、ステップ１０６において、約定が成立した場合には、要件ＤＢの「取引」を「約定」に変更する。また、約定が成立しない場合には、「取引」を「未約定」に変更する。

次に、ステップ１０７では、この登録もしくは時間、登録の数などをトリガに、各受付装置は、要件ＤＢから、自身に対応する「取引端末（グループ）」であって、取引状況が「約定」を示す取引要求を抽出し、当該取引要求を送信した取引端末に約定を特定する約定番号を含む約定通知を送信する。そして、ステップ１０７に進む。

次に、ステップ１０８では、取引装置３１、３２のそれぞれは（取引処理プログラムを用いて）、図示しない相場システムなどへ送信する外部出力情報を作成して送信する。ここでは、上述のとおり、自身に対応する「銘柄」の取引要求であって「約定」もしくは「未約定」のものを抽出して、これらについてこの処理を実行する。

次に、図４および５を用いて、ステップ１０１〜１０３(特に１０３)の詳細について説明する。まず、図４を用いて、正常に処理できた場合の例を説明する。

まず、ステップ１０１と１０２の詳細について説明する。なお、ステップ１０１、１０２（すなわち下記の詳細処理）は、「グループ」単位で実行するものである。これは、先に記述したとおりである。

ステップ１０１１においては、送信された取引要求を受信し、ステップ１０１２では先に説明のとおり、入力電文すなわち取引要求のチェックを行う。このチェックは、通信経路上での障害発生状況により、正常に受信できたかを判断するものである。正常でないと判定された場合にはステップ１０２１に進み、正常であると判定された場合にはステップ１０２２に進む。

ステップ１０２１では、送信した取引端末にエラー（正常に受信できなかった旨）の通知を行う。そして、ステップ１０２２では、受信した取引要求、「銘柄」毎に設けられた要件ＤＢに対して、登録を行う。すなわち、受信した取引要求の「銘柄」に対応する要件ＤＢに登録する。この際、「受付」を「取引」に変更して登録する。

次に、ステップ１０２３では、受信が正常に行われたことを、取引端末に送信する。そして、ステップ１０２４で、転送キュー（ＭＱ）を発生させて、取引装置３１などでの処理トリガとする。ここでは、「銘柄」毎に発生するようにしてもよい。この転送キューの発生（もしくは処理装置へ通知）は上述のとおり、一定時間毎を含む所定タイミング、受付装置での要件ＤＢへの登録(含む同一「銘柄」の取引要求が一定数以上)になったことを検知して、実行してもよい。

次に、ステップ１０３の詳細について説明する。なお、ステップ１０３（すなわち下記の詳細処理）は、「銘柄」単位で実行するものである。これは、上述のとおりである。ステップ１０３１で、自身に対応する「銘柄」の取引情報を要件ＤＢから抽出する。そして、ステップ１０３２において、抽出された取引要求の各項目に抜けがないか、数量について発行数と対応が取れていないか等の確認処理を実行する。

そして、ステップ１０３３において、エラー（すなわち正しくないと判断された）場合、ステップ１０３４に進みエラー処理を行う。つまり、取引端末にエラーの旨の通知を実行する。

また、正常であると判定された場合、ステップ１０３５に進む。そして、ステップ１０３５において、「板登録処理」を行う。板登録処理の態様としては、要件ＤＢにおいて、取引可能であるとのフラグを立てることが含まれる。また、注文受付・板ＤＢに登録することも本実施の形態の一態様に含まれる。さらに、これらの組み合わせでもよい。

次に、ステップ１０３６において、板登録処理を実行したことを、対応する「銘柄」の要件ＤＢに登録する。そして、ステップ１０３７に進み取引端末に対して注文が正常に受付けられた旨の通知を実行する。そして、ステップ１０３９で、ステップ1024と同様に、転送キュー（ＭＱ）を発生させて、取引装置３１などでの処理トリガとする。ここでは、「銘柄」毎に発生するようにしてもよい。この転送キューの発生（もしくは処理装置へ通知）は上述のとおり、一定時間毎を含む所定タイミング、受付装置での要件ＤＢへの登録(含む同一「銘柄」の取引要求が一定数以上)になったことを検知して、実行してもよい。

次に、図５を用いて、異常終了した場合の処理について説明する（ステップ１０３の途中で異常終了した場合）。基本的には、図４と同様の処理を実行する。異常終了を検知した場合、その処理要求を再実行する。具体的には、異常終了した取引要求と同一のデータを要件ＤＢから読み込むことで実現する。

なお、要件ＤＢは上述のように、銘柄ごと、グループごとなど複数種類用意してもよい。この場合、処理状況が変わること（ある要件ＤＢの「受付」から「取引」へなど）をトリガに、互いの情報の整合が取れるよう、他の要件ＤＢの取引状況を変更するよう制御する。

また、データベース群としては、図４、５での各処理の連携を行うためのデータベースを設けてもよい。要件ＤＢやこれらには、以下のものが含まれる。
要件DB：基盤ＡＰＰのトランザクション連携用にデータを格納するデータベース
要件DB（受付→取引）：「受付処理→取引処理」間におけるデータ連携用ＤＢ
要件DB（取引→約定）：「取引処理→約定処理」間におけるデータ連携用ＤＢ
要件DB（約定→取引）：「約定処理→取引処理」間におけるデータ連携用ＤＢ
要件DB（取引→受付）：「取引処理→受付処理」間におけるデータ連携用ＤＢ
業務DB：業務で必要となるデータベース。
注文受付・板DB：取引処理装置の結果を格納
注文履歴DB：約定処理装置の結果を格納
なお、以上の本発明の実施の形態により、パイプライン処理のような（擬似的な）並行処理によってスループット向上することも可能になる。

なお、以上のような実施の形態（グルーピング化による分散処理）を採用することで、各処理装置（取引処理装置３、約定処理装置４）を増設する垂直拡張により、取引（演算）量の増大にも対応が可能になる。また、受付装置２は処理装置（ＣＰＵ）の追加（増強）による水平拡張により、取引（演算）量の増大にも対応が可能になる。なお、本発明では、このような拡張に限定されず、例えば、各取引装置をいわゆる垂直拡張とし、受付装置を水平拡張としてもよい。また、それぞれいずれも垂直拡張、水平拡張としてもよい。

次に、本発明の第２の実施形態について、図８〜１１を用いて説明する。

第２の実施の形態では、上記の実施の形態での分散処理を行った場合のレスポンス時間の算出について説明する。すなわち、前記第１の実施形態のように、分散処理を行った場合、各取引要求についてのレスポンス時間はすぐには算出できない。これは、図１０、１１に示すように、各サブ業務処理が１つの装置で実行されるのでないので、業務処理全体の実行時間の算出が困難になるためである。なお、レスポンス時間とは、図８に示すように注文受付処理の開始時刻から受信通知処理や約定通知処理の終了時刻までの時間を指す。

そこで、本実施の形態では、複数の処理装置で、分散実行しているサブ業務を１つの注文受信通知業務としてつなぎあわせ、業務レスポンス情報として作成するよう制御する。すなわち、各サブ業務のうち、最初のサブ業務の開始時間と最後のサブ業務の終了時間を記録し、これの差分をレスポンス時間として算出する。なお、時間の記録の際は、取引を識別する情報（受付ＮＯ）を対応付けて記録しておく。

また、図８に示すよう、各サブ業務の開始時間と、最後のサブ業務においては終了時間をも記録して構成してもよい。この場合、必要なサブ業務を指定に基づいて抽出して、サブ業務（複数のサブ業務からなるものを含む）のレスポンス時間を算出することが可能になる。より、具体的には、以下の処理を実行する。注文受付のサブ業務開始時刻と受付番号を、ＤＢに登録する。以降の処理においても、サブ業務開始時刻と受付番号をＤＢに登録する。１つの注文受信通知業務の最後にあたるサブ業務「受信通知処理」では、サブ業務開始時刻と受付番号の他、取引端末への応答後であるサブ業務終了時刻をＤＢに登録する。１つの注文受信通知業務に対応した受付番号をキーとして、先頭のサブ業務「注文受付」の開始時刻と、最後のサブ業務「受信通知処理」の終了時刻の差分より、注文受信通知業務のレスポンス時間を算出する。

本実施の形態におけるシステム構成図（１）である。 本実施の形態におけるシステム構成図（２）である。 本実施の形態における処理の内容を示すフローチャートである。 図３におけるステップ１０１〜１０３の詳細処理を示すフローチャート(正常)である。 図３におけるステップ１０１〜１０３の詳細処理を示すフローチャート(異常終了)である。 本実施の形態の基本的な処理内容を説明するための図である。 本実施の形態の銘柄−銘柄グループの対応関係を記録したテーブルを示す図である。 レスポンス情報の概念を示す図である。 レスポンス情報の時間イメージを示す図である。 端末別のレスポンス情報対象処理を示す図である。 銘柄別のレスポンス情報対象処理を示す図である。 実施の形態における待ちの考え方を示す図である（その１）。 実施の形態における待ちの考え方を示す図である（その２）。 実施の形態における待ちの考え方を示す図である（その３）。

符号の説明

１…取引端末、２…受付装置、３…取引処理装置、４…約定処理装置

Claims (10)

1. 証券取引の注文を発行する複数の取引端末と接続され、前記注文の取引を実行する証券取引システムであって、それぞれが処理すべき注文が前記取引端末に基づいて定められる複数の受付装置と、それぞれが処理すべき銘柄が予め定められた複数の取引処理装置と、それぞれが処理すべき銘柄が予め定められた複数の約定処理装置と、それぞれが、前記注文の銘柄各々に対応付けられた複数要件データベースとから構成される証券取引システムを用いた証券取引方法において、
   前記受付装置は、当該受付装置で処理すべき注文として、前記複数の取引端末のうち自身の取引端末グループでの注文の受付処理を行い、受付処理が終了した注文を当該注文の銘柄に対応付けられた要件データベースに登録し、前記注文を登録したことを示す第１のメッセージを前記注文の銘柄の処理対象として定められた取引処理装置に送信し、前記注文の受付が終了したことを示す通知を前記取引端末に送信し、
   前記取引処理装置は、前記第１のメッセージを受信した場合、前記受付処理が終わった注文のうち当該取引処理装置で処理すべき銘柄の注文を、当該注文の銘柄に対応付けられ、自身に対応する要件データベースから検索して読み出して取引可能な状態として、前記要件データベースに登録し、前記注文を取引可能な状態として登録したことを示す第２のメッセージを前記受付装置及び前記注文の銘柄の処理対象として定められた約定処理装置に送信し、
   前記受付装置は、前記第２のメッセージを受信した場合、取引可能な状態として登録が済んだ注文のうち当該受付装置で処理すべき注文である当該受付装置の取引端末グループの注文を、前記注文の銘柄に対応付けられ、自身に対応する要件データベースから読み出して、読み出した注文の登録が済んだことを前記取引端末に通知し、
   前記約定処理装置は、前記第２のメッセージを受信した場合、当該約定処理装置で処理すべき銘柄に対応付けられた要件データベースに取引可能な状態として登録された注文で取引が成立する注文があれば成立処理を行い、成立済み注文として前記要件データベースに登録し、前記注文を成立済み注文として登録したことを示す第３のメッセージを前記受付装置に送信し、
   前記受付装置は、前記第３のメッセージを受信した場合、成立済み注文として登録が済んだ注文のうち当該受付装置で処理すべき注文である当該受付装置の取引端末グループの注文を、当該注文の銘柄に対応付けられ自身に対応する要件データベースから読み出して、読み出した注文が約定されたことを前記取引端末に通知し、
   前記複数の取引処理装置及び複数の約定処理装置のうちの一の取引処理装置及び約定処理装置が処理すべき銘柄は重複がないように設定されることを特徴とする証券取引方法。
2. 請求項１に記載の証券取引方法において、
   前記第１乃至第３のメッセージは、メッセージキューによって送受信されることを特徴とする証券取引方法。
3. 請求項１または２に記載の証券取引方法において、
   前記受付装置は、
   前記取引端末から、指定銘柄、売買の別、希望金額、株数および当該取引端末を識別する識別情報を含む注文を受信し、
   受信した前記注文が正常に受信できたかを判断し、
   正常に受信できたと判断した場合は、受付処理が完了したことを示す取引状況を前記注文に対応付けて前記要件データベースに登録することを特徴とする証券取引方法。
4. 請求項３に記載の証券取引方法において、
   前記取引処理装置は、
   前記要件データベースから、受付処理が完了したことを示す取引状況に対応付けられた注文のうち、当該注文に含まれる指定銘柄が当該取引処理装置で処理すべき銘柄と一致する注文を抽出し、
   抽出した注文の形式が正しいかを判断し、
   正しいと判断した場合は、前記取引状況を取引可能な状態であることを示す情報に更新することを特徴とする証券取引方法。
5. 請求項４に記載の証券取引方法において、
   前記約定処理装置は、
   前記要件データベースから、取引可能な状態であることを示す取引状況に対応付けられた注文のうち、当該注文に含まれる指定銘柄が当該約定処理装置で処理すべき銘柄と一致する注文を抽出し、
   抽出した注文に含まれる売買の別の逆を示す注文であって、希望金額および株数が対応する注文が前記要件データベースに存在するかを判断し、
   前記対応する注文が存在した場合は、当該対応する注文と前記抽出した注文の取引状況を約定が成立したことを示す情報に更新し、
   前記対応する注文が存在しなかった場合は、前記抽出した注文の取引状況を約定が成立しなかったことを示す情報に更新することを特徴とする証券取引方法。
6. 証券取引の注文を発行する複数の取引端末と接続され、前記注文の取引を実行する証券取引システムであって、それぞれが処理すべき注文が前記取引端末に基づいて定められる複数の受付装置と、それぞれが処理すべき銘柄が予め定められた複数の取引処理装置と、それぞれが処理すべき銘柄が予め定められた複数の約定処理装置と、それぞれが前記注文の銘柄各々に対応付けられた複数の要件データベースとから構成される証券取引システムにおいて、
   前記受付装置は、当該受付装置で処理すべき注文として、前記複数の取引端末のうち自身の取引端末グループでの注文の受付処理を行い、受付処理が終了した注文を当該注文の銘柄に対応付けられた要件データベースに登録し、前記注文を登録したことを示す第１のメッセージを前記注文の銘柄の処理対象として定められた取引処理装置に送信し、前記注文の受付が終了したことを示す通知を前記取引端末に送信し、
   前記取引処理装置は、前記第１のメッセージを受信した場合、前記受付処理が終わった注文のうち当該取引処理装置で処理すべき銘柄の注文を、当該注文の銘柄に対応付けられ、自身に対応する要件データベースから読み出して取引可能な状態として、前記要件データベースに登録し、前記注文を取引可能な状態として登録したことを示す第２のメッセージを前記受付装置及び前記注文の銘柄の処理対象として定められた約定処理装置に送信し、
   前記受付装置は、前記第２のメッセージを受信した場合、取引可能な状態として登録が済んだ注文のうち当該受付装置で処理すべき注文である当該受付装置の取引端末グループの注文を、前記注文の銘柄に対応付けられ、自身に対応する要件データベースから読み出して、読み出した注文の登録が済んだことを前記取引端末に通知し、
   前記約定処理装置は、前記第２のメッセージを受信した場合、当該約定処理装置で処理すべき銘柄に対応付けられた要件データベースに取引可能な状態として登録された注文で取引が成立する注文があれば成立処理を行い、成立済み注文として前記要件データベースに登録し、前記注文を成立済み注文として登録したことを示す第３のメッセージを前記受付装置に送信し、
   前記受付装置は、前記第３のメッセージを受信した場合、成立済み注文として登録が済んだ注文のうち当該受付装置で処理すべき注文である当該受付装置の取引端末グループの注文を、当該注文の銘柄に対応付けられ、自身に対応する要件データベースから読み出して、読み出した注文が約定されたことを前記取引端末に通知し、
   前記複数の取引処理装置及び複数の約定処理装置のうちの一の取引処理装置及び約定処理装置が処理すべき銘柄は重複がないように設定されることを特徴とする証券取引システム。
7. 請求項６に記載の証券取引システムにおいて、
   前記第１乃至第３のメッセージは、メッセージキューによって送受信されることを特徴とする証券取引システム。
8. 請求項６または７に記載の証券取引システムにおいて、
   前記受付装置は、
   前記取引端末から、指定銘柄、売買の別、希望金額、株数および当該取引端末を識別する識別情報を含む注文を受信し、
   受信した前記注文が正常に受信できたかを判断し、
   正常に受信できたと判断した場合は、受付処理が完了したことを示す取引状況を前記注文に対応付けて前記要件データベースに登録することを特徴とする証券取引システム。
9. 請求項８に記載の証券取引システムにおいて、
   前記取引処理装置は、
   前記要件データベースから、受付処理が完了したことを示す取引状況に対応付けられた注文のうち、当該注文に含まれる指定銘柄が当該取引処理装置で処理すべき銘柄と一致する注文を抽出し、
   抽出した注文の形式が正しいかを判断し、
   正しいと判断した場合は、前記取引状況を取引可能な状態であることを示す情報に更新することを特徴とする証券取引システム。
10. 請求項９に記載の証券取引システムにおいて、
    前記約定処理装置は、
    前記要件データベースから、取引可能な状態であることを示す取引状況に対応付けられた注文のうち、当該注文に含まれる指定銘柄が当該約定処理装置で処理すべき銘柄と一致する注文を抽出し、
    抽出した注文に含まれる売買の別の逆を示す注文であって、希望金額および株数が対応する注文が前記要件データベースに存在するかを判断し、
    前記対応する注文が存在した場合は、当該対応する注文と前記抽出した注文の取引状況を約定が成立したことを示す情報に更新し、
    前記対応する注文が存在しなかった場合は、前記抽出した注文の取引状況を約定が成立しなかったことを示す情報に更新することを特徴とする証券取引システム。

Images