JP2008135013A - 注文システム - Google Patents

Abstract

【課題】
証券取引における１つの注文情報について、受信、取引条件確認、取引成立、結果送信の各処理をシリアルに実行している。このため、特許文献１においては、特定の銘柄の注文が集中した場合など取引量が増加した場合、取引処理がスムーズに流れない、場合によってはシステムがダウンするとの問題が生じた。
【解決手段】
そこで、本発明では、いわゆるトランザクション（注文処理）を、所定の単位で分割し、トランザクション間の連携をトリガ方式とする構成にした。また、本発明には、トランザクション処理増加に伴いデータが滞留した場合に、一定のレスポンスを確保できる範囲内で、自動的に１トランザクションで複数の処理実行をすることも含まれる。例えば、処理、ステップごとにデータベースに処理の進捗状況を格納しておくことが含まれる。また、所定の単位としては、銘柄、端末、市場、サーバなどが含まれる。
【選択図】 図１

Description

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

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

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

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

特に、取引量の増加（変化）を、翌日などに制御を変化させるなどして対応することについては、何ら考慮されていなかった。

そこで、本発明では、いわゆるトランザクション（注文処理）を、所定の単位で分割し、トランザクション間の連携をトリガ方式とする構成にした。また、本発明には、トランザクション処理増加に伴いデータが滞留した場合に、一定のレスポンスを確保できる範囲内で、自動的に１トランザクションで複数の処理実行をすることも含まれる。例えば、処理、ステップごとにデータベースに処理の進捗状況を格納しておくことが含まれる。また、所定の単位としては、銘柄、端末、市場、サーバなどが含まれる。

より具体的には、「複数のグループのいずれかに属し、注文要求を送信する複数の営業店端末と接続された、複数の受付装置（サーバ）」、「前記注文要求に対し、自身が対応する注文要求の注文処理を行う、複数の注文処理装置（サーバ）」、「取引注文要求に対し、自身が対応する取引注文要求の取引注文処理を行う、複数の取引所直結装置（サーバ）」を備え、複数の証券注文を並行して実行可能な注文システムである。
受付装置（サーバ）は、グループごとに営業店端末から、注文銘柄を含む注文要求を受付け、受付けられた注文要求を正常に受信したか否かを確認して、正常な受信の場合、当該注文要求を送信した営業店端末に受信結果を送信して、前記注文要求を注文受付キューに格納する手段と、注文要求を受付けたことを注文処理装置へ連絡する手段とを有する。

注文処理装置（サーバ）は、前記注文要求を受付けたことの連絡を受け、前記注文受付キューから自身の注文銘柄に対応する注文要求を抽出する手段と、抽出した前記注文要求を、取引受付可能な状態として取引注文キューに登録する手段と、前記注文受付キュー内で注文要求が目標処理時間を超過するような滞留時間となった場合、１注文処理において一括処理最大数（システム管理者が目標レスポンスを考慮し設定する、一括で処理を許可するデータ件数）の範囲内で前記注文受付キューに滞留している次に処理すべき注文要求を連続して処理する手段と、取引注文要求を受付けたことを取引所直結装置へ連絡する手段とを有する。

取引所直結装置（サーバ）は、前記取引注文要求を受付けたことの連絡を受け、前記取引注文キューに登録された注文要求のうち、自身の注文銘柄に応じた取引注文要求について取引所に注文を出す手段と、前記取引注文キュー内で取引注文要求が目標処理時間を超過するような滞留時間となった場合、予め定められた１取引注文処理において一括処理最大数（例えばmシステム管理者が目標レスポンスを考慮し設定する、一括で処理を許可するデータ件数）の範囲内で前記取引注文キューに滞留している次に処理すべき取引注文要求を連続して処理する手段と、前記取引注文処理結果を反映した注文要求を前記取引注文キューに登録する手段とを有する。

また、本発明には、このシステムを構成する各装置（サーバ）、方法、これを実現するためのプログラムも含まれる。

さらに、本発明では、予め定められた閾値以上の取引要求量を検知した場合、当該検知された取引状況における平均取引処理時間を算出し、これと予め定められている取引時間とから、取引可能な件数を算出し、これに基づいた制御を、例えば、翌日の同時間帯など対応する時間帯で行う。この場合、取引可能な件数を予め定めた最大処理数を超える場合、当該最大処理数に基づいた制御としてもよい。なお、本制御には、いわゆる一括処理件数を特定することが含まれ、上記の取引可能件数もしくは最大処理数を、一括処理件数とすることが含まれる。

