JP2005527046A - 動的割引合意を備えた購入者と供給業者の間の電子決算を変更するシステム及び方法 - Google Patents

Abstract

リクエストが、確立された合意を有する取引に対して購入者（１０１）及び販売業者（１０２）の間での支払いを成し遂げるために受信される。合意は、支払額及び決算日を含んでいる。確立された合意以外の支払いに対する新たな合意の申し出及び受理を含むメッセージが、購入者と販売業者の間で交換される（１０３）。前記新たな合意は、取引と協働するイベント後の特定時になされることになる、調整された支払額を含んでいる。イベントが発行されたという電子的通知が受信されると、その通知後、新たな合意の下で、購入者と販売業者の間での支払いがなされる。一実現方法では、新たな合意の受理を指示するデジタル署名が受信される。別の実施例は、エンティティの設定を有する取引の設定を成し遂げるためにリクエストを受信することを含む支払い方法に向けられる。確立された合意と異なる合意の申し出のためのリクエストは、エンティティに送信され、異なる合意は、イベント後の特定時になされる支払いに適用されることになる。申し出（１３０）は、リクエスト（１３１）に応答して受信され、申し出間の申し出の設定は、１又は複数の基準の設定に基づいて選定される。申し出のためのリクエスト及び申し出の選定は、目標探索処理に基づいてなされ得る。別の実施例は、購入者、販売業者及び金融機関のような第三者を伴う支払い方法に向けられる。

Description

本発明は、ソフトウェア及びコンピュータネットワークの分野に関する。特に、本発明は、金融取引と協働する電子システムに関する。

米国特許出願、出願番号１０／１５５，７９７ 米国特許出願、出願番号１０／１５５，８００ 米国特許出願、出願番号１０／１５５，８４０ 米国特許出願、出願番号１０／１５５，８５３ 米国特許出願、出願番号１０／１５５，８６６

本出願は、これに添えて同日に出願した以下の米国特許出願：
代理人整理番号25923.703、発明者Duc Lam, Georg Muller, Chandra(CP) Agrawal, Baby Lingampalli, Pavel Lopin及びXuan(Sunny) Mcrae、特許文献１のMethod and System for Collaborative Vendor Reconciliation；
代理人整理番号25923.704、発明者Duc Lam, Matthew Roland及びXuan(Sunny) McRae、特許文献２のSystem and Method for Electronic Aunthorization of Batch Checks；
代理人整理番号25923.706、発明者Duc Lam, Ramnath Shabhorue, Lmmanuel Kan, Bob Moore及びXuan(Sunny) McRae、特許文献３のSystem and Method for Electronic Payer(Buyer) Defined Invoice Exchange；
代理人整理番号25923.707、発明者Bob Moore及びXuan(Sunny) Mcrae、特許文献４のMethod and System for Invoice Routing and Approval in Electronic Payment System；及び
代理人整理番号25923.708、発明者Duc Lam, Celeste Wyman及びXuan(Sunny) McRae、特許文献５のMethod and System for Buyer-Centric Dispute Resoluin Electronic Payment System、に関する。前述の出願の全ては、その全体の参照によってこの中に取り込まれている。

従来の紙幣支払いシステムでは、組織又は個人は、どこにデビットが払われるかという物理的なチェックを当事者に送信することによって開始する。チェックは、デビットが支払われる当事者からのインボイスに応答して送信される。より最新のアプローチは、電子的な支払いである。例えば、消費者事情において、個人が電子バンキングを経由して支払いをすることができる。支払い命令は、個人のコンピュータシステムから個人の銀行に電子的に送信される。支払いは、その後、銀行によって成し遂げられる。

ここで、決算及び請求書支払いに関して多数のシステムが存在する。例えば、コンピュータソフトウェアがインボイスを追跡することや支払いチェックをプリントするのに用いられる。支払いは、支払いが成し遂げられることになる当事者の口座に転送されるように、一の金融機関で支払人のファンドを要求する命令を用いて、電信送金によってなされる。

管理業務統合（ＥＲＰ）システムは、商品及びサービスの購入を管理するのに用いられる。前記システムは、様々な供給業者の住所及び購入に関連する同様な情報のような複雑なデータベース及び情報の拡張設定を有する。また、販売業者は、電子会計を利用し、受信を援助するシステムを保存し、商品及びサービスに対する支払いの受信を追跡して記録する。先のシステムは、更新して維持するにはかなりの量の努力を必要とし、また、組織が取引において保証したい、当事者によって用いられるシステムとの互換性を欠く。従って、購入者と販売業者との間の取引を容易にするための改善されたシステムが必要とされる。

本発明の実施例は、支払い方法に向けられる。要求は、購入者と販売業者との間で確立された合意を有する取引の支払いを遂げるために受信される。合意は、支払い額と決算日を含んでいる。確立された合意以外の支払いに対する新たな合意のオファーと受理を含むメッセージが、購入者と販売業者との間で交換される。新たな合意は、取引に関連するイベントの後の特定時になされる調整された額の支払いを含んでいる。イベントが発生したという電子的通知が受信されると、その通知後、販売業者と購入者との間の支払いが新たな合意の下で達成される。一つの実現方法では、新たな合意の受理を示すデジタル署名が受信される。システムは、新たな合意の下での手続きの前に前記署名を検査する。

異なる実現方法によると、イベントは異なる形態の電子的通知を含んでいる。例えば、一の実現方法では、イベントは、購入者による販売業者のインボイスの承認の電子的表示を含んでいる。他の実現方法によると、イベントは、販売業者が取引において注文された商品を輸送しているという電子的表示、購入者が取引において注文された商品を受信したという電子的通知、又は購入者が取引に対する支払いを許可したという電子的通知を含んでいる。

異なる合意は、異なる形態を取る。例えば、本発明の一実施例では、異なる合意は、決算日とイベントとの間の特定時の支払いと引き替えの割引を含んでいる。別の実現方法では、確立された合意は、販売業者が特定の割引を売り出すのに同意する割引日を含んでおり、新たな合意は、確立された合意で提供された割引とは異なる、割引日よりも早い特定時の支払いと引き替えの割引を含んでいる。別の実現方法では、新たな合意は、確立された合意で提供される割引とは異なる、割引日よりも遅い特定の時の支払いと引き替えの割引を含んでいる。

本発明に係る別の実施例は、新たな合意に従って支払いをする方法に向けられるが、この場合、新たな合意は、取引に対するインボイスに関連するイベント後の特定時になされる調整された支払い額を含んでいる。インボイスは販売業者から受信されると、インボイスに関連するイベントが発生したという電子的通知が受信される。通知後、新たな合意の下で購入者と販売業者との間の支払いがなされる。

本発明に係る別の実施例は、エンティティの設定を用いて取引の設定を成し遂げるためのリクエストを受信することを含む、支払い方法に向けられる。取引は、確立された合意を有する。取引と協働するイベントの通知設定が受信される。確立された合意と異なる合意のオファーに対するリクエストは、エンティティに送信され、異なる合意は、イベント後の特定時になされた支払いに適用されることになる。オファーは、リクエストに応答して受信され、オファーの中でのオファー設定は、１又は複数の基準の設定に基づいて選定される。それぞれのイベントの後、支払いは、それぞれのオファーにおける合意の下、選定されたオファーに関連するそれぞれのエンティティに対して達成される。エンティティの設定は、販売業者を含み、オファーのためのリクエストの設定は、購入者のシステムによって送信される。

本発明の異なる実施例によると、前記リクエスト及び／又はオファーは、異なってなされる。例えば、１つの実現方法によると、合意のオファーのための個々のエンティティに対して一連のリクエストがなされ、オファーは、連続するリクエストに応答して個々のエンティティから受信される。利益を有してより魅力的な個々のエンティティであるリクエストが時を経て合意と共になされる。別の実現方法では、メッセージは、エンティティが合意のオファーをするために選定する一連の異なる合意と共に個々のエンティティに送信される。一連の異なる合意は、申し込まれた支払い額とその関連する支払い日の設定を含んでいる。前記設定は、少なくとも幾つかの提案される支払い日に関連する多数の提案される支払い額を含んでいる。

上記で示されているように、オファーは、１又は複数の基準に基づいて選定される。１又は複数の基準の設定は、一実現方法によるとそれぞれのエンティティの危機分析を含んでいる。別の実現方法では、１又は複数の基準の設定は、取引毎の節約額を含んでおり、別の実現方法では、それは、それぞれの取引の決算日までの残りの時間量を含んでいる。

本発明の別の実施例は、購入者、販売業者及び第三者を伴う支払いをする方法に向けられる。一実施例によると、第三者は、銀行のような金融機関である。購入者と販売業者の間の取引の実体に関係する通知が受信される。取引は、支払い額及び決算日を含む、確立された合意を有している。メッセージは、購入者、販売業者及び第三者の間で交換され、確立された合意以外の支払いに対する新たな合意のオファーと受理を含んでいる。新たな合意は、取引に関連するイベント後の特定時に第三者によって販売業者に対してなされる支払い額を含んでいる。イベントが発生したという電子的通知が受信される。通知後、調整された額の支払いが、新たな合意の下で第三者から販売業者に対してなされる。第三者による支払いの後、購入者と金融機関の間の支払いは、新たな合意の下で成し遂げられる。一実現方法によると、合意は第三者と購入者の間で交渉され、第三者と販売業者の間の合意から独立している。取引は、販売業者及び購入者の両者を拘束する。イベントは、異なる実施例によると、販売業者による販売業者のインボイスの承認の電子的表示、販売業者が取引で注文される商品を輸送したという電子的表示、購入者が取引で注文した商品を受信したという電子的表示、又は購入者の組織におけるエンドユーザが取引で注文した商品を受信したという電子的表示を含んでいる。

本発明の別の実施例は、支払いをするシステムに向けられる。システムは、販売業者に関連する第１のシステムと購入者に関連する第２のシステムを含んでいる。第１のシステムは、インボイスを発生させ、そのインボイスを購入者に送信する論理を含んでいる。インボイスは、関連する合意の設定を有する。また、第１のシステムは、インボイスに関連する合意以外の新たな合意の設定のために購入者からのオファーのためのリクエストに応答して、購入者に対して少なくともオファーを送信する論理を含んでいる。オファーは、インボイスの処理に関連するイベントの後の支払いに適用される。購入者に関連する第２のシステムは、販売業者からのインボイスを受信する論理及びオファーのためのリクエストを発生させて販売業者に送信する論理を含んでいる。また、第２のシステムは、販売業者からのオファーを受信する論理、販売業者からのオファーを受理して電子的表示を販売業者に送信する論理、及びインボイスの処理に関連するイベントの電子的表示を発生させる論理を含んでいる。さらに、第２のシステムは、インボイスの処理に関連するイベントの電子的表示の受信後に新たな合意に従って購入者から販売業者への支払いを達成する論理を含んでいる。

特定の実現方法によると、第２のシステムは、新たな合意設定オファーのためのリクエストを複数の販売業者と関連するシステムに送信する論理を含んでいる。オファーは、関連するインボイスの処理と協働するイベント後に支払いに適用され、新たな合意は、インボイスに関連する、以前確立された合意とは異なる。また、この論理は、オファーの一部を受理し、新たな合意のためのオファーに応答してそれぞれのイベントの後の新たな合意の下で支払いを達成する。

本発明の別の実現方法は、目標を満たすか否かに基づいてオファーの一部を選定する論理を含んでいる。目標は、節約額、目標の期間、又は金額と期間の組み合わせを含んでいる。また、目標は、他の財政上の目標又はリスクに対する目標と許容範囲の組み合わせのような他の基準を含んでいる。

本発明の別の実施例では、第１のシステムは、新たな合意設定オファーのためのリクエストを複数の購入者に関連するシステムに送信する論理を含んでいる。オファーは、関連するインボイスの処理と協働するイベント後の支払いに適用される。また、論理は、オファーの一部を受理し、それぞれのイベント後の新たな合意の下で新たな合意のオファーに応答して支払いを受理する。

本発明に係る実施例は、それぞれの取引に関連するイベントの電子的通知に基づいて取引上の支払いの合意を動的に調整するシステムに向けられる。例えば、早期の支払いは、それぞれのインボイスの承認又はインボイスに対する支払いの解除のようなイベントの電子的通知の受信後になされる。オファーは、それぞれのイベント後の時期の支払いに適用される合意を調整するためになされる。一実現方法では、購入者等の１つのエンティティは、前記エンティティとそれぞれの他のエンティティとの間の確立された合意と異なる合意のオファーのために、販売業者等のエンティティの設定に対してリクエストを送信する。一実現方法では、オファー間でのリクエスト選定を送信したエンティティは、目標に基づいてエンティティの設定を受信する。リクエストを送信したエンティティは、目標が達成されるまで新たな合意のオファーを評価し続ける。オファーの受理後であって、新たに承認された合意の下でのそれぞれのイベント後に、支払いがなされる。

