JP2002508552A

JP2002508552A - オープンネットワークを通じて機密保持がなされた呈示及び支払いをするシステム及び方法

Info

Publication number: JP2002508552A
Application number: JP2000538324A
Authority: JP
Inventors: ショロム・エス・ローゼン
Original assignee: Citibank NA
Current assignee: Citibank NA
Priority date: 1998-03-20
Filing date: 1999-02-12
Publication date: 2002-03-19
Also published as: US6081790A; WO1999049427A1; AU3292199A; EP1068597A1

Abstract

(57)【要約】第１の電子処理装置及び第２の電子処理装置を有する機密保持された呈示及び支払いシステム。第１の処理装置は呈示チケットを格納された送り状データから作成して呈示チケット及び送り状データを第２の処理装置に機密保持よく送信する。第２の処理装置は、どの送り状が支払われるべきかを決定し、それが第１の処理装置に機密保持よく送信する対応する送金通知を作成する。第１の処理装置は、送金通知に対応する商業的支払いチケットを作成し、それを第２の処理装置に送信する。第２の処理装置は、その後、送信通知において特定されたものに対応する額の電子マネーを第１の処理装置に機密保持よく送信する。

Description

【発明の詳細な説明】

【０００１】発明の属する技術分野本発明は、オープンネットワークを通じて要求払いで人対人の送り状及び期限
を過ぎた通知の呈示をするためのシステムに関する。本システムは、機密保持の
なされた商人による呈示と顧客による支払いの取引を作成するためのマネーモジ
ュールに結合される「信託エージェント」と呼ばれる改ざん防止電子ユニットを
利用する。

【０００２】発明の背景電子商取引の成長に対応するために数多くの電子支払いシステムが現在開発中
である。私の米国特許第５，４５３，６０１号、米国特許第５，５５７，５１８
号及び１９９５年４月２１日に出願されて係属中の米国特許出願番号第０８／４
２７，２８７号には一の電子支払い方法が記載されており、それらの記載はここ
で参照して結合される。これらの特許及び係属中の出願は、現金、小切手、クレ
ジットカード、デビットカード及び電子資金移動の代替的な交換媒体としての電
子マネーの支払いを実行する電子マネーシステムを開示している。特に、記載さ
れたシステムは、電子手形を格納して移転する改ざん防止筐体に収納されたマネ
ーモジュールを使用している。マネーモジュールによる支払いは、マネーモジュ
ール間（例えば、顧客の「電子財布」に含まれるマネーモジュールと商人のＰＯ
Ｓ端末に含まれるマネーモジュールとの間）で実時間でオフラインの支払いであ
ってもよいし、情報検索及び通話等、若しくは、航空券や劇場チケットを購入す
るためのネットワークサービスのオンライン払いであってもよい。

【０００３】ここで説明される信託エージェントは米国特許第５，５５７，５１８号に詳細
に説明されている。当該特許は、実時間の匿名払い又は許可ベース払いにより、
電子商品の機密保持がなされた配送を可能にするシステムを説明している。シス
テムは、顧客と商人の両方が、彼等の利益が満足されていると安全に感じること
を可能にしている。

【０００４】米国特許第５，６７１，２８０号は、顧客信託エージェントが商人信託エージ
ェントに送金情報を供給し、その後、商人信託エージェントは商業的支払いチケ
ットを顧客信託エージェントに与えるシステムを説明している。商業的支払いチ
ケットを受け取ると顧客から商人への電子マネーの移転が開始する。従って、か
かるシステムは、送り状の受領後に顧客の便宜でなされる支払いを述べている。
支払いは支払いの証拠と共に電子的になされ、実時間で売掛金及び未払金を処理
することができる。

【０００５】本発明は、インターネットなどのオープンネットワークを通じて、商人が送り
状又は期限を過ぎた通知を顧客に機密保持よく呈示することができるシステムを
説明している。更に、本発明は、呈示に際して顧客が実時間で支払いをすること
を可能にしている。従来の出納事務による支払いシステムは、本発明によって大
幅に単純化されることができ、コスト削減とミスの低減をもたらす。迅速な支払
いにより、商人が資金の費用、及び、未払い清算を追跡する措置を低減すること
ができるだろう。代わりに、商人は、迅速な支払いを奨励するために顧客に割引
をもっと喜んで与えることができるだろう。期限の過ぎた送り状に対しては、本
発明により、商人は、今日必要な骨の折れる追跡及び電話催促を必要とせずに、
期限の過ぎた売掛金を処理することができ、これによって回収費用を削減するこ
とができる。

【０００６】発明の要約本発明の目的は、商人から顧客への送り状及び期限の過ぎた通知の呈示を仲介
者なしに可能にする信託エージェントを使用して機密保持のなされたシステムを
提供することである。

【０００７】本発明の更なる目的は、支払い用に呈示された品目のうちから選択されたもの
に対する実時間払いに、送り状及び期限の過ぎた通知の呈示を機密保持よく統合
する支払いシステムを提供することである。

【０００８】本発明の更なる目的は、商人も顧客も効果的に反駁することができないように
信託エージェントによって呈示及び支払い情報の両方が電子的に署名されるシス
テムを提供することである。

【０００９】本発明の一側面によれば、少なくとも一のデータプロセッサ、メモリ及び暗号
手段を有する第１の電子処理装置と、少なくとも一のデータプロセッサ、メモリ
及び暗号手段を有する第２の電子処理装置が設けられる。第１の処理装置は、格
納された送り状データから呈示チケットを作成する。呈示チケット及び送り状デ
ータは第２の処理装置に機密保持よく送信される。第２の処理装置は、どの送り
状が支払われるべきかを決定し、それが第１の処理装置に機密保持よく送信する
、対応する送金通知を作成する。第１の処理装置は、送金通知に対応する商業的
支払いチケットを作成し、それを第２の処理装置に機密保持よく送信する。第２
の処理装置は、その後、送金通知において特定されたものに対応する額の電子マ
ネーを第１の処理装置に機密保持よく送信する。

【００１０】本発明は、添付図面を参照して以下に詳細に説明される。

【００１１】好ましい実施例の説明米国特許第５，５５７，５１８号に記載されているように、信託エージェント
はハードウェア及びソフトウェアコンポーネントの結合である。それは、改ざん
防止処理が施され、機密保持がなされた発送払いに同期するマネーモジュールと
協同する機密保持がなされたプロトコルを含んでいる。マネーモジュールは電子
マネーを格納及び移転することができる改ざん防止装置である。電子マネーは、
好ましくは、通貨又はクレジットの代替物である電子手形の形態である。マネー
モジュールは、他の装置と暗号によって機密保持がなされた通信セッションを設
定することもできる。本発明の好ましい実施例は、私の米国特許第５，４５３，
６０１号及び私の同時係属米国特許出願第０８／４２７，２８７号に記載された
取引マネーモジュールを使用する。

【００１２】本発明では、機密保持がなされた呈示と支払いのために、図１に示すように、
商人の信託エージェント（ＭＴＡ）４が呈示チケット及び送り状及び／又は期限
の過ぎた通知を顧客の信託エージェント（ＣＴＡ）２に送信する。ＣＴＡ２は、
その後、送金情報をＭＴＡ４に送信し、ＭＴＡ４は商業的支払いチケットをＣＴ
Ａ２に送信する。最終的に、マネーモジュールによる支払いが起こり、顧客のマ
ネーモジュール６が電子マネーを商人のマネーモジュール６に、ＣＴＡ２及びＭ
ＴＡ４を介して、送信する。

【００１３】本発明においては、送り状及び期限を過ぎた通知の呈示は、第三者によって起
動されて標準フォーマットを要求する現在の電子データ交換（ＥＤＩ）システム
と異なり、フォーマットが弾力性であるように人対人である。多くの商業契約は
様々なフォーマットを要求する。図２Ａに示すように、送り状又は期限の過ぎた
通知で与えられる情報の種類は、送り状ｉｄ６０、顧客情報６２、商人情報６４
、購入注文番号６６、取引日６８（例えば、注文日及び出荷日）、種類７０（例
えば、送り状、最初の通知、期限を過ぎた通知）、支払条件７２（例えば、早期
又は迅速な支払いに対する割引）、出荷された品目７４、バックオーダー品目７
６、及び、送り状金額７８を含むことができる。更なる例では、期限を過ぎた通
知は多数の期限を過ぎた送り状を要約金額と共に含むことができる。明らかに、
送り状の一般の形式は、それが物理的商品ではなくサービスに関係していれば、
上記とは異なる。本発明においては、かかる送り状その他の情報は、商人及び顧
客が共有する特定のホストアプリケーションソフトウェアによって処理可能であ
る。ホストアプリケーションソフトウェアは、信託エージェントを介して彼の顧
客に商人が機密保持よく分配することができる。

【００１４】図２Ｂに示すように、送金通知は、取引を開始するのに必要な情報を含む。か
かる情報は、顧客及び商人情報４６、４７（例えば、顧客及び商人の名前及び住
所、顧客参照番号、商人のネットワークアドレス）、支払い日４８、支払い金額
４９、及び、支払われるべき送り状のリスト５０を含むことができる。送り状の
情報は、商人が売掛金システムのデータと照らし合わせて紛争で使用するのに十
分な情報を含む。

【００１５】チケット図３を参照するに、チケット８は、ＭＴＡ４によって作成されてＣＴＡ２に取
引中に移転される電子品目である。チケットは、信託エージェントの財産とみな
すことができる。ＣＴＡ２がチケットをちょうど受信した顧客は、取引が成功裡
に終了すると当該チケットを使用可能になるのみである。

【００１６】本発明は、呈示チケットと商業的支払いチケットという２種類のチケットを利
用する。支払いチケットは、顧客に呈示される送り状及び／又は期限の過ぎた通
知に対する呈示人のディジタル署名を含む。商業的支払いチケットは、商業的支
払いの事項を識別し、送金通知に対して受取人のディジタル署名を有する。両種
類のチケットは紛争が生じた場合に使用可能である。

【００１７】図３は、識別子１０、コンポーネント１２、発行者署名１４、発行者証明書１
６、移転履歴１８及び送信者署名２０という６つの主なセクションをチケットが
有するチケット８の好ましい実施例を示す。同様に、セクションはフィールドを
含む様々な情報を有する。

【００１８】識別子セクション１０は、チケットを作成する商人又は機関を識別する情報を
保持するフィールド２２を有する。商人又は機関の名前などのかかる情報はチケ
ット発行者が保持する商人又は機関の信用状からコピーされる。フィールド２２
は、商人又は機関の信用状の満了日も含んでいる。フィールド２４は、受信する
信託エージェントのＩＤ番号を含む。フィールド２４は、チケット受信者の信託
エージェントの信用状の満了日も含んでいる。フィールド２６は、チケットの種
類（例えば、クレジット又はデビットカードチケット、商業的支払いチケットな
ど）を指定する。

【００１９】コンポーネントセクション１２は、チケットの種類及びその特定の目的によっ
て異なる基本チケット内容を含む。図３は、呈示チケット及び商業的支払いチケ
ットで見られるコンポーネントの例を示している。

【００２０】呈示チケットは、顧客に呈示される送り状及び／又は期限の過ぎた通知の情報
に対するＭＴＡのディジタル署名である『送り状及び期限の過ぎた通知の署名』
フィールド３５を含むことができる。それは、顧客の信用状（例えば、顧客の名
前、住所、信用状の機関、信用状の満了日）から取得可能な顧客情報３７を含む
こともできる。

【００２１】代替的に、フィールド３５は、送り状データのグループ署名を含んでもよい。
グループ署名は、識別子ｉｄＭ₁、ｉｄＭ₂、…、ｉｄＭ_kを有する電子対象物
Ｍ₁、Ｍ₂、…Ｍ_kのグループを署名する方法によって作成可能である。かかるグループ署名があると、署名者は、一のプライベート鍵操作を実行し、検証者は一
の公開鍵操作を実行しなければならない。また、グループの受信者は、各小派が
他の対象物とは独立に検証可能になるように、グループを対象物の小派に分割す
ることができる。

