JP2003514316A

JP2003514316A - オンラインコマースのための支払方法及びシステム

Info

Publication number: JP2003514316A
Application number: JP2001537199A
Authority: JP
Inventors: グレッグ，イー．スミス，; レオ，アール．シュリンカート，
Original assignee: ネットチャージ．コム，インコーポレイテッド
Priority date: 1999-11-05
Filing date: 2000-11-06
Publication date: 2003-04-15
Also published as: WO2001035570A1; AU1584001A; AU775065B2; CA2390167A1

Abstract

(57)【要約】オンライン取引のために支払システムをつくる本発明の発明のシステムは、システム関係者及び中央取引管理システムのコンピュータのクライアントソフトウェアを通して実行される。各々のクライアントソフトウェア・コンポーネントは、他システム関係者のクライアントソフトウェア及び中央取引管理システムと相互に作用する。取引管理システムは、各々のパーティから取引まで取引要求を受け、各々のパーティから受けた情報を比較し、各々のパーティから受けられる取引情報が一致することを確実とし、取引をそれによって認証する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、インターネットを利用して取引を行うこと、さらに詳細には、処理
を行い、認証し、及びマーチャントの購入リクエストと一致させ、購入リクエス
トの取引完了を確認し、マーチャントへ購入パーティからのクレジット又はデビ
ット支払を実行する、取引管理システムを利用した支払システムに関する。

【０００２】

【背景技術】

インターネットアクセスの著しい増加及び使用は、ビジネス電子取引を行う新
しい方法という結果になった。代表的な電子商取引において、購入者は商品又は
サービスをマーチャントから購入し、マーチャントは、将来の顧客がインターネ
ットを利用してアクセスし、オーダし、マーチャントの商品及びサービスを受け
取り又は支払を行う確立された方法を有する。これらの取引は、現在、従来のク
レジットカード、デビット・カード、郵便為替又は船舶会社のキャッシュオンデ
リバリーサービスを使用して、実行されている。

【０００３】クレジットカード及びデビット・カードは、長年取引において使用されてきた
。代表的な従来のクレジットカード取引において、消費者は自分自身をマーチャ
ントの面前で自分のカードを示すことにより物理的に認証し、購入スリップに署
名することにより取引のタームに同意し、同時に購入した商品を物理的に受け取
る。マーチャントは、購入総額がカードの信用限度の範囲内であることを通常電
子的に確認することができる。

【０００４】取引の後、マーチャントは支払のために購入スリップを購入者の銀行（「獲得
銀行」）に届ける。提携例えばビザ又はマスタカードを使用して、獲得銀行は購
入スリップを、クレジットカードを発行し獲得銀行に信用貸しをしている銀行（
発行銀行）に届ける。購入スリップは、物理的に又は電子的に届けられてもよい
。

【０００５】発行銀行は、代表的には、命令を届け、取引を確認し、カード所有者から支払
を受信するためにグランドメールシステムを使用する。

【０００６】クレジット及びデビット・カードは、支払方式としてインターネット販売取引
で現在使用されている。しかし、オンライン取引で、顧客は物理的にカードを提
示することができず、購入スリップに署名すること及び商品の配達を受けること
もできない。クレジット及びデビット・カードは、好都合で信頼できる安全な支
払を提供するキー属性の多くを失う。この無能力の結果、発行銀行及びカード提
携会社は、マーチャントで面倒な料金及び高価な料金を戻す義務を課している。
これらは、カード所有者による詐欺及びカードアカウント番号の所有を得る窃盗
犯人にマーチャントを曝すことになる。

【０００７】その上、本人の身元、取引の完了の周囲における不確実性及び関連する一般的
なプライバシーが盗まれる危険のため、多くのユーザはインターネット上にアカ
ウント情報を伝送するのを望まない。

【０００８】さらに、少額決済取引のために、取引総額が小さい場合、売り手が取引の支払
方法として従来のカードを使用することは金銭的に実際的ではないかもしれない
。

【０００９】インターネットもまた、既存のクレジット及びキャッシュカードシステムに対
してマーチャント詐欺行為の重要な及び拡大する源を表す。これは部分的には、
限られた稼働の歴史によるマーチャントの急速な形成のためである。インターネ
ット取引の利点の１つは、インターネットが顧客及びマーチャントをたとえ二人
の個人でさえ取引において結びつけることができ、関係者は互いを知らず、将来
においても関係を有さないものである。しかし、これらの匿名の取引は、電子取
引の全ての関係者に取引の新しいタイプの危険を生成する。これらの匿名の取引
によって生み出される危険は、既存のデビット又はクレジットカードシステムに
よって言及することができない。

【００１０】インターネットに独特な他の危険は、インターネットを介して得られかつ配信
される例えばソフトウェア、ゲーム又は音楽ファイル等の知的財産である。この
ような知的財産は、知的財産の所有者の権利に違反して、事実上無制限なコピー
及び使用に曝される。現在の支払システムは、知的財産の購入者を知的財産の使
用者と結びつけることができる信頼できる方法又は手続ではなく、或いは購入者
が実際に対象となる知的財産の作業用コピーを受信したことを確かめる信頼でき
る方法でもない。知的財産の所有者又は許諾者は、購入者が購入された又は許諾
された知的財産を受信したことを確認することは困難かもしれないので、所有者
は、購入者による支払実施能力及び明白な窃盗から保護する能力を現在制限され
ている。

【００１１】他のセキュリティ問題は、クレジットカード及びデビット・カードの詐欺の可
能性である。物理的な取引と異なり、マーチャントはオンライン取引で購入者に
識別を要求することができない。有効なクレジットカードアカウント番号を獲得
する誰でも、購入をするために潜在的にそれを使用することができる。マーチャ
ントの詐欺の可能性もある。一旦マーチャントがクレジットカードアカウント番
号を有するならば、マーチャントは購入者に不当な要求をするか、支払を受信し
た後に注文される商品を届けないか、又はアカウント番号を他の者に与える潜在
的な誤用の可能性がある。その上、取引処理の間に、クレジット又はデビットカ
ード・アカウント番号及び他の個人情報が電子的に伝送される時、第三者による
妨害の危険がある。

【００１２】このような問題への現在の対応は、電子証明及び暗号を使用することである。
しかし、このような方法は一般に、カード所持者側についてのセキュリティ問題
だけを扱い、技術的な制約のために限られた効果を有するかもしれない。より重
大には、暗号化はメッセージが改変されていないことを確認することのみを手助
けし、メッセージの送り手を認証せず、オリジナルメッセージの正確さも保証し
ない。

【００１３】現在の支払システムで起こる他の問題は、「不本意な」取引の困難性及び費用
である。顧客が購入したアイテムを返却するとき、返却取引は通常オリジナルの
購入取引とは別個に取り扱われる。特に小規模の購入のために、通常マニュアル
で行われるこの付加的な処理は、非常に高価である。一部の場合において、商品
の返却は商品それ自体よりも多くコストが掛かるかもしれない。

【００１４】従って、インターネットを利用する好都合で安全かつ信頼できる取引を行う方
法のニーズがある。

【００１５】

【課題を解決するための手段】

本発明は、上記の状況を考慮して作成され、オンライン支払システムを生み出す
ことによって現在の支払システムの問題を解決するものである。本発明のオンラ
イン支払システムは、取引当事者の確実性を確認し、取引の詳細が正しいことを
認証し、商品及びサービスの配送における検証を容易にし、インターネット上で
ビジネスを行っている知的財産の所有者に増大された保護を提供し、個人情報の
悪用を防止し、クレジット又はデビット・カード情報を通してインターネット識
別の窃盗を防止し、取引におけるインターネットのコスト減少インパクトを強制
又は減少しない方法で、電子商取引を戻すコストを減少する。

【００１６】本発明の１つの目的は、取引で含まれる全ての当事者間で、照合し、認証し、
取引の全要素を確認する電子リアルタイム接続を使用するオンライン支払システ
ムを提供することであり、購入のために伝統的な物理的クレジット又はデビット
・カードの使用又はカードアカウント番号の伝達を要求しない。

【００１７】本発明の他の目的は、取引を確認し認証する取引管理システムを提供すること
であり、このシステムは、第１の取引当事者から取引のタームを受信し、第２の
取引当事者からの取引のタームを受信し、第１の取引当事者から受信されるター
ムと第２の取引当事者から受信したタームとを比較し、両タームが一致するかを
決定することを含む。

【００１８】本発明の他の目的は、マーチャントが電子取引の認証を得る方法を提供するこ
とであり、この方法は、購入者へ取引情報を提供し、購入者から取引別キーを受
信し、取引管理者へ取引別キーを伝送し、取引管理者から購入認証を受信するこ
とを含む。

【００１９】本発明の他の目的は、購入物の配送を確認する取引管理システムを提供するこ
とであり、このシステムは、取引当事者から配送のタームを受信し、配信エージ
ェントから配送の確認を受信し、取引当事者から受信した配送のタームを配送確
認と比較し、タームが一致するかどうかを決定することを含む。

【００２０】本発明の他の目的は、自分のクライアントソフトウェアを通して取引パーティ
を識別する方法を提供することである。

【００２１】本発明の付加的な目的及び利点は、一部は以下に記載され、一部はその記載か
ら明らかであり、或いは本発明の実施例により明らかとなってもよい。本発明の
目的及び利点は、特に添付の請求項により指摘された要素及び組み合わせによっ
て実現及び達成される。

【００２２】本発明の目的に従って、これら及び他の目的を達成するために、具体化されて
ここで広く記述されるように、本発明の１つの態様は、取引管理者によって複数
の取引パーティ間で電子取引を認証する方法を含む。この方法は、第１の取引パ
ーティから取引のタームを受信するステップと；第２の取引パーティから取引の
タームを受信するステップと；第１の取引パーティから受信した取引のタームと
第２の取引パーティから受信した取引のタームとを比較し、これらのタームが一
致するかどうかを決定するステップと；タームが一致する場合、取引を確認する
ステップとを含む。

【００２３】本発明の他の態様は、売り手が電子取引の認証を得る方法を含む。この方法は
、購入者に売り手識別子を含む取引情報を提供するステップと；購入者から取引
別キーを受信するステップと；取引管理者に取引別キーを伝送するステップと；
取引管理者から認証を受信するステップとを含む。