イベントの電子的通知は、支払いをしている組織における従業員又は他の個人の動作に基づいてなされる。例えば、イベントは、取引に関連するインボイスの責任のある従業員による承認である。１つの実現方法では、応答は、支払人組織の従業員によって受信されるインボイスに関係している電子メール通知に対する応答を通してなされる。従業員は、注文のステータスを考慮してイベントに基づいたインボイスを承認できる。例えば、注文商品が受信されたことを従業員が確定する際に、従業員はインボイスを承認する。インボイスの承認は、代替的には、自動的に生じる。例えば、インボイスは、商品が受信され、インボイスデータが対応する注文書と比較して正確であるという通知を、調達システムが送信する際に、自動的に承認される。

本発明に係る一実施例は、それぞれの注文のステータスに関係しているイベントの電子的通知後の承認された時期以外であって承認された合意以外における支払いをすることに向けられる。注文のステータスに関係しているイベントの電子的通知は、異なる実現方法によると、信頼性の異なるレベルを提供するイベントに関係している電子的通知を含んでおり、それぞれの商品又はサービスが納得のいくように受信され、支払いが適切に許可される。前記イベントは以下を含んでいる。
・購入者から販売業者へ送信される注文書
・購入者代理としての販売業者購入部分
・販売業者によって購入される注文部分
・販売業者によって完了された商品
・満期の特定の割合まで完了された商品
・完了した製品の検査
・郵送の準備完了を指示された商品
・販売業者によって送信される発送
・共通キャリアを有している発送
・購入者によって受信された発送
・他の購入者の発送確定ステータス
・発送を注文した購入者の組織におけるエンドユーザ個人によって受信される発送
・サービス開始
・サービスの特定割合の完了、サービス完了
・エンドユーザによって承認されるインボイス
・支払うべき請求書によって承認されるインボイス
・責任のある管理者によって承認されるインボイス
・購入者の組織におけるインボイスの最終承認
・購入者組織内の支払うべき部門によって承認されるインボイスに対する支払い
・支払いに対して受信される承認
・解除を承認された支払い
・商品又はサービスが満足のいくような配信である、特定レベルの信頼性を指示する購入者によって画定される他のイベント

それぞれのイベントの電子的通知が提供される。様々な実現方法では、前記イベントの強力かつ補助的な設定み合わせは、最初に承認された同意以外の同意の下で支払いをトリガーするようにユーザが選定するのに利用できる。例えば、１つの実現方法では、前記システムにより、購入者は、いずれか又は一部の次のイベント、すなわち（１）注文書が販売業者に送信され、（２）インボイスが承認され、（３）支払いはそれぞれの注文を承認される、というイベントの後、支払いをすることができる。購入者は、その後、これらのイベントのうちのどれが、特定の取引、特定の販売業者、又は取引の設定すなわち販売業者の設定に対する支払いをトリガーするのに用いられることになるかをリスク及び他の要素に基づいて選定することができる。

購入者及び販売業者は、異なる要素に基づいて支払いに対する新たな合意を交渉する。例えば、選定される金利計算に基づく単純な時間価値に基づいて、支払い額の変化は、支払いが行われる最初に承認された決算日より早い又は遅い日数に基づいて計算され得る。販売業者の最初の合意、すなわち販売業者と購入者の間で最初に取り決めた合意で提供する、割引から推定される金利が利用される。前記アプローチの利点は、支払い合意の調整のために、より大きな細分度が本発明に係る一定の実施例で提供されることである。

本発明の一実施例は、支払い合意の１の変化又は複数の変化のために多数の当事者からのオファーをリクエストして、注文のステータスに関係する電子的通知後に承認された同意以外についての支払いをすることに向けられる。オファーのための前記リクエストは、販売業者に関係するように購入者によってなされ、販売業者は購入者に関係し、販売業者の組み合わせはそれぞれの購入者に関係することになる。前記リクエストが送信される当事者は、取引の大きさ、受信されることになる可能性のある節約、得られることになる最新キャッシュフローの可能性のある額、当事者が耐え得る基準、取引で残された合意の額、及び信用等級すなわち特定の当事者に接した経験のような他のエンティティについては、信頼性に関連する他の要素に基づいて選定される。取引の大きさに基づいた選定は、全体として当事者との未処理の取引の大きさに基づいてなされ、代替的に、個々の取引の大きさに基づいてなされる。オファーは、その後、達成されることになる節約の総計又はキャッシュフローにおける前払い額のような目標に基づいて受理される。

オファーに対するリクエストは、イベントのそれぞれの電子的通知が発生する時になされる。代替的に、交渉は、それぞれのイベントの電子的通知が発生した後に行われるように合意に対する調整タイプを考慮してそれぞれの当事者間で行われる。例えば、購入者及び販売業者は、購入者が注文に対するインボイスを承認した後に、金利に基づき、かつ最初に要求された決算日の前の残りの日数に基づいて、購入者が早期の支払いをすること、及び支払われるべき額の調整を受信することに同意する。

図１は、本発明に係る実施例に従う、割引を有する支払いシステムのブロック図を示す。図１は、支払人システム１０１及び受取人システム１０２を含んでいる。支払人システム１０１は、プロセッサ１１０及び入／出力（Ｉ／Ｏ）１０９のようなコンピュータ電子部品を含んでいる。コンピュータサーバで見つけられるものような他の電子部品は、本発明に係る実施例に従って支払人システム１０１に含まれ得る。支払人システム１０１は、それに接続されるルート割当て論理１０４及び承認論理１０５を含んでいる。承認論理１０５はまた、支払人システム１０１に含まれている、支払い解除論理１０６、合意調整１０７及び注文ステータス論理１１１と接続されている。また、支払人システムは、決算論理１０８を含んでおり、支払い解除論理１０６及び受取人システム１０２の決算論理１２３に接続され、オファー１３０は、合意調整論理１０７及び販売業者システム１０２のオファー論理１３１に接続されている。支払人システム１０１のルート割当て論理１０４は、支払人システム１０１で受信されるインボイス１０３に接続されている。

受取人システム１０２は、インボイス作成論理１２０を含んでおり、支払人システム１０１のインボイス１０３に接続されている。また、受取人システム１０２は、承認／通知論理１２１を含んでおり、また、受取人システム１０２によって含まれる合意調整１２２及び決算論理１２３と接続されている。加えて、受取人１０２は、オファー論理１３１を含んでおり、割引論理１２２及び支払人システム１０１のオファー論理１３０に接続されている。受取人システムは、インボイス作成論理１２０を用いてインボイスを作成する。インボイスは、一実現方法によると、支払人システム１０１によって提供されるインボイス定義に基づいて作成される。インボイス１０３は、受取人システム１０２のインボイス作成論理１２０から支払人システム１０１によって受信される。

インボイス１０３は、インボイスが承認されて支払いのために検査されるように、適切な人員又は機構にルート指定される。承認は、ルート割当て論理１０４と接続される承認論理１０５によって実行される。承認は、特定の注文のステータスに基づいており、前記ステータスは、注文ステータス論理１１１によって自動的に得られる。注文ステータスは、インボイスが受信される商品が輸送されているか否か、又はそれらが支払人組織によって受信されているか否か、というような項目を含んでいる。注文ステータス論理１１１は、ジャストインタイム（ＪＩＴ）に基づいて、受信される装備又は他の在庫管理システムの数に関する情報を自動的に利用できるような注文情報に関係する付加的情報を得る。従って、注文ステータス論理１１１は、管理業務統合（ＥＲＰ）システムと接続され得る。それぞれの注文が承認された後、支払いが解除され、支払いがなされる。前記動作は、承認論理１０５と接続される支払い解除論理１０６によって実行される。

オファー論理１３０は、特定の取引に関連する、それらの確立した合意以外の異なる合意のオファーのためのリクエストをする。それぞれの合意の受理に関して、取引は異なる受理された合意の下でなされ得る。従って、オファー論理１３０は、合意調整論理１０７と通信し、特定の１の取引又は複数の取引に適用される合意を調整する。オファーのためのリクエスト及びそれぞれの応答の受信は、本発明に係る一実施例によると、支払いをトリガーするイベントに先立ってなされる。代替的に、オファーに関係する少なくとも幾つかの相互作用する部分は、取引に対するインボイスが支払人システム１０１で承認されている電子的通知の受信後のような、それぞれのイベントの電子的通知の受信に基づいてなされる。オファー論理１３０は、オファーが受理される基準を含んでいる。前記実現方法では、オファーは、それが構成される基準を満たすものである場合にのみ受理される。新たに画定される合意に対するオファーの受理に基づいて、それぞれのイベントの電子的通知の受信の後に、合意調整論理１０７は、新たな決算日及び支払い額を計算する。通知は、新たに画定される合意のオファーの受理を指示するために販売業者システム１０２に送信される。

合意調整論理１０７は、（割引のような）最初の支払い額に対するそれぞれの調整を実現し、調整された支払い日に引き替えてなされることになる。合意調整論理は、支払い解除論理１０６及び承認論理１０５と接続されており、調整された支払いは、インボイスの承認又はそれぞれの支払いの解除に関してトリガーされる。合意調整論理１０７は、それぞれの割引を調停するために受取人システム１０２の割引論理１２２と通信する。決算論理１０８は、受取人システム１０２の決算論理１２３と通信して支払人システム１０１と受取人システム１０２の間のそれぞれの支払いを処理する。前記決算は、それぞれの額の支払いから合意調整論理１０７によって決定される早期支払いに対して取られる任意の割引分を割り引く処理をする。

示される論理モジュールは、互いに通信するソフトウェア処理で実現される。幾つかの機能性は、デザイン、効率性及び他の理由のために異なるそれぞれのモジュール間で共有され得る。代替的に、それぞれの論理モジュールの特徴は、ハードウェア又はハードウェアとソフトウェアの組み合わせで実現され得る。示される機能は、プロセッサ１１０及び入／出力（Ｉ／Ｏ）１０９を用いてここで示されるようなプロセッサ入／出力を備えたコンピュータシステムで実現され得る。従って、支払人システム１０１は、コンピュータサーバで実現され、受取人システムは、異なるコンピュータサーバで実現される。代替的に、支払人システム１０１及び受取人システム１０２の機能は、共通のサーバで実現される。また、様々なシステムの機能が異なるコンピュータシステム又はサーバに配置される。前記コンピュータシステム又はサーバは、直接的なリンクを通して又はインターネットのようなコンピュータネットワークを介して通信する。

図２は、本発明に係る実施例に従う割引支払いのフロー図を示す。オファーは、支払い額の調整と引き替えに、支払いタイミングを調整するためになされる。オファーが受理される場合、インボイスは、新たに承認された支払いの同意に従って支払われる。トリガーイベントは、その後に支払いがなされるイベントである。トリガーイベントは、最初の支払い期日前のインボイス承認又は最初の支払い期日前のインボイスに対する支払い解除のようなイベントである。

初めの支払いの合意は、最初の支払い期日で確立される（ブロック２０１）。次のオファーは、合意プログラムの調整のためになされる。販売業者の場合、販売業者は購入者による早期の支払いの引き替えに別の支払われるべき額の割引を購入者にオファーする（ブロック２０２）。購入者の場合、購入者は、購入者によって別の支払われるべき額からの割引に引き替えて早期支払いを販売業者にオファーする（ブロック２０３）。早期支払いに対する割引をオファーする前記プロセスは、本発明に係る実施例によると、異なる合意のために様々な購入者又は販売業者にリクエストを送信するシステムによって自動的に実行される。他の当事者から早期支払いに対する割引への同意が受信されない場合（ブロック２０４）、その後、最初の合意に従って支払いがなされる（ブロック２０５）。他の当事者から早期支払いに対する割引への同意が受信される場合（ブロック２０４）、その後、インボイスの処理に進行し、割引を提供する。支払いを調整するための他の解決がこの段階で確立され得る。例えば、購入者は、購入者によって支払われる額の調整と引き替えの特定のトリガーイベント後であって、最初の決算日と関係がある日に支払うことに同意する。１つの例では、前記調整は、最初に確立された支払いの合意の下で要求される支払いからの割引である。

また、合意は、調整される合意のオファーをすることよりもむしろ調整される合意のオファーのためにリクエストをして、交渉を始めるそれぞれの当事者によって調整される。前記リクエストをしている当事者は、その後、受信されるオファーを受理するか否かを決定する。前記リクエスト及び結果として生じるオファーの交換は、本発明に係る１つの実現方法に従い、トリガーイベントの受信後になされる。従って、前記アプローチでは、支払いがなされる実際の時間は、トリガーイベントが確立され、前記日付又は可能な日付になされるように対応する支払い額が提案された後である。別の実現方法によると、オファー及びキャンペーンプロセス定義／設定は、入ってくるインボイスから独立している。トリガーイベントは、ビジネスドキュメントが承認される場合、受信される場合、又はドキュメントに関係する他のイベント又は注文が発生する場合に生じる。