本発明によれば、トランザクション間の連携をトリガ方式にすることにより、トランザクション起動時の即時性を確保する。また、処理件数増加の際（例えば瞬間的なもの）に、処理データが滞留した際には、１トランザクションで複数処理を一括処理最大数設定値内で実行する方式とすることにより、一括処理最大数の範囲内でレスポンスを確保し、かつスループットを自動的に向上させる効果を有する。

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

まず、本実施の形態におけるシステム構成図を図１に示す。各コンピュータは、ネットワークを介して相互接続されている。また、各コンピュータは、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。図１に示すように、本実施の形態におけるシステムは、営業店端末１、受付装置２、注文処理装置３、取引所直結装置４から構成される。これらの構成要件のそれぞれは、複数から構成されるものである。なお、営業店端末は、一般投資家の端末であってもよい。なお、図示しないが一括取引件数を管理する管理装置が各装置と接続され、この管理装置から各装置のうち少なくとも一部に、算出（もしくは再算出した）一括処理件数を送信するようにしてもよい。この算出方法に関しては、後述する。

次に、従来のトランザクション処理の内容について、図２で示す。
注文処理装置３で実行される注文処理（処理８０２）では、ステップ１１１〜１１９までが１回のプロセス起動で実行される。そのうち、処理１１２〜１１７が１トランザクションであり、１件の処理を行う。注文処理（処理８０２）はスループット重視である。ステップ１１１ではタイマ起動されるが、注文処理プロセスが未起動中（ステップ１１９からステップ１１１までの間）に注文受付キュー（ＤＢ５０１）にデータが格納された場合、次回タイマ起動（ステップ１１１）されるまで処理が行われないため、トランザクションの即時性に欠ける。また、注文受付キュー（ＤＢ５０１）に大量のデータが滞留した時は、１トランザクションで１件の処理を行うため、処理待ちとなりトランザクションレスポンスが長時間になることがあった。

そこで、改善策として発明した本発明の一態様について、図３で示す。
トランザクションレスポンス向上のため、受付装置２の受付処理（処理８０１）に新たに非同期ＲＰＣ処理（ステップ１０３１）を設け、注文処理装置３で非同期ＲＰＣをトリガにした注文処理（パラレル処理で実行）の起動（ステップ１１１２）を行う制御を行う。また、１件の処理を行った後、同一注文のデータが注文受付キュー（ＤＢ５０１）に滞留していた場合（ステップ１１６１でＹＥＳの場合）、続けて次の銘柄の処理も行う。例として、図４、図５で銘柄ｂが銘柄グループ1に属し、かつ９:００〜１１:００の場合について説明する。銘柄ｂ−１番目（図４．ＤＢ５０１ データ９０２）を処理（ステップ１１２〜ステップ１１６）したあと、ステップ１１６１「当該銘柄（銘柄ｂ）で未処理のデータがあるか？」を確認する。銘柄ｂ−２番目（図４．ＤＢ５０１ データ９０３）があるためＹＥＳとなり、次のステップ１１６２「一括処理最大数範囲内か」を確認する。この際の一括処理最大数は、図５．ＤＢ５０４ データ９１２より「２」である。次処理が２件目であるため、引続き銘柄ｂ−２番目（図４．ＤＢ５０１ データ９０３）の処理（ステップ１１２〜ステップ１１６）を行う。続いて、ステップ１１６１「当該銘柄（銘柄ｂ）で未処理のデータがあるか？」を確認する。銘柄ｂ−３番目（図４．ＤＢ５０１ データ９０６）のデータが滞留しているが、本処理は３件目となり、ステップ１１６２「一括処理最大数範囲内か」で一括処理最大数「２」を超えるためＮＯとなり、ステップ１１６３「同期点取得」を行ない当該トランザクションを終了する。ステップ１１６４「オンライン終了か」で引続きオンライン処理中でＮＯとなり、ステップ１１１２以降で銘柄ｂ−３番目（図４．ＤＢ５０１ データ９０６）の処理を後続の別トランザクションとして処理を続ける。

