JP2007241771A - 取引システム - Google Patents

Abstract

【課題】
取引市場のシステムに注文を発注する際に、取次業者などが利用する取引システムを提供することを目的とする。
【解決手段】
注文受付手段と注文ＩＤ割当手段と、少なくとも一以上のイベントを監視し、発注条件を満たすかを判定するイベント監視手段と、注文属性に基づいて、確定された注文属性を取引市場システムに発注する発注手段と、未確定の注文属性を含む場合にはオブジェクトに基づいて処理を実行し、その結果を返す注文属性確定手段と、を有しており、発注手段は、未確定の注文属性に含まれるオブジェクトＩＤを渡し、注文属性確定手段は、そのオブジェクトを実行して結果を発注手段に返し、発注手段は実行結果を受け取って、未確定の注文属性の部分を実行結果に変更して、注文属性を確定した注文属性に変更した上で、確定した注文属性を取引市場システムに発注する、取引システムである。
【選択図】 図１

Description

本発明は、株式、債券、為替、商品先物、オプションなど各種の金融商品、その他の商品の商品取引について、取引市場のシステムに注文を発注する際に、取次業者などが利用する取引システムに関する。

近年、インターネットを介した金融商品、その他の商品のオンライントレードが普及しており、特に株式、債券、為替、商品先物、オプションなどの各種の金融商品の取引に関心が高まっている。金融商品やその他の商品の商品取引については、それらの取引市場のシステムに、取次業者を介して注文を行うことで、売買が成立している。例えば商品が株式の場合、投資家は、取次業者である証券会社の取引システムを介して東京証券取引所のシステムに注文を発注している。

オンライントレードによる取引の普及によって、投資家は、様々な条件を指定した上での注文を行うことを希望している。それに対して取次業者は、例えば指値注文（銘柄と売買価格と数量とを指定した注文形態）、成行注文（売買価格を指定せず、銘柄と数量のみを指定する注文形態）、逆指値注文（証券等の価格が、指定した価格より高くなったら買い注文を行い、指定した価格よりも安くなったら売り注文を行う注文形態）、連続注文（ある注文の約定により他の注文を発注する注文形態）、タイマー注文（時間や時刻に関する条件を満たした場合に発注する注文形態）、排他注文（２つの注文に対して、一つの注文が約定すると他方の注文が取り消される注文形態）などを組み合わせ、複雑な条件を備えた注文を発注可能なシステムを提供することで、投資家が価格変動リスクをコントロールできるようになっている。

このような様々な注文形態が行えることは、投資家にとって非常に有益ではあるが、投資家は、注文時に、発注条件（どのタイミングで注文属性を取引市場に発注するかを指定する条件）と注文の内容（注文属性：どの銘柄をどの価格でどれだけの数量を売／買するのかを指定する条件）とが一意に定まるように注文しなければならない。従って、投資家がマーケットの状況を見ながら、逐次、具体的な注文内容（発注条件と注文属性）を指定する必要があるが、これは投資家にとって、常にマーケットを監視していなければならないので、監視負担が発生する。

そこで、発注条件と注文属性との双方に変数という注文内容の指定後に定まるパラメータを含ませ、マーケットの状況によって変数が決定した場合に、具体的な発注条件と注文属性とが同時に自動的に決定され、それによって発注条件を満たした場合に前記決定された注文属性で取引市場に発注する取引システムが、下記特許文献１に示されている。また特許文献１に示された取引システムが、下記非特許文献１にも記載されている。

更に、特許文献１や非特許文献１に開示された取引システムと同様の処理を実現可能なシステムについて、非特許文献２に開示されている。非特許文献２に開示されている取引システム（自動発注システム：プログラム・トレーディング・システム）は、１９８０年代から米国を中心に使用されている。特に、インターネットが普及した１９９０年代後半からは、リアルタイムの時価フィールドによって株価情報を監視し、将来の不確定な株価などがある条件を満たしたときに、その値にバインドされる変数を使って、プログラムで動的に注文属性を計算して発注するシステムが一般投資家にも広く使われるようになった。代表的なシステムとしては、オメガ・リサーチ社から販売されたトレード・ステーション（TradeStation）があり、自動注文専用プログラム言語を用いて、自在な条件設定に基づく自動注文を簡便な表記により一般投資家でも記述が出来、非常に利便性が高いシステムである。またそれから数年遅れて日本でもトレード・ステーション（TradeStation）の一部の機能を実現するオンライン・トレードシステムが開発されている（非特許文献２）。

特開２００４−５４６４３号公報

カブドットコム証券株式会社、[online]、インターネット＜ＵＲＬ：http://kabu.com/company/pressrelease/20051226.asp＞ サミュエル・ナイト・テニス（Samuel Knight Tennis）著、「アスク・ミスター・イージーランゲージ（Ask Mr. EasyLanguage）」、（米国）、トレイダーズ・プレス（Traders Press, Inc.）、１９９９年

上述の特許文献１、非特許文献１、非特許文献２に示されている取引システムの場合、変数を発注条件と注文属性との双方に含めることにより、注文内容の指定時には具体的な発注条件と注文属性とが確定されず、発注条件の評価の際に変数の数値が決定することによって注文属性が決定し、具体的な注文内容（発注条件と注文属性）が定まるので、マーケットの状況に応じた取引を投資家は行うことが出来る点では有益である。

しかし、発注条件に含まれる変数の数値が決定することによって、それに応じた注文属性が同時に決定されるので（特許文献１段落（００４５）、段落（００５６）、段落（００６１）、段落（００６６）など）、変数の数値が決定したタイミングから、実際に発注条件を満たして、確定した注文属性を持つ注文が取引市場のシステムに取り込まれるタイミングまでに、通常、数十ミリ秒から数秒の時間差があり、その間のマーケットの変動に的確に対応することが出来ない。

例えば特許文献１に記載のように、注文内容が「現値が始値＋１０円になれば、指値を始値＋２０円で買いの注文」（この場合、「始値＋１０円」が発注条件、「指値を始値＋２０円で買い」が注文属性、「始値」が変数）の場合、変数「始値」が決定されたタイミングで発注条件と注文属性とが具体的な値に決定される。例えば「始値」が「５００円」の場合、発注条件が「５１０円」、注文属性が「５２０円で買い」として具体的な注文内容が確定する。

そうすると、投資家が指定した銘柄の時価が５１０円になるまで注文属性が「５２０円の買い」として固定されており、変数が決定されたタイミングから発注条件を満たすタイミングまでの間に、マーケットに大きな変化などがあった場合であっても注文属性が変更されることはない。従って、変数が決定したタイミングから発注条件を満たすタイミングまでの間の価格変動などのマーケットの変化に対して、柔軟に対応することが出来ないリスクを投資家は被らなければならない問題点がある。

非特許文献２に開示の取引システムを用いた場合、特許文献１や非特許文献１に開示されている取引システムよりは複雑な処理を実行させることが出来るが、条件部と帰結部が同一のスコープで実現されてしまうので、条件部の処理によりすぐに値として確定されてしまう。つまり条件として不確定なものを引き継ぐことが出来ず、上述と同様なタイムラグの発生が否めない。

上述した例をマーケットの変化に対応するように、「現値が始値＋１０円になれば、指値を（始値＋現値）÷２＋１０円で買いの注文」と変更することも出来る。この場合、指値を決定する「（始値＋現値）÷２＋１０円」の計算に使われる現値の値は、出来る限り注文が取引市場のシステムに取り込まれ、取引処理が行われる時点での値に近いことが望ましく、上述のような従来技術を用いた場合、「現値が始値＋１０円になった」時点での現値では古すぎる可能性がある。

またこのようなリスクを減らそうと思った場合には、このタイムラグがあることによるリスクが生じにくい変数や計算方法に限定せざるを得ず、投資家は注文属性の計算方法を多様化することが出来ない。つまり投資家の利便性に欠ける。

