CN101454794A

CN101454794A - 移动的个人之间支付系统

Info

Publication number: CN101454794A
Application number: CNA2007800197662A
Authority: CN
Inventors: J·图米纳罗; C·里尔尼; P·霍索卡瓦; D·斯科瓦特兹; H·斯霍基; N·沙
Original assignee: Obopay Inc
Current assignee: Obopay Inc
Priority date: 2006-03-30
Filing date: 2007-03-30
Publication date: 2009-06-10
Also published as: CN101454795A

Abstract

移动支付平台和服务提供了由移动设备的用户进行付款的快速，简便的方式。该平台还与诸如电子邮件、即时消息，以及Web之类的非移动渠道以及设备连接。在一种实现方式中，从诸如移动电话或个人数字助理之类的帐户持有人的移动设备访问资金，以进行支付或接收支付。金融交易可以在个人之间(P2P)或个人与商家之间(P2M)进行，其中，每一方都由诸如电话号码或条形码之类的唯一指示符来进行标识。可以通过任意数量的手段来请求进行交易，包括SMS消息、Web、电子邮件、即时消息、移动客户端应用程序、即时消息插件应用程序或“小部件”。驻留在移动设备上的移动客户端应用程序简化了访问，并以快速安全的方式执行金融交易。

Description

移动的个人之间支付系统

对相关申请的交叉引用

[02]本专利申请要求2006年3月30日递交的美国专利申请60/744,013、2006年4月15日递交的美国专利申请60/744,930、以及2006年12月18日递交的美国专利申请60/870,484的优先权，通过与本申请中引用的所有其他参考文献一起引用结合在本申请中。

发明背景

[03]本发明的实施例涉及用于通过诸如移动电话之类的移动设备进行金融交易的系统和技术，具体来说，涉及用于转帐支付的移动的个体化支付转帐基础架构和方法。进一步地，本发明的实施例涉及金融交易系统，具体来说，涉及用于进行个人之间的和消费者与商家之间的交易的闭环金融交易系统以及使用该金融交易系统的方法。

[04]从历史来看，希望进行金融交易以购买商品的帐户持有人都是依赖诸如货币、支票、信用卡或借记卡之类的各种金融工具。令人遗憾的是，这些金融工具种类存在某些安全性问题，防欺诈对于支付行业的盈利率是一个大的考验。当现金丢失或被盗时，通常没有补救的办法，唯有接受损失。对于其他金融工具，损失不是主要问题，但是，欺诈会导致支付行业的严重损失。的确，信用卡、借记卡以及支票欺诈一直是并将继续是该行业的较大的问题。

[05]支票欺诈如此常见的一个原因是由于需要在物理上向付款方开户行出示支票。如此，当支票在金融交易中被接受时，支票不会保证有资金。相反地，支票只是一张纸，必须连同所使用的帐户以及用于授权支付的签名一起验证支取该支票的银行的合法性。对于信用卡或借记卡，用户可能没有被授权，而是在发行者可以停用帐户之前收取相当大的费用。

[06]显而易见，所需的是这样的支付系统，金融交易中的资金的接收方能够轻松地利用电话验证持有资金、帐户以及余额的实体的合法性和人的身份。进一步，所需的是访问信用卡和借记卡以进行金融交易的更安全的方式。

[07]尽管上面列出的每一种金融工具过去表现得很好，显然，消费者需要一种简单、安全的用于达成金融交易的方法。信用卡的普遍使用提供了充分的证据证明，对于小的购物，消费者更愿意使用电子付款系统，而不是携带大量的现金或开具多张支票。甚至随着电子付款系统的非常流行地采用，显然，对于用于完成金融交易的更快更便宜更方便的电子付款系统有强烈的需求。进一步，对于更个体化的电子付款系统也有需求，以便以类似于现金交易的方式轻松地进行金融交易。

[08]尽管信用卡的使用越来越普及，但是，仍有巨大的群体主要依赖于现金交易，这一群体仍需要方便的并且经济合算的电子付款系统来发出支付和接收支付。这种需求导致预存款的借记卡的普遍使用。令人遗憾的是，借记卡主要是为了使消费者可以在购置了销售点交易终端的商家用借记卡进行支付而设计的。若不是不得不麻烦地去趟银行或具有POS终端的商家，个人难以将存储在预存款的借记卡中的一部分金额转帐给另一个个人。所需的是能在个人之间达成金融交易而无需直接涉及第三方金融机构或外面的金融机构的电子付款系统。

[09]虽然许多人不能访问POS终端，但是，大多数人可以访问便携式无线通信设备，常常简称为蜂窝式移动设备。的确，现在人们通常利用由典型的移动电话提供的附加功能，如文本消息、照相，以及听音乐，因为移动设备已经能够包括集成的PDA、MP3、传呼、播放器，以及电子邮件功能。

[10]通过语音、电子邮件、SMS文本消息、即时消息以及因特网处理通信的移动电话设备及其他便携式设备有了爆炸式的增长。人们常常记住随身携带他们的移动或蜂窝电话，即使他们忘记携带他们的钱包或汽车钥匙。移动电话在美国以及全世界的许多国家无所不在。在2005年，据估计，有21.4亿移动电话用户。世界的人口的大约80％拥有移动电话覆盖。因此，对于允许移动电话发出支付和接收支付(如现金)，并提供其他金融和移动银行交易的系统的需求是巨大的。

[11]使用蜂窝式设备创建移动支付系统的尝试有时成功有时失败，主要因为手机必须具有用于存储帐户余额和帐户信息的附加线路设备(或“芯片”)。当持有电话的人希望划拨资金时，资金在销售点从芯片中扣除，并稍后转帐到金融机构，并由金融机构进行记录。显而易见，这种在进行销售的时间和记录销售的时间之间的滞后是低效率的，万一在记录销售资料之前商家的POS设备失常，就存在销售资料丢失的风险。此外，如果电话丢失，帐户余额可能被持有该电话的任何人使用。尽管这种系统能较好地防止资金丢失并优于携带现金，但是，这种系统也缺乏适当的安全性以防止帐户持有人的资金被其他人非法使用。

[12]此外，信用卡还表明，持有人被银行或其他发行者给予了一定的信用额度，它允许持有人在预定的金额范围内进行购物或提取现金。基于信用卡协议的条款收取利息，有时还向持有人收取年费。传统上，给持有人提供一张带有帐号的塑料卡。

[13]信用卡交易利用由商家买单的专有的网络来对交易进行结算。由于支付系统的专有的特征，这样的系统的成本很高。此外，还因为有多方参与到信用卡交易中，这样的系统常常被称为“开环”金融系统。

[14]图34显示了一种专有的网络的示例，包括销售点(POS)终端3401，用于在商家的位置启动交易，以及通过专有的网络3403与POS终端3401相连接的支付处理器3402。在某些情况下，专有的网络只不过是与因特网的连接。支付处理器3402又通过专有的网络3404连接到信用卡交换中心3408。

[15]为启动交易，消费者将在POS终端处出示信用卡3406，或者RFID钥匙链3407。钥匙链是一种安全令牌：带有内嵌存储机制的小型硬件设备。信用卡3406和钥匙链3407两者都包括编码信息，POS终端检测这种信息，并通过专有的网络3403转发到交易处理器3402。令人遗憾的是，信用卡和钥匙链都不能在不访问POS终端的情况下工作，所说的访问POS终端是指可以通过接近POS终端进行也可以通过电话进行。

[16]交易处理器3402通过私用网络3404向信用卡交换中心(进行通信以管理信用卡交易的处理、清算，以及结算的金融实体的网络)提交交易。信用卡交换中心将交易路由到用户的信用卡发行者3409那里。发行者基于检测到的帐号识别消费者，并在批准或者拒绝交易之前确定可用的信用额度。如果批准了交易，则通过信用卡交换中心将金额转发到商家的银行处理器3405，金额被添加到商家的银行维护的信用帐户。

[17]由于交易的信息是在专有的网络上传输的，商家为接受信用卡的特权和访问这些专有的网络支付高昂的月度服务费。商家还进一步为每一次交易支付相当可观的每次交易费用。例如，为处理在便利商店购买一瓶$1.00的水的简单交易，商家可能要产生大约$0.25的每次交易费用和交易金额的3％，虽然如果商家产生大量的拒绝付款，支付更高的费用是常见的。在支付他们的管理费用之后，每次交易费用可以是总体费用的相当可观的一部分，在某些情况下，会大于特定商品的利润率。令人遗憾的是，对于许多小型商家，月度服务费和每次交易的费用的总和可能超过他们的该月的信用卡销售的总利润。对于较大的商家，交易费用对于盈利率妨碍程度较小，但对他们的利润率仍是一个不受欢迎的侵蚀。

[18]不仅信用卡对于大多数商家是“高成本”费用项目，他们还经常遭到严重的欺诈和滥用。例如，如果信用卡被盗，则可以被任何人在POS终端中使用，即使他们不是持有人。为防止这样的使用，许多POS终端现在包括要求消费者输入发送信用卡帐单的邮政编码，以鉴定消费者是否为持有人。令人遗憾的是，邮政信息可以在因特网上轻松地获得，如此，大胆的小偷不会被完成交易的额外信息请求所吓住。然而，必须输入这样的多余信息也会使持有人觉得麻烦。

[19]最后，开环信用卡系统也不完全适合于那些其中一方不是商家的个人之间的交易。例如，如果两个学生希望分担一对电影票的费用，一个学生希望以电子方式向另一个学生转帐资金。然而，即便只有交易费用也会使得交易十分昂贵，阻拦使用。此外，学生同意支付月费及与商家的帐户关联的其他费用以便访问信用卡交换中心也是不大可能的。相应地，由信用卡发行者部署和操作的闭环系统也几乎不完全适合于个人之间的金融交易。

[20]因此，所需的是经济合算的移动支付系统，使帐户持有人能在任何时间任何地方都可以灵活地进行他们的金融交易。此外，还需要一种“移动钱包”，人们可以作为可以从移动电话访问的现金源携带。此外，还需要一种用于供消费者进行移动支付的软件应用程序和受管理的服务，它们作为移动电话平台上的移动钱包来操作。此移动钱包应该是安全的，易于使用的，并易于获取的，以便进行移动支付的功能对任何移动帐户持有人都可用。此外，还需要一种易于进行支付的闭环金融交易系统，这种金融交易系统没有与闭环金融系统关联的大量的付款手续费，并且对于参与金融交易的持有人、商家及其他各方来说，具有高度的安全性。相应地，公开了本发明的下列实施例和示范性描述。

发明内容

[21]移动支付平台和服务提供了由移动设备的用户进行付款的快速，简便的方式。该平台还与诸如电子邮件、即时消息，以及Web之类的非移动渠道以及设备连接。在一种实现方式中，从诸如移动电话或个人数字助理之类的帐户持有人的移动设备访问资金，以进行支付或接收支付。金融交易可以在个人之间(P2P)或个人与商家之间(P2M)进行，其中，每一方都由诸如电话号码或条形码之类的唯一指示符来进行标识。可以通过任意数量的手段来请求进行交易，包括SMS消息、Web、电子邮件、即时消息、移动客户端应用程序、即时消息插件应用程序或“小部件”。驻留在移动设备上的移动客户端应用程序简化了访问，并以快速安全的方式执行金融交易。

[22]本发明提供了移动支付系统(MPS)或移动的个人之间支付系统，用于快速方便地进行货币交易。移动电话在全世界无所不在。许多人在日常生活中都携带移动电话或类似的便携式通信设备，即使他们不携带钱包。通过移动支付系统以及他们的电话，用户将能够象用普通的钱包那样办很多事情，并且远远多于用普通钱包办的事。用户将能够发出支付和接收支付，为服务进行支付，为帐单进行支付，为电影票进行支付、为杂货店进行支付，为保姆进行支付，为咖啡和报纸进行支付，立刻偿付给朋友，为晚餐帐单各自支付，向孩子汇款，从父母那里得到汇款，获得快速的或紧急的现金，发送紧急的现金，为友好赌博付清或收费，为梦幻足球(fantasy football)游戏进行支付，为花园服务进行支付，为会费进行支付，跟踪购物，检查余额，等等。可以理解，本发明的系统提供了许多优点。

[23]本发明所解决的问题和满足的需求包括：现金会被盗，现金交易不可追踪。需要鼓励现金存放在银行中，而不是消费者的口袋中。需要低成本的或小型存现存储器。需要较低的成本的电子支付。需要电子支付对每个人、任何地方、任何时间几乎实时地可用。需要电子支付产生立等可用的形式(例如，附属预存款借记卡，或通过实时连接到用户的在银行中的活期储蓄帐户(DDA))。需要电子支付能够被有银行帐户的和无银行帐户的消费者访问。需要电子支付能够链接到现有的金融工具，如信用卡、借记卡、预存款的卡、工资单，及其他。需要能够实时地或几乎实时地向现有的金融工具中加载和从中卸载。需要电子支付能够跨银行地使用。需要电子支付能够通过移动设备进行访问。需要电子支付能够通过诸如PC、POS支付终端、TV电缆盒、数字视频记录器(DVR)、卫星盒之类的消费者媒体设备，及其他设备进行访问。需要电子支付能够通过诸如自动售货机、停车计时器、售货亭之类的人机设备及其他设备进行访问。需要电子支付能够跨诸如移动运营商、有线运营商、卫星运营商之类的电子网络及其他网络地使用。

[24]本发明的一些优点包括MPS电子支付，鼓励现金留在银行(而不是消费者的口袋中)。MPS电子支付是安全的，并且是可追踪的。MPS电子支付几乎实时地进行。MPS电子支付能够被任何人在任何时间和任何地方进行访问。MPS可以提供可选的或者不是必需的附属预存款借记卡(例如，MasterCard、Visa，或其他)，用于进行即时资金访问。MPS电子支付可以用于个人之间的(P2P)以及个人与商家之间的(P2M)交易。MPS资金存储在分布式合并合作银行帐户内。在MPS支付记录系统内管理了MPS消费者资金的“T”记录(用于较低的成本P2P和P2M转帐)。MPS促进现有金融工具(例如，信用卡、借记卡，其他)的手动或自动化加载功能。MPS促进现有金融工具(例如，信用卡、借记卡，其他)的手动或自动化卸载功能。MPS可以优化加载或卸载处理(即，当可能时，在银行内执行加载或卸载)。MPS有助于跨银行地进行电子支付。MPS有助于跨运营商或跨网络地进行电子支付。MPS有助于跨设备或跨渠道地(即，手机、电子邮件、Web、即时消息)进行电子支付。MPS资金是在银行中电子的，受PIN保护的，并且在银行中是“活的”。

[25]此外，闭环金融交易系统部分地基于手机或PDA的使用来进行支付或接收支付。金融交易可以在个人之间进行，其中，每一方都由诸如电话号码、电子邮件地址、即时消息标识符或条形码之类的唯一指示符来进行标识，或在消费者与商家之间进行。费用结构是公开的，以有助于广泛的采用，人们无需携带现金。

[26]在一个实施例中，本发明是包括连接到网络的消费者界面的金融交易系统，包括：处理来自Web浏览器客户端的交易请求的Web界面；处理来自移动电话客户端上的移动因特网浏览器的交易请求的移动因特网浏览器界面；使用SMS文本消息处理交易请求的SMS界面；以及，处理来自在移动电话客户端上执行的移动客户端应用程序的请求的移动客户端应用程序界面。

[27]消费者界面可以包括处理来自电话音频信道的请求的交互式语音响应界面。系统可以包括新注册的用户的合并帐户，其中，在注册之后，新注册的用户可以立即与已注册的用户进行交易。移动客户端应用程序界面可以允许进行汇款交易、加载帐户交易、卸载帐户交易，以及余额查询交易。消费者界面还可以进一步包括处理来自即时消息客户端的请求的即时消息界面。

[28]该系统可以包括：金融合作伙伴界面；商家界面，其中，用户能通过消费者界面访问存储在通过金融合作伙伴界面连接到系统的银行中的资金，并向连接到商家界面的商家转帐。该系统可以包括由金融交易系统进行管理的记录系统，记录通过消费者界面执行的交易。该系统可以包括由金融交易系统进行管理的合并帐户(pooledaccount)，其中，通过消费者界面访问该系统的多个客户端在合并帐户中具有帐户。许多客户端可以在合并帐户中没有帐户，而是在可以访问该系统的金融机构中具有帐户。

[29]在一个实施例中，本发明是包括下列步骤的方法：提供与第一金融合作伙伴进行交易的应用程序界面；提供接收进行交易的请求的SMS消息界面；以及，提供用于接收进行交易的请求的移动客户端应用程序界面，其中，通过SMS消息界面或移动客户端界面，客户端可以请求从位于第一金融合作伙伴的第一帐户向位于第二金融合作伙伴的第二帐户转帐。

[30]该方法还可以进一步包括提供用于接收进行交易的请求的移动客户端应用程序界面，其中，通过SMS消息界面或移动客户端界面，客户端可以请求从位于第一金融合作伙伴的第一帐户向位于第二金融合作伙伴的第二帐户汇款。该方法可以包括提供用于记录通过SMS消息和移动客户端界面请求的交易的记录系统。

[31]在一个实施例中，本发明是包括下列步骤的方法：在移动电话的显示器上显示第一屏幕，以显示多个选项，包括向另一方付款的第一选项和请求余额信息的第二选项；在用户选择第一选项时，显示第二屏幕，供用户输入向其发出支付的目标电话号码；在用户输入目标电话号码之后，显示第三屏幕，供用户输入交易金额；在用户输入电话号码之后，显示第四屏幕，供用户输入PIN代码；以及，在用户输入PIN代码之后，以无线方式向服务器发送交易信息，包括目标电话号码、交易金额，以及PIN代码，以便进行处理。

[32]该方法可以包括，在用户输入目标电话号码之后，显示第五屏幕，供用户输入可选消息。该方法可以包括：在用户选择了第二选项时，以无线方式向服务器发送查询余额信息的请求；从服务器接收余额信息；以及，在第五屏幕中显示余额信息。该方法可以包括，其中，第一屏幕进一步提供从另一方请求付款的第三选项。该方法可以包括，第二屏幕具有第三选项，在用户选择了该选项时，给用户提供地址簿的使用权，从该地址簿中，用户可以选择一个条目用作目标电话号码。交易信息可以包括由移动电话生成的序列号。在一种实现方式中，用户的资金是在服务器中维护的，而不是在移动电话上维护的。

[33]在一种实现方式中，该方法包括：当在移动电话中接收到要求付款的请求时，显示第五屏幕，供用户可以输入小费金额。

[34]通过下面的参考附图进行的详细描述，本发明的其他目的、特征，以及优点将变得更加显而易见，在附图中，类似的附图标记在整个图中表示相同的功能，其中：

附图说明

[35]图1显示了本发明的系统的方框图。

[36]图2显示了本发明的特定实施例的软件体系结构。

[37]图3显示了用于实现本发明的实施例的环境。

[38]图4显示了本发明的实施例，其中，与支付服务一起提供了增值服务。

[39]图5显示了移动的个人之间支付的系统拓扑。

[40]图6显示了在同业银行的个人之间的支付。

[41]图7显示了跨银行个人之间的支付。

[42]图8显示了链接的帐户加载。

[43]图9显示了链接的帐户卸载。

[44]图10显示了根据本发明的技术的支付系统和个人之间的支付。

[45]图11显示了用于在带有卡的会员和未注册的用户之间进行交易的方法。

[46]图12显示了用于在没有卡的会员和未注册的用户之间进行交易的方法。

[47]图13显示了在一个无卡会员和另一个无卡会员之间进行交易的方法。

[48]图14显示了用于在一个有卡会员和另一个有卡会员之间进行交易的方法。

[49]图15显示了在一个有卡会员和一个无卡会员之间进行交易的方法。

[50]图16显示了在一个无卡会员和一个有卡会员之间进行交易的方法。

[51]图17显示了对未注册的用户进行注册的方法。

[52]图18显示了激活卡的方法。

[53]图19显示了本发明的特定实施例的完整的系统图形。

[54]图20显示了两个个人卡帐户之间的个人之间的支付。

[55]图21显示了卡帐户和非会员帐户之间的个人之间的支付。

[56]图22显示了卡帐户和无卡帐户之间的个人之间的支付。

[57]图23显示了无卡帐户到无卡帐户之间的个人之间的支付。

[58]图24显示了信用卡加载。

[59]图25显示了本发明的另一个特定实施例的完整的系统图形。

[60]图26显示了无卡帐户和无卡帐户之间的个人之间的支付。

[61]图27显示了无卡帐户和卡帐户之间的个人之间的支付。

[62]图28显示了个人之间的支付，与非会员的“病毒式”交易。

[63]图29显示了奖励资金。

[64]图30显示了信用卡加载。

[65]图31显示了ACH加载。

[66]图32显示了ACH卸载。

[67]图33显示了ATM加载。

[68]图34显示了用于使用“封闭的”互换网络实现信用卡交易的现有技术环境。

[69]图35显示了根据本发明的实施例的闭环支付交易系统。

[70]图36显示了根据本发明的实施例的用于实现费用较低并且安全性改善的闭环金融交易系统的环境。

[71]图37是根据本发明的实施例的闭环金融系统的方框图。

[72]图38是根据本发明的实施例的移动客户端应用程序(MCA)的方框图。

[73]图39显示了根据本发明的实施例的闭环支付交易系统。

[74]图40显示了根据本发明的实施例的闭环金融系统的示范性费用结构。

[75]图41显示了本发明的支持会员的支付系统实现方式中的加载信任操作。

[76]图42显示了支持会员的支付系统中的消费者注册过程。

[77]图43显示了支持会员的支付系统中的加载和卸载操作。

[78]图44显示了支持会员的支付系统中的购物交易。

[79]图45显示了使用虚拟合并帐户的系统。

[80]图46显示了根据本发明的实施例的购物功能。

[81]图47显示了根据本发明的实施例的另一个购物功能。

[82]图48是由根据本发明的实施例的至少一个SMS消息机制执行的金融交易的系统级别的例图。

[83]图49显示了根据本发明的实施例的用于保护基于SMS的金融交易的方法。

[84]图50显示了根据本发明的一个实施例的安全的SMS聚集服务器的用途。

[85]图51显示了根据本发明的实施例的新帐户持有人的注册过程。

[86]图52显示了根据本发明的实施例的分层的欺诈检测系统。

[87]图53显示了根据本发明的实施例的合并帐户结构。

[88]图54，55和56显示了根据本发明的实施例的用于防止欺诈和多重重复交易请求的方法。

[89]图57显示了序列号验证的示例。

[90]图58显示了序列号验证的另一个示例。

[91]图59显示了根据本发明的实施例的指定在设备和数据中心之间传递的序列化数据的格式的有线协议。

[92]图60显示了根据本发明的实施例的服务电话的成功的调用。

[93]图61显示了根据本发明的实施例的对服务电话的响应，其中，由于服务电话而生成异常。

[94]图62显示了根据本发明的实施例的另一个服务电话的成功的调用。

[95]图63显示了根据本发明的实施例的移动设备的高水平OMAP设计层。

[96]图64是显示了根据本发明的实施例的OMAP通信设计的状态图。

[97]图65是显示了根据本发明的实施例的OMAP持久设计的状态图，以及显示了根据本发明的实施例的OMAP用户通知设计的状态图。

[98]图66显示了根据本发明的实施例的OMAP屏幕调色板。

[99]图67是显示了根据本发明的实施例的OMAP屏幕转换的状态图。

[100]图68显示了根据本发明的实施例的OMAP主菜单的布局。

[101]图69显示了根据本发明的实施例的从来源角度来看的OMAP支付屏幕流程。

[102]图70显示了根据本发明的实施例的从目标角度来看的OMAP支付屏幕流程。

[103]图71显示了根据本发明的实施例的从源-请求角度来看的OMAP请求支付屏幕流程。

[104]图72显示了根据本发明的实施例的从目标-接受角度来看的OMAP请求支付屏幕流程。

[105]图73显示了根据本发明的实施例的其中目标拒绝请求的OMAP请求支付屏幕流程。

[106]图74显示了根据本发明的实施例的其中源和目标两者都接受请求的OMAP请求支付屏幕流程。

[107]图75显示了根据本发明的实施例的其中源和目标两者都拒绝请求的OMAP请求支付屏幕流程。

[108]图76显示了根据本发明的实施例的OMAP余额屏幕流程。

[109]图77显示了根据本发明的实施例的OMAP历史屏幕流程。

[110]图78显示了根据本发明的实施例的在源位置的OMAP设置屏幕流程。

[111]图79显示了根据本发明的实施例的未知移动ID的OMAP的屏幕流程。

[112]图80显示了根据本发明的实施例的其中请求失败的OMAP系统异常屏幕流程。

[113]图81到86显示了用于进行个人之间的支付的移动电话应用程序的用户屏幕和流程。

[114]图87和88显示了根据本发明的实施例的用于提供离线支付系统的体系结构。

[115]图89是根据本发明的实施例的用于在移动设备上进行实时和离线两种金融交易的移动设备的组件的方框图。

[116]图90显示了根据本发明的实施例的MCA的J2ME应用程序基础架构。

[117]图91显示了根据本发明的实施例的应用程序(MCA)初始化和屏幕序列图。

[118]图92显示了根据本本发明的实施例的屏幕序列类。

[119]图93显示了根据本发明的实施例的EWP J2ME同步服务调用。

[120]图94显示了根据本发明的实施例的与服务器的异步交互或未经请求的通知。

[121]图95是带有标识模块的典型的移动消费类通信设备(蜂窝电话)的表示。

[122]图96是根据本发明的一个实施例的连接到IM的IM适配器和可编程处理单元的布局的方框图；

[123]图97显示了图96的IM适配器如何插入到蜂窝电话的IM插槽中的布局；

[124]图98显示了图96的布局如何翻转过来，以便可以存储在蜂窝电话内。

[125]图99是显示了根据本发明的实施例的图96布局的电连接的方框图。

[126]图100是具有本发明的优点的图96布局的方框图，带有USB连接以便笔记本电脑与无线通信网络进行通信。

[127]图101是根据本发明的实施例的图96中的可编程处理单元中的一些软件元件的表示。

[128]图102是根据本发明的一个实施例的移动消费类通信设备和网络服务器之间的音频信道通信的方框图表示。

具体实施方式

[129]在此对本发明的实施例的描述中，提供了很多具体细节，如组件或方法或两者的示例，以便于对本发明的实施例进行全面的理解。然而，本领域技术人员应认识到，可以在没有一个或多个具体细节的情况下来实施本发明的实施例，也可以利用其他设备、系统、组件、方法、部件等等，以及这些东西的组合来实施。在其他情况下，没有具体地显示或详细描述已知的结构、材料、或操作，以避免使得本发明的实施例的某些方面变得模糊。

[130]在特定实现方式中，本发明涉及移动支付平台和服务。本发明的实施例包含了一个支付平台，该支付平台提供了供个人或商家使用他们的移动设备访问诸如借记帐户之类的帐户以便进行付款的快速，简便的方式。进一步的界面包括IM、Web，以及应用程序小部件。其他帐户可以包括DDA或信用卡帐户。帐户也可以是没有卡与其关联的储值帐户。本发明的另外的实施例涉及各种合作伙伴，包括移动电话运营商、全国性的品牌商家，以及金融服务提供商，连同支付平台，该支付平台提供供个人使用他们的移动设备进行付款的快速，简便的方式。

[131]图1显示了本发明的系统的方框图，用于进行价值交换交易，包括以特定实现方式实现的，移动的个人之间支付和交易，移动的个人与商家的支付交易，以及移动银行。应用程序服务器107连接到网络109。虽然只显示了一个应用程序服务器，但是，在本发明的系统中，可以有任意数量的应用程序服务器。这样的应用程序服务器可以在单一服务器机器上运行，也可以在许多服务器机器上运行。随着应用程序服务器上的负载增大，通常，将使用更多的机器来处理和响应增大的负载。

[132]商家的界面112和用户界面116也连接到网络。此网络可以是传输数据的任何网络，包括，但不仅限于，因特网、以太网、普通老式电话业务(POTS)线路、公共电话交换网(PSTN)、ISDN、DSL、同轴电缆、光纤、卫星、蜂窝式、有线、无线、固定线路、串联、并联，以及许多其他形式，以及它们的组合。用户界面可以处理任意数量的用户，如用户A、用户B，以及最多用户n，其中，n是任何正整数。商家界面也连接到应用程序服务器。类似于用户界面，可以有任意数量的商家连接到应用程序服务器。

[133]在应用程序服务器上，有一个也可以连接到商家界面的支付处理器119。金融机构界面123连接到应用程序服务器和支付处理器。可以有任意数量的金融机构连接到应用程序服务器。应用程序服务器也可以包括数据库127。或者，数据库可以位于与应用程序服务器分开的服务器上，应用程序服务器通过网络或其他连接可以访问它。金融机构也连接到数据库。数据库可以包括应用程序服务器可以管理的记录系统130和虚拟合并帐户134。金融机构可以管理合并帐户138。因此，在金融机构中，可以与合并帐户分开地管理记录系统和虚拟合并帐户。

[134]本发明的系统可以包括图中所显示的任意数量的元件。系统也可以包括其他未显示的元件。某些元件可以被分成单独的块，或者，某些元件也可以与其他元件相结合(例如，两个块合并到单一的块中)。另外，也可以用其他未显示的元件代替某些元件(例如，用一个不同的块替换一个块)。

[135]在操作中，本发明的系统用于帮助在用户之间以及用户和商家之间进行金融交易。在一种实现方式中，用户能通过使用诸如移动电话或智能电话之类的移动设备来启动交易。此外，交易的目标可以是具有能够访问移动支付系统的移动设备的人。

[136]在一种实现方式中，这些金融交易的资金来源可以是应用程序服务器(有时可以被称为移动支付服务器或移动支付服务)的所有者或运营商。然后，用户(以及商家)将能够从移动支付服务加载或卸载资金。这些资金可以是任何来源，包括现金、支票，在线支付解决方案，电汇资金转帐、支票帐户、储蓄帐户、存款单、反向抵押贷款帐户、经纪人帐户、红利、证券、对冲基金帐户、信用卡、借记卡，或任何金融票据，或这些东西的任何组合。

[137]在其他实现方式中，资金来源是可由用户通过移动支付服务器访问的金融机构。如果需要，资金可以在各金融机构之间转移。例如，用户A可以向用户B或商家汇款，各方在不同的金融机构有存款。移动支付系统将有助于各个机构之间的转帐，并相应地通知各方。

[138]图2显示了本发明的特定实施例的软件体系结构。此方框图显示了可以在应用程序服务器上实现的特定体系结构的层。层包括用户Web应用程序容器203、支付系统容器206、持久层209，以及关系数据库管理系统(RDBMS)层212。

[139]在特定实现方式中，用户Web应用程序容器和支付系统容器可以基于由BEA Systems，Inc.出品的WebLogic。持久层可以基于Hibernate。关系数据库管理系统可以使用Oracle数据库。然而，在其他特定实现方式中，也可以使用其他供应商的系统。例如，本发明的系统可以包括开放源代码。

[140]在用户Web应用程序容器中，有针对不同类型的客户端的接口的表示层。所提供的接口的一些示例包括SMS网关、电话应用程序网关、万维网服务网关、Web应用程序页面网关，以及Web应用程序框架网关。电话消息编解码器将诸如SMS或电话之类的传入的或传出请求或两者转换为系统或客户端特定的消息。本发明的体系结构可以包括任意数量的这些界面。

[141]支付系统容器包括到外部金融或安全系统、邮件服务器以及消息传送服务的连接器。还有业务逻辑接口和支付系统业务逻辑。服务客户端可以通过业务服务网关来调用业务服务。网关实现方式可以使用EJB或其他技术。

[142]本发明的系统可以包括图中所显示的任意数量的元件。系统也可以包括其他未显示的元件。某些元件可以被分成单独的块，或者，某些元件也可以与其他元件相结合(例如，两个块合并到单一的块中)。另外，也可以用其他未显示的元件代替某些元件(例如，用一个不同的块替换一个块)。

[143]支付系统基础架构—技术环境

[144]本发明的一个方面是移动支付系统或服务。本申请讨论了单个组件和元件的许多特定实施例和实现方式，这些实施例和实现方式的变化和修改，以及它们的组合。本发明的系统可以包括所讨论的变化或特定实现方式中的任何一种，单独地或以任何组合的形式。在本申请中，提供了移动支付系统的特定实现方式的示例，此特定实现方式是Obopay系统。Obopay系统只是移动支付系统的实现方式的示例，用于比较轻松地描述本发明的各个方面。本发明包含了许多移动支付系统实现方式，不仅限于所描述的特定实现方式。

[145]图3显示了本发明的特定实现方式。图3显示了根据本发明的实施例的强健的技术环境300，包括移动客户端服务器平台302、可扩展的硬件环境304，以及银行集成306。

[146]平台302是提供安全性、通信、总帐、货币，欺诈和报告，以及管理的支付系统基础架构的核心。移动客户端应用程序(MCA)在J2EE支付服务器上运行，这是许多银行喜欢的技术。传入和传出的交易请求通过HTTP或万维网服务命令来进行处理。欺诈检测、交易数据库，以及银行集成构成了整个画面。

[147]应了解，由于本发明的无所不在的特征，平台302包括许多不同的实现方式。例如，平台302可以包括其中有多个服务器连接到存储设备的网络的服务器场。在其他实施例中，平台可以作为提供负载平衡和冗余的多个数据中心来实现。

[148]支付系统基础架构—平台302的硬件环境

[149]支付系统基础架构基于提供强健的故障转移功能的水平方向可扩展的，群集化的，可缩放的硬件环境。基于Linux的操作系统支持瘦客户端应用程序—诸如Microsoft

Internet Explorer、Netscape、Opera和Mozilla Firefox之类的最著名的浏览器。操作系统还支持胖客户端应用程序。在一种实现方式中，在移动客户端平台上使用了Java 2平台，Micro Edition(J2ME)和Microsoft.NET。体系结构是可轻松地配置的，以根据需要，可以用于其他胖客户端应用程序。

[150]可以与系统连接的客户端的示例包括移动电话、智能电话、个人数字助理设备、笔记本电脑、台式计算机，以及许多其他设备。客户端可以通过通信网络连接到系统。此网络可以是无线的，也可以是有线的。在特定实现方式中，网络是无线的，客户端设备是移动设备。

[151]通信网络可以由许多互连的计算机系统和通信链路构成。通信链路可以是硬连线的链路、光链路、卫星或其他无线通信链路、波传播链路，或任何其他用于传递信息的机制。可以使用各种通信协议来在各种系统之间进行通信。这些通信协议可以包括TCP/IP、HTTP协议、无线应用协议(WAP)、供应商特定的协议、自定义协议等等。在一个实施例中，通信网络是因特网，而在其他实施例中，通信网络可以是任何合适的通信网络，包括局域网(LAN)、广域网(WAN)、无线网络、内部网、私用网络、公共网络、交换网络、SMS消息网络、移动电话网络、蜂窝电话网络、以太网，以及这些网络的组合，等等。

[152]网络可以是有线网络(例如，使用铜线)、电话网络、分组网络、光网络(例如，使用光纤)，或无线网络，或这些网络的任何组合。例如，可以使用无线网络，使用诸如Wi-Fi(IEEE标准802.11、802.11a、802.11b、802.11e、802.11g、802.11i，以及802.11n，仅举几个例子而已)之类的协议，在本发明的系统的计算机和组件(或步骤)之间传输数据及其他信息。

[153]在一个实施例中，用户通过诸如智能电话或移动电话之类的便携式计算设备与系统进行连接。计算机系统可以包括显示器、机壳、小键盘，以及指示设备。在机壳内，可以有诸如处理器、存储器、大容量存储设备等等之类的熟悉的计算机组件。可以有单个处理器，也可以有多个处理器。处理器可以是多核处理器。

[154]可以与计算设备连接的大容量存储设备的一些示例包括快闪及其他非易失性存储器、快闪驱动器、闪卡(例如，SD卡)、大容量磁盘驱动器、软盘、磁盘、光盘、磁光盘、固定盘、硬盘、CD-ROM、可记录的CD、DVD、可记录的DVD(例如，DVD-R、DVD+R、DVD-RW、DVD+RW、HD-DVD或蓝光光盘)、带蓄电池后备电源的易失性存储器、磁带存储器、读取器，以及其他类似的介质，以及这些介质的组合。

[155]在一个实施例中，本发明是由计算设备执行的计算机软件。计算设备可以是客户端设备或服务器设备，或这些设备的组合。本发明的计算机实现的或计算机可执行的版本可以使用计算机可读取的介质来实施，存储在计算机可读取的介质中，或与计算机可读取的介质关联。计算机可读取的介质可以包括用于向一个或多个处理器提供指令以便执行的任何介质。这样的介质可以呈现许多形式，包括但不仅限于，非易失性、易失性，以及传输介质。非易失介质包括，例如，快闪存储器，或光盘或磁盘。易失性介质包括静态的或动态的存储器，如高速缓冲存储器或RAM。传输介质包括同轴电缆、铜线、光纤线路，以及以总线形式提供的线路。传输介质还可以呈现电磁、无线电频率、声波或光波的形式，如在无线电波和红外线数据通信的过程中生成的那些。

[156]例如，本发明的软件的二进制，机器可执行的版本可以存储在或驻留在RAM或高速缓冲存储器中，或存储在大容量存储设备中。本发明的软件的源代码也可以存储或驻留在大容量存储设备中(例如，硬盘、磁盘、磁带或CD-ROM)。作为进一步的示例，本发明的代码也可以通过线路、无线电波，或通过诸如因特网之类的网络进行传输。例如，可以将本发明的应用程序下载并安装到电话上。在安装之后，电话的用户可以运行该应用程序，并向另一个用户汇款。

[157]计算机软件产品可以以各种合适的编程语言中的任何一种进行编写，如C、C++、C#、Pascal、Fortran、Perl、SAS、SPSS、JavaScript、AJAX，以及Java。计算机软件产品可以是带有数据输入和数据显示模块的独立应用程序。或者，计算机软件产品可以是类，可以作为分布式对象而实例化。计算机软件产品也可以是诸如JavaBeans(来自Sun Microsystems)或Enterprise Java Beans(来自SunMicrosystems的EJB)。

[158]系统的操作系统可以是Microsoft Windows

系列操作系统(例如，Windows 95、98、Me、Windows NT、Windows 2000、Windows XP、Windows XP x64 Edition、Windows Vista、WindowsCE、Windows Mobile)、Linux、HP-UX、UNIX、Sun OS、Solaris、Mac OS X、Alpha OS、AIX、IRIX32或IRIX64中的任何一种。也可以使用其他操作系统。Microsoft Windows是MicrosoftCorporation的商标。

[159]在一个实施例中，在一个Web浏览器在设备上执行的情况下，用户通过诸如因特网之类的网络访问万维网(WWW)上的系统。Web浏览器用于下载各种格式的Web页面或其他内容，包括HTML、XML、文本、PDF、以及postscript，并可以用来向系统的其它部件上传信息。Web浏览器可以使用统一资源标识符(URL)来标识Web上的资源，使用超文本传输协议(HTTP)在Web上传输文件。

[160]平台302包括服务器308，用于处理与帐户持有人的交互，并维护交易记录。服务器308还提供到由商业合作伙伴所提供的增值服务的链接。服务器308利用交易数据库309，该数据库优选情况下包括数据存储网络。服务器308使用从交易数据库309获得的信息(如帐号、余额信息等等)，来管理与商业销售点(POS)终端311进行通信的支付处理器310。商家可以使用POS终端311来进行金融交易，如向帐户持有人的借记卡添加资金。商家也可以与支付服务器302建立单独的链接，以用于结算目的。

[161]结算引擎处理闭环系统内的交易，该闭环系统将实时地进行结算。用户的帐户和商家的帐户将同时更新。因为大多数商家也可以充当加载代理，因此，商家将在他们的帐户中带有余额。结算引擎将主要用于将预置的美元金额或通过最低限度的美元金额转帐到商家持有的外部银行帐户。

[162]由于能够从一个注册的帐户持有人向另一个注册帐户持有人划拨资金，结算引擎便于个人之间的(P2P)交易。

[163]平台302进一步包括欺诈检测系统312，用于跟踪从每一个金融交易中提取的信息。这样的欺诈检测系统是已知的，常常在使用信用卡时用于监视欺诈行为。风险由一般规则引擎进行控制(参见图3)，该引擎应用限制，并从风险的角度确定请求的交易的可接受性。

[164]可以挖掘为每一个金融交易收集的信息，供商家以及消费者增值应用程序、商业监视应用程序、系统操作应用程序和安全监视应用程序使用，如313所显示的。

[165]为说明，销售引擎从参与的商家向帐户持有人提供了赠券或折扣。此引擎还控制即时赊帐的使用，以奖励注册。

[166]货币兑换模块用于国外业务，闭环支付系统中的价值度量需要转换为其他货币。该模块还将用于控制外汇兑换。

[167]病毒式引擎提供向未注册用户汇款的能力。此模块允许帐户持有人汇款，还向收款人发送一则消息，说明为他们保留了一笔资金，前提是他们要进行注册。

[168]漫游功能提供了对等伙伴与商家的交易环境，其中，商家将使用移动电话来接收资金，商家不能访问通常用于信用卡或借记卡接受的终端。本发明的一个优点是由于不接受现金，资金有保证，不像支票那样，是安全的，还提供即时验证，这是对于没有终端的信用卡购物是不可行的。

[169]银行合作伙伴集成

[170]交易数据库308直接与合作银行维护的合并银行帐户306集成在一起。所有资金都存放在此帐户内，虽然商家可以通过ACH转帐或通过直接的API与他们的银行的直接DDA集成或通过ATM网，将他们的资金从他们的预存款贷记帐户转帐到其他帐户。应了解，可以有一个以上的合作银行，以便每一个帐户都可以在一个以上的银行链接到合并银行帐户。由于平台302知道每一个帐户的可用余额(不管银行合作伙伴的数量是多少)，当进行同业银行间的结算时，没有资金不可用的风险。

[171]由于适用于销售合作伙伴，包括移动运营商、全国性品牌商家和金融服务提供商，如较大的银行和信贷协会，支付系统基础架构利用现有的移动基础架构和和消息传送技术，以提供低成本的，普遍地可访问的金融服务。在一种实现方式中，本发明的系统提供了银行之间的互操作性。在合并帐户和作为个人帐户持有的任何持卡者的帐户之间也有互操作性。

[172]移动服务提供商合作伙伴

[173]通过给用户提供数字支付解决方案，移动服务提供商可获得增量收益，以及更大的数据流量，以及竞争优势。与其他支付系统不同，本发明可以提供给提供商的整个用户群体，因为除可下载的应用程序之外，它还可以使用SMS或移动因特网服务(例如，WAP)。

[174]此外，帐户持有人可以通过他们的服务帐户支付他们的帐单或者到期支付(top-off minute)。这对没有其他金融服务可用的帐户持有人特别有用。

[175]商家合作伙伴

[176]传统上接受信用卡、借记卡、支票，以及现金的各种商家将会接受移动个体化支付转帐基础架构，由采用成本较低。商家还有机会为处理预存款帐户交易，如帮助帐户持有人向他们的帐户中添加资金，而获得佣金收入。大多数商家也可以提供少量的现金退回，类似于当今使用的借记卡模式。

[177]本发明的移动支付服务的特定实施例具有移动P2M扩展和万维网服务。这些都可使商家轻松地接受来自用户或者来自移动电话或者或者网站的支付。它们也可以帮助商家降低接受交易的成本，扩大他们的用户的范围。

[178]银行合作伙伴

[179]银行现在可以“移动”他们现有的用户群体，因为可以快速访问他们的帐户，并能够进行帐户持有人与帐户持有人之间的支付。跨银行之间的交易也是可以的。利用此合作伙伴关系，银行也可以获得以前服务起来太昂贵的消费者。不会产生建立银行并遵循严肃的管理制度的成本，成员银行中的合并帐户，处理正面的总帐，向其合作银行，或代表其合作银行，报告净部位并允许银行进行最终结算。这将适应政府的规章，并允许与银行环境积极的共存。

[180]通过使用合作银行和伴随的银行帐户，支付系统基础架构被设计为只要有可能，增强帐户持有人的现有的银行帐户，还在必要时充当单独的帐户。在为帐户持有人委托保管的商业银行帐户中维护了由单个预存款贷记帐户代表的所有资金。在每一个工作日结束时，所有帐户的合计的余额将等于银行余额。在二十四小时的时间段内产生的所有交易将在该时间段内进行结算。帐户就像带有现金的钱包一样，余额会立即变化。换句话说，本发明不充当其中可以由第三方出示金融工具的活期存款。例如，帐户持有人将不能够发出诸如支票之类的即期工具。结果，将不会有在未来的日期进行结算的待办交易。

[181]在本发明的特定实现方式中，借记卡帐户不由移动支付服务提供商保留在合并帐户中，而是保留在直接的银行合作伙伴那里的单个借记卡帐户中。移动支付服务提供商为无卡的用户将资金保留在合并帐户中，放在银行委托保管。

[182]操作方法

[183]在本发明的一个实施例中，在购物之前，帐户持有人向预存款贷记帐户中添加资金。可以通过使用移动电话或另一个电话，通过利用因特网可访问的网站或通过联系客户服务代表，利用交互式语音响应(IVR)向位于合作伙伴那里的预存款贷记帐户添加资金。在一个实施例，用户能通过ACH或ATM网络，建立直接储蓄链接或将一个帐户链接到银行帐户。资金可以从位于金融服务提供商合作伙伴(如金融机构)那里的现有帐户转帐，或通过向预存款贷记帐户(在参与的商家或其他第三方)存现或出示支票。然后，帐户持有人可以通过他们的移动设备访问这些资金，以进行付款，他们也可以从其他人那里接收支付，汇到它们的帐户中。在其他实施例中，资金可以从指定的信用卡帐户转帐到预存款贷记帐户中。

[184]在另一个实施例中，来自每一个帐户持有人的资金被合并在单一的金融机构中，每一个帐户持有人都在合并帐户中有等于存放的资金减去转帐到另一个帐户再加上从其他人那里接收到的资金的资金总数的利息。帐户持有人可以从合并帐户中提取一些或全部他们的可用资金。

[185]在另一个实施例中，每一个帐户持有人都可以在任何金融机构设立预存款贷记帐户，并间接地访问该帐户以划拨资金。如此，帐户持有人不限于带有在特定金融机构中的合并帐户中维护的资金的借记卡。相反地，帐户持有人可以访问他们选择的金融机构中的借记卡帐户。

[186]在另一个实施例中，信用卡帐户被指定为主要帐户，每当借记卡帐户中的资金下降到或低于某一个选定金额时，现金预付被移动到预存款借记卡帐户中。

[187]在再一个实施例中，金融交易是在个人之间进行的，每一方都通过电话号码和密码(例如，个人标识号，PIN)来进行标识。或者，金融交易也可以通过用户名和密码来进行标识。在其他实施例中，参与交易的至少一方通过条形码来进行标识。条形码可以显示在诸如移动电话的屏幕之类的显示器上，并由大多数现代的移动设备上具有的照相机进行检测。条形码可以打印在设备上，也可以以别的方式附着于移动设备上。

[188]在一个特定实施例中，驻留在移动电话上的被称为移动客户端应用程序(MCA)只要求帐户持有人拥有移动电话号码和预存款贷记帐户。可选地，信用卡或支票帐户可以作为资金来源而被访问。优选情况下，不需要诸如销售点终端之类的额外的硬件或因特网接入。一旦注册，帐户持有人拥有唯一帐户持有人标识号码(PIN)，以验证所有交易。在进行注册时，帐户持有人输入他们的移动电话号码，服务器将移动客户端应用程序推到他们的电话中。一旦安装了移动客户端应用程序，帐户持有人就可以开始使用移动电话来进行金融交易了。另一个选项是，用户使用该用户的移动因特网浏览器访问特定URL(例如，get.obopay.com)，浏览器将开始移动应用程序的下载进程，来下载该应用程序。

[189]帐户持有人也可以选择将他们的帐户链接到由金融机构提供的借记卡或信用卡，这些卡可以世界范围内的数百万商家销售场所使用。此外，万一需要，它还允许帐户持有人使用ATM从预存款贷记帐户获取现金。

[190]对于帐户持有人来说，达成金融交易是无缝的。只需通过从配备移动客户端应用程序的移动电话向服务器发送一则消息即可。支付服务器验证每一个交易，并划拨资金，或响应帐户持有人的对帐户信息的请求。

[191]向服务器发送交易请求

[192]当帐户持有人从他们的移动电话发出交易请求时，信息被路由到移动运营商，如Cingular或Verizon或其他移动电话服务提供商。然后，信息通过安全的因特网连接，被路由到支付服务器。在备选实施例中，信息是通过诸如无线网络、POTS或其他可用的网络进行路由的。这种冗余是重要的，因为帐户持有人不限于单一访问路径以控制他们的帐户和进行金融交易。取决于帐户持有人的位置或其他情况，一个或多个通信路径可能不可用。然而，由于系统冗余，可能至少有一个通信路径可用，金融交易将可以完成。

[193]取决于帐户持有人的移动电话，金融交易请求是以两种方式中的一种进行传输的。如果帐户持有人拥有支持应用程序的电话，该电话允许通过基于Web的应用程序(HTTP或HTTPS)或诸如J2ME、.NET、.NET CF、WAP或SMS之类的移动应用程序或这些应用程序的任何组合来传输金融请求，传输直接进入服务器。一旦MCA与支付服务器建立连接，就发送请求消息。

[194]由于支持应用程序的设备当前只是当今所使用的设备的相对较小的部分，因此，支付服务器也通过短消息服务(也被称为SMS文本消息，或简单地，SMS)传输与接收，因为几乎所有的设备都支持SMS。在此情况下，财务数据被路由到移动运营商，然后，被路由到SMS综合器，该综合器实时地向支付服务器传输消息。

[195]SMS移动支付系统避免了与向手机中添加芯片关联的成本和问题。在SMS系统的操作中，金融信息是使用SMS文本消息进行发送的。尽管SMS文本消息适用于各种类型的蜂窝设备和某些其他类型的移动通信设备，如便携式数字助理或PDA，但是，SMS会暴露未加密的密码或个人标识号(PIN)，以及余额信息或有关最近的交易的细节。由于拥有电话的任何人都可以阅读SMS消息文件并立即知道如何访问另一个人的帐户和其他机密信息，因此，最好避免使用公共的SMS消息来传输PIN。相应地，在一个实施例中，本发明提供了在通过SMS文本消息启动金融交易。SMS消息以提供请求的交易的类型的关键字开始—PAY、REQUEST PAYMENT、BALANCE、TRANSFER或HELP。在一种实现方式中，“PAY”称为“SEND”，”REQUEST PAY”称为“GET”。

[196]在SMS消息包含表示希望从一个帐户持有人向另一个帐户持有人划拨资金的关键字的情况下，关键字将是pay或requestpayment(或，send或者get)。在关键字之后，输入金额，带有小数点，也可以没有小数点。在金额之后，输入目标电话号码(或短代码、电子邮件地址、驾照号码、或其他标识信息)。此信息可以从移动设备的电话号码簿获得。在电话号码之后，帐户持有人可以输入向对方显示的消息。在某些情况下，此消息可以是虚消息。在某些实施例中，帐户持有人可以输入补充的消息，用于记录的目的。

[197]一旦SMS消息被发送到支付服务器，就可以由帐户持有人输入PIN，并通过音频信道连接发送到支付服务器，以验证SMS消息。PIN是通过键盘输入的，可以是任何字母数字代码。然后，PIN被作为DTMF编码消息发送给支付服务器，其中，DTMF是指双音多频，是当电话的接触键被按下时电话公司接收到的信号。

[198]在服务器上，支付服务器通过SMS文本消息通信路径接收SMS消息，并通过音频信道接收PIN。对支付服务器的访问可以由帐户持有人进行，也可以作为对接收到SMS消息的响应由支付服务器作为“回叫”功能来启动。PIN可以作为DTMF编码的消息发送，以维护安全性，但是，在其他实施例中，PIN可以由帐户持有人说出，并由在支付服务器或专用于处理语音电话的另一个服务器(未显示)上工作的交互式语音识别软件模块进行转换。

[199]在一个实施例中，移动设备包括移动客户端应用程序。移动客户端应用程序要么由帐户持有人直接调用，要么响应移动设备上的SMS文本消息功能的激活而调用。MCA确定发送PIN的最佳方法。

[200]在一个备选实施例中，PIN由移动客户端应用程序进行加密，并包括在发送给支付服务器的后续的SMS消息中。支付服务器通过将电话号码和每一则消息的发送时间匹配来使消息关联。如果PIN是在与SMS消息相比在时间上较远的消息中发送的，则可以拒绝交易。如果只接收了两个消息中的一个，则可以拒绝交易。然而，如果接收并验证了带有金融交易细节的SMS消息(至少有关键字)和PIN代码，那么，进行金融交易。

[201]在一个备选实施例中，当有音频信道可用时，移动客户端应用程序调用将PIN编码为DTMF形式的模块。然后，DTMF由移动客户端应用程序沿着由移动客户端应用程序建立的音频信道连接发送到支付服务器。模块可以是基于小键盘的输入而生成适当的音调的Java API。

[202]在又一个备选实施例中，移动客户端应用程序在移动设备的显示屏幕上提供用户界面(UI)，引导帐户持有人进行金融交易。在此实施例中，通过自动插入关键字、金额、目标电话号码、密码，以及消息(如果有的话)，来引导帐户持有人完成构建SMS文本消息的过程。

[203]在又一个备选实施例中，SMS消息可以包括关键字、金额、目标电话号码和密码。此实现方式的缺点是，密码将对控制移动设备的任何人都可见。然而，本发明通过向帐户持有人发送消息，或通过帮助和FAQ信息指示用户从SMS日志文件夹中删除发送的消息，来控制此问题。这些指示也可以建议，当进行金融交易时帐户持有人应关闭记录传出的SMS消息的功能。

[204]下面的描述说明了使用SMS文本消息来使帐户持有人从任何支持SMS的移动电话或其他支持SMS的设备访问支付服务器。移动客户端应用程序不需要驻留在移动设备上，虽然如所讨论的，将移动客户端应用程序安装到移动设备上具有很多优点。

[205]在操作中，帐户持有人使用他们的电话上的现有的文本消息功能来向支付服务器发送文本消息。功能包括Pay(或Send)、Request Pay(或Get)、Balance、History和Help，通过使用这些功能中的任何一个作为关键字来调用这些功能。也可以有引荐或邀请选项，以允许用户邀请他人加入到系统中。引荐人或被引荐人，或两者，都可以被给予引荐奖金。帐户持有人在文本消息的正文中输入关键字连同补充信息，以构建发送给支付服务器的命令。对支付服务器的访问可以通过免费的电话号码、短代码或电子邮件地址来进行，所有的这些都向SMS文本消息系统标识支付服务器。短代码的一个示例是62729，被用作文本消息命令发送到支付服务器的目标电话号码。电子邮件地址的一个示例是sms@obopay.com，这是发送给支付服务器的SMS文本消息命令的电子邮件目标。

[206]要使用SMS方法向他人或商家进行支付，帐户持有人可以输入表A所显示的命令字符串。

[207]表A

关键字	PIN	目标移动电话号码	金额	消息(可选)
关键字	PIN	目标移动电话号码	金额	消息(可选)	pay	###	##########	#.##	Abed

[208]每一项与前一项之间都应该有间隔。在一种实现方式中，关键字不区分大小写。移动号码应该包括区号加移动电话号码，在移动号码中没有空格。帐户持有人可以在电话号码中输入引导1，或不输入。美元符号不需要与金额一起输入，但是应该允许输入。用户应该能够可选地与他们的支付一起包括一则消息。

[209]在一个备选示例中，通过话音呼叫在第二消息中发送PIN。要使用组合的SMS加音频信道方法向他人或商家进行支付，帐户持有人可以输入表B所显示的命令字符串。

[210]表B

关键字	目标移动电话号码	金额	消息(可选)
关键字	目标移动电话号码	金额	消息(可选)	pay	##########	#.##	Abed

[211]PIN通过话音通信信道—即，蜂窝网络、因特网或POTS—发送到支付服务器。

[212]当使用SMS方法或组合的SMS加语音方法对帐户持有人作出支付请求时，他们可以使用手动SMS文本消息系统来接受或者拒绝该请求。

[213]在支付服务器端，一个或多个数据中心将具有用于处理金融交易的系统。每一个数据中心都将包含PBX/ACD/VRU技术的组合，以允许多个同时的呼叫处理。可以使用VRU技术来提供可编程入站和出站DTMF支持。VRU可以连接到表示实际业务逻辑的企业J2EE系统和记录金融交易的记录系统。然后，J2EE系统可以与用于进行交易结算的实际银行集成。在一种实现方式中，为SMS安全性，有一次性的密码选项来作为选项。这是通过让用户发送交易而没有PIN来工作的，系统将给用户发送一系列问题让他们回答。

[214]使用移动客户端应用程序(MCA)进行交易

[215]向另一个帐户持有人或商家汇款既便捷又简单。本系统简化了批量支付，如从许多帐户持有人为一个慈善活动募捐，或同时从同一个帐户持有人进行多个交易。

[216]帐户持有人与帐户持有人(个人之间的)交易

[217]从一个帐户持有人向跨房间、跨城镇、或跨国家的另一个人汇款简单、方便、并且便宜。预存款的贷记帐户持有人可以向任何支持SMS的手机帐户持有人汇款，即使他们的移动设备上没有安装移动客户端应用程序或没有预存款的贷记帐户。如果收款人还不是帐户持有人，则收款人接收一则SMS文本消息，指出已经有人以他们的名称进行了转帐。为获得对这些资金的及时的访问，收款人可以进行注册，以获得他们自己的预存款的贷记帐户。此“病毒式”消息使得非帐户用户方便地自己成为帐户持有人。如果非帐户用户所使用的移动设备支持WAP或移动因特网浏览器，那么，注册可以通过电话立即进行。用户还具有使用Web、售货亭、亲自在商家合作伙伴那里或通过另一个设备预定该服务的选项。

[218]本发明的灵活性可提供在交易中选择和标识各方的新颖的方法。在一个实施例中，付款人可以通过他们的移动设备的小键盘键入电话号码或其他标识码。标识码可以是特殊的三、四或五位“短代码”，由移动服务提供商转换为特定帐户。例如，如果帐户持有人希望下载由诸如CBS电视网之类的电视网提供的电视节目，帐户持有人可以键入227的短代码，支付给该网络，以获得所希望的内容。短代码可以使用任何字母数字字符。此实施例要求，某些方面获取短代码，以鼓励用户访问他们的服务。

[219]在备选实施例中，资金的收款人可以通过从移动设备上的地址簿功能中选择的电话号码来进行标识。如此，没有必要单独地输入电话号码。在一种实现方式中，使用托管的地址簿，用户将利用服务设置他们的地址簿，然后，他们将通过所使用的任何设备使用该地址簿。要起初填充托管的地址簿，系统可以进入诸如Outlook、电话个人信息管理器(PIM)地址簿之类的第三方地址簿，或诸如Plaxo之类的第三方服务的界面。

[220]在又一个备选实施例中，付款人可以使用移动设备上的照相机功能来获取标识收款人的图像。图像的一个示例是条形码。

[221]在又一个备选实施例中，付款人由收款人通过获取的图像来进行标识。一个这样的获取的图像是显示在显示屏幕上或者可见地固定在移动设备外部的条形码。

[222]在又一个实施例中，无论是付款人还是收款人都可以通过诸如无线电频率识别设备(RFID)之类的近距离设备或近场通信(NFC)设备来进行标识。

[223]帐户持有人与商家

[224]帐户持有人可以以多种方式提取资金或在合作伙伴商家那里进行购物：

[225](1)移动电话与商家的移动电话；

[226](2)移动电话与商家销售点Web应用程序；

[227](3)预存款伙伴借记卡；

[228](4)通过向服务输入标识产品的代码字母数字显示用户希望购物的商家；

[229](5)通过从商家的电子购物手推车或Web或移动应用程序中选择进行支付；或

[230](6)通过从Web内或服务的电话应用程序内的目录中选择产品。

[231]在本发明的一个实施例中，移动设备与一个或多个银行帐户关联(支票、储蓄、信用卡、预存款，或合并帐户等等)，帐户持有人可以从一个帐户实时地向另一个帐户划拨资金，无需对服务中心进行任何访问，也无需任何因特网或计算机访问。优选情况下，帐户持有人可以选择某个帐户，从该帐户中获取资金，以实时进行购物。

[232]在本发明的另一个实施例中，帐户持有人贡献于银行合作伙伴持有的主要有息帐户。在任何时间，帐户持有人都可以提取他们的全部分担款项，没有任何损失。银行合作伙伴管理支付系统，并用累积的利息对该合作伙伴进行补偿。

[233]在另一个实施例中，使用NFC来在移动设备之间进行通信以使用本发明的基础架构进行金融交易。在再一个实施例中，使用NFC在移动设备与POS终端之间进行通信，以进行金融交易。

[234]有许多现有的产品，潜在地，有大量的新产品将受益于本发明。例如，诸如VoIP电话之类的任何支持因特网的电话设备都可以用来实施本发明，尽管可以固定在一个特定位置，不一定是移动的。在其他实施例中，可以使用电子邮件地址作为电话号码的补充或代替电话号码来标识参与金融交易的一方或多方。

[235]还应该理解，附图中所描述的一个或多个元件也可以以分离的或集成方式来实现，或者甚至去除或在某些情况下不工作，可以根据特定的应用场合来使用。

[236]对于移动、个体化支付转帐基础架构的营业收入模式

[237]运营移动个体化支付转帐基础架构，提供了产生收入来源的机会，无需对商家参与其中的交易收费高昂的费用。应该认识到，在移动或无线世界中，手机用户常常愿意购买一种小额包月费来获得某些服务。相应地，通过对汇款的每次交易收取小额的费用来产生收入。在一个示范性实施例中，对于选定金额(如$25)以下的交易，每次交易费用几个美分。为进一步说明问题，在备选实施例中，“每次交易”费用可以从$0.05到大约$0.10。可以收取从每次交易小于一个美分到每次交易几个美元。例如，费用可以每次交易从$0.00001到$10。

[238]费用可以向收款方和付款方两方面收取。或者，可以向汇款的帐户持有人收取费用。在其他实施例中，可以收取交易金额的百分比。在此实施例中，对于较高价值交易，如，举例说明，$25，收取费用。优选情况下，在帐户持有人最后批准和授权进行汇款之前，将费用通知，如果有的话，显示在批准屏幕上。在其他实施例中，对于小额交易，可以不收取费用。如此，小使用支付转帐基础架构进行小额购物时，没有“每次交易”费用。另一个运营模式是根据预订进行收费。

[239]不是支付“每次交易”费用，帐户持有人可以选择支付汇款和收款的每月包月费用。在此实施例中，没有“每次交易”费用。每月的收费可以变化，商家支付的费用比个人用户支付的费用要高一些(或者，在某些情况下低一些)。

[240]相应地，本发明有三种不同的收入来源模式。具体来说，(1)针对参与金融交易的一方或双方，评估“每次交易”。优选情况下，费用金额从大约一个美分到大约$0.15；(2)包月收费，每个帐户持有人都支付每月的服务费；(3)对于超过选定金额，如，作为说明，$50，的交易，较高的交易费用，对于所有其他交易，放弃费用；以及，(4)增值服务，如链接帐户服务，以自动地记录交易细节或帮助准备提交税务报表。服务可以获得持有资金的浮动收益或广告收入，这些可以适用于商家费用(例如，交易费用)。

[241]图4显示了本发明的系统的另一种实现方式。图4显示了在两个帐户持有人之间使用增值服务的一个实施例。作为示例，如果与移动设备401关联的帐户持有人启动一个向移动设备402的转帐操作，则向服务器平台403传输支付请求，如引用箭头404所示。支付请求可以包括支付事宜的可选描述。例如，帐户持有人可以对支付事项进行批注，以表示它是支出帐商品。描述可以从显示在移动设备401上的菜单中选择。或者，描述可以是与支付请求关联的语音或文本消息。

[242]在接收到支付请求时，服务器403从付款人的帐户向与移动设备402关联的帐户持有人的帐户划拨资金。通知管理合并帐户405的金融机构发生了该交易，如引用箭头406所示。如此，资金被添加到与移动设备402关联的帐户中，并从与移动设备401关联的帐户。然后，金融机构发送一则确认，如引用箭头407所示。

[243]服务器平台403还向移动设备402发送支付的通知，如引用箭头408所示。向移动电话401发送第二消息，指出已经进行了支付，如引用箭头409所示。如果移动设备402的用户不是帐户持有人，则可以开立新帐户，如引用箭头410所示。或者，用户可以从指定的ATM或与管理合并资金的金融机构关联的其他设施提取资金。

[244]然后，服务器平台403通过向帐户和记录保持服务411发送交易金额和交易的描述，记录交易，如引用箭头412所示。此后，帐户持有人可以要么通过移动设备401要么通过另一种因特网连接(未显示)，访问由帐户和记录保持服务411存储和组织的描述他们的购物情况的信息。

[245]为进一步显示帐单支付如何进入应收帐款系统，请看一个小企业，该小企业使用记帐程序(可以存储在个人计算机上)，打印出纸张发票，再将纸张发票寄给其客户。然后，客户必须支付给该小企业，这通常是通过支票进行的。因为纸张发票不能与支票一起发送，因此，该小企业需要将帐号与支票关联。如果帐号没有写在支票上，则时间会浪费在尝试查找支付与发票的副本的匹配。然后，小企业将支票存到他们的银行，并将数据手动输入到他们的应收帐款记帐程序中。显而易见，这种老旧的过程很慢，支持起来昂贵。

[246]然而，利用本发明，小企业只需要选择一个开发票选项，该选项将发票从记帐程序置于，例如，OFX格式，或可由记帐程序读取的其他导入/导出格式。然后，将此电子发票发送给支付平台(参见图3)。支付平台创建发送给客户的“Request Payment”消息。当客户批准发票的支付时，支付数据通过OFX被发回记帐程序的中，并将资金放入小企业的帐户中。OFX消息将该项记入记帐程序中。由于客户的应收帐款标识是他们的电话号码，因此，跟踪并记录简化得多。应该指出的是，资金一路上都可以有保证，没有退回的支票，或其他这样的问题。

[247]对于应付帐款交易，帐户和记录保持服务411发送OFX消息，通过例图，说明了一个雇员的成本报销(T&E)支付。资金被转帐到该雇员的帐户，并向他们的移动设备发送通知。优选情况下，本发明省略了手动向记帐程序中输入每一次交易的过程。

[248]图5显示了移动的个人之间支付的系统的进一步的实现方式。如上文所讨论的，本发明的特定实施例允许用户或客户端通过Web(例如，通过因特网浏览器)、WAP(例如，通过移动电话、智能电话、个人数字助理设备上的移动因特网浏览器)、SMS(例如，通过移动电话的文本消息)、IVR(例如，从电话按键理解用户的语音响应或音调的交互式语音响应系统)、WSDL(例如，可以通过诸如智能电话之类的移动设备进行访问的万维网服务)与移动支付系统连接。

[249]系统可以通过多个运营商中的任何一种，如Verizon、Cingular(AT&T)、Sprint、Nextel、Alltel、Virgin Mobile、Amp′dMobile、U.S.Cellular、T-Mobile及其他运营商与无线电话连接。本服务也可以与预存款电话连接。移动运营商的一些优点包括：基于收入共享模式的传输或基于预订。促进应用程序下载/购买。促进网络或数据使用。促进SMS使用。“Off bill”支付解决方案将帮助减轻惊人的“big bill”问题。

[250]移动支付系统允许为用户提供许多不同的金融服务。一些服务的示例包括信用卡加载、借记卡加载、自动票据交换所(ACH)加载、ACH卸载、个人之间的(P2P)支付、远程支付(RPAY)、病毒式、个人与商家之间的支付(P2M)，以及引荐。其他服务可以包括自动柜员机(ATM)网络加载和卸载，如通过NYCE、PLUS，或STAR ATM系统。系统也可以包括帐单支付集成，其中，用户可以支付帐单，如有线电视帐单、电费单、因特网服务帐单、电话费帐单、家政服务帐单，及其他帐单。

[251]加载帐户是指将资金转帐到移动支付系统上的帐户，在那里可以进行资金处理。例如，用户可以将资金从支票帐户或信用卡中加载到用户的移动支付系统帐户，该移动支付系统帐户可以由金融合作伙伴进行管理，或由移动支付系统的运营商进行管理。

[252]卸载帐户是指将资金从移动支付系统转帐到另一个帐户。例如，用户可以将资金从可以由金融合作伙伴进行管理，或由移动支付系统的运营商进行管理的用户的移动支付系统帐户卸载到支票帐户或信用卡中。

[253]加载和卸载资金可以以本申请中所讨论的任何一种方式进行，包括通过ACH、ATM，或信用卡或交换中心。ACH一般是最便宜的，但是，ACH通常是实时的，因为资金是在在一天结束时以批处理模式进行结算的。如此，当请求了ACH资金转帐时，实际资金将不会被转帐，也不会对移动支付系统可用，直到当天结束时。对于ATM和信用卡，资金转帐是实时的。ATM使用起来通常比ACH贵一些，但是比信用卡便宜一些。注意，ATM和ACH两者都可以用来访问用户的支票帐户。一般而言，信用卡在三者中使用起来是最昂贵的。在一种实现方式中，本发明的系统允许从这些网络中的任何一种网络加载和卸载。在另一种实现方式中，系统只允许从这些网络中的一个或多个加载和卸载，如只从ACH，只允许ACH和ATM，只允许信用卡，只允许ATM，只允许ATM和信用卡，或只允许ACH和信用卡。

[254]移动的个人之间支付系统进一步为提供了一个或多个金融合作伙伴提供了平台。这些合作伙伴可以包括让受方合作伙伴，如Pay by Touch(PBT)、Verisign，或其他；银行或其他金融机构合作伙伴，如纽约市、旧金山、圣何塞(加利福尼亚州)、伦敦、上海、香港，或东京银行，电子银行，NYCE；直接的合作伙伴(如共同品牌预存款卡)；预存款处理合作伙伴；以及ACH合作伙伴。移动支付系统也可以与销售点(POS)系统连接。

[255]可以有所讨论的任何数量的合作伙伴以及服务，以及任何的组合。例如，系统可以只有一个合作伙伴、可以具有两个合作伙伴，三个合作伙伴，或三个以上的合作伙伴。系统可以包括只提供供移动客户端访问的借记卡(即，无信用卡)的单一银行合作伙伴。系统可以包括提供供移动客户端访问的借记卡和信用卡的单一银行合作伙伴。系统可以包括两个或更多银行合作伙伴，一个提供供移动客户端访问的借记卡，另一个提供不同的借记卡。系统可以包括两个或更多银行合作伙伴，一个提供供移动客户端访问的借记卡，另一个提供不同的借记卡和信用卡。系统可以包括只提供供移动客户端访问的信用卡的单一银行合作伙伴。系统可以包括只提供供移动客户端访问的信用卡的单一银行合作伙伴。

[256]对于每一种类型的合作伙伴(例如，借记卡)，可以有多个这样的与移动支付系统或网络连接的合作伙伴实体。例如，系统可以与两个银行，银行A和银行B，或任意数量的银行合作伙伴连接。系统可以具有本申请中所描述的合作伙伴的任何组合。例如，系统可以具有直接的合作伙伴和银行合作伙伴，但没有预存款处理合作伙伴。系统可以只具有预存款处理合作伙伴。系统可以只具有直接合作伙伴。系统可以具有多个银行合作伙伴。

[257]每一个合作伙伴系统都可以具有不同的电子接口方案，移动支付系统将对于每一个合作伙伴使用适当的应用程序编程接口(API)进行通信。本发明的系统允许金融合作伙伴(例如，银行合作伙伴、卡合作伙伴)方便地集成到移动及其他消费者合作伙伴(例如，移动电话运营商)。

[258]在系统的特定实现方式中，让受方合作伙伴具有结算帐户。银行合作伙伴具有合并帐户和往来帐户。直接合作伙伴具有合并帐户和往来帐户。预存款处理合作伙伴具有合并帐户和往来帐户。ACH合作伙伴具有结算帐户。移动支付系统可以提供合并帐户管理、跨银行结算和资金管理，以及移动银行集成中的一个或多个。

[259]系统的资金通过所有合作银行的合并帐户的总和来表示。通过与移动支付系统的商务关系，移动支付系统促进了定期资金管理处理过程，以便合作银行的合并帐户保留的余额代表他们对移动支付系统客户群体的贡献加上“其他”移动支付系统资金的同意的百分比。客户的获取“路径”规定了给定合作银行的合并帐户余额(即，合作银行通过“他们的”路径获得的客户越多，他们的关联的合并帐户的余额就越高)。

[260]用户通常与特定金融合作伙伴(如特定银行)关联。在移动支付系统中，每一个用户都将具有一个用户资料，该用户资料具有该用户的设置。这些参数可以包括(1)参与的级别，(2)哪一个处理器(例如，哪一个金融合作伙伴)，(3)速度设置，(4)链接的帐户，或这些设置的任何组合。本系统可以在用户资料中包括任意数量的参数设置，比本专利申请中所描述的多一些，或少一些。

[261]本发明的系统适用于任意数量的不同的金融合作伙伴(例如，1、2、3、4、5、6、7、8、507、1001、2054、3096，或更多)，每一个合作伙伴都可以具有不同的API接口。在每一个用户资料中，“哪一个处理器”设置将指出用户与哪一个金融合作伙伴关联。当为该用户进行交易时，系统将知道把交易指向哪里(哪一个银行)以及使用哪一个API，以便用户的价值交换交易(通常是金钱交换)被正确地处理。

[262]“参与的级别”设置是用户将具有的特权或服务级别。“参与的级别”设置可以基于若干个因素，如当用户进行注册时提供了什么信息，用户在他的帐户中有多少钱，用户进行了多少次引荐，用户已经进行了多少次交易，或所交易的美元的总金额数。此配置文件的设置可以随着收集到新的信息而定期更新。用户的参与的级别名称的一些示例可以是“铜”、“黄金”、“银”，以及“白金”级别。可以使“参与的级别”对用户可见，并可以用来构建顾客忠诚度。在本发明的其他实施例中，可以隐藏参与的级别，或以别的方式对用户不可用。

[263]当向系统进行注册时，系统将给用户提供用户希望透露多少信息的选择。例如，用户可以选择透露用户的移动电话号码，然后，用现金给用户的帐户存放资金。这可能是开立帐户所需的最低限度。将给用户提供其他信息的选项，如电子邮件地址、信用卡号、社会保障号码(例如，用于信用支票)、支票帐户号码等等。在本发明的一种实现方式中，用户选择透露的信息越多，用户获得的参与的级别就越高。

[264]在一种实现方式中，对于参与级别的设置，用户可以是下列四种用户状态之一：(1)邀请、(2)注册、(3)验证，以及(4)高级。在其他实现方式中，可以有额外的状态。对于邀请状态，用户已经引荐，或给其发送了“病毒式”资金。“病毒式”是指汇款或接收汇款，其中，某一个用户是以前没有向系统进行注册的用户。“病毒式”用户也可以简称为非会员用户或未注册用户。“病毒式”是指本发明的移动支付系统的一个特征，该特征鼓励或允许当前用户与非会员用户进行交易。随着越来越多的用户进行注册并使用系统，用户将帮助扩散新闻，并带进另外的用户，在某种程度上，类似于病毒进行传播的方式。例如，为了使非会员用户收到资金，将鼓励非会员进行注册，成为会员。

[265]对于注册状态，用户已经输入基本信息，如确认的电话。电话可以通过系统拨打由用户在进行注册时所提供的电话号码来进行确认。此呼叫可以是自动化的或IVR型呼叫。对于用户进行注册，可以有奖励，如用户得到放进该用户的帐户中的现金(例如，$5)。奖励可以简称为引荐奖金，并可以是任何金额。引荐奖金可以只支付给引荐人，只支付给被引荐人，或向两者都支付。在此状态下，用户可以收到和索取资金。

[266]对于验证状态，用户的身份是已知的。用户提供地址或其他相关的联系信息。用户在验证状态下可以收到、请求、添加(即，加载)或提取(即，卸载)资金。

[267]对于高级状态，用户已经提供了用户的社会保障号码。在此状态下，例如，用户可以向特定银行合作伙伴进行注册，以接收卡。此卡可以是预存款的借记卡。在其他实施例中，卡可以是信用卡。用户将能够做验证用户所能够做的一切，外加能够立刻在接受卡的任何地方进行消费。可以通过一个或多个网络，包括Visa、MasterCard、American Express、NYCE、PLUS或STAR，或这些机构的任何组合，接受或使用卡。卡链接到用户的帐户。没有卡的用户可以叫做无卡用户，而有卡的用户可以叫做有卡用户。

[268]当进行注册时一个人可以获得验证的一些方式包括：对于人的信息，系统可以要求提供地址和驾驶执照号码。一种备选方案是要求提供地址和社会保障号码。可以对照诸如Equifax数据库之类的信用报告机构的数据库，核对该信息。对于链接的银行帐户，可以使用质询储蓄来对这些进行验证。例如，系统可以将任意数量的小额存款放入用户的帐户中。用户告诉系统，那些存款的金额，以获得验证。或者，用户能通过在线即时帐户验证来进行验证，其中，用户提供在线的屏幕姓名和密码。对于添加信用卡或借记卡，也可以使用质询储蓄来对这些进行验证。诸如Visa和MasterCard之类的一些卡也可以使用安全代码等等来进行验证。

[269]参与的速度是对帐户设置某些限制的一种设置。对帐户设置的限制的一些示例有：用户一天可以进行多少次交易，或在一次交易中最多可以转帐多少金额。可以有一些硬性限制和软性的限制。硬性限制将不会随第三方的干涉(如人更改限制)而变化。软性的限制可以随着用户的操作而变化。例如，在用户已经成为会员六个月之后，当用户的对于一些号码的前一限制少于五时时，可以自动地允许用户一天可以进行五次交易。

[270]通常，用户将不会知道参与速度的设置。然而，在某些实现方式中，可以告诉用户有关参与速度的信息，如信用额度或交易限制。

[271]链接的帐户是可以存储在用户的资料中的另一个功能。然而，本申请中所讨论的任何一个用户设置，或这些用户设置的组合，可以保存在单独的位置，不一定放在用户的资料中。链接的帐户是系统的一种功能，其中，用户的多个身份被集中到或统一到单一帐户中。对于用户，可以有一个锚定(例如，如帐号)，多个身份将与此锚定关联。这些身份可以包括多个电话号码、电子邮件地址，即时消息标识符，等等。用户将不必知道帐号或锚定，即可访问该帐户。用户将能够通过任何一个关联的身份访问用户的帐户。

[272]此外，在一种实现方式中，要向帐户添加身份，用户将证实每一个新的身份。这可以通过IVR回叫来进行，或在采用电话号码的情况下响应SMS消息。对于电子邮件，可以通过发送一个带有唯一URL或验证码(用户在我们的网页上以此作出响应)的电子邮件来进行。对于即时消息ID，可以通过响应IM来进行。

[273]用户的资料中可用的其他选项可以包括某些功能的首选项设置。可以由用户在任何时间通过访问帐户维护屏幕，来设置或修改这样的选项。此外，还可以询问用户在注册流程(参见下文)中是否启用或禁用选项。一个功能是自动接受和手动接受功能。当自动接受被打开时，汇往此会员的支付款项将自动地被接受。当手动接受被启用时，汇往此会员的支付款项需要手动地接受或拒绝。

[274]系统流程

[275]图6显示了在同业银行的个人之间的支付。此图显示了一个消费者A向另一个消费者B汇款，其中，这两个消费者都是同一个银行合作伙伴A的会员。本发明的移动支付系统将处理该交易。

[276]交易的基本流程是：(1)消费者A向移动支付系统发送支付请求。此支付请求可以通过此专利中所讨论的任何一种方式来提供。(2)移动支付系统更新移动支付系统的记录系统(SOR)中的T或交易记录中，以反映交易。这些交易记录是由移动支付系统进行管理的。(3)系统(例如，Obopay)将支付情况通知给消费者B。这可以通过电子通知、电子邮件、即时消息、SMS消息，或其他通知来进行。

[277]图7显示了跨银行个人之间的支付。此图显示了一个消费者A向另一个消费者B汇款，其中，这两个消费者是不同的银行合作伙伴的会员。消费者A具有银行A，而消费者B具有银行合作伙伴B。本发明的移动支付系统将处理该交易。

[278]交易的基本流程是：(1)消费者A向移动支付系统发送支付请求。(2)移动支付系统从合并帐户向往来帐户划拨资金。(3)移动支付系统从往来帐户向合并帐户划拨资金。(4)移动支付系统更新移动支付系统的记录系统中的T记录。(5)移动支付系统将支付通知给消费者B。(6)移动支付系统定期在合作银行之间进行结算。此结算可以以任何时间周期进行。结算可以不实时地进行，而是以批处理模式进行。例如，可以每隔24小时进行一次。周期不一定必须是相等的时间周期，而可以是不同的时间周期。

[279]图8显示了链接的帐户加载。此图显示了消费者利用另一个来源的资金向用户的移动支付系统帐户加载的情况。例如，用户可能希望从支票帐户或信用卡向用户的移动支付系统帐户中转移一些资金。

[280]此交易的基本流程是：(1)消费者A向移动支付系统发送“加载”请求，指出链接的信用或贷记工具。(2)(a/b)移动支付系统提交实时信用卡(CC/DDA交易(良好的资金)。(3)移动支付系统从往来帐户向合并帐户划拨资金。(4)移动支付系统更新移动支付系统的记录系统中的T记录。(5)移动支付系统定期进行资金管理。此管理可以以任何时间周期进行。例如，可以每隔24小时进行一次。周期不一定必须是相等的时间周期，而可以是不同的时间周期。

[281]信用卡加载的具体示例。从Web中，用户输入信用卡号，以将$300加载到用户的MPS卡中。MPS从Pay-By-Touch(PBT)获取$300的信用卡交易的授权。MPS向支持MPS卡的金融合作伙伴发送一则消息，启动从MPS信用卡帐户到用户的借记卡帐户的$300的个人之间的支付。将资金立即划入用户的帐户。PBT对信用卡交易进行结算，并向位于处理结算帐户的MPS的银行的MPS结算帐户转帐$300ACH。MPS向MSP信用卡主帐户发送$300ACH，以补充资金。

[282]图9显示了链接的帐户卸载。此图显示了消费者将资金从用户的移动支付系统帐户卸载到另一个帐户的情况。例如，用户可能希望从用户的移动支付系统帐户向用户的支票帐户、信用卡，或其他帐户转移一些资金。

[283]此交易的基本流程是：(1)消费者A向移动支付系统发送一则加载请求，指出链接的信用工具。(2)移动支付系统提交实时DDA交易(良好的资金)。(3)移动支付系统从合并帐户向往来帐户划拨资金。(4)移动支付系统更新移动支付系统的记录系统中的T记录。(5)系统定期进行资金管理。

[284]在特定实施例中，本发明涉及支付系统，具体来说，在特定实施例中，涉及使用移动电话进行支付的在线系统。

[285]需要能够通过移动电话进行钱或其他有价值的东西的交换及其他交易的在线系统。

[286]在个人之间的支付系统中，支付系统的现有的会员可以向非会员(也可以简称为未注册用户)进行支付，以希望非会员成为会员。支付系统的这种能力可以称为“病毒”，因为它以指数扩散方式促进新的会员注册。

[287]关于个人之间的支付系统，本发明提供了支付系统的现有的会员向非会员进行支付的能力，以希望非会员成为会员。支付系统的这种能力可以称为“病毒”，因为它以指数扩散方式促进新的会员注册。病毒功能的一些元件包括下列各项，没有按任何特定顺序列出。

[288](1)支付系统允许现有会员通过一些唯一标识符或“ID”向非会员汇款。此唯一标识符可以普遍地使用。这样的标识符的一些示例包括电子邮件地址、电话号码(例如，陆上通信线路、IP电话、移动电话、寻呼机或传真机)、社会保障号码、帐号、汽车牌照号码，即时消息用户名，及其他。标识符可以由用户选定，如非会员选择一个电话号码或电子邮件地址。

[289](2)支付系统通知现有的会员，他们即将要与其进行“汇款”交易的人是非会员，并给予现有的会员取消此交易的机会。

[290](3)在现有会员选择向非会员汇款的情况下，支付系统必须通过各种常见的通信机制(如电子邮件、语音，及其他)通知非会员，已经向他们汇了款。

[291](4)支付系统应该允许“被邀请”非会员接受或拒绝从现有会员尝试转帐的资金。

[292](5)如果被邀请的非会员决定从现有的会员接受资金，那么，支付系统应该提供让非会员通过常见的通信机制(如电子邮件、语音，及其他)进行注册的能力。

[293](6)为了完成病毒交易，支付系统最终将促进从现有的会员帐户向新的会员帐户转拨资金。

[294]下面是在支付系统内进行病毒式资金转帐的技术的多个实施例。

[295]实施例1A

[296]后续支付提醒。提醒现有的会员，在新的会员进行注册之后，进行支付。在下面的示例中，Obopay被用作特定支付系统的示例，但是，也可以使用其他支付系统。支付系统可以叫做任何名称。特别指出了obopay.com网站，但是，可以使用任何适当的网站、网站名称，或IP地址。此外，本发明也可以用于其他网络基础架构的环境中，而不只是因特网。

[297]1.现有会员用户A决定通过给B汇款来邀请非会员用户B加入，B必须通过注册为会员才能接收款项。

[298]2.用户A通过插入B的移动电话号码和美元金额，向B发送支付交易。系统最初不会区别向会员和非会员的支付。

[299]3.如果移动电话号码不是发往当前会员的，则用户A接收到下列消息，“注意：您的会非会员的支付待办。”

[300]4.用户A还接收到如下表述的电子邮件：“感谢您的引荐。”我们已经联系您的朋友并邀请他向我们的系统进行注册。”

[301]5.向B的汇款金额从A的帐户中划出，并被保留，等待B的注册。

[302]6.用户B接收到一则消息，说明A向他汇了款，B可以通过在obopay.com进行注册而获得资金。

[303]7.用户B在系统网站(例如，obopay.com)进行注册。

[304]8.在用户B成功地进行注册之后，B的帐户自动地被注入了A的转帐资金。

[305]实施例1B

[306]图10显示了根据如本发明的实施例1B所描述的技术的支付系统和个人之间的支付。

[307]1.现有会员用户A决定通过给B汇款来邀请非会员用户B加入，B必须通过注册为会员才能接收款项。

[308]2.用户A通过插入B的移动电话号码和美元金额，向B发送支付交易。系统最初不会区别向会员和非会员的支付。

[309]3.如果移动电话号码不是发往当前会员的，则用户A接收到下列消息，“注意：您的转帐已经发给非会员用户。您愿意我们邀请他们加入吗？是/否。”

[310]4.如果步骤3的回答是yes，则用户A还接收到如下表述的电子邮件：“感谢您的引荐。我们已经联系您的朋友并邀请他向我们的系统进行注册。”

[311]5.支付金额不会从用户A的帐户划出。

[312]6.用户B接收到一则消息，说明A已经邀请B加入系统，以便A可以给B汇款。

[313]7.用户B在系统网站(例如，obopay.com)进行注册。

[314]8.在B成功地进行注册之后，通知B，A希望给他汇款，B可以对该支付执行“Request Pay”。如果B同意，则给B显示一个预先填写的Request Pay交易，带有A的电话号码，以及原始支付金额。

[315]9.用户A接收到“Request Pay”，并同意该支付

[316]10.从A的帐户划出资金，并划入B的帐户。通知给B。

[317]实施例2

[318]个人预留资金病毒式—允许现有的会员留出资金，这是为“病毒式”支付预留的。例如，用户可以拨出用户的帐户中的一定数量的美元，以进行“病毒式”交易。这些资金将不会可用于“非病毒式”交易(例如，通过借记卡进行花费)。在一种实现方式中，用户能通过用户帐户维护功能更改预留的金额。

[319]实施例3

[320]会话病毒式—实时地出现完整的病毒生命周期，将沿途的其他“步骤”通知给双方。然后，最终的资金转帐只是两个会员之间的转帐。

[321]实施例4

[322]约定的病毒式—现有的会员承诺支付被邀请的会员(如果他们注册)。现有会员的资金将被预留，以便一旦被邀请的会员注册，进行后续支付。

[323]实施例5

[324]分离资金病毒式—支付系统，通过提供资金拆分，剌激现有会员，以进行病毒式支付，其中，支付系统通过固定的或相对金额，匹配支付金额。

[325]实施例6

[326]请求资金病毒式—不是现有的会员向非会员汇款，而是现有的会员从非会员请求汇款。

[327]本发明的实现方式可以包括上文所描述的功能中的任何一种。在本发明的系统中，可以分别地或与任何其他实施例相结合地实现上面的实施例。

[328]特定实现方式描述了使用移动电话号码作为用户的标识符。然而，对于每一个用户，可以使用任何标识符，如任何电话号码(例如，家庭电话号码、办公电话号码、IP电话电话号码、传真机或寻呼机)，电子邮件地址、即时消息用户名、社会保障号码、驾驶执照号码、会员号码、信用卡号、借记卡号码，或其他。

[329]讨论了电子邮件作为在用户之间发送消息的技术，但是，也可以使用其他通信技术，包括语音邮件、自动化语音消息、即时消息，或文本消息。用户A和用户B只作为系统可以具有的很多用户中的两个代表。本发明的系统可以具有任意数量的用户。

[330]图1显示了一个概述方框图，该方框图描述了利用本发明的两个或更多人之间的移动支付系统。在本发明的系统中，用户A通过唯一标识符或ID向用户B汇款。唯一标识符可以普遍地使用。示例包括电话号码(例如，陆上通信线路、IP电话、移动电话、寻呼机或传真机)、电子邮件地址、社会保障号码、帐号、汽车牌照号码，即时消息用户名，及其他。此标识符可以用来联络用户，独立于经过本发明的系统(例如，电话号码或电子邮件地址，可以直接联系用户，而不涉及本系统)。

[331]每一个唯一标识符都可以只与一个用户关联，以确保帐户和系统安全性。用户A也可以提供金融交易的细节，如要转帐的金额，或支付的形式，或这些细节的组合，如果请求验证帐户，则还应提供PIN号码。

[332]系统将用户A标识为会员，并可以检查PIN号码，验证帐户，并检查用户A的帐户的余额。在用户A的帐户没有足够的资金进行金融交易的情况下，系统可以向用户A发送一个电子通知，说明资金不足。如果用户A的帐户具有足够的资金进行交易，则系统还通过移动技术将待办的交易通知给用户B。由于用户A和B接收到的即时的电子通知，好像金融交易几乎即刻进行。

[333]系统可以允许用户设置有关交易的接受的首选项。如果用户B选定了自动接受设置(当用户在系统上进行注册时选定)，用于自动地接受支付，资金立即从用户A的帐户转帐到用户B的帐户。如果用户B选定了手动接受设置，则只有在用户B批准交易之后才转帐。系统也可以包括用户规定他们将只从指定的会员接受交易，或者相反，他们将不会从指定的会员接受支付的设置。

[334]如果在由系统设置的一定天数(如三十天)之后用户B还没有批准交易，则系统可以自动地取消交易。然后，系统可以向用户A和用户B两者发送电子通知，通知两者，交易已取消。用户B也可以具有拒绝交易的选项，在这样的情况下，可以通过电子通知，通知用户A，拒绝支付。

[335]在用户A具有足够的资金的情况下，用户B接受交易，从用户A的帐户划出该金额，并划入用户B的帐户。由于电子金融交易系统中的固有延时，交易可能被延迟。

[336]在本申请中呈现了一些流程的具体示例。然而，应该理解，本发明不限于呈现的特定流程和步骤。本发明的流程可以具有可能在本申请中不一定描述的另外的步骤，替换呈现的一些步骤的不同的步骤，较少的步骤或呈现的步骤的子集，与呈现的步骤的顺序不同的步骤，或这些情况的任何组合。

[337]此外，本发明的其他实现方式中的步骤可以不与所呈现的步骤完全相同。作为具体示例，采用的是用户B的移动电话号码作为唯一或电子标识符(ID)的。在本发明的其他实施例中，标识符不限于用户B的电话号码。在本发明的其他实现方式中，标识符也可以是用户B的即时消息用户名或电子邮件地址。

[338]在不偏离本发明的范围的情况下，流程中的可能的变化的另一个示例是，用户A和B在流程中的各种步骤中接收到的特定消息。在本发明的其他实施例中，这些消息可以不同于在本申请中特别指出的那些消息，或者，一些消息可以不发送，并且这些消息可以组合起来。

[339]图11显示了用于在带有卡的会员和未注册的用户之间进行交易的方法。此流程包括：(1)会员A以非会员B作为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标识交易源为会员，对帐户进行验证，检查余额，并检查PIN。(3)移动支付服务识别目标为非会员。(4)移动支付服务将支付通知给源会员A。(5)移动支付服务将支付通知给目标非会员B。(6)(a/b)移动支付服务从会员卡帐户中划出，并划入病毒式合并帐户。(7)(a/b)移动支付服务记录源会员划出交易，并记录目标病毒式划入交易。步骤6和7可以是异步的服务器端线程。这意味着，在一个实施例中，这些操作异步地进行。服务器请求操作，但是它们不一定由服务器本身执行，如此，操作的完成独立于调用方服务器的过程。

[340]图12显示了用于在没有卡的会员和未注册的用户之间进行交易的方法。该流程包括：(1)会员A以非会员B作为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标识交易源为会员，对帐户进行验证，检查余额，并检查PIN。(3)移动支付服务识别目标为非会员。(4)移动支付服务将支付通知给源会员A。(5)移动支付服务将支付通知给目标非会员B。(6)(a/b)移动支付服务从会员合并帐户中划出，并划入病毒式合并帐户。(7)(a/b)移动支付服务记录源会员划出交易，并记录目标病毒式划入交易。步骤6和7可以是异步的服务器端线程。

[341]图13显示了在一个无卡会员和另一个无卡会员之间进行交易的方法。该流程包括：(1)会员A为会员B发送“pay”请求。(2)移动支付服务标识交易源A为会员，对帐户进行验证，检查余额，并检查PIN。(3)移动支付服务识别目标B为会员，并对帐户进行验证。(4)移动支付服务将支付通知给源会员A。(5)移动支付服务将支付通知给目标会员B。(6)(a/b)移动支付服务记录会员A划出交易，并记录会员B划入交易。步骤6可以使用异步服务器端线程进行。

[342]图14显示了用于在一个有卡会员和另一个有卡会员之间进行交易的方法。该流程包括：(1)会员A以会员B作为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标识交易源A为会员，对帐户进行验证，检查余额，并检查PIN。(3)移动支付服务识别目标B为会员，并对帐户进行验证。(4)移动支付服务将支付通知给源会员A。(5)移动支付服务将支付通知给目标会员B。(6)(a/b)移动支付服务从会员A卡帐户中划出，并划入会员B卡帐户。(7)(a/b)移动支付服务记录会员A划出交易，并记录会员B划入交易。步骤6和7可以是异步的服务器端线程。

[343]图15显示了在一个有卡会员和一个无卡会员之间进行交易的方法。该流程包括：(1)会员A以会员B作为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标识交易源A为会员，对帐户进行验证，检查余额，并检查PIN。(3)移动支付服务识别目标B为会员，并对帐户进行验证。(4)移动支付服务将支付通知给源会员A。(5)移动支付服务将支付通知给目标会员B。(6)(a/b)移动支付服务从会员A卡帐户中划出，并划入会员合并帐户。(7)(a/b)移动支付服务记录会员A划出交易，并记录会员B划入交易。步骤6和7可以是异步的服务器端线程。

[344]图16显示了在一个无卡会员和一个有卡会员之间进行交易的方法。该流程包括：(1)会员A以会员B作为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标识交易源A为会员，对帐户进行验证，检查余额，并检查PIN。(3)移动支付服务识别目标B为会员，并对帐户进行验证。(4)移动支付服务将支付通知给源会员A。(5)移动支付服务将支付通知给目标会员B。(6)(a/b)移动支付服务从会员A卡帐户中划出，并划入会员B的卡帐户。(7)(a/b)移动支付服务记录会员A划出交易，并记录会员B划入交易。步骤6和7可以是异步的服务器端线程。

[345]图17显示了对未注册的用户进行注册的方法。该流程包括：(1)未来的会员A提交注册请求。(2)创建新的会员帐户。(3)对于新的会员，进行身份风险控制，并相应地更新帐户。(4)检查与新的会员关联的病毒记录。(5)(a/b)移动支付服务从病毒式合并帐户中划出，并划入会员合并帐户。(6)(a/b)移动支付服务记录源病毒式划出交易，并记录目标会员划入交易。(7)检查适用于新的会员的奖励。(8)(a/b)移动支付服务从奖励帐户中划出奖励金额，并划入会员合并帐户。(9)移动支付服务记录新的会员划入奖励金额。步骤5、6和7可以是异步的服务器端线程。

[346]图18显示了激活卡的方法。该流程包括：(1)会员A收到邮寄的卡，并拨打“移动支付服务”IVR，进行激活。(2)在IVR交互过程中，移动支付服务关闭无卡帐户。(3)(a/b)移动支付服务从会员合并帐户划出，并划入新的会员A个人卡帐户。(4)(a/b)移动支付服务记录会员合并帐户划出交易，并记录会员A划入交易。(5)移动支付服务系统向会员A发送关闭无卡活动声明电子邮件。步骤3和4可以是异步的服务器端线程。

[347]在一种实现方式中，系统处理近距离的电子支付，如通过使用NFC、蓝牙、RFID、红外光束、LED光束，或其他近场技术。一种情况可以是，会员A和B身体彼此靠近，他们希望进行电子支付。这可以是消费者与消费者或消费者与商家之间的情况。这可以是汇款、收款，或任何其他资金转帐情况。

[348]这样的交易的基本流程是：(1)A和B同意近距离电子支付交易。(2)B选择“准备好近距离收款”。设备查询PIN，B输入PIN，设备激活接收模式。(3)A选择“准备好近距离付款”。设备查询PIN，A输入PIN，设备激活付款模式。(4)A和B将设备放置在合适的近距离内。A和B只有有限量的时间执行此步骤，否则设备将超时。(5)A和B设备彼此识别，并向彼此传输支付信息。(6)A和B审查设备上的确认对话框，并选择“确认”。(7)支付交易开始。

[349]系统允许多渠道和跨渠道交易。具体来说，可以从任何一个可用渠道(例如，移动电话、即时消息、电子邮件、Web、借记卡、WAP、SMS、消息，或专用的移动电话应用程序)请求进行支付，交易可以是指向任何一个可用渠道，以任何组合。例如，某人可以从即时消息向移动电话，从Web向移动电话，从移动电话向即时消息，从WAP向即时消息，从即时消息向电子邮件，从电子邮件向移动电话，从电子邮件向即时消息，从Web向SMS，从SMS向电子邮件，或任何其他组合，请求进行支付。本系统也可以用于通过支付终端、交互式网站进行支付，通过电视为服务或媒体内容进行支付(例如，为由有线电视或卫星提供商提供的点播电影进行支付)，通过预存款电话，以及许多其他手段进行支付。例如，用户能通过即时消息支付给商家。本系统可以支持通过自动售货机、停车计时器、售货亭、自动收费公用电话、飞机票售票亭，以及许多其他手段进行支付。

[350]下面的流程A显示了在注册的用户(用户A)和未注册的用户(用户B)之间进行交易的一种实现方式。

[351]流程A

步骤	操作
步骤	操作	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有被识别为注册的用户，则A接收到下列消息：“您的请求已经被接受，将被处理。[tel #]，[value]，[trans #]请求待办的未注册用户。”	3
4		5	在A的帐户预留出该交易金额。
6	B接收到下列消息：“有一笔支付，待办，来自[tel #]，[value]，[trans #]请去系统网站注册。”	5	在A的帐户预留出该交易金额。
6	B接收到下列消息：“有一笔支付，待办，来自[tel #]，[value]，[trans #]请去系统网站注册。”	7	在B批准支付之前，A可以取消支付。倘若如此，将给A和B发送消息：‘支付已取消。[tel #]，[value]，[trans #]”如果在A启动交易之后并且在B批准支付之前已经过去30天以上，则交易自动取消。然后，将给A和B发送消息：‘支付已取消。[tel #]，[value]，[trans #]＂
	在30天过去之后，消除A的帐户中的交易金额的预留。	7
	在30天过去之后，消除A的帐户中的交易金额的预留。	8	B向移动支付系统进行注册。在系统上为B创建一个帐户。
9	在B成功地注册之后，通知B，说明A希望给B汇款。给B提供了一个画面，询问B是接受A的支付，拒绝A的支付，还是请求对A的待办交易进行更改。	8	B向移动支付系统进行注册。在系统上为B创建一个帐户。
9		10	如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”
11	如果B请求更改，则将给B呈现一个画面，B将能够协商或请求对A的交易的条款进行更改。如果B不请求更改，则进入步骤13。	10	如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”
11	如果B请求更改，则将给B呈现一个画面，B将能够协商或请求对A的交易的条款进行更改。如果B不请求更改，则进入步骤13。	12	如果B希望更改交易(例如，更改交易金额)，则向A发送一则有关提议的更改的消息。A将能够接受或拒绝B的提议的更改。
13	如果B接受来自A的支付，则系统检查A是否具有足够的资金来完成交易。如果没有，将给A和B发送消息：“资金不足。[tel #]，[value]，[trans #]”	12	如果B希望更改交易(例如，更改交易金额)，则向A发送一则有关提议的更改的消息。A将能够接受或拒绝B的提议的更改。
13		14	如果A有足够的资金，将给A发送消息：“支付已被接受。[tel #]，[value]，[trans #]”
15	从A的帐户划出交易金额，并划入B的帐户。	14	如果A有足够的资金，将给A发送消息：“支付已被接受。[tel #]，[value]，[trans #]”

[352]在步骤1中，用户A通过用户B的移动电话号码向移动支付系统标识用户B。在本发明的其他实现方式中，用户A可以通过其他手段，如用户B的电子邮件地址、即时消息名称，或其他唯一标识符，来标识用户B。这些标识符可以是电子标识标识符，可以是也许用于甚至在移动支付系统的环境外面标识B的标识符。换句话说，标识符不一定只有移动支付系统才有的(例如，帐号)。

[353]在特定实现方式中，移动支付系统不允许现有的注册的用户从未注册的用户请求进行支付。在另一个实施例中，用户可以从未注册的用户请求进行支付。

[354]在步骤2中，移动支付系统检查A的帐户是否具有足够的资金来完成交易。移动支付系统也可以执行PIN和帐户验证或其他验证步骤，以确保A的帐户没有被暂停，具有足够的资金等等。为清楚起见，这些步骤在上面的流程中被省略。

[355]在步骤3中，移动支付系统通过SMS消息通知用户A，资金不足。在本发明的另一个实施例中，用户A可以以其他形式接收此消息，如电子邮件、SMS消息，或其他形式的移动通信。在本发明的某些实施例中，用户可以根本不接收此消息，如当用户A决定并向系统指出不接收这样的消息时。该流程也可以应用于电子邮件支付系统或其他支付系统，移动的，非移动的(即，移动电话不参与交易的情况)，或别的样式的。

[356]在步骤4中，移动支付系统确定用户B是未注册的，并将这一情况通知给用户A。在本发明的另一个实施例中，系统可以允许用户A向用户B发出支付，不管用户B的未注册的状态，如此，可以跳过此步骤。

[357]在步骤5中，移动支付系统在A的帐户上预留该交易金额。交易金额不会从A的帐户中划出，直到该交易在步骤15中划出。

[358]在步骤6中，由移动支付系统给未注册的用户B发送一则消息，请求用户B向系统进行注册。此消息可以通过SMS消息、电子邮件、MMS消息、即时消息，或其他形式的移动通信发送到用户B的移动电话中。

[359]在步骤7中，给用户A提供能够在用户B接受支付之前取消支付的选项。如果在用户A进行支付之后并且用户B接受支付之前已经过去了30天以上，则支付也可以自动地失效。交易自动地被取消的天数可以变化。例如，天数可以是任何数字，如5、10、14、15、16、21，或多于或少于30。此外，用户A和B可以不接收通知他们交易已取消的消息。

[360]在步骤8中，在用户B进行注册时，系统为用户B创建帐户。在本发明的另一个实施例中，系统可以不要求用户B向系统进行注册，而是可以自动地将系统链接到用户B的一个银行帐户。

[361]在步骤9中，只有在用户B向系统进行注册之后，才给用户B发送有关用户A请求发出支付的消息。在本发明的另一个实施例中，用户B可以接收有关用户A的支付的消息，无需向系统进行注册。

[362]在当前实施例的步骤10中，给用户A发送有关用户B取消交易的SMS消息。在本发明的另一个实施例中，系统可以给用户A发送不同的消息，并可以以其他形式的移动通信发送。

[363]在步骤11中，B可以具有以某种方式更改或修改交易的选项。可以给用户B提供yes按钮，no按钮，以及“request change”按钮。或者，“请求更改”按钮可以称为协商按钮，因为给B提供了与A协商的机会。可以给B提供更改交易的任何条款的机会。B可以更改的交易的一些条款包括金额，选择将资金划入哪一个帐户中，或其他。

[364]在步骤12中，如果用户B请求对交易进行更改，则给用户A发送一个有关提议的更改的通知。给用户A提供了接受或拒绝用户B的提议的更改的机会。在本发明的一个实施例中，用户A利用系统在他的初始设置中可能已经选择自动地拒绝提议的更改。然后，可以给用户B发送一个用户A自动拒绝更改的消息。如果用户A拒绝更改，无论是手动还是自动地，可以给用户B提供向用户A发送另一个提议的更改的选项。或者，可以给B提供接受原始交易的机会。

[365]在步骤13中，移动支付系统通过SMS消息通知用户A，资金不足。在本发明的另一个实施例中，用户A可以以其他形式接收此消息，如电子邮件、MMS消息，或其他形式的移动通信，或者，也可以根本不接收此消息。

[366]在步骤14中，给用户A发送一个类似于收据的SMS通知，通知他交易已经完成。在另一个实施例中，可以给用户A发送其他形式的通知，如通过电子邮件、即时消息、MMS消息，或其他形式的移动通信。系统也可以给用户B发送一个交易已经完成的通知。系统也可以不给用户A或B发送有关交易完成的任何消息。

[367]在步骤15中，进行货币交易。在一种实现方式中，划入和划出交易不实时进行。由于电子资金系统中的固有延时，交易可能在处理开始之后大约六十秒或更多才能完成。

[368]流程A中的任意数量的步骤，以任何组合，都可以与任何其他移动支付系统流程相结合，包括本申请中所讨论的其他流程。

[369]下面的流程B显示了在注册的用户(用户A，会员)和未注册的用户(用户B)之间进行交易的另一种实现方式。

[370]流程B

步骤	操作
步骤	操作	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有被识别为注册的用户，则A接收到下列消息：“您的支付待办。未注册用户必须开立帐户。[tel #]，[value]，[trans #]”	3
4		5	B接收到下列消息：“您收到一笔款！[tel #]，[value]，[trans #]请去系统网站注册。”
6	起始从A的个人帐户划出资金交易，并划入未注册用户合并帐户中的B。	5	B接收到下列消息：“您收到一笔款！[tel #]，[value]，[trans #]请去系统网站注册。”
6	起始从A的个人帐户划出资金交易，并划入未注册用户合并帐户中的B。	7	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”否则，划出和划入交易会成功。没有发送消息。
8	如果在A启动交易之后已经过去30天以上而B还没有注册，则交易自动取消。然后，将给A和B发送消息：“支付已取消。[tel #]，[value]，[trans #]”上面的步骤6中请求的划出和划入交易颠倒。将从未注册用户合并帐户获取的交易金额划入A的个人帐户。	7
8		9	B在系统网站进行了注册，并成为已注册的无卡用户。资金从未注册用户合并帐户转帐到B的无卡合并帐户。
10	为B制作塑料借记卡，并寄给B。	9	B在系统网站进行了注册，并成为已注册的无卡用户。资金从未注册用户合并帐户转帐到B的无卡合并帐户。
10	为B制作塑料借记卡，并寄给B。	11	在B收到卡之后，B通过拨打交互式语音响应(IVR)系统来激活该卡。在激活过程中，在B连接到IVR系统的同时，资金从无卡合并帐户转帐到B的个人帐户。

[371]流程B中的实现方式与上面的流程A相似。然而，与流程A不同，流程B没有在A的帐户中预留交易金额(流程A的步骤5)。在流程B的步骤4中，因为在A的帐户中没有预留并且没有从A的帐户划出，钱仍可以供用户A通过移动支付或借记卡支付进行花费，直到在步骤6中从用户A的帐户中成功地划出交易金额。

[372]在步骤5中，给用户B发送一则有关交易的消息，并要求用户B向系统进行注册。

[373]在步骤6中，资金被划出。这样的交易可以是异步的线程，由于电子资金系统中的固有延时，交易可能在处理开始之后大约六十秒或更多才能完成。延迟的量是不确定的，因为有各种因素影响延迟。一般而言，延迟大约是60秒，但是，如果，例如，电网发生故障，则延迟将会大得多。

[374]具体来说，系统的支付处理可能不会以同步方式进行。将执行一定量的首先的请求验证。发送给消费者的通知可以指出，请求已经被接受，将会立刻处理。异步服务器端线程将启动，以实际处理支付请求。在一种实现方式中，在向用户发送通知之后执行异步线程。这会给用户提供更快的有关交易的响应。支付处理的异步部分可能会失败。例如，这可能是由于卡的同时使用而导致资金不足而引起的。在异步支付处理失败的情况下，将会通知用户。

[375]在一种实现方式中，有两种合并帐户，(i)未注册用户合并帐户，(ii)无卡合并帐户。所有未注册用户资金将会合并在未注册用户合并帐户中。如果用户A是还没有个人帐户的无卡用户，则A的资金将会存放在无卡合并帐户中。在本发明的另一种实现方式中，可以为未注册用户合并帐户和无卡合并帐户准备单一的合并帐户。在本发明的另一个实施例中，在合并帐户中对A和B的帐户划入和划出，在银行合作伙伴中进行的交易(合作伙伴处理借记卡)是利用其他系统交易共同地分批地在在一天结束时(或另一个特定时间)进行的。

[376]在本发明的另一种实现方式中，可以有单一的合并帐户类型，其中，有未注册用户和无卡用户两种用户存在。对于这样的用户之间的资金转帐，资金将停留在同一个合并帐户内。在本发明的再一个实现方式中，可以有两种以上的合并帐户类型。

[377]在步骤9中，在B进行注册之后，B成为无卡用户。作为无卡用户，B可以像注册的用户那样汇款和接收汇款。然而，由于B还没有收到他的卡，因此，B不能通过卡进行消费。在一种实现方式中，在用户B成功地进行注册之后24小时内，创建用户B的个人帐户。然而，帐户将没有资金，直到它在下面的步骤11中被激活。在本发明的另一个实施例中，没有使用无卡合并帐户，资金直接从用户A帐户转帐到用户B的帐户。

[378]在步骤10中，通常需要花费大约7到10个工作日，作出新的卡，用户B通过邮寄收到它。在本发明的另一个实施例中，用户B可以收到另一种卡，如信用卡，也可以选择根本不接收卡。

[379]在步骤11中，在用户B激活他的卡时，用户B成为有卡注册的用户，不再是无卡用户。在不使用无卡合并帐户的实施例中，在卡被激活时，不需要划拨余额。

[380]下面的流程C显示了在注册的用户(用户A，会员)和未注册的用户(用户B)之间进行交易的另一种实现方式。

[381]流程C

步骤	操作
步骤	操作	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有被识别为注册的用户，则A接收到下列消息：“您的请求已经被接受，将被处理。[tel #]，[value]，[trans #]请求待办的未注册用户。＂	3
4		5	B接收到下列消息：“有一笔支付，待办，来自[tel #]，[value]，[trans #]请去系统网站注册。”
6	在B批准支付之前，A可以取消支付。倘若如此，将给A和B发送消息：“支付已取消。[tel #]，[value]，[trans #]”如果在A启动交易之后并且在B批准支付之前已经过去30天以上，则交易自动取消。然后，将给A和B发送消息：“支付已取消。[tel #]，[value]，[trans #]”	5	B接收到下列消息：“有一笔支付，待办，来自[tel #]，[value]，[trans #]请去系统网站注册。”
6		7	B向系统进行注册。在系统上为B创建一个帐户。
8	在B成功地注册之后，通知B，说明A希望给B汇款。给B提供了一个画面，询问B是否接受A的支付。	7	B向系统进行注册。在系统上为B创建一个帐户。
8	在B成功地注册之后，通知B，说明A希望给B汇款。给B提供了一个画面，询问B是否接受A的支付。	9	如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”
10	如果B接受来自A的支付，则系统检查A是否具有足够的资金来完成交易。如果没有，将给A和B发送消息：“资金不足。[tel #]，[value]，[trans #]”	9	如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”
10		11	如果A有足够的资金，将给A发送消息：“支付已被接受。[tel #]，[value]，[trans #]”
12	从A的帐户划出交易金额，并划入B的帐户。	11	如果A有足够的资金，将给A发送消息：“支付已被接受。[tel #]，[value]，[trans #]”

[382]流程C中的实现方式与上面的流程A相似。然而，与流程A不同，流程C没有在A的帐户中预留交易金额(流程A的步骤5)。以上的对流程A和B的讨论也相应地适用于流程C。

[383]在一种实现方式中，尽管A的支付是待办，但是，A也可以取消支付，并相应地给B通知。在步骤8中，在有多个待办支付的情况下，可以向B呈现待办支付的列表，并要求B指出是接受还是拒绝每一个待办支付。如果异步服务器端线程(例如，步骤12)万一失败，则将通知双方。

[384]下面的流程D显示了在无卡的用户(用户A)和无卡用户(用户B)之间进行交易的一种实现方式。

[385]流程D

步骤	操作
步骤	操作	1	现有的用户A(无卡注册的用户)决定给用户B(无卡用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册的用户，发送下列消息：“您收到一笔款！[tel #]，[value]，[trans #]”	3
4		5	检查B是无卡注册的用户还是有卡注册的用户。由于B是无卡用户，开始从无卡用户合并帐户中的A划出交易资金并划入无卡用户合并帐户中的B。
7	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	5
7	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	8	如果B打开了自动接受，则资金从无卡合并帐户中的A转帐到B。没有发送消息。
9	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	8	如果B打开了自动接受，则资金从无卡合并帐户中的A转帐到B。没有发送消息。
9	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	10	如果在A启动交易之后已经过去30天以上而B还没有批准，则交易自动取消。然后，将给A和B发送消息：
	“支付已取消。[tel #]，[value]，[trans #]”如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”	10	如果在A启动交易之后已经过去30天以上而B还没有批准，则交易自动取消。然后，将给A和B发送消息：
		11	如果B接受交易，并且A和B仍是无卡用户，则资金从无卡合并帐户中的A转帐到B。如果B接受交易，而A是无卡用户，B现在是有卡用户，则资金从无卡合并帐户中的A转帐到B的个人帐户。如果A和B两者都已经成为有卡用户，则资金从A的个人帐户转帐到B的个人帐户。如果A已经成为有卡用户，但是，B仍是无卡用户，则资金从A的个人帐户转帐到无卡合并帐户中的B。

[386]上面所提供的备注也相应地适用于流程D。例如，在步骤3中，没有在A的帐户中预留交易金额。不会从A的帐户中划出交易金额。直到在下一步骤中成功地从A的帐户划出交易金额之前，钱仍可以供用户A通过移动支付或借记卡支付进行花费。

[387]用户B可能已经设置了白名单或黑名单。白名单可以规定，B将只从指定的用户(可以存储在用户的资料中)接受支付。黑名单可以规定，B将不会从指定的会员(可以存储在用户的资料中)接受支付。本发明的各种实现方式可以只有白名单、只有黑名单，或白名单和黑名单两者。未经授权的汇款人，由于白名单或黑名单，在他们尝试支付失败之后，将会通知他们发生了错误。

[388]下面的流程E显示了在无卡注册的用户(用户A)和有卡用户(用户B)之间进行交易的一种实现方式。

[389]流程E

步骤	操作
步骤	操作	1	现有的用户A(无卡注册的用户)决定给用户B(有卡用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册的用户，发送下列消息：“您收到一笔款！[tel #]，[value]，[trans #]”	3
4		5	检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用户，开始从无卡用户合并帐户中的A划出交易资金并划入B的个人帐户。
6	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	5
6	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	7	如果B打开了自动接受，则资金从无卡合并帐户中的A转帐到B的个人帐户。没有发送消息。
8	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	7	如果B打开了自动接受，则资金从无卡合并帐户中的A转帐到B的个人帐户。没有发送消息。
8	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	9	如果在A启动交易之后已经过去30天以上而B还没有批准，则交易自动取消。然后，将给A和B发送消息：“支付已取消。[tel #]，[value]，[trans #]”如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”
10	如果B接受交易，而A仍是无卡用户，则资金从无卡合并帐户中的A转帐到B的个人帐户。	9
10	如果B接受交易，而A仍是无卡用户，则资金从无卡合并帐户中的A转帐到B的个人帐户。		如果B接受交易，而A现在是有卡用户，则资金从A个人帐户转帐到B的个人帐户。

[390]上面所提供的备注也相应地适用于流程E。

[391]下面的流程F显示了在有卡用户(用户A)和无卡用户(用户B)之间进行交易的一种实现方式。

[392]流程F

步骤	操作
步骤	操作	1	现有的用户A(有卡注册的用户)决定给用户B(无卡用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的(无卡或有卡)用户还是未注册用户。如果B是注册的用户，则发送下列消息：“您收到一笔款！[tel #]，[value]，[trans #]”	3
4		5	检查B是无卡注册的用户还是有卡注册的用户。如果B是无卡用户，则开始从A的个人帐户中划出交易资金并划入无卡用户合并帐户中的B。
6	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	5
6	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	7	如果B打开了自动接受，则资金从A的帐户转帐到B的无卡合并帐户。没有发送消息。
8	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	7	如果B打开了自动接受，则资金从A的帐户转帐到B的无卡合并帐户。没有发送消息。
8	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	9	如果在A启动交易之后已经过去30天以上而B还没有批准，则交易自动取消。然后，将给A和B发送消息：“支付已取消。[tel #]，[value]，[trans #]”如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付已被拒绝。[tel #]，[value]，[trans #]”
10	如果B接受交易，并且B仍是无卡用户，则资金从A的帐户转帐到B的无卡合并帐户。如果B接受交易，并且B现在是有卡注册的用户，则资金从A的帐户转帐到B的个人帐户。	9

[393]上面所提供的备注也相应地适用于流程F。

[394]下面的流程G显示了在有卡用户(用户A)和有卡用户(用户B)之间进行交易的一种实现方式。

[395]流程G

步骤	操作
步骤	操作	1	现有的用户A(有卡注册的用户)决定给用户B(有卡注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。如果有足够的资金，则进入下一步骤。
4	检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册的用户，发送下列消息：“您收到一笔款！[tel #]，[value]，[trans #]”	3
4		5	检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用户，开始从A的个人帐户划出交易资金并划入B的个人帐户。
6	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	5	检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用户，开始从A的个人帐户划出交易资金并划入B的个人帐户。
6	如果划出和划入交易失败，则给A和B发送消息：“支付失败。[tel #]，[value]，[trans #]”	7	如果B打开了自动接受，则资金从A的帐户自动地转帐到B的无卡合并帐户。没有发送消息。
8	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	7	如果B打开了自动接受，则资金从A的帐户自动地转帐到B的无卡合并帐户。没有发送消息。
8	如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才进行。	9	如果在A启动交易之后已经过去30天以上而B还没有批准，则交易自动取消。然后，将给A和B发送消息：“支付已取消。[tel #]，[value]，[trans #]”如果B拒绝接收支付，则交易取消，给A发送一则消息：“支付被拒绝，[tel #]，[value]，[trans #]”
10	如果B接受交易，则资金从A的个人帐户转帐到B的个人帐户。	9

[396]上面所提供的备注也相应地适用于流程G。

[397]流程H显示了未注册用户的引荐流程。用户A是注册的用户，用户B是未注册用户。

步骤	操作
步骤	操作	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	1	现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2	移动支付系统检查A的帐户是否具有足够的资金来完成交易。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。
	如果有足够的资金，则进入下一步骤。	3	如果资金不足，则给A发送一则消息：“资金不足。[tel #]，[value]，[trans #]”B不会接收到消息。
	如果有足够的资金，则进入下一步骤。	4	检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有被识别为注册的用户，则A接收到下列消息：“B不是会员。我们已经邀请B加入系统。[tel #]，[value]，[trans #]＂不会从A的帐户中扣除资金。
5	B接收到下列消息：“A尝试给您汇款。[tel #]，[value]，[trans #]请去系统网站注册。”	4
5	B接收到下列消息：“A尝试给您汇款。[tel #]，[value]，[trans #]请去系统网站注册。”	6	B向系统网站进行了注册，并成为已注册的无卡用户。
7	A还接收到下列消息：“B现在是注册的用户，您愿意再次提交您的交易吗？”	6	B向系统网站进行了注册，并成为已注册的无卡用户。
7	A还接收到下列消息：“B现在是注册的用户，您愿意再次提交您的交易吗？”	8	A在他的帐户中收到引荐奖金(例如，$5)。
9	A利用B的移动电话号码向移动支付系统重新发送一则消息和交易金额。如果是，则交易将作为注册的用户与注册的用户的交易来进行处理。	8	A在他的帐户中收到引荐奖金(例如，$5)。

[398]上面所提供的备注也相应地适用于流程H。在此流程中，在B进行注册之后资金不会自动地从A转帐到B。相反地，B被邀请加入，在B加入时，给A发送一则消息(步骤9)，询问A是否希望再次尝试向B汇款。如果A希望汇款，那么，后续的A与B之间的处理与任何一个注册的用户到注册的用户之间转帐类似。

[399]实现方式可以包括引荐奖金(例如，$5)。步骤4中的消息可以包括发往A的通知，说明在B加入时，A将收到引荐奖金。在B在步骤6中进行注册之后，用户A将有资格获得放进A的帐户的引荐奖金(参见步骤8)。步骤8在步骤6之后，但是可以在步骤7和9之前或之后。

[400]在系统的各种实现方式中，可以只向汇款人支付引荐奖金，只向收款人，或汇款人和收款人支付引荐奖金。此外，在引荐流程的备选实施例中，在B进行注册之后，钱可以自动地转帐到B，A不用重新发送请求支付交易。在另一个实施例中，流程是：(1)用户A(会员)给用户B(非会员)$X。(2)系统检查B，发现B不是会员。(3)$X被标记为在A的帐户中待办。(4)通知B，说明A邀请B加入系统。等待收取$Y的奖励资金+A发送的资金。(5)B选择注册为会员，并立即收到$Y的奖励(已经在帐户中)。(6)然后，B收到一则消息，指出从A接收到$X的支付。(7)从A的帐户中扣除$X。(8)待办的“病毒式”交易可以被A取消，但仍可以处理该邀请。(9)如果B在某一时间段内没有接受邀请，则待办的金额被释放回帐户。

[401]在本发明的进一步的实施例中，在特定情况下，金融交换系统可以每次交易通过多个通知来向用户发出通知，如利用SMS，利用电子邮件。这样的情况的示例包括：在进行新用户注册时，在进行系统卡注册时，在发送或接收引荐时，在划入/划出加载时，在ACH/直接-存放加载或卸载时，在eAllowance(即，帐单支付)加载，以及在帐户或资料数据更改时。

[402]在移动支付系统中，注册的用户或会员可以向其他会员或未注册用户或非会员发出支付。在特定实现方式中，个人之间的支付系统允许支付系统的现有的会员向非会员进行支付，以希望非会员成为会员。支付系统的这种能力可以称为“病毒性的”，因为它以指数扩散方式促进新的会员注册。

[403]在一个实施例中，本发明是包括下列步骤的方法：从第一用户接收向第二用户支付某一金额的付款指示，其中，所述第一用户是已注册的用户，所述第二用户通过所述第二用户的电话号码来进行标识；基于所述电话号码，确定所述第二用户不是已注册的用户；以及，向与所述电话号码关联的设备发送第一电子消息，通知所述第二用户来自所述第一用户的待付款。该方法包括：在发送所述第一电子消息之后，注册所述第二用户，并给所述第二用户呈现接受来自所述第一用户的待付款的第一选项，以及拒绝来自所述第一用户的待付款的第二选项；当所述第二用户选择所述第一选项时，从与所述第一用户关联的第一帐户划出所述金额，并向与所述第二用户关联的第二帐户划入所述金额；以及，当所述第二用户选择所述第二选项时，向所述第一用户发送付款被拒绝的第二电子消息。

[404]在一种实现方式中，第二帐户位于合并帐户中，并且当所述第一用户是无卡已注册的用户时，所述第一帐户位于所述合并帐户中，以及所述划出和划入过程包括在所述合并帐户内维护所述金额。在一种实现方式中，第二帐户位于合并帐户中，并且当所述第一用户是无卡已注册的用户时，所述第一帐户位于所述合并帐户中，以及所述划出和划入过程包括不在所述合并帐户外部转移所述金额。在一种实现方式中，当所述第一用户是无卡已注册的用户时，所述第一帐户位于第一合并帐户中，第二帐户位于不同于所述第一合并帐户的第二合并帐户中，以及所述划出和划入过程包括从所述第一合并帐户向所述第二合并帐户转移所述金额。

[405]在一种实现方式中，第一用户是有卡，注册的用户，而第二帐户位于合并帐户中，划出和划入包括将资金金额从第一帐户转帐到合并帐户中的第二帐户，从而，合并帐户中被增加了资金金额。与注册的用户关联的卡可以是借记卡、信用卡、自动化提款卡、或显示了帐号的任何其他物理卡。通过使用这样的卡，第一用户可以独立于从其中发送支付指示的电子设备进行交易。

[406]在一种实现方式中，该方法包括：除所述付款指示之外，还接收由发送了所述付款指示的设备生成的序列号；以及，在接收所述序列号之后，生成所述付款指示的交易号。在一种实现方式中，只有在所述序列号不匹配存储在数据库中的任何以前接收到的序列号的情况下才处理所述付款指示。数据库可以包括在轮询时间周期内接收到的序列号，如上周，上两周、上个月、前六个月，或任何其他时间段。

[407]在一种实现方式中，在收到序列号之后，生成预期的序列号。然后，只有在所述序列号匹配所述预期的序列号的情况下才处理所述付款指示。

[408]在一个实施例中，本发明是包括下列步骤的方法：从第一用户接收向第二用户支付某一金额的付款指示，其中，所述第一用户是已注册的用户，所述第二用户通过所述第二用户的电话号码来进行标识；基于所述电话号码，确定所述第二用户不是已注册的用户；以及，向与所述电话号码关联的设备发送第一电子消息，通知所述第二用户来自所述第一用户的待付款。该方法包括：在发送所述第一电子消息之后，注册所述第二用户，并给所述第二用户呈现接受来自所述第一用户的待付款的第一选项，拒绝来自所述第一用户的待付款的第二选项，以及请求对来自所述第一用户的待付款作出更改的第三选项；当所述第二用户选择所述第一选项时，从与所述第一用户关联的第一帐户划出所述金额，并向与所述第二用户关联的第二帐户划入所述金额；当所述第二用户选择所述第二选项时，向所述第一用户发送付款被拒绝的第二电子消息。

[409]在一种实现方式中，该方法包括：当所述第二用户选择所述第三选项时，向所述第一用户发送第三电子消息，说明所述第二用户请求对所述待付款进行更改。在一种实现方式中，该方法包括：当所述第二用户选择所述第三选项时，接收来自所述第二用户将待付款更改为不同的金额的请求，向所述第一用户发送第三电子消息，通知所述第一用户对所述待办支付款项进行更改，给所述第一用户呈现接受所述对所述待付款的更改的第四选项或拒绝对所述待付款的更改的第五选项，以及当所述第一用户选择所述第四选项时，从所述第一用户的帐户中划出所述所述不同的金额并向与所述第二用户关联的帐户划入所述不同的金额。

[410]该方法还可以进一步包括：在确定所述第二用户不是已注册的用户之后，在所述第一帐户中预留出所述金额。该方法可以包括：在确定所述第二用户不是已注册的用户之后，在所述第一帐户中预留出所述金额；以及，在从接收到付款指示而所述第二用户仍没有注册时起一定天数过去之后，取消所述第一帐户中的所述金额的预留。

[411]所述设备至少是智能电话、移动电话设备、便携式电子邮件设备、个人数字助理或计算机中的一个。

[412]在一个实施例中，本发明是包括下列步骤的方法：从第一用户接收向第二用户支付某一金额的付款指示，其中，所述第一用户是已注册的用户，所述第二用户通过所述第二用户的电话号码来进行标识；基于所述电话号码，确定所述第二用户不是已注册的用户；以及，向与所述电话号码关联的设备发送第一电子消息，通知所述第二用户所述第一用户尝试付款。该方法包括：在发送所述第一电子消息之后，注册所述第二用户，向所述第一用户发送第二电子消息，说明第二用户已经注册，并给所述第一用户呈现给所述第二用户支付所述金额的第一选项；以及，当所述第一用户选择所述第一选项时，从与所述第一用户关联的第一帐户中划出所述所述金额，并向与所述第二用户关联的第二帐户划入所述金额。

[413]在一种实现方式中，在所述第二用户进行注册之后，给所述第一帐户划入引荐奖金金额。引荐奖金金额可以是任何资金金额，如$5。在一种实现方式中，在所述第二用户进行注册之后，给所述第二帐户划入引荐奖金金额。另外，第一和第二用户两者都可以收到引荐奖金。

[414]在一种实现方式中，该方法包括：向所述第一用户发送第二电子消息，说明第二用户不是已注册的用户。在一种实现方式中，该方法包括：除所述付款指示之外，还接收由发送了所述付款指示的设备生成的序列号；以及，在接收所述序列号之后，生成所述付款指示的交易号。

[415]图19显示了本发明的特定实施例的完整的系统图形。这是移动支付系统(即，Obopay)的特定实现方式的示意图。如前所述，Obopay只作为示例，用于说明本发明的功能，本发明不应该仅限于此示例。Obopay的系统具有借记卡主干网。Diamond FinancialProducts是合作伙伴。通过Diamond，Obopay发放借记卡并与ECL和First Premiere Bank进行通信，以给予Obopay用户在借记卡之间转帐和接收资金的能力。PBT(Pay By Touch)处理ACH交易和信用卡交易。Bancorp Bank提供结算帐户，并与PBT有关系。

[416]图20显示了两个个人卡帐户之间的个人之间的支付。“卡”是指持有Diamond Financial Products借记卡的Obopay会员。这是“卡用户”或“有卡用户”，与无卡用户不同。具体流程包括：(1)从U1的电话，启动向U2的$5的P2P支付。(2)Obopay向Diamond发送P2P请求(而Diamond又将它发送到ECL和First Premier)。(3)从U1的借记卡帐户划出金额$5，$5被划入U2的借记卡帐户。(4)$0.10的费用被从U1的帐户中扣除，并划入位于First Premier Bank的Diamond Financial Products银行帐户。

[417]图21显示了卡帐户和非会员帐户之间的个人之间的支付。具体流程包括：(1)从U1的电话，启动向非用户V1的$5的P2P支付。(2)Obopay向Diamond发送P2P请求(而Diamond又将它发送到ECL和First Premier)。(3)从U1的借记卡帐户划出金额$5，$5被划入Obopay In & Out帐户。(4)$0.10的费用被从U1的帐户中扣除，并划入位于First Premier Bank的DiamondFinancial Products银行帐户。(5)记录被输入到U1的“邀请”数据库表中。这存储“病毒式”交易的记录的位置；交易可以保留，直到“病毒式”收款人注册了Obopay帐户。

[418]图22显示了卡帐户和无卡帐户之间的个人之间的支付。“无卡”用户是还没有收到或激活他们的借记卡的Obopay用户。在本发明的另一个实施例中，不需要借记卡。在特定实施例中，存在订购卡和激活之间的状态，在该状态下，用户仍可以转帐和接收资金。

[419]具体流程包括：(1)U1从电话中启动向“无卡”用户O1的$5的P2P交易。(2)金额$5.00被从U1的借记卡帐户转帐到位于First Premier的Obopay In & Out银行帐户。(3)$0.10的费用被转帐(通过Diamond)到位于First Premier Bank的DiamondFinancial Products银行帐户。(4)Obopay在Obopay总帐上记录O1的余额增多$5。

[420]图23显示了无卡帐户到无卡帐户之间的个人之间的支付。具体流程包括：(1)O1从电话中启动向“无卡”用户O2的$10的P2P交易。(2)$10仍保留在位于First Premier的Obopay In &Out帐户中。$0.10的费用也停留在In & Out帐户中。(3)Obopay在Obopay总帐中记录了O2的余额增多，O1的余额缩小。

[421]图24显示了信用卡加载。具体流程包括：(1)U1从web输入CC-Number，以将$300加载到他的Obopay卡上。(2)Obopay从Pay-By-Touch获取$300的信用卡交易的授权。(3)Obopay向Diamond发送一则消息，启动Obopay CC-Master A/C到U1的借记卡的$300P2P交易。将资金立即划入用户的帐户。(4)PBT对信用卡交易进行结算，并向位于Bancorp Bank的Obopay的结算帐户转帐$300ACH。(5)Obopay向Obopay CC Master A/C转帐$300ACH，以补充资金。

[422]图25显示了本发明的另一个特定实施例的完整的系统图形。下列流程78到85涉及图77中的系统实现方式。在此系统实现方式中，用户将不需要为借记卡卡帐户而进行注册。这些用户将叫做“无卡”用户，并将持有虚拟帐户。资金将保留在银行帐户中(为了Obopay用户的利益)。

[423]图26显示了无卡帐户和无卡帐户之间的个人之间的支付。具体流程包括：(1)从O1的电话，启动向O2的$5的P2P支付。(2)由于O1和O2两者都是现有的用户，因此，他们的资金存放在Bancorp Bank的合并帐户中。$5停留在同一个帐户中，减去$0.10的费用。(3)Obopay的总帐反映了余额的变化。从O1的帐户划出金额$5，$5被划入O2的帐户。(4)$0.10的费用从合并客户帐户转帐到流动资本帐户。

[424]图27显示了无卡帐户和卡帐户之间的个人之间的支付。具体流程包括：(1)从O1的电话，启动向U6的$5的P2P支付。(2)用户O1的帐户被划出$5.10。此变化反映在Obopay的总帐中。(3)Obopay(通过与Diamond的通信)启动P2P，从FirstPremier In & Out帐户向借记卡U6转帐$5。(4)在夜晚时间的批处理中，从Obopay合并帐户向位于Bancorp的Obopay流动资本帐户转帐$5.10(有10美分的汇款手续费)。

[425]图28显示了个人之间的支付，与非会员的“病毒式”交易。“病毒式”支付是指一个Obopay会员，有卡或无卡，向非Obopay用户电话号码进行支付。具体流程包括：(1)从O1的电话，启动向V1的$5的P2P支付。(2)Obopay的总帐反映了O1的余额的变化。$5.10从O1的帐户中划出。(3)$5.10仍保留在合并客户帐户中。费用以后转帐。(4)病毒式交易记录在Obopay数据库中的O1的“邀请”表中。如果“病毒式”支付到期，则资金将被退回到O1。(5)$0.10的费用从合并客户帐户转帐到流动资本帐户。这可以在夜晚时间的批处理中进行。

[426]图29显示了奖励资金。当给新的obopay用户提供$5的注册奖金或任何其他金额时，产生奖励资金。当用户进行注册时，此$5将反映在余额中。此外，象病毒发送给用户的任何资金都将转帐到他们的帐户中。当非Obopay用户以病毒式方式发送他们保留在客户合并帐户中的资金时，发生待办的“病毒式”支付。支付被记录在汇款人“邀请表”中，这是他们自己的资料数据的一部分。“病毒式”只是“待办”，表示汇款人可以取消该支付。

[427]具体流程包括：(1)V1(“病毒式”资金收款人，非用户)在Obopay.com注册使用Obopay。(2)在Obopay数据库中创建帐户。(3)Obopay GL中的用户余额现在反映$5奖金和$10“病毒式”支付。(4)以病毒式方式发送给V1的资金(在注册之前发送给用户的$10)仍保留在客户合并帐户中。(5)“病毒式”资金的原始发件人的数据库资料被更新为“RFPAID”(引荐支付)。(6)在夜晚的批处理中，$5被从Obopay w/c帐户转帐到客户合并帐户。

[428]图30显示了信用卡加载。信用卡加载是通过信用卡将资金加载到Obopay帐户的过程。Obopay流动资本帐户是在Bancorp银行(或任何其他银行合作伙伴)的银行帐户。此帐户包含Obopay流动资本，并用Obopay流动资本填充。此帐户还被用作NYCE、PBT、及其他机构的结算帐户。

[429]具体流程包括：(1)Obopay用户O1进入Obopay.com，并启动从他的Visa卡到他的Obopay帐户的$300加载。(2)Obopay，使用Pay-By-Touch作为处理器，获得信用卡交易的$301.50授权(包括适当的费用)。(3)金额$300划入Obopay GL位于O1的帐户。(4)Obopay将$300从流动资本帐户转帐到客户合并帐户。这在夜晚时间的批处理中进行。(5)Pay-By-Touch对交易进行结算，然后，启动到Bancorp Bank的Obopay结算帐户的$301.50ACH。这在翌日的批处理中进行。

[430]图31显示了ACH加载。具体流程包括：(1)无卡用户O1从Obopay网站启动从他的DDA向Obopay帐户的$100ACH交易。(2)Obopay对用户DDA启动ACH划出交易。(3)资金从用户DDA转帐到Obopay流动资本帐户。(4)在Obopay GL中，给用户帐户划入$100。(5)Obopay将$100从Obopay流动资本帐户转帐到合并客户帐户。这可以在夜晚时间的批操作中完成。

[431]图32显示了ACH卸载。具体流程包括：(1)无卡用户O1从Obopay网站启动向他的DDA的$100ACH交易。(2)在Obopay总账中，用户O1的“可用余额”减少$100。(3)通过Pay-By-Touch，ACH信用被记入O1的DDA。(4)ACH被记入，从Obopay流动资本帐户取出$100。(5)用户“当前余额”减少$100，以匹配可用余额。(6)$100被从Obopay客户合并帐户转帐到Obopay流动资本帐户。

[432]图33显示了ATM加载。加载可以通过任何ATM机构进行，如NYCE、PLUS、STAR，及其他。在特定实现方式中，ATM加载是NYCE加载。具体流程包括：(1)无卡用户O1从Obopay网站启动从他的DDA的$100NYCE加载。(加载资金需要$0.99的费用。)(2)Obopay提交，并从NYCE收到$100.99授权。(3)Obopay GL中的O1的帐户被划入$100。(4)在夜晚的批处理中，$100被从Obopay流动资本帐户转帐到客户合并帐户。(5)NYCE将$100.99ACH记入Obopay流动资本帐户。

[433]当今的支付系统(即，信用卡和借记卡)对于消费者和商家都费用。可以向消费者收取年度预订费用。向商家主要收取了交易费用。所需要的是对消费者和商家可用的，没有注册费用、没有预订费，对于消费者或者商家没有交易费用的支付系统。同时，也必须对运行这样的系统的“处理器”相应地进行补偿。

[434]闭环支付方案

[435]在一个实施例中，本发明提供了用于操作作为闭环支付系统的支付转帐基础架构的方法。闭环金融交易系统便于进行支付，没有与闭环金融系统关联的大量的付款手续费，并且对于参与金融交易的持有人、商家及其他各方来说，具有高度的安全性。

[436]闭环支付系统是这样的，价值转移过程的组件在拥有该支付系统的实体控制下工作。由于所有者控制了该系统，因此，基础价格也在所有者的控制之下。相比之下，现金和支票是开放的支付系统，每一个参与者都为他们的交易的处理设置价格，无需支付给网络运营商费用。

[437]图35显示了闭环支付系统中的交易流程。具体来说，当从一个移动设备3501向另一个移动设备3502进行支付时，向支付服务器3503传输转帐请求。请求通过引用箭头3504来表示。服务器3503访问与移动设备3501关联的帐户持有人的T-总帐(如引用箭头3505所示)，如果满足了如3506处所示的某些速度规则，则将指定的金额转帐到收款人T-总帐(如引用箭头3507所示)。一旦资金已经转帐到收款人，如3508所示，服务器3503就向收款人发送一则通知消息，如3509所显示的。最后，付款人帐户持有人从服务器3503接收到确认消息，说明交易已经完成。优选情况下，整个闭环系统由单一实体所拥有。系统由帐户持有人装填或加载，帐户持有人由于在支付服务器上维护的帐户余额，而获得美元(参见图36)。

[438]闭环支付系统有多个优点。主要优点是，系统的所有者能够控制向汇款人和收款人收取的费用，对于加载到系统中的资金，有赚取利息的机会。支付系统所有者能够赚取系统中的所有资金的利息，直到它们被转换回美元或卸载回美元。随着更多功能被添加，由于费用和余额的增多，闭环系统会变得更有利可图。

[439]给参与帐户持有人带来的好处包括：

[440](1)安全—帐户持有人的资金被安全地锁在移动设备中而不是必须将现金装在口袋或钱包中；

[441](2)安全性—及时验证看看帐户中有多少钱可用；

[442](3)信息—易于获取帐户活动和余额信息；

[443](4)方便—帐户持有人可以以秒为单位在全世界或跨房间地移动资金。

[444]给商家带来的好处包括：

[445](1)安全—没有现金；

[446](2)较少的处理成本—不计数现金收入，无存款单，无计数单；

[447](3)较少的交易费用—比信用卡的费用要低；以及

[448](4)资金有保证—无退回支票。

[449]商家合作伙伴具有极难得的机会赚取处理针对将资金存放到预存款贷记帐户中的交易或用于向帐户持有人提供现金的交易的收入。当资金被添加到帐户中时，商家可以赚取佣金。

[450]本发明的独立的闭环支付系统被设计为与伙伴银行帐户集成在一起。此帐户可以是预先存在的帐户，或者，对于无银行帐户的用户，可以创建帐户，或者保留在合作银行的合并帐户中。

[451]闭环系统维护了用户资料数据库，包括帐户持有人的姓名和人口统计数据，每一个特定帐户持有人的用于对风险进行签名的信息，以及将用于向帐户中加载或从帐户中卸载资金的帐户的链接的银行帐户信息。用户资料数据库也需要面向消费者和面向顾客服务的网站，用于当开立时收集注册数据。

[452]支付服务器为每一个帐户持有人维护了“T”帐户记录。此帐户是跟踪每一个帐户持有人的交易和余额的总帐。和T型帐户数据库一起，支付服务器还通过移动设备以及面向消费者和顾客服务的网站，提供历史和余额数据。

[453]为了将资金转入闭环支付系统或转出该闭环支付系统，本发明为不同的帐户持有人提供了三种功能。

[454]某些帐户持有人已经在不是合作伙伴的银行具有银行帐户。系统允许帐户持有人通过ACH系统或通过与帐户持有人的DDA直接的集成，或通过ATM网络的集成，往返于此银行帐户地移动资金。由于存在风险，用户必须进行风险控制，可以包括延迟划拨的资金可用性(例如，在星期一从您的银行帐户转帐的资金直到星期四才可以使用)。此延期时间可以通过额外的签名而缩短(运行信用报告或获取财务报表)。延迟时间的缩短也可以由于用户在合作伙伴运营商那里具有良好的资信评级或利用保留的信用卡保证支付而出现。一般而言，由于涉及风险，此方法不是我们的首选，除非有涉及的运营商可以提供某些签名数据和足够的用户证明额外的签名是正当的。

[455]在帐户持有人由于与合作银行的关系而被注册的情况下，与活期储蓄帐户(支票帐户)系统的实时连接允许帐户持有人获取余额并实时地将交易记入他们的帐户中。

[456]在其他情况下，帐户持有人在某一家银行(例如，BancorpBank或First Premier Bank)有一个帐户，银行开办银行业务，但是，网站，支票，以及客户对帐单将带有亲缘品牌。此方法将允许我们在紧密的整体环境中与伙伴银行帐户(该帐户对用户是免费的)提供亲缘品牌。

[457]本发明涉及交易费用较低的或无交易费用并且安全性改善的闭环金融交易服务。本发明的实施例包含在任何对等伙伴之间或在消费者和商家之间进行快速方便的支付转帐的方法。该方法的一种实现方式包括移动电话设备，蜂窝电话(手机)或类似的设备，作为访问诸如预存款贷记帐户之类的帐户并授权从该帐户向另一方转拨资金的机制。本发明的另外的实施例涉及各种合作伙伴，包括移动电话运营商、全国性的品牌商家，以及金融服务提供商，连同支付平台，该支付平台提供供个人使用他们的手机或其他电信设备进行付款的快速，简便的方式。

[458]现在请参看图36，该图显示了根据本发明的实施例的闭环金融交易系统。在此交易系统中，消费者和商家，一组两个或更多消费者，或者一组两个或更多商家可以快速地，安全地完成金融交易，交易费用很少或没有。

[459]此闭环金融交易系统利用预存款贷记帐户，因此，可以包括销售点(POS)终端3612，其中，可以如在现有技术系统中那样使用传统的借记卡3606—通过在与POS终端3612关联的磁性读取器3613中刷卡。卡3606提供了查看帐户持有人的帐户的第二途径。

[460]在某些实施例中，POS终端3612进一步包括近场(NF)天线和电路3614。NF天线和电路3614检测诸如支持NF的手机、支持蓝牙的手机之类的无源装置，或与手机3618关联的诸如RFID或条形码之类的其他近距离传输设备。如此，当手机3618位于POS终端的附近时，帐户信息被自动地传输到POS终端。在其他实施例中，POS终端3612包括在交易启动时建立与交易处理器3630(也被称为支付服务器或服务器)的连接的手机连接。应该理解，交易处理器3630包括一个或多个服务器场或数据中心，它们能够处理大量的同时的交易。如当前技术很好地理解的，这样的服务器场通常在地理位置上是分散的，并采用适当的技术，链接在一起，以维护所有帐户的实时状态的准确的视图。POS终端将交易金额直接从POS终端转帐到支付服务器，以便通过手机连接3615进行授权。支付服务器3630呼叫帐户持有人的手机3619，以便确认交易细节。本领域技术人员将认识到，POS终端可以只包括磁性读取器3613、NF天线和电路3614，以及手机3615中的一个或两个。还要理解，POS终端3612通常与商家关联。

[461]本发明的实施例的一个重要优点是，手机3618或3619和卡3606两者共用一个共同的PIN。如此，帐户持有人不会因为必须回忆多个PIN而感到不方便。

[462]除消费者与商家之间的交易之外，本发明足够灵活，可以实现真正的个人之间的金融交易功能。个人之间的设备3620各自都包括链接到帐户和帐户持有人的手机。当对等伙伴3620中的一个希望启动交易请求，以便向另一个对等伙伴进行支付时，交易的请求、授权和确认都是通过公共网络在支付服务器3630和对等伙伴3620之间发送的。优选情况下，由于使用了一个或多个公共网络，没有了交换中心的费用，如此，对于参与者来说，成本可以免费的，或者相当便宜，以至于它占在系统上进行的总体交易的百分比可忽略，特别是与典型的交易费用相比时。

[463]正如上文所指出的，交易请求通过公共网络被路由到支付服务器3630。在一个实施例中，公共网络3625是因特网。在另一个实施例中，公共网络3625是蜂窝电话网络。在再一个实施例中，公共网络3625是无线电网络，而在再一个实施例中，它是公用交换电话网或PSTN。公共网络3625将帐户持有人的交易请求传输到支付服务器3630。

[464]在一种实现方式中，通过公共网络3625的连接是依赖于对参与者进行身份验证和加密的安全的链路。如此，对于通过因特网的连接，连接协议可以是HTTPS，链路可以是虚拟专用网络或VPN。支付服务器3630还要么通过公共网络3625(未显示)要么通过专有的ACH银行或者金融网络连接到所链接的储蓄帐户3635。

[465]图37是根据本发明的实施例的闭环金融系统的方框图。更具体地说，本发明的简单性可以使其普遍地使用，并可以向帐户持有人和商家提供巨大的使用价值。如前面所讨论的，本发明提供了用于完成消费者与商家之间的交易和个人之间的交易的便宜的电子金融交易服务。这种灵活性部分地是通过将消费者的手机3702连接到POS终端3612来实现的。在一个实施例中，消费者可以在与POS终端关联的小键盘上输入他们的电话号码，当获得了交易总金额时，商家可以通过因特网连接3706和支付服务器3704向手机3702发送PAY REQUEST(支付请求)。支付服务器3704将呼叫手机3702，并请求消费者授权进行资金转拨。然后，消费者将输入他们的PIN或其他生物特征标识，并确认金额，以对支付进行授权。支付服务器3704会将资金从消费者的预存款贷记帐户(加上任何交易费用)转帐到商家的帐户(减去任何交易费用)。

[466]在备选实施例中，手机3702包括近场通信(NFC)电路、蓝牙电路或RFID电路(未显示)，用于允许POS终端3712查询和恢复诸如手机电话号码之类的帐户信息。在此实施例中，商家将自动地检测帐户信息，并向支付服务器3704发送请求。支付服务器3704将再次呼叫手机3702，以请求PIN或其他生物特征标识和支付授权。

[467]个人之间的交易将POS终端从处理过程中免除，每一个对等伙伴3707和3708都直接联系支付服务器3704，以进行金融交易。

[468]图38是根据本发明的实施例的移动客户端应用程序(MCA)的方框图。MCA驻留在手机3802上，并包括用户界面API3802和3803和支付API 3805。API 3802提供用户屏幕图像，引导帐户持有人执行各种金融交易，如识别对方、交易的金额(如果有的话)以及可用的交易类型。API 3803给服务提供商或其他增值合作伙伴(如帐户或记录服务)提供了用于访问支付API 3805以获取提供增值服务所需的信息的机制。在一个实施例中，支付API 3805提供了用于实现本发明的逻辑以及用于与手机的通信层3810进行连接的逻辑。

[469]用于操作根据本发明的实施例的支付转帐基础架构的一种方法是作为闭环支付系统来实现的。闭环支付系统是这样的，价值转移过程的全部组件在拥有该支付系统的实体控制下工作。由于所有者控制了该系统，因此，基础价格也在所有者的控制之下。

[470]图39显示了如图36所示的闭环支付系统中的交易流程。具体来说，对于个人之间的交易，当从移动设备3901向另一个移动设备3901进行支付时，向支付服务器3903传输转帐请求。请求通过引用箭头3904来表示。服务器3903访问与移动设备3901关联的帐户持有人的T-总帐(如引用箭头3905所示)，如果满足了如3906处所示的某些速度规则，则将指定的金额转帐到收款人T-总帐(如引用箭头3907所示)。一旦资金已经转帐到收款人，如3908所示，服务器3903就向收款人发送一则通知消息，如3909所显示的。最后，付款人帐户持有人从服务器3903接收到确认消息，说明交易已经完成。在一个实施例中，整个闭环系统由单一实体所拥有。系统由帐户持有人装填或加载，帐户持有人由于在支付服务器上维护的帐户余额，而获得美元(参见图36)。

[471]闭环支付系统有多个优点。主要优点是，系统的所有者能够控制向汇款人和收款人收取的费用，对于加载到系统中的资金，有赚取利息的机会。支付系统所有者能够赚取系统中的所有资金的利息，直到它们被转换回美元或卸载回美元。随着更多功能被添加，由于费用和余额的增多，闭环系统会变得更有利可图。

[472]给参与帐户持有人带来的好处包括：

[473](1)安全—帐户持有人的资金被安全地锁在移动设备中而不是必须将现金装在口袋或钱包中；

[474](2)安全性—及时验证看看帐户中有多少钱可用；

[475](3)信息—易于获取帐户活动和余额信息；

[476](4)方便—帐户持有人可以以秒为单位在全世界或跨房间地移动资金。

[477]给商家带来的好处包括：

[478](1)安全—没有现金；

[479](2)较少的处理成本—不计数现金收入，无存款单，无计数单；

[480](3)较少的交易费用—比信用卡的费用要低；以及

[481](4)资金有保证—无退回支票。

[482]商家合作伙伴具有极难得的机会赚取处理针对将资金存放到预存款贷记帐户中的交易或用于向帐户持有人提供现金的交易的收入。当商家使用他们的POS终端向帐户中添加资金时，商家可以赚取佣金。

[483]本发明的独立的闭环支付系统被设计为与伙伴银行帐户集成在一起。此帐户可以是预先存在的帐户，或者，对于没有现成的银行帐户的用户，合作银行可以创建一个帐户。

[484]闭环系统维护了用户资料数据库，包括帐户持有人的姓名和人口统计数据，每一个特定帐户持有人的用于对风险进行签名的信息，以及将用于向预存款贷记帐户中加载或从该帐户中卸载资金的帐户的链接的银行帐户信息。用户资料数据库也需要面向消费者和面向顾客服务的网站，用于当开立帐户时收集注册数据。优选情况下，本闭环系统与信用卡交换系统连接，以访问信用卡帐户下可用的信用额度。

[485]支付服务器为每一个帐户持有人维护了“T”帐户记录。此帐户是跟踪每一个帐户持有人的交易和余额的总帐。和T型帐户数据库一起，支付服务器还通过移动设备以及面向消费者和顾客服务的网站，提供历史和余额数据。T型帐户数据库是在交易进行时记录交易的实时记录。这意味着，当交易进行时，资金的汇款人可以观察到他们的帐户中的余额立即缩小，而收款人可以观察到他们的帐户余额立即增多。在帐户之间移动资金时，没有与ACH或其他转帐相关的延迟。

[486]为了将资金转入闭环支付系统或转出该闭环支付系统，本发明为不同的帐户持有人提供了三种功能。

[487]某些帐户持有人已经在不是合作伙伴的银行具有银行帐户。该系统允许帐户持有人通过ACH系统往返于此银行帐户地移动资金。由于存在风险，用户必须进行风险控制，可以包括延迟划拨的资金可用性(例如，在星期一从您的银行帐户转帐的资金直到星期四才可以使用)。此延期时间可以通过额外的签名而缩短(运行信用报告或获取财务报表)。延迟时间的缩短也可以由于用户在合作伙伴运营商那里具有良好的资信评级或利用保留的信用卡保证支付而出现。一般而言，由于从闭环金融交易系统的外面转拨资金所涉及的风险，此方法不作为我们的首选，除非有涉及的运营商可以提供某些签名数据和足够的用户证明额外的签名是正当的。

[488]在帐户持有人由于与合作银行的关系而被注册的情况下，与活期储蓄帐户(支票帐户储蓄或诸如现金市场帐户之类的其他帐户)系统的实时连接允许帐户持有人获取余额并实时地将交易记入他们的帐户中。

[489]在其他情况下，帐户持有人在Bancorp Bank或类似的金融机构有一个帐户，银行开办银行业务，但是，所有网站，支票，以及客户对帐单将带有亲缘品牌。此方法将允许我们在紧密的整体环境中与伙伴银行帐户(该帐户对用户是免费的)提供亲缘品牌。

[490]图40显示了根据本发明的实施例的闭环金融系统的示范性费用结构。应该理解，费用结构可以变化，该例图呈现了用于生成营业收入的典型结构。由于本发明的无所不在的特征，交易费用可以非常低或免费。如此，如4001所示，对于某一美元金额下的交易，交易费用被放弃。为说明问题，请看在个人之间转帐$1的金融交易。无交易费用。尽管可以收取交易费用的美元金额是任意设置的，但是，通常，美元金额将是小于$25的金额。帐户持有人将有资格每个月进行无限个这样的交易。

[491]对于超过选定最大值的交易费用，帐户持有人进行汇款(启动支付交易)将产生某些费用，如4002所示。为说明问题，对于在$50和$100之间的交易金额，帐户持有人将产生，例如，$1.00的交易费用。对于超过选定金额(如超过$100)的金额，可以收取较高的费用或协商费用。这些费用比信用卡发行者收取的每次交易费用少得多。在一个备选实施例中，交易费用可以是名义帐面额，如向汇款人收取的一个美分，$0.05，或$0.10。

[492]对于涉及商家的交易，商家可以可选地提议支付否则将会向消费者收取的交易费用，如4003所显示的。此外，也可以向商家收取接收资金的额外的费用。同样，商家交易费用的实际金额可以变化，但是，在一个实施例中，是交易金额的额定1％。

[493]在一个实施例中，额定每月的服务费，通过移动服务提供商添加到手机用户的帐单中，如4004所示。移动服务提供商和本发明的闭环金融交易系统的所有者按比例分配地共享每月的服务费。

[494]向消费者和商家提供了支持会员的支付系统，消费者或者商家无需支付注册费用、预订费，或交易费用。在一种特定实现方式中，会员支付系统是这样的移动支付系统，消费者可以使用诸如移动电话、智能电话、个人数字助理之类的移动设备，或类似的便携式无线手持式设备来进行交易。商家将进行可退款的一次性的捐献。这些捐献由系统存储在合并信托帐户中，这些捐献的浮动股息或利息将为该系统提供资金。

[495]在一种特定实现方式中，支持会员的支付系统(MSPS)根据下列原理向消费者和商家提供完全免费的支付系统：

[496]1.对于消费者或商家，无注册费用

[497]2.对于消费者或商家，无预订费

[498]3.对于消费者或商家，无交易费用

[499]4.需要商家提供可退款的一次性的捐献。

[500]5.一次性的商家分担款项被合并到MSPS信托帐户中

[501]6.MSPS信托帐户产生浮动红利，该红利为MSPS处理公司和系统提供补偿。

[502]7.消费者和商家可以向合并MSPS往来帐户(与信托帐户分开)加载和从其中卸载

[503]8.消费者可用的资金是预存的，在合并MSPS往来帐户内是活的。

[504]9.MSPS系统为消费者和商家管理了“T”帐户(即，余额、划出、划入)。

[505]在一个实施例中，本发明是包括下列步骤的方法：接收多个商家分担款项以为会员支付系统提供资金；将商家分担款项放入合并信托帐户中，其中，商家对他们的分担款项不收利息；允许多个消费者免费成为移动支付系统的注册的用户；允许注册的用户免费向会员支付系统的往来帐户加载资金或从中卸载资金；以及，允许商家免费向会员支付系统的往来帐户加载资金或从其中卸载资金，从而，用合并信托帐户的利息为会员支付系统提供资金。

[506]图41显示了本发明的支持会员的支付系统实现方式中的加载信任操作。

[507]图42显示了支持会员的支付系统中的消费者注册过程。

[508]图43显示了支持会员的支付系统中的加载和卸载操作。

[509]图44显示了支持会员的支付系统中的购物交易。

[510]在一种实现方式中，商家分担款项可以是某一时间段内的分期付款。取决于分担款项的金额，商家在系统将具有较大的访问权限或特权。例如，可以有分担款项的固定的量，对应于商家将有资格免除额外的费用地进行的交易的数量。此外，商家还可以进行后续的捐献，以扩大商家的特权。

[511]在一种实现方式中，会员支付系统允许注册的用户通过移动电话请求向另一个注册的用户付款。会员支付系统可以允许注册的用户通过移动电话请求向商家付款。

[512]会员支付系统可以管理注册的用户的交易记录。会员支付系统可以管理商家的交易记录。会员支付系统可以管理注册的用户和商家的交易记录。这将降低商家的成本，因为他们不需要管理他们自己的交易记录。

[513]分担款项是可退款的，如此，商家可以决定以后不参与。例如，当商家请求归还该商家向会员支付系统捐献的资金时，注册的用户将不再被允许向该商家转帐。

[514]一般而言，在商家是会员支付系统的参与者的情况下，不向该商家收取定期经常性交易费用。系统是由包含商家分担款项的合并信托帐户的浮动收益资助的。

[515]注册的用户能通过自动票据交换所(ACH)或直接储蓄帐户(DDA)中的至少一个来加载或卸载资金。在系统的进一步的实现方式中，可以给注册的用户和商家提供很多额外的加载和卸载资金的方式。例如，注册的用户可以选择让用户的工资支票或工资支票的一部分直接存放到系统中。

[516]在一种实现方式中，该方法包括：允许注册的用户通过使用两因素授权方案，通过会员支付系统授权向商家支付。这两因素授权可以包括(1)人所拥有的(例如，电话、卡)和(2)人所知道的(例如，PIN、母亲的婚前姓，挑战性的问题)。例如，系统可以允许注册的用户通过使用注册的用户的移动电话和用户正确地输入个人标识号或PIN，通过会员支付系统授权向商家支付。

[517]可选地，也可以为每一个注册的用户提供一个借记卡。利用借记卡，用户可以在没有，例如，移动电话的情况下，进行收费。

[518]虚拟合并帐户

[519]请参看图45，在本发明的一种特定实现方式中，为避免为每一个银行记录总账，移动支付系统将为每一个国家的虚拟合并帐户记录一个总账。这会降低系统的结算和营运成本。由于资金将保留在虚拟合并帐户中，因此，虚拟合并帐户的所有者(例如，移动支付系统服务运营商)将接收到此资金的浮动收益或利息。虚拟合并帐户的浮动收益的收款人可以将某些金额分发给合作银行(它们不再收到他们的总账的浮动收益)。

[520]分发浮动资金的方法如下：

[521](1)由合作银行获取的帐户将被认为是来自该银行。例如，如果银行Ci销售移动支付系统服务，并吸收客户A，那么，客户A在他的一生中都被标记为“由Ci吸收”。为每一个用户记录(在本申请中别处进行了讨论)，可以有一个字段，指出该特定用户是从哪一个来源招收的。可能的来源的某些示例包括直接的移动支付服务、合作银行、合作金融机构，以及合作移动电话提供商。

[522]在每天结束时，移动支付系统服务将估计保留在移动支付系统服务帐户中的被标记为由每一个合作银行吸收的资金的金额。让我们将此估计金额叫做X-Ci、X-BA、X-ING，其中，Ci、BA和ING是金融机构或银行的示例。

[523]例如，在图45中，会员6504044762是由第一银行Ci吸收的，而会员4154443214是由第三银行BA吸收的。在此示例中，会员是通过电话号码来进行标识的。美国的电话号码的示例包括4158675309或2128675309。在本发明的一种实现方式中，输入的电话号码格式可以排除区号，如7762323或5550123。例如，这可以用于收款人与汇款人位于同一个区号的情况。系统将自动地填充补充区代码数字。如在本申请中别处所指出的，会员可以通过其他类型的标识符来进行标识，如即时消息用户名、电子邮件地址、社会保障号码、驾驶执照号码，帐号，及其他。

[524](2)让我们将其余部分叫做Y。这是移动支付系统服务帐户中要保留的没有被标记为吸收的资金的估计金额。这些是由移动支付系统服务直接吸收或非银行合作伙伴吸收的帐户。在图45中，这由电话号码6508622730来表示，表示为由第二银行MSPS(移动支付系统服务提供商)吸收。

[525](3)每天，也许在指定的时间，移动支付系统服务将计算要保留在合作银行中的适当的资金。例如，可以根据下列公式：X-合作银行加Y的百分比。百分比将在建立银行合作伙伴关系时协商，并将取决于销售花费的水平。例如，对于Ci，移动支付系统服务可以将Y的10％放在Ci的移动支付系统服务帐户中。百分比可以是任何百分比，如，1、2、3、4、5、6、7、8、9、10、11、12、13、14、15或其他。百分比可以是整数，也可以是分数，包括1.1、1.2、1.3、1.5，小于1、小于2、小于3、小于6，及其他。

[526]此方法能够避免记载多个总账和准确的结算净额的成本。还将给予合作银行分得多于移动支付系统服务资金的应得的一份。

[527]虚拟合并帐户用于运营具有多个金融合作伙伴的系统中。在特定实现方式中，系统是移动银行系统。不是为每一个金融机构都维护单独的总账，系统将记载一个一般的虚拟合并帐户。这会降低系统的结算和营运成本。虚拟合并帐户的所有者将收到虚拟合并帐户的浮动收益，此浮动收益将根据一个公式，分发给多个金融合作伙伴。

[528]在一个实施例中，本发明是包括下列步骤的方法：处理系统的一组用户的金融交易，其中，金融交易可以通过移动电话指定，用户的子组与金融机构关联；处理与第一金融机构关联的金融交易，其中，第一子组中的用户与所述第一金融机构关联；处理与第二金融机构关联的金融交易，其中，第二子组中的用户与所述第二金融机构关联；处理与第三金融机构关联的金融交易，其中，第三子组中的用户与所述第三金融机构关联；维护包括与所述第一、第二、以及第三金融机构关联的所述第一、第二以及第三子组用户的资金的虚拟合并帐户；以及，基于所述第一子组用户的所述虚拟合并帐户中的资金的浮动收益，加所述第三子组用户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第一金融机构分发第一红利。

[529]在一种实现方式中，该方法包括，基于所述第二子组用户的所述虚拟合并帐户中的资金的浮动收益，加所述第三子组用户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第二金融机构分发第二红利。在一种实现方式中，该方法包括：从所述第一子组中的第一用户接收向所述第二子组中的第二用户转帐的指示，其中，资金不在所述虚拟合并帐户外部转移。指示可以以无线方式通过SMS消息从移动电话进行发送。指示可以以无线方式使用在所述移动电话上执行的应用程序从移动电话进行发送。

[530]第三金融机构可以是系统的直接合作伙伴。在一种实现方式中，该方法包括：每一个用户都只与所述第一、第二或第三金融机构中的一个关联。在一种实现方式中，该方法包括：管理虚拟合并帐户的记录系统，其中，所述记录系统包括所述第一、第二以及第三子组中的用户的交易的记录。

[531]在一个实施例中，本发明是包括下列步骤的方法：处理系统的一组用户的金融交易，其中，金融交易可以通过移动电话指定，用户的子组与金融机构关联；

处理与第一金融机构关联的金融交易，其中，第一子组中的用户与第一金融机构关联；处理与第二金融机构关联的金融交易，其中，第二子组中的用户与所述第二金融机构关联；处理第三子组中的与所述系统关联而不与所述第一和第二金融机构关联的用户的金融交易；维护包括与所述第一、第二金融机构和所述系统关联的所述第一、第二以及第三子组用户的资金的虚拟合并帐户；以及，基于所述第一子组用户的所述虚拟合并帐户中的资金的浮动收益，加所述第三子组用户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第一金融机构分发第一红利。

[532]在一种实现方式中，该方法包括，基于所述第二子组用户的所述虚拟合并帐户中的资金的浮动收益，加所述第三子组用户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第二金融机构分发第二红利。在一种实现方式中，该方法包括：从所述第一子组中的第一用户接收向所述第二子组中的第二用户转帐的指示，其中，资金不在所述虚拟合并帐户外部转移。指示可以以无线方式通过SMS消息从移动电话进行发送。指示可以以无线方式使用在所述移动电话上执行的应用程序从移动电话进行发送。指示可以通过因特网浏览器进行发送。

[533]在一种实现方式中，每一个用户都只与所述第一金融机构、第二金融机构，或系统中的一个关联。在一种实现方式中，该方法包括：从所述第一子组中的第一用户接收向所述第三子组中的第二用户转帐的指示，其中，资金不在所述虚拟合并帐户外部转移。在一种实现方式中，该方法包括：管理虚拟合并帐户的记录系统，其中，所述记录系统包括所述第一、第二以及第三子组中的用户的交易的记录。

[534]图46显示了根据本发明的实施例的快速购物的方法。在一个实施例中，招贴画、报纸广告、或电视广告包括允许购物者获取显示在手机上的有关产品的具体细节的机制。此机制可以包括打印的条形码或拨入即可获取信息的电话号码。在另一个实施例中，利用近场通信来启动购物者和远程商家之间的连接，如4601所示。通过启动该连接，会激活MCA，以便如果购物者决定进行购物，则MCA被唤醒，并已经建立连接，如4602所示。通过选定Buy Request选项，如4603所示，购物者可以与支付服务器进行购物交易，处理诸如“发货给”地址和资金转帐之类的细节。在较短时间内，可以从几分钟到几天，订购的产品将被发出，如4604所示。

[535]在另一个实施例中，帐户持有人具有选择“投递到当前地理位置”的选项，而不是帐户持有人的帐单地址。当帐户持有人正在旅行并希望从客房送餐服务菜单中进行订购而不希望对任何人说时，此功能特定需要。在此情况下，菜单将包括近场通信设备，如此，帐户持有人将只须选择Buy Request，食品将提供给帐户持有人所在的房间。

[536]图47显示了根据本发明的实施例的再一个快速购物功能。在此实施例中，帐户持有人预期产品或服务的定期出现的支付。为说明问题，请看典型的持月票乘客，每天早上，在登上火车驶入市区之前，停下购买报纸。对于图47中所显示的实施例，帐户持有人可以为这样的定期出现的支付设立预先授权的帐户，如4701所示。预先授权的帐户可以包括可以获取的产品或服务的类型，如4702所示，以及要预先授权的最大允许的购物金额，如4703所示。如此，当持月票乘客买了报纸，近场天线检测到手机上的帐户信息，并将交易金额发送到支付服务器，该支付服务器将会把确认发送回商家，无需等待消费者验证，具体地，授权进行金融交易，如4704所示。此功能也是对于时间紧迫的金融交易加速购物处理的重要手段，如当持月票乘客在他们经过十字转门时希望使用他们的手机支付地铁票时。预先授权的金额可以实时地扣除，或者，作为批处理的金融交易来进行处理，例如，一小时一次。

[537]为最小化验证处理时间，可以在预期的使用之前，将预先授权情况通知给商家。在预先授权接收到时，电话号码可以放置在“绿名单”中，指出商家可以接受支付，无需来自支付服务器的验证。绿名单存储在POS终端中，或能够被POS终端从本地服务器进行访问，而不是从交易服务器进行访问。

[538]如果预先授权的帐户已用完，而帐户持有人没有及时地补充该帐户，则电话号码可以放在“红名单”中，并禁止未来使用该服务。红名单也可以由商家本地存储在POS中，或存储在连接到POS设备的本地服务器中。如果电话号码包括在红名单中，则商家可以接受替代的支付形式。或者，服务器可以拒绝服务，并发送一则消息，建议帐户持有人借此机会对帐户持有人的帐户进行再充值。商家可以接受再充值支付，并收取收到对帐户持有人的帐户进行再充值的资金的奖励费用。

[539]为了加快预先授权的购物，在一个实施例中，手机包括从外部可见的条形码，可以在POS上扫描，该条形码，以启动和结束交易。或者，条形码可以显示在手机的屏幕上，并在POS上被扫描。由于对于许多日常的购物速度和方便性是如此重要，条形码，连同本地高速缓存的绿名单，使得商家“动态地”接受购物，然后在选定时间间隔内以批处理模式提交交易。

[540]对于帐户持有人的一个优点是，如果手机丢失，可以要么通过访问Web页面，更新用户资料，要么通过呼叫顾客服务中心，快速地暂停预先授权。如果报告手机丢失，则将新的绿名单和红名单立即分发给受影响的商家，从而缩小帐户持有人和商家的潜在的损失。比较一下丢失的预存款的月票的情况—如果丢失，则该月票的全部价值也丢失，谁捡到了谁获益。如此，绿名单和红名单是防止通过盗窃电话对于预先授权的帐户进行欺诈的有效工具。

[541]由于并非当今使用的每个手机都是配备应用程序的，因此，支付服务器适应于对每一个帐户持有人都可用的服务级别。用于在手机设备之间传递消息的一种方法是使用短消息服务(通常也称为“SMS文本消息”，或简单地，SMS)来传输与接收，因为大多数移动设备都支持SMS。SMS是用于通过移动网络提供短消息的机制。它是往返于手机传输消息的存储转发方式。来自发送方手机的消息(仅限文本)存储在与SMS传输系统关联的服务器中，该服务器稍后将它转发到目标手机。这意味着，如果收件人不可用，则消息被存储，并稍后发送。由于SMS使用信令信道而不是专用信道，因此，这些消息可以通过移动网络与语音服务同时发送/接收。对于基于所有三种蜂窝技术的移动网络，GSM、CDMA、以及TDMA都支持SMS，SMS现在是应用非常广泛的手机数据服务。

[542]利用SMS，SMS综合器在支付服务器和帐户持有人之间实时地路由消息，资金立即可供收款人使用。如果金融交易包括另一方，服务器也使用SMS，再次使用SMS综合器实时地与对方进行通信。当非帐户持有人是从帐户持有人的支付转帐的收款人时，SMS是特别重要的机制。非帐户持有人的问题是在他们的电话中没有嵌入MCA，如此，SMS是用于与非帐户持有人进行通信的机制。MCA管理和插入交易号，该交易号包括幂等性密钥，使得交易号对于数据服务SMS、HTTP，以及HTTPS协议消息唯一，但是，当使用手动SMS时，没有交易号。

[543]SMS移动金融交易系统避免了与只为支持和启用设备的金融功能而添加特殊芯片(即，集成电路器件)关联的成本和问题。向手机或其他移动设备中添加另外的组件会增大制造和支持的成本。如果需要许可证费用或其他专有的费用才能使用这种芯片，则成本进一步增大。此外，向手机中添加芯片会增大功率消耗，并缩短电池寿命—两者对于诸如手机之类的移动设备都具有负面效果。

[544]尽管SMS文本消息适用于各种类型的蜂窝设备和某些其他类型的移动通信设备，如便携式数字助理或PDA，但是，SMS会暴露未加密的密码或个人标识号(PIN)，以及余额信息或有关最近的交易的细节。由于拥有电话的任何人都可以阅读SMS消息文件并立即知道如何访问另一个人的帐户和其他机密信息，因此，最好避免使用公共的SMS消息来传输PIN。相应地，在一个实施例中，本发明提供了在通过SMS文本消息启动金融交易的情况下一部分交易通过音频信道来进行的方式。

[545]图48是由根据本发明的实施例的至少一个SMS消息机制执行的金融交易的系统级别的例图。此交易方法用于没有哪个手机支持因特网的情况。此外，手机也没有嵌入的MCA，如此，依赖于SMS消息来处理交易。本领域技术人员将认识到，如果其中一个电话是支持因特网的，并安装了MCA，那么，它这一端的交易将通过HTTPS链接进行，与另一个电话的通信将通过SMS消息进行。应该理解，HTTPS是指安全套接字层上的超文本传输协议，或HTTPover SSL，该链接是因特网链接。还应理解，因特网连接提供了非常丰富的用户界面，更加安全，启动并进行金融交易更加容易。当HTTPS不可用时，MCA可以修改交易以使用HTTP协议，这是一种安全性稍低一些的传输机制。在这种情况下，帐户可以在将交易信息发送到服务器之前以及在插入交易信息之前调用软件加密。

[546]如果因特网连接不可用，则在一个实施例中使用SMS(或短消息服务)消息。在一个实施例中，移动客户端应用程序利用数据服务功能来发送二进制SMS消息。在移动客户端应用程序不可用的另一个实施例中，使用明语SMS消息来进行金融交易，并采取了特殊的措施，以保护PIN的完整性。还应该进一步理解，缺乏移动客户端应用程序进一步会限制用户界面功能，如此，用户可以从本发明取得有限的满足，但是，然而，否则，会享受到本金融交易系统的全部功能和优点。

[547]利用本发明，移动客户端应用程序选择向服务器4804(也简称为交易处理器)传输金融交易的模式。例如，如果因特网连接可用，则使用HTTPS链接(这是对用户页面请求以及由服务器4804返回的页面进行加密和解密的Web协议)进行交易。要使用因特网，帐户持有人只需在Web页面上输入交易细节，并选择“发送”，以启动交易。如果涉及另一方，并且该方具有支持Web的设备，则在Web页面上提供交易细节。在此实施例中，服务器4804充当Web服务器。

[548]通常，并非所有的帐户持有人都具有支持因特网的手机或设备。因此，本发明提供了从手机进行金融交易的其他方法。这样的方法包括使用SMS数据服务、SMS明语(这两者都可以使用音频信道来传输PIN)或只使用音频信道。

[549]对于支持SMS的手机，帐户持有人通过SMS网关4802向服务器4804传输SMS消息，以从他们的手机4806启动交易，如流向箭头4810所示。网关4802将SMS消息中继到服务器4804，如流向箭头4811所示。在接收到SMS消息时，服务器4804采取在消息中请求的指定操作，并向网关4802发送回复SMS消息，如流向箭头4812所示。网关4802将回复SMS消息中继到手机4806，如流向箭头4813所示。此事件序列可以多次重复地进行，直到金融交易完成。可以通过任何电路交换或分组交换网络来在电话自动数值判定网关4802之间传输SMS消息。

[550]在一些实施例中，建立了话音通信信道，如音频信道4815和4835所示。当从电话4806接收到初始SMS消息时，服务器4804可以通过拨打与帐户关联的电话号码来打开音频信道4815。使用音频信道4815的一种情况是，获取PIN(作为DTMF或者语音数据来接收)，以完成验证过程，并响应SMS消息，对作为帐户持有人的用户进行身份验证。DTMF是指双音多频，是当电话的接触键被按下时电话公司接收到的信号。

[551]初始SMS消息以提供请求的交易的类型的关键字开始—PAY、REQUEST PAYMENT、BALANCE、TRANSFER或HELP。在SMS消息包含表示希望从一个帐户持有人向另一个帐户持有人划拨资金的关键字的情况下，关键字将是pay或requestpayment。在关键字之后，输入金额，带有小数点，也可以没有小数点。在金额之后，输入目标电话号码(或短代码、电子邮件地址、或其他标识信息)。此信息可以从移动设备的电话号码簿自动地获得。在电话号码之后，帐户持有人可以在消息字段输入向对方显示的消息。在某些情况下，此消息可以是虚消息。在某些实施例中，帐户持有人也可以输入补充的消息，用于记录的目的。消息字段中的特殊代码描述了补充的消息，以指出特殊代码之后的文本是专用的，不需要转发。代表性的特殊代码的示例可以是＊/＊/or/-/或其他唯一的用户定义的代码。

[552]一旦SMS消息被发送到服务器，就可以由帐户持有人输入PIN，并通过音频信道连接发送到服务器，以验证SMS消息。PIN是通过键盘输入的，可以是任何字母数字代码。然后，PIN作为DTMF编码消息，发送给支付服务器。

[553]在服务器上，服务器通过SMS文本消息通信路径接收SMS消息，并通过音频信道接收PIN。对服务器的访问可以由帐户持有人进行，也可以作为对接收到SMS消息的响应由支付服务器作为“回叫”功能来启动。优选情况下，PIN是作为DTMF编码的消息发送的，以维护安全性，虽然在其他实施例中，PIN可以由帐户持有人说出，并由在支付服务器或专用于处理语音电话的另一个服务器(未显示)上工作的交互式语音识别软件模块进行转换。

[554]为说明问题，请看当使用手机4506的帐户持有人通过发给服务器4504的SMS消息请求帐户余额时发生的过程。SMS消息由用户进行格式化，以包括请求的金融交易的类型，即，BALANCE(该请求的可以接受的简单形式可以是BAL，或简单地，B)，以及与他们的帐户关联的电话号码，例如，4088675309(例如，Jenny的电话号码)。或者，也可以通过使用呼叫方ID来确定帐号。

[555]当服务器4804收到SMS消息时，它首先检查序列号或交易号(例如，参见图54、55，以及56)。如果序列号是正确的，则服务器4804拨打与帐户关联的电话号码，并请求用户输入PIN。在其他实施例中，PIN包括在原始SMS消息中，如此，没有必要呼叫帐户持有人以便进行验证。如果手机4806配置有移动客户端应用程序，则可以在将密码包括在SMS消息之前对它进行加密。移动客户端应用程序将使用数据服务。使用SMS消息传输PIN的不利的一面是，此秘密的号码将对可以接触电话的任何人可见，并可能导致非帐户持有人未经授权的使用。

[556]如果PIN是正确的，则服务器4804处理请求的交易。用户可以选择通过利用音频信道4815的语音应答或通过返回的SMS消息(在此情况下，服务器向网关4802发送带有余额的消息，而网关4802又将消息转发到手机4806上)来接收请求的信息。

[557]在其他金融交易中，涉及了两个手机4806和4808。这类金融交易通常是一个帐户持有人向一个可以是与手机4808关联的帐户持有人的收款人转帐。在其他交易中，收款人是非帐户持有人。

[558]与BAL请求相同，给手机4808的用户的PAY请求是通过使用发给服务器4804的SMS消息启动的。SMS消息由用户进行格式化，以包括请求的金融交易的类型，即，PAY，收款人的电话号码(例如，2127875466)，以及与他们的帐户关联的电话号码，再次例如，4088675309。如果帐户持有人的电话支持移动客户端应用程序，那么，在手机4806和服务器4804之间交换的所有SMS消息都可以是经过加密的，以增强安全性。

[559]当服务器4804接收到SMS消息时，它首先检查序列号或交易号(如果可用)，只有在序列号正确或在由服务器维护的帐户记录中表示为不可用的情况下才继续进行。然后，服务器4804接收PIN，并判断PIN是否正确。如果序列号和PIN两者都正确，则服务器4804通过从与帐户持有人相关联的帐户划出(参见，例如，图43)并通过网关4802向帐户持有人发送确认SMS消息，来处理请求的交易。

[560]如果收款人4808是帐户持有人，则服务器4802也发送确认收到资金的确认消息。如果手机是移动PDA或其他支持IP的设备，则消息通过HTTPS进行发送，并可以是经过加密的，以确保安全性。加密可以通过任何已知的方法来进行。

[561]如果收款人4808是安装了移动客户端应用程序的帐户持有人，则移动客户端应用程序可以在将消息发送到服务器4804之前对其消息进行加密，并从服务器4804接收加密消息。

[562]如果收款人4808是帐户持有人，但是手机不支持在手机上下载和执行移动客户端应用程序，那么，来自服务器4804的消息将是明语。使用明语SMS消息传输PIN的不利的一面是，此秘密的号码将对可以接触电话的任何人可见。这可能导致非帐户持有人的未经授权的使用，除非帐户持有人花点时间从他们的手机的邮箱中删除SMS消息。如果收款人4808不是帐户持有人，那么，SMS消息也将是明语消息。

[563]尽管SMS文本消息适用于手机和某些其他类型的移动通信设备，如便携式数字助理或PDA，但是，SMS会暴露未加密的密码或个人标识号(PIN)，以及余额信息或有关最近的交易的机密细节。由于拥有电话的任何人都可以阅读SMS消息文件并立即知道如何访问另一个人的帐户和其他机密信息，因此，最好避免使用公共的SMS消息来传输PIN。

[564]如此，对于由合作伙伴服务提供商发出的移动设备，优选情况下，移动设备应包括移动客户端应用程序作为预先存在的软件模块。或者，优选情况下，移动客户端应用程序可从服务提供商下载到最初没有配备移动客户端应用程序的手机中。移动客户端应用程序对于金融交易系统的使用有显著的增强。移动客户端应用程序要么由帐户持有人直接调用，要么响应移动设备上的SMS文本消息功能的激活而调用。

[565]下面是说明了在有移动客户端应用程序可用的实施例中，使用SMS文本消息来使帐户持有人从任何支持SMS的移动电话或其他支持SMS的设备访问支付服务器的详细描述。

[566]在操作中，帐户持有人使用他们的电话上的现有的文本消息功能来向服务器4804发送文本消息。功能包括Pay、RequestPay、Balance、History和Help，通过使用这些功能中的任何一个作为关键字来调用这些功能。帐户持有人在文本消息的正文中输入关键字连同补充信息，以构建发送给服务器的命令。对服务器的访问可以通过免费的电话号码、短代码或电子邮件地址来进行，所有的这些都向SMS网关标识该服务器。短代码的一个示例是62729，被用作文本消息命令发送到支付服务器的目标电话号码。电子邮件地址的一个示例是sms@obopay.com，这是发送给服务器的SMS文本消息命令的电子邮件目标。

[567]要使用SMS方法向他人或商家进行支付，帐户持有人可以输入表C所显示的命令字符串。

[568]表C

关键字	PIN	目标移动电话号码	金额	消息(可选)
关键字	PIN	目标移动电话号码	金额	消息(可选)	pay	###	############		Abed

[569]每一项与前一项之间都应该有间隔。在一种实现方式中，关键字不区分大小写。移动号码应该包括区号加移动电话号码，在移动号码中没有空格。帐户持有人可以在电话号码中输入引导1，或不输入。美元符号不需要与金额一起输入，但是应该允许输入。用户可以可选地与他们的支付一起包括一则消息。MCA对消息进行加密，并作为数据服务SMS消息以二进制形式进行发送，而不是作为明语发送。

[570]在一个备选示例中，通过话音呼叫在第二消息中发送PIN。要使用组合的SMS加音频信道方法向他人或商家进行支付，帐户持有人可以输入表D所显示的命令字符串。

[571]表D

关键字	目标移动电话号码	金额	消息(可选)
关键字	目标移动电话号码	金额	消息(可选)	pay	############		Abed

[572]在接收到SMS消息时，服务器4804呼叫与SMS消息关联的手机以建立音频信道，获取PIN。PIN通过话音通信信道—即，蜂窝网络—发送到服务器4104。在备选实施例中，PIN是通过因特网或POTS发送的。

[573]当使用SMS方法或组合的SMS加语音方法对帐户持有人作出支付请求时，他们可以使用手动SMS文本消息系统来接受或者拒绝该请求。

[574]在服务器端，一个或多个数据中心将具有用于处理金融交易的系统。每一个数据中心都将包含PBX/ACD/VRU技术的组合，以允许多个同时的呼叫处理。可以使用VRU技术来提供可编程入站和出站DTMF支持。VRU可以连接到表示实际业务逻辑的企业J2EE系统和记录金融交易的记录系统。然后，J2EE系统可以与用于进行交易结算的实际银行集成。

[575]优选情况下，移动客户端应用程序确定用于发送PIN的首选的或最佳的方法，如通过应用程序SMS(数据服务)，其中，SMS消息是经过加密的，并被转换为二进制(即，消息不以明语进行传输)，或者，通过音频信道使用DTMF来维护安全性。在其他实施例中，PIN可以由帐户持有人说出，并由在服务器或专用于处理语音电话的另一个服务器(未显示)上工作的交互式语音识别软件模块进行转换。

[576]在一个备选实施例中，PIN由移动客户端应用程序进行加密，并包括在发送给服务器4804的后续的SMS消息中。服务器4804通过将电话号码和每一则消息的发送时间匹配来使消息关联。如果PIN是在与SMS消息相比在时间上较远的消息中发送的，则可以拒绝交易。如果只接收了两个消息中的一个，则可以拒绝交易。然而，如果及时地接收并验证了带有金融交易细节的SMS消息(至少有关键字)和PIN代码，那么，进行金融交易。

[577]在一个备选实施例中，当有音频信道可用时，移动客户端应用程序可以调用将PIN编码为DTMF形式的模块。然后，DTMF由MCA沿着由移动客户端应用程序建立的音频信道连接发送到支付服务器。模块可以是基于小键盘的输入而生成适当的音调的JavaAPI。DTMF是指双音多频，是当电话的接触键被按下时电话公司接收到的信号。

[578]在又一个备选实施例中，移动客户端应用程序在移动设备的显示屏幕上提供用户界面(UI)，引导帐户持有人进行金融交易。在此实施例中，通过自动插入关键字、金额、目标电话号码、密码，以及消息(如果有的话)，来引导帐户持有人完成构建SMS文本消息的过程。

[579]在又一个备选实施例中，SMS消息可以包括关键字、金额、目标电话号码和密码。此实现方式的缺点是，密码将对控制移动设备的任何人都可见。然而，本发明通过向帐户持有人发送消息，指示用户从帐户持有人的电话上的SMS日志文件夹中删除发送的消息，来控制此问题。该消息也可以建议，当将来使用SMS功能进行金融交易时帐户持有人应关闭记录传出的SMS消息的功能。

[580]本发明也可以不使用明语SMS消息，而是可以使用下载到手机中的JAVA API来进行金融交易。JAVA API生成用户界面屏幕，引导用户准备交易请求。消息格式与表C或表D中所显示的格式相似。

[581]一旦帐户持有人完成了交易请求，则用户选定显示在用户界面上的SEND选项。JAVA API使用蜂窝电话连接来启动话音呼叫，以访问服务器4804上的交互式语音识别(IVR)模块或DTMF接口。当DTMF接口捡起呼叫时，JAVA API使用DTMF音调来传输交易请求。JAVA API也可以使用加密的形式，以便在万一DTMF音调被秘密地记录的情况下不会被轻松地解密。当IVR提供对交易请求的响应时，响应也是经过加密的，然后，使用DTMF进行编码，并通过音频信道传输回有关方。由于JAVA API提高了安全性，此实施例优于发送明语SMS。

[582]因此，通信可以通过音频信道和DTMF音调来进行。这就提供了用于进行交易的另一个通信渠道(除SMS、数据服务或应用程序SMS、HTTP，以及HTTPS之外)。通过拥有许多通信渠道，这在系统中提供了更大的可靠性，因为当某些渠道不可用时，可以使用其他任何渠道。

[583]图49显示了根据本发明的实施例的用于保护基于SMS的金融交易的方法。更具体地说，对于诸如GSM手机之类的移动设备，在手机上安装MCA涉及以物理方式插入小型电路板，被称为加密和交易号生成器，或简称为生成器4902，以截取SMS消息通信。

[584]生成器4902包括插入到电话中的可与SIM卡4903通电的电路。在一个实施例中，生成器4902是插入在SIM卡4903周围的套子。或者，生成器4902是插入在手机的发射模块4904和SIM卡4903之间的垫片。SIM卡4903是用户标识模块卡，这是一种插入到手机或其他基于GSM、GPRS或3G的移动设备中的用于向网络标识用户的电子卡。

[585]虽然SIM卡最广泛地用于GSM系统中，但是，兼容的模块也用于UMTS UE(USIM)和IDEN电话中。SIM卡4903包含用户的个人标识号，诸如用户的电话号码、电话簿、SMS消息之类的信息，以及其他与用户相关的信息。

[586]生成器4902截取传入的SMS消息，寻找来自服务器1004的消息(参见图48)。当生成器4902检测到由服务器4804发送的SMS消息时，它通过对SMS数据服务消息进行解密，并给帐户持有人呈现明语消息，就像移动客户端应用程序那样工作。

[587]生成器4902也截取发往服务器4804的传出的SMS消息。再者，生成器4903还通过向每一次交易添加交易号来提供移动客户端应用程序的服务，并对SMS消息进行加密。由于生成器4902包含嵌入式软件模块，因此，它可以作为数据服务SMS消息而不是作为明语来发送SMS消息。

[588]生成器4902计划作为单独的组件出售或以别的方式提供，使得没有配备MCA的手机获得移动客户端应用程序驻留在手机上的优点。在其他实施例中，SIM 4903是作为插件板电路来包括生成器4902的，并通过手机的服务提供商提供给用户的。

[589]图50显示了根据本发明的一个实施例的安全的SMS聚集服务器的用途，其中，生成器4902还将传出的SMS消息重定向到安全的SMS聚集服务器5011，而不是重定向到服务提供商的标准SMS服务器。通过向安全的SMS聚集服务器发送包含金融交易信息的SMS消息，最大限度地降低了数据被窃的机会，降低了由于SMS服务器5010中的超载而导致的消息延迟或丢失，并改善了对消息投放系统的总体控制。

[590]现在请参看图51，该图显示了根据本发明的实施例的新帐户持有人的注册过程。当资金的收款人还不是帐户持有人时，本发明的一个实施例调用一个病毒式的新的客户获取方式，现有的帐户持有人通过简单地向非帐户收款人汇款来带进新帐户持有人。非帐户收款人收到一个SMS消息，说明他们收到了汇款，并邀请他们进行注册，才能访问资金，如5101所示。提供了Web地址。

[591]注册可以在任何银行合作伙伴那里进行，或通过因特网访问Web页面在线地进行注册，如5102所示。注册过程允许收款人开立一个预存款(使用划拨的资金)贷记账户。此过程类似于开立任何其他银行帐户，只是没有最小帐户余额，如此，甚至没有资格在银行获得支票或储蓄帐户的个人也可以参与。

[592]一旦进行了注册，新帐户持有人具有“无卡”受限制的帐户，如5103所示。在此阶段(阶段I)，新帐户持有人能够实时地查看他们的预存款贷记帐户中的资金。然而，由于银行规则，新帐户持有人的帐户的对资金的访问权限是受限制的，直到完成OFAC报告，如5104所示。“OFAC”是指美国财政部的外国资产控制局，该局根据美国外交政策和国家安全目标，针对指定的外国、恐怖分子、未经批准的国际毒品走私犯，以及那些参与与未经批准的大规模杀伤性武器的扩散相关的活动的人，进行管理和实施经济和贸易制裁。

[593]对照可疑人员名单审查帐户持有人是OFAC适应性计划中的基本步骤。如果帐户持有人被标记为潜在的与OFAC名单匹配，则进行调查，以判断是否事实上真的匹配。直到解决之前，资金不会被放行。在市场上可以购买到软件程序包来用于进行适应性检查。适应性检查识别重复的客户记录，在个人和公司之间建立链接，以便进行传统的和非传统的家庭理财，创建多功能“家庭理财”键以随着时间的推移跟踪变化，以及建立基于规则的处理过程以解决重复，并创建链接和家庭理财。

[594]一旦OFAC适应性检查完成(该过程通常大约要花24小时)，并没有发现不利的链接，帐户持有人会变为“无卡”帐户，这意味着，金融机构可以开立预存款借记卡账户，并将塑料借记卡发送给新帐户持有人，如5105所示。然而，在此阶段(阶段II)，新的无卡帐户持有人对资金只有有限的支配权。例如，新帐户持有人可以使用本发明的金融交易系统将资金转帐到其他个人，但是由于额外的政府限制，资金不能被提取或转帐到一个商家。

[595]在本发明的系统的后端处理部分，如果收款人还不是帐户持有人，则合并保留帐户保留着划拨的资金。总帐条目标识属于每一个电话号码的资金(参见图39)。这些资金可以由收款人转帐到其他帐户(如果他们注册了帐户)。由于不能强迫个人注册帐户，因此，收款人有可能主动地拒绝资金或简单地不作回应。在这样的情况下，在交易窗口到期之后(交易窗口可以是选定的时长，如30天或60天)或当主动拒绝时，资金被退回到启动该交易的帐户持有人。交易服务器可以向资金的汇款人和收款人发送定期的提醒消息。在其他情况下，如果收款人还没有进行注册以获取访问资金的权限，则资金的汇款人可以停止支付。此功能在各方同意取消电子转帐并以另一种方式进行交易的情况下—例如，使用现金，很重要。

[596]如果所有帐户持有人的资金都保留在合并帐户中，那么，当新帐户变“活”，则新帐户持有人对资金具有完全的即时的存取权限。如果资金对于每一个帐户持有人都保留在单独的帐户中，则当帐户变“活”时，资金从保留转帐到帐户持有人的帐户。可能有某些延迟，资金才会出现在个人帐户中。

[597]一旦开立了帐户，并通过了适应性检查，金融机构将塑料借记卡发送到新帐户持有人的记录中的地址。当卡到达时，帐户持有人拨打免费电话号码，确认收到。该确认电话还表明，该帐户持有人的地址是正确的。

[598]在拨打此电话过程中，帐户持有人还选定他们的PIN。PIN链接到卡和帐户持有人的移动电话的电话号码两者。此外，塑料借记卡上的帐号和电话也被锁定在一起。卡可以用来通过任何银行的ATM从帐户中提取现金或向帐户中储蓄现金。它也可以在有POS设备接受信用卡和银行卡的任何商家销售场所使用。在此阶段(阶段III)，帐户持有人的帐户完全被启用，供持有人使用。

[599]现在请参看图52，分层的欺诈检测系统5200是作为交易处理器3630的一部分显示的。分层的系统5200的第一层包括基于规则的引擎和用户选定的组件5201。分层系统5202的第二层包括专有的组件，帐户持有人不能访问这些组件。

[600]用户选定的组件包括，例如，帐户持有人为他们的帐户自定义安全性的能力。帐户持有人可以链接被授权访问预存款帐户的家庭成员的多个手机号码。对于每一个指定的电话号码，帐户持有人可以指定每天、每周或每月的最高花费限制。帐户持有人可以通过为指定的排除的各方创建个人“黑名单”，排除某些商家、帐号或电话号码。

[601]特定的黑名单实现方式允许帐户持有人指定通配符排除项，如阻止向具有特定区号的任何电话或向任何“900”或外国号码进行转帐。帐户持有人可以为被授权的用户创建单独的个人黑名单。此功能对于控制配有手机的孩子不适当的花费特别有用。可以有任意数量的号码或帐户包括在黑名单中。

[602]相反，帐户持有人也可以指定可以包括在涉及某一个被授权的用户的金融交易中的某些商家或电话号码。所有其他商家和电话号码都可以可选地被视为在个人黑名单上。再者，此功能通过允许孩子购买车票、午餐，以及学校的供应品，但不允许购买杂志或其他新奇品，对于控制孩子的花费特别有用。

[603]除指定个人黑名单和白名单之外，帐户持有人也可以预先授权在出现在白名单上的每一个商家那里的购物，而对白名单上的其他号码设置每次交易的限制。

[604]帐户持有人可以自定义基于规则的欺诈检测机制，该机制也在第一层实现。

[605]帐户持有人也可以指定每一次交易的最高金额，以及在选定时间段内在手机上可以处理的交易的数量。帐户持有人也可以指定要存放和保留在预存款贷记帐户中的资金的最高金额。交易处理器3630每天将多余的款转移到另一个指定的帐户，如个人储蓄帐户。

[606]分层系统5202的第二层包括专有的组件，帐户持有人不能访问这些组件。例如，第二层5202包括基于历史平均值、地理验证，日常交易的历史数量所作出的最高花费限制。这里也可以实现其他基于规则的欺诈检测和交易频率(速度)控制机制。

[607]欺诈和风险规则引擎(未显示)，是通过应用花费限制，并从风险的角度确定请求的交易的可接受性，来控制风险的。这样的欺诈检测系统是已知的，常常在使用信用卡时用于监视欺诈。可以挖掘为每一个金融交易收集的信息，供商家以及消费者增值应用程序、商业监视应用程序、系统操作应用程序和安全监视应用程序使用。

[608]现在请参看图53，该图显示了最小化ACH和信用卡交易费用的合并帐户实施例。本实施例不是为每一个帐户持有人维护一个单独的预存款贷记帐户，而是利用合并预存款贷记帐户5300。当在帐户持有人之间进行交易时，如5301所示，资金被保留在合并帐户5300中，但是，从一个帐户持有人的帐户移到另一个帐户持有人的帐户。转帐是直接的，对于系统运营商，不会产生任何交易费用。因此，可以向帐户持有人收费，几乎没有交易费用，或者很少。

[609]有时，帐户持有人可以向合并帐户中添加资金，如5302所示。这样的资金可以存放在同意从帐户持有人接受资金的合作商家那里，然后，这些资金储蓄到合并帐户中。或者，帐户持有人可以利用他们的塑料借记卡在ATM存现金或支票，在因特网上进行，或用电话进行转帐，或自动地进行，如在与每一个帐户关联的用户资料页面所指定的。

[610]在其他时候，帐户持有人可以向合并帐户之外划拨资金，如5303所示。当新帐户持有人不希望在他们的预存款贷记帐户中保留余额时，他们可以提取这样的资金。

[611]在此实施例中，系统运营商是帐户综合商，就风险和风险控制而言，变为记录系统。系统运营商还负责进行OFAC适应性检查。系统运营商可以是银行、金融机构，也可以将合并帐户管理转包给另一个银行。

[612]在一个实施例中，使用近场通信来在移动设备之间进行通信以使用本发明的基础架构进行金融交易。在再一个实施例中，使用近场通信在移动设备与POS终端之间进行通信，以进行金融交易。

[613]安全性和防欺诈

[614]安全性和防欺诈对于支付行业是重要的议题，并且是持续的问题来源。根据本发明的移动支付转帐基础架构和操作方法，是针对这些问题的有效工具。具体来说，通过使用移动设备来进行金融交易，可以进行实时的交易，使用的资金保证可用。接收方可以验证持有资金的实体的合法性，以及帐户是否具有足够的余额来进行交易。优选情况下，不必提供帐户信息(信用卡号、借记卡号或位于金融机构中的其他帐户)即可进行交易。

[615]在交易的发起端，发送方使用PIN代码来标识通电话的人。这种验证提供了高水平的安全性，因为支付服务器能够使用呼叫方ID来识别移动设备，并通过PIN来识别使用移动设备的人。优选情况下，以安全的方式转帐的资金不会以可见的形式存储在移动设备中。

[616]另外，交易也可以通过唯一序列号码来进行标识，该唯一序列号码是由移动客户端应用程序确定的，并用作命令流的一部分发送到支付服务器。在支付服务器上，维护了所使用的序列号的历史，如此，带有以前所使用的序列号的交易将不会被处理。在每一次交易之后和在下一次交易之前，移动设备利用新的序列号更新该序列号。例如，新的序列可以是旧的序列号增加1。在一种备选实现方式中，序列号可以是任何数字，包括随机数。此外，也可以使用创建可预测的数字序列的算法。此数字序列可以使用从有关诸如电话号码、时刻之类的信息或其他信息的散列函数创建的种子来生成。在进行初始化时，给支付服务器提供了初始序列号，知道算法和种子，如此，它可以预测下一个应该是什么序列号。如果序列号不正确，则服务器拒绝交易。这可以有助于防止诱骗攻击。

[617]序列号有助于防止欺诈，还避免了金融交易的重复，重复可能是由于通信协议引起的，交易信息可能被发送多次。这类似于这样的情况：如果传真机没有收到正常的确认，它会试图再者发送传真。

[618]如果使用SMS消息来完成交易，则授权PIN优选情况下是朗读到移动设备中并传输到支付服务器的口头代码，以便使用语音识别软件进行验证。

[619]商家交易优选情况下是使用活动的授权，其中，帐户持有人的电话收到一则消息而响起，让批准转帐的美元金额。信用卡和支票不能利用此水平的交互进行操作。

[620]通过使用PIN代码激活移动客户端应用程序，来提供更大的安全性。在此实施例中，PIN代码出现在第一个实例中，打开移动客户端应用程序，并启动其操作。同一个PIN代码，或者，优选情况下，一个单独的PIN代码用于通过网络对交易进行授权。这种双PIN代码处理对信用卡、支票或者智能卡不可用。

[621]当检测到欺诈时，可以禁用该移动设备，并阻止其使用网络来访问帐户。一般而言，移动设备具有多个关键属性，促进未来的安全保护。如果不是全部至少大多数这些属性不存在于卡上。具体地，移动设备包括独立的电源来运行物理设备，如专用芯片，以及可以罩住诸如智能芯片之类的设备的安全外壳。移动设备允许通过语音以及通过蜂窝网络或通过因特网进行通信，如此，可以将语音验证和PIN结合起来使用，或单独地使用，以标识帐户持有人。可以通过使用语音识别技术并利用通过键盘输入的数据，启动和验证交易。在其他实施例中，图像通信是通过使用照相机提供的。

[622]另一个安全层是通过使用定位技术(如地球定位系统)来提供，或者GPS可以确定设备的物理位置。如此，如果帐户持有人在非典型的位置(如当他们正在休假时)使用支付服务，则可以通过要求重新输入PIN来鉴定帐户的用户。定位技术的另一个优点是，可以基于帐户持有人所在的位置，调整对帐户持有人可用的服务。例如，每当帐户持有人的位置匹配商家的位置时，可以与交易的确认一起发送折扣或特殊促销信息。在其他实施例中，如果帐户持有人位于某个正在提供特别折扣的商家的地区，则如果由支付服务器维护的该帐户持有人的资料授权，则可以向该帐户持有人发送促销消息。

[623]图54显示了根据本发明的实施例的用于防止欺诈和多重重复交易请求的机制和方法。防欺诈机制包括在每一个手机上的寄存器中以及在支付服务器中存储序列号。通常，如5401所示，当激活手机支付服务时，初始化序列号。同时，在支付服务器中初始化相同的序列号，并与帐户持有人的其他信息一起存储在数据库中。

[624]在接收到交易请求时，如5402所示，支付服务器从手机收到一个序列号，并将它与支付服务器中保留的序列号相比较。如果两个序列号匹配，如5403所示，那么，支付服务器授权交易继续进行。然后，将手机和支付服务器中的序列号更新为一个新的序列号。此安全机制用于防止诱骗攻击或克隆电话。然后，要求用户输入他们的PIN，如5405所示。通过将序列号与PIN和手机号码结合起来使用，有三级安全覆盖，对用户(PIN)、电话号码(通过呼叫方ID检测到并链接到特定帐户)和序列号进行验证，以验证交易防止入侵者企图捕获交易，然后再提交重复的交易请求)。序列号还用于区别SMS系统的用于提供交易消息的多次尝试与有效的多个交易。

[625]如果序列号不匹配，则支付服务器拒绝交易请求，如5406处所示，防欺诈措施被激活，如5407处所示。作为示例，当序列号不匹配时，帐户可以被冻结，直到客户服务代表可以确定序列号不匹配的原因。这可能需要打电话给帐户持有人，询问他们是否仍拥有他们的电话，以及他们是否授权进行所尝试的交易。

[626]图55显示了根据本发明的实施例的用于防止欺诈和多重重复交易请求的机制和方法的另一个实施例。

[627]在5510，用户(即，帐户持有人)在移动电话设备(例如，移动电话)上启动金融交易。在5511，用户在启动交易时传输PIN(选项A)。或者，如在5512所显示的，用户在启动交易时不传输PIN(选项B)。

[628]在5513处，支付服务器从移动设备接收启动金融交易的请求。服务器在5514检查由移动设备传输的呼叫者标识(呼叫方ID)编号，看看移动设备是否是系统的被授权的用户。如果在电话上没有启用呼叫方ID，则禁止交易，如5915所显示的。可以显示一个错误消息，以指出交易被禁止，因为呼叫方ID未启用。用户可以在启用呼叫方ID之后重试请求。

[629]如果选择了选项B，则服务器必须向移动设备发送一个请求，要求用户传输PIN，如5516处所显示的。此PIN可以通过移动设备的小键盘或语音(例如，向服务器的交互式语音响应(IVR)单元)进行传输。

[630]一旦验证了呼叫方ID，则服务器对照系统中记录的PIN检查从移动设备传输的PIN，以验证PIN是否匹配预期的电话号码，如5517处所显示的。当且仅当PIN匹配时，服务器才允许进行交易。如果PIN不匹配，则禁止交易，如5518处所显示的。

[631]然后，服务器从移动设备接收金融交易的交易号(也简称为序列号)。交易号可以在启动交易时发送，或以后作为移动设备和服务器之间的信息传输的一部分发送。交易号包括使其唯一的幂等性密钥。

[632]服务器还对照以前已经使用的交易号列表检查来自移动设备的当前交易号，如5519处所显示的。此列表存储在与服务器关联的数据库中。如果当前序列号匹配以前使用的序列号中的任何一个，则用户没有通过鉴定，交易将被禁止，如5520所显示的。此验证步骤对防止消息的多个副本被当做新的和独立的消息有用。对于黑客已经截取了一则消息并企图重新提交旧的交易的情况，还防止黑客攻击。

[633]在一些实施例中，服务器还对照存储在服务器中的预期的交易号，检查从移动设备接收到的交易号，如5521处所显示的。如果序列号不匹配，则用户没有通过鉴定，交易将被禁止，如5520所显示的。

[634]如果来自电话的序列号匹配存储在服务器上的序列号，或者是以前没有使用的编号，则用户通过鉴定，将允许金融交易进行。在一些实施例中，服务器只进行交易号验证，如5519处所显示的。在其他实施例中，服务器只进行交易号验证，如5521处所显示的。在其他实施例中，服务器只进行交易号验证，如5519和5521处所显示的。只要服务器确定来自电话的序列号是以前没有使用过的，或者是预期的序列号，或者两者，则将允许交易进行。序列号也可以被用作唯一的交易标识符。步骤5521通过链路5607连接到步骤5622。

[635]服务器还存储以前的序列号，或以别的方式在服务器中表示为已经使用的序列号，如5622处所显示的。这些以前使用的序列号可以存储在服务器上的数据库中。如果服务器维护一个预期的序列号，则电话和服务器中的序列号递增，以为下一次交易作准备，如5623处所显示的。然后，服务器继续完成金融交易，如5624处所显示的。

[636]一种三因素验证技术基于下列因素进行鉴定：

[637](1)检查呼叫方ID

[638](2)检查PIN或个人标识号

[639](3)检查交易号

[640]上面的验证方法按特定的顺序呈现一些验证步骤。本发明的一种实现方式按给定顺序执行这些步骤。然而，在本发明的其他实现方式中，可以有其他步骤，或者也可以省略一些步骤，或者步骤的顺序可以不同于上面的顺序。例如，呼叫方ID、PIN，以及交易可以不按顺序。因此，在一个实施例中，可以在呼叫方ID之前检查PIN。在另一个实施例中，可以在PIN之前检查交易号。此外，上面的一些步骤还可以以并行处理的实现方式在不同的处理器或处理器核心中同时执行。

[641]在一种实现方式中，本发明的系统可以省略上面所列的一个或多个验证技术。例如，可以不鉴定呼叫方ID，如此，将使用两因素验证方法。

[642]两因素验证的传统的模式基于(1)您所拥有的和(2)您所知道的。第一因素是用户所拥有的某种东西，如移动电话、个人数字助理、智能电话，或塑料卡。第二因素是用户所知道的某种东西，如个人标识号(PIN)、母亲的婚前姓、街道地址、社会保障号码、驾驶执照编号，或家庭电话号码。

[643]是使用三因素还是使用两因素验证可以取决于移动设备和服务器所使用的通信渠道。例如，当使用SMS或数据服务SMS时，有呼叫方ID可用，则可以使用三因素验证。然而，当使用HTTP或HTTPS时，呼叫方ID通常不可用，则将不会使用三因素验证。可以有用于鉴定帐户持有人或用户的额外因素，如此，技术可以具有三个以上的因素。此外，验证的第三因素可以由客户端和服务器端软件组件来进行管理。

[644]示范性三因素验证流程

[645](1)在移动电话设备(例如，移动电话)上启动金融交易

[646](2a)(选项A)在执行步骤1时传输PIN。

[647](2b)(选项B)在执行步骤1时不传输PIN。

[648](3)在服务器上，从移动设备接收启动金融交易的请求。

[649](4)在服务器上，检查由移动设备传输的呼叫者标识(呼叫方ID)，看看移动设备是否是系统的被授权的用户。如果在电话上没有启用呼叫方ID，则禁止交易。可以显示一个错误消息，以指出交易被禁止，因为呼叫方ID未启用。用户可以在启用呼叫方ID之后重试请求。

[650](5)如果选择了选项A，一旦验证了呼叫方ID，则进入步骤6。如果选择了选项B，一旦验证了呼叫方ID，则服务器向用户的移动设备发送传输PIN的请求。此PIN可以通过移动设备的小键盘或语音(例如，向服务器的交互式语音响应(IVR)单元)进行传输。

[651](6)呼叫方ID已经验证，因此，对照系统中记录的PIN检查从移动设备传输的PIN。如果PIN匹配，则进入步骤7。

[652](7)从移动设备接收金融交易的交易号或序列号。此交易号可以在执行步骤1时发送，也可以以后在移动设备和服务器之间的信息传输中发送。进入下面的8a(选项C)或8b(选项D)。

[653](8a)(选项C)对照服务器中存储的序列号，检查来自移动设备的序列号。如果序列号不匹配，则用户没有通过鉴定，交易将被禁止。

[654](8b)(选项D)对照存储在服务器中的以前所使用的序列号的列表或数据库，检查来自移动设备的当前序列号。如果当前序列号匹配以前使用的序列号中的任何一个，则用户没有通过鉴定，交易将被禁止。

[655](9)如果来自电话的序列号匹配存储在服务器上的序列号(对于选项C)，或者是以前没有使用的编号(对于选项D)，则用户通过鉴定，将允许金融交易进行。对于选项D，换句话说，只要服务器确定来自电话的序列号是以前没有使用过的，则将允许交易进行。

[656](10a)如果选择了选项C，则电话和服务器中的序列号递增，以为下一次交易作准备。

[657](10b)如果选择了选项D，则电话中的序列号递增到下一个序列号。以前的序列号被存储在服务器中，或以别的方式表示为已经使用的序列号。这些以前使用的序列号可以存储在服务器上的数据库中。

[658]交易号或序列号验证的各种实现方式

[659](1)在服务初始化时，使用存储在移动设备和服务器上的初始交易号值。初始交易号可以是(1a)或(1b)。

[660](1a)初始交易号可以是整数，如0，1，2，3，4，5，6，7，8，9，10，或其他数字。

[661](1b)初始交易号可以是随机数，如由伪随机数发生器和给定种子所生成的随机数。此种子可以是基于设备的属性或特征的散列码。例如，种子可以基于电话号码、设备的序列号、设备的集成电路中的属性或存储的值，或实时时钟值。

[662](2)当用户使用那些使用交易号验证的应用程序时，交易号值将从初始或以前的交易号值变为序列中的下一个值。序列可以是任何级数，数学的、伪随机的或其他种类的。序列可以是有限的、无限的，或重复的级数。如果是重复级数，则在它重复之前级数中的交易号的数量可以基于用于表示交易号的二进制比特的数量。

[663](2a)例如，序列可以是算术的或几何的。对于算术级数的示例，交易号可以递增1或任何其他值(或递减1或任何其他值)，以获得序列中的下一个交易号。如果使用八个二进制比特来表示交易号，则序列将每隔256个数字就重复。如果使用十六个二进制比特来表示交易号，则序列将每隔65536个数字就重复。因此，所使用的比特数越多，序列就越长。

[664](2b)序列可以是由伪随机数发生器生成的伪随机数。伪随机数的序列将基于起始的种子值。伪随机数可以使用浮点数来表示。浮点数可以使用二进制浮点表示法来存储。

[665](3)在每一次交易之后，移动设备和服务器(在服务器中，将对照鉴定移动设备的交易号)两者都根据相同的算法生成序列中的下一个交易号。如果移动设备使用算术级数，则服务器也将使用算术级数。如果移动设备使用伪随机数级数，则服务器也将使用伪随机数级数。移动设备所使用的同一个种子也将供服务器使用。取决于特定实现方式，此种子可以从设备传输到服务器，或者反之，或者独立地确定。

[666](4)移动设备和服务器将各自存储相应的交易号。移动设备上的交易号可以简称为移动设备交易号。服务器上的交易号可以简称为服务器交易号。

[667](5)当交易进行时，服务器会将其存储的交易号与移动设备上存储的交易号进行比较。如果交易号匹配，则验证通过，交易将被允许进行。否则，交易将被禁止。

[668](6)在允许交易之后，在移动设备和服务器上，交易号将前进到序列中的下一个交易号。

[669]使用交易号来鉴定移动设备的这些技术可以帮助防止欺诈、重复交易，及其他不希望发生的情况。交易号验证的特定实现方式会有许多变化，可以使用这些变化中的任何一种，也可以与上文所描述的方法组合起来使用。例如，不是检查来自移动设备的交易号是否匹配服务器上的对应的数字，验证技术可以检查交易号是否(a)不匹配服务器上的对应的数字，(b)不匹配服务器上以前所使用的数字(如本申请前面所述)。

[670]图57显示了序列号验证的示例。有一个消费者计算机设备(例如，电话设备、智能电话，或便携式计算机)和企业应用程序。在消费者计算机设备上，有序列号验证(SNA)客户端软件组件。企业应用程序包括序列号验证服务器软件组件。当消费者设备向服务器发送交易时，这些组件进行验证。此验证可以是三因素验证方法中的第三因素。

[671]在特定实现方式中，客户端序列号验证组件跟踪经过加密的计数器，该计数器以随机非零值开始，是在客户端安装过程中设置的。在每一次交易时，客户端SNA组件都将客户端计数器值递增一个随机非零值。服务器序列号验证组件基于客户端标识符跟踪客户端的“最后收到的”计数器值。如果传入的客户端计数器值大于最后收到的值，则交易被接受。计数器值被存储，交易被执行。否则，如果计数器值不大于最后收到的值，则交易无效，可以暂停帐户。此实现方式只是一种，序列号验证有许多可能的变化。

[672]图58显示了序列号验证的另一个示例。在此特定技术中，取决于发起交易的客户端，使用不同类型的序列号，并将其发送给移动支付服务服务器。例如，可以使用胖客户端或瘦客户端。

[673]胖客户端的示例包括在移动电话、智能电话、便携式计算机或其他电子设备上执行的应用程序或程序。应用程序或应用程序的一部分可以以诸如J2ME、BREW或.NET CF之类的编程语言进行编写。应用程序可以是用于进行移动支付的特定的应用程序。在本申请的别处描述了这样的程序的示例以及伴随的用户屏幕。或者功能可以是另一个程序的一部分，如，即时消息程序、实时因特网聊天程序、文件传送程序、音乐播放器程序、视频播放器程序、文件共享程序、计费支付服务接口程序，或帐单分离程序。

[674]例如，当使用即时消息程序(例如，AOL Instant Messenger(AIM)、ICQ、Yahoo！Messenger、Microsoft Windows Live Messenger、Google Talk或Skype)时，将会有一个向另一个用户进行支付的选项。进行支付的选项可以通过右键单击鼠标或通过下拉式或层叠式菜单进行访问。接收者可以通过用户名、会员名、电话号码、会员号、帐号，或另一个标识符来进行标识。支付将通过移动支付服务服务器进行处理。

[675]瘦客户端的示例包括Web浏览器应用程序、具有SMS文本消息的电话或其他设备，具有WAP浏览器的电话或其他设备，或终端仿真程序。

[676]在本发明的特定实现方式中，当使用胖客户端时，存储的序列号将永久地存储在胖客户端中的计数器中。此存储的序列号可以遵循任何任意序列，如连续的整数或二进制计数器(例如，1、2、3、4，等等)，基于已知起始种子值的随机序列，或根据等式、公式或规则的序列。存储的序列号可以存储在，例如，快闪存储器、电可擦除的(E^2)存储器、非易失性存储器、带蓄电池后备电源的存储器、硬盘驱动器，或其他存储器中。

[677]对于每一次交易，向移动支付系统发送幂等性密钥(在本发明的其他实现方式中，叫做序列号)。对于胖客户端，密钥将包括会员ID和存储的序列号的组合。此存储的序列号可以是下一个未使用的存储的序列号。当移动支付系统接收到胖客户端的幂等性密钥时，交易与幂等性密钥一起被存储在交易表中。在交易表中，每一个幂等性密钥都将希望是唯一的。如此，如果移动支付系统接收到另一个具有以前接收到的幂等性密钥的交易，则该交易可以忽略，因为它可能是重复交易或安全性问题。

[678]在特定实现方式中，可以用潜在的违反安全记号来标记用户的帐户，以供人研究。如果用户具有许多这样的违规或在特定时间段内具有许多这样的违规，那么，可以自动地暂停该帐户，以便进行调查。

[679]在本发明的特定实现方式中，当使用瘦客户端时，幂等性密钥将包括会员ID、目标ID、交易金额，以及时间(或时间戳)。移动支付系统将接收此幂等性密钥，并与当接收到胖客户端幂等性密钥时情况类似地进行处理。

[680]因此，本发明的移动支付系统可以适用于不同类型的客户端，每一种客户端类型都可以发送不同类型的幂等性密钥或序列号。此实施例具有两种不同类型的幂等性密钥，但是，在其他实施例中，可以有任意数量的幂等性密钥或序列号类型。例如，可以有三种、四种、五种、六种、七种、八种，或更多种密钥类型。

[681]使用了确保请求系统执行交易的无线传输源的真实性的技术。交易可以是个人之间的汇款或其他价值交换交易。无线传输源可以是移动电话或其他类似的设备。无线传输源与交易请求一起传输密钥。系统将基于传输的密钥来确定传输的真实性。如果传输被确定为是真实的，则对交易进行处理。讨论了用于确定真实性的各种方法。也可以使用防止处理重复传输的技术。

[682]在一个实施例中，本发明包括接收从用户设备以无线方式传输的价值交换交易的电子请求；与电子请求与一起接收到与电子请求关联的传输的密钥；以及判断所述传输的密钥是否存在于交易表中。如果所述传输的密钥不位于交易表中，则传输将被视为真实的。因此，传输的密钥和价值交换交易被输入到交易表中，由系统对价值交换交易进行处理。如果传输的密钥位于交易表中，则传输不被视为真实的(或可能是重复传输)。因此，系统不对价值交换交易进行处理。用户设备可以是移动电话。

[683]在一种实现方式中，传输的密钥包括标识了请求了价值交换交易的电子标识符，以及序列号。序列号存储在用户设备中，在用户设备传输下一个价值交换交易之前前进到序列中的下一个编号。然后，每一次有效的传输都应该具有不同的或唯一序列号。

[684]序列号可以存储在用户设备中的非易失性或其它形式的永久性存储器中，如快闪、电可擦除的(E^2)存储器、磁存储器，或带蓄电池后备电源的存储器中。这将确保每一次传输都将具有唯一值。

[685]传输的密钥可以包括伪随机数，如使用伪随机数发生器并使用特定种子值生成的伪随机数。每次生成新的伪随机数时，种子值都将变化，如此，将生成伪随机数的序列。

[686]在一种实现方式中，传输的密钥包括标识了请求了价值交换交易的用户的第一电子标识符，标识了作为价值交换交易的目标的用户的第二电子标识符，价值交换交易的金额，以及与价值交换交易关联的时间。

[687]在一种实现方式中，价值交换交易可以是从与用户设备关联的第一用户向与另一个用户设备关联的第二用户汇款。例如，第一用户可以请求从第一用户的帐户向第二用户支付一定量的资金。

[688]传输的密钥不会显示在用户设备上，如此，用户将不会知道它。这可以对于防止尝试“克隆”另一个用户的帐户并使用另一个用户的帐户中的资金的人很有用。如果显示传输的密钥，则另一个用户可以比较轻松地确定序列中的下一个编号，使用函数或方程来生成密钥，或其他可以帮助对密钥进行反向工程的信息。在进一步的实现方式中，对传输的密钥进行加密，使得截取密钥的无线传输难以进行。

[689]可以通过用户设备的SMS文本消息服务来发出电子请求。密钥也可以使用SMS文本消息服务来进行传输。

[690]当使用不同类型的客户端或程序时，可以以不同的方式生成或获得传输的密钥，如通过不同的函数。例如，密钥可以包括不同的信息。当用户设备使用第一应用程序客户端发送电子请求时，密钥可以包括第一信息，当用户设备使用不同于第一应用程序客户端的第二应用程序客户端发送电子请求时，传输密钥可以包括第二信息。第一信息的示例可以是包括永久地存储的序列号的密钥。第二信息的示例可以是包括时间或时间戳的密钥。

[691]第一应用程序客户端可以是胖客户端，如在用户设备上执行的专用的价值交换交易服务应用程序(例如，以J2ME、BREW、或.NET CF编写的)或即时消息应用程序。第二应用程序客户端可以是瘦客户端，如用户设备上的SMS消息应用程序、用户设备上的WAP浏览器，或用户设备上的Web浏览器。当从胖客户端发送请求时，可以有永久性存储的值(如存储的计数器)，这将用于密钥中。然而，当从瘦客户端发送请求时，可能没有永久性存储的值，相反，时间或时间戳可以用于密钥中。系统将能够处理接收不同的密钥或不同的密钥类型。

[692]如果传输的密钥位于交易表中，这意味着，传输可能是以前发送的，或者某人试图侵入系统。可以暂停用户的帐户，并进一步研究事件。这将防止对用户的帐户的进一步的非法交易。

[693]此外，对价值交换交易进行处理的过程可以包括为价值交换交易生成交易标识符号码。此交易标识符号码将由对请求进行处理的系统生成。可以向用户设备发送包括交易标识符号码的电子消息。交易标识符号码在用户设备上可以是可查看的。这可使用户具有交易的参考编号，如此，用户可以直接与顾客服务代表讨论或询问有关交易的情况。此交易标识符可以与身份验证密钥(在用户设备上生成)完全不相关。交易标识符可以由处理交易的银行合作伙伴生成。在备选实现方式中，密钥可以用于生成或创建交易标识符。

[694]在一个实施例中，本发明包括接收从用户设备以无线方式传输的价值交换交易的电子请求；接收与电子请求关联的传输的密钥；生成预期的密钥；将传输的密钥与预期的密钥进行比较；以及，如果传输的密钥匹配预期的密钥，则处理价值交换交易。价值交换交易可以是从与用户设备关联的第一用户向与另一个用户设备关联的第二用户汇款，其中，用户设备是移动电话。

[695]生成预期的密钥的过程可以包括使用为与价值交换交易关联的用户帐户存储的种子值对一个函数或方程进行求值。此外，用户帐户也可以存储有关用来生成预期的密钥的特定函数或方程的信息。例如，一些用户可以使用一个特定函数来生成密钥，而其他用户使用其他函数。对于不同的用户，使用不同的起始种子，在每一次使用之后，将创建新的种子，用于生成下一个密钥。换句话说，该方法进一步包括在对函数进行求值之后，确定序列中的下一个种子值，并用序列中的下一个种子值替换为用户帐户存储的种子值。

[696]例如，用户设备具有计数器，用于在特定序列中的进行计数，并使用特定的函数(例如，伪随机数发生器)生成此序列中的密钥。在服务器端或系统端，服务器将知道预期的密钥，因为它存储在用户的资料中，还将知道用来生成密钥的函数。如果预期的密钥匹配传输的密钥，那么，用户的请求通过鉴定。如上所述，所使用的函数或方程可以每个用户地或每个设备地，或者甚至每次使用时发生变化。用来生成预期的密钥的函数或方程的标识将存储在系统中的某处，如存储在用户的资料中。

[697]具体来说，本发明可以包括：从与价值交换交易关联的用户资料中检索种子值；从用户资料中检索有关用来生成传输的密钥的函数的信息；以及，使用种子值对函数进行求值。如上文所讨论的，本发明的方法可以包括也可以不包括不同的函数。在这样的情况下，函数信息将不需要存储在资料中。

[698]如果传输的密钥不匹配预期的密钥，则不处理价值交换交易。可以暂停与价值交换交易关联的用户帐户，以防止进一步的资金转移，因为已经发生了违反安全的情况。可以向系统管理员对帐户进行标记(例如，显示在屏幕上，发送电子邮件，发送即时消息)，让系统管理员进一步进行研究。或者可以发送一个自动化电子邮件，以联络顾客服务代表，因为用户的帐户已经发生了违反安全的情况。

[699]对价值交换交易进行处理的过程可以包括：为价值交换交易生成不同于预期的密钥的交易标识符号码，向用户设备发送包括交易标识符号码的电子消息，其中，交易标识符号码显示在用户设备上。

[700]支付系统基础架构—移动客户端应用程序(MCA)

[701]在一个实施例中，MCA基于Java 2平台，企业版(J2EE)，这是简单直观的界面。结果，帐户持有人输入他们的请求数据—如金额、电话号码，或其他帐户身份信息，如接收方帐户的电子邮件地址或即时消息ID，以及PIN。MCA设计得配置起来灵活简便，对于不同的语言，具有不同的版本，设计为在Java 2 MobileEdition(J2ME)、.NET、以及WAP、BREW、Symbian，以及SIMToolkit或其他移动协议下运行，并可以端接到诸如蜂窝设备、PDA或其他移动电子设备之类的平台上。Java、.Net、Brew、Symbian和Sim Toolkit被认为是它们的相应的所有者的商标。MCA还可用于电话操作系统，包括Nokia、Motorola、Samsung、Sanyo，及其他常见的品牌。优选情况下，在移动设备上不需要特别的半导体器件或“芯片”执行安全的经济合算的，以及移动金融交易。

[702]为启动操作，帐户持有人在他们的移动电话上安装(或已经安装)MCA。应用程序的提供可以以下列方式进行：

[703](1)以无线方式使用WAP推的方式提供，支付服务器向帐户持有人发送消息，以启动应用程序下载。或者，帐户持有人可以使用WAP拉的方式，向支付服务器发送消息，以启动该处理；

[704](2)在用户服务中心、合作商家位置近距离地提供，或移动服务提供商可以通过蓝牙、红外线或其他近场无线连接，安装MCA；

[705](3)因特网下载，帐户持有人可以通过因特网下载该程序，并通过USB端口安装它—或者甚至可以从一个电话将程序下载到另一个电话中；或者

[706](4)在SIM卡上，帐户持有人可以购买在SIM卡上已经安装了MCA的设备。

[707]在示例情况下，用户具有配备有近场通信功能的移动设备。用户可以查看他希望购买的产品。用户将用户的移动设备放在与产品关联的近场通信设备的附近。然后，移动设备的显示器查询用户是否同意交易，以购买产品。如果用户批准，则处理交易。用户将接收商品，如从交货地点领取，或者商品可以投递到用户的邮件地址处。可以提示用户输入PIN或质询问题，以验证他们已经批准交易。

[708]本发明的一个方面是移动支付系统或服务。本申请讨论了单个组件和元件的许多特定实施例和实现方式，这些实施例和实现方式的变化和修改，以及它们的组合。本发明的系统可以包括所讨论的变化或特定实现方式中的任何一种，单独地或以任何组合的形式。在本申请中，提供了移动支付系统的特定实现方式的示例，此特定实现方式是Obopay系统。Obopay系统只是移动支付系统的一种实现方式，用于比较轻松地描述本发明的各个方面。本发明包含了许多移动支付系统实现方式，不仅限于所描述的特定实现方式。

[709]移动应用程序处理移动客户端应用程序

[710]移动客户端应用程序允许人们通过他们的移动设备支付给朋友、商店，以及划拨资金。帐户持有人可以利用支持文本消息或移动因特网功能的移动设备，访问移动客户端应用程序，进行汇款或从任何人请求汇款。他们也可以实时地看到他们帐户的余额和历史。

[711]移动客户端应用程序支持下列功能：支付、余额、历史、请求支付、引荐或邀请，添加资金(即，加载)，设置，帮助。可以使用MCA从一个帐户持有人帐户向其设备支持文本消息的任何移动用户汇款。要进行汇款，必须是帐户持有人；然而，向其汇款的人或商家可以不是。

[712]金融交易可以由付款人或者收款人启动。如果付款人启动交易，则使用MCA来启动交易。要使用MCA从预存款贷记帐户汇款，帐户持有人将经过下列步骤序列：

[713](1)打开帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按“输入”继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、引荐或邀请、添加资金(即，加载)，设置，和帮助。

[714](2)然后，帐户持有人选择“支付”选项，进行汇款。这将把帐户持有人带到“支付”屏幕，帐户持有人将输入他们希望向其汇款的电话号码。

[715](3)要选择帐户持有人的电话簿中的电话号码，帐户持有人将选择选项(从移动设备上的左下方的软键)，然后查找(从选项菜单)，将显示出帐户持有人的现有电话地址簿，并允许他们选择其中的一个姓名。可选地，帐户持有人可以直接从小键盘输入电话号码。在另一个实施例中，帐户持有人输入短代码来标识所需的商家收款人。一旦帐户持有人输入了移动电话号码，他们将选择“确定”。

[716](4)这将把他们带到金额屏幕，帐户持有人将输入他们希望支付的金额。取决于收款人的资料，可能出现小费屏幕，提供给帐户持有人向金额中添加他们希望支付的小费的机会。

[717](5)当帐户持有人选择“确定”，他们将被带到消息屏幕，他们可以向他们的交易中添加消息。此消息可以是文本、音频或视频附件。如果帐户持有人不希望添加消息，他们可以只需在写入消息之前点击“确定”，将不会向交易中添加消息。如果传输网络的带宽有限，则帐户持有人会在消息的类型和长度方面受到限制。如果交易的接收方没有能够处理视频或音频消息的移动设备，则消息可以短时间地存储在服务器上，以允许通过因特网进行后续的检索。

[718](6)一旦帐户持有人选择“确定”，他们将被带到PIN屏幕，在此，他们将输入PIN，并选择“确定”。当输入PIN时，字母数字字符不会出现在屏幕上，而是显示伪字符。此外，也不能在移动设备上的消息日志或其他日志中查找PIN。如果另一个人能接触到移动设备，则他们将不能够确定PIN。

[719]这将把帐户持有人带到确认屏幕，该屏幕将显示下列信息：

[720]支付到：(目标电话号码)

[721]金额：

[722]任何相关交易费用：

[723]消息(如果他们留了的话)

[724]一旦帐户持有人选择了“确定”，则他们将被带到具有下列信息的屏幕：

[725]付款人

[726]如果目标收款人有现有的帐户

[727]消息

[728]支付到：(目标电话号码)

[729]金额

[730]日期：mm/dd/yyyy hh：mm

[731]Trans：xxxx

[732]如果目标收款人没有现有的帐户，那么，会出现这样的消息，如：注意：您支付的收款人不是注册的帐户持有人。给收款人发送一则消息，带有如何接收款项的指示。

[733]消息

[734]支付到：(目标电话号码)

[735]金额

[736]日期：mm/dd/yyyy hh:mm

[737]交易：xxxx

[738]收款人：

[739]如果目标收款人是现有的帐户持有人，则收款人将接收到一则消息，说明他们有一笔新的款项被添加到他们的帐户中。当他们打开该款项时，他们将看到一个带有下列信息的交易收据：

[740]日期：mm/dd/yyyy hh:mm

[741]金额：

[742]来自：(付款人电话号码)

[743]如果目标收款人还没有现有帐户，则收款人将接收到文本消息，说“您收到一笔款！”，并指示他们到诸如www.obopay.com之类的网站，进行注册，成为帐户持有人，并接收他们的资金。在本文档中稍后详细描述了新帐户持有人的注册过程。

[744]如果金融交易由收款人启动，则使用MCA，通过请求付款人进行支付来启动交易。收款人启动的交易的一个示例是，比萨饼外卖服务店在递送比萨饼之前拨打订购了比萨饼的人的电话号码。当通过移动设备应答时，帐户持有人被给予通过本发明的移动支付基础架构来进行付款的机会。

[745]要使用MCA从一个帐户请求资金，帐户持有人将经过下列类似的步骤序列：

[746](1)打开帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按“输入”继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、引荐或邀请、添加资金，设置，和帮助。

[747](2)然后，帐户持有人选择“请求”选项，请求进行支付，将输入他们希望发送他们的请求的电话号码。

[748](3)要选择帐户持有人的电话簿中的电话号码，帐户持有人将选择选项(从移动设备上的左下方的软键)，然后查找(从选项菜单)，将显示出帐户持有人的现有电话地址簿，并允许他们选择其中的一个姓名。此地址簿可以对应于，作为说明，请求了比萨饼外卖的帐户持有人的电话号码列表。作为请求的一部分，外卖人可以附加一个小费屏幕，提供给帐户持有人向金额中添加他们希望支付的小费的机会。

[749](4)当收款人选择“确定”，他们将被带到消息屏幕，他们可以向他们的交易中添加消息。在一个实施例中，此消息可以是文本、音频或视频附件。如果收款人不希望添加消息，他们可以只需在写入消息之前点击“确定”，将不会向交易中添加消息。

[750](5)一旦帐户持有人选择“确定”，他们将被带到PIN屏幕，在此，他们将输入PIN，可选地输入小费，并选择“确定”。请求将被发送给付款人，付款人可以通过输入他们的PIN并按“确定”来批准交易的选项。正如上文所指出的那样，PIN是机密的，并且安全的，如此，未经授权的人不能只通过获得对移动设备的未经授权的访问来确定PIN。

[751]将首先处理支付，收款人将接收到支付通知。如果交易没有问题，则帐户持有人将不会接收到任何进一步的通知。如果支付确实出现问题的话(即，资金不足)，则将会通知帐户持有人和目标收款人。有关支付所发生的任何问题的通知将在进行支付之后迅速地发出，以便各方都可以确认交易。

[752]帐户持有人也可以使用MCA来从他们的移动设备检查预存款贷记帐户的当前余额。要使用MCA检查余额，帐户持有人将经过下列步骤：

[753](1)打开帐户持有人的电话上的MCA。

[754](2)这将把帐户持有人带到开始屏幕，显示徽标和标记行。帐户持有人将按Enter键继续。

[755]这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、设置，和帮助。帐户持有人将选择“余额”以检查他们的余额。

[756]这将把帐户持有人带到PIN屏幕，在此，他们将输入PIN，并选择“确定”。

[757]这将把帐户持有人带到余额屏幕，该屏幕将提供下列信息：

[758]日期：MM/DD/YYYY HH:MM

[759]余额：

[760]当帐户持有人选择“确定”时，他们将被带回主菜单画面。

[761]帐户持有人可以使用MCA从移动设备中查看最后n次交易的历史，其中，n是整数(例如，3或5)，以及预存款贷记帐户的当前余额。要使用MCA检查历史，帐户持有人将经过下列步骤：

[762](1)打开帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按Enter键继续。

[763](2)这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、设置，和帮助。帐户持有人将选择“历史”以查看他们的历史。

[764](3)这将把帐户持有人带到PIN屏幕，在此，他们将输入PIN，并选择“确定”。

[765](4)这将把帐户持有人带到历史屏幕，该屏幕将提供下列信息：

[766]交易日期和交易金额：MM/DD(+/-)$.$$

[767]帐户持有人将能够选择列出的交易中的任何一个，以获得有关该特定交易的详细信息。为此，他们滚动浏览到他们希望查看的具体交易，并选定它。这将把他们带到具有下列信息的屏幕：

[768]日期：MM/DD/YYYY HH:MM:SS

[769]金额：(+/-)$.$$

[770]收件人：收款人或付款人的电话号码)

[771]消息：(如果可用)

[772]然后，帐户持有人选定“确定”回到历史屏幕。从这里，他们可以查看另一个交易或返回到主菜单画面。

[773]此外，帐户持有人还可以将他们的帐户与计帐应用程序软件链接，以便每一笔交易都记录在数据库中，用于预算、计划、跟踪或用于缴税。在此实施例中，帐户持有人可以根据金融交易的特征，添加说明支付的第二消息，是发出还是接收。例如，当帐户持有人在出差途中购买了一顿饭，则第二消息可以指出交易是减税的，可补偿成本的。通过计帐应用程序软件来记录费用。计帐应用程序软件可以由服务器平台提供(参见图3)或由软件提供商合作伙伴提供。计帐应用程序软件可以是一个增值选项，帐户持有人可以支付每月的费用才能访问。

[774]当帐户持有人选择退回软键时，他们将被带回主菜单画面。

[775]正如上文所指出的那样，帐户持有人可以使用MCA从任何其他帐户持有人的帐户请求资金。请求资金的帐户持有人和向其请求资金的帐户持有人两者都应该是帐户持有人。在本发明的另一种实现方式中，服务允许向非会员请求支付交易(即，病毒式请求支付)。要使用MCA从帐户持有人请求支付，请求方帐户持有人将经过下列步骤。打开请求方帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕，显示徽标和标记行。帐户持有人按Enter键继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、引荐或邀请、设置，和帮助。

[776]帐户持有人将选择“请求支付”，以请求进行支付。这将把帐户持有人带到“发送给”屏幕，帐户持有人将输入他们希望向其发送他们的支付请求的移动电话号码。要选择帐户持有人的电话簿中的电话号码，帐户持有人将选择选项(从移动设备上的左下方的软键)，然后查找(从选项菜单)，将显示出帐户持有人的现有电话地址簿，并允许他们选择其中的一个姓名。一旦帐户持有人输入了移动电话号码，他们将选择“确定”。

[777]这将把他们带到金额屏幕，帐户持有人将输入他们希望支付的金额。请求方帐户持有人选择他们是否希望请求小费(即，请求者除他们正在请求的金额之外添加一个金额的能力。当帐户持有人选择“确定”，他们将被带到消息屏幕，他们可以向他们的交易中添加文本或音频或视频消息。如果帐户持有人不希望添加消息，他们可以在写入消息之前点击“确定”，将不会向交易中添加消息。

[778]一旦帐户持有人选择“确定”，他们将被带到PIN屏幕，在此，他们将输入PIN，并选择“确定”。这将把帐户持有人带到确认屏幕，该屏幕将显示下列信息：

[779]发送给：(目标电话号码)

[780]金额：

[781]小费请求(开/关)

[782]任何相关交易费用：

[783]消息(如果他们留了的话)

[784]一旦帐户持有人选择了“确定”，则他们将被带到具有下列信息的屏幕：

[785]请求者

[786]消息

[787]发送给：(目标电话号码)

[788]金额

[789]日期：mm/dd/yyyy hh:mm

[790]交易：xxxx

[791]被请求者：

[792]被请求者将从支付服务器接收到他们具有新的款项的消息。当帐户持有人打开款项时，它将打开MCA，这将把帐户持有人带到开始屏幕，显示徽标和标记行。帐户持有人按Enter键继续。然后，帐户持有人将被带到支付请求那里，在那里，他们将看到下列信息。

[793]消息(如果适用的话)

[794]支付到：(请求者电话号码)

[795]金额

[796]日期：mm/dd/yyyy hh:mm:

[797]交易ID

[798]收款人将能够接受或者拒绝对支付的请求。如果收款人接受请求，则他们将选择“接受”软键。如果收款人接受请求，小费请求已经由请求方帐户持有人进行了设置，接受请求将会把收款人带到小费金额屏幕，他们可以添加小费。一旦输入小费，选定“确定”，帐户持有人将被带到PIN屏幕。一旦收款人输入他们的PIN，选定“确定”，他们将被带到确认屏幕。确认屏幕包括下列信息：

[799]支付到：(支付请求者电话号码)

[800]金额

[801]小费(如果适用的话)

[802]一旦收款人选择了“确定”，则交易将被处理，收款人将被带到具有下列信息的屏幕：

[803]发送给：(支付请求者电话号码)

[804]金额

[805]余额：

[806]日期：MM/DD/YYYY HH:MM

[807]交易：(交易ID)

[808]一旦收款人选择“确定”，他们将返回到主菜单画面。

[809]如果收款人拒绝请求，他们将选定“拒绝”软键。支付请求者将接收有关他们的支付请求是被接受还是被拒绝的通知。通知将包括下列信息：

[810]消息：(如果适用的话)

[811]来自：(收款人电话号码)

[812]金额：

[813]日期：MM/DD/YYYY HH:MM:SS

[814]交易：

[815]帐户持有人可以更改帐户持有人可配置的默认设置。当前，这包括更改他们用来在他们的移动设备和服务器之间发送和接收支付信息协议(即，SMS或HTTP)。这也可以包括应用程序的将来版本中的其他帐户持有人可配置的信息。要更改他们的MCA上的设置，帐户持有人将经过下列步骤：打开帐户持有人的移动设备上的MCA。

[816]这将把帐户持有人带到开始屏幕，显示徽标和标记行。帐户持有人按Enter键继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、引荐或邀请、设置，和帮助。

[817]帐户持有人将选定“设置”以更改他们的设置。这将把他们带到设置屏幕，他们可以选定他们希望修改的设置。当前，只有一个选项是协议。当帐户持有人选择协议时，他们将被带到协议屏幕。帐户持有人将能够在协议屏幕上选定HTTP或者SMS。默认情况下，他们的应用程序被设置为HTTP。要返回到协议屏幕，帐户持有人将必须选定“退回”软键。要返回到主菜单，帐户持有人将必须选定“退回”软键。

[818]帐户持有人将能够从MCA查看“帮助”屏幕。这将包括应用程序的简要的描述，以及有关帐户持有人到哪里获得更多帮助的说明。要查看MCA的“帮助”部分，帐户持有人将经过下列步骤。打开帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕，显示徽标和标记行。帐户持有人将必须按Enter键继续。

[819]这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历史、请求支付、设置，和帮助。帐户持有人将选定“帮助”，查看帮助。这将把帐户持有人带到主“帮助”屏幕，该屏幕将提供下列链接：

[820]MCA的简要描述，如：

[821]Obopay可供您使用电话进行汇款、进行购物，以及催付款。还可以使用您的借记卡进行购物和提取现金。还有：

[822]到显示例如下列各项的功能页面：

[823]当执行下列操作时，您将被要求输入帐户持有人的电话号码，金额，以及PIN。还有：

[824]支付功能，显示，例如：

[825]利用移动或VOIP电话，使用Obopay支付功能向任何人进行汇款。如果他们没有预存款贷记帐户，则他们将被定向网站，建立一个帐户。要取消支付，请访问obopay.com了解详情。

[826]余额功能，显示，例如：

[827]使用“余额”功能了解您的帐户中可用的金额。

[828]历史功能，显示，例如：

[829]使用“历史”了解最近的交易以及可用余额。选定一个以了解详情。

[830]请求支付，显示，例如：

[831]使用“请求支付”要求移动电话帐户持有人付款。添加消息和要求小费是可选的。

[832]到“输入信息”上的帮助页面的链接，显示，例如：

[833]电话号码-当选定“支付”或“请求支付”时，输入带有区号的电话号码。无短划线或空格。

[834]金额，显示，例如：

[835]在$0.01-$9999.99之间。不必添加小数点—为美元金额添加零

[836]您的PIN，显示，例如：

[837]当您激活您的帐户时，提供您的PIN。如果您忘记了，请拨打888-80BOPAY

[838]链接到快捷方式的帮助页面

[839]退回：返回到前页屏幕。

[840]清除：擦除键入的最后一个字符。

[841]联系人：访问您的地址簿。

[842]退出：关闭应用程序。

[843]链接到FAQ的帮助页面

[844]安全性

[845]Obopay通过在网络层、应用程序层和交易层对交易进行加密，提供了安全的交易。有关详细信息，请访问www.obopay.com

[846]数据(因特网)计划

[847]您不需要数据计划即可使用Obopay。然而，您将需要数据计划，将Obopay下载到新的电话中。此外，数据计划还可以优化Obopay服务的性能。

[848]成本？

[849]提款吗？

[850]在接受信用卡的任何ATM中使用您的借记卡，或在www.obopay.com网站从Obopay请求支票

[851]取消交易

[852]要取消与非帐户持有人的交易，请访问www.obopay.com/help，选定“取消支付”。向帐户持有人的支付只能在交易未经授权(欺诈)的情况下才能被取消。要取消未经授权的交易，请拨打888-8OBOPAY

[853]添加资金吗？

[854]请访问www.obopay.com，选定“加载帐户”按钮

[855]忘记PIN。

[856]如果您忘记了，请拨打888-8OBOPAY

[857]链接到“技术支持”的帮助页面

[858]有关详细信息，请访问obopay.com或拨打888-8OBOPAY

[859]链接到“关于”的帮助页面

[860]软件版本

[861]文件大小：

[862]优选情况下，MCA允许帐户持有人创建离线资料，可以被配置为当他们的移动设备被关闭或在范围之外时自动响应。例如，帐户持有人可以配置他们的帐户，以自动吸收存款或自动接受从指定的帐户持有人的提款。如果帐户持有人的移动设备被打开，则可以通过拨到支付服务器，进行余额查询或历史请求，就可以检索任何离线交易。在其他替代方案中，帐户持有人可以指定，帐户信息通过SMS或电子语音邮件提供。

[863]有线协议

[864]MCA和平台有线协议

[865]概述

[866]MCA和平台有线协议与MCAP编解码器结合使用，以序列化/解序列化运行MCA的各种设备和提供基于J2EE的主机服务的数据中心之间的通信的数据。MCA和平台有线协议指定了在设备和数据中心之间传输的序列化数据的格式。MCAP编解码器是移动设备上的组件，数据中心根据MCA和平台有线协议规范，处理序列化和解序列化。图59显示了基本概念的简单例图。

[867]下面显示了来自移动设备的服务请求和示例有线表示。

[868]由移动设备启动的服务请求是Paymentservice.payP2P调用。此函数执行帐户持有人与帐户持有人之间的支付，Java方法签名是：

[869]public PaymentSummary payP2P(

[870] String srcDevKey，

[871] String srcPin，

[872] String tgtDevKey，

[873] String transactionAmount，

[874] String paymentMemo)throws Exception；

[875]附图中说明了返回值之外的一切。作为响应，除了开销，还包括返回值，返回值字符串以对象类型代码开始(在此情况下，9，转换为CommonPaymentSummary)，返回值的非空的属性跟随其后，例如，属性#1—paymentAmount—具有$1.27值等等。

[876]现在请参看图60，该图是显示了通过调用PaymentService.retrieveBalance调用，成功地调用服务电话的示例。此调用检索帐户的帐户余额。

[877]public BalanceSummary retrieveBalance(

[878] String devKey，

[879] String pin)throws Exception；

[880]

[881]请求部分与前一示例完全相同，虽，响应现在表示由于服务电话而引发异常。对象类型6表示类型EWPBusinessException的返回值，在图61中说明了其属性。

[882]来自移动设备的另一个服务请求和示例有线表示是PaymentService.retrieveHistory调用。如名称所指出的，此函数检索帐户的交易历史。

(883]public TransactionSummary[]retrieveHistory(

[884] String devKey，

[885] String pin)throws Exception；

[886]图62演示了成功的调用，这里唯一值得注意的是，返回值的“对象类型”(10)现在后面跟了阵列标志“<”，这意味着，返回值是对象类型10的阵列，表示CommonTransactionSummary。

[887]另一个设备启动的服务请求是用于从另一个会员请求支付的requestPay函数。

[888]public PayRequestSummary requestPay(

[889] String srcDevKey，

[890] String srcPin，

[891] String tgtDevKey，

[892] String transactionAmount，

[893] Boolean tipRequest，

[894] String memoText)throws Exception；

[895]payRequestPay函数用于对requestPay调用进行响应，此调用批准请求的支付。

[896]public PayRequestSummary payRequestPay(

[897] String payerDevKey，

[898] String payerPin，

[899] String tgtDevKey，

[900] String paymentAmount，

[901] String tipAmount，

[902] Boolean acceptRequest，

[903] String transactionRef，

[904] String memoText)throws Exception；

[905]另一个函数是RegistrationService.whoAmI函数，该函数与数据中心建立服务，当第一次调用应用程序时，被调用。

[906]public String whoAmI(String deviceNumber)throwsException；

[907]另一个请求的类别是由服务器发送的那些请求，这些请求的特征是，(1)它们当前只通过SMS发送；(2)它们通常是从服务器到设备的事件的通知；(3)没有对这样的请求的同步响应。

[908]为与处理设备启动的调用的MCA和平台体系结构一致，本发明在设备上作为“设备服务”实现了这样的通知的处理程序，与当从服务器端调用这些“设备服务”上的方法时，有相同的ServiceProxy签名。编解码器和有线协议与由设备启动的那些请求完全相同。这里是当前可用的“设备服务”和它们的方法的列表：

[909]J2ME支付服务

[910]P2pNotify—将p2p支付通知给目标

[911]requestPay—将requestPay请求通知给会员。

[912]notifyRequestPayReceived—将接收到请求支付的请求支付操作通知给目标。

[913]cancelViralNotify—将“病毒式”支付通知给“病毒式”目标

[914]MCAP的技术概述

[915]可以轻松地定义其他设备服务，并将它们添加MCA，它们被认为是基于特定实施例的设计考虑。

[916]现在讨论了MCA & 平台(MCAP)的高水平的设计，以及用户界面(UI)，呈现了MCAP预期的并且是所需的完整的一套移动功能。MCAP基本上是“移动钱包”或“通过电话支付”的消费者/移动-商家应用程序。MCAP的用户界面简单，它只需要一步接一步地输入请求数据(如金额、PIN，等等)，然后显示响应数据。通过例图和比较，MCAP的用户界面不需要移动游戏应用程序的图形复杂性。

[917]优选情况下，MCAP以轻松地被移植以在尽可能多的移动设备上执行的语言进行编写。然而，MCAP基础架构预期某些功能存在于移动设备上。例如，需要显示输入字段和捕获帐户持有人输入内容的功能。如果通过编程SMS API调用利用移动设备的SMS文本服务的能力不可用，则还需要通过编程性的HTTPS API调用来利用移动设备的数据服务的能力。

[918]通过编程API调用，利用移动设备的持久数据服务。例如，在SIM卡上或其他非瞬时存储器中永久地存储数据的能力是可选的功能。类似地，截取到移动设备的入站消息并“MCAP”以便进行处理的能力也是可选的。此功能提供，例如，截取入站SMS消息(在特定端口上)并通过MCAP处理它的能力。以编程方式与移动设备的“地址簿”集成以便特定输入字段可以“链接”到地址簿的能力也是可选的。通过声音、振动或光将值得注意的事件以编程方式将值得注意的事件通知给移动设备帐户持有人的能力是可选的。

[919]优选情况下，MCAP是模块化的，以便它在J2ME上轻松地实现，并在.NET以及J2ME、BREW、Symbian，以及.NETCF(以前的Windows Mobile)上证明

[920]图63显示了移动设备的高水平OMAP设计层。

[921]图64是显示了使用单一文本字符串(带有分隔参数/值对)的OMAP通信设计和请求/响应编码方案的流程图。

[922]图65显示了OMAP持久性设计，利用了移动设备永久性存储器机制，以及显示了OMAP用户通知设计的状态图。

[923]图66显示了实施例的OMAP屏幕调色板。

[924]图67是显示了OMAP屏幕转换的状态图。

[925]图68显示了OMAP主菜单的布局。

[926]图69显示了从来源角度来看的OMAP支付屏幕流程。在本发明的其他实施例中，“支付资金”功能可以叫做“汇款”。

[927]图70显示了从来目标角度来看的OMAP支付屏幕流程。

[928]图71显示了从源-请求角度来看的OMAP请求支付屏幕流程。在本发明的其他实施例中，“请求支付”功能可以叫做“获取资金”。

[929]图72显示了从目标-接受角度来看的OMAP接受支付屏幕流程。

[930]图73显示了其中目标拒绝请求的OMAP请求支付屏幕流程。

[931]图74显示了其中源和目标两者都接受请求的OMAP请求支付屏幕流程。

[932]图75显示了其中源和目标两者都拒绝请求的OMAP请求支付屏幕流程。

[933]图76显示了OMAP余额屏幕流程。

[934]图77显示了OMAP历史屏幕流程。

[935]图78显示了在源位置处的OMAP设置屏幕流程。

[936]图79和80显示了OMAP系统屏幕流程。具体来说，图79显示了未知移动ID的OMAP的屏幕流程。图80显示了其中请求失败的OMAP系统异常屏幕流程。

[937]图81到86显示了用于进行个人之间的支付的移动电话应用程序的用户屏幕和流程。在一种实现方式中，此应用程序是在移动电话上执行的独立应用程序，允许用户向其他用户发出支付，从其他用户请求支付，检查余额信息，检查交易历史，并执行其他功能。[938]用户可以更改诸如字体大小(例如，小、中，或大)之类的设置。可以选择用于与系统进行通信的协议，如HTTPS、HTTP，或SMS。用户可以要求，当接收支付时，有声音或光，或两者。有小费开关，如此，用户可以让小费屏幕在请求支付的目标上(或收款人的电话)上显示或不显示。然后，收款人可以发送比用户在请求支付中请求的金额支付更多的金额。

[939]有一个联系人菜单，用户可以保存联系人，并从其中选择要支付或请求支付的联系人。有一个消息或便笺字段，用户可以与发出支付或支付请求一起输入消息。例如，用户可以告诉目标，“资金4，午餐”。有一个让用户可以输入用户的PIN的屏幕。PIN将不会显示，而是将显示星号，空白，或另一个字符。可以有一个屏幕，列出全部交易，并给予用户在汇款之前确认交易的机会。如果有错误，当然，可以在发送之前对交易进行编辑。

[940]应用程序还可以进一步包括帮助或简要用户指南，以协助用户并回答用户的有关系统的使用的问题。

[941]金融服务API

[942]移动设备和电子钱包平台(EWP)服务代理之间的接口包括诸如支付服务和注册服务之类的服务组件，以及其高水平的异常对象的层次结构。还描述了从服务调用返回的业务数据传输类。

[943]支付服务

[944]根据EWP的应用程序服务基础架构定义，定义和实现了此业务服务。支付服务包括对合作银行系统的通路方法调用。合作银行管理正式的记录系统、支付处理，以及帐户和会员信息。EWP内管理的超出与合作银行集成所需的数据仅供内部使用。

[945]程序包：

[946]com.ewp.services

[947]类：

[948]public interface PaymentServiceInterface

[949]public class PaymentServiceImplemenation implements

[950]PaymentServiceInterface

[951]为此服务定义的应用程序编程接口(API)有：

[952]payP2P-在两个消费者会员之间执行帐户持有人与帐户持有人(p2p)之间的交易

[953]retrieveBalancee-检索指定的帐户的可用余额

[954]retrieveHistory-检索指定的帐户的最后五个交易记录，包括显示了可用余额的第六行

[955]requestPay-由两部分组成的交互的第一步骤，一个会员从另一个会员请求进行支付

[956]payRequestPay—由两部分组成的交互的第二步骤，支付请求的收款人要么付款或者拒绝付款

[957]在下列小节中提供了详细信息。注意，返回的任何货币值将作为Java.lang.String类型呈现，格式为<monetarysymbol><dollars>.<cents>。例如，二十美元五十五美分的字符串表示为“$20.55”。

[958]方法签名：payP2P

[959]此方法支持从移动设备呼叫，以向具有与移动设备号码关联的帐户的另一个会员进行支付。交易结果被发送到调用的会员的移动电话。此外，还向收款人发送接收到资金的通知。

[960]public PaymentSummary payP2P(

[961]String srcDevKey，

[962]String srcPin，

[963]String tgtDevKey，

[964]String transactionAmount，

[965]String paymentMemo)

[966]throws Exception

[967]输入参数：

[968]srcDevKey·字符串值，通常是启动支付的帐户的电话号码

[969]srcPin·字符串值，发出请求的帐户的PIN

[970]tgtDevKey·字符串值，通常是接收支付的帐户的电话号码

[971]transactionAmount·字符串值，向接收方帐户进行支付的金额。

[972]paymentMemo·字符串，从付款人到收款人的短语。

[973]返回类型对象：

[974]PaymentSummary·包括目标帐号、支付金额，以及可用余额数据的容器对象。有关详细信息，参见PaymentSummary类描述。

[975]方法签名：retrieveBalance

[976]此方法支持从移动设备呼叫以获得会员的当前帐户余额。

结果被发送到调用的会员的移动电话。

[977]public BalanceSummary retrieveBalance(

[978]String devKey，

[979]String pin)

[980]throws Exception

[981]输入参数：

[982]devKey·字符串值，通常是正在请求其余额的帐户的电话号码

[983]pin·字符串值，发出请求的帐户的PIN

[984]返回类型对象：

[985]BalanceSummary·包括可用余额数据的容器对象。有关详细信息，参见BalanceSummary类描述。

[986]方法签名：retrieveHistory

[987]此方法支持从移动设备呼叫，以检索会员的五个最近的交易，并在其历史显示中包括当前帐户余额。结果被发送到调用的会员的移动电话。

[988]public TransactionSummary[]rerrieveHistory(

[989]String devKey，

[990]String pin)

[991]throws Exception

[992]输入参数：

[993]devKey·字符串值，通常是正在请求其交易历史的帐户的电话号码

[994]pin·字符串值，发出请求的帐户的PIN

[995]返回类型对象：

[996]TransactionSummary[]·容器对象的阵列，每一个容器对象都包括金额值、贷记/信用/余额，以及交易数据的时间戳。有关详细信息，参见TransactionSummary类描述。

[997]方法签名：payRequestPay

[998]此方法支持从移动设备呼叫，以接受或者拒绝对支付的请求。交易结果被发送到支付会员的移动电话。此外，还向收款人发送接收到资金的通知。

[999]public PayRequestSummary payRequestPayMobile(

[1000]String payerDevKey，

[1001]String payerPin，

[1002]String tgtDevKey，

[1003]String paymentAmount，

[1004]String tipAmount，

[1005]Boolean acceptRequest，

[1006]String transactionRef，

[1007]String requestText，

[1008]String memoText)

[1009]throws Exception

[1010]输入参数：

[1011]payerDevKey·字符串值，通常是履行支付请求的帐户的电话号码(与payP2P的源相同)

[1012]payerPin·字符串值，是履行支付请求的帐户的PIN

[1013]tgtDevKey·字符串值，要么是接收支付的帐户的电话号码，要么是用于向与接收支付的帐户关联的设备标识JNDI连接键的引用键

[1014]paymentAmount·字符串值，向接收方帐户进行支付的金额。

[1015]tipAmount·字符串值，要添加到交易总和中的小费支付金额

[1016]acceptRequest·布尔值，指出是否接受支付请求(true＝接受)

[1017]transactionRef·字符串值，来自原始支付请求的交易参考编号

[1018]requestText·字符串，从请求进行支付的帐户持有人到进行付款的帐户持有人的短语。

[1019]memoText·字符串，从付款人到收款人的短语。

[1020]返回类型对象：

[1021]PayRequestSummary·包括交易参考编号、目标帐号、支付金额，以及可用余额数据的容器对象。有关详细信息，参见PayRequestSummary类描述。

[1022]方法签名：requestPay

[1023]此方法调用设备服务方法，将来自另一个会员的支付请求的情况通知给目标会员。

[1024]public PayRequestSummary requestPay(

[1025]String srcDevKey，

[1026] String srcPin，

[1027]String tgtDevKey，

[1028]String transactionAmount，

[1029]Boolean tipRequest，

[1030]String requestText)

[1031]throws Exception

[1032]输入参数：

[1033]srcDevKey·字符串值，要么是启动支付请求的帐户的电话号码，要么是用于向与作出支付请求的帐户关联的设备标识JNDI连接键的引用键

[1034]srcPin·字符串值，发出请求的帐户的PIN

[1035]tgtDevKey·字符串值，通常是应该接收支付请求通知的帐户的电话号码

[1036]transactionAmount·字符串值，请求的支付的金额。

[1037]tipRequest·布尔值，指出是否向请求收款人呈现小费请求屏幕。

[1038]requestText·字符串，从支付请求者到进行付款的帐户持有人的短语。

[1039]返回类型对象：

[1040]PayRequestSummary·包括交易参考编号、目标帐号、支付金额，以及可用余额数据的容器对象。有关详细信息，参见PayRequestSummary类描述。

[1041]注册服务

[1042]根据EWP的应用程序服务基础架构定义，定义和实现了此业务服务。注册服务提供了用来供Web服务从合作银行系统呼叫回EWP系统的方法。尽管合作银行维护了正式的帐户和会员信息，但是，EWP必须知道会员的预存款借记卡号码和会员的移动电话号码之间的映射。此数据，潜在地更多，将在EWP系统中持久存在下去。

[1043]程序包：

[1044]com.ewp.services

[1045]类：

[1046]public interface RegistrationServiceInterface

[1047]public class RegistrationServiceImplemenationimplements

[1048]paymentServiceInterface

[1049]为此服务定义的应用程序编程接口(API)有：

[1050]addRegistrationInfo-创建涉及帐户的数据记录

[1051]在下列小节中提供了详细信息。

[1052]方法签名：addRegistrationInfo

[1053]此方法persists设备号为帐户数据记录。如果有更多信息可用，诸如会员名，那么，该方法还将persist补充信息。根据需要，在数据对象之间进行引用。该方法返回指出了帐户的注册状态的容器对象。

[1054]public ArrayList addRegistrationInfo(

[1055]ArrayList regContainerList，

[1056]String dsName)

[1057]throws Throwable

[1058]输入参数：

[1059]regContainerList·最低限度地包含与帐户关联的电话的RegistrationContain er容器对象。

[1060]返回类型对象：

[1061]ArrayList of RegistrationContainer objects·包含本应持续的信息的容器对象列表。

[1062]转帐对象

[1063]本节中所描述的每一个转帐对象都提供了其每一个类属性和默认构造函数的getter和setter。本节中的对象实现了java.io.Serializable接口和TransferInterface接口，是潜在的公用接口需求的占位符，并提供基类型。

[1064]Balan ceSummary

[1065]从paymentServiceInterface.retrieveBalanceMobile()API返回的容器对象。

程序包：

[1066]com.ewp.transferobjects

[10671类：

[1068]public class BalanceSummary

[1069]implements TransferInterface，Serializable

[1070]属性：

[1071]currentBalanceAmount·字符串值，当前可用的资金金额

[1072]errorCode·字符串值，指出错误的特征；只有在状态＝0的情况下才设置

[1073]status·字符串值，指出是否在服务执行过程中发生了错误：

1＝好，0＝错误

[1074]requestDate·字符串值，余额请求的审核时间戳

[1075]PaymentSummary

[1076]从PaymentServiceInterface.payP2PMobile()API返回的容器对象。此对象还在通知回叫中传输到移动设备接口，带有显示的值。

[1077]程序包：

[1078]com.ewp.transferobj ects

[1079]类：

[1080]public class PaymentSummary

[1081]implements TransferInterface，Serializable

[1082]属性：

[1083J newBalanceAmount·字符串值，当前可用的资金金额。

[1084]paymentAmount·字符串值，已支付的资金金额

[1085]sourceDeviceKey·字符串值，是进行了付款的帐户的电话号码

[1086]targetBalanceAmount·字符串值，当前可用于目标帐户的资金金额

[1087]targetDeviceKey·字符串值，是向其进行支付的帐户的电话号码

[1088]errorCode·字符串值，指出错误的特征；只有在状态＝0的情况下才设置

[1089]status·字符串值，指出是否在服务执行过程中发生了错误：

1＝好，0＝错误

[1090]requestDate·字符串值，是支付请求的交易时间戳

[1091]TransactionSummary

[1092]从PaymentServiceInterface.retrieveHistoryMobile()API返回的容器对象。

程序包：

[1093]com.ewp.transferobj ects

[1094]类：

[1095]public class TransactionSummary

[1096]implements TransferInterface，Serializable

[1097]属性：

[1098]transactionDate·字符串值，自从1970年1月1日午夜以来以毫秒代表的协调世界时(UTC)值。日期是初笔交易的日期。

[1099]settleDate·字符串值，自从1970年1月1日午夜以来以毫秒代表的协调世界时(UTC)值。日期是当完成交易时的日期。

[1100]transactionAmount·字符串值，特定交易的金额

[1101]transactionKey·字符串值，指出交易金额是表示划入(“+”)，划出(“-”)，或余额(“余额”)。

[1102]transactionType·字符串值，指出交易类型：P2P、POS、ATM、LOAD、BAL

[1103]locationName·字符串值，标识交易是在哪里进行的，例如，商店ID或ATM ID。

[1104]errorCode·字符串值，指出错误的特征；只有在状态＝0的情况下才设置

[1105]status·字符串值，指出是否在服务执行过程中发生了错误：

1＝好，0＝错误

[1106]PayRequestSummary

[1107]在通知回叫中传输到移动设备的容器对象，带有显示的值。程序包：

[1108]com.ewp.transferobj ects

[1109]类：

[1110]public class PayRequestSummary

[1111]implements TransferInterface，Serializable

[1112]属性：

[1113]acceptRequest·布尔值，指出是否接受支付请求。TRUE值表示处理p2p支付。

[1114]paymentAmount·字符串值，待支付的资金金额

[1115]payerBalanceAmount·字符串值，当前可用的资金金额

[1116]payerDeviceKey·字符串值，是从其请求支付的帐户的电话号码

[1117]requesterDeviceKey·字符串值，作出支付请求的帐户的电话号码以及向谁进行支付的电话号码

[1118]targetBalanceAmount·字符串值，当前可用于目标帐户的资金金额

[1119]transactionRef·字符串值，服务器产生的交易参考编号

[1120]errorCode·字符串值，指出错误的特征；只有在状态＝0的情况下才设置

[1121]status·字符串值，指出是否在服务执行过程中发生了错误：

1＝好，0＝错误

[1122]requestDate·字符串值，是支付请求的交易时间戳

[1123]tipRequest·布尔值，指出是否应该从收款人那里请求小费金额

[1124]异常类

[1125]EWPServiceException

[1126]为EWP系统定义的基异常类。从服务引发的所有异常都将此基类或其一个子类继承下来。程序包：

[1127]com.ewp.core.exceptions

[1128]类：

[1129]public class EWPException extends Throwable

[1130]属性：

[1131]errorCode·字符串值，标识EWP系统中的唯一错误代码。此代码将被定义为Java常数。它将用于message.property文件，以标识定位字符串。

[1132]errorText·在EWP系统日志中记录的错误消息的字符串值。

[1133]InternalException

[1134]此异常表示发生的所有系统和服务错误，应该保留在EWP系统的内部。此错误的来源通常不传播回客户端应用程序。

程序包：

[1135]com.ewp.core.exceptions

[1136]类：

[1137]public class InternalException extends EWPException

[1138]属性：从父类继承。

[1139]BusinessException

[1140]此异常表示可以呈现给客户端应用程序的错误。异常对象中包含的错误消息不是显示给帐户持有人的消息。返回到帐户持有人的错误消息是帐户持有人可理解的形式，并且被本地化。在网关中进行errorCode到错误消息的转换。程序包：

[1141]com.ewp.core.exceptions

[1142]类：

[1143]public class BusinessException extends EWPException

[1144]属性：从父类继承。

[1145]错误代码

[1146]有时作为TransactionEvent事件状态代码和AuditEvent事件状态代码出现的错误代码。请参阅ErrorCodesAndNotifications.doc了解错误代码和定义。

[1147]业务对象

[1148]本节讨论了用于一个实施例中的数据对象。在EWP_Design_Pilot.doc和EWPDOModel_v2.vsd设计文档中定义了一组数据对象。那些对象表示此实施例以外的全部EWP系统设计。下表中呈现了一个实施例的业务对象的示例。应了解，对象本身可以只包含在EWPDOModel_v2.vsd设计模型中提议的属性的子集。

[1149]下表显示了业务对象类名称，其对应的数据表名称，属性名称，对应的数据表列名称，以及数据表的估计的增长率。

[1150]

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	Account	ACCOUNT	Integer idLong createTimeStampLong timeStampString accountNumberString acctStatusCodeBoolean acctWhtlistFlagBigDecimalavailBalanceBigDecimal balanceString cardNumberString currencyCodeString deviceNumberProfile profileBigDecimaldailyTransTotalBigDecimalmonthTransTotalBigDecimalweekTransTotal	NUMBER(24)IDNUMBER(16)CREATETIMESTAMPNUMBER(16)TIMESTAMPVARchar2(16)ACCOUNTNUMBERVARchar2(8)ACCTSTATUSCODENUMBER(l)ACCTWHTLISTFLAGNUMBER(19，4)AVAILBALANCENUMBER(19，4)BALANCEVARchar2(16)CARDNUMBERVARchar2(3)CURRENCYCODEVARchar2(20)DEVICENUMBERNUMBER(24)PROFILEREFIDNUMBER(19，4)DAILYTRANSTOTALNUMBER(19，4)	最初80个注册请求每周4个“病毒式”注册请求每次注册，1个

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	MONTHTRANSTOTALNUMBER(19，4)WEEKTRANSTOTAL
AuditEvent	AUDITEVENT	Integer idLong timeStampInteger accountIdString auditNumberString auditTypeCodeString eventStatusCodeString infoTextInteger memberIdString networkConnInfoInteger transEventIdBigDecima ltransFeesAmtBigDecima ltransGrossAmtString transNumberRefInteger transTgtAcctIdString transTypeCodeSt ring memoString message1	NUMBER(24)IDNUMBER(16)TIMESTAMPNUMBER(24)ACCOUNTIDVARchar2(16)AUDITNUMBERVARchar2(8)AUDITTYPECODEVARchar2(8)EVENTSTATUSCODEVARchar2(250)INFOTEXTNUMBER(24)MEMBERIDVARchar2(250)NETWORKCONNINFONUMBER(24)FRANSEVENTIDNUMBER(19，4)FRANSFEESAMTNUMBER(19，4)FRANSGROSSAMTVARchar2(16)FRANSNUMBERREFNUMBER(24)FRANSTGTACCTID	所有转帐事件+注册请求	MONTHTRANSTOTALNUMBER(19，4)WEEKTRANSTOTAL

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	VARchar2(8)TRANSTYPECODEVARchar2(32)MEMOVARchar2(32)MESSAGE 1
TransactionEvent	TRANSACTIONEVENT	Integer idLong timeSta mpCurrencyExchangecurrency XCString currencyTranRefString currencyCodeString eventStatusCodeString extPayConfRefSt ring extPayAcctRefString extPayTransRefFloat feeRetainRateBigDecimalgrossAmountString infoTextString locationRefString networkConnInfoInteger srcAccountIdBigDecima lsrcFees AmountInteger srcMemberId(＊)St ring srcMemTransRefInteger tgtAccountIdBigDecimaltgtFeesAmountInteger tgtMemberId(^＊)	NUMBER(24)IDNUMBER(16)TIMESTAMPNUMBER(24)CURRENCYXCREFIDVARchar2(24)CURRENCYTRANREFVARchar2(3)CURRENCYCODEVARchar2(8)EVENTSTATUSCODEVARchar2(24)EXTPAYCONFREFVARchar2(24)EXTPAYACCTREFVARchar2(24)EXTPAYTRANSREFNUMBER(5，4)FEERETAINRATENUMBER(19，4)GROSSAMOUNTVARchar2(250)1NFOTEXTVARchar2(24)LOCATIONREF	每天每个帐户2个

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	String transNumberString transTypeCodeSt ring memoString message1	VARchar2(250)NETWORKCONNINFONUMBER(24)SRCACCOUNTIDNUMBER(19，4)SRCFEESAMOUNTNUMBER(24)SRCMEMBERIDVARchar2(24)SRCMEMTRANSREFNUMBER(24)TGTACCOUNTIDNUMBER(19，4)TGTFEESAMOUNTNUMBER(24)TGTMEMBERIDVARchar2(16)TRANSNUMBERVARchar2(8)TRANSTYPECODEVARchar2(32)MEMOVARchar2(32)MESSAGE1
Member	MEMBER	Integer idLong createTimeStampLong timeStampBooleanmemBlkListFlagString chalQuestionString chalAnswer	NUMBER(24)IDNUMBER(16)CREATETIMESTAMPNUMBER(16)TIMESTAMPNUMBER(1)MEMBLKLISTFLAG

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	Integer contactInfoIdInteger feeStructureIdArrayListfundsAccountsString languageString memStatusCodeString pinAlarmCodeString pinCodeProfile profileString screenName	VARchar2(32)CHALQUESTIONVARchar2(32)CHALANSWERNUMBER(24)CONTACTINFOIDn/an/aVARchar2(24)LANGUAGEVARchar2(8)MEMSTATUSCODEVARchar2(16)PINALARMCODEVARchar2(16)PINCODENUMBER(24)PROFILEREFIDVARchar2(16)SCREENNAME
ConsumerMember	CONSUMERMEMBER(+MEMBER)	Integer idLong birthDateSt ringgovernmentIdNumLongidDocExpDateStringidDocIssuerStringidDocNumString idDocTypeCoden/a	NUMBER(24)IDNUMBER(16)BIRTHDATEVARchar2(24)GOVERNMENTIDNUMNUMBER(16)IDDOCEXPDATEVARchar2(24)IDDOCISSUERVARchar2(24)	(＊)每次注册，1个

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率				IDD OCNUMVARchar2(8)IDDOCTYPECODENUMBER(24)MEMBERREFID
MerchantMember	MERCHANTMEMBER(+MEMBER)	IntegeridSt ring employerIdNumn/a	NUMBER(24)IDVARchar2(24)EMPLOYERIDNUMNUMBER(24)MEMBERREFID	(＊)每次注册，1个				IDD OCNUMVARchar2(8)IDDOCTYPECODENUMBER(24)MEMBERREFID
MerchantMember	MERCHANTMEMBER(+MEMBER)	IntegeridSt ring employerIdNumn/a	NUMBER(24)IDVARchar2(24)EMPLOYERIDNUMNUMBER(24)MEMBERREFID	(＊)每次注册，1个	MemberAccountRole	MEMBERACCOUNTROLE	Integer accountIdInteger memberIdString roleTypeCodeLong timeStamp	NUMBER(24)ACCOUNTIDNUMBER(24)MEMBERIDVARchar2(8)ROLETYPECODENUMBER(16)TIMESTAMP	(＊)每次注册，1个
Con tactInformation	CONTACTINFORMATION	Integer idLong createTimeStampLong timeStampString dataStatusCodeString e-mailAddressStringfirstNameString middleNameString familyNameAddress homeAddressPhoneNumber	NUMBER(24)IDNUMBER(16)CREATETIMESTAMPNUMBER(16)TIMESTAMPVARchar2(8)DATASTATUSCODEVARchar2(32)E-MAILADDRESSVARchar2(16)	(＊)每次注册，1个	MemberAccountRole	MEMBERACCOUNTROLE			(＊)每次注册，1个

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	homePhonePhoneNumbermobilePhoneAddress officeAddressPhoneNumberofficePhone	FIRSTNAMEVARchar2(16)middleNAMEVARchar2(24)FAMILYNAMEn/an/an/an/an/a
Address	ADDRESS	Integer idLong timeStampString addressLine1String addressLIne2String addressLine3String addressTypeCodeString cityString countrySt ring stateCodeString provinceString postalCoden/an/a	NUMBER(24)IDNUMBER(16)TIMESTAMPVARchar2(24)ADDRESSLINE1VARchar2(24)ADDRESSLINE2VARchar2(24)ADDRESSLINE3VARchar2(8)ADDRESSTYPECODEVARchar2(24)CITYVARchar2(24)COUNTRYVARchar2(2)STATECODEVARchar2(24)PROVINCEVARchar2(8)POSTALCODE	(＊)每次注册，1个

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率				NUMBER(24)CONTACTINFREFIDNUMBER(24)FUNDSACCTREFID
PhoneNumber	PHONENUMBER	Integer idLong timeStampString areaCodeSt ring localNumberString extensionString phoneTypeCoden/an/a	NUMBER(24)IDNUMBER(16)TIMESTAMPVARchar2(8)AREACODEVARchar2(12)LOCALNUMBERVARchar2(8)EXTENSIONVARchar2(8)PHONETYPECODENUMBER(24)CONTACTINFREFIDNUMBER(24)FUNDSACCTREFID	(＊)每次注册，1个				NUMBER(24)CONTACTINFREFIDNUMBER(24)FUNDSACCTREFID
PhoneNumber	PHONENUMBER			(＊)每次注册，1个	Profile	PROFILE	Integer idLong createTimeStampLong timeStampString dataStatusCodeString desc ription	NUMBER(24)IDNUMBER(16)CREATETIMESTAMPNUMBER(16)FIMESTAMPVARchar2(8)DATASTATUSCODEVARchar2(80)DESCRIPTION	(＊)每次注册，1个
NoAccessEvent	NOACCESSEVEN	Integer idLong timestamp	NUMBER(24)IDNUMBER(16)		Profile	PROFILE			(＊)每次注册，1个

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率		T	String identityRefString infoTextString networkConnInfoString requestTypeCode	TIMESTAMPVARchar2(24)IDENTITYREFVARchar2(250)INFOTEXTVARchar2(250)NETWORKCONNINFOVARchar2(8)REQUESTTYPECODE
GatewayEvent	GATEWAYEVENT	IntegeridLong timestampString chanTypeCodeString chanOrigInfoString chanDestInfoString hostInfoString message	NUMBER(24)IDNUMBER(16)TIMESTAMPVARchar2(8)CHANTYPEC ODEVARchar2(80)CHAN ORIGINFOVARchar2(80)CHANDESTINFOVARchar2(250)HOSTINFOVARchar2(250)MESSAGE			T
GatewayEvent	GATEWAYEVENT				DeviceInfo	DEVICEINFO	Integer idString deviceNumberString deviceKeyString connectionKeyString processorTypeString applicationType	NUMBER(24)IDVARchar2(20)DEVICENUMBERVARchar2(16)DEVICEKEYVARchar2(250)CONNECTIONKEYVARchar2(16)

业务对象	数据表名称	所使用的属性	数据表列名称	增长率
业务对象	数据表名称	所使用的属性	数据表列名称	增长率	PROCESSORTYPEVARchar2(24)APPLICATIONTYPE
Invitation	INVITATION	Intege ridLong timestampString deviceNumberInteger transEventIdString transNumberRefString srcAccountIdString srcMemberIdString invitStatusCode	NUMBER(24)IDNUMBER(16)TIMESTAMPVARchar2(20)DEVICENUMBERNUMBER(24)TRANSEVENTIDVARchar2(16)TRANSNUMBERREFNUMBER(24)SRCACCOUNTIDNUMBER(24)SRCMEMBERIDVARchar2(8)INVITSTATUSCODE		PROCESSORTYPEVARchar2(24)APPLICATIONTYPE

[1151](^＊)如果Member数据保留

[1152]斜体文本表示将不会被定义的字段。

[1153]粗体文本表示将被定义的字段，但是，将不会被使用(对象中为空值)。

[1154]PaymentProcessorHelper

[1155]本节定义了测试API，以模拟合作银行的存在，作为支付处理器和记录系统的管理人。程序包：

[1156]com.ewp.integration.interfaces-定义了helper方法。

[1157]com.ewp.integration.implemenations-用于实现运行helper方法的服务所使用的接口。

[1158]com.ewp.integmtion.paymentProcessor-用于运行helper方法的服务

[1159]类：

[1160]public class PaymentProcessorHelper

[1161]为helper定义的应用程序编程接口(API)有：

[1162]balance-处理返回当前可用余额的请求

[1163]history-处理返回最后五个交易记录的列表和当前余额的请求

[1164]p2p—处理p2p支付交易

[1165]verifyPin-处理对照帐户验证pin的请求

[1166]Method signature：balance

[1167]public BalanceSummary balance(

[1168] String sourceMobileID，String sourcePIN)；

[1169]Method signature：history

[1170]public TransactionSummary[]history(

[1171]String devNumber，

[1172]String pin)；

[1173]Method signature：p2p

[1174]public PaymentSummary p2p(

[1175] String srcDevNumber，

[1176] String srcPin，

[1177] String tgtDevNumber，

[1178] String transactionAmount)；

[1179]增值服务

[1180]许多小企业都使用商业会计服务来处理应收帐款以及他们的总帐。优选情况下，本发明链接到会计服务，以提供一个增值服务，省去了数据输入步骤，并保留了所有交易的及时记录。当完成金融交易时，支付平台自动地向应收帐款系统中记入支付。也可以将消息、声音注释或其他指定金融交易类型的手段发送给会计服务。

[1181]离线交易

[1182]所讨论的本发明的实施例涉及实时在线系统，在支付服务器上维护了帐户持有人的余额。然而，在有的情况下，离线支付选项是理想的。相应地，在本发明的一个实施例中，帐户持有人的帐户中的余额存储在移动设备附属的或与移动设备关联的芯片中。常常简称为智能芯片的芯片在交易进行过程中更新。由Sony公司制造的叫做FeliCa芯片的智能卡芯片是这样的智能芯片的一个示例。在一天结束时，在每一个商家和支付系统提供商之间进行批传输，以进行结算。

[1183]图87和88中显示了离线支付选项，而图89显示了本发明的实施例的实时在线体系结构。首先请参看图89，驻留在移动设备8701上的MCA 8901，与充当离线管理器8702的芯片(与移动设备8701关联)连接。MCA 8901和离线管理器8902两者都可以访问共享存储器8903。在一个实施例中，离线管理器8902还具有内部存储器，在它更新共享存储器8903之前，它在内部存储器中存储每一次交易。就设置可用于离线交易的初始帐户余额以及在设备8901重新同步帐户之后从离线管理器8902清除陈旧的交易而言，离线管理器8902由MCA进行控制。重新同步是由MCA 8901使用通信平台8904执行的，在每天的固定时间或者快要由帐户持有人启动在线交易时进行。

[1184]现在请参看图87，当离线管理器被激活，并检测到商家的POS终端时，交易可以在离线模式下进行。在此模式下，离线管理器8902负责与POS终端8702连接以扣除交易金额。当管理器8902检测到支付请求时，它向MCA发送消息以请求授权或等待来自用户的授权。这样的授权可以是响应授权请求选定的键或键的组合被按下。如引用箭头8703所示，支付被发送到POS 8702。作为响应，POS 8702接受支付，并发送如引用箭头8704所示的收据。管理器8902维护可用于离线购物的动态余额，如8705处所指出的。

[1185]稍后，移动设备8701必须与支付服务器8806再同步，这是图88中所显示的过程。由于离线管理器保持了帐户持有人的可用于离线购物的余额，它定期向支付服务器8806发送离线花费报告和余额，如引用箭头8807所示。通常，重新同步是在每天的结束或者开始进行的。在重新同步过程中，离线管理器向服务器8806传输交易摘要，包括交易的金额，以及日期戳，商家的标识号码，如引用箭头8808所示。服务器8806确认交易，并将可用的离线交易金额重新设置为同步后的值，如引用箭头8809所示。应该理解，存储的供离线管理器使用的值可以由用户选定。如此，每天、每星期或每个月，帐户持有人都可以用可用于离线交易的预先选择的金额开始。为确认余额，服务器8806还将帐户与每一个商家8802同步，如引用箭头8810所示。

[1186]与通过只配备有智能芯片的移动电话发送离线资金相比，此离线实施例的优点包括：

[1187](1)丢失移动设备并不意味着丢失资金，因为利用在线同步，帐户可以关闭，余额可以转移到新帐户；以及

[1188](2)问题帐户可以轻松地禁用，然后，在问题解决之后重新启用。

[1189]离线交易的主要优点是交易时间非常短即可完成交易。离线交易对于那些网络授权交易可能太慢的帐户持有人有好处。然而，当与离线支付功能相结合时，本发明的实时网络授权模式提供了通用的，自适应的并且有用的系统。

[1190]如上文所描述的，本发明涉及一种移动支付平台和服务，通过个人使用移动设备，可以提供快速、安全，并且方便的付款方式。从帐户持有人的移动设备访问资金，移动设备可以是手机、PDA，或其他面向数据包的通信设备，用于发出支付和接收支付。金融交易在个人之间(P2P)进行，其中，每一方都由诸如电话号码或条形码之类的唯一指示符来进行标识。驻留在移动设备上的移动客户端应用程序(MCA)简化了访问，并以快速安全的方式执行金融交易。

[1191]图90显示了根据本发明的实施例的MCA的J2ME应用程序基础架构。屏幕序列9000由如9001处所显示的DataScreen类的一个或多个实例的系列构成。DataScreen实例可使用户提供特定输入或者读取信息。DataFieldScreen 9002专业化允许输入美元金额、电话号码、文本或个人标识号等等。DataFieldScreen实例负责验证用户数据输入。MenuDataScreen 9003和ListDataScreen 9004提供各种菜单和列表选择功能。变化实现了单一选择(圆形按扭)、多项选择(复选框)或菜单式样交互。ReadOnlyDataScreen 9005实例提供输出。专业化提供适合于正在被显示的数据的格式。变化实现了单一选择(圆形按扭)、多选择(复选框)或菜单式样交互。ReadOnlyDataScreen实例提供输出。专业化提供适合于正在被显示的数据的格式。

[1192]图91显示了应用程序(MCA)初始化和屏幕序列顺序图。图91所示的应用程序启动顺序显示了Menu基类如何管理其包含的菜单项的显示和选择。菜单项类定义了它们的关联的功能—例如，支付、余额、历史等等。通常，这将启动屏幕序列。

[1193]图92显示了屏幕序列类。屏幕序列9201组合了DataScreen实例的系列，并驱动通过诸如数据输入和选择“确定”和“后退”按钮用户操作而启动的序列。屏幕序列实例还实现了由屏幕序列的完成而启动的行为。通常，这将导致调用服务方法—即，调用诸如个人之间的支付之类的服务器端的服务。9202处显示了由来自服务器的通知启动的序列。

[1194]图93显示了EWP J2ME同步服务调用。同步服务调用是由诸如完成诸如支付之类的屏幕序列之类的用户操作而启动的。在此情况下，启动与服务器端的服务的通信的同一个线程还处理返回值。

[1195]图94显示了EWP J2ME异步服务调用。然而，如果协议是SMS，则以异步的方式调用服务，一旦(SMS)消息发送完毕，线程就完成。来自服务器端服务的返回值在从系统线程中衍生的一个接收消息通知的新的线程中进行处理。

[1196]在一个实施例中，本发明涉及供消费者使用的移动通信设备，具体来说，涉及利用可移动的标识模块增强蜂窝电话及其他移动消费类通信设备的功能的方式。

[1197]大多数移动消费类通信设备例如，蜂窝电话、PDA(个人数字助理)、笔记本电脑等等，都包含可移动标识模块(IM)卡或芯片，用于向无线通信网络运营商唯一地标识特定消费者的帐户。IM卡/芯片存储了数据，并提供一些“大脑”，可使宿主移动消费类通信设备运转，例如，发出和接收语音电话、发送或接收消息，运行计算机应用程序等等。这可使用户，例如，通过从一个电话中取出IM卡/芯片并将卡/芯片重新插入到另一个电话中，轻松地更换蜂窝电话。不需要通过通信网络来激活第二个蜂窝电话。

[1198]不同类型的移动消费类通信设备使用不同类型的IM卡/芯片。例如，SIM(用户标识模块)卡用于GSM(全球移动通信系统)设备中。另一种IM卡/芯片是USIM(通用用户标识模块)，用于UMTS(通用移动电信系统)设备中，再一种是RUIM(可移动用户标识模块)，用于CDMA(码分多址)设备中。对于本专利申请，任何IM卡/芯片都简称为IM或标识模块。

[1199]但是，不管类型如何，IM以及它们的宿主移动通信设备一般是“封闭的”，无线通信网络运营商(例如，Cingular、T-Mobile、Verizon等等)、移动消费类通信设备的制造商，以及IM制造商(例如，Gemplus、Oerthur等等)专有的系统。尽管如此，通信协议，IM宿主通信设备，即，移动消费类通信设备，IM之间的接口是通过由ISO(国际标准化组织)制定的技术标准而开放的。

[1200]本发明利用这些开放的标准为宿主移动消费类通信设备创建额外的功能，而不会干涉IM操作。移动消费类通信设备仍与IM一起操作，但是，向设备中“插入”了额外的功能。本发明允许限制移动运营商，手机制造商和IM被绕过，以便移动应用程序可以在移动消费类通信设备中运行，以便增强设备的功能。

[1201]PIP CPU具有一个操作系统，事件接口call-out，后IM卡处理call-out。

[1202]图95显示了可以受益于本发明的移动消费类通信设备的示例，在此情况下，典型的蜂窝电话9500。在蜂窝电话内部，有装入IM插槽中的IM(标识模块)。如前所述，IM包含用户的用于访问通信网络的标识信息，IM被插入到IM插槽中，设备9500可以以常规方式用于无线通信网络中。

[1203]图96显示了本发明的一个实施例。IM 9619，无论是卡的形式还是芯片的形式，都安装在薄的外壳9617中，该外壳9617还包含可编程处理单元9618。外壳9617将IM 9619和可编程处理单元9618互连在一起，外壳9617还通过细的带状电缆9616连接到IM适配器9615。

[1204]IM适配器9615可以装入移动消费类通信设备9500的IM插槽中，如图97所示。IM适配器9615装入蜂窝电话9500的IM插槽9625中，其后盖(未显示)被取出。如图所示，IM适配器9615装入IM插槽9625中，并通过带状电缆9616连接IM9619和可编程处理单元9618。由于电缆9616是软的，外壳9617可以翻过来，放入蜂窝电话9500中，如图98所示。在实践中，蜂窝电话9500的电池(未显示)可以安装在IM插槽9625和IM适配器9615上方，然后，外壳9617覆盖在电池，然后，盖子可以被替换，如图95所示。

[1205]图99显示了IM适配器9615、带状电缆9616、可编程处理单元9618和IM 9619之间的电连接。移动消费类通信设备9500中的IM插槽9625和IM 9619之间的所有电子通信(即，数据通信)必须经过可编程处理单元9618。如下文所描述的，在一种情况下，对于常规或本地无线通信，可编程处理单元9618作为允许电子通信不受阻碍地通过的栅极而操作。在另一种情况下，可以通过在可编程处理单元9618中运行的应用程序来截取和增强电子通信，以向设备9500的用户提供增强功能。

[1206]可编程处理单元9618可以在微控制器、ASIC(专用集成电路)、所谓的SOC(系统级芯片)及其他集成电路中实现。这些集成电路类型中的每一种都具有一个或多个处理器单元，以及可变容量的存储器，并针对特定的应用要求提供不同程度的自定义、功能和成本。可编程处理单元9618的存储器包含用于增强功能的应用程序，处理器单元执行这些应用程序。应用程序通过无线通信网络上传。

[1207]在任何情况下，可编程处理单元9618都与操作系统10110、事件接口call-out 10111、后IM处理call-out 10112、应用程序注册表10113，以及编程语言和运行时10114一起操作，如图101所示。操作系统促进宿主移动消费类通信设备9500和IM 9619之间的通信，如以前所说明的。操作系统还向在可编程处理单元9618中注册和安装的应用程序提供编程call-out。

[1208]事件接口call-out 10111提供编程事件接口，这是应用程序实现的，为了在发生特定移动设备事件时，例如，按下按钮，振铃信号等等，获得对宿主移动消费类通信设备的编程控制。在此控制过程中，应用程序具有对事件添加功能和处理的能力。

[1209]后IM处理call-out 10112提供一个编程事件接口，这是应用程序实现的，为了在从移动消费类通信设备事件的本地IM处理返回时，获得对宿主移动消费类通信设备的编程控制。IM始终是事件的处理链中的最后一个。在此控制过程中，在移动消费类通信设备收回控制之前，应用程序具有对事件添加功能和后处理的能力。

[1210]应用程序注册表10113提供了一个配置，以便应用程序可以被注册为对特定的事件感兴趣(因此，当这些事件发生时，被以编程方式进行调用)。对于相同的事件，可以注册多个应用程序，并进行链式调用。

[1211]编程语言和运行时10114提供了一个编程语言和平台，在其上面，可以创建应用程序。标准的多个合适的语言/运行时包括由位于加利福尼亚州圣迭戈的Qualcomm，Inc.开发的BREW(BinaryRuntime Environment for Wireless，用于无线通信的二进制运行时环境)，用于为开发人员提供标准的应用程序编程接口组，轻松地向基于Qualcomm的无线硬件(即，配备有CDMA芯片集的手机)中添加新的功能和用途；J2ME(Java2Mobile Edition)，来自位于加利福尼亚州Santa Clara的Sun Microsystems，Inc.的用于移动系统的基于Java的技术；位于华盛顿州Redmond的Microsoft，Inc.的.NET，为Windows操作系统提供软件开发平台，使用XML(扩展标记语言)；以及，Symbian，这是由许多公司(包括瑞典斯德哥尔摩的L.M.Ericsson，以及芬兰Espoo的Nokia Corp.)的合资企业为移动设备设计的平台。当然，前面的语言/平台只是示例而已，也可以使用其他语言。

[1212]在本申请中描述了可以在可编程处理单元中运行的应用程序的某些示例。例如，下面，本申请描述了通过音频信道发送数据的方式，而不是通过移动消费类通信设备的无线通信网络的数据信道发送数据。在一个应用程序中，移动消费类通信设备可以通过向其音频信道向另一个移动消费类通信设备发送文本消息。在另一个专利申请中，可以通过移动消费类通信设备利用其音频信道进行移动支付。

[1213]到目前为止，诸如图95的蜂窝电话9500之类的移动消费类通信设备，被描述为只需要一个IM，将该IM装入设备的IM插槽中，以连接无线通信网络。另一方面，笔记本电脑通常没有内嵌的IM插槽。笔记本电脑使用USB适配器10021，接受用户的IM，USB适配器10021连接到装入笔记本电脑的USB端口的USB连接器10022。图100显示了以前所描述的IM适配器9615如何装入USB适配器10021，以使IM 9619与宿主笔记本电脑接触。在IM9619与笔记本电脑接触以接合无线通信网络的情况下，可编程处理单元9618允许通过应用程序获得另外的功能。

[1214]诸如蜂窝电话之类的移动消费类通信设备，通常使用音频信道来传输与接收语音。本发明为应用程序提供了通过移动消费类通信设备的音频信道传输数据的方式。

[1215]本发明允许可以在任意数量的移动应用程序的编程平台/运行时上创建的应用程序通过宿主移动消费类通信设备的音频信道联网。平台的示例包括由位于加利福尼亚州圣迭戈的Qualcomm，Inc.开发的BREW(Binary Runtime Environment for Wireless，用于无线通信的二进制运行时环境)，用于为开发人员提供标准的应用程序编程接口组，轻松地向基于Qualcomm的无线硬件(即，配备有CDMA芯片集的手机)中添加新的功能和用途；J2ME(Java 2 MobileEdition)，来自位于加利福尼亚州Santa Clara的SunMicrosystems，Inc.的用于移动系统的基于Java的技术；位于华盛顿州Redmond的Microsoft，Inc.的.NET，为Windows操作系统提供软件开发平台，使用XML(扩展标记语言)；Symbian，这是由许多公司(包括瑞典斯德哥尔摩的L.M.Ericsson，以及芬兰Espoo的Nokia Corp.)的合资企业为移动设备设计的平台。当然，也可以使用其他编程平台/运行时。

[1216]图102显示了根据本发明的一个实施例的数据通过无线通信网络的音频信道进行传输的一种布局。移动消费类通信设备10210的示例，例如，蜂窝电话、PDA等等，通过无线通信网络的音频信道10211进行通信。通常，这些通信是谈话。API(应用程序编程接口)10223允许来自在上文所描述的平台/运行时中实现的移动应用程序(即，宿主客户端应用程序10221)的数据通过音频信道10211传递到服务器系统10212。API 10223对音调中的数据进行编码，以便通过音频信道10211进行传输。在此示例中，使用长时间的DTMF(双音多频)，但是，也可以使用适用于音频信道的其他编码方式。

[1217]在接收到DTMF音调的情况下，服务器10212跨无线通信网络接合IVR(交互式语音响应)单元10226以对音调进行解码。IVR可以发送和接收DTMF音调(有时叫做“按键音”)，在许多当前的自动电话应答系统中都有。它允许计算机自动地使用语音识别、音频播放、文本到语音转换(ITS)和DTMF技术与人进行交互。IVR“插件”10224是IVR改编的API，用于将数据变成服务器10212中的应用程序10222的正常形式。这允许移动消费类通信设备10210中的应用程序10221通过音频信道10211与服务器10212中的企业应用程序10222进行通信。数据信号在两个应用程序10221和10222之间的两个方向进行传输。移动消费类通信设备10210和服务器10212之间的通信是通过音频信道的客户端/服务器之间的通信的示例。另一方面，服务器应用程序10222的操作可以是简单地将来自移动消费类通信设备10210的数据中继到另一个移动消费类通信设备。这是通过音频信道的对等通信的示例。

[1218]本发明的实施例中的API，例如，图102的API 10223和10224，基于简单的“sendRequest()＂/processRequest()”模型，在客户端和服务器端都带有已知的请求/响应数据结构。API10223和10224是配对的客户端和服务器API组，移动应用程序和企业服务器开发人员用它们来构建完整的客户端/服务器应用程序。客户端(移动消费类通信设备)和服务器端上的语音数据处理软件(即，库组件)对于跨音频信道的数据通信实现了语音数据处理算法。当然，这些算法不同于特定客户端/服务器应用程序10221和10223。

[1219]API的一个示例如下：

[1220]SendRequest()Client Function：

[1221]这是移动客户端应用程序用来向企业服务器应用程序发送请求/数据的单一API接口。

[1222]Input：A Request structure

[1223]Output：A Response structure

[1224]ProcessRequest()Server Function：

[1225]这是企业服务器应用程序实现的以便处理呼叫的移动客户端的请求的单一API接口。处理逻辑是完全是“宿主”企业应用程序的职责，汇编将返回到呼叫移动客户端的响应数据也是宿主企业应用程序的职责。

[1226]Input：A Request structure

[1227]Output：A Response structure

[1228]Request结构：

[1229]CommandID-唯一地表示被宿主客户端和服务器应用程序两者理解的命令(以及关联的参数数据)的数值。

[1230]ServerAddress-表示“电话号码”的数值，该“电话号码”将用于“拨打”话音呼叫，该话音呼叫将联络到服务器IVR组件，该组件是目标企业服务的“前端”。

[1231]ParameterData-关联到“此”CommandID请求的ParameterData阵列。

[1232]Response结构：

[1233]ResponseID-唯一地表示被宿主客户端和服务器应用程序两者理解的响应(以及关联的参数数据)的数值。

[1234]ParameterData-关联到“此”ResponseID结果的ParameterData阵列。

[1235]ParameterData结构：

[1236]ParameterID-唯一地表示给定CommandID内的参数，并被宿主客户端和服务器应用程序两者理解的数值。

[1237]ParameterType-带有下列设置的数值：

[1238]1-数字

[1239]2-字母

[1240]...其他类型

[1241]ParameterValue-参数的实际值

[1242]编码/解码

[1243]如上文所提及的，根据本发明，API可以使用不同的编码/解码算法。下面是利用DTMF进行编码的一个示例。DTMF编码的这些规则基于使用电话上存在的小键盘标记输入数字和字母的普遍接受的规则：

[1244]所有数据元素最终都编码为数字。

[1245]每一个完整的数据元素都以“#”代码结尾。

[1246]数字数据元素使用它们的关联的DTMF数字。

[1247]数字数据元素是作为不间断的序列发送的。

[1248]每一个完整的数字数据元素序列都以“#”代码结尾。

[1249]字母数据元素被分解为单个的字符元素。

[1250]使用下列方案对单个字母字符元素进行编码：

[1251]＂A＂＝2

[1252]＂B＂＝22

[1253]＂C＂＝222

[1254]＂D＂＝3

[1255]＂E＂＝33

[12561＂F＂＝333

[1257]...使用标准DTMF字母编码规则，依次类推。

[1258]单个字母字符元素以“#”代码结尾。

[1259]每一个完整的字母数据元素都以“#”代码结尾。

[1260]每一个完整的请求/响应结构都以“#”代码结尾。

[1261]上面的编码示例具体地显示了数字和大写字母字符。然而，也可以进行小写字母和特殊字符的编码。

[1262]因此，上文所描述的API的元素提供了一个协议，根据该协议，来自应用程序的数据可以通过移动消费类通信设备的音频信道进行传递。

[1263]音频信道数据应用的示例

[1264]应用的一个示例是通过音频信道的简单文本消息，而不是如传统那样通过数据信道。图102的移动消费类通信设备10210上的应用程序10221，例如，跨音频信道10211发送带有收款人的标识(例如，电话号码)的字母数字信号。服务器10212中的企业应用程序10222简单地跨另一个音频信道将字母数字信号中继到指定收款人。当然，假设收款人也跨音频信道描述了接收和发送数据的功能。

[1265]更加全面地利用上文所描述的特定API功能的联网应用的更加复杂的示例是对于移动消费者的移动支付功能。所有需要的客户端/服务器数据通信都是通过音频信道“电话呼叫”进行的。在此应用示例中，假设移动消费者具有移动消费类通信设备，能够运行移动支付应用程序，消费者的移动服务计划只允许语音电话。“源”消费者需要从他的或她的移动帐户向朋友的(“目标”消费者)移动帐户汇款。源和目标消费者两者都注册了企业服务器应用程序提供的服务。企业服务器应用程序提供Web服务API，能从源帐户向目标帐户划拨资金。

[1266]此示例中的命令是由CommandID 1代表的payRequest，以及由CommandID 2代表的payResponse。下面的两个表中定义了参数数据结构：

[1267]表E：payRequest参数数据定义：

参数名称	参数描述	数据类型	ParameterID
参数名称	参数描述	数据类型	ParameterID	sourceAccountNumber	汇款的消费者的帐号	1-numeric	1
sourcePIN	汇款的消费者的身份验证数据	1-numeric	2	sourceAccountNumber	汇款的消费者的帐号	1-numeric	1
sourcePIN	汇款的消费者的身份验证数据	1-numeric	2	pay Amount	源消费者需要向目标消费者汇款的金额	1—numeric	3
targetAccountNumberpayMessage	正在向其汇款的消费者的帐号源消费者需要附加于此交易中的消息(即，备注)	1-numeric2-alpha	45	pay Amount	源消费者需要向目标消费者汇款的金额	1—numeric	3

[1268]表F：payResponse参数数据定义：

参数名称	参数描述	数据类型	ParameterID
参数名称	参数描述	数据类型	ParameterID	status	交易的状态。0表示成功，1表示失败。	1-numeric	6
transactionNumber	与此请求关联的唯一交易号	1-numeric	7	status	交易的状态。0表示成功，1表示失败。	1-numeric	6

[1269]现在，对于源消费者支付目标消费者，发生下列操作和交互：

[1270]宿主移动客户端应用程序与源消费者进行交互，并收集下列数据：

[1271]sourceAccountNumber-＂123456789＂

[1272]sourcePIN-＂4321＂

[1273]payAmount-＂15＂

[1274]sourceAccountNumber-＂987654321＂

[1275]payMessage-＂THANKS＂

[1276]由于上下文和配置，宿主移动客户端应用程序“知道”下列数据：

[1277]commandID-＂1＂(i.e.payRequest)

[1278]serverAddress-＂8885551212＂(即，企业应用程序的IVR组件的“电话号码”)

[1279]宿主移动应用程序组合下列数据结构：

[1280]ParameterData[1]

[1281]ParameterID＝1

[1282]ParameterType＝1

[1283]ParameterValue＝＂123456789＂

[1284]ParameterData[2]

[1285]ParameterID＝2

[1286]ParameterType＝1

[1287]ParameterValue＝＂4321＂

[1288]ParameterData[3]

11289]ParameterID＝3

[1290]ParameterType＝1

[1291]ParameterValue＝＂15＂

[1292]ParameterData[4]

[1293]ParameterID＝4

[1294]ParameterType＝1

[1295]ParameterValue＝＂987654321＂

[1296]ParameterData[5]

[1297]ParameterID＝5

[1298]ParameterType＝2

[1299]ParameterValue＝＂Thanks＂

[1300]Request

[1301]commandID＝1

[1302]serverAddress＝＂8885551212＂

[1303]parameterData＝5element ParameterData array fromabove

[1304]然后，移动应用程序使用上面的Request结构数据，调用SendRequest()API。

控制现在传递给客户端API。

[1305]客户端API现在进行编码算法，并将Request结构转换为下列文本字符串：

[1306]

1#1#1#123456789#2#1#4321#3#1#15#4#1#987654321#5#2#8#44#2#66#55#7777###

[1307]对上面的编码示例应用上面的规则，看到下面的东西：

[1308]引导“1#”表示“CommandID 1”，已知是“payRequest”命令

[1309]后续“1#”表示“ParameterID 1”，已知是“sourceAccountNumber”参数。

[1310]后续“1#”表示“AMD参数类型1”，已知是“numeric”。

[1311]后续“123456789#”表示sourceAccountNumber值是“123456789”。

[1312]...对于数字参数类型，依次类推

[1313]尾部“8#44#2#66#55#7777##”是单词“THANKS”的DTMF字母编码。

最后一个“#”表示完整的字母数据元素序列。

[1314]最后一个“#”表示完整的请求/响应数据的结尾。

[1315]返回到示例应用程序的操作。

[1316]然后，API拨打指出的服务器“电话号码”(即“8885551212”)，并启动话音呼叫。

[1317]服务器IVR组件“捡起电话”，并等待编码的DTMF请求数据。

[1318]然后，客户端API传输全部上面的编码的DTMF请求。

[1319]当接收到最后一个#时，服务器IVR“插件”组件开始对编码的DTMF请求数据进行解码。为此，IVR“插件”使用上面提供的编码规则的相反规则。

[1320]IVR“插件”现在组合了客户端的Request结构的完整的副本，现在只在服务器端存储空间中。

[1321]IVR“插件”现在通过企业服务器应用程序实现的ProcessRequest()接口来调用企业服务器应用程序。

[1322]企业服务器应用程序相应地处理请求。

[1323]然后，企业服务器应用程序组合Response结构，正如移动客户端应用程序组合了Request结构那样。

[1324]企业服务器应用程序向IVR插件返回Response结构和控制。

[1325]然后，如上文所描述的，IVR插件对Response结构进行编码(即，在此情况下，带有状态和transactionNumber数据元素)。

[1326]IVR将经过编码的DTMF响应数据传输到移动客户端应用程序API。

[1327]移动客户端应用程序API使用上文所描述的解码规则将经过编码的DTMF响应数据解码为客户端Response结构(即，在此情况下，解码为Response结构)。

[1328]API向宿主客户端移动应用程序返回Response结构和控制。

[1329]宿主客户端移动应用程序收回控制，可以访问服务器Response结构，并继续处理。

[1330]因此，本发明提供了通过移动消费类通信设备的音频信道进行通信的应用程序。如上所述，可以选择不同于DTMF的编码，以加速跨音频信道的数据传输。这样的编码可以依赖于宿主移动消费类通信设备上的特定应用程序和对应的企业服务器。移动消费类通信设备可以用于跨音频信道传递应用程序数据，而不是跨无线通信网络的数据信道。

[1331]本发明的各种特定实施例包括：

[1332]1.一种移动个体化支付系统，包括：

[1333]移动客户端；

[1334]用于管理闭环支付系统的服务器；以及

[1335]能使所述移动客户端和服务器一起作为“移动钱包”的协议。

[1336]2.根据权利要求1所述的系统，其中，所述协议进一步包括：

[1337]简化的UI它只需要一步接一步地输入请求数据，然后显示响应数据。

[1338]3.根据权利要求1所述的系统，进一步包括通过编程性的HTTPS API调用来利用所述移动设备的数据服务的装置。

[1339]4.根据权利要求3所述的系统，进一步包括调用所述编程性的HTTPS API调用的安全性装置。

[1340]5.根据权利要求1所述的系统，进一步包括通过编程性的SMS API调用来利用所述移动设备的SMS文本服务的装置。

[1341]6.一种移动个体化支付系统，包括：

[1342]专用于进行金融交易的移动客户端应用程序；以及

[1343]用于与所述客户端应用程序进行通信以便利用到合作银行系统的通路方法调用提供付款服务的服务器。

[1344]7.根据权利要求6所述的系统，进一步包括由所述合作银行系统维护的合并帐户。

[1345]8.根据权利要求7所述的系统，其中，所述合并帐户表示多个预存款的借记卡。

[1346]9.根据权利要求8所述的系统，其中，所述预存款借记卡链接到所述合作银行系统中的支票帐户。

[1347]10.根据权利要求8所述的系统，其中，每一个所述预存款的借记卡可以通过响应由客户端程序启动的电话呼叫向链接的帐户转移资金或从链接的帐户转移资金来再充值。

[1348]11.根据权利要求6所述的系统，进一步包括至少一个另外的移动客户端应用程序，其中，所述移动客户端应用程序、服务器和所述至少一个另外的移动客户端应用程序的组合构成了闭环支付系统。

[1349]12.根据权利要求6所述的系统，其中，所述移动客户端应用程序、服务器和所述至少一个另外的移动客户端应用程序的组合构成了个人之间的付款转帐系统。

[1350]13.根据权利要求6所述的系统，其中，所述移动客户端应用程序、服务器和所述至少一个另外的移动客户端应用程序的组合构成了对等伙伴与商家之间的付款转帐系统。

[1351]14.一种移动个体化支付系统，包括：

[1352]客户端和平台线路协议与MCAP编解码器结合使用，以序列化/解序列化数据以在多个移动设备和平台之间传递，所述平台包括提供基于J2EE的主机服务的数据中心。

[1353]15.根据权利要求14所述的系统，其中，所述MCAP编解码器是移动设备上的组件。

[1354]16.根据权利要求14所述的系统，其中，所述数据中心根据客户端和平台线路协议规范来处理序列化和解序列化。

[1355]17.根据权利要求14所述的系统，在移动设备上存在某些功能，包括能够显示输入字段和捕获帐户持有人的输入，能够通过编程性的HTTPS API调用来利用移动设备的数据服务。

[1356]18.根据权利要求14所述的系统，在移动设备上存在某些功能，包括能够显示输入字段和捕获帐户持有人的输入，能够通过编程性的SMS API调用，通过移动设备的SMS文本服务，来利用移动设备的数据服务。

[1357]19.根据权利要求14所述的系统，进一步包括通过编程的API调用来利用移动设备的持久数据服务。

[1358]20.根据权利要求14所述的系统，其中，移动设备包括能够截取发往移动设备的入站消息，并“唤醒”MCAP以便进行处理，其中，入站SMS消息是在特定端口上截取的，并通过协议进行处理。

[1359]21.根据权利要求14所述的系统，移动设备包括用于以编程方式与移动设备的“地址簿”集成，以便特定输入字段可以“链接”到地址簿，并通过声音、振动或光，以编程方式将值得注意的事件通知给移动设备帐户持有人的装置。

[1360]22.一种用于操作闭环支付系统的方法，包括：

[1361]在支持IP的设备上激活客户端应用程序；

[1362]建立到支付服务器的通信渠道；

[1363]将来自客户端应用程序的请求传输到所述支付服务器，其中，所述请求包括付款金额和标识所述收款人的标识号码；

[1364]调整帐户余额以反映所述请求；以及

[1365]将收到付款通知给所述收款人。

[1366]23.根据权利要求22所述的方法，进一步包括：

[1367]如果付款是针对没有帐户的号码，则为收款人建立帐户；以及

[1368]让用户开一个帐户以接收储蓄在建立的帐户中的资金的“病毒式”诱饵。

[1369]24.根据权利要求22所述的方法，进一步包括：

[1370]如果收款人的资料指出小费是适当的，则从付款请求者请求添加“小费”金额；以及

[1371]调整余额，以反映小费的额外支付。

[1372]25.根据权利要求22所述的方法，进一步包括：

[1373]通过从合并帐户向相应的帐户划拨资金来对每一个交易实时进行结算。

[1374]26.根据权利要求22所述的方法，进一步包括：

[1375]在离线模式下对选定交易进行结算。

[1376]27.根据权利要求26所述的方法，进一步包括基于近场通信链路来启动交易。

[1377]28.根据权利要求26所述的方法，进一步包括基于由无线射频识别(RFID)转发器和接收器建立的通信链路启动交易。

[1378]29.根据权利要求26所述的方法，进一步包括在记帐程序中连同交易金额记录每一个交易的描述。

[1379]30.根据权利要求29所述的方法，其中，所述记录过程包括向记帐程序实时发送交易的口头描述。

[1380]31.根据权利要求29所述的方法，其中，所述记录过程包括通过SMS向记帐程序实时发送交易的文本描述。

[1381]32.根据权利要求22所述的方法，其中，启动所述客户端应用程序的过程包括：

[1382]输入第一密码以标识用户并激活所述客户端应用程序的操作；

[1383]输入第二密码以建立到所述支付服务器的安全链接；以及

[1384]验证所述密码匹配预期的呼叫方ID。

[1385]33.一种用于进行金融交易的方法，包括：

[1386]通过第一通信路径从移动设备向支付服务器发送进行金融交易的请求；

[1387]通过第二通信路径发送个人标识号(PIN)；

[1388]在支付服务器中将所述请求与PIN相关联；以及

[1389]基于请求和PIN之间的关联，进行金融交易。

[1390]34.根据权利要求33所述的方法，其中，发送请求的过程进一步包括：

[1391]形成命令；以及

[1392]通过短消息服务(SMS)发送命令。

[1393]35.根据权利要求34所述的方法，其中，形成所述命令的过程进一步包括：

[1394]请求支付。

[1395]36.根据权利要求35所述的方法，其中，形成所述命令的过程进一步包括：

[1396]请求向对等伙伴进行支付。

[1397]37.根据权利要求35所述的方法，其中，形成所述命令的过程进一步包括：

[1398]请求向商家进行支付。

[1399]38.根据权利要求35所述的方法，其中，形成所述命令的过程进一步包括：

[1400]向所述命令添加消息。

[1401]39.根据权利要求38所述的方法，其中，形成所述命令的过程进一步包括：

[1402]向所述命令添加记录标记。

[1403]40.根据权利要求39所述的方法，其中，发送所述命令的过程进一步包括：

[1404]向计帐应用程序发送所述命令。

[1405]41.根据权利要求39所述的方法，其中，发送所述命令的过程进一步包括：

[1406]向增值服务提供商发送所述命令。

[1407]42.根据权利要求33所述的方法，其中，形成所述命令的过程进一步包括：

[1408]请求帐户余额。

[1409]43.根据权利要求42所述的方法，进一步包括：

[1410]通过SMS接收帐户余额消息。

[1411]44.根据权利要求33所述的方法，进一步包括：

[1412]请求帐户历史。

[1413]45.根据权利要求44所述的方法，进一步包括：

[1414]通过SMS接收帐户历史消息。

[1415]46.根据权利要求33所述的方法，进一步包括：

[1416]请求向对等伙伴发送支付请求。

[1417]47.根据权利要求46所述的方法，进一步包括：

[1418]通过SMS向对等伙伴发送支付请求消息。

[1419]48.根据权利要求47所述的方法，进一步包括：

[1420]接收支付已经被授权或者拒绝的指示，所述指示是通过SMS发送的。

[1421]49.根据权利要求48所述的方法，进一步包括：

[1422]请求对等伙伴建立一个帐户，从该帐户向请求者进行支付，所述请求是通过SMS发送的。

[1423]50.根据权利要求33所述的方法，进一步包括：

[1424]请求帮助。

[1425]51.根据权利要求50所述的方法，进一步包括：

[1426]通过SMS接收帮助消息。

[1427]52.根据权利要求33所述的方法，其中，移动设备是蜂窝电话。

[1428]53.根据权利要求33所述的方法，其中，所述第一通信路径是SMS文本通信渠道，所述第二通信路径是话音通信渠道。

[1429]54.根据权利要求53所述的方法，其中，在DTMF中对PIN进行编码。

[1430]55.根据权利要求53所述的方法，其中，给出PIN的清晰发音，然后由交互式语音识别系统对其进行解码。

[1431]56.一种使用移动设备进行金融交易的方法，包括：

[1432]激活移动客户端应用程序以管理金融请求；

[1433]显示用户界面，以便形成命令；

[1434]通过第一通信路径从移动设备向支付服务器发送包括进行金融交易的命令的请求；

[1435]通过第二通信路径发送个人标识号(PIN)；

[1436]在支付服务器中将所述请求与PIN相关联；以及

[1437]基于请求和PIN之间的关联，进行金融交易。

[1438]57.根据权利要求56所述的方法，其中，发送所述请求的过程进一步包括：

[1439]通过消息协议发送命令。

[1440]58.根据权利要求57所述的方法，其中，形成所述命令的过程进一步包括：

[1441]请求支付。

[1442]59.根据权利要求56所述的方法，其中，形成所述命令的过程进一步包括：

[1443]请求向对等伙伴进行支付。

[1444]60.根据权利要求59所述的方法，其中，形成所述命令的过程进一步包括：

[1445]请求向商家进行支付。

[1446]61.根据权利要求56所述的方法，其中，形成所述命令的过程进一步包括：

[1447]向所述命令添加消息。

[1448]62.根据权利要求61所述的方法，其中，形成所述命令的过程进一步包括：

[1449]向所述命令添加记录标记。

[1450]63.根据权利要求62所述的方法，其中，发送所述命令的过程进一步包括：

[1451]向计帐应用程序发送所述命令。

[1452]64.根据权利要求62所述的方法，其中，发送所述命令的过程进一步包括：

[1453]向增值服务提供商发送所述命令。

[1454]65.根据权利要求56所述的方法，其中，形成所述命令的过程进一步包括：

[1455]请求帐户余额。

[1456]66.根据权利要求65所述的方法，进一步包括：

[1457]通过选定协议接收帐户余额消息。

[1458]67.根据权利要求56所述的方法，进一步包括：

[1459]请求帐户历史。

[1460]68.根据权利要求67所述的方法，进一步包括：

[1461]通过选定协议接收帐户历史消息。

[1462]69.根据权利要求56所述的方法，进一步包括：

[1463]请求向对等伙伴发送支付请求。

[1464]70.根据权利要求69所述的方法，进一步包括：

[1465]通过选定协议向对等伙伴发送支付请求消息。

[1466]71.根据权利要求70所述的方法，进一步包括：

[1467]接收支付已经被授权或者拒绝的指示，所述指示是通过SMS发送的。

[1468]72.根据权利要求71所述的方法，进一步包括：

[1469]请求对等伙伴建立一个帐户，从该帐户向请求者进行支付，所述请求是通过SMS发送的。

[1470]73.根据权利要求56所述的方法，进一步包括：

[1471]请求帮助。

[1472]74.根据权利要求73所述的方法，进一步包括：

[1473]通过SMS接收帮助消息。

[1474]75.根据权利要求56所述的方法，其中，移动设备是蜂窝电话。

[1475]76.一种移动个体化支付系统，包括：

[1476]专用于进行金融交易的移动客户端应用程序；以及

[1477]用于与所述客户端应用程序进行通信，以便提供链接到多个帐户中的选定帐户的支付服务的服务器。

[1478]77.根据权利要求76所述的系统，进一步包括至少一个另外的移动客户端应用程序，其中，所述移动客户端应用程序、服务器和所述至少一个另外的移动客户端应用程序的组合构成了具有较低的交易费用的闭环支付系统。

[1479]78.根据权利要求76所述的系统，进一步包括至少一个另外的移动客户端应用程序，其中，所述移动客户端应用程序、服务器和所述至少一个另外的移动客户端应用程序的组合构成了没有交易费用的闭环支付系统。

[1480]79.根据权利要求76所述的系统，包括个人之间的支付转帐系统。

[1481]80.根据权利要求79所述的系统，包括向每一个对等伙伴收取的月度服务费。

[1482]81.根据权利要求76所述的系统，包括消费者与商家的支付转帐系统，其中，向消费者收取交易费用。

[1483]82.根据权利要求81所述的系统，进一步包括代表消费者选择支付交易费用的商家支付计划。

[1484]83.一种用于进行购物的方法，包括：

[1485]选择产品；

[1486]激活移动客户端应用程序以处理金融交易；

[1487]进行购物；以及

[1488]在指定的地址自动地接收选定产品。

[1489]84.一种用于进行购物的方法，包括：

[1490]选择产品；

[1491]激活移动客户端应用程序以处理金融交易；

[1492]进行购物；以及

[1493]在指定地理位置自动地接收选定产品。

[1494]85.根据权利要求84所述的方法，进一步包括使用与手机关联的从外部可见的条形码，通过条形码扫描来激活交易。

[149S]86.根据权利要求84所述的方法，进一步包括利用与手机关联的近场通信设备来激活交易。

[1496]87.根据权利要求84所述的方法，进一步包括利用与手机关联的RFID设备来激活交易。

[1497]88.一种用于进行购物的方法，包括：

[1498]预先授权选定产品或服务的购买；

[1499]利用手机进行购物；以及

[1500]消除由消费者进行的任何进一步的操作以授权购物。

[1501]89.根据权利要求88所述的方法，进一步包括使用与手机关联的从外部可见的条形码，通过条形码扫描来激活交易。

[1502]90.根据权利要求88所述的方法，进一步包括利用与手机关联的近场通信设备来激活交易。

[1503]91.根据权利要求88所述的方法，进一步包括利用与手机关联的RFID设备来激活交易。

[1504]92.一种用于防止从手机输入的重复金融交易的欺骗性提交的方法，包括：

[1505]在授权金融交易之前，将从手机接收到的序列号与预期的序列号进行比较；以及

[1506]如果两个序列号匹配，则允许进行交易。

[1507]93.根据权利要求92所述的方法，进一步包括：

[1508]请求PIN；以及

[1509]将从呼叫方ID获取的电话号码和PIN与数据库进行比较，以验证手机的使用是合法的；

[1510]消除由消费者进行的任何进一步的操作以授权购物。

[1511]94.一种用于防止从手机输入的重复金融交易的欺骗性提交的方法，包括：

[1512]在授权金融交易之前，将从手机接收到的序列号与以前使用的序列号的列表进行比较；以及

[1513]如果接收到的序列号不匹配以前使用的序列号中的任何一个，则允许进行交易。

[1514]95.根据权利要求94所述的方法，进一步包括：

[1515]请求PIN；以及

[1516]将从呼叫方ID获取的电话号码和PIN与数据库进行比较，以验证手机的使用是合法的；

[1517]消除由消费者进行的任何进一步的操作以授权购物。

[1518]96.一种用于防止从手机输入的重复金融交易的欺骗性提交的方法，包括：

[1519]在授权金融交易之前，将从手机接收到的序列号与预期的序列号进行比较；

[1520]在授权金融交易之前，将从手机接收到的序列号与预期的序列号进行比较；以及

[1521]如果在第一比较步骤中序列号匹配而在第二比较步骤中不匹配，则允许进行交易。

[1522]97.根据权利要求96所述的方法，进一步包括：

[1523]请求PIN；以及

[1524]将从呼叫方ID获取的电话号码和PIN与数据库进行比较，以验证手机的使用是合法的。

[1525]98.一种用于防止从手机输入的金融交易的欺骗性提交的方法，包括：

[1526]通过发送具有第一标识符的请求来启动金融交易，所述请求是使用第一通信渠道发送的；

[1527]通过第二通信渠道，使用DTMF音调发送PIN；

[1528]只有在所述请求和PIN匹配一个共同帐户的情况下才达成金融交易。

[1529]99.一种用于防止从手机输入的金融交易的欺骗性提交的方法，包括：

[1530]在第一通信渠道上接收启动金融交易的请求，所述请求具有第一帐户标识符；

[1531]通过第二通信渠道，使用DTMF音调接收PIN；以及

[1532]只有在所述请求和PIN匹配一个共同帐户的情况下才达成金融交易。

[1533]100.根据权利要求99所述的方法，进一步包括启动向由第一帐户标识符指出的电话号码的电话呼叫。

[1534]101.根据权利要求99所述的方法，其中，第一通信渠道是SMS传输渠道。

[1535]102.一种用于防止从手机使用SMS输入的金融交易中的欺诈的方法，包括：

[1536]在手机上形成带有进行金融交易的指示的第一明语SMS消息；

[1537]向交易处理器发送SMS消息；

[1538]截取SMS消息；以及

[1539]在将经过转换的SMS消息发送到交易处理器之前，将截取的SMS消息转换为数据服务消息。

[1540]103.根据权利要求102所述的方法，进一步包括：

[1541]将包含密码的第二明语消息发送到交易处理器；

[1542]截取第二SMS消息；以及

[1543]在将经过转换的SMS消息发送到交易处理器之前，将第二截取的SMS消息转换为数据服务消息。

[1544]104.根据权利要求103所述的方法，进一步包括在手机中的交易文件夹中存储第一明语SMS消息。

[1545]105.根据权利要求103所述的方法，进一步包括在转换成数据服务消息之前对第一和第二明语SMS消息进行加密。

[1546]106.根据权利要求103所述的方法，其中，所述截取步骤是由线路套执行的，线路套包括在手机和其SIM卡之间插入的移动客户端应用程序(MCA)。

[1547]107.一种具有SIM卡的手机设备，所述设备进一步包括在SIM卡和手机之间插入的线路，用于截取发送给交易处理器或从交易处理器接收到的SMS消息，所述线路包括用于在截取的消息被发送到交易处理器之前对截取的消息进行加密并将它们转换为数据服务消息，以及对于从交易处理器接收到的消息，用于对数据服务消息进行解密并将数据服务消息转换为明语SMS消息的逻辑元件。

[1548]108.一种用于进行金融交易的移动设备，包括：

[1549]通信层；

[1550]程序API；

[1551]用于连接到程序API的用户界面API；以及

[1552]用于连接到增值服务的用户界面API。

[1553]109.根据权利要求108所述的系统，其中，能够通过编程性的SMS API调用，通过移动设备的SMS文本服务，来利用移动设备的SMS数据服务。

[1554]110.根据权利要求108所述的系统，其中，能够通过针对增值服务的编程性的API调用，来利用移动设备的持久数据服务。

[1555]111.一种闭环金融系统，包括：

[1556]用于从多个帐户持有人接收金融交易请求的交易处理器；

[1557]多个手机，每一个手机都与对应的帐户持有人相关联；

[1558]用于将手机链接到交易处理器的通信网络。

[1559]112.根据权利要求111所述的系统，进一步包括总帐，用于将资金从一个帐户持有人转移到至少一个另外的帐户持有人，而不产生信用卡交易费用或银行ACH费用。

[1560]113.根据权利要求111所述的系统，进一步包括合并帐户，其中包括帐户持有人持有的所有资金，合并帐户与总帐关联，以管理帐户持有人之间的资金转拨。

[1561]114.根据权利要求113所述的系统，进一步包括用于从外部来源向合并帐户注入资金的装置。

[1562]115.根据权利要求114所述的系统，进一步包括用于从合并帐户移动资金的装置。

[1563]116.一种用于操作闭环金融系统的方法，包括：

[1564]维护包含来自所有帐户持有人的资金的合并帐户；

[1565]从至少一个帐户持有人接收划拨资金的金融交易请求；以及

[1566]维护总帐，以跟踪合并帐户中的属于每一个帐户持有人的资金。

[1567]117.根据权利要求116所述的方法，其中，资金被转移到至少一个另外的帐户持有人。

[1568]118.根据权利要求116所述的方法，其中，资金被转移到一个非帐户持有人。

[1569]119.根据权利要求118所述的方法，进一步包括通过SMS消息通知非帐户持有人资金的可用性。

[1570]120.根据权利要求119所述的方法，进一步包括为非帐户持有人开一个新帐户，从而使非帐户持有人成为新帐户持有人。

[1571]121.根据权利要求120所述的方法，其中，无需广告费就获得了新帐户持有人。

[1572]122.根据权利要求120所述的方法，进一步包括对新帐户持有人启动适应性(OFAC)检查。

[1573]123.根据权利要求122所述的方法，进一步包括：

[1574]将新帐户持有人指定为“无卡”帐户持有人；以及

[1575]给予无卡帐户持有人有限的资金接触权限。

[1576]124.根据权利要求123所述的方法，进一步包括通过向记录地址发送借记卡来向无卡帐户持有人发放借记卡。

[1577]125.根据权利要求124所述的方法，进一步包括：

[1578]接收在记录的地址处接收到卡的确认；以及

[1579]将无卡帐户持有人指定为具有对合并帐户中持有的资金的完全访问权限的帐户持有人。

[1580]126.根据权利要求116所述的方法，其中，维护、接收，以及维护都是由单个实体进行管理的。

[1581]127.根据权利要求126所述的方法，其中，单个实体是记录系统，并承担维护合并帐户的风险。

[1582]128.一种用于防止从手机输入的金融交易的欺骗性提交的系统，包括：

[1583]可由帐户持有人控制的第一层；以及

[1584]可由管理实体控制的第二层。

[1585]129.根据权利要求128所述的系统，所述第一层进一步包括：

[1586]用于指定帐户持有人有资格从由帐户持有人控制的帐户接收资金的装置；以及

[1587]用于指定帐户持有人无资格从由帐户持有人控制的帐户接收资金的装置。

[1588]130.根据权利要求128所述的系统，其中，所述第一层进一步包括用于指定由帐户持有人控制的帐户的用户的花费限制的装置。

[1589]131.根据权利要求128所述的系统，其中，所述第二层进一步包括用于指定由帐户持有人控制的帐户的用户的花费速度限制的装置。

[1590]132.根据权利要求128所述的系统，其中，所述第二层进一步包括用于检测欺骗性交易的装置。

[1591]133.一种用于进行金融交易的移动设备，包括：

[1592]话音通信连接；

[1593]在移动设备上执行的用于生成用户界面API以创建交易请求的JAVA API；

[1594]在移动设备上执行的用于使用DTMF音调向交易处理器传输请求的JAVA API。

[1595]134.根据权利要求133所述的设备，进一步包括：

[1596]在移动设备上执行的用于接收来自交易处理器的DTMF编码响应的JAVA API；以及

[1597]在移动设备上执行的用于将编码响应转换为用户界面上人可读取的格式的JAVA API。

[1598]135.根据权利要求134所述的设备，进一步包括用于在传输之前对所述请求进行加密的装置以及在转换之前对所述响应进行解密的装置。

[1599]136.一种金融交易系统，包括：

[1600]用于启动金融交易的第一移动设备，具有用于选择启动所述金融交易的通信渠道的装置；以及

[1601]交易处理器。

[1602]137.根据权利要求136所述的系统，进一步包括与所述交易处理器关联的用于确定通信渠道的装置，用于通知第二移动设备，说明金融交易已经进行，其中，所述金融交易至少涉及两个帐户持有人。

[1603]138.根据权利要求137所述的系统，其中，由所述第一设备选定的所述通信渠道与由所述交易服务器选定以与所述第二移动设备联系的通信渠道类型不相同。

[1604]139.根据权利要求102所述的方法，进一步包括：

[1605]通过安全的SMS综合器，向所述交易处理器发送包含密码的SMS消息。

[1606]有许多现有的产品，潜在地，有大量的新产品将受益于本发明。例如，诸如IP电话(VoIP)电话之类的任何支持因特网的电话设备都可以用来实施本发明，尽管可以固定在一个特定位置，不一定是移动的。在其他实施例中，可以使用电子邮件地址作为电话号码的补充或代替电话号码来标识参与金融交易的一方或多方。此外，本发明也不仅限于手机，而是可以包括任何移动设备，子机、PDA，或其他能够连接到诸如电话、因特网、蜂窝式，或其他有线或无线通信网络之类的通信渠道的其他通信设备。

[1607]还应该理解，附图中所描述的一个或多个元件也可以以分离的或集成方式来实现，或者甚至去除或在某些情况下不工作，可以根据特定的应用场合来使用。

[1608]虽然是利用特定实施例来描述本发明的，但是，这些实施例只是说明性的，而不对本发明进行限制。例如，其他实施例可以包括各种显示器体系结构、生物特征传感器、压力传感器、温度传感器、光传感器、化学传感器、X射线及其他电磁传感器、放大器、门阵列、其他逻辑电路、打印机，以及用于实现所描述的各种实施例的存储电路。手机可以是任何通信设备。

[1609]另外，附图中的任何信号箭头都应该是被视为只是示范性的，而不是限制性的，除非特别声明。此外，本申请中所使用的术语“或”一般是指“和/或”，除非另有陈述。组件或步骤的组合也将被视为被指出的，其中，术语被预见因为呈现分离或组合的能力是不清楚的。

[1610]如在本申请中的描述中以及随后的整个权利要求书中所使用的，“一个”包括多个引用，除非上下文明显地特别指出。此外，如在本描述以及随后的整个权利要求书中所使用的，“在...内”的含义也包括“在...内”和“在...上”，除非上下文明显地特别指出。

[1611]本发明的描述只是为了说明和描述。它不是详尽的说明或将本发明限于所描述的准确的形式，显然，根据上文的讲述，许多修改方案和变化也是可以的。所选择的实施例只是为了最好地说明本发明的原理，以及其实际应用。本描述将能使本领域技术人员以各种实施例最佳地利用和实施本发明，根据特定用途进行各种修改。本发明的范围由下面的权利要求进行定义。

Claims

1.一种金融交易系统，包括：

连接到网络的消费者界面，包括：

处理来自Web浏览器客户端的交易请求的Web界面；

处理来自移动电话客户端上的移动因特网浏览器的交易请求的移动因特网浏览器；

使用SMS文本消息处理交易请求的SMS界面；以及

处理来自在移动电话客户端上执行的移动客户端应用程序的请求的移动客户端应用程序界面。

2.根据权利要求1所述的系统，其中，消费者界面进一步包括：

处理来自电话音频信道的请求的交互式语音响应界面。

3.根据权利要求1所述的系统，包括：

新注册的用户的合并帐户，其中，在注册之后，新注册的用户可以立即与已注册的用户进行交易。

4.根据权利要求1所述的系统，其中，所述移动客户端应用程序界面允许进行汇款交易、加载帐户交易、卸载帐户交易，以及余额查询交易。

5.根据权利要求1所述的系统，其中，消费者界面进一步包括：

处理来自即时消息客户端的请求的即时消息界面。

6.根据权利要求1所述的系统，包括：

金融合作伙伴界面；

商家界面，其中，用户能通过消费者界面访问位于通过所述金融合作伙伴界面连接到系统的银行中的资金，并向连接到所述商家界面的商家转帐。

7.根据权利要求1所述的系统，包括：

由所述金融交易系统进行管理的记录系统，记录通过消费者界面执行的交易。

8.根据权利要求1所述的系统，包括：

由所述金融交易系统进行管理的合并帐户，其中，通过消费者界面访问所述系统的多个客户端在合并帐户中具有帐户。

9.根据权利要求8所述的系统，其中，多个客户端在所述合并帐户中没有帐户，而是在可以访问所述系统的金融机构中具有帐户。

10.一种方法，包括：

提供与第一金融合作伙伴进行交易的应用程序界面；

提供接收进行交易的请求的SMS消息界面；以及

提供用于接收进行交易的请求的移动客户端应用程序界面，其中，通过SMS消息界面或移动客户端界面，客户端可以请求从位于第一金融合作伙伴的第一帐户向位于第二金融合作伙伴的第二帐户转帐。

11.根据权利要求10所述的方法，包括：

提供用于与第二金融合作伙伴进行交易的应用程序界面，其中，通过SMS消息界面或移动客户端界面，客户端可以请求从位于第一金融合作伙伴的帐户向位于第二金融合作伙伴的帐户转帐。

12.根据权利要求10所述的方法，包括：

提供用于记录通过所述SMS消息界面和移动客户端界面请求的交易的记录系统。

13.一种方法，包括：

在移动电话的显示器上显示第一屏幕，以显示多个选项，包括向另一方付款的第一选项和请求余额信息的第二选项；

在用户选择所述第一选项时，显示第二屏幕，供用户输入向其发出支付的目标电话号码；

在用户输入所述目标电话号码之后，显示第三屏幕，供用户输入交易金额；

在用户输入所述电话号码之后，显示第四屏幕，供用户输入PIN代码；以及

在用户输入所述PIN代码之后，以无线方式向服务器发送包括所述目标电话号码、交易金额以及PIN代码的交易信息，以便进行处理。

14.所述方法包括：

在用户输入所述目标电话号码之后，显示第五屏幕，供用户输入可选消息。

15.根据权利要求13所述的方法，包括：

在用户选择了所述第二选项时，以无线方式向所述服务器发送查询余额信息的请求；

从所述服务器接收余额信息；以及

在第五屏幕中显示所述余额信息。

16.根据权利要求13所述的方法，其中，所述第一屏幕进一步提供从另一方请求付款的第三选项。

17.根据权利要求13所述的方法，其中，所述第二屏幕具有第三选项，在用户选择了该选项时，给用户提供地址簿的使用权，从该地址簿中，用户可以选择一个条目用作所述目标电话号码。

18.根据权利要求13所述的方法，其中，所述交易信息包括由所述移动电话生成的序列号。

19.根据权利要求13所述的方法，其中，资金是在所述服务器中维护的，而不是在所述移动电话上维护的。

20.根据权利要求13所述的方法，进一步包括：

当在所述移动电话中接收到要求付款的请求时，显示第五屏幕，供用户可以输入小费金额。

21.一种方法，包括：

从第一用户接收向第二用户支付某一金额的付款指示，其中，所述第一用户是已注册的用户，所述第二用户通过所述第二用户的电话号码来进行标识；

基于所述电话号码，确定所述第二用户不是已注册的用户；

向与所述电话号码关联的设备发送第一电子消息，通知所述第二用户来自所述第一用户的待付款；

在发送所述第一电子消息之后，注册所述第二用户，并给所述第二用户呈现接受来自所述第一用户的待付款的第一选项，以及拒绝来自所述第一用户的待付款的第二选项；

当所述第二用户选择所述第一选项时，从与所述第一用户关联的第一帐户划出所述金额，并向与所述第二用户关联的第二帐户划入所述金额；以及

当所述第二用户选择所述第二选项时，向所述第一用户发送付款被拒绝的第二电子消息。

22.根据权利要求21所述的方法，其中，所述第二帐户位于合并帐户中，并且当所述第一用户是无卡已注册的用户时，所述第一帐户位于所述合并帐户中，以及所述划出和划入过程包括在所述合并帐户内维护所述金额。

23.根据权利要求21所述的方法，其中，所述第二帐户位于合并帐户中，并且当所述第一用户是无卡已注册的用户时，所述第一帐户位于所述合并帐户中，以及所述划出和划入过程包括不在所述合并帐户外部转移所述金额。

24.根据权利要求21所述的方法，其中，当所述第一用户是无卡已注册的用户时，所述第一帐户位于第一合并帐户中，而所述第二帐户位于不同于所述第一合并帐户的第二合并帐户中，以及所述划出和划入过程包括从所述第一合并帐户向所述第二合并帐户转移所述金额。

25.根据权利要求21所述的方法，其中，所述第一用户是有卡已注册的用户，而所述第二帐户位于合并帐户中，以及所述划出和划入过程包括从所述第一帐户向所述合并帐户中的所述第二帐户转移所述金额，从而，所述合并帐户被增加了所述金额。

26.根据权利要求21所述的方法，包括：

除所述付款指示之外，还接收由发送了所述付款指示的设备生成的序列号；以及

在接收所述序列号之后，生成所述付款指示的交易号。

27.根据权利要求21所述的方法，包括：

只有在所述序列号不匹配存储在数据库中的任何以前接收到的序列号的情况下才处理所述付款指示。

28.根据权利要求27所述的方法，其中，所述数据库包括在轮询时间周期内接收到的序列号。

29.根据权利要求21所述的方法，包括：

在接收到所述序列号之后，生成预期的序列号；以及

只有在所述序列号匹配所述预期的序列号的情况下才处理所述付款指示。

30.一种方法，包括：

基于所述电话号码，确定所述第二用户不是已注册的用户；

在发送所述第一电子消息之后，注册所述第二用户，并给所述第二用户呈现接受来自所述第一用户的待付款的第一选项，拒绝来自所述第一用户的待付款的第二选项，以及请求对来自所述第一用户的待付款作出更改的第三选项；

31.根据权利要求30所述的方法，包括：

当所述第二用户选择所述第三选项时，向所述第一用户发送第三电子消息，说明所述第二用户请求对所述待付款进行更改。

32.根据权利要求30所述的方法，包括：

当所述第二用户选择所述第三选项时，

接收来自所述第二用户将待付款更改为不同的金额的请求，

向所述第一用户发送第三电子消息，通知所述第一用户对所述待付款进行更改，

给所述第一用户呈现接受所述对所述待付款的更改的第四选项或拒绝对所述待付款的更改的第五选项，以及

当所述第一用户选择所述第四选项时，从所述第一用户的帐户中划出所述所述不同的金额并向与所述第二用户关联的帐户划入所述不同的金额。

33.根据权利要求30所述的方法，其中，所述设备至少是智能电话、移动电话设备、便携式电子邮件设备、个人数字助理或计算机中的一个。

34.根据权利要求30所述的方法，包括：

在确定所述第二用户不是已注册的用户之后，在所述第一帐户中预留出所述金额。

35.根据权利要求30所述的方法，包括：

在确定所述第二用户不是已注册的用户之后，在所述第一帐户中预留出所述金额；以及

在从接收到付款指示而所述第二用户仍没有注册时起一定天数过去之后，取消所述第一帐户中的所述金额的预留。

36.一种方法，包括：

基于所述电话号码，确定所述第二用户不是已注册的用户；

向与所述电话号码关联的设备发送第一电子消息，通知所述第二用户所述第一用户尝试付款；

在发送所述第一电子消息之后，注册所述第二用户，向所述第一用户发送第二电子消息，说明第二用户已经注册，并给所述第一用户呈现给所述第二用户支付所述金额的第一选项；以及

当所述第一用户选择所述第一选项时，从与所述第一用户关联的第一帐户中划出所述所述金额，并向与所述第二用户关联的第二帐户划入所述金额。

37.根据权利要求36所述的方法，包括：

在所述第二用户进行注册之后，给所述第一帐户划入引荐奖金金额。

38.根据权利要求36所述的方法，包括：

在所述第二用户进行注册之后，给所述第二帐户划入引荐奖金金额。

39.根据权利要求36所述的方法，包括：

向所述第一用户发送第二电子消息，说明第二用户不是已注册的用户。

40.根据权利要求36所述的方法，包括：

在接收所述序列号之后，生成所述付款指示的交易号。

41.一种方法，包括：

接收从用户设备以无线方式传输的价值交换交易的电子请求；

与所述电子请求与一起接收与所述电子请求关联的传输的密钥；

判断所述传输的密钥是否存在于交易表中；

如果所述传输的密钥不在所述交易表中，则向所述交易表中输入所述传输的密钥和价值交换交易，并处理所述价值交换交易；

如果所述传输的密钥位于所述交易表中，则不对所述价值交换交易进行处理。

42.根据权利要求41所述的方法，其中，所述传输的密钥包括标识请求了所述价值交换交易的用户的电子标识符和序列号，所述序列号存储在所述用户设备中，在由所述用户设备传输下一个价值交换交易之前前进到序列中的下一个编号。

43.根据权利要求42所述的方法，其中，所述序列号存储在所述用户设备中的非易失性存储器中。

44.根据权利要求41所述的方法，其中，所述传输的密钥包括伪随机数。

45.根据权利要求41所述的方法，所述传输的密钥包括标识请求了所述价值交换交易的用户的第一电子标识符，标识作为所述价值交换交易的目标的用户的第二电子标识符，所述价值交换交易的金额，以及与所述价值交换交易关联的时间。

46.根据权利要求41所述的方法，其中，所述价值交换交易包括从与所述用户设备关联的第一用户向与另一个用户设备关联的第二用户汇款。

47.根据权利要求41所述的方法，其中，所述用户设备是移动电话。

48.根据权利要求41所述的方法，其中，所述传输的密钥不在所述用户设备上显示。

49.根据权利要求41所述的方法，其中，电子请求是通过所述用户设备的SMS文本消息服务发送的。

50.根据权利要求41所述的方法，其中，当所述用户设备使用第一应用程序客户端发送所述电子请求时，所述传输的密钥包括第一信息，当所述用户设备使用不同于所述第一应用程序客户端的第二应用程序客户端发送所述电子请求时，所述传输的密钥包括第二信息。

51.根据权利要求50所述的方法，其中，所述第一应用程序客户端是在所述用户设备上执行的专用价值交换交易服务应用程序，而所述第二应用程序客户端是所述用户设备的SMS消息应用程序。

52.根据权利要求41所述的方法，其中，如果所述传输的密钥位于所述交易表中，则暂停发送所述电子请求的用户的帐户。

53.根据权利要求41所述的方法，其中，处理所述价值交换交易的过程包括：

为所述价值交换交易生成交易标识符号码；

向所述用户设备发送包括所述交易标识符号码的电子消息，其中，所述交易标识符号码在所述用户设备上是可查看的。

54.一种方法，包括：

接收与所述电子请求关联的传输的密钥；

生成预期的密钥；

将所述传输的密钥与所述预期的密钥进行比较；以及

如果所述传输的密钥匹配所述预期的密钥，则处理所述价值交换交易。

55.根据权利要求54所述的方法，其中，生成所述预期的密钥的过程包括使用为与所述价值交换交易关联的用户帐户存储的种子值对一个函数进行求值，所述方法进一步包括在对所述函数进行求值之后，确定序列中的下一个种子值，并用序列中的所述下一个种子值替换为所述用户帐户存储的所述种子值。

56.根据权利要求54所述的方法，包括：

如果所述传输的密钥不匹配所述预期的密钥，则不对所述价值交换交易进行处理，并暂停与所述价值交换交易关联的用户帐户。

57.根据权利要求54所述的方法，其中，处理所述价值交换交易的过程包括：

为所述价值交换交易生成不同于所述预期的密钥的交易标识符号码；

向所述用户设备发送包括所述交易标识符号码的电子消息，其中，所述交易标识符号码显示在所述用户设备上。

58.根据权利要求54所述的方法，其中，所述价值交换交易包括从与所述用户设备关联的第一用户向与另一个用户设备关联的第二用户汇款。

59.根据权利要求54所述的方法，其中，所述预期的密钥是伪随机数。

60.根据权利要求54所述的方法，其中，生成所述预期密钥的过程包括：

从与所述价值交换交易关联的用户资料中检索种子值；

从所述用户资料中检索有关用来生成所述传输的密钥的函数的信息；以及

使用所述种子值对所述函数进行求值。

61.一种方法，包括：

处理系统的一组用户的金融交易，其中，所述金融交易可以通过移动电话指定，所述用户的子组与金融机构关联；

处理与第一金融机构关联的金融交易，其中，第一子组中的用户与所述第一金融机构关联；

处理与第二金融机构关联的金融交易，其中，第二子组中的用户与所述第二金融机构关联；

处理与第三金融机构关联的金融交易，其中，第三子组中的用户与所述第三金融机构关联；

维护包括与所述第一、第二、以及第三金融机构关联的所述第一、第二以及第三子组用户的资金的虚拟合并帐户；以及

基于所述第一子组用户的所述虚拟合并帐户中的资金的浮动收益，加所述第三子组用户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第一金融机构分发第一红利。

62.根据权利要求61所述的方法，包括：

基于所述第二子组用户的所述虚拟合并帐户中的资金的浮动收益，加所述第三子组用户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第二金融机构分发第二红利。

63.根据权利要求61所述的方法，包括：

从所述第一子组中的第一用户接收向所述第二子组中的第二用户转帐的指示，其中，资金不在所述虚拟合并帐户外部转移。

64.根据权利要求63所述的方法，其中，所述指示是以无线方式通过SMS消息从移动电话发送的。

65.根据权利要求63所述的方法，其中，所述指示是以无线方式使用在所述移动电话上执行的应用程序从移动电话发送的。

66.根据权利要求61所述的方法，其中，所述第三金融机构是所述系统的直接合作伙伴。

67.根据权利要求61所述的方法，其中，每一个用户都只与所述第一、第二或第三金融机构中的一个关联。

68.根据权利要求61所述的方法，包括：

管理虚拟合并帐户的记录系统，其中，所述记录系统包括所述第一、第二以及第三子组中的用户的交易的记录。

69.一种方法，包括：

处理第三子组中的与所述系统关联而不与所述第一和第二金融机构关联的用户的金融交易；

维护包括与所述第一、第二金融机构和所述系统关联的所述第一、第二以及第三子组用户的资金的虚拟合并帐户；以及

70.根据权利要求69所述的方法，包括：

71.根据权利要求69所述的方法，包括：

72.根据权利要求71所述的方法，其中，所述指示是以无线方式通过SMS消息从移动电话发送的。

73.根据权利要求71所述的方法，其中，所述指示是以无线方式使用在所述移动电话上执行的应用程序从移动电话发送的。

74.根据权利要求69所述的方法，其中，每一个用户都只与所述第一金融机构、第二金融机构，或所述系统中的一个关联。

75.根据权利要求69所述的方法，包括：

从所述第一子组中的第一用户接收向所述第三子组中的第二用户转帐的指示，其中，资金不在所述虚拟合并帐户外部转移。

76.根据权利要求71所述的方法，其中，所述指示是通过因特网浏览器发送的。

77.根据权利要求71所述的方法，包括：

78.一种方法，包括：

接收多个商家分担款项以为会员支付系统提供资金；

将所述商家分担款项放入合并信托帐户中，其中，商家对他们的分担款项不收利息；

允许多个消费者免费成为所述会员支付系统的注册的用户；

允许注册的用户免费向所述会员支付系统的往来帐户加载资金或从中卸载资金；以及

允许商家免费向所述会员支付系统的往来帐户加载资金或从其中卸载资金，从而，用合并信托帐户的利息为所述会员支付系统提供资金。

79.根据权利要求78所述的方法，其中，所述会员支付系统允许注册的用户通过移动电话请求向另一个注册的用户付款。

80.根据权利要求78所述的方法，其中，所述会员支付系统允许注册的用户通过移动电话请求向商家付款。

81.根据权利要求78所述的方法，其中，所述会员支付系统管理所述注册的用户的交易记录。

82.根据权利要求78所述的方法，其中，所述会员支付系统管理所述商家的交易记录。

83.根据权利要求78所述的方法，其中，所述会员支付系统管理所述注册的用户和商家的交易记录。

84.根据权利要求78所述的方法，其中，当商家请求归还所述商家对所述会员支付系统的分担款项时，注册的用户将不再被允许向所述商家转帐。

85.根据权利要求78所述的方法，其中，在商家是所述会员支付系统的参与者的情况下，不向所述商家收取定期经常性交易费用。

86.根据权利要求78所述的方法，其中，注册的用户能通过自动票据交换所(ACH)或直接储蓄帐户(DDA)中的至少一个来加载或卸载资金。

87.根据权利要求78所述的方法，包括：

允许注册的用户通过使用两因素授权方案，通过所述会员支付系统授权向商家支付。

88.根据权利要求78所述的方法，包括：

允许注册的用户通过使用所述注册的用户的移动电话和所述用户正确地输入个人标识号，通过所述会员支付系统授权向商家支付。

89.根据权利要求78所述的方法，其中，给每一个注册的用户提供借记卡。

90.基本上如上文所描述的系统。

91.基本上如图所示的系统。

92.基本上如图所示的方法。

93.基本上如上文所描述的方法。