インボイスは、ベンダーシステムにおいてベンダーから受信される（ブロック２０６）。前記インボイスは、本発明に係る一実施例に従って、購入者によって提供されるルールの設定に基づいてベンダーによって作られる。次に、販売業者インボイスが、確認される(ブロック２０７)。前記確認は、インボイスに提供されるデータの様々な基準をチェックすることを含んでいる。前記確認は、本発明に係る一実施例に従って、購入者によって提供されるルールの設定に基づいている。完了したインボイスが、その後、署名され、暗号化される（ブロック２０８）。本発明に係る一実施例に従って、インボイスの署名は、販売業者のデジタル署名を用いて実行され、受領者は、インボイスが販売業者によって送信されていることを確かめる。インボイスは、セキュリティを提供するために暗号化される。暗号化は、公開鍵／秘密鍵方式を用いて実現され、暗号化は、受領者の公開鍵を用いて実行される。その後、インボイスは、公開鍵／秘密鍵方式に従う受領者の公開鍵を用いて遅れて暗号化され得る。次に、インボイス購入者システムに送信される（ブロック２０９）。前記送信は、インボイスを電子メールフォーマットに配置し、購入者システムと販売業者システムの間の電子メールリンクを介してその電子メールを送信することによって実行される。代替的に、電子通信の他の形態が、ｈｔｔｐ ｐｏｓｔ、ｆｔｐ、電子データ交換（ＥＤＩ）のようなインボイスを送信するのに用いられる。

インボイスは、購入者システムで受信される（ブロック２１０）。インボイスは、購入者システムにおいて複合化され、認証される（ブロック２１１）。前記複合化は、インボイスが購入者の公開鍵を用いて暗号化されていることを想定して、購入者の公開鍵を用いて実行される。インボイスは、それが販売業者によって送信されるか否かを決定することによって認証される。前記認証は、公開鍵／秘密鍵方式を伴っており、インボイスは販売業者システムによってデジタル的に署名されていることを想定して、販売業者の公開鍵を用いて実行される。インボイスのデータは、それが購入者によって望まれる一定の特性を満たすことを確実にするために確認される（ブロック２１２）。前記特性は、インボイスのデータが一定の値を有するか否かに加えてデータフォーマットのような項目を含んでいる。

次に、インボイスは、購入者システムにルート割当てされる（ブロック２１３）。インボイスは、インボイスに関するそれらの入力を受信するために購入者システム内の様々な受領者にルート割当てされる。それらの入力は、インボイスの承認又はインボイスの受信の通知を含んでいる。ルート割当てプロセスにおける受領者による承認のようなイベントに基づいて、トリガーイベントが発生する。また、トリガーイベントは、注文ステータスを考慮して自動更新に基づいている。例えば、一実現方法では、システムは、それぞれの商品が輸送されていること、又はそれぞれのサービスが開始されていることを自動的に決定する。代替的に、システムは、それぞれの商品が受信されていること、又はそれぞれのサービスが完了されていることを自動的に決定する。前記決定は、トリガーイベントを自動的に更新する。代替的に、前記情報は、ルート割当てプロセスを通してユーザ入力に基づいて得られる。ユーザは、本発明に係る一実施例に従って、それぞれのインボイスに関係している電子メールのような電子的通知を受信する。ユーザは、その後、メッセージに応答でき、注文のステータスを指示する。例えば、電子メールは、注文される製品のそれぞれのエンドユーザにルート割当てされる。その後、ユーザは、本発明に係る一実施例に従って、ユーザが注文した商品を受信したことを指示するシステムに電子的通知を提供する。ユーザからの前記指示に応答して、システムは、トリガーイベントを自動的に生じさせる。代替的に、ユーザは、インボイスの承認を指示する。

トリガーイベントは、異なるタイプのイベント間から選定される。例えば、ここで示されるように、システムは、インボイス承認又は予定される支払いの解除のいずれかのトリガーイベントを提供する（ブロック２１４）。インボイス承認は、多くの要素に基づいて決定される。示されているように、インボイスは、管理業務統合（ＥＲＰ）システムに通知される（ブロック２１５）。ＥＲＰシステムは、マッチングルールを実行することを通知する（ブロック２１６）。システムは、インボイスのステータスを監視し、それがユーザによって承認されるか否かのようなインボイスで取られる動作を決定する（ブロック２１７）。インボイスが承認される場合、又は一定の時間内に承認されない場合、それぞれのステータスが販売業者に送信される（ブロック２１８）。前記動作に基づいて、インボイスの承認が最初の支払い期日前に受信される場合（ブロック２１９）、その後、調整された支払いがなされる（ブロック２２０）。インボイスの承認が最初の支払い期日前に受信されない場合、前記動作がトリガーイベントであることを想定して、支払いは最初の合意に従ってなされる（ブロック２２２）。調整された支払いは、トリガーイベントのすぐ後に行われる。代替的に、初期の支払いは、トリガーイベントの一定時間後であって、最初の支払い期日前に行われる。

一実現方法によると、調整された支払いを用いた新たな合意の設定のオファーのためのリクエストは、トリガーイベントの受信後に送信される。オファーは、オファーのためのリクエストに応答して販売業者にから受信される。購入者は、販売業者がオファーすることになる新たな合意を提案する。購入者は、販売業者によって提案されたオファーを拒否することを決定すると、代わりに最初の合意に従って支払いをする。

新たな合意が受理されている場合であって、トリガーイベントが予定される支払いの解除である場合（ブロック２１４）、その後、支払いの解除が最初の支払い期日の前に生じているか否かが決定される（ブロック２２１）。支払いの解除は、最初の支払い期日によっては生じない場合（ブロック２２１）、その後、支払いは最初の合意に従ってなされる（ブロック２２２）。支払いの解除が最初の支払い期日の前に予定されている場合（ブロック２２１）、トリガーイベントは予定される支払いの解除であり、その後、割引された早期の支払いがなされる（ブロック２２０）。早期の割引された支払いは、トリガーイベント後すぐに行われる。代替的に、早期の支払いは、トリガーイベント後の一定時間後であって、最初の支払い期日の前に行われる。

図３は、本発明に係る一実施例に従うエンティティの設定にオファーをするための論理を有する支払いシステムのブロック図を示す。図３は、購入者システム３０１、販売業者システムＡ３０２、販売業者システムＢ３０３、販売業者システムＣ３０４、及び販売業者システムＤ３０５を含んでいる。また、応答３０８及び３０９に加えて結果３０６及び３０７の設定が図３に示されている。購入者システム３０１は、目標探索論理３１３、支払い論理３１４及びイベント発生論理３１５を含んでいる。また、イベントＡ３１７及びイベントＢ３１６が購入者システム３０１に示されている。目標探索論理３１３は、ルール３１８、選定論理３１９及び停止論理３２０を含んでいる。イベントＡ３１７及びイベントＢ３１６は、イベントに関係する情報をそれぞれ含んでいる。例えば、イベントＡ３１７は、イベントタイプ３２４、ベンダーの識別情報３２１、取引額の識別情報３２２及び決算日３２３を含んでいる。オファーリクエストは、イベントのベンダー識別情報に基づいて適切な販売業者に送信される。

図３に示されるシステムでは、購入者は、購入者システム３０１を通して、イベントの電子的通知に基づいて新たな合意のオファーのために設定のリクエストをする。購入者システム３０１は、新たな合意を用いて達成されるように一の目標又は目標のセットを確立する。目標は、異なる合意に達するための試行が停止する基準を含んでおり、異なる合意の探索の停止は、停止論理３２０によって前記基準に基づいて制御される。選定論理３１９は、多くの場合、合意の変化を有するオファーの設定が、どのように評価されて選定されるかを決定する。ルール論理３１８は、オファーが特定のイベントに基づいて販売業者又は購入者に送信されるか否かを決定する。前記決定は、ベンダーの識別情報、取引における支払い額及び決算日に基づいてなされる。

変更される合意のためのリクエストが異なる販売業者に送信される。ここで示されているように、リクエスト３０６及びリクエスト３０７は、販売業者システムＡ３０２及び販売業者システムＢ３０３それぞれに送信される。応答は、それぞれの合意の変化のオファーを用いて販売業者から受信される。例えば、応答３０８及び応答３０９は、販売業者システムＣ３０４及び販売業者システムＤ３０５それぞれから受信される。合意の異なる設定のオファーに対するリクエストは、設定結果の形態である。例えば、リクエスト３０６は、設定の日付の３１０及び対応してなされ得る調整された支払い３１１を含んでいる。前記リクエストは、結果３１２の追加の設定に示されるように追加次元を有する。例えば、前記結果の追加の設定は、異なる金利計算に基づいて支払いを表す。販売業者は、設定結果の一部の選定を有するオファーを用いて応答する。購入者は、その後、この一部の間及び様々な他の販売業者からの前記オファーの間で選定し得る。

販売業者は、目標探索論理３３０及び販売業者システムＡ３０２を備えてここで示されているような目標探索論理に基づいてそれらの応答オファーを自動的に作り出す。前記目標探索論理は、様々な基準に基づいてオファーをするように結果の間で選定する。例えば、前記選定が信用等級、支払いの大きさ、日数に基づいてなされると、支払いは、支払い日の金利又は他の基準に対して変更されて、前払いされる。

図４は、本発明に係る実施例に従う、割引された支払いのためのキャンペーン又は目標探索の作成フロー図を示す。キャンペーンは、改善されたキャッシュフローに対する早期支払いを達成し、すなわち、購入者として、より早期の日程で支払いをする引き替えに全体の支払い低減を達成するために、設定の購入者又は供給業者との合意を変更する目的で保証されている。

第１に、購入者又は供給業者の設定は、所望の節約に従って決定される（ブロック４０１）。前記決定は、供給業者に設定に対して支払うべきそれぞれの額、及び前記支払いが支払い期日の来る前の時期を考慮してなされる。前記支払いの支払い時期が来る前に残されている残存時間が十分に大きい場合、前記支払いにおいて大きな割引を交渉できる可能性がある。一般の金利及び未払い残高に基づいて、購入者又は供給業者の設定は、所望の節約を達成するように選定される。供給業者の場合は、供給業者に支払うべき十分な額を実質的に有する購入者の設定は、早期の支払いの候補として選定される。この設定は、支払いの未払い額及び前記支払いに対する残存時間に基づいて選定される。選定は、高額の未払い残高及び前記未払いについて最大残存時間を有する組織の設定を最初に選択することに基づいてなされる。代替的に、未払い額又は前記未払いについての時間のような要素は、本発明に係る他の様々な実施例を通して望まれるものである。購入者又は販売業者の異なる部分は、信用等級、大きさ、関係の長さ又は他の要素のような様々な要素に基づいて確立される。その後、応答のための異なるルールがグループの性質に依存して購入者又は販売業者の各グループに対して確立される。

トリガー状況が画定される（ブロック４０２）。前記トリガー状況は、インボイスの承認又は支払いの解除である。他のトリガー状況は、本発明に係る代替的な実施例において選定される。交渉は、早期支払いに対する割引の支払いを引き換える際に異なる支払いの合意を達成するために導入されている。前記交渉は、本発明に係る実施例によると、段階的手法で実行される（ブロック４０３）。前記交渉は、他の当事者に対してより良い合意のために累進的に一連のオファーを提供することによって実行される。例えば、本発明に係る一実施例によると、購入者は、継続的に特定の割引と引き替えに、より早期の支払いを自動的にオファーする。代替的に、購入者は、特定の早期の支払いと引き替えに、より少ない割引を継続的にオファーする。本発明に係る一実施例では、販売業者は、特定のより早期の支払い時期と引き替えに継続的に、より大きな割引をオファーする。代替的な実施例では、販売業者は、特定の割引と引き替えに、より遅い支払い時期を継続的にオファーする。前記オファーの設定み合わせは、本発明に係る代替え的な実施例で用いられる。一実現方法において、交渉は、（以下で述べる）トリガーイベント後に行われる。

