JPH10511788A

JPH10511788A - 電子マネーをオープン流通させるための信託エージェント

Info

Publication number: JPH10511788A
Application number: JP9500429A
Authority: JP
Inventors: ショーロムエスローゼン
Original assignee: Citibank NA
Current assignee: Citibank NA
Priority date: 1995-06-07
Filing date: 1996-03-11
Publication date: 1998-11-10
Anticipated expiration: 2016-03-11
Also published as: CZ380597A3; PL179381B1; JP3390016B2; HU220576B1; DE69602265D1; KR19990022340A; CA2223079C; SK167397A3; AU5355596A; MX9709725A; SI9620073A; RU2145439C1; DE69602265T2; US5745886A; HK1009193A1; BR9608559A; NZ305540A; CA2223079A1; HUP9801603A3; NO975670L

Abstract

(57)【要約】第１のマネーモジュールに関連付けられた顧客信託エージェントと、該顧客信託エージェントに対して第１の暗号的に安全なセッションを確立し、第２のマネーモジュールに関連付けられた商人信託エージェントとを有する電子マネーのオープン流通のためのシステムが提供される。マネーモジュールは、第２の暗号的に安全なセッションを確立する。顧客信託エージェントは、電子マネー購入又は売却情報と口座信用証明を商人信託エージェントに送り、商人信託エージェントは受取チケットを顧客信託エージェントに提供する。商人信託エージェントは、承認ネットワークにアクセスし、電子マネー購入又は売却情報と口座信用証明からの情報に基づき承認プロセスを開始する。承認を受けたとき、商人信託エージェントは、購入の場合には第２のマネーモジュールから第１のマネーモジュールへの電子マネーの移転を開始し、売却の場合には第１のマネーモジュールから第２のマネーモジュールへの電子マネーの移転を開始する。

Description