【００２４】本発明の他の態様は、取引管理者によって複数の取引参加者の間で電子取引を
認証する方法を含む。この方法は、取引管理者に第１の取引パーティによって取
引情報を提供するステップと；取引管理者による取引別キーを発生させ、取引管
理者から第１の取引パーティに取引別キーを提供するステップと；第１の取引パ
ーティから第２の取引パーティへの取引別キーを提供するステップと；確認のた
めに第２の取引パーティから取引管理者へ取引別キーを提供するステップと；取
引管理者によって取引を確認するステップとを含む。

【００２５】本発明の他の態様は、取引管理者によって複数の取引参加者の間で電子取引を
認証する方法を含む。この方法は、取引管理者に第１の取引パーティによって取
引情報を提供するステップと；取引管理者により取引別キーを発生させ、取引管
理者から第１の取引パーティに取引別キーを提供するステップと；第１の取引パ
ーティから第２の取引パーティへ取引別キーを提供するステップと；第２の取引
パーティから第１の取引パーティへ取引別キーを提供するステップと；確認のた
めに第１の取引パーティから取引管理者へ取引別キーを提供するステップと；取
引管理者によって取引を確認するステップとを含む。

【００２６】本発明の他の態様は、複数の取引パーティ間で商品の配送を認証する方法を含
む。この方法は、購入物の配送を確認するために取引管理システムを提供するス
テップと；取引パーティから配送のタームを受信するステップと；配送エージェ
ントから配送の確認を受信するステップと；取引パーティから受信した配送のタ
ームを配送確認と比較しタームが一致するかどうかを決定するステップとを含む
。

【００２７】本発明の他の態様は、複数の取引パーティ間で取引を認証する方法を含む。こ
の方法は、第１の取引パーティによって第２の取引パーティから取引を要求する
ステップと；第２の取引パーティによって取引管理者に取引情報を提供するステ
ップと；取引リクエストを確認するために第１の取引パーティを要求するステッ
プと；第１の取引パーティによって取引管理者に確認を提供するステップと；第
１の取引パーティのために確認を記憶された確認データと比較するステップと；
取引管理者によって取引を確認するステップとを含む。

【００２８】発明の他の態様は、複数の取引パーティ間で取引を認証する方法を含む。この
方法は、第２の取引パーティから第１の取引パーティによって取引を要求するス
テップと；第２の取引パーティから取引管理者へ取引情報を提供するステップと
；取引管理者によって第２の取引パーティに取引数を提供するステップと；第２
の取引パーティによって第１の取引パーティに取引数を通信するステップと；取
引管理者に接触する第１の取引パーティによって取引を確認し、取引数を通信す
るステップと；第１の取引パーティによって提供される確認と記憶された取引数
とを比較するステップと；取引管理者によって取引を確認するステップとを含む
。

【００２９】本発明の他の態様は、取引管理者でアカウントを各々有する購入者及び売り手
間の取引を戻す方法を含む。この方法は、売り手から返品取引を要求するステッ
プと；返品取引数を受信するステップと；配送エージェントへ商品を返品するス
テップと；配送エージェントによって返品商品を売り手に届けるステップと；購
入者の勘定を返金し、返品商品の売り手の受取りを取引管理者によってマーチャ
ントの勘定の借方に記入するステップとを含む。

【００３０】本発明の他の態様は、複数の取引パーティ間で電子購入を確認する方法及び知
的財産の配送を含む。ここで、第１の取引パーティは、取引管理者によって第２
の取引パーティからダウンロード可能な知的財産を購入することを要求する。こ
の方法は、取引管理者に取引情報を提供するステップと；取引管理者によって取
引別キー及び個人の配送キーを発生させて第１の取引パーティに提供するステッ
プと；第１の取引パーティから第２の取引パーティへ取引別キーを提供するステ
ップと；第２の取引パーティによって取引管理者に取引別キーを提供するステッ
プと；受信した取引別キーを発生した取引別キーと比較することによって取引を
確認するステップと；取引が確認された場合、公衆配送キーを第２の取引パーテ
ィに提供するステップと；個人の配送キーで暗号化される第１の取引パーティに
知的財産を提供するステップと；第１の取引パーティによって知的財産を解読す
るステップとを含む。

【００３１】前述の概要及び以下の詳細な記載は、例示であり単なる説明のみのためであり
、本発明を請求項に記載された発明に限定するものではないことを理解されたい
。

【００３２】

【発明の実施の形態】

添付の図面は本明細書に組み入れられてその一部を成すものであり、本発明の原
理を説明するために提供される記載と共に、本発明の実施の形態を示す。

【００３３】参照例は、本発明の発明（付随する図面で示される例）の例示的な実施形態で
詳細にされる。可能な場合はいつでも、同じ又は同様の構成部材を言及するため
に同じ参照番号が図面を通して使われる。

【００３４】インターネットの上の電子的取引の成長のための鍵となる問題は、プライバシ
ー侵害又はクレジット又はキャッシュカード詐欺の恐れのない、オーダ商品及び
サービスに有能な能力である。多くの暗号方式及び他の方法が、この問題に取り
組むために使われたが、これらの方法は、ある危険を低減するだけである。さら
に、それらは認証又はオリジナルのメッセージ有効性に取り組もうとしない。従
って、電子的取引は、窃盗又は詐欺にさらに弱い。

【００３５】本発明は、オンライン支払システムを作ることによって従来のカード・ベース
の電子的取引取引の問題を解決する。それは、従来の物理的なクレジット又はデ
ビット・カード、シグニチャー又はアカウント番号を使わない。本発明のシステ
ムは、システム関係者及び中央取引管理システムのコンピュータのクライアント
ソフトウェアを通して実行される。各々のクライアントソフトウェア・コンポー
ネントは、一以上の他のシステム関係者及び中央取引管理システムを有するクラ
イアントソフトウェアと相互に作用する。取引管理システムは、取引を受ける他
のパーティに取引を要求し、同時に情報比較し、互いから受けられる各々のパー
ティから受けられる取引情報が一致することを確実とし、それによって取引を認
証する。

【００３６】好ましくは、本発明のシステムによって扱われる代表的な取引で、取引への第
一のパーティは、買い手であり、取引への第二のパーティは、マーチャントであ
り、商品又はサービスをマーチャントから購入するという取引要求が買い手から
あり、取引管理システムと提携した金融機関を有する買い手のアカウントに購入
価格をチャージする。取引管理システムは、買い手が知っているように取引のタ
ームを、マーチャントが知っているように取引のタームと比較し、全てのターム
が一致することを確実とする。買い手・マーチャント取引でのタームは、買い手
の識別、マーチャントの識別、アイテム識別子、価格、量、支払機構及び配送イ
ンストラクションを含むかもしれない。買い手によって既知である取引のターム
がマーチャントによって既知のタームと一致する場合、取引管理システムは、取
引を認証するであろう。マーチャントが取引管理システムから認可を受けると、
彼は、買い手に購入された商品又は情報を配送又はダウンロードする。

【００３７】システムに関与するあらゆる取引パーティは、独特な個人の識別子を有する。
識別子は、彼のクライアントソフトウェアを通してパーティに譲渡される。取引
への実際のパーティは、彼のコンピュータのクライアントソフトウェアがシステ
ムに自動的にそのパーティを識別するので、彼の識別子が何であるか知っている
必要はありさえしない。識別子は、好ましくはクライアントソフトウェアで埋め
込まれ、ユーザに既知にされない。識別子が、認証マッチングプロセスで取引管
理者によって使われる。取引管理システムだけは、識別子を通してパーティが誰
であるかについてわかることができる。システム識別子が変更されることができ
ず、複製されることができず、盗まれることができないので、詐欺の危険性は実
際上排除される。追加のセキュリティは、個人の識別子とともにパスワード又は
ＰＩＮを用いてなしとげられてもよい。

【００３８】好ましい実施形態で、買い手が購入リクエストを作るとき、彼のコンピュータ
のクライアントソフトウェアは、マーチャントのシステムのクライアントソフト
ウェアに彼の一意の名前を送る。買い手の識別子は、マーチャントが後で起こる
認証マッチングの目的であることを「知っている」取引タームのうちの一つにな
る。マーチャントは実際に、買い手が誰であるかについて知らないが、むしろ、
マーチャントのシステムのクライアントソフトウェアはプロセスの一部として買
い手の識別子を受ける。マーチャントのシステムのクライアントソフトウェアは
、買い手にマーチャントの一意の名前を送り、買い手が買い手のクライアントソ
フトウェアを通して「知っている」取引のタームに加える。

【００３９】取引管理システムが取引タームを比較するとき、パーティ識別子を含むターム
の全てが一致する場合のみ、購入は承認される。タームの全てが一致するならば
、取引管理システムは、取引キーを生成して買い手に戻す。プロセスを完了する
ために、買い手はマーチャントに取引キーを伝える。マーチャントは、取引管理
システムへ取引別キーを伝えることによって購入の最終の認可を得る。ファース
トマッチを実行した時に生成されたものを有するマーチャントによって送り返さ
れた取引キーと一致することによって取引管理システムは、取引を確認する。マ
ーチャントは、彼が取引管理システムから認証確認を受けるまで購入された商品
を配送しないか、ダウンロードしないか、購入されたサービスを実行しない。

【００４０】このプロセスを通り抜けることによって、買い手が前記商品又はサービスを買
い、マーチャントがタームに同意しているという保証の高いレベルがある。一致
するプロセスは、取引ミスがないことを確実とし、従って、取引詐欺の可能性がほとんどない。

【００４１】マッチングは、商品又はサービスの販売と同様に商品又はサービスの配送に印
加されてもよい。配信エージェントを電子的に接続することによって、取引管理
者は、商品及びサービスの実際の配送を確かめることができる。

【００４２】電子的マッチング・ネットワークを用いて、本発明の発明のシステムは、個人
を含む全てのユーザが、買い手及び売り手として働くようにする。両方のパーテ
ィが電子的にネットワークにリンクされるので、どちらも買い手又は売り手とし
て働くことができる。これは、個人が売り手として機能する事を可能にし、個人
が個人電子回路取引ができるようにする。

【００４３】本発明のシステムで、クレジット又はデビットカード・アカウント番号は必要
でない。その代わりに、取引パーティは、取引管理システムに直接にリンクされ
る。アカウントは、買い手及びマーチャントが取引管理システムを登録するか、
登録する時確立される。システムは、各々のパーティのコンピュータでクライア
ントソフトウェアを通して取引パーティを識別する。

