JP2005196760A - オンデマンド融資サービスを実現するためのシステムおよび方法 - Google Patents

Abstract

【課題】 インターネットによるクレジット・カード購入の容易さと、従来のリースの柔軟性とを結合するコンピュータ・システム、サービス、コンピュータ・プログラム記録媒体、および関連方法を提供することにある。
【解決手段】 オンデマンド融資システムは、ｅ−署名などの安全な電子送達および法的に強制執行可能なドキュメント・アーカイブとともにクレジット承認、リース構造およびリース・レート、条件などの顧客資格プロセスをプリパッケージする融資ｅ−ユーティリティである。このシステムは、内部管理コストの低減、現行ビジネス・プロセスの迅速化、エンドユーザとベンダの別なく一緒にビジネスを実行する容易さの強化という利点をマーチャントに提供する。これは、融資会社の要件を満たす安全で法的に強制執行可能なドキュメントを生成する。
【選択図】 図３

Description

本発明は、一般に、商業金融（commercialfinancing）の分野に関し、特に、安全かつカスタマイズ可能で、顧客取引（customer transaction）が発生したときにオンデマンドで使用可能な、インターネットにより高額商業販売（high value commercial sales）に融資するためのソフトウェア・システム、コンピュータ・プログラム記録媒体、サービス、および関連方法に関する。より具体的には、本発明は、安全な電子送達およびｅ−署名（e-signature）などの法的に強制執行可能なドキュメントとともにクレジット承認、リース構造およびリース・レート、条件などの顧客資格プロセス（customer entitlement process）をプリパッケージし、従来の大量の紙を要する製品リース・プロセスを自動化し、インターネットにより製品に融資するための新しい方法を提供するｅ−ビジネス（e-business）方法に関する。

ワールド・ワイド・ウェブ（World WideWeb：ＷＷＷ）またはインターネットは、その上で世界中の企業、政府、グループ、および個人がウェブ・ページとして知られるインターリンク・コンピュータ・ファイル（inter-linked computer file）を維持する相互接続コンピュータの広範囲にわたるネットワークからなる。当初、インターネットは情報の転送のために考案された。より最近では、インターネットは、電子カタログ（electronic catalogue）のようにユーザ用のショッピング・ツールとしてますます使用されている。インターネットにより製品を購入するインターネット・ユーザの数が増加した結果、企業が製品販売に対して取る手法が大幅に変化し、標準的なビジネス・モデルから電子ビジネスまたはｅ−ビジネス・モデルへ転換している。

インターネットによる購入トランザクションの導入により、顧客とｅ−ビジネス・マーチャント（merchant）との間の安全な金融トランザクションの必要性が生まれた。マーチャントの様々な処理要求に対応するために、多数の支払システムが考案されている。たとえば、数社の融資会社はマーチャントにインターネット・マーチャント銀行口座を提供し、マーチャントがクレジット・カード・トランザクションを受理できるようにしている。

これらの会社は、クレジット・カード・トランザクションを実行するために「ウォレット」手法を使用する。ウォレットを開始する場合、消費者は概してインターネットにより融資会社にクレジット・カード情報を提供する。見返りとして、消費者は、そのクレジット・カードを指す暗号化されたコードを受信する。参加ウェブ・マーチャントで購入を行う場合、消費者はマーチャントにウォレット・コードを提供する。マーチャントはそのコードを購入価格に付加し、ウォレットを発行した融資会社に両方とも送信する。融資会社は、クレジット・カード会社と一緒にそのトランザクションを認証し、次に製品を出荷するための許可とともにマーチャントに資金を移転する。

インターネットによる金融トランザクションを可能にするためのもう１つの手法は、クレジット・カード番号の代わりに「仮想」コードの使用を伴うものである。融資会社は、クレジット・カード情報と交換で「仮想」コードを顧客（または消費者）に発行する。セキュリティ上の理由で、この交換はほとんどいつもインターネットではなく電話によって実行される。購入が許可される前に、融資会社は確認要求を顧客に電子メールで送信する。融資会社が顧客の確認を受信すると、クレジット・カード・トランザクションはインターネットから離れて処理され、マーチャントには製品出荷を許可するための電子メールが送信される。

クレジット・カードベースの購入方式の代替手法はディジタル・キャッシュまたは「ｅ−キャッシュ（e-cash）」である。ディジタル・キャッシュは本質的に、銀行によって発行された数字またはトークンのストリングである。しかし、ｅ−キャッシュを使用するためには、ｅ−ビジネス・マーチャントと顧客はどちらも、ｅ−キャッシュを発行する銀行に口座を持っていなければならない。銀行は、ｅ−ビジネス・マーチャントと顧客の両方に対し、ｅ−キャッシュを管理し移転するための「財布」ソフトウェアを提供する。顧客は、金銭を自分の銀行口座からｅ−キャッシュに転換し、次にそれを財布ソフトウェアに転送するが、そこでｅ−キャッシュは暗号化され、消費者のハード・ディスク上に保管される。

ｅ−キャッシュで購入する場合、消費者は、適用可能なトークンをマーチャントに伝送し、マーチャントは認証および償却のためにそれを銀行に中継する。ｅ−キャッシュは物理的対象物ではないので、各ｅ−キャッシュ「硬貨」は１回しか使えないことを保証するために複雑な一連の通し番号が使用される。ｅ−キャッシュは、比較的低いトランザクション・コストを発生し、他のインターネット融資手法で可能なものより小額の額面金額を提供し、株式の取引値または新商品の支払などの低額トランザクションでの使用に適したものになる。しかし、ｅ−キャッシュを受け入れるウェブ・マーチャントは多いわけではなく、現在、それを発行している銀行は比較的少数である。

電子小切手（Electronicchecking）は、ｅ−コマース（e-commerce）で使用するもう１つの実行可能な支払方法である。電子小切手または「ｅ−小切手（e-check）」は本質的に紙の小切手と同様の特徴を有する。その最も単純な形では、いくつかのシステムはウェブ・ストア（Web store）上のオンライン用紙（onlineform）に記入するよう消費者に要求する。次に入力データはベンダに転送され、そこで標準的なオフィス・プリンタで白地小切手用紙を使用することによって紙の小切手に転換される。その後、小切手は通常通り、支払のために銀行に提示される。

