專利名稱：移動的個人之間支付系統(tǒng)的制作方法
移動的個人之間支付系統(tǒng)從歷史來看，希望進行金融交易以購買商品的帳戶持有人都 是依賴諸如貨幣、支票、信用卡或借記卡之類的各種金融工具。令人 遺憾的是，這些金融工具種類存在某些安全性問題，防欺詐對于支付 行業(yè)的盈利率是一個大的考驗。當現(xiàn)金丟失或被盜時，通常沒有補救 的辦法，唯有接受損失。對于其他金融工具，損失不是主要問題，但 是，欺詐會導致支付行業(yè)的嚴重損失。的確，信用卡、借記卡以及支 票欺詐一直是并將繼續(xù)是該行業(yè)的較大的問題。通過語音、電子郵件、SMS文本消息、即時消息以及因特 網(wǎng)處理通信的移動電話設備及其他便攜式設備有了爆炸式的增長。人 們常常記住隨身攜帶他們的移動或蜂窩電話，即使他們忘記攜帶他們 的錢包或汽車鑰匙。移動電話在美國以及全世界的許多國家無所不 在。在2005年，據(jù)估計，有21.4億移動電話用戶。世界的人口的 大約80%擁有移動電話覆蓋。因此，對于允許移動電話發(fā)出支付和 接收支付(如現(xiàn)金)，并提供其他金融和移動銀行交易的系統(tǒng)的需求 是巨大的。交易處理器3402通過私用網(wǎng)絡3404向信用卡交換中心 (進行通信以管理信用卡交易的處理、清算，以及結算的金融實體的 網(wǎng)絡)提交交易。信用卡交換中心將交易路由到用戶的信用卡發(fā)行者 3409那里。發(fā)行者基于檢測到的帳號識別消費者，并在批準或者拒 絕交易之前確定可用的信用額度。如果批準了交易，則通過信用卡交 換中心將金額轉發(fā)到商家的銀行處理器3405,金額被添加到商家的 銀行維護的信用帳戶。在一個實施例中，本發(fā)明是包括下列步驟的方法在移動電 話的顯示器上顯示第一屏幕，以顯示多個選項，包括向另一方付款的 第一選項和請求余額信息的第二選項；在用戶選擇第一選項時，顯示 第二屏幕，供用戶輸入向其發(fā)出支付的目標電話號碼；在用戶輸入目 標電話號碼之后，顯示第三屏幕，供用戶輸入交易金額；在用戶輸入 電話號碼之后，顯示第四屏幕，供用戶輸入PIN代碼；以及，在用 戶輸入PIN代碼之后，以無線方式向服務器發(fā)送交易信息，包括目 標電話號碼、交易金額，以及PIN代碼，以便進行處理。在一種實現(xiàn)方式中，該方法包括當在移動電話中接收到要 求付款的請求時，顯示第五屏幕，供用戶可以輸入小費金額。