【００４４】本発明のシステムがクレジット又はデビット・カードに関して説明されるが、
本発明のシステムのコンセプトが様々及び適切に、投資情報サービス及びプロダ
クトの多くの種類に加えられ、結合されることが理解されなければならない。例
えば、デマンド・デポジット・アカウント、ダイレクト・デビット・アカウント
、ライン・オブ・クレジット、セキュリティ・アカウント、ミューチュアル・フ
ァンド・アカウント、及びストアド・バリュー・アカウントは本発明の発明のシ
ステムを、有利にも結合され又は引き立たせることができる。多くの種類のファ
イナンシャル取引（例えば分割払いローン、固定デビットアカウント又はリボル
ビングデビットアカウント）が、本発明のシステムによって実行されることがで
きる。

【００４５】本発明のシステムは、取引管理システムを実行し、インターネット等の公衆網
に購入リクエストを処理するようにする。提携された金融機関で働く取引管理者
（ＴＡ）は、情報センター、現金受け側及び／又はオンライン取引の実際のパー
ティへの支払人として働くであろう。ＴＡは、一つの取引パーティが知っている
取引のタームを、もう一つの取引パーティが知っている取引のタームと比較する
ことによって、取引を確認する。取引へのパーティは、買い手、マーチャント及
び配送者を含むかもしれない。ＴＡが実行する取引ターム・マッチングは、配送
取引と同様に販売に適用することができる。全てのタームが一致する場合だけ、
ＴＡは取引を確認する。

【００４６】マッチングプロセスは、実際上、取引及び決済のリスクを排除する。どちらの
パーティも、取引が始められなかったこと、又は配送が完了されなかったと主張
することができない。その上、販売及び配送のタームはＴＡによって明白に定め
られ、パーティの間で契約をそれによって画成する。

【００４７】本発明のシステムで、電子的取引へのパーティは、いかなる取引が起こる前に
、システムを登録するか書き入れる。登録プロセスは、システムへのパーティを
識別し、そのパーティがシステムに関与するのを可能にするための適切なソフト
ウェアを各々のパーティを提供する。図１Ａ−１Ｄは、各々のパーティに登録す
るプロセス及びシステムの好ましい４つのパーティの種類を図で示す。

【００４８】好ましい「マーチャント」は、インターネットによって商品又はサービスを売
っている構成である。本発明のシステムに関与するマーチャントのために、彼は
、システムの認可されたマーチャントにならなければならない。図１Ａにおける
ステップ１１０で示すように、オンライン・マーチャントは、システムに関与す
るか、システムに関与するよう頼まれることを要求することができる。マーチャ
ントが加わることに決めるならば、支払の形に彼がシステムを使うことに同意し
てＴＡと契約にサインする。契約は、マーチャントのために取引タームを明確に
し、ＶＩＳＡ又はマスタカードを受け入れるマーチャントと比較する。ＴＡは、
ステップ１１２でマーチャント・ソフトウェアを有する認可されたマーチャント
を提供する。このマーチャント・ソフトウェアは、アプリケーション・プログラ
ム・インタフェース（ＡＰＩ）及び用途を含むことができ、認可されたマーチャ
ントが、ステップ１１４で、システムで関与するために、そのウェブサイト及び
オーダ遂行システムに組み込まなければならない。ＡＰＩは、通常ＴＡと既存の
マーチャントソフトウェアプログラムとの通信を管理する。マーチャント・ソフ
トウェアは、電子的にマーチャントに伝えられることができ、又は、それはＣＤ
−ＲＯＭ又はその種の他のものによって伝達されることができる。マーチャント
・ソフトウェアは、好ましくは一意の名前を確立し、ステップ１６でＴＡにマー
チャントシステムを識別する。このマーチャントＩＤが、ＴＡにマーチャントを
識別するためにシステムを通して使われる。

【００４９】好ましい「発行銀行」は、連邦及び／又は州バンキング法を受けた金融機関で
あり、それは、それが働く管区において、消費者信用及びデマンド・デポジット
・アカウントを提供する許可を与えられる。すでにシステムに関与するどんな発
行銀行でも、リアルタイムでデビット及びクレジット取引を提供するためにイン
フラ及び技術を有する。

【００５０】図１Ｂのステップ１２０に示すように、金融機関は、システムに関与するか、
システムに関与するよう頼まれることを要求することができる。金融機関が関与
することに決めるならば、それは、ＴＡと「フランチャイズ」契約にサインする
ことができる。ＴＡは、ステップ１２２で、好ましくは発行銀行ソフトウェアを
金融機関に提供する。この発行銀号ソフトウェアは、ステップ１２４で、金融機
関がそのシステムに組み込むアプリケーション・プログラム・インタフェース（
ＡＰＩ）及びウェブ接続モジュールを含むことができる。このソフトウェアは、
電子的に金融機関に伝えられることができるか、或いはＣＤ−ＲＯＭ又はその種
の他のものによって伝達されることができる。ソフトウェアが組み込まれると、
金融機関はシステム内の発行銀号になる。

【００５１】好ましい「配送業者」は、配送会社又はサービスのいかなる種類でであっても
よい。本発明のシステムに関与する配送業者のために、彼は「関与配送者」にな
らなければならない。関与配送者は、システムのトラッキング・ソフトウェアを
利用して、オーダ配送確認サービスの一部としてパッケージ受け側から必要なシ
グニチャーを集める。図１Ｃにおけるステップ１３０に示すように、配送業者は
、システムに関与することを要求することができる、又は、システムに関与する
よう頼まれることができる。配送業者が関与することに決めるならば、彼はＴＡ
と契約にサインする。ＴＡは、ステップ１３２で配送業者に配送者ソフトウェア
を提供する。この配送者ソフトウェアは、ＡＰＩ及び適用を含むことができる。
配送業者は、システムで関与するために、ステップ１３４でそのシステムに組み
込む。このソフトウェアは電子的に配送業者に伝えられることができる、或いは
、それはＣＤ−ＲＯＭ又はその種の他のものによって伝達されることができる。
一旦配送業者が配送者ソフトウェアを組み込むならば、彼は関与配送者になる。

【００５２】好ましい「アカウント・ホルダ」は、発行銀号を有するクレジット／デビット
関係を確立する個人又は会社であることができる。アカウント・ホルダは、従業
員又はファミリーメンバの取引を管理するためにサブ・アカウントを準備するこ
とができる。サブ・アカウントは、購入指示書システムにリンクされることがで
きるか、認可しているパーティに電子メール承認通知を固定することができる。

【００５３】本発明の好ましいシステムでのアカウント・ホルダになるために、人又は構成
は、図１Ｄにおけるステップ１４０に示すように、システムに関与することを要
求しなければならない。アカウント・ホルダが関与することに決めるとき、彼は
使用のタームに同意してＴＡとの契約にサインする。ＴＡは、ステップ１４２で
アカウント・ホルダにアカウント・ホルダー・ソフトウェアを提供する。アカウ
ント・ホルダー・ソフトウェアは、一般的にインターネット・ブラウザ・プラグ
イン又はアプレットを含む。アカウント・ホルダは、ステップ１４４でアカウン
ト・ホルダー・ソフトウェアを取り付ける。このソフトウェアは電子的にアカウ
ント・ホルダに伝えられることができ、或いは、それはＣＤ−ＲＯＭ又はその種
の他のものによって伝達されることができる。

【００５４】アカウント・ホルダー・ソフトウェアは、ステップ１４６でＴＡにアカウント
・ホルダのコンピュータを識別するために一意の名前を作る。システムがアカウ
ント・ホルダを識別するのは、アカウント・ホルダー・ソフトウェアを通してあ
る。アカウント・ホルダー・クライアントソフトウェアを通して、コンピュータ
又は装置をユニークに識別するために使われることができる多くの方法がある。
識別子は、例えば、コンピュータのハードディスクの上で固定されたスポットを
通してＣＰＵの識別子を通して、又は、ソフトウェアで埋め込まれたシークレッ
ト・トークンを通して決定されることができる。アカウント・ホルダは、彼の識
別子を知らず、それを渡すことができない。取引管理システムは、さらにセキュ
リティを確実にするために定期的に新しいアカウント・ホルダ識別子を確立する
ことができる。追加のセキュリティは、アカウント・ホルダー・クライアントソ
フトウェアによって確立される個人的なＩＤとともにパスワード又は個人識別番
号（ＰＩＮ）を用いて達成されることができる。

【００５５】アカウント・ホルダー・ソフトウェアは、一般的に公的に利用できるインター
ネット・ブラウザ（例えばネットスケープナビゲータ及びマイクロソフト・エク
スプローラ）と働くブラウザ・プラグインである。加えて、ブラウザ・プラグイ
ンの代わりに、アカウント・ホルダー・ソフトウェアは、ハンドヘルドのワイヤ
レス装置（例えばＰａｌｍＯＳ、ＧｏＯＳ及びＭａｃＯＳ）のオペレーテ
ィングシステムと、又はデジタル無線電話と、働くように設計されるワイヤレス
・アプリケーションプロトコルであることができる。

【００５６】アカウント・ホルダー・クライアント・ソフトウェアは、クイックン及びマイ
クロソフトマネーにビルトインリンクを有することができ、それで、その取引情
報は、これらの用途に占められることができる。アカウント・ホルダー・クライ
アントソフトウェアで、アカウント・ホルダは、オンライン支払履歴などをチェ
ックすることができる。

【００５７】アカウント・ホルダー・クライアントソフトウェアは、また、カスタマイズさ
れることができ、合計、商品の種類又はマーチャントによって購入をブロック化
するようになっている。これは、ファミリーメンバ又は従業員のためにサブ・ア
カウントの設定を望むアカウント・ホルダのための重要な特徴である。

【００５８】本発明の関与しているエンティティーの間の好ましい関係を、図２で示し説明
する。マーチャント２９０は、認可されたマーチャントになるために、取引管理
者（ＴＡ）２５０と登録した、インターネットによって、商品又はサービスを売
っている構成である。システムに関与するために、マーチャント２９０はマーチ
ャント・ソフトウェアをその電子商取引ウェブサイト及びオーダ遂行システムに
組み込む。これは、マーチャントのウェブサイトから購入する場合に購入者が支
払の方法として本発明のシステムを選ぶことを可能にする。アカウント・ホルダ
２８０は、マーチャント２９０と好ましくは標準のマーチャント顧客関係を有し
、注文することは、マーチャント２９０から小売プロダクト及び／又はサービス
をオーダする。

