[21]本发明通过提供易于使用，轻松地可访问的电子付款系统， 基本上克服了现有技术的如前所述的局限性，该系统对于对等伙伴的 交易和商家与客户之间的交易来说，允许方便地交换良好的资金，在 至少某些实施例中，无需诸如与常规信用卡和借记卡关联的商业银行 系统的基础架构和成本。在许多实施例中，该电子付款系统能够被用 户通过诸如手机之类的无线设备进行访问，以便可以进行资金转帐并 基本上实时地验证是否收到，而同时又能提供适当的安全性，确保欺 骗性的交易被减少到最低程度。
[22]根据本发明的某些实施例的移动支付平台和服务提供了由 移动设备的用户进行快速方便的支付并验证支付的方式。该平台还与 诸如电子邮件、即时消息，以及Web之类的非移动渠道以及设备连 接。在一种实现方式中，从诸如移动电话或个人数字助理之类的帐户 持有人的移动设备访问资金，以进行支付或接收支付。金融交易可以 在个人之间(P2P)，个人与商家之间(P2M)进行，其中，每一方都 由诸如电话号码、条形码之类的唯一指示符，或任何其他合适的标志 来进行标识。可以通过任意数量的手段来效果进行交易，包括SMS 消息、Web、电子邮件、即时消息、移动客户端应用程序、即时消息 插件应用程序或“小部件”。在某些实施例中，驻留在移动设备上的 移动客户端应用程序简化了访问，并以快速安全的方式执行金融交 易。
[23]本发明提供了移动支付系统(MPS)或移动的个人之间支付 系统，用于快速方便地进行货币划拨。通过移动支付系统和诸如他们 的手机之类的访问设备，用户将能够进行支付，请求支付，验证是否 收到资金，为服务进行支付，为帐单进行支付，为电影票进行支付、 为杂货店进行支付，为保姆进行支付，为咖啡和报纸进行支付，立刻 偿付给朋友，为晚餐帐单各自支付，向孩子汇款，从父母那里得到汇 款，获得快速的或紧急的现金，发送紧急的现金，为友好赌博付清或 收费，为梦幻足球(fantasy football)游戏进行支付，为花园服务进 行支付，为会费进行支付，跟踪购物，检查余额，等等。此外，在至 少某些实施例中，这些交易中的每一种交易都基本上实时地进行，良 好的资金立即对收款人可用。
[24]在一个实施例中，本发明允许对ATM网络进行访问，例如， 对NYCE网络进行访问，以进行交易。
[25]本发明解决了现有技术的金融工具的许多如前所述的局限 性，包括下列各项：现金会被盗，现金交易不可追踪。需要鼓励现金 存放在银行中，而不是消费者的口袋中。需要低成本的或小型存现存 储器。需要较低的成本的电子支付。需要电子支付对每个人、任何地 方、任何时间几乎实时地可用。需要电子支付产生立刻的或近乎立刻 可使用的货币形式(诸如，例如，附属预存款借记卡，或通过连接到 用户的在银行中的活期储蓄帐户(DDA))。需要电子支付能够被有银 行帐户的和无银行帐户的消费者访问。需要电子支付能够链接到现有 的金融工具，如信用卡、借记卡、预存款的卡、工资单，及其他。需 要能够实时地或几乎实时地向现有的金融工具中加载和从中卸载。需 要电子支付能够跨银行地使用。需要电子支付能够通过移动设备进行 访问。需要电子支付能够通过诸如PC、POS支付终端、TV电缆盒、 DVR、卫星盒之类的消费者媒体设备，及其他设备进行访问。需要电 子支付能够通过诸如自动售货机、停车计时器、售货亭之类的人机设 备及其他设备进行访问。需要电子支付能够跨诸如移动运营商、有线 运营商、卫星运营商之类的电子网络及其他网络地使用。
[26]本发明的MPS的一些优点下列各项：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保护的，并且在银行中是“活的”。
[27]在一个实施例中，本发明的闭环金融交易系统部分地基于诸 如手机或PDA之类的无线设备的使用来进行支付或接收支付。金融 交易可以在个人之间进行，其中，每一方都由诸如电话号码、电子邮 件地址、即时消息标识符或条形码之类的唯一指示符来进行标识，或 在消费者与商家之间进行。
[28]在一个实施例中，本发明是包括连接到网络的消费者界面的 金融交易系统，包括：处理来自Web浏览器客户端的交易请求的 Web界面；处理来自移动电话客户端上的移动因特网浏览器的交易 请求的移动因特网浏览器界面；使用SMS文本消息处理交易请求的 SMS界面；以及，处理来自在移动电话客户端上执行的移动客户端 应用程序的请求的移动客户端应用程序界面。
[29]在一个实施例中，消费者界面可以包括处理来自电话音频信 道的请求的交互式语音响应界面。系统的一个实施例可以包括新注册 的用户的合并帐户，其中，在注册之后，新注册的用户可以立即与已 注册的用户进行交易。移动客户端应用程序界面可以，在至少某些实 施例中，允许“汇款”交易、“请求资金”交易、“加载帐户”交易、“卸 载帐户”交易，以及“余额查询”交易。消费者界面还可以进一步包括 处理来自即时消息客户端的请求的即时消息界面。
[30]该系统的一个实施例可以包括：金融合作伙伴界面；商家界 面，其中，用户能通过消费者界面访问存储在通过金融合作伙伴界面 连接到系统的银行中的资金，并向连接到商家界面的商家转帐。该系 统的一个实施例可以包括由金融交易系统进行管理的记录系统，记录 通过消费者界面执行的交易。在某些实施例中，该系统可以包括由金 融交易系统进行管理的合并帐户(pooled account)，其中，通过消 费者界面访问该系统的多个客户端在合并帐户中具有帐户。许多客户 端可以在合并帐户中没有帐户，而是在可以访问该系统的金融机构中 具有帐户。
[31]在一个实施例中，本发明是包括下列步骤的方法：提供与第 一金融合作伙伴进行交易的应用程序界面；提供接收进行交易的请求 的SMS消息界面；以及，提供用于接收进行交易的请求的移动客 户端应用程序界面，其中，通过SMS消息界面或移动客户端界面， 客户端可以请求从位于第一金融合作伙伴的第一帐户向位于第二金 融合作伙伴的第二帐户转帐。
[32]该方法还可以进一步包括提供用于接收进行交易的请求的 移动客户端应用程序界面，其中，通过SMS消息界面或移动客户端 界面，客户端可以请求从位于第一金融合作伙伴的第一帐户向位于第 二金融合作伙伴的第二帐户汇款。该方法可以包括提供用于记录通过 SMS消息和移动客户端界面请求的交易的记录系统。
[33]在一个实施例中，本发明是包括下列步骤的方法：在移动电 话的显示器上显示第一屏幕，以显示多个选项，包括向另一方付款的 第一选项和请求余额信息的第二选项；在用户选择第一选项时，显示 第二屏幕，供用户输入向其发出支付的目标电话号码或其他标志；在 用户输入目标电话号码之后，显示第三屏幕，供用户输入交易金额； 在用户输入电话号码之后，显示第四屏幕，供用户输入PIN代码； 以及，在用户输入PIN代码之后，以无线方式向服务器发送交易信 息，包括目标电话号码、交易金额，以及PIN代码，以便进行处理。
[34]该方法可以包括下列步骤，在用户输入目标电话号码之后， 显示第五屏幕，供用户输入可选消息。该方法可以包括：在用户选择 了第二选项时，以无线方式向服务器发送查询余额信息的请求；从服 务器接收余额信息；以及，在第五屏幕中显示余额信息。该方法可以 包括，其中，第一屏幕进一步提供从另一方请求付款的第三选项。该 方法可以包括，第二屏幕具有第三选项，在用户选择了该选项时，给 用户提供地址簿的使用权，从该地址簿中，用户可以选择一个条目用 作目标电话号码。交易信息可以包括由移动电话生成的序列号，用于 对交易进行鉴定。在一种实现方式中，用户的电子资金是在服务器中 维护的，而不是在移动电话上维护的。
[35]在一种实现方式中，该方法包括：当在移动电话中接收到要 求付款的请求时，显示第五屏幕，供用户可以输入小费金额。
[36]通过下面的参考附图进行的详细描述，本发明的其他目的、 特征，以及优点将变得更加显而易见，在附图中，类似的附图标记在 整个图中表示相同的功能，其中：

[37]图1显示了本发明的系统的方框图。
[38]图2显示了本发明的特定实施例的软件体系结构。
[39]图3显示了用于实现本发明的实施例的环境。
[40]图4显示了本发明的实施例，其中，与支付服务一起提供 了增值服务。
[41]图5显示了移动的个人之间支付的系统拓扑。
[42]图6显示了在同业银行的个人之间的支付。
[43]图7显示了跨银行个人之间的支付。
[44]图8显示了链接的帐户加载。
[45]图9显示了链接的帐户卸载。
[46]图10显示了根据本发明的技术的支付系统和个人之间的 支付。
[47]图11显示了用于在带有卡的会员和未注册的用户之间进 行交易的方法。
[48]图12显示了用于在没有卡的会员和未注册的用户之间进 行交易的方法。
[49]图13显示了在一个无卡会员和另一个无卡会员之间进行 交易的方法。
[50]图14显示了用于在一个有卡会员和另一个有卡会员之间 进行交易的方法。
[51]图15显示了在一个有卡会员和一个无卡会员之间进行交 易的方法。
[52]图16显示了在一个无卡会员和一个有卡会员之间进行交 易的方法。
[53]图17显示了对未注册的用户进行注册的方法。
[54]图18显示了激活卡的方法。
[55]图19显示了本发明的特定实施例的完整的系统图形。
[56]图20显示了两个个人卡帐户之间的个人之间的支付。
[57]图21显示了卡帐户和非会员帐户之间的个人之间的支付。
[58]图22显示了卡帐户和无卡帐户之间的个人之间的支付。
[59]图23显示了无卡帐户到无卡帐户之间的个人之间的支付。
[60]图24显示了信用卡加载。
[61]图25显示了本发明的另一个特定实施例的完整的系统图 形。
[62]图26显示了无卡帐户和无卡帐户之间的个人之间的支付。
[63]图27显示了无卡帐户和卡帐户之间的个人之间的支付。
[64]图28显示了个人之间的支付，与非会员的“病毒式”交易。
[65]图29显示了刺激资金。
[66]图30显示了信用卡加载。
[67]图31显示了ACH加载。
[68]图32显示了ACH卸载。
[69]图33显示了ATM加载。
[70]图34显示了用于使用“封闭的”互换网络实现信用卡交易 的现有技术环境。
[71]图35显示了根据本发明的实施例的闭环支付交易系统。
[72]图36显示了根据本发明的实施例的用于实现费用较低并 且安全性改善的闭环金融交易系统的环境。
[73]图37是根据本发明的实施例的闭环金融系统的方框图。
[74]图38是根据本发明的实施例的移动客户端应用程序 (MCA)的方框图。
[75]图39显示了根据本发明的实施例的闭环支付交易系统。
[76]图40显示了根据本发明的实施例的闭环金融系统的示范 性费用结构。
[77]图41显示了本发明的支持会员的支付系统实现方式中的 加载信任操作。
[78]图42显示了支持会员的支付系统中的消费者注册过程。
[79]图43显示了支持会员的支付系统中的加载和卸载操作。
[80]图44显示了支持会员的支付系统中的购物交易。
[81]图45显示了使用虚拟合并帐户的系统。
[82]图46显示了根据本发明的实施例的快速购物功能。
[83]图47显示了根据本发明的实施例的另一个快速购物功能。
[84]图48是由根据本发明的实施例的至少一个SMS消息机 制执行的金融交易的系统级别的例图。
[85]图49显示了根据本发明的实施例的用于保护基于SMS 的金融交易的方法。
[86]图50显示了根据本发明的一个实施例的安全的SMS聚 集服务器的用途。
[87]图51显示了根据本发明的实施例的新帐户持有人的注册 过程。
[88]图52显示了根据本发明的实施例的分层的欺诈检测系统。
[89]图53显示了根据本发明的实施例的合并帐户结构。
[90]图54，55和56显示了根据本发明的实施例的用于防止欺 诈和多重重复交易请求的方法。
[91]图57显示了序列号验证的示例。
[92]图58显示了序列号验证的另一个示例。
[93]图59显示了根据本发明的实施例的指定在设备和数据中 心之间传递的序列化数据的格式的有线协议。
[94]图60显示了根据本发明的实施例的服务电话的成功的调 用。
[95]图61显示了根据本发明的实施例的对服务电话的响应，其 中，由于服务电话而生成异常。
[96]图62显示了根据本发明的实施例的另一个服务电话的成 功的调用。
[97]图63显示了根据本发明的实施例的移动设备的高水平 OMAP设计层。
[98]图64是显示了根据本发明的实施例的OMAP通信设计 的状态图。
[99]图65是显示了根据本发明的实施例的OMAP持久设计 的状态图，以及显示了根据本发明的实施例的OMAP用户通知设计 的状态图。
[100]图66显示了根据本发明的实施例的OMAP屏幕调色 板。
[101]图67是显示了根据本发明的实施例的OMAP屏幕转换 的状态图。
[102]图68显示了根据本发明的实施例的OMAP主菜单的布 局。
[103]图69显示了根据本发明的实施例的从来源角度来看的 OMAP支付屏幕流程。
[104]图70显示了根据本发明的实施例的从目标角度来看的 OMAP支付屏幕流程。
[105]图71显示了根据本发明的实施例的从源-请求角度来看的 OMAP请求支付屏幕流程。
[106]图72显示了根据本发明的实施例的从目标-接受角度来看 的OMAP请求支付屏幕流程。
[107]图73显示了根据本发明的实施例的其中目标拒绝请求的 OMAP请求支付屏幕流程。
[108]图74显示了根据本发明的实施例的其中源和目标两者都 接受请求的OMAP请求支付屏幕流程。
[109]图75显示了根据本发明的实施例的其中源和目标两者都 拒绝请求的OMAP请求支付屏幕流程。
[110]图76显示了根据本发明的实施例的OMAP余额屏幕流 程。
[111]图77显示了根据本发明的实施例的OMAP历史屏幕流 程。
[112]图78显示了根据本发明的实施例的在源位置的OMAP 设置屏幕流程。
[113]图79显示了根据本发明的实施例的未知移动ID的 OMAP的屏幕流程。
[114]图80显示了根据本发明的实施例的其中请求失败的 OMAP系统异常屏幕流程。
[115]图81到86显示了用于进行个人之间的支付的移动电话 应用程序的用户屏幕和流程。
[116]图87和88显示了根据本发明的实施例的用于提供离线 支付系统的体系结构。
[117]图89是根据本发明的实施例的用于在移动设备上进行实 时和离线两种金融交易的移动设备的组件的方框图。
[118]图90显示了根据本发明的实施例的MCA的J2ME应 用程序基础架构。
[119]图91显示了根据本发明的实施例的应用程序(MCA)初 始化和屏幕序列图。
[120]图92显示了根据本发明的实施例的屏幕序列类。
[121]图93显示了根据本发明的实施例的EWP J2ME同步服 务调用。
[122]图94显示了根据本发明的实施例的与服务器的异步交互 或未经请求的通知。