そこで本願発明者は、従来のように発注条件における変数の決定によって、注文属性が同時に確定するのではなく、発注条件が満たされた場合、注文属性を確定するためのデータ、データ取得方法、或いは注文属性の計算処理方法を表現する注文確定オブジェクトを動的に生成し、または予め用意された複数の注文確定オブジェクトの中から選び、注文が取引市場のシステムに取り込まれる時点に出来る限り近いタイミングで、注文確定オブジェクトの計算処理を実行することで、注文属性を確定する取引システムを発明した。

請求項１の発明は、投資家が利用する投資家端末から売買の注文を受け付け、それを取引市場が利用する取引市場システムに発注する取引システムであって、前記取引システムは、前記投資家端末から売買の注文を受け付ける注文受付手段と、前記受け付けた注文における注文属性を注文属性記憶手段に記憶させ、また前記注文に条件が含まれている場合には前記条件を条件記憶手段に記憶させる手段と、時価イベント、約定イベント、時刻イベントのうち少なくとも一以上のイベントを監視し、前記条件記憶手段に記憶した条件を満たすかを判定するイベント監視手段と、前記条件が含まれていない注文、又は前記注文における条件を満たした注文について、前記注文属性記憶手段に記憶した注文属性に基づいて確定された注文属性を前記取引市場システムに発注する発注手段と、前記発注手段が発注する注文について、未確定の注文属性を含む場合には、オブジェクト記憶手段に記憶している、注文属性を確定する処理が記述された注文確定オブジェクトの処理を実行し、その結果を前記発注手段に返す注文属性確定手段と、を有しており、前記発注手段は、少なくとも前記未確定の注文属性に含まれる、前記注文確定オブジェクトを識別するオブジェクトＩＤ又は前記注文確定オブジェクトを前記注文属性確定手段に渡し、前記注文属性確定手段は、与えられた前記注文確定オブジェクト又は前記オブジェクトＩＤに基づいて、前記オブジェクト記憶手段から得られる前記注文確定オブジェクトの処理を実行して、その結果を前記発注手段に返し、前記発注手段は、前記注文確定オブジェクトの実行結果を受け取って、前記未確定の注文属性の部分を前記実行結果に変更することにより、前記注文属性を確定した注文属性に変更した上で、前記確定した注文属性を前記取引市場システムに発注する、取引システムである。

本発明のように構成することで、未確定な注文属性については、発注の直前に確定して、取引市場システムに発注を行うことが出来る。これによって、従来のように、発注条件と注文属性とが同時に確定して、そこから実際に注文が発注されるまでのタイムラグを少なくすることが出来、価格変動などのマーケットの変化に対して柔軟に対応することが出来る。またタイムラグによるリスクもないので、注文属性に多様な計算処理を実現する注文確定オブジェクトを用いることが出来、注文属性の計算方法を多様化することが出来る。

請求項２の発明において、前記注文ＩＤ割当手段は、前記注文に含まれる識別子に基づいて、条件の付いた注文属性と条件とを特定する、取引システムである。

注文属性と発注条件の特定は確実に行わなければならない。そこで、本発明のように、注文に含まれる識別子に基づいて特定することにより、確実に処理が可能となる。

請求項３の発明において、前記発注手段は、前記注文属性に前記オブジェクトＩＤ又は前記注文確定オブジェクトが含まれている場合には、未確定の注文属性であると判定し、前記オブジェクトＩＤ又は前記注文確定オブジェクトが含まれていない場合には確定された注文属性であると判定する、取引システムである。

オブジェクトＩＤは、注文確定オブジェクトを識別する情報である。注文確定オブジェクトが注文属性に含まれていることは、何らかの計算方法を用いることによって値を算出する必要があることを示している。従って、オブジェクトＩＤが含まれていると未確定の注文属性であると判定し、含まれていない場合には確定された注文属性であると判定すると良い。

請求項４の発明において、前記オブジェクトは、データ、又はデータと一以上の処理命令から構成されるコードである、取引システムである。

オブジェクトは、データや処理命令、或いはそれらの組合せから構成されるコード（プログラムやモジュールなども含む）とすることで、単純な処理から複雑な計算方法まで任意に設定できる。また投資家自らがこのコードを組み、記憶させることで、自分なりのカスタマイズをすることが出来る。

請求項５の発明は、投資家が利用する投資家端末から売買の注文を受け付け、それを取引市場が利用する取引市場システムに発注する取引システムであって、前記取引システムは、前記投資家端末から売買の注文を受け付ける注文受付手段と、前記売買の注文を構成する各要素注文に対して、前記要素注文を特定するデータである注文ＩＤを割り当て、前記要素注文の注文属性と条件を示す情報とを前記注文ＩＤと対応付けて注文属性記憶手段に記憶させ、また前記要素注文に条件が含まれている場合には前記条件を前記注文ＩＤと対応付けて条件記憶手段に記憶させる注文ＩＤ割当手段と、時価イベント、約定イベント、時刻イベントのうち少なくとも一以上のイベントを監視し、前記条件記憶手段に記憶した条件を満たした場合にはその旨の情報を記憶させるイベント監視手段と、前記注文属性記憶手段に条件を示す情報がない注文、又は前記注文における条件が満たされたことを示す情報が記憶された注文について、前記注文ＩＤに基づいて、前記注文属性記憶手段に記憶した注文属性を抽出し、確定した注文属性を前記取引市場システムに発注する発注手段と、前記発注手段が発注する注文について、前記注文属性にオブジェクトＩＤを含む場合には、前記発注手段から前記オブジェクトＩＤを受け取り、前記オブジェクトＩＤに対応する注文確定オブジェクトの処理を実行して、その結果を前記発注手段に返す注文属性確定手段と、を有しており、前記発注手段は、前記注文の発注の前に、前記注文ＩＤに対応する注文属性にオブジェクトＩＤが含まれているかを判定し、オブジェクトＩＤが含まれていない場合にはそのまま確定した注文属性を前記取引市場システムに発注し、オブジェクトＩＤが含まれている場合には少なくとも前記オブジェクトＩＤを前記注文属性確定手段に渡し、前記注文属性確定手段から前記オブジェクトＩＤに対応する前記注文確定オブジェクトの実行結果を受け取って、前記未確定の注文属性の部分を前記実行結果に変更することにより、確定した注文属性に変更した上で、前記確定した注文属性を前記取引市場システムに発注する、取引システムである。

請求項１に記載の取引システムは、本発明のように構成することも出来る。

請求項６の発明は、投資家が利用する投資家端末から売買の注文を受け付け、それを取引市場が利用する取引市場システムに発注するコンピュータで処理を実行させる取引方法であって、前記取引方法を実行するコンピュータは、前記投資家端末から売買の注文を受け付けて、前記注文における注文属性を注文属性記憶手段に記憶し、前記注文に条件が含まれている場合には更に前記条件を条件記憶手段に記憶し、前記注文において条件が含まれていない場合には前記取引市場システムに前記注文属性記憶手段に記憶した注文属性が確定された注文属性であるかを判定し、前記確定された注文属性の場合には、前記取引市場システムに前記確定された注文属性で発注し、前記未確定の注文属性の場合には、前記未確定の注文属性で指定された注文確定オブジェクトを実行することで、前記未確定の注文属性における未確定の部分を前記注文確定オブジェクトの実行結果に変更することにより、確定された注文属性に変更した上で、前記取引市場システムに前記確定された注文属性を発注し、時価イベント、約定イベント、時刻イベントのうち少なくとも一以上のイベントを監視して、前記条件記憶手段に記憶した条件を満たすかを判定し、前記注文における全ての条件を満たした注文について、前記注文属性記憶手段に記憶した注文属性が確定された注文属性であるかを判定し、前記確定された注文属性の場合には、前記取引市場システムに前記確定された注文属性で発注し、前記未確定の注文属性の場合には、前記未確定の注文属性で指定された注文確定オブジェクトを実行することで、前記未確定の注文属性における未確定の部分を前記注文確定オブジェクトの実行結果に変更して、確定された注文属性に変更した上で、前記取引市場システムに前記確定された注文属性を発注する、取引方法である。

