(57)【要約】      （修正有）【課題】取引注文どうしを取り合わせるための改良されたシステムおよび方法を提供する。【解決手段】取引注文どうしを取り合わせるためのシステムがメモリおよびプロセッサを有している。メモリは、ある取引製品についての、それぞれがトレーダーと市場センターのうちの少なくとも一つに関連付けられている複数のビッド要求と、その取引製品についてのビッド量と、その取引製品についてのビッド価格とを保存している。プロセッサはその取引製品についてのオファー要求を指定した取引注文を受け取る。その取引注文はさらにその取引製品についてのオファー量およびその取引製品についての目標オファー価格を指定している。プロセッサは前記複数のビッド要求のうちから、前記目標オファー価格以上のビッド価格を有する少なくとも一つを同定する。【選択図】図１
2011170880.tif 000002
【特許請求の範囲】
【請求項１】
命令を記憶している記憶媒体を有する製造物であって、前記命令はプロセッサによって実行されたときに、前記プロセッサに：
前記プロセッサとネットワークを通じて通信するユーザーのリモート装置から、前記プロセッサに結合された受信手段を介して、全量の要求および目標価格の要求を含む取引注文要求を受信する段階と；
前記取引注文要求のうちの第一の量を、複数の取引注文を記憶している内部データベースから取得される少なくとも二つの取引注文と取り合わせる段階であって、前記少なくとも二つの取引注文のそれぞれは前記目標価格を満足し、前記全量の少なくとも一部を満足し、前記複数の取引注文のそれぞれは量、価格およびあらかじめ記憶された優先順位付けを含んでいる、段階と；
前記取引注文要求の前記第一の量を満足する前記少なくとも二つの取引注文のうちの一つを、前記あらかじめ記憶された優先順位付けに基づいて選択する段階と、
前記選択に応答して、前記取引注文要求の残りの量を、前記取引注文要求の前記全量から前記第一の量を引くことによって判別する段階と；
前記データベースの外部のある市場センターが前記残りの量の少なくとも一部を前記目標価格で充足できることを判別する段階と；
前記プロセッサは前記市場センターに送られたペンディング・トランザクションの数を記録しており、前記市場センターがペンティング・トランザクションの所定の最大数を超えていないことを判別する段階と；
前記残りの量を前記市場センターに振り向ける段階とを実行させる、
製造物。
【請求項２】
前記複数の取引注文が以前に受信されたものである、請求項１記載の製造物。
【請求項３】
前記記憶媒体がさらに、前記プロセッサによって実行されたときに、前記プロセッサに：
前記取引注文要求の前記第一の量が前記少なくとも二つの取引注文のうちの前記一つによって充足されたことの指標を、前記プロセッサに結合された送信手段を介して送信する段階を実行させる命令を記憶している、
請求項１記載の製造物。
【請求項４】
前記記憶媒体がさらに、前記プロセッサによって実行されたときに、前記プロセッサに：
前記少なくとも二つの取引注文のうちの前記一つを前記データベースから除去する段階を実行させる命令を記憶している、
請求項１１記載の製造物。
【請求項５】
前記あらかじめ記憶された優先順位付けが、前記複数の取引注文のそれぞれに、オファーされている前記取引製品の量に従って優先順を付けることを含む、請求項１記載の製造物。
【請求項６】
前記少なくとも二つの取引注文のうちの前記一つを選択する前記段階がさらに：
前記少なくとも二つの取引注文のうちの前記一つによってオファーされる取引製品の量が前記取引注文要求の全量に最も近く一致することを判別する段階を含む、
請求項５記載の製造物。
【請求項７】
前記あらかじめ記憶された優先順位付けが、前記複数の取引注文のそれぞれに、前記価格に従って優先順を付けることを含む、請求項１記載の製造物。
【請求項８】
前記少なくとも二つの取引注文のうちの前記一つを選択する前記段階がさらに：
前記少なくとも二つの取引注文のうちの前記一つによってオファーされる価格が前記取引注文要求の前記目標価格に最も近く一致することを判別する段階を含む、
請求項７記載の製造物。
【請求項９】
前記あらかじめ記憶された優先順位付けが、前記複数の取引注文のそれぞれに、トレーダーの素性に基づいて優先順を付けることを含む、請求項１記載の製造物。
【請求項１０】
前記少なくとも二つの取引注文のうちの前記一つを選択する前記段階がさらに：
前記少なくとも二つの取引注文のうちの前記一つオファーするトレーダーの素性が、他のトレーダーよりも上に優先順を付けられるべきであることに基づく、
請求項９記載の製造物。
【請求項１１】
前記あらかじめ記憶された優先順位付けが、トレーダーによってオファーされる取引注文を、市場センターによってオファーされる取引注文よりも上に優先順を付けることを含む、
請求項１記載の製造物。
【請求項１２】
前記記憶媒体がさらに、前記プロセッサによって実行されたときに、前記プロセッサに：
トレーダーおよび前記市場センターの両者が前記取引注文との一致をオファーしていることを判別する段階と；
前記トレーダーを、前記市場センターよりも上に優先順を付ける段階とを実行させる命令を記憶している、
請求項１１記載の製造物。
【請求項１３】
前記残りの量を前記市場センターに振り向ける前記段階がさらに：
前記市場センターによってオファーされる前記取引製品の量に量乗数を適用する段階を含む、
請求項１記載の製造物。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般には電子取引に、より詳細には取引注文どうしを取り合わせるためのシステムに関する。
【背景技術】
【０００２】
近年、電子取引システムは多様な物品、サービス、金融証書および金融商品といった品目の取引について広範に受容されるにいたっている。たとえば、株、証券、通貨、先物契約、石油および金といった金融証書および金融商品の取引を容易にする電子取引システムが作成されている。
【０００３】
こうした電子取引システムの多くはビッド／オファー〔買い注文／売り提示〕プロセスを利用する。ビッドおよびオファーは受動側によってシステムに提出され、次いで行動側がビッドをヒットする〔食いつく〕またはオファーをリフト（またはテイク）する〔受ける〕。たとえば、受動取引当事者はある特定の取引製品を買う「ビッド」を提出しうる。そのようなビッドに反応して、行動側当事者は、その取引製品を第一の当事者に提示価格で売る意向を示すために「ヒット」を提出する。あるいはまた、受動側当事者がその特定の取引製品をその提示価格で売るために「オファー」を提出し、次いで行動側当事者がそのオファーに反応してその受動側当事者から提示価格でその取引製品を買う意向を示すために「リフト」（または「テイク」）を提出することもある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
市場価格は時間とともに――それも一分、一秒ごとに――変化しうる。時間とともに特定の商品を取引したいと思う人は変わりうるし、ビッド／オファーされる量も変わりうる。異なる取引センターはコスト構造も異なることがある。トレーダーはだいたいのところは知っているかもしれないが、センターＡがセンターＢより安いかどうかは取引される量と市場価格、そしてそれに付随するトランザクション費用に依存することがある。取引費用を折り込んでどの市場センターが最も安いかを評価するのは難しいことがある。トレーダーは常習的に市場価格しか考えず、選択プロセスにおいてその他の関連要因を分析から除外してしまいがちである。また、費用は、費用方程式が考量不能および予測不能な要素を含む場合には評価することが不可能なこともある。たとえば取引される製品が所定の時間以内に売れれば費用はかからないが、それまでに取引が完了しなければ取引センターが料金を徴収するなどである。トレーダーが実際上市場価格以外の何物も考えようとさえしないもう一つの理由は、単にかかずらうには難しすぎるということである。そのためトレーダーは「直感」と「感触」を使って取引センターを選ぶことがある。
【０００５】
多くの取引が電話を通じて行われる。トレーダーは個人的、主観的な理由から特定の市場センターに電話することを選ぶことがある。たとえば、電話番号が短縮ダイヤルに登録されていたからとか、ただその組織の評判や普段話す人が気に入ったからとかである。同様に、特定の取引センターを個人的な理由で避けることもある。
【０００６】
また、異なる取引センターは、買い手／売り手の素性および取引量に関して異なる開示規則を有する。この情報は扱いに注意が必要なことがあり、市場の変動を引き起こすことがある。たとえば、Ａ社がＢ社に何百万もの物品または株または証券を売ろうとしているという情報は市場価格および／または取引戦略を変更させることがある。トレーダーは好ましくない開示規則があるためにある特定の取引センターを使わないことに決めるかもしれない。単に「安全策」を取って、問題のない取引分野があるかもしれなくても（たとえば閾値Ｘ未満であれば開示問題がないなど）、どんな取引、どんな取引分野についてもその取引センターを使わない思考態度になっていることもある。また、開示規則は時とともに変わりうるものであり、取引センターによっても変化があるものである。トレーダーは誰しも、情報から取り残されたくない一方、必要のない情報は開示したくない。これは「安全策」を取って最も規則が寛容な取引センターを常習的に利用するもう一つの誘因である。
【０００７】
トレーダーはトランザクションの速度に動かされるが、精確さにも動かされる。これらの要因はトレーダーを異なる方向に引きつける。
【０００８】
現在存在するシナリオは、トレーダーＡは取引センターＢを使うことを好み、取引の多くについてそうしている。これはＡとＢの間の電気通信回線に圧力をかける。取引センターＣが実際にはよりよい条件だったとしても、トレーダーＡは快適地帯を乱すに十分な好条件にならない限り使っている取引センターを切り換えることはないという意味で、一定の慣性がある。それにトレーダーＡがセンターＣのほうが安いということを学ぶには時間的遅延がある。トレーダーＡが使うころにはセンターＣは結局のところ安くはなくなっているということもありうる。条件が同じくらいよい場合には使用度の低い取引センターでの取引を計画することにより、使用度の高いセンターへの電気通信トラフィックのボトルネックを軽減することができる。現在のところ、これはトレーダーの頭の中では考慮の対象になっていないことがある。
【０００９】
取引を成立させることを可能にする既知の取引システム商品が存在している。問題は、人間がリアルタイムで完全に処理するには難しすぎる一つまたは複数の要因に基づいて知的に取引注文を振り向ける装置をいかにして提供するかである。代替的な取引システム商品、前記問題に対する代替的な解決策を提供することが本発明の目的である。他の製品に対して利点のある製品が顧客によって好まれることは自明の理である。よりよい製品を作ることは多くの、おそらくはすべてのメーカーに共通する望みである。製品をよくする一つの方法は、同じまたは匹敵するものをより安く作ることである。製品をよくするもう一つの方法は、機能を高めた製品、競合製品にできない何かをすることのできる製品を作ることである。
【００１０】
本発明の多くの実施形態のねらいは、人間が考慮するには難しすぎるかもしれない多数の要因を使って取引注文に関する決定をすることのできる改良された取引システム製品を提供することである。したがって、取引注文およびその振り向けの速度と精確さが上昇する。より優れた性能を有する、あるいはそもそも競合製品にはできないことができる製品を持つことは、製造業界共通の一般的な望みである。本発明の多くの実施形態を有する製品は、既存の製品が、また人間でさえもがそもそもできないこと、そのような製品の購入者にとって魅力的な利点となること、旧製品の技術的機能を超えたことができる。
【００１１】
本発明の多くの実施形態はこの問題に代替的な解決策を与える。当該製品は従来製品を超える向上した機能を有する：新たな、有用なことをなしうるのである。多くの実施形態については、当該製品はトレーダーにとってよりよい条件を得る可能性をより高くでき、どの取引センターを使うかに関する決断から運と個人的な偏見を除去することもありうる。
【００１２】
本発明によれば、従来の電子取引システムに付随する欠点および問題点は実質的に軽減または解消される。
【課題を解決するための手段】
【００１３】
本発明のある実施形態によれば、取引注文を一つの市場センターに振り向けるためのシステムがメモリおよびプロセッサを有している。メモリは取引製品を指定する取引注文を保存する。プロセッサはその取引製品についての複数の市場センター価格を判別する。各市場センター価格は複数の市場センターのうちの少なくとも一つに結びついている。プロセッサは前記複数の市場センターのうちの一つを判別された市場センター価格に基づいて選択する。プロセッサはさらに選択された市場センターについての開示ポリシーを判別し、その判別された開示ポリシーに従って当該取引注文をその選択された市場センターに振り向ける。
【００１４】
本発明のもう一つの実施形態によれば、取引注文を価格に従って市場センターに振り向けるためのシステムがメモリおよびプロセッサを有している。メモリは複数の市場センターに関連するポリシー情報、費用情報、リベート（ｒｅｂａｔｅ）情報を保存している。プロセッサは取引製品を指定する取引注文、その取引注文についての複数の市場センター価格およびその取引製品についての最良価格情報を受け取る。プロセッサは少なくとも一つの市場センター価格を対応する市場センターの前記ポリシー情報および前記最良価格情報に従って調整する。プロセッサはまた少なくとも一つの市場センター価格を対応する市場センターの前記費用情報および前記リベート情報のうちの少なくとも一つに従って調整する。プロセッサは次いで前記複数の市場センター価格を比較し、少なくとも部分的にその比較に基づいてある特定の市場センターを選択する。
【００１５】
本発明のもう一つの実施形態によれば、取引注文の開示を管理するためのシステムがメモリおよびプロセッサを有している。メモリは諸市場センターに関する開示ポリシーを保存している。プロセッサは、ある取引製品についての取引注文を、該取引製品の全量および該取引製品の最大開示量を指定した形で受け取る。この取引注文はある特定の市場センターに結び付けられている。プロセッサは次いでその取引注文を、その特定の市場センターに結び付けられた開示ポリシーに従ってその特定の市場センターに振り向ける。
【００１６】
本発明のもう一つの実施形態によれば、取引注文に付随するトランザクション費用を回避するためのシステムがメモリおよびプロセッサを有している。メモリはある取引注文に関連付けられた注文識別子とその取引注文に関連付けられた時間閾値を保存している。プロセッサはその取引注文を処理する市場センターに関してその取引注文が有効である時間の長さを監視する。プロセッサはさらにその市場センターに関してその取引注文が有効である時間の長さが前記時間閾値以上になったら時間切れと判定する。プロセッサは次いで、時間切れを判定したのを受け、その取引注文についての取り消し指示を通信する。
【００１７】
本発明のもう一つの実施形態によれば、取引注文を取り合わせるためのシステムがメモリおよびプロセッサを有している。メモリは、ある取引製品についての、それぞれがトレーダーと市場センターのうちの少なくとも一方に関連付けられている複数のビッド要求と、その取引製品についてのビッド量と、その取引製品についてのビッド価格とを保存している。プロセッサはその取引製品についてのオファー要求を指定した取引注文を受け取る。その取引注文はさらにその取引製品についてのオファー量およびその取引製品についての目標オファー価格を指定している。プロセッサは前記複数のビッド要求のうちから、前記目標オファー価格以上のビッド価格を有する少なくとも一つを同定する。プロセッサは、その同定されたビッド要求がトレーダーに関連付けられたものであれば、前記取引注文のオファー要求と前記少なくとも一つの同定されたビッド要求とを取り合わせ、前記少なくとも一つの同定されたビッド要求が特定の市場センターに関連付けられたものであれば、その取引注文をその特定の市場センターに振り向ける。
【００１８】
本発明のさらにもう一つの実施形態によれば、取引注文を取り合わせるためのシステムがメモリおよびプロセッサを有している。メモリはある取引製品についての、それぞれがトレーダーと市場センターのうちの少なくとも一方に関連付けられている複数のオファー要求と、その取引製品についてのオファー量と、その取引製品についてのオファー価格とを保存している。プロセッサはその取引製品についてのビッド要求を指定した取引注文を受け取る。その取引注文はさらにその取引製品についてのビッド量およびその取引製品についての目標ビッド価格を指定している。プロセッサは前記複数のオファー要求のうちから、前記目標ビッド価格以下のビッド価格を有する少なくとも一つを同定する。プロセッサは、その同定されたオファー要求がトレーダーに関連付けられたものであれば、前記取引注文のビッド要求と前記少なくとも一つの同定されたオファー要求とを取り合わせ、前記少なくとも一つの同定されたオファー要求が特定の市場センターに関連付けられたものであれば、その取引注文をその特定の市場センターに振り向ける。
【００１９】
本発明のさまざまな実施形態は多数の利点の恩恵を受けることができる。一つまたは複数の実施形態は以下で議論される利点の一部の恩恵を受けることもあれば、どの恩恵も受けないこともあれば、あるいはすべての恩恵を受けることもある。
【００２０】
一般に、本発明のシステムは、ある取引交換プラットフォーム内の取引注文を内部的に取り合わせ、諸市場センターを使って取引注文を満たし、市場センターに付随するトランザクション費用を回避し、達成可能な最良価格に基づいて特定の市場センターに取引注文を振り向け、取引注文のある種の詳細の市場センターへの開示を管理することによって取引注文の処理を最適化する。
【００２１】
以下の図面、記述および請求項から、当業者にはその他の利点もすぐに明らかとなるであろう。本発明のより完全な理解のため、これから、付属の図面とともに以下の記述を見ていく。
【図面の簡単な説明】
【００２２】
【図１】本発明に基づく取引システムの一つの実施形態を示す図である。
【図２】図１のシステムの価格モジュールの一つの実施形態を示す図である。
【図３】前記価格モジュールによって使用される情報の表を示す図である。
【図４】価格に基づいて取引注文を振り向けるための例示的な方法を示すフローチャートである。
【図５】図１のシステムの費用回避モジュールの一つの実施形態を示す図である。
【図６Ａ】トランザクション費用を回避するための例示的なフローチャートを示す図の一部である。
【図６Ｂ】トランザクション費用を回避するための例示的なフローチャートを示す図の一部である。
【図７】費用回避モジュールによって使用される情報の表を示す図である。
【図８】図１のシステムの規模開示モジュールの一つの実施形態を示す図である。
【図９】費用回避モジュールによって使用される情報の表を示す図である。
【図１０】取引注文の規模開示を管理するための例示的な方法のフローチャートである。
【図１１】注文取り合わせモジュールの一つの実施形態を示す図である。
【図１２】注文取り合わせモジュールによって使用される注文取り合わせログを示す図である。
【図１３】注文取り合わせを実行するための例示的な方法のフローチャートである。
【発明を実施するための形態】
【００２３】
図１は、ネットワーク１６を使用して多様なクライアント１４に結合され、さらに市場センター１８に結合された取引交換プラットフォーム１２を含む取引システム１０の一つの実施形態を示している。一般に、システム１０は、取引交換プラットフォーム１２内の取引注文２０を内部的に取り合わせ、諸市場センター１８を使って取引注文２０を満たし、市場センター１８に付随するトランザクション費用を回避し、達成可能な最良価格に基づいて特定の市場センター１８に取引注文２０を振り向け、取引注文２０のある種の詳細の市場センター１８への開示を管理することによって、取引注文２０の処理を最適化する。
【００２４】
取引注文２０はある特定の量のある特定の取引製品を買う注文（たとえばビッド要求）またはある特定の量のある特定の取引製品を売る注文（たとえばオファー要求）からなる。売り買いされるべき取引製品の量はここでは「全量」と呼ぶ。取引注文２０はさらに、前記全量のうち、任意の所与の時点で市場センター１８に開示してもよい全部または一部を同定する「最大開示量」を指定していてもよい。特定の実施例では、取引注文２０は目標価格（たとえば目標ビッド価格および目標オファー価格）も指定していてもよい。システム１０の以下の記述は株取引に関して詳述されるが、ある所与の取引注文２０の基礎をなす取引製品はいかなる種類の物品、サービス、金融証書、商品などであってもよい。金融証書の例としては、これに限られるものではないが、株、証券および先物契約が含まれる。
【００２５】
クライアント１４は、取引システム１０の取引交換プラットフォーム１２のような一つまたは複数の要素にアクセスするためにトレーダーが使用することのできる、いかなる好適なローカルまたはリモートのエンドユーザー装置であってもよい。たとえば、クライアント１４はコンピュータ、ワークステーション、電話、インターネットブラウザー、電子ノートブック、携帯情報端末（ＰＤＡ）、ポケットベル、またはシステム１０の他の構成要素との間で情報を受信し、処理し、保存し、および／もしくは通信する機能のある他の任意の好適な（無線であってもなくてもよい）装置、コンポーネントまたは要素を有していてもよい。クライアント１４はまた、ディスプレイ、マイク、キーボードまたは特定の構成設定および配置に基づく他の任意の適切な端末装置といった、トレーダーにとっていかなる好適なインターフェースを有していてもよい。ネットワーク１６に結合されているクライアント１４の数はいくつあってもよいことは理解されるであろう。クライアント１４はここでは「トレーダー」によって使用されるものとして記述されるが、「トレーダー」の用語は取引システム１０のいかなるユーザーにも広く適用されることが意図されており、当人に代わって行動する代理人、当人、個人、法人（企業など）またはシステム１０において取引注文２０を出したりおよび／もしくは取引注文２０に反応したりする機能のある任意の機械もしくは機構でよいことを理解しておくべきである。
【００２６】
ネットワーク１６はクライアント１４と取引交換プラットフォーム１２との間でデータまたは情報を交換するよう動作できる通信プラットフォームである。ネットワーク１６は本発明のある特定の実施形態ではインターネット構造を表しており、クライアント１４を操作するトレーダーが取引を電子的に実行したり、取引プラットフォーム１２に配送されるべきトランザクションを開始したりする機能を与える。ネットワーク１６はまた、普通の電話システム（ＰＯＴＳ：  ｐｌａｉｎ  ｏｌｄ  ｔｅｌｅｐｈｏｎｅ  ｓｙｓｔｅｍ）であってもよく、これもトレーダーは同じ操作または機能を実行するために使用できる。あるトランザクションが実行されることを要求するためには、そのようなトランザクションは、交換プラットフォーム１２に関連したブローカーによって支援されてもよいし、電話またはその他の好適な電子的装置に手動で入力されてもよい。他の実施形態では、ネットワーク１６は、システム１０内の任意の２つのノードの間の通信インターフェースまたは交換を提供するいかなるパケットデータネットワーク（ＰＤＮ：  ｐａｃｋｅｔ  ｄａｔａ  ｎｅｔｗｏｒｋ）でもよい。ネットワーク１６はさらに、構内ネットワーク（ＬＡＮ：  ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、都市圏ネットワーク（ＭＡＮ：  ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ）、広域ネットワーク（ＷＡＮ：  ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）、無線構内ネットワーク（ＷＬＡＮ：  ｗｉｒｅｌｅｓｓ  ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）、仮想私設網（ＶＰＮ：  ｖｉｒｔｕａｌ  ｐｒｉｖａｔｅ  ｎｅｔｗｏｒｋ）、イントラネットまたはクライアント１４と交換プラットフォーム１２との間の通信を容易にする他の任意の適切なアーキテクチャもしくはシステムを含んでいてもよい。
【００２７】
市場センター１８は、交換所、電子通信ネットワーク（ＥＣＮｓ：  Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋｓ）、代替取引システム（ＡＴＳｓ：  Ａｌｔｅｒｎａｔｉｖｅ  Ｔｒａｄｉｎｇ  Ｓｙｓｔｅｍｓ）、マーケットメーカーまたは他の任意の好適な市場参加者を含む。各市場センター１８は、市場センター価格とも呼ばれる公開の取引価格で売り買いする準備をして待機し、意向があり、その能力があることによって、ある所与の取引製品におけるビッドおよびオファーの価格を維持している。
【００２８】
取引交換プラットフォーム１２は取引注文２０の振り向け、取り合わせおよびその他の処理を容易にする取引アーキテクチャである。交換プラットフォーム１２は、注文２０の取引を管理しようとする任意の個人、企業またはエンティティのための管理センターまたは本部事務所を含みうる。従って、交換プラットフォーム１２は、取引環境の経営的管理または行政的管理を行う行政的管理団体または監督エンティティの作用および機能を達成するために利用または実装されうるハードウェア、ソフトウェア、人員、装置、コンポーネント、要素またはオブジェクトのいかなる好適な組み合わせを含んでいてもよい。ここに記載される特定の実施形態では、取引交換プラットフォーム１２は，交換プラットフォーム１２いくつかのインターフェース、モジュールおよびデータベースを含む。
【００２９】
ネットワーク１６に結合されたクライアントインターフェース３０はクライアント１４と交換プラットフォーム１２のさまざまな構成要素との間の通信をサポートしている。ある特定の実施形態では、クライアントインターフェース３０は、クライアント１４によって通信された取引注文２０を受信するトランザクションサーバーを有している。
【００３０】
注文さばきモジュール３２はクライアントインターフェース３０に結合されており、交換プラットフォーム１２内でいくつかの注文さばきタスクを実行する。特に、注文さばきモジュール３２はデータベース５０に取引注文２０を記録し、取引注文２０をさらなる処理のために交換プラットフォーム１２内のさまざまな他のモジュールまたはインターフェースに振り向ける。市場センターインターフェース３４は交換プラットフォーム１２と市場センター１８との間の通信をサポートする。
【００３１】
異なる市場センター１８は、特定の取引製品について異なる市場センター価格を提供する。たとえば、ある特定の市場センター１８はある特定のビッド価格および／またはオファー価格をある特定の取引製品について提供する一方、別の市場センター１８は異なるビッド価格および／またはオファー価格をその同じ取引製品について提供することがある。価格モジュール３８は、ある特定の取引注文２０を振り向けるべき特定の市場センター１８を、その特定の取引注文２０について得ることのできる最良の市場センター価格に基づいて選択する。これについては図２〜４を参照しつつより詳細に説明する。特定の実施例では、価格モジュール３８は、特定の市場センター１８を選択するのに先立って、取引製品の市場センター価格を費用情報、リベート情報および／または市場センター１８に関連付けられている最良価格情報に従って調整する。これについてものちにより詳細に説明する。
【００３２】
特定の市場センター１８は、ある期間を超えて注文帳に残っている取引注文２０を実行するためにはトランザクション費用を課す。費用回避モジュール４０は、こうした種類の市場センター１８に関して仕掛かりになっている取引注文２０をこうしたトランザクション費用を回避するために管理する。これについては図５〜７を参照しつつより詳細に説明する。
【００３３】
異なる市場センター１８は、取引注文２０について該取引注文２０の規模などさまざまな詳細のマーケットメーカーへの開示に関して異なるポリシーを採用してきた。規模開示モジュール４２は取引注文２０のさまざまな詳細の市場センター１８への開示を、そうした市場センター１８によって採用されている開示ポリシーに基づいて管理する。これについては図８〜１０を参照してより詳細に説明する。
【００３４】
注文取り合わせモジュール４４は、取引注文２０の取り合わせを取引交換プラットフォーム１２内で内部化する。これについては図１１〜１３を参照してより詳細に説明する。これに関し、注文取り合わせモジュール４４は、ある取引製品についてはいってくるビッド要求を指定した取引注文２０を、その取引製品についての保存されている一つまたは複数のオファー要求と取り合わせることがある。同様に、取り合わせモジュール４４は、ある取引製品についてはいってくるオファー要求を指定した取引注文２０を、その取引製品についての保存されている一つまたは複数のビッド要求と取り合わせることもある。
【００３５】
取引交換プラットフォーム１２を参照して上述した各モジュールは、そのモジュールの記載された機能または作用を提供するためのハードウェアおよびソフトウェアのいかなる好適な組み合わせを有していてもよい。たとえば、モジュールは、プログラム命令ならびに該プログラム命令を実行するための付随するメモリおよび処理コンポーネントを含んでいてもよい。また、図１に示した諸モジュールおよびそれに関する作用は、他のモジュールから別個でもよいし、統合されていてもよい。さらに、モジュール３８、４０、４２、４４のそれぞれは、個別の必要および希望に応じて互いと一緒に動作してもよいし、あるいはスタンドアローン・ベースで動作してもよい。
【００３６】
データベース５０は一つまたは複数のファイル、リスト、表または情報のその他の配列を有している。それが保存されるのは、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、磁気コンピュータディスク、ＣＤ−ＲＯＭもしくはその他の磁気式もしくは光学式記憶媒体または他の任意の揮発性もしくは不揮発性記憶装置の一つもしくは複数のコンポーネントであってよい。図１はデータベース５０を取引交換プラットフォーム１２内部にあるように示しているが、データベース５０は個別の実装によって、システム１０のコンポーネントの内部にあっても外部にあってもいいことは理解しておくべきである。また、図１に示されているデータベース５０は、システム１０内で使用するためのデータベースの任意の好適な構成を達成するための他のデータベースと別個であってもそれらと統合されていてもよい。データベース５０は取引注文２０および関連付けられた注文識別子５２（たとえば内部注文識別子および外部注文識別子）、時間閾値５４および注文状態情報５６ならびに市場センター１８に関連する情報５８（たとえば最良価格ポリシー情報、費用情報、リベート情報、開示ポリシー情報）ならびに注文取り合わせログ６０を保存している。
【００３７】
取引交換プラットフォーム１２およびそれに付随するインターフェース、モジュールおよびデータベースの内部構造が順応性のあるもので、意図された動作を達成するために容易に変更、修正、再配列または再構成できることを注意しておくべきだろう。
【００３８】
価格サーバー７０は取引交換プラットフォーム１２に価格情報を提供する。価格情報は市場センター価格、最良ビッド価格（たとえば、ある取引製品を買うためにある市場センター１８が払う意向のある最高価格）、および最良オファー価格（たとえば、ある取引製品を売るためにある市場センター１８が受け取る意向のある最低価格）を含みうる。最良ビッド価格および最良オファー価格はまとめて最良価格情報と称される。特定の実施形態では、価格サーバー７０は市場センター１８から価格情報を受け取る。別の実施形態では、価格サーバー７０は一つまたは複数の市場データベンダー７２から価格情報を受け取る。
【００３９】
〈価格モジュール〉
図２は、データベース５０と価格サーバー７０に結合された価格モジュール３８の一つの実施形態を示している。価格モジュール３８が取引交換プラットフォーム１２およびシステム１０の他の要素と別に示されているのは単に説明のためであって、価格モジュール３８がここに記載される動作を実行するためにシステム１０の一つまたは複数の他のコンポーネントと相互運用できることは理解しておくべきである。価格モジュール３８によって実行されるさまざまな動作を明確にするため、適宜、図３を参照することにする。
【００４０】
価格モジュール３８は、ある特定の量のある特定の取引製品を買う注文（たとえばビッド要求）またはある特定の量のある特定の取引製品を売る注文（たとえばオファー要求）を含む取引注文２０を受け取る。しかし、取引注文２０はそれがどの市場センター１８に振り向けられるかについては指定していない。価格モジュール３８は、当該取引注文２０が潜在的に振り向けられうる特定の諸市場センター１８を同定する。たとえば表１００を示している図３を参照すると、価格モジュール３８は、価格モジュール３８が受け取った取引注文２０と取り合わされる可能性のある市場センター１８を５つ同定しうる。表１００に示されるように、候補となる市場センター１８はＡＲＣＡ、ＩＳＬＤ、ＮＩＴＥ、ＭＷＳＥおよびＢＲＵＴを含むことができる。
【００４１】
図２に戻ると、価格モジュール３８は、取引注文２０の基礎になる取引製品について市場センター価格１０２を価格サーバー７０から受け取る。表１００に示されているように、市場センター価格１０２はビッド価格×オファー価格の形に整形されうる。市場センター価格１０２は、当該取引注文２０の基礎になる取引製品の一部の指定量について有効であることもあれば、あるいはあらゆる指定量について有効であることもある。さらに、各市場センター１８は特定の取引製品について異なる市場センター価格１０２を有しうる。
【００４２】
価格モジュール３８はまた、その取引製品についての最良価格１０４を価格サーバー７０から受け取る。最良価格１０４はその取引製品についてすべての市場センター１８のうちで得られる最良のビッド価格１０４および最良のオファー価格１０４を表している。たとえば、最良ビッド価格１０４は、いずれかの市場センター１８がその取引製品を買うときに支払う用意のある最高価格である。最良オファー価格１０４はいずれかの市場センター１８がその取引製品を売るときに受け取る用意のある最低価格である。ここに記載される例では、当該取引製品についての最良価格１０４はＢＲＵＴ×ＢＲＵＴで、９．５００×１０．０００である。
【００４３】
価格モジュール３８は、市場センター情報５８および最良価格１０４に基づいて市場センター価格１０２に一つまたは複数の調整を実行する。市場センター情報５８は最良価格ポリシー１０６、費用情報１０８およびリベート情報１１０を含みうる。各市場センター１８の最良価格ポリシー１０６は、その市場センター１８が最良価格１０４に反応して何をするかを示す。たとえば、市場センター１８は最良価格１０４に合わせたり、最良価格１０４の中を取ったり、あるいは最良価格１０４を無視したりすることができる。費用情報１０８は、その取引注文２０を処理するためにある特定の市場センター１８が課すトランザクション費用を指定する。リベート情報１１０は、その取引注文２０を処理するためにある特定の市場センター１８が与えるトランザクションリベートを指定する。したがって、価格モジュール３８は市場センター価格１０２をこれらの要因に基づいて調整することにより、各市場センター１８について調整市場センター価格１１２を決定する。
【００４４】
たとえば表１００を参照すると、価格モジュール３８はＡＲＣＡについての市場センター価格１０２として９．２５０×１０．０１０を受け取り、ＡＲＣＡは最良価格１０４を顧慮せず、トランザクション費用として０．００３ドルを課し、取引注文２０の処理に対して何のリベートも出さないことを判別する。価格モジュール３８はしたがって、ＡＲＣＡについての調整市場センター価格１１２を９．２４７×１０．０１３であると決定する。
【００４５】
ＩＳＬＤに関しては、価格モジュール３８は市場センター価格１０２として９．２６０×１０．０２０を受け取り、ＩＳＬＤは最良価格１０４を顧慮せず、トランザクション費用を課さず、取引注文２０の処理に対して０．００３ドルのリベートを出すことを判別する。価格モジュールはしたがって、ＩＳＬＤについての調整市場センター価格１１２を９．２６３×１０．０１７と決定する。
【００４６】
ＮＩＴＥに関しては、価格モジュール３８は市場センター価格１０２として９．０００×１０．０５０を受け取り、ＮＩＴＥは最良価格１０４すなわち９．５００×１０．０００に合わせると判定する。最良価格１０４に合わせることによって、価格モジュール３８はＮＩＴＥのビッド価格１０２を最良ビッド価格１０４の９．５００に設定し、ＮＩＴＥのオファー価格１０２を最良オファー価格の１０．０００に設定する。価格モジュール３８はＮＩＴＥがトランザクション費用も課さなければ取引注文２０の処理に対してトランザクションリベートも出さないことを判別する。結果として、価格モジュール３８はＮＩＴＥについての調整市場センター価格１１２を９．５００×１０．０００と決定する。
【００４７】
ＭＷＳＥに関しては、価格モジュール３８は９．０００×１０．０６０の市場センター価格１１２を受け取り、ＭＷＳＥが最良価格１０４の中を取ることを判別する。最良価格は９．５００×１０．０００である。最良価格１０４の中を取ることによって、価格モジュール３８はＭＷＳＥのビッド価格１０２およびオファー価格１０２を、最良ビッド価格１０４と最良オファー価格１０４の平均値である９．７５０に設定する。価格モジュール３８はＭＷＳＥが０．００１ドルをトランザクション費用として課すが、取引注文２０の処理について何のリベートも出さないことを判別する。結果として、価格モジュール３８はＭＷＳＥについての調整市場センター価格１１２を９．７４９×９．７５１と決定する。
【００４８】
ＢＲＵＴに関しては、価格モジュール３８は市場センター価格１０２として９．５００×１０．０００を受け取り、ＢＲＵＴは最良価格１０４を顧慮せず、トランザクション費用として０．００４ドルを課し、取引注文２０の処理に対して何らのリベートも出さないことを判別する。したがって、価格モジュールはＢＲＵＴについての調整市場センター価格１１２を９．４９６×１０．００４と決定する。
【００４９】
調整市場センター価格１１２および価格モジュール３８が取引注文２０のどちらの側に立って処理しているか（たとえばビッドかオファーか）に基づいて、価格モジュール３８はさまざまな市場センター価格１１２を比較し、最良市場センター価格１１２が得られる市場センターを同定する。たとえば、取引注文２０がある取引製品についてのビッド要求を指定していた場合、価格モジュール３８はその取引製品について最低のオファー価格１１２を提供する市場センター１８を同定する。この場合、価格モジュール３８は９．７５１というオファー価格１１２に対応するＭＷＳＥを選択し、ＭＷＳＥに取引注文２０を振り向ける。取引注文２０がその取引製品についてオファー要求を指定していた場合には、価格モジュール３８はその取引製品について最高ビッド価格１１２を提供する市場センター１８を同定する。この場合、価格モジュール３８は９．７４９というビッド価格１１２に対応するＭＷＳＥを選択する。
【００５０】
上記では市場センター価格１０２は、最良価格１０４ならびに最良価格ポリシー１０６、費用情報１０８およびリベート情報１１０に応じて調整されるものとして記述されているが、価格モジュールが市場センター価格１１２を決定するために市場センター価格１０２を調整するのは、これらの要因のうちの一部を使ってでも全部を使ってでもよい。たとえば、価格モジュール３８は市場センター価格１０２を調整するのに最良価格１０４および最良価格ポリシー１０６は使うが費用情報やリベート情報１１０は使わないということもありうる。さらに、価格モジュール３８が市場センター価格１０２を調整するのに、費用情報１０８および／またはリベート情報１１０は使うが、最良価格１０４や最良価格ポリシー１０６は使わないということもありうる。
【００５１】
図４は、価格に基づいて取引注文２０を市場センター１８に振り向けるための例示的な方法のフローチャート１５０を示している。本方法は、ステップ１５２で価格モジュール３８が取引注文２０を受け取ることで始まる。価格モジュール３８はステップ１５４で、取引注文２０の根底にある取引製品についてのさまざまな市場センター価格１０２を受け取る。価格モジュール３８はステップ１５６で、最良価格に従って市場センター価格１０２の調整をすべきかどうかを判別する。すべきであれば、実行はステップ１５８に進んで価格モジュール３８は最良価格１０４を受け取る。最良価格１０４は最良ビッド価格１０４および／または最良オファー価格１０４を含みうる。
【００５２】
価格モジュール３８はステップ１６０で市場センター１８の最良価格ポリシー１０６を判別する。特定の実施例では、最良価格ポリシー１０６は市場センター情報５８の一部としてデータベース５０に保存される。価格モジュール３８はステップ１６２で市場センター価格１０２をしかるべく調整する。具体的には、ある特定の市場センター１８が最良価格１０４を顧慮しない場合には、価格モジュール３８はその市場センター１８についての市場センター価格１０２を調整しない。ある特定の市場センター１８が最良価格１０４に合わせる場合には、価格モジュール３８はその市場センター１８のビッド価格１０２を最良ビッド価格１０４に設定し、その市場センター１８のオファー価格１０２を最良オファー価格１０４に設定する。ある特定の市場センター１８が最良価格１０４の中を取る場合には、価格モジュール３８はその市場センター１８のビッド価格１０２およびオファー価格１０２を最良ビッド価格１０４と最良オファー価格１０４の平均値に設定する。
【００５３】
ステップ１６２で市場センター価格１０２を調整したら、あるいはステップ１５６で市場センター価格１０２を最良価格１０４に基づいて調整しないと判別された場合には、実行はステップ１６４に進み、価格モジュール３８は、市場センター価格１０２を費用情報１０８および／またはリベート情報１１０に基づいて調整するかどうかを判別する。すべきである場合、実行はステップ１６６に進み、価格モジュール３８はさまざまな市場センター１８についての費用情報１０８および／またはリベート情報１１０を判別する。特定の実施例では、情報１０８および１１０は市場センター情報５８の一部としてデータベース５０に保存される。
【００５４】
価格モジュール３８はステップ１６８で市場センター価格１０２を調整する。特に、ある特定の市場センター１８が取引注文２０の処理についてトランザクション費用を課す場合、価格モジュール３８はそのトランザクション費用をその特定の市場センター１８のビッド価格１０２から差し引き、そのトランザクション費用をその特定の市場センター１８のオファー価格に上乗せする。ある特定の市場センター１８が取引注文２０の処理に対してトランザクションリベートを出す場合には、価格モジュールはそのトランザクションリベートをその特定の市場センター１８のビッド価格１０２に上乗せし、そのトランザクションリベートをその特定の市場センター１８のオファー価格１０２から差し引く。価格モジュール３８がステップ１６２で先に市場センター価格１０２を調整していた場合には、ステップ１６８では価格モジュール３８はその先に調整された市場価格をさらに調整する。
【００５５】
ステップ１６８で市場センター価格１０２を調整したら、あるいはステップ１６４で市場センター価格１０２を費用情報１０８および／またはリベート情報１１０に基づいて調整しないと判別された場合には、実行はステップ１７０に進み、価格モジュール３８はさまざまな調整市場センター価格１１２を比較する。特に、価格モジュール３８は、取引注文２０がビッド要求を指定している場合には取引製品についての最低オファー価格１１２を同定する。価格モジュール３８は、取引注文２０がオファー要求を指定している場合には取引製品についての最高ビッド価格１１２を同定する。市場センター価格１０２がステップ１６２でもステップ１６８でも調整されていない場合には、価格モジュール３８はステップ１７０では市場センター価格１０２を比較する。
【００５６】
実行はステップ１７２に進み、価格モジュール３８はステップ１７０で実行された比較に基づいて市場センター１８を選択する。特に、価格モジュール３８は、最低オファー価格１１２および／または最高ビッド価格１１２を提供する市場センター１８のそれぞれを同定する。二つ以上の市場センター１８が該当する場合には、価格モジュール３８は市場センター１８の所定の〔あらかじめ確立された〕優先順（pre-established  priority  ranking）に従って、あるいは他の決定要因に従ってある特定の一つの市場センター１８を選択することができる。
【００５７】
ある種の事例では、二つ以上の市場センター１８が最低オファー価格１１２または最高ビッド価格１１２を提供することがある。そうした事例では、モジュール３８は、取引注文２０によって指定された量以上の量の当該取引製品に対して最低オファー価格１１２または最高ビッド価格１１２を提供する市場センター１８を同定することができる。モジュール３８は次いで同定された市場センター１８の一つを選択する。
【００５８】
ステップ１７４では、取引交換プラットフォーム１２が取引注文２０を選択された市場センター１８に振り向ける。特定の実施例では、価格モジュール３８の作用の前または後のどちらかに、取引交換プラットフォーム１２の別のモジュールが取引注文２０の処理を実行する。したがって、交換プラットフォーム１２に付随する他のモジュール、あるいは市場センターインターフェース３４でさえもが、価格モジュール３８の代わりに取引注文２０の振り向けを行うことがありうることを理解しておくべきである。本方法はステップ１７６で終了する。
【００５９】
図４のフローチャートやここに示される他のフローチャートに記載された諸ステップは、本開示の範囲から外れることなく、同時に実行されてもよいし、および／または示されているのとは異なる順序で実行されてもよいことは理解しておくべきである。
【００６０】
〈費用回避モジュール〉
図５は、データベース５０および価格サーバー７０に結合された費用回避モジュール４０の一つの実施形態を示している。費用回避モジュール４０が取引交換プラットフォーム１２およびシステム１０の他の要素と別に示されているのは単に説明のためであって、費用回避モジュール４０がここに記載される動作を実行するためにシステム１０の一つまたは複数の他のコンポーネントと相互運用できることは理解しておくべきである。
【００６１】
費用回避モジュール４０は、ある選択された市場センター１８に振り向けられようとしている取引注文２０に関する情報を受け取る。いくつかの事例では、前記選択された市場センター１８は、取引注文２０がその選択された市場センター１８の注文帳にある長さの期間を超えて残っていた場合にはその取引注文２０を遂行するためにトランザクション費用を課すことがある。たとえば、ＮＹＳＥおよびＡＭＥＸは、５分未満で遂行できる注文については何らフロア仲介手数料を課さない。しかし、いずれも５分を超えて注文帳にあった注文を遂行するためには手数料を課す。費用回避モジュール４０は、選択された市場センター１８の素性についての情報と取引注文２０の詳細は価格モジュール３８から受け取りうる。費用回避モジュール４０は、選択された市場センター１８によって課されるトランザクション費用の額とタイミングについての情報は価格モジュール３８と価格サーバー７０の一方または両方から受け取りうる。
【００６２】
これらのトランザクション費用を回避するため、費用回避モジュール４０は「取り消しおよび差し替え」動作を実行する。具体的には、費用回避モジュール４０は取引注文２０が上記のようなトランザクション費用を課す市場センター１８について有効である時間の長さを監視する。費用回避モジュール４０はそのような監視を、その取引注文２０がその市場センター１８について有効であるという確認２００を受け取るのに反応して開始しうる。費用回避モジュール４０が確認２００を受け取るのは、プラットフォーム１２のいかなる好適なコンポーネントからであってもよいし、あるいは特定の市場センター１８から直接であってもよい。
【００６３】
費用回避モジュール４０は、前記取引注文２０が前記市場センター１８について有効である時間の長さがある関連付けられた時間閾値５４以上になったときに時間切れと判定する。時間閾値５４が指定するのは、特定の市場センター１８がトランザクション費用を課さずに取引注文２０を処理する時間の長さよりも、緩衝時間とも呼ばれるある所定の時間だけ短い時間の長さである。たとえば、市場センター１８が５分を超えて注文帳で有効になっている取引注文２０を維持するためにトランザクション費用を課す場合、費用回避モジュール４０は取引注文２０が有効になってから４分５０秒たったときに時間切れと判定しうる。なお、時間閾値５４は、取引注文２０を処理している市場センター１８に関連付けられている。
【００６４】
ここでさらに述べるように、取引注文２０を取り消して差し替えるのに十分な緩衝時間を提供するために選択される時間閾値５４はいかなる好適な値であってもよい。したがって、時間閾値５４は上記では５分の期限でトランザクション費用が課される前に１０秒のバッファを維持するよう４分５０秒として述べたが、特定の必要性または希望に従ってより短いまたはより長い時間閾値５４を選択してもよい。たとえば、特定の実施例では、自動的に取り消し／差し替え動作を実行するための時間閾値５４は、３０秒に（または他のいかなる好適な時間期間にでも）設定されうる。
【００６５】
時間切れと判定するのに反応して、費用回避モジュール４０は、適切な市場センター１８の注文帳の有効状態から取引注文２０を実効的に除く取引指示２０２を通信する。費用回避モジュール４０はまた、注文情報２０４を通信することもする。これは本質的には、たった今取り消された取引注文２０と同じパラメータをもつ新たな取引注文２０である。こうして、古い取引注文２０は取り消されて新しい取引注文２０で差し替えられる。費用回避モジュール４０は、上述した取り消しおよび差し替え動作を管理するために、注文識別子５２（たとえば内部注文識別子および外部注文識別子）を維持する。
【００６６】
取り消し指示２０２および注文指示２０４はそれぞれ、適切な市場センター１８に最終的に通信するため、取引交換プラットフォーム１２の市場センターインターフェース３４のような一つまたは複数のコンポーネントに通信されうる。あるいはまた、指示２０２および２０４の一方または両方が費用回避モジュール４０から直接適切な市場センター１８に通信されてもよい。特定の実施例では、指示２０２および２０４は実質同時に通信されてもよく、あるいは同一メッセージ中で通信されてもよい。
【００６７】
上記の取り消しおよび差し替え動作は、最初の取引注文２０に市場センター１８の注文帳での位置を失わせることになるが、市場センター１８によって課されるトランザクション費用を削減する。
【００６８】
図６Ａおよび６Ｂは、市場センター１８による取引注文２０の処理の間にトランザクション費用を回避するための例示的な方法のフローチャート２１０を示している。費用回避モジュール４０によって実行されるさまざまな動作を明確にするために、適宜、図７を参照することにする。本方法は、ステップ２１２において費用回避モジュール４０が特定の取引注文２０についての情報を受け取ることで始まる。その情報は取引注文２０の諸パラメータ、その取引注文２０が振り向けられようとしている特定の市場センター１８の素性およびこの市場センター１８が、取引注文２０が注文帳にある長さの時間を超えて残っている場合にはその取引注文２０を遂行するためにトランザクション費用を課すという指標を含みうる。
【００６９】
費用回避モジュール４０はステップ２１４において時間閾値５４を決定する。実行はステップ２１６および２１８に進み、費用回避モジュール４０は取引注文２０についてそれぞれ外部注文識別子５２ａおよび内部注文識別子５２ｂを設定する。費用回避モジュール４０はステップ２２０で注文状態５６をペンディングに設定する。たとえば図７の表２０６を参照すると、費用回避モジュール４０は外部注文識別子５２ａおよび内部注文識別子５２ｂを、行２０８ａで示されているように「１」に設定する。費用回避モジュール４０はさらに、時間閾値５４を「４：５０」に決定し、注文状態をペンディング（ｐｅｎｄｉｎｇ）の「Ｐ」に設定する。
【００７０】
フローチャート２１０に戻ると、費用回避モジュール４０はステップ２２２で確認２００を受け取る。確認２００は取引注文２０が市場センター１８のところで有効になっていることを示す。モジュール４０はステップ２２４でタイマーをスタートさせ、取引注文２０がその市場センター１８のところで有効である時間の長さの監視を開始する。モジュール４０はステップ２２６で取引注文２０についての注文状態５６を、表２０６の行２０８ｂで示されているように有効（ａｃｔｉｖｅ）に設定する。
【００７１】
費用回避モジュール４０はステップ２２８で注文２０がその市場センター１８によって満たされたかどうかを判定する。ある実施例では、費用回避モジュール４０は注文２０が満たされたということを示すメッセージを受け取る。このメッセージは内部注文識別子５２ｂを使って注文２０を同定する。
【００７２】
ステップ２２８の判定により注文が満たされていなければ、実行はステップ２３０に進み、費用回避モジュール４０は注文２０が取り消されているかどうかを判定する。ある実施例では、費用回避モジュール４０は、トレーダーによって生成される、注文２０の取り消しを要求する取り消し要求のようなメッセージを受け取る。このメッセージは外部注文識別子５２ａを使って注文２０を同定する。
【００７３】
ステップ２３０の判定により注文が取り消されていなければ、実行はステップ２３２に進み、費用回避モジュール４０は注文２０が打ち切られたかどうかを判定する。ある実施例では、費用回避モジュール４０は、注文２０が打ち切られたことを示す「ＵＲ  ＯＵＴ」のようなメッセージを受け取る。このメッセージは内部注文識別子５２ｂを使って注文２０を同定する。
【００７４】
ステップ２３２の判定で注文が打ち切られていなければ、実行はステップ２３４に進んで費用回避モジュール４０は時間切れが生じたかどうかを判定する。具体的には、モジュール４０が時間切れと判定するのは、たとえばステップ２２４でスタートされたタイマーによって測定されるところの取引注文２０がその市場センター１８のところで有効である時間の長さが、ステップ２１４で決定された時間閾値５４以上になるときである。ステップ２３４の判定で時間切れが生じていなければ、実行はステップ２２８に戻る。ステップ２３４の判定により時間切れが生じていれば、実行はステップ２３６に進む。
【００７５】
ステップ２３６では、費用回避モジュール４０は注文状態５６を、表２０６の行２０８ｃで示されているようなペンディングに設定する。モジュール４０はステップ２３８で取り消し指示２０２を送り、ステップ２４０で注文指示２０４を送る。フローチャート２１０は指示２０２および２０４が時間的に逐次送られるように示しているが、これらが実質的に同時に送られても、および／または単一のメッセージもしくは通信において送られてもよいことは理解しておくべきである。取り消し指示２０２は、市場センター１８の注文帳の有効状態から取引注文２０を実効的に除く。注文指示２０４は、本質的には、たった今取り消された取引注文２０と同じパラメータをもつ新たな取引注文２０である。こうして、費用回避モジュール４０は「取り消しおよび差し替え」動作を実行する。
【００７６】
費用回避モジュール４０は新しい内部注文識別子５２ｂを新しい取引注文２０に関連付けるべく割り当てる。表２０６の行２０８ｄを参照すると、新しい内部注文識別子５２ｂは「２」であり、これはもとの外部注文識別子５２ａの「１」と相互対応している。実行はステップ２２０に戻って、モジュール４０は注文状態５６をペンディングに設定する。
【００７７】
ステップ２２２で新しい取引注文２０に対応する確認２００を受け取ると、モジュール４０はステップ２２４でタイマーをスタートさせ、ステップ２２６で注文状態５６を有効に設定する。こうしてモジュール４０は、新しい取引注文２０がその市場センター１８の注文帳で有効である時間の長さの監視を開始する。表２０６の行２０８ｅは新しい取引注文２０の注文状態５６が有効であることを示している。
【００７８】
実行は再びステップ２２８、２３０および２３２と進んで注文が満たされたか、取り消されたか、打ち切られたかが判定される。ステップ２２８で、たとえば注文２０が満たされたことを示す市場センター１８からのメッセージに反応するなどして取引注文２９が満たされたと判定された場合、実行はステップ２５０に進む。ステップ２５０ではモジュール４０は満たされた注文２０に関連付けられた内部注文識別子５２ｂを同定する。上述したように、識別子５２ｂは注文２０が満たされたことを示す市場センター１８からのメッセージによって指定されうる。ステップ２５２では、モジュール４０は、ステップ２５０で同定された内部注文識別子５２ｂに対応する外部注文識別子５２ａを決定する。たとえば、モジュール４０は、外部注文識別子５２ａと内部注文識別子５２ｂとの間の適切な相互対応を決定するために表２０６の行２０８ｅを参照することができる。モジュール４０はステップ２５４で、トレーダーに通信するための、注文２０が満たされていることを示す状態メッセージを送る。この状態メッセージは、取引注文２０をトレーダーに対して同定するために外部注文識別子５２ａを使う。実行はステップ２８０で終了する。
【００７９】
ステップ２３０で、たとえば注文２０の取り消しを要求するトレーダーからのメッセージに反応するなどして取引注文２０が取り消されていると判定された場合には、実行はステップ２６０に進む。ステップ２６０では、モジュール４０は取り消された注文２０に関連付けられている外部注文識別子５２ａを同定する。上述したように、識別子５２ａは、注文２０の取り消しを要求するトレーダーからのメッセージによって指定されうる。ステップ２６２では、モジュール４０は、ステップ２６０で同定された外部注文識別子５２ａに対応する内部注文識別子５２ｂを決定する。たとえば、モジュール４０は、外部注文識別子５２ａと内部注文識別子５２ｂとの間の適切な相互対応を決定するために表２０６の行２０８ｅを参照してもよい。モジュール４０は、ステップ２６４で、市場センター１８に通信するための取り消し指示２０２を送る。取り消し指示２０２は、市場センター１８の注文帳の有効状態から取引注文２０を実効的に除く。この取り消し指示２０２は、取引注文２０を市場センター１８に対して同定するために内部注文識別子５２ｂを使う。実行はステップ２８０で終了する。
【００８０】
ステップ２３２で、たとえば注文２０の一部または全部が打ち切られることを示す市場センター１８からのメッセージに反応するなどして取引注文２０が打ち切られたと判定された場合、実行はステップ２７０に進む。ステップ２７０では、モジュール４０は打ち切られた注文２０に関連付けられた内部注文識別子５２ｂを同定する。上述したように、識別子５２ｂは注文２０が打ち切られたことを示す市場センター１８からのメッセージによって指定されうる。ステップ２７２では、モジュール４０は、ステップ２７０で同定された内部注文識別子５２ｂに対応する外部注文識別子５２ａを決定する。たとえば、モジュール４０は、外部注文識別子５２ａと内部注文識別子５２ｂとの間の適切な相互対応を決定するために表２０６の行２０８ｅを参照してもよい。モジュール４０は、ステップ２７４で、トレーダーに通信するための、注文２０の一部または全部が打ち切られていることを示す状態メッセージを送る。この状態メッセージは、取引注文２０をトレーダーに対して同定するために外部注文識別子５２ａを使う。実行はステップ２８０で終了する。
【００８１】
〈規模開示モジュール〉
図８は、データベース５０に結合された規模開示モジュール４２の一つの実施形態を示している。規模開示モジュール４２が取引交換プラットフォーム１２およびシステム１０の他の要素と別に示されているのは単に説明のためであって、規模開示モジュール４２がここに記載される動作を実行するためにシステム１０の一つまたは複数の他のコンポーネントと相互運用できることは理解しておくべきである。規模開示モジュール４２によって実行されるさまざまな動作を明確にするために適宜図９の表３００を参照することにする。
【００８２】
大きな取引注文２０を提出するトレーダーは自分の注文２０の総規模をあらゆる市場参加者が見るのは望まないことがあるが、かといって一連のより小口の注文２０を入力したがるとは思えない。規模開示モジュール４２はこの問題に対処するものであるが、それは、トレーダーが取引注文２０に、売買する取引製品の全量とともに任意の時点において市場参加者に示すべきその取引製品の最大開示量をも指定することができるようにすることによる。規模開示モジュール４２は特定の市場センターに対して開示する取引注文２０の規模を、少なくとも部分的にはそうした市場センター１８の開示ポリシーに基づいて決定する。これについてここでより十分に記述する。
【００８３】
たとえば表３００を示している図９を参照すると、規模開示モジュール４２は種々の市場センター１８の開示ポリシー３０２を同定しうる。表３００に示されているように、市場センター１８は少なくとも３つの異なる開示ポリシー３０２：ＰＲＯＰ、ＩＯＣ、ＮＯＩＯＣを含むことができる。
【００８４】
〈ＰＲＯＰ〉
「ＰＲＯＰ」の開示ポリシー３０２を有する市場センターは、取引交換プラットフォーム１２が保留取引注文２０を送ることができるようにする独自の（ｐｒｏｐｒｉｅｔａｒｙ）保留機能を有している。保留取引注文２０というのは、取引すべき取引製品の全量（たとえば購入または売却されるべき株の全数）と、任意の時点において公衆に開示されるべき取引製品の最大開示量（たとえば購入または売却されるとして公に開示される最大株数）とを指定する注文である。これらの市場センター１８は全量まで満たすものの、開示するのは保留取引注文２０で指定されている最大開示量までである。
【００８５】
多くの市場センター１８は独自の保留機能はサポートしてはいない。さらに、取引注文２０について得られる最良価格１０４が独自の保留機能を提供しない市場センター１８にあることもある。そこで、規模開示モジュール４２は、市場センター１８が独自の保留機能を提供しないときでさえ取引注文２０の規模開示の管理ができる。
【００８６】
〈ＩＯＣ〉
「ＩＯＣ」の開示ポリシー３０２を有する市場センター１８は、ＩＯＣ注文２０は市場参加者に開示しない。ＩＯＣ注文２０というのは、市場センター１８がすぐに最善努力ベースで満たそうと試みるが、すぐに満たすことのできない部分は取り消すという注文である。ちなみに、「ＩＯＣ」はＩｍｍｅｄｉａｔｅ  ｏｒ  Ｃａｎｃｅｌ（すぐでなければ取り消し）の略である。これらの市場センター１８に関しては、規模開示モジュール４２は最初は取引製品の全量を指定したＩＯＣ取引注文２０を通信する。市場センター１８はＩＯＣ取引注文２０全体を満たすこともあるし、満たさないこともあるが、しかるべく応答する。
【００８７】
たとえば、モジュール４２が受け取った取引注文２０が株Ｘの全量５０，０００株と株Ｘの最大開示量１０，０００株とを指定している場合、モジュール４２によって通信されるＩＯＣ取引注文２０は「株Ｘを５０，０００株購入されたし」といったもので、市場センターからの応答は「株Ｘを２，０００株購入した；株Ｘの４８，０００株はＵＲ  ＯＵＴ」といったものでありうる。応答の「ＵＲ  ＯＵＴ」の部分は、市場センター１８がトレーダーを、注文帳に注文２０を載せたことに関する法的義務から解放したことを示す略記である。
【００８８】
市場センター１８からの応答が「ＵＲ  ＯＵＴ」メッセージを含んでいる場合、規模開示モジュール４２は、最大開示量（たとえば株Ｘの１０，０００株）と注文２０についての残量（たとえば株Ｘの４８，０００株）のうちの小さいほうについて「当日限り」注文２０を通信する。「当日限り」注文２０は、現取引日の残りの間、あるいは取り消されるか満たされるかするまで市場センター１８の取引帳に留まる注文である。したがって、「当日限り」注文２０は「株Ｘを１０，０００株購入されたし」といったものになる。
【００８９】
「当日限り」注文２０が完全に満たされると、規模開示モジュール４２は、取引注文２０の残りの量（たとえば株Ｘの３８，０００株）について別のＩＯＣ注文２０を通信する。ＩＯＣ注文２０と「当日限り」注文２０を市場センター１８に交互に通信する処理は、トレーダーが注文２０を取り消すか、注文２０が完全に満たされるかするまで繰り返される。
【００９０】
〈ＮＯＩＯＣ〉
「ＮＯＩＯＣ」の開示ポリシー３０２を有する市場センター１８は、ＩＯＣ注文２０を市場参加者に開示する。これらの市場センター１８に関しては、規模開示モジュール４２は最大開示量についての「当日限り」注文２０を通信する。「当日限り」注文２０が完全に満たされると、モジュール４２は、指定された最大開示量と取引注文２０の残量とのうちの少ないほうについて別の「当日限り」注文２０を送る。「当日限り」注文２０を送るこのプロセスは、トレーダーが注文２０を取り消すが、注文２０が完全に満たされるかするまで繰り返される。
【００９１】
図１０は、市場センター１８への取引注文２０の規模開示を管理するための例示的な方法を示している。本方法は、ステップ３１２で、規模開示モジュール４２が、取引製品の全量と該取引製品の最大開示量とを指定した取引注文２０を受け取ることで始まる。取引注文２０は、取引交換プラットフォーム１２のいかなる好適なコンポーネントから受け取られてもよく、振り向けられるべき特定の市場センター１８を指定している。規模開示モジュール４２はステップ３１４で前記特定の市場センター１８を同定し、ステップ３１６で該同定された市場センター１８に関連付けられた開示ポリシー３０２をたとえば表３００を使って判別する。
【００９２】
同定された市場センター１８が採用している開示ポリシー３０２の種類に依存して、規模開示モジュール４２はいくつかの動作を実行する。モジュール４２は、ステップ３１８で開示ポリシー３０２が独自の保留ポリシーであるかどうかを判定する。もしそうであれば、実行はステップ３２０に進み、モジュール４２は購入されるべき（または売却されるべき）取引製品の全量と該取引製品の最大開示量とを指定する保留注文２０を送る。保留注文２０は、モジュール４２によって、あるいはモジュール４２の代わりに取引交換プラットフォーム１２の任意の好適なコンポーネントによってステップ３１４で同定された市場センター１８に送られうる。これは、モジュール４２によって送られる取引注文２０のようなすべての通信についてあてはまる。実行はステップ３４４で終了する。
【００９３】
ステップ３１８で、同定された市場センター１８の開示ポリシー３０２が独自保留ポリシーではないと判定された場合、実行はステップ３２２に進み、モジュール４２は同定された市場センター１８の開示ポリシー３０２がＩＯＣポリシーであるかどうかを判定する。もしそうであれば、実行はステップ３２４に進み、モジュール４２は購入されるべき（または売却されるべき）取引製品の全量を指定するＩＯＣ注文２０を送る。モジュール４２はステップ３２６で応答を受け取り、ステップ３２８で応答が「ＵＲ  ＯＵＴ」メッセージを含んでいないと判定されれば、ＩＯＣ注文２０全体が市場センター１８によって満たされており、実行はステップ３４４で終了する。
【００９４】
ステップ３２８で、ステップ３２６で受け取られた応答が実際に「ＵＲ  ＯＵＴ」メッセージを含んでいると判定された場合は、実行はステップ３３０に進み、モジュール４２はステップ３１２で受け取った取引注文２０の最大開示量と全量の残りとの少ないほうを指定する「当日限り」注文２０を送る。「当日限り」注文２０は、ステップ３３２で満たされたと判定されるまで市場センター１８でペンディングのまま留まる。実行は次いでステップ３３４に進み、モジュール４２はステップ３１２で受け取った取引注文２０の全量の残りを指定するもう一つのＩＯＣ注文２０を送る。実行は次いでステップ３２６に戻る。ステップ３２６から３３４は、取引注文２０全体が満たされるまで繰り返される。取引注文２０全体が満たされたことは、ステップ３２８で「ＵＲ  ＯＵＴ」メッセージを受け取らないことで判定される。
【００９５】
ステップ３２２で前記同定された市場センター１８の開示ポリシー３０２がＩＯＣポリシーではないと判定された場合には、実行はステップ３３６に進み、モジュール４２は同定された市場センター１８の開示ポリシーがＮＯＩＯＣポリシーであるかどうかを判定する。もしそうであれば、実行はステップ３３８に進み、モジュール４２は、購入されるべき（または売却されるべき）取引製品の最大開示量を指定する「当日限り」注文２０を送る。「当日限り」注文２０は、ステップ３４０で満たされたと判定されるまで市場センター１８でペンディングのまま留まる。実行は次いでステップ３４２に進み、モジュール４２はステップ３１２で受け取った取引注文２０の最大開示量と全量のうちの残りとの少ないほうを指定したもう一つの「当日限り」注文２０を送る。実行はステップ３４４で終了する。
【００９６】
〈注文取り合わせモジュール〉
図１１は、データベース５０および価格サーバー７０に結合された注文取り合わせモジュール４４の一つの実施形態を示している。注文取り合わせモジュール４４が取引交換プラットフォーム１２およびシステム１０の他の要素と別に示されているのは単に説明のためであって、注文取り合わせモジュール４４がここに記載される動作を実行するためにシステム１０の一つまたは複数の他のコンポーネントと相互運用できることは理解しておくべきである。注文取り合わせモジュール４４によって実行されるさまざまな動作を明確にするために適宜図１２を参照することにする。
【００９７】
注文取り合わせモジュール４４は、ある特定の量のある特定の取引製品をある目標ビッド価格で購入する注文（たとえばビッド要求）、あるいはある特定の量のある特定の取引製品をある目標オファー価格で売却する注文（たとえばオファー要求）である取引注文２０を受け取る。しかし、取引注文２０はどの市場センター１８に振り向けられるかについては未指定である。たとえば、注文取り合わせモジュールは、トレーダー１から、ＸＹＺ株を１００，０００株、９．９８の目標価格で売るようにという注文である取引注文２０を受け取りうる。
【００９８】
注文取り合わせモジュール４４は、はいってくる取引注文２０をその取引製品についての保存されている一つまたは複数の要求と取り合わせるためにデータベース５０に保存されている注文取り合わせログ６０を管理している。たとえばログ６０を示している図１２を参照すると、注文取り合わせモジュール４４は、上で特定したようなオファー要求を指定したはいってくる取引注文２０を段４０４に図示されているその取引製品についての保存されている一つまたは複数のビッド要求と取り合わせうる。同様に、ある取引製品についてビッド要求を指定したはいってくる取引注文２０を段４０６に図示されているその取引製品についての保存されている一つまたは複数のオファー要求と取り合わせうる。
【００９９】
段４０４の項目は製品４１０、ビッド量４１２、ソース４１４、ビッド価格４１６および状態４１８といった、保存されているビッド要求に関する情報を含んでいる。段４０６の項目は、製品４２０、オファー量４２２、ソース４２４、オファー価格４２６および状態４２８といった、保存されているオファー要求に関する情報を含んでいる。製品４１０および４２０は、ＸＹＺ株など、取引の対象となりうるある特定の取引製品を指す。ビッド量４１２およびオファー量４２２はそれぞれ、購入しようと目指している、あるいは販売のために提供されているその取引製品の量をいう。ソース４１４および４２４は、その取引製品を購入または売却しようと求める当事者のことをいい、たとえばシステム１０内で活動している特定の市場センター１８または特定のトレーダーなどである。価格４１６および４２６はそれぞれビッド価格およびオファー価格であり、これは未調整価格１０２であってもよいし、調整価格１１２であってもよい。状態４１８および４２８はそれぞれある特定のビッド要求またはオファー要求の状態をいう。
【０１００】
トレーダー１からＸＹＺ株を１００，０００株、目標価格９．９８で売却するという注文を指定する取引注文２０を受け取ると、注文取り合わせモジュール４４は取り合わせ相手をみつけるためにＸＹＺ株についての保存されているビッド要求に対応する段４０４を参照する。一般に、注文取り合わせモジュール４４は、関与するトレーダーにとって最良の価格につながる仕方で取引注文２０を満たそうと努める。それゆえ、注文取り合わせモジュール４４はＸＹＺ株についての最高ビッド価格４１６を同定する項目を段４０４で探す。
【０１０１】
トレーダー２およびトレーダー３はそれぞれＸＹＺ株についてのビッド要求を、トレーダー１の目標オファー価格９．９８よりも高い１０．０２のビッド価格４１６で提出している。トレーダー２とトレーダー３の場合のように複数のトレーダーが同じビッド価格（またはオファー価格）で取引要求を提出した場合には、注文取り合わせモジュール４４はビッド要求（またはオファー要求）を特定の順番で満たしていく。その順番を決めるのは、各要求のビッド量（またはオファー量）、各要求が受け取られた順番、トレーダーの素性、またはトレーダー間の優先順位を付ける（prioritize）のに使用される他の任意の好適な要因のうちの一つまたは複数である。注文取り合わせモジュール４４は、トレーダーのビッド／オファー要求を、同じビッド価格またはオファー価格の市場センター１８のビッド／オファー要求より先に満たしてもよい。流動性を促進してトランザクション費用を削減するためである。
【０１０２】
トレーダー１によって提出された取引注文２０は１００，０００株の売却を要求していたため、トレーダー２およびトレーダー３によって提出されたビッド要求のそれぞれが取り合わされる。その結果、トレーダー１とトレーダー２の間でのＸＹＺ株１，０００株の第一の取り合わされた取引注文と、トレーダー１とトレーダー３との間でのＸＹＺ株２，０００株の第二の取り合わされた取引注文とが成立する。これらの取り合わされた取引注文のそれぞれについての価格は取り合わせ価格と称されるが、これは少なくとも部分的にはビッド要求のビッド価格４１６と取引注文２０によって指定されたオファー価格とに基づいている。たとえば、取り合わせ価格は１０．０２（ビッド要求のビッド価格４１６）であってもいいし、９．９８（取引注文２０によって指定されたオファー価格）であってもいいし、あるいは９．９８と１０．０２の平均値の１０．００などその間のいかなる価格であってもいい。トレーダー２およびトレーダー３に対応するビッド要求の状態は「取り合わせ済み」のようなフラグで示される。あるいはまた、取り合わせられたビッド要求は、取り合わせ済みであることを示すためにログ６０から除かれてもよい。
【０１０３】
取引注文２０の残っているオファー量残高はＸＹＺ各９７，０００株である（たとえば、１０，０００株−１，０００株−２，０００株＝９７，０００株）。注文取り合わせモジュール４４は、ＡＲＣＡがＸＹＺ株６，０００株について１０．０１のビッド価格４１６を提示していることを判別する。これはトレーダー１の目標オファー価格である９．９８よりも高い。よって、ある実施例では、注文取り合わせモジュール４４はＸＹＺ株を６，０００株、１０．０１で売却する注文を含む取引注文２０をＡＲＣＡに振り向ける。
【０１０４】
別の実施例では、注文取り合わせモジュール４４は取引注文２０においてＡＲＣＡに振り向ける取引製品の量（市場センター量ともいう）を、市場センター１８によって提示されたビッド量（たとえば、ＸＹＺ株６，０００株）およびその特定の市場センター１８に関連付けられた量乗数に基づいて決定する。たとえば、注文取り合わせモジュール４４がＡＲＣＡに適用する量乗数は３倍であり、この場合、ＸＹＺ株１８，０００株を１０．０１で売却するというオファーを含む取引注文２０がＡＲＣＡに振り向けられる結果となる。ＡＲＣＡに対応するビッド要求の状態４１８はこれで「ペンディング」と示される。これは、ＡＲＣＡとの取引注文２０が現在ペンディングであることを示す。ある実施例では、市場センター１８に振り向けられる取引注文２０はＩＯＣ取引注文２０を含む。別の実施例では、市場センター１８に振り向けられる取引注文２０は規模開示モジュール４２によって決定される注文のタイプを含む。
【０１０５】
注文取り合わせモジュール４４は、各市場センター１８についての量乗数を決定するのを、その特定の取引製品に関して市場センター１８と関連付けられている現在または最近の「充足率」に基づいて行う。「充足率」を決定するのは、ある特定の取引製品についてある特定の価格で市場センター１８によって満たされた株数の割合の移動平均に基づいて行ってもよい。個別的な実施例では、８３％の充足率に対して３倍の量乗数が対応させられる。
【０１０６】
注文取り合わせモジュール４４が量乗数を適用するとすると、取引注文２０は、ＸＹＺ株の残りのオファー量残高７９，０００株となる（たとえば、９７，０００株−１８，０００株＝７９，０００株）。注文取り合わせモジュール４４は次にＩＳＬＤがＸＹＺ株７，０００株に対して１０．０１のビッド価格４１６を提示していることを判別する。これもトレーダー１の目標オファー価格９．９８より高い。特定の実施例では、注文取り合わせモジュール４４は、ある特定の市場センター１８がすでにプラットフォーム１２から所定の最大数を超えるペンディング取引注文２０を受け取っていると判定することがある。そのような場合、プラットフォーム１２は、その市場センター１８に対するペンディング取引注文２０の現在数が所定の許容最大数未満になるまでさらなる取引注文２０は送らない。ここで記載している動作例では、ＩＳＬＤは許容されるペンディング取引注文２０の所定の最大数を超えているものと想定され、よって注文取り合わせモジュール４４はＩＳＬＤには取引注文２０を送らない。したがって、ＩＳＬＤに関するビッド要求の状態４１８は「オープン」と示される。
【０１０７】
注文取り合わせモジュール４４は次にＡＲＣＡがＸＹＺ株の２，０００株について１０．００のビッド価格４１６を提示していることを判別する。これはトレーダー１の目標オファー価格９．９８よりも高い。特定の実施例では、注文取り合わせモジュール４４はある特定の市場センター１８がすでにある特定の取引製品についての取引注文２０を受け取っているかどうかを判定し、その同じ取引製品についてはその同じ市場センター１８には別の取引注文２０を送らないことを決定しうる。他の実施例では、注文取り合わせモジュール４４はその同じ市場センター１８にその同じ取引製品について、ビッド量４１２に等しい量または適切な量乗数によって調整されたビッド量４１２に等しい量だけ、いま一つの取引注文を通信してもよい。ここに記載された動作例では、注文取り合わせモジュール４４はもう一つの取引注文２０をＡＲＣＡに送らないものと想定される。したがって、ＡＲＣＡに関するビッド要求の状態４１８は「オープン」と示される。
【０１０８】
注文取り合わせモジュール４４は次に、トレーダー４がＸＹＺ株の５０，０００株について１０．００でビッド要求を提出していることを判別する。これはトレーダー１の目標オファー価格９．９８よりも高い。トレーダー４によって提出されたビッド要求は、トレーダー１によって提出された取引注文２０と取り合わされる。結果として、トレーダー１とトレーダー４との間でＸＹＺ株５０，０００株について第三の取り合わされた取引注文が成立する。上述したように、この取り合わされた取引注文に対する取り合わせ価格は、９．９８でも、１０．００でも、あるいはその間のいかなる価格でもよい。トレーダー４に対応するビッド要求の状態４１８は「取り合わせ済み」と示されるか、あるいはまた、そのビッド要求が取り合わせ済みであることを示すためにログ６０から除かれる。
【０１０９】
取引注文２０の残っているオファー量残高はＸＹＺ各２９，０００株である（たとえば、７９，０００株−５０，０００株＝２９，０００株）。注文取り合わせモジュール４４は、ログ６０にはＸＹＺ株へのビッド要求はほかには保存されていないことを判別する。結果として、モジュール４４はトレーダー１の代理としてログ６０に、ＸＹＺ株２９，０００株に対する９．９８でのオファー要求を保存する。
【０１１０】
注文取り合わせモジュール４４の動作について、オファー要求を保存されているビッド要求と取り合わせることを参照して詳述してきたが、注文取り合わせモジュール４４は同様の動作原理を適用してビッド要求を保存されているオファー要求と取り合わせてもよいことは理解しておくべきである。
【０１１１】
注文取り合わせモジュール４４の格別な利点は、はいってくる取引注文２０を、適切かつ可能な場合に他のトレーダーから提出された要求と取り合わせることで、システム１０の注文充足プロセスを取引交換プラットフォーム１２内で内部化しようとすることである。そのような注文２０がプラットフォーム１２内で内部的に満たされるとき、注文取り合わせモジュール４４は適切なトレーダーに対して、満たされた注文の詳細を指定する一つまたは複数の確認４０２を通信しうる。はいってくる取引注文２０の少なくとも一部分が内部的に満たされないときには、注文取り合わせモジュール４４は一つまたは複数の取引注文２０を一つまたは複数の市場センター１８に通信しうる。
【０１１２】
図１３は、注文取り合わせを実行するための例示的な方法のフローチャート４５０を示している。本方法は、ステップ４５２においてモジュール４４がある特定の量のある特定の取引製品をある目標ビッド価格で購入する注文、あるいはある特定の量のある特定の取引製品をある目標オファー価格で売却する注文を含む取引注文２０を受け取ることで始まる。実行はステップ４５４に進み、モジュール４４は対応する要求が注文取り合わせログ６０内で同定できるかどうかを判定する。たとえば、取引注文２０がある特定の取引製品についてのオファー要求を含んでいる場合、モジュール４４はその特定の取引製品についての対応するビッド要求がログ６０内に同定しうるかどうかを判定する。その取引注文２０がある特定の取引製品についてのビッド要求を含んでいる場合なら、モジュール４４はその特定の取引製品についての対応するオファー要求がログ６０内に同定しうるかどうかを判定する。モジュール４４がある特定の取引製品について二つ以上の対応する要求を同定するような特定の実施例では、実行は同定された要求のうち、最高ビッド価格または最低オファー価格といった最良価格を有する一つを用いて進行する。
【０１１３】
ステップ４５４で対応する要求が同定された場合、モジュール４４はステップ４５６で、その要求がトレーダーに関するものであるかどうかを判定する。もしそうであれば実行はステップ４５８に進み、モジュール４４はその取引注文２０をステップ４５４で同定された要求と取り合わせて取り合わせ済み取引注文を成立させる。ステップ４６０での判定によりその取引注文の量残高が残っていれば、実行はステップ４５４に戻って別の対応する要求が同定されるかどうかが判定される。
【０１１４】
ステップ４５４で同定された要求がステップ４５６の判定でトレーダー要求ではなかった場合、実行はステップ４６２に進み、モジュール４４はその要求が市場センター１８に関するものであるかどうかを判定する。もしそうであれば、モジュール４４はステップ４６４で、市場センター１８がすでにプラットフォーム１２からペンディングの取引注文２０を所定の最大数を超えて受け取っているかどうかを判定する。もしそうであれば、実行はステップ４５４に戻る。そうでなければ、実行はステップ４６６に進み、モジュール４４はその特定の市場センター１８について適切な量乗数を決定する。モジュール４４はステップ４６８において、特定の市場センター１８に向けられた取引注文２０を通信する。
【０１１５】
ステップ４７０での判定により取引注文の量残高が残っていた場合には、実行はステップ４５４に戻り、別の対応する要求が同定されるかどうかが判定される。ステップ４５４で別の対応する要求が同定されない場合には、実行はステップ４７２に進み、取引注文２０のさまざまなパラメータが要求として注文取り合わせログ６０に保存される。たとえば、取引注文２０がビッド要求を指定していた場合には、モジュールはステップ４７２で残りの量残高についてのビッド要求をログ６０に保存する。取引注文２０がオファー要求を指定していた場合には、モジュール４４はステップ４７２で残りの量残高についてのオファー要求をログ６０に保存する。ステップ４７２で要求を保存したら、あるいはステップ４６０または４７０で取引注文２０の量残高が残っていないと判定したら、実行はステップ４７４に進んで本方法は終了する。
【０１１６】
本発明はいくつかの実施形態において記載されてきたが、当業者なら無数の変更および修正が提案しうるものであり、本発明は付属の請求項の範囲にはいるかぎりそうした変更および修正をも包含することが意図されている。
【０１１７】
いくつかの態様を記しておく。
〔態様１〕
取引注文どうしを取り合わせるためのシステムであって：
ある取引製品についての、それぞれがトレーダーと市場センターのうちの少なくとも一つに関連付けられている複数のビッド要求と、その取引製品についてのビッド量と、その取引製品についてのビッド価格とを保存するよう動作しうるメモリと、
前記メモリに結合されており：
前記取引製品についてのオファー要求を指定しさらに前記取引製品についてのオファー量および前記取引製品についての目標オファー価格を指定した取引注文を受け取り、
前記複数のビッド要求のうちから、前記目標オファー価格以上のビッド価格を有する少なくとも一つを同定し、
前記同定されたビッド要求がトレーダーに関連付けられたものであれば、前記取引注文のオファー要求と前記少なくとも一つの同定されたビッド要求とを取り合わせ、
前記少なくとも一つの同定されたビッド要求が特定の市場センターに関連付けられたものであれば、前記取引注文をその特定の市場センターに振り向ける、
よう動作しうるプロセッサ、
とを有することを特徴とするシステム。
〔態様２〕
前記取引注文のオファー要求と前記同定されたビッド要求とを取り合わせることが、一致した量および一致した価格を有する取り合わせ済み取引注文を成立させることを特徴とする、態様１記載のシステム。
〔態様３〕
前記一致した量が、前記同定されたビッド要求のビッド量と前記取引注文によって指定されたオファー量との少ないほうであることを特徴とする、態様２記載のシステム。
〔態様４〕
前記一致した価格が、前記同定されたビッド要求のビッド価格と前記取引注文によって指定されたオファー価格のうちの少なくとも一つに基づいていることを特徴とする、態様２記載のシステム。
〔態様５〕
態様１記載のシステムであって、同定することが、前記目標オファー価格以上の第一のビッド価格を有する第一のビッド要求を同定すること、および前記目標オファー価格以上で前記第一のビッド価格より低い第二のビッド価格を有する第二のビッド要求を同定することを含んでいることを特徴とするシステム。
〔態様６〕
態様５記載のシステムであって：
前記第一のビッド要求がトレーダーに関連付けられており、前記取引注文によって指定されるオファー量よりも少ないビッド量を指定しており、
取り合わせることが、前記取引注文のオファー要求と前記第一のビッド要求とに関わる取引を促進することを含み、それにより取り合わせ後に満たされずに残るオファー量のすべての部分は前記取引製品についての残りの量残高となる、
ことを特徴とするシステム。
〔態様７〕
態様６記載のシステムであって：
前記第二のビッド要求がある特定の市場センターに関連付けられており、
振り向けることが、前記残りの量残高の少なくとも一部分である市場センター量についての取引注文を前記特定の市場センターに振り向けることである、
ことを特徴とするシステム。
〔態様８〕
態様７記載のシステムであって、前記プロセッサが前記市場センター量を決定するのを、少なくとも部分的に前記第二のビッド要求のビッド量および前記特定の市場センターに関連付けられた量乗数に基づいて行うことを特徴とするシステム。
〔態様９〕
態様６記載のシステムであって、前記メモリが前記取引製品についてのあるオファー要求を保存しており、該オファー要求が前記残りの量残高を充足させるオファー量を指定し、さらに前記目標オファー価格を充足させるオファー価格を指定していることを特徴とするシステム。
〔態様１０〕
態様６記載のシステムであって、前記プロセッサが：
前記第一のビッド要求が取り合わせ済みとなったことを示すフラグを立てること、
前記第一のビッド要求が取り合わせ済みとなったことを示すために前記第一のビッド要求をメモリから除去すること、
のうちの少なくとも一つを実行することを特徴とするシステム。
〔態様１１〕
態様５記載のシステムであって：
前記第一のビッド要求がある特定の市場センターに関連付けられており、前記取引注文によって指定されるオファー量よりも少ないビッド量を指定しており、
振り向けることが、ある市場センター量についての取引注文を前記特定の市場センターに振り向けることを含み、それにより前記オファー量が前記市場センター量だけ減らされたものが残りの量残高をなす、
ことを特徴とするシステム。
〔態様１２〕
態様１１記載のシステムであって：
前記第二のビッド要求がトレーダーに関連付けられており、
取り合わせることが、前記取引注文のオファー要求と、前記残りの量残高の少なくとも一部分である量についての前記第二のビッド要求とに関わる取引を促進することを含む、
ことを特徴とするシステム。
〔態様１３〕
態様１１記載のシステムであって、前記プロセッサが前記市場センター量を決定するのを、少なくとも部分的に前記第一のビッド要求のビッド量および前記特定の市場センターに関連付けられた量乗数に基づいて行うことを特徴とするシステム。
〔態様１４〕
態様１２記載のシステムであって、前記メモリが前記取引製品についてのあるオファー要求を保存しており、該オファー要求が前記残りの量残高を充足させるオファー量を指定しており、さらに前記目標オファー価格を充足させるオファー価格を指定していることを特徴とするシステム。
〔態様１５〕
態様１１記載のシステムであって、前記振り向けられた取引注文がＩＯＣ注文であることを特徴とするシステム。
〔態様１６〕
態様１記載のシステムであって、市場センターに関連付けられている各ビッド要求のビッド価格が、該市場センターに関する費用情報およびリベート情報のうちの少なくとも一つに従って調整されたビッド価格であることを特徴とするシステム。
〔態様１７〕
態様１記載のシステムであって、市場センターに関連付けられている各ビッド要求のビッド価格が、該市場センターに関するポリシー情報および当該取引製品についての最良価格情報に従って調整されたビッド価格であることを特徴とするシステム。
〔態様１８〕
取引注文どうしを取り合わせるためのシステムであって：
ある取引製品についての、それぞれがトレーダーと市場センターのうちの少なくとも一つに関連付けられている複数のオファー要求と、その取引製品についてのオファー量と、その取引製品についてのオファー価格とを保存するよう動作しうるメモリと、
前記メモリに結合されており：
前記取引製品についてのビッド要求を指定しさらに前記取引製品についてのビッド量および前記取引製品についての目標ビッド価格を指定した取引注文を受け取り、
前記複数のオファー要求のうちから、前記目標ビッド価格以下のオファー価格を有する少なくとも一つを同定し、
前記同定されたオファー要求がトレーダーに関連付けられたものであれば、前記取引注文のビッド要求と前記少なくとも一つの同定されたオファー要求とを取り合わせ、
前記少なくとも一つの同定されたオファー要求が特定の市場センターに関連付けられたものであれば、前記取引注文をその特定の市場センターに振り向ける、
よう動作しうるプロセッサ、
とを有することを特徴とするシステム。
〔態様１９〕
前記取引注文のビッド要求と前記同定されたオファー要求とを取り合わせることが、一致した量および一致した価格を有する取り合わせ済み取引注文を成立させることを特徴とする、態様１８記載のシステム。
〔態様２０〕
前記一致した量が、前記同定されたオファー要求のオファー量と前記取引注文によって指定されたビッド量との少ないほうであることを特徴とする、態様１９記載のシステム。
〔態様２１〕
前記一致した価格が、前記同定されたオファー要求のオファー価格と前記取引注文によって指定されたビッド価格のうちの少なくとも一つに基づいていることを特徴とする、態様１９記載のシステム。
〔態様２２〕
態様１８記載のシステムであって、同定することが、前記目標ビッド価格以下の第一のオファー価格を有する第一のオファー要求を同定すること、および前記目標ビッド価格以下で前記第一のオファー価格より高い第二のオファー価格を有する第二のオファー要求を同定することを含んでいることを特徴とするシステム。
〔態様２３〕
態様２２記載のシステムであって：
前記第一のオファー要求がトレーダーに関連付けられており、前記取引注文によって指定されるビッド量よりも少ないオファー量を指定しており、
取り合わせることが、前記取引注文のビッド要求と前記第一のオファー要求とに関わる取引を促進することを含み、それにより取り合わせ後に満たされずに残るビッド量のすべての部分は前記取引製品についての残りの量残高となる、
ことを特徴とするシステム。
〔態様２４〕
態様２３記載のシステムであって：
前記第二のオファー要求がある特定の市場センターに関連付けられており、
振り向けることが、前記残りの量残高の少なくとも一部分である市場センター量についての取引注文を前記特定の市場センターに振り向けることである、
ことを特徴とするシステム。
〔態様２５〕
態様２４記載のシステムであって、前記プロセッサが前記市場センター量を決定するのを、少なくとも部分的に前記第二のオファー要求のオファー量および前記特定の市場センターに関連付けられた量乗数に基づいて行うことを特徴とするシステム。
〔態様２６〕
態様２３記載のシステムであって、前記メモリが前記取引製品についてのあるビッド要求を保存しており、該ビッド要求が前記残りの量残高を充足させるビッド量を指定し、さらに前記目標ビッド価格を充足させるビッド価格を指定していることを特徴とするシステム。
〔態様２７〕
態様２３記載のシステムであって、前記プロセッサが：
前記第一のオファー要求が取り合わせ済みとなったことを示すフラグを立てること、
前記第一のオファー要求が取り合わせ済みとなったことを示すために前記第一のオファー要求をメモリから除去すること、
のうちの少なくとも一つを実行することを特徴とするシステム。
〔態様２８〕
態様２２記載のシステムであって：
前記第一のオファー要求がある特定の市場センターに関連付けられており、前記取引注文によって指定されるビッド量よりも少ないオファー量を指定しており、
振り向けることが、ある市場センター量についての取引注文を前記特定の市場センターに振り向けることを含み、それにより前記ビッド量が前記市場センター量だけ減らされたものが残りの量残高をなす、
ことを特徴とするシステム。
〔態様２９〕
態様２８記載のシステムであって：
前記第二のオファー要求がトレーダーに関連付けられており、
取り合わせることが、前記取引注文のビッド要求と、前記残りの量残高の少なくとも一部分である量についての前記第二のオファー要求とに関わる取引を促進することを含む、
ことを特徴とするシステム。
〔態様３０〕
態様２８記載のシステムであって、前記プロセッサが前記市場センター量を決定するのを、少なくとも部分的に前記第一のオファー要求のオファー量および前記特定の市場センターに関連付けられた量乗数に基づいて行うことを特徴とするシステム。
〔態様３１〕
態様２９記載のシステムであって、前記メモリが前記取引製品についてのあるビッド要求を保存しており、該ビッド要求が前記残りの量残高を充足させるビッド量を指定しており、さらに前記目標ビッド価格を充足させるビッド価格を指定していることを特徴とするシステム。
〔態様３２〕
態様２８記載のシステムであって、前記振り向けられた取引注文がＩＯＣ注文であることを特徴とするシステム。
〔態様３３〕
態様１８記載のシステムであって、市場センターに関連付けられている各オファー要求のオファー価格が、該市場センターに関する費用情報およびリベート情報のうちの少なくとも一つに従って調整されたオファー価格であることを特徴とするシステム。
〔態様３４〕
態様１８記載のシステムであって、市場センターに関連付けられている各オファー要求のオファー価格が、該市場センターに関するポリシー情報および当該取引製品についての最良価格情報に従って調整されたオファー価格であることを特徴とするシステム。
【図１】
2011170880.tif 000003
【図２】
2011170880.tif 000004
【図３】
2011170880.tif 000005
【図４】
2011170880.tif 000006
【図５】
2011170880.tif 000007
【図６Ａ】
2011170880.tif 000008
【図６Ｂ】
2011170880.tif 000009
【図７】
2011170880.tif 000010
【図８】
2011170880.tif 000011
【図９】
2011170880.tif 000012
【図１０】
2011170880.tif 000013
【図１１】
2011170880.tif 000014
【図１２】
2011170880.tif 000015
【図１３】
2011170880.tif 000016