【００２２】グループ署名は、以下のように作成可能である。１．ｈ（Ｍ₁）、ｈ（Ｍ₂）、…ｈ（Ｍ_k）を生成する。２．Ｔ＝ｉｄ（Ｍ₁）‖ｈ（Ｍ₁）‖ｉｄ（Ｍ₂）‖ｈ（Ｍ₂）‖ｉｄ（Ｍ_k） ‖ｈ（Ｍ_k）とする。３． σ（Ｍ₁、Ｍ₂、…Ｍ_k）＝Ｄ_k（ｈ（Ｔ））‖Ｔをグループ署名とする。

【００２３】１．ｈ（Ｔ）を計算する。２．Ｅ_k（Ｄ_k（ｈ（Ｔ）））＝Ｓを計算する。３．ｈ（Ｔ）＝Ｓを確認する。そうでなければ無効である。

【００２４】ここで、‖は連鎖状データストリングで、ｈは一方向ハッシュ関数（例えば、
セキュア・ハッシュ・アルゴリズム（ＳＨＡ）又はメッセージ・ダイジェスト−
５（ＭＤ−５））で、Ｅ_kは公開鍵による暗号化で、Ｄ_kはプライベート鍵による
復号化である。

【００２５】グループ署名は、署名及び検証処理をより効率的にするために、呈示チケット
において使用可能である。ｉｄＭは送り状番号であってもよい。それにより、商人は選択ベースで送り状が呈示されたことを示すことができる。特に、商人は
顧客に呈示チケットと未払い送り状を確認のために送信することができる。

【００２６】グループ署名は、一以上の手形の移転に対する署名及び検証時間を短縮するた
めに、米国特許第４，４５３，６０１号に記載された電子マネーシステムにも使
用可能である。かかるアプリケーションでは、グループ署名は、手形が受信マネ
ーモジュールによって別個に移転及び検証されると、個別的な手形の各々に選択
ベースで適用するだろう。

【００２７】グループ署名は、上述以外の方法を使用して計算することもできる。例えば、
許可ツリー方法を利用する代替的なグループ署名がアール・マークルへの米国特
許第４，３０９，５６９号に記載されているように使用可能である。

【００２８】商業的支払いチケットは、顧客情報フィールド３６、商人情報フィールド３８
、支払いデータフィールド４０、支払い金額フィールド４２、及び、送金通知情
報に対するＭＴＡのディジタル署名である送金通知署名フィールド４４を含むこ
とができる。

【００２９】チケット８の発行者署名セクション１４は、識別子及びコンポーネントセクシ
ョン１０、１２を通じてチケット作成者によって形成されたディジタル署名を保
持する。かかる署名は、発行者の信託エージェントに付属するプライベート鍵を
使用してなされる。発行者証明書セクション１６は、発行されたチケット８の信
憑性を検証するために発行者署名と関連付けられて使用される（以降では「信託
エージェンシー」と呼ばれる。）信託第三者による証明を含む。かかる証明は、
発行者の信託エージェントに付属する証明書の形態である。証明書とディジタル
署名の一般的な使用は既知であり、例えば、ディー・ダブリュー・デイビス及び
ダブリュー・エル・プライスの「セキュリティ・フォー・コンピュータ・ネット
ワークス」（ジョン・ウィレイ・アンド・サンズ、１９８４年）に記載されてい
る。

【００３０】移転履歴セクション１８は、商人又は機関によるチケット８の最初の発行後に
チケットが信託エージェント間で移転されると生成される情報を含む。受信者Ｉ
Ｄのフィールド２８は受信信託エージェントのＩＤ番号を含む。送信者ＩＤのフ
ィールド３０は、送信信託エージェントのＩＤ番号を含む。送信者証明書フィー
ルド３２は、送信信託エージェントの証明書を含む。日時フィールド３４は、チ
ケット８の移転日時を含む。その後の移転がなされると、追加的な受信者及び送
信者ＩＤ、送信者証明書及び日時が各フィールドに添付され、これにより、移転
履歴情報のリストが形成される。識別子セクションの受信者フィールドで見られ
る信託エージェントＩＤは、送信者ＩＤのフィールドの最初のＩＤと同一でなけ
ればならないことに留意する必要がある。

【００３１】また、チケット８が信託エージェント間で移転されるたびに、送信者は、送信
者の信託エージェントに付属するプライベート鍵を使用して、５つの先行チケッ
トセクションに亘ってチケットにディジタル署名をする。送信者署名セクション
２０は、新しく作成されたディジタル書名を添付することによってその後更新さ
れ、これにより、送信者の署名リストを作成する。

【００３２】取引装置図４を参照するに、信託エージェント１２０は取引装置１２２に埋め込まれて
いる。取引装置１２２は、商人及び顧客の両方に対して３つの主なコンポーネン
トから構成されている。即ち、ホストプロセッサ１２４、信託エージェント１２
０及びマネーモジュール６である。これらのコンポーネントは、例えば、バス１
２６によって接続される。信託エージェント及びマネーモジュールはハードウェ
ア及びソフトウェアコンポーネントを有する。信託エージェント及びマネーモジ
ュールは別個に組み立て可能であるか、組み立て費用を削減するために一体化さ
れてもよい。かかる結合された信託エージェント及びマネーモジュールはハード
ウェアコンポーネント（例えば、マイクロプロセッサ、メモリ及びクロック）及
びソフトウェアコンポーネント（例えば、暗号機能）を共有することができる。
信託エージェント１２０がＭＴＡ２であれば、装置１２２は商人取引装置（ＭＴ
Ｄ）と呼ばれる。信託エージェント１２０がＣＴＡ４であれば、装置１２２は顧
客取引装置（ＣＴＤ）と呼ばれる。

【００３３】図４は、ホストプロセッサ１２４の機能的なコンポーネントを示している。ホ
ストプロセッサは、通信１２８、取引アプリケーション１３０、マン・マシンイ
ンターフェース１３２、日時１３６及びメッセージマネージャー１３４の機能を
与える。

【００３４】通信機能１２８は、取引装置１２２と外界との間の通信をサポートする。かか
る通信は、通信が装置間で互換性がある限り、有線又は無線、広帯域又は狭帯域
であってもよい。通信機能１２８は、２つの取引装置１２２間の接続を設定する
か、取引装置を別の取引装置又は信託サーバーへの間接接続用ネットワークに接
続する。

【００３５】取引アプリケーション１３０は、様々なタスクを実行することができる。例え
ば、取引アプリケーションは、以前の取引から受け取った送り状を支払うことが
できる。一般に、取引装置１２２は、電子対象物、電子マネー、信用状、その他
のチケット８を選択、購入及び使用可能な全ての処理又はそれらを販売する処理
を含む。

【００３６】マン・マシンインターフェース機能１３２は取引装置１２２の視覚及び感覚を
与える。それは、キーボード、マウスペン、音声、タッチスクリーン、アイコン
、メニュー等を含むことができる。マン・マシンインターフェース１３２は、信
託エージェント１２０及びマネーモジュール６の他の機能とメッセージマネージ
ャー１３４を介して交信する。あるアプリケーションでは、マン・マシンインタ
ーフェース１３２は、例えば、完全に自動化された商人又は顧客の取引装置にお
いては、必要ではない。

【００３７】日時機能１３６は、取引装置１２２の所有者によって設定され、日付、時間及
び時間帯を含む。日時情報は、信託エージェントが使用にオープンであればいつ
でも埋め込まれた信託エージェント１２０に送信される。

【００３８】メッセージマネージャー１３４は、取引装置間で内部ホストメッセージ（即ち
、取引装置間のメッセージは、別のホストに発送する通信機能に送信される）及
びメッセージをホストプロセッサ１２４、信託エージェント１２０及びマネーモ
ジュール６の間で発送する。

【００３９】信託エージェント図５Ａは、信託エージェント１２０の機能的なコンポーネントを示している。
オープンな電子商取引を意図されたシステムは、それらが提供するある独自の取
引者機能１４６において異なる３種類の信託エージェント１２０を使用する。図
５Bは、ＣＴＡ２で見られる取引者機能を示す。図５Ｃは、ＭＴＡ４で見られる取引者機能を示す。図５Ｄは、どうように、機関の取引装置（ＡＴＤ）に埋め込
まれた機関の信託エージェント（ＡＴＡ）で見られる取引者機能を示す。ＡＴＤ
は銀行などの信用状発行機関に関連付けられている。

【００４０】外部インターフェース機能１３８は、信託エージェント１２０が埋め込まれて
いる取引装置１２２のホストプロセッサ１２４及びマネーモジュール６に物理的
通信を与える。メッセージインターフェース機能１４０は、内部エージェント及
びエージェント間のメッセージを処理及び発送する。セッションマネージャー機
能１４２は、内部エージェントセッション及び信託サーバーセッションへのエー
ジェントを設定及び切断する。機密保持マネージャー機能１４４は、（例えば、
信託エージェント証明書及び非信託エージェントリストなどの）機密保持情報を
維持して、（ホストプロセッサ１２４を介して）相手信託エージェント及び同一
の取引装置１２２内のローカルマネーモジュール６との機密保持がなされた通信
を設定する。取引者機能１４６は、取引を実行するプロトコルを与える。顧客、
商人及び機関の取引者は、ＣＴＡ、ＭＴＡ及びＡＴＡにそれぞれ使用される。

【００４１】図５Ｂは、顧客の取引者機能を示している。『購入』機能１５８は、チケット
８の支払いと電子対象物とを交換する。『至ホスト』機能１６０は取引装置のホ
ストプロセッサ１２４へのインターフェースを与える。チケット呈示機能１６４
は、情報又はサービスを取得するためにチケット８を呈示する。信用状取得機能
１６６は信用状チケットを受信するために対話する。取引ログ機能１６２は、信
託エージェント取引のログを維持する。ＣＴＡ２及びＭＴＡ４の両方は、取引の
種類（例えば、チケットの種類）、取引前チケット画像、取引後チケット画像、
（紛争ダイアログで各信託エージェントが維持するように）紛争日、状態、及び
、商人による解決方法（例えば、交換、返金、拒否）を含む紛争情報、及び、再
証明情報（例えば、再証明の日付）の情報を格納する取引ログを維持する。紛争
開始機能１６８は、顧客が不満を抱けば、電子商品を呈示する。

【００４２】図５Ｃは、商人の取引者機能を示している。『購入』機能１７０は、チケット
８と支払い用電子対象物を交換する。『至ホスト』機能１７２は、取引装置のホ
ストプロセッサ１２４へのインターフェースを与える。チケット受信機能１７６
は、サービス又は情報を提供するために、受信されたチケット８を処理する。信
用状取得機能１７７は、商人の信用状を取得する。取引ログ機能１７４は、信託
エージェント取引のログを維持する。紛争解決機能１７８は、顧客の苦情を解決
するために、チケット８及び電子対象物を受信する。

【００４３】図５Ｄは、機関の取引者機能を示している。信用状作成機能１８０は、信用状
チケットを構成して要求者に配送する。『至ホスト』機能１８２は、取引装置の
ホストプロセッサ１２４にインターフェースを与える。チケット受信機能１８４
は、サービス又は情報を提供するために、受信されたチケット８を処理する。信
用状再有効化機能１８６は、現在の信用状を受領して新しい満了日を有する信用
状を再発行する。取引ログ機能１８３は、取引のログを維持する。信用状取得機
能１８５は、機関の信用状を取得する。