請求項１に記載の取引システムは、サーバなどのコンピュータで実行する場合には、本発明の方法の処理により実現することが出来る。

請求項７の発明は、投資家が利用する投資家端末から売買の注文を受け付ける取引システムから、未確定の注文属性の発注を受け取る取引市場システムであって、前記取引市場システムは、前記注文属性に含まれる未確定の注文属性に関する処理が記述された注文確定オブジェクトの処理を実行し、前記未確定の注文属性の部分を前記実行結果に変更することで確定した注文属性に変更する注文属性確定手段と、前記確定した注文属性を、他の注文の確定した注文属性とマッチングさせることで売買の成立をさせる手段と、を有する取引市場システムである。

請求項８の発明は、投資家が利用する投資家端末から売買の注文を受け付ける取引システムから、未確定の注文属性の発注を受け取る取引市場システムであって、前記取引市場システムは、前記注文属性に含まれる未確定の注文属性に関する処理が記述された注文確定オブジェクトをオブジェクトＩＤと対応付けて記憶するオブジェクト記憶手段と、前記取引システムから、未確定の注文属性を受け取る手段と、前記未確定の注文属性に含まれるオブジェクトＩＤに基づいて、前記オブジェクトＩＤに対応する注文確定オブジェクトの処理を実行し、前記未確定の注文属性の部分を前記実行結果に変更することで確定した注文属性に変更する注文属性確定手段と、前記確定した注文属性を、他の注文の確定した注文属性とマッチングさせることで売買の成立をさせる手段と、を有する取引市場システムである。

従来の取引市場システムでは、確定された注文（注文属性）しか受け付けていなかった。例えば東京証券取引所などのシステムでは、売買の区別、売買する銘柄、売買の価格（或いは成行）が確定された注文のみを受け付けていた。その為、証券会社などの取次業者が利用する取引システムから、取引市場システムに対して注文を発注する際には、確定された注文を発注せざるを得ない。しかし注文の発注から、それを実際に取引市場システムで受け入れるまで若干のタイムラグがあり、その間にもマーケットは変動している。一方、投資家にとっては、そのようなタイムラグの間に変動するリスクや機会損失を被らなければならないので、注文の内容（注文属性）は出来るだけ、取引市場システムでのマッチングの直前に決定されることが好ましい。その為、上述の発明では、従来技術と異なり、発注条件が確定された時点で注文属性を確定するのではなく、発注する直前に注文属性を確定しているのである。ところがそれでも取引システムで注文属性の確定から取引市場システムで受け取るまで、従来技術よりは短いタイムラグではあるが、それでもタイムラグの発生が否めず、その部分のリスクは存在する。そこで本発明のように、取引システムからは未確定の注文属性を発注し、東京証券取引所などのような取引市場システムでマッチングする直前にその注文属性を確定させる取引市場システムとすることによって、そのタイムラグによるリスクを限りなく減らすことが出来る。

本発明のように、発注条件を満たした注文を、取引市場のシステムに発注する直前のタイミングで注文属性を確定する取引システムとすることによって、従来のように、指値などの注文属性が決定されたタイミングから取引市場に発注されるタイミングまでの間の価格変動などのマーケットの変化に対して、柔軟に対応することが出来ないリスクを被ることがない。従って、投資家も従来よりも、マーケットの急激な変動に影響されにくいリスク管理を行った投資行動をとることが出来る。

またタイムラグによるリスクや機会損失も従来より少ないので、注文属性の決定に際して注文確定オブジェクトにより様々な計算方法を設定することが出来、注文属性の計算方法の多様化が可能となり、投資家の利便性が向上する。

本発明の取引システム１のシステム構成の概念図を図１に示す。取引システム１は、証券会社などの、金融商品やその他の商品の取引について取引市場との間で売買注文を取り次ぐ業者が利用するシステムである。また取引システム１は、投資家が利用するコンピュータ（投資家端末３）と、取引市場が金融商品やその他の商品の取引の場として利用する取引市場システム２と、データの送受信が可能である。なお、取引市場としては、東京証券取引所のような予め指定された取引所の他、証券会社などの取次業者などが提供しても良い。

取引システム１は、投資家端末３から受け取った売買の注文を、取引市場システム２に対して発注する制御を行う一台または複数台のサーバである。これらのサーバは、プログラムの演算処理を実行するＣＰＵなどの演算装置と、情報を記憶するＲＡＭやハードディスクなどの記憶装置と、演算装置の処理結果や記憶装置に記憶する情報をインターネットやＬＡＮなどのネットワークを介して送受信する通信装置とを少なくとも有している。取引システム１をコンピュータ上で実現する各機能（各手段）は、その処理を実行する手段（プログラムやモジュールなど）が演算装置に読み込まれることでその処理が実行される。各手段は、記憶装置に記憶した情報をその処理において利用する場合には、該当する情報を当該記憶装置から読み出し、読み出した情報を適宜、演算装置における処理に用いる。また当該サーバには、キーボードやマウスなどの入力装置、ディスプレイなどの表示装置を有していても良い。

取引システム１は、注文受付手段４と注文ＩＤ割当手段５と条件記憶手段７と注文属性記憶手段６とイベント監視手段８と発注手段１０と注文属性確定手段１１とオブジェクト記憶手段９とを有している。

注文受付手段４は、ネットワークを介して投資家端末３から売買の注文の情報を受け付ける手段である。この売買の注文の情報には、注文の種類、注文の発注や取り消し等の条件、注文属性が含まれていると良いが、条件はなくても良い。図７に投資家端末３から受け付けた売買の注文の情報の一例を示す。なお図７では、注文の階層構造を分かりやすく表現するために、ＸＭＬを用いた記法を用いているが、これに限定されるものではない。

図７の売買の注文の例は、二つの要素（要素注文）から構成される連続注文である。第一の要素注文は単純注文で銘柄Ａを４，５００円で１，０００株の買い注文である。第二の要素注文は排他注文であり、それ自体が二つの要素注文からなる。それぞれの要素注文は時価条件注文であって、一つ目の注文が銘柄Ａの現値が４，６００円以上になった場合に、銘柄Ａの直近１５秒の価格に基づいて２次補間による価格算出を行い、その価格で銘柄Ａの１，０００株の売り注文、他方の注文が銘柄Ａの現値が４，４５０円より低くなった場合に、銘柄Ａの１，０００株の成行での売り注文、を示している。また、この二つの売り注文はどちらかが約定すると他方は取り消される。このように、本発明の取引システム１で受け付ける売買の注文は階層構造を有している（なお、階層構造は一階層のみであっても良い）。図７の売買の注文を、階層構造で模式的に示した図が図８である。本発明の取引システム１で処理する売買の注文は、このように階層構造となっている。従って、取引システム１において各注文が再帰的に処理が行われる。

注文ＩＤ割当手段５は、注文受付手段４で受け付けた売買の注文の情報を構成する各要素注文に対して、階層の上位の注文から順に注文ＩＤを割り当てて、注文属性を注文属性記憶手段６（後述）に記憶させる手段である。また当該注文に、条件がある場合には条件記憶手段７（後述）に記憶させる手段である。この際に、例えば図７に示すように連続注文、排他注文など、一つの売買の注文の情報に、複数の売買の注文が含まれている場合には、その各々に注文ＩＤを割り当て、関連する注文を注文属性記憶手段６に記憶させると良い。また注文属性記憶手段６と条件記憶手段７とを統合し、注文属性と条件は一緒にまとめて記憶するように構成しても良い。