[123]在此对本发明的实施例的描述中，提供了很多具体细节， 如组件或方法或两者的示例，以便于对本发明的实施例进行全面的理 解。然而，本领域技术人员应认识到，可以在没有一个或多个具体细 节的情况下来实施本发明的实施例，也可以利用其他设备、系统、组 件、方法、部件等等，以及这些东西的组合来实施。在其他情况下， 没有具体地显示或详细描述已知的结构、材料、或操作，以避免使得 本发明的实施例的某些方面变得模糊。
[124]在特定实现方式中，本发明涉及移动支付平台和服务。本 发明的实施例包含了一个支付平台，该支付平台提供了供个人或商家 使用他们的移动设备访问诸如借记帐户之类的帐户以便进行付款的 快速，简便的方式。进一步的界面包括IM、Web，以及应用程序小 部件。其他帐户可以包括DDA或信用卡帐户。帐户也可以是没有卡 与其关联的储值帐户。本发明的另外的实施例涉及各种合作伙伴，包 括移动电话运营商、全国性的品牌商家，以及金融服务提供商，连同 支付平台，该支付平台提供供个人使用他们的移动设备进行付款的快 速，简便的方式。
[125]图1显示了本发明的系统的方框图，用于进行价值交换交 易，包括以特定实现方式，个人之间的支付和交易，人与商家的支付 交易，及其他银行交易。应用程序服务器107连接到网络109。虽 然只显示了一个应用程序服务器，但是，在本发明的系统中，可以有 任意数量的应用程序服务器，而这样的服务器在地理位置上可以是分 散的。这样的应用程序服务器可以在单一服务器机器上运行，也可以 在许多服务器机器上运行。随着应用程序服务器上的负载增大，通常， 将使用更多的机器来处理和响应增大的负载。
[126]商家的界面112和用户界面116也连接到网络。此网络 可以是传输数据的任何网络，包括，但不仅限于，因特网、以太网、 普通老式电话业务(POTS)线路、公共电话交换网(PSTN)、ISDN、 DSL、同轴电缆、光纤、卫星、蜂窝式、有线、无线、固定线路、串 联、并联，以及许多其他形式，以及它们的组合。用户界面可以处理 任意数量的用户，如用户A、用户B，以及最多用户n，其中，n是 任何正整数。用户界面可以通过各种设备来实现，包括诸如手机或 PDA之类的无线或移动设备，或者通过固定线路或有线链路，使用， 例如，连接到因特网的浏览器来实现。用户界面可以通过任何合适的 协议进行操作，包括SMS消息、IVR应用程序，或其他移动应用 程序。商家界面也连接到应用程序服务器。类似于用户界面，可以有 任意数量的商家使用任何合适的设备和协议连接到应用程序服务器。
[127]在应用程序服务器上，有一个也可以连接到商家界面的支 付处理器119。金融机构界面123连接到应用程序服务器和支付处 理器。可以有任意数量的金融机构连接到应用程序服务器。应用程序 服务器也可以包括数据库127。或者，数据库可以位于与应用程序服 务器分开的服务器上，应用程序服务器通过网络或其他连接可以访问 它。金融机构也可以连接到数据库。数据库可以包括通常由应用程序 服务器107进行管理的记录系统130和虚拟合并帐户134。金融机 构可以管理合并帐户138。因此，在金融机构中，可以与合并帐户分 开地管理记录系统和虚拟合并帐户。
[128]在操作中，本发明的系统驻留在应用程序服务器107上。 用户通过网络109利用他所选定的设备以及其关联的协议来访问系 统。在一个实施例中，系统为消费者维护了一个帐户，消费者通过任 何合适的方法，如直接储蓄，链接到诸如支票或储蓄帐户或信用卡之 类的银行帐户来将款项储蓄到他的帐户中。由每一个消费者存款的金 额都全部在金融机构的合并帐户138中进行维护，记录系统维护了 每一个个人消费者帐户的记录，尽管资金是合并在金融机构中的。同 样，商家也维护了一个帐户，他们的资金驻留在合并帐户中，并由记 录系统进行跟踪。在合并帐户138在多个金融机构中进行维护的情 况下，虚拟合并帐户134执行那些不同的虚拟帐户138中的余额的 实时表示，允许消费者和商家实现实时和近乎实时交易的优点，而同 时提高了银行效率，允许不太定期地进行协调，例如，如每天或每周 地定期进行。所属领域的技术人员将认识到，合并帐户不是所有实施 例所必需的，相反，可以在金融机构实现个人帐户，虽然，系统的操 作方式基本上与合并帐户相同。
[129]如果消费者希望向另一个人或商家汇款，他通过他的接入 设备，例如手机，提供适当的信息，并系统进行交易的记录。作为交 易的一部分，消费者的帐户被从中划出，收款人的帐户将被划入。由 于资金实际在单一合并帐户中维护，因此，没有外部资金转拨。相反， 唯一的更改是相应的帐户的划出和划入，并反映在记录系统中，这基 本上是实时发生的。甚至在汇款人的资金和收款人的资金维护在不同 的机构中维护的不同的合并帐户中的情况下，记录系统管理资金转 帐，以便，从汇款人和收款人的角度，交易基本上是实时发生的。如 此，没有使用ACH或其他昂贵的基础架构，如与常规信用卡关联的 专有系统。这又使得系统的用户进行金额非常少的货币兑换，没有不 适当的成本。
[130]此外，由于本发明的系统具有从汇款人可用的资金的当前 记录，给收款人确信有可以立即访问的良好的资金。结果是用于基本 上实时进行的P2P和P2M资金转帐的方便的，经济合算的系统， 以便就易用性和认可度而言，相当现金，而同时又提供对支票和信用 卡的验证和记录，没有与常规资金转帐的协调及其他方面关联的延迟 和不确定性。
[131]虚拟合并帐户134也可以用来平衡在各种合并帐户138 中维护的资金，确保有足够的资金可用于任何交易，并且，还为托管 了合并帐户138的合作金融机构提供适当的回馈。
[132]本发明的系统可以包括附图中所显示的某些或全部元件， 并可以包括未显示的其他元件。某些元件可以被分成单独的块，或者， 某些元件也可以与其他元件相结合(例如，两个块合并到单一的块 中)。另外，也可以用其他未显示的元件代替某些元件(例如，用一 个不同的块替换一个块)。
[133]在操作中，本发明的系统用于帮助在个人之间以及消费者 和商家之间进行金融交易。在一种实现方式中，用户能通过使用诸如 移动电话或智能电话之类的移动设备来启动交易。此外，交易的目标 可以是具有能够访问移动支付系统的移动设备的人。
[134]在一种实现方式中，这些金融交易的资金来源可以是应用 程序服务器(有时可以被称为移动支付服务器或移动支付服务)的所 有者或运营商。然后，消费者(以及商家)将能够从移动支付服务加 载或卸载资金。这些资金可以是任何来源，包括现金、支票，在线支 付解决方案，电汇资金转帐、支票帐户、储蓄帐户、存款单、反向抵 押贷款帐户、经纪人帐户、红利、证券、对冲基金帐户、信用卡、借 记卡，或任何金融票据，或这些东西的任何组合。
[135]在其他实现方式中，资金来源是可由用户通过移动支付服 务器访问的金融机构。如果需要，资金可以在各金融机构之间转移。 例如，用户A可以向用户B或商家汇款，各方在不同的金融机构 有存款。移动支付系统将有助于各个机构之间的转帐，并相应地通知 各方。
[136]图2显示了本发明的特定实施例的软件体系结构。此方框 图显示了可以在应用程序服务器107上实现的特定体系结构的层。 层包括用户Web应用程序容器203、支付系统容器206、持久层 209，以及关系数据库管理系统(RDBMS)层212。
[137]在特定实现方式中，用户Web应用程序容器和支付系统 容器可以基于由BEA Systems，Inc.出品的WebLogic。持久层可以 基于Hibernate。关系数据库管理系统可以使用Orancle数据库。然 而，在其他特定实现方式中，也可以使用其他供应商的系统。例如， 本发明的系统可以包括开放源代码。
[138]在用户Web应用程序容器中，有用于与不同类型的客户 端连接的表示层。所提供的接口的一些示例包括SMS网关、电话应 用程序网关、万维网服务网关、Web应用程序页面网关，以及Web 应用程序框架网关。电话消息编解码器将诸如SMS或电话之类的传 入的或传出请求或两者转换为系统或客户端特定的消息。本发明的体 系结构可以包括任意数量的这些界面。
[139]支付系统容器包括到外部金融或安全系统、邮件服务器以 及消息传送服务的连接器。还有业务逻辑接口和支付系统业务逻辑。 服务客户端可以通过业务服务网关来调用业务服务。网关实现方式可 以使用EJB或其他技术。
[140]本发明的系统可以包括图中所显示的任意数量的元件。系 统也可以包括其他未显示的元件。某些元件可以被分成单独的块，或 者，某些元件也可以与其他元件相结合(例如，两个块合并到单一的 块中)。另外，也可以用其他未显示的元件代替某些元件(例如，用 一个不同的块替换一个块)。
[141]支付系统基础架构—技术环境
[142]本发明的一个方面是移动支付系统或服务。本申请讨论了 单个组件和元件的许多特定实施例和实现方式，这些实施例和实现方 式的变化和修改，以及它们的组合。本发明的系统可以包括所讨论的 变化或特定实现方式中的任何一种，单独地或以任何组合的形式。在 本申请中，提供了移动支付系统的特定实现方式的示例，这里为了方 便起见，此特定实现方式被称为“Obopay系统”。Obopay系统只是 移动支付系统的实现方式的示例，用于比较轻松地描述本发明的各个 方面。本发明包含了许多移动支付系统实现方式，不仅限于所描述的 特定实现方式。
[143]图3显示了本发明的特定实现方式。图3显示了根据本 发明的实施例的强健的技术环境300，包括移动客户端服务器平台 302、可扩展的硬件环境304，以及银行集成306。
[144]平台302是提供安全性、通信、总帐、货币，欺诈和报告， 以及管理的支付系统基础架构的核心。移动客户端应用程序(MCA) 在J2EE支付服务器上运行，这是许多银行喜欢的技术。传入和传出 的交易请求通过HTTP或万维网服务命令来进行处理。欺诈检测、 交易数据库，以及银行集成构成了整个画面。
[145]应了解，由于本发明的无所不在的特征，平台302包括许 多不同的实现方式。例如，平台302可以包括其中有多个服务器连 接到存储设备的网络的服务器场。在其他实施例中，平台302可以 作为提供负载平衡和冗余的多个数据中心来实现。
[146]支付系统基础架构—平台302的硬件环境
[147]支付系统基础架构基于提供强健的故障转移功能的水平方 向可扩展的，群集化的，可缩放的硬件环境。在一个实施例中，平台 302是使用基于Linux的操作系统实现的，该操作系统支持瘦客户 端应用程序，包括诸如Microsoft Internet Explorer、Netscape、 Opera，以及Mozilla Firefox之类的浏览器。该操作系统还支持胖客 户端应用程序。在一种实现方式中，在移动客户端平台上使用了Java 2平台，Micro Edition(J2ME)和Microsoft.NET，并根据需要，使 用了其他胖客户端应用程序。
[148]可以与系统连接的客户端的示例包括移动电话、智能电话、 个人数字助理设备、笔记本电脑、台式计算机，以及许多其他设备。 客户端可以通过通信网络连接到系统。此网络可以是无线的，也可以 是有线的。在特定实现方式中，网络是无线的，客户端设备是移动设 备。
[149]通信网络可以由许多互连的计算机系统和通信链路构成。 通信链路可以是硬连线的链路、光链路、卫星或其他无线通信链路、 波传播链路，或任何其他用于传递信息的机制。可以使用各种通信协 议来在各种系统之间进行通信。这些通信协议可以包括TCP/IP、 HTTP协议、无线应用协议(WAP)、供应商特定的协议、自定义协 议等等。在一个实施例中，通信网络是因特网，而在其他实施例中， 通信网络可以是任何合适的通信网络，包括局域网(LAN)、广域网 (WAN)、无线网络、内部网、私用网络、公共网络、交换网络、SMS 消息网络、移动电话网络、蜂窝电话网络、以太网，以及这些网络的 组合，等等。
[150]网络可以是有线网络(例如，使用铜线)、电话网络、分 组网络、光网络(例如，使用光纤)，或无线网络，或这些网络的任 何组合。例如，可以使用无线网络，使用诸如Wi-Fi(IEEE标准 802.11、802.11a、802.11b、802.11e、802.11g、802.11i，以及802.11n， 仅举几个例子而已)之类的协议，在本发明的系统的计算机和组件(或 步骤)之间传输数据及其他信息。
[151]在一个实施例中，用户通过诸如智能电话或移动电话之类 的便携式计算设备与系统进行连接。计算机系统可以包括显示器、机 壳、小键盘，以及指示设备。在机壳内，可以有诸如处理器、存储器、 大容量存储设备等等之类的熟悉的计算机组件。可以有单个处理器， 也可以有多个处理器。处理器可以是多核处理器。
[152]可以与计算设备连接的大容量存储设备的一些示例包括快 闪及其他非易失性存储器、快闪驱动器、闪卡(例如，SD卡)、大 容量磁盘驱动器、软盘、磁盘、光盘、磁光盘、固定盘、硬盘、CD-ROM、 可记录的CD、DVD、可记录的DVD(例如，DVD-R、DVD+R、 DVD-RW、DVD+RW、HD-DVD或蓝光光盘)、带蓄电池后备电源 的易失性存储器、磁带存储器、读取器，以及其他类似的介质，以及 这些介质的组合。
[153]在一个实施例中，本发明是由计算设备执行的计算机软件。 计算设备可以是客户端设备或服务器设备，或这些设备的组合。本发 明的计算机实现的或计算机可执行的版本可以使用计算机可读取的 介质来实施，存储在计算机可读取的介质中，或与计算机可读取的介 质关联。计算机可读取的介质可以包括用于向一个或多个处理器提供 指令以便执行的任何介质。这样的介质可以呈现许多形式，包括但不 仅限于，非易失性、易失性，以及传输介质。非易失介质包括，例如， 快闪存储器，或光盘或磁盘。易失性介质包括静态的或动态的存储器， 如高速缓冲存储器或RAM。传输介质包括同轴电缆、铜线、光纤线 路，以及以总线形式提供的线路。传输介质还可以呈现电磁、无线电 频率、声波或光波的形式，如在无线电波和红外线数据通信的过程中 生成的那些。
[154]例如，本发明的软件的二进制，机器可执行的版本可以存 储在或驻留在RAM或高速缓冲存储器中，或存储在大容量存储设备 中。本发明的软件的源代码也可以存储或驻留在大容量存储设备中 (例如，硬盘、磁盘、磁带或CD-ROM)。作为进一步的示例，本 发明的代码也可以通过线路、无线电波，或通过诸如因特网之类的网 络进行传输。例如，可以将本发明的应用程序下载并安装到电话上。 在安装之后，电话的用户可以运行该应用程序，并向另一个用户汇款。
[155]根据本发明的计算机软件可以以各种合适的编程语言中的 任何一种进行编写，如C、C++、C#、Pascal、Fortran、Perl、SAS、 SPSS、JavaScript、AJAX，以及Java。计算机软件产品可以是带有 数据输入和数据显示模块的独立应用程序。或者，计算机软件产品可 以是类，可以作为分布式对象而实例化。计算机软件产品也可以是诸 如Java Beans(来自Sun Microsystems)或Enterprise Java Beans (来自Sun Microsystems的EJB)。
[156]系统的操作系统可以是Microsoft Windows系列操作系 统(例如，Windows 95、98、Me、Windows NT、Windows 2000、 Windows XP、Windows XP x64 Edition、Windows Vista、Windows CE、Windows Mobile)、Linux、HP-UX、UNIX、Sun OS、Solaris、 Mac OS X、Alpha OS、AIX、IRIX32或IRIX64中的任何一种。也 可以使用其他操作系统。Microsoft Windows是Microsoft Corporation的商标。
[157]在一个实施例中，在一个Web浏览器在设备上执行的情 况下，用户通过诸如因特网之类的网络访问万维网(WWW)上的系 统。Web浏览器用于下载各种格式的Web页面或其他内容，包括 HTML、XML、文本、PDF、以及postscript，并可以用来向系统的 其它部件上传信息。Web浏览器可以使用统一资源标识符(URL)来 标识Web上的资源，使用超文本传输协议(HTTP)在Web上传 输文件。
[158]平台302包括服务器308，用于处理与帐户持有人的交 互，并维护交易记录。服务器308还提供到由商业合作伙伴所提供 的增值服务的链接。服务器308利用交易数据库309，该数据库优 选情况下包括数据存储网络。服务器308使用从交易数据库309获 得的信息(如帐号、余额信息等等)，来管理与商业销售点(POS)终 端311进行通信的支付处理器310。商家可以使用POS终端311 来进行金融交易，如向帐户持有人的借记卡添加资金。商家也可以与 支付服务器302建立单独的链接，以用于结算目的。
[159]结算引擎处理闭环系统内的交易，该闭环系统将实时地或 近乎实时地进行结算。在产生P2M交易时，用户的帐户和商家的基 本上同时更新。因为大多数商家也可以充当加载代理，因此，商家将 在他们的帐户中带有余额。结算引擎可以用于将预置的美元金额或通 过最低限度的美元金额转帐到商家持有的外部银行帐户。
[160]由于能够从一个注册的帐户持有人向另一个注册帐户持有 人划拨资金，结算引擎也便于个人之间的(P2P)交易。
[161]平台302进一步包括欺诈检测系统312，用于跟踪从每一 个金融交易中提取的信息。这样的欺诈检测系统是已知的，常常在使 用信用卡时用于监视欺诈行为。风险由一般规则引擎进行控制(参见 图3)，该引擎应用限制，并从风险的角度确定请求的交易的可接受 性。
[162]可以挖掘为每一个金融交易收集的信息，供商家以及消费 者增值应用程序、商业监视应用程序、系统操作应用程序和安全监视 应用程序使用，如313所显示的。为说明，销售引擎从参与的商家 向帐户持有人提供了赠券或折扣。此引擎还控制即时赊帐的使用，以 刺激注册。
[163]货币兑换模块用于国外业务，闭环支付系统中的价值度量 需要转换为其他货币。该模块还用于控制外汇兑换。
[164]病毒式引擎提供向未注册用户汇汇款的能力。此模块允许 帐户持有人汇款，还向收款人发送一则消息，说明为他们保留了一笔 资金，一旦他们进行了注册，将对他们可用。
[165]漫游功能提供了对等伙伴与商家的交易环境，其中，商家 使用移动电话来验证是否接收到资金，商家不能访问通常用于信用卡 或借记卡接受的终端。本发明的一个优点是由于不接受现金，资金有 保证，不像支票那样，是安全的，还提供即时验证，这是对于没有终 端的信用卡购物是不可行的。
[166]银行合作伙伴集成
[167]交易数据库308直接与合作银行维护的合并银行帐户 306集成在一起。所有资金都存放在此帐户内，虽然商家可以通过 ACH转帐，将他们的资金从他们的预存款贷记帐户转帐到其他帐户。 应了解，可以有一个以上的合作银行，以便每一个帐户都可以在一个 以上的银行链接到合并银行帐户。由于平台302知道每一个帐户的 可用余额(不管银行合作伙伴和合并帐户306的数量是多少)，当 进行同业银行间的结算时，没有资金不可用的风险。
[168]由于适用于销售合作伙伴，包括移动运营商、全国性品牌 商家和金融服务提供商，如较大的银行和信贷协会，支付系统基础架 构利用现有的移动基础架构和和消息传送技术，以提供低成本的，普 遍地可访问的金融服务。
[169]移动服务提供商合作伙伴
[170]通过给用户提供数字支付解决方案，移动服务提供商可获 得增量收益，以及更大的数据流量，以及竞争优势。与其他支付系统 不同，本发明可以提供给提供商的整个用户群体，因为它可以使用 SMS。
[171]此外，帐户持有人可以通过他们的预存款贷记帐户支付他 们的帐单或者到期支付(top-off minute)。这对没有其他金融服务可 用的帐户持有人特别有用。
[172]商家合作伙伴
[173]传统上接受信用卡、借记卡、支票，以及现金的各种商家 是被激发接受本发明的个体化支付转帐基础架构，由采用成本较低。 商家还有机会为处理预存款帐户交易，如帮助帐户持有人向他们的帐 户中添加资金，而获得佣金收入。大多数商家也可以提供少量的现金 退回，类似于当今使用的借记卡模式。
[174]银行合作伙伴
[175]通过本发明的系统，银行现在可以“移动”他们现有的用户 群体，因为可以快速访问他们的帐户，并能够进行帐户持有人与帐户 持有人之间的支付。利用此合作伙伴关系，银行也可以获得以前服务 起来太昂贵的消费者。不会产生建立银行而是遵循严肃的管理制度的 成本，本发明的一个实施例是使用参与银行的合并帐户实现的，其中， 系统处理正面的总帐，向其合作银行，或代表其合作银行，报告净部 位，但是允许银行进行最终结算。这将适应政府的规章，并允许与银 行环境积极的共存。通过使用合作银行和伴随的银行帐户，支付系统 基础架构被设计为只要有可能，增强帐户持有人的现有的银行帐户， 还在必要时充当单独的帐户。在为帐户持有人委托保管的商业银行帐 户中维护了由单个预存款贷记帐户代表的所有资金。在每一个工作日 结束时，所有帐户的合计的余额将等于银行余额。在一个实施例中， 在二十四小时的时间段内产生的所有交易将在该时间段内进行结算， 而在其他实施例中，结算时间段可以变化，可以，例如，每周、每月， 或任何常规的或不规则的时间段。帐户就像带有现金的钱包一样，余 额会立即变化。换句话说，本发明不充当其中可以由第三方出示金融 工具的活期存款。在至少某些实施例中，帐户持有人不能够发出诸如 支票之类的即期工具。结果，没有在未来的日期进行结算的待办交易， 再者确保了在任何交易中有良好的资金被提供到收款人。
[176]操作方法
[177]在本发明的一个实施例中，在购物之前，帐户持有人向预 存款贷记帐户中添加资金。可以通过使用移动电话或另一个电话，通 过利用因特网可访问的网站或通过联系客户服务代表，利用交互式语 音响应(IVR)向位于合作伙伴那里的预存款贷记帐户添加资金。在 一个实施例，用户能通过ACH或ATM网络，建立直接储蓄链接 或将一个帐户链接到银行帐户。资金可以从位于金融服务提供商合作 伙伴(如金融机构)那里的现有帐户转帐，或通过向预存款贷记帐户 (在参与的商家或其他第三方)存现或出示支票。然后，帐户持有人 可以通过他们的移动设备访问这些资金，以进行付款，他们也可以从 其他人那里接收支付，汇到它们的帐户中。在其他实施例中，资金可 以从指定的信用卡帐户转帐到预存款贷记帐户中。
[178]在另一个实施例中，来自每一个帐户持有人的资金被合并 在单一的金融机构中，每一个帐户持有人都在合并帐户中有等于存放 的资金减去转帐到另一个帐户再加上从其他人那里接收到的资金的 资金总数的利息。帐户持有人可以从合并帐户中提取一些或全部他们 的可用资金。
[179]在另一个实施例中，每一个帐户持有人都可以在任何金融 机构设立预存款贷记帐户，并间接地访问该帐户以划拨资金。如此， 帐户持有人不限于带有在特定金融机构中的合并帐户中维护的资金 的借记卡。相反地，帐户持有人可以访问他们选择的金融机构中的借 记卡帐户。
[180]在另一个实施例中，信用卡帐户被指定为主要帐户，每当 借记卡帐户中的资金下降到或低于某一个选定金额时，现金预付被移 动到预存款借记卡帐户中。
[181]在再一个实施例中，金融交易是在个人之间进行的，每一 方都通过电话号码和密码(例如，个人标识号，PIN)来进行标识。 或者，金融交易也可以通过用户名和密码来进行标识。在其他实施例 中，参与交易的至少一方通过条形码来进行标识。条形码可以显示在 诸如移动电话的屏幕之类的显示器上，并由大多数现代的移动设备上 具有的照相机进行检测。或者，条形码也可以打印在设备上，也可以 以别的方式附着于移动设备上。
[182]在一个特定实施例中，驻留在移动电话上的被称为移动客 户端应用程序(MCA)只要求帐户持有人拥有移动电话号码和预存 款贷记帐户。可选地，信用卡或支票帐户可以作为资金来源而被访问。 优选情况下，不需要诸如销售点终端之类的额外的硬件或因特网接 入。一个旦注册，帐户持有人拥有唯一个帐户持有人标识号码(PIN)， 以验证所有交易。在进行注册时，帐户持有人输入他们的移动电话号 码，服务器将移动客户端应用程序推到他们的电话中。一旦安装了移 动客户端应用程序，帐户持有人就可以开始使用移动电话来进行金融 交易了。或者，用户使用该用户的移动因特网浏览器访问特定URL (例如，get.obopay.com)，浏览器将开始移动应用程序的下载进程， 来下载该应用程序。
[183]帐户持有人也可以选择将他们的帐户链接到由金融机构 提供的借记卡或信用卡，这些卡可以世界范围内的数百万商家销售场 所使用。此外，通过链接到诸如NYCE网络ATM网络，帐户持有 人可以使用ATM，从他们的预存款贷记帐户获取现金。
[184]对于帐户持有人来说，达成金融交易是无缝的。在其中用 户设备是手机的实现方式中，只需通过从配备移动客户端应用程序的 移动电话向服务器发送一则消息即可进行资金转帐。支付服务器验证 每一个交易，并划拨资金，或响应帐户持有人的对帐户信息的请求。
[185]向服务器发送交易请求
[186]当帐户持有人从他们的移动电话发出交易请求时，信息被 路由到移动运营商，如Cingular或Verizon或其他移动电话服务提 供商。然后，信息通过安全的因特网连接，被路由到支付服务器。在 备选实施例中，信息是通过诸如无线网络、POTS或其他可用的网络 进行路由的。这种冗余是重要的，因为帐户持有人不限于单一访问路 径以控制他们的帐户和进行金融交易。取决于帐户持有人的位置或其 他情况，一个或多个通信路径可能不可用。然而，由于系统冗余，可 能至少有一个通信路径可用，金融交易将可以完成。
[187]取决于帐户持有人的移动电话，金融交易请求是以两种方 式中的一种进行传输的。如果帐户持有人拥有支持应用程序的电话， 该电话允许通过基于Web的应用程序(HTTP或HTTPS)或诸如 J2ME、.NET、.NET CF、WAP或SMS之类的移动应用程序或这 些应用程序的任何组合来传输金融请求，传输直接进入服务器。一旦 MCA与支付服务器建立连接，就发送请求消息。
[188]由于支持应用程序的设备当前只是当今所使用的设备的相 对较小的部分，因此，支付服务器也通过短消息服务(也被称为SMS 文本消息，或简单地，SMS)传输与接收，因为几乎所有的设备都支 持SMS。在此情况下，财务数据被路由到移动运营商，然后，被路 由到SMS综合器，该综合器实时地向支付服务器传输消息。
[189]SMS移动支付系统避免了与向手机中添加芯片关联的成 本和问题。在SMS系统的操作中，金融信息是使用SMS文本消息 进行发送的。尽管SMS文本消息适用于各种类型的蜂窝设备和某些 其他类型的移动通信设备，如便携式数字助理或PDA，但是，SMS会 暴露未加密的密码或个人标识号(PIN)，以及余额信息或有关最近的 交易的细节。由于拥有电话的任何人都可以阅读SMS消息文件并立 即知道如何访问另一个人的帐户，本发明的实施例不使用SMS消息 来发送PIN。相应地，在一个实施例中，本发明提供了通过SMS文 本消息启动金融交易。SMS消息以提供请求的交易的类型的关键字 开始—PAY、REQUEST PAYMENT、BALANCE、TRANSFER或 HELP。在一种实现方式中，“PAY”称为“SEND”，“REQUEST PAY” 称为“GET”。
[190]在SMS消息包含表示希望从一个帐户持有人向另一个帐 户持有人划拨资金的关键字的情况下，关键字将是pay或request payment(或，send或者get)。在关键字之后，输入金额，带有小 数点，也可以没有小数点。在金额之后，输入目标电话号码(或短代 码、电子邮件地址、驾照号码、或其他标识信息)。此信息可以从移 动设备的电话号码簿获得。在电话号码之后，帐户持有人可以输入向 对方显示的消息。在某些情况下，此消息可以是虚消息。在某些实施 例中，帐户持有人可以输入补充的消息，用于记录的目的。
[191]一旦SMS消息被发送到支付服务器，就可以由帐户持有 人输入PIN，并通过音频信道连接发送到支付服务器，以验证SMS 消息。PIN是通过键盘输入的，可以是任何字母数字代码。然后，PIN 被作为DTMF编码消息发送给支付服务器，其中，DTMF是指双音 多频，是当电话的接触键被按下时电话公司接收到的信号。
[192]在服务器上，支付服务器通过SMS文本消息通信路径接 收SMS消息，并通过音频信道接收PIN。对支付服务器的访问可以 由帐户持有人进行，也可以作为对接收到SMS消息的响应由支付服 务器作为“回叫”功能来启动。PIN可以作为DTMF编码的消息发 送，以维护安全性，但是，在其他实施例中，PIN可以由帐户持有人 说出，并由在支付服务器或专用于处理语音电话的另一个服务器(未 显示)上工作的交互式语音识别软件模块进行转换。
[193]在一个实施例中，移动设备包括移动客户端应用程序。移 动客户端应用程序要么由帐户持有人直接调用，要么响应移动设备上 的SMS文本消息功能的激活而调用。MCA确定发送PIN的最佳 方法。
[194]在一个备选实施例中，PIN由移动客户端应用程序进行加 密，并包括在发送给支付服务器的后续的SMS消息中。支付服务器 通过将电话号码和每一则消息的发送时间匹配来使消息关联。如果 PIN是在与SMS消息相比在时间上较远的消息中发送的，则可以拒 绝交易。如果只接收了两个消息中的一个，则可以拒绝交易。然而， 如果接收并验证了带有金融交易细节的SMS消息(至少有关键字) 和PIN代码，那么，进行金融交易。
[195]在另一个备选实施例中，当有音频信道可用时，移动客户 端应用程序调用将PIN编码为DTMF形式的模块。然后，DTMF 由移动客户端应用程序沿着由移动客户端应用程序建立的音频信道 连接发送到支付服务器。模块可以是基于小键盘的输入而生成适当的 音调的Java API。
[196]在又一个备选实施例中，移动客户端应用程序在移动设备 的显示屏幕上提供用户界面(UI)，引导帐户持有人进行金融交易。在 此实施例中，通过自动插入关键字、金额、目标电话号码、密码，以 及消息(如果有的话)，来引导帐户持有人完成构建SMS文本消息 的过程。
[197]在又一个备选实施例中，SMS消息可以包括关键字、金额、 目标电话号码和密码。此实现方式的缺点是，密码将对控制移动设备 的任何人都可见。然而，在这样的实施例中，此问题是通过向帐户持 有人发送消息来进行管理的，指示用户从SMS日志文件夹中删除发 送的消息。或者，这样的指示可以通过帮助和FAQ信息提供给用户。 这些指示也可以建议，当进行金融交易时，帐户持有人应关闭记录传 出的SMS消息的功能。
[198]下面的描述说明了使用SMS文本消息来使帐户持有人从 任何支持SMS的移动电话或其他支持SMS的设备访问支付服务 器。移动客户端应用程序不需要驻留在移动设备上，虽然如所讨论的， 将移动客户端应用程序安装到移动设备上具有很多优点。
[199]在操作中，帐户持有人使用他们的电话上的现有的文本消 息功能来向支付服务器发送文本消息。功能包括Pay(或Send)、 Request Pay(或Get)、Balance、History和Help，通过使用这些 功能中的任何一个作为关键字来调用这些功能。也可以有“引荐”或 “邀请”选项，以允许用户邀请他人加入到系统中。引荐人或被引荐人， 或两者，都可以被给予引荐奖金。帐户持有人在文本消息的正文中输 入关键字连同补充信息，以构建发送给支付服务器的命令。对支付服 务器的访问可以通过免费的电话号码、短代码或电子邮件地址来进 行，所有的这些都向SMS文本消息系统标识支付服务器。短代码的 一个示例是62729，被用作帐户持有人的文本消息命令发送到支付服 务器的目标电话号码。电子邮件地址的一个示例是 sms@obopay.com，这是发送给支付服务器的SMS文本消息命令的 电子邮件目标。
[200]要使用SMS方法向他人或商家进行支付，帐户持有人可 以输入表A所显示的命令字符串。
[201]表A
  关键字 PIN 目标移动电话号码 金额 消息(可选) pay ### ########## #.## Abed
[202]在某些方案中，每一项与前一项之间都应该有间隔。在一 种实现方式中，关键字不区分大小写。移动号码可以包括区号加移动 电话号码，在移动号码中没有空格。帐户持有人可以在电话号码中输 入引导1，或不输入。美元符号不需要与金额一起输入，但是允许输 入。可选地，用户可以与他们的支付一起包括一则消息。
[203]在一个备选示例中，通过话音呼叫在第二消息中发送PIN。 要使用组合的SMS加音频信道方法向他人或商家进行支付，帐户持 有人可以输入表B所显示的命令字符串。
[204]表B
  关键字 目标移动电话号码 金额 消息(可选) pay ########## #.## Abed
