JP2002510409A

JP2002510409A - 外国為替取引システム

Info

Publication number: JP2002510409A
Application number: JP51992897A
Authority: JP
Inventors: ショーラムエスローゼン
Original assignee: Citibank NA
Current assignee: Citibank NA
Priority date: 1995-11-21
Filing date: 1996-11-21
Publication date: 2002-04-02
Also published as: CA2236046C; AU703984B2; WO1997019427A2; MX9803886A; US5774553A; AU1122497A; EP0865642A2; CA2236046A1; US5978485A; WO1997019427A3

Abstract

(57)【要約】コンピュータで実行されるネッティングシステムと、第１のマネーモジュールと第１のホストアプリケーションを有するプロセッサベースの多角的決済調整器（ＭＳＣ）とを備えるリアルタイムの外国為替決済システムであって、第１のホストアプリケーションが前記ネッティング市捨て値から借方及び貸方データを受ける。複数のプロセッサベースの多角的決済エージェント（ＭＳＡｓ）の各々が第２のマネーモジュールと第２のホストアプリケーションを有する。複数のプロセッサベースの当事者間決済エージェント（ＣＳＡｓ）の各々が第３のマネーモジュールと第３のホストアプリケーションを有する。第２及び第３のマネーモジュールは暗号的安全保障セッションを介して通信する。第１のマネーモジュールは第２のマネーモジュールを介してネット借方ＣＳＡｓの第３のマネーモジュールから電子マネーを受け取る。すべてのネット借方当事者が支払いを行ったとき第１のマネーモジュールが電子マネーをネット貸方ＣＳＡｓの第３のマネーモジュールに第２のマネーモジュールを介して送る。

Description