顧客およびマーチャントに高レベルのセキュリティを提供するために、サード・パーティ企業は、消費者が安全なサイトで自分の当座預金口座情報を入力し、固有のユーザ名およびパスワードを選択できるようにする。参加ウェブ・ストアから購入を行いたいと希望する顧客は、単にマーチャントのオンライン注文用紙を完成するだけである。次に注文情報はサード・パーティのセキュア・サーバにサブミットされ、そこで検証される。検証後、マーチャントはその小切手を印刷し、銀行に提示する。この電子小切手手段は、小切手が購入者からマーチャントへの郵送をクリアするまでの待ち時間を回避する。しかし、これは、ウォレットまたは仮想コードを使用するｅ−コマース支払ほど好都合ではない。

ｅ−コマース・トランザクションの上記の手法はいずれも、概してクレジット・カード・トランザクションによって処理される比較的少額の購入を行う個人をターゲットにしている。ユーザおよびマーチャントのいずれにとっても現行のｅ−コマース融資の主な焦点は、最小限のオーバヘッドで安全な高速トランザクションを提供することである。この購入トランザクションは比較的単純なものであり、融資会社からマーチャントへの金銭またはクレジットの移転を伴うものである。しかし、ｅ−コマース・ビジネス・モデルが拡大すると、ｅ−ビジネス・マーチャントは、インターネットによる、より複雑なトランザクションを管理できなければならない。

企業間取引トランザクションでは、より多額の資金が必要になる。インターネットにより高額品目を販売するｅ−ビジネスは、その顧客に対し、融資の柔軟性を提供できなければならない。現在、顧客は、マーチャントから所望の製品を選択し、次にその価格を折衝する。顧客が所望の価格で購入を希望する製品を確保した後、顧客は製品の購入の融資を希望する可能性がある。その場合、顧客は、クレジット承認を取得し、多数の文書に署名する必要がある。このプロセス全体は、インターネット上で実現するには比較的難しいものであり、時間のかかるものである。

また、顧客は、むしろリース契約によりｅ−ビジネス・マーチャントへの支払を構造化することを決定する可能性もある。しかし、顧客および融資会社と一緒にリースをセットアップする際に大量の事務処理が必要になるので、顧客に対してインターネットによりリース・オプションを提供することも比較的難しいものである。購入トランザクションにおけるインターネットの主な魅力は、トランザクションが行われる際の容易さと、トランザクションが処理される速度であるので、リースまたは融資の際に大量の事務処理が必要になることは、マーチャントと顧客のいずれにとってもインターネットの利点を否定するものである。

安全かつカスタマイズ可能で、顧客取引が発生したときにオンデマンドで使用可能な、インターネットにより高額商業販売に融資するためのシステム、サービス、コンピュータ・プログラム記録媒体、および関連方法が必要である。したがって、このようなソリューションの必要性は満たされないままになっている。

本発明は、この必要性を満足し、オンデマンド融資（financing on demand）サービスを実現するためのシステム、サービス、コンピュータ・プログラム記録媒体、および関連方法（ひとまとめにして本明細書では「システム」または「本システム」という）を提示する。本システムは、インターネットによるクレジット・カード購入の容易さと、従来のリースの柔軟性とを結合し、オンデマンド融資（ＦＯＤ）システムを提供する。

本システムは、ショッピング・ウェブ・サイトなどのインターネット・アプリケーションから呼び出し可能なモジュラ・ウェブ・サービスを有する融資ｅ−ユーティリティ（financing e-utility）を有する。このｅ−ユーティリティは、ｅ−署名などのドキュメントの安全な電子送達および法的に強制執行可能なドキュメント・アーカイブとともにクレジット決定（credit decisioning）、リース構造およびリース・レート、条件などの顧客資格プロセスをプリパッケージする。

本システムは、従来の大量の紙を要する製品リース・プロセスを自動化し、インターネットにより製品に融資するための新しい方法を提供する。本システムは、概して最低信用限度額と限られた支払構造を有するクレジット・カードを使用せず、ウェブベースのトランザクションの速度と利便性という基本的な利点を否定するオフライン融資プロセスを当てにしない。

本システムは、安全かつ完全にカスタマイズ可能で、顧客取引がリアルタイムで発生したときにオンデマンドで使用可能な、インターネットにより高額販売に融資するための新しい方法を提供する。本システムの１つの特徴は、購入価格送り状を融資付き定期的支払（financed periodic payment）に転換する。

従来、リース・プロセスは、詳細な定期的支払を生成するために限られた期間に複数のトランザクションまたはトランシュ（tranche）について順次実行される。その結果として、本システムは、大量で低コストの製品の調達プロセスを単純にする。本システムは、内部管理コストの低減、現行ビジネス・プロセスの迅速化、エンドユーザとベンダの別なく一緒にビジネスを実行する容易さの強化という利点をマーチャントに提供する。

本システムは、融資会社の契約およびセキュリタイゼーション（securitization）要件を満たす安全で法的に強制執行可能なドキュメントを生成する。マーチャントは、たとえば、ソフトウェア・トークン、ＣＤ−ＲＯＭ、スマート・カード・メディア、単純なセキュア・パスワード、またはオンラインで有資格顧客を識別するためのその他の定義済みの安全な手段により、顧客が本システムにアクセスできるようにする。本システムは、固定信用限度額または支払構造をまったく備えておらず、完全に暗号化されて安全であり、任意のベンダのウェブ・サイトへの都合の良い統合を可能にするために入出力において所有権のないオープン・スタンダード・アーキテクチャを使用する。１つのユーティリティとして、その使用は、クレジット・カード発行銀行によって請求されるマーチャント手数料と同様に、トランザクションごとに請求可能なものにすることができる。

現在、ウェブにより行われる企業間取引情報技術（ＩＴ）トランザクションは、クレジットまたは調達カードによって支払われる小規模取引を除き、注文が行われた後にオフラインで融資される。製品融資は、ウェブ販売プロセスに対し、制限的で比較的手動主体の事後ステップである。

本システムは、カスタマイズ・リース構造化およびチェックアウトまたは送り状作成の時点で各顧客によって事前合意された支払計画に加えて、安全で即時の有資格信用限度額を提供する。顧客は、オンラインでドキュメントを執行するために自分の暗号化されたＩＤを呼び出す。他のサポート・ドキュメンテーションはいずれも、トランザクションの時点で必要な追加のベンダまたは顧客の対話なしに、本システムで生成されてアーカイブされ、オンデマンドで使用可能である。

本システムは、マーチャント、顧客、および融資会社に対し、現行の融資方法を越える明瞭な利点を提供する。ベンダの場合、本システムは、大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化、各顧客ごとに予定された金融構造化（financial structuring）、および融資ソースに関する送り状決済の加速を提供する。顧客の場合、本システムは、インターネットにより顧客の要求で使用可能なカスタマイズ融資および信用限度額の利便性ならびに安全なドキュメント追跡およびアーカイブを提供する。融資会社の場合、本システムは、事務処理の削減、生産性の強化、インターネットによる新しい企業間取引市場へのアクセスの拡大、オンデマンド融資プロセスを管理するための追加の手数料収入を提供する。

