(57)【要約】【課題】  従来、取引量（取引要求の量）が増大した場合、ある装置に負荷が集中してしまい、システム全体がダウンするとの課題に関しては、何ら考慮されていなかった。【解決手段】  本発明では、注文が集中しないよう、振分を行うことで、上記の課題を解消する。より具体的には、以下の構成が含まれる。  商品に対する取引要求を受付け、当該取引要求に応じた取引を実現するための取引制御を行う取引システムにおいて、受付けられた取引要求に応じて、取引のための注文データであって、取引端末を識別する取引端末識別子を含む注文データを生成し、当該注文データを送信する取引端末と、前記取引端末から送信される前記注文データを受信し、前記取引端末識別子に基づいて、前記注文データの振分先を特定し、特定された前記振分先に応じた送信先に前記注文データを送信する振分装置とを有し、前記振分先での処理に応じて、前記取引制御を実行する取引システムである。【選択図】図１
2009086796.tif 000002
【特許請求の範囲】
【請求項１】
商品に対する取引要求を受付け、当該取引要求に応じた取引を実現するための取引制御を行う取引システムにおいて、
受付けられた取引要求に応じて、取引のための注文データであって、取引端末を識別する取引端末識別子を含む注文データを生成し、当該注文データを送信する取引端末と、
前記取引端末から送信される前記注文データを受信し、前記取引端末識別子に基づいて、前記注文データの振分先を特定し、特定された前記振分先に応じた送信先に前記注文データを送信する振分装置とを有し、前記振分先での処理に応じて、前記取引制御を実行することを特徴とする取引システム。
【請求項２】
請求項１に記載の取引システムにおいて、
さらに、前記振分装置から送信された注文データを受信し、注文受付処理を実行する受付け装置を有することを特徴とする取引システム。
【請求項３】
請求項２に記載の取引システムにおいて、
さらに、前記受付け装置から前記注文受付処理として、前記注文データに応じた取引処理依頼を受信し、前記取引依頼に応じた取引処理を実行する取引処理装置を有することを特徴とする取引システム。
【請求項４】
商品に対する取引要求を受付け、当該取引要求に応じた取引を実現するための取引制御を行う取引システムでの取引制御方法おいて、
取引端末が、受付けられた取引要求に応じて、取引のための注文データであって、取引端末を識別する取引端末識別子を含む注文データを生成し、当該注文データを送信し、
振分装置が、前記取引端末から送信される前記注文データを受信し、前記取引端末識別子に基づいて、前記注文データの振分先を特定し、特定された前記振分先に応じた送信先に前記注文データを送信することで、
前記振分先での処理に応じて、前記取引制御を実行することを特徴とする取引制御方法。
【請求項５】
請求項４に記載の取引制御方法において、
さらに、前記取引システムを構成する受付け装置が、前記振分装置から送信された注文データを受信し、注文受付処理を実行することを特徴とする取引制御方法。
【請求項６】
請求項５に記載の取引制御方法において、
さらに、前記取引システムを構成する取引処理装置が、前記受付け装置から前記注文受付処理として、前記注文データに応じた取引処理依頼を受信し、前記取引依頼に応じた取引処理を実行することを特徴とする取引制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、株式を含む商品の取引を実現するための取引システムに関する。その中でも特に、取引所と呼ばれる運用主体が運用する取引所のシステムに関する。
【背景技術】
【０００２】
従来、証券取引を含む取引においては、注文情報を受信し、注文情報同士を比較して取引条件が満たすか否かにより取引を成立させていた(特許文献１)。より具体的には、入力装置３２から入力された証券売買の注文情報，取引情報は、制御装置３３を介して、取引記憶装置３４、約定記憶装置３６に記憶される。注文情報，取引情報は注文情報送信部３５を通じて各顧客１０，２０に送信され、表示装置１２に表示される。取引が成立した場合には、取引成立情報送信部３７を介して、取引成立情報が送信され、表示装置１２に表示され、スピーカ１３から警告音が発せられる。取引内容が確認された場合は、注文情報、取引成立情報が削除され、約定記憶装置３６に顧客識別情報、注文情報、取引情報が記憶される。
【０００３】
【特許文献１】特開２００１−２９７１９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１においては、取引量（取引要求の量）が増大した場合、ある装置に負荷が集中してしまい、システム全体がダウンするとの課題に関しては、何ら考慮されていなかった。
【課題を解決するための手段】
【０００５】
そこで、本発明では、注文が集中しないよう、振分を行うことで、上記の課題を解消する。より具体的には、以下の構成が含まれる。
【０００６】
商品に対する取引要求を受付け、当該取引要求に応じた取引を実現するための取引制御を行う取引システムにおいて、
受付けられた取引要求に応じて、取引のための注文データであって、取引端末を識別する取引端末識別子を含む注文データを生成し、当該注文データを送信する取引端末と、
前記取引端末から送信される前記注文データを受信し、前記取引端末識別子に基づいて、前記注文データの振分先を特定し、特定された前記振分先に応じた送信先に前記注文データを送信する振分装置とを有し、前記振分先での処理に応じて、前記取引制御を実行する取引システムである。
【０００７】
また、この取引システムにおいて、さらに、前記振分装置から送信された注文データを受信し、注文受付処理を実行する受付け装置を有することも本発明の一態様に含まれる。
【０００８】
さらに、この取引システムにおいて、さらに、前記受付け装置から前記注文受付処理として、前記注文データに応じた取引処理依頼を受信し、前記取引依頼に応じた取引処理を実行する取引処理装置を有することも本発明に含まれる。
【０００９】
なお、上述した取引システムを用いた取引制御方法や取引システムを構成する各装置、各装置での方法もしくは各装置をコンピュータとしてその処理を実行させるためのプログラムも本発明に含まれる。
【発明の効果】
【００１０】
本発明により、より効率的に取引処理を実現できる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施の形態について、図面を用いて詳細に説明する。
図1は、本発明の実施の形態におけるシステム構成図である。各コンピュータは、ネットワークを介して互いに接続されている。また、各コンピュータは、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。図２は、各システム構成要素が有するテーブルの構成図である。図３は、注文データの構成図である。図４は、処理手順の実施の形態を示すフローチャートである。図５は、振分処理のフローを詳細に説明した概念図である。図６は端末ＧＲＰテーブル作成のフローチャートである。図７は端末ＧＲＰテーブル作成のフローを詳細に説明した概念図である。
【００１２】
図１において、取引端末１０は、注文入力機能を有し、注文データを作成し証券取引所システム側の窓口である振分装置２０へ送信する。振分装置２０は、電文振分機能を有し、取引端末１０より受信した注文データを対応する受付装置３０に振り分ける。受付装置３０は、注文受付機能を有し、振分装置２０より受信した注文データに対して注文受付処理を行い取引処理装置４０に取引処理を依頼するとともに、受け付けた注文データを注文実績として蓄積する。取引処理装置４０は、取引機能を有し、受付装置３０より受信した業務データをもとに証券取引における取引処理を実施する。制御装置５０は、端末ＧＲＰテーブル作成機能と端末ＧＲＰテーブル配布機能を有し、受付装置３０より収集した注文実績データをもとに各端末ＧＲＰの受付件数が均等になるように端末ＧＲＰテーブルを作成し、振分装置２０に端末ＧＲＰテーブルを配布する。
【００１３】
取引端末１０、振分装置２０、受付装置３０、取引処理装置４０はそれぞれ複数台存在し、受付装置３０は端末ＧＲＰ毎、取引処理装置４０は銘柄ＧＲＰ毎に配置してもよい。なお、端末ＧＲＰは複数の端末を処理単位として纏めたもの、銘柄ＧＲＰは複数の銘柄を処理単位として纏めたものである。
【００１４】
以下、本実施の形態の処理内容について図４のフローチャートに沿って説明する。
本実施の形態における処理手順は取引時間帯の処理と取引終了時間帯の処理に分けられる。最初に取引時間帯の処理について説明する。
【００１５】
まず、ステップ１００において、取引参加者は取引端末１０において図３に示す注文データ７０を作成する。注文データ７０は制御ヘッダ７１、業務ヘッダ７２、業務データ７３で構成される。次に、ステップ１０２において、取引端末１０は作成した注文データ７０を振分装置２０に送信する。
ステップ１０４において、振分装置２０は取引端末１０より注文データ７０を受信し、ステップ１０６において、受信した注文データ７０と図２に示す端末ＧＲＰテーブル６０、宛先テーブル６１により、振分先の受付装置３０を決定する。具体的には、図５に示すように、注文データ７０の中の制御ヘッダ７１の端末ＩＤ（００００１）を、端末ＧＲＰテーブル６０の中の端末ＩＤと付け合せ、対応する端末ＧＲＰ（００１）を特定する。そして、特定した端末ＧＲＰ（００１）を宛先テーブル６１の中の端末ＧＲＰと付け合せ、対応する宛先（受付装置１）を特定する。次に、ステップ１０８において、振分装置２０は受付装置３０（受付装置１）に注文データ７０を送信する。なお、ここでは、注文データを各ヘッダとして表現しているが、他の形式でも構わない。
【００１６】
ステップ１１０において、受付装置３０は振分装置２０より注文データ７０を受信し、ステップ１１２において、受信した注文データ７０に対して注文受付処理を行い対応する取引処理装置に注文データ７０を送信し取引処理を依頼する。なお、本発明はステップ１１２における対応する取引処理装置を決定するプロセスにおいても適用が可能である。その後、ステップ１１４において、受付装置３０は図２に示す注文実績テーブル６に対して、注文データ７０の中の制御ヘッダの端末ＩＤ（００００１）の受付件数に１を加算することで端末からの注文実績を蓄積する。
【００１７】
ステップ１１６において、取引処理装置４０は受付装置３０より注文データ７０を受信し、取引処理を実施する。
以上が取引時間帯の処理内容である。次に取引終了時間帯の処理について以下に示す。
【００１８】
まず、ステップ１１８において、受付装置３０は制御装置５０に図２に示す注文実績テーブル６２を送信する。
【００１９】
ステップ１２０において、制御装置５０は各受付装置３０から注文実績テーブル６２を受信し、ステップ１２２において、受信した注文実績テーブル６２をマージし図２に示す集計テーブル６３を作成する。次に、ステップ１２４において、集計テーブル６３をもとに各端末ＧＲＰの受付件数が均等となるように図２に示す端末ＧＲＰテーブル６４を作成する。以下、図６のフローチャートと図７の概念図を用いてステップ１２４の詳細を説明する。ここで、均等とは、各端末ＧＲＰでの受付件数の差が、一定の範囲内になることや偏差が一定範囲内になることを示す。このため、各端末ＧＲＰでの受付件数の差がまったく一致しなくともよい。
まず、ステップ１３０において図７の集計テーブル８１より受付件数の合計を算出し、この合計を端末ＧＲＰ数で割ることで、端末ＧＲＰあたりの平均受付件数ｘ（５４，１４８）を算出する。なお、端末ＧＲＰ数については事前に入力しておく（図７の例では６０）。
【００２０】
また、ステップ１３２において、集計テーブルを受付件数の昇順（もしくは降順）にソートする。このソート処理は、ステップ１３０に先立って行ったり、ステップ１３０と並行して行ってもよい。図７の例では、端末ＩＤ＝００２４３，０００８９…００４９２の順に昇順にソートされるものとする。
【００２１】
次に、ステップ１３４〜１５８において、集計テーブル８１からレコードを一件ずつ抽出し、平均受付件数ｘ（５４，１４８）を超えないように各端末ＧＲＰを構成する処理を行う。
【００２２】
各端末ＧＲＰを構成する際には、抽出済みでないレコードのうち、受付件数の合計が平均を超えないように昇順にレコードを抽出する。ワークテーブル８１には抽出済みフラグを設定できる列を設け、端末ＧＲＰとして抽出が完了したレコードには抽出済みフラグを立てることで抽出済みかどうかを判定できるようにする。また、昇順に通番を振ることで、最終レコードを判定できるようにする。以下、処理の詳細について説明する。
【００２３】
ステップ１３４において、ソートされた各データについて、ソート順にそれを識別する端末ＧＲＰを付与し、記憶する。つまり、最初のデータについては、端末ＧＲＰ番号＝１とセットし、順次、２，３、…との番号を付与する。
【００２４】
また、ステップ１３６で、端末ＧＲＰ番号ａが最終端末ＧＲＰ番号かどうかの判定を行う。ここで端末ＧＲＰ番号ａが最終端末ＧＲＰ番号（図７の例では６０）であった場合には、ステップ１５４に進み処理を終了する。
【００２５】
次に、ステップ１３８で、端末ＧＲＰ毎合計受付件数ｙを０として初期設定し、記録する。この処理は、ステップ１３６に先立って行ったり、ステップ１３６と並行して行ってもよい。
【００２６】
次に、ステップ１４０において、抽出されていないレコードの中から昇順に１件ずつレコードを抽出し、抽出されたレコードの受付件数をｚに記録する。図７の例では、端末ＩＤ：２４３のレコードが抽出され、受付件数ｚに５３，８９２が記録される。
【００２７】
その後、ステップ１４２で、端末ＧＲＰ毎合計受付件数ｙと抽出レコードの受付件数ｚの和が、端末毎ＧＲＰあたりの平均受付件数ｘを超えていないかどうかを判定する。超えていない（ＹＥＳ）場合にはステップ１４４に進み、超えている、あるいは等しい（ＮＯ）場合にはステップ１５０に進む。図７の例では、ｘ＝５４，１４８、ｙ＝０、ｚ＝５３，８９２であるため、ＹＥＳと判定され、ステップ１４４からの端末ＧＲＰへの追加処理へと進む。
【００２８】
ステップ１４４では、抽出したレコードの端末ＩＤを端末ＧＲＰ番号ａとして端末ＧＲＰテーブルに追加する。図７の例では、端末ＩＤ：２４３が端末ＧＲＰ番号：１として端末ＧＲＰテーブル８２に追加される。
【００２９】
そして、ステップ１４６で、対象レコードに抽出済みのフラグを立て、以降の抽出対象からはずす。図７の例では、端末ＩＤ：２４３のレコードに抽出済みのフラグが立てられる。
【００３０】
次に、ステップ１４８で、抽出したレコードが未抽出レコードの中で最終レコードかどうかの判定を行う。最終レコードの場合（ＹＥＳ）には、ステップ１５２に進み、最終レコードでない場合（ＮＯ）には、ステップ１５０に進む。図７の例で、端末ＩＤ：２４３のレコードを抽出した段階では、最終レコードではないため、ステップ１５０に進む。
【００３１】
ステップ１５０では、端末ＧＲＰ毎合計受付件数ｙに抽出したレコードの受付件数ｚを加算して端末ＧＲＰ毎合計受付件数を更新する。図７の例では、ｙ＝０、ｚ＝５３，８９２であるため、ｙ＝５３，８９２に更新される。
【００３２】
以降、ステップ１４０〜１５０の処理を未抽出レコードのうち最終レコードを抽出するまで繰り返し実施する。なお、抽出したレコードが最終レコードかどうかは、抽出レコードの通番とあらかじめ記録しておいたレコード数とを付け合せることで判定する。図７の例では、端末ＩＤ：６９のレコードが端末ＧＲＰ：１として端末ＧＲＰテーブル８２に追加される。
【００３３】
その後、最終レコードまで抽出完了後、ステップ１５２に進み、端末ＧＲＰ番号ａに１を加算することで、次の端末ＧＲＰ番号に処理を移す。
【００３４】
ここまでの一連の処理により、各端末ＧＲＰの受付件数の合計が端末ＧＲＰ毎の平均受付件数を超えないように端末ＧＲＰを構成することで、各端末ＧＲＰの合計受付件数がほぼ均等な端末ＧＲＰ構成を作成できる。ただし、最終端末ＧＲＰについては、ステップ１５４において、残りの全ての未抽出レコードを含んだ構成となり、平均受付件数を超えてしまう可能性があることに注意する。
【００３５】
その後、ステップ１６０において、制御装置５０は作成した端末ＧＲＰテーブル６４を各振分装置２０に対して送信する。
【００３６】
ステップ１６２において、振分装置２０は制御装置５０から端末ＧＲＰテーブル６４を受信し、ステップ１６４において、図２に示す端末ＧＲＰテーブル６０を受信した端末ＧＲＰテーブル６４に更新する。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施の形態におけるシステム構成図
【図２】本発明の実施の形態における各システム構成要素が有するテーブルの構成図
【図３】本発明の実施の形態における注文データの構成図
【図４】本発明の実施の形態における処理手順の実施の形態を示すフローチャート
【図５】本発明の実施の形態における振分処理のフローを詳細に説明した概念図
【図６】本発明の実施の形態における端末ＧＲＰテーブル作成のフローチャート
【図７】本発明の実施の形態における端末ＧＲＰテーブル作成のフローを詳細に説明した概念図
【符号の説明】
【００３８】
１０、１１、１２…取引端末、２０、２１、２２…振分装置、３０、３１、３２…受付装置、４０、４１、４２…取引処理装置、５０…制御装置
【図１】
2009086796.tif 000003
【図２】
2009086796.tif 000004
【図３】
2009086796.tif 000005
【図４】
2009086796.tif 000006
【図５】
2009086796.tif 000007
【図６】
2009086796.tif 000008
【図７】
2009086796.tif 000009