【００５９】また、システムに関与するマーチャント銀行２２０で、各々の関与しているマ
ーチャント２９０は、好ましくはアカウントを確立する。マーチャント銀行２２
０は、有効なクレジット・イベントの受領時にマーチャント２９０に支払をする
役割を果たす。破線によって示されるように、ＴＡ２５０もマーチャント銀行
として働くことができる。マーチャントは、支払のための、電子的支払イベント
をＴＡ２５０又はマーチャント銀行２２０に提示することができる。

【００６０】好ましい実施形態で、マーチャント銀行２２０又はＴＡ２５０は、各々の発
行銀号２１０でアカウントを有する。マーチャント銀行２２０は、クレジット・
マーチャント・アカウントに規則的なベースでスィープする、ＴＡ２５０によ
って指示されるように支払を集め、又はＴＡ２５０はマーチャント銀行として
働くこともでき、及び、発行銀号２１０からマーチャント２９０まで支払を処理
する。

【００６１】好ましいアカウント・ホルダ配置、発行銀行２１０は、システムの登録したア
カウント・ホルダ２８０と、クレジット／デビット関係を確立する。発行銀号２
１０は、アカウントを確立しアカウント・ホルダ２８０にファンドアベイラビリ
ティーを提供する。発行銀号２１０は、従来のクレジットカード又はデビット・
カードを発行する銀行のように、アカウント・ホルダ２８０に命令を送り出す。

【００６２】ＴＡ２５０は、好ましくはマーチャントからアカウント・ホルダへのディス
カウントポイント、クーポン分配及びディスカウントの制御を維持する。ＴＡ
２５０は、発行銀号のためのアカウント・ホルダのためにソフトウェア及び技術
のためにカスタマーサービスを提供することができる。

【００６３】マーチャント２９０は、また、配送者２６０とのアカウントを確立することが
できる。好ましい実施形態で、アカウント・ホルダ２８０は、配送者２６０から
配送による購入商品を受ける。チャージオン配送取引で、アカウント・ホルダの
アカウントが商品のサイン／レシートにデビットされる。配送者２６０は、ＴＡ
２５０に必要情報を伝える。配送者２６０も、マーチャント２９０によるアカ
ウントを有する。

【００６４】ＴＡ２５０は、リアルタイム取引クリーニング・ユーティリティーを提供し、
発行バンク２１０からの現金受け側として働くか、或いは、マーチャント２９０
又はマーチャント・バンク２２０への支払い人は、マーチャント・バンクとして
機能する。

【００６５】本発明によるシステムのコンポーネントの高レベルで好ましい図を図３に示す
。図に見られるように、システムの全ての部分がそれぞれのクライアントコンポ
ーネントとインターネットを通じて通信できる。アカウント・ホルダ２８０は、
通常はＮｅｔｓｃａｐｅＮａｖｉｇａｔｏｒやＭｉｃｒｏｓｏｆｔＥｘｐｌ
ｏｒｅｒＢｒｏｗｓｅｒＰｌｕｇ−ｉｎ３８０のアカウントホルダークラ
イアントソフトウェアを通じて通信する。マーチャント２９０は、自身が有する
マーチャント取引システムを用いて、マーチャントクライアントソフトウェア３
９０を通じて通信し、マーチャントクライアントソフトウェアはオーソライズさ
れたマーチャントアプリケーションとＡＰＩとから構成されている。マーチャン
トクライアントソフトウェア３９０は、マーチャント自身の販売と注文のフルフ
ィルメントシステムと一体化されていてもよい。イシューイングバンク２１０は
、イシューイングバンクウェブ接続モジュールとＡＰＩとを含むイシューイング
バンクソフトウェア３１０を通じて通信する。マーチャントクライアントソフト
ウェアのように、イシューイングバンククライアントソフトウェアは、イシュー
イングバンクが有するシステムに一体化されている。シッパー２６０は、オーソ
ライズされたシッピングエージェントクライントソフトウェアを通じて通信し、
これはオーソライズされたシッパーアプリケーションＡＰＩを含んでもよい。最
後に、ＴＡ２５０はアカウント取引マネージメントアプリケーション３５０を通
じて通信する。アカウント取引マネージメントアプリケーション３５０は、取引
ターム・マッチングや、アカウント管理、注文フルフィルメント管理など、ＴＡ
機能のすべてを実行する。

【００６６】図３には示されていないが、取引のパーティは、インターネットやその他の公
衆ネットワーク上で、それぞれのソフトウェアコンポーネントを通じてシステム
と接続されている必要はない。様々なコネクションに見られるその他の通信モー
ドが考えられる。

【００６７】本発明のシステムの好ましい接続性が図４に示される。このシステムにおける
アカウント・ホルダの接続は、好ましくはセキュアドサーバーリンク（ＳＳＬｓ
）である。図に見られるように、アカウント・ホルダとマーチャントとの間の接
続４１０、アカウント・ホルダとイシューイングバンクとの間の接続４２０、ア
カウント・ホルダとＴＡとの間の接続４３０は、セキュアドサーバーリンクであ
る。イシューイングバンクとＴＡとの間の接続４５０、マーチャントとＴＡとの
間の接続４６０は、好ましくはバーチャルプライベートネットワークコネクショ
ン（ＶＰＮ）又はセキュアドシェルコネクション（ＳＳＣ）のいずれかである。

【００６８】本発明の基本的なプロセスは、図５に示される。ステップ５１０で、第１の取
引パーティがＴＡに取引情報を送信する。ステップ５３０で、第２の取引パーテ
ィがＴＡに取引情報を送信する。ステップ５５０で、ＴＡはこれらの取引情報パ
ケットを比較し、それらが一致するかどうか決定する。もし一致すれば、ステッ
プ５７０で、ＴＡは取引認可を返す。もし一致しなければ、開始させるリターン
を返すか、プロセスが終了する。

【００６９】図５に概略が示される基本的なプロセスは、多くの異なる方法論を通じて達成
し得る。２つの好ましい実施形態を図６及び図７に示す。

【００７０】本発明の好適な第１の実施形態は、図６Ａ及び図７Ａに描かれている。取引プ
ロセスはアカウント・ホルダ２８０から開始する。図７Ａに示されるように、ア
カウント・ホルダ２８０は、マーチャントのウェブサイト２９０にアクセスし、
商品の選択を行う。アカウント・ホルダ２８０は、支払方法として本発明のシス
テムを選択しているマーチャント２９０に購入要求７１１を送信する。例えば、
これは、アカウント・ホルダが電子的なショッピングカートを満たすか、或いは
マーチャントの「今、購入する」のオプションを選択したあとに起こる。通常、
購入要求には、ユニバーサルプライスコード（ＵＰＣｓ）、値段、数量などの情
報が含まれている。

【００７１】マーチャントのウェブサイト２９０では、クライアントソフトウェアは、まず
取引識別子（ＩＤ）を生成し、次にこの取引ＩＤをマーチャントＩＤ及び取引情
報７１２と共に、アカウント・ホルダのコンピュータ２８０上のクライアントソ
フトウェアに送信することによって、購入要求に応答する。取引ＩＤは、プロセ
スを通じてこの特定の取引を特定するために利用される。一の買い手と一のマー
チャントはある時間内でたくさんの取引を有するかもしれないので、この特定の
取引を特定するために取引ＩＤが必要となる。

【００７２】取引ＩＤとマーチャントＩＤを含む取引情報がアカウント・ホルダのコンピュ
ータに送信された後、アカウント・ホルダのコンピュータ上のアカウントホルダ
ークライアントソフトウェアはアカウント・ホルダのユニークなＩＤをその情報
に付加し、すべての情報７１３をＴＡ２５０に送信する。さらなるセキュリティ
のために、アカウント・ホルダＩＤは、残りの取引情報と共に送信される前に暗
号化されることとしてもよい。データパケット７１３でＴＡ２５０に送信された
情報は、アカウント・ホルダがそれを「知っている」として取引を定義する。実
際には、アカウント・ホルダではなく、アカウント・ホルダのコンピュータ上の
クライアントソフトウェアが取引の全てのタームを知っており、ソフトウェアの
ユーザはシステムで用いられているいかなるＩＤも決して見ることはない。アカ
ウント・ホルダＩＤはたった今送信されたので、マーチャントはいかなるアカウ
ント・ホルダ情報も有することはない。

【００７３】データパケット７１３を受信すると、ＴＡは、取引のアマウントのために、イ
シューイングバンク認可要求７２０を生成し、イシューイングバンク２１０に送
信する。イシューイングバンクシステム２１０上のクライアントソフトウェアは
、アカウント・ホルダＩＤを用いてアカウント・ホルダのアカウントにアクセス
し、アマウントの要求を認めるか拒否するかを決定する。イシューイングバンク
２１０はその後、取引認可コードをＴＡ２５０に送信する。もし、イシューイン
グバンク２１０が取引を認めれば、ＴＡ２５０は取引キー７３１を生成し、取引
ＩＤと共にアカウント・ホルダのコンピュータに送信する。

【００７４】取引キーを受信すると、アカウント・ホルダのコンピュータ２８０上のクライ
アントソフトウェアは、取引キーと取引ＩＤをデータバケット７３２でマーチャ
ント２９０に送信する。さらに、アカウント・ホルダはこのとき、配達方法指示
を促されることとしてもよい。配達情報もまた、データパケット７３２でマーチ
ャント２９０に引き渡される。マーチャントシステム２９０上のクライアントソ
フトウェアは、取引ＩＤ、取引キー、及び配達指示を含む取引情報をデータバケ
ット７３３でＴＡ２５０に送信する。

【００７５】その後、ＴＡ２５０はキーをマッチングし、マーチャント２９０によって送信
された情報と関連付ける。もし情報がマッチすれば、ＴＡ２５０は取引ＩＤ７７
０と共に認可コードをマーチャント２９０に送信する。さらに、ＴＡ２５０は請
求通知７８０をイシューイングバンク２１０に送信する。請求通知を受信すると
、イシューイングバンク２１０はアカウント・ホルダのアカウントから引き落と
し、ＴＡマスタアカウントに入金する。その後、単独であるいはＴＡと共に、マ
ーチャントバンクのマーチャントアカウントに入金される。

【００７６】最後に、マーチャント２９０はアカウント・ホルダ２８０に取引が完了したこ
とを確認し、商品を発送する。

