(57)【要約】【課題】株券の売買注文をユーザが連続して行えるようにする。【解決手段】この株取引システムのＡＰＰサーバー２０は、発注端末４０からＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じて受信した注文電文をＧＷサーバー１０へ送信すると同時に、受信した注文電文に対する応答電文をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて発注端末４０へ送信する発注プロセス２２と、ＵＤＰ／ＩＰ通信（一斉同報通信）でＬＡＮ１１より受信した発注端末４０への応答電文より書き込み要求をＤＢサーバー３０へ送信し、ＤＢサーバー３０からの登録完了通知電文をＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じて受信する発注データ書き込みプロセス２３とを有する。【選択図】図５
2005135214.tif 000002
【特許請求の範囲】
【請求項１】
有価証券の取引を行う取引所と通信を行うゲートウェイサーバーと、このゲートウェイサーバーにネットワークを介して接続され、取引所に有価証券の取引を行なうための注文電文を送出する発注端末と、前記ネットワークに接続され、前記発注端末および取引所間でやり取りされる電文を蓄積するデータベースサーバーと、前記ネットワークに接続され、前記発注端末からネットワークを通じて受信された注文電文、前記取引所からゲートウェイサーバーを通じて受信された通知電文を前記データベースサーバーに蓄積するアプリケーションサーバーとを備える有価証券売買システムにおいて、
前記アプリケーションサーバーが、
前記発注端末からＴＣＰ／ＩＰ通信にて送信された注文電文を前記ネットワークを通じて受信し前記ゲートウェイサーバーへ送信すると同時に、受信した前記注文電文に対する応答電文を同報通信にて前記発注端末へ返信する発注手段と、
前記ネットワークより同報通信で前記発注端末へ送信された注文電文を受信し、ＴＣＰ／ＩＰ通信にて前記ネットワークを通じて前記データベースサーバーへ送信し、前記データベースサーバーからの登録完了通知電文をＴＣＰ／ＩＰ通信にて前記ネットワークより受信する書き込み手段と
を具備したことを特徴とする有価証券売買システム。
【請求項２】
有価証券の取引を行う取引所と通信を行うゲートウェイサーバーと、このゲートウェイサーバーにネットワークを介して接続され、取引所に有価証券の取引を行なうための注文電文を送出する発注端末と、前記ネットワークに接続され、前記発注端末および取引所間でやり取りされる電文を蓄積するデータベースサーバーと、前記ネットワークに接続され、前記発注端末からネットワークを通じて受信された注文電文、前記取引所からゲートウェイサーバーを通じて受信された通知電文を前記データベースサーバーに蓄積するアプリケーションサーバーとを備える有価証券売買システムにおいて、
前記アプリケーションサーバーが、
前記取引所から送信された通知電文を前記ゲートウェイサーバーおよび前記ネットワークを通じて受信し、受信した前記通知電文を同報通信にて前記発注端末へ送信する受信手段と、
前記ネットワークより同報通信で前記発注端末へ送信された通知電文を受信し、ＴＣＰ／ＩＰ通信にて前記ネットワークを通じて前記データベースサーバーへ送信し、前記データベースサーバーからの登録完了通知電文をＴＣＰ／ＩＰ通信にて前記ネットワークより受信する書き込み手段と
を具備したことを特徴とする有価証券売買システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば株券などの有価証券を売買する有価証券売買システムに関する。
【背景技術】
【０００２】
例えば証券会社などの株券売買部門の発注担当者は、証券取引所に設置された取引用のコンピュータ（サーバー）から送信されてきたデータをディーラー等に設置された発注用のコンピュータ（端末）の画面に表示させ、その端末の画面に表示されたデータの変化をユーザが見ながら、所望のタイミングで所望の株券の売買注文を行っており、一瞬が明暗を分けることがある。
【０００３】
この種の電子取引を行う従来のシステムとしては、ディーラー等のユーザにより行われた有価証券の売買注文を出すクライアント端末と、クライアント端末から出された売買注文をネットワークを介して受けて売買注文を証券取引所（外部ネットワーク）に出す注文アプリケーションサーバー（以下注文ＡＰＰサーバーと称す）と、注文ＡＰＰサーバーが証券取引所へ出した売買注文を記憶する注文ＤＢと、ユーザからの売買注文が成立した旨の通知を証券取引所より受ける出来アプリケーションサーバー（以下出来ＡＰＰサーバーと称す）と、出来ＡＰＰサーバーにより受信された通知を記憶する出来データベース（出来ＤＢ）と、を備えた証券売買注文システムがある（特許文献１参照）。
【０００４】
特許文献１に記載された証券売買注文システムの場合、ネットワークに接続されたクライアント端末によりユーザからの有価証券の売買注文を注文ＡＰＰサーバーが受けると、注文ＡＰＰサーバーは、その売買注文をネットワークを介して証券取引所に出し、ユーザからの売買注文を注文ＤＢに記憶する。
そして、証券取引所からの注文が成立した旨の通知を出来ＡＰＰサーバーが受けると、出来ＡＰＰサーバーは、成立した注文を出来ＤＢに記憶する。記憶後、出来ＤＢ及び注文ＤＢからユーザの売買注文の情報を読み出しクライアント端末の画面上にユーザの売買注文の出来状況を一覧表示する。
【０００５】
ここで、従来の証券売買注文システムの動作を、電文レベルのやり取りに落として詳細に説明する。
従来の証券売買注文システムの場合、図６に示すように、クライアント端末より注文ＡＰＰサーバーに対して売買注文電文を送信する（Ｓ８０１）。注文ＡＰＰサーバーは注文ＤＢに対して売買注文電文を送信し（Ｓ８０２）、売買注文電文が注文ＤＢに登録されたことの応答を待つ。
【０００６】
注文ＤＢで売買注文電文の登録が成功し応答が送信され（Ｓ８０３）、注文ＡＰＰサーバーに受信されると、注文ＡＰＰサーバーは、第１ゲートウェイを通じて外部ネットワークに対して注文電文を送信することで発注を行う（Ｓ８０４）。
この発注に対する応答電文（この電文は受信に対する応答の電文であって取引が成立したときの約定電文ではない）が第１ゲートウェイから返信され（Ｓ８０５）、注文ＡＰＰサーバーに受信されると、注文ＡＰＰサーバーは、その応答電文を注文ＤＢに登録する（Ｓ８０６）。注文ＤＢに応答電文が登録されて、登録終了を示す電文が注文ＤＢより返信されると（Ｓ８０７）、注文ＡＰＰサーバーは、クライアント端末へ注文が正常に受付られたことを通知する（Ｓ８０８）。このように各サーバーでは、各電文に対する送受信およびデータベースへのアクセス（記憶および読出し）等の各処理がシーケンシャルに行われる。
【０００７】
ところで、各ＡＰＰサーバーでは、注文や通知の送受信処理がコンマ何秒という単位で行われるのに対して、データベースのデータ記憶およびデータ読出しといったアクセス速度は遅く、例えば数秒程度かかる。
一方、ディーラーにおける株の取引では、複数の注文を連続して行いたいケースが多々ある。この場合でも、発注処理の段階から登録完了通知の処理までがシーケンシャルに行なわれるため、初めの注文に対して注文ＡＰＰサーバーから登録完了通知がクライアント端末へ出されるまで、クライアント端末では、次の発注ができないという問題があった。
【特許文献１】特開２００２−２１５９０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
このように従来の証券売買注文システムの場合、発注処理の段階から登録完了を通知する処理までがシーケンシャルに行なわれるため、クライアント端末では、登録終了の電文を受信するまで次の注文の処理に入れず、ユーザは、注文を連続して出したくてもそれができないという問題があった。
【０００９】
本発明はこのような課題を解決するためになされたもので、有価証券の電子取引をユーザが連続して行なうことができる有価証券売買システムを提供することを目的としている。
【課題を解決するための手段】
【００１０】
上記した課題を解決するために、本発明の有価証券売買システムは、有価証券の取引を行う取引所と通信を行うゲートウェイサーバーと、このゲートウェイサーバーにネットワークを介して接続され、取引所に有価証券の取引を行なうための注文電文を送出する発注端末と、前記ネットワークに接続され、前記発注端末および取引所間でやり取りされる電文を蓄積するデータベースサーバーと、前記ネットワークに接続され、前記発注端末からネットワークを通じて受信された注文電文、前記取引所からゲートウェイサーバーを通じて受信された通知電文を前記データベースサーバーに蓄積するアプリケーションサーバーとを備える有価証券売買システムにおいて、前記アプリケーションサーバーが、前記発注端末からＴＣＰ／ＩＰ通信にて送信された注文電文を前記ネットワークを通じて受信し前記ゲートウェイサーバーへ送信すると同時に、受信した前記注文電文に対する応答電文を同報通信にて前記発注端末へ返信する発注手段と、前記ネットワークより同報通信で前記発注端末へ送信された注文電文を受信し、ＴＣＰ／ＩＰ通信にて前記ネットワークを通じて前記データベースサーバーへ送信し、前記データベースサーバーからの登録完了通知電文をＴＣＰ／ＩＰ通信にて前記ネットワークより受信する書き込み手段とを具備したことを特徴とする。
【００１１】
本発明の有価証券売買システムは、有価証券の取引を行う取引所と通信を行うゲートウェイサーバーと、このゲートウェイサーバーにネットワークを介して接続され、取引所に有価証券の取引を行なうための注文電文を送出する発注端末と、前記ネットワークに接続され、前記発注端末および取引所間でやり取りされる電文を蓄積するデータベースサーバーと、前記ネットワークに接続され、前記発注端末からネットワークを通じて受信された注文電文、前記取引所からゲートウェイサーバーを通じて受信された通知電文を前記データベースサーバーに蓄積するアプリケーションサーバーとを備える有価証券売買システムにおいて、前記アプリケーションサーバーが、前記取引所から送信された通知電文を前記ゲートウェイサーバーおよび前記ネットワークを通じて受信し、受信した前記通知電文を同報通信にて前記発注端末へ送信する受信手段と、前記ネットワークより同報通信で前記発注端末へ送信された通知電文を受信し、ＴＣＰ／ＩＰ通信にて前記ネットワークを通じて前記データベースサーバーへ送信し、前記データベースサーバーからの登録完了通知電文をＴＣＰ／ＩＰ通信にて前記ネットワークより受信する書き込み手段とを具備したことを特徴とする。
【００１２】
本発明では、発注端末とゲートウェイサーバー間で電文をやり取りする発注手段をアプリケーションサーバーに設けると共に、これとは別に、発注手段より同報通信で発注端末へ返信された注文電文に対する応答電文をネットワークより受信して、データベースサーバーに電文の書き込み（登録）を行なう書き込み手段を独立させて設けたことで、アプリケーションサーバーでは、発注手段がデータベースサーバーにおける注文電文の登録処理を待つことなく、発注端末からの注文電文をゲートウェイサーバーへ送信でき、この時点で応答電文を発注端末へ返信して次の注文電文を受けられる。
また、取引所から受信される通知電文についても受信手段とは別に独立した書き込み手段を設けたことで、データベースサーバーにおける通知電文の登録処理を待つことなく、通知電文を発注端末へ送信できる。
この結果、発注端末のユーザは、株券などの有価証券の売買注文を連続して行なえるようになる。
【発明の効果】
【００１３】
以上説明したように本発明によれば、有価証券の電子取引をユーザが連続して行なうことができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態を図面を参照して詳細に説明する。
図１は本発明に係る一つの実施形態の株取引システムの概要構成を示す図、図２は図１の株取引システムにおいて証券会社（ディーラー）のＡＰＰサーバーの構成を示す図、図３は図１の株取引システムにおいて証券会社（ディーラー）のＤＢサーバーの構成を示す図、図４は図１の株取引システムにおいて証券会社（ディーラー）の発注端末の構成を示す図である。
【００１５】
図１に示すように、この株取引システムは、証券取引所Ａの株式売買システム１と、証券取引所Ｂの株式売買システム２と、証券取引所Ａの時価情報配信システム３と、証券取引所Ｂの時価情報配信システム４と、それぞれのシステムと専用回線５，６，７，８を介して接続された証券会社Ｃの有価証券売買システムとしての株式トレーディングシステム９とから構成されている。
株式トレーディングシステム９は、ゲートウェイサーバーコンピュータ１０（以下ＧＷサーバー１０と称す）と、このＧＷサーバー１０にＬＡＮ１１などのネットワークを介して接続されたアプリケーションサーバーコンピュータ２０（以下ＡＰＰサーバー２０と称す）と、ＬＡＮ１１に接続されたデータベースサーバー３０（以下ＤＢサーバー３０と称す）と、ＬＡＮ１１に接続されたクライアントコンピュータ４０（以下発注端末４０と称す）等から構成されている。
【００１６】
ＧＷサーバー１０、ＡＰＰサーバー２０、ＤＢサーバー３０及び発注端末４０は、ＲＯＭ、ＲＡＭなどのメモリ、オペレーティングシステム（以下ＯＳと称す）を含む各種ソフトウェアの記憶領域としてのハードディスク装置、ＯＳの環境下で起動したソフトウェアの処理を実行する制御装置としてのＣＰＵ、モニタ等の表示装置、キーボードおよびマウス等の入力装置、ＬＡＮボード等の外部ネットワークとの通信インターフェース装置等を備えるものである。
【００１７】
図２に示すように、ＡＰＰサーバー２０は、通信部２１、発注プロセス２２、受注データ書き込みプロセス２３、受信プロセス２４、受信データ書き込みプロセス２５などを有している。通信部２１および発注プロセス２２は発注手段として機能する。通信部２１および受信プロセス２４は受信手段として機能する。
【００１８】
通信部２１は、ＬＡＮ１１とＬＡＮボードを介して電文のやり取りを行なうものであり、発注端末４０より発注プロセス２２が受信した注文電文を注文キューに蓄積してＧＷサーバー１０へ順次送信する一方、ＧＷサーバー１０からの通知電文を通知キューに順次受信し受信プロセス２４に送出する。
【００１９】
発注プロセス２２は、各発注端末４０からの注文電文をＴＣＰ／ＩＰ通信で受信し、受信した注文電文を各証券取引所毎の注文電文に編集した上で通信部２１へ渡す機能と、受信した注文電文に対する応答電文をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて発注データ書き込みプロセス２３および発注端末４０へ送信する応答電文ＵＤＰ／ＩＰ返信機能と、発注端末４０から受信した注文電文を通信部２１へ送り、該当証券取引所の株式売買システム（株式売買システム１あるいは該当株式売買システム２）へ送信する機能、各証券取引所毎の注文電文を通信部２１へ渡す機能、証券取引所へ送信した注文電文に対し該当株式売買システムより返信されＧＷサーバー１０を通じて通信部２１が受信した受付電文、あるいは約定などの取引成立を知らせる通知電文をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて受信プロセス２４および発注端末４０へ送信する通知電文ＵＤＰ／ＩＰ送信機能と、各証券取引所の時価情報配信システム３，４からＧＷサーバー１０を通じて通信部２１が受信した時価情報をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて受信プロセス２４へ配信する時価情報受信及び配信機能、各発注端末４０からの時価情報要求を通信部２１へ送りＧＷサーバー１０へ送信する一方、に対し受信したことを示す応答電文をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて注文データ書き込みプロセス２３へ配信する機能等を有している。
つまり、発注プロセス２２は、発注端末４０よりＴＣＰ／ＩＰ通信によってＬＡＮ１１へ送信された注文電文、時価情報要求を受信し、受信した注文電文あるいは時価情報要求に対する応答電文をＵＤＰ／ＩＰ通信によって返信する。なお応答電文には発注内容（発注データ）が含まれている。ＵＤＰ／ＩＰとはUser Datagram Protocol/Internet Protocolの略称である。ＴＣＰ／ＩＰとはTransmission Control Protocol/Internet Protocolの略称である。
【００２０】
受注データ書き込みプロセス２３は、発注プロセス２２よりＵＤＰ／ＩＰ通信によってＬＡＮ１１を通じて返信されてきた応答電文を受信し、受信した応答電文から取り出した発注内容（発注データ）を書き込み要求としてＴＣＰ／ＩＰ通信でＬＡＮ１１を通じてＤＢサーバー３０へ送信する。
受信プロセス２４は、通信部２１の通知キューより、ＧＷサーバー１０からの通知電文を順次受信し、受信した通知電文を株式売買システム１，２毎、つまり取引所毎の通知電文に編集した上で、通知電文を含む書き込み要求を、ＵＤＰ／ＩＰ通信にてＬＡＮ１１へ送信する。
受信データ書き込みプロセス２５は、ＵＤＰ／ＩＰ通信によりＬＡＮ１１より受信した書き込み要求から通知電文を抽出し、抽出した通知電文の内容（通知データ）を、ＴＣＰ／ＩＰ通信でＬＡＮ１１を通じてＤＢサーバー３０へ送信する。
【００２１】
すなわち、ＡＰＰサーバー２０は、発注端末４０からＴＣＰ／ＩＰ通信にて送信された注文電文をＬＡＮ１１を通じて受信しＧＷサーバー１０へ送信するとほぼ同時に、受信した注文電文に対する応答電文をＵＤＰ／ＩＰ通信にて発注端末４０へ返信する発注手段としての発注プロセスと、ＬＡＮ１１よりＵＤＰ／ＩＰ通信で発注端末４０へ送信された注文電文を受信し、ＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じてＤＢサーバー３０へ送信し、ＤＢサーバー３０からの登録完了通知電文をＴＣＰ／ＩＰ通信にてＬＡＮ１１より受信する書き込み手段としての発注データ書き込みプロセス２３とを備えている。
また、ＡＰＰサーバー２０は、証券取引所から送信された通知電文をＧＷサーバー１０およびＬＡＮ１１を通じて受信し、受信した通知電文をＵＤＰ／ＩＰ通信にて発注端末４０へ送信する受信手段としての受信プロセス２４と、ＬＡＮ１１よりＵＤＰ／ＩＰ通信で発注端末４０へ送信された通知電文を受信し、ＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じてＤＢサーバー３０へ送信し、ＤＢサーバー３０からの登録完了通知電文をＴＣＰ／ＩＰ通信にてＬＡＮ１１より受信する書き込み手段としての受信データ書き込みプロセス２５とを備えている。
【００２２】
図３に示すように、ＤＢサーバー３０は、通信部３１、書き込み・読み出し処理部３２、データベース３３（以下ＤＢ３３と称す）などを備えている。
ＤＢ３３には、注文ＤＢ３４、注文受付ＤＢ３５、約定ＤＢ３６と、その他、価格ＤＢ、銘柄属性ＤＢなどの各種データベースが構築されている。
注文ＤＢ３４には、例えば銘柄コード、売買、発注数量、発注価格、発注時刻、発注市場、執行条件、社内処理用項目等、ユーザから受信された売買注文のデータが書き込まれる。
注文受付ＤＢ３５には、株式売買システム１あるいは株式売買システム２から受信された注文受付通知電文が書き込まれる。注文受付通知電文は、ユーザからの売買注文を該当証券取引所の株式売買システム１あるいは株式売買システム２へ送信したとき、該当証券取引所で売買注文を受け付けたことを示す電文である。
約定ＤＢ３６には、例えば銘柄コード、売買、約定数量、約定価格、約定時刻、約定市場、執行条件、社内処理用項目等の約定通知電文が書き込まれる。約定通知電文は、ユーザからの売買注文を該当証券取引所の株式売買システム１あるいは株式売買システム２が受けてから、取引が成立したときにそれを通知する電文である。
【００２３】
通信部３１は、ＡＰＰサーバー２０からＴＣＰ／ＩＰ通信で送信された書き込み要求をＬＡＮ１１を通じて受信して書き込み・読み出し処理部３２に渡す。通信部３１は、ＡＰＰサーバー２０よりＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じて読み出し要求を受信して書き込み・読み出し処理部３２に渡す。通信部３１は、読み出し要求に対して書き込み・読み出し処理部３２がＤＢ３３から読み出したデータを要求元へ返信する。
【００２４】
書き込み・読み出し処理部３２は、通信部３１より受け取った書き込み要求から発注内容（発注データ）を取り出し、取り出した発注内容（発注データ）を注文ＤＢ３４へ書き込む。書き込み・読み出し処理部３２は、通信部３１によりＬＡＮ１１から受信された通知電文を注文受付ＤＢ３５及び約定ＤＢ３６に記憶する。
つまり、書き込み・読み出し処理部３２は、ＵＤＰ／ＩＰ通信により通信部３１で受信された注文受付電文を注文受付ＤＢ３５に記憶する。また、書き込み・読み出し処理部３２は、通信部３１で受信された注文電文を注文ＤＢ３４に記憶する。
書き込み・読み出し処理部３２は、ＵＤＰ／ＩＰ通信により通信部３１がＬＡＮ１１から受信した書き込み要求に含まれる注文受付電文を注文受付ＤＢ３５に記憶する。書き込み・読み出し処理部３２は、ＵＤＰ／ＩＰ通信により通信部３１がＬＡＮ１１から受信した書き込み要求に含まれる約定通知電文を約定ＤＢ３６に記憶する。この他、書き込み・読み出し処理部３２は、時価情報配信システム３，４からそれぞれ受信された株券の銘柄毎の時価情報を価格ＤＢ及び銘柄属性ＤＢへ記憶する時価情報記憶機能等を有している。
【００２５】
発注端末４０は、証券取引所に有価証券の取引を行なうための売買の注文電文を送出する端末である。この発注端末４０にインストールされているソフトウェアの一つとして本システムを実現するクライアントソフトウェアがある。このクライアントソフトウェアは、図４に示すように、通信部４１、注文処理部４２、記憶部４３、画面表示処理部４４、操作処理部４５等の機能を有している。
通信部４１は、ＬＡＮ１１との電文および要求のやり取りをＬＡＮボードを介して行なう。注文処理部４２は、マウスあるいはキーボードなどで操作された指示に基づいて株券の注文処理を行う。注文処理部４２は、通信部４１に受信された約定通知電文を解読して画面表示処理部４４に渡し、画面に表示する。
記憶部４３は、ハードディスク装置およびメモリ等に生成される記憶領域であって、注文処理部４２が処理するデータを記憶すると共に注文処理部４２が注文電文、通知電文を送信用に編集する上での作業領域となる。画面表示処理部４４は、発注画面を表示するとともに、表示した発注画面の所定の欄に入力操作の内容および受信データ等を表示する。受信データとしては、時価情報、注文受付電文、約定電文等の通知データなどである。操作処理部４５は、マウスあるいはキーボードなどで操作された画面の指示を注文処理部４２に伝達する。
【００２６】
画面表示処理部４４は、メニュー画面と、このメニュー画面のメニュー選択操作により発生する発注画面とを表示する。発注画面では、株券の売買注文の入力が行なわれる。メニュー画面には、発注画面で発注された株券の売買注文の一覧および株券の売買注文の入力内容の履歴等が表示される。
【００２７】
以下、この株取引システムの動作を説明する。
この株取引システムの場合、発注端末４０では、ユーザがクライアントソフトウェアの起動操作を行なうことで、ハードディスク装置にインストールされているクライアントソフトウェアが起動し、画面表示処理部４４が表示装置にメニュー画面を表示する。このメニュー画面に表示されている発注ボタンをマウスで操作すると、画面表示処理部４４は、発注画面を表示する。発注画面には、時価情報表示欄、発注情報入力欄などと、株券の売買注文、情報照会のための各種ボタン類（発注ボタン、取り消しボタン、表示切替ボタン、プルダウンメニュー等）が表示されている。
【００２８】
一方、各証券取引所の時価情報配信システム３，４は、ディーラーに対して時価情報を所定時間間隔で配信するので、時価情報は、ＧＷサーバー１０、ＡＰＰサーバー２０を通じて複数の発注端末４０それぞれに受信される。発注端末４０では、時価情報を通信部４１が受信し、画面表示処理部４４が発注画面の該当時価情報表示欄に表示する。この時価情報は、時々刻々と変化する。発注画面の時価情報表示欄に表示された時価情報をユーザが見ながら、所望の株券についての発注操作を行う。
そして、あるタイミングで、発注画面からユーザにより発注操作が行なわれると、発注端末４０では、操作処理部４５が注文処理部４２へ操作内容を伝達するので、図７に示すように、注文処理部４２は、操作内容に応じた株券の売買注文の電文（注文電文）を生成して通信部４１に送る。通信部４１は、注文処理部４２から受け取った注文電文をＴＣＰ／ＩＰ通信でＬＡＮ１１を通じてＡＰＰサーバー２０へ送信する（Ｓ１０１）。
【００２９】
ＡＰＰサーバー２０では、ＬＡＮ１１から発注プロセス２２がＴＣＰ／ＩＰ通信で注文電文を受信すると、発注プロセス２２は、受信した注文電文を各証券取引所毎の注文電文、例えば株式売買システム1等への注文電文に編集した上で通信部２１へ渡す。注文電文を受け取った通信部２１は、該当株式売買システムである株式売買システム１への注文電文をＧＷサーバー１０へ送信する（Ｓ１０２）。
また、これと同時に、発注プロセス２２は、受信した注文電文に対する応答電文をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて発注データ書き込みプロセス２３）および発注端末４０へ送信する（Ｓ１０３）。
発注データ書き込みプロセス２３は、ＵＤＰ／ＩＰ通信（一斉同報通信）でＬＡＮ１１より注文電文を受信すると、受信した注文電文の書き込み要求をＤＢサーバー３０へ送信し（Ｓ１０４）、ＤＢサーバー３０において注文電文の登録処理が行なわれて、注文電文の登録が終了したことを示す登録完了通知電文が返信されてくるのを待機する。
【００３０】
ＤＢサーバー３０では、ＬＡＮ１１より通信部３１が注文電文を受信すると、受信した注文電文を書き込み・読み出し処理部３２に渡す。
書き込み・読み出し処理部３２は、注文電文をＤＢ３３の注文ＤＢ３４に登録、つまり書き込み処理を実行する。
ＤＢ３３への注文電文の登録が成功すると、書き込み・読み出し処理部３２は、注文電文の登録が終了したことを示す登録完了通知電文をＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じてＡＰＰサーバー２０へ返信する（Ｓ１０５）。
登録完了通知電文がＬＡＮ１１よりＡＰＰサーバー２０の発注データ書き込みプロセス２３に受信されると、発注データ書き込みプロセス２３は、自身の処理を終了する。
【００３１】
一方、Ｓ１０２の処理で送信された注文電文がＧＷサーバー１０に受信されると、ＧＷサーバー１０では、ＧＷサーバー１０のサーバープログラムが注文電文を、送信先である株式売買システム１へ通信回線５を通じて送信する。なお、証券取引所に対する発注は、上位層APIを用いて行われる。
そして、注文電文が株式売買システム１で受信されると、株式売買システム１は、受信した注文電文に対する受付処理を行なった後、注文を受け付たことを示す受付通知電文を返信するので、受付通知電文が通信回線５を通じてＧＷサーバー１０に受信されると、ＧＷサーバー１０では、ＧＷサーバー１０のサーバープログラムが受付通知電文をＬＡＮ１１を通じてＡＰＰサーバー２０へ送信する（Ｓ１０６）。
ＡＰＰサーバー２０では、ＬＡＮ１１より通信部２１が受付通知電文を受信すると、受付通知電文が通知キューに蓄積されて、順次受信プロセス２４に受信される。
受信プロセス２４は、受信した受付通知電文をＵＤＰ／ＩＰ通信（一斉同報通信）にてＬＡＮ１１を通じて受信データ書き込みプロセス２５および発注端末４０へ送信する（Ｓ１０７）。
受信データ書き込みプロセス２５は、ＵＤＰ／ＩＰ通信（一斉同報通信）でＬＡＮ１１より受付通知電文を受信すると、受信した受付通知電文を含む書き込み要求をＤＢサーバー３０へ送信し（Ｓ１０８）、ＤＢサーバー３０において受付通知電文の登録処理が行なわれて、注文電文の登録が終了したことを示す登録完了通知電文が返信されてくるのを待機する。
【００３２】
ＤＢサーバー３０では、ＬＡＮ１１より通信部３１が書き込み要求を受信すると、受信した書き込み要求に含まれる受付通知電文を書き込み・読み出し処理部３２に渡す。
書き込み・読み出し処理部３２は、受付通知電文をＤＢ３３の注文受付ＤＢ３５に登録、つまり書き込み処理を実行する。
ＤＢ３３への受付通知電文の登録が成功すると、書き込み・読み出し処理部３２は、受付通知電文の登録が終了したことを示す登録完了通知電文をＴＣＰ／ＩＰ通信にてＬＡＮ１１を通じてＡＰＰサーバー２０へ返信する（Ｓ１０９）。
登録完了通知電文がＬＡＮ１１よりＡＰＰサーバー２０の受信データ書き込みプロセス２５に受信されると、受信データ書き込みプロセス２５は、自身の処理を終了する。
【００３３】
なお、売買注文後、株式売買システム１において、注文した売買注文の取引が成立した際に、株式売買システム１より約定通知電文が送信されるが、この約定通知電文に対するＡＰＰサーバー２０の処理動作は、上記受付通知電文のときの処理動作と同様である。
【００３４】
このようにこの実施の形態の株取引システムによれば、ＡＰＰサーバー２０のソフトウェアとして、電文送受信用の発注プロセス２２、受信プロセス２４の他に、ＤＢ３３への書き込み、読み出し専用の発注データ書き込みプロセス２３および受信データ書き込みプロセス２５を設け、発注端末４０から送信された注文電文を発注プロセス２２が受信すると、注文電文に対する応答電文をＵＤＰ／ＩＰ通信により同報で返信するとほぼ同時に、受信した注文電文を通信部２１を通じてＧＷサーバー１０へ送信するので、ＵＤＰ／ＩＰ通信された応答電文をＬＡＮ１１より発注データ書き込みプロセス２３が受信してＤＢ３３への書き込み処理を実行する。
【００３５】
発注プロセス２２とＤＢサーバー３０へアクセスする発注データ書き込みプロセス２３とを分離したことで、並行処理を行なえるようになり、ＤＢ３３への電文の書き込みの遅延が発生しても、発注のタイミング、速度、連続性に影響を与えることがなくなる。
また、取引所からの受付通知電文や約定通知電文の受信処理においても上記発注処理と同様に、受信プロセス２４と受信データ書き込みプロセス２５とを分離したことで、ＤＢ３３に対するアクセス時の遅延が原因で発注端末４０への通知電文の配信が遅延することがなくなる。
【００３６】
すなわち、ＡＰＰサーバー２０では、ＤＢサーバー３０への注文電文の登録処理を発注データ書き込みプロセス２３が行なうので、発注プロセス２２は、注文電文の登録処理を待つことなく、注文電文を通信部２１を通じてＧＷサーバー１０へ送信し、応答を発注端末へ返すことができ、この時点で発注端末４０は次の注文電文を出せるようになり、発注端末４０のユーザは、株券の売買注文（発注）を連続して行なえるようになる。
なお、上記の他、本実施形態では、以下のような効果も得られる。
すなわち、発注プロセス２２への電文はTCP/IPの「ポイントToポイント」を用いることにより、発注の2重発注を防ぐことができる。
また、発注データを処理した後のACK（応答電文）の返信を、ＵＤＰ／ＩＰ通信、ブロードキャスト、マルチキャスト等の同報通信で行なうことで、複数のプロセスや複数の端末が同一の電文を同時に処理することができる。
なお、本発明は、上記実施形態のみ限定されるものではない。
上記実施形態では、発注プロセスと発注データ書き込みプロセスというように、処理手段をプログラム単位で分けたが、この他、処理手段をスレッド単位で分けてもよい。
【図面の簡単な説明】
【００３７】
【図１】本発明の一つの実施形態の株取引システムの構成を示す図。
【図２】図１の株取引システムのＡＰＰサーバーの構成を示す図。
【図３】図１の株取引システムのＤＢサーバーの構成を示す図。
【図４】図１の株取引システムの発注端末の構成を示す図。
【図５】この株取引システムの動作を示すシーケンス図。
【図６】従来の株取引システムの動作を示すシーケンス図。
【符号の説明】
【００３８】
１，２…株式売買システム、３，４…時価情報配信システム、５〜８…通信回線、９…株式トレーディングシステム、１０…ＧＷサーバー、１１…ＬＡＮ、２０…ＡＰＰサーバー、２１…通信部、２２…発注プロセス、２３…発注データ書き込みプロセス、２４…受信プロセス、２５…受信データ書き込みプロセス、３０…ＤＢサーバー、３１…通信部、３２…書き込み・読み出し処理部、３３…データベース（ＤＢ）、３４…注文ＤＢ、３５…注文受付ＤＢ、３６…約定ＤＢ、４０…発注端末、４１…通信部、４２…注文処理部、４３…記憶部、４４…画面表示処理部、４５…操作処理部。
【図１】
2005135214.tif 000003
【図２】
2005135214.tif 000004
【図３】
2005135214.tif 000005
【図４】
2005135214.tif 000006
【図５】
2005135214.tif 000007
【図６】
2005135214.tif 000008