【００４４】図５Ａを再び参照するに、『至マネーモジュール』機能１５０は、支払いを与
えるために、同一の取引装置１２２のマネーモジュール６と交信する。暗号機能
１５２は、公開鍵及び対称鍵暗号機能を与える。いかなる公開鍵暗号技術（例え
ば、ＲＳＡ、ＥｌＧａｍａｌ（例えば、楕円曲線）及び対称鍵暗号技術（例えば
、トリプルＤＥＳ、ＲＣ−５、ＩＤＥＡ）も使用可能である。チケット保持者機
能１４８は、チケット８をＭＴＡ４に作成するか、チケット８をＣＴＡ２内に格
納して検索する。乱数発生器機能１５６は、暗号鍵を作成するために乱数を生成
する。日時機能１５４は、チケット８に日付を付して証明書及び呈示チケットを
有効にするために、ホストプロセッサ１２４から発送される日時を管理する。現
在のクロック情報は、信託エージェントがオープンされるたびに（即ち、使用の
ためにサインオンされるたびに）、信託エージェント1２０に送信され、信託エージェントがクローズされるまで維持される。

【００４５】信託エージェント／マネーモジュールハードウェアは、取引プロトコルを実行
するマイクロコントローラ（例えば、アドバンスト・リスク・マシン（ＡＲＭ）
ファミリー）と、実行中にオペレーティングシステム、アプリケーション、暗号
等の一部を格納する高速揮発性メモリ（例えば、ＳＲＡＭ）と、オペレーティン
グシステム、アプリケーション、チケット、電子マネー、ログ等を格納する不揮
発性メモリ（例えば、フラッシュメモリ）と、参照時間を与えるＩＣクロックと
、クロック用バッテリと、乱数発生器用のノイズダイオードその他のランダム源
とを有することができる。

【００４６】ネットワークの概要図６は、要求払いによる人対人の呈示に対して意図されたシステムの一般的な
ネットワーク構築を示す。商人取引装置１９８は、商人の売掛金システム１９３
と商人ネットワーク１９２を介して交信する。売掛金システム１９３は、送り状
データを、送り状及び／又は期限を過ぎた通知情報を商人信託エージェント２に
呈示用に提供するＭＴＤ１９８のホストプロセッサに送信する。ＭＴＤ１９８は
、ＣＴＤ１８８とゲートウェイネットワーク１９０（例えば、インターネット）
及び顧客ネットワーク１９１を介して接続可能である。顧客ネットワーク１９１はＣＴＤ１８８及び未払金システム１８９に通信を提供
する。

【００４７】呈示後に一旦支払いの決定がなされると、ＣＴＤ１８８はそのマネーモジュー
ル６が十分な支払い資金を有していることを確認するか、電子マネーを別の取引
装置から取得するか、若しくは、例えば、私の米国特許第５，４５３，６０１号
及び私の同時係属米国特許出願０８／４２７，２８７号に記載されているように
、銀行から電子マネーを引き出す。かかる銀行からの引き出しにおいては、ＣＴ
Ｄ１８８は、顧客ネットワーク１９１、ゲートウェイネットワーク１９０及び銀
行ネットワーク２００を介して、テラーモジュール２０４に接続する。テラーモ
ジュール２０４は、電子マネーをマネー発生器モジュール２０２から要求し、バ
ンキングシステム２０６は引き出し取引に対する適当な勘定を維持する。

【００４８】フローチャート以下の図で示されるフローチャートは、２つの対話する信託エージェント１２
０を示すのに目的地Ａ及びＢを使用する。同一の目的地Ａ及びＢは、特定の信託
エージェント１２０に関連付けられた（即ち、同一の取引装置１２２内で）ホス
トプロセッサ１２４又はマネーモジュール６にも適用可能である。フローチャー
トは、所与のタスクを実行する責任を主として有する機能的なコンポーネントを
示す。例えば、機密保持マネージャーＡは列挙されたタスクが信託エージェント
Ａの機密保持マネージャー機能１４４（図５Ａ参照）によって実行されることを
意味する。

【００４９】また、フローチャートは、その幾つかがパラメータ指定Ｘ及びＹを使用するサ
ブルーチンを呼び出す。例えば、Ａ→Ｂセッション設定はセッション設定サブル
ーチンを呼び出す。セッション設定フローチャートは、その後、フロー中でＸ＝
Ａ及びＹ＝Ｂであることが理解されなければならない。

【００５０】中止とコミット所期の種類の取引処理においては、ゼロサムゲームを維持しながら、チケット
８及び電子手形などの電子品目を二者間で移すことが望ましい。換言すれば、電
子取引終了時に取引前の倍の品目が存在するように電子品目を複製することは望
ましくない。同様に、取引後に前よりも品目が少なくなるように電子品目を失う
ことは望ましくない。例えば、取引開始時にＡが電子チケット８を有してそれを
Ｂに渡したいと思う場合、取引終了時にＢが電子チケット８を有してＡが当該電
子チケットを有しないことが望ましい。しかし、現実の世界では、２人の別の成
果を有する、即ち、Ａ及びＢの両方が同一の電子チケット８を有する（複製）か
、ＡもＢも電子チケット８を有しない（損失）場合がある。

【００５１】複製又は損失の見込みを無視できる程度にするために、自然又は故意のイベン
トが典型的な取引フローを中断しうる可能性を取引プロトコルは考慮しなければ
ならない。自然の中断には、例えば、取引中のＡＢ間の通信リンクの遮断がある
。かかる無作為なイベントからの複製又は損失の可能性を最小限にするために、
複製又は損失を作成する機会は最小限にされなければならない。故意の中断（即
ち、明らかな攻撃）を最小にするために、かかる攻撃に対する経済的な動機を排
除することが好ましい。例えば、攻撃者は取引を中断しようとすることによって
チケット及び／又はマネーを失うのみであれば、攻撃者は最初の攻撃を開始する
動機を失うだろう。

【００５２】これらの概念は、前記システムの効率的な取引プロトコルで具体化される。特
に、２つの取引信託エージェント１２０（又はマネーモジュール６）間で一貫し
た中止及びコミット状態を確保することが望ましい。例えば、Ａが取引をコミッ
トすればＢも取引をコミットしなければならない。若しくは、Ａが取引を中止す
ればＢも取引を中止しなければならない。一貫性を確保して（一貫性がない場合
に）複製又は損失の可能性を最小限にするために、取引プロトコルは所与の取引
をコミットするＡ及びＢの注文とタイミングを考慮する。

【００５３】図７は、中止とコミットという２つのサブルーチンを示している。中止サブル
ーチンは、関連取引が失敗した場合に、所与の信託エージェント１２０の内部で
実行される。中止サブルーチンは、失敗した取引に関与する以前の状態に正確に
信託エージェント１２０をロールバック又は戻す。また、商人信託エージェント
が許可後に中止すると、その許可は覆される。逆に、コミット取引は、関連取引
が成功裡に終了すると所与の信託エージェント１２０の内部で実行される。従っ
て、信託エージェント１２０は、終了した取引をその取引ログに記録して今度は
新しい取引に備える。例えば、チケット移転取引中に電子チケット８は信託エー
ジェントＡから信託エージェントＢに移る。この時点でＡもＢも取引をコミット
も中止もしていないので、Ａはチケット８を暫定的に保持し、Ｂもチケット８を
暫定的に保持する。ＡとＢの両方がコミットするとＡはそのチケット８を消去し
、Ｂのチケット８の保持はもはや暫定的ではなくなる。しかし、ＡとＢの両者が
中止すると、Ａはそのチケットを保持してＢが暫定的に保持していたチケットは
取引をロールバックすることによって消去される。消去動作は当業界で周知の様
々な方法で実行可能であることに留意する必要がある。前述のように、別の信託
エージェント１２０が中止する間にある信託エージェント１２０がコミットする
可能性を最小化することが望ましい。なぜなら、これはある限定された環境では
電子品目の複製又は損失をもたらすからである。

【００５４】電子手形を交換するマネーモジュール６に関しても同様の状況が存在する。購
入取引中、電子手形はマネーモジュールＡからマネーモジュールＢに移り、その
結果、Ａが暫定的にその電子手形を（移転金額だけ）減分し、Ｂは暫定的に電子
手形を（移転金額だけ）有する。Ａ及びＢの両者がコミットすると、その後、Ａ
は減分された金額の手形を保持し、Ｂの電子手形の保持はもはや暫定的ではなく
なる。

【００５５】図７Ａはコミットサブルーチンを示す。取引ログＸは取引ログを更新する。『
至ホスト』Ｘはホストに取引終了を通知する。セッションマネージャーＸはセッ
ションの終了に留意する（ステップ２３０−２３４）。

【００５６】図７Ｂは中止サブルーチンを示す。セッションマネージャーＸは変更をロール
バックしエージェントの中止に留意する。セッションマネージャーは、セッショ
ン開始以来でロールバックがこれらのステップを元に戻すと既に行われたことを
追跡する。『至ホスト』Ｘはホストに取引中止のメッセージを送信する（ステッ
プ２３６−２３８）。

【００５７】中止サブルーチンは、例えば、信託エージェント１２０が証明書は有効ではな
いと決定する場合に、フローチャートから直接呼び出されることができる。中止
サブルーチンは、期待動作が起こらない場合に呼び出されてもよい。特に、２つ
の信託エージェント１２０が通信する場合に、彼らはタイムアウトプロトコルを
監視する。例えば、第１の信託エージェント１２０が第２の信託エージェント１
２０にメッセージを送信した後で、第１の信託エージェント（Ａ）のセッション
マネージャーは返信が必要であれば返信用タイマを設定する。セッションマネー
ジャーは送信されるメッセージに番号を付すこともできる。この番号は第２の信
託エージェント（Ｂ）のセッションマネージャーからの返信メッセージに現れる
。

【００５８】メッセージが受信される前にタイマが満了すると、セッションマネージャーＡ
はセッションマネージャーＢにＢが依然として取引中であるかどうかを決定する
ように尋ねる。Ｂが応答しなければ、セッションマネージャーＡは取引を中止す
る。取引処理中の返信を受信すると、タイマは新しい時間にリセットされる。Ａ
がＢに原メッセージへの返信を受信せずに所定回数を質問するとＡは取引を中止
する。同様なタイムアウト機能がマネーモジュール６に存在する。

【００５９】要求払いによる呈示図８は、統合された実時間マネーモジュールによる支払いにより、送り状及び
／又は期限の過ぎた通知の人対人の呈示のフローチャートを示す。最初に、売掛
金システム１９３又は他の自動送り状発送回収システムから送り状及び期限の過
ぎた通知の情報がＭＴＤ１９８のホストに送信される。売掛金システム１９３及
び未払金システム１８９の両方は好ましくは自動システムであるが、本発明の教
示は（例えば、送り状発送／送金データがＭＴＤ１９８及びＣＴＤ１８８のホス
トにキー入力される）手動システムにも同様に適用される。呈示を開始するため
に、ホスト取引アプリケーションＡ（ＨＴＡ）はホスト取引アプリケーション（
ＨＴＢ）Ｂに好ましくは商人ネットワーク１９２、ゲートウェイネットワーク１
９０及び顧客ネットワーク１９１を介して、接続する（ステップ７００）。ＨＴ
Ａは、その信託エージェントＡに、送り状及び／又は期限の過ぎた通知を呈示す
るために、メッセージを送信し、ＨＴＢは、メッセージをその信託エージェント
Ｂに、送り状及び／又は期限の過ぎた通知を受信するために、送信する（ステッ
プ７０２−７０４）。

【００６０】商人及び顧客の信託エージェント（Ａ及びＢ）はその後、私の米国特許第５，
５５７，５１８号に記載されたように、セッションを設定する。特に、暗号で機
密保持された通信チャネルを信託エージェントＡ及び信託エージェントＢ間で設
定するためのセッション設定サブルーチンが呼び出される（ステップ７０６）。