[205]PIN通过话音通信信道—即，蜂窝网络、因特网或POTS —发送到支付服务器。
[206]当使用SMS方法或组合的SMS加语音方法对帐户持有 人作出支付请求时，他们可以使用手动SMS文本消息系统来接受或 者拒绝该请求。
[207]在支付服务器端，一个或多个数据中心具有用于处理金融 交易的系统。每一个数据中心都包含PBX/ACD/VRU技术的组合， 以允许多个同时的呼叫处理。可以使用VRU技术来提供可编程入站 和出站DTMF支持。VRU可以连接到表示实际业务逻辑的企业 J2EE系统和记录金融交易的记录系统。然后，J2EE系统可以与用 于进行交易结算的实际银行集成。在一种实现方式中，为SMS安全 性，有一次性的密码选项来作为选项，这是，例如，通过让用户发送 交易而没有PIN来工作的，系统将给用户发送一系列问题让他们回 答。
[208]使用移动客户端应用程序(MCA)进行交易
[209]向另一个帐户持有人或商家汇款既便捷又简单。本系统简 化了批量支付，如从许多帐户持有人为一个慈善活动募捐，或同时从 同一个帐户持有人进行多个交易。
[210]帐户持有人与帐户持有人(个人之间的)交易
[211]从一个帐户持有人向跨房间、跨城镇、或跨国家的另一个 人汇款简单、方便、并且便宜。预存款的贷记帐户持有人可以向任何 支持SMS的手机帐户持有人汇款，即使他们的移动设备上没有安装 移动客户端应用程序或没有预存款的贷记帐户。如果收款人还不是帐 户持有人，则收款人接收一则SMS文本消息，指出已经有人以他们 的名称进行了转帐。为获得对这些资金的及时的访问，收款人进行注 册，以获得他们自己的预存款的贷记帐户。此“病毒式”消息使得非帐 户用户方便地自己成为帐户持有人。如果非帐户用户所使用的移动设 备支持WAP或移动因特网浏览器，那么，注册可以通过电话立即进 行。用户还具有使用Web、售货亭、亲自在商家合作伙伴那里或通 过另一个设备预定该服务的选项。
[212]本发明的灵活性可提供在交易中选择和标识各方的新颖的 方法。在一个实施例中，付款人通过他们的移动设备的小键盘键入电 话号码或其他标识码。标识码可以是特殊的三、四或五位“短代码”， 由移动服务提供商转换为特定帐户。例如，如果帐户持有人希望下载 电视网提供的电视节目，帐户持有人键入227的短代码，支付给该 网络，以获得所希望的内容。短代码可以使用任何字母数字字符序列。 在这样的方案中，收款人获得短代码以鼓励用户访问他们的服务是理 想的。
[213]在备选实施例中，资金的收款人可以通过从移动设备上的 地址簿功能中选择的电话号码来进行标识。如此，没有必要单独地输 入电话号码。在一种实现方式中，使用托管的地址簿，用户将利用服 务设置他们的地址簿，然后，他们将通过所使用的任何设备使用该地 址簿。要起初填充托管的地址簿，系统可以进入诸如Outlook、电话 个人信息管理器(PIM)地址簿之类的第三方地址簿，或诸如Plaxo 之类的第三方服务的界面。
[214]在又一个备选实施例中，付款人使用移动设备上的照相机 功能来获取标识收款人的图像。图像的一个示例是条形码。
[215]在又一个备选实施例中，付款人由收款人通过获取的图像 来进行标识。一个这样的获取的图像是显示在显示屏幕上或者可见地 固定在移动设备外部的条形码。
[216]在又一个实施例中，无论是付款人还是收款人都可以通过 诸如无线电频率识别设备(RFID)之类的近距离设备或近场通信 (NFC)设备来进行标识。
[217]帐户持有人与商家
[218]帐户持有人可以以多种方式提取资金或在合作伙伴商家那 里进行购物：
[219](1)移动电话与商家的移动电话；
[220](2)移动电话与商家销售点Web应用程序；
[221](3)预存款伙伴借记卡；
[222](4)通过向服务输入标识产品的代码字母数字显示用户希 望购物的商家；
[223](5)通过从商家的电子购物手推车或Web或移动应用程 序中选择进行支付；或
[224](6)通过从Web内或服务的电话应用程序内的目录中选 择产品。
[225]在本发明的一个实施例中，移动设备与一个或多个银行帐 户关联(支票、储蓄、信用卡、预存款，等等)，帐户持有人可以从 一个帐户实时地向另一个帐户划拨资金，无需对服务中心进行任何访 问，也无需任何因特网或计算机访问。优选情况下，帐户持有人可以 选择某个帐户，从该帐户中获取资金，以实时进行购物。
[226]在本发明的另一个实施例中，帐户持有人贡献于银行合作 伙伴持有的主帐户。在任何时间，帐户持有人都可以提取他们的全部 分担款项，没有任何损失。在某些方案中，主帐户是带有利息的，用 在该帐户上累积的利息对管理了支付系统的银行合作伙伴进行补偿。
[227]在另一个实施例中，使用NFC来在移动设备之间进行通 信以使用本发明的基础架构进行金融交易。在再一个实施例中，使用 NFC在移动设备与POS终端之间进行通信，以进行金融交易。
[228]有许多现有的产品，潜在地，有大量的新产品将受益于本 发明。例如，诸如VoIP电话之类的任何支持因特网的电话设备都可 以用来实施本发明，尽管可以固定在一个特定位置，不一定是移动的。 在其他实施例中，可以使用电子邮件地址作为电话号码的补充或代替 电话号码来标识参与金融交易的一方或多方。
[229]还应该理解，附图中所描述的一个或多个元件也可以以分 离的或集成方式来实现，或者甚至去除或在某些情况下不工作，可以 根据特定的应用场合来使用。
[230]对于移动、个体化支付转帐基础架构的营业收入模式
[231]运营移动个体化支付转帐基础架构，提供了产生收入来源 的机会，无需对商家参与其中的交易收费高昂的费用。应该认识到， 在移动或无线世界中，手机用户常常愿意购买一种小额包月费来获得 某些服务。相应地，通过对汇款的每次交易收取小额的费用来产生收 入。在一个示范性实施例中，对于选定金额(如$25)以下的交易， 每次交易费用几个美分。为进一步说明问题，在备选实施例中，“每 次交易”费用可以从$0.05到大约$0.10，虽然可以收取任何费用， 从每次交易小于一个美分到每次交易几个美元。例如，费用可以每次 交易从$0.00001到$10。
[232]费用可以向收款方和付款方两方面收取。或者，可以向汇 款的帐户持有人收取费用。在其他实施例中，可以收取交易金额的百 分比。在此实施例中，对于较高价值交易，如，举例说明，$25，收 取费用。优选情况下，在帐户持有人最后批准和授权进行汇款之前， 将费用通知，如果有的话，显示在批准屏幕上。在其他实施例中，对 于某些或所有交易，例如，对于小额交易，可以不收取费用。如此， 小使用支付转帐基础架构进行小额购物时，没有“每次交易”费用。
[233]不是支付“每次交易”费用，帐户持有人可以选择支付汇款 和收款的每月包月费用。在此实施例中，没有“每次交易”费用。每月 的收费可以变化，商家支付的费用比个人用户支付的费用要高一些 (或者，在某些情况下低一些)。
[234]相应地，本发明的实施例预期有多种不同的收入来源模式， 具体来说，(1)针对参与金融交易的一方或双方，评估“每次交易”。 优选情况下，费用金额从大约一个美分到大约$0.15；(2)包月收费， 每个帐户持有人都支付每月的服务费；(3)对于超过选定金额，如， 作为说明，$50，的交易，较高的交易费用，对于所有其他交易，放 弃费用；以及，(4)增值服务，如链接帐户服务，以自动地记录交易 细节或帮助准备提交税务报表。服务可以获得持有资金的浮动收益或 广告收入，这些可以适用于商家费用(例如，交易费用)。或者，或 另外，可以通过收取合并帐户的利息来产生收入。
[235]图4显示了本发明的系统的另一种实现方式。图4显示 了在两个帐户持有人之间使用增值服务的一个实施例。作为示例，如 果与移动设备401关联的帐户持有人启动一个向移动设备402的 转帐操作，则向服务器平台403传输支付请求，如引用箭头404所 示。支付请求可以包括支付事宜的可选描述。例如，帐户持有人可以 对支付事项进行批注，以表示它是支出帐商品。描述可以从显示在移 动设备401上的菜单中选择。或者，描述可以是与支付请求关联的 语音或文本消息。
[236]在接收到支付请求时，服务器403从付款人的帐户向与移 动设备402关联的帐户持有人的帐户划拨资金。通知管理合并帐户 405的金融机构发生了该交易，如引用箭头406所示。如此，资金 被添加到与移动设备402关联的帐户中，并从与移动设备401关联 的帐户。然后，金融机构发送一则确认，如引用箭头407所示。
[237]服务器平台403还向移动设备402发送支付的通知，如 引用箭头408所示。向移动电话401发送第二消息，指出已经进行 了支付，如引用箭头409所示。如果移动设备402的用户不是帐户 持有人，则可以开立新帐户，如引用箭头410所示。或者，用户可 以从指定的ATM或与管理合并资金的金融机构关联的其他设施提 取资金。
[238]然后，服务器平台403通过向帐户和记录服务411发送 交易金额和交易的描述，记录交易，如引用箭头412所示。此后， 帐户持有人可以要么通过移动设备401要么通过另一种因特网连接 (未显示)，访问由帐户和记录服务411存储和组织的描述他们的 购物情况的信息。
[239]当前系统还有助于更加自动化的计帐和会计过程。在现有 技术中，小企业使用记帐程序(可以存储在个人计算机上)，打印出 纸张发票，再将纸张发票寄给其客户。然后，客户必须支付给该小企 业，这在现有技术中，常常是通过支票进行的。一旦收到了支票，小 企业必须将帐号与支票关联。如果帐号没有写在支票上，并且发票的 副本没有与支票一起进行发送，则时间会浪费在尝试查找支付与发票 的副本的匹配。一旦匹配，小企业将支票存到他们的银行，并将数据 手动输入到他们的应收帐款记帐程序中。显而易见，这种老旧的过程 很慢，费力，支持起来昂贵。
[240]然而，利用本发明，小企业只需要选择一个开发票选项， 该选项将发票从记帐程序导出到，例如，OFX格式，或可由记帐程 序读取的其他导入/导出格式。然后，将此电子发票发送给支付平台(参 见图3)。支付平台创建发送给客户的“Request Payment”消息。当 客户批准发票的支付时，支付数据通过OFX被发回记帐程序的中， 并将资金放入小企业的帐户中。OFX消息将该项记入记帐程序中。 由于客户的应收帐款标识是他们的电话号码，因此，跟踪并记录简化 得多。应该指出的是，资金一路上都可以有保证，没有退回的支票， 或其他这样的问题。
[241]对于应付帐款交易，帐户和记录服务411发送OFX消 息，通过例图，说明了一个雇员的成本报销(T & E)支付。资金被转 帐到该雇员的帐户，并向他们的移动设备发送通知。优选情况下，本 发明省略了手动向记帐程序中输入每一次交易的过程。
[242]图5显示了移动的个人之间支付的系统的进一步的实现 方式。如上文所讨论的，本发明的特定实施例允许用户或客户端通过 Web(例如，通过因特网浏览器)、WAP(例如，通过移动电话、智 能电话、个人数字助理设备上的移动因特网浏览器)、SMS(例如， 通过移动电话的文本消息)、IVR(例如，从电话按键理解用户的语 音响应或音调的交互式语音响应系统)、WSDL(例如，可以通过诸 如智能电话之类的移动设备进行访问的万维网服务)与移动支付系统 连接。
[243]系统可以通过多个运营商中的任何一种，如Verizon、 Cingular(AT&T)、Sprint、Nextel、Alltel、Virgin Mobile、Amp′d Mobile、U.S.Cellular、T-Mobile及其他运营商与无线电话连接。本 服务也可以与预存款电话连接。移动运营商的一些优点包括：基于传 输或预订的收入共享模式；促进应用程序下载/购买；促进网络或数据 使用；促进SMS使用；启用“Off bill”支付解决方案，将帮助减轻惊 人的“big bill”问题。
[244]移动支付系统允许为用户提供许多不同的金融服务。一些 服务的示例包括信用卡加载、借记卡加载、自动票据交换所(ACH) 加载、ACH卸载、个人之间的(P2P)支付、远程支付(RPAY)、病 毒式、个人与商家之间的支付(P2M)，以及引荐。其他服务包括自动 柜员机(ATM)网络加载和卸载，如通过NYCE、PLUS，或STAR ATM系统。系统也可以包括帐单支付集成，其中，用户能通过他们 选择的界面，例如，他们的手机，支付帐单，如有线电视帐单、电费 单、因特网服务帐单、电话费帐单、家政服务帐单，及其他帐单。
[245]加载帐户是指将资金转帐到移动支付系统上的帐户，在那 里可以进行资金处理。例如，用户可以将资金从支票帐户或信用卡中 加载到用户的移动支付系统帐户，该移动支付系统帐户可以由金融合 作伙伴进行管理，或由移动支付系统的运营商进行管理。
[246]卸载帐户是指通过，例如，ATM网络，将资金从移动支付 系统转帐到另一个帐户，或直接转帐到帐户持有人。例如，用户可以 从用户的移动支付系统帐户向支票帐户或信用卡卸载资金。
[247]加载和卸载资金可以以本申请中所讨论的任何一种方式进 行，包括通过ACH、ATM，或信用卡或交换中心。ACH一般是最 便宜的，但是，ACH通常是实时的，因为资金是在在一天结束时以 批处理模式进行结算的。如此，当请求了ACH资金转帐时，实际资 金将不会被转帐，也不会对移动支付系统可用，直到当天结束时。对 于ATM和信用卡，资金转帐是实时的。ATM使用起来通常比ACH 贵一些，但是比信用卡便宜一些。注意，ATM和ACH两者都可以 用来访问用户的支票帐户。一般而言，信用卡在三者中使用起来是最 昂贵的。在一种实现方式中，本发明的系统允许从这些网络中的任何 一种网络加载和卸载。在另一种实现方式中，系统只允许从这些网络 中的一个或多个加载和卸载，如只从ACH，只允许ACH和ATM， 只允许信用卡，只允许ATM，只允许ATM和信用卡，或只允许 ACH和信用卡。
[248]移动的个人之间支付系统进一步为提供了一个或多个金融 合作伙伴提供了平台。这些合作伙伴可以包括让受方合作伙伴，如 Pay by Touch(PBT)、Verisign，或其他；银行或其他金融机构合作伙 伴，如纽约市、旧金山、圣何塞(加利福尼亚州)、伦敦、上海、香 港，或东京银行，电子银行，NYCE；直接的合作伙伴(如共同品牌 预存款卡)；预存款处理合作伙伴；以及ACH合作伙伴。移动支付 系统也可以与销售点(POS)系统连接。
[249]可以有上文所讨论的任何数量的合作伙伴和服务，以及任 何的组合。例如，系统可以没有合作伙伴，只有一个合作伙伴、有两 个合作伙伴，三个合作伙伴，或三个以上的合作伙伴。系统可以包括 只提供供移动客户端访问的借记卡(即，无信用卡)的单一银行合作 伙伴。系统可以包括提供供移动客户端访问的借记卡和信用卡的单一 银行合作伙伴。系统可以包括两个或更多银行合作伙伴，一个提供供 移动客户端访问的借记卡，另一个提供不同的借记卡。系统可以包括 两个或更多银行合作伙伴，一个提供供移动客户端访问的借记卡，另 一个提供不同的借记卡和信用卡。系统可以包括只提供供移动客户端 访问的信用卡的单一银行合作伙伴。系统可以包括只提供供移动客户 端访问的信用卡的单一银行合作伙伴。
[250]对于每一种类型的合作伙伴(例如，借记卡)，可以有多 个这样的与移动支付系统或网络连接的合作伙伴实体。例如，系统可 以与两个银行，银行A和银行B，或任意数量的银行合作伙伴连接。 系统可以具有本申请中所描述的合作伙伴的任何组合。例如，系统可 以具有直接的合作伙伴和银行合作伙伴，但没有预存款处理合作伙 伴。系统可以只具有预存款处理合作伙伴。系统可以只具有直接合作 伙伴。系统可以具有多个银行合作伙伴。
[251]每一个合作伙伴系统都可以具有不同的电子接口方案，移 动支付系统将对于每一个合作伙伴使用适当的应用程序编程接口 (API)进行通信。本发明的系统允许金融合作伙伴(例如，银行合作 伙伴、卡合作伙伴)方便地集成到移动及其他消费者合作伙伴(例如， 移动电话运营商)。
[252]在系统的特定实现方式中，让受方合作伙伴具有结算帐户。 银行合作伙伴具有合并帐户和往来帐户。直接合作伙伴具有合并帐户 和往来帐户。预存款处理合作伙伴具有合并帐户和往来帐户。ACH合 作伙伴具有结算帐户。移动支付系统可以提供合并帐户管理、跨银行 结算和资金管理，以及移动银行集成中的一个或多个。
[253]系统的资金通过所有合作银行的合并帐户的总和来表示。 通过与移动支付系统的商务关系，移动支付系统促进了定期资金管理 处理过程，以便合作银行的合并帐户保留的余额代表他们对移动支付 系统客户群体的贡献加上“其他”移动支付系统资金的同意的百分比。 客户的获取“路径”规定了给定合作银行的合并帐户余额(即，合作银 行通过“他们的”路径获得的客户越多，他们的关联的合并帐户的余额 就越高)。
[254]用户通常与特定金融合作伙伴(如特定银行)关联。在移 动支付系统中，每一个用户都将具有一个用户资料，该用户资料具有 该用户的设置。这些参数可以包括(1)参与的级别，(2)哪一个处理 器(例如，哪一个金融合作伙伴)，(3)速度设置，(4)链接的帐户， 或这些设置的任何组合。本系统可以在用户资料中包括任意数量的参 数设置，比本专利申请中所描述的多一些，或少一些。
[255]本发明的系统适用于任意数量的不同的金融合作伙伴(例 如，1、2、3、4、5、6、7、8、507、1001、2054、3096，或更多)， 每一个合作伙伴都可以具有不同的API接口。在每一个用户资料中， “哪一个处理器”设置将指出用户与哪一个金融合作伙伴关联。当为该 用户进行交易时，系统将知道把交易指向哪里(哪一个银行)以及使 用哪一个API，以便用户的价值交换交易(通常是金钱交换)被正确 地处理。
[256]“参与的级别”设置是用户将具有的特权或服务级别。“参与 的级别”设置可以基于若干个因素，如当用户进行注册时提供了什么 信息，用户在他的帐户中有多少钱，用户进行了多少次引荐，用户已 经进行了多少次交易，或所交易的美元的总金额数。此配置文件的设 置可以随着收集到新的信息而定期更新。用户的参与的级别名称的一 些示例可以是“铜”、“黄金”、“银”，以及“白金”级别。可以使“参与 的级别”对用户可见，并可以用来构建顾客忠诚度。在本发明的其他 实施例中，可以隐藏参与的级别，或以别的方式对用户不可用。
[257]当向系统进行注册时，系统将给用户提供用户希望透露多 少信息的选择。例如，用户可以选择透露用户的移动电话号码，然后， 用现金给用户的帐户存放资金。在至少某些实施例中，这是开立帐户 所需的最低限度。将给用户提供其他信息的选项，如电子邮件地址、 信用卡号、社会保障号码(例如，用于信用审核)、支票帐户号码等 等。在本发明的一种实现方式中，用户选择透露的信息的量的多少对 应于给予用户的参与级别的高低。
[258]在一种实现方式中，对于参与级别的设置，用户可以是下 列四种用户状态之一：(1)邀请、(2)注册、(3)验证，以及(4)高级。 在其他实现方式中，可以有额外的状态。对于邀请状态，用户已经引 荐，或给其发送了“病毒式”资金。“病毒式”是指汇款或接收汇款，其 中，某一个用户以前没有向系统进行注册。“病毒式”用户也可以简称 为非会员用户或未注册用户。“病毒式”是指本发明的移动支付系统的 一个特征，该特征鼓励或允许当前用户与非会员用户进行交易。随着 越来越多的用户进行注册并使用系统，用户将帮助扩散新闻，并带进 另外的用户。例如，为了使非会员用户收到资金，将鼓励非会员进行 注册，或者非会员必须进行注册，才能成为会员。
[259]对于注册状态，用户已经输入基本信息，如确认的电话。 电话可以由系统以任何合适的方式进行确认，包括拨打由用户在进行 注册时所提供的电话号码。此呼叫可以是自动化的或IVR型呼叫。 对于用户进行注册，可以有奖励，如用户得到放进该用户的帐户中的 现金(例如，$5)。奖励可以简称为引荐奖金，并可以是任何金额。 引荐奖金可以只支付给引荐人，只支付给被引荐人，或向两者都支付。 一旦注册，用户可以收到和索取资金。
[260]对于验证状态，用户的身份是已知的。用户提供地址或其 他相关的联系信息。用户在验证状态下可以收到、请求、添加(即， 加载)或提取(即，卸载)资金。
[261]对于高级状态，用户已经提供了用户的社会保障号码。在 此状态下，例如，用户可以向特定银行合作伙伴进行注册，以接收诸 如预存款借记卡之类的卡。在其他实施例中，卡可以是信用卡。在此 实现方式中，高级状态用户将能够做验证用户所能够做的一切，外加 能够立刻在接受卡的任何地方进行消费。取决于发放卡的机构，可以 通过一个或多个网络，包括Visa、MasterCard、American Express、 NYCE、PLUS或STAR，或这些机构的任何组合，接受或使用卡。 卡链接到用户的帐户。没有卡的用户可以叫做无卡用户，而有卡的用 户可以叫做有卡用户。
[262]当进行注册时一个人可以获得验证的一些方式包括：对于 个人信息，系统可以要求提供地址和驾驶执照号码。一种备选方案是 要求提供地址和社会保障号码。可以对照诸如Equifax数据库之类 的信用报告机构的数据库，核对该信息。可以使用质询储蓄来对链接 的银行帐户进行验证。例如，系统可以将若干个小额存款放入用户的 帐户中。用户告诉系统那些存款的金额，作为他们被授权使用链接的 帐户的验证。或者，用户能通过在线即时帐户验证来进行验证，其中， 用户提供在线的屏幕姓名和密码。对于添加信用卡或借记卡，也可以 使用质询储蓄来进行验证。诸如Visa和MasterCard之类的一些卡 也可以使用安全代码等等来进行验证。
[263]参与的速度是对帐户设置某些限制的一种设置。对帐户设 置的限制的一些示例有：用户一天可以进行多少次交易，或在一次交 易中最多可以转帐多少金额。可以使用硬性限制和软性限制，其中， 硬性限制将不会随第三方的干涉(如人更改限制)而变化。软性限制 可以随着用户的操作而变化。例如，在用户已经成为会员六个月之后， 当用户的前一限制是小于5的某个数字时，可以自动地允许用户一 天可以进行五次交易。
[264]通常，用户将不会访问到或知道参与速度的设置。然而， 在某些实现方式中，可以告诉用户有关参与速度的信息，如信用额度 或交易限制。
[265]链接的帐户是可以存储在用户的资料中的另一个功能。然 而，本申请中所讨论的任何一个用户设置，或这些用户设置的组合， 可以保存在单独的位置，不一定放在用户的资料中。链接的帐户是系 统的一种功能，其中，用户的多个身份被集中到或统一到单一帐户中。 在典型的方案中，对于用户，有一个锚定(例如，如帐号)，多个另 外的身份与此锚定关联。这些身份可以包括多个电话号码、电子邮件 地址，即时消息标识符，等等。用户将不必知道帐号或锚定，即可访 问该帐户。用户能够通过任何一个关联的身份访问用户的帐户。
[266]此外，在一种实现方式中，要向帐户添加身份，用户要证 实每一个新的身份。这可以通过IVR回叫来进行，或在采用电话号 码的情况下响应SMS消息。对于电子邮件，可以通过发送一个带有 唯一URL或验证码(用户在我们的网页上以此作出响应)的电子邮 件来进行。对于即时消息ID，可以通过响应IM来进行。
[267]用户的资料中可用的其他选项可以包括某些功能的首选项 设置。可以由用户在任何时间通过访问帐户维护屏幕，来设置或修改 这样的选项。此外，还可以询问用户在注册流程(参见下文)中是否 启用或禁用选项。一个功能是自动接受和手动接受功能。当自动接受 被打开时，汇往此会员的支付款项将自动地被接受。当手动接受被启 用时，汇往此会员的支付款项需要手动地接受或拒绝。
[268]系统流程
[269]图6显示了在同业银行的个人之间的支付。此图显示了一 个消费者A向另一个消费者B汇款，其中，这两个消费者都是同 一个银行合作伙伴A的会员。本发明的移动支付系统将处理该交易。
[270]交易的基本流程是：(1)消费者A向移动支付系统发送 支付请求。此支付请求可以通过此专利中所讨论的任何一种方式来发 送。(2)移动支付系统更新移动支付系统的记录系统(SOR)中的“T” 或交易记录中，以反映交易。这些交易记录是由移动支付系统进行管 理的。(3)系统(例如，Obopay)将支付情况通知给消费者B。这可 以通过电子通知、电子邮件、即时消息、SMS消息，或其他通知来 进行。
[271]图7显示了跨银行个人之间的支付的一种实现方式。此图 显示了消费者A向消费者B汇款，其中，这两个消费者是不同的 银行合作伙伴的会员。消费者A在由银行A进行管理的帐户中有 资金，而消费者B在由银行合作伙伴B进行管理的帐户中有资金。 本发明的移动支付系统将处理该交易。
[272]交易的基本流程是：(1)消费者A向移动支付系统发送 支付请求。(2)移动支付系统从银行A合并帐户向银行A往来帐户 划拨资金。(3)移动支付系统从银行B往来帐户向银行B合并帐户 划拨资金。(4)移动支付系统更新移动支付系统的记录系统中的T记 录，以从消费者A的帐户中划出，并划入消费者B的帐户。(5)移 动支付系统将支付通知给消费者B。(6)移动支付系统定期在合作银 行A和B之间进行结算。此结算可以以任何时间周期进行。结算 可以不实时地进行，而是以批处理模式进行。例如，可以每隔24小 时进行一次。周期不一定必须是相等的时间周期，而可以是不同的时 间周期。还应该理解，顺序可以变化，特别对于划出、划入，以及通 知步骤。例如，在备选方案中，可以对消费者A的帐户中的资金进 行预留，通知消费者B，然后，进行资金转帐。特定顺序并不重要， 只要可以保证在每一个步骤中存在良好的资金。
[273]图8显示了链接的帐户加载。此图显示了消费者利用另一 个来源的资金向用户的移动支付系统帐户加载的情况。例如，用户可 能希望从支票帐户或信用卡向用户的移动支付系统帐户中转移资金。
[274]此交易的基本流程是：(1)消费者A向移动支付系统发 送“加载”请求，指出将要链接的信用或贷记工具中取出资金。(2)(a/b) 移动支付系统提交实时信用卡(CC)/DDA交易(良好的资金)。(3)移 动支付系统从往来帐户向合并帐户划拨资金。(4)移动支付系统更新 移动支付系统的记录系统中的消费者A的T记录。(5)移动支付系 统定期进行财务管理。此管理可以以任何时间周期进行。例如，可以 每隔24小时进行一次。如上所述，周期不一定必须是相等的时间周 期。
[275]图8还显示了信用卡加载的具体示例。从Web中，用户 输入信用卡号，以将$300加载到用户的MPS卡中。MPS从，例 如，Pay-By-Touch(PBT)获取$300的信用卡交易的授权。MPS向 支持MPS卡的金融合作伙伴发送一则消息，启动从MPS信用卡帐 户到用户的借记卡帐户的$300的个人之间的支付。将资金立即划入 用户的帐户。PBT对信用卡交易进行结算，并向位于处理结算帐户 的MPS的银行的MPS结算帐户转帐$300 ACH。MPS向MSP 信用卡主帐户转帐$300 ACH，以补充资金。
[276]图9显示了链接的帐户卸载。此图显示了消费者将资金从 用户的移动支付系统帐户卸载到另一个帐户的情况。例如，用户可能 希望从用户的移动支付系统帐户向用户的支票帐户、信用卡，或其他 帐户转移一些资金。
[277]此交易的基本流程是：(1)消费者A向移动支付系统发送 一则加载请求，指出链接的信用工具作为目标。(2)移动支付系统提 交实时DDA交易(良好的资金)。(3)移动支付系统从合并帐户向 往来帐户划拨资金。(4)移动支付系统更新移动支付系统的记录系统 中的消费者A的T记录。(5)系统定期进行财务管理。
[278]在特定实施例中，本发明涉及支付系统，具体来说，在特 定实施例中，涉及使用移动电话进行支付的在线系统。
[279]如前面所讨论的，在本个人之间的支付系统的至少某些实 施例中，支付系统的现有的会员可以可以向非会员(也可以简称为未 注册用户)进行支付，以希望非会员成为会员。支付系统的这种能力 可以称为“病毒”，因为它能促进新的会员注册。病毒功能的一些元件 包括下列各项，没有按任何特定顺序列出。
[280](1)支付系统允许现有会员通过一些唯一标识符或“ID”向 非会员汇款。此唯一标识符可以普遍地使用。这样的标识符的一些 示例包括电子邮件地址、电话号码(例如，陆上通信线路、IP电话、 移动电话、寻呼机或传真机)、社会保障号码、帐号、汽车牌照号码， 即时消息用户名，及其他。标识符可以由用户进行选定，如非会员选 择一个电话号码或电子邮件地址。
[281](2)支付系统通知现有的会员，他们即将要与其进行“汇款” 交易的人是非会员，并给予现有的会员取消此交易的机会。
[282](3)在现有会员选择向非会员汇款的情况下，支付系统通知 非会员，已经向他们汇了款。通知可以通过任何一种常见的通信机制 (如电子邮件、语音，SMS、IM，及其他)来进行。
[283](4)支付系统应该允许“被邀请”非会员接受或拒绝从现有 会员尝试转帐的资金。
[284](5)如果被邀请的非会员决定从现有的会员接受资金，那 么，支付系统提供让非会员也是通过常见的通信机制(如电子邮件、 语音、SMS、IM，及其他)进行注册的能力。
[285](6)为了完成病毒式交易，支付系统最终将促进从现有的会 员的帐户向新的会员的帐户转拨资金。
[286]下面是用于在支付系统内进行病毒式资金转帐的技术的多 个实施例。在下面的示例中，Obopay被用作特定支付系统的示例， 但是，也可以使用其他支付系统。支付系统可以叫做任何名称。特别 指出了obopay.com网站，但是，可以使用任何适当的网站、网站名 称，或IP地址。此外，本发明也可以用于其他网络基础架构的环境 中，而不只是因特网。这些示例是对前面所讨论的示例的补充。
[287]实施例1A-自动资金划拨
[288]未注册的用户B的帐户在作为下面的步骤的结果进行注 册时自动地被注入资金：
[289]1.现有会员用户A决定通过给用户B汇款来邀请非会 员用户B加入，其中，B必须通过注册为会员才能接收款项。
[290]2.用户A通过插入用户B的移动电话号码和美元金额， 向用户B发送支付交易。系统最初不会区别向会员和非会员的支付。
[291]3.如果移动电话号码不是发往当前会员的，则用户A接 收到下列消息，“注意：您的会非会员的支付待办。”
[292]4.用户A还接收到如下表述的电子邮件：“感谢您的引 荐。”我们已经联系您的朋友并邀请他向我们的系统进行注册。”
[293]5.向用户B的汇款金额从A的帐户中划出，并被保留， 等待用户B的注册。
[294]6.用户B接收到一则消息，说明用户A向他汇了款，用 户B可以通过在obopay.com进行注册而获得资金。
[295]7.用户B在支付系统网站或其他界面进行注册。
[296]8.在用户B成功地进行注册之后，用户B的帐户自动地 被注入了用户A的转帐资金。
[297]实施例1B-请求支付
[298]图10显示了支付系统和个人之间的支付，其中，非会员 用户必须在进行注册时请求提供的支付，如下面的步骤所描述的。
[299]1.现有会员用户A决定通过给B汇款来邀请非会员用 户B加入，B必须通过注册为会员才能接收款项。
[300]2.用户A通过插入用户B的移动电话号码和美元金额， 向用户B发送支付交易。系统最初不会区别向会员和非会员的支付。
[301]3.如果移动电话号码不是发往当前会员的，则用户A接 收到下列消息，“注意：您的转帐已经发给非会员用户。您愿意我们 邀请他们加入吗？是/否。”
[302]4.如果步骤3的回答是yes，则用户A还接收到如下表 述的电子邮件：“感谢您的引荐。我们已经联系您的朋友并邀请他向 我们的系统进行注册。”
[303]5.支付金额不会从用户A的帐户划出。
[304]6.用户B接收到一则消息，说明用户A已经邀请用户B 加入系统，以便用户A可以给用户B汇款。
[305]7.用户B在系统网站或其他界面进行注册。
[306]8.在用户B成功地进行注册之后，通知用户B，用户A 希望给他汇款，用户B可以对该支付执行“Request Pay”。如果用户 B同意，则给用户B显示一个预先填写的Request Pay交易，带有 A的电话号码，以及原始支付金额。
[307]9.用户A接收到“Request Pay”，并同意该支付。
[308]10.从用户A的帐户划出资金，并划入用户B的帐户。 通知给用户B。
[309]实施例2—个人预留资金病毒式—允许现有的会员留出 资金，这是为“病毒式”支付预留的。例如，用户可以拨出用户的帐户 中的一定数量的美元，以进行“病毒式”交易。这些资金将不会可用于 “非病毒式”交易(例如，通过借记卡进行花费)。在一种实现方式中， 用户能通过用户帐户维护功能更改预留的金额。
[310]实施例3--会话病毒式—实时地出现完整的病毒生命 周期，将沿途的另一个人的“步骤”通知给双方。然后，最终的资金转 帐只是两个会员之间的转帐。
[311]实施例4—约定的病毒式—现有的会员承诺支付被邀 请的会员(如果他们注册，并且当他们注册时)。现有会员的资金将 被预留，以便一旦被邀请的会员注册，进行后续支付。
[312]实施例5—分离资金病毒式—支付系统，通过提供资金 拆分，剌激现有会员，以进行病毒式支付，其中，支付系统通过固定 的或相对金额，匹配支付金额。
[313]实施例6—请求资金病毒式—不是现有的会员向非会 员汇款，而是现有的会员从非会员请求汇款。
[314]实施例7-协商-现有用户A希望向非会员用户B汇 款。用户A使用用户B的合适的标识符来请求进行汇款。通知用 户B有待办的支付，并邀请用户B注册为会员。此外，给用户B提 供与用户A协商交易的一个或多个条款的选项。可协商的条款可以 包括转帐的金额、将开立帐户的银行，引荐费的分配，等等。在备选 方案中，用户A被允许选择哪些条款他们将愿意与用户B进行协 商，部分地鼓励用户B进行注册。
[315]本发明的实现方式可以包括上文所描述的功能中的任何一 种。在本发明的系统中，可以分别地或与任何其他实施例相结合地实 现上面的实施例。
[316]特定实现方式描述了使用移动电话号码作为用户的标识 符。然而，对于每一个用户，可以使用任何标识符，如任何电话号码 (例如，家庭电话号码、办公电话号码、IP电话电话号码、传真机 或寻呼机)，电子邮件地址、即时消息用户名、社会保障号码、驾驶 执照号码、会员号码、信用卡号、借记卡号码，或其他。
[317]讨论了电子邮件作为在用户之间发送消息的技术，但是， 也可以使用其他通信技术，包括语音邮件、自动化语音消息、即时消 息，或文本消息。用户A和用户B只作为系统可以具有的很多用 户中的两个代表。本发明的系统可以具有任意数量的用户。
[318]图1显示了一个概述方框图，该方框图描述了利用本发明 的两个或更多人之间的移动支付系统。在本发明的系统的一个实施例 中，用户A通过唯一标识符或ID向用户B汇款。唯一标识符可 以普遍地使用。示例包括电话号码(例如，陆上通信线路、IP电话、 移动电话、寻呼机或传真机)、电子邮件地址、社会保障号码、帐号、 汽车牌照号码，即时消息用户名，及其他。此标识符可以用来联络用 户，独立于经过本发明的系统(例如，电话号码或电子邮件地址，可 以直接联系用户，而不涉及本系统)。
[319]每一个唯一标识符都可以只与一个用户关联，以确保帐户 和系统安全性。用户A也可以提供金融交易的细节，如要转帐的金 额，或支付的形式，或这些细节的组合，如果请求验证帐户，则还应 提供PIN号码。
[320]系统将用户A标识为会员，在某些实现方式中，检查PIN 号码，验证帐户，并检查用户A的帐户的余额。在用户A的帐户 没有足够的资金进行金融交易的情况下，系统向用户A发送一个电 子通知，说明资金不足。如果用户A的帐户具有足够的资金进行交 易，则系统还通过任何合适的链接(包括移动技术)将待办的交易通 知给用户B。由于用户A和B接收到的即时的电子通知，他们将 感觉到，金融交易几乎即刻，或实时地或近乎实时地进行。
[321]在一个实施例中，系统可以允许用户设置有关交易的接受 的首选项。如果用户B选定了自动接受设置(当用户在系统上进行 注册时选定)，用于自动地接受支付，资金立即从用户A的帐户转 帐到用户B的帐户。如果用户B选定了手动接受设置，则只有在 用户B批准交易之后才转帐。系统也可以包括用户规定他们将只从 指定的会员接受交易，或者相反，他们将不会从指定的会员接受支付 的设置。
[322]如果在由系统设置的一定天数(如三十天)之后用户B还 没有批准交易，则系统的至少某些实施例可以被配置为自动地取消交 易。在这样的方案中，系统向用户A和用户B两者发送电子通知， 通知他们，交易已取消。用户B也可以具有拒绝交易的选项，在这 样的情况下，通过电子通知，通知用户A，拒绝支付。
[323]在用户A具有足够的资金的情况下，用户B接受交易， 从用户A的帐户划出该金额，并划入用户B的帐户。在某些实施 例中，取决于维护帐户的方式，由于电子金融交易系统中的固有的延 迟，交易的完成会被延迟。
[324]在本申请中呈现了一些流程的具体示例。然而，应该理解， 本发明不限于这里呈现的特定流程和步骤。本发明的流程可以具有在 本申请中不一定描述的另外的步骤，替换呈现的一些步骤的不同的步 骤，较少的步骤或呈现的步骤的子集，与呈现的步骤的顺序不同的步 骤，或这些情况的任何组合。
[325]此外，本发明的其他实现方式中的步骤不必与所呈现的步 骤完全相同。作为具体示例，为了说明起来方便起见，采用的是用户 B的移动电话号码作为唯一或电子标识符(ID)的。在本发明的其他 实施例中，标识符不限于用户B的电话号码。或者，标识符可以是 用户B的即时消息用户名、电子邮件地址，或任何其他合适的标识 符。
[326]在不偏离本发明的范围的情况下，流程中的可能的变化的 另一个示例是，用户A和B在流程中的各种步骤中接收到的特定 消息。在本发明的其他实施例中，这些消息可以不同于在本申请中特 别指出的那些消息，或者，一些消息将不会被发送，并且这些消息可 以组合起来。
[327]图11显示了用于在有卡会员和未注册用户之间进行交易 的方法的实施例。此流程包括下列步骤：(1)会员A以非会员B作 为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标 识交易源A为会员，对会员A的帐户进行验证，检查余额，并检 查PIN。(3)移动支付服务识别目标为非会员。(4)移动支付服务将 支付通知给源会员A。(5)移动支付服务将支付通知给目标非会员 B。(6)(a/b)移动支付服务从会员卡帐户中划出，并划入病毒式合并 帐户。(7)(a/b)移动支付服务记录源会员划出交易，并记录目标病毒 式划入交易。步骤6和7可以是异步的服务器端线程。这意味着， 在一个实施例中，这些操作异步地进行。服务器请求操作，但是它们 不一定由服务器本身执行，如此，操作的完成独立于调用方服务器进 程。
[328]图12显示了用于在无卡会员和未注册用户之间进行交易 的备选方法。此实施例包括下列步骤：(1)会员A以非会员B作 为目标，向移动支付服务服务器发送“pay”请求。(2)移动支付服务标 识会员A为会员，对他的帐户进行验证，检查他的余额，并检查他 的PIN。(3)移动支付服务识别目标为非会员。(4)移动支付服务将 支付通知给源会员A。(5)移动支付服务将支付通知给目标非会员 B。(6)(a/b)移动支付服务从会员合并帐户中划出，并划入病毒式合 并帐户。(7)(a/b)移动支付服务记录源会员划出交易，并记录目标病 毒式划入交易。步骤6和7可以是异步的服务器端线程。
[329]图13显示了在一个无卡会员和另一个无卡会员之间进行 交易的方法。此实施例的流程包括：(1)会员A为会员B发送 “pay”请求。(2)移动支付服务标识交易源A为会员，对帐户进行验 证，检查余额，并检查PIN。(3)移动支付服务识别目标B为会员， 并对帐户进行验证。(4)移动支付服务将支付通知给源会员A。(5)移 动支付服务将支付通知给目标会员B。(6)(a/b)移动支付服务记录会 员A划出交易，并记录会员B划入交易。步骤6可以使用异步服 务器端线程进行。
[330]图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可以是异步的服务器端线程。
[331]图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可以是异步的服务器端线程。
[332]图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可以是异步的服务器端线程。
[333]图17显示了对未注册的用户进行注册的方法。该流程包 括：(1)未来的会员A提交注册请求。(2)创建新的会员帐户。(3)对 于新的会员，进行身份风险控制，并相应地更新帐户。(4)检查与新 的会员关联的病毒记录。(5)(a/b)移动支付服务从病毒式合并帐户中 划出，并划入会员合并帐户。(6)(a/b)移动支付服务记录源病毒式划 出交易，并记录目标会员划入交易。(7)检查适用于新的会员的奖励。 (8)(a/b)移动支付服务从奖励帐户中划出奖励金额，并划入会员合并 帐户。(9)移动支付服务记录新的会员划入奖励金额。步骤5、6和7 可以是异步的服务器端线程。
[334]图18显示了激活对会员的帐户发出的卡的方法。该流程 包括：(1)会员A收到邮寄的卡，并拨打“移动支付服务”IVR，进 行激活。(2)在IVR交互过程中，移动支付服务关闭无卡帐户。(3) (a/b)移动支付服务从会员合并帐户划出，并划入新的会员A个人卡 帐户。(4)(a/b)移动支付服务记录会员合并帐户划出交易，并记录会 员A划入交易。(5)移动支付服务系统向会员A发送关闭无卡活动 声明电子邮件。步骤3和4可以是异步的服务器端线程。
[335]在一种实现方式中，系统处理近距离的电子支付，如通过 使用NFC、蓝牙、RFID、红外光束、LED光束，或其他近场技术。 例如，会员A和B身体彼此靠近，他们希望进行电子支付。这可 以是消费者与消费者或消费者与商家之间的情况。同样，交易可以是 汇款、收款，或任何其他资金转帐情况。
[336]这样的交易的基本流程是：(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)支付交易开始。
[337]系统允许多渠道和跨渠道交易。具体来说，可以从任何一 个可用渠道(例如，移动电话、即时消息、电子邮件、Web、借记卡、 WAP、SMS、消息，或专用的移动电话应用程序)请求进行支付，交 易可以是指向任何一个可用渠道，以任何组合。例如，某人可以从即 时消息向移动电话，从Web向移动电话，从移动电话向即时消息， 从WAP向即时消息，从即时消息向电子邮件，从电子邮件向移动电 话，从电子邮件向即时消息，从Web向SMS，从SMS向电子邮 件，或任何其他组合，请求进行支付。本系统也可以用于通过支付终 端、交互式网站进行支付，通过电视为服务或媒体内容进行支付(例 如，为由有线电视或卫星提供商提供的点播电影进行支付)，通过预 存款电话，以及许多其他手段进行支付。例如，用户能通过即时消息 支付给商家。本系统可以支持通过自动售货机、停车计时器、售货亭、 自动收费公用电话、飞机票售票亭，以及许多其他手段进行支付。
[338]在特定实现方式中，移动支付系统不允许现有的注册的用 户从未注册的用户请求进行支付。在另一个实施例中，用户被允许从 未注册的用户请求进行支付。
[339]下面的流程A显示了在注册的用户(用户A)和未注册 的用户(用户B)之间进行交易的一种实现方式。
[340]流程A
  步骤 操作 1 现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话 号码向移动支付系统发送一则消息和交易金额。                     2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3       如果资金不足，则给A发送一则消息：  “资金不足。                     [tel #]，[value]，[trans #]”        B不会接收到消息。                如果有足够的资金，则进入下一步骤。 4       检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有被识别为 注册的用户，则A接收到下列消息：                                    “您的请求已经被接受，将被处理。                                   [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的帐户中的交易金额的预留。 8 B向移动支付系统进行注册。在系统上为B创建一个帐户。 9   在B成功地注册之后，通知B，说明A希望给B汇款。给B提供了一个画    面，询问B是接受A的支付，拒绝A的支付，还是请求对A的待办交易进 行更改。                                                     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 #]”                                       14    如果A有足够的资金，将给A发送消息： “支付已被接受。                   [tel #]，[value]，[trans #]”          15 从A的帐户划出交易金额，并划入B的帐户。
[341]在上面的步骤1中，用户A通过用户B的移动电话号 码向移动支付系统标识用户B。在本发明的其他实现方式中，用户A 可以通过其他手段，如用户B的电子邮件地址、即时消息名称，或 其他唯一标识符，来标识用户B。这些标识符可以是电子标识标识符， 可以是也许用于甚至在移动支付系统的环境外面标识B的标识符。 换句话说，标识符不一定只有移动支付系统才有的(例如，帐号)。
[342]在步骤2中，移动支付系统检查A的帐户是否具有足够 的资金来完成交易。移动支付系统也可以执行PIN和帐户验证或其 他验证步骤，以确保A的帐户没有被暂停，具有足够的资金等等。 为清楚起见，这些步骤在上面的流程中被省略。
[343]在步骤3中，移动支付系统通过SMS消息通知用户A， 资金不足。在本发明的另一个实施例中，用户A可以通过其他技术 接收此消息，如电子邮件、SMS消息，或其他形式的移动通信。在 本发明的某些实施例中，用户可以根本不必接收此消息，如当用户A 决定并向系统指出不接收这样的消息时。该流程也可以应用于电子邮 件支付系统或其他支付系统，移动的，非移动的(即，移动电话不参 与交易的情况)，或别的样式的。
[344]在步骤4中，移动支付系统确定用户B是未注册的，并 将这一情况通知给用户A。在本发明的另一个实施例中，系统可以允 许用户A向用户B发出支付，不管用户B的未注册的状态，如此， 可以跳过此步骤。
[345]在步骤5中，移动支付系统在A的帐户上预留该交易金 额。交易金额不会从A的帐户中划出，直到该交易在步骤15中划 出。
[346]在步骤6中，由移动支付系统给未注册的用户B发送一 则消息，请求用户B向系统进行注册。此消息可以通过SMS消息、 电子邮件、MMS消息、即时消息，或其他形式的移动通信发送到用 户B的移动电话中。
[347]在步骤7中，给用户A提供能够在用户B接受支付之 前取消支付的选项。系统也可以被配置为，如果在用户A进行支付 之后并且用户B接受支付之前已经过去了30天以上，则支付自动 地失效。交易自动地被取消的天数可以变化。例如，天数可以是任何 数字，如5、10、14、15、16、21，或多于或少于30。取决于实现 方式，用户A和B不必收到通知他们交易已取消的消息。
[348]在步骤8中，在用户B进行注册时，系统为用户B创 建帐户。在本发明的另一个实施例中，系统可以不要求用户B向系 统进行注册，而是可以自动地将系统链接到用户B的一个银行帐户。
[349]在步骤9中，只有在用户B向系统进行注册之后，才 给用户B发送有关用户A请求发出支付的消息。在本发明的另一 个实施例中，用户B接收有关用户A的支付的消息，无需向系统 进行注册。
[350]在当前实施例的步骤10中，给用户A发送有关用户B 取消交易的SMS消息。在本发明的另一个实施例中，系统给用户A 发送不同的消息，可以通过其他形式的移动通信发送。
[351]在步骤11中，给B提供了以某种方式更改或修改交易的 选项。在一种实现方式中，给用户B提供了“是”按钮、“否”按钮， 以及“请求更改”按钮。或者，“请求更改”按钮可以称为“协商”按钮， 因为通过提供更改交易的一个或多个条款的机会，给用户B提供了 与用户A协商的机会。用户B可以寻求更改的交易的一些条款包 括金额，将资金划入哪一个帐户中，引荐费的分配，以及什么银行将 管理帐户。
[352]在步骤12中，如果用户B请求对交易进行更改，则给用 户A发送一个有关提议的更改的通知。给用户A提供了接受或拒 绝用户B的提议的更改的机会。在本发明的一个实施例中，用户A 利用系统在他的初始设置中可能已经选择自动地拒绝提议的更改。然 后，可以给用户B发送一个用户A自动拒绝更改的消息。如果用 户A拒绝更改，无论是手动还是自动地，都可以给用户B提供向 用户A发送另一个提议的更改的选项，或者，也可以给用户B提 供接受原始交易的机会。根据需要，这些步骤可以重复，直到达成协 议，或者取消交易。如果达成协议，则转到步骤13。
[353]在步骤13中，移动支付系统再次检查用户A的帐户，以 验证资金，如果适当，则通过SMS消息通知用户A，资金不足。在 本发明的另一个实施例中，用户A可以以其他形式接收此消息，如 电子邮件、MMS消息，或其他形式的移动通信，或者，也可以根本 不接收此消息。如果用户A的帐户有足够的资金，则转到步骤14。
[354]在步骤14中，给用户A发送一个类似于收据的SMS通 知，通知他交易已经完成。在另一个实施例中，可以给用户A发送 其他形式的通知，如通过电子邮件、即时消息、MMS消息，或其他 形式的移动通信。系统的某些实施例还给用户B发送通知，交易已 经完成，虽然在某些实施例中，没有完成的通知需要发送。
[355]在步骤15中，进行资金转帐。取决于实现方式，划入和 划出交易不必实时地进行。由于电子资金系统中的固有延时，交易可 能在处理开始之后大约六十秒或更多才能完成。
[356]取决于特定实现方式的设计首选项，流程A中的任意数量 的步骤，以任何组合，都可以与任何其他移动支付系统流程组合起来， 包括本申请中所讨论的其他流程。
[357]下面的流程B显示了在注册的用户(用户A，会员)和 未注册的用户(用户B)之间进行交易的方法的另一种实现方式。
[358]流程B
  步骤 操作 1 现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的移动电话 号码向移动支付系统发送一则消息和交易金额。                     2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3       如果资金不足，则给A发送一则消息：  “资金不足。                     [tel #]，[value]，[trans #]”        B不会接收到消息。                如果有足够的资金，则进入下一步骤。 4     检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有被识别为注 册的用户，则A接收到下列消息：                                        “您的支付待办。未注册用户必须开立帐户。                             [tel #]，[value]，[trans #]”                                            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的个人帐户。                                                   9 B在系统网站进行了注册，并成为已注册的无卡用户。资金从未注册用户合并帐户 转帐到B的无卡合并帐户。                                                 10 为B制作塑料借记卡，并寄给B。 11    在B收到卡之后，B通过拨打交互式语音响应(IVR)系统来激活该卡。       在激活过程中，在B连接到IVR系统的同时，资金从无卡合并帐户转帐到B的 个人帐户。                                                       
[359]流程B中的实现方式与上面的流程A相似。然而，与流 程A不同，流程B没有在A的帐户中预留交易金额(流程A的 步骤5)。在流程B的步骤4中，因为在A的帐户中没有预留并 且没有从A的帐户划出，钱仍可以供用户A通过移动支付或借记 卡支付进行花费，直到在步骤6中从用户A的帐户中成功地划出交 易金额。
[360]在步骤5中，给用户B发送一则有关交易的消息，并要 求用户B向系统进行注册。
[361]在步骤6中，资金被划出。取决于实现方式，这样的交易 可以是异步的线程，由于电子资金系统中的固有延时，交易可能在处 理开始之后大约六十秒或更多才能完成。延迟的量是不确定的，因为 有各种因素影响延迟。一般而言，延迟大约是60秒，但是，如果， 例如，电网发生故障，则延迟将会大得多。
[362]具体来说，系统的支付处理不必以同步方式进行。将执行 一定量的首先的请求验证。在一种实现方式中，发送给消费者的通知 可以指出，请求已经被接受，将会立刻处理。异步服务器端线程将启 动，以实际处理支付请求。在一种实现方式中，在向用户发送通知之 后执行异步线程。这会给用户提供更快的有关交易的响应。支付处理 的异步部分可能会失败。例如，这可能是由于卡的同时使用而导致资 金不足而引起的。在异步支付处理失败的情况下，将会通知用户。
[363]在一种实现方式中，有两种合并帐户，(i)未注册用户合并 帐户，(ii)无卡合并帐户。所有未注册用户资金将会合并在未注册用 户合并帐户中。如果用户A是还没有个人帐户的无卡用户，则A的 资金将会存放在无卡合并帐户中。在本发明的另一种实现方式中，未 注册用户合并帐户和无卡合并帐户有单一的合并帐户。在本发明的另 一个实施例中，在合并帐户中对A和B的帐户划入和划出，在银 行合作伙伴(合作伙伴处理借记卡)中管理的“密室”银行交易通常是 利用其他系统交易共同地分批地在在一天结束时(或另一个特定时 间)进行的。
[364]在本发明的另一种实现方式中，有单一的合并帐户类型， 其中，有未注册用户和无卡用户两种用户存在。对于这样的用户之间 的资金转帐，资金将停留在同一个合并帐户内。在本发明的再一个实 现方式中，有两种以上的合并帐户类型。
[365]在步骤9中，在B进行注册之后，B成为无卡用户。作 为无卡用户，B可以像注册的用户那样汇款和接收汇款。然而，由于 B还没有收到他的卡，因此，B不能通过卡进行消费。在一种实现方 式中，在用户B成功地进行注册之后24小时内，创建用户B的 个人帐户。然而，帐户将没有资金，直到它在下面的步骤11中被激 活。在本发明的另一个实施例中，没有使用无卡合并帐户，资金直接 从用户A帐户转帐到用户B的帐户。
[366]在步骤10中，通常需要花费大约7到10个工作日，作 出新的卡，用户B通过邮寄收到它。在本发明的另一个实施例中， 用户B收到另一种卡，如信用卡，也可以选择根本不接收卡。
[367]在步骤11中，在用户B激活他的卡时，用户B成为有 卡注册的用户，不再是无卡用户。在不使用无卡合并帐户的实施例中， 在卡被激活时，不需要划拨余额。
[368]下面的流程C显示了在注册的用户(用户A，会员)和 未注册的用户(用户B)之间进行交易的方法的另一种实现方式。
[369]
  步骤 操作 1 现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的 移动电话号码向移动支付系统发送一则消息和交易金额。     2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3     如果资金不足，则给A发送一则消息：       “资金不足。[tel #]，[value]，[trans #]” B不会接收到消息。                     如果有足够的资金，则进入下一步骤。      4 检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有 被识别为注册的用户，则A接收到下列消息：                    “您的请求已经被接受，将被处理。 [tel #]，[value]，[trans #]          请求待办的未注册用户。＂         5   B接收到下列消息：                             “有一笔支付，待办，来自[tel #]，[value]，[trans #] 请去系统网站注册。”                          6             在B批准支付之前，A可以取消支付。倘若如此，将给A和B发送     消息：                                                     “支付已取消。                                             [tel #]，[value]，[trans #]”                                  如果在A启动交易之后并且在B批准支付之前已经过去30天以上，则 交易自动取消。然后，将给A和B发送消息：                     “支付已取消。                                             [tel #]，[value]，[trans #]”                                  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 #]”                                 11    如果A有足够的资金，将给A发送消息： “支付已被接受。                   [tel #]，[value]，[trans #]”          12 从A的帐户划出交易金额，并划入B的帐户。
[370]流程C中的实现方式与上面的流程A相似。然而，与流 程A不同，流程C没有在A的帐户中预留交易金额(流程A的 步骤5)。以上的对流程A和B的讨论也相应地适用于流程C。
[371]在一种实现方式中，尽管A的支付是待办，但是，A也 被允许取消支付，并相应地给B通知。在步骤8中，在有多个待办 支付的情况下，可以向B呈现待办支付的列表，并要求B指出是 接受还是拒绝每一个待办支付。如果异步服务器端线程(例如，步骤 12)万一失败，则将通知双方。
[372]下面的流程D显示了在无卡的用户(用户A)和无卡用 户(用户B)之间进行交易的方法的一种实现方式。
[373]流程D
  步骤 操作 1 现有的用户A(无卡注册的用户)决定给用户B(无卡用户)汇一些款。 A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。 2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3     如果资金不足，则给A发送一则消息：       “资金不足。[tel #]，[value]，[trans #]” B不会接收到消息。                     如果有足够的资金，则进入下一步骤。      4   检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册 的用户，发送下列消息：                                   “您收到一笔款！[tel #]，[value]，[trans #]”                  5   检查B是无卡注册的用户还是有卡注册的用户。由于B是无卡用户，    开始从无卡用户合并帐户中的A划出交易资金并划入无卡用户合并帐户 中的B。                                                       7 如果划出和划入交易失败，则给A和B发送消息： “支付失败。[tel #]，[value]，[trans #]”      8 如果B打开了自动接受，则资金从无卡合并帐户中的A转帐到B。没 有发送消息。                                              9 如果B关闭了自动接受，则划出和划入交易只有在B批准交易之后才 进行。                                                     10 如果在A启动交易之后已经过去30天以上而B还没有批准，则交易自 动取消。然后，将给A和B发送消息：                           “支付已取消。                                 [tel #]，[value]，[trans #]”                      如果B拒绝接收支付，则交易取消，给A发送一则消息： “支付已被拒绝。                               [tel #]，[value]，[trans #]”                      11                   如果B接受交易，并且A和B仍是无卡用户，则资金从无卡合并帐户 中的A转帐到B。                                            如果B接受交易，而A是无卡用户，B现在是有卡用户，则资金从无 卡合并帐户中的A转帐到B的个人帐户。                        如果A和B两者都已经成为有卡用户，则资金从A的个人帐户转帐到 B的个人帐户。                                             如果A已经成为有卡用户，但是，B仍是无卡用户，则资金从A的个 人帐户转帐到无卡合并帐户中的B。                          
[374]上面所提供的备注也相应地适用于流程D。例如，在步骤3 中，没有在A的帐户中预留交易金额。不会从A的帐户中划出交 易金额。直到在下一步骤中成功地从A的帐户划出交易金额之前， 钱仍可以供用户A通过移动支付或借记卡支付进行花费。
[375]在某些实施例中，用户B可以设置白名单或黑名单。白名 单规定，B将只从指定的用户(可以存储在用户的资料中)接受支付。 黑名单规定，B将不会从指定的会员(也可以存储在用户的资料中) 接受支付。本发明的各种实现方式可以只有白名单、只有黑名单，或 有白名单和黑名单两者。未经授权的或被阻止的汇款人，由于白名单 或黑名单，在他们尝试支付失败之后，将会通知他们发生了错误。
[376]下面的流程E显示了在无卡注册的用户(用户A)和有 卡用户(用户B)之间进行交易的一种实现方式。
[377]流程E
  步骤 操作 1 现有的用户A(无卡注册的用户)决定给用户B(有卡用户)汇一些款。 A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。 2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3       如果资金不足，则给A发送一则消息：  “资金不足。                     [tel #]，[value]，[trans #]”        B不会接收到消息。                如果有足够的资金，则进入下一步骤。 4   检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册 的用户，发送下列消息：                                   “您收到一笔款！[tel #]，[value]，[trans #]”                  5 检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用户， 开始从无卡用户合并帐户中的A划出交易资金并划入B的个人帐户。 6   如果划出和划入交易失败，则给A和B发送消息： “支付失败。                               [tel #]，[value]，[trans #]”                  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的个人帐户。                                       如果B接受交易，而A现在是有卡用户，则资金从A个人帐户转帐到 B的个人帐户。                                            
[378]上面所提供的备注也相应地适用于流程E。
[379]下面的流程F显示了在有卡用户(用户A)和无卡用户(用 户B)之间进行交易的一种实现方式。
[380]流程F
  步骤 操作 1 现有的用户A(有卡注册的用户)决定给用户B(无卡用户)汇一些款。 A利用B的移动电话号码向移动支付系统发送一则消息和交易金额。 2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3       如果资金不足，则给A发送一则消息：  “资金不足。                     [tel #]，[value]，[trans #]”        B不会接收到消息。                如果有足够的资金，则进入下一步骤。 4     检查B是注册的(无卡或有卡)用户还是未注册用户。如果B是注册的 用户，则发送下列消息：                                     “您收到一笔款！                                             [tel #]，[value]，[trans #]”                                  5 检查B是无卡注册的用户还是有卡注册的用户。如果B是无卡用户，则 开始从A的个人帐户中划出交易资金并划入无卡用户合并帐户中的B。 6   如果划出和划入交易失败，则给A和B发送消息： “支付失败。                               [tel #]，[value]，[trans #]”                  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的个人帐户。                            
[381]上面所提供的备注也相应地适用于流程F。
[382]下面的流程G显示了在有卡用户(用户A)和有卡用 户(用户B)之间进行交易的一种实现方式。
[383]流程G
  步骤 操作 1   现有的用户A(有卡注册的用户)决定给用户B(有卡注册的用户)汇 一些款。A利用B的移动电话号码向移动支付系统发送一则消息和交易 金额。                                                   2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3       如果资金不足，则给A发送一则消息：  “资金不足。                     [tel #]，[value]，[trans #]”        B不会接收到消息。                如果有足够的资金，则进入下一步骤。 4     检查B是注册的(无卡或有卡)用户还是未注册用户。由于B是注册 的用户，发送下列消息：                                   “您收到一笔款！                                           [tel #]，[value]，[trans #]”                                5 检查B是无卡注册的用户还是有卡注册的用户。由于B是有卡用户， 开始从A的个人帐户划出交易资金并划入B的个人帐户。           6   如果划出和划入交易失败，则给A和B发送消息： “支付失败。                               [tel #]，[value]，[trans #]”                  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的个人帐户。
[384]上面所提供的备注也相应地适用于流程G。
[385]流程H显示了未注册用户的引荐流程。用户A是注册的 用户，用户B是未注册用户。
  步骤 操作 1 现有的用户A决定给用户B(未注册的用户)汇一些款。A利用B的 移动电话号码向移动支付系统发送一则消息和交易金额。     2 移动支付系统检查A的帐户是否具有足够的资金来完成交易。 3     如果资金不足，则给A发送一则消息： “资金不足。                    [tel #]，[value]，[trans #]”       B不会接收到消息。               如果有足够的资金，则进入下一步骤。 4       检查B是注册的用户还是未注册的用户。如果B的移动电话号码没有 被识别为注册的用户，则A接收到下列消息：                    “B不是会员。我们已经邀请B加入系统。                       [tel #]，[value]，[trans #]＂                                  不会从A的帐户中扣除资金。                                  5     B接收到下列消息：       “A尝试给您汇款。       [tel #]，[value]，[trans #] 请去系统网站注册。”    6 B向系统网站进行了注册，并成为已注册的无卡用户。 7 A还接收到下列消息：                               “B现在是注册的用户，您愿意再次提交您的交易吗？” 8 A在他的帐户中收到引荐奖金(例如，$5)。 9 A利用B的移动电话号码向移动支付系统重新发送一则消息和交易金         额。如果是，则交易将作为注册的用户与注册的用户的交易来进行处理。
[386]上面所提供的备注也相应地适用于流程H。在此流程中， 在B进行注册之后资金不会自动地从A转帐到B。相反地，B被 邀请加入，在B加入时，给A发送一则消息(步骤9)，询问A是 否希望再次尝试向B汇款。如果A希望汇款，那么，后续的A与 B之间的处理与任何一个注册的用户到注册的用户之间转帐类似。
[387]实现方式可以包括引荐奖金(例如，$5)。步骤4中的消 息可以包括发往A的通知，说明在B加入时，A将收到引荐奖金。 在B在步骤6中进行注册之后，用户A将有资格获得放进A的 帐户的引荐奖金(参见步骤8)。步骤8在步骤6之后，但是可以 在步骤7和9之前或之后执行。
[388]在系统的各种实现方式中，可以只向汇款人支付引荐奖金， 只向收款人，或汇款人和收款人支付引荐奖金。此外，在引荐流程的 备选实施例中，在用户B进行注册之后，钱可以自动地从用户A转 帐到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在某一时间段内没有接 受邀请，则待办的金额被释放回帐户。
[389]在本发明的进一步的实施例中，在特定情况下，金融交换 系统可以每次交易通过多个通知来向用户发出通知，如利用SMS， 利用电子邮件。这样的情况的示例包括：在进行新用户注册时，在进 行系统卡注册时，在发送或接收引荐时，在划入/划出加载时，在ACH/ 直接-存放加载或卸载时，在eAllowance(即，帐单支付)加载，以 及在帐户或资料数据更改时。
[390]在一个实施例中，本发明的一个方面是包括下列步骤的方 法：从第一用户接收向第二用户支付指定金额的付款指示，其中，所 述第一用户是已注册的用户，所述第二用户通过所述第二用户的电话 号码来进行标识；基于所述电话号码，确定所述第二用户不是已注册 的用户；以及，向与所述电话号码关联的设备发送第一电子消息，通 知所述第二用户来自所述第一用户的待付款。该方法包括：在发送所 述第一电子消息之后，注册所述第二用户，并给所述第二用户呈现接 受来自所述第一用户的待付款的第一选项，以及拒绝来自所述第一用 户的待付款的第二选项；当所述第二用户选择所述第一选项时，从与 所述第一用户关联的第一帐户划出所述金额，并向与所述第二用户关 联的第二帐户划入所述金额；以及，当所述第二用户选择所述第二选 项时，向所述第一用户发送付款被拒绝的第二电子消息。
[391]在一种实现方式中，第二帐户位于合并帐户中，当所述第 一用户是无卡已注册的用户时，所述第一帐户位于所述合并帐户中， 以及所述划出和划入过程包括在所述合并帐户内维护所述金额。在一 种实现方式中，第二帐户位于合并帐户中，当所述第一用户是无卡已 注册的用户时，所述第一帐户位于所述合并帐户中，以及所述划出和 划入过程包括不在所述合并帐户外部转移所述金额。在一种实现方式 中，当所述第一用户是无卡已注册的用户时，所述第一帐户位于第一 合并帐户中，第二帐户位于不同于所述第一合并帐户的第二合并帐户 中，以及所述划出和划入过程包括从所述第一合并帐户向所述第二合 并帐户转移所述金额。
[392]在一种实现方式中，第一用户是有卡，注册的用户，而第 二帐户位于合并帐户中，划出和划入包括将资金金额从第一帐户转帐 到合并帐户中的第二帐户，从而，合并帐户中被增加了资金金额。与 注册的用户关联的卡可以是借记卡、信用卡、自动化提款卡、或显示 了帐号的任何其他物理卡。通过使用这样的卡，第一用户可以独立于 从其中发送支付指示的电子设备进行交易。
[393]在一种实现方式中，该方法包括：除所述付款指示之外， 还接收由发送了所述付款指示的设备生成的序列号；以及，在接收所 述序列号之后，生成所述付款指示的交易号。在一种实现方式中，只 有在所述序列号不匹配存储在数据库中的任何以前接收到的序列号 的情况下才处理所述付款指示。数据库可以包括在轮询时间周期内接 收到的序列号，如上周，上两周、上个月、前六个月，或任何其他时 间段，其中，时间段一般是确定的，以确保序列号不会被重复使用， 而以前产生的序列号在系统内仍有效。
[394]在一种实现方式中，在收到序列号之后，生成预期的序列 号。然后，只有在所述序列号匹配所述预期的序列号的情况下才处理 所述付款指示。
[395]在一个实施例中，本发明是包括下列步骤的方法：从第一 用户接收向第二用户支付某一金额的付款指示，其中，所述第一用户 是已注册的用户，所述第二用户通过所述第二用户的电话号码来进行 标识；基于所述电话号码，确定所述第二用户不是已注册的用户；以 及，向与所述电话号码关联的设备发送第一电子消息，通知所述第二 用户来自所述第一用户的待付款。该方法包括：在发送所述第一电子 消息之后，注册所述第二用户，并给所述第二用户呈现接受来自所述 第一用户的待付款的第一选项，拒绝来自所述第一用户的待付款的第 二选项，以及请求对来自所述第一用户的待付款作出更改的第三选 项；当所述第二用户选择所述第一选项时，从与所述第一用户关联的 第一帐户划出所述金额，并向与所述第二用户关联的第二帐户划入所 述金额；当所述第二用户选择所述第二选项时，向所述第一用户发送 付款被拒绝的第二电子消息。
[396]在一种实现方式中，该方法包括：当所述第二用户选择所 述第三选项时，向所述第一用户发送第三电子消息，说明所述第二用 户请求对所述待付款进行更改。在一种实现方式中，该方法包括：当 所述第二用户选择所述第三选项时，接收来自所述第二用户将待付款 更改为不同的金额的请求，向所述第一用户发送第三电子消息，通知 所述第一用户对所述待办支付款项进行更改，给所述第一用户呈现接 受所述对所述待付款的更改的第四选项或拒绝对所述待付款的更改 的第五选项，以及当所述第一用户选择所述第四选项时，从所述第 一用户的帐户中划出所述所述不同的金额并向与所述第二用户关联 的帐户划入所述不同的金额。
[397]该方法可以进一步包括，在确定第二用户不是注册的用户 之后，在第一帐户中预留某一金额。如果从接收到付款指示而第二用 户仍没有注册时起一定天数已经过去，取消第一帐户中的所述金额的 预留。
[398]在一种实现方式中，设备至少是智能电话、移动电话设备、 便携式电子邮件设备、个人数字助理或计算机中的一个。
[399]在一个实施例中，本发明是包括下列步骤的方法：从第一 用户接收向第二用户支付某一金额的付款指示，其中，所述第一用户 是已注册的用户，所述第二用户通过所述第二用户的电话号码来进行 标识；基于所述电话号码，确定所述第二用户不是已注册的用户；以 及，向与所述电话号码关联的设备发送第一电子消息，通知所述第二 用户所述第一用户尝试付款。该方法包括：在发送所述第一电子消息 之后，注册所述第二用户，向所述第一用户发送第二电子消息，说明 第二用户已经注册，并给所述第一用户呈现给所述第二用户支付所述 金额的第一选项；以及，当所述第一用户选择所述第一选项时，从与 所述第一用户关联的第一帐户中划出所述所述金额，并向与所述第二 用户关联的第二帐户划入所述金额。
[400]在一种实现方式中，在所述第二用户进行注册之后，给所 述第一帐户划入引荐奖金金额。引荐奖金金额可以是任何资金金额， 如$5。在一种实现方式中，在所述第二用户进行注册之后，给所述 第二帐户划入引荐奖金金额。另外，第一和第二用户两者都可以收到 引荐奖金。
[401]在一种实现方式中，该方法包括：向所述第一用户发送 第二电子消息，说明第二用户不是已注册的用户。在一种实现方式中， 该方法包括：除所述付款指示之外，还接收由发送了所述付款指示的 设备生成的序列号；以及，在接收所述序列号之后，生成所述付款指 示的交易号。
[402]图19显示了本发明的特定实施例的完整的系统图形。这 是移动支付系统(即，Obopay)的特定实现方式的示意图。如前所述， Obopay只作为示例，用于说明本发明的功能，本发明不应该仅限于 此示例。Obopay的系统具有借记卡主干网。Diamond Financial Products是合作伙伴。通过Diamond，Obopay发放借记卡并与 ECL和First Premiere Bank进行通信，以给予Obopay用户在借 记卡之间转帐和接收资金的能力。PBT(Pay By Touch)处理ACH交 易和信用卡交易。Bancorp Bank提供结算帐户，并与PBT有关系。
[403]图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银行帐 户。
[404]图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的Diamond Financial Products银行帐户。(5)记录被输入到U1的“邀请”数据 库表中。这存储“病毒式”交易的记录的位置；交易可以保留，直到“病 毒式”收款人注册了Obopay帐户。
[405]图22显示了卡帐户和无卡帐户之间的个人之间的支付。 “无卡”用户是还没有收到或激活他们的借记卡的Obopay用户。在 本发明的另一个实施例中，不需要借记卡。在特定实施例中，存在订 购卡和激活之间的状态，在该状态下，用户仍可以转帐和接收资金。
[406]具体流程包括：(1)U1从电话中启动向“无卡”用户O1 的$5的P2P交易。(2)金额$5.00被从U1的借记卡帐户转帐到 位于First Premier的Obopay In & Out银行帐户。(3)$0.10的费 用被转帐(通过Diamond)到位于First Premier Bank的Diamond Financial Products银行帐户。(4)Obopay在Obopay总帐上记录 O1的余额增多$5。
[407]图23显示了无卡帐户到无卡帐户之间的个人之间的支 付。具体流程包括：(1)O1从电话中启动向“无卡”用户O2的$10 的P2P交易。(2)$10仍保留在位于First Premier的Obopay In & Out帐户中。$0.10的费用也停留在In & Out帐户中。(3)Obopay 在Obopay总帐中记录了O2的余额增多，O1的余额缩小。
[408]图24显示了信用卡加载。具体流程包括：(1)U1从web 输入CC-Number，以将$300加载到他的Obopay卡上。(2) Obopay从Pay-By-Touch获取$300的信用卡交易的授权。(3) Obopay向Diamond发送一则消息，启动Obopay CC-Master A/C 到U1的借记卡的$300 P2P交易。将资金立即划入用户的帐户。(4) PBT对信用卡交易进行结算，并向位于Bancorp Bank的Obopay 的结算帐户转帐$300 ACH。(5)Obopay向Obopay CC Master A/C 转帐$300 ACH，以补充资金。
[409]图25显示了本发明的另一个特定实施例的完整的系统图 形。下列流程78到85涉及图77中的系统实现方式。在此系统实 现方式中，用户将不需要为借记卡卡帐户而进行注册。这些用户将叫 做“无卡”用户，并将持有虚拟帐户。资金将保留在银行帐户中(为了 Obopay用户的利益)。
[410]图26显示了无卡帐户和无卡帐户之间的个人之间的支 付。具体流程包括：(1)从O1的电话，启动向O2的$5的P2P 支付。(2)由于O1和O2两者都是现有的用户，因此，他们的资金 存放在Bancorp Bank的合并帐户中。$5停留在同一个帐户中，减 去$0.10的费用。(3)Obopay的总帐反映了余额的变化。从O1的 帐户划出金额$5，$5被划入O2的帐户。(4)$0.10的费用从合并 客户帐户转帐到流动资本帐户。
[411]图27显示了无卡帐户和卡帐户之间的个人之间的支付。 具体流程包括：(1)从O1的电话，启动向U6的$5的P2P支 付。(2)用户O1的帐户被划出$5.10。此变化反映在Obopay的总 帐中。(3)Obopay(通过与Diamond的通信)启动P2P，从First Premier In & Out帐户向借记卡U6转帐$5。(4)在夜晚时间的批 处理中，从Obopay合并帐户向位于Bancorp的Obopay流动资 本帐户转帐$5.10(有10美分的汇款手续费)。
[412]图28显示了个人之间的支付，与非会员的“病毒式”交易。 “病毒式”支付是指一个Obopay会员，有卡或无卡，向非Obopay用 户电话号码进行支付。具体流程包括：(1)从O1的电话，启动向V1 的$5的P2P支付。(2)Obopay的总帐反映了O1的余额的变化。 $5.10从O1的帐户中划出。(3)$5.10仍保留在合并客户帐户中。费 用以后转帐。(4)病毒式交易记录在Obopay数据库中的O1的“邀 请”表中。如果“病毒式”支付到期，则资金将被退回到O1。(5)$0.10 的费用从合并客户帐户转帐到流动资本帐户。这可以在夜晚时间的批 处理中进行。
[413]图29显示了奖励资金。当给新的obopay用户提供$5 的注册奖金或任何其他金额时，产生奖励资金。当用户进行注册时， 此$5将反映在余额中。此外，象病毒发送给用户的任何资金都将转 帐到他们的帐户中。当非Obopay用户以病毒式方式发送他们保留 在客户合并帐户中的资金时，发生待办的“病毒式”支付。支付被记录 在汇款人“邀请表”中，这是他们自己的资料数据的一部分。“病毒式” 只是“待办”，表示汇款人可以取消该支付。
[414]具体流程包括：(1)V1(“病毒式”资金收款人，非用户) 在Obopay.com注册使用Obopay。(2)在Obopay数据库中创建 帐户。(3)Obopay GL中的用户余额现在反映$5奖金和$10“病毒 式”支付。(4)以病毒式方式发送给V1的资金(在注册之前发送给 用户的$10)仍保留在客户合并帐户中。(5)“病毒式”资金的原始发 件人的数据库资料被更新为“RFPAID”(引荐支付)。(6)在夜晚的 批处理中，$5被从Obopay w/c帐户转帐到客户合并帐户。
[415]图30显示了信用卡加载。信用卡加载是通过信用卡将资 金加载到Obopay帐户的过程。Obopay流动资本帐户是在 Bancorp银行(或任何其他银行合作伙伴)的银行帐户。此帐户包含 Obopay流动资本，并用Obopay流动资本填充。此帐户还被用作 NYCE、PBT、及其他机构的结算帐户。
[416]具体流程包括：(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.50 ACH。这在翌日的批处理中进行。
[417]图31显示了ACH加载。具体流程包括：(1)无卡用户 O1从Obopay网站启动从他的DDA向Obopay帐户的$100 ACH交易。(2)Obopay对用户DDA启动ACH划出交易。(3)资 金从用户DDA转帐到Obopay流动资本帐户。(4)在Obopay GL 中，给用户帐户划入$100。(5)Obopay将$100从Obopay流动资 本帐户转帐到合并客户帐户。这可以在夜晚时间的批操作中完成。
[418]图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流动资本帐户。
[419]图33显示了ATM加载。加载可以通过任何ATM机构 进行，如NYCE、PLUS、STAR，及其他。在特定实现方式中，ATM 加载是NYCE加载。具体流程包括：(1)无卡用户O1从Obopay 网站启动从他的DDA的$100 NYCE加载。(加载资金需要$0.99 的费用。)(2)Obopay提交，并从NYCE收到$100.99授权。(3) Obopay GL中的O1的帐户被划入$100。(4)在夜晚的批处理中， $100被从Obopay流动资本帐户转帐到客户合并帐户。(5)NYCE 将$100.99 ACH记入Obopay流动资本帐户。
[420]当今的支付系统(即，信用卡和借记卡)对于消费者和商 家都费用。可以向消费者收取年度预订费用。向商家主要收取了交易 费用。所需要的是对消费者和商家可用的，没有注册费用、没有预订 费，对于消费者或者商家没有交易费用的支付系统。同时，也必须对 运行这样的系统的“处理器”相应地进行补偿。
[421]闭环支付方案
[422]在一个实施例中，本发明提供了用于操作作为闭环支付系 统的支付转帐基础架构的方法。闭环金融交易系统便于进行支付，没 有与闭环金融系统关联的大量的付款手续费，并且对于参与金融交易 的持有人、商家及其他各方来说，具有高度的安全性。
[423]闭环支付系统是这样的，价值转移过程的组件在拥有该支 付系统的实体控制下工作。由于所有者控制了该系统，因此，基础价 格也在所有者的控制之下。相比之下，现金和支票是开放的支付系统， 每一个参与者都为他们的交易的处理设置价格，无需支付给网络运营 商费用。
[424]图35显示了闭环支付系统中的交易流程。具体来说，当 从一个移动设备3501向另一个移动设备3502进行支付时，向支付 服务器3503传输转帐请求。请求通过引用箭头3504来表示。服务 器3503访问与移动设备3501关联的帐户持有人的T-总帐(如引 用箭头3505所示)，如果满足了如3506处所示的某些速度规则， 则将指定的金额转帐到收款人T-总帐(如引用箭头3507所示)。 一旦资金已经转帐到收款人，如3508所示，服务器3503就向收款 人发送一则通知消息，如3509所显示的。最后，付款人帐户持有人 从服务器3503接收到确认消息，说明交易已经完成。优选情况下， 整个闭环系统由单一实体所拥有。系统由帐户持有人装填或加载，帐 户持有人由于在支付服务器上维护的帐户余额，而获得美元(参见图 36)。
[425]闭环支付系统有多个优点。主要优点是，系统的所有者能 够控制向汇款人和收款人收取的费用，对于加载到系统中的资金，有 赚取利息的机会。支付系统所有者能够赚取系统中的所有资金的利 息，直到它们被转换回美元或卸载回美元。随着更多功能被添加，由 于费用和余额的增多，闭环系统会变得更有利可图。
[426]给参与帐户持有人带来的好处包括：
[427](1)安全—帐户持有人的资金被安全地锁在移动设备中 而不是必须将现金装在口袋或钱包中；
[428](2)安全性—及时验证看看帐户中有多少钱可用；
[429](3)信息—易于获取帐户活动和余额信息；
[430](4)方便—帐户持有人可以以秒为单位在全世界或跨房 间地移动资金。
[431]给商家带来的好处包括：
[432](1)安全—没有现金；
[433](2)较少的处理成本—不计数现金收入，无存款单，无计 数单；
[434](3)较少的交易费用—比信用卡的费用要低；以及
[435](4)资金有保证—无退回支票。
[436]商家合作伙伴具有极难得的机会赚取处理针对将资金存放 到预存款贷记帐户中的交易或用于向帐户持有人提供现金的交易的 收入。取决于实现方式，当资金被添加到帐户中时，商家可以赚取佣 金。
[437]本发明的独立的闭环支付系统被设计为与伙伴银行帐户集 成在一起。此帐户可以是预先存在的帐户，或者，对于无银行帐户的 用户，可以由合作银行创建帐户。
[438]闭环系统维护了用户资料数据库，包括帐户持有人的姓名 和人口统计数据，每一个特定帐户持有人的用于对风险进行签名的信 息，以及将用于向预存款贷记帐户中加载或从该帐户中卸载资金的帐 户的链接的银行帐户信息。用户资料数据库也需要面向消费者和面向 顾客服务的网站，用于当开立时收集注册数据。优选情况下，本闭环 系统与信用卡交换系统连接，以访问信用卡帐户下可用的信用额度。 或者，或另外在某些实施例中，如前面所指出的，当前闭环系统还与 各种ATM网络连接。
[439]支付服务器为每一个帐户持有人维护了“T”帐户记录。此帐 户是跟踪每一个帐户持有人的交易和余额的总帐。和T型帐户数据 库一起，支付服务器还通过移动设备以及面向消费者和顾客服务的网 站，提供历史和余额数据。
[440]为了将资金转入闭环支付系统或转出该闭环支付系统，本 发明为不同的帐户持有人提供了三种功能。
[441]某些帐户持有人已经在不是合作伙伴的银行具有银行帐 户。该系统允许帐户持有人通过ACH系统往返于此银行帐户地移动 资金。由于存在风险，用户必须进行风险控制，可以包括延迟划拨的 资金可用性(例如，在星期一从您的银行帐户转帐的资金直到星期四 才可以使用)。此延期时间可以通过额外的签名而缩短(运行信用报 告或获取财务报表)。延迟时间的缩短也可以由于用户在合作伙伴运 营商那里具有良好的资信评级或利用保留的信用卡保证支付而出现。 在某些实施例中，此方法不是首选，虽然这些风险可以通过运营商的 参与而最小化，运营商可以提供某些签名数据和足够的用户证明额外 的签名是正当的。
[442]在帐户持有人由于与合作银行的关系而被注册的情况下， 与活期储蓄帐户(支票帐户)系统的实时连接允许帐户持有人获取余 额并实时地将交易记入他们的帐户中。
[443]在其他情况下，帐户持有人在Bancorp Bank或类似的金 融机构有一个帐户，银行开办银行业务，但是，所有网站，支票，以 及客户对帐单将带有亲缘品牌。此方法将允许我们在紧密的整体环境 中与伙伴银行帐户(该帐户对用户是免费的)提供亲缘品牌。
[444]本发明涉及交易费用较低的或无交易费用并且安全性改善 的闭环金融交易服务。本发明的实施例包含在任何对等伙伴之间或在 消费者和商家之间进行快速方便的支付转帐的方法。该方法的一种实 现方式包括移动电话设备，蜂窝电话(手机)或类似的设备，作为访 问诸如预存款贷记帐户之类的帐户并授权从该帐户向另一方转拨资 金的机制。本发明的另外的实施例涉及各种合作伙伴，包括移动电话 运营商、全国性的品牌商家，以及金融服务提供商，连同支付平台， 该支付平台提供供个人使用他们的手机或其他电信设备进行付款的 快速，简便的方式。
[445]现在请参看图36，该图显示了根据本发明的实施例的闭环 金融交易系统。在此交易系统中，消费者和商家，一组两个或更多消 费者，或者一组两个或更多商家可以快速地，安全地完成金融交易， 交易费用很少或没有。
[446]闭环金融交易系统的此示例利用预存款贷记帐户，因此， 可以包括销售点(POS)终端3612，其中，可以如在现有技术系统中 那样使用传统的借记卡3606—通过在与POS终端3612关联的 磁性读取器3613中刷卡。卡3606提供了查看帐户持有人的帐户的 第二途径。
[447]在某些实施例中，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通常与商家关联。
[448]本发明的某些实施例的一个重要优点是，手机3618或 3619和卡3406两者共用一个共同的PIN。如此，帐户持有人不会 因为必须回忆多个PIN而感到不方便。
[449]除消费者与商家之间的交易之外，本发明足够灵活，可以 实现真正的个人之间的金融交易功能。个人之间的设备3620各自都 包括链接到帐户和帐户持有人的手机。当对等伙伴3620中的一个希 望启动交易请求，以便向另一个对等伙伴进行支付时，交易的请求、 授权和确认都是通过公共网络在支付服务器3630和对等伙伴3620 之间发送的。优选情况下，由于使用了一个或多个公共网络，没有了 交换中心的费用，如此，对于参与者来说，成本可以免费的，或者相 当便宜，以至于它占在系统上进行的总体交易的百分比可忽略，特别 是与典型的交易费用相比时。
[450]正如上文所指出的，交易请求通过公共网络被路由到支付 服务器3630。在一个实施例中，公共网络3625是因特网。在另一 个实施例中，公共网络3625是蜂窝电话网络。在再一个实施例中， 公共网络3625是无线电网络，而在再一个实施例中，它是公用交换 电话网或PSTN。公共网络3625将帐户持有人的交易请求传输到支 付服务器3630。
[451]在一种实现方式中，通过公共网络3625的连接是依赖于 对参与者进行身份验证和加密的安全的链路。如此，对于通过因特网 的连接，连接协议可以是，例如，HTTPS，链路可以是虚拟专用网 络或VPN。支付服务器3630还要么通过公共网络3625(未显示) 要么通过专有的ACH银行或者金融网络连接到所链接的储蓄帐户 3635。
[452]图37是根据本发明的实施例的闭环金融系统的方框图。 更具体地说，本发明的简单性可以使其普遍地使用，并可以向帐户持 有人和商家提供巨大的使用价值。如前面所讨论的，本发明提供了用 于完成消费者与商家之间的交易和个人之间的交易的便宜的电子金 融交易服务，以及诸如帐单支付等等之类的其他金融交易。在某些实 施例中，这种灵活性部分地是通过将消费者的手机3702连接到 POS终端3612来实现的。在一个实施例中，消费者可以在与POS 终端关联的小键盘上输入他们的电话号码，当获得了交易总金额时， 商家可以通过因特网连接3706和支付服务器3704向手机3702发 送PAY REQUEST(支付请求)。在这样的方案中，支付服务器3704 将呼叫手机3702，并请求消费者授权进行资金转拨。然后，消费者 输入他们的PIN或其他生物特征标识，并确认金额，以对支付进行 授权。支付服务器3704会将资金(加上任何交易费用)从消费者的 预存款贷记帐户转帐，将支付金额(减去任何交易费用)添加到商家 的帐户。
[453]在备选实施例中，手机3702包括近场通信(NFC)电路、 蓝牙电路或RFID电路(未显示)，用于允许POS终端3712查 询和恢复诸如手机电话号码之类的帐户信息。在此实施例中，商家将 自动地检测帐户信息，并向支付服务器3704发送请求。支付服务器 3704将再次呼叫手机3702，以请求PIN或其他生物特征标识和支 付授权。
[454]个人之间的交易将POS终端从处理过程中免除，每一个 对等伙伴3707和3708都直接联系支付服务器3704，以进行金融 交易。
[455]图38是根据本发明的实施例的移动客户端应用程序 (MCA)的方框图。MCA驻留在手机3802上，并包括用户界面API 3802和3803和支付AP I3805。API 3802提供用户屏幕图像，引 导帐户持有人执行各种金融交易，如识别对方、交易的金额(如果有 的话)以及可用的交易类型。API 3803给服务提供商或其他增值合 作伙伴(如帐户或记录服务)提供了用于访问支付API 3805以获取 提供增值服务所需的信息的机制。在一个实施例中，支付API 3805 提供了用于实现本发明的逻辑以及用于与手机的通信层3810进行 连接的逻辑。
[456]用于操作根据本发明的实施例的支付转帐基础架构的一种 方法是作为闭环支付系统来实现的。闭环支付系统是这样的，价值转 移过程的全部组件在拥有该支付系统的实体控制下工作。由于所有者 控制了该系统，因此，基础价格也在所有者的控制之下。
[457]图39显示了如图36所示的闭环支付系统中的交易流 程。具体来说，对于个人之间的交易，当从移动设备3901向另一个 移动设备3901进行支付时，向支付服务器3903传输转帐请求。请 求通过引用箭头3904来表示。服务器3903访问与移动设备3901 关联的帐户持有人的T-总帐(如引用箭头3905所示)，如果满足 了如3906处所示的某些速度规则，则将指定的金额转帐到收款人 T-总帐(如引用箭头3907所示)。一旦资金已经转帐到收款人，如 3908所示，服务器3903就向收款人发送一则通知消息，如3909所 显示的。最后，付款人帐户持有人从服务器3903接收到确认消息， 说明交易已经完成。在一个实施例中，整个闭环系统由单一实体所拥 有。系统由帐户持有人装填或加载，帐户持有人由于在支付服务器上 维护的帐户余额，而获得美元(参见图36)。
[458]图40显示了根据本发明的实施例的闭环金融系统的示范 性费用结构。应该理解，费用结构可以变化，该例图只呈现了用于生 成营业收入的结构的一个示例。由于本发明的无所不在的特征，交易 费用可以非常低或免费。如此，如4001所示，对于某一美元金额下 的交易，交易费用被放弃。为说明问题，请看在个人之间转帐$1的 金融交易。无交易费用。尽管可以收取交易费用的美元金额是任意设 置的，但是，通常，美元金额将是小于$25的金额。帐户持有人将 有资格每个月进行无限个这样的交易。
[459]在这样的实施例中，对于超过选定最大值的交易费用，帐 户持有人进行汇款(启动支付交易)将产生某些费用，如4002所示。 为说明问题，对于在$50和$100之间的交易金额，帐户持有人将 产生，例如，$1.00的交易费用。对于超过选定金额(如超过$100) 的金额，可以收取较高的费用或协商费用。这些费用比至少某些信用 卡发行者收取的每次交易费用少得多。在一个备选实施例中，交易费 用可以是名义帐面额，如向汇款人收取的一个美分，$0.05，或$0.10。
[460]对于涉及商家的交易，商家可以可选地提议支付否则将会 向消费者收取的交易费用，如4003所显示的。此外，对于这样的实 施例，也可以向商家收取接收资金的额外的费用。同样，商家交易费 用的实际金额可以变化，但是，在一个实施例中，是交易金额的额定 1％。
[461]在一个实施例中，额定每月的服务费，通过移动服务提供 商添加到手机用户的帐单中，如4004所示。移动服务提供商和本发 明的闭环金融交易系统的所有者按比例分配地共享每月的服务费。
[462]向消费者和商家提供了支持会员的支付系统，消费者或者 商家无需支付注册费用、预订费，或交易费用。在一种特定实现方式 中，会员支付系统是这样的移动支付系统，消费者可以使用诸如移动 电话、智能电话、个人数字助理之类的移动设备，或类似的便携式无 线手持式设备来进行交易。商家将进行可退款的一次性的捐献。这些 捐献由系统存储在合并信托帐户中，这些捐献的浮动股息或利息将为 该系统提供资金。
[463]在一种特定实现方式中，支持会员的支付系统(MSPS)根 据下列原理向消费者和商家提供完全免费的支付系统：
[464]1.对于消费者或商家，无注册费用
[465]2.对于消费者或商家，无预订费
[466]3.对于消费者或商家，无交易费用
[467]4.需要商家提供可退款的一次性的捐献。
[468]5.一次性的商家分担款项被合并到MSPS信托帐户中
[469]6.MSPS信托帐户产生浮动红利，该红利为MSPS处理公 司和系统提供补偿。
[470]7.消费者和商家可以向合并MSPS往来帐户(与信托帐 户分开)加载和从其中卸载
[471]8.消费者可用的资金是预存的，在合并MSPS往来帐户 内是活的。
[472]9.MSPS系统为消费者和商家管理了“T”帐户(即，余额、 划出、划入)。
[473]在一个实施例中，本发明是包括下列步骤的方法：接收多 个商家分担款项以为会员支付系统提供资金；将商家分担款项放入合 并信托帐户中，其中，商家对他们的分担款项不收利息；允许多个消 费者免费成为移动支付系统的注册的用户；允许注册的用户免费向会 员支付系统的往来帐户加载资金或从中卸载资金；以及，允许商家免 费向会员支付系统的往来帐户加载资金或从其中卸载资金，从而，用 合并信托帐户的利息为会员支付系统提供资金。
[474]图41显示了本发明的支持会员的支付系统实现方式中的 加载信任操作。
[475]图42显示了支持会员的支付系统中的消费者注册过程。
[476]图43显示了支持会员的支付系统中的加载和卸载操作。
[477]图44显示了支持会员的支付系统中的购物交易。
[478]在一种实现方式中，商家分担款项可以是某一时间段内的 分期付款。取决于分担款项的金额，商家在系统将具有较大的访问权 限或特权。例如，可以有分担款项的固定的量，对应于商家将有资格 免除额外的费用地进行的交易的数量。此外，商家还可以进行后续的 捐献，以扩大商家的特权。
[479]在一种实现方式中，会员支付系统允许注册的用户通过移 动电话请求向另一个注册的用户付款。会员支付系统可以允许注册的 用户通过移动电话请求向商家付款。
[480]会员支付系统可以管理注册的用户的交易记录。会员支付 系统可以管理商家的交易记录。会员支付系统可以管理注册的用户和 商家的交易记录。这将降低商家的成本，因为他们不需要管理他们自 己的交易记录。
[481]分担款项是可退款的，如此，商家可以决定以后不参与。 例如，当商家请求归还该商家向会员支付系统捐献的资金时，注册的 用户将不再被允许向该商家转帐。
[482]一般而言，在商家是会员支付系统的参与者的情况下，不 向该商家收取定期经常性交易费用。系统是由包含商家分担款项的合 并信托帐户的浮动收益资助的。
[483]注册的用户能通过自动票据交换所(ACH)或直接储蓄帐 户(DDA)中的至少一个来加载或卸载资金。在系统的进一步的实现 方式中，可以给注册的用户和商家提供很多额外的加载和卸载资金的 方式。例如，注册的用户可以选择让用户的工资支票或工资支票的一 部分直接存放到系统中。
[484]在一种实现方式中，该方法包括：允许注册的用户通过使 用两因素授权方案，通过会员支付系统授权向商家支付。这两因素授 权可以包括(1)人所拥有的(例如，电话、卡)和(2)人所知道的 (例如，PIN、母亲的婚前姓，挑战性的问题)。例如，系统可以允 许注册的用户通过使用注册的用户的移动电话和用户正确地输入个 人标识号或PIN，通过会员支付系统授权向商家支付。
[485]可选地，也可以为每一个注册的用户提供一个借记卡。利 用借记卡，用户可以在没有，例如，移动电话的情况下，进行收费。
[486]虚拟合并帐户
[487]请参看图45，在本发明的一个方面的特定实现方式中，为 避免为每一个银行记录总账，移动支付系统被配置为，为每一个国家 的虚拟合并帐户记录一个总账。这会降低系统的结算和营运成本。或 者，虚拟合并帐户可以被配置为，是合并帐户的群组表示，其中，根 据任何方便的参数或参数组，如银行合作伙伴、地理、国家、大小等 等，选择那些合并帐户，以便包括在特定虚拟合并帐户中。在某些实 施例中，实现了单一虚拟合并帐户，或者，实现了虚拟合并帐户的分 层结构。应了解，虚拟合并帐户基本上是一个大型数据库，其中，为 综合到该虚拟合并帐户中的合并帐户维护了交易记录。
[488]由于资金将保留在虚拟合并帐户中，因此，虚拟合并帐户 的所有者(例如，移动支付系统服务运营商)将接收到此资金的浮动 收益或利息。虚拟合并帐户的浮动收益的收款人可以将某些金额分发 给合作银行(它们不再收到他们的总账的浮动收益)。用于分发浮动 资金的方法的一个实施例如下：
[489](1)由合作银行获取的帐户将被认为是来自该银行。例如， 如果银行Ci销售移动支付系统服务，并吸收客户A，那么，客户A 在他的一生中都被标记为“由Ci吸收”。在这样的实施例中，对于 每一个用户记录(在本中请中别处进行了讨论)，有一个字段，指出 该特定用户是从哪一个来源招收的。可能的来源的某些示例包括直接 的移动支付服务、合作银行、合作金融机构，以及合作移动电话提供 商。
[490]在每天结束时，移动支付系统服务将估计保留在移动支付 系统服务帐户中的被标记为由每一个合作银行吸收的资金的金额。让 我们将此估计金额叫做X-Ci、X-BA、X-ING，其中，Ci、BA和ING 是金融机构或银行的示例。
[491]例如，在图45中，会员6504044762是由第一银行Ci吸 收的，而会员4154443214是由第三银行BA吸收的。在此示例中， 会员是通过电话号码来进行标识的。美国的电话号码的示例包括 4158675309或2128675309。在本发明的一种实现方式中，输入的电 话号码格式可以排除区号，如7762323或5550123。例如，这可以 用于收款人与汇款人位于同一个区号的情况。系统将自动地填充补充 区代码数字。如在本申请中别处所指出的，会员可以通过其他类型的 标识符来进行标识，如即时消息用户名、电子邮件地址、社会保障号 码、驾驶执照号码，帐号，及其他。
[492](2)让我们将其余部分叫做Y。这是移动支付系统服务帐 户中要保留的没有被标记为吸收的资金的估计金额。这些是由移动支 付系统服务直接吸收或非银行合作伙伴吸收的帐户。在图45中，这 由电话号码6508622730来表示，表示为由第二银行MSPS(移动支 付系统服务提供商)吸收。
[493](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，及其他。
[494]此方法能够避免记载多个总账和准确的结算净额的成本。 还将给予合作银行分得多于移动支付系统服务资金的应得的一份。
[495]图46显示了根据本发明的实施例的快速购物的方法。在 一个实施例中，招贴画、报纸广告、或电视广告包括允许购物者获取 显示在手机上的有关产品的具体细节的机制。此机制可以包括打印的 条形码或拨入即可获取信息的电话号码。在另一个实施例中，利用近 场通信来启动购物者和远程商家之间的连接，如4601所示。通过启 动该连接，会激活MCA，以便如果购物者决定进行购物，则MCA被 唤醒，并已经建立连接，如4602所示。通过选定Buy Request选 项，如6503所示，购物者可以与支付服务器进行购物交易，处理诸 如“发货给”地址和资金转帐之类的细节。在较短时间内，可以从几分 钟到几天，订购的产品将被发出，如4604所示。
[496]在另一个实施例中，帐户持有人具有选择“投递到当前地理 位置”的选项，而不是帐户持有人的帐单地址。当帐户持有人正在旅 行并希望从客房送餐服务菜单中进行订购而不希望对任何人说时，此 功能特定需要。在此情况下，菜单将包括近场通信设备，如此，帐户 持有人将只须选择Buy Request，食品将提供给帐户持有人所在的房 间。
[497]图47显示了根据本发明的实施例的再一个快速购物功 能。在此实施例中，帐户持有人预期产品或服务的定期出现的支付。 为说明问题，请看典型的持月票乘客，每天早上，在登上火车驶入市 区之前，停下购买报纸。对于图47中所显示的实施例，帐户持有人 可以为这样的定期出现的支付设立预先授权的帐户，如4701所示。 预先授权的帐户可以包括可以获取的产品或服务的类型，如4702所 示，以及要预先授权的最大允许的购物金额，如4703所示。如此， 当持月票乘客买了报纸，近场天线检测到手机上的帐户信息，并将交 易金额发送到支付服务器，该支付服务器将会把确认发送回商家，无 需等待消费者验证，具体地，授权进行金融交易，如4704所示。此 功能也是对于时间紧迫的金融交易加速购物处理的重要手段，如当持 月票乘客在他们经过十字转门时希望使用他们的手机支付地铁票时。 预先授权的金额可以实时地扣除，或者，作为批处理的金融交易来进 行处理，例如，一小时一次。
[498]为最小化验证处理时间，在某些实施例中，可以在预期的 使用之前，将预先授权情况通知给商家。在预先授权接收到时，电话 号码可以放置在“绿名单”中，指出商家可以接受支付，无需来自支付 服务器的验证。绿名单存储在POS终端中，或能够被POS终端从 本地服务器进行访问，而不是从交易服务器进行访问。
[499]如果预先授权的帐户已用完，而帐户持有人没有及时地补 充该帐户，则电话号码可以放在“红名单”中，并禁止未来使用该服务。 红名单也可以由商家本地存储在POS中，或存储在连接到POS设 备的本地服务器中。如果电话号码包括在红名单中，则商家可以接受 替代的支付形式。或者，服务器可以拒绝服务，并发送一则消息，建 议帐户持有人借此机会对帐户持有人的帐户进行再充值。商家可以接 受再充值支付，并收取收到对帐户持有人的帐户进行再充值的资金的 奖励费用(如果有的话)。
[500]为了加快预先授权的购物，在一个实施例中，手机包括从 外部可见的条形码，可以在POS上扫描，该条形码，以启动和结束 交易。或者，条形码可以显示在手机的屏幕上，并在POS上被扫描。 由于对于许多日常的购物速度和方便性是如此重要，条形码，连同本 地高速缓存的绿名单，使得商家“动态地”接受购物，然后在选定时间 间隔内以批处理模式提交交易。
[501]对于帐户持有人的一个优点是，如果手机丢失，可以要么 通过访问Web页面，更新用户资料，要么通过呼叫顾客服务中心， 快速地暂停预先授权。如果报告手机丢失，则将新的绿名单和红名单 立即分发给受影响的商家，从而缩小帐户持有人和商家的潜在的损 失。比较一下丢失的预存款的月票的情况—如果丢失，则该月票的 全部价值也丢失，谁捡到了谁获益。如此，绿名单和红名单是防止通 过盗窃电话对于预先授权的帐户进行欺诈的有效工具。
[502]由于并非当今使用的每个手机都是配备应用程序的，因此， 支付服务器适应于对每一个帐户持有人都可用的服务级别。用于在手 机设备之间传递消息的一种方法是使用短消息服务(通常也称为 “SMS文本消息”，或简单地，SMS)来传输与接收，因为大多数移 动设备都支持SMS。SMS是用于通过移动网络提供短消息的机制。 它是用于往返于手机传输消息的“存储转发”技术。来自发送方手机的 消息(仅限文本)存储在与SMS传输系统关联的服务器中，该服务 器稍后将它转发到目标手机。这意味着，如果收件人不可用，则消息 被存储，并稍后发送。由于SMS使用信令信道而不是专用信道，因 此，这些消息可以通过移动网络与语音服务同时发送/接收。对于基于 所有三种蜂窝技术的移动网络，GSM、CDMA、以及TDMA都支持 SMS，SMS现在是应用非常广泛的手机数据服务。
[503]利用SMS，SMS综合器在支付服务器和帐户持有人之间 实时地路由消息，资金立即可供收款人使用。如果金融交易包括另一 方，服务器也使用SMS，再次使用SMS综合器实时地与对方进行 通信。当非帐户持有人是从帐户持有人的支付转帐的收款人时，SMS 是特别重要的机制。非帐户持有人的问题是在他们的电话中没有嵌入 MCA，如此，SMS是用于与非帐户持有人进行通信的机制。MCA管 理和插入交易号，该交易号包括幂等性密钥，使得交易号对于数据服 务SMS、HTTP，以及HTTPS协议消息唯一，但是，当使用手动 SMS时，没有交易号。
[504]SMS移动金融交易系统避免了与只为支持和启用设备的 金融功能而添加特殊芯片(即，集成电路器件)关联的成本和问题。 向手机或其他移动设备中添加另外的组件会增大制造和支持的成本。 如果需要许可证费用或其他专有的费用才能使用这种芯片，则成本进 一步增大。此外，向手机中添加芯片会增大功率消耗，并缩短电池寿 命—两者对于诸如手机之类的移动设备都具有负面效果。
[505]尽管SMS文本消息适用于各种类型的蜂窝设备和某些其 他类型的移动通信设备，如便携式数字助理或PDA，但是，SMS会 暴露未加密的密码或个人标识号(PIN)，以及余额信息或有关最近的 交易的细节。由于拥有电话的任何人都可以阅读SMS消息文件并立 即知道如何访问另一个人的帐户和其他机密信息，因此，最好避免使 用公共的SMS消息来传输PIN。相应地，在一个实施例中，本发明 提供了在通过SMS文本消息启动金融交易的情况下一部分交易通 过音频信道来进行的方式。
[506]图48是由根据本发明的实施例的至少一个SMS消息机 制执行的金融交易的系统级别的例图。此交易方法用于没有哪个手机 支持因特网的情况。此外，手机也没有嵌入的MCA，如此，依赖于 SMS消息来处理交易。本领域技术人员将认识到，如果其中一个电 话是支持因特网的，并安装了MCA，那么，它这一端的交易将通过 HTTPS链接进行，与另一个电话的通信将通过SMS消息进行。应 该理解，HTTPS是指安全套接字层上的超文本传输协议，或HTTP over SSL，该链接是因特网链接。还应理解，因特网连接提供了非常 丰富的用户界面，更加安全，启动并进行金融交易更加容易。当 HTTPS不可用时，MCA可以修改交易以使用HTTP协议，这是一 种安全性稍低一些的传输机制。在这种情况下，帐户可以在将交易信 息发送到服务器之前以及在插入交易信息之前调用软件加密。
[507]如果因特网连接不可用，则在一个实施例中使用SMS(或 短消息服务)消息。在一个实施例中，MCA利用数据服务功能来发 送二进制SMS消息。在MCA不可用的另一个实施例中，使用明 语SMS消息来进行金融交易，并采取了特殊的措施，以保护PIN的 完整性。还应该进一步理解，缺乏MCA进一步会限制UI功能， 如此，用户可以从本发明取得有限的满足，但是，然而，否则，会享 受到本金融交易系统的全部功能和优点。
[508]利用本发明，MCA选择向服务器4804(也简称为交易处 理器)传输金融交易的模式。例如，如果因特网连接可用，则使用 HTTPS链接(这是对用户页面请求以及由服务器4804返回的页面 进行加密和解密的Web协议)进行交易。要使用因特网，帐户持有 人只需在Web页面上输入交易细节，并选择“发送”，以启动交易。 如果涉及另一方，并且该方具有支持Web的设备，则在Web页面 上提供交易细节。在此实施例中，服务器4804充当Web服务器。
[509]通常，并非所有的帐户持有人都具有支持因特网的手机或 设备。因此，本发明提供了从手机进行金融交易的其他方法。这样的 方法包括使用SMS数据服务、SMS明语(这两者都可以使用音频 信道来传输PIN)或只使用音频信道。
[510]对于支持SMS的手机，帐户持有人通过SMS网关4802 向服务器4804传输SMS消息，以从他们的手机5206启动交易， 如流向箭头4810所示。网关4802将SMS消息中继到服务器 4804，如流向箭头4811所示。在接收到SMS消息时，服务器4804 采取在消息中请求的指定操作，并向网关4802发送回复SMS消 息，如流向箭头4812所示。网关4802将回复SMS消息中继到手 机4806，如流向箭头4813所示。此事件序列可以多次重复地进行， 直到金融交易完成。可以通过任何电路交换或分组交换网络来在电话 自动数值判定网关4802之间传输SMS消息。
[511]在一些实施例中，建立了话音通信信道，如音频信道4815 和4835所示。当从电话4906接收到初始SMS消息时，服务器 4804可以通过拨打与帐户关联的电话号码来打开音频信道4815。使 用音频信道4815的一种情况是，获取PIN(作为DTMF或者语音 数据来接收)，以完成验证过程，并响应SMS消息，对作为帐户持 有人的用户进行身份验证。DTMF是指双音多频，是当电话的接触 键被按下时电话公司接收到的信号。
[512]初始SMS消息以提供请求的交易的类型的关键字开始 —PAY、REQUEST PAYMENT、BALANCE、TRANSFER或 HELP。在SMS消息包含表示希望从一个帐户持有人向另一个帐户 持有人划拨资金的关键字的情况下，关键字将是pay或request payment。在关键字之后，输入金额，带有小数点，也可以没有小数 点。在金额之后，输入目标电话号码(或短代码、电子邮件地址、或 其他标识信息)。此信息可以从移动设备的电话号码簿自动地获得。 在电话号码之后，帐户持有人可以在消息字段输入向对方显示的消 息。在某些情况下，此消息可以是虚消息。在某些实施例中，帐户持 有人也可以输入补充的消息，用于记录的目的。消息字段中的特殊代 码描述了补充的消息，以指出特殊代码之后的文本是专用的，不需要 转发。代表性的特殊代码的示例可以是＊/＊/or/-/或其他唯一的用户 定义的代码。
[513]一旦SMS消息被发送到服务器，就可以由帐户持有人输 入PIN，并通过音频信道连接发送到服务器，以验证SMS消息。 PIN是通过键盘输入的，可以是任何字母数字代码。然后，PIN作 为DTMF编码消息，发送给支付服务器。
[514]在服务器上，服务器通过SMS文本消息通信路径接收 SMS消息，并通过音频信道接收PIN。对服务器的访问可以由帐户 持有人进行，也可以作为对接收到SMS消息的响应由支付服务器作 为“回叫”功能来启动。优选情况下，PIN是作为DTMF编码的消息 发送的，以维护安全性，虽然在其他实施例中，PIN可以由帐户持有 人说出，并由在支付服务器或专用于处理语音电话的另一个服务器 (未显示)上工作的交互式语音识别软件模块进行转换。
[515]为说明问题，请看当使用手机4506的帐户持有人通过发 给服务器4504的SMS消息请求帐户余额时发生的过程。SMS消 息由用户进行格式化，以包括请求的金融交易的类型，即，BALANCE (该请求的可以接受的简单形式可以是BAL，或简单地，B)，以及 与他们的帐户关联的电话号码，例如，4081234567。或者，也可以通 过使用呼叫方ID来确定帐号。
[516]当服务器4804收到SMS消息时，它首先检查序列号或 交易号(例如，参见图54、55，以及56)。如果序列号是正确的， 则服务器4804拨打与帐户关联的电话号码，并请求用户输入PIN。 在其他实施例中，PIN包括在原始SMS消息中，如此，没有必要呼 叫帐户持有人以便进行验证。如果手机1006配置有MCA，则可以 在将密码包括在SMS消息之前对它进行加密。MCA将使用数据服 务。使用SMS消息传输PIN的不利的一面是，此秘密的号码将对 可以接触电话的任何人可见，并可能导致非帐户持有人未经授权的使 用。
[517]如果PIN是正确的，则服务器4804处理请求的交易。用 户可以选择通过利用音频信道4815的语音应答或通过返回的SMS 消息(在此情况下，服务器向网关4802发送带有余额的消息，而网 关4802又将消息转发到手机4806上)来接收请求的信息。
[518]在其他金融交易中，涉及了两个手机4806和4808。这类 金融交易通常是一个帐户持有人向一个可以是与手机4808关联的 帐户持有人的收款人转帐。在其他交易中，收款人是非帐户持有人。
[519]与BAL请求相同，给手机4808的用户的PAY请求是 通过使用发给服务器4804的SMS消息启动的。SMS消息由用户 进行格式化，以包括请求的金融交易的类型，即，PAY，收款人的电 话号码(例如，6263456789)，以及与他们的帐户关联的电话号码， 再次例如，4081234567。如果帐户持有人的电话支持MCA，那么， 在手机4806和服务器4804之间交换的所有SMS消息都可以是 经过加密的，以增强安全性。
[520]当服务器4804接收到SMS消息时，它首先检查序列号 或交易号(如果可用)，只有在序列号正确或在由服务器维护的帐户 记录中表示为不可用的情况下才继续进行。然后，服务器4804接收 PIN，并判断PIN是否正确。如果序列号和PIN两者都正确，则服 务器4804通过从与帐户持有人相关联的帐户划出(参见，例如，图 43)并通过网关4802向帐户持有人发送确认SMS消息，来处理请 求的交易。
[521]如果收款人4808是帐户持有人，则服务器4802也发送 确认收到资金的确认消息。如果手机是移动PDA或其他支持IP的 设备，则消息通过HTTPS进行发送，并可以是经过加密的，以确保 安全性。加密可以通过任何已知的方法来进行。
[522]如果收款人4808是安装了MCA的帐户持有人，则 MCA可以在将消息发送到服务器4804之前对其消息进行加密，并 从服务器4804接收加密消息。
[523]如果收款人4808是帐户持有人，但是手机不支持在手机 上下载和执行MCA，那么，来自服务器4804的消息将是明语。使 用明语SMS消息传输PIN的不利的一面是，此秘密的号码将对可 以接触电话的任何人可见。这可能导致非帐户持有人的未经授权的使 用，除非帐户持有人花点时间从他们的手机的邮箱中删除SMS消 息。如果收款人4808不是帐户持有人，那么，SMS消息也将是明 语消息。
[524]尽管SMS文本消息适用于手机和某些其他类型的移动通 信设备，如便携式数字助理或PDA，但是，SMS会暴露未加密的密 码或个人标识号(PIN)，以及余额信息或有关最近的交易的机密细 节。由于拥有电话的任何人都可以阅读SMS消息文件并立即知道如 何访问另一个人的帐户和其他机密信息，因此，最好避免使用公共的 SMS消息来传输PIN。
[525]如此，对于由合作伙伴服务提供商发出的移动设备，优选 情况下，移动设备应包括MCA作为预先存在的软件模块。或者，优 选情况下，MCA可从服务提供商下载到最初没有配备MCA的手机 中。MCA对于金融交易系统的使用有显著的增强。MCA要么由帐 户持有人直接调用，要么响应移动设备上的SMS文本消息功能的激 活而调用。
[526]下面是说明了在有MCA可用的实施例中，使用SMS文 本消息来使帐户持有人从任何支持SMS的移动电话或其他支持 SMS的设备访问支付服务器的详细描述。
[527]在操作中，帐户持有人使用他们的电话上的现有的文本消 息功能来向服务器4804发送文本消息。功能包括Pay、Request Pay、Balance、History和Help，通过使用这些功能中的任何一个作 为关键字来调用这些功能。帐户持有人在文本消息的正文中输入关键 字连同补充信息，以构建发送给服务器的命令。对服务器的访问可以 通过免费的电话号码、短代码或电子邮件地址来进行，所有的这些都 向SMS网关标识该服务器。短代码的一个示例是62729，被用作文 本消息命令发送到支付服务器的目标电话号码。电子邮件地址的一个 示例是sms@obopay.com，这是发送给服务器的SMS文本消息命令 的电子邮件目标。
[528]要使用SMS方法向他人或商家进行支付，帐户持有人可 以输入表C所显示的命令字符串。
[529]表C
  关键字 PIN 目标移动电话号码 金额 消息(可选) pay ### ############ Abed
[530]在某些方案中，每一项与前一项之间都应该有间隔。在一 种实现方式中，关键字不区分大小写。移动号码可以包括区号加移动 电话号码，在移动号码中没有空格。帐户持有人可以在电话号码中输 入引导1，或不输入。美元符号不需要与金额一起输入，但是允许输 入。可选地，用户可以与他们的支付一起包括一则消息。MCA对消 息进行加密，并作为数据服务SMS消息以二进制形式进行发送，而 不是作为明语发送。
[531]表D
  关键字 目标移动电话号码 金额 消息(可选) pay ############ Abed
[533]在接收到SMS消息时，服务器4804呼叫与SMS消息 关联的手机以建立音频信道，获取PIN。PIN通过话音通信信道— 即，蜂窝网络—发送到服务器4104。在备选实施例中，PIN是通 过因特网或POTS发送的。
[534]当使用SMS方法或组合的SMS加语音方法对帐户持有 人作出支付请求时，他们可以使用手动SMS文本消息系统来接受或 者拒绝该请求。
[535]在服务器端，一个或多个数据中心将具有用于处理金融交 易的系统。每一个数据中心都将包含PBX/ACD/VRU技术的组合， 以允许多个同时的呼叫处理。可以使用VRU技术来提供可编程入站 和出站DTMF支持。VRU可以连接到表示实际业务逻辑的企业 J2EE系统和记录金融交易的记录系统。然后，J2EE系统可以与用 于进行交易结算的实际银行集成。
[536]优选情况下，MCA确定用于发送PIN的最佳方法，如通 过应用程序SMS(数据服务)，其中，SMS消息是经过加密的，并 被转换为二进制(即，消息不以明语进行传输)，或者，通过音频信 道使用DTMF来维护安全性。在其他实施例中，PIN可以由帐户持 有人说出，并由在服务器或专用于处理语音电话的另一个服务器(未 显示)上工作的交互式语音识别软件模块进行转换。
[537]在一个备选实施例中，PIN由MCA进行加密，并包括在 发送给服务器4804的后续的SMS消息中。服务器4804通过将电 话号码和每一则消息的发送时间匹配来使消息关联。如果PIN是在 与SMS消息相比在时间上较远的消息中发送的，则可以拒绝交易。 如果只接收了两个消息中的一个，则可以拒绝交易。然而，如果及时 地接收并验证了带有金融交易细节的SMS消息(至少有关键字)和 PIN代码，那么，进行金融交易。
[538]在一个备选实施例中，当有音频信道可用时，MCA可以调 用将PIN编码为DTMF形式的模块。然后，DTMF由MCA沿 着由移动客户端应用程序建立的音频信道连接发送到支付服务器。模 块可以是基于小键盘的输入而生成适当的音调的Java API。DTMF 是指双音多频，是当电话的接触键被按下时电话公司接收到的信号。
[539]在又一个备选实施例中，MCA在移动设备的显示屏幕上提 供用户界面(UI)，引导帐户持有人进行金融交易。在此实施例中，通 过自动插入关键字、金额、目标电话号码、密码，以及消息(如果有 的话)，来引导帐户持有人完成构建SMS文本消息的过程。
[540]在又一个备选实施例中，SMS消息可以包括关键字、金额、 目标电话号码和密码。此实现方式的缺点是，密码将对控制移动设备 的任何人都可见。然而，本发明通过向帐户持有人发送消息，指示用 户从帐户持有人的电话上的SMS日志文件夹中删除发送的消息，来 控制此问题。该消息也可以建议，当将来使用SMS功能进行金融交 易时帐户持有人应关闭记录传出的SMS消息的功能。
[541]本发明也可以不使用明语SMS消息，而是可以使用下载 到手机中的JAVA API来进行金融交易。JAVA API生成用户界面 屏幕，引导用户准备交易请求。消息格式与表C或表D中所显示 的格式相似。
[542]一旦帐户持有人完成了交易请求，则用户选定显示在用户 界面上的SEND选项。JAVA API使用蜂窝电话连接来启动话音呼 叫，以访问服务器7104上的交互式语音识别(IVR)模块或DTMF 接口。当DTMF接口捡起呼叫时，JAVA API使用DTMF音调来 传输交易请求。JAVA API也可以使用加密的形式，以便在万一 DTMF音调被秘密地记录的情况下不会被轻松地解密。当IVR提供 对交易请求的响应时，响应也是经过加密的，然后，使用DTMF进 行编码，并通过音频信道传输回有关方。由于JAVA API提高了安 全性，此实施例优于发送明语SMS。
[543]因此，通信可以通过音频信道和DTMF音调来进行。这 就提供了用于进行交易的另一个通信渠道(除SMS、数据服务或应 用程序SMS、HTTP，以及HTTPS之外)。通过拥有许多通信渠 道，这在系统中提供了更大的可靠性，因为当某些渠道不可用时，可 以使用其他任何渠道。
[544]图49显示了根据本发明的实施例的用于保护基于SMS 的金融交易的方法。更具体地说，对于诸如GSM手机之类的移动设 备，在手机上安装MCA涉及以物理方式插入小型电路板，被称为加 密和交易号生成器，或简称为生成器4902，以截取SMS消息通信。
[545]生成器4902包括插入到电话中的可与SIM卡4903通 电的电路。在一个实施例中，生成器4902是插入在SIM卡4903 周围的套子。或者，生成器4902是插入在手机的发射模块4904和 SIM卡4903之间的垫片。SIM卡4903是用户标识模块卡，这是 一种插入到手机或其他基于GSM、GPRS或3G的移动设备中的用 于向网络标识用户的电子卡。
[546]虽然SIM卡最广泛地用于GSM系统中，但是，兼容的 模块也用于UMTS UE(USIM)和IDEN电话中。SIM卡4903包 含用户的个人标识号，诸如用户的电话号码、电话簿、SMS消息之 类的信息，以及其他与用户相关的信息。
[547]生成器4902截取传入的SMS消息，寻找来自服务器 1004的消息(参见图48)。当生成器4902检测到由服务器4804发 送的SMS消息时，它通过对SMS数据服务消息进行解密，并给帐 户持有人呈现明语消息，就像MCA那样工作。
[548]生成器4902也截取发往服务器4804的传出的SMS消 息。再者，生成器4903还通过向每一次交易添加交易号来提供 MCA的服务，并对SMS消息进行加密。由于生成器4902包含嵌 入式软件模块，因此，它可以作为数据服务SMS消息而不是作为明 语来发送SMS消息。
[549]生成器4902计划作为单独的组件出售或以别的方式提 供，使得没有配备MCA的手机获得MCA驻留在手机上的优点。 在其他实施例中，SIM 4903是作为插件板电路来包括生成器4902 的，并通过手机的服务提供商提供给用户的。
[550]图50显示了根据本发明的一个实施例的安全的SMS聚 集服务器的用途，其中，生成器4902还将传出的SMS消息重定向 到安全的SMS聚集服务器5011，而不是重定向到服务提供商的标 准SMS服务器。通过向安全的SMS聚集服务器发送包含金融交易 信息的SMS消息，最大限度地降低了数据被窃的机会，降低了由于 SMS服务器5010中的超载而导致的消息延迟或丢失，并改善了对 消息投放系统的总体控制。
[551]现在请参看图51，该图显示了根据本发明的实施例的新帐 户持有人的注册过程。当资金的收款人还不是帐户持有人时，本发明 的一个实施例调用一个病毒式的新的客户获取方式，现有的帐户持有 人通过简单地向非帐户收款人汇款来带进新帐户持有人。非帐户收款 人收到一个SMS消息，说明他们收到了汇款，并邀请他们进行注册， 才能访问资金，如5101所示。提供了Web地址。
[552]注册可以在任何银行合作伙伴那里进行，或通过因特网访 问Web页面在线地进行注册，如5102所示。注册过程允许收款人 开立一个预存款(使用划拨的资金)贷记账户。此过程类似于开立任 何其他银行帐户，只是没有最小帐户余额，如此，甚至没有资格在银 行获得支票或储蓄帐户的个人也可以参与。
[553]一旦进行了注册，新帐户持有人具有“无卡”受限制的帐户， 如1203所示。在此阶段(阶段I)，新帐户持有人能够实时地查看 他们的预存款贷记帐户中的资金。然而，由于银行规则，新帐户持有 人的帐户的对资金的访问权限是受限制的，直到完成OFAC报告， 如5104所示，这样的报告在那里适用。“OFAC”是指美国财政部的 外国资产控制局，该局根据美国外交政策和国家安全目标，针对指定 的外国、恐怖分子、未经批准的国际毒品走私犯，以及那些参与与未 经批准的大规模杀伤性武器的扩散相关的活动的人，进行管理和实施 经济和贸易制裁。
[554]对照可疑人员名单审查帐户持有人是OFAC适应性计划 中的基本步骤。如果帐户持有人被标记为潜在的与OFAC名单匹配， 则进行调查，以判断是否事实上真的匹配。直到解决之前，资金不会 被放行。在市场上可以购买到软件程序包来用于进行适应性检查。适 应性检查识别重复的客户记录，在个人和公司之间建立链接，以便进 行传统的和非传统的家庭理财，创建多功能“家庭理财”键以随着时间 的推移跟踪变化，以及建立基于规则的处理过程以解决重复，并创建 链接和家庭理财。
[555]一旦OFAC适应性检查完成(该过程通常大约要花24 小时)，并没有发现不利的链接，帐户持有人会变为“无卡”帐户，这 意味着，金融机构可以开立预存款借记卡账户，并将塑料借记卡发送 给新帐户持有人，如5105所示。然而，在此阶段(阶段II)，新的 无卡帐户持有人对资金只有有限的支配权。例如，新帐户持有人可以 使用本发明的金融交易系统将资金转帐到其他个人，但是由于额外的 政府限制，资金不能被提取或转帐到一个商家。
[556]在本发明的系统的后端处理部分，如果收款人还不是帐户 持有人，则合并保留帐户保留着划拨的资金。总帐条目标识属于每一 个电话号码的资金(参见图39)。这些资金可以由收款人转帐到其 他帐户(如果他们注册了帐户)。由于不能强迫个人注册帐户，因此， 收款人有可能主动地拒绝资金或简单地不作回应。在这样的情况下， 在交易窗口到期之后(交易窗口可以是选定的时长，如30天或60 天)或当主动拒绝时，资金被退回到启动该交易的帐户持有人。交易 服务器可以向资金的汇款人和收款人发送定期的提醒消息。在其他情 况下，如果收款人还没有进行注册以获取访问资金的权限，则资金的 汇款人可以停止支付。此功能在各方同意取消电子转帐并以另一种方 式进行交易的情况下，很重要。
[557]如果所有帐户持有人的资金都保留在合并帐户中，那么， 当新帐户变“活”，则新帐户持有人对资金具有完全的即时的存取权 限。如果资金对于每一个帐户持有人都保留在单独的帐户中，则当帐 户变“活”时，资金从保留转帐到帐户持有人的帐户。可能有某些延迟， 资金才会出现在个人帐户中。
[558]一旦开立了帐户，并通过了适应性检查，金融机构将塑料 借记卡发送到新帐户持有人的记录中的地址。当卡到达时，帐户持有 人拨打免费电话号码，确认收到。该确认电话还表明，该帐户持有人 的地址是正确的。
[559]在拨打此电话过程中，帐户持有人还选定他们的PIN。PIN 链接到卡和帐户持有人的移动电话的电话号码两者。此外，塑料借记 卡上的帐号和电话也被锁定在一起。卡可以用来通过任何银行的 ATM从帐户中提取现金或向帐户中储蓄现金。它也可以在有POS 设备接受信用卡和银行卡的任何商家销售场所使用。在此阶段(阶段 III)，帐户持有人的帐户完全被启用，供持有人使用。
[560]现在请参看图52，分层的欺诈检测系统5200是作为交易 处理器3630的一部分显示的。分层的系统5200的第一层包括基于 规则的引擎和用户选定的组件5201。分层系统4502的第二层包括 专有的组件，帐户持有人不能访问这些组件。
[561]用户选定的组件包括，例如，帐户持有人为他们的帐户自 定义安全性的能力。帐户持有人可以链接被授权访问预存款帐户的家 庭成员的多个手机号码。对于每一个指定的电话号码，帐户持有人可 以指定每天、每周或每月的最高花费限制。帐户持有人可以通过为指 定的排除的各方创建个人“黑名单”，排除某些商家、帐号或电话号码。
[562]特定的黑名单实现方式允许帐户持有人指定通配符排除 项，如阻止向具有特定区号的任何电话或向任何“900”或外国号码进 行转帐。帐户持有人可以为被授权的用户创建单独的个人黑名单。此 功能对于控制配有手机的孩子不适当的花费特别有用。可以有任意数 量的号码或帐户包括在黑名单中。
[563]相反，帐户持有人也可以指定可以包括在涉及某一个被授 权的用户的金融交易中的某些商家或电话号码。所有其他商家和电话 号码都可以可选地被视为在个人黑名单上。再者，此功能通过允许孩 子购买车票、午餐，以及学校的供应品，但不允许购买杂志或其他新 奇品，对于控制孩子的花费特别有用。
[564]除指定个人黑名单和白名单之外，帐户持有人也可以预先 授权在出现在白名单上的每一个商家那里的购物，而对白名单上的其 他号码设置每次交易的限制。
[565]帐户持有人可以自定义基于规则的欺诈检测机制，该机制 也在第一层实现。
[566]帐户持有人也可以指定每一次交易的最高金额，以及在选 定时间段内在手机上可以处理的交易的数量。帐户持有人也可以指定 要存放和保留在预存款贷记帐户中的资金的最高金额。交易处理器 3630每天将多余的款转移到另一个指定的帐户，如个人储蓄帐户。
[567]分层系统5202的第二层包括专有的组件，帐户持有人不 能访问这些组件。例如，第二层5202包括基于历史平均值、地理验 证，日常交易的历史数量所作出的最高花费限制。这里也可以实现其 他基于规则的欺诈检测和交易频率(速度)控制机制。
[568]欺诈和风险规则引擎(未显示)，是通过应用花费限制， 并从风险的角度确定请求的交易的可接受性，来控制风险的。这样的 欺诈检测系统是已知的，常常在使用信用卡时用于监视欺诈。可以挖 掘为每一个金融交易收集的信息，供商家以及消费者增值应用程序、 商业监视应用程序、系统操作应用程序和安全监视应用程序使用。
[569]现在请参看图53，该图显示了最小化ACH和信用卡交易 费用的合并帐户实施例。本实施例不是为每一个帐户持有人维护一个 单独的预存款贷记帐户，而是利用合并预存款贷记帐户5300。当在 帐户持有人之间进行交易时，如5301所示，资金被保留在合并帐户 5300中，但是，从一个帐户持有人的帐户移到另一个帐户持有人的 帐户。转帐是直接的，对于系统运营商，不会产生任何交易费用。因 此，可以向帐户持有人收费，几乎没有交易费用，或者很少。
[570]有时，帐户持有人可以向合并帐户中添加资金，如5302所 示。这样的资金可以存放在同意从帐户持有人接受资金的合作商家那 里，然后，这些资金储蓄到合并帐户中。或者，帐户持有人可以利用 他们的塑料借记卡在ATM存现金或支票，在因特网上进行，或用电 话进行转帐，或自动地进行，如在与每一个帐户关联的用户资料页面 所指定的。
[571]在其他时候，帐户持有人可以向合并帐户之外划拨资金， 如7103所示。当新帐户持有人不希望在他们的预存款贷记帐户中保 留余额时，他们可以提取这样的资金。
[572]在此实施例中，系统运营商是帐户综合商，就风险和风险 控制而言，变为记录系统。系统运营商还负责进行OFAC适应性检 查。系统运营商可以是银行、金融机构，也可以将合并帐户管理转包 给另一个银行。
[573]在一个实施例中，使用近场通信来在移动设备之间进行通 信以使用本发明的基础架构进行金融交易。在再一个实施例中，使用 近场通信在移动设备与POS终端之间进行通信，以进行金融交易。
[574]安全性和防欺诈
[575]安全性和防欺诈对于支付行业是重要的议题，并且是持续 的问题来源。根据本发明的移动支付转帐基础架构和操作方法，是针 对这些问题的有效工具。具体来说，通过使用移动设备来进行金融交 易，可以进行实时的交易，使用的资金保证可用。接收方可以验证持 有资金的实体的合法性，以及帐户是否具有足够的余额来进行交易。 优选情况下，不必提供帐户信息(信用卡号、借记卡号或位于金融机 构中的其他帐户)即可进行交易。
[576]在交易的发起端，发送方使用PIN代码来标识通电话的 人。这种验证提供了高水平的安全性，因为支付服务器能够使用呼叫 方ID来识别移动设备，并通过PIN来识别使用移动设备的人。优 选情况下，以安全的方式转帐的资金不会以可见的形式存储在移动设 备中。
[577]另外，交易也可以通过唯一序列号码来进行标识，该唯一 序列号码是由MCA确定的，并用作命令流的一部分发送到支付服务 器。在支付服务器上，维护了所使用的序列号的历史，如此，带有以 前所使用的序列号的交易将不会被处理。在每一次交易之后和在下一 次交易之前，移动设备利用新的序列号更新该序列号。例如，新的序 列可以是旧的序列号增加1。在一种备选实现方式中，序列号可以是 任何数字，包括随机数。此外，也可以使用创建可预测的或者伪随机 数字序列的算法。此数字序列可以使用从有关诸如电话号码、时刻之 类的信息或其他信息的散列函数创建的种子来生成。在进行初始化 时，给支付服务器提供了初始序列号，知道算法和种子，如此，它可 以预测下一个应该是什么序列号。如果序列号不正确，则服务器拒绝 交易。这可以有助于防止诱骗攻击。
[578]序列号有助于防止欺诈，还避免了金融交易的重复，重复 可能是由于通信协议引起的，交易信息可能被发送多次。这类似于这 样的情况：如果传真机没有收到正常的确认，它会试图再者发送传真。
[579]如果使用SMS消息来完成交易，则授权PIN优选情况下 是朗读到移动设备中并传输到支付服务器的口头代码，以便使用语音 识别软件进行验证。
[580]商家交易优选情况下是使用活动的授权，其中，帐户持有 人的电话收到一则消息而响起，让批准转帐的美元金额。信用卡和支 票不能利用此水平的交互进行操作。
[581]通过使用PIN代码激活MCA，来提供更大的安全性。在 此实施例中，PIN代码出现在第一个实例中，打开MCA，并启动其 操作。同一个PIN代码，或者，优选情况下，一个单独的PIN代 码用于通过网络对交易进行授权。这种双PIN代码处理对信用卡、 支票或者智能卡不可用。
[582]当检测到欺诈时，可以禁用该移动设备，并阻止其使用网 络来访问帐户。一般而言，移动设备具有多个关键属性，促进未来的 安全保护。如果不是全部至少大多数这些属性不存在于卡上。具体地， 移动设备包括独立的电源来运行物理设备，如专用芯片，以及可以罩 住诸如智能芯片之类的设备的安全外壳。移动设备允许通过语音以及 通过蜂窝网络或通过因特网进行通信，如此，可以将语音验证和PIN 结合起来使用，或单独地使用，以标识帐户持有人。可以通过使用语 音识别技术并利用通过键盘输入的数据，启动和验证交易。在其他实 施例中，图像通信是通过使用照相机提供的。
[583]另一个安全层是通过使用定位技术(如地球定位系统)来 提供，或者GPS可以确定设备的物理位置。如此，如果帐户持有人 在非典型的位置(如当他们正在休假时)使用支付服务，则可以通过 要求重新输入PIN来鉴定帐户的用户。定位技术的另一个优点是， 可以基于帐户持有人所在的位置，调整对帐户持有人可用的服务。例 如，每当帐户持有人的位置匹配商家的位置时，可以与交易的确认一 起发送折扣或特殊促销信息。在其他实施例中，如果帐户持有人位于 某个正在提供特别折扣的商家的地区，则如果由支付服务器维护的该 帐户持有人的资料授权，则可以向该帐户持有人发送促销消息。
[584]图54显示了根据本发明的实施例的用于防止欺诈和多重 重复交易请求的机制和方法。防欺诈机制包括在每一个手机上的寄存 器中以及在支付服务器中存储序列号。通常，如5401所示，当激活 手机支付服务时，初始化序列号。同时，在支付服务器中初始化相同 的序列号，并与帐户持有人的其他信息一起存储在数据库中。
[585]在接收到交易请求时，如5402所示，支付服务器从手机 收到一个序列号，并将它与支付服务器中保留的序列号相比较。如果 两个序列号匹配，如5403所示，那么，支付服务器授权交易继续进 行。然后，将手机和支付服务器中的序列号更新为一个新的序列号。 此安全机制用于防止诱骗攻击或克隆电话。然后，要求用户输入他们 的PIN，如5405所示。通过将序列号与PIN和手机号码结合起来 使用，有三级安全覆盖，对用户(PIN)、电话号码(通过呼叫方ID检 测到并链接到特定帐户)和序列号进行验证，以验证交易防止入侵者 企图捕获交易，然后再提交重复的交易请求)。序列号还用于区别 SMS系统的用于提供交易消息的多次尝试与有效的多个交易。
[586]如果序列号不匹配，则支付服务器拒绝交易请求，如5406 处所示，防欺诈措施被激活，如5407处所示。作为示例，当序列号 不匹配时，帐户可以被冻结，直到客户服务代表可以确定序列号不匹 配的原因。这可能需要打电话给帐户持有人，询问他们是否仍拥有他 们的电话，以及他们是否授权进行所尝试的交易。
[587]图55显示了根据本发明的实施例的用于防止欺诈和多重 重复交易请求的机制和方法的另一个实施例。
[588]在5510，用户(即，帐户持有人)在移动电话设备(例如， 移动电话)上启动金融交易。在5511，用户在启动交易时传输PIN (选项A)。或者，如在5512所显示的，用户在启动交易时不传输 PIN(选项B)。
[589]在5513处，支付服务器从移动设备接收启动金融交易的 请求。服务器在5514检查由移动设备传输的呼叫者标识(呼叫方 ID)编号，看看移动设备是否是系统的被授权的用户。如果在电话上 没有启用呼叫方ID，则禁止交易，如5915所显示的。可以显示一 个错误消息，以指出交易被禁止，因为呼叫方ID未启用。用户可以 在启用呼叫方ID之后重试请求。
[590]如果选择了选项B，则服务器必须向移动设备发送一个 请求，要求用户传输PIN，如5516处所显示的。此PIN可以通过 移动设备的小键盘或语音(例如，向服务器的交互式语音响应(IVR) 单元)进行传输。
[591]一旦验证了呼叫方ID，则服务器对照系统中记录的PIN 检查从移动设备传输的PIN，以验证PIN是否匹配预期的电话号 码，如5517处所显示的。当且仅当PIN匹配时，服务器才允许进 行交易。如果PIN不匹配，则禁止交易，如5518处所显示的。
[592]然后，服务器从移动设备接收金融交易的交易号(也简称 为序列号)。交易号可以在启动交易时发送，或以后作为移动设备和 服务器之间的信息传输的一部分发送。交易号包括使其唯一的幂等性 密钥。
[593]服务器还对照以前已经使用的交易号列表检查来自移动设 备的当前交易号，如5519处所显示的。此列表存储在与服务器关联 的数据库中。如果当前序列号匹配以前使用的序列号中的任何一个， 则用户没有通过鉴定，交易将被禁止，如5520所显示的。此验证步 骤对防止消息的多个副本被当做新的和独立的消息有用。对于黑客已 经截取了一则消息并企图重新提交旧的交易的情况，还防止黑客攻 击。
[594]在一些实施例中，服务器还对照存储在服务器中的预期的 交易号，检查从移动设备接收到的交易号，如5521处所显示的。如 果序列号不匹配，则用户没有通过鉴定，交易将被禁止，如5520所 显示的。
[595]如果来自电话的序列号匹配存储在服务器上的序列号，或 者是以前没有使用的编号，则用户通过鉴定，将允许金融交易进行。 在一些实施例中，服务器只进行交易号验证，如5519处所显示的。 在其他实施例中，服务器只进行交易号验证，如5521处所显示的。 在其他实施例中，服务器只进行交易号验证，如5519和5521处所 显示的。只要服务器确定来自电话的序列号是以前没有使用过的，并 且/或者是预期的序列号，则将允许交易进行。序列号也可以被用作唯 一的交易标识符。
[596]服务器还存储以前的序列号，或以别的方式在服务器中表 示为已经使用的序列号，如5622处所显示的。这些以前使用的序列 号可以存储在服务器上的数据库中。如果服务器维护一个预期的序列 号，则电话和服务器中的序列号递增，以为下一次交易作准备，如 5623处所显示的。然后，服务器继续完成金融交易，如5624处所 显示的。
[597]一种三因素验证技术基于下列因素进行鉴定：
[598](1)检查呼叫方ID
[599](2)检查PIN或个人标识号
[600](3)检查交易号
[601]上面的验证方法按特定的顺序呈现一些验证步骤。本发明 的一种实现方式按给定顺序执行这些步骤。然而，在本发明的其他实 现方式中，可以有其他步骤，或者也可以省略一些步骤，或者步骤的 顺序可以不同于上面的顺序。例如，呼叫方ID、PIN，以及交易可以 不按顺序。因此，在一个实施例中，可以在呼叫方ID之前检查PIN。 在另一个实施例中，可以在PIN之前检查交易号。此外，上面的一 些步骤还可以以并行处理的实现方式在不同的处理器或处理器核心 中同时执行。
[602]在一种实现方式中，本发明的系统可以省略上面所列的一 个或多个验证技术。例如，可以不鉴定呼叫方ID，如此，将使用两 因素验证方法。
[603]两因素验证的传统的模式基于(1)您所拥有的和(2)您 所知道的。第一因素是用户所拥有的某种东西，如移动电话、个人数 字助理、智能电话，或塑料卡。第二因素是用户所知道的某种东西， 如个人标识号(PIN)、母亲的婚前姓、街道地址、社会保障号码、驾 驶执照编号，或家庭电话号码。
[604]是使用三因素还是使用两因素验证可以取决于移动设备和 服务器所使用的通信渠道。例如，当使用SMS或数据服务SMS时， 有呼叫方ID可用，则可以使用三因素验证。然而，当使用HTTP或 HTTPS时，呼叫方ID通常不可用，则将不会使用三因素验证。可 以有用于鉴定帐户持有人或用户的额外因素，如此，技术可以具有三 个以上的因素。此外，验证的第三因素可以由客户端和服务器端软件 组件来进行管理。
[605]示范性三因素验证流程
[606](1)在移动电话设备(例如，移动电话)上启动金融交易
[607](2a)(选项A)在执行步骤1时传输PIN。
[608](2b)(选项B)在执行步骤1时不传输PIN。
[609](3)在服务器上，从移动设备接收启动金融交易的请求。
[610](4)在服务器上，检查由移动设备传输的呼叫者标识(呼叫 方ID)，看看移动设备是否是系统的被授权的用户。如果在电话上 没有启用呼叫方ID，则禁止交易。可以显示一个错误消息，以指出 交易被禁止，因为呼叫方ID未启用。用户可以在启用呼叫方ID之 后重试请求。
[611](5)如果选择了选项A，一旦验证了呼叫方ID，则进入步 骤6。如果选择了选项B，一旦验证了呼叫方ID，则服务器向用户 的移动设备发送传输PIN的请求。此PIN可以通过移动设备的小 键盘或语音(例如，向服务器的交互式语音响应(IVR)单元)进行 传输。
[612](6)呼叫方ID已经验证，因此，对照系统中记录的PIN 检查从移动设备传输的PIN。如果PIN匹配，则进入步骤7。
[613](7)从移动设备接收金融交易的交易号或序列号。此交易号 可以在执行步骤1时发送，也可以以后在移动设备和服务器之间的 信息传输中发送。进入下面的8a(选项C)或8b(选项D)。
[614](8a)(选项C)对照服务器中存储的序列号，检查来自移 动设备的序列号。如果序列号不匹配，则用户没有通过鉴定，交易将 被禁止。
[615](8b)(选项D)对照存储在服务器中的以前所使用的序列 号的列表或数据库，检查来自移动设备的当前序列号。如果当前序列 号匹配以前使用的序列号中的任何一个，则用户没有通过鉴定，交易 将被禁止。
[616](9)如果来自电话的序列号匹配存储在服务器上的序列号 (对于选项C)，或者是以前没有使用的编号(对于选项D)，则 用户通过鉴定，将允许金融交易进行。对于选项D，换句话说，只要 服务器确定来自电话的序列号是以前没有使用过的，则将允许交易进 行。
[617](10a)如果选择了选项C，则电话和服务器中的序列号递 增，以为下一次交易作准备。
[618](10b)如果选择了选项D，则电话中的序列号递增到下一 个序列号。以前的序列号被存储在服务器中，或以别的方式表示为已 经使用的序列号。这些以前使用的序列号可以存储在服务器上的数据 库中。
[619]交易号或序列号验证的各种实现方式
[620](1)在服务初始化时，使用存储在移动设备和服务器上的初 始交易号值。初始交易号可以是(1a)或(1b)。
[621](1a)初始交易号可以是整数，如0，1，2，3，4，5，6，7，8，9，10， 或其他数字。
[622](1b)初始交易号可以是随机数，如由伪随机数发生器和给 定种子所生成的随机数。此种子可以是基于设备的属性或特征的散列 码。例如，种子可以基于电话号码、设备的序列号、设备的集成电路 中的属性或存储的值，或实时时钟值。
[623](2)当用户使用那些使用交易号验证的应用程序时，交易号 值将从初始或以前的交易号值变为序列中的下一个值。序列可以是任 何级数，数学的、伪随机的或其他种类的。序列可以是有限的、无限 的，或重复的级数。如果是重复级数，则在它重复之前级数中的交易 号的数量可以基于用于表示交易号的二进制比特的数量。
[624](2a)例如，序列可以是算术的或几何的。对于算术级数的 示例，交易号可以递增1或任何其他值(或递减1或任何其他值)， 以获得序列中的下一个交易号。如果使用八个二进制比特来表示交易 号，则序列将每隔256个数字就重复。如果使用十六个二进制比特 来表示交易号，则序列将每隔65536个数字就重复。因此，所使用 的比特数越多，序列就越长。
[625](2b)序列可以是由伪随机数发生器生成的伪随机数。伪随 机数的序列将基于起始的种子值。伪随机数可以使用浮点数来表示。 浮点数可以使用二进制浮点表示法来存储。
[626](3)在每一次交易之后，移动设备和服务器(在服务器中， 将对照鉴定移动设备的交易号)两者都根据相同的算法生成序列中的 下一个交易号。如果移动设备使用算术级数，则服务器也将使用算术 级数。如果移动设备使用伪随机数级数，则服务器也将使用伪随机数 级数。移动设备所使用的同一个种子也将供服务器使用。取决于特定 实现方式，此种子可以从设备传输到服务器，或者反之，或者独立地 确定。
[627](4)移动设备和服务器将各自存储相应的交易号。移动设备 上的交易号可以简称为移动设备交易号。服务器上的交易号可以简称 为服务器交易号。
[628](5)当交易进行时，服务器会将其存储的交易号与移动设备 上存储的交易号进行比较。如果交易号匹配，则验证通过，交易将被 允许进行。否则，交易将被禁止。
[629](6)在允许交易之后，在移动设备和服务器上，交易号将前 进到序列中的下一个交易号。
[630]使用交易号来鉴定移动设备的这些技术可以帮助防止欺 诈、重复交易，及其他不希望发生的情况。交易号验证的特定实现方 式会有许多变化，可以使用这些变化中的任何一种，也可以与上文所 描述的方法组合起来使用。例如，不是检查来自移动设备的交易号是 否匹配服务器上的对应的数字，验证技术可以检查交易号是否(a)不 匹配服务器上的对应的数字，(b)不匹配服务器上以前所使用的数字 (如本申请前面所述)。
[631]图57显示了序列号验证的示例。有一个消费者计算机设 备(例如，电话设备、智能电话，或便携式计算机)和企业应用程序。 在消费者计算机设备上，有序列号验证(SNA)客户端软件组件。企 业应用程序包括序列号验证服务器软件组件。当消费者设备向服务器 发送交易时，这些组件进行验证。此验证可以是三因素验证方法中的 第三因素。
[632]在特定实现方式中，客户端序列号验证组件跟踪经过加密 的计数器，该计数器以随机非零值开始，是在客户端安装过程中设置 的。在每一次交易时，客户端SNA组件都将客户端计数器值递增一 个随机非零值。服务器序列号验证组件基于客户端标识符跟踪客户端 的“最后收到的”计数器值。如果传入的客户端计数器值大于最后收到 的值，则交易被接受。计数器值被存储，交易被执行。否则，如果计 数器值不大于最后收到的值，则交易无效，可以暂停帐户。此实现方 式只是一种，序列号验证有许多可能的变化。
[633]图58显示了序列号验证的另一个示例。在此特定技术中， 取决于发起交易的客户端，使用不同类型的序列号，并将其发送给移 动支付服务服务器。例如，可以使用胖客户端或瘦客户端。
[634]胖客户端的示例包括在移动电话、智能电话、便携式计算 机或其他电子设备上执行的应用程序或程序。应用程序或应用程序的 一部分可以以诸如J2ME、BREW或.NET CF之类的编程语言进 行编写。应用程序可以是用于进行移动支付的特定的应用程序。在本 申请的别处描述了这样的程序的示例以及伴随的用户屏幕。或者功能 可以是另一个程序的一部分，如，即时消息程序、实时因特网聊天程 序、文件传送程序、音乐播放器程序、视频播放器程序、文件共享程 序、计费支付服务接口程序，或帐单分离程序。
[635]例如，当使用即时消息程序(例如，AOL Instant Messenger、 ICQ、Yahoo！Messenger、Microsoft Windows Live Messenger、Google Talk或Skype)时，将会有一个向另一个用户进行支付的选项。进 行支付的选项可以通过右键单击鼠标或通过下拉式或层叠式菜单进 行访问。接收者可以通过用户名、会员名、电话号码、会员号、帐号， 或另一个标识符来进行标识。支付将通过移动支付服务服务器进行处 理。
[636]瘦客户端的示例包括Web浏览器应用程序、具有SMS 文本消息的电话或其他设备，具有WAP浏览器的电话或其他设备， 或终端仿真程序。
[637]在本发明的特定实现方式中，当使用胖客户端时，存储的 序列号将永久地存储在胖客户端中的计数器中。此存储的序列号可以 遵循任何任意序列，如连续的整数或二进制计数器(例如，1、2、3、 4，等等)，基于已知起始种子值的随机序列，或根据等式、公式或 规则的序列。存储的序列号可以存储在，例如，快闪存储器、电可擦 除的(E^2)存储器、非易失性存储器、带蓄电池后备电源的存储器、 硬盘驱动器，或其他存储器中。
[638]对于每一次交易，向移动支付系统发送幂等性密钥(在本 发明的其他实现方式中，叫做序列号)。对于胖客户端，密钥将包括 会员ID和存储的序列号的组合。此存储的序列号可以是下一个未使 用的存储的序列号。当移动支付系统接收到胖客户端的幂等性密钥 时，交易与幂等性密钥一起被存储在交易表中。在交易表中，每一个 幂等性密钥都将希望是唯一的。如此，如果移动支付系统接收到另一 个具有以前接收到的幂等性密钥的交易，则该交易可以忽略，因为它 可能是重复交易或安全性问题。
[639]在特定实现方式中，可以用潜在的违反安全记号来标记用 户的帐户，以供人研究。如果用户具有许多这样的违规或在特定时间 段内具有许多这样的违规，那么，可以自动地暂停该帐户，以便进行 调查。
[640]在本发明的特定实现方式中，当使用瘦客户端时，幂等性 密钥将包括会员ID、目标ID、交易金额，以及时间(或时间戳)。 移动支付系统将接收此幂等性密钥，并与当接收到胖客户端幂等性密 钥时情况类似地进行处理。
[641]因此，本发明的移动支付系统可以适用于不同类型的客户 端，每一种客户端类型都可以发送不同类型的幂等性密钥或序列号。 此实施例具有两种不同类型的幂等性密钥，但是，在其他实施例中， 可以有任意数量的幂等性密钥或序列号类型。例如，可以有三种、四 种、五种、六种、七种、八种，或更多种密钥类型。
[642]使用了确保请求系统执行交易的无线传输源的真实性的 技术。交易可以是个人之间的汇款或其他价值交换交易。无线传输源 可以是移动电话或其他类似的设备。无线传输源与交易请求一起传输 密钥。系统将基于传输的密钥来确定传输的真实性。如果传输被确定 为是真实的，则对交易进行处理。讨论了用于确定真实性的各种方法。 也可以使用防止处理重复传输的技术。
[643]在一个实施例中，本发明包括接收从用户设备以无线方式 传输的价值交换交易的电子请求；与电子请求与一起接收到与电子请 求关联的传输的密钥；以及判断所述传输的密钥是否存在于交易表 中。如果传输的密钥不位于交易表中，则传输将被视为真实的。因此， 传输的密钥和价值交换交易被输入到交易表中，由系统对价值交换交 易进行处理。如果传输的密钥位于交易表中，则传输不被视为真实的 (或可能是重复传输)。因此，系统不对价值交换交易进行处理。用 户设备可以是移动电话。
[644]在一种实现方式中，传输的密钥包括标识了请求了价值交 换交易的电子标识符，以及序列号。序列号存储在用户设备中，在用 户设备传输下一个价值交换交易之前前进到序列中的下一个编号。然 后，每一次有效的传输都应该具有不同的或唯一序列号。
[645]序列号可以存储在用户设备中的非易失性或其它形式的永 久性存储器中，如快闪、电可擦除的(E^2)存储器、磁存储器，或 带蓄电池后备电源的存储器中。这将确保每一次传输都将具有唯一 值。
[646]传输的密钥可以包括伪随机数，如使用伪随机数发生器并 使用特定种子值生成的伪随机数。每次生成新的伪随机数时，种子值 都将变化，如此，将生成伪随机数的序列。
[647]在一种实现方式中，传输的密钥包括标识了请求了价值交 换交易的用户的第一电子标识符，标识了作为价值交换交易的目标的 用户的第二电子标识符，价值交换交易的金额，以及与价值交换交易 关联的时间。
[648]在一种实现方式中，价值交换交易可以是从与用户设备关 联的第一用户向与另一个用户设备关联的第二用户汇款。例如，第一 用户可以请求从第一用户的帐户向第二用户支付一定量的资金。
[649]传输的密钥不会显示在用户设备上，如此，用户将不会知 道它。这可以对于防止尝试“克隆”另一个用户的帐户并使用另一个用 户的帐户中的资金的人很有用。如果显示传输的密钥，则另一个用户 可以比较轻松地确定序列中的下一个编号，使用函数或方程来生成密 钥，或其他可以帮助对密钥进行反向工程的信息。在进一步的实现方 式中，对传输的密钥进行加密，使得截取密钥的无线传输难以进行。
[650]可以通过用户设备的SMS文本消息服务来发出电子请 求。密钥也可以使用SMS文本消息服务来进行传输。
[651]当使用不同类型的客户端或程序时，可以以不同的方式生 成或获得传输的密钥，如通过不同的函数。例如，密钥可以包括不同 的信息。当用户设备使用第一应用程序客户端发送电子请求时，密钥 可以包括第一信息，当用户设备使用不同于第一应用程序客户端的第 二应用程序客户端发送电子请求时，传输密钥可以包括第二信息。第 一信息的示例可以是包括永久地存储的序列号的密钥。第二信息的示 例可以是包括时间或时间戳的密钥。
[652]第一应用程序客户端可以是胖客户端，如在用户设备上执 行的专用的价值交换交易服务应用程序(例如，以J2ME、BREW、 或.NET CF编写的)或即时消息应用程序。第二应用程序客户端可 以是瘦客户端，如用户设备上的SMS消息应用程序、用户设备上的 WAP浏览器，或用户设备上的Web浏览器。当从胖客户端发送请 求时，可以有永久性存储的值(如存储的计数器)，这将用于密钥中。 然而，当从瘦客户端发送请求时，可能没有永久性存储的值，相反， 时间或时间戳可以用于密钥中。系统将能够处理接收不同的密钥或不 同的密钥类型。
[653]如果传输的密钥位于交易表中，这意味着，传输可能是以 前发送的，或者某人试图侵入系统。可以暂停用户的帐户，并进一步 研究事件。这将防止对用户的帐户的进一步的非法交易。
[654]此外，对价值交换交易进行处理的过程可以包括为价值交 换交易生成交易标识符号码。此交易标识符号码将由对请求进行处理 的系统生成。可以向用户设备发送包括交易标识符号码的电子消息。 交易标识符号码在用户设备上可以是可查看的。这可使用户具有交易 的参考编号，如此，用户可以直接与顾客服务代表讨论或询问有关交 易的情况。此交易标识符可以与身份验证密钥(在用户设备上生成) 完全不相关。交易标识符可以由处理交易的银行合作伙伴生成。在备 选实现方式中，密钥可以用于生成或创建交易标识符。
[655]在一个实施例中，本发明包括接收从用户设备以无线方式 传输的价值交换交易的电子请求；接收与电子请求关联的传输的密 钥；生成预期的密钥；将传输的密钥与预期的密钥进行比较；以及， 如果传输的密钥匹配预期的密钥，则处理价值交换交易。价值交换交 易可以是从与用户设备关联的第一用户向与另一个用户设备关联的 第二用户汇款，其中，用户设备是移动电话。
[656]生成预期的密钥的过程可以包括使用为与价值交换交易关 联的用户帐户存储的种子值对一个函数或方程进行求值。此外，用户 帐户也可以存储有关用来生成预期的密钥的特定函数或方程的信息。 例如，一些用户可以使用一个特定函数来生成密钥，而其他用户使用 其他函数。对于不同的用户，使用不同的起始种子，在每一次使用之 后，将创建新的种子，用于生成下一个密钥。换句话说，该方法进一 步包括在对函数进行求值之后，确定序列中的下一个种子值，并用序 列中的下一个种子值替换为用户帐户存储的种子值。
[657]例如，用户设备具有计数器，用于在特定序列中的进行计 数，并使用特定的函数(例如，伪随机数发生器)生成此序列中的密 钥。在服务器端或系统端，服务器将知道预期的密钥，因为它存储在 用户的资料中，还将知道用来生成密钥的函数。如果预期的密钥匹配 传输的密钥，那么，用户的请求通过鉴定。如上所述，所使用的函数 或方程可以每个用户地或每个设备地，或者甚至每次使用时发生变 化。用来生成预期的密钥的函数或方程的标识将存储在系统中的某 处，如存储在用户的资料中。
[658]具体来说，本发明可以包括：从与价值交换交易关联的用 户资料中检索种子值；从用户资料中检索有关用来生成传输的密钥的 函数的信息；以及，使用种子值对函数进行求值。如上文所讨论的， 本发明的方法可以包括也可以不包括不同的函数。在这样的情况下， 函数信息将不需要存储在资料中。
[659]如果传输的密钥不匹配预期的密钥，则不处理价值交换交 易。可以暂停与价值交换交易关联的用户帐户，以防止进一步的资金 转移，因为已经发生了违反安全的情况。可以向系统管理员对帐户进 行标记(例如，显示在屏幕上，发送电子邮件，发送即时消息)，让 系统管理员进一步进行研究。或者可以发送一个自动化电子邮件，以 联络顾客服务代表，因为用户的帐户已经发生了违反安全的情况。
[660]对价值交换交易进行处理的过程可以包括：为价值交换交 易生成不同于预期的密钥的交易标识符号码，向用户设备发送包括 交易标识符号码的电子消息，其中，交易标识符号码显示在用户设备 上。
[661]支付系统基础架构—移动客户端应用程序(MCA)
[662]在一个实施例中，MCA基于Java 2平台，企业版 (J2EE)，这是简单直观的界面。结果，帐户持有人输入他们的请求数 据—如金额、电话号码，或其他帐户身份信息，如接收方帐户的电子 邮件地址或即时消息ID，以及PIN。MCA设计得配置起来灵活简 便，对于不同的语言，具有不同的版本，设计为在Java 2 Mobile Edition(J2ME)、.NET、以及WAP、BREW、Symbian，以及SIM Toolkit或其他移动协议下运行，并可以端接到诸如蜂窝设备、PDA 或其他移动电子设备之类的平台上。Java、.Net、Brew、Symbian和 Sim Toolkit被认为是它们的相应的所有者的商标。MCA还可用于 电话操作系统，包括Nokia、Motorola、Samsung、Sanyo，及其他 常见的品牌。优选情况下，在移动设备上不需要特别的半导体器件或 “芯片”执行安全的经济合算的，以及移动金融交易。
[663]为启动操作，帐户持有人在他们的移动电话上安装(或已 经安装)MCA。应用程序的提供可以以下列方式进行：
[664](1)以无线方式使用WAP推的方式提供，支付服务器向 帐户持有人发送消息，以启动应用程序下载。或者，帐户持有人可以 使用WAP拉的方式，向支付服务器发送消息，以启动该处理；
[665](2)在用户服务中心、合作商家位置近距离地提供，或移动 服务提供商可以通过蓝牙、红外线或其他近场无线连接，安装MCA；
[666](3)因特网下载，帐户持有人可以通过因特网下载该程序， 并通过USB端口安装它—或者甚至可以从一个电话将程序下载 到另一个电话中；或者
[667](4)在SIM卡上，帐户持有人可以购买在SIM卡上已经 安装了MCA的设备。
[668]在示例情况下，用户具有配备有近场通信功能的移动设备。 用户可以查看他希望购买的产品。用户将用户的移动设备放在与产品 关联的近场通信设备的附近。然后，移动设备的显示器查询用户是否 同意交易，以购买产品。如果用户批准，则处理交易。用户将接收商 品，如从交货地点领取，或者商品可以投递到用户的邮件地址处。可 以提示用户输入PIN或质询问题，以验证他们已经批准交易。
[669]本发明的一个方面是移动支付系统或服务。本申请讨论了 单个组件和元件的许多特定实施例和实现方式，这些实施例和实现方 式的变化和修改，以及它们的组合。本发明的系统可以包括所讨论的 变化或特定实现方式中的任何一种，单独地或以任何组合的形式。在 本申请中，提供了移动支付系统的特定实现方式的示例，此特定实现 方式是Obopay系统。Obopay系统只是移动支付系统的一种实现方 式，用于比较轻松地描述本发明的各个方面。本发明包含了许多移动 支付系统实现方式，不仅限于所描述的特定实现方式。
[670]移动应用程序处理移动客户端应用程序(MCA)
[671]移动客户端应用程序允许人们通过他们的移动设备支付给
朋友、商店，以及划拨资金。帐户持有人可以利用支持文本消息或移 动因特网功能的移动设备，访问MCA，进行汇款或从任何人请求汇 款。他们也可以实时地看到他们预存款贷记帐户的余额和历史。
[672]MCA支持下列功能：支付、余额、历史、请求支付、设置， 帮助。可以使用MCA从一个帐户持有人帐户向其设备支持文本消息 的任何移动用户汇款。要进行汇款，必须是帐户持有人；然而，向其 汇款的人或商家可以不是。
[673]金融交易可以由付款人或者收款人启动。如果付款人启动 交易，则使用MCA来启动交易。要使用MCA从预存款贷记帐户 汇款，帐户持有人将经过下列步骤序列：
[674](1)打开帐户持有人的移动设备上的MCA。这将把帐户持 有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按“输入” 继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单， 包括支付、余额、历史、请求支付、设置，和帮助。
[675](2)然后，帐户持有人选择“支付”选项，进行汇款。这将把 帐户持有人带到“支付”屏幕，帐户持有人将输入他们希望向其汇款的 电话号码。
[676](3)要选择帐户持有人的电话簿中的电话号码，帐户持有人 将选择选项(从移动设备上的左下方的软键)，然后查找(从选项菜 单)，将显示出帐户持有人的现有电话地址簿，并允许他们选择其中 的一个姓名。可选地，帐户持有人可以直接从小键盘输入电话号码。 在另一个实施例中，帐户持有人输入短代码来标识所需的商家收款 人。一旦帐户持有人输入了移动电话号码，他们将选择“确定”。
[677](4)这将把他们带到金额屏幕，帐户持有人将输入他们希望 支付的金额。取决于收款人的资料，可能出现小费屏幕，提供给帐户 持有人向金额中添加他们希望支付的小费的机会。
[678](5)当帐户持有人选择“确定”，他们将被带到消息屏幕，他 们可以向他们的交易中添加消息。此消息可以是文本、音频或视频附 件。如果帐户持有人不希望添加消息，他们可以只需在写入消息之前 点击“确定”，将不会向交易中添加消息。如果传输网络的带宽有限， 则帐户持有人会在消息的类型和长度方面受到限制。如果交易的接收 方没有能够处理视频或音频消息的移动设备，则消息可以短时间地存 储在服务器上，以允许通过因特网进行后续的检索。
[679](6)一旦帐户持有人选择“确定”，他们将被带到PIN屏 幕，在此，他们将输入PIN，并选择“确定”。当输入PIN时，字母 数字字符不会出现在屏幕上，而是显示伪字符。此外，也不能在移动 设备上的消息日志或其他日志中查找PIN。如果另一个人能接触到移 动设备，则他们将不能够确定PIN。
[680]这将把帐户持有人带到确认屏幕，该屏幕将显示下列信息：
[681]支付到：(目标电话号码)
[682]金额：
[683]任何相关交易费用：
[684]消息(如果他们留了的话)
[685]一旦帐户持有人选择了“确定”，则他们将被带到具有下列 信息的屏幕：
[686]付款人
[687]如果目标收款人有现有的帐户
[688]消息
[689]支付到：(目标电话号码)
[690]金额
[691]日期：mm/dd/yyyy hh:mm
[692]Trans：xxxx
[693]如果目标收款人没有现有的预存款贷记帐户，那么，会出 现这样的消息，如：注意：您支付的收款人不是注册的帐户持有人。 给收款人发送一则消息，带有如何接收款项的指示。
[694]消息
[695]支付到：(目标电话号码)
[696]金额
[697]日期：mm/dd/yyyy hh:mm
[698]交易：xxxx
[699]收款人：
[700]如果目标收款人是现有的帐户持有人，则收款人将接收到 一则消息，说明他们有一笔新的款项被添加到他们的帐户中。当他们 打开该款项时，他们将看到一个带有下列信息的交易收据：
[701]日期：mm/dd/yyyy hh:mm
[702]金额：
[703]来自：(付款人电话号码)
[704]如果目标收款人还没有现有的预存款贷记帐户，则收款人 将接收到文本消息，说“您收到一笔款！”，并指示他们到诸如 www.obopay.com之类的网站，进行注册，成为帐户持有人，并接收 他们的资金。在本文档中稍后详细描述了新帐户持有人的注册过程。
[705]如果金融交易由收款人启动，则使用MCA，通过请求付款 人进行支付来启动交易。收款人启动的交易的一个示例是，比萨饼外 卖服务店在递送比萨饼之前拨打订购了比萨饼的人的电话号码。当通 过移动设备应答时，帐户持有人被给予通过本发明的移动支付基础架 构来进行付款的机会。
[706]要使用MCA从一个预存款贷记帐户请求资金，帐户持有 人将经过下列类似的步骤序列：
[707](1)打开帐户持有人的移动设备上的MCA。这将把帐户持 有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按“输入” 继续。这将把帐户持有人带到主菜单画面，显示MCA的功能的菜单， 包括支付、余额、历史、请求支付、设置，和帮助。
[708](2)然后，帐户持有人选择“请求”选项，请求进行支付，将 输入他们希望发送他们的请求的电话号码。
[709](3)要选择帐户持有人的电话簿中的电话号码，帐户持有人 将选择选项(从移动设备上的左下方的软键)，然后查找(从选项菜 单)，将显示出帐户持有人的现有电话地址簿，并允许他们选择其中 的一个姓名。此地址簿可以对应于，作为说明，请求了比萨饼外卖的 帐户持有人的电话号码列表。作为请求的一部分，外卖人可以附加一 个小费屏幕，提供给帐户持有人向金额中添加他们希望支付的小费的 机会。
[710](4)当收款人选择“确定”，他们将被带到消息屏幕，他们可 以向他们的交易中添加消息。在一个实施例中，此消息可以是文本、 音频或视频附件。如果收款人不希望添加消息，他们可以只需在写入 消息之前点击“确定”，将不会向交易中添加消息。
[711](5)一旦帐户持有人选择“确定”，他们将被带到PIN屏幕， 在此，他们将输入PIN，可选地输入小费，并选择“确定”。请求将被 发送给付款人，付款人可以通过输入他们的PIN并按“确定”来批准 交易的选项。正如上文所指出的那样，PIN是机密的，并且安全的， 如此，未经授权的人不能只通过获得对移动设备的未经授权的访问来 确定PIN。
[712]将首先处理支付，收款人将接收到支付通知。如果交易没 有问题，则帐户持有人将不会接收到任何进一步的通知。如果支付确 实出现问题的话(即，资金不足)，则将会通知帐户持有人和目标收 款人。有关支付所发生的任何问题的通知将在进行支付之后迅速地发 出，以便各方都可以确认交易。
[713]帐户持有人也可以使用MCA来从他们的移动设备检查预 存款贷记帐户的当前余额。要使用MCA检查余额，帐户持有人将经 过下列步骤：
[714](1)打开帐户持有人的电话上的MCA。
[715](2)这将把帐户持有人带到开始屏幕，显示徽标和标记行。 帐户持有人将按Enter键继续。
[716]这将把帐户持有人带到主菜单画面，显示MCA的功能的 菜单，包括支付、余额、历史、请求支付、设置，和帮助。帐户持有 人将选择“余额”以检查他们的余额。
[717]这将把帐户持有人带到PIN屏幕，在此，他们将输入 PIN，并选择“确定”。
[718]这将把帐户持有人带到余额屏幕，该屏幕将提供下列信息：
[719]日期：MM/DD/YYYY HH:MM
[720]余额：
[721]当帐户持有人选择“确定”时，他们将被带回主菜单画面。
[722]帐户持有人可以使用MCA从移动设备中查看最后n次 交易的历史，其中，n是整数(例如，3或5)，以及预存款贷记帐 户的当前余额。要使用MCA检查历史，帐户持有人将经过下列步骤：
[723](1)打开帐户持有人的移动设备上的MCA。这将把帐户持 有人带到开始屏幕，显示徽标和标记行。然后，帐户持有人按Enter 键继续。
[724](2)这将把帐户持有人带到主菜单画面，显示MCA的功能 的菜单，包括支付、余额、历史、请求支付、设置，和帮助。帐户持 有人将选择“历史”以查看他们的历史。
[725](3)这将把帐户持有人带到PIN屏幕，在此，他们将输入 PIN，并选择“确定”。
[726](4)这将把帐户持有人带到历史屏幕，该屏幕将提供下列信 息：
[727]交易日期和交易金额：MM/DD(+/-)$.$$
[728]帐户持有人将能够选择列出的交易中的任何一个，以获得 有关该特定交易的详细信息。为此，他们滚动浏览到他们希望查看的 具体交易，并选定它。这将把他们带到具有下列信息的屏幕：
[729]日期：MM/DD/YYYY HH:MM:SS
[730]金额：(+/-)$.$$
[731]收件人：收款人或付款人的电话号码)
[732]消息：(如果可用)
[733]然后，帐户持有人选定“确定”回到历史屏幕。从这里，他 们可以查看另一个交易或返回到主菜单画面。
[734]此外，帐户持有人还可以将他们的帐户与计帐应用程序软 件链接，以便每一笔交易都记录在数据库中，用于预算、计划、跟踪 或用于缴税。在此实施例中，帐户持有人可以根据金融交易的特征， 添加说明支付的第二消息，是发出还是接收。例如，当帐户持有人在 出差途中购买了一顿饭，则第二消息可以指出交易是减税的，可补偿 成本的。通过计帐应用程序软件来记录费用。计帐应用程序软件可以 由服务器平台提供(参见图3)或由软件提供商合作伙伴提供。计帐 应用程序软件可以是一个增值选项，帐户持有人可以支付每月的费用 才能访问。
[735]当帐户持有人选择退回软键时，他们将被带回主菜单画面。
[736]正如上文所指出的那样，帐户持有人可以使用MCA从任 何其他帐户持有人的帐户请求资金。请求资金的帐户持有人和向其请 求资金的帐户持有人两者都应该是帐户持有人。要使用MCA从帐户 持有人请求支付，请求方帐户持有人将经过下列步骤。打开请求方帐 户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕， 显示徽标和标记行。帐户持有人按Enter键继续。这将把帐户持有 人带到主菜单画面，显示MCA的功能的菜单，包括支付、余额、历 史、请求支付、设置，和帮助。
[737]帐户持有人将选择“请求支付”，以请求进行支付。这将把 帐户持有人带到“发送给”屏幕，帐户持有人将输入他们希望向其发送 他们的支付请求的移动电话号码。要选择帐户持有人的电话簿中的电 话号码，帐户持有人将选择选项(从移动设备上的左下方的软键)， 然后查找(从选项菜单)，将显示出帐户持有人的现有电话地址簿， 并允许他们选择其中的一个姓名。一旦帐户持有人输入了移动电话号 码，他们将选择“确定”。
[738]这将把他们带到金额屏幕，帐户持有人将输入他们希望支 付的金额。请求方帐户持有人选择他们是否希望请求小费(即，请求 者除他们正在请求的金额之外添加一个金额的能力。当帐户持有人选 择“确定”，他们将被带到消息屏幕，他们可以向他们的交易中添加文 本或音频或视频消息。如果帐户持有人不希望添加消息，他们可以在 写入消息之前点击“确定”，将不会向交易中添加消息。
[739]一旦帐户持有人选择“确定”，他们将被带到PIN屏幕，在 此，他们将输入PIN，并选择“确定”。这将把帐户持有人带到确认屏 幕，该屏幕将显示下列信息：
[740]发送给：(目标电话号码)
[741]金额：
[742]小费请求(开/关)
[743]任何相关交易费用：
[744]消息(如果他们留了的话)
[745]一旦帐户持有人选择了“确定”，则他们将被带到具有下列 信息的屏幕：
[746]请求者
[747]消息
[748]发送给：(目标电话号码)
[749]金额
[750]日期：mm/dd/yyyy hh:mm
[751]交易：xxxx
[752]被请求者：
[753]被请求者将从支付服务器接收到他们具有新的款项的消 息。当帐户持有人打开款项时，它将打开MCA，这将把帐户持有人 带到开始屏幕，显示徽标和标记行。帐户持有人按Enter键继续。 然后，帐户持有人将被带到支付请求那里，在那里，他们将看到下列 信息。
[754]消息(如果适用的话)
[755]支付到：(请求者电话号码)
[756]金额
[757]日期：mm/dd/yyyy hh:mm:
[758]交易ID
[759]收款人将能够接受或者拒绝对支付的请求。如果收款人接 受请求，则他们将选择“接受”软键。如果收款人接受请求，小费请求 已经由请求方帐户持有人进行了设置，接受请求将会把收款人带到小 费金额屏幕，他们可以添加小费。一旦输入小费，选定“确定”，帐户 持有人将被带到PIN屏幕。一旦收款人输入他们的PIN，选定“确 定”，他们将被带到确认屏幕。确认屏幕包括下列信息：
[760]支付到：(支付请求者电话号码)
[761]金额
[762]小费(如果适用的话)
[763]一旦收款人选择了“确定”，则交易将被处理，收款人将被 带到具有下列信息的屏幕：
[764]发送给：(支付请求者电话号码)
[765]金额
[766]余额：
[767]日期：MM/DD/YYYY HH:MM
[768]交易：(交易ID)
[769]一旦收款人选择“确定”，他们将返回到主菜单画面。
[770]如果收款人拒绝请求，他们将选定“拒绝”软键。支付请求 者将接收有关他们的支付请求是被接受还是被拒绝的通知。通知将包 括下列信息：
[771]消息：(如果适用的话)
[772]来自：(收款人电话号码)
[773]金额：
[774]日期：MM/DD/YYYY HH:MM:SS
[775]交易：
[776]帐户持有人可以更改帐户持有人可配置的默认设置。当前， 这包括更改他们用来在他们的移动设备和服务器之间发送和接收支 付信息协议(即，SMS或HTTP)。这也可以包括应用程序的将来 版本中的其他帐户持有人可配置的信息。要更改他们的MCA上的设 置，帐户持有人将经过下列步骤：打开帐户持有人的移动设备上的 MCA。
[777]这将把帐户持有人带到开始屏幕，显示徽标和标记行。帐 户持有人按Enter键继续。这将把帐户持有人带到主菜单画面，显 示MCA的功能的菜单，包括支付、余额、历史、请求支付、设置， 和帮助。
[778]帐户持有人将选定“设置”以更改他们的设置。这将把他们 带到设置屏幕，他们可以选定他们希望修改的设置。当前，只有一个 选项是协议。当帐户持有人选择协议时，他们将被带到协议屏幕。帐 户持有人将能够在协议屏幕上选定HTTP或者SMS。默认情况下， 他们的应用程序被设置为HTTP。要返回到协议屏幕，帐户持有人将 必须选定“退回”软键。要返回到主菜单，帐户持有人将必须选定“退 回”软键。
[779]帐户持有人将能够从MCA查看“帮助”屏幕。这将包括应 用程序的简要的描述，以及有关帐户持有人到哪里获得更多帮助的说 明。要查看MCA的“帮助”部分，帐户持有人将经过下列步骤。打开 帐户持有人的移动设备上的MCA。这将把帐户持有人带到开始屏幕， 显示徽标和标记行。帐户持有人将必须按Enter键继续。
[780]这将把帐户持有人带到主菜单画面，显示MCA的功能的 菜单，包括支付、余额、历史、请求支付、设置，和帮助。帐户持有 人将选定“帮助”，查看帮助。这将把帐户持有人带到主“帮助”屏幕， 该屏幕将提供下列链接：
[781]MCA的简要描述，如：
[782]Obopay可供您使用电话进行汇款、进行购物，以及催付款。 还可以使用您的借记卡进行购物和提取现金。还有：
[783]到显示例如下列各项的功能页面：
[784]当执行下列操作时，您将被要求输入帐户持有人的电话号 码，金额，以及PIN。还有：
[785]支付功能，显示，例如：
[786]利用移动或VOIP电话，使用Obopay支付功能向任何人 进行汇款。如果他们没有预存款贷记帐户，则他们将被定向网站，建 立一个帐户。要取消支付，请访问obopay.com了解详情。
[787]余额功能，显示，例如：
[788]使用“余额”功能了解您的帐户中可用的金额。
[789]历史功能，显示，例如：
[790]使用“历史”了解最近的交易以及可用余额。选定一个以了 解详情。
[791]请求支付，显示，例如：
[792]使用“请求支付”要求移动电话帐户持有人付款。添加消息 和要求小费是可选的。
[793]到“输入信息”上的帮助页面的链接，显示，例如：
[794]电话号码-当选定“支付”或“请求支付”时，输入带有区号 的电话号码。无短划线或空格。
[795]金额，显示，例如：
[796]在$0.01-$9999.99之间。不必添加小数点—为美元金额 添加零
[797]您的PIN，显示，例如：
[798]当您激活您的帐户时，提供您的PIN。如果您忘记了，请 拨打888-80BOPAY
[799]链接到快捷方式的帮助页面
[800]退回：返回到前页屏幕。
[801]清除：擦除键入的最后一个字符。
[802]联系人：访问您的地址簿。
[803]退出：关闭应用程序。
[804]链接到FAQ的帮助页面
[805]安全性
[806]Obopay通过在网络层、应用程序层和交易层对交易进行加 密，提供了安全的交易。有关详细信息，请访问www.obopay.com
[807]数据(因特网)计划
[808]您不需要数据计划即可使用Obopay。然而，您将需要数据 计划，将Obopay下载到新的电话中。此外，数据计划还可以优化 Obopay服务的性能。
[809]成本？
[810]提款吗？
[811]在接受信用卡的任何ATM中使用您的借记卡，或在 www.obopay.com网站从Obopay请求支票
[812]取消交易
[813]要取消与非帐户持有人的交易，请访问 www.obopay.com/help，选定“取消支付”。向帐户持有人的支付只能 在交易未经授权(欺诈)的情况下才能被取消。要取消未经授权的交 易，请拨打888-8OBOPAY
[814]添加资金吗？
[815]请访问www.obopay.com，选定“加载帐户”按钮
[816]忘记PIN。
[817]如果您忘记了，请拨打888-8OBOPAY
[818]链接到“技术支持”的帮助页面
[819]有关详细信息，请访问obopay.com或拨打 888-8OBOPAY
[820]链接到“关于”的帮助页面
[821]软件版本
[822]文件大小：
[823]优选情况下，MCA允许帐户持有人创建离线资料，可以被 配置为当他们的移动设备被关闭或在范围之外时自动响应。例如，帐 户持有人可以配置他们的帐户，以自动吸收存款或自动接受从指定的 帐户持有人的提款。如果帐户持有人的移动设备被打开，则可以通过 拨到支付服务器，进行余额查询或历史请求，就可以检索任何离线交 易。在其他替代方案中，帐户持有人可以指定，帐户信息通过SMS或 电子语音邮件提供。
[824]有线协议
[825]MCA和平台有线协议
[826]概述
[827]MCA和平台有线协议与MCAP编解码器结合使用，以序 列化/解序列化运行MCA的各种设备和提供基于J2EE的主机服 务的数据中心之间的通信的数据。MCA和平台有线协议指定了在设 备和数据中心之间传输的序列化数据的格式。MCAP编解码器是移 动设备上的组件，数据中心根据MCA和平台有线协议规范，处理序 列化和解序列化。图59显示了基本概念的简单例图。请查询 MCAP体系结构文档，以了解这里未说明的涉及基础架构的另外的 组件。
[828]下面显示了来自移动设备的服务请求和示例有线表示。
[829]由移动设备启动的服务请求是Paymentservice.payP2P调 用。此函数执行帐户持有人与帐户持有人之间的支付，Java方法签 名是：
[830]public PaymentSummary pay P2P(
[831]         String srcDevKey，
[832]         String srcPin，
[833]         String tgtDevKey，
[834]         String transactionAmount，
[835]         String paymentMemo)throws Exception；
[836]附图中说明了返回值之外的一切。作为响应，除了开销， 还包括返回值，返回值字符串以对象类型代码开始(在此情况下，9， 转换为CommonPaymentSummary)，返回值的非空的属性跟随其后， 例如，属性#1—paymentAmount—具有$1.27值等等。
[837]现在请参看图60，该图是显示了通过调用 PaymentService.retrieveBalance调用，成功地调用服务电话的示例。 此调用检索帐户的帐户余额。
[838]public BalanceSummary retrieveBalance(
[839]        String devKey，
[840]        String pin)throws Exception；
[841]
[842]请求部分与前一示例完全相同，虽，响应现在表示由于服 务电话而引发异常。对象类型6表示类型EWPBusinessException 的返回值，在图61中说明了其属性。
[843]来自移动设备的另一个服务请求和示例有线表示是 PaymentService.retrieveHistory调用。如名称所指出的，此函数检索 帐户的交易历史。
(844]public TransactionSummary[]retrieveHistory(
[845]              String devKey，
[846]              String pin)throws Exception；
[847]图62演示了成功的调用，这里唯一值得注意的是，返回 值的“对象类型”(10)现在后面跟了阵列标志“<”，这意味着，返回值 是对象类型10的阵列，表示Common TransactionSummary。
[848]另一个设备启动的服务请求是用于从另一个会员请求支付 的requestPay函数。
[849]public PayRequestSummary requestPay(
[850]          String srcDevKey，
[851]          String srcPin，
[852]          String tgtDevKey，
[853]          String transactionAmount，
[854]          Boolean tipRequest，
[855]          String memoText)throws Exception；
[856]payRequestPay函数用于对requestPay调用进行响应，此 调用批准请求的支付。
[857]public PayRequestSummary payRequestPay(
[858]          String payerDevKey，
[859]          String payerPin，
[860]          String tgtDevKey，
[861]          String paymentAmount，
[862]          String tipAmount，
[863]          Boolean acceptRequest，
[864]          String transactionRef，
[865]          String memoText)throws Exception；
[866]另一个函数是RegistrationService.whoAmI函数，该函数 与数据中心建立服务，当第一次调用应用程序时，被调用。
[867]public String whoAmI(String deviceNumber)throws Exception；
[868]另一个请求的类别是由服务器发送的那些请求，这些请求 的特征是，(1)它们当前只通过SMS发送；(2)它们通常是从服务 器到设备的事件的通知；(3)没有对这样的请求的同步响应。
[869]为与处理设备启动的调用的MCA和平台体系结构一致， 本发明在设备上作为“设备服务”实现了这样的通知的处理程序，与当 从服务器端调用这些“设备服务”上的方法时，有相同的ServiceProxy 签名。编解码器和有线协议与由设备启动的那些请求完全相同。这里 是当前可用的“设备服务”和它们的方法的列表：
[870]J2ME支付服务
[871]P2pNotify—将p2p支付通知给目标
[872]requestPay—将requestPay请求通知给会员。
[873]notifyRequestPayReceived—将接收到请求支付的请求支 付操作通知给目标。
[874]cancelViralNotify—将“病毒式”支付通知给“病毒式”目标
[875]MCAP的技术概述
[876]可以轻松地定义其他设备服务，并将它们添加MCA，它们 被认为是基于特定实施例的设计考虑。
[877]现在讨论了MCA &平台(MCAP)的高水平的设计，以 及用户界面(UI)，呈现了MCAP预期的并且是所需的完整的一套 移动功能。MCAP基本上是“移动钱包”或“通过电话支付”的消费者/ 移动-商家应用程序。MCAP的用户界面简单，它只需要一步接一步 地输入请求数据(如金额、PIN，等等)，然后显示响应数据。通过 例图和比较，MCAP的用户界面不需要移动游戏应用程序的图形复 杂性。
[878]优选情况下，MCAP以轻松地被移植以在尽可能多的移动 设备上执行的语言进行编写。然而，MCAP基础架构预期某些功能 存在于移动设备上。例如，需要显示输入字段和捕获帐户持有人输入 内容的功能。如果通过编程SMS API调用利用移动设备的SMS文 本服务的能力不可用，则还需要通过编程性的HTTPS API调用来利 用移动设备的数据服务的能力。
[879]通过编程API调用，利用移动设备的持久数据服务。例如， 在SIM卡上或其他非瞬时存储器中永久地存储数据的能力是可选 的功能。类似地，截取到移动设备的入站消息并“MCAP”以便进行处 理的能力也是可选的。此功能提供，例如，截取入站SMS消息(在 特定端口上)并通过MCAP处理它的能力。以编程方式与移动设备 的“地址簿”集成以便特定输入字段可以“链接”到地址簿的能力也是 可选的。通过声音、振动或光将值得注意的事件以编程方式将值得注 意的事件通知给移动设备帐户持有人的能力是可选的。
[880]优选情况下，MCAP是模块化的，以便它在J2ME上轻 松地实现，并在.NET以及J2ME、BREW、Symbian，以及.NET CF(以前的Windows Mobile)上证明
[881]图63显示了移动设备的高水平OMAP设计层。
[882]图64是显示了使用单一文本字符串(带有分隔参数/值对) 的OMAP通信设计和请求/响应编码方案的流程图。
[883]图65显示了OMAP持久性设计，利用了移动设备永久 性存储器机制，以及显示了OMAP用户通知设计的状态图。
[884]图66显示了实施例的OMAP屏幕调色板。
[885]图67是显示了OMAP屏幕转换的状态图。
[886]图68显示了OMAP主菜单的布局。
[887]图69显示了从来源角度来看的OMAP支付屏幕流程。 在本发明的其他实施例中，“支付资金”功能可以叫做“汇款”。
[888]图70显示了从来目标角度来看的OMAP支付屏幕流 程。
[889]图71显示了从源-请求角度来看的OMAP请求支付屏幕 流程。在本发明的其他实施例中，“请求支付”功能可以叫做“获取资 金”。
[890]图72显示了从目标-接受角度来看的OMAP接受支付屏 幕流程。
[891]图73显示了其中目标拒绝请求的OMAP请求支付屏幕 流程。
[892]图74显示了其中源和目标两者都接受请求的OMAP请 求支付屏幕流程。
[893]图75显示了其中源和目标两者都拒绝请求的OMAP请 求支付屏幕流程。
[894]图76显示了OMAP余额屏幕流程。
[895]图77显示了OMAP历史屏幕流程。
[896]图78显示了在源位置处的OMAP设置屏幕流程。
[897]图79和80显示了OMAP系统屏幕流程。具体来说， 图79显示了未知移动ID的OMAP的屏幕流程。图80显示了其 中请求失败的OMAP系统异常屏幕流程。
[898]金融服务API
[899]移动设备和电子钱包平台(EWP)服务代理之间的接口包 括诸如支付服务和注册服务之类的服务组件，以及其高水平的异常对 象的层次结构。还描述了从服务调用返回的业务数据传输类。
[900]支付服务
[901]根据EWP的应用程序服务基础架构定义，定义和实现了 此业务服务。支付服务包括对合作银行系统的通路方法调用。合作银 行管理正式的记录系统、支付处理，以及帐户和会员信息。EWP内 管理的超出与合作银行集成所需的数据仅供内部使用。
[902]程序包：
[903]com.ewp.services
[904]类：
[905]public interface PaymentServiceInterface
[906]public class PaymentServiceImplemenation implements
[907]PaymentServiceInterface
[908]为此服务定义的应用程序编程接口(API)有：
[909]payP2P-在两个消费者会员之间执行帐户持有人与帐户持 有人(p2p)之间的交易
[910]retrieveBalancee-检索指定的帐户的可用余额
[911]retrieveHistory-检索指定的帐户的最后五个交易记录，包 括显示了可用余额的第六行
[912]requestPay-由两部分组成的交互的第一步骤，一个会员从 另一个会员请求进行支付
[913]payRequestPay—由两部分组成的交互的第二步骤，支付 请求的收款人要么付款或者拒绝付款
[914]在下列小节中提供了详细信息。注意，返回的任何货币值 将作为Java.lang.String类型呈现，格式为.。例如，二十美元五十五美分的字符串表示 为“$20.55”。
[915]方法签名：payP2P
[916]此方法支持从移动设备呼叫，以向具有与移动设备号码关 联的帐户的另一个会员进行支付。交易结果被发送到调用的会员的移 动电话。此外，还向收款人发送接收到资金的通知。
[917]public PaymentSummary payP2P(
[918]String srcDevKey，
[919]String srcPin，
[920]String tgtDevKey，
[921]String transactionAmount，
[922]String paymentMemo)
[923]throws Exception
[924]输入参数：
[925]srcDevKey·字符串值，通常是启动支付的帐户的电话号码
[926]srcPin·字符串值，发出请求的帐户的PIN
[927]tgtDevKey·字符串值，通常是接收支付的帐户的电话号码
[928]transactionAmount·字符串值，向接收方帐户进行支付的 金额。
[929]paymentMemo·字符串，从付款人到收款人的短语。
[930]返回类型对象：
[931]PaymentSummary·包括目标帐号、支付金额，以及可用 余额数据的容器对象。有关详细信息，参见PaymentSummary类描 述。
[932]方法签名：retrieveBalance
[933]此方法支持从移动设备呼叫以获得会员的当前帐户余额。 结果被发送到调用的会员的移动电话。
[934]public BalanceSummary retrieveBalance(
[935]String devKey，
[936]String pin)
[937]throws Exception
[938]输入参数：
[939]devKey·字符串值，通常是正在请求其余额的帐户的电话 号码
[940]pin·字符串值，发出请求的帐户的PIN
[941]返回类型对象：
[942]BalanceSummary·包括可用余额数据的容器对象。有关详 细信息，参见BalanceSummary类描述。
[943]方法签名：retrieveHistory
[944]此方法支持从移动设备呼叫，以检索会员的五个最近的交 易，并在其历史显示中包括当前帐户余额。结果被发送到调用的会员 的移动电话。
[945]public TransactionSummary[]rerrieveHistory(
[946]String devKey，
[947]String pin)
[948]throws Exception
[949]输入参数：
[950]devKey·字符串值，通常是正在请求其交易历史的帐户的 电话号码
[951]pin·字符串值，发出请求的帐户的PIN
[952]返回类型对象：
[953]TransactionSummary []·容器对象的阵列，每一个容器对 象都包括金额值、贷记/信用/余额，以及交易数据的时间戳。有关详 细信息，参见TransactionSummary类描述。
[954]方法签名：payRequestPay
[955]此方法支持从移动设备呼叫，以接受或者拒绝对支付的请 求。交易结果被发送到支付会员的移动电话。此外，还向收款人发送 接收到资金的通知。
[956]public PayRequestSummary payRequestPayMobile(
[957]String payerDevKey，
[958]String payerPin，
[959]String tgtDevKey，
[960]String paymentAmount，
[961]String tipAmount，
[962]Boolean acceptRequest，
[963]String transactionRef，
[964]String requestText，
[965]String memoText)
[966]throws Exception
[967]输入参数：
[968]payerDevKey·字符串值，通常是履行支付请求的帐户的 电话号码(与payP2P的源相同)
[969]payerPin·字符串值，是履行支付请求的帐户的PIN
[970]tgtDevKey·字符串值，要么是接收支付的帐户的电话号 码，要么是用于向与接收支付的帐户关联的设备标识JNDI连接键的 引用键
[971]paymentAmount·字符串值，向接收方帐户进行支付的金 额。
[972]tipAmount·字符串值，要添加到交易总和中的小费支付 金额
[973]acceptRequest·布尔值，指出是否接受支付请求(true＝ 接受)
[974]transactionRef·字符串值，来自原始支付请求的交易参考 编号
[975]requestText·字符串，从请求进行支付的帐户持有人到进 行付款的帐户持有人的短语。
[976]memoText·字符串，从付款人到收款人的短语。
[977]返回类型对象：
[978]PayRequestSummary·包括交易参考编号、目标帐号、支 付金额，以及可用余额数据的容器对象。有关详细信息，参见 PayRequestSummary类描述。
[979]方法签名：requestPay
[980]此方法调用设备服务方法，将来自另一个会员的支付请求 的情况通知给目标会员。
[981]public PayRequestSummary requestPay(
[982]String srcDevKey，
[983]String srcPin，
[984]String tgtDevKey，
[985]String transactionAmount，
[986]Boolean tipRequest，
[987]String requestText)
[988]throws Exception
[989]输入参数：
[990]srcDevKey·字符串值，要么是启动支付请求的帐户的电 话号码，要么是用于向与作出支付请求的帐户关联的设备标识JNDI 连接键的引用键
[991]srcPin·字符串值，发出请求的帐户的PIN
[992]tgtDevKey·字符串值，通常是应该接收支付请求通知的 帐户的电话号码
[993]transactionAmount·字符串值，请求的支付的金额。
[994]tipRequest·布尔值，指出是否向请求收款人呈现小费请 求屏幕。
[995]requestText·字符串，从支付请求者到进行付款的帐户持 有人的短语。
[996]返回类型对象：
[997]PayRequestSummary·包括交易参考编号、目标帐号、支 付金额，以及可用余额数据的容器对象。有关详细信息，参见 PayRequestSummary类描述。
[998]注册服务
[999]根据EWP的应用程序服务基础架构定义，定义和实现了 此业务服务。注册服务提供了用来供Web服务从合作银行系统呼叫 回EWP系统的方法。尽管合作银行维护了正式的帐户和会员信息， 但是，EWP必须知道会员的预存款借记卡号码和会员的移动电话号 码之间的映射。此数据，潜在地更多，将在EWP系统中持久存在下 去。