(57)【要約】【課題】取引所に次々に寄せられる証券や商品等の取引要求を銘柄に応じて振り分けて並列処理を行う場合に、取引順序を守りながら取引を停止させずに迅速に振り分けを変更する。【解決手段】各銘柄を分類してなる各銘柄グループに、銘柄に応じて取引要求を振り分けて並列処理を行い、各銘柄グループに分類される各銘柄を記憶した銘柄グループ管理テーブルと、各取引要求と各取引要求が振り分けられる銘柄グループの識別子とを対応付けて記憶する取引要求記憶部とを備え、ある銘柄の分類を変更する際に、銘柄グループ管理テーブルに記憶されているある銘柄が分類される銘柄グループの識別子を変更すると共に、取引要求記憶部に記憶されている、ある銘柄を指定した取引要求と対応付けられている銘柄グループの識別子も変更する。【選択図】  図１
2006293852.tif 000002
【特許請求の範囲】
【請求項１】
市場で取引される取引対象の各銘柄を分類してなる複数の銘柄グループの各識別子と、各銘柄グループに分類される取引対象の各銘柄を示す情報とをそれぞれ対応付ける銘柄グループ管理テーブルと、
取引対象の銘柄を示す情報が記載された複数の取引要求を受信する取引要求受信部と、
受信した各取引要求を、各取引要求に記載された取引対象の各銘柄を示す情報とそれぞれ対応付けられる各銘柄グループの識別子とそれぞれ対応付けて記憶する取引要求記憶部と、
前記取引要求記憶部に記憶された各取引要求を、記憶された順に銘柄グループ毎にそれぞれ読み出して取引処理を行う複数の取引処理部と、
各取引処理部がそれぞれ前記取引要求記憶部から読み出す取引要求を特定する銘柄グループの識別子を、各取引処理部の識別子とそれぞれ対応付けて記憶する読出管理テーブルと、
取引対象のある銘柄が分類される銘柄グループを第１の銘柄グループから第２の銘柄グループに変更する際に、前記銘柄グループ管理テーブルにおいて前記取引対象のある銘柄を示す情報と対応付けられている銘柄グループの識別子を前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更すると共に、前記取引要求記憶部において前記取引対象のある銘柄を示す情報が記載された各取引要求とそれぞれ対応付けられている各銘柄グループの識別子についても前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更する銘柄グループ更新処理部と、
を備えることを特徴とする情報処理装置。
【請求項２】
単位時間あたりに受信する取引要求の数を、銘柄グループ毎にそれぞれ判定値と比較する受信数比較部と、
を備え、
前記第１の銘柄グループは、単位時間あたりに受信した取引要求の数が判定値を超えた銘柄グループである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記各取引処理部の異常を検知する異常検知部と、
を備え、
前記第１の銘柄グループは、前記読出管理テーブルにおいて、前記異常検知部により異常が検知された取引処理部の識別子と対応付けられる識別子により特定される銘柄グループである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
市場で取引される取引対象の各銘柄を分類してなる複数の銘柄グループの各識別子と、各銘柄グループに分類される取引対象の各銘柄を示す情報とをそれぞれ対応付ける銘柄グループ管理テーブルと、
取引対象の銘柄を示す情報が記載された複数の取引要求を受信する取引要求受信部と、
受信した各取引要求を、各取引要求に記載された取引対象の各銘柄を示す情報とそれぞれ対応付けられる各銘柄グループの識別子とそれぞれ対応付けて記憶する取引要求記憶部と、
前記取引要求記憶部に記憶された各取引要求を、記憶された順に銘柄グループ毎にそれぞれ読み出して取引処理を行う複数の取引処理部と、
各取引処理部がそれぞれ前記取引要求記憶部から読み出す取引要求を特定する銘柄グループの識別子を、各取引処理部の識別子とそれぞれ対応付けて記憶する読出管理テーブルと、
を備える情報処理装置の制御方法であって、
取引対象のある銘柄が分類される銘柄グループを第１の銘柄グループから第２の銘柄グループに変更する際に、前記銘柄グループ管理テーブルにおいて前記取引対象のある銘柄を示す情報と対応付けられている銘柄グループの識別子を前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更すると共に、前記取引要求記憶部において前記取引対象のある銘柄を示す情報が記載された各取引要求とそれぞれ対応付けられている各銘柄グループの識別子についても前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更することを特徴とする情報処理装置の制御方法。
【請求項５】
市場で取引される取引対象の各銘柄を分類してなる複数の銘柄グループの各識別子と、各銘柄グループに分類される取引対象の各銘柄を示す情報とをそれぞれ対応付ける銘柄グループ管理テーブルと、
取引対象の銘柄を示す情報が記載された複数の取引要求を受信する取引要求受信部と、
受信した各取引要求を、各取引要求に記載された取引対象の各銘柄を示す情報とそれぞれ対応付けられる各銘柄グループの識別子とそれぞれ対応付けて記憶する取引要求記憶部と、
前記取引要求記憶部に記憶された各取引要求を、記憶された順に銘柄グループ毎にそれぞれ読み出して取引処理を行う複数の取引処理部と、
各取引処理部がそれぞれ前記取引要求記憶部から読み出す取引要求を特定する銘柄グループの識別子を、各取引処理部の識別子とそれぞれ対応付けて記憶する読出管理テーブルと、
を備える情報処理装置に、
取引対象のある銘柄が分類される銘柄グループを第１の銘柄グループから第２の銘柄グループに変更する際に、前記銘柄グループ管理テーブルにおいて前記取引対象のある銘柄を示す情報と対応付けられている銘柄グループの識別子を前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更すると共に、前記取引要求記憶部において前記取引対象のある銘柄を示す情報が記載された各取引要求とそれぞれ対応付けられている各銘柄グループの識別子についても前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更する手順
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関する。
【背景技術】
【０００２】
今日、証券取引所や商品取引所などにおいては、株式や各種商品などの取引対象が毎日活発に取引されている。また情報技術の進歩により、これらの取引はコンピュータシステムを用いて行われるようになった。  
取引所には毎日多くの顧客から様々な銘柄に対する注文が次々と寄せられるが、これらの注文は迅速かつ公平に処理されなければならない。  
このため、取引所において取引に用いられるコンピュータシステムには様々な技術が採用されている（例えば特許文献１参照）。
【特許文献１】特開２００２−３２４０２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、取引所に大量に寄せられるこれらの注文を並列に処理することにより迅速な処理を実現しようとする場合には、取引の公平化を図るために、取引の順序に対する配慮が求められる。つまり、ある銘柄に対して後から出された注文が、その銘柄に対して先に出された注文よりも先に処理されてしまうことがないようにしなければならない。
【０００４】
このため取引を並列処理する場合には、別銘柄に対する注文同士で行われる必要がある。この場合、処理効率等の観点から、取引所に上場されている各銘柄を複数の銘柄グループに分類した上で、銘柄グループ間で並列に処理することになる。
【０００５】
そしてこの場合には、各銘柄グループ間の負荷バランスに対する配慮が求められる。例えば株式の取引においては、突然のニュースなどにより、ある特定の銘柄に対する注文が殺到する場合がある。この場合、ある銘柄グループに対する処理負荷が上昇することになる。このため、取引を停止させることなく、かつ取引の順序を守りながら、迅速にその銘柄を他の銘柄グループに移動させ、銘柄グループ間の負荷分散を図ることを可能とする技術が望まれる。
【０００６】
また、取引中にコンピュータシステムに障害が発生した場合には、取引に影響を与えないようにすることが求められる。このため、障害による影響を受ける銘柄グループに分類される各銘柄を、障害による影響を受けない銘柄グループに、取引を停止させることなく、かつ取引の順序を守りながら、迅速に移動させることを可能とする技術が望まれている。
【０００７】
本発明は上記課題を鑑みてなされたものであり、取引を継続したまま、かつ取引の順序を守りながら、迅速に処理の振り分け変更が可能な情報処理装置、情報処理装置の制御方法、及びプログラムを提供することを主たる目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明は、市場で取引される取引対象の各銘柄を分類してなる複数の銘柄グループの各識別子と、各銘柄グループに分類される取引対象の各銘柄を示す情報とをそれぞれ対応付ける銘柄グループ管理テーブルと、取引対象の銘柄を示す情報が記載された複数の取引要求を受信する取引要求受信部と、受信した各取引要求を、各取引要求に記載された取引対象の各銘柄を示す情報とそれぞれ対応付けられる各銘柄グループの識別子とそれぞれ対応付けて記憶する取引要求記憶部と、前記取引要求記憶部に記憶された各取引要求を、記憶された順に銘柄グループ毎にそれぞれ読み出して取引処理を行う複数の取引処理部と、各取引処理部がそれぞれ前記取引要求記憶部から読み出す取引要求を特定する銘柄グループの識別子を、各取引処理部の識別子とそれぞれ対応付けて記憶する読出管理テーブルと、取引対象のある銘柄が分類される銘柄グループを第１の銘柄グループから第２の銘柄グループに変更する際に、前記銘柄グループ管理テーブルにおいて前記取引対象のある銘柄を示す情報と対応付けられている銘柄グループの識別子を前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更すると共に、前記取引要求記憶部において前記取引対象のある銘柄を示す情報が記載された各取引要求とそれぞれ対応付けられている各銘柄グループの識別子についても前記第１の銘柄グループの識別子から前記第２の銘柄グループの識別子に変更する銘柄グループ更新処理部と、を備えることを特徴とする情報処理装置に関する。
【０００９】
その他、本願が開示する課題、及びその解決方法は、発明を実施するための最良の形態の欄、及び図面により明らかにされる。
【発明の効果】
【００１０】
取引を継続したまま、かつ取引の順序を守りながら、迅速に処理の振り分け変更が可能な情報処理装置、情報処理装置の制御方法、及びプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１１】
＝＝＝第１の実施の形態＝＝＝
＝＝＝全体構成例＝＝＝
第１の実施の形態に係る取引所システムの全体構成を図１に示す。本実施の形態に係る取引所システムは、証券取引所において株式の取引を行うコンピュータシステムである。もちろん取引の対象は株式に限られず、有価証券、金、大豆、生糸、とうもろこし、えび、コーヒー豆、アルミニウム、ゴムなど、証券取引所や商品取引所において取引の対象とされるものとすることができる。
【００１２】
取引所システムは、注文受付サーバ３００と、取引執行サーバ（特許請求の範囲に記載の情報処理装置に相当する）２００とがネットワーク４００を介して通信可能に接続されてなる。
【００１３】
また取引所システムは、ネットワーク４００を介して注文入力端末１００と通信可能に接続される。注文入力端末１００は、投資家からの株式売買注文を受け付ける証券会社等が有するコンピュータである。なお、図１には１台の注文入力端末１００が記載されているが、注文入力端末１００は複数台とすることもできる。注文入力端末１００は、投資家からの株式売買注文に応じて、図１０に示すような注文電文（特許請求の範囲に記載の取引要求に相当する）６００を注文受付サーバ３００に送信する。
【００１４】
図１０に示すように注文電文６００には、”市場コード”、”商品コード”、”銘柄コード”、”会員コード”、”売買”、”値段”、”数量”の各欄が含まれる。”市場コード”欄には、株式市場を示す情報が記載される。株式市場としては、例えば大阪証券取引所における第１部市場や第２部市場、ヘラクレス市場、東京証券取引所における第１部市場等とすることができる。”商品コード”欄には、「先物取引」や「オプション取引」等の取引の種別を示す情報が記載される。”銘柄コード”欄には株式の銘柄を示す情報が記載される。”会員コード”欄には、証券会社の識別情報が記載される。”売買”欄には、株式を買うのか、売るのかを示す情報が記載される。”値段”欄には、株式の売買希望価格を示す情報が記載される。”数量”欄には、取引を希望する株式の数量を示す情報が記載される。
【００１５】
注文電文６００が注文受付サーバ３００に送信されると、注文受付サーバ３００及び取引執行サーバ２００により株式の取引の処理が行われる。
【００１６】
注文受付サーバ３００は、注文入力端末１００から注文電文６００を受信すると、注文電文６００の内容を、注文番号と対応付けて注文受付データベース７００に記憶する。注文受付データベース７００を図６に示す。注文番号は注文受付サーバ３００により各注文に対して一意に付される番号である。そして注文受付サーバ３００は、図７に示す銘柄グループ定義データベース（特許請求の範囲に記載の銘柄グループ管理テーブルに相当する）７１０を参照し、注文電文６００に記載された銘柄コードにより示される銘柄が分類される銘柄グループの識別子（銘柄グループ番号）を取得する。銘柄グループ定義データベース７１０は、株式市場における株式の各銘柄を分類してなる複数の銘柄グループの各識別子と、各銘柄グループに分類される株式の各銘柄を示す情報とをそれぞれ対応付けたものである。なお図７に示すように銘柄グループは、銘柄コードによってのみならず、商品コードや市場コードによっても分類するようにすることもできる。このようにすることにより、取引の形態により適合した詳細な株式の銘柄の分類をすることができる。
【００１７】
続いて注文受付サーバ３００は、取得した銘柄グループ番号と、注文番号と、銘柄キーとを対応付けてなる注文データを、要件データベース（特許請求の範囲に記載の取引要求記憶部に相当する）７２０に記憶する。要件データベース７２０への記憶は、注文データを取引執行サーバ２００に送信し、取引執行サーバ２００が、受信した上記注文データを要件データベース７２０に書き込むことにより行われる。注文データは、注文番号により、注文受付データベース７００に記憶されている注文電文（取引要求）６００と対応付けられる。従ってもちろん、注文電文６００を銘柄グループ番号と対応付けて要件データベース７２０に直接記憶してしまうようにすることもできる。要件データベース７２０を図８に示す。なお銘柄キーは、市場コードと商品コードと銘柄コードとを一つのコードとして纏めたものである。また要件データベース７２０の”要件作成時刻”欄には、注文データが要件データベース７２０に書き込まれた時刻を示す情報が記憶される。”処理フラグ”欄には、各注文データに対して取引処理がなされているか、いないかを示す情報が記載される。取引執行サーバ２００は、”処理フラグ”欄を「未処理」にして、注文データを要件データベース７２０に書き込む。
【００１８】
そして要件データベース７２０に書き込まれた各注文データに対して、取引執行サーバ２００により取引処理が行われる。取引執行サーバ２００は、各注文データに対する処理を行う複数の取引処理プロセス（特許請求の範囲に記載の取引処理部に相当する）８１１を実行している。各取引処理プロセス８１１にはそれぞれ銘柄グループ番号が割り当てられており、割り当てられた銘柄グループ番号の注文データに対する処理を行う。各取引処理プロセス８１１へ割り当てられる銘柄グループ番号は、図９に示す取引処理割当データベース（特許請求の範囲に記載の読出管理テーブルに相当する）７５０に記載される。各取引処理プロセス８１１は要求データベース７２０に記憶された各注文データを、”要件作成時刻”欄に記載された時刻情報、及び”銘柄グループ番号”欄に記載された銘柄グループ番号に基づいて、記憶された順に（古い順に）銘柄グループ毎にそれぞれ読み出して取引処理を行う。このようにすることにより、各注文データを順序性を保ったまま銘柄グループ単位で並列処理することができる。各注文データに対する取引の結果は、銘柄データベース７３０及び歩みデータベース７４０に記憶される。銘柄データベース７３０には各銘柄の注文データが記憶されており、取引処理プロセス８１１が、条件の折り合う売り注文と買い注文との間で売買を成立させる。歩みデータベース７４０には、過去から現在に至る全取引の履歴情報が記憶されている。また要求データベース７２０に記憶されている注文データに対して取引処理が行われると、取引処理プロセス８１１によりその注文データの”処理フラグ”欄が「処理済み」に更新される。
【００１９】
また取引執行サーバ２００はモニタリングプロセス（特許請求の範囲に記載の受信数比較部に相当する）８１３を実行している。モニタリングプロセス８１３は、単位時間あたりに受信する株式取引要求の数、例えば単位時間あたりに要件データベース７２０に書き込まれる注文データの数を、銘柄グループ毎にそれぞれ判定値と比較する。これにより、ある銘柄グループに対する取引件数が急増したことを検知することが可能となる。例えば新製品発表のニュースなどにより、ある銘柄グループに分類されるある銘柄に対する取引件数が急増すると、その銘柄グループに分類される他の銘柄に対して、処理が遅延する等の影響を与える。そこでこの場合、各銘柄グループ間の処理負荷の分散を図るべく、銘柄グループ間での銘柄の入れ換えや移動を行う。
【００２０】
ここで、銘柄グループ間での銘柄の入れ替えや移動は、銘柄グループ定義データベース７１０を更新することにより行うことができるが、単に銘柄グループ定義データベース７１０を更新しただけでは、新規の注文電文６００に対しては新たな分類に従って銘柄グループが決定されるようになるが、要件データベース７２０に記憶された処理待ちの各注文データに対しては、古い分類に従った銘柄グループのまま取引処理が行われることになる。そのためこの場合、銘柄グループの分類の変更を直ちに行ったとしても、なお相当の期間古い分類での処理が行われることになる。そこで本実施の形態においては、銘柄グループ定義データベース７１０を更新すると共に、要件データベース７２０に記憶されている各注文データの銘柄グループ番号も更新する。これにより、銘柄グループの分類の変更と共に、直ちに新たな分類での処理が開始されるようにすることができる。このことは、処理の迅速性が要求される株式等の取引においては極めて重要である。なお、銘柄グループ定義データベース７１０の更新や要件データベース７２０の更新は、運転管理プロセス（特許請求の範囲に記載の銘柄グループ更新処理部に相当する）８１２により行われる。
【００２１】
また本実施の形態に係る取引執行サーバ２００は障害検知プロセス（特許請求の範囲に記載の異常検知部に相当する）８１４を実行している。障害検知プロセス８１４は各取引処理プロセス８１１の異常を検知する。ある取引処理プロセス８１１に異常が発生すると、その取引処理プロセス８１１が処理すべき銘柄グループの処理に影響が生じる。そのためこのような場合には直ちに正常な取引処理プロセス８１１に処理を引き継がなければならない。そのため本実施の形態に係る運転管理プロセス８１２は、ある取引処理プロセス８１１に異常が検知された場合には、その取引処理プロセス８１１が処理していた銘柄グループに分類される各銘柄を他の銘柄グループに移動させるべく、銘柄グループ定義データベース７１０を更新すると共に、要件データベース７２０に記憶されている各注文データの銘柄グループ番号も更新する。これにより、取引処理プロセス８１１の障害発生時の銘柄グループの分類の変更に伴って、直ちに正常な取引処理プロセス８１１に処理を引き継ぐことができるようになる。なお、取引処理プロセスの引き継ぎは、取引処理割当データベース７５０の更新によって行うようにすることも可能である。
【００２２】
なお図１には注文受付サーバ３００と取引執行サーバ２００とは、それぞれ１台ずつ記載されているが、それぞれ複数台とすることもできる。また注文受付サーバ３００により実現される機能が取引執行サーバ２００により実現され、注文受付サーバ３００を設けない構成とすることもできる。
【００２３】
＝＝＝機器構成＝＝＝
次に、注文入力端末１００、注文受付サーバ３００及び取引執行サーバ２００のそれぞれのハードウェア構成について説明する。  
注文入力端末１００、注文受付サーバ３００及び取引執行サーバ２００はいずれもコンピュータであり、ハードウェア構成は基本的に同様である。そのため、これらのハードウェア構成を一つのブロック図にまとめて図２に示す。またこれらの各機能をそれぞれ実現するための制御プログラム等やテーブル等について、図３ないし図９に示す。
【００２４】
＜取引執行サーバの構成＞
まず取引執行サーバ２００の構成について説明する。
【００２５】
取引執行サーバ２００は、ＣＰＵ（Central Processing Unit）２１０、メモリ２２０、ポート２３０、記録媒体読取装置２４０、入力装置２５０、出力装置２６０、記憶装置２８０を備える。
【００２６】
ＣＰＵ２１０は取引執行サーバ２００の全体の制御を司るもので、記憶装置２８０に記憶される本実施の形態に係る各種の動作を行うためのコードから構成される取引執行サーバ制御プログラム（特許請求の範囲に記載のプログラムに相当する）８１０をメモリ２２０に読み出して実行することにより、取引執行サーバ２００としての各種機能を実現する。例えばＣＰＵ２１０により取引執行サーバ制御プログラム８１０が実行され、メモリ２２０やポート２３０、入力装置２５０、出力装置２６０、記憶装置２８０等のハードウェア機器と協働することにより、特許請求の範囲に記載の銘柄グループ管理テーブル、取引要求受信部、取引要求記憶部、取引処理部、読出管理テーブル、銘柄グループ更新処理部、受信数比較部、異常検知部が実現される。メモリ２２０は例えば半導体記憶装置により構成することができる。
【００２７】
記録媒体読取装置２４０は、記録媒体５００に記録されているプログラムやデータを読み取るための装置である。読み取られたプログラムやデータはメモリ２２０や記憶装置２８０に格納される。従って、例えば記録媒体５００に記録された取引執行サーバ制御プログラム８１０を、記録媒体読取装置２４０を用いて上記記録媒体５００から読み取って、メモリ２２０や記憶装置２８０に記憶するようにすることができる。  
記録媒体５００としてはフレキシブルディスクや磁気テープ、コンパクトディスク等を用いることができる。記録媒体読取装置２４０は取引執行サーバ２００に内蔵されている形態とすることもできるし、外付されている形態とすることもできる。
【００２８】
記憶装置２８０は、例えばハードディスク装置や半導体記憶装置等とすることができる。記憶装置２８０には、取引執行サーバ制御プログラム８１０や銘柄グループ定義データベース７１０、要件データベース７２０、銘柄データベース７３０、歩みデータベース７４０、取引処理割当データベース７５０が記憶される。なお以下、「データベース」を「ＤＢ」と記す場合もある。
【００２９】
取引執行サーバ制御プログラム８１０は、顧客からの株式売買注文に応じて株式の取引の処理を行うためのプログラムである。取引執行サーバ制御プログラム８１０がＣＰＵ２１０により実行されることにより、取引処理プロセス８１１、運転管理プロセス８１２、モニタリングプロセス８１３、障害検知プロセス８１４が実現される。
【００３０】
入力装置２５０は取引執行サーバ２００へのデータ入力等のために用いられる装置でありユーザインタフェースとして機能する。入力装置２５０としては例えばキーボードやマウス等を用いることができる。  
出力装置２６０は情報を外部に出力するための装置でありユーザインタフェースとして機能する。出力装置２６０としては例えばディスプレイやプリンタ等を用いることができる。
【００３１】
ポート２３０は通信を行うための装置である。例えばネットワーク４００を介して行われる、注文受付サーバ３００や注文入力端末１００等の他のコンピュータとの通信は、ポート２３０を介して行われるようにすることができる。また例えば、取引執行サーバ制御プログラム８１０をポート２３０を通じて他のコンピュータからネットワーク４００を介して受信して、メモリ２２０や記憶装置２８０に記憶するようにすることもできる。
【００３２】
＜注文受付サーバの構成＞
次に注文受付サーバ３００の構成について説明する。注文受付サーバ３００は、ＣＰＵ３１０、メモリ３２０、ポート３３０、記録媒体読取装置３４０、入力装置３５０、出力装置３６０、記憶装置３８０を備える。これらの各装置の機能は、上述した取引執行サーバ２００が備える各装置と同様である。
【００３３】
図５に示すように、注文受付サーバ３００が備える記憶装置３８０には、本実施の形態に係る各種の動作を行うためのコードから構成される注文受付サーバ制御プログラム８２０及び注文受付データベース７００が記憶される。  
ＣＰＵ３１０が注文受付サーバ制御プログラム８２０をメモリ３２０に読み出して実行することにより、注文受付サーバ３００としての各種機能が実現される。注文受付サーバ３００としての各種機能は注文受付処理プロセス８２１により実現される。
【００３４】
＜注文入力端末の構成＞
次に注文入力端末１００の構成について説明する。注文入力端末１００は、ＣＰＵ１１０、メモリ１２０、ポート１３０、記録媒体読取装置１４０、入力装置１５０、出力装置１６０、記憶装置１８０を備える。これらの各装置の機能は、上述した取引執行サーバ２００が備える各装置と同様である。
【００３５】
図３に示すように、注文入力端末１００が備える記憶装置１８０には、本実施の形態に係る各種の動作を行うためのコードから構成される注文入力端末制御プログラム８００が記憶される。  
ＣＰＵ１１０が注文入力端末制御プログラム８００をメモリ１２０に読み出して実行することにより、注文入力端末１００としての各種機能が実現される。
【００３６】
＝＝＝処理の流れ＝＝＝
次に、本実施の形態に係る取引所システムにおける処理の流れについて、図１１ないし図１３を参照しながら説明する。
【００３７】
＜注文受付処理＞
まず注文受付サーバ３００において行われる株式の注文受付処理について図１１を用いて説明する。
【００３８】
注文受付サーバ３００は、注文入力端末１００から注文電文６００を受信すると（S1000）、注文受付番号を付与した注文電文を注文受付データベース７００に格納する（S1010）。注文受付番号は前述した注文番号のことである。
【００３９】
次に注文受付サーバ３００は、ロックが解除されているか否かを確認する（S1020）。詳細は後述するが、取引執行サーバ２００が要件データベース７２０及び銘柄グループ定義データベース７１０を更新中の場合に取引執行サーバ２００によりロックがかけられる。ロックが解除されているか否かは、取引執行サーバ２００が備える記憶装置２８０に記憶されている。ロックが解除されていない場合には、注文受付サーバ３００はロックが解除されるまで待機する。
【００４０】
ロックが解除されている場合には、注文受付サーバ３００は、注文電文６００に含まれる銘柄キーにより銘柄グループ定義データベース７１０を検索し、担当銘柄グループを決定する（S1030）。銘柄キーは、上述したように市場コードと商品コードと銘柄コードとを一つのコードとして纏めたものである。そして注文受付サーバ３００は取引執行サーバ２００に注文データを送信する。そして要件データベース７２０に注文データと要件作成時刻と処理フラグが書き込まれる（S1040）。
【００４１】
そして注文受付サーバ３００は、取引執行サーバ２００において実行される取引処理プロセス８１１に対して、処理依頼の連絡（イベント発行）を行う（S1050）。
【００４２】
＜取引処理＞
次に、取引執行サーバ２００において実行される各取引処理プロセス８１１により行われる株式の取引処理について図１２を用いて説明する。
【００４３】
まず取引処理プロセス８１１は、注文受付サーバ３００から取引処理の連絡イベントを受信する（S2000）。そうすると取引処理プロセス８１１はロックが解除されているか否かを確認する（S2010）。ロックが解除されている場合には、取引処理プロセス８１１は、取引処理割当データベース７５０を参照して処理すべき銘柄グループ番号を特定する（S2020）。そして取引処理プロセス８１１は、要件データベース７２０から、処理すべき銘柄グループ番号をキーに、未処理のレコード（注文データ）を作成時刻の昇順で（古いものから）取り出す（S2030）。
【００４４】
続いて取引処理プロセス８１１は、注文受付サーバ３００が備える注文受付データベース７００を参照して、要件データベース７２０の注文番号をキーに注文を取りだし、売買取引処理を行う（S2040）。そして取引の結果を銘柄データベース７３０及び歩みデータベース７４０に格納する（S2050）。そして要件データベース７２０の当該レコードを「処理済み」に更新する（S2060）。
【００４５】
＜銘柄グループ更新処理＞
次に、取引執行サーバ２００において実行される運転管理プロセス８１２により行われる銘柄グループの更新処理について図１３を用いて説明する。
【００４６】
まず運転管理プロセス８１２は、モニタンリングプロセス８１３や障害検知プロセス８１４から銘柄グループ変更の連絡イベントを受信する（S3000）。ここでは例として、銘柄グループ１に分類される銘柄Ａを、銘柄グループ２に変更するものとして説明する。そうすると運転管理プロセス８１２は、まずロックをかける（S3010）。ロックは、例えば記憶装置２８０に記憶されるロックがかけられているかいないかを示すフラグを、ロックがかけられていることを示す値に書き換えることにより、掛けることができる。
【００４７】
続いて運転管理プロセス８１２は、要件データベース７２０に記憶されている、銘柄Ａに関する株式の注文データについて、銘柄グループ番号を銘柄グループ１から銘柄グループ２に変更する（S3020）。さらに運転管理プロセス８１２は、銘柄グループ定義データベース７１０に記憶されている、銘柄Ａと対応付けられる銘柄グループ番号を、銘柄グループ番号１から銘柄グループ番号２に変更する（S3030）。
【００４８】
そして運転管理プロセス８１２はロックを解除する（S3040）。ロックの解除は、上述したロックがかけられているかいないかを示すフラグを、ロックがかけられていないことを示す値に書き換えることにより行うことができる。
【００４９】
そして運転管理プロセス８１２は、銘柄グループ２に対する株式取引処理を行う取引処理プロセス８１１に対して、イベントを発行して連絡する（S3050）。
【００５０】
＝＝＝第２の実施の形態＝＝＝
上記第１の実施の形態は、以下に記すような第２の実施の形態とすることもできる。  
第２の実施の形態に係る取引所システムの全体構成を図１４に示す。本実施の形態に係る取引所システムは、注文受付サーバ３００と、取引執行サーバ２００と、注文受付データベース７００と、銘柄グループ定義データベース７１０と、要件データベース７２０と、銘柄グループ指示状態データベース７６０と、滞留銘柄臨時割当判定データベース７７０とがネットワーク４００を介して通信可能に接続されてなる。また取引所システムは、ネットワーク４００を介して注文入力端末１００と通信可能に接続される。なお本実施の形態においても、注文受付サーバ３００と取引執行サーバ２００とは、それぞれ複数台とすることもできる。また注文受付サーバ３００により実現される機能が取引執行サーバ２００により実現され、注文受付サーバ３００を設けない構成とすることもできる。
【００５１】
注文入力端末１００は、取引所システムに接続したネットワーク４００を介して接続し、取引所システムに注文電文６００を送信することが可能な端末である。注文電文６００のインタフェース例を図１９に示す。
【００５２】
注文受付サーバ３００は、注文入力端末１００から送信された注文電文６００を受信し、取引所システムの取引執行サーバ２００に中継するサーバである。通常、各注文受付サーバ３００において複数の注文受付処理プロセス８２１が実行されている。
【００５３】
注文受付処理プロセス８２１は、注文入力端末１００から受信した注文電文６００を注文受付ＤＢ７００に格納し、注文電文６００の内容（銘柄コードとそれに付随する情報）から銘柄キーを生成し、銘柄キーによって銘柄グループ定義ＤＢ７１０に従った銘柄グループ番号を決定し、当該銘柄グループ番号の注文登録処理プロセス８１７に売買取引処理を依頼する処理である。その様子を図１５に示す。また売買取引処理の依頼は、図２３に示す要件処理依頼イベントを注文登録処理プロセス８１７に送信することにより行われる。注文登録処理プロセス８１７は取引執行サーバ２００により実行されるプロセスである。通常、１つの注文受付処理プロセス８２１は、複数台の注文入力端末１００を担当して接続する。
【００５４】
一方取引執行サーバ２００においては、銘柄グループ処理プロセス８１５、銘柄グループ変更処理プロセス８１２、活況銘柄臨時割当処理プロセス８１３、銘柄グループ障害臨時割当処理プロセス８１４が実行されている。なお、第１の実施の形態において説明した取引処理プロセス８１１は、銘柄グループ処理プロセス８１５に含まれるプロセスの一つである。すなわち図１５に示すように、本実施の形態に係る銘柄グループ処理プロセス８１５は、注文登録処理プロセス８１７、取引処理プロセス８１１、受付通知作成処理プロセス８１６を含む。また銘柄グループ変更処理プロセス８１２、活況銘柄臨時割当処理プロセス８１３、銘柄グループ障害臨時割当処理プロセス８１４はそれぞれ、第１の実施の形態において説明した運転管理プロセス８１２、モニタンリングプロセス８１３、障害検知プロセス８１４に相当する。
【００５５】
銘柄グループ処理プロセス８１５は、処理の負荷分散を目的に、複数の銘柄をグルーピングしてなる銘柄グループ毎に実行される。銘柄グループ単位の各々には一連の銘柄グループ番号が付与される。個々の銘柄はそれぞれ一意の銘柄グループ番号を持つ。銘柄グループ処理プロセス８１５は、銘柄毎の時間優先の原則を保証するため、これら銘柄グループに対応した単位で、売買取引に関する一連の処理を実施する。一連の処理とは、図１５において例えば注文登録処理の後に取引処理が行われることが示されるように、逐次に行われる各処理のことである。
【００５６】
また銘柄グループ処理プロセス８１５には、担当する銘柄の割当数があらかじめゼロとして定義された予備の銘柄グループ処理プロセス８１５も設けられる。これは、活況銘柄を割当て済みの銘柄グループに移動してしまうと移動先の銘柄グループにおける他銘柄の処理が移動した活況銘柄に巻き込まれて滞留してしまうため、あらかじめ予備銘柄グループを一つ以上用意しておき、活況銘柄の移動が必要になった場合には予備銘柄グループに移動することにより、当該活況銘柄が、銘柄グループ処理プロセス８１５が許す限りの最大限の処理スピードで、なおかつ他銘柄への悪影響を与えずに取引が行えるようにしておくことを可能とするためである。特に自動でオペレーションする活況銘柄臨時割当処理プロセス８１３や銘柄グループ障害臨時割当処理プロセス８１４で、変更先の銘柄グループとして自動的に予備の銘柄グループを選択できるようにするため、銘柄グループ指示状態ＤＢ７６０に予備の銘柄グループ番号にはあらかじめフラグを付与しておくこととする。
【００５７】
銘柄グループ変更処理プロセス８１２は、銘柄グループ変更（銘柄キー指定）処理プロセス８１２と銘柄グループ変更（銘柄グループ指定）処理プロセス８１２とに分けられる。
【００５８】
銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、オペレータによる指示もしくは、活況銘柄臨時割当処理プロセス８１３からの指示の入力を契機に動作する。指示の入力は、図２４に示す銘柄グループ変更（銘柄指定）処理依頼イベントを受信することにより行われる。銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、指定した銘柄キーを、指定した変更元銘柄グループから指定した変更先銘柄グループに割当変更するための処理を行う。
【００５９】
銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、オペレータによる指示もしくは、銘柄グループ障害臨時割当処理プロセス８１４からの指示の入力を契機に動作する。指示の入力は、図２５に示す銘柄グループ変更（銘柄グループ指定）処理依頼イベントを受信することにより行われる。銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、指定した変更元銘柄グループ番号に属する全銘柄の銘柄キーを、指定した変更先銘柄グループに割当変更するための処理を行う。
【００６０】
このような銘柄グループの変更は、例えば特定の銘柄の売買取引が活況になった場合に行われる。その様子を図１６乃至図１８に示す。
【００６１】
一般的に、特定の銘柄の売買取引が活況になるのは、ニュース報道や有事の発生、経営発表、政治的コメント等によってである。売買取引は突発的に活況化し、事前の予測は困難である。またこの場合、１銘柄に通常は想定していない大量の売買注文が短時間に集中して投入される。この結果、平常時に比べて、当該銘柄の取引処理が極端に遅くなるばかりか、同一の銘柄グループに属する他の銘柄の取引処理レスポンスまでもが悪化してしまう。
【００６２】
通常は、突発的な事態に対応すべく、全銘柄に対して上記を想定したシステムリソース配分することがコスト的に非常に困難であるため、注文が集中している銘柄に対しては、手動で「特定条件の注文禁止」または、「売買マッチング時間の制限」という処置がとられる。例えば、「成行注文（値段を指定せず、どんな値段でも売買を成立させる注文条件）の発注を禁止」して売買が成立しにくい条件にしたり、「売買のマッチングを行う時間を取引終了時間の１回に絞る（注文の受付は行うが、取引成立処理は最後の１回のみで実施）」などの措置を行うことで、突発的な事態に対応する。
【００６３】
しかし、上記の措置によって、活況銘柄（取引ニーズが非常に高い銘柄）の取引機会を制限させることとなる。  
このため本実施の形態においては、あらかじめ用意しておく予備の銘柄グループに取引の集中した銘柄をオンライン中に即時に退避する、すなわち銘柄グループの変更を行う。これにより、１銘柄グループの最大性能範囲まで取引サービスを提供することが可能となる。また銘柄グループが別単位になることで、同一銘柄グループに属する他の銘柄のレスポンスの悪化を回避する。また、その監視手段としても、要件ＤＢ７２０のレコード件数を、銘柄キーで検索するだけで可能である。
【００６４】
また、いずれかの銘柄グループが障害になった場合には、障害になった銘柄グループを回復させて、取引を再開する必要があるが、本実施の形態によれば、銘柄グループ単位の回復が迅速に可能となる。これは、本実施の形態においては障害中の銘柄グループの回復を待つ必要がないからである。これにより、取引の中断時間（回復に要する時間）に伴う、取引所利用者の取引機会の損失を減らすことが可能となる。
【００６５】
なお銘柄グループの変更を行う場合に、図１７に示すように、銘柄グループ定義データベース７１０を更新しただけでは、変更前の担当銘柄グループ処理プロセス００１（８１５）内の銘柄Ａの滞留分が解消されないため、同銘柄グループ処理のＢ銘柄やＣ銘柄の処理が遅延し続け、スループットが「即座には」解消されない上、新たに銘柄グループ処理プロセス００２（８１５）に振分けられたＡ銘柄処理が、銘柄グループ処理プロセス００１（８１５）に滞留中のＡ銘柄情報を追い越して処理されてしまうおそれがあり、「銘柄単位で受付順序を保証して処理を行う」とのニーズが守れなくなる。
【００６６】
そのため本実施の形態においては、図１８に示すように、要件ＤＢ７２０で論理的に担当替えを実施し、旧担当銘柄グループがイベントを受信しても処理は行わず、イベントを破棄するようにしている。イベントの破棄は極めて迅速に行うことができるため、滞留は「即時」に解消することができる。また、本実施の形態においては、要件ＤＢ７２０内の要件登録時刻は更新しないため、振分変更後も「銘柄単位で受付順序を保証して処理を行う」ことが容易に実現可能である。
【００６７】
図１４に戻って、活況銘柄臨時割当処理プロセス８１３は、定期的なタイマ等を契機に起動し、要件ＤＢ７２０から、銘柄毎の未処理レコードの件数をカウントし、滞留銘柄臨時割当判定ＤＢ７７０に記憶された閾値（判定値）を超えた場合に銘柄グループ変更（銘柄キー指定）処理プロセス８１２を呼び出す処理である。この際、変更先銘柄グループは予備の銘柄グループを指定する。
【００６８】
銘柄グループ障害臨時割当処理プロセス８１４は、定期的なタイマ等を契機に起動し、システムログやシステムジャーナルなどから、銘柄グループが障害になったことを検知し、障害中の銘柄グループの全銘柄を、予備銘柄グループに移動するための処理を行う。起動契機は、ＯＳ（Operating System）やＣＰＵの監視処理から直接システムコールで呼ばれた際など、障害を正確に検知する手段ならば何でも良い。
【００６９】
注文受付データベース７００は、受信した注文電文６００を格納するデータベースである。注文受付データベース７００を図２０に示す。注文受付データベース７００には、注文登録処理プロセス８１７が処理するためのキー情報として、注文受付番号や銘柄キーなどが記憶される。注文受付番号は、銘柄毎の注文受付順序を示す番号が付与できれば、発注者に送信する受付通知の受付番号として機能する。例えば、複数の注文受付処理プロセス８２１による採番競合を避けるため、発注者コード別かつ銘柄別の番号を採番し、銘柄別の受付順序の採番は、注文登録処理プロセス８１７で行うようにすることもできる。
【００７０】
要件データベース７２０は、銘柄グループ番号、銘柄キー、および処理順序を示す通番（例えば要件登録時刻）を備える。要件データベース７２０を図２２に示す。ここで、銘柄グループ変更時には、銘柄グループ番号の列のみを変更するが、銘柄キーおよび処理順序が更新されないため、銘柄グループ内に滞留する処理途上のイベント銘柄に対する銘柄グループ変更を行っても、本来の受信順の正しい順番で処理を継続することを可能とする。例えば要件登録時刻は、当該レコードをインサート時にＤＢシステムが自動で設定する。
【００７１】
なお要件登録時刻は論理的に採番した番号とすることもできる。処理順序を守りたい昇順であれば良いからである。これは、ＤＢシステムが自動的に登録時刻を設定してくれない処理系システムの場合に有効である。この場合、注文登録の機能名では「電文受信時刻」などとする。これは、例えば「銘柄別発注者別番号」では銘柄別の順序にならない（発注者毎の同一番号がある）ためである。
【００７２】
しかし、銘柄グループ処理プロセス８１５における一連の処理において、前段機能が１機能に限られる場合に限り、前段機能が処理順に採番している通番があるとすれば、この番号を採用することが可能である。例えば、注文登録処理から取引処理の要件では、注文登録処理で採番した銘柄別受付番号を要件登録時刻として採用したほうが自然である。これは、そもそもの目的が、銘柄別の受付順序を保証して処理をすることにあるためである。また、取引処理の後続機能向けの要件では、銘柄別取引通番を採番しているため、これが採用できる。
【００７３】
また要件ＤＢ７２０は、性能の観点から、依頼先機能名毎に要件ＤＢ７２０そのものを分割することも考えられる。これにより、ＤＢシステムの負荷を、機能単位で分散させることも可能となる。その場合は、依頼先機能名の列を消去し、ＤＢ名を”要件（注文登録）ＤＢ７２０”及び”要件（取引処理）ＤＢ７２０”などに分ける。
【００７４】
また、参照時に依頼先機能名を用いている場合はＤＢ名を分ける。監視処理など複数機能名の処理を行う場合は、機能数分だけのＤＢ数分の検索を繰り返して実施する。
【００７５】
また、処理フラグの列は、下記の通り、不要とすることも考えられる。すなわち、要件処理の完了時に「処理済」で更新するのではなく、行をデリートとする。加えて検索条件の「未処理」の条件も不要とする。
【００７６】
銘柄グループ定義データベース７１０は、それぞれの銘柄グループに、自銘柄グループが担当して取引処理を行う銘柄キーの対応を定義するデータベースである。銘柄グループ定義データベース７１０を図２１に示す。全ての銘柄キーに対して、銘柄キー毎に一意の銘柄グループ番号を設定する。予備銘柄グループは割当銘柄数をゼロとする。通常割当の銘柄グループは、可能な限り、見込みを含めた１日のピークトラフィック時や総処理件数が平滑化されるように、均等に割当を行う。
【００７７】
銘柄グループ指示状態データベース７６０は、銘柄グループ変更時の排他制御に用いるデータベースである。また銘柄グループ指示状態データベース７６０は、銘柄グループ毎に割当状態を示す。銘柄グループ指示状態データベース７６０を図２６に示す。なお図２６において、「予備」と記載された銘柄グループはあらかじめ割当銘柄数をゼロで定義した銘柄グループである。この銘柄グループは臨時変更の変更先となる。また「通常割当」と記載された銘柄グループはあらかじめ割当銘柄数を１以上で定義した銘柄グループである。通常は数十〜数百銘柄の割り当てがされる。「臨時割当」と記載された銘柄グループは、開始時は「予備」であったが臨時変更により１銘柄以上が割り当て済みの銘柄グループである。「障害中」と記載された銘柄グループは障害中の銘柄グループである。なお、自動でオペレーションする活況銘柄臨時割当処理プロセス８１３や銘柄グループ障害臨時割当処理プロセス８１４では、予備グループにしか臨時割当を行わないこととする。また滞留監視（活況銘柄の自動臨時割当）は、臨時割当の銘柄グループに対しては行わない。
【００７８】
滞留銘柄臨時割当判定データベース７７０は、銘柄キー毎に滞留許容値（判定値）を設定するデータベースである。滞留銘柄臨時割当判定データベース７７０を図２７に示す。当該許容値はあらかじめ設定しておく。この滞留許容値を超えて滞留が発生した場合は活況銘柄と判断し、自動的な銘柄グループ変更により予備グループに移動し、「他銘柄への悪影響の解消」および「活況銘柄の単体処理性能の向上」を図ることができる。  
この滞留許容値は、銘柄キー別の設定のみではなく銘柄キー別かつ機能別の設定を持って判定することもできる。例えば注文登録処理プロセス８１７の滞留許容値を１００と設定したり、取引処理プロセス８１１の滞留許容値を５００に設定することができる。  
監視対象とされる銘柄グループは通常割当の銘柄グループのみとすることができる。例えば、臨時割当中の銘柄グループは活況銘柄として１銘柄が割当済みであるため、これ以上変更することができないからである。また、銘柄グループ障害によりグループ指定で変更して臨時割当となる場合があるが、これも障害中に溜まった要件の滞留に一定時間がかかる為、監視対象外とする。
【００７９】
＝＝＝処理の流れ＝＝＝
次に、本実施の形態に係る取引所システムにおける処理の流れについて、図２８ないし図３４を参照しながら説明する。
【００８０】
＜注文受付処理＞
まず注文受付サーバ３００において行われる株式の注文受付処理について図２８を用いて説明する。
【００８１】
注文受付処理プロセス８２１は、注文入力端末１００から送信された注文電文６００を受信する（S4000）。そうすると注文受付処理プロセス８２１は、銘柄グループ指示状態ＤＢ７６０の全体を共用取得する（S4010）。ここで、銘柄グループ変更処理プロセス８１２が変更処理中の場合は変更処理が終了するまで待つ。なお共用取得は、共用取得同士は待たず、別プロセスが排他取得している間は待つ。排他取得は、別プロセスが排他取得もしくは共用取得している間は待つ。
【００８２】
続いて注文受付処理プロセス８２１は、S4000で受信した注文電文６００に記載されたシステムコード（第１の実施の形態の市場コードに相当する）、商品コード、銘柄コード、取引種別から銘柄キーを生成する（S4020）。そして注文受付処理プロセス８２１は、銘柄グループ定義ＤＢ７１０をS4020で生成した銘柄キーで検索し、当該銘柄が属する銘柄グループ番号を決定する（S4030）。そして受信した注文電文６００を注文受付ＤＢ７００に格納する（S4040）。ここで、S4020で取得した銘柄キー及び採番する注文受付番号は、「注文受付処理毎の一連通番」、「銘柄別かつ発注者別番号」などが考えられる。「注文受付処理毎の一連通番」の場合のキー情報は、注文受付処理番号及び注文受付番号により構成され、「銘柄別かつ発注者別番号」の場合のキー情報は、銘柄キー、発注者コード及び注文受付番号により構成される。なお、注文受付番号は注文受付順序を保証するものではない。受付順序は、要件ＤＢ７２０の依頼登録時刻によって決定される。これは、注文受付処理で銘柄順序を決定しようとすると、「銘柄別番号」の正確な採番が必要になり（排他処理で競合）、注文受付処理の段階で活況銘柄による遅延処理が発生してしまう可能性があるからである。
【００８３】
続いて注文受付処理プロセス８２１は、要件ＤＢ７２０に要件処理依頼イベント（注文登録）を格納する（S4050）。依頼先機能名は「注文登録」を設定する。ただし機能毎にＤＢを分割する場合は不要である。ここで、要件登録時刻はＤＢシステムが自動設定し、銘柄キーはS4020で取得した銘柄キーを使用し、銘柄グループ番号はS4030で取得したグループ番号を使用する。依頼内容は、後続処理の注文登録が必要な情報、例えば注文受付ＤＢ７００のキー情報などが含まれる。処理フラグは「未処理」が設定される。
【００８４】
そして注文受付処理プロセス８２１は、S4050で設定した銘柄グループ番号および依頼先機能宛に、要件処理依頼イベント（注文登録）を送信する（S4060）。要件処理依頼イベントを図２３に示す。なお、送信先オブジェクト名（キュー名）は、銘柄グループ番号および依頼先機能名の組み合わせで一意に取得、生成できるものとする。
【００８５】
＜注文登録処理＞
次に取引執行サーバ２００において行われる注文登録処理について図２９を用いて説明する。
【００８６】
まず注文登録処理プロセス８１７は、要件処理依頼イベント（注文登録）を受信する（S5000）。そうすると注文登録処理プロセス８１７は、要件処理依頼イベントに記載された情報により、自銘柄グループ番号、および銘柄キーを取得する。なおプロセス毎に自銘柄グループの銘柄グループ番号が定義されている場合には、依頼イベント中の銘柄グループ番号は無くても良い。
【００８７】
続いて注文登録処理プロセス８１７は、銘柄グループ指示状態ＤＢ７６０を、自銘柄グループ番号の銘柄グループ番号で検索し、共用取得する（S5010）。そして銘柄グループ定義ＤＢ７１０を、要件処理依頼イベントより取得した銘柄キーで検索し、銘柄グループ番号を取得する（S5020）。なおS5020の処理はかならずしも必須ではない。これは、銘柄グループ変更元に無駄なイベントが残留するため、その無駄なイベントを要件ＤＢ７２０アクセス負荷を誘発することなく削除するための処理である。当該チェック実施によりイベントを削除せずに要件ＤＢ７２０を検索しても良いが、既に銘柄グループが変更された変更元銘柄グループの場合は、検索結果がゼロ件になる。銘柄グループ定義ＤＢ７１０をメモリ上で仮想管理している場合には、当該チェック処理の負荷が少ないため、実施することもできる。
【００８８】
次に注文登録処理プロセス８１７は、取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が、自プロセスの銘柄グループ番号と異なるか否かを判定する（S5030）。取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が自プロセスの銘柄グループ番号と異なる場合は、当該イベントの対象銘柄は既に割当変更されているため、”ＹＥＳ”に進み当該イベントによる処理は行わない。
【００８９】
取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が自プロセスの銘柄グループ番号と同じ場合は”ＮＯ”に進み、注文登録処理プロセス８１７は、要件ＤＢ７２０から、下記の条件で先頭１件を取得する（S5040）。ここで、ｎ件取得して処理しても良いが、その後、同じ銘柄に対してｎー１件分の処理済み（空振り）イベントを受信する。同一銘柄をｎ件を纏めて処理することにより性能の向上を図ることができる。ここで上述した条件とは、依頼先機能名が注文登録で、かつ、銘柄グループ番号がS5000で取得の自銘柄グループ番号と同一で、銘柄キーがS5000で取得の銘柄キーと同一で、処理フラグが未処理であるレコードを、要件登録時刻順に先頭１件（又はｎ件）取得する。
【００９０】
続いて注文登録処理プロセス８１７は、取得した要件ＤＢ７２０のレコードの処理依頼情報部に従い、注文登録処理を行う（S5050）。具体的には、要件ＤＢ７２０中の注文登録依頼内容に従い、注文受付ＤＢ７００を依頼キー内容で検索し、注文登録チェックを行う。エラーの場合は受付通知作成処理プロセス８１６にエラー通知作成依頼を行う。さらに銘柄別受付番号を採番し、注文・板ＤＢに当該銘柄別受付番号および当該注文情報を格納する。
【００９１】
次に注文登録処理プロセス８１７は、注文登録処理プロセス８１７の後続処理は２機能存在するため、要件ＤＢ７２０には依頼先機能名別の２件登録する（S5060）。なお後続処理の数は、処理結果、すなわちエラーになったか、正常だったか、取引が成立したか、取引が成立しなかったかなどや、注文登録処理や取引処理等の機能数毎に異なる。本実施の形態においては、要件ＤＢ７２０に要件処理依頼イベント（取引処理）を格納すると共に、要件処理依頼イベント（受付通知作成処理）も格納する。具体的には、要件処理依頼イベント（取引処理）を格納する場合には、依頼先機能名は「取引処理」を設定する。なお機能毎にＤＢを分割する場合は不要である。要件登録時刻はＤＢシステムが自動設定し、銘柄キーはS5000で取得した銘柄キーを使用し、銘柄グループ番号はS5000で取得したグループ番号を使用し、依頼内容は、後続処理の取引処理が必要な情報、例えば注文・板ＤＢのキー情報などを記載する。処理フラグは「未処理」を設定する。また要件処理依頼イベント（受付通知作成処理）を格納する場合には、依頼先機能名は「受付通知作成処理」を設定する。なお、機能毎にＤＢを分割する場合は不要である。要件登録時刻はＤＢシステムが自動設定する。銘柄キーはS5000で取得した銘柄キーを使用し、銘柄グループ番号はS5000で取得した銘柄グループ番号を使用し、依頼内容は、後続処理の受付通知作成処理が必要な情報、例えば注文・板ＤＢのキー情報などを記載する。処理フラグは「未処理」を設定する。
【００９２】
続いて注文登録処理プロセス８１７は、同一の銘柄グループ番号の依頼先機能宛に、要件処理依頼イベントを送信する（S5070）。具体的には、同一銘柄グループの取引処理宛てに「取引処理依頼」イベントを送信すると共に、同一銘柄グループの受付通知作成宛てに「受付通知作成処理」イベントを送信する。  
そして注文登録処理プロセス８１７は、上記で処理が終了した要件ＤＢ７２０の「処理済みフラグ」を「処理済み」に更新する（S5080）。なおS5040の取り出し件数に従い、ｎ件の場合もある。
【００９３】
なお、図示はしないが、受付通知作成処理プロセス８１６は、要件処理依頼イベント（受付通知作成処理）を受信すると、要件ＤＢ７２０中の受付通知作成依頼内容に従い、注文・板ＤＢを依頼キー内容で検索して取得し、受付通知電文を編集し、受付通知ＤＢにインサートする。そして入力端末ＩＤ毎に担当する通知送信処理が存在し、当該プロセス宛ての送信処理をコールする。注文受付サーバ３００の通知送信処理は、上記契機、あるいはタイマ契機で起動し、受付通知ＤＢから取得した注文受付通知を、ネットワーク４００を介して注文入力端末１００に送信する。そして受付通知作成処理プロセス８１６は、上記で処理が終了した要件ＤＢ７２０の「処理済みフラグ」を「処理済み」に更新する。
【００９４】
＜取引処理＞
次に取引執行サーバ２００において行われる取引処理について図３０を用いて説明する。
【００９５】
まず取引処理プロセス８１１は、要件処理依頼イベント（取引処理）を受信する（S6000）。そうすると取引処理プロセス８１１は、要件処理依頼イベントに記載された情報により、自銘柄グループ番号、および銘柄キーを取得する。なおプロセス毎に自銘柄グループの銘柄グループ番号が定義されている場合には、依頼イベント中の銘柄グループ番号は無くても良い。
【００９６】
続いて取引処理プロセス８１１は、銘柄グループ指示状態ＤＢ７６０を、自銘柄グループ番号の銘柄グループ番号で検索し、共用取得する（S6010）。そして銘柄グループ定義ＤＢ７１０を、イベントより取得した銘柄キーで検索し、銘柄グループ番号を取得する（S6020）。なおS6020の処理はかならずしも必須ではない。これは、銘柄グループ変更元に無駄なイベントが残留するため、その無駄なイベントを要件ＤＢ７２０アクセス負荷を誘発することなく削除するための処理である。当該チェック実施によりイベントを削除せずに要件ＤＢ７２０を検索しても良いが、既に銘柄グループが変更された変更元銘柄グループの場合は、検索結果がゼロ件になる。銘柄グループ定義ＤＢ７１０をメモリ上で仮想管理している場合には、当該チェック処理の負荷が少ないため、実施することもできる。
【００９７】
次に取引処理プロセス８１１は、取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が、自プロセスの銘柄グループ番号と異なるか否かを判定する（S6030）。取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が自プロセスの銘柄グループ番号と異なる場合は、当該イベントの対象銘柄は既に割当変更されているため、”ＹＥＳ”に進み当該イベントによる処理は行わない。
【００９８】
取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が自プロセスの銘柄グループ番号と同じ場合は”ＮＯ”に進み、取引処理プロセス８１１は、要件ＤＢ７２０から、下記の条件で先頭１件を取得する（S6040）。ここで、ｎ件処理しても良いが、その後同じ銘柄に対してｎー１件分の処理済み（空振り）イベントを受信する。同一銘柄をｎ件を纏めて処理することにより性能の向上を図ることができる。ここで上述した条件とは、依頼先機能名が取引処理で、かつ、銘柄グループ番号がS6000で取得した自銘柄グループ番号と同一で、銘柄キーがS6000で取得した銘柄キーと同一で、処理フラグが未処理であるレコードを、要件登録時刻順に先頭１件（ｎ件）を取得する。
【００９９】
続いて取引処理プロセス８１１は、取得した要件ＤＢ７２０のレコードの処理依頼情報部に従い、取引処理を行う（S6050）。具体的には、要件ＤＢ７２０の注文・板ＤＢのキー情報に従って該当レコードを取得し、売注文と買注文のマッチング処理を行う。マッチング処理の結果は、注文・板ＤＢ（注文単位で管理するＤＢ）と銘柄ＤＢ７３０（銘柄毎の最新情報を持つデータベース）および歩みＤＢ７４０（取引履歴を随時インサートするデータベース）に格納する。
【０１００】
上記S6050で約定が成立しなかった場合は、取引処理プロセス８１１は、相場配信情報作成プロセス、及び市況情報作成プロセス宛ての２機能の要件ＤＢ７２０を作成し、約定が成立した場合は、上記に加えて、約定通知作成プロセスの３機能宛の要件ＤＢ７２０を作成する（S6060）。約定とは、売注文と買注文がマッチングして売買取引が成立することをいう。要件処理依頼イベント（相場配信情報作成）を格納する場合には、依頼先機能名は「相場配信情報作成」を設定する。なお機能毎にＤＢを分割する場合は不要である。要件登録時刻はＤＢシステムが自動設定し、銘柄キーはS6000で取得した銘柄キーを使用し、銘柄グループ番号はS6000で取得した銘柄グループ番号を使用し、依頼内容は、後続処理の相場配信情報作成処理が必要な情報、例えば歩みＤＢのキー情報などを記載する。処理フラグは「未処理」を設定する。要件処理依頼イベント（市況情報作成）を格納する場合には、依頼先機能名は「市況情報作成」を設定する。なお機能毎にＤＢを分割する場合は不要である。要件登録時刻はＤＢシステムが自動設定し、銘柄キーはS6000で取得した銘柄キーを使用し、銘柄グループ番号はS6000で取得した銘柄グループ番号を使用し、依頼内容は、後続処理の市況情報作成処理が必要な情報、例えば歩みＤＢのキー情報に加えて注文・板ＤＢのキー情報などを記載する。処理フラグは「未処理」を設定する。要件処理依頼イベント（約定通知作成）を格納する場合には、依頼先機能名は「約定通知作成」を設定する。なお機能毎にＤＢを分割する場合は不要である。要件登録時刻はＤＢシステムが自動設定し、銘柄キーはS6000で取得した銘柄キーを使用し、銘柄グループ番号はS6000で取得した銘柄グループ番号を使用し、依頼内容は、後続処理の約定通知作成処理が必要な情報、例えば注文・板ＤＢのキー情報などを記載する。処理フラグは「未処理」を設定する。
【０１０１】
続いて取引処理プロセス８１１は、振分先の銘柄グループ番号の依頼先機能宛に、要件処理依頼イベントを送信する（S6070）。具体的には、同一銘柄グループの相場配信情報作成プロセス宛てに「相場配信情報作成依頼」イベントを送信すると共に、同一銘柄グループの市況情報作成プロセス宛てに「市況情報作成依頼」イベントを送信する。また約定が成立した場合は、上記に加えて、同一銘柄グループの約定通知作成プロセス宛てに「約定通知作成依頼」イベントを送信する。  
そして取引処理プロセス８１１は、上記で処理が終了した要件ＤＢ７２０の「処理済みフラグ」を「処理済み」に更新する（S6080）。なおS6040の取り出し件数に従い、ｎ件の場合もある。
【０１０２】
なお、図示はしないが、相場配信情報作成プロセスは、要件処理依頼イベント（相場配信情報作成依頼）を受信すると、歩みＤＢ７４０を依頼キー内容で検索して取得し、相場配信情報電文を編集し、相場配信情報ＤＢにインサートする。なお相場配信サーバの相場配信処理は一定間隔で相場配信情報ＤＢの内容を送信する。
【０１０３】
また約定通知作成処理プロセスは、要件処理依頼イベント（約定通知作成処理）を受信すると、注文・板ＤＢを依頼キー内容で検索して取得し、約定通知電文を編集し、約定通知ＤＢにインサートする。また入力端末ＩＤ毎に担当する通知送信処理が存在し、当該プロセス宛ての送信処理をコールする。注文受付サーバ３００の通知送信処理は、上記契機又はタイマ契機で起動し、約定通知ＤＢから取得した注文約定通知を、ネットワークを介して注文入力端末１００に送信する。
【０１０４】
＜銘柄グループ変更（銘柄キー指定）処理＞
次に取引執行サーバ２００において行われる銘柄グループ変更（銘柄キー指定）処理について図３１を用いて説明する。
【０１０５】
まず銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、要件処理依頼イベント（銘柄グループ変更（銘柄キー指定））を受信する（S7000）。図２４にイベント情報を示す。そうすると銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、銘柄グループ指示状態ＤＢ７６０を、S7000で取得した変更元グループ番号と変更先グループ番号で排他取得する（S7010）。つまり当該変更処理中は注文受付処理および変更元と変更先の銘柄グループに属する銘柄グループ処理を待たせる。
【０１０６】
続いて銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、銘柄グループ定義ＤＢ７１０を、S7000で取得した変更対象銘柄キーで検索して銘柄グループ番号を取得する（S7020）。そしてS7020で取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が、変更元銘柄グループ番号と同一かチェックする（S7030）。異なる場合は、当該イベントで指定した変更対象銘柄キーは既にいずれかの銘柄グループへの変更処理済みであるため、エラーメッセージを出力して終了する（S7100）。
【０１０７】
一方、同一の場合は、S7020で取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号を、変更先銘柄グループで更新する（S7040）。そしてS7010で取得した、変更先グループ番号の銘柄グループ指示状態ＤＢ７６０のレコードの割当状態が予備であるかチェックする。そして、予備（＝銘柄割当数がゼロ）の場合は、当該変更処理によって、銘柄割当数が１以上になるため、割当状態を臨時割当に更新する（S7050）。
【０１０８】
続いて銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、要件ＤＢ７２０の内容を、銘柄グループ変更の指示に従い一括更新するためにレコードを抽出する（S7060）。具体的には、要件ＤＢから、銘柄グループ番号が、S7000で取得した変更元銘柄グループ番号と同一で、かつ、銘柄キーが、S7000で取得した変更対象銘柄キーと同一で、かつ、処理フラグが未処理であるレコードを要件登録時刻順に検索して取得する。
【０１０９】
その結果、該当するレコードが１件も無ければ処理を終了し（S7070）、１件以上あれば、S7060で取得した要件ＤＢ７２０のレコードのうち、銘柄グループ番号だけを、変更先銘柄グループ番号で更新する（S7080）。
【０１１０】
そして銘柄グループ変更（銘柄キー指定）処理プロセス８１２は、当該依頼イベントは変更先銘柄グループには送信されていないため、本処理で送付する（S7090）。つまり変更先銘柄グループ番号の依頼先機能名宛てに、要件処理依頼イベントを送信する。この際の銘柄グループ番号は変更後の銘柄グループ番号である。
【０１１１】
＜銘柄グループ変更（銘柄グループ指定）処理＞
次に取引執行サーバ２００において行われる銘柄グループ変更（銘柄グループ指定）処理について図３２を用いて説明する。
【０１１２】
まず銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、要件処理依頼イベント（銘柄グループ変更（銘柄グループ指定））を受信する（S8000）。図２５にイベント情報を示す。そうすると銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、銘柄グループ指示状態ＤＢ７６０を、S8000で取得した変更元グループ番号と変更先グループ番号で排他取得する（S8010）。つまり当該変更処理中は注文受付処理および変更元と変更先の銘柄グループに属する銘柄グループ処理を待たせる。
【０１１３】
続いて銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、銘柄グループ定義ＤＢ７１０を、銘柄グループ番号が変更元銘柄グループと一致するレコードを検索する（S8020）。
【０１１４】
その結果、該当するレコードが１件も無ければエラーメッセージを出力して処理を終了し（S8110）、該当するレコードがあれば、変更元銘柄グループに割当られていた銘柄数分だけ更新処理を行う（S8040、S8050）。
【０１１５】
そしてS8010で取得した、変更先グループ番号の銘柄グループ指示状態ＤＢ７６０のレコードの割当状態が予備であるかチェックする。そして、予備（＝銘柄割当数がゼロ）の場合は、当該変更処理によって、銘柄割当数が１以上になるため、割当状態を臨時割当に更新する（S8060）。
【０１１６】
続いて銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、要件ＤＢ７２０の内容を、銘柄グループ変更の指示に従い一括更新するためにレコードを抽出する（S8070）。具体的には、要件ＤＢから、銘柄グループ番号が、S8000で取得した変更元銘柄グループ番号と同一で、かつ、処理フラグが未処理であるレコードを要件登録時刻順に検索して取得する。
【０１１７】
その結果、該当するレコードが１件も無ければ処理を終了し（S8080）、１件以上あれば、S8070で取得した要件ＤＢ７２０のレコードのうち、銘柄グループ番号だけを、変更先銘柄グループ番号で更新する（S8090）。
【０１１８】
そして銘柄グループ変更（銘柄グループ指定）処理プロセス８１２は、当該依頼イベントは変更先銘柄グループには送信されていないため、本処理で送付する（S8100）。つまり変更先銘柄グループ番号の依頼先機能名宛てに、要件処理依頼イベントを送信する。この際の銘柄グループ番号は変更後の銘柄グループ番号である。
【０１１９】
＜活況銘柄臨時割当処理＞
次に取引執行サーバ２００において行われる活況銘柄臨時割当処理について図３３を用いて説明する。なお活況銘柄臨時割当処理は一定時間のタイマ等で起動する。
【０１２０】
まず活況銘柄臨時割当処理プロセス８１３は、銘柄グループ指示状態ＤＢ７６０から、銘柄グループ番号順にレコードを共用取得する（S9000）。そして取得した銘柄グループ指示状態レコードの割当状態が通常割当か否かを判定する（S9010）。なお、通常に銘柄の割り当てを行った銘柄グループを監視対象とする。予備や障害中の銘柄グループは監視しなくても良い。また臨時割当中の銘柄グループは、活況銘柄として１銘柄が割当済みであるため、これ以上変更することができないからである。グループ指定で変更して臨時割当となる場合もあるが、これも障害中に溜まった要件の滞留に一定時間がかかる為、監視対象外とする。
【０１２１】
続いて活況銘柄臨時割当処理プロセス８１３は、要件ＤＢ７２０を銘柄グループ番号がS9000で取得した銘柄グループ番号と同一で、かつ処理フラグが未処理であるレコードを銘柄キー毎にカウントする（S9020）。これは活況銘柄を探すためである。なお機能毎に要件ＤＢ７２０を分割した場合には、機能１から機能ｎのそれぞれの要件ＤＢ７２０でカウントする。またカウント方法は、銘柄キー毎かつ機能毎にカウントして、機能毎の判定処理を行うようにすることもできる。この場合は、滞留銘柄臨時割当判定レコードの許容値は機能毎に設定することも可能になる。一般的に、負荷の大きな取引処理機能が滞留しやすいため、この取引処理機能に絞って監視することも有効である。一般的に、負荷の小さな機能ではあまり滞留しない。
【０１２２】
続いて活況銘柄臨時割当処理プロセス８１３は、S9020で上記カウント数の大きい銘柄を優先に、滞留銘柄臨時割当判定ＤＢ７７０を銘柄キーで検索する（S9030）。
【０１２３】
そして活況銘柄臨時割当処理プロセス８１３は、取得した滞留銘柄臨時割当判定レコードの滞留許容値で、滞留許容値がカウント値よりも小さいか否かを判定する（S9040）。つまり銘柄毎に設定したそれぞれの許容滞留件数を超えてないかどうかをチェックする。  滞留許容値がカウント値よりも小さい場合は”ＹＥＳ”に進み、許容値を超えた銘柄（＝活況銘柄）を、予備銘柄グループに臨時割当するために、予備の銘柄グループ番号を検索する（S9060）。具体的には、銘柄グループ指示状態ＤＢ７６０から、割当状態が予備のコードを検索し、先頭の１件を排他取得する。予備の銘柄グループ番号が見つからない場合は処理を終了する（S9070）。
【０１２４】
予備の銘柄グループ番号が見つかった場合には、活況銘柄を予備銘柄グループに臨時割当するために、銘柄グループ変更（銘柄キー指定）を送信する（S9080）。すなわち、図２４の銘柄グループ変更（銘柄キー指定）処理依頼イベントの、変更対象銘柄キーに上記S9030の銘柄キー、変更元銘柄グループ番号にS9000の銘柄グループ番号、変更先銘柄グループ番号にS9060の銘柄グループ番号をそれぞれ設定して、銘柄グループ変更（銘柄キー指定）処理宛に、銘柄グループ変更（銘柄キー指定）イベントを送信する。
【０１２５】
そして活況銘柄臨時割当処理プロセス８１３は、要件ＤＢ７２０で該当する銘柄キー数分だけ、活況銘柄チェックを繰り返す（S9050）。さらに上記処理を銘柄グループ数分だけ繰り返す（S9090）。
【０１２６】
＜銘柄グループ障害臨時割当処理＞
次に取引執行サーバ２００において行われる銘柄グループ障害臨時割当処理について図３４を用いて説明する。
【０１２７】
まず銘柄グループ障害臨時割当処理プロセス８１４は、前回起動時に監視済みのシステムログの続きから、銘柄グループ障害を連絡するメッセージが存在するかどうか走査する（S10000）。検知する方法はどのような方法とすることもできる。ＣＰＵやＯＳ等から連絡を受けても良いし、システムログを監視するようにすることもできる。
【０１２８】
続いて銘柄グループ障害臨時割当処理プロセス８１４は、銘柄グループ障害の発生を示すメッセージが存在したか否かをチェックする（S10010）。ここでは、障害メッセージ中から障害になった銘柄グループ番号を取得できるものとする。メッセージが存在しなかった場合には処理を終了する（S10010）。
【０１２９】
メッセージが存在した場合には、障害メッセージの出力内容より、障害銘柄グループ番号を取得する（S10020）。  
そしてS10020で取得した銘柄グループ番号で、銘柄グループ指示状態ＤＢ７６０を排他取得する（S10030）。さらにS10020で取得した銘柄グループ指示状態レコードの割当状態を障害中に更新する（S10040）。
【０１３０】
そして銘柄グループ障害臨時割当処理プロセス８１４は、S10020で取得した銘柄グループ指示状態レコードの更新前の割当状態が予備であったかどうかチェックする（S10050）。予備の場合は、割当られている銘柄数がゼロであるため、以降の処理を終了する（S10050）。
【０１３１】
予備でない場合は、障害中の銘柄グループに属する全銘柄を使用可能な銘柄グループ（＝予備銘柄グループ）に移すため、銘柄グループ指示状態ＤＢ７６０から、割当状態が予備のレコードを検索し、先頭の１件を排他取得する（S10060）。そして予備の銘柄グループの有無をチェックする（S10070）。  
その結果、予備の銘柄グループが無しの場合（＝全て割り当て済み）は、処理を終了する（S10070）。
【０１３２】
一方、予備の銘柄グループがありの場合は、障害中の銘柄グループの全銘柄を、予備銘柄グループに臨時割当するために、銘柄グループ変更（銘柄グループ指定）を送信する（S10080）。具体的には、図２５に示す銘柄グループ変更（銘柄グループ指定）処理依頼イベントの、変更元銘柄グループ番号にS10020の銘柄グループ番号、変更先銘柄グループ番号にS10060の銘柄グループ番号を設定して、銘柄グループ変更（銘柄グループ指定）処理宛に銘柄グループ変更（銘柄グループ指定）イベントを送信する。
【０１３３】
＝＝＝第３の実施の形態＝＝＝
上記第２の実施の形態は、以下に記すような第３の実施の形態とすることもできる。  
第３の実施の形態は、第２の実施の形態と比べて、注文登録処理と取引処理とが異なる。第３の実施の形態に係る注文登録処理及び取引処理の流れをそれぞれ図３８及び図３９に示す。第３の実施の形態によれば、より一層の処理の高速化を図ることが可能となる。
【０１３４】
まず注文登録処理について図３８を参照しながら説明する。  
まず注文登録処理プロセス８１７は、要件処理依頼イベント（注文登録）を受信する（S11010）。本実施の形態においては、要件処理依頼イベント（注文登録）には図２３に示したような”銘柄グループ番号”や”銘柄キー”等の情報は含まれていなくても良い。銘柄グループ番号は自分のプロセス定義として起動時から保持しており、銘柄キーは検索で使用しないからである。本実施の形態においては要件の検索は銘柄グループ番号のみで行う。よって銘柄グループ変更時、変更元グループには無効イベントを受信するが、要件ＤＢ７２０の検索結果がゼロ件になるだけで実害がない。
【０１３５】
続いて注文登録処理プロセス８１７は、銘柄グループ指示状態ＤＢ７６０を共用取得する（S11020）。そして注文登録処理プロセス８１７は、図３５に示す要件ＤＢ７２０から、下記の条件で先頭１件を取得する（S11030）。ここで、ｎ件取得して処理しても良いが、その後、同じ銘柄に対してｎー１件分の処理済み（空振り）イベントを受信する。同一銘柄をｎ件を纏めて処理することにより性能の向上を図ることができる。ここで上述した条件とは、銘柄グループ番号が自銘柄グループ番号と同一で、処理フラグが未処理であるレコードを、要件登録時刻順に先頭１件（又はｎ件）取得する。注文登録処理プロセス８１７は、何かイベントがきたら自分の担当を要件がないかどうか検索する。銘柄キーによる変更チェックもしない。銘柄グループ変更は頻繁に起こるわけではないからである。
【０１３６】
続いて注文登録処理プロセス８１７は、取得した要件ＤＢ７２０のレコードの処理依頼情報部に従い、注文登録処理を行う（S11040）。具体的には、要件ＤＢ７２０中の注文登録依頼内容に従い、注文受付ＤＢ７００を依頼キー内容で検索し、注文登録チェックを行う。エラーの場合は受付通知作成処理プロセス８１６にエラー通知作成依頼を行う。さらに銘柄別受付番号を採番し、注文・板ＤＢに当該銘柄別受付番号および当該注文情報を格納する。
【０１３７】
次に注文登録処理プロセス８１７は、注文登録処理プロセス８１７の後続処理は２機能存在するため、要件ＤＢ７２０には依頼先機能名別の２件登録する（S11050）。なお後続処理の数は、処理結果、すなわちエラーになったか、正常だったか、取引が成立したか、取引が成立しなかったかなどや、注文登録処理や取引処理等の機能毎に異なる。本実施の形態においては、要件ＤＢ７２０に要件処理依頼イベント（取引処理）を格納すると共に、要件処理依頼イベント（受付通知作成処理）も格納する。
【０１３８】
続いて注文登録処理プロセス８１７は、同一の銘柄グループ番号の依頼先機能宛に、要件処理依頼イベントを送信する（S11060）。具体的には、同一銘柄グループの取引処理宛てに「取引処理依頼」イベントを送信すると共に、同一銘柄グループの受付通知作成宛てに「受付通知作成処理」イベントを送信する。
【０１３９】
そして注文登録処理プロセス８１７は、上記で処理が終了した要件ＤＢ７２０の「処理済みフラグ」を「処理済み」に更新する（S11070）。なおS11030の取り出し件数に従い、ｎ件の場合もある。
【０１４０】
次に取引処理について図３９を参照しながら説明する。  
まず取引処理プロセス８１１は、要件処理依頼イベント（取引処理）を受信する（S12010）。本実施の形態における要件処理依頼イベント（取引処理）には、図３７に示すように”銘柄キー”が含まれているが、”銘柄グループ番号”は含まれていなくても良い。銘柄グループ番号は自分のプロセス定義として起動時から保持しているからである。
【０１４１】
続いて取引処理プロセス８１１は、銘柄グループ指示状態ＤＢ７６０を、自銘柄グループ番号の銘柄グループ番号で検索し、共用取得する（S12020）。そして銘柄グループ定義ＤＢ７１０を、イベントより取得した銘柄キーで検索し、銘柄グループ番号を取得する（S12030）。なおS12030の処理はかならずしも必須ではない。これは、銘柄グループ変更元に無駄なイベントが残留するため、その無駄なイベントを要件ＤＢ７２０アクセス負荷を誘発することなく削除するための処理である。当該チェック実施によりイベントを削除せずに要件ＤＢ７２０を検索しても良いが、既に銘柄グループが変更された変更元銘柄グループの場合は、検索結果がゼロ件になる。銘柄グループ定義ＤＢ７１０をメモリ上で仮想管理している場合には、当該チェック処理の負荷が少ないため、実施することもできる。
【０１４２】
次に取引処理プロセス８１１は、取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が、自プロセスの銘柄グループ番号と異なるか否かを判定する（S12040）。取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が自プロセスの銘柄グループ番号と異なる場合は、当該イベントの対象銘柄は既に割当変更されているため、”ＹＥＳ”に進み当該イベントによる処理は行わない。
【０１４３】
取得した銘柄グループ定義ＤＢ７１０のレコードの銘柄グループ番号が自プロセスの銘柄グループ番号と同じ場合は”ＮＯ”に進み、取引処理プロセス８１１は、図３６に示す要件ＤＢ７２０から、下記の条件で先頭１件を取得する（S12050）。ここで、ｎ件処理しても良いが、その後同じ銘柄に対してｎー１件分の処理済み（空振り）イベントを受信する。同一銘柄をｎ件を纏めて処理することにより性能の向上を図ることができる。ここで上述した条件とは、銘柄キーがS12010で取得した銘柄キーと同一で、処理フラグが未処理であるレコードを、要件登録時刻順に先頭１件（ｎ件）を取得する。
【０１４４】
続いて取引処理プロセス８１１は、取得した要件ＤＢ７２０のレコードの処理依頼情報部に従い、取引処理を行う（S12060）。具体的には、要件ＤＢ７２０の注文・板ＤＢのキー情報に従って該当レコードを取得し、売注文と買注文のマッチング処理を行う。マッチング処理の結果は、注文・板ＤＢと銘柄ＤＢ７３０および歩みＤＢ７４０に格納する。
【０１４５】
上記S12060で約定が成立しなかった場合は、取引処理プロセス８１１は、相場配信情報作成プロセス、及び市況情報作成プロセス宛ての２機能の要件ＤＢ７２０を作成し、約定が成立した場合は、上記に加えて、約定通知作成プロセスの３機能宛の要件ＤＢ７２０を作成する（S12070）。
【０１４６】
続いて取引処理プロセス８１１は、振分先の銘柄グループ番号の依頼先機能宛に、要件処理依頼イベントを送信する（S12080）。具体的には、同一銘柄グループの相場配信情報作成プロセス宛てに「相場配信情報作成依頼」イベントを送信すると共に、同一銘柄グループの市況情報作成プロセス宛てに「市況情報作成依頼」イベントを送信する。また約定が成立した場合は、上記に加えて、同一銘柄グループの約定通知作成プロセス宛てに「約定通知作成依頼」イベントを送信する。  
そして取引処理プロセス８１１は、上記で処理が終了した要件ＤＢ７２０の「処理済みフラグ」を「処理済み」に更新する（S12090）。なおS12050の取り出し件数に従い、ｎ件の場合もある。
【０１４７】
以上各実施の形態によれば、株式等の様々な商品の売買取引処理を銘柄グループ単位に並列処理し、迅速かつ公平な株式等の取引処理を実現することができると共に、取引を停止させることなく負荷分散及び障害回避を図ることができる。これにより、高信頼かつ高速な株式等の取引処理を実現することが可能となる。つまり、株式等の取引において、突然のニュースなどにより、ある特定の銘柄に対する注文が殺到し、ある銘柄グループに対する処理負荷が上昇した場合であっても、取引を停止させることなく、かつ取引の順序を守りながら、迅速にその銘柄を他の銘柄グループに移動させ、銘柄グループ間の負荷分散を図ることが可能となる。また、株式等の取引中にコンピュータシステムに障害が発生した場合であっても、障害による影響を受ける銘柄グループに分類される各銘柄を、障害による影響を受けない銘柄グループに、取引を停止させることなく、かつ取引の順序を守りながら、迅速に移動させることにより、取引に影響を与えないようにすることが可能となる。
【０１４８】
以上発明を実施するための最良の形態について説明したが、上記実施の形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明はその趣旨を逸脱することなく変更、改良され得ると共に、本発明にはその等価物も含まれる。
【図面の簡単な説明】
【０１４９】
【図１】取引所システムの全体構成を示す図である。
【図２】取引執行サーバ、注文受付サーバ、注文入力端末の構成を示す図である。
【図３】注文入力端末の記憶装置を示す図である。
【図４】取引執行サーバの記憶装置を示す図である。
【図５】注文受付サーバの記憶装置を示す図である。
【図６】注文受付データベースを示す図である。
【図７】銘柄グループ定義データベースを示す図である。
【図８】要件データベースを示す図である。
【図９】取引処理割当データベースを示す図である。
【図１０】注文電文を示す図である。
【図１１】注文受付処理の流れを示すフローチャートである。
【図１２】取引処理の流れを示すフローチャートである。
【図１３】銘柄グループ変更処理の流れを示すフローチャートである。
【図１４】取引所システムの全体構成を示す図である。
【図１５】注文受付処理、銘柄グループ処理を説明するための図である。
【図１６】注文受付処理、銘柄グループ処理を説明するための図である。
【図１７】注文受付処理、銘柄グループ処理を説明するための図である。
【図１８】注文受付処理、銘柄グループ処理を説明するための図である。
【図１９】注文電文を示す図である。
【図２０】注文受付データベースを示す図である。
【図２１】銘柄グループ定義データベースを示す図である。
【図２２】要件データベースを示す図である。
【図２３】要件処理依頼イベントを示す図である。
【図２４】銘柄グループ変更（銘柄指定）処理依頼イベントを示す図である。
【図２５】銘柄グループ変更（銘柄グループ指定）処理依頼イベントを示す図である。
【図２６】銘柄グループ指示状態データベースを示す図である。
【図２７】滞留銘柄臨時割当判定データベースを示す図である。
【図２８】注文受付処理の流れを示すフローチャートである。
【図２９】注文登録処理の流れを示すフローチャートである。
【図３０】取引処理の流れを示すフローチャートである。
【図３１】銘柄グループ変更（銘柄キー指定）処理の流れを示すフローチャートである。
【図３２】銘柄グループ変更（銘柄グループ指定）処理の流れを示すフローチャートである。
【図３３】活況銘柄臨時割当処理の流れを示すフローチャートである。
【図３４】銘柄グループ障害臨時割当処理の流れを示すフローチャートである。
【図３５】要件データベースを示す図である。
【図３６】要件データベースを示す図である。
【図３７】要件処理依頼イベントを示す図である。
【図３８】注文登録処理の流れを示すフローチャートである。
【図３９】取引処理の流れを示すフローチャートである。
【符号の説明】
【０１５０】
１００    注文入力端末
２００    取引執行サーバ
３００    注文受付サーバ
４００    ネットワーク
５００    記録媒体
６００    注文電文
７００    注文受付データベース
７１０    銘柄グループ定義データベース
７２０    要件データベース
７３０    銘柄データベース
７４０    歩みデータベース
７５０    取引処理割当データベース
７６０    銘柄グループ指示状態データベース
７７０    滞留銘柄臨時割当判定データベース
８００    注文入力端末制御プログラム
８１０    取引執行サーバ制御プログラム
８１１    取引処理
８１２    運転管理
８１３    モニタリング
８１４    障害検知
８１５    銘柄グループ処理
８１６    受付通知作成処理
８１７    注文登録処理
８２０    注文受付サーバ制御プログラム
８２１    注文受付処理
【図１】
2006293852.tif 000003
【図２】
2006293852.tif 000004
【図３】
2006293852.tif 000005
【図４】
2006293852.tif 000006
【図５】
2006293852.tif 000007
【図６】
2006293852.tif 000008
【図７】
2006293852.tif 000009
【図８】
2006293852.tif 000010
【図９】
2006293852.tif 000011
【図１０】
2006293852.tif 000012
【図１１】
2006293852.tif 000013
【図１２】
2006293852.tif 000014
【図１３】
2006293852.tif 000015
【図１４】
2006293852.tif 000016
【図１５】
2006293852.tif 000017
【図１９】
2006293852.tif 000018
【図２０】
2006293852.tif 000019
【図２１】
2006293852.tif 000020
【図２２】
2006293852.tif 000021
【図２３】
2006293852.tif 000022
【図２４】
2006293852.tif 000023
【図２５】
2006293852.tif 000024
【図２６】
2006293852.tif 000025
【図２７】
2006293852.tif 000026
【図２８】
2006293852.tif 000027
【図２９】
2006293852.tif 000028
【図３０】
2006293852.tif 000029
【図３１】
2006293852.tif 000030
【図３２】
2006293852.tif 000031
【図３３】
2006293852.tif 000032
【図３４】
2006293852.tif 000033
【図３５】
2006293852.tif 000034
【図３６】
2006293852.tif 000035
【図３７】
2006293852.tif 000036
【図３８】
2006293852.tif 000037
【図３９】
2006293852.tif 000038
【図１６】
2006293852.tif 000039
【図１７】
2006293852.tif 000040
【図１８】
2006293852.tif 000041