【００６１】図９を参照するに、信託エージェントＡのセッションマネージャーはＡの証明
書（即ち、証明書（ＴＡ））を要求して、その後、機密保持マネージャーから受
信する（ステップ２９６−２９８）。セッションマネージャーＡは、その後、証
明書（ＴＡ）を信託エージェントＢのセッションマネージャーに送信し、それは
、今度は、その機密保持マネージャーに移転する（ステップ３００−３０４）。

【００６２】信託エージェントＢの公開鍵機能は、米国特許第５，５５７，５１８号及び同
時係属米国出願第０８／４２７，２８７号に記載されたように、有効化プロトコ
ルを使用して、証明書（ＴＡ）を検証する（ステップ３０６−３０８）。

【００６３】証明書（ＴＡ）が有効ではなければ、セッションマネージャーＢはセッション
が終了されることを留意し、セッションマネージャーＡに取引の拒否を通知する
。セッションマネージャーＡはセッションが終了されることを同様に留意する（
ステップ３１０−３１２）。証明書（ＴＡ）が有効であれば、セキュリティマネ
ージャーＢは信託エージェントＡが非信託リストに載っているかどうかをチェッ
クする（ステップ３１４−３１６）。信託エージェントＡが非信託であれば、セ
ッションは終了される（ステップ３１０−３１２）。

【００６４】Ａが非信託リストに載っていなければ、乱数発生器Ｂは乱数Ｒ（Ｂ）及びＢ検
証メッセージも生成する（ステップ３１８）。乱数Ｒ（Ｂ）は、最終的にセッシ
ョン鍵を形成するのに使用される。Ｂ検証メッセージは、Ｂがメッセージ返信に
対して保護するのに使用する乱数である。次に、機密保持マネージャーＢはＲ（
Ｂ）、Ｂ検証メッセージ、及び証明書（ＴＡ）を信託エージェントＡのためのメ
ッセージに組み合わせる（ステップ３２０）。公開鍵Ｂは、信託エージェントＢ
がＡの証明書（ＴＡ）と共に受信した信託エージェントＡの公開鍵（ＴＡ（ＰＫ
））を使用してメッセージを暗号化する（ステップ３２２）。セッションマネー
ジャーＢは、暗号化されたメッセージをＡのセッションマネージャーに送信する
（ステップ３２４−３２６）。

【００６５】公開鍵Ａはメッセージを（その公開鍵に対応する）そのプライベート鍵を利用
して復号化して証明書（ＴＡ）の有効性を検証する（ステップ３２８−３３０）
。証明書（ＴＡ）が無効であれば、セッションマネージャーＡはセッションが終
了されたことに留意し、取引拒否メッセージをＢに送信し、そのセッションマネ
ージャーは同様にセッションが終了されたことに留意する（ステップ３３２−３
３４）。証明書（ＴＡ）が有効であれば、機密保持マネージャーＡは信託エージ
ェントＢが非信託リストに載っているかどうかをチェックする（ステップ３３６
−３３８）。信託エージェントＢがリストに載っていれば、セッションは終了さ
れる（ステップ３３２−３３４）。

【００６６】Ｂが非信託リストに載っていなければ、乱数発生器Ａは乱数Ｒ（Ａ）及びA検証メッセージ（例えば、別の乱数）を作成する（ステップ３４０）。日時機能は
現在の日時を機密保持マネージャーに移す（ステップ３４２）。日時は、Ａ及び
Ｂが、コミット中に取引ログの最終的な記録と交換する。機密保持マネージャー
Ａは、その後、乱数Ｒ（Ａ）及びＲ（Ｂ）を排他的ＯＲすることによって、セッ
ション鍵（ＴＡ／ＴＡ）を形成して格納する（ステップ３４４）。セッション鍵
（ＴＡ/ＴＡ）は、２つの信託エージェント１２０間で通信を暗号化するのに使用される。セッションマネージャーＡは、Ａ及びＢ検証メッセージ、日時情報、
及び、Ｒ（Ａ）を含むメッセージを組み合わせる（ステップ３４４）。公開鍵Ａ
はメッセージを（証明書（ＴＡ）でＡから受信した）信託サーバーＢの公開鍵で
暗号化し、暗号化されたメッセージを信託サーバーＢのセッションマネージャー
に送信する（ステップ３４６−３５０）。

【００６７】公開鍵Ｂは受信したメッセージを（その公開鍵に対応する）その秘密鍵を使用
して復号化する（ステップ３５２）。機密保持マネージャーＢは、Ａから受信し
たＢ検証メッセージが、それが以前にＡに送信したＢ検証メッセージと同一であ
るかどうかをチェックする（ステップ３５４−３５６）。同一でなければセッシ
ョンは終了される（ステップ３１０−３１２）。同一であれば、セッションマネ
ージャーＢはセッションの開始に留意する（ステップ３５８）。

【００６８】機密保持マネージャーＢは、Ｒ（Ａ）ＸＯＲＲ（Ｂ）によってセッション鍵
（ＴＡ／ＴＡ）を形成し、そのセッション鍵を格納する（ステップ３６０）。こ
の時点で、ＡとＢの両方は、彼らの現在の対話に使用される同一のセッション鍵
（即ち、セッション鍵（ＴＡ/ＴＡ））を作成して格納する。次に、日時Ｂは、その現在の日時情報を機密保持マネージャーＢに送信する（ステップ３６２）。
機密保持マネージャーＢは、Ａへの受領書、A検証メッセージ及びＢの日時情報を有するメッセージを作成する（ステップ３６４）。メッセージをＢからＡに送
信するために、メッセージ送信サブルーチンが、その後、呼び出される（ステッ
プ３６６）。

【００６９】図１０を参照するに、信託エージェントＢの対称鍵機能はセッション鍵（ＴＡ
／ＴＡ）を利用してメッセージを暗号化する（ステップ３７６）。メッセージイ
ンターフェースＢは、その後、メッセージをフォーマットしてそれをホストプロ
セッサのメッセージマネージャーに送信する（ステップ３７８）。ホストメッセ
ージマネージャーＢは、その後、メッセージを、『通信』を介して、信託エージ
ェントＡのホストプロセッサのホストメッセージマネージャーＡに発送する（ス
テップ３８０）。ホストメッセージマネージャーＡは、その後、メッセージを、
メッセージを細切れにする信託エージェントＡのメッセージインターフェースに
送信する。対称鍵Ａはメッセージをセッション鍵（ＴＡ／ＴＡ）で復号化し、こ
れにより、セッション鍵（ＴＡ／ＴＡ）を使用して信託エージェント間で機密保
持のなされたメッセージの通信を完了する（ステップ３８６）。

【００７０】図９を再び参照するに、機密保持マネージャーＡは受領書、A検証メッセージ及びＢの日時情報を受信する（ステップ３６８）。機密保持マネージャーＡは、
A検証メッセージが、Ａが以前にＢに送信したA検証メッセージと同一であるかど
うかをチェックする（ステップ３７０−３７２）。同一でなければ、セッション
マネージャーＡはセッションを終了する（ステップ３３２−３３４）。同一であ
れば、セッションマネージャーＡはセッションの開始に留意する（ステップ３７
４）。

【００７１】図８を再び参照するに、セッション設定後に、信託エージェントＡは、米国特
許第５，５５７，５１８号にも記載されているように、信託エージェントＢの顧
客の信用状を要求してチェックする。特に、信用状チェックサブルーチンが呼び
出される（ステップ７０８）。ＣＴＤ１８８が保持する顧客信用状は、個人の運
転免許証やクレジットカードを含み、顧客信用状は様々なＩＤ機関によって発行
された商業信用状であってもよい。全てのＭＴＤ１９８は、所有者／商人を識別
する信用状を含んでいる。かかる商人信用状は、例えば、信託エージェンシーに
よって管理される商人ＩＤ機関によって発行されてもよい。図１１を参照するに
、『購入』Ａは、信託エージェントＢの『購入』Ｂにメッセージを送信し、その
顧客信用状を要求する（ステップ４４４−４４８）。チケット所持者Ｂはその顧
客信用状を検索して信用状を有効化のためにＡに送信する（ステップ４５０−４
５６）。

【００７２】チケット８の信用状その他のいかなる種類も以下のように有効化される。１）発行者証明書を有効にして発行者署名をチェックする。２）各移転を検証し、受信者及び送信者の識別子を一致させる（即ち、Ｓ₀ ＝発行者、Ｒ₀＝最初の受信者、その後、Ｒ_i＝Ｓ_i+1、ｉ＞０）。３）各送信者証明書を有効にして各送信者署名をチェックする。４）最後の受信者識別子が現在のセッションの信託エージェントの証明書（
証明書（ＴＡ））の識別子（ＴＡ（ｉｄ））に一致することを確認する。

【００７３】顧客信用状が有効でなければ、取引中止サブルーチンを呼び出すことによって
取引は中止される（ステップ４５８）。図１２を参照するに、信託エージェント
Ａは中止し（ステップ３８８）、信託エージェントＢのセッションマネージャー
にメッセージを送信し、ＢにＡが中止した旨を通知する（ステップ３９０−３９
４）。信託エージェントＢはその後中止する（ステップ３９６）。図１１に戻っ
て、顧客信用状が有効であれば『至ホスト』Ａは信用状情報を、確認（例えば、
送り状の顧客の身元が顧客信用状の顧客の身元に一致することの確認）のために
、ホスト取引アプリケーションに送信する（ステップ４６０−４６２）。

【００７４】図８を再び参照するに、『至ホスト』Ａは、いかなる送り状及び期限の過ぎた
通知をも顧客への呈示用に要求する（ステップ７１０）。ＨＴＡは、その後、『
至ホスト』Ａが受信した、要求された送り状及び期限の過ぎた通知を信託エージ
ェントＡに送信する（ステップ７１２−７１４）。公開鍵Ａは、いかなる送り状
及び期限の過ぎた通知をも署名し、署名（例えば、グループディジタル署名）を
チケット所持者Ａに送信する（ステップ７１６）。チケット所持者Ａは、その後
、顧客に呈示される送り状及び／又は期限の過ぎた通知を識別するのに使用可能
な呈示チケットを作成する。『購入』Ａは、送り状及び／又は期限の過ぎた通知
及び呈示チケットを信託エージェントＢに送信する（ステップ７２０−７２４）
。公開鍵Ｂは、その後、呈示チケット及び送り状／期限の過ぎた通知の署名を検
証する（ステップ７２６−７２８）。チケット又はディジタル署名が無効であれ
ば、取引は中止される（ステップ７３０）。有効であれば、『購入』Ｂは呈示チ
ケットをチケット所持者Ｂに送信し、『至ホスト』Ｂはチケット情報（例えば、
商人識別子）及び送り状及び期限の過ぎた通知をＨＴＢに送信する（ステップ７
３２−７３４）。顧客信託エージェントは、その後、信用状チェックサブルーチ
ンを開始し（ステップ７３６）、これによって、商人の信用状は顧客信託エージ
ェントに送信される。信用状チェックサブルーチン中に、ホスト取引アプリケー
ションは、例えば、送り状の商人の身元は商人信用状の商人の身元に一致するこ
とを確認することによって商人の信用状を確認する（ステップ４６０−４６２）
。

【００７５】顧客信託エージェントの取引ログは、その後、取引の現在の状態を記録するた
めに暫時ログ更新を実行する。かかる更新は、呈示チケットから少なくとも基本
情報を記録しなければならない（例えば、顧客情報及び送り状／期限の過ぎた通
知のディジタル署名）（ステップ７３８）。セッションマネージャーＢは中止の
際に暫時更新がロールバックされない（即ち、覆されない）ことを確認する（ス
テップ７４０）。受領書は、その後、信託エージェントＡに送信され、セッショ
ンマネージャーによって受信される（ステップ７４２−７４４）。商人の信託エ
ージェントは、その後、呈示チケットからの少なくとも基本情報の暫時取引ログ
更新も実行する（ステップ７４６）。チケット所持者Ａは呈示チケットをホスト
に送信し（ステップ７４８）、これによってそれは、信託エージェントの外部に
呈示チケットを更に格納する。セッションマネージャーＡは商人信託エージェン
トの暫時更新が中止の場合にロールバックしないことを確認する（ステップ７５
０）。セッションマネージャーは、その後、取引を継続するために、メッセージ
を信託エージェントＢに送信する（ステップ７５０−７５４）。