圖1顯示了本發(fā)明的系統(tǒng)的方框圖。36圖2顯示了本發(fā)明的特定實施例的軟件體系結構。 [37圖3顯示了用于實現(xiàn)本發(fā)明的實施例的環(huán)境。38]圖4顯示了本發(fā)明的實施例，其中，與支付服務一起提供 了增值服務。圖15顯示了在一個有卡會員和一個無卡會員之間進行交 易的方法。圖25顯示了本發(fā)明的另一個特定實施例的完整的系統(tǒng)圖形。圖26顯示了無卡帳戶和無卡帳戶之間的個人之間的支付。[61圖27顯示了無卡帳戶和卡帳戶之間的個人之間的支付。圖29顯示了獎勵資金。圖31顯示了 ACH加載。圖44顯示了支持會員的支付系統(tǒng)中的購物交易。 [79圖45顯示了使用虛擬合并帳戶的系統(tǒng)。 [80圖46顯示了根據(jù)本發(fā)明的實施例的購物功能。 [81圖47顯示了根據(jù)本發(fā)明的實施例的另一個購物功能。 [82圖48是由根據(jù)本發(fā)明的實施例的至少一個SMS消息機 制執(zhí)行的金融交易的系統(tǒng)級別的例圖。圖54， 55和56顯示了根據(jù)本發(fā)明的實施例的用于防止欺 詐和多重重復交易請求的方法。圖62顯示了根據(jù)本發(fā)明的實施例的另一個服務電話的成 功的調用。圖64是顯示了根據(jù)本發(fā)明的實施例的OMAP通信設計 的狀態(tài)圖。圖68顯示了根據(jù)本發(fā)明的實施例的OMAP主菜單的布局。圖69顯示了根據(jù)本發(fā)明的實施例的從來源角度來看的 OMAP支付屏幕流程。圖70顯示了根據(jù)本發(fā)明的實施例的從目標角度來看的 OMAP支付屏幕流程。圖71顯示了根據(jù)本發(fā)明的實施例的從源-請求角度來看的 OMAP請求支付屏幕流程。圖75顯示了根據(jù)本發(fā)明的實施例的其中源和目標兩者都 拒絕請求的OMAP請求支付屏幕流程。圖76顯示了根據(jù)本發(fā)明的實施例的OMAP余額屏幕流程。
109圖77顯示了根據(jù)本發(fā)明的實施例的OMAP歷史屏幕流程。圖78顯示了根據(jù)本發(fā)明的實施例的在源位置的OMAP 設置屏幕流程。圖79顯示了根據(jù)本發(fā)明的實施例的未知移動ID的 OMAP的屏幕流程。圖98顯示了圖96的布局如何翻轉過來，以便可以存儲 在蜂窩電話內。圖1顯示了本發(fā)明的系統(tǒng)的方框圖，用于進行價值交換交 易，包括以特定實現(xiàn)方式實現(xiàn)的，移動的個人之間支付和交易，移動 的個人與商家的支付交易，以及移動銀行。應用程序服務器107連
接到網(wǎng)絡109。雖然只顯示了一個應用程序服務器，但是，在本發(fā)明 的系統(tǒng)中，可以有任意數(shù)量的應用程序服務器。這樣的應用程序服務 器可以在單一服務器機器上運行，也可以在許多服務器機器上運行。 隨著應用程序服務器上的負載增大，通常，將使用更多的機器來處理 和響應增大的負載。在應用程序服務器上，有一個也可以連接到商家界面的支 付處理器119。金融機構界面123連接到應用程序服務器和支付處 理器?？梢杂腥我鈹?shù)量的金融機構連接到應用程序服務器。應用程序 服務器也可以包括數(shù)據(jù)庫127?；蛘撸瑪?shù)據(jù)庫可以位于與應用程序服 務器分開的服務器上，應用程序服務器通過網(wǎng)絡或其他連接可以訪問 它。金融機構也連接到數(shù)據(jù)庫。數(shù)據(jù)庫可以包括應用程序服務器可以 管理的記錄系統(tǒng)130和虛擬合并帳戶134。金融機構可以管理合并 帳戶138。因此，在金融機構中，可以與合并帳戶分開地管理記錄系 統(tǒng)和虛擬合并帳戶。在用戶Web應用程序容器中，有針對不同類型的客戶端 的接口的表示層。所提供的接口的一些示例包括SMS網(wǎng)關、電話應 用程序網(wǎng)關、萬維網(wǎng)服務網(wǎng)關、Web應用程序頁面網(wǎng)關，以及Web 應用程序框架網(wǎng)關。電話消息編解碼器將諸如SMS或電話之類的傳 入的或傳出請求或兩者轉換為系統(tǒng)或客戶端特定的消息。本發(fā)明的體 系結構可以包括任意數(shù)量的這些界面。計算機軟件產(chǎn)品可以以各種合適的編程語言中的任何一種 進4亍編寫，如C、 C++、 C#、 Pascal、 Fortran、 Perl、 SAS、 SPSS、 JavaScript、 AJAX,以及Java。計算機軟件產(chǎn)品可以是帶有數(shù)據(jù)輸 入和數(shù)據(jù)顯示模塊的獨立應用程序?；蛘?，計算機軟件產(chǎn)品可以是類， 可以作為分布式對象而實例化。計算機軟件產(chǎn)品也可以是諸如Java Beans(來自 Sun Microsystems )或Enterprise Java Beans(來自 SunMicrosystems的EJB)。平臺302包括服務器308,用于處理與帳戶持有人的交 互，并維護交易記錄。服務器308還提供到由商業(yè)合作伙伴所提供 的增值服務的鏈接。服務器308利用交易數(shù)據(jù)庫309，該數(shù)據(jù)庫優(yōu) 選情況下包括數(shù)據(jù)存儲網(wǎng)絡。服務器308使用從交易數(shù)據(jù)庫309獲 得的信息(如帳號、余額信息等等)，來管理與商業(yè)銷售點(POS)終 端311進行通信的支付處理器310。商家可以使用POS終端311 來進行金融交易，如向帳戶持有人的借記卡添加資金。商家也可以與 支付服務器302建立單獨的鏈接，以用于結算目的。為說明，銷售引擎從參與的商家向帳戶持有人提供了贈券 或折扣。此引擎還控制即時賒帳的使用，以獎勵注冊。商家合作伙伴在另一個實施例中，信用卡帳戶被指定為主要帳戶，每當 借記卡帳戶中的資金下降到或低于某一個選定金額時，現(xiàn)金預付被移 動到預存款借記卡帳戶中。
187]在再一個實施例中，金融交易是在個人之間進行的，每一 方都通過電話號碼和密碼(例如，個人標識號，PIN)來進行標識。 或者，金融交易也可以通過用戶名和密碼來進行標識。在其他實施例 中，參與交易的至少一方通過條形碼來進行標識。條形碼可以顯示在 諸如移動電話的屏幕之類的顯示器上，并由大多數(shù)現(xiàn)代的移動設備上 具有的照相機進行檢測。條形碼可以打印在設備上，也可以以別的方 式附著于移動設備上。對于帳戶持有人來說，達成金融交易是無縫的。只需通過 從配備移動客戶端應用程序的移動電話向服務器發(fā)送一 則消息即可。 支付服務器驗證每一個交易，并劃撥資金，或響應帳戶持有人的對帳 戶信息的請求?！㏒MS消息被發(fā)送到支付服務器，就可以由帳戶持有 人輸入PIN，并通過音頻信道連接發(fā)送到支付服務器，以驗證SMS 消息。PIN是通過鍵盤輸入的，可以是任何字母數(shù)字代碼。然后，PIN 被作為DTMF編碼消息發(fā)送給支付服務器，其中，DTMF是指雙音 多頻，是當電話的接觸鍵被按下時電話公司接收到的信號。在一個實施例中，移動設備包括移動客戶端應用程序。移 動客戶端應用程序要么由帳戶持有人直接調用，要么響應移動設備上 的SMS文本消息功能的激活而調用。MCA確定發(fā)送PIN的最佳 方法。在又一個備選實施例中，移動客戶端應用程序在移動設備 的顯示屏幕上提供用戶界面(UI)，引導帳戶持有人進行金融交易。在 此實施例中，通過自動插入關鍵字、金額、目標電話號碼、密碼，以 及消息(如果有的話)，來引導帳戶持有人完成構建SMS文本消息 的過程。表B
關鍵字目標移動電話號碼金額消息(可選)
pay##########Abed當使用SMS方法或組合的SMS加語音方法對帳戶持 有人作出支付請求時，他們可以使用手動SMS文本消息系統(tǒng)來接受 或者拒絕該請求。在支付服務器端， 一個或多個數(shù)據(jù)中心將具有用于處理金 融交易的系統(tǒng)。每一個數(shù)據(jù)中心都將包含PBX/ACD/VRU技術的組 合，以允許多個同時的呼叫處理?？梢允褂肰RU技術來提供可編程 入站和出站DTMF支持。VRU可以連接到表示實際業(yè)務邏輯的企 業(yè)J2EE系統(tǒng)和記錄金融交易的記錄系統(tǒng)。然后，J2EE系統(tǒng)可以與 用于進行交易結算的實際銀行集成。在一種實現(xiàn)方式中，為SMS安 全性，有一次性的密碼選項來作為選項。這是通過讓用戶發(fā)送交易而 沒有PIN來工作的，系統(tǒng)將給用戶發(fā)送一系列問題讓他們回答。向另一個帳戶持有人或商家匯款既便捷又簡單。本系統(tǒng)簡 化了批量支付，如從許多帳戶持有人為一個慈善活動募捐，或同時從 同 一個帳戶持有人進行多個交易。本發(fā)明的靈活性可提供在交易中選擇和標識各方的新穎的 方法。在一個實施例中，付款人可以通過他們的移動設備的小鍵盤鍵 入電話號碼或其他標識碼。標識碼可以是特殊的三、四或五位"短代 碼"，由移動服務提供商轉換為特定帳戶。例如，如果帳戶持有人希 望下載由諸如CBS電視網(wǎng)之類的電視網(wǎng)提供的電視節(jié)目，帳戶持有 人可以鍵入227的短代碼，支付給該網(wǎng)絡，以獲得所希望的內容。 短代碼可以使用任何字母數(shù)字字符。此實施例要求，某些方面獲取短 代碼，以鼓勵用戶訪問他們的服務。相應地，本發(fā)明有三種不同的收入來源;漠式。具體來說，(1) 針對參與金融交易的一方或雙方，評估"每次交易"。優(yōu)選情況下，費
用金額從大約一個美分到大約$0.15; (2)包月收費，每個帳戶持有人都支付每月的服務費；(3)對于超過選定金額，如，作為說明，$50， 的交易，較高的交易費用，對于所有其他交易，；故棄費用；以及，(4) 增值服務，如鏈接帳戶服務，以自動地記錄交易細節(jié)或幫助準備提交 稅務報表。服務可以獲得持有資金的浮動收益或廣告收入，這些可以
適用于商家費用(例如，交易費用)。
241圖4顯示了本發(fā)明的系統(tǒng)的另一種實現(xiàn)方式。圖4顯示 了在兩個帳戶持有人之間使用增值服務的一個實施例。作為示例，如 果與移動設備401關聯(lián)的帳戶持有人啟動一個向移動設備402的 轉帳操作，則向服務器平臺403傳輸支付請求，如引用箭頭404所 示。支付請求可以包括支付事宜的可選描述。例如，帳戶持有人可以 對支付事項進行批注，以表示它是支出帳商品。描述可以從顯示在移 動設備401上的菜單中選擇。或者，描述可以是與支付請求關聯(lián)的 語音或文本消息。圖5顯示了移動的個人之間支付的系統(tǒng)的進一步的實現(xiàn) 方式。如上文所討論的，本發(fā)明的特定實施例允許用戶或客戶端通過 Web(例如，通過因特網(wǎng)瀏覽器)、WAP(例如，通過移動電話、智 能電話、個人數(shù)字助理設備上的移動因特網(wǎng)瀏覽器)、SMS(例如， 通過移動電話的文本消息)、IVR(例如，從電話按鍵理解用戶的語 音響應或音調的交互式語音響應系統(tǒng))、WSDL (例如，可以通過諸 如智能電話之類的移動設備進行訪問的萬維網(wǎng)服務)與移動支付系統(tǒng) 連接。[249系統(tǒng)可以通過多個運營商中的任何一種，如Verizon、 Cingular (AT&T)、 Sprint、 Nextel、 AUtel、 Virgin Mobile、 Amp，d Mobile、 U.S. Cellular、 T-Mobile及其他運營商與無線電話連接。本 服務也可以與預存款電話連接。移動運營商的一些優(yōu)點包括基于收 入共享模式的傳輸或基于預訂。促進應用程序下載/購買。促進網(wǎng)絡或
數(shù)據(jù)使用。促進SMS使用。"Offbill，，支付解決方案將幫助減輕驚人 的"big bill"問題。可以有所討論的任何數(shù)量的合作伙伴以及服務，以及任何
的組合。例如，系統(tǒng)可以只有一個合作伙伴、可以具有兩個合作伙伴，
三個合作伙伴，或三個以上的合作伙伴。系統(tǒng)可以包括只提供供移動
客戶端訪問的借記卡(即，無信用卡)的單一銀行合作伙伴。系統(tǒng)可
以包括提供供移動客戶端訪問的借記卡和信用卡的單一銀行合作伙
伴。系統(tǒng)可以包括兩個或更多銀行合作伙伴， 一個提供供移動客戶端
訪問的借記卡，另一個提供不同的借記卡。系統(tǒng)可以包括兩個或更多
銀行合作伙伴， 一個提供供移動客戶端訪問的借記卡，另一個提供不
同的借記卡和信用卡。系統(tǒng)可以包括只提供供移動客戶端訪問的信用
卡的單一銀行合作伙伴。系統(tǒng)可以包括只提供供移動客戶端訪問的信 用卡的單一銀行合作伙伴。在系統(tǒng)的特定實現(xiàn)方式中，讓受方合作伙伴具有結算帳戶。 銀行合作伙伴具有合并帳戶和往來帳戶。直接合作伙伴具有合并帳戶 和往來帳戶。預存款處理合作伙伴具有合并帳戶和往來帳戶。ACH合 作伙伴具有結算帳戶。移動支付系統(tǒng)可以提供合并帳戶管理、跨銀行 結算和資金管理，以及移動銀行集成中的一個或多個。系統(tǒng)的資金通過所有合作銀行的合并帳戶的總和來表示。 通過與移動支付系統(tǒng)的商務關系，移動支付系統(tǒng)促進了定期資金管理 處理過程，以便合作銀行的合并帳戶保留的余額代表他們對移動支付 系統(tǒng)客戶群體的貢獻加上"其他"移動支付系統(tǒng)資金的同意的百分比。 客戶的獲取"路徑"規(guī)定了給定合作銀行的合并帳戶余額(即，合作銀 行通過"他們的"路徑獲得的客戶越多，他們的關聯(lián)的合并帳戶的余額 就越高)。對于驗證狀態(tài)，用戶的身份是已知的。用戶提供地址或其 他相關的聯(lián)系信息。用戶在驗證狀態(tài)下可以收到、請求、添加(即， 加載)或提取(即，卸載)資金。對于高級狀態(tài)，用戶已經(jīng)提供了用戶的社會保障號碼。在 此狀態(tài)下，例如，用戶可以向特定銀行合作伙伴進行注冊，以接收卡。 此卡可以是預存款的借記卡。在其他實施例中，卡可以是信用卡。用 戶將能夠做驗證用戶所能夠做的一切，外加能夠立刻在接受卡的任何 地方進行消費。可以通過一個或多個網(wǎng)絡，包括Visa、 MasterCard、 American Express、 NYCE、 PLUS或STAR,或這些4幾構的任4可組 合，接受或使用卡。卡鏈接到用戶的帳戶。沒有卡的用戶可以叫做無 卡用戶，而有卡的用戶可以叫做有卡用戶。當進行注冊時一個人可以獲得驗證的一些方式包括對于 人的信息，系統(tǒng)可以要求提供地址和駕駛執(zhí)照號碼。 一種備選方案是 要求提供地址和社會保障號碼?？梢詫φ罩T如Equifax數(shù)據(jù)庫之類 的信用報告機構的數(shù)據(jù)庫，核對該信息。對于鏈接的銀行帳戶，可以 使用質詢儲蓄來對這些進行驗證。例如，系統(tǒng)可以將任意數(shù)量的小額 存款放入用戶的帳戶中。用戶告訴系統(tǒng)，那些存款的金額，以獲得驗 證?；蛘撸脩裟芡ㄟ^在線即時帳戶驗證來進行驗證，其中，用戶提 供在線的屏幕姓名和密碼。對于添加信用卡或借記卡，也可以使用質 詢儲蓄來對這些進行驗證。諸如Visa和MasterCard之類的一些卡 也可以使用安全代碼等等來進行驗證。
269]參與的速度是對帳戶設置某些限制的一種設置。對帳戶設置的限制的一些示例有用戶一天可以進行多少次交易，或在一次交 易中最多可以轉帳多少金額?？梢杂幸恍┯残韵拗坪蛙浶缘南拗啤Ｓ?性限制將不會隨第三方的千涉(如人更改限制)而變化。軟性的限制 可以隨著用戶的操作而變化。例如，在用戶已經(jīng)成為會員六個月之后， 當用戶的對于一些號碼的前一限制少于五時時，可以自動地允許用戶 一天可以進行五次交易。系統(tǒng)流程[275圖6顯示了在同業(yè)銀行的個人之間的支付。此圖顯示了一 個消費者A向另一個消費者B匯款，其中，這兩個消費者都是同 一個銀行合作伙伴A的會員。本發(fā)明的移動支付系統(tǒng)將處理該交易。
276交易的基本流程是(1)消費者A向移動支付系統(tǒng)發(fā)送 支付請求。此支付請求可以通過此專利中所討論的任何一種方式來提 供。(2)移動支付系統(tǒng)更新移動支付系統(tǒng)的記錄系統(tǒng)(SOR)中的T 或交易記錄中，以反映交易。這些交易記錄是由移動支付系統(tǒng)進行管 理的。(3)系統(tǒng)(例如，Obopay)將支付情況通知給消費者B。這可 以通過電子通知、電子郵件、即時消息、SMS消息，或其他通知來 進行。(3)在現(xiàn)有會員選擇向非會員匯款的情況下，支付系統(tǒng)必須 通過各種常見的通信機制(如電子郵件、語音，及其他)通知非會員， 已經(jīng)向他們匯了款。下面是在支付系統(tǒng)內進行病毒式資金轉帳的技術的多個實施例。5.向B的匯款金額從A的帳戶中劃出，并被保留，等待 B的注冊。7.用戶B在系統(tǒng)網(wǎng)站(例如，obopay.com)進行注冊。8.在用戶B成功地進行注冊之后，B的帳戶自動地4皮注 入了 A的轉帳資金。
305實施例1B 1.現(xiàn)有會員用戶A決定通過給B匯款來邀請非會員用戶 B加入，B必須通過注冊為會員才能接收款項。6.用戶B接收到一則消息，說明A已經(jīng)邀請B加入系 統(tǒng)，以<更A可以給B匯款。9.用戶A接收到"Request Pay",并同意該支付個人預留資金病毒式一 允許現(xiàn)有的會員留出資金，這是為 "病毒式，，支付預留的。例如，用戶可以撥出用戶的帳戶中的一定數(shù)量 的美元，以進行"病毒式"交易。這些資金將不會可用于"非病毒式"交 易(例如，通過借記卡進行花費)。在一種實現(xiàn)方式中，用戶能通過 用戶帳戶維護功能更改預留的金額。實施例3會話病毒式 一 實時地出現(xiàn)完整的病毒生命周期，將沿途 的其他"步驟，，通知給雙方。然后，最終的資金轉帳只是兩個會員之間 的轉帳。如果在由系統(tǒng)設置的一定天數(shù)(如三十天)之后用戶B還 沒有批準交易，則系統(tǒng)可以自動地取消交易。然后，系統(tǒng)可以向用戶 A和用戶B兩者發(fā)送電子通知，通知兩者，交易已取消。用戶B也 可以具有拒絕交易的選項，在這樣的情況下，可以通過電子通知，通 知用戶A，拒絕支付。圖15顯示了在一個有卡會員和一個無卡會員之間進行交 易的方法。該流程包括(1)會員A以會員B作為目標，向移動 支付服務服務器發(fā)送"pay"請求。(2)移動支付服務標識交易源A為 會員，對帳戶進行驗證，檢查余額，并檢查PIN。 (3)移動支付服務 識別目標B為會員，并對帳戶進行驗證。(4)移動支付服務將支付通 知給源會員A。 (5)移動支付服務將支付通知給目標會員B。(6)(a/b) 移動支付服務從會員A卡帳戶中劃出，并劃入會員合并帳戶。(7)(a/b) 移動支付服務記錄會員A劃出交易，并記錄會員B劃入交易。步 驟6和7可以是異步的服務器端線程。在步驟9中，只有在用戶B向系統(tǒng)進行注冊之后，才給 用戶B發(fā)送有關用戶A請求發(fā)出支付的消息。在本發(fā)明的另一個 實施例中，用戶B可以接收有關用戶A的支付的消息，無需向系 統(tǒng)進行注冊。在步驟14中，給用戶A發(fā)送一個類似于收據(jù)的SMS通 知，通知他交易已經(jīng)完成。在另一個實施例中，可以給用戶A發(fā)送 其他形式的通知，如通過電子郵件、即時消息、MMS消息，或其他 形式的移動通信。系統(tǒng)也可以給用戶B發(fā)送一個交易已經(jīng)完成的通 知。系統(tǒng)也可以不給用戶A或B發(fā)送有關交易完成的任何消息。在步驟15中，進行貨幣交易。在一種實現(xiàn)方式中，劃入 和劃出交易不實時進行。由于電子資金系統(tǒng)中的固有延時，交易可能 在處理開始之后大約六十秒或更多才能完成。流程A中的任意數(shù)量的步驟，以任何組合，都可以與任何 其他移動支付系統(tǒng)流程相結合，包括本申請中所討論的其他流程。， [value，[trans #j，， B不會接收到消息。 如果有足夠的資金，則進入下一步驟。
4檢查B是注冊的用戶還是未注冊的用戶。如果B的移動電話號碼沒有 被識別為注冊的用戶，則A接收到下列消息 "您的支付待辦。未注冊用戶必須開立帳戶。 [tel #1，value，[trans #，，
5B接收到下列消息 "您收到一筆款！tel #1，valuej， [trans #1 請去系統(tǒng)網(wǎng)站注冊。，，
6起始從A的個人帳戶劃出資金交易，并劃入未注冊用戶合并帳戶中的 B。
如果劃出和劃入交易失敗，則給A和B發(fā)送消息 "支付失敗。 [tel #，[value], [trans #，， 否則，劃出和劃入交易會成功。沒有發(fā)送消息。
8如果在A啟動交易之后已經(jīng)過去30天以上而B還沒有注冊，則交易 自動取消。然后，將給A和B發(fā)送消息 "支付已取消。 [tel #，value，[trans #]，， 上面的步驟6中請求的劃出和劃入交易顛倒。將從未注冊用戶合并帳戶 獲取的交易金額劃入A的個人帳戶。
9B在系統(tǒng)網(wǎng)站進行了注冊，并成為已注冊的無卡用戶。資金從未注冊用戶 合并帳戶轉帳到B的無卡合并帳戶。
10為B制作塑料借記卡，并寄給B。
11在B收到卡之后，B通過撥打交互式語音響應(IVR)系統(tǒng)來激活該卡。 在激活過程中，在B連接到IVR系統(tǒng)的同時，資金從無卡合并帳戶轉 帳到B的個人帳戶。[371流程B中的實現(xiàn)方式與上面的流程A相似。然而，與流 程A不同，流程B沒有在A的帳戶中預留交易金額(流程A的 步驟5)。在流程B的步驟4中，因為在A的帳戶中沒有預留并 且沒有從A的帳戶劃出，錢仍可以供用戶A通過移動支付或借記 卡支付進行花費，直到在步驟6中從用戶A的帳戶中成功地劃出交 易金額。在步驟10中，通常需要花費大約7到10個工作日，作 出新的卡，用戶B通過郵寄收到它。在本發(fā)明的另一個實施例中， 用戶B可以收到另一種卡，如信用卡，也可以選擇根本不接收卡。在步驟11中，在用戶B激活他的卡時，用戶B成為有 卡注冊的用戶，不再是無卡用戶。在不使用無卡合并帳戶的實施例中， 在卡被激活時，不需要劃撥余額。， [value!, [trans #]，， B不會接收到消息。 如果有足夠的資金，則進入下一步驟。
4檢查B是注冊的(無卡或有卡)用戶還是未注冊用戶。由于B是 注冊的用戶，發(fā)送下列消息 "您收到一筆款！ [tel #]， [value], [trans #]"
5檢查B是無卡注冊的用戶還是有卡注冊的用戶。由于B是有卡用 戶，開始從無卡用戶合并帳戶中的A劃出交易資金并劃入B的個 人帳戶。
6如果劃出和劃入交易失敗，則給A和B發(fā)送消息 "支付失敗。 ftel #1, [valuel，trans #1"
7如果B打開了自動接受，則資金從無卡合并帳戶中的A轉帳到B 的個人帳戶。沒有發(fā)送消息。
8如果B關閉了自動接受，則劃出和劃入交易只有在B批準交易之 后才進行。
9如果在A啟動交易之后已經(jīng)過去30天以上而B還沒有批準，則 交易自動取消。然后，將給A和B發(fā)送消息 "支付已取消。 [tel #，[value，[trans #，， 如果B拒絕接收支付，則交易取消，給A發(fā)送一則消息 "支付已被拒絕。tel #1， [value，trans #1"
10如果B接受交易，而A仍是無卡用戶，則資金從無卡合并帳戶中 的A轉帳到B的個人帳戶。
如果B接受交易，而A現(xiàn)在是有卡用戶，則資金從A個人帳戶轉 帳到B的個人帳戶。[390上面所提供的備注也相應地適用于流程E。 [391]下面的流程F顯示了在有卡用戶(用戶A)和無卡用戶(用 戶B)之間進行交易的一種實現(xiàn)方式。步驟操作
1現(xiàn)有的用戶A(有卡注冊的用戶)決定給用戶B(無卡用戶)匯一些款。 A利用B的移動電話號碼向移動支付系統(tǒng)發(fā)送一則消息和交易金額。
2移動支付系統(tǒng)檢查A的帳戶是否具有足夠的資金來完成交易。
3如果資金不足，則給A發(fā)送一則消息 "資金不足。 [tel #，[value], [trans #，， B不會接收到消息。 如果有足夠的資金，則進入下一步驟。
4檢查B是注冊的(無卡或有卡)用戶還是未注冊用戶。如果B是注冊 的用戶，則發(fā)送下列消息 "您收到一筆款！ [tel #1，value，trans #，，
5檢查B是無卡注冊的用戶還是有卡注冊的用戶。如果B是無卡用戶， 則開始從A的個人帳戶中劃出交易資金并劃入無卡用戶合并帳戶中的 B。
6如果劃出和劃入交易失敗，則給A和B發(fā)送消息 "支付失敗。 [tel弁l，〖valuel，trans #1"
7如果B打開了自動接受，則資金從A的帳戶轉帳到B的無卡合并帳 戶。沒有發(fā)送消息。
8如果B關閉了自動接受，則劃出和劃入交易只有在B批準交易之后才 進行。
9如果在A啟動交易之后已經(jīng)過去30天以上而B還沒有批準，則交易 自動取消。然后，將給A和B發(fā)送消息 "支付已取消。 [tel #1， [value], [trans #，， 如果B拒絕接收支付，則交易取消，給A發(fā)送一則消息 "支付已被拒絕。 [tel #1， [valuel， ftrans #1"
10如果B接受交易，并且B仍是無卡用戶，則資金從A的帳戶轉帳到B 的無卡合并帳戶。如果B接受交易，并且B現(xiàn)在是有卡注冊的用戶，則 資金從A的帳戶轉帳到B的個人帳戶。
80[393上面所提供的備注也相應地適用于流程F。 [394下面的流程G顯示了在有卡用戶(用戶A)和有卡用戶 (用戶B)之間進行交易的一種實現(xiàn)方式。[395流程G
步驟操作
1現(xiàn)有的用戶A (有卡注冊的用戶)決定給用戶B (有卡注冊的用戶)匯 一些款。A利用B的移動電話號碼向移動支付系統(tǒng)發(fā)送一則消息和交易 金額。
2移動支付系統(tǒng)檢查A的帳戶是否具有足夠的資金來完成交易。
3如果資金不足，則給A發(fā)送一則消息 "資金不足。 [tel #，value，[trans司" B不會接收到消息。 如果有足夠的資金，則進入下一步驟。
4檢查B是注冊的(無卡或有卡)用戶還是未注冊用戶。由于B是注冊 的用戶，發(fā)送下列消息 "您收到一筆款！ 〖tel #，[value，ftrans #1"
5檢查B是無卡注冊的用戶還是有卡注冊的用戶。由于B是有卡用戶， 開始從A的個人帳戶劃出交易資金并劃入B的個人帳戶。
6如果劃出和劃入交易失敗，則給A和B發(fā)送消息 "支付失敗。 ftel #1， [value],t醒s #1"
7如果B打開了自動接受，則資金從A的帳戶自動地轉帳到B的無卡合 并帳戶。沒有發(fā)送消息。
8如果B關閉了自動接受，則劃出和劃入交易只有在B批準交易之后才 進行。
9如果在A啟動交易之后已經(jīng)過去30天以上而B還沒有批準，則交易 自動取消。然后，將給A和B發(fā)送消息 "支付已取消。 [tel #，[value]， [trans #]，， 如果B拒絕接收支付，則交易取消，給A發(fā)送一則消息 "支^H皮拒纟色，[tel #]， [valuej， [trans
10如果B接受交易，則資金從A的個人帳戶轉帳到B的個人帳戶。， [value，[trans #1" B不會接收到消息。
如果有足夠的資金，則進入下一步驟。
4檢查B是注冊的用戶還是未注冊的用戶。如果B的移動電話號碼沒有 被識別為注冊的用戶，貝'j A接收到下列消息 "B不是會員。我們已經(jīng)邀請B加入系統(tǒng)。 [tel #，[value], [trans #1" 不會從A的帳戶中扣除資金。
5B接收到下列消息 "A嘗試給您匯款。 [tel #1， [value], [trans #J 請去系統(tǒng)網(wǎng)站注冊。"
6B向系統(tǒng)網(wǎng)站進行了注冊，并成為已注冊的無卡用戶。
7A還接收到下列消息 "B現(xiàn)在是注冊的用戶，您愿意再次提交您的交易嗎？"
8A在他的帳戶中收到引薦獎金(例如，$5)。
9A利用B的移動電話號碼向移動支付系統(tǒng)重新發(fā)送一則消息和交易金 額。如果是，則交易將作為注冊的用戶與注冊的用戶的交易來進行處理。上面所提供的備注也相應地適用于流程H。在此流程中， 在B進行注冊之后資金不會自動地從A轉帳到B。相反地，B被
83邀請加入，在B加入時，給A發(fā)送一則消息(步驟9)，詢問A是 否希望再次嘗試向B匯款。如果A希望匯款，那么，后續(xù)的A與 B之間的處理與任何一個注冊的用戶到注冊的用戶之間轉帳類似。在一種實現(xiàn)方式中，第二帳戶位于合并帳戶中，并且當所
述第一用戶是無卡已注冊的用戶時，所述第 一帳戶位于所述合并帳戶
中，以及所述劃出和劃入過程包括在所述合并帳戶內維護所述金額。
在一種實現(xiàn)方式中，第二帳戶位于合并帳戶中，并且當所述第一用戶
是無卡已注冊的用戶時，所述第一帳戶位于所述合并帳戶中，以及所
述劃出和劃入過程包括不在所述合并帳戶外部轉移所述金額。在一種
實現(xiàn)方式中，當所述第一用戶是無卡已注冊的用戶時，所述第一帳戶
位于第一合并帳戶中，第二帳戶位于不同于所述第一合并帳戶的第二
合并帳戶中，以及所述劃出和劃入過程包括從所述第一合并帳戶向所 述第二合并帳戶轉移所述金額。在一種實現(xiàn)方式中，在收到序列號之后，生成預期的序列 號。然后，只有在所述序列號匹配所述預期的序列號的情況下才處理 所述付款指示。在一種實現(xiàn)方式中，該方法包括當所述第二用戶選擇所 述第三選項時，向所述第一用戶發(fā)送第三電子消息，說明所述第二用 戶請求對所述待付款進行更改。在一種實現(xiàn)方式中，該方法包括當 所述第二用戶選擇所述第三選項時，接收來自所述第二用戶將待付款 更改為不同的金額的請求，向所述第一用戶發(fā)送第三電子消息，通知所述第 一用戶對所述待辦支付款項進行更改，給所述第 一用戶呈現(xiàn)接 受所述對所述待付款的更改的第四選項或拒絕對所述待付款的更改 的第五選項，以及當所述第一用戶選擇所述第四選項時，從所述第 一用戶的帳戶中劃出所述所述不同的金額并向與所述第二用戶關聯(lián) 的帳戶劃入所述不同的金額。該方法還可以進一步包括在確定所述第二用戶不是已注 冊的用戶之后，在所述第一帳戶中預留出所述金額。該方法可以包括 在確定所述第二用戶不是已注冊的用戶之后，在所述第一帳戶中預留 出所述金額；以及，在從接收到付款指示而所述第二用戶仍沒有注冊 時起一定天數(shù)過去之后，取消所述第一帳戶中的所述金額的預留。圖19顯示了本發(fā)明的特定實施例的完整的系統(tǒng)圖形。這 是移動支付系統(tǒng)(即，Obopay)的特定實現(xiàn)方式的示意圖。如前所述， Obopay只作為示例，用于說明本發(fā)明的功能，本發(fā)明不應該僅限于 此示例。Obopay的系統(tǒng)具有借記卡主干網(wǎng)。Diamond Financial Products是合作伙伴。通過Diamond, Obopay發(fā)放借記卡并與 ECL和First Premiere Bank進行通信，以給予Obopay用戶在借 記卡之間轉帳和接收資金的能力。PBT( Pay By Touch )處理ACH交 易和信用卡交易。Bancorp Bank提供結算帳戶，并與PBT有關系。具體流程包括(1) Ul從電話中啟動向"無卡"用戶Ol 的$5的P2P交易。(2)金額$5.00被從Ul的借記卡帳戶轉帳到 位于First Premier的Obopay In & Out銀行帳戶。(3) $0.10的費 用4皮轉巾艮(通過Diamond)到位于First Premier Bank的Diamond Financial Products #4亍中艮戶。(4) Obopay在Obopay總帳上記錄 Ol的余額增多$5。
付。具體流程包括(l)Ol從電話中啟動向"無卡，，用戶02的$10 的P2P交易。(2)$10仍保留在位于FirstPremier的Obopay In & Out帳戶中。$0.10的費用也停留在In & Out帳戶中。(3) Obopay 在Obopay總帳中記錄了 02的余額增多，Ol的余額縮小。閉環(huán)支付方案在一個實施例中，本發(fā)明提供了用于操作作為閉環(huán)支付系 統(tǒng)的支付轉帳基礎架構的方法。閉環(huán)金融交易系統(tǒng)便于進行支付，沒 有與閉環(huán)金融系統(tǒng)關聯(lián)的大量的付款手續(xù)費，并且對于參與金融交易 的持有人、商家及其他各方來說，具有高度的安全性。閉環(huán)支付系統(tǒng)有多個優(yōu)點。主要優(yōu)點是，系統(tǒng)的所有者能 夠控制向匯款人和收款人收取的費用，對于加載到系統(tǒng)中的資金，有 賺取利息的機會。支付系統(tǒng)所有者能夠賺取系統(tǒng)中的所有資金的利 息，直到它們被轉換回美元或卸栽回美元。隨著更多功能被添加，由 于費用和余額的增多，閉環(huán)系統(tǒng)會變得更有利可圖。(3)信息一易于獲取帳戶活動和余額信息；商家合作伙伴具有極難得的機會賺取處理針對將資金存放 到預存款貨記帳戶中的交易或用于向帳戶持有人提供現(xiàn)金的交易的 收入。當資金被添加到帳戶中時，商家可以賺取傭金。閉環(huán)系統(tǒng)維護了用戶資料數(shù)據(jù)庫，包括帳戶持有人的姓名 和人口統(tǒng)計數(shù)據(jù)，每一個特定帳戶持有人的用于對風險進行簽名的信 息，以及將用于向帳戶中加載或從帳戶中卸載資金的帳戶的鏈接的銀 行帳戶信息。用戶資料數(shù)據(jù)庫也需要面向消費者和面向顧客服務的網(wǎng) 站，用于當開立時收集注冊數(shù)據(jù)?，F(xiàn)在請參看圖36，該圖顯示了根據(jù)本發(fā)明的實施例的閉環(huán) 金融交易系統(tǒng)。在此交易系統(tǒng)中，消費者和商家， 一組兩個或更多消 費者，或者一組兩個或更多商家可以快速地，安全地完成金融交易， 交易費用很少或沒有。
459此閉環(huán)金融交易系統(tǒng)利用預存款貨記帳戶，因此，可以包 括銷售點(POS)終端3612,其中，可以如在現(xiàn)有技術系統(tǒng)中那樣使 用傳統(tǒng)的借記卡3606 —通過在與POS終端3612關聯(lián)的i茲性讀 取器3613中刷卡?？?606提供了查看帳戶持有人的帳戶的第二途 徑。在某些實施例中，POS終端3612進一步包括近場(NF) 天線和電路3614。 NF天線和電路3614檢測諸如支持NF的手機、 支持藍牙的手機之類的無源裝置，或與手機3618關聯(lián)的諸如RFID 或條形碼之類的其他近距離傳輸設備。如此，當手機3618位于POS終端的附近時，帳戶信息被自動地傳輸?shù)絇OS終端。在其他實施例 中，POS終端3612包括在交易啟動時建立與交易處理器3630 (也 被稱為支付服務器或服務器)的連接的手機連接。應該理解，交易處 理器3630包括一個或多個服務器場或數(shù)據(jù)中心，它們能夠處理大量 的同時的交易。如當前技術很好地理解的，這樣的服務器場通常在地 理位置上是分散的，并采用適當?shù)募夹g，鏈接在一起，以維護所有帳 戶的實時狀態(tài)的準確的視圖。POS終端將交易金額直接從POS終 端轉帳到支付服務器，以便通過手機連接3615進行授權。支付服務 器3630呼叫帳戶持有人的手機3619，以便確認交易細節(jié)。本領域 技術人員將認識到，POS終端可以只包括》茲性讀取器3613、 NF天 線和電路3614，以及手才幾3615中的一個或兩個。還要理解，POS終 端3612通常與商家關聯(lián)。除消費者與商家之間的交易之外，本發(fā)明足夠靈活，可以 實現(xiàn)真正的個人之間的金融交易功能。個人之間的設備3620各自都 包括鏈接到帳戶和帳戶持有人的手機。當對等伙伴3620中的一個希 望啟動交易請求，以便向另一個對等伙伴進行支付時，交易的請求、 授權和確認都是通過公共網(wǎng)絡在支付服務器3630和對等伙伴3620 之間發(fā)送的。優(yōu)選情況下，由于使用了一個或多個公共網(wǎng)絡，沒有了 交換中心的費用，如此，對于參與者來說，成本可以免費的，或者相 當便宜，以至于它占在系統(tǒng)上進行的總體交易的百分比可忽略，特別 是與典型的交易費用相比時。圖39顯示了如圖36所示的閉環(huán)支付系統(tǒng)中的交易流 程。具體來說，對于個人之間的交易，當從移動設備3901向另一個 移動設備3901進行支付時，向支付服務器3903傳輸轉帳請求。請 求通過引用箭頭3904來表示。服務器3903訪問與移動設備3901 關聯(lián)的帳戶持有人的T-總帳(如引用箭頭3905所示)，如果滿足 了如3906處所示的某些速度規(guī)則，則將指定的金額轉帳到收款人 T-總帳(如引用箭頭3907所示)。 一旦資金已經(jīng)轉帳到收款人，如 3908所示，服務器3903就向收款人發(fā)送一則通知消息，如3卯9所 顯示的。最后，付款人帳戶持有人從服務器3卯3接收到確認消息， 說明交易已經(jīng)完成。在一個實施例中，整個閉環(huán)系統(tǒng)由單一實體所擁 有。系統(tǒng)由帳戶持有人裝填或加栽，帳戶持有人由于在支付服務器上 維護的帳戶余額，而獲得美元(參見圖36)。6.MSPS信托帳戶產(chǎn)生浮動紅利，該紅利為MSPS處理公 司和系統(tǒng)提供補償。9.MSPS系統(tǒng)為消費者和商家管理了"T"帳戶(即，余額、 劃出、劃入)。在一個實施例中，本發(fā)明是包括下列步驟的方法接收多 個商家分擔款項以為會員支付系統(tǒng)提供資金；將商家分擔款項放入合 并信托帳戶中，其中，商家對他們的分擔款項不收利息；允許多個消 費者免費成為移動支付系統(tǒng)的注冊的用戶；允許注冊的用戶免費向會 員支付系統(tǒng)的往來帳戶加載資金或從中卸載資金；以及，允許商家免 費向會員支付系統(tǒng)的往來帳戶加載資金或從其中卸載資金，從而，用 合并信托帳戶的利息為會員支付系統(tǒng)提供資金。—般而言，在商家是會員支付系統(tǒng)的參與者的情況下，不 向該商家收取定期經(jīng)常性交易費用。系統(tǒng)是由包含商家分擔款項的合 并信托帳戶的浮動收益資助的。
515注冊的用戶能通過自動票據(jù)交換所(ACH)或直接儲蓄帳 戶(DDA)中的至少一個來加載或卸載資金。在系統(tǒng)的進一步的實現(xiàn) 方式中，可以給注冊的用戶和商家提供很多額外的加載和卸載資金的 方式。例如，注冊的用戶可以選擇讓用戶的工資支票或工資支票的一 部分直接存放到系統(tǒng)中。(1)由合作銀行獲取的帳戶將被認為是來自該銀行。例如， 如果銀行Ci銷售移動支付系統(tǒng)服務，并吸收客戶A，那么，客戶A 在他的一生中都被標記為"由Ci吸收"。為每一個用戶記錄(在本 申請中別處進行了討論)，可以有一個字段，指出該特定用戶是從哪 一個來源招收的。可能的來源的某些示例包括直接的移動支付服務、 合作銀行、合作金融機構，以及合作移動電話提供商。在每天結束時，移動支付系統(tǒng)服務將估計保留在移動支付 系統(tǒng)服務帳戶中的被標記為由每一個合作銀行吸收的資金的金額。讓 我們將此估計金額叫做X-Ci、 X-BA、 X-ING，其中，Ci、 BA和ING 是金融機構或銀行的示例。在一個實施例中，本發(fā)明是包括下列步驟的方法處理系 統(tǒng)的一組用戶的金融交易，其中，金融交易可以通過移動電話指定， 用戶的子組與金融機構關聯(lián)；
處理與第一金融機構關聯(lián)的金融交易，其中，第一子組中的用戶 與第一金融機構關聯(lián)；處理與第二金融機構關聯(lián)的金融交易，其中， 第二子組中的用戶與所述第二金融機構關聯(lián)；處理第三子組中的與所 述系統(tǒng)關聯(lián)而不與所述第一和第二金融機構關聯(lián)的用戶的金融交易； 維護包括與所述第一、第二金融機構和所述系統(tǒng)關聯(lián)的所述第一、第 二以及第三子組用戶的資金的虛擬合并帳戶；以及，基于所述第一子 組用戶的所述虛擬合并帳戶中的資金的浮動收益，加所迷第三子組用 戶的所述虛擬合并帳戶中的資金的浮動收益的百分比，向所述第一金 融機構分發(fā)第一紅利。圖46顯示了根據(jù)本發(fā)明的實施例的快速購物的方法。在 一個實施例中，招貼畫、報紙廣告、或電視廣告包括允許購物者獲取 顯示在手機上的有關產(chǎn)品的具體細節(jié)的機制。此機制可以包括打印的 條形碼或撥入即可獲取信息的電話號碼。在另一個實施例中，利用近 場通信來啟動購物者和遠程商家之間的連接，如4601所示。通過啟 動該連接，會激活MCA，以便如果購物者決定進行購物，則MCA被 喚醒，并已經(jīng)建立連接，如4602所示。通過選定Buy Request選 項，如4603所示，購物者可以與支付服務器進行購物交易，處理諸 如"發(fā)貨給，，地址和資金轉帳之類的細節(jié)。在較短時間內，可以從幾分 鐘到幾天，訂購的產(chǎn)品將被發(fā)出，如4604所示。如果預先授權的帳戶已用完，而帳戶持有人沒有及時地補 充該帳戶，則電話號碼可以放在"紅名單"中，并禁止未來使用該服務。 紅名單也可以由商家本地存儲在POS中，或存儲在連接到POS設 備的本地服務器中。如果電話號碼包括在紅名單中，則商家可以接受 替代的支付形式?；蛘?，服務器可以拒絕服務，并發(fā)送一則消息，建 議帳戶持有人借此機會對帳戶持有人的帳戶進行再充值。商家可以接 受再充值支付，并收取收到對帳戶持有人的帳戶進行再充值的資金的 獎勵費用。如果收款人4808是帳戶持有人，但是手機不支持在手機 上下栽和執(zhí)行移動客戶端應用程序，那么，來自服務器4804的消息 將是明語。使用明語SMS消息傳輸PIN的不利的一面是，此秘密 的號碼將對可以接觸電話的任何人可見。這可能導致非帳戶持有人的 未經(jīng)授權的使用，除非帳戶持有人花點時間從他們的手機的郵箱中刪 除SMS消息。如果收款人4808不是帳戶持有人，那么，SMS消 息也將是明語消息。要4吏用SMS方法向他人或商家進行支付，帳戶持有人可 以輸入表C所顯示的命令字符串。在服務器端， 一個或多個數(shù)據(jù)中心將具有用于處理金融交 易的系統(tǒng)。每一個數(shù)據(jù)中心都將包含PBX/ACD/VRU技術的組合， 以允許多個同時的呼叫處理?？梢允褂肰RU技術來提供可編程入站 和出站DTMF支持。VRU可以連接到表示實際業(yè)務邏輯的企業(yè) J2EE系統(tǒng)和記錄金融交易的記錄系統(tǒng)。然后，J2EE系統(tǒng)可以與用 于進行交易結算的實際銀行集成。
575優(yōu)選情況下，移動客戶端應用程序確定用于發(fā)送PIN的首 選的或最佳的方法，如通過應用程序SMS(數(shù)據(jù)服務)，其中，SMS 消息是經(jīng)過加密的，并被轉換為二進制(即，消息不以明語進行傳輸)， 或者，通過音頻信道使用DTMF來維護安全性。在其他實施例中， PIN可以由帳戶持有人說出，并由在服務器或專用于處理語音電話的 另 一個服務器(未顯示)上工作的交互式語音識別軟件模塊進行轉換。
576在一個備選實施例中，PIN由移動客戶端應用程序進行加 密，并包括在發(fā)送給服務器4804的后續(xù)的SMS消息中。服務器4804通過將電話號碼和每一則消息的發(fā)送時間匹配來使消息關聯(lián)。 如果PIN是在與SMS消息相比在時間上較遠的消息中發(fā)送的，則 可以拒絕交易。如果只接收了兩個消息中的一個，則可以拒絕交易。 然而，如果及時地接收并驗證了帶有金融交易細節(jié)的SMS消息(至 少有關鍵字)和PIN代碼，那么，進行金融交易。在又一個備選實施例中，移動客戶端應用程序在移動設備 的顯示屏幕上提供用戶界面(UI)，引導帳戶持有人進行金融交易。在 此實施例中，通過自動插入關鍵字、金額、目標電話號碼、密碼，以 及消息(如果有的話)，來引導帳戶持有人完成構建SMS文本消息 的過程。圖49顯示了根據(jù)本發(fā)明的實施例的用于保護基于SMS 的金融交易的方法。更具體地說，對于諸如GSM手機之類的移動設 備，在手機上安裝MCA涉及以物理方式插入小型電路板，被稱為加 密和交易號生成器，或簡稱為生成器4902,以截取SMS消息通信?！┻M行了注冊，新帳戶持有人具有"無卡，，受限制的帳戶， 如5103所示。在此階段(階段I),新帳戶持有人能夠實時地查看他們的預存款貨記帳戶中的資金。然而，由于銀行規(guī)則，新帳戶持有
人的帳戶的對資金的訪問權限是受限制的，直到完成OFAC報告， 如5104所示。"OFAC"是指美國財政部的外國資產(chǎn)控制局，該局根 據(jù)美國外交政策和國家安全目標，針對指定的外國、恐怖分子、未經(jīng) 批準的國際毒品走私犯，以及那些參與與未經(jīng)批準的大規(guī)模殺傷性武 器的擴散相關的活動的人，進行管理和實施經(jīng)濟和貿易制裁?！㎡FAC適應性檢查完成(該過程通常大約要花24小 時)，并沒有發(fā)現(xiàn)不利的鏈接，帳戶持有人會變?yōu)?無卡"帳戶，這意 味著，金融機構可以開立預存款借記卡賬戶，并將塑料借記卡發(fā)送給 新帳戶持有人，如5105所示。然而，在此階段(階段II)，新的無 卡帳戶持有人對資金只有有限的支配權。例如，新帳戶持有人可以使 用本發(fā)明的金融交易系統(tǒng)將資金轉帳到其他個人，但是由于額外的政 府限制，資金不能被提取或轉帳到一個商家。帳戶持有人也可以指定每一次交易的最高金額，以及在選 定時間段內在手機上可以處理的交易的數(shù)量。帳戶持有人也可以指定 要存放和保留在預存款貨記帳戶中的資金的最高金額。交易處理器 3630每天將多余的款轉移到另一個指定的帳戶，如個人儲蓄帳戶。在一個實施例中，使用近場通信來在移動設備之間進行通 信以使用本發(fā)明的基礎架構進行金融交易。在再一個實施例中，使用 近場通信在移動設備與POS終端之間進行通信，以進行金融交易。如果使用SMS消息來完成交易，則授權PIN優(yōu)選情況下 是朗讀到移動設備中并傳輸?shù)街Ц斗掌鞯目陬^代碼，以便使用語音 識別軟件進行驗證。通過使用PIN代碼激活移動客戶端應用程序，來提供更大 的安全性。在此實施例中，PIN代碼出現(xiàn)在第一個實例中，打開移動 客戶端應用程序，并啟動其操作。同一個PIN代碼，或者，優(yōu)選情 況下， 一個單獨的PIN代碼用于通過網(wǎng)絡對交易進行授權。這種雙PIN代碼處理對信用卡、支票或者智能卡不可用。在5510，用戶(即，帳戶持有人)在移動電話設備(例如， 移動電話)上啟動金融交易。在5511，用戶在啟動交易時傳輸PIN (選項A)?；蛘?，如在5512所顯示的，用戶在啟動交易時不傳輸 PIN (選項B )。—旦驗證了呼叫方ID，則服務器對照系統(tǒng)中記錄的PIN 檢查從移動設備傳輸?shù)腜IN，以驗證PIN是否匹配預期的電話號 碼，如5517處所顯示的。當且僅當PIN匹配時，服務器才允許進行交易。如果PIN不匹配，則禁止交易，如5518處所顯示的。然后，服務器從移動設備接收金融交易的交易號(也簡稱 為序列號)。交易號可以在啟動交易時發(fā)送，或以后作為移動設備和 服務器之間的信息傳輸?shù)囊徊糠职l(fā)送。交易號包括使其唯一的冪等性 密鑰。上面的驗證方法按特定的順序呈現(xiàn)一些驗證步驟。本發(fā)明 的一種實現(xiàn)方式按給定順序執(zhí)行這些步驟。然而，在本發(fā)明的其他實 現(xiàn)方式中，可以有其他步驟，或者也可以省略一些步驟，或者步驟的 順序可以不同于上面的順序。例如，呼叫方ID、 PIN，以及交易可以 不按順序。因此，在一個實施例中，可以在呼叫方ID之前檢查PIN。 在另一個實施例中，可以在PIN之前檢查交易號。此外，上面的一 些步驟還可以以并行處理的實現(xiàn)方式在不同的處理器或處理器核心 中同時執(zhí)行。在一種實現(xiàn)方式中，本發(fā)明的系統(tǒng)可以省略上面所列的一 個或多個驗證技術。例如，可以不鑒定呼叫方ID，如此，將4吏用兩 因素驗證方法。(3)在服務器上，從移動設備接收啟動金融交易的請求。 [649](4)在服務器上，檢查由移動設備傳輸?shù)暮艚姓邩俗R(呼叫 方ID)，看看移動設備是否是系統(tǒng)的被授權的用戶。如果在電話上 沒有啟用呼叫方ID，則禁止交易?？梢燥@示一個錯誤消息，以指出 交易^皮禁止，因為呼叫方ID未啟用。用戶可以在啟用呼叫方ID之 后重試請求。(8a)(選項C)對照服務器中存儲的序列號，檢查來自移 動設備的序列號。如果序列號不匹配，則用戶沒有通過鑒定，交易將 被禁止0(8b)(選項D)對照存儲在服務器中的以前所使用的序列 號的列表或數(shù)據(jù)庫，檢查來自移動設備的當前序列號。如果當前序列 號匹配以前使用的序列號中的任何一個，則用戶沒有通過鑒定，交易 將被禁止。(1)在服務初始化時，使用存儲在移動設備和服務器上的初 始交易號值。初始交易號可以是(la)或(lb)。例如，當<吏用即時消息程序(例如，AOL Instant Messenger (AIM)、 ICQ、 Yahoo! Messenger、 Microsoft Windows Live Messenger、 Google Talk或Skype)時，將會有一個向另一個用戶進行支付的選 項。進行支付的選項可以通過右鍵單擊鼠標或通過下拉式或層疊式菜 單進行訪問。接收者可以通過用戶名、會員名、電話號碼、會員號、 帳號，或另一個標識符來進行標識。支付將通過移動支付服務服務器 進行處理。在本發(fā)明的特定實現(xiàn)方式中，當使用胖客戶端時，存儲的 序列號將永久地存儲在胖客戶端中的計數(shù)器中。此存儲的序列號可以 遵循任何任意序列，如連續(xù)的整數(shù)或二進制計數(shù)器(例如，1、 2、 3、 4，等等)，基于已知起始種子值的隨機序列，或根據(jù)等式、公式或 規(guī)則的序列。存儲的序列號可以存儲在，例如，快閃存儲器、電可擦 除的(E")存儲器、非易失性存儲器、帶蓄電池后備電源的存儲器、 硬盤驅動器，或其他存儲器中。在特定實現(xiàn)方式中，可以用潛在的違反安全記號來標記用 戶的帳戶，以供人研究。如果用戶具有許多這樣的違規(guī)或在特定時間 段內具有許多這樣的違規(guī)，那么，可以自動地暫停該帳戶，以便進行 調查。當使用不同類型的客戶端或程序時，可以以不同的方式生 成或獲得傳輸?shù)拿荑€，如通過不同的函數(shù)。例如，密鑰可以包括不同 的信息。當用戶設備使用第一應用程序客戶端發(fā)送電子請求時，密鑰 可以包括第一信息，當用戶設備使用不同于第一應用程序客戶端的第 二應用程序客戶端發(fā)送電子請求時，傳輸密鑰可以包括第二信息。第 一信息的示例可以是包括永久地存儲的序列號的密鑰。第二信息的示 例可以是包括時間或時間戳的密鑰。在 一 個實施例中，本發(fā)明包括接收從用戶設備以無線方式 傳輸?shù)膬r值交換交易的電子請求；接收與電子請求關聯(lián)的傳輸?shù)拿?鑰；生成預期的密鑰；將傳輸?shù)拿荑€與預期的密鑰進行比較；以及， 如果傳輸?shù)拿荑€匹配預期的密鑰，則處理價值交換交易。價值交換交 易可以是從與用戶設備關聯(lián)的第 一用戶向與另 一個用戶設備關聯(lián)的 第二用戶匯款，其中，用戶設備是移動電話。生成預期的密鑰的過程可以包括使用為與價值交換交易關 聯(lián)的用戶帳戶存儲的種子值對一個函數(shù)或方程進行求值。此外，用戶 帳戶也可以存儲有關用來生成預期的密鑰的特定函數(shù)或方程的信息。 例如， 一些用戶可以使用一個特定函數(shù)來生成密鑰，而其他用戶使用 其他函數(shù)。對于不同的用戶，使用不同的起始種子，在每一次使用之 后，將創(chuàng)建新的種子，用于生成下一個密鑰。換句話說，該方法進一 步包括在對函數(shù)進行求值之后，確定序列中的下一個種子值，并用序 列中的下一個種子值替換為用戶帳戶存儲的種子值。在示例情況下，用戶具有配備有近場通信功能的移動設備。 用戶可以查看他希望購買的產(chǎn)品。用戶將用戶的移動設備放在與產(chǎn)品 關聯(lián)的近場通信設備的附近。然后，移動設備的顯示器查詢用戶是否 同意交易，以購買產(chǎn)品。如果用戶批準，則處理交易。用戶將接收商 品，如從交貨地點領取，或者商品可以投遞到用戶的郵件地址處?？?以提示用戶輸入PIN或質詢問題，以驗證他們已經(jīng)批準交易。(1)打開帳戶持有人的移動設備上的MCA。這將把帳戶持 有人帶到開始屏幕，顯示徽標和標記行。然后，帳戶持有人按"輸入，， 繼續(xù)。這將把帳戶持有人帶到主菜單畫面，顯示MCA的功能的菜單， 包括支付、余額、歷史、請求支付、引薦或邀請、添加資金(即，加 載)，設置，和幫助。(3)要選擇帳戶持有人的電話簿中的電話號碼，帳戶持有人 將選擇選項(從移動設備上的左下方的軟鍵)，然后查找(從選項菜 單)，將顯示出帳戶持有人的現(xiàn)有電話地址簿，并允許他們選擇其中 的一個姓名?？蛇x地，帳戶持有人可以直接從小鍵盤輸入電話號碼。 在另 一 個實施例中，帳戶持有人輸入短代碼來標識所需的商家收款 人。 一旦帳戶持有人輸入了移動電話號碼，他們將選擇"確定"。支付到(目標電話號碼)任何相關交易費用消息(如果他們留了的話)消息如果目標收款人還沒有現(xiàn)有帳戶，則收款人將接收到文本 消息，說"您收到一筆款！，，，并指示他們到諸如www.obopay.com之 類的網(wǎng)站，進行注冊，成為帳戶持有人，并接收他們的資金。在本文 檔中稍后詳細描述了新帳戶持有人的注冊過程。將首先處理支付，收款人將接收到支付通知。如果交易沒 有問題，則帳戶持有人將不會接收到任何進一步的通知。如果支付確 實出現(xiàn)問題的話(即，資金不足)，則將會通知帳戶持有人和目標收 款人。有關支付所發(fā)生的任何問題的通知將在進行支付之后迅速地發(fā) 出，以便各方都可以確認交易。日期MM/DD/YYYY HH:MM(1)打開帳戶持有人的移動設備上的MCA。這將把帳戶持
有人帶到開始屏幕，顯示徽標和標記行。然后，帳戶持有人按Enter
鍵繼續(xù)。交易日期和交易金額MM/DD (+/-)$.$$
7671帳戶持有人將能夠選擇列出的交易中的任何一 個，以獲得 有關該特定交易的詳細信息。為此，他們滾動瀏覽到他們希望查看的 具體交易，并選定它。這將把他們帶到具有下列信息的屏幕然后，帳戶持有人選定"確定，，回到歷史屏幕。從這里，他 們可以查看另一個交易或返回到主菜單畫面。金額任何相關交易費用消息(如果他們留了的話) —旦帳戶持有人選擇了 "確定"，則他們將被帶到具有下列 信息的屏幕帳戶持有人將能夠從MCA查看"幫助"屏幕。這將包括應 用程序的簡要的描述，以及有關帳戶持有人到哪里獲得更多幫助的說 明。要查看MCA的"幫助，，部分，帳戶持有人將經(jīng)過下列步驟。打開 帳戶持有人的移動設備上的MCA。這將把帳戶持有人帶到開始屏幕， 顯示徽標和標記行。帳戶持有人將必須按Enter鍵繼續(xù)。請求支付，顯示，例如成本？如杲您忘記了，請撥打888-80BOPAY [857鏈接到"技術支持"的幫助頁面下面顯示了來自移動設備的服務請求和示例有線表示。 [868]由移動設備啟動的服務請求是Paymentservice.payP2P調 用。此函數(shù)執(zhí)行帳戶持有人與帳戶持有人之間的支付，Java方法簽 名是請求部分與前一示例完全相同，雖，響應現(xiàn)在表示由于服 務電話而引發(fā)異常。對象類型6表示類型五^T5wwVie^五A:c印"Vm 的返回值，在圖61中說明了其屬性。 String pin) throws Exception; String transactionAmount， Boolean tipRequest,
8941 String memoText) throws Exception;/mj;i ^rMW戶aj;函數(shù)用于對r^r^WiV);調用進行響應，此 調用批準請求的支付。[896publicPayRequestSummary payRequestPay(為與處理設備啟動的調用的MCA和平臺體系結構一致， 本發(fā)明在設備上作為"設備服務"實現(xiàn)了這樣的通知的處理程序，與當 從服務器端調用這些"設備服務，，上的方法時，有相同的ServiceProxy 簽名。編解碼器和有線協(xié)議與由設備啟動的那些請求完全相同。這里 是當前可用的"設備服務"和它們的方法的列表現(xiàn)在討論了 MCA &平臺(MCAP)的高水平的設計，以 及用戶界面(UI),呈現(xiàn)了 MCAP預期的并且是所需的完整的一套 移動功能。MCAP基本上是"移動錢包"或"通過電話支付"的消費者/ 移動-商家應用程序。MCAP的用戶界面簡單，它只需要一步接一步 地輸入請求數(shù)據(jù)(如金額、PIN，等等)，然后顯示響應數(shù)據(jù)。通過 例圖和比較，MCAP的用戶界面不需要移動游戲應用程序的圖形復 雜性。優(yōu)選情況下，MCAP是模塊化的，以便它在J2ME上輕 -松地實現(xiàn)，并在.NET以及J2ME、 BREW、 Symbian，以及.NET CF (以前的Windows Mobile)上證明圖63顯示了移動設備的高水平OMAP設計層。圖64是顯示了使用單一文本字符串(帶有分隔參數(shù)/值對) 的OMAP通信^沒計和請求/響應編碼方案的流程圖。圖69顯示了從來源角度來看的OMAP支付屏幕流程。
在本發(fā)明的其他實施例中，"支付資金"功能可以叫做"匯款"。圖72顯示了從目標-接受角度來看的OMAP接受支付 屏幕流程。圖73顯示了其中目標拒絕請求的OMAP請求支付屏幕流程。圖75顯示了其中源和目標兩者都拒絕請求的OMAP請 求支付屏幕流程。圖77顯示了 OMAP歷史屏幕流程。有一個聯(lián)系人菜單，用戶可以保存聯(lián)系人，并從其中選擇 要支付或請求支付的聯(lián)系人。有一個消息或便箋字段，用戶可以與發(fā) 出支付或支付請求一起輸入消息。例如，用戶可以告訴目標，"資金4， 午餐"。有一個讓用戶可以輸入用戶的PIN的屏幕。PIN將不會顯 示，而是將顯示星號，空白，或另一個字符?？梢杂幸粋€屏幕，列出 全部交易，并給予用戶在匯款之前確認交易的機會。如果有錯誤，當 然，可以在發(fā)送之前對交易進行編輯。應用程序還可以進一步包括幫助或簡要用戶指南，以協(xié)助 用戶并回答用戶的有關系統(tǒng)的使用的問題。金融服務API為此服務定義的應用程序編程接口 (API)有 [952]/mj，戶2尸-在兩個消費者會員之間執(zhí)行帳戶持有人與帳戶持
有人(p2p)之間的交易r^Weve好/Woo;-檢索指定的帳戶的最后五個交易記錄，包
括顯示了可用余額的第六行/m^i qweW戶flj;—由兩部分組成的交互的第二步驟，支付 請求的收款人要么付款或者拒絕付款String srcDevKey,String srcPin，throws ExceptiontransactionAmount 字符串值，向接收方帳戶進行支付的金額。返回類型對象public BalanceSummary retrieveBalance (throws Exception輸入?yún)?shù)devKey字符串值，通常是正在請求其佘額的帳戶的電話
號碼BalanceSummary 包括可用余額數(shù)據(jù)的容器對象。有關詳 細信息，參見BalanceSummarv類描述。 [986方法簽名retrieveHistory此方法支持從移動設備呼叫，以檢索會員的五個最近的交 易，并在其歷史顯示中包括當前帳戶余額。結果被發(fā)送到調用的會員 的移動電話。reirieveHistory ( [989] String devKey， [990String pin)[991throws Exception [992輸入?yún)?shù) String paymentAmount， String transactionRef，tgtDevKey 字符串值，要么是接收支付的帳戶的電話號碼，要么是用于向與接收支付的帳戶關聯(lián)的設備標識JNDI連接鍵的 引用鍵 tipAmount 字符串值，要添加到交易總和中的小費支付
金額返回類型對象 String srcDevKey， tipRequest 布爾值，指出是否向請求收款人呈現(xiàn)小費請
求屏幕。返回類型對象此方法persists設備號為帳戶數(shù)據(jù)記錄。如果有更多信息 可用，諸如會員名，那么，該方法還將persist補充信息。根據(jù)需要， 在數(shù)據(jù)對象之間進行引用。該方法返回指出了帳戶的注冊狀態(tài)的容器 對象。
10541 public ArrayList addRegistrationInfo( [1055J ArrayList regContainerList， [1056String緒ame) [1057throws Thiwable [1058輸入?yún)?shù)轉帳對象 status 字符串值，指出是否在服務執(zhí)行過程中發(fā)生了錯
誤
1=好，0=錯誤 transactionType 字符串值，指出交易類型P2P、 POS、 ATM、 IX)AD、 BAL屬性此異常表示可以呈現(xiàn)給客戶端應用程序的錯誤。異常對 象中包含的錯誤消息不是顯示給帳戶持有人的消息。返回到帳戶持有 人的錯誤消息是帳戶持有人可理解的形式，并且被本地化。在網(wǎng)關中 進行errorCode到錯誤消息的轉換。程序包
1141com.ewp.core.exceptions屬性從父類繼承。 [1145錯誤代碼有時作為 TransactionEvent 事件狀態(tài)代碼和 AuditEvent 事件狀態(tài)代碼出現(xiàn)的錯誤代碼。請參閱 ErrorCodesAndNotifications.doc 了解4晉誤代碼和定義。業(yè)務對象 vw(/3;戶/w -處理對照帳戶驗證pin的請求
1166Method signature: balance Method signature: history public TransactionSummary[]history( String transactionAmount); (1)丟失移動設備并不意味著丟失資金，因為利用在線同 步，帳戶可以關閉，余額可以轉移到新帳戶；以及圖93顯示了 EWP J2ME同步服務調用。同步服務調 用是由諸如完成諸如支付之類的屏幕序列之類的用戶操作而啟動的。 在此情況下，啟動與服務器端的服務的通信的同一個線程還處理返回 值。大多數(shù)移動消費類通信設備例如，蜂窩電話、PDA(個 人數(shù)字助理)、筆記本電腦等等，都包含可移動標識模塊(IM)卡或 芯片，用于向無線通信網(wǎng)絡運營商唯一地標識特定消費者的帳戶。IM 卡/芯片存儲了數(shù)據(jù)，并提供一些"大腦"，可使宿主移動消費類通信設 備運轉，例如，發(fā)出和接收語音電話、發(fā)送或接收消息，運行計算機 應用程序等等。這可使用戶，例如，通過從一個電話中取出IM卡/ 芯片并將卡/芯片重新插入到另一個電話中，輕松地更換蜂窩電話。不 需要通過通信網(wǎng)絡來激活第二個蜂窩電話。但是，不管類型如何，IM以及它們的宿主移動通信設備 一般是"封閉的"，無線通信網(wǎng)絡運營商(例如，Cingular、 T-Mobile、 Verizon等等)、移動消費類通信設備的制造商，以及IM制造商(例 如，Gemplus、 Oerthur等等)專有的系統(tǒng)。盡管如此，通信協(xié)議， IM宿主通信設備，即，移動消費類通信設備，IM之間的接口是通 過由ISO (國際標準化組織)制定的技術標準而開放的。在任何情況下，可編程處理單元9618都與操作系統(tǒng) 10110、事件接口 call-out 10111、后IM處理call-out 10112、應用 程序注冊表10113,以及編程語言和運行時10114 —起操作，如圖 101所示。操作系統(tǒng)促進宿主移動消費類通信設備9500和IM9619 之間的通信，如以前所說明的。操作系統(tǒng)還向在可編程處理單元9618 中注冊和安裝的應用程序提供編程call-out。
〖l208事件接口 call-out 10111提供編程事件接口，這是應用程
序實現(xiàn)的，為了在發(fā)生特定移動設備事件時，例如，按下按鈕，振鈴 信號等等，獲得對宿主移動消費類通信設備的編程控制。在此控制過
程中，應用程序具有對事件添加功能和處理的能力。在接收到DTMF音調的情況下，服務器10212跨無線 通信網(wǎng)絡接合IVR (交互式語音響應)單元10226以對音調進行解 碼。IVR可以發(fā)送和接收DTMF音調(有時叫4故"按鍵音")，在許 多當前的自動電話應答系統(tǒng)中都有。它允許計算^L自動地使用語音識 別、音頻播放、文本到語音轉換(ITS)和DTMF 4支術與人進行交互。IVR "插件"10224是IVR改編的API,用于將數(shù)據(jù)變成服務器 10212中的應用程序10222的正常形式。這允許移動消費類通信設 備10210中的應用程序10221通過音頻信道10211與服務器 10212中的企業(yè)應用程序10222進行通信。數(shù)據(jù)信號在兩個應用程 序10221和10222之間的兩個方向進^f亍傳輸。移動消費類通信i殳備 10210和服務器10212之間的通信是通過音頻信道的客戶端/服務器 之間的通信的示例。另一方面，服務器應用程序10222的操作可以 是簡單地將來自移動消費類通信設備10210的數(shù)據(jù)中繼到另一個移 動消費類通信設備。這是通過音頻信道的對等通信的示例。本發(fā)明的實施例中的API,例如，圖102的API 10223 和10224，基于簡單的"sendRequest()"/processRequest()，，模型，在客 戶端和服務器端都帶有已知的請求/響應數(shù)據(jù)結構。API 10223和 10224是配對的客戶端和服務器API組，移動應用程序和企業(yè)力l務 器開發(fā)人員用它們來構建完整的客戶端/服務器應用程序?？蛻舳?移 動消費類通信設備)和服務器端上的語音數(shù)據(jù)處理軟件(即，庫組件) 對于跨音頻信道的數(shù)據(jù)通信實現(xiàn)了語音數(shù)據(jù)處理算法。當然，這些算 法不同于特定客戶端/服務器應用程序10221和10223。這是移動客戶端應用程序用來向企業(yè)服務器應用程序發(fā) 送請求/數(shù)據(jù)的單一 API接口。字母數(shù)據(jù)元素被分解為單個的字符元素。每一個完整的字母數(shù)據(jù)元素都以"#"代碼結尾。此示例中的命令是由 CommandID 1代表的 payRequest,以及由 CommandID 2代表的payResponse。下面的兩 個表中定義了參數(shù)數(shù)據(jù)結構宿主移動客戶端應用程序與源消費者進行交互，并收 集下列數(shù)據(jù) sourceAccountN腿ber - "123456789"
1272] sourcePIN-'，4321" sourceAccountNumber - "987654321，'由于上下文和配置，宿主移動客戶端應用考呈序"知道" 下列數(shù)據(jù) [1281] ParameterID = 1 [1282] ParameterType = 1[1283ParameterValue = "123456789" ParameterID = 4對上面的編碼示例應用上面的規(guī)則，看到下面的東西 [1308引導"ir，表示"CommandlD 1"，已知是"payRequest，，命
令...對于數(shù)字參數(shù)類型，依次類推然后，客戶端API傳輸全部上面的編碼的DTMF請求。企業(yè)服務器應用程序向IVR插件返回Response結構 和控制。移動客戶端應用程序API使用上文所描述的解碼規(guī)則 將經(jīng)過編碼的DTMF響應數(shù)據(jù)解碼為客戶端Response結構(即， 在此情況下，解碼為Response結構)。 API向宿主客戶端移動應用程序返回Response結構和控制。本發(fā)明的各種特定實施例包括 1. —種移動個體化支付系統(tǒng)，包括用于管理閉環(huán)支付系統(tǒng)的服務器；以及 4.根據(jù)權利要求3所述的系統(tǒng)，進一步包括調用所述編 程性的HTTPSAPI調用的安全性裝置。 8.根據(jù)權利要求7所述的系統(tǒng)，其中，所述合并帳戶表 示多個預存款的借記卡。 9,根據(jù)權利要求8所述的系統(tǒng)，其中，所述預存款借 記卡鏈接到所述合作銀行系統(tǒng)中的支票帳戶。 12.根據(jù)權利要求6所述的系統(tǒng)，其中，所述移動客戶 端應用程序、服務器和所述至少一個另外的移動客戶端應用程序的組 合構成了個人之間的付款轉帳系統(tǒng)。在支持IP的設備上激活客戶端應用程序；將收到付款通知給所述收款人。 [136623.根據(jù)權利要求22所述的方法，進一步包括 [1367如果付款是針對沒有帳戶的號碼，則為收款人建立帳戶；
以及 24.根據(jù)權利要求22所述的方法，進一步包括:通過從合并帳戶向相應的帳戶劃撥資金來對每一個交易
實時進行結算。 26.根據(jù)權利要求22所述的方法，進一步包括 [1375在離線模式下對選定交易進行結算。 30.根據(jù)權利要求29所述的方法，其中，所述記錄過程 包括向記帳程序實時發(fā)送交易的口頭描述。通過第二通信路徑發(fā)送個人標識號(PIN);在支付服務器中將所述請求與PIN相關聯(lián)；以及
l389基于請求和PIN之間的關聯(lián)，進行金融交易。
139034.根據(jù)權利要求33所述的方法，其中，發(fā)送請求的過
程進一步包括通過短消息服務(SMS)發(fā)送命令。 36.根據(jù)權利要求35所述的方法，其中，形成所述命令 的過程進一步包括
1396請求向對等伙伴進行支付。向計帳應用程序發(fā)送所述命令。 41.根據(jù)權利要求39所述的方法，其中，發(fā)送所述命令 的過程進一步包括通過SMS接收帳戶余額消息。44. 4艮據(jù)權利要求33所述的方法，進-一步包括請求帳戶歷史。45.根據(jù)權利要求44所述的方法，進-一步包括請求對等伙伴建立一個帳戶，從該帳戶向請求者進行支 付，所述請求是通過SMS發(fā)送的。 55.根據(jù)權利要求53所述的方法，其中，給出PIN的 清晰發(fā)音，然后由交互式語音識別系統(tǒng)對其進行解碼。顯示用戶界面，以《更形成命令；通過第二通信路徑發(fā)送個人標識號(PIN); 59.根據(jù)權利要求56所述的方法，其中，形成所述命令 的過程進一步包括61.根據(jù)權利要求56所述的方法，其中，形成所述命令
的過程進一-步包括
1447]向所述命令添加消息。62.根據(jù)權利要求61所述的方法，其中，形成所述命令
的過程進一-步包括
1449]向所述命令添力6己錄標t己。64.根據(jù)權利要求62所述的方法，其中，發(fā)送所述命令
的過程進一步包括向增值服務提供商發(fā)送所述命令。通過選定協(xié)議接收帳戶余額消息。請求帳戶歷史。71.根據(jù)權利要求70所述的方法，進一步包括
1467接收支付已經(jīng)被授權或者拒絕的指示，所述指示是通過SMS發(fā)送的。[146872.根據(jù)權利要求71所述的方法，進一步包括 [1469請求對等伙伴建立一個帳戶，從該帳戶向請求者進行支 付，所述請求是通過SMS發(fā)送的。 76. —種移動個體化支付系統(tǒng)，包括 77.根據(jù)權利要求76所述的系統(tǒng)，進一步包括至少一個
另外的移動客戶端應用程序，其中，所述移動客戶端應用程序、服務
器和所述至少一個另外的移動客戶端應用程序的組合構成了具有較
低的交易費用的閉環(huán)支付系統(tǒng)。
147978.根據(jù)權利要求76所述的系統(tǒng)，進一步包括至少一個
另外的移動客戶端應用程序，其中，所述移動客戶端應用程序、服務
器和所述至少一個另外的移動客戶端應用程序的組合構成了沒有交
易費用的閉環(huán)支付系統(tǒng)。選擇產(chǎn)品；激活移動客戶端應用程序以處理金融交易； [1487進行購物；以及 [1488在指定的地址自動地接收選定產(chǎn)品。 [148984， 一種用于進4亍購物的方法，包括 [1490選擇產(chǎn) 品586.根據(jù)權利要求84所述的方法，進一步包括利用與手 機關聯(lián)的近場通信設備來激活交易。 87.根據(jù)權利要求84所述的方法，進一步包括利用與手 機關聯(lián)的RFID設備來激活交易。 88. —種用于進4亍購物的方法，包括通過發(fā)送具有第一標識符的請求來啟動金融交易，所述 請求是使用第 一通信渠道發(fā)送的； 99. —種用于防止從手機輸入的金融交易的欺騙性提交 的方法，包括 101.根據(jù)權利要求99所述的方法，其中，第一通信渠 道是SMS傳輸渠道。
103.才艮據(jù)權利要求102所述的方法，進一步包括 [1541將包含密碼的第二明語消息發(fā)送到交易處理器；[1542截取第二 SMS消息；以及 109.根據(jù)權利要求108所述的系統(tǒng)，其中，能夠通過 編程性的SMS API調用，通過移動設備的SMS文本服務，來利用 移動設備的SMS數(shù)據(jù)服務。
113. 4艮據(jù)權利要求111所述的系統(tǒng)，進一步包括合并
帳戶，其中包括帳戶持有人持有的所有資金，合并帳戶與總帳關聯(lián)，
以管理帳戶持有人之間的資金轉撥。從至少一個帳戶持有人接收劃撥資金的金融交易請求；
以及 117.根據(jù)權利要求116所述的方法，其中，資金被轉 移到至少一個另外的帳戶持有人。將新帳戶持有人指定為"無卡，，帳戶持有人；以及 [1S75]給予無卡帳戶持有人有限的資金接觸權限。1576124.根據(jù)權利要求123所述的方法，進一步包括通過
向記錄地址發(fā)送借記卡來向無卡帳戶持有人發(fā)放借記卡。
125.根據(jù)權利要求124所述的方法，進一步包括 127.根據(jù)權利要求126所述的方法，其中，單個實體
是記錄系統(tǒng)，并承擔維護合并帳戶的風險?？捎晒芾韺嶓w控制的第二層。 132.根據(jù)權利要求128所述的系統(tǒng)，其中，所述第二 層進一步包括用于檢測欺騙性交易的裝置。 話音通信連接；在移動設備上執(zhí)行的用于將編碼響應轉換為用戶界面上 人可讀取的格式的JAVAAPI。本發(fā)明的描述只是為了說明和描述。它不是詳盡的說明 或將本發(fā)明限于所描述的準確的形式，顯然，根據(jù)上文的講述，許多 修改方案和變化也是可以的。所選擇的實施例只是為了最好地說明本 發(fā)明的原理，以及其實際應用。本描述將能使本領域技術人員以各種 實施例最佳地利用和實施本發(fā)明，根據(jù)特定用途進行各種修改。本發(fā) 明的范圍由下面的權利要求進行定義。
權利要求
1. 一種金融交易系統(tǒng)，包括連接到網(wǎng)絡的消費者界面，包括處理來自Web瀏覽器客戶端的交易請求的Web界面；處理來自移動電話客戶端上的移動因特網(wǎng)瀏覽器的交易請求的移動因特網(wǎng)瀏覽器；使用SMS文本消息處理交易請求的SMS界面；以及處理來自在移動電話客戶端上執(zhí)行的移動客戶端應用程序的請求的移動客戶端應用程序界面。
2. 根據(jù)權利要求1所述的系統(tǒng)，其中，消費者界面進一步包括處理來自電話音頻信道的請求的交互式語音響應界面。
3. 根據(jù)權利要求1所述的系統(tǒng)，包括新注冊的用戶的合并帳戶，其中，在注冊之后，新注冊的用戶可 以立即與已注冊的用戶進行交易。
4. 根據(jù)權利要求1所述的系統(tǒng)，其中，所述移動客戶端應用 程序界面允許進行匯款交易、加載帳戶交易、卸載帳戶交易，以及余 額查詢交易。
5. 根據(jù)權利要求1所述的系統(tǒng)，其中，消費者界面進一步包括:處理來自即時消息客戶端的請求的即時消息界面。
6. 根據(jù)權利要求1所述的系統(tǒng)，包括 金融合作伙伴界面；商家界面，其中，用戶能通過消費者界面訪問位于通過所述金融 合作伙伴界面連接到系統(tǒng)的銀行中的資金，并向連接到所述商家界面 的商家轉帳。
7. 根據(jù)權利要求1所述的系統(tǒng)，包括由所述金融交易系統(tǒng)進行管理的記錄系統(tǒng)，記錄通過消費者界面執(zhí)行的交易。
8. 根據(jù)權利要求1所述的系統(tǒng)，包括由所述金融交易系統(tǒng)進行管理的合并帳戶，其中，通過消費者界 面訪問所述系統(tǒng)的多個客戶端在合并帳戶中具有帳戶。
9. 根據(jù)權利要求8所述的系統(tǒng)，其中，多個客戶端在所述合 并帳戶中沒有帳戶，而是在可以訪問所述系統(tǒng)的金融機構中具有帳 戶。
10. —種方法，包括提供與第 一金融合作伙伴進行交易的應用程序界面； 提供接收進行交易的請求的SMS消息界面；以及 提供用于接收進行交易的請求的移動客戶端應用程序界面，其 中，通過SMS消息界面或移動客戶端界面，客戶端可以請求從位于 第一金融合作伙伴的第一帳戶向位于第二金融合作伙伴的第二帳戶 轉帳。
11. 根據(jù)權利要求10所述的方法，包括 提供用于與第二金融合作伙伴進行交易的應用程序界面，其中，通過SMS消息界面或移動客戶端界面，客戶端可以請求從位于第一 金融合作伙伴的帳戶向位于第二金融合作伙伴的帳戶轉帳。
12. 根據(jù)權利要求10所述的方法，包括提供用于記錄通過所述SMS消息界面和移動客戶端界面請求 的交易的記錄系統(tǒng)。
13. —種方法，包括在移動電話的顯示器上顯示第一屏幕，以顯示多個選項，包括向 另 一方付款的第 一選項和請求余額信息的第二選項；在用戶選擇所述第一選項時，顯示第二屏幕，供用戶輸入向其發(fā) 出支付的目標電話號碼；在用戶輸入所述目標電話號碼之后，顯示第三屏幕，供用戶輸入 交易金額；在用戶輸入所述電話號碼之后，顯示第四屏幕，供用戶輸入PIN代碼；以及在用戶輸入所述PIN代碼之后，以無線方式向服務器發(fā)送包括 所述目標電話號碼、交易金額以及PIN代碼的交易信息，以便進行 處理。
14. 所述方法包括在用戶輸入所述目標電話號碼之后，顯示第五屏幕，供用戶輸入 可選消息。
15. 根據(jù)權利要求13所述的方法，包括在用戶選擇了所述第二選項時，以無線方式向所述服務器發(fā)送查 詢余額信息的請求；從所述服務器接收余額信息；以及 在第五屏幕中顯示所述余額信息。
16. 根據(jù)權利要求13所述的方法，其中，所述第一屏幕進一步 提供從另 一方請求付款的第三選項。
17. 根據(jù)權利要求13所述的方法，其中，所述第二屏幕具有第 三選項，在用戶選擇了該選項時，給用戶提供地址簿的使用權，從該 地址簿中，用戶可以選擇一個條目用作所述目標電話號碼。
18. 根據(jù)權利要求13所述的方法，其中，所述交易信息包括由 所述移動電話生成的序列號。
19. 根據(jù)權利要求13所述的方法，其中，資金是在所述服務器 中維護的，而不是在所述移動電話上維護的。
20. 根據(jù)權利要求13所述的方法，進一步包括 當在所述移動電話中接收到要求付款的請求時，顯示第五屏幕，供用戶可以輸入小費金額。
21. —種方法，包括從第一用戶接收向第二用戶支付某一金額的付款指示，其中，所 述第一用戶是已注冊的用戶，所述第二用戶通過所述第二用戶的電話 號碼來進行標識；基于所述電話號碼，確定所述第二用戶不是已注冊的用戶；向與所述電話號碼關聯(lián)的設備發(fā)送第一電子消息，通知所述第二用戶來自所述第 一用戶的待付款；在發(fā)送所述第一電子消息之后，注冊所述笫二用戶，并給所述第 二用戶呈現(xiàn)接受來自所述第一用戶的待付款的第一選項，以及拒絕來 自所述第 一用戶的待付款的第二選項;當所述第二用戶選擇所述第 一選項時，從與所述第 一用戶關聯(lián)的 第一帳戶劃出所述金額，并向與所述第二用戶關聯(lián)的第二帳戶劃入所 述金額；以及當所述第二用戶選擇所述第二選項時，向所述第 一用戶發(fā)送付款 被拒絕的第二電子消息。
22. 根據(jù)權利要求21所述的方法，其中，所述第二帳戶位于合 并帳戶中，并且當所述第一用戶是無卡已注冊的用戶時，所述第一帳 戶位于所述合并帳戶中，以及所述劃出和劃入過程包括在所述合并帳 戶內維護所述金額。
23. 根據(jù)權利要求21所述的方法，其中，所述第二帳戶位于合 并帳戶中，并且當所述第一用戶是無卡已注冊的用戶時，所述第一帳 戶位于所述合并帳戶中，以及所述劃出和劃入過程包括不在所述合并 帳戶外部轉移所述金額。
24. 根據(jù)權利要求21所述的方法，其中，當所述第一用戶是無 卡已注冊的用戶時，所述第一帳戶位于第一合并帳戶中，而所述第二 帳戶位于不同于所述第一合并帳戶的第二合并帳戶中，以及所述劃出 和劃入過程包括從所述第一合并帳戶向所述第二合并帳戶轉移所述 金額。
25. 根據(jù)權利要求21所述的方法，其中，所述第一用戶是有卡 已注冊的用戶，而所述第二帳戶位于合并帳戶中，以及所述劃出和劃 入過程包括從所述第 一帳戶向所述合并帳戶中的所述第二帳戶轉移 所述金額，從而，所述合并帳戶被增加了所述金額。
26. 根據(jù)權利要求21所述的方法，包括除所述付款指示之外，還接收由發(fā)送了所述付款指示的設備生成的序列號；以及在接收所述序列號之后，生成所述付款指示的交易號。
27. 根據(jù)權利要求21所述的方法，包括只有在所述序列號不匹配存儲在數(shù)據(jù)庫中的任何以前接收到的 序列號的情況下才處理所述付款指示。
28. 根據(jù)權利要求27所述的方法，其中，所述數(shù)據(jù)庫包括在輪 詢時間周期內接收到的序列號。
29. 根據(jù)權利要求21所述的方法，包括 在接收到所述序列號之后，生成預期的序列號；以及 只有在所述序列號匹配所述預期的序列號的情況下才處理所述付款指示。
30. —種方法，包括從第一用戶接收向第二用戶支付某一金額的付款指示，其中，所 述第一用戶是已注冊的用戶，所述第二用戶通過所述第二用戶的電話 號碼來進行標識；基于所述電話號碼，確定所述第二用戶不是已注冊的用戶；向與所述電話號碼關聯(lián)的設備發(fā)送第一電子消息，通知所述第二 用戶來自所述第 一用戶的待付款；在發(fā)送所述第一電子消息之后，注冊所述第二用戶，并給所述第 二用戶呈現(xiàn)接受來自所述第一用戶的待付款的第一選項，拒絕來自所 述第一用戶的待付款的第二選項，以及請求對來自所述第一用戶的待 付款作出更改的第三選項；當所述第二用戶選擇所述第 一選項時，從與所述第 一用戶關聯(lián)的 第一帳戶劃出所述金額，并向與所述第二用戶關聯(lián)的第二帳戶劃入所 述金額；以及當所述第二用戶選擇所述第二選項時，向所述第 一用戶發(fā)送付款 被拒絕的第二電子消息。
31. 根據(jù)權利要求30所述的方法，包括當所述第二用戶選擇所述第三選項時，向所述第 一用戶發(fā)送第三電子消息，說明所述第二用戶請求對所述待付款進行更改。
32. 根據(jù)權利要求30所述的方法，包括 當所述第二用戶選擇所述第三選項時，接收來自所述第二用戶將待付款更改為不同的金額的請求， 向所述第 一用戶發(fā)送第三電子消息，通知所述第 一用戶對所述待 付款進行更改，給所述第一用戶呈現(xiàn)接受所述對所述待付款的更改的第四選項 或拒絕對所述待付款的更改的第五選項，以及當所述第一用戶選擇所述第四選項時，從所述第 一用戶的帳戶中 劃出所述所述不同的金額并向與所述第二用戶關聯(lián)的帳戶劃入所述 不同的金額。
33. 根據(jù)權利要求30所述的方法，其中，所述設備至少是智能 電話、移動電話設備、便攜式電子郵件設備、個人數(shù)字助理或計算機 中的一個。
34. 根據(jù)沖又利要求30所述的方法，包括在確定所述第二用戶不是已注冊的用戶之后，在所述第一帳戶中 預留出所述金額。
35. 根據(jù)權利要求30所述的方法，包括在確定所述第二用戶不是已注冊的用戶之后，在所述第一帳戶中 預留出所述金額；以及在從接收到付款指示而所述第二用戶仍沒有注冊時起一定天數(shù) 過去之后，取消所述第一帳戶中的所述金額的預留。
36. —種方法，包括從第一用戶接收向第二用戶支付某一金額的付款指示，其中，所 述第一用戶是已注冊的用戶，所述第二用戶通過所述第二用戶的電話 號碼來進行標識；基于所述電話號碼，確定所述第二用戶不是已注冊的用戶； 向與所述電話號碼關聯(lián)的設備發(fā)送第一電子消息，通知所述第二 用戶所述第一用戶嘗試付款；在發(fā)送所述第一電子消息之后，注冊所述第二用戶，向所述第一 用戶發(fā)送第二電子消息，說明第二用戶已經(jīng)注冊，并給所述第一用戶呈現(xiàn)給所述第二用戶支付所述金額的第一選項；以及當所述第一用戶選擇所述第 一選項時，從與所述第一用戶關聯(lián)的 第一帳戶中劃出所述所述金額，并向與所述第二用戶關聯(lián)的第二帳戶 劃入所述金額。
37. 根據(jù)權利要求36所述的方法，包括在所述第二用戶進行注冊之后，給所述第一帳戶劃入引薦獎金金額。
38. 根據(jù)權利要求36所述的方法，包括在所述第二用戶進行注冊之后，給所述第二帳戶劃入引薦獎金金額。
39. 根據(jù)權利要求36所述的方法，包括向所述第一用戶發(fā)送第二電子消息，說明第二用戶不是已注冊的用戶。
40. 根據(jù)權利要求36所述的方法，包括除所述付款指示之外，還接收由發(fā)送了所述付款指示的設備生成 的序列號；以及在接收所述序列號之后，生成所述付款指示的交易號。
41. 一種方法，包括接收從用戶設備以無線方式傳輸?shù)膬r值交換交易的電子請求；與所述電子請求與一起接收與所述電子請求關聯(lián)的傳輸?shù)拿荑€；判斷所述傳輸?shù)拿荑€是否存在于交易表中；如果所述傳輸?shù)拿荑€不在所述交易表中，則向所述交易表中輸入 所述傳輸?shù)拿荑€和價值交換交易，并處理所述價值交換交易；如果所述傳輸?shù)拿荑€位于所述交易表中，則不對所述價值交換交 易進行處理。
42. 根據(jù)權利要求41所述的方法，其中，所述傳輸?shù)拿荑€包括 標識請求了所述價值交換交易的用戶的電子標識符和序列號，所述序列號存儲在所迷用戶設備中，在由所述用戶設備傳輸下一個價值交換 交易之前前進到序列中的下一個編號。
43. 根據(jù)權利要求42所述的方法，其中，所述序列號存儲在所 述用戶設備中的非易失性存儲器中。
44. 根據(jù)權利要求41所述的方法，其中，所述傳輸?shù)拿荑€包括 偽隨機數(shù)。
45. 根據(jù)權利要求41所述的方法，所述傳輸?shù)拿荑€包括標識請 求了所述價值交換交易的用戶的第 一 電子標識符，標識作為所述價值 交換交易的目標的用戶的第二電子標識符，所述價值交換交易的金 額，以及與所述價值交換交易關聯(lián)的時間。
46. 根據(jù)權利要求41所述的方法，其中，所述價值交換交易包 括從與所述用戶設備關聯(lián)的第一用戶向與另一個用戶設備關聯(lián)的第 二用戶匯款。
47. 根據(jù)權利要求41所述的方法，其中，所述用戶設備是移動電話。
48. 根據(jù)權利要求41所述的方法，其中，所述傳輸?shù)拿荑€不在 所述用戶設備上顯示。
49. 根據(jù)權利要求41所述的方法，其中，電子請求是通過所述 用戶設備的SMS文本消息服務發(fā)送的。
50. 根據(jù)權利要求41所述的方法，其中，當所述用戶設備使用 第 一應用程序客戶端發(fā)送所述電子請求時，所述傳輸?shù)拿荑€包括第一 信息，當所述用戶設備使用不同于所述第 一應用程序客戶端的第二應 用程序客戶端發(fā)送所述電子請求時，所述傳輸?shù)拿荑€包括第二信息。
51. 根據(jù)權利要求50所述的方法，其中，所述第一應用程序客 戶端是在所述用戶設備上執(zhí)行的專用價值交換交易服務應用程序，而 所述第二應用程序客戶端是所述用戶設備的SMS消息應用程序。
52. 根據(jù)權利要求41所述的方法，其中，如果所述傳輸?shù)拿荑€ 位于所述交易表中，則暫停發(fā)送所述電子請求的用戶的帳戶。
53. 根據(jù)權利要求41所述的方法，其中，處理所述價值交換交易的過程包括為所述價值交換交易生成交易標識符號碼；向所述用戶設備發(fā)送包括所述交易標識符號碼的電子消息，其 中，所述交易標識符號碼在所述用戶設備上是可查看的。
54. —種方法，包括接收從用戶設備以無線方式傳輸?shù)膬r值交換交易的電子請求；接收與所述電子請求關聯(lián)的傳輸?shù)拿荑€；生成預期的密鑰；將所述傳輸?shù)拿荑€與所述預期的密鑰進行比較；以及 如果所述傳輸?shù)拿荑€匹配所述預期的密鑰，則處理所述價值交換交易。
55. 根據(jù)權利要求54所述的方法，其中，生成所述預期的密鑰 的過程包括使用為與所述價值交換交易關聯(lián)的用戶帳戶存儲的種子 值對一個函數(shù)進行求值，所述方法進一步包括在對所述函數(shù)進行求值 之后，確定序列中的下一個種子值，并用序列中的所述下一個種子值 替換為所述用戶帳戶存儲的所述種子值。
56. 根據(jù)權利要求54所述的方法，包括如果所述傳輸?shù)拿荑€不匹配所述預期的密鑰，則不對所述價值交 換交易進行處理，并暫停與所述價值交換交易關聯(lián)的用戶帳戶。
57. 根據(jù)權利要求54所述的方法，其中，處理所述價值交換交 易的過程包括為所述價值交換交易生成不同于所述預期的密鑰的交易標識符號碼；向所述用戶設備發(fā)送包括所述交易標識符號碼的電子消息，其 中，所述交易標識符號碼顯示在所述用戶設備上。
58. 根據(jù)權利要求54所述的方法，其中，所述價值交換交易包 括從與所述用戶設備關聯(lián)的第一用戶向與另一個用戶設備關聯(lián)的第 二用戶匯款。
59. 根據(jù)權利要求54所述的方法，其中，所述預期的密鑰是偽隨機數(shù)。
60. 根據(jù)權利要求54所述的方法，其中，生成所述預期密鑰的 過程包括從與所述價值交換交易關聯(lián)的用戶資料中檢索種子值； 從所述用戶資料中檢索有關用來生成所述傳輸?shù)拿荑€的函數(shù)的 信息；以及使用所述種子值對所述函數(shù)進行求值。
61. —種方法，包括處理系統(tǒng)的一組用戶的金融交易，其中，所述金融交易可以通過 移動電話指定，所述用戶的子組與金融機構關聯(lián)；處理與第一金融機構關聯(lián)的金融交易，其中，第一子組中的用戶 與所述第 一金融機構關聯(lián)；處理與第二金融機構關聯(lián)的金融交易，其中，第二子組中的用戶與所述第二金融機構關聯(lián)；處理與第三金融機構關聯(lián)的金融交易，其中，第三子組中的用戶 與所述第三金融機構關聯(lián)；維護包括與所述第一、第二、以及第三金融機構關聯(lián)的所述第一、 第二以及笫三子組用戶的資金的虛擬合并帳戶；以及基于所述第一子組用戶的所述虛擬合并帳戶中的資金的浮動收 益，加所述第三子組用戶的所述虛擬合并帳戶中的資金的浮動收益的 百分比，向所述第一金融機構分發(fā)第一紅利。
62. 根據(jù)權利要求61所述的方法，包括 基于所述第二子組用戶的所述虛擬合并帳戶中的資金的浮動收益，加所述第三子組用戶的所述虛擬合并帳戶中的資金的浮動收益的 百分比，向所述第二金融機構分發(fā)第二紅利。
63. 根據(jù)權利要求61所述的方法，包括 從所述第一子組中的第一用戶接收向所述第二子組中的第二用戶轉帳的指示，其中，資金不在所述虛擬合并帳戶外部轉移。
64. 根據(jù)權利要求63所述的方法，其中，所述指示是以無線方式通過SMS消息從移動電話發(fā)送的。
65. 根據(jù)權利要求63所述的方法，其中，所述指示是以無線方 式使用在所述移動電話上執(zhí)行的應用程序從移動電話發(fā)送的。
66. 根據(jù)權利要求61所述的方法，其中，所述第三金融機構是 所述系統(tǒng)的直接合作伙伴。
67. 根據(jù)權利要求61所述的方法，其中，每一個用戶都只與所 述第一、第二或第三金融機構中的一個關聯(lián)。
68. 根據(jù)權利要求61所述的方法，包括 管理虛擬合并帳戶的記錄系統(tǒng)，其中，所述記錄系統(tǒng)包括所述第一、第二以及第三子組中的用戶的交易的記錄。
69. —種方法，包括處理系統(tǒng)的一組用戶的金融交易，其中，所述金融交易可以通過 移動電話指定，所述用戶的子組與金融機構關聯(lián)；處理與第一金融機構關聯(lián)的金融交易，其中，第一子組中的用戶 與所述第一金融機構關聯(lián)；處理與第二金融機構關聯(lián)的金融交易，其中，第二子組中的用戶與所述第二金融機構關聯(lián)；處理第三子組中的與所述系統(tǒng)關聯(lián)而不與所述第一和第二金融 機構關聯(lián)的用戶的金融交易；維護包括與所述第一、第二金融機構和所述系統(tǒng)關聯(lián)的所述第 一、第二以及第三子組用戶的資金的虛擬合并帳戶；以及基于所述第一子組用戶的所述虛擬合并帳戶中的資金的浮動收 益，加所述第三子組用戶的所述虛擬合并帳戶中的資金的浮動收益的 百分比，向所述第一金融機構分發(fā)第一紅利。
70. 根據(jù)權利要求69所述的方法，包括 基于所述第二子組用戶的所述虛擬合并帳戶中的資金的浮動收益，加所述第三子組用戶的所述虛擬合并帳戶中的資金的浮動收益的 百分比，向所述第二金融機構分發(fā)第二紅利。
71. 根據(jù)權利要求69所述的方法，包括從所述第一子組中的第一用戶接收向所述第二子組中的第二用 戶轉帳的指示，其中，資金不在所述虛擬合并帳戶外部轉移。
72. 根據(jù)權利要求71所述的方法，其中，所述指示是以無線方 式通過SMS消息從移動電話發(fā)送的。
73. 根據(jù)權利要求71所述的方法，其中，所述指示是以無線方 式使用在所述移動電話上執(zhí)行的應用程序從移動電話發(fā)送的。
74. 根據(jù)權利要求69所述的方法，其中，每一個用戶都只與所 述第一金融機構、第二金融機構，或所述系統(tǒng)中的一個關聯(lián)。
75. 根據(jù)權利要求69所述的方法，包括從所述第一子組中的第一用戶接收向所述第三子組中的第二用 戶轉帳的指示，其中，資金不在所述虛擬合并帳戶外部轉移。
76. 根據(jù)權利要求71所述的方法，其中，所述指示是通過因特 網(wǎng)瀏覽器發(fā)送的。
77. 根據(jù)權利要求71所述的方法，包括管理虛擬合并帳戶的記錄系統(tǒng)，其中，所述記錄系統(tǒng)包括所述第 一、第二以及第三子組中的用戶的交易的記錄。
78. —種方法，包括接收多個商家分擔款項以為會員支付系統(tǒng)提供資金；將所述商家分擔款項放入合并信托帳戶中，其中，商家對他們的分擔款項不收利息；允許多個消費者免費成為所述會員支付系統(tǒng)的注冊的用戶； 允許注冊的用戶免費向所述會員支付系統(tǒng)的往來帳戶加載資金或從中卸載資金；以及允許商家免費向所述會員支付系統(tǒng)的往來帳戶加載資金或從其中卸栽資金，從而，用合并信托帳戶的利息為所述會員支付系統(tǒng)提供資金。
79. 根據(jù)權利要求78所述的方法，其中，所述會員支付系統(tǒng)允 許注冊的用戶通過移動電話請求向另 一個注冊的用戶付款。
80. 根據(jù)權利要求78所述的方法，其中，所述會員支付系統(tǒng)允許注冊的用戶通過移動電話請求向商家付款。
81. 根據(jù)權利要求78所述的方法，其中，所述會員支付系統(tǒng)管 理所述注冊的用戶的交易記錄。
82. 根據(jù)權利要求78所述的方法，其中，所述會員支付系統(tǒng)管 理所述商家的交易記錄。
83. 根據(jù)權利要求78所述的方法，其中，所述會員支付系統(tǒng)管 理所述注冊的用戶和商家的交易記錄。
84. 根據(jù)權利要求78所述的方法，其中，當商家請求歸還所述 商家對所述會員支付系統(tǒng)的分擔款項時，注冊的用戶將不再被允許向 所述商家轉帳。
85. 根據(jù)權利要求78所述的方法，其中，在商家是所述會員支 付系統(tǒng)的參與者的情況下，不向所述商家收取定期經(jīng)常性交易費用。
86. 根據(jù)權利要求78所述的方法，其中，注冊的用戶能通過自 動票據(jù)交換所(ACH)或直接儲蓄帳戶(DDA)中的至少一個來加載 或卸載資金。
87. 根據(jù)權利要求78所述的方法，包括允許注冊的用戶通過使用兩因素授權方案，通過所述會員支付系 統(tǒng)授權向商家支付。
88. 根據(jù)權利要求78所述的方法，包括允許注冊的用戶通過使用所述注冊的用戶的移動電話和所述用 戶正確地輸入個人標識號，通過所述會員支付系統(tǒng)授權向商家支付。
89. 根據(jù)權利要求78所述的方法，其中，給每一個注冊的用戶 提供借記卡。
90. 基本上如上文所描述的系統(tǒng)。
91. 基本上如圖所示的系統(tǒng)。
92. 基本上如圖所示的方法。
93. 基本上如上文所描述的方法。
全文摘要
移動支付平臺和服務提供了由移動設備的用戶進行付款的快速，簡便的方式。該平臺還與諸如電子郵件、即時消息，以及Web之類的非移動渠道以及設備連接。在一種實現(xiàn)方式中，從諸如移動電話或個人數(shù)字助理之類的帳戶持有人的移動設備訪問資金，以進行支付或接收支付。金融交易可以在個人之間(P2P)或個人與商家之間(P2M)進行，其中，每一方都由諸如電話號碼或條形碼之類的唯一指示符來進行標識?？梢酝ㄟ^任意數(shù)量的手段來請求進行交易，包括SMS消息、Web、電子郵件、即時消息、移動客戶端應用程序、即時消息插件應用程序或“小部件”。駐留在移動設備上的移動客戶端應用程序簡化了訪問，并以快速安全的方式執(zhí)行金融交易。
文檔編號G06Q40/00GK101454794SQ200780019766
公開日2009年6月10日 申請日期2007年3月30日 優(yōu)先權日2006年3月30日
發(fā)明者C·里爾尼, D·斯科瓦特茲, H·斯霍基, J·圖米納羅, N·沙, P·霍索卡瓦 申請人:奧博佩公司