JPH11504144A

JPH11504144A - 電子マネーシステム

Info

Publication number: JPH11504144A
Application number: JP8531976A
Authority: JP
Inventors: ショーラムエスローゼン
Original assignee: Citibank NA
Current assignee: Citibank NA
Priority date: 1995-04-21
Filing date: 1996-04-19
Publication date: 1999-04-06
Anticipated expiration: 2016-04-19
Also published as: US5799087A; NO974835D0; EP0823105A2; WO1996033476A2; SI9620055A; US6047067A; BR9608187A; SK142697A3; CZ332397A3; MX9708120A; WO1996033476A3; US5920629A; CA2218612C; AU720200B2; HU221396B1; NO974835L; HUP9800982A3; JP3604151B2; US5953423A; PL180662B1

Abstract

(57)【要約】（１）要求払い預金及び電子クレジット授権によって裏書きされた電子通貨を含んでいる電子マネーを発生しかつ加入している顧客に発行するマネー発生器装置に結合された銀行または金融機関；（２）電子マネーを受け入れかつ分配するコルレス銀行；（３）電子マネーを記憶し、参加銀行のオン−ラインシステムでマネー取引を実行するかまたはオフ−ライン取引で他の同様な取引装置と電子マネーを交換するために加入者によって用いられる複数の取引装置；（４）処理取扱しかつ開設またはコルレス銀行に取引装置をインターフェイスし、かつ開設またはコルレス銀行自体の間でインターフェイスするために、開設またはコルレス銀行に対応付けられた、テラー装置；（５）異なる発行銀行の電子マネー口座をバランスするための決済銀行；（６）システムの全てのコンポーネントに通信サービスを供給するためのデータ通信ネットワーク；及び（７）システムの保全性を維持しかつシステム内の偽造及び不正を検出するためのセキュリティ構成を有している電子マネーシステム。本発明の実施例は、銀行アクセスを供給するために口座をマネーモジュールにリンクしかつ紛失マネー請求を取り扱う顧客サービスモジュールを含む。

Description