例えば図７の注文の場合には連続注文なので二つの要素注文からなり、また第二の要素注文は排他注文で、これも二つの要素注文からなる。従って、図７の場合には五つの要素注文がある。これらの各要素注文に対して、階層の上位の注文から順に注文ＩＤを割り当て、注文属性記憶手段６に記憶させる。注文ＩＤ割当手段５は、まず最も上位の注文である連続注文に対して注文ＩＤ「１」を割り当てる。そして注文ＩＤ「１」の連続注文を構成する単純注文に注文ＩＤ「２」を、排他注文に注文ＩＤ「３」を割り当てる。更に注文ＩＤ「３」の排他注文は、二つの時価条件注文を有しているので、第一の時価条件注文に対して注文ＩＤ「４」を、第二の時価条件注文に対して注文ＩＤ「５」を割り当てる。これらの各々を注文属性記憶手段６に記憶させる。この状態の注文属性記憶手段６（後述）を図３に示す。なおここでは、階層か構造の中の要素注文の注文ＩＤを割り当てる際に、深さ優先（depth-first）で階層構造を辿ったが、階層構造を辿る方法は、任意に決めて良い。

また注文ＩＤ割当手段５は、注文属性に条件が適用されている場合には、注文属性記憶手段６の当該注文に対して条件があることを示す情報（条件ＩＤ）を記憶させ、更に、その注文ＩＤの条件を条件記憶手段７に記憶させる。

図７の場合、注文ＩＤ「１」の連続注文、注文ＩＤ「２」の単純注文には、条件が適用されていないので、注文属性記憶手段６の条件を記憶させる領域には、条件がないことを示す情報「なし」が記憶される。

一方、注文ＩＤ「３」の排他注文は注文ＩＤ「１」の連続注文において、注文ＩＤ「２」の単純注文が約定することが条件なので、その条件を示す情報（条件ＩＤ「１００」とその発注条件）を条件記憶手段７に記憶させる。また注文ＩＤ「４」の時価条件注文は、発注の際に時価に条件があるので、その条件を示す情報（条件ＩＤ「１０１」）とその発注条件）を条件記憶手段７に記憶させる。また注文ＩＤ「４」の約定を監視する条件を示す情報（条件ＩＤ「１０２」）とその条件）を条件記憶手段７に記憶させる。また注文ＩＤ「５」の時価条件注文にも条件があるので、その条件を示す情報（条件ＩＤ「１０３」とその条件）を条件記憶手段７に記憶させる。また注文ＩＤ「５」の約定を監視する条件を示す情報（条件ＩＤ「１０４」とその条件）を条件記憶手段７に記憶させる。

なお、注文ＩＤ「４」及び注文ＩＤ「５」の時価条件注文は、その親注文である注文ＩＤ「３」が排他注文なので、一方の注文が成立すれば他方の注文は取り消される。従って、各注文についてその約定を監視する必要があり、注文ＩＤ「４」、注文ＩＤ「５」についてはそれぞれ（条件ＩＤ「１０２」、条件ＩＤ「１０４」）が監視されることとなる。

注文属性記憶手段６は要素注文の注文属性を記憶する手段であって、注文ＩＤ割当手段５で割り当てられた注文ＩＤと、注文の種類を示す情報と、条件の有無を示す情報と、注文属性と、その注文属性間の構造的関係を示す注文ＩＤと、注文の発注数の情報と、約定数の情報などを記憶している。また注文属性として、売買する銘柄を識別する情報、売買の数量、売買価格、売買の区別が記憶される。ここで、売買価格の算出にあたり、投資家が注文属性として予め指定している場合には、その価格が記憶されており、成行の場合には成行を示す情報が記憶されており、予め定められた計算方法で算出した価格を用いる場合にはコンピュータにおける計算方法のコード（プログラムやモジュールも含む）を表現する注文確定オブジェクトを識別する情報がオブジェクトＩＤとして記憶されている。図３に注文属性記憶手段６の概念図を示す。

条件記憶手段７は、注文属性に条件が付加されている場合の条件を記憶する手段であって、条件を識別する条件ＩＤと、条件の処理状態と、その監視状態と、各条件式などを記憶している。条件が成立したことを示す情報が記憶された場合、その注文ＩＤの注文属性を発注する処理を、後述する発注手段１０が行うこととなる。図４に初期状態の条件記憶手段７の概念図を示す。図４の条件記憶手段７では、条件ＩＤ、注文ＩＤ、イベント型、条件式、処理状態、監視状態が記憶されている。注文ＩＤは監視対象となる注文であり、イベント型は監視の種類（約定を監視するか（ＥＸＥＣ）、時価などの価格を監視するか（ＰＲＩＣＥ）、時間や時刻を監視するか（ＴＩＭＥ））を示している。また処理状態が「未」はまだ条件が未成立であり、「済」は条件成立を示す。監視状態が「ＯＦＦ」はイベント監視手段８が監視をしていない状態であり、「ＯＮ」はイベント監視手段８が監視をしている状態である。また条件式はその監視条件を示しており、例えば条件ＩＤ「１００」の「ＥＸＥＣ（＆ｐｒｉｃｅ，＆ｓｈａｒｅｓ）」は注文ＩＤ「２」で特定される注文の約定価格と約定数とを監視する。条件ＩＤ「１０１」の「ＵＰ（現値（Ａ）、４６００）」は銘柄Ａの現値が４６００円以上であるかを監視する。また条件ＩＤ「１０３」の「ＤＯＷＮ（現値（Ａ）、４４５０）」は銘柄Ａの現値が４４５０円以下であるかを監視する。

つまり条件ＩＤ「１００」では注文ＩＤ「２」の約定（約定価格と約定数）を監視しており、条件ＩＤ「１０１」では注文ＩＤ「４」の銘柄Ａの現値が４，６００円以上であるかを監視しており、条件ＩＤ「１０２」では注文ＩＤ「４」の約定（約定価格と約定数）を監視しており、条件ＩＤ「１０３」では注文ＩＤ「５」の銘柄Ａの現値が４，４５０円以下であるかを監視しており、条件ＩＤ「１０４」では注文ＩＤ「５」の約定（約定価格と約定数）を監視していることを示している。なお、ここでの条件式はあくまでも一例であり、取引システム１で予め様々な条件式を設定したり、投資家が任意に設定し、設定した条件式を投資家端末から受け取ることで、条件記憶手段７に記憶させるようにしても良い。

イベント監視手段８は、条件記憶手段７に記憶された条件が成立しているか否かを監視する手段である。このイベントとしては、時価イベント、約定イベント、時刻イベントなどが例としてある。時価イベントは、条件で指定された銘柄の現値を取引市場システム２や、金融商品やその他の商品の現値を提供するシステムから受け取り、条件に指定された銘柄の現値が条件を満たしているか、を判定する。約定イベントは、連続注文などのように、ある注文が成立した場合に次の注文の発注を行う、など他の注文が約定したことを示す情報が注文属性記憶手段６に記憶された場合に、条件を満たしているか、を判定する。時刻イベントは、時刻や時間を所定のタイマー装置から受け取り、それが条件を満たしているか、を判定する。これらのイベントも一例であり、他のイベントを監視可能にしても良い。

イベント監視手段８において、ある注文に対する条件が全て成立したことを判定した場合には、それが発注条件の場合には条件記憶手段７に記憶させ、発注手段１０に対して注文ＩＤと発注指示とを渡す。またその条件が取り消し条件の場合には、注文属性記憶手段６に記憶する当該注文の取り消し処理を行う。

なお従来技術のように、条件式についてその条件内に注文時には不確定なパラメータや他の条件式を設定しておき、その条件の時価イベント、約定イベント、時刻イベントなどをイベント監視手段８が監視し、それによって条件を確定した上で、上述のように、条件記憶手段７に記憶された条件が成立しているか否かを監視するように構成することも出来る。

発注手段１０は、注文属性記憶手段６に記憶する注文属性に基づいて、注文属性を取引市場システム２に送信し、注文の発注を行う手段である。この注文属性において、条件があることを示す情報（条件ＩＤ）が記憶されていない場合には発注手段１０はそのまま注文属性を発注し、条件があることを示す情報が記憶されている場合には、条件が成立したことを示す情報が記憶されてから（或いは条件が成立したことを示す情報をイベント監視手段８から受け取ってから）、発注手段１０は注文属性を発注する。

また発注手段１０は、注文属性に注文確定オブジェクトを含むことが注文属性記憶手段６に記憶されている場合には、その注文確定オブジェクトを識別するオブジェクトＩＤとそのオブジェクトの処理指示を注文属性確定手段１１に渡し、注文確定オブジェクトの処理を実行後、結果を受け取って注文属性を確定してから、発注を行う。