【００７６】ホストは、送り状及び／又は期限の過ぎた通知に対応する現存する送金情報を
チェックすることを尋ねられる。そこで、ＨＴＢは、いずれかが既に支払われた
かどうかを検証するために、送り状及び／又は期限の過ぎた通知を未払金システ
ム１８９に送信する（ステップ７５６−７６０）。

【００７７】ある送り状及び／又は期限の過ぎた通知が以前に支払われれば、ＨＴＢは対応
する送金通知及び商業的支払いチケットを受信する（ステップ７６２）。これら
の送金通知及び商業的支払いチケットは信託エージェントＢを介して有効化のた
めに信託エージェントＡに送られる（ステップ７６４−７６８）。公開鍵Ａは商
業的支払いチケットで署名を有効にする（ステップ７７２）。商業的支払いチケ
ットのいずれもが有効であれば、有効な送金情報がホストＡに送信される。ホス
トＡはこの情報を売掛金システム１９３に送り、信託エージェントＡに処理続行
を通知する（ステップ７８２−７８４）。売掛金システムは、送られた送金情報
をそのデータベースの送金情報に一致させる。

【００７８】商業的支払いチケットの全てが有効であれば、『購入』Ａは単に受領書を『購
入』Ｂに送信する（ステップ７８８−７９２）。しかし、商業的支払いチケット
の全部又はいくつかが無効であれば、『購入』Ａは無効送金情報を『購入』Ｂに
送信し、それはホストＢにそれを送信する。ホストＢは無効情報を未払金システ
ム１８９に送る（ステップ７７４−７８１）。未払金システムは無効送金情報を
そのデータベースの送金情報に一致させる。

【００７９】ホストＢが、呈示された送り状又は期限の過ぎた通知のいずれもが支払われて
いないと決定すると（ステップ７６０）又はステップ７８１後で、ＨＴＢはいず
れの送り状又は期限の過ぎた通知が現在支払われるべきかであるかどうかをチェ
ックする（ステップ７９６−７９８）。同様に、ステップ７９２後で、顧客信託
エージェントは、いずれかの呈示された送り状及び／又は期限の過ぎた通知の支
払いに関する指示をそのホストに促す（ステップ７９４）。いずれもが支払われ
るべきでない場合には、ＨＴＢは信託エージェントＢに通知する。信託エージェ
ントＢは、いずれも支払われない旨のメッセージを信託エージェントＡに送信し
（ステップ８００−８０６）、その後コミットする（ステップ８０８）。支払わ
ない旨のメッセージを受け取ると、信託エージェントＡは同様にコミットする（
ステップ８１０−８１２）。信託エージェントＢがコミットすると、ホストＢは
未払い送り状及び期限の過ぎた通知を未払金システム１８９にセットアップのた
めに送信するように指示される（ステップ８８０）。信託エージェントＡがコミ
ットすると、ホストＡは呈示チケットを売掛金システム１９３に呈示の有効化の
ために送信するように指示される。

【００８０】どの送り状及び／又は期限の過ぎた通知が支払われるべきかについて決定がな
される。この決定は、例えば、ホスト又は外部（の一又は複数の装置）で、単独
又は、自動未払金システムなどの他の装置又は人間のオペレータと協同して、実
行される現金管理機能によってなされることができる。全て又はいずれかの送り
状又は期限の過ぎた通知が支払われるべきであれば、ホストは信託エージェント
Ｂにそのマネーモジュールが十分な資金を有するかどうかをチェックするように
尋ねるよう命令する（ステップ７９８、８１３−８１６）。マネーモジュールの
資金が不十分であれば、信託エージェントＢはそのホストからの指図を要求する
（ステップ８１８）。ＨＴＢは、他の取引装置１２２が要求された金額を有する
かどうかをチェックする（ステップ８２０−８２２）。別の取引装置Ｃが十分な
資金を有すれば、ＨＴＢはＨＴＣに電子マネーを送信するためのメッセージを送
信する（ステップ８２４）。電子マネーによる支払い（ステップ８２８）は、米
国特許第５，４５３，６０１号に記載されているように達成することができる。

【００８１】別の取引装置Ｃが十分な金額の電子マネーを有していない場合、ＨＴＢは金額
が銀行から引き出し可能であるかどうかをチェックする（ステップ８３０−８３
２）。電子マネーは、その後、例えば、米国特許第５，４５３，６０１号に記載
されているように、銀行から引き出し可能となる（ステップ８３４）。銀行から
の引き出しが不可能であれば、ＨＴＢは支払い可能な送り状及び／又は期限の過
ぎた通知の小派を選択する（ステップ８３６）。かかる選択は、例えば、現金管
理システム又は人間のオペレータから受信した優先順位情報に基づくことができ
る。支払い可能な品目がなければ、ＨＴＢは信託エージェントＢに支払い可能な
送り状又は期限の過ぎた通知がないことを通知する（ステップ８３８及び８００
）。信託エージェントＢは、その後、信託エージェントＡに通知して、両信託エ
ージェントは前述したようにコミットする（ステップ８０２−８１２）。同様に
、ホストはそれら各々の未払金及び売掛金システムを更新する（ステップ８８０
及び８８６）。

【００８２】十分な資金がマネーモジュールＢに存在すれば、ＨＴＢは送金通知を作成して
それを信託エージェントＢに送信する（ステップ８４０）。信託エージェントＢ
は送金通知を信託エージェントＡに送信する（ステップ８４２−８４４）。『購
入』Ａは、送り状及び期限の過ぎた金額に対する送金通知総額を有効にする（ス
テップ８４６−８４８）。

【００８３】金額が有効にされなければ取引は中止される（ステップ８５０）。有効にされ
れば、送金通知はホストＡに送信される（ステップ８５２）。公開鍵Ａは、その
後、送金通知に署名をしてディジタル署名をチケット所持者Ａに送信する。チケ
ット所持者Ａは、信託エージェントＢにチケット及び送信通知署名の有効化のた
めに送信される商業的支払いチケットを作成する（ステップ８５４−８６４）。
有効でなければ、取引は中止され（ステップ８６６）、ホストは各未払金及び売
掛金システムを更新する（ステップ８８０及び８８６）。

【００８４】信託エージェントＢが商業的支払いチケット及び通知署名が有効であると決定
すると、『購入』Ｂはチケットをチケット所持者Ｂに送信する（ステップ８６８
）。信託エージェントＢは、その後、後述するように、マネーモジュールＢから
マネーモジュールＡへマネーモジュールによる支払いを開始する（ステップ８７
４）。

【００８５】信託エージェントＢは、米国特許第５，５５７，５１８号に記載されているよ
うに、信託エージェントＡに対するマネーモジュールによる支払いを実行する。
特に、マネーモジュール支払いサブルーチンが呼び出される。図１３を参照する
に、乱数発生器Ｂは乱数Ｒ（１）を生成する（ステップ５２０）。『購入』Ｂは
、その後、「マネーモジュールによる支払い」がなされてＲ（１）も含む旨を表
示するメッセージを信託エージェントＡに送信する（ステップ５２２−５２４）
。『購入』Ａはメッセージを受信してＲ（１）を機密保持マネージャーＡに送信
する（ステップ５２６−５２８）。乱数発生器Ａは、乱数Ｒ（２）を生成してそ
れを信託エージェントＢに送信する（ステップ５３０−５３２）。機密保持マネ
ージャーＢ及びＡの両方は、Ｒ（１）及びＲ（２）を排他的ＯＲすることによっ
てセッション鍵（ＴＡ／ＭＭ）を形成する（ステップ５３４−５３６）。

【００８６】図１４を参照するに、取引中に設定された４つの暗号チャンネルが示されてい
る。２つの信託エージェント１２０の間の暗号チャンネル４３６は、セッション
鍵（ＴＡ／ＴＡ）によって暗号化されたメッセージを運ぶ。信託エージェント１
２０及びそのマネーモジュール６間のチャンネル４３８及び４４０は、セッショ
ン鍵（ＴＡ／ＭＭ）を共有する。異なる取引装置１２２のマネーモジュール６間
のチャンネル４４２はセッション鍵（ＭＭ／ＭＭ）を使用する。

【００８７】セッション鍵（ＴＡ／ＭＭ）は、暗号チャンネル４３８及び４４０を介して、
信託エージェント１２０とその関連マネーモジュール６間で送信されるメッセー
ジを暗号化するのに使用される。フローチャートの現時点では、２つの信託エー
ジェント１２０のみがセッション鍵（ＴＡ／ＭＭ）を有する。両マネーモジュー
ル６は、信託エージェント１２０とそれらのマネーモジュール６との間で暗号化
された通信を可能にするために、フローチャートの後においてセッション鍵（Ｔ
Ａ／ＭＭ）のコピーを形成する。

【００８８】前述したように、信託エージェント１２０とマネーモジュール６が別個の改ざ
ん防止コンポーネントとして具体化される代わりに、それらが一の改ざん防止モ
ジュールとして組立てられることができることに留意する必要がある。この場合
、機密保持のなされた通信用のセッションを同一の取引装置１２２の信託エージ
ェント１２０とマネーモジュール６との間に設定する必要はない。しかし、別個
のマネーモジュール６と信託エージェント１２０は、構成がより大きなアプリケ
ーションの弾力性を可能にする点で、好ましいかもしれない。

【００８９】図１３に戻って、『至マネーモジュール』Bは「支払いをする」メッセージ及びＲ（１）をその関連マネーモジュールＢに送信する。同様に、『至マネーモジ
ュール』Ａは「支払い受領」メッセージ及びＲ（２）をその関連マネーモジュー
ルＡに送信する（ステップ５３８−５４４）。

【００９０】この時点で、各マネーモジュール６が新しいセッション鍵（ＭＭ／ＭＭ）を保
持して終了するように、マネーモジュールＢ及びマネーモジュールＡはその間に
セッションを設定する（ステップ５４６）。このマネーモジュール対マネーモジ
ュールセッションを設定する際に、マネーモジュールは、既に現存する信託エー
ジェントのセッションを介して、メッセージを交換する。図１４を参照するに、
暗号化チャンネル４４２のためのセッション鍵は、チャンネル４３６によって暗
号化されたメッセージを交換することによって形成される。マネーモジュールセ
ッションが設定された後で、マネーモジュール間で送信されるメッセージは、信
託エージェント１２０の通信路の一部に沿って、両セッション鍵（ＭＭ／ＭＭ）
及びセッション鍵（ＴＡ／ＴＡ）によって２度暗号化される。

【００９１】好ましい実施例においては、マネーモジュールセッションは信託エージェント
セッションの設定と同様の方法で設定される。マネーモジュール６は、従って、
それらの公開鍵を含むそれら自身の証明書を保持する。証明書及び（排他的ＯＲ
のための）乱数の交換はセッション鍵（ＭＭ／ＭＭ）の機密保持のなされた作成
を可能にする。マネーモジュールによって使用されるセッション設定プロトコル
は、米国出願第０８／４２７，２８７号に記載され、図１５に示されている。『
機密保持の維持』Ｂはセッションマネージャーにモジュール証明書を送信し、セ
ッションマネージャーＢは証明書を受信してマネーモジュールＢがネットワーク
に接続されているかどうかをチェックする（ステップ１４６４−１４６６）。マ
ネーモジュールＢがネットワークに接続されていなければ、セッションマネージ
ャーＢは『機密保持の維持』Ｂから受信した証明書を目的地Ａに送信する（ステ
ップ１４７６）。