次に、承認ルールを画定する（ブロック４０４）。前記ルールは、商品が受信されることが十分に確実であるような状況、又は購入者が信頼性をもって支払いを保証し得るサービスが表示されているような状況にそれぞれのインボイスがある時に決定される（ブロック４０４）。例えば、ルール次第で、異なるトリガー状況が異なる当事者、例えば異なる販売業者、又は確立されたルール次第である異なる購入者又は異なるグループ、に適用される。次に、通知及び承認ルールが画定される（ブロック４０５）。前記ルールは、どの状況通知が注文のステータスを考慮して提供されているかを決定する。前記ルールの例は、額が一定額よりも高い場合には特定の個人（ＣＦＯなど）からの署名された承認を待つこと、承認動作がビジネスデイの日数で受信されていない場合には自動承認を待つこと、又はその他のルールを待つこと、を含んでいる。前記画定の後、キャンペーンが動作可能にされる（ブロック４０６）。その後、前記キャンペーンが動作可能である時、トリガーイベントが発生し（ブロック４０７）、供給業者承認、通知及び確認ルールが実行される（ブロック４０８）。同様に、購入者承認、通知及び確認ルールが実行される（ブロック４０９）。応答に際して、最後の決算日及び金額が自動的に調整される（ブロック４１０）。

図５は、本発明に係る実施例に従って金融機関のような第３の当事者を伴う、割引される支払いシステムのブロック図を示す。販売業者がその電子的にインボイス作成された請求書に対して早期の支払いを受信できるように金融機関が含まれている。販売業者システムは、インボイスの承認又は購入者による支払いの解除のようなトリガーイベントの際又はその後に早期の支払いを受信する。販売業者は、このより早い日付で金融機関からこの支払いを受信する。購入者は、金融機関に対して遅れて支払いをする。金融機関から販売業者によって受信される支払いは割引されており、購入者によって金融機関に対してなされる支払いは、金融機関が販売業者に対して支払う額より高額である。

図５に示されるシステムは、前記取引を達成するための本発明に係る一実施例である。示されているシステムは、購入者システム５０１、販売業者システム５０２及び金融機関システム５０３を含んでいる。購入者システムは、支払い合意設定論理５０４、インボイス５０５、承認論理５０６、支払い及び解除論理５０７、イベント論理５０８及び未払いを支払う日付を用いた支払い論理５０９を含んでいる。支払い合意設定論理５０４は、金融機関５０３の購入者合意５１３と接続されている。購入者システム５０１のインボイス５０５は、承認論理５０６及び支払い解除論理５０７に接続されている。承認論理５０６は、支払い及び解除論理５０７及びイベント論理５０８に接続されている。承認論理５０６、支払い及び解除論理５０７及びイベント論理５０８は、販売業者システム５０２のイベント通知論理５２３に接続されているイベント照会論理５２０に接続されている。また、承認論理５０６、支払い解除論理５０７及びイベント論理５０８は、金融機関５０３のイベント通知論理５１４に接続されている。未払いを支払う日付を用いた支払い論理５０９は、支払い及び解除論理５０７及び承認論理５０６に接続されている。また、論理５０９は、金融機関５０３の支払い受信論理５１５に接続されている。

金融機関５０３は、購入者合意論理５１３、イベント通知論理５１４、支払い受信論理５１５、販売業者合意論理５１６、支払い解除論理５１７、送金情報論理５１８及びデビットメモ論理５１９を含んでいる。販売業者合意論理５１６は、販売業者システム５０２の支払い合意設定論理５２１に接続されている。支払い解除論理５１７は、販売業者システム５０２の支払い受信論理５２４に接続されている。送金情報論理５１８は、デビットメモ５１９と共に、販売業者システム５０２の照合調整論理５２５に接続されている。

販売業者システム５０２は、支払い合意設定論理５２１、インボイス発生論理５２２、イベント通知受信論理５２３、支払い受信論理５２４及び照合調整論理５２５を含んでいる。支払い合意設定論理５２１は、ビジネスイベント論理５２６、手数料論理５２７及び合意論理５２８を含んでいる。

支払い合意は、購入者と金融機関の間で設定される。本システムは、前記交渉を容易にし、支払い合意設定論理５０４及び購入者合意論理５１３を用いて設定する。支払い合意設定論理は、ビジネスイベントの設定、未払いを支払うべき日付及び承認された合意の下で提供される払い戻し割合を決定する。前記設定は、ビジネスイベント論理５１０、付加的ＤＰＯ論理５１１及び払い戻し割合論理５１２それぞれによってそれぞれ実行される。前記合意が設定された後、それらは、将来の金融取引においてそれぞれの合意を自動的に設定するのに利用できるように購入者合意論理５１３によって記録される。

交渉は、金融機関と販売業者の間で発生する。販売業者合意論理５１６及び支払い合意設定論理５２１は、前記交渉を容易にし、金融機関と販売業者の間のそれぞれの合意を設定する。支払い合意の設定は、早期の支払い、早期の支払い対して金融機関によって販売業者に請求される手数料、及び前記支払いがなされる合意、を生じさせるそれぞれのビジネスイベントの決定を含んでいる。前記設定は、ビジネスイベント論理５２６、手数料論理５２７、及び合意論理５２８それぞれによって実行される。

図示した本システムに示される前記論理によって実行されるタスクは、ソフトウェアプログラムによって実行される。ソフトウェアプログラムは、示される構成のモジュールで動作する。前記ソフトウェアは、本発明に係る様々な実施例によると、ソフトウェアモジュール及び／又はクラス又は異なるシステム及び通信要件に従う処理の異なる方式として実現される。本発明に係る一実施例によると、購入者システム及び販売業者システムは、それぞれ１つのコンピュータプロセッサ又は複数のコンピュータプロセッサを備えてそれぞれ別のサーバで実現される。代替的に、それぞれのシステムは、共通のサーバ又は分散型サーバで実現される。分散型ネットワーク環境ような他の実現方法が可能である。

購入者システムと金融機関の間、又は販売業者と金融機関の間、又はそれらの設定み合わせの間のいずれかにおいて合意が設定された後、取引が新たな合意を用いて実行される。本発明に係る一実施例によると、購入者又は販売業者のいずれか一方のみが金融機関との調整に入る。本発明に係る別の実施例によると、購入者と販売業者の両者が、支払い合意を最初の支払い合意から変更するために金融機関との調整に入る。

インボイスは、販売業者システム５０２によって発生させられる。ここで示したように、インボイス５２２が作成される。前記インボイスは作成され、インボイスの画定及び購入者又は購入者システムによって提供されるインボイスに対するルールの画定に基づいて確認される。インボイスは、購入者システムに送信され、インボイス５０５としてここで示したように受信される。インボイスは、バリデーションのような承認及び他の要素を必要とする。承認は承認論理５０６によって実現される。インボイスが適切なステータスに達する時、支払いは、支払い解除論理５０７が実行されて解除される。支払いが解除されるイベントは、ユーザから受信される指示であって、商品が受信され、適切な管理が費用を承認したという指示である。インボイスのステータスを及び注文に関係する他のイベントは、イベント論理５０８によって記録されて送信される。承認、支払い解除及び他のイベントのようなイベントの照会は、金融機関５０３のイベント通知論理５１４に送信される。これにより、金融機関は、購入者システムの適切なイベントに基づいて販売業者システムに支払うことが可能となる。また、イベント照会は、販売業者システムのイベント通知論理５２３に対してイベント照会５２０として送信される。支払いは、ＤＰＯ論理５０９を用いた支払いによって購入者システム５０１から金融機関５０３になされる。この論理は、販売業者は金融機関によって直接的に支払われるので、販売業者システムの代わりに金融機関に対して支払いをする。支払いは、インボイスの全額又は販売業者に金融機関によって支払われる額よりも幾らか高い額でなされる。

販売業者システム５２１は、金融機関５０３の支払い解除論理５１７から支払い受信論理５２４で支払いを受信する。適切なトリガーイベントが前記イベントの満了日前に発生していると想定すると、この支払いは、購入者と販売業者の間での最初の合意の下で初期的に予定された時期よりも早い時期になされる。しかしながら、支払いは、早期に支払いがなされた際の時価を計上して割引された額でなされる。販売業者システム５０２の照合調整論理５２５は、金融機関５０２の送金情報論理５１８及びデビットメモ論理５１９から送信される送金情報に関して最初のインボイス記録及び他の支払い記録を含む支払いの様々な記録を照合調整する。

図６は、本発明に係る実施例に従って金融機関を伴って割引される支払いフロー図を示す。合意は、購入者と金融機関の間で設定され、購入者は、通常の支払い予定に従って又はそれに遅れて金融機関に対する支払いをすることができる。合意は、販売業者と金融機関の間で設定され、販売業者は、金融機関が販売業者に最初の合意された支払い額の割引額のみを支払っていることと引き替えに、通常の予定された支払い時期よりも早く支払いを受信することができる。

本システムは、購入者と金融機関の間の合意の交渉を容易にする（ブロック６０１）。金融機関に対して前記支払いの合意を提供する奨励プログラムと購入者の間で関連付けが確立され（ブロック６０２）、これは、トリガーイベントのタイプ（インボイス承認、商品受信など）、未払いを支払う付加的な日付（ＤＰＯ）の払い戻し割合及び／又は他の合意を含んでいる。前記システムは、金融機関から購入者の支払いタイプの設計を受信する（ブロック６０３）。支払いタイプは、どのように金融機関が販売業者のために支払いを収集するか（例えば、金融機関に対する支払いは購入者によって送信されるか、又は金融機関は異なる任意のアプローチに従って自動的に購入者の会計からデビットする）を画定する。金融機関は、購入者による利用が可能である様々な支払いタイプを有しており、購入者と金融機関の間で承認されたタイプの選定が受信される。支払い制限が購入者のために確立される（ブロック６０４）。前記クレジット制限は、クレジットを決定するための多くの基準要素に基づいて決定される。加えて、クレジット制限は、購入者によるそれぞれのインボイス承認のような一定のトリガーイベントに基づき、販売業者に対する支払いを許可しているというセキュリティの分析に基づいて確立される。前記イベントは他のタイプのイベントのより典型的な銀行資金調達に比べて異なるリスクプロファイルを与える。

以下は、資金調達に対してベンダーを設定することに関する。標準的なベンダーの合意及び状況が受信される（ブロック６０５）。金融機関を備えた付加的な合意及び状況に対する登録簿がベンダーから受信される（ブロック６０６）。これらの付加的状況は、イベントタイプ、割引率、新たな合意／支払い期日、及び／又は固定か又は補間するかどうか、を含んでいる。次に、承認は、ベンダー及び付加的合意及び状況について金融機関から受信される（ブロック６０７）。前記承認は、ベンダー及び合意及び状況を考慮して様々な金融基準に基づいている。加えて、承認は、ベンダーへの支払いが購入者によるインボイスの電子的承認又は購入者による支払い解除の電子的通知のような特定のイベントを基礎とするセキュリティの分析に基づいている。選定された特定イベント及び通知タイプに基づいて、分析はクレジットリスクから作られ、適切な資金調達合意が提供される。

クレジット同意及び承認は、購入者と金融機関の間及び販売業者と金融機関の間で確立された後、本システムを用いて支払いがなされる。支払いは、金融機関と販売業者との間及び購入者と金融機関の間でなされる。インボイスが準備され、ベンダーシステムにおいて確認される（ブロック６０８）。準備されたインボイスが受信されると、購入者システムにおいて確認される（ブロック６０９）。インボイスの承認は、購入者システムで受信される（ブロック６１０）。前記承認は、この中で上述したように購入システムのそれぞれの従業員による承認のような選定された設定の要素に基づいてなされる。ステータスがベンダー及び金融機関に送信される（ブロック６１１）。前記ステータスは、購入者システムによって受信され、購入者システムで発生させられるイベントに基づいて、インボイス及びそれぞれの注文に関係する、承認、支払い解除又は他のイベントのステータスを含んでいる。特に、調整された支払いの合意が基づいているトリガーイベントの通知は、ベンダー及び金融機関に送信される。

金融機関と購入者と販売業者のそれぞれの間での新たな支払いの合意に対して承認されている付加的な支払い状況が満たされない場合（ブロック６１２）、その後、支払いは、最初の合意に従ってなされる（ブロック６１３）。付加的な支払い状況が満たされる場合（ブロック６１２）、その後、交渉された合意が実行される（ブロック６１４）。ベンダーは、ファンド転送及び手数料を通知され、転送／送金情報を提供される（ブロック６１５）。前記ファンド転送は、購入者と販売業者の間で最初に承認された支払いから割引された割引額である。手数料は、全額からの割引である。代替的に、ファンド転送は割引された額であり、別の手数料は請求されない。さらに別の選択肢として、ファンド転送は、全額からそれぞれの手数料を引いた額である。その後、購入者のファンド宛先変更が実行されると、購入者決算日は、購入者と金融機関の間で承認されるので遅延される（ブロック６１６）。購入者ファンドは、販売業者の代わりに金融機関に宛先変更される。