【発明の詳細な説明】電子マネーシステムこの出願は、１９９４年４月２８日に出願された出願係属中の米国特許出願第 08/234,461号の一部継続出願である。発明の分野本発明は、現金、小切手、クレジット及びキャッシュカード、並びに電子資金振替に対する経済取引の代替媒体として電子マネー取引を実行するための電子マネーシステムに関する。発明の背景今日、毎年約３５００億の硬貨及び通貨取引が、個人と企業の間で発生している。硬貨及び通貨取引の大規模な使用は、購入、運賃、並びに銀行口座預金及び引出しのような個々の取引の自動化を制限している。個々の現金取引は、正しい金額を有すること及びその釣銭を用意することの必要性によって負担になる。更に、ペーパーキャッシュ及び硬貨の取扱い、及び管理（保護を含む）は、個人及び金融機関の両方に対して不便であり、費用が掛かり、かつ時間の浪費である。米国だけでも、単に貨幣を移動するために一年に６００億ドルが貨幣取扱者によって費やされるということが推定される。更に、紙幣のセキュリティは、例えば、広範囲にわたりアクセス可能な、高性能カラー複写機を使用することにより比較的容易な偽造によって著しく脅かされている。小切手は、口座において利用可能な金額までは、どんな特定な金額についても記入できるけれども、小切手は、振替可能性が非常に限られており、かつ物理的な機関から供給を受けなければならない。紙をベースとする小切手振出しシステムは、現金取引の制限を十分に緩和せず、小切手を処理することに関連付けられた固有な遅延を追加すると同時に通貨を取扱うことの不都合の多くを共有する。この点で、経済取引は、改良されたセキュリティを求めると同時に、より低いコストでのより大きな便宜を求めて努力している。自動化は、コンピュータ化された電子資金振替（“ＥＦＴ”）システムを通して大きな取引に対するこれらの品質をある程度は達成した。電子資金振替は、本質的に銀行制度の集中コンピュータ取引を通して達成される価値交換の処理である。ＥＦＴサービスは、大きな商業組織によって主に用いられる、電子“小切手 ”を利用する支払いの振替である。自動決済機構（ＡＣＨ）及び販売時点（ＰＯＳ）システムは、近年における実質的基準で小売り及び商業組織によって用いられるようになった電子資金振替システムの例である。しかしながら、これらの型のＥＦＴシステムを通して行われる支払いは、銀行組織なしにそれらを実行することができないという点で限られている。更に、ＡＣＨ取引は、業務外時間中に通常実行することができない。ホームバンキング請求書支払いサービスは、支払いを行うために個人によって用いられる電子資金振替システムの例である。現在、ホームバンキング構想は、ほとんど顧客を見出していない。パーソナルコンピュータを用いて電話回線上で支払い、口座取引及び情報に対するサービスを供給する銀行では、銀行の顧客の１％未満がサービスを用いている。ホームバンキングが成功した製品ではない一つの理由は、顧客がこの型のシステムでは必要に応じて貨幣を預金及び引出しできないからである。小売り業者の口座と顧客の口座の間のような、口座間で貨幣を取引するためにオン−ラインシステムで用いられる、現行のＥＦＴシステム、クレジットカード、キャッシュカードは、バンキングシステムの外で汎用的に受け入れられる経済価値の振替を与える自動取引システムに対する必要性を満たすことができない。更に、クレジット及びキャッシュカードシステムは、不正に対して一般的に安全ではなくかつ適切なプライバシーを与えるものではない。振替を仲介することをバンキングシステムに要求せず、かつある形の経済価値を提供できる、自動で、しかもより便利な取引システムを実行するために、オフ −ライン電子資金振替に向かう傾向があった。例えば、通常の通貨及び小切手型の支払いシステムに対する代替としてキャッシュレス支払い取引において用いることができるある形の“電子マネー”に対して多数のアイデアが提案されている。“METHOD AND APPARATUS FOR IMPLEMENTING ELECTRONIC CASH”という発明の名称の米国特許第4，977，595 号公報、及び“MODULAR FUNDS TRANSFER SYSTEM ” という発明の名称の米国特許第4，305，059 号公報を参照のこと。更によく知られた技術としては、所与の金額について購入されかつ特定の目的に対してそれから前払い価格を控除をできる磁気ストライプカードがある。経済価値の消耗により、カードは、破棄される。他の例としては、価値を表す情報を繰り返し記憶さえることができ、この価値が特定の目的に対して同様に控除されるように構成された通称スマートカードまたはメモリカードがある。しかしながら、これらの提案されたシステムは、貨幣としての銀行預金の重要性と、発行されうる汎用的に受け入れられるマネー表示であればどんな形式のものでもバックできることの必要性を十分に認識できていないものである。これらのシステムでは、電子的であれ、紙であれ、経済価値の表示は、それらの資産に対する見返りとしての等価負債の保証なしで発行される。これらの提案されたペーパーレス支払いシステムのいずれも、仲介するシステムなしで、加入者間で、電子資金またはマネーを加入者が振替できるようにする自動装置を含むだけでなく、電子マネーによって表示された価値を発生し、システム内のマネーバランスを維持するために設けられた銀行及び金融機関の電子マネー口座を決済しかつ支払うための全バンキングシステムを備え、包含する多目的電子マネーシステムを実行できるほど十分に包括的ではない。それゆえに、金融機関の仲介なしで支払元から支払先への共通した経済的為替取引を許容し、かつ個人への支払い過程の管理を与えるシステムに対する必要性が存在する。更に、現行ＥＦＴシステムの制限を有さない、あらゆる大きさの商業的支払いに対して大きな組織によって用いることができる経済的為替取引のシステムを与えることに対する必要性が存在する。ここで参考文献として採り入れられる、本出願人に譲渡された１９９１年１１月１５日に出願の、米国特許出願第07/794,112号には、上述した、及び他の従来技術の制限を克服することができ、通常の現金と交換可能でありかつ汎用的に受け入れられる電子マネーを利用する完全な電子マネーシステムを提供できる電子マネーシステム（ＥＭＳ）が記述されている。この発明によるＥＭＳは、加入者の間、金融機関の間、及び加入者と金融機関の間で、通貨及びクレジットを含む経済価値を安全かつ確実に振替る方法及びシステムを提供する。また、ＥＭＳは、多種通貨の形式における電子マネーを与える。それにも係わらず、安全性かつ確実性の最優先は、ＥＭＳに対する更なる向上の必要性を生成する。従って、本発明の目的は、再使用、複製及び偽造から守られた経済取引に対する向上したＥＭＳシステム及び関連方法を提供することである。本発明の別の目的は、紛失マネーを請求するためのシステム及び処理を提供することである。本発明の更に別の目的は、購入者から品物の小売り業者へのマネーのリアルタイム振替に対して確実にかつ安全に使用されうるユーザフレンドリな電子支払いシステム及び方法を提供することである。本発明の上記目的及び効果は、本発明によって達成することができるものの例示であり、すべてを記述したものではなく、また、認識することができる可能な効果を制限することを企図するものでもない。それゆえに、本発明のこれら及び他の目的及び効果は、ここに実施されたもの、または当業者において自明でありうるあらゆる変更を考慮して修正を加えられたものの両方を含む意味で、ここの記述から自明であるかまたは本発明を実施することにより学ぶことができるものである。従って、本発明は、ここに示しかつ説明した新規な方法、構成、組合せ及び改良にある。発明の要約上記、及び他の目的を達成するために、本発明の方法及び装置は、（１）要求払い預金及び電子クレジット授権によって裏付けられた電子通貨を含んでいる電子マネーを発生し、加入している顧客に対して発行するためのマネー発生装置に連結された銀行または金融機関；（２）電子マネーを受入れかつ分配するコルレス銀行；（３）電子マネーを記憶し、参加銀行のオン−ラインシステムでマネー取引を実行するため、またはオフ−ライン取引における他の類似する取引装置と電子マネーを交換するために加入者によって用いられる複数の取引装置；（４）発行銀行及びコルレス銀行に取引装置をプロセスハンドリングしかつインターフェイスし、かつ発行銀行及びコルレス銀行自体の間でインターフェイスするために、発行銀行及びコルレス銀行に関連付けられた、テラー装置；（５）異なる発行銀行の電子マネー口座をバランスするための決済銀行；（６）システムの全てのコンポーネントに通信サービスを与えるためのデータ通信ネットワーク；及び（７）システムの完全性を維持し、かつシステム内の偽造及び不正変更を発見するためのセキュリティ構成を有している電子マネーシステムの形式の好ましい実施例を採り入れる。好ましい実施例では、マネー発生装置、取引装置、及びテラー装置の機能は、互いにネットワークされうる不正変更されないコンピュータハードウェア及びアプリケーションソフトウェアモジュールの組合せによって実行される。情報は、不正検査からの保証を与えるために暗号化された形式で伝送される。電子マネーは、有効化、及び変更または偽造からの保証を与えるべくディジタル署名で伝送される。これらの装置によって交換された電子マネーは、通貨またはクレジットの電子表示でありうる。電子通貨の重要な形態は、それが銀行ノートと等価なものでありかつ発行銀行における預金に対する引き出し要求を通して通常の紙幣と交換可能であるが、発行銀行及びコルレス銀行の両方において引出しまたは預金できるということである。しかしながら、発行銀行だけが電子通貨を発生することができ、かつその償還に対して責任がある。発行銀行は、今日の銀行産業によって現在実行されているように、銀行システムにおけるマネーバランスを維持するために銀行間決済及び支払い処理を後で利用する。電子マネー表示は、代替可能であり、汎用的に受け入れられ、かつ発行銀行から申し分なく償還可能である、即ち、それらは、マネー取引の特性を有する。電子マネーシステムの保全性を保存するために、電子マネーの各交換は、他の情報と一緒に、クレジットまたは通貨のマネー単位、（即ち、ドル、円、等）、クレジットまたは通貨の単位の金額、電子クレジットまたは通貨を発行している銀行及び複数のディジタル署名、を識別するデータを含む。本発明の広い態様によれば、電子マネーシステムは、現金取引の代わりに銀行の要求払い預金、及び電子クレジット授権によって裏付けられた電子通貨を含んでいる電子マネーを利用する取引を提供する。本発明の実施例では、ＥＭＳは、電子マネーを発生するためのマネーモジュール；電子マネーを発行、分配、及び受け入れるためのマネーモジュール；及び他の受け入れマネーモジュール間及び受け入れマネーモジュールと発行マネーモジュール間で電子マネーを受け入れ、記憶し、かつ振替るためのマネーモジュールを備えている。本発明の更なる態様によれば、電子マネーシステムは、銀行の預金の債権及び電子クレジット授権を通して通常のマネーと相互交換可能な電子通貨を含む電子マネーを実行しかつ維持するために設けられている。本発明の実施例では、システムは、複数の発行銀行；電子マネーを生成するための発生器モジュール；電子マネーの受け入れ及び分配を含む取引のようなテラー取引を実行し、他のテラーモジュールと相互作用させるために、発生器モジュールに結合されたテラーモジュール；電子マネーシステムの全体としての保全性を与えるためのセキュリティシステム；個別の発行銀行の電子マネー口座をバランスし、かつ発行銀行によって発行された電子マネーを決済するための決済及び支払い処理；及び取引モジュール間及び取引モジュールとテラーモジュールの間で電子マネーを振替るための、承認されたユーザにより所有される複数の取引モジュール；及び紛失マネーのクレームを処理し、かつ銀行アクセスを与えるべくマネーモジュールに口座を連結するための顧客サービスモジュールを含む。本発明の別の形態によれば、発生器モジュール、取引モジュール、テラーモジュール、及び顧客サービスモジュールの機能は、互いにネットワークされうるいたずらよけコンピュータハードウェア及びアプリケーションソフトウェアの組合せによって実行される。発行銀行またはクレジット授権における要求払い預金によって裏付けられた通貨の電子表示でありうる、これらのモジュールによって交換される電子マネーは、無権限変更または偽造からのセキュリティを与えるべくディジタル署名と共に伝送されうる。好ましい実施例では、偽造及び不正変更からの保証は、また、電子マネーのモジュール及び個々のユニットに周期的に書換えられるように要求することによって供給される。モジュール間のノートの移転は、ノート移転履歴照合を容易にすべくシーケンス識別番号を含むのが好ましい。オフェンディングモジュールまたは偽造電子マネーは、それらが発見されると直ぐに流通から除去することができる。また、本発明の更なる形態によれば、紛失マネーを請求するための方法が提供され、それにより取引モジュール所有者／保持者は、顧客サービスモジュールを介して銀行組織に請求を提出しうるし、かつ銀行組織によるノート移転履歴照合に続いて、所有者／保持者は、請求された紛失ノートを回復しうる。本発明の更なる形態は、マネーモジュールにおける各クレジット口座に対して一つのクレジットノートのみが存在するようにクレジットを更新するための取引モジュールに対する方法を提供する。また、本発明の好ましい形態によれば、商人から品物を安全かつ確実に購入するために取引モジュールの所有者／保持者に対する方法が提供される。図面の簡単な説明本発明の更なる形態、特徴、及び効果は、本発明が添付した図面に関連してなされた以下の説明に照らして考慮される場合に理解されかつより容易に明らかになるであろう。図１Ａは、ＥＭＳセキュリティ階層構造を示す図である。図１Ｂは、主要セキュリティサーバと通常のセキュリティサーバの間のセキュリティネットワーク通信を示す図である。図２は、ＥＭＳに対するセキュリティネットワーク構成を示す図である。図３Ａは、セキュリティサーバの機能コンポーネントを示す図である。図３Ｂは、ネットワークサーバの機能コンポーネントを示す図である。図４Ａは、顧客サーバモジュールの機能コンポーネントを示す図である。図４Ｂは、主要セキュリティサーバの機能コンポーネントを示す図である。図５は、ネットワークサイン−オン手順の概観を示す図である。図６Ａ−６Ｋは、ネットワークサイン−オンプロトコルを示す図である。図７Ａ−７Ｅは、ＥＭＳにおけるエスタブリッシュセッションプロトコルを示す図である。図８Ａ−８Ｂは、移転ノートプロトコルを示す図である。図９Ａ−９Ｄは、外国為替プロトコルを示す図である。図１０は、ＥＭＳにおけるモジュールに対する委任プロトコルを示す図である。図１１Ａ−１１Ｂは、ＥＭＳにおけるモジュールに対する中止取引プロトコルを示す図である。図１２Ａ−１２Ｃは、販売時点（ＰＯＳ）支払いプロトコルを示す図である。図１３Ａ−１３Ｂは、更新クレジット形式発行銀行プロトコルを示す図である。図１４は、設定クレジットプロトコルを示す図である。図１５Ａ−１５Ｂは、要求クレジットプロトコルを示す図である。図１６は、ノート移転履歴の例を示す図である。図１７は、ノート移転ツリーを示す図である。図１８Ａ−１８Ｃは、銀行アクセスプロトコルに対する銀行口座へのリンクマネーモジュールを示す図である。図１９Ａ−１９Ｃは、銀行口座プロトコルへの再確認マネーモジュールを示す図である。図２０は、有効口座番号プロトコルを示す図である。図２１Ａ−２１Ｂは、生成紛失ノート請求プロトコルを示す図である。図２２Ａ−２２Ｅは、請求紛失ノートプロトコルを示す図である。実施例本発明は、安全かつ確実に経済価値を変換するための電子媒体を用いている改良されたマネーシステムを提供する。システムは、新規のデータ処理システムを現行の世界中の銀行組織で実行することができる他の手順と統合することによって実行することができる。本発明によれば、ここに参考文献として採り入れる、本出願人に譲渡された１９９１年１１月１５日出願の、米国特許出願第07/794,1 12 号に開示された、電子マネーシステムに複数の型の改良が加えられる。これらの改良は、改良された外国為替（Ｆ／Ｘ）及び移転ノート取引処理、紛失マネーを請求するための処理、銀行アクセスに対するマネーモジュールをリンクするための処理、販売地点の支払いに対する処理、及びクレジットを更新するための処理を含んでいる一組のセキュリテ改良を含む。セキュリティマネーシステムに対する有効セキュリティは、３つの特性を有する：偽造を禁止し、偽造を検出し、かつ偽造者を制止する。上記ＥＭＳは、３つの特性の全てを示すコンポーネントを有するべく設計される。偽造を禁止するために、マネーモジュールは、対称及び非対称キー暗号を用いて通信する。いかなるメッセージも明文ではない。モジュールのプロトコルは、また、不正防止ハードウェアによって物理的に保護される。偽造は、ノート照合処理によって検出される。全システム時間プロトコル（例えば、ノート満期）は、電子ノートに規則的に照合されることを強制する。電子ノートは、また、銀行取引が実行される場合に新しくされる（即ち、新たな満期日を有する新たなノートで置換される）。マネーモジュールは、複製されたまたは偽造されたノートがそれらにタイバックされるならば、ブロックされる（例えば、不良ＩＤリストに配置される）。また、これらのモジュールを通過したノートは、移転することを許されない。ノートが満了するかまたは最終的に銀行に預金されるので、複製または偽造ノートの移転は、、制止される。更に、重要なシステムセキュリティ問題の場合には、ＥＭＳは、全地球的な証明更新を要求して、次にそれらがＥＭＳネットワークにサインするときに取引マネーモジュールを含む、全てのモジュールに証明更新するように要求する。次の改良の一覧表は、モジュール間の対話を聞いている立ち聞き者から全ての情報を保護することを意図している。全ての情報は、公開キー及びモジュール識別子でさえも、覆い隠される。改良されたセキュリティ特徴の一覧表は、以下のものを含む。１）図５を参照して以下に説明するように、だれもマネーモジュールをだますかまたは明文でその情報のいずれも妨害することができないようにネットワークサイン−オンを確保すること。２）セキュリティサーバ、マネー発生器、及びテラー識別子を割り当てる方法を生成すること（モジュール番号付けスキームを参照）。これらの識別子はａ）セッションを確立すること（図７参照）；ｂ）ノートを移転（転送）すること−−移転記録をチェックする（図８参照）でチェックされる。３）全てのモジュールは、主要セキュリティサーバの公開キー、及び全ての他のモジュールを証明するセキュリティサーバを運ぶような、主要セキュリティサーバを含んでいる、２層セキュリティサーバ構成（セキュリティ階層構造及びセキュリティネットワークを参照）を実行すること。４）支払いのノートまたは外国為替（Ｆ／Ｘ）を受け入れる前に全ての移転に対して不良ＩＤ一覧表をチェックし、かつ複製ノートをチェックするために移転ノートを改良すること（図８参照）。５）セキュリティサーバの非公開キーを用いて全ての証明を暗号化すること（証明構成及び有効化参照）。６）動的に公開キーの大きさを変化させること（セキュリティネットワーク及び図６参照）。７）故障がマネーの複製を生じないようにコミットプロトコルを変更すること（図１０参照）。８）マネーを受け取りマネーを送らないことによって、確実にごまかしを行うためにコミットを妨害することを、いずれのパーティもできないようにするために、Ｆ／Ｘを変更すること（図９参照）。９）支払人がコミットするが受取人がアボートした場合に、失敗したコミットに情報をログするためにアボートを変更すること（図１１参照）。１０）必要に応じて地球的証明更新ができるようにすること（セキュリティネットワーク及び図６参照）。セキュリティ改良の上記一覧表は、本発明の強化されたセキュリティシステムによってもたらされるセキュリティ特性の幾つかを挙げたものである。これら及び他の改良は、ＥＭＳに対するセキュリティシステムの代替の好ましい実施例のそれに続く詳細な説明から更に理解することができるであろう。セキュリティ階層構造本発明によれば、ＥＭＳシステムセキュリティに対する別の実施例は、次のように構成できる。図１Ａを参照すると、ＥＭＳは、主セキュリティサーバ１１８２及び通常セキュリティサーバ１１８４の二つの型のセキュリティサーバを有する。主セキュリティサーバ１１８２は、（通常）セキュリティサーバ１１８４を証明する。セキュリティサーバ１１８４は、システムの全ての他のモジュール（取引ＭＭｓ１１８６、テラーＭＭｓ１１８８、マネー発生器モジュール１１９０、及び顧客サービスモジュール１１９２）を証明する。主サーバ１１８２は、他の主サーバ１１８２またはセキュリティサーバ１１８４とだけ対話する。図２を参照すると、主セキュリティサーバ１１８２は、セキュリティＬＡＮ１１９４によって互いに接続された安全なファシリティに収容される。ＬＡＮ１１９４は、セキュリティネットワーク１１９６に安全なゲートウェイを通して接続される。セキュリティサーバだけがこのネットワークで通信する。全てセキュリティサーバは、物理的に保護された装置である。セキュリティサーバ１１８４は、ＥＭＳネットワーク１１９８及び銀行ローカルネットワーク１２００にも取り付けられている。セキュリティサーバは、それらが偽造されたかのように取り扱われ、他のすべてのモジュールとの対話により有効にされる。セキュリティサーバ１１８４及びモジュールのみが証明を有する。主セキュリティサーバの公開キーは、これらの装置によって運ばれる。二つの型の証明が存在する：セキュリティサーバ及びモジュール。証明有効化プロトコルは、：１）Ｃｅｒｔ（ＳＳ）を有効化するａ）ＰＳＳ（ｉｄ）＝［ＰＳＳ（ｉｄ）ＸＯＲＣ］ＸＯＲＣｂ）Ｄ_PSS（Ｅ_PSS（Ｘ‖σ_PSS（Ｘ）））＝Ｘ‖σ_PSS（Ｘ）ｃ）ＳＳ（ｉｄ）が本物であるかどうかをチェックする（モジュール番号付スキーム参照）ｄ）日付が有効かどうかチェックするｅ）Ｄ_PSS（σ_PSS（Ｘ））＝ｈ（Ｘ）かどうかチェックする２）Ｃｅｒｔ（Ｍ）を有効化するａ）Ｃｅｒｔ（ＳＳ）を有効化するｂ）Ｄ_PSS（Ｅ_SS（Ｙ‖σ_PSS（Ｙ）））＝Ｙ‖σ_PSS（Ｙ）ｃ）Ｍ（ｉｄ）が本物であるかどうかをチェックする（モジュール番号付スキーム参照）ｄ）日付が有効かどうかチェックするｅ）Ｄ_PSS（σ_PSS（Ｙ））＝ｈ（Ｙ）かどうかチェックするここで、ＰＳＳ＝主セキュリティサーバＳＳ＝セキュリティサーバＭ＝モジュール ‖＝連鎖ｉｄ＝識別番号ｈ＝ハッシュ関数Ｃ＝全てのモジュールにより共有される一定の乱数ＰＫ＝公開キー（キーの長さを含む） σ＝ディジタル署名＝ＥｈＣｅｒｔ=証明Ｅ＝ディジタル署名を暗号化しかつ生成するために用いられる非公開キーを有するアルゴリズムＤ＝ディジタル署名を暗号解読しかつチェックするために用いられる公開キーを有するアルゴリズム他のアプリケーションに応用される場合にノートＥ及びＤもまたそれぞれ暗号解読及び暗号化に用いられうる。主セキュリティサーバ１１８２、セキュリティサーバ１１８４、テラーマネーモジュール１１８８、マネー発生器モジュール１１９０、顧客サービスモジュール１１９２、及び取引マネーモジュール１１８６は、番号を真偽についてチェックすることができるように識別番号（ｉｄ’ｓ）が割り当てられている。４８− ビット素数“ｐ”が発生されかつプリミティブルート“ａ”モジュロｐ（ここで、全ての１≦ｎ＜ｐ−１に対してａⁿ≠１（ｐ）が安全な処理を介して見出される。ａ及びｐの両方は、それらが製造される場合に主セキュリティサーバによって安全にシステムの全てのモジュールにロードされる。スキームは、次に示すように作用する：ａⁿ≡ｍ（ｐ）でありかつ（１）１≦ｍ≦９９，９９９であれば、ｎは、主セキュリティサーバのｉｄとして割り当てられ、（２）１００，０００≦ｍ≦９９９，９９９であれば、ｎは、セキュリティサーバのｉｄとして割り当てられ、（３）１，０００，０００≦ｍ≦６，９９９，９９９であれば、ｎは、テラーマネーモジュールのｉｄとして割り当てられ、（４）７，０００，０００≦ｍ≦９，９９９，９９９であれば、ｎは、テラーマネー発生器モジュールのｉｄとして割り当てられ、（５）１０，０００，０００≦ｍ≦１１，９９９，９９９であれば、ｎは、顧客サービスモジュールのｉｄとして割り当てられ、（６）ｍ≧１２，０００，０００であれば、ｎは、取引マネーモジュールのｉｄとして割り当てられる。モジュールまたはサーバが証明を有効化しているならば、それは、ａⁿ≡ｍ（ｐ）を計算することによって識別番号（例えば、Ｍ（ｉｄ）、ＳＳ（ｉｄ）、またはＰＳＳ（ｉｄ））ｎの真偽をチェックしそしてｍが正しい範囲にあるかどうかをチェックする。セキュリティネットワーク図２に示すように、セキュリティネットワーク１１９６及びセキュリティＬＡＮ１１９４は、セキュリティサーバ１１８４を主セキュリティサーバ１１８２に接続する。セキュリティサーバ１１８４は、製造においてマネーモジュール及び顧客サービスモジュール１１９２を最初に証明する。そのようなセキュリティサーバは、モジュール製造ＬＡＮ１２０２に接続できる。それらは、不良ｉｄ一覧表及び主セキュリティサーバの一覧表並びにそれらの公開キー（パブリックキー）のようなセキュリティ情報をモジュールにパスする。不良ｉｄ一覧表は、マネーモジュール、顧客サーバモジュール、及び取引から阻止されるセキュリティサーバの識別を包含する。これらのモジュールの証明更新は、ネットワークサイン−オンフロー図に続いて記述される。セキュリティサーバ１１８４は、製造において主セキュリティサーバ１１８２によって最初に証明される。そのような主セキュリティサーバは、セキュリティサーバ製造ＬＡＮ１２０４に接続できる。図１Ｂを参照すると、セキュリティサーバ１１８４は、それらが他のモジュールにパスする種々のセキュリティ情報を受取る。セキュリティサーバは、それらが更新されたセキュリティ情報をパスするネットワークサイン−オンのような、ＥＭＳネットワーク１１９８及び銀行ＬＡＮｓ１２００に対するセキュリティサービスを供給する。セキュリティサーバ１１８４は、セキュリティネットワーク１１９６にわたり主セキュリティサーバ１１８２からこの情報を受取る。取引マネーモジュール１１８６は、ネットワークサーバ１２０６（ＮＳ）を介してＥＭＳネットワーク１１９８と通信する。参加銀行は、テラーマネーモジュール１１８８そしてたぶんそれらのＬＡＮｓ１２００に接続されたマネー発生器１１９０を有する。セキュリティネットワーク１１９６は、リンク暗号化される。更に、主セキュリティサーバ及びセキュリティサーバは、共通対称キー（セキュリティネットワーク暗号化キー）を共有する。このキーは、公開キー、キー交換により指定された主サーバ１１８２によって周期的に変更される。不良ｉｄ’ｓの一覧表は、指定された主サーバ１１８２によって維持される。一覧表は、参加銀行、法の執務管轄庁、及びシステムへの加入者との対話から累積される。周期的にセキュリティサーバ及びモジュールに対する公開キーの長さは、変更される。キーの長さは、高いセキュリティレベルを維持するために通常長くされる。新しく指定されたキーの長さは、指定された主サーバによって主セキュリティサーバに通信される。新しい長さは、不要ｉｄ一覧表が送られる場合または証明更新により主サーバによってセキュリティサーバと通信される。セキュリティの危険な違反の場合には、主セキュリティサーバは、汎用証明更新を呼出すことができる。各主サーバに対する公開キーの長さは、変わらない。主セキュリティサーバの実行及び撤去を計画するタイムテーブルが生成される。新しいサーバは、増加した取引量によりそれらが実行されない限りより長いキーを有するであろう。アクティブＰＳＳ公開キーの一覧表は、主セキュリティサーバによって生成されかつその非公開キー（プライベートキー）を有するサーバによってサインされる。一覧表は、次いで、他のセキュリティサーバに放送される。図３Ａは、セキュリティサーバ１１８４の機能コンポーネントを示す。外部インターフェイス機能１２０８は、ネットワークインターフェイシングに対する通信層を供給する。セッションマネージャ機能１２１０は、取引セッションのセキュリティ形態を制御する。ネットワークサイン−オン機能１２１２は、ネットワークサイン−オンに対するセキュリティ機能を管理する。生成証明機能１２１４は、あらゆるマネーモジュールに対する証明を証明する（主セキュリティサーバでは、この機能は、セキュリティサーバを証明する）。分配証明となるキー機能１２１８は、有効主セキュリティサーバ公開キーの証明エージェンシーの一覧表をマネーモジュールに分配する（主セキュリティサーバは、また、汎用証明更新メッセージも分配する）。制御不良ＩＤ一覧表機能１２２０は、不良識別子の一覧表を制御しかつ分配する。同期日付／時間機能１２２２は、システム時間に同期されたマネーモジュールクロック／タイマサービスを保持する。クロック／タイマ１２２４及び暗号化機能１２２６は、マネーモジュールにおけるそれらの機能と同じである。図３Ｂは、ネットワークサーバ１２０６の機能的コンポーネントを示す。外部インターフェイス機能１２２８は、ネットワークインターフェイシングに対する通信層を供給する。通信セッションマネージャ機能１２３０は、マネーモジュール間、及びマネーモジュールとセキュリティサーバの間の通信セッションを管理する。ネットワークサイン−オン機能１２３２は、マネーモジュールネットワークサイン−オン処理を制御する。ルートメッセージ機能１２３４は、ルーティングメッセージに対するディレクトリサービスを供給し、サイン−オンの間中及びマネーモジュールセッションの間中メッセージルーティングを制御する。直接対銀行サービス機能１２３６は、参加銀行によって供給されたサービスに情報を供給する。暗号化機能１２３８は、対称キー機能１２４０及び乱数発生器機能１２４２を供給する。対称キー機能１２４０は、ネットワークサーバ１２０６とネットワークをアクセスしているモジュールの間、及びネットワークサーバ１２０６とセキュリティサーバ１１８４の間でメッセージを暗号化する。乱数発生器機能１２４２は、暗号化キー及び有効化メッセージに対する乱数を発生する。本発明によれば、別の安全処理コンポーネント、顧客サービスモジュール（ＣＳＭ）１１９２が採り入れられるのが好ましい。ＣＳＭは、口座プロフィールを生成しかつ更新するために用いられるいたずらされない（不正操作防止）装置である。ＣＳＭｓは、マネーモジュール及びセキュリティサーバにおいて見出されたような独自の証明を包含する。ＣＳＭｓは、他のモジュール（例えば、セキュリティサーバ）を有する安全セッションを確立するこができる。ＣＭＳは、顧客サービス代理及びオン−ライン銀行組織へのインターフェイスのためにホストを必要とする。ＣＳＭは、二つの主機能を有する。第１に、ＣＭＳは、マネーモジュールが銀行口座をアクセスし、銀行口座へのマネーモジュールリンクを再有効化し、かつ口座番号を有効化することができるように口座プロフィールを生成する。これらの取引は、図１８〜２０を参照して以下により完全に記述される。第２に、ＣＭＳは、ホスト顧客サービス代理からの要求に応じて紛失ノードを請求すべく機能し、それらは、図２１及び図２２にさらに詳しく記述される。ＣＭＳは、マネーモジュールと同じセキュリティ機能及びその識別子に対する番号の特別な範囲を有する（“Module Numbering Scheme ”を参照）。ＣＳＭによるこれらの機能の性能は、テラーモジュールに対する有効化口座番号処理を簡略化する。ＣＳＭを採り入れるＥＭＳの実施例によれば、各銀行に対する口座プロフィール構成は、に変わる。ここで、Ｍ（ｉｄ）＝モジュール識別子Ｂ（ｉｄ）＝銀行識別子ＬＡ＝口座番号及び口座の型（預金またはローン）の一覧表 σ_csm＝ＣＳＭの署名Ｃｅｒｔ（ＣＳＭ）＝（ＣＳＭ）の証明 ‖＝連鎖である。そのようなプロフィールに対する有効化手順は、図２０を参照して以下に記述する。図４Ａは、顧客サービスモジュール（ＣＳＭ）１１９２の機能的コンポーネントを示す。外部インターフェイス３０００は、顧客サービスモジュールホスト（ＣＳＭＨ）プロセッサ内の他の処理及び通信手段にＣＳＭをインターフェイスする；セッションマネージャ３００１は、ＣＳＭと取引マネーモジュールまたは顧客サービス代理の間の取引セッションを制御及びコミット（即ち、最終的に決定する）、または中止すべく作動する。生成口座プロフィール機能３００２は、マネーモジュールに加入者の異なる銀行口座をアクセスさせる口座プロフィールを顧客口座情報から構築する。公開キー機能は、銀行口座プロフィールを証明しかつサインする。ＣＭＳが顧客サービス代理及びオン−ライン銀行組織にインターフェイスするためにホストを必要とするので対ホスト機能３００６は、ＣＳＭアプリケーションとホストアプリケーションの間のデューティの分離を調停する。請求紛失ノート機能３００８は、ＣＳＭが有効化しかつ発行銀行に分配する加入者紛失ノート請求に応答する。維持セキュリティ機能３００４は、偽造マネーモジュールの一覧表を管理し、証明に適用し、クロックを同期し、かつ新しいディジタルキーの生成を管理する。クロック／タイマ３０１２及び暗号化機能３０１０は、マネーモジュールにおけるそれらの機能と同じである。図４Ｂは、主セキュリティサーバ１１８２の機能的コンポーネントを示す。外部インターフェイス機能３０２０は、ネットワークインターフェイシングに対する通信層を供給する。セッションマネージャ機能３００２は、それらが偽造されうるように扱われる、セキュリティサーバで、及び他の主セキュリティサーバでセッションのセキュリティ形態を制御する。生成証明機能３０２４は、あらゆるセキュリティサーバに対する証明を生成する。分配証明となるキー機能３０２６は、証明エージェントの有効主セキュリティサーバ公開キーの一覧表をセキュリティサーバに分配する。分配セキュリティネットワークキー機能３０３２は、主セキュリティサーバの間でセキュリティネットワークキーを管理しかつセキュリティサーバに分配する。セット汎用証明更新機能３０３０は、汎用証明更新が要求されるかどうかを決定し(例えば、セキュリティの危険な不履行により)、かつ必要と思われる場合に汎用証明更新を呼出す。分配不良ＩＤ一覧表機能３０２８は、不良識別子の一覧表を制御しかつ分配する。クロック／タイマ３０３４及び暗号化機能３０３６は、マネーモジュールにおけるそれらの機能と同じである。ネットワークサイン−オンネットワークサイン−オン手順の概観は、図５を参照して供給される。サイン −オンプロトコルは、モジュール１２４３が再証明、預金、引出し、または他の理由に対するＥＭＳネットワーク１１９８へのアクセスを所望する情況を記述する。モジュール１２４３は、取引マネーモジュール１１８６、テラーマネーモジュール１１３８、マネー発生器モジュール１１８８、または顧客サービスモジュール１１９２でありうる。（ａ）モジュール１２４３とネットワークサーバ１２０６の間に通信を確立する。（ｂ）モジュールの証明をネットワークサーバ１２０６へパスする。（ｃ）ネットワークサーバ１２０６は、乱数有効化番号Ｖ及び乱数キーＫを発生する；ネットワークサーバは、次いで、モジュールの証明、Ｖ、及びＫを、セキュリティサーバ１１８４へパスする（ＮＳ／ＳＳキーによって暗号化される）。（ｄ）モジュール１２４３及びセキュリティサーバ１１８４は、（セッションキー（ＭＭ／ＳＳ）を介して）安全通信セッションを確立する。（ｅ）セキュリティサーバ１１８４は、時間／日付、更新不要ＩＤ一覧表、主セキュリティサーバ公開キーの更新一覧表、公開キーの長さ、汎用再証明（必要ならば）、及び再証明されたモジュール証明（必要ならば）をパスする。(ｆ)モジュール１２４３を有するセッションを終了しかつＶ及びＫをモジュール１２４３へ送る。（ｇ）ＫでＶを暗号化しかつネットワークサーバ１２０６へ送る。(ｈ) ネットワークサーバ１２０６は、モジュール１２４３へネットワークサイン−オンを肯定応答する。（ｉ）モジュール１２４３は、それが接続されることを望む宛先（もしあれば）のネットワークサーバ１２０６を次いで報告する。（ｊ）ネットワークサーバ１２０６は、宛先への接続を確立する。ネットワークサイン−オンは、だれもモジュール１２４３をだますかまたは明文のその情報のいずれかを妨害することができないように設計される。図６は、ネットワークサイン−オン手順の詳細のフローを記述する。通信Ａは、ＥＭＳネットワーク１１９８との通信を確立する（ステップ１２４４）。維持セキュリティＡは、その証明をネットワークサーバ１２０６へ送る（ステップ１２４６）。ＮＳネットワークサイン−オンは、証明を受取る（ステップ１２４８）。ＮＳ乱数発生器は、乱数キーＫ及び乱数有効化番号Ｖを発生する（ステップ１２５０）。ＮＳ対称キーは、ＮＳ／ＳＳキーでモジュールの証明、Ｋ及びＶを暗号化する（ステップ１２５２）。ＮＳ／ＳＳキーは、ネットワークサイン−オンに対して通信するネットワークサーバ１２０６及びセキュリティサーバ１１８４に設置された局所対称キーである。ＮＳネットワークサイン−オンは、証明、Ｋ及びＶをセキュリティサーバ１１８４へ送り、そこでＳＳネットワークサイン−オンは、メッセージを受取りかつＳＳ対称キーは、メッセージを暗号解読する（ステップ１２５４−１２５８）。ＳＳネットワークサイン−オンは、Ｋ及びＶを記憶してモジュール証明を有効化のためにＳＳ公開キーへ送る（ステップ１２６０−１２６４）。再証明の可能性を許容するために、ＳＳ公開キーは、モジュール証明の有効化を決定することにおいて満了日を考慮しない。モジュール証明が有効でなければ、ＳＳネットワークサイン−オンは、ネットワークサーバ１２０６及びモジュール１２４３への伝送に対するアクセスを否定するためにメッセージを生成する(ステップ１２６６)。ＳＳ公開キーは、モジュールの公開キーでモジュール１２４３へのメッセージを暗号化しかつＳＳセッションマネージャは、ネットワークサーバへメッセージを送る（ステップ１２６８ −１２７０）。ＮＳネットワークサイン−オンは、メッセージを受取りかつアクセスが否定されたことに気付く。暗号化されたメッセージは、次いでモジュールへ送られ、かつネットワークサーバは、切断する（ステップ１２７２）。セッションマネージャＡは、メッセージを受取り、公開キーＡは、メッセージを暗号解読し、かつセッションマネージャＡは、サイン−オンが否定されたということに気付く（ステップ１２７４−１２７８）。サイン−オンを要求している装置が取引マネージャモジュールであれば、対加入者Ａは、加入者に報告する（ステップ１２８０−１２８２）。さもなければ、対銀行Ａは、銀行に報告する（ステップ１２８４）。他方、モジュールの証明が有効であれば、ＳＳ制御不良ＩＤ一覧表は、モジュールのｉｄが不良ｉｄ一覧表にあるかどうかをチェックする（ステップ１２８６ −１２８８）。ｉｄが一覧表にあれば、ネットワークアクセスは、否定される。さもなければ、ＳＳ乱数番号発生器は、乱数Ｒ及び有効化メッセージを生成する（ステップ１２９０）。ＳＳネットワークサイン−オンは、Ｒ及びＡ’ｓの公開キーを用いてＳＳ公開キーによって暗号化されるメッセージにおける有効化メッセージをアセンブルする。公開キーＡは、また、セキュリティサーバの証明を付加することによってこの暗号化されたメッセージを増大する（ステップ１２９２ −１２９４）。メッセージは、公開キーＡがメッセージを暗号解読しかつセキュリティサーバの証明を有効化するところのＡに送られる（ステップ１２９８）。証明が無効であれば、Ａは、セッション終了に気付きかつ加入者または銀行のいずれかに報告する（ステップ１３０４−１３０６）。証明が有効であれば、維持セキュリティＡは、セキュリティサーバのｉｄが不良ｉｄ一覧表にあるどうかをチェックする（ステップ１３０８−１３１０）。一覧表にあれば、セッションは、終了される（ステップ１３００−１３０６）。一覧表になければ、乱数発生器Ａは、乱数Ｒ（Ａ）を生成する（ステップ１３１２）。維持セキュリティＡは、操作Ｒ（Ａ）ＸＯＲＲによってセッションキー（ＭＭ／ＳＳ）を形成しそしてセッションキーを記憶する（ステップ１３１４）。有効化メッセージ及びＲ（Ａ）を含んでいるメッセージは、アセンブルされかつセキュリティサーバの公開キーで暗号化される(ステップ１３１６)。セッションマネージャＡは、メッセージをＳＳネットワークサイン−オンへ送りかつＳＳ公開キーは、メッセージを暗号解読する（ステップ１３１８−１３２２）。ＳＳネットワークサイン−オンは、有効化メッセージがそれが生成されたものであるということを有効化する（ステップ１３２４−１３２６）。そうでなければ、セキュリティサーバは、ネットワークアクセスを否定する。有効化メッセージが正しければ、ＳＳ対称キーは、Ｒ（Ａ）ＸＯＲＲによってセッションキー（ＭＭ／ＳＳ）を形成する（ステップ１３２８）。ＳＳセッションマネージャは、セッションの開始に気付きかつセンドメッセージサブルーチンによって肯定応答をＡに送る（ステップ１３３０−１３３２）。セッションマネージャＡは、肯定応答を受取りかつセッションの開始に気付く（ステップ１３３４）。クロック／タイマＡは、時間及び日付を、それをセキュリティサーバに送るセッションマネージャに送る（ステップ１３３６−１３４０）。ＳＳ同期日付／時間は、時間及び日付を受取りかつそれがパラメータ内であるかどうかをチェックする（ステップ１３４２−１３４４）。パラメータ内でなければ、ＳＳ同期日付／時間は、新しい時間及び日付をセッションマネージャＡに送る（ステップ１３４６−１３５０）。チェック／タイマＡは、次いで時間及び日付を調整する（ステップ１３５２）。Ａは、次いでその日付及び時間を再チェックのためにセキュリティサーバに再送付する。クロック同期がセット回数よりも多く試みられたならば、クロック障害は、加入者または銀行へ報告され、もし望ましいならば再試みされうる（ステップ１３５４−１３６２）。しかしながら、時間及び日付がパラメータ内であれば、ＳＳネットワークサイン−オンは、不良ｉｄ一覧表、主セキュリティサーバ公開キー（分配証明となるキー機能からくる）の新しい一覧表、及び公開キーの長さ(公開キーの大きさは、周期的に変化する)を含んでいるメッセージをアセンブリする(ステップ１３６４)。ＳＳ生成証明は、汎用再証明が呼出されたかどうかをチェックし、かつ汎用再証明に対する期間が満了していないことを確実にする（ステップ１３６６− １３６８）。そのような期間は、全ての証明が再証明されるかまたは満了するように十分に長くなければならない。機能は、また、それが汎用再証明の期間中に証明されたならば、再証明の必要がないので、モジュールが最後に再証明された場合をチェックすべきである。再証明が必要であれば、ＳＳ生成証明が先のメッセージに加えられる：モジュールは、再証明すべきである（ステップ１３７０）。そして、再証明が呼出されたかどうか、ＳＳ公開キーは、メッセージをサインする（ステップ１３７２）。メッセージは、公開キーＡがメッセージ上のディジタル署名をチェックするところのＡに送られる（ステップ１３７４−１３７８）。署名が無効であれば、セッションは、終了される。維持セキュリティＡは、次いで、その不良ｉｄ一覧表、公開キー一覧表、及びキーの長さを更新する（ステップ１３８２）。モジュールＡは、次いで（汎用再証明オーダーによるかまたは期限切れ証明によるかのいずれかにより）その証明が再証明されることを必要とするかどうかをチェックする（ステップ１３８４−１３８６）。新しい証明が要求されるならば、維持セキュリティＡは、新しい証明の発生を始める（ステップ１３８８）。公開キーＡは、新しいキーを発生しかつその古い非公開キーで新しい公開キーにサインする（ステップ１３９０）。セッションマネージャＡは、サインした新しい公開キーをセキュリティサーバのＳＳ証明に送る（ステップ１３９２−１３９６）。次いで、ＳＳ公開キーは、新しい公開キー上の署名を有効化する（ステップ１３９８−１４００）。有効な署名でないならば、セキュリティサーバは、ネットワークアクセスを否定する。署名が有効ならば、ＳＳ公開キーは、モジュールの新しい証明にサインしかつそれをモジュールに送る（ステップ１４０２）。セッションマネージャＡは、証明を受取り、維持セッションＡは、証明を有効化することを引受け、かつ公開キーＡは、署名を有効化する（ステップ１４０４−１４１０）。証明が有効でないならば、セッションマネージャＡは、センドメッセージ機能によって“証明無効”メッセージ及び証明をセキュリティサーバへ送る（ステップ１４１２−１４１３）。ＳＳネットワークサイン−オンは、メッセージを受取りかつＳＳ公開キーは、署名を有効化する（ステップ１４１４−１４１８）。セキュリティサーバは、証明が実際に有効であるということを決定したならば、それは、ネットワークへのモジュールアクセスを否定する。しかしながら、証明が無効であれば、ＳＳセキュリティマネージャは、それがネットワークから切断されるということをネットワークサーバに報告する（ステップ１４２０）。ＮＳネットワークサイン−オンは、障害をモジュールに報告する（ステップ１４２２）。モジュールは、次いで再試みに対して加入者または銀行に照会する（ステップ１４２４−１４３２）。他方、モジュールがその新しい証明が有効であるということを決定したならば、セッションマネージャＡは、肯定応答をセキュリティサーバに送る（ステップ１４３４）。同様に、新しい証明が要求されないならば、維持セキュリティＡは、肯定応答メッセージをセキュリティサーバに送る(ステップ１４３６−１４３８)。いずれの場合においても、ＳＳセッションマネージャは、肯定応答を受取りかつモジュールでそのセッションの終りに気付く(ステップ１４４０)。ＳＳネットワークサイン−オンは、次いでＫ及びＶをＡに送る(ステップ１４４２−１４４４)。セッションマネージャＡは、メッセージを受取りかつ対称キーＡは、Ｖ及びＫを有する宛先を暗号化しかつメッセージをネットワークサーバへ送る（ステップ１４４６−１４４８）。ＮＳネットワークサイン−オンは、メッセージを受取りかつＮＳ対称キーは、メッセージを暗号解読しかつＶがそれが先に生成したものと同じＶであるかどうかをチェックする（ステップ１４５０−１４５４）。Ｖが正しくないならば、ＮＳネットワークサイン−オンは、アクセス否定メッセージをＡに送りそして切断する（ステップ１４５６−１４５８）。Ｖが正しいならば、ＮＳネットワークサイン−オンは、宛先へのリンクを確立しかつ肯定応答をＡに送る（ステップ１４６０）。そして、セッションマネージャＡは、肯定応答を受取りかつＡがＥＭＳネットワーク１１９８にサイン−オンされたということに気付く（ステップ１４６２）。セッション確立図７はセッションプロトコールを示す。セキュリテイ維持Ａはセッションマネージャーへモジュール有効化を送り、そしてセッションマネージャーＡはその有効化を受け、そしてマネーモジュールＡがネットワークへ接続されているか、否かを調べる（ステップ１４６４−１４６６）。もしマネーモジュールＡがネットワークへ接続されていないと、セッションマネージャーＡはセキュリテイ維持Ａから受けた有効化を行き先Ｂへ送る（ステップ１４７６）。又は、もしマネーモジュールＡがネットワークへ接続されていると、対称キーＡは有効化をＫで暗号に書き直し、そしてセッションマネージャーＡはその暗号に書き直した有効化をネットワークサーバーへ送る（ステップ１４６８− １４７２）。ネットワークサーバーはＫでその有効化を解読し、そしてその有効化を行き先Ｂへ送る。有効化を送ったのがネットワークサーバーであろうと、セッションマネージャーＡであろうと、そのことに係わりなくセッションマネージャーＢはその有効化を受取、そしてセキュリテイ維持Ｂがその有効化を有効とする（もしＢがセキュリテイサーバーであれば、そのときはこの機能はセッションマネージャーにより遂行される）（ステップ１４８０−１４８２）。もし有効化が有効でなければ、そのときはセッションマネージャーＢは、セッションが終了したことを確認し、そしてサブスクライバーもしくは銀行のどちらかに知らせる（ステップ１４８６ −１４９２）（もしＢがセキュリテイサーバーであると、そのときはＢはその取引が終了したことを確認するだけである）。もし有効化が有効であれば、そのときはセキュリテイ維持Ｂは、Ａが不良ｉｄリストに載っているか、否かを調べる。もしもＡが不良ｉｄリストに載っていると、そのときはセッションを終了する。もしもＡが不良ｉｄリストに載っていないと、そのときは乱数ジェネレータＢが乱数Ｒ（Ｂ）とＢ有効化メッセージとをつくる（ステップ１４９８）。クロックタイマーＢは日時を回収する（ステップ１５００）。セキュリテイ維持ＢはＲ（Ｂ）、Ｂ有効化メッセージそして日時をメッセージに組み立てる（ステップ１５０２）。パブリックキーＢはメッセージをＡのパブリックキーで暗号に書き直し、そしてセッションマネージャーＢはＢの有効化を暗号に書き直したメッセージへ加え、そしてそのメッセージをＡへ送る（ステップ１５０４−１５０６）。セッションマネージャーＡはそのメッセージを受け、パブリックキーＡはそのメッセージの暗号に書き直した部分を解読し、そしてセキュリテイ維持ＡはＢの有効化を有効とする(ステップ１５０８−１５１４)。もし有効化が有効でなければ、そのときはセッションマネージャーＡはセッションの終了を確認して、サブスクライバーもしくは銀行のどちらかに知らせる(ステップ１５１６−１５２２) 。もし有効化が有効であると、そのときはセキュリテイ維持ＡはＢが不良ｉｄリストに載っているか、否かを調べる（ステップ１５２４−１５２６）。もしもＢが不良ｉｄリストに載っていると、そのときはセッションを終わらせる。もしＢが不良ｉｄリストに載っていないと、そのときはセキュリテイ維持Ａが日時を回収し、そしてそれをＢの日時と比較する（ステップ１５２８−１５３０）。もしも日時が範囲外であると、そのときはセッションを終わらせる。もしも日時が範囲内であると、そのときは乱数ジェネレータＡは乱数Ｒ（Ａ）と有効化メッセージとをつくる（ステップ１５３２）。その場合セキュリテイ維持ＡはＲ（Ａ）ＸＯＲＲ（Ｂ）の演算によりセッションキーを形成する（ステップ１５３４）。Ａ有効化メッセージ、Ｂ有効化メッセージ、日時そしてＲ(Ａ) がメッセージとして組み立てられ、そしてＢのパブリックキーで暗号に書き直す（ステップ１５３６）。メッセージはセッションマネージャーＡによりＢへ送られる（ステップ１５３８）。セッションマネージャーＢはメッセージを受け、パブリックキーＢがそのメッセージを暗号に書換え、そしてセキュリテイ維持ＢがＢ有効化メッセージを調べる（ステップ１５４０−１５４６）。もしもＢ有効化メッセージが不正確であると、セッションを終了させる。もしもＢ有効化メッセージが正確であると、セキュリテイ維持ＢはＲ（Ａ）ＸＯＲＲ（Ｂ）によりセッションキーを形成する（ステップ１５４８）。日時を回収し、そしてＡの日時と比較してその日時がそれぞれの既定の範囲内にあるか、否かを調べる。もしも日時が範囲外であると、そのときはセッションを終わらせ、その場合セッションマネージャーＢはセッションの開始を確認する（ステップ１５５２）。セッションマネージャーＢは確認とＡ有効化メッセージとをＡへ送る（ステップ１５５４−１５５６）。セッションマネージャーＡはメッセージを受け取り、そしてセキュリテイ維持ＡはＡ有効化メッセージを調べる（ステップ１５５８− １５６２）。もし有効化メッセージが正しくないと、セッションを終わらせる。もし有効化メッセージが正しいと、セッションマネージャーＡはセッションの開始を確認する（ステップ１５６４）。ノート移転図８はノート移転プロトコールを示す。ノートディレクトリーＸは移転のノートと価値とを選択し、ノート額とシーケンス番号とを更新し、それからメッセージをノートへ送る（ステップ１５６６）。移転のためのノートを選択するときに生じることのある目的は、（１）ディジタル署名の数（これは処理時間を必要とする）の最小化、（２）パケットの寸法の最小化、（３）移転しているサブスクライバーへ残っている電子ノートの有効性を最大化する（すなわち満期までに残されている最短時間でノートをパスする）ことである。このような目的は以下のノート移転アルゴリズムにより達成される。（１）最小数のノートを含むすべてのあり得る選択肢を決定し、（２）これらの選択肢のどれが最小数の移転を有するかを決定し、（３）一つよりも多い選択がステップ２から残されていると、最小数の金融単位日を有しているものを選ぶ。金融単位日とは移転しようとするノートの残存価値とノートの満期まで残されている日数との積の、そのパケット内の総てのノートについての集計である。ノートディレクトリＸからのメッセージを受けたときノートＸは、移転されている各ノートへ加えようとする移転をつくる（ステップ１５６８）。パブリックキーＸはノートのための署名をつくる（ステップ１５７０）。その場合、パケットマネージャーＸはそのノートと新規の移転とを組み合わせてパケットとし、そのパケットをＹへ送る（ステップ１５７２−１５７４）。パケットマネージャーＹはパケットを受取り、そしてそれを分解する（ステップ１５７６）。Ｙ有効化はノートにおけるすべての有効化を有効とする（例えば、マネージェネレータ有効化とすべての移転有効化）。その場合、移転グループ内の認識番号が、電子ノートの履歴にわたっての署名と有効化とのグループにおける有効化のモジュール認識番号と一致することを有効化Ｙは確認する。また、電子ノートの履歴を通して次々の移転で移される額が直前の移転の額よりも少ないことを確実にすることにより各ノートの移転額の一致性を有効としている。加えて、移転された全額を調べてそれが予期された額であることを保証する（ステップ１５７８ −１５８０）。もしも無効であると、そのときは移転は行われない（ステップ１５８２）。もし有効で、そしてＹが取引マネーモジュールであると、そのときは有効化Ｙはノートの満期を有効化する（ステップ１５８４−１５８８）。ノートの何れかが満期となっていると、そのときはその取引は行われない。もしいずれも満期となっていないと、そのときは有効化Ｙは不良ｉｄリストでそのノートのトランスファーの個別のｉｄを調べる（ステップ１５９０−１５９２）。もし何れかのノートのトランスファーの個別のｉｄが不良ｉｄリストに載っていれば、そのときは取引は行われない。もしトランスファーのｉｄが不良リストに載っていなければ（もしくはＹが取引マネーモジュールでないと）、そのときはパブリックキーＹはノートの照明の有効性を有効化する(ステップ１５９４−１５９６)。もしも署名のうちのどれかが有効でないと、その取引は行われない。もし署名が有効であると、そのときはノートアプリケーションにより蓄積されている、もしくはトランログに入っているノートボディーとそのノートボディーが一致するかを有効化Ｙが調べる（ステップ１５９８−１６００）。一致しているノートボディー毎にノート移転ツリーをつくって、ノート複製があったか、なかったかを決定する（ステップ１６０２ −１６０４）。もしもノートのどれかが複製されていると、そのときは取引は行われない（すなわち、ステップ１６０２−１６０４）。この複製チェック（すなわち、ステップ１５９８−１６０４）は、偽造取引マネーモジュールを使用する「自己取引」によりノートを移すことによりマネーをつくろうとする個人の行為を阻止する。複製がない、もしくはノートボディーの一致が認識されないと、そのときはノートＹはノートをマネーホルダー内に置く（ステップ１６０６）。最後に、ノートディレクトリＹはノートの位置と額とを更新し、そしてシーケンス番号を初期化する（ステップ１６０８）。移転ノートプロセスはノートの調停を容易とするためシーケンス番号を更新し、そして初期化するステップを含み（「イッシュしたマネーの調停」参照）、いずれかのノートのトランスファリーが不良ｉｄリストに載っているかどうかを調べ、そしてノート複製を調べる。これらの追加の特徴とステップとは、複製されたノートを当事者が導入し、循環させ、そして循環している複製ノートを検出する能力を高めるのを困難としている。外国為替ドルとポンドとを例としての貨幣単位として使用する外国為替取引のプロトコールを図９に示す。最初、＄／£の為替レートでポンド（£）をドル（＆）に変えることをＡはＢと契約する。その場合、ＡとＢとは彼らのマネーモジュールに署名し、そしてモジュールは取引のそのタイプに対し加入者を誘導する（ステップ１６０４−１６１０）。Ａは外国為替を買うことを選択し、そしてＢは外国為替を売ることを選択する。ＡとＢは安全な取引セッションを確立する（ステップ１６１６−１６２０）。対加入者Ａは、彼が交換を望んでいるドルのノートのタイプによる額をＡの所有者／所持者に督促する（ステップ１６２２）。支払い／交換Ａはその額を受取り、そしてノートダイレクトリーＡはＡが十分なファンドを有しているか、否かを調べる（ステップ１６２４−１６２８）。もしファンドが十分でないと、そのときは対加入者Ａは、既存のファンドに対して再びチェックされる新規な額を督促する（ステップ１６３０−１６３２）。もし新規の額が入れられなければ、そのときは取引は行われない（ステップ１６３４）。もしファンドが十分であると、そのときは支払い／交換Ａはドルの額をＢへ送る（ステップ１６３６−１６３８）。その場合対加入者Ｂは、ドルに対して彼が交換を望んでいるポンドの額を選択してＢの所有者／所持者を督促するか、もしくはドルに対する交換レートだけを促す（ステップ１６４０）。ノートダイレクトリＢは十分なファンドについてチェックする（ステップ１６４２−１６４４）。もしファンドが不十分であると、そのときは対加入者Ｂは新しいレートを督促し、そして再び既存のファンドが十分かをチェックする（ステップ１４４６−１６４８）。しかしながら、新しいレートが選択されないと、そのときは支払い／交換ＢがＡにそれのファンドが不十分であることを知らせる（ステップ１６５０ −１６５２）。Ａは交換の新しい額を選択するか、もしくは取引を中止する（ステップ１６３０−１６３４）。Ｂが取引に十分なファンドを有していると、そのときは支払い／交換ＢはＡに確認と、交換しようとするポンドの額とを送る（均等レートも送る）（ステップ１６５４−１６５６）。対加入者Ａはポンドの額とレートの有効化を督促する（ステップ１６５８−１６６０）。もし額とレートとが不正確であると、そのときは、支払い／交換ＡはＢに、その額とレートとは不正確であることを告げる（ステップ１６６２−１６６４）。対加入者Ｂは新しいレートを督促する（ステップ１６６６−１６６８）。もし新しいレートが選ばれないと、そのときは取引は行われない（ステップ１６７０）。もしＡが取引の正確な額とレートとを有効化すると、そのときは、支払い／交換Ａはドル額をマネーホルダーに渡す（ステップ１６７２）。ドルのノートはＡからＢへ移される（ステップ１６７４）。支払い／交換Ｂはポンドをそれのマネーホルダーへ渡す（ステップ１６７６）。ポンドのノートはＢからＡへ移される（ステップ１６７８）。取引のこの点でＡとＢとの両方が正確な外国為替ノートを仮に保持している。ＡとＢとはそれぞれが２つの取引に酸化している。Ａの取引では、（１）ＡがドルをＢに移転し、（２）ＡはＢからポンドを受け取る。Ｂの取引では、（１）ＢがドルをＡに移転し、（２）ＢはＡからドルを受け取る。外国為替取引を完結するにはＡはそれの２つの移転を両方とも今コミットしなければならない（すなわち、終わりにして、取引ログに永久に記録する）。同様に、Ｂもそれの２つの移転を両方とも今コミットしなければならない。Ａは外国為替取引Ａ→Ｂ（ＡからＢへドル）をコミットし、そして別に、外国為替取引Ｂ→Ａ（ＢからＡへポンド）をコミットしてもよいことに注意されたい。同様にＢは外国為替取引Ａ→Ｂを、そして別に、外国為替取引Ｂ→Ａをコミットしてもよい。外国為替プロトコールの次の部分は、当事者のどちらも取引マネーモジュールがコミットする順序を知らないように設計されている。このような不確かさは当事者が取引で不正を意図的に働こうとするのを断念させる。背景として、ファンクションＳ（Ｘ）は、Ｓ（０）＝Ａ、そしてＳ（１）＝Ｂとなるように決められている。ここでＡとＢとはマネーモジュールＡとＢを言うものとする。こうして、もしＸが０もしくは１にランダムに選択されると、マネーモジュールＡとＢはランダムに指示される。以下のルーチンを使って、ＡとＢとが共通にランダムＸを確立する。Ｒ（Ａ）とＲ（Ｂ）とはセッション確立サブルーチン中ＡとＢとにより発生された乱数である。Ｒ（Ａ）ＸＯＲＲ（Ｂ）のパリテイは、（Ｒ（Ａ）ＸＯＲＲ(Ｂ) の各ビットをエクスクルーシヴ−オアすることにより）決定される。このパリテイは乱数Ｘである。Ｘ’はＸのコンリメントである（Ｘ’＝ＸＸＯＲ１）。図９を参照する。トランログＡは条件付きでそれの取引ログを更新してＳ(Ｘ) からＳ（Ｘ’）への移転を記録する（ステップ１６８０）。もしＸを計算して０となると、そのときはＡからＢへの移転（すなわち、ドル移転）が条件付きで記録される。もしＸを計算して１となると、そのときはＢからＡへの移転（すなわち、ポンド移転）が条件付きで記録される。ログは条件付きで記録されるので、多くのマネーモジュールＡが取引を中止する事態ではそれはロールバックされる。更新ログは、（流れ図に説明されているように、もしくはコミット中に暗黙で）ログ更新が一度無条件に設定されると永久となる。そのとき、セッションマネージャーＡは「ログ更新」メッセージをＢへ送る（ステップ１６８２−１６８４）。応答して、トランログＢも条件付きでそれのログを更新し、Ｓ（Ｘ）からＳ（Ｘ’）への移転を記録する（ステップ１６８６）。もしＸ＝１であると、トランログＢはログ更新を無条件へセットする（ステップ１６８８−１６９０）。こうして、この点でＢはＡへのそれのポンドの移転をコミットする。次に、Ｂは図１０を参照して説明するコミットプロトコールに従う（ステップ１６９２）。この状態で、Ａはそれの移転の両方にコミットし（すなわち、ドルを移転し、そしてポンドを受ける）、そしてＢは一つの未処理の（コミットされていない）移転、すなわちドル受領をコミットする。もしＸ＝０であると（ステップ１６８８）、セッションマネージャーＢは「コミット開始」メッセージをＡへ送る（ステップ１６９４−１６９６）。そのとき、ログＡはそれのログ更新を無条件に設定し（ステップ１６９８）、それのドル移転をコミットする。図１０のコミットプロトコールが読みだされる（ステップ１７００）。このプロトコール（後述する）中、Ｂはそれの両方の移転（すなわち、ポンドを移転し、ドルを受領する）をコミットし、そしてＡはそれの未処理の移転、ポンド受領をコミットする。理解されるように、Ｆ／Ｘ取引はノートの各移転をコミットし、ノートが複製されないようにし、そのような複製はコミットがただ一回だけだと起きることがえる。外国為替プロトコールは、誰の移転（ＡのドルもしくはＢのポンド）が最初コミットされるかは当事者のどちらも知らない。このことが取引で不正を働こうという気持ちを当事者に持たせないようにする。それぞれの移転が別個にコミットされるが、コミットの順序が２つのモジュールによりでたらめに選ばれる。取引に干渉しようとする第３者は金を失う確率は５０−５０である。また、その失われた金の返還を主張できるのでコミットに干渉しようという気持ちにはならない（紛失マネーの請求参照）。コミット図１０は、モジュールのためのコミットプロトコルを示している。セッションマネージャＸは、レディーコミットメッセージをＹへ送る（ステップ１７０２− １７０４）。これにより、コミットオブリゲーションがそのメッセージを受信するモジュールへ通される。通常のマネー移転シナリオにおいては、コミット義務を通すこの方法は、先ず、マネー複製の可能性を排除するように最初にマネーを移転する当事者がコミットすることを保証するために、使用される。それから、セッションマネージャＹは、確認をＸへ送り（ステップ１７０６− １７０８）、その取引きログを更新することによって、未済の取引きをコミットする（ステップ１７１０）。また、もし、Ｙが取引きマネーモジュールであるならば、対加入者Ｙは、その加入者に、取引きがうまくいったことを通知する（ステップ１７１２−１７１４）。セッションマネージャＹは、セッションの終りを確認する（ステップ１７１６）。取引きログＸは、Ｙから確認を受信し、その取引きログを更新し、未済の移転をコミットする。Ｘは、Ｙと同じようにしてそのコミットを完了する（ステップ１７１８−１７２４）。取引き中止図１１は、モジュールのための取引き中止プロトコルを示している。セッションマネージャＸは、変化をロールバックして、その取引きが中止されることを確認する（ステップ１７２６）。それから、セッションマネージャＸは、コミットレディーメッセージが送られたかをチェックする（ステップ１７２８−１７３０）。もし、そうならば、Ｘは、コミットレディーメッセージを送った後に中止されたＸを記録し且つノート移転プロトコル中に受信された各ノートの額およびノート識別子を記録することによって、その取引きログを更新する（ステップ１７３２）。このようにして、中止プロトコルは、失敗コミットサブルーチン中に中止サブルーチンが呼び出される時の情報を記録する。もし、Ｘが取引きマネーモジュール１１８６であり、コミットレディーメッセージが送られた場合には、対加入者Ｘは、その加入者に、その取引きが中止されたこと、およびマネー移転エラーがあったかもしれないことを知らせる（ステップ１７３４−１７３８）。もし、Ｘが出納マネーモジュール１１８８であるならば、対銀行Ｘは、その銀行に、その勘定取引きをリバースすべきこと（適当なデビットおよびクレジットによって）を知らせる（ステップ１７４０−１７４２）。もし、Ｘが取引きマネーモジュール１１８６であり、コミットレディーメッセージが送られていない場合には、対加入者Ｘは、その加入者に、その取引きが中止されたことを知らせる（ステップ１７４４）。いずれの場合においても、セッションマネージャＸは、Ｙに、その取引きが完了され得ないことを示すメッセージを送る（ステップ１７４６−１７４８）。セッションマネージャＹは、その変化をロールバックし、その取引きが中止されたことを確認する（ステップ１７５０）。それから、Ｙは、その加入者に、その取引きが中止されたことを知らせる（ステップ１７５２−１７５４）か、または、その銀行に、その勘定取引きをリバースすべきことを知らせる（ステップ１７５６−１７５８）。前述したように、もし、コミットプロトコル中に取引きが中止される場合には、ノートが紛失する可能性がある。もし、このようなことが起こる場合には、移転先が中止したのに対して、移転元がノートの移転をコミットしたというようなことがありうる。この場合において、移転先マネーモジュールは、受信すべきであったノートについての情報を記録し、その加入者に、問題がありうること（すなわち、Ａによって送られたノートを受信していなかったというようなこと）を知らせる。このような状況において、移転元マネーモジュールに関する限り、この移転元マネーモジュールは、正しくノートを移転したということが考えられる。移転先マネーモジュール加入者は、そのマネーについてのクレイムを有効化エージェンシーに対してなすことができる。クレイム情報は、失敗した取引きのログ記録を含む。有効化エージェンシーは、ノートが折り合いがついたかを知るために発行銀行でチェックすることができる。ある時間期間の後、もし、ノートが折り合いがついていない場合には、加入者は、自分のマネーをリクレイムすることができる。ＰＯＳ支払い図１２は、販売時点（ＰＯＳ）支払いプロトコルを示している。ＰＯＳ支払いプロトコルは、買手の取引きマネーモジュール１１８６と売手の取引きマネーモジュール１１８６との間で行われる支払いを簡単化しようとしているものである。売手の取引きマネーモジュール１１８６は、例えば、スーパーマーケットのキャッシュレジスタに配置されうる。最初に、Ａは、Ｂから物品またはサービスを購入することに同意する（ステップ１７６０）。取引きマネーモジュールＡの所有者／所持者は、自分のマネーモジュールにサイン−オンする（ステップ１７６２）。対加入者Ａは、その所有者／所持者に取引きを督促し、Ａは、ＰＯＳ支払いすることを選択する（ステップ１７６４−１７６６）。一方、売手は、総購入価格を決定する（ステップ１７６８）。対加入者Ｂは、取引きを督促し、Ｂは、ＰＯＳ支払いを受けることを選択する（ステップ１７７０−１７７２）。ＡおよびＢは、保証セッションを確立する（ステップ１７７４−１７７６）。対加入者Ｂは、支払い額を督促し、支払い／交換Ｂは、その額を受信し、それをＡへ送る（ステップ１７７８−１７８２）。それから、対加入者Ａは、その加入者に要求額を検証することを督促する（ステップ１７８４−１７８６）。さらにまた、加入者は、総額が要求額に等しくなるようにどのノートで（例えば、通貨またはクレジットで）どれくらいの額を支払うかを選択するように要求される。もし、要求額が正しくない場合には、支払い／交換Ａは、Ｂに、要求額が正しくないことを示すメッセージを送る（ステップ１７８８−１７９０）。それから、対加入者Ｂは、そのホストに新しい額を督促する(ステップ１７９２−１７９４)。もし、新しい額が選択されない場合には、その取引きは中止される（ステップ１７９６）。もし、要求額が正しい場合には、支払い／交換Ａは、ノートのタイプによる額を受信する（ステップ１７９８）。それから、ノートディレクトリＡは、充分なファンドかについてチェックする（ステップ１８００−１８０２）。もし、ファンドが不足である場合には、対加入者Ａは、ノートのタイプによる新しい額を督促する（ステップ１８０４−１８０６）。もし、新しい額が入力されない場合には、支払い／交換Ａは、Ｂに、それがファンド不足であることを示すメッセージを送る（ステップ１８０８、１７９０）。対加入者Ｂは、ホストに新しい額を督促する（ステップ１７９２−１７９４）。もし、新しい額が選択されない場合には、その取引きは中止される（ステップ１７９６）。もし、新しい額が選択される場合には、その支払い取引きが再開される。もし、ファンドが充分である場合には、支払い／交換Ａは、その額をマネーホルダーへ通す（ステップ１８１０）。それから、ノートがＡからＢへ移転される（ステップ１８１２）。最後に、取引きマネーモジュールがコミットする（ステップ１８１４）。理解しうるように、ＰＯＳ支払いは、買手に対して簡単化される。何故ならば、それが被支払い人始動支払いであるからである。一般的に、ＰＯＳ支払いは、商品についての売手に対する支払いのために使用されるのに対して、加入者対加入者（ＳＴＳ）支払いは、各顧客支払い、または手形支払いのために使用される。発行銀行からのクレジットの更新図１３は、発行銀行取引きクレジット更新プロトコルを示しており、特に、加入者が予め許可されたクレジット支払い媒体であるクレジットノートを如何にして取得するかを記述している。加入者は、その加入者が所有する各クレジット勘定口座について１つまでのクレジットノートを保有しうる。加入者に更新クレジットノートを受信しうるようにするどの銀行もそれらのクレジットノートについて発行銀行である。クレジット更新取引きをセットアップするプロセスの流れは、マネーモジュールＡと銀行の出納マネーモジュールＢとの間のクレジットセットアッププロセスで始まり（ステップ１８５４）、それについては、図１４を参照して以下に説明する。クレジットセットアップクレジット引出しセットアッププロセスは、取引きマネーモジュールＡの所有者／所持者がクレジット更新をなすことを決定し、自分のマネーモジュールにサイン−オンするときに始まる（ステップ１８７６）。例えば、加入者Ａは、クレジットノートを所有するが、そのクレジット額を、ゼロまで減少させることを含めて変更（例えば、増大または減少）することを望むかもしれないし、または、現在、クレジットノートを所有していないが、１つのクレジットノートを取得することを望むかもしれない。対加入者Ａは、その所有者／所持者に取引きを督促し、Ａは、特定の銀行および勘定口座からの特定の額のクレジット更新をなすことを選択する（ステップ１８７８−１８８０）。この実施において、加入者によって指定されたクレジット額は、加入者Ａが保有したい総クレジット額である。それから、取引きマネーモジュールＡは、前述したネットワークサイン−オン手順を通してそのネットワークにつなぐことにより、選択された銀行と通信するための手順を開始する（ステップ１８８２）。マネーモジュールサイン−オン、取引き選択およびネットワークサイン−オンのステップが完了した後、ＡおよびＢは、保証セッションを確立する（ステップ１８８４）。それから、取引きマネーモジュールＡは、図１５に関してより充分に説明されるクレジット要求手順にしたがって、出納マネーモジュールＢからクレジット要求をなす（ステップ１８８６）。クレジット要求図１５を参照して、クレジットを要求するプロセスについて説明する。図はＸおよびＹを当事者として示しているが、後述するプロセスステップにおいて、それらは、出納マネーモジュールと取り引きするどのマネーモジュールにも適用されうる。開始するのに、もし、選択された勘定口座に対するクレジットノートがある場合には、ノートディレクトリＸは、このクレジットノートの額を対出納Ｘへ送る（ステップ１８９７）。対出納Ｘは、加入者Ａによって要求された総クレジット額とそのクレジットノート額との間の正味の差を決定し、クレジット更新要求を出納マネーモジュールへ送り、クレジットの特定の正味額が特定の勘定口座から許可されるように要求する。更新クレジット要求のその送信において、勘定口座番号および勘定プロファイルが、正味クレジット額と共に、要求マネーモジュールから出納マネーモジュールへと送信される（ステップ１８９８）。このメッセージは、メッセージ送出プロトコルに従って送出される（ステップ１９００）。そのメッセージ送出プロトコルにおいては、そのメッセージは、記述した暗号化法を使用して暗号化される。クレジット引出し要求および勘定口座番号およびプロファイルが出納マネーモジュールへ送信されるとき、勘定口座番号を確証する手順が開始される（ステップ１９０２）。勘定口座番号が如何にして確証されるかを示すフロー図を図２０に示している。これについては、説明を簡単化するために以下に別に説明する。勘定情報が確証された場合には、対銀行Ｙは、クレジット更新要求額を支持するに充分なクレジットがあることを検証する（ステップ１９０４）。充分なクレジットの場合には、対取り引きＹに、確認をＸへ送ることを督促する。Ｘは、その対出納アプリケーションファンクションを通して確認を受信する（ステップ１９０６−１９１２）。しかしながら、クレジットの額が不足であると、加入者に、そのクレジット更新についての新しい額を入力するように督促する（ステップ１９１４−１９１８、図１５Ｂ参照）。加入者によってクレジット更新についての新しい額が入力されると、その結果として、対出納アプリケーションが、最近の要求額をカバーするに充分なファンドがあるかを知るために、その新しいクレジット額をその出納マネーモジュールの対銀行アプリケーションへ送り(ステップ１９２２−１９２４)、図１５Ａのステップ１９０４に戻る。もし、新しい額が加入者によって要求されない場合には、その取引きは、中止される（ステップ１９２６）。図１４を参照するに、クレジット引出し要求プロセスから戻るとき、対出納Ａは、その勘定についての総通貨ノート、移転クレジットノート（すなわち、前の取引きにおいて受信されたクレジットノート）およびクレジットノートのその出納マネーモジュールへの移転を発動する(ステップ１８８８)。もし、クレジット引出し要求がなされたときに取引きマネーモジュールにノートが保持されていない場合には、対出納マネーモジュールＡアプリケーションは、ノートがないことを示すメッセージを出納マネーモジュールに送る(ステップ１８９２−１８９４) 。しかしながら、もし、取引きマネーモジュールにノートが保持されている場合には、図８に関して前述したノート移転手順にしたがって、電子ノートが、Ａから出納Ｂへと移転される（ステップ１８９６）。図１３に戻って、対取引きＢは、通貨ノートおよび移転クレジットノートが移転されたかをチェックし（ステップ１８５６−１８５８）、そして、ノートのこれらのタイプのいずれかが実際に取引きマネーモジュールＡから移転された場合には、勘定取引きが対銀行アプリケーションＢによってこの状態を反映するために掲示されるウステップ１８６０）。マネーモジュールからノートが移転されなかった場合にも、ステップ１８６０において勘定取引きが掲示された後においても、出納マネーモジュールとマネージェネレータモジュールとの間にセッションが確立される（ステップ１８６２）。対銀行Ｂは、利用しうる総クレジットを得るためにクレジットの利用しうるラインにそのクレジットの額（もし、あるならば）を加え、その利用しうる総クレジットからその要求されたクレジット額を差し引くことにより、そのクレジットラインを更新する。もし、要求クレジット額がゼロであり且つ通貨ノートが移転されていないために、ノート（通貨ノートおよびクレジットノートを含む）を作成すべきでない場合には、マネーモジュールは、図１０に関して前述したコミット手順にしたがってその取引きを完了させる（ステップ１８６５−１８７５）。しかしながら、もし、非ゼロクレジット額および／または移転通貨ノートのために、いずれかのノート（クレジットまたは通貨）を作成すべき場合には、ノート要求手順にしたがってマネージェネレータモジュールから出納Ｂによってノートが要求される（ステップ１８６５−１８６６）。マネージェネレータモジュールにおける要求ノートは、電子ノートを移転するための前述したノート移転プロセス（図８参照）を使用して出納マネーモジュールＢへ移転される（ステップ１８６８）。それから、ノートが、同じノート移転プロセスを使用して、出納マネーモジュールＢから取引きマネーモジュールへと移転される（ステップ１８７０）。最後に、クレジット更新手順を首尾良く完了させるために、マネーモジュールは、図１０に関して前述したコミット手順にしたがってその取引きを完了させる。そのコミット手順は、先ず、その取引きを出納マネーモジュールＢとコミットする取引きマネーモジュールによって開始させられる（ステップ１８７２）。それから、そのコミットプロセスは、出納マネーモジュールＢとマネージェネレータモジュールとの間で実行される（ステップ１８７４）。これにより、発行銀行からの１つの完全なクレジット更新の処理が完了させられる。発行マネーの一致ノート一致のプロセスは、ノートの偽造と複製をチェックし、図１６と図１７を参照して記述する。発行マネー一致システムは、発行マネーマスターファイルに記憶された情報に基づき、ノートの移転履歴を表すノート移転ツリーを構成する。図１６は、識別子番号「１」を有するマネー発生モジュール（マネー発生器１という）と、識別子番号「２」を有するテラーモジュール（テラーモジュール２という）と、整数の識別子番号３から６を有する４つの取引マネーモジュール（取引モジュール３−６という）との間の、マネー発生器１が1:00:00 で示す日／時間に発生した１つのノートに関連する仮定の一連の取引を図式的に表す。図１６に示す移転履歴の例に関連して、図１７は通貨の電子表示の移転により、マネー発生モジュールにより生じた初期のノートから誘導されて通貨の電子表示のツリー状構造がどのように生じるかを示す。ノートの個々の移転（ツリーブランチの一部）がノートの更新に従って預金されるかバンキングシステムに戻ると、図１７のノート移転ツリーが発行マネー一致システムにより作られる。この例では、マネー発生器１（モジュール識別子はディジタル署名した証明内に含まれる）は、データフィールドの本体グループとデータフィールドの移転グループとを有する通貨の電子表示2300を生じる。この説明を明確にするため一部を図式的に示す。さらに、便宜上データフィールドの署名及び証明グループは示さない。データフィールドの本体グループは、ノート識別子（例えば、「Ｎ１２」）と、マネー発生器モジュール識別子（例えば、「ＭＧ１」）と、発行銀行識別子（例えば、「銀行名」）と、発行日（例えば、「1:00:00」）と、満了日（例えば、「12:00:00」）と、ノートの金額と通貨単位識別子（例えば、「＄５０」）を含む。ノートの種類等他の本体グループのデータフィールドは、便宜上示さない。電子ノートの色々のデータフィールドを例示のため日：時間：分の形式で示す。他の時間モニター形式（例えば秒を含む）ももちろん可能である。データフィールドの移転グループは、移転先識別番号と移転日と移転金額とを有する移転レコードを含む。移転グループは、個々の移転後に移転元のノートディレクトリによりインクリメントされるシーケンス番号を含むのが好ましい。通常、移転の日／時間と移転IDは、移転を独自のものと識別するのに十分である。しかし、移転間で時間調整され、同じ金額が同じモジュールに移転されるなら、移転、移転先ＩＤ、日／時間、及び金額は、２重にすることができる。従って、この潜在的な問題を避けるには、移転を独自のものと識別するため、シーケンス番号（ｓｅｑ）を移転レコードとノートディレクトリに加えるのが好ましい。シーケンス番号は、個々の移転後にノートディレクトリによりインクリメントされる。もし、シーケンス番号がリセットされると、これは複製であると検出されるであろう。従って、通貨の電子表示2300がテラーモジュル２に移転されると、移転レコード２３０２が移転グループに付加され、これは移転先識別番号(例えば、「２」) と、移転日（例えば、「1:00:00」）と、移転金額（例えば、「＄５０」）と、シーケンス番号（例えば、「１」）とを含む。例示の便宜のため、図１７に示すノートの移転は、移転されたノートの新しく付加された移転レコード部分のみを示す。また便宜上、移転の総数を示す移転グループデータフィールドは示さない。マネー発生器からの通貨の電子表示2300は、テラーモジュール２に記憶される。取引モジュール３による＄５０の引き出しの一部として、テラーモジュール２は、移転レコード２３０２により増加した通貨の電子表示のデータフィールドのコピーに移転レコード２３０４を付加することにより、通貨の電子表示を形成する。このノートは、引き出しの完了により、取引モジュール３に記憶される。ノート移転ツリーの個々のノードは、移転されたノートの新しく付加された移転レコードを示すことが分かるであろう。ノート移転ツリーにより表されるように、取引モジュールＴＲ３は、1:00:05 に、移転レコード２３０６により取引モジュール４に＄１０支払う。取引モジュール３は、1:01:00 に移転レコード2308により取引モジュール５に＄10支払う。取引モジュール３は、3:08:01 に移転レコード２３１０により取引モジュール５に＄２５支払う。取引モジュール３は、4:11:08 に移転レコード２３１２により取引モジュール６に＄５を移転する。取引モジュール４は、2:00:01 に移転レコード２３１４により取引モジュール６に＄５移転する。取引モジュール４は、2:01:07 に移転レコード２３１５により取引モジュール６に追加の＄５を移転し、取引モジュール６は次に、3:07:05 に移転レコード２３２１により取引モジュール３に＄５を移転する。取引モジュール５は、2:00:06 に移転レコード２３１６により取引モジュール３に＄１０のノート全体を移転する。取引モジュール５が、3:08:01 に取引モジュール３から受け取った＄２５のノートから、取引モジュール５は、3:09:12 に移転レコード２３１８により取引モジュール６に＄２０支払い、残りの＄５を4: 12:05 に移転レコード２３２０によりテラーモジュール２に預金する。取引モジュール６は、4:10:00 に移転レコード２３２２に従い取引モジュール５に＄１０を移転し、5:00:06 に移転レコード２３２４により取引モジュール３に残りの＄１０を移転する。本発明の実施例により、取引モジュールから銀行へマネーを預金すると、取引モジュール内の全てのノート（クレジットノートを含む）は、バンキングシステムに送られ更新されることが分かる。それ故、上述の移転レコード２３２０により表される取引モジュール５からテラーモジュール２への預金とほぼ同時に、移転レコード２３２６で表される追加で同時の移転が自動的に起こる。次に、＄５の価値を有する新しいノートが（取引モジュール３がクレジットノートを有さないと仮定する）、マネーモジュール１により発生し、適当な移転レコードを付加して（図示せず）テラーモジュール２を経由して取引モジュール３へ移転される。従って、取引モジュールとテラーモジュール間の取引（例えば、預金叉は引き出し）による取引マネーモジュール内の全てのノートを更新することは、ノートをバンキングシステムに戻すことに別の手段を提供することにより、ノート一致プロセスを容易にする。取引モジュール３は、5:00:10 に移転レコード2328により、テラーモジュール２に＄１０を預金する。取引モジュール５の預金について上述したように、移転レコード２３２８により表される取引モジュール３の預金と同時に、取引モジュール３が所有した全てのノート（移転レコード２３１６と移転レコード２３２１で表されるものを含む）のバンキングシステムへの追加で同時の移転(図示せず) が起こる。次に、バンキングシステムは、取引モジュール３に更新の為バンキングシステムに送られた合計のノート（例えば、＄１５）に等しい価値を有するノートを戻す。従って、この時点で、取引モジュール６のみが、移転ノート２３１２と２３１４で表されるように、当初のノート２３００の移転可能な形跡を所有する。もし、取引モジュール６が、これらのノートを他の移転マネーモジュールに移転する前に、テラーモジュールと取引（例えば、預金叉は引き出し）をすれば、当初のノート２３００に関連する移転可能なノートは流通していないことになる。当初のノート２３００の取引から派生する全てのノートは、バンキングシステムに戻され、図１７に示すようなノート移転ツリーの完全な構成ができる。満了日により、ノートが移転される時間を制限することで、ノートの一致が容易になる。ノート移転ツリーから、ノートが偽造されたら、預金された第１ピースにマッチするノート本体はないことが分かるであろう。もし、移転が複製されれば、後の移転は上位の移転金額より大きな値になるであろう。例えば、もし取引モジュール６が、5:00:06 に取引モジュール３に＄１０(即ち、移転レコード２３２４) の代わりに＄２０移転すると、移転レコード２３１８（即ち、ＳＥＱ１、3:09:1 2、ＴＲ６、＄２０）の下の移転は合計＄３０になり、取引モジュール６が移転を複製したことを示すであろう。銀行アクセスのため銀行口座にマネーモジュールをリンク図１８は、銀行にアクセスするため、銀行口座にマネーモジュールをリンクするプロトコルを示す。加入者が、顧客サービス代理（ＣＲＳ）に自分を明らかにし、ＣＲＳに加入者の口座をマネーモジュールへリンクすることを要請するとき、このプロセスが始まる（ステップ１９２８）。ＣＲＳは、識別された加入者の口座をリンクする要請をＣＳＭホストＡ(ＣＳＭＡ)に入れ、ＣＳＭＡは、バンキングシステムから識別された加入者の口座情報にアクセスする（ステップ１９３０−１９３４）。次に、加入者とＣＲＳが、口座情報を有効化し、加入者はどの口座をマネーモジュールにリンクさせるかを選択する（ステップ１９３６）。加入者が、自分のマネーモジュールＢを銀行口座にリンクすることを要請し、ＣＳＲがＣＳＭＨＡを通してＣＳＭＡが銀行口座にリンクすることを要請した後、加入者のマネーモジュールＢとＣＳＭＡの間で安全セッションが行われる（ステップ１９３８−１９４６）。次に、ＣＳＭＡのホストＡへからの要請に応じて、ＨＣＳＭＡは、口座情報をＣＳＭＡに送り、それは口座情報を受け取り、それから口座プロフィールを構成する（ステップ１９４８−１９５２）。次に、公開キーＡが口座プロフィールにサインし、口座プロフィール生成で、口座プロフィールからメッセージと署名を構成し、このメッセージをマネーモジュールＢに送る（ステップ１９５４−１９５８）。セキュリティ保持Ｂが、メッセージを受け取り、公開キーＢがメッセージのディジタル署名をチェックする（ステップ１９５８−１９６２）。もし、署名が無効であれば、このセッションは中止される（ステップ１９６６）。もし署名が有効であれば、加入者Ｂへは、顧客が口座プロフィールを有効化するため、プロフィールをホストに送る。もし、顧客が口座プロフィールを肯定しなければ、取引は中止される。もし、顧客が口座プロフィールを肯定すれば、セキュリティＢ保持は、口座プロフィールにＣＳＭ証明を追加する（ステップ１９６８）。次に、テラーＢへは、最近生じた（「新しい」）口座プロフィールに関連する口座プロフィールが既に銀行に記憶されているかを求めるチェックをする。もし、テラーＢへの適用の中に銀行の口座プロフィールが既に存在すれば、テラーＢへは新しい口座プロフィールに置き換える。そうでなければ、テラーＢへで新しい口座プロフィールを追加する（ステップ１９７０−１９７４）。マネーモジュールの銀行口座へのリンクの再確認図１９は、加入者がマネーモジュールのリンクを銀行口座に再確認するプロトコルを示す。加入者が自分のマネーモジュールにサインするときプロセスが始まり、加入者Ａへで生じる取引のプロンプトに応じて、加入者は、顧客サービスモジュール（ＣＳＭ）Ｂと関連する銀行への銀行口座リンクを再確認することを選択する（ステップ１９７８−１９８２）。マネーモジュールは、図６に関連して上述したネットワークのサイン−オンプロトコルを呼び出して実行し、マネーモジュールＡとＣＳＢＭの間で安全セッションが確立される（ステップ１９８６）。テラーＡへは、銀行口座の口座プロフィールをＣＳＢＭに送る（ステップ１９８８−１９９０）。口座プロフィールＢ生成はメッセージを受け取り、セキュリティＢ保持でＣＳＭ証明と口座プロフィールの署名を確認する（ステップ１９９２−１９９５）。もし、証明叉は署名が無効であれば、ＣＳＭは取引を中止する（ステップ２０００）。もし、証明が有効であれば、ホストＢへは口座プロフィールからの口座のリストをＣＳＭホスト（ＣＳＭＨ）に送り、それがオンラインのバンキングシステムで個々の口座が現在アクティブであるかを求める（ステップ１９９６−２００１）。口座のどれかが満了していれば、ＣＳＭＨはＣＳＭに中止メッセージを送信し（ステップ２０１０）、ＣＳＭは次に中止プロセスに従い取引を中止する（ステップ２０００）。もし全ての口座がアクティブなら、ＣＳＭＨはＣＳＭに再確認指示を送信し、口座プロフィールＢ生成でメッセージを受け取り、口座情報から口座プロフィールを構成する（ステップ２００２−２００４）。公開キーＢが口座プロフィールにサインし、口座プロフィールＢ生成で、口座プロフィールからのメッセージと署名を構成し、このメッセージをマネーモジュールＡに送る（ステップ２００６ −２０１０）。公開キーＡは、メッセージを受け取り、ディジタル署名を有効化する（ステップ２０１２）。もし署名が無効であれば、マネーモジュールＡは取引を中止する（ステップ２０１８）。もしそれが有効であれば、口座プロフィールにプロフィール署名とＣＳＭ証明が追加され（ステップ２０１４）、マネーモジュールＡは取引をコミットする（ステップ２０１６）。口座番号の確認上述した顧客サービスモジュール（ＣＳＭ）を使用する本発明の実施例に従って、どのように口座番号が確認されるかを示すフローチャートを図２０に示す。このプロセスで、セキュリティＹ保持が、口座番号とＣＳＭ証明を含む口座プロフィールを受け取り、ＣＳＭ証明を有効化する（ステップ２０２０）。無効な証明は、２つのマネーモジュールの間の取引を中止させる（ステップ２０２８）。もし、証明が有効であれば、セキュリティ保持Ｙで、ＣＳＭ署名を有効化するため、口座プロフィールを公開キーＹに伝達する（ステップ２０２２）。無効な署名は、セキュリティＹ保持でセッションマネージャーに口座プロフィールが無効であると通知させ（ステップ２０２６）、２つのマネーモジュールの間の取引は中止される（ステップ２０２８）。署名テストが、有効な署名であると確かめると、手順は銀行Ｙへに進み、そこで受け取った口座番号を銀行のオンラインコンピューターシステムに送る（ステップ２０２４）。アクティブでない口座は、セキュリティ保持Ｙがセッションマネージャーに活動していない口座を知らせるようにし（ステップ２０３０）、取引を中止させる（ステップ２０２８）。アクティブな口座は、口座番号の確認プロセスから口座番号確認プロセスを呼び出したオペレーションのフローの次のステップにリターンさせる。口座番号確認プロセスは、本発明の実施例と比較して、ＣＳＭを含まないテラーマネーモジュールでは簡単になっている。紛失マネーの請求前述したように、電子マネーは、（１）マネーモジュールが損傷し、もはや機能しない、（２）マネーモジュールを紛失したか叉は盗まれた、（３）コミットが失敗した等のいくつかの理由で紛失することがある。マネーシステムの有用性には、加入者が自分のマネーは無事であるとシステムを信頼できることが重要である。従って、移転先はシステムの故障で紛失したマネーを再度請求できることが重要である。電子的な故障は物理的損傷による紙の紛失より起こりそうなので、マネーモジュールが損傷したときマネーを置き換えられることが、信頼を改善する。マネーモジュールを紛失したか盗まれた災難によって、マネーを置き換えることは、より問題がある。このような請求を許すと、加入者が紛失に対して用心しなくなるので、システムに広い請求を招くことになる。どの場合も、本発明で具体化されるのは、これらのどの場合のマネー紛失でも置き換えられる方法である。最初の２つの場合（即ち上の場合（１）と（２））、加入者は周期的にマネーモジュールの外部に記憶できる紛失ノート請求を生成しなければならない（図２１参照）。故障すると、加入者の識別と共に発行銀行に請求を提出することができる（図２２参照）。請求は、加入者のマネーモジュールの最後の分かる状態を含むであろう。請求されたノートの記述は、確認され、発行銀行に配送することができる。発行銀行は、請求されたノートが預金されていなければ、ある期間の後マネーを置き換えることができる。コミットが失敗した場合（即ち上の場合（３））、マネーモジュールがまだ機能するなら、マネーモジュールと顧客サービスモジュールの間で請求が交互に生成される（図２２参照）。この請求は、場合（１）と（２）と同様に、発行マネー調査システムに渡され、それが預金されたマネーに対して請求をモニターする。発行銀行は、不正の適用に対して入ってくるマネーをモニターでき、志願者の識別を持っているので、信頼して紛失したマネーを置き換えることができる。これらの方法は、図２１と図２２を参照してより詳しく記述する。紛失ノート生成請求図２１Ａを参照すると、本発明の実施例に関連して実行できる紛失ノートの生成請求のプロセスが示される。加入者が、マネーモジュールにサイン−オンするときプロセスが開始し、加入者Ａへは加入者に取引をプロンプトし、加入者が紛失ノート生成請求のオプションを選択する（ステップ２０３２−２０３６）。次に、全てのノートと請求されない失敗コミットを統合するいくつかのステップが起こる（ステップ２０３８−２０４２）。特に、ノートディレクトリＡは、独自の請求シーケンス番号（請求を識別するのに使用する）を生成し、ノートディレクトリのコピーをシーケンス番号と共にパケットマネージャーに運ぶ。ノートＡは、全てのノートのコピーを署名と証明と共にパケットマネージャーに運ぶ。次に、ＴｒａｎＬｏｇＡは、中止プロセスの間に記録された全ての請求されない取引のコミットを失敗したものをパケットマネージャーに運ぶ。次に、公開キーＡが、マネーモジュール非公開キーを使用し、請求シーケンス番号と、ノートディレクトリと、ノートと、パケットマネージャーに送られた失敗コミットにサインし、パケットマネージャーＡは、アセンブルしたデータに署名を追加し、その結果アセンブルしたデータパケットになり（ステップ２０４４ −２０４６）、それが次に公開キーＡにより暗号化される（ステップ２０４８）。暗号化した請求に、公開キーＡは、請求シーケンス番号と、請求の合計金額の値と、マネーモジュールＡの識別とからなる請求記述を追加する（ステップ２０５０）。加入者Ａへは、この請求をマネーモジュールホストへ送り、それが請求を受け取り、将来の使用のため、マネーと独立の媒体上に請求を記憶する（ステップ２０５２−２０５４）。それ故、紛失ノート請求プロセスは、マネーモジュールの損傷叉は故障により破壊されない潜在的マネー請求を発生し保護する方法を提供することがわかる。紛失ノートの請求図２２は、紛失ノートを請求するプロトコルを示し、加入者が顧客サービス代理（ＣＳＲ）に紛失ノートの請求することを頼むとき、プロセスは始まり、加入者の識別がＣＳＲに明かされる（ステップ２０５６）。ＣＳＲは次に、加入者の識別を顧客サービスモジュールホスト（ＣＳＭＨ）Ａに伝達し、請求が失敗したコミットによるか、叉はマネーモジュールの紛失叉は破壊によるかをチェックする（ステップ２０５８−２０６０）。もし、失敗したコミットが請求の元であり（加入者のマネーモジュールは紛失も損傷もしていなければ）、加入者のマネーモジュールから紛失したノートの請求をするという選択と、ＣＳＲのマネーモジュールから紛失したノートの請求を受け入れるという選択により、加入者のマネーモジュールのセッションマネージャーＢと顧客サービスモジュール（ＣＳＭ）のセッションマネージャーＡは、顧客サービス代理と共に（顧客サービスモジュールホスト（ＨＣＳＭ））を通じて、それぞれ呼び出され、ＣＳＭＡとマネーモジュールＢの間で安全セッションを確立する（ステップ２０６２−２０７０）。いったん安全セッションが確立されると、ＣＳＭのホストＡへで、加入者の識別を求め、ＨＣＳＭＡが、加入者の識別を含むメッセージをＣＳＭに送ることにより、この請求に応答する（ステップ２０７２−２０７４）。紛失ノートＡ請求で、このメッセージを受け取り、請求を送るべきと指示するメッセージをマネーモジュールＢに送る（ステップ２０７６−２０７８）。ＴｒａｎＬｏｇＢが、このメッセージを受け取り、請求されていない失敗したコミットの記録を引き出す（ステップ２０８０）。失敗したコミットの記録がなければ、取引は中止される（ステップ２０８３）。そうでなければ、加入者Ｂへは、失敗コミットの記録から引き出された情報（即ち、データ、時間、金額）を加入者に再調査のため送る（ステップ２０８２）。この情報から、加入者は請求する取引を選択する（ステップ２０８４）。例えば加入者は、別に解決した失敗したコミット取引を選択しないであろう。次に、加入者が選択した個々の失敗したコミット取引のため、ＴｒａｎＬｏｇＢは、これらの取引の記録情報を含むメッセージを構成し、このメッセージをＣＳＭに送る（ステップ２０８６− ２０８８）。紛失ノート請求Ａは、このメッセージを受け取り、将来請求を参照するため請求の識別子（即ち、コンファメーション番号）を含む承認をＢに送る（ステップ２０９２）。ＴｒａｎＬｏｇＢは、承認を受け取り、個々の選択した失敗コミット取引記録に、請求の日／時間とＣＳＭにより提供された請求の識別子を記す（ステップ２０９４）。次に、Ｂは、取引をコミットする（ステップ２０９６）。コミットの手順が終了した後、失敗したコミット取引情報を含む受け取ったメッセージから、紛失ノート請求Ａは発行マネー調査システム（ＭＩＴＳ）に送る請求を構成する。ＭＩＴＳは、取引調査システムの一部を形成することが好ましい。ホストＡへで、この請求をＨＣＳＭＡに送り、それは請求を受け取り、さらに請求をＭＩＴＳに送る（ステップ２０９８−２１０２）。図２２のステップ２０６０に戻り、請求が失敗したコミットによる（即ち、紛失した又は損傷したマネーモジュールによる）のでなければ、加入者は、図２１を参照して前述した紛失ノート生成の請求のプロセスに従って、発生しマネーモジュール計算環境から（即ち、フラッシュメモリー上へ）外された加入者の請求のどれかにアクセスを有するホストＢからの紛失ノートを請求する選択をすることができる。ＣＳＲは、別にマネーモジュールホストからの紛失ノートの請求を受け取るプロセスを開始し、ホストは公知の技術に従ってコミュニケーションのリンクを設立する（ステップ２１０４−２１０８）。次に、加入者ホストＢが、マネーモジュール証明を含む請求をＣＳＭＨＡに送り、それは請求をＣＳＭＡに送る（ステップ２１０８−２１１２）。紛失ノート請求Ａは、請求を受け取り、請求を公開キーＡに送り、それがマネーモジュールの証明を再確認する（ステップ２１１４−２１１６）。もし、マネーモジュール証明が無効であれば、ホストＡへは、請求は拒絶されたことを示すメッセージをＣＳＭＨＡに送り、ＣＳＭＨＡはこのメッセージを加入者ホストＢに送り、紛失ノート請求プロセスは終了する（ステップ２１２０−２１２１）。もし、マネーモジュール証明が有効であれば、公開キーＡが請求を暗号化し、請求内の全てのノート証明と署名を有効化する（ステップ２１１８）。ノート証明と署名の何方かが有効でなければ、取引は終了する（ステップ２１１９− ２１２１）。ノート証明と署名が有効であれば、紛失ノート請求Ａは、移転金額の一致性を有効化し、個々のノートの移転履歴により、移転先に運ばれたマネーの値は移転元が受け取った値より大きくないことを保証する（ステップ２１２２ −２１２３）。もし一致しなければ、取引は終了する（ステップ２１２０−２１２１）。しかし、移転金額が全てのノートについて一致性があれば、紛失ノート請求Ａは、ＭＩＩＳへ送る請求を構成し、また請求に対応する請求の識別子を発生する。ホストＡへは、構成した請求と請求の識別子をＣＳＭＨＡへ送り、それが請求と請求の識別子を受け取り、請求の識別子を加入者ホストＢへ発送し、請求をＭＩＩＳへ送り（ステップ２１２４−２１２８）、従って紛失ノート請求プロセスを完了する。上述の記述は、多くの特性を与えるが、これらの実施可能な詳細は、本発明の範囲を制限すると解釈すべきでなく、本発明はこの範囲から離れずに又伴う利点をなくすことなく多くの改変、適応、均等な実行が可能であることが、当業者には分かるであろう。それゆえ、本発明は開示された実施例に制限されず、請求の範囲に従って定義される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ【要約の続き】ジュールにリンクしかつ紛失マネー請求を取り扱う顧客サービスモジュールを含む。