【発明の詳細な説明】外国為替取引システム発明の分野本発明は、多数の金銭単位の間でリアルタイムの交換を実行するための外国為替取引システムに関する。発明の背景本件特許出願人に譲渡された米国特許第5,453,601号及び第5,557,518号と、19 95年４月21日出願の米国特許出願08/427,287号（1996年10月24日公開のＰＣＴ国際出願ＷＯ96/33476号に対応）は、参照として本明細書に組み込まれるものであるが、これらには、慣用的な現金と互換性があり広範囲に受け入れられている電子マネーを使用する電子マネーシステム（ＥＭＳ）が説明されている。ここに説明されたＥＭＳは、通貨及びクレジットを含む経済的価値を、加入者間、金融機関間、及び加入者と金融機関との間で確実に信頼性をもって移転するための方法及びシステムを提供する。該ＥＭＳは又、多数の通貨の形態で電子マネーを提供する。外国為替は、1974年の１日あたり10億ドルから1994年の１日あたり１兆ドルにまで成長した。１日あたり何千億ドルもがこれらの取引を決済するのに国際支払いシステムを通過する。関係者による失敗の危険が主要経済の中央銀行の気掛かりな点である。これらの気掛かり及び潜在的な解決策が、国際決済銀行によるレポート「国境を越えた複数通貨取引に関する中央銀行支払い及び決済サービス」に述べられている。このレポートは、私的セクターからの２つの反応を引き起こした。すなわち、ニューヨーク外国為替委員会による「外国為替決済のリスクの減少」と、ニューヨーク決済ハウス協会による「高額支払いシステムにおけるリスク減少と効率の増大：私的セクターの反応」である。この問題は、1974年にドイツのヘルシュタット銀行が期限の終日に支払い不能を宣告されたときに顕在化した。条約では、外国為替取引は取引日から２業務日内に決済することになっている。これは、決済日と呼ばれている。例えば、ドルとドイツマルクの決済のためには、当事者間でドルの額とドイツマルクの額の移転を行わねばならない。これらの移転は、例えばフェデラルリザーブバンクとドイツ連邦銀行のような関与する中央銀行において最終的に行われる。ドイツは、ニューヨーク時間に比べて７時間進んでいるので、ドイツ連邦銀行はフェデラルリザーブバンクより早く閉店する。したがって、マルクの移転は、ドルが移転される前に終了することがある。ヘルシュテット銀行に対する当事者が、ドイツにおける支払い日の終わりまでにマルクを支払い、ドルを受け取らなかった場合、マルクは損失になることがある。このリスクは、外国為替リスク又はヘルシュタットリスクと呼ばれる。外国のレポートはすべて、銀行営業時間の延長、中央銀行会計システム間の調整及び複数通貨決済銀行の設立を含む解決策を示唆する。提案された解決策の各々は、リスクを減少させるが、なくすものではない。本発明は、ここで「外国為替決済」と呼ぶ強化された取引をもったＥＭＳを導入して、中央銀行システムの外で複数通貨支払いの調整によるリスクをなくすことを提案するものである。発明の要約したがって、本発明の一目的は、離れて位置する当事者がネットワークを通じて交信することにより、複数通貨単位の電子マネーをリアルタイムで交換することができるようになるシステムを提供することである。本発明の他の目的は、当事者間決済エージェントを使用する、全体又は２極間でのリアルタイムの外国為替決済システムを提供することである。本発明の他の目的は、多極間決済調整機関、多極間決済エージェント及び当事者間決済エージェントを使用する、リアルタイムな多極間外国為替システムを提供することである。本発明の一態様においては、第１のマネーモジュールと第２のマネーモジュールの間で暗号的セキュリティセッションが確立される。第１の加入者が、異なる通貨単位による複数の額を含む第１の交換データを第１のマネーモジュールに送り、該第１のマネーモジュールがこのデータを暗号的セキュリティセッションを経由して第２のマネーモジュールに送る。第２のマネーモジュールは、第２の加入者に対して、この第１のデータを検証することを促し、該第２の加入者は、異なる通貨単位による複数の額を含む第２の交換データを第２のマネーモジュールに送る。第２のマネーモジュールは、暗号的セキュリティセッションを経由して、この第２の交換データを第１のマネーモジュールに送り、第１のマネーモジュールは、第１の加入者に対して、この第２の交換データを検証することを促す。第１のマネーモジュールは、第１の移転によって、通貨単位識別子を備え第１の交換データにより特定された額及び通貨単位による第１のマネーの電子的象徴を、暗号的セキュリティセッションを経由して第２のマネーモジュールに送る。第２のマネーモジュールは、第２の移転によって、通貨単位識別子を備え第２の交換データにより特定された額及び通貨単位による第２のマネーの電子的象徴を、暗号的セキュリティセッションを経由して第１のマネーモジュールに送る。第１及び第２のマネーモジュールの各々は、取引ログを無条件で更新して第１の移転と第２の移転を別々に終了させる。本発明の第２の態様においては、全体又は２極間ネッティングプロセスが、第１及び第２の交換データを、第１及び第２のホストアプリケーションである第１及び第２の加入者に送る。本発明の第３の態様においては、多極間決済調整機関（ＭＳＣ）がネッティングシステムからネット当事者の借方及び貸方データを受け取り、ネット当事者借方データを多極間決済エージェント（ＭＳＡｓ）に送る。ＭＳＡｓは、ネット当事者の借方データをネット借方当事者決済エージェント（ＣＳＡｓ）に送る。ネット借方ＣＳＡｓは、第２及び第３のマネーモジュール間で確立された第１の暗号的セキュリティセッションを介して、ネット当事者借方データに応じて、電子マネーをＭＳＡｓに移転する。ＭＳＡｓの第２のマネーモジュールが、ＭＳＣの第１のマネーモジュールに電子マネーを移転する。すべてのネットＣＳＡｓが支払いを行ったとき、ＭＳＣがネット貸方当事者のためのＭＳＡｓの第２のマネーモジュールに電子マネーを移転する。ＭＳＡｓは、第２及び第３のマネーモジュール間で確立された第２の暗号的セキュリティセッションを介して、ネット当事者貸方データに応じてネット貸方当事者ＣＳＡｓに電子マネーを移転する。図面の簡単な説明本発明の他の態様、特徴及び利点は、添付図面とともに以下の説明に基づいて本発明を考察するとき理解でき、かつ、より明瞭になるであろう。図において、図１Ａは、ＥＭＳセキュリティ階層を示す図表である。図１Ｂは、主セキュリティサーバーと通常セキュリティサーバーとの間のメッセージ通信を行うセキュリティネットワークを示す図表である。図２は、ＥＭＳのセキュリティネットワーク構造を示す図表である。図３Ａは、セキュリティサーバーの機能部分を示すものである。図３Ｂは、ネットワークサーバーの機能部分を示すものである。図４Ａは、顧客サービスモジュールの機能部分を示すものである。図４Ｂは、主セキュリティサーバーの機能部分を示すものである。図５は、ネットワークサインオンの手順の概略である。図６Ａ−Ｋは、ネットワークサインオンプロトコールを示すものである。図７Ａ−Ｅは、ＥＭＳ内の確立セッションプロトコールを示すものである。図８Ａ−Ｂは、移転ノートプロトコールを示すものである。図９Ａ−Ｄは、外国為替プロトコールを示すものである。図１０は、ＥＭＳ内のモジュールのためのコミットプロトコールを示すものである。図１１Ａ−Ｂは、ＥＭＳ内のモジュールのためのアボート取引プロトコールを示すものである。図１２Ａ−Ｃは、ポイントオブセール（ＰＯＳ）支払いプロトコールを示すものである。図１３Ａ−Ｂは、更新クレジットフォーム発行銀行プロトコールを示すものである。図１４は、セットアップクレジットプロトコールを示すものである。図１５Ａ−Ｂは、要求クレジットプロトコールを示すものである。図１６は、ノート移転履歴の例を示すものである。図１７は、ノート移転ツリーを示すものである。図１８Ａ−Ｃは、銀行アクセスプロトコールのための銀行口座に対するリンクマネーモジュールを示すものである。図１９Ａ−Ｃは、銀行口座プロトコールに対する再有効化マネーモジュールリンクを示すものである。図２０は、有効口座番号プロトコールを示すものである。図２１Ａ−Ｂは、紛失ノート発生プロトコールを示すものである。図２２Ａ−Ｅは、紛失ノートクレームプロトコールを示すものである。図２３は、外国為替プロセスを示すものである。図２４は、決済エージェントを示すものである。図２５は、全体／２極間外国為替決済の形態を示すものである。図２６は、多極間外国為替決済の形態を示すものである。図２７Ａ−Ｅは、外国為替決済プロトコールを示すものである。図２８は、全体／２極間外国為替決済プロトコールを示すものである。図２９Ａ−Ｄは、多極間外国為替決済プロトコールを示すものである。発明の詳細な説明本発明においては、本件出願人に譲渡された1995年４月21日出願の米国特許出願08/427,287号に開示された外国為替能力をさらに拡張するものであり、この特許出願は、ここに参照として組み入れられる。当該出願は、それ自体、米国特許第5,453,601号に最初に開示されたＥＭＳを発展させることを説明している。以下は、この拡張のリストである。１）図５について後で説明するように、誰もマネーモジュールを騙したり或いは決済における情報のいずれかを妨げたりすることができないように、ネットワークのサインオンを安全保障する。２）セキュリティサーバー、マネー発生器及び出納識別子を割り当てるための方法を生成する（モジュール番号付けスキームを参照）。これらの識別子は、 (a)セッションの確立（図７参照） (b)移転ノート−−チェック移転レコード（図８参照）に記録される。３）主セキュリティサーバーを含む２階層セキュリティサーバー構造（セキュリティ階層及びセキュリティネットワークを参照）を確立し、すべてのモジュールが該主セキュリティサーバーと他のすべてのモジュールを認証するセキュリティサーバーの公開キーを持つようにする。４）支払い又は外国為替（Ｆ／Ｘ）においてノートを受け入れる前にすべての移転に対して不良ＩＤをチェックし、重複ノートをチェックするために、移転ノートを改良する。５）セキュリティサーバーのプライベートキーを使用してすべての証明を暗号化する（証明構造と有効化を参照）６）公開キーのサイズをダイナミックに変更する（セキュリティネットワーク及び図６を参照）。７）失敗によってマネーが複製されないようにコミットプロトコールを変更する（図１０参照）。８）どの当事者も、マネーを受け取りながらマネーを送らないようなことよって、コミットを妨げ、確実性をもって欺瞞を行うことができないように、Ｆ／Ｘを変更する（図９参照）。９）支払い側がコミットし、受け取り側がアボートする場合に、失敗したコミットについてのログ情報に対するアボートを変更する（図１１参照）。１０）必要な場合に全体的な再証明を可能にする（セキュリティネットワーク及び図６を参照）。以下が、上記したリストの拡張の詳細な説明である。セキュリティ階層ＥＭＳシステムセキュリティの好ましい実施例は、次のようにして与えることができる。図１Ａを参照すると、ＥＭＳは、主セキュリティサーバー１１８２と通常セキュリティサーバー１１８４の２つの型式のセキュリティサーバーを持っている。主セキュリティサーバー１１８２は、（通常）セキュリティサーバー１１８４を認証する。セキュリティサーバー１１８４は、システム内の他のモジュール（取引ＭＭｓ１１８６、出納ＭＭｓ１１８８、マネー発生モジュール１１９０、及び顧客サービスモジュール１１９２）のすべてを認証する。主サーバー１１８２は、他の主サーバー１１８２又は他のセキュリティサーバー１１８４とのみ相互作用する。図２を参照すると、主セキュリティサーバー１１８２は、セキュリティＬＡＮ１１９４によって互いに接続された安全保障機関内に納められている。ＬＡＮ１１９４は、安全保障ゲートウェイを通じてセキュリティネットワーク１１９６に接続されている。セキュリティサーバーだけが此のネットワーク上で通信する。すべてのセキュリティサーバーは、物理的に保護された装置である。セキュリティサーバー１１８４は又、ＥＭＳネットワーク１１９８及び銀行ローカルネットワーク１２００に取り付けられている。セキュリティサーバーは、コンプロマイズされる可能性があり、他のモジュールとの相互作用により有効化されるものとして取り扱われる。セキュリティサーバー１１８４とモジュールのみが証明を持つ。これらの装置は、主セキュリティサーバーの公開キーを持っている。これらは、２つの型式の証明、すなわちセキュリティサーバー及びモジュールである。証明構造及び有効化証明の構造は、次の通りである。証明有効化プロトコールは、ここに、ＰＳＳ＝主セキュリティサーバーＳＳ＝セキュリティサーバー、Ｍ＝モジュール ‖＝連結 id＝識別番号ｈ＝ハッシュ関数Ｃ＝すべてのモジュールが使用するコンスタントランダム数ＰＫ＝公開キー（キーの長さを含む） σ＝ディジタル署名＝Ｅ・ｈ Cert＝証明Ｅ＝暗号化及びディジタル署名の生成のために使用するプライベートキーを有するアルゴリズムＤ＝暗号解読及びディジタル署名のチェックに使用されるプライベートキーを有するアルゴリズム注：Ｅ及びＤは又、他の用途への適用の場合には暗号解読及び暗号化にそれぞれ使用できるモジュール番号付けスキーム主セキュリティサーバー１１８２、セキュリティサーバー１１８４、出納マネーモジュール１１８８、マネー発生モジュール１１９０、顧客サービスモジュール１１９２及び取引マネーモジュール１１８６は、識別番号（id's）を割り当てられ、真正の確認にこの番号をチェックできる。４８ビットのプライム数「Ｐ」が生成され、プリミティブルート「ａ」モジュールｐ（すべての≦ｎ≦ｐ−１に対してａⁿ≠１(p)である）が安全保障プロセスにおいて見いだされる。ａとｐの両方が、主セキュリティサーバーを製造するときにシステム内のすべてのモジュールに対してロードされる。このスキームは、次のように働く。ａⁿ≡ｍ(p)であり、かつ、 (1) １≦ｍ≦99,999であれば、主セキュリティサーバーのidとしてｎが割り当てられる。 (2) 100,000≦ｍ≦999,999であれば、セキュリティサーバーのidとしてｎが割り当てられる。 (3) 1,000,000≦ｍ≦6,999,999であれば、出納マネーモジュールのidとしてｎが割り当てられる。 (4) 7,000,000≦ｍ≦9,999,999であれば、マネー発生モジュールのidとしてｎが割り当てられる。 (5) 10,000,000≦ｍ≦11,999,999であれば、顧客サービスモジュールのidとしてｎが割り当てられる。 (6) ｍ≧12,000,000であれば、取引マネーモジュールのidとしてｎが割り当てられる。モジュール又はサーバーが証明を有効化している場合には、このモジュール又はサーバーは、識別番号（例えば、Ｍ(id)、ＳＳ(id)、又はＰＳＳ(id)）ｎが真正であるかどうかを、ａⁿ≡ｍ(p)の計算によりチェックし、ｍが正しい範囲にあるかどうかをチェックする。セキュリティネットワーク図２に示すように、セキュリティネットワーク１１９６及びセキュリティＬＡＮ１１９４は、セキュリティサーバー１１８４を主セキュリティサーバー１１８２に接続する。セキュリティサーバー１１８４は、最初に、製造時にマネーモジュール及び顧客サービスモジュール１１９２を認証する。このセキュリティサーバーは、モジュール製造ＬＡＮによって接続してもよい。これらは、不良idリスト及び主セキュリティサーバーとその公開キーのようなセキュリティ情報をモジュールに通す。不良idリストは、取引から遮断されたマネーモジュール、顧客サービスモジュール及びセキュリティサーバーの識別子を含む。これらモジュールの再証明は、後で、ネットワークサインオン図表に記述される。セキュリティサーバー１１８４は、最初に、製造時に、主セキュリティサーバー１１８２によって証明される。この主セキュリティサーバーは、セキュリティサーバー製造ＬＡＮ１２０４に接続することができる。図１Ｂを参照すると、セキュリティサーバー１１８４は、種々のセキュリティ情報を受け取り、これを他のモジュールに通す。セキュリティサーバーは、ＥＭＳネットワーク１１９８及び銀行ＬＡＮｓ１２００のためのセキュリティサービス、例えば更新セキュリティ情報のようなネットワークサインオンを提供する。セキュリティサーバー１１８４は、セキュリティネットワーク１１９６上で主セキュリティサーバー１１８２からこの情報を受け取る。取引マネーモジュール１１８６は、ネットワークサーバー１２０６（ＮＳ）を介してＥＭＳネットワーク１１９８と通信する。関与銀行は出納モジュール１１８８を備え、マネー発生器１１９０を備えることもあり、これらはそれぞれのＬＡＮ１２００に接続される。セキュリティネットワーク１１９６はリンク暗号化される。加えて、主セキュリティサーバーとセキュリティサーバーは、共通対称キー（セキュリティネットワーク暗号化キー）を共有している。このキーは、公開キー、キー変更により指定された主サーバー１１８２により定期的に変更される。不良idのリストは指定された主サーバー１１８２により維持される。このリストは、関与する銀行や法律執行機関及びシステムの加入者との相互作用により累積される。セキュリティサーバー及びモジュールの公開キーの長さは、定期的に変更される。高いセキュリティレベルを維持するためには、キーの長さは通常は長くされる。新しい指定されたキー長は、指定された主サーバーにより主セキュリティサーバーに通信される。新しい不良リストが送られるか又は再証明のときに、この新しい長さは、主サーバーからセキュリティサーバーに通信される。セキュリティに危険な破壊があったときは、主セキュリティサーバーは全体の再証明を要求することができる。各主サーバーの公開キーの長さは変更しない。主セキュリティサーバーの実行及び改易を計画するタイムテーブルが生成される。取引量が増加したことを理由に実行される場合でなければ、新しいサーバーは長いキーを持つことが最も多くなる。活きたＰＳＳ公開キーが主セキュリティサーバーにより生成され、該サーバーのプライベートキーを用いて該サーバーにより署名される。次いで、このリストは他のセキュリティサーバーに知らされる。図３Ａは、セキュリティサーバー１１８４の機能部分を示す。外部インターフェース機能１２０８は、ネットワークインターフェースのための通信層を形成する。セッションマネージャー機能１２１０は、取引セッションのセキュリティ態様を制御する。ネットワークサインオン機能１２１２は、ネットワークサインオンのための制御機能を司る。証明生成機能１２１４は、マネーモジュール（主セキュリティサーバー内のもの、この機能はセキュリティサーバーを証明する）の証明を認証する。証明キー分配機能１２１８は、有効な主セキュリティサーバー公開キーの証明エージェンシーリストをマネーモジュールに分配する（主セキュリティサーバーは又、全体再証明メッセージを分配する）。不良idリスト管理機能１２２０は、不良識別子のリストを管理し分配する。日付／時間同期機能１２２２は、マネーモジュールのクロック／タイマーサービスがシステム時間に同期するようにする。クロック／タイマー１２２４及び暗号機能１２２６は、マネーモジュールにおける機能と同じである。図３Ｂは、ネットワークサーバー１２０６の機能部分を示す。外部インターフェース機能１２２８は、ネットワークインターフェースの通信層を形成する。通信セッションマネージャー機能１２３０は、マネージャーモジュール間及びマネージャーモジュールとセキュリティサーバーの間の通信を司る。ネットワークサインオン機能１２３２は、マネージャーモジュールのネットワークサインオンプロセスを制御する。ルートメッセージ機能１２３４は、サインオンの間及びマネーモジュールセッションの間におけるメッセージのルートを制御する、メッセージルーティングのための指示サービスを提供する。銀行サービス指示機能１２３６は、関与銀行により提供されるサービスの情報を与える。暗号機能１２３８は対称キー機能１２４０とランダム数発生機能１２４２を提供する。対称キー機能１２４０は、ネットワークサーバー１２０６と該ネットワークにアクセスするモジュールとの間、及びネットワークサーバー１２０６とセキュリティサーバー１１８４との間のメッセージを暗号化する。ランダム数発生機能１２４２は、暗号化キー及び認証メッセージのためのランダム数を生成する。このＥＭＳにおいては、他の安全保障処理部品、顧客サービスモジュール（ＣＭＳ）を採用することか好ましい。ＣＳＭは、会計プロファイルを生成し更新するために使用される不正防止性装置である。ＣＳＭｓは、マネーモジュール及びセキュリティサーバーに見られるような独特の証明を有する。ＣＳＭｓは、他のモジュール（例えばセキュリティサーバー）と安全保障セッションを確立することができる。ＣＳＭは、ホストが顧客サービス代表及びオンライン銀行システムにインターフェースすることを要求する。ＣＳＭは、２つの主要な機能を有する。第一に、ＣＳＭは、マネーモジュールが銀行口座にアクセスできるようにする会計プロファイルを生成し、銀行口座へのマネーモジュールリンクを再有効化し、口座番号を有効化する。これらの処理は、図１８ないし２０を参照して後で詳細に説明する。第二に、ＣＳＭは、ホスト顧客サービス代表からの要求に応答して紛失ノートをクレームするように機能し、これは、図２１及び図２２を参照してさらに詳細に説明する。ＣＳＭは、マネーモジュールと同じセキュリティ機能とその識別子のための特別な範囲の番号を有する（「モジュール番号付けスキーム」参照）。ＣＳＭによるこれらの機能の行為は、出納モジュールのための口座番号有効化プロセスを簡単にする。ＣＳＭを採用するＥＭＳの実施例においては、各銀行の会計プロファイル構造は、に変化する。ここで、Ｍ（id）＝モジュール識別子Ｂ（id）＝銀行識別子ＬＡ＝口座番号及び口座のタイプ（預金かローンか）のリスト σ_csm＝ＣＳＭの署名 Cert（ＣＳＭ）＝ＣＳＭの証明 ‖＝連結このプロファイルを有効化する手順は、以下に図２０を参照して説明する。図４Ａは、顧客サービスモジュール（ＣＳＭ）１１９２の機能部分を示す。外部インターフェース３０００は、ＣＳＭを顧客サービスモジュールホスト（ＣＳＭＨ）プロセッサ内の他の処理及び通信手段にインターフェースし、セッションマネージャー３００１がＣＳＭと取引マネーモジュール又は顧客サービス代表との間の取引セッションを管理及びコミット（すなわち終了）させるか、又はアボートするように作用する。会計プロファイル生成機能３００２は、顧客口座情報から、マネーモジュールが加入者の異なる銀行口座にアクセスするのを可能にする会計プロファイルを構成する。公開キー機能は、銀行口座プロファイルを認証し署名する。ＣＳＭは、ホストが顧客サービス代表及びオンライン銀行システムにアクセスすることを要求するので、ホスト向け機能３００６は、ＣＳＭ適用とホスト適用との間の義務の分離を仲介する。紛失ノートクレーム機能３００８はＣＳＭが有効化し発行銀行に分配する加入者の紛失ノートクレームに応答する。主セキュリティ機能３００４は、コンプロマイズされたマネーモジュールのリストを管理し、証明に適用し、クロックを同期させ、新しいディジタルキーの生成を管理する。クロック／タイマー３０１２及び暗号機能３０１０は、マネーモジュールのそれらの機能と同じである。図４Ｂは、主セキュリティサーバー１１８２の機能部分を示す。外部インターフェース機能３０２０は、ネットワークインターフェースのための通信層を形成する。セッションマネーシャー機能３００２は、コンプロマイズされたかのように取り扱われるセキュリティサーバーと、他の主セキュリティサーバーとを伴うセッションのセキュリティ態様を制御する。証明生成機能３０２４は、セキュリティサーバーの証明を生成する。証明キー分配機能３０２６は、有効な主セキュリティサーバー公開キーの証明エージェンシーのリストをセキュリティサーバーに分配する。セキュリティネットワークキー分配機能３０３２は、主セキュリティサーバー間のセキュリティネットワークキーを管理し、セキュリティサーバーに分配する。全体再証明設定機能３０３０は、全体的な再証明が要求されるかどうか（例えば、セキュリティの危険な破壊があったため）を決定し、必要と認めるとき、全体サーバー証明を求める。不慮idリスト分配機能３０２８は、不良識別子のリストを管理し分配する。クロック／タイマー３０３４及び暗号機能３０３６は、マネージャーモジュールにおけるものと同じである。ネットワークサインオンネットワークサインオン手順を図５を参照して説明する。サインオンプロトコールは、モジュール１２４３が再証明や預金、引き出しその他の理由のためにＥＭＳネットワーク１１９８にアクセスすることが望まれる状況を述べる。モジュール１２４３は、例えば、取引マネーモジュール１１８６、出納マネーモジュール１１３８、マネー発生モジュール１１８８、又は、顧客サービスモジュール１１９２である。（a）モジュール１２４３とネットワークサーバー１２０６との間の通信を確立する。（b）モジュールの証明をネットワークサーバー１２０６に通す。（c）ネットワークサーバー１２０６がランダムな証明数ＶとランダムキーＫを生成し、ネットワークサーバーがモジュールの証明とＶとＫをセキュリティサーバー１１８４（ＮＳ／ＳＳキーにより暗号化されている）に通す。（d ）モジュール１２４３とセキュリティサーバー１１８４が安全な通信セッションを（セッションキー（ＭＭ／ＳＳ）を通じて）確立する。（e）セキュリティサーバー１１８４が、時刻／日付と、更新された不良idリストと、主セキュリティサーバー公開キーの更新されたリストと、公開キーの長さと、全体再証明（必要な場合に）と、再証明されたモジュール証明（必要な場合に）を通す。（f）モジュール１２４３とのセッションを終了し、ＶとＫをモジュール１２４３に送る。（g）ＫによりＶを暗号化し、ネットワークサーバー１２０６に送る。（h）ネットワークサーバー１２０６はネットワークサインオンの受け取りをモジュール１２４３に知らせる。（i）次いで、モジュール１２４３は、該モジュールが接続されることを望む宛先（もしあれば）をネットワークサーバー１２０６に知らせる。（j ）ネットワークサーバー１２０６は、宛先への接続を確立する。このネットワークサインオンは、誰もモジュール１２４３を騙したり決済における情報を妨げたりすることができないように設計されている。図６は、ネットワークサインオン手順の流れの詳細を示す。通信Ａが、ＥＭＳネットワーク１１９８との通信を確立する（ステップ１２４４）。セキュリティ維持Ａが、その証明をネットワークサーバー１２０６に送る（ステップ１２４６）。ＮＳネットワークサインオンが証明を受け取る（ステップ１２４８）。ＮＳ乱数発生器がランダムキーＫとランダム証明数Ｖを生成する（ステップ１２５０）。ＮＳ対称キーが、モジュール証明とＫとＶをＮＳ／ＳＳキーにより暗号化する（ステップ１２５２）。ＮＳ／ＳＳキーは局部的対称キーであり、ネットワークサインオンのために通信するネットワークサーバー１２０６とセキュリティサーバー１１８４に設けられている。ＮＳネットワークサインオンは、証明とＫとＶをセキュリティサーバー１１８４に送り、ここでＳＳネットワークサインオンがメッセージを受け取り、ＳＳ対称キーがこのメッセージを暗号化する（ステップ１２５４−１２５８）。ＳＳネットワークサインオンは、ＫとＶを記憶し、モジュール証明を有効化のためにＳＳ公開キーに送る（ステップ１２６０−１２６４）。再証明の可能性を持たせるために、ＳＳ公開キーは、モジュール証明の有効性を判断する際には満了日を考慮しない。モジュール証明が有効でないとき、ＳＳネットワークサインオンは、ネットワークサーバー１２０６とモジュール１２４３への移転のためのアクセスを拒否するメッセージを生成する。ＳＳ公開キーは、モジュール１２４３の公開キーによって該モジュールへのメッセージを暗号化し、ＳＳセッションマネージャーがこのメッセージをネットワークサーバーに送る（ステップ１２６８−１２７０）。ＮＳネットワークサインオンがこのメッセージを受け取り、アクセスが拒否されたことを認識する。暗号化されたメッセージは、次いでモジュールに送られ、ネットワークサーバーは接続を絶つ（ステップ１２７２）。セッションマネージャーＡがメッセージを受け取り、公開キーＡがこのメッセージを解読し、セッションマネージャーＡがサインオンの拒否を認識する（ステップ274−1278）。サインオンを要求している装置が取引マネーモジュールであれば、加入者Ａ向けが、加入者にこのことを伝える（ステップ１２８０−１２８２）。その他の場合には銀行Ａ向けが銀行に通報する（ステップ１２８４）。他方、モジュール証明が有効であれば、不良idリストＳＳ管理が、モジュールのidが不良リストにあるかどうかをチェックする(ステップ1286-1288)。idがリスト上にあれば、ネットワークへのアクセスが拒否される。その他の場合には、ＳＳ乱数発生器が乱数Ｒと証明メッセージを生成する（ステップ１２９０）。ＳＳネットワークサインオンは、Ｒと証明メッセージをメッセージに集め、これをＡの公開キーを使用してＳＳ公開キーにより暗号化する。公開キーＡは又、セキュリティサーバーの証明を添付することにより、この暗号化されたメッセージを補強する（ステップ１２９２−１２９４）。このメッセージはＡに送られ、ここで公開キーＡがメッセージを解読してセキュリティサーバーの証明を有効化する（ステップ１２９８）。証明が有効であれば、Ａがセッションの終了を認識し、加入者又は銀行に通報する（ステップ１３０４−１３０６）。証明が有効であれば、セキュリティ維持Ａが、セキュリティサーバーのidが不良リスト上にあるかどうかをチェックする（ステップ１３０８−１３１０）。もしリスト上にあれば、セッションは終了する（１３００−１３０６）。もしリスト上になければ、乱数発生器Ａが乱数Ｒ(A )を生成する（ステップ１３１２）。セッション維持Ａは、Ｒ（Ａ）ＸＯＲＲの演算によりセッションキー（ＭＭ／ＳＳ）を形成し、このセッションキーをストアする（ステップ１３１４）。証明メッセージとＲ（Ａ）を含むメッセージが形成されてセキュリティサーバーの公開キーにより暗号化される（ステップ１３１６）。セッションマネージャーＡが、このメッセージをＳＳネットワークサインオン向けに送り、ＳＳ公開キーがこのメッセージを解読する（ステップ１３１８−１３２２）。ＳＳネットワークサインオンは、この証明メッセージが生成されるべきものであることを認証する（ステップ１３２４−１３２６）。もし、生成されるべきものでなければ、セキュリティサーバーはネットワークアクセスを拒否する。もし証明メッセージが正しければ、ＳＳ対称キーが、Ｒ（Ａ）ＸＯＲＲによりセッションキー（ＭＭ／ＳＳ）を形成する。ＳＳセッションマネージャーは、セッションの開始を認識し、メッセージ送付サブルーチンにより、Ａに受け取りを送る（ステップ１３３０−１３３２）。セッションマネージャーＡは、この受け取りを受領し、セッションの開始を認識する（ステップ１３３４）。クロック／タイマーＡは、時刻と日付をセッションマネージャーに送り、該セッションマネージャーは、これをセキュリティサーバーに送る（ステップ１３３６−１３４０）。ＳＳ日付／時刻同期は、この時刻と日付を受け、これがパラメーター内であるかどうかをチェックする（ステップ１３４２−１３４４）。パラメーター内でなければ、ＳＳ日付／時刻同期は、新しい時刻と日付をセッションマネージャーＡに送る（ステップ１３４６−１３５０）。クロック／タイマーＡは、ここで、時刻と日付を調節する（ステップ１３５２）。次に、Ａは、その日付と時刻を再チェックのためにセキュリティサーバーに送る。クロックの同期の試みが設定された回数以上になされたときは、クロックの故障が加入者又は銀行に報告され、加入者又は銀行は、望む場合には再度試みる（ステップ１３５４− １３６２）。しかし、時刻と日付がパラメーター内であれば、ＳＳネットワークサインオンが、不良idリストと、主セキュリティサーバー公開キーの新しいリスト（これは証明キー分配機能からくる）と、公開キーの長さ（公開キーのサイズは周期的に変更される）とを含むメッセージを集成する（ステップ１３６４）。ＳＳ証明生成は、全体再証明が求められているかどうかをチェックし、全体再証明の期間が満了していないことを確認する（ステップ１３６６−１３６４）。この機能は、該モジュールが最後に再証明を受けた時をチェックしなければならない。その理由は、全体再証明の期間注に証明を受けていれば、再証明の必要はないからである。再証明が求められる場合には、ＳＳ証明生成が、先のメッセージに、モジュー再証明が求められる場合には、ＳＳ証明生成が、先のメッセージに、モジュールは再証明が必要であることを追加する（ステップ１３７０）。ここで、再証明が求められているかどうかに関係なく、ＳＳ公開キーはこのメッセージに署名する（ステップ１３７２）。そこで、メッセージはＡに送られ、ここで公開キーＡがメッセージ上のディジタル署名をチェックする(ステップ1374-1378)。署名が無効であれば、セッションは終了する。次いで、セキュリティ維持Ａがその不良 idリストと公開キーとキー長を更新する（ステップ１３８２）。次に、モジュールＡは、その証明が再証明を要するかどうか（全体再証明のオーダーのため、又は、証明満了のため）をチェックする（ステップ１３８４−１３８６）。新しい証明が必要な場合には、セキュリティ維持Ａが、新しい証明の生成を開始する（ステップ１３８４−１３８６）。公開キーＡは、新しいキーを生成し、この新しい公開キーにその古いプライベートキーを用いて署名する（ステップ１３９０）。セッションマネージャーＡは、署名された新しい公開キーをセキュリティサーバーのＳＳ証明生成に送る（ステップ１３９２−１３９６）。ここで、ＳＳ公開キーは、新しい公開キーの署名を有効化する（ステップ１３９８−１４００）。有効な署名でない場合、セキュリティサーバーは、ネットワークアクセスを拒否する。署名が有効であれば、ＳＳ公開キーがモジュールの新しい証明に署名し、それをモジュールに送る（ステップ１４０２）。セッションマネージャーＡは、証明を受け取り、セッション維持Ａがこの証明を有効化し、公開キーＡが署名を有効化する（ステップ１４０４−１４１０）。証明が有効でなければ、セッションマネージャーＡが「証明無効」メッセージと証明をメッセージ送付機能によりセキュリティサーバーに送る（ステップ１４１２−１４１３）。ＳＳネットワークサインオンがこのメッセージを受け取り、ＳＳ公開キーが署名を有効化する（ステップ１４１４−１４１８）。セキュリティサーバーが証明が実際に有効であると判断すると、該セキュリティサーバーはネットワークへのモジュールのアクセスを拒否する。しかし、証明が無効であれば、ＳＳセッションマネージャーが、ネットワークサーバーに対してネットワークから接続を絶つ旨を通報する（ステップ１４２０）。ＮＳネットワークサインオンは、故障したモジュールを通報する（ステップ１４２２）。ここで、モジュールは、加入者又は銀行に再度試みるかどうかを尋ねる（ステップ１４２４−１４３２）。他方、モジュールがその新しい証明が有効であると判断すると、セッションマネージャーＡはセキュリティサーバーに受け取りを送る（ステップ１４３４）。同様に、新しい証明が要求されない場合には、セキュリティ維持Ａが受取メッセージをセキュリティサーバーに送る（ステップ１４３６−１４３８）。いずれの場合にも、ＳＳセッションマネージャーが受取を受領し、モジュールとのセッションの終了を認識する（ステップ１４４０）。ここで、ＳＳネットワークサインオンがＫとＶをＡに送る（ステップ１４４２−１４４４）。セッションマネージャーＡはこのメッセージを受け、対称キーＡがＶと宛先をＫにより暗号化し、このメッセージをネットワークサーバーに送る（ステップ１４４６−１４４８）。ＮＳネットワークサインオンがこのメッセージを受け取り、ＮＳ対称キーがメッセージを解読して、このＶが先に生成したＶと同じであるかどうかをチェックする（ステップ１４５０−１４５４）。Ｖが正しくなければ、ＮＳネットワークサインオンがアクセス拒否メッセージをＡに送り、接続を絶つ（ステップ１４５６−１４５８）。Ｖが正しければ、ＮＳネットワークサインオンが宛先へのリンクを確立し、受取をＡに送る（ステップ１４６０）。最後に、セッションマネージャーＡは、受取を受領し、ＡがＥＭＳネットワーク１１９８にサインしたことを認識する（ステップ１４６２）。セッション確立図７は、確立セッションプロトコールを示す。セキュリティ維持Ａが、モジュール証明をセッションマネージャーに送り、セッションマネージャーＡがこの証明を受け取り、マネーモジュールＡがネットワークに接続されているかどうかをチェックする（ステップ１４６４−１４６６）。モジュールＡがネットワークに接続されていない場合には、セッションマネーＡがセッション維持Ａから受けた証明を宛先Ｂに送る（ステップ１４７６）。また、マネーモジュールＡがネットワークに接続されている場合には、対称キーＡがＫによりこの証明を暗号化し、セッションマネージャーＡが暗号化された証明をネットワークサーバーに送る（ステップ１４６８−１４７２）。ネットワークサーバーは、Ｋによりこの証明を解読し、該証明を宛先Ｂに送る。証明がネットワークサーバーから送られたか、或いはセッションマネージャーＡから送られたかに関係なく、セッションマネージャーＢが証明を受け、セキュリティ維持Ｂ（Ｂがセキュリティサーバーの場合には、この機能はセッションマネージャーにより達成される）がこの証明を有効化する（ステップ１４８０−１４８２）。証明が有効でない場合には、セッションマネージャーＢがセッションは終了したことを認識し、加入者又は銀行に通報する（ステップ１４８６−１４９２）（Ｂがセキュリティサーバーの場合には、Ｂは単に取引が終了したことを認識するだけである）。証明が有効であれば、セキュリティ維持Ｂが、Ａが不良idリスト上にあるかどうかをチェックする（ステップ１４９４−１４９６）。Ａがリスト上にあれば、セッションは終了される。Ａがリスト上になければ、乱数発生器Ｂが乱数Ｒ(B) とＢ認証メッセージを生成する（ステップ１４９８）。クロック／タイマーＢが時刻と日付を取り出す（ステップ１５００）。セキュリティ維持ＢがＲ(B)とＢ認証メッセージと時刻及び日付をメッセージ内に集成する（ステップ1502）。公開キーＢがＡの公開キーによりメッセージを暗号化し、セッションマネージャーＢが暗号化されたメッセージにＢの証明を添付して、このメッセージをＡに送る（ステップ１５０４−１５０６）。セッションマネージャーＡは、このメッセージを受け取り、公開キーＡがメッセージき暗号化された部分を解読し、セキュリティ維持ＡがＢの証明を有効化する（ステップ１５０８−１５１４）。証明が有効でない場合には、セッションマネージャーＡはセッションの終了を認識し、加入者又は銀行のいずれかに通報する（ステップ１５１６−１５２２）。証明が有効であれば、セキュリティ維持Ａが、Ｂが不良idリスト上にあるかどうかをチェックする（ステップ１５２４−１５２６）。Ｂがリスト上になければ、セキュリティ維持Ａは日付と時刻を取り出して、それをＢの日付及び時刻と比較する（ステップ１５２８−１５３０）。日付及び時刻が範囲外であれば、セッションは終了する。日付及び時刻が範囲内であれば、乱数発生器Ａが乱数Ｒ(A)とＡ認証メッセージをを生成する（ステップ１５３２）。ここで、セキュリティ維持Ａが、Ｒ(A) ＸＯＲＲの演算によりセッションキーを生成する（ステップ１５３４）。Ａ認証メッセージと、Ｂ認証メッセージと、時刻、日付及びＲ(A)はメッセージに集成され、Ｂの公開キーで暗号化される（ステップ１５３６）。このメッセージはセッションマネージャーＡによりＢに送られる（ステップ１５３８）。セッションマネージャーＢがこのメッセージを受け取り、公開キーＢがメッセージを解読し、セキュリティ維持ＢがＢ認証メッセージをチェックする（ステップ１５４０ −１５４６）。Ｂ認証メッセージが正しくなければ、セッションは終了される。Ｂ認証メッセージが正しい場合には、セキュリティ維持Ｂが、Ｒ(A)XOR Ｒ（B）の演算によりセッションキーを生成する（ステップ１５４８）。時刻と日付が取り出され、Ａの時刻及び日付と比較されて、互いに所定の範囲内にあるかどうかがチェックされる（ステップ１５５０）。時刻と日付が範囲外であれば、セッションは終了される。時刻と日付が範囲内であれば、セッションマネージャーＢはセッションの開始を認識する（ステップ１５５２）。次いで、セッションマネージャーＢは、受取とＡ認証メッセージとをＡに送る（ステップ１５５４−１５５６）。セッションマネージャーＡがこのメッセージを受け取り、セキュリティ維持ＡがＡ認証メッセージをチェックする（ステップ１５５８−１５６２）。認証メッセージが正しくなければ、セッションは終了される。認証メッセージが正しい場合には、セッションマネージャーＡはセッションの開始を認識する（ステップ１５６４）。移転ノート図８は、移転ノートプロトコールを示す。ノートディレクトリーＸがノートと移転のための価値を選択して、ノートの額と一連番号を更新し、メッセージを「ノート」に送る（ステップ１５６６）。移転のためにノートを選択する目的としては、(1)ディジタル署名の数（これは処理時間を要する）を最小にする、(2)パケットのサイズを最小にする、(3)送金側加入者に残された電子ノートの有用性を最大にする（すなわち、満了までの期間が最小のノートを送る）ことがある。この目的は、以下の移転アルゴリズムにより達成することができる。(1)最小数のノートを含む可能な選択肢をすべて求める、(2)これら選択肢のうちのどれが最小の移転数であるかを求める、(3)ステップ２において、これら選択肢に２以上の選択の余地が残されている場合には、通貨単位日が最小になるものを選択する。通貨単位日は、移転されるべきノートの価値の残額に、ノート満了日までの日数を掛けた値であり、パケット内のすべてのノートについての値の合計とする。ノートディレクトリーＸからメッセージを受け取ったとき、ノートＸは、移転される各ノートに添付される移転（トランスファー）を生成する（ステップ１５６８）。公開キーＸは、ノートのための署名を生成する（ステップ１５７０）。ここで、パケットマネージャーＸは、ノートにその新しい移転（トランスファー）と署名を集成してパケットとし、該パケットをＹに送る（ステップ1572-1574 ）。パケットマネージャーＹは、このパケットを受け取り、それを分解する（ステップ１５７６）。認証Ｙがノート内のすべての証明を有効化する（例えばマネー発生器証明及びすべての移転証明）。次いでＹが、移転グループ内の識別番号が署名内の証明の識別番号及び電子ノートの履歴全体にわたる証明グループの識別番号と合致することえ認証する。また、各ノートの移転額の一致性が、電子ノートの履歴全般にわたり、各継続する移転における額が直前の移転における額より小さいことを確認することによって、有効とされる。さらに、移転される全体の額がチェックされて、予期される額であることが確認される（ステップ１５７８−１５８０）。有効でなければ、取引はアボートされる（ステップ１５８２）。有効であり、Ｙが取引マネーモジュールである場合には、検証部Ｙがノートの満了日を認証する（ステップ１５８４−１５８８）。ノートのいずれかが満了している場合には、検証部Ｙがノート移転からの各idを不良idリストと対比することによってチェックする（ステップ１５９０−１５９２）。移転idのいずれかが不良idリスト上にあれば、取引はアボートされる。移転idが不良idリスト上にない場合（又はＹが取引マネーモジュール出ない場合）には、公開キーＹがノート署名を認証する(ステップ1594-1596)。どの署名も有効でない場合には、取引はアボートされる。署名が有効であれば、検証部Ｙは、そのノート本体がノートアプリケーションにストアされているか又は取引ログに位置させられたノート本体に合致するかどうかをチェックする（ステップ１５９８−１６００）。合致する各々のノート本体について、ノート移転ツリーが生成されて、ノート重複があったかどうかを判断する（ステップ１６０２−１６０４）。いずれかのノートが重複している場合には、取引はアボートされる。この重複チェックは、コンプロマイズされた取引マネーモジュールを使用する「セルフディーリング」によってノートを移転してマネーを生成するように試みる邪な個人を特に意識したものであり、このような個人に対して特に適している。重複がないか、又は、ノート本体の合致が識別されない場合には、ノートＹが該ノートをマネーホルダー内に位置させる（ステップ１６０６）。最後に、ノートディレクトリーＹがノート位置及び額を更新し、一連番号を初期化する（ステップ１６０８）。この移転ノートプロセスは、ノートの調整（「マネー生成調整」を参照）と、ノートの受取側が不良idリスト上にあるかどうかのチェックと、ノートの重複のチェックを助ける。これら追加の特徴及びステップは、相手側が重複ノートを持ち込んで流通させるのを困難にし、流通段階で重複ノートを検出する能力を高める。外国為替図９は、例示的に通貨単位としてドルとポンドを使用する外国為替のためのプロトコールを示す。最初に、ＡがＢに対してある＄／£交換レートでドルをポンドと交換することに同意する（ステップ１６０２）。次いで、ＡとＢがそのマネーモジュールにサインオンし、モジュールがその加入者に取引のタイプを示すように促す（ステップ１６０４−１６１０）。Ａが外貨の購入を選択し、Ｂが外貨の売却を選択する（ステップ１６１２−１６１４）。ＡとＢは安全保障取引セッションを確立する（１６１６−１６２０）。加入者Ａは、Ａの所有者／保持者に対して、額と交換しようとするドルのタイプとを示すように促す（ステップ１６２２）。支払い／交換Ａは、その額を受け取り、ノートディレクトリーＡは、Ａが十分な資金を持っているかどうかをチェックする（ステップ１６２４−１６２８）。資金が十分でなけれは、加入者向けＡは、新しい額を促し、この額は再び現存の資金との対比でチェックされる（ステップ１６３０−１６３２）。新しい額が入力されない場合には、取引はアボートされる（ステップ１６３４）。資金が十分であれば、支払い／交換Ａがドルの額をＢに送る（ステップ１６３６−１６３８）。加入者向けＢが、ここで、Ｂの所有者／保持者に対して、交換するポンドの額か又は単にドルに対する交換レートを示すことを促す（ステップ１６４０）。ノートディレクトリーＢは資金が十分かどうかをチェックする（ステップ１６４２−１６４４）。資金が十分でなければ、加入者向けＢが新ししルートを示すように促し、現在の資金が十分かどうかを再びチェックする（ステップ１６４６−１６４８）。しかし、新ししルートが選択されない場合には、支払い／交換ＢがＡに資金が不十分であることを通報する（ステップ１６５０−１６５２）。ここで、Ａは交換のための新しい額を選択するか又は取引をアボートする（ステップ１６３０−１６３４）。Ｂが取引にとって十分な資金を持っている場合には、支払い／交換ＢがＡに対して受取と交換すべきポンドの額（対応するレートも送る）を送る（ステップ１６５４−１６５６）。加入者向けＡは、ポンドの額及びレートの承認を行う（ステップ１６５８−１６６０）。額及びレートが正しくなければ、支払い／交換Ａは、Ｂに対して額及びレートが正しくないことを通報する（ステップ１６６２− １６６４）。加入者向けＢは、ここで、新しいレートを示す（ステップ１６６６ −１６６８）。新ししルートが選択さない場合には、取引はアボートされる（ステップ１６７０）。しかし、Ａが取引の額及びレートが正しいことを承認すれば、支払い／交換Ａがドルの額をマネーホルダーに通す（ステップ１６７２）。ここで、ドルノートがＡからＢに移転される（ステップ１６７４）。支払い／交換Ｂは、ポンド額をそのマネーホルダーに通す（ステップ１６７６）。ポンドノートは、ここで緒一からＡに移転される（ステップ１６７８）。取引のこの時点では、ＡとＢの両方は、正確な額の外国為替ノートを暫定的に保持する。ＡとＢは、２つの移転に参加したことになる。Ａは、(1)ＡからＢへのドルの移転と、(2)ＡがＢからポンドを受け取る移転を行い、Ｂは、(1)ＢからＡへのポンドの移転と、(2)ＢがＡからドルを受け取る移転を行う。外国為替取引を完了させるために、Ａは、その２つの移転の両方についてコミット（すなわち、終了させ、その取引ログに永久的に記録する）しなければならない。同様に、Ｂもその２つの取引の両方についてコミットしなければならない。Ａは、Ａ→Ｂの外国為替（ＡからＢへのドル）及びＢ→Ａの外国為替（ＢからＡへのポンド）に対して別々にコミットしてもよい。同様に、Ｂも、Ａ→Ｂの外国為替とＢ→Ａの外国為替に対して別々にコミットしてもよい。外国為替プロトコールの次の部分は、いずれの当事者も取引するマネーモジュールがコミットする順序を知らないように計画されている。この不確かさは、当事者が取引に際して意図的に不正を働く意欲を削ぐように働く。背景として、機能Ｓ（Ｘ）が、Ｓ（Ｏ）＝Ａ及びＳ（１）＝Ｂとなるように定義される。ここにＡ及びＢはマネーモジュールＡ及びＢを指す。したかって、Ｘがランダムに０又は１に選択されると、マネーモジュールＡ又はＢはランダムに指示される。以下のルーチンが、Ａ及びＢが共通のランダムＸを確立できるようにするために使用される。Ｒ(A)及びＲ(B)は、セッション確立サブルーチン中にそれぞれＡ及びＢにより生成された乱数である。Ｒ(A)ＸＯＲＲ(B)のパリティが、該Ｒ(A )ＸＯＲＲ(B)の各ビットをイクスクルーシブＯＲ処理することにより求ＯＲ１）。図９を再び参照すると、Tran Log Ａは、その取引ログを条件付きで更新し、と、ＡからＢへの移転（すなわちドル移転）が条件付きで記録される。Ｘが１と計算されると、ＢからＡへの移転（即ちポンド移転）が記録される。ログは条件付きで記録されるのであるから、マネーモジュールＡが取引をアボートする場合には、元に戻すことができる。更新ログは、該ログの更新が条件付きでなくなると（フローダイヤグラムに明示的に示されるか、又はコミット中に非明示的に示されるかして）永久的になる。セッションマネーＡは、ここで「ログ更新」メッセージをＢに送る（ステップ１６８２−１６８４）。応答として、Tran LogＢもップ１６８６）。Ｘ＝１であれば、Tran LogＢが炉具更新を条件付きでなくするようにセットする（ステップ１６８８−１６９０）。したがって、この時点では、ＢがＡへのポンドの移転についてコミットしている。次に、後で図１０を参照して説明するように、Ｂがコミットプロトコールに従う（ステップ１６９２）。この状況では、Ａが、その移転の両方（すなわち、ドルの移転とポンドの受け取り）についてコミットしており、Ｂは一つの継続中（コミットしていない）移転、すなわち、ドルの受け取りについてコミットしている。しかし、Ｘ＝０であれば（ステップ１６８８）、セッションマネーＢが「コミット開始」メッセージをＸに送る（ステップ１６９４−１６９６）。Tran LogＡが、ここでそのログ更新を条件付きでなくし（ステップ１６９８）、そのドル移転に対してコミットする。次に、図１０のコミットプロトコールが呼ばれる（ステップ１７００）。このプロトコール中（後で説明する）に、Ｂがその両方の取引（すなわち、ポンドの移転とドルの受け取り）についてコミットし、Ａが一つの継続中の取引、すなわちポンドの受け取りについてコミットする。以上のように、F/X取引は、ノートの各移転についてコミットし、一つのコミットのみの場合に起こり得るノートの複製が生じないようにする。外国為替プロトコールは、いずれの当事者も、どちらの移転（Ａのドルか、或いはＢのポンドか）が最初にコミットするかを知らないようにするものである。これは、当事者が取引で不正をしようとする動機を弱めることになる。各移転は別々にコミットされるが、コミットの順序は２つのモジュールによりランダムに選ばれる。取引を妨げようとする当事者は、50-50の確率でマネーの損失をすることになる。また、紛失したマネーは再クレームができるので、コミットを妨げようとする動機は生じない（紛失マネーのクレームを参照）。コミット図１０は、モジュールのコミットプロトコールを示す。セッションマネージャ −Ｘが「コミット準備完了」メッセージをＹに送る（ステップ１７０２−１７０４）。これは、該メッセージを受け取るモジュールに対しコミットする義務を与えるものとなる。従来のマネー移転シナリオでは、最初にコミットする責任を課する技術は、マネーを移転している当事者が最初にコミットし、マネーの複製の可能性を除去するものである。セッションマネージャーＹが次に受取をＸに送り（ステップ１７０６−１７０８）、その取引ログを更新することによって継続中の取引をコミットする（ステップ１７１０）。また、Ｙが取引マネーモジュールであれば、加入者向けＹが加入者に対して取引が成功したことを通報する（ステップ１７１２−１７１４）。セッションマネージャーＹはセッションの終了を認識する（ステップ１７１６）。 Tran LogＸがＹから受取を受領し、その取引ログを更新して、継続中の移転についてコミットする。Ｘは、Ｙと同様にして、そのコミットを終了する（ステップ１７１８−１７２４）。取引のアボート図１１は、モジュールのための取引アボートプロトコールを示す。セッションマネージャーＸは、変更を元に戻し、取引がアボートされたことを記録する（ステップ１７２６）。次いで、セッションマネージャーＸは、「コミットの準備完了」メッセージが送られたかどうかをチェックする（ステップ１７２８−１７３０）。もし送られていれば、Ｘは、コミット準備完了メッセージが送られた後にＸがアボートしたことを記録し、ノート識別子及びノート移転プロトコール中に受け取った各ノートの額を記録することによって、その取引ログを更新する（ステップ１７３２）。このようにして、失敗したコミットサブルーチン中にアボートプロトコールが呼び出されたときに、アボートプロトコールが情報を記録することになる。Ｘが取引マネーモジュール１１８６であり、コミット準備完了メッセージが送られていれば、加入者向けＸが、その加入者に、取引がアボートされたこと、及びマネー移転エラーがあるかも知れないことを知らせる（ステップ１７３４−１７３８）。Ｘが出納マネーモジュール１１８８である場合には、銀行向けＸが、銀行に対し、その会計取引を（適当な借方及び貸方により）元に戻すように通報する（ステップ１７４０−１７４２）。Ｘが取引マネーモジュール１１８６であり、コミット準備完了メッセージが送られていない場合には、加入者向けＸは、加入者に対し、取引がアボートされたことを通報する（ステップ１７４４）。いずれにしても、セッションマネージャーＸは、ここで取引を完了できない旨のメッセージをＹに送る（ステップ１７４６−１７４８）。セッションマネージャーＹは、その変更を元に戻し、取引がアボートされたことを記録する（ステップ１７５０）。次いで、Ｙが、その加入者に対し取引がアボートされたこと（ステップ１７５２−１７５８）、或いは銀行に対しその会計取引を元に戻すよう通報する（ステップ１７５６−１７５８）。以上述べたように、コミットプロトコール中に取引が中断されたときは、ノートが紛失する可能性がある。もし、その状態が生じると、受取側がアボートし、送り側がノートの移転を小ミントしたことになる。この場合には、受取側のマネーモジュールが、受け取った筈のノートについての情報を記録し、加入者に対して、潜在的な問題があること（すなわち、Ａが送ったノートをうけとらなかったこと）を知らせる。この状態では、送り側のマネーモジュールについては、ノートを適切に移転したことになる。ここで、受取側マネーモジュール加入者は、認証エージェンシーに対してマネーのクレームをすることができる。このクレーム情報は、失敗した取引のログ記録を含むことになる。認証エージェンシーは、そこで発行銀行に対して、このノートが調整されたかどうかをチェックすることができる。ある程度の時間の後、ノートが調整されていなければ、加入者はそのマネーをリクレームすることができる。 POS支払い図１２は、ポイントオブセールス（POS）支払いプロトコールを示す。該POS支払いプロトコールは、購買者の取引マネーモジュール１１８６と商人の取引マネーモジュール１１８６の間で行われる支払いを簡単にすることを意図するものである。商人の取引マネーモジュール１１８６は、例えば、スーパーマーケットのキャッシュレジスタに配置される。最初に、ＡがＢから製品を購入するか、サービスを受けることを同意する（ステップ１７６０）。取引マネーモジュールＡの所有者／ホルダーは、そのマネーモジュールにサインする（ステップ１７６２）。加入者向けＡが該所有者／ホルダーに取引を促し、Ａは、POS支払いをすることを選択する（ステップ１７６４ −１７６６）。一方、商人は、合計購入価格を決定する（ステップ１７６８）。加入者向けＢが取引を促し、ＢがPOS支払いをうけることを選択する（ステップ１７７０−１７７２）。ここで、ＡとＢは、安全保障セッションを確立する（ステップ１７７４−１７７６）。加入者Ｂは、支払い額を知らせ、支払い／交換Ｂがこの額を受け、それをＡに送る（ステップ１７７８−１７８２）。加入者向けＡが、ここでその加入者に対し、要求された額の承認を促す（ステップ１７８４−１７８６）。さらに、加入者は、支払いを行うノート（例えば、現金かクレジットか）を選択し、金額合計が要求された金額に一致するかどうかの確認を求められる。要求された金額が正しくなければ、支払い／交換Ａは、Ｂに対し、要求された金額が正しくないことを示すメッセージを送る（ステップ１７８８−１７９０）。加入者向けＢは、そこで、そのホストに対して新しい金額を示すことを促す（ステップ１７９２−１７９４）。新しい額が選択されない場合には、取引はアボートされる（ステップ１７９６）。要求された金額が正しければ、支払い／交換Ａがその額をノートのタイプにより受ける（ステップ１７９８）。ノートディレクトリーＡが、十分な資金があるかどうかをここでチェックする（ステップ１８００−１８０２）。資金が十分にない場合には、加入者向けＡが、新しい額をノートのタイプで出すよう促す（ステップ１８０４−１８０６）。新しい額が入金されない場合には、支払い／交換Ａは、Ｂに対して、十分な資金がないというメッセージを送る（ステップ１８０８−１７９０）。加入者向けＢは、ホストに対して新しい額の提示を促す（ステップ１７９２−１７９４）。新しい額が選択されない場合には、取引はアボートされる（ステップ１７９６）。新しい額が選択されると、支払い取引が再開される。資金が十分であれば、支払い／交換Ａは、この額をマネーホルダーに送る（ステップ１８１０）。そこで、ノートがＡから延びに移転される（ステップ１８１２）。最後に、取引マネーモジュールがコミットする（ステップ１８１４）。以上のように、POS支払いは、受取側が開始するので、購買者にとって手続が簡単になる。一般に、POS支払いは、商品に対する対価として商人に対して行う支払いに使用され、加入者対加入者（STS）支払いは、個人に対する支払い又は請求書に対する支払いに使用される。発行銀行からの更新クレジット図１３は、発行銀行更新クレジット取引プロトコールを示すもので、予め商人されたクレジット支払い手段であるクレジットノートを加入者が取得する手法を説明する。加入者は、該加入者が所有するクレジット口座に対し、一つまでのクレジットノートを所持することができる。加入者に更新されたクレジットノートの所持を認める各銀行は、それらのクレジットノートの発行銀行である。更新されたクレジット取引を設定するプロセスの流れは、マネーモジュールＡと銀行の出納モジュールＢの間のクレジット設定プロセスで始まるもので、（ステップ１８５４）、これを図１４を参照してさらに説明する。クレジット設定クレジット引き出し設定プロセスは、取引マネーモジュールＡの所有者／保持者がクレジットの更新を決定し、そのマネーモジュールにサインしたときに始まる（ステップ１８７６）。例えば、加入者Ａがクレジットノートを所有しているが、額をゼロにすることも含めてクレジットの額を変更すること（例えば、増加又は減少）を望むか、又は、現在はクレジットノートを所有していないが、所有することを希望する場合がある。加入者向けＡは、所有者／保持者に対して取引を促し、Ａは特定の銀行及び額から特定の額へのクレジット更新をすることを選択する（ステップ１８７８−１８８０）。この場合には、加入者Ａにより特定されたクレジット更新額は、該加入者Ａが所持しようとするクレジットの合計額である。そこで、取引マネーモジュールＡは、前述したネットワークサインオン手順によりネットワークに接続することによって選択された銀行との通信手順を開始する（ステップ１８８２）。マネーモジュールのサインオ、取引選択及びネットワークサインオンのステップが完了した後、Ａ及びＢは、安全保障セッションを確立する（ステップ１８８４）。そこで、取引マネーモジュールＡは、図１５を参照してもっと詳細に説明するクレジット要求手順により、出納マネーモジュールＢからのクレジットを要求する（ステップ１８８６）。クレジット要求ここで、図１５を参照して、クレジットを要求するプロセスについて以下に説明する。この図は、当事者をＸ及びＹとして表示しているが、以下に説明するプロセスステップでは、これらは、出納マネーモジュールと取引するどのようなマネーモジュールにも適用できる。初めに、選定した口座についてクレジットノートがあれば、ノートディレクトリーＸがこのクレジットノートの額を出納向けＸに送る（ステップ１８９７）。出納向けＸは、加入者Ａが要求するクレジット額の合計とクレジットノートの額の間のネットの差額を求め、クレジット更新要求を出納マネーモジュールに送って、このネット額のクレジットを特定の口座について承認することを要求する。この更新クレジット要求の通信において、要求側のマネーモジュールから出納マネーモジュールに対して、口座番号と口座のプロファイルとが、ネットのクレジット額とともに送られる（ステップ１８９８）。このメッセージは、メッセージ送付プロトコール（ステップ１９００）により送られ、この場合、メッセージは説明された暗号化技術を用いて暗号化される。クレジット引き出し要求と、口座番号及びプロファイルが出納マネーモジュールに送られると、この口座番号を有効化する手順が開始される（ステップ１９０２）。口座番号を有効化する手順を示す流れ図が図２０に示されており、これは説明を明瞭にするために、別に述べることにする。口座情報が有効化された状態で、銀行向けＹが、クレジット更新要求額をサポートするのに十分なクレジットがあることを検証する（ステップ１９０４）。十分なクレジットがあれば、取引向けＹが受取をＸに送り、Ｘは、この受取を出納向けアプリケーション機能を介して受領する（ステップ１９０６−１９１２）。しかし、クレジットの額が不十分な場合には、加入者は、クレジット更新のために新しい額を入力することを促される（ステップ1914-1918、図１５Ｂ）。加入者によりクレジット更新のために新しい額が入力されると、出納向けアプリケーションが、新しい額を出納マネーモジュールの銀行向けアプリケーションに送り、最新の要求額をカバーするのに十分な資金があるかどうかの検証を受け（ステップ１９２２−１９２４）、図１５Ａのステップ１９０４に戻る。加入者から新しい額が要求されない場合には、取引はアボートされる（ステップ1926）。図１４に戻ると、クレジット引き出し要求プロセスから戻ったとき、出納向けＡは、全通貨ノートと、移転されたクレジットノート（すなわち、前の取引で受け取ったクレジットノート）と、当該口座についてのクレジットノートを出納マネーモジュールに送る（ステップ１８８８）。クレジット引き出し要求がなされた時点で取引マネーモジュールがノートを保持していない場合には、出納向けＡアプリケーションは、提示されたノートがないというメッセージを出納マネーモジュールに送る（ステップ１８９２−１８９４）。しかし、取引マネーモジュールがノートを保持している場合には、図８について先に述べたノート移転手順に応じて、電子ノートがＡからＢに移転される（ステップ１８９６）。図１３に戻ると、取引向けＢは、通貨ノート又は移転されたクレジットノートが移転されたかどうかをチェックし（ステップ１８５６−１８５８）、これらのタイプのノートが実際に取引マネーモジュールＡから移転されていれば、会計取引が銀行向けアプリケーションＢによって掲示される（ステップ１８６０）。ノートがマネーモジュールから移転されていない場合には、会計取引がステップ１８６０により行われた後に、出納マネーモジュールとマネー発生モジュールの間にセッションが確立される（ステップ１８６２）。銀行向けＢは、クレジットノート（もしあれば）の額を利用可能なクレジット限度ラインに加えて利用可能なクレジットの合計額を得るとともに、要求されたクレジット額を利用可能なクレジット合計額から減額することによってクレジット限度ラインを更新する。要求クレジット額がゼロであり、通貨ノートが移転されないためにノート（通貨ノートとクレジットノートを含む）が作成されない場合には、マネーモジュールは、図１０を参照して前述したコミット手順に応じて取引を終了させる（ステップ１８６５−１８７５）。しかし、クレジット要求額がゼロでないか、通貨ノートが移転されたときのように、ノート（クレジット又は通貨）を作成する場合には、ノート要求手順に応じて出納Ｂがマネー発生モジュールからのノートを要求する（ステップ１８６５ −１８６６）。マネー発生モジュール内の要求されたノートは、前述した電子ノート移転のためのノート移転プロセス（図８参照）を使用して出納マネーモジュールＢに移転される（ステップ１８６８）。そこで、ノートは、同じノート移転プロセスを使用して、出納マネーモジュールＢから取引マネーモジュールに移転される（ステップ１８７０）。最後に、このクレジット更新手順を完了させるために、マネーモジュールは、図１０を参照して前述したコミット手順に応じて取引を終了させる。コミットプロセスは、出納マネーモジュールＢとの取引をコミットする取引マネーモジュールにより開始される（ステップ１８７２）。次に、コミットプロセスは、出納マネーモジュールＢとマネー発生モジュールとの間で行われる（ステップ１８７４）。これによって、発行銀行による一つの完全なクレジット更新の処理が完了する。マネー発行調整ノート調整のプロセスは、ノートの偽造及び複製をチェックするもので、図１６及び図１７を参照して説明する。マネー発行調整システムは、マネー発行マスターファイルにストアされた情報に基づくもので、ノートの移転履歴をモデル化するノート移転ツリーを構築する。図１６は、識別番号「１」を持つマネー発生モジュール（マネー発生器１と呼ぶ）と、識別子「２」を持つ出納マネーモジュール（出納モジュール２と呼ぶ）と、識別子３ないし６を持つ４つの取引マネーモジュールが、該マネー発生器１によって1:00:00の日付／時刻に生成された一つのノートに関連する仮想的シリーズの取引を概略的に示す。図１６に示される移転履歴の例において、図１７は、通貨の電子的象徴の移転がどのようにして最初にマネー発生モジュールにより生成されたノートから派生する通貨の電子的象徴のツリー状構造を形成するか、について示すものである。ノートの個々の移転（ツリーの枝の一部）は、ノート更新により銀行システムに入れられるか戻されるので、図１７のノート移転ツリーは、マネー発行調整システムにより構築される。この例では、マネー発生器１（モジュール識別子はディレクトリー署名された証明に含まれる）が、データフィールドの本体グループとデータフィールドの移転グループとを有する通貨の電子的象徴２３００を生成するもので、データフィールドは内容を明瞭にするために一部が概略的に示されている。さらに、便宜上、データフィールドの署名と証明は示されていない。データフィールドの本体グループは、ノート識別子（例えば、「Ｎ１２」）とマネー発生モジュール識別子（例えば、「ＭＧ１」）と発行銀行識別子（例えば「銀行名」）と発行日（例えば、1:00:00）と満了日（例えば、12:00:00）とノートの額と通貨単位識別子（例えば、＄５０）とを含む。ノートのタイプ等の他の本体グループのデータフィールドは、便宜上示していない。電子ノートの種々の日付フィールドは、例示目的で日：時間：分の形で示してある。勿論、他の時刻監視型式（秒も含む）も可能である。データフィールドの移転グループは、移転先識別子と移転の日付と移転額を有する移転レコードを含む。移転グループは又、各移転の後に移転元のノートディレクトリーによって歩進的に増加する一連番号を含むことが好ましい。通常は、移転を識別するには、日付／時刻と移転の移転先idで十分である。しかし、移転間で時刻の調整があり、同一の額が同一のモジュールにより移転される場合には移転と移転先idと日付／時刻と額とを重複させることもできる。したがって、この潜在的な問題を避けるために、移転を個々に識別するためには、移転レコードとノートディレクトリーに一連番号を加えることが好ましい。一連番号は、各移転の後に、ノートディレクトリーによって歩進的に増加される。一連番号をリセットすると、これは重複として検出されることになる。このように、通貨の電子的象徴２３００が出納モジュール２に移転されると、移転グループに移転レコード２３０２が追加され、これは、移転先識別番号（例えば、「２」）と移転の日付（例えば、1:00:00）と移転額（例えば、＄５０）と一連番号（例えば、「１」）を含む。例示のために、図１７に表されたノート移転は、移転されたノートの新しく追加された移転レコード部分のみを示す。また、便宜上、移転のすべての数を示す移転グループデータフィールドは示されていない。マネー発生器１からの通貨の電子的象徴２３００は出納モジュール２にストアされる。取引モジュール３により＄５０の引き出しの一部として、出納モジュール２は、移転レコード２３０２か添付された通貨の電子的象徴内のデータフィールドのコピーに移転レコード２３０４を追加することによって通貨の電子的象徴を形成する。このノートは、引き出しの完了とともに取引モジュール３にストアされる。ノート移転ツリーの各ノードは、移転ノートの新しく追加されたレコード部分を示すものである。移転ツリーに表されるように、1:00:00において、取引モジュールTR3が移転レコード２３０６により取引モジュール４に＄１０を支払う。1:01:00に、取引モジュール３が、移転レコード２３０８により、取引モジュール５に＄１０を支払う。3:08:01に、取引モジュール３が、移転レコード２３１０により、取引モジュール５に＄２５を支払う。4:11:08に、取引モジュール３が、移転レコード２３１２により、取引モジュール６に＄５を支払う。 2:00:01に、取引モジュール４が、移転レコード２３１４により、取引モジュール６に＄５を支払う。2:01:07に、取引モジュール４が、移転レコード２３１５により、取引モジュール６にさらに＄５を支払い、取引モジュール６は、3:07 :05に、移転レコード２３２１により、取引モジュール３に＄５を支払う。 2:00:06に、取引モジュール５は、移転レコード２３１６により、全部の＄10 のノートを取引モジュール３に支払う。3:08:01に取引モジュール３から移転レコード２３１０によって受け取った＄２５から、3:09:12に、取引モジュール５は、移転レコード２３１８により、取引モジュール６に＄２０を支払い、残りの＄５を4:12:05に移転レコード２３２０により出納モジュール２に預金する。 4:10:00に、取引モジュール６は、移転レコード２３２２によって、＄１０を取引モジュール５に移転し、5:00:06に、移転レコード２３２４によって、残りの＄１０を取引モジュール３に移転する。このＥＭＳの実施例においては、取引モジュールから銀行にマネーが預金されたとき、取引モジュール内のすべてのノート（クレジットノートも含む）が銀行システムに送られ、更新される。したがって、移転レコード２３２０によって表される取引モジュール５から出納モジュール２への上述した預金とほぼ同時に、移転レコード２３２６により表される別の同時移転が自動的に生じる。次いで、＄５の価値をもった新しいノートが（取引モジュール３がクレジットノートを持たないと仮定して）マネーモジュール１により発生され、出納モジュール２を介して適切な移転レコード（図示せず）を伴って取引モジュール３に移転される。したがって、取引モジュールと出納モジュールとの間の取引（例えば預金又は引き出し）のときに、該取引モジュール内のすべてのノートを更新することが、ノートを銀行システムに戻す別の手段を提供することとなり、ノート調整が助長される。 5:00:10において、移転レコード２３２８により、取引モジュール３が出納モジュール２に＄１０を預金する。取引モジュール５による預金について前述したように、移転レコード２３２８により表される取引モジュール３による預金と同時に、取引モジュール３が所有するすべてのノートの銀行システムに対する別の同時移転（図示せず）が、移転レコード２３１６及び移転レコード２３２１により表される移転も含めて、発生する。そこで、銀行システムは、更新のために該銀行システムに送られたノートの合計と等価のノートを取引モジュール３に戻す（例えば、＄１５）。したがって、この時点では、取引モジュール６のみが、移転ノート２３１２及び２３１４により表された初期ノート２３００の移転可能な部分を所有する。取引モジュール６が、これらのノートを他の取引マネーモジュールに移転する前に出納モジュールと取引（預金又は引き出し）すると、初期のノート２３００に関連する移転可能なノートは流通状態でなくなり、初期ノート２３００の移転により派生したすべてのノートは銀行システムに戻されたことになり、図１７に示す移転ツリーが完全に構築できるようになる。満了日は、ノートが移転できる期間を限定することで、ノートの調整を助長する。このノート移転ツリーにより理解できるように、ノートが偽造されると、預金された第１のピースに合致するノート本体がなくなる。ノートが複製されると、それ以降の移転は、前の移転額より大きい価値に加算されることになる。例えば取引モジュール６が5:00:06に＄１０（すなわち、移転レコード２３２４）でなく＄２０を取引モジュール３に移転したとすると、移転レコード２３１８（例えば、SEQ １，3:09:12，TR６，＄２０）以降の移転は合計＄３０になり、取引モジュール６が移転を重複したことが示される。銀行アクセスのための銀行口座へのマネーモジュールのリンク図１８は、銀行アクセスのために銀行口座にマネーモジュールをリンクさせるプロトコールを示す。このプロセスは、加入者が自身を顧客サービス代表（ＣＳＲ）に表示し、ＣＳＲが該加入者の口座をマネーモジュールにリンクさせるように要求することから始まる（ステップ１９２８）。ＣＳＲは、要求をＣＳＭホストＡ（ＣＳＭＨＡ）に入力して、表示した加入者の口座をリンクし、ＣＳＭＨＡが銀行からの表示された加入者の口座情報にアクセスするようにする（ステップ１９３０−１９３４）。次いで、加入者及びＣＳＲは、口座情報を承認し、加入者は、どの口座をマネーモジュールにリンクさせるかを選択する（ステップ１９３６）。加入者が、そのマネーモジュールＢが銀行口座にリンクするように要求し、ＣＳＲが、ＣＳＭＨＡを介して、ＣＳＭＡが銀行口座にリンクするように要求した後、安全保障セッションが加入者のマネーモジュールＢとＣＳＭＡの間に確立される（ステップ１９３８−１９４６）。ここで、ＣＳＭＡのホスト向けＡからの要求に応答して、ＨＣＳＭＡが口座情報をＣＳＭＡに送り、該ＣＳＭＡは口座情報を受けてその情報から口座プロファイルを作成する（ステップ１９４８−１９５２）。次いで、公開キーＡが口座プロファイルにサインし、口座プロファイル作成が口座プロファイルと署名からメッセージを作成し、このメッセージをマネーモジュールＢに送る（ステップ１９５４−１９５８）。安全維持Ｂがこのメッセージを受け、公開キーＢが該メッセージ上のディジタル署名をチェックする。署名が無効であれば、セッションはアボートされる（ステップ１９６６）。署名が有効であれば、加入者向けＢがこのプロファイルをホストに送って、顧客がこき口座プロファイルを検証できるようにする。顧客が口座プロファイルを承認しない場合には、取引はアボートされる。顧客が口座プロファイルを承認すれば、安全維持ＢがＣＳＭ証明を該口座プロファイルに追加する（ステップ１９６８）。出納向けＢが、ここで、口座プロファイルが最近生成された（新しい）口座プロファイルに関連する銀行について既にストアされたものかどうかをチェックする。出納向けＢアプリケーションに銀行の口座が既に存在する場合には、これは出納向けＢによって新しい口座プロファイルと置き換えられ、それ以外の場合には、出納向けＢが新しい口座プロファイルを追加する（ステップ１９７０−１９７４）。銀行口座へのマネーモジュールリンクの再有効化図１９は、加入者が、銀行口座への加入者のマネーモジュールのリンクを再有効化するためのプロトコールを示す。このプロセスは、加入者がそのマネーモジュールにサインオンすることによって開始され、加入者向けＡにより生成された取引への促しに応答して、加入者は、顧客サービスモジュール（ＣＳＭ）Ｂに関連する銀行のための銀行口座リンクを再有効化することを選択する（ステップ１９７８−１９８２）。マネーモジュールは、図６について先に説明したネットワークサインオンプロトコールを実行し、安全保障セッションがマネーモジュールＡとＣＳＭＢの間に確立される（ステップ１９８６）。出納向けＡは、ここで銀行口座の口座プロファイルをＣＳＭＢに送る（ステップ１９８８−１９９０）。口座プロファイル作成Ｂは、このメッセージを受け、安全維持ＢがＣＳＭ証明と口座プロファイルの署名を有効化する（ステップ１９９２−１９９５）。証明と署名が無効であれば、ＣＳＭは取引をアボートする（ステップ２０００）。証明が有効であれば、ホスト向けＢが口座プロファイルからの口座のリストをＣＳＭホスト（ＣＳＭＨ）に送り、ＣＳＭホストは、オンライン銀行システムにおいて各口座が現在生きているかどうかをチェックする(ステップ1996-2001)。口座のいずれかが満了している場合には、ＣＳＭＨは、アボートメッセージをＣＳＭに送り（ステップ２０１０）、ＣＳＭはアボートプロセスにより取引をアボートする（ステップ２０００）。すべての口座が生きていれば、ＣＳＭＨは再有効化の指示をＣＳＭに送り、口座プロファイル作成Ｂがこのメッセージを受けて口座情報から口座プロファイルを作成する（ステップ２００２−２００４）。ここで、公開キーＢが口座プロファイルにサインし、口座プロファイル作成Ｂが口座プロファイルと署名からメッセージを形成して、このメッセージをマネーモジュールＡに送る（ステップ２００６−２０１０）。公開キーＡは、このメッセージを受け取り、ディジタル署名を検証する（ステップ２０１２）。署名が有効でなければ、マネーモジュールＡは取引をアボートし（ステップ２０１８）、署名が有効であれば、プロファイル署名とＣＳＭ証明が口座プロファイルに加えられ（ステップ２０１４）、マネーモジュールＡは取引をコミットする（ステップ２０１６）。口座番号き有効化顧客サービスモジュール（ＣＳＭ）を採用する前述した実施例については、口座番号をどのようにして有効化するかを示す流れ図が図２０に示される。このプロセスにおいては、安全維持ＹがＣＳＭ証明を含む口座番号と口座プロファイルを受け取り、ＣＳＭ証明を検証する（ステップ２０２０）。無効な証明の場合は、２つのマネーモジュール間の取引はアボートされる（ステップ２０２８）。証明が有効であれば、安全維持Ｙが口座プロファイルを公開キーＹに送り、ＣＳＭ署名を検証する（ステップ２０２２）。無効な署名の場合は、安全維持Ｙがセッションマネージャーに対して、口座プロファイルが無効であることを通報し（ステップ２０２６）、２つのモジュール間の取引はアボートされる（ステップ２０２８）。署名の検証で有効な署名であることが確認されると、手順は銀行向けＹに進んで、該銀行向けＹが、受領した口座番号を銀行のオンラインコンピュータシステムに送る（ステップ２０２４）。口座が生きていない場合には、安全維持Ｙがセッションマネージャーに口座が生きていない旨を通報し（ステップ２０３０）、取引をアボートさせ（ステップ２０２８）、口座が生きている場合には、口座番号有効化プロセスにより、作動フローにおいて次のステップに戻り、口座番号有効化プロセスを実行する。以上述べたように、口座番号有効化プロセスは、ＣＳＭを含まない実施例に比べて、出納マネーモジュールについて簡単になる。紛失マネーのクレーム既に述べたように、幾つかの理由により電子マネーは紛失することがある。その理由は、(1)マネーモジュールが損傷し、機能しないとき、(2)マネーモジュールが紛失又は盗難にあったとき、又は(3)コミットに失敗したとき、である。マネーシステムの実用性に関しては、システムの加入者は、そのマネーが安全であることを確信できることが重要である。したがって、システムの故障により紛失したマネーを再クレームできることが重要である。物理的な損傷により紙が紛失する場合よりも起こり易いので、マネーモジュールが損傷したときマネーを交換できることは、信頼性を改善することになる。紛失又は盗難にあったマネーモジュールによる不幸が原因となる場合のマネーの交換はもっと問題である。そのようなクレームを許容することは、加入者が紛失に対する注意を怠ることになり、このシステムにおいて広い範囲のクレームがなされることになる。いずれにしても、ここに開示するＥＭＳは、これらのいずれの場合にも、紛失したマネーの交換を許容する方法を有する。最初の２つの場合では（すなわち、上述のケース(1)と(2)）、加入者は、紛失ノートのクレームを周期的に生成しなければならず（図２１参照）、これは、マネーモジュールの外にストアされる。故障のときは、クレームは、加入者の識別手段とともに発行銀行に提出される（図２２参照）。このクレームは、加入者のマネーモジュールの最後に知られた状態を含むものとなる。クレームされたノートの記述が有効化され、発行銀行に分配される。発行銀行は、ある期間の後、クレームされたノートが預金されない場合には、マネーを交換できる。コミットが失敗した場合には（すなわち、ケース(3)）、マネーモジュールが依然として機能していれば、クレームは、マネーモジュールと顧客サービスモジュールとの間での相互作用により生成される（図２２参照）。ケース(1)及びかっこ２の場合と同様に、このクレームは、マネー発行調査システムに送られ、該システムが預金されたマネーとクレームを照合する。発行銀行は、入金するマネーを詐欺的なものと対比でき、当事者の識別手段を有するので、発行銀行は確信をもって紛失したマネーを交換することができる。これらの方法を、図２１及び図２２を参照してもっと詳細に説明する。紛失ノートクレーム作成図２１Ａを参照するに、ここに説明したＥＭＳの一実施例によって実施されうる紛失ノートクレーム作成プロセスが示されている。このプロセスは、加入者が取引きのために、マネーモジュールへ、該加入者を促す加入者Ａ向けへ署名するときに開始される。そして、その加入者は、紛失ノートクレームオプション（ステップ２０３２〜２０３６）を選択する。それから、すべてのノートおよび非クレイム失敗コミットをまとめて整理するいくつかのステップが行われる（ステップ２０３８〜２０４２）。詳述すると、ノートディレクトリＡは、独自のクレイムシーケンス番号（クレームを識別するの使用される）を生成し、そのシーケンス番号でそのノートディレクトリのコピーをパケットマネージャへ送付する。ノートＡは、署名と証明付き全ノートのコピーをパケットマネージャへ送付する。それから、取引ログＡは、アボートプロセス中に記録されたコミットに失敗した全非クレームをパケットマネージャへ送る。次に、公開キーＡは、マネーモジュールプライベートキーを使用して、パケットマネージャに送られたクレームシーケンス番号、ノートディレクトリ、ノートおよび失敗したコミットに署名し、パケットマネージャＡは、その署名をアセンブルしたデータに付加し、その結果、アセンブルされたデータパケットとなり（ステップ２０４４〜２０４６）、このアセンブルされたデータパケットは、それから、公開キーＡで暗号化される（ステップ２０４８）。暗号化されるクレイムに対して、公開キーＡは、クレームシーケンス番号、クレームの総価値額およびマネーモジュールＡの証明からなるクレイム記述を付加する（ステップ２０５０）。加入者向けは、このクレームをマネーモジュールホストへ送り、そのマネーモジュールホストは、そのクレイムを受け取り、後で使用するために、そのマネーとは物理的に独立して、媒体に記憶させる（ステップ２０５２〜２０５４）。したがって、紛失ノートクレームプロセスは、マネーモジュールの損傷や故障によって破壊されない潜在的マネークレームを生成し保護するための方法を提供するものである。紛失ノートクレーム図２２は、紛失ノートをクレームするプロトコルを示している。これは、加入者が顧客サービス代表（ＣＳＲ）に対して紛失ノートのクレームを作成することを要求するときに開始される。加入者のアイデンティティが、ＣＳＲに明かされる（ステップ２０５６）。それから、ＣＳＲは、その加入者アイデンティティを顧客サービスモジュールホスト（ＣＳＭＨ）へ送り、そのクレイムが失敗コミットによるマネーモジュールの紛失または破壊によるものなのかをチェックする（ステップ２０５８〜２０６０）。もし、失敗コミットがそのクレイムに基づくものである（およびその加入者のマネーモジュールが紛失または損傷させられていない）場合には、そのマネーモジュールからの紛失ノートに対するクレームを受け取ることを加入者が選択し且つマネーモジュールからの紛失ノートに対するクレームを受け取ることをＣＳＲが選択した時に、顧客サービス代表に関連した（顧客サービスモジュールホスト（ＨＣＳＭ）を介して）顧客サービスモジュール（ＣＳＭ）のセッションマネージャＡおよび加入者のマネーモジュールのセッションマネージャＢは、ＣＳＭＡとマネーモジュールＢとの間にセキュリティセッションを確立するために呼び出される（ステップ２０６２〜２０７０）。セキュリティセッションが確立されるとき、ＣＳＭのホストＡ向けは、加入者のアイデンティティを要求し、ＨＣＳＭＡは、この要求に応答して、加入者アイデンティティを含むメッセージをＣＳＭへ送る（ステップ２０７２〜２０７４）。紛失ノートクレームＡは、このメッセージを受け取り、そのクレームが送られるべきことを指示するメッセージをマネーモジュールＢへ送る（ステップ２０７６〜２０７８）。取引ログＢは、このメッセージを受け取り、クレームされていない心配コミット記録を検索する（ステップ２０８０）。もし、失敗コミット記録が全く探し出されない場合には、その取引は中止される（ステップ２０８３）。さもなければ、加入者Ｂ向けは、検索された失敗コミット記録からの情報（例えば、日、時刻および額）を検討のために加入者へ送る（ステップ２０８２）。この情報から、加入者は、クレームされるべき取引を選択する（ステップ２０８４）。例えば、加入者は、別に解決された失敗コミット取引を選択しないであろう。それから、加入者によって選択された各失敗コミット取引について、取引ログＢは、これらの取引に対するログ情報を含むメッセージを作成して、このメッセージをＣＳＭへ送る（ステップ２０８６〜２０８８）。紛失ノートクレームＡは、このメッセージを受け取り、このクレームについて後で参照するために、クレーム識別子（例えば、確認番号）を含む承認をＢへ送る（ステップ２０９２）。取引ログＢは、この承認を受け取り、各選択された失敗コミット取引記録に、そのクレームの日／時刻およびＣＳＭによって与えられるクレーム識別子を付する（ステップ２０９４）。それから、Ｂは、その取引に対してコミットする（ステップ２０９６）。このコミット手続きが完了した後、この失敗コミット取引情報を含む受け取られたメッセージから、紛失ノートクレームＡは、好ましくは、取引調査システムの一部を構成するマネー発行調査システム（ＭＩＩＳ）へ送られるべきクレームを形成する。ホストＡ向けは、このクレームをＨＣＳＭＡへ送り、ＨＣＳＭＡは、このクレイムを受け取り、さらに、このクレームをＭＩＩＳへ送る（ステップ２０９８〜２１０２）。図２２のステップ２０６０へ戻って、もし、そのクレームが失敗コミットによるものでない（例えば、紛失または損傷したマネーモジュールによる）場合には、加入者は、図２１に関連して前述した紛失ノートクレーム作成プロセスにしたがって、マネーモジュール計算環境（例えば、フラッシュメモリへ）から発生されオフロードされた加入者のクレイムのうちのどれかにアクセスするホストＢからの紛失ノートに対するクレームを作成することを選択することができる。ＣＳＲは、別に、マネーモジュールホストからの紛失ノートに対するクレームを受け取るためのプロセスを開始させることを選択し、これらホストは、任意の既知の技法により通信リンクを確立する（ステップ２１０４〜２１０８）。それから、加入者ホストＢは、マネーモジュール証明を含むクレームを、ＣＳＭＨＡへ送る（ステップ２１０８〜２１１２）。ＣＳＭＨＡは、そのクレームをＣＳＭＡへ送る（ステップ２１０８〜２１１２）。紛失ノートクレームＡは、そのクレームを受け取り、そのクレームを公開キーＡへ送る。公開キーＡは、そのマネーモジュール証明を確認する（ステップ２１１４〜２１１６）。もし、そのマネーモジュール証明が無効である場合には、ホストＡ向けは、ＣＳＭＨＡに、そのクレームが拒否されたことを指示するメッセージを送り、ＣＳＭＨＡは、このメッセージを、加入者ホストＢへルーティングし、この紛失ノートクレームプロセスが終了する（ステップ２１２０〜２１２１）。もし、そのマネーモジュール証明が有効である場合には、公開キーＡは、そのクレームを復号して、そのクレーム内のすべてのノート証明および署名を照合する（ステップ２１１８）。もし、それらのノート証明および署名のうちのいずれかが有効でない場合には、その取引は、終了する（ステップ２１１９〜２１２１）。もし、それらのノート証明および署名が有効である場合には、紛失ノートクレームＡは、各ノートの移転履歴について、移転先へ送られたマネーの額が移転元によって受け取られるマネーの額より大きくないようにするために、移転額の一致性を照合する（ステップ２１２２〜２１２３）。もし、不一致がある場合には、その取引は終了させられる（ステップ２１２０〜２１２１）。しかしながら、もし、その取引額が全てのノートについて一致している場合には、紛失ノートクレームＡは、ＭＩＩＳへ送られるべきクレームを形成し、そのクレームに関連させられるクレーム識別子を生成する。ホストＡ向けは、その形成されたクレームおよびクレーム識別子をＣＳＭＨＡへ送り、このＣＳＭＨＡは、そのクレームおよびクレーム識別子を受け取り、そのクレーム識別子を加入者ホストＢへ適当にルーティングし、そのクレームをＭＩＩＳへ送り（ステップ２１２４〜２１２８）、この紛失ノートクレームプロセスを完了する。外国為替決済本発明では、電子マネーシステム（ＥＭＳ）を使って外国為替決済のリスクを排除する。外国為替取引は３つの仕方の中の一つで決済できる。１）粗（グロス）決済−−支払いは取り引き毎に行う。２）双方向粗決済−−２つの取り引き相手毎に取り引きを集計（ネット）して支払いを行う。３）多方向粗決済−−２つよりも多い取り引き相手をグループとして、グループ毎に取り引きを集計（ネット）して支払いを行う。これら３つのタイプの決済の有効性を説明するため図２３に示す外国為替プロセスを一わたり見ることにする。大きな外国為替取り引きはニューヨーク、ロンドンそして東京などで行われ、小さい取り引きはトロント、シドニーそしてシンガポールで行われる。これらの地域のそれぞれで、仕事日にはデイーラー３０００が取り引きを行っている（ステップ３００２）。取引日の終わりにディラーのバック・オフイスはそれの取り引きを取り引きの相手方のバック・オフイスとマッチさせ、そして確認する（ステップ３００４）。電話で、またはリューツやＥＢＳが提供するオン・ライン取り引きシステムもしくは仲介システムを介して取り引きできる。確認された取り引きは、相手方との取決めによって変わる取り引きプロセスに入る。粗決済（ステップ３００６）はアッド・ホックベースで行えるが、ネッティング・アレンジメント（ステップ３００８、３０１０）は相手方のオブリゲーションを確認するコントラクトを必要とする。取り引きする者同士が同じ通貨を売買するディラー・マーケットでだけネッティングは有用である。マルチラテラル・ネッティングは売買された通貨を集計する第３者であるネッティング・エージェントを必要とする。ネット・デビットのポジションにある取引者から支払いを受け、そしてネット・クレジットのポジションにある取引者へそのファンドを支払うことによりエージェント３０１２は支払いの相手方に支払う。これらのオプションを説明するため、２つの通貨、米国ドル（ＵＳＤ）と日本円（ＪＹＮ）を３人の取引相手Ａ，Ｂ，Ｃが扱うものとする。次の取り引きをしたものとする。１）ＡはＣから１０ＵＳＤで１０００ＪＹＮを買う。２）ＡはＢから５００ＪＹＮで５ＵＳＤを買う。３）ＢはＣから６００ＪＹＮで６ＵＳＤを買う。４）ＡはＢから９ＵＳＤで９００ＪＹＮを買う。粗ベースではＡはＣに１０ＵＳＤを払い、そして１０００ＪＹＮを受け取る。ＡはＢに５００ＪＹＮと９ＵＳＤを払い、そして５ＵＳＤと９００ＪＹＮを受け取る。そしてＢはＣに６００ＪＹＮを払い、そして６ＵＳＤを受ける。双方向ベースでは唯一の相違点は、ＡがＢに４ＵＳＤを払い、そして４００ＪＹＮを受け取ることである。多方向スキムではネッティング代理人３０１２はＡから１４ＵＳＤ，Ｂから１０００ＪＹＮそしてＣから４００ＪＹＮを受取り、そしてＡへ１４００ＪＹＮ、Ｂへ１０ＵＳＤＮそしてＣへ４ＵＳＤを支払う。決済額の同意があってから、ナショナル・ペイメント・システム３０１４へ支払いオーダーが与えられ、取り引きセッションのためのスケジュールド・ヴァリュー・デートに合わせる。ヘルスタット・リスクをなくすため本発明は支払い対支払いを同時的に行って、銀行日が終わってもどの取引者も鞄を保持してはいないようにする。マネーモジュール取引−−外国為替を決済−−を使用し、これにより多くの通貨の安全な交換ができる。図２４を参照する。マネーモジュール３０１６をホスト・アプリケーション３０１８−−リアルタイム決済−−との関連で使用し、決済エージェント３０２０を形成する。これらのエージェント３０２０を使って粗もしくは双方向決済をする。ホストアプリケーション・ソフトウエア３０１８の機能は後で決済プロトコールとの関連で説明する。粗もしくは双方向外国為替決済のための基本的なシステムの形態を図２５に示す。粗取引決済プロセス３００６もしくは双方向ネット決済プロセス３００８は送ったり、受け取ったりする外国為替の額をパスさせ、そして決済エージェント３０２０への決済の時間と日（例えば、そのヴァリュー・デート）とをパスさせる。プロセス３００６、３００８は例えば、コンピュータ処理されるか、もしくは取引チケットのマニュアル・エントリーを行う。割り当てられた決済時間に決済エージェント３０２０はリアルタイムで外国為替決済を行う。図２６を参照する。多方向ネッテイングのため多方向決済エージェント３０２２と多方向コーディネーター３０２４を導入する。これらは決済エージェント３０２０の変体（各々が特定のアプリケーションとマネーモジュールとを有する）であり、以下の流れ図で詳述することとなる。多方向決済コーディネーター３０２４と多方向決済エージェント３０２２とが一緒になってネッティング・エージェント３０１２を形成する。相手方の決済エージェント（ＣＳＡ）３０２０は、ＭＳＣへ接続された複数の多方向決済エージェント３０２２の一つを介して多方向決済コーディネーター（ＭＳＣ）３０２４へアクセスする。この構成がＭＳＣにアクセスする競争の問題をなくす。もっとももしも十分少ないＣＳＡが入っていると、ＭＳＣに直接アクセスできる。本発明の好ましい実施例ではＥＭＳにおける発行銀行は中央銀行である。ＥＭＳによりノン・ホーム・ベースド支払いのための対応バンキング関係が保存されることができ、新しいバンキング関係を確立しなくてよい。ハースタットのリスクが除去される理由の基礎は、中央銀行の電子マネーの受領が最終であるということと、一日２４時間、一周間７日交換が行われることができ、支払い対支払いが最終的な成功もしくは失敗へコーディネートされているということを仮定している。失敗は、例えその決済が完了しなくても誰も金を失っていないということを意味している。外国為替決裁本発明によると、ＥＭＳマネーモジュールは、為替期間の安全確認および多重通貨ユニット（例えば、ドル、円、およびリラとスイスフランのために交換されたポンド）においてデノミ化された電子マネーの安全な即時交換を可能にする外国為替決裁プロトコールを有する。このような為替はマネーモジュールのオーナー間のマネーモジュール取引として（例えば、加入者への機能はマネーモジュールの保持者を促す）、または後で述べられるグロス、バイラテラル、又はマルチラテラルの決裁の１つの一部として（即ち、加入者への機能が即時決裁のホストアプリケーション３０１８）実現することができる。図２７に図示されるように、ＡはＢと外国為替取引を決裁することに同意する（ステップ３０２６）。この同意は、マネーモジュールのオーナー間か、或いは各マネーモジュールのホストの即時決裁のアプリケーション間の何れかに発生する。ＡがマネーモジュールＡ上でサインをすることは、取引の型式に対して支払い、外国為替決裁および開始期間を選択する（ステップ３０２８−３０３２）。同様に、ＢがマネーモジュールＢ上でサインすることは、取引に対して促し、外国為替決裁と加入期間を選択する（ステップ３０３４−３０３８）。マネーモジュールの期間管理者は期間を確立する（ステップ３０４０−３０４４）。加入者Ａは、ノートおよび通貨ユニットの型式による額に対して支払い、支払い／為替Ａはこの情報を受け取る（ステップ３０４６−３０４８）。その後、ノートディレクトリーＡは、充分な資金に対してチェックする（ステップ３０５０ −３０５２）。もし、資金が充分でないなら、Ａは新しい額に対して支払われる（ステップ３０５４）。もし、新しい額が行われるなら、マネーモジュールは、再度充分な資金をチェックし、さもなければ、取引は成立しない（ステップ３０５６−３０５８）。もし、資金が充分であれば、支払い／交換所Ａは、ノートおよび通貨ユニットの型式による額を支払い／交換所Ｂへ送り、そしてＢは、額と通貨ユニットを検証するように促される（ステップ３０６０−３０６６）。もし、検証が不成功であれば、支払い／交換所Ｂは、失敗を報告するメッセージを支払い／交換所Ａに送り、ここでＡは新しい額に対して再度支払われる（ステップ３０６８−３０７１）。もし、額と通貨ユニットが検証されるなら、加入者Ｂは、ノートおよび通貨ユニットの型式による額に対して支払う（ステップ３０７２）。支払い／交換所Ｂは返事を受取り、ノートディレクトリーＢは充分な資金に対してチェックする（ステップ３０７３−３０７４）。もし、資金が不充分であるなら、Ｂは新しい額に対して支払われ、それに応答してマネーモジュールＢは、充分な資金に対して再チェックするか停止する（ステップ３０７６−３０８０）。もし、資金が充分であれば、加入者Ａが検証のために支払う場合、支払い／交換所Ｂは、通貨ユニットによる額をＡに送る（ステップ３０８２−３０８６）。もし、額が検証されなければ、支払い／交換所Ａは、失敗を報告するメッセージをＢへ送り、そして加入者Ｂは、新しい額に対して支払う（ステップ３０９０− ３０９４）。もし、新しい額が入れられるなら、マネーモジュールＢは、再度充分な資金に対してチェックし、そうでなければ、それは取引を停止する（ステップ３０９６−３０９８）。Ａが通貨ユニットによる額を検証するなら、支払い／交換所Ａは、額をマネーホルダーへ通す（ステップ３１００）。その後Ａは適切な電子ノートをＢへ移転する（ステップ３１０２）。支払い／交換所Ｂは、それが送られるべき額がゼロであるか否か、即ち一方向支払いかをチェックする（ステップ３１０６）。もし、そうなら、取引は完了し、マネーモジュールはコミットする（３１２４）。もし、送られる額がゼロでないなら、支払い／交換所Ｂはその額をマネーホルダーへ通し、特定化した電子マネーはＢからＡへ移転される（ステップ３１０８−３１１０）。トランログ(Tran Log)Ａは、Ｓ（Ｘ）が再びＳ（０）＝ＡおよびＳ（１）＝Ｂであるように定義され、Ｘが各取引に対してランダムに０か１であり、マネーモジュールＡとＢの両方に共通である場合、移転Ｓ（Ｘ）〜Ｓ（Ｘバー）上で条件付きの記録の更新を行う（ステップ３１１２）。期間管理者Ａは“記録が更新された“というメッセージをＢに送り（ステップ３１１４−３１１６）、トランログＢはその記録を条件付きで更新し、移転Ｓ（Ｘ）〜Ｓ（Ｘバー）を記録する（ステップ３１１８）。もし、Ｘ＝１なら、トランログＢは記録更新を無条件でセットする（ステップ３１２０−３１２２）。次に、Ｂは、コミットプロトコールに従い（ステップ３１２４）、その結果Ａは双方のその移転にコミットし、Ｂはその一方の未解決の移転にコミットする。しかし、Ｘ＝０なら期間管理者Ｂは“開始コミット”のメッセージをＡに送る（ステップ３１２０−３１２８）。トランログは、その記録更新を無条件でセットし、その移転にコミットする。コミットプロトコールが呼び出される（ステップ３１３２）。このプロトコールＢは、双方のその移転にコミットし、Ａは一方の未解決の移転にコミットする。全体／二極間決済図２８は、当事者決済エージエント３０２０（図２５参照）を使って、全体あるいは２極間外国為替のいずれかを実行するための段階を示す。最初に、当事者ＡとＢが、全体または２極間ネッティング決済プロセス３００６または３００８から交換されるべき金額を受け取る。当事者とは、例えばコンピュータ化された取引システムにより代表されるような当事者決済エージェント（ＣＳＡｓ）の所有者のことを意味する。当事者は、送付され、受け取られるべき金額と、決済の時刻と日付を当事者決済エージェント（ＣＳＡｓ）に渡す（段階３１３４）。次いで、ＣＳＡＡとＣＳＡＢは、決済を完了するのに必要な資金を、各銀行からマネーモジュール引出しを介することによって、あるいは十分な資金が手元にない場合には貸し手からの支払いとして獲得する（段階３１３６）。日付と時刻が一致すると、ＣＳＡＡとＣＳＡＢのホストアプリケーション３０１８が、照会し、各々が決済する準備ができたかを判定する（段階３１３８ −３１４０）。ＣＳＡｓの両者が準備できていない場合には、決済が失敗したことを当事者に通知する。ＣＳＡ両者の準備が整うと、マネーモジュールは外国為替決済プロトコルを実行し（段階３１４４）、リアルタイムで資金交換が行なわれる。次いで、ＣＳＡｓは、例えば、プリントアウトあるいは取引/勘定照合コンピュータシステムに通知することによって、決済が成功したことを当事者に知らせる（段階３１４６）。多極間決済図２９は、ＣＳＡｓ３０２０、ＭＳＡｓ３０２２およびＭＳＣ３０２４を用いて多極間外国為替決済を実行するための段階（図２６参照）を示す。最初に、ＭＳＣ３０２４がネッティングプロセス３０１０（同様の情報がＣＳＡｓ３０２０に報告される）からネット当事者借方および貸方を受け取る。当事者借方金額が決済の日付と時刻とともにＭＳＡｓ３０２２に送付される（段階３１４８）。ＭＳＡｓが、決済の日付と時間とともにネット借方金額を対応するＣＳＡｓに送る（段階３１５０）。ＣＳＡｓ３０２０は、各銀行からマネーモジュール引出しを介し、もしくは十分な資金が手元にない場合には貸し手からの支払いにより、必要とされる資金（例えば、適切な中央銀行から発行された電子マネー）を獲得する（段階３１５２）。ＣＳＡｓ３０２０は、資金が獲得されたことをＭＳＡｓ３０２２に通知し、外国為替決済プロトコルを用いて電子マネーをＭＳＡｓに移転する（段階３１５４−３１５８）。次いでＭＳＡｓ３０２２は、資金の受取りをＭＳＣ３０２４に通知し、電子マネーを外国為替決済プロトコルによりＭＳＣに移転する（段階３１６０−３１６２）。決済の指定された日付と時刻に、ＭＳＣ３０２４は、全ネット借方当事者が支払ったかどうかを検証する（段階３１６４−３１６６）。全当事者が支払っていなかった場合には、ＭＳＣ３０２４は、決済が失敗したという通知とともに借方記入されたＣＳＡｓに戻されるべき資金をＭＳＡｓ３０２２に移転する（段階３１６８）。ＭＳＡｓは、決済の失敗を借方ではないＣＳＡｓに通知するように知らされる。ＭＳＡｓ３０２２は、このような通知と（適切な場合には）ＣＳＡｓ３０２０に移転するための資金を受け取る（段階３１７２）。借方記入されたＣＳＡｓへの資金移転は、外国為替決済プロトコルを介する。ＣＳＡｓは、決済失敗の通知を受取り、借方ＣＳＡｓは資金を受け取る。最後に、ＣＳＡｓは決済が失敗したことを当事者に通知する（段階３１７４）。ＭＳＣ３０２４が全ネット借方当事者から支払いを受け取った場合には、ＭＳＣは、ネット借方当事者の資金を、支払いのためにＭＳＡｓ３０２２に移転する（段階３１７６）。このような資金の移転は、外国為替決済プロトコルを介する（段階３１７８）。ＭＳＣは、別のＭＳＡｓには決済が成功したことも通知する。ＭＳＡｓ３０２２は、決済が成功した通知と、適切な場合には資金とを受け取る。次に、これらはＣＳＡｓ３０２０に送られ、当事者に決済の成功を通知する（段階３１８０−３１８４）。記載した発明においては、外国為替プロセスが、適切な通信セキュリティを備えた既知の当事者間でなされると想定する。しかし、当事者がオープンで危険なネットワークを介し通信したいと望む場合には、取引を保護し確実にし、取引の証明を行なうのに信託エージェントを用いることができる。本発明の別の態様において、双方の当事者が取引を決済するのにマネーモジュール内に十分な資金を有する場合には、取引と決済をリアルタイムで圧縮するのにＥＭＳを使用できる。このことは、通常取引の一方側、すなわち外国為替の買いを行なう法人組織のディーラーにとって有益である。通常取引の両者、すなわち同一の通貨を売買するディーラは、取引ごとに換金の問題を決済することになる。上述の記載では多くの仕様を提供しているが、これらの可能となる詳細を、本発明の範囲を制限するものとして解釈すべきでなく、本分野の当業者であれば、本発明は、この思想範囲から逸脱することなくかつ利点をなくすことなく、多くの修正、付加および均等例を実行できることが容易にわかるであろう。従って、本発明は、開示された実施例に制限されるものでなく、以下の請求の範囲に従って定義されるものである。