融資会社の典型的な顧客は、定期リース基本契約（termlease master agreement）（ＴＬＭＡ）または顧客ベースの基本契約（customer based master agreement）（ＣＢＭＡ）を結んでいる顧客である。これらは、条件がすでに折衝されたリース契約である。定期的に、通常は四半期ごとに、これらの顧客は更新されたリース・レートについて融資会社と折衝する。ドルの金額が融資されている間、信用状期限延長はトランザクション時の記名承諾規則に基づいて固定される。

その四半期についてリース・レートが設定されると、顧客と融資会社はその基本的な定期リース基本契約（「ＴＬＭＡ」）に対するレート補足（rate supplement）を実行する。貸し主は、顧客の有資格条件、通常は延長されたクレジットの金額をマーチャントに通知する。顧客はマーチャントに連絡し、次にマーチャントは、顧客に製品を出荷した後で融資会社に対し製品に関する送り状を発行する。融資会社は、製品の受領および基礎となるリースの開始について署名し肯定応答するために、顧客に対し送達確認文書（delivery confirmation document）を発行する。

本システムは「調整前払（reconciliationup front）」という概念に基づくものである。顧客は、リースをセットアップするための合法的契約書を作成して、製品を購入する前に本システムによりレート補足および送達確認を承認する。顧客が送達確認を受け入れると、機器のリースが開始され、貸し主はマーチャントの送り状の決済を実行することができる。

事前合意の理由（価格設定の間違いなど）に基づいて支払を拒否するために顧客がアクションを講じない限り、送達確認は指定の期間後に受け入れられたものと想定される。本システムは、その送り状について月毎にどのように融資されるかを示す詳細補足を顧客に対して表示する。本発明の１つの特徴は、顧客に対して送り状がリリースされると、融資プロセスの残りの部分が自動になることである。送り状は、顧客と融資会社との間のリースまたはその他の融資協定の始まりである。

基本契約の基礎となる補足はトランザクションごとに（価格設定、期間、支払構造、妥当性などのトランザクション固有の詳細によって）変化するが、基本契約は静的なものになる傾向がある。四半期ごとの要約補足は四半期ごとの合意レート（agreed-to rate）を指定する。送達確認／詳細補足は、その四半期に出荷された製品に関するマーチャント送り状から生成される。これらの補足は、その四半期に有効な要約補足のレートを使用して、送り状購入価格を支払うべき月毎のリース賃貸料に転換する。

本システムは、検討および安全な電子署名のために適切な時期に、基本定期リース契約、要約補足および任意の関連ドキュメンテーション（別表Ａ）、送達確認／詳細補足、およびマーチャント送り状を有資格顧客に提示する。このような文書はいずれも、合法的文書として扱われ、現地法に従って安全に両当事者によって電子的に署名され、本システムによってアーカイブされ、融資会社による後日のセキュリタイゼーションのためまたは署名当事者によるオンライン・サーチおよび検索のために使用可能になる。

本発明は、オンデマンド融資消費者ユーティリティ・プログラムなどのユーティリティ・プログラムで実施することができる。本発明は、リースをセットアップするための合法的契約書を作成して、顧客が製品を購入する前にこのユーティリティ・プログラムによりレート補足および送達確認を承認するための手段を提供する。顧客が送達確認を受け入れると、機器のリースが開始され、貸し主はマーチャントの送り状の決済を実行することができる。顧客は、たとえば、ソフトウェア・トークン、ＣＤ−ＲＯＭ、スマート・カード・メディア、単純なセキュア・パスワード、またはオンラインで有資格顧客を識別するためのその他の定義済みの安全な手段により、マーチャントにアクセスする。顧客は、カスタマイズ・リース構造化および事前合意された支払計画に加えて、安全で即時の有資格信用限度額をさらに入手する。顧客は、オンラインでドキュメントを執行するために自分の暗号化されたＩＤを呼び出す。他のサポート・ドキュメンテーションはいずれも、本システムで生成されてアーカイブされ、顧客によってオンデマンドで使用可能である。

本発明は、オンデマンド融資マーチャント・ユーティリティ・プログラムなどのユーティリティ・プログラムで実施することができる。本発明は、マーチャントが内部管理コストを低減し、現行ビジネス・プロセスを迅速化し、エンドユーザとベンダの別なく一緒にビジネスを実行する容易さを強化するための手段を提供する。マーチャントは、顧客の有資格条件、通常は延長されたクレジットの金額の通知を受信する。マーチャントは、大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化、各顧客ごとに予定された金融構造化、および融資ソースに関する送り状決済の加速を獲得する。

本発明の様々な特徴およびそれらを達成する方法については、以下の説明、特許請求の範囲、および図面に関連して、以下に詳細に記載するが、参照番号は、参照項目間の対応を示すために適宜、再利用される。

以下の定義および説明は、本発明の技術分野に関連する背景情報を示すものであり、その範囲を制限せずに本発明の理解を容易にするためのものである。

ＥＤＩ：電子データ交換（ElectronicData Interchange）。注文、確認、および送り状などの組織間のビジネス・トランザクションの電子通信。

インターネット（Internet）：グローバルな分散ネットワークを形成するために１組の標準的なプロトコルによってルータとともにリンクされる相互接続された公衆および私設コンピュータ・ネットワークの集合。

ＰＤＦ：ポータブル・ドキュメント・フォーマット（Portable Document Format）、すなわち、複数のコンピュータ・プラットフォーム間で移植可能になるように設計されたＡｃｒｏｂａｔ（Ｒ）文書交換システムで使用されるページ記述言語。このフォーマットを使用する２つの主な利点は、インターネット上で使用可能なフリーウェアのＰＤＦリーダが多数存在することと、ソース・ドキュメントなしでＰＤＦ文書を変更できないことである。

ＵＣＣ−１ファイリング（UCC-1Filing）：債務者担保権者連合（debtor-securedparty association）および関連の担保（security）に対応する公示を行うように設計された統一商事法典（Uniform CommercialCode）内の一項目。さらに、ＵＣＣ−１は、ローンのために債務者によって提供される担保に関する担保権者の利権を記録し保護する。

ＵＲＬ（ユニフォーム・リソース・ロケータ（UniformResource Locator））：インターネット上のコンテンツ・オブジェクトの位置を完全に指定する固有のアドレス。ＵＲＬの一般的なフォーマットは、プロトコル：／／サーバアドレス／パス／ファイル名である。