注文属性確定手段１１は、発注手段１０から注文確定オブジェクトまたは注文確定オブジェクトのオブジェクトＩＤを受け取ることにより、当該注文確定オブジェクトの処理を取引システム１或いは所定のサーバで実行する手段である。オブジェクトＩＤに対応する注文確定オブジェクトの処理内容は、オブジェクト記憶手段９に記憶するコードなどの処理命令に基づいて実行する。この処理の実行結果を発注手段１０に返す。

オブジェクト記憶手段９は、注文確定オブジェクトを一意に識別するオブジェクトＩＤとその注文確定オブジェクトの処理内容やデータとが対応付けて記憶されている。ここで注文確定オブジェクトとは、いくらの価格で発注するか、どれだけの数量発注するか、などのコンピュータにおける計算方法とその計算に必要なデータがコード化（その計算方法を実行するための関数やクラスなども含む）されて記憶されたものである。注文確定オブジェクトとしては、例えば「２次補間による価格算出」がある。図５にオブジェクト記憶手段９の概念図を示す。図５のオブジェクト記憶手段９におけるオブジェクトＩＤ「１０」については、「（銘柄Ｘ）の直近（Ｙ秒）の価格の２次補間による価格算出」の処理コードなどが記憶されている。ここで２次補間に用いる「銘柄Ｘ」「Ｙ秒」についてはパラメータとして注文属性確定手段１１から受け取ればよい。またオブジェクトＩＤ「１１」は「始値と現値の平均値の価格算出」の処理コードなどが記憶されている。なお、注文確定オブジェクトには、上述の「２次補間による価格算出」のように複雑な処理を実行するもののほか、単に「変数」や「数値」のみであっても良く、様々な形態を設定することが出来る。また注文確定オブジェクトは取次業者が予め設定したものであっても良いし、投資家自らが注文確定オブジェクトを実行するためのコードを記述し、それをオブジェクトＩＤと対応付けてオブジェクト記憶手段９に記憶させても良い。

次に本発明の取引システム１の処理プロセスの一例を図２のフローチャート、図１の概念図を用いて説明する。なお、本発明では、図７の注文の内容が投資家端末３から取引システム１に対して行われ、その一連の処理を説明するが、実際には複数の注文が並行して処理されている。

まず投資家は、投資家端末３で所定の操作をすることにより、売買の注文を入力し、それを投資家端末３から取引システム１に対して送信する。ここでは、まず銘柄Ａの株式を４，５００円で１，０００株買いの注文を行った後に（連続注文）、銘柄Ａの現値が４，６００円以上になったら（時価条件注文）、銘柄Ａの直近１５秒間の価格を２次補間による価格算出のオブジェクトで価格を算出してその価格で銘柄Ａを１，０００株売りの注文を行うか、或いは銘柄Ａの現値が４，４５０円より低くなったら（時価条件注文）、銘柄Ａを１，０００株成行で売りの注文を行う（排他注文）、を行うことを入力する。そうすると、図７に示すような注文の内容の情報が投資家端末３から取引システム１に送信される。この注文を階層的に示したのが図８であり、これらの注文は、取引システム１において再帰的に処理される。

この注文を取引システム１の注文受付手段４で受け付ける（Ｓ１００）。そして注文ＩＤ割当手段５は、Ｓ１００で受け付けた注文の内容に含まれる注文の構成要素に対して、それぞれの構成要素を一意に識別する注文ＩＤを割り当て（Ｓ１１０）、その注文の内容に条件が含まれているかを判定し（Ｓ１２０）、含まれていない場合にはそのまま注文属性を注文属性記憶手段６に記憶させる（Ｓ１３０）。またその注文属性に条件が付加されている場合には（Ｓ１２０）、注文ＩＤ割当手段５は、注文属性を注文属性記憶手段６に記憶させると共に、その条件を注文ＩＤと対応付けて条件記憶手段７に記憶させる（Ｓ１４０）。注文属性や条件は、投資家端末３から受け取った注文の内容に含まれる、注文の種類や条件等を示すタグなどの識別子に基づいて判定することが出来る。

注文の構造を明確にするために、注文の例をＸＭＬ形式で図７に示す。この注文の場合、二つの要素注文を含む連続注文からなり（単純注文と排他注文）、また排他注文が二つの時価条件注文である要素注文からなる、ことが、その注文の種類を識別するタグから判定できる。従って、合計で五つの要素注文があることが判定される。つまり最上位（第１階層）の注文は連続注文であり、単純注文の約定によって排他注文が発注される。また第２階層の排他注文では、いずれか一方の注文が約定すると、他方の注文が取り消される。また排他注文を構成する第３階層の二つの時価条件注文は、各条件を満たした場合に発注され、一方の注文が約定すると他方の注文が取り消される。

注文ＩＤ割当手段５は、これらの注文構造の各要素に対して、注文ＩＤを割り当てる。第１階層の連続注文は注文ＩＤ「１」が割り当てられる。第２階層においては、連続注文の第一の要素である単純注文は注文ＩＤ「２」が割り当てられる。またこれらの注文には「条件」を示すタグ（＜条件＞）がないので、条件がないことも判定できる。そして、注文属性として銘柄を示すタグ（＜銘柄＞）、価格を示すタグ（＜価格＞）、数量を示すタグ（＜数量＞）から銘柄、価格、数量、売買の別の注文属性を、注文ＩＤ「２」の注文属性として注文属性記憶手段６に記憶させる。この際に、それぞれの要素注文の種類「連続注文」（注文ＩＤ「１」の注文種類）と「単純注文」（注文ＩＤ「２」の注文種類）とを記憶させる。

なお図３では、説明の便宜上、情報をデータベースのデータ・エントリーのように表現しているが、メモリ上、ファイル上、データベース上で同じような情報を保つ構造化されたデータ形式でよい。また実際に発注される注文の情報を示す注文属性の部分は、注文ＩＤで対応付けられ、別のデータとして表現、記憶されても良い。データベース・テーブルで表現されている他のデータも同様である。

第２階層における、連続注文の第二の要素注文は注文ＩＤ「３」が割り当てられ、注文の種類として「排他注文」であることを記憶させる。ここで注文ＩＤ「３」の親注文は注文ＩＤ「１」の連続注文なので、注文ＩＤ「２」の成立が条件であることが判定できる（連続注文を示すタグ＜連続注文＞から）。従って、条件記憶手段７に、条件ＩＤ「１００」として、注文ＩＤ「２」の約定を監視する条件式を記憶させる。そして条件ＩＤ「１００」があることを注文属性記憶手段６に記憶させる。

第３階層における、排他注文の二つの要素注文の時価条件注文には、それぞれ注文ＩＤ「４」、注文ＩＤ「５」が割り当てられる。また注文ＩＤ「４」の注文について、発注条件の一つであるタグ（＜条件＞）から条件があることを判定して注文属性記憶手段６に条件があることを示す情報と、その条件を注文ＩＤ割当手段５は、条件記憶手段７に記憶する。即ち、注文ＩＤ「４」に対応付けて、条件のタグ（＜条件＞）に含まれる「銘柄Ａの現値が４，６００円以上」を条件として記憶させる。そしてこの条件を条件ＩＤ「１０１」とする。また注文ＩＤ「４」の親注文（注文ＩＤ「３」）の注文の種類を示すタグ（＜排他注文＞）から、注文ＩＤ「４」の約定を監視する条件も条件ＩＤ「１０２」として記憶させる。