次に、ファンド通知及び販売業者の送金フォーマットを受信する（ブロック６１７）。ファンド通知は、ファンドが販売業者に転送されていることを指示する。送金フォーマットは、支払いに関して購入者によって提供される送金情報のフォーマットである。照合調整は、その後、販売業者アカウントレシーバブル（Ａ／Ｒ）システムで実行される（ブロック６１８）。ファンド宛先変更命令は、購入者システムで受信される（ブロック６１９）。照合調整は、その後、購入者システムで生じる（ブロック６２０）。その後、払い戻しは、一実現方法に従って実行される（ブロック６２１）。前記払い戻しは、より高額な支払いを受信する時、及びそれぞれの取引に対してそれぞれの販売業者への支払い額が少ない時に金融機関から被る総節約に基づいており、購入者によって後に支払われる額の割引された額及び金融機関の利益を考慮している。払い戻しの提供は、任意の基準であり得る。

支払いは、購入者の好みに基づいて転送される。単一の又は組み合わせの機構は、ペーパチェックから電子的クリアリング・ハウスセンター（ＡＣＨ，ＶＩＳＡ，クレジットカード等）に及ぶ。ファンド利用性は、電子メールによって供給業者に通知される。送金情報は、供給業者（ＥＤＩ、ＰｅｏｐｌｅＳｏｆｔ、ＳＡＰ、Ｏｒａｃｌｅ Ｆｉｎａｎｃｉａｌｓ、など）によって画定される、異なるＡ／Ｒフォーマットに加えて多数のメディア（紙、電子メール、又はオンライン）で利用できる。これらの送金ファイルは、様々なＥＲＰシステムを用いて照合調整するのに供給業者によって用いられ得る。

図７は、本発明に係る実施例に従う、割引された支払いのタイミング図を示す。図７は、購入者と販売業者の間の取引に対する２つの対照時刻表を示す。最初の対照時刻表は、販売業者７０１及び購入者７０２を含んでいる。第２の対照時刻表は、販売業者７０３、金融機関７０４及び購入者７０５を含んでいる。販売業者に対する対照時刻表は、次の販売業者動作：商品輸送７０６及びインボイス発行７０７を含んでいる。購入者７０２に対する対照時刻表は、次の購入者動作：インボイス承認７０８、支払い解除７０９、割引支払いの送信７１０及び全額支払満期日７１１を含んでいる。

以下、第１の対照時刻表に従うイベントを説明する。最初に商品が輸送される（動作７０６）。代替的に、同様の動作は、サービスの性能のような販売業者の他の動作に基づいてなされる。商品承認の受信及び商品の検査のような他の動作、又は商品又はサービスに関連する他の動作は、この方式に従ってイベントをトリガーする。インボイスは、その後、販売業者によって発行される（動作７０７）。購入者は、その後、インボイスを承認する（動作７０８）。その後、購入者は、支払いを解除する（動作７０９）。購入者は、より遅い時期では結局は別の方法で支払うべき全額支払いよりも少ない割引された支払いを提供する。別の方法で支払うべき前記全額の支払いは、全額支払満期日７１１として示されている。購入者は、新たに承認された全額の支払い満期日７１８として全額の支払いを金融機関に支払う。

以下は、選定されている状況での支払い例である。本例は、例示するものであり、本発明を限定することを意図するものではない。

例１
ＰＯ通知 ６日
インボイス提出 ０日
インボイス額 ＄１００，０００
本購入者に対する供給業者合意 ２％１０、Ｎｅｔ３０
本供給業者に対する購入者合意 ２％１０、Ｎｅｔ３０
早期支払い割引獲得閾値 １０日
インボイス支払い期日 ３０日
トリガー通知：インボイス承認 １２日
支払い方法：ＡＣＨ ＡＣＨ
処理方法遅延 ２日
供給業者アカウントで利用可能なファンド １４日
計算方法 Ｓｉｍｐｌｅ
満期日に対する早期日付 １６日
有効割引 １．６０％
割引額 ＄１，６００
支払い額 ＄９８，４００

この例１では、インボイスは、日数０で購入者へ提出される。このインボイスでの支払い対する供給業者の合意は、２％、１０、ｎｅｔ３０であり、購入者が１０日以内に支払い場合のほか、３０日で全額支払う場合には、供給業者は購入者に２％の割引をオファーする意志があることを意味する。この例では、本供給業者に対する購入者の合意は、供給業者の合意に整合している。この例でのトリガーイベントはインボイス承認であり、それによって、トリガーイベントを考慮している通知は、インボイス提出日から１２日目に発生する。これは、承認される合意によって画定される早期支払い日を２日過ぎていることに注目すべきである。両当事者は、満期範囲の中で割引獲得機会を延長する意志を表しているので（１０日から３０日）、数値的方法を早期の支払い額を推定することに適用することができ、実際のトリガーとなる選定された支払い方法の日＋遅延を調整するが、この例では２日である。また、この例では、単利が用いられているが、金銭数式の現在価値又は時価のような他の方法が用いられ得る。満期に対する実際の決算日は、１４日目（インボイス承認に対する１２日＋支払い処理遅延２日）であり、すなわち全額合意の３０日よりも１６日早い。上述した数値的方法を用いる割引論理が適用される（２０日早期の２％は１６日早期の１．６％に対して方法的に等しい）。従って、支払いは、インボイス提出日にから１４日目に供給業者銀行預金口座において利用できるように予定された＄９８，４００の額で供給業者に渡される。

例２
ＰＯ通知 ８日
インボイス提出 ０日
インボイス額 ＄１００，０００
本購入者に対する初期供給業者合意 １．５％１０、Ｎｅｔ３０
本供給業者に対する購入者合意 ２％１０、Ｎｅｔ３０
本購入者に対する調整後供給者合意 １．７５％１０、Ｎｅｔ３０
本供給業者に対する調整後購入者合意 １．７５％１０、Ｎｅｔ３０
早期支払い割引獲得閾値 １０日
インボイス支払い期日 ３０日
トリガー通知：インボイス承認 ２日
トリガー通知：合意承認 ４日
支払い方法：ＡＣＨ ＡＣＨ
処理方法遅延 ＮＡ
満期日に対する早期日付 ２６日
基本割引率 １．７５％
基本早期日数 ２０
有効日歩 ０．０８７５％
計算又はルックアップ方式 Ｓｉｍｐｌｅ
有効割引率（早期日付の日歩^*＃） ２．２８％
実際の割引 ＄２，２７５．００
支払い額 ＄９７，７２５．００

この例では、インボイスは、０日で購入者へ提出される。このインボイスでの支払いに対する供給業者の合意は、１．５％、１０、ｎｅｔ３０であるが、購入者が１０日以内に支払う場合のほか、３０日で全額支払う場合には、供給業者は購入者に１．５％割引をオファーする意図があることを意味している。しかしながら、提出の時点では、本供給業者に対する購入者の合意は、２％１０、Ｎｅｔ３０を“オファーしている”点で高い。この例におけるトリガーイベントはインボイス承認であり、それによって、トリガーイベントを考慮している通知は、インボイス提出の日から２日目に発生する。合意の格差を認識すると、供給業者は、“購入者が中間点で応じる”ように１．７５％１０、ｎｅｔ３０の新たな合意に入る。購入者は、１．７５％１０、ｎｅｔ３０に応じるように自己の合意を調整することによって供給業者の合意の下、この“オファー”又は“調整”に応答する。また、購入者は、本供給業者に対してこの新たな割合を用いるように自己の割引論理選択を指示する。例１で与えられたような支払い方法遅延が回避されていることに注目すべきである。推定論理は早期支払い期日より前の日数が適用され得ることに注目すべきであり、すなわち、“早期支払い閾値”は、割引論理として存在する“推定”の選択に関しては、本発明に係る特定の態勢次第であることに注目すべきである。この例では、承認された合意は１．７５％１０、Ｎｅｔ３０であり、この承認は４日で発生し、割引論理は、相対日との差分に対する額を調整して、支払いができる限り早くなされることを決定する。この例では、支払いは４日で、すなわち予定された支払い期日から２６日早く開始される。当事者は、２０日早い（３０日より１０日早い）支払いと引き替えに１．７５％の率に同意する場合、その後、数学的に、有効割引率割引額を決定するために正味現在価値のような単利又は他の数値手法を用いて推定し得る。例２では、この調整された割引率は、画定した早期閾値よりも早いインボイスの支払いを反映して２．２８％である。

例３
ＰＯ通知 ４日
インボイス提出 ０日
インボイス額 ＄１００，０００
本購入者に対する供給業者合意 １４％ＡＰＲ、Ｎｅｔ３０
本供給業者に対する購入者合意 １４％ＡＰＲ、Ｎｅｔ３０
インボイス支払い期日 ３０日
トリガー通知：インボイス承認 １４
支払い方法：ＡＣＨ ＡＣＨ
処理方法遅延 ２
満期日に対する早期日付 １４日
有効日歩 ０．０３８４％
計算又はルックアップ方式 正味現在価値
正味現在価値割引要素 ０．５４％
有効割引率（早期日付の日歩^*＃） ２．２８％
実際の割引 ＄５３４．１２
支払い額 ＄９９，４６５．８８

この例３では、割引合意は、返還年率又は金利として表されており、すなわちそれら内部的な障害となる割合をビジネスとして共通に言及する。インボイスのネット満期日は、この金利に関連している。これらの２つの数値データポイントを用いて、システムはインボイス支払い期日に対して有効なトリガーイベントのタイミングに依存して適切な割引を推定し得る。他の方法によれば、単利又は正味現在価値のように多様な計算方法を用い得る。例３は、計算上、正味現在価値を利用している。例３は、購入者と販売業者の両者が、年率１４％及び３０日のインボイス支払い期日である、同じ設定の合意を承認している。この例では、インボイスは、実際の支払い期日の１４日前又は１６日前に承認される。しかしながら、例３は、２日である支払い方法要素を利用しており、実際には、早期支払い日をインボイス提出１６日後であって、それが支払われる１４日前に調整していることに注目すべきである。この１４日は割引計算の基礎となる。１４％のＡＰＲを用いると、有効な０．０３８４％（.１４／３６５）の日歩を発生させ得る。１４日のという期間に対してこの率を適用すると、０．５３７％（１４＊０．０３８４）になる。計算の正味現在価値は、３０日では＄１００，０００の将来的な額を与えられるが、一区切りの割引率として０．５３７％を用いると、＄９９，４６５．８８の現在価値を生じ、すなわち＄５３４．１２の割引額を生じる。

例４
ＰＯ通知 ４日
インボイス提出 ０日
インボイス額 ＄１００，０００
供給業者インボイス支払い合意 ３０日
購入者インボイス支払い合意 ３０日
供給業者支払い合意、１日から１０日 ２％
供給業者支払い合意、１１日から１５日 １．５％
供給業者支払い合意、１６日から２２日 １％
購入者支払い合意、５日から１０日 ２．５％
購入者支払い合意、１１日から１５日 １．５％
購入者支払い合意、１６日から２２日 １．２５％
トリガー通知：インボイス承認 ５
支払い方法：ＡＣＨ ＡＣＨ
処理方法遅延 ２
（ルックアップ値に基づいて）適用される割引 １．５％
予定される決算日 １５日
実際の割引 ＄１，５００．１２
支払い額 ＄９８，５００．００

本発明に係る本実施例では、上述した方法によってオファーされる、連続変動する計算の代わりに計数値探索が利用される。例３では、購入者と供給業者の両者は、トリガーイベントが行われる時に依存して参照されるように一連の合意を割引論理エンジンに入力している。表が示しているように、供給業者は、インボイスが１から１０日の間で承認される場合に適用されるべき割引額、１１から１５日の間では異なる率などを入力している。購入者は、５−１０日、１１−１６日等に対する率を画定する。例４では、インボイスは、２日のＡＣＨ処理遅延を有して５日で承認され、結果として、７日で早期支払い日を生じる。７日は１−１０日の供給業者の範囲及び５−１０日に購入者の範囲に収まるので、それらのそれぞれの割引率が参照され、承認に対してチェックされる。この例では、それらは、どちらの割引率を参照するかについては承認せず、リストで次に利用できる機会は、これらの場合、購入者と供給業者の両者に対しては１１−１５日である。表から、この範囲の日付の割引額で承認されることに注目すべきである。従って、支払いは、１５日目の前であって１１日目の後の１．５％割引に関して決算するようにスケジュールされる。

第２の対照時刻表は、金融機関７０４を含む当事者間の相互関係を示す。商品は、販売業者７０３から購入者７０５に輸送される（動作７１２）。次に、インボイスが販売業者によって発行される（動作７１３）。インボイスは、イベントインボイス承認で購入者７０５によって承認される（動作７１４）。インボイス承認照会イベントは、販売業者７０３と同様に金融機関７０４に提供され、金融機関により販売業者に対する支払いはインボイスの承認に基づく。次に、支払いが解除される（動作７１５）。前記解除の通知は、金融機関７０４と同様に販売業者７０３に提供される。前記通知は、金融機関７０４に提供され、金融機関は、購入者による支払いの解除に基づいて販売業者に対する支払いを任意にトリガーする。割引された支払いは、金融機関７０４から販売業者７０３になされる（動作７１６）。その後、全額支払いが購入者７０５と金融機関７０４の間でなされる（動作７１８）。前記支払いは、本発明に係る代替的な実施例では、全額よりは安いが、販売業者に対して金融機関によって支払われた額よりは高い支払いに等しい。また、前記支払いは、初期の支払い満期日よりも遅い時期（動作７１８）になされ得る（動作７１７）。