ここで、一括処理最大数は、複数件処理してもトランザクションの実行時間が一定(予め定められた)のレスポンス範囲内で終了するように設定する。これにより、トランザクションの即時性を確保しつつ、トランザクションのスループットを確保できる。

なお、図４．ＤＢ５０１「注文受付キュー」、図５．ＤＢ５０４「一括処理最大数設定テーブル」は、端末ごとや銘柄ごと、グループごとなど複数用意してもよい。この場合、処理状況が変わること（「注文受付」から「注文処理済」へなど）をトリガに、お互いの整合性がとれるよう、他のデータベースの状況（ステータス）を変更するよう制御する。

本実施の形態で用いた例では、図５．ＤＢ５０４「一括処理最大数設定テーブル」のキーは、処理区分（銘柄グループ）と、時刻としているが、時間帯、商品ごとの処理区分、注文受付中などの運用区分などをキーにしてもよい。

従来技術と本発明の一態様の、１件の処理時間の比較を図６に示す。非同期ＲＰＣ（図３．ステップ１０３１）をトリガにトランザクションを起動する本発明の一態様を適用した場合、タイマ起動待ちの時間（図２．ステップ１１９からステップ１１１までの間、図６．処理時間４０１）が削減される。

また、トランザクションスループット一括処理時のレスポンス確保概要について、２件の注文処理を受信した場合の処理イメージを図７で示す。

従来技術では、「１件の注文処理時間（処理時間４０１〜４０４）の約２倍」のレスポンス時間を費やす。しかし、本発明を適用した場合、「1件目の注文処理時間（処理時間４１１〜４１３）＋２件目の注文処理時間（処理時間４１４）」のレスポンス時間で処理が可能となる。ここで、２件の処理を一括して実施しても、注文処理１件の目標時間（目標処理時間４３１）以内に、注文処理１（処理時間４２１）、注文処理２（処理時間４２２）が完了し、かつ従来の約２倍のスループットを確保できる。

従来の処理では、注文データを連続して受信すると、処理を１件づつ実行（シリアル処理）するため、レスポンス及びスループットが確保できなかったが、本発明により、トランザクションレスポンスを目標処理時間程度に抑え、かつスループットを確保するため、取引時間帯毎で一括処理最大数をn件処理可能な処理となっている。

最後に、上記の処理に加え、（例えば、瞬間的な）処理件数が増加した場合に、処理データが注文受付キューに滞留した際においてもレスポンス時間を増加させないために、図５の一括処理最大数の設定値を動的に変更する処理について説明する。

図８は、システムへのアクセスが集中した場合においても、目標レスポンスを確保するための概念を示す図である。ここで、最大（限界）レスポンスは、システムで許容できるレスポンス時間の最大値である。また、目標レスポンスは、過去の経験より目標とするレスポンス時間を定めたものである。本例では、n日の９：００にシステムへのアクセスが集中し、レスポンス時間が目標レスポンス時間を越えている。翌日のn+1日の９：００にも同程度の負荷がかかると考えられるので、この時間帯のレスポンス時間を目標レスポンスまで下げるために、図９に示す一括処理最大数の更新処理を行う。

図１０、１１は、図９のフロー中で用いるデータテーブルである。
図１０は、注文処理前に注文受付キュー（図４.ＤＢ５０１）のデータをコピーし、注文処理後に処理時間（図１０.項目５０５６）とその時の滞留件数（図１０.項目５０５７）を格納している。処理時間（図１０.項目５０５６）は、受付処理時にトランザクション１件ごとの受付時間を注文受付キューに蓄積した値から、処理が完了した時間の差を求めることにより算出する。

図１１は、滞留に関する設定情報を格納している。ここで、基準値（現行）（図１１．項目５０６３）は、一括処理最大数設定テーブル（図５）より取得した現行の一括処理件数を示す。また、過去の経験によりMAX値（図１１.項目５０６５）、滞留判断件数（図１１.項目５０６７）を設定している。MAX値（図１１.項目５０６５）は、一括処理件数の限界値を示し、本件数を超えるとレスポンス時間が増加し、最大レスポンスを超える可能性が生じる。本件数は、目標レスポンスと最大レスポンスの間に収まるような値を選定している。