【００７７】この実施形態のプロセスは図６Ａに示される。図５のステップ５１０は拡大さ
れ、サブステップ６１１、６１２、６１３を含む。ステップ６１１で、第１の取
引パーティが第２の取引パーティに取引要求を送信する。ステップ６１１は、図
７Ａのデータパケット７１１に対応し、ここで買い手はマーチャントからの購入
要求を作る。ステップ６１２で、第２のパーティは、自身の識別子を含む取引情
報を第１のパーティに送信する。ステップ６１２は、図７Ａのデータパケット７
１２に対応し、ここでマーチャントは、マーチャントＩＤ、取引ＩＤ、及び全て
の取引情報を買い手に送信する。ステップ６１３で、第１のパーティは、第２の
パーティから受信した、第２のパーティの識別子を含む全ての情報と、自身の識
別子とをＴＡに伝達する。ステップ６１３は図７Ａのデータパケット７１３に対
応し、ここでアカウント・ホルダのコンピュータ上のクライアントソフトウェア
は、アカウント・ホルダのプライベート識別子を暗号化し、マーチャントから受
信した取引情報と共にＴＡに送信する。

【００７８】サブステップ６１１、６１２及び６１３はステップ５１０に対応し、ここで第
１の取引パーティは、彼の知る取引タームをＴＡに送信する。この実施形態では
、第１の取引パーティは、具体的な購入情報、マーチャントＩＤ、アカウント・
ホルダＩＤの全てをＴＡに送信する買い手である。アカウント・ホルダのマシン
上のクライアントソフトウェアは、全ての伝達を管理する。アカウント・ホルダ
は、これら全ての情報を手動で送信する必要はなく、またクライアントソフトウ
ェアが何をしているか知っている必要はない。アカウント・ホルダは単にマーチ
ャントウェブサイトで購入要求を行えばよい。アカウント・ホルダのコンピュー
タ上のクライアントソフトウェアはマーチャントからの情報を受信し、アカウン
ト・ホルダＩＤを暗号化し、必要な情報をＴＡに送信する。

【００７９】図６Ａのステップ６２０は図７Ａのデータパケット７２０、７２１に対応する
。ステップ６２０で、ＴＡは、アカウント・ホルダのために特定の取引をアマウ
ントするため、イシューイングバンクからの取引認可要求を行い、イシューイン
グバンクの認可コードを受信する。もし取引が認可されれば、図６Ａのプロセス
はステップ６３１まで続けられる。

【００８０】図５のステップ５３０は拡大され、図６Ａのサブステップ６３１、６３２，６
３３を含む。ステップ６３１で、ＴＡは取引キーを生成し、取引ＩＤと共にアカ
ウント・ホルダのコンピュータのクライアントソフトウェアに送信する。ステッ
プ６１３は図７Ａのデータパケット７３１に対応する。ステップ６３２で、第１
のパーティは取引キーと取引ＩＤを第２のパーティに送信する。ステップ６３２
は図７Ａのデータパケット７３２に対応する。ステップ６３３で、第２のパーテ
ィは、取引キーを含む第１のパーティから受信した全ての取引情報をＴＡに伝達
する。ステップ６３３は図７Ａのデータパケット７３３に対応する。

【００８１】サブステップ６３１，６３２，６３３はいずれもシステムのユーザからは見え
ない。アカウント・ホルダやマーチャントのコンピュータ上のクライアントソフ
トウェアは、全ての必要な伝達を行う。サブステップ６３１，６３２，６３３は
ステップ５３０の結果と結びつく。

【００８２】ステップ５５０において、ＴＡはステップ６１３で第１のパーティから受信し
たすべての取引情報を、ステップ６３３で第２のパーティから受信した取引情報
と比較し、パーティ識別子やマッチ等を含む全てのタームを確認する。さらに、
ＴＡはステップ６３３で第２のパーティから受信した取引キーと、生成されてス
テップ６３１で第１のパーティに送信された取引キーを比較し、マッチするか確
認する。全てのタームがマッチした場合にのみ、ステップ５７０でＴＡは認可コ
ードを第２のパーティに送信する。

【００８３】より好ましい実施形態では、第２のパーティは取引キーなしで取引を完了する
ことができない。第２のパーティが取引キーを取得する唯一の方法は、第１のパ
ーティからである。これにより、第１のパーティはアカウントのオーソライズさ
れていない購入から保護される。

【００８４】本発明の好適な第２の実施形態は図６Ｂ及び図７Ｂに示されている。この実施
形態では、ＴＡへの全ての通信は一のパーティを通じて行われる。この実施形態
では、第１のパーティは同じステップ６１１，６１２，６１３を実行し、取引タ
ームをＴＡに伝達する。しかしながら、ＴＡは第２の取引パーティの取引ターム
はＴＡを通じてではなく第１のパーティを通じて受信する。

【００８５】図７Ｂに示されるように、取引プロセスはアカウント・ホルダ２８０がマーチ
ャントのウェブサイト２９０にアクセスすることにより開始され、購入選択を行
う。アカウント・ホルダ２８０は購入要求７１１を支払方法として本発明のシス
テムを選択しているマーチャント２９０に送信する。

【００８６】マーチャントウェブサイト２９０上のクライアントソフトウェアは、まず取引
識別子（ＩＤ）を生成し、次にこの取引ＩＤをマーチャントＩＤ及び取引情報７
１２と共に、アカウント・ホルダのコンピュータ２８０上のクライアントソフト
ウェアに送信することによって、購入要求に応答する。

【００８７】取引ＩＤ及びマーチャントＩＤを含む取引情報がアカウント・ホルダのコンピ
ュータに伝達された後、アカウント・ホルダのコンピュータ上のアカウントホル
ダークライアントソフトウェアは、アカウント・ホルダのユニークなＩＤを情報
に付加し、全ての情報７１３をＴＡ２５０に送信する。

【００８８】データパケット７１３を受信すると、ＴＡは、取引をアマウントするためのイ
シューイングバンク認可要求７２０を生成し、イシューイングバンク２１０に伝
達する。その後、イシューイングバンク２１０は、取引認可コード７２１をＴＡ
２５０に送信する。もし、イシューイングバンク２１０が取引を認可すると、Ｔ
Ａ２５０は取引キー７３１を取引ＩＤと共にアカウント・ホルダのコンピュータ
に送信する。

【００８９】取引キーを受信すると、アカウント・ホルダのコンピュータ２８０のクライア
ントソフトウェアは取引キーと取引ＩＤをデータパケット７３２でマーチャント
２９０に送信する。さらに、このときアカウント・ホルダは、配達方法指示を促
されることとしてもよい。配達情報もまた、データパケット７３２でマーチャン
ト２９０に引き渡される。マーチャントシステム２９０上のクライアントソフト
ウェアは、取引ＩＤ、取引キー、配達指示を含む取引情報をデータパケット７３
３で再度送信しアカウント・ホルダ２８０に戻す。そして、アカウント・ホルダ
のコンピュータ２８０上のクライアントソフトウェアは、この情報をデータパケ
ット７３４でＴＡ２５０に再度送信する。

【００９０】ＴＡ２５０は、キーをマッチングし、アカウント・ホルダ２８０から送信され
た情報と関連付ける。もし、情報がマッチすれば、ＴＡ２５０は取引認可コード
を取引ＩＤ７７０と共にアカウント・ホルダ２８０に伝達する。その後、アカウ
ント・ホルダのコンピュータ上のクライアントソフトウェアは、同じ情報をデー
タパケット７７１でマーチャント２９０に再度伝達する。

【００９１】さらに、ＴＡ２５０は請求通知をイシューイングバンク２１０に伝達する。請
求通知を受信すると、イシューイングバンク２１０はアカウント・ホルダのアカ
ウントから引き落とし、ＴＡのマスタアカウントに入金する。その後、単独であ
るいはＴＡと共に、マーチャントバンクのマーチャントアカウントに入金される
。

【００９２】最後に、マーチャント２９０はアカウント・ホルダ２８０に取引が完了したこ
とを確認し、商品を発送する。

【００９３】この実施形態のプロセスは図６Ｂに示される。図５のステップ５１０は拡大さ
れ、サブステップ６１１、６１２、６１３を含む。ステップ６１１で、第１の取
引パーティが第２の取引パーティに取引要求を送信する。ステップ６１１は、図
７Ｂのデータパケット７１１に対応し、ここで買い手はマーチャントからの購入
要求を作る。ステップ６１２で、第２のパーティは、自身の識別子を含む取引情
報を第１のパーティに送信する。ステップ６１２は、図７Ｂのデータパケット７
１２に対応し、ここでマーチャントは、マーチャントＩＤ、取引ＩＤ、及び全て
の取引情報を買い手に送信する。ステップ６１３で、第１のパーティは、第２の
パーティから受信した、第２のパーティの識別子を含む全ての情報と、自身の識
別子とをＴＡに伝達する。ステップ６１３は図７Ｂのデータパケット７１３に対
応し、ここでアカウント・ホルダのコンピュータ上のクライアントソフトウェア
は、アカウント・ホルダのプライベート識別子を暗号化し、マーチャントから受
信した取引情報と共に送信する。

【００９４】ステップ６１１，６１２，６１３が実行された後、第１のパーティの取引ター
ムをＴＡに送信することにより、ＴＡはステップ６２０で取引のためのクレジッ
ト認可を取得する。取引のための認可を受信した後、ＴＡは取引キーを生成し、
ステップ６３１で第２のパーティに送信する。ステップ６３２で第１のパーティ
は第２のパーティに取引キーを送信する。第２のパーティは、取引キーを伝達し
、ステップ６３５で取引情報を第１のパーティに伝達して戻す。第１のパーティ
は、ステップ６３６でＴＡに再度送信する。ステップ６３６、６３７は図７Ｂの
データパケット７３６，７３７に対応する。

【００９５】ＴＡは、ステップ６１３で受信した情報と比較するためにステップ６３６で受
信した情報を使い、全てのタームが一致することを確認するためにステップ６３
１で作成した取引キーを使う。全てのデータ項目が一致する場合は、ステップ６
７１で、ＴＡは第一パーティに承認コードを送る。その後、第一パーティは、ス
テップ６７１で、マーチャントに承認コードを送信する。ステップ６７０及び６
７１は、図７Ｂのデータパケット７７０及び７７１に相当する。

【００９６】第二の実施形態では、マーチャントはＴＡと直接的には通信しない。その代わ
り、マーチャントは、アカウント・ホルダを通してその取引情報の全てを送信す
る。この送信は、アカウント・ホルダのコンピュータにおいてはユーザに明らか
ではない。