例５
購入者１ 購入者２
ＰＯ通知 ４日 ５日
インボイス提出 ０日 ０日
インボイス額 ＄１００，０００ ＄２００，０００
供給業者合意 ２％１０、Ｎｅｔ３０ ２％１０、Ｎｅｔ３０
購入者プログラム ６０日支払い満期、 ５０日支払い満期
払い戻しなし １０％割引
トリガー通知：インボイス承認 ５ ５
支払い方法：ＡＣＨ ＡＣＨ ＡＣＨ
処理方法遅延 ２ ２
満期日に対する早期日付 ２３日 ２３日
有効日歩 ０．１０００％ ０．１０００％
計算又はルックアップ方式 Ｓｉｍｐｌｅ Ｓｉｍｐｌｅ
有効割引率 ２．３０％ ２．３％
実際の割引 ＄２，３００．００ ＄４，６００．００
支払い額 ＄９７，７００．００ ＄１９５，４００．００
ネット結果：銀行の
供給業者への支払い ＄２９３，１００．００
銀行返済 ＄１００，０００ ＄２００，０００
購入者への銀行払い戻し Ｎｏｎｅ ＄４６０．００
（簡単のため、これは割引プログラムａ％、利益プログラムのａ％であるので、資本の銀行費用は無視される）

例５では、銀行は、供給業者からインボイスを受信して処理している２人の購入者に代わって供給業者に支払っている。表は、支払期日まで５日で生じた購入組織内のトリガーイベントを示している。支払い方法遅延の調整は、早期支払い機会を２３日にしている。０．１％（２０日の早期で２％＝一日につき０．１％）の有効な一日の割引率を用いると、各インボイスに適用される有効な割引率は、２．３％である。これは、購入者１に対して＄２，３００の割引、購入者２に対して＄４，６００の割引になる。初期のインボイス額からの割引額を提出することは、購入者１及び購入者２のそれぞれに対して＄９７，７００及び＄１９５，４００のネット支払いを生じる。また、金融機関はこの例では単一の供給業者に対して支払いをしているので、支払いは１つに統合されるか、又は金融機関の選択次第で別個に開始され得ることに注目すべきである。金融機関は６０日で購入者１から＄１００，０００を受信し、５０日で購入者２から＄２００，０００を受信する。加えて、購入者１は金融機関からの払い戻しの受信を受けないことに注目すべきである。購入者２は、この例では、＄４６０の額の払い戻し、すなわち１０％の割引獲得率を受ける。銀行は、資本の費用に基づいて、及びこの場合２０日（５０日―３０日（インボイスの初期支払期日））である、クレジットが未払いである期間に基づいて、＄４６０を低く調整するように計算に対して異なる方法を適用し得ることに注目すべきである。また、例１−４で述べた数値的又はルックアップ方式が、本システムのバンキング指向の実施例に適用し得ることに注目すべきである。

図８は、本発明に係る実施例に従う、バンキングシステムのユーザインターフェースを示している。銀行インターフェースは、上位レベルナビゲーション入力８０１及び下位レベルナビゲーション／表示、フィルタ又はファンクション８０２を含んでいる。銀行がこのインターフェースに従って取り得る主な動作は、タスクリスト８０３、購入者８０４、供給業者８０５、アクティビティ８０６及びクレジット分析８０７と協働するものを含んでいる。

以下は、異なるそれぞれのカテゴリーで利用可能な動作である。タスクリスト８０３の下では、供給業者ターゲット８０８を利用することができる。購入者８０４の下では、奨励プログラム８０９、購入者デビット８１７、クレジット制限８２１、交信情報８２４及びクレジットプログラム８２５を利用できる。奨励プログラム内では、払い戻し方法が利用でき、均一対割合の利益オプション８１３及び支払い満期日８１５を含んでいる。払い戻し方法８１３は価格８１４を含んでいる。支払い満期日は、インボイス日付からの日数８１６を含んでいる。購入者デビット８１７は、支払い方法８１８、クレジット制限８２１、交信情報８２４及びクレジットプログラム８２５を含んでいる。支払い方法８１８は、ダイレクトデビット口座番号８１９及び購入者の開始８２０を含んでいる。クレジット制限８２１は価格８２３を含んでいる。クレジットプログラム８２５は、価格又は関税８２６を含んでいる。

以下の動作について、供給業者８０５には、割引プログラム８１０、供給業者登録簿８３０及び参加統計８３２が含まれている。割引プログラム８１０には、レート８２７、合意／支払期日８２８及び固定／補間８２９が含まれている。供給業者登録簿には、割引プログラム８３１が含まれている。カテゴリーアクティビティ８０６には、現時点８１１、支払い８３３、クローズ８３４が含まれている。クローズ８３４には、承認日８３５、購入者８３６、インボイス番号８３７、供給業者８３８、初期金額８３９、支払い額８４０及び支払い満期日８４１が含まれている。

カテゴリークレジット分析８０７には、購入者によるクレジット制限概要８１２、ドル変換８４２、獲得割引８４３及びネット利益８４４が含まれている。ネット利益には、傾向分析８４５、累積概要８４６及び受取鑑定８４７が含まれている。受取鑑定には、概要８４８及び購入者８５１が含まれている。概要８４８には、金額８４９及び年齢８５０が含まれている。購入者関係８５１には、金額８５２及び年齢８５３が含まれている。

銀行インターフェースは、銀行が、販売業者に支払いをして、購入者から支払いを受信するという、自己のプログラムを管理・分析できる様々なオプションを含んでいる。例えば、購入者８０４は、銀行がそれぞれの購入者に設定される様々なプログラムを分析することを許可している。示されているプログラムは、本発明に係る様々な実施例の様々な設定み合わせで利用できる。同様に、カテゴリー供給業者８０５は、銀行が様々な供給業者に提供されている自己のプログラムを分析することを許可している。前記分析は、それぞれの供給業者に提供され、また、プログラムは、一般には供給業者に関する銀行に利用可能である。他のカテゴリーについては、付加的要素と共に含んでいる、様々な設定み合わせ又は示されている基準の副次的な設定み合わせが、異なる実現方法で提供される。カテゴリーアクティビティ８０６は、銀行によって提供され管理されている割引プログラムに関する様々な保留アクティビティを分析することを銀行に許可している。クレジット分析カテゴリー８０７は、銀行がこれらのプログラムに関する様々な形態の分析を行うことを許可している。分析は、示されているタイプの形態又は他の設定み合わせ、副次的な設定み合わせ又はこれらの要素の優れた設定み合わせの形態を取り得る。

図９は、本発明に係る実施例に従う、支払いシステムのユーザインターフェースを示している。支払い管理インターフェースは、上位レベルナビゲーション動作９０１及び低レベルナビゲーション／表示、フィルタ又はファンクション９０２を含んでいる。上位レベルナビゲーション９０１は、次のカテゴリー：タスクリスト９０３、供給業者９０５、アクティビティ９０６及びクレジット分析９０７を含んでいる。タスクリスト９０３は供給業者ターゲット９０４を含んでいる。

供給業者９０５は、同様の最新ＧＳＤ９０８を含んでいる。同様の最新ＧＳＤ９０８は、支払うべき資金調達９０９、及びフィルタ及び表示９１０に対する新たなフラグを含んでいる。カテゴリーアクティビティ９０６は、現時点９１１、支払い９１２及びクローズ９１３を含んでいる。クローズ９１３は、承認日９１４、購入者９１３、インボイス番号９１６、供給業者９１７、初期金額９１８、支払い金額９１９及び支払い期日９２０を含んでいる。

カテゴリークレジット分析９０７は、購入者によるクレジット制限概要９２１、ドル変換９２２、獲得割引９２３及びネット利益９２４を含んでいる。カテゴリーネット利益９２４は、傾向分析９２５、累積分析９２５及び受取鑑定分析９２７を含んでいる。受取鑑定分析は、概要９２８及び購入者９３１を含んでいる。概要９２８は、金額９２９及び９３０を含んでいる。購入者９３１は、金額９３２及び年齢９３３を含んでいる。

支払人管理は、割引のプログラムが保証される、可能性のある候補供給業者を表示するのに購入者によって用いられ得る。示されている様々な動作により、購入者は、購入者が取り扱う供給業者の設定の間でフィルタの働きをして、様々なレベルの節約が早期の支払い及び相互の割引を通して達成される、可能性のある供給業者を見つけることができる。例えば、フィルタ及び表示９１０は、様々なフィルタによって選定される供給業者の識別情報を考慮している。前記フィルタは、それぞれの供給業者に対する可能性のある節約に基づいている。アクティビティ９０６は、最新の支払いアクティビティの分析を考慮している。クレジット分析９０７は、節約を達成するために割引の利用の分析を考慮に入れている。前記節約は、示されるように様々な形態で表示される。

このインターフェースは、最新の進行中のアクティビティ及び購入者と供給業者に関する残高を示している。そこでは、最新、クローズ、及び支払いのセクションを完了する。最新セクションは、実行されるように承認を待っている、画定された基準を整合するインボイスを表示する。支払いセクションは、供給業者に現時点で支払われているインボイスを表示し、購入者の再支払いを待つ。クローズセクションは、全ての完了した取引を表示する。

図１０は、本発明に係る実施例に従うシステムのブロック図である。本システムにより、支払いエンティティは、本システムが受信を望むインボイスに対するインボイスフォーマットを画定できる。本システムは、支払いについてのルート割当て、編集、論争解決、及び支払い金を容易にする。本システムは、１００１として示される支払人（購入者）、１００２として示される受取人（ベンダー）、及び１０５０として示される金融機関を含んでいる。本システムは、一実現方法に従って次の特性：共同ネットワークモデル、Ａ／Ｐ（購入者）主要企業ソフトウェア、既存のＥＲＰシステムへのプラッギング、全サイクルの支払い機能に対する請求書、ウェブベースのＡ／Ｒ（ベンダー）ソフトウェア、及び銀行が関連する既存の顧客との共存、を有する。

共同ネットワークモデルは、１０２８として示されるグローバルディレクトリと１０２７として示されるＡ／Ｐ中心の主要なベンダーリストとの間が、特定の共同ベンダー照合調整エンジンによってサポートされている。照合調整エンジンは、グローバルディレクトリにおける自己登録されたベンダー情報を用いて既存のベンダー名／アドレスを整合する方法を提供する。これらの方法は、１０３０として示されるファジー属性重みベースマッチング、１０３１として示される知識ベースにおける整合の事前のベンダー履歴、１０３２として示される第三者外注推薦マッチング提案、及び１０３３として示される購入者からの手動の対話型選定を含んでいる。各ベンダーは、グローバルディレクトリにおいて、幾つかの危機的な属性：１０３８として示されるアドレス、１０３９として示される実際のアカウント及びエイリアスアカウント、及び１０４０として示されるキーによってあらわされている。ベンダーエンティティは、購入者ＥＲＰシステムからアップロードされた情報を用いて事前に取り込まれている。ベンダーは、オンラインセルフサービス登録簿１０３５を介して登録される。また、ベンダーは、整合１０３４、Ａ／Ｒ送金フォーマット属性１０３６、及び通知ルール／アドレス１０３７に追加ルールを提供する。

支払人システム１００１に協働する支払勘定（Ａ／Ｐ）購入者中心企業ソフトウェアは、幾つかのキーとなる特定ファンクションを含んでいる。これらのファンクションは、購入者画定電子的インボイス交換、ルート割当て／編集及び承認、及び論争解決を含んでいる。支払いシステム１００１は、インボイス画定エンジン１００３、インボイス１００４、ＨＲ組織データ１００８、ルート割当て／編集論理１００５、論争論理１００９、通知論理１０１２、支払い論理１０１３、動的合意論理／オファー１０６０、割引論理１０１６及び決算論理１０１７を含んでいる。また、支払人システム１００１には、入出力（Ｉ／Ｏ）１０１０、プロセッサ１０１１、エンティティキー１０１５、及び支払人主要リポジトリデータベース１０２７が含まれている。インボイス画定エンジン１００３は、確認論理１０５３、許容／置換項目１０５５、相互作用重大度１０５４、及び幾つかの表示形態１０５６を含んでいる。この画定エンジンは、支払人の助けによって制御され、受取人からの純粋なインボイスデータを提供する。画定論理（１０５３、１０５４、１０５５、及び１０５６）は、特定の受取人又は特定グループの受取人に対して配置され得る。