ウェブ・サイト（Web Site）：インターリンクされたハイパーテキスト・ドキュメント（「ウェブ・ドキュメント」または「ウェブ・ページ」）および関連データ・エンティティのデータベースまたはその他の集合であって、コンピュータ・ネットワークを介してアクセス可能であり、ＷＷＷなどのより大規模な分散情報システムの一部を形成するもの。一般に、あるウェブ・サイトは、特定のインターネット・ドメイン・ネームに対応し、特定の組織のコンテンツを含む。他のタイプのウェブ・サイトとしては、たとえば、法人の「イントラネット」（すなわち、標準のインターネット・プロトコルを使用する内部ネットワーク）のハイパーテキスト・データベースまたはＷＷＷのもの以外のドキュメント検索プロトコルを使用するハイパーテキスト・システムのサイトを含むことができる。

ワールド・ワイド・ウェブ（World WideWeb）（ＷＷＷ）：インターネット・ユーザ／サーバ・ハイパーテキスト分散情報検索システム。

ＸＭＬ：拡張マークアップ言語（eXtensibleMarkup Language）。ウェブ・ドキュメントに使用する標準的な半構造化言語。ドキュメント・オーサリング段階中に、ＸＭＬ「タグ」はドキュメントの情報コンテンツ内に埋め込まれる。続いてウェブ・ドキュメント（または「ＸＭＬドキュメント」）がウェブ・サーバによってウェブ・ブラウザに伝送されると、タグはブラウザによって解釈され、ドキュメントを構文解析し表示するために使用される。ウェブ・ブラウザがどのようにドキュメントを表示するかを指定することに加えて、ＸＭＬタグは、他のウェブ・ドキュメントへのハイパーリンクを作成するために使用することができる。

図１は、本発明によるオンデマンド融資を実現するためのシステム、サービス、コンピュータ・プログラム記録媒体、および関連方法（「システム１０」）を使用できる例示的な環境全体を描写している。オンデマンド融資システム１０は、概してホスト・サーバ１５内に埋め込まれたかまたはホスト・サーバ１５上にインストールされたソフトウェア・プログラミング・コードまたはコンピュータ・プログラム記録媒体を含む。別法として、システム１０は、ディスケット、ＣＤ、ハード・ディスク、または同様のデバイスなどの適切な記憶媒体上に保管することができる。ＷＷＷに関連してシステム１０について説明するが、システム１０は、ＷＷＷまたはその他のソースから導出された可能性のある用語のスタンドアロン・データベースで使用することができる。

雲状の通信ネットワーク２０は、サーバ２５、２７などのサーバをゲートウェイ３０などのゲートウェイに接続する通信回線とスイッチからなる。サーバ２５、２７およびゲートウェイ３０は、ＷＷＷまたはインターネットへの通信アクセスを可能にする。リモート・インターネット・ユーザなどのユーザは、コンピュータ３５、３７、３９などの様々なコンピュータによって表され、通信ネットワーク２０を介して所望の情報についてホスト・サーバ１５に照会することができる。コンピュータ３５、３７、３９はそれぞれ、ユーザがインターネットをブラウズし、安全にホスト・サーバ１５とのインターフェースを取れるようにするソフトウェアを含む。

ホスト・サーバ１５は、電話、ケーブル、または衛星リンクなどの通信リンク４２を介してネットワーク２０に接続される。サーバ２５、２７は、高速インターネット・ネットワーク回線４４、４６を介して他のコンピュータおよびゲートウェイに接続することができる。サーバ２５、２７は、５０、５５、および６０に全体的に示されているハイパーテキストまたはウェブ・ドキュメントなどの保管情報へのアクセスを可能にする。ドキュメント５０、５５、６０は、テキスト、画像、およびその他のオブジェクトを含むことができる。ハイパーテキスト・ドキュメント５０、５５、６０は、ローカルに保管された他のページへの埋込みハイパーテキスト・リンクと、他のウェブ・サイトまたはサーバ２７などの様々なウェブ・サーバによって保管された他のドキュメント５５、６０へのハイパーテキスト・リンク７０、７２、７４、７６とを含む可能性が最も高い。

図２は本発明のサービス方法２００を示し、それにより顧客はシステム１０からの融資を使用してベンダから製品を購入する。顧客の資格はまずシステム１０によって確立される。

ステップ２０２で、顧客は、以下に示す図４のサービス方法３００に詳細に示すように自分の基本契約を確立するために融資会社と対話する。また、顧客の資格は、以下に示す図５のサービス方法４００に詳細に示すように作成される。顧客の資格としては、その顧客の信用限度額、融資条件、支払期間および構造に関する顧客の希望、支払追跡、および支払明細プリファレンスを含む。

融資会社と取引する場合、顧客は概して、四半期ごとなどの定期的に融資レートおよび／または支払構造を再折衝することになる。サービス方法４００は、この定期的ベースで繰り返し、顧客の資格をリフレッシュすることになる（ステップ２０６）。これらの融資条件および再融資期間も顧客の資格に含まれる。ステップ２０２は、ホスト・サーバ１５を介してオンラインで提示され、顧客によって受け入れられるドキュメント５０、５５、６０などの標準的なドキュメントを使用して実行される。その後、顧客の口座は使用可能になる。

次に融資会社は、ステップ２１０で顧客のクレジット承認をマーチャントに通知する。

図３の例をさらに参照すると、有資格顧客（「ユーザ」）２１５は、ホスト・サーバ１５上のマーチャントのウェブ・サイトにアクセスする。ユーザ２１５は製品を購入することを決定し、ステップ２２０（図２）で注文を行う。ホスト・サーバ１５上のマーチャントのウェブ・サイトは、支払方法としてシステム１０へのアクセス権をユーザ２１５に提供する。

ユーザ２１５が自分のショッピング・カートをチェックアウトすると、ユーザ２１５は、システム１０からホスト・サーバ１５上のマーチャントのウェブ・サイトで自分にとって使用可能な融資オプションを選択する。システム１０はユーザ２１５をオンライン・トランザクション・サーバ２２５（図３）に振り向け、そこでユーザ２１５の融資および請求情報が暗号化される。ユーザ２１５は、チェックアウトの前に自分のショッピング・カート内の適格製品について四半期ごとのレートを表示することができる。

注文が行われると、送り状情報が専用ゲートウェイ２３０を介して処理ネットワーク２３５に送信される。処理ネットワーク２３５は融資会社の融資会社サーバ２４０に送り状情報を経路指定する。マーチャントは、ユーザ２１５の有資格信用限度額までの価値の製品を有資格ユーザ２１５に出荷し（ステップ２５０）、前に受信した融資会社のリース許可／購入注文の条件に基づいて融資会社に送り状を送付する。