【００９７】第一の実施形態では、ＴＡは第二パーティから取引キーを直接的に受信する。
第二の実施形態では、ＴＡは第一のパーティを通して取引キーを間接的に受信す
る。しかし、両実施形態において、第二パーティは、取引キーなしでは取引を完
了することができない。

【００９８】本発明のシステムの特徴は、アカウント・ホルダが、その機械又は装置であっ
てアカウントホルダークライアントソフトウェアがインストールされたものを使
う必要が無いことである。アカウント・ホルダが「リモート」コンピュータ又は
装置であってアカウントホルダークライアントソフトウェアがインストールされ
ていないものを使う場合には、その支払方法として、システムと一緒にそのアカ
ウントを使うよう要求することができる。

【００９９】図８には、リモート端末装置からされた購入についての取引プロセスが示して
ある。図５からのステップ５１０及び５３０は、リモート取引に必要なサブステ
ップを含むように拡大されてある。このタイプの取引では、アカウント・ホルダ
は、コンピュータ若しくは他の電子装置であってその「ホーム」コンピュータで
はないもの、又はアカウントホルダークライアントソフトウェアがインストール
されていないコンピュータを使っている。

【０１００】ステップ８１１に示してあるように、アカウント・ホルダは、このリモートコ
ンピューターのマーチャントウェブサイトを尋ねて購入リクエストをする。そし
て、支払方法として本発明のシステムを選択する。ステップ８１３では、マーチ
ャントクライアントソフトウェアが、マーチャントに購入リクエストを送るコン
ピュータに、マーチャントＩＤ及び取引情報を送る。数種類の通信故障があると
、コンピュータは応答しない。例えば、クライアントソフトウェアがインストー
ルされていないコンピュータをアカウント・ホルダが使っているとこのようなこ
とが起こる。このようにして、ステップ８１５では、マーチャントシステム上の
クライアントソフトウェアは応答を得ることなくステップ８１７に進む。マーチ
ャントクライアントソフトウェアが応答を得る場合には、標準的なオンライン取
引であり、図６からの方法のうちの１つが使われる。ステップ８１７で、マーチ
ャントクライアントソフトウェアは、アカウント・ホルダのリモートコンピュー
ター上のウェブページをリモート取引スクリーンに切り換えて、ステップ８１３
の場合のように、ＴＡのリモート取引サイトに同じ取引情報を送信する。

【０１０１】ＴＡはＳＳＬコネクションを介してアカウント・ホルダのリモートサーバーサ
イトに接続し、ステップ８３１では、ユーザに取引について確認することを要求
し、アカウントがセットアップされるときにアカウント・ホルダが入力したセキ
ュリティークエスションのうちの１つに答えるか、セキュリティークエスション
のうちの１つを尋ねるかを要求する。ステップ８３３でユーザは、セキュリティ
ークエスションに正確に答えるか、セキュリティークエスションを正確に尋ねる
かして、取引の確認をする。

【０１０２】ステップ８４０で、ＴＡは、当該アカウント・ホルダの発行銀行に取引総額に
ついてクレジット承認リクエストを送信する。発行銀行は、発行銀行承認コード
又は非承認コードをＴＡに送信することによって、リクエストされた総額を承認
又は非承認する。ＴＡは、アカウント・ホルダに対して、格納されたデリバリー
アドレスの１つを選択するよう、又はこの時点で新たなデリバリーアドレスを入
力するようリクエストすることもできる。

【０１０３】ステップ８３１及び８３３でアカウント・ホルダが取引の確認をした場合、タ
ームは、ステップ５５０の目的と「一致」する。その後、ＴＡは、ステップ８７
１でデリバリーインストラクションと共に取引承認コードをマーチャントに送る
。図示されてはいないが、ＴＡは借方通知を発行銀行に送信する。借方通知を受
けた後、発行銀行はアカウント・ホルダのアカウントに借方記入し、ＴＡのマス
タアカウントに貸方記入する。その後、マーチャント銀行のマーチャントアカウ
ントに貸方記入される。

【０１０４】この時点で、リモート取引サイトは、アカウント・ホルダを切り換えてマーチ
ャントサイトへ戻す。マーチャントサイトでは、取引が完了して発送されること
をマーチャントがアカウント・ホルダに確認する。ステップ８７３では、ＴＡは
、アカウント・ホルダに電子メールを送信し、アカウント・ホルダがリモート取
引を完了したという確認をリクエストする。確認は、２４時間以内にアカウント
・ホルダから受信されなければならない。そうでなければ、取引は取り消される
。アカウント・ホルダは、確認を電子メールでするか、又は無料番号に電話して
取引の確認をするためのセキュリティークエスションに答えてもよい。

【０１０５】また、本発明のシステムは、オフライン取引（例えば電話から始められるもの
）を扱うことができる。電話でされる購入のための取引方法は図９に示されてい
る。図５からのステップ５１０及び５３０は、このタイプの取引に好適なサブス
テップを含むように拡大されている。

【０１０６】ステップ９１１で示されるように、アカウント・ホルダは、支払方法としての
本発明のシステムについてマーチャント代表者に告げる。これは電話でされるの
が一般的である。しかし、マーチャント店において本人自身ですることもできる
。顧客（アカウントホルダー）からの購入リクエストに関する必要情報を集めた
後、ステップ９１３で、マーチャントは、マーチャントＩＤ、取引ＩＤ、顧客名
、ＵＰＣｓ価格、購入総額、及びＴＡへのデリバリーインストラクションを送信
する。ＴＡは、取引のために独特のオフライン取引ＩＤを作成して、ステップ９
２０で、マーチャントに送信する。ステップ９２２で、マーチャント電話又は店
内代表者は、取引を完了させるために、アカウント・ホルダにオフライン取引Ｉ
Ｄを知らせるか、好ましくは無料電話番号を知らせる。

【０１０７】ステップ９３１で、アカウント・ホルダは、無料番号に電話してオフライン取
引ＩＤを入力することが好ましい。アカウント・ホルダによる他の種類の通信を
考えることもできる。ＴＡはそのデータベースから取引を引き出し、音声発生技
術を使ってアカウント・ホルダに読み示す。アカウント・ホルダは、ステップ９
３３で、取引を受理又は却下する。受理した場合、ステップ９３５で、ＴＡは、
アカウント・ホルダの格納されたセキュリティークエスションからランダムに選
択するようアカウント・ホルダにプロンプトを出す。これらのクエスションは、
本発明のシステムにアカウント・ホルダ登録されたときにセットアップされたも
のである。その後、ＴＡは、セキュリティークエスションが正しく答えられてい
るかどうか決定するために音声変換技術に対するテキストを使うことができる。

【０１０８】先に記述された方法に従い、ステップ９４０で、ＴＡは取引総額について当該
アカウント・ホルダ用の発行銀行に、クレジット承認リクエストを送信する。発
行銀行の承認コード又は不承認コードをＴＡに送信することによってリクエスト
された総額を承認又は不承認する。アカウント・ホルダがステップ９３３及び９
３５で取引を確認すると、タームはステップ５５０の目的に「一致」する。その
後、ＴＡは、ステップ９７１で、取引承認コードをマーチャントに送ることがで
きる。図示されてはいないが、ＴＡは借方通知を発行銀行に送信する。借方通知
を受け取った後、発行銀行は、アカウント・ホルダのアカウントに借方記入し、
ＴＡのマスタアカウントに貸方記入をする。その後、マーチャント銀行のマーチ
ャントアカウントに貸方記入される。

【０１０９】本発明のシステムは、その注文確認及び納品サービスを通して不正を削減する
こともできる。アカウント保持者が購入選択を行い、システムが購入を確証した
後に、アカウント保持者は、自分の過去に記憶された納品住所（複数の場合があ
る）の１つを選ぶか、或いは新しい納品住所を入力してよい。例えば、図６Ａ及
び図７Ａに図示されている本発明の第１実施態様においては、これは、データパ
ケット７３２のステップ６３２の一部として実行できる。この納品情報が、デー
タパケット７３３の一部としてステップ６３３のＴＡに伝送されるトランザクシ
ョン情報の一部になる。ＴＡがステップ５５０で突き合わせを実行するとき、納
品情報は、トランザクションが有効であるかどうかを判断するために比較される
情報の一部である。

【０１１０】注文確認及び納品プロセスの情報の流れが図１０に示されている。売買業者２
９０が販売甘楽用確認通知７９０を（図７Ａと図７Ｂに図示されるような）アカ
ウント保持者２８０に送信した後、売買業者２９０は、納品指示１０１０ととも
に梱包された商品を出荷人２６０に転送する。それから、出荷人２６０は、デー
タパケット１０２０を通して売買業者に出荷人の梱包／出荷ＩＤを送達する。そ
れから、該売買業者は、データパケット１０３０として、出荷ＩＤ及び出荷日付
けとともにトランザクションＩＤをＴＡ２５０に送信する。

【０１１１】ＴＡ２５０は、定期的にその梱包監視事項一覧表を出荷人２６０に伝送し、ど
のパッケージ（ｏｎｅｓ）が署名を有さなければならないのか、及びそれがデー
タパケット１０４０で納品対支払（ＤＶＰ）出荷である場合には、誰からこのよ
うな署名が得られなければならないのかを示す。ＤＶＰ出荷は、写真識別、又は
親指の指紋の跡などのなんらかのその他の種類の物理的な認証、或いはそれ以外
の生物測定データを必要とする。

【０１１２】商品は、１０５０でアカウント保持者２８０の指定された納品住所に送達され
る。存在する場合は、必要とされる署名又は生物測定サンプルが、通常の再試行
手順に続いて得られる。それから、アカウント保持者２８０は、納品を受け入れ
、１０５５で必要とされるのであれば署名する。

【０１１３】出荷人２６０は、梱包変更ステータスをＴＡ２５０に伝送し、データパケット
１０６０で商品の受領を確認する。ＴＡ２５０は、ステータスの変更時に、デー
タパケット１０７０で売買業者２９０にトランザクションＩＤ及び受領書ステー
タスを伝送する。

【０１１４】トランザクションがＤＶＰである場合、売買業者の口座は、商品が納品され、
許可された署名が得られた旨の通知時に貸し方記入され、ＴＡ２５０は発行銀行
２１０に対し、データパケット１０８０でアカウント保持者の口座に借り方記入
するように通知する。