そして注文ＩＤ「４」の条件をクリアした場合の注文処理を示すタグ（＜アクション＞）から、発注される注文の注文価格について、銘柄Ａの直近１５秒の２次補間による価格算出の注文確定オブジェクトを用いて算出することを判定し、それを注文ＩＤ「４」の注文属性の価格属性として記憶させる。なお注文属性の属性として注文確定オブジェクトを用いる場合には、本明細書では言葉で示しているが、実際には注文確定オブジェクトを識別するオブジェクトＩＤ又はオブジェクトへの参照で表現されていると良い。銘柄Ｘの直近Ｙ秒の２次補間による価格を算出する注文確定オブジェクトのオブジェクトＩＤが「１０」である場合を示し、また銘柄Ｘ、Ｙ秒は各々パラメータとして注文の内容に含めておき、それを注文確定オブジェクトの一部として更に記憶させておく。銘柄、数量、売買の別については、図７では説明の便宜上、言葉で示しているが、注文ＩＤ「２」と同様にタグなどの識別子から判定しても良いし、タグ＜アクション＞の中から判定しても良い。

第３階層における、排他注文の第二の要素注文は注文ＩＤ「５」が割り当てられ、注文の種類として「時価条件注文」であることを記憶させる。また発注条件の一つであるタグ（＜条件＞）から条件があることを判定して、条件記憶手段７にその条件を条件ＩＤに対応付けられた注文属性記憶手段６に条件があることを示す情報と、その条件を注文ＩＤ割当手段５は、条件記憶手段７に記憶する。即ち、注文ＩＤ「５」に対応付けて、条件のタグ（＜条件＞）に含まれる「銘柄Ａの現値が４，４５０円未満」を条件として記憶させる。そしてこの条件を条件ＩＤ「１０３」とする。また注文ＩＤ「４」と同様に、注文ＩＤ「５」の親注文（注文ＩＤ「３」）の注文の種類を示すタグ（＜排他注文＞）から、注文ＩＤ「５」の約定を監視する条件も条件ＩＤ「１０４」として記憶させる。

そして注文ＩＤ「５」の条件をクリアした場合の注文処理であることを示すタグ（＜アクション＞）から、銘柄、価格、数量について、「注文価格を成行として、銘柄Ａの１，０００株の売り注文」の注文属性を注文ＩＤ「５」の注文属性として注文属性記憶手段６に記憶させる。

このように注文ＩＤ「１」から注文ＩＤ「５」の注文属性が記憶された注文属性記憶手段６を図３に、条件が記憶された条件記憶手段７を図４に示す。なお、上述では注文属性を記憶した後に、条件を記憶しているが、この順序は逆でも良いし、同時に行っても良い。

このように注文属性が注文属性記憶手段６に記憶されると、当該注文に対して条件が指定されているか否かを判定し（Ｓ１５０）、条件が指定されていない注文について、発注手段１０は取引所システム２が注文を受け付けている時間帯であれば、取引市場システム２に対して発注の情報を送信する（Ｓ２００）。図３では、注文ＩＤ「１」が条件が指定されていないので、まずその処理を行う。しかしこれは子注文を有するだけなので、次にその子注文である注文ＩＤ「２」と注文ＩＤ「３」を処理する。

注文ＩＤ「２」には注文属性記憶手段６に条件が指定されていないので、銘柄「Ａ」、数量「１，０００」、価格「４，５００」、「買」の注文の情報を発注する。発注後、当該注文ＩＤに発注数の情報を記憶させる。例えば「発注数」を「１，０００」に変更する。このようにして発注後、その注文が約定した通知を取引市場システム２から受け取ったら、当該注文ＩＤの約定済みの情報を記憶させる。例えば「約定数」を「１，０００」に変更する。この状態を図９に示す。

一方、上記と並行して、注文ＩＤ「３」には注文属性記憶手段６に条件ＩＤ「１００」が指定されているので、条件を満たすまでは処理が行われない。また条件ＩＤ「１００」が設定されているので、条件記憶手段７の条件ＩＤ「１００」の監視状態を「ＯＦＦ」から「ＯＮ」に変更して、イベント監視手段８による監視を開始する。この状態の条件記憶手段７を図６に示す。

このように、条件がある注文（「条件がある」として条件記憶手段７、注文属性記憶手段６に記憶されている注文）については、イベント監視手段８が、条件記憶手段７に記憶された条件が成立しているか否かを監視している（Ｓ１６０）。ここでは、時価イベント、約定イベント、時刻イベントなどが監視する対象のイベントの例である。

上述のように、注文ＩＤ「２」が約定すると、条件記憶手段７に記憶する注文ＩＤ「３」の条件ＩＤ「１００」が成立したことが約定イベントの監視により分かる。これにより、イベント監視手段８は、条件記憶手段７の条件ＩＤ「１００」の監視状態をＯＦＦにし、また処理状態を処理済みに更新する。そして注文ＩＤ「３」の処理が開始される。注文ＩＤ「３」に対応する注文は連続注文の二番目の要素注文であるからその処理を行うが、これも子注文を有するだけなので、注文ＩＤ「３」の子注文である注文ＩＤ「４」、注文ＩＤ「５」の処理を行う。ここで注文属性記憶手段６には注文ＩＤ「４」の条件として条件ＩＤ「１０１」があり、また注文ＩＤ「５」の条件として条件ＩＤ「１０３」がある。従って、条件を満たすまでは注文ＩＤ「４」、注文ＩＤ「５」の処理は行われない。また条件ＩＤ「１０１」、条件ＩＤ「１０３」が設定されているので、条件記憶手段７に記憶する条件ＩＤ「１０１」、「１０３」の監視状態をＯＮに変更して、イベント監視手段８による監視を開始する。例えば、図６に示すような条件記憶手段７を図１０に示すように更新する。

この段階では、注文ＩＤ「４」、注文ＩＤ「５」については条件をクリアしていないので、条件を充足しておらず（Ｓ１６０）、イベント監視手段８はイベントの監視を継続する（Ｓ１７０）。

このようにしてイベント監視手段８がイベントの監視を継続した結果、例えば銘柄Ａの現値が４，６００円になったとする。そうすると、イベント監視手段８は、条件記憶手段７に記憶された注文ＩＤ「４」の条件ＩＤ「１０１」が成立したこと（処理状態を「済」にする）とその監視状態をＯＦＦにして条件記憶手段７を更新させる。この状態の条件記憶手段７が図１１である。またそれと共に、条件ＩＤ「１０２」を「ＯＮ」にする。この状態の条件記憶手段７が図１４である。条件記憶手段７に記憶した条件が成立した場合には、イベント監視手段８は、注文属性記憶手段６に記憶した当該注文ＩＤについて条件が成立したことを示す情報を記憶させる。またイベント監視手段８は、注文ＩＤ「４」の時価条件が成立したことを判定したので（Ｓ１６０）、発注手段１０に対して、注文ＩＤ「４」の発注指示を渡す。この状態の注文属性記憶手段６が図１２である。

発注手段１０は、イベント監視手段８から注文ＩＤ「４」の発注指示を受け取ったので、注文ＩＤ「２」の注文属性に、オブジェクトＩＤが含まれているか（即ち、注文属性が未確定であるか否か）を判定し（Ｓ１８０）、オブジェクトＩＤが含まれていなければ（注文属性が確定していれば）そのまま取引市場システム２に対して、注文を送信する（Ｓ２００）。

一方、注文属性にオブジェクトＩＤが含まれている場合（注文属性が未確定の場合）、発注手段１０は、そのオブジェクトＩＤと、注文属性記憶手段６に記憶するパラメータと、注文確定オブジェクトの処理指示を注文属性確定手段１１に渡す。ここではオブジェクトＩＤ「１０」と、パラメータとして、「銘柄Ａ」、「１５秒」の情報を渡す。

オブジェクトＩＤと、注文属性記憶手段６に記憶するパラメータと、注文確定オブジェクトの処理指示を受け取った注文属性確定手段１１は、そのオブジェクトＩＤに基づいてオブジェクト記憶手段９から検索することで、実行する注文確定オブジェクトを特定し、その注文確定オブジェクト（注文確定オブジェクトのコード）を実行して実行結果を返す。ここではオブジェクトＩＤ「１０」は、オブジェクト記憶手段９では、「（銘柄Ｘ）の直近（Ｙ秒）の価格の２次補間による価格算出」の注文確定オブジェクト（カッコ内はパラメータを示す）なので、「銘柄Ａの直近１５秒の価格の２次補間による価格算出」の注文確定オブジェクトを実行する。従って、この場合、注文属性確定手段１１は、銘柄Ａの直近１５秒の価格を、所定の価格を提供するサーバから取得して２次補間による算出をした後に、その算出結果を発注手段１０に返す。例えば「４，５９０円」として返す。なお、価格や数量は、それぞれの銘柄毎に発注できる単位が指定されているので、その単位ではない場合には、最も近い価格、数量等に近似した上で発注手段１０に返すと良い。

