(57)【特許請求の範囲】
【請求項１】
それぞれが複数のグループのいずれかに属する複数の取引端末であって、取引要求を送信する取引端末と接続され、複数の処理装置から構成され前記取引要求に応じた証券取引処理を行う取引システムにおいて、
前記複数の処理装置は、少なくとも前記証券取引処理の一部を実行するための処理依頼であってタイムアウトにより一定時間時間後に発行後効力が消滅することがある処理依頼を発行する第１の処理装置、および前記処理依頼が格納された記憶装置を備えた第２の処理装置であって、前記記憶装置から抽出された処理依頼に応じた処理を実行する第２の処理装置を含み、
前記第１の処理装置が、
前記処理依頼を発行して、前記記憶装置に格納させ、
前記処理依頼に対応する前記処理依頼で実行すべき処理を実行するための要件情報を要件データベースに格納し、
前記第２の処理装置が、
前記記憶装置に前記処理依頼が存在するかを確認し、
（１）前記処理依頼が存在する場合には、対応する要件情報を前記要件データベースから検索して、対応する処理を実行し、
（２）前記処理依頼が存在しない場合には、前記要件データベースを検索して、自身で実行すべき処理のうち、未処理の要件情報を検索し、
未処理の要件情報がある場合には、自身に対して未処理の要件情報に対応する処理依頼である依頼情報を発行して、前記記憶装置に格納させ、
前記記憶装置に前記依頼情報もしくは前記処理依頼が存在するかを確認し、前記依頼情報もしくは前記処理依頼が存在する場合は、前記要件データベースから、対応する要件情報を取得して、該当する処理を実行することを特徴とする取引システム。
【請求項２】
請求項１に記載の取引システムにおいて、
前記第２の処理装置は、前記依頼情報がある場合、当該未処理の要件情報の件数を計数し、
前記該当する処理を実行した場合もしくは前記対応する要件情報を取得した場合、計数された前記件数を１減算し、
減算された前記件数が０を示すまで自身への依頼情報の発行を繰り返すことを可能とすることを特徴とする取引システム。
【請求項３】
請求項１または２のいずれかに記載の取引システムにおいて、
前記依頼情報は、タイムアウトにより一定時間後に自身の効力が消滅する情報であることを特徴とする取引システム。
【請求項４】
請求項３に記載の取引システムにおいて、
前記第２の処理装置は、前記処理依頼および前記依頼情報のうち少なくとも一方の効力が消滅したことを検知し、当該検知した場合に、前記処理依頼がないと判定することを特徴とする取引システム。
【請求項５】
請求項３または４のいずれかに記載の取引システムにおいて、
前記処理依頼および前記依頼情報は、前記記憶装置である転送キューに格納されていることを特徴とする取引システム。
【請求項６】
請求項２乃至５のいずれかに記載の取引システムにおいて、
前記第２の処理装置は、自身に対する依頼情報を、計数された前記未処理の要件情報の件数以下であることを特徴とする取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、株式等の有価証券を含む商品の取引を含む所定の業務を実現するための技術に関する。その中でも取引、特にいわゆる証券市場と称される取引所で用いられる証券取引システム、その方法およびそのためのプログラムに関する。
【背景技術】
【０００２】
従来、証券取引などの業務を実行する場合、複数の処理装置を連携して業務を実現することが実行されている。このような処理を実行するために、いわゆるキューを用いて処理が行われている。例えば、特許文献１においては、以下の構成が開示されている。業務 プロセス トラッキング装置に関し，異なる業務 システム間を跨いで行われる複数のアプリケーションからなる業務 プロセス の流れを，既存システムを変更することなく追跡することを可能とすることを目的とする。この目的を達成するために、特許文献１では、イベント管理装置１は，各業務 システムＡ３〜Ｃ５のイベント抽出部３２〜５２がイベント抽出定義に基づいて抽出したイベントデータを収集し，イベントキュー １２にキュー イングする。イベント関連付け部１３は，イベントデータを業務 データ単位にまとめ，業務 データ間の関連付けを行ってイベント管理ＤＢ１４に蓄積する。ユーザ端末６から検索条件が入力されると，出力部１６が検索条件に従ってイベント管理ＤＢ１４を検索し，業務 データ間の関連をツリー形式でユーザ端末６に出力し表示する。
【０００３】
【特許文献１】特開2005-115494号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１においては、ワークフローを対象としており、業務プロセスを如何にして把握（追跡）するかを目的としている。すなわち、特許文献１では、各処理装置が実行すべき処理が行われていない場合、どのようにリカバリー（回復）させるかに関しては、特に考慮されていない。このため、特許文献１においては、処理装置での処理がとまった場合、所定の業務を効率的に回復させることができなかった。特に、ある装置から処理依頼（時限式の所定時間などでその効力が消滅するもの）を発行して、それをトリガーに処理を実行するものの場合、未処理の案件が蓄積されてしまうとの問題が生じる。さらに、このように未処理の案件が蓄積されると、記憶装置などのハードウエア資源が無駄になるばかりでなく、ひいてはこれらハードウエア資源を含むシステムが停止し、取引を含む業務自体が中止されることも生じてしまう。
【課題を解決するための手段】
【０００５】
そこで、本発明では、自身に対する処理依頼に関する情報がなく、実態としては処理すべきもの（案件、要件情報）が存在する場合には、自身に対して依頼情報を発行して処理を開始する。ここで、本発明においては、処理依頼に関する情報とこれに対応し、処理を実行するために必要な要件情報を別に扱うことも含まれ、この要件情報の有無により実体として処理すべきものが存在するかを判断してもよい。
【０００６】
より具体的には、本発明は以下のように構成される。
それぞれが複数のグループのいずれかに属する複数の取引端末であって、取引要求を送信する取引端末と接続され、複数の処理装置から構成され前記取引要求に応じた証券取引処理を行う取引システムにおいて、前記複数の処理装置は、少なくとも前記証券取引処理の一部を実行するための処理依頼であって発行後に効力が消滅することがある処理依頼を発行する第１の処理装置および前記依頼情報に応じた処理を実行する第２の処理装置を含み、前記第１の処理装置が、前記処理依頼を発行し、前記処理依頼に対応する前記処理依頼で実行すべき処理を実行するための要件情報を要件データベースに格納し、前記第２の処理装置が、発行された処理依頼の有無を確認し、（１）前記処理依頼がある場合には、対応する要件情報を前記要件データベースから検索して、対応する処理を実行し、（２）前記処理依頼がない場合には、前記要件データベースを検索して、自身で実行すべき処理のうち、未処理の要件情報を検索し、未処理の要件情報がある場合には、自身に対して未処理の要件情報の存在に対応する依頼情報を発行し、前記依頼情報を受けて前記要件データベースから、対応する要件情報を取得して、該当する処理を実行する。ここで、発行後一定期間後に効力が消滅する処理依頼とは、マシンの障害時等に回復されない、非永続的なメッセージを含む。また、一定期間後に効力もしくは自身が消滅するものでもよい。
【０００７】
ここで、発行された処理依頼の有無の確認は、有効な処理依頼の有無を確認することも含む。例えば、発行された処理依頼が無効化(効力の消滅および自身の消滅を含む例えば、タイムアウト)されることを検知することも含まれる。また、第1の処理装置は、この処理依頼を所定のデータベース（各処理装置からアクセス可能な）に書き込む。なお、このデータベースは、要件データベースとしてもよい。また、第２の処理装置の処理依頼の有無の確認は、上記のデータベースにアクセスことで実行する。この際、要件情報に処理・未処理を示すフラグを設け、この内容を用いて有無の確認を実行してもよい。但し、処理依頼を第２の処理装置に送信し、要件情報を要件データベースに格納する構成にしてもよい。
【０００８】
また、第２の処理装置が発行する依頼情報は、「擬似」処理依頼としてよい。つまり、内容的に、処理依頼と同じ項目とし、対象の要件情報（処理対象）を要件データベースに格納された要件情報に従って入力する。つまり、要件データベースに格納された要件情報のうち、自身で処理すべきものであって、未処理の要件情報を抽出し、その要件情報に対応する識別情報を書き込む。ここで、タイムスタンプ機能を用いて順序性を保つよう構成してもよい。つまり、抽出された要件情報には、タイムスタンプ機能により記録された依頼時を示す情報が含まれており、これを用いて順序性を保つように制御する。
【０００９】
さらに、依頼情報は、タイムアウトした(無効化)ことを検知した場合に、発行することも本発明に含まれる。
【００１０】
また、上記において、以下の処理を実行することも本発明に含まれる。前記第２の処理装置は、前記未処理の処理依頼がある場合（例えば、タイムアウト等の無効化を検出した場合）、当該未処理の要件情報の件数を計数して、前記該当する処理を実行した場合もしくは前記対応する要件情報を取得した場合、前記件数を１減算して、この件数が０を示すまで自身への依頼情報の発行を繰り返すことを可能とする。
【００１１】
ここで、件数の計数は、以下のとおりとしてもよい。まず、要件情報に自身が処理済みか未処理かを示す情報を含ませておき、このうち未処理の要件情報であって、自身が処理すべきものを識別情報等により計数する。より具体的には、以下のとおりとする。「グループコード」を検索条件とする場合はそのプロセスが担当する「グループコード(当該グループを識別する識別子)」での集計，「キー」を検索条件とする場合はそのプロセスが担当する「グループコード」を検索条件として「キー」単位での集計を行って，再送用ＭＱ（依頼情報）にその件数を設定する。（「キー」の場合は，ＭＱは未処理要件があるキーの種類分，送信する）。ここで、未処理の件数を要件データベースの内容から計数しておき、これを記録しておいてもよい（つまり、この記録内容を未処理の件数とする）。
【００１２】
また、要件情報としては、処理済みのものを消去し、未処理のものを要件データベースに残す構成として、残った要件情報の件数をカウントすることで実現することが可能になる。
【００１３】
また、上記の構成において、前記処理依頼および前記依頼情報の少なくとも一方は、一定時間後に自身の効力が消滅(無効化、タイムアウト)する情報であることも本発明に含まれる。また、前記処理依頼および前記依頼情報は、転送キューであってもよい。
【００１４】
さらに、本発明では、いわゆるトランザクション（複数の取引要求）を、所定の単位で分割してそれぞれ各処理(処理のためのサブ業務単位を含む)を並行処理で実行するように構成したものに適用することも含まれる。
【発明の効果】
【００１５】
本発明によれば、処理の回復をより容易に実現することが可能になる。
【発明を実施するための最良の形態】
【００１６】
本発明の実施の形態について、図面を用いて説明する。本実施の形態は、証券(株式)の取引を例に説明するが、本発明はそれに限定されるものではない（他業務などに適用することも本発明に含まれる）。
【００１７】
まず、本実施の形態の基本的な内容について説明する。
（１）通常は、連絡元プロセス（例えば、図１や２の受付装置２）から連絡先プロセス（例えば、図１，２の取引処理装置３）図に対して、処理依頼（例：ＭＱ「転送キュー」）を送信する。ここでは、送り先を装置すなわちハードウエアとしたが、本実施の形態では、ハードは異なる場合もあれば同一の場合も含む。あくまでも、あるプロセス(処理プログラム)から，処理依頼先のプロセスに，要件データベースの登録と処理依頼（ＭＱ）を送信できればよい。例えば、「注文受付」というプロセスは端末グループ数分あり，「取引処理制御１」というプロセスは銘柄グループ数分動作している。「取引処理制御１」は複数の銘柄キーの集合である「銘柄グループ」に括り付いている。「取引処理制御１」という機能名称と，銘柄グループの組合せで１つのプロセスが特定される。サーバとグループが１対１でもよいし、サーバに複数のグループが配置されていてもよい。
（２）連絡先プロセスでは，ＭＱを受信すると，当該MQに対応する要件ＤＢから要件情報(レコード)を１件取得（ＳＥＬＥＣＴ）する。ここで、この取得の方法としては、(a)自身の「グループ」(もしくは自身)を識別する識別子(例えば、グループコード)を用いて行う（MQと要件情報には、それぞれグループコードを含ませるようにする）、(b)取引対象の銘柄を識別する識別子を用いて行う（MQと要件情報には、それぞれ銘柄を識別する識別子を含ませるようにする）。また、要件情報には、連絡元プロセスが処理依頼を発行（もしくは送信など所定の処理であり、要件情報に対する処理であってもよい）を実行した時間の時間情報を、タイムスタンプ機能を用いて含ませておく。そして、この時間情報の順に従って、取得する順序を決定する。例えば、古い順に取得するようにする。
【００１８】
ここで、ＭＱが無効(タイムアウト)になるなどして無効化した場合（もしくは無効化を検出した場合）、連絡先プロセスでは、要件データベースを検索して、未処理の案件（例えば、要件情報）がないかを検知する。この検知は、上記（２）に記載した方法と同様に検索等を行う。より詳細には、以下のとおりである。要件データベースと処理依頼（ＭＱ）双方に，処理依頼先の「グループコード」および「キー」を付与している。連絡先プロセスは，ＭＱＧＥＴでメッセージ（MQ）を取得すると，自プロセスむけのメッセージであることをチェックしてから「グループコード」または「キー」が同一，かつ未処理であることを検索条件として，登録時刻の最も古い要件レコードを要件データベースから検索する。
【００１９】
なお、ＭＱは要件データベースを検索するためのトリガーである。すなわち、ＭＱには，「何を行うか」という情報が示されていなくともよい。「何を行うか」は，要件データベース（の要件情報）に登録されている。要件データベースには，「何を行うか」として例えば対応する注文データ（注文受信データベースなどに記録）などを特定する情報が設定されているので，要件データベースを取得する順序で注文受信データベースの処理を行うことが可能になる（例；取引所で必要な同一銘柄内での注文の処理順序性を確保している）。
【００２０】
（３）次に、連絡先プロセスでは、取得した要件情報に対応する処理を実行するプログラムを起動し、処理を実行する。そして、次プロセス（例えば、約定処理装置）への通知を行う。
【００２１】
次に、本実施の形態におけるシステム構成図を図1に示す。各コンピュータは、ネットワークを介して互いに接続されている。また、各コンピュータは、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。図１に示すように、本実施の形態におけるシステムは、取引端末１、受付装置２、取引処理装置３、約定処理装置４と、取引に関する情報が格納された記憶装置群５から構成される。これら構成要件のそれぞれは、複数から構成されるものであるが、（１）取引端末１はグループとして複数の取引端末をまとめておいてもよい、（２）また、受付装置２、取引処理装置３、約定処理装置４は、ハードウエアとして一体のサーバ装置として構成され、それぞれはその機能を有するソフトウエアとして構成してもよい。また、（２）の場合、受付装置２、取引処理装置３を一体、取引処理装置３、約定処理装置４を一体などとしてもよい。本実施の形態では、図２に示すように約定処理装置４と取引処理装置３を一体とした例で説明する。この図１，２の構成では、各受付装置２（２１，２２）は、取引端末のグループ毎(証券会社など)に対応付けられている。また、各取引処理装置３、各約定処理装置４は（もしくはこれらが一体化された処理装置３１，３２）、処理すべき銘柄毎に対応付けられており、この対応関係の取引要求についての処理を実行する。この対応関係は、装置すなわちハードウエアでなく、ソフトウエアが有するようにしてもよい。さらに、この対応関係は、取引量などの条件に基づいて動的に変更してもよい。すなわち、あるグループからの取引要求やある銘柄の取引要求が(増加して)所定数(量)になった場合、所定の装置（例えば、取引要求の最も少ない同じ種類の装置、コンピュータ資源）をそのグループ(もしくは銘柄)の処理を実行するようにしてもよい。また、同じ種類の装置において、取引要求（もしくはそれに伴う計算量）の関係が一定の関係（差分が閾値以上や１：１０などの所定の関係）を満たすかを検知して、この内容に応じて対応関係を変更する（少ない取引要求の装置を多い取引要求の装置に変える）ことも、本実施の形態に含まれる。このように、分散化処理と組み合わせることで以下の効果を達成することが可能になる。
（１）業務要件である「処理順序性保証」をすることが可能となる。「端末グループ：n→銘柄グループ：m→端末グループ：n」のような流れで、サブ業務を分割しているため、処理順序性確保が問題となりますが、要件DB内の一番古い未処理のものから順に処理するため、処理順序性保証（銘柄グループ単位）が可能になる（銘柄グループ１の要件DBに対して、n個の端末グループから処理要求が発生する）。
（２）障害復旧対象リソースをDBMSのみとすることが可能になる。トランザクションモニタと、DBMSの両方で、回復対象リソースを持ったXA連携（2相コミット）では、Commit処理性能が長くなるため、回復対象リソースをDBMSのみとし、非XA連携としcommit性能を確保することが可能になる。なお、本発明は、ＸＡ連携した場合でも適用可能であることは言うまでもない。
（３）回復時の順序性確保が可能になる。（１）の機能（要件データベース内の一番古い未処理のものから順に処理する）により、障害回復後も、順序性を確保することが可能になる。
なお、サブ業務単位に分散化しないことも本発明に含まれる。
【００２２】
次に、図３を用いて本実施の形態の処理フローについて、説明する。まず、初期処理として、ステップ１００で、プロセスを起動する。以下のステップも含みここでは、取引処理装置３での処理を例に説明する。例えば、本装置で用いるプログラムを起動させる。
【００２３】
次に、ステップ１０１において、MQＧＥＴ、すなわち、処理依頼を取得する。ＭＱは、受付装置２から送信されたもので、所定の記憶装置に格納されている。そして、ＭＱ記憶装置に存在しない場合には、ＭＱＧＥＴの動作がタイムアウトとなる。ここで、ＭＱは予め定めた時間になるとタイムアウトと称して無効化するように制御してもよい。この予め定めた時間としては、プロセスの起動の際は、それ以外の場合に比べて短い時間でタイムアウトになるよう設定してもよい。このように設定することにより、系切替などによって格納されているＭＱが消滅することを防止することが可能になる。なお、起動の際とは、起動してから最初に記憶装置にアクセスすることを含む。
【００２４】
次に、ステップ１０２において、ＭＱＧＥＴ（もしくはＭＱ）がタイムアウトになったかを検知する。タイムアウトになった場合(検知した場合)は、ステップ１０３に進み、自身に対するＭＱ送信を行う。なお、ここで、ＭＱは、要件データベースを検索するためのトリガーであればよく。「何を行うか」という情報が示されていなくともよい。「何を行うか」は，要件データベース（の要件情報）に登録されている。要件データベースには，「何を行うか」として例えば対応する注文データ（注文受信データベースなどに記録）などを特定する情報が設定されている。このように、トリガーとなるもの（かつ所定の条件で無効化されるものならより好適である）であればよく、ＭＱ以外のものであっても構わない。
【００２５】
ここで、ステップ１０３の詳細について、図４を用いて説明する。
まず、ステップ１０３１において、図５に示す要件データベースから未処理の案件（すなわち要件情報）の数を計数する。すなわち、各要件情報のうち、処理済フラグが未処理を示すものを抽出し、そのうち当該取引処理装置が処理すべきことを示す情報（当該取引処理装置の識別情報でもよい）の要件情報の数を計数する。なお、まず、当該取引処理装置が処理すべきことを示す情報（当該取引処理装置の識別情報でもよい）の要件情報を抽出し、その中から処理済みフラグが未処理を示すものを検知してもよい。
【００２６】
次にステップ１０３２において、ステップ１０３１で未処理の案件があるか否かを判断する。この結果、ない場合にはそのままステップ１１５に進み、本ステップ１０３を終了する。ある場合には、ステップ１０３３に進む。
【００２７】
ステップ１０３３において、自身に送信するすなわち再送のＭＱを編集（生成）する。上述したように、ＭＱはトリガーとなればよいので、自身（取引処理装置）であること識別する情報が含まれればよい。但し、より好適には、ＭＱには当該取引処理装置が属するグループ（もしくは取引処理装置自身）を識別するグループコードもしくは対応する要件情報の登録などの処理時間等のキー情報を含めてもよい。また、ここでは、ステップ１０３１で計数された未処理の件数以下の数のＭＱを生成する。より好適には、未処理の件数未満とするとよい。これは、この再送ＭＱによりトランザクションの増加やキュー溢れを防止するためのもので、その数はこれらを考慮して適当に定めてもよい。
【００２８】
そして、ステップ１０３４に進み、再送ＭＱを自プロセス（取引処理装置）に向けて送信する。そして、本処理を終了し(ステップ１０３５)、ステップ１１５に進む。
【００２９】
次に、ステップ１１５に進み、本トランザクションに決着がつけられたことになり、ステップ１０４に進む。ステップ１０４において、ステップ１０１と同様に、処理依頼を取得する。そして、ステップ１０５では、ステップ１０２と同様にタイムアウトしたか否かを検知する。ここでのタイムアウト値は、ステップ１０２でのそれと比べて長くしてもよい。この結果、タイムアウトとなった場合には、ステップ１０６に進みステップ１０３と同様の処理を実行する。
【００３０】
次に、ステップ１０２やステップ１０５で、タイムアウトがないと判断された場合について、説明する。このように判断された場合、ステップ１０７に進む。ステップ１０７では、ステップ１０３や１０６で再送されたＭＱを含み自身に送信されたＭＱを記憶装置から取得する。ここで、取得されたＭＱを格納していた記憶装置から削除する。
【００３１】
次に、ステップ１０８において、ＭＱの取得に対応して、要件データベース（要件ＤＢ）から１件の要件情報を取得する。ここで、１件の要件情報の取得の方法は、ＭＱに含まれるキー情報と、図５に示す要件データベースの内容（キー情報、時間情報(図示せず)）を用いて行う。すなわち、要件情報に含まれる要件情報のうち、処理済フラグが未処理であり、当該取引処理装置で登録が最も古い要件情報を選択する（キー情報やＵＡＰ情報にこれらの情報を含ませて構成することが可能である）。このようにして、要件情報が選択できない場合はステップ１１５に進み、選択した場合はステップ１１０に進む。
【００３２】
次に、ステップ１１０において、選択された要件情報に対応する取引処理を、当該要件情報を用いてアプリケーションプログラムに従って実行する。
【００３３】
このステップ１１０の終了後もしくはステップ１１０と並行して、ステップ１１１〜１１４の処理を実行する。ステップ１１１において、ステップ１００以降の再送ＭＱの数を計数する。これは、ＭＱ内に件数を含ませ、それをカウントすることで実現する。なお、発行の度にカウントし、記録することで行ってもよい。実現可能である。この結果、再送ＭＱが０件の場合、ステップ１１５に進む。０件でない場合には、ステップ１１２に進む。
【００３４】
ステップ１１２では、再送ＭＱの件数が格納された記憶装置から再送件数を１減算するよう演算する。そして、一定時間を経過したかを検知して(ステップ１１３)、その結果した場合にはステップ１１４に進み、ステップ１０３などと同様に再送処理を実行する。なお、ステップ１１３で一定時間を経過したと検知しなかった場合には、ステップ１１５に進む。ここで、一定時間が経過したか否かの確認は、一部の装置の障害やキュー溢れに対応するために監視を行うために実行する。ここでは、再送件数を記憶装置に格納するようにしたが、以下のように構成してもよい。メモリ等への一時的な格納はするが、再送するＭＱに再送件数を含ませる。つまり、ステップ１１２では、ステップ１１１で計数した再送件数から１減算した再送件数を含むＭＱを再送する。
【００３５】
以上の実施の形態の処理によれば、図６および以下に示される効果を達成することが可能になる。要件ＤＢが登録できてさえいれば，要件登録順での業務処理続行可能である。また，ＭＱ再送処理により大幅な遅延なく処理可能になる。特に、以下のような場合に対応が可能になる。（１）一部の参加者（証券会社等）からの多量注文入力などによって，処理依頼元サーバのＭＱのキューあふれが発生したケース、（２）特定の銘柄に注文が集中するなどによって，処理依頼先のＭＱのキューあふれが発生したケース、（３）処理依頼先サーバのダウンなどによって，ＭＱが消失したケース、（４）処理依頼先プロセスのダウンなどによってＭＱが削除されず，結果としてＭＱのキューあふれが発生したケース。
【００３６】
本実施の形態のように、ＭＱをトリガーとして取り扱うことで、
・データベースに蓄積された注文を時間優先順の原則に従って処理する
・レスポンスの高速化と単位時間処理件数の向上
することが可能になる。
【００３７】
そして、本実施の形態による回復処理では，
・特定銘柄への注文集中などによって，ＭＱが部分的に消失してしまった場合でも，極力遅滞なく注文の処理を行うことが可能になる。なお、本実施の形態では、ＭＱ（障害時に回復対象にならない）を含む（永続ＭＱが混在しても構わない）場合に有効である。例えば注文受付プロセスは複数の通信サーバに配置される。この場合、あるサーバでＭＱの転送遅延や，転送途中での障害が発生した際，該当する注文の発注元取引参加者は，他の取引参加者に遅れを取る形になったり，銘柄の取引状態が変化することで不利をこうむったりする恐れがあることを解消できる。
【図面の簡単な説明】
【００３８】
【図１】本実施の形態におけるシステム構成図（１）である。
【図２】本実施の形態におけるシステム構成図（２）である。
【図３】本実施の形態における処理の内容を示すフローチャートである。
【図４】図３において、再送処理の詳細を説明するフローチャートである。常)である。
【図５】要件データベースを示す図である。常終了)である。
【図６】本実施の形態の効果および処理概要を説明する図である。
【符号の説明】
【００３９】
１…取引端末、２…受付装置、３…取引処理装置、４…約定処理装置
【図１】
0004797689.tif 000002
【図２】
0004797689.tif 000003
【図３】
0004797689.tif 000004
【図４】
0004797689.tif 000005
【図５】
0004797689.tif 000006
【図６】
0004797689.tif 000007