マーチャントの送り状は送達確認文書を作成するために使用される。マーチャントの送り状と送達確認文書はどちらも、ホスト・サーバ１５上のマーチャントのウェブ・サイトでユーザ２１５によって検討および受入れのために使用可能になる（ステップ２５５）。一実施形態では、システム１０は、送り状がポストされたことをステップ２６０でユーザ２１５に通知することができる。

ユーザ２１５は、送り状が自動的に承認される前に送り状を検討し受け入れるための所定の期間を有する。その場合、ユーザ２１５は送り状を検討し、ステップ２６５で送り状を承認するかまたは拒否する。

ユーザ２１５が送り状を拒否した場合、システム１０はステップ２７０でエラー処理のために送り状をマーチャントに返す。そうではない場合、システム１０は送り状を定期的支払明細に転換する。ステップ２７５では、融資会社はマーチャントの送り状を全額決済し、リースまたは融資計画はユーザ２１５と融資会社との間で予定されたように記帳される。購入した製品がリースされる場合、資産権利は、リースの終了時にユーザ２１５によって何らかの決定が行われるまでその資産の権利を保有する融資会社に移行する。

システム１０においてユーザ２１５の基本契約トランザクションを作成する（ステップ２０２）ためのサービス方法３００は図４のフローチャートにより詳細に示されている。融資会社の従業員は、ステップ３０１でシステム１０にログインし、ユーザ２１５の組織のために基本契約トランザクションの作成を要求する。このアクションの前に、ユーザ２１５またはその組織はすでに、ステップ２０２（図２）によって表されるように、融資会社から顧客資格を受け取っている。この顧客資格は、使用限度額およびリース見積もり、条件などを含み、これは初めに本人が出向いて直接折衝されており、おそらくユーザ２１５のビジネス要求を満たすものである。

システム１０はステップ３０２でそのレコードをサーチし、組織のリストを探す。ステップ３０２でその組織が存在する場合、システム１０は基本契約をホスト・サーバ１５に保管する（ステップ３０３）。その組織がシステム１０のレコード内に存在しない場合、従業員はステップ３０４でその組織に関するレコードを作成し、顧客の資格からその組織の情報を入力する。

次にシステム１０はステップ３０５でホスト・サーバ１５に基本契約を保管する。次に融資会社の従業員は、同じくステップ２０２でユーザ２１５によって提供される情報に基づいて、ステップ３１０でユーザ口座およびユーザ・グループを作成する。ユーザ２１５がその組織に関する文書に署名する権限が与えられていることをシステム１０がステップ３１５で検証した場合、融資会社はステップ３２０でユーザ２１５の指定の受信位置にクレジット・アクセス・トークンまたは保護されたパスワードを電子的に転送し、トークン転送に関する配達証明書を要求する。アクセス・トークンは、許可ユーザ２１５に対し物理的に郵送するかまたは電子メールで送信することができる。ユーザ２１５が文書に署名する権限が与えられていない場合、いかなるトークンも郵送されない。

ユーザ２１５は、自分の口座、デフォルト・パスワード、およびセキュリティ・コードを使用することにより、ステップ３２５で自分のユーザ登録ウェブ・サイトにアクセスすることができる。ユーザ登録ウェブ・サイトはユーザ基本契約を表示する。ユーザ２１５がステップ３３０でユーザ契約を辞退した場合、システム１０はステップ３４０でセッションを終了する。ユーザ２１５がステップ３３０で契約を受け入れた場合、ユーザ２１５の有資格口座はシステム１０によってステップ３３５で使用可能になる。マーチャントは、ユーザ２１５の基本契約口座がその時点で使用可能になっているという通知を受ける（ステップ２１０）。サービス方法３００および以下に示すサービス方法４００はほとんどの場合、ユーザ２１５の初期登録時に同時に行われることが予想される。

図２のステップ２０６でユーザ２１５について資格を作成し、定期的にそれをリフレッシュするサービス方法４００は図５のフローチャートにより詳細に示されている。見積もりは、特定のユーザ２１５に関するリースの契約上の詳細を含み、ユーザ名、アドレス、承認された信用限度額、融資を受ける資格のある製品、折衝されたリース・レートおよび条件／支払構造、ならびに基本契約に関連する任意の特殊な条件を含むいくつかの部分からなる。

資格プロセスは、融資会社がステップ３５０で資格付与見積もり（entitling quote）を作成したときに始まる。まず、ユーザ２１５に関するオンデマンド融資（ＦＯＤ）口座はＸＭＬフォーマットの資格付与見積もりによって供給される情報でステップ３５５で作成または更新される（たとえば、四半期ごとの更新）。システム１０でトランザクションを更新するために、融資会社の担当者はシステム１０にログオンし、新しい見積もりトランザクションを作成し、ユーザ２１５に関するリース・トランザクションを実行するために融資会社が必要とする信用限度額およびその他の契約データを確認し、標準化したＸＭＬフォーマットを使用してそれらをシステム１０にロードする。

ステップ３７５でシステム１０は関連するリース文書を生成する。システム１０は、この見積もりに関する定期的な要約レート補足および適格機器の関連リスト（別表Ａ）を構築する。レート補足は、複数カテゴリの製品に関するリース・レートをリストするものである。別表Ａは各カテゴリ内の機器のタイプを定義するものである。したがって、リース・レートおよび別表Ａは、来るべき四半期のすべてのトランザクションについて固定されている。融資会社の顧客契約担当者（customer contract representative）は、四半期ごとに１回、別表Ａを入力し、システム１０はその四半期中にすべての見積もりトランザクションで使用するためにそれを保管する。

ステップ３８０でシステム１０は、要求された通り、電子メールを介してユーザ２１５に通知する。この通知は、レート補足にアクセスするために必要なシステム１０のウェブ・サイトのＵＲＬおよび見積もり番号を含む。ユーザ２１５は、自分の資格がユーザ２１５について確立され、ユーザ２１５が自分の受入れを確認する準備ができていることをシステム１０によって通知される。ユーザ２１５は、システム１０によって提供される自分の安全な口座アクセスおよびｅ−署名機能により、自分の資格をオンラインで受け入れる。

ステップ３８５でシステム１０は、ユーザ２１５がレート補足に署名したかどうかをチェックする。レート補足が署名されていない場合、システム１０はステップ３９０で、その補足がどのくらい長い間、署名を待っているかをチェックする。１日などの所定の期間がまだ経過していない場合、システム１０はステップ３８５に戻り、ユーザ２１５の署名を待つ。