注文属性確定手段１１から実行結果を受け取った発注手段１０は、その時点で注文属性を確定し（Ｓ１９０）、それに基づいて、取引市場システム２に注文を発注する（Ｓ２００）。例えば価格「４，５９０円」を受け取ることによって、注文ＩＤ「４」の注文属性は、銘柄「Ａ」、数量「１，０００」、価格「４，５９０」円、「売り」で確定したので、注文属性における価格を「４，５９０」円で更新して、発注手段１０は、注文を発注する（Ｓ２００）。なお、複数の注文確定オブジェクトが一つの注文属性に含まれている場合には、各注文確定オブジェクトについて処理を実行し、注文属性を確定させた上で注文を発注する。

そして発注手段１０は、注文属性記憶手段６に記憶する、注文ＩＤ「４」の発注数を示す情報を「０」から「１，０００」に変更して記憶させる。この状態を図１３に示す。

そしてイベント監視手段８の約定イベントの監視の結果、注文ＩＤ「４」が約定すれば、条件ＩＤ「１０２」が成立する。そこでイベント監視手段８は、条件記憶手段７の条件ＩＤ「１０２」の処理状態を「済」にして監視状態を「ＯＦＦ」に更新する。注文ＩＤ「５」は注文ＩＤ「３」の排他注文であり、注文ＩＤ「４」が成立したことによって、取り消されるべき注文である。従って、注文属性記憶手段６の注文ＩＤ「５」の条件ＩＤ「１０３」、条件ＩＤ「１０４」については、条件記憶手段７に取り消しの情報が記憶され、またそれらの監視状態も「ＯＦＦ」に更新される。この状態の条件記憶手段７を図１５に示す。なお時価の動きによっては、注文ＩＤ「４」が約定する前に、条件ＩＤ「１０３」が成立して、注文ＩＤ「５」の注文が発注される場合もある。この場合には注文ＩＤ「５」の注文の取り消し要求を取引所システム２に送信する。

また注文ＩＤ「４」が約定したので、注文属性記憶手段６の注文ＩＤ「４」の約定数が「０」から「１０００」に更新され記憶される。また注文ＩＤ「４」の親注文「３」は、注文ＩＤ「４」と注文ＩＤ「５」の排他注文なので、注文ＩＤ「５」について注文取り消しの情報を注文属性記憶手段６に記憶させ、注文を取り消しする。この状態の注文属性記憶手段６を図１６に示す。

上記で説明した排他注文は、約定に対して排他処理を行うが、発注そのものに排他処理を行う方式もある。つまり、排他注文の要素注文が時価条件注文のように、何らかの条件が成立した場合のみ発注されるような場合、ある一つの要素注文からある株数が発注された場合に、その要素注文の全株数に対して発注された注文の割合だけ、他の要素注文を取り消す。

以上のような処理を実行することで、図７に示す一連の注文処理を行うことが出来る。また従来のように、変数が決定した段階で発注条件と注文属性とを確定させず、注文属性を発注する直前で確定させることが出来るので、よりマーケットの状況に対応させることが出来る。

また注文確定オブジェクトを取り扱うことが出来るので、様々な注文を取り扱うことが出来る。

本発明に於ける各手段は、その機能が論理的に区別されているのみであって、物理上あるいは事実上は同一の領域を為していても良い。また各記憶手段には、データベースやデータファイル、あるマシン上にあるプロセスのメモリ空間などの形式を用いることが出来る。また、データは同一のコピーが異なったマシンの異なった記憶領域に同時に格納されても良い。

なお注文属性記憶手段６に記憶した注文属性における注文確定オブジェクトに関する処理について、上述の実施例では取引システム１で実行する場合を説明したが、取引システム１の発注手段１０からは、注文属性として注文確定オブジェクトのオブジェクトＩＤを含んだまま取引市場システム２に対して発注されても良い。この場合、取引市場システム２には、上述の実施例における注文属性確定手段１１とオブジェクト記憶手段９に相当する機能が備えられている。

即ち、オブジェクトＩＤを含んだ注文属性を取引システム１から受け取ることにより、取引市場システムにおいて売買の注文のマッチングを行う直前に、注文確定オブジェクトを値として確定させることにより、上述の実施例より更にタイムラグの少ないシステムを構成することが出来る。

例えば、注文属性記憶手段６が図１２に示す場合、上述の実施例では、注文ＩＤ「４」に含まれる注文確定オブジェクト（オブジェクトＩＤ「１０」）を値として確定させた後に、発注手段１０が取引市場システム２に注文属性を発注している。つまり、注文ＩＤ「４」について、「銘柄Ａを１，０００株、４，５９０円で売り」のように確定した後に発注している。しかし、これを注文ＩＤ「４」に注文確定オブジェクト（オブジェクトＩＤ「１０」を含んだまま発注手段１０が発注する。例えば「銘柄Ａを１，０００株、オブジェクトＩＤ「１０」で算出した価格で売り」のように発注手段１０が発注する。

この注文属性を受け取った取引市場システム２は、オブジェクトＩＤ「１０」の処理を、取引市場システム２に備えるオブジェクト記憶手段１１に基づいて行った後に（即ち、オブジェクトＩＤ「１０」に基づいて価格を算出した後に）、取引市場システム２においてその価格を確定し、マッチングを行うように構成することも出来る。また取引市場システム２にはオブジェクトＩＤではなく、注文確定オブジェクトそのものを電文化して送っても良い。

本発明を用いることによって、発注条件を満たした注文を、取引市場のシステムに発注する直前のタイミングで注文属性を確定する取引システム１とすることが出来る。その為、従来のように、変数が決定されたタイミングから発注条件を満たすタイミングまでの間の価格変動などのマーケットの変化に対して、十分に対応することが出来ないリスクを被ることがない。従って、投資家も従来よりも、よりしっかりとリスク管理を行った投資行動をとることが出来る。

またタイムラグによるリスクもないので、注文属性に様々な計算方法を表現するオブジェクトを設定することが出来、注文属性の計算方法の多様化が可能となり、投資家の利便性が向上する。

本発明の取引システムの概念図である。 本発明の取引システムの処理プロセスの一例を示したフローチャートである。 注文属性記憶手段の一例である。 条件記憶手段の一例である。 オブジェクト記憶手段の一例である。 条件ＩＤ「１００」が監視状態になった条件記憶手段の一例である。 注文の内容を示すコードの一例である。 注文が階層構造であることを示す概念図である。 注文ＩＤ「２」が約定した後の注文属性記憶手段の一例である。 条件ＩＤ「１０１」、条件ＩＤ「１０３」が監視状態になった条件記憶手段の一例である。 条件ＩＤ「１０１」が成立した状態を示す条件記憶手段の一例である。 注文ＩＤ「４」について価格を確定する前の注文属性記憶手段の一例である。 注文ＩＤ「４」の価格を確定した後の条件記憶手段の一例である。 条件ＩＤ「１０２」が監視状態になった条件記憶手段の一例である。 条件ＩＤ「１０２」が成立し、条件ＩＤ「１０３」、条件ＩＤ「１０４」が取り消された状態の条件記憶手段の一例である。 注文ＩＤ「４」が約定し、注文ＩＤ「５」が取り消された状態の注文属性記憶手段の一例である。

符号の説明

１：取引システム
２：取引市場システム
３：投資家端末
４：注文受付手段
５：注文ＩＤ割当手段
６：注文属性記憶手段
７：条件記憶手段
８：イベント監視手段
９：オブジェクト記憶手段
１０：発注手段
１１：注文属性確定手段