【０１１５】システムは、音楽、ニュース記事、及びソフトウェアなどの購入された知的財
産品目を処理することもできる。ネットワークリンク買い手、売り手及びトラン
ザクション管理者のこの使用が、知的財産データアイテムの安全な販売及び納品
に対処する。購入と納品が同じシステムにより管理されるため、知的財産の購入
と使用の間の連結は、これらの財産のより優れた管理を実現する。

【０１１６】ダウンロードされる知的財産は、すでにアカウント保持者クライアントソフト
ウェアがその上にインストールされているアカウント保持者のコンピュータに移
動する。従って、アカウント保持者クライアントソフトウェアは、あらゆるこの
ような購入され、ダウンロードされる知的財産を追跡調査することができる。こ
のリンクにより、売買業者は、誰が実際に彼らの知的財産をダウンロードしてい
るのか、知的財産がコピーされるかどうか、及び何回それがコピーされるか、或
いはプレイされるのかに関してさらに優れた理解を有することができる。

【０１１７】加えて、オンラインミューチュアルファンドなどの金融インスツルメンツが、
本発明のシステムを通して、購入、納品できる。システムは、個人対個人の送金
及び現金前貸しも処理できる。システムは、オンラインサービス用のパスワード
をアカウント保持者に安全に送達することもできる。

【０１１８】システムは、これらの種類の電子ファイル及び／又はパスワード送達を、公開
暗号化鍵及び秘密暗号化鍵を通して提供する。アカウント保持者は、つねにＴＡ
からの暗号化鍵の個人的な部分を受信する唯一の関係者である。売買業者及びそ
れ以外の第三者は、暗号化鍵の公開部分を受信してよい。この組み合わせが、ダ
ウンロードされるファイル及び／又はパスワードを盗難及び許可されていない使
用から保護する。

【０１１９】オンライン送達プロセスの情報の流れが図１１に示されている。図示されてい
るように、アカウント保持者２８０は、データパケット１１１１を通して電子送
達を行うことのできる知的財産品目に対する売買業者２９０からの購入要求を行
う。売買業者２９０は、データパケット１１１２で、売買業者ＩＤ、トランザク
ションＩＤ、製品説明（複数の場合がある）、価格情報、（日付け、時間、及び
方法を含む）納品情報を、アカウント保持者のコンピュータ２８０上のクライア
ントソフトウェアに伝送する。

【０１２０】アカウント保持者クライアントソフトウェア２８０は、パケット１１１２で受
信される情報に、アカウント保持者のシステム上に位置する暗号化されたアカウ
ント保持者の個人ＩＤを加えたものを、データパケット１１１３でＴＡ２５０に
伝送する。ＴＡ２５０は、データパケット１１２０で、購入の金額について、発
行銀行承認要求を発行銀行２１０に伝送する。発行銀行２１０は、承認／不認下
符号１１２１を通してトランザクションを承認する、或いは不認可とする。

【０１２１】クレジットが承認されると、ＴＡ２５０はトランザクションキー、トランザク
ションＩＤ、及びオンライン送達暗号化キーの個人部分をアカウント保持者のク
ライアントソフトウェア２８０に伝送する。アカウント保持者ソフトウェア２８
０は、データパケット１１３２でトランザクションキー及びトランザクションＩ
Ｄを伝送する。オンライン送達暗号化キーの個人的な部分は、それが電子的に送
達するときに、ファイル又は情報を複合するために使用されるだろう。個人暗号
化キーをこのように使用することにより、購入された電子商品又はサービスの送
達はさらに安全になる。

【０１２２】それから、売買業者２９０は、データパケット１１３３でトランザクションキ
ー、売買業者ＩＤ、トランザクションＩＤ及びトランザクション情報をＴＡ２５
０に伝送する。

【０１２３】ＴＡ２５０は、キー及び送達等に関する関連情報を突き合わせ、データパケッ
ト１１７０でトランザクション承認符号を、トランザクションＩＤ及びオンライ
ン送達暗号化キーの公開部分とともに売買業者２９０に送信する。

【０１２４】売買業者２９０は、情報／製品がオンライン送達暗号化キーの公開の半分を使
用して暗号化されるように、知的財産又はパスワードの安全なトランザクション
に従事するというオプションを利用できるようにしてよい。アカウント保持者２
８０が、ダウンロードされたファイルでアンパックコマンドを実行する、或いは
ダウンロードされたファイルが自動的にアンパックを実行すると、プログラムは
、トランザクションＩＤ及びトランザクションキーを使用することによって、ア
カウント保持者のクライアントソフトウェアから暗号化キーの個人の半分を検索
するだろう。それから、暗号化キーのこの個人部分は、ダウンロードされたファ
イル／パスワードを複合するために使用される。さらに、アンパックは、ダウン
ロードされた知的財産の送達及び使用を追跡調査するためにアカウント保持者の
クライアントにフラグをセットすることができる。

【０１２５】アカウント保持者クライアントソフトウェア２８０が送達されたファイルの複
合を完了すると、それは、データパケット１１７４で完了符号、トランザクショ
ンＩＤ及びオンライン送達暗号化キーの公開部分をＴＡ２５０に送信する。ＴＡ
２５０は、データパケット１１８０で発行銀行２１０に借り方通知を送信し、発
行銀行２１０はＴＡマスタ勘定に借り方記入する。それから、売買業者の銀行に
ある、又はＴＡとの売買業者のアカウントは、売買業者のシステムとの合意に従
って条件に基づいて（ｏｎｔｈｅｔｅｒｍｓ）借り方記入される。

【０１２６】本発明のシステムは、定期的な支払に使用されてもよい。この特徴は、例えば
、月々のＩＳＰサービス又は分割ローンの販売で使用されてよい。定期的な支払
購入についての情報の流れは図１２に示されている。データパケット１１３２は
、図１１に図示される実施態様についてと同じであり、ここでは合計購入価格よ
りむしろ定期的な価格が情報に含まれているだけである。

【０１２７】定期的な支払購入について、売買業者は、支払額を支払期間ごとに受領する。
図１２は、定期的な購入の各支払期間ごとに講じられる好ましいステップを描く
。データパケット１２４０では、売買業者２９０は、トランザクションキー、ト
ランザクションＩＤ、トランザクション情報及び定期的な価格をＴＡ２５０に伝
送する。データパケット１２４０の受信時、ＴＡ２５０は、キー及び納品等に関
する関連情報を突き合わせ、発行銀行に、データパケット１２４２で定期的な支
払に対する承認を要求する。発行銀行２１０は、要求される金額を承認する、或
いは不認可とし、発行銀行承認符号１２４４をＴＡ２５０に伝送する。発行銀行
２１０は、支払期間ごとにＴＡ２５０からこのような要求を受信し、承認するだ
ろう。対照的に、図１１に図示されるような完全価格トランザクションでは、完
全購入価格は一度だけ承認される。

【０１２８】定期支払が承認された後、発行銀行２１０は、アカウント保持者の口座に借り
方記入し、データパケット１２８０で売買業者の銀行との、又はＴＡとの売買業
者の口座を貸方記入する。

【０１２９】本発明の重要な特徴とは、容易にトランザクションを「解約する（ｕｎｗｉｎ
ｄ）」ことのできる能力である。現在のシステムでは、返却プロセスは手動で処
理されるため、きわめて高価である。買い手、売買業者、及び関連付けられる金
融機関を含むトランザクションのあらゆる関係者が手動で返却トランザクション
を処理しなければならないため、購入された商品の返却を処理するには最高＄２
５又は＄３０がかかる場合がある。インターネット上でマイクロトランザクショ
ンが成長するに伴ない、このコストは許容できなくなってきた。

【０１３０】しかしながら、本発明のシステムでは、ＴＡは、それを通して処理されるあら
ゆるトランザクションのデータのすべてを有している。加えて、トランザクショ
ンのあらゆる関係者は、電子的にＴＡにリンクされている。従って、ＴＡは、通
常の購入トランザクションと同じくらい容易に解約トランザクションを処理する
ことができる。

【０１３１】解約トランザクションの好ましい実施態様では、アカウント保持者は、返却番
号を要求するために売買業者のウェブサイトを訪問するだけで、本発明のシステ
ムを通して購入された製品を返却できる。それから、システムは、システムに関
与している出荷者に集荷の要求を送信することによってこの新しいトランザクシ
ョンを処理する。アカウント保持者は、返却商品を出荷者に与え、それはシステ
ムによって追跡調査される。売買業者はやがて返却商品を受け取る。ＴＡは、そ
れが返却商品の送達を追跡調査するにつれて、トランザクションをクリアし、ア
カウント保持者に貸方記入し、売買業者の口座に借り方記入する。なんらかの関
係者によるそれ以外の介入は必要とされない。

【０１３２】本発明のシステムは、外部との通信を行わずにトランザクションを完全に解約
できる。返却商品はシステムを通して購入されたため、ＴＡはすでに解約トラン
ザクションに必要な情報のすべてを有している。

【０１３３】解約は、本発明のシステムによって、アカウント保持者が売買業者に商品を納
品している関係者である通常のトランザクションとして処理されてよい。それは
、関係者を逆にしても通常のトランザクションのように処理できる。

【０１３４】発明は詳細にその特定の実施態様に関して説明されてきたが、その精神及び範
囲から逸脱することなく、多様な変更及び変型が加えられてよことが当業者に明
らかになるだろう。本発明が、本発明の変型及び変型を、それらが添付請求項及
びその同等物の範囲内であるならばカバーすることが意図される。

【図面の簡単な説明】

【図１】購入者、マーチャント、出荷エージェント及び発行銀行のための登録プロセス
を示す。

【図２】本発明における代表的な取引のために取引パーティの関係を示す。

【図３】本発明のシステムのソフトウェアコンポーネントを示す。

【図４】本発明のシステムの接続性を示す。

【図５】本発明のシステムの基本的な取引認証プロセスを示すフローチャートである。

【図６Ａ】取引認証プロセスの実施形態を示す。

【図６Ｂ】取引認証プロセスの実施形態を示す。

【図７Ａ】取引認証プロセスの実施形態のためのデータフローを示す。

【図７Ｂ】取引認証プロセスの実施形態のためのデータフローを示す。

【図８】遠隔終端からの認証のためのプロセスを示すフローチャートである。

【図９】電話からのオフライン取引のためのプロセスを示すフローチャートである。

【図１０】オーダデリバリ確認サービスプロセスを示す。

