(57)【要約】【課題】監視プログラム側のデータ連携に係わる遅延を改善する。【解決手段】売買プログラム１１は、売注文や買注文や約定通知の実データを、キー情報と共にメッセージ連携テーブル２に格納すると共に、この実データのデータ種別とキー情報を含む“種別通知情報”３をメッセージキュー１に格納する。各監視プログラム２２，２３，２４は、それぞれ、メッセージキュー１から“種別通知情報”３を順次取得し、“種別通知情報”３のデータ種別が自己に関係する場合に限り、該当する実データをキー情報に基づいてメッセージ連携テーブル２から取得する。【選択図】図１
2018139038.tif 000002
【特許請求の範囲】
【請求項１】
１以上の監視部が動作する売買システムであって、
売買に係わる任意の実情報が得られると、該実情報を第２記憶部に記憶すると共に、該実情報に係わる所定の判定情報を第１記憶部に記憶する売買実行部を有し、
前記各監視部は、それぞれ、前記第１記憶部から前記判定情報を取得して、該判定情報に基づいて自己の処理対象であるか否かを判定し、自己の処理対象であると判定した場合には前記第２記憶部から該当する前記実情報を取得するデータ取得部を有することを特徴とする売買システム。
【請求項２】
前記各監視部は、前記第１記憶部から取得した前記判定情報に基づいて自己の処理対象ではないと判定した場合には、前記第２記憶部からの実情報の取得は行わないことを特徴とする請求項１記載の売買システム。
【請求項３】
前記売買実行部は、前記売買に係わる任意の実情報が得られると、一意のキー情報を生成して、前記実情報は該キー情報と共に前記第２記憶部に記憶し、前記判定情報は該キー情報と共に前記第１記憶部に記憶し、
前記各監視部は、前記自己の処理対象であると判定した場合には、前記キー情報に基づいて前記該当する実情報を判別することを特徴とする請求項１または２記載の売買システム。
【請求項４】
前記各監視部は、前記データ取得部によって取得した前記実情報に基づいて監視画面を生成・表示して、前記売買実行部による売買実行状況をリアルタイムで監視させることを特徴とする請求項１〜３の何れかに記載の売買システム。
【請求項５】
売買サーバと監視サーバを有する売買システムにおけるデータ連携方法であって、
前記売買サーバは、売買に係わる任意の実情報が得られると、該実情報を第２記憶部に記憶すると共に、該実情報に係わる所定の判定情報を第１記憶部に記憶し、
前記監視サーバ上で動作する１以上の監視部は、それぞれ、前記第１記憶部から前記判定情報を取得して、該判定情報に基づいて自己の処理対象であるか否かを判定し、自己の処理対象であると判定した場合には前記第２記憶部から該当する前記実情報を取得することを特徴とするデータ連携方法。
【請求項６】
１以上の監視部が動作する売買システムのコンピュータを、
売買に係わる任意の実情報が得られると、該実情報を第２記憶部に記憶すると共に、該実情報に係わる所定の判定情報を第１記憶部に記憶する売買実行部と、
前記各監視部がそれぞれ有する、前記第１記憶部から前記判定情報を取得して、該判定情報に基づいて自己の処理対象であるか否かを判定し、自己の処理対象であると判定した場合には前記第２記憶部から該当する前記実情報を取得するデータ取得部、
として機能させるためのプログラム。
【請求項７】
売買サーバと監視サーバを有する売買システムにおける該売買サーバのコンピュータを、
売買に係わる任意の実情報が得られると、前記監視サーバで連携させるデータとしての該実情報を第２記憶部に記憶すると共に、該実情報に係わる所定の判定情報を第１記憶部に記憶するデータ連携部、
として機能させる為のプログラム。
【請求項８】
売買サーバと監視サーバを有する売買システムにおける該監視サーバのコンピュータを、
前記売買サーバが任意の実情報に係わる判定情報を記憶した第１記憶部から該判定情報を取得して、該判定情報から自己の処理対象であるか否かを判定して、自己の処理対象であると判定した場合には、前記売買サーバが前記実情報を記憶した第２記憶部から該当する実情報を取得するデータ取得部、
として機能させる為のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、売買プログラムとその売買状況の監視を行う監視プログラムによって構成される売買システムにおけるデータ連携方式に関する。
【背景技術】
【０００２】
図１１に、従来の株式売買システムのシステム構成例を示す。
図示の例では、株式売買システムは、売買サーバ１１０、監視サーバ１２０等を有する。売買サーバ１１０では、売買プログラム１１１が動作している。売買サーバ１１０には、不図示の外部装置から、証券の買注文／売注文等が入力され、この様な証券の注文が入力されると、売買プログラム１１１によって売注文と買注文とを突合させる。売注文と買注文との突合により売買が成立した場合、売買プログラム１１１より約定通知（売買の成立情報）が生成・出力される。
【０００３】
また、株式売買システムにおいて、売注文／買注文、および、約定通知の発生状況を監視するため、これらの情報を売買サーバ１１０から取得して監視画面１２１に表示する監視サーバ１２０が、設けられている。監視サーバ１２０では、注文監視プログラム１２２、約定監視プログラム１２３、集計情報監視プログラム１２４等が動作する。
【０００４】
これら各監視プログラム１２２，１２３，１２４は、それぞれが、売買サーバ１１０から所定のデータを取得して監視画面１２１上に所定の画面を表示する。株式売買システムの管理者は、各監視プログラムによって画面に出力される情報を確認して、証券の注文状況、売買の成立状況を監視する。
【０００５】
尚、株式売買システムは、更に運用管理サーバ１００を有していても良い。運用管理サーバ１００は、ジョブ管理ミドルウェア１０１を有し、例えば、売買サーバ１１０、監視サーバ１２０の各プロセス（売買プログラム１１１、注文監視プログラム１２２、約定監視プログラム１２３、集計情報監視プログラム１２４）の起動／停止の指示を行う。
【０００６】
売買プログラム１１１と、注文監視プログラム１２２／約定監視プログラム１２３／集計情報監視プログラム１２４との間でのデータ連携は、メッセージキューが使用される。すなわち、売買サーバ１１０はメッセージキュー１１２を有し、監視サーバ１２０はメッセージキュー１２５を有する。同期機能によりメッセージキュー１１２からメッセージキュー１２５へのデータ転送が行われる。これより、売買サーバ１１０の売買プログラム１１１が、売注文／買注文、約定通知を自己のメッセージキュー１１２に格納すると、この格納データが、監視サーバ１２０側のメッセージキュー１２５へ転送・格納される。
【０００７】
各監視プログラム１２２，１２３，１２４は、それぞれが、メッセージキュー１２５からデータを取得して自己の処理を実行する。尚、監視サーバ１２０には、メッセージキュー１２５の格納データの管理を行う不図示の機能が設けられている。この機能は、例えばメッセージキュー１２５に新規データが格納される毎に、各監視プログラム１２２，１２３，１２４を起動する処理を行う。また、この機能によって、各監視プログラム１２２，１２３，１２４は古いデータから順に取得していく。また、この機能によって、各監視プログラム１２２，１２３，１２４による各格納データの取得の有無が管理され、全ての監視プログラムによって取得された格納データはクリアする等の処理が行われても良い。
【０００８】
売買プログラム１１１は、売注文１件、買注文１件、約定通知１件の情報が発生する毎に、そのデータをメッセージキュー１１２に格納する。この１件のデータがメッセージキュー１２５に転送・格納されると、それを契機に注文監視プログラム１２２／約定監視プログラム１２３／集計情報監視プログラム１２４の各監視プログラムが起動して、メッセージキュー１２５の格納データを用いた所定の処理が行われる。
【０００９】
なお、このような株式売買システムでは、株式の取引を短時間に大量に処理するため、高い処理性能が求められる。
【００１０】
図１１に示す株式売買システムにおいて、売買プログラム１１１から注文監視プログラム１２２／約定監視プログラム１２３／集計情報監視プログラム１２４に買注文／売注文／約定通知をデータ連携させる際、売注文／買注文／約定通知の区別なく全てのデータを１つのメッセージキューに格納させる。尚、ここではメッセージキュー１１２とメッセージキュー１２５とを纏めて１つのメッセージキューとして説明するものとする。
【００１１】
このように、売買プログラム１１１から各監視プログラムへのデータ連携を１つのメッセージキューに集約しているのは、売買プログラム１１１の処理負荷を軽減するためである。各監視プログラム向けにそれぞれメッセージキューを用意して、それぞれのメッセージキューに対して売買プログラム１１１からデータを格納する場合、１件のデータに対して２〜３倍の処理量となってしまう。
【００１２】
また、売買サーバ１１０は、株式の取引を短時間に大量に処理するため、監視サーバ１２０よりも性能が高いマシンが使われている。更に、監視サーバ１２０における画面生成・出力の負荷が大きい等の理由により、売買サーバ１１０の方が監視サーバ１２０よりも処理が速く、監視プログラムの処理が追いつかない場合がある。
【００１３】
また、例えば、特許文献１、２の従来技術が知られている。
特許文献１には、複数の取引処理を所定の単位で分割してそれぞれ各処理（処理の為のサブ業務単位を含む）を並行処理で実行する証券取引方法が開示されている。また、証券取引で、売買のメッセージがメッセージキューを介して送受信される点が、開示されている。
【００１４】
また、特許文献２には、シグナルを受信したことに対応して、メッセージキューに登録されているメッセージ中から優先度の高いメッセージを見つけるメッセージ優先度解析部と、見つけた優先度の高いメッセージに対応するデータをメッセージバッファの領域から読み出すデータ読み出し部とを設けた受信プロセスを備えるように構成することが、開示されている。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００９−９６１３号公報
【特許文献２】特開平７−８４８０４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１６】
上記のように、株式売買システムでは、複数の監視プログラムが１つのメッセージキューを共有する為、以下に述べる問題が生じる。
【００１７】
すなわち、各監視プログラムは、メッセージキューからデータを受信してプログラムを起動するフレームワークを適用して動作している。これにより、各監視プログラムはメッセージキューにデータが格納される毎に起動してデータを処理するが、上記のように１つのメッセージキューを共有する為、格納データが自己にとって必要ないデータである場合がある。
【００１８】
例えば、注文監視プログラム１２２は買注文と売注文のみ、約定監視プログラム１２３は約定通知のみ、集計情報監視プログラム１２４は買注文・売注文・約定通知のすべてのデータを対象として処理を行う。このため、自プログラムが処理対象とするデータ以外のキュー格納データによって起動した場合、その格納データは読み出した後に直ちに読み捨てられることになる。つまり、無駄なデータ読出し処理が行われることになる。
【００１９】
これについて、例えば、図１２を参照して説明する。
図１２は、図１１の従来の株式売買システムの動作を説明する為の図である。
【００２０】
ここで、図１２に示すメッセージキュー１３０は、上記メッセージキュー１１２とメッセージキュー１２５を、１つに纏めて示したものである。
【００２１】
売買プログラム１１１は、買注文データ１３１、売注文データ１３２、約定通知データ１３３を、メッセージキュー１３０に格納する。上記のように、これらの何れかのデータがメッセージキュー１３０に１件格納される毎に、各監視プログラムが起動してメッセージキュー１３０から読み出すことになる。
【００２２】
たとえば、注文監視プログラム１２２では、メッセージキュー１３０に買注文データ１３１が格納された場合、プログラムが起動して買注文データ１３１をメッセージキュー１３０から読み出して、この買注文データ１３１に基づいて所定の処理を行って監視画面１２１に画面出力する。つまり、この場合には特に問題ない。しかしながら、注文監視プログラム１２２は、メッセージキュー１３０に約定通知データ１３３が格納された場合でも、プログラムが起動して約定通知データ１３３をメッセージキュー１３０から読み出すが、これは自プログラムには関係の無いデータであるので（不要なデータであるので）、読み出した約定通知データ１３３を捨てることになる。この様に、プログラムが起動してもデータを読み捨てるのみで処理が終了する場合がある。
【００２３】
ここで、買注文データ１３１、売注文データ１３２、約定通知データ１３３は、何れも、データ量がある程度大きい（データ長が長い）。この為、各監視プログラムがこれらのデータをメッセージキュー１３０から読み出す処理は、ある程度時間が掛かることになる。しかしながら、この様にしてデータを読み出しても、上記のように不要なデータを読み出した場合には直ちに破棄することになり、無駄な読出し処理が行われることになる。
【００２４】
株式売買システムにおける監視は、注文状況や売買の成立状況をリアルタイムで監視をする必要がある。この為、各監視プログラム１２２，１２３，１２４は、売買プログラム１１１によってメッセージキュー１３０に格納されたデータを直ちに読み出して監視画面に反映させることが望まれる。しかし、このシステムでは取引を円滑にするために売買プログラム１１１の処理性能をより優先しており、売買プログラム１１１の処理が速く監視プログラムの処理が追いつかず、メッセージキュー１３０にデータが滞留する可能性がある。
【００２５】
従来の技術では、メッセージキュー１３０に格納されたデータを各監視プログラムが順に取得して処理するが、注文監視プログラムが約定通知を取得した場合などのように、取得したデータを直ちに読み捨ててプログラムを終了する場合がある。買注文／売注文、約定通知の１件1件のデータはデータ量が大きいため、各監視プログラムがメッセージキューからデータを取得するのに時間が掛かるが、メッセージキュー１３０からデータを取得してもそのデータによっては処理をしないことになる。
【００２６】
そして、上記のように、メッセージキュー１３０へのデータ格納・読出し処理に関して、売買プログラム１１１によるデータ格納処理に対して、性能差等により各監視プログラム１２２，１２３，１２４のデータ読出し処理が追いつかず、メッセージキュー１３０へのデータ格納から取得までに遅延が発生する場合がある。特に短時間に取引が集中する場合、この遅延が拡大し、注文状況や売買の成立状況のリアルタイムでの監視に弊害が出てしまう。更に、上記のように不要なデータもあり、監視プログラムが無用なメッセージキュー１３０からのデータ読出しを行う場合がある。
【００２７】
本発明の課題は、売買プログラムと各監視プログラムとでデータ連携を行う売買システムにおいて、監視プログラムに無用な実データ読出し処理を回避させ、以って監視プログラム側のデータ連携に係わる遅延を改善することができる売買システム、データ連携方法、プログラム等を提供することである。
【課題を解決するための手段】
【００２８】
本発明の売買システムは、１以上の監視部が動作する売買システムであって、売買に係わる任意の実情報が得られると、該実情報を第２記憶部に記憶すると共に、該実情報に係わる所定の判定情報を第１記憶部に記憶する売買実行部を有する。
【００２９】
そして、前記各監視部は、それぞれ、前記第１記憶部から前記判定情報を取得して、該判定情報に基づいて自己の処理対象であるか否かを判定し、自己の処理対象であると判定した場合には前記第２記憶部から該当する前記実情報を取得するデータ取得部を有する。
【発明の効果】
【００３０】
本発明の売買システム、データ連携方法、プログラム等によれば、売買プログラムと各監視プログラムとでデータ連携を行う売買システムにおいて、監視プログラムに無用な実データ読出し処理を回避させ、以って監視プログラム側のデータ連携に係わる遅延を改善することができる。
【図面の簡単な説明】
【００３１】
【図１】本例の株式売買システムの構成・動作を示す図である。
【図２】図１の株式売買システムの具体的なシステム構成例である。
【図３】（ａ）〜（ｄ）は、本例の株式売買システムに関わる各種データ構成例である。
【図４】売買プログラムの処理フローチャート（その１）である。
【図５】売買プログラムの処理フローチャート（その２）である。
【図６】注文監視プログラムの処理フローチャートである。
【図７】約定監視プログラムの処理フローチャートである。
【図８】集計情報監視プログラムの処理フローチャートである。
【図９】（ａ）〜（ｃ）は、各監視プログラムによる画面出力例である。
【図１０】本例の株式売買システムの機能ブロック図である。
【図１１】従来の株式売買システムのシステム構成例を示す図である。
【図１２】図１１の従来の株式売買システムの動作を説明する為の図である。
【発明を実施するための形態】
【００３２】
以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本例の株式売買システムの構成・動作を示す図である。
【００３３】
本例の株式売買システムでも、従来と同様、売買プログラムと、複数の監視プログラムが動作していると共に、売買プログラムと各監視プログラムとの間で記憶部を介したデータ連携が行われる。
【００３４】
図示の例では、株式売買システムは、売買プログラム１１と、注文監視プログラム２２、約定監視プログラム２３、集計情報監視プログラム２４を有する。そして、売買プログラム１１と、注文監視プログラム２２／約定監視プログラム２３／集計情報監視プログラム２４との間でのデータ連携は、メッセージキュー１とメッセージ連携テーブル２が用いられる。データ連携は、従来では上記の通りメッセージキューを使用したが、本例では更にメッセージ連携テーブル２も使用される。
【００３５】
まず、売買プログラム１１は、任意の売注文や買注文や約定通知が１件発生する毎に、それに対応する一意のキー情報を生成する。キー情報は、例えば、１，２，３，４，５、・・・等であっても良い。
【００３６】
そして、売買プログラム１１は、上記売注文や買注文や約定通知の実データを、メッセージキュー１には格納せず、メッセージ連携テーブル２に格納する（キー情報も一緒に格納する）。すなわち、売買プログラム１１は、売注文／買注文／約定通知が１件発生する毎に、任意のキー情報を生成して、このキー情報と共に実データ（売注文データ／買注文データ／約定通知データ）をメッセージ連携テーブル２に格納する。売買プログラム１１は、更に、上記発生した実データのデータ種別を、このキー情報に対応付けて、メッセージキュー１に格納する。
【００３７】
ここで、キー情報は、例えば１，２，３，４，５、・・・等の様に順次＋１インクリメントされる番号等であり、データ種別は売注文／買注文／約定通知の何れかを示す。例えば、買注文データをメッセージ連携テーブル２に格納する場合には、データ種別は“買注文”を示すものとなる。
【００３８】
この様に、本手法では、売買プログラムから各監視プログラムへのデータ連携に関して、実データ（買注文データ／売注文―多／約定通知データ）は、メッセージキュー１ではなくメッセージ連携テーブル２に格納する。メッセージキュー１には、上記メッセージ連携テーブル２に格納する実データの種類を示す情報（データ種別）が格納される。
【００３９】
つまり、メッセージキュー１に格納される情報（読み捨てられる可能性がある情報）は、監視プログラムを起動する契機とするための最小限の情報のみとする。データ種別は、どの監視プログラムで処理実行させるかを判定する為の判定情報の一例となる。データ種別は、各監視プログラムにおいて、メッセージキュー１からの取得データに対応する実データが、自己の処理対象であるか否かを判定させる為の判定情報の一例である。
【００４０】
また、例えば、上記実データとデータ種別は、両方とも、売買プログラム１１によって一意に採番されたキー情報に対応付けて格納する。各監視プログラムは、このキー情報によって、メッセージ連携テーブル２における該当データを判別できる。
【００４１】
尚、メッセージキュー１に格納するデータ（データ種別３ｂ＋キー情報３ａ）を、“種別通知情報”３と記すものとする。また、メッセージ連携テーブル２には、キー情報２ａと実データ２ｂが格納される（キー情報２ａに対応付けられて実データ２ｂが格納される）。
【００４２】
メッセージ連携テーブル２に格納する各実データ２ｂ（買注文実データ／売注文実データ／約定通知実データ）と、メッセージキュー１に格納される“種別通知情報”３との対応関係は、上記キー情報２ａ，３ａによって判別できる。
【００４３】
各監視プログラム（２２，２３，２４）は、それぞれが、従来と同様に、メッセージキュー１にデータが格納されたことを契機として起動し、まず、メッセージキュー１から１件のデータを取り出す。この動作自体は従来と同様であるが、メッセージキュー１の格納データ（“種別通知情報”３）は、実データに比べてデータ量が非常に小さいので、データ取得負荷が大幅に軽減される。
【００４４】
その後、各監視プログラム（２２，２３，２４）は、それぞれが、メッセージキュー１からの取得データ“種別通知情報”３のデータ種別３ｂに基づいて、それに該当する実データが自己の処理対象であるか否かを判別する。そして、自己の処理対象である場合には、“種別通知情報”３に含まれるキー情報３ａをもとに、メッセージ連携テーブル２から該当する実データ２ｂを取得し、これに基づいて監視データを生成して画面出力する。尚、該当する実データ２ｂとは、メッセージ連携テーブル２において、対応付けられたキー情報２ａが種別通知情報”３に含まれるキー情報３ａと一致する実データ２ｂである。
【００４５】
ここで、メッセージ連携テーブル２から該当する実データ２ｂを取得する動作に関して、図１では注文監視プログラム２２を例に矢印で示しているが、他の監視プログラム２３，２４も同様に、必要に応じてメッセージ連携テーブル２から該当する実データ２ｂを取得する動作を行う。
【００４６】
ここでは注文監視プログラム２２を例にすると、メッセージキュー１から取得した“種別通知情報”３のデータ種別３ｂが“約定通知”であった場合には、自己の処理対象ではないと判定し、取得データを破棄して処理終了とする。一方、メッセージキュー１から取得した“種別通知情報”３のデータ種別３ｂが例えば“買注文”であった場合には、自己の処理対象であると判定し、“種別通知情報”３のキー情報３ａをもとに、メッセージ連携テーブル２から該当する実データ２ｂを取得する。この場合、取得される実データ２ｂは、買注文データであるはずである。そして、取得した実データ２ｂに基づいて所定の処理を実行して監視データを生成して画面出力する。
【００４７】
上記のように、本手法においてもメッセージキューからの取得データを破棄する場合があるが、それはデータ量が実データに比べて格段に少ない“種別通知情報”３であり、実データを取得後に直ちに破棄するようなことはない。つまり、データ量が多い実データに関しては、無駄なデータ読出しが行われることはない（監視プログラムに無用な実データ読出し処理を回避させることができる）。
【００４８】
ここで、図１では、売買プログラム１１が、“買注文”→“売注文”→“約定通知”→“約定通知”の順で順次、監視側とデータ連携した例を纏めて示している。
【００４９】
つまり、図示の例の場合、売買プログラム１１は、まず、任意の買注文データ（実データ）に関して、キー情報３ａ＝「１」、データ種別３ｂ＝「買注文」の“種別通知情報”３を生成してメッセージキュー１に格納する。更に、この買注文データ（実データ）をこのキー情報＝「１」と共にメッセージ連携テーブル２に格納する。
【００５０】
売買プログラム１１は、続いて、任意の売注文データ（実データ）に関して、キー情報３ａ＝「２」、データ種別３ｂ＝「売注文」の“種別通知情報”３を生成してメッセージキュー１に格納する。更に、この売注文データ（実データ）をこのキー情報＝「２」」と共にメッセージ連携テーブル２に格納する。
【００５１】
売買プログラム１１は、次に、任意の約定通知データ（実データ）に関して、キー情報３ａ＝「３」、データ種別３ｂ＝「約定通知」の“種別通知情報”３を生成してメッセージキュー１に格納する。更に、この約定通知データ（実データ）をこのキー情報＝「３」」と共にメッセージ連携テーブル２に格納する。
【００５２】
売買プログラム１１は、次に、別の任意の約定通知データ（実データ）に関して、キー情報３ａ＝「４」、データ種別３ｂ＝「約定通知」の“種別通知情報”３を生成してメッセージキュー１に格納する。更に、この約定通知データ（実データ）をこのキー情報＝「４」」と共にメッセージ連携テーブル２に格納する。
【００５３】
各監視プログラム（２２，２３，２４）は、それぞれ、メッセージキュー１に任意のデータが格納されると起動して、メッセージキュー１からデータを取得する。上記の例では最初は、キー情報３ａ＝「１」、データ種別３ｂ＝「買注文」の“種別通知情報”３を、取得することになる。この場合、約定監視プログラム２３は、データ種別３ｂが「買注文」であることから、自己の処理対象ではないと判定して、取得した“種別通知情報”３を破棄して処理終了する。一方、注文監視プログラム２２、集計情報監視プログラム２４は、データ種別３ｂが「買注文」であることから、自己の処理対象であると判定して、上記キー情報＝「１」を用いてメッセージ連携テーブル２から該当する実データ２ｂ（買注文データ（実データ））を取得する。そして、取得した実データ２ｂに基づいて所定の処理を実行して監視画面出力などを行う。
【００５４】
各監視プログラム（２２，２３，２４）は、それぞれ、続いて、メッセージキュー１から、キー情報３ａ＝「２」、データ種別３ｂ＝「売注文」の“種別通知情報”３を、取得することになる。この場合も、約定監視プログラム２３は、データ種別３ｂが「売注文」であることから、自己の処理対象ではないと判定して、取得した“種別通知情報”３を破棄して処理終了する。一方、注文監視プログラム２２、集計情報監視プログラム２４は、データ種別３ｂが「売注文」であることから、自己の処理対象であると判定して、上記キー情報３ａ＝「２」を用いてメッセージ連携テーブル２から該当する実データ２ｂ（売注文データ（実データ））を取得する。そして、取得した実データ２ｂに基づいて所定の処理を実行して監視画面出力などを行う。
【００５５】
各監視プログラム（２２，２３，２４）は、それぞれ、続いて、メッセージキュー１から、キー情報３ａ＝「３」、データ種別３ｂ＝「約定通知」の“種別通知情報”３を、取得することになる。この場合は、注文監視プログラム２２は、データ種別３ｂが「約定通知」であることから、自己の処理対象ではないと判定して、取得した“種別通知情報”３を破棄して処理終了する。一方、約定監視プログラム２３、集計情報監視プログラム２４は、データ種別３ｂが「約定通知」であることから、自己の処理対象であると判定して、上記キー情報３ａ＝「３」を用いてメッセージ連携テーブル２から該当する実データ２ｂ（約定通知データ（実データ））を取得する。そして、取得した実データ２ｂに基づいて所定の処理を実行して監視画面出力などを行う。
【００５６】
次のキー情報３ａ＝「４」の“種別通知情報”３に関して、約定監視プログラム２３と集計情報監視プログラム２４は、メッセージ連携テーブル２から、キー情報２ａ＝「４」に対応する実データ２ｂ（約定通知データ（実データ））を、取得することになる。一方、注文監視プログラム２２は、自己の処理対象ではないと判定して、取得した“種別通知情報”３を破棄して処理終了することになる。
【００５７】
図２に、図１の株式売買システムの具体的なシステム構成例を示す。
但し、これは一例であり、この例に限るものではない。図２では２台のサーバ装置で構成されるが、この例に限らず、１台または３台以上のサーバ装置で構成されてもよい。
【００５８】
図示の例の株式売買システムは、上記図１１の例と同様、売買サーバ１０、監視サーバ２０等を有する。そして、上記売買プログラム１１は売買サーバ１０上で動作している。また、上記各監視プログラム（注文監視プログラム２２／約定監視プログラム２３／集計情報監視プログラム２４）は、監視サーバ２０上で動作している。
【００５９】
売買サーバ１０は、外部のサーバ装置等から送信されてくる買注文、売注文に基づいて、売買成立、約定通知の生成・通知等を行う。また、これら、売注文／買注文、および、約定通知の発生状況を監視するため、これらの情報を売買サーバ１０から取得して監視画面２１に表示する監視サーバ２０が、設けられている。監視サーバ２０では、上記各監視プログラム２２、２３、２４等が動作する。
【００６０】
これら各監視プログラム２２，２３，２４は、それぞれが、売買サーバ１０から所定のデータを取得して監視画面２１上に画面表示する。株式売買システムの管理者は、各監視プログラムによって画面に出力される情報を確認して、証券の注文状況、売買の成立状況を監視する。
【００６１】
ここで、図示の例では、売買サーバ１０はメッセージキュー１２を備え、監視サーバ２０はメッセージキュー２５を備える。これらメッセージキュー１２及びメッセージキュー２５が、図１のメッセージキュー１に相当する。尚、これは上記従来のメッセージキュー１１２及びメッセージキュー１２５と、メッセージキュー１３０との関係と同様である。従って、メッセージキュー１２、２５に関しても、メッセージキュー１２の格納データは、不図示の既存の同期機能によって、メッセージキュー２５に転送・格納されることになる。
【００６２】
また、図示の例では、売買サーバ１０がメッセージ連携テーブル１３を備え、監視サーバ２０がメッセージ連携テーブル２６を備える。これらメッセージ連携テーブル１３及びメッセージ連携テーブル２６が、図１のメッセージ連携テーブル２に相当する。上記メッセージキューの場合と同様に、メッセージ連携テーブル１３の格納データは、不図示の同期機能によってメッセージ連携テーブル２６に転送・格納される。
【００６３】
上記売買プログラム１１は、メッセージ連携テーブル１３に実データ等を格納する。上記各各監視プログラム（注文監視プログラム２２／約定監視プログラム２３／集計情報監視プログラム２４）は、必要に応じて、メッセージ連携テーブル２６から実データ等を取得する。
【００６４】
売買プログラム１１が動作している売買サーバ１０には、不図示の外部装置から、証券の買注文／売注文等が入力され、この様な証券の注文が入力されると、売買プログラム１１によって売注文と買注文とを突合させる。売注文と買注文との突合により売買が成立した場合、売買プログラム１１より約定通知（売買の成立情報）が生成・出力される。
【００６５】
また、例えば、一例としては、売買サーバ１０と監視サーバ２０とでは性能差があり、売買サーバ１０の方が処理性能が高い場合もあり得るが、この例に限らない。あるいは、監視サーバ２０における監視画面生成・表示処理の処理負荷が、売買サーバ１０の処理負荷よりも大きい場合もあり得るが、この例に限らない。理由が何であれ、従来では、監視サーバ２０が売買サーバ１０の処理に追いつけず、実データ取得に遅延が発生する場合があったが、本手法によればこの様な場合でも遅延を短縮することができる。
【００６６】
尚、図２は一例であり、この例に限らず、例えば一台のサーバ上に全ての機能（売買プログラム１１や後述する注文監視プログラム２２／約定監視プログラム２３／集計情報監視プログラム２４、メッセージキュー１など）が搭載された構成であっても良い。
【００６７】
尚、図２に示す例では、株式売買システムは、更に、ジョブ管理ミドルウェア３１を備える運用管理サーバ３０を有するが、これ自体は従来と同様であってよく、特に説明しないものとする。尚、ジョブ管理ミドルウェア３１は、例えば、売買サーバ１０、監視サーバ２０の各プロセスの起動／停止を指示するものである。
【００６８】
ここで、図３（ａ）〜（ｄ）に、上記株式売買システムに関わる各種データ構成例を示す。
図３（ａ）は、買注文／売注文に係わる電文４０のデータ構成例である。
【００６９】
尚、この電文４０（買注文／売注文）は、不図示の外部システム（機関投資家、証券会社など）から送信されて、売買サーバ１０が受信する。売買サーバ１０は、電文４０を受信する毎に、例えば後述する図４及び図５に示す処理を実行する。
【００７０】
図示の例では電文４０は、電文コード４１、銘柄４２、参加者４３、売買区分４４、値段４５、数量４６、時刻４７などの各種データより構成され、更に特に図示しない他のデータを含む。そして、電文４０の全データ量は、たとえば約2,000Byteである。従来では、メッセージキューに、たとえばデータ量が約2,000Byte前後である買注文／売注文データが格納される。
【００７１】
図３（ｂ）は、約定通知に係わる電文５０のデータ構成例である。
尚、この電文５０（約定通知）は、売買サーバ１０が上記電文４０（買注文／売注文）に基づいて生成する。
【００７２】
図示の例では電文５０は、電文コード５１、銘柄５２、参加者５３、売買区分５４、値段５５、数量５６、時刻５７などの各種データより構成され、更に特に図示しない他のデータを含む。そして、電文５０の全データ量は、たとえば約1500Byteである。従来では、メッセージキューに、たとえばデータ量が約1500Byte前後である約定通知データが格納される。
【００７３】
図３（ｃ）に、上記メッセージ連携テーブル２のデータ構成例を示す。
尚、上記メッセージ連携テーブル１３，２６のデータ構成は、メッセージ連携テーブル２と同じである。
【００７４】
図示の例では、メッセージ連携テーブル２は、キーNo.６１、電文種別６２、銘柄６３、参加者６４、売買区分６５、値段６６、数量６７、時刻６８などの各種データより構成され、更に特に図示しない他のデータを含む。キーNo.６１は上記キー情報の一例である。電文種別６２〜時刻６８等は、上記電文４０における電文コード４１〜時刻４７等、あるいは、電文５０における電文コード５１〜時刻５７等に相当する。つまり、メッセージ連携テーブル２には、「キーNo.６１＋電文４０」あるいは「キーNo.６１＋電文５０」が、格納される。
【００７５】
従って、メッセージ連携テーブル２に格納される各レコードのデータ量は、電文５０の全データ量（約1500Byte）と同等、あるいは、電文４０の全データ量（約2,000Byte）と同等である。従って、各監視プログラムがメッセージ連携テーブル２からデータ（１レコード分）を取得する処理には、ある程度、時間が掛かることになる。一方で、図３（ｄ）に示すような“種別通知情報”３を取得する処理には、時間が掛からないことになる。
【００７６】
図３（ｄ）は、上記“種別通知情報”３のデータ構成例である。
図示の例では、“種別通知情報”３は、キーNo.７１と電文種別７２から構成される。キーNo.７１は、上記キーNo.６１と同様に上記キー情報の一例である。そして、図示の例では、キーNo.７１は8Byte、電文種別７２は1Byteであり、“種別通知情報”３全体で9Byteに過ぎない。つまり、上記実データの約2,000Byteや約1500Byteに比べて、データ量が非常に小さくて済み、監視プログラムがメッセージキューからデータ取得する処理負荷が軽減される（処理時間が非常に短くて済む）。従って、たとえメッセージキューから取得した“種別通知情報”を直ちに破棄することになっても、無駄は最小限に抑えられることになる。
【００７７】
尚、電文種別７２は、例えば、売買プログラム１１が、電文コード５１、売買区分５４に基づいて、あるいは電文コード４１と売買区分４４に基づいて、生成している。つまり、電文コード４１が「注文」で売買区分４４が「売」であったら電文種別７２は「売注文」、電文コード４１が「注文」で売買区分４４が「買」であったら電文種別７２は「買注文」と判定する。電文コード５１が「約定通知」であったら電文種別７２は「約定通知」となる。尚、これは上記電文種別６２に関しても同様であっても良い。
【００７８】
図４〜図８に、上記各プログラムの処理フローチャートを示し、以下、説明する。
図４、図５は、売買プログラムの処理フローチャート（その１）（その２）である。尚、図４、図５は、１つの処理を２分割して示しているのであり、従って以下の説明では特に区別せずに“図４等”と記すものとする。
【００７９】
また、本処理中にはキーNo.に係わる変数“Ｘ”を用いるものとする。変数“Ｘ”の値は、例えば売買プログラム１１の起動時の初期処理の際に所定の初期値（仮に‘１’とする）がセットされている。
【００８０】
図４等に示す処理例では、売買プログラム１１は、随時、注文入力待ち状態となっており（ステップＳ１１）、任意の注文入力があるとステップＳ１２以降の処理を開始する。尚、注文入力は、上記不図示の外部システムから送られてくる上記買注文、売注文等を、受信したものである。
【００８１】
そして、注文入力が“売注文”であれば（ステップＳ１２，ＹＥＳ）ステップＳ１３〜Ｓ１６の処理を実行してステップＳ２１へ移行し、“買注文”であれば（ステップＳ１２，ＮＯ）ステップＳ１７〜２０の処理を実行してステップＳ２１へ移行する。
【００８２】
“売注文”を受信した場合には（ステップＳ１２，ＹＥＳ）、まず、この“売注文”データ（実データ）を現在のキーNo.“Ｘ”（初期状態であればキーNo.＝‘１’）と共にメッセージ連携テーブル２に格納する（ステップＳ１３）。更に、この“売注文”データに対応する“種別通知情報”３（そのキーNo.７１が現在のキーNo.“Ｘ”、その電文種別７２が「売注文」）を生成してメッセージキュー１に格納する（ステップＳ１４）。そして、“Ｘ”の値を＋１インクリメントする（ステップＳ１５）。
【００８３】
上記“売注文”データ入力に応じた処理によって、上記具体例であれば、メッセージキュー１には9Byteのデータが格納され、メッセージ連携テーブル２には約2,000Byteの実データが格納されることになる。
【００８４】
その後、売注文の受付通知を注文入力元（外部システム）へ送信して（ステップＳ１６）、ステップＳ２１へ移行する。
【００８５】
一方、“買注文”を受信した場合には（ステップＳ１２，ＮＯ）、まず、この“買注文”データ（実データ）を現在のキーNo.“Ｘ”と共にメッセージ連携テーブル２に格納する（ステップＳ１７）。更に、この“買注文”データに対応する“種別通知情報”３（そのキーNo.７１が現在のキーNo.“Ｘ”、その電文種別７２が「買注文」）を生成してメッセージキュー１に格納する（ステップＳ１８）。そして、“Ｘ”の値を＋１インクリメントする（ステップＳ１９）。
【００８６】
上記“買注文”入力に応じた処理によって、上記具体例であれば、メッセージキュー１には9Byteのデータが格納され、メッセージ連携テーブル２には約2,000Byteの実データが格納されることになる。
【００８７】
その後、買注文の受付通知を注文入力元（外部システム）へ送信して（ステップＳ２０）、ステップＳ２１へ移行する。
【００８８】
ステップＳ２１の処理は注文の突合処理であり、それによって売買成立か否かを判定する（ステップＳ２２）。この注文の突合処理自体は、既存の処理であり、概略的には、例えば下記のようになる。
【００８９】
突合処理とは、入力された（もしくは入力済みとなっている）売注文の中で最も優先される売注文と、入力された（もしくは入力済みとなっている）買注文の中で最も優先される買注文とが、ある値段で合致するか否かを確認する処理である。そして、合致する場合には、これらの売注文と買注文とで「売買成立」と判断する。
【００９０】
注文の優先順位については、注文の値段や入力された時刻によって、価格優先の原則や時間優先の原則などに従って決定される。価格優先の原則とは、売注文については値段の低い注文が優先され、買注文については値段の高い注文が優先されるという原則である。時間優先の原則とは、同じ値段の注文が複数件入力済みであった場合には注文が行われた時間によって、先に入力された注文が優先されるという原則である。
【００９１】
売買成立した場合には（ステップＳ２２，ＹＥＳ）ステップＳ２３〜Ｓ３０の処理を実行してステップＳ１１に戻り、売買不成立の場合には（ステップＳ２２，ＮＯ）そのままステップＳ１１の処理に戻るが、何れの場合でも停止指示があった場合には（ステップＳ３１，ＹＥＳ）売買プログラム１１の実行を停止する。尚、停止指示は、図１の運用管理サーバ３０のジョブ管理ミドルウェア３１から出される。
【００９２】
売買成立した場合には（ステップＳ２２，ＹＥＳ）、まず、売注文に対する約定通知を生成して、この約定通知（実データ）を現在のキーNo.“Ｘ”と共にメッセージ連携テーブル２に格納する（ステップＳ２３）。更に、この約定通知（実データ）に対応する“種別通知情報”３（そのキーNo.７１が現在のキーNo.“Ｘ”、その電文種別７２が「約定通知」）を生成してメッセージキュー１に格納する（ステップＳ２４）。そして、“Ｘ”の値を＋１インクリメントする（ステップＳ２５）。
【００９３】
上記“売注文に対する約定通知”に係わる処理によって、上記具体例であれば、メッセージキュー１には9Byteのデータが格納され、メッセージ連携テーブル２には約1,500Byteのデータが格納されることになる。
【００９４】
その後、上記“売注文に対する約定通知”を注文入力元（外部システム）へ送信する（ステップＳ２６）。
【００９５】
上記のように売買成立した売注文に関して上記ステップＳ２３〜Ｓ２６の処理を実行したら、続いて、売買成立した買注文に関して以下のステップＳ２７〜Ｓ３０の処理を実行する。
【００９６】
すなわち、まず、買注文に対する約定通知を生成して、この約定通知（実データ）を現在のキーNo.“Ｘ”と共にメッセージ連携テーブル２に格納する（ステップＳ２７）。更に、この約定通知（実データ）に対応する“種別通知情報”３（そのキーNo.７１が現在のキーNo.“Ｘ”、その電文種別７２が「約定通知」）を生成してメッセージキュー１に格納する（ステップＳ２８）。そして、“Ｘ”の値を＋１インクリメントする（ステップＳ２９）。
【００９７】
上記“買注文に対する約定通知”に係わる処理によって、上記具体例であれば、メッセージキュー１には9Byteのデータが格納され、メッセージ連携テーブル２には約1,500Byteのデータが格納されることになる。
【００９８】
一方、従来では、メッセージキューに約1,500Byteのデータが格納されることになる。
その後、上記“買注文に対する約定通知”を注文入力元（外部システム）へ送信する（ステップＳ３０）。
【００９９】
そして、停止指示が無いならば（ステップＳ３１，ＮＯ）ステップＳ１１に戻る。
図６は、注文監視プログラム２２の処理フローチャートである。
【０１００】
図示の例では、注文監視プログラム２２は、随時、メッセージキュー待ち受け状態であり（ステップＳ４１）、メッセージキュー１に何等かのデータが格納されると起動されてステップＳ４２以降の処理を実行する。
【０１０１】
すなわち、まず、メッセージキュー１の格納データ（任意の“種別通知情報”３）を１つ取得する（ステップＳ４２）。そして、この“種別通知情報”３の電文種別７２より、買注文／売注文であるか否かを判定する（ステップＳ４３）。そして、買注文でも売注文でもない場合（約定通知などである場合）（ステップＳ４３，ＮＯ）、そのまま（取得データを破棄する等して）ステップＳ４１に戻る。但し、停止指示があった場合には（ステップＳ４７，ＹＥＳ）注文監視プログラム２２の実行を停止する。尚、停止指示は、図１の運用管理サーバ３０のジョブ管理ミドルウェア３１から出される。
【０１０２】
一方、買注文または売注文である場合には（ステップＳ４３，ＹＥＳ）、上記取得した“種別通知情報”３のキーNo.７１を取得して（ステップＳ４４）、このキーNo.７１を用いてメッセージ連携テーブル２を検索して該当する実データを取得する（ステップＳ４５）。対応付けられたキーNo.６１がキーNo.７１と一致する実データ（電文種別６２〜時刻６８など）が、該当する実データである。そして、ステップＳ４５で取得した実データを編集する等して画面出力する（ステップＳ４６）。
そして、停止指示がないならば（ステップＳ４７，ＮＯ）ステップＳ４１に戻る。
【０１０３】
上記のように、注文監視プログラム２２は、まず、メッセージキュー１から“種別通知情報”３を取得する。“種別通知情報”３は、例えば9Byteのデータであり、従ってデータ取得処理負荷は、実データを取得する場合に比べて、格段に軽減される。つまり、データ取得するのに時間は掛からない。そして、その電文種別が買注文でも売注文でもない場合には、自己には関係ないものとして、実データは取得することなく、ステップＳ４１に戻る。この様にして、データ量が比較的大きい実データを、自己には関係ないにも係わらず読み出すことを（無駄で且つ時間が掛かる処理の実行を）、避けることができる。
【０１０４】
図７は、約定監視プログラム２３の処理フローチャートである。
図示の例では、約定監視プログラム２３は、随時、メッセージキュー待ち受け状態であり（ステップＳ５１）、メッセージキュー１に何等かのデータが格納されると起動されてステップＳ５２以降の処理を実行する。
【０１０５】
すなわち、まず、メッセージキュー１の格納データ（任意の“種別通知情報”３）を１つ取得する（ステップＳ５２）。そして、この“種別通知情報”３の電文種別７２より、約定通知であるか否かを判定する（ステップＳ５３）。そして、約定通知ではない場合（ステップＳ５３，ＮＯ）、そのまま（取得データを破棄する等して）ステップＳ５１に戻る。但し、停止指示があった場合には（ステップＳ５７，ＹＥＳ）約定監視プログラム２３の実行を停止する。尚、停止指示は、図１の運用管理サーバ３０のジョブ管理ミドルウェア３１から出される。
【０１０６】
一方、約定通知である場合には（ステップＳ５３，ＹＥＳ）、上記取得した“種別通知情報”３のキーNo.７１を取得して（ステップＳ５４）、このキーNo.７１を用いてメッセージ連携テーブル２を検索して該当する実データを取得する（ステップＳ５５）。対応付けられたキーNo.６１がキーNo.７１と一致する実データ（電文種別６２〜時刻６８など）が、該当する実データである。そして、ステップＳ５５で取得したデータを編集する等して画面出力する（ステップＳ５６）。
そして、停止指示がないならば（ステップＳ５７，ＮＯ）ステップＳ５１に戻る。
【０１０７】
上記のように、約定監視プログラム２３は、まず、メッセージキュー１から“種別通知情報”３を取得する。“種別通知情報”３は、例えば9Byteのデータであり、従って取得するのに時間は掛からない。そして、その電文種別が約定通知ではない場合には、自己には関係ないものとして、その実データは取得することなく、ステップＳ５１に戻る。この様にして、データ量が比較的大きい実データを、自己には関係ないにも係わらず読み出すことを（無駄で且つ時間が掛かる処理の実行を）、避けることができる。
【０１０８】
図８は、集計情報監視プログラム２４の処理フローチャートである。
図示の例では、集計情報監視プログラム２４は、随時、メッセージキュー待ち受け状態であり（ステップＳ６１）、メッセージキュー１に何等かのデータが格納されるとステップＳ６２以降の処理を実行する。
【０１０９】
すなわち、まず、メッセージキュー１の格納データ（任意の“種別通知情報”３）を１つ取得する（ステップＳ６２）。そして、この“種別通知情報”３のキーNo.７１を取得して（ステップＳ６３）、このキーNo.７１を用いてメッセージ連携テーブル２を検索して該当する実データを取得する（ステップＳ６４）。対応付けられたキーNo.６１がキーNo.７１と一致する実データ（電文種別６２〜時刻６８など）が、該当する実データである。そして、ステップＳ６４で取得したデータを編集する等して画面出力する（ステップＳ６５）。
そして、停止指示がないならば（ステップＳ６６，ＮＯ）ステップＳ６１に戻る。
【０１１０】
一方、停止指示があれば（ステップＳ６６，ＹＥＳ）集計情報監視プログラム２４の実行を停止する。尚、停止指示は、図１の運用管理サーバ３０のジョブ管理ミドルウェア３１から出される。
【０１１１】
図９（ａ）〜（ｃ）に、上記各監視プログラムによる画面出力例を示す。
図９（ａ）には、注文監視プログラム２２によって生成されて監視画面２１上に表示される注文データ監視画面の一例を示す。
【０１１２】
図９（ｂ）には、約定監視プログラム２３によって生成されて監視画面２１上に表示される約定データ監視画面の一例を示す。
【０１１３】
図９（ｃ）には、集計情報監視プログラム２４によって生成されて監視画面２１上に表示される集計データ監視画面の一例を示す。
【０１１４】
図１０は、本例の売買システムの機能ブロック図である。
本例の売買システムは、何等かの対象の売買を実行・監視するシステムであり、その一例が上記株式売買システムであるが（つまり、この例では、何等かの対象＝株式）、この例に限らない。
【０１１５】
図示の例の売買システム８０は、１以上の監視部８４が動作するシステムである。
そして、図示の売買システム８０は、売買に係わる任意の実情報が得られると、該実情報を第２記憶部８３に記憶すると共に、該実情報に係わる所定の判定情報を第１記憶部８２に記憶する売買実行部８１を有する。
【０１１６】
そして、各監視部８４は、それぞれ、データ取得部８５を有する。データ取得部８５は、第１記憶部８２から上記判定情報を取得して、該判定情報に基づいて、この判定情報が係わる実情報が自己の処理対象であるか否かを判定する。そして、データ取得部８５は、自己の処理対象であると判定した場合には第２記憶部８３から該当する実情報を取得する。
【０１１７】
尚、上記判定情報の一例が上記種別通知情報３のデータ種別３ｂであるが、この例に限らない。また、上記第１記憶部８２の一例が上記メッセージキュー１であるが、この例に限らない。また、上記第２記憶部８３の一例が上記メッセージ連携テーブル２であるが、この例に限らない。また、上記売買実行部８１の一例が上記売買プログラム１１であるが、この例に限らない。また、上記各監視部８４の一例が上記注文監視プログラム２２、約定監視プログラム２３、集計情報監視プログラム２４であるが、この例に限らない。
【０１１８】
そして、例えば、各監視部８４は、第１記憶部８２から取得した判定情報に基づいて自己の処理対象ではないと判定した場合には、第２記憶部８３からの実情報の取得は行わない。自己に必要のない実情報を無駄に取得する処理を行わなくて済む。
【０１１９】
また、例えば、売買実行部８１は、上記売買に係わる任意の実情報が得られると、一意のキー情報を生成して、上記実情報は該キー情報と共に第２記憶部８３に記憶し、上記判定情報は該キー情報と共に第１記憶部８２に記憶する。そして、各監視部８４は、自己の処理対象であると判定した場合には、例えば、上記キー情報に基づいて上記該当する実情報を判別する。
【０１２０】
また、例えば、上記判定情報は、実情報に比べて格段にデータ量が少ない。これより、各監視部８４は、自己に必要のない実情報を無駄に取得する場合があっても、売買実行部８１とのデータ連携に係わる影響（遅延など）は、最小限に抑えられる。
【０１２１】
また、例えば、上記判定情報は、実情報のデータ種別である。
データ種別は、例えば、買注文、売注文、約定通知の何れかであり、この例の場合、上記実情報は、買注文の実データ、売注文の実データ、約定通知の実データの何れかであることになる。
【０１２２】
また、例えば、各監視部８４は、自己の処理対象が買注文／売注文である第１の監視部、または／及び、自己の処理対象が約定通知である第２の監視部等である。
【０１２３】
また、例えば、売買システム８０は、上記１以上の監視部が動作する監視サーバと、上記売買実行部を有する売買サーバとを有する構成であってもよく、その一例が上記図２の構成であるが、この例に限らない。
【０１２４】
また、例えば、各監視部８４は、各々のデータ取得部８５によって取得した実情報に基づいて監視画面を生成・表示して、売買実行部８１による売買実行状況をリアルタイムで監視させるものである。
【０１２５】
尚、売買サーバ１０、監視サーバ２０は、それぞれ、一般的なサーバ装置のハードウェア構成を有するものであって良い。すなわち、売買サーバ１０、監視サーバ２０は、それぞれ、不図示のＣＰＵ等の演算プロセッサ、ハードディスク等の記憶装置等を有している。そして、例えば、上記演算プロセッサが、上記記憶装置に予め記憶されている所定のアプリケーションプログラムを実行することで、例えば上記図４〜図８の処理や、図１０に示す各種処理機能等が、実現されることになる。
【０１２６】
・以上説明した本例の売買システムでは、メッセージキューに格納するデータの内容を、各監視プログラムに実データの取得処理を実行するか否かを判定させる為の判定情報（一例が上記データ種別）と、メッセージ連携テーブルから該当する実データを取得するためのキー情報に限定する。尚、各監視プログラムは、実データを取得する場合には既存の所定の監視画面生成処理を行うことになる。
【０１２７】
この様にメッセージキューに格納するデータの内容を最小限にすることで、監視プログラムがメッセージキューから処理対象でないデータを取得する際にも発生してしまう“メッセージデータの取得にかかる時間”を、非常に小さくすることができる。更に、各監視プログラムは、メッセージキューからの取得データより、自己に必要ない実データの読出し処理は、行わないようにでき、以って監視プログラムの処理負荷を軽減できる。
【０１２８】
このように、本例の売買システムでは、売買プログラムと各監視プログラムとでデータ連携を行う売買システムにおいて、監視プログラムに無用な実データ読出し処理を回避させ、以って監視プログラム側のデータ連携に係わる遅延を改善することができる。
【０１２９】
例えば、買注文の全情報は2,000Byte程度であるが、種別通知情報３は9Byte程度で済む。監視プログラムの処理対象データに係わる場合、従来技術によってメッセージキューから実データを取得する時間と、本手法によってメッセージキューから種別通知情報３を取得後に、メッセージ連携テーブルから実データを取得する時間とで、殆ど差はない。一方で、監視プログラムの処理対象ではないデータに係わる場合、従来技術ではメッセージキューから実データ（2,000Byte程度）を取得するのに対して、本手法ではメッセージキューから種別通知情報３を取得するだけで処理を終了するため、“メッセージキューからのデータ取得時間”が100分の1程度に短縮することが可能となる。
【０１３０】
特に、売買サーバ１０と監視サーバ２０とで性能差があり、売買サーバ１１０の方が処理が速い場合には、上述したように従来では、監視プログラムの処理が追いつかず、特に短時間に取引が集中する場合、注文状況や売買の成立状況のリアルタイムでの監視に弊害が出てしまう問題があった。本手法では、この様な問題を解決できる。つまり、本手法によれば、売買プログラムと各監視プログラムとでデータ連携を行う売買システムにおいて、監視プログラム側のデータ連携に係わる遅延を短縮（改善）することができる。
【０１３１】
・また、本システムは、既存のシステムに基づいて構築する場合、既存のシステムのメッセージキューに係わる仕組みを、そのまま利用できる。すなわち、本システムにおいても、売買プログラムがメッセージキューにデータを格納すると、各監視プログラムがメッセージキューの格納データを取得する仕組みは、従来と同じであってよい。違いは、メッセージキューに格納するデータの容量が、従来に比べて格段に少ない点と、監視プログラムが場合によっては更にメッセージ連携テーブルにアクセスする点である。
【０１３２】
尚、本説明において、“／”は、基本的には、“または”や“あるいは”を意味するものとする。よって、例えば「または／及び」は、「または、あるいは、及び」を意味することになる。
【符号の説明】
【０１３３】
１  メッセージキュー
２  メッセージ連携テーブル
２ａ  キー情報
２ｂ  実データ
３  種別通知情報
３ａ  キー情報
３ｂ  データ種別
１０  売買サーバ
１１  売買プログラム
１２  メッセージキュー
１３  メッセージ連携テーブル
２０  監視サーバ
２１  監視画面
２２  注文監視プログラム
２３  約定監視プログラム
２４  集計情報監視プログラム
２５  メッセージキュー
２６  メッセージ連携テーブル
３０  運用管理サーバ
３１  ジョブ管理ミドルウェア
４０  電文
４１  電文コード
４２  銘柄
４３  参加者
４４  売買区分
４５  値段
４６  数量
４７  時刻
５０  電文
５１  電文コード
５２  銘柄
５３  参加者
５４  売買区分
５５  値段
５６  数量
５７  時刻
６１  キーNo.
６２  電文種別
６３  銘柄
６４  参加者
６５  売買区分
６６  値段
６７  数量
６８  時刻
７１  キーNo.
７２  電文種別
８０  売買システム
８１  売買実行部
８２  第１記憶部
８３  第２記憶部
８４  監視部
８５  データ取得部
１００  運用管理サーバ
１０１  ジョブ管理ミドルウェア
１１０  売買サーバ
１１１  売買プログラム
１１２  メッセージキュー
１２０  監視サーバ
１２１  監視画面
１２２  注文監視プログラム
１２３  約定監視プログラム
１２４  集計情報監視プログラム
１２５  メッセージキュー
１３０  メッセージキュー
１３１  買注文データ
１３２  売注文データ
１３３  約定通知データ
【図１】
2018139038.tif 000003
【図２】
2018139038.tif 000004
【図３】
2018139038.tif 000005
【図４】
2018139038.tif 000006
【図５】
2018139038.tif 000007
【図６】
2018139038.tif 000008
【図７】
2018139038.tif 000009
【図８】
2018139038.tif 000010
【図９】
2018139038.tif 000011
【図１０】
2018139038.tif 000012
【図１１】
2018139038.tif 000013
【図１２】
2018139038.tif 000014