【手続補正書】【提出日】平成１０年１１月１８日（１９９８．１１．１８）【補正内容】請求の範囲１．第１のマネーモジュールと前記第２のマネーモジュールを使用して外国為替決済を行う方法であって、 (a)前記第１のマネーモジュールと第２のマネーモジュールの間で暗号的セキュリティセッションを確立し、 (b)第１の加入者が、異なる通貨単位による複数の額を含む第１の交換データを前記第１のマネーモジュールに送り、 (c)前記第１のマネーモジュールが前記第１の交換データを前記暗号的セキュリティセッションを経由して前記第２のマネーモジュールに送り、 (d)前記第２のマネーモジュールが、第２の加入者に対して、前記第１の交換データを検証することを促し、 (e)前記第２の加入者が、異なる通貨単位による複数の額を含む第２の交換データを前記第２のマネーモジュールに送り、 (f)前記第２のマネーモジュールが前記第２の交換データを前記暗号的セキュリティセッションを経由して前記第１のマネーモジュールに送り、 (g)前記第１のマネーモジュールが、前記第１の加入者に対して、前記第２の交換データを検証することを促し、 (h)前記第１のマネーモジュールが、第１の移転によって、通貨単位識別子を備え前記第１の交換データにより特定された額及び通貨単位による第１のマネーの電子的象徴を、前記暗号的セキュリティセッションを経由して前記第２のマネーモジュールに送り、 (i)前記第２のマネーモジュールが、第２の移転によって、通貨単位識別子を備え前記第２の交換データにより特定された額及び通貨単位による第２のマネーの電子的象徴を、前記暗号的セキュリティセッションを経由して前記第１のマネーモジュールに送り、 (j)前記第１及び第２のマネーモジュールの各々は、取引ログを無条件で更新して前記第１の移転と前記第２の移転を別々に終了させる、ことから成る方法。２．前記第１及び第２の移転の双方に対して、移転元のマネーモジュールは、そのログを無条件に更新して移転元のマネーモジュールの前に前記第１又は第２の移転を終了させることを特徴とする請求項１に記載の方法。３．前記第１及び第２の移転に対してログを無条件に更新する命令は、ランダムであることを特徴とする請求項２に記載の方法。４．前記ログにおいて無条件に更新されるべき前記移転のうちの第１の移転は、無条件に更新される前に条件付きで更新されることを特徴とする請求項３に記載の方法。５．前記第１及び第２の加入者は、マネーモジュール又はリアルタイム決済ホストアプリケーションの保有者であることを特徴とする請求項１に記載の方法。６．前記第２のマネーモジュールは、前記第２の交換データにより特定された額がゼロであるかどうかをチェックして、もしゼロであれば、前記第１の移転が、取引に対して唯一つの電子マネー移転であることを特徴とする請求項１に記載の方法。７．前記第１の加入者が第１のリアルタイムホスト決済アプリケーションであり、前記第２の加入者が第２のリアルタイムホスト決済アプリケーションであり、さらに、決済処理システムが前記第１及び第２の交換データを前記第１及び第２のリアルタイムホスト決済アプリケーションに送り、前記第１及び第２のマネーモジュールが決済取引を完成するのに必要な電子マネーを取得する、ステップを含むことを特徴とする請求項１に記載の方法。８．請求項７に記載の方法において、前記決済プロセッシングシステムが、全体又は２極間ネッティングプロセスを行うことを特徴とする方法。９．請求項７に記載の方法において、前記電子マネーが、マネーモジュール請け出しを経由して得られることを特徴とする方法。 10．請求項７に記載の方法において、前記電子マネーが、マネーモジュール支払いを経由して得られることを特徴とする方法。 11．請求項７に記載の方法において、決済情報の時間と日付が、前記第１及び第２リアルタイムホストアプリケーションへ送られることを特徴とする方法。 12．請求項１１に記載の方法において、前記決済情報の時間及び日付によって特定された時間及び日付において、前記第１及び第２リアルタイムホストアプリケーションが、その各々が決済の準備ができたかどうを尋ねることを特徴とする方法。 13．第１のマネーモジュールを有するプロセッサベースの多極間の決済調整機関（ＭＳＣ）と、複数のプロセッサベースの多極間の決済エージェント（ＭＳＡｓ）であって各々が第２のマネーモジュールを有する多極間決済エージェントエージェントと、複数のプロセッサベースの当事者決済エージェント（ＣＳＡｓ）とを使用する、リアルタイム多極間決済の方法において、 (a)前記ＭＳＣが、ネッティングシステムからネット当事者の借方及び貸方データを受け取り、 (b)前記ＭＳＣが、前記ネット当事者借方データを前記ＭＳＡｓに送り、 (c)前記ＭＳＡｓが、前記ネット当事者借方データを、ネット借方ＣＳＡｓに送り、 (d)前記ネット借方ＣＳＡｓは、前記第２マネーモジュール及び第３のマネーモジュールの間で確立された第１の暗号セキュリティセッションを介して、前記ネット当事者借方データに応じて、電子マネーを、前記ＭＳＡｓに移転し、 (e)前記ＭＳＡｓの第２マネーモジュールは、前記電子マネーを前記ＭＳＣの第１マネーモジュールに移転し、 (f)前記ＭＳＣの第１マネーモジュールは、ネット貸方当事者のための前記ＭＳＡｓの第２マネーモジュールに、前記電子マネーを移転し、 (g)前記ＭＳＡｓは、前記第２及び第３マネーモジュールの間で確立された第２の暗号セキュリティセッションを介して、前記ネット当事者貸方データに応じて、前記電子マネーを前記ネット貸方当事者ＣＳＡｓに移転する諸ステップを有することを特徴とする方法。 14．請求項１３に記載の方法において、前記ＭＳＣ、ＭＳＡｓ及びＣＳＡｓは、各々、ホストアプリケーションを有することを特徴とする方法。 15．請求項１３に記載の方法において、ステップ(b)は、更に、前記ＭＳＣが、前記ＭＳＡｓに、決済データ及び時間データを送るステップを含み、ステップ (c)は、更に、前記ＭＳＡｓが、前記決済データ及び時間データを、前記ネット貸方ＣＳＡｓに送るステップを含むことを特徴とする方法。 16．請求項１５に記載の方法において、ステップ(e)の後に、前記決済データ及び時間データによって特定された日付及び時間において、全ネット貸方当事者ＣＳＡｓが支払われたかどうかを、前記ＭＳＣがチェックすることを特徴とする方法。 17．請求項１６に記載の方法において、更に、全ネット貸方当事者ＣＳＡｓが支払い終えていない場合、前記ＭＳＣは、前記電子マネーを、借方に記入したＣＳＡｓに戻すように、その決済が不首尾である通知をつけて、移転するステップを有することを特徴とする方法。 18．請求項１３に記載の方法において、更に、前記ステップ(c)の後に、前記ネット借方ＣＳＡｓが、マネーモジュール請け出し又は支払いを経由して電子マネーを取得するステップを有することを特徴とする方法。 19．請求項１３に記載の方法において、前記ステップ(f)は、前記ＭＳＣは、前記ネット借方当事者ＣＳＡｓへ報告するように、前記ＭＳＡｓに通知するステップを含むことを特徴とする方法。 20．第１のマネーモジュールおよび第１のホストアプリケーションを有するプロセッサベースの多極間の決済調整機関（ＭＳＣ）と、複数のプロセッサベースの多極間の決済エージェント（ＭＳＡｓ）であって各々が第２のマネーモジュールおよび第２のホストアプリケーションを有する多極間決済エージェントエージェントと、複数のプロセッサベースの当事者決済エージェント（ＣＳＡｓ）とを使用する、リアルタイム多極間決済の方法において、 (a)前記第１のホストアプリケーションが、ネッティングシステムからネット当事者の借方及び貸方データを受け取り、 (b)前記第１のホストアプリケーションが、前記ネット当事者借方データおよび決済日および時刻データをネット借方ＣＡＳｓの前記第２のホストアプリケーションに送り、 (c)前記ネット借方ＣＡＳｓの前記第１および第２のマネーモジュールの間に第１の暗号セキュリティセッションを確立し、 (d)前記ネット借方ＣＳＡｓは、前記暗号セキュリティセッションを介して、前記ネット当事者借方データに応じて、電子マネーを、前記ＭＳＣに移転し、 (e)前記第１のホストアプリケーションは、前記ネット借方ＣＳＡｓのすべてが支払われたかをチェックし、 (f)ネット借方ＣＳＡｓの前記第１および第２のマネーモジュールの間に第２の暗号セキュリティセッションを確立し、 (g)前記ＭＳＣは、前記第２の暗号セキュリティセッションを介して、前記ネット当事者貸方データに応じて、前記電子マネーを前記ネット貸方ＣＳＡｓに移転する諸ステップを有することを特徴とする方法。 21．リアルタイム多極間決済システムにおいて、コンピュータインプリメントネッティングシステムと、第１のマネーモジュールおよび第１のホストアプリケーションを有し、該第１のホストアプリケーションが前記ネッティングシステムから借方および貸方データを受け取るようなプロセッサベース多極間決済調整機関（ＭＳＣ）と、各々が第２のマネーモジュールおよび第２のホストアプリケーションを有する複数のプロセッサベース多極間決済エージェント（ＭＳＡｓ）と、各々が第３のマネーモジュールおよび第３のホストアプリケーションを有する複数のプロセッサベース当事者決済エージェント（ＣＳＡｓ）と、を備えており、前記第２および第３のマネーモジュールは、暗号セキュリティセッションを介して通信し、前記第１のマネーモジュールは、前記第２のマネーモジュールを介してネット貸方ＣＳＡｓの前記第３のマネーモジュールから電子マネーを受け取り、ネット貸方当事者のすべてが支払をした時、前記第１のマネーモジュールは、前記第２のマネーモジュールを介してネット貸方ＣＳＡｓの前記第３のマネーモジュールへ前記電子マネーを送る、ことを特徴とするリアルタイム多極間決済システム。 22．前記第１のホストアプリケーションは、ネット貸方ＣＳＡｓの前記第３のホストアプリケーションへ報告された特定の決済日および時刻でネット当事者のすべてが支払をしたかをチェックする請求項２１記載のシステム。 23．プロセッサベース当事者決済エージェントにおいて、マネーの電子的象徴を記憶し、移転し、受け取るマネーモジュールであって、他のマネーモジュールとの暗号的セキュリティセッションを確立するマネーモジュールと、ネット貸方データを受け取り、それにより、前記マネーモジュールにマネーの電子的象徴を移転させるように命令し、且つネット貸方データを受け取り、それにより、前記マネーモジュールにマネーの電子的象徴を受け取るように命令するリアルタイムホストアプリケーションと、を備えることを特徴とするプロセッサベース当事者決済エージェント。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．第１のマネーモジュールと前記第２のマネーモジュールを使用して外国為替決済を行う方法であって、 (a)前記第１のマネーモジュールと第２のマネーモジュールの間で暗号的セキュリティセッションを確立し、 (b)第１の加入者が、異なる通貨単位による複数の額を含む第１の交換データを前記第１のマネーモジュールに送り、 (c)前記第１のマネーモジュールが前記第１の交換データを前記暗号的セキュリティセッションを経由して前記第２のマネーモジュールに送り、 (d)前記第２のマネーモジュールが、第２の加入者に対して、前記第１の交換データを検証することを促し、 (e)前記第２の加入者が、異なる通貨単位による複数の額を含む第２の交換データを前記第２のマネーモジュールに送り、 (f)前記第２のマネーモジュールが前記第２の交換データを前記暗号的セキュリティセッションを経由して前記第１のマネーモジュールに送り、 (g)前記第１のマネーモジュールが、前記第１の加入者に対して、前記第２の交換データを検証することを促し、 (h)前記第１のマネーモジュールが、第１の移転によって、通貨単位識別子を備え前記第１の交換データにより特定された額及び通貨単位による第１のマネーの電子的象徴を、前記暗号的セキュリティセッションを経由して前記第２のマネーモジュールに送り、 (i)前記第２のマネーモジュールが、第２の移転によって、通貨単位識別子を備え前記第２の交換データにより特定された額及び通貨単位による第２のマネーの電子的象徴を、前記暗号的セキュリティセッションを経由して前記第１のマネーモジュールに送り、 (j)前記第１及び第２のマネーモジュールの各々は、取引ログを無条件で更新して前記第１の移転と前記第２の移転を別々に終了させる、ことから成る方法。２．前記第１及び第２の移転の双方に対して、移転元のマネーモジュールは、そのログを無条件に更新して移転元のマネーモジュールの前に前記第１又は第２の移転を終了させることを特徴とする請求項１に記載の方法。３．前記第１及び第２の移転に対してログを無条件に更新する命令は、ランダムであることを特徴とする請求項２に記載の方法。４．前記ログにおいて無条件に更新されるべき前記移転のうちの第１の移転は、無条件に更新される前に条件付きで更新されることを特徴とする請求項３に記載の方法。５．前記第１及び第２の加入者は、マネーモジュール又はリアルタイム決済ホストアプリケーションの保有者であることを特徴とする請求項１に記載の方法。６．前記第２のマネーモジュールは、前記第２の交換データにより特定された額がゼロであるかどうかをチェックして、もしゼロであれば、前記第１の移転が、取引に対して唯一つの電子マネー移転であることを特徴とする請求項１に記載の方法。７．前記第１の加入者が第１のリアルタイムホスト決済アプリケーションであり、前記第２の加入者が第２のリアルタイムホスト決済アプリケーションであり、さらに、決済処理システムが前記第１及び第２の交換データを前記第１及び第２のリアルタイムホスト決済アプリケーションに送り、前記第１及び第２のマネーモジュールが決済取引を完成するのに必要な電子マネーを取得する、ステップを含むことを特徴とする請求項１に記載の方法。８．請求項７に記載の方法において、前記決済プロセッシングシステムが、全体又は２極間ネッティングプロセスを行うことを特徴とする方法。９．請求項７に記載の方法において、前記電子マネーが、マネーモジュール請け出しを経由して得られることを特徴とする方法。 10．請求項７に記載の方法において、前記電子マネーが、マネーモジュール支払いを経由して得られることを特徴とする方法。 11．請求項７に記載の方法において、決済情報の時間と日付が、前記第１及び第２リアルタイムホストアプリケーションへ送られることを特徴とする方法。 12．請求項１１に記載の方法において、前記決済情報の時間及び日付によって特定された時間及び日付において、前記第１及び第２リアルタイムホストアプリケーションが、その各々が決済の準備ができたかどうを尋ねることを特徴とする方法。 13．第１のマネーモジュールを有するプロセッサベースの多極間の決済調整機関（ＭＳＣ）と、複数のプロセッサベースの多極間の決済エージェント（ＭＳＡｓ）であって各々が第２のマネーモジュールを有する多極間決済エージェントエージェントと、複数のプロセッサベースの当事者決済エージェント（ＣＳＡｓ）とを使用する、リアルタイム多極間外国為替決済の方法において、 (a)前記ＭＳＣが、ネッティングシステムからネット当事者の借方及び貸方データを受け取り、 (b)前記ＭＳＣが、前記ネット当事者借方データを前記ＭＳＡｓに送り、 (c)前記ＭＳＡｓが、前記ネット当事者借方データを、ネット借方ＣＳＡｓに送り、 (d)前記ネット借方ＣＳＡｓは、前記第２マネーモジュール及び第３のマネーモジュールの間で確立された第１の暗号セキュリティセッションを介して、前記ネット当事者借方データに応じて、電子マネーを、前記ＭＳＡｓに移転し、 (e)前記ＭＳＡｓの第２マネーモジュールは、前記電子マネーを前記ＭＳＣの第１マネーモジュールに移転し、 (f)前記ＭＳＣの第１マネーモジュールは、ネット貸方当事者のための前記ＭＳＡｓの第２マネーモジュールに、前記電子マネーを移転し、 (g)前記ＭＳＡｓは、前記第２及び第３マネーモジュールの間で確立された第２の暗号セキュリティセッションを介して、前記ネット当事者貸方データに応じて、前記電子マネーを前記ネット貸方当事者ＣＳＡｓに移転する諸ステップを有することを特徴とする方法。 14．請求項１３に記載の方法において、前記ＭＳＣ、ＭＳＡｓ及びＣＳＡｓは、各々、ホストアプリケーションを有することを特徴とする方法。 15．請求項１３に記載の方法において、ステップ(b)は、更に、前記ＭＳＣが、前記ＭＳＡｓに、決済データ及び時間データを送るステップを含み、ステップ (c)は、更に、前記ＭＳＡｓが、前記決済データ及び時間データを、前記ネット貸方ＣＳＡｓに送るステップを含むことを特徴とする方法。 16．請求項１５に記載の方法において、ステップ(e)の後に、前記決済データ及び時間データによって特定された日付及び時間において、全ネット貸方当事者ＣＳＡｓが支払われたかどうかを、前記ＭＳＣがチェックすることを特徴とする方法。 17．請求項１６に記載の方法において、更に、全ネット貸方当事者ＣＳＡｓが支払い終えていない場合、前記ＭＳＣは、前記電子マネーを、借方に記入したＣＳＡｓに戻すように、その決済が不首尾である通知をつけて、移転するステップを有することを特徴とする方法。 18．請求項１３に記載の方法において、更に、前記ステップ(c)の後に、前記ネット借方ＣＳＡｓが、マネーモジュール請け出し又は支払いを経由して電子マネーを取得するステップを有することを特徴とする方法。 19．請求項１３に記載の方法において、前記ステップ(f)は、前記ＭＳＣは、前記ネット借方当事者ＣＳＡｓへ報告するように、前記ＭＳＡｓに通知するステップを含むことを特徴とする方法。 20．第１のマネーモジュールおよび第１のホストアプリケーションを有するプロセッサベースの多極間の決済調整機関（ＭＳＣ）と、複数のプロセッサベースの多極間の決済エージェント（ＭＳＡｓ）であって各々が第２のマネーモジュールおよび第２のホストアプリケーションを有する多極間決済エージェントエージェントと、複数のプロセッサベースの当事者決済エージェント（ＣＳＡｓ）とを使用する、リアルタイム多極間外国為替決済の方法において、 (a)前記第１のホストアプリケーションが、ネッティングシステムからネット当事者の借方及び貸方データを受け取り、 (b)前記第１のホストアプリケーションが、前記ネット当事者借方データおよび決済日および時刻データをネット借方ＣＡＳｓの前記第２のホストアプリケーションに送り、 (c)前記ネット借方ＣＡＳｓの前記第１および第２のマネーモジュールの間に第１の暗号セキュリティセッションを確立し、 (d)前記ネット借方ＣＳＡｓは、前記暗号セキュリティセッションを介して、前記ネット当事者借方データに応じて、電子マネーを、前記ＭＳＣに移転し、 (e)前記第１のホストアプリケーションは、前記ネット借方ＣＳＡｓのすべてが支払われたかをチェックし、 (f)ネット借方ＣＳＡｓの前記第１および第２のマネーモジュールの間に第２の暗号セキュリティセッションを確立し、 (g)前記ＭＳＣは、前記第２の暗号セキュリティセッションを介して、前記ネット当事者貸方データに応じて、前記電子マネーを前記ネット貸方ＣＳＡｓに移転する諸ステップを有することを特徴とする方法。 21．リアルタイム多極間外国為替決済システムにおいて、コンピュータインプリメントネッティングシステムと、第１のマネーモジュールおよび第１のホストアプリケーションを有し、該第１のホストアプリケーションが前記ネッティングシステムから借方および貸方データを受け取るようなプロセッサベース多極間決済調整機関（ＭＳＣ）と、各々が第２のマネーモジュールおよび第２のホストアプリケーションを有する複数のプロセッサベース多極間決済エージェント（ＭＳＡｓ）と、各々が第３のマネーモジュールおよび第３のホストアプリケーションを有する複数のプロセッサベース当事者決済エージェント（ＣＳＡｓ）と、を備えており、前記第２および第３のマネーモジュールは、暗号セキュリティセッションを介して通信し、前記第１のマネーモジュールは、前記第２のマネーモジュールを介してネット貸方ＣＳＡｓの前記第３のマネーモジュールから電子マネーを受け取り、ネット貸方当事者のすべてが支払をした時、前記第１のマネーモジュールは、前記第２のマネーモジュールを介してネット貸方ＣＳＡｓの前記第３のマネーモジュールへ前記電子マネーを送る、ことを特徴とするリアルタイム多極間外国為替決済システム。 22．前記第１のホストアプリケーションは、ネット貸方ＣＳＡｓの前記第３のホストアプリケーションへ報告された特定の決済日および時刻でネット当事者のすべてが支払をしたかをチェックする請求項２１記載のシステム。 23．プロセッサベース当事者決済エージェントにおいて、マネーの電子的象徴を記憶し、移転し、受け取るマネーモジュールであって、他のマネーモジュールとの暗号的セキュリティセッションを確立するマネーモジュールと、ネット貸方データを受け取り、それにより、前記マネーモジュールにマネーの電子的象徴を移転させるように命令し、且つネット貸方データを受け取り、それにより、前記マネーモジュールにマネーの電子的象徴を受け取るように命令するリアルタイムホストアプリケーションと、を備えることを特徴とするプロセッサベース当事者決済エージェント。