【図１１】オンラインデリバリープロセスを示す。

【図１２】周期的な支払プロセスを示す。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 17/60 ５１２Ｇ０６Ｆ 17/60 ５１２ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者シュリンカート，レオ，アール．アメリカ合衆国，コネチカット州，ダリエン，グッドワイヴズリヴァーロード 30

Claims

【特許請求の範囲】

【請求項１】複数の取引パーティ間で、電子取引を認証する方法であって
、前記方法は： (a)第１の取引パーティから取引のタームを受信するステップと； (b)第２の取引パーティからの取引のタームを受信するステップと； (c)第１の取引パーティから受信した取引のタームと、第２の取引パーティか
ら受信した取引のタームを比較して、タームが一致するかどうかを判定するステ
ップと； (d)タームが一致した場合に取引を確認するステップと、含む方法。
【請求項２】ステップ（ｄ）での確認の結果を取引パーティに戻す、更な
るステップを含む、請求項１記載の方法。
【請求項３】ステップ（ａ）が、第１の取引パーティからの取引のターム
を電子受信するステップを含む、請求項１記載の方法。
【請求項４】ステップ（ａ）が、第１の取引パーティのコンピュータシス
テム上のクライアントソフトウェアから取引のタームを電子受信するステップを
含む、請求項３記載の方法。
【請求項５】ステップ（ｂ）が、第２の取引パーティからの取引のターム
を電子受信するステップを含む、請求項１記載の方法。
【請求項６】ステップ（ｂ）が、第２の取引パーティのコンピュータシス
テム上のクライアントソフトウェアから取引のタームを電子受信するステップを
含む、請求項５記載の方法。
【請求項７】ステップ（ａ）で受信される取引のタームは、第１の取引
パーティの識別子と第２の取引パーティの識別子とを含む、請求項１記載の方法
。
【請求項８】ステップ（ｂ）で受信される取引のタームは、第１の取引パ
ーティの識別子と第２の取引パーティの識別子と取引キーとを含む、請求項１記
載の方法。
【請求項９】ステップ（ａ）が、取引のクレジット承認を得る更なるステッ
プを含む、請求項１記載の方法。
【請求項１０】ステップ（ａ）が、第１の取引パーティへの取引キーを生
成して送信する更なるステップを含む、請求項１記載の方法。
【請求項１１】ステップ（ｃ）で比較されるタームは、第１の取引パーテ
ィの識別子と第２の取引パーティの識別子とセールス情報とを含む、請求項１記
載の方法。
【請求項１２】第１の取引パーティは買い手であり、第２の取引パーティ
は売り手である、請求項１記載の方法。
【請求項１３】識別子は、取引パーティのコンピュータシステム上のクラ
イアントソフトウェアによって生成される、請求項１記載の方法。
【請求項１４】取引のタームはデリバリ情報を含む、請求項１記載の方法
。
【請求項１５】売り手が電子取引の認可を得る方法であって、前記方法は
：（ａ）買い手に売り手識別子を含む取引情報を提供するステップと；（ｂ）買い手から取引キーを受信するステップと；（ｃ）取引キーを取引管理者に送信するステップと；（ｄ）取引管理者から認可を受信するステップと、を含む方法。
【請求項１６】取引管理者によって複数の取引参加者間での電子取引を認
可する方法であって、前記方法は：（ａ）第１の取引パーティによる取引情報を取引管理者に提供するステッ
プと；（ｂ）取引管理者による取引キーを生成して、取引キーを取引管理者から
第１の取引パーティに提供するステップと；（ｃ）第１の取引パーティから第２の取引パーティに取引キーを提供する
ステップと；（ｄ）確認のために第２の取引パーティから取引管理者に取引キーを提供
するステップと；（ｅ）取引管理者によって取引を確認するステップと、を含む方法。
【請求項１７】ステップ（ｅ）での確認の結果を取引パーティに提供する
更なるステップを含む、請求項１６記載の方法。
【請求項１８】ステップ（ａ）が：（ｉ）第１の取引パーティが第２の取引パーティにトランザクション要求を
送るステップと；（ｉｉ）第２の取引パーティが、第１の取引パーティに取引情報と第２の取
引パーティ識別子とを送るステップと；（ｉｉｉ）第１の取引パーティが、取引管理者に、取引情報、第２の取引パ
ーティ識別子、及び第１の取引パーティ識別子を送るステップと、を含む、請求項１６記載の方法。
【請求項１９】ステップ（ｃ）が：（ｉ）取引管理者が第１の取引パーティに取引キーを送るステップと；（ｉｉ）第１の取引パーティが第２の取引パーティに取引キーを送るステ
ップと；（ｉｉｉ）第２の取引パーティが取引管理者に取引情報と取引キーを送る
ステップと、を含む、請求項１６記載の方法。
【請求項２０】ステップ（ａ）が、第１の取引パーティから取引管理者に
取引情報を電子送信するステップを含む、請求項１６記載の方法。
【請求項２１】ステップ（ａ）が、第１の取引パーティのコンピュータシ
ステム上のクライアントソフトウェアから取引管理者に取引情報を電子送信する
ステップを含む、請求項２０記載の方法。
【請求項２２】取引情報はセールス情報を含む、請求項１６記載の方法。
【請求項２３】取引情報はデリバリ情報を含む、請求項１６記載の方法。
【請求項２４】ステップ（ａ）での取引情報は、各取引パーティの識別子
を含む、請求項１６記載の方法。
【請求項２５】識別子は、各取引パーティのコンピュータシステム上のク
ライアントソフトウェアによって生成される、請求項２４記載の方法。
【請求項２６】ステップ（ｂ）での取引キー生成ステップは、パーティ識
別子をマッチさせるステップを含む、請求項１６記載の方法。
【請求項２７】ステップ（ｅ）は、ステップ（ｄ）で受信された取引キー
とステップ（ｂ）で生成された取引キーとを突き合わせるステップを含む、請求
項１６記載の方法。
【請求項２８】ステップ（ａ）の取引情報は個人識別番号を含み、ステッ
プ（ｅ）はステップ（ａ）からの個人識別番号と格納されている個人識別番号と
を突き合わせるステップを含む、請求項１６記載の方法。
【請求項２９】ステップ（ｂ）が、取引のクレジット承認を得る更なるス
テップを含む、請求項１６記載の方法。
【請求項３０】複数の取引参加者間での電子取引を取引管理者によって認
可する方法であって、前記方法は：（ａ）第１の取引パーティによる取引情報を取引管理者に提供するステップと
；（ｂ）取引管理者による取引キーを生成して、取引キーを取引管理者から第１
の取引パーティに提供するステップと；（ｃ）第１の取引パーティから第２の取引パーティに取引キーを提供するステ
ップと；（ｄ）第２の取引パーティから第１の取引パーティに取引キーを提供するステ
ップと；（ｅ）確認のために第１の取引パーティから取引管理者に取引キーを提供する
ステップと；（ｆ）取引管理者によって取引を確認するステップと、を含む方法。
【請求項３１】複数の取引パーティ間での商品のデリバリを認証する方法
であって、前記方法は：（ａ）購入のデリバリを確認する取引管理システムを提供するステップと；（ｂ）取引パーティからのデリバリのタームを受信するステップと；（ｃ）配信エージェントからのデリバリの確認を受信するステップと；（ｄ）取引パーティから受信されたデリバリのタームとデリバリ確認とを比較
して、タームが一致するかどうかを判定するステップと、を含む方法。
【請求項３２】複数の取引パーティ間での取引を認証する方法であって、
前記方法は：（ａ）第１の取引パーティを介して第２の取引パーティから取引を要求するス
テップと；（ｂ）取引情報を第２の取引パーティを介して取引管理者に提供するステップ
と；（ｃ）トランザクション要求を確認することを第１の取引パーティに要求する
ステップと；（ｄ）確認を第１の取引パーティを介して取引管理者に提供するステップと；（ｅ）確認と第１の取引パーティ用に格納されている確認データとを比較する
ステップと；（ｆ）取引管理者によって取引を確認するステップと、を含む方法。
【請求項３３】複数の取引パーティ間での取引を認証する方法であって、
前記方法は：（ａ）第２の取引パーティから第１の取引パーティを介して取引を要求するス
テップと；（ｂ）第２の取引パーティから取引管理者に取引情報を提供するステップと；（ｃ）取引管理者を介して第２の取引パーティに取引ナンバーを提供するステ
ップと；（ｄ）第２の取引パーティを介して第１の取引パーティに取引ナンバーを伝達
するステップと；（ｅ）取引管理者と交信している第１の取引パーティによる取引を確認して、
取引ナンバーを伝達するステップと；（ｆ）第１の取引パーティによって提供される確認と格納されている取引ナン
バーとを比較するステップと；（ｇ）取引管理者による取引を確認するステップと、を含む方法。
【請求項３４】買い手と売り手間での取引をほどく方法であって、各々が
取引管理者とのアカウントを有している、前記方法は：（ａ）売り手からリターン取引を要求するステップと；（ｂ）リターン取引ナンバーを受信するステップと；（ｃ）配信エージェン
トに商品を戻すステップと；（ｄ）配信エージェントによって売り手にリターン商品をデリバリするステップ
と；（ｅ）売り手がリターン商品を受け取ると取引管理者によって買い手のアカウ
ントがクレジットされ、マーチャントのアカウントがデビットされるステップと
、を含む方法。
【請求項３５】複数の取引パーティー間での知的財産の電子購入およびデ
リバリを確認する方法であって、第１の取引パーティが取引管理者を介して第２
の取引パーティからのダウンロード可能な知的財産を購入することを要求する、
前記方法は：（ａ）取引管理者に取引情報を提供するステップと；（ｂ）取引キーと個人デリバリキーを生成し、取引管理者を介して第１の取引
パーティに提供するステップと；（ｃ）第１の取引パーティから第２の取引パーティに取引キーを提供するステ
ップと；（ｄ）第２の取引パーティを介して取引管理者に取引キーを提供するステッ
プと；（ｅ）受信された取引キーと生成された取引キーとを比較することによって、
取引を確認するステップと；（ｆ）取引が確認された場合に、パブリックデリバリキーを第２の取引パーテ
ィに提供するステップと；（ｇ）個人デリバリキーで暗号化して、第１の取引パーティに知的財産を提
供するステップと；（ｈ）第１の取引パーティによって知的財産を解読するステップと、を含む方法。