滞留判断件数（図１１.項目５０６７）は、滞留とみなす基準値を示している。これは、適切な一括処理最大件数を算出するために、設定している。また、目標処理時間（図１１.項目５０６２）は、各時刻の目標処理時間を示し、図８の目標レスポンスに対応している。基準値（現行）（図１１.項目５０６３）は、目標処理時間を考慮し設定しており、各時間帯の図５の一括処理最大数を示す。判断基準（図１１.項目５０６４）は、「滞留設定テーブルの目標処理時間 ÷ 統計情報蓄積テーブルの処理時間」の結果である、目標処理時間内で処理できる処理件数とMAX値（図１１.項目５０６５）の比較基準を示す。変更時間（図１１.項目５０６６）は、一括処理最大数の自動見直し開始時間を示す。これは、処理集中がない時間を設定している。

図９のフローに則り、処理の具体的説明を下記に示す。
滞留設定テーブルに設定された「変更時刻（図１１.項目５０６６）」の時刻をシステムで検知すると、滞留設定テーブルの「時刻（図１１.項目５０６１）」をキーにして、統計情報蓄積テーブルの「受付時間」を検索し、「時刻」に設定された時間内の「受付時間」を示すデータを特定する（ステップ１２１）。

本例では、滞留設定テーブルの「１１：１０」を検知した場合、同一のレコードの「時刻」には「８：００−８：５９」と設定されているので、統計情報蓄積テーブルの「受付時間」が８：００から８：５９までの間のデータを特定する。

次に、滞留が発生したデータの件数と処理時間を特定する。具体的には、「受付時間」で特定した「滞留件数」と滞留設定テーブルの「滞留判断件数」とを比較し、「滞留件数」が「滞留判断件数」以上になるデータの件数と処理時間を特定する（ステップ１２２）。

本例では「滞留判断件数」は「２」と設定されているため、８：００から８：５９までに処理を受け付けたデータのうち、「銘柄a-１０２」「銘柄b-１０３」「銘柄a-１３０」「銘柄a-１３１」が滞留したものとして特定され、これらの数をカウントすることにより、「滞留件数」が２以上となるデータの件数は４件と特定する。また、その処理時間はそれぞれ「０．３秒」「０．４秒」「０．３秒」「０．５秒」であると特定する。なお、滞留件数と処理時間が特定できればよいので、「銘柄a-１０２」「銘柄b-１０３」「銘柄a-１３０」「銘柄a-１３１」等の案件の特定まではしなくともよい。

次に、滞留設定テーブルに設定された「目標処理時間（図１１.項目５０６２）」を超えない範囲での最大処理件数を特定する。具体的には、滞留設定テーブルの「目標処理時間」を滞留発生時の処理時間から特定した「平均処理時間」を割算することにより、特定する（ステップ１２３）。本例では、８：００から８：５９までの「目標処理時間」は、「３秒」と設定されている。また、ステップ１２２の例で記載の通り、８：００から８：５９までの滞留件数は４件であり、平均処理時間は、（０．３＋０．４＋０．３＋０．５）÷４＝０．４秒と算出される。これらから、目標処理時間を超えない範囲での最大処理件数は、３ ÷ ０．４ ＝７．５より７件と特定できる。

次に、上記の目標処理時間を超えない範囲での最大処理件数と滞留設定テーブルの「MAX値（図１１.項目５０６５）」を比較し、MAX値以下であるかを特定する（ステップ１２４）。

本例では、８：００から８：５９において、目標処理時間を超えない範囲での最大処理件数は、「７件」であり、MAX値は「１２」である。このことより、目標処理時間を超えない範囲での最大処理件数は、MAX値以下である。

最後に、滞留設定テーブルの「MAX値（図１１.項目５０６５）」以下なら、目標処理時間を超えない範囲での最大処理件数、以上なら既定のMAX値を翌日の一括処理最大件数と特定し、滞留設定テーブルの「基準値（現行）（図１１.項目５０６３）」と一括処理最大数設定テーブルの一括最大数を自動更新する（ステップ１２５、ステップ１２６）。