【００９２】代替的に、マネーモジュールＢがネットワークに接続されていれば、対称鍵Ｂ
は証明書をＫで暗号化し、セッションマネージャーＢは暗号化された証明書をネ
ットワークサーバーに送信する（ステップ１４６８−１４７２）。ネットワーク
サーバーは証明書をＫで復号化して目的地Ａに証明書を送信する。

【００９３】証明書がネットワークサーバーによって、又は、セッションマネージャーＢに
よって送信されるかどうかに拘らず、セッションマネージャーＡは証明書を受信
して『機密保持の維持』Ａ（Ａが機密保持サーバーであればこの機能はセッショ
ンマネージャーによって行われる）は証明書を有効にする（ステップ１４８０−
１４８２）。証明書が有効でなければ、セッションマネージャーＡはセッション
が終了されたことを留意して加入者又は銀行のどちらかに通知する（ステップ１
４８６−１４９２）（Ａが機密保持サーバーであればＡは単に取引が終了された
ことを留意する）。

【００９４】証明書が有効であれば『機密保持の維持』ＡはＢが不良ｉｄリストに載ってい
るかどうかをチェックする（ステップ１４９４−１４９６）。Ｂがリストに載っ
ていれば、セッションは終了される。Ｂがリストに載っていなければ乱数発生器
Ａは乱数Ｒ（Ａ）及びA検証メッセージを生成する（ステップ１４９８）。クロック／タイマＡは日時を検索する（ステップ１５００）。『機密保持の維持』Ａ
は、Ｒ（Ａ）、A検証メッセージ及び日時をメッセージに組み込む（ステップ１５０２）。公開鍵ＡはメッセージをＢの公開鍵で暗号化し、セッションマネージ
ャーＡはＡの証明書を暗号化されたメッセージに添付し、メッセージをＢに送信
する（ステップ１５０４−１５０６）。

【００９５】セッションマネージャーＢはメッセージを受信し、公開鍵Ｂは暗号化されたメ
ッセージの一部を復号化し、『機密保持の維持』ＢはＡの証明書を有効にする（
ステップ１５０８−１５１４）。証明書が有効でなければ、セッションマネージ
ャーＢはセッションの終了に留意し、加入者または銀行のどちらかに通知する（
ステップ１５１６−１５２２）。証明書が有効であれば、『機密保持の維持』Ｂ
はＡが不良ｉｄリストに載っているかどうかをチェックする（ステップ１５２４
−１５２６）。Ａがリストに載っていれば、セッションは終了される。Ａがリス
トに載っていなければ、『機密保持の維持』Ｂは日時を検索してＡの日時とそれ
を比較する（ステップ１５２８−１５３０）。日時が範囲外であれば、セッショ
ンは終了される。

【００９６】日時が範囲内であれば、乱数発生器Ｂは乱数Ｒ（Ｂ）及びＢ検証メッセージを
生成する（ステップ１５３２）。『機密保持の維持』Ｂは、その後、Ｒ（Ｂ）ＸＯＲＲ（Ａ）の演算によってセッション鍵を形成する（ステップ１５３４）。Ｂ検証メッセージ、A検証メッセージ、日時及びＲ（Ｂ）はメッセージに組み込まれてＡの公開鍵で暗号化される（ステップ１５３６）。メッセージはセッシ
ョンマネージャーＢによってＡに送信される（ステップ１５３８）。セッション
マネージャーＡはメッセージを受信し、公開鍵Ａはメッセージを復号化し、『機
密保持の維持』ＡはA検証メッセージをチェックする（ステップ１５４０−１５４６）。A検証メッセージが間違っていれば、セッションは終了される。A検証メ
ッセージが正しければ、『機密保持の維持』Ａは、Ｒ（Ｂ）ＸＯＲＲ（Ａ）に
よってセッション鍵を形成する（ステップ１５４８）。日時が検索され、Ｂの日
時に比較され、それらが互いに所定の範囲内にあるかどうかがチェックされる（
ステップ１５５０）。日時が範囲外であれば、セッションは終了される。日時が
範囲内であれば、セッションマネージャーＡはセッションの開始に留意する（ス
テップ１５５２）。

【００９７】セッションマネージャーＡは、その後、受領書及びＢ検証メッセージをＢに送
信する（ステップ１５５４−１５５６）。セッションマネージャーＢはメッセー
ジを受信し、『機密保持の維持』ＢはＢ検証メッセージをチェックする（ステッ
プ１５５８−１５６２）。検証メッセージが正しくなければ、セッションは終了
される。検証メッセージが正しければ、セッションマネージャーＢはセッション
の開始に留意する（ステップ１５６４）。

【００９８】マネーモジュールに関わるシステムの機密保持全体は信託エージェント１２０
のそれに統合可能であるが、強化されたシステムの機密保持とシステムの弾力性
を与えるために好ましくは別々にされる。

【００９９】図１３に戻るに、マネーモジュールＢはＲ（１）をマネーモジュールＡに送信
する。この機能は、マネーモジュールＢにあるＭＭ『機密保持の維持』Ｂアプリ
ケーションによって開始されることができる（ステップ５４８）。このアプリケ
ーションその他のマネーモジュールのアプリケーションは、指定「ＭＭ」が頭に
つけられ、米国特許第５，５５７，５１８号に開示された変形及び／又は付加と
共に、共通して譲渡された米国特許第５，４５３，６０１号に記載されている。

【０１００】乱数Ｒ（１）はマネーモジュールＢからマネーモジュールＡに発送メッセージ
送信サブルーチンによって送信される（ステップ５５０）。図１６を参照するに
、ＭＭ対称鍵Ｂは（Ｒ（１）を含む）メッセージをセッション鍵（ＭＭ／ＭＭ）
で暗号化する（ステップ６４０）。ＭＭセッションマネージャーＢはメッセージ
をホストメッセージマネージャーＢに送信し、それは、今度は、メッセージを信
託エージェントＢのメッセージインターフェースＢに送信する（ステップ６４２
−６４６）。信託エージェントＢは、その後、メッセージを信託エージェントＡ
のメッセージインターフェースＡに、信託エージェント間でメッセージをセッシ
ョン鍵（ＴＡ／ＴＡ）で暗号化及び復号化するメッセージ送信サブルーチン（ス
テップ６４８）を使用して、送信する。メッセージインターフェースＡは、その
後、ホストメッセージマネージャーＡを介してメッセージをマネーモジュールＡ
のＭＭセッションマネージャーに送信する（ステップ６５０−６５４）。最終的
に、ＭＭ対称鍵Ａはメッセージをセッション鍵（ＭＭ／ＭＭ）で復号化する（ス
テップ６５６）。

【０１０１】図１３を再び参照するに、（マネーモジュールＡの）ＭＭ『機密保持の維持』
Ａは、Ｒ（１）及びＲ（２）を排他的ＯＲすることによってセッション鍵（ＴＡ
／ＭＭ）を形成する。マネーモジュールＡは、その後、Ｒ（１）及びＲ（２）を
排他的ＯＲすることによってセッション鍵（ＴＡ／ＭＭ）を同様に形成するマネ
ーモジュールＢにＲ（２）を送信する（ステップ５５２−５５６）。図１４を参
照するに、この時点では、（ＭＭ／ＭＭ）、（ＭＭ／ＴＡ）及び（ＴＡ／ＴＡ）
という３つのセッション鍵が存在する。従って、図示された４つの暗号チャンネ
ルは所定位置に存在する。

【０１０２】図１３を参照するに、ＭＭ『至加入者』Ｂは、手形の種類（例えば、ドル、円
、ポンドなど）による支払い金額を信託エージェントＢに促す（ステップ５５８
）。米国特許第５，４５３，６０１号に記載されているように、マネーモジュー
ルはマネーモジュールの所有者／所持者と通信するのに『至加入者』アプリケー
ションを一般に使用する。しかし、本実施例で使用されるように、『至加入者』
アプリケーションは、様々な指示を得るのに信託エージェント１２０と通信する
。ここで、信託エージェント１２０は、（信託エージェントＡが金額を決定する
ために取引装置１２２の所有者／所持者と以前に交信した）支払い金額と手形の
種類情報を発送する。

【０１０３】マネーモジュール６から信託エージェント１２０へのプロンプト応答はＭＭ／
ＴＡメッセージ送信サブルーチンを介して送信される（ステップ５６０）。図１
７を参照するに、ＭＭ対称鍵Ｂがメッセージをセッション鍵（ＴＡ／ＭＭ）で暗
号化する（ステップ６５８）。ＭＭセッションマネージャーＢはメッセージを信
託エージェントＢのメッセージインターフェースにホストメッセージマネージャ
ーＢを介して送信する（ステップ６６０−６６４）。対称鍵Ｂはメッセージをセ
ッション鍵（ＴＡ／ＭＭ）で復号化する（ステップ６６６）。図１３に戻るに、
信託エージェントＢの『購入』Ｂは手形の種類による金額をマネーモジュールＢ
のＭＭ『支払い／交換』Ｂに送信する（ステップ５６２−５６６）。このメッセ
ージはＴＡ／ＭＭメッセージ送信サブルーチンを介して送信される（ステップ５
６４）。図１８を参照するに、対称鍵Ｂはメッセージをセッション鍵（ＴＡ／Ｍ
Ｍ）で暗号化する（ステップ６６８）。メッセージインターフェースＢはメッセ
ージを、ホストメッセージマネージャーＢを介して、マネーモジュールＢのＭＭ
セッションマネージャーに送信する（ステップ６７０−６７４）。最後に、ＭＭ
対称鍵Ｂはメッセージをセッション鍵（ＴＡ／ＭＭ）で復号化する（ステップ６
７６）。

【０１０４】図１３を参照するに、ＭＭ手形ディレクトリＢは、マネーモジュール６が支払
いをカバーするのに十分な資金を有しているかどうかをチェックする（ステップ
５６８−５７０）。不十分であれば、マネーモジュールＢ及びＡは取引を中止す
る（ステップ５７２−５８２）。マネーモジュールＢの資金はステップ８１６で
既にチェック済みであるので、不十分な資金の状態は発生してはならない。それ
にも拘らず、ＭＭ取引中止プロトコルは完全性のために記載されている。

【０１０５】ＭＭ取引中止プロトコル（ステップ５８２）は、米国出願第０８／４２７，２
８７号に記載されて図１９に示されているような、好ましい電子マネーシステム
のそれであってもよい。セッションマネージャーＸは変更をロールバックし、取
引中止に留意する（ステップ１７２６）。セッションマネージャーＸは、その後
、「コミット準備完了」メッセージが送信されたかどうかをチェックする（ステ
ップ１７２８−１７３０）。そうであれば、Ｘは、コミット準備完了メッセージ
を送信した後にＸがコミットしたことを記録することによって、そして、手形移
転プロトコル中に受信された各手形の手形識別子及び金額を記録することによっ
て、その取引ログを更新する（ステップ１７３２）。従って、失敗したコミット
サブルーチン中に中止サブルーチンが呼び出されると、中止プロトコルは情報を
ログする。

【０１０６】Ｘが取引マネーモジュール１１８６であり、かつ、コミット準備完了メッセー
ジが送信されると、『至加入者』Ｘはその加入者に取引が中止されたこと、及び
、マネーの移転エラーが発生した可能性があることを通知する（ステップ１７３
４−１７３８）。

【０１０７】Ｘがテラーマネーモジュール１１８８であれば、『至銀行』Ｘは銀行に対して
、それがその会計取引を（適当な借方記入及び貸方記入によって）覆さなければ
ならないこと通知する（ステップ１７４０−１７４２）。Ｘが取引マネーモジュ
ールであり、かつ、コミット準備メッセージがなければ、『至加入者』Ｘは加入
者に取引が中止された旨を通知する（ステップ１７４４）。