しかし、１日が経過した場合（ステップ３９０）、システム１０は、レート補足に関する署名が必要であるという催促状をステップ３９５でユーザ２１５に送信し、３日間などの延長（または最大）期間が経過したかどうかをステップ４０２でチェックする。経過していない場合、システム１０はステップ３８５に戻り、クライアントの署名を待つ。ステップ３８５〜４０２は、３日間が経過するかまたは署名がユーザ２１５によって提供されるまで繰り返される。この３日間の間、催促状は定期的に、すなわち、３回、毎日１回など、ユーザ２１５に送信される。

署名なしで３日間が経過した場合、システム１０はステップ４０５で顧客契約担当者（ＣＣＲ）に通知する。システム１０は、ステップ４０２で判定された通り、３回の通知後にレート補足に署名するのを辞退することによりユーザ２１５が契約を拒否したことを顧客契約担当者に知らせる。

ユーザ２１５のオンデマンド融資ウェブ・サイトで要約レート補足が許可を待っていることをステップ３８０で通知されると、ユーザ２１５はシステム１０にログオンし、要約レート補足ドキュメントにアクセスする。システム１０は、ユーザ２１５のアテンションを必要とする見積もりトランザクションのリストを提示する。

ユーザ２１５は、適切な要約レート補足、レート補足に対する別表Ａ、および任意の補遺を検索する。ユーザ２１５はステップ４１０で、要約レート補足および補遺にｅ−署名することにより、要約レート補足の条件を受け入れることができる。また、ユーザ２１５は、レート補足に署名しないかまたは条件を拒否する理由を融資会社に知らせることにより、レート補足の条件を辞退することもできる。

ユーザ２１５が条件を辞退した場合、システム１０はステップ４０５で顧客契約担当者に通知し、ステップ４１０でユーザ２１５が入力した理由を示す。次に融資会社の顧客契約担当者はシステム１０にアクセスして、見積もりトランザクションを更新する。顧客契約担当者は、必要であれば、同じ見積もり番号を保持する更新した新しい要約補足および／または補遺を入手し、ステップ３５５に戻ってプロセスを繰り返す。

ユーザが見積もりおよびその条件を受け入れた場合、システム１０はステップ４１５で顧客業務マネージャ（customer operations manager）（ＣＯＭ）に通知を電子メールで送信し、ユーザ２１５が要約レート補足および任意の補遺を受け入れたことを融資会社の顧客業務マネージャに知らせる。次に、融資会社の顧客業務マネージャは、必要であれば、システム１０からドキュメントを検索し、そのドキュメントを検討し、そのドキュメントに副署する。

ステップ４２０でシステム１０は、ユーザ２１５が署名したレート補足の各ベンダに通知を送信する。この通知は、ユーザ２１５の信用限度額、見積もり番号、および製品のリストを含む。システム１０は、見積もりドキュメントおよび別表Ａのドキュメントからベンダに送信される情報を導出する。ベンダはシステム１０にアクセスできず、この通知を介してその情報のすべてを受信する。各ベンダは、電子メールを介してリース許可証と同等のものを受信する。加えて、システム１０は、ユーザ２１５がレート補足を受け入れたという通知をステップ４２５で顧客契約担当者（ＣＣＲ）に送信する。

上記のプロセスは、定期的に（四半期ごとに）繰り返され、レートを価格設定し直し、別表Ａのリースすべき機器のリストを作成し直し、信用限度額状況を検討し、使用可能なクレジットをベンダに助言し直す。

図６および図７は、図２のステップ２５０以降に示す通り、機器のリースを開始し、関連のマーチャント送り状を決済するために融資会社がたどるサービス方法５００をより詳細に記述している。ユーザ２１５がオンデマンド融資条件を受け入れたことをベンダに通知する図５のステップ４２０に続いて、ベンダはステップ４３５で注文された製品を出荷する。

ステップ４４０でベンダは融資会社に電子フォーマットの送り状をサブミットする。各送り状は、それにより製品に融資されるリース契約を適切に識別するための見積もり番号を含む。電子送り状は、現在使用されているかまたは所定の位置にある融資会社の同じシステムにサブミットされる。オンデマンド融資のためのトランザクションは、着信送り状トランザクション（incoming invoiced transaction）の汎用プールから選択される。

次に送り状はステップ４４５でＸＭＬフォーマットに変換され、システム１０に転送される。ステップ４５０でシステム１０は見積もり番号、タイプ妥当性、または型式番号に矛盾があるかどうかをチェックする。送り状および見積もりが調整された場合、システム１０はステップ４５５に進み、そこでシステム１０は各トランザクションに含まれる見積もり番号に基づいてＸＭＬ送り状文書を正しいトランザクションに入れる。システム１０はステップ４５５で送り状文書から送達確認文書を構築する。

ステップ４６０では、システム１０はユーザ２１５の信用限度額の状況を判定する。限度額を超えている場合、システム１０は、ユーザ２１５の信用限度額を超えていることをステップ４６５でベンダおよび顧客契約担当者（ＣＣＲ）に通知する。

ユーザ２１５の信用限度額を超えていない場合（ステップ４６０）、システム１０はステップ４７０で送達確認にアクセスするための催促状としてオンデマンド融資ウェブ・サイトのＵＲＬと見積もり番号を含む通知をユーザ２１５に電子メールで送信する。次にシステム１０はステップ４７５（図７）でユーザ２１５が送達確認に署名したことを検証する。

送達確認に署名されていない場合、システム１０はステップ４８０でその補足がどのくらい長い間、署名を待っているかをチェックする。第１の期間、すなわち、１日が経過していない場合、システム１０はステップ４７５に戻り、ユーザ２１５の署名を待つ。

１日が経過した場合（ステップ４８０）、システム１０は、所定の最大期間、たとえば、１０日間が経過したかどうかをステップ４８５でチェックする。経過していない場合、システム１０はステップ４７０に戻り、もう１回、送達確認要求をユーザ２１５に送信する。ステップ４７０〜４８５は、１０日間が経過するかまたは署名がユーザ２１５によって提供されるまで繰り返される。この１０日間の間、通知は定期的に、たとえば、１０回、毎日１回など、ユーザ２１５に送信される。その後の各通知は、送達確認への署名を怠ると製品の送達を受け入れることになることを強調する異なるテキストを含む。ユーザ２１５が１０日後に送達確認への署名を怠った場合、システム１０はステップ４９５に進む。