本例では、８：００から８：５９において目標処理時間を超えない範囲での最大処理件数は「７」、MAX値は「１２」であり、MAX値以下であるので、最大処理件数の「７件」で滞留設定テーブルの「基準値（現行）（図１１.項目５０６３）」と一括処理最大数設定テーブルの一括処理最大数を更新する。
これにより、柔軟に一括処理最大件数を変更し、滞留時のレスポンスの向上が実現できる。

本実施の形態におけるシステム構成図（１）である。 本実施の形態における処理の内容（従来方式）を示すフローチャートである。 本実施の形態における処理の内容（本発明方式）を示すフローチャートである。 図３におけるＤＢ５０１に示す注文受付キューの詳細図である。 図３におけるＤＢ５０４に示す一括処理最大数を管理するテーブルである。 本実施の形態の基本的な処理内容及び処理時間を表した図である。 本実施の形態におけるデータ滞留時の処理内容及び処理時間を表した図である。 本実施の形態における銘柄の分析、予測を表した図である。 本実施の形態における処理の内容（改善方式）を示すフローチャートである。 ＤＢ５０５に示す統計情報を蓄積するテーブルである。 ＤＢ５０６に示す滞留設定情報を管理するテーブルである。

符号の説明

１・・・営業店端末（一般投資家の端末を含む）、２・・・受付装置、３・・・注文処理装置、
４・・・取引所直結装置

Claims (5)

1. それぞれが複数のグループのいずれかに属する複数の営業店端末であって、注文要求を送信する営業店端末と接続され、
   前記グループごとに、注文銘柄を含む注文要求を受付け、受付けられた注文要求を正常に受信したか否かを確認して、正常な受信の場合、当該注文要求を送信した営業店端末に受信結果を送信して、前記注文要求を注文受付キューに格納する手段と、注文要求を受付けたことを注文処理装置へ連絡する手段とを有する受付装置と、
   前記注文要求を受付けたことの連絡を受け、前記注文受付キューから自身の注文銘柄に対応する注文要求を抽出する手段と、抽出した前記注文要求を、取引受付可能な状態として取引注文キューに登録する手段と、前記注文受付キュー内で注文要求が目標処理時間を超過するような滞留時間となった場合、予め設定された１注文処理において一括処理最大数の範囲内で前記注文受付キューに滞留している次に処理すべき注文要求を連続して処理する手段と、取引注文要求を受付けたことを取引所直結装置へ連絡する手段とを有する複数の注文処理装置と、
   それぞれが証券取引所の注文銘柄に対応している複数の取引所直結装置であって、前記取引注文要求を受付けたことの連絡を受け、前記取引注文キューに登録された注文要求のうち、自身の注文銘柄に応じた取引注文要求について取引所に注文を出す手段と、前記取引注文キュー内で取引注文要求が目標処理時間を超過するような滞留時間となった場合、前記一括処理最大数の範囲内で前記取引注文キューに滞留している次に処理すべき取引注文要求を連続して処理する手段と、前記取引注文処理結果を反映した注文要求を前記取引注文キューに登録する手段とを有する複数の取引所直結装置とを備え、
   複数の証券株式注文処理を並行して実行可能な注文システム。
2. 請求項１に記載の注文システムにおいて、
   さらに、所定の時間内での取引要求量が予め定められた閾値以上の取引要求量を検知した場合、当該検知された取引状況における平均取引処理時間を算出する手段と、
   算出された前記平均処理時間と予め定められている取引時間とから、取引可能な件数を算出する手段と、
   算出された取引可能な件数に基づいた取引制御を実行する要求情報を、前記注文処理装置および前記取引所直結装置に対して送信する手段を有すること管理装置を有することを特徴とする注文システム。
3. 請求項２に記載の取引システムにおいて、
   前記管理装置は、前記要求情報として、前記取引可能な件数を前記一括処理最大数とする要求が含まれることを特徴とする取引システム。
4. 請求項３に記載の注文システムにおいて、
   前記管理装置は、前記取引可能な件数を前記一括処理最大数と比較し、比較の結果前記取引可能な件数が、前記一括処理最大数未満の場合、前記要求情報を送信することを特徴とする注文システム。
5. 請求項２乃至４のいずれかに記載の注文システムにおいて、
   前記管理装置は、前記閾値以上の取引要求量があるか否かを、予め定められた期間内での取引要求量が前記閾値と比較することで判定する手段をさらに有することを特徴とする注文システム。

Images