【発明の詳細な説明】電子マネーをオープン流通させるための信託エージェント発明の分野本発明は、電子マネーの流通を容易にするためのシステムに関する。特に、このシステムは、顧客がクレジット又は借方カード信任状を使用して商人に対し電子マネーを売買できるようにする保証取引環境を生成するために、「信託エージェント」と呼ばれる耐不正使用性の電子ユニットをマネーモジュールと組み合わせて使用するものである。発明の背景電子的商業の成長に対応するように、多くの電子的支払いシステムが開発されている。電子的支払いの一つの方法が、1991年11月15日に出願された係属中の米国特許出願第07／794,112号、1994年４月28日に出願された同08／234,461 号、及び1995年４月21日に出願された同08／427,287 号に開示されており、それらの開示を、参照としてここに組み入れる。これらの出願は、現金、小切手、クレジットカード、借方カード、及び電子的資金移転による取引に代わる媒体として、電子マネー支払いを実行する電子マネーシステムを開示する。特に、この説明されたシステムは、耐不正使用性ハウジング内にパッケージされ、電子ノートがストアされ移転されるようになったマネーモジュールを使用する。マネーモジュールによる支払いは、リアルタイムであったり、マネーモジュール間（例えば、顧客の「電子財布」と商人のポイント・オブ・セールス端末内に含まれるマネーモジュールとの間）のオフライン支払いであったり、或いは、情報取り出し及び電話の通話のようなネットワークサービス、又は航空券や劇場入場券等の購入に対するオンライン支払いであったりする。ここで、信託エージェントは、1994年４月28日出願の係属中の米国特許出願第 08／234,461 号に十分に説明されており、その開示を、参照としてここに組み入れる。この出願は、リアルタイムの匿名支払い又は承認をベースとする支払いで電子商品を安全に供給できるようにするシステムを説明している。このシステムは、顧客と商人の両方に対して、それぞれの利益が満たされていると感じさせるものである。現金は、銀行及び商人から広く入手できるものである。電子マネーは、一般的に受け入れられるためには、現金と同様に、広く用できるものであることが必要である。本発明は、どのようにして信託エージェントが、支払い承認ネットワークに接続された商人を通じて電子マネーの流通を容易にするか、を説明する。この流通取引は、局地的にも、又は商人から離れても達成でき、銀行ネットワークよりも大幅に流通ポイントを増加させることができる。また、開示された流通システムでは、一つのマネー単位を他のものと交換することもできる。例えば、英国ポンド口座から米国ドルを得ることができる。米国特許出願第07／794,112 号は、現金をどのようにして電子マネーに交換できるか、について、またその逆について説明する。その取引は、銀行の出納において又はATM 機械において局部地に達成され、現金が払い出されていた。ATM 機械又はポイント・オブ・セールス端末が電子マネーを支払うように改修され、端末が取引の安全性を保証できる場合には、電子マネーも又、局地的に支払いできた。本発明は、ATM 端末やPOS 端末のような特殊な端末なしに、どのようにして電子マネーを商人が遠隔的にかつ安全に処理できるか、について説明する。顧客がよく知らず、顧客の電子マネーを取得するか又は該顧客の秘密の銀行情報を捕捉するトロイの馬的な処理を持つ可能性のある特殊な端末は必要ではない。発明の要約本発明の一目的は、支払い承認ネットワークに接続された商人又は銀行を会して電子マネーを流通させるための、信託エージェントを使用する安全なシステムを提供することである。本発明の他の目的は、特殊な端末なしで遠隔的にかつ安全に商人に対し電子マネーを売買するためのシステムを提供することである。本発明のさらに他の目的は、商人が最初に電子マネーを所有していない場合でも、商人が電子マネーについての顧客の需要を満足させることができるシステムを提供することである。本発明のさらに他の目的は、電子マネーシステムに関与する多数の銀行に対して手続をする必要なしに、電子マネーの流通を増大させることである。本発明においては、顧客信託エージェントと、該顧客信託エージェントに関連付けられ該エージェントと安全に通信する第一のマネーモジュールと、該顧客信託エージェントと第一の暗号的安全セッションを確立する商人信託エージェントと、前記商人信託エージェントに関連付けられ該商人信託エージェントと安全に通信する第二のマネーモジュールとを有する電子マネーのオープン流通のためのシステムが提供される。第一及び第二のマネーモジュールは、第二の暗号的安全セッションを確立する。顧客信託エージェントは、電子マネー購入情報と口座信用状を商人信託エージェントに提供し、商人信託エージェントは、該顧客信託エージェントに受領票を与える。商人信託エージェントは、承認ネットワークにアクセスし、電子マネー購入情報と口座信用状からの情報を使用して承認処理を始める。商人信託エージェントは、承認を得たのち、第二のマネーモジュールから第一のマネーモジュールへの電子マネーの移転を開始する。商人信託エージェントが、該エージェントの関連するマネーモジュールに十分な資金を持っていないときは、該商人信託エージェントは、系列下の取引装置から電子マネーを取得するか、又は該商人が口座を有し電子マネープロバイダーでもある銀行から電子マネーを引き出すように試みる。この説明したシステムアーキテクチャー及びプロトコールは又、顧客から商人への電子マネーの販売をサポートするものであり、これは、預金取引に類似している。図面の簡単な説明以下に、本発明を添付図面を参照して詳細に説明する。図において、図１は、信託エージェントとマネーモジュールの間の相互作用を示す図表である。図２は、種々のチケットのセクション及び分野を示す。図３は、取引装置の構成部分を示す。図４ＡないしＤは、信託エージェントの機能部分を示す。図５は、電子マネーのオープン流通のためのネットワーク構造を示す図表である。図６Ａは、コミットプロトコールを示す。図６Ｂは、中止プロトコールを示す。図７ＡないしＧは、電あマネープロトコールにおける承認ベースの購入・販売を示す。図８ＡないしＥは、確立セッションプロトコールを示す。図９は、送りメッセージプロトコールを示す。図１０は、小切手信用状プロトコールを示す。図１１は、中止取引プロトコールを示す。図１２ＡないしＥは、マネーモジュール支払いプロトコールを示す。図１３は、信託エージェントとマネーモジュールとの間に確立される史樹のメッセージ暗号化層を示す。図１４ＡないしＥは、マネーモジュールのための確立セッションプロトコールを示す。図１５は、送りルートメッセージプロトコールを示す。図１６は、送りMM/TA メッセージプロトコールを示す。図１７は、送りTA/MM メッセージプロトコールを示す。図１８Ａ、Ｂは、マネーモジュールのための中止取引プロトコールを示す。図１９は、送りＥルートメッセージプロトコールを示す。図２０Ａ、Ｂは、取引ノートプロトコールを示す。図２１は、マネーモジュールのためのコミットプロトコールを示す。好ましい実施例の説明係属中の米国特許出願第08／234,461 号に説明したように、信託エージェントはハードウエア部分とソフトウエア部分の組み合わせである。これは耐不正使用性であり、間違いのない支払いを商品提供に同期させるためにマネーモジュールと協働する安全プロトコールを備える。マネーモジュールは、電子マネーをストアし移転することができる耐不正使用性の装置である。電子マネーは、現金又はクレジットを表す電子ノートの形態であることが好ましい。マネーモジュールは又、他の装置との間で暗号的に安全な通信を確立することができる。本発明の好ましい実施例は、係属中の米国特許出願第07／794,112 号及び08／427,287号に記載した取引マネーモジュールを利用する。信託エージェントは、ネットワークを通じて購入を行うとき、電子商品と支払いを交換する。図１に示すように、本発明においては、商人信託エージェント４（MTA）は、顧客信託エージェント２（CTA）に受領票を送る。その返信で、顧客が電子マネーを売却しようとしている場合には、顧客マネーモジュール６が、CT A ２及びMTA ４を介して電子マネーを商人マネーモジュール６に送る。顧客が電子マネーを購入しようとしている場合には、電子マネーは商人から顧客に流れることになる。チケット図１及び図２を参照すると、チケット８はMTA ４により生成され取引中にCTA ２に移転される電子的アイテムである。チケットは、信託エージェントの財産と考えることもできる。CTA ２がチケット８を受領した顧客は、取引が成功裏に完了したときにのみ該チケットを使用する。米国特許出願第08／234,461 号に説明したように、信託エージェントは、種々の目的で使用される種々の型式のチケットをサポートする。しかし、本発明にとって特に重要なものは、信用状チケットと電子マネー購入受領チケットである。信用状チケットは、「所有者」を表示し、特別の特権を認める。信用状の例としては、クレジット及び借方カードがある。クレジットチケット又は借方チケットは、承認ベースの支払いのために提示される。顧客受領チケットは、流通上の取引（電子マネーの購入又は売却）の詳細を表示し、紛争シナリオにおいて顧客により使用することができる。図２は、チケット８の好ましい実施例を示すもので、チケットは６つの主要なセクション、すなわち、識別子１０、コンポーネント１２、発行者サイン１４、発行者証明１６、取引履歴１８及び送り主サイン２０からなる。これらのセクションは、種々の情報保有フィールドからなる。識別子セクション1０は、商人又はチケットを生成する機関を識別する情報を保持する。この情報は、例えば商人の機関名であり、チケット発行者が保有する商人又は機関の信用状から複写される。フィールドは又、商人又は機関の信用状の期間満了日を含む。フィールド２４は、受取側信託エージェントの識別番号を含む。フィールド２４は又、チケット受取人の信託エージェントの信用状の満了日を含む。フィールド２６は、チケットの形式（例えば、クレジット又は借方カードチケット、受領票など）を表示する。コンポーネントセクション１２は、チケットの種類とその特定の目的で異なるチケットの基本的内容を含む。図２は、異なる形式のチケットに見られるコンポーネントの例を示す。クレジット又は借方カードのような信用状チケットは、信用状所有者の銀行を特定する銀行IＤフィールド３６と、口座番号フィールド３８と、効力発生日フィールド４０と、満了日フィールド４２と、顧客名フィールド４４を有することができる。電子マネー購入受領チケットは、顧客の信用状に表示された銀行を特定する銀行ＩＤフィールド４６と、顧客の信用状に表示された口座番号を特定する口座番号フィールド３８と、取引が電子マネーの購入であるか売却であるかを特定する取引形式フィールド５０と、送金額又は受領額フィールド５４と、商人料金フィールド５６と、取引日フィールド５８を有することができる。承認額は、購入取引の場合には受領額と商人料金の和であり、売却の場合には送金額から商人料金を差し引いた額である。チケット８の発行者サインセクション１４は、チケット生成者により識別子セクション１０及びコンポーネントセクション１２に形成されたディジタル署名を保持する。このサインは、発行者の信託エージェントに属するプライベートキーを使用してなされる。発行者証明セクション１６は、信託された第３者（以下において「信託エージェンシー」と呼ぶ）による証明を含み、この証明は、発行されたチケット８の信憑性を確認するために、発行者のサインと合わせて使用される。この証明は、発行者の信託エージェントに属する証明の形態である。証明とディジタル署名の一般的な使用は公知であり、例えば、D.W.デービス及びW.L.プライスによるコンピュータネットワークのための安全保証（ジョンワイリーアンドサンズ、1984年）に説明されている。取引履歴セクション1８は、商人又は機関によってチケット８の最初の発行後に信託エージェント間で該チケットが移転されたとき生成される情報を含む。受取人ＩＤフィールド２８は、受取側信託エージェントの識別番号を含む。送り側ＩＤフィールド３０は、送り側信託エージェントの識別番号を含む。送り側証明フィールド３２は、送り側信託エージェントの証明を含む。日時フィールド３４は、チケットの取引の日時を含む。後で移転が行われると、別の受取人及び送り側ＩＤ、送り側証明、及び日時が各フィールドに付記されて、取引履歴情報のリストを生成する。識別子セクションの受取人フィールドに見られる信託エージェントＩＤは、送り側ＩＤフィールドの最少のＩＤと同一でなければならない。さらに、チケット８が信託エージェント間で移転されるときは、常に、送り側の信託エージェントに属するプライベートキーを使用して先行する５つのチケットに送り側のディジタル署名をしなければならない。ここで、送り側サインセクション２０が新たに生成されたディジタル署名を付記することによって更新されて、送り側サインのリストを形成する。取引装置図３を参照すると、信託エージェント１２０は取引装置１２２内に内蔵されている。取引装置１２２は、商人と顧客の両方について３つの主要部分から構成されている。ホストプロセッサ１２４と、信託エージェント１２０と、マネーモジュール６がある。これらの部分は、例えばバス１２６により接続されている。信託エージェント１２０がMTA ２であると、装置１２２は商人取引装置（MTD）と呼ばれる。信託エージェント１２０がCTA ４であると、装置１２２は顧客取引装置（CTD）と呼ばれる。図３にホストプロセッサ１２４の機能部分を示す。該ホストプロセッサは、次の機能、すなわち、通信１２８と、取引アプリケーション１３０と、人・機械インターフェース１３２と、日時１３６と、メッセージマネージャー１３４の機能を提供する。通信機能１２８は、取引装置１２２と外部世界との間の通信をサポートする。この通信は、装置間で対応性があれば、有線でも無線でもよく、広帯域でも狭帯域でもよい。通信機能１２８は、２つの取引装置１２２間の接続を設定するか、又は取引装置をネットワークに接続して他の取引装置又は信託サーバーとの間で間接的な接続を形成する。取引アプリケーション１３０は、種々のタスクを達成することができる。例えば、取引アプリケーションは、電子マネーの購入又は売却取引に際して、商人取引料金が最も低いものや交換レートが最もよいものを、商人ネットワーク上で探すことができる。一般に、取引装置１２２は、電子的対象物や電子マネー、信用状、その他のチケット８を選択し、購入し、及び、時には使用することについてのすべての処理と、これらを売却するための処理を含む。人・機械インターフェース機能１３２は、取引装置１２２に対する視覚及び触覚を提供する。これは、キーボード、マウス、ペン、音声、タッチスクリーン、アイコン、メニュー等を含むことができる。この人・機械インターフェース機能１３２は、メッセージマネージャー１３４を通じて信託エージェント１２０及びマネーモジュール６内の他の機能と通信することができる。例えば、完全に自動化された商人取引装置のように、幾つかの用途においては、人・機械インターフェース機能１３２は必要ではない。日時機能１３６は、取引装置１２２の所有者により設定されるものであり、日と時間及び時間帯を含む。日時情報は、内蔵された信託エージェントが使用のために開かれたとき、該信託エージェントに与えられる。メッセージマネージャー１３４は、ホスト内メッセージ（すなわち、取引装置間のメッセージ）、及び、ホストプロセッサ１２４と信託エージェント１２０とマネーモジュール６の間のメッセージを通す。信託エージェント図４Ａは、信託エージェント１２０の機能的部分を示す。オープンな電子的商業のためのこのシステムは、３つの形式の信託エージェントを使用するものであり、これらは、それぞれが提供する独特の取引者機能１４６において相違する。図４Ｂは、CTA ２に見られる取引者機能を示す。図４Ｃは、MTA ４に見られる取引者機能を示す。図４Ｄは、機関取引装置（ATD）内に内蔵される機関信託エージェント（ATA）に見られる取引者機能を示す。ATD は、銀行のような信用状発行機関に関連付けられる。外部インターフェース機能１３８が、ホストプロセッサ１２４と信託エージェント１２０を内蔵する取引装置１２２のマネーモジュール６に対する物理的通信を提供する。メッセージインターフェース機能１４０が、エージェント間及びエージェント内のメッセージを処理し、通過させる。セッションマネージャー機能１４２が、エージェント間セッション及びエージェントと信託サーバーの間のセッションを設定し、破棄する。安全マネージャー機能１４４が、安全情報（例えば、信託エージェント証明及び信託されないエージェントのリスト）を保持し、相手方信託エージェント及び同じ取引装置１２２内の局地的マネーモジュール６に対し（ホストプロセッサを通じて）安全な通信を確立する。取引者機能１４６は、取引を行うためのプロトコールを提供する。顧客、商人及び機関取引者が、それぞれCTA 、MTA 及びATA のために使用される。図４Ｂは、顧客取引機能を示す。購入機能１５８は、チケット８及び電子的対象物に対して支払いを交換する。ホスト向け機能１６０が、取引装置のホストプロセッサ１２４へのインターフェースを提供する。チケット提供機能１６４が、情報又はサービスを受けるためのチケット８を与える。信用状取得機能１６６が信用状チケットを受けるための仲介を果たす。取引ログ機能１６２が、信託エージェント取引のログを維持する。CTA 2とMTA 4の両方が、取引ログを維持し、このログは、下記の情報、すなわち、取引の形式（例えば、チケットの形式）、取引前チケットの像、取引後のチケットの像、紛争の日付や状況及び商人の解決（例えば、交換、払戻し、否認）を含む紛争情報、再証明情報（例えば、再証明の日付）を記憶する。紛争開始機能１６８が、顧客が満足しない場合に電子商品を提示する。図４Ｃは、商人取引機能を示す。購入機能１７０が、支払いに対してチケット８と電子的対象物を交換する。ホスト向け機能１７２が、取引装置のホストプロセッサ１２４へのインターフェースを提供する。受取チケット機能１７６が、受け取ったチケット８を処理して、サービス又は情報を提供する。証明取得機能１７７が、商人の信用状を得る。取引ログ機能１７４が、信託MTA ４取引のログを維持する。紛争解決機能１７８が、チケット８と電子的対象物を受け取って、顧客の不服を解決する。図４Ｄは、機関取引者機能を示す。証明生成機能１８０が、信用状チケットを生成し、要求者に送る。ホスト向け機能１８２が、取引装置のホストプロセッサ１２４へのインターフェースを提供する。受取チケット機能１８４が、受け取ったチケット８を処理して、サービス又は情報を提供する。再有効化証明機能１８６が、現在の信用状を受けて新しい満了日を有する信用状を再発行する。取引ログ機能１８３が、取引のログを維持する。証明取得機能１８５が、機関信用状を得る。図４Ａを再び参照すると、マネーモジュール向け機能１５０が、同じ取引装置１２２内のマネーモジュール６と通信して支払いを行う。暗号機能１５２が、公開キーと対称キーの暗号機能を与える。例えば、RSA 及びDE Sのような、周知のどのような公開キー・対称キー暗号技術を用いてもよい。チケット保持者機能１４８が、MTA ４内にチケット８を生成し、或いはCTA ２にチケット８をストアしたり取り出したりする。乱数発生機能１５６が、暗号キーを形成するための乱数を発生する。日時機能１５４が、ホストプロセッサ１２４から送られる日及び時刻を管理してチケット８に日付を与え、信用状及び提示されたチケットを有効化する。信託エージェントが開かれる（すなわち、使用のために署名される）度ごとに現在クロック情報が送られ、該信託エージェントが閉じられるまで維持される。信託エージェント／マネーモジュールハードウエアは、次のもの、すなわち、取引プロトコールを実行するためのマイクロコントローラー（例えは、インテル 196 ファミリー）と、オペレーションシステムやアプリケーションの一部、暗号等を実行中に記憶するための高速揮発性メモリ（例えば、SRAM）と、オペレーションシステムやアプリケーション、チケット、電子マネー、ログ等を記憶するための非揮発性メモリ（例えば、フラッシュメモリ）と、時刻基準を与えるための集積回路クロックと、クロックのための電池と、乱数発生器のためのノイジーダイオードその他の乱数源からなる。システムの概観図５は、電子マネーのオープン流通のための提案されたシステムの全体的なネットワークアーキテクチャを示すものである。顧客取引装置１８８がゲートウエイネットワークを通じて商人と通信できる。顧客は、電子マネーの購入又は売却のために商人の電子スペースをサーチして、最低の取引料金及び／又は交換レートを提示する商人を選定することができる。そして、このシステムは、クレジット又は借方カードによる安全な承認をベースとした電子マネーの購入／売却を提供する。これは、顧客が信託エージェント１２０に信用状としてストアされたクレジット又は借方カード情報を提示することによって行われる。好ましい実施例においては、ゲートウエイ１９０は、CTD １８８がMTD １９８に接続された局地商人ネットワーク１３４にアクセスできるようにする。商人ネットワーク１３４は、商人の銀行ネットワーク２００に接続されており、この銀行ネットワーク２００は、係属中の米国取引出願第07／794,112 号に説明してあるように、マネー発生モジュール２０２、出納マネーモジュール２０４、及び銀行のオンライン会計システムを構成する銀行システム２０６を介して電子マネーにアクセスすることができる。クレジット又は借方カード信用状は処理されて、承認ネットワーク２０８を通じて顧客の銀行口座に対するクレジット又は借方の実行を行う承認が得られる。カードの承認は当業界で周知であり、十分な資金があるか、又はカード所有者のクレジット限度内である場合に、特定の支払いについて、カード発行者又はそのエージェントが承認を行うことを含む。承認ネットワークは又、例えば払い戻しを行う場合に、顧客の口座に対してクレジットを発行する。承認ネットワーク２０８は、顧客の銀行ネットワーク２００に接続され、該銀行ネットワークは、顧客の銀行口座を有する銀行システム２０６接続されている。このアーキテクチャーは、電子マネーシステムのメンバー銀行の顧客でない記名人が、メンバー銀行にアクセスを有する商人を通じて電子マネーにアクセスすることを可能にする。このシステム構造は、記名者が多くの流通点で電子マネーを売買できるようにするもので、これは、記名者の観点からは、その銀行口座に対して電子マネーを引き出し又は預け入れするのと、実効的に同じである。電子マネーシステム銀行は又、MTD １９８を通じて上述した流通サービスを提供することができる。この場合には、商人ネットワークは勿論必要でない。銀行ネットワーク２００が、単にマネー発生モジュール２０２、出納マネーモジュール２０４、銀行システム２０６、MTD １９８、承認ネットワーク２０８、及びゲートウエイ１９０に接続するだけである。その他の点では、取引は同様である。フローチャート以下の図に示されるフローチャートは、２つの相互作用する信託エージェント１２０を示すために「Ａ」及び「Ｂ」を使用する。同様な表示Ａ及びＢが、その特定の信託エージェントに関連付けられた（すなわち、同一の取引装置１２２内のもの）ホストプロセッサ１２４又はマネーモジュール６にも付されることがある。このフローチャートは、所定のタスクを達成するために主たる責任を持つ機能部分を示す。例えば、安全マネージャーＡは、信託エージェントＡ内の安全マネージャー機能１４４（図４Ａ参照）によって初期のタスクが遂行されることを意味する。このフローチャートは又、サブルーチンのコールを行うもので、該サブルーチンの幾つかは、パラメーター表示Ｘ及びＹを使用する。例えば、セッションの確立Ａ→Ｂはサブルーチン確立セッションへのコールである。次いで、セッション確立フローチャートが、Ｘ＝Ａ及びＹ＝Ｂの了解のもとにフロー全体にわたって遂行される。中止及びコミットここで説明する形式の取引処理においては、チケット８及び電子ノートのような電子アイテムを、ゼロサムゲームを維持しながら、２つのパーティー間で流通させることが望ましい。換言すると、取引の完了時点で取引前のアイテムの２倍のアイテムが存在するようになる電子アイテムの複写は望ましくない。同様に、取引後に取引前よりもアイテムの数が少なくなるように電子アイテムを減らすことも望ましくない。例えば、取引の開始時にＡが電子チケット８を持っており、これをＢに廻したいときは、取引の終わりにＢが電子チケット８を持ち、Ａが電子チケット８を持たないのを確認することが望ましい。しかしながら、実際の世界では、他の２つの結果、すなわち、Ａ及びＢの両方が同じ電子チケット８（複製）を持つか、Ａ及びＢのいずれもが電子チケット８を持たない（紛失）状態となる可能性がある。複製又は紛失の可能性を無視できるようにするためには、自然又は意図的なイベントが典型的な取引フローを中断させることがあるという可能性を、取引プロトコールが考慮するようにしなければならない。自然の中断の例は、取引中におけるＡとＢの間の通信リンクの破壊である。このようなランダムなイベントからくる複製又は紛失の可能性を最小限にするために、複製又は紛失を生じる機会となるウインドーを最少にしなければならない。意図的な中断（すなわち、明白な攻撃）を最少にするためには、そのような攻撃に対する経済的な動機をなくすことが望ましい。例えば、取引の中断を試みることで、攻撃者がチケット又はマネーを失うだけとなる場合には、攻撃者は、最初から攻撃の動機を持たなくなるであろう。この概念は、ここで説明するシステムの有効な取引プロトコールにおいて実現されている。特に、２つの取引中の信託エージェント１２０（又はマネーモジュール６）間で、一貫性ある中止とコミットの状態を確立することが望ましい。例えば、Ａが取引についてコミットすると、Ｂも又、その取引についてコミットすべきであり、また、Ａが取引を中止すると、Ｂも又、この取引を中止すべきである。一貫性を達成し、複製又は紛失（この場合には一貫性がない）の可能性を最少にするためには、取引プロトコールが、所定の取引に対するＡのコミットとＢのコミットの順序と時期を考慮する。図６は、中止及びコミットのサブルーチンを示す。中止のサブルーチンは、所定の信託エージェント１２０が関与する取引が失敗に終わったとき、該信託エージェント１２０内で内部的に実行される。中止サブルーチンは、信託エージェント１２０を、この失敗した取引に関与する前の正確な状態に戻す。加えて、商人信託エージェントが承認の後で中止を行う場合には、該承認は取り消される。逆に、コミット取引は、特定の信託エージェント１２０が関与している取引が成功裏に完了したとき、該信託エージェント内で内部的に実行される。したがって、信託エージェント１２０は、完了した取引をその取引ログに記録し、新しい取引ができる状態となる。例えば、チケット移転の取引では、電子チケット８が信託エージェントＡから信託エージェントＢに通される。この時点では、ＡもＢも、取引についてコミットも中止もしていないので、Ａが暫定的にチケット８を保持し、Ｂも又、暫定的にチケット８を保持する。ＡとＢの両方がコミットすると、Ａがチケット８を抹消し、Ｂが保持するチケット８は最早暫定的でなくなる。しかし、ＡとＢの両方が中止すると、Ａがチケット８を保持し、Ｂが暫定的に保持していたチケット８は、取引を戻すことによって抹消される。この抹消作用は、業界で周知のどのような方法によっても実行できる。前述したように、一つの信託エージェント１２０がコミットし、他方の信託エージェント１２０が中止する可能性は最少とすることが望ましい。何故ならば、これは、限定されたある事情のもとでは複製又は紛失となることがあるからである。同様な状況は、電子ノートを交換するマネーモジュール６に関しても生じる。購入取引中に、電子ノートがマネーモジュールＡからマネーモジュールＢに通され、Ａが暫定的にその電子ノートを（移転される額だけ）減額し、Ｂが暫定的に（移転される額の）電子ノートを持つ。ＡとＢの両方がコミットすると、Ａが減額したノートを保持し、Ｂの電子ノートの保持は最早暫定的ではなくなる。図６Ａは、コミットサブルーチンを示す。取引ログＸが取引ログを更新する。ホスト向けＸが、取引が完了したことをホストに知らせる。セッションマネージャーＸは、セッションの終わりを記録する（ステップ２３０ないし２３４）。図６Ｂは、中止サブルーチンを示す。セッションマネージャーＸは、変更を元に戻し、エージェントが中止したことを記録する。セッションマネージャーは、セッションの初めから何がなされたか、これらのステップを何時取り消したかの履歴を維持する。ホスト向けＸは、取引が中止されたことのメッセージをホストに送る（ステップ２３６ないし２３８）。中止サブルーチンは、例えば、信託エージェント１２０が信用状は有効でないと判断したときに、フロー図から直接にコールされる。中止サブルーチンは又、期待した作用が生じないときにコールされる。特に、２つの信託エージェント１２０が通信しているときに、これらエージェントはタイムアウトプロトコールをモニターする。例えば、第１の信託エージェント１２０が第２の信託エージェント１２０にメッセージを送った後に、回答が必要な場合には、第１の信託エージェントＡのセッションマネージャーが、回答のための時間を設定する。セッションマネージャーは又、送られたメッセージに番号を付ける。この番号は、第２の信託エージェントＢのセッションマネージャーからの回答メッセージにも表される。メッセージを受信する前に時間が過ぎると、セッションマネージャーＡはセッションマネージャーＢに対して該取引がBにおいてまだ継続中であるかどうかを確認する。もしＢが回答しない場合には、セッションマネージャーＡは取引を中止する。取引が継続中であるとの回答が得られると、タイマーが新しい時間にリセットされる。最初のメッセージに対する回答がない状態でＡがＢに対して所定回数の問い合わせをした場合には、Ａは取引を中止する。マネーモジュール６にも同様なタイムアウト機能が存在する。電子マネーの売買図７は、承認をベースとした電子マネーの売買のためのフローチャートを示すものである。信託エージェントＡの所有者が、その銀行口座に借方又はクレジット処理をして電子マネーの購入又は売却をしたい場合には、そのCTD １８８内の取引アプリケーションを使用して、最低の商人取引料金及び／又は交換レートを商人ネットワークで探し、本例では信託エージェントＢの所有者である商人を選択する（ステップ７００ないし７０２）。別の態様として、承認ネットワークが交換レートを設定することもできる。次いで、ホスト取引アプリケーションＡ（HTA）は、ホスト取引アプリケーション（HTB）に接続し、ここで顧客が取引の形式、すなわち、電子マネーの購入又は売却を選ぶ（ステップ７０４）。HTA はその信託エージェントＡに電子マネーを購入（売却）するメッセージを送り、HTB はその信託エージェントＢに電子マネーを送金（受領）するメッセージを送る（ステップ７０６ないし７０８）。顧客及び商人の信託エージェント（Ａ及びＢ）は、次に係属中の米国特許出願第08／234,461 号に説明したセッションを確立する。特に、信託エージェントＡと信託エージェントＢの間に暗号的に安全な通信チャンネルを設定するために、セッション確立サブルーチンがコールされる（ステップ７１０）。図８を参照すると、信託エージェントＡのセッションマネージャーが＠安全マネージャーに対してＡの信用状（すなわち、cert（TA））を要求し、これを受け取る（ステップ２９６ないし２９８）。次いで、セッションマネージャーＡが信託エージェントＢのセッションマネージャーにcert（TA）を送り、信託エージェントＢのセッションマネージャーは、これをその安全マネージャーに通す（ステップ３００ないし３０４）。信託エージェントＢの公開キー機能は、係属中の米国特許出願第08／234,461 号及び08／427,287 に記載されたプロトコールのような有効化プロトコールを使用してcert（TA）を証明する（ステップ３０６ないし３０８）。 cert（TA）が有効でなければ、セッションマネージャーＢは該セッションが終了したことを記録し、セッションマネージャーＡに取引が否定されたことを通報する。セッションマネージャーＡも又、該セッションが終了したことを記録する（ステップ３１０ないし３１２）。cert（TA）が有効であれば、安全マネージャーＢは信託エージェントＡが非信託リストに記載されているかどうかをチェックする（ステップ３１４ないし３１６）。信託エージェントＡが信託されていない場合には、セッションは終了される（ステップ３１０ないし３１２）。Ａが非信託リストに記載されていない場合には、乱数発生器Bが乱数Ｒ（Ｂ）とＢ証明メッセージを生成する（ステップ３１８）。乱数Ｒ（Ｂ）は、最終的にはセッションキーを形成するために使用される。Ｂ証明メッセージは乱数であって、メッセージのリプレイに対する保護のためにＢにより使用される。次に、安全マネージャーＢが、Ｒ（Ｂ）とＢ証明メッセージとcert（TA）を集めてメッセージとして信託エージェントＡに送る（ステップ３２０）。公開キーＢが、Ａの cert（TA）とともに受け取ったＡの公開キー（TA(PK)）を使用して、メッセージを暗号化する（ステップ３２２）。セッションマネージャーＢは、この暗号化されたメッセージをＡのセッションマネージャーに送る（ステップ３２４ないし３２６）。公開キーＡは、そのプライベートキー（その公開キーに対応する）を使用してメッセージを解読し、cert（TA）の有効性を証明する（ステップ３２８ないし３３０）。もし、cert（TA）が無効であれば、セッションマネージャーＡは該セッションが終了したものとして記録し、取引否定メッセージをＢに送り、Ｂのセッションマネージャーも又、このセッションが終了したものと記録する（ステップ３３２ないし３３４）。cert（TA）が有効であれば、安全マネージャーＡは、信託エージェントＢが非信託リストに記載されていないかをチェックする（ステップ３３６ないし３３８）。信託エージェントＢがリスト上にあれば、セッションは終了する（ステップ３３２ないし３３４）。もし、Ｂが非信託リストになければ、乱数発生器Ａが括数Ｒ（Ａ）とＡ証明メッセージ（例えば、他の乱数）を生成する（ステップ３４０）。日時機能が現在の日付と時刻を安全マネージャーに通す（ステップ３４２）。日付と時刻は、コミットに際して互いの取引ログに記録するために、ＡとＢの間で交換される。安全マネージャーＡは、ここで、乱数Ｒ（Ａ）とＲ（Ｂ）をイクスクルーシブＯＲ処理することによりセッションキー（TA／TA）を形成し、ストアする（ステップ３４４）。セッションキー（TA／TA）は、２つの信託エージェント１２０間の通信を暗号化するために使用される。セッションマネージャーＡが、Ａ及びＢの証明メッセージと日時情報とＲ（Ａ）を含むメッセージを集める。公開キーＡが、信託サーバーＢの公開キー（cert（TA）においてＡが受ける）によりこのメッセージを暗号化し、暗号化したメッセージを信託サーバーＢのセッションマネージャーに送る（ステップ３４６ないし３５０）。公開キーＢは、その秘密キー（その公開キーに対応する）を用いて受け取ったメッセージを解読する（ステップ３５２）。安全マネージャーＢは、Ａから受け取ったＢ証明メッセージが、ＢがＡに前に送ったＢ証明メッセージと同じかどうかをチェックする（ステップ３５４ないし３５６）。それが同じでなければ、このセッションは終了される（ステップ３１０ないし３１２）。もしそれが同じであれば、セッションマネージャーＢはセッションの開始を記録する（ステップ３５８）。安全マネージャーＢは、Ｒ（Ａ）ＸＯＲＲ（Ｂ）によりセッションキー（TA ／TA）を形成し、該セッションキーをストアする（ステップ３６０）。この点において、Ａ及びＢの両方が、それらの現在の相互作用のために使用される同じセッションキー（すなわち、セッションキー（TA／TA））を形成したことになる。次に、日時Ｂが、日時情報を安全マネージャーＢに送る（ステップ３６２）。安全マネージャーＢは、Ａへの受取を有するメッセージと、Ａ証明メッセージと、Ｂの日時情報とを集める（ステップ３６４）。次に、メッセージ送りサブルーチンがコールされ（ステップ３６６）、メッセージをＢからＡに送る。図９を参照すると、信託エージェントＢの対称キー機能がセッションキー（TA ／TA）を使用してメッセージを解読する（ステップ３７６）。次いでメッセージインターフェースＢが該メッセージをフォーマットし、これをホストプロセッサのメッセージマネージャーに送る（ステップ３７８）。ホストメッセージマネージャーＢは、次に該メッセージを信託エージェントＡのホストプロセッサ内にあるホストメッセージマネージャーＡに通信を介して通す（ステップ３８０）。次に、ホストメッセージマネージャーＡは、該メッセージを信託エージェントＡのメッセージインターフェースに送り、該インターフェースは、このメッセージを裸にする（ステップ３８２ないし３８４）。対称キーＡがセッションキー（TA／ TA）によりメッセージを解読し、セッションキー（TA／TA）を使用して信託エージェントと信託エージェントの間の安全な通信を完了する（ステップ３８６）。図８を再び参照すると、安全マネージャーＡは、受取とＡ証明メッセージとＢの日時情報とを受ける（ステップ３６８）。安全マネージャーＡは、このＡ証明メッセージが、Ａが前にＢに送ったＡ証明メッセージと同じであるかどうかをチェックする（ステップ３７０ないし３７２）。もしそれが同じでなければ、セッションマネージャーＡは、該セッションを終了する（ステップ３３２ないし３３４）。もしそれが同じであれば、セッションマネージャーＡはセッションの開始を記録する（ステップ３７４）。図７を再び参照すると、セッションの確立の後に、信託エージェントＡは、米国特許出願第08／234,461 号に記載されているように、信託エージェントＢの商人の信用証明書を要求し、チェックする。特に、図１０を参照すると、信用証明チェックサブルーチンがコールされる（ステップ７１２）。すべてのMTD １９８は、所有者／商人を識別する信用証明書（例えば、NYNEX、Ticketron 等）を含んでいる。このような商人信用証明書は、例えば、信託エージェンシーによりコントロールされる商人識別機関により発行される。他方、CTD により保持される顧客信用証明書としては、運転免許証又は種々の識別機関により発行されるクレジットカードがある。図１０を参照すると、購入Ａが信託エージェントＢの購入Ｂにメッセージを送って、その商人信用証明書を要求する（ステップ４４４ないし４４８）。チケット保持者Bは、その商人信用証明書を取り出して、該信用証明書を有効化のためにＡに送る（ステップ４５０ないし４５６）。信用証明書又は他の何らかの形式のチケット８は、次のようにして有効化される。１）発行者の証明を有効化し、発行者の署名をチェックする。２）各移転を承認し、受取側と送り側の識別子をマッチさせる（すなわち、S₀=発行者、R₀=第１の受取側とすると、Ｒ_i= Ｓ_i+1、ｉ≧0）。３）各送り側の証明書を有効化し、各送り側の署名をチェックする。４）最後の受取側の識別子が現在のセッションの信託エージェント内の証明書（cert（TA））の識別子（TA（id））にマッチすることを認定する。商人の信用証明書が有効でない場合には、取引中止サブルーチンをコールすることによって取引が中止される（ステップ４５８）。図１１を参照すると、信託エージェントＡが中止をし（ステップ３８８）、そのセッションマネージャーがメッセージを信託エージェントＢのセッションマネージャーに送って、ＢにＡが中止したことを知らせる（ステップ３９０ないし３９４）。信託エージェントＢが次いで中止をする（ステップ３９６）。図１０を再び参照すると、商人の信用証明書が有効であれば、ホスト向けＡが、信用情報を確認のためにホスト移転アプリケーションに送る（ステップ４６０ないし４６２）。図７を再び参照すると、電子マネーの購入／売却のためのフローが続く。ホスト向けＡが、購入又は売却しようとする電子マネーの額と金銭単位（例えば、ドル、円、ポンド等）を要求する（ステップ７１４）。顧客又は代わりのプロセスが、この情報を入力し、これは購入Ａにより受けられて、信託エージェントＢに送られる（ステップ７１６ないし７１８）。購入Ｂがこのメッセージを受けて、電子マネーを受けることになっているかどうか、のチェックを行う（ステップ７２０ないし７２２）。もしそうであれば、該購入Ｂは、信託エージェントＡにメッセージを送り、銀行クレジット又は借方信用状を要求する（ステップ７５０ないし７５２）。チケット保持者Ａがメッセージを受けて、可能な信用状のリストをHTA に送る（ステップ７５４）。信用証明書が抽出され、選択したものが信託エージェントＡに送られる（ステップ７５６）。次いで、チケット保持者Ａは、選択したクレジット又は借方カード信用状及び購入Ａを取り出して、信託エージェントＢに送る（ステップ７５６ないし７６２）。次いで、購入Ｂは、前述した信用証明書を有効化する（ステップ７６４ないし７６６）。信用証明書が有効でなければ、取引は中止される。もしこれが有効であれば、チケット保持者Ｂは電子マネー購入受取を生成し、購人Ｂがこの受取を信託エージェントＡに送る（ステップ７６８ないし７７２）。購入Ａは、この受取を受けて、それが有効であるかどうかをチェックする（ステップ７７４ないし７７６）。有効でなければ、取引は中止される。もしこれが有効であれば、購入Ａは受取情報をHTA に送って購入確認を行う（ステップ７８０ないし７８２）。確認が行われないと、取引は中止され、その他の場合には購入Ａは受取をチケット保持者Ａに送る（ステップ７８４ないし７８６）。次いで、購入Ａは、受取を表すメッセージを信託エージェントＢに送る（ステップ７８８ないし７９０）。ここで、購入Ｂは電子マネーを受け取ることになっているがどうかをチェックする（ステップ７９２ないし７９４）。もしそうであれば、ホスト向けＢが、額と信用証明書についてのメッセージをカード承認ネットワーク２０８に送り、信用証明書に表示される銀行口座をクレジットする（ステップ７９６）。カード承認過程（ステップ７９８）の後で、購入Ｂは、クレジットが承認されたかどうかをチェックする（ステップ８００ないし８０２）。もし承認がなければ、取引は中止され、その他の場合には、購入Ｂはクレジットが承認されたことのメッセージを信託エージェントＡに送る（ステップ８０４ないし８０６）。次いで、信託エージェントＡは、米国特許出願第08／234,461 号に記載されたように、信託エージェントＢに対してマネーモジュール支払いを行う。特に、マネーセッション支払いサブルーチンがコールされる（ステップ８０８）。図１２を参照すると、乱数発生器Ａが乱数Ｒ(1)を生成する（ステップ５２０）。次に、購入Ａが、「マネーモジュール支払い」がなされる旨とＲ(1)を含むメッセージを信託エージェントＢに送る（ステップ５２２ないし５２４）。購入Ｂは、このメッセージを受けて、Ｒ(1)を安全マネージャーＢに送る（ステップ５２６ないし５２８）。乱数発生器Ｂが乱数Ｒ(2)を生成し、信託エージェントＡに送る（ステップ５３０ないし５３２）。安全マネージャーＡ及びＢの両方が、Ｒ(1) とＲ(2)をイクスクルーシブＯＲ処理することにより、セッションキー（TA／MM ）を生成する（ステップ５３４ないし５３６）。図１３を参照すると、取引中に確立される４つの暗号化チャンネルが示されている。２つの信託エージェント１２０間の暗号化チャンネル４３６は、セッションキー（TA／TA）により暗号化されたメッセージを運ぶ。信託エージェント１２０とそのマネーモジュール６の間のチャンネル４３８及び４４０は、セッションキー（TA／MM）を共有する。異なる取引装置１２２のマネーモジュール６間のチャンネル４４２は、セッションキー（MM／MM）を使用する。セッションキー（TA／MM）は、信託エージェント１２０とそれに関連付けられたマネーモジュール６との間で送られるメッセージを、暗号化チャンネル４３８及び４４０を介して暗号化するために使用される。フローチャートのこの時点では、２つの信託エージェント１２０だけがセッションキー（TA／MM）を持っている。両方のマネーモジュール６は、フローチャートの後の方で、セッションキー（TA／MM）のコピーを作り、信託エージェント１２０とそのマネーモジュール６との間の暗号化された通信を可能にする。信託エージェント１２０とマネーモジュール６を耐不正使用性個別部分として構成する代わりに、これらを一つの耐不正使用性モジュールとして製造することも可能である。この場合には、同一の取引装置１２２内では、信託エージェント１２０とマネーモジュール６との間の通信に安全セッションを確立する必要はない。しかし、マネーモジュール６と信託エージェント１２０を個別の部分として構成すると適用に柔軟性が得られるので、この構成の方が好ましい。図１２を再び参照すると、マネーモジュール向けＡは、「支払いせよ」メッセージとＲ(1)を、それに関連付けられたマネーモジュールＡに送る。また、マネーモジュール向けＢは、「支払い受け取り」メッセージとＲ(2)をそれに関連付けられたマネーモジュールＢに送る（ステップ５３８ないし５４４）。この段階で、マネーモジュールＡ（CTA ２内の）とマネーモジュールＢ（MTA ２内の）が、それらの間でセッションを確立し、各マネーモジュール６が新しいセッションキー（MM／MM）を持って立ち上がる（ステップ５４６）。このマネーモジュールとマネーモジュールの間のセッションを確立するにあたって、マネーモジュールは、予め存在していた信託エージェントのセッションを介してメッセージを交換する。図１３を参照すると、暗号化チャンネル４４２のためのセッションキーが、チャンネル４３６内で暗号化されたメッセージを交換することによって形成される。マネーモジュールセッションが確立された後、マネーモジュール間で送られるメッセージは、信託エージェント１２０間の通信経路の一部において、セッションキー（MM／MM）とセッションキー（TA／TA）の両方により、２度暗号化される。好ましい実施例では、マネーモジュールセッションが、信託エージェントセッションの確立と同様な手法で確立される。したがって、マネーモジュール６は、公開キーを含むそれ自身の証明書を保持することになる。証明書と乱数を（ＸＯＲのために）交換することで、セッションキー（MM／MM）の安全な生成が可能になる。マネーモジュールにより使用されるセッション確立プロトコールは、米国特許出願第08／427,287 号に記載されており、図１４に示されている。安全維持Ａは、モジュール信用証明書をセッションマネージャーに送り、セッションマネージャーＡがこの証明書を受け取って、マネーモジュールＡがネットワークに接続されているかどうかをチェックする（ステップ１４６４ないし１４６６）。マネーモジュールAがネットワークに接続されていない場合には、セッションマネージャーＡは、安全維持Ａから受け取った証明書を宛先Ｂに送る（ステップ１４７６）。別に、マネーモジュールＡがネットワークに接続されている場合には、対称キーＡがＫで証明書を暗号化し、セッションマネージャーＡが暗号化された証明書をネットワークサーバーに送る（ステップ１４６８ないし１４７２）。ネットワークサーバーは、Ｋで証明書を解読し、この証明書を宛先Ｂに送る。証明書がネットワークサーバーから送られたか、セッションマネージャーＡから送られたかに係わりなく、セッションマネージャーＢがこの証明書を受け取って、安全維持Ｂ（もしＢが安全サーバーであれば、この機能はセッションマネージャーにより達成される）が証明書を有効化する（ステップ１４８０ないし１４８２）。証明書が有効でなければ、セッションマネージャーＢはこのセッションが終了したことを記録し、加入者又は銀行に通報する（ステップ１４８６ないし１４９２）（もしＢが安全サーバーであれば、Ｂは取引が終了したことを記録するだけである。）証明書が有効であれば、安全維持Ｂは、Ａが不良識別リストに載っていないかどうかをチェックする（ステップ１４９４ないし１４９６）。Ａがリストにある場合には、セッションは終了される。Ａがリストになければ、乱数発生器Ｂが乱数Ｒ（Ｂ）とＢ承認メッセージを生成する（ステップ１４９８）。クロック／タイマーＢが日時を取り出す（ステップ１５００）。安全維持Ｂが、Ｒ（Ｂ）とＢ承認メッセージとメッセージ内の日時を集める（ステップ１５０２）。公開キーＢがＡの公開キーでメッセージを暗号化し、セッションマネージャーＢがＢの証明書を暗号化したメッセージに付けて、該メッセージをＡに送る（ステップ１５０４ないし１５０６）。セッションマネージャーは、このメッセージを受け取り、公開キーＡがメッセージの暗号化部分を解読し、安全維持ＡがＢの証明書を有効化する（ステップ１５０８ないし１５１４）。証明書が有効でなければ、セッションマネージャーＡはセッションの終了を記録し、加入者又は銀行に通報する（ステップ１５１６ないし１５２２）。証明書が有効であれば、安全維持Ａは、Ｂが不良識別リストに載っていないかどうかをチェックする（ステップ１５２４ないし１５２６）。Ｂがリスト上にあれば、セッションは終了される。Ｂがリストになければ、安全維持Ａは日時を取り出し、それをＢの日時と比較する（ステップ１５２８ないし１５３０）。日時が範囲外であれば、セッションは終了される。日時が範囲内であれば、乱数発生器Ａは乱数Ｒ（Ａ）とＡ証明メッセージを生成する（ステップ１５３２）。ここで、安全維持Ａが、Ｒ（Ａ）とＲ（Ｂ）のＸＯＲ演算によりセッションキーを生成する（ステップ１５３４）。Ａ証明メッセージとＢ証明メッセージと時刻と日付及びＲ（Ａ）がメッセージに集められ、Ｂの公開キーにより暗号化される（ステップ１５３６）。このメッセージは、セッションマネージャーＡによりＢに送られる（ステップ１５３８）。セッションマネージャーＢは、このメッセージを受け取り、公開キーＢが該メッセージを解読し、安全維持ＢがＢ証明メッセージをチェックする（ステップ１５４０ないし１５４６）。Ｂ証明メッセージが正しくなければ、セッションは終了される。Ｂ証明メッセージが正しければ、安全維持ＢがＲ（Ａ）とＲ（Ｂ）のＸＯＲによりセッションキーを形成する（ステップ１５４８）。日時が取り出され、Ａの日時と比較されて、それらが互いに所定の範囲内かどうかがチェックされる（ステップ１５５０）。日時が範囲外であれば、セッションは終了される。日時が範囲内であれば、セッションマネージャーＢはセッションの開始を記録する（ステップ１５５２）。ここで、セッションマネージャーＢは、受取及びＡ証明メッセージをＡに送る（ステップ１５５４ないし１５５６）。セッションマネージャーＡはこのメッセージを受け取り、安全維持ＡがＡ証明メッセージをチェックする（ステップ１５５８ないし１５６２）。証明メッセージが正しくなければ、セッションは終了される。証明メッセージが正しければ、セッションマネージャーＡは、セッションの開示を記録する（ステップ１５６４）。マネーモジュールに関連する全体的なシステム安全性は、信託エージェント１２０のそれと一体にしてもよいが、システム安全性とシステムの柔軟性を高めるためには、これらは別にすることが好ましい。図１２に戻ると、マネーモジュールＡはマネーモジュールＢにＲ(1)を送る。この機能は、マネーモジュールＡ内にあるMM安全維持Ａアプリケーションにより開始することができる（ステップ５４８）。このアプリケーション及び他のマネーモジュールアプリケーションは、表示MMを付してあり、本出願人に譲渡された米国特許出願第07／794,112 号に説明されており、米国特許出願第08／234,461 号に開示した修正又は追加とともに使用することができる。乱数Ａ(1)は、マネーモジュールＡからルートメッセージ送りサブルーチンによりマネーモジュールＢに送られる（ステップ５５０）。図１５を参照すると、 MM対称キーＡがセッションキー（MM／MM）によりメッセージ（Ｒ(1)を含む）を暗号化する（ステップ６４０）。MMセッションマネージャーＡは、このメッセージを信託エージェントＡのメッセージインターフェースＡに送る（ステップ６４２ないし６４６）。次いで、信託エージェントＡがこのメッセージをメッセージ送りサブルーチンを使用して信託エージェントＢのメッセージインターフェースＢに送り（ステップ６４８）、信託エージェント間で、セッションキー（TA／TA ）により暗号化及び解読が行われる。メッセージインターフェースＢは、ここでホストメッセージマネージャーＢを介してマネーモジュールＢ内のMMセッションマネージャーＢにメッセージを送る（ステップ６７５０ないし６５４）。最後に、MM対称キーＢがセッションキー（MM／MM）によりメッセージを解読する（ステップ６５６）。図１２を再び参照すると、MM安全維持Ｂ（マネーモジュールＢ内の）がＲ(1) とＲ(2)をイクスクルーシブＯＲ処理することによりセッションキー(TA／MM)を形成する。マネーモジュールＢがマネーモジュールＡにＲ(2)を送り、該モジュールＡがＲ(1)とＲ(2)をイクスクルーシブＯＲ処理することによりセッションキー（ TA／MM）を形成する（ステップ５５２ないし５５６）。この段階で図１３を参照すると、（MM／MM）、（MM／TA）、（TA／TA）の３つのセッションキーが存在する。したがって、図示される４つの暗号化チャンネルが存在することになる。図１２を参照すると、MM加入者向けＡが、信託エージェントＡにノートの形式（例えば、ドル、円、ポンド等）による支払いを促す（ステップ５５８）。ここに参照として組み入れる米国特許出願第07／794,112 号に記載されたマネーモジュールは、マネーモジュールの所有者／保持者との通信に、加入者向けアプリケーションを一般に使用する。しかし、本例で使用するように、加入者向けアプリケーションは、信託エージェント１２０と通信して史樹の情報を得る。ここで、信託エージェント１２０は、支払い額及びノート形式の情報を送る（信託エージェントＡは前もってCTD ｋ所有者／保持者と通信して額を決定している）。マネーモジュール６から信託エージェント１２０への促しは、MM／TAメッセージ送りサブルーチンにより送られる（ステップ５６０）。図１６を参照すると、 MM対称キーＡが、セッションキー（TA／MM）によりメッセージを暗号化する（ステップ６５８）。セッションマネージャーＡは、ホストメッセージマネージャーＡを通してメッセージを信託エージェントＡのメッセージインターフェースに送る（ステップ６６０ないし６６４）。対称キーＡは、セッションキー（TA／MM）でメッセージを解読する。図１２に戻ると、信託エージェントＡの購入Ａが、金額（選択した商品の価格）をノートの形式で表示して、マネーモジュールＡのMM 支払い／交換Ａに送る（ステップ５６２ないし５６６）。このメッセージは、TA ／MMメッセージ送りサブルーチンを介して送られる（ステップ５６４）。図１７を参照すると、対称キーＡがセッションキー（TA／MM）でメッセージを暗号化する（ステップ６６８）。メッセージインターフェースＡがホストメッセージマネージャーＡを介してマネーモジュールＡのMMセッションマネージャーにメッセージを送る（ステップ６７０ないし６７４）。最後に、キー（TA／MM）でメッセージを解読する（ステップ６７６）。図１２を参照すると、MMノートディレクトリーＡが、マネーモジュール６が支払いをカバーするのに十分な資金を持っているかどうかをチェックする（ステップ５６８ないし５７０）。不十分であれば、マネーモジュールＡ、Ｂは取引を中止する（ステップ５７２ないし５８２）。 MM取引中止プロトコール（ステップ５８２）は、米国特許出願第08／427,287 号に説明され、図１８に示された好ましい電子マネーシステムのそれでよい。セッションマネージャーＸが変更を元の状態に戻し、取引が中止されたことを記録する（ステップ１７２６）。次いで、セッションマネージャーＸが、「コミット準備完了」メッセージが送られたかどうかをチェックする（ステップ１７２８ないし１７３０）。もしそうであれば、Ｘは、コミット準備完了メッセージを送った後にＸがコミットしたことを記録し、ノート識別子とノート移転プロトコール中に受け取った各ノートの額を記録することによって取引ログを更新する（ステップ１７３２）。コミットサブルーチンが失敗して中止サブルーチンがコールされたときには、中止プロトコールが情報をログする。Ｘか取引マネーモジュール１１８６であり、コミット準備完了メッセージが送られた場合には、加入者向けＸが、加入者に取引が中止されたこと、及びマネー移転エラーが生じたかも知れないこと、を知らせる（ステップ１７３４ないし１７３８）。Ｘが出納モジュール１１８８であれば、銀行向けＸが、銀行に対して、その会計取引を（適当な請求書及びクレジットにより）元に戻すべきである旨を通知する（ステップ１７４０ないし１７４２）。Ｘが取引マネーモジュール１１８６であり、コミット準備完了メッセージが送られていなければ、加入者向けＸは、加入者に対して、取引が中止されたことを通報する（ステップ１７４４）。いずれにしても、セッションマネージャーＸは、ここでＹに対して取引が完了できないことのメッセージを送る（ステップ１７４６ないし１７４８）。セッションマネージャーＹは、その変更を元に戻し、取引を中止されたものとして記録する（ステップ１７５０）。次いで、Ｙは、その加入者に対して、取引が中止されたことを通報するか（ステップ１７５４）、又は、銀行に対して、その会計取引を元に戻すことを通報する（ステップ１７５６ないし１７５８）。前述のように、コミットプロトコール中に取引が中断されると、ノートが紛失する可能性がある。もしこの状態が生じれば、受け取り側は中止となり、送り側はノートの移転をコミットした状態となる。この場合には、受け取り側のマネーモジュールが、該モジュールが受け取ったに違いないノートについてい情報を記録し、加入者に対して、問題の可能性（すなわち、マネーモジュールはＡから送られたノートを受け取らなかったこと）があることを知らせる。この場合には、送り側のマネーモジュールに関する限り、該モジュールは、適切にノートを送っているのである。ここで、受け取り側のマネーモジュールの加入者は、証明エージェンシーに対して、そのマネーについてのクレームを申し立てる。クレーム情報は、失敗した取引のログ記録を含む。証明エージェンシーは、ここで発行銀行をチェックし、ノートが戻っていないかどうかを調べる。ある程度の時間の後、ノートが戻っていなければ、加入者はそのマネーについて再度クレームすることができる。図１２を再び参照すると、マネーモジュールＡとマネーモジュールＢの間のメッセージは、３つのセッションキー（MM／MM）、（TA／MM）、（TA／TA）のすベてを利用するＥルートメッセージ送りサブルーチンにより送られる。図１９を参照すると、MM対称キーＡがセッションキー（MM／MM）によたメッセージを暗号化する（ステップ６７８）。次いで、このメッセージは、信託エージェントＡに送られる前にセッションキー（MM／TA）により２重に暗号化される。このメッセージは、信託エージェントＡにより受け取られると、セッションキー（MM／TA）により解読される（ステップ６８０）。メッセージインターフェースＡは、ここでメッセージをメッセージインターフェースＢに送る（ステップ６８２ないし６８４）。信託エージェント１２０間で、メッセージはセッションキー（TA／TA）により２重に暗号化される。同様にして、メッセージインターフェースＢはメッセージをMM対称キーＢに送り最終の解読を行う（ステップ６８６ないし６９０）。図１３に、種々の解読用法則を示す。図１２を再び参照すると、マネーモジュールＡ、Ｂの中止サブルーチン（ステップ５８２）中に、これらモジュールは、それぞれの信託エージェントＡ、Ｂに送られるメッセージを生成して（ステップ５８４ないし５８６）、該モジュールが取引を中止し、支払いが不成功であったことを通報する。セッションマネージャーＡ、Ｂは、支払いが不成功で、したがって、信託エージェントＡ、Ｂが中止したことを記録する（ステップ５８８ないし５９８）。他方、顧客のマネーモジュール２が十分な資金を持っている場合には、MM支払い／交換Ａが、支払いにおいて移転されるべきマネージャーの額とノートの形式を含むメッセージを商人のマネーモジュールに送る（ステップ６００）。このメッセージは、Ｅルートメッセージ送りサブルーチンにより送られる（ステップ６０２）。マネーモジュールＢはマネーモジュールＡによる支払い額を含むメッセージを受ける。MM加入者向けＢは、ここで、この支払い額を確認するように信託エージェントＢに促しを送る（ステップ６０４ないし６０６）。したがって、信託エージェントＢの購入Ｂが額が正しいかどうかを確認する（ステップ６０８ないし６１０）。もし正しければ、信託エージェントＢは「正確な額」メッセージをマネーモジュールＢに送る。もし不正確であれば、「不正確な額」メッセージが送られることになる（ステップ６１２ないし６１６）。「不正確な額」メッセージの場合には、マネーモジュールＢはマネーモジュールＡに通報し、マネーモジュールＡは、その信託エージェントに新しい額を再送するように要求するか、又は中止をする（ステップ６１８ないし６２２、５７２ないし５８２）。電子商品の購入中に行われるマネーモジュール支払いでは、信託エージェントは新しい額を送ることをせず、両方のマネーモジュール６と両方の信託エージェント１２０が中止となる。他方、マネーモジュールＢが「正確な額」のメッセージをその関連する信託エージェントＢから受けたときには、マネーモジュールＢは、顧客のマネーモジュールに対して受取メッセージを送り返す（ステップ６２４ないし６２６）。MM支払い／交換Ａは、受取メッセージを受けると、その額をマネー保持者Ａ（マネーの電子的表現を含み管理するアプリケーション）に送る（ステップ６２８）。上述した支払い者主導のプロトコールの代わりに、ＰＯＳ支払いプロトコールにおけるように、受取者主導の支払いの形で実行することもできる。そのようなプロトコールの場合、商人の信託エージェントが、受取予定の支払い額についてそのマネーモジュールに指示を与え、この支払い情報が顧客のマネーモジュールに送られて、顧客のマネーモジュールが、その信託エージェントに確認を促し、額が正しければ顧客の信託エージェントはそのマネーモジュールに通報する。図１２を再び参照すると、顧客のマネーモジュールＡは、ここで、特定された額の電子ノートを商人のマネーモジュール４に対しＥルートメッセージ経路を通じて送る（ステップ６３０）。図２０は、米国特許出願第08／427,287 号に説明されたノート移転プロトコールを示す。ノートディレクトリーＸが、移転されるノートと価値を選択し、ノート額と順序番号を更新し、メッセージをノートに送る（ステップ１５６６）。移転のためのノートを選択することの目的としては、例えば、(1)ディジタル署名（処理時間を必要とする）の数を最少とする、(2)パケットのサイズを最少にする、(3)送り側加入者に残された電子ノートの有用性を最大にする（すなわち、満了までの残存期間が最も短いノートを送る）ことが挙げられる。この目的は、次のノート移転アルゴリズムにより達成される。(1) 最少数のノートを含む可能性ある組み合わせをすべて求める、(2)にれらの組み合わせのいずれが最少の移転回数ですむかを求める、(3)ステップ２で２つ以上の可能性が残されていたときには、マネーユニット日付が最少の数となるものを選択する。マネーユニット日付は、移転されるノートの残存価値に該ノートが満了する迄に残された日数を乗じたものであり、パケット内のすべてのノートについて合計する。ノートＸは、ノートディレクトリーＸからメッセージを受けたとき、移転される各ノートに付加すべきトランスファーを生成する。公開キーＸがノートのための署名を生成する（ステップ１５７０）。ここで、パケットマネージャーＸが、パケット内に新しいトランスファーと署名を集めて該パケットをＹに送る（ステップ１５７２ないし１５７４）。パケットマネージャーＹは、このパケットを受け取って、分解する（ステップ１５７６）。ベリファイヤーＹは、ノート内のすべての証明書（例えば、マネージェネレーター証明書及びすべてのトランスファー証明書）を有効化する。次いで、ベリファイヤーＹは、トランスファーグループ内の識別番号が、署名内の証明書及び電子ノートの履歴を通じての証明書グループのモジュール識別番号と一致するかどうかを確認する。さらに、電子ノートの履歴全体を通じて相続く移転の各々における移転額がその直前の移転の額よりも小さいことを確認することにより、各ノートについての移転額の一致性が有効化される。これに加えて、移転される総額が、予定される額であるかどうかを確認することによってチェックされる（ステップ１５７８ないし１５８０）。有効でなければ、取引は中止される（ステップ１５８２）。有効であり、Ｙが取引マネーモジュールであれば、ベリファイヤーＹはノートの満了日を確認する（ステップ１５８４ないし１５８８）。いずれかのノートが期間満了であれば、取引は中止される。いずれも期間満了でなければ、ベリファイヤーＹは、移転ノートの各識別子を不良識別子リストと対比してチェックする（ステップ１５９０ないし１５９２）。移転される識別子が不良リストにある場合には、取引は中止される。移転される識別子が不良リストになければ（又はＹが取引マネーモジュールでなければ）、公開キーＹがノート署名の有効性を確認する（ステップ１５９４ないし１５９６）。いずれかの署名が有効でなければ、取引は中止される。署名が有効であれば、ベリファイヤーＹは、ノートボデーがノートアプリケーション内にストアされた又は取引ログ内に置かれたノートボデーと一致するかどうかをチェックする（ステップ１５９８ないし１６００）。一致するノートボデーの各々について、ノート移転ツリーが生成され、ノートの重複がないかどうかが調べられる（ステップ１６０２ないし１６０４）。いずれかのノートが重複している場合には、取引は中止される。この重複チェック（すなわち、ステップ１５９８ないし１６０４）は、コンプロマイズされた取引マネーモジュールを使用して「セルフディーリング」を行うことによりマネーを生成しようとする者の試みを妨害するためのものであり、これに十分に適している。重複がないか、又はノートボデーの一致が識別されない場合には、ノートＹは該ノートをマネー保持者内に置く（ステップ１６０６）。最後に、ノートディレクトリーＹが、ノートの位置及び額を更新し、順序番号を初期化する（ステップ１６０８）。ノート移転プロセスは、ノートの調整のために順序番号を更新及び初期化し、ノートの移転が不良識別子リストにないかどうかをチェックし、ノートの重複をチェックすることを含む。これらの追加の特徴及びステップは、重複したノートを導入し流通させる不正行為を困難にするもので、流通過程において重複ノートを発見する能力が高められる。図１２に戻り該図を参照すると、MMコミットサブルーチンがコールされる（ステップ６３２）。好ましい電子マネーシステムに使用されるコミットプロトコールは、米国特許出願第08／427,287 号に記載があり、図２１に示されている。セッションマネージャーＸが「コミット準備完了」メッセージをＹに送る（ステップ１７０２ないし１７０４）。これは、コミットする義務を該メッセージを受けるモジュールに移す。従来のマネー移転のシナリオでは、コミットする責任を最初に移すこの技術は、マネーを移転する当事者が最初にコミットし、マネーの重複の可能性を除去することを確実にするために使用されている。次いで、セッションマネージャーＹが受取をＸに送り（ステップ１７０６ないし１７０８）、その取引ログを更新することによって係属中の取引に対してコミットする（ステップ１７１０）。また、Ｙが取引マネーモジュールであれば、加入者向けＹは、加入者に対して取引が成功したことを通知する（ステップ１７１２ないし１７１４）。セッションマネージャーＹは、セッションの終わりを記録する（ステップ１７１６）。取引ログＸは、Ｙから受取を受け、その取引ログを更新し、係属中の取引に対してコミットする。Ｘは、Ｙと同様にしてコミットを完了する（ステップ１７１８ないし１７２４）。このフローチャートは、マネーモジュール６が信託エージェント１２０と相互作用している場合にも、メッセージ送り＝Ｅルートメッセージ送りとし、加入者向けメッセージが暗号化した状態で信託エージェント１２０に送られる、という理解のもとで、適用できる。前述のことに留意して、マネーモジュールＢのMMセッションマネージャーが「コミット準備完了」メッセージをＥルートメッセージ送りサブルーチンを介してマネーモジュールＡのMMセッションマネージャーに送る（ステップ１７２０ないし１７０４）。MMセッションマネージャーＡは、「受取」メッセージをマネーモジュールＢに送り、マネーモジュールＡはコミットする（ステップ１７０６ないし１７１６）。マネーモジュールＢが「受取」メッセージを受けると、該マネーモジュールもコミットする（ステップ１７１８ないし１７２２）。マネーモジュールＡ、Ｂのコミットルーチンにおいて、これらは、それぞれの信託エージェントＡ、Ｂに送られるメッセージを生成し（ステップ１７１４ないし１７２２）、これらモジュールが取引にコミットしたこと、したがって支払いが成功であったことを該エージェントに通報する。図１２を参照すると、ここで、マネーモジュールは、両方とも、上述の「支払い成功」メッセージをそれらの信託エージェントに送る（ステップ５８４ないし５８６）。これらメッセージはセッションキー（TA／MM）により暗号化される。セッションマネージャーＡは、支払いが成功裏になされたことを検出し、チケット保持者Ａは、受け取ったチケットを取引の日付のような支払い情報で更新する（ステップ５８８、５９２、６３４）。次いで、信託エージェントＡがコミットし（ステップ６３６）、そのチケットの保持が最早「暫定的」でなくなる。同様に、セッションマネージャーＢは成功裏の支払いを検出し（ステップ５９０、５９４）、信託エージェントＢがコミットする（ステップ６３８）。ここで取引が完了する。図７に戻ると、前述の説明は、顧客がその銀行口座における負債の交換として電子マネーを商人に売却することを望む場合であった。顧客が商人から電子マネーを受け取る場合には、購入Ｂがマネーモジュールに十分な資金があるかどうかを尋ねる（ステップ７２４ないし７２６）。MTD 内のマネーモジュールが十分な資金を持たない場合には、ホスト向けＢがホストのガイダンスを要求し、該ホストは、商人の他の取引装置が要求される額を持っているかどうかをチェックする（ステップ７２８ないし７３２）。もし、持っていれば、ホストＢは、他の取引装置（ホストＣを有する）に対して、マネーを送るようにメッセージを送る（ステップ７３４）。ＣとＢの間にセッションが確立され、マネーモジュール支払いがなされる（ステップ７３６ないし７３８）。このシナリオでは、マネーモジュール支払いのステップ６３４に示されるようなチケットはない。この場合には、このステップは単に省略することができる。他のMTD が十分な資金を持たない場合には、ホストＢは、口座を有する銀行から引き出しが可能かどうかをチェックする（ステップ７４０ないし７４２）。もしできるようであれば、マネーモジュールＡは、米国特許出願第07／794,112 号に記載したマネージェネレーターモジュール２０２、出納モジュール２０４、及び銀行システム２０６を使用して、銀行から電子マネーを引き出す（ステップ７４８）。電子マネーを引き出すことができない場合には、ホストＢが中止を要求し、取引は中止される（ステップ７４４ないし７４６）。商人が顧客に渡すのに十分な資金を持っている場合には、取引はステップ７５０ないし７９４に記載したように進行する。ホスト向けＢは、ここで額と信用証明についてのメッセージをカード承認機関ネットワーク２０８に送り、信用証明書に表示された銀行口座に対して負債処理をする（ステップ８１０）。カード承認プロセスが進行し（ステップ８１１）、購入Ｂが負債は承認されたかどうかをチェックする（ステップ８１３ないし８１５）。承認されないときは、取引は中止され、その他の場合には、信託エージェントＢは信託エージェントＡに対してマネーモジュール支払いを行い、取引を完了する（ステップ８１７）。この説明では、本発明の好ましい実施例を図示し説明したが、本発明は、他の種々の組み合わせ及び環境のもとで使用でき、ここに表現された発明思想の範囲から外れることなく、変更や修正が可能である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号ＦＩＧ０６Ｆ 15/30 Ｌ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．電子マネーのオープン流通のためのシステムであって、顧客信託エージェントと、前記顧客信託エージェントに関連付けられて該顧客信託エージェントと安全に通信する第１のマネーモジュールと、前記顧客信託エージェントとの間で第１の暗号的に安全なセッションを確立する商人信託エージェントと、前記商人信託エージェントに関連付けられて該商人信託エージェントと安全に通信し、前記第１のマネーモジュールとの間で第２の暗号的に安全なセッションを確立する第２のマネーモジュールと、を備え、前記顧客信託エージェントは、電子マネー購入情報と口座信用証明を前記商人信託エージェントに提供し、前記商人信託エージェントは受取チケットを前記顧客信託エージェントに提供するようになっており、前記商人信託エージェントは商人ネットワークにアクセスし、前記電子マネー購入情報及び前記口座信用証明からの情報を使用して承認プロセスを開始するようになっており、承認を取得したとき、前記商人信託エージェントは前記第２のマネーモジュールから前記第１のマネーモジュールへの電子マネーの移転を開始するようになった、ことを特徴とするシステム。２．請求の範囲第１項に記載したシステムであって、前記口座信用証明は、クレジット又は借方カードチケットであることを特徴とするシステム。３．請求の範囲第１項に記載したシステムであって、前記顧客信託エージェントは又、前記商人信託エージェントに電子マネー売却情報を提供し、該商人信託エージェントは、前記電子マネー売却情報及び前記口座信用証明からの情報を承認プロセスに使用して、承認を受けたとき、前記商人信託エージェントは、前記第１のマネーモジュールが電子マネーを前記第２のマネーモジュールに移転するプロトコールを開始させるようになったことを特徴とするシステム。４．請求の範囲第１項に記載したシステムであって、前記商人信託エージェントは共有する他のマネーモジュールから前記第２のマネーモジュールに電子マネーの移転を開始するようになっており、該他のマネーモジュールからの電子マネーは前記第１のマネーモジュールに流通させられるようになったことを特徴とするシステム。５．請求の範囲第１項に記載したシステムであって、前記第２のマネーモジュールは電子マネーを提供する銀行の銀行ネットワークにアクセスし、前記銀行から電子マネーを引き出して前記第１のマネーモジュールに流通させるようになったことを特徴とするシステム。６．請求の範囲第１項に記載したシステムであって、前記受取チケットは顧客の銀行ＩＤと口座番号と承認額とを含むことを特徴とするシステム。７．電子マネーのオープン流通のためのシステムであって、顧客信託エージェントと、前記顧客信託エージェントに関連付けられて該顧客信託エージェントと安全に通信する第１のマネーモジュールと、前記顧客信託エージェントとの間で第１の暗号的に安全なセッションを確立する商人信託エージェントと、前記商人信託エージェントに関連付けられて該商人信託エージェントと安全に通信し、前記第１のマネーモジュールとの間で第２の暗号的に安全なセッションを確立する第２のマネーモジュールと、を備え、前記顧客信託エージェントは、電子マネー売却情報と口座信用証明を前記商人信託エージェントに提供し、前記商人信託エージェントは受取チケットを前記顧客信託エージェントに提供するようになっており、前記商人信託エージェントは商人ネットワークにアクセスし、前記電子マネー売却情報及び前記口座信用証明からの情報を使用して承認プロセスを開始するようになっており、承認を取得したとき、前記顧客信託エージェントは前記第１のマネーモジュールから前記第２のマネーモジュールへの電子マネーの移転を開始するようになった、ことを特徴とするシステム。８．請求の範囲第７項に記載したシステムであって、前記口座信用証明は、クレジット又は借方カードチケットであることを特徴とするシステム。９．請求の範囲第７項に記載したシステムであって、前記受取チケットは顧客の銀行ＩＤと口座番号と承認額とを含むことを特徴とするシステム。 10．顧客信託エージェントと、第１のマネーモジュールと、商人信託エージェントと、第２のマネーモジュールとを使用して電子マネーをオープン流通させるための方法であって、 (a) 前記顧客信託エージェントと前記商人信託エージェントとの間に第１の暗号的に安全なセッションを確立し、 (b) 前記顧客信託エージェントが購入情報と口座信用証明を前記暗号的に安全なセッションを通じて前記商人信託エージェントに移転し、 (c) 前記商人信託エージェントが少なくとも部分的に前記購入情報と前記顧客の銀行口座番号を含む受取チケットを生成し、 (d) 前記商人信託エージェントが前記第１の暗号的に安全なセッションを通じて前記受取チケットを前記顧客信託エージェントに移転し、該顧客信託エージェントは暫定的に前記チケットを保持し、 (e) 前記商人信託エージェントは承認ネットワークにアクセスし、前記購入情報及び前記口座信用証明からの情報を使用して承認プロセスを開始し、 (f) 前記第１のマネーモジュールと前記第２のマネーモジュールの間で第２の暗号的に安全なセッションを確立し、 (g) 前記第２のマネーモジュールが前記第２の暗号的に安全なセッションを通じて前記第１のマネーモジュールに電子マネーを移転し、該第１のマネーモジュールは暫定的に前記電子マネーを保持し、 (h) 前記第１のマネーモジュールがコミットし、そこで前記電子マネーの保持が最早暫定的でなくなり、前記顧客信託エージェントに電子マネーを成功裏に受け取ったことを安全に通報し、 (i) 前記第２のマネーモジュールがコミットし、前記商人信託エージェントに電子マネーの成功裏の移転を安全に通報し、 (j) 前記顧客信託エージェントがコミットし、そこで前記受取チケットの保持が最早暫定的でなくなり、 (k) 前記商人信託エージェントがコミットする、段階からなる方法。 11．請求の範囲第１０項に記載した方法であって、前記口座信用証明は、前記顧客の口座番号を有するクレジット又は借方カードチケットであることを特徴とする方法。 12．請求の範囲第１０項に記載した方法であって、前記顧客信託エージェントが前記受取チケットを確認する段階を含む方法。 13．顧客信託エージェントと、第１のマネーモジュールと、商人信託エージェントと、第２のマネーモジュールとを使用して電子マネーをオープン流通させるための方法であって、 (a) 前記顧客信託エージェントと前記商人信託エージェントとの間に第１の暗号的に安全なセッションを確立し、 (b) 前記顧客信託エージェントが電子マネー売却情報と口座信用証明を前記暗号的に安全なセッションを通じて前記商人信託エージェントに移転し、 (c) 前記商人信託エージェントが少なくとも部分的に前記電子マネー売却情報と前記顧客の銀行口座番号を含む受取チケットを生成し、 (d) 前記商人信託エージェントが前記第１の暗号的に安全なセッションを通じて前記受取チケットを前記顧客信託エージェントに移転し、該顧客信託エージェントは暫定的に前記チケットを保持し、 (e) 前記商人信託エージェントは承認ネットワークにアクセスし、前記電子マネー売却情報及び前記口座信用証明からの情報を使用して承認プロセスを開始し、 (f) 前記第１のマネーモジュールと前記第２のマネーモジュールの間で第２の暗号的に安全なセッションを確立し、 (g) 前記第１のマネーモジュールが前記第２の暗号的に安全なセッションを通じて前記第２のマネーモジュールに電子マネーを移転し、該第２のマネーモジュールは暫定的に前記電子マネーを保持し、 (h) 前記第１のマネーモジュールがコミットし、前記顧客信託エージェントに電子マネーを成功裏に移転したことを安全に通報し、 (i) 前記第２のマネーモジュールがコミットし、そこで前記電子マネーの保持が最早暫定的でなくなり、前記商人信託エージェントに電子マネーの成功裏の受取りを安全に通報し、 (j) 前記顧客信託エージェントがコミットし、そこで前記受取チケットの保持が最早暫定的でなくなり、 (k) 前記商人信託エージェントがコミットする、段階からなる方法。 14．請求の範囲第１３項に記載した方法であって、前記口座信用証明は、前記顧客の口座番号を有するクレジット又は借方カードチケットであることを特徴とする方法。 15．請求の範囲第１３項に記載した方法であって、前記顧客信託エージェントが前記受取チケットを確認する段階を含む方法。 16．電子マネーの安全な流通のためのシステムであって、第１のプロセッサを含む耐不正使用性の第１の電子的取引装置と、第２のプロセッサを含み暗号的に安全なセッションを通じて前記第１の電子的取引装置と通信する耐不正使用性の第２の電子的取引装置と、を備え、前記第１のプロセッサが購入額情報と顧客口座信用証明を前記第２の電子取引装置に送るようになっており、前記第２のプロセッサが前記購入額情報と前記顧客口座信用証明からの情報を受取チケット内に組み入れ、該受取チケットを前記暗号的に安全なセッションを通じて前記第１の電子的取引装置に送るようになっており、前記第２のプロセッサが前記購入額情報と前記顧客口座信用証明からの情報に基づき承認プロセスを開始するようになっており、承認が得られたとき、前記第２の電子的取引装置が電子マネーを前記第１の電子的取引装置に移転して、電子マネーを顧客の銀行が電子マネーを流通させるかどうかとは無関係に電子マネーの流通を提供するようになった、ことを特徴とするシステム。 17．請求の範囲第１６項に記載したシステムであって、前記第２の電子的取引装置は商人ネットワーク及び顧客の銀行ネットワークに接続された承認ネットワークに接続されており、前記承認ネットワークで前記承認プロセスが開始されるようになったことを特徴とするシステム。 18．請求の範囲第１７項に記載したシステムであって、前記第２の電子的取引装置は電子マネーを流通させる銀行の商人銀行ネットワークに接続されたことを特徴とするシステム。 19．請求の範囲第１６項に記載したシステムであって、前記顧客の口座信用証明は、前記顧客の口座番号を有するクレジット又は借方カードチケットであることを特徴とするシステム。 20．電子マネーの安全な流通のためのシステムであって、第１のプロセッサを含む耐不正使用性の第１の電子的取引装置と、第２のプロセッサを含み暗号的に安全なセッションを通じて前記第１の電子的取引装置と通信する耐不正使用性の第２の電子的取引装置と、を備え、前記第１のプロセッサが電子マネー売却情報と顧客口座信用証明を前記第２の電子取引装置に送るようになっており、前記第２のプロセッサが前記電子マネー売却情報と前記顧客口座信用証明からの情報を受取チケット内に組み入れ、該受取チケットを前記暗号的に安全なセッションを通じて前記第１の電子的取引装置に送るようになっており、前記第２のプロセッサが前記電子マネー売却情報と前記顧客口座信用証明からの情報に基づき承認プロセスを開始するようになっており、承認が得られたとき、前記第１の電子的取引装置が電子マネーを前記第２の電子的取引装置に移転して、電子マネーを顧客の銀行が電子マネーを流通させるようになった、ことを特徴とするシステム。 21．請求の範囲第２０項に記載したシステムであって、前記第２の電子的取引装置は商人ネットワーク及び顧客の銀行ネットワークに接続された承認ネットワークに接続されており、前記承認プロセスは前記承認ネットワークで実行されるようになったことを特徴とするシステム。 22．請求の範囲第２１項に記載したシステムであって、前記第２の電子的取引装置は電子マネーを流通させる銀行の商人銀行ネットワークに接続されたことを特徴とするシステム。 23．請求の範囲第２０項に記載したシステムであって、前記顧客の口座信用証明は、前記顧客の口座番号を有するクレジット又は借方カードチケットであることを特徴とするシステム。