專利名稱：使用記賬方的支付平臺來支付顧客賬單的系統和方法
技術領域：
本發明總體上涉及用于使用第三方記賬方或定向收款方來支付顧客賬單的系統和方法。具體地，本發明涉及避免典型支付渠道且代之以使用收款方自己的支付平臺的系統和方法。
背景技術：
存在大量的賬單支付程序和計劃，其范圍從與顧客的財務賬戶相關聯的反復支付計劃到由大多數主要銀行機構提供的在線賬單支付。這種賬單支付系統通常專注于沒有銀行賬戶的人口部分，且可以比現有方法(例如，匯票或西聯)提供更高效和廉價的支付賬單的方法。由支付處理方維護和操作的很多賬單支付系統要求顧客輸入與要支付的賬戶相關的信息，并要求顧客向支付處理方提供資金。支付處理方一般通過傳統方法(通常是金額轉賬)來支付由顧客所識別的賬單。這種金額轉賬通常通過使用記賬匯總方(billingaggregator)來實現。記賬匯總方一般從一個公司收集記賬記錄，并向另一記賬系統通知該記錄。通常如果顧客使用賬單支付處理方“A”向其電力公司支付賬單，則交易通常如下所述:(i)顧客向支付處理方“A”支付錢(貨幣)；(ii)支付處理方“A”支付記賬匯總方(例如，RPS、Checkfree) ； (iii)記賬匯總方支付該電力公司。盡管該過程對于記賬匯總方提供的結算中心能力而言通常是有用的，但其涉及了額外的金額轉賬及其伴隨的所有費用(fee)、成本、收費(charge)和風險。因此，需要回避記賬匯總方的系統。然而，為了避免大多數記賬匯總方提供的連接，必須維護和/或訪問收款方(或要支付的貨物或服務的提供方)的支付平臺的某個鏈接。越來越多的提供方開始維護其自己的支付平臺(通常由顧客經由互聯網來訪問)，作為接受支付的附加手段。因此，需要可以能夠避免使用記賬匯總方且代之以直接訪問提供方或收款方的支付平臺的系統。除了記賬匯總方的缺陷之外，大多數賬單支付系統還要求顧客以特定方式對賬單支付賬戶進行撥款-通常在賬戶建立或支付時使用現金來撥款。在假定存在儲值卡的無處不在的特性的情況下，采用儲值卡作為支付選項的賬單支付系統是令人期望的。然而，應當理解:很多提供方或收款方可以不接受儲值-特別是與封閉式系統相關的儲值。因此，需要維護通常接受來自顧客的封閉式儲值但是向提供方或收款方提供開放式儲值(例如，預付費Visa借記卡號)的系統和方法。
發明內容
本發明的各方案可以包括一種向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的方法，所述方法方便了顧客、貨物或服務的提供方以及處理方，所述方法包括:從所述顧客接收金額、所述顧客的識別信息、以及足以識別所述提供方和所述顧客的預先存在的賬戶的信息；訪問所述提供方的支付平臺；確定為了向所述顧客賬戶提供支付而由所述提供方需要的信息；傳輸為了向所述顧客賬戶提供支付而由所述提供方需要的信息；以及向所述顧客賬戶提供金額。本發明的其他方案可以包括一種向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的方法，所述方法方便了顧客、貨物或服務的提供方以及處理方，所述方法包括:從所述顧客接收金額、包括所述顧客的姓名和地址在內的所述顧客的識別信息、以及包括所述預先存在的顧客賬戶的賬號在內的足以識別所述提供方和所述顧客的預先存在的賬戶的信息；對要支付給在所述提供方處預先存在的顧客賬戶的數量的識別；由所述處理器，并經由互聯網，訪問所述提供方的支付網站；查詢所述支付網站，以確定用于進行支付的由所述提供方所需的信息；所述提供方代替所述顧客采取行動，并向所述支付網站輸入從所述顧客接收的識別信息；確定所述提供方是否接受具有從所述顧客接收到的金額的形式的支付；當確定所述提供方接受具有從所述顧客接收到的金額的形式的支付時，將從所述顧客接收到的金額向所述提供方轉讓；當確定所述提供方不接受具有從所述顧客接收到的金額的形式的支付時，生成虛擬預付費借記卡號，并向所述提供方轉讓所述虛擬預付費借記卡號；以及向所述顧客提供對支付的確認。本發明的其他方案可以包括一種用于向顧客在貨物或服務的提供方處預先存在的顧客賬戶提供支付的處理方，所述處理方與所述顧客和所述提供方選擇性通信，所述處理方包括:顧客接口，提供在所述處理方和所述顧客之間的可選擇通信，所述顧客接口被配置為從所述顧客接收金額、包括所述顧客的姓名和地址在內的所述顧客的識別信息、包括所述預先存在的顧客賬戶的賬號在內的足以識別所述提供方和所述顧客的預先存在的賬戶的信息；以及對要支付給在所述提供方處預先存在的顧客賬戶的數量的識別；提供方接口，在所述處理方和所述提供方之間提供可選擇通信，所述提供方接口被配置為:訪問所述提供方的支付平臺或網站；以及向所述提供方的支付平臺或網站提供信息；網絡數據提取模塊，與所述提供方接口通信，所述網絡數據提取模塊被配置為:確定用于進行支付的由所述提供方所需的信息；處理模塊，與所述顧客接口、所述提供方接口、以及所述網絡數據提取模塊通信，所述處理模塊被配置為:向所述支付平臺或網站輸入從所述顧客接收的識別信息；向所述支付平臺或往網站提供金額。通過結合附圖對本發明進行的以下描述，這些和其它方案將變得顯而易見，然而可以在不脫離本發明的新穎概念的精神和范圍的情況下實現變化和修改。
通過閱讀以下具體實施方式
以及附圖可以更加完全地理解本發明，在附圖中，相似的附圖標記用于指代相似的元素。附圖示出了特定說明性實施例，且可以幫助理解以下具體實施方式
。在詳細解釋本發明的任何實施例之前，應當理解:本發明不限于其對以下描述中闡述的或在附圖中示出的組件的構造和布置的細節的應用。應當理解所描繪的實施例是示例性的，且不以任何方式限制本發明的整體范圍。此外，還應當理解:本文使用的措辭和術語用于描述的目的，且不應被視為是限制性的。
具體實施方式
將參考以下附圖，在附圖中:圖1示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法。圖2示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法。圖3示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法。圖4示出了根據本發明的一些實施例的作為便于使用記賬方的支付平臺來支付顧客賬單的方法的一部分的、確定由記賬方接受的撥款選項的過程。圖5示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法。圖6示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的系統。圖7示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的系統。在詳細解釋本發明的任何實施例之前，應當理解:本發明不限于其對以下描述中闡述的或在附圖中示出的組件的構造和布置的細節的應用。本發明能夠具有其他實施例且能夠以各種方式來實行或執行。此外，應當理解本文使用的措辭和術語用于描述的目的，且不應被視為是限制性的。
具體實施例方式提供在本描述中例示的內容，以幫助對參照附圖公開的各個示例實施例的全面理解。因此，本領域普通技術人員將意識到:可以在不脫離所要求保護的本發明的精神和范圍的情況下對本文所述的示例實施例進行各種改變和修改。為了清楚和簡潔，省略了對眾所周知功能和構造的描述。此外，如本文所使用的，單數形式可被解釋為復數，且備選地，可以將任何復數形式的術語解釋為單數形式。以“S”開頭的附圖標記(例如，S100)指示了步驟。總體上，本發明涉及用于進行賬單支付程序的系統和方法。具體地，本發明涉及賬單支付程序，其中，顧客向處理方提供各種個人和賬戶識別信息，以及處理方(代表該顧客)使用記賬方的支付平臺(例如，支付網頁)來提供直接支付。本文討論的系統和方法還規定了處理方接受儲值作為支付(包括封閉式儲值，例如Wal-Mart禮品卡)，同時向記賬方提供虛擬預付費借記卡(例如，Visa品牌借記卡號)作為支付。參見圖1，現在將討論根據本發明的一些實施例的支付賬單的方法10。圖1所示方法總體上在顧客、處理器、和記賬方之間提供方便。顧客可以是使用賬單支付系統和方法來進行支付的任何一方。盡管下面的討論可能介紹進行支付的那方與負債方或將從支付中受益的那方是同一方，但并不一定是這種情況。換言之，本文提出的賬單支付系統和方法提供了用于向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的手段。然而，可以想到:向預先存在的賬戶提供支付的“顧客”與擁有預先存在的賬戶或以其他方式從預先存在的賬戶受益的那方可以不是相一方。這種情況的示例可以是:對孩子或家屬名下持有的賬戶進行支付的家長。處理方是從顧客接收通信并與記賬方(或更具體地，記賬方的支付平臺或網站)交互的一方。盡管下面的討論可以將處理方介紹為分離的中間系統，但是可以想到:處理方可以與一個或多個記賬方相關聯，或可以與零售商或商家相關聯或是零售商或商家的一部分。記賬方是持有預先存在的顧客賬戶的一方。一般而言，記賬方可以是貨物或服務的提供方；然而，可以存在提供方的記賬和收款側可被外包給分離的不相關的一方的很多實例。本發明旨在也涵蓋該場景，且因此術語“記賬方”和“貨物或服務的提供方”預期是相關的。“記賬方”可以是“貨物或服務的提供方”，但是“貨物或服務的提供方”不一定是“記賬方”。下面可以將顧客、處理方、和記賬方之間的通信討論為好像這種通信是直接的。然而，可以預期:這種通信可能需要附加的各方或設備。例如，顧客可以經由互聯網、電話(例如，交互式語音識別(IVR)系統、消息系統(例如，短消息系統(SMS)或媒體消息系統(MMS))、在各種電子設備上運行的應用或小應用、銷售點終端或設備，或經由商家通信與處理方交互。在使用中間設備或中間方的情況下(例如，使用商家或商家位置處的銷售點設備)，結算可以發生在中間方和處理方之間確立的正常循環上。在這種情況下，可以存在處理方已進行了支付但是尚未從顧客收款的時間段。顧客與處理方通信的示例還可以包括大量的通信信道。例如，顧客可以向處理方登記，并經由第一信道(例如，互聯網)提供一些初始信息，然后可以經由第二信道(例如，在商家處的道內(in-lane)交易期間，經由商家銷售點設備以及商家至處理方的通信鏈路)請求支付賬單。圖1在非常基本的意義上(包括三個(3)步驟)表示了本發明的一些實施例。首先，在S110，處理方從顧客接收各種信息，包括例如⑴個人識別信息；(ii)記賬方賬戶信息；以及(iii)資金賬戶信息。個人識別信息可以包括為了向顧客賬戶進行支付記賬方所需的信息。例如，個人識別信息可以包括:顧客的姓名、地址、生日、登錄信息、以及密碼信息。記賬方信息可以包括足以讓處理方識別特定記賬方和在記賬方處的特定賬戶的信息。例如，記賬方賬戶信息可以包括:記賬方的標識和預先存在的顧客賬戶的賬號。在一些情況下，且根據本發明的一些實施例，記賬方賬戶信息可以是與特定設備相關聯的信息，該特定設備進而與賬戶相關聯。例如，記賬方賬戶信息可以包括電子設備的電話號碼。這種電話號碼可以足以確定提供方和顧客在提供方處的賬號。資金賬戶信息可以包括用于對賬戶支付交易進行撥款的信息，或金額本身。資金賬戶信息可以包括:財務賬戶信息(例如，支票賬戶信息)、儲值賬戶信息(例如，儲值賬號)、或可以從其提取金額用于支付的任何其他類型的賬戶信息。注意:“儲值”通常指代具有關聯賬戶的標記，該關聯賬戶其中存有金額。因此，可以將提供儲值賬號(例如，在預付費Visa借記卡或Wal-Mart禮品卡上的賬號)視為轉讓金額。如本領域普通技術人員將理解的:可以將“儲值”限定為“開放式(open-loop)”或“封閉式(closed-loop) ”。例如，“封閉式”儲值一般可以由有限數目的各方來贖回，在第一示例中通常由發行或提供儲值的一方(或其代表)來限制。例如，Wal-Mart禮品卡是封閉式儲值卡，因為僅可以在Wal-Mart對其進行贖回，且不能在其他地方使用。應當將預付費Visa、MasterCard、Discover、或American Express儲值卡視為“開放式”。盡管這種金額僅可以在接受Visa、MasterCard、Discover、或AmericanExpress的位置處贖回，但是贖回位置與發行或提供儲值的一方不綁定。在S120，處理方可以直接訪問記賬方的支付平臺，且可以提供為了進行支付記賬方所需的信息。例如，可以要求處理方提供顧客的姓名、地址、和/或賬號。在S130，處理方可以向記賬方的支付平臺提供支付。例如，在一些實施例中，處理方可以便于從顧客識別出的資金賬戶向記賬方的金額的直接轉賬(減去任何適用的費用或稅費)。在本發明的一些實施例中，處理方可以用從顧客接收一種格式的金額，并可以將該接收到的金額兌換為具有記賬方接受的格式的金額。例如，顧客可以向處理方提供封閉式儲值，且處理方可以使用開放式儲值來支付記賬方。如可以根據圖1所示的方法10看到的，處理方處于顧客的立場上，并直接進行與記賬方的賬單支付交易。根據本發明的一些實施例的方法和系統對于顧客可能是有益且有利的，因為賬單支付系統可以進行與多個記賬方的大量交易。例如，處理方可以保存個人識別信息。處理方可以保存在多個記賬方處的大量記賬方賬戶信息。因此，通過在顧客和處理方之間的單次交易，可以進行將來對多個記賬方的賬單支付交易。此外，由于處理方與記賬方直接作用，與在遵循傳統支付技術的情況下(例如，發送支票或利用記賬匯總方)相比，對顧客賬戶的支付可以更快進行通知。圖2示出了根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法20。圖2所示方法將該方法的登記部分(從顧客向處理方提供信息)與該方法的支付部分(從顧客向處理方提供金額，以支付賬單)加以分割。在210，處理方可以從顧客接收⑴個人識別信息；以及(ii)記賬方賬戶信息。如上所述，可以用任何方式以及經由任何信道從顧客接收該信息。在S220，處理方可以從顧客那接收資金。該步驟S220可以包括對實際資金的接收，或對其中可以找到實際資金或金額的賬戶信息的接收。注意到:在S210和S220之間可以經過相當大的時間段，且在S210和S220中，顧客和處理方之間的通信信道不需要相同。在S230，處理方可以訪問記賬方的支付平臺。根據本發明的一些實施例，支付平臺可以是互聯網網站，通過該互聯網網站，顧客可以向他或她在記賬方的賬戶進行支付。在S240，處理方可以確定為了對顧客賬戶進行支付記賬方所需的信息。可以用任何方式來確定和收集該信息。根據本發明的一些實施例，可以通過使用網絡查詢(web-scraping)、網絡收獲(web-harvesting)、或網絡數據提取程序或模塊來收集該信息。網絡查詢、網絡收獲或網絡數據提取時從特定網站自動收集和提取信息的過程，一般使用計算機軟件。通常地，這種軟件程序對人類瀏覽網站進行仿真。網絡查詢模塊一般收集無結構的網絡內容并將其轉換為可以存儲和分析的有結構數據。根據本發明的一些實施例，可以經由與記賬方的支付平臺的應用編程接口(API)來直接收集該信息。
在250，處理方可以向記賬方的支付平臺提供所需信息。在一些實施例中，這可以包括向網頁上的所請求字段插入恰當的信息(例如，向字段“姓名”插入顧客的姓名，或向字段“賬號”插入顧客的賬號)。在一些實施例中，支付平臺可以初次時要求多個信息，但是對于將來的交易可以向顧客僅要求登錄和密碼。在這種情況下，要么處理方建立登錄和密碼，要么處理方在S210中從顧客接收預先存在的登錄和密碼。在一些實施例中，可以按所請求的方式來布置支付處理方所要求的信息，并經由例如API向支付平臺直接發送該信肩、O在S260，處理方可以向支付平臺提供金額或金額的標記。例如，如果顧客已向處理方提供了銀行賬戶信息，處理方可以方便從顧客的銀行賬戶向支付平臺轉賬。如果顧客已以支付平臺不接受的格式(例如，封閉式禮品卡形式)向處理方提供了金額，則處理方可以將該接收到的金額兌換為支付平臺接受的金額。例如，在一些實施例中，處理方可以接收具有一種格式的金額，但是可以以生成的開放式虛擬預付費借記卡號的形式向支付平臺提供支付。作為非限制性示例，顧客可以經由Wal-Mart禮品卡向處理方提供支付；然后處理方可以創建虛擬預付費Visa借記卡，向該虛擬預付費Visa借記卡劃撥剛好等于向記賬方支付的數量的撥款，并向記賬方提供該虛擬預付費Visa借記卡賬號。作為附注，開放式虛擬預付費借記卡號的生成和提供可以具有附加或附帶的優點。例如，在Visa品牌儲值卡的情況下，當贖回這種儲值卡時，可以使得發行該儲值卡的一方有權獲得兌換費。兌換費是在接收方使用卡網絡(例如，Visa和MasterCard)接受支付時接收方的銀行(或獲取銀行)向發行銀行支付的費用。通常，發行銀行從其向獲取銀行支付的數量中扣除兌換費。該兌換費可以變化，但是通常約為交易金額的1.5% 2.0%。由于處理方是發行銀行，將交易的成本減少兌換費的數量。該兌換費可以用作給處理方的報酬，以進行支付交易，或可以用來通過減少兌換費或提供抵消報酬(offseting payment)來提升與各個記賬方的關系。在S270，處理方可以向顧客發送對支付的確認。該確認可以經由任何通信信道，且可以與從顧客接收到的支付指令具有相同的格式(但這不是必須的)。在根據本發明的一些實施例中，可以經由 SMS、麗S、電子郵件、應用通知、在社交網絡頁面上的消息、電話呼叫、尋呼、傳真、或任何其他通信來發送該確認。根據圖3，現在將討論根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法30。在S305，顧客可以向處理方提供信息，例如(i)個人識別信息；( )記賬方賬戶信息；以及(iii)資金賬戶信息。在S310，處理方可以接收在S305中發送的來自顧客的信息，且可以驗證該信息有效且資金賬戶具有正確的資金(即，具有與其相關聯的金額)。在S315，處理方可以基于從顧客接收到的信息來識別記賬方，且可以訪問記賬方的支付平臺(例如，允許接收付款并將之應用到顧客賬戶的記賬方的網站)。在S320，處理方可以確定向記賬方提供支付所需的信息，例如通過使用網絡查詢、網絡收獲或網絡數據提取程序。在S325，處理方可以用恰當的格式向支付平臺提供恰當的信息。例如，處理方可以用空白字段來填寫基于網絡的表單，或可以基于支付平臺已知的API來組裝傳輸。在S330，處理方可以確定應從顧客付給記賬方的數量。該確定可以基于從支付平臺接收到的信息，例如經由通信或通過在網頁上通知的應付數量且處理方再次利用網絡查詢、網絡收獲或網絡數據提取程序的服務。在S335，處理方可以確定顧客提供(或與顧客識別的賬戶相關聯)的資金數量是否大于等于應付給記賬方的數量。在確定資金數量不足時，交易可以終止，或處理方可以向顧客通知該不足，并要么請求附加資金源，要么請求減少支付給記賬方的數量。在確定資金數量充足時，處理方可以從資金賬戶中扣除應付給記賬方的數量(或顧客指示的任何其他數量)、以及任何適用的費用、收費或稅費。在S345，處理方可以向記賬方的支付平臺提供支付。在S350，處理方可以向顧客確認進行過支付，且可以向顧客通知最終的支付數量。處理方在S345向支付平臺提供的金額的形式可以不是在S305處從顧客接收到的金額的相同形式。參見圖4，現在將討論根據本發明的一些實施例的作為便于使用記賬方的支付平臺來支付顧客賬單的方法的一部分的確定記賬方40接受的撥款選項的過程。在S410，處理方可以確定記賬方和/或記賬方的支付平臺所接受的撥款選項的類型。例如，一些記賬方可以接收直接賬戶轉賬，而其他記賬方可以僅接受具有Visa或MasterCard格式的支付。一些記賬方可以接受一些形式的封閉式儲值(例如，可以用BestBuy禮品卡來進行對Best Buy授信額度的支付)，而其他記賬方可以不接受任何封閉式儲值。在S420，如果許可，處理方可以方便從顧客的賬戶(例如，諸如支票賬戶之類的財務賬戶)向支付平臺的直接金額轉賬。如果支付平臺不接受金額的直接轉賬，或不接受具有顧客提供的格式的金額，則處理方可能需要兌換所提交的金額。在S430，處理方可以從顧客識別的資金源扣除恰當數量的金額。該數量可以包括支付的數量加上任何適用的費用或稅費。適用的費用或稅費可以基于若干因素。可以存在發起或建立費；可以存在與每個賬戶、每個記賬方、和/或每個支付交易相關聯的服務費。可以存在在要求金額兌換時適用的費用。適用的稅費可以基于多個因素，包括(但不限于):與顧客賬戶相關聯的位置；支付請求的發起位置(例如，發起計算機位置(由ISP來確定)、發起銷售點設備或位置、接收到電話發起的支付交易的交換機的位置等等)、處理方的位置、以及提供方的位置。在S440，處理方可以生成虛擬開放式預付費儲值卡或借記卡，例如Visa品牌的預付費借記卡。處理方可以用支付交易的精確數量對虛擬開放式預付費儲值卡或借記卡進行撥款。在S450，處理方可以向支付平臺提供虛擬開放式預付費儲值卡或借記卡的賬號(例如，虛擬卡號)。在S460，處理方可以接收對支付平臺接收到資金的確認。參見圖5，現在將討論根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的方法50。在S510，顧客可以向處理方提供信息。這種信息可以包括:個人識別信息(例如，姓名、地址等)、記賬方賬戶信息(例如，記賬方的名稱、顧客的賬號)。可選地，在S511，顧客可以向處理方提供要為將來支付而使用的財務賬戶信息。例如，顧客可以在S511提供足以識別和訪問顧客的支票賬戶的信息。在S520，處理方可以接收信息，并驗證該信息是否有效，以及是否足以訪問所識別的記賬方的支付平臺并進行支付交易。例如，作為S521，基于對記賬方的識別，處理方可以咨詢數據庫或其他記錄，以確定記賬方要求什么信息。備選地，在S522，處理方可以訪問記賬方的支付平臺并在S523確定用于進行支付交易的由記賬方所需的信息。該確定可以經由網絡查詢、網絡收獲、或網絡數據提取程序或模塊來進行。在S524，處理方可以對從顧客接收到的信息和進行與支付平臺的支付交易所需的信息進行比較。如果在S525接收到的信息充足，則過程可以繼續。如果接收到的信息不足，則在S526，可以向顧客請求更多信息，且處理過程返回S520。可以在該過程中包括附加可選步驟。例如，在S527，處理方可以在支付平臺處創建顧客支付賬戶。S527可以包括創建(或指派)登錄和/或密碼。顧客支付賬戶可以避免需要為了將來的交易不斷地重新輸入各種信息。在S528，處理方可以向顧客通知顧客支付賬戶，且可以向顧客提供為了訪問而需要的登錄和/或密碼。在S530,處理方可以從顧客接收支付賬單的請求。該請求可以包括對顧客希望支付的特定記賬方的識別。在可選步驟S531，處理方可以訪問記賬方的支付平臺，并確定顧客虧欠和/或應付給記賬方的數量。在可選步驟S532，處理方可以向顧客通知該數量。在S540，處理方可以從顧客接收對要支付給記賬方的金額的數量的指示。如果顧客在S511中未提供與財務賬戶相關的信息，或如果顧客選擇不使用這種財務賬戶作為資金源,在S541，處理方可以從顧客接收金額或金額的標記。在S550，處理方可以確定從顧客或由顧客識別出的資金源或財務賬戶接收到的金額是否大于等于在S540中從顧客接收到的指示的支付數量。如果接收到的金額不足，或資金源或財務賬戶未具有充足數量的金額，在S551，可以向顧客通知該不足，且過程可以返回S540，其中，顧客提供對要支付給記賬方的金額的數量的新的指示。
在S560，如果接收到的數量金額充足，或資金源或財務賬戶具有充足數量的金額，則處理方可以確定支付平臺是否接受具有由顧客提供給處理方的格式的金額。如果支付平臺不接受具有由顧客提供給處理方的格式的金額，則處理方可以生成虛擬開放式預付費儲值或借記卡號，其具有要支付給記賬方的支付的數量(或與該數量相關聯)。在S570，從處理方向記賬方的支付平臺轉賬該金額。該金額可以具有由顧客提供給提供方的格式，或可以具有虛擬開放式預付費儲值或借記卡號的格式。在S580，處理方可以向顧客提供對進行過支付交易的確認。可以經由任何通信信道來發送該確認，且該確認可以具有任何格式。參見圖6，現在將討論根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的系統60。總體上，系統60包括:一個或多個顧客610、處理方620、以及記賬方的一個或多個支付平臺630。一個或多個顧客610可以通過通信信道615的任何變種與處理方620通信，例如(但不限于):互聯網、交互式語音識別(IVR)系統、消息(例如，SMS或MMS)、在電子設備上運行的應用或小應用、來自信息亭、銷售點設備、終端、或位置的通 目等等。處理方620可以包括:顧客接口 621、記賬方接口 622、處理模塊623、網絡數據提取模塊624、金額兌換模塊625、以及數據庫626。顧客接口可以處理與一個或多個顧客的所有對內和對外通信。由于每個顧客610可以使用不同的通信信道615，顧客通信接口 621可以統一識別與不同顧客的不同通信信道的多個接口。顧客接口 621可以提供在處理方和顧客之間的可選擇通信，且可以被配置為:從顧客接收金額、顧客的識別信息、足以識別提供方和顧客的預先存在的賬戶的信息、以及對在提供方處預先存在的顧客賬戶進行支付的數量的識別。記賬方接口 622可以處理與一個或多個記賬方和支付平臺630的所有對內和對外通信。由于每個記賬方630可以要求不同的通信屬性(例如，一些記賬方可以經由API接受通信和支付交易；其他記賬方可以要求經由特定網站或基于網絡的支付形式的通信和支付交易)，記賬方接口 622可以統一識別與多個記賬方的多個接口。記賬方接口可以提供在處理方和提供方之間的可選擇通信，其被配置為:訪問提供方的支付平臺或網站，以及向提供方的支付平臺或網站提供信息。處理模塊623可以與處理方620的每個組件通信，包括:顧客接口 621、記賬方接口 622、網絡數據提取模塊624、金額兌換模塊625、以及數據庫626。處理模塊可以被配置為執行所有所需確定和計算。例如，處理模塊624可以被配置為:至少將從顧客接收到的識別信息向支付平臺或網站輸入，以及向支付平臺或網站提供金額。網絡數據提取模塊624可以被配置為:確定用于進行支付的由記賬方所需的信息。這可以通過查詢支付平臺的網頁并確定需要什么信息以及在何處恰當插入這種信息來進行。金額兌換模塊625可以提供用于接受具有由顧客提供的第一格式的金額，并將其兌換為具有記賬方或支付平臺接受的第二格式的金額(減去任何適用的費用或稅費)的手段。例如，金額兌換模塊625可以接受封閉式儲值，并將其兌換為虛擬開放式儲值或借記卡。數據庫626可以耦合到處理模塊623，且可以存儲從顧客接收到的信息，且還可以存儲與在記賬方處預先存在的顧客賬戶相關的信息。例如，如果確立或使用具有特定登錄和密碼信息的顧客支付賬戶，數據庫可以在與特定記賬方和特定顧客相關聯的記錄中存儲所需的登錄和密碼信息。數據庫還可以存儲過去的交易信息，其可以用于記錄保持目的或用于重復或周期支付。參見圖7，現在將討論根據本發明的一些實施例的便于使用記賬方的支付平臺來支付顧客賬單的系統70。總體上，系統70包括:一個或多個顧客710、處理方720、一個或多個記賬方730、以及一個或多個財務機構740。一個或多個顧客710可以通過通信信道715的任何變種與處理方720通信，例如(但不限于):互聯網、交互式語音識別(IVR)系統、消息(例如，SMS或MMS)、在電子設備上運行的應用或小應用、來自信息亭、銷售點設備、終端、或位置的通信等等。一個或多個記賬方730可以包括向一個或多個顧客710銷售貨物或服務的提供方，或可以包括與貨物或服務的提供方分離的執行提供方的記賬功能或代表提供方執行記賬功能的實體。一個或多個財務機構740可以包括以下財務機構:其中，一個或多個顧客710具有可以用于向一個或多個記賬方730進行支付的財務賬戶。處理方720包括:顧客接口 721、記賬方接口 722、資金源接口 723、處理模塊724、網絡數據提取模塊725、網絡應用模塊726、金額兌換模塊727、虛擬預付費借記卡生成器728以及數據庫729。顧客接口 721可以處理與一個或多個顧客710的所有對內和對外通信。由于每個顧客710可以使用不同的通信信道715，顧客通信接口 721可以統一識別與不同顧客的不同通信信道的多個接口。顧客接口 721可以提供在處理方和顧客之間的可選擇通信，且可以被配置為:從顧客接收金額、顧客的識別信息、足以識別提供方和顧客的預先存在的賬戶的信息、以及對在提供方處預先存在的顧客賬戶進行支付的數量的識別。記賬方接口 722可以處理與一個或多個記賬方和支付平臺730的所有對內和對外通信。由于每個記賬方730可以要求不同的通信屬性(例如，一些記賬方可以經由API接受通信和支付交易；其他記賬方可以要求經由特定網站或基于網絡的支付形式的通信和支付交易)，記賬方接口 722可以統一識別與多個記賬方的多個接口。記賬方接口 722可以提供在處理方720和提供方或記賬方730之間的可選擇通信，其被配置為:訪問記賬方或提供方的支付平臺或網站，以及向記賬方或提供方的支付平臺或網站提供信息。資金源接口 723可以處理與一個或多個資金源的所有對內和對外通信。由于每個資金源740可以要求不同的通信屬性(例如，一些資金源(如財務機構)可以要求增加安全性或授權)，資金源接口 723可以統一識別與多個資金源的多個接口。處理模塊724可以與處理方720的所有其他組件通信。處理模塊724可以執行進行支付交易所必需的所有確定，如圖1 5及其所附討論所闡述的。網絡數據提取模塊725可以被配置為:確定用于進行支付的由記賬方所需的信息。這可以通過查詢支付平臺的網頁并確定需要什么信息以及在何處恰當插入這種信息來進行。網絡應用模塊726可以與記賬方的支付平臺網站交互，且可以用于向各種記賬方支付平臺系統之中或之上的恰當字段、欄、或輸入區域中插入正確信息。換言之，網絡應用模塊726可以識別提供方支付平臺所請求的每一條信息，根據從顧客接收到的識別信息來確定恰當的信息，以及響應于提供方支付平臺所請求的每條信息來提供恰當的信息。這可以包括自動填寫在線表單。金額兌換模塊727可以提供用于接受具有由顧客提供的第一格式的金額，并將其兌換為具有記賬方或支付平臺接受的第二格式的金額(減去任何適用的費用或稅費)的手段。當要將從顧客接收到的金額兌換為虛擬開放式儲值或借記卡時，金額兌換模塊727可以與虛擬預付費借記卡生成器728交互。虛擬預付費借記卡生成器728可以生成可由記賬方接受的具有等于要向記賬方支付的數量的虛擬借記卡(例如，Visa或MasterCard品牌預付費借記卡)。數據庫729可以耦合到處理模塊724，且可以存儲從顧客接收到的信息，且還可以存儲與在記賬方處預先存在的顧客賬戶相關的信息。例如，如果確立或使用具有特定登錄和密碼信息的顧客支付賬戶，數據庫可以在與特定記賬方和特定顧客相關聯的記錄中存儲所需的登錄和密碼信息。數據庫還可以存儲過去的交易信息，其可以用于記錄保持目的或用于重復或周期性支付。應該理解:本文所示和所述的本發明的具體實施例僅是示例性的。在不脫離本發明的精神和范圍的情況下，本領域技術人員將能夠進行各種變化、改變、替換和等價。例如，處理方可以由財務機構、資金源、商家、或記賬方來維護或管理。因此，預期將本文所述和附圖所示的所有主題僅視為是說明性的，且不是限制性的，且本發明的范圍僅由所附權利要求來確定。
權利要求
1.一種向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的方法，所述方法方便了顧客、貨物或服務的提供方以及處理方，所述方法包括: 從所述顧客接收: 金額； 所述顧客的識別信息；以及 足以識別所述提供方和所述顧客的預先存在的賬戶的信息；訪問所述提供方的支付平臺； 確定為了向所述顧客賬戶提供支付所述提供方所需的信息； 傳輸為了向所述顧客賬戶提供支付所述提供方所需的信息；以及 向所述顧客賬戶提供金額。
2.根據權利要求1所述的方法，其中，經由從以下各項構成的組中選擇的方式來接收金額、所述顧客的識別信息、以及足以識別所述提供方和所述顧客的預先存在的賬戶的信息:互聯網、自動語音識別(IVR)系統、經由短消息服務(SMS)發送的消息、經由媒體消息服務(MMS)發送的消息、在移動設備上運行的應用、信息亭、銷售點設備、以及商家位置。
3.根據權利要求1所述的方法，其中，從所述顧客接收金額包括:訪問儲值賬戶。
4.根據權利要求3所述的方 法，其中，所述儲值賬戶是封閉式儲值賬戶。
5.根據權利要求1所述的方法，其中，從所述顧客接收金額包括:由所述顧客向銷售點設備進行支付，以及所述處理方在稍后時間與所述銷售點設備結算。
6.根據權利要求1所述的方法，其中，所述顧客的識別信息包括:對所述顧客賬戶進行支付所述提供方所需的信息。
7.根據權利要求6所述的方法，其中，所述識別信息包括登錄信息和密碼。
8.根據權利要求1所述的方法，其中，足以識別所述提供方和所述顧客的預先存在的賬戶的信息包括:賬號。
9.根據權利要求1所述的方法，其中，足以識別所述提供方和所述顧客的預先存在的賬戶的信息包括:與在所述提供方處的所述顧客的賬戶相關聯的標記。
10.根據權利要求9所述的方法，其中，所述標記包括電話號碼。
11.根據權利要求1所述的方法，其中，訪問所述提供方的支付平臺的步驟是經由互聯網實現的。
12.根據權利要求1所述的方法，其中，訪問所述提供方的支付平臺的步驟包括:訪問由所述提供方維護的或與所述提供方相關聯的支付網頁。
13.根據權利要求1所述的方法，其中，確定為了向所述顧客賬戶提供支付所述提供方所需的信息的步驟是通過所述處理方執行的網絡查詢或網絡數據提取程序來實現的。
14.根據權利要求1所述的方法，其中，確定為了向所述顧客賬戶提供支付所述提供方所需的信息的步驟包括:確定為了向顧客賬戶進行支付所述提供方所需的具體信息。
15.根據權利要求1所述的方法，其中，傳輸為了向所述顧客賬戶提供支付所述提供方所需的信息的步驟包括:將接收自所述顧客的識別信息插入所述提供方的支付平臺。
16.根據權利要求1所述的方法，其中，傳輸為了向所述顧客賬戶提供支付所述提供方所需的信息的步驟包括: 識別所述提供方支付平臺所請求的每條信息；根據接收自所述顧客的識別信息來確定恰當信息； 響應于所述提供方支付平臺所請求的每條信息，提供所述恰當信息。
17.根據權利要求16所述的方法，其中，傳輸所述提供方需要的信息的步驟包括:自動填寫在線表單。
18.根據權利要求1所述的方法，其中，向所述顧客賬戶提供金額的步驟包括:向在所述提供方處的所述顧客賬戶發送從所述顧客接收到的金額。
19.根據權利要求18所述的方法，其中，向所述顧客賬戶提供的金額是從接收自所述顧客的金額中扣除適用費用和稅費之后的剩余部分。
20.根據權利要求19所述的方法，其中，在銷售點設備處從所述顧客接收金額，以及基于從由以下各項構成的組中選擇的一個或多個因素來計算適用費用和稅費:與所述顧客賬戶相關聯的位置；所述銷售點設備的位置；所述處理方的位置；以及所述提供方的位置。
21.根據權利要求1所述的方法，其中，向所述顧客賬戶提供金額的步驟包括:生成虛擬預付費借記卡號，并向所述提供商的支付平臺提供所述虛擬預付費借記卡號。
22.根據權利要求21所述的方法，其中，所述虛擬預付費借記卡號具有等于要支付給所述提供方的數量的資金。
23.一種向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的方法，所述方法方便了顧客、貨物或服務的提供方以及處理方，所述方法包括: 從所述顧客接收 金額； 包括所述顧客的姓名和地址在內的所述顧客的識別信息；以及包括所述預先存在的顧客賬戶的賬號在內的足以識別所述提供方和所述顧客的預先存在的賬戶的信息； 對要支付給在所述提供方處預先存在的顧客賬戶的支付數量的標識； 由所述處理方經由互聯網訪問所述提供方的支付網站； 查詢所述支付網站，以確定為了進行支付所述提供方所需的信息； 所述提供方代替所述顧客采取行動，并向所述支付網站輸入接收自所述顧客的識別信息； 確定所述提供方是否接受具有從所述顧客接收到的金額的形式的支付； 當確定所述提供方接受具有從所述顧客接收到的金額的形式的支付時，將從所述顧客接收到的金額傳送給所述提供方； 當確定所述提供方不接受具有從所述顧客接收到的金額的形式的支付時，生成虛擬預付費借記卡號，并將所述虛擬預付費借記卡號傳送給所述提供方； 向所述顧客提供對支付的確認。
24.根據權利要求23所述的方法，其中，經由從以下各項構成的組中選擇的方式來接收金額、所述顧客的識別信息、以及足以識別所述提供方和所述顧客的預先存在的賬戶的信息:互聯網、自動語音識別(IVR)系統、經由短消息服務(SMS)發送的消息、經由媒體消息服務(MMS)發送的消息、在移動設備上運行的應用、信息亭、銷售點設備、以及商家位置。
25.根據權利要求23所述的方法， 其中，從所述顧客接收金額包括:由所述顧客向銷售點設備進行支付，以及所述處理方在稍后時間與所述銷售點設備結算。
26.根據權利要求23所述的方法，其中，從所述顧客接收金額包括:訪問儲值賬戶。
27.根據權利要求26所述的方法，其中，所述儲值賬戶是封閉式儲值賬戶。
28.根據權利要求27所述的方法，其中，從所述顧客接收金額包括:由所述顧客在商家處使用僅能由所述商家贖回的封閉式儲值卡來進行支付。
29.一種用于向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的處理方，所述處理方選擇性地與所述顧客和所述提供方通信，所述處理方包括: 顧客接口，提供在所述處理方和所述顧客之間的能夠選擇的通信，所述顧客接口被配置為從所述顧客接收: 金額； 包括所述顧客的姓名和地址在內的所述顧客的識別信息；以及包括所述預先存在的顧客賬戶的賬號在內的足以識別所述提供方和所述顧客的預先存在的賬戶的信息； 對要支付給在所述提供方處預先存在的顧客賬戶的支付數量的標識； 提供方接口，在所述處理方和所述提供方之間提供能夠選擇的通信，所述提供方接口被配置為: 訪問所述提供方的支付平臺或網站；以及 向所述提供方的支付平臺或網站提供信息； 網絡數據提取模塊，與所述提供方接口通信，所述網絡數據提取模塊被配置為:確定為了進行支付所述提供方所需的 信息； 處理模塊，與所述顧客接口、所述提供方接口、以及所述網絡數據提取模塊通信，所述處理模塊被配置為: 向所述支付平臺或網站輸入接收自所述顧客的識別信息； 向所述支付平臺或網站提供金額。
30.根據權利要求29所述的系統，其中，所述處理模塊還被配置為: 確定所述提供方是否接受具有從所述顧客接收到的金額的形式的支付； 當確定所述提供方接受具有從所述顧客接收到的金額的形式的支付時，將從所述顧客接收到的金額傳送給所述提供方； 當確定所述提供方不接受具有從所述顧客接收到的金額的形式的支付時，生成虛擬預付費借記卡號，并將所述虛擬預付費借記卡號傳送給所述提供方。
31.根據權利要求29所述的系統，還包括: 金額兌換模塊，被配置為:從所述顧客接受具有特定幣值的金額，扣除適用費用或稅費，以及將剩余金額兌換為所述提供方的支付平臺或網站接受的幣值。
32.根據權利要求29所述的系統，還包括: 虛擬預付費借記卡生成器，被配置為:生成具有關聯賬戶的預付費借記卡號，所述關聯賬戶具有要支付給所述預先存在的顧客賬戶的支付數量的資金。
33.根據權利要求29所述的系統，還包括: 財務賬戶接口，提供在所述處理方和所述顧客的財務賬戶之間的能夠選擇的通信，所述財務賬戶接口被配置為向所述處理方轉賬。
34.根據權利要求29所述的系統，其中，所述顧客接口經由從以下各項構成的組中選擇的方式提供與所述顧客的通信:互聯網、自動語音識別(IVR)系統、經由短消息服務(SMS)發送的消息、經由媒體消息服務(MMS)發送的消息、在移動設備上運行的應用、信息亭、銷售點設備、以及商家位置。
35.根據權利要求29所述的系統，其中，所述顧客接口還被配置為:在已成功進行對所述預先存在的顧客賬戶的支付之后，向所述顧客`提供對支付的確認。
全文摘要
本發明涉及向在貨物或服務的提供方處預先存在的顧客賬戶提供支付的系統和方法，該方法便于顧客、貨物或服務的提供方以及處理方。所述方法包括例如以下步驟從所述顧客接收金額、所述顧客的識別信息、以及足以識別所述提供方和所述顧客的預先存在的賬戶的信息；訪問所述提供方的支付平臺；確定為了向所述顧客賬戶提供支付所述提供方需要的信息；傳輸為了向所述顧客賬戶提供支付所述提供方需要的信息；以及向所述顧客賬戶提供金額。
文檔編號G06Q20/14GK103180867SQ201180051839
公開日2013年6月26日 申請日期2011年7月11日 優先權日2010年8月26日
發明者梅安爾·布魯克斯·史密斯, 菲利普·克雷格·格雷夫斯, 菲爾·M·查克里斯 申請人:e2因特萊科迪伏有限公司