专利名称：移动的个人之间支付系统的制作方法
移动的个人之间支付系统从历史来看，希望进行金融交易以购买商品的帐户持有人都 是依赖诸如货币、支票、信用卡或借记卡之类的各种金融工具。令人 遗憾的是，这些金融工具种类存在某些安全性问题，防欺诈对于支付 行业的盈利率是一个大的考验。当现金丢失或被盗时，通常没有补救 的办法，唯有接受损失。对于其他金融工具，损失不是主要问题，但 是，欺诈会导致支付行业的严重损失。的确，信用卡、借记卡以及支 票欺诈一直是并将继续是该行业的较大的问题。通过语音、电子邮件、SMS文本消息、即时消息以及因特 网处理通信的移动电话设备及其他便携式设备有了爆炸式的增长。人 们常常记住随身携带他们的移动或蜂窝电话，即使他们忘记携带他们 的钱包或汽车钥匙。移动电话在美国以及全世界的许多国家无所不 在。在2005年，据估计，有21.4亿移动电话用户。世界的人口的 大约80%拥有移动电话覆盖。因此，对于允许移动电话发出支付和 接收支付(如现金)，并提供其他金融和移动银行交易的系统的需求 是巨大的。交易处理器3402通过私用网络3404向信用卡交换中心 (进行通信以管理信用卡交易的处理、清算，以及结算的金融实体的 网络)提交交易。信用卡交换中心将交易路由到用户的信用卡发行者 3409那里。发行者基于检测到的帐号识别消费者，并在批准或者拒 绝交易之前确定可用的信用额度。如果批准了交易，则通过信用卡交 换中心将金额转发到商家的银行处理器3405,金额被添加到商家的 银行维护的信用帐户。在一个实施例中，本发明是包括下列步骤的方法在移动电 话的显示器上显示第一屏幕，以显示多个选项，包括向另一方付款的 第一选项和请求余额信息的第二选项；在用户选择第一选项时，显示 第二屏幕，供用户输入向其发出支付的目标电话号码；在用户输入目 标电话号码之后，显示第三屏幕，供用户输入交易金额；在用户输入 电话号码之后，显示第四屏幕，供用户输入PIN代码；以及，在用 户输入PIN代码之后，以无线方式向服务器发送交易信息，包括目 标电话号码、交易金额，以及PIN代码，以便进行处理。在一种实现方式中，该方法包括当在移动电话中接收到要 求付款的请求时，显示第五屏幕，供用户可以输入小费金额。
图1显示了本发明的系统的方框图。36图2显示了本发明的特定实施例的软件体系结构。 [37图3显示了用于实现本发明的实施例的环境。38]图4显示了本发明的实施例，其中，与支付服务一起提供 了增值服务。图15显示了在一个有卡会员和一个无卡会员之间进行交 易的方法。图25显示了本发明的另一个特定实施例的完整的系统图形。图26显示了无卡帐户和无卡帐户之间的个人之间的支付。[61图27显示了无卡帐户和卡帐户之间的个人之间的支付。图29显示了奖励资金。图31显示了 ACH加载。图44显示了支持会员的支付系统中的购物交易。 [79图45显示了使用虚拟合并帐户的系统。 [80图46显示了根据本发明的实施例的购物功能。 [81图47显示了根据本发明的实施例的另一个购物功能。 [82图48是由根据本发明的实施例的至少一个SMS消息机 制执行的金融交易的系统级别的例图。图54， 55和56显示了根据本发明的实施例的用于防止欺 诈和多重重复交易请求的方法。图62显示了根据本发明的实施例的另一个服务电话的成 功的调用。图64是显示了根据本发明的实施例的OMAP通信设计 的状态图。图68显示了根据本发明的实施例的OMAP主菜单的布局。图69显示了根据本发明的实施例的从来源角度来看的 OMAP支付屏幕流程。图70显示了根据本发明的实施例的从目标角度来看的 OMAP支付屏幕流程。图71显示了根据本发明的实施例的从源-请求角度来看的 OMAP请求支付屏幕流程。图75显示了根据本发明的实施例的其中源和目标两者都 拒绝请求的OMAP请求支付屏幕流程。图76显示了根据本发明的实施例的OMAP余额屏幕流程。
109图77显示了根据本发明的实施例的OMAP历史屏幕流程。图78显示了根据本发明的实施例的在源位置的OMAP 设置屏幕流程。图79显示了根据本发明的实施例的未知移动ID的 OMAP的屏幕流程。图98显示了图96的布局如何翻转过来，以便可以存储 在蜂窝电话内。图1显示了本发明的系统的方框图，用于进行价值交换交 易，包括以特定实现方式实现的，移动的个人之间支付和交易，移动 的个人与商家的支付交易，以及移动银行。应用程序服务器107连
接到网络109。虽然只显示了一个应用程序服务器，但是，在本发明 的系统中，可以有任意数量的应用程序服务器。这样的应用程序服务 器可以在单一服务器机器上运行，也可以在许多服务器机器上运行。 随着应用程序服务器上的负载增大，通常，将使用更多的机器来处理 和响应增大的负载。在应用程序服务器上，有一个也可以连接到商家界面的支 付处理器119。金融机构界面123连接到应用程序服务器和支付处 理器。可以有任意数量的金融机构连接到应用程序服务器。应用程序 服务器也可以包括数据库127。或者，数据库可以位于与应用程序服 务器分开的服务器上，应用程序服务器通过网络或其他连接可以访问 它。金融机构也连接到数据库。数据库可以包括应用程序服务器可以 管理的记录系统130和虚拟合并帐户134。金融机构可以管理合并 帐户138。因此，在金融机构中，可以与合并帐户分开地管理记录系 统和虛拟合并帐户。在用户Web应用程序容器中，有针对不同类型的客户端 的接口的表示层。所提供的接口的一些示例包括SMS网关、电话应 用程序网关、万维网服务网关、Web应用程序页面网关，以及Web 应用程序框架网关。电话消息编解码器将诸如SMS或电话之类的传 入的或传出请求或两者转换为系统或客户端特定的消息。本发明的体 系结构可以包括任意数量的这些界面。计算机软件产品可以以各种合适的编程语言中的任何一种 进4亍编写，如C、 C++、 C#、 Pascal、 Fortran、 Perl、 SAS、 SPSS、 JavaScript、 AJAX,以及Java。计算机软件产品可以是带有数据输 入和数据显示模块的独立应用程序。或者，计算机软件产品可以是类， 可以作为分布式对象而实例化。计算机软件产品也可以是诸如Java Beans(来自 Sun Microsystems )或Enterprise Java Beans(来自 SunMicrosystems的EJB)。平台302包括服务器308,用于处理与帐户持有人的交 互，并维护交易记录。服务器308还提供到由商业合作伙伴所提供 的增值服务的链接。服务器308利用交易数据库309，该数据库优 选情况下包括数据存储网络。服务器308使用从交易数据库309获 得的信息(如帐号、余额信息等等)，来管理与商业销售点(POS)终 端311进行通信的支付处理器310。商家可以使用POS终端311 来进行金融交易，如向帐户持有人的借记卡添加资金。商家也可以与 支付服务器302建立单独的链接，以用于结算目的。为说明，销售引擎从参与的商家向帐户持有人提供了赠券 或折扣。此引擎还控制即时赊帐的使用，以奖励注册。商家合作伙伴在另一个实施例中，信用卡帐户被指定为主要帐户，每当 借记卡帐户中的资金下降到或低于某一个选定金额时，现金预付被移 动到预存款借记卡帐户中。
187]在再一个实施例中，金融交易是在个人之间进行的，每一 方都通过电话号码和密码(例如，个人标识号，PIN)来进行标识。 或者，金融交易也可以通过用户名和密码来进行标识。在其他实施例 中，参与交易的至少一方通过条形码来进行标识。条形码可以显示在 诸如移动电话的屏幕之类的显示器上，并由大多数现代的移动设备上 具有的照相机进行检测。条形码可以打印在设备上，也可以以别的方 式附着于移动设备上。对于帐户持有人来说，达成金融交易是无缝的。只需通过 从配备移动客户端应用程序的移动电话向服务器发送一 则消息即可。 支付服务器验证每一个交易，并划拨资金，或响应帐户持有人的对帐 户信息的请求。—旦SMS消息被发送到支付服务器，就可以由帐户持有 人输入PIN，并通过音频信道连接发送到支付服务器，以验证SMS 消息。PIN是通过键盘输入的，可以是任何字母数字代码。然后，PIN 被作为DTMF编码消息发送给支付服务器，其中，DTMF是指双音 多频，是当电话的接触键被按下时电话公司接收到的信号。在一个实施例中，移动设备包括移动客户端应用程序。移 动客户端应用程序要么由帐户持有人直接调用，要么响应移动设备上 的SMS文本消息功能的激活而调用。MCA确定发送PIN的最佳 方法。在又一个备选实施例中，移动客户端应用程序在移动设备 的显示屏幕上提供用户界面(UI)，引导帐户持有人进行金融交易。在 此实施例中，通过自动插入关键字、金额、目标电话号码、密码，以 及消息(如果有的话)，来引导帐户持有人完成构建SMS文本消息 的过程。表B
关键字目标移动电话号码金额消息(可选)
pay##########Abed当使用SMS方法或组合的SMS加语音方法对帐户持 有人作出支付请求时，他们可以使用手动SMS文本消息系统来接受 或者拒绝该请求。在支付服务器端， 一个或多个数据中心将具有用于处理金 融交易的系统。每一个数据中心都将包含PBX/ACD/VRU技术的组 合，以允许多个同时的呼叫处理。可以使用VRU技术来提供可编程 入站和出站DTMF支持。VRU可以连接到表示实际业务逻辑的企 业J2EE系统和记录金融交易的记录系统。然后，J2EE系统可以与 用于进行交易结算的实际银行集成。在一种实现方式中，为SMS安 全性，有一次性的密码选项来作为选项。这是通过让用户发送交易而 没有PIN来工作的，系统将给用户发送一系列问题让他们回答。向另一个帐户持有人或商家汇款既便捷又简单。本系统简 化了批量支付，如从许多帐户持有人为一个慈善活动募捐，或同时从 同 一个帐户持有人进行多个交易。本发明的灵活性可提供在交易中选择和标识各方的新颖的 方法。在一个实施例中，付款人可以通过他们的移动设备的小键盘键 入电话号码或其他标识码。标识码可以是特殊的三、四或五位"短代 码"，由移动服务提供商转换为特定帐户。例如，如果帐户持有人希 望下载由诸如CBS电视网之类的电视网提供的电视节目，帐户持有 人可以键入227的短代码，支付给该网络，以获得所希望的内容。 短代码可以使用任何字母数字字符。此实施例要求，某些方面获取短 代码，以鼓励用户访问他们的服务。相应地，本发明有三种不同的收入来源;漠式。具体来说，(1) 针对参与金融交易的一方或双方，评估"每次交易"。优选情况下，费
用金额从大约一个美分到大约$0.15; (2)包月收费，每个帐户持有人都支付每月的服务费；(3)对于超过选定金额，如，作为说明，$50， 的交易，较高的交易费用，对于所有其他交易，；故弃费用；以及，(4) 增值服务，如链接帐户服务，以自动地记录交易细节或帮助准备提交 税务报表。服务可以获得持有资金的浮动收益或广告收入，这些可以
适用于商家费用(例如，交易费用)。
241图4显示了本发明的系统的另一种实现方式。图4显示 了在两个帐户持有人之间使用增值服务的一个实施例。作为示例，如 果与移动设备401关联的帐户持有人启动一个向移动设备402的 转帐操作，则向服务器平台403传输支付请求，如引用箭头404所 示。支付请求可以包括支付事宜的可选描述。例如，帐户持有人可以 对支付事项进行批注，以表示它是支出帐商品。描述可以从显示在移 动设备401上的菜单中选择。或者，描述可以是与支付请求关联的 语音或文本消息。图5显示了移动的个人之间支付的系统的进一步的实现 方式。如上文所讨论的，本发明的特定实施例允许用户或客户端通过 Web(例如，通过因特网浏览器)、WAP(例如，通过移动电话、智 能电话、个人数字助理设备上的移动因特网浏览器)、SMS(例如， 通过移动电话的文本消息)、IVR(例如，从电话按键理解用户的语 音响应或音调的交互式语音响应系统)、WSDL (例如，可以通过诸 如智能电话之类的移动设备进行访问的万维网服务)与移动支付系统 连接。[249系统可以通过多个运营商中的任何一种，如Verizon、 Cingular (AT&T)、 Sprint、 Nextel、 AUtel、 Virgin Mobile、 Amp，d Mobile、 U.S. Cellular、 T-Mobile及其他运营商与无线电话连接。本 服务也可以与预存款电话连接。移动运营商的一些优点包括基于收 入共享模式的传输或基于预订。促进应用程序下载/购买。促进网络或
数据使用。促进SMS使用。"Offbill，，支付解决方案将帮助减轻惊人 的"big bill"问题。可以有所讨论的任何数量的合作伙伴以及服务，以及任何
的组合。例如，系统可以只有一个合作伙伴、可以具有两个合作伙伴，
三个合作伙伴，或三个以上的合作伙伴。系统可以包括只提供供移动
客户端访问的借记卡(即，无信用卡)的单一银行合作伙伴。系统可
以包括提供供移动客户端访问的借记卡和信用卡的单一银行合作伙
伴。系统可以包括两个或更多银行合作伙伴， 一个提供供移动客户端
访问的借记卡，另一个提供不同的借记卡。系统可以包括两个或更多
银行合作伙伴， 一个提供供移动客户端访问的借记卡，另一个提供不
同的借记卡和信用卡。系统可以包括只提供供移动客户端访问的信用
卡的单一银行合作伙伴。系统可以包括只提供供移动客户端访问的信 用卡的单一银行合作伙伴。在系统的特定实现方式中，让受方合作伙伴具有结算帐户。 银行合作伙伴具有合并帐户和往来帐户。直接合作伙伴具有合并帐户 和往来帐户。预存款处理合作伙伴具有合并帐户和往来帐户。ACH合 作伙伴具有结算帐户。移动支付系统可以提供合并帐户管理、跨银行 结算和资金管理，以及移动银行集成中的一个或多个。系统的资金通过所有合作银行的合并帐户的总和来表示。 通过与移动支付系统的商务关系，移动支付系统促进了定期资金管理 处理过程，以便合作银行的合并帐户保留的余额代表他们对移动支付 系统客户群体的贡献加上"其他"移动支付系统资金的同意的百分比。 客户的获取"路径"规定了给定合作银行的合并帐户余额(即，合作银 行通过"他们的"路径获得的客户越多，他们的关联的合并帐户的余额 就越高)。对于验证状态，用户的身份是已知的。用户提供地址或其 他相关的联系信息。用户在验证状态下可以收到、请求、添加(即， 加载)或提取(即，卸载)资金。对于高级状态，用户已经提供了用户的社会保障号码。在 此状态下，例如，用户可以向特定银行合作伙伴进行注册，以接收卡。 此卡可以是预存款的借记卡。在其他实施例中，卡可以是信用卡。用 户将能够做验证用户所能够做的一切，外加能够立刻在接受卡的任何 地方进行消费。可以通过一个或多个网络，包括Visa、 MasterCard、 American Express、 NYCE、 PLUS或STAR,或这些4几构的任4可组 合，接受或使用卡。卡链接到用户的帐户。没有卡的用户可以叫做无 卡用户，而有卡的用户可以叫做有卡用户。当进行注册时一个人可以获得验证的一些方式包括对于 人的信息，系统可以要求提供地址和驾驶执照号码。 一种备选方案是 要求提供地址和社会保障号码。可以对照诸如Equifax数据库之类 的信用报告机构的数据库，核对该信息。对于链接的银行帐户，可以 使用质询储蓄来对这些进行验证。例如，系统可以将任意数量的小额 存款放入用户的帐户中。用户告诉系统，那些存款的金额，以获得验 证。或者，用户能通过在线即时帐户验证来进行验证，其中，用户提 供在线的屏幕姓名和密码。对于添加信用卡或借记卡，也可以使用质 询储蓄来对这些进行验证。诸如Visa和MasterCard之类的一些卡 也可以使用安全代码等等来进行验证。
269]参与的速度是对帐户设置某些限制的一种设置。对帐户设置的限制的一些示例有用户一天可以进行多少次交易，或在一次交 易中最多可以转帐多少金额。可以有一些硬性限制和软性的限制。硬 性限制将不会随第三方的千涉(如人更改限制)而变化。软性的限制 可以随着用户的操作而变化。例如，在用户已经成为会员六个月之后， 当用户的对于一些号码的前一限制少于五时时，可以自动地允许用户 一天可以进行五次交易。系统流程[275图6显示了在同业银行的个人之间的支付。此图显示了一 个消费者A向另一个消费者B汇款，其中，这两个消费者都是同 一个银行合作伙伴A的会员。本发明的移动支付系统将处理该交易。
276交易的基本流程是(1)消费者A向移动支付系统发送 支付请求。此支付请求可以通过此专利中所讨论的任何一种方式来提 供。(2)移动支付系统更新移动支付系统的记录系统(SOR)中的T 或交易记录中，以反映交易。这些交易记录是由移动支付系统进行管 理的。(3)系统(例如，Obopay)将支付情况通知给消费者B。这可 以通过电子通知、电子邮件、即时消息、SMS消息，或其他通知来 进行。(3)在现有会员选择向非会员汇款的情况下，支付系统必须 通过各种常见的通信机制(如电子邮件、语音，及其他)通知非会员， 已经向他们汇了款。下面是在支付系统内进行病毒式资金转帐的技术的多个实施例。5.向B的汇款金额从A的帐户中划出，并被保留，等待 B的注册。7.用户B在系统网站(例如，obopay.com)进行注册。8.在用户B成功地进行注册之后，B的帐户自动地4皮注 入了 A的转帐资金。
305实施例1B 1.现有会员用户A决定通过给B汇款来邀请非会员用户 B加入，B必须通过注册为会员才能接收款项。6.用户B接收到一则消息，说明A已经邀请B加入系 统，以<更A可以给B汇款。9.用户A接收到"Request Pay",并同意该支付个人预留资金病毒式一 允许现有的会员留出资金，这是为 "病毒式，，支付预留的。例如，用户可以拨出用户的帐户中的一定数量 的美元，以进行"病毒式"交易。这些资金将不会可用于"非病毒式"交 易(例如，通过借记卡进行花费)。在一种实现方式中，用户能通过 用户帐户维护功能更改预留的金额。实施例3会话病毒式 一 实时地出现完整的病毒生命周期，将沿途 的其他"步骤，，通知给双方。然后，最终的资金转帐只是两个会员之间 的转帐。如果在由系统设置的一定天数(如三十天)之后用户B还 没有批准交易，则系统可以自动地取消交易。然后，系统可以向用户 A和用户B两者发送电子通知，通知两者，交易已取消。用户B也 可以具有拒绝交易的选项，在这样的情况下，可以通过电子通知，通 知用户A，拒绝支付。图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可以是异步的服务器端线程。在步骤9中，只有在用户B向系统进行注册之后，才给 用户B发送有关用户A请求发出支付的消息。在本发明的另一个 实施例中，用户B可以接收有关用户A的支付的消息，无需向系 统进行注册。在步骤14中，给用户A发送一个类似于收据的SMS通 知，通知他交易已经完成。在另一个实施例中，可以给用户A发送 其他形式的通知，如通过电子邮件、即时消息、MMS消息，或其他 形式的移动通信。系统也可以给用户B发送一个交易已经完成的通 知。系统也可以不给用户A或B发送有关交易完成的任何消息。在步骤15中，进行货币交易。在一种实现方式中，划入 和划出交易不实时进行。由于电子资金系统中的固有延时，交易可能 在处理开始之后大约六十秒或更多才能完成。流程A中的任意数量的步骤，以任何組合，都可以与任何 其他移动支付系统流程相结合，包括本申请中所讨论的其他流程。， [value，[trans #j，， B不会接收到消息。 如果有足够的资金，则进入下一步骤。
4检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有 被识别为注册的用户，则A接收到下列消息 "您的支付待办。未注册用户必须开立帐户。 [tel #1，value，[trans #，，
5B接收到下列消息 "您收到一笔款！tel #1，valuej， [trans #1 请去系统网站注册。，，
6起始从A的个人帐户划出资金交易，并划入未注册用户合并帐户中的 B。
如果划出和划入交易失败，则给A和B发送消息 "支付失败。 [tel #，[value], [trans #，， 否则，划出和划入交易会成功。没有发送消息。
8如果在A启动交易之后已经过去30天以上而B还没有注册，则交易 自动取消。然后，将给A和B发送消息 "支付已取消。 [tel #，value，[trans #]，， 上面的步骤6中请求的划出和划入交易颠倒。将从未注册用户合并帐户 获取的交易金额划入A的个人帐户。
9B在系统网站进行了注册，并成为已注册的无卡用户。资金从未注册用户 合并帐户转帐到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的帐户中成功地划出交 易金额。在步骤10中，通常需要花费大约7到10个工作日，作 出新的卡，用户B通过邮寄收到它。在本发明的另一个实施例中， 用户B可以收到另一种卡，如信用卡，也可以选择根本不接收卡。在步骤11中，在用户B激活他的卡时，用户B成为有 卡注册的用户，不再是无卡用户。在不使用无卡合并帐户的实施例中， 在卡被激活时，不需要划拨余额。， [value!, [trans #]，， B不会接收到消息。 如果有足够的资金，则进入下一步骤。
4检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是 注册的用户，发送下列消息 "您收到一笔款！ [tel #]， [value], [trans #]"
5检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用 户，开始从无卡用户合并帐户中的A划出交易资金并划入B的个 人帐户。
6如果划出和划入交易失败，则给A和B发送消息 "支付失败。 ftel #1, [valuel，trans #1"
7如果B打开了自动接受，则资金从无卡合并帐户中的A转帐到B 的个人帐户。没有发送消息。
8如果B关闭了自动接受，则划出和划入交易只有在B批准交易之 后才进行。
9如果在A启动交易之后已经过去30天以上而B还没有批准，则 交易自动取消。然后，将给A和B发送消息 "支付已取消。 [tel #，[value，[trans #，， 如果B拒绝接收支付，则交易取消，给A发送一则消息 "支付已被拒绝。tel #1， [value，trans #1"
10如果B接受交易，而A仍是无卡用户，则资金从无卡合并帐户中 的A转帐到B的个人帐户。
如果B接受交易，而A现在是有卡用户，则资金从A个人帐户转 帐到B的个人帐户。[390上面所提供的备注也相应地适用于流程E。 [391]下面的流程F显示了在有卡用户(用户A)和无卡用户(用 户B)之间进行交易的一种实现方式。步骤操作
1现有的用户A(有卡注册的用户)决定给用户B(无卡用户)汇一些款。 A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。
2移动支付系统检查A的帐户是否具有足够的资金来完成交易。
3如果资金不足，则给A发送一则消息 "资金不足。 [tel #，[value], [trans #，， B不会接收到消息。 如果有足够的资金，则进入下一步骤。
4检查B是注册的(无卡或有卡)用户还是未注册用户。如果B是注册 的用户，则发送下列消息 "您收到一笔款！ [tel #1，value，trans #，，
5检查B是无卡注册的用户还是有卡注册的用户。如果B是无卡用户， 则开始从A的个人帐户中划出交易资金并划入无卡用户合并帐户中的 B。
6如果划出和划入交易失败，则给A和B发送消息 "支付失败。 [tel弁l，〖valuel，trans #1"
7如果B打开了自动接受，则资金从A的帐户转帐到B的无卡合并帐 户。没有发送消息。
8如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才 进行。
9如果在A启动交易之后已经过去30天以上而B还没有批准，则交易 自动取消。然后，将给A和B发送消息 "支付已取消。 [tel #1， [value], [trans #，， 如果B拒绝接收支付，则交易取消，给A发送一则消息 "支付已被拒绝。 [tel #1， [valuel， ftrans #1"
10如果B接受交易，并且B仍是无卡用户，则资金从A的帐户转帐到B 的无卡合并帐户。如果B接受交易，并且B现在是有卡注册的用户，则 资金从A的帐户转帐到B的个人帐户。
80[393上面所提供的备注也相应地适用于流程F。 [394下面的流程G显示了在有卡用户(用户A)和有卡用户 (用户B)之间进行交易的一种实现方式。[395流程G
步骤操作
1现有的用户A (有卡注册的用户)决定给用户B (有卡注册的用户)汇 一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易 金额。
2移动支付系统检查A的帐户是否具有足够的资金来完成交易。
3如果资金不足，则给A发送一则消息 "资金不足。 [tel #，value，[trans司" B不会接收到消息。 如果有足够的资金，则进入下一步骤。
4检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册 的用户，发送下列消息 "您收到一笔款！ 〖tel #，[value，ftrans #1"
5检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用户， 开始从A的个人帐户划出交易资金并划入B的个人帐户。
6如果划出和划入交易失败，则给A和B发送消息 "支付失败。 ftel #1， [value],t醒s #1"
7如果B打开了自动接受，则资金从A的帐户自动地转帐到B的无卡合 并帐户。没有发送消息。
8如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才 进行。
9如果在A启动交易之后已经过去30天以上而B还没有批准，则交易 自动取消。然后，将给A和B发送消息 "支付已取消。 [tel #，[value]， [trans #]，， 如果B拒绝接收支付，则交易取消，给A发送一则消息 "支^H皮拒纟色，[tel #]， [valuej， [trans
10如果B接受交易，则资金从A的个人帐户转帐到B的个人帐户。， [value，[trans #1" B不会接收到消息。
如果有足够的资金，则进入下一步骤。
4检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有 被识别为注册的用户，贝'j A接收到下列消息 "B不是会员。我们已经邀请B加入系统。 [tel #，[value], [trans #1" 不会从A的帐户中扣除资金。
5B接收到下列消息 "A尝试给您汇款。 [tel #1， [value], [trans #J 请去系统网站注册。"
6B向系统网站进行了注册，并成为已注册的无卡用户。
7A还接收到下列消息 "B现在是注册的用户，您愿意再次提交您的交易吗？"
8A在他的帐户中收到引荐奖金(例如，$5)。
9A利用B的移动电话号码向移动支付系统重新发送一则消息和交易金 额。如果是，则交易将作为注册的用户与注册的用户的交易来进行处理。上面所提供的备注也相应地适用于流程H。在此流程中， 在B进行注册之后资金不会自动地从A转帐到B。相反地，B被
83邀请加入，在B加入时，给A发送一则消息(步骤9)，询问A是 否希望再次尝试向B汇款。如果A希望汇款，那么，后续的A与 B之间的处理与任何一个注册的用户到注册的用户之间转帐类似。在一种实现方式中，第二帐户位于合并帐户中，并且当所
述第一用户是无卡已注册的用户时，所述第 一帐户位于所述合并帐户
中，以及所述划出和划入过程包括在所述合并帐户内维护所述金额。
在一种实现方式中，第二帐户位于合并帐户中，并且当所述第一用户
是无卡已注册的用户时，所述第一帐户位于所述合并帐户中，以及所
述划出和划入过程包括不在所述合并帐户外部转移所述金额。在一种
实现方式中，当所述第一用户是无卡已注册的用户时，所述第一帐户
位于第一合并帐户中，第二帐户位于不同于所述第一合并帐户的第二
合并帐户中，以及所述划出和划入过程包括从所述第一合并帐户向所 述第二合并帐户转移所述金额。在一种实现方式中，在收到序列号之后，生成预期的序列 号。然后，只有在所述序列号匹配所述预期的序列号的情况下才处理 所述付款指示。在一种实现方式中，该方法包括当所述第二用户选择所 述第三选项时，向所述第一用户发送第三电子消息，说明所述第二用 户请求对所述待付款进行更改。在一种实现方式中，该方法包括当 所述第二用户选择所述第三选项时，接收来自所述第二用户将待付款 更改为不同的金额的请求，向所述第一用户发送第三电子消息，通知所述第 一用户对所述待办支付款项进行更改，给所述第 一用户呈现接 受所述对所述待付款的更改的第四选项或拒绝对所述待付款的更改 的第五选项，以及当所述第一用户选择所述第四选项时，从所述第 一用户的帐户中划出所述所述不同的金额并向与所述第二用户关联 的帐户划入所述不同的金额。该方法还可以进一步包括在确定所述第二用户不是已注 册的用户之后，在所述第一帐户中预留出所述金额。该方法可以包括 在确定所述第二用户不是已注册的用户之后，在所述第一帐户中预留 出所述金额；以及，在从接收到付款指示而所述第二用户仍没有注册 时起一定天数过去之后，取消所述第一帐户中的所述金额的预留。图19显示了本发明的特定实施例的完整的系统图形。这 是移动支付系统(即，Obopay)的特定实现方式的示意图。如前所述， Obopay只作为示例，用于说明本发明的功能，本发明不应该仅限于 此示例。Obopay的系统具有借记卡主干网。Diamond Financial Products是合作伙伴。通过Diamond, Obopay发放借记卡并与 ECL和First Premiere Bank进行通信，以给予Obopay用户在借 记卡之间转帐和接收资金的能力。PBT( Pay By Touch )处理ACH交 易和信用卡交易。Bancorp Bank提供结算帐户，并与PBT有关系。具体流程包括(1) Ul从电话中启动向"无卡"用户Ol 的$5的P2P交易。(2)金额$5.00被从Ul的借记卡帐户转帐到 位于First Premier的Obopay In & Out银行帐户。(3) $0.10的费 用4皮转巾艮(通过Diamond)到位于First Premier Bank的Diamond Financial Products #4亍中艮户。(4) Obopay在Obopay总帐上记录 Ol的余额增多$5。
付。具体流程包括(l)Ol从电话中启动向"无卡，，用户02的$10 的P2P交易。(2)$10仍保留在位于FirstPremier的Obopay In & Out帐户中。$0.10的费用也停留在In & Out帐户中。(3) Obopay 在Obopay总帐中记录了 02的余额增多，Ol的余额缩小。闭环支付方案在一个实施例中，本发明提供了用于操作作为闭环支付系 统的支付转帐基础架构的方法。闭环金融交易系统便于进行支付，没 有与闭环金融系统关联的大量的付款手续费，并且对于参与金融交易 的持有人、商家及其他各方来说，具有高度的安全性。闭环支付系统有多个优点。主要优点是，系统的所有者能 够控制向汇款人和收款人收取的费用，对于加载到系统中的资金，有 賺取利息的机会。支付系统所有者能够賺取系统中的所有资金的利 息，直到它们被转换回美元或卸栽回美元。随着更多功能被添加，由 于费用和余额的增多，闭环系统会变得更有利可图。(3)信息一易于获取帐户活动和余额信息；商家合作伙伴具有极难得的机会賺取处理针对将资金存放 到预存款货记帐户中的交易或用于向帐户持有人提供现金的交易的 收入。当资金被添加到帐户中时，商家可以賺取佣金。闭环系统维护了用户资料数据库，包括帐户持有人的姓名 和人口统计数据，每一个特定帐户持有人的用于对风险进行签名的信 息，以及将用于向帐户中加载或从帐户中卸载资金的帐户的链接的银 行帐户信息。用户资料数据库也需要面向消费者和面向顾客服务的网 站，用于当开立时收集注册数据。现在请参看图36，该图显示了根据本发明的实施例的闭环 金融交易系统。在此交易系统中，消费者和商家， 一组两个或更多消 费者，或者一組两个或更多商家可以快速地，安全地完成金融交易， 交易费用很少或没有。
459此闭环金融交易系统利用预存款货记帐户，因此，可以包 括销售点(POS)终端3612,其中，可以如在现有技术系统中那样使 用传统的借记卡3606 —通过在与POS终端3612关联的i兹性读 取器3613中刷卡。卡3606提供了查看帐户持有人的帐户的第二途 径。在某些实施例中，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通常与商家关联。除消费者与商家之间的交易之外，本发明足够灵活，可以 实现真正的个人之间的金融交易功能。个人之间的设备3620各自都 包括链接到帐户和帐户持有人的手机。当对等伙伴3620中的一个希 望启动交易请求，以便向另一个对等伙伴进行支付时，交易的请求、 授权和确认都是通过公共网络在支付服务器3630和对等伙伴3620 之间发送的。优选情况下，由于使用了一个或多个公共网络，没有了 交换中心的费用，如此，对于参与者来说，成本可以免费的，或者相 当便宜，以至于它占在系统上进行的总体交易的百分比可忽略，特别 是与典型的交易费用相比时。图39显示了如图36所示的闭环支付系统中的交易流 程。具体来说，对于个人之间的交易，当从移动设备3901向另一个 移动设备3901进行支付时，向支付服务器3903传输转帐请求。请 求通过引用箭头3904来表示。服务器3903访问与移动设备3901 关联的帐户持有人的T-总帐(如引用箭头3905所示)，如果满足 了如3906处所示的某些速度规则，则将指定的金额转帐到收款人 T-总帐(如引用箭头3907所示)。 一旦资金已经转帐到收款人，如 3908所示，服务器3903就向收款人发送一则通知消息，如3卯9所 显示的。最后，付款人帐户持有人从服务器3卯3接收到确认消息， 说明交易已经完成。在一个实施例中，整个闭环系统由单一实体所拥 有。系统由帐户持有人装填或加栽，帐户持有人由于在支付服务器上 维护的帐户余额，而获得美元(参见图36)。6.MSPS信托帐户产生浮动红利，该红利为MSPS处理公 司和系统提供补偿。9.MSPS系统为消费者和商家管理了"T"帐户(即，余额、 划出、划入)。在一个实施例中，本发明是包括下列步骤的方法接收多 个商家分担款项以为会员支付系统提供资金；将商家分担款项放入合 并信托帐户中，其中，商家对他们的分担款项不收利息；允许多个消 费者免费成为移动支付系统的注册的用户；允许注册的用户免费向会 员支付系统的往来帐户加载资金或从中卸载资金；以及，允许商家免 费向会员支付系统的往来帐户加载资金或从其中卸载资金，从而，用 合并信托帐户的利息为会员支付系统提供资金。—般而言，在商家是会员支付系统的参与者的情况下，不 向该商家收取定期经常性交易费用。系统是由包含商家分担款项的合 并信托帐户的浮动收益资助的。
515注册的用户能通过自动票据交换所(ACH)或直接储蓄帐 户(DDA)中的至少一个来加载或卸载资金。在系统的进一步的实现 方式中，可以给注册的用户和商家提供很多额外的加载和卸载资金的 方式。例如，注册的用户可以选择让用户的工资支票或工资支票的一 部分直接存放到系统中。(1)由合作银行获取的帐户将被认为是来自该银行。例如， 如果银行Ci销售移动支付系统服务，并吸收客户A，那么，客户A 在他的一生中都被标记为"由Ci吸收"。为每一个用户记录(在本 申请中别处进行了讨论)，可以有一个字段，指出该特定用户是从哪 一个来源招收的。可能的来源的某些示例包括直接的移动支付服务、 合作银行、合作金融机构，以及合作移动电话提供商。在每天结束时，移动支付系统服务将估计保留在移动支付 系统服务帐户中的被标记为由每一个合作银行吸收的资金的金额。让 我们将此估计金额叫做X-Ci、 X-BA、 X-ING，其中，Ci、 BA和ING 是金融机构或银行的示例。在一个实施例中，本发明是包括下列步骤的方法处理系 统的一组用户的金融交易，其中，金融交易可以通过移动电话指定， 用户的子组与金融机构关联；
处理与第一金融机构关联的金融交易，其中，第一子组中的用户 与第一金融机构关联；处理与第二金融机构关联的金融交易，其中， 第二子组中的用户与所述第二金融机构关联；处理第三子组中的与所 述系统关联而不与所述第一和第二金融机构关联的用户的金融交易； 维护包括与所述第一、第二金融机构和所述系统关联的所述第一、第 二以及第三子组用户的资金的虚拟合并帐户；以及，基于所述第一子 组用户的所述虚拟合并帐户中的资金的浮动收益，加所迷第三子组用 户的所述虚拟合并帐户中的资金的浮动收益的百分比，向所述第一金 融机构分发第一红利。图46显示了根据本发明的实施例的快速购物的方法。在 一个实施例中，招贴画、报纸广告、或电视广告包括允许购物者获取 显示在手机上的有关产品的具体细节的机制。此机制可以包括打印的 条形码或拨入即可获取信息的电话号码。在另一个实施例中，利用近 场通信来启动购物者和远程商家之间的连接，如4601所示。通过启 动该连接，会激活MCA，以便如果购物者决定进行购物，则MCA被 唤醒，并已经建立连接，如4602所示。通过选定Buy Request选 项，如4603所示，购物者可以与支付服务器进行购物交易，处理诸 如"发货给，，地址和资金转帐之类的细节。在较短时间内，可以从几分 钟到几天，订购的产品将被发出，如4604所示。如果预先授权的帐户已用完，而帐户持有人没有及时地补 充该帐户，则电话号码可以放在"红名单"中，并禁止未来使用该服务。 红名单也可以由商家本地存储在POS中，或存储在连接到POS设 备的本地服务器中。如果电话号码包括在红名单中，则商家可以接受 替代的支付形式。或者，服务器可以拒绝服务，并发送一则消息，建 议帐户持有人借此机会对帐户持有人的帐户进行再充值。商家可以接 受再充值支付，并收取收到对帐户持有人的帐户进行再充值的资金的 奖励费用。如果收款人4808是帐户持有人，但是手机不支持在手机 上下栽和执行移动客户端应用程序，那么，来自服务器4804的消息 将是明语。使用明语SMS消息传输PIN的不利的一面是，此秘密 的号码将对可以接触电话的任何人可见。这可能导致非帐户持有人的 未经授权的使用，除非帐户持有人花点时间从他们的手机的邮箱中删 除SMS消息。如果收款人4808不是帐户持有人，那么，SMS消 息也将是明语消息。要4吏用SMS方法向他人或商家进行支付，帐户持有人可 以输入表C所显示的命令字符串。在服务器端， 一个或多个数据中心将具有用于处理金融交 易的系统。每一个数据中心都将包含PBX/ACD/VRU技术的组合， 以允许多个同时的呼叫处理。可以使用VRU技术来提供可编程入站 和出站DTMF支持。VRU可以连接到表示实际业务逻辑的企业 J2EE系统和记录金融交易的记录系统。然后，J2EE系统可以与用 于进行交易结算的实际银行集成。
575优选情况下，移动客户端应用程序确定用于发送PIN的首 选的或最佳的方法，如通过应用程序SMS(数据服务)，其中，SMS 消息是经过加密的，并被转换为二进制(即，消息不以明语进行传输)， 或者，通过音频信道使用DTMF来维护安全性。在其他实施例中， PIN可以由帐户持有人说出，并由在服务器或专用于处理语音电话的 另 一个服务器(未显示)上工作的交互式语音识别软件模块进行转换。
576在一个备选实施例中，PIN由移动客户端应用程序进行加 密，并包括在发送给服务器4804的后续的SMS消息中。服务器4804通过将电话号码和每一则消息的发送时间匹配来使消息关联。 如果PIN是在与SMS消息相比在时间上较远的消息中发送的，则 可以拒绝交易。如果只接收了两个消息中的一个，则可以拒绝交易。 然而，如果及时地接收并验证了带有金融交易细节的SMS消息(至 少有关键字)和PIN代码，那么，进行金融交易。在又一个备选实施例中，移动客户端应用程序在移动设备 的显示屏幕上提供用户界面(UI)，引导帐户持有人进行金融交易。在 此实施例中，通过自动插入关键字、金额、目标电话号码、密码，以 及消息(如果有的话)，来引导帐户持有人完成构建SMS文本消息 的过程。图49显示了根据本发明的实施例的用于保护基于SMS 的金融交易的方法。更具体地说，对于诸如GSM手机之类的移动设 备，在手机上安装MCA涉及以物理方式插入小型电路板，被称为加 密和交易号生成器，或简称为生成器4902,以截取SMS消息通信。—旦进行了注册，新帐户持有人具有"无卡，，受限制的帐户， 如5103所示。在此阶段(阶段I),新帐户持有人能够实时地查看他们的预存款货记帐户中的资金。然而，由于银行规则，新帐户持有
人的帐户的对资金的访问权限是受限制的，直到完成OFAC报告， 如5104所示。"OFAC"是指美国财政部的外国资产控制局，该局根 据美国外交政策和国家安全目标，针对指定的外国、恐怖分子、未经 批准的国际毒品走私犯，以及那些参与与未经批准的大规模杀伤性武 器的扩散相关的活动的人，进行管理和实施经济和贸易制裁。—旦OFAC适应性检查完成(该过程通常大约要花24小 时)，并没有发现不利的链接，帐户持有人会变为"无卡"帐户，这意 味着，金融机构可以开立预存款借记卡账户，并将塑料借记卡发送给 新帐户持有人，如5105所示。然而，在此阶段(阶段II)，新的无 卡帐户持有人对资金只有有限的支配权。例如，新帐户持有人可以使 用本发明的金融交易系统将资金转帐到其他个人，但是由于额外的政 府限制，资金不能被提取或转帐到一个商家。帐户持有人也可以指定每一次交易的最高金额，以及在选 定时间段内在手机上可以处理的交易的数量。帐户持有人也可以指定 要存放和保留在预存款货记帐户中的资金的最高金额。交易处理器 3630每天将多余的款转移到另一个指定的帐户，如个人储蓄帐户。在一个实施例中，使用近场通信来在移动设备之间进行通 信以使用本发明的基础架构进行金融交易。在再一个实施例中，使用 近场通信在移动设备与POS终端之间进行通信，以进行金融交易。如果使用SMS消息来完成交易，则授权PIN优选情况下 是朗读到移动设备中并传输到支付服务器的口头代码，以便使用语音 识别软件进行验证。通过使用PIN代码激活移动客户端应用程序，来提供更大 的安全性。在此实施例中，PIN代码出现在第一个实例中，打开移动 客户端应用程序，并启动其操作。同一个PIN代码，或者，优选情 况下， 一个单独的PIN代码用于通过网络对交易进行授权。这种双PIN代码处理对信用卡、支票或者智能卡不可用。在5510，用户(即，帐户持有人)在移动电话设备(例如， 移动电话)上启动金融交易。在5511，用户在启动交易时传输PIN (选项A)。或者，如在5512所显示的，用户在启动交易时不传输 PIN (选项B )。—旦验证了呼叫方ID，则服务器对照系统中记录的PIN 检查从移动设备传输的PIN，以验证PIN是否匹配预期的电话号 码，如5517处所显示的。当且仅当PIN匹配时，服务器才允许进行交易。如果PIN不匹配，则禁止交易，如5518处所显示的。然后，服务器从移动设备接收金融交易的交易号(也简称 为序列号)。交易号可以在启动交易时发送，或以后作为移动设备和 服务器之间的信息传输的一部分发送。交易号包括使其唯一的幂等性 密钥。上面的验证方法按特定的顺序呈现一些验证步骤。本发明 的一种实现方式按给定顺序执行这些步骤。然而，在本发明的其他实 现方式中，可以有其他步骤，或者也可以省略一些步骤，或者步骤的 顺序可以不同于上面的顺序。例如，呼叫方ID、 PIN，以及交易可以 不按顺序。因此，在一个实施例中，可以在呼叫方ID之前检查PIN。 在另一个实施例中，可以在PIN之前检查交易号。此外，上面的一 些步骤还可以以并行处理的实现方式在不同的处理器或处理器核心 中同时执行。在一种实现方式中，本发明的系统可以省略上面所列的一 个或多个验证技术。例如，可以不鉴定呼叫方ID，如此，将4吏用两 因素验证方法。(3)在服务器上，从移动设备接收启动金融交易的请求。 [649](4)在服务器上，检查由移动设备传输的呼叫者标识(呼叫 方ID)，看看移动设备是否是系统的被授权的用户。如果在电话上 没有启用呼叫方ID，则禁止交易。可以显示一个错误消息，以指出 交易^皮禁止，因为呼叫方ID未启用。用户可以在启用呼叫方ID之 后重试请求。(8a)(选项C)对照服务器中存储的序列号，检查来自移 动设备的序列号。如果序列号不匹配，则用户没有通过鉴定，交易将 被禁止0(8b)(选项D)对照存储在服务器中的以前所使用的序列 号的列表或数据库，检查来自移动设备的当前序列号。如果当前序列 号匹配以前使用的序列号中的任何一个，则用户没有通过鉴定，交易 将被禁止。(1)在服务初始化时，使用存储在移动设备和服务器上的初 始交易号值。初始交易号可以是(la)或(lb)。例如，当<吏用即时消息程序(例如，AOL Instant Messenger (AIM)、 ICQ、 Yahoo! Messenger、 Microsoft Windows Live Messenger、 Google Talk或Skype)时，将会有一个向另一个用户进行支付的选 项。进行支付的选项可以通过右键单击鼠标或通过下拉式或层叠式菜 单进行访问。接收者可以通过用户名、会员名、电话号码、会员号、 帐号，或另一个标识符来进行标识。支付将通过移动支付服务服务器 进行处理。在本发明的特定实现方式中，当使用胖客户端时，存储的 序列号将永久地存储在胖客户端中的计数器中。此存储的序列号可以 遵循任何任意序列，如连续的整数或二进制计数器(例如，1、 2、 3、 4，等等)，基于已知起始种子值的随机序列，或根据等式、公式或 规则的序列。存储的序列号可以存储在，例如，快闪存储器、电可擦 除的(E")存储器、非易失性存储器、带蓄电池后备电源的存储器、 硬盘驱动器，或其他存储器中。在特定实现方式中，可以用潜在的违反安全记号来标记用 户的帐户，以供人研究。如果用户具有许多这样的违规或在特定时间 段内具有许多这样的违规，那么，可以自动地暂停该帐户，以便进行 调查。当使用不同类型的客户端或程序时，可以以不同的方式生 成或获得传输的密钥，如通过不同的函数。例如，密钥可以包括不同 的信息。当用户设备使用第一应用程序客户端发送电子请求时，密钥 可以包括第一信息，当用户设备使用不同于第一应用程序客户端的第 二应用程序客户端发送电子请求时，传输密钥可以包括第二信息。第 一信息的示例可以是包括永久地存储的序列号的密钥。第二信息的示 例可以是包括时间或时间戳的密钥。在 一 个实施例中，本发明包括接收从用户设备以无线方式 传输的价值交换交易的电子请求；接收与电子请求关联的传输的密 钥；生成预期的密钥；将传输的密钥与预期的密钥进行比较；以及， 如果传输的密钥匹配预期的密钥，则处理价值交换交易。价值交换交 易可以是从与用户设备关联的第 一用户向与另 一个用户设备关联的 第二用户汇款，其中，用户设备是移动电话。生成预期的密钥的过程可以包括使用为与价值交换交易关 联的用户帐户存储的种子值对一个函数或方程进行求值。此外，用户 帐户也可以存储有关用来生成预期的密钥的特定函数或方程的信息。 例如， 一些用户可以使用一个特定函数来生成密钥，而其他用户使用 其他函数。对于不同的用户，使用不同的起始种子，在每一次使用之 后，将创建新的种子，用于生成下一个密钥。换句话说，该方法进一 步包括在对函数进行求值之后，确定序列中的下一个种子值，并用序 列中的下一个种子值替换为用户帐户存储的种子值。在示例情况下，用户具有配备有近场通信功能的移动设备。 用户可以查看他希望购买的产品。用户将用户的移动设备放在与产品 关联的近场通信设备的附近。然后，移动设备的显示器查询用户是否 同意交易，以购买产品。如果用户批准，则处理交易。用户将接收商 品，如从交货地点领取，或者商品可以投递到用户的邮件地址处。可 以提示用户输入PIN或质询问题，以验证他们已经批准交易。(1)打开帐户持有人的移动设备上的MCA。这将把帐户持 有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按"输入，， 继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单， 包括支付、余额、历史、请求支付、引荐或邀请、添加资金(即，加 载)，设置，和帮助。(3)要选择帐户持有人的电话簿中的电话号码，帐户持有人 将选择选项(从移动设备上的左下方的软键)，然后查找(从选项菜 单)，将显示出帐户持有人的现有电话地址簿，并允许他们选择其中 的一个姓名。可选地，帐户持有人可以直接从小键盘输入电话号码。 在另 一 个实施例中，帐户持有人输入短代码来标识所需的商家收款 人。 一旦帐户持有人输入了移动电话号码，他们将选择"确定"。支付到(目标电话号码)任何相关交易费用消息(如果他们留了的话)消息如果目标收款人还没有现有帐户，则收款人将接收到文本 消息，说"您收到一笔款！，，，并指示他们到诸如www.obopay.com之 类的网站，进行注册，成为帐户持有人，并接收他们的资金。在本文 档中稍后详细描述了新帐户持有人的注册过程。将首先处理支付，收款人将接收到支付通知。如果交易没 有问题，则帐户持有人将不会接收到任何进一步的通知。如果支付确 实出现问题的话(即，资金不足)，则将会通知帐户持有人和目标收 款人。有关支付所发生的任何问题的通知将在进行支付之后迅速地发 出，以便各方都可以确认交易。日期MM/DD/YYYY HH:MM(1)打开帐户持有人的移动设备上的MCA。这将把帐户持
有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按Enter
键继续。交易日期和交易金额MM/DD (+/-)$.$$
7671帐户持有人将能够选择列出的交易中的任何一 个，以获得 有关该特定交易的详细信息。为此，他们滚动浏览到他们希望查看的 具体交易，并选定它。这将把他们带到具有下列信息的屏幕然后，帐户持有人选定"确定，，回到历史屏幕。从这里，他 们可以查看另一个交易或返回到主菜单画面。金额任何相关交易费用消息(如果他们留了的话) —旦帐户持有人选择了 "确定"，则他们将被带到具有下列 信息的屏幕帐户持有人将能够从MCA查看"帮助"屏幕。这将包括应 用程序的简要的描述，以及有关帐户持有人到哪里获得更多帮助的说 明。要查看MCA的"帮助，，部分，帐户持有人将经过下列步骤。打开 帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕， 显示徽标和标记行。帐户持有人将必须按Enter键继续。请求支付，显示，例如成本？如杲您忘记了，请拨打888-80BOPAY [857链接到"技术支持"的帮助页面下面显示了来自移动设备的服务请求和示例有线表示。 [868]由移动设备启动的服务请求是Paymentservice.payP2P调 用。此函数执行帐户持有人与帐户持有人之间的支付，Java方法签 名是请求部分与前一示例完全相同，虽，响应现在表示由于服 务电话而引发异常。对象类型6表示类型五^T5wwVie^五A:c印"Vm 的返回值，在图61中说明了其属性。 String pin) throws Exception; String transactionAmount， Boolean tipRequest,
8941 String memoText) throws Exception;/mj;i ^rMW户aj;函数用于对r^r^WiV);调用进行响应，此 调用批准请求的支付。[896publicPayRequestSummary payRequestPay(为与处理设备启动的调用的MCA和平台体系结构一致， 本发明在设备上作为"设备服务"实现了这样的通知的处理程序，与当 从服务器端调用这些"设备服务，，上的方法时，有相同的ServiceProxy 签名。编解码器和有线协议与由设备启动的那些请求完全相同。这里 是当前可用的"设备服务"和它们的方法的列表现在讨论了 MCA &平台(MCAP)的高水平的设计，以 及用户界面(UI),呈现了 MCAP预期的并且是所需的完整的一套 移动功能。MCAP基本上是"移动钱包"或"通过电话支付"的消费者/ 移动-商家应用程序。MCAP的用户界面简单，它只需要一步接一步 地输入请求数据(如金额、PIN，等等)，然后显示响应数据。通过 例图和比较，MCAP的用户界面不需要移动游戏应用程序的图形复 杂性。优选情况下，MCAP是模块化的，以便它在J2ME上轻 -松地实现，并在.NET以及J2ME、 BREW、 Symbian，以及.NET CF (以前的Windows Mobile)上证明图63显示了移动设备的高水平OMAP设计层。图64是显示了使用单一文本字符串(带有分隔参数/值对) 的OMAP通信^没计和请求/响应编码方案的流程图。图69显示了从来源角度来看的OMAP支付屏幕流程。
在本发明的其他实施例中，"支付资金"功能可以叫做"汇款"。图72显示了从目标-接受角度来看的OMAP接受支付 屏幕流程。图73显示了其中目标拒绝请求的OMAP请求支付屏幕流程。图75显示了其中源和目标两者都拒绝请求的OMAP请 求支付屏幕流程。图77显示了 OMAP历史屏幕流程。有一个联系人菜单，用户可以保存联系人，并从其中选择 要支付或请求支付的联系人。有一个消息或便笺字段，用户可以与发 出支付或支付请求一起输入消息。例如，用户可以告诉目标，"资金4， 午餐"。有一个让用户可以输入用户的PIN的屏幕。PIN将不会显 示，而是将显示星号，空白，或另一个字符。可以有一个屏幕，列出 全部交易，并给予用户在汇款之前确认交易的机会。如果有错误，当 然，可以在发送之前对交易进行编辑。应用程序还可以进一步包括帮助或简要用户指南，以协助 用户并回答用户的有关系统的使用的问题。金融服务API为此服务定义的应用程序编程接口 (API)有 [952]/mj，户2尸-在两个消费者会员之间执行帐户持有人与帐户持
有人(p2p)之间的交易r^Weve好/Woo;-检索指定的帐户的最后五个交易记录，包
括显示了可用余额的第六行/m^i qweW户flj;—由两部分组成的交互的第二步骤，支付 请求的收款人要么付款或者拒绝付款String srcDevKey,String srcPin，throws ExceptiontransactionAmount 字符串值，向接收方帐户进行支付的金额。返回类型对象public BalanceSummary retrieveBalance (throws Exception输入参数devKey字符串值，通常是正在请求其佘额的帐户的电话
号码BalanceSummary 包括可用余额数据的容器对象。有关详 细信息，参见BalanceSummarv类描述。 [986方法签名retrieveHistory此方法支持从移动设备呼叫，以检索会员的五个最近的交 易，并在其历史显示中包括当前帐户余额。结果被发送到调用的会员 的移动电话。reirieveHistory ( [989] String devKey， [990String pin)[991throws Exception [992输入参数 String paymentAmount， String transactionRef，tgtDevKey 字符串值，要么是接收支付的帐户的电话号码，要么是用于向与接收支付的帐户关联的设备标识JNDI连接键的 引用键 tipAmount 字符串值，要添加到交易总和中的小费支付
金额返回类型对象 String srcDevKey， tipRequest 布尔值，指出是否向请求收款人呈现小费请
求屏幕。返回类型对象此方法persists设备号为帐户数据记录。如果有更多信息 可用，诸如会员名，那么，该方法还将persist补充信息。根据需要， 在数据对象之间进行引用。该方法返回指出了帐户的注册状态的容器 对象。
10541 public ArrayList addRegistrationInfo( [1055J ArrayList regContainerList， [1056String緒ame) [1057throws Thiwable [1058输入参数转帐对象 status 字符串值，指出是否在服务执行过程中发生了错
误
1=好，0=错误 transactionType 字符串值，指出交易类型P2P、 POS、 ATM、 IX)AD、 BAL属性此异常表示可以呈现给客户端应用程序的错误。异常对 象中包含的错误消息不是显示给帐户持有人的消息。返回到帐户持有 人的错误消息是帐户持有人可理解的形式，并且被本地化。在网关中 进行errorCode到错误消息的转换。程序包
1141com.ewp.core.exceptions属性从父类继承。 [1145错误代码有时作为 TransactionEvent 事件状态代码和 AuditEvent 事件状态代码出现的错误代码。请参阅 ErrorCodesAndNotifications.doc 了解4晉误代码和定义。业务对象 vw(/3;户/w -处理对照帐户验证pin的请求
1166Method signature: balance Method signature: history public TransactionSummary[]history( String transactionAmount); (1)丢失移动设备并不意味着丢失资金，因为利用在线同 步，帐户可以关闭，余额可以转移到新帐户；以及图93显示了 EWP J2ME同步服务调用。同步服务调 用是由诸如完成诸如支付之类的屏幕序列之类的用户操作而启动的。 在此情况下，启动与服务器端的服务的通信的同一个线程还处理返回 值。大多数移动消费类通信设备例如，蜂窝电话、PDA(个 人数字助理)、笔记本电脑等等，都包含可移动标识模块(IM)卡或 芯片，用于向无线通信网络运营商唯一地标识特定消费者的帐户。IM 卡/芯片存储了数据，并提供一些"大脑"，可使宿主移动消费类通信设 备运转，例如，发出和接收语音电话、发送或接收消息，运行计算机 应用程序等等。这可使用户，例如，通过从一个电话中取出IM卡/ 芯片并将卡/芯片重新插入到另一个电话中，轻松地更换蜂窝电话。不 需要通过通信网络来激活第二个蜂窝电话。但是，不管类型如何，IM以及它们的宿主移动通信设备 一般是"封闭的"，无线通信网络运营商(例如，Cingular、 T-Mobile、 Verizon等等)、移动消费类通信设备的制造商，以及IM制造商(例 如，Gemplus、 Oerthur等等)专有的系统。尽管如此，通信协议， IM宿主通信设备，即，移动消费类通信设备，IM之间的接口是通 过由ISO (国际标准化组织)制定的技术标准而开放的。在任何情况下，可编程处理单元9618都与操作系统 10110、事件接口 call-out 10111、后IM处理call-out 10112、应用 程序注册表10113,以及编程语言和运行时10114 —起操作，如图 101所示。操作系统促进宿主移动消费类通信设备9500和IM9619 之间的通信，如以前所说明的。操作系统还向在可编程处理单元9618 中注册和安装的应用程序提供编程call-out。
〖l208事件接口 call-out 10111提供编程事件接口，这是应用程
序实现的，为了在发生特定移动设备事件时，例如，按下按钮，振铃 信号等等，获得对宿主移动消费类通信设备的编程控制。在此控制过
程中，应用程序具有对事件添加功能和处理的能力。在接收到DTMF音调的情况下，服务器10212跨无线 通信网络接合IVR (交互式语音响应)单元10226以对音调进行解 码。IVR可以发送和接收DTMF音调(有时叫4故"按键音")，在许 多当前的自动电话应答系统中都有。它允许计算^L自动地使用语音识 别、音频播放、文本到语音转换(ITS)和DTMF 4支术与人进行交互。IVR "插件"10224是IVR改编的API,用于将数据变成服务器 10212中的应用程序10222的正常形式。这允许移动消费类通信设 备10210中的应用程序10221通过音频信道10211与服务器 10212中的企业应用程序10222进行通信。数据信号在两个应用程 序10221和10222之间的两个方向进^f亍传输。移动消费类通信i殳备 10210和服务器10212之间的通信是通过音频信道的客户端/服务器 之间的通信的示例。另一方面，服务器应用程序10222的操作可以 是简单地将来自移动消费类通信设备10210的数据中继到另一个移 动消费类通信设备。这是通过音频信道的对等通信的示例。本发明的实施例中的API,例如，图102的API 10223 和10224，基于简单的"sendRequest()"/processRequest()，，模型，在客 户端和服务器端都带有已知的请求/响应数据结构。API 10223和 10224是配对的客户端和服务器API组，移动应用程序和企业力l务 器开发人员用它们来构建完整的客户端/服务器应用程序。客户端(移 动消费类通信设备)和服务器端上的语音数据处理软件(即，库组件) 对于跨音频信道的数据通信实现了语音数据处理算法。当然，这些算 法不同于特定客户端/服务器应用程序10221和10223。这是移动客户端应用程序用来向企业服务器应用程序发 送请求/数据的单一 API接口。字母数据元素被分解为单个的字符元素。每一个完整的字母数据元素都以"#"代码结尾。此示例中的命令是由 CommandID 1代表的 payRequest,以及由 CommandID 2代表的payResponse。下面的两 个表中定义了参数数据结构宿主移动客户端应用程序与源消费者进行交互，并收 集下列数据 sourceAccountN腿ber - "123456789"
1272] sourcePIN-'，4321" sourceAccountNumber - "987654321，'由于上下文和配置，宿主移动客户端应用考呈序"知道" 下列数据 [1281] ParameterID = 1 [1282] ParameterType = 1[1283ParameterValue = "123456789" ParameterID = 4对上面的编码示例应用上面的规则，看到下面的东西 [1308引导"ir，表示"CommandlD 1"，已知是"payRequest，，命
令...对于数字参数类型，依次类推然后，客户端API传输全部上面的编码的DTMF请求。企业服务器应用程序向IVR插件返回Response结构 和控制。移动客户端应用程序API使用上文所描述的解码规则 将经过编码的DTMF响应数据解码为客户端Response结构(即， 在此情况下，解码为Response结构)。 API向宿主客户端移动应用程序返回Response结构和控制。本发明的各种特定实施例包括 1. —种移动个体化支付系统，包括用于管理闭环支付系统的服务器；以及 4.根据权利要求3所述的系统，进一步包括调用所述编 程性的HTTPSAPI调用的安全性装置。 8.根据权利要求7所述的系统，其中，所述合并帐户表 示多个预存款的借记卡。 9,根据权利要求8所述的系统，其中，所述预存款借 记卡链接到所述合作银行系统中的支票帐户。 12.根据权利要求6所述的系统，其中，所述移动客户 端应用程序、服务器和所述至少一个另外的移动客户端应用程序的组 合构成了个人之间的付款转帐系统。在支持IP的设备上激活客户端应用程序；将收到付款通知给所述收款人。 [136623.根据权利要求22所述的方法，进一步包括 [1367如果付款是针对没有帐户的号码，则为收款人建立帐户；
以及 24.根据权利要求22所述的方法，进一步包括:通过从合并帐户向相应的帐户划拨资金来对每一个交易
实时进行结算。 26.根据权利要求22所述的方法，进一步包括 [1375在离线模式下对选定交易进行结算。 30.根据权利要求29所述的方法，其中，所述记录过程 包括向记帐程序实时发送交易的口头描述。通过第二通信路径发送个人标识号(PIN);在支付服务器中将所述请求与PIN相关联；以及
l389基于请求和PIN之间的关联，进行金融交易。
139034.根据权利要求33所述的方法，其中，发送请求的过
程进一步包括通过短消息服务(SMS)发送命令。 36.根据权利要求35所述的方法，其中，形成所述命令 的过程进一步包括
1396请求向对等伙伴进行支付。向计帐应用程序发送所述命令。 41.根据权利要求39所述的方法，其中，发送所述命令 的过程进一步包括通过SMS接收帐户余额消息。44. 4艮据权利要求33所述的方法，进-一步包括请求帐户历史。45.根据权利要求44所述的方法，进-一步包括请求对等伙伴建立一个帐户，从该帐户向请求者进行支 付，所述请求是通过SMS发送的。 55.根据权利要求53所述的方法，其中，给出PIN的 清晰发音，然后由交互式语音识别系统对其进行解码。显示用户界面，以《更形成命令；通过第二通信路径发送个人标识号(PIN); 59.根据权利要求56所述的方法，其中，形成所述命令 的过程进一步包括61.根据权利要求56所述的方法，其中，形成所述命令
的过程进一-步包括
1447]向所述命令添加消息。62.根据权利要求61所述的方法，其中，形成所述命令
的过程进一-步包括
1449]向所述命令添力6己录标t己。64.根据权利要求62所述的方法，其中，发送所述命令
的过程进一步包括向增值服务提供商发送所述命令。通过选定协议接收帐户余额消息。请求帐户历史。71.根据权利要求70所述的方法，进一步包括
1467接收支付已经被授权或者拒绝的指示，所述指示是通过SMS发送的。[146872.根据权利要求71所述的方法，进一步包括 [1469请求对等伙伴建立一个帐户，从该帐户向请求者进行支 付，所述请求是通过SMS发送的。 76. —种移动个体化支付系统，包括 77.根据权利要求76所述的系统，进一步包括至少一个
另外的移动客户端应用程序，其中，所述移动客户端应用程序、服务
器和所述至少一个另外的移动客户端应用程序的组合构成了具有较
低的交易费用的闭环支付系统。
147978.根据权利要求76所述的系统，进一步包括至少一个
另外的移动客户端应用程序，其中，所述移动客户端应用程序、服务
器和所述至少一个另外的移动客户端应用程序的组合构成了没有交
易费用的闭环支付系统。选择产品；激活移动客户端应用程序以处理金融交易； [1487进行购物；以及 [1488在指定的地址自动地接收选定产品。 [148984， 一种用于进4亍购物的方法，包括 [1490选择产 品586.根据权利要求84所述的方法，进一步包括利用与手 机关联的近场通信设备来激活交易。 87.根据权利要求84所述的方法，进一步包括利用与手 机关联的RFID设备来激活交易。 88. —种用于进4亍购物的方法，包括通过发送具有第一标识符的请求来启动金融交易，所述 请求是使用第 一通信渠道发送的； 99. —种用于防止从手机输入的金融交易的欺骗性提交 的方法，包括 101.根据权利要求99所述的方法，其中，第一通信渠 道是SMS传输渠道。
103.才艮据权利要求102所述的方法，进一步包括 [1541将包含密码的第二明语消息发送到交易处理器；[1542截取第二 SMS消息；以及 109.根据权利要求108所述的系统，其中，能够通过 编程性的SMS API调用，通过移动设备的SMS文本服务，来利用 移动设备的SMS数据服务。
113. 4艮据权利要求111所述的系统，进一步包括合并
帐户，其中包括帐户持有人持有的所有资金，合并帐户与总帐关联，
以管理帐户持有人之间的资金转拨。从至少一个帐户持有人接收划拨资金的金融交易请求；
以及 117.根据权利要求116所述的方法，其中，资金被转 移到至少一个另外的帐户持有人。将新帐户持有人指定为"无卡，，帐户持有人；以及 [1S75]给予无卡帐户持有人有限的资金接触权限。1576124.根据权利要求123所述的方法，进一步包括通过
向记录地址发送借记卡来向无卡帐户持有人发放借记卡。
125.根据权利要求124所述的方法，进一步包括 127.根据权利要求126所述的方法，其中，单个实体
是记录系统，并承担维护合并帐户的风险。可由管理实体控制的第二层。 132.根据权利要求128所述的系统，其中，所述第二 层进一步包括用于检测欺骗性交易的装置。 话音通信连接；在移动设备上执行的用于将编码响应转换为用户界面上 人可读取的格式的JAVAAPI。本发明的描述只是为了说明和描述。它不是详尽的说明 或将本发明限于所描述的准确的形式，显然，根据上文的讲述，许多 修改方案和变化也是可以的。所选择的实施例只是为了最好地说明本 发明的原理，以及其实际应用。本描述将能使本领域技术人员以各种 实施例最佳地利用和实施本发明，根据特定用途进行各种修改。本发 明的范围由下面的权利要求进行定义。
权利要求
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. 基本上如上文所描述的方法。
全文摘要
移动支付平台和服务提供了由移动设备的用户进行付款的快速，简便的方式。该平台还与诸如电子邮件、即时消息，以及Web之类的非移动渠道以及设备连接。在一种实现方式中，从诸如移动电话或个人数字助理之类的帐户持有人的移动设备访问资金，以进行支付或接收支付。金融交易可以在个人之间(P2P)或个人与商家之间(P2M)进行，其中，每一方都由诸如电话号码或条形码之类的唯一指示符来进行标识。可以通过任意数量的手段来请求进行交易，包括SMS消息、Web、电子邮件、即时消息、移动客户端应用程序、即时消息插件应用程序或“小部件”。驻留在移动设备上的移动客户端应用程序简化了访问，并以快速安全的方式执行金融交易。
文档编号G06Q40/00GK101454794SQ200780019766
公开日2009年6月10日 申请日期2007年3月30日 优先权日2006年3月30日
发明者C·里尔尼, D·斯科瓦特兹, H·斯霍基, J·图米纳罗, N·沙, P·霍索卡瓦 申请人:奥博佩公司