(57)【要約】安全な電子為替手形を介した支払を含む電子取引を実行する方法は、為替手形の表示を含む安全なコンピュータサイトを開設するステップを含み、サイトは金融サービスプロバイダによって管理され、認証された取引の当事者のみにアクセス可能であり（１Ｂ)、前記方法はさらに、為替手形の振出人へ連結され、予め定められた条件を含む第１のオンライン信用状を作成するステップを含み、条件の充足は、金融サービスプロバイダが振出人へクレジットを供与する前提条件であり（７）、前記方法はさらに、コンピュータサイトに表示された為替手形へのアクセスを要請する為替手形の各当事者を認証するステップと、為替手形の名宛人へ為替手形に対する支払を発出するステップとを含む。発出された支払の少なくとも一部は振出人へ供与されたクレジットから生じてもよい（９）。オンライン契約履行保証は、違反した当事者により支払われるべき清算損害額を規定してもよい（１０）。オンライン信用状は、さまざまな場合におけるさまざまな種類の信用状、契約履行保証、および保険を含む商取引金融商品すべてをモデル化するための基礎となってもよい。
2004531813.tif 000002
【特許請求の範囲】
【請求項１】
安全な電子為替手形を介した支払を含む電子取引を実行する、コンピュータにより実施される方法であって、
為替手形の表示を含む安全なコンピュータサイトを開設するステップを含み、サイトは金融サービスプロバイダによって管理され、認証された取引の当事者のみにアクセス可能であり、前記方法はさらに、
為替手形の振出人へ連結され、予め定められた条件を含む第１のオンライン信用状を作成するステップを含み、条件の充足は、金融サービスプロバイダが振出人へクレジットを供与する前提条件であり、前記方法はさらに、
安全なコンピュータサイトへのアクセスを求める為替手形の各当事者を、金融サービスプロバイダが満足するように認証するステップと、
為替手形の名宛人へ為替手形に対する支払を発出するステップとを含み、発出された支払の自由選択の部分は振出人に供与されたクレジットから生じる、方法。
【請求項２】
為替手形に対する支払は、付帯事項の抹消を条件としており、安全なコンピュータサイトは、付帯事項の説明を提供し、付帯事項の抹消を可能にするよう構成されており、発出するステップは、付帯事項が付帯事項を抹消するよう認可されている認証された当事者によって適時に抹消されたときのみ実行される、請求項１に記載の方法。
【請求項３】
付帯事項は、商品の出荷、商品出荷の約束、サービスの履行、サービス履行の約束、出荷期日制限、履行期日制限、および商品の検査のうちの少なくとも１つを含む、請求項２に記載の方法。
【請求項４】
金融サービスプロバイダはＦＳＰを含む、請求項１に記載の方法。
【請求項５】
発出するステップは、金融サービスプロバイダに預けられた振出人の資金を仮差押えするステップを含み、仮差押えされた資金は少なくとも為替手形に対する支払の一部と等しい、請求項１に記載の方法。
【請求項６】
第１の信用状は取消可能および取消不能のうちの一方である、請求項１に記載の方法。
【請求項７】
第１の信用状は予め定められた期間の間有効である、請求項１に記載の方法。
【請求項８】
金融サービスプロバイダは、為替手形の振出人に、オンライン信用状の開設についての手数料を請求するステップをさらに実行する、請求項１に記載の方法。
【請求項９】
金融サービスプロバイダに預けられた振出人の資金から手数料を引き落とすステップをさらに含む、請求項１に記載の方法。
【請求項１０】
第１の信用状は、為替手形に対する支払を発出するのに十分な資金があるかどうかを判断する目的のためだけに、金融サービスプロバイダに預けられた振出人の資金の価値を高める、請求項１に記載の方法。
【請求項１１】
第１の信用状は単一の電子取引および多数の電子取引のうちの一方について有効である、請求項１に記載の方法。
【請求項１２】
発出された支払と引換えに、受取られた商品の担保権を金融サービスプロバイダに与えるステップをさらに含む、請求項１に記載の方法。
【請求項１３】
コンピュータサイトは、為替手形の振出人に、第１の信用状の現状の会計への安全なアクセスを提供するよう構成されている、請求項１に記載の方法。
【請求項１４】
安全なコンピュータサイトは、第１の信用状の存在およびそれへのアクセスを、為替手形の名宛人から保護するよう構成されている、請求項１に記載の方法。
【請求項１５】
為替手形の名宛人へ連結された第１のオンライン契約履行保証を作成するステップをさらに含み、第１の契約履行保証は、名宛人が電子取引の条件に従って履行しなかった場合に、第１の清算損害額を為替手形の振出人へ発出する、請求項１に記載の方法。
【請求項１６】
名宛人が電子取引の条件に従って履行するまで、または履行を免除されるまで、第１の清算損害額を名宛人の口座から仮差押えするステップをさらに含む、請求項１５に記載の方法。
【請求項１７】
名宛人へ連結された第２のオンライン信用状を作成するステップをさらに含み、名宛人が利用可能な資金が第１の清算損害額の支払を振出人へ発出するには不十分である場合、第１の清算損害額の少なくとも一部は第２のオンライン信用状から生じる、請求項１５に記載の方法。
【請求項１８】
為替手形の振出人へ連結された第２のオンライン契約履行保証を作成するステップをさらに含み、第２のオンライン契約履行保証は、振出人が電子取引の条件に従って履行しなかった場合に、第２の清算損害額を為替手形の名宛人へ発出する、請求項１に記載の方法。
【請求項１９】
振出人が電子取引の条件に従って履行するまで、または履行を免除されるまで、第２の清算損害額を振出人の口座から仮差押えするステップをさらに含む、請求項１８に記載の方法。
【請求項２０】
金融サービスプロバイダに預けている振出人の資金が第２の清算損害額の発出をカバーするには不十分である場合、第２の清算損害額の少なくとも一部は振出人に供与されたクレジットから生じる、請求項１８に記載の方法。
【請求項２１】
安全なコンピュータサイトは、電子取引の条件を規定する少なくとも１つの文書の表示をさらに含む、請求項１に記載の方法。
【請求項２２】
少なくとも１つの文書は、認証された取引の当事者のみにアクセス可能である、請求項２１に記載の方法。
【請求項２３】
少なくとも１つの文書の改訂案は、改訂付帯事項、改訂案の承認を構成する認証された当事者によるその適時の抹消を含む、請求項２１に記載の方法。
【請求項２４】
安全な電子為替手形を介した支払を含む電子取引を実行する、コンピュータにより実施される方法であって、
為替手形の表示を含む安全なコンピュータサイトを開設するステップを含み、サイトは金融サービスプロバイダによって管理され、認証された取引の当事者のみにアクセス可能であり、前記方法はさらに、
第１のオンライン契約履行保証を作成するステップを含み、第１のオンライン契約履行保証は、名宛人の不履行時に為替手形の振出人へ支払われるべき第１の清算損害額、および振出人の不履行時に為替手形の名宛人へ支払われるべき第２の清算損害額のうちの一方を規定し、前記方法はさらに、
安全なコンピュータサイトへのアクセスを要請する為替手形の各当事者を、金融サービスプロバイダが満足するように認証するステップと、
振出人および名宛人の双方が履行した場合に、為替手形に対する支払を為替手形の名宛人へ発出するステップ、
名宛人の不履行時、または第１の事象の発生時に、第１の清算損害額を振出人へ支払うステップ、および
振出人の不履行時、または第２の事象の発生時に、第２の清算損害額を名宛人へ支払うステップのうちの１つを実行するステップとを含む、方法。
【請求項２５】
為替手形に対する支払は、付帯事項の抹消を条件としており、安全なコンピュータサイトは、付帯事項の説明を提供し、付帯事項の抹消を可能にするよう構成されており、発出するステップは、付帯事項が付帯事項を抹消するよう認可されている認証された当事者によって適時に抹消されたときのみ実行される、請求項２４に記載の方法。
【請求項２６】
付帯事項は、商品の出荷、商品出荷の約束、サービスの履行およびサービス履行の約束、出荷期日制限、履行期日制限、および商品の検査のうちの少なくとも１つを含む、請求項２４に記載の方法。
【請求項２７】
金融サービスプロバイダはＦＳＰを含む、請求項２４に記載の方法。
【請求項２８】
金融サービスプロバイダに預けられた振出人の資金を仮差押えするステップをさらに含み、仮差押えされた資金は少なくとも為替手形に対して発出されるべき支払の一部と等しい、請求項２４に記載の方法。
【請求項２９】
仮差押えするステップは、少なくとも第２の清算損害額と等しい振出人の資金を仮差押えする、請求項２８に記載の方法。
【請求項３０】
名宛人の資金を仮差押えするステップをさらに含み、仮差押えされた資金は少なくとも第１の清算損害額と等しい、請求項２４に記載の方法。
【請求項３１】
為替手形の振出人へ連結され、第１の予め定められた条件を含む第１の信用状を作成するステップをさらに含み、第１の予め定められた条件の充足は、金融サービスプロバイダが振出人へクレジットを供与する前提条件であり、前記方法はさらに、
金融サービスプロバイダに預けている振出人の資金が、為替手形に対する支払、または第２の清算損害額の支払をカバーするには不十分である場合、名宛人へ発出される支払の少なくとも一部を、振出人へ供与されたクレジットから引出すステップを含む、請求項２４に記載の方法。
【請求項３２】
第１の信用状は予め定められた期間の間有効である、請求項３１に記載の方法。
【請求項３３】
金融サービスプロバイダは、為替手形の振出人に、オンライン信用状の開設についての手数料を請求する、請求項３１に記載の方法。
【請求項３４】
手数料は、金融サービスプロバイダに預けられた振出人の資金から引き落とされる、請求項３２に記載の方法。
【請求項３５】
第１の信用状は、振出人の不履行時に第２の清算損害額を支払う目的のため、または為替手形に対する支払を発出するのに十分な資金があるかどうかを判断する目的のためだけに、金融サービスプロバイダに預けられた振出人の資金の価値を高める、請求項３１に記載の方法。
【請求項３６】
第１の信用状は１つの電子取引および多数の電子取引のうちの一方について有効である、請求項３１に記載の方法。
【請求項３７】
コンピュータサイトは、為替手形の振出人に、第１の契約履行保証および第１の信用状の現状の会計への安全なアクセスを提供するよう構成されている、請求項２４に記載の方法。
【請求項３８】
安全なコンピュータサイトは、第１の信用状の存在およびそれへのアクセスを、為替手形の名宛人から保護するよう構成されている、請求項２４に記載の方法。
【請求項３９】
為替手形の名宛人へ連結され、第２の予め定められた条件を含む第２の信用状を作成するステップをさらに含み、第２の予め定められた条件の充足は、クレジットが名宛人へ供与される前提条件であり、前記方法はさらに、
名宛人の資金が第１の清算損害額の支払をカバーするには不十分である場合、名宛人へ発出される支払の少なくとも一部を、名宛人へ供与されたクレジットから引出すステップを含む、請求項２４に記載の方法。
【請求項４０】
安全なコンピュータサイトは、電子取引の条件を規定する少なくとも１つの文書の表示をさらに含む、請求項２４に記載の方法。
【請求項４１】
少なくとも１つの文書は、認証された取引の当事者のみにアクセス可能である、請求項４０に記載の方法。
【請求項４２】
少なくとも１つの文書の改訂案は、改訂付帯事項、改訂案の承認を構成する認証された当事者によるその適時の抹消を含む、請求項４０に記載の方法。
【請求項４３】
第１および第２の事象の少なくとも１つは電子取引の条件において規定される、請求項２４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の背景
１．  発明の分野
この発明は電子商取引（以下「ｅコマース」）の分野に関する。より特定的には、この発明は、安全な電子銀行為替手形を介した付帯事項依存の（contingency-dependent）支払を含む、ディレクトリにより認証される電子取引のための方法およびシステムに関する。
【背景技術】
【０００２】
２．  関連技術の説明
インターネットとして一般に知られる、当初は軍事用および学術用通信ツールとして開発されたコンピュータおよびネットワークのネットワークは、今では世界的な通信媒体へと成熟した。インターネットの爆発的な成長は、それへの高帯域幅アクセスがますます至るところで利用可能となるのに合わせて、この媒体を商用に適合させる取組みに拍車をかけてきた。ワールドワイドウェブ（以下「ウェブ」）、および「ブラウザ」として知られるウェブをナビゲートするためのソフトウェアツールの双方の発展は、インターネット上での商品およびサービスの売買の好評な受入れを促進するのに貢献してきた。現在、ウェブ上で商品および／またはサービスを購入したい人（以下「ウェブ買手」）はまず、検索エンジンまたはポータルを通常用いて、対象商人（以下「ウェブ売手」）のユニバーサルリソースロケータ（Universal Resource Locator）（以下「ＵＲＬ」）を見つけなければならない。また、これに代えて、ユーザは売手のＵＲＬを広告から知ったり、または情報源が何であれ、そこから得たＵＲＬを記憶させて、ポータルまたは検索エンジンを通さずに直接売手のサイトを訪れてもよい。その後、ウェブ買手は自分のウェブブラウザを用いてウェブ売手のウェブサイトへナビゲートしなければならない。ウェブ買手が購入したい製品を選択した後で、ウェブ買手は通常、ウェブ売手のサイト上の長たらしい電子書式に記入するよう促される。そのような電子書式は普通、少なくともユーザの氏名、住所、電話番号、ｅメールアドレス、およびクレジットカード情報を含む個人および機密情報を要請する。さらに、買手は自分が商品およびサービスを購入したい各ウェブサイトに別々にログインしなければならない。そのような各々のウェブサイトにおいて、買手は上述の個人および機密情報を記入しなければならない。実際、買手は自分が本当にクレジットを希望するかまたは必要とするかどうかにかかわらず、各ウェブ売手用のクレジット申込書に記入しなければならない。ウェブ買手はしばしば、個人の独特な識別タグ（以下「ＩＤ」）とパスワードとを選択するよう要請され、または促される。そのようなＩＤとパスワードのペアにより、ウェブ買手は、そのウェブ売手のサイトを次に訪れた際に、ウェブ売手の電子書式へのデータ入力の多くを迂回できる場合がある。しかしながら、このことは、ウェブ売手が各ウェブ買手についての個人および課金情報を収集し記憶するということを必然的に伴う。ウェブ売手の大半はこの多数の個人情報を注意深く保護し、守るであろうが、そのような情報がウェブ買手がもともと考えていたこと以外の目的のために使用されるかもしれない可能性がある。クレジットまたはチャージカード情報は特に、不正および誤用にやられやすい。実際、盗まれた（または不正流用された）もののその他の点では有効なクレジットカード番号がウェブを通して商品またはサービスを購入するのに不正に使用されるおそれがあり、これはそのようなクレジットまたはチャージカードの不正を防止するためにウェブ売手によって採用される機密保護対策の欠如（または本質的に大幅に異なる性質）のためである。そのような不正は、クレジットカード発行会社、ウェブ買手、および、買手の苦情処���に時間とエネルギを費やさなければならないウェブ売手を含む全関係当事者にとって有害である。クレジットカードからの金銭上の損失はクレジットカード発行会社と買手の双方に影響を及ぼす。しかしながら、主な損失を経験するのは、商品を手放したものの請求がクレジットカード発行会社に許可されなかった商人であろう。商人にとって、この損失はｅコマースにクレジットカードを使用する際の主な欠点である。
【０００３】
しかしながら、盗まれ得るのはウェブ買手のクレジットカード情報だけではない。潜在的にはるかにより有害なのは、いわゆる個人情報盗難、つまりある人の個人および財政情報の不正流用および誤用の可能性である。個人情報盗難の恐ろしさはますますより大きく立ちはだかっている。なぜなら、これらのウェブベースの電子書式が、非常に詳細な機密情報の予めパッケージ化されたワンストップショッピング源を、それにアクセスする不心得者に提供するためである。ウェブ売手の大半はきちんとしており、個人情報盗難の阻止を狙った手順を確立しているものの、インターネット上でのウェブ売手の全くの急増は事実上、そのような盗難がますます一般化していくということを確実にしている。
【０００４】
おそらく起訴可能性が劣る（しかし同様に苛立たしい）ものは、いわゆる「個人情報混同」の可能性である。この場合、ある人が別の人ととり違えられてそれぞれの人の個人情報が互いに代用されるかまたは合併されるおそれがある。たとえば、ウェブ売手または信用機関が間違って、名前は同一であるが別人である２人の２つの記録を合併するかもしれない。ここでも、この問題は、各々自分のウェブ買手から得た個人および財政情報を要請し、保管し、そしておそらく調査し、および／または販売する、インターネット上のウェブ売手の急増によって悪化するばかりである。
【０００５】
ウェブ売手のこの急増はまた、ウェブ買手が各ウェブ売手につき１つずつ、非常に多くの別々のＩＤとパスワードのペアを選択するよう繰返し要請されていることも意味する。したがって、ウェブ買手にとって、これらのＩＤ−パスワードのペアを覚えておくこと、および／または特定のＩＤ−パスワードのペアを特定のウェブ売手に関連付けることは難しくなるであろう。ウェブ買手の中には、単一のＩＤ−パスワードのペアを選択し、その単一のＩＤ−パスワードのペアを自分が取引を行なうすべてのウェブ売手に対して用いることに頼る者もいる。しかしながら、これは満足できない解決策である。なぜなら、そのようなウェブ買手は、その単一のＩＤ−パスワードのペアが不正流用されれば、より不正の対象になりやすいためである。
【０００６】
ウェブ売手間でのデータ収集における安全性、簡潔性および均質性の認知された欠如は、ｅコマースへの加入に対する障壁として働き、多くの潜在的な買手にオンラインで商品およびサービスを購入することを思いとどまらせている。したがってウェブ買手は、簡単で均質かつ安全なウェブベースの取引の促進に関心を持っている。したがって必要なのは、金融取引が、インターネットまたは他のネットワーク上において簡単でウェブ売手間で均質な態様で実行され、ウェブ買手の個人および財政情報の完全性および安全性を確実にする態様で行なわれることを可能にする方法およびシステムである。
【０００７】
ウェブ売手は、最大限可能な数の買手を自分のサイトに引きつけるために、簡単で安全なｅコマースを促進することに関心を持っているので、ウェブ売手の関心は一般に彼らの買手の関心と揃っている。買手の個人および財政情報のやみくもな収集に対する代案が今後実施されるならば、ウェブ売手は自分たちが提供する商品またはサービスに対する支払を実際に受けるということを確信するに違いない。したがって必要なのは、ウェブ売手の関心を促進し、自分のウェブサイトから販売された商品およびサービスに対して適時に支払を受けるという完全な確信を売手に提供する方法およびシステムである。
【０００８】
不思議なことに、これまでウェブ買手−ウェブ売手の取引にとって不可欠な当事者であった銀行は数少ない。実際、金銭は最終的にはウェブ買手の銀行口座から引き落とされるかまたは買手のクレジットもしくはチャージカードに請求されるものの、買手の銀行または他の金融機関は通常、ｅコマース取引に積極的には関与してこなかった。なぜなら、そのような取引は従来どおりに構成されているためである。したがって、同様に必要なのは、銀行などの金融機関を、ｅコマース取引における不可欠で中心的な参加者として含む方法およびシステムである。
【０００９】
とはいえ、単一の買手が単一の売手へ支払う無条件の支払または無条件の約束をすることにかかわる単純な取引は、日常的に実行される取引のほんの一部分しか構成しない。たとえば、多くの取引はある種の付帯事項付き（contingent）支払を伴う。実際、多くの取引は、商品または権利所有権の所有者が変わったりまたは義務が免除される前に満たされなければならない固有の付帯事項を含む。たとえば、不動産の購入についての契約は、多数の付帯事項（検査に合格すること、融資を得ること、改良を実行すること、および他の一般に期日に左右される買手および売手双方の義務）の解除を通常伴う複雑な取引である。そのような取引は歴史的に紙の文書上への自筆の署名を中心としてきた。実際、土地の販売についての契約の場合、買手（および時には売手）は通常、付帯事項を解除するため、および／または、付帯事項が満たされた場合および／または解除された場合に支払を行なうために、エスクローエージェントの事業所を繰り返し訪れなければならない。また、これに代えて、単一の文書が署名を求めてファクシミリを介し繰返し送信される場合があり、結局、最終的な文書をほぼ判読できなくしてしまって潜在的に履行拒絶を受けやすくなる。
【００１０】
他の付帯事項付き支払方式は、同様に履行拒絶になりやすい他の安全でない方式に頼っている場合がある。たとえば、株式仲買人は、電話を通して、証券または他の証書を買うまたは売る注文を、その注文が既知の顧客から来ているということを前提に受付ける。注文が満たされてから予め定められた期間（たとえば５日）たつと、取引は完了し、文書作成および支払の双方が相互の合意により「決済」として続く。この筋書では、顧客は仲買人の仮定された善意に基づいて株の操作をし、仲買人は自分の顧客の仮定された善意に基づいて株の操作をする。しかしながら、そのような相互作用モデルは、悪用の可能性をはらんでおり、双方の当事者を著しい不利益にさらすおそれがある。
【００１１】
現在ますます広まっているウェブベースの仲買業は、顧客の認証に基づくウェブを通した売買注文を可能にしている。これは電話音声方法を凌ぐ改良であるが、今のところシングルサインオンメカニズムは利用できず、ウェブ仲買業の顧客は、自分が取引を行なう各仲買業者についてＩＤおよびパスワードを選択しなければならない。他の従来どおりに構成されているウェブ取引と同様に、ＩＤおよびパスワードのこの急増は、そのようなｅコマースビジネスへの加入に対する障壁として働き、このビジネスの幅広い受入れを妨げるおそれがある。
【００１２】
消費者志向のウェブオークションについてのオークションエスクロー協定は、主としてクレジットカードにより従来どおり取扱われている。オンラインオークションウェブサイトの中には、認証を確立するために参加者に自分のクレジットカード番号を提供するよう要求するところもある。独立したエスクロー会社は通常、クレジットカードでの支払を必要とし、その支払は、期日が決められた付帯事項の解除があるまで、または購入者の特定の行為により、エスクローとして第三者に預託される。付帯事項付き支払の他の例は、会社間の支払、特に１つのｅビジネスから別のｅビジネスへの支払を含む。そのような支払は通常、従来の紙の証書またはクレジットカードで実行されるが、どちらの解決策も本当に満足できるものではない。多くの取引は、双方の配偶者が物理的に紙の証書に署名することを必要とする。各配偶者が付帯事項を自筆で承認する（解除する）、または紙の小切手、契約書もしくは他の証書に一緒に署名するだけのために特定された場所へ物理的に行かなければならない不便さはしばしば、暗黙のうちに配偶者文書偽造を奨励する。しかしながら、そのような文書偽造も、ほとんどの場合配偶者文書偽造者の意図が悪意から出たものではない性質であるにもかかわらず、同様に銀行またはエスクローエージェントによる証書の履行拒絶につながり得る。現在のところ、これらのおよび他の付帯事項付き支払は一般に、自筆の署名を有する紙の書式において全面的に取扱われている。そのような付帯事項含有取引の電子変換は、付帯事項含有取引の当事者を安全に認証する実行可能な方法を待っている。
【００１３】
そのような方法は、付帯事項に基づく支払または他の付帯事項含有取引の買手および売手に、使いやすさ、安全性、および明確に個人情報を提供しなければならない。好ましくは、そのような方法は、識別および／または認証のためにクレジットカード番号および／または社会保障番号を使用するということに頼るべきではない。なぜなら、多くの顧客は当然ながらそのような情報を、特にインターネットなどの公設ネットワークを通して流したがらないためである。好ましくは、そのような方法は、取引の全当事者の遠隔認証を可能にすべきであり、そのような当事者が取引内の任意の付帯事項の現状を閲覧でき、および／または（その個人に与えられた許可レベルに依存して）任意の付帯事項を解除または拒否できるようにすべきである。好ましくは、そのような方法は、取引の完了時または失敗時（および／または任意の中間段階）、たとえば最終支払が売手へ入金されたとき、または任意の付帯事項が取引の任意の当事者によって拒否されたときなどに、認証された取引の全当事者に非同期的に通知すべきである。さらに、取引の当事者それぞれの口座にある資金が不十分である場合に、取引の当事者のいずれかにクレジットを供与するためのオンラインメカニズムが存在すべきである。
【００１４】
ここで企業間領域に目を向けると、支払は普通、買手が取引を約束した時点では発出されず、その代わり、取引の当事者間で合意されたように（たとえば正味３０日ベースで）遅延される。これについての１つの理由は、根底にある取引に内在する不確実性である。たとえば、買手は、売手が当該商品を出荷しないのではないか、または商品が満足いくものでなかったりもしくは他の点で不適合なものではないかと懸念するかもしれない。他方、買手からの支払を受け取る前に商品を出荷することは、売手に、買手が出荷された商品に対して実際に支払うかどうか、および／または買手が時間どおりにおよび合意どおりに支払うかどうかに関する疑いを残す。必要なのは、これらの懸念および疑いに対処し、どちらか一方の当事者を他方の当事者の不履行時に補償するオンラインメカニズムである。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
発明の概要
したがって、この発明の目的は、金融取引が、インターネットなどのネットワーク上で、簡単でかつ買手が個人であろうと企業体であろうと買手の個人および財政情報の完全性および安全性を確実にする態様で実行されるようにする方法およびシステムを提供することにある。同様に、この発明の目的は、銀行、または政府機関もしくは法人などの他の信用ある当事者などの金融機関を、ウェブベースの取引および同様の取引における不可欠で中心的な参加者として含むｅコマース方法およびシステムを提供することにある。この発明のさらなる目的は、付帯事項に基づく取引の当事者を遠隔から安全に認証するための方法およびシステムを提供し、それにより、付帯事項を解除するのに紙の文書上へ自筆の署名を得る必要をなくすことである。この発明のさらに他の目的は、複雑な取引が遠隔の参加者によって安全に完了されるようにするインフラストラクチャを提供することにある。この発明のさらに他の目的は、取引の当事者それぞれの口座に資金が十分にない場合に、取引の当事者のいずれかに選択的にクレジットを供与するオンラインメカニズムを提供することにある。この発明の別の目的は、いずれか一方の当事者を他方の当事者の不履行時に補償するオンラインメカニズムを提供することにある。
【課題を解決するための手段】
【００１６】
したがって、この発明の一実施例に従った、安全な電子為替手形を介した支払を含む電子取引を実行する、コンピュータにより実施される方法は、為替手形の表示を含む安全なコンピュータサイトを開設するステップを含み、サイトは信用ある主体によって管理され、認証された取引の当事者のみにアクセス可能であり、前記方法はさらに、為替手形の振出人へ連結され、予め定められた条件を含む第１のオンライン信用状を作成するステップを含み、条件の充足は、信用ある主体が振出人へクレジットを供与する前提条件であり、前記方法はさらに、コンピュータサイトに表示された為替手形へのアクセスを要請する為替手形の各当事者を、要請してきた当事者によって安全な通信路を通して提供された識別情報の少なくとも一部を暗号化し、暗号化された識別情報を、記憶された暗号化された（または別様で銀行もしくは金融機関により保護された）要請してきた当事者独特の識別子とうまく整合させることによって認証するステップと、為替手形の名宛人へ為替手形に対する支払を発出するステップとを含み、発出された支払の少なくとも一部は、信用ある主体に預けている振出人の資金から、または、信用ある主体に預けている振出人の資金が為替手形に対する支払をカバーするには不十分である場合には振出人に供与されたクレジットから生じる。信用ある主体での振出人の口座におけるクレジットベースの信用状は、仮差押えに対する第１の切り札であってもよい。その後、振出人の口座における利用可能などの現金も取っておかれてもよい。これら２つの財源が枯渇すると、信用ある主体は振出人へ残高不足メッセージを返してもよい。
【００１７】
為替手形に対する支払は、付帯事項の抹消を条件としており、安全なコンピュータサイトは、付帯事項の説明を提供し、付帯事項の抹消を可能にするよう構成されている。発出するステップは、付帯事項が付帯事項を抹消するよう認可されている認証された当事者によって適時に抹消されたときのみ実行されてもよい。付帯事項は、たとえば商品の出荷、商品出荷の約束、サービスの履行、サービス履行の約束、出荷期日制限、履行期日制限、および／または商品の検査を含んでいてもよい。信用ある主体はたとえば銀行を含んでいてもよい。発出するステップは、信用ある主体に預けられた振出人の資金を仮差押えするステップを含み、仮差押えされた資金は少なくとも為替手形に対する支払の一部と等しい（たとえば購入に等しい信用状が口座にない場合）。第１の信用状は取消可能であっても取消不能であってもよく、単一のまたは多数の取引について有効であってもよい。第１の信用状は予め定められた期間の間有効であってもよい。信用ある主体は、為替手形の振出人に、オンライン信用状の開設についての手数料を請求するステップをさらに実行してもよい。信用ある主体に預けられた振出人の資金から手数料を引き落とすステップも実行されてもよい。第１の信用状は、為替手形に対する支払を発出するのに十分な資金があるかどうかを判断する目的のためだけに、信用ある主体に預けられた振出人の資金の価値を高めてもよい。発出された支払と引換えに、受取られた商品の担保権を信用ある主体に与えるステップが実行されてもよい。コンピュータサイトは、為替手形の振出人に、第１の信用状の現状の会計への安全なアクセスを提供するよう構成されていてもよい。安全なコンピュータサイトはまた、為替手形の名宛人から、第１の信用状の存在およびそれへのアクセスを保護するよう構成されていてもよい。為替手形の名宛人へ連結された第１のオンライン契約履行保証を作成するステップが実行されてもよく、第１の契約履行保証は、名宛人がオンライン取引の条件に従って履行しなかった場合に、第１の清算損害額を為替手形の振出人へ発出する。前記方法は、名宛人がオンライン取引の条件に従って履行するまで、または履行を免除されるまで、第１の清算損害額を名宛人の口座から仮差押えするステップも含んでいてもよい。
【００１８】
名宛人へ連結された第２のオンライン信用状が作成されてもよく、名宛人が利用可能な資金が第１の清算損害額の支払を振出人へ発出するには不十分である場合、第１の清算損害額の少なくとも一部は第２のオンライン信用状から生じてもよい。第２のオンライン契約履行保証を作成するステップが作り出されてもよく、第２のオンライン契約履行保証は為替手形の振出人へ連結され、第２のオンライン契約履行保証は、振出人がオンライン取引の条件に従って履行しなかった場合に、第２の清算損害額を為替手形の名宛人へ発出する。第２の清算損害額は、振出人がオンライン取引の条件に従って履行するまで、または履行を免除されるまで、振出人の口座から仮差押えされてもよい。信用ある主体に預けている振出人の資金が第２の清算損害額の発出をカバーするには不十分である場合、第２の清算損害額の少なくとも一部は振出人に供与されたクレジットから生じてもよい。安全なコンピュータサイトは、電子取引の条件を規定する１つ以上の文書の表示をさらに含んでいてもよい。文書は好ましくは、認証された取引の当事者のみにアクセス可能である。文書の各改訂案は、改訂付帯事項、改訂案の承認を構成する認証された当事者によるその適時の抹消を含んでいてもよい。
【００１９】
この発明はまた、安全な電子為替手形を介した支払を含み得る電子取引を実行する、コンピュータにより実施される方法であって、為替手形の表示を含み得る安全なコンピュータサイトを開設するステップを含み、サイトは信用ある主体によって管理され、認証された取引の当事者のみにアクセス可能であり、前記方法はさらに、第１のオンライン契約履行保証を作成するステップを含み、第１のオンライン契約履行保証は、名宛人の不履行時に為替手形の振出人へ支払われるべき第１の清算損害額、および振出人の不履行時に為替手形の名宛人へ支払われるべき第２の清算損害額のうちの一方を規定し、前記方法はさらに、コンピュータサイトに表示された為替手形へのアクセスを要請する為替手形の各当事者を、要請してきた当事者によって安全な通信路を通して提供された識別情報の少なくとも一部を暗号化し、暗号化された識別情報を、要請してきた当事者にとって独特であり得る記憶された暗号化された識別子とうまく整合させることによって認証するステップと、振出人および名宛人の双方が履行した場合に、為替手形に対する支払を為替手形の名宛人へ発出するステップ、名宛人の不履行時、または第１の事象の発生時に、第１の清算損害額を振出人へ支払うステップ、および振出人の不履行時、または第２の事象の発生時に、第２の清算損害額を名宛人へ支払うステップのうちの１つを実行するステップとを含む。
【００２０】
信用ある主体に預けられた振出人の資金を仮差押えするステップが実行されてもよく、仮差押えされた資金は少なくとも為替手形に対して発出されるべき支払の一部と等しい。仮差押えするステップは、少なくとも第２の清算損害額と等しい振出人の資金を仮差押えしてもよい。名宛人の資金を仮差押えするステップも実行されてもよく、仮差押えされた資金は少なくとも第１の清算損害額と等しい。
【００２１】
前記方法はまた、為替手形の振出人へ連結され、第１の予め定められた条件を含む第１の信用状を作成するステップも含んでいてもよく、第１の予め定められた条件の充足は、信用ある主体が振出人へクレジットを供与する前提条件であり、前記方法はさらに、信用ある主体に預けている振出人の資金が、為替手形に対する支払、または第２の清算損害額の支払をカバーするには不十分である場合、名宛人へ発出される支払の少なくとも一部を、振出人へ供与されたクレジットから引出すステップも含んでいてもよい。
【００２２】
第１の信用状は、振出人の不履行時に第２の清算損害額を支払う目的のため、または為替手形に対する支払を発出するのに十分な資金があるかどうかを判断する目的のためだけに、信用ある主体に預けられた振出人の資金の価値を高めてもよい。コンピュータサイトは、為替手形の振出人に、第１の契約履行保証および第１の信用状の現状の会計への安全なアクセスを提供するよう構成されていてもよい。為替手形の名宛人へ連結され、第２の予め定められた条件を含む第２の信用状が作成されてもよく、第２の予め定められた条件の充足は、クレジットが名宛人へ供与される前提条件であり、前記方法はさらに、名宛人の資金が第１の清算損害額の支払をカバーするには不十分である場合に、名宛人へ発出される支払の少なくとも一部を、名宛人へ供与されたクレジットから引出すステップを含んでいてもよい。第１および第２の清算損害額の支払をそれぞれひきおこす第１および／または第２の事象は、好ましくは、電子取引の条件において規定される。
【００２３】
この発明の目的および利点のさらなる理解のため、以下の詳細な説明を添付図面とともに参照されたい。
【発明を実施するための最良の形態】
【００２４】
好ましい実施例の説明
機能的概要
この発明は、従来のｅコマース方式に内在する多くの問題、とりわけ、安全でないネットワーク間でのおよびさまざまなウェブ売手への機密取引、個人および／または財政情報の流布、取引上の機密保護、個人情報を繰返し再入力する必要性、個人情報盗難および個人情報混同の危険、ならびに、商品の出荷不履行、不適合品の出荷、支払不履行、適時の出荷、不払出荷などの商品の遅延された支払に関連する不確実性を解決する。この発明によれば、限られた数の主体（および好ましくは唯一のそのような主体）しか、ウェブ買手の銀行口座番号およびクレジット／チャージカード番号などの個人および／または財政情報を保有しない。好ましくは、そのような情報を保有する主体は、将来のまたは既存のウェブ買手との信任関係または信用ある関係を既に享受している主体、たとえばウェブ買手の金融サービスプロバイダ（Financial Service Provider）（以下「ＦＳＰ」）、銀行、クレジットカード保有者などである。このように、どのウェブ売手も（または、顧客が故意におよび自発的にこの情報を取引へ付加した場合には、より少数のウェブ売手しか）ウェブ買手の口座番号、クレジットカード番号、パスワードなどの個人および／または財政情報を保有せず、またはそれへアクセスしない。
【００２５】
この発明は、ｅコマースが、所望すれば、ウェブ買手に対する高度の安全性およびウェブ売手に対する高度の信頼性を維持しつつ、クレジットまたはチャージカードに頼らずに実行されるようにする（この発明の文脈内では、ウェブ売手は、ウェブを通して商品およびサービスを提供する小売業者だけでなく、インターネット、イントラネット、仮想私設ネットワークまたは安全な専用回線を、ビジネスを行なったり資金を振込む通信および取引媒体として利用するいかなる個人または主体も含む）。実際、この発明は、為替手形が、小切手（為替手形のある特定の形）とかなり同じ態様で、インターネット（または何か他の公設、私設または仮想私設ネットワーク（Virtual Private Network）（以下ＶＰＮ））を通してウェブ買手により作成され、ウェブ売手の適切なＦＳＰ提供ソフトウェアのインストールによりウェブ買手の金融機関へ支払用に提示されるようにする。しかしながら、小切手とは異なり、その作成、提示および支払は、この発明によれば、電子書式で、および従来の「紙の」小切手を流通させるのに不可欠な部分を形成する小切手為替手形交換所の仲介なく、実行されてもよい。
【００２６】
一般に受入れられている法律用語を用いると、為替手形とは、振出人と呼ばれる第１の当事者が、名宛人と呼ばれる第２の当事者に、受取人と呼ばれる第３の当事者へ金銭を支払うよう指示する注文書である。ｅコマースおよびこの発明に関しては、ウェブ売手が受取人として考えられ、ウェブ買手が振出人として考えられ、そして銀行などの金融機関が名宛人として考えられ得る。ここでは、「ＦＳＰ」、「金融機関」および「銀行」という用語は交換可能に用いられており、番号の付いた（または他のやり方で独特に識別された）口座への現金、有価証券、市場性のある株／株式の預入を受付け、小切手、為替手形および／または他の顧客の指示を有効として引受けるすべての金融サービス機関を含むものとして理解されるべきである。そのような定義は、伝統的な銀行および貯蓄機関、株式仲買業者、オンライン商社、信用組合、および、口座保有者を合法的に識別して口座保有者と何らかの金融関係を有する、および特定の口座に関する顧客または口座保有者の指示を有効として引受ける能力を有する任意の機関または信用ある主体を含む（がそれらに限定されない）。この発明の利用可能性は、銀行機能または銀行に準じる機能を実行する郵便局または他の政府機関などの組織にも延長され、これは、それらの組織および機関が番号の付いた（または他のやり方で独特に識別された）口座を保持しており、銀行で必要とされるのと同様の身分証明、つまり、その機関で番号の付いた口座を開設するための本人の署名と、この発明に従ったシステムへ参加するためのサービス条件への同意とを必要とするという仮定に基づいている。そのような政府機関の別の例として、内国税歳入局（ＩＲＳ）が考えられ得る。
【００２７】
為替手形は受取人の指図により金銭を支払う無条件の約束としても考えられ得るため、名宛人（ＦＳＰおよび／または他の機関）は、振出人を適正に認証すること（明確にその個人情報を検証すること）に多大な関心を持っている。実際、ＦＳＰ（および通常は口座保有者ではない）は、不適正な認証が行なわれた場合に損失を負担する義務を負う場合がある。従来の紙ベースの為替手形（たとえば小切手）の振出人を認証する主な手段は振出人の署名であり、その見本は通常、ＦＳＰ内のカードファイルに保管されている。署名の代わりに、この発明の一実施例は、識別文字列とパスワードのペアなどの識別情報、および／または証明書、および／または生体測定データ、もしくは他の任意の適切な機密保護システムの使用を考えている。生体測定データは、たとえば指紋、網膜スキャン、および／または声紋などの、ある振出人をその他全員から区別するあらゆる物理的特徴を含み得る。識別情報が識別文字列とパスワードのペアを含んでいる、この発明の例示的な一実施例を以下に開示するが、他の識別情報（たとえば生体測定データなど）が、この発明の範囲を逸脱することなく、その代わりに使用されるかまたはそれとともに使用されてもよいことが理解されるであろう。
【００２８】
識別文字列（以下「ＩＤ」）は好ましくは、アルファベットと数字双方（英数字）の文字を含み、為替手形の振出人（ウェブ買手など）を他の振出人から独特に識別する。ＦＳＰは試験を行なってＩＤの独特性を確実にしてもよい。同様に、パスワードも好ましくは英数字の文字を含む。ＩＤは、この発明の一実施例によれば、ウェブ買手に割当てられてもよく、一方、パスワードは好ましくは、参加するウェブ買手により選択され、ウェブ買手にしか知られず、名宛人（ＦＳＰなど）および受取人（ウェブ売手など）を含む他の全員は除外される。たとえば、ＩＤは、“joesmith.smithco@myFSP.com”にあるような完全収縮されたドメイン名を含んだりまたはそのドメイン名へ割当てられていてもよく、ここで“myFSP”はスミス社（Smith Co.）のホームＦＳＰの第２レベルのドメインである。選択されたパスワードがウェブ買手にしか知られないままであることを確実にするため、選択されたパスワードはその受取時に直ちに暗号化され、ＦＳＰのみによりその暗号化された形で記憶されてもよい。これは、ＦＳＰを、ウェブ買手のパスワードおよびＩＤの不正流用の申し立てから保護する。ＩＤとパスワードの組合せは好ましくは、すべての個人に対し、そのような個人が彼ら自身を表わしていようと企業体を表わしていようと、必要とされる。この発明によれば、いかなる当事者による行為も、少なくともＩＤとパスワードの組合せによって認証され得るが、ＦＳＰが満足できる個人認証のいかなる手段もこの発明の文脈内で実現されてもよい。ＩＤは、この発明によれば、明瞭に送信されてもよく、独特のものである。にもかかわらず、ＩＤは関係者のみに知らせる原則でしか流されるべきではない。さらに、ＦＳＰがＩＤの所有者の代理人として活動する場合、ＩＤは、ＦＳＰによって使用されるか、またはＦＳＰもしくはＦＳＰの行為によって覆い隠されてもよい。企業もその個々の従業員について役割および特権を作り出してもよい。これらの役割および特権（たとえば購入能力における規定可能な制限）はＩＤと結び付けられてもよく、ＦＳＰとの取引関係を通して、およびこの発明の実施を通して管理される。さらに、企業のＣＥＯまたはＣＦＯからずっと下までの特権の規定された鎖は、後の履行拒絶を防止するかもしれない。他方、パスワードは好ましくは、パスワードが関連しているまたは割当てられている個人にしか知られない。また、これに代えて、組織内のより下位ランクの個人のパスワードが、その人が報告するより上位ランクの個人にも知られてもよい。ＦＳＰは、この発明によれば、たとえばユーザのＩＤとパスワードの組合せを検証することによってユーザを認証してもよい。また、これに代えて、ＦＳＰによって正式に認可された他の当事者が、ＦＳＰの公認代理人として活動することにより、ＦＳＰに代わってユーザを認証してもよい。
【００２９】
図１Ａ〜８を参照して、この発明の実施例を詳細に説明する。図１Ａに示すように、ウェブ買手は、ステップＳ１１Ａに示すように自分のホームＦＳＰまたは支店を訪問し、この発明に従ったiDraftTM（ｉ為替手形TM）システムに参加するために署名入りの認可を出すことによって、この発明に従った方法を開始してもよい。また、これに代えて、ウェブ買手は自分のホームＦＳＰのウェブサイト（または公設もしくは私設ネットワーク上の他の同等のＦＳＰの存在）にログオンしてもよいが、ＦＳＰの中には、ウェブ買手がＦＳＰまたは支店を物理的に訪れて必要な書類に記入し、本人の自筆の署名を得ることを好む、または必要とするところがあるかもしれない。ウェブ買手のホームＦＳＰは、ウェブ買手の仲買業者または貯蓄機関であってもよく、もしくは、たとえば買手が当座預金口座を保持しているＦＳＰであってもよい。好ましくは、ウェブ買手とウェブ買手のホームＦＳＰとは、ウェブを通して接続されると、ある合意されたおよび規格化されたプロトコル、たとえばセキュア・ソケット・レイヤー（Secure Socket Layer）（以下「ＳＳＬ」）プロトコル（ここに引用により援用する）またはマイクロソフト社（Microsoft Corp.）のセキュリティ・サポート・プロバイダ・インターフェイス（Security Support Provider Interface：ＳＳＰＩ）などを用いて、安全な通信チャネルを確立する。ＳＳＬは、通信時にネゴシエーションする暗号方式（たとえば公開鍵暗号方式など）を利用して、ウェブ買手とウェブ買手のホームＦＳＰとの間の電子盗聴者が、明瞭で暗号化されていないいかなる通信も傍受できないようにすることを確実にする手助けをする。そのようなＳＳＬは、たとえばウェブ買手のウェブブラウザソフトウェアとウェブ買手のホームＦＳＰのワールドワイドウェブサーバとの間でネゴシエーションされてもよい。ウェブ買手が一旦自分のホームＦＳＰのウェブサイトへ到達すると（またはＦＳＰを物理的に訪れてこの発明に従ったiDraftTMシステムへの参加を認可すると）、ステップＳ１２Ａに概説されるように、ウェブ買手は、適切な書類に記入しまたはウェブ買手のホームＦＳＰのウェブサイトに供給されたフィールドに必須の識別情報を入力した後で、ＩＤを割当てられ、パスワードを選択するよう促されてもよい。また、それに代えて、ウェブ買手は、ＩＤおよびパスワードの双方を選択してもよく、ＩＤおよびパスワードの双方を割当てられてもよく、またはそれらのいかなる順列であってもよい。この発明の一実施例によれば、ウェブ買手のブラウザソフトウェアは、ウェブ買手のホームＦＳＰ（または何らかの信用仲介機関）の管理の下で、ウェブ買手とウェブ買手のホームＦＳＰとの間に安全な通信路を確立し、ウェブ買手のパスワードを暗号化する。iDraftTMに関連する取引に対する信用ある仲介機関の一例は、iDraftTM参加ＦＳＰまたは他の金融機関と提携していてもよい、およびiDraftTMを通してＦＳＰと情報の収集および／または交換を行なってもよい電子取引所（その中でも、オラクル・エクスチェンジ（Oracle Exchange）−その詳細はオラクル・インターナショナル・コーポレイション（Oracle Corp.）のウェブサイトで利用可能である−はほんの一例である）および／または他の電子市場である。
【００３０】
ここで図１Ａに戻ると、ウェブ買手のパスワードは、それがブラウザに打込まれている間のみ、ウェブ買手のサイトにおいてつかの間明瞭な状態にある（つまり、暗号化されていない）かもしれない。しかしながら、ウェブ買手のホームＦＳＰ（または或る信用ある仲介機関）は、たとえばキー操作を収集しそれらを或る第三者へインターネットを通して送信し得るアプレットがないか検査することによって、ウェブ買手が、ブラウザソフトウェアが走っている自分たちのコンピュータを保護するのを助けてもよい。好ましくは、ウェブ買手のパスワードは決して、明瞭な状態でＦＳＰに送られはしない。次に、Ｓ１３Ａに示すように、ウェブ買手のホームＦＳＰはウェブ買手のＩＤと暗号化されたパスワードとを記憶する。暗号化されたパスワードは次に、たとえばディレクトリソフトウェアによって管理されるウェブ買手のホームＦＳＰのサーバまたは他の記憶装置内に記憶される。ホームＦＳＰの（たとえばジャバ（Java（Ｒ））プログラミング言語の）ソフトウェアは、ウェブ買手のブラウザソフトウェアを用いて、ウェブ買手のコンピュータ上に証明書または他の機密保護機構を設けてもよい。ホームＦＳＰはまた、ウィルスまたは他の潜在的な有害物がこれらの取引の機密保護に影響を及ぼさないことを確実にする他の措置をとってもよい。上に詳述した措置は、信用ある当事者（たとえばＦＳＰ、金融機関、またはＦＳＰの公認代理人として働く取引所などの他の仲介機関など）が、ユーザ（またはユーザの代理人として活動する仲介機関）を満足ゆくように認証するために取る措置の単なる例示である。実際、この発明は、ＦＳＰ、金融機関、または他の仲介機関がこの発明に従ったシステムおよび方法のユーザを認証するやり方を多少なりとも限定するものとして解釈されるべきではない。ＦＳＰが不適正な認証による損失の危険を負うため、ＦＳＰにその好ましい認証方法を特定させ、実行させるようにすることは適正である。
【００３１】
ウェブ買手の暗号化されたパスワードだけを、その明瞭で暗号化されていないバージョンを記憶せずにまたはそのバージョンにアクセスせずに記憶することによって、ウェブ買手のホームＦＳＰは、ウェブ買手の暗号化されていないパスワードがウェブ買手だけにしか知られないままであることを確実にする。したがって、好ましくは、ウェブ買手のホームＦＳＰでさえ、ウェブ買手によって選択された暗号化されていない明瞭なパスワードを知らない。この発明の一実施例によれば、（他のすべてのＦＳＰおよびウェブ売手を除外した）ウェブ買手のホームＦＳＰしか、ウェブ買手の暗号化されたパスワードを知らず、および／またはそれにアクセスしない。ステップＳ１４Ａに示すように、ホームＦＳＰは、この発明の一実施例によれば、次にローカルマスタリストを更新する。マスタリストは、この発明の一実施例によれば、ＩＤによって識別されるウェブ買手とウェブ買手のホームＦＳＰの識別情報とのリストを含んでいてもよい。また、それに代えて、暗号化されたパスワードは、取引所またはｅコマースサイトなどの第三者で記憶されてもよい。しかしながら、第三者、取引所またはｅコマースサイトは、暗号化されたパスワードを記憶するだけであり、ユーザによって入力された暗号化された形のパスワードを記憶された暗号化されたパスワードと比較することによってユーザを認証するだけである。暗号化されていないパスワードはユーザ（たとえばウェブ買手）にしか知られないままであり、第三者、取引所またはｅコマースサイトには知られない。この知識が、根底にある取引に関する否認防止の根拠である。認証されたユーザは次に、ユーザのホームＦＳＰまたは他のＦＳＰに通されてもよい。
【００３２】
図１Ｂは、この発明のさらなる局面を示すフローチャートであり、ＦＳＰのウェブサイトを通してアクセスされたウェブ売手から商品またはサービスを購入したいウェブ買手を認証するためにウェブ買手のホームＦＳＰが取り得る例示的な措置を示す。ステップＳ１１Ｂでは、ウェブ買手とその人のホームＦＳＰとは、ウェブ買手のウェブブラウザソフトウェアとウェブ買手のホームＦＳＰのウェブサーバとの間でネゴシエーションされるＳＳＬ（例）を介したような安全な通信を確立する。ウェブ買手は、自分のホームＦＳＰのウェブサイトにアクセスすると、ステップＳ１２Ｂに概説されるように、自分のＩＤおよびパスワード（および／またはたとえば他の生体測定データ）を、ウェブ買手のホームＦＳＰのサーバとウェブ買手のパーソナルコンピュータ、ネットワークコンピュータまたは他のネットワーク対応もしくはウェブ対応装置または機器にインストールされたソフトウェア（ウェブブラウザなど）との間の安全な通信チャネルを通して入力するよう促されてもよい。ウェブ買手のパスワードは好ましくは、ウェブ買手のホームＦＳＰに送られる前に（たとえばブラウザソフトウェアによって）暗号化される。また、これに代えて、他の機密保護対策および／または認証手段が、ＦＳＰの要求に応じて採用されてもよい（たとえば証明書ベースの対策を含む）。安全な通信チャネルを通して送信されたＩＤと暗号化されたパスワードとは次に、ウェブ買手のホームＦＳＰのサーバによって受信される。ウェブ買手のＦＳＰのサーバは次に、受信されたウェブ買手のＩＤを利用して、そのＩＤに関連する記録にアクセスしてもよい。受信されたＩＤに関連する記録は、好ましくは、そのＩＤについての以前に暗号化されて記憶されたパスワードを含む（または指す）。次に、そのウェブ買手についての以前に暗号化され記憶されたパスワードが検索される。図１ＢのステップＳ１４ＢおよびＳ１５Ｂに示すように、ウェブ買手から受信された暗号化されたパスワードは、そのＩＤについての以前に記憶された暗号化されたパスワードと比較される。２つの暗号化されたパスワード同士が整合しない場合、Ｓ１６Ｂに示すように、ウェブ買手はウェブ買手のホームＦＳＰによって認証されない。適切なメッセージが次に生成されてウェブ買手に送られ、買手にＩＤとパスワードとを再入力するか、または何か他の操作を実行するよう促してもよい。２つの暗号化されたパスワード同士が整合すると、ウェブ買手は認証され（ステップＳ１７Ｂ）、ウェブ買手の個人情報が損失の危険を負う主体、つまりウェブ買手のホームＦＳＰが満足するように検証されたことを意味する。ウェブ買手は次に、この発明の一実施例によれば、ホームＦＳＰの自分の口座へのアクセス、および、たとえばホームＦＳＰの安全なウェブサイトへの、またはＦＳＰが主催する安全なウェブサイトへのアクセスを与えられる。そのような安全なウェブサイトは、たとえば、ユニバーサルリソースロケータ（ＵＲＬ）または何か他のネットワークに関連するアドレス、もしくはホームＦＳＰが提携関係を結んでいるウェブ売手へのリンクを含む受取人（ウェブ売手）リストを含んでいてもよく、これらのウェブ売手が、ステップＳ１８Ｂに示すように、この発明に従ったiDraftTMシステムに参加している（およびこのシステムの条件によって結合されることに同意している）ことを意味している。一旦認証されると、ウェブ買手がウェブ買手のホームＦＳＰのウェブサイト内に、またはＦＳＰのウェブサイトからアクセスされる、および／またはＦＳＰが提携関係を確立したウェブ売手のウェブサイト内に留まっている限り、ウェブ買手は現行セッションの期間中、認証されたままであってもよい。ウェブ買手が一旦そのようなウェブサイトを離れると、買手はもはや認証されず、自分のホームＦＳＰによって作成され有効として引受けられる電子ＦＳＰ為替手形を有したい場合には、再認証されなければならない。ＦＳＰによってそれぞれのウェブ売手および／または電子市場サイトおよび／または買手に提供される適切なソフトウェアは、ウェブ買手のブラウザと協力してこれらの機能および機構を実行する。なお、図１Ａおよび１Ｂに概説した認証方法は、ウェブ買手のホームＦＳＰがいかにしてウェブ買手をインターネットなどのコンピュータネットワークを通して認証するかを単に例示したものである。しかしながら、ウェブ買手の個人情報をウェブ買手のホームＦＳＰ（または他の信用ある仲介機関）が満足するように検証するいかなる認証方法も、この発明の文脈内で用いられてもよい。たとえば、生体測定が上述のＩＤ／暗号化されたパスワードの組合せを補足または置き換えてもよい。高度の確実性でウェブ買手を識別する他のいかなる手段も、この発明の範囲内で用いられてもよい。
【００３３】
安全なホームＦＳＰのウェブサイトは、付加価値ポータル、つまり、認証されたウェブ買手が選択されたウェブ売手のウェブサイトへそこから移るジャンプステーションまたはゲートウェイとして機能してもよい。そのようなポータルは、この発明によれば、ＦＳＰまたはＦＳＰが契約関係を有する任意の第三者のソフトウェアまたはサイトを含んでいてもよい。この発明の文脈内では、この発明はインターネットまたはワールドワイドウェブのみに関連する用途よりも幅広い利用可能性を有しているため、ネットワークを適切に表現するものが「ウェブ」という用語の代わりに使われてもよい。特徴あるウェブ売手のうちの１つのウェブサイトへ移ると、認証されたウェブ買手は、商品および／またはサービスを購入し、その支払として１つ以上のＦＳＰ為替手形を作成させてもよい。ホームＦＳＰのウェブサイトからウェブ売手のウェブサイトへアクセスしているウェブ買手は既に認証されているため、ウェブ売手は、そのような認証されたウェブ買手によって作成される為替手形は実際にウェブ買手のホームＦＳＰによって有効として引受けられる（支払われる）ことを確信するであろう。そのような為替手形は好ましくは、たとえばウェブ買手が自分のホームＦＳＰと安全な通信を確立する際に利用したのと同様の態様で、ウェブ売手によりホームＦＳＰへ電子の暗号化された形で提示される。
【００３４】
ホームＦＳＰは、ウェブ買手のパスワードを受信し暗号化すると、ウェブ買手（為替手形振出人）の個人情報を検索するだけでなく、他の財政的に関係する情報も検索する。そのような他の財政的に関係する情報は、たとえば、ウェブ買手の関連する口座における残高、買手の信用限度および／または予め定められた支出限度を含んでいてもよい。ホームＦＳＰは次に、検索された財政情報に基づいて制約を設ける。たとえば、ウェブ買手がＦＳＰの満足いくように適正に認証されていても、引出される金額がウェブ買手の関連する口座、融資限度額、現金準備額、クレジットまたは購入またはチャージカードなどにおいて引出し用に利用可能な資金を上回っている場合、ホームＦＳＰはウェブ売手によりそれへ提示された為替手形を有効として引受けない場合がある。このように、提示された為替手形の振出人が名宛人により認証され、かつ名宛人によって設けられた制約が満たされた場合のみ、ホームＦＳＰは名宛人が提携関係を有する受取人によって提示された為替手形を有効として引受ける。そのような制約は、以前にＦＳＰとウェブ買手双方によって交渉され合意されたものであってもよく、またはＦＳＰによって決められてもよい。ＦＳＰはそのような決められた制約を受けるとiDraftTMシステムへの参加を調整してもよい。
【００３５】
好ましくは、前述した図１ＡのステップＳ１３Ａに示すように、ホームＦＳＰは、ウェブ買手のＩＤ、暗号化されたパスワード、および他の関連する財政および個人情報を、ディレクトリソフトウェアにより管理されるデータ構造に記憶する。ディレクトリソフトウェアは通常、ネットワーク内の氏名、許可、リソース、ハードウェア、ソフトウェア、および階層的な情報および／または規則のリポジトリ（たとえばリストまたはデータベース）を含む。「ディレクトリソフトウェア」という語句は、この発明によれば、ネットワークに結合されたコンピュータ上で動作するよう設計されたそのようなレポジトリを含む、または管理するあらゆるソフトウェアを包含する。たとえば、ホームＦＳＰは上述の情報を、そのプロトコルをここに引用により援用するＸ．５００ディレクトリ・アクセス・プロトコル（Directory Access Protocol：ＤＡＰ）またはそのサブセット、拡張もしくは変形と互換性のあるディレクトリアクセスソフトウェアなどのディレクトリアクセスソフトウェアと互換性があり、それを通してアクセス可能であるディレクトリソフトウェアに記憶してもよい。ＤＡＰの１つのそのようなサブセットは、ライトウェイト・ディレクトリ・アクセス・プロトコル(Lightweight Directory Access Protocol)つまりＬＤＡＰ、または同等の登録されたユーザについての認証および詳細な情報のデータベース格納である。たとえば、ウェブ買手のホームＦＳＰは、この発明の譲受人によって開発されたソフトウェア製品であるオラクル・インターネット・ディレクトリTM（Oracle Internet DirectoryTM：ＯＩＤTM）ソフトウェア（またはそのアップグレード版／変形）を導入してもよい。ＯＩＤTMは、インターネット技術特別調査委員会（Internet Engineering Task Force：ＩＥＴＦ）ＬＤＡＰ  ｖ３規格（その全容を同様にここに引用により援用する）のネイティブの導入を、たとえばオラクル８（または後の導入）バックエンドデータストアと組合せる。同様に、ウェブ買手のホームＦＳＰは上に詳述された情報を、上に識別されたオラクル・インターナショナル・コーポレイションからのＯＩＤTMソフトウェアなどの、ＬＤＡＰ  ｖ３（または後のバージョン）プロトコルと互換性のあるディレクトリソフトウェア内に記憶してもよい。また、これに代えて、ノベル社（Novell Inc.）のノベル・ディレクトリ・サービスTM（Novell Directory ServicesTM：ＮＤＳTM）などの他のディレクトリソフトウェアを、この目的のために使用してもよい。
【００３６】
取引上の機密保護を確実にするため、この発明に従ったiDraftTMシステムに参加する各ＦＳＰは、その参加する口座保有者の財政情報に対する管理を、口座保有者が買手であれ売手であれ維持する。これにより、口座保有者の財政情報は、それが属するところ、つまりその人のホームＦＳＰ内に保持され、その人が取引する商人には渡されない。また、各iDraftTMＦＳＰは、各参加ＦＳＰのiDraftTM活動を監視し、各iDraftTMＦＳＰが遵守を同意した共通の規則を管理する監督および規格制定機関として形成されてもよいiDraftTM協会に対して責任を負っていてもよい。
【００３７】
この発明によれば、iDraftTMＦＳＰ（少なくともウェブ買手のホームiDraftTMＦＳＰ、およびおそらくはウェブ売手のiDraftTMＦＳＰも）は常に買手と売手との間を仲介する。実際、売手がiDraftTMＦＳＰでもある場合でない限り、売手が買手を認証することはない。その場合、買手もiDraftTM特権を有するiDraftTMＦＳＰの口座保有者であってもよい。たとえば、ＦＳＰはたとえば印刷された小切手をそのiDraftTM買手および口座保有者へ（iDraftTM取引を介して）販売してもよい。iDraftTM取引の全当事者は、好ましくは、自前でまたは自分たちのiDraft会員のＦＳＰとの合意を通して、iDraft協会の会員である。売手は従来の手段を通してiDraftTMＦＳＰ−買手のペアから支払を受けてもよい。
【００３８】
図２はこの発明の別の局面を概説しており、ウェブ買手がまず自分のホームＦＳＰのウェブサイトにログオンし、自分のホームＦＳＰのiDraftTMソフトウェアにより認証されることによって認証される図１Ｂとは対照的に、ウェブ買手はウェブ売手のサイトまたは電子市場にアクセスした後で認証される。ステップＳ２１に示すように、ウェブ売手はウェブ買手から購入依頼を受ける。たとえば、ウェブ買手はパーソナルコンピュータまたは他のウェブ対応装置を介してウェブ売手のウェブサイトにログオンし、購入する商品を選択し、自分の購入を終える準備をしてもよい。また、これに代えて、ウェブ買手は単にウェブ売手のサイトにログオンし、そして、たとえば認証されること、特に特徴のある商品またはサービスへのアクセスを得ること、または認証されたウェブ買手用に確保されたウェブ売手のサイト内の区域へのアクセスを得ることを依頼してもよい。ウェブ買手とウェブ売手とは次に、ステップＳ２２に示すように、たとえばＳＳＬプロトコル（または何か他の安全で規格化されたプロトコル）に準拠する安全な通信チャネルを確立してもよい。ステップＳ２３によれば、ウェブ売手のサイト（たとえばウェブ売手のホームＦＳＰなどの参加iDraftTMＦＳＰによって維持および管理される、または維持および管理されるようになっている）のＦＳＰiDraftTMソフトウェアが次に、ウェブ買手の識別情報を要請してもよい。そのような識別情報はウェブ買手のＩＤを含んでいてもよく、ウェブ買手のホームＦＳＰの識別情報（ウェブ買手がこのウェブ売手から今回初めて購入する場合）、選択された生体測定データ、および／またはウェブ買手のホームＦＳＰによって要請された他の機密保護情報を含んでいてもよい。しかしながら、識別情報はウェブ買手の暗号化されたパスワードを含まない。なぜなら、そのようなものはウェブ買手のホームＦＳＰにしか伝達されないためである。電子市場への、および／または他の市場参加者へのアクセス権を確立する他のパスワードがあってもよい。識別情報は、ステップＳ２２においてウェブ買手のウェブ対応装置（たとえばパーソナルコンピュータなど）とウェブ売手のサーバとの間に確立された安全な通信チャネルを通して送られてもよい。ステップＳ２４に示すように、ウェブ売手のサイトのＦＳＰiDraftTMソフトウェアは、ウェブ買手の識別情報を受信し、iDraftTM取引を実行する。しかしながら、iDraftTM取引がウェブ買手のホームＦＳＰによって有効として引受けられる前に、ウェブ買手は認証されなければならない。そのため、ウェブ売手のサイトのiDraftTMソフトウェアは、ウェブ買手を（たとえばその人のブラウザソフトウェアを通して）その人のホームＦＳＰ（ウェブ買手によって提供されるその識別情報によりアクセスされる）へ、ここでも安全な通信チャネルを介して接続してもよい。ステップＳ２５に示すように、ウェブ買手のホームＦＳＰのiDraftTMソフトウェアは、ウェブ買手からウェブ買手の暗号化されたパスワードを要請してもよい。ステップＳ２６に示すように、ウェブ買手のホームＦＳＰは次に、提供された暗号化されたパスワードを、ステップＳ２３でウェブ買手により提供されたＩＤに対応する、以前に記憶され暗号化されたパスワードと比較しても��い。上述のＩＤとパスワードの組合せの代わりに、またはそれに加えて、ウェブ買手を認証する他の手段が容易に実現されてもよい。
【００３９】
ウェブ買手のホームＦＳＰの識別情報は、たとえば、ＦＳＰの株式市場の記号であってもよく、それはウェブ買手のホームＦＳＰの安全なウェブサイトのＵＲＬを指してもよい。さらに、ウェブ買手のホームＦＳＰの識別情報とウェブ買手のＩＤとを組合せて、たとえば独特なＦＳＰおよび顧客ＩＤを作り出してもよい。したがって、認証されるべきiDraftTM取引は、ウェブ買手のホームＦＳＰの識別情報、ウェブ買手のＩＤ、購入金額およびウェブ売手の識別情報を含んでいてもよい。iDraftTM取引の認証は、ウェブ売手のサイトのiDraftTMソフトウェアとウェブ買手のホームＦＳＰのiDraftTMソフトウェアとの間のＶＰＮを通して行なわれてもよい。ＶＰＮのパラメータは、ウェブ売手のサイトのiDraftTMソフトウェア（ウェブ売手のiDraftTMＦＳＰによって管理、維持される）およびウェブ買手のホームＦＳＰのiDraftTMソフトウェアそれぞれによってネゴシエーションされ、管理されてもよい。
【００４０】
ここで図２に戻ると、２つの暗号化されたパスワード同士が整合する（および適正なＩＤに対応する）と判断された場合、ステップＳ２７に示すように、ウェブ買手は認証されてもよい。ここでも、ウェブ買手を肯定的に認証する他の手段が、ＦＳＰまたは信用ある主体の裁量で実現されてもよい。ステップＳ２８に示すように、ウェブ買手のホームＦＳＰは、ウェブ売手によりそれへ提示されたiDraftTM取引に対する支払を認可し、または発出する前に、現在認証されているウェブ買手の現在の口座残高または信用限度額をチェックすることを望んでもよい。一旦支払が発出されると、ウェブ買手の口座は、購入金額（プラス、ウェブ買手のホームＦＳＰおよび／またはウェブ売手のＦＳＰからの適用可能なあらゆるiDraftTM手数料）が引き落とされ、ウェブ売手の口座はそれに応じて、購入金額が、あらゆる交渉手数料および／または必須の税金を減じて入金されてもよい。また、これに代えて、選択された支払証書が、ウェブ買手のホームＦＳＰとウェブ買手との間で調整されたように、購入に充てられてもよい。ウェブ売手はこのように、ウェブ買手のホームＦＳＰが為替手形を履行拒絶しないこと（それが認証されたウェブ買手によって認可されているため）、およびウェブ買手のホームＦＳＰへ提示された為替手形に対する支払がなされることを確信する。しかしながら、ウェブ買手が認証されていない場合、またはウェブ買手のホームＦＳＰが課した制約の１つ以上が満たされていない場合には、ウェブ買手のホームＦＳＰへ提示されたiDraftTM取引は失敗する。取引の失敗を確認するため、失敗通知（それ自体が暗号化されていてもよい）が全関係当事者へ作成されてもよい。根底にある取引の失敗にもかかわらず、iDraftTM手数料は、ウェブ買手のホームＦＳＰまたはウェブ売手のＦＳＰのいずれかによって課されてもよい。iDraftTM手数料はまた、成功した取引に関するＦＳＰの一方または双方によって課されてもよい。
【００４１】
ウェブ買手は好ましくは、自分のホームＦＳＰにより、１セッションだけ認証される。つまり、ウェブ買手は好ましくは、ウェブ売手のウェブサイトに次回ログオンする際に再度認証される必要がある。しかしながら、ウェブ買手は、次回にそのウェブ売手から商品を購入する際には、自分のホームＦＳＰの識別情報を必ずしも再入力しなくてもよい。実際、ウェブ売手は、ウェブ買手のＩＤとウェブ買手のホームＦＳＰの識別情報とを、ウェブ売手のサーバ内などのローカルに維持されたマスタファイルに記憶させてもよい。このように、ウェブ買手がウェブ売手のウェブサイトを次回訪れた際には、ウェブ売手は、ウェブ買手がそのホームＦＳＰを変更していないと仮定して、どのＦＳＰがウェブ買手のホームＦＳＰかを知り、ウェブ買手の次の購入についてのさらなるiDraftTM取引の認証についてそのＦＳＰに自動的に連絡を取ってもよい。
【００４２】
ウェブ買手の個人および／または財政情報の機密保護、およびウェブ買手とウェブ売手との間の取引自体の機密保護は、いくつかのレベルで確実とされる。実際、生体測定データおよび／またはＩＤ、パスワードなどの識別情報およびデータの転送に伴うすべての通信は、好ましくは、安全な通信チャネルを通して実行され、暗号化される。さらに、ウェブ買手のホームＦＳＰでウェブ買手のパスワードを暗号化するために使用される暗号方式は、ウェブ買手のホームＦＳＰのディレクトリソフトウェアにしか知らされず、ＦＳＰ自体、ウェブ売手またはウェブ買手には知らされない。この発明によれば、どのウェブ売手も、ウェブ買手のＩＤとウェブ買手のホームＦＳＰの識別情報よりも多くの（暗号化されていない）ウェブ買手からの情報を、ウェブ買手がそのようなものを自発的にウェブ売手に提供しない限り記憶したりまたはアクセスすることはない。これは、氏名、住所、電話番号およびクレジットカード情報の日常的な収集である、現在普及している慣例とは対照的である。この敏感な情報は、この発明によれば、既にそれにアクセスしそれを管理する主体、つまりウェブ買手のホームＦＳＰによって維持される。ウェブ買手の個人および財政情報の流布は、したがって、全く良性のウェブ買手のＩＤとウェブ買手のホームＦＳＰの識別情報とに限定される。加えて、一旦ウェブ買手がホームＦＳＰによって認証され、ホームＦＳＰが為替手形の支払を認可する（為替手形を有効として引受ける、または為替手形を有効として引受けることに同意する）と、ウェブ売手は、自分が実際にウェブ買手のオンライン購入の金額の支払を受けることを保証される。この保証は、ウェブ買手のホームＦＳＰにより、ウェブ売手のサイトのiDraftTMソフトウェアと買手のホームＦＳＰのiDraftTMソフトウェアとの間に確立されたＶＰＮを通して、ウェブ売手へ送られるｅメールの形を取ってもよく、このｅメールは、以前に合意されたあらゆる条件に従ってウェブ売手が支払を受けることを述べている。したがって、ウェブ買手のホームＦＳＰなどの金融機関は、ウェブ買手の財政情報の唯一の保有者および管理者として、および、この発明の実現のため以前に合意された共通規則への準拠を確実にするiDraftTM協会、または他の同様の規格制定および監督機関にそのＦＳＰが属しているウェブ買手とウェブ売手との間のｅコマース取引の機密保護および完全性の保証人として、ｅコマースにおいてより大きな役割を担っている。
【００４３】
ウェブ買手、ウェブ売手およびホームＦＳＰなどの関係当事者間の取引は、それぞれの当事者間の高速接続の恩恵がなくても、大変な速度で実行される。実際、任意の特定の交換中に交換される情報量は、およそ数百バイト程度である。なぜなら、ウェブ売手、ウェブ買手のディレクトリソフトウェアとホームＦＳＰのディレクトリソフトウェアとの間では、ほんの少量の情報しか実際には転送されないからである。実際、ウェブ買手のＩＤとパスワードとを含む暗号化されたメッセージは、約１００バイト以下の使用しか必要としない。ウェブ売手とウェブ買手のホームＦＳＰとの間の通信は、同様に短時間であってもよい。いずれにせよ、ＦＳＰは一般に、この発明により必要とされる少々付加された通信帯域幅を取扱うのに好適である。なぜなら、ＦＳＰは通常、既存の電子取引を取扱うために高速通信ネットワークを維持しているからである。この発明に従った典型的な取引中に交換される情報量は非常に少ないため、当事者が通信する媒体として機能するのにインターネットは好適である。実際、ダイヤルアップ速度（これを書いている時点で約数十キロビット／秒程度）ででさえ、ウェブ買手は非常に迅速に認証され、自分の購入に対するウェブ売手からの（および、したがってウェブ買手のホームＦＳＰからの）確認を十分短時間で受取ることができ、ウェブ買手およびウェブ売手双方のレベルにおいてこの発明の幅広い受入れが促進される。
【００４４】
図３は、この発明の実施例を実行するよう適合されたコンピュータ装置３０１、３０２、３０３、３０４２、３０５２、３０６２、および３０７２のシステムを示しており、コンピュータ装置３０１、３０２、３０３、３０４２、３０５２、３０６２、および３０７２の各々は、ネットワーク３０８に結合されている。コンピュータ装置３０１−３０７の各々は、たとえば図８に概説されたものと同様の構造を有していてもよい。ウェブ買手は、この発明によれば、さまざまなネットワークアクセスチャネル３１０の１つ以上を通してネットワーク３０８にアクセスするパーソナルコンピュータ、ワークステーション、ウェブ対応装置、または他の手段を利用してもよい。そのような手段は参照符号３０１および３０２で包括的に示される。ネットワークアクセスチャネル３１０は、電話回線、専用回線、無線チャネルなどを含んでいてもよい。ネットワーク３０８は、公設ネットワークでも、私設ネットワークでも、または公設および私設ネットワークの混成でもよい、あらゆる種類のネットワークを含んでいてもよい。たとえば、ネットワーク３０８はインターネットを含んでいてもよい。参照符号３０３で示されるウェブ買手のホームＦＳＰのサーバもネットワーク３０８へ接続されており、ディレクトリソフトウェア３０３２によって管理されるデータベース３０３１を含む。この発明に従ったiDraftTMシステムに参加するウェブ売手の各々は、ウェブ買手３０１、３０２にネットワーク３０８を通してアクセス可能なウェブサイト３０７１、３０６１、３０５１、および３０４１を維持する。ウェブ売手の各々はまた、そのそれぞれのホームＦＳＰ３０７２、３０６２、３０５２、および３０４２へもネットワーク３０８を介して結合されている。ウェブ売手のホームＦＳＰ３０７２、３０６２、３０５２、および３０４２の各々は、ウェブ売手のＩＤ、暗号化されたパスワード、財政情報などを含むデータベースを維持しており、そのデータベースはディレクトリソフトウェアによって制御されている。例示を簡潔にするため、図３にはウェブ売手３０４１のデータベース３０４２１とディレクトリソフトウェア３０４２２のみを示す。ウェブ買手３０１とウェブ売手３０４１とがたとえば同じホームＦＳＰ３０４２を共有する場合、ウェブ買手のホームＦＳＰ３０３は省略されてもよく、取引はすべてＦＳＰ３０４２内で起こる。つまり、ウェブ売手３０４１でのディレクトリソフトウェアは、（たとえば）ＬＤＡＰフォーマットされたクエリーがウェブ売手の（およびウェブ買手の）ホームＦＳＰ３０４２へ送られるようにし、そのクエリーは、ウェブ買手３０１によって入力されたように、ウェブ買手３０１のＩＤとウェブ買手３０１のホームＦＳＰ（この場合、ウェブ売手のホームＦＳＰ３０４２）の識別情報とを含んでいる。ＦＳＰ３０４２は次に、ウェブ買手３０１のパスワードを要請し、それを暗号化し、ウェブ買手３０１のＩＤおよび暗号化されたパスワードがそのＩＤに対応する記憶された暗号化されたパスワードと整合するかをそのデータベース３０４２１に照会する。整合が見出された場合、ウェブ買手３０１はこの取引のみについて認証される。その後、ウェブ売手３０４１およびウェブ買手３０���のホームＦＳＰ３０４２は、ウェブ買手３０１の口座をチェックして、ウェブ買手３０１がiDraftTM取引の購入金額およびそれに関連するiDraftTM取引手数料をカバーするのに十分な預金を有しているかどうかを判断する。そうである場合、ウェブ買手３０１の購入についてウェブ売手３０４１によりウェブ売手のホームＦＳＰ３０４２へ提示された電子為替手形は、当事者の共通のホームＦＳＰ３０４２によって有効として引受けられる。つまり、ウェブ売手３０４１へおよび／またはウェブ買手３０１へ通知が発送されてもよく、その通知はＦＳＰ３０４２が実際に為替手形を有効として引受けることを示している。ウェブ売手３０４１はその後、当該商品の発送またはサービスの履行を、それに対する支払を受けることを完全に確信して行なうことができる。
【００４５】
とはいえ、ウェブ売手３０４１とウェブ買手３０１とはしばしば、同じホームＦＳＰを共有していない。ここで、ウェブ買手のホームＦＳＰ３０３とウェブ売手のホームＦＳＰ３０４２とが別々の主体であると仮定する。ウェブ売手のウェブサイト３０４１を訪れると、ウェブ買手３０１はウェブ売手３０４１に、選択された商品および／またはサービスに対する支払として、iDraftTM取引を実行させる。この発明の一実施例によれば、ウェブ売手のウェブサイト３０４１は次に、ウェブ買手のＩＤとウェブ買手３０１のホームＦＳＰ３０３の識別情報とを要請することによって、ウェブ買手３０１の認証を要請する。ウェブ売手３０４１のディレクトリソフトウェアは、そのホームＦＳＰ３０４２によって管理および制御されているが、次に、供給された情報を、ウェブ買手３０１によって識別されたホームＦＳＰへ送る。また、それに代えて、ウェブ買手３０１によって供給された情報（ＩＤおよびホームＦＳＰ３０３の識別情報）は、ウェブ売手３０４１のホームＦＳＰ３０４２へ送信されてもよく、そのＦＳＰ３０４２が認証のために、供給された情報をウェブ買手３０１のホームＦＳＰ３０３へ送る。いずれにせよ、ウェブ買手３０１のホームＦＳＰ３０３は次に、ウェブ買手３０１のパスワードを、安全な通信チャネルを通して要請する。ウェブ買手３０１のホームＦＳＰ３０３は次に、提供されたパスワードを暗号化し、ウェブ買手３０１のＩＤおよび暗号化されたパスワードがそのＩＤについての記憶された暗号化されたパスワードと整合するかを、そのデータベース３０３１に照会する。整合が見出された場合、ウェブ買手３０１はこの取引のみについて認証される。その後、ウェブ買手３０１のホームＦＳＰ３０４２は、ウェブ買手３０１の口座をチェックして、ウェブ買手３０１が購入金額およびそれに関連するiDraftTM取引手数料をカバーするのに十分な預金、または利用可能なクレジットを有しているかどうかを判断する。そうである場合、ウェブ買手３０１の購入についてウェブ売手３０４１によりウェブ買手３０１のホームＦＳＰ３０３へ提示された電子為替手形は、ウェブ買手３０１のホームＦＳＰ３０３によって有効として引受けられる。為替手形に対する支払は即時であってもよく、および／または、ウェブ売手３０４１へおよび／またはウェブ買手３０１へ通知が送られてもよい。その通知は、ウェブ買手３０１のホームＦＳＰ３０３が実際に為替手形を有効として引受けることを示している。ウェブ売手３０４１はその後、当該商品の発送またはサービスの履行を、それに対する支払を受けることを完全に確信して行なうことができる。
【００４６】
しかしながら、多くの取引は、単一の孤立した個別の取引において単一の買手が単一の売手から商品またはサービスを購入する、というようには構成されていない。複雑な取引はしばしば、段階的な履行および段階的な支払、買手および／または売手の側における何らかの行為、または受入れおよび履行についての時間制限を付帯事項とする支払を含む。たとえば、この発明によれば、１組の付帯事項が、送り状の各行項目に関連し、購入注文書の対応する行に参照される場合がある。これは、商品の分割出荷と結果として生じる分割支払とを可能にする。そのような取引は、図１ａ、１ｂ、２および３を参照して詳述された単純な取引モデルには容易には当てはまらないであろう。そのような取引が、インターネットなどの公設ネットワークを通して安全に実行されるには、付帯事項（支払を伴うものであってもなくても）、段階的履行および分割支払などのそのような付加された複雑性を支持可能なｅコマースインフラストラクチャを必要とする。この発明はそのような複雑な取引を、ｉ取引（以下「ｉＴＸ」）と呼ばれるインフラストラクチャを採用することによって支持する。ｉＴＸは、この発明の一実施例によれば、上述のような数々のiDraftTM取引、および／または以下に説明する１つ以上の付帯事項付きiDraftTM取引（以下「iDraftCTM」）を含んでいてもよい。この発明に従ったｉＴＸの構成要素であるiDraftTM取引および／またはiDraftCTM取引は、互いに依存していてもよく、または互いに完全に独立していてもよい。ｉＴＸは、その構成要素であるiDraftTM取引および／またはiDraftCTM取引の各々が成功し、ｉＴＸの成否をｉＴＸの全当事者へ報告することを確実にするフレームワークを含む。成功したiDraftTM取引とは、この発明の一実施例によれば、２つ以上の認証された当事者間で交渉され、支払がなされた電子為替手形として定義されてもよい。iDraftCTM取引とは、この発明の一実施例によれば、それに対する支払の発出が１つ以上の関連する付帯事項の抹消（または、同義では充足）を前提としているiDraftTM取引として定義されてもよい。付帯事項の抹消は、この発明の例示的な実施例によれば、たとえば或る必要な行為の実行（または実行するという約束）、１つ以上のiDraftTM取引の成功した完了、または、或る行為もしくは義務の放棄を含んでいてもよい。したがって、成功したiDraftCTM取引とは、この発明の一実施例によれば、関連する付帯事項がすべて充足され（抹消され）、構成要素であるiDraftTM取引がすべて、iDraftCTM構造により表わされる合意された条件内で有効として引受けられ（たとえば支払われ）または拒否されたiDraftTM取引として定義されてもよい。たとえば、シロアリ報告書の作成にかかった代金は、根底にある不動産取引が失敗しても支払われる。
【００４７】
ｉＴＸの論理構造は、その一例を図４に示すが、実行されるべき根底にある取引のアーキテクチャを反映していてもよい。つまり、ｉＴＸは、一連の関連する支払の各々（各々はたとえばiDraftTM取引を用いてなされる）および／または１つ以上の付帯事項付き支払（各々は、１つ以上の関連する付帯事項が抹消されると、iDraftCTM取引を用いてなされる）を列挙していてもよい。一連のiDraftTM取引および／またはiDraftCTM取引は、iDraftTM取引に関して上に詳述された認証手順を用いて、インターネットなどのネットワークを通して遠隔から実行されてもよい。したがって、そのような取引は、共通の安全なウェブブラウザソフトウェア（または他の適切で安全な通信ソフトウェア）から遠隔で、ユーザの識別情報（たとえば生体測定データ、および／またはＩＤとパスワードのペア）を受入れてネットワークを通し別のコンピュータへ送信する能力を有するあらゆるウェブ対応装置から安全に実行されてもよい。このように、物理的なまたはデジタルの自筆署名に頼ることなく、および敏感な個人情報（たとえばクレジットカード番号など）を公設ネットワークを通して無数のウェブ売手へほぼ無差別に流布することなく、取引上の機密保護が確実とされる。
【００４８】
図４に示すように、この発明の一実施例に従ったｉＴＸ４００は、参照符号４１０、４２０、および４３０で示すような数々のiDraftTM取引を含んでいてもよい。これらのiDraftTM取引の各々は、たとえば、特定された第１の当事者（たとえば買手）が特定された第２の当事者（たとえば売手）になすべき支払に対応していてもよい。また、これに代えて、各iDraftTM取引は取引の各端で多数の当事者に関与していてもよい。iDraftTM取引４１０、４２０および４３０の各々は、同じ当事者、いくつかは同じ当事者、または完全に異なる当事者に関与していてもよい。しかしながら、ｉＴＸのこれらの当事者の各々（および、ひいては構成要素であるiDraftTM取引およびiDraftCTM取引の当事者の各々）は、発出されるべき為替手形に対する支払のため、図１ａ、１ｂ、２および３に関して詳述された態様で認証されなければならない。また、認証は、ｉＴＸ４００の各当事者が自分のホームＦＳＰなどの参加iDraftTM機関に属することを必然的に伴う。図４に示す例では、符号４１０によって参照されるiDraftTM取引１は、所有物に対する頭金についての為替手形を表わしていてもよく、その頭金はｉＴＸ４００（たとえば住宅用不動産取引全体を表わす）が成功するために支払わなければならない。iDraftTM取引２および３（それぞれ参照符号４２０および４３０）は、ｉＴＸ取引４００によって表わされる住宅用不動産取引全体が成功するために、つまり販売が完了されるために各々支払われなければならない他の税金またはサービスの支払についての為替手形を表わしていてもよい。
【００４９】
ｉＴＸ取引４００は、図４に示すように、iDraftCTM４  ４４０およびiDraftCTM５  ４５０によって参照される１つ以上の付帯事項付き支払iDraftTM取引も含んでいてもよい。iDraftCTM取引４４０、４５０の各々は、根底にあるそれぞれのiDraftTM取引に対してなされるべき支払のために満たされるべき（つまり、抹消されるべき）１つ以上の付帯事項を含んでいてもよい。図４の例示的な例では、iDraftCTM４  ４４０は２つの付帯事項、つまり付帯事項４１  ４４２および付帯事項４２  ４４４を含んでおり、一方、iDraftCTM５  ４５０取引は単一の付帯事項５１  ４５２を含んでいる。iDraftCTM４  ４４０取引では、双方の付帯事項４４２および４４４は、iDraftTM４１に対する支払が起こるために満たされなければ（つまり、抹消されなければ）ならない。不動産取引の例を踏まえると、たとえば、付帯事項４１は家屋の構造検査に関連し、一方、付帯事項４２はその電気システムの検査に関係していもよい。iDraftCTM取引４４０の構造によれば、たとえば請負業者へのiDraftTM４１  ４４６に対して支払がなされるためには、家屋の構造および電気システムの双方が検査に合格しなければならない。このため、この例によれば、構造検査官および電気検査官の双方が、ｉＴＸ４００の（および具体的にはiDraftCTM４  ４４０の）当事者または付帯事項抹消者として指定され、各々上述の態様で認証される必要がある。構造および電気システムが検査に合格したと仮定すると、構造および電気システムの検査官たちは、たとえば、エスクローエージェントまたは他の信用ある当事者（たとえば買手のまたは売手のＦＳＰ）によって管理されるウェブサイトにログオンし、それぞれのホームＦＳＰによって上述の態様で認証され、たとえば適切なボックスをマウスまたは他の入力装置のクリックでチェックすることにより適切な付帯事項を抹消する裁量を与えられる。同様に、付帯事項５１はスイミングプールの完了および検査を表わしていてもよく、iDraft５１取引はプールの元請業者への支払を表わしていてもよい。
【００５０】
たとえば構造検査が深刻な欠陥を露呈した場合、その住宅用不動産の販売は完了されず、買手および売手は、根底にある所有物についての支払を交換しないであろう。この発明に従ったｉＴＸ取引はそのような実世界の制約を支持するため、契約の成功（現在の例では住宅用不動産の販売）を、構成要素であるiDraftTM取引およびiDraftCTM取引各々の支払へ、および列挙された各付帯事項がiDraftTM取引に関連していようといまいと満たされること（たとえば抹消されること）へ結び付けている。構造検査が不合格となった場合、付帯事項抹消者（この場合は構造検査官）は構造検査付帯事項を抹消する裁量を行使せず、住宅用不動産取引全体を表わすｉＴＸは失敗するであろう。ｉＴＸ４００の場合、ｉＴＸ４００自体が成功するには、iDraftTM取引４１０、４２０および４３０の各々、ならびにiDraftCTM取引４４０および４５０の各々が（列挙された全付帯事項が抹消され、支払がなされて）成功しなければならない。或る手数料および／または料金が、前払い協定により、ｉＴＸ取引における買手または売手によって支払われてもよい。
【００５１】
図５の参照符号５００に示すように、取引の当事者がｉＴＸ取引を創設させると、この発明に従ったiDraftTMソフトウェアにより、取引の各当事者（および／または、必要に応じ、各付帯事項抹消者）は、自分がｉＴＸへの参加を要請されていることを通知される。この発明の一実施例によれば、そのような通知はたとえばｅメールを介して実行されてもよい。ｉＴＸ取引５００の当事者は、自分が参加を要請されていることを、ｅメール以外の様相を介して通知されてもよく、そのような他の通知様相はすべて、この発明の範囲内に含まれるべきである。図５に示すように、ｉＴＸ５００は少なくとも、根底にあるｉＴＸ取引５００に関与する所有物（またはサービス）の買手、根底にある所有物の売手、エスクローエージェントなどの信用ある当事者、および／または取引に利害関係がある（たとえば必要な）他の当事者に通知する（参加を要請するｅメールを送る）。特に、ｉＴＸ取引５００を管理するＦＳＰがインターネットサービスプロバイダ（ＩＳＰ）として機能する場合、通知は暗号化されてもよい。信用ある当事者は、金融機関（たとえば買手のホームＦＳＰなど）、信用発行特性および開設された口座を有する企業体（たとえば売手の不動産代理店など）、または何か他の公的または政府機関（たとえば郵便局など）であってもよい。利害関係がある当事者は、上述のように、たとえば取引所またはｅコマースサイトであってもよい。利害関係がある当事者の別の例は、付帯事項承認者のそれである。住宅用不動産取引の例では、付帯事項承認者は、取引の根底にある関与する所有物の買手でも売手でもないものの、にもかかわらずそれの必要な当事者である、構造検査官であってもよい。
【００５２】
ｉＴＸ取引５００への参加が要請されていることを通知されると、通知された各当事者（付帯事項承認者を含む）は、好ましくは、iDraftTMシステムによって認証される措置を取らなければならない。認証は、限定された期間のセッション間のみ有効であってもよい。認証されるには、通知された各当事者はまず図１ａに示すステップＳ１１ａ、Ｓ１２ａおよびＳ１３ａを実行する。ここで「通知された当事者」という語句は「ウェブ買手」という語句の代わりに使われてもよく、選択された信用ある当事者は「ホームＦＳＰまたは支店」という語句の代わりに使われてもよい。通知された当事者が既にiDraftTM特権を有する場合（以前に図１ＡのステップＳ１１Ａ−Ｓ１４Ａを実行していた場合）、その当事者はこれらのステップを再度繰返す必要はなく、上述のようにたとえばウェブブラウザを介して遠隔から認証されてもよい。この発明によれば、信用ある当事者（大抵の場合、当事者のホームＦＳＰ）は、ｉＴＸ取引５００の通知された当事者の認証を支持するために必要な文書化された識別情報のレベルを判断する。信用ある当事者への訪問は、物理的に（本人自ら）実行されてもよく、または信用ある当事者のウェブサイトを訪れて、信用ある当事者が満足いくように身分証明を提供することによって実行されてもよい。したがって、ｉＴＸ取引５００の通知された当事者の各々は、上述の態様で、独特のＩＤを受取り、パスワードを選択し、または割当てられてもよい。また、これに代えて、生体測定データまたはＦＳＰに管理された証明書が、ＩＤ−パスポートの組合せに取って代わるかまたはそれを補足してもよい。実際、たとえば多額のお金がiDraftTM取引またはiDraftCTM取引を介して送金される場合、またはＦＳＰが付加された機密保護手段を必要とする他の場合に、進化したさらなる機密保護手段（たとえば証明書の使用など）が買手−売手−ＦＳＰ関係に必要とされてもよい。その場合、そのような証明書は、１回限りの、その取引独自の取引認証証明書であってもよく、または特別の状況に適用されて取引の限度を決める多数回証明書であってもよい。外部からの証明書は通常のｅコマースの自由な流れに不当に負担をかける場合があり、それらの使用は、好ましくは、特別の状況へ追いやられるべきである。外部からの証明書（および／またはiDraftTMＦＳＰ、または上述のような他の信用ある当事者と顧客との間で合意された他の機密保護手段）は、使用される場合、iDraftTMＦＳＰによって顧客に提供されるべきであり、この発明に従った顧客の認証に加えて実施されなければならず、その代わりとしては実施されてはならない。
【００５３】
この発明の一実施例によれば、ｉＴＸ取引５００の構成要素であるiDraftTM取引またはiDraftCTM取引（図５のiDraftTM４１０、４２０、４３０、またはiDraftCTM取引４４０、４５０のいずれかなど）のいずれかが失敗した場合、ｉＴＸ５００自体も、取引の全当事者への通知とともに失敗する。根底にあるｉＴＸ５００が失敗したとしても、ＦＳＰ手数料、技術所有者手数料、iDraftTM協会手数料および他の取引手数料を表わすiDraftTM取引は成功してもよい。図４を再度参照すると、そのような失敗は、ｉＴＸ４００の構成要素であるiDraftTM取引４１０、４２０、４３０またはiDraftCTM取引４４０、４５０のいずれかに対する不払いによって、または、たとえば、認証された当事者または付帯事項承認者が構成要素であるiDraftCTM取引の（たとえば時間ベースの）付帯事項のいずれかを拒否する（付帯事項を抹消する提供された裁量の行使に失敗する、または行使を拒絶する）ことによって引起され得る。失敗通知は全当事者にｉＴＸ取引（および根底にある契約）が失敗したことを通知する。１つ以上の構成要素であるiDraftTM取引４１０、４２０、４３０またはiDrafCtTM取引４４０、４５０の提示に応答して発出される分割支払が、次に、状況の下で適切に、または取引の当事者たちと信用ある当事者との間で以前に合意されたように、保持されるかまたは完全にもしくは部分的に返金されてもよい。信用ある当事者は取引手数料の代わりに発出された支払の一部を保持してもよい。さらに、ｉＴＸが失敗しても、当事者の中には依然としてiDraftTM取引を介して支払を受けるものもいるかもしれない（たとえば所有物検査官など）。
【００５４】
ＦＳＰまたは他の適切な信用発行機関は、ＦＳＰとの買手の合意（買手に供与されるローンの条件など）および／または買手の検索された財政情報（たとえば資金の利用可能性および／または信用限度額）に基づいて、適切な制約を設けてもよい。このため、ＦＳＰなどの信用ある当事者は、iDraftTM（他の点では無条件である支払または支払約束）またはiDraftCTM取引に対してなされるべき支払の規模を制限してもよい。
【００５５】
図６は、この発明の一実施例に従ったｉＴＸ取引の実行フローのフローチャートを示す。そこに示すように、ステップＳ６１は、ｉＴＸ取引の全当事者に、彼らがそれへの参加を要請されていることを通知する。この発明の一実施例によれば、通知は安全な（つまり暗号化された）ｅメールによってインターネット上のＶＰＮを通して実行されてもよい。ｉＴＸ取引の当事者は、たとえば、買手／売手、支払人／受取人、付帯事項承認者、信用ある主体（たとえばＦＳＰおよび／または他のエスクローエージェント）を含んでいてもよい。この発明の一実施例によれば、ｉＴＸ取引の各当事者は（ｉＴＸ取引の創設時および／または認証手順中に各当事者に与えられる許可レベルに依存して）自分と関係がある構成要素であるｉＴＸ取引のすべてまたはその選択された一部を（たとえばウェブブラウザを用いて）遠隔から検査し（つまり閲覧し）、どのiDraftTMおよび／またはiDraftCTM取引がまだ保留中か、もしあれば判断することによってｉＴＸ取引全体の進行を監視してもよい。保留中のiDraftTMまたはiDraftCTM取引は、この発明によれば、根底にある為替手形の名宛人によって支払が発出されていない取引として考えられてもよい。ｉＴＸ取引を検査するのは、その当事者またはそれの付帯事項承認者でなければならず（たとえばそれへの参加を要請する通知を受取っている）、たとえば図１ｂに関して詳述された態様で認証されている。ｉＴＸ取引は次にＦＳＰのソフトウェア（ｉＴＸ取引がＦＳＰによって維持または主催されている場合）によって提示され、認証された当事者たちは、認証手順中に彼らに与えられた特権のレベルに依存して、その当事者に適切ないずれのiDraftCTM取引のいずれの付帯事項も承認および／または否認してもよく、または措置を全く取らなくてもよい。なお、認証された当事者は、たとえば特定の付帯事項を承認または否認するなどの限定された目的のためだけに認証されてもよい。上述の例では、構造検査官は、家屋の構造検査に関する付帯事項を承認／否認するという限定された目的のためだけに認証されてもよく、他の目的のためには認証されない。そのような限定された認証は、認証された当事者または付帯事項承認者がｉＴＸ取引を主催するウェブサイトへログオンした際に目にするｉＴＸ取引の文字または図による表示の範囲も制限してもよい。
【００５６】
ここで図６に戻ると、ステップＳ６２は、ｉＴＸ取引の通知された全当事者が（図５に示す）通知の受取を確認し、認証され、ｉＴＸ取引および根底にある契約に参加する意向を示したかどうかを判断する。通知された全参加者より少ない者しか通知の受取を確認していない場合（Ｓ６２のＮＯ枝路の場合、またはＳ６３のＮＯ枝路によって示されるようにiDraftTM取引およびiDraftCTM取引が全部は成功しなかった場合）に起こるようなｉＴＸ取引の失敗時には、ステップＳ６４に示すように、根底にある取引は、さらなる行為が行なわれるまでその現在の状態で凍結されるであろう。そのような場合、iDraftTM取引またはiDraftCTM取引はどれも実行されず、付帯事項（関与するｉＴＸがそのようなものを含む場合）のいずれかを抹消するどの裁量も行使されない。ステップＳ６５に示すように、ｉＴＸが失敗すると、ステップＳ６６に示すように、以前に通知された全当事者に失敗通知が送られる。にもかかわらず、ステップＳ６７で示すように、ｉＴＸ、iDraftTMおよび／またはiDraftCTM取引手数料は、もしあれば、関与するｉＴＸ取引の失敗にかかわらず、参加iDraftTMＦＳＰおよび／またはiDraftTM協会へ支払われてもよい。しかしながら、ステップＳ６２でｉＴＸ取引の通知された全当事者が彼らのそれぞれの通知の受取を確認し、認証され、彼らのｉＴＸ取引への参加の意向を示すと、この発明に従った方法はステップＳ６３へ進む。ステップＳ６３では、ｉＴＸ取引の構成要素であるiDraftTM取引および／またはiDraftCTM取引がすべて成功したかどうか、つまり、ｉＴＸの完了に対して指定された時間制限内で（そのような時間制限が存在する場合）構成要素であるiDraftTM取引およびiDraftCTM取引すべてに対し、要求される支払がすべて発出されたかどうか、および支払を伴わない付帯事項が（もしあれば）すべて解除されたかどうかが判断される。この発明に従った方法は、矢印Ｓ６３Ａによって示すように、そのような時間制限の満了までステップＳ６３に留まってもよい。各iDraftCTM取引に対する支払は、そのような各iDraftCTM取引の各付帯事項が解除されたこと、または満たされたことを必然的に伴う。ステップＳ６３でｉＴＸ取引の構成要素であるiDraftTM取引およびiDraftCTM取引がすべて実際に成功したと判断されると、ｉＴＸ取引自体が成功と考えられ、それは、ｉＴＸ取引がモデル化されている根底にある物理的な契約または取引が、それ自体成功して完了され、または完了へと実行されたこと（または、取引の成功した完了に必要なすべての先行措置が実行されたこと）を必然的に伴う。ステップＳ６８でｉＴＸ取引が成功すると、ステップＳ６９で述べるように取引の各当事者はそのように通知され、ステップＳ７０に示すように、すべてのiDraftTM、iDraftCTMおよびｉＴＸ取引に対する全支払が発出される。支払はまた、ステップＳ６７に示すように、すべての適切なｉＴＸ、iDraftTMおよびiDraftCTM手数料についてもなされてもよい。そのような手数料は、振出人および名宛人双方としてのＦＳＰ間のiDraftTM取引の形を取ってもよい。
【００５７】
図７は、この発明の一実施例に従ったｉＴＸ取引を実行するよう適合されたコンピュータ装置７００のシステムまたはネットワークを示しており、コンピュータ装置またはネットワーク対応装置の各々はネットワーク７０８に結合されている。図７は、ＦＳＰ、信用発行義務を有する団体、政府機関、または他の取引の信用あるもしくは中立の当事者などの信用ある当事者７０３によって、ｉＴＸ取引が開始され着手されている例を示している。図７の例示的な表示に示すように、関与するｉＴＸ取引の当事者は、買手７０１、売手７０２、および付帯事項抹消者７０４を含んでいてもよく、各々は象徴的にコンピュータ装置によって表わされる。コンピュータ装置７０１−７０４の各々は、たとえば図８に概説されたものと同様の構造を有していてもよい。買手７０１、売手７０２、信用ある当事者７０３、および／または付帯事項抹消者７０４は、この発明の一実施例によれば、さまざまなネットワークアクセスチャネル７１０の１つ以上を通してネットワーク７０８にアクセスするパーソナルコンピュータ、ワークステーション、ウェブ対応機器、または他の手段を利用してもよい。そのようなネットワークアクセス手段は図７に参照符号７０１、７０２、７０３、および７０４で包括的に示される。ネットワークアクセスチャネル７１０は、電話回線、専用回線、無線チャネルなどを含んでいてもよい。参照符号７０３で示される信用ある当事者のコンピュータ（たとえばサーバ）もネットワーク７０８に接続されており、データベース７０３１および／またはディレクトリソフトウェア７０３２を含んでいてもよい。ネットワーク７０８は、公設ネットワークでも、私設ネットワークでも、または公設および私設ネットワークの混成でもよい、あらゆる種類のネットワークを含んでいてもよい。たとえば、ネットワーク７０８はインターネットを含んでいてもよい。信用ある当事者７０３は、この発明の一実施例によれば、ｉＴＸ取引（図４のｉＴＸ取引４００など）の文字および／または図による表示を含むウェブサイトを維持していてもよい。そのようなウェブサイトのＵＲＬまたは他の識別子は、たとえば、関与するｉＴＸ取引の要請された参加者の各々へ送られる暗号化されたｅメール通知（図５に示す）に有利に含まれていてもよい。信用ある当事者のウェブサイトへログオンした後、ｉＴＸ取引の各当事者および／または付帯事項抹消者は、たとえば図１ａ、１ｂおよび２に関して説明された態様で、信用ある当事者のディレクトリソフトウェア７０３２およびデータベース７０３１を通して認証されてもよい。関与するｉＴＸ取引の構成要素であるiDraftTM取引およびiDraftCTM取引の取引上の機密保護を確実にするために、信用ある当事者７０３との通信は、ＳＳＬプロトコルに準拠した、または他の安全な通信プロトコルに準拠したネットワークアクセスチャネル７１０を介して実行されてもよい。しかしながら、この発明は、その範囲において、いかなる特定のデータ暗号方式または安全な通信プロトコルにも限定されない。なぜなら、好適な暗号方式または通信プロトコルは、当業者には周知であるためである。
【００５８】
ディレクトリソフトウェア７０３２によって与えられる許可レベルに依存して、ｉＴＸの当事者（および付帯事項抹消者）の各々は、ｉＴＸ取引のすべてまたは選択された部分を閲覧して付帯事項を抹消する（または拒否する）裁量を行使し、および／またはたとえばｉＴＸ取引の現状を閲覧してもよい。たとえば、買手７０１と売手７０２の双方はｉＴＸ取引全体を閲覧する許可を与えられてもよいが、一方、付帯事項抹消者７０４は、その人が承認または否認を課された付帯事項を閲覧し、承認または否認することと調和した許可レベルを与えられるであろう。ここに詳述された態様でディレクトリソフトウェアを用いることは、複雑な取引が匿名ではあるが安全なやり方で完了されることを可能にするため、有利である。実際、買手の財政情報へのアクセスは、信用ある当事者７０３（たとえば、その情報に既にアクセスし、それを守る対策を確立している買手のホームＦＳＰなど）に限定されていてもよい。これにより、買手７０１は、iDraftTM取引および／またはiDraftCTM取引を通してＦＳＰ７０３へ提示された為替手形が、ＦＳＰが課す制約（たとえば十分な預金の欠如など）を除外して、有効として引受けられるという完全な保証を売手７０２に提供する間ずっと、売手７０２へ洩らされる個人情報を制限することができる。このため、取引上の機密保護は保証され、買手および売手ならびにｉＴＸ取引の他の当事者は、匿名のやり方、匿名に準ずるやり方、または公開されたやり方で対話することを選択することにより、流布される個人情報の量を選択的に制限してもよい。たとえば、匿名モードでは、当事者たちはたとえば彼らのＩＤだけによって識別されてもよい。ＦＳＰは出荷会社と連絡を取って買手により購入される商品の発送を調整し、このため買手の匿名性をさらに保護する。この発明の発明者による同時係属中の、共通に譲渡された米国特許出願「ｅドロップシップ：匿名ｅコマース出荷のための方法およびシステム」（“eDROPSHIP: Methods And Systems For Anonymous eCommerce Shipment”）（譲渡連続番号第０９／４９０，７８３号、提出日２０００年１月２４日）に開示され、および／または主張されている出荷メカニズム（ここに引用により援用する）が、出荷者の匿名性を保護するために有利に使用されてもよい。このように、買手は売手が自分の住所を知ることを防止できる。合法的な目的および法執行の目的のため、ＦＳＰは各取引の文書での痕跡または他の耐久性のある記録を保持してもよい。さらに、ｉＴＸの根底にある所有物の権利所有権（たとえば上に展開した不動産の例を用いると、土地の経緯の証書）は、ｉＴＸ取引全体が成功したときのみ、たとえば図６のフローチャートのステップＳ６２に示すｉＴＸ成功通知が受取られたときのみ、売手７０１によって移管されてもよく、それは、上に詳述した態様で、すべての付帯事項が解除され、すべての支払が、iDraftTM取引またはiDraftCTM取引にかかわっていようといまいとなされて、適切な口座に入金されたことを示す。また、これに代えて、根底にある所有物の権利所有権は、買手のＦＳＰであってもよい貸手に渡されてもよく、ｉＴＸは同様に成功する。さらにそれに代えて、第三者または取引所が、ここに詳述されたiDraftTMメカニズムを用いて、買手、売手、およびＦＳＰを接続してもよい。
【００５９】
以下の実現化例は、iDraftCTM取引が、特定された付帯事項を条件として、買手により認可される際の関係当事者間の相互作用の連続を示す。本人の自筆署名を用いる現在の慣例とは異なり、以下の実現化例では、iDraftCTMおよび／またはｉＴＸTM取引の全当事者は、適切で安全な措置を遠隔から（たとえばインターネットを通してウェブブラウザソフトウェアから）行なってもよい。さらに、クレジットカード番号（または同様の敏感で悪用されるおそれのある個人情報）をウェブサイトでの認証用に用いる現在の慣例は、この発明に従ったiDraftCTMおよび／またはｉＴＸTM取引の使用により不必要となる。iDraftCTMおよび／またはｉＴＸTM取引は、関連する一連の相互依存する付帯事項付き支払に採用されてもよく、各支払は、取引のそれぞれの当事者により規定された１つ以上の付帯事項の解除によって論理的にひきおこされる。
【００６０】
実現化例１：オンラインオークション
オンラインオークションの例では、多数の買手が売手によりウェブサイトを通して販売される１つ以上の物件またはサービスに入札する。買手も売手も不必要に個人情報を流布したくはないが、各々は、他方の当事者が履行するという何らかの保証を望んでいる。つまり、落札したオークションの買手は、自分の機密情報を保護することを望み、当該商品が売手の記載どおりのものだと確信することを望み、購入した商品を売手が実際に適時に配送するのを確信することを望んでいる。売手もまた、関与する商品を発送する前に、入札額が適正に自分の口座へ入金されるという何らかの保証を必要としている。しかしながら、双方の当事者は、クレジットカードおよび／または社会保障番号などの識別情報の代理に頼ることなく、彼らそれぞれの個人情報の流布を防ぎ、制限することを望むであろう。この発明は、このような必要事項を満たすために、図４の参照符号４００で示すようなｉＴＸ取引を通してiDraftTM取引および／またはiDraftCTM取引を含むインフラストラクチャを提供する。これを行なうため、この発明によれば、オークションの買手（以下「買手」）は、オークションウェブサイトにログオンし、自分のホームＦＳＰの識別情報と個人ＩＤとを、ＳＳＬを通し、適切なブラウザソフトウェアを介して供給することによって認証される。オークションサイトのディレクトリソフトウェア（この例ではオークションサイトのホームiDraftＦＳＰにより提供、維持および制御される）は次に、買手の認証を買手のホームＦＳＰから要請してもよく、買手のホームＦＳＰ自体のディレクトリソフトウェアが、オークション買手のパスワードを要請し、提供されたパスワードを暗号化し、オークション買手により提供されたＩＤおよび暗号化されたパスワードを、そのＩＤについての整合する記憶された暗号化されたパスワードと比較する。オークション買手のホームＦＳＰに記憶された暗号化されたパスワードとＩＤのペアが、買手により提供されたＩＤとパスワードのペア（パスワードは買手のホームＦＳＰによって暗号化されている）と整合する場合、買手はこのセッションのみについて認証される。機密保護を維持するため、オークションウェブサイトのＦＳＰはまた、たとえば買手のホームＦＳＰのサーバでオークションサイトのウェブドメインを主催していてもよく、これは買手には認識されないことである。
【００６１】
一旦認証されると、買手は売手から購入する商品を選択し、例示的な目的だけのため、落札したと仮定する。買手は、商品が売手の表示どおりのものである（たとえば性質、量、状態）ことを確認したがっている。他方、売手は、買手が合意どおりに支払うことを確認したがっている。この発明によれば、買手は、iDraftCTMがオークションサイトソフトウェアを介してエスクローエージェント（たとえば中立の当事者、オークション会社または買手のホームＦＳＰであってもよい）へ送られるようにする。エスクローエージェントは次に、買手のホームＦＳＰに確認し、購入される商品に関連するiDraftCTMを支払うのに必要な資金を確保した（たとえばエスクローとして第三者に預託した）後で、第１の付帯事項（買手の支払）を解除してもよい。売手は次に、第２の付帯事項（買手がその日までに第３の付帯事項（買手の審査）を解除しなければならない申入れ期日の満了）を条件として、当該商品を買手へ送ってもよい（またはエスクローエージェントを通して商品を買手へ送ってもよい）。ここで、買手が第２の付帯事項により特定された期間内に商品を審査し、その商品が満足いくものであると見出したと仮定すると、買手はオークションウェブサイトのiDraftTMページにログオンし、上述の態様で自分のホームＦＳＰを通して認証され、当該iDraftCTM取引の第３の付帯事項を解除する裁量を選択してもよい。エスクローエージェントは次に（たとえば暗号化されたｅメールを介して）自動的に通知され、次に第２の付帯事項を解除する裁量を行使してもよい。iDraftCTM取引の第１、第２および第３の付帯事項がここで解除されたので、買手のホームＦＳＰはiDraftCTM支払を特定された売手の口座へ、およびエスクローエージェントの手数料がもしあればそれを特定されたエスクローエージェントの口座へ、自動的に入金してもよい。これは、これがデビット取引かクレジット取引かに関する買手の指示を用いて行なわれてもよい。なおここでは、この発明は、支払の達成に利用されるまさしくその支払証書に関係なく、広く利用可能である。実際、クレジットカード支払、電信送金または他の支払証書がこの発明のインフラストラクチャ内で実施されてもよい。
【００６２】
申入れ期日が満了した場合、iDraftCTM取引支払がたとえば買手のホームＦＳＰにより資金提供されなかった場合（限度を超えた支出または利用可能な資金の不足いずれかのため）、または商品が売手の表示どおりではないと買手が判断した場合などの付帯事項の拒否は、iDraftCTM取引を失敗させる。その場合、支払うべき手数料は、買手（および／または、売手が手数料を供託するのに同意していた場合は売手）から自動的に収集されてもよく、買手のホームＦＳＰは、エスクローエージェントが検査された商品を受取っていること、および新しい取引期日が満了していないことを付帯事項として、iDraftCTM取引を買手へ送ってもよい（エスクローとして第三者に預託された金額から経費を引いた分の返金）。
【００６３】
実現化例２：不動産取引
不動産販売は、iDraftTMシステムの会員であるエスクローエージェントなどの信用ある当事者を通して取扱われてもよい。エスクローエージェントのＦＳＰ（エスクローエージェントとＦＳＰとは同じものであってもよい）は、エスクローエージェンシーの選択された従業員（エージェント）を、ＩＤおよびパスワードの作成時に信用ある当事者（たとえばＦＳＰ）のディレクトリソフトウェアを通して割当てられた適切な特権を持たせて登録してもよい。エスクローエージェントは、証書における必要な全付帯事項を含み、他の全資金が分配され他の全付帯事項が抹消された後で最終支払が売手により受取られると仮定した、不動産の売手への付帯事項付き支払として、iDraftCTM取引を自分の口座から創設してもよい。エスクローエージェントは、上述のiDraftCTM取引と、ローンの払戻、不動産に対する手数料または債務の支払、不動産販売手数料の支払などの他の当事者へのiDraft取引とを含むｉＴＸTM取引を創設してもよい。iDraftCTM取引は、何らかの支払がたとえば小切手、債務免除、または配偶者の権利放棄によってなされる支払付帯事項の抹消を可能にしてもよい。iDraftCTM取引に対してなされる支払は、意図された受取人のＦＳＰが一旦支払を受取ると、iDraftCTM取引の対応する付帯事項を自動的に抹消してもよい。
【００６４】
買手による検査は大抵、どのような不動産取引でもその一部であり、買手（または指定された付帯事項抹消者）はそのような付帯事項を、たとえば自分のブラウザソフトウェアを介して、エスクローエージェントのサイトの保留中のiDraftCTM取引にアクセスすることにより、およびたとえばiDraftTMシステムソフトウェアにより提示されている「付帯事項抹消」ボックスをチェックすることによって付帯事項を解除する裁量を行使することにより、遠隔から抹消してもよい。
【００６５】
この発明の一実施例によれば、付帯事項に関連するすべての行為は、裁量の所有者のホームiDraftTMＦＳＰで行なわれてもよい。そこには、iDraftTM付帯事項関連メッセージが、保留中のiDraftTM取引と同様の態様で記憶されている。付帯事項関連メッセージは保留中のiDraftTM取引とは別に分類されてもよい。さらに、付帯事項関連メッセージはそれら自体、iDraftTM口座保有者の承認を待つ保留中のiDraftTM取引であってもよい。裁量の所有者が今のところ、iDraftTM特権を有するiDraftTMＦＳＰでの口座保有者でない場合、所有者は、そのようなｉＴＸTM、iDraftTM−ＣまたはiDraftTM取引に参加するために、そのようなＦＳＰでの口座保有者となり、iDraftTM特権を要請しなければならない。
【００６６】
頭金としてエスクローエージェントにより受取られる資金は、不動産取引全体（およびそれについてモデル化されたｉＴＸTM取引）が何らかの理由で失敗した場合の（少なくとも部分的な）払戻を条件として、買手からのiDraftTM取引支払として実現されてもよい。そのようなｉＴＸTM取引はおそらく無条件支払（iDraftTM取引）と付帯事項付き支払（iDraftCTM取引）の双方を含んでおり、構成要素であるiDraftTMおよびiDraftCTM取引すべてが成功し、支払われた場合のみ、成功してもよい。さもなければ、エスクローエージェントは、たとえば無条件支払（iDraftTM支払）を適切な当事者へ、任意の適切な取引手数料を減じて送ることにより、iDraftCTM取引合意に従って全資金を返却してもよい。
【００６７】
iDraftCTM管理信用状（iLofCTM）
iDraftCTMおよび／またはｉＴＸTM取引に関連するすべての付帯事項が解除された場合に、ＦＳＰが安全に売手または売手のＦＳＰへの支払を約束できるようにするには、iDraftCTMは、好ましくは、買手のＦＳＰが保留中の取引に対する必要な支払を行なうのに十分な買手の口座内の資金を仮差押えする（エスクローとして第三者に預託する）ことを必要とし、支払は、取引に関連するすべての付帯事項が抹消されたときのみ発出される。この発明は、iDraftCTM信用状つまりiLofCTMと呼ばれる代替的なメカニズムも提供している。信用状は一般に、クレジットにおけるすべての条件（前もってＦＳＰと預金者との間で合意されている）が満たされた場合に為替手形および／または他の支払請求を有効として引受ける、というＦＳＰによる約定を指す。そのような条件は、たとえば、或る期間または不定期間の間、iLofCTMを取消不能または取消可能にしてもよい。条件は、ＦＳＰがこの発明に従ったiDraftTM、iDraftCTMおよび／またはｉＴＸTMに対する支払を発出する前に明記された文書を提示するという要件などの制約を、買手および／または売手に課してもよい。iLofCTMはＦＳＰによってその預金者の１人に発行されてもよい。iLofCTMはiDraftTMの下で管理された預金者の口座へ連結されていてもよく、購入を支持するのに十分な資金が利用可能かどうかを判断するためにその口座の価値を高めるよう機能する。
【００６８】
有利なことに、この発明によれば、明記された文書はオンラインで、バージョン制御され、全関係当事者によって承認され、iLofCTM取引の不可欠な部分を構成している。将来の承認を条件とする明記された文書における要素（出荷の受取および送り状の承認など）は、好ましくは、付帯事項の所有権において暗示された特権の保有者による付帯事項入力を介して取扱われる。実際、編集された文書は、好ましくは、元々の未編集の文書と同じ当事者による承認を必要とする。改訂レベルについての承認プロセスは、抹消された場合に改訂版および／または編集された文書の承認を暗示する付帯事項を含んでいてもよい。多くの従来の取引は、文書が正確には整合していないために失敗している。この発明によれば、全当事者によって承認されたオンライン文書の使用は、この問題を治癒し、ここに説明するiLofCTMメカニズムへ多大な機能性を付加する。
【００６９】
この発明に従ったiLofCTMが買手の口座に付加されると、買手は、買手がiDraftTMおよび／またはiDraftCTMを通して現金勘定ベースで支払うことを約束した場合に起こるであろう既存の資金の支配権を失うということはない。ＦＳＰは口座へ連結されたiLofCTMに対する利子を請求しないかもしれない。むしろＦＳＰは、iLofCTMサービスについての手数料を請求してもよく、十分な資金が利用可能で、付帯事項が抹消された際にiLofCTMの信用限度額を条件として支払われるということを売手に約束してもよい。iLofCTMメカニズムは有利に、売手が、買手よりもＦＳＰの支払約束、支払能力および評判に頼ることができるようにする。付帯事項が抹消された際に買手の口座に必要な支払をカバーするのに十分な資金がない場合、iDraftTMおよび／またはiDraftCTMを通した実際の支払は、口座保有者とＦＳＰとが前もって、iLofCTMにおいて具体的に建議されるように合意したiLofCTMのローン規約をひきおこすであろう。買手の口座における資金額およびiLofCTM規約のひきおこしはすべて、好ましくは、売手には認識されず、売手はＦＳＰの支払約束のみを見るべきである。
【００７０】
購入の種類、時間制限の有効性および他の条件、商品、および売手はすべて、iDraftCTMのためにiLofCTMにおいて特定されていてもよく、そのような情報は十分な資金の判断の一部であってもよい。ＦＳＰがiLofCTMを発行するのに先立って、およびiLofCTMをひきおこし得る任意の所与のiDraftCTM支払が実行される前に、ＦＳＰと買手とはクレジット協定を結ばなければならない。買手は、支払が発出される前のいかなる時点でも、iLofCTMとは独立してiDraftCTM支払をカバーするのに十分な資金を自分の口座に付加することによって、iLofCTMクレジット協定の発効を回避してもよい。
【００７１】
ＦＳＰは、iLofCTMの条件を、それが１回の使用（単一取引）用に利用可能か、その使用後に更新可能かに関して設定してもよい。ＦＳＰはiLofCTMの使用についての手数料を請求してもよく、iLofCTMが口座へ連結されている場合にこの手数料が支払われる（たとえばiLofCTM保有者の口座から引き落とされる）ことを要求してもよい。なお、iLofCTMは決して支出されない。むしろそれは、ＦＳＰと結んだクレジット協定がiLofCTMを支持するのに十分であるという仮定に基づいた、ＦＳＰの支払約束を表わしている。iDraftCTMおよびiLofCTMを通して購入された商品は、それ自体が別のローンの担保であってもよい。ＦＳＰは、名宛人（売手）へ発出される支払と引換えに、振出人（買手）によって受取られる商品における担保権を与えられてもよい。
【００７２】
この発明に従ったiLofCTMを有するiDraftCTMを用いる１つの利点は、ＦＳＰがiLofCTMにより表わされる信用状を支配および管理して、信用状の保有者による意図せぬまたは無許可の使用を防止し、保有者が信用状の現状の会計にアクセスできることを確実にし、信用状の根底にあるクレジット協定が適切にそれと結び付けられることを確実にするということである。売手（為替手形の名宛人）は好ましくは、iLofCTMを閲覧、アクセスしたりまたは知ることはない。むしろ、買手の支払能力は、買手のＦＳＰが関与する商品の配送および受入（および売手と買手との間で合意されたような他の要因）を付帯事項とする支払約束をすることによって証明される。売手は次にＦＳＰの支払約束を有し、買手の身元およびその人の信用度（または、その開示を全部ここに援用する、同時係属中の、共通に譲渡された米国特許出願「ｅドロップシップ：匿名ｅコマース出荷のための方法およびシステム」（連続番号第０９／４９０，７８３号、２０００年１月２４日提出）の規定によればその人の住所）すら知らずに、商品をしかるべく出荷してもよい。このように、売手は、iDraftCTMメカニズムを通したおよび／またはここに説明されたiLofCTMメカニズムを認識しないまま通した、要請された商品および／またはサービスに対する買手の支払能力を別にすれば、買手について何も知る必要がない。
【００７３】
図９は、この発明の一実施例に従ったiLofCTMの操作のフローチャートである。Ｓ９１に示すように、買手（オンライン取引の根底にある為替手形の振出人）はiLofCTM信用状の条件を交渉する。また、これに代えて、買手は、自分のＦＳＰまたは自分が権限を与えている他の信用ある主体によって提供された複数の予め構成されたiLofCTM金融商品の中から単に選択してもよい。Ｓ９２に示すように、iDraftCTM、iDraft-CTMおよび／またはｉＴＸTMが、図１−７に関して上に詳述したように、商品および／またはサービスの購入のために開設される。ステップＳ９３は、買手が、売手へ発出されるべき全支払を、ステップＳ９１において開設されたiLofCTMから生じさせるよう選択したかどうかの判断を必要とする。この選択により、ＦＳＰに預けられた買手の資金は、買手にとって他の目的用に利用可能なままとなり、ＦＳＰが、少なくとも買手になされるべき支払に等しい、ＦＳＰに預けられた買手の資金額を仮差押えして利用できなくすることを防止する。また、これに代えて、ステップＳ９３は全く省略されてもよい。買手が売手への全支払を自分の口座へ連結されたiLofCTMから行なうことを選んだ場合、Ｓ９５に示すように、ＦＳＰは、支払がオンライン取引の売手へなされる際に、ステップＳ９１で交渉されたiLofCTMの条件に従って買手にクレジットを供与する。実際、ＦＳＰはそれ自体の資金から引出す（および対応して買手にクレジットを供与する）ため、ＦＳＰがいくらか後の時点で売手へ支払を発出することを予期してそれ自体の資金を仮差押えする必要はないであろう。買手が売手へなすべき全支払をiLofCTMから生じさせることを選択しなかった場合、ステップＳ９４が実行されてもよい。ステップＳ９４では、買手が売手へ発出されるべき支払をカバーするのに十分な資金をＦＳＰに預けているかどうかが判断されてもよい。買手が売手へなすべき全支払をカバーするのに十分な資金をＦＳＰに預けていない場合（Ｓ９４のＮＯ枝路）、Ｓ９６に示すように、売手へ発出されるべき支払の一部のみが買手の口座から仮差押えされてもよい。売手へ発出されるべき資金の残高は、Ｓ９６Ａに示すように、買手のiLofCTM信用状から引出されてもよい。十分な資金が実際に買手のＦＳＰの口座から利用可能である場合には、Ｓ９７に示すように、少なくとも売手へ発出されるべき全支払に等しい金額が買手の口座から仮差押えされてもよい。ＦＳＰは、この発明の方法のどの段階でも、手数料を課してもよい。たとえば、買手の口座から資金を仮差押えする際に、ＦＳＰは予め取決められた手数料をそこから仮差押えしても、および／または引き落としてもよい。
【００７４】
ステップＳ９８では、特定された事象の発生時に自動的に、または付帯事項を抹消する権限を有する適切に認証された個人の肯定的な行為によって、すべての付帯事項が抹消されたかどうかが判断されてもよい。たとえば、オンライン取引の成功は、買手が売手から商品を受取った後で商品を検査するための特定された時間期限などの期日および／または時間付帯事項を満たすこと、または抹消することに依存してもよい。この筋書では、適合するまたは受入可能な商品の買手は、ＦＳＰが主催する安全なウェブサイトにログオンし、認証され、オンライン取引の現状を安全に閲覧し、「検査」付帯事項を抹消し、それにより仮差押えされた資金からの、および／またはiLofCTM信用状からの売手への支払の発出をひきおこしてもよい。また、これに代えて、商品が出荷されたと売手が示してから特定された期間たつと、期日および／または時間付帯事項が時間切れとなってもよい。付帯事項の性質はオンライン取引の構造によってのみ限定される。すべての付帯事項が抹消された後、Ｓ１０２に示すように、支払が売手へ発出されてもよい。付帯事項が全部は抹消されていなかった場合、Ｓ９９に示すように、期日および／または時間制限が超過されたかどうか、および／または１つ以上の付帯事項が失敗したかどうかが判断されてもよい。たとえば住居の購入に振出されるオンライン取引の場合、住居検査付帯事項が失敗したかも知れず、または家屋検査官が家屋検査付帯事項を適時に抹消しそこなったか、もしくはどういうわけかそれを無視したかもしれない。付帯事項が全部は抹消されてはおらず、どの付帯事項も時間切れとなったりまたは別様に失敗していない場合、ステップＳ９８が上述のように繰返されてもよい。付帯事項が抹消されていなかった場合、および／または付帯事項のうちの１つが時間切れとなったかまたは別様に失敗した場合、この方法は直接ステップＳ１０１へ進んでもよく、そこで取引が失敗に終わる。この方法はまた、自由選択のステップＳ１００へ進んでもよく、そこでは図１１のステップＳ１０５および後続のステップが以下に詳述されるように実行され、ステップＳ１０１がそれに続いてもよい。
【００７５】
iDraftTM契約履行保証（iPBondTM）
iDraftTM契約履行保証機能（iPBondTM）はiLofCTMと非常に似ている。買手の口座にiLofCTMが既にある場合、iPBondTMは、その口座へ連結していてもよく、またはしていなくてもよい。買手（根底にある為替手形の振出人）と売手（根底にある為替手形の名宛人）とが、買手が（付帯事項を拒否することにより）商品またはサービスの購入を取消さないという合意を破った場合の売手への損害額がiLofCTMの信用限度額および／または既に購入用に充当された仮差押えされた資金を上回り得る、ということに合意している場合に限り、iPBondTMは買手の口座へ預けられるかまたは他のやり方で連結されるであろう（その条件が買手と買手のＦＳＰとの間で交渉された後で）。この場合、iPBondTMは、買手側の不履行の場合に（たとえば清算損害額の形で）売手に損失を補償するよう機能する。売手は好ましくは、iPBondTMを見たり、アクセスしたり、または知ることはない（売手自身が買手側の不履行に対抗して別個のiPBondTMを確保していない限り）。さらに、買手が履行を怠った場合、iPBondTMをひきおこすことは、売手（iPBondTMの受取人）には全く認識されなくてもよい。売手は、iLofCTMの場合と同様に、買手のＦＳＰの支払約束のみを見る。理由のいかんを問わず、保留中の購入を実行する能力が不十分である場合、買手のＦＳＰは買手および売手に通知してもよい。
【００７６】
しかしながら、iPBondTMの別の目的は、売手による不履行から買手を保護することである。この場合、売手のＦＳＰはiPBondTMを売手の口座へ連結させ、このiPBondTMの条件はそれぞれの当事者間で交渉されている。そのような不履行の例は、商品の高騰市況における販売である。買手は自分が購入時に公正な取引として、そして後になって（売手から買手への商品の予定された出荷の直前に）よりよい取引として認めるものを獲得したかもしれない。iPBondTMがなければ、売手は販売を不履行にし、商品を約束どおり出荷することをやめたくなるかもしれない。このことにより、そのような売手は、買手による購入時点と商品を比較的より高い価格で別の買手へ販売した時点との間で評価されるような、そのような商品の販売についての市場価格の差からの割増金を収集できるであろう。この発明に従ったオンライン契約履行保証は、そのような挙動を、買手との合意に従って履行するために（たとえば清算損害額の形の）組込まれた報奨金を売手へ提供することによって思いとどまらせる。売手の口座に預けられたiPBondTMは、買手および売手により、価格および条件に関する彼らの合意を承諾するよう調節されてもよい。つまり、どのような売手の不履行も、買手と売手との間の合意どおりにiPBondTMに頼ることによってカバーされるであろう。
【００７７】
売手による不履行の理由は他にも多数あるであろう。これらは火事、天災、ストライキ、事故、および、売手の手に負える、および手に負えない他の事象を含む場合があり得る。しかしながら、買手は、購入した商品がそれにもかかわらず手に入るという何らかの保証を必要とするかもしれない。ＦＳＰおよび／またはその提携者は、売手および売手の過去の実績の知識から、履行の危険を承諾するかもしれない。ＦＳＰとその提携者（もしいれば）は、手数料を売手から（iPBondTMが売手の口座に預けられている場合）または買手から（iPBondTMが買手の口座に預けられている場合）収集してもよい。
【００７８】
iPBondTMは、この発明によれば、買手および売手の双方にとって有用であろう。実際、iPBondTMは、買手と売手との間の根底にある合意における条件、および／または当事者間の根底にある取引を履行する合意を履行しないよう構成されていてもよい。不履行の例は、売手が取引の根底にある商品を善意で出荷したにもかかわらず、買手が付帯事項を適時に抹消しなかったことであろう。同様に、当事者間での合意どおりに出荷しなかったことは、売手側における不履行を構成するであろう。合意により、双方の当事者は、合意の条件を遵守するために、または商品を出荷しおよび／または特定されたサービスを提供するためにより多くの時間を付加してもよい。この発明によれば、iPBondTMの不履行は、取引の当事者間の根底にある合意の条件の不履行、および任意の付帯事項に関する不適切な行為であり得る。何が不履行を構成するかに関する合意は、iPBondを支持する文書の１つ以上において現われるべきである。また、条件は交換される商品および／またはサービスの十分かつ完全な（合意による）説明を有する文書を伴うことも理解されたい。
【００７９】
買手と売手とはそのようないずれのiPBondTMの範囲を設定してもよく、ＦＳＰは、当事者間で交渉され、iDraftTM購入時に設定された指示および／または予め定められた条件に従って、それが管理する口座におけるiPBondTMを管理してもよい。iPBondは、各当事者が行なう他方の当事者による起こり得る不履行に起因する損失の危険の評価に依存して、任意のiDraftTM参加ＦＳＰ、金融機関から、または買手もしくは売手のいずれかにより認可されたＦＳＰの代理人の役割を果たす仲介機関から保護されてもよい。iPBondTMから資金を収集するための手順は、買手のおよび／または売手のそれぞれのＦＳＰによって設定されるであろう。iDraftTM  iPBondTMは、ＦＳＰがiPBondTMを預かって管理するようなソフトウェア機能を提供する。つまり、iDraftTMはそれ自体、何の条件も強要せず、またはＦＳＰなどの信用ある主体による管理から離れて機能することはない。
【００８０】
買手がオンライン取引の条件に従って評価されるように履行しなかった場合、買手のＦＳＰは、清算損害額を売手に支払うために、買手の口座から十分な資金を仮差押えしてもよい。買手のＦＳＰが為替手形に対する支払を発出するのに、または清算損害額を売手へ支払うのに十分な資金が買手の口座にない場合、買手と買手のＦＳＰとの間で交渉された条件に従って、iLofCTMが創設され、買手にクレジットが供与されてもよい。十分な資金が買手の口座にある場合でも、iLofCTMに備わっているクレジットは同様に、買手と買手のＦＳＰとの間で合意されたように買手に供与されてもよい。言換えれば、iLofCTMは、この発明によれば、買手または売手の口座において資金が利用できないことに基づく必要はない。iLofCTMの創設および維持のために手数料が買手に対して課されてもよく、その手数料は買手のＦＳＰに預けられている買手の資金から引き落とされてもよい。このように、iPBondTMおよびiLofCTMは協調して働いて、資本へのより大きなアクセスを買手に提供し、かつ、買手が違反した際に清算損害額の補償を売手に提供するであろう。
【００８１】
同様に、iPBondTMは売手のＦＳＰによって創設され、売手へ連結されてもよい。売手がオンライン取引の条件に従って履行しなかった際に、買手に支払うべき清算損害額の支払をカバーするために十分な資金が売手の口座にない場合、iLofCTMが創設されて、予め定められた条件に従って売手にクレジットを供与してもよい。このように、売手の不履行時に、iPBondTMに規定された、買手に支払うべき清算損害額の少なくとも一部が、iLofCTMの下で売手に供与されたクレジットから生じてもよい。買手および売手は、同じまたは異なるＦＳＰ（または独特に識別された口座を保持する何か他の信用ある主体）に口座を保持していてもよい。iLofCTMが或る当事者の口座へ連結され、数々のオンライン取引（その条件に制約される）についてクレジットを供与するのに有効であり得る一方、iPBondTMは、各当事者（または当事者の一方）が他方の当事者の不履行時に自分のリスクエクスポージャーを制限することを望む高値の取引に対してのみ創設されてもよい（が、創設される必要はない）。
【００８２】
図１０は、この発明の一実施例に従ったiPBondTM契約履行保証の１つの可能な操作、および上に詳述したiLofCTM信用状メカニズムとのその関連および相互作用を示している。図１０に詳述された方法は、図９の方法とともに実行されてもよく、またはそれとは全く独立して実行されてもよい。図１０のＳ１０３に示すように、買手と売手、および／または彼らのそれぞれのホームＦＳＰ（買手のＦＳＰと売手のＦＳＰ）は、１つ以上のiPBondTMの条件を交渉してもよい。たとえば、買手と売手の双方が別個の契約履行保証を掲示することに合意し、一方は買手のＦＳＰによって保持および管理され、買手の不履行時にのみ発効され、他方は売手のＦＳＰによって保持および管理され、売手の側の不履行時にのみ発効される。Ｓ１０４に示すように、買手および売手は、図１−７に関して上に詳述されたように、商品および／またはサービスの購入および販売のためにiDraftTM、iDraftCTM、および／またはｉＴＸTMを開設してもよい。ステップＳ１０５では、買手による不履行があったかどうかが判断される。そのような不履行は、たとえば付帯事項の失敗によって、および／または付帯事項を適時に抹消しなかったことによって検出されてもよい。ＮＯの場合、Ｓ１０８に示すように、売手側に不履行があったかどうかが判断される。そのような不履行も、たとえば付帯事項の失敗によって、および／または付帯事項を適時に抹消しなかったことによって検出されてもよい。不履行がない場合、どの当事者も取引の条件に従って履行するのに失敗していなくても、Ｓ１１１に示すように、取引は失敗するかもしれない。
【００８３】
しかしながら、Ｓ１０５で買手側の不履行が検出された場合（たとえば、時間制限付帯事項が経過することによって、および／または、当事者および／または付帯事項抹消者が安全なiDraftTMウェブサイトにログオンして積極的に付帯事項を失敗させるようにすることによって）、ステップＳ１０６が実行され、買手のiPBondTMによって規定された清算損害額が、そのような損害額の支払についての条件がすべて満たされているならば、売手に支払われてもよい。買手が自分のＦＳＰに預けている資金が売手へ支払われたまたは支払われるべき清算損害額をカバーするには不十分である場合、１０７に示すように、買手の口座へ連結されたiLofCTMが、ＦＳＰが清算損害額を売手へ支払えるようにするために必要なクレジットを、買手に提供してもよい。Ｓ１０８で売手側の不履行が検出された場合、ステップＳ１０９が実行され、売手のiPBondTMによって規定された清算損害額が、そのような清算損害額の支払についての（売手のiPBondTMに規定されたような）条件がすべて満たされているならば、買手に支払われてもよい。売手が自分のＦＳＰに預けている資金が買手へ支払われたまたは支払われるべき清算損害額をカバーするには不十分である場合、Ｓ１１０に示すように、売手の口座へ連結されたiLofCTMが、ＦＳＰが清算損害額を買手に支払えるようにするために必要なクレジットを、売手に提供してもよい。
【００８４】
取引所またはｅコマースサイトのオペレータなどの第三者も、買手と売手との間の取引に関与してもよい。実際に、買手および売手は、取引所に登録された１つ以上の金融サービスプロバイダ（ＦＳＰ）とともに取引所を使用していてもよい。この発明によれば、取引所に登録されていないＦＳＰについては、確認されたiLofCTMおよび／または確認されたiPBondTMにより、買手が自分自身の未登録のＦＳＰで参加できるようになっていてもよい。買手、売手、および／またはＦＳＰは、取引所または第三者に登録してもよく、ここに説明されるiDraftTMメカニズムはその場合、これらの当事者どれもの代理人として機能し、当事者間で安全なメッセージを交換し、第三者のサイトでiDraftTMソフトウェアを動作させるであろう。当業者には公知の拡張マークアップ言語（Extended markup Language：ＸＭＬ）、電子データ交換（Electronic Data Interchange：ＥＤＩ）または他の安全なメッセージングプロトコル（その各々をここに引用により援用する）を用いて、iDraftTMを第三者のサイトまたはその登録者と接続してもよい。
【００８５】
図８は、この発明の一実施例に従った、iLofCTM信用状および／またはiPBondTM契約履行保証によって支持されるiDraftTMオンライン取引を実行するよう適合されたコンピュータ装置のシステムを示す。そこに示すように、買手、売手、および付帯事項抹消者は彼らのそれぞれのコンピュータ装置８０１、８０２、および８０４によって表わされる。買手８０１および／または売手８０２は彼ら自体が付帯事項抹消者であってもよいため、付帯事項抹消者８０４は破線で示されている。また、これに代えて、付帯事項抹消者８０４は、オンライン取引の当事者とは全く別の個人または主体であってもよい。買手８０１、売手８０２（オンライン取引は２人以上の買手および／または売手を含む場合がある）、および付帯事項抹消者８０４の各々は、たとえばセキュア・ソケット・レイヤー（ＳＳＬ）などの安全な通信チャネル８１０を介して、各々コンピュータネットワーク８０８（たとえばインターネットを含む）に結合されてもよい。買手のＦＳＰ８１１および売手のＦＳＰ８１２もネットワーク８０８に結合されていてもよい。買手のＦＳＰ８１１と売手のＦＳＰ８１２とは同じＦＳＰであってもよく、または、この方法を実行するよう合意している、もしくは別様でiDraftTM協会に属している異なるＦＳＰであってもよく、iDraftTM協会は、上に詳述されているように、各参加ＦＳＰのiDraftTM活動を監視し、各iDraftTM  ＦＳＰが遵守を合意している共通の規則を管理する、監督および規格制定機関として形成されていてもよい。図８に示すように、買手のＦＳＰ８１１はそれに預けられた買手の資金を番号の付いた口座において維持してもよい。買手の口座は、上述のように、それへ連結されたiLofCTM信用状および／またはiPBondTM契約履行保証を有していてもよい。同様に、売手のＦＳＰ８１２における売手の口座は、それへ連結されたiLofCTM信用状および／またはiPBondTM契約履行保証を有していてもよい。その後、買手から売手への支払の発出が（付帯事項がすべて抹消されているかまたは別様で満たされている場合）買手のＦＳＰ８１１における買手の口座から売手のＦＳＰ８１２における売手の口座へ直接、たとえばネットワーク８０８を介してなされてもよい。有利には、この発明のiLofCTMおよび／またはiPBondTMを用いた場合、どの信用貸決定も売手によってなされる必要はなく、売手は買手の信用貸または約束よりもむしろＦＳＰの支払約束に頼ることができる。
【００８６】
この発明は、いわゆる一括または要件付注文にも利用可能である。そのような一括注文は、たとえば、同意された上限および／または下限、および／または、同意された支払および／または配送についての付帯事項（例）を条件として、固定または可変量の商品を合意された価格で周期的に配送することについての規約を含んでいてもよい。たとえば、買手が参加iDraftTMベンダーの安全なウェブサイト上で、サイト上の提供された「一括注文」裁量を使用して、特定された期間（たとえば年間）の購入を実行するかもしれない。そのような場合、iDraftソフトウェアはこの購入をiDraftCTM取引として扱ってもよく、その場合、付帯事項のうちの１つは、合意された商品を合意された価格で買手に適時に配送することである。買手は、一旦認証されると、売手のまたはＦＳＰの安全なiDraftTMサイト上の付帯事項付き為替手形を検査してもよく、および／または付帯事項付き為替手形を詳述するｅメールまたは他の通知を受取ってもよい。商品が一旦適時に配送されると、買手は次に配送付帯事項を抹消し、付帯事項付き為替手形に対する支払がＦＳＰによって発出される。
【００８７】
同様に、見計らい注文も、この発明に従ったiDraftCTMを用いて容易にモデル化され得る。見計らい注文は一括注文と同様であるが、商品の価格が固定されておらず、上限も設けられていない点が異なる。たとえば、商品の価格は或る相互に認識される商品規格（先物市場など）へ結び付けられている場合がある。買手は参加iDraftTMベンダーの安全なウェブサイト上で「見計らい注文」裁量を選択してもよく、上述のように適切な依存性が確立されてもよい。
【００８８】
その他の種類の注文の多くもこの発明の機能性を用いてモデル化され得る。それらにはオークション注文も含まれ、それは一括注文と同様であるが、買手が注文開始前にオークションを行なって商品の価格を設定する点が異なっている。予約注文もこの発明に従ってモデル化され得る。予約注文は一括注文と同様であるが、商品の価格が固定されている点が異なる。実際、不履行または他の状況に応じた出来事に起因して当事者を補償するための付帯事項およびメカニズムを適切に巧妙に作ることによって、どの種類の注文および／または支払方式も、ここに説明されたiDraftTM、iDraftCTM、iPBondTMおよびiLofCTMツールを用いて規定されるであろう。
【００８９】
iDraftTM、iDraftCTM、iPBondTMおよびiLofCTMツールを用いた商取引金融モデル化
有利なことに、iDraftTMの付帯事項特徴は、この発明に従ったiPBondTMおよびiLofCTM双方の機能性を補足する。たとえば、ＦＳＰの（またはiDraftTMの要件を満たし、iDraftTMによって結合されることに合意する他の信用ある当事者もしくは仲介機関の）支払約束が買手の支払約束の代わりに使われ、それは支払がなされるという売手の確信を高める。ＦＳＰまたは他の信用ある主体もしくは仲介機関によって主催されるiDraftTMおよび／またはiDraftCTM取引は、当事者間の取引の根底にある製品および／またはサービスについての識別子と、販売の条件の詳細な説明とを含んでいてもよい。iDraftTMおよび／またはiDraftCTM取引はまた、iLofCTMオンライン信用状の条件の詳細な説明も含んでいてもよく、それは適切に認証された取引の当事者により、安全なウェブサイト上で閲覧可能であってもよい。iDraftTM、iDraftCTM、および／または任意の関連するiLofCTMは、購入注文書、条件、および送り状（それは次に、その部分的な履行において購入注文書を参照してもよい）に関する買手と売手との間のいかなる合意の説明も含んでいてもよい。また、ＦＳＰは、iLofCTM信用状および／またはその信用状が適用される取引に関連するいかなる文書も、当事者が満足ゆくように有効にしてもよい。以下の例はこの発明に従ったiLofCTMの有用性および用途を示している。しかしながら、この発明は以下に挙げられた例に限定されないことを理解されたい。
【００９０】
単純な支払
単純な支払は、付帯事項が特定されておらず、販売時に特定された条件（もしあれば）のみが支払を制約する取引において起こる。このため、iDraftTMとiLofCTMとの組合せを用いて、そのような取引、またはどんな付帯事項も持たない、つまり無条件の支払を、買手の支払約束の代わりにＦＳＰの支払約束を使うことにより支払を保証することによって、モデル化することができる。
【００９１】
履行保証
iDraftTM、iDraftCTM、iPBondTMおよびiLofCTMの組合わせに備わっている付帯事項特徴により、ＦＳＰまたは他の金融機関（たとえば保険会社）は、買手、売手、または取引の誰か他の当事者のいずれかであってもよい保証の買手により期待される履行を規定できるようになる。iLofCTMおよび／またはiPBondTM取引には、保証の買手の支払をひきおこし得る特定の挙動事例が提供されてもよい。本質的に、履行保証は、買手が売手に時間どおりにおよび合意どおりに支払うこと、売手が商品を合意どおりに出荷すること、および／または商品が適合品であることを保証するであろう。そのようなiLofCTMに備わった履行保証は、本質的には、１人以上の当事者が根底にあるiDraftTM、またはiDraftCTM、および／またはiPBondTM取引の列挙された条件のいずれかを破った場合に、損害に対する保険となる。
【００９２】
海上保険
海上保険、または任意の様式の出荷に関連して実行される保険は、iDraftCTMによって規定されるような適切な付帯事項を有するiLofCTMまたはiPBondTMとしてモデル化され得る。つまり、受取人は、根底にある取引の条件に従って損失を補償するための予め合意された資金を与えられてもよい。たとえば、購入された商品の要求どおりの配送が商品の欠如のために不可能であるかもしれない。適切に構成されたiLofCTMまたはiPBondTMのどちらかの下で提供される資金の支払は、買手および／または売手（根底にある合意に依存する）に損失を補償する保険として機能してもよい。
【００９３】
現金エスクロー
iLofCTMの規約の下でローンがない場合、現金はＦＳＰによりエスクローとして第三者に預託されてもよく、iDraftCTMとiLofCTMの組合せに備わっている付帯事項規約により、特定された受取人への資金の付帯事項付き発出が可能になる。このモデルは、不動産取引を含むすべてのエスクロー取引に適用され得る。
【００９４】
この発明に従ったiDraftTM、iDraftCTM、iLofCTMおよび／またはiPBondTMの組合せを用いて取引を適切にモデル化することによって、上述の例に詳述されるような支払条件の危険および付帯事項に基づく承認を含む大抵の商取引金融証書をモデル化することが可能である。
【００９５】
買手のＦＳＰ８１１と売手のＦＳＰ８１２との間で資金を振込む経費を最小限にさらに減少させるため、ＦＳＰ８１１および８１２は、その開示を全部ここに援用する、２０００年４月２６日提出の共通に譲渡された同時係属中の米国仮特許出願第６０／１９９，９３２号「多対多の対応：銀行間の資金振込に取って代わる方法およびシステム」（“Many To Many Correspondence: Methods And Systems For Replacing Interbank Funds Transfers”）に記載されたメッセージング方法論を採用してもよい。
【００９６】
ハードウェア概要
図１１は、この発明の一実施例が実現され得るコンピュータ１１００のブロック図を示す。コンピュータシステム１１００は、情報を通信するためのバス１１０１または他の通信メカニズムと、バス１１０１に結合され、通信を処理するためのプロセッサ１１０２とを含む。コンピュータシステム１１００は、バス１１０１に結合され、情報およびプロセッサ１１０２により実行されるべき命令を記憶するためのランダムアクセスメモリ（ＲＡＭ）または他のダイナミック記憶装置１１０４（メインメモリとして言及される）をさらに含む。メインメモリ１１０４は、プロセッサ１１０２による命令の実行中に一時的数値変数または他の中間情報を記憶するためにも使用されてもよい。コンピュータシステム１１００はまた、バス１１０１に結合され、スタティック情報およびプロセッサ１１０２用の命令を記憶するための読出専用メモリ（ＲＯＭ）および／または他のスタティック記憶装置１１０６も含む。磁気ディスクまたは光ディスクなどのデータ記憶装置１１０７が、情報および命令を記憶するためにバス１１０１に結合される。モデムまたはネットワークインターフェイスカード（たとえばイーサネット（Ｒ）など）の通信装置１１０８もバス１１０１に結合されて、図８の８０８で示すようなネットワークへのアクセスを提供する。
【００９７】
コンピュータシステム１１００はまた、バス１１０１を介して、情報をコンピュータユーザへ表示するための陰極線管（ＣＲＴ）などのディスプレイ装置１１２１へ結合されてもよい。英数字および他のキーを含む英数字入力装置１１２２は通常、バス１１０１に結合されて、情報およびコマンド選択をプロセッサ１１０２へ通信する。ユーザ入力装置の別の種類は、マウス、トラックボール、またはカーソル方向キーなどの、方向情報およびコマンド選択をプロセッサ１１０２へ通信し、ディスプレイ１１２１上のカーソルの動きを制御するカーソル制御１１２３である。この入力装置は通常、２つの軸、つまり第１の軸（たとえばｘ）および第２の軸（たとえばｙ）において２つの自由度を有しており、それによりこの装置は平面における位置を特定することができる。
【００９８】
また、これに代えて、指紋読取装置、網膜スキャナ、および／または他の生体測定情報計測および／または取得装置などの他の入力装置１１２４が含まれていてもよい。また、これに代えて、スタイラスまたはペンを用いてディスプレイと対話してもよい。コンピュータスクリーン上の表示されたオブジェクトは、スタイラスまたはペンを用いて表示されたオブジェクトを触ることによって選択されてもよい。コンピュータはタッチスクリーンを実装することによってこの選択を検出する。同様に、ライトペンまたは光感知スクリーンを用いて表示されたオブジェクトを選択してもよい。そのような装置は、マウスまたはトラックボールを取入れたシステムでの「ポイント＆クリック」の代わりに、選択位置および選択を単一の操作として感知してもよい。スタイラスおよびペンベースの入力装置、およびタッチスクリーン、光感知スクリーンは当該技術分野において周知である。そのようなシステムには１１２２のようなキーボードもなく、この場合、それとの対話はすべてスタイラスなどの代替的な入力装置を介して行なわれてもよく、書かれた文書はたとえば光学式文字認識（ＯＣＲ）手法を用いて解読されてもよい。
【００９９】
この発明は、信用状および／または契約履行保証によって支持される安全な電子ＦＳＰ為替手形を介して付帯事項依存の支払を実行するための方法およびシステムを提供するためのコンピュータシステム１１００の使用に関する。一実施例によれば、この発明に従った方法は、プロセッサ１１０２がメモリ１１０４内に含まれる命令の連続を実行することに応答する１つ以上のコンピュータシステム１１００によって実施される。そのような命令は、データ記憶装置１１０７などの別のコンピュータ可読媒体からメモリ１１０４に読込まれてもよい。メモリ１１０４に含まれる命令の連続の実行により、プロセッサ１１０２は、上に説明されたプロセスステップを行なうようになる。代替的な実施例では、この発明のすべてのまたは選択された部分を実施するために、ソフトウェア命令の代わりにまたはそれと組合せて、配線回路が使用されてもよい。このため、この発明は配線回路とソフトウェアとのどの特定の組合せにも限定されない。
【０１００】
これまで詳述した説明はこの発明の好ましい実施例を説明してきたが、上述の説明は単に例示的であって開示された発明を限定するものでないことが理解されるべきである。実際、当業者であれば他の代替的な実施例を認識するであろうし、そのような実施例はすべて、この発明の範囲内に当てはまると考えられる。このため、この発明は特許請求の範囲によってのみ限定されるべきである。
【図面の簡単な説明】
【０１０１】
【図１Ａ】この発明の一実施例の一局面を示すフローチャートであり、ウェブ買手が自分のホームバンクと、ディレクトリにより認証される銀行為替手形システム（「iDraftTM」システム）に参加するよう契約する場合の図である。
【図１Ｂ】この発明の一実施例の別の局面を示すフローチャートであり、ウェブ買手のホームバンクがウェブ買手をウェブ売手へ認証し、またはウェブ買手が銀行のウェブサイトまたはポータルから参加ウェブ売手のウェブサイトへアクセスできるようにするために取るステップを示す図である。
【図２】この発明の別の実施例を示すフローチャートである。
【図３】この発明の実施例を実行するよう適合されたコンピュータ装置のシステムまたはネットワークを示し、コンピュータ装置の各々はネットワーク（たとえばインターネットなど）に結合されている図である。
【図４】例示的なｉ取引（ｉＴＸ）の論理構造のブロック図である。
【図５】ｉＴＸがｉＴＸの全関係当事者へ通知を送っている図である。
【図６】この発明の一実施例に従ったｉＴＸ取引の実行フローのフローチャートである。
【図７】この発明の一実施例に従ったｉＴＸ取引を実行するよう適合されたコンピュータ装置のシステムまたはネットワークを示し、コンピュータ装置またはネットワーク対応装置の各々はインターネットなどのネットワークに結合されている図である。
【図８】この発明の一実施例に従って、iLofCTM信用状および／またはiPBondTM契約履行保証により支持されたiDraftTMオンライン取引を実行するよう適合されたコンピュータ装置のシステムを示す図である。
【図９】この発明の一実施例に従った、オンライン取引におけるiLofCTM信用状の操作の一例のフローチャートである。
【図１０】この発明の一実施例に従った、iPBondTM契約履行保証の操作の一例のフローチャートである。
【図１１】この発明の一実施例が実現され得るコンピュータのブロック図である。
【図１Ａ】
2004531813.tif 000003
【図１Ｂ】
2004531813.tif 000004
【図２】
2004531813.tif 000005
【図３】
2004531813.tif 000006
【図４】
2004531813.tif 000007
【図５】
2004531813.tif 000008
【図６】
2004531813.tif 000009
【図７】
2004531813.tif 000010
【図８】
2004531813.tif 000011
【図９】
2004531813.tif 000012
【図１０】
2004531813.tif 000013
【図１１】
2004531813.tif 000014
【国際公開パンフレット】
2004531813.tif 000015
2004531813.tif 000016
2004531813.tif 000017
2004531813.tif 000018
2004531813.tif 000019
2004531813.tif 000020
2004531813.tif 000021
2004531813.tif 000022
2004531813.tif 000023
2004531813.tif 000024
2004531813.tif 000025
2004531813.tif 000026
2004531813.tif 000027
2004531813.tif 000028
2004531813.tif 000029
2004531813.tif 000030
2004531813.tif 000031
2004531813.tif 000032
2004531813.tif 000033
2004531813.tif 000034
2004531813.tif 000035
2004531813.tif 000036
2004531813.tif 000037
2004531813.tif 000038
2004531813.tif 000039
2004531813.tif 000040
2004531813.tif 000041
2004531813.tif 000042
2004531813.tif 000043
2004531813.tif 000044
2004531813.tif 000045
2004531813.tif 000046
2004531813.tif 000047
2004531813.tif 000048
2004531813.tif 000049
2004531813.tif 000050
2004531813.tif 000051
2004531813.tif 000052
2004531813.tif 000053
2004531813.tif 000054
2004531813.tif 000055
2004531813.tif 000056
2004531813.tif 000057
2004531813.tif 000058
2004531813.tif 000059
2004531813.tif 000060
2004531813.tif 000061
2004531813.tif 000062
2004531813.tif 000063
2004531813.tif 000064
2004531813.tif 000065
2004531813.tif 000066
2004531813.tif 000067
2004531813.tif 000068
2004531813.tif 000069
2004531813.tif 000070
2004531813.tif 000071
2004531813.tif 000072
2004531813.tif 000073
2004531813.tif 000074
2004531813.tif 000075
2004531813.tif 000076
2004531813.tif 000077
2004531813.tif 000078
2004531813.tif 000079
2004531813.tif 000080
2004531813.tif 000081
2004531813.tif 000082
2004531813.tif 000083
2004531813.tif 000084
2004531813.tif 000085
2004531813.tif 000086
2004531813.tif 000087
【国際公開パンフレット（コレクトバージョン）】
2004531813.tif 000088
【国際調査報告】
2004531813.tif 000089
2004531813.tif 000090