【０１０８】いずれにしても、セッションマネージャーＸは、その後、取引が完了できない
旨のメッセージをＹに送信する（ステップ１７４６−１７４８）。セッションマ
ネージャーＹはその変更をロールバックし、取引が中止されたものと留意する（
ステップ１７５０）。Ｙは、その後、取引が中止された旨をその加入者に通知す
る（ステップ１７５２−１７５４）か、銀行にその会計取引を覆すように通知す
る（ステップ１７５６−１７５８）。

【０１０９】述べたように、コミットプロトコル中に取引が中断されると、手形が失われる
場合がある。これが生じると、譲受人は手形の移転を中止して譲渡人はコミット
する。この場合、譲受人マネーモジュールはそれが受け取らなければならない手
形の情報を記録し、加入者に潜在的な問題があること（即ち、Ｂから送信された
手形を受け取っていないこと）を通知する。譲渡人マネーモジュールが関わる限
り、それは手形を適当に移転したことをこの状況では留意する必要がある。

【０１１０】譲受人マネーモジュール加入者は、その後、証明エージェンシーに対してマネ
ーに関する請求を作成することができる。請求情報は失敗した取引のログ記録を
含むだろう。証明エージェンシーは、その後、手形が一致したかどうかをみるた
めに、発行銀行を利用してチェックすることができる。ある期間の経過後に、手
形が一致していなければ加入者は彼のマネーを再請求することができるだろう。

【０１１１】図１３を再び参照するに、マネーモジュールＢとマネーモジュールＡとの間で
メッセージは、３つ全てのセッション鍵（ＭＭ／ＭＭ）、（ＴＡ／ＭＭ）及び（
ＴＡ／ＴＡ）を利用する電子発送メッセージ送信サブルーチンを介して送信され
る。図２０を参照するに、ＭＭ対称鍵Ｂはメッセージをセッション鍵（ＭＭ／Ｍ
Ｍ）で暗号化する（ステップ６７８）。メッセージは、その後、それが信託エー
ジェントＢに送信される前に、セッション鍵（ＭＭ／ＴＡ）によって二重に暗号
化される。一旦信託エージェントＢが受信すると、メッセージはセッション鍵（
ＭＭ／ＴＡ）によって復号化される（ステップ６８０）。メッセージインターフ
ェースＢは、その後、メッセージをメッセージインターフェースＡに送信する（
ステップ６８２−６８４）。信託エージェント１２０間においては、メッセージ
はセッション鍵（ＴＡ／ＴＡ）によって二重に暗号化される。同様に、メッセー
ジインターフェースＡは、メッセージをＭＭ対称鍵Ａに最終復号化用に送信する
（ステップ６８６−６９０）。図１４は、様々な暗号化レイヤを示している。

【０１１２】図１３を再び参照するに、マネーモジュールＢ及びＡの中止ルーチン中（ステ
ップ５８２）に、それらはそれらの信託エージェントＢ及びＡにそれぞれ送信さ
れるメッセージを生成し（ステップ５８４−５８６）、彼らが取引を中止したこ
と及びそのために支払いが不成功であったことをそれらに通知する。セッション
マネージャーＢ及びＡは支払いが不成功であり、その結果、信託エージェントＢ
及びＡが中止する旨を留意する。

【０１１３】マネーモジュールＢが十分な資金を有する場合、ＭＭ『支払い／交換』Ｂはマ
ネーモジュールＡに、移転されるマネーの金額と手形の種類を含むメッセージを
送信する（ステップ６００）。このメッセージは、電子発送メッセージ送信サブ
ルーチンによって送信される（ステップ６０２）。

【０１１４】マネーモジュールＡは、マネーモジュールＢに従って、支払い金額を含むメッ
セージを受信する。ＭＭ『至加入者』Ａは、その後、この支払い金額を検証する
ために、信託エージェントＡにプロンプト応答を送信する（ステップ６０４−６
０６）。そこで、信託エージェントＡの『購入』Ａは、金額が正しいかどうかを
検証する（ステップ６０８−６１０）。正しければ、信託エージェントＡはマネ
ーモジュールＡに「正しい金額」メッセージを送信する。間違っていれば、「間
違った金額」メッセージが送信される（ステップ６１２−６１６）。「間違った
金額」メッセージの場合、マネーモジュールＡはマネーモジュールＢに通知し、
それは、今度は、その信託エージェントに新しい金額の再送信又は中止を要求す
る（ステップ５７２−５８２）。

【０１１５】他方、マネーモジュールＡは「正しい金額」メッセージを信託エージェントか
ら受信すると、マネーモジュールＡは受領書メッセージをマネーモジュールＢに
返信する（ステップ６２４−６２６）。ＭＭ『支払い／交換』Ｂが受領書メッセ
ージを受信すると、それはその後マネー所持者Ｂにその金額を移す（そのアプリ
ケーションはマネーの電子的代替物を含んで管理する）（ステップ６２８）。正
に説明された支払人開始プロトコルが代わりに、受取人開始払いとして、実行可
能であることに留意する必要がある。

【０１１６】図１３を再び参照するに、マネーモジュールＢは、その後、電子発送メッセー
ジ経路を介して、マネーモジュールＡに特定された金額の電子手形を移転する（
ステップ６３０）。図２１は、米国出願０８／４２７，２８７号に記載されてい
るように、手形移転プロトコルを示す。手形ディレクトリＸは移転用の手形と価
値を選択し、手形金額及び通し番号を更新し、メッセージを手形に送信する（ス
テップ１５６６）。移転用の手形を選択する可能な目的は、例えば、（１）（処
理時間を要求する）ディジタル署名の数を最小にすること、（２）パケットのサ
イズを最小にすること、(３)移転する加入者に残される電子手形の有用性を最大
にすること（即ち、満了までに残された最小時間で手形を流通すること）を含む
。かかる目的は以下の手形移転アルゴリズムによって達成可能である。即ち、（
１）最少の手形数を含む全ての可能な代替物を決定すること、（２）これらの代
替物のいずれが最少の移転数を有するかを決定すること、(３)ステップ２で一以
上の選択肢があれば最小の貨幣単位日数を有するものを選択することである。こ
こで、貨幣単位日数は、パケットの全ての手形に対して加算された、移転される
べき手形の残余価値かける当該手形が満了するまでの残り日数である。

【０１１７】手形ディレクトリＸからメッセージを受信すると、手形Ｘは、移転される各手
形に添付されるべき移転を作成する（ステップ１５６８）。公開鍵Ｘは手形に対
する署名を作成する（ステップ１５７０）。代替的に、前述したように、各手形
に対して別個のディジタル署名を作成する代わりに、グループ署名技術が使用可
能であり、そこでは、各手形が一方向ハッシュ関数によって処理され、その後、
グループ署名はこれらのハッシュされた手形に基づいて作成される。パケットマ
ネージャーＸは、その後、手形をパケットのそれらの新しい移転及び署名と組み
合わせて、パケットをＹに送信する（ステップ１５７２−１５７４）。パケット
マネージャーＹはパケットを受け取ってそれを解体する（ステップ１５７６）。

【０１１８】『検証』Ｙは手形の全ての証明書（例えば、マネー発生器証明書及び全ての移
転証明書）を有効にする。その後、『検証』Ｙは、移転グループのＩＤ番号が、
電子手形の履歴中ずっと、署名及び証明書グループの証明書のモジュールＩＤ番
号と一致することを検証する。同様に、各手形に対する移転金額の不一致は、電
子手形履歴中ずっと、各連続する移転の移転金額が直前の移転のそれよりも少な
いことを検証することによって、有効にされる。また、移転総額は、それが期待
金額であることを確認するために、チェックされる（ステップ１５７８−１５８
０）。有効でなければ、取引は中止される（ステップ１５８２）。

【０１１９】有効であり、Ｙが取引マネーモジュールであれば、『検証』Ｙは手形満了日を
検証する（ステップ１５８４−１５８８）。手形のいずれかが満了すれば、取引
は中止される。いずれも満了していなければ、『検証者』Ｙは手形移転から各ｉ
ｄを不良ｉｄリストに照らしてチェックする（ステップ１５９０−１５９２）。
移転ｉｄのいずれかが不良ｉｄリストに載っていれば、取引は中止される。

【０１２０】移転ｉｄが不良ｉｄリストに載っていなければ（又はＹが取引マネーモジュー
ルでなければ）、公開鍵Ｙは手形署名の有効性を検証する（ステップ１５９４−
１５９６）。いずれの署名も有効でなければ、取引は中止される。署名が有効で
あれば、『検証者』Ｙは手形アプリケーションに格納されるか取引ログに配置さ
れた手形本体がその手形本体と一致するかどうかをチェックする（ステップ１５
９８−１６００）。一致する各手形本体に対して、いずれかの手形の複製が存在
したかどうかを決定するために、手形移転ツリーが作成される（ステップ１６０
２−１６０４）。手形のいずれかが複製されていれば、取引は中止される。この
複製のチェック（即ち、ステップ１５９８−１６０４）は、不正侵入取引マネー
モジュールを使用して「セルフディーリング」で手形を移転することによってマ
ネーを作成しようとする目的妨害者に対して、特に指向し、かつ、好適である。

【０１２１】複製がないか、手形本体の一致が識別されなければ、手形Ｙはマネー所持者に
手形を配置する（ステップ１６０６）。最後に、手形ディレクトリＹが手形位置
及び金額を更新し、通し番号を初期化もする（ステップ１６０８）。

【０１２２】手形移転処理は、手形の一致を容易にするために、通し番号を更新及び初期化
するステップ、いずれかの手形譲受人が不良ｉｄリストに載っているかどうかを
チェックするステップ、及び、手形の複製をチェックするステップを含むことが
理解されるであろう。これらの追加的な特徴及びステップは、不心得者が、複製
手形を導入して流通させることを困難にし、流通における複製手形を検出する能
力を高める。

【０１２３】図１３に戻るに、ＭＭコミットサブルーチンが呼び出される（ステップ６３２
）。好ましい電子マネーシステムで使用されるようなコミットプロトコルは米国
出願第０８／４２７，２８７号に記載され、図２２に示されている。セッション
マネージャーＸは「コミット準備完了」メッセージをＹに送信する（ステップ１
７０２−１７０４）。これにより、メッセージを受信するモジュールはコミット
する義務が生じる。従来、マネーを移転する場合には、マネーを複製する可能性
を排除するために、最初にコミットする責任を移す本技術が、マネーを移転する
当事者が最初にコミットすることを確認するのに使用されている。

【０１２４】セッションマネージャーＹは、その後、受領書をＸに送信し（ステップ１７０
６−１７０８）、その取引ログを更新することによっていずれかの未払いの取引
にコミットする（ステップ１７１０）。同様に、Ｙが取引マネーモジュールであ
れば、『至加入者』Ｙが加入者に取引の成功を通知する（ステップ１７１２−１
７１４）。セッションマネージャーＹはセッションの終了に留意する（ステップ
１７１６）。

【０１２５】取引ログＸは受領書をＹから受信してその取引ログを更新し、これによって、
未払いの移転をコミットする。ＸはＹと同様な方法でそのコミットを完了する（
ステップ１７１８−１７２４）。

【０１２６】このフローチャートは、マネーモジュール６が信託エージェント１２０と対話
している場合であって、メッセージ送信＝電子発送メッセージ送信で、『至加入
者』メッセージが現実に暗号化されて信託エージェント１２０に送信されている
という理解がある場合には、依然として続く。上記事項に留意して、マネーモジ
ュールＡのＭＭセッションマネージャーは、電子発送メッセージ送信サブルーチ
ンを介して、「コミット準備完了」メッセージをマネーモジュールＢのＭＭセッ
ションマネージャーに送信する（ステップ１７０２−１７０４）。ＭＭセッショ
ンマネージャーＢは、その後、「受領書」メッセージをマネーモジュールＡに送
信し、マネーモジュールＢはコミットする（ステップ１７０６−１７１６）。マ
ネーモジュールＡが「受領書」メッセージを受信すると、それもコミットする（
ステップ１７１８−１７２４）。

