(57)【特許請求の範囲】
【請求項１】
接続された少なくとも１つのコンピュータを有するコンピュータネットワークを介してコンピュータによって金融取引を行う方法であって、
第１のクライアント・コンピュータが、金融取引の要求を受け取ることと、
前記第１のクライアント・コンピュータのプロセッサが、前記第１のクライアント・コンピュータにおいて、ユーザインタフェースを動作させ、前記第１のクライアント・コンピュータのスクリーン上で金融取引の組み立てを可能にし、証券、資金、支払、デビット、口座残高、貸付及び借入の少なくとも１つを含む金融取引に関する情報を受け取って表示することと、
前記第１のクライアント・コンピュータが前記金融取引の要求を第２のクライアント・コンピュータ又は第１のサーバ・コンピュータに供給すること、
前記第２のクライアント・コンピュータまたは前記第１のサーバ・コンピュータのプロセッサは、前記金融取引に関する情報に取引番号をコードスタンプし、前記金融取引に関する情報を、前記スクリーン上での表示のために第１のクライアント・コンピュータに提供し、
第２のクライアント・コンピュータまたは第１のサーバ・コンピュータのプロセッサは、送金エンティティと受取エンティティと送金額とを含むベクトルである関連エンティティの複数の金融取引のベクトルをマクロ元帳に記録し、前記マクロ元帳から同一当事者を有するゼロ和対の成分を削除し、前記マクロ元帳を充足する新しい金融取引のベクトルの組合せを生成することにより、各関連エンティティの金融取引による流入又は流出の総額を変更せずに前記関連エンティティ間の複数の金融取引のベクトルの組合せを変更して、全関連エンティティの取引量又は取引回数を低減させ、
前記第２のクライアント・コンピュータ又は前記第１のサーバ・コンピュータのプロセッサが、ベクトルが変更された前記金融取引の実行に含まれる全関連エンティティのチェックを開始させ、当該関連エンティティから前記金融取引に関する最終的な情報を受け取って、前記最終的な情報を実行命令に変換し、前記実行命令を開始することにより、コンピュータ及びネットワークインフラ上の資本移動を実行する、
方法。
【請求項２】
前記第１のクライアント・コンピュータからの、シミュレーション要求を送るユーザーに関する情報に応じて、前記第１のクライアント・コンピュータからシミュレーション要求を受けた前記少なくとも第１のサーバ・コンピュータの前記プロセッサが、前記金融取引をシミュレーションすることをさらに含む請求項１記載の方法。
【請求項３】
前記第２のクライアント・コンピュータおよび前記第１のサーバ・コンピュータのいずれかのプロセッサによって、前記金融取引の情報を将来の検索のために保存することをさらに含む請求項１記載の方法。
【請求項４】
前記金融取引を他の金融取引と統合して複合金融取引を構成する、請求項３記載の方法。
【請求項５】
接続された少なくとも１つのコンピュータを有するコンピュータネットワークを介して金融取引を行うように構成された金融サービス・システムであって、
第１のクライアント・コンピュータが、金融取引の要求を受け取る手段と、
前記第１のクライアント・コンピュータのプロセッサが、前記第１のクライアント・コンピュータにおいて、ユーザインタフェースを動作させ、前記第１のクライアント・コンピュータのスクリーン上で金融取引の組み立てを可能にし、証券、資金、支払、デビット、口座残高、貸付及び借入の少なくとも１つを含む金融取引に関する情報を受け取って表示する手段と、
前記第１のクライアント・コンピュータが前記金融取引の要求を第２のクライアント・コンピュータ又は第１のサーバ・コンピュータに供給する手段と、
前記第２のクライアント・コンピュータまたは前記第１のサーバ・コンピュータのプロセッサは、前記金融取引に関する情報に取引番号をコードスタンプし、前記金融取引に関する情報を、前記スクリーン上での表示のために第１のクライアント・コンピュータに提供する手段と、
第２のクライアント・コンピュータまたは第１のサーバ・コンピュータのプロセッサは、送金エンティティと受取エンティティと送金額とを含むベクトルである関連エンティティの複数の金融取引のベクトルをマクロ元帳に記録し、前記マクロ元帳から同一当事者を有するゼロ和対の成分を削除し、前記マクロ元帳を充足する新しい金融取引のベクトルの組合せを生成することにより、各関連エンティティの金融取引による流入又は流出の総額を変更せずに前記関連エンティティ間の複数の金融取引のベクトルの組合せを変更して、全関連エンティティの取引量又は取引回数を低減させる手段と、
前記第２のクライアント・コンピュータ又は前記第１のサーバ・コンピュータのプロセッサが、ベクトルが変更された前記金融取引の実行に含まれる全関連エンティティのチェックを開始させ、当該関連エンティティから前記金融取引に関する最終的な情報を受け取って、前記最終的な情報を実行命令に変換し、前記実行命令を開始することにより、コンピュータ及びネットワークインフラ上の資本移動を実行する手段とを備える、
金融サービス・システム。
【請求項６】
接続された少なくとも１つのコンピュータを有するコンピュータネットワークを介して金融取引を行うように構成されたコンピュータ・システムによって実行されるプログラムを記録するコンピュータ読み取り可能な記録媒体であって、
前記プログラムは、前記コンピュータ・システムに、
第１のクライアント・コンピュータが、金融取引の要求を受け取ることと、
前記第１のクライアント・コンピュータのプロセッサが、前記第１のクライアント・コンピュータにおいて、ユーザインタフェースを動作させ、前記第１のクライアント・コンピュータのスクリーン上で金融取引の組み立てを可能にし、証券、資金、支払、デビット、口座残高、貸付及び借入の少なくとも１つを含む金融取引に関する情報を受け取って表示することと、
前記第１のクライアント・コンピュータが前記金融取引の要求を第２のクライアント・コンピュータ又は第１のサーバ・コンピュータに供給すること、
前記第２のクライアント・コンピュータまたは前記第１のサーバ・コンピュータのプロセッサは、前記金融取引に関する情報に取引番号をコードスタンプし、前記金融取引に関する情報を、前記スクリーン上での表示のために第１のクライアント・コンピュータに提供し、
第２のクライアント・コンピュータまたは第１のサーバ・コンピュータのプロセッサは、送金エンティティと受取エンティティと送金額とを含むベクトルである関連エンティティの複数の金融取引のベクトルをマクロ元帳に記録し、前記マクロ元帳から同一当事者を有するゼロ和対の成分を削除し、前記マクロ元帳を充足する新しい金融取引のベクトルの組合せを生成することにより、各関連エンティティの金融取引による流入又は流出の総額を変更せずに前記関連エンティティ間の複数の金融取引のベクトルの組合せを変更して、全関連エンティティの取引量又は取引回数を低減させ、
前記第２のクライアント・コンピュータ又は前記第１のサーバ・コンピュータのプロセッサが、ベクトルが変更された前記金融取引の実行に含まれる全関連エンティティのチェックを開始させ、当該関連エンティティから前記金融取引に関する最終的な情報を受け取って、前記最終的な情報を実行命令に変換し、前記実行命令を開始することにより、コンピュータ及びネットワークインフラ上の資本移動を実行すること、
を実行させる記録媒体。
【請求項７】
接続された少なくとも１つのコンピュータを有するコンピュータネットワークを介して金融取引を行うように構成されたコンピュータ・システムであって、
前記コンピュータ・システムは、
プログラムを格納する少なくとも１つのメモリと、
前記プログラムを実行する少なくとも１つのプロセッサと、
を含み、前記プログラムは、前記少なくとも１つのプロセッサによって実行されることにより、前記コンピュータ・システムに、
第１のクライアント・コンピュータが、金融取引の要求を受け取ることと、
前記第１のクライアント・コンピュータのプロセッサが、前記第１のクライアント・コンピュータにおいて、ユーザインタフェースを動作させ、前記第１のクライアント・コンピュータのスクリーン上で金融取引の組み立てを可能にし、証券、資金、支払、デビット、口座残高、貸付及び借入の少なくとも１つを含む金融取引に関する情報を受け取って表示することと、
前記第１のクライアント・コンピュータが前記金融取引の要求を第２のクライアント・コンピュータ又は第１のサーバ・コンピュータに供給すること、
前記第２のクライアント・コンピュータまたは前記第１のサーバ・コンピュータのプロセッサは、前記金融取引に関する情報に取引番号をコードスタンプし、前記金融取引に関する情報を、前記スクリーン上での表示のために第１のクライアント・コンピュータに提供し、
第２のクライアント・コンピュータまたは第１のサーバ・コンピュータのプロセッサは、送金エンティティと受取エンティティと送金額とを含むベクトルである関連エンティティの複数の金融取引のベクトルをマクロ元帳に記録し、前記マクロ元帳から同一当事者を有するゼロ和対の成分を削除し、前記マクロ元帳を充足する新しい金融取引のベクトルの組合せを生成することにより、各関連エンティティの金融取引による流入又は流出の総額を変更せずに前記関連エンティティ間の複数の金融取引のベクトルの組合せを変更して、全関連エンティティの取引量又は取引回数を低減させ、
前記第２のクライアント・コンピュータ又は前記第１のサーバ・コンピュータのプロセッサが、ベクトルが変更された前記金融取引の実行に含まれる全関連エンティティのチェックを開始させ、当該関連エンティティから前記金融取引に関する最終的な情報を受け取って、前記最終的な情報を実行命令に変換し、前記実行命令を開始することにより、コンピュータ及びネットワークインフラ上の資本移動を実行すること、
を実行させるコンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、包括的には、グローバル・コンピュータ・ネットワークを介して複数の金融取引を行なうことができる自動分散型金融または資本システムの装置および方法に関する。
【背景技術】
【０００２】
金融サービスにおいて、地理は、特に地理的距離が通貨、法律、および政治領域の違いにより複雑化する場合に大きな障壁である。金融取引処理の自動化（Straight through processing）および動作の能率化を行なう、世界経済における将来の展望および完全なシステム化のための全ての要求にもかかわらず、特に統合グローバル金融サービスを処理するように設計されたアーキテクチャを提供する組織は依然として存在しない。
なお、本出願に対応する外国の特許出願においては下記の文献が発見または提出されて
いる。
【特許文献１】国際公開第０２／００５１９５号パンフレット
【特許文献２】国際公開第０１／０５３９７７号パンフレット
【特許文献３】米国特許第５７０４０４５号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明は、グローバル・コンピュータ・ネットワークを介して複数の金融取引を行なうことができる自動分散型資本システムの装置および方法に関する。
【課題を解決するための手段】
【０００４】
本発明の分散型資本システム（ＤＣＳ）は、特に、２つの大きなカテゴリ、すなわち従来型（個人）および共同型（複数当事者）に入る取引を管理することが可能である。これら２つのカテゴリは取引範囲を網羅し、ここに記載される本発明のＤＣＳは、取引イベント（料金の支払い、外国為替等）の組み立て、テスト、実行、および管理を網羅し、これらは独特のものである。
【０００５】
具体的には、本発明のＤＣＳは、取引の中でも特に、料金支払いの構造化、管理および実行、請求書発行の構造化、管理、および実行、振り込みの開始および管理、世界中の当事者間が対称（すなわち、取引の双方の当事者が、相対する相手方と全額交換する同等の価値を保持する）であるか、非対称（取引の双方の当事者が異なる額を保持する）であるか（特に通貨）に関わりなく（中間ブローカーまたは第３者の金融機関なしで）、国際振替なしの資金の本国送金や代替可能なユニットの直接交換を含む分散（拡散）資金振替（ＤＦＴ）の開始および管理、自動化された外国為替市場、プログラムされたクレジット・カード支払いのスケジューリング、世界中でのＡＴＭ手数料支払いの回避、従来の為替取引を必要としない、異なる通貨でのオンライン購入取引、消費者金融・直接融資システム、分散型信用格付けシステム、無制限の参加者からの少額から巨額の金額を処理するシンジケーションシステム、ならびに個人的または他人と共同してプログラムされた投機的投資を処理する。
【０００６】
具体的には、本発明の態様は、インターネット等のコンピュータ・ネットワークを介して複数の金融取引を行なうことができる自動分散型資本システムに関する。本発明の分散型資本システム（ＤＣＳ）は、任意の数の当事者間で任意の種別の金融取引を管理する。したがって、例えば、当事者が特定貨幣価値または交換価値分の金融取引を実行したい場合で、かつ第１の相手方が全ての貨幣価値または交換価値に対する取引を実行することができない場合に、本発明のＤＣＳは、取引を完全に実行することができるまで、さらに別の相手方を自動的に取得する。したがって、ネットワーク上の様々な当事者に分散される十分な価値がある限り、本発明のＤＣＳは任意の価値の金融取引を実行することが可能である。
【０００７】
金融取引を開始する当事者が相手方を選択したり、または本発明のＤＣＳがそうした相手方を自動的に取得したりすることもできる。さらに、相手方はネットワーク上のどこにいても可能である。したがって、ネットワークが例えばインターネットである場合、本発明による方法およびシステムは、地理的境界に制限されない。本発明のＤＣＳは、様々な国の当事者間で取引を実行することができ、また、各交換通貨を自動的に交換することができる。
【０００８】
その結果、分散型資本システムは、任意の数の当事者が共同して任意の額の価値を任意の数の相手方と取引することを可能にし、独立した市場から導き出されるレートおよび期間を調整して、価値の移転を処理する。これは例えば、ブローカー等の仲介者なしで行われる。
【０００９】
任意の数の当事者および相手方が存在し得るため、ＤＣＳは、例えば、一人の当事者と一人の相手方（従来簡易型）、同時にいくつかの従来簡易取引を実行する一人の当事者（従来複合型）、一人の当事者と複数の相手方（共同簡易型）、および複数の当事者と複数の相手方（共同複合型）を含む金融取引を実行することができる。
【００１０】
本発明による方法によれば、プログラムを有するデータ処理システムにおける方法が提供される。データ処理システムは、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つと接続される。その方法は、プログラムにより実行されるステップを含んでおり、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と少なくとも１つの金融取引を実行する要求をユーザーから受け取り、金融取引に関連するリアルタイム金融情報を取得して、金融取引を少なくとも一人の当事者と実行することができるかを確認する。
【００１１】
本発明による方法によれば、プログラムを有するデータ処理システムにおける方法が提供される。データ処理システムは、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続される。その方法は、プログラムにより実行されるステップを含んでおり、データ処理システムの１つにそれぞれ対応する複数の当事者の少なくとも一人と、少なくとも１つの金融取引を実行する要求をユーザーから受け取り、金融取引に関連するリアルタイム金融情報を取得して、金融取引の貨幣価値または交換価値を判定するステップ、貨幣価値または交換価値分の金融取引を実行することになる少なくとも一人の当事者か否かを判定し、識別された少なくとも一人の当事者が、貨幣価値または交換価値分の金融取引を実行しないことに応答して、当事者が金融取引を実行する全貨幣価値または全交換価値が、金融取引の所定の貨幣価値または交換価値に等しくなるまで、金融取引を少なくとも一人の当事者の他にさらなる当事者と実行することができるかを確認する。
【００１２】
本発明による製品によれば、データ処理システムに方法を実行させる命令を含むコンピュータ可読媒体が提供される。データ処理システムは、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続される。その方法は、プログラムにより実行されるステップを含んでおり、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と、少なくとも１つの金融取引を実行する要求をユーザーから受け取り、金融取引に関連するリアルタイム金融情報を取得して、金融取引を少なくとも一人の当事者と実行することができるかを確認する。
【００１３】
本発明による製品によれば、データ処理システムに方法を実行させる命令を含むコンピュータ可読媒体が提供される。データ処理システムは、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続される。その方法は、プログラムにより実行されるステップを含んでおり、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と少なくとも１つの金融取引とを実行する要求をユーザーから受け取り、金融取引に関連するリアルタイム金融情報を取得して、金融取引の貨幣価値または交換価値を判定し、貨幣価値または交換価値分の金融取引を実行することになる少なくとも一人の当事者か否かを判定して、識別された少なくとも一人の当事者が、貨幣価値分または交換価値の金融取引を実行しないことに応答して、当事者が金融取引を実行する全貨幣価値または交換価値が金融取引の所定の貨幣価値または交換価値に等しくなるまで、金融取引を少なくとも一人の当事者の他にさらなる当事者と実行することができるかを確認する。
【００１４】
本発明によるシステムによれば、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続されたデータ処理システムが提供される。データ処理システムは、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と、少なくとも１つの金融取引とを実行する要求をユーザーから受け取る手段、金融取引に関連するリアルタイム金融情報を取得する手段、および金融取引を少なくとも一人の当事者と実行することができるかを確認する手段を備える。
【００１５】
本発明によるシステムによれば、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続されたデータ処理システムが提供される。データ処理システムは、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と、少なくとも１つの金融取引とを実行する要求をユーザーから受け取る手段、金融取引に関連するリアルタイム金融情報を取得する手段、金融取引の貨幣価値または交換価値を判定する手段、貨幣価値または交換価値分の金融取引を実行することになる少なくとも一人の当事者か否かを判定する手段、および識別された少なくとも一人の当事者が、貨幣価値または交換価値分の金融取引を実行しないことに応答して、当事者が金融取引を実行する全貨幣価値または全交換価値が金融取引の所定の貨幣価値または交換価値に等しくなるまで、金融取引を少なくとも一人の当事者の他にさらなる当事者と実行することができるかを確認する手段を備える。
【００１６】
本発明によるシステムによれば、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続されたデータ処理システムが提供される。データ処理システムは、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と、少なくとも１つの金融取引とを実行する要求をユーザーから受け取り、金融取引に関連するリアルタイム金融情報を取得し、金融取引を少なくとも一人の当事者と実行することができるかを確認するプログラムを含むメモリ、ならびにプログラムを実行する処理ユニットを備える。
【００１７】
本発明によるシステムによれば、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続されたデータ処理システムが提供される。データ処理システムは、データ処理システムの１つに、それぞれ対応する複数の当事者の少なくとも一人と、少なくとも１つの金融取引とを実行する要求をユーザーから受け取り、金融取引に関連するリアルタイム金融情報を取得し、金融取引の貨幣価値または交換価値を判定し、貨幣価値または交換価値分の金融取引を実行することになる少なくとも一人の当事者か否かを判定し、識別された少なくとも一人の当事者が、貨幣価値または交換価値分の金融取引を実行しないことに応答して、当事者が金融取引を実行する全貨幣価値または全交換価値が金融取引の所定の貨幣価値または交換価値に等しくなるまで、金融取引を少なくとも一人の当事者の他にさらなる当事者と実行することができるかを確認するプログラムを含むメモリ、ならびにプログラムを実行する処理ユニットを備える。
【００１８】
本発明による製品によれば、データ構造を有するプログラムがエンコードされたコンピュータ可読メモリデバイスが提供される。プログラムは、ネットワークを介して複数の遠隔データ処理システムの少なくとも１つに接続されたデータ処理システム内のプロセッサによって実行される。データ構造は複数のエントリーを有し、各エントリーは、金融取引の貨幣価値または交換価値を記憶する第１の記憶領域、および金融取引の当事者のＩＤおよび当事者が金融取引を実行する額をそれぞれ記憶した複数の第２の記憶領域を含み、プログラムは、当事者が金融取引を実行する総額が貨幣価値または交換価値と等しくなるまで、さらなる当事者、およびさらなる有資格当事者が金融取引を実行する額を確認する。
【００１９】
こうして、以下の本発明の詳細な説明をよりよく理解することができ、また当技術分野に対する本発明の貢献をよりよく理解することができるように、本発明によるいくつかの特徴を概説した。したがって、以下述べる、本明細書に添付される特許請求項の主題を成す本発明によるさらなる特徴が当然存在する。
【００２０】
この点に関して、本発明による少なくとも１つの実施形態を詳細に説明する前に、本発明の適用は、以下の説明に述べられる、または図面に示される構成要素の構造および配置の詳細に限定されないことを理解されたい。本発明による方法および装置は、他の実施形態が可能であり、また、様々な方法で実施し実行することが可能である。また、本明細書ならびに以下に含まれる要約書に使用される表現および用語は、説明を目的としており、限定とみなされるべきではないことを理解されたい。
【００２１】
したがって、当業者は、本開示が基となる概念を、本発明のいくつかの目的を実行する他の構造、方法、およびシステムの設計のベースとして容易に利用できることを理解するであろう。したがって、本発明による方法および装置の精神および範囲から逸脱しない限り、このような等価の構造を包含するものとして特許請求項を解釈することが重要である。
【図面の簡単な説明】
【００２２】
【図１】図１は、本発明に適合する一実施形態に基づいた、クライアント−サーバ環境を示す概略図である。
【図２】図２は、本発明に適合する一実施形態に基づいた、分散型ネットワーク環境を示す概略図である。
【図３】図３は、本発明に適合する一実施形態に基づいた、クライアント−サーバ環境内のクライアントおよびサーバをより詳細に示す概略図である。
【図４】図４は、本発明に適合する一実施形態に基づいた、金融取引を遂行するにあたって分散ベクトル解決プログラム・モジュールにより単一平均を使用して平衡がとられた要求を示す図である。
【図５】図５は、本発明に適合する一実施形態に基づいた、金融取引を遂行する際に分散ベクトル解決プログラム・モジュール(the Spread-Vector Resolution program module)により複数平均を使用して平衡した要求(a balanced request)を示す図である。
【図６】図６は、本発明に適合する一実施形態に基づいた、金融取引を遂行する際に分散ベクトル解決プログラム・モジュール(the Spread-Vector Resolution program module)によって処理される非対称マッチング(an asymmetric matching)を示す図である。
【図７Ａ】図７Ａは、本発明に適合する一実施形態に基づいた、金融取引を遂行する際に分散ベクトル解決プログラム・モジュール(the Spread-Vector Resolution program module)により処理される右側全探索マッチング(an all-seek opposite-side match)を示す図である。
【図７Ｂ】図７Ｂは、本発明に適合する一実施形態に基づいた、分散ベクトル解決プログラム・モジュール(the Spread-Vector Resolution program module)に提供されるシステムへの資本注入(a capital infusion)を示す図である。
【図８Ａ】図８Ａは、本発明に適合する一実施形態に基づいた分散ベクトル総計(Spread-Vector Netting)を示す。
【図８Ｂ】図８Ｂは、本発明に適合する一実施形態に基づいた分散ベクトル総計(Spread-Vector Netting)を示す。
【図９】図９は、本発明に適合する一実施形態に基づいた、符号分割多重取引プログラム・モジュール(the Code Division Multiple Transaction program module)の機能を示す。
【図１０】図１０は、本発明に適合する一実施形態に基づいた、符号分割多重取引プログラム・モジュール(the Code Division Multiple Transaction program module)の機能を示す。
【図１１Ａ】図１１Ａは、本発明に適合する一実施形態に基づいた、従来簡易型取引(the Traditional Simple transaction)の動作を示すフローチャートを示す。
【図１１Ｂ】図１１Ｂは、本発明に適合する一実施形態に基づいた、従来簡易型取引(the Traditional Simple transaction)の動作を示すフローチャートを示す。
【図１２】図１２は、本発明に適合する一実施形態に基づいたユーザー・インタフェースの取引ワークパッド(the Transaction Workpad)の画面ショットである。
【図１３】図１３は、本発明に適合する一実施形態に基づいたユーザー・インタフェースの取引ワークパッド(the Transaction Workpad)の画面ショットである。
【図１４】図１４は、本発明に適合する一実施形態に基づいた、ユーザー・インタフェースの取引ワークパッド(the Transaction Workpad)上での未組み立て従来簡易型取引(an unassembled Traditional Simple transaction)の画面ショットである。
【図１５】図１５は、本発明に適合する一実施形態に基づいた、ユーザー・インタフェースの取引ワークパッド(the Transaction Workpad)上での組み立て済従来簡易型取引(an assembled Traditional Simple transaction)の画面ショットである。
【図１６】図１６は、本発明に適合する一実施形態に基づいた、取引シンタックス承認済従来簡易型取引(a transaction syntax approved Traditional Simple transaction)の画面ショットである。
【図１７】図１７は、本発明に適合する一実施形態に基づいた、従来簡易型取引(a Traditional Simple transaction)に伴うリアルタイム・シミュレーション実行データ(a real-time simulated execution data)の画面ショットである。
【図１８】図１８は、本発明に適合する一実施形態に基づいた、組み立て済従来複合型取引(an assembled Traditional Compound transaction)の画面ショットである。
【図１９】図１９は、本発明に適合する一実施形態に基づいた、組み立て済共同簡易型取引(an assembled Collaborative Simple transaction)の画面ショットである。
【図２０】図２０は、本発明に適合する一実施形態に基づいた、共同複合型取引(a Collaborative Compound transaction)を行なう方法のフローチャートである。
【図２１Ａ】図２１Ａは、本発明に適合する一実施形態に基づいた、共同複合型取引(a Collaborative Compound transaction)における符号分割多重取引プログラム・モジュール(the Code Division Multiple Transaction program module)により保持されるマクロ元帳(a macro ledger)を示す表である。
【図２１Ｂ】図２１Ｂは、本発明に適合する一実施形態に基づいた、分散ベクトル解決プログラム・モジュール(the Spread-Vector Resolution program module)により処理中の共同複合取引に対する当事者を示す図である。
【図２１Ｃ】図２１Ｃは、本発明に適合する一実施形態に基づいた、共同複合型取引(a Collaborative Compound transaction)における符号分割多重取引プログラム・モジュール(the Code Division Multiple Transaction program module)により保持される、経験的に減じられたマクロ元帳(a macro ledger)を示す表である。
【発明を実施するための形態】
【００２３】
本発明に適合する方法およびシステムは、グローバル・コンピュータ・ネットワークを介して自動分散型金融サービスを利用可能にする。中でも特に、本発明のシステムは、個人が共同して（任意の少額（particulate amount）を）任意の人物または企業に貸し付け、独立して市場から導き出されるレートおよび期間を調整できるようにし、それからまた、システムに払い戻しの分配を処理させる。分散型資本システムは、ブローカーなしで任意所望の額の貨幣を交換し、従来の方法よりも高速かつ安価に、株式、債券、または他の代替可能な証券トレードの相手方とマッチングさせる。本発明による分散型資本システムは、スケーラビリティ、ネットワークエフェクト、およびオープンコミュニティの概念を含む。
【００２４】
本発明による方法およびシステムは、ネットワーク共同取引サービスをサポートするように設計された拡張的システムを含む。この共同フォーマットはより高度であり、従来のシステムよりも多くのシステムアーキテクチャを必要とすることから、現在の取引構造（一対一商取引関係）は本発明の共同実施形態の機能の部分集合として可能である。
【００２５】
システムアーキテクチャ
これより、本発明の一実施形態について、本発明による方法およびシステムの実施に適した金融システムを示す図を参照して考察する。
【００２６】
本発明は、クライアント−サーバ環境（図１参照）において実施しても、またはクライアント・コンピュータのみが利用される分散型環境（図２参照）において実施してもよい。したがって本発明では、特定の動作またはサービスは、クライアントあるいはサーバのどちらか一方において、ネットワークの端または中央、あるいは両方において行われ得る。したがって、クライアントまたはサーバのどちらか一方、または両方において、所望の動作／サービスに対応するプログラムを利用することが可能である。本発明では、クライアントおよびサーバにおける対応するプログラムの対は、ユーザーから見ればそれぞれ同じ動作を実行する場合であっても、図２に示すような分散型機能ネットワーク内のクライアント・コンピュータにおいて動作を完全に実行させることを含め、システムの内部では異なる動作を実行してもよい。
【００２７】
より具体的には、本発明の分散型金融ネットワークでは、ネットワーク上のあらゆるノードが最近傍のセットを有し、各ノードが近傍と認識世界(awareness universe)を共有する。したがって、問い合わせを自律的に要求する当事者に再び関連付けることができる。本発明は、これを「認識伝搬（awareness propagation）」と呼ぶ。したがって、本発明の動作は図２に示すクライアント・コンピュータだけでも提供することが可能である。
【００２８】
しかし、少なくとも１つのクライアント・コンピュータ、およびおそらく、少なくとも１つのサーバコンピュータを本発明による方法およびシステムの実施に使用し得ることが好ましい。
【００２９】
クライアント−サーバ環境では、少なくとも１つのクライアントおよび少なくとも１つのサーバはそれぞれ、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、および／またはインターネット等のネットワーク（図１参照）に通信リンクを介して接続される。本発明に適合する方法でのステップは、クライアントまたはサーバ、あるいは両方において実行され、サーバが使用される場合、クライアントは、ブラウザアプリケーション等を使用して、例えばインターネットを介してサーバにアクセスすることが可能である。
【００３０】
具体的には、図１〜図３に示すクライアントは、クライアントから離れた（すなわち、サーバにある）金融サービスにアクセスする際にユーザーが操作する、パーソナルコンピュータ、モバイルコンピューティング装置、携帯電話、またはモバイルデータオーガナイザ等の移動端末であり得る。２つのクライアントのみが図１に示されるが、当業者は、他のクライアントまたはサーバに接続された複数の同様のクライアントがあり得ることを認めるであろう。
【００３１】
図３に示すように、クライアント・コンピュータ１０は通常、クライアントデータ処理手段または機構としてプロセッサ１１を備え、プロセッサ１１は、中央演算処理装置（ＣＰＵ）１２および入出力（Ｉ／Ｏ）インタフェース１３と、データ構造１６を有するプログラム１５を具備したメモリ１４（これらは全てバス１７によって接続されている）と、入力装置または手段１８と、ディスプレイ１９とを備えており、補助記憶装置２０もまた備えてもよい。バス１７は、クライアント１０の内部にあることが好ましく、キーボードまたは入力装置１８へのアダプタを備えてもよく、または外部接続を備えてもよい。
【００３２】
データ構造１６は複数のエントリーを含むことができ、各エントリーは、金融取引の貨幣価値または交換価値を記憶する第１の記憶領域と、金融取引に対する当事者のＩＤおよび当事者が金融取引を実行する額をそれぞれ記憶する複数の第２の記憶領域とを少なくとも含み、プログラムは、当事者が金融取引を実行する総額が貨幣価値または交換価値と等しくなるまで、さらなる当事者およびそのさらなる有資格当事者が金融取引を実行する額を確認する。データ構造はまた、当業者が以下の説明から認めるような、マッチ・コードまたは他の記憶情報と関連付けられたものを含んでいる代わりの実施形態を有することも可能である。
【００３３】
本発明に適合する方法およびシステムでは、クライアント１０は、アドレスまたはポートにより指定される通信終端ポートを使用して、クライアント通信手段または機構としての通信リンク２１を介して他のクライアント１０またはサーバ３０に接続され、通信リンクは、モバイル通信リンク、交換回線通信リンクを含むことができ、また、ＬＡＮ、ＷＡＮ、インターネット、もしくはこれらの組み合わせ等のデータ処理装置ネットワークを含むことができる。通信リンク２１は、サーバ３０との通信を確立し維持するために、様々な通信プロトコルを実行可能なアダプタユニットであることが好ましい。通信リンク２１は、専用ハードウェアにより構成されてもよく、または対応するプログラム命令を実行する汎用ＣＰＵにより実現されてもよい。通信リンク２１は、少なくとも部分的に、対応するプログラム命令を実行するプロセッサ１１に包含され得る。
【００３４】
クライアント１０におけるプロセッサ１１は、プロセッサ１１の内部にあっても外部にあってもよく、所定の動作に適用されたプログラム１５を実行する。プロセッサ１１は、所定の動作を実行するプログラム１５およびデータ構造１６を含む少なくとも１つのコード命令シーケンスを記憶可能なメモリ１４にアクセスすることができる。メモリ１４およびプログラム１５は、回路１０の内部にあっても外部にあってもよい。
【００３５】
プログラム１５は、所望の動作またはサービスを実行する別個のプログラムコードを含んでもよく、または、サービスを提供するより大きなプログラムのモジュールの一部であってもよい。プログラム１５は、以下さらに述べるサービスの下位動作を実行する複数のモジュールも含み得る。
【００３６】
プロセッサ１１は、複数のサービス／動作に対応する複数のプログラム１５にアクセスし、かつ／または複数のプログラム１５を実行するように適合し得ることが理解される。
【００３７】
プログラム１５により行われる動作またはサービスは、例えば、ユーザー・インタフェースのサポート、電子メールアプリケーションの実行、金融取引のセットアップ等であることができる。
【００３８】
クライアント１０の入力手段１８は、キーボード、マウス、または音声処理手段等の標準的な入力装置を含み得る。
【００３９】
記憶装置２０は、特定のサービスをユーザーに提供するにあたり、テキストファイル、データファイル、イメージ、オーディオ、ビデオファイル等の少なくとも１つのデータファイルを記憶する。記憶手段２０としてのデータ記憶装置は、例えばデータベースであることがよく、そのデータベースは、例えばネットワーク２２を介して接続された分散型データベースを含んでいる。記憶装置２０は、直接またはＬＡＮあるいはＷＡＮ等の通信ネットワークを通してサーバ３０および／またはクライアント１０に接続することができる。２０等の内部記憶装置または外部記憶装置２３は任意選択であり、データも、例えばネットワーク２２を介して受け取って直接処理してもよい。
【００４０】
サーバ３０は、非分散環境で使用される場合、サーバデータ処理手段または機構であるＣＰＵ２５やＩ／Ｏインタフェース２６を有するプロセッサ２４をよく備えているが、１つまたは複数のマシン上に個々のプロセッサ２４を複数含む分散型ＣＰＵ２５によって構成されてもよい。サーバ３０のプロセッサ２４は、汎用データ処理ユニットであってもよいが、好ましくは、大量資源、すなわち高い処理能力および大量のデータを記憶する大容量のメモリを有するデータ処理ユニットであり得る。
【００４１】
サーバ３０はまた、データ構造２９を有するプログラム２８を備えたメモリ２７も含んでおり、これらは全てバス３１によって接続されている。バス３１または同様の接続ラインは、サーバ３０が分散型システムによって構成されている場合には、外部接続から成ってもよい。サーバプロセッサ２４は、様々なサービスをユーザーに提供するため、すなわちクライアント１０を操作するユーザーが望む様々な金融操作を実行するために、好ましくは多数のプログラムを記憶する記憶装置（すなわち、記憶装置３２）にアクセスすることができる。
【００４２】
データ構造２９は、複数のエントリーを含むことがよく、各エントリーは、金融取引の貨幣価値または交換価値を記憶する第１の記憶領域と、金融取引に対する当事者のＩＤおよび当事者が金融取引を実行する額をそれぞれ記憶する複数の第２の記憶領域とを少なくとも含み、プログラムは、当事者が金融取引を実行する総額が貨幣価値または交換価値と等しくなるまで、さらなる当事者およびそのさらなる有資格当事者が金融取引を実行する額を確認する。データ構造は、当業者が以下の説明から認めるような、制御コードまたは他の記憶情報に関連するものを含んだ代わりの実施形態を有することができる。
【００４３】
サーバ３０は単一のユニットであっても、複数のサーバ３０またはデータ処理ユニットの分散システムであってもよく、互いに直接または間接的に接続して複数のユーザーが共有してもよい。サーバ３０は、所望の動作に関する少なくとも１つのサーバプログラム２８を実行するが、これはクライアント１０からの要求に応える際に必要である。
【００４４】
サーバ３０からの通信リンク３３は、複数のクライアント１０と通信するように適合されることが好ましい。
【００４５】
サーバプログラム２８は、金融取引を組み立てられるようにすること、提案された金融取引をテストできるようにすること、各取引要求が一意の取引番号を使用してコード・スタンプされ、金融システムを通してセキュリティ追跡されていることを確実にすること等をユーザーができるように、ユーザーへの金融サービスの提供に関連する複数の動作を提供することを関連付けることができる。
【００４６】
本発明のシステムは、場合によっては、特定の機能を実行するものとして説明されることに留意されたい。しかし当業者は、プログラムは、システム自体のエンティティではなく機能を実行するものであることがわかるだろう。
【００４７】
本発明の一実施態様の態様はメモリに記憶されているものとして示されるが、当業者は、本発明に適合したシステムおよび方法の全てまたは一部が、ハードディスク、フロッピーディスク、およびＣＤ−ＲＯＭ、インターネット等のネットワークから受信する搬送波、または現在既知の、あるいは将来開発される他の形のＲＯＭまたはＲＡＭのような補助記憶装置等、他のコンピュータ可読媒体に記憶しても、またはそこから読み取ってもよいことを認めるであろう。さらに、システムの特定の構成要素を説明したが、当業者は、本発明による方法およびシステムとの併用に適したシステムは追加の、または異なる構成要素を含み得ることを認めるであろう。
【００４８】
上述した特徴および処理動作は、専用ハードウェアにより実現しても、またはデータ処理ユニットで実行されるコード命令を含むプログラムとして実現してもよいことに留意されたい。さらに、上述した動作順序の一部はハードウェアで実行されることが可能であるのに対して、上述した処理動作の他の部分はソフトウェアを使用して実行されることも可能である。
【００４９】
さらに、本発明による方法およびシステムは、メニューの選択ボタン、ダイアログ・ボックス、またはクライアントにおいて提供されるインタフェースのロールダウン・ウィンドウを含むユーザー選択手段を提供することにより実行され、ユーザーはキーボード等を通してコマンドを入力することができる。選択手段は、ハードウェアの専用部分によって構成されてもよく、また、その機能を、例えば、選択ウィンドウを表示するディスプレイ・ユニットおよび選択を入力するキーボードを含め、クライアント・プロセッサで実行されるコード命令により実行してもよい。
【００５０】
プログラム・モジュール
本発明のプログラム（少なくとも１５または２８のいずれか一方、あるいは両方）の一実施形態は、４つの主要プログラム・モジュールを含む：ベクトルフロー・トポグラフィ（ＶｆＴ）、符号分割多重取引（ＣＤＭＸ）、分散ベクトル解決（ＳＶＲ）、およびマトリックス・クォーター・マスター（matrix quartermaster）（ＭａＱｓ）。各プログラム・モジュールは、様々な新金融サービスを独立してサポートすることが可能であり、また他のアプリケーションに独立して使用することが可能であるが、互いに共に結び付けられており、以下さらに述べるように提携して他のプログラム・モジュールとともに働き、本発明による分散型資本システムプラットフォームを作る。
【００５１】
ただし、当業者は、本発明の特徴の達成に使用し得るさらなるモジュールまたはプログラムがあり得ること、また、プログラム・モジュールは同じ目的のために単一のプログラムに組み合わせ得ることがわかろう。さらに、５つの主要なプログラム・モジュールの特徴および処理動作は、専用ハードウェアにより実現されてもよく、またデータ処理ユニットで実行されるコード命令を含むプログラムとして実現されてもよい。上述した動作順序の一部はハードウェアで実行されることが可能であるのに対して、上述した処理動作の他の部分はソフトウェアを使用して実行されることも可能である。
【００５２】
上に述べたように、以下の本発明によるプログラム・モジュールは、分散型資本システムアーキテクチャの親プログラムにより実行することができ、クライアント−サーバ環境の一部であっても、またはクライアント・コンピュータの分散プラットフォームの一部であってもよい。
【００５３】
１）ベクトルフロー・トポグラフィ・プログラム・モジュール
ベクトルフロー・トポグラフィ（ＶｆＴ）・プログラム・モジュールは、ユーザー・インタフェースを実行し、全種の取引の簡素化された構造、テスト、および管理を可能にする。ＶｆＴモジュールは、ユーザーに対して、画面上取引ワークパッド上に調整され結び付けられた視覚的オブジェクトとの金融取引を素早く構築させて、それから証券および資金、支払い、デビット、口座残高等の提案された流れを実行前にテストさせることができる。ＶｆＴプログラム・モジュールは、また、取引後または取引の詳細が最初にシステムに入力された後での任意の他の時間に、各種データ、確認、および他の表示を受け取り、ユーザーに表示する。
【００５４】
それゆえに、ユーザーは取引イベントを構築して保存し、望むたびごとにそれらを再利用することができる。このＶｆＴプログラム・モジュールにより、ユーザーは、構築された取引の全ての実行およびテストの履歴に容易にアクセスでき、履歴情報はＣＤＭＸプログラム・モジュールにより追跡される、以下参照）。このようにして、ユーザーは随時、各自のいずれの取引イベントにおけるありとあらゆる詳細を再び見ることができる。
【００５５】
料金支払い等のような単純な取引の組み立ておよび実行を可能にしながら、ＶｆＴプログラム・モジュールは、高度で複雑な、または「複合」と呼ばれる取引もまた処理を行ない、「複合」は、所望される位置の商業的結果を実現するために、複数または複合の暫定的なステップや取引を構成するものとして定義される。ＶｆＴプログラム・モジュールの「ドラッグ・アンド・ドロップ」機能により、複合取引を容易に組み立て、テストし、実行することができる。
【００５６】
２）符号分割多重取引（ＣＤＭＸ）プログラム・モジュール
ＣＤＭＸプログラム・モジュールは、本発明の分散型資本システムを可能にする追跡および会計を実行する。ＣＤＭＸプログラム・モジュールは、２種類のデータ（金融および通信）を同時に安全かつ非公開で処理し、二次元間の関係を保持・使用するが、それでもなお伝送の完全な分離、機密性、および匿名性を保持する。したがってＣＤＭＸプログラム・モジュールは、通信プロトコルおよび取引プロトコルを両方とも採用し、厳密なデータ要件を監視してマッチングさせ、相手方とのマッチングのマクロ的な意味に従って、無作為当事者のつながりを完全に無作為な当事者に対して実現できるようにする（これはＳＶＲプログラム・モジュール中のアルゴリズムにより処理される、以下参照）。ＣＤＭＸプログラムは、複数平均マッチング・エンジン（ＳＶＲモジュール−以下参照）とインタフェースして、無作為当事者のマッチングを完了し、考案された追跡コードを本発明のＤＣＳにおける額に適宜添付する。金融ベクトルが異なるより小さな構成要素に分割される場合であっても、または後に再び組み合わせられるか否かにかかわらず、ＣＤＭＸプログラム・モジュールは、全ての構成要素をゼロ和会計環境内のシステムを経るときに追跡する。
【００５７】
ＣＤＭＸプログラム・モジュールは、ユーザー・プログラム取引の４つの種別またはカテゴリ、すなわちリアルタイム、パッシブ、固定、および分割を追跡する。リアルタイムは、取引要求の実行時か、それとも設定時間が経過したときかにかかわらず、即時処理を意味する。パッシブは、ユーザーが処理のタイミングまたは額を決めず、ユーザーが示した時間制限が経過する前に、システムが要求をアットランダムに、かつ／または最適なときに実行することを意味する。固定は、ユーザーが実行要件セットを示しており、要件が見合うことによりトリガーされない限り取引が行われないことを意味する。分割は、その他の３種別の組み合わせ（例えば、所定の時間に行われる同じ取引であってもよい）からなり、組み合わせは、システムに入るとより小さな構成要素取引に分けられ、それぞれに、全ての分割を全体の親取引にリンクする特別な親コードがタグ付けされる。
【００５８】
ＣＤＭＸモジュールのプロトコルは、従来簡易型イベントであれ、それとも共同複合イベントであれ（より詳細に以下述べる）、適切なデータベースにＣＤＭＸモジュール元帳により保存され記録されているあらゆる取引詳細を用いて、プログラムを巻き戻して元の口座、任意の取引を遡ることができるように設計された。分散型資金移転（ＤＦＴ）取引が豊富であり、意図するターゲット口座がすぐには見えない分散型環境であっても、ＣＤＭＸプログラム・モジュールは、プログラムのＣＤＭＸ元帳、または分散したクライアント／サーバ／サーベント（servent）の非常に小さな部分集合でも分散を事後に（post facto）再構築できるようにし、資金移転ネットワークを巻き戻して再見し、任意の分散型資本システム取引の詳細（すなわち、何を、どのようにして、どれだけ、誰が等）を確認することができる。
【００５９】
ＣＤＭＸプログラム・モジュールが記録する情報は、分散型クライアント／サーバ／サーベントでさえも暗号化された形で保持され、召還等のような公的な法的行為による等、システム監視者による慎重な行動による以外は、誰も入手することは不可能である。ＣＤＭＸプログラム・モジュールはまた、達成されたＣＤＭＸデータを調整のために中央収集／監視サーバ等に自動的に送る、分散型装置に常駐する組み込み機能も含むことができる。
【００６０】
本発明のＣＤＭＸプログラム・モジュールは、以下の関数すなわち、ａ）コード・スタンプ、ｂ）コードサイクリング、およびｃ）コード・マッチ集約を実行する。
【００６１】
コード・スタンプおよびコード・マッチ集約サブプログラムは、マトリックス・クォーター・マスター・モジュール（さらに以下述べる）と手続きの関係を有し、コードサイクリングサブプログラムは、分散ベクトル解決プログラム・モジュール（さらに以下述べる）との反復的交換を含む対話型プロセスを実行することに留意されたい。
【００６２】
コード・スタンプに関して、コード・スタンプは、任意の新しい活動が開始するときは常に行われる。システムに入る全ての取引イベント要求には、コードスタンプ・サブプログラムを使用してコード・スタンプが付与され、このプログラムは、要求された取引を、取引に入ったユーザーに関連付ける親コードになる一意の取引番号を割り当てる。この一意の取引番号は、取引を開始した人物または口座の或る一意の識別子、ならびにその取引に一意のコードを含む。
【００６３】
共同型取引イベント（以下に述べる）では、このプログラムは取引番号を複製する場合があるが（取引に２人以上の参加者（すなわち、相手方）が存在するため）、いずれの取引番号にも一意のユーザー口座識別子が添付されることから、親コードスタンプはそれぞれ一意であることに留意されたい。
【００６４】
プログラムは、ＳＶＲプログラム・モジュール（以下参照）が相手方のマッチングを完了（解決）する度に、共同取引においてマッチした対にタグ付けするコードサイクリング関数もまた実行する。コードサイクリングが要求されている取引の種別に求められる場合に、コードサイクリング・プログラム・モジュールは、いくつかの子コードをさらに作成し、分散ベクトル解決（ＳＶＲ）プログラム・モジュールに従って割り振られ指示された各構成要素額を追跡して、親取引まで跡を辿ることができる。記録は、プログラムにより暗号化された形で保存することができる。
【００６５】
プログラムは、コード・マッチ集約関数もまた実行し、それによってＣＤＭＸプログラム・モジュールは、単一ユーザーまたは口座の利用可能な取引額を全て集約し、データを実行のためにマトリックス・クォーター・マスター（ＭａＱｓ）に渡す前に、額を総計するか、または活動を最適化する。
【００６６】
コードサイクリングは必ずしも、従来の簡易的なまたは従来の複合的な（以下さらに述べる）取引種別のいずれかを処理する必要はないことに留意されたい。
【００６７】
３）分散ベクトル解決（ＳＶＲ）モジュール
ＳＶＲプログラム・モジュールは、多次元（すなわち、ベクトル）オブジェクトの入力を受け取り、各次元量を自動的に分離して、実行を行なう前に各次元量を独立して処理する。処理前に次元量を分離することの利点は、一緒に扱われる複数の次元の共通部分において利用可能またはアクセス可能な有効性を単に取り込むよりも、各次元の有効性をより十分に捕らえることができることにある。言い換えれば、ＳＶＲモジュールは、制約を受けた（すなわち多次元の）オブジェクトの複雑さを別の方法で固定されるという有効性を得ることができる。
【００６８】
したがって、従来の２つのユーザーからの２つの支払いは、支払い額の一方の次元がこれら支払いに関する他の次元の変数によって複雑化して、支払い側および受け取り側の識別のように、２つの支払いを互いに殆ど関連しない多次元オブジェクトにするため、一緒に扱うことはできない。しかし、ＳＶＲプログラム・モジュールは、各次元値を分離して別個に処理することができる。実際に、これは、完全に関連のない当事者を一緒に同じ総計概要に包含することを実行することを意味する。相手方とのマッチングを割り当てる際に能率を実現するのは、各種アルゴリズムを含むマッチングユーティリティである。ＳＶＲプログラム・モジュールは、金融ベクトルのデジタル表現（すなわち、数学的に結合し操作することが可能であり、例えば、成分ベクトルの全てのコミットメントを解決する縮合または組み合わせたベクトルをもたらす）を処理して取り入れ、この情報を、全てを正確に考慮し、それから解決されたベクトルを実行することができるシステム（以下に述べる）に出力する。
【００６９】
ＳＶＲプログラム・モジュールは、特に共同複合型取引（以下、参照）における相手方が等しく平衡していない場合、すなわち、取引環境の双方の間に等しくない価値バランスがある場合に動作するように設計される。これら非対称の状況下で、ＳＶＲプログラム・モジュールは、遅延なしで取引を処理して、ベクトル・フロー・パティキュレーション（vector-flow particulation）を介して非対称を解決する。さらに以下の詳細に述べるように、ＳＶＲマッチングは、理論上多数の参加者を有する大きい流動性市場のゼロ和「市場機構」に、限定された参加者の取引環境をもたらされるようにできる。取引毎のレベルでは、非ゼロ和会計が瞬間的に顕在化する場合があるが、システム取引全体のマクロ・ベクトル・フロー処理はゼロ和原理に従って、連続した流れが処理されると以前の取引は全てゼロ和に従うものとなるため、いずれの側にも額が残らないようなプログラムによる完全なマッチングがあるべきである。
【００７０】
ＣＤＭＸプログラム・モジュールは、所与の期間にマッチングすべき額がシステムに残っていないときに完成するマクロ元帳を保持する。
【００７１】
このようにして、ＳＶＲプログラム・モジュールは、総計関数、資金移転アルゴリズム、為替アルゴリズム、統合会計アルゴリズム、ローン・シンジケーション、およびＡＴＭシェアリング等（以下、さらに述べる）を実行する。
【００７２】
ＳＶＲプログラム・モジュールに使用されるアルゴリズム
詳細には、共同複合取引（詳細な説明については以下参照）を果たすＳＶＲプログラム・モジュールにより使用される１つの考え得るアルゴリズムを図４に示し、図４には、円からドル、またドルから円への交換を要求する相手方が存在する。
【００７３】
図４では、左側は、この潜在的なアルゴリズムの交換プロセスの説明に用いられる基準を示す。左側はプロセス前の状態である。あらゆる交換は通貨対により構成されるため、右側(Oppside)は、交換取引の実行に使用されるターゲット（相手方）通貨での要求に対する基準である。したがって、左側の要求を満たすために必要な右側の要求総数が最小化されたときに最適な効率が生じる。プログラムはこの基準に基づく交換を優先する。アクティブ・シーク・クラスの額は、好ましくは、単一の右側額で満たされることに留意されたい。
【００７４】
したがって、システムにエントリーされると、ＳＶＲプログラム・モジュールは、額が例えば算術平均未満の場合にはアクティブ・シーク（active-seeking）として、額が算術平均を上回る場合にはパッシブ・フィル(passive-fill)として、交換すべき額を自動的に分類する。この算術平均は常に、プログラムがシステムを流れるベクトル／資金の額に応じて算術平均を再計算するときに変更することに留意されたい。
【００７５】
全ての要求は、実際に処理されたとき又はその近くで、そのＳＶＲプログラムによってリアルタイム要求として特徴付けられることに留意されたい。単一点固定時間（すなわち、或る日付で）やイベント・トリガー実行詳細（すなわち、ダウ・ジョーンズ・インデックスが、例えば１０，０００に達したとき）を有さず、時間期間制限詳細（すなわち、或る日付までに）を有するユーザー・プログラム取引から来る受動要求の母集団があるため、プログラムにより要求される能動的な再分類は、この受動取引の倉庫に対して、いくつか、または全てをリアルタイムに変換するよう要請し（call upon）、受動取引を処理して流動性をシステムにもたらし、軽度の変動性（すなわち、一貫した流動性）のシームレスな進行を引き起こそうとしてもよい。
【００７６】
さらに、場合によっては、プログラムは複数の平均を有し、量平均セパレーターを提供して２つの平均を区別する（図５参照）。例えば、取引量が予め設定されているトリガーをアクティブ化するために十分に増大すると、プログラムは、量を処理する新しい並列チャネルを作成することによって、この増大したベクトル・フローに対応する。トリガーは量を２つのセクションに分け、各セクションは先の単一仕切りプログラム関数のように動作する（図４参照）。図示される上半分にあるより大きなベクトルが解決されてマッチングが行われると、残りは下半分に下がり、量が低減すると、予め設定されているトリガーがトリップされて、プログラムはセパレーターを外すので、プログラム関数が元の単一仕切り状態に戻される。
【００７７】
アクティブ・シーク額は、各ターゲット通貨のパッシブ・フィル額を目標とする。潜在的にマッチング可能な２つの要求は、互いを能動的に探し求めることはできない。額が元々、プログラムによりアクティブ・シークに分類されている場合、プログラムは、単一相手方マッチング額でその要求を満たそうとする（図４参照）。その額が元々、プログラムによりパッシブ・シークに分類されている場合、額は、平均未満になるまでアクティブ・シーク額分低減され、そして再分類されているアクティブ・シーク額自体になり、その後満たされて取引が完了する。
【００７８】
したがって、為替要求のマッチングは、いくつかのアルゴリズムを使用してマッチングさせることができ、右側のアクティブ・シーク取引が、左側、またはその逆、またはジグザグ線形マッチング、または角度付き左側の全探索の右側マッチング（angled Nearside all seek opposite-side match）（図７Ａ参照）でパッシブ・フィル取引からマッチングする。
【００７９】
市場または取引の通常の活動では、時に、ベクトル・フローに不均衡が発生する。売り手が或る価格Ｅで何かを提供しているが、多数の買い手がはるかに低い価格Ｄしか支払う気がない場合が毎日あるように、直接参加者からシステムに対して目に見える流動性の欠如は、片方が他方よりもはるかに大きく、片方で相手方（すなわち、「買い手」）が少なすぎる状態で、大量のベクトル（すなわち、「売り手」）が利用可能であることを示す三角形の対として表現することができる。
【００８０】
この不均衡は、為替イベントに関連するもの、または方向性相手方マッチングとして構造化される国内イベント、または取引種別の片方が他方よりもはるかに多い任意の数の他の状況であり得る。ＳＶＲプログラム・モジュールは、自己選択ベクトルの流入を採用し、自己選択は、全てのベクトルが、少なくとも１つの同じ変数を有することを保証する。例えば、国内分散型資金移転では、通貨は全てのベクトルで同じであり、これがマッチ・ペア化(match-paired)された方向変数である。為替では方向は重要ではないため、マッチ・ペアのベースは通貨対である。
【００８１】
この種の不均衡の場合、システムはできるだけ多くの処理を行なうが、これは片側で利用可能な全てのベクトルが処理されて、右側で利用可能なベクトルがゼロである経験的状態で不均衡を残すことを意味する（図６および図７Ａ参照）。
【００８２】
これが発生する場合、マクロ世界の流動性危機の原因である可能性があり、またより高い可能性としては、ユーザー母集団が小さいことによる可能性（少なくとも、システムがまだ導入の途中であり、単に、流動性が問題ならないよう保証するのに十分な人々が登録していない場合）もある。この場合、システムのプログラムは、残っている片側のベクトル・フローを、例えば中間ブローカーにより流動性を提供可能な、より従来的なチャネルに向けるように予め設定され、これらベクトルの所有者はそれぞれの取引を満たすことができる（すなわち、従来のチャネルからの資本注入−図７Ａ参照）。このようにして、ユーザーは、システム参加者から第３者の大型銀行中間ブローカー／トレーダーへの流動性プールの切り替えを認識しなくてよい。
【００８３】
会計の総計
例えば、エンティティが多くの相手方との取引および金融関係を有するコーポラエト（corporaet）企業の状況では、企業が設定時間期間中に複数の取引を有する場合、負債（負）および受取債券（正）がある可能性が高く、多くの場合、同じ相手方と正および負の取引がある。同一当事者取引をその１つの関係について単一の結果に総計するのではなく、ＳＶＲプログラムは特定の総計プロセスを後回しにし、その代わりに全ての当事者の期間負および期間正の値を（企業が取引を有する全ての当事者にわたり）合計する。したがって、直接同一当事者総計は、好ましくは、取引世界における全ての当事者の間でのマクロ分散総計の段階を設定することを優先して迂回される。
【００８４】
取引分散ベクトル総計（ＳＶＮ）
分散ベクトル総計または分散型直接交換は、複数当事者の簡潔化 (multi-party compaction)であり、任意の当事者が任意の場所で取引しているときに可能である。ＳＶＲプログラム・モジュールは、ＳＶＮ関数を実行するとき、個人または機関のありとあらゆる取引サイズを処理することができる。従来の総計の場合よりもはるかに多数の参加者が可能である。
【００８５】
ＳＶＮでは、複数の当事者が常に分散総計を構成しており、相互負債およびリンクされた決済は必要ない。従来の総計は、固定数の参加当事者、ならびに総計を行なう固定時間期間の両方を必要とする。分散総計はこれらのいずれも必要としない。複雑性が当事者数に相関することはまずなく、リスクは当事者数に反比例して相関しがちである。
【００８６】
ＳＶＮにおける負債領域（これは、負債義務を遂行するための支払い送金が、サークル中の各債務者が支払うのを待っているときに中止することができるような循環構成中の債務者数として定義される）を分散総計するには、プログラムはＣＰＮ下に記載のように総計するが、そのままのベクトル関係を維持する代わりではなく、各当事者の流入／流出総計結果が総計前の絶対値と同じ絶対値であるように、必要ないずれのベクトルも再指向する（図８Ａおよび図８Ｂ参照）。当事者Ｄが当事者Ａに対して返済義務があり、当事者Ｃが当事者Ｄに対して返済義務がある取引方向をトレースするにあたり、分散総計後、プログラムは、当事者Ｄが当事者Ｃおよび当事者Ｂ−前者の取引方向とは完全に逆であり、後者にとってはまったく新しい関係−を補償できるようにする。分散総計は、一見、従来の総計よりもリスク低減において５０％を越える向上をもたらすように見える。したがって、取引総額は３４であり、総計された物理的な決済は８であり、リスクにある額の低減は２６／３４＝７６％である。
【００８７】
４）マトリックス・クォーター・マスター（ＭａＱｓ）（別名分散型銀行業務貸出クレジット）（ＤＢＬＣ:distributed banking lending credit））・プログラム・モジュール
マトリックス・クォーター・マスター（ＭａＱｓ）・プログラム・モジュールは、入力として最終的な集約取引情報をとって、その情報を実行命令に変換し、それから、必要とされるインフラが何であれ取引の実行を開始して、すでに存在しているプロトコルは何でも使用し、複数の口座およびシステムに対処して、全ての当事者の取引が達成されることを保証する、交渉マネージャ（negotiating manager）である。ＭａＱｓプログラム・モジュールは、ＣＤＭＸプログラム・モジュールまたは同様の追跡モジュールと協働して、資本移動の実行を実現する。
【００８８】
ＭａＱｓプログラム・モジュールは、既存のインフラを介して命令を実行する。ＭａＱｓプログラム・モジュールは、残りの金融業界および銀行業界との対話を可能にする各種ＡＰＩを保持しまたは組み込む。これは、例えば、オートメイテッドクリアリングハウス（Automated Clearing House; ACH）、連邦準備Ｆｅｄｗｉｒｅシステム（Federal Reserve Fedwire system）、アーキペラゴ（Archipelago）、インスティネット（Instinet）、およびアイランド（Island）等のＥＣＮ、クレジット・カード会社、銀行、ユーティリティ企業の口座、ウェブ・マーチャント（Web Merchants）を含め、広範囲のエンティティを含む。
【００８９】
ＭａＱｓプログラム・モジュールは、Ｖｆｔプログラム・モジュールにより組み立てられた実行コマンド、およびＣＭＤＸプログラム・モジュールにより提供されるユーザー口座情報を、取引の実行に使用されているインフラに従って適宜かつ正式な実行命令にひとまとめにする。複数のインフラネットワークが使用される場合があるため、ＭａＱｓプログラム・モジュールは、取引コマンドをフォーマットされた様々な実行命令にまとめることができる。
【００９０】
したがって、ＭａＱｓプログラム・モジュールは、本発明の分散型金融システムにおいて、作成され、プログラムされ、解決され、または他のことが行われた取引を実行する。ＭａＱｓプログラム・モジュールは、市場、製品、およびサービス提供者や、もちろん銀行または他の全ての関連エンティティ（ユーティリティ企業、保険会社等）の顧客口座におけるより大きなネットワークへのリンクである。システム自体が口座を有し、その口座が動作に関わる（ＡＴＭシェアリングまたは投資エンジン等、特定の機能またはサービスの実施に必要な場合がある、以下参照）場合、ＭａＱｓプログラム・モジュールは資本ベクトルをシステムから取り出し、またシステムに資本ベクトルを供給する。
【００９１】
プログラムは、プログラムが、表示および操作のために、システムを通して口座および市場から検索したデータをシステムに渡すことができるように、本システムと市場（すなわち、株式市場資金、ニューヨーク証券取引所等）内の他のシステムとの間に、ブリッジを備える。新しいセキュア・システム(secure-system)のインフラは必要ない。
【００９２】
銀行マルチプレクサＡＰＩ
以下に、ＭａＱｓプログラム・モジュールの構成要素であってもよい一種別のＡＰＩの一例について説明する。ユーザー銀行口座へ分配するために実行され処理されるシステムや命令を入力する命令または市場データ入力は、銀行マルチプレクサ・プログラムにより処理される。「マルチプレクサ」は、本明細書では、実施され得る同じＡＰＩを重複して使用して、２つ以上の口座または機関に同時に接続可能であることを示すために用いられている。本システムのプログラムは、取引を逐次順で排他的に処理するのではなく、むしろ複数の取引を同時に実行可能であることに留意されたい。
【００９３】
銀行マルチプレクサ・プログラムは、例えば、各処理済み取引額上の識別子コードを読み出し、これらを各種金融ネットワーク命令、例えば、システムに登録された銀行口座に送るべき直接振り込みおよび直接引き落とし命令に変換する。受動要求がシステムに入ると、さらなるコードにより、プログラムがこれらプログラムされた取引額を異なるときに引き落とし、プログラムされた取引の実行が必要とされるまで（さらに以下を参照）、投資エンジンに使用するために、システム所有の口座に振り込むように指示することが可能である。プログラムは、投資エンジンを実行し、必要なときに集約資金を使用し、終了時に、元の交換マッチング額を適切なエンドユーザー相手方口座に送り、それ以降の使用のためにシステム口座の利益を保持する。
【００９４】
５）符号分割多重取引（ＣＤＭＴ）プログラム・モジュール
符号分割多重接続は、同じ通信インフラの帯域幅を増大するという特定の目的のために、他が多数絡み合った単一の発信元−受信者対間で相互リンクされた接続（すなわち、音声／データ通信）を維持するように特に設計された通信技術である。符号分割多重取引（ＣＤＭＴ）は、分散ベクトル解決と協働し、通信帯域幅の設備を考慮せず、代替可能なトレードの相手方のマッチングを考慮し、さらに、（設定された入力のみを採用することができ、接続セッション、例えば電話をかけている期間全体にわたっての設定された出力の送り出しは、電話の最中に未知の当事者とランダムに切り替えることはできず、そうしないＣＤＭＡとは異なり）取引の期間全体にわたって取引の各側で相手側を固定しないことによって区別される。実際に、協働する２つの技術ＣＤＭＸおよびＳＶＲは、普通なら関連せず、所望なら匿名のままにすることができる複数のランダムな相手方に対して、いずれの相手方サイドでもリンクし、リンクを切り替え、また新しいリンクを追加することができる。
【００９５】
また一方で、ＳＶＲプログラム・モジュールと協働する本発明の符号分割多重取引（ＣＤＭＴ）プログラム・モジュールは、通信帯域幅の設備を考慮せずに、代替可能なトレードの相手方のマッチングを実行して、さらに、取引期間全体にわたって取引の各側で相手方を固定しないことによって区別される（図１０参照）。
【００９６】
実際に、協働するＣＤＭＸおよびＳＶＲプログラム・モジュールを利用するプログラムは、普通なら関連せず、所望であれば匿名のままにすることができる複数のランダムな相手方に対して、いずれの相手方サイドでもリンクし、リンクを切り替え、また新しいリンクを追加することができる。
【００９７】
金融取引はゼロ和の枠組みで行われるため、あらゆる相手方の対は平衡した値からならなければならず、そうでなければ取引は有効とみなすことはできず、また実際ではそのようなことは発生しない。プログラムは、ＣＤＭＸプログラム・モジュールを介して、例えば、匿名の買い手および売り手が単に価格に基づいて自動的にマッチングできるようにする（すなわち、同じ価格に複数の買い手および売り手がいる場合、システムは、ゼロ和を非対称数の相手方にも広げることができるように、入力トレード要求を自動的に符号分割する）（図１０参照）。したがって、５人の米ドルの売り手（日本円の買い手でもある）が、３人だけの相手方で満足される（図９〜図１０参照）。相手側はいずれも互いを知る、または認識する必要はない。
【００９８】
登録
まず、参加者はシステム・メンバーとして登録しなければならない。一般に、登録し、本発明のシステムに口座を作成するには、参加者は単に電子メール・アカウントを有する必要があるだけであり、標準の加入選択手続きを経て、例えばユーザー名およびパスワードをウェブサイトで初期設定し、ウェブサイトに基本的なユーザー情報を与えて口座ファイルを作成し、それから加入選択検証要求を供給された電子メールアドレスに送る。
【００９９】
検証後、ユーザー口座はアクティブになり、ユーザーは分散型クライアント・アプリケーションをダウンロードして、それから各種口座および金融データの入力に取りかかり、新しい分散型資本口座アクセスクリアランスをユーザーが分散型資本口座内からの操作を可能にしたい任意の第３者の口座に与えてもよく、あるいはユーザーは同種の情報を同じ目的で中央サーバに供給してもよい。
【０１００】
しかしながら、ユーザーには登録時にはシステムに対する完全なアクセスが提供されないが、どちらかというと、段階を踏んで進む必要があり、初期登録時にユーザーに対して最低限の機能（従来簡易型取引や制限された従来複合型取引を実行する能力等）が利用可能であるが、さらに多くの強力なツール（すなわち、共同取引）は、取引の数および価値、および洗練された投資家ステータス等に対する認識度、精通度、および／または忠実度の実証に利用することが可能となり、おそらくオンラインセミナーおよびテストを介して金融の規定、リスク・プロファイル、投資構造、税金規則等の数や量に従う。
【０１０１】
企業用途の場合、本システムは、例えば、ＣＦＯが企業システム口座にわたりマスター特権および完全な機能、ひいては企業の資産を操作し管理するより大きな自由を有する一方で、より低いレベルの財務職員は、可視性の理由で同じ口座にアクセスすることができるが、操作または管理するマスター特権を有さないように、複数のアクセス・パスワードおよびユーザー・クリアランス・レベルをサポートする。
【０１０２】
この手法は、ビデオゲームでよく見られる、非常に高度なチャレンジ・ランプ(challenge-ramp)の設計の技術を金融サービス設備に導入することを意味する。教育的または問題解決の相互作用、ならびに典型的なユーザー統計ハードルを組み込んだチャレンジ・ランプを統合することにより、金融サービスの周りに構築された双方向性の環境を作り出すことが可能である。
【０１０３】
以下、さらに説明する信用格付けシステムは、特定のアーチファクトまたはテクニックを各自の旅に沿って蓄積するユーザーにより大きな力または強さ（より強力な剣またはより強力な魔法の呪文等）が与えられるロール・プレイング・ゲームと略同じように分類システムを駆動することができる。したがって、本システムは、金融スキル、資本（または資産）力等、ならびに信用または健全性に従ってユーザーを分類することができる。ユーザーの母集団が増大すると、参照のために母集団に利用可能な分類格付けが存在することができ、したがって大きなコミュニティが成熟すると、ユーザーの評価が信用格付けすなわちムーディーズ(Moody's）（登録商標）格付け等の意味を帯びるが、信用格付け管理の力は、イクイファックス（Equifax）（登録商標）等秘密の第３者組織ではなく公平にユーザーおよびコミュニティの手の中にある。
【０１０４】
初期登録の別の代替は、公式の機関がユーザーを検証することができるというものであり、公的な身分証明書および社会保障番号等他の個人情報を求める。
【０１０５】
システム登録
ユーザーが本発明の金融システムのメンバになると、ユーザーは、構築、テスト、および／または実行したいかもしれない取引への包含に利用できることを必要とする、銀行口座、ユーティリティ企業口座、クレジット・カード口座等各自の口座を登録することができる。
【０１０６】
金融口座データを本システムにロードし、本システムにアクセスする、異なる各種方法が可能である。例えば、個人口座集約サービスは、ユーザーとともに各金融口座ウェブサイトを回るアシスタントを使用し、アシスタントは、ログインおよびパスワード情報を取り込み、個人集約サービス口座においてユーザーに提供することができる。
【０１０７】
今日既存のシステムは、全てユーザーが管理し、ユーザーがアクセスする口座を含む。既知の例で、これらシステムのユーザーが他のユーザーに対してこのようなアクセス特権を認可して送るものはない。しかしながら、本発明は、この複数当事者アクセスおよび取引イベントへのアクセス認可を意図的に可能にする。
【０１０８】
例えば、共同取引では、口座アクセスまたは単一の取引アクセスがこのような参加特権を認可されたユーザーにより受け取られ、そのユーザーの特別なアクションを必要とすることなくユーザーに対して利用可能になる。もちろん、ユーザーは認可された特権を拒否する権利を有するが、アクセス特権の認可は、他のシステム・ユーザーの教唆によって起こる何かであった。各種金融サービス提供側が多くの機能を提供し、ユーザーの既存の口座内においてその機能に対するアクセスを認可することは予想される一方で、共同参加者として互いに対話するシステム・ユーザーに役立ち、互いの口座および取引への許可を認可するように設計された金融サービス・プラットフォームはどこにもない。
【０１０９】
金融取引種別−４つの主要な実施形態
本発明による方法およびシステムは、４つの主要な種別の金融取引を含んでいる。それらはすなわち、従来簡易(Traditional Simple)、従来複合(Traditional Compound)、共同簡易(Collaborative Simple)、および共同複合(Collaborative Compound)であり、これらについて概略的に以下述べ、その後より詳細にさらに説明する。
【０１１０】
従来型取引
従来簡易
現在、金融サービスは、金融サービス提供側と消費者、またはクライアントとの間での一対一の関係の背景において、主に遂行されている。一対一の商業的関係、およびそれぞれの背景において行われる取引イベントはかなり単純である。通常、買い手が売り手から商品を購入する、またはユーザーがクレジット・カード企業に支払う等、全て単純な線形式に調整された一人の売り手／提供者、一人の買い手／ユーザー、および１つの形の購入通貨またはクレジットがある。
【０１１１】
これらをサポートするこれら金融の相互関係やサービスは、本発明のシステムが従来簡易型取引イベントとして指定するものである。従来簡易型取引（以下の数１（図面１）を参照）の例は、ブローカーから株式を購入する、またはウェブサイトにログインして購入を行なう、またはクレジット・カードの料金を支払う等である。顧客(Customer)と提供者(Provider)の間の本質的な関係は、取引のオンライン態様により取引が理論上容易かつ高速になっても変わっていない。実際に、一度に一企業ずつ金融サービスに接続している単一のユーザーは、インターネット等のグローバル・コンピュータ・ネットワークにおける本当のネットワークの利点を利用していない。
【０１１２】
本発明は、複数のシステム、ユーザー、提供者、顧客、買い手、売り手等を接続した本当のネットワークの利点を利用するネットワーク共同取引サービスをサポートするように設計されるが、従来簡易型取引は、本発明を使用するユーザーにそれぞれの取引世界における全ての口座の関与を見て操作することが可能である全知視点が提供されることから、この分散型金融システムを使用して容易に実行することができるのに対して、現行の方法およびシステムは、クレジットカードウェブサイトまたは銀行ウェブサイト等、取引参加者の中のただ一つのノード視点にユーザーを置く。
【０１１３】
【数１】
0005505897.tif 000002
【０１１４】
従来複合
従来複合型取引（以下の数２（図面２）を参照）では、ユーザーは、いくつかの従来簡易型取引を同時に管理、統合、およびプログラムすることができる。例えば、ユーザーは、ユーザーのクレジット・カード料金をユーザーの住宅ローン、公共料金、株式、債券、オンライン購入、およびユーザーが行ないたい取引を含む他の任意のものと共に管理し統合することができる。従来複合型取引は、新しい住宅担保ローンを取得すること、およびクレジット・カード料金および自動車ローン、または子供の大学の授業料をローンで支払うことを含むことができる。現在、これら種別の決定に対処した方法は１つしかない。すなわち、一度に１つずつ実行しなければならず、ユーザーは各種ソースからデータを集め、それから基礎知識および技能を得て計算の仕方を理解し、それから複数の一対一の個人的な取引に順序付きの組み合わせを介して最適な各種金融状況を達成しなければならず、この複雑さは大半の顧客のやる気を失わせる。明瞭化のために、各種金融サービスのユーザーが、各種第３者によって保持されている多くの負債を統合する等、利用可能な複数のサービスを組み合わせて、または統合して利用することを望む（または、そうすべきか否かを確かめる）状況下では、ユーザー各自の特定の状況に対して明確かつ単純な金融実行戦略を組み立てるにあたって、ユーザーに役立つ既存の自動サポートサービスは存在しない。金融サービスのユーザーは、それぞれの多くの義務および責任を管理するために実行する必要のある従来複合型取引のサポートを得る術がないため、一連の調整された従来簡易型取引を組み立てて、タイミングをとることによって人為的に複合取引を組み立てようとするしかない。いくつかの既存のサービスは、複数の口座の情報を一箇所に集約してインタフェースすることができるが、既存のシステムではユーザーに複数の口座の相互作用を管理、統合、およびプログラムをさせない。しかし、本発明はこれを可能にする。
【０１１５】
ビジネスユーザーの場合、ユーザーは、企業の様々な金融活動と責任の間の相互作用を査定する場合があり、また例えば、給料の支払い、ベンダーへの支払い、借り換え、ローンの借り入れ等を行なう場合があり、賢明なところを自動化し、よりよい意志決定を可能にする従来にないデータ（これは会社の財政状態の可視性にあたる）を捕捉する。したがって、全て同じインタフェース内で、ベンダーへの料金請求を、財務管理（すなわち、通貨管理、クレジットヘッジ）または収益の源泉等の次に行なうことができる。従来複合型取引は、ユーザーがそれぞれの各種支払協定、受取債権、負債（キャッシュフロー管理等）、責務、およびスケジュールの間の相互作用を構築し、ならびに取引をテストして単一の口座または関係だけではなく全体に影響を及ぼす結果を査定することを可能にする。
【０１１６】
例えば、大規模な企業ほど、会社での購入をそれぞれ許可し、受け取り、支払う別個のグループを有する傾向がある。この分離は、異種のグループが承認へ到達するのに必要な集約情報を組み立てるために何度も通信に頼らなければならないことから、購入ならびに支払いの両方の承認を処理する際の遅延につながる。従来複合型取引は、ログインまたは電子メールを使用して各事業部またはグループとのこのインボイス・プロセスを簡易化して、プロセスを通しての進行を最終的な承認および会社の財務部により発行され管理される送金注文に向けて進める、またトリガーを行なうために組み立てることができる。その時点でいくつかの変数に対して警報を設定できる簡易型のシステムと同じように、結果として電子メールまたは他の通知がユーザーに送られ、この場合ではインボイスを担当する上級当事者が、インボイス処理プロセスと共に様々なトリガーを調整することができ、会計部門が支払いの送金を出す前に、別のグループまたは事業部（商品を使用する特定のチーム）が正確性（すなわち、プロジェクトに必要な正しい部品）等を承認する間に、各種事業部（例えば、会社の郵便室）にいる異種のユーザーが商品の受領および商品の品質（すなわち、発送リストに従った正しく請求された部品番号および商品の適性）を承認できるようにすることができる。この制御は会社の構造全体を通して実施することができるので、企業の財政状態についてのはるかに大きなデータを素早く所持することが可能となる。
【０１１７】
さらに、ユーザーは、統合取引のパラメータを設定することができる（すなわち、株式が特定の値に達したときに売るべき株式、または特定の時刻または日に売るべき株式等）。したがって、取引を自動的かつ遠隔的に設定することができ、ユーザーは取引が行われたときに通知され、また、構成要素取引結果ならびに複合取引全体の結果を詳述した概要情報にアクセスすることができる。
【０１１８】
【数２】
0005505897.tif 000003
【０１１９】
共同取引
本発明の一実施形態は、金融活動の分野におけるネットワーク化された、または共同的なオプションの存在として大まかに定義することができる。これは、既存の金融、銀行、および商取引活動と一意に異なる。これら活動（一般に商取引を包含）の既存のパラダイムは略例外なく、単一線形の顧客−提供者の構成での関係に向けられた構造である。けれども、共同的活動は、相互に向けられ、単一よりも多くの関係を包含しており、多くの当事者が同時に顧客で、かつ提供者であることができる。
【０１２０】
共同取引は、本発明による方法およびシステムがサポートするように設計されており、複数の当事者および多様な形の通貨および／またはクレジットを含む。共同取引は、推移的（または分散ベクトルの）アクションを含んでおり、推移的なアクションは、貸方と借方、すなわち受取債権と負債等をネット・ゼロ化する(net-zeroing)こととして複雑であり得ることを意味するが、従来取引でのように直接関連する当事者同士だけではなく、ネットワーク世界における全ての参加者の中でのグローバルなレベルで扱われる。
【０１２１】
これは、本発明の分散型資本システムは、任意の単一の参加者よりも大きな取引分野の認識を有するため、取引のロジスティックスを積極的かつ理知的に最適化し、例えば、その分野における実際の資金移動の総額を、その分野において支払われた負債と同額分低減することができるように、使用されている口座および機関に従って受領当事者および債務当事者をマッチングさせて支払いを送金または受け入れることができることとして、何千人もの参加者にわたる負債を推移的に混ぜたものを理論的に計算するので、したがって例えば、正味資金(net funds)なしで、またはその銀行から出て、ＡＣＨまたはＣＨＩＰＳ等の銀行間転送ネットワークに入る正味資金を低減させて、資金の移動を内部銀行業務実行（債務者および受領者が互いに対する接続をまったく有していない場合であっても、これら個人の参加者を識別することが可能となり、同じ機関で少なくとも一部マッチングすることができる）として処理できるようにすることを意味する。
【０１２２】
共同取引を試行して視覚化するための分かりやすい方法は、株式市場の特定の現実を調べることである。買い手と売り手とはおおよそ互いを知らないが、取引されている証券は代替可能であるため、近接性または認識に関わりなく一方の当事者の売り証券が任意の当事者の買い証券になることを可能にする。証券が当事者Ａから当事者Ｂの手に取引される参加者は、相手方が誰であるかを気にせず、また気にする必要もなく、それぞれの取引が局所的にネット・ゼロ化することを考慮する必要があるだけであり、市場機構自体が、全ての取引にわたる、また全ての参加者間でのグローバル・レベルでのネット・ゼロ化することを解決する。本発明は、この保証されたグローバルなゼロ化機構を、市場として機能する（すなわち、流動性を実現する等）臨界質量または構造（すなわち、証券化等）を決して有さなかった様々な取引状況に導入する。
【０１２３】
現在、グローバル・レベルのゼロ化(global-level zeroing)は、証券化または商品化されたアイテムを取引する理論的に多数の参加者を有して活発な、流動性のある市場においてのみ明らかである。本発明は、このグローバル・レベルのゼロ和機構を参加者限定の取引環境に導入する。上述したように、ＳＶＲプログラム・モジュールと呼ばれるプログラムで実現される推移的なアクションを用いて、わずか２つの参加エンティティを含む任意の数の取引がここで、全ての参加エンティティにわたる義務をネット・ゼロ化するシステムにアクセスすることができる。もちろん、２つのエンティティの取引、または２つのエンティティ間での複数の取引は非常に容易に総計することができるため、当事者間でのゼロ化を解決するために高度なネットワーク技術は必要でなくてもよいが、それでも本発明はこの２つのエンティティ取引環境を管理可能であることを認識する。しかしながら、３つ以上の当事者が存在する場合、グローバル正味ゼロ化を解決するのは直観的に容易ではなく、これは本発明が最も有用かつ最も有価値になる場合であり、リスクにある総資本、展開された総経済資本、取引の機敏性等に関して効率をもたらす。
【０１２４】
この公開市場に参加する際、全ての参加者は、同時に顧客および提供者の両方である。全ての参加者が顧客特徴および提供者特徴を示す場合、取引種別は共同複合、すなわち最も高度かつ拡張的な取引種別（言い換えると、共同複合型取引の単なる一例は株式市場である）として分類される。
【０１２５】
代替可能であることは、取引の解決を容易にする。これが意味するのは、例えば、当事者Ａが当事者Ｂに対して或る額Ｘの負債を有し、かつ当事者Ｂが当事者Ｃに対して或る額Ｘの負債を有する場合、３人の当事者の取引の役割および義務は、当事者Ａが当事者Ｃに送金する単一のＸの支払いで満たすことができる。分散型資本システムは、公募による資金調達の買い手および売り手がそれぞれの取引に対する相手方が誰であるかを知らず、気にしないのと同じ趣旨で、当事者Ａ、Ｂ、およびＣが互いを知っているか否か、または互いに気付いているか否かも関わりなくこの推移的なシナリオを見つけて実行する。共同取引では現在の購入者または売り手が誰であるかは重要ではなく、むしろ問題なのは、債務および受取債権が全て遂行され、正しい当事者が、特に責任を負っていた負債の遂行により引き落とされ、正しい受取当事者が貸していた額を実際に受け取ることを確認することである。
【０１２６】
取引の世界では、ランダムな参加者が、上の例で前もって想定されるように、まったく同じ額Ｘの負債に辿り着くことはまずないため、分散型資本システムは、マッチングしない（すなわち非対称な）額に対処する方法およびシステムを有する。上述したように、分散ベクトル解決プログラム・モジュールは、取引の世界をフロー・ベース化されたモデルとして取り扱う際に、終わりのない様式で、当事者の一部または全ての負債額または受取債券額がマッチングする後続する相手方を繋ぎ合わせることにより、マッチングしない額の「解決」を実現する。
【０１２７】
共同簡易
共同簡易型取引（数３（図面３）参照）では、２人以上の当事者が独立して、同じ機会に参加を選択する。単純な一例では、これは、民間投資機会を選択された投資家グループに提供する小規模事業主を含む。現在、このようなシナリオは一対一の関係の集まりとして遂行され、事業主は他と独立したそれぞれ一人の当事者になる（会社に投資される資金はプールされた資産の集約であるにもかかわらず）。
【０１２８】
投資信託は、分散型資本システムがどのように投資家に対する顧客サービス提供を向上することができるかについての好例であるが、現在、投資信託は従来の一対一の関係のパラダイムおよび取引の静的処理の両方に従っている。しかしながら、分散型資本システムは、例えば、資金状態、およびおそらく、資金状態に関わる他の投資家のリアルタイムなアクションさえも常に見ることができるようにすることによって、はるかに多くのサービスや価値を顧客に答えることができる。
【０１２９】
例えば、第３者の金を貸し付けている２人の友人−この場合、全ての貸付当事者は、利子と共に返済を申し出る第３者の友人に提供される「投資機会」の「顧客」である。別の例は、信徒から寄付金を集める、またはローン、寄付金、利子付きの支払い等によってローンの形で銀行（複数可）から金を工面する教会であり、本発明の分散型資本システムにより管理することができるので、教会が信徒の各構成員間、ならびに複数の銀行間での全ての取引を行なう場合よりも安価なコストにすることができる。
【０１３０】
より多数の投資家が、例えば、貸付限度額のシンジケーション等のような上位の証券（債務）に参加することを望む従業員所有の企業や公営企業が、共同簡易型取引のユーザーある。
【０１３１】
【数３】
0005505897.tif 000004
【０１３２】
共同複合
本発明の方法およびシステムによる別の実施形態は、共同複合型取引（数４（図面４）参照）である。共同複合取引では、取引の双方が各自を顧客（および、それを行なう背景においては同様に提供者にもなる）とみなしている。顧客は、互いに対する直接的な認識はいずれも有さなくてもよく、本発明の分散型資本システムは単純に、共同複合型の実施形態を用いて取引をより効率的に、またはよりお金のかからない、あるいはこれら両方等を行なう。
【０１３３】
共同複合型取引の一例では、ユーザーの企業が特定の活動のために英国ポンドを必要とする場合がある。従来の様式では、ユーザーは物理的にあるいはオンライン等で銀行へ行って、特定額の資本を米ドルから英ポンドへの換金を手配していた。
【０１３４】
第１のユーザーと関連のない世界のどこかにいる第２のユーザーが特定の企業活動のために米ドルを必要としている場合、従来では、そのユーザーは、同様に物理的にまたはオンライン等で銀行または他の金融機関等へ行って、特定額の資本を英ポンドから米ドルへの換金を手配していた。
【０１３５】
両方のユーザーは顧客であるので、金融機関は両方に従来の様式でサービスを提供することができる。その一方で、両方のユーザーは互いに取引を手配して、または互いを自動的に匿名でマッチングさせて、本発明の分散型資本システムにおいて互いのニーズを相互に満足させることができるため、顧客であると同時に提供者にもなる。
【０１３６】
特に、そのユーザーらは、本発明の分散型資本システムを利用して通貨の交換を要求することができる。本発明の分散型資本システムのプログラムは、両方のユーザー／当事者が要求する資金を厳密にマッチングさせて、当事者ができるだけ全額を取引できるようにし、それから残っている額をいずれも取って（例えば、一人のユーザーがその他の当事者が提供可能な額よりも大きな米ドルを要求した場合）、別の「顧客」にその部分額を遂行させて、その顧客の残りをその取引の反対側にいる次にくるもう一人の顧客によって満足させるという問題を解決するために、ベクトル・フロー・アルゴリズムを使用する。
【０１３７】
これは、全ての取引を単一の相手方で完全に満足させなければならない（銀行が正確な額の所望の為替を遂行する例において等）という前提を強制する主流の静的処理ではなくフロー・ベースの取引処理である。この種別の共同複合取引は、関わる額―小さいか、それとも大きいか―に関係することなく行なうことができるため、おそらく、第３者である仲介者の除去による手数料の低下につれて、流動性は理論上増大することから、世界中の地域経済および国家経済にわたる変動の緩和に貢献し、結果として経済（通貨、政策、主権等）領域間の摩擦が少なくなる（ひいては、経済の歪みや苦難につながる待ち時間が短くなる）。
【０１３８】
【数４】
0005505897.tif 000005
【０１３９】
取引のタイミング
各型の取引におけるこれら４つの実施形態を説明するにあたり、ユーザーは、即時処理（通常、料金の支払い、または投資適格債要求に望まれる）を望むか、それとも取引を行なう時刻を設定する（すなわち、分割での料金支払いのために後日等）ことを望むか、それともイベント・トリガー取引の実行（特定の株式価格、さらにはユーザーがそのデータを使用したい場合がある任意の変数等、例えばラスベガスの周囲温度、またはグリーン・ベイ・パッカーズ(Green Bay Packers)の試合の得点等）を望むかを示すことができることに留意されたい。最初の取引はリアルタイム型または瞬時型の要求として、次は受動要求として、最後は固定要求としてシステムにより指定される。後者のシステムでは、取引の資金は、本システムの投資エンジンが利用可能であり得る（以下の投資エンジン参照）。
【０１４０】
従来簡易型取引
本発明の方法およびシステムによる一実施形態は従来簡易型金融取引であり、これよりより詳細に説明する。従来簡易型取引のみについて以下説明するが、以下の異なる種別の取引全てが本システムのユーザー・インタフェースを利用することができることに留意されたい。したがって、従来簡易型取引に関して説明するユーザー・インタフェースについては、その他の取引に関して再び詳細に説明しない。
【０１４１】
上に述べたように、従来簡易型取引は大半のオンラインユーザーにとって馴染みがあるものであり、顧客および提供者、および料金の支払い等単純な金融取引のみが関わる。
【０１４２】
したがって、ユーザーがシステムにログインし、ステップＳ１００（図１１Ａ参照）におけるログインプロセスおよびステップＳ１０１における認証プロセスを経ると、ステップＳ１０２において、プログラムが、文書処理プログラムが開くときに開く画面と同様のブランクの表示画面を開き、表示画面には取引オプションが示されている。
【０１４３】
次にユーザーは、マウスを使用して「ファイル」の上にカーソルを置き、マウスを左クリックする。その時点で、ステップＳ１０３において、プログラムは、ユーザーが利用可能な実行可能取引を列挙したプル・ダウン・メニュー、またはおそらくダイアログウィンドウ、オプションパレット、ツールバー、もしくはユーザーが口座にセットアップした任意の同様のカスタム設計された取引の表現（すなわち、既存取引１(Existing Transaction 1)、既存取引２(Existing Transaction 2)、新取引構築(Build New Transaction)等）を提供する。
【０１４４】
活動は適切な選択の上にあるカーソルを使用して、右クリックまたは左クリックして活動を開始するマウスのアクションを使用して実行されるものとして説明されるが、当業者は、これらアクションがキーボード上のコマンド機能により、または音声起動もしくは他の同様の方法により実行することができることを理解して、インタフェース設計の域の「通常の技術」の一貫した進歩により、インタフェース設計を提示するよりよい方法を常に実現し、情報量を増大していくであろうことに留意されたい。
【０１４５】
さらに、各種動作および取引について個別のステップおよび特定の用語を使用して説明するが、当業者は、取引を様々な方法で、また異なる用語もしくはステップを使用して、また以下説明する方法の変形を用いて実現することが可能であることがわかる。
【０１４６】
これが新しい、すなわち最初の取引であると想定すると、「ファイル(File)」メニューにおいて一度、ユーザーは「新規取引(New Transaction)」を選択することができ、そのオプションを左クリックすることにより、ステップＳ１０４において取引が新規取引であると判定される場合、それによりステップＳ１０５において、プログラムは表示画面上にブランクの取引ワークパッド(Transaction Workpad)を開く（図１２参照）。
【０１４７】
ユーザーは、基本のブランクの取引ワークパッド表示に来ると、カーソルを見出しの「表示(View)」に移動させ、そのオプション上で左クリックすることができ、ステップＳ１０６において、プログラムは、「ツールバー(Toolbars)」を含むプル・ダウン・メニューを提供する。
【０１４８】
次にユーザーは、「ツールバー(Toolbars)」を左クリックする、または「ツールバー(Toolbars)」の右側を辿ってサブメニューをドロップ・ダウンさせることができ、それによりステップＳ１０７において、プログラムは、ユーザーが選択することができる取引オプションのリストを提供する。
【０１４９】
例えば、「ツールバー(Toolbars)」の下は、「私の銀行(My Bank)」、「私のクレジット・カード(My Credit Cards)」、「私のコミュニケーション(My Communications)」、「私のユーティリティ(My Utilities)」、「私の保険(My Insurance)」、「私のローン(My Loans)」等、ならびに「取引オブジェクト(Transaction Object)」という名称の選択肢を含むオプションリストであることができる（図１３参照）。
【０１５０】
当業者は、設計要素により「ツールバー(Toolbars)」を、「取引エンティティ(Transaction Entities)」、またはユーザーに最も有効に伝わる或る他のこのような名称等、より適切な名称への置換を指示することができることを認識するであろう。
【０１５１】
この例の従来簡易型取引では、ユーザーはガス料金を支払いたい場合があり、これは２人の当事者（３つのエンティティ）が関与する単純な取引であり、ユーザーおよびガス会社が当事者である（ユーザー、ガス会社、および二者間の取引アクションが３つのエンティティである）。
【０１５２】
したがって、ユーザーは「取引オブジェクト」を選択し、そのオプション上で左クリックすることができ、それによりプログラムは、ステップＳ１０７においてコマンドを受け取って、取引ワークパッドに隣接する位置に作業領域を表示し（図１４参照）、「取引オブジェクト」とラベルされて、その中に各種機能取引アクションを表す複数のアイコンを配置する。
【０１５３】
例えば、アイコンは、資本資産ベクトル(Capital Asset Vector)（支払い、またはより正確には、資本の大まかな動き＝「資金移動(Move Funds)」）、為替(Convert Currency)、購入(Buy)、売却(Sell)、貸付(Lend)、借入(Borrow)、および通貨ヘッジ(Currency Hedge)等の金融取引アクション(financial transaction-action)を表すことができる。これらオブジェクトは、この取引オブジェクトのツールバーまたはパレットにある間は、不活性である。これらのいずれかが取引ワークパッド上にドラッグされると、アクティブ・オブジェクト、すなわちユーザーが組み立てる取引のビルディング・ブロック・エンティティになる。
【０１５４】
マウス・オーバ、マウス・ボタン・クリック（右または左）、あるいはユーザー・フレンドリー・アクセスを指示する他の或るインタフェース設計を介してアクティブになる（すなわち、取引ワークパッド上にくると）と、ユーザーはそのエンティティに関連する「プロパティ」情報を見ることができる。「オブジェクト(object)」は、「エンティティ(entities)」の部分集合であることに留意されたい。したがって、「取引オブジェクト(transaction object)」は取引アクションに固有の用語である一方で、「エンティティ(entities)」は、取引の当事者ならびに当事者間のアクションの両方を識別するために用いられる。
【０１５５】
「新規取引(New Transaction)」の場合、「目的エンティティ(object entities)」は、取引が新規であり、この特定の取引内のアクションはまだ使用されておらず、表示する記録を作る使用履歴を有さないことから、一般的な機能の実現可能性やシステム状態種別情報以外の「プロパティ(properties)」情報を表示しない。しかし、「新規取引(New Transaction)」を組み立てるために「取引ワークパッド(Transaction Workpad)」上に配置されたアクティブな「当事者エンティティ(party entities)」は、これら「エンティティ(entities)」が現在の新規取引を越えて、組み立て中の様々な取引に関わっていることから、豊富な「プロパティ(properties)」情報を正確に明らかにするようになる。ユーザーは、各ユーザーにとって最も重要なものに従ってこのプロパティ情報の提示を構成することができる。
【０１５６】
「取引オブジェクト(Transaction Objects)」ツールバー内には、「新規オブジェクト探索(Search for New Objects)」ボタンがあり、これによりユーザーは、「取引オブジェクト(Transaction Objects)」ツールバーに最近追加されたものについてシステムに定期的に問い合わせ、そうしてさらなる機能を、ユーザーが作成しユーザーが管理する取引に追加することができる。しかし、プログラムは、システムにより提供される定期的な更新に連動して、または実現された前提条件要素（オンライン投資家教育セミナーまたはトレーニングプログラムへの参加、または製品およびサービスを設定期間使用する、定められた量使用する、または適格に使用する等）に連動して「取引オブジェクト」ツールバーに自動的に現れる新規の「取引オブジェクト」を提供する。これら新規の「取引オブジェクト」によっては、システムから受け取るために承認または特別なアクセス（上級な投資家の地位等）を必要とするものもある。
【０１５７】
次に、ユーザーは「ツールバー(Toolbars)」メニューから「私の銀行(My Banks)」を選択することができ、それによってプログラムはコマンドを受け取って、ユーザーが事前に登録した様々な銀行口座を指すアイコンを示す別のラベルの付いたセクションを取引ワークパッドに隣接して表示する。
【０１５８】
本発明では、口座および取引アクションは、表示上のアイコンとして好ましく示されているが、プル・ダウン・メニュー(pull-down menu)、テーブル、グリッド等で利用可能であってもよいことに留意されたい。取引は、マウスを使用して、またはキーボードもしくはディスプレイ上のコマンド機能や音声起動等により、エンティティの処理に固有の取引オブジェクト・アイコン(Transaction Objects icons)またはプレースホルダ表示(placeholder representations)（テキスト名、またはそのようなもの等）の移動によって組み立てることができる。以下の説明は、マウスを使用して操作されるアイコンの使用に関連しているが、当業者は、キーボードもしくはディスプレイ上でのコマンド機能の使用、または音声起動等も、コマンドを実行するため、または取引を開始するために設けることが可能であることを認めるであろう。
【０１５９】
最後に、ユーザーは、「ツールバー(Toolbars)」メニューから「私のユーティリティ(My Utilities)」を選択することができ、それによってプログラムは、ラベルの付いたセクションを「私の銀行(My Banks)」および「取引オブジェクト(Transaction Objects)」の領域に隣接して表示し、それによって「ガス会社(Gas Company)」、「水道会社(Water Company)」、「電気会社(Electric Company)」等を示す複数のアイコンが「私のユーティリティ(My Utilities)」セクションに出現する。
【０１６０】
金融取引を行なうためには、取引の当事者、および当事者間で実行するように選択された取引アクションを、取引として実行することが望まれる関係に配置された、取引ワークパッド領域に配置しなければならない。
【０１６１】
したがって、ユーザーは、カーソルを「私の銀行口座(My Banks Account)」アイコン（ユーザーが登録した特定の銀行にある特定の銀行口座に固有であることができる）上に配置することができ、マウスを使用して、カーソルを左クリックしたままにして移動させる、すなわちアイコン「私の銀行口座(My Banks Account)」をブランクの取引ワークパッド・セクション上にドラッグして、アイコンを取引ワークパッド・セクションに配置する。元の場所からドラッグしてもアイコンは元の場所から除去されず、カーソルがクリックしたオブジェクトを元の場所から離れて移動させたときにコピーが作成される。したがって、プログラムはステップＳ１０８において、ユーザーが取引の組み立てに進む際に、取引ワークパッド・セクションにおいて取引エンティティを受け取る。
【０１６２】
ユーザーが、取引ワークパッド・セクション内の「私の銀行口座(My Banks Account)」アイコンに関連する「プロパティ」情報を必要とするアクションをマウス・オーバする、または実行すると、プログラムはステップＳ１０９において、ＶｆＴプログラム・モジュール(Vft program module)を使用して、ユーザーの銀行口座の状態についてのリアルタイムの情報（すなわち、口座番号(account number)、当座残高(balance in checking)、普通残高(savings)等）を得るコマンドとしてこのアクションを受け取る。ＶｆＴプログラム・モジュールはこのコマンドを実行し、いずれのユーザーがいずれのエンティティにこの要求を送っているのかをＣＤＭＸプログラム・モジュールに教え、ＣＤＭＸプログラム・モジュールは、ユーザー登録の全口座の記録を保持する信頼できる「口座レジストリ(Account Registry)」にアクセスし、これら口座についての適切かつ正式な識別ならびにアクセス許可データを集める。
【０１６３】
もう一つの方法として、システムは、必要な場合に、必要なユーザーパスワードを要求し、いずれのユーザーパスワードも記憶しないように構成することができる。続けて、記憶されることの他に、要求を実行してシステム外部の現実世界エンティティから情報を検索するＭａＱｓプログラム・モジュール(MaQs program module)にこの検索情報を渡す前に、ＣＤＭＸプログラム・モジュールがこのアクセスにタイムスタンプを付けて(timestamped)、取引コード(transaction code)を割り当てる。
【０１６４】
したがって、プログラムは、ステップＳ１０９において、インターネットを介して、また情報の取得に必要な任意のセキュアな金融ネットワークを介して、ユーザーの銀行に問い合わせる。この要求は、クライアントから別のクライアント、またはサーバに送られて、要求が送られたクライアントまたはサーバが銀行への取り合わせを実行することに留意されたい。（しかし、問い合わせられた銀行は、要求が容易に処理されるように本システムの一部であってもよいことに留意されたい。
【０１６５】
より高度な１つの取引オプションでは、ユーザーはオプション「全口座更新スキャン(Scan All Accounts for Updates)」を選択することができ、それによりプログラムは、ユーザーの事前登録された全ての口座をスキャンし、各口座に関連するリアルタイムデータ  をユーザーに提供し、いずれの新規請求、投資信託または銀行口座等の残高変更）をユーザーにアドバイスする。
【０１６６】
ステップＳ１１０では、ＭａＱｓプログラム・モジュールは、サーバで銀行からの情報を受け取って、その時点で任意の全体的なシステムの状態またはネットワークを介しての要求を発行する結果として供給されるかもしれないネットワークの情報も同様に含んでいる、検索された情報をＣＤＭＸプログラム・モジュールに渡す。次に、プログラムはＣＤＭＸプログラム・モジュールを介して、検索された情報全てにタイムスタンプを付け、コード化し、かつ記憶する。ＣＤＭＸプログラム・モジュールは、次に、受け取った情報をフィルタリング(filters)して、要求された情報のみをＶｆＴプログラム・モジュールに返すので、ユーザーの銀行口座のリアルタイム状態はクライアント・コンピュータに提供されて、ステップＳ１１１において、クライアント・コンピュータは銀行口座のリアルタイム状態をユーザーに対して、アイコンの隣の画面、またはプル・ダウン・メニュー、テーブル、または他のウィンドウ等の下に表示する。
【０１６７】
ユーザーは各自の銀行口座をシステムに事前登録しているため、この問い合わせはセキュアに実行することができ、例えば、ＡＴＭ機から現金を引き出そうとするときにユーザーが受け取るように、結果は略瞬時に検索されることに留意されたい。さらに、既存のセキュア・ネットワーク(secure networks)が使用されるため、この問い合わせを実行し情報を受け取るために新しい物理的なインフラは必要ない。
【０１６８】
ユーザーはここで、「ガス会社(Gas Company)」アイコンをホールドして取引ワークパッド(Transaction Workpad)上にドラッグし、「ガス会社(Gas Company)」アイコンにおいてマウス・オーバ等を実行することにより、「ガス会社(Gas Company)」アイコンに関しても同じステップを実行することができ、プログラムは、「ガス会社(Gas Company)」に関するリアルタイムおよび他の情報を得ることができる（すなわち、口座名、口座番号顧客サービス電話、支払い額、過去に支払った額等）。
【０１６９】
ユーザーは、「取引オブジェクト(Transaction Objects)」セクションから取引オブジェクトを選択して同じステップを実行することもできる。この場合、「資本資産ベクトル(Capital Asset Vector)」が「私の銀行口座(My Bank Account)」と「ガス会社(Gas Company)」の間に配置されてこの２つを結び付ける適切な金融取引アクションである。したがって、「資本資産ベクトル(Capital Asset Vector)」が「取引オブジェクト(Transaction Objects)」セクションから検索され、取引ワークパッド・セクションにおいてプログラムにより受け取られた後、ステップＳ１１２において（図１１Ｂおよび図１４参照）、ユーザーはここで、実際に実行を望む場合、金融取引を開始し、金融取引の開始を確認することができる。
【０１７０】
したがって、ユーザーは「資本資産ベクトル(Capital Asset Vector)」を２つのエンティティ（すなわち、「私の銀行口座(My Bank Account)」および「ガス会社(Gas Company)」）の間に付けて、取引を完全に組み立てられた取引（すなわち、ユーザーの銀行口座からのガス料金の支払い）にし、プログラムは組み立てられた取引をステップＳ１１３において受け取ることができる（図１５参照）。
【０１７１】
「資本資産ベクトル(Capital Asset Vector)」取引オブジェクトが「私の銀行口座(My Bank Account)」エンティティおよび「ガス会社(Gas Company)」エンティティ・アイコンの両方に付けられるまで、取引は行われず、実行を行なうことはできず、取引ワークパッド(Transaction Workpad)上のいずれのエンティティにマウス・オーバまたは他の「プロパティ(Properties)」チェックを行っても表示、結果の証拠、またはこの取引の確認は生成されないことに留意されたい。プログラムは、ステップＳ１１４において、ユーザーに実行を開始させる前に、あらゆる取引の組み立てをチェックして、組み立てられた取引の少なくともシンタックス(syntax)が実行可能であるか（額および選択されたエンティティ等におけるユーザーエラーを全てチェックし回避することはできないが）を確認する（図１６参照）。同様に、プログラムは、組み立てられた取引がユーザー開始を介して実行に利用可能になる前に、ユーザーに「資本資産ベクトル(Capital Asset Vector)」の方向（送金要求（すなわち、返金要求またはユーザーからガス会社への請求提示）ではなく、支払いがガス会社に送られるように）ならびに資本ベクトルの額の両方を設定し確認するように求める。
【０１７２】
取引を組み立てるために、ユーザーは次に、「資本資産ベクトル(Capital Asset Vector)」アイコンの下部を左クリックし、そのままの状態で「私の銀行口座(My Bank Account)」アイコンにドラッグすることができ、「資本資産ベクトル(Capital Asset Vector)」は「カチッ(snap)」と音がして付けられる。さらに、プログラムは「私の銀行口座(My Bank Account)」アイコンの境界線を変更して濃くしたり、または色を変更したり、等を行ない、添付が成功したことを示すことができる。「カチッ(snap)」と音がする機能は、「描画(Draw)」アプリケーションを使用して矢印を各種オブジェクトに付けることができるユーザーにとっては馴染みがあるものである。
【０１７３】
ユーザーは次に、「資本資産ベクトル(Capital Asset Vector)」の上部を左クリックし、そのままの状態で「ガス会社(Gas Company)」アイコンにドラッグすることができ、ここでも「カチッ(snap)」と音がして付き、プログラムは、結び付きの成功を伝えるために選択されたユーザー中心設計が何であれ、境界線を濃くする等を行なう。
【０１７４】
上述したステップについて、１つのエンティティから別のエンティティに支払う際の資金の移動配置順で説明したが、当業者は、これらステップは任意の順序で実行することができ、エンティティは取引ワークパッド(Transaction Workpad)に任意の順序で配置することができ、各配置直後に結び付けられても、あるいは全てのエンティティが取引ワークパッド(Transaction Workpad)に配置された後に結び付けられてもよいことを認めるであろうことに留意されたい。
【０１７５】
３つのエンティティ（すなわち「私の銀行口座(My Bank Account)」、「資本資産ベクトル(Capital Asset Vector)」、および「ガス会社(Gas Company)」）の間に結び付きが行われると、システムの取引シンタックス(the system's transaction syntax)の実行可能性チェックに合格し、ユーザーが取引オブジェクト重要事項(transaction object Criticals)を設定し確認するのを待った後、取引は完全に組み立てられてアクティブな取引になる。
【０１７６】
完全に組み立てられると、ユーザーによるユーザー中心設計(user-centered design)が指示し得るように利用可能である、「プロパティ」要求アクション("properties" request action)のマウス・オーバまたは他の同様の資本資産ベクトルにより、プログラムはその資本資産ベクトル(Capital Asset Vector)の特徴を詳述する情報の表示を開始する。これは例えば、ベクトル・ソース・エンティティ(Vector Source Entity)（すなわち、機関名、資金が引き起こされる口座番号等を含む、ユーザーの銀行）、ベクトル宛先エンティティ(Vector Destination Entity)（すなわち、機関名、ターゲット口座番号等を含む、ユーザーのガス会社）、実行時に使用される可能性が最も高い取引システムまたはネットワーク（ＡＣＨ、ＰａｙＰａｌ（登録商標）、電子小切手等）、実行が現在の時刻で進められないような場合があればネットワークまたはシステムの状態等を含む。また、過去に使用された組み立て済みの取引が存在する（すなわち、先月のガス料金の支払いが、今月の料金取引およびベクトルと同じ取引エンティティおよび組み立て向きであり、タイミングおよび額のみが変更されている）場合、プログラムは、特定の資本資産ベクトル（すなわち、特定のユーザー銀行口座からガス会社への支払い）を使用して前の取引活動の指示を提供し、さらなる詳細にアクセスすることが可能であり、取引履歴(Transaction History)とプログラムが呼ぶユーザー中心設計指示が最適な表示方法であることができる。
【０１７７】
いくつかの異なる送金エンティティ(remitting entities)が異なる時刻にガス会社への支払いに使用されている場合、それぞれ別個のファイルとして保存されている複数の組み立て済み取引があり、それは、それぞれ一意に定義された資本資産ベクトルをそれぞれ有しており、ユーザーが別個のファイルを随時開いて再び使用することが可能であることに留意されたい（言い換えると、ユーザーは、複数の銀行口座およびクレジット・カード口座等を有すると共に、あるときには口座１から送金し、別のときにはクレジット・カード口座等から送金することを好む場合、所望の送金方法に従って保存されている取引ファイルを開くことを選ぶ）。ユーザーは、ある時点で、特定のガス会社口座が関わる全ての活動の詳細を見たい場合、「ガス会社への支払い」取引ファイル("payment to Gas Co." transaction files)のいずれの「プロパティ」中のガス会社口座履歴にただ単にアクセスするだけよい。これは、プログラムが、いずれの送金口座が支払いを送っているかに関わりなく、ガス会社口座に対する活動に従って、全てにおけるガス会社の記録を更新するためである。
【０１７８】
ユーザーは、これら「ガス会社への支払い」取引ファイルの１つの中で特定の資本資産ベクトルの「取引履歴」を見たい場合、このオプションを選択することができ、プログラムはデータベースにアクセスして、取引額、日付等を含む、これら２つの特定のエンティティ（送金エンティティ(remitting entity)および受取エンティティ(receiving entity)）間の以前の取引を示す表示を提供する。
【０１７９】
組み立てられた取引は、取引オブジェクト重要事項(transaction object Criticals)（すなわち、このガス会社の例でのベクトル重要事項(Vector Criticals)）がユーザーにより設定され確認されるまで、「実行利用可能(available for execution)」状態に進んで遷移することはできない。取引オブジェクト重要事項を設定して確認した上で（資本資産ベクトルの場合、これらはベクトル重要事項と呼ばれる）、組み立てられた取引は、ユーザーの判断で開始に利用可能な状態へ遷移する。プログラムは、オーディオ、ビジュアル、アニメーションを含む表示または提示を変更することにより、または輝度、色、形状、次元、配置等の状態を変更することにより、この遷移を示すことができる。
【０１８０】
ユーザーは、資本資産ベクトルをダブル・クリックまたは右クリック等することができ、それによりプログラムは、ステップＳ１１５においてメニューを表示画面に開く。メニューは様々なオプションを含み、１つのオプションは「ベクトル重要事項(Vector Criticals)」である。
【０１８１】
資本資産ベクトル取引オブジェクトの場合、ユーザーは最低２つの重要事項を設定し確認しなければならない。他の重要事項はデフォルト、または設定しないまま残すことができる。資本資産ベクトルに関する２つの必須の重要事項は、１）ベクトル・ソース割り当て(Vector Source assignment)（＝送金エンティティの決定）およびベクトル宛先割り当て(Vector Destination assignment)（＝受取エンティティの決定）を内含する方向、ならびに２）ユーザーが送金したい額である。資本資産ベクトルが取引組み立て段階でエンティティにカチッと付けられる(snap-attached)と、プログラムは、ベクトル・ソースあるいはベクトル宛先の選択肢のいずれかを選択するために、これらエンティティを重要事項インタフェースで利用できるようにする。ユーザーが取引にベクトル・タイミングを設定しないことを選ぶ場合、プログラムはこの設定を、技術的に実行可能な場合、「この取引を実行」ボタン("Execute this transaction" button)を押下すると、取引を即時実行するデフォルトにする。
【０１８２】
他の重要事項としては、通貨種別（すなわち、ターゲット・エンティティが許容する可能な通貨の中から）、支払い日、および異なる外部イベント（すなわち、給料の直接振り込み(direct-deposit of paycheck)の確認、為替ターゲット(currency-exchange target)等）により引き起こされる複数のベクトルまたは支払いを異なる日付で自動的に送金するオプション等を含むことができる。ユーザーは、ベクトル固有のパスワードを設定することも、または別法として、ユーザーのシステム・ログイン・パスワードを使用するようにベクトルを設定することもでき、それによりこのベクトルの重要事項へのアクセスを保護する。この設定は、目的重要事項を見る、または変更する際に全ての取引オブジェクトがパスワードを要求するように、プログラムにより全体的に制御することもできる。
【０１８３】
この取引の実行中におけるより高度なオプションの場合、ユーザーは、アクセスすべき各取引エンティティが実行時にユーザーによるパスワードの入力を求めるように（システムのプログラムがこのプライベート情報をファイルに保持するようにするのではなく）、このベクトルまたは全ての取引エンティティの設定におけるよりセキュアなオプションを選択することができる。
【０１８４】
プログラムは、重要事項の下での取引のタイミングを設定するオプションをユーザーに提供することに留意されたい。取引はリアルタイムで即座に行なうことができ、または取引のタイミングが指定されていない、または後日に指定される場合、取引は実行に関してパッシブ・フィルに設定される。これは、資金をユーザーの銀行口座から引き落とすことができるが、履行する日付前にシステムの投資エンジンに転用され得ることを意味する（以下の投資エンジン参照）。
【０１８５】
重要事項を設定した後、取引の組み立てが実行するに十分に完了するとすぐに、プログラムはステップＳ１１７において重要事項インタフェースを閉じる。ユーザーは、この時点で取引を保存したい場合がある。ユーザーは、取引が完全に組み立てられていて実行可能であるか否かに関わらず任意の段階の取引を保存することができ、また同様に、任意の暫定段階でテキスト文書を保存して閉じ、編集または完了等のためにそのテキスト文書に後日戻ることができる。
【０１８６】
取引を保存するには、ユーザーはドロップ・ダウン・メニュー中の「ファイル(File)」をクリックして「保存(Save)」を選択すべきであり、またはこの機能をキーボード等で実行することもでき、それによりプログラムは、ユーザーが保存すべき取引に名前を付けるよう要求するダイアログ・ボックスを提供する。次にユーザーは、ファイル名（すなわち、ガス会社通常支払い）を入力して「保存(Save)」を押下し、それによりプログラムはステップＳ１１８において、取引を保存し、将来ユーザーが要求した場合、これらファイルをユーザーが容易に利用できるようにするのに最適であると指示されるように、その取引をドロップ・ダウン・メニューまたは「取引(Transaction)」の他のウィンドウで、「最近(Recent)」の下でその取引を利用できるようにする。ユーザーは、任意の数の取引を作成して保存することができ、再使用または再見、編集、調整等を行なうのに随時利用することが可能である。
【０１８７】
取引がシンタックス的に実行可能な場合、以下言及する「この取引をテスト(Test this Transaction)」ボタンおよび「実行準備(Prepare for Execution)」ボタンを淡色、グレー、次元的に平坦なもの等から濃色、色付き、次元的に浮き上がり影を有するもの等に変更して、ボタン機能が非アクティブすなわち利用不可能な状態からアクティブすなわち利用可能な状態に遷移したことをユーザーに伝えることができることに留意されたい。
【０１８８】
ユーザーが、実行可能なように取引の組み立ておよび確認を終えた時点で、プログラムは、ユーザーがこのボタンを、システム中での任意の他の取引または活動にではなく、考慮中の取引に関連付けるように配置された「この取引をテスト(Test this Transaction)」ボタンを利用可能にし、このボタンにより、ユーザーは実際に本物の取引を実行する前に取引の実行をシミュレーションすることができる。
【０１８９】
ユーザーが「この取引をテスト(Test this Transaction)」をクリックすると、ＶｆＴプログラム・モジュールは、ステップＳ１１９において、このアクションをコマンドとして受け取り、ＭａＱｓプログラム・モジュールを介して組み立てられた取引中での全てのエンティティのチェックを開始して、実現性（技術的、金融的等）を判定するとともに、全ての取引額および結果として生じる全てのエンティティにおける変更のシミュレーション会計を、ユーザーに提示するために処理する。テスト中、資本は実際には移動しないことに留意されたい。
【０１９０】
このようにしてシステムは、ユーザーがシステムを介しての処理を選択した全てのユーザー金融活動範囲にわたって決定を行ない管理するように、ユーザーの財政に関する予測認識を提供することができる。一実施形態では、システムのプログラムは、履歴的(historical)および統計学的な情報資源(resource)に基づいて、カスタマイズされた判断解析を提供してユーザーをサポートすることができる。
【０１９１】
したがって、ＶｆＴプログラム・モジュールはテスト・コマンドを実行し、ＣＤＭＸプログラム・モジュールにいずれのユーザーがいずれのエンティティにこの要求を送っているかを教え、ＣＤＭＸプログラム・モジュールは、全てのユーザー登録口座(user-registered accounts)の記録を保持するセキュアな「口座レジストリ(Account Registry)」データベースにアクセスし、これら口座についての適切かつ正式な識別ならびにアクセス許可データを集める。記憶されることの他に、ＣＤＭＸプログラム・モジュールは、要求を実行してシステム外部の現実世界エンティティ(real-world entities)（組み立てられたエンティティ・アイコンを介して取引において識別される）から情報を検索するＭａＱｓプログラム・モジュールにこの検索情報を渡す前に、このアクセスにタイムスタンプを付け、これはテスト（シミュレーション）目的であるという指示がマークされた取引コードを割り当てる。
【０１９２】
したがって、テスト・ステップの一環として、プログラムは、インターネットを介して、および／または必要とされる利用可能な任意のセキュアな金融ネットワークを介して、関連する現実世界エンティティにあるユーザーの口座を取り合わせて、要求された情報を得る。例えばクライアント−サーバ環境では、要求はクライアントからサーバに送られ、サーバが外部エンティティに対して問い合わせを実行することに留意されたい。
【０１９３】
テスト・ステップの一環として、プログラムは問い合わせに背景チェックさせて、ガス会社システムが動作している（送金された取引額を受け取ることが可能である）ことを確認し、要求される取引通貨、現在の取引処理時間（すなわち、リアルタイム、１８分、２時間、４日、または他のタイマー周期等）等を判定するように指示する。さらに、同じステップにおいて、同様のチェックを銀行に対して実行して、残高（資金が利用可能なことを確認する）および銀行取引システムが動作していること（取引額を送ることが可能である）等を確認する。
【０１９４】
プログラムは、各種エンティティ口座から情報を受け取り、この時点でＭａＱｓプログラム・モジュールは、検索された情報、ならびにネットワークを介して要求を発行した結果として生じる場合がある任意の全体的なシステム状態またはそのネットワークの情報の更新をＣＤＭＸプログラム・モジュールに渡す。ＣＤＭＸプログラム・モジュールは次に、受け取った情報全てにタイムスタンプを付け、コード化し、記憶し、ここでもテストとして区別可能であるようにコードをマークする。次に、ＣＤＭＸプログラム・モジュールは、受け取った情報をフィルタリングして、要求された情報のみをＶｆＴプログラム・モジュールに渡す。したがって、ステップＳ１２０において、ユーザーの取引に伴うリアルタイム・シミュレーション実行データ(real-time simulated execution data)が、ユーザーにそのデータをエンティティ・アイコンの隣の画面に表示する、またはプル・ダウン・メニュー等の下に提供するプログラムによりユーザーに提供される（図１７参照）。
【０１９５】
一般的なメッセージおよび警告ダイアログ、ウィンドウ、警報等の他に、テスト進行中や実際に実行進行（Execution proceedings）中における取引の画面インタフェースおよび表示全体のグラフィック属性を、実際に進行中であり管理中であることをユーザーに容易に伝える輝度、色、次元、サイズ、配置等の差を用いて区別可能なように変更することができる。
【０１９６】
ユーザーが支払い機能をどのようにテストすることができるかどうかの一例は、以下の通りである。例えば、「テスト」機能を使用することにより、資金がユーザーの銀行で利用可能であるか、ガス会社の口座が取引の受け入れもまた利用可能であるか、についてプログラムは自動的にチェックする。例えば、ユーザーの銀行口座が未回収の資金を有する、またはガス会社の口座がオフラインである場合、取引は行なうことができず、プログラムは、ポップ・アップするか表示上に現れるかして、取引を行なうことができないことを記したダイアログ・ボックス中のメッセージでユーザーに通知する。ユーザーは、即座に取引を再試行するオプションを有し、または取引を後日行なうようにプログラムすることができるか、または取引をキャンセル等することができる。
【０１９７】
具体的には、「テスト」オプションを使用すると、ユーザーは、ＶｆＴプログラム・モジュールを使用するプログラムにより、シミュレーションされた取引の視覚的表現を見ることになる。例えば、プログラムは、「私の銀行口座」アイコンの上に、額を示したテキストキャラクタとともに、サイズが大きくなる金袋アイコンを表示することができ、テキストキャラクタは金袋アイコンに添付され、ユーザーが設定した正確な総額が得られるまで量が増大する。
【０１９８】
同時に、プログラムは例えば、「私の銀行口座」アイコンに添付された小さな会計ボックスを表示させることが可能で、この会計ボックスはユーザーの銀行における現在の残高を示しており、２行目には次第に負（赤）になって正の財布(money-bag)の増加と同等の負債に相当する回転額（rolling amount）を示す。
【０１９９】
ユーザーが設定したベクトル額に達すると、プログラムはベクトル額を財布の袋の中で二度明滅させてそのままにする、または完了を伝える或る同様の指示にする。
【０２００】
次に、プログラムは、ガス会社アイコン(Gas Company icon)上に円筒形アイコン(a cylinder icon)を表示し、現在の口座残高のテキスト指示を添付する。総額が借金の場合、このテキストは負でありかつ赤であるとともに、円筒形アイコン(cylinder icon)は空であり、境界線は赤である。借金と示される額が現在ない場合、黒字のドル額が表示され（すなわち、＄０．００）とともに、円筒形アイコン(cylinder icon)は空で、境界線は黒である。ガス会社の口座が現在、請求額よりも大きな預かり額を保持している場合、預かり額は緑のテキストを示すとともに、円筒形アイコンの境界線が緑となって、円筒形アイコンは量の緑のボリュームを示す。
【０２０１】
テスト中、プログラムは、財布アイコン(money-bag icon)が縮み始めるのと同時に、資本資産ベクトルが、例えば、ベクトルを通過していくサイズの増大を示す（すなわち、まるで大きい何かがパイプを通り、パイプの長手に沿って移動するときに一時的にパイプの直径を広げるかのように）ように、資金を或るエンティティから別のエンティティに移す。
【０２０２】
次に、プログラムは、例えば、取引が進行するにつれ、ガス会社アイコンを経て徐々に満たされていく（すなわち、まるで水が中に貯まっていくかのように）円筒形アイコンを示し、円筒形アイコン上に示される資本流入を数値で示すテキストが円筒形アイコンに添付される。
【０２０３】
取引額が或るエンティティから別のエンティティへの移動を完了すると、例えば、最終額に残る円筒形アイコンに添付された２行目のテキストや、取引の会計（言い換えると、支払われた残高および取引が借りている資金なしで完了したことを示す黒字のドル額（すなわち、＄０．００）、（負の赤）で任意の残りの未払い残高、あるいは緑のテキストでの預かり（過払い）である総計結果を示して現れる３行目のテキストをプログラムは表示する。
【０２０４】
プログラムは、例えば、「私の銀行口座」アイコンに添付されたテキストも表示し、資金が銀行口座の残高から移転された取引の会計もまた示すことがある。
【０２０５】
「テスト」機能については特定種別のアイコンを使用して説明したが、任意の種別のアイコンを使用することができるので、ユーザーの銀行口座からガス会社への資金の移転を示す任意の種別のインジケータを使用することが可能となることに留意されたい。したがって、取引における資金の移動を表示するユーザー・インタフェースの説明は、ユーザーの便宜のためのものであり、プログラムは、銀行口座の資金の利用可能性、資金を移転する銀行の能力、および取引を受け入れるガス会社の能力等をテストする。
【０２０６】
テストが完了した後、プログラムはステップＳ１２１において、ユーザーは、ダイアログ・ボックスを介して、「テスト再実行(Run Test Again)」、「取引編集(Edit Transaction)」、あるいは「取引保存(Save Transaction)」という取引オプションがプロンプトされる。
【０２０７】
この例では、ユーザーは「取引保存(Save Transaction)」を選択することができ、プログラムは、後で実行する、または将来検索、再見、編集、および／または実行等を行なうために取引を保存する。
【０２０８】
後日または複数自動分割払いの場合、プログラムは取引アクティブ化の警告通知をユーザー指定の電子メール・アカウントに送ることが可能であり、この通知はセキュアシステムウェブページへのＵＲＬを、システム・ログインおよびパスワードを最初に要求するインタフェースと一緒に含むことができるので、ユーザーログインが成功したと想定したときに、プログラムは取引詳細の表示を提供して、要求されたパスワードの入力を取り入れるウィンドウを形成し、確認チェックボックス等、ならびに「実行準備」ボタンおよび「取引実行」ボタンを提供する。プログラムは、どこか他の場所で説明したように、保存されている取引ファイルに取引詳細および結果を記録し、ユーザーは次にシステム・ログインしたときに利用することが可能であり、また、ユーザーが次回その（ＰＣ）クライアントからシステムにログインしたときにローカル−クライアント（すなわち、ユーザーのＰＣ）に自動的に更新することが可能である。
【０２０９】
ユーザーは、テストしたばかりの取引の詳細を見直ししたい場合、「取引のテキスト概要(Text Summary of Transaction)」と呼ばれる、取引ワークパッドの下部にあるボタンをクリックすることができ、それによりプログラムは、ユーザーの銀行口座に関連するあらゆる詳細、ＣＤＭＸプログラム・モジュールがテスト取引に割り当てた一意のコードを含む取引テスト概要を表示し、このコードは、コードがテストされたことを示すように実行時に一部を変更することができ、それから実際に実行することができる（例えば、コードは数字および文字からなってよく、１文字の「Ｔ」が「テスト」を示し、実行時に「Ｅ」をコードに追加することができる。このようにして、見直し中の取引が実行されたか、テストされたか、それとも両方が行われたのか、取引額、ベクトル重要事項により選択されたタイミング等、ならびにガス会社の料金、支払いについての詳細等を、ＣＤＭＸプログラム・モジュールは容易に区別可能であり、またユーザーも容易に理解することができる。
【０２１０】
ユーザーは、所望すればこれをプリントすることができる。ユーザーは、テストした取引および／または実行された取引のいずれか一方または両方のテキスト概要もまたプリントすることができる。実行された取引の概要は、取引のレシートとして有効である必要な情報および追跡コードを全て含み、この情報は支払いが開始されたことを証明するに足る。
【０２１１】
ＣＤＭＸプログラム・モジュールは全ての取引および取引に関わったエンティティを追跡するため、取引コードを含む、プログラムにより提供されるユーザープリントによるテキスト概要により、現実世界の受取エンティティにおける顧客サービス専門家は正確な取引の詳細を識別することができる。取引は従来の既存のセキュアな支払いネットワーク（ＡＣＨ、ＰａｙＰａｌ（登録商標）等）を介して実行されるため、これら受取エンティティはすでに、システムが開始した取引を受け取ることが可能である。したがって、受取エンティティは、どの第３者（すなわち、本発明のシステム）が支払いを開始したのかを気にしなくてよく、単に支払いを、同じインフラを通して受け取った他の全てと共に記録することが可能であり、したがって、消費者が、システム開始取引におけるベクトル宛先エンティティであった受取エンティティの顧客サービス部門に呼びかけて、額および支払いタイミング等の特定の取引詳細について話し合いたい場合、再見のために容易に検索可能になる。
【０２１２】
ここで、テストが成功し、シミュレーション結果が、ユーザーが取引を実行したいような満足のいくものであった場合、ユーザーは、取引ワークパッドの一番下にあるボタンをクリックすることができる。プログラムは、ステップＳ１２２において、取引ワークパッドを縮小させて、例えば表示画面の左側上に後退させ、取引エンティティおよび取引エンティティを結び付けるベクトルのみをはるかに小さい形で表示させる。
【０２１３】
このウィンドウの下に、プログラムは、ユーザーが保存した取引名(the Transaction Name)を表示し、取引名の下に、例えば下に行くほど最近のものになる時系列順に、この特定の組み立て済み取引およびベクトルを使用して行われた全ての履歴取引（もしあれば）を示す会計元帳(accounting ledger)または取引履歴(Transaction History)を表示する。
【０２１４】
このウィンドウの下で、プログラムは、「取引間近(About to be Transacted)」として本取引の日付および額を示す最終会計エントリーを示す。
【０２１５】
プログラムは、表示画面の下部に「この取引を確定(Lock in this Transaction)」ボタンを表示し、次にユーザーはこのボタンをクリックすることができる。「この取引を確定」ボタンを押下すると、プログラムは、例えば、必要な全ての態様においてチェックし確認する必要のあるアイテム・リスト（言い換えると、ユーザーの銀行口座に十分な資金、ガス会社システム・オンラインの利用可能性等）を含む取引の淡色表示の構成要素を示す縦長のウィンドウを表示する。
【０２１６】
次にプログラムは、チェックし確認すべきアイテムのチェックリストを通って進み、プログラムが見直しをすると各アイテムが点灯する（すなわち、アイテムは、問題がある場合は赤にかわり、取引を進めることができる場合は緑にかわる）。
【０２１７】
プログラムが取引の全ての態様を肯定とチェックし確認すると、プログラムは、ステップＳ１２３において、「取引確定・準備完了(Transaction Locked In and Ready to Go)」メッセージ等、ならびに確認アイコンを表示し、プログラムは次に、取引がある取引ワークパッドに関連する等の、表示されている「この取引を実行(Execute this transaction)」ボタンをアクティブ化する。表示上のボタンの配置は、ユーザーがこのボタンを考慮中の取引と正しく関連付け、システム中における他のいずれの取引または活動とも取り違えることのないようなものであるべきである。（このボタンは、ユーザーの判断で使用にアクティブな利用可能性の状態に遷移する。この遷移は、オーディオ、ビジュアル、アニメーション、または輝度、色、形状、次元、配置等の状態変化等を含む変化で認識可能であることができる）。
【０２１８】
こうしてユーザーは「この取引を実行」ボタンをクリックすることができるので、プログラムは、ステップＳ１２４において、縦長ウィンドウの内容を消去して取引の新しい実行アイテム・リスト、ならびに縦の下方進行ハイライト・バー(highlighted bar)を表示する。各アイテム（「取引の事前通知をガス会社システムに送信(Send Pre-Notification of Transaction to Gas Company System)」、「ユーザー銀行口座からの設定額分割(Partition Set Amount from User Bank Account)」、「分割した額の放出(Release Partition Amount)」、「ガス会社による受信確認(Confirm Receipt by Gas Company)」等）がプログラムにより実行され確認されると、完了したアイテムは、例えば緑にかわり、例えば左にチェックマークが付き、プログレス・バー(progress bar)がリストの下方に続く。選択された取引エンティティ毎に、プログラムは、関わる取引種別、目的−エンティティ（すなわち、送金、要求、購入、売却等）、および当事者エンティティ（すなわち、銀行、保険会社、ユーティリティ等）に応じて、確認されるためのアイテムに関する所定の命令のセットにアクセスすることに留意されたい。
【０２１９】
実行中、縮小された取引やベクトル・アセンブリは、実行プロセスの実際の各進行ステップに連動して、テストにおいて説明したグラフィック表示を繰り返す。したがって、例えば、実行プロセスが「分割した額の放出(Release Partition Amount)」を実行する場合、テスト手順中に説明した財布が徐々に尽きて、ベクトルを移動し始める等である。
【０２２０】
プログラムは、また、取引に対する全ての当事者（すなわち、銀行、ユーザー、ガス会社）によって追跡可能な一意の取引番号を取引にも提供する。
【０２２１】
取引が完了して取引番号が割り当てられると、プログラムは、ステップＳ１２５において、ベクトル取引の図、全口座詳細、機関コンタクト情報、および特定の公的取引−システム時間−スタンプデータ、ならびに取引番号を含む包括的な取引記録を表示する。
【０２２２】
次に、ユーザーは、ユーザーの記録のため、包括的な取引記録(the Comprehensive Transaction Record)をプリントアウトする、または単にデジタル・コピーをローカルまたはサーバに（ネットワーク記録は銀行業務法に従って自動的に保持される）保存することができる。ユーザーはまた、取引の詳細を任意の主要な金融会計ソフトウェア（Quicken（登録商標）等）にエクスポートすることができる。逆に、主要な金融会計ソフトウェアは、このようなアプリケーション内から本発明により可能になる取引を実行する能力を有することになり、全ての概要データが金融ソフトウェア・ログに直接戻される、等であることが構想されている。
【０２２３】
保存された取引は、それ以降の取引のテンプレートになるため、それによりユーザーは、保存された取引を再び開いて別のベクトルの取引を将来の日付で実行することができるので、重要事項および実行を確認する必要があるだけですむ。同様に、既存の保存されている取引のコピーを作成して、これらを元の取引と同様の新しい取引の中に素早く編集することができる。
【０２２４】
この一例は、ユーザーが第２の「ガス会社への支払い(Payment to Gas Co.)」取引アセンブリを作成することを望むかどうかかもしれないが、元の銀行口座の代わりに別の送金エンティティを備えている。ユーザーはまず、既存の保存されている取引ファイル・アイコンを一度クリックし、それから「ファイル(File)」プル・ダウン・メニューに行き、「取引ファイル複製(Duplicate Transaction File)」を選択し、ここでプログラムは、既存の保存されている取引のカーボン・コピーを生成し、その名称が、元ではなくカーボン・コピーであることを反映するように自動的に調整される。次にユーザーはこのカーボン・コピーをダブル・クリックすることができ、プログラムは、ユーザーがエンティティのいずれかまたは全てを編集、置き換え、および調整できるようにする。これを行なうにあたってのユーザーの利点は、カーボン・コピー中のエンティティの設定全てが、元にあったまま残る（ユーザーの判断で変更可能であるが）ことであり、したがって例えば、ベクトル方向(the Vector direction)は、ガス会社に送金するために必要なようにすでに適切に設定されている。
【０２２５】
取引については、実行前にテストするものとして説明したが、ユーザーは取引をセットアップし、それからすぐに実行に進み、それによってテスト機能をスキップすることも可能であることに留意されたい。
【０２２６】
従来簡易型取引は、本発明による分散型資本システムにおける全能力のほんの一部のみを使用するが、この機能は今日、ユーザーが最も容易に利用可能なものの１つである傾向がある。本発明による分散型金融システムは第３者プラットフォームであるため、ユーザーは単一の口座を維持し、同じ口座およびログインシステムを介して、銀行口座であれ、クレジット・カード口座であれ、ユーティリティ料金であれ、各種ローンであれ、投資ポートフォリオ等であれ、任意の数の多様な口座を監視することができ、また、経験的取引当事者−エンティティおよび取引オブジェクト−エンティティを本明細書にある程度説明したように使用して、所望のようにそれらのいずれかまたは全てからの取引を構築し、テストし、かつ実行することができる。
【０２２７】
従来複合型取引(Traditional Compound transaction)
本発明による一実施形態では、従来簡易型取引(Traditional Simple transaction)と同様に従来複合型金融取引(Traditional Compound financial transaction)を組み立てて、テストし、かつ実行することができる。本質的には、上に述べたように、従来複合型取引には、従来の金融システムでは普通結び付けられない２つのエンティティが関与する。従来複合型取引は多くの様々な形を採ることができるため、３つの例で説明する。さらに、ユーザー・インタフェースについては従来簡易型取引に関して詳細に説明したため、以下詳細には説明しない。
【０２２８】
例１(Example 1)
ユーザーがログインし、認証し、「新規取引(New Transaction)」に到達し、従来簡易型取引において上に述べたようにブランクの取引ワークパッドにいる場合、ユーザーは次に、従来簡易型取引において説明したものと同じプロセスを続ける。例えば、ユーザーは「私の株式(My Stocks)」を選択したい場合があり、「私の株式(My Stocks)」アイコンをマウス・オーバすることにより、プログラムはユーザーの口座にアクセスし、口座に関連するリアルタイム・データをいずれも取得して表示することができる。
【０２２９】
本発明の方法およびシステムを適合する例１では、ユーザーが「私の株式(My Stocks)」や「私の自動車ローン(My Auto Loan)」を選択する場合があり、問題となっている現在の自動車ローンは、例えば１８ヶ月の支払いが残っている。ユーザーは、ここで、これら２つのアイコンおよび取引オブジェクト・アイコンである「売却(Sell)」を使用して、ユーザーが望む株式を何でも売却し、それから資本資産ベクトルを用いて、流動資本を自動車ローン全額の支払いに向ける取引を、単一のプログラムされた取引として構築することができ、全ては本発明の分散型金融プログラムにより記録され管理される。
【０２３０】
従来簡易型取引と同様に、ユーザーは、１つの取引として取引を組み立て、テストし、変更し、それから実行することができる。したがって、金融取引に中間ブローカー(interbroker)または介在者(intersticial parties)を関与させる必要がない。
【０２３１】
ＭａＱｓプログラム・モジュールは市場とのやりとり、およびＶｆＴプログラム・モジュールを使用して構造化され、ＣＤＭＸプログラム・モジュールを使用してコード化されたコマンドの実行を取り扱うことに留意されたい。ＶｆＴプログラム・モジュールは、ＭａＱｓプログラム・モジュールおよびＣＤＭＸプログラム・モジュールから供給される情報により更新される全ての取引の閲覧可能な記録を保持する。また、ＶｆＴプログラム・モジュールは、取引を保存し、額、相手方口座番号、時刻等を解析するために見直しおよび追跡目的で利用できるようにする。
【０２３２】
例２(Example 2)
本発明の方法およびシステムを適合する別の例では、「新規取引」メニュー下で、ユーザーは「問い合わせ」等のオプションを選択することができ、また複数のオプションから「ローン」、「保険」等を選択することができる。この場合、ユーザーは「ローン」を選択することができ、この時点でプログラムは、ユーザーに各種ローンパラメータ（すなわち、「ローンパラメータ設定(Set Loan Parameters)」オプション）を入力するように促す。ユーザーがパラメータを入力すると、プログラムは市場（すなわち、銀行、クレジット・カード会社等）または分散型資本システム・コミュニティ(distributed capital system community)（ローンをシンジケートすること(syndicating a loan)に参加する複数の貸し手を呼び込むために）に、ユーザー指定のローンについて問い合わせ、利子率、クレジットデータ等のリアルタイム情報を返信する。ユーザーは、ローンへの申し込みを決める場合申し込むことができ、そしてその申し込みはオンラインで、従来取引において銀行等の単一の相手方と（従来簡易型取引を構成する）、あるいは本発明の本プログラムにより自動的に調整されるシンジケート様式で複数の貸し手と（共同簡易型取引を構成する）行なうことができる。いずれの手法を用いてローンを確保するかに関わりなく、この初期活動は、この例では以下の通り、連続した取引活動にリンクされ、従来複合型取引の構成要素になる。このようにして、取引種別は独立した取引種別としてのみの使用に制限されずに組み合わせて、ユーザーが見つけ出すことができる結果が何であれその効率化を実現することができる。
【０２３３】
ユーザーが例えばローンをオンラインで認可され、資金が銀行またはクレジットユニオン等で利用可能になると想定すると、ユーザーは次に、ローン資金を、例えばユーザーのクレジット・カードまたは子供の大学ローン等の返済に充てることができる。この取引は、ユーザーが「私のローン(My Loan)」アイコン、「私のクレジット・カード(My Credit Cards)」アイコン、および「私の大学ローン(My College Loan)」アイコンをアップし、これらを「資本資産ベクトル(Capital Asset Vector)」等の「取引オブジェクト(Transaction Object)」に結び付け、ローン資金を使用してクレジット・カードおよび大学ローン請求を返済するという点で従来簡易型取引と同様である（図１８参照）。
【０２３４】
資金は、２つ以上の「資本資産ベクトル(Capital Asset Vector)」を使用してローンから分けることができることに留意されたい。資本資産ベクトルの同時または連続しての発出を実行するようにプログラムに指示することができる。テスト要求および実行要求は、保留中の取引全てに対して一度に開始することができる。
【０２３５】
さらに、当業者は、この種別の取引が、複数の異なるターゲットと相互作用する任意のエンティティ（すなわち、従業員にそれぞれの給料を支払っている雇用者等）間で実現可能であることを認識するであろう。
【０２３６】
例３(Example 3)
本発明の方法およびシステムを適用するさらに別の例では、ユーザーは、例１の場合のように投機活動をプログラムすることができ、ユーザーは株式を「売却(Sell)」したいが、特定の価格でのみそうしたい。プログラムはユーザーに、売却パラメータを設定するオプションを提供する（ローンパラメータが設定される例２のように）。株式価格はプログラムによりリアルタイムで取得してユーザーに表示することができるため、ユーザーは、株式価格が、ユーザーが売却したい価格よりも下であるか否かがわかる。
【０２３７】
したがって、プログラムは、ユーザーに、ユーザーが望む価格に達したときに株式を売却するオプションを提供することができると同時に、プログラムは、市場において取引をユーザーがプログラムした任意の間隔でリアルタイムにテストしたり、または特定の時刻または日付に、その時刻での株式価格等が何であれ株式を売却したりすること等ができる（すなわち、「ローンパラメータ設定(Set Loan Parameters)」機能と同様に、「売却パラメータ設定(Set Sale Parameters)」機能がメニューの一部として提供される）。
【０２３８】
プログラムは、ユーザーが、特定のトリガー・イベント(a certain triggered event)の発生時に特定の金融証券に投資し、終了の引き金が外された場合にシステムに投資を自動的に終了させ、それに従ってユーザーの銀行口座に利益を送るようにシステムを事前設定することができるような、トレーリング・ストップ・ロス・モニタ(trailing-stop-loss monitors)のような機能も組み込む。
【０２３９】
したがって、ユーザーは、ユーザーによって設定されたパラメータに従って将来の時刻に行なうことができる任意の種別の投機（または非投機）活動をプログラムすることができる。
【０２４０】
さらに、プログラムは、「テスト(Test)」でパラメータが満足させられたときに取引を自動的に実行する上で、プログラムは、ユーザーがログインしたときにメッセージをユーザーに提供することにより、またはユーザーのコンピュータ、もしくはユーザーの携帯電話、ページャ、もしくはモバイル・オーガナイザ(mobile organizer)等にユーザーへの電子メールを送ることにより、プログラムされた取引が行われたことをユーザーに自動的に（またはユーザーによる要求により）通知することができる。
【０２４１】
したがって取引は、本発明の分散型金融システムを通して遠隔的に、安全に、かつ自動的に行なうことができる。
【０２４２】
共同簡易型取引(Collaborative Simple Transaction)
従来複合型取引(Traditional Compound transaction)と共同簡易型取引(Collaborative Simple Transaction)の相違は、前者は単一の顧客が複数の片道ユーザーの会計や取引を一箇所で一緒に操作できるようにする一方で、後者は、複数の顧客が同じ口座および／または取引に参加する可能性を生み出すことにある。共同簡易型取引の一実施形態による方法およびシステムについて以下に説明する。上述した従来複合型取引の例２のように、取引種別は、ユーザーが各自のニーズを達成する拡張取引を作成するのが適切であると考える場合に組み合わせることができることに留意されたい。
【０２４３】
例１(Example 1)
共同簡易型取引の一つの例では、ユーザーは、他のシステム・ユーザーに拡張された投資機会または他の資金調達活動をセットアップすることができる。「投資機会」は、この種別の取引は所定数のユーザーに向けて提供されるか、そうでない場合は、所望の投資資金（例えば、慈善事業への寄付金調達、または法人証券投資への招待）の上限額等を使用して規定または制約されることを除き、従来簡易型取引の例において説明したものと同様に、取引ワークパッド上でユーザーによりセットアップされる。
【０２４４】
ユーザーは、次に、メニューオプションを使用して、例えば、ユーザーが「機会(opportunity)」を届けたいユーザー（「被招待者(invitees)」）リストを作成することができ、または他の例では、様々な制約を選択して、機会へのアクセスを事前設定された制約に見合ういずれのユーザーにも提供することができる。この種の取引に参加しているユーザータイプの区別は、ユーザー・インタフェース上に可視的に表示することができ、おそらく、名前が挙げられ、特に招待された当事者は正方形オブジェクト（図１９）で表され、名前は挙げられていないが、事前設定されている制約に対して有資格な参加者は円（図１９）で表される。プログラムのＣＤＭＸモジュールは、オファーに一意の親取引番号を、それから各被招待者ユーザー名に子コードを提供し、またＣＤＭＸは、列挙された各被招待者に分配する一意のオファー取引被招待者パスワード (offering transaction invitee passwords) を発生させる。
【０２４５】
さらに、ユーザーはメニューおよびプル・ダウン・オプションにアクセスすることができ、ここでユーザーは、取引に対する様々な制約、例えば、取引への受け入れおよび／または参加に対する時間制限（すなわち、３０日）を調整することができる。
【０２４６】
被招待者がユーザーにより確認されると、プログラムは、ユーザーがそれぞれの口座に次回ログインするときに、おそらく明滅するアイコン等の形でオファー機会についての通知を見るように、ユーザーのシステム口座に自動的に通知する。例えば、機会へ参加するよう招待する通知をマウスクリックして承認すると、システムは特定のオファー取引パスワードの入力を求める。ユーザーがこのパスワードを有していない場合、オファーにアクセスすることはできない。被招待者は、電子メールを介して、（または電話、郵送等により）それぞれ個人のオファー固有のパスワードを受け取る。このようにして、取引のユーザーオーナーは、間違った人物が偶発的に、その人物に意図されていない取引へのアクセスを得るには、被招待者を二度誤って識別する必要がある（上述した被招待者をシステムに対して識別する際に一度、またおそらく、同じ間違った人物に特定のオファー取引パスワードを有する電子メールを送信することにより、被招待者と通信する際にもう一度）。
【０２４７】
正しい被招待者にオファーがシステムにより首尾良く通知されるが、間違った人物がオファー固有取引パスワードを受け取る場合では、その人物がシステム口座を有してログインする場合であっても、オファー招待の通知はないため、パスワードは役に立たない。逆に、システムが識別した被招待者が間違いであり、間違った人物がオファー取引招待通知を受け取る場合、ユーザーは機会へのアクセスに必要なパスワードを有さない。このようにして、システムはセキュアであるように、また不注意の、意図しない、さらには望ましくない金融相互作用を制限するように設計される。
【０２４８】
正しいシステム口座が通知され、その後正しい特定の被招待者オファーパスワードが入力されることを介してアクセスが実現される場合、ユーザーには、例えば、マウス・オーバ中を介して、またはマウスを右クリックしてメニューまたはダイアログ・ボックス等をプルアップする(pull up)ことによって、システムで「投資機会(investment opportunity)」へのアクセスが与えられる。取引の詳細はプログラムによりリアルタイムで提供され、プログラムは全ての情報（すなわち、要求される額、要求される日付、他の投資家、他の投資家が提供した額等）をユーザーに提供する。
【０２４９】
「投資(investment)」取引詳細を検討した後、被招待者は次に「投資機会(investment opportunity)」の「オファー(offer)」を「許諾(accept)」または「辞退(decline)」することができる。被招待者がオファーを辞退する場合、プログラムは取引ワークパッド画面からアイコンを削除し、一例では、被招待者にコメントをオファーする当事者に送る手段を提供する。ユーザーは、取引を後日再び検討したい場合、許諾も辞退もせずに取引を終了することもできる。
【０２５０】
ユーザーが取引を許諾したい場合、ユーザーは、例えば「許諾(accept)」をクリックすることができ、それから従来簡易型取引の場合と同様に、取引のセットアップに進むことができ、ここで例えば、ユーザーは銀行口座にアクセスして、エンティティ、この場合は「投資機会(investment opportunity)」に支払う額を取り出す。
【０２５１】
従来簡易型取引と同様に、ユーザーは取引をテストし保存することができる。さらに、ユーザーは、銀行口座または投資信託口座等からの資金を使用して店からの請求に対して準備する方法と同様に、「投資機会(investment opportunity)」への支払いの支払い計画を準備することができ、これは定期的なまたはランダムな間隔で設定額または可変額を送金することを含むことができる。全額が「投資機会」に支払われると、プログラムはアイコンを閉じる、またはアイコンを利用不可能にし、ユーザーは、請求が支払われたときに得られるものと同様に、「投資機会(investment opportunity)」への支払額の取引記録を有する。この投資機会取引イベントは、後日再び投資するという点で再使用不可能であり得るが、その取引ファイルは被招待者クライアントに残し、投資資産についてのリアルタイム情報で更新することができる。このようにして、一回限りの取引イベントをリアルタイム情報で更新することができる。
【０２５２】
例２(Example 2)
本発明によるもう一つの例では、２人のシステム・ユーザーがオンライン購入で共同したい場合がある。購入には、２人のユーザーの銀行口座、クレジット・カード等のそれぞれ１つまたは複数からの複数の異なる額の資金を、アイテムを販売している第３者に送金することが必要になる。
【０２５３】
しかし、電子マネーシステムと異なり、プログラムがＭａＱｓプログラム・モジュールを介して、既存のインフラを介して既存の口座に支払いを向けることができるため、売り手が共同取引を受け取るための特別な口座は必要ない。
【０２５４】
取引は例１とよく似たように構築されるが、ここでは「購入機会(purchase opportunity)」を構築することができ、共同して購入額に達するまで、第１のユーザーが第２のユーザーに「購入機会(purchase opportunity)」への支払いを促すことができる。その時点で、第１のユーザーは売り手に販売を「促す(invite)」ことができる。これを実現するために、第１のユーザーは、システムのプログラムを介して「購入機会(purchase opportunity)」を売り手に自動的に送信させ、その後、電子メール、または言葉等を介して特定の機会パスワードを売り手に別個に通知する。この種の取引に参加するには、ユーザーはシステム口座を有さなければならない（そうでなければ、参加者を認証する二重安全手法の実現が難しくなる）ことに留意されたい。プログラムのＣＤＭＸモジュールは各取引を辿り、安全に行われることを保証する。
【０２５５】
例３(Example 3)
本発明による別の実施形態では、外国為替構成要素を用いて例１を１ステップ広げて使用することができる。例えば、図１９に示すように、取引ワークパッド(Transaction Workpad)上のアイコン１(icon 1)として識別される「投資機会(purchase opportunity)」を、アイコン２〜５(icon 2〜5)として識別される４人の潜在的な参加者に送ることができる。ユーザーは、外国交換構成要素（アイコン１(icon 1)とユーザー（左側の大きな銀行口座アイコン(large Bank account icon)）の間の垂直バーとして識別される）をセットアップすることができるが、その場合、取引へのエンティティはいずれも１つの通貨での資金を供給して、別の通貨に自動的に交換させることができる。これは、異なる取引種別を組み合わせて単一のより大きな取引を実行することの別の例である。為替機能については、以下の共同複合(Collaborative Compound)の例を参照のこと。
【０２５６】
共同複合(Collaborative Compound)
この取引は４つの実施形態の中で最も高度なものであり、システムは主にこの取引のために設計されたものである。共同複合型取引(Collaborative Compound transactions)では、例えば、何百万ものユーザーをそれぞれの金融目標を追求するにあたって統合することができる。上に述べたように、共同取引では、取引の双方が各自を顧客であるとみなしており、そうすることによって互いの提供者の役割を果たす。多くの場合、顧客は互いを直接認識せず、本発明は単純に、共同複合実施形態を用いて取引をより効率的にする、またはコストを下げる、またはその両方を達成する。
【０２５７】
現在、このモデルに従う取引は存在せず、したがって以下の例が共同複合型取引の実施例である。
【０２５８】
本発明による共同複合型取引について以下より詳細に説明する。共同複合型取引では、プログラムは、ＶｆＴ、ＳＶＲ、ＣＤＭＸ、およびＭａＱｓプログラム・モジュール等、主要なプログラム・モジュール全てを利用する。
【０２５９】
さらに、以下に提供する最初の例は為替に関わるが、これは様々な取引種別―従来簡易型から本発明の共同複合型まで―のいずれにおいても実現することができることに留意されたい。例えば、請求の支払いに関わる従来簡易型取引は、アイテムの対価をフランスにいるエンティティに仏フラン（またはユーロ）で支払い、フラン（またはユーロ）を米ドルに交換することによって行なうことができる。したがって、為替は、共同複合例だけの領域ではない。
【０２６０】
例１
このように、本発明に適合する、共同複合型取引に関して手短に上述した一例では、ユーザー企業が特定の活動に英ポンドを必要とする場合がある。ユーザーはシステムのウェブサイトにアクセスし、例えば従来簡易型取引下で説明したようにＶｆＴプログラム・モジュールを使用して取引を組み立てるステップを用いて、図２０のステップＳ２００において、取引ワークパッド上に「為替(Change Currency)」取引を構築する。ユーザーは、取引を構築すると、所望であれば、前に述べたように取引をテストして実行することができる。
【０２６１】
テストされると、プログラムはＣＤＭＸプログラム・モジュールおよびＭａＱｓプログラム・モジュールを使用して問い合わせ、ステップＳ２０１においてリアルタイム市場通貨レート(real-time market currency rates)、またはユーザーが国または相手方情報を知りたいということを示し、かつそれが利用可能な場合はこのような情報を取得して、ユーザーが取引を実行したいか否かを判断できるようにユーザーに情報を提示する。
【０２６２】
為替レートがユーザーの望むものではない（すなわち、英ポンドのコストが高すぎる）場合、ユーザーは、通貨が特定の交換値に達するまで、プログラムがスケジュールされた間隔で市場に問い合わせ続けることができるように取引をプログラムすることが可能であり、またユーザーは、他のより単純な取引に関して上に説明したように、取引が特定の日等に行われるようにプログラムすることができる。スケジュールされた取引は、即座に実行すべきである（すなわち、リアルタイム）とユーザーが示すか、または固定タイプであるイベント・トリガー(event trigger)が示さない限り、デフォルトでプログラムによりパッシブ・フィル(passive-fill)またはパッシブ・タイプ(passive type)の取引に指定される。
【０２６３】
ステップＳ２０２において、ユーザーがリアルタイムでの取引実行を決定した場合、ステップＳ２０３において、プログラムはＣＤＭＸプログラム・モジュールを呼び出し、一意の取引番号（すなわち、親コード）をコード・スタンプし(codestamp)、または割り当てて、システムを通して取引を追跡する。プログラムは、ＣＤＭＸプログラム・モジュールを使用して取引に関する記録情報を暗号化した形で保存し、ステップＳ２０４において、確認データがプログラムによりＶｆＴプログラム・モジュールに再び渡され、ＶｆＴプログラム・モジュールは、ユーザー・インタフェースを介してこの情報をユーザーに提供する。リアルタイム指定の取引では、要求実行時に資金はＳ２０５においてステップ・ユーザーの口座から取り出されないが、関連する口座（複数可）への実行命令を即座に送ることができるように、要求遂行（すなわち、以下述べる相手方のマッチングまたはマッチ・コードの割り当て）後に取り出される（すなわち、マッチ・ペアリングが解決するまで命令が実行不可能である）ことに留意されたい。
【０２６４】
プログラムは、要求にコード・スタンプを付ける(codestamp)と、ＭａＱｓプログラム・モジュールおよびＳＶＲプログラム・モジュールを呼び出して取引を実行する。ＭａＱｓおよびＳＶＲプログラム・モジュールが呼び出されると、算術平均またはアルゴリズムで計算されたセパレーター等の主なアルゴリズムの１つを使用して、ステップＳ２０６において、ＳＶＲプログラム・モジュールは、所望の取引を実現する相手方をマッチングする。
【０２６５】
特に、取引ベクトルは、方向および額タイプ（例えば、通貨対）に従って分けられ、値でランク付けされる。ＳＶＲプログラム・モジュールは次に、上に述べた様々なアルゴリズムによるクロス・マッチ(cross-match)に進む。
【０２６６】
上に述べたように、額が元々プログラムによりアクティブ・シークに分類されている場合、プログラムは、要求を単一の相手方のマッチング額で遂行しようと努める。さらに、額が元々プログラムによりパッシブ・シークに分類されている場合は、平均の下になるまでアクティブ・シーク額分低減され、アクティブ・シーク額自体になるように再分類され、その後、フィル（fill）されて取引が完了する。
【０２６７】
したがって、ドルを英ポンドに交換する要求と、英ポンドをドルに交換するという別のユーザーからの要求とのマッチングは、いくつかのアルゴリズムの少なくとも１つを使用してマッチングすることができる。プログラムがどのアルゴリズムをその交換に使用するか（また、このアルゴリズムがプログラム可能であるか）に関わりなく、ＳＶＲプログラム・モジュールは常に相手方のマッチ・ペアを生成する。
【０２６８】
プログラムは、ユーザーによる英ポンド要求を、英ポンドを保持する別のユーザーによる、マッチングする米ドル要求とマッチングする。一方よりも他方の額が大きく、マッチが行われた後、いずれかの側にゼロではない残りがある場合、プログラムは、別のシステム通過で残りをマッチングさせる。例えば、大きな取引がシステムを通過するとき、ＳＶＲプログラム・モジュールは取引額を複数の部分に分け、システムを通過する連続した取引の中でそれぞれ１つを異なる相手方とマッチングさせる(match-pair)。
【０２６９】
ステップＳ２０７において、ＣＤＭＸプログラム・モジュールが呼び出されて、全ての残額がマッチングする、すなわち解決されるまで、相手方マッチング解決(the counterparty matching resolution)（ベクトル分散）のプロセスを通して、個々の当事者をコードサイクルして追跡（マッチ・ペアをタグ付け）し、いくつかのさらなる子コードを作成して、マッチングプロセスを通して、取引の異なる、または連続した部分を追跡し、取引部分を親取引まで辿ることができるようにする。これらコードはそれぞれ、ＣＤＭＸプログラム・モジュールにより会計追跡元帳(an accounting tracking ledger)に記録され、ステップＳ２０８において、コード・マッチ集約器(the Codematch Aggregator)（以下さらに説明）に送られて蓄積される。マッチングが行われた後、ＣＤＭＸプログラム・モジュールは、最終結果が所望の取引の実現であるように、支払いを実行する前に取引部分を再度組み立てる。
【０２７０】
システムは、各取引を終了まで厳密な逐次様式では処理せず、現在の取引がまだ遂行の過程にある間であっても、連続した取引要求を混合する、または取引を織り交ぜることに留意されたい。
【０２７１】
ＳＶＲプログラム・モジュールは複数の取引を同時に処理するため、マッチ・ペアは複数の相手方を有する。
【０２７２】
したがって、ステップＳ２０９において、プログラムは、ＭａＱｓプログラム・モジュールを呼び出して、ユーザーの口座からしかるべきユーザー宛先口座(the user-destination account)への資金移転命令(the funds transfer instructions)を実行する前に、ＣＤＭＸプログラム・モジュールのコード・マッチ集約機能(the Codematch Aggregator program)を呼び出して、収集（同ユーザーの取引額の集約）し総計（額が総計される）し、この合計は、既存の金融システム・インフラを介して実行された、当初意図された取引の全額に等しい。したがって、コード・マッチ集約プログラムは、プログラムされた設定に従って、銀行マルチプレクサ・プログラム(the Bank Multiplexer program)のアクティブ化を待つことができるため、ステップＳ２１０において、ユーザー口座への資金の移転を一括することができる。ＣＤＭＸプログラム・モジュールは、実行された取引の確認および追跡情報を記録する。
【０２７３】
ＳＤＥＸ（リアルタイム即時転送）取引では、命令は、相手方マッチングがすでに実行された後に、ユーザー口座に対して実行される。ＣＤＥＸ（固定およびパッシブ・フィル）取引では、ユーザー口座がまずシステム所有口座（以下の投資エンジン参照）に送金され、相手方マッチングがＳＶＲプログラム・モジュールにより解決する間、またはその後、正確なユーザー指示取引が行われるまで保持される。取引が通過交換を含み、このような取引のオーナーにより投機として指定されていない場合、ユーザーの事前スケジュールされた取引の期日が来て資金が必要になるまで、システムは各自のプログラムされた判断で、資金を即座に引き落として基本通貨を保持する、またはターゲット通貨に交換して保持することができる。
【０２７４】
従来簡易型取引に述べたように、プログラムは、それぞれのログイン口座内のメッセージ、電子メールを介して、または電話、携帯電話、ファックス、もしくは他の任意所望の媒体により、取引が完了したこと、ターゲット通貨がそれぞれの口座に振り込まれたこと、それぞれの通貨で対応する額と任意の手数料がそれぞれの口座から引き落とされたことをユーザーに通知する。引き落とされる取引手数料は、プログラムにより利益としてシステム所有口座に流れる。
【０２７５】
例２
本発明による２番目の例に示すように、図２１Ａでは、Enterprise A's−４４額がアクティブ・シーカであり、プログラムはこれを図２１Ｂ中のEnterprise A's＋１２０にクロス・マッチングさせ、４４個のゼロ和対(zero-sum pair)が作成され、Enterprise A of＋７６はシステムに残る（図２１Ａおよび図２１Ｃ参照）。
【０２７６】
プログラムはInstitution B's＋３２をアクティブ・シークして、３２個のゼロ和対（図２１Ａ参照）を作成し、Institution B's−８８をシステムに残し、プログラムはこれを即座にアクティブシーカボブ＋１２にマッチングさせて１２個のゼロ和対を作成し、Institution B's−７６をシステムに残す（図２１Ｃ参照）。プログラムは、Enterprise A＋７６およびInstitution B−７６に関して期間の最終ゼロ和対を作成し、システムを空にする（領域のゼロ和を立証する）（図２１Ｃ参照）。
【０２７７】
したがって、マクロ元帳(the Macro Ledger)のゼロ和対が図２１Ａおよび図２１Ｃに列挙され、ゼロ和対が双方で同じ相手方を有する場合、プログラムにより削除することができ、経験的に削減された図２１Ｃのマクロ元帳(Macro Ledger)を形成する。図２１Ｃの経験的マクロ元帳は、最も効率的な資本ベクトル（額および方向）を表示する。全ての額が総計から独立して移転された場合、１６４単位の資本が移動することになる。単一当事者総計が用いられる場合、１００単位の資本が移動する（Institution BからEnterprise Aに８８、Enterprise Aからボブ(Bob)に１２）。分散ベクトル総計が用いられる場合、８８単位のみが移動する（以下のマクロ経験的元帳に示すように、Institution Bがボブ(Bob)に１２移動し、Enterprise Aに７６移動する）。この最小資本移動はそれでも、世界の各当事者の総計元帳口座を満足させている（Enterprise A、Institution B、およびボブ(Bob)の個々の各元帳における値を合算することによる）。
【０２７８】
例３
本発明による別の例では、資金を英ポンドに換える単一ユーザーではなく、より大きい規模で、米国のような国が、未払い金の４百万米ドルを、例えばユーロに交換してジュネーブ銀行口座に振り込み、国連に支払うことができる。本システムは、このような複合取引を実行し、欧州に存在する個人および法人（ユーロを保持し、ドルを求めている）を米国によるユーロ要求とマッチングさせて、何千人または何万人もの未知の相手方の間での完璧な共同的マッチングを解決する。本システムの効果は、厳密に通貨に限定されず、代替可能な取引の道具として取り扱うことができるもの全てに対してのものである。
【０２７９】
システムが為替または任意の取引のニーズに見合う十分な内在する流動性を有していない場合、プログラムは、市場を自動的にチェックして、交換要求を従来の銀行に流して要求を満たすことができることに留意されたい。この資本注入は、結果として発生する任意の従来市場手数料の通過以外は、ユーザーに対してトランスペアレント(transparent)である。流動性危機の場合、つまり交換要求が満たされないか、それと同様の場合は、一般の市場においても、ターゲット通貨を供給しようとする人がいないであろうことが考えられる。
【０２８０】
したがって、本明細書に記載のシステムは、流動性危機を回避することはできないが、プログラムは、毎日の売買高の監視等から、このようなことについて早期の警告を与えることができ、取引をプログラムしスケジュールすることができることから（パッシブ・フィル(passive-fill）、流動性が鈍る期間中に、事前にスケジュールされたパッシブ・フィルを実行するようにシステムをプログラムすることができるため、結果としてある程度の緩和を行なうことができる。
【０２８１】
さらに、分散型資本移転（ＤＦＴ）（下述する）は、このシステムにより可能になることから、システムが資本逃避の方針に由来する規制（資本の自由な流れに障壁を作り出す）を迂回することができるため、結果として大衆市場の世界規模での流動性危機について非常に早期に警告を行なうことができると共に、システムの要員は、資本を国から輸出しようとしているが、規制制限等によるのではなく、資本輸出を希望する者の基本通貨を要求する当事者の不足によりシステムのＤＦＴ機能を使用することができないでいる人々から発生する初期局地流動性危機をより明確に気付くことができる。
【０２８２】
例４
本発明による共同複合型取引の別の例では、互いに相補的な資本管理ニーズを有している、互いを自身が選択したか、またはランダムにマッチングされた２つの企業間で資本資金の交換を行なうことができる。例えば、米国企業が中国で得たＲＭＢ利益を（米ドルとして）米国へ返送したい場合、中国から資金を移転するにあたって制限がある可能性が高い。また、米国企業が、中国への新しい投資のために米ドルの蓄えをＲＭＢに交換したい場合、新しい資本を持ち込むにあたって制限がある可能性が高い。
【０２８３】
分散型資金移転プロセスを実行するＳＶＲプログラム・モジュールは、ターゲット銀行口座が適宜設定されている場合、地域企業の口座からそれぞれ反対の企業の口座への、米国および中国それぞれに１つずつのように、２つの国内移転からなるベクトル・スケジュールを単純に解決することができる。額面では、これは２つの独立した関連のない資金の国内移動に見えるが、マクロとしては、イベントは要するに、分散型システムを介してそれぞれの通貨を交換する２つの企業となる。このようにして、２つの企業は、それぞれ国境を越えて金を移動するというそれぞれの目的を、国家間資本移動における難しさ、注意、費用、および考えられる制約なしで達成することができる。
【０２８４】
差し迫った要求日または遂行される資金額を何らかの理由により満足させることができない場合、プログラムは、システムが示唆する日までユーザーに待つよう促す、または取引を後でキャンセルするよう促す。取引を実行することができると、資金は取引の両当事者の銀行口座から引き落とされ、プログラムは要求を遂行し、ターゲット通貨での額をユーザーの銀行口座に送信する。
【０２８５】
利益および社会貢献のための投資エンジン(Investment Engine for Profit and Philanthropy)
本発明による一実施形態では、ユーザーの指示による、またはパッシブ・フィルの要求タイプによる場合に、プログラムは、ＣＤＭＸおよびＭａＱｓプログラム・モジュールを介して、口座を保持している回転ドアを通る分散資本の流れを集約し、資金を使用してリスクのないまたは低リスクの投資を一時的に保持する。
【０２８６】
上に述べたように、パッシブ取引タイプはデフォルト・タイプであり、ユーザーが取引を特定の日付までに行なわなければならないこと示すことを特徴とする。これは、その日付までの時間はいずれも、取引の開始、実行、および資本の使用に許諾可能な日付として解釈することができることを意味する。したがって、システムはパッシブ・フィル取引の資金を引き出し、その資金を短期投資のために口座に保持することができる。さらに、為替等、特定の即時取引の場合、システムは割増手数料を課すことができる。
【０２８７】
具体的には、共同複合型取引において上述したように、ユーザーが例えば、パッシブ要求である為替取引を開始する場合、プログラム（すなわち、ＭａＱｓプログラム・モジュール）は、ユーザーの資金を即座に口座から取り出し、資金をシステム内の保持口座に移動することができ、所有者が投資の承認を与えている場合でも、資金は、他の一時的に保持されている口座からの他の資金とともに、低リスクまたはゼロリスクの従来の金融機関等のマネー・マーケット口座または普通口座に投資することができる（資金は所有者に戻されなければならない、または開始した取引を終了途中で全部揃えて送らなければならないため）。
【０２８８】
プログラムは自動的に、市場データを引き抜き、どの種別の金融証券が必要なリスク・パラメータ内で利用可能かをチェックし、各選択についての資本の機会費用（すなわち、入退出、および資本要件のコスト）を求める。プログラムは次に、資本ベクトル・フローのレート、システムへの入退出およびレート、ならびにコード・マッチ・システムへの資本ベクトル・フロー(capital vector flow)のレートをチェックし、必要なシステム流動性レベル(system liquidity level)（すなわち、銀行多重化機能により引き出される資本のレート、およびコード・マッチ集約機能(the Codematch Aggregator function)により要求されるシステム所望レート(the system desired rate)）で最良のリターンを提供する「最適な(optimal)」資本使用オプションを求める。
【０２８９】
個々の規模では非常に少ない利益を生み出すが、例えば１年以上にわたって何百万回も多重されると、合計として相当額の収入が生み出されることになるゼロまたは略ゼロ・リスク・オプションのタイプの間では、翌日物金利収入(overnight interest income)のためにシステムにより保持される銀行口座に資金を集約されたり、格付けＡＡＡの安全なローン・ポートフォリオ(loan portfolios)を購入したり、負債を利用して米国債を購入してそれを売却して現金を得て利子収入のため現金を銀行口座に入れたり、負債を利用して米国債を購入してそれを売却して現金を得て現金を格付けＡＡＡの企業に貸し付けたり、負債を利用して米国債を購入してヘッジ・ファンドに一夜またはそれ以上貸し付けたりすること等が行なわれる。
【０２９０】
相手方とのマッチングの実行がスケジュールされている、または締め切り期日が期限に近づいていて、実行命令がすぐにこの流用資本を召集する場合に、プログラムはマッチングが行われるのを待って、それから資金を必要な場所に送金するが、ユーザーの元の口座ではなくシステム所有のソース口座(source account)を形成する。この投資指示を出すのに、個々の口座を使用してもよく、またはシステムを流れる資本の集約の割合を使用してもよい。ユーザーは、マネーが投資に使われていることを知っていても、または知らなくてもよい。
【０２９１】
システムは、ユーザー取引を完了するために資本を返すよう要求する場合、プログラムは、そこで前に流用した資金により行われた手配済みの投資を解くのではなく、新たに入ってきた資本をユーザー取引の履行に充てることに留意されたい。投資は、システムに戻ると、また取引を遂行する新しい資本として利用可能になる。
【０２９２】
投資により生まれた利益は、ユーザーが指示する場合にはプログラムによりユーザーへ返してもよく（すなわち、ユーザーは取引を後日実行するようにセットアップし、資金を即座に取り出して、取引が行われるまで金融市場口座に入れることを許可することができるとともに、利益はユーザーに返されるが、初期取引額は実行のために移転される）、またはユーザーが利益をおそらく集約して慈善目的に使用するよう指示することもできる。システムの利益もまた自動的に再投資され、システム更新のための資本購入または後日の慈善目的等に向けて資金を集約することができる。
【０２９３】
プログラムが全てを追跡し実行するため、投資を無期限に保持することができ、新しく入ってきた分散ソース資金が、プログラムによって前のソース購入の支払いに偏向され、この資金の偏向（シフト）は、１）大半の購入はクレジット・カードを使用してオンラインで行われる、また２）本システムは使用可能な資金を単方向口座に事前割り振りするように容易に要求することができることから、系統リスクを増大しない。
【０２９４】
分散ソース資金が慈善理由のために利益形成に使用されると、プログラムにより少額の税額控除(tax-credits)を各ソースに自動的に還付することができ、さらに、プログラムは各少額に見合った割り振り票(allocation votes)を認可することができる。割り振り票は、各参加者が、慈善資金をどのように使用すべきかについて民主主義的な発言の機会を持てるようにし、利用可能なオプションはプロの慈善専門家(philanthropic experts)により調整される。さらに本システムは、記録ログからの重み付き平均に基づいて、ユーザーがシステムに使用を許可した資本の恩恵として、慈善活動からユーザーに税額控除を還付することができる。
【０２９５】
このようにして、投資の場での他の金融サービスをユーザーに提供することができる。さらに、ユーザーは、投資機会の利用に自分の金を用いたくない場合、おそらく金融機関から金を借りて投資機会に参加することができる。
【０２９６】
資本注入(Capital Infusion)
本発明による一実施形態では、上に述べたように、ＭａＱｓプログラム・モジュールは定期的かつ自動的にシステムをチェックして、システムの適宜機能に容易に円滑化するのに利用可能な十分な流動性を確保する。システムがひどく非対称である（算術平均等、または１０パーセントを超える変動、例えば左側との変動に基づいて）場合、プログラムは、それ自体を、新しいビジネス・ソースに関心があり得るＪＰモルガン等の従来の銀行チャネルに開くことによって、自動的に新しい資本を使用する、または、システムの所有者がシステムの資本のいくらかを置きたい場合、システムの利益を用いる（すなわち、ビジネスの機会に投資する）ことができる。
【０２９７】
この資本注入はユーザーに対してトランスペアレント(transparent)であり、コードマッチング(codematching)は止まることなく続けられ、マッチングしない要求はいずれも、履行されるまで、単純にシステムを何度も通過するだけである。
【０２９８】
信用貸し操作(Credit Operation)
本発明による別の実施形態では、上述した操作で生まれた集約資金または利益の慈善的な動機の他に、システムは、システム全体をそれら自体に適するようにする、より高度な機能を包含する。
【０２９９】
例えば、プログラムは、銀行が現在提供するものと同様に、信用貸しサービス操作を提供することができ、信用貸しをシステム・ユーザー、グループ、小規模事業、さらには大規模企業へ拡張し、かつクレジット・カードおよび／またはＡＴＭカードを発行する（この場合、システムはユーザーの口座に結び付いているため、ユーザーがクレジット・カードまたはクレジット・ラインまたはローンを要求する場合に、そのユーザーについての信用格付けを容易に行なうことができる）、または、信用格付けは以下説明するように分散ベースで行なうことができる。この信用格付けは、イクイファックス(Equifax)等の第３者的な信用調査所に頼らずに、実際の支払いのＣＤＭＸプログラム・トレース機能と連動して行なうことができる。
【０３００】
ユーザーにシステム決定信用格付けを開始させるには、信用格付けの進化はＥｂａｙ（登録商標）の進化に従うことができ、そのため、ユーザー格付けを伝える際には、口座使用が主要要因となるであろう。しかし、ユーザー信用格付けのベースは、既存の信用スコア入力を採用して各ユーザーの非ゼロ初期格付け(non-zero initial rating)に帰着する或る数式を基にすることを含め、複数の他の方法を進めてもよい。初期信用スコア(the initial credit-score)の入力は、正式な信用事業者スコア(credit-bureau score)であっても、または、特定の数字範囲または特定の数字に帰着するように或るアルゴリズムを介してプログラムにより操作された、ユーザーのクレジット・カード使用について提出された記録に基づいて適合されたものであってもよく、これが初期信用格付け(the initial credit rating)になり、ユーザーはこの初期信用格付けを使用して共同環境(collaborative environment)への参加を開始することができる。
【０３０１】
貸付およびマイクロ貸付（Lending and Microlending）
本発明による別の実施形態では、システムは、そのシステムのユーザーが他のシステム・ユーザー（個人、法人にかかわらず）に対して、ならびにシステムがその目的のためにアクティブ化された口座を有する場合はシステム自体に対して、率決定、貸付／借入することができる、直接貸付システムを提供することができる。
【０３０２】
直接貸付システムでは、ユーザーは資金を、規定の利子率および支払いスケジュールで他の遠隔ユーザー（例えば、アフリカで使用することができる）に資金を提供することができ、借り手は特定の利子率および支払いスケジュールで金を借りることができる。プログラムが自動的に、スケジュールされた時に、借り手の口座に振り込み、貸し手の口座を引き落とし、さらには自動的に為替を実行して貸し手へのローン返済をするため、借り手／貸し手は互いを認識する必要はない。
【０３０３】
別の例はマイクロ貸付である。グラミン（Grameen）銀行プロジェクトによって構築されたマイクロ貸付モデルは、ピア・ツー・ピア・ネットワーク効果(peer-to-peer network-effect)を利用するが、それはオフラインで非常に小さく地域規模である。
【０３０４】
本明細書において説明した本発明の共同機能により、マイクロ貸付はグローバル−ローカル規模(global-local scale)で推進することができ、個人は各自の資本の流れを、自身が選択したこの星の任意の果てに対して容易かつ迅速に向けることができる。同じネットワーク効果のピア関係(network-effect peer-relationships)をサポートする本システムの共同目的モデルの場合（すなわち、自己選択を表明した複数の個人）、人道活動、救済活動、救急活動等への参加、遂行、ならびに資金の流れに前例のないスピードおよび流動性をもたらす潜在性が手の届く範囲にある。
【０３０５】
このように、グラミン経済は非常に小さな額をオフラインで処理するが（資金が寄贈者からオンラインで集められる場合でも、寄付金の分配はオフラインで行われ、支配している組織により分配される）、本明細書に記載のシステムは、非常に小さな額であるか、それとも巨大な額であるかに関わらず、任意の額のレベルでの共同取引および直接分配をサポートし、ユーザーが個人の関係、賞賛、および完全性に頼って、自身が提供する借り入れ機会または投資機会において参加者（すなわち、仲間(peer)）を得て、それから各貸し手／投資家と直接的に、またはグループとして対話できるようにする。
【０３０６】
本発明の借入および貸付に対する共同直接手法(the communal-direct approach)では、ＣＤＭＸプログラム・モジュールは全てを追跡し、成功した信用貸付取引に提携した全ての参加者に「成功ポイント」を与えて、励みにすることができる。これらポイントの累積は、プログラムによりユーザー・インタフェースに表示され、結果として分散型信用格付けシステムになり、またはより広くは、分散型完全性格付けになり、それによって参加者ネットワークは、それまでの記録に基づいて他人の信用価値についての査定を開始することができる。
【０３０７】
これは、ユーザー、企業等が金を貸す際に、より高い利子率を課し（すなわち、成功した取引に関わっていることでわかる質の高い貸し手または投資家は、各自の取引への参加が多くの場合、他の人の参加をさらに促し、最終的に取引が成功するという心理的要素を提供するため、割り増し料金を課すことができる）、またより低い借入金利を課す（信頼の置ける借り手は素晴らしい支払い記録を有し、格別の信用を受けるため、借入の率が低い）道を開くものである。さらに、コミュニティ（システム）内において誠実で信頼のおける参加者が受ける健全性プレミアムは、また、健全性格付けの低い人(lower integrity ratings)はアクセスすることができない投資等への有利な、または優遇的なアクセスまたはオファー能力を含むことができる。
【０３０８】
ユニバーサル・オンライン購入(Universal On-line Purchasing)
本発明による別の実施形態では、従来のオンライン購入を行なうことができ（すなわち、従来簡易型取引）、この場合ユーザーは、ユーザー口座（すなわち、これまで説明した取引のいずれかと同じようにセットアップされる銀行、株式の売却等）からの直接引き落としとして、システムローン（前に説明したように）として、あるいはシステム・クレジット・カードとして、システムを使用して支払うオプションを利用することができる。これらの取引は、リアルタイムで、またはプログラムされた時刻に実行することができるので、ユーザーは各自の購入を柔軟に行なうことができる。
【０３０９】
しかし、いくつかの場合、例えば、通貨は、一方のユーザーが米国にいて、外国通貨で列挙されている別の国のアイテムを購入することを望むという問題となる。本発明を使用すれば、購入を行なう際、ユーザーはシステムを利用してアイテムの料金を支払うことができ、それによってシステムがアイテムの料金をターゲット通貨で支払い、対応する米国通貨をユーザーの口座を引き落とすことを許可する。
【０３１０】
具体的には、オンライン・ショッピング後、売り手のウェブサイトのチェックアウト画面において、ユーザーは支払いオプションとして「システムを使用して支払う」を選択することができる。システム画面が選択され、プログラムはユーザーにログインおよびパスワードを促す（オンライン購入専用の特別なパスワードも同様にセットアップすることができる）。ユーザーは、購入を取引ワークパッド画面で確認することができ、システム−売り手識別コード、および他の任意の識別コード（購入されたアイテムの識別コードまたは購入注文番号等）を使用して、上の共同複合型取引の場合でのように通貨を交換することができる。ＣＤＭＸおよびＭａＱｓプログラム・モジュールは、購入および取引の実行を追跡し、ターゲット通貨資金を売り手の口座に移転し、ユーザーの口座から資金を引き落とす。プログラムは、資金が提供され、取引が完了したことを売り手に通知し、また、口座から資金が引き落とされたことをユーザーに通知する。
【０３１１】
ＡＴＭシェアリング(ATM Sharing)
本発明による別の実施形態では、定量化アクセスと呼ばれる概念を用いて、非固有のＡＴＭカードが任意の銀行領域内における任意のＡＴＭ機を使用することができ、ＰｌｕｓまたはＣｉｒｒｕｓ、または他の同様のネットワーク（手数料が発生する）を利用しない。
【０３１２】
定量化アクセスは、資金を引き落とすＡＴＭカードに所有されない、関連しない、リンクしない、またはいずれにしても関連しない銀行口座にある資金を引き落とすために一時的なまたは定量額のアクセスを認可することを意味する。ＡＴＭカードに認可された許可は、任意の銀行または任意の銀行のＡＴＭがそのＡＴＭカードを固有のものとして認識するというようなものである。
【０３１３】
これはユーザー許可なしで進めることができると考えられる（すなわち、それぞれの口座を瞬時に使用して、速やかに引き落とされる資金を一時的に注入するため、口座は元の状態のままである）。しかし、規制問題により、システム・ユーザーが各自の口座をこの目的で使用する許可を示すことを要する場合がある。
【０３１４】
プロセスは以下の通りである。ユーザーは、各自のＡＴＭカードを手数料なしで使用することができる領域に固有ではないＡＴＭ機に行く。これは同様にいずれの通貨領域でもよく−これはシステムが必要に応じて交換取引を実行することができるため問題ではない−、このプロセスについてはさらに詳細に説明する。
【０３１５】
ユーザーはカードを挿入し、ＡＭＴコンピュータにより有効なカードとして確認される。ここで、コンピュータは、所与のＡＴＭカードが世界中の現実の銀行にある有効な銀行口座に結び付いているかをチェックして確認する。
【０３１６】
確認されると、ユーザーは通常、固有の銀行ユーザーの手数料なし取引ではない場合、取引に＄１．５０または或る同様の額が課されることを示す画面で注意される。
【０３１７】
Ｉｎｔｕｉｔ社のＱｕｉｃｋｅｎ（登録商標）や最終消費者(end-consumers)向けの他の会計ソフトウェアのようなソフトウェア・プログラムは、すでにネットワークを介して銀行口座データをダウンロードすることが可能であるため、この口座監視をリアルタイムで進めることができると考えられる。したがって、ユーザーは、登録した口座に対する活動を追跡するようにシステムを設定することができる。ユーザーがこのようにして各自の口座を応答するように設定した場合、ユーザーがＡＴＭ画面上でＡＴＭの使用に対する潜在的な手数料請求を承認するとすぐに、システムプログラムは、ＡＴＭ引き落としに関して保留中の銀行引き落としについて通知され、取引を受け継ぎ、銀行には進めさせない。
【０３１８】
まず、ＡＴＭでのユーザー・セッションをキャンセルすることなく、プログラムは銀行での進行を中止し、ユーザーの銀行での引き落としを許可せず、ＡＴＭからの現金受渡しも許可しない。
【０３１９】
次にプログラムは、銀行マルチプレクサ・プログラム・モジュールを使用して、資金をユーザーの口座から、現在の取引に使用されているＡＴＭ領域内の任意の口座Ｘに移し、これは、このような領域内のこのような口座Ｘの任意の所有者が、ユーザーが引き落とす定量化アクセスに資金を貸し付ける気がある場合に起こり得ることと同様である。ＣＤＭＸプログラム・モジュールはそれに従って追跡ログを更新する。同時に、ＡＴＭを所有する銀行には、プログラムにより、ＡＴＭで読み込まれた非固有のＡＴＭカードが口座Ｘに固有レベル定量化アクセスしたことを示す情報が送られる。
【０３２０】
資金は即座に口座Ｘから分配され、残高を元の状態にし（ログが同額の瞬間の振り込みおよび引き落としを示す）、銀行は固有のＡＴＭカードの引き落としとして認識するため、手数料は課されない。
【０３２１】
したがって、定量化アクセスは、銀行がＡＴＭを固有の口座と認識するように、プログラムにより特定の規定の制限された額の資金を、ユーザーが通常はアクセスすることができない口座から差し引く許可を提供すること意味する。言い換えれば、ＡＴＭカードは一時的に、また定量額だけ、口座ＸにリンクされたＡＴＭカードとして認識されている。
【０３２２】
ここで、ＡＴＭで引き出された現金は、本当に物理的にユーザーの口座からとられたものではなく、単に電子的に差し引かれたものであるため、システムに実際に資金を任意のＸ口座に移動させなくてもよく、銀行における任意の一般的な口座が作業すべきであり、これは、システムがありとあらゆる銀行領域に銀行口座を開いて保持する場合、単に自身の銀行口座を使用して、定量化アクセスをそのように認可して、本質的に全てのシステム・ユーザーに共有口座を提供し、これにより世界中どこでもありとあらゆる領域でのＡＴＭ手数料を迂回することができることを意味する。
【０３２３】
分散型資本移転(Distributed Funds Transfer)
本発明による別の実施形態では、本システムは、あらゆる従来の資金移転を、少額の多数の異なる方向に分散され、推移的解決を介してシフトされ、宛先でより少額の移転として集められて元の額の合計に収束する分散型資金移転にすることができる。ＳＶＲプログラム・モジュールは、分散パターンが検出不可能なようにこれを行なうことができ、これは、移転の外部観察者が分散方法を見抜くことがまったくないであろうため、特定のセキュリティまたは安全性がシステムに内在することを暗に示す。
【０３２４】
まず、定義を与えるとすると、資金移転または電子資金移転(electronic funds transfer)（ＥＦＴ）は、ポイントＡからポイントＢへ、ネットワークを介しての資金の国際間対象移動である。
【０３２５】
分散型資金移転（ＤＦＴ）は、既存の資金移転ネットワークを使用する方法であり、その趣旨は、資金フロー世界(fund-flow universe)のマクロゼロ和認識(a macro zero-sum awareness)により、送り手および受け手それぞれでの総計が、資金が送り手から受け手に直接移動することなく、元の意図された移転の方向に従って遂行されるように、２つの被選択ポイント（すなわち、送り手および受け手）に向かって、またそこから離れる、資金フローのベクトルを偏極させることができるというものである。
【０３２６】
通信伝達は、グローバル相互接続ネットワーク手法(global interconnected networks approach)を介して瞬間的に急がせるので、認識伝搬により、付近のクライアント、サーバ、およびサーベントに、行われていることについて、また遠隔クライアント、サーバ、およびサーベント(servent)に何か見えているかについての情報を提供することが可能である。これら速度で動作するネットワークでは、「近く(near)」は「グローバル(global)」を包含し得ることに留意されたい。本発明は既存のインフラ（既存の規制を受ける）を使用して資金移転を実行するため、資金移転を外部から予測し追跡することは非常に難しい。
【０３２７】
これは、（物理的または地理的に）遠隔のエンティティＲが、自分の近くの或るポイントＡから物理的な地理的世界にある自分から離れた或るポイントＢに資金を移動するという要望および意図に関する特定の情報をネットワークに知らせた瞬間に、或るエンティティＳが、自分の近くの或るポイントＦから物理的な地理的世界にある自分から離れた或るポイントＧに資金を移動するという要望および意図を考慮している場合があることを意味する。今日の世界では、資金移転は、資金移転ネットワークを介して実行されている他のいずれの移転からも完全に孤立した状態で、それぞれ独立して遂行される。「総計(netting)」の場合のみ（固定時間期間にわたる同当事者に対するインおよびアウトの移転を合計して、期間終了時に送ることができる「総計(net)」額に到達することにより、２つの当事者間の総資本移動を減じる、計算的手法である）、他の移転に関連して複数の移転が考慮される。
【０３２８】
本発明のシステムを使用すれば、システム・ネットワーク中の各参加者にリスク定義ガイドラインが与えられる場合、プログラムは、認識伝搬を介して近から遠(near-to-far)、および遠から近(far-to-near)の資金移転通知に目を配り、参加している全てのクライアント、サーバ、およびサーベントに、事前設定されたアルゴリズムを使用して、例えば、全ての資金移動の合計された総距離が最小化されるような資金の方向転換を実現することができる。これは例えば、資金をＡ→Ｂに長距離移動するのではなく、またＦ→Ｇに長距離移動するのではなく、２つのより小さな移転Ｆ→ＢおよびＡ→Ｇは、時間あたりでリスクに曝される資本の総量を低減することによってシステム全体のリスクを低減し、全ての当事者の責任を遂行することを意味する。
【０３２９】
Ａ→Ｂ、Ｆ→Ｇが相手方を交換して総資本移動を低減する本例では、これは、２つの意図する移転が等しい場合にのみ実現可能である。この等価(parity)（系統的）条件は、臨界質量に対するしきい値として存在し、これは何故このようなシステムが今日存在していないのかを説明する。本発明は、世界中の全てのベクトル、より重要なことには世界中の連続ベクトルを考慮することによって、この等価条件を解決する。資金移転ネットワークは、ボリュームの絶え間ない上昇に直面しているため、連続ベクトルが来ると想定することはかなり信頼できる。本発明は、理論的には絶え間ないと想定されるベクトルフィールドまたはフローの一部であるベクトルとして取引を取り扱う代替可能な取引を管理する独自のシステムである。
【０３３０】
具体的には、以下述べるように、プログラムはまず、或る資金移転ネットワークを介して、資金を送るユーザーコマンドを受け取る。次に、システムのクライアント／サーバ／サーベントのプログラムは、認識伝搬を介して、自身の機関または付近の機関を対象とする、意図される資金移転を見つける。本システムのクライアント／サーバ／サーベントは、その遠隔クライアント／サーバ／サーベントへの直接通信経路を識別し、通信を開く。２つのクライアント／サーバ／サーベントは、それぞれ意図する移転ベクトルについての情報を交換し、各ターゲットでの意図される総計ベクトル位置をローカルに記録する（ベクトルは二次元エンティティであり、この場合、額情報および方向情報を含むことを想起する）。（注記：これはここでは、金融記録の全滅および破壊が略不可能な程度まで、大体は匿名で、または少なくとも暗号化された形で、銀行業務情報を完全に冗長性を持って分配することができ、自然災害、または全ての人々を平等にするという名義の下で資本の排除を狙うテロは近代社会に対して極めて実現性の薄い脅威になるだろう）。
【０３３１】
２つのクライアント／サーバ／サーベントは、所与の規定された時間期間に含められる任意の意図されたベクトルに対して再帰的に最適な移転方向を計算する。「再帰的(recursively)」とは、意図する移転ベクトルの変化するネットワーク母集団との絶え間ない対話だと仮定する（すなわち、認識伝搬により、参加しているあらゆるクライアント／サーバ／サーベントに、新しい意図される移転ベクトルについての情報が与えられ続ける）が、これはもう分散型移転最適化プロセスの中に含まれ得ることに留意されたい。「最適(Optimal)」は、期間認識ベクトル世界(the period-awareness vector-universe)の背景および程度の中で計算された最も効率的なベクトル（１つまたは複数）として定義される。
【０３３２】
したがって、分散（または分配）資金移転期間(a Period Distributed(or Dispersed) Funds Transfer)では、プログラムは、特定の口座Ａから特定の意図されたターゲット口座Ｂへの資金の送出を、ＡからＢに資金を直接移転することなく実現することができるため、ＤＦＴは、それぞれの移転ラインがハッカー、テロリスト、自然災害等により危険に曝される可能性を心配する略全ての高価値移転エージェントにとって驚くべきツールになる。
【０３３３】
周期が完了すると、最適化された分散移転がプログラムにより実行される。いくつかの総計ベクトル条件は履行されないままか、または一部しか履行されないまま残り、後続の周期は、これら未履行および一部履行ベクトル条件の認識を含む。プログラムの各種事前設定ルールは、前の不完全な総計ベクトル条件を先に履行することを確保するため、連続して押し寄せる未完了および未履行の取引が完了される。
【０３３４】
したがって、本システムは、ＴＣＰ／ＩＰがインターネットを介しての通信にもたらすのと同じように、絶え間のない送出達成までのリルートが成し遂げられる信頼性を代替可能な証券移転にもたらす。
【０３３５】
セキュリティおよびプライバシーの問題(Security and Privacy Issues)
取引ベクトルは、システムにある間は暗号化され、完全なプライバシーを全てのシステム・ユーザーに提供する。しかし、ベクトルの額、方向、および識別は、法的権限による命令で別個に解読される場合がある。本発明のプログラムは、潜在的なロンダリングタイプまたは脱税タイプの活動を理解してシステム管理者に警告するフィルタを提供することができる。
【０３３６】
本発明の上述した実施形態は、本発明の原理を明確に理解するために記された実施態様の単なる可能例にすぎないことが強調されるべきである。本発明の精神および原理から逸脱することなく、変形および変更を本発明の上述した実施形態に対して行なうことができる。このような変更および変形は全て、本明細書では本発明の範囲内に包含されるべきであり、以下の特許請求項により保護されるべきであるもと意図される。
【図１】
0005505897.tif 000006
【図２】
0005505897.tif 000007
【図３】
0005505897.tif 000008
【図４】
0005505897.tif 000009
【図５】
0005505897.tif 000010
【図６】
0005505897.tif 000011
【図７Ａ】
0005505897.tif 000012
【図７Ｂ】
0005505897.tif 000013
【図８Ａ】
0005505897.tif 000014
【図８Ｂ】
0005505897.tif 000015
【図９】
0005505897.tif 000016
【図１０】
0005505897.tif 000017
【図１１Ａ】
0005505897.tif 000018
【図１１Ｂ】
0005505897.tif 000019
【図１２】
0005505897.tif 000020
【図１３】
0005505897.tif 000021
【図１４】
0005505897.tif 000022
【図１５】
0005505897.tif 000023
【図１６】
0005505897.tif 000024
【図１７】
0005505897.tif 000025
【図１８】
0005505897.tif 000026
【図１９】
0005505897.tif 000027
【図２０】
0005505897.tif 000028
【図２１Ａ】
0005505897.tif 000029
【図２１Ｂ】
0005505897.tif 000030
【図２１Ｃ】
0005505897.tif 000031