ステップ４７５および４９０において、ユーザ２１５が文書に署名し、送達確認を受け入れたものとシステム１０が判定した場合、システム１０はステップ４９５で対応するベンダに通知する。ユーザ２１５が送達確認文書を受け入れない場合、システム１０はステップ４９９で対応するベンダに通知する。ステップ４５０で送り状に何らかの矛盾が見つかった場合にも、システム１０はステップ４９９でベンダに通知する。

ステップ４９９でシステム１０は、ユーザ２１５による送達確認文書の拒否の原因となった送り状作成のエラー、積残品、または誤配などをベンダに知らせる。ベンダは、ステップ４５０で通知された矛盾の問題すべてに対処し、ステップ４４０で訂正された新しい送り状を以前のようにサブミットする。

また、ステップ４９５でシステム１０は、ステップ４８５のデフォルトでまたはステップ４９５で送達確認を受け入れることにより、ユーザ２１５が送達確認を肯定応答したことを示す通知を見積もりトランザクション・システムに入れる。システム１０は、融資会社の顧客契約担当者および業務マネージャに通知し、使用可能なクレジットを減分する。必要であれば、顧客業務マネージャは副署する。

ステップ５１０でリースが実行済みトランザクションとしてリース見積もりシステムに記帳され、マーチャントに対する決済が開始される。システム１０は、ＵＣＣ−１ファイリング情報をレコード内に構築し、ＵＣＣ−１ファイリングを処理する外部サービスにこのレコードを渡す。このトランザクション・ドキュメントは、有資格ユーザにとって使用可能なオンライン・データベースにアーカイブされる。有資格ユーザは、現地の法律上のアーカイブ要件に応じて、数年分までの署名済みドキュメントをブラウズし、検索することができる。

次に、図２に関連してシステム１０のパフォーマンスを示す一例を説明する。リース構造化の利便性を希望するｅ−コマース・クライアントは、特定の融資要求を融資会社に持ちかける。クライアントは、トラクタ部隊など、自分が購入したい製品があり、各トラクタが１０，０００ドルを要することを知っている。この製品はインターネット上のベンダから入手可能である。クライアントは６ヶ月間に渡って１０台のトラクタを必要としている。

クライアントは、システム１０を使用してオンデマンド融資を提供する融資会社と折衝する。システム１０は、クレジット承認、リース構造およびリース・レート、条件を含むクライアント資格プロセスをプリパッケージする。ステップ２０２で融資会社は、顧客によって提供される情報に基づいてクライアントのクレジットを査定し、クレジット融資資格を生成する。両当事者は融資のレートおよび条件について合意し、融資会社は顧客の資格を生成する。

トラクタ・マーチャントのオンライン・ウェブ・サイトは事前合意により、システム１０からのオンライン融資をすでに統合している。システム１０はこの時点でクライアントの資格をトラクタ・マーチャントに通知する。クレジット・カード購入およびリース契約の場合とは異なり、トラクタ・マーチャントは、顧客が注文を行う前にクライアントがクレジットに値することを知らされている。システム１０の場合、トラクタ・マーチャントには、拡張クレジット・アクセスおよび金融構造化により売上増大の機会がある。

ステップ２２０で、クライアントは、数台のトラクタの購入を続行することを決定し、融資会社に対しリースでトラクタを出荷する権限をベンダに与える。トラクタはすべて顧客に出荷され、融資会社に送り状が送付される。融資会社は、送達を確認するクライアントに対し、送り状および送達確認をオンラインで提示する（ステップ２６５）。融資会社はステップ２７５でトラクタについてベンダに支払う。ベンダは送り状決済の加速の恩恵を受ける。予定の金融構造化はクライアントごとに異なる可能性があるが、トラクタ・マーチャントにとって透過なものである。

購入価格は、ステップ２０２における融資会社とユーザ２１５との間の契約に基づいて、ステップ２５０でリースに転換される。たとえば、１０，０００ドルの送り状は３６ヶ月の期間に渡って融資を受けることができる。融資会社は、ステップ２５５でクライアントのオンデマンド融資ウェブ・ページ上で送達確認および詳細なリース情報とともに送り状をポストし、その趣旨の通知をクライアントに送信する。

送り状の条件をクライアントが受け入れることを条件として、クライアントは従来のリースのように月賦払いで融資会社に支払うことになるであろう。このリース構造は、安全なドキュメント追跡およびアーカイブを介してインターネットによりクライアントの要求で使用可能な特別仕様の融資および信用限度額の利便性をクライアントに提供する。購入した商品または送り状について何らかの紛争が発生した場合、融資会社はステップ２７０でベンダに警告する。

記載されている本発明の特定の実施形態は単に本発明の原理の所与の適用例を例証するものに過ぎないことを理解されたい。本発明の精神および範囲を逸脱せずに、本明細書に記載したオンデマンド融資サービス発明を実現するためのシステムおよび方法に対し多数の変更を行うことができる。その上、ＷＷＷに関して例示のためにのみ本発明を記載したが、本発明は、任意の適切なネットワークによりアクセス可能な商業金融システムにも適用可能であることは明瞭であるはずである。

本発明のオンデマンド融資を実現するためのシステムおよび方法を使用できる例示的な動作環境の概略図である。 図１のオンデマンド融資システムの操作方法を示すプロセス・フローチャートである。 図１および図２のシステムおよび方法の例示的な高レベル階層を示す図である。 本発明のオンデマンド融資システムおよび方法を使用して顧客の資格および基本契約を作成する方法を示すプロセス・フローチャートである。 顧客が本発明のオンデマンド融資システムで注文を行う方法を示すプロセス・フローチャートである。 製品を注文し、リースにする方法を示すプロセス・フローチャートを表す。 製品を注文し、リースにする方法を示すプロセス・フローチャートを表す。

符号の説明

１０ オンデマンド融資システム
１５ ホスト・サーバ
２０ ネットワーク
２１５ ユーザ
２２５ オンライン・トランザクション・サーバ
２３０ ゲートウェイ
２３５ 処理ネットワーク
２４０ 融資会社サーバ
２４５ マーチャント銀行サーバ

Claims (35)

1. 顧客の資格を自動的に生成するステップと、
   前記顧客の資格に基づいて基本契約トランザクションを自動的に作成するステップと、
   顧客のクレジット承認を融資会社およびマーチャントに自動的に通知するステップと、
   顧客取引が承認されたときにネットワーク上で対応する送り状を自動的にポストするステップと、
   前記顧客の承認のために前記送り状がポストされたことを前記顧客に自動的に通知するステップと、
   を有する、送り状決済の加速に加えて大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化および各顧客ごとに予定された金融構造化を提供するために、ネットワークによりオンデマンド融資トランザクションの実現を自動的にカスタマイズするための方法。