Claims (8)

1. 投資家が利用する投資家端末から売買の注文を受け付け、それを取引市場が利用する取引市場システムに発注する取引システムであって、
   前記取引システムは、
   前記投資家端末から売買の注文を受け付ける注文受付手段と、
   前記受け付けた注文における注文属性を注文属性記憶手段に記憶させ、また前記注文に条件が含まれている場合には前記条件を条件記憶手段に記憶させる手段と、
   時価イベント、約定イベント、時刻イベントのうち少なくとも一以上のイベントを監視し、前記条件記憶手段に記憶した条件を満たすかを判定するイベント監視手段と、
   前記条件が含まれていない注文、又は前記注文における条件を満たした注文について、前記注文属性記憶手段に記憶した注文属性に基づいて確定された注文属性を前記取引市場システムに発注する発注手段と、
   前記発注手段が発注する注文について、未確定の注文属性を含む場合には、オブジェクト記憶手段に記憶している、注文属性を確定する処理が記述された注文確定オブジェクトの処理を実行し、その結果を前記発注手段に返す注文属性確定手段と、を有しており、
   前記発注手段は、少なくとも前記未確定の注文属性に含まれる、前記注文確定オブジェクトを識別するオブジェクトＩＤ又は前記注文確定オブジェクトを前記注文属性確定手段に渡し、
   前記注文属性確定手段は、与えられた前記注文確定オブジェクト又は前記オブジェクトＩＤに基づいて、前記オブジェクト記憶手段から得られる前記注文確定オブジェクトの処理を実行して、その結果を前記発注手段に返し、
   前記発注手段は、前記注文確定オブジェクトの実行結果を受け取って、前記未確定の注文属性の部分を前記実行結果に変更することにより、前記注文属性を確定した注文属性に変更した上で、前記確定した注文属性を前記取引市場システムに発注する、
   ことを特徴とする取引システム。
2. 前記注文ＩＤ割当手段は、
   前記注文に含まれる識別子に基づいて、条件の付いた注文属性と条件とを特定する、
   ことを特徴とする請求項１に記載の取引システム。
3. 前記発注手段は、
   前記注文属性に前記オブジェクトＩＤ又は前記注文確定オブジェクトが含まれている場合には、未確定の注文属性であると判定し、前記オブジェクトＩＤ又は前記注文確定オブジェクトが含まれていない場合には確定された注文属性であると判定する、
   ことを特徴とする請求項１に記載の取引システム。
4. 前記オブジェクトは、
   データ、又はデータと一以上の処理命令から構成されるコードである、
   ことを特徴とする請求項１に記載の取引システム。
5. 投資家が利用する投資家端末から売買の注文を受け付け、それを取引市場が利用する取引市場システムに発注する取引システムであって、
   前記取引システムは、
   前記投資家端末から売買の注文を受け付ける注文受付手段と、
   前記売買の注文を構成する各要素注文に対して、前記要素注文を特定するデータである注文ＩＤを割り当て、前記要素注文の注文属性と条件を示す情報とを前記注文ＩＤと対応付けて注文属性記憶手段に記憶させ、また前記要素注文に条件が含まれている場合には前記条件を前記注文ＩＤと対応付けて条件記憶手段に記憶させる注文ＩＤ割当手段と、
   時価イベント、約定イベント、時刻イベントのうち少なくとも一以上のイベントを監視し、前記条件記憶手段に記憶した条件を満たした場合にはその旨の情報を記憶させるイベント監視手段と、
   前記注文属性記憶手段に条件を示す情報がない注文、又は前記注文における条件が満たされたことを示す情報が記憶された注文について、前記注文ＩＤに基づいて、前記注文属性記憶手段に記憶した注文属性を抽出し、確定した注文属性を前記取引市場システムに発注する発注手段と、
   前記発注手段が発注する注文について、前記注文属性にオブジェクトＩＤを含む場合には、前記発注手段から前記オブジェクトＩＤを受け取り、前記オブジェクトＩＤに対応する注文確定オブジェクトの処理を実行して、その結果を前記発注手段に返す注文属性確定手段と、を有しており、
   前記発注手段は、
   前記注文の発注の前に、前記注文ＩＤに対応する注文属性にオブジェクトＩＤが含まれているかを判定し、
   オブジェクトＩＤが含まれていない場合にはそのまま確定した注文属性を前記取引市場システムに発注し、
   オブジェクトＩＤが含まれている場合には少なくとも前記オブジェクトＩＤを前記注文属性確定手段に渡し、前記注文属性確定手段から前記オブジェクトＩＤに対応する前記注文確定オブジェクトの実行結果を受け取って、前記未確定の注文属性の部分を前記実行結果に変更することにより、確定した注文属性に変更した上で、前記確定した注文属性を前記取引市場システムに発注する、
   ことを特徴とする取引システム。
6. 投資家が利用する投資家端末から売買の注文を受け付け、それを取引市場が利用する取引市場システムに発注するコンピュータで処理を実行させる取引方法であって、
   前記取引方法を実行するコンピュータは、
   前記投資家端末から売買の注文を受け付けて、前記注文における注文属性を注文属性記憶手段に記憶し、前記注文に条件が含まれている場合には更に前記条件を条件記憶手段に記憶し、
   前記注文において条件が含まれていない場合には前記取引市場システムに前記注文属性記憶手段に記憶した注文属性が確定された注文属性であるかを判定し、
   前記確定された注文属性の場合には、前記取引市場システムに前記確定された注文属性で発注し、
   前記未確定の注文属性の場合には、前記未確定の注文属性で指定された注文確定オブジェクトを実行することで、前記未確定の注文属性における未確定の部分を前記注文確定オブジェクトの実行結果に変更することにより、確定された注文属性に変更した上で、前記取引市場システムに前記確定された注文属性を発注し、
   時価イベント、約定イベント、時刻イベントのうち少なくとも一以上のイベントを監視して、前記条件記憶手段に記憶した条件を満たすかを判定し、
   前記注文における全ての条件を満たした注文について、前記注文属性記憶手段に記憶した注文属性が確定された注文属性であるかを判定し、
   前記確定された注文属性の場合には、前記取引市場システムに前記確定された注文属性で発注し、
   前記未確定の注文属性の場合には、前記未確定の注文属性で指定された注文確定オブジェクトを実行することで、前記未確定の注文属性における未確定の部分を前記注文確定オブジェクトの実行結果に変更して、確定された注文属性に変更した上で、前記取引市場システムに前記確定された注文属性を発注する、
   ことを特徴とする取引方法。
7. 投資家が利用する投資家端末から売買の注文を受け付ける取引システムから、未確定の注文属性の発注を受け取る取引市場システムであって、
   前記取引市場システムは、
   前記注文属性に含まれる未確定の注文属性に関する処理が記述された注文確定オブジェクトの処理を実行し、前記未確定の注文属性の部分を前記実行結果に変更することで確定した注文属性に変更する注文属性確定手段と、
   前記確定した注文属性を、他の注文の確定した注文属性とマッチングさせることで売買の成立をさせる手段と、
   を有することを特徴とする取引市場システム。
8. 投資家が利用する投資家端末から売買の注文を受け付ける取引システムから、未確定の注文属性の発注を受け取る取引市場システムであって、
   前記取引市場システムは、
   前記注文属性に含まれる未確定の注文属性に関する処理が記述された注文確定オブジェクトをオブジェクトＩＤと対応付けて記憶するオブジェクト記憶手段と、
   前記取引システムから、未確定の注文属性を受け取る手段と、
   前記未確定の注文属性に含まれるオブジェクトＩＤに基づいて、前記オブジェクトＩＤに対応する注文確定オブジェクトの処理を実行し、前記未確定の注文属性の部分を前記実行結果に変更することで確定した注文属性に変更する注文属性確定手段と、
   前記確定した注文属性を、他の注文の確定した注文属性とマッチングさせることで売買の成立をさせる手段と、
   を有することを特徴とする取引市場システム。
   

Images