Claims

【特許請求の範囲】１．プロセッサベースド電子モジュールの間で電子ノートを移転するためのシステムにおいて、各々が暗号保証チャネルを形成することができ且つ該暗号保証チャネルを介して電子ノートを移転したり受信したりすることができ、且つ前記電子ノートを記憶するためのメモリを有しているプロセッサベースド電子モジュールを備えており、各記憶される電子ノートは、該電子ノートと関連した貨幣的価値を示すデータを含むデータフィールドのボディーグループと、移転記録のリストを含むデータフィールドの移転グループとを備えており、各移転記録は、移転元電子モジュールによって作成され、移転された電子ノートを、前記移転元電子モジュールから移転された他の移転された電子ノートから区別するシーケンス番号を含むことを特徴とするシステム。２．前記貨幣的価値は、前記電子ノートに関連した原始貨幣的価値であり、前記移転記録は、さらに、移転された貨幣的価値を含む請求項１記載のシステム。３．第１のマネーモジュールを使用してマネーの電子的表示を第２のマネーモジュールへと移転する支払い方法において、 (a) 前記第１のマネーモジュールと前記第２のマネーモジュールとの間に暗号保証セッションを確立し、ここで、前記第１および第２のマネーモジュールが改ざん防止モジュールであり、 (b) 前記第２のマネーモジュールが取引き条項について第２の加入者に督促し、該第２の加入者が取引き条項を前記第２のマネーモジュールへ供給するようにし、 (c) 前記第２のマネーモジュールが前記取引き条項を、前記暗号保証セッションを介して前記第１のマネーモジュールへと送るようにし、 (d) 前記第１のマネーモジュールが前記取引き条項を検証するように第１の加入者に督促し、前記第１の加入者が前記取引き条項の検証を供給するようにし、 (e) 前記第１のマネーモジュールが前記マネーの電子的表示を前記暗号保証セッションを介して前記第２のマネーモジュールへ移転するようにし、 (f) 前記第１のマネーモジュールが前記電子マネート移転をロギングすることによって前記電子マネー移転を行い、該第１のマネーモジュールがその状態をローリングバックすることによってもはや前記電子マネー移転を中止し得ないようにし、 (g) 前記第２のマネーモジュールが前記電子マネー移転をロギングすることによって前記電子マネー移転を行い、前記第２のマネーモジュールがその状態をローリングバックすることによってもはや前記電子マネー移転を中止し得ないようにする、ことを特徴とする支払い方法。４．前記トランザクション条項は、前記マネーの電子的表示の貨幣的額を含み、前記第１の加入者が検証を供給する段階は、前記貨幣的額のクレジットと通貨との間での割り振りを指定することを含む請求項３記載の支払い方法。５．プロセッサベースド電子モジュールの間で電子ノートを移転するための方法において、移転元電子モジュールと移転先電子モジュールとの間に暗号保証セッションを確立し、前記移転元電子モジュールに記憶される電子ノートに、前記電子ノートの貨幣的額のすべて、またはある部分が移転されているかを示す移転記録を付加することにより移転電子ノートを作成し、前記移転電子ノートを前記移転元電子モジュールから前記移転先電子モジュールへと移転し、前記移転記録は、前記移転電子ノートを、前記移転元電子モジュールからの別の移転電子ノートと区別するシーケンス番号を含むことを特徴とする方法。６．電子モジュールをセキュリティサーバへリンクするネットワークサーバを有する電子マネーシステムネットワークへサインオンするための方法において、前記電子モジュールがその認証を前記ネットワークサーバへ送り、前記ネットワークサーバがランダムキーおよびランダム検証番号を発生し、該認証、前記ランダムキーおよび前記ランダム検証番号を含む暗号化メッセージを前記セキュリティサーバへと送り、前記セキュリティサーバが前記暗号化メッセージを解読し、前記ランダムキーおよびランダム検証番号を記憶し、前記認証の正当性を検証し、前記セキュリティサーバが前記電子モジュールとの保証通信セッションを確立し、前記セキュリティサーバが該セキュリティサーバの暗号キーによってディジタル的にサインされた更新セキュリティ情報を前記電子モジュールへと送り、前記電子モジュールが前記ディジタル的にサインされた更新セキュリティ情報の正当性を検証し、前記更新セキュリティ情報で記憶されているセキュリティ情報を更新し、前記セキュリティサーバが前記ランダムキーおよび前記ランダム検証番号を前記電子モジュールへと送り、前記保証通信セッションを終了させ、前記電子モジュールが前記ランダムキーで前記ランダム検証番号および行き先を暗号化することにより行き先メッセージを作成し、該行き先メッセージを前記ネットワークサーバへ送り、前記ネットワークサーバが前記メッセージを解読し前記ランダム検証番号を検証し、前記ネットワークサーバが前記行き先に対するリンクを確立する、ことを特徴とする方法。７．前記電子モジュールは、取引きモジュール、顧客サービスモジュール、マネージェネレータモジュール、または出納モジュールである請求項６記載の方法。８．前記電子モジュールがその日付および時間情報を前記セキュリティサーバへ送り、前記セキュリティサーバが前記日付および時間情報をチェックしてそれが所定の許容パラメータ外であるかを判定し、前記日付および時間情報が前記所定の許容パラメータ外である場合には、前記セキュリティサーバが前記電子モジュールを同期化するために新しい日付および時間を前記電子モジュールへ送る請求項６記載の方法。９．前記ネットワークサーバと前記セキュリティサーバとの間の前記暗号化メッセージは、前記ネットワークサーバおよび前記セキュリティサーバに記憶されたローカル対称キーを使用して与えられる請求項６記載の方法。 10．前記更新セキュリティ情報は、不良電子モジュールの更新リスト、更新パブリックキーおよび更新キー長さを含む請求項１０記載の方法。 11．前記セキュリティサーバが前記電子モジュールとの保証通信セッションを確立する段階は、前記セキュリティサーバおよび前記電子モジュールに共通なセッションキーを与えるためのパブリックキー交換プロトコルを含む請求項６記載の方法。 12．前記セキュリティサーバが前記認証を再認証する段階をさらに含む請求項６記載の方法。 13．前記再認証する段階は、前記セキュリティサーバが再認証要求メッセージを前記電子モジュールへ送ることに応答して行われる請求項１２記載の方法。 14．前記認証は、期限切れ時間を含み、前記再認証する段階は、前記認証が期限切れしたことを前記電子モジュールが判定することに応答して行われる請求項１２記載の方法。 15．電子モジュールベースドマネー取引きシステムにおいて、一次セキュリティサーバと、各々が前記一次セキュリティサーバによってディジタル的にサインされた独特なセキュリティサーバ認証を有している複数の二次セキュリティサーバと、各々が前記二次セキュリティサーバのうちの一つによってディジタル的にサインされた独特なモジュール認証、マネーの電子的表示を記憶するメモリおよび前記マネーの電子的表示を移転したり受信したりするための暗号保証チャネルを与えるようにするプロセッサを有する複数の改ざん防止電子モジュールとを備えており、前記セキュリティサーバ認証は、前記二次セキュリティサーバが前記電子モジュールまたは前記一次セキュリティサーバと相互動作するときに確証され、前記モジュール認証は、前記電子モジュールが他の電子モジュールまたは前記セキュリティサーバと相互動作するときに確証されることを特徴とするシステム。 16．前記モジュール認証および前記セキュリティサーバ認証は、期限切れ時間を有しており、前記電子モジュールは、期限切れした認証を有する他の電子モジュールまたは二次セキュリティサーバとは取引きしないようになっている請求項１５記載のシステム。 17．前記複数の電子モジュールの各々、前記一次セキュリティサーバおよび前記複数の二次セキュリティサーバの各々は、サーバのタイプまたは電子モジュールのタイプを示す独特な識別子を有する請求項１５記載のシステム。 18．前記電子モジュールのタイプは、取引きモジュール、顧客サービスモジュール、マネージェネレータモジュールおよび出納モジュールを含み、前記サーバのタイプは、前記一次セキュリティサーバおよび前記二次セキュリティサーバを含む請求項１７記載のシステム。 19．前記サーバのタイプの各々および前記電子モジュールのタイプの各々は、タイプ変数の独特な範囲と関連付けられており、前記独特な識別子の各々は、前記電子モジュールの各々、前記二次サーバの各々および前記一次サーバに安全に記憶されたマッピング機構によって前記サーバのタイプまたは電子モジュールのタイプに割り当てられた前記独特な範囲内の前記タイプ変数のある値にマッピングされる請求項１７記載のシステム。 20．前記独特な識別子の各々は、所定の素数より小さい独特な整数値であり、前記タイプ変数の前記値は、前記所定の素数に関するモジュロ算術のもとで前記素数の一次根を前記独特な識別子の羃乗することにより発生され、前記複数の電子モジュールの各々、前記一次セキュリティサーバおよび前記複数の二次セキュリティサーバの各々は、前記一次根および前記素数を安全に記憶する請求項１９記載のシステム。 21．前記一次セキュリティサーバは、不良電子モジュールおよび不良二次セキュリティサーバのための前記独特な識別子のリストを維持し、前記リストは、前記副セキュリティサーバおよび前記電子モジュールへ与えられる請求項１５記載のシステム。 22．前記セキュリティサーバ認証は、前記一次セキュリティサーバによって暗号化され、前記モジュール認証は、前記二次セキュリティサーバによって暗号化されている請求項１５記載のシステム。 23．前記セキュリティサーバ認証は、前記一次セキュリティサーバのプライベートキーで暗号化された第１および第２のデータフィールドを備えており、前記第１のデータフィールドは、前記二次セキュリティサーバの独特な識別子、前記セキュリティサーバのパブリックキーおよび前記セキュリティサーバ認証の期限切れ時間を含み、前記第２のデータフィールドは、前記一次セキュリティサーバによってディジタル的にサインされた前記第１のデータフィールドを含み、前記セキュリティサーバ認証は、さらに、前記一次セキュリティサーバの独特な識別子を含む第３のデータフィールドを備える請求項２２記載のシステム。 24．前記一次セキュリティサーバの前記独特な識別子は、暗号化されている請求項２３記載のシステム。 25．前記モジュール認証は、二次セキュリティサーバのプライベートキーで暗号化された第１および第２のデータフィールドを備えており、前記第１のデータフィールドは、前記電子モジュールの独特な識別子、前記電子モジュールのパブリックキーおよび前記モジュール認証の期限切れ日付を含み、前記第２のデータフィールドは、前記二次セキュリティサーバによってディジタル的にサインされた前記第１のデータフィールドを含み、前記モジュール認証は、さらに、前記セキュリティサーバ認証を含む第３のデータフィールドを備える請求項２２記載のシステム。 26．前記一次セキュリティサーバおよび前記二次セキュリティサーバは、パブリックキーキー変換を使用して周期的に変化される共通の対称キーを共用する請求項１５記載のシステム。 27．前記一次セキュリティサーバは、前記セキュリティサーバ認証および前記モジュール認証についてグローバル再認証を選択的にコマンドする請求項１５記載のシステム。 28．第１のマネーモジュールを使用してマネーの電子的表示を第２のマネーモジュールへ移転する支払い方法において、前記第１のマネーモジュールと前記第２のマネーモジュールとの間に暗号保証セッションを確立し、ここで、前記第１および第２のマネーモジュールは改ざん防止電子モジュールであり、前記第１のマネーモジュールが前記暗号保証セッションを介してマネーの電子的表示を前記第２のマネーモジュールへと移転し、前記第２のマネーモジュールがコミットレディーメッセージを前記第１のマネーモジュールへ送り、前記第１のマネーモジュールが前記コミットレディーメッセージに応答して確認を送り、それから、前記第１のマネーモジュールがその状態をローリングバックすることによって前記電子マネー移転をもはや中止し得ないように前記電子マネー移転を行い、前記第２のマネーモジュールが前記確認を受信後、その状態をローリングバックすることによって前記電子マネー移転をもはや中止し得ないように行う、ことを特徴とする支払い方法。 29．前記マネーモジュールの各々は、該マネーモジュールにプログラムされた中止ルーチンに従うことにより、前記移転を行う前に中止しうる請求項２８記載の支払い方法。 30．前記中止ルーチンは、前記コミットレディーメッセージが送られたかをチェックするマネーモジュール実行ステップを含み、前記コミットレディーメッセージが送られた場合、前記第１のマネーモジュールから受信された前記マネーの電子的表示に関連した情報を記録し、前記マネーの電子的表示に関連した前記情報は、紛失した電子マネーをクレイムするために使用されうる請求項２８記載の支払い方法。 31．前記中止ルーチンは、前記電子マネー移転が完了し得ないことを示すメッセージを他の前記マネーモジュールへと送るマネーモジュール実行ステップを含み、前記他のマネーモジュールは、前記メッセージに応答して、前記電子マネー移転に関するその変化をロールバックし、前記電子マネー移転が中止されることを知る請求項３０記載の支払い方法。 32．前記他のマネーモジュールが第２の加入者によって使用される取引きマネーモジュールである場合、前記電子移転が中止されることを示すメッセージを前記第２の加入者へ送るステップをさらに含む請求項３１記載の支払い方法。 33．前記他のマネーモジュールが銀行に関連した出納モジュールである場合、前記電子移転のために行われる勘定取引きをリバースするように前記銀行に通知するステップをさらに含む請求項３１記載の支払い方法。 34．前記第１のマネーモジュールが変化をローリングバックし、前記取引きが中止されることを記録するステップをさらに含む請求項３０記載の支払い方法。 35．前記マネーモジュールがある加入者によって使用される取引きマネーモジュールであり、且つ前記コミットレディーメッセージが送られなかった場合、前記電子移転が中止されることを示すメッセージを前記加入者へ送るステップをさらに含む請求項３０記載の支払い方法。 36．前記マネーモジュールがある加入者によって使用される取引きマネーモジュールであり、且つ前記コミットレディーメッセージが送られた場合、前記電子移転が中止され、ありうるマネー移転エラーが起きたことを示すメッセージを前記加入者へ送るステップをさらに含む請求項３０記載の支払い方法。 37．前記マネーモジュールが銀行に関連した出納マネーモジュールであり、且つ前記コミットレディーメッセージが送られた場合、前記電子移転のために行われた勘定取引きをリバースすることを前記銀行に通知するステップをさらに含む請求項３０記載の支払い方法。 38．第１デバイスと第２デバイスが電子金融システムにおけるサーバーもしくは電子モジュールであって、その第１デバイスが第２デバイスとのセッションを確立する方法において、（ａ）前記第２デバイスが前記第１デバイスの認証を受取り、（ｂ）前記第２デバイスが前記第１デバイスの前記認証の正当性を確証し、（ｃ）前記第１デバイスのパブリックキーで暗号に書き直した部分（第１の乱数、第２デバイスの時間情報そして第１の検証メッセージを含む）と前記第２デバイスの認証とを含むメッセージを前記第２デバイスが前記第１デバイスへ送り、（ｄ）前記第２デバイスの前記認証の正当性を前記第１デバイスが確証し、そして前記第２デバイスの時間情報が第１デバイスの時間情報の所定範囲内にあるか、否かを決定し、（ｅ）前記第２デバイスのパブリックキーで暗号に書き直した第２のメッセージ（前記第１デバイスが発生した第２の乱数、前記第１デバイスが発生した第２の検証メッセージ、前記第２デバイスが発生した前記検証メッセージそして前記第１デバイスの時間情報を含む）を前記第１デバイスが前記第２デバイスへ送り、（ｆ）前記第１乱数と前記第２乱数との組み合わせからセッションキーを前記第１デバイスが形成し、（ｇ）前記第２デバイスが前記第１検証メッセージを確証し、前記第１乱数と前記第２乱数との組み合わせから前記セッションキーを形成し、そして前記第１デバイスの時間情報が前記第２デバイスの時間情報の所定範囲内にあるか、否かを決定し、（ｈ）前記セッションキーで暗号に書き直した確認メッセージを前記第２デバイスが前記第１デバイスへ送り、（ｉ）前記第１デバイスが前記確認メッセージを解読し、そして前記第２検証メッセージを検証することを特徴とする方法。 39．前記第１デバイスがネットワークサーバを有する電子金融システムへ接続されている場合、前記段階（ａ）が、対称キーで暗号に書き直した、前記第１デバイスの前記認証を含むメッセージを前記第１デバイスが前記ネットワークサーバへ送り、そして前記ネットワークサーバーが前記メッセージを解読し、そして前記第１デバイスの前記認証を前記第２デバイスへ送る請求項３８に記載の方法。 40．各認証がデバイス毎に独自の識別子を含み、前記第１デバイスの独自の識別子が前記第２デバイスに蓄積された第１リストに含まれているか、否かを前記第２デバイスが決定し、そして前記第２デバイスの独自の識別子が前記第１デバイスに蓄積された第２リストに含まれているか、否かを前記第１デバイスが決定し、前記第１リストと前記第２リストとが不良デバイスの独自の識別子のリストである請求項３８に記載の方法。 41．各デバイスは複数のタイプの中の一つであり、各タイプはタイプの変数の独自の範囲と関連しており、そして所与のデバイスの前記独自の認識子が、各デバイスに蓄積されたマッピング機構に従って前記所与のデバイスのタイプに割り当てられた前記独自の範囲内で前記タイプの変数の値にマップし、前記段階（ｂ）では前記第１デバイスの前記独自の識別子を第１デバイスのタイプの変数にマップし、そして前記第１デバイスのタイプの変数が前記第１デバイスの予期されたタイプに対応し、そして前記段階（ｄ）では前記第２デバイスの前記独自の識別子を第２デバイスのタイプ変数にマップし、そして前記第２デバイスのタイプ変数が前記第２デバイスの予期されたタイプに対応するか、否かを決定する請求項４０に記載の方法。 42．移転元マネーモジュールから移転先マネーモジュールへ所定の全貨幣的価値の電子ノートを移転する方法において、（ａ）前記全貨幣的価値を与える一つもしくはそれ以上の電子ノートを前記移転元マネーモジュールが選択し、（ｂ）前記移転元マネーモジュールのそれぞれの移転記録とディジタル署名とを前記一つもしくはそれ以上の電子ノートへ加えることにより一つもしくはそれ以上の移転電子ノートを前記移転元マネーモジュールがつくり、一つもしくはそれ以上の移転電子ノート毎に前記それぞれの移転記録は、前記一つもしくはそれ以上の電子ノートの総てもしくはある部分が移転されているか、否かを示しており、（ｃ）前記移転元マネーモジュールは前記一つもしくはそれ以上の移転電子ノートを前記移転先マネーモジュールへ送り、（ｄ）前記移転先マネーモジュールは前記一つもしくはそれ以上の移転電子ノートの正当性を検証し、（ｅ）前記移転先マネーモジュールはノートディレクトリーに前記一つもしくはそれ以上の移転電子ノートを、それの正当性を検証した後、蓄積し、前記ノートディレクロリーは前記移転先マネーモジュールが所有する電子ノートを含んでおり、そして前記移転先マネーモジュールは、それが企画している取引に含まれる電子ノートのノートボディーと移転の記録を含むノートログ情報に蓄積し、そして前記段階（ｄ）では前記一つもしくはそれ以上の移転電子ノートの移転ノート毎に、前記移転ノートとのマッチのため前記ノートディレクトリーと前記ノートログ内のノートボディーを検査し、そして認識されたマッチのためのノート移転トリーをつくり、そして重複検査することを特徴とする方法。 43．前記移転記録はシーケンス識別番号を含み、前記一つもしくはそれ以上の電子ノート毎に前記シーケンス識別番号はそれからつくられたすべての移転電子ノートを区別する請求項４２に記載の方法。 44．前記一つもしくはそれ以上の移転電子ノートの移転電子ノート毎に、前記段階（ｅ）では前記移転記録と他の移転元マネーモジュールによって加えられたすべての他の移転記録とを検査して、直前の移転で移された貨幣的価値よりも大きくない貨幣量が移転毎に移されたことを確認する請求項４２に記載の方法。 45．前記一つもしくはそれ以上の移転電子ノートの各移転電子ノートは、前記移転電子ノートの履歴にわたって各移転元マネーモジュールのディジタル署名と認証とを含んでおり、前記段階（ｄ）では各ディジタル署名と認証の正当性を検証する請求項４２に記載の方法。 46．前記一つもしくはそれ以上の移転電子ノートの各移転電子ノートは期限切れ日付けを含んでおり、そして前記移転先マネーモジュールは取引マネーモジュールであり、前記段階（ｄ）では前記移転先マネーモジュールが各電子ノートの期限切れ日付を検証する請求項４２に記載の方法。 47．前記電子ノートは期限切れ日付けと貨幣的価値とを有する通貨の電子的表示であり、前記段階（ａ）は、（ａ）所定の全貨幣的価値を与え、そして最小数の電子ノートを使用するためのすべてあり得る選択を決定し、（ｂ）前記のすべてあり得る選択の中どのセットが最小数の移転を含んでいるかを見出し、そして（ｃ）そのセットが一つよりも多い要素を含んでいる場合、そのセットの要素のすべてのノートにわたって集計した最小数の貨幣単位日を含むセットの要素を選択し、この貨幣単位日は電子ノートの満期日までの日数とその電子ノートの残りの貨幣的価値との積を表している請求項４２に記載の方法。 48．前記段階（ｄ）では、前記移転先マネーモジュールは、移転された前記所定の貨幣的価値が予期した値に一致することを検証する請求項４２に記載の方法。 49．移転元マネーモジュールから移転先マネーモジュールへ所定の全貨幣的価値の電子ノートを移転する方法において、（ａ）前記全貨幣的価値を与える一つもしくはそれ以上の電子ノートを前記移転元マネーモジュールが選択し、（ｂ）前記移転元マネーモジュールのそれぞれの移転記録とディジタル署名とを前記一つもしくはそれ以上の電子ノートへ加えることにより一つもしくはそれ以上の移転電子ノートを前記移転元マネーモジュールがつくり、一つもしくはそれ以上の移転電子ノート毎に前記それぞれの移転記録は、前記一つもしくはそれ以上の電子ノートの総てもしくはある部分が移転されているか、否かを示しており、（ｃ）前記移転元マネーモジュールは前記一つもしくはそれ以上の移転電子ノートを前記移転先マネーモジュールへ送り、（ｄ）前記移転先マネーモジュールは前記一つもしくはそれ以上の移転電子ノートの正当性を検証し、（ｅ）前記移転先マネーモジュールはノートディレクトリーに前記一つもしくはそれ以上の移転電子ノートを、それの正当性を検証した後蓄積し、前記一つもしくはそれ以上の移転電子ノートの各移転電子ノートは移転電子ノートの履歴にわたり各移転元マネーモジュールのディジタル署名と認証とを含み、これらの認証のそれぞれは前記移転電子ノートの履歴にわたる各移転マネーモジュールからその関連の移転元マネーモジュールを特定する独自の識別子を含み、そして前記移転記録は前記移転電子ノートの履歴にわたっての各移転先電子モジュールの独自の識別子を含み、そして、前記段階（ｄ）では前記移転記録の独自の識別子が前記電子ノートの履歴にわたって順次の移転毎に前記認証内の独自の識別子に一致することを検査している方法。 50．移転元マネーモジュールから移転先マネーモジュールへ所定の全貨幣的価値の電子ノートを移転する方法において、（ａ）前記全貨幣的価値を与える一つもしくはそれ以上の電子ノートを前記移転元マネーモジュールが選択し、（ｂ）前記移転元マネーモジュールのそれぞれの移転記録とディジタル署名とを前記一つもしくはそれ以上の電子ノートへ加えることにより一つもしくはそれ以上の移転電子ノートを前記移転元マネーモジュールがつくり、一つもしくはそれ以上の移転電子ノート毎に前記それぞれの移転記録は、前記一つもしくはそれ以上の電子ノートの総てもしくはある部分が移転されているか、否かを示しており、（ｃ）前記移転元マネーモジュールは前記一つもしくはそれ以上の移転電子ノートを前記移転先マネーモジュールへ送り、（ｄ）前記移転先マネーモジュールは前記一つもしくはそれ以上の移転電子ノートの正当性を検証し、（ｅ）前記移転先マネーモジュールはノートディレクトリーに前記一つもしくはそれ以上の移転電子ノートを蓄積し、前記一つもしくはそれ以上の移転電子ノートの各移転電子ノートは移転電子ノートの履歴にわたり各移転先マネーモジュールのそれぞれ独自のディジタル署名を含み、そして前記移転先マネーモジュールは取引マネーモジュールであり、前記段階（ｄ）では前記の独自の識別子の各々が前記移転先マネーモジュールに蓄積されている不良マネーモジュールの独自の識別子のリストにのっているか、否かを検査していることを特徴とする方法。 51．第１取引モジュールに蓄積されている第１外国通貨の電子表示を第２取引モジュールに蓄積されている第２外国通貨の電子表示に第１の加入者が変える方法において、（ａ）前記第１取引モジュールと前記第２取引モジュールとの間で暗号で安全保証したセッションを確立し、（ｂ）前記第１取引モジュールにより、売ろうとする前記外国通貨の第１の量を選択し、（ｃ）前記第１取引モジュールが十分なファンドを有するか、否かを調べ、（ｄ）前記第１取引モジュールが前記第１の量を前記第２取引モジュールへ暗号で安全保証したセッションを介して送り、（ｅ）前記第２取引モジュールはそれのオーナーに交換レートもしくは前記第２の通貨の第２の量を選択させ、（ｆ）前記第２取引モジュールが十分なファンドを有するか、否かを調べ、（ｇ）前記第２の量もしくは前記交換レートを表しているメッセージを前記第２取引モジュールが、暗号で安全保証したセッションを介して、前記第１取引モジュールへ送り、（ｈ）前記第１の加入者が前記第２の量もしくは前記交換レートを確認し、（ｉ）第１の外国通貨の前記電子表示を、前記第１の量だけ、前記第１取引モジュールが、暗号で安全保証したセッションを介して、前記第２取引モジュールへ送り、（ｊ）第２の外国通貨の前記電子表示を、前記第２の量だけ、前記第２取引モジュールが、暗号で安全保証したセッションを介して、前記第１取引モジュールへ送り、そして（ｋ）前記第１取引モジュールに前記第１の外国通貨を前記第２取引モジュールへ移させ、そして前記第２取引モジュールに前記第１取引モジュールから前記第１の外国通貨を受け取らせ、そして前記第２取引モジュールに前記第１取引モジュールへ前記第２の外国通貨を移させ、そして前記第１取引モジュールに前記第２取引モジュールから前記第２の外国通貨を受け取らせ、これらは予想不能の順序で行われることを特徴とする方法。 52．前記段階（ｋ）で、（ａ）前記第１取引モジュールと前記第２取引モジュールは、第１の値もしくは第２の値のどちらかを有する、共通のランダムバイナリ値を共有し、（ｂ）前記第１の外国通貨を前記第２取引モジュールへの前記移転か、もしくは前記第２の外国通貨を前記第２取引モジュールからの前記受領かのどちらかを条件付で前記第１取引モジュールが記録し、前記共通のランダムバイナリ値は前記第１の値もしくは前記第２の値を有し、ローリングバックが生じるようにし、（ｃ）前記第１の取引モジュールが移転の条件付での記録を完了したことを示すメッセージを前記第１取引マネーモジュールが前記第２取引マネーモジュールへ送り、（ｄ）前記第１の取引モジュールからの前記第１の外国通貨の前記受領か、前記第１の取引モジュールへの前記第２の外国通貨の前記移転かのいずれかを条件付きで前記第２取引モジュールが前記メッセージに応答して記録し、前記共通のランダムバイナリ値は前記第１の値もしくは前記第２の値に等しく、ローリングバックが生じるようにし、（ｅ）前記共通のランダム数の値が第１の値に等しいとき、前記第２取引マネーモジュールは前記第１取引モジュールへスタートコミットメッセージを送り、（ｆ）前記スタートコミットメッセージに応答して前記第１取引モジュールは前記条件付き記録を無条件記録へセットし、そしてコミットプロトコールを開始し、そこでは前記第１取引モジュールはそれの未処理の移転を処置して前記第１取引モジュールがそれの状態をロールバックすることにより前記移転をもはや中絶できないようにし、そして前記第２マネーモジュールは前記第２外国通貨移転と前記第１外国通貨受領とを、前記移転と受領とを記録することにより行って、前記第２マネーモジュールがそれの状態をロールバックすることにより前記外国通貨の両替をもはや中絶できないようにし、そして（ｇ）前記共通の乱数の値が第２の値に等しいとき、前記第２取引マネーモジュールは前記条件付き記録を無条件記録へセットし、そしてコミットプロトコールを開始し、そこでは前記第２取引モジュールはそれの未処理の移転を処置して前記第２取引モジュールがそれの状態をロールバックすることにより前記移転をもはや中絶できないようにし、そして前記第１マネーモジュールは前記第１外国通貨移転と前記第２外国通貨受領とを行って、前記第１マネーモジュールがそれの状態をロールバックすることにより前記外国通貨の両替をもはや中止できないようにする請求項５１に記載の方法。 53．暗号で安全保証されたセッションを確立する前記段階中前記共通乱数をセッションキーとして発生させる請求項５２に記載の方法。 54．別のマネーモジュールに対して未処理のマネー移転のため所与のマネーモジュールにより開始される前記コミットプロトコールにおいて、前記所与のマネーモジュールが前記別のマネーモジュールへコミットレディーメッセージを送り、前記別のマネーモジュールは前記コミットレディーメッセージに応答して前記所与のマネーモジュールへ確認を送り、前記所与のマネーモジュールは未処理のマネー移転を記録することにより処置し、前記所与のマネーモジュールがそれの状態をロールバックすることにより未処理のマネー移転をもはや中止できないようにし、前記別のマネーモジュールは未処理のマネー移転を記録することにより処置し、前記別のマネーモジュールがそれの状態をロールバックすることにより未処理のマネー移転をもはや中止できないようにする請求項５１に記載の方法。 55．前記段階（ｂ）では、前記加入者がノートのタイプにより売ろうとする前記第１の外国通貨の前記第１の量を選択する請求項５１に記載の方法。 56．それぞれが複数のモジュールタイプの一つであるプロセッサベースド電子モジュールの間で電子ノートを移転するシステムにおいて、プロセッサベースド電子モジュールを備え、各プロセッサベースド電子モジュールは独自のモジュール識別子を蓄積し、そしてそれぞれは暗号で安全を保証されたチャネルをつくり、そしてこの暗号で安全を保証されたチャネルを介して電子ノートを移転したり、受け取ったりすることができ、そして前記電子モジュールの各々は前記電子ノートを蓄積するメモリーを有し、前記複数のモジュールタイプの各々はモジュールタイプ変数の独自の範囲と関連しており、そして前記独自のモジュール識別子の各々は、前記電子モジュールの各々に蓄積されているマッピング機構に従って前記モジュールタイプへ割り当てられた前記独自の範囲内の前記タイプの変数の値へマップすることを特徴とするシステム。 57．前記独自の識別子の各々は所定の素数より小さい独自の整数値であり、前記素数の一次根を前記所定の素数を越えるモジュローアリスマテイックの下で前記独自の認識子のぺきへ上げることにより前記タイプ変数の値を発生させ、前記複数の電子モジュールの各々、前記一次セキュリテイサーバーそして前記複数の二次セキュリテイサーバーは前記一次根と前記素数とを蓄積する請求項５６に記載のシステム。 58．出納モジュール、マネージェネレータモジュール及びオンライン勘定システムを有する発行銀行において加入者が取引モジュールを使用して加入者の銀行勘定のクレジットノートを更新する方法であって、（ａ）前記加入者が、前記取引モジュールにより、前記クレジットノートを更新するための前記銀行勘定と、前記クレジットノートの要求されたクレジット総額）を表す要求されたクレジット額とを選択し、（ｂ）前記取引モジュールが前記出納モジュールと第１の暗号保証セッションを確立し、（ｃ）前記取引モジュールが前記第１の暗号保証セッションを介してクレジット要求メッセージを前記出納モジュールに送り、ここで、前記クレジット要求メッセージは、前記クレジットノートの正味のクレジット額に対応するクレジット更新額と前記銀行勘定に対応する銀行勘定情報を含み、（ｄ）前記銀行勘定情報をチェックしてその正当性を検証し、（ｅ）前記要求されたクレジット額を与えるのに十分なファンドであるかどうかについて前記加入者の銀行勘定の関係するクレジットラインをチェックし、（ｆ）前記加入者の銀行勘定の現在のクレジットノートが存在する場合には、前記取引モジュールが前記現在のクレジットノートを前記出納モジュールに送り、（ｇ）前記出納モジュールが前記マネージェネレータモジュールと第２の暗号保証セッションを確立し、（ｈ）前記クレジットノートについて前記要求されたクレジットの総額に従って前記加入者の銀行勘定に関係する前記クレジットラインを更新し、（ｉ）前記出納モジュールが前記第２の暗号保証セッションを介してノート作成要求を前記マネージェネレータモジュールに送り、ここで、前記ノート作成要求は、要求されたクレジットノート値を含み、（ｊ）前記マネージェネレータモジュールが前記要求されたクレジットノート値のクレジットノートを発生し、（ｋ）前記第２の暗号保証セッションを介して前記クレジットノートを前記出納モジュールに移転し、（ｌ）前記第１の暗号保証セッションを介して前記クレジットノートを前記取引モジュールに移転し、（ｍ）前記取引モジュールと前記出納モジュールセッションをコミットし、（ｎ）前記出納モジュールが前記マネージェネレータモジュールとコミットする、ことから成る方法。 59．前記現在のクレジットノートが存在する場合に、前記段階（ｃ）において、前記クレジットノートの前記正味のクレジット額は、前記要求されたクレジット総額と前記現在のクレジットノートの現在のクレジット額との間の差額を表す請求項５８に記載のクレジット更新方法。 60．前記銀行勘定情報は、顧客サービスモジュールによりディジタル署名された銀行勘定番号を有する勘定プロフィルを含み、前記銀行勘定情報の正当性をチェックする段階は、前記顧客サービスモジュールのパブリックキーで前記勘定プロフィルについてディジタル署名をチェックする段階を含む請求項５８に記載のクレジット更新方法。 61．段階（ｆ）は、さらに、前記取引モジュールが前記取引モジュールに記憶された任意の通貨ノートと任意の転送されたクレジットノートとを前記出納モジュールに送る段階を含み、段階（ｆ）の後に、前記出納モジュールが前記通貨ノートと転送されたクレジットノートとに従って前記オンライン勘定システムを更新する段階が続き、段階（ｉ）において、前記ノート作成要求は、前記取引モジュールに記憶された前記通貨ノートと前記転送されたクレジットノートの総合値に対応する要求された通信ノート値を含み、前記要求された通貨ノート値により前記オンライン勘定システムにマネー発行額を信用貸し、段階（ｊ）は、前記マネージェネレータモジュールが前記要求された通貨ノート値の通貨ノートを発生する段階を含み、段階（ｋ）は、前記第２の暗号保証セッションを介して前記通貨ノートを前記出納モジュールに移転する段階を含み、段階（ｌ）は、前記第１の暗号保証セッションを介して前記通貨ノートを前記取引モジュールに移転する段階を含む請求項５８に記載のクレジット更新方法。 62．出納モジュール、マネージェネレータモジュール及びオンライン勘定システムを有する銀行において、加入者が、１つ以上の銀行へのアクセスを有するホストに関係する顧客サービスモジュールにより、取引マネーモジュールを前記加入者の銀行勘定にリンクさせる方法であって、（ａ）前記顧客サービスモジュールのホストが、前記加入者の識別情報を受け取るのに応答して、前記１つ以上の銀行から前記加入者の銀行勘定情報をアクセスし、（ｂ）前記銀行勘定情報を検証し、そして、前記加入者が、前記取引マネーモジュールとリンクさせるために前記加入者の銀行勘定を識別し、（ｃ）前記取引マネーモジュールと前記顧客サービスモジュールとの間にセッションを確立し、（ｄ）前記顧客サービスモジュールが、前記加入者の銀行勘定の勘定プロフィルを発生し、（ｅ）前記顧客サービスモジュールが、前記取引マネーモジュールにメッセージを送り、ここで、前記メッセージは、前記勘定プロフィルと、前記顧客サービスモジュールのパブリックキーにより署名された前記勘定プロフィルのディジタル署名とを含み、（ｆ）前記取引マネーモジュールが、前記勘定プロフィルを記憶し、（ｇ）前記取引マネーモジュールが、前記顧客サービスモジュールの認証を前記勘定プロフィルに付し、（ｈ）前記取引マネーモジュールが前記勘定プロフィルを記憶し、（ｉ）前記取引マネーモジュールと前記顧客サービスモジュールセッションをコミットする、ことから成る方法。 63．段階（ｆ）は、さらに、前記加入者が前記勘定プロフィルを検証する段階を含む請求項６２に記載の方法。 64．段階（ｈ）は、前記取引マネーモジュールが前記銀行勘定の現存する第２の勘定プロフィルを前記勘定プロフィルと交換する段階を含む請求項６２に記載の方法。 65．出納モジュール、マネージェネレータモジュール及びオンライン勘定システムを有する銀行において、加入者が、１つ以上の銀行へのアクセスを有する顧客サービスモジュールにより、取引マネーモジュールと前記加入者の銀行勘定とのリンクを再確証する方法であって、（ａ）前記加入者が、前記取引マネーモジュールにより、前記リンクを再確証するために前記銀行を選択し、（ｂ）前記取引マネーモジュールが、前記顧客サービスモジュールと第１の暗号保証セッションを確立し、（ｃ）前記取引マネーモジュールが、前記取引マネーモジュールに記憶されている前記銀行勘定の銀行プロフィルを前記顧客サービスモジュールに送り、（ｄ）前記顧客サービスモジュールが、前記銀行プロフィルの正当性を検証し、（ｅ）前記顧客サービスモジュールが、前記勘定プロフィルに含まれる前記加入者の銀行勘定が生きているかどうかを前記銀行でチェックし、（ｆ）前記顧客サービスモジュールが、前記加入者の銀行勘定の更新された勘定プロフィルを発生し、（ｇ）前記顧客サービスモジュールが、前記取引マネーモジュールにメッセージを送り、ここで、前記メッセージは、前記更新された勘定プロフィルと、前記顧客サービスモジュールのプライベートキーにより署名された前記勘定プロフィルのディジタル署名とを含み、（ｈ）前記取引マネーモジュールが、前記ディジタル署名を検証し、（ｉ）前記取引マネーモジュールが、前記更新された勘定プロフィルに前記顧客サービスモジュールの認証を付し、（ｊ）前記取引マネーモジュールと前記顧客サービスモジュールのセッションをコミットする、ことから成る方法。 66．前記勘定プロフィルは、特定の顧客サービスモジュールディジタル署名と、前記特定の顧客サービスモジュールディジタル署名と、前記特定の顧客サービスモジュールの認証を含み、前記勘定プロフィルの正当性を検証する段階（ｄ）は、前記特定の顧客モジュールディジタル署名をチェックして前記特定の顧客サービスモジュールの前記認証を正当化する段階を含む請求項６５に記載の方法。 67．オンライン勘定システムを有する発行銀行と、マネー発行調停システムと、前記オンライン勘定システムにおいて勘定されるマネーの電子的表示と、前記マネーの電子的表示を発生する、前記発行銀行と関係するマネージェネレータモジュールと、前記マネーの電子的表示を記憶できる、前記発行銀行と関係する出納モジュールと、前記マネーの電子的表示を移転できる取引マネーモジュールと、を備え、前記モジュールの任意の２つの間の移転毎に前記マネーの電子的表示に移転記録が付され、前記電子ノートが前記マネー発行調停システムに周期的に送られ、前記マネー発行調停システムが、各ノートについて前記移転記録を分析して紛失した又は複製されたマネーの電子的表示を識別するプロセッサを有し、与えられた取引マネーモジュールの加入者が、マネーの紛失の電子的表示を識別する紛失マネークレームを前記発行銀行に提出し、前記発行銀行が、前記紛失マネークレームに基づいて、及び、前記マネー発行調停システムが前記紛失マネーの電子的表示の各々について前記紛失マネークレームの正当性を確認するのに基づいて、前記加入者に報酬を支払う、電子マネーシステム。 68．前記取引マネーモジュールは、それぞれ、中止された取引に関係するマネーの電子的表示に関係する情報を記憶するようになっており、前記紛失マネークレームは前記情報を含む請求項６７に記載の電子マネーシステム。 69．前記取引マネーモジュールは、それぞれ、独立した記憶装置に前記紛失マネークレームを記憶するようになっており、前記紛失マネークレームは、前記取引マネーのモジュールのプライベートキーによりディジタル署名される請求項６７に記載の電子マネーシステム。 70．前記紛失マネークレームは、前記取引マネーモジュールに記憶されたマネーのすべての電子的表示と関係する情報を含む請求項６７に記載の電子マネーシステム。 71．加入者が、加入者の取引マネーモジュールに関係する紛失電子ノートを識別する紛失ノートクレームを作成する方法であって、（ａ）前記加入者が、前記取引マネーモジュールにより、紛失ノートクレームを作成し、（ｂ）前記取引マネーモジュールが、独自のクレームシーケンス番号を発生して前記紛失ノートクレームを、前記独自のクレームシーケンス番号、前記取引マネーモジュールに記憶されたすべての移転可能な電子ノートについての情報、前記取引マネーモジュールによる失敗したコミットに関係する任意の電子ノートについての失敗コミット情報及び前記取引マネーモジュールのディジタル署名及び認証を含むパケットとして構成し、（ｃ）前記取引マネーモジュールから独立した記憶媒体に前記紛失ノートクレームを記憶する、ことから成る方法。 72．前記紛失ノートクレームは、前記取引マネーモジュールのプライベートキーで暗号化された第１と第２のデータフィールドであって、前記第１データフィールドが、前記独自のクレームシーケンス番号と、現在の値及び前記移転可能な電子ノートのそれぞれのコピーを含む前記取引マネーモジュールに記憶されたすべての移転可能な電子ノートについての情報と、クレームされていない失敗コミットについての前記失敗コミット情報とを含んでおり、前記第２データフィールドが、前記取引マネーモジュールのプライベートキーでディジタル署名された前記第１データフィールドを含んでいる、前記第１と第２のデータフィールドと、前記クレームシーケンス番号と、前記紛失ノートクレームについてのマネー値の総額と、前記取引マネーモジュールの前記認証とを含む第３のデータフィールドと、を含む請求項７１に記載の方法。 73．加入者が、１つ以上の発行銀行に対するアクセスを有する顧客サービスモジュールにより、取引マネーモジュールを使用して該取引マネーモジュールに関係する紛失ノートをクレームする方法であって、（ａ）前記加入者が、前記顧客サービスモジュールのホストに識別を与え、（ｂ）前記取引マネーモジュールと前記顧客サービスモジュールとの間に暗号保証セッションを確立し、（ｃ）前記顧客サービスモジュールが、前記ホストから前記加入者の識別情報を受け取り、（ｄ）前記取引マネーモジュールが、前記顧客サービスモジュールに、前記取引マネーモジュールに記憶されたクレームされていない失敗コミット記録に関係するクレームされていない失敗コミット情報を含むメッセージを送り、（ｅ）前記顧客サービスモジュールが、前記クレームされていない失敗コミット情報からクレームを構成して該クレームを前記ホストを介して前記１つ以上の銀行に関係するマネー発行調査システムに送る、ことから成る紛失ノートクレーム方法。 74．さらに、前記顧客サービスモジュールが、前記メッセージに応答して、前記取引マネーモジュールにクレーム識別子を送り、前記取引マネーモジュールが前記クレーム識別子で前記クレームされていない失敗コミットの各々に印を付けることを含む請求項７３に記載の紛失ノートクレーム方法。 75．前記段階（ｄ）において前記顧客サービスモジュールに送られた前記クレームされていない失敗コミット情報が、以前にクレームされたことのないクレームされていない失敗記録のみに関係している請求項７３に記載の紛失ノートクレーム方法。 76．前記段階（ｄ）の前に、前記加入者が、前記取引マネーモジュールにより、前記失敗コミット記録リストの中から前記失敗コミット記録を選択する請求項７３に記載の紛失ノートクレーム方法。 77．加入者が、１つ以上の発行銀行に対するアクセスを有する顧客サービスモジュールにより、取引マネーモジュールから記憶された紛失ノートクレームを含む記憶装置を使用して該取引マネーモジュールに関係する紛失ノートをクレームする方法であって、前記記憶装置が前記取引マネーモジュールから独立している方法において、（ａ）前記加入者が、前記顧客サービスモジュールのホストに識別を与え、（ｂ）前記顧客サービスモジュールが、前記記憶装置に記憶された紛失ノートクレームをアクセスし、（ｃ）前記顧客サービスモジュールが、前記記憶装置から前記紛失ノートクレームを受け取り、（ｄ）前記顧客サービスモジュールが、前記紛失ノートクレームの正当性を検証し、（ｅ）前記顧客サービスモジュールが、前記クレームされていない失敗コミット情報からクレームを構成して該クレームを前記ホストを介して前記１つ以上の発行銀行に関係するマネー発行調査システムに送る、ことから成る紛失ノートクレーム方法。 78．前記紛失ノートクレームは、前記取引マネーモジュールの認証を含み、前記顧客サービスモジュールが前記紛失ノートクレームの正当性を検証する段階（ｄ）は、前記認証を検証することを含む請求項７７に記載の紛失ノートクレーム方法。 79．前記紛失ノートクレームは、紛失ノートのコピーを含み、前記紛失ノートコピーの各々の紛失ノートコピーは、前記紛失ノートコピーのオリジナルを移転させた各移転マネーモジュールのリストを含むデータフィールドの認証グループを有するとともに各々前記移転マネーモジュールのディジタル署名及び認証を含み、段階（ｄ）は、さらに、各移転マネーモジュールの認証及びディジタル署名の正当性を検証する段階を含む請求項７７に記載の紛失ノートクレーム方法。 80．前記紛失ノートクレームは、紛失ノートのコピーを含み、前記紛失ノートコピーの各々の紛失ノートコピーは、前記紛失ノートコピーのオリジナルの移転の度に移転された各マネー値の額のリストを含む移転記録データフィールドを有し、段階（ｄ）は、さらに、前記移転記録データフィールドをチェックして、各移転について、直前の移転において移転されたマネー値よりも大きくないマネー値が移転されたかどうかを確認する段階を含む請求項７７に記載の紛失ノートクレーム方法。 81．段階（ｄ）において、前記顧客サービスモジュールと前記記憶装置に関係するホスト装置との間に通信リンクが確立され、前記顧客サービスモジュールは、前記通信リンクを介して前記紛失ノートクレームをアクセスする請求項７７に記載の紛失ノートクレーム方法。 82．複数のセキュリティサーバと、前記セキュリティサーバの１つによりディジタル署名される独自のモジュール認証と、マネーの電子的表示を記憶するメモリと、前記マネーの電子的表示を移転しかつ受け取る暗号保証チャンネルを与えるようになったプロセッサとを有する複数の改ざん防止データモジュールと、を備え、前記モジュール認証は、前記電子モジュールが他の電子モジュールと又は前記セキュリティサーバと相互に作用する際に正当化され、前記複数のセキュリティサーバは、前記モジュール認証についてグローバルな再確証を選択的にコマンドし、前記セキュリティサーバの１つと相互に作用して前記モジュール認証を再確証する電子モジュールを要求する、電子モジュールをベースとするマネー取引システム。