2. 前記顧客の資格を生成するステップが、定期的に条件を生成するステップを含む、請求項１に記載の方法。
3. 定期的に前記条件を生成するステップが、四半期ごとに前記条件を生成するステップを含む、請求項２に記載の方法。
4. 前記顧客の資格が顧客の信用限度額を含む、請求項１に記載の方法。
5. 前記顧客の資格が顧客の融資条件を含む、請求項１に記載の方法。
6. 前記顧客の資格が、補足支払を入手したいという顧客の希望を含む、請求項１に記載の方法。
7. 前記顧客の資格が顧客の支払追跡を含む、請求項１に記載の方法。
8. 前記顧客の資格が顧客の支払明細プリファレンスを含む、請求項１に記載の方法。
9. 前記基本契約トランザクションが融資会社によって作成される、請求項１に記載の方法。
10. オンデマンド融資サーバが前記ネットワーク上で前記対応する送り状をポストする、請求項１に記載の方法。
11. 前記基本契約トランザクションを自動的に作成するステップが、前記融資会社の契約およびセキュリタイゼーション要件を満たす安全で法的に強制執行可能なドキュメントを生成するステップを含む、請求項９に記載の方法。
12. 製品を購入する前に前記顧客がレート補足および送達確認を承認するステップをさらに有し、
    前記顧客が前記送達確認を受け入れると、機器のリースが開始され、前記顧客がマーチャントの送り状の決済を実行することができる、請求項１に記載の方法。
13. 前記顧客の送り状について定期的にどのように融資されるかを示す詳細補足を前記顧客に対して表示するステップをさらに有する、請求項１２に記載の方法。
14. 顧客の資格を自動的に生成するための第１の組の命令コードと、
    前記顧客の資格に基づいて基本契約トランザクションを自動的に作成するための第２の組の命令コードと、
    顧客のクレジット承認を融資会社およびマーチャントに自動的に通知するための第３の組の命令コードと、
    顧客取引が承認されたときにネットワーク上で対応する送り状を自動的にポストするための第４の組の命令コードと、
    前記顧客の承認のために前記送り状がポストされたことを前記顧客に自動的に通知するための第５の組の命令コードと、
    を有する、送り状決済の加速に加えて大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化および各顧客ごとに予定された金融構造化を提供するために、ネットワークによりオンデマンド融資トランザクションの実現を自動的にカスタマイズするために命令コードが媒体上に埋め込まれているコンピュータ・プログラム記録媒体。
15. 前記第１の組の命令コードが定期的に条件を生成する、請求項１４に記載のコンピュータ・プログラム記録媒体。
16. 前記顧客の資格が顧客の信用限度額を含む、請求項１４に記載のコンピュータ・プログラム記録媒体。
17. 前記顧客の資格が顧客の融資条件を含む、請求項１４に記載のコンピュータ・プログラム記録媒体。
18. 前記顧客の資格が、補足支払を入手したいという顧客の希望を含む、請求項１４に記載のコンピュータ・プログラム記録媒体。
19. 前記顧客の資格が顧客の支払追跡を含む、請求項１４に記載のコンピュータ・プログラム記録媒体。
20. 前記顧客の資格が顧客の支払明細プリファレンスを含む、請求項１４に記載のコンピュータ・プログラム記録媒体。
21. オンデマンド融資サーバが前記ネットワーク上で前記対応する送り状をポストする、請求項１４に記載のコンピュータ・プログラム記録媒体。
22. 前記基本契約トランザクションが、融資会社の契約およびセキュリタイゼーション要件を満たす安全で法的に強制執行可能なドキュメントを含む、請求項１４に記載のコンピュータ・プログラム記録媒体。
23. 前記顧客の送り状について定期的にどのように融資されるかを示す詳細補足を前記顧客に対して表示するための第６の組の命令コードをさらに有する、請求項１４に記載のコンピュータ・プログラム記録媒体。
24. 顧客の資格を自動的に生成するための手段と、
    前記顧客の資格に基づいて基本契約トランザクションを自動的に作成するための手段と、
    顧客のクレジット承認を融資会社およびマーチャントに自動的に通知するための手段と、
    顧客取引が承認されたときにネットワーク上で対応する送り状を自動的にポストするための手段と、
    前記顧客の承認のために前記送り状がポストされたことを前記顧客に自動的に通知するための手段と、
    を有する、送り状決済の加速に加えて大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化および各顧客ごとに予定された金融構造化を提供するために、ネットワークによりオンデマンド融資トランザクションの実現を自動的にカスタマイズするためのシステム。
25. 顧客の資格を自動的に生成するための手段が定期的に条件を生成する、請求項２４に記載のシステム。
26. 前記顧客の資格が顧客の信用限度額を含む、請求項２４に記載のシステム。
27. 前記顧客の資格が顧客の融資条件を含む、請求項２４に記載のシステム。
28. 前記顧客の資格が、補足支払を入手したいという顧客の希望を含む、請求項２４に記載のシステム。
29. 前記顧客の資格が顧客の支払追跡を含む、請求項２４に記載のシステム。
30. 前記顧客の資格が顧客の支払明細プリファレンスを含む、請求項２４に記載のシステム。
31. オンデマンド融資サーバが前記ネットワーク上で前記対応する送り状をポストする、請求項２４に記載のシステム。
32. 前記基本契約トランザクションが、融資会社の契約およびセキュリタイゼーション要件を満たす安全で法的に強制執行可能なドキュメントを含む、請求項２４に記載のシステム。
33. 前記顧客の送り状について定期的にどのように融資されるかを示す詳細補足を前記顧客に対して表示するための第６の手段をさらに有する、請求項２４に記載のシステム。
34. 顧客の資格を自動的に生成することと、
    基本契約トランザクションを自動的に作成することと、
    顧客のクレジット承認を融資会社およびマーチャントに自動的に通知することと、
    を有する、送り状決済の加速に加えて大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化および各顧客ごとに予定された金融構造化を提供するために、ネットワークによりトランザクションの実現を自動的にカスタマイズするためのオンデマンド融資サービス。
35. 顧客の資格の自動生成と、
    基本契約トランザクションの自動作成と、
    顧客のクレジット承認に関する融資会社およびマーチャントへの自動通知と、
    を有する、送り状決済の加速に加えて大幅に拡大されたクレジット・アクセスによる製品販売の容易さの強化および各顧客ごとに予定された金融構造化を提供するために、ネットワークによりオンデマンド融資トランザクションの実現を自動的にカスタマイズするためのサービス・モデル。

Images