【０１２７】マネーモジュールＢ及びＡのコミットルーチン中で、彼らはそれらの信託エー
ジェントＢ及びＡにそれぞれ送信されるメッセージを作成し（ステップ１７１４
、１７２２）、それらは取引をコミットしたために支払いは成功した旨を通知す
る。

【０１２８】図１３を再び参照するに、マネーモジュールはその後両者とも上述の「支払い
成功」メッセージを彼らの信託エージェントに送信する（ステップ５８４−５８
６）。これらのメッセージはセッション鍵（ＴＡ／ＭＭ）によって暗号化される
。セッションマネージャーＢは支払いの成功裡になされたことを検出し、チケッ
ト所持者Ｂは取引日などの支払い情報で商業的支払いチケットを更新する（ステ
ップ５８８、５９２、６３４）。信託エージェントＢは、その後、そのチケット
の保持がもはや「暫定的」ではないように、コミットする（ステップ６３６）。
同様に、セッションマネージャーＡは支払いの成功を検出し（ステップ５９０、
５９４）、信託エージェントＡはコミットする（ステップ６３８）。取引はこれ
で完了する。

【０１２９】マネーモジュールの支払い成功後に、ホストＢは商業的支払いチケットを信託
エージェントＢから要求する。これに対して、チケット所持者ＢはＨＴＢに商業
的支払いチケットを送信する。ＨＴＢは、その後、チケット及び送金通知を未払
金システムに支払いの証拠として送信する。ＨＴＢは、同様に、いずれかの未払
い送り状及び期限の過ぎた通知を、セットアップ用に未払金システムに送信する
。

【０１３０】同様に、マネーモジュールによる支払い成功後に、ホストＡは商業的支払いチ
ケットを信託エージェントＡから要求する。これに対して、チケット所持者Ａは
商業的支払いチケットをＨＴＡに送信する。ＨＴＡは、その後、未払いの送り状
を一致させるために、チケット及び送金通知を売掛金システムに送信する。かか
る送り状の一致は取引中に実行可能でもある。ＨＴＡは呈示チケットを、呈示の
有効化のために、売掛金システムに送信もする（ステップ８８２−８８６）。

【０１３１】本明細書は本発明の好ましい実施例を図示して説明しているが、本発明は様々
な別の結合及び環境において使用可能であり、ここで明示されている発明の概念
の範囲内で変更又は変形が可能であることが理解されるであろう。

【図面の簡単な説明】

【図１】商人及び顧客信託装置の相互作用を示す図である。

【図２】図２Ａ及び図２Ｂは、送り状／期限を過ぎた通知及び送金通知に含ま
れるデータを示す。

【図３】呈示チケット及び商業的支払いチケットのセクション及びフィールド
を示す。

【図４】取引装置のコンポーネントを示す。

【図５】図５Ａ乃至図５Ｄは、信託エージェントの機能的なコンポーネントを
示す。

【図６】本発明のシステムのネットワーク構成を示す図である。

【図７】図７Ａはコミットプロトコルを示し、図７Ｂは中止プロトコルを示す
。

【図８】図８Ａ乃至図８Ｊは、要求払いによる呈示を示す。

【図９】図９Ａ乃至図９Ｅは、セッション設定プロトコルを示す。

【図１０】メッセージ送信プロトコルを示す。

【図１１】信用状チェックプロトコルを示す。

【図１２】取引中止プロトコルを示す。

【図１３】図１３Ａ乃至図１３Ｅは、マネーモジュール支払いプロトコルを示
す。

【図１４】信託エージェント及びマネーモジュール間で設定される様々なメッ
セージ暗号レイヤを示す。

【図１５】図１５Ａ乃至図１５Ｅは、マネーモジュール用のセッション設定プ
ロトコルを示す。

【図１６】発送メッセージ送信プロトコルを示す。

【図１７】ＭＭ／ＴＡメッセージ送信プロトコルを示す。

【図１８】ＴＡ／ＭＭメッセージ送信プロトコルを示す。

【図１９】図１９Ａ及び図１９Ｂは、マネーモジュール用の取引中止プロトコ
ルを示す。

【図２０】電子発送メッセージ送信プロトコルを示す。

【図２１】図２１Ａ及び図２１Ｂは、手形移転プロトコルを示す。

【図２２】マネーモジュール用のコミットプロトコルを示す。

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

Claims

【特許請求の範囲】

【請求項１】機密保持がなされた呈示及び支払いのためのシステムであっ
て、少なくとも一のデータプロセッサ、メモリ及び暗号手段を有する第１の電子処
理装置と、少なくとも一のデータプロセッサ、メモリ及び暗号手段を有する第２の電子処
理装置とを有し、前記第１の電子処理装置は格納された送り状データから呈示チケットを作成し
、前記呈示チケット及び前記送り状データを前記第２の電子処理装置に機密保持
よく送信し、前記第２の電子処理装置は、いずれの送り状が支払われるべきかを決定し、そ
れが前記第１の電子処理装置に機密保持よく送信する対応送金通知を作成し、前記第１の電子処理装置は前記送金通知に対応する商業的支払いチケットを作
成し、前記商業的支払いチケットを前記第２の電子処理装置に機密保持よく送信
し、前記第２の電子処理装置は、前記送信通知において特定されたものに対応する
金額の電子マネーを前記第１の電子処理装置に機密保持よく送信するシステム。
【請求項２】前記送り状データは少なくとも一の現在の送り状データ及び
／又は少なくとも一の期限の過ぎた通知データを含む請求項１記載のシステム。
【請求項３】前記送り状データは、自動送り状発送システムによって前記
第１の電子処理装置に与えられる請求項２記載のシステム。
【請求項４】ディジタル署名が前記送り状データから作成され、前記呈示
チケットに含まれる請求項１記載のシステム。
【請求項５】前記ディジタル署名はグループ署名である請求項４記載のシ
ステム。
【請求項６】前記第２の電子処理装置は、前記受信された呈示チケット及
び前記ディジタル署名を検証する請求項５記載のシステム。
【請求項７】前記第１及び第２の電子処理装置は、前記第２の電子処理装
置が前記呈示チケットを受信した後に、暫時ログ更新を実行する請求項１記載の
システム。
【請求項８】前記暫時ログ更新は前記送り状データに由来するデータを含
む取引データを記録する請求項７記載のシステム。
【請求項９】前記送り状データに由来する前記データは、前記呈示チケッ
ト内のデータである請求項８記載のシステム。
【請求項１０】前記第１及び第２の電子処理装置は、前記第２の電子処理
装置が前記電子マネーを前記第１の電子処理装置に送信した後で、最終ログ更新
を実行する請求項７記載のシステム。
【請求項１１】前記第２の処理装置は、自動未払金システムに対して前記
送り状データに示されたいずれかの送り状が既に支払われたかどうかをチェック
する要求を開始する請求項１記載のシステム。
【請求項１２】前記未払金システムは、前記送り状データに表示された送
り状に対応するそのデータベースにおいて送金データを識別し、前記対応する送
金データ及びその対応する商業的支払いチケットは前記第１の電子処理装置に有
効化のために送信される請求項１１記載のシステム。
【請求項１３】前記第２の電子処理装置はプログラムされた現金管理機能
にいずれの送り状が支払われるべきかを決定することを尋ねる請求項１記載のシ
ステム。
【請求項１４】前記第２の取引装置は、満額払いをするのに十分な電子マ
ネーがあるかどうかをチェックし、十分な資金が利用可能ではない場合には呈示
された送り状の小派を支払い用に選択する請求項１記載のシステム。
【請求項１５】前記選択はプログラムされた現金管理機能からの優先順位
情報に基づいている請求項１４記載のシステム。
【請求項１６】前記送金通知は、支払いが選択された送り状からのデータ
を含む請求項１記載のシステム。
【請求項１７】前記第１の電子処理装置は、前記送り状データへの比較に
よって前記送金通知を有効にする請求項１６記載のシステム。
【請求項１８】前記商業的支払いチケットは、前記送金通知から作成され
たディジタル署名を含む請求項１記載のシステム。
【請求項１９】前記商業的支払いチケット及び前記送金通知は、支払いの
証拠として自動未払金システムに送信される請求項１記載のシステム。
【請求項２０】前記商業的支払いチケット及び前記送金通知は、未払いの
送り状を一致させるために、自動売掛金システムに送信される請求項１９記載の
システム。
【請求項２１】未払いの送り状データは前記未払金システムにセットアッ
プのために送信される請求項２０のシステム。
【請求項２２】前記呈示チケットは、呈示の有効化のために、前記売掛金
システムに送信される請求項２１記載のシステム。
【請求項２３】機密保持のなされた呈示及び支払いのためのシステムであ
って、少なくとも一のプロセッサ及びメモリを有する第１のホストと、第１の信託エ
ージェントと、少なくとも一のプロセッサ及びメモリを有する第１のマネーモジ
ュールとを有する第１の電子取引装置と、少なくとも一のプロセッサ及びメモリを有する第２のホストと、第２の信託エ
ージェントと、少なくとも一のプロセッサ及びメモリを有する第２のマネーモジ
ュールとを有する第２の電子取引装置と、前記第１のホストは送り状データを前記第１の信託エージェントに送信し、前記第１の信託エージェントは前記送り状データに対応する呈示チケットを作
成し、前記呈示チケットを前記第２の信託エージェントに送信し、前記第２の信託エージェントは、前記呈示チケットを検証し、前記送り状デー
タに対応する送金通知を作成し、前記送金通知を前記第１の信託エージェントに
送信し、前記第１の信託エージェントは、前記送金通知を検証し、商業的支払いチケッ
トを作成し、前記商業的支払いチケットを前記第２の信託エージェントに送信し
、前記第２のマネーモジュールは、電子マネーを前記第１のマネーモジュールに
送信するシステム。
【請求項２４】前記第１及び第２の信託エージェント及び前記第１及び第
２のマネーモジュールは、各々マイクロプロセッサを有する別個の改ざん防止装
置に組み込まれる請求項２３記載のシステム。
【請求項２５】前記第１の信託エージェント及び前記第１のマネーモジュ
ールは、マイクロプロセッサを共有する単一の改ざん防止装置に組み込まれ、前
記第２の信託エージェント及び前記第２のマネーモジュールは、マイクロプロセ
ッサを共有する単一の改ざん防止装置に組み込まれる請求項２３記載のシステム
。
【請求項２６】前記第１及び第２の信託エージェント及び前記第１及び第
２のマネーモジュールは、暗号により機密保持のなされたセッションを介して交
信する請求項２５記載のシステム。
【請求項２７】機密保持のなされた呈示のための方法であって、商人処理装置が送り状データを受信する工程と、前記商人処理装置が前記送り状データに基づいて呈示チケットを作成し、前記
呈示チケットを顧客処理装置に機密保持よく送信する工程と、前記顧客処理装置が前記呈示チケットを検証していずれかの送り状が支払われ
るべきであるかどうかを決定する工程とを有する方法。
【請求項２８】前記顧客処理装置が前記決定工程の結果に基づいて送金通
知を作成し、前記送金通知を前記商人処理装置に機密保持よく送信する工程と、前記顧客処理装置が前記送金通知を有効にする工程とを更に有する請求項２７
記載の方法。
【請求項２９】前記商人処理装置が商業的支払いチケットを作成して前記
顧客処理装置に送信する工程と、前記顧客処理装置が前記商人処理装置に電子マネーを送信する工程とを更に有
する請求項２８記載の方法。