(57)【特許請求の範囲】
【請求項１】
それぞれの受信完了に要する時間が異なる複数種別のメッセージについて、当該メッセージの処理順序を制御するメッセージ順序制御装置において、
前記メッセージを受信する手段と、
前記メッセージを受信する場合、当該メッセージの受信について前記受信に要する時間の変動が固定的な受信状況を示す情報を記録する手段と、
前記受信状況を示す情報に応じて、前記メッセージの処理順序を制御する手段とを有し、
前記メッセージは、商品の取引に関するメッセージであって、
前記処理順序を制御する手段は、前記メッセージに含まれ、他のメッセージとの処理順序の関係を考慮すべきものであることを示し、当該メッセージ種類を示すキー情報を特定し、特定された前記キー情報を用いて、当該メッセージを前記商品の売買のいずれかを要求する売買メッセージ、前記商品の売買状況の確認を要求する参照メッセージおよび前記メッセージの送信状況の確認を含む事務メッセージのいずれの種類であるかを特定し、
特定された種類が売買メッセージないし参照メッセージの場合、複数の売買メッセージないし参照メッセージのうち、前記受信状況が最も早く受信したことを示すメッセージから順に前記処理を実行するよう制御し、
特定された種類が事務メッセージの場合、複数の事務メッセージのうち、当該メッセージの受信完了が最も早いメッセージから順に前記処理を実行するように制御することを特徴とするメッセージ順序制御装置。
【請求項２】
請求項１に記載のメッセージ順序制御装置において、
前記受信状況は、前記メッセージの先頭ブロックの受信であることを特徴とするメッセージ順序制御装置。
【請求項３】
請求項１または２のいずれかに記載のメッセージ順序制御装置において、
前記受信状況を示す情報は、前記受信状況におけるタイムスタンプないし当該受信状況の順序に従って付与される当該メッセージを識別するメッセージＩＤのいずれか一方であることを特徴とするメッセージ順序制御装置。
【請求項４】
請求項１に記載のメッセージ順序制御装置であって、
さらに、
前記受信状況に応じて、当該受信状況の時間的な順序に従ったメッセージＩＤを算出する手段と、
前記キー情報を記憶するメッセージテーブルと、
前記メッセージの受信状況において、前記メッセージＩＤを前記受信状況の示す時間的な順序に並べて記憶する種類未確定テーブルと、
前記メッセージの受信に従ってキー情報を受信した場合、当該キー情報によりメッセージの種類を判別して、前記メッセージテーブルに判別されたメッセージの種類を前記メッセージＩＤに対応付けて記録する手段と、
前記メッセージが参照メッセージと判別された場合に、当該メッセージＩＤを前記受信状況の時間的な順序に並べて記憶する参照メッセージテーブルと、
前記メッセージが売買メッセージと判別された場合に、当該メッセージＩＤを前記受信状況の時間的な順序に並べて記憶する銘柄未確定テーブルと、
前記メッセージに前記商品の銘柄を示す銘柄情報を示すブロックであった場合に、銘柄毎にメッセージＩＤを前記受信状況の時間的な順序に並べて記憶する銘柄別テーブルと、
前記処理順序を制御する手段は、
前記メッセージを受信完了した場合、
前記受信完了したメッセージが売買メッセージの場合は、当該メッセージのメッセージＩＤと、当該メッセージの銘柄の前記銘柄別テーブルの先頭のメッセージのメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示し、前記受信完了したメッセージのメッセージＩＤと前記銘柄未確定テーブルの先頭のメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示し、前記受信完了したメッセージのメッセージＩＤと前記種類未確定テーブルの先頭のメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示す場合に前記受信完了したメッセージを処理し、
前記受信完了メッセージが参照メッセージの場合は、当該メッセージのメッセージＩＤと、前記参照メッセージテーブルの先頭のメッセージのメッセージＩＤを比較した結果、
前記受信完了したメッセージＩＤが時間的に古いことを示し、前記受信完了したメッセージＩＤと前記種類未確定テーブルの先頭のメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示す場合に、前記受信完了したメッセージを処理し、
前記受信完了メッセージが事務手続きメッセージの場合は、当該メッセージを処理することを特徴とするメッセージ順序制御装置。
【請求項５】
それぞれの受信完了に要する時間が異なる複数種別のメッセージについて、当該メッセージの処理順序を制御するメッセージ順序制御装置を用いたメッセージ順序制御方法において、
前記メッセージ順序制御装置は、
前記メッセージを受信するステップと、
前記メッセージを受信する場合、当該メッセージの受信について前記受信に要する時間の変動が固定的な受信状況を示す情報を記録するステップと、
前記受信状況を示す情報に応じて、前記メッセージの処理順序を制御するステップとを有し、
前記メッセージは、商品の取引に関するメッセージであって、
前記処理順序を制御するステップは、
前記メッセージに含まれ、他のメッセージとの処理順序の関係を考慮すべきものであることを示し、当該メッセージ種類を示すキー情報を特定し、特定された前記キー情報を用いて、当該メッセージを前記商品の売買のいずれかを要求する売買メッセージ、前記商品の売買状況の確認を要求する参照メッセージおよび前記メッセージの送信状況の確認を含む事務メッセージのいずれの種類であるかを特定し、
特定された種類が売買メッセージないし参照メッセージの場合、複数の売買メッセージないし参照メッセージのうち、前記受信状況が最も早く受信したことを示すメッセージから順に前記処理を実行するよう制御し、
特定された種類が事務メッセージの場合、複数の事務メッセージのうち、当該メッセージの受信完了が最も早いメッセージから順に前記処理を実行するように制御することを特徴とするメッセージ順序制御方法。
【請求項６】
請求項５に記載のメッセージ順序制御方法において、
前記受信状況は、前記メッセージの先頭ブロックの受信であることを特徴とするメッセージ順序制御方法。
【請求項７】
請求項５または６のいずれかに記載のメッセージ順序制御方法において、
前記受信状況を示す情報は、前記受信状況におけるタイムスタンプないし当該受信状況の順序に従って付与される当該メッセージを識別するメッセージＩＤのいずれか一方であることを特徴とするメッセージ順序制御方法。
【請求項８】
請求項５に記載のメッセージ順序制御方法であって、
さらに、
前記受信状況に応じて、当該受信状況の時間的な順序に従ったメッセージＩＤを算出するステップと、
前記キー情報をメッセージテーブルに記憶するステップと、
前記メッセージの受信状況において、前記メッセージＩＤを前記受信状況の示す時間的な順序に並べて種類未確定テーブルに記憶するステップと、
前記メッセージの受信に従ってキー情報を受信した場合、当該キー情報によりメッセージの種類を判別して、前記メッセージテーブルに判別されたメッセージの種類を前記メッセージＩＤに対応付けて記録するステップと、
前記メッセージが参照メッセージと判別された場合に、当該メッセージＩＤを前記受信状況の時間的な順序に並べて参照メッセージテーブルに記憶するステップと、
前記メッセージが売買メッセージと判別された場合に、当該メッセージＩＤを前記受信状況の時間的な順序に並べて銘柄未確定テーブルに記憶するステップと、
前記メッセージに前記商品の銘柄を示す銘柄情報を示すブロックであった場合に、銘柄毎にメッセージＩＤを前記受信状況の時間的な順序に並べて銘柄別テーブルに記憶するステップとを備え、
前記処理順序を制御するステップは、
前記メッセージを受信完了した場合、
前記受信完了したメッセージが売買メッセージの場合は、当該メッセージのメッセージＩＤと、当該メッセージの銘柄の前記銘柄別テーブルの先頭のメッセージのメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示し、前記受信完了したメッセージのメッセージＩＤと前記銘柄未確定テーブルの先頭のメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示し、前記受信完了したメッセージのメッセージＩＤと前記種類未確定テーブルの先頭のメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示す場合に前記受信完了したメッセージを処理し、
前記受信完了メッセージが参照メッセージの場合は、当該メッセージのメッセージＩＤと、前記参照メッセージテーブルの先頭のメッセージのメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示し、前記受信完了したメッセージＩＤと前記種類未確定テーブルの先頭のメッセージＩＤを比較した結果、前記受信完了したメッセージＩＤが時間的に古いことを示す場合に、前記受信完了したメッセージを処理し、
前記受信完了メッセージが事務手続きメッセージの場合は、当該メッセージを処理することを特徴とするメッセージ順序制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理(特に、受信)に要する時間がそれぞれ異なる複数種別のメッセージが混在して送受信される場合に、これらのメッセージの処理順序を制御するための技術に関する。その中でも特に、取引参加者からの送信メッセージを受信する証券取引所や商品取引所などのメッセージ受信技術に係わり、特に受信したメッセージを業務処理システムへ投入する場合のメッセージ順序制御に関する。なお、メッセージの種別としては、ＸＭＬ、テキストといったそのデータ形式が含まれる。
【背景技術】
【０００２】
証券取引所や商品取引所などは、日々取引に係わるメッセージの業務処理を行なっている。近年の情報処理技術の進歩により、取引におけるメッセージ送受信、業務処理などの処理はコンピュータシステムで実現されている。
【０００３】
取引所などでは多くの取引参加者からの送信メッセージを受信し、受信時点での順序を保ちつつ迅速に処理を行なう必要がある。
【０００４】
このため、特許文献１では、取引所のコンピュータシステムがメッセージの受信処理を完了した時点で受信完了したメッセージにタイムスタンプを付与し、このタイムスタンプに依り、業務処理システムへのメッセージ投入の順序制御を行なっている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２９３８５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１では、メッセージ送信システムから送信されるメッセージを取引所のコンピュータシステムが受信完了した時点でのタイムスタンプに基づき、受信時点での順序を保証していた。
【０００７】
しかし、同じ内容のメッセージでも送受信に要する時間に差がある、異なるデータ形式（異なる種別のデータ）が共存するとき、特許文献１のタイムスタンプの付与タイミングでは、先に取引所のコンピュータシステムで受信開始したメッセージが受信処理において処理時間のかかるデータ形式であるために、後から受信開始した、処理時間がよりかからないデータ形式である別のメッセージが先に業務システムにメッセージ投入されてしまうといった問題がある。
【０００８】
そこで本発明は、先に取引所のメッセージ投入順序制御システムが受信開始したメッセージが、注文受付の送受信に時間の比較的かかるデータ形式、比較的かからないデータ形式に依らず、受信開始時点での公平性（本願明細書での公平性とは、特定の銘柄、もしくは特定のメッセージ種別のメッセージ投入順序制御において、後から取引所のコンピュータシステムが受信開始したメッセージが、先に受信開始したメッセージよりも先に業務システムへメッセージ投入されてしまうことがない状態を指す）を確保することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、本発明ではメッセージに含まれる先頭ブロックの受信などメッセージ受信において受信等に要する時間で変動しない（ないし少ない）固定的な受信状況を示す情報に従った順序で受信後の処理を実行する。この受信状況を示す情報には、タイムスタンプやその順序に応じた（従った）各メッセージに付与するＩＤが含まれる。また、より好適には、メッセージに含まれるキー情報の内容を特定し、その内容に応じて、受信後の処理順序を制御する。
【００１０】
また、本発明ではメッセージの受信を完了した場合、先に受信開始した同じ銘柄や同じメッセージ種別のメッセージ、すなわち、同列に取り扱うメッセージが受信途中であれば、後から受信開始し、かつ先に受信完了したメッセージより当該受信途中のメッセージの投入を時間的に優先させる。
【００１１】
また、先に受信開始したメッセージが受信途中である場合、銘柄やメッセージ種別が不明な場合(同列に取り扱うメッセージか不明)においても、先に受信開始したメッセージが同じ銘柄、同じメッセージ種別となる可能性があるため、後から受信開始し、先に受信完了したメッセージより当該受信途中のメッセージを時間的に優先させる。
【００１２】
さらに、先に受信開始したメッセージが受信途中であっても、後から受信開始、先に受信完了し待機状態のメッセージと、先に受信開始し受信途中のメッセージが業務処理システムへのメッセージ投入において順序を考慮する必要のない、他の銘柄や他のメッセージ種別であると判断した場合（先に受信開始したメッセージの銘柄やメッセージ種別を示すキー情報受信した際）、後から受信開始、受信完了し待機状態のメッセージを優先して業務処理システムへメッセージ投入する。
【発明の効果】
【００１３】
本発明によれば、メッセージの種別により生じる処理（受信ないし業務処理など他のシステムへの処理要求である投入）の不公正を抑止することが可能になる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態におけるメッセージ投入順序制御システムを含む取引所システムやこれと接続されるメッセージ送信システムの概略構成図である。
【図２】本発明の一実施形態におけるメッセージ投入順序制御システムのハードウェアの構成図である。
【図３】本発明の一実施形態で用いられる各メッセージ種別の項目を示す図である。
【図４】本発明の一実施形態で用いられるメッセージテーブルの例を示す図である。
【図５】本発明の一実施形態で用いられるメッセージ種別未確定テーブルの例を示す図である。
【図６】本発明の一実施形態で用いられる銘柄未確定テーブルの例を示す図である。
【図７】本発明の一実施形態で用いられる銘柄別テーブルの例を示す図である。
【図８】本発明の一実施形態で用いられる参照メッセージテーブルの例を示す図である。
【図９】本発明の一実施形態のメッセージ順序制御の処理フロー図である。
【図１０】本発明の一実施形態の自テーブル中のメッセージ投入制御の処理フロー図である。
【図１１】参照メッセージテーブルの処理フロー図である。
【図１２】売り（買い）メッセージ投入制御の処理フロー図である。
【図１３】他銘柄メッセージ投入制御の処理フロー図である。
【図１４】他テーブル中のメッセージ投入制御の処理フロー図である。
【図１５】図５におけるメッセージ種別未確定テーブルの具体例を示す図である。
【図１６】図４におけるメッセージテーブルの具体例を示す図である。
【図１７】図８における参照メッセージテーブルの具体例を示す図である。
【発明を実施するための形態】
【００１５】
以下、添付の図面を参照しながら、本発明に係る一実施形態について説明する。図１は、メッセージ投入順序制御システムがメッセージを受信し、順序制御を行ない、業務システムへメッセージ投入する仕組み（全体システム）の概略構成図である。
【００１６】
本実施の形態は、メッセージ送信システム0101がネットワーク0102を介して取引所システム0103のメッセージ投入順序制御システム0104へメッセージを送信した場合、取引所0103のメッセージ投入順序制御システム0104がメッセージを受信し、順序制御を行なった後、メッセージの約定処理等を行なう業務処理システム0108へメッセージを投入する仕組みである。メッセージ投入順序制御システム0104は、メッセージの受信、業務処理システム0108への投入順序制御を行なうメッセージ順序制御機能0105と、受信したメッセージの内容を記憶するメッセージ情報記憶部0107と、メッセージ順序制御機能0105が受信したメッセージを順序制御する場合に参照する、補助テーブル記憶部0106から成る。補助テーブル記憶部0106の詳細については後述する。なお、メッセージ送信システム0101は、いわゆるコンピュータで実現されるものであって、本実施の形態で対象としている株式の売買希望者ないしその仲介者（証券会社等）が、その売買やその確認などを行うために用いられるものである。
【００１７】
前記メッセージ投入順序制御システム0104は、外部からの指示に応じてソフトウェアを実行可能な通常のコンピュータシステムにより実現することができる。具体的なハードウエア構成を図２に示す。図２に示すこの情報処理装置、ずなわち、メッセージ投入順序制御システム0104は、各種ソフトウェア及びデータが格納されたハードディスク0203、メモリ0202、ハードディスク0203からメモリ0202上にロードされたソフトウェアを実行するプロセッサ（CPU等）0201、ネットワーク0102を介した通信を制御する通信制御装置（ネットワークカード等）0205、ユーザからの入力を受け付ける入力装置（マウス、キーボード等）0206及びユーザへの提示情報を出力する出力装置（ディスプレイやプリンタ等）0207の外部機器が接続される入出力インタフェース0208、これらを相互に接続するバス0209、等のハードウェアを有している。前記メッセージ投入順序制御システム0104は、このようなハードウェア構成とハードディスク上のソフトウェア及びデータとにより、所要の機能構成を実現する。
【００１８】
メッセージ投入順序制御システム0104が受信するメッセージには、例えば次の3種類があるものとする。１つ目は売り（買い）メッセージ(売買メッセージ)であり、メッセージ中に銘柄情報を含んでいる。同じ銘柄の売り（買い）メッセージ同士については受信開始時点での順序で業務処理システム0108へメッセージ投入する。また異なる銘柄や異なるメッセージ種別のメッセージ同士については、業務処理システム0108へメッセージ投入する順序は任意であるとする。この売り（買い）メッセージとは例えば株等の金融商品の売り（買い）注文のような銘柄を指定したメッセージをいい、そのようなメッセージの場合、同じ銘柄の注文はメッセージの処理（受信や他のシステムへの処理要求である投入を含む）順序を維持する必要がある。これは、金融商品の売買（売り（買い））は、希望者の希望した順序性を確保する必要があるため、上述の性格を有する。、
2つ目は売買状況の問い合わせなどを行なう参照メッセージである。参照メッセージは、同じメッセージ種別（参照）のメッセージ同士では受信開始時点など所定の条件での順序で業務処理システム0108へメッセージ投入する。参照メッセージについても、異なるメッセージ種別のメッセージ同士については、任意の順序で業務処理システム0108へメッセージ投入する。この参照メッセージとは例えば、売買状況を問い合わせるようなメッセージで、当該参照メッセージ間でその投入(処理、受信)順序を維持する必要がある。これは、売買状況が問合せ者の問合せ時期に即した順序で回答など処理をする必要があるため、このような性格を有する。
【００１９】
3つ目は、送受信履歴の問い合わせなどを行なう事務手続きに関するメッセージである。事務手続きメッセージについては、受信完了した時点で業務処理システム0108へメッセージ投入可能である。この事務手続きメッセージとは例えば送受信履歴の問い合わせ等、他のメッセージの投入の順序性を気にすることなく業務システムへメッセージ投入可能なメッセージをいう。これは、送受信の結果を問い合わせするものであるため、その回答順序は特に問わないためである。
【００２０】
前記3種類のメッセージの詳細（より具体的な内容）について、メッセージ順序制御機能0105のメッセージの受信方法の説明と併せて、以下で述べる。
【００２１】
本実施の形態では、メッセージ順序制御機能0105が一つのメッセージにつき、ブロック単位でメッセージを受信することを想定している。以下、売り（買い）メッセージ、参照メッセージ、事務手続きメッセージがどのようなブロックから構成されているかを述べる。なおデータ形式はXMLであることを想定して以下説明するが、他のデータ形式であってもよい。
【００２２】
まず図３（a）を用いて、売り（買い）メッセージについて述べる。売り（買い）メッセージの先頭ブロック0301には、XMLであればメッセージの先頭ブロックに必ず現れる、<？ｘｍｌ  …>タグが含まれている。2つ目のブロック0302には売り（買い）情報であることを示す情報（例えば売り情報であれば<sell>タグ。買い情報であれば<buy>タグ）が含まれている。3つ目のブロック0303には売り（買い）処理を行なう銘柄の情報（例えば<meigara>タグの要素の内容）が含まれている。4つ目のブロック0304には売り（買い）処理の本体情報0304（金額、氏名情報など）が含まれている。5つ目のブロック0305には受信メッセージが終了であることを示す情報（例えばルート要素の閉じタグ</root>）が含まれている。
【００２３】
なお、メッセージ順序制御機能0105は、各ブロックに含まれている前記キー情報（<sell>タグ、閉じタグ</root>など）を予め保持する、例えばデータベース等を参照し、3種類のメッセージ種別のうちどのメッセージ種別に属するかを判断可能であり、また先頭ブロック（0301、0306、0310）、終了ブロック（0305、0309、0313）など、どのブロックであるかを判断可能であるとする。
【００２４】
次に、図３（b）を用いて参照メッセージについて述べる。参照メッセージのメッセージ先頭ブロック0306には売り（買い）メッセージと同様、例えば<?xml 〜>タグが含まれている。2つ目のブロック0307には受信中のメッセージが参照メッセージであることを示す情報（例えば<reference>タグ）が含まれている。3つ目のブロック0308には参照メッセージの本体情報（参照処理における条件文）が記述されている。4つ目のブロック0309には受信メッセージが終了であることを示す情報、例えばルート要素の閉じタグ</root>が含まれている。
【００２５】
最後に、図３（c）を用いて事務手続きメッセージについて述べる。事務手続きメッセージのブロックの構成は参照メッセージと同様であり、メッセージ先頭ブロック0310には例えば<？ｘｍｌ  …>タグが含まれている。2つ目のブロック0311には受信中のメッセージが事務手続きメッセージであることを示す情報（例えば<jimusyori>タグ）が含まれている。3つ目のブロック0312には事務手続きメッセージの本体情報（例えば履歴問い合わせにおける時刻情報、問い合わせ対象名などの条件文）が記述されている。4つ目のブロック0313には受信メッセージが終了であることを示す情報、例えばXMLであればメッセージの終了ブロックに現れるルート要素の閉じタグ</root>が含まれているものとする。  次に、本実施の形態におけるメッセージ投入順序制御システム０１０４の各構成要件について述べる。まず、メッセージ情報記憶部0107について述べる。メッセージ情報記憶部0107は、メッセージ順序制御機能0105が受信したメッセージの内容（以降、メッセージ情報と呼ぶ）を記憶する。メッセージ順序制御機能0105がメッセージを業務処理システム0108へ送る場合にはメッセージ情報記憶部0107が記憶しているメッセージ情報を業務処理システム0108へ送り、メッセージ情報記憶部0107から送信したメッセージに関するメッセージ情報を削除する。
【００２６】
次に、補助テーブル記憶部0106の詳細について述べる。補助テーブル記憶部0106は、メッセージの順序制御で用いられる、メッセージテーブル0401、メッセージ種別未確定テーブル0501、銘柄未確定テーブル0601、銘柄別テーブル0701、参照メッセージテーブル0801の5つのテーブルから成る。以下、これら各テーブルについて、それぞれ説明する。
【００２７】
まず始めに、図４を用いてメッセージテーブル0401について説明する。メッセージテーブル0401は、メッセージ順序制御機能0105がメッセージの先頭ブロック（0301、0306、0310）を受信開始した時点での時刻を記憶するタイムスタンプの項目0402、受信中のブロックがどのメッセージのブロックであるかを一意に定めるメッセージのID情報の項目0403（以下、メッセージIDと表記する場合もある）、メッセージ種別が事務手続き、売り（買い）、参照のいずれであるかを記憶するメッセージ種別の項目0404、メッセージ種別が売り（買い）メッセージであるとき、受信中のメッセージがどの銘柄情報を含んでいるかを記憶する銘柄情報の項目0405、メッセージが受信中であるか、受信完了し、待機状態にあるかどうかを記憶する受信状態の項目0406から成る。メッセージIDについては、メッセージ投入順序制御システムが日毎に管理する通番番号でもよいし、メッセージ投入順序制御システムが使用しなくなったID情報を使いまわしてもよい。
【００２８】
受信状態0406の項目については、メッセージ受信中である場合を“未完了”、受信完了し、他のメッセージの受信完了を待っている場合を”待機”と記憶する（“待機”と記憶する場合の具体的な事例については後述する）。上記メッセージテーブル0401の各項目について、初期状態ではそれぞれ空欄であるものとする。またメッセージテーブル0401は、メッセージ順序制御機能0105が受信する一つのメッセージにつき一つの行データ0407を割り当てる。
【００２９】
次に、メッセージテーブル0401の処理方法（追加、検索、削除）について述べる。まず、メッセージテーブル0401への追加とは、メッセージ順序制御機能0105が最上段の行から下へ順に行データ0407を読み込み、タイムスタンプの項目0402が空欄である場合、タイムスタンプ0402、ID情報0403、受信状態0406（“未完了”）をメッセージテーブル0401に書き込む処理を指す。もしくは最後段の行データの次に新たにタイムスタンプ0402、ID情報0403、受信状態0406（“未完了”）をメッセージテーブル0401に書き込む。
【００３０】
続いて、メッセージテーブル0401での検索について述べる。まず、予め、メッセージ順序制御機能0105は検索すべきメッセージのID情報を一時的にメモリに保持しているものとする。メッセージテーブル0401の検索とは、メッセージ順序制御機能0105がメッセージテーブル0401の行データ0407を最上段から下へ順に読み込み、読み込んだ行データ0407中のID情報と検索すべきメッセージのID情報が一致する行データ0407を読み込む処理を指す。なお、ここでは読み込みの順序を規定したが、この順序は他の順序であっても構わない。
【００３１】
最後にメッセージテーブル0401での削除とは、上記メッセージテーブル0401での検索の後、読み込んだ行データ0407のメッセージ個別情報（タイムスタンプ0402、ID情報0403、メッセージ種別0404、銘柄情報0405、受信状態0406）の各項目を空欄とする処理を指す。
【００３２】
次に、図５を用いてメッセージ種別未確定テーブル0501について述べる。メッセージ種別未確定テーブル0501はメッセージ順序制御機能0105で受信中のメッセージについて、メッセージ種別が事務手続きであるか売り（買い）であるか参照であるかその時点までに受信したブロックでは判別できない、メッセージのID情報をタイムスタンプ順で古いものを先頭にし、以下古い順にリストで記憶する。前記リストの各要素を以下IDノードと呼ぶ。前記リストにおいて、メッセージのID情報を有するIDノードがない場合、つまり記憶される情報がない場合、リストの先頭ノードには終端ノードがあるものとする。
また、IDノードは、IDノードと、IDノードが有するID情報と同じ値のID情報を有するメッセージテーブル0401中の行データ0407とを結ぶポインタを有していてもよい。このとき、メッセージ種別未確定テーブル0501のIDノードと、IDノードが有するID情報と同じ値のID情報を有するメッセージテーブル0401中の行データ0407は互いに対応するデータを参照可能であり、メッセージ種別未確定テーブル0501のIDノードと、IDノードが有するID情報と同じ値のID情報を有するメッセージテーブル0401中の行データ0407は「紐付いている」と呼ぶ。
【００３３】
次に、メッセージ種別未確定テーブル0501の処理方法（追加、検索、削除）について述べる。まず、メッセージ種別未確定テーブル0501への追加とは、メッセージ順序制御機能0105がメッセージ種別未確定テーブル0501にアクセスし、リストの先頭ノードから順に辿りつつ、終端ノードが現れたとき、終端ノードの直前（1つ前の）のIDノードと終端ノード間の双方向のポインタを削除し、終端ノードの直前のIDノードと追加したいIDノードを双方向のポインタでつなぎ、追加したいIDノードと終端ノードを双方向のポインタでつなぐ処理を指す。もしくは、メッセージ種別未確定テーブル0501において終端ノードが先頭であった場合、追加したいIDノードを新たに先頭ノードとし、追加したいIDノードと終端ノードを双方向のポインタでつなぐ処理を指す。
【００３４】
続いて、メッセージ種別未確定テーブル0501での検索について述べる。ここで、メッセージ順序制御機能0105は予め、検索すべきメッセージのID情報をメモリに保持しているものとする。メッセージ種別未確定テーブル0501の検索とは、メッセージ順序制御機能0105がメッセージ種別未確定テーブル0501のリストの先頭ノードから順に辿りつつ、IDノードに紐付けられたテーブル0401中での、ID情報が一致するIDノードを見つけ出す処理を指す。IDノード自体のID情報を参照して一致するIDノードを見つけてもよい。また、検索の順序は先頭ノードから辿ることに限定されない。逆の順序でも他の条件に従った順序でも構わない。
【００３５】
次に、メッセージ種別未確定テーブル0501での削除とは、上記メッセージ種別未確定テーブル0501での検索の後、メッセージ順序制御機能0105が削除するIDノードの前後のIDノードとの双方向ポインタを削除し、削除するIDノードの前後のIDノード同士を双方向のポインタでつなぐ処理を指す。
【００３６】
次に、図６により銘柄未確定テーブル0601について述べる。銘柄未確定テーブル0601は、メッセージ種別が売り（買い）であると判定できたメッセージのうち、銘柄が未確定であるメッセージを管理するテーブルである。銘柄未確定テーブル0601はメッセージ種別が売り（買い）であると判別できたメッセージに対し、メッセージのID情報をタイムスタンプ順で古いものを先頭にし、以下古い順にリストで記憶する。なお、この記憶される順序は、新しいものから順にして記憶されるようにしてもよい。
【００３７】
メッセージ種別未確定テーブル0501と同様、前記リストにおいて、メッセージのID情報を有するIDノードがない場合、リストの先頭ノードには終端ノードがあるものとする。また、IDノードは実装の工夫により、IDノードと、IDノードが有するID情報と同じ値のID情報を有するメッセージテーブル0401中の行データ0407とを結ぶポインタを有していてもよい。銘柄未確定テーブル0601での処理方法（検索、追加、削除）はメッセージ種別未確定テーブル0501での処理方法と同様である。
【００３８】
次に、図７を用いて銘柄別テーブル0701について述べる。銘柄別テーブル0701はメッセージ種別が売り（買い）であり、さらに銘柄情報が判定できたメッセージのうち、受信途中であるメッセージを管理するテーブルである。銘柄別テーブル0701は銘柄別に行データ0704を有し、各行データは銘柄0702の項目、メッセージのID情報のリスト0703の項目から成る。銘柄別テーブル0701はメッセージ種別が売り（買い）であり、かつ銘柄情報が判別できたメッセージに対し、メッセージのID情報をタイムスタンプ順で古いものを先頭にし、以下古い順にリストで記憶する。ここでの順序も、古い順序でなくとも構わない。メッセージ種別未確定テーブル0501と同様、銘柄別テーブル0701のID情報を用いて、メッセージ順序制御機能0105はメッセージテーブル0401で銘柄未確定テーブル0601と対応するメッセージを検索することも可能である。
【００３９】
次に、図８を用いて参照メッセージテーブル0801について述べる。参照メッセージテーブル0801もメッセージ種別未確定テーブル0501と同様、メッセージ順序制御機能0105で受信中のメッセージを管理するテーブルである。参照メッセージテーブル0801はメッセージ種別が参照であると判別できたメッセージに対し、メッセージのID情報をタイムスタンプ順で古いものを先頭にし、以下古い順にリストで記憶する。ここでの順jも古い順に限定されない。メッセージ種別未確定テーブル0501と同様、前記リストにおいて、メッセージのID情報を有するIDノードがない場合、リストの先頭ノードには終端ノードがあるものとする。また、IDノードは実装の工夫により、IDノードと、IDノードが有するID情報と同じ値のID情報を有するメッセージテーブル0401中の行データ0407とを結ぶポインタを有していてもよい。参照メッセージテーブル0801での処理方法（検索、追加、削除）は、メッセージ種別未確定テーブル0501での処理方法と同様である。
【００４０】
以上を踏まえ、メッセージ順序制御機能0105が、メッセージ種別に依り、受信したメッセージをどのように順序制御するかを以下で述べる。メッセージ順序制御機能0105の処理方法における各フローの説明では、ブロックの先頭ブロック（0301、0306、0310）、メッセージの本体情報部分を含むブロック（0304、0308、0312）、終了ブロック（0305、0309、0313）、メッセージ種別が売り（買い）の場合に銘柄情報を含むブロック0303、メッセージ種別が判断可能な情報を含むブロック（0302、0307、0311）の順で述べる。
【００４１】
まず、図９のメッセージ順序制御機能0105における処理フローについて述べる。メッセージ順序制御機能はメッセージ送信システム0101によって送信された各種メッセージ（売り（買い）メッセージ、参照メッセージ、事務手続きメッセージ）をブロック単位で受信し、図９で示すような処理フローにしたがう。メッセージは、メッセージに始まり部分を示す先頭ブロックから終了部分を示す終了ブロックまで順に受信されていき、終了ブロックまでが受信されなくとも、ブロックが受信された場合に、順次受信処理が実行されていく。
【００４２】
＜先頭ブロックを受信した場合の処理＞
ここではまず、メッセージ順序制御機能0105がメッセージの先頭ブロック（0301、0306、0310）を受信した場合の処理の流れについて述べる。
【００４３】
まず、メッセージ送信システム0101が、売り（買い）メッセージ、参照メッセージ、事務手続きメッセージいずれかのメッセージを送信し、ネットワーク0120を介して、取引所システム0103のメッセージ投入順序制御システム0104中のメッセージ順序制御機能が前記0105メッセージをブロック単位で受信する（ステップ0901）。
【００４４】
そして、メッセージ順序制御機能0105は、受信したブロックが先頭ブロック（0301、0306、0310）であるかどうかの判定を行なう（ステップ0902）。ここでの判定処理とは、メッセージ順序制御機能0105が、受信中のメッセージ内容を、データベース上に記憶している各メッセージ種別の各ブロック中のキー情報と照らし合わせ、一致する項目があればその項目に対応するメッセージ種別名を特定する処理を指す。メッセージのうち、各メッセージ種別が判別可能な情報のブロック（0320,0307,0311）を受信すると、メッセージ種類判別可能である。以降、ブロックの判定処理は上記の処理を指すものとし、処理の詳細については省略するものとする。
【００４５】
メッセージ順序制御機能0105が受信したブロックは先頭ブロック（0301、0306、0310）であるため、メッセージテーブル0401に以下に示す追加（登録）処理を行なう（ステップ0908）。すなわち、タイムスタンプ0420に当該先頭ブロックを受信した時間を、ID0403にメッセージ固有のIDを、受信状態0406はまだ受信が完了していない状態を表す未完了を記憶する。
【００４６】
次に、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501にアクセスし、メッセージの種別が判別できていないメッセージを示すID情報を上書きする（ステップ0909）。
【００４７】
次に、メッセージ順序制御機能0105は受信したブロックの情報をメッセージ情報記憶部0107に対して、メッセージテーブル0401のメッセージ種別0404に判別したメッセージの種類情報を記憶し（ステップ0926）、メッセージの先頭ブロック（0301、0306、0310）を受信した場合の一連の処理を終了しステップ0901に戻る。メッセージの種類が判別できたものについては、メッセージ種別未確定テーブル0501からID情報を削除する削除処理をする。なお、本削除処理については、無効化フラグを記録することで、無効化するように制御してもよい。
【００４８】
＜メッセージの本体情報を含むブロックを受信した場合の処理＞
続いて、メッセージの本体情報を含むブロック（0304、0308、0312）をメッセージ順序制御機能0105が受信したかどうかの判別処理について述べる。メッセージ順序制御機能0105がメッセージの本体情報を含むブロック（0304、0308、0312）を受信（ステップ0901）した場合、受信したブロックがメッセージの先頭ブロック（0301、0306、0310）であるかどうか（ステップ0902）、事務手続きメッセージであることを示す情報を含むかどうか（ステップ0903）、参照メッセージであることを示す情報を含むかどうか（ステップ0904）、売り（買い）メッセージであることを示す情報を含むかどうか（ステップ0905）、また銘柄情報を含むかどうか（ステップ0906）、メッセージの終了ブロック（0305、0309、0313）であるかどうか（ステップ0907）の判定を行なう。判定の結果、いずれのブロックでもない場合、メッセージ順序制御機能0105が受信したブロックはメッセージの本体情報を含むブロック（0304、0308、0312）であり、上記のいずれの判定においてもキー情報を含まないため、メッセージ順序制御機能0105は受信したブロック（0304、0308、0312）の情報をメッセージ情報記憶部0107に記憶し（ステップ0926）、メッセージの本体部分（0304、0308、0312）を受信した場合の一連の処理を終了しステップ0901に戻る。
【００４９】
先にも述べたが、メッセージ種別が売り（買い）の場合に銘柄情報を含むブロック0303、メッセージ種別が判断可能な情報を含むブロックの詳しい処理については後述し、先に終了ブロック（0305、0309、0313）をメッセージ順序制御機能0105が受信した場合の処理について図９により述べる。
【００５０】
＜終了ブロックを受信した場合の処理＞
続いて、メッセージの終了ブロック（0305、0309、0313）をメッセージ順序制御機能0105が受信した際の処理について図９により述べる。ただし、図９による具体的な処理の説明の前にまず、メッセージ順序制御機能0105が各メッセージ種別の終了ブロック（0305、0309、0313）を受信した場合の順序制御の考え方について説明する。
【００５１】
ここではまず、3種類のメッセージ種別のうち、順序制御において最も複雑な処理を行なう売り（買い）メッセージについて述べることとする。メッセージ順序制御機能0105は売り（買い）メッセージを受信完了した場合、受信完了した売り（買い）メッセージが業務処理システム0108へメッセージ投入可能であるかどうかを、受信完了した売り（買い）メッセージが属する銘柄別テーブル0701の行データ0704、銘柄未確定テーブル0601、メッセージ種別未確定テーブル0501を参照して判定する。この場合、銘柄未確定テーブルとメッセージ種別未確定テーブルにあるメッセージIDを通じて、メッセージテーブルの情報も参照されることとなるが、メッセージテーブルを参照することとしてもよい。これは、受信完了した売り（買い）メッセージよりも受信開始時点でのタイムスタンプがより古く、かつ同じメッセージ種別、同じ銘柄のメッセージがあった場合の公平性を保証するためである。売り（買い）メッセージで同じ銘柄を購入しようとしているメッセージの順序がメッセージの受信完了までに入れ替わり、先に送信されたメッセージが後に送信されたメッセージよりも後の注文となることを防止して、注文された順番に実際の注文がなされるよう公平性を保証するものである。例えば、株取引等の場合、ほんの一瞬の注文のタイミングの差で大きく利益が変動してしまうので、注文が前後することによる不公平感をなくす意味がある。
【００５２】
次に、参照メッセージについて述べる。参照メッセージも売り（買い）メッセージと同様、受信開始時点での公平性を確保するためメッセージ順序制御機能0105において順序制御を行なうが、参照メッセージはメッセージ種別が確定した時点で売り（買い）メッセージのように銘柄未確定テーブル0601との依存関係を考慮する必要がない。このためメッセージ順序制御機能0105が参照メッセージを受信完了した時点で参照すべき補助テーブルは参照メッセージテーブル0801、メッセージ種別未確定テーブル0501となる。
【００５３】
最後に、事務手続きメッセージについてであるが、事務手続きメッセージはメッセージ順序制御機能0105が受信開始した時点での公平性を考慮する必要がない。このため、事務手続きメッセージに関しては受信完了時点で業務処理システム0108にメッセージ投入が可能である。
【００５４】
上記を踏まえ、メッセージ順序制御機能0105がメッセージの終了ブロック（0305、0309、0313）を受信した場合の処理について述べる。このとき、売り（買い）メッセージ、参照メッセージ、事務手続きメッセージについて、メッセージテーブル0401、銘柄別テーブル0701、参照メッセージテーブル0801に銘柄情報やメッセージ種別等が上書きされている状態である。メッセージ順序制御機能0105がメッセージ終了ブロック（0305、0309、0313）を受信（ステップ0901）した後、受信したブロックがメッセージの先頭ブロック（0301、0306、0310）であるかどうか（ステップ0902）、事務手続きメッセージであることを示す情報を含むかどうか（ステップ0903）、参照メッセージであることを示す情報を含むかどうか（ステップ0904）、売り（買い）メッセージであることを示す情報を含むかどうか（ステップ0905）、また銘柄情報を含むかどうか（ステップ0906）、メッセージの終了ブロック（0305、0309、0313）であるかどうか（ステップ0907）の判定を行なう。
【００５５】
メッセージ順序制御機能0105が受信したメッセージは終了ブロック（0305、0309、0313）であるため、メッセージ順序制御機能0105は受信完了したメッセージについて、業務処理システム0108へのメッセージ投入制御（ステップ0925）を行なう。またこのとき、メッセージ順序制御機能0105は終了ブロックを受信したメッセージのID情報を一時ファイルに保持しておく。ステップ0925の処理の詳細については図１０で述べる。自テーブル中のメッセージ投入制御（ステップ0925）を行い、メッセージ順序制御は受信メッセージに対して処理を終了する。
【００５６】
ここで、図１０により自テーブル中のメッセージ投入制御の処理について述べる。図１０の処理フローは受信完了したメッセージに対し、業務処理システム0108へ投入可能かどうかを制御するものである。まず始めに、本処理での自テーブルとは、売り（買い）メッセージであればそのメッセージが属する銘柄別テーブル0701の行データ0704、参照メッセージであれば参照メッセージテーブル0801、事務手続きメッセージであればメッセージテーブル0401を指すものとする。この処理手続きで受信完了したメッセージを業務処理システム0108へメッセージ投入可能かどうかの判定を行なうにあたり、まず受信したメッセージのメッセージ内容をメッセージ情報記憶部0107に保存する（ステップ1001）。以下、受信完了したメッセージのメッセージ種別により処理の流れが変わるが、ここではまず、受信完了したメッセージのメッセージ種別が売り（買い）であるとする。ステップ1001の処理の後、受信完了したメッセージのメッセージ種別が事務手続きメッセージであるかどうか（ステップ1002）、参照メッセージであるかどうか（ステップ1003）の判定を行なう。判定の結果、メッセージ種別が売り（買い）であるため、売り（買い）メッセージ投入制御（ステップ1004）を行なう。ステップ1004の処理については図１２の別フローにて説明する。
【００５７】
続いて、図１２により売り（買い）メッセージ投入制御の処理フローについて述べる。始めに、メッセージ順序制御機能0105が銘柄別テーブル0701にアクセスし、受信完了した売り（買い）メッセージのIDノードが銘柄別テーブル0701中で属する行データ0704において先頭ノードであるかどうか、先頭ノードのID情報とメモリ保持している受信完了した売り（買い）メッセージのID情報を比較し、判定を行なう（ステップ1201）。ステップ1201の判定の結果、受信完了した売り（買い）メッセージが銘柄別テーブル0701中で属する行データ0704において先頭ノードでない場合、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、受信完了した売り（買い）メッセージに関する行データ0407の受信状態の項目0406について、”待機”と上書きし、処理を終了する（ステップ1210）。先頭ノードでない場合とは、受信完了した売り（買い）メッセージよりも、先に受信開始したメッセージが存在していることを示している。ここで“待機”とは、メッセージが受信完了状態である旨示す情報であるなら何でもよくこれに限定されるものではない。また、ステップ1201の判定において、受信完了した売り（買い）メッセージが銘柄別テーブル0701中で属する行データ0704において先頭ノードである場合、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501にアクセスする。メッセージ順序制御機能0105は、メッセージ種別未確定テーブル0501の先頭ノードのID情報と紐付けられたメッセージテーブル0401中のタイムスタンプと、受信完了した売り（買い）メッセージのID情報と紐付けられたメッセージテーブル0401中のタイムスタンプを比較し、受信完了した売り（買い）メッセージが先頭ノードのタイムスタンプより古いかどうかを判定する。
【００５８】
また、メッセージ順序制御機能0105は銘柄未確定テーブル0601にアクセスし、銘柄情報が未確定であるメッセージのIDノードのリストの先頭ノードに対し、銘柄未確定テーブル0601のID情報と紐付けられたメッセージテーブル0401中のタイムスタンプを比較し、先頭ノードのタイムスタンプより古いかどうかを判定する。上記2つの判定（ステップ1202）により、メッセージ種別未確定テーブル0501の先頭ノード、銘柄未確定テーブル0601の先頭ノードの少なくとも一方、のノードよりも受信完了した売り（買い）メッセージのタイムスタンプが新しかった場合、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、受信完了した売り（買い）メッセージに関する行データ0407の受信状態の項目0406について、”待機”と上書きし、処理を終了する（ステップ1211）。つまり、受信完了した売り（買い）メッセージよりも新しい記録が存在するということは、これより先に受信の受付を開始した他のメッセージが存在していることを表す。このため、本ステップでは、そのメッセージと順序性を維持するように受信完了した旨示す“待機”の情報を上書きする。
【００５９】
ステップ1202での判定の結果、メッセージ種別未確定テーブル0501、銘柄未確定テーブル0601どちらの先頭ノードよりも受信完了した売り（買い）メッセージのタイムスタンプが古かった場合、メッセージ順序制御機能0105は業務処理システム0108へメッセージ投入する（ステップ1203）。つまり、メッセージのタイムスタンプがどちらの先頭ノードよりも古いということは、この受信完了した売り（買い）メッセージよりも前に受信を開始したメッセージが存在しないことを示し、メッセージの順序が前後する恐れがないため、業務システムへ投入する。
【００６０】
受信完了した売り（買い）メッセージを業務処理システム0108へメッセージ投入し、メッセージ順序制御機能0105はメッセージテーブル0401へアクセスし、受信完了した売り（買い）メッセージに関する行データ0407を削除する（ステップ1204）。次に、メッセージ順序制御機能0105は受信完了した売り（買い）メッセージが属していた銘柄別メッセージテーブル0401にアクセスし、受信完了した売り（買い）メッセージのIDノードを削除する（ステップ1205）。次に、メッセージ順序制御機能0105は再び銘柄別テーブル0701にアクセスし、銘柄別テーブル0701中のID情報0403と紐付くメッセージテーブル0401中の受信状態を参照し、銘柄別テーブル0701の行データ0704の先頭ノードから連続した、待機状態のIDノードを抽出する（ステップ1206）。こうして受信が完了しているメッセージを順次処理していく。ここでの処理では、銘柄別テーブル0701の行データ0704の先頭IDノードに紐付けられたメッセージテーブル0401中の受信状態が”待機”であることを前提とする。受信状態が”待機”でない場合は、自テーブル中のメッセージ投入制御での売り（買い）メッセージに関する処理を終了する。
【００６１】
ステップ1206で抽出した売り（買い）メッセージ中の各IDノードについて、ステップ1202での処理と同様に、メッセージ種別未確定テーブル0501、銘柄未確定テーブル0601のいずれの先頭ノードよりもタイムスタンプが古い売り（買い）メッセージについては業務処理システム0108へ投入する（ステップ1207）。ステップ1207の処理で業務処理システム0108へ投入した売り（買い）メッセージについては、メッセージ順序制御機能0105がメッセージテーブル0401にアクセスし、メッセージ投入した売り（買い）メッセージに関する行データ0407を削除する（ステップ1208）。また、同様にメッセージ順序制御機能0105はメッセージ投入した売り（買い）メッセージが属する銘柄別テーブル0701にアクセスし、メッセージ投入した売り（買い）メッセージのIDノードを削除し（ステップ1209）、処理を終了する。以上の処理により、自テーブル中のメッセージ投入制御での売り（買い）メッセージに関する処理を終了し、またステップ0925での処理も終了する。
【００６２】
次に、受信完了したメッセージのメッセージ種別が参照メッセージである場合のメッセージ順序制御機能0105の処理について述べる。まず、メッセージ順序制御機能0105がメッセージ内容をメッセージ情報記憶部0107に保存し（ステップ1001）、受信完了したメッセージのメッセージ種別が事務手続きメッセージであるかどうか（ステップ1002）、参照メッセージであるかどうか（ステップ1003）の判定を行なう。すなわち、これらで、メッセージの種別を判断する。本例では、受信完了したメッセージのメッセージ種別が参照であるので、ステップ1003の判定の後、参照メッセージ投入制御（ステップ1007）を行なう。ステップ1007での詳細な処理の説明は図１１の処理フローを用いて述べる。
【００６３】
図１１の参照メッセージ投入制御の処理フローでは、始めに、メッセージ順序制御機能0105が参照メッセージテーブル0801にアクセスし、リストの先頭ノードのID情報とメモリに保持している受信完了した参照メッセージのID情報を比較し、一致するかどうか判定する（ステップ1101）。ステップ1101の判定において、受信完了した参照メッセージが参照メッセージテーブルの先頭ノードでない場合、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、受信完了した参照メッセージに関する行データ0407の受信状態の項目0406について、”待機”と上書きし、処理を終了する。先頭ノードと一致しない場合とは、他により早く受信を開始した参照メッセージが存在することを意味する。
【００６４】
ステップ1101の判定において、受信完了した参照メッセージが参照メッセージテーブル0801のリストの先頭ノードである場合、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501にアクセスする。ここで、先頭ノードと一致する場合とは、当該処理対象の参照メッセージが、受信したないし受信中のメッセージの中で最も早く受信した参照メッセージであることを意味する。
【００６５】
メッセージ順序制御機能0105はメッセージ種別未確定テーブルの先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプと、受信完了した参照メッセージのID情報と紐付けられたメッセージテーブル0401中のタイムスタンプを比較し、先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプより古いかどうかを判定する（ステップ1102）。判定の結果、メッセージ種別未確定テーブル0501の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプよりも受信完了した参照メッセージのタイムスタンプが新しい場合、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、受信完了した参照メッセージに関する行データ0407の受信状態の項目について、”待機”と上書きし、処理を終了する。
【００６６】
ステップ1102の判定において、メッセージ種別未確定テーブル0501の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプよりも受信完了した参照メッセージのタイムスタンプが古い場合、メッセージ順序制御機能0105は業務処理システム0108へメッセージ投入する（ステップ1103）。受信完了した参照メッセージを業務処理システム0108へメッセージ投入後、メッセージ順序制御機能0105はメッセージテーブル0401へアクセスし、受信完了した参照メッセージに関する行データ0407を削除する（ステップ1104）。次に、メッセージ順序制御機能0105は参照メッセージテーブル0801にアクセスし、受信完了した参照メッセージのIDノードを削除する（ステップ1105）。
【００６７】
次に、メッセージ順序制御機能0105は再び参照メッセージテーブル0801にアクセスし、参照メッセージテーブル0801中のID情報と紐付くメッセージテーブル0401中の受信状態を参照し、参照メッセージテーブル0801の先頭ノードから、待機状態であるIDノードを抽出する（ステップ1106）。以降の処理では、参照メッセージテーブル0801の先頭IDノードに紐付けられたメッセージテーブル0401中の受信状態が”待機”であることを前提とする。受信状態が”待機”でない場合は、自テーブル中のメッセージ投入制御での参照メッセージに関する処理を終了する。
【００６８】
抽出した参照メッセージテーブル0801中の各IDノードについて、ステップ1103での処理と同様に、メッセージ種別未確定テーブル0501の先頭ノードよりもタイムスタンプが古い参照メッセージについては業務処理システム0108へ投入する（ステップ1107）。ステップ1107の処理で業務処理システム0108へ投入した参照メッセージについては、メッセージ順序制御機能0105がメッセージテーブル0401にアクセスし、メッセージ投入した参照メッセージに関する行データ0407を削除する（ステップ1108）。また同様にメッセージ順序制御機能0105は参照メッセージテーブル0801にアクセスし、メッセージ投入した参照メッセージのIDノードを削除し（ステップ1109）、処理を終了する。以上の処理により、自テーブル中のメッセージ投入制御での参照メッセージに関する処理（ステップ0916）も終了する。
【００６９】
ここで図１５、図１６、図１７により、具体例を述べる。メッセージIDが「002」の参照メッセージが受信完了したとき 、メッセージIDが「002」のIDノードは参照メッセージテーブル（図１７の0801）において先頭ノードであり、かつメッセージ種別未確定テーブル（図１５の0501）の先頭ノードであるメッセージIDが「008」のメッセージよりもタイムスタンプが古いため、業務処理システムへメッセージ投入する。続いて、参照メッセージテーブル（図１７の0801）において、メッセージIDが「002」の参照メッセージと連続し、かつ待機状態であるメッセージIDが「004」の参照メッセージを抽出する。メッセージIDが「004」の参照メッセージについても、メッセージ種別未確定テーブル（図１５の0501）の先頭ノードである、メッセージIDが「008」のメッセージとタイムスタンプを比較し、メッセージIDが「004」の参照メッセージがより古いため、業務処理システム0108へメッセージ投入する。参照メッセージにおいて、メッセージIDが「004」である参照メッセージ以降の参照メッセージについては、たとえばメッセージIDが「006」の参照メッセージも待機状態であるが、参照メッセージテーブル（図１７の0801）において直前の参照メッセージである、メッセージIDが「005」の参照メッセージが受信途中であるため、当該参照メッセージの受信処理を継続する。
【００７０】
最後に、受信完了したメッセージのメッセージ種別が事務手続きメッセージである場合のメッセージ順序制御機能0105の処理について述べる。まず、メッセージ順序制御機能0105がメッセージ内容をメッセージ情報記憶部0107に保存し（ステップ1001）、受信完了したメッセージのメッセージ種別が事務手続きメッセージであるかどうか（ステップ1002）を判定する。なお、ここでは、メッセージ情報記憶部0107に記録すると記載したが、本記録処理を省略して判定処理を実行してもよい。受信完了したメッセージのメッセージ種別は事務手続きであるため、ステップ1002の判定の結果、メッセージ順序制御機能0105は、メッセージ情報記憶部0107が記憶する、受信完了した事務手続きメッセージの情報を業務処理システム0108へ送信する（ステップ1005）。メッセージ情報を業務処理システム0108へメッセージ投入後、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、受信完了したメッセージに関する行データ0407を削除し（ステップ1006）、処理を終了する。以上、メッセージ順序制御機能0105がメッセージの終了ブロック（0305、0309、0313）を受信した場合の処理の説明とする。
【００７１】
＜銘柄情報を含むブロックを受信した場合の処理＞
次に、メッセージ順序制御機能0105が銘柄情報（<meigara>タグ）を含むブロック0303を受信した場合のメッセージ投入制御の処理について述べる。図９による具体的な処理の説明の前にまず、メッセージ順序制御機能0105が銘柄情報を含むブロック0303を受信した場合の順序制御の考え方について説明する。
【００７２】
メッセージ順序制御機能0105が銘柄情報を含むブロック0303を受信したことにより、銘柄が未確定であった売り（買い）メッセージの銘柄が特定され、これにより、メッセージ順序制御機能0105が受信し、銘柄を特定した売り（買い）メッセージと公平性において依存関係にない、他の銘柄の売り（買い）メッセージが業務処理システム0108へメッセージ投入可能となる可能性がある。
【００７３】
上記を踏まえ、メッセージ順序制御機能0105が銘柄情報を含むブロック0303を受信した場合の処理について述べる。このとき、メッセージ種別が事務手続きメッセージであった場合と同様、メッセージテーブル0401にはタイムスタンプ0402、ID情報0403、メッセージ種別0404、受信状態0406が既に上書きされている状態であるとする。
また、銘柄未確定テーブル0601にも、メッセージ順序制御機能0105が受信した売り（買い）メッセージに関するIDノードが既に存在するものとする。
【００７４】
メッセージ順序制御機能0105が銘柄情報を含むブロック0303を受信（ステップ0901）すると、メッセージ順序制御機能0105は受信したブロックがメッセージの先頭ブロック（0301、0306、0310）であるかどうか（ステップ0902）、事務手続きメッセージであることを示すキー情報（<jimusyori>タグ）を含むかどうか（ステップ0903）、参照メッセージであることを示すキー情報（<reference>タグ）を含むかどうか（ステップ0904）、売り（買い）メッセージであることを示すキー情報（<sell>タグ、もしくは<buy>タグ）を含むかどうか（ステップ0905）、銘柄情報（<meigara>タグ）を含むかどうか（ステップ0906）の判定を行なう。
【００７５】
ここで、受信したブロックは銘柄情報を含んでいるため、ステップ0906の判定処理の後、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、ステップ0906で銘柄情報を含むと判定したメッセージに関する行データ0407中の銘柄情報の項目0405に<meigara>タグの内容（銘柄情報）を上書きする（ステップ0921）。また、メッセージ順序制御機能0105は銘柄別テーブル0701にアクセスし、ステップ0906で銘柄情報を含むと判定したメッセージに関するID情報を行データ0704中のリストに追加する（ステップ0922）。このことにより、銘柄情報から銘柄を特定して、対応する銘柄とID情報を対応付けて記憶することになる。
【００７６】
次に、ステップ0901で受信した売り（買い）メッセージが属する銘柄別テーブル0701の行データ0704以外の行データ0704において、受信したブロックがステップ0906で銘柄情報を含むと確定したことにより、受信状態が待機状態であり、業務処理システム0108に新たにメッセージ投入可能となったメッセージについての処理を行なう（ステップ0923）。この処理の詳細な処理の流れについては図１３のフローで述べる。
【００７７】
図１３の他銘柄メッセージ投入制御（ステップ0923）を行なうと、メッセージ順序制御機能0105は銘柄未確定テーブル0601にアクセスし、銘柄が確定したIDノードを削除する（ステップ0924）。ステップ0924の処理の後、メッセージ順序制御機能0105は受信したブロックのメッセージ情報をメッセージ情報記憶部0107に保存し（ステップ0926）、処理を終了する。
【００７８】
ここで、ステップ0923の詳しい処理について、図１３により述べる。図１３の他銘柄メッセージ投入制御（ステップ0923）では、まず、メッセージ順序制御機能0105が、銘柄情報が確定したメッセージに関して、銘柄未確定テーブル0601の先頭ノードであるかどうかの判定を行なう（ステップ1301）。ステップ1301の判定の結果、銘柄未確定テーブル0601の先頭ノードでない場合、ステップ0924処理を終了する。
【００７９】
ステップ1301の判定において、銘柄情報が確定したメッセージが銘柄未確定テーブル0601の先頭ノードである場合、メッセージ順序制御機能0105は銘柄未確定テーブル0601の先頭ノードの次のIDノードを参照し、前記IDノードに紐付けられたメッセージテーブル0401中のタイムスタンプを一時的にメモリに保持しておく。
【００８０】
そして、メッセージ順序制御機能0105は銘柄別テーブル0701の各行データ0704にアクセスし、各行データ0704の先頭ノードと紐付けられたメッセージテーブル0401のタイムスタンプを参照し、メモリ上に保持している、銘柄未確定テーブル0601の先頭ノードの次のIDノードのタイムスタンプと比較し、銘柄別テーブル0701の他銘柄の各行データ0704の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプの方が銘柄未確定テーブル0601の先頭ノードの次のIDノードのタイムスタンプよりも古いIDノードについて抽出する。
【００８１】
またこのとき、メッセージ順序制御機能0105は、銘柄別テーブル0701の他銘柄の各行データ0704において、抽出した先頭ノード以降のIDノードと紐付けられたメッセージテーブル0401中の受信状態が待機状態であり、かつ先頭ノードと連続したノードも併せて抽出する（ステップ1302）。
【００８２】
次に、抽出した各IDノードについて、メッセージ順序制御機能0105は、メモリに一時的に保持している銘柄未確定テーブル0601の先頭ノードの次のIDノードと紐付けられたメッセージテーブル0401中のタイムスタンプと比較し、メモリに一時的に保持しているタイムスタンプのタイムスタンプよりも古いメッセージについては、業務処理システム0108へ投入する（ステップ1303）。ステップ1303で業務処理システム0108へ投入したメッセージについては、メッセージ順序制御機能0105は各メッセージが属している銘柄別テーブル0701の各行データ0704にアクセスし、メッセージ投入した各メッセージが属する銘柄別テーブル0701の各行データ0704にアクセスし、メッセージ投入した各メッセージのIDノードを削除し（ステップ1305）、処理を終了する。以上、メッセージ順序制御機能0105が銘柄情報（<meigara>タグ）を含むブロック0303を受信した場合の処理の説明とする。
【００８３】
＜メッセージ情報を含むブロックを受信した場合の処理＞
最後に、3種類のメッセージ種別のうち、売り（買い）、参照、事務手続きのいずれかのキー情報を含むブロック（0302、0307、0311）をメッセージ順序制御機能0105が受信した場合のそれぞれの処理について述べる。
【００８４】
図９に示す具体的な処理の説明の前にまず、メッセージ順序制御機能0105が売り（買い）、参照、事務手続きのいずれかのキー情報を含むブロック（0302、0307、0311）を受信した場合の順序制御の考え方について説明する。
【００８５】
まず、メッセージ順序制御機能0105が受信したメッセージを売り（買い）メッセージであると特定可能なキー情報を含むブロック0302を受信した場合の考え方について述べる。メッセージ順序制御機能0105が、メッセージ種別が売り（買い）であると特定可能なブロックを受信したことにより、メッセージ種別が参照であり、待機状態にある参照メッセージが業務処理システム0108へメッセージ投入可能となる可能性がある。このため、メッセージ順序制御機能0105は受信状態が待機中である参照メッセージについて、メッセージ投入可能かどうかの判定処理を行なう。
【００８６】
続いて、メッセージ順序制御機能0105がメッセージを参照メッセージであると特定可能なキー情報を含むブロック0307を受信した場合の考え方について述べる。メッセージ順序制御機能0105が、メッセージ種別が参照であると特定可能なブロックを受信したことにより、メッセージ種別が売り（買い）であり、待機状態にある各銘柄別の売り（買い）メッセージが業務処理システム0108へメッセージ投入可能となる可能性がある。つまり、メッセージ種別が確定されないと、後に先頭ブロックが受信されて先に受信完了して待機状態になっているメッセージは、先に先頭ブロックが受信されまだ受信が完了していないメッセージより、後に投入処理されるようその投入処理を待機して、メッセージ投入のタイミングが前後が入れ替えないようにする必要がある。メッセージ種別が確定した場合に、待機中のメッセージは投入してよいのか、新たに受信したメッセージを先に投入する必要があるのかを判断する必要がある。このため、メッセージ順序制御機能0105は受信状態が待機中である各銘柄別の売り（買い）メッセージについて、メッセージ投入可能かどうかの判定処理を行なう。
【００８７】
最後に、メッセージ順序制御機能0105がメッセージを事務手続きメッセージであると特定可能なキー情報を含むブロック0311を受信した場合の考え方について述べる。メッセージ順序制御機能0105が、メッセージ種別が事務手続きであると特定可能なブロックを受信したことにより、メッセージ種別が売り（買い）であり、待機状態にある各銘柄別の売り（買い）メッセージと、メッセージ種別が参照であり、待機状態にある参照メッセージが、業務処理システム0108へメッセージ投入可能となる可能性がある。このため、メッセージ順序制御機能0105は受信状態が待機中である各銘柄別の売り（買い）メッセージと、同じく受信状態が待機中である参照メッセージについて、メッセージ投入可能かどうかの判定処理を行なう。
【００８８】
上記を踏まえ、メッセージ順序制御機能0105がメッセージ種別を特定可能なキー情報を含むブロック（0302、0307、0311）を受信した場合の処理について述べる。
【００８９】
まず、メッセージ種別が売り（買い）であることを示すキー情報（<sell>タグ、もしくは<buy>タグ）を含むブロック0302をメッセージ順序制御機能0105が受信した場合の処理について述べる。
【００９０】
このとき、メッセージテーブル0401にはタイムスタンプ、ID情報、受信状態が既に上書きされている状態である。メッセージ順序制御機能0105が売り（買い）メッセージのキー情報を含むブロック0302を受信（ステップ0901）した後、メッセージ順序制御機能0105は受信したブロックがメッセージの先頭ブロック（0301、0306、0310）であるかどうか（ステップ0902）、事務手続きメッセージであることを示すキー情報（<jimusyori>タグ）を含むかどうか（ステップ0903）、参照メッセージであることを示すキー情報（<reference>タグ）を含むかどうか（ステップ0904）、売り（買い）メッセージであることを示すキー情報を含むかどうか（ステップ0905）の判定を行なう。
【００９１】
受信したメッセージのメッセージ種別が売り（買い）であるため、ステップ0905の判定処理（ステップ0902、ステップ0903、ステップ0904、ステップ0905）の後、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、ステップ0903で売り（買い）メッセージであると判定したメッセージに関する行データ0407中のメッセージ種別に”売り（買い）”であると上書きする（ステップ0917）。また、メッセージ順序制御機能0105は銘柄未確定テーブル0601にアクセスし、ステップ0903で売り（買い）メッセージであると判定したメッセージに関するID情報を銘柄未確定テーブル0601のリストに追加する（ステップ0918）。この場合、銘柄情報を含んだブロックはまだ受信状態になく、売り（買い）メッセージの銘柄はまだ確定していないことを表している。
【００９２】
次に、参照メッセージテーブル0801において、受信したメッセージがステップ0903で売り（買い）メッセージであると確定したことに依り、受信状態が待機状態であり、業務処理システム0108に新たにメッセージ投入可能となったメッセージについての処理を行なう（ステップ0919）。この処理についての具体的な処理フローを図１４で示す。他テーブル中のメッセージ投入制御（ステップ0919）の後、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501にアクセスし、メッセージ種別が確定したIDノードを削除する（ステップ0920）。ステップ0920の処理の後、メッセージ順序制御機能0105は受信したブロックのメッセージ情報をメッセージ情報記憶部0107に保存し（ステップ0926）、ステップ0901の処理に戻る。
【００９３】
ここで、図１４を用いて、メッセージ順序制御機能0105が売り（買い）メッセージであると判定可能なキー情報（<sell>タグ、もしくは<buy>タグ）を含むブロック0302を受信した場合の、他テーブル中のメッセージ投入制御（ステップ0919）の具体的な処理について述べる。
【００９４】
始めに、メッセージ種別が売り（買い）であると確定したメッセージに関して、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501で先頭ノードであるかどうかの判定を行なう（ステップ1401）。ステップ1401の判定でメッセージ種別未確定テーブル0501の先頭ノードでない場合、ステップ0919の処理を終了する。
【００９５】
メッセージ投入制御のステップ1401の判定において、メッセージ種別未確定テーブル0501で先頭ノードである場合、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501の先頭ノードの次のノードを参照し、前記IDノードに紐付けられたメッセージテーブル0401中の情報を参照し、タイムスタンプ情報をメモリ上に保持しておく。その後、メッセージ順序制御機能0105は参照メッセージテーブル0801にアクセスし、参照メッセージテーブル0801の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプを参照し、メモリ上に保持していたメッセージ種別未確定テーブル0501の先頭ノードの次のノードと紐付けられたメッセージテーブル0401中のタイムスタンプと比較し、参照メッセージテーブル0801の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプの方がメッセージ種別未確定テーブル0501の先頭ノードの次のIDノード、銘柄未確定テーブル0601の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプよりも古いIDノードについて抽出する。これにより、投入可能な参照メッセージテーブルの先頭の参照メッセージを特定する。
【００９６】
またこのとき、参照メッセージテーブル0801のリストにおいて、抽出した先頭ノード以降のIDノードについて、メッセージ順序制御機能0105は、メッセージテーブル0401の受信状態が待機状態である、先頭ノードと連続したノードも併せて抽出する（ステップ1402）。
【００９７】
次に、メッセージ順序制御機能0105は、ステップ1402で抽出した各IDノードと、メッセージ種別未確定テーブル0501の先頭ノードの次のIDノード、銘柄未確定テーブル0601の先頭ノードのタイムスタンプとをそれぞれ比較し、いずれのタイムスタンプよりも古いメッセージは、業務処理システム0108へ投入する（ステップ1403）。これは、投入可能、すなわち、受信（要求）順序を保証された参照メッセージを投入することを意味する。ステップ1403の処理で業務処理システム0108へ投入したメッセージについては、メッセージ順序制御機能0105は各メッセージが属している参照メッセージテーブル0801にアクセスし、メッセージ投入したメッセージと紐付くメッセージテーブル0401の行データ0407を削除する（ステップ1404）。またメッセージ順序制御機能0105は、メッセージ投入した各メッセージが属する参照メッセージテーブル0801にアクセスし、メッセージ投入した各メッセージのIDノードを削除し（ステップ1405）、ステップ0919の処理を終了する。
【００９８】
続いて、メッセージ種別が参照であることを示すキー情報（<reference>タグ）を含むブロック0311を、メッセージ順序制御機能0105が受信した場合の処理について述べる。このとき、メッセージ種別が事務手続きメッセージであった場合と同様、メッセージテーブル0401にはタイムスタンプ、ID情報、受信状態が既に上書きされている状態であるとする。
【００９９】
メッセージ順序制御機能0105が参照メッセージのキー情報を含むブロック0311を受信（ステップ0901）すると、メッセージ順序制御機能0105は受信したブロックがメッセージの先頭ブロック（0301、0306、0310）であるかどうか（ステップ0902）、事務手続きメッセージであることを示すキー情報（<jimusyori>タグ）を含むかどうか（ステップ0903）、参照メッセージであることを示すキー情報（<reference>タグ）を含むかどうか（ステップ0904）の判定を行なう。
【０１００】
受信したメッセージのメッセージ種別が参照であるため、ステップ0904の判定の後、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、ステップ0904で参照メッセージであると判定したメッセージに関する行データ0407中のメッセージ種別に”参照”であると上書きする（ステップ0913）。また、メッセージ順序制御機能0105は参照メッセージテーブル0801にアクセスし、ステップ0904で参照メッセージであると判定したメッセージに関するID情報を参照メッセージテーブル0801のリストに追加する（ステップ0914）。
【０１０１】
次に、銘柄別テーブル0701において、メッセージ順序制御機能0105が受信したメッセージがステップ0903で参照メッセージであると確定したことに依り、受信状態が待機状態であり、業務処理システム0108に新たにメッセージ投入可能となったメッセージについての処理を行なう（ステップ0915）。この処理についての具体的な処理フローについて図１４で示す。他テーブル中のメッセージ投入制御（ステップ0915）の後、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501にアクセスし、メッセージ種別が確定したIDノードを削除する（ステップ0916）。ステップ0915の処理の後、メッセージ順序制御機能0105は受信したブロックのメッセージ情報をメッセージ情報記憶部0107に保存し（ステップ0926）、ステップ0901の処理に戻る。
【０１０２】
ここで、図１４により、メッセージ順序制御機能0105が参照メッセージであると判定可能なキー情報（<reference>タグ）を含むブロック0307を受信した場合の、他テーブル中のメッセージ投入制御（ステップ0915）の具体的な処理について述べる。
【０１０３】
始めに、メッセージ種別が参照であると確定したメッセージに関して、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501で先頭ノードであるかどうかの判定を行なう（ステップ1401）。ステップ1401の判定の結果、メッセージ種別未確定テーブル0501において先頭ノードでない場合、ステップ0915の処理を終了する。
【０１０４】
メッセージ投入制御のステップ1401の判定において、メッセージ種別未確定テーブル0501で先頭ノードである場合、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501の先頭ノードの次のノードを参照し、前記IDノードに紐付けられたメッセージテーブル0401中の行データ0407を参照し、タイムスタンプ情報をメモリ上に保持しておく。そして、メッセージ順序制御機能0105は各銘柄別テーブル0701にアクセスし、銘柄別の各行データ0704の先頭ノードと紐付けられたメッセージテーブル0401中のタイムスタンプを参照し、メモリ上に保持していたメッセージ種別未確定テーブル0501、銘柄未確定テーブル0601の先頭ノードのタイムスタンプと比較し、銘柄別テーブル0701の各行データ0704の先頭ノードのタイムスタンプの方がメッセージ種別未確定テーブル0501の先頭ノードの次のIDノード、銘柄未確定テーブル0601の先頭ノードのタイムスタンプよりも古いノードについて抽出する。これにより、投入可能な、すなわち、順序性が保証された銘柄別テーブルの先頭の参照メッセージを特定する。またこのとき、銘柄別テーブル0701の各行データ0704において、抽出した先頭ノード以降のIDノードについて、メッセージ順序制御機能0105は、メッセージテーブル0401の受信状態が待機状態である、先頭ノードと連続したノードも併せて抽出する（ステップ1402）。
次に、ステップ1402で抽出した各IDノードについて、メッセージ順序制御機能0105は、メモリ上に一時的に保持しているメッセージ種別未確定テーブル0501の先頭ノードの次のIDノード、銘柄未確定テーブル0601の先頭ノードのタイムスタンプと比較し、いずれのタイムスタンプよりも古いメッセージについては、業務処理システム0108へ投入する（ステップ1403）。これにより、投入可能な売り（買い）メッセージが投入される。ステップ1403の処理で業務処理システム0108へ投入したメッセージについては、メッセージ投入したメッセージと紐付くメッセージテーブル0401の行データ0407を削除する（ステップ1404）。またメッセージ順序制御機能0105は、メッセージ投入した各メッセージが属する銘柄別テーブル0701の各行データ0407にアクセスし、メッセージ投入した各メッセージのIDノードを削除し（ステップ1405）、ステップ0915の処理を終了する。
【０１０５】
最後に、メッセージ種別が事務手続きであることを示すキー情報を含むブロック0311をメッセージ順序制御機能0105が受信した場合の処理について述べる。このとき、メッセージテーブル0401にはタイムスタンプ、ID情報、受信状態が既に上書きされている状態である。
【０１０６】
メッセージ順序制御機能0105が事務手続きメッセージのキー情報を含むブロック0311を受信（ステップ0901）した後、メッセージ順序制御機能0105は受信したブロックがメッセージの先頭ブロック（0301、0306、0310）であるかどうか（ステップ0902）、事務手続きメッセージであることを示すキー情報（<jimusyori>タグ）を含むかどうかの判定（ステップ0903）を行なう。
【０１０７】
受信したメッセージのメッセージ種別は事務手続きメッセージであるため、ステップ0903の判定処理の後、メッセージ順序制御機能0105はメッセージテーブル0401にアクセスし、ステップ0903で事務手続きメッセージであると判定したメッセージに関する行データ0407中のメッセージ種別に”事務手続き”であると上書きする（ステップ0910）。
【０１０８】
次に、ステップ0901で受信した事務手続きメッセージが属するメッセージテーブル0401以外のテーブル（参照メッセージテーブル0801、銘柄別テーブル0701）において、受信したメッセージがステップ0903で事務手続きメッセージであると確定したことに依り、受信状態が待機状態であり、業務処理システム0108に新たにメッセージ投入可能となったメッセージについての処理を行なう（ステップ0911）。この処理についての詳細な処理の流れについては図１４のフローで述べる。他テーブル中のメッセージ投入制御の後、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501にアクセスし、メッセージ種別が確定したIDノードを削除する（ステップ0912）。ステップ0912の処理を行うと、メッセージ順序制御機能0105は受信したブロックのメッセージ情報をメッセージ情報記憶部0107に保存し、ステップ0901の処理に戻る。
【０１０９】
メッセージ順序制御機能0105は、図１４の他テーブル中のメッセージ投入制御において、始めに、メッセージ種別が事務手続きであると確定したメッセージに関して、メッセージ種別未確定テーブル0501で先頭ノードであるかどうかの判定を行なう（ステップ1401）。ステップ1401の判定の結果、メッセージ種別が事務手続きであると確定したメッセージがメッセージ種別未確定テーブル0501の先頭ノードでない場合、ステップ0911の処理を終了する。
【０１１０】
メッセージ投入制御のステップ1401の判定において、メッセージ種別が事務手続きであると確定したメッセージがメッセージ種別未確定テーブル0501の先頭ノードである場合、メッセージ順序制御機能0105はメッセージ種別未確定テーブル0501の先頭ノードの次のノード、銘柄未確定テーブル0601の先頭ノードをそれぞれ参照し、各ノードのID情報に紐付けられたメッセージテーブル0401中の情報を参照し、タイムスタンプ情報をメモリ上に保持しておく。
【０１１１】
そして、メッセージ順序制御機能0105は参照メッセージテーブル0801、各銘柄別テーブル0701の各テーブルの先頭ノードについて、それぞれ紐付けられているメッセージテーブル0801中の受信状態が“待機”であるIDノードを抽出する。
【０１１２】
またこのとき、参照メッセージテーブル0801、各銘柄別テーブル0701のリストにおいて、抽出した先頭ノード以降のIDノードについて、メッセージ順序制御機能0105は、メッセージテーブル0401の受信状態が待機状態である、先頭ノードと連続したIDノードも併せて抽出する。
【０１１３】
抽出した各IDノードのうち、メッセージ種別が売り（買い）であるIDノードについて、メッセージ順序制御機能0105が、メモリ上に一時的に保持しているメッセージ種別未確定テーブル0501の先頭ノードの次のノード、銘柄未確定テーブル0601の先頭ノードのタイムスタンプと比較し、いずれのタイムスタンプよりも古いメッセージについては、業務処理システム0108へ投入する（ステップ1403）。
【０１１４】
また抽出した各IDノードのうち、メッセージ種別が参照であるIDノードについて、メッセージ順序制御機能0105が、メモリ上に一時的に保持しているメッセージ種別未確定テーブル0501の先頭ノードの次のノードのタイムスタンプと比較し、より古い参照メッセージについては、業務処理システム0108へ投入する（ステップ1403）。
【０１１５】
ステップ1403の処理で業務処理システム0108へ投入したメッセージについては、メッセージ順序制御機能0105が、各メッセージが属している参照メッセージテーブル0801、もしくは銘柄別テーブル0701にアクセスし、メッセージ投入したメッセージに関する行データ0407を削除する（ステップ1404）。また同様にメッセージ順序制御機能0105はメッセージ投入した各メッセージが属する参照メッセージテーブル0801、銘柄別テーブル0701にアクセスし、メッセージ投入した各メッセージのIDノードを削除し（ステップ1405）、ステップ0911の処理を終了する。
【符号の説明】
【０１１６】
０１０１  メッセージ送信システム
０１０２  ネットワーク
０１０３  取引所システム
０１０４  メッセージ投入順序制御システム
０１０５  メッセージ順序制御機能
０１０６  補助テーブル記憶部
０１０７  メッセージ情報記憶部
０１０８  業務処理システム
０２０１  CPU
０２０２  メモリ
０２０３  ハードディスク
０２０４  ネットワーク
０２０５  通信制御装置
０２０６  入力装置
０２０７  出力装置
０２０８  入出力インタフェース
０２０９  バス
０３０１  売り（買い）メッセージの先頭部分
０３０２  売り（買い）メッセージか判別可能な情報を含むブロック
０３０３  銘柄情報を含むブロック
０３０４  売り（買い）メッセージの本体部分
０３０５  売り（買い）メッセージの終了部分
０３０６  参照メッセージの先頭部分
０３０７  参照メッセージが判別可能な情報を含むブロック
０３０８  参照メッセージの本体部分
０３０９  参照メッセージの終了部分
０３１０  事務手続きメッセージの先頭部分
０３１１  事務手続きメッセージか判別可能な情報を含むブロック
０３１２  事務手続きメッセージの本体部分
０３１３  事務手続きメッセージの終了部分
０４０１  メッセージテーブル
０４０２  タイムスタンプの項目
０４０３  メッセージIDの項目
０４０４  メッセージ種別の項目
０４０５  銘柄情報の項目
０４０６  受信状態の項目
０４０７  メッセージテーブルの行データ
０５０１  メッセージ種別未確定テーブル
０６０１  銘柄未確定テーブル
０７０１  銘柄別テーブル
０７０２  銘柄情報の項目
０７０３  メッセージのID情報の項目
０７０４  銘柄別テーブルの行データ
【図１】
0005608528.tif 000002
【図２】
0005608528.tif 000003
【図３】
0005608528.tif 000004
【図４】
0005608528.tif 000005
【図５】
0005608528.tif 000006
【図６】
0005608528.tif 000007
【図７】
0005608528.tif 000008
【図８】
0005608528.tif 000009
【図９】
0005608528.tif 000010
【図１０】
0005608528.tif 000011
【図１１】
0005608528.tif 000012
【図１２】
0005608528.tif 000013
【図１３】
0005608528.tif 000014
【図１４】
0005608528.tif 000015
【図１５】
0005608528.tif 000016
【図１６】
0005608528.tif 000017
【図１７】
0005608528.tif 000018