インボイス画定エンジン１００３及びその画定論理は、グローバルディレクトリを介して受取人に公表され、受取人システム１００２のインボイス画定／発生／確認１０１８を用いて動作する。ルート指定／編集論理１００５は、どのようにインボイスがＡＰ事務員によって処理されるか、そして、どのデータ入力情報が取引を完了するのに必要とされるかを支配するビジネス論理を含んでいる。ルート割当て／編集論地１００５は、多数の属性：ドキュメントタイプ、ドキュメント値、割引額、などに基づいて異なった動作をする。ルート割当て／編集論理１００５は、ＨＲ組織データベース１００８に関して動作し、従業員情報１００７及び役割価値１００６に基づいてルート割当て／編集／承認動作フローを画定する。インボイス１００４は、ルート割当て論理１００５に接続されている。ルート割当て論理１００５は、従業員論理１００７及び役割指定１００６と接続されている。ルート割当て論理１００５は、支払いシステム１００１のＨＲデータ１００８及び論争論理１００９、通知論理１０１２及び支払い論理１０１３と接続されている。通知論理１０１２は、支払人によって構成され、共同フィルタリングを含んでおり、内部の間でのステータス及び通知画定を外部受取人にマッピングする。これらの共同フィルタリング及びマッピングは、受取人又は受取人のグループに指定され得る。

論争論理１００９は、インボイス又は他の交換ドキュメントに関連する争点を解決するために、中心となる共同ルール及び支払人と受取人の間の相互作用を画定する支払人の設定である。論争は、単純なもの(例えば、項目数が受信されるなど)もある一方で、中には、非常に複雑なもの（例えば、置換項目が指定及び価格の一部を満たしていない）もある。論争の結果は、部分的支払い、部分的インボイス、新たなインボイス、又は他の結果である。一実現方法によると、論争は、支払人及びそのメンバーによって最終的に承認され得るのみであり、最終的に承認される交換の中には、放棄しないことを確実にするためにデジタル署名を必要とするものもある。支払人論争論理１００９は、受取人論争論理１０２２と調整をとっている。支払人論争論理、基準、及び履歴は、支払人主要リポジトリ１０２７に記憶される。

受取人システム１００２と協働するＡ／Ｒウェブベースの主要ソフトウェアは、オンラインセルフサービス受取人システムの提供を支援する。受取人システム１００２は、プロセッサ１０５２及び入／出力（Ｉ／Ｏ）１０５１を含んでいる。前記プロセッサ１０５２及び入／出力１０５１は、支払人システム１００１、金融機関１０５０及びグローバルデータベース１０２８のような他のエンティティとの通信に関係している。受取人１００２及び支払人１００１それぞれのプロセッサ１０５２及びプロセッサ１０１１は、様々なソフトウェア処理を実行し、示される論理を実現する。処理は、ソフトウェアオブジェクト、ルーチン又は他のソフトウェア処理、プログラム又は実装として実現される。代替的に、前記論理の一部は、ハードウェア論理又は他の論理形態で実現される。示される機能は、代替的には、共通サーバ又はコンピュータネットワークを介して分離されている分散コンピュータシステム、又は示される論理機能を達成する他の構成で実現される。グローバルデータベースに対するようなデータ及び情報は、データ構造又は他のデータフォーマットで記憶され、コンピュータメモリ、固定記憶装置又は本発明に係る様々な実現方法で達成される他のデータ記憶装置に記憶される。

受取人システム１００２は、インボイス発生／確認論理１０１８、インボイス送信論理１０２１、論争論理１０２２、通知論理１０２３、受信／確認論理１０２４、割引論理１０２５及び決算論理１０２６を含んでいる。インボイス又は他のドキュメントは、多数の機構を介して支払人に提出され得る。３つのサンプル機構：１０５７に示されるウェブ形態、注文書事前生成インボイス（ＰＯフリップ）１０５８、及びファイルマッピングを介した電子ファイル提出１０１９がここで示される。ウェブ形態１０５７は、支払人の設定するものであり、受取人によって用いられるように、選択され及び／又は認可され得る表示が画定されるものである。また、受取人は、（会社ロゴなどのような）図画素材と同様にＡ／Ｒマッチング中に用いられるように追加の受取人プライベート属性及び範囲を画定し得る。ＰＯフリップ１０５８は、インボイスデータを事前生成するために支払人から受取人に提出される注文書からの情報を用いる。各注文書のステータスは、一括した注文書をサポートするために受取人主要リポジトリ内に保存される。ファイルマッピング１０１９は、大量のインボイス提出処理を自動化するのに受取人によって用いられる。通常、これらのファイルは、受取人のＡ／Ｒシステムからエクスポートされる。マッピングは、デフォルト／画定／変換ルールと同様にどの受取人データが支払人に割当てられるかを画定する。複数の機構（１０５７、１０５８、１０１９）を介したこれらのインボイス又は他のドキュメントを提出すると、ドキュメントは、支払人画定エンジン１０１８に基づいて確認される。この画定エンジン１０１８は、支払人画定エンジン１００３およびその要素：確定１０５３、重大度１０５４、許容度１０５５及び表示１０５６を含んでいる。

インボイス発生／確認論理１０１８は、ファイルデータ１０２０と通信するマッピング論理１０１９と接続されている。インボイス発生／確認論理１０１８は、インボイス送信論理１０２１に接続されている。論争論理１０２２は、支払人システム１００１の論争論理１００９と接続されている。通知論理１０２３は、支払人システム１００１の通知論理１０１２及び受取人システム１００２の割引論理１０２５と通信している。受取人システム１００２の受信／確認１０２４は、支払人システム１００１の支払いモジュール１０１３と通信する。決算論理１０２６は、受取人システム１００２の割引論理１０２５及び受信／確認論理１０２４を用いて動作する。

グローバルデータベース１０２８は、通知論理１０１２及び１０２３、支払い論理１０１３、決算論理１０１７及び１０２６、インボイス送信論理１０２１、受信１０２１及び受信／確認論理１０２４に利用できる。グローバルデータベース１０２８は、属性整合ルール１０３０、知識ベース履歴マッチングサンプル１０３１、第三者推薦／提案１０３２及び支払人による手動相互作用マッチング１０３３を介して支払人データベース１０２７と通信する。グローバルデータベース１０２８は、整合ルール１０３４、登録簿論理１０３５、送金フォーマット１０３６及び通知選択１０３７を介して受取人データベース１０２９と通信する。グローバルデータベースは、アドレス１０３８、アカウント１０３９及び公開鍵１０４０のような項目を含んでいる。支払人データベース１０２７は、支払人システム１００１に配置されており、受取人データベース１０２９は、受取人システム１００２に配置されている。また、グローバルデータベース１０２８は、金融機関１０５０に利用できる。

インボイス画定エンジン１００３を通して、支払人は、支払人システム１００１を用いて、自己が受信したいインボイスを画定する。販売業者のような受取人からの結果インボイスは、それが受信される時、おそらく適当なデータフォーマットであり得るので、前記画定は、支払人システムの効率を上げる助けとなる。受取人システム１００２は、インボイス発生／確認論理１０１８における画定されたインボイスに基づいてインボイスを発生させる。インボイスに対する入力データは、支払人システム１００１で画定されるインボイス画定ルールに基づいて確認される。ファイルデータがインボイスに自動的に割当てるのに用いられる場合、前記マッピングは、マッピング論理１０１９によって本発明に係る一実施例で実現される。マッピング論理１０１９は、それぞれのインボイスに取り込まれることになる情報と共にファイルデータ１０２０を受信する。ファイルデータ１０２０は、受取人から商品又はサービスを購入した様々な支払人に対するインボイスのデータを有するファイルを含んでいる。インボイスが完了される時、それはインボイス送信論理１０２１を介して支払人システム１００１に送信される。支払人によるインボイスの画定に関係する付加情報及び関連するインボイスルールの利用は、特許文献３、発明者Ｄｕｃ Ｌａｍ，Ｒａｍｎａｔｈ Ｓｈａｎｂｈｏｇｕｅ，Ｉｍｍａｎｕｅｌ Ｋａｎ，Ｂｏｂ Ｍｏｏｒｅ及びＸｕａｎ（Ｓｕｎｎｙ）ＭｃＲａｅ、代理人整理番号２５９２３．７０６である、System and Method for Electronic Payer (Buyer) Defined Invoice Exchangeと称する米国特許出願に含まれており、この中にその全体の参照によって取り込まれている。

インボイスは、インボイス１００４を用いてここで示されているように支払人システム１００１で受信される。インボイスは、その検査及び承認のためにそれぞれの従業員又は他の代理人にルート割当てされる。承認の中には、本発明に係る一実施例に従って付加的署名を必要とするものもある。ここで示されているように、従業員論理１００７は、従業員が認可し、それぞれのインボイスを検査又は表示し、又は情報をチェックできるように、ルート割当て論理１００５と通信する。

また、ルート割当て論理１００５は、ＨＲデータ１００８を用いる署名又は承認のためにチェック又は他のドキュメントを様々な従業員にルート割当てするのに用いられる。ルート割当て論理１００５は、インボイス又はチェックのようなそれぞれのドキュメントをルート割当てする適当な従業員を決定するのにＨＲデータ１００８を用いる。ルート割当ては、従業員がドキュメントに対して一定時間内に応答しなかった場合、それぞれの従業員の管理人に対してなされる。ルート割当てする前記管理人のそのような選定は、ＨＲデータベース１００８に記憶される組織の管理階層構造に基づいてなされる。前記データベースは、本発明に係る一実施例では、ヒューマンリソース管理システム（ＨＲＭＳ）から抽出される。本システムにおけるドキュメントのルート割当てに関係する付加情報は、Method and System for Invoice Routing and Approval in Electrinic Payment Systemと称する特許文献４、発明者Ｂｏｂ Ｍｏｏｒｅ及びＸｕａｎ（Ｓｕｎｎｙ）ＭｃＲａｅ、代理人整理番号２５９２３．７０７である、米国特許出願で述べられており、この中にその全体の参照によって取り込まれている。

支払人システム１００１のユーザは、論争論理１００９を介してインボイス又は他の支払い要求に論争し得る。論争論理１００９は、受取人システム１００２の論争論理１０２２と通信する。これは、支払人と受取人の間の論争に関係する通信を許容する。論争は、支払人によってのみ開始されて、最終的に承認される。本発明に係る一実施例によると、論争は、購入者すなわち支払人システムによってのみ最終的に承認される。論争は、税金のようにインボイスの特定の項目が論争されることを指示する能力を含んでいる。論争論理１００９及び１０２２は、支払人システム１００１、受取人システム１００２を用いてチャットダイアログにおいて保証するように個別の能力を含んでいる。前記システムにおいて電子的論争解決に関係する追加議論に対しては、Method and System for Buyer-Centric Dispute Resolution in Electronic Payment Systemと称する特許文献５、発明者Ｄｕｃ Ｌａｍ，Ｃｅｌｅｓｔｅ Ｗｙｍａｎ及びＸｕａｎ（Ｓｕｎｎｙ）ＭｃＲａｅ、代理人整理番号２５９２３．７０８であり、この中にその全体の参照によって取り込まれている、米国特許出願を参照することにする。

通知論理１０１２は、インボイス及び支払いに関する、様々な段階の承認又は他のステータス発行の完了を通信する。例えば、インボイスが承認される時、通知論理１０１２は、受取人システム１００２の通知論理１０２３に対する通知を通信する。前記通知に基づいて、割引が、割引論理１０１６を介して可能となり、受取人システム１００２の割引論理１０２５と通信する。例えば、インボイスが承認される場合、割引は、２０６０として示される承認又は未払い動的合意オファーに基づいて可能となり、対応する支払いは、初期の合意及び状況の下で必要とされていたものよりも早期になされる。動的合意は、支払人又は受取人１０６１によって確立される、付加的リアルタイム合意、ルール設定、及び／又は目標探索である。これらの動的合意ルール１０６０及び１０６１は、ビジネスイベントタイプ（インボイス承認、注文書承認など）、受取人又は受取人グループ、及び新たな別個の又は変化する合意の設定に基づいている。これらの動的合意目標探索により、支払人及び受取人は所望の結果を設定することができる。これらの動的合意は、ビジネスイベントタイプに基づいて前払い又はリアルタイムを事前交渉され得る。これらの新たな合意の承認は、支払人又は受取人のいずれかのデジタル署名を必要とし得る。また、第三者金融機関は、早期支払いに対する払い戻しにおいて受取人に対する資金調達を提供することを必要とし得る。

