(57)【要約】  分散型取引プラットフォーム（１０９）を操作する方法は、リアルタイムで通信ネットワーク（１１０）を介して、流動性取得者であり第２の参加者（１０３）夫々の取引活動を示す取引活動情報を監視することと、第２の参加者に対する有害性評価をリアルタイムで判定することと、流動性提供者の第１の参加者システム（１０７）からの通信ネットワークを介して最初の注文を受信することと、最初の注文を受信すると自動的に及びリアルタイムで、第２の参加者夫々の有害性評価から有害性の増加を判定し、通信ネットワークを介して最初の注文表示情報を第２の参加者夫々の第２の参加者システム（１１５）に送信して、最初の注文の表示の、第２の参加者システムのうちの各々の第２の参加者システムのディスプレイ（３００）のグラフィカルユーザインターフェース（ＧＵＩ）上に、第２の参加者に対応する有害性の増加を表示させることと、を含んでいてもよい。【選択図】  図１
2021535525.tif 000002
【特許請求の範囲】
【請求項１】
分散型取引プラットフォームを操作する方法であって、少なくとも１つのプロセッサによって、
リアルタイムで通信ネットワークを介して、流動性取得者であり第２の参加者夫々の取引活動を示す取引活動情報を監視することと、
前記取引活動情報に基づいて、前記第２の参加者夫々に対する有害性評価をリアルタイムで判定することと、
流動性提供者の第１の参加者システムからの前記通信ネットワークを介して最初の注文を受信することと、
前記最初の注文を受信すると、自動的に及びリアルタイムで、
前記第２の参加者夫々の前記有害性評価から有害性の増加を判定し、
前記通信ネットワークを介して最初の注文表示情報を前記第２の参加者夫々の第２の参加者システムに送信して、前記最初の注文の表示の、第２の参加者システムのうちの各第２の参加者システムのディスプレイのグラフィカルユーザインターフェース（ＧＵＩ）上に、前記第２の参加者に対応する前記有害性の増加を表示させることと、
前記第２の参加者システムの所与の第２の参加者システムから前記通信ネットワークを介して、反対注文を受信することと、
前記反対注文を受信すると、前記通信ネットワークを介して前記反対注文を前記第１の参加者システムに送信することと、
前記通信ネットワークを介して前記第１の参加者システムから前記最初の注文に表示されている金融商品の数量が予約されていることを示す表示を受信することと、
前記金融商品の前記数量が予約されていることを示す前記表示を受信すると、前記反対注文と前記最初の注文各々の少なくとも一部を成立させる取引の執行を容易にすることと、を制御することを含む、方法。
【請求項２】
前記第２の参加者の所与の第２の参加者に対する所与の有害性の増加は、前記所与の第２の参加者に対応する所与の有害性レベルの関数として判定される、請求項１に記載の方法。
【請求項３】
前記第２の参加者の所与の第２の参加者に対する所与の有害性の増加は、夫々の有害性レベルに対する所与の有害性の増加を示すルックアップテーブルから判定される、請求項１に記載の方法。
【請求項４】
前記取引活動情報は、前記通信ネットワークを介して遠隔地の市場データプロバイダから受信したリアルタイムの市場データを含む、請求項１に記載の方法。
【請求項５】
前記第２の参加者の所与の第２の参加者に対する所与の有害性の増加は、所与の表示情報の一部として前記通信ネットワークを介して前記所与の第２の参加者の所与の第２の参加者システムに送信される、請求項１に記載の方法。
【請求項６】
前記第２の参加者の所与の第２の参加者の所与の有害性の増加及び前記最初の注文の価格の合計と等しい量が、所与の表示情報の一部として前記通信ネットワークを介して前記所与の第２の参加者の所与の第２の参加者システムに送信される、請求項１に記載の方法。
【請求項７】
前記表示は、前記最初の注文を、前記最初の注文の価格の表示とは別に表示される前記夫々の有害性の増加と共に表示する、請求項１に記載の方法。
【請求項８】
前記表示は、前記最初の注文を、前記最初の注文の価格の表示に組み込まれる前記夫々の有害性の増加と共に表示する、請求項１に記載の方法。
【請求項９】
前記通信ネットワークを介して、前記最初の注文表示情報を前記第２の参加者システムに送信することは、前記第２の参加者システム夫々の前記ディスプレイに、前記最初の注文の価格と共に異なる有害性の増加を同時に表示させる、請求項１に記載の方法。
【請求項１０】
少なくとも１つのプロセッサによって、前記通信ネットワークを介して、前記第２の参加者システムのうち、少なくとも１つの第２の参加者システムの前記ディスプレイの前記ＧＵＩ上におけるショットクロックの前記表示に、前記少なくとも１つの第２の参加者システムに対応する少なくとも１人の第２の参加者に対して残された利用可能時間のカウントダウンを表示して、前記最初の注文に反応すること、を制御すること更に含む、請求項１に記載の方法。
【請求項１１】
少なくとも１つのプロセッサによって、
前記少なくとも１人の第２の参加者に対して残された時間がないと判定すると、自動的に
前記最初の注文に反応し、前記通信ネットワークを介して、（ｉ）前記ショットクロックが、前記利用可能な時間が満了したことを示し、（ｉｉ）前記ＧＵＩ上に表示された前記最初の注文を成立させる取引を執行することを要求する為に操作可能な表示が、前記最初の注文の再読み込みを要求する為に操作可能な表示に置き換わるように、前記ＧＵＩ上の前記表示を再読み込みすること、
を制御することを更に含む、請求項１０に記載の方法。
【請求項１２】
少なくとも１つのプロセッサによって、
自動的に、前記最初の注文を再読み込みする要求の前記表示が操作されたと判定すると、
前記最初の注文に表示された前記金融商品の第２の数量が予約されている旨の表示を受け取り、
前記反対注文と前記最初の注文の各々の少なくとも一部を成立させる取引の執行を簡素化すること、
を制御することを更に含む、請求項１１に記載の方法。
【請求項１３】
少なくとも１つのプロセッサによって、
前記第２の参加者の所与の第２の参加者に対し、前記所与の第２の参加者夫々の前記有害性評価から更新された有害性の増加を判定することと、
前記更新された有害性の増加の判定に自動的に呼応して、前記通信ネットワークを介してリアルタイムで、前記更新された有害性の増加を夫々前記所与の第２の参加者の所与の第２の参加者システムに送信して、前記所与の第２の参加者システム夫々の前記グラフィカルユーザインターフェースの再読み込みを行わせて、前記所与の第２の参加者システムに夫々対応する前記有害性の増加の代わりに前記更新された有害性の増加を表示すること、を制御することを更に含む、請求項１に記載の方法。
【請求項１４】
少なくとも１つのプロセッサによって、前記第２の参加者が前記最初の注文を見る資格があるかどうかを判定すること、を制御することを更に含む、請求項１に記載の方法。
【請求項１５】
少なくとも１つのプロセッサによって、前記最初の注文表示情報を、前記通信ネットワークを介して送信して、前記第２の参加者システムの証印の各々を、前記有害性の増加が見られる前記最初の注文を受け付ける為に操作可能なボタンとして前記ＧＵＩ上に表示させること、を制御することを更に含む、請求項１に記載の方法。
【請求項１６】
少なくとも１つのプロセッサによって、前記第１の参加者システムから前記通信ネットワークを介して受信した前記流動性提供者の取引の意思を、データベース内に安全に保存すること、を制御することを更に含む、請求項１に記載の方法。
【請求項１７】
前記取引の意思は、前記通信ネットワークを介して受信するときに暗号化され、前記少なくとも１つのプロセッサは、
前記取引の意思を復号化することと、
前記取引の意思を前記データベースに復号化された形式で保存することと、を制御する、請求項１６に記載の方法。
【請求項１８】
前記最初の注文表示情報は、夫々暗号化して前記第２の参加者システムに送信される、請求項１に記載の方法。
【請求項１９】
分散型取引システムであって、
流動性提供者の第１の参加者システムであって、第１の参加者システムが
前記第１の参加者システムのトレーダーインターフェースに入力された分散注文マッチング用の最初の注文を識別することと、
通信ネットワークを介して、前記最初の注文を前記分散型取引システムの中央システムに送信することと、
を制御するように構成された第１のコンピューティングデバイスを備え、
前記中央システムは、
夫々の、流動性取得者である第２の参加者の取引活動を示す取引活動情報をリアルタイムで前記通信ネットワークを介して監視することと、
前記取引活動情報に基づいて、前記第２の参加者夫々に対する有害性評価をリアルタイムで判定することと、
前記通信ネットワークを介して、前記第１の参加者システムから、前記最初の注文を受信することと、
自動的に、前記最初の注文を受信すると、及びリアルタイムで、
前記第２の参加者夫々の前記有害性評価からの有害性の増加を判定し、
前記通信ネットワークを介して、最初の注文表示情報を前記第２の参加者夫々の第２の参加者システムに送信して、前記最初の注文の表示の前記第２の参加者システムの各第２の参加者システムのディスプレイのグラフィカルユーザインターフェース上に前記第２の参加者に対応する前記有害性の増加を表示させることと、
前記第２の参加者システムの所与の第２の参加者システムから前記通信ネットワークを介して、反対注文を受信することと、
前記反対注文を受信すると、前記通信ネットワークを介して前記反対注文を前記第１の参加者システムに送信することと、
前記通信ネットワークを介して前記第１の参加者システムから前記最初の注文に表示されている金融商品の数量が予約されていることを示す表示を受信することと、
前記金融商品の前記数量が予約されていることを示す前記表示を受信すると、前記反対注文と前記最初の注文各々の少なくとも一部を成立させる取引の執行を簡素化することと、を制御するように構成された第２のコンピューティングデバイスを備え、
前記第１のコンピューティングデバイスは、
前記通信ネットワークを介して、前記反対注文を受信することと、
前記通信ネットワークを介して、前記最初の注文に表示されている前記金融商品の前記数量が予約されている旨の前記表示を送信することと、を制御するように構成された、
分散型取引システム。
【請求項２０】
前記第２の参加者システムを更に備え、
前記第２の参加者システムの各々は、
前記通信ネットワークを介して、前記最初の注文表示情報を受信することと、
前記グラフィカルユーザインターフェース上に前記第２の参加者に対応する前記有害性の増加を有する前記最初の注文の前記表示をレンダリングすることと、
前記通信ネットワークを介して、所与の反対注文を送信することと、
を制御するように構成された
第３のコンピューティングデバイスを含む、請求項１９に記載の分散型取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願との相互参照
本出願は、２０１８年８月２３日に提出の米国仮特許出願第６２／７２１，７４８号の利益を主張するものであり、この参照により全文が開示に含まれるものとする。本開示の様々な実施形態は、取引プラットフォーム、取引所、注文管理システム（ＯＭＳ）、価格判定アルゴリズム、市場力学、及び、米国特許及び出願、即ち２０１３年１０月２２日発行の米国特許第８，５６６，２１３号、米国特許出願第１０／３１０，３４５号（米国特許出願公開第２００４／００３４５９１号）、米国特許出願第１２／４７７，５４９号、米国特許出願第１２／４７０，４３１号、米国特許出願第１２／１３５，４７９号、米国特許出願第１２／１１３，６０２号、及び米国特許出願第１２／２３７，９７６号の他の機能のうちの１つ以上を利用してもよい。ここに記載されている機能は、「複数の注文を生成する為の商品及びプロセス」と題する２００９年６月３日提出の、米国特許出願第１２／４７７，５４９号、２００９年５月２１日提出の米国特許出願第１２／４７０，４３１号、２００８年６月９日提出の「取引システム商品及びプロセス」と題した米国特許出願第１２／１３５，４７９号、２００８年５月１日提出の「注文管理システムを統合した電子セキュリティマーケットプレイス」と題する米国特許出願第１２／１１３，６０２号、２００８年９月２５日提出の「ファンド組成に関わる取引」と題する米国特許出願第１２／２３７，９７６号、２００８年５月１日提出の米国特許出願第１２／１１３，６４２号、２００８年１０月２４日提出の米国特許出願第１２／２５７，４９９号、２０１３年５月６日提出の米国第１３／８８８，３５２号（米国特許出願公開第２０１４／０２２９３５３号）、２０１３年３月１５日提出の米国第１３／８４４，７７９号、２０１７年６月１４日提出の米国特許出願第１５／６２２，９７７号、２０１７年１月１０日提出の米国仮特許出願第６２／４４４，７１１号、及び２０１７年１月１１日提出の米国仮特許出願第６２／４４５０３９号に記載されている取引システム内で動作するように構成されていることも理解されるべきである。これらの出願、特許、及び出版物の開示内容、及び本特許出願において参照されている他の全ての文書は、参照により、その全体が本明細書に組み込まれる。
【０００２】
この発明は取引ネットワークにおける有害性に関する。
【背景技術】
【０００３】
様々なシステムで取引の注文を出すことができる。例えば、参照により本明細書に組み込まれる特許文献１は、一側から、対象となるカウンターパーティのグループへ匿名の取引メッセージを送るシステムについて説明している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願第１０／３１０，３４５号（米国特許出願公開第２００４／００３４５９１号）
【発明の概要】
【課題を解決するための手段】
【０００５】
本開示の一態様によれば、分散型取引プラットフォームを操作する方法は、少なくとも１つのプロセッサによって、夫々の、流動性取得者である第２の参加者の取引活動を示す取引活動情報をリアルタイムで通信ネットワークを介して監視することと、取引活動情報に基づいて、第２の参加者に対する夫々の有害性評価をリアルタイムで判定することと、流動性取得者の第１の参加者システムからの通信ネットワークを介して最初の注文を受信することと、最初の注文を受信すると、自動的に第２の参加者夫々の有害性評価から有害性の増加をリアルタイムで判定し、通信ネットワークを介して最初の注文表示情報を第２の参加者夫々の第２の参加者システムに送信して、最初の注文の表示の、第２の参加者システムのうちの各々の第２の参加者システムのディスプレイのグラフィカルユーザインターフェース（ＧＵＩ）上に、第２の参加者に対応する有害性の増加を表示させることと、第２の参加者システムの所与の第２の参加者システムからの通信ネットワークを介して、反対注文を受信することと、反対注文を受信すると、通信ネットワークを介して反対注文を第１の参加者システムに送信することと、通信ネットワークを介して第１の参加者システムから最初の注文に表示されている金融商品の数量が予約されている旨の表示を受信することと、金融商品の数量が予約されている旨の表示を受信すると、反対注文と最初の注文夫々の少なくとも一部を成立させる取引の執行を簡素化することと、を制御することを含んでいてもよい。
【０００６】
一つの代替案では、第２の参加者の所与の第２の参加者に対する所与の有害性の増加は、所与の第２の参加者に対応する所与の有害性レベルの関数として判定してもよい。
【０００７】
一つの代替案では、第２の参加者の所与の第２の参加者に対する所与の有害性の増加は、夫々の有害性レベルに対する所与の有害性の増加を示すルックアップテーブルから判定してもよい。
【０００８】
一つの代替案では、取引活動情報は、通信ネットワークを介して遠隔地の市場データプロバイダから受信したリアルタイムの市場データを含んでいてもよい。
【０００９】
一つの代替案では、第２の参加者の所与の第２の参加者の所与の有害性の増加は、所与の表示情報の一部として通信ネットワークを介して所与の第２の参加者の所与の第２の参加者システムに送信されてもよい。
【００１０】
一つの代替案では、第２の参加者の所与の第２の参加者の所与の有害性の増加及び最初の注文の価格の合計と等しい量が、所与の表示情報の一部として通信ネットワークを介して所与の第２の参加者の所与の第２の参加者システムに送信されてもよい。
【００１１】
一つの代替案では、表示は、最初の注文を、最初の注文の価格の表示とは別に表示される夫々の有害性の増加と共に表示してもよい。
【００１２】
一つの代替案では、表示は、最初の注文を、最初の注文の価格の表示に組み込まれた、夫々の有害性の増加と共に表示してもよい。
【００１３】
一つの代替案では、通信ネットワークを介して、最初の注文表示情報を第２の参加者システムに送信することは、第２の参加者システム夫々のディスプレイに、最初の注文の価格と共に異なる有害性の増加を同時に表示させてもよい。
【００１４】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、通信ネットワークを介して、第２の参加者システムのうち、少なくとも１つの第２の参加者システムのディスプレイのＧＵＩ上にショットクロックの表示に、少なくとも１人の第２の参加者システムに対応する少なくとも１人の第２の参加者に対して残された利用可能時間のカウントダウンを表示して、最初の注文に反応すること、を制御することを更に含んでいてもよい。
【００１５】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、少なくとも１人の第２の参加者に対して残された時間がないとの判定に自動的に呼応して、最初の注文に反応し、通信ネットワークを介して、（ｉ）ショットクロックが、利用可能な時間が満了したことを示し、（ｉｉ）ＧＵＩ上に表示された最初の注文を成立させる取引を執行することを要求する為に操作可能な表示が、最初の注文の再読み込みを要求する為に操作可能な表示に置き換わるように、ＧＵＩ上の表示を再読み込みすること、を制御することを更に含んでいてもよい。
【００１６】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、最初の注文を再読み込みする要求の表示が操作された判定に自動的に呼応して、最初の注文に表示された金融商品の第２の数量が予約されている旨の表示を受信することにより、反対注文と最初の注文の各々の少なくとも一部を成立させる取引の執行を簡素化すること、を制御することを更に含んでいてもよい。
【００１７】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、第２の参加者の所与の第２の参加者に対し、所与の第２の参加者夫々の有害性評価から更新された有害性の増加を判定することと、更新された有害性の増加の判定に自動的に呼応して、通信ネットワークを介してリアルタイムで、更新された有害性の増加を夫々所与の第２の参加者の所与の第２の参加者システム夫々に送信して所与の第２の参加者システム夫々のグラフィカルユーザインターフェースの再読み込みを行わせて、所与の第２の参加者システムに夫々対応する有害性の増加の代わりに更新された有害性の増加を表示すること、を制御することを更に含んでいてもよい。
【００１８】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、第２の参加者が最初の注文を見る資格があるかどうかを判定すること、を制御することを更に含んでいてもよい。
【００１９】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、最初の注文表示情報を、通信ネットワークを介して送信して、第２の参加者システムの証印の夫々を、有害性の増加が見られる最初の注文を受け付ける為に操作可能なボタンとしてＧＵＩ上に表示させること、を制御することを更に含んでいてもよい。
【００２０】
一つの代替案では、方法は、少なくとも１つのプロセッサによって、第１の参加者システムから通信ネットワークを介して受信した流動性提供者の取引の意思を、データベース内に安全に保存すること、を制御することを更に含んでいてもよい。
【００２１】
一つの代替案では、取引の意思は、通信ネットワークを介して受信するときに暗号化されてもよく、少なくとも１つのプロセッサは、取引の意思を復号化することと、取引の意思をデータベースに復号化された形式で保存することと、を制御してもよい。
【００２２】
一つの代替案では、最初の注文表示情報は、夫々暗号化して第２の参加者システムに送信されてもよい。
【００２３】
本開示の一態様によると、分散型取引システムは、流動性提供者の第１の参加者システムであって、第１の参加者システムのトレーダーインターフェースに入力された分散注文照合用の最初の注文を識別することと、通信ネットワークを介して、最初の注文を分散型取引システムの中央システムに送信することと、を制御するように構成された第１のコンピューティングデバイスを含む、第１の参加者システムを含んでいてもよく、中央システムは、夫々の、流動性取得者である第２の参加者の取引活動を示す取引活動情報をリアルタイムで通信ネットワークを介して監視することと、取引活動情報に基づいて、第２の参加者夫々に対する有害性評価をリアルタイムで判定することと、通信ネットワークを介して、第１の参加者システムから、最初の注文を受信することと、最初の注文を受信すると、自動的に、及びリアルタイムで、第２の参加者夫々の有害性評価からの有害性の増加を判定し、通信ネットワークを介して、最初の注文表示情報を第２の参加者夫々の第２の参加者システムに送信して、最初の注文の表示の第２の参加者システムの各第２の参加者システムのディスプレイのグラフィカルユーザインターフェース上に、第２の参加者に対応する有害性の増加を表示させることと、第２の参加者システムの所与の第２の参加者システムからの通信ネットワークを介して、反対注文を受信することと、反対注文を受信すると、通信ネットワークを介して反対注文を第１の参加者システムに送信することと、通信ネットワークを介して第１の参加者システムから最初の注文に表示されている金融商品の数量が予約されている旨の表示を受信することと、金融商品の数量が予約されている旨の表示を受信すると、反対注文と最初の注文夫々の少なくとも一部を成立させる取引の執行を簡素化することと、を制御するように構成された第２のコンピューティングデバイスを含み、第１のコンピューティングデバイスは、通信ネットワークを介して、反対注文を受信することと、通信ネットワークを介して、最初の注文に表示されている金融商品の数量が予約されている旨の表示を送信することと、を制御するように構成されている。
【００２４】
一つの代替案では、取引システムは、更に、第２の参加者システムを含み、第２の参加者システムの各々は、通信ネットワークを介して、最初の注文表示情報を受信することと、グラフィカルユーザインターフェース上に第２の参加者に対応する有害性の増加を有する最初の注文の表示をレンダリングすることと、通信ネットワークを介して、所与の反対注文を送信することと、を制御するように構成された第３のコンピューティングデバイスを含む。
【図面の簡単な説明】
【００２５】
【図１】本明細書で開示されるシステムの少なくとも１つの実施形態によるシステムを示す。
【図２】本明細書で開示される方法の少なくとも１つの実施形態によるフロー図を示す。
【図３】幾つかの実施形態におけるグラフィカルユーザインターフェースの一部となり得るポップアップ要素を示す図である。
【図４】幾つかの実施形態におけるグラフィカルユーザインターフェースの一部となり得る別のポップアップ要素を示す図である。
【発明を実施するための形態】
【００２６】
様々な実施形態は、取引ネットワーク及び／又はインターフェースに向けられたものである。幾つかの実施形態では、分散型システムは、１つ以上の注文管理システムと対話して第１の１人以上の参加者に対して利用可能な注文を判定する。幾つかの実施形態では、分散型システムは、注文管理システムと対話して、利用可能な注文のうち、第２の複数の参加者から一致を求めるべき注文を判定する。様々な実施形態が、従来の取引システム及び従来の取引インターフェースの速度、効率、及び使い易さを向上させる。
【００２７】
一つの例示的な実施形態では、メモリは、執行された時に少なくとも１つのプロセッサに様々なアクションを指示し得る命令を保存している。プロセッサは、市場参加者の注文管理システム（ＯＭＳ）における最初の注文について情報を受信してもよい。プロセッサは、第２の市場参加者の注文管理システムの内容に基づいて、最初の注文を夫々の第２の市場参加者に表示させることによって市場参加者に対する最初の注文を取り扱う又は成立させる際に最初の注文に一致するものを検索してもよい。一致したら、プロセッサは、ＯＭＳにおける注文を予約及び／又は取引の執行を試みてもよい。
【００２８】
幾つかの実施形態は、市場参加者の注文管理システム及び／又は執行管理システムと対話して、対象となる注文の照合を簡易化する為のシステム及び方法を含んでいてもよい。図１は、このような実施形態の少なくとも１つによるシステムを示す。この図示されたシステムの要素及び配置は、あくまでも例示であることを認識しておく必要がある。他の実施形態では、より多い、より少ない、異なる、異なった配置等の要素を含んでいてもよい。
【００２９】
図１の分散型システム１００は、第１の参加者１０１を含む。幾つかの実施形態では、第１の参加者は、購入側のエンティティを含んでいてもよい。第１の参加者は、一連の取引の希望（例えば、取引戦略を追及して様々な金融商品を買う及び／又は売る）を有していてもよい。
【００３０】
このような取引の意思は、一般的に、第１の参加者の注文管理システムで安全に保持される。図１は、注文管理システム１０３を含む第１の参加者を示す。幾つかの実施形態では、このようなシステム１０３は、売買執行管理システム（ＥＭＳ）でもよい、又は売買執行管理システム（ＥＭＳ）を含んでいてもよい。注文管理システム及び売買執行管理システムは、当技術分野で知られており、本開示の目的と互換的に使用してもよい。ＯＭＳ／ＥＭＳの幾つかの例は、Ｆｉｄｅｓｓａ注文管理システム、チャールズリバーＯＭＳ及びブルームバーグ売買執行管理システムを含んでいてもよい。ＯＭＳは、注文状況を追跡してもよく、注文の予約、注文の読み取り、注文のキャンセル、注文成立済みの表示、新規注文の入力等が可能としてもよい。
【００３１】
このような注文管理システムは、権限を有するシステムに対してＯＭＳへの読み取り、書き込み、及び／又は変更機能を提供するアプリケーションプログラミングインターフェース（ＡＰＩ）を含んでいてもよい。トレーダーインターフェースを使用するトレーダーは、ＯＭＳ内の情報に対して入力、受信、及び／又は変更の権限を有していてもよい。第１の参加者システム１０７は、ＯＭＳ内の情報に対して入力、受信、及び／又は変更の権限を有していてもよい。ＯＭＳは、ＡＰＩを通して指示を受け取り、その指示に応答してそのような読み取り、書き込み、及び／又は変更を可能にしてもよい。
【００３２】
幾つかの実施形態では、このようなＯＭＳは、（例えば、トレーダーインターフェース１０５を介して）第１の参加者に対する注文の意思を受信し、第１の参加者システム１０７に注文を伝達し、注文に対する流動性を担保する要求を受信し、他の場所（例えば、ＯＭＳでの注文を取り扱う他の取引所や他のブローカーと）で十分に担保した流動性をキャンセルすることにより、流動性を担保するように試み、流動性の担保の結果を第１の参加者システムに報告し、注文に対する流動性の変更を受信し、及び／又は注文を変更して注文成立済みの流動性を反映させる。
【００３３】
第１の参加者は、１つ以上のトレーダーインターフェースを含んでいてもよい。このようなトレーダーインターフェースの例は１０５で示している。このようなインターフェースは、ＯＭＳ１０３内に保存された取引の意思及び／又は分散型システム若しくはグラフィカルユーザインターフェースを使用して他の場所で取り扱われている注文を入力及び／又は関与し得るトレーダーのワークステーションを含んでいてもよい。幾つかの実施形態では、トレーダーインターフェースを使用して、攻撃性レベルを入力し、分散型システムを通して注文の照合を可能にし、分散型システムからのプロンプトと対話し、及び／又は注文管理システムを介して取引を管理してもよい。第１の参加者は、幾つかの実装形態において多くのトレーダーインターフェースを含んでいてもよい。
【００３４】
第１の参加者は、第１の参加者と分散型システムの中央システム１０９とのインターフェースとなる第１の参加者システム１０７を含んでいてもよい。例えば、第１の参加者システムは、ＯＭＳと対話して、暗号化されている注文についての情報を読み取り、その暗号化された注文の情報を中央システムに送信してもよく、これにより、その暗号化された注文の情報を復号化し、その復号化された注文の情報を中央システムのデータベースに保存してもよい。別の例では、第１の参加者システムはＯＭＳと対話して、注文を予約し、その注文が約定されたことを識別する、或いは、ＯＭＳに情報を書き込む、又は変更してもよい。このような対話を簡易化する為、ＯＭＳは、ＯＭＳのＡＰＩと通信し、及び／又は、ＯＭＳへ及び／又はＯＭＳからのパケット通信をスヌープすると共に分析してもよい。第１の参加者システムは、ＯＭＳから注文を読み取り、それらの注文を、試行した注文照合の為に中央システムに送信し、その注文の少なくとも一部を成立させる一致が、中央システムを介して見つかったという情報を受信し、一致を受信すると、ＯＭＳに流動性の担保を試み、ＯＭＳに流動性の担保に成功したかどうかを知らせ、中央システムを通じて注文の執行の表示を受信し、ＯＭＳを変更して注文の一部の少なくとも一部が成立したことを示してもよい。
【００３５】
幾つかの実施形態では、第１の参加者システムは、トレーダーインターフェース１０５と対話してトレーダーインターフェースを制御して情報を提示する又は、入力を求めてもよい。幾つかの実施形態では、第１の参加者システムは、トレーダーインターフェースを制御してＯＭＳにおける注文に基づいて注文が執行されたら、注文成立の表示を表示してもよい。
【００３６】
幾つかの実施形態では、第１の参加者システムは、中央システム１０９と対話してもよい。例えば、第１の参加者システムは、トレーダーインターフェースを介した入力をプロンプト表示する為の応答についての情報、及び、ＯＭＳにおける注文及び／又は予約についての情報を中央システムに送ってもよく、注文成立及び／又はＯＭＳからの予約に対する要求についての情報を受信してもよい。
【００３７】
第１の参加者の識別されたコンポーネントは、プロセッサ、ワークステーション、ブレード、サーバ、ディスプレイ等のコンピューティングデバイスを含んでいてもよい。識別されたコンポーネントは、本明細書に記載する機能を実行し得るソフトウェア及び／又はハードウェアモジュールを含んでいてもよい。第１の参加者１０１のコンポーネントは、第１の参加者１０１のネットワークを介して互いに対話してもよい。このようなネットワークを、１０２で示す。幾つかの実施形態では、このようなネットワークは、ＬＡＮ或いは有線及び／又は無線コンポーネントによる他のローカルな実在又は仮想ネットワークを含んでいてもよい。要素間の通信は、ＦＩＸ又は他のプロトコルを使って行われてもよい。通信は、取引の意思を安全に保つ、暗号化された通信を含んでいてもよい。
【００３８】
幾つかの実施形態は、中央システム１０９を含んでいてもよい。このような中央システムは、当事者（例えば、第１の参加者）から注文を受信し、その注文（例えば、第２の参加者の照合反対注文に対して）を成立させる取引の執行を簡易化しようと試みる注文照合システムを含んでいてもよい。執行は、幾つかの実施形態において、中央システムから離れた場所にあり得る電子手形交換所を介して実行してもよい。中央システムは、最初の注文を第１の参加者から（例えば、第１の参加者のＯＭＳからの注文を読み取る第１の参加者システムから）受信してもよい。中央システムは、次に、第１の参加者の最初の注文を約定する際に、第２の参加者（例えば、第２の参加者システム）と通信することによって、最初の注文を、複数の第２の参加者に分配してもよい。最初の注文に対する一致の判定がなされたら（例えば、確定注文が第２の参加者によって行われたという、最初の注文の１つに一致する第２の参加者の第２の参加者システムからの表示を受信すること）、最初の注文がもしまだ残っていれば、中央システムは、（例えば、第１の参加者の第１の参加者システムで通信することによって）第１の参加者で反対注文を成立させるのに十分な取引の意思を確保又は担保し、十分な流動性の担保に成功した場合には注文を成立させ（例えば、第１の参加者の第１の参加者システムによって予約が成功したことの表示を受信すると、手形交換所を使用して）、第１の参加者と第２の参加者に（例えば、夫々の参加者システムへの通信によって）執行を通知する。
【００３９】
中央システム１０９は、分散型取引ネットワークに、コンピュータ、サーバ、ハブ、中央プロセッサ、メモリ、及び／又は他のエンティティを備えていてもよい。中央システム１０９は、他の様々なシステム１００要素と通信する為の入出力装置（例えば、ネットワークインターフェース）を構成してもよい。幾つかの実施形態では、中央システム１０９は、取引プラットフォーム、取引又は他の注文処理システムを備えていてもよい。中央システムは、ネットワーク１１０を使って別のシステムと通信してもよい。ネットワークは、パブリックネットワークやプライベートネットワークを含んでいてもよい。ネットワークは、有線又は無線要素を含んでいてもよい。ネットワークは、インターネットを含んでいてもよい。通信は、取引の意思を安全に保つ、暗号化された通信を含んでいてもよい。通信は、幾つかの実装形態では、ＦＩＸプロトコルを使用してもよい。
【００４０】
図１の分散型システムは、第２の参加者を含んでいてもよい。図示のシステムは、２人の第２の参加者１０３ａ及び１０３ｂを含む。第２の参加者１０３ａを詳細に示す。第２の参加者１０３ｂは、同様又は異なる構造を含んでいてもよい。様々な実施形態において、そのような第２の参加者の数は幾つでもよい。
【００４１】
第１の参加者のような、第２の参加者は、一連の取引の希望（例えば、取引戦略を追及して様々な金融商品を売る／買う希望）を有していてもよい。このような取引の意思は、一般的に、第２の参加者の注文管理システムで安全に保持される。図１は、注文管理システム１１１を含む第２の参加者１０３ａを示す。
【００４２】
このような注文管理システムは、権限を有するシステムに対してＯＭＳへの読み取り、書き込み、及び／又は変更機能を提供するＡＰＩを含んでいてもよい。トレーダーインターフェースを使用するトレーダーは、ＯＭＳ内の情報に対して入力、受信、及び／又は変更の権限を有していてもよい。第２の参加者システム１１５は、ＯＭＳ内の情報に対して入力、受信、及び／又は変更の権限を有していてもよい。ＯＭＳは、ＡＰＩを通して指示を受け取り、その指示に応答してそのような読み取り、書き込み、及び／又は変更を可能にしてもよい。
【００４３】
幾つかの実施形態では、このようなＯＭＳは、（例えば、トレーダーインターフェース１１３を介して）第２の参加者に対する注文の意思を受信し、第２の参加者システム１１５に注文を伝達し、流動性を担保する表示を（例えば、トレーダーが承認された取引に対するトレーダーインターフェース及び／又は第２の参加者システムから）受信し、流動性の担保の結果を第２の参加者システムに報告し、注文に対する流動性の変更を受信し、及び／又は注文を変更し、注文成立済みの流動性を反映させる。
【００４４】
第２の参加者は、１つ以上のトレーダーインターフェースを含んでいてもよい。このようなトレーダーインターフェースの例は１１３に示している。このようなインターフェースは、ＯＭＳ１１１内に保存された取引の意思及び分散型システムを介して、又はグラフィカルユーザインターフェースを使用して他の場所で取り扱われている注文を入力及び／又は関与し得るトレーダーワークステーションを含んでいてもよい。幾つかの実施形態では、トレーダーインターフェース１１３を使用して第２の参加者システムからの取引プロンプト表示を受信して応答しても、及び／又は注文管理システムを介して取引を管理してもよい。第２の参加者は、幾つかの実装形態において多くのトレーダーインターフェースを含んでいてもよい。
【００４５】
第２の参加者は、第２の参加者と中央システム１０９とのインターフェースとなる第２の参加者システム１１５を含んでいてもよい。第２の参加者システムは、第２の参加者と中央システム１０９との間のインターフェースを実行してもよい。例えば、第２の参加者システムは、ＯＭＳと対話して、参加者システムが使用して注文についての情報を読み取って、注文にフィルタをかけてもよい。別の例では、第２の参加者システムはＯＭＳと対話して、注文を予約し、その注文が約定されたことを識別する、或いは、ＯＭＳに情報を書き込む、又は変更してもよい。このような対話を簡易化する為、ＯＭＳは、ＯＭＳのＡＰＩと通信し、及び／又は、ＯＭＳへ及び／又はＯＭＳからのパケット通信をスヌープすると共に分析してもよい。
【００４６】
第２の参加者システムは、中央システム及びトレーダーインターフェース及びＯＭＳと対話してもよい。例えば、幾つかの実施形態では、このような第２の参加者システムは、ＯＭＳから注文を読み取り、中央システムから最初の注文を受信し、第２の参加者のＯＭＳから読み取った注文に基づいて最初の注文をフィルタにかけ、最初の注文を第２の参加者のトレーダーインターフェースを介して提示し、最初の注文に一致する第２の参加者から確定注文を受信し、確定注文を受信すると、第２の参加者のＯＭＳの確定注文の為の流動性を担保し、流動性が担保され、及び／又は確定注文を受信すると、確定注文を中央システムに送信し、中央システムから確定注文が成立している旨の表示を受信し、確定注文が成立している旨の表示を受信すると、第２の参加者のＯＭＳを変更して、確定注文が成立していることを示す。
【００４７】
第２の参加者の識別されたコンポーネントは、プロセッサ、ワークステーション、ブレード、サーバ、ディスプレイ等のコンピューティングデバイスを含んでいてもよい。識別されたコンポーネントは、本明細書に記載する機能を実行し得るソフトウェア及び／又はハードウェアモジュールを含んでいてもよい。第２の参加者１０３ａのコンポーネントは、第２の参加者１０３ａのネットワークを介して互いに対話してもよい。このようなネットワークを、１０４で示す。幾つかの実施形態では、このようなネットワークは、ＬＡＮ或いは有線及び／又は無線コンポーネントによる他のローカルな実在又は仮想ネットワークを含んでいてもよい。要素間の通信は、ＦＩＸ又は他のプロトコルを使って行われてもよい。通信は、取引の意思を安全に保つ、暗号化された通信を含んでいてもよい。
【００４８】
幾つかの実施形態では、中央システム、第２の参加者及び／又は第１の参加者のコンポーネントは、ファイアーウォールの背後で、利用者が情報を見られない、又は取得できないようにファイアーウォールの背後で動作してもよい。例えば、第１の参加者のＯＭＳでの最初の注文についての情報は、第２の参加者の第２の参加者システムに少なくとも部分的に暗号化されて通信され、第２の参加者と他のシステム外部の利用者が、その情報の少なくとも一部（例えば、第２の参加者が見る権限を持たない最初の注文等）が見られない、及び／又はアクセスできないようにしてもよい。幾つかの実施形態では、第２の参加者が見る権限を持たない特定の最初の注文は、暗号化されたメッセージで通信され、第２の参加者は、そのメッセージから特定の最初の注文を復号化する必要のある情報は持たないが、暗号化されずに、又は第２の参加者が復号化できる暗号化でそのメッセージに含まれている特定の２回目の注文を見ることができるようにしてもよい。
【００４９】
幾つかの実施形態は、金融商品に関連する情報を提供し得るデータプロバイダ１１７を含んでいてもよい。このような情報は、情報が作成された時、又はそれが最初に一般市民に対して利用可能になった時、又は別の時間にリアルタイムでネットワーク１１０を介して提供されてもよい。データプロバイダ１１７は、そのような情報を、映像、音声（例えば、ラジオ放送）、テキスト（例えばストックティッカー型の情報）、又は情報を伝達し得る他のデータ等のような、１つ以上の様々な形態及び手段で提供してもよい。データは様々な異なるタイミングで提供されてもよい。幾つかの実施形態では、データは、定期的又は連続的に、例えば、データフィード（例えば、取引関連の情報のリアルタイムの更新を含むデータのストリーム）を介して提供されてもよい。幾つかの実施形態では、データは、イベント、例えば取引又は注文の提出後に提供されてもよい。幾つかの実施形態では、データプロバイダ１１７は、中央システム１０９に、取引関連情報を提供してもよい。幾つかの実施形態では、中央システムは、そのような情報を分散型システムの要素に分散してもよい。
【００５０】
システム１００の様々な要素は、非限定的な例としてのみ示されていることを認識すべきである。各コンポーネント、コンポーネントの要素、及び／又はそれら要素の機能性、及び／又は示されている、若しくは記載されているコンポーネントは、異なっていても、同一でも、又は様々な実施形態では存在していなくてもよい。例えば、幾つかの実施形態では、複数の第１の参加者、一人の第２の参加者、及び／又は通信ネットワークを介して中央システムと通信して複数の最初の注文のうちの１つに注文照合を実行する遠隔電子手形交換所がある。別の例として、幾つかの実施形態では、システムは、遠隔地の取引所と通信して、レギュレーション全米市場システム（ＮＭＳ）に準拠することができるようになる。
【００５１】
分散型システム１００は、流動性分散、インターフェースの乱れ、及び従来の取引システム上でのコンピュータリソースの使用を改善する、高速、有効、安全及び利用可能な取引環境を可能にするように動作してもよい。これまで非公開であった取引の意思は、利用可能となり、対象の参加者としての対象当事者に暗号化された状態で安全に配布されてもよい。幾つかの実施形態では、取引の意思は、暗号化され、同時に複数の対象参加者に通信ネットワークを介して提供されてもよく、暗号化された取引情報は、選択された対象参加者の所定の有害性特性に従って選択的に準備され、選択された対象参加者に配布される。よって、本開示は技術的問題に対して技術的な解決策となる技術的な利点を提供するものであり、本開示は、より広く、取引情報を広め、選択された対象の参加者を構成する自然の反対側当事者から情報が広がるのを防止することにより情報の漏洩を制限し、参加者内の送信を、関連性の高い注文のみに制限することで、帯域幅の使用を制限し、注文の提示を、関連性の高い注文のみに制限することでインターフェースの乱れを制限し、短時間で資金源のより最適な分配を行うようにしてもよい。
【００５２】
幾つかの実施形態は、ある方法を含んでいてもよい。このような方法は、分散型システム１００の１つ以上のコンポーネントのようなコンポーネントを含む分散型システムによって実行してもよい。図２は、このような分散型システムの機能性の少なくとも１つの実施形態によるフロー図２００を示す。
【００５３】
各ブロックに記載した各機能は、その機能を実行可能な１つ以上のコンピュータコンポーネントを使用して実行してもよいことは、理解すべきである。また、これらのブロックに記載した行為は、任意の順番（図に示す例示の順序付けを含むがこれに限らない）で実行してもよく、全てのブロックを実行しなくてもよい、また、幾つかのブロックは、一緒に、同時に、及び／又は単一の行為として実行してもよいことは認識すべきである。
【００５４】
ブロック２０５では、システム１００（例えば、中央システム１０９）は、参加者の取引活動を監視し、取引活動に基づいて参加者の有害性評価を判定してもよい。取引活動の監視は、分散型システム１００上で発生する取引活動の監視、及び／又は、（例えば、公開データ及び／又は他の取引所からの情報を通じた）より広い市場での取引活動の監視を含んでいてもよい。取引活動の監視には、特定の参加者との取引が、その取引に関わる金融商品の市場価格に与える影響を監視すること（例えば、データソースから市場データを受信すること）を含んでいてもよい。有害性とは、このような取引が、取引の、反対側当事者に対する金融商品の市場価格に及ぼす影響を指してもよい。
【００５５】
幾つかの実施形態では、システムは、有害性評価に基づいて、第２の参加者を複数の有害性レベル又はグループの１つに入力してもよい。例えば、低い有害性グループ、中間の有害性グループ、及び高い有害性グループを含んでいてもよい。有害性評価は、各参加者をグループのうちの１つに追加することを含んでいてもよい。
【００５６】
有害性測定の一例は、昨年を通して（又はそれ以上又はそれ以下の期間、より最近の活動項目がより重要となるように重み付けされた）、システム１００を通じた取引活動に基づいていてもよい。一例では、取引の１０秒前の金融商品のパフォーマンスと、取引後３０分までの様々な時点でのパフォーマンスを判定してもよい。取引の前後で、価格がどれほど移動したかで判定してもよい。例えば、金融商品の購入後に第２の参加者に対する金融商品の価格が定期的に増加する場合は、第２の参加者は正の有害性レベルを有していることになる。反対に、特定の取引において、第２の参加者が金融商品を購入してその価格が購入後に下がった場合は、その取引は、第２の参加者にとって、負の有害性レベルを有していることになる。幾つかの実施形態で、ある期間における取引の全てにおける有害性レベルは平均化（時間及び／又は数量、直線平均等に基づく重み付け平均）してもよい。特定の第２の参加者に対し、例えば、第２の参加者による購入後に常に価格が上がる場合には、第２の参加者は、有害性が高く、取引コストの高い参加者と見なしてもよい。
【００５７】
有害性レベルは、絶対ベース及び／又はヘッジベースでもよい。例えば、有害性レベルは、Ｓ＆Ｐ５００が、監視期間中（又は他の指標）にどのように動いたかに関連してもよい。ある銘柄が監視期間中にＳ＆Ｐを上回っていた場合、価格の絶対値が下がっても（例えば、下がったがその期間のＳ＆Ｐほどではなかった）有害性がある可能性がある。
【００５８】
幾つかの実施形態では、有害性レベルは、（例えば、金融商品のベストビッドとベストオファーの間の）スプレッドで表されることがある。例えば、有害性レベルは、複数のスプレッドとして表現してもよい。通常の取引を通じて、約２分の１スプレッド分の有害性があると期待するかもしれない。その範囲（及び／又は１スプレッドまで）の有害性は、有害性がないか、もしくは低いと考えられる。幾つかの実施形態では、スプレッドの２倍になると、有害性が高いと考えてもよい。幾つかの実施形態では、スプレッドの１倍から２倍になると、有害性が中程度と考えてもよい。このようなグループの有害性レベルの例は、一例にすぎず、他の実施形態は、他のグループ及び／又はレベルを含んでいてもよいと認識すべきである。
【００５９】
幾つかの実施形態では、第２の参加者は、それらの有害性評価を通知されてもよい。第２の参加者システムは、有害性レベルの指標を受信し、それを保存し、それを後で使用して、注文のフィルタリング及び／又は表示をしてもよい。幾つかの実施形態では、第１の参加者システム又は第２の参加者システム、又は中央システムは、特定の第２の参加者の有害性レベルの指標を暗号化されたデータとして受信し、暗号化された有害性レベルの指標を復号し、復号された有害性レベルの指標を保存し、後で注文のフィルタリング及び／又は表示の為に復号された有害性レベルの指標を使用してもよい。幾つかの実施形態では、各第２の参加者の有害性評価は、その第２の参加者に対しては秘密にしておき、他の第２の参加者が互いの有害性レベルを知ることがないようにしてもよい。
【００６０】
取引は、経時的に監視し、有害性レベルは、新しい情報（例えば、連続的に、毎日、定期的に、取引に応じて自動的に等）に基づいて更新されてもよい。
【００６１】
従来の取引システムでは、高い有害性を有する参加者は避けてもよい。これは、市場の流動性及び効率性を低下させる可能性がある。システム１００は、有害性にも関わらず取引を可能にすることによって、従来のシステムと比較して、本開示の取引システムの速度、利用可能性、及び効率を有利に高めてもよい。
【００６２】
ブロック２１０では、システム１００（例えば、参加者システム１０７）は、システム１００を通じて配布された注文照合に対して指定された第１の参加者１０１の最初の注文（例えば、注文管理システム１０３）を識別してもよい。この識別は、ＡＰＩを通じた注文管理システムからの情報の読取り、ＯＭＳ１０３へ及び／又はＯＭＳ１０３から作成された送信のパケットキャプチャ、分散型システムへの提出の順番を選択するトレーダーインターフェース１０５からの通信から、及び／又は別の方法を通じて若しくは他の入力に呼応して実行してもよい。幾つかの実施形態では、トレーダーインターフェースを使ってＯＭＳにおける特定の注文を指定して、分散型システムを通じた注文照合を行ってもよい。最初の注文には、金融商品（株式、債券、金融派生商品等）のある数量を購入又は売却する注文を含んでいてもよい。例えば、最初の注文は、ＧＯＯＧＬＥ社の株を市場価格で２０，０００株売却するという注文でもよい。この例においては、現在の市場価格は、１４１ドルと仮定できる。
【００６３】
ブロック２１５では、システム１００（例えば、第１の参加者システム１０７）は、最初の注文の有害性の増加を判定してもよい。有害性の増加には、反対側当事者の有害性レベルに基づいて適用された注文価格又は市場価格からの価格変更を含んでいてもよい。有害性の増加は、多くの方法で判定してもよい。例えば、利用者は、トレーダーインターフェースを通じた最初の注文に対する有害性の増加を入力してもよく、注文管理システムは、有害性の増加を保存し、提供してもよく、普遍的な有害性の増加は、全ての注文又は第１の参加者からの全ての注文に適用してもよく、トレーダーは、注文パラメータに基づいて有害性の増加を設定してもよく、有害性の増加は、特定の第２の参加者の又は第２の参加者のトレーダーインターフェースを通じて取引し得る特定のトレーダー等の、レベルの有害性の関数として判定してもよい。有害性の増加は、例えば、異なるレベルの反対側当事者の有害性に適用される価格変更を示してもよい（例えば、非有害性の反対側当事者は増加せず、低レベルの有害性は増加が小さく、高レベルの有害性は、増加が大きい等）。一実施形態では、１つ以上のルックアップテーブルが、システム１００（例えば、第１の参加者システム１０７）のメモリ内に構成されて、夫々の有害性レベルと相互参照された有害性の増加を保存し、また、反対側当事者としての夫々の参加者と相互参照された有害性レベルを保存してもよく、システム１００は、テーブルを使用して、第２の参加者としての特定の潜在的な反対側当事者の特定の有害性レベルに応じて、特定の潜在的な反対側当事者の為の特定の有害性の増加を検索してもよい。
【００６４】
ブロック２２０において、システム１００は、最初の注文及び／又は有害性の増加を中央システム１０９に送信させ、そして受信させてもよい。これは、最初の注文を識別して、及び／又は、有害性の増加を判定したら実行してもよい。このようにして、中央システムは、第１の参加者の注文管理システムに安全に保存されている流動性のダークプールであり得る、一般からは安全に隠されている情報を知ることができる。中央システムは、この情報を使用して、第２の参加者のＯＭＳにある他のダークプールの流動性に隠された注文の一致を検索することができるようになる可能性がある。
【００６５】
ブロック２２５では、最初の注文に関する情報が、システム１００によって第２の参加者に伝達されてもよい。注文は、中央システムから、複数の第２の参加者各々に夫々の第２の参加者システムに送信されてもよい。第２の参加者システムは、注文を受信してもよい。幾つかの実施形態では、注文を送信することは、注文の為の有害性の増加を送信することを含んでいてもよい。
【００６６】
ブロック２３０では、システム１００（例えば、第２の参加者システム１１５）は、第２の参加者のＯＭＳにおける注文を判定してもよい。これは、分散型システム１００の参加者である各第２の参加者に対して行われてもよい。これらの注文は、ＡＰＩを通じた注文管理システムからの情報の読取り、ＯＭＳ１１１へ及び／又はＯＭＳ１１１から作成された送信のパケットキャプチャ、分散型システムへの提出の順番を選択するトレーダーインターフェース１１３からの通信から、及び／又は別の方法を通じて、若しくは他の入力に呼応して判定してもよい。幾つかの実施形態では、トレーダーインターフェースを使ってＯＭＳにおける特定の注文を指定して、分散型システムを通じた注文照合を行ってもよい。
【００６７】
ブロック２３５では、システム１００（例えば、第２の参加者システム１１５）は、第２の参加者が最初の注文を見る権限があるかどうかを判定してもよい。各第２の参加者の各第２の参加者システムは、同様の判定を行ってもよい。
【００６８】
幾つかの実施形態では、第２の参加者が注文を見る権限があるかどうかを判定することは、ブロック２２５からの受信情報を参照することによって、第２の参加者がその注文管理システムにおいて最初の注文に対する反対注文を有しているかどうかを判定することを含んでいてもよい。最初の注文と一致する反対注文がある場合、第２の参加者は最初の注文を見る権限があると判定してもよい。
【００６９】
ブロック２４０では、システム１００（例えば、第２の参加者システム１１５及び／又はトレーダーインターフェース１１３）は、最初の注文に関する情報を第２の参加者（例えば、トレーダーインターフェース１１３を使用するトレーダー）に提示してもよい。この情報は、トレーダーインターフェースのグラフィカルユーザインターフェースを通じて表示してもよい。ポップアップやプロンプトにより、第２の参加者が最初の注文の少なくとも一部を成立させる確定注文をするように求めてもよい。図３は、幾つかの実施形態で使用し得るポップアップインターフェースの例を示す。これにより、第２の参加者には、効率的で安全かつ使いやすいインターフェース体験が提供され、分散型取引システムとの高度な情報交換と迅速な対話が可能になる。
【００７０】
幾つかの実施形態では、情報の提示は、最初の注文を見る権限を有する第２の参加者の各々で実行されてもよい。
【００７１】
幾つかの実施形態は、有害性の増加のうち何れを注文に適用するかを判定することを含んでいてもよい。例えば、最初の注文を、その有害性の増加と共に第２の参加者システムが受け取ってもよい。幾つかの実施形態では、有害性の増加は、最初の注文の価格と合計される量として第２の参加者システムに提供されてもよく、有害性の増加は、最初の注文の価格を含む通信メッセージと同じか、又はそれとは別に提供される。幾つかの実施形態では、有害性の増加と最初の注文の価格の合計に等しい金額が、第２の参加者システムに提供されてもよい。
【００７２】
幾つかの実施形態では、第２の参加者システムは、第２の参加者が現在どの有害性レベルにいるかを判定してもよい。判定された有害性レベルと、上述のようにメモリ内のテーブルから又は有害性レベルの関数として判定される有害性の増加を使用して、第２の参加者システムは、適切な有害性の増加（例えば、参加者の有害性レベルに対する有害性の増加）を注文価格に適用して、注文に対してどのような価格を提示するかを判定してもよい。第２の参加者システムは、第２の参加者に提示される内容に、参加者のクラスに応じたプレミアを付与する。
【００７３】
幾つかの実施形態では、ポップアップウィンドウ（例えば、グラフィカルユーザインターフェース３００）が、トレーダーインターフェース１１３を通じて、権限を有するトレーダーに注文の取引又は棄却をプロンプト表示してもよい。例えば、ポップアップウィンドウには、ボタン３０１のようなオファーに参加する為のオプションを表示してもよい。これは、第１の参加者のＯＭＳにおける最初の注文の取引の側に応じて、（例のように）入札するか、オファーを解除するかのオプションでもよい。ポップアップウィンドウには、ボタン３０３等、オファーを棄却する為のオプションを表示してもよい。ポップアップウィンドウには、サイズインターフェース３０５のような、サイズを調整するオプションを含んでいてもよい。ポップアップウィンドウには、価格３０７（例えば、有害性の増加を適用した価格）の表示を含んでいてもよい。
【００７４】
幾つかの実施形態では、中央システム１０９は、ネットワーク１１０及びシステム１００の外部の通信ネットワークのうちの１つ以上を介して、データプロバイダ１１７からリアルタイムで受信した取引活動情報又はシステム１００上で発生したリアルタイムの取引活動のうちの少なくとも１つに基づいて、システム１００の第２の参加者の取引活動をリアルタイムで監視してもよい。中央システム１０９は、取引活動のリアルタイムの監視に基づいて、夫々の第２の参加者に対する異なる有害性レベルをリアルタイムで判定し、夫々の第２の参加者に対する注文に適用される有害性の増加を動的かつリアルタイムで自動的に更新し、以前に判定された有害性の増加を有する最初の注文の代わりに、有害性の増加を更新した最初の注文を提示する為に、ディスプレイ上のＧＵＩをリアルタイムで自動的に再読み込みさせることができる。
【００７５】
別の実施形態では、図４を参照すると、ポップアップウィンドウ（例えば、グラフィカルユーザインターフェース４００）は、オファーの価格に適用される有害性の増加の量（例えば、＋０．０２）の表示を伴う価格４０２の表示を表示してもよく、この表示は、ＧＵＩ４００を表示するディスプレイと同一又は異なるディスプレイに表示されてもよい。
【００７６】
価格が市場価格（例えば、ベストビッドやオファーの中間値）に連動している幾つかの実施形態では、市場価格の変動に合わせて価格を連続的に更新してもよい。他の実施形態では、図３を参照すると、有害性の増加を含む価格は、ショットクロックインターフェース３０９に示されるある期間、安定していてもよく、これは、第２の参加者がオファーに反応する為に利用可能な時間（例えば、１５秒）を示してもよい。更に他の実施形態では、有害性の増加を含む価格は、市場価格からのオフセットとして表現されてもよく、それは安定していてもよいし、及び／又は実施形態に応じて市場の状況に応じて自動的かつ動的にリアルタイムで調整されてもよい。更に他の実施形態では、有害性の増加を含む価格は、市場価格からのオフセットとして表現されてもよく、このオフセットは、リアルタイムの市場の状況及び第２の参加者に関するリアルタイムの取引活動情報の１つ以上に基づく有害性の増加の変更に応じて、リアルタイムで自動的かつ動的に調整されてもよい。
【００７７】
ブロック２４５において、システム（例えば、第２の参加者システム１１５、トレーダーインターフェース１１３及び／又は中央システム１０９）は、第２の参加者から最初の注文の少なくとも一部を成立させる取引を執行する要求を受信してもよい。例えば、第２の参加者は、トレーダーインターフェースのグラフィカルユーザインターフェースを操作して、オファーの受け入れを示すことができる。リクエストを識別するトレーダーインターフェースから第２の参加者システムに、情報を送信してもよい。
【００７８】
ブロック２５０において、システム（例えば、第２の参加者システム１１５、トレーダーインターフェース１１３及び／又は中央システム１０９）は、取引を執行する要求を受信すると、第２の参加者のＯＭＳにおいて反対注文を予約してもよい。この予約は、第２の参加者システムから、又はトレーダーインターフェースから、第２の参加者のＯＭＳに予約の要求を通信することによって実行してもよい。この反対注文の予約という行為により、反対注文は確定注文となり、予約されている間は他の取引所やブローカーが反対注文に対して行為を行うことができなくなる。
【００７９】
第２の参加者のＯＭＳで取引の執行と流動性の確保の要求を受信することは、様々な方法で行われてもよい。例えば、幾つかの実装形態では、取引を執行する要求が中央システムに送信し、中央システムで受信してもよい（例えば、トレーダーインターフェースから第２の参加者システムに送信し、次に中央システムに送信する）。中央システムは、最初の注文がまだ利用可能であること（例えば、より時間的に優先度の高い別の反対注文よって獲得されていないこと）を判定してもよい。このような判定に応じて、中央システムは、第２の参加者システム及び第２の参加者のＯＭＳを通じて、流動性の確保を要求してもよい。中央システムが、最初の注文が利用できないと判定した場合、中央システムは第２の参加者システムに通知してもよく、流動性の確保は発生しないことがある。
【００８０】
別の例として、流動性の確保は、中央システムに注文が通知される前に行われることがある。第２の参加者システムは、トレーダーインターフェースから要求を受け取り、それに応じてＯＭＳで流動性を担保してもよい。流動性を担保することに応答して、第２の参加者システムは、中央システムに注文を通知してもよい。その後、中央システムは、最初の注文がまだ利用可能であるかどうかを判定してもよい。最初の注文がもしまだ利用可能であれば、この方法を続けてもよい。最初の注文が利用できない（他の場所で一致、及び／又は、キャンセルされた）場合、中央サーバは、第２の参加者に対して確保された流動性を（例えば、第２の参加者システム１１５との通信を通じて）解除してもよい。
【００８１】
ブロック２５５では、第２の参加者のＯＭＳで反対注文を予約することに応答して、システム１００は、第１の参加者のＯＭＳで反対注文を成立させるのに十分な流動性を担保しようと試行してもよい。例えば、第２の参加者システム１１５は、第２の参加者が最初の注文に係わるオファーを受け入れ、反対注文が第２の参加者のＯＭＳに予約されているという表示を受信してもよい。これを受けて、第２の参加者システムは、そのような情報を中央システムに送信してもよい。中央システムは、第２の参加者の第２の参加者システムから情報を受信してもよい。最初の注文がまだ有効である場合、中央システムは、情報を受信すると、第１の参加者の第１の参加者システムに情報を送信して、反対注文を成立させる為の株の予約を要求してもよい。第１の参加者システム１０７は、その情報を受信し、それに応じて、第１の参加者システム１０７は、第１の参加者の注文管理システム１０３と通信して、その株数（例えば、ＧＯＯＧＬＥの１６，０００株）を、中央システムを通じて、執行する為に予約を依頼してもよい。
【００８２】
第１の参加者は、最初の注文の全部又は一部を別の場所で購入している可能性があり、また、本明細書に記載されているプロセスの間に、最初の注文が別の場所でキャンセルされたり、約定されたりする場合があることを理解しておく必要がある。もし、最初の注文が既に他の場所で執行されていたり、キャンセルされていたりすると、第１の参加者のＯＭＳでは反対注文を成立させる為の流動性が得られない可能性がある。このような場合、取引はキャンセルされ、第２の参加者のＯＭＳにおける反対注文の予約が解除されることがある。幾つかの実装形態では、流動性が十分でないにもかかわらず反対注文を継続することができる１００％未満の最小約定パーセンテージ（例えば、９０％）があってもよい。
【００８３】
幾つかの実施形態では、第１の参加者（例えば、第１の参加者ＯＭＳ）によって予約要求が受信されると、最初の注文の一部が他のエンティティによって予約されることがある。このような場合、第１の参加者は反対注文を成立させるのに十分な流動性を担保しようとする可能性がある。このような担保には、まだ取引を完了していない他の取引所及び／又はブローカーの予約をキャンセルすることも含まれる。第１の参加者が十分な流動性を担保することができれば、第１の参加者のＯＭＳは反対注文の為の株を確保してもよい。ＯＭＳは、確保要求を受信すると、十分な流動性を担保する為に、ＯＭＳに流動性を担保している遠隔地の取引先にキャンセルメッセージを送信してもよい。
【００８４】
第１の参加者のＯＭＳに十分な流動性が反映されている場合、あるいは第１の参加者が十分な流動性を担保できている場合、ＯＭＳは株を予約し、第１の参加者システム１０７に株が予約されたことを通知してもよい。幾つかの実施形態では、ある限られた期間、ＯＭＳで株を予約しておくことができる。その期間が過ぎれば、ＯＭＳが株を公開してもよい。他の実施形態では、株を予約しているエンティティが積極的に解放するまで、株は予約しておいてもよい。
【００８５】
ブロック２６０では、第１の参加者のＯＭＳに流動性を担保すると、システム１００は、最初の注文と反対注文の各々の少なくとも一部を成立させる取引の執行を簡易化してもよい。ＯＭＳ１０３によって流動性が担保されたことを示す情報を受信すると、第１の参加者システム１０７は、流動性が担保されたことを中央システム１０９と通信してもよい。そのような情報を受信すると、中央システムは、取引を執行する為のアクションを取ってもよい。例えば、中央システムは、遠隔電子手形交換所と通信して取引を執行してもよい。
【００８６】
取引の価格は、反対側当事者の有害性のレベルに合わせて有害性の増加を適用した最初の注文の価格でもよい。図３及び図４を参照すると、有害性レベル及び第２の参加者が最初の注文を見る権限があることを判定すると、第２の参加者システムにおいてトレーダーインターフェースにこの情報を追加してもよい。このように、幾つかの実施形態では、１つの最初の注文が、異なる反対側当事者に表示される異なる価格を持つ反対注文と合わせる機能を持っていてもよい。注文識別子は、入力された反対注文を追跡する為に使用され、中央システムは、有害性の増加の為に価格が異なる可能性があるにもかかわらず、反対注文が特定の最初の注文に対して一致していると判定してもよい。
【００８７】
幾つかの実施形態では、取引の価格がＮＢＢＯスプレッドの外にある場合、中央システムは遠隔地の取引所と通信し、ＲｅｇＮＭＳの保護された取引所で、より良い価格での注文が取引に含まれるようにしてもよい。この場合、手形交換所で執行される取引は、合意された総量ではない可能性もある。例えば、中央システムは、１つ以上の遠隔地の保護された取引所において、一致した価格よりも良い価格の注文があることを示す市場データを受信してもよい。システムは、最初の注文と反対注文を照合する前に、それらの会場の注文と合わせるように、それらの取引所と通信してもよい。これにより、最初の注文と同サイズの反対注文、又は反対注文から保護された取引所でのより良い価格での注文を差し引いたサイズが残っている場合がある。この残りの注文サイズは、最初の注文と反対注文の残りを約定する為に執行されてもよい。このようにして、最初の注文と反対注文の一方が完全に約定され、他方が部分的に約定されても（保護注文の流動性を欠いても）よい。幾つかの例では、最初の注文が第１の参加者のＯＭＳにおける流動性の一部のみに対するものであり、最初の注文の一部が保護された取引所での注文で約定されている場合、第１の参加者における残りの流動性を使用して、反対注文の残りの部分を約定してもよい。幾つかの実施形態では、各注文に対して少なくとも幾つかの最小約定量（例えば、９０％）がない場合、取引が発生しない場合がある。
【００８８】
ブロック２６５では、取引が執行されたら、システムは、第１の参加者のＯＭＳ及び第２の参加者のＯＭＳのコンテンツを変更してもよい。例えば、中央システムは、特定のパラメータ（例えば、価格、数量、時間）で取引が執行されたことを（例えば、遠隔地の電子手形交換所から受け取った情報に基づいて）判定してもよい。その情報を受信すると、中央システムは、その情報を第１の参加者システム１０７及び第２の参加者システム１１５の夫々に伝達してもよい。第１の参加者システムは、情報を受信し、情報へ反映したら、第１の参加者のＯＭＳのコンテンツを変更してもよい（例えば、ＡＰＩを使用して、ＯＭＳで取引が執行されたことを識別する）。第２の参加者システムは、情報を受信し、情報へ反映したら、第２の参加者のＯＭＳのコンテンツを変更してもよい（例えば、ＡＰＩを使用して、ＯＭＳで取引が執行されたことを識別する）。
【００８９】
ブロック２７０では、第１の参加者のＯＭＳに残っている流動性の為に、後続の最初の注文は、システムを介して処理されてもよい。例えば、取引を執行することで、第１の参加者のＯＭＳで通常保留される最初の注文の一部が成立している可能性がある。第１の参加者のＯＭＳには、同じ金融商品の保留注文が残っていてもよい（例：総数量が少ない）。残りの流動性は、分散型システムで処理してもよい。この処理は、本明細書に記載されているプロセスと同様でよい。
【００９０】
幾つかの実施形態では、参加者の相互の匿名性を維持してもよい。当事者の身元は、他の当事者には隠しておいてもよい。このようにして、情報漏洩を更に低減できる。
【００９１】
現代の市場参加者は、信じられないほど複雑なアルゴリズムとデータ処理技術を使って、取引戦略を開発し実装していると認識されている。これらのアルゴリズムは、世界最高水準のコンピュータによって実行される。しかし、そのようなコンピュータであっても、限りある資源には限界がある。取引戦略の処理に必要なデータ量を削減することで、これらのマシンの機能を向上させ、限りある計算資源の影響を拡大することができる。有害性の増加を伴う取引注文を、承認された対象参加者のみに選択的に送信することで、取引を執行する為に処理され、送信されるデータ量を削減してもよい。これにより、処理時間、ストレージの必要性、及び取引戦略の処理と実装に使用されるその他の計算資源（電力、帯域幅等）が削減される可能性がある。有害性の増加に対応した取引注文を選択的に送信することで、より使いやすく、効率的に運用される市場が生まれる可能性がある。
【００９２】
幾つかの実施形態では、図４を参照すると、オファーに反応する為に利用可能な時間が満了したときに自動的に呼応して、ＧＵＩ４００のプレゼンテーション上のショットクロックインターフェース４０９が更新され、第１のオファーの残り時間、例えば１秒の提示から、第１のオファーに反応する為に利用可能な時間が満了したことを示す「ＥＸＰＩＲＥＤ」等の提示に切り替わってもよい。幾つかの実施形態では、トレーダーは、ＧＵＩ４００を操作して、ＧＵＩ４００上の再読み込みボタン４０４をクリックすることにより、取引の希望を示してもよい。再読み込みボタンが操作されると自動的に呼応して、第１の参加者（又は中央システム）は、最初の注文又はその一部が利用可能なままであるかどうかを判定し、はいの場合、ショットクロックが終了する前に取引の執行要求がなされる実施形態について上述したのと同様に、最初の注文又はその利用可能な残りの部分の取引が執行されてもよい。幾つかの実施形態では、ショットクロックインターフェース３０９は、リアルタイムのカウントダウンクロックとしてのインターフェースを通じて第２の参加者に提示されてもよい。幾つかの実装形態では、期間の終わりに達したことを示す表示が、第２の参加者に（例えば、その期間に加えて、その期間の代わりに、色を変えることによって、音を鳴らすことによって、インターフェースを通じて、等）送信されてもよい。
【００９３】
幾つかの実施形態では、最初の注文の取引を執行する為に残っている時間の量の表示が、１人以上の第２の参加者に送信されてもよい。幾つかの実装形態では、期間が終了したことを示す表示が、１人以上の第２の参加者に示されてもよい。幾つかの実施形態では、ショットダウンクロックを用いてＧＵＩに表示される最初の注文を執行する期間は、第２の参加者に対して、夫々の異なる有害性レベルに応じて異なっていてもよい。
【００９４】
上記の説明は、非限定的な例の動作を説明する為に含まれるものであり、本開示の範囲を限定するものではない。上記の議論から、関連する技術分野の当業者には、本開示の精神と範囲にまだ包含されるであろう、多くの変形例が明らかになるであろう。
【００９５】
例えば、中央システムの観点から例を挙げているが、他の実施形態ではそのような中央システムを含まない場合もあることを認識しておく必要がある。例えば、１つ以上の参加者システムは、幾つかの実装形態において、中央システムの１つ以上の機能を実行してもよい。他の実装形態では、参加者のシステムや中央システムを含まなくてもよく、ＯＭＳが両方の要素の役割を果たしてもよい。更に別の例では、参加者システムの一部として説明されている役割は、中央システム、ＯＭＳ、又は相手側の参加者システムによって実行されてもよい。例えば、参加者システムではなく参加者のＯＭＳからの注文情報を中央システムが維持している幾つかの実装形態では、第１の参加者に対して承認された第２の参加者及び承認された第２の参加者の有害性レベルに応じた注文フィルタリングは、中央システムによって実行されてもよい。
【００９６】
別の例として、幾つかの実施形態では、参加者システムではなく中央システムで有害性の価格増加を実行してもよい。その為、１つの増加した注文を各第２の参加者に送信してもよい。その単一の注文は、第２の参加者の有害性レベルに基づいて、第２の参加者によって異なる場合がある。中央システムは、各第２の参加者の有害性レベルを追跡し、夫々の第２の参加者に同時に注文を送信する前に、選択的に増加を適用してもよい。
【００９７】
したがって、本開示は、第２の参加者としての複数の対象となる当事者を、ディスプレイの夫々のＧＵＩ上で、夫々の有害性の増加を含む取引情報を、提示された取引を執行する為に行動する為のリアルタイムの情報と共に、リアルタイムで提示することを同時に可能にすることによって、コンピュータ及びコンピュータネットワークに改善を提供するものである。本開示のこのような改良は、ネットワーク及びコンピュータ技術に根ざしており、コンピュータネットワーク及びコンピュータの領域で具体的に生じる技術的問題を克服するものである。更に、本開示は、改良されたグラフィカルユーザインターフェースを提供し、これにより、参加者における電子計算機の使用効率を高めることができる。更に、中央システムは、有利なことに、自分の取引意図を他の参加者に明らかにされたくない異なる遠隔地の異なる取引当事者との、通信ネットワークを介した安全な暗号化通信を制御して、第２の参加者システムのＧＵＩ上で選択された取引情報をリアルタイムで安全に提示し、中央システムを介して取引関連情報をリアルタイムで安全に交換することを、夫々の第２の参加者システムでそのＧＵＩを介して取られたアクションに自動的に呼応して提供してもよい。したがって、本開示は、コンピュータネットワークの領域で生じるソフトウェア技術の問題に対する解決策を開示している。開示されたＧＵＩソリューションは、トレーダーの商取引の精度を向上させることで、技術の機能性を改善する。
【００９８】
別の例として、中央システムは、有害性のレベル毎に別々の注文控元帳を含んでいてもよい。最初の注文は、有害性レベルが適用された各注文控元帳にコピーされてもよい。中央システムは、注文控元帳間の注文をリンクさせてもよい。ある注文が約定されると、その約定された注文は、複数の注文控元帳にまたがる全ての注文に適用されてもよい。
【００９９】
別の例として、最初の注文は、確定注文としてシステム１００に提出されてもよい。このような例では、流動性は提出時にＯＭＳに確保される。したがって、第２の参加者との照合後に、第１の参加者に流動性を担保する必要はない場合もある。
【０１００】
更に別の例として、幾つかの実施形態は、システム１００及びダークプール又はＯＭＳへのアクセスに関して説明してきたが、他の実施形態は、ダークプール又はＯＭＳへのアクセスを含まない取引環境に、より一般的に適用してもよい。例えば、ＦｅｎｉｃｓＵＳＴやＡｑｕａｔｒａｄｉｎｇｓｙｓｔｅｍのようなシステムでは、参加者の有害性の増加を利用してもよい。
【０１０１】
ここで説明した様々なプロセスが、例えば、適切にプログラムされた特別目的のコンピュータやコンピューティングデバイスによって実施することができることは、通常の技術者であれば容易に理解できるだろう。典型的には、プロセッサ（例えば、１つ以上のマイクロプロセッサ、１つ以上のマイクロコントローラ、１つ以上のデジタルシグナルプロセッサ）が（例えば、メモリ等のデバイスから）命令を受け取り、それらの命令を実行することで、それらの命令によって定義された１つ以上のプロセスを実行する。指示は、例えば、１つ以上のコンピュータプログラム、１つ以上のスクリプトで具現化してもよい。
【０１０２】
プロセッサは、アーキテクチャ（例えば、チップレベルのマルチプロセッシング又はマルチコア、ＲＩＳＣ、ＣＩＳＣ、パイプラインステージが連動していないマイクロプロセッサ、パイプライン構成、同時マルチスレッディング、統合グラフィックス処理ユニット付きマイクロプロセッサ、ＧＰＧＰＵ等）にかかわらず、１つ以上のマイクロプロセッサ、中央処理装置（ＣＰＵ）、コンピューティングデバイス、マイクロコントローラ、デジタルシグナルプロセッサ、グラフィックス処理ユニット（ＧＰＵ）等のデバイス、又はそれらの任意の組み合わせを含んでいてもよい。
【０１０３】
コンピューティングデバイスの幾つかは、プロセスの各ステップを実行する為に共に動作してもよいし、プロセスの別々のステップで動作してもよいし、プロセスの実行を簡易化することが可能な他のコンピューティングデバイスに基礎的なサービスを提供してもよい。このようなコンピューティングデバイスは、中央管理局の指示の下で作動してもよい。別の実施形態では、そのようなコンピューティングデバイスは、中央管理局の指示無しに作動してもよい。これらの方法の一部又は全部で動作する装置の例としては、グリッドコンピュータシステム、クラウドコンピュータシステム、ピアツーピアコンピュータシステム、サービスとしてのソフトウェアを提供するように構成されたコンピュータシステム等を含んでいてもよい。例えば、装置は、ＶＭｗａｒｅソフトウェアを実行するコンピュータシステムのように、処理負荷の大部分を遠隔地のサーバで実行するが、ローカルのユーザコンピュータに表示情報を出力したり、利用者の入力情報を受信したりするコンピュータシステムを備えていてもよい。
【０１０４】
更に、そのような方法を実装するプログラム（他のタイプのデータも同様）は、様々な媒体（例えば、コンピュータ可読媒体）を使用して、多くの方法で保存及び送信してもよい。幾つかの実施形態では、ハードワイヤード回路又はカスタムハードウェアを、様々な実施形態のプロセスを実装できるソフトウェア命令の一部又は全部の代わりに、又はそれらと組み合わせて使用してもよい。その為、ソフトウェアのみではなく、代わりにハードウェアとソフトウェアの様々な組み合わせが使用可能である。
【０１０５】
コンピュータ読み取り可能な媒体は、不揮発性媒体、揮発性媒体、伝送媒体等、限定しないが様々な形態を取ることができる。不揮発性媒体には、例えば、光ディスクや磁気ディスク等の永続的なメモリがある。揮発性媒体には、典型的にはメインメモリを構成するＤＲＡＭ（ダイナミックランダムアクセスメモリ）がある。伝送媒体には、同軸ケーブル、銅線、光ファイバー等があり、プロセッサに結合されたシステムバスを構成する電線も含まれる。伝送媒体には、音響波、光波、及び無線周波（ＲＦ）や赤外線（ＩＲ）のデータ通信で発生するような電磁放射が含まれたり、搬送されたりする。コンピュータ可読媒体の共通の形態としては、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、その他の磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ、その他の光学媒体、パンチカード、紙テープ、その他の穴の開いた物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ（登録商標）−ＥＥＰＲＯＭ、その他のメモリチップやカートリッジ、後述する搬送波、その他コンピュータが読み取り可能な媒体等が挙げられる。
【０１０６】
様々な形態のコンピュータ可読媒体が、データ（命令のシーケンス等）をプロセッサに運ぶことに関わってもよい。例えば、データは、（ｉ）ＲＡＭからプロセッサに配信されても、（ｉｉ）無線伝送媒体を介して搬送されても、（ｉｉｉ）イーサネット（又はＩＥＥＥ８０２．３）、ＩＥＥＥ８０２．１１仕様で、ＷｉＦｉＡｌｌｉａｎｃｅで承認されているかどうかが定義された無線ローカルエリアネットワーク通信、ＳＡＰ、ＡＴＰ、ＢｌｕｅｔｏｏｔｈＴＭ、及びＴＣＰ／ＩＰ、ＴＤＭＡ、ＣＤＭＡ、３Ｇ等の多数のフォーマットや標準、プロトコルに従ってフォーマット及び／又は送信されても、及び／又は（ｉｖ）暗号化してプライバシーを確保する、あるいは、当技術分野で周知の様々な方法のいずれかで不正を防止してもよい。
【０１０７】
様々な実施形態は、１つ以上のデバイスと（例えば、通信ネットワークを介して）通信しているコンピュータを含むネットワーク環境で動作するように構成してもよい。コンピュータは、任意の有線又は無線媒体（インターネット、ＬＡＮ、ＷＡＮ又はイーサネット、トークンリング、電話回線、ケーブル回線、無線チャネル、光通信回線、商用オンラインサービスプロバイダ、掲示板システム、衛星通信リンク、上記のいずれかの組み合わせ等）を介して、直接又は間接的にデバイスと通信してもよい。各デバイスは、それ自体が、コンピュータや、Ｉｎｔｅｌ登録商標、Ｐｅｎｔｉｕｍ登録商標、又はＣｅｎｔｒｉｎｏＴＭ、ＡｔｏｍＴＭ、ＣｏｒｅＴＭプロセッサをベースにした、コンピュータと通信するように適合された他のコンピューティングデバイスを構成してもよい。任意の数と種類のデバイスが、コンピュータと通信状態にあってもよい。
【０１０８】
一実施形態では、サーバコンピュータや中央管理局は必要ではなく、望ましいものではないこともある。例えば、本発明は、一実施形態では、中央機関のない１つ以上のデバイスで実施してもよい。そのような実施形態では、サーバコンピュータによって実行されると本明細書に記載されているあらゆる機能、又はサーバコンピュータに保存されていると記載されているデータは、代わりに１つ以上のそのようなデバイスによって実行されるか、又はそのようなデバイスに保存されていてもよい。
【０１０９】
プロセスが記載されている場合、一実施形態では、プロセスは利用者の介入無しに自動的に動作することがある。別の実施形態では、プロセスは何らかの人間の介入を含む（例えば、あるステップは、人間によって、又は人間の助けを借りて実行される）。
【０１１０】
幾つかの実施形態では、暗号化のプロセスを使用して、平文と呼ばれる生の情報を暗号化された情報に変換してもよい。暗号化された情報を暗号文と呼ぶことがあり、平文を暗号文に変換するアルゴリズムを暗号と呼ぶことがある。また、暗号は、暗号文を平文に戻すという逆の操作を行う為にも使われる。暗号の例としては、置換暗号、転置暗号、ロータマシンを使った暗号等がある。
【０１１１】
様々な暗号化方式において、暗号は鍵と呼ばれる補助的な情報を必要とする場合がある。鍵は、例えば、ビット列で構成されている。鍵は、平文を暗号化する為に、暗号と組み合わせて使用してもよい。鍵は、暗号文を復号化する為に、暗号と組み合わせて使用してもよい。対称鍵アルゴリズム（例えば、秘密鍵暗号）と呼ばれるカテゴリーの暗号では、暗号化と復号化の両方に同じ鍵が使用される。このように、暗号化された情報の尊厳は、鍵が秘密にされているかどうかにかかっている。対称鍵アルゴリズムの例としては、ＤＥＳとＡＥＳがある。非対称鍵アルゴリズム（例えば、公開鍵暗号）と呼ばれるカテゴリーの暗号では、暗号化と復号化には異なる鍵を使用する。非対称鍵アルゴリズムでは、公衆の誰もが第１の鍵（例えば、公開鍵）を使用して平文を暗号文に暗号化してもよい。しかし、第２の鍵（例えば、秘密鍵）を持つ人だけが、暗号文を復号して平文に戻すことができる。非対称鍵アルゴリズムの例として、ＲＳＡアルゴリズムがある。
【０１１２】
数多くの実施形態が本願明細書に記載されているが、これは例示を目的としたものである。説明された実施形態は、いかなる意味でも限定的なものではなく、またそのように意図されたものでもない。本開示の開示発明は、開示内容から容易に分かるように、多数の実施形態に広く適用可能である。当業者であれば、開示された発明本開示は、構造的、論理的、ソフトウェア的、電気的な変更等、様々な修正や変更を加えて実施できることを認識するだろう。開示された本開示発明の特定の特徴は、１つ以上の特定の実施形態及び／又は図面を参照して説明されることがあるが、明示的に別の方法で指定されない限り、そのような特徴は、それらが説明されている１つ以上の特定の実施形態又は図面での使用に限定されないことが理解されるべきである。
【符号の説明】
【０１１３】
１００  分散型システム
１０１  第１の参加者
１０２  ネットワーク
１０３  注文管理システム
１０３ａ  第２の参加者
１０３ｂ  第２の参加者
１０４  ネットワーク
１０５  トレーダーインターフェース
１０７  第１の参加者システム
１０９  中央システム
１１０  ネットワーク
１１１  注文管理システム
１１３  トレーダーインターフェース
１１５  第２の参加者システム
１１７  データプロバイダ
【図１】
2021535525.tif 000003
【図２】
2021535525.tif 000004
【図３】
2021535525.tif 000005
【図４】
2021535525.tif 000006
【国際調査報告】
2021535525.tif 000007