(57)【要約】【課題】  端株取引の発注者からの注文に対して、その注文通りに端株取引を実行するとともに、注文があった後できるだけ早期に約定を成立させ、更には、その約定の成立結果を発注者がすぐに確認することができるようにした端株取引システムを提供する。【解決手段】  注文データの受付手段８と、注文データの格納手段２２と、各注文データに対応する処理用データの生成手段１１と、株式の在庫情報の格納手段２５と、株式銘柄毎の必要株数の集計手段１２と、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理手段１３と、各株式銘柄の値段情報の取得手段１５と、値段情報が取得された株式銘柄についての処理用データの約定処理手段１６と、約定処理が行われた処理用データに対応する注文データの更新手段１７と、注文データ格納手段２２に格納された注文データを発注元装置３ａ〜ｃに送信可能とする結果送信手段１９、２７、８とを備える。【選択図】        図１
2006277070.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付ける注文受付手段と、
前記注文データを格納する注文データ格納手段と、
前記注文データに基づいて各注文データに対応する処理用データを生成する処理用データ生成手段と、
前記処理用データを格納する処理用データ格納手段と、
株式の在庫情報を格納する株式在庫情報格納手段と、
前記処理用データに基づいて株式銘柄毎の必要株数を集計する必要株数集計手段と、
前記必要株数集計手段による集計結果と前記在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理手段と、
各株式銘柄についての値段情報を取得する値段情報取得手段と、
前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする処理用データについての約定処理を行う約定処理手段と、
前記約定処理が行われた処理用データについて、当該処理用データに対応する、前記注文データ格納手段に格納された注文データに対して、前記約定処理の結果情報を追加する更新を行う注文データ更新手段と、
前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能とする結果送信手段と、
を備える端株取引システム。
【請求項２】
前記処理用データ生成手段は、前記注文データに、システム内での処理に必要な情報の格納領域を付加して前記処理用データを生成する請求項１に記載の端株取引システム。
【請求項３】
前記処理用データに基づいて端株取引の注文を受け付けた株式銘柄を集計した銘柄データを生成する銘柄データ生成手段を備え、
前記値段情報取得手段は、前記銘柄データに含まれる株式銘柄についての値段情報を取得する処理を行う請求項１又は２に記載の端株取引システム。
【請求項４】
前記約定処理手段は、前記値段情報が取得された株式銘柄を取引対象とする処理用データを前記処理用データ格納手段から検索し、検索された各処理用データに対応させて、前記値段情報に従って決定された約定値段を含む約定データを生成する請求項１から３の何れか一項に記載の端株取引システム。
【請求項５】
市場での取引終了後に、前記処理用データ格納手段から約定処理が行われていない処理用データを検索し、当該処理用データに対応する、前記注文データ格納手段に格納された注文データに対して、前記約定処理の結果情報として不出来情報を追加する更新を行う不出来処理手段を備える請求項１から４の何れか一項に記載の端株取引システム。
【請求項６】
株式銘柄毎に取引可能か否かに関する情報が格納された株式銘柄情報格納手段と、前記注文データの送信を許可された発注者に関する情報が格納された発注者情報格納手段と、前記株式銘柄情報格納手段及び前記発注者情報格納手段に格納された情報に基づいて、前記発注元装置から受信した注文データが処理可能か否かを確認する注文データ確認手段と、を備え、
前記処理用データ生成手段は、前記注文データ確認手段により処理可能とされた注文データに対応する処理用データを生成する請求項１から５の何れか一項に記載の端株取引システム。
【請求項７】
前記注文データは、前記注文データ確認手段による確認結果を表す確認結果情報の格納領域を備えたデータ構造を有する請求項６に記載の端株取引システム。
【請求項８】
通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付ける注文受付手段と、
前記注文データを格納する注文データ格納手段と、
株式の在庫情報を格納する株式在庫情報格納手段と、
前記注文データに基づいて株式銘柄毎の必要株数を集計する必要株数集計手段と、
前記必要株数集計手段による集計結果と前記在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理手段と、
各株式銘柄についての値段情報を取得する値段情報取得手段と、
前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする注文データについての約定処理を行う約定処理手段と、
前記約定処理が行われた注文データについて、前記約定処理の結果情報を追加する更新を行う注文データ更新手段と、
前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能とする結果送信手段と、
を備える端株取引システム。
【請求項９】
前記注文データは、前場取引用の注文か後場取引用の注文かを表す前後場区分情報、及び前場取引用の注文である場合であって前場に約定が成立しなかった場合に注文を後場に引き継ぐか否かを表す引継区分情報の格納領域を備えたデータ構造を有する請求項１から８の何れか一項に記載の端株取引システム。
【請求項１０】
前記注文データは、発注者を識別するための発注者識別情報、端株取引の注文内容を表す注文内容情報、及び前記約定処理手段による約定処理の結果情報を表す約定情報の格納領域を備えたデータ構造を有する請求項１から９の何れか一項に記載の端株取引システム。
【請求項１１】
前記値段情報取得手段は、前記値段情報として、寄付値情報を取得する請求項１から１０の何れか一項に記載の端株取引システム。
【請求項１２】
通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付けて注文データ格納手段に格納する注文受付ステップと、
前記注文データに基づいて各注文データに対応する処理用データを生成して処理用データ格納手段に格納する処理用データ生成ステップと、
株式の在庫情報を取得する株式在庫情報取得ステップと、
前記処理用データに基づいて株式銘柄毎の必要株数を集計する必要株数集計ステップと、
前記必要株数集計ステップによる集計結果と前記株式在庫情報取得ステップにより取得された在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理ステップと、
各株式銘柄についての値段情報を取得する値段情報取得ステップと、
前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする処理用データについての約定処理を行う約定処理ステップと、
前記約定処理が行われた処理用データについて、当該処理用データに対応する、前記注文データ格納手段に格納された注文データに対して、前記約定処理の結果情報を追加する更新を行う注文データ更新ステップと、
前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能な状態とする結果送信ステップと、
をコンピュータに実行させるための端株取引プログラム。
【請求項１３】
通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付けて注文データ格納手段に格納する注文受付ステップと、
株式の在庫情報を取得する株式在庫情報取得ステップと、
前記注文データに基づいて株式銘柄毎の必要株数を集計する必要株数集計ステップと、
前記必要株数集計ステップによる集計結果と前記株式在庫情報取得ステップにより取得された在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理ステップと、
各株式銘柄についての値段情報を取得する値段情報取得ステップと、
前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする注文データについての約定処理を行う約定処理ステップと、
前記約定処理が行われた注文データについて、前記約定処理の結果情報を追加する更新を行う注文データ更新ステップと、
前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能な状態とする結果送信ステップと、
をコンピュータに実行させるための端株取引プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、株式銘柄毎に定められている売買単位数未満の端株の取引を行うための端株取引システム及びそのシステムにおいて用いる端株取引プログラムに関する。
【背景技術】
【０００２】
証券取引所における株式の売買は、株式銘柄毎に定められている売買単位数毎に行われる。一方、証券会社等では、個人投資家による小口売買、或いは新株式の割当発行や分割等により発生する売買単位数未満の株式の取引、すなわち端株取引の需要がある。
このような端株取引を支援するための技術として、例えば下記特許文献１には、以下のようなシステムが開示されている。
【０００３】
このシステムは、図１２に示すように、証券会社が運用するものであって、店頭端末５４や顧客端末５５と接続された端株仲介人システム５１と、この端株仲介人システム５１に接続された証券取引所システム５２並びに同業仲介人システム５３とから構成されている。そして、これらの中で中心的な構成である端株仲介人システム５１は、端株取引の注文を店頭端末５４や顧客端末５５から受信し、単位株数と端株の総注文株数との差を計算して顧客などに提供し、或いは各注文に対して割り当てられた株数や注文残数を記憶装置に記録するなどの処理を実施する注文受付管理部５１ａと、単位株数の注文を例えば証券取引所システム５２に対して出力すべきタイミングを所定の基準にて判断し、当該タイミングにて注文を発行する単位株注文発行部５１ｂと、例えば証券取引所システム５２から株価等の情報を取得して顧客などに提供する株価提供処理部５１ｃと、端株の総注文株数が単位株数を超えてしまった場合に各顧客に割り当てられる株数を決定する株割当処理部５１ｄとを有している。
【０００４】
そして、このシステムは、端株仲介人システム５１を運用する証券会社が、売れ残りの端株在庫を多数抱えることによって株式の価格変動による損失を被らないようにするため、顧客等から受け付けた端株取引の売買注文に対して、実際に顧客等に割り当てる株数を調整する処理を行うものとなっている。
具体的には、以下のような処理を行う。すなわち、まず特定の株式銘柄の端株売注文又は端株買注文を受け付ける。次に、受け付けられた端株売注文の総株数又は端株買注文の総株数が、売買単位株数及び証券会社が設定した売買手数料により決定された閾値を超えたか否か判断する。端株売注文の総株数又は端株買注文の総株数が前記決定された閾値を超えたと判断された場合には、端株売注文に対して特定の株式銘柄の売買単位株数の売注文又は端株買注文に対して単位株数の買注文を行う。そして総買注文又は総売注文株数が単位株数を超えたか否かを判断し、もし超えてしまった場合には買注文又は売注文のうち最小注文株数を全顧客に配布し、未割当株を各注文残の荷重平均で割り当てる。
【０００５】
【特許文献１】特開２００２−１３３１０６号公報（第３−６頁、第１−２図）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記のシステムは、端株仲介人システム５１を運用する証券会社が、売れ残りの端株在庫を多数抱えることによって株式の価格変動による損失を被らないようにすることを目的とするものである。そのため、顧客等の端株取引の発注者からすれば、売買の注文を行うことができる株数に制限を受ける場合や、売買注文を行ったにも関わらず注文通りの株数の売買が実行されない場合があるという問題が存在する。
【０００７】
また、同様の理由により、上記のシステムでは、営業終了時刻等に設定された所定時刻を経過した後に、各発注者に対して注文株数に応じて株割当処理を実行するため、当該所定時刻が経過するまでは約定が成立しない。そのため、発注者が端株売買の結果に基づいて同じ日の内に次の売買注文を行うことができず、自己の資金や資産を有効に活用できない場合があるという問題が存在する。
【０００８】
本発明は、上記の課題に鑑みてなされたものであり、その目的は、顧客等の端株取引の発注者からの注文に対して、その注文通りに端株取引を実行するとともに、注文があった後できるだけ早期に約定を成立させ、更には、その約定の成立結果を発注者がすぐに確認することができるようにした端株取引システム、及びそのシステムを構成するための端株取引プログラムを提供する点にある。
【課題を解決するための手段】
【０００９】
上記目的を達成するための本発明に係る端株取引システムの特徴構成は、通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付ける注文受付手段と、前記注文データを格納する注文データ格納手段と、前記注文データに基づいて各注文データに対応する処理用データを生成する処理用データ生成手段と、前記処理用データを格納する処理用データ格納手段と、株式の在庫情報を格納する株式在庫情報格納手段と、前記処理用データに基づいて株式銘柄毎の必要株数を集計する必要株数集計手段と、前記必要株数集計手段による集計結果と前記在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理手段と、各株式銘柄についての値段情報を取得する値段情報取得手段と、前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする処理用データについての約定処理を行う約定処理手段と、前記約定処理が行われた処理用データについて、当該処理用データに対応する、前記注文データ格納手段に格納された注文データに対して、前記約定処理の結果情報を追加する更新を行う注文データ更新手段と、前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能とする結果送信手段と、を備える点にある。
【００１０】
この特徴構成によれば、発注元装置から受け付けた各注文データに対応して生成された処理用データに従い、株式銘柄毎の必要株数を集計して在庫株数が不足する銘柄については買付処理を実行し、値段情報が取得された株式銘柄を取引対象とする処理用データについて順次約定処理を行うため、顧客等からの注文データにより指定された注文通りに端株取引を実行するとともに、注文データを受け付けた後、その注文データで指定された株式銘柄について値段が付いて約定を成立させることができるようになった時点ですぐに約定を成立させる処理を行うことができる。
また、約定処理が行われた処理用データについては、それに対応する注文データに対して約定処理の結果情報を追加する更新を行い、その注文データを発注元装置に送信可能とするので、注文データの発注者は、その注文に対する約定の成立結果をすぐに確認することができる。
【００１１】
ここで、前記処理用データ生成手段は、前記注文データに、システム内での処理に必要な情報の格納領域を付加して前記処理用データを生成する構成とすると好適である。
これにより、端株取引システムの内部において処理を迅速に実行することができる。
【００１２】
また、前記処理用データに基づいて端株取引の注文を受け付けた株式銘柄を集計した銘柄データを生成する銘柄データ生成手段を備え、前記値段情報取得手段は、前記銘柄データに含まれる株式銘柄についての値段情報を取得する処理を行う構成とすると好適である。
【００１３】
これにより、値段情報取得手段において、上場されている全ての銘柄についての値段情報を取得することなく、端株取引の注文があった株式銘柄についての値段情報のみを取得することになるので、値段情報として取得する情報量を抑えることができる。したがって、値段情報の取得のためのコストやシステムの負荷を軽減することができる。また、約定処理手段による約定処理の際に、無用な値段情報が取得されることにより生じる処理負荷の増大を防ぐことができる。
【００１４】
また、前記約定処理手段は、前記値段情報が取得された株式銘柄を取引対象とする処理用データを前記処理用データ格納手段から検索し、検索された各処理用データに対応させて、前記値段情報に従って決定された約定値段を含む約定データを生成する構成とすると好適である。
【００１５】
これにより、約定処理を行うことが可能となった処理用データのすべてについて確実に約定処理を行うことができる。また、各処理用データに対応させて約定値段を含む約定データを生成するので、注文データ更新手段において、処理用データに対応する注文データに対して約定処理の結果情報を追加する更新を容易に行うことができる。
【００１６】
また、市場での取引終了後に、前記処理用データ格納手段から約定処理が行われていない処理用データを検索し、当該処理用データに対応する、前記注文データ格納手段に格納された注文データに対して、前記約定処理の結果情報として不出来情報を追加する更新を行う不出来処理手段を備える構成とすると好適である。
【００１７】
これにより、市場での取引の終了までに値段が付かずに不出来となった株式銘柄を取引対象とする注文データに対して、不出来となったことを表す情報を追加する更新を行うことになるので、注文データの発注者は、その注文が不出来となったことを、市場での取引終了後すぐに確認することができる。
【００１８】
また、株式銘柄毎に取引可能か否かに関する情報が格納された株式銘柄情報格納手段と、前記注文データの送信を許可された発注者に関する情報が格納された発注者情報格納手段と、前記株式銘柄情報格納手段及び前記発注者情報格納手段に格納された情報に基づいて、前記発注元装置から受信した注文データが処理可能か否かを確認する注文データ確認手段と、を備え、前記処理用データ生成手段は、前記注文データ確認手段により処理可能とされた注文データに対応する処理用データを生成する構成とすると好適である。
【００１９】
これにより、取引可能な株式銘柄についての注文データや、注文データの送信を許可された正規の発注者からの注文データのみに基づいて処理用データを生成して約定処理等を行うことになるので、異常な注文データに基づいて無駄な処理を行うことを回避することができる。
【００２０】
また、前記注文データは、前記注文データ確認手段による確認結果を表す確認結果情報の格納領域を備えたデータ構造を有する構成とすると好適である。
【００２１】
ここで、注文データ確認手段により処理可能か否かの確認が行われた注文データは、処理の可否に関わらず注文データ格納手段に格納される。したがって、このように注文データが注文データ確認手段による確認結果を表す確認結果情報の格納領域を備えることにより、注文データの発注者は、発注元装置に送信可能とされた注文データを受信して前記確認結果情報の格納領域を参照することにより、送信した注文データが処理可能であったか処理不可能であったかの結果をすぐに確認することができる。
【００２２】
本発明に係る端株取引システムの更なる特徴構成は、通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付ける注文受付手段と、前記注文データを格納する注文データ格納手段と、株式の在庫情報を格納する株式在庫情報格納手段と、前記注文データに基づいて株式銘柄毎の必要株数を集計する必要株数集計手段と、前記必要株数集計手段による集計結果と前記在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理手段と、各株式銘柄についての値段情報を取得する値段情報取得手段と、前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする注文データについての約定処理を行う約定処理手段と、前記約定処理が行われた注文データについて、前記約定処理の結果情報を追加する更新を行う注文データ更新手段と、前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能とする結果送信手段と、を備える点にある。
【００２３】
この特徴構成によれば、発注元装置から受け付けた各注文データに従い、株式銘柄毎の必要株数を集計して在庫株数が不足する銘柄については買付処理を実行し、値段情報が取得された株式銘柄を取引対象とする注文データについて順次約定処理を行うため、顧客等からの注文データにより指定された注文通りに端株取引を実行するとともに、注文データを受け付けた後、その注文データで指定された株式銘柄について値段が付いて約定を成立させることができるようになった時点ですぐに約定を成立させる処理を行うことができる。
また、約定処理が行われた注文データに対して約定処理の結果情報を追加する更新を行い、その注文データを発注元装置に送信可能とするので、注文データの発注者は、その注文に対する約定の成立結果をすぐに確認することができる。
【００２４】
ここで、前記注文データは、前場取引用の注文か後場取引用の注文かを表す前後場区分情報、及び前場取引用の注文である場合であって前場に約定が成立しなかった場合に注文を後場に引き継ぐか否かを表す引継区分情報の格納領域を備えたデータ構造を有する構成とすると好適である。
【００２５】
これにより、前場取引用の注文データを発注する発注者は、前場に約定が成立せずに不出来となった場合に、同じ注文を後場に引き継ぐか否かを任意に選択することが可能となる。
【００２６】
また、注文データは、この端株取引システムにおいてその機能を適正に果たすために、発注者を識別するための発注者識別情報、端株取引の注文内容を表す注文内容情報、及び前記約定処理手段による約定処理の結果情報を表す約定情報の格納領域を備えたデータ構造を有する構成とすると好適である。
【００２７】
また、前記値段情報取得手段は、前記値段情報として、寄付値情報を取得する構成とすると好適である。
これにより、最も早く定まる値段である寄付値を約定値段とすることになるので、早い段階で約定処理を行うことが可能となる。
【００２８】
本発明に係る端株取引プログラムの特徴構成は、通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付けて注文データ格納手段に格納する注文受付ステップと、前記注文データに基づいて各注文データに対応する処理用データを生成して処理用データ格納手段に格納する処理用データ生成ステップと、株式の在庫情報を取得する株式在庫情報取得ステップと、前記処理用データに基づいて株式銘柄毎の必要株数を集計する必要株数集計ステップと、前記必要株数集計ステップによる集計結果と前記株式在庫情報取得ステップにより取得された在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理ステップと、各株式銘柄についての値段情報を取得する値段情報取得ステップと、前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする処理用データについての約定処理を行う約定処理ステップと、前記約定処理が行われた処理用データについて、当該処理用データに対応する、前記注文データ格納手段に格納された注文データに対して、前記約定処理の結果情報を追加する更新を行う注文データ更新ステップと、前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能な状態とする結果送信ステップと、をコンピュータに実行させる点にある。
【００２９】
この端株取引プログラムを実行するコンピュータを用いたシステムによれば、発注元装置から受け付けた各注文データに対応して生成された処理用データに従い、株式銘柄毎の必要株数を集計して在庫株数が不足する銘柄については買付処理を実行し、値段情報が取得された株式銘柄を取引対象とする処理用データについて順次約定処理を行うため、顧客等からの注文データにより指定された注文通りに端株取引を実行するとともに、注文データを受け付けた後、その注文データで指定された株式銘柄について値段が付いて約定を成立させることができるようになった時点ですぐに約定を成立させる処理を行うことができる。また、約定処理が行われた処理用データについては、それに対応する注文データに対して約定処理の結果情報を追加する更新を行い、その注文データを発注元装置に送信可能とするので、注文データの発注者は、その注文に対する約定の成立結果をすぐに確認することができる。
【００３０】
本発明に係る端株取引プログラムの更なる特徴構成は、通信ネットワークを介して接続された発注元装置からの端株取引についての１又は２以上の注文データを受け付けて注文データ格納手段に格納する注文受付ステップと、株式の在庫情報を取得する株式在庫情報取得ステップと、前記注文データに基づいて株式銘柄毎の必要株数を集計する必要株数集計ステップと、前記必要株数集計ステップによる集計結果と前記株式在庫情報取得ステップにより取得された在庫情報とを対比して、在庫株数が不足する銘柄についての売買単位数毎の株式の買付処理を実行する買付処理ステップと、各株式銘柄についての値段情報を取得する値段情報取得ステップと、前記値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする注文データについての約定処理を行う約定処理ステップと、前記約定処理が行われた注文データについて、前記約定処理の結果情報を追加する更新を行う注文データ更新ステップと、前記注文データ格納手段に格納された注文データを前記発注元装置に送信可能な状態とする結果送信ステップと、をコンピュータに実行させる点にある。
【００３１】
この端株取引プログラムを実行するコンピュータを用いたシステムによれば、発注元装置から受け付けた各注文データに従い、株式銘柄毎の必要株数を集計して在庫株数が不足する銘柄については買付処理を実行し、値段情報が取得された株式銘柄を取引対象とする注文データについて順次約定処理を行うため、顧客等からの注文データにより指定された注文通りに端株取引を実行するとともに、注文データを受け付けた後、その注文データで指定された株式銘柄について値段が付いて約定を成立させることができるようになった時点ですぐに約定を成立させる処理を行うことができる。また、約定処理が行われた注文データに対して約定処理の結果情報を追加する更新を行い、その注文データを発注元装置に送信可能とするので、注文データの発注者は、その注文に対する約定の成立結果をすぐに確認することができる。
【発明を実施するための最良の形態】
【００３２】
〔第一の実施形態〕
以下に、本発明の第一の実施形態について図面に基づいて説明する。図１は、本発明の第一の実施形態に係る端株取引システム１の概略図である。
【００３３】
本実施形態においては、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）等の通信ネットワーク２を介して接続された顧客側装置３ａ、３ｂ、３ｃから端株取引についての注文データを受信する場合を例として説明する。この例では、顧客側装置３ａ、３ｂ、３ｃが本発明における「発注元装置」に相当する。
なお、この端株取引システム１の顧客としては、一般投資家や、一般投資家に対する端株取引のサービス提供窓口となる証券会社等が含まれる。したがって、顧客側装置３ａ、３ｂ、３ｃは、前記証券会社等が顧客である場合には、一般投資家からの端株取引の注文の受け付け及び管理等を行うサーバ又はそのサーバに接続された通信用の端末又はサーバ等となる。一方、一般投資家が顧客である場合には、注文データを入力及び送信等する端末となる。
図１に示す例では、顧客Ａ及び顧客Ｂが一般投資家に対する端株取引のサービス提供窓口となる証券会社であり、その顧客側装置３ａ、３ｂは、一般投資家からの端株取引の注文の受け付け及び管理等を行うサーバ４と、端株取引システム１に対して送信済みの注文データを管理するための送信済み注文データベース５と、送信した注文データの約定結果を管理するための約定結果データベース６とを備えた構成となっている。また、顧客Ｃが一般投資家であり、その顧客側装置３ｃは、端株取引システム１との間で注文データや約定結果の送受信を行う端末７を備えた構成となっている。
【００３４】
一方、端株取引システム１は、図１に示すように、通信ネットワーク２を介して顧客側装置３ａ、３ｂ、３ｃと接続された通信サーバ８と、この通信サーバ８に接続されて、端株取引のための実質的な処理を実行するホストシステム９とを有して構成されている。本実施形態においては、通信サーバ８が本発明における「注文受付手段」を構成する。
これらの通信サーバ８及びホストシステム９は、ＣＰＵ等の演算処理装置を中核部材として、入力されたデータに対して種々の処理を行うための処理部がハードウエア又はソフトウエア或いはその両方で実装された構成を備えている。
【００３５】
本実施形態においては、ホストシステム９は、注文データ確認処理部１０、処理用データ生成処理部１１、必要株数集計処理部１２、買付処理部１３、銘柄データ生成処理部１４、値段情報取得処理部１５、約定処理部１６、注文データ更新処理部１７、不出来処理部１８、及び結果出力処理部１９を備えている。これらの各処理部における処理の具体的内容については、後にフローチャートに基づいて詳細に説明する。
また、ホストシステム９は、株式銘柄情報データベース２０、顧客情報データベース２１、注文データベース２２、処理用データベース２３、約定データベース２４、株式在庫情報データベース２５、及び株式情報管理データベース２６を備えている。
また、通信サーバ８は、送信用データベース２７に接続されている。
また、買付処理部１３は、株式の買付処理を行うために、通信ネットワーク２を介して証券取引所が備える取引所システム２８に接続されている。値段情報取得処理部１５は、株式の値段情報を取得するために、通信ネットワーク２を介して株式情報ベンダーが備える株式情報ベンダーシステム２９に接続されている。
【００３６】
株式銘柄情報データベース２０には、株式銘柄毎に取引可能か否かに関する情報が格納される。具体的には、例えば、株式銘柄、各株式銘柄の売買単位数、各株式銘柄に対して予め定められた固有の銘柄コード、及びその株式銘柄が端株取引可能な銘柄か否かを表す情報等が含まれる。なお、端株取引が可能か否かは、ホストシステム９の管理者側で一定の規定に基づいて設定するとよい。例えば、市場において管理ポストに割り当てられた株式銘柄や新規上場銘柄であって初値が未だついていない株式銘柄等は、上場されている株式銘柄であっても端株取引が不可能な銘柄とする等の設定が可能である。本実施形態においては、この株式銘柄情報データベース２０が本発明における「株式銘柄情報格納手段」に相当する。
顧客情報データベース２１には、注文データの送信を許可された顧客（発注者）に関する情報が格納される。具体的には、例えば、顧客名、予め登録された顧客毎に個別に設定された識別情報である注文顧客コード、各顧客の住所等の連絡先、各顧客に設定された手数料区分、各顧客の取引税区分等の情報が含まれる。本実施形態においては、この顧客情報データベース２１が本発明における「発注者情報格納手段」に相当する。
【００３７】
注文データベース２２には、通信サーバ８により受信した注文データが格納される。ここに格納された注文データは、注文データ更新処理部１７又は不出来処理部１８により、約定処理の結果情報を追加する更新が行われる。本実施形態においては、この注文データベース２２が本発明における「注文データ格納手段」に相当する。
処理用データベース２３には、処理用データ生成処理部１１により、注文データに基づいて各注文データに対応させて生成された処理用データが格納される。本実施形態においては、この処理用データベース２３が本発明における「処理用データ格納手段」に相当する。ここで、処理用データは、注文データに、システム内での約定処理部１６や買付処理部１３等における処理に必要な情報の格納領域を付加して生成される。具体的には、後述するように注文データに含まれる「注文顧客コード」や「銘柄コード」に基づいて、顧客情報データベース２１や株式銘柄情報データベース２０を検索し、顧客名や顧客の手数料区分及び取引税区分等の情報、並びに株式銘柄やその銘柄の売買単位数の情報等が注文データの内容に付加されて生成される。
約定データベース２４には、約定処理部１６による約定処理の結果情報である約定データが格納される。この約定データには、具体的には、約定年月日、約定時刻、約定数量、約定値段、手数料、取引税等の情報が含まれる。この約定データベース２４に格納される約定データは、処理用データベース２３に格納される各処理用データに対して一対一に対応した状態で格納される。この状態を表すために、図１では約定データベース２４を処理用データベース２３の中に配置して表している。
【００３８】
株式在庫情報データベース２５には、ホストシステム９の管理者が所有する株式の在庫情報が格納される。なお、約定年月日と実際の株式の受け渡し日とが異なる場合があるが、この株式在庫情報データベース２５に格納されるのは、約定が成立した株式を考慮に入れた約定現在の在庫情報とするのが好適である。本実施形態においては、この株式在庫情報データベース２５が本発明における「株式在庫情報格納手段」に相当する。
株式情報管理データベース２６には、銘柄データ生成処理部１４により生成された端株取引の注文を受け付けた株式銘柄を集計した銘柄データ、各株式銘柄について約定処理部１６において既に約定処理が行われたか否かの情報、及び日通し値段の情報等が格納される。
送信用データベース２７には、結果出力処理部１９により、注文データベース２２に格納された注文データに基づいて生成された送信用データが格納される。ここで、送信用データは、具体的には、同一の顧客の１又は２以上の注文データを一つにまとめ、後述するヘッダ及びトレーラを付加することにより生成される。
【００３９】
次に、本実施形態に係る端株取引システム１において取り扱う注文データの内容について説明する。図２は、本実施形態における注文データが備える情報格納領域の内容の具体例を示す図であり、図３は、この注文データを、通信ネットワーク２を介して送受信する際に、注文データの前に付加されるヘッダ（図３（ａ））及び注文データの後に付加されるトレーラ（図３（ｂ））が備える情報格納領域の内容の具体例を示す図である。
【００４０】
まず、図２に示される注文データが備える情報格納領域の内容について説明する。
「１．レコード区分」は、ヘッダ部及びトレーラ部と区別するために、注文データの内容そのものであることを示す情報の格納領域である。「２．市場区分」は、注文された株の約定を付ける市場を表す情報の格納領域であって、例えば東京証券取引所（東証）や大阪証券取引所（大証）等の各市場を表す情報が格納される。「３．注文顧客コード」は、予め登録された顧客毎に個別に設定された識別情報の格納領域である。この「３．注文顧客コード」が、本発明における「発注者識別情報」に相当する。「４．注文年月日」は、端株取引の注文執行日を指定する情報の格納領域である。「５．顧客設定項目」は、顧客側において自由に設定した情報の格納領域である。
【００４１】
「６．注文  銘柄コード」、「７．注文  売買区分」及び「８．注文  売買数量」は、いずれも端株取引の注文内容を表す情報の格納領域であり、本発明における「注文内容情報の格納領域」に相当する。すなわち、「６．注文  銘柄コード」は、注文する株式銘柄に対して予め定められた固有の銘柄コードの格納領域である。「７．注文  売買区分」は、売却又は買付の別を表す情報の格納領域である。「８．注文  売買数量」は、その株式銘柄の売買を行う数量を表す情報の格納領域である。
【００４２】
「９．引継区分」は、その注文データが前場取引用の注文である場合であって前場に約定が成立しなかった場合（不出来となった場合）にその注文を後場に引き継ぐか否かを表す情報の格納領域である。「１０．前後場区分」は、その注文データが前場取引用の注文か後場取引用の注文かを表す情報の格納領域である。
【００４３】
「１１．約定  約定結果」、「１２．約定  約定値段」及び「１３．約定  約定時刻」は、いずれも約定処理の結果情報を表す情報の格納領域であり、本発明における「約定情報の格納領域」に相当する。すなわち、「１１．約定  約定結果」は、約定の成立又は不出来、或いは約定処理の結果が確定していない未処理のいずれかを表す情報の格納領域である。「１２．約定  約定値段」は、約定が成立した場合に約定値段を表す情報の格納領域である。「１３．約定  約定時刻」は、約定が成立した場合に約定時刻を表す情報の格納領域である。
【００４４】
「１４．確認結果」は、後述する注文データ確認処理部１０による注文データが処理可能か否かの確認結果を表す確認結果情報の格納領域である。「１５．受渡日」は、約定が成立した株式の受渡しを行う日付を表す情報の格納領域である。「１６．注文Ｎｏ．」は、その注文データに対して固有に付与される識別符号を表す情報の格納領域である。
なお、本実施形態においては、以上の注文データが備える情報格納領域のうち、１及び３〜１０は顧客側装置３ａ、３ｂ、３ｃにおいて設定入力される情報であり、２及び１１〜１６は端株取引システム１において設定入力される情報となっている。
【００４５】
次に、図３（ａ）に示されるヘッダが備える情報格納領域の内容について説明する。
「１．レコード区分」は、注文データ及びトレーラと区別するために、ヘッダであることを示す情報の格納領域である。「２．注文顧客コード」は、予め登録された顧客毎に個別に設定された識別情報の格納領域である。「３．処理日付」は、注文データの前後にヘッダ及びトレーラが付加された送信用データが作成された日付情報の格納領域である。「４．ファイルＩＤ」は、このヘッダが付加された注文データの性質を示す情報の格納領域であり、具体的には、送受信される注文データが、顧客側装置３ａ、３ｂ、３ｃから端株取引システム１へ送信される注文データか、端株取引システム１から顧客側装置３ａ、３ｂ、３ｃへ送信される注文データかを示す情報等が格納される。
【００４６】
次に、図３（ｂ）に示されるトレーラが備える情報格納領域の内容について説明する。
「１．レコード区分」は、注文データ及びヘッダと区別するために、トレーラであることを示す情報の格納領域である。「２．注文顧客コード」は、予め登録された顧客毎に個別に設定された識別情報の格納領域である。「３．件数」は、このトレーラが付加された送信用データに含まれる注文データの件数を表す情報の格納領域である。
なお、「注文顧客コード」については、注文データ、ヘッダ、及びトレーラのいずれにも備えられているが、これらの各情報格納領域には同じ情報が重複して格納される。
【００４７】
次に、図１に示す端株取引システム１の各処理能部による処理の流れをフローチャートに基づいて以下に説明する。図４は、本実施形態に係る端株取引システム１による端株取引処理の全体を示すフローチャートである。
【００４８】
この図４に示すように、端株取引システム１は、通信サーバ８が、通信ネットワーク２を介して顧客側装置３ａ、３ｂ、３ｃから注文データを受け付けた場合には（ステップ＃０１：ＹＥＳ）、まず注文データ確認処理部１０において注文データが処理可能であるか否かを確認する処理を行う（ステップ＃０２）。このステップ＃０２の注文データ確認処理については、後に図５のフローチャートに基づいて詳細に説明する。本実施形態においては、注文データ確認処理部１０が本発明における「注文データ確認手段」に相当する。
【００４９】
このステップ＃０２の処理の結果、注文データが処理可能であると判断された場合には（ステップ＃０３：ＹＥＳ）、注文データの「１４．確認結果」領域に注文データが処理可能であることを表す情報を格納し、その注文データを注文データベース２２に格納する（ステップ＃０４）。
一方、このステップ＃０２の処理の結果、注文データが処理不可能であると判断された場合には（ステップ＃０３：ＮＯ）、注文データの「１４．確認結果」領域に注文データが処理不可能であることを表す情報を格納し、その注文データを注文データベース２２に格納する（ステップ＃０５）。そして、処理不可能と判断された注文データについては、ステップ＃０６〜＃０９の処理が行われず、ステップ＃１０の結果出力処理が行われる。
【００５０】
ステップ＃０２の処理の結果、注文データが処理可能であると判断された場合には（ステップ＃０３：ＹＥＳ）、ステップ＃０４の後、処理用データ生成処理部１１において注文データに基づいて各注文データに対応する処理用データを生成し（ステップ＃０６）、生成された処理用データを処理用データベース２３に格納する処理が行われる（ステップ＃０７）。したがって、本実施形態においては、処理用データ生成処理部１１が本発明における「処理用データ生成手段」に相当する。なお、処理用データの内容については既に説明したのでここでは省略する。
【００５１】
次に、必要株数集計処理部１２において、処理用データベース２３に格納された全ての処理用データに基づいて、株式銘柄毎の必要株数を集計する処理を行う（ステップ＃０８）。すなわち、処理用データベース２３に格納された全ての処理用データに基づいて、注文された売買数量を株式銘柄毎に集計する。そして、各株式銘柄についての買い注文数と売り注文数との差の演算結果が、各株式銘柄についての必要株数となる。ここで、買い注文数と売り注文数との差が負になる場合、すなわち売り注文数が買い注文数より多い場合は、その株式銘柄については、後述する買付処理部１３における株式買付処理（ステップ＃１２）は行われず、余剰分の株式は在庫となる。本実施形態においては、必要株数集計処理部１２が本発明における「必要株数集計手段」に相当する。
【００５２】
次に、銘柄データ生成処理部１４において、処理用データベース２３に格納された全ての処理用データに基づいて、端株取引の注文を受け付けた株式銘柄を集計した銘柄データを生成する処理を行う（ステップ＃０９）。すなわち、処理用データベース２３に格納された全ての処理用データに基づいて、各処理用データに含まれる株式銘柄を抽出して集計することにより、注文を受け付けた株式銘柄を全て列挙した銘柄データを生成する。したがって、本実施形態においては、銘柄データ生成処理部１４が本発明における「銘柄データ生成手段」に相当する。
【００５３】
次に、結果出力処理部１９において結果出力処理が行われる（ステップ＃１０）。この結果出力処理については、後に図９のフローチャートに基づいて詳細に説明するが、要約すると、この処理では、注文データベース２２に格納されている注文データを顧客毎に抽出して顧客毎の送信用データを生成し、通信サーバ８により送信可能とする処理が行われる。この段階では、注文データベース２２に格納されている注文データには、約定処理の結果情報は格納されていないが、注文データ確認処理（ステップ＃０２）での確認結果の処理可能（ステップ＃０４参照）又は処理不可能（ステップ＃０５参照）を表す情報が格納されている。したがって、このステップ＃１０の処理により、顧客側装置３ａ、３ｂ、３ｃにおいては、通信サーバ８から送信用データを受信し、当該顧客側装置３ａ、３ｂ、３ｃから送信した注文データが処理可能であったか処理不可能であったかの情報を得ることができるようになる。
【００５４】
その後、市場での取引開始時刻になったか否かの判断を行う（ステップ＃１１）。なお、東京証券取引所（東証）や大阪証券取引所（大証）等の一般的な市場では、取引時間は、前場が９：００〜１１：００、後場が１２：３０〜１５：００となっている。したがって、取引開始時刻は、具体的には、前場取引用の注文データに対しては９：００、後場取引用の注文データに対しては１２：３０となる。なお、市場における取引時間は、これ以外の場合も有り得るので、そのような市場向けの注文データに対しては、取引開始時刻は、それに応じた時刻に設定すると好適である。
そして、未だ取引開始時刻になっていない場合には（ステップ＃１１：ＮＯ）、処理はステップ＃０１へ戻り、通信サーバ８において次の注文データを受け付けた場合には（ステップ＃０１：ＹＥＳ）、当該注文データに基づいて更にステップ＃０２〜＃１０の処理を行う。
【００５５】
そして、市場での取引開始時刻になった場合には（ステップ＃１１：ＹＥＳ）、買付処理部１３において、必要株数集計処理部１２によるステップ＃０８の必要株数集計処理での集計結果と、株式在庫情報データベース２５に格納された株式の在庫情報とを対比して、在庫株数が不足する株式銘柄についての売買単位数毎の株式の買付処理を実行する（ステップ＃１２）。このステップ＃１２の株式買付処理については、後に図６のフローチャートに基づいて詳細に説明する。本実施形態においては、買付処理部１３が本発明における「買付処理手段」に相当する。
【００５６】
次に、値段情報取得処理部１５において、ステップ＃０９により生成された銘柄データに含まれる各株式銘柄についての値段情報を取得する処理を行う（ステップ＃１３）。このステップ＃１３の値段情報取得処理については、後に図７のフローチャートに基づいて詳細に説明する。本実施形態においては、値段情報取得処理部１５が本発明における「値段情報取得手段」に相当する。
【００５７】
次に、約定処理部１６において、ステップ＃１３により値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする処理用データについての約定処理を行う（ステップ＃１４）。このステップ＃１４の約定処理については、後に図８のフローチャートに基づいて詳細に説明するが、要約すると、この処理では、値段情報が取得された株式銘柄を取引対象とする処理用データを処理用データベース２３から検索し、各処理用データに対応する約定データを生成して約定データベース２４に格納する処理を行う。したがって、本実施形態においては、約定処理部１６が本発明における「約定処理手段」に相当する。
【００５８】
その後、注文データ更新処理部１７において、ステップ＃１４により約定処理が行われた処理用データについて、当該処理用データに対応する、注文データベース２２に格納された注文データに対して、約定処理の結果情報を追加する更新を行う（ステップ＃１５）。具体的には、ステップ＃１４により生成されて約定データベース２４に格納された約定データの内容から、注文データの「１１．約定  約定結果」、「１２．約定  約定値段」及び「１３．約定  約定時刻」に対応する情報を抽出し、それぞれの格納領域に格納する処理を行う。したがって、本実施形態においては、注文データ更新処理部１７が本発明における「注文データ更新手段」に相当する。
【００５９】
その後、結果出力処理部１９において結果出力処理を行う（ステップ＃１６）。この結果出力処理の流れは、ステップ＃１０と同じである。したがって、後に図９のフローチャートに基づいて詳細に説明するが、要約すると、この処理では、注文データベース２２に格納されている注文データを顧客毎に抽出して顧客毎の送信用データを生成し、通信サーバ８により送信可能とする処理が行われる。但し、ステップ＃１０の場合と異なり、この段階では、注文データベース２２に格納されている注文データには、既に約定処理の結果情報が格納されている。したがって、このステップ＃１６の処理により、顧客側装置３ａ、３ｂ、３ｃにおいては、通信サーバ８から送信用データを受信し、当該顧客側装置３ａ、３ｂ、３ｃから送信した注文データの約定処理の結果の情報を得ることができるようになる。
【００６０】
次に、市場での取引終了時刻になったか否かの判断を行う（ステップ＃１７）。上記のとおり、東京証券取引所（東証）や大阪証券取引所（大証）等の一般的な市場では、取引時間は、前場が９：００〜１１：００、後場が１２：３０〜１５：００となっている。したがって、取引終了時刻は、前場取引用の注文データに対しては１１：００、後場取引用の注文データに対しては１５：００となる。なお、市場における取引時間は、これ以外の場合も有り得るので、そのような市場向けの注文データに対しては、取引終了時刻は、それに応じた時刻に設定すると好適である。
そして、未だ取引終了時刻になるまでの間は（ステップ＃１７：ＮＯ）、ステップ＃１２〜＃１６の処理を継続して行う。
【００６１】
その後、市場での取引終了時刻になった場合には（ステップ＃１７：ＹＥＳ）、不出来処理部１８において約定が成立しなかった注文を確定する不出来注文確定処理を行う（ステップ＃１８）。具体的には、処理用データベース２３及び約定データベース２４を検索することにより、対応する約定データが生成されていない処理用データを抽出し、抽出された処理用データを、約定が成立しなかった不出来注文として確定する処理を行う。
なお、注文が不出来となるのは、市場における取引時間中に当該処理用データ（注文データ）が取引対象とする株式銘柄について値段が付かず、取引終了時刻になるまで値段情報取得処理部１５において値段情報が取得されなかったことにより生じる。
そして、不出来処理部１８において、ステップ＃１８により不出来注文として確定された処理用データについて、当該処理用データに対応する、注文データベース２２に格納された注文データに対して、約定処理の結果情報として不出来情報を追加する更新を行う（ステップ＃１９）。具体的には、当該処理用データに対応する注文データを注文データベース２２から検索し、当該注文データの「１１．約定  約定結果」の格納領域に当該注文が不出来となったことを表す情報を格納する処理を行う。
【００６２】
その後、結果出力処理部１９において結果出力処理を行う（ステップ＃２０）。この結果出力処理の流れは、ステップ＃１０及び＃１６と同じである。したがって、後に図９のフローチャートに基づいて詳細に説明するが、要約すると、この処理では、注文データベース２２に格納されている注文データを顧客毎に抽出して顧客毎の送信用データを生成し、通信サーバ８により送信可能とする処理が行われる。この段階では、注文データベース２２に格納されている注文データには、不出来情報を含む約定処理の結果情報が格納されている。したがって、このステップ＃２０の処理により、顧客側装置３ａ、３ｂ、３ｃにおいては、通信サーバ８から送信用データを受信し、当該顧客側装置３ａ、３ｂ、３ｃから送信した注文データの不出来情報を含む約定処理の結果の情報を得ることができるようになる。
【００６３】
次に、図４のフローチャートにおけるステップ＃０２の注文データ確認処理の具体的な流れについて、図５に示すフローチャートに基づいて説明する。
【００６４】
この図に示すように、注文データ確認処理部１０における注文データ確認処理では、まず、株式銘柄の確認処理が行われる（ステップ＃３１）。この処理では、具体的には、通信サーバ８により受け付けた注文データの「６．注文  銘柄コード」の格納領域に格納されている銘柄コードを有する株式銘柄情報を株式銘柄情報データベース２０から検索し、当該株式銘柄が取引可能であるか否かを確認する。そして、当該株式銘柄が取引可能である場合には「ＯＫ」、取引不可能である場合には「ＮＧ」と判断する処理を行う。
【００６５】
次に、顧客確認処理が行われる（ステップ＃３２）。この処理では、具体的には、受け付けた注文データの「３．注文顧客コード」の格納領域に格納されている注文顧客コードを有する顧客情報を顧客情報データベース２１から検索し、当該顧客が予め登録された注文データの送信を許可された顧客であるか否かを確認する。そして、当該顧客が注文データの送信を許可された顧客である場合には「ＯＫ」、そうでない場合には「ＮＧ」と判断する処理を行う。
【００６６】
次に、注文日付の確認処理が行われる（ステップ＃３３）。この処理では、具体的には、受け付けた注文データの「４．注文年月日」の格納領域に格納されている注文執行日の指定が正常であるか否かを、ホストシステム９が有する現在年月日の情報と対比することにより確認する。すなわち、現在年月日よりも前の年月日や受け付け可能な年月日より先の年月日が注文執行日として指定されている場合には、「ＮＧ」と判断する処理を行う。
【００６７】
次に、売買数量の確認処理が行われる（ステップ＃３４）。この処理では、具体的には、受け付けた注文データの「８．注文  売買数量」の格納領域に格納されている端株の売買数量が正常であるか否かを、株式銘柄情報データベース２０に格納されている各株式銘柄の売買単位数等に基づいて確認する。すなわち、例えば、注文された売買数量が売買単位数以上である場合には、端株取引として売買するのは適切でないので、「ＮＧ」と判断する処理を行う。
【００６８】
そして、以上のステップ＃３１〜＃３４の確認処理の結果、全て「ＯＫ」と確認された場合には、注文データ確認処理部１０は、注文データベース２２に格納された注文データの「１４．確認結果」の格納領域に注文データが処理可能であることを表す情報を格納する処理を行う（ステップ＃３５）。一方、ステップ＃３１〜＃３４の確認処理の結果、いずれか一つで「ＮＧ」とされた場合には、注文データ確認処理部１０は、注文データベース２２に格納された注文データの「１４．確認結果」の格納領域に注文データが処理不可能であることを表す情報を格納する処理を行う（ステップ＃３６）。これにより、注文データ確認処理を終了する。
【００６９】
次に、図４のフローチャートにおけるステップ＃１２の株式買付処理の具体的な流れについて、図６に示すフローチャートに基づいて説明する。
【００７０】
この図に示すように、買付処理部１３における株式買付処理では、まず、上記ステップ＃０８（図４参照）の必要株数集計処理による株式銘柄毎の必要株数の集計結果と、株式在庫情報データベース２５に格納されている株式の在庫情報とを対比する処理を行う（ステップ＃４１）。そして、在庫株数が不足する株式銘柄があるか否かの判断を行う（ステップ＃４２）。在庫株数が不足する株式銘柄がない場合には（ステップ＃４２：ＮＯ）、株式を新たに買い付ける必要がないので、株式買付処理は終了する。
【００７１】
一方、在庫株数が不足する株式銘柄がある場合には（ステップ＃４２：ＹＥＳ）、株式銘柄毎に新たに市場で調達する必要がある株数を算出する処理を行う（ステップ＃４３）。この際、市場での株式の買い付けは当然に売買単位数毎でしかできないので、この処理により算出される市場調達株数は、株式銘柄毎に定められた売買単位数の整数倍の数として算出するようになっている。そして、算出された株式銘柄毎の市場調達株数に基づいて、各株式銘柄が上場されている証券取引所に対する買付注文データを生成し（ステップ＃４４）、生成した買付注文データを、通信ネットワーク２を介して各証券取引所が備える取引所システム２８（図１参照）に対して送信する処理を行う（ステップ＃４５）。
【００７２】
その後、買付結果更新時間Ｔ１が経過する毎に（ステップ＃４６）、取引所システム２８から買付結果データを受信し（ステップ＃４７）、その買付結果に基づいて株式在庫情報データベース２５に格納されている株式の在庫情報を更新する処理（ステップ＃４８）を、市場の取引終了時刻まで繰り返し行う（ステップ＃４９）。ここで、買付結果更新時間Ｔ１は、送信した買付注文データに対する買付結果の最新情報を更新する処理を行う間隔であり、必要に応じて任意の時間間隔に設定することができる。
【００７３】
そして、市場の取引終了時刻となった場合には（ステップ＃４９：ＹＥＳ）、上記ステップ＃１８（図４参照）の不出来注文確定処理が終了した後（ステップ＃５０：ＹＥＳ）、買付注文データとして送信した株式銘柄の中に不出来となった株式銘柄が存在するか否かの判断を行う（ステップ＃５１）。不出来となった株式銘柄が存在しない場合には（ステップ＃５１：ＮＯ）、買付注文データとして送信した全ての株式銘柄について値段が付いて買付けが行われたということになるので、株式買付処理はそのまま終了する。
【００７４】
一方、不出来となった株式銘柄が存在する場合には（ステップ＃５１：ＹＥＳ）、次に、取引終了時刻となったのが前場であるか否かについて判断する（ステップ＃５２）。すなわち、取引所システム２８においては、前場で注文が不出来となった場合であってもその注文が取り消されることはなく、後場の取引に引き継がれるのが通常である。一方、本実施形態においては、注文データに上記のとおり「９．引継区分」の格納領域が設けられており、その注文データが前場取引用の注文である場合であって前場に約定が成立しなかった場合（不出来となった場合）にその注文を後場に引き継ぐか否かを顧客が選択可能となっている。したがって、前場で不出来となった場合にその注文を自動的に後場に引き継ぐと不都合が生じる。そこで、ここでは取引終了時刻となったのが前場である場合には（ステップ＃５２：ＹＥＳ）、ステップ＃４５において送信した買付注文データを取り消すための買付注文取消データを生成し（ステップ＃５３）、生成した買付注文取消データを、通信ネットワーク２を介して各証券取引所が備える取引所システム２８（図１参照）に対して送信する処理を行う（ステップ＃５４）。そして、株式買付処理は終了する。
なお、取引終了時刻となったのが後場である場合には（ステップ＃５２：ＮＯ）、買付注文データは取引所システム２８において不出来として自動的に注文を取り消す処理が行われるので、買付注文取消データを送信する必要はなく、そのまま株式買付処理は終了する。
【００７５】
次に、図４のフローチャートにおけるステップ＃１３の値段情報取得処理の具体的な流れについて、図７に示すフローチャートに基づいて説明する。
【００７６】
この図に示すように、値段情報取得処理部１５における値段情報取得処理では、まず、上記ステップ＃０９（図４参照）により生成された銘柄データを取り込む処理を行う（ステップ＃６１）。また、取り込んだ銘柄データを株式情報管理データベース２６に格納する処理を行う（ステップ＃６２）。
そして、値段情報更新時間Ｔ２が経過する毎に（ステップ＃６３）、通信ネットワーク２を介して接続された株式情報ベンダーシステム２９から、取り込んだ銘柄データに含まれる株式銘柄についての値段情報を受信して取得し（ステップ＃６４）、取得された値段情報を約定処理部１６へ転送する処理（ステップ＃６５）を、市場の取引終了時刻まで繰り返し行う（ステップ＃６６）。ここで、値段情報更新時間Ｔ２は、株式情報ベンダーシステム２９から最新の値段情報を取得する処理を行う間隔であり、例えば、１０分に設定される。なお、値段情報を取得する方法は株式情報ベンダーからに限られるものではなく、市場から直接に値段情報を取得する方法等、その他の様々な方法を用いることができる。
本実施形態においては、この値段情報取得処理で取得する値段情報を寄付値情報としている。これは、最も早く定まる値段である寄付値を約定値段とすることになるので、早い段階で約定処理を行うことが可能となるからである。なお、値段情報として取得する値段はこれに限定されるものではなく、例えば、前場又は後場の終値、安値、高値等とすることも好適な実施形態の一つである。
【００７７】
そして、市場の取引終了時刻となった場合には（ステップ＃６６：ＹＥＳ）、上記ステップ＃１８（図４参照）の不出来注文確定処理が終了した後（ステップ＃６７：ＹＥＳ）、取引終了時刻となったのが後場であるか否かについて判断する（ステップ＃６８）。そして、取引終了時刻となったのが後場である場合には（ステップ＃６８：ＹＥＳ）、株式情報ベンダーシステム２９から株式銘柄毎の日通し値段情報を取得し（ステップ＃６９）、取得した日通し値段情報を株式情報管理データベース２６に格納する処理を行う（ステップ＃７０）。ここで、日通し値段情報とは、株式銘柄毎のその日一日の値段の動きの情報である。株式情報管理データベース２６に格納された日通し値段情報は、株式銘柄情報データベース２０に格納される株式銘柄が端株取引可能な銘柄か否かを表す情報の更新等に用いられる。
なお、取引終了時刻となったのが前場である場合には（ステップ＃６８：ＮＯ）、値段情報取得処理はそのまま終了する。
【００７８】
次に、図４のフローチャートにおけるステップ＃１４の約定処理の具体的な流れについて、図８に示すフローチャートに基づいて説明する。
【００７９】
この図に示すように、約定処理部１６における約定処理では、まず、値段情報取得処理部１５において株式銘柄毎の値段情報が取得されるのを待ち、値段情報が取得された株式銘柄があった場合に（ステップ＃８１）、当該値段情報が取得された株式銘柄が既に約定処理済みの株式銘柄か否かの判断を行う（ステップ＃８２）。この判断は、後述するステップ＃８７により、約定処理済みの株式銘柄については、その情報が株式情報管理データベース２６に格納されているので、値段情報が取得された株式銘柄の約定済みであることの情報が株式情報管理データベース２６に格納されているか否かを検索することにより、行うことができる。値段情報が取得された株式銘柄が既に約定処理済みの株式銘柄である場合には（ステップ＃８２：ＹＥＳ）、処理はステップ＃８１へ戻り、次の値段情報が取得されるまで待機する。
【００８０】
一方、値段情報が取得された株式銘柄が既に約定処理済みの株式銘柄でない場合には（ステップ＃８２：ＮＯ）、処理用データベース２３から、当該値段情報が取得された株式銘柄を取引対象とする処理用データを検索する処理を行う（ステップ＃８３）。そして、取得された値段情報に基づいて、このステップ＃８３で検索された各処理用データに対応する約定をその時刻に成立させ、その結果情報である約定データを生成する処理を行う（ステップ＃８４）。この約定データには、約定が成立した年月日を表す約定年月日、約定が成立した時刻を表す約定時刻、約定が成立した当該株式銘柄の売買数量を表す約定数量、約定が成立した値段を表す約定値段、各顧客に設定された手数料区分に基づいて算出された手数料額、各顧客の取引税区分に基づいて算出された取引税額等の情報が含まれる。
【００８１】
そして、ステップ＃８４で生成された約定データを約定データベース２４に格納する（ステップ＃８５）。その後、生成された約定データに含まれる約定数量に従って、株式在庫情報データベース２５に格納されている株式の在庫情報を更新する処理を行う（ステップ＃８６）。次に、約定済みの株式銘柄の情報を株式情報管理データベース２６に格納する処理を行う（ステップ＃８７）。ここで格納された情報は、ステップ＃８２において値段情報が取得された株式銘柄が既に約定処理済みの株式銘柄か否かの判断を行う際に用いられる。これにより、約定処理は終了する。
【００８２】
次に、図４のフローチャートにおけるステップ＃１０、＃１６、及び＃２０の結果出力処理の具体的な流れについて、図９に示すフローチャートに基づいて説明する。
【００８３】
この図に示すように、結果出力処理部１９における結果出力処理では、まず、結果出力更新時間Ｔ３が経過するのを待ち、結果出力更新時間Ｔ３が経過した後に（ステップ＃９１）、注文データベース２２から注文データを顧客毎に抽出する処理を行う（ステップ＃９２）。ここで、結果出力更新時間Ｔ３は、この結果出力処理の前の処理であるステップ＃０４又は＃０５の注文データを注文データベース２２に格納する処理や、ステップ＃１５又は＃１９の注文データの更新処理が確実に完了するのを待ってから結果出力を行うための待機時間であり、例えば３分に設定される。
【００８４】
そして、注文データを顧客毎に抽出した（ステップ＃９２）後、顧客毎の送信用データを生成する処理を行う（ステップ＃９３）。ここで、送信用データは、同一の顧客による１又は２以上の注文データを一つにまとめ、上記ヘッダ及びトレーラを当該注文データの前後に付加することにより生成される。これにより、一の顧客に対して、当該顧客の注文データの処理結果を一つにまとめて送信可能な状態とすることができる。
次に、ステップ＃９３で生成された送信用データを送信用データベースに格納する（ステップ＃９４）。
【００８５】
その後、顧客側装置３ａ、３ｂ、３ｃから、通信サーバ８に対して送信用データの受信要求があった場合には（ステップ＃９５：ＹＥＳ）、受信要求をした顧客側装置３ａ、３ｂ、３ｃに対して、当該顧客向けの送信用データを送信する処理を行う（ステップ＃９６）。この処理は、通信サーバ８が送信用データベース２７から当該顧客向けの送信用データを検索して送信することにより行う。そして、これにより、結果出力処理は終了する。
したがって、ホストシステム９の結果出力処理部１９、送信用データベース２７、及び通信サーバ８が、本発明における「結果送信手段」を構成する。
【００８６】
〔第二の実施形態〕
上記第一の実施形態では、処理用データ生成処理部１１において注文データに基づいて各注文データに対応する処理用データを生成して処理用データベース２３に格納するとともに、この処理用データベース２３に格納された処理用データに基づいて、必要株数集計処理（ステップ＃０８）、銘柄データ生成処理（ステップ＃０９）、株式買付処理（ステップ＃１２）、及び約定処理（ステップ＃１４）等を行う例について説明した。
しかし、このような処理用データを用いることは、本発明における必須の要件ではなく、処理用データを用いずに注文データに基づいてホストシステム９内の各処理を行うことも好適な実施形態の一つである。
【００８７】
したがって、本発明の第二の本実施形態に係る端株取引システム１は、図１０に示すように、処理用データ生成処理部１１及び処理用データベース２３を備えておらず、上記第一の実施形態において処理用データに基づいて行っていた処理を注文データベース２２に格納された注文データに基づいて行うシステムである。したがって、本実施形態に係る端株取引システム１は、ホストシステム９内の処理部及びデータベースの構成以外は、上記第一の実施形態と同様である。以下、上記第一の実施形態に対する相違点を中心に説明する。
【００８８】
図１０は、本実施形態に係る端株取引システム１による端株取引処理の全体を示すフローチャートである。この図に示すように、本実施形態においては、通信サーバ８を介して顧客側装置３ａ、３ｂ、３ｃから注文データを受け付けた場合には（ステップ＃１０１：ＹＥＳ）、注文データ確認処理部１０において、上記第一の実施形態と同様に、注文データが処理可能であるか否かを確認する処理（ステップ＃１０２）を行い、注文データが処理可能か処理不可能かを表す情報を注文データに格納して、当該注文データを注文データベース２２に格納する（ステップ＃１０４、＃１０５）。
その後、本実施形態においては、上記第一の実施形態とは異なり、注文データベース２２に格納された注文データに基づいて必要株数集計処理（ステップ＃１０６）、銘柄データ生成処理（ステップ＃１０７）、株式買付処理（ステップ＃１１０）、及び約定処理（ステップ＃１１２）等を行う。
【００８９】
すなわち、必要株数集計処理部１２において、ステップ＃１０４により処理可能情報が格納された注文データを注文データベース２２から抽出し、抽出された全ての注文データに基づいて株式銘柄毎の必要株数を集計する処理を行う（ステップ＃１０６）。この処理の具体的内容は、上記第一の実施形態と同様である。
次に、銘柄データ生成処理部１４において、ステップ＃１０４により処理可能情報が格納された注文データを注文データベース２２から抽出し、抽出された全ての注文データに基づいて、端株取引の注文を受け付けた株式銘柄を集計した銘柄データを生成する処理を行う（ステップ＃１０７）。
その後、上記第一の実施形態のステップ＃１０〜１３と同様に、結果出力処理（ステップ＃１０８）、市場での取引開始時刻か否かの判断処理（ステップ＃１０９）、株式買付処理（ステップ＃１１０）、値段情報取得処理（ステップ＃１１１）を行う。
【００９０】
次に、約定処理部１６において、ステップ＃１１１により値段情報が取得された株式銘柄について、当該株式銘柄を取引対象とする注文データについての約定処理を行う（ステップ＃１１２）。すなわち、値段情報が取得された株式銘柄があった場合に、当該値段情報が取得された株式銘柄が既に約定処理済みの株式銘柄か否かを判断し、約定処理済みでない株式銘柄を取引対象とする注文データを注文データベース２２から検索する処理を行う。そして、取得された値段情報に基づいて、各注文データに対応する約定をその時刻に成立させ、その結果情報である約定データを生成する処理を行う。この約定処理で生成された約定データは、注文データ更新処理部１７へ出力される。
【００９１】
そして、注文データ更新処理部１７において、ステップ＃１１２により約定処理が行われた注文データについて、約定処理の結果情報である約定データを追加する更新を行う（ステップ＃１１３）。具体的には、約定処理部１６から出力された約定データの内容から、注文データの「１１．約定  約定結果」、「１２．約定  約定値段」及び「１３．約定  約定時刻」に対応する情報を抽出し、それぞれの格納領域に格納する処理を行う。
その後、上記第一の実施形態のステップ＃１６〜１７と同様に、結果出力処理（ステップ＃１１４）、市場での取引終了時刻か否かの判断処理（ステップ＃１１５）を行う。
【００９２】
そして、市場での取引終了時刻になった場合には（ステップ＃１１５：ＹＥＳ）、不出来処理部１８において約定が成立しなかった注文を確定する不出来注文確定処理を行う（ステップ＃１１６）。具体的には、注文データベース２２に格納された注文データの中から、「１４．確認結果」に処理可能であることを表す情報が格納されており、かつ、「１１．約定  約定結果」に約定が成立したことを表す情報が格納されていない、すなわち未処理を表す情報が格納されている注文データを検索し、検索された注文データを不出来注文として確定する処理を行う。
次に、不出来処理部１８において、ステップ＃１１５により不出来注文として確定された注文データに対して、約定処理の結果情報として不出来情報を追加する更新を行う（ステップ＃１１７）。具体的には、当該注文データの「１１．約定  約定結果」の格納領域に当該注文が不出来となったことを表す情報を格納する処理を行う。
その後、上記第一の実施形態のステップ＃２０と同様に、結果出力処理（ステップ＃１１８）を行い、処理は終了する。
【産業上の利用可能性】
【００９３】
本発明は、株式銘柄毎に定められている売買単位数未満の端株の取引サービスを提供する証券会社等における端株取引システム、或いはそのようなシステムにおいて用いる端株取引プログラムとして好適に用いられる。
【図面の簡単な説明】
【００９４】
【図１】本発明の第一の実施形態に係る端株取引システムの概略図
【図２】本発明の第一の実施形態における注文データの情報格納領域の具体例を示す図
【図３】注文データの前に付加されるヘッダ（ａ）及び注文データの後に付加されるトレーラ（ｂ）が備える情報格納領域の具体例を示す図
【図４】本発明の第一の実施形態に係る端株取引システムによる端株取引処理の全体を示すフローチャート
【図５】図４のステップ＃０２の注文データ確認処理の流れを示すフローチャート
【図６】図４のステップ＃１２の株式買付処理の流れを示すフローチャート
【図７】図４のステップ＃１３の値段情報取得処理の流れを示すフローチャート
【図８】図４のステップ＃１４の約定処理の流れを示すフローチャート
【図９】図４のステップステップ＃１０、＃１６、及び＃２０の結果出力処理の流れを示すフローチャート
【図１０】本発明の第二の実施形態に係る端株取引システムの概略図
【図１１】本発明の第二の実施形態に係る端株取引システムによる端株取引処理の全体を示すフローチャート
【図１２】本発明の背景技術の一例を示す図
【符号の説明】
【００９５】
１：端株取引システム
８：通信サーバ（注文受付手段、結果送信手段）
１０：注文データ確認処理部（注文データ確認手段）
１１：処理用データ生成処理部（処理用データ生成手段）
１２：必要株数集計処理部（必要株数集計手段）
１３：買付処理部（買付処理手段）
１４：銘柄データ生成処理部（銘柄データ生成手段）
１５：値段情報取得処理部（値段情報取得手段）
１６：約定処理部（約定処理手段）
１７：注文データ更新処理部（注文データ更新手段）
１８：不出来処理部（不出来処理手段）
１９：結果出力処理部（結果送信手段）
２０：株式銘柄情報データベース（株式銘柄情報格納手段）
２１：顧客情報データベース（発注者情報格納手段）
２２：注文データベース（注文データ格納手段）
２３：処理用データベース（処理用データ格納手段）
２５：株式在庫情報データベース（株式在庫情報格納手段）
２７：送信用データベース（結果送信手段）
【図１】
2006277070.tif 000003
【図２】
2006277070.tif 000004
【図３】
2006277070.tif 000005
【図４】
2006277070.tif 000006
【図５】
2006277070.tif 000007
【図６】
2006277070.tif 000008
【図７】
2006277070.tif 000009
【図８】
2006277070.tif 000010
【図９】
2006277070.tif 000011
【図１０】
2006277070.tif 000012
【図１１】
2006277070.tif 000013
【図１２】
2006277070.tif 000014