完全な請求書から支払いの機能性を容易にするために、図１０のシステムは、支払い論理１０１３及び決算論理１０１７を含んでいる。支払い論理１０１３は、それぞれのインボイス又は支払いのために他の必要となるものに対する、全ての支払いルート割当て、サイン、及び承認論理を含んでいる。幾つかの支払いは、支払額及び／又は宛先受取人に基づいてサインされることになる多数の署名を必要とする。デジタル署名は及び非デジタル署名は、両方用いられ得る。また、支払人は、画定される受取人グループによる支払いの新たな決算日及び調整されることになるビジネス／カレンダー日数を制御するように構成し得る。また、支払い論理は、署名数及び／又は金額に基づいて多数のレベルを有する可能性を検査することを含んでいる。一実現方法では、支払い論理１０１３は、電子的チェックの形態で前記支払いをする。前記電子的チェックは、デジタル署名を用いて発生させられ、サインされる。デジタル署名は、役割指定デジタルキー１００６を用いて従業員論理１００７からの署名を得るために、ルート割当て論理１００５を用いてルート割当て処理するそれぞれのユーザから得られる。

代替的に、命令セットは、従業員のデジタル署名よりもむしろ支払人組織のデジタル署名を用いるチェックセットを送信するために受信され得る。前記チェック処理は、バッチ処理論理１０１４及び支払い論理１０１３を介して成し遂げられる。前記バッチ処理論理１０１４は、支払人の組織の秘密鍵であるエンティティキー１０１５を用いる。バッチ処理論理１０１４は、それぞれの命令に対して特定の権限を必要とする。権限は、チェックセットを要求する代理人が自己の秘密鍵を用いて命令にサインすることを必要とする。受取人システム１００２の受信／確認論理は、支払い論理１０１３と通信する。受信／確認論理１０２４は、電子的チェックの形態での支払いを受信する。前記電子的チェックは、それらが正確であることを確実にするように確認される。受信／確認論理は、任意の号化されたドキュメントを解読し、例えば、電子的チェックが受取人システム１０２２の公開鍵を用いて解読される場合、前記チェックは解読される。加えて、送信者のデジタル署名は、受信／確認論理１０２４で認証される。前記認証は、バッチ処理論理１０１４で用いられる支払人の組織の公開鍵（エンティティキー１０１５）に対応する、支払人の公開鍵を用いて成し遂げられる。加えて、チェックが支払人システムによって実際に送信されていたことを確実にするために、チェックが作成される時、照合は、支払人システムによって発生させられる支払いデータベースに対してなされる。支払い１０１３及びバッチ処理１０１４に関係する付加的情報は、System and Method for Electronic Authorization of Batch Checksと称する特許文献２、発明者Ｄｕｃ Ｌａｍ，Ｍａｔｔｈｅｗ Ｒｏｌａｎｄ及びＸｕａｎ（Ｓｕｎｎｙ）ＭｃＲａｅ、代理人整理番号２５９２３．７０４である、米国特許出願に含まれており、この中にその全体の参照によって取り込まれている。

決算論理１０１７は、支払人システム１００１と受取人１００２の間の支払い決算を許可する。決算機構は、紙ベースのチェック、標準家庭的電子支払いネットワーク（Ｆｅｄ Ｗｉｒｅ，ＡＣＨ，ＣＨＩＰＳなど）、国際電子支払いネットワーク（ＳＷＩＦＴ，Ｂｏｌｅｒａなど）、適正プライベート支払いネットワーク（ＶＩＳＡ，Ｍａｓｔｅｒ Ｃａｒｄ，及びＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓなど）、及び内部アカウント銀行転送（ＯＮ−ｕｓなど）の既存の設定み合わせを含んでいる。例えば、決算は、本システム内のデータベースにおいてデビット及びクレジットを通してなされる。代替的に、決算は金融機関１０５０のような金融機関を備えたＡＣＨネットワークを伴うような外部ネットワークを通して実行され得る。

決算論理１０１７は、標準ファンド転送モデル（購入者の口座がデビットされ、供給業者の口座がクレジットされる。）及び商品ファンドモデル（購入者の口座がデビットされ、仮の口座がクレジットされる。仮の口座でファンド有効性を受信した時、供給業者はクレジットされる。）をサポートしている。決算論理１０１７は、決算ネットワークにリクエストを発行することを介して実現される。前記リクエストは、ＡＣＨのようなファイルベースのリクエスト又はＶＩＳＡネットワークのような取引リクエストであり得る。各リクエストに対して、各取引のトレーサビリティを確実にするために関連する確認ＩＤが存在する。

グローバルデータベース１０２８は、支払い論理１０１３及び決算論理１０１７のような支払いを送信する構成要素によって利用可能である。また、グローバルデータベース１０２８は、受取人とそれら各々の金融機関との間で他のドキュメント又は情報を送信する構成要素に利用可能でもある。例えば、インボイスは、グローバルデータベース１０２８に記憶されるそれぞれの受領者アドレスに基づいて送信される。従って、インボイス送信論理１０２１は、グローバルデータベース１０２８と通信する。

グローバルデータベース１０２８は、本システムを用いるそれぞれの支払人及び受取人のアドレス及びアカウント情報を含んでいる。グローバルデータベースが更新され、対応するリンク情報が利用され続けるように、グローバルデータベースと他のデータベースの項目間にリンクが作成される。従って、例えば、本発明に係る一実施例によると、支払人は、別個のデータベースである支払人データベース１０２７を有し、整合は、アドレス又は支払いエンティティ及び支払人１０２７のような項目と、整合発生処理１０３０を介したグローバルデータベース１０２８のそれぞれの項目との間で作成される。前記整合発生処理１０３０は、支払人データベース１０２７に記憶されたアドレスとグローバルデータベース１０２８におけるアドレス又は支払いエンティティの対応するスペルとの間の一連の候補の整合を支払人システム１００１のユーザに提供することを含んでいる。支払人システム１００１のユーザは、その後、最良の整合を選定し、それぞれのアドレス又は支払い識別情報の間のリンクを作成することができる。

このリンクは、その後、グローバルデータベースに記憶される適当なアドレスに対する支払いを有効にするのに用いられる。同様に、受取人データベース１０２９及びグローバルデータベース１０２８の項目間の整合発生が実行され、受取人システム１００２は、グローバルデータベース１０２８の情報を用いて項目を適当な受領者に送信し得る。登録簿論理１０３５は、グローバルデータベースに対して受取人として新たなエンティティを登録するのに利用でき、支払人システム１００１又は受取人システム１００２がそれらを利用できるようにする。

確立されるリンクは、その後、ドキュメント又は支払いが送信されることになる受領者を見つけるために、それぞれ支払人データベース１０２７及び受取人データベース１０２９における情報を利用可能である。本発明に係る実施例によると、アドレス情報１０３８及びアカウント情報１０３９に加えて、本システムの様々な関係者の公開鍵がグローバルデータベース１０２８に記憶される。前記鍵は、同時に、特定のエンティティによって送信されるデジタル署名の正確性を決定するために利用可能である。グローバルデータベース１０２８及び関連する論理及び通信に関係する付加的情報は、Method and System for Collaborative Vendor Reconciliationと称する特許文献１、発明者Ｄｕｃ Ｌａｍ，Ｇｅｏｒｇ Ｍｕｌｌｅｒ，Ｃｈａｎｄｒａ（ＣＰ）Ａｇｒａｗａｌ，Ｂａｂｙ Ｌｉｎｇａｍｐａｌｌｉ，Ｐａｖｅｌ Ｌｏｐｉｎ及びＸｕａｎ（Ｓｕｎｎｙ）ＭｃＲａｅ、代理人整理番号２５９２３．７０３である、米国特許出願に含まれており、この中にその全体の参照によって取り込まれている。

図１０のシステムにおいて、インボイス及び他のドキュメントは、公共及びインターネットネットワーク１０８０を介して支払人と受取人の間で交換される。セキュリティ及びプライバシーを提供するために、それらが送信される前に、インボイス及び他のドキュメントは、送信元秘密鍵を用いてサインされ、１０８１として示される宛先公開鍵を用いて解読される。インボイス又は他のドキュメントを受信した時、ドキュメントは、それ自身の秘密鍵を用いて解読され、１０８２として示される支払い拒否のないことを確実にするために送信元公開鍵に接して確認される。

また、システムは、１０６２として示される管理業務統合（ＥＲＰ）システムを用いて統合し得る。前記ＥＲＰシステムは、ＰｅｏｐｌｅＳｏｆｔ、ＳＡＰ、Ｏｒａｃｌｅ Ｆｉｎａｎｃｉａｌｓなどを含んでいる。本システムは、固有の及び／又は標準のインターフェースを介してこれらのＥＲＰシステムを用いて統合する。ＰｅｏｐｌｅＳｏｆｔの固有インターフェース例は、メッセージエージェントなどである。インターフェースは、ＥＤＩゲートウェイ等を含んでいる。本システムは、ＥＲＰを利用して、ドキュメント（注文書、インボイスステータス、測定ユニット、ベンダーリストなど）を抽出し、ドキュメント（インボイス、ベンダー情報、ステータスなど）を通知する。

本発明に係る様々な実施例の前記記載は、例示及び説明の目的で与えられるものである。説明される正確な形態に本発明を制限することを意図するものではない。

本発明に係る実施例に従う、割引を有する支払いシステムのブロック図を示す。 本発明に係る実施例に従う、割引される支払いのフロー図を示す。 本発明に係る実施例に従う、設定のエンティティに対するオファーをするための論理を有する支払いシステムのブロック図を示す。 本発明に係る実施例に従う、割引される支払いのキャンペーン作成のフロー図を示す。 本発明に係る実施例に従う、金融機関を伴う、割引される支払いシステムのブロック図を示す。 本発明に係る実施例に従う、金融機関を伴う、割引される支払いのフロー図を示す。 本発明に係る実施例に従う、割引される支払いのタイミング図を示す。 本発明に係る実施例に従う、バンキングシステムのユーザインターフェースを示す。 本発明に係る実施例に従う、支払人システムのユーザインターフェースを示す。 本発明に係る実施例に従う、電子的支払いシステムを示す。

Claims (43)

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. 前記新たな合意の受理を指示しているデジタル署名を受信することを含んでいる請求項２９に記載の方法。
36. 前記取引に対するインボイスの確認であって、前記インボイスが前記販売業者によって送信されていることを決定するための確認を含み、前記イベントは、前記確認後に発生することを特徴とする請求項２９に記載の方法。
37. 取引に対するインボイスのデータを電子的にチェックすることを含み、前記イベントは、前記データが特定の基準を満たす場合にのみ発生することを特徴とする請求項２９に記載の方法。
38. 販売業者と協働する第１のシステムであって、
    関連する合意の設定を有するインボイスを発生させ、前記インボイスを購入者に送信する論理と、前記購入者からのオファーのためにリクエストに応答して、関連する合意の設定以外の新たな合意の設定のために前記購入者に少なくともオファーを送信する論理であって、前記オファーが前記インボイスの処理に協働するイベント後の支払いに適用されるオファーを送信する論理と、を含んでいる前記第１のシステムと、
    購入者と協働する第２のシステムであって、
    前記販売業者から前記インボイスを受信する論理と、オファーのためにリクエストを発生させ、前記販売業者に送信する論理と、前記オファーを前記販売業者から受信する論理と、前記販売業者からの前記オファーを受信する前記販売業者に電子的指示を送信する論理と、前記インボイスの処理と協働するイベントの電子的指示を発生させる論理と、前記インボイスの処理と協働する前記イベントの電子的通知の受信後に前記新たな合意に従って前記購入者から前記販売業者に支払いをする論理と、を含んでいる前記第２のシステムと、
    を備えている支払いシステム。
39. 前記イベントは、前記購入者による前記販売業者のインボイスの承認の電子的指示を含んでいることを特徴とする請求項３８に記載のシステム。
40. 前記第２のシステムは、
    複数の販売業者と協働するシステムに対する新たな合意の設定のオファーのためのリクエストであって、関連するインボイスの処理と協働するイベント後の支払いに適用されるオファーのためのリクエストと、前記インボイスと協働する事前に確立された合意と異なる前記新たな合意と、を送信し、
    新たな合意のためのオファーに応答して、前記オファーの一部を受理し、前記それぞれのイベント後の前記新たな合意の下で支払いをする、論理を含んでいることを特徴とする請求項３８に記載のシステム。
41. 目標が満たされているか否かに基づいてオファーの部分を選定する論理を含んでいる請求項４０に記載のシステム。
42. 前記目標は、節約額を含んでいることを特徴とする請求項４１に記載のシステム。
43. 前記第１のシステムは、新たな合意の設定のオファーのためのリクエストであって、関連するインボイスの処理と協働するイベント後の支払いに適用されるオファーのためのリクエストを送信し、
    新たな合意のためのオファーに応答して、前記オファーの一部を受理し、前記それぞれのイベント後の前記新たな合意の下で支払いを受理する、論理を含んでいることを特徴とする請求項３８に記載のシステム。

Images