CN103635920A - 通用电子付款装置、方法与系统 - Google Patents

Abstract

通用电子付款装置、方法与系统(“UEP”)经UEP组件把输入虚拟钱包移动应用界面的触摸屏输入变换成购买交易触发与收据通知。在一种实现中，UEP经用户设备提供产品信息搜索请求；并且响应该产品信息搜索请求而获得关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息。利用关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息，UEP生成单个购买交易请求。UEP经用户设备提供所述单个购买交易请求，用于付款处理。而且，UEP获得关于由第一商家出售的第一产品和由第二商家出售的第二产品的电子购买收据。

Description

通用电子付款装置、方法与系统

用于专利证书公开文档的本专利描述了包括各种新颖创新的发明性方面(下文中称为“公开内容”)并且包含服从版权、布图设计和／或其它知识产权保护的素材。这种知识产权的对应所有者不反对任何人对在公开的专利局文件／记录中出现的公开内容所进行的传真复制，但是除此之外在任何情况下都保留所有权利。

优先权要求

本申请依据美国法典35章119条要求以下专利申请的优先权：于2011年2月22提交、标题为“UNIVERSAL ELECTRONICPAYMENT APPARATUSES，METHODS AND SYSTEMS”且代理人案号为P-42051PRV|20270-136PV的美国临时专利申请序列号61／445,482；于2011年10月11日提交、标题为“UNIVERSALELECTRONIC PAYMENT APPARATUSES，METHODS ANDSYSTEMS”且代理人案号为P-42051US01|20270-136PV1的美国临时专利申请序列号61／545,971；于2011年4月8日提交、标题为“APPARATUSES，METHODS AND SYSTEMS FOR ANAPPLICATION INTERGATION PAYMENT PLATFORM”且代理人案号为P-42189PRV|20270-147PV的美国临时专利申请序列号61／473,728；于2011年3月22日提交、标题为“ELECTRONICwALLET”且代理人案号为P-41963PRV|20270-148PV的美国临时专利申请序列号61／466,409；于2011年3月31日提交、标题为“APPARATUSES，METHODS AND SYSTEMS FOR ATARGETED ACCEPTANCE PLATFORM”且代理人案号为P-41838PRV|20270-062PV的美国临时专利申请序列号61／469,965；及于2011年9月23日提交、标题为“ELECTRONIC WALLETTRANSACTION CONSUMER LEASH APPARATUSES，METHODSAND SYSTEMS”且代理人案号为93US01|20270-194PV的美国临时专利申请序列号61／538,761。

依据美国法典35章120条和365条，本申请还是以下专利申请的部分继续并要求其优先权：于2012年2月16提交、标题为“SNAP MOBILE PAYMENT APPARATUSES，METHODS ANDSYSTEMS”且代理人案号为P-42032US01|20270-127US的美国非临时专利申请序列号13／398,817；及于2012年1月11提交、标题为“UNIVERSAL VALUE EXCHANGE APPARATUSES，METHODSAND SYSTEMS”且代理人案号为P-41948US01|20270-089US的美国非临时专利申请序列号13／348,634。

以上提到的申请的全部内容都明确地通过引入，包含于此。

技术领域

本创新总体上针对用于电子商务的装置、方法与系统，而且更具体地说包括通用电子付款装置、方法与系统(“UEP”)。

背景技术

消费者交易一般要求消费者从商店货架或网站选择产品，然后在结帐柜台或者网页结帐离开。产品信息选自网页目录或者输入到销售点终端，或者信息是通过利用在销售点终端集成的条形码扫描器扫描物品的条形码自动输入的。通常为消费者提供多种付款选项，例如现金、支票、信用卡或借记卡。一旦进行了付款并得到认可，销售点终端就在商家的计算机系统中记住该交易，并且生成指示交易圆满完成的收据。

附图说明

附录和／或附图说明了根据本公开内容的各种非限制性、示例、发明性方面：

图1示出了说明在UEP的有些实施例中虚拟移动钱包购买的示例方面的框图；

图2A-B示出了说明在UEP的有些实施例中虚拟钱包应用的购物模式的示例方面的用户界面图；

图3A-C示出了说明在UEP的有些实施例中虚拟钱包应用的发现购物模式的示例方面的用户界面图；

图4A-B示出了说明在UEP的有些实施例中虚拟钱包应用的购物车模式的示例方面的用户界面图；

图5示出了说明在UEP的有些实施例中虚拟钱包应用的账单支付模式的示例方面的用户界面图；

图6A-B示出了说明在UEP的有些实施例中虚拟钱包应用的(本地附近)商家购物模式的示例方面的用户界面图；

图7示出了说明在UEP的有些实施例中在虚拟钱包应用中为购买付款分配资金的示例方面的用户界面图；

图8示出了说明在UEP的有些实施例中在虚拟钱包应用中选择资金转移收款人的示例方面的用户界面图；

图9A-B示出了说明在UEP的有些实施例中虚拟钱包应用的示例附加方面的用户界面图；

图10A-B示出了说明在UEP的有些实施例中虚拟钱包应用的历史模式的示例方面的用户界面图；

图11A-C示出了说明在UEP的有些实施例中在虚拟钱包应用及相关联的收入共享方案中创建用户购物跟踪的示例方面的用户界面与逻辑流图；

图12A-I示出了说明在UEP的有些实施例中虚拟钱包应的快照模式的示例方面的用户界面与逻辑流图；

图13A-B示出了说明在UEP的有些实施例中虚拟钱包应用的提议项模式的示例方面的用户界面与逻辑流图；

图14示出了说明在UEP的有些实施例中虚拟钱包应用的通用设置模式的示例方面的用户界面图；

图15示出了说明在UEP的有些实施例中虚拟钱包应用的钱包耦合设置模式的示例方面的用户界面图；

图16A-C示出了说明在UEP的有些实施例中虚拟钱包应用的购买控制设置模式的示例方面的用户界面图；

图17A-C示出了说明在UEP的有些实施例中配置虚拟钱包应用设置并实现购买控制设置的示例方面的逻辑流图；

图18示出了说明在UEP的有些实施例中集中式个人信息平台的示例方面的框图；

图19A-F示出了说明在UEP的有些实施例中集中式个人信息平台中数据模型的示例方面的框图；

图20示出了说明在UEP的有些实施例中示例UEP组件配置的框图；

图21示出了说明在UEP的有些实施例中一种示例搜索结果聚合过程的数据流图；

图22示出了说明在UEP的有些实施例中聚合搜索结果的示例方面(例如，搜索结果聚合(“SRA”)组件2200)的逻辑流图；

图23A-D示出了说明在UEP的有些实施例中基于卡的示例交易执行过程的数据流图；

图24A-E示出了说明在UEP的有些实施例中基于卡的交易执行的示例方面(例如，基于卡的交易执行(“CTE”)组件2400)的逻辑流图，其中基于卡的交易执行导致基于卡的交易数据和服务使用数据的生成；

图25示出了说明在UEP的有些实施例中聚合基于卡的交易数据的示例过程的数据流图；

图26示出了说明在UEP的有些实施例中聚合基于卡的交易数据的示例方面(例如，交易数据聚合(“TDA”)组件2600)的逻辑流图；

图27示出了说明在UEP的有些实施例中示例社交数据聚合过程的数据流图；

图28示出了说明在UEP的有些实施例中聚合社交数据的示例方面(例如，社交数据聚合(“SDA”)组件2800)的逻辑流图；

图29示出了说明在UEP的有些实施例中用于登记增值服务的示例过程的数据流图；

图30示出了说明在UEP的有些实施例中社交网络支付认证登记的示例方面(例如，增值服务登记(“VASE”)组件3000)的逻辑流图；

图31A-B示出了说明在UEP的有些实施例中把聚合的搜索、登记的服务使用、交易和／其它聚合数据正规化成标准化数据格式的示例方面(例如，聚合数据记录正规化(“ADRN”)组件3100)的流程图；

图32示出了说明在UEP的有些实施例中识别正规化的聚合数据记录中数据字段的示例方面(例如，数据字段识别(“DFR”)组件3200)的逻辑流图；

图33示出了说明在UEP的有些实施例中分类实体类型的示例方面(例如，实体类型分类(“ETC”)组件3300)的逻辑流图；

图34示出了说明在UEP的有些实施例中识别跨实体相关的示例方面(例如，跨实体相关(“CEC”)组件3400)的逻辑流图；

图35示出了说明在UEP的有些实施例中把属性关联到实体的示例方面(例如，实体属性关联(“EAA”)组件3500)的逻辑流图；

图36示出了说明在UEP的有些实施例中更新实体简档图的示例方面(例如，实体简档图更新(“EPGU”)组件3600)的逻辑流图；

图37示出了说明在UEP的有些实施例中为简档图更新生成搜索项的示例方面(例如，搜索项生成(“STG”)组件3700)的逻辑流图；

图38示出了说明在UEP的有些实施例中基于聚合的购买交易数据分析用户行为的示例方面(例如，用户行为分析(“UBA”)组件3800)的逻辑流图；

图39示出了说明在UEP的有些实施例中基于用户之前的聚合购买交易行为为用户生成推荐的示例方面(例如，基于用户行为的提议项推荐(“UBOR”)组件3900)的逻辑流图；

图40示出了说明在UEP的有些实施例中经社交网络的付款交易的示例方面的框图；

图41示出了说明在UEP的有些实施例中示例社交支付登记过程的数据流图；

图42示出了说明在UEP的有些实施例中社交支付登记的示例方面(例如，社交支付登记(“SPE”)组件4200)的逻辑流图；

图43A-C示出了说明在UEP的有些实施例中的示例社交付款触发过程的数据流图；

图44A-C示出了说明在UEP的有些实施例中社交付款触发的示例方面(例如，社交付款触发(“SPT”)组件4400)的逻辑流图；

图45A-B示出了说明在UEP的有些实施例中实现钱包安全性与设置的示例方面(例如，某物(“WSS”)组件4500)的逻辑流图；

图46示出了说明在UEP的有些实施例中的示例社交商家消费者桥接过程的数据流图；

图47示出了说明在UEP的有些实施例中社交商家消费者桥接的示例方面(例如，社交商家消费者桥接(“SMCB”)组件4700)的逻辑流图；

图48示出了说明在UEP的有些实施例中虚拟钱包应用的示例特征概观的用户界面图；

图49A-G示出了说明在UEP的有些实施例中处于购物模式的虚拟钱包应用的示例特征的用户界面图；

图50A-F示出了说明在UEP的有些实施例中处于付款模式的虚拟钱包应用的示例特征的用户界面图；

图51示出了说明在UEP的有些实施例中处于历史模式的虚拟钱包应用的示例特征的用户界面图；

图52A-E示出了说明在UEP的有些实施例中处于快照模式的虚拟钱包应用的示例特征的用户界面图；

图53示出了说明在UEP的有些实施例中处于提议项模式的虚拟钱包应用的示例特征的用户界面图；

图54A-B示出了说明在UEP的有些实施例中处于安全性与隐私模式的虚拟钱包应用的示例特征的用户界面图；

图55示出了说明在UEP的有些实施例中示例用户购买结帐过程的数据流图；

图56示出了说明在UEP的有些实施例中用户购买结帐的示例方面(例如，用户购买结帐(“UPC”)组件5600)的逻辑流图；

图57A-B示出了说明在UEP的有些实施例中示例购买交易授权过程的数据流图；

图58A-B示出了说明在UEP的有些实施例中购买交易授权的示例方面(例如，购买交易授权(“PTA”)组件5800)的逻辑流图；

图59A-B示出了说明在UEP的有些实施例中示例购买交易清除过程的数据流图；

图60A-B示出了说明在UEP的有些实施例中购买交易清除的示例方面(例如，购买交易清除(“PTC”)组件6000)的逻辑流图；及

图61示出了说明UEP控制器的实施例的框图。

附图中每个标号的开始数字指示那个标号在其中被介绍和／或详述的图。因此，标号101的具体讨论将在图1中找到和／介绍。标号201在图2中介绍，等等。

具体实施方式

通用电子付款(UEP)

通用电子付款装置、方法与系统(下文中称为“UEP”)经UEP组件把输入虚拟钱包移动应用接口的触摸屏输入变换成购买交易触发和收据通知。图1示出了说明在UEP的有些实施例中虚拟移动钱包购买的示例方面的框图。在有些实现方式中，UEP可以促进虚拟钱包，例如100，用于进行购买交易。例如，用户101可以使用移动设备102(例如，智能电话、平板电脑等)对购物车103(例如，实体商店的物理购物车、在线购物站点的虚拟购物车)的内容进行购买交易，可选地在销售点(PoS)客户端104处(例如，在实体商店的传统终端、在在线购物站点的计算设备、具有虚拟钱包应用的其他用户、用于人到人的资金转移等)。用户可能能够从一张或多张卡中选择，用于交易，从虚拟卡包选择的卡存储在移动设备上执行的虚拟移动钱包应用中。当选择了卡选项中的一个或多个时，移动设备可以(例如，经单向／双向近场通信[NFC]、蓝牙、Wi-Fi、蜂窝连接、创建并捕捉QR码的图像等)把卡选择信息传送到进行购买交易的PoS终端。在有些实施例中，在交易授权完成后，移动设备可以获得购买收据。各种附加特征可以经移动设备上执行的虚拟移动钱包应用提供给用户，如在以下参考至少图2-54的讨论中进一步描述的。

图2A-B示出了说明在UEP的有些实施例中虚拟钱包应用的购物模式的示例方面的用户界面图。参考图2A，在有些实施例中，用户可以利用虚拟钱包应用201参与购买交易。在本文所述的各种实施例中，虚拟钱包应用可以提供促进用户的购物体验202的许多特征。例如，虚拟钱包应用可以允许用户执行对产品203的广泛搜索，如在以下参考图2B的讨论中进一步讨论的。

在有些实现方式中，虚拟钱包应用可以提供“发现购物”模式211。例如，在用户设备上执行的虚拟钱包应用可以与服务器通信。服务器可以向虚拟钱包提供关于跨总体上广泛的消费者的消费者趋势的信息。例如，服务器可以指示总体上消费者参与什么类型的交易、他们在买什么、他们注意什么评论等等。在有些实现方式中，虚拟钱包应用可以利用这种信息来提供图形化的用户界面，方便用户导航通过这种聚合信息，例如在以下参考图3A-C的讨论中所描述的。例如，聚合信息的这种生成可以通过UEP使用集中式个人信息平台组件来促进，其中集中式个人信息平台组件在以下参考图18-37的讨论中描述。

在有些实现方式中，虚拟钱包应用可以允许用户同时维护多个购物车，例如212-213。在有些实现方式中，这种购物车可以是用于在线网站的完全虚拟的购物车，但是在备选实现方式中，可以反映商家商店中物理购物车的内容。在有些实现方式中，除非另外规定，否则虚拟钱包应用可以允许用户规定用户期望的物品将缺省地放在其中的当前购物车。在有些实现方式中，虚拟钱包应用可以允许用户改变当前的购物车(例如，213)。在有些实现方式中，虚拟钱包应用可以允许用户创建可以在线或者在社交网络上公布的愿望清单，以便传到用户的朋友。在有些实现方式中，虚拟钱包应用可以允许用户查看、管理并且为用户付账单，214。例如，虚拟钱包应用可以通过拍摄账单的快照、通过输入足以让虚拟钱包应用建立与账单所关联的商家通信的关于账单的信息等来允许用户把账单导入虚拟钱包应用接口。

在有些实现方式中，虚拟钱包应用可以允许用户在参与虚拟钱包的商家的商品目录中购物。例如，商家的商品目录可以在虚拟钱包应用中为用户提供，以便进行购买。在有些实现方式中，虚拟钱包应用可以在虚拟钱包应用的图形用户界面中为用户提供虚拟店面。因此，用户可以虚拟地进入参与UEP虚拟钱包应用的商家的商店。

在有些实现方式中，虚拟钱包应用可以利用用户设备的位置坐标(例如，经GPS、IP地址、蜂窝塔三角测量等)来识别在用户当前位置附近的商家。在有些实现方式中，虚拟钱包应用可以利用这种信息向用户提供关于本地商家的商品目录的信息，和／或可以虚拟地使商家的商店进入用户的虚拟钱包应用。

在有些实现方式中，虚拟钱包应用可以提供售货员204。例如，用户可以走进商家的物理商店。用户在购物体验中可能需要帮助。在有些实现方式中，虚拟钱包应用可以允许用户求助售货员(见217)，而且商家商店中的商店主管可能能够经另一个设备帮助用户。在有些实施例中，用户可以进入一个商店(例如，物理的实体商店、[经计算设备的]虚拟在线商店等)，参与购物体验。用户可以有用户设备。用户设备102可以具有在其上执行的虚拟钱包移动应用，包括例如本文所述那些的特征。进入商店后，用户设备可以与商店管理服务器通信。例如，用户设备可以传送地理位置坐标、用户登录信息和／或类似的登记进入信息，以便自动登入商店。在有些实施例中，UEP可以在登入后把用户加进虚拟钱包商店。例如，在用户设备上执行的虚拟钱包应用可以提供如下所述的特征，来增进用户的店内购物体验。在有些实施例中，商店管理服务器可以通知消费者服务代表(“CSR”)用户到达商店。例如，CSR可以具有CSR设备，而且一个应用(“CSR应用”)可以在其上执行。例如，该应用可以包括例如在以下本文的讨论中所描述的特征。CSR应用可以通知CSR用户的进入，包括提供关于用户简档的信息，例如用户的身份、用户先前与最近的购买、用户在当前和／或其它商家的消费模式等。在有些实施例中，商店管理服务器可能能够访问用户先前的购买行为、用户的实时店内行为(例如，用户利用用户设备扫描了什么物品的条形码、用户扫描条形码花了多长时间、用户通过扫描相似类型物品的条形码参与比较性购物了吗，等等)、用户的消费模式(例如，跨时间、商家、商店、地理位置等分辨)等用户简档信息。商店管理系统可以利用这种信息分别经CSR设备和／或用户设备向CSR和／或用户提供提议项／优惠券、推荐等。在有些实施例中，CSR可以在购物体验中帮助用户。例如，CSR可以传达提议项、优惠券、推荐、价格比较等，而且可以代表用户执行动作，例如向用户的物理／虚拟购物车添加／除去物品、对用户的购买应用／除去优惠券、搜索提议项、推荐、提供商店地图或者存储3D浸入视图(immersion view)等。在有些实施例中，当用户准备好结帐时，UEP可以向用户设备和／或CSR设备提供结帐通知。用户可以利用在用户设备上执行的用户的虚拟钱包应用来结帐，或者可以利用通信机制(例如，近场通信、刷卡、QR码扫描等)向CSR设备提供付款信息。利用该付款信息，UEP可以为用户启动购买交易，并且向用户设备和／或CSR设备提供电子收据。利用电子收据，用户可以带着购买付款的证据离开商店。

参考图2B，在有些实施例中，虚拟钱包应用221可以响应用户提供搜索关键字和／或用于搜索查询的过滤器而提供广泛的搜索结果222。例如，在图2B的说明中，用户搜索包括通过拍摄物品快照(如以下更具体地讨论的)获得的“Acme”并且日期在年份“2052”的所有物品(见223)。在有些实现方式中，搜索结果可以包括用户的历史交易231、基于用户的行为模式、优惠券232、账单234、折扣、人到人的转账请求236等给予用户的提议项(235，对于新账户，用户可以把它导入虚拟钱包应用)和／或推荐，或者基于商家商品目录可用性的提议项，等等。例如，搜索结果可以根据类型、日期、描述或提议项来组织。在有些实现方式中，描述可以包括先前价格的列表(例如，在先前购买的时候)、在之前购买其的同一地方的当前价格和／或与物品相关的其它提议项(见例如231)。有些提议项可以堆放在彼此顶部，例如，它们可以应用到同一笔交易。在有些情况下，例如，像账单的支付(见234)，物品可以由自动支付系统来支付。在更多实现方式中，用户可以具有手动支付或者定期支付、暂停支付(例如，在预定的时间量之后显示付款提醒，考虑到延迟付款，要收取附加的利息)和／或修改其它设置(见234)的能力。在有些实现方式中，用户可以把列出的一个或多个物品添加到购物车224、237。例如，用户可以把物品添加到缺省的当前购物车，或者可以输入备选(或者新购物车／愿望清单)的名称，来添加物品，并且通过激活图形用户界面(“GUI”)元素237来提交命令。

图3A-C示出了说明在UEP的有些实施例中虚拟钱包应用的发现购物模式的示例方面的用户界面图。在有些实施例中，虚拟钱包应用可以为用户提供“发现购物”模式。例如，虚拟钱包应用可以获得关于与用户有关的人群样本的聚合购物行为的信息，并且可以为用户提供关于购买行为的统计／聚合信息，作为方便用户购物的指导。例如，参考图3A，发现购物模式301可以提供基于产品目录来划分的聚合消费者行为的视图(见302)。例如，在以下参考图18-37的讨论中描述的集中式个人信息平台组件可以方便为虚拟钱包应用提供这种数据。因而，虚拟钱包应用可以提供特定市场分割中消费者支出数量的可视化，并且生成代表消费者支出的那些数量的可视表示(见303-306)。在有些实施例中，虚拟钱包应用还可以提供虚拟钱包应用的用户的相对支出(见蓝色的条)的指示器(见309)；因而，用户可能能够总体上可视化用户的购买行为与消费者行为之间的区别。用户可能能够关闭用户的购买行为指示器(见310)。在有些实施例中，虚拟钱包应用可以允许用户放大和缩小可视化，使得用户可以按照用户的期望获得适当粒度的视图(见307-308)。在任何时候，用户都可能能够把可视化复位到缺省比例(见311)。

类似地，发现购物模式321可以提供基于跨网络的专家观点聚合表单来划分的对专家观点的聚合消费者响应视图(见302)。例如，以下在参考图18-37的讨论中所述的集中式个人信息平台组件可以方便为虚拟钱包应用提供这种数据。因而，虚拟钱包应用可以提供消费者倾向于同意关于各种产品分类的各种专家观点有多好，及总体上谁的观点对消费者有重大关系(见323-326)。在有些实施例中，虚拟钱包应用还可以提供虚拟钱包应用的用户的相对开支(见蓝色的条)的指示器(见329)；因而，用户可能能够总体上可视化用户的购买行为与消费者行为之间的差异。用户可能能够关闭用户的购买行为指示器(见330)。在有些实施例中，虚拟钱包应用可以允许用户放大和缩小可视化，使得用户可以按照用户的期望获得适当粒度的视图(见327-328)。在任何时候，用户都可能能够把可视化复位到缺省比例(见331)。

参考图3B，在有些实施例中，虚拟钱包应用可以允许用户创建用于购买的、有针对性的购物规则(见图3A，312、322)。例如，用户可以利用消费者聚合行为和专家观点数据来构思关于何时自动地启动购买的规则。作为一个示例，规则341规定，如果其消费者报告分级在3月1日之前降至低于3.75／5.0，则虚拟钱包应当向用户卖iPad2，假定可以获得$399的销售价格。作为另一个示例，规则342规定，如果规则341在2月15日之前成功，则虚拟钱包应当买iPad3。作为另一个示例，规则343规定，如果其Slashdot分级在2月1日之前大于3.75，则钱包应当买来自Android市场的低于$349.99的Moto Droid Razr。类似地，在发现模式中，可以为有针对性的购物生成许多具有广泛变化与依赖性的规则。在有些实现方式中，虚拟钱包用户可以允许用户修改规则。例如，钱包可以为用户提供类似于346或347的界面。用户可以根据用户的期望利用规则编辑器工具箱中可用的工具来设计规则。在有些实现方式中，钱包还可以为服从有针对性的购物规则的物品提供市场现状。

参考图3C，在有些实现方式中，虚拟钱包应用可以提供市场观望特征，其中可以为用户跟踪并可视表示与服从有针对性的购物规则的物品关联的趋势。例如，在有些实现方式中，可视化可以采取票表的形式，其中对比每个物品351(A)-(E)列出与该产品相关的产品目录或专家观点群集352、价格指示器，包括但不限于：规则创建时的价格352、查看市场观望屏幕时的价格353及物品(A)-(E)的目标价格。基于这些价格，市场观望屏幕可以为服从有针对性的购物规则的每件物品提供趋势符号(例如，上、下、不变等)。在物品满足有针对性的规则的时候(见物品(E))，一旦满足目标价格，虚拟钱包就自动地启动对那件物品的购买交易。

图4A-B示出了说明在UEP的有些实施例中虚拟钱包应用的购物车模式的示例方面的用户界面图。参考图4A，在有些实现方式中，虚拟钱包应用可能能够为用户存储、维护和管理多个购物车和／或愿望清单(401-406)。购物车可以是完全虚拟的，或者它们可以代表商家商店中物理购物车的内容。用户可以激活列出的任何购物车，查看目前存储在购物车中的物品(例如，410-416)。在有些实现方式中，虚拟钱包应用还可以提供愿望清单，例如高科技愿望清单417，这个清单具有用户期望作为礼物得到的物品(见418-419)。在有些实现方式中，虚拟钱包应用可以允许用户利用弹出菜单，例如420，快速地根据另一个购物车或愿望清单改变购物车或愿望清单。

参考图4B，在一种实现方式中，用户可以选择一个特定的物品来获得该物品的详细视图，421。例如，用户可以查看与交易关联的物品的详情及每件物品的金额、商家等，422。在各种实现方式中，用户可能能够在这个视图中执行附加的操作。例如，用户可以(再次)购买物品423、获得该物品的第三方评论并且写该物品的评论424、把照片添加到物品从而与物品一起组织与该物品相关的信息425、把物品添加到相关物品的组(例如，家用)426、提供分级426或者泛泛地查看来自用户的朋友或者来自网络的快速分级。例如，这种系统可以用在以下参考图18-37的讨论中所述的示例集中式个人信息平台组件来实现。用户可以把照片添加到交易。在进一步的实现方式中，如果用户先前经社交通道共享了该购买，则包括照片的帖子可以生成并发送到社交通道，以便公布。在一种实现方式中，任何共享都是可选的，而且不经社交通道共享购买的用户仍然可以直接从钱包应用的历史模式通过他或她选择的一个或多个社交通道共享照片。在另一种实现方式中，用户可以把交易添加到一个组，例如公司开支、家庭开支、旅行开支或者用户设置的其它分类。这种分组可以方便年终的开支记账、工作开支报告的提交、增值税(VAT)退款的提交、个人开支等。在还有另一种实现方式中，用户可以买在该交易中购买过的一种或多种物品。于是，用户不用去商家的目录或站点找这些物品就可以执行交易。在进一步的实现方式中，用户还可以在购物车中存放该交易中的一种或多种物品，以便以后购买。

在另一种实施例中，虚拟钱包可以提供获得并显示交易中物品分级427的方便。分级的来源可以是用户、用户的朋友(例如，来自社交通道、联系人，等等)、从网络聚合的评论等。有些实现方式中的用户界面还可以允许用户向社交通道(例如，TWITTER或FACEBOOK)的其他用户发消息。例如，显示区域428示出了在两个用户之间交换的FACEBOOK消息。在一种实现方式中，用户可以经消息429共享链接。对具有到产品的嵌入式链接的这种消息的选择可以允许用户查看产品的描述和／或直接从历史模式购买该产品。

在有些实现方式中，钱包应用可以为用户显示商店跟踪，例如430。例如，用户可能已经在多个网站(例如，ElecReports、APPLFanBoys、Gizmo、Bing、Amazon、(例如，根据用户偏好自动地检查各种来源来寻找可用的最佳价格并且向用户提供提议项的)VisaSmartbuy特征，等等)调查了一种产品，这可能把用户引导到用户最终购买产品的最终商家网站。在有些实现方式中，UEP可以识别用户访问过的网站、对用户决定买产品有帮助的网站，并且可以由于对用户进入销售点网站并且在那里购买产品有贡献而奖励它们通过“销售点”网站获得的收入的份额。例如，网站可以与产品制造商、批发商、零售店、支付服务提供商、支付网络等彼此之间有关于产品放置、广告、用户重定向等的协定。相应地，UEP可以利用收入共享模型在用户的购物跟踪中为每个网站计算收入份额，并且为网站提供收入共享。

在有些实现方式中，虚拟钱包可以提供SmartBuy有针对性的购物特征。例如，用户可以为用户想买的产品422设定目标价格431。虚拟钱包可以为那个产品提供实时市场观望状态更新432。当用户可以获得的市场价格降至低于用户的目标价格431时，虚拟钱包可以自动为用户买下该产品，并且向用户提供发货／通知。

图5示出了说明在UEP的有些实施例中虚拟钱包应用的账单支付模式的示例方面的用户界面图。在有些实现方式中，虚拟钱包应用可以响应用户激活了图2A中的元素214而提供对账单的搜索结果列表501-503。在有些实现方式中，搜索结果可以包括用户的历史结算交易及即将到来的账单(例如，511-515)。例如，搜索结果可以根据类型、日期、描述来组织。在有些实现方式中，描述可以包括以前价格的列表(例如，在之前购买的时候)、在之前购买其的同一地方的当前价格和／或与物品相关的其它提议项(见例如511)。在有些情况下，例如像账单支付(见514)，物品可以由自动支付系统来支付。在进一步的实现方式中，用户可以具有手动支付或者定期支付、暂停支付(例如，在预定的时间量之后显示付款提醒，考虑到延迟付款，要收取附加的利息)和／或修改其它设置的能力(见514)。

图6A-B示出了说明在UEP的有些实施例中虚拟钱包应用的(本地附近)商家购物模式的示例方面的用户界面图。在有些实现方式中，在激活图2A中元素215或216之后，虚拟钱包应用可以分别给出屏幕600和610，如在图6A中绘出的。在图6A，600，中，虚拟钱包应用显示参与UEP的虚拟钱包的商家列表，例如601-605。类似地，在图6A，610，中，虚拟钱包应用显示在用户附近的位置参与UEP的虚拟钱包的商家列表。用户可以点击在两个屏幕600和610中列出的任何商家，加入到该商家的商店商品目录。在加入之后，可以为用户给出例如620的屏幕，这个屏幕类似于以上在参考图4A的描述中所讨论过的屏幕(中间)。而且，在有些实现方式中，如果用户点击在屏幕620上列出的任何物品，则用户可以被带到屏幕630，这个屏幕类似于在以上参考图4B的描述中讨论过的屏幕。参考图6B，在有些实施例中，用户可以加入商家的虚拟现实2D／3D店面。例如，可以为用户给出商店的平面地图视图641。在有些地图视图中，可以为用户提供用户的位置(例如，利用GPS，或者如果不可用的话，就使用利用蜂窝信号的粗略近似)。在有些实现方式中，如果用户希望的话，则可以向用户提供用户之前与目前购买的位置(见642，在有些实现方式中，用户可以关闭该指示)。在有些实现方式中，可以在虚拟店面中为用户提供过道的3D过道视图。用户可以把视向指向任何对象，以便获得虚拟工具从“虚拟货架”获得物品并且把它们放到用户的虚拟购物车中。在650的屏幕显示了过道的放大现实视图，在那里，用户可以看到由管理员建议的物品代码(pin)，或者通过直播视频视图65X突出显示的在其购物车／愿望清单中做标记的物品。在另一个视图中，当消费者不在商店中但是想查找产品时；虚拟商店过道视图(例如，类似于Google地图街景)可以被导航651；方向性控制651允许上下导航过道，并且旋转在商家位置物品的视图。此外，消费者可以点击货架中的物品并且创建新的产品代码，然后可以添加652到购物车或愿望清单，用于将来交易。

图7示出了说明在UEP的有些实施例中在虚拟钱包应用中分配用于购买支付的资金的示例方面的用户界面图。在一种实施例中，钱包移动应用可以为用户提供经钱包模式701支付交易的多种选项。钱包模式可以方便用户为支付交易设定偏好，包括设定资金来源702、收款人703、交易模式704、对交易705应用实时提议项705并且在社会上公布交易细节706，如以下进一步具体描述的。

在一种实现方式中，示出了进行付款的示例用户界面711。该用户界面可以清楚地识别交易的金额712与货币713。金额可以是可支付的金额，而货币可以包括例如美元和欧元的实际货币及例如奖励积分的虚拟货币。用户可以选择资金选项卡702，来选择一种或多种付款形式717，这可以包括各种信用卡、借记卡、礼品卡、奖励和／或预付卡。用户还可以具有完全或部分地用奖励积分支付的选项。例如，用户界面上的图形指示器718示出了可用的积分，而图形指示器719示出了朝付款金额234.56要使用的积分及选定货币(例如，USD)中该积分的等价值720。

在一种实现方式中，用户可以结合来自多个来源的资金来支付交易。用户界面上所显示的金额715可以提供到目前为止由选定的支付形式(例如，发现卡(discover card)与奖励积分)所覆盖的总资金金额的指示。用户可以选择另一种付款形式或者调整要从一种或多种付款形式借记的金额，直到金额715匹配可支付的金额714。一旦用户最后定下从一种或多种支付形式借记的金额，就可以开始付款授权。

在一种实现方式中，用户可以通过选择“CLOAK”按钮有效地伪装或匿名一些(例如，预先配置的)或全部识别信息来选择交易的安全授权，使得，当用户选择支付按钮721时，以安全和匿名的方式进行交易授权。在另一种实现方式中，用户可以选择支付按钮721，这可以使用标准的授权技术进行交易处理。在还有另一种实现方式中，当用户选择社交按钮723时，关于交易的消息可以传送到(用户设置的)一个或多个社交网络，这些网络可以在例如海报或tweet的社交论坛中发贴或通告该购买交易。在一种实现方式中，用户可以选择社交付款处理选项723。指示器724可以显示进行中的授权与发送社交共享数据。

在另一种实现方式中，受限付款模式725可以对某些购买活动激活，例如指定购买。该模式可以根据由发行者、保险公司、商家、付款处理器和／或其它实体定义的规则来激活，以方便专用商品与服务的处理。在这种模式中，用户可以向下滚资金选项卡下面的付款形式列表726，来选择例如弹性支出账户(FSA)、健康储蓄账户(HAS)727等的专用账户和要借记到选定账户的金额。在一种实现方式中，这种受限付款模式725处理可以禁止购买信息的社交共享。

在一种实现方式中，钱包移动应用可以方便资金经导入资金用户界面728的导入。例如，失业的用户可以经钱包移动应用获得失业金729。在一种实现方式中，提供资金的实体还可以配置使用资金的规则，如由处理指示器消息730所示出的。钱包可以事先读取并应用规则，而且可以拒绝用失业金进行未能满足规则所设定标准的任何购买。示例标准可以包括例如商家类别代码(MCC)、交易时间、交易地点等。作为一个示例，与具有MCC5411的杂货店商家的交易可以被批准，而与具有MCC5813的酒吧商家的交易可以被拒绝。

图8示出了说明在UEP的有些实施例中在虚拟钱包应用中选择资金转账的收款人的示例方面的用户界面图。在一种实施例中，钱包移动应用用户界面中的收款人屏幕801可以方便用户选择接收在资金选项卡中选定的资金的一个或多个收款人。在一种实现方式中，用户界面可以显示用户以前与其交易过或者可用于进行交易的全部收款人的列表802。然后，用户可以选择一个或多个收款人803。例如，选择可以包括多商家条目，这可能是当用户支付购物车中的产品时的情况，其中产品本身是来自多个商家。在另一个示例中，用户可以支付放在多个购物车中的产品，每个购物车包括来自一个或多个商家的产品。收款人803可以包括例如Amazon.com公司的较大的商家和例如Jane P.Doe的个人。在每个收款人名字后面，可以显示用于该收款人的可接受付款模式的列表。在有些实现方式中，用户可以把附加的名字导入804用户界面802中所包括的地址本。

在一种实现方式中，用户可以选择收款人Jane P.Doe接收付款。选择之后，用户界面可以显示关于该收款人的附加识别信息806。该用户界面可以允许用户联系收款人(例如，打电话、发信息、发电子邮件)、修改地址本中该收款人的条目(例如，编辑、删除、与另一个联系人合并)或者对收款人付款807。例如，用户可以输入要付给该收款人的金额808。用户可以包括用于该收款人(或者用于用户自己)的、与支付相关的注释809。用户还可以包括附连到支付的串(string)。例如，用户可以规定只有在收款人在社交网络站点上转贴该用户的注释的时候支付处理才能发生，810。在任何时候，用户都可以修改付款中使用的资金来源，811。而且，用户可以对每个用户利用多种不同的付款模式，812。例如，像在参考图9B的讨论中描述的那些的附加模式可以用于人到人的付款。例如，社交付款机制可以对人到人的支付采用。关于社交付款机制的附加描述可以在参考图40-47和49D的讨论中找到。作为另一个示例，人到人的付款可以经快照移动机制进行，如以下在参考图12A的讨论中进一步描述的。

图9A-B示出了说明在UEP的有些实施例中虚拟钱包应用的示例附加方面的用户界面图。参考图9A，在有些实现方式中，提议项屏幕901可以提供与用户购物车中物品相关的实时提议项，用于让用户选择。用户可以从可用提议项的列表903中选择一个或多个提议项(见902)来兑换。在一种实现方式中，有些提议项可以组合(见例如904)，而其它的可能不能(可选地)。当用户选择了可能不能与别的提议项组合的提议项时，未选择的提议项可以被禁用。在进一步的实现方式中，钱包应用的推荐引擎推荐的提议项可以被指示器识别，例如由905示出的推荐。一种示例提议项推荐引擎在以下参考图39的讨论中进一步描述。在进一步的实现方式中，通过如用户界面中由905所示的那样展开提议项行，用户可以读取提议项的细节。用户可以在任何时候刷新实时提议项屏幕中所显示的提议项(见906)。

参考图9B，在有些实现方式中，模式选项卡911可以方便选择收款人接受的付款模式。多种支付模式可用于选择。其中，示例模式包括蓝牙912、无线913、通过用户获得的QR码的快照移动914、安全芯片915、TWITTER916、近场通信(NFC)921、蜂窝920、通过用户提供的QR码的快照移动919、USB918和FACEBOOK917。在一种实现方式中，只有收款人接受的付款模式可以被用户选择。其它不被接受的付款模式可以被禁用。

在一种实施例中，社交选项卡931可以方便钱包应用与社交通道932的集成。在一种实现方式中，用户可以选择一个或多个社交通道932并且可以通过向钱包应用提供该社交通道的用户名与口令933并登录934从钱包应用登录到选定的社交通道。然后，用户可以使用社交按钮935通过集成的社交通道发送或接收钱。在进一步的实现方式中，用户可以通过集成社交通道发送社交共享数据，例如购买信息或者链接。在另一种实施例中，用户提供的登录凭证可以允许UEP参与截取解析。

图10A-B示出了说明在UEP的有些实施例中虚拟钱包应用的历史模式的示例方面的用户界面图。参考图10A，在一种实施例中，用户可以选择历史模式1001来查看先前购买的历史并且对那些先前的购买执行各种动作。钱包应用可以从移动设备或别的地方(例如，远离移动设备的一个或多个数据库和／或表)中的存储区字段查询先前的交易。然后，用户界面可以显示查询的结果，例如交易1003。用户界面可以识别1004：交易的类型(例如，先前购买的物品、已经在快照模式中被照相机捕捉的账单、人到人的转账[例如，经如以下在参考图40-47的讨论中所描述的社交付款机制]，等等)；交易的日期；交易的描述，包括但不限于：购物车名字、购物车内容指示器、总成本、交易中所涉及的商家；到获得商店跟踪的链接(以下进一步更具体地解释)、关于交易的提议项及任何其它相关信息。在有些实现方式中，任何显示的交易、优惠券、账单等都可以添加到购物车，以便(再次)购买，1005。

在一种实施例中，用户可以选择历史模式1011来查看过滤后的先前购买的历史并且对那些先前的购买执行各种动作。例如，用户可以在搜索条1012中输入例如名字、产品、MCC等的商家识别信息。在另一种实现方式中，用户可以使用语音激活的搜索特征来搜索历史。在另一种实现方式中，钱包应用可以显示弹出屏幕1016，用户可以在其中输入高级搜索过滤器、关键字等。钱包应用可以从移动设备或别的地方(例如，远离移动设备的一个或多个数据库和／或表)中的存储区域查询匹配搜索关键字的交易。然后，用户界面可以显示查询结果，例如交易1003。用户界面可以识别1004：交易的类型(例如，先前购买的物品、已经在快照模式中被照相机捕捉的账单、人到人的转账[例如，经如以下在参考图40-47的讨论中所描述的社交付款机制]，等等)；交易的日期；交易的描述，包括但不限于：购物车名字、购物车内容指示器、总成本、交易中所涉及的商家；到获得商店跟踪的链接(以下进一步更具体解释的)、关于交易的提议项及任何其它相关信息。在有些实现方式中，任何显示的交易、优惠券、账单等都可以添加到购物车，以便(再次)购买，1015。

参考图10B，在一种实施例中，历史模式还可以包括用于导出收据的设备。导出收据弹出框1021可以提供导出历史交易收据的多种选项。例如，用户可以使用选项1022中的一个或多个，包括保存(到本地移动存储器、到服务器、到云账户等)、打印到打印机、传真、电子邮件等。为了导出，用户可以利用他或她的地址本来查找电子邮件或传真号。用户还可以规定用于导出收据的格式选项。示例格式选项可以包括但不限于文本文件(.doc、.txt、.rtf、.iif等)、电子数据表(.csv、.xls等)、图像文件(.jpg、.tff、.png等)、便携式文档格式(.pdf)、Postscript(.ps)等。然后，用户可以点击或轻击导出按钮，启动收据的导出。

图11A-C示出了说明在UEP的有些实施例中在虚拟钱包应用及相关联的收入共享方案中创建用户购物跟踪的示例方面的用户界面与逻辑流图。参考图11A，在有些实现方式中，用户可以选择历史模式1101来查看先前购买的历史并对那些先前购买执行各种动作。钱包应用可以从移动设备或别的地方(例如，远离移动设备的一个或多个数据库和／或表)中的存储区域查询先前的交易。然后，用户界面可以显示查询结果，例如交易1103。用户界面可以识别1104：交易的类型(例如，先前购买的物品、已经在快照模式中被照相机捕捉的账单、人到人的转账[例如，经如以下在参考图40-47的讨论中所描述的社交付款机制]，等等)；交易的日期；交易的描述，包括但不限于：购物车名字、购物车内容指示器、总成本、交易中所涉及的商家；到获得商店跟踪的链接(以下进一步更具体解释的)、关于交易的提议项及任何其它相关信息。在有些实现方式中，任何显示的交易、优惠券、账单等都可以添加到购物车，以便(再次)购买，1105。

在一种实现方式中，用户可以选择一个交易，例如交易1106，来查看该交易的细节。例如，用户可以查看与该交易关联的物品的详情及每种物品的量、商家等，1112。在各种实现方式中，用户可能能够在这个视图中执行附加的操作。例如，用户可以(再次)购买物品1113、获得物品的第三方评论并且写物品的评论1114并且把照片添加到物品，从而连同物品一起组织与该物品相关的信息1115、把物品添加到一组相关的物品(例如，家用)、提供分级1117或者泛泛地查看来自用户的朋友或来自网络的快速分级。例如，这种系统可以利用以下在参考图18-37的讨论中所述的示例集中式个人信息平台来实现。用户可以把照片添加到交易。在进一步的实现方式中，如果用户先前经社交通道共享了该购买，则包括照片的帖子可以生成并发送到社交通道，以便公布。在一种实现方式中，任何共享都是可选的，而且不经社交通道共享购买的用户仍然可以直接从钱包应用的历史模式通过他或她选择的一个或多个社交通道共享照片。在另一种实现方式中，用户可以把交易添加到一个组，例如公司开支、家庭开支、旅行开支或者用户设置的其它分类。这种分组可以方便年终的开支记账、工作开支报告的提交、增值税(VAT)退款的提交、个人开支等。在还有另一种实现方式中，用户可以买在该交易中购买过的一种或多种物品。然后，用户不用去商家的目录或站点找这些物品就可以执行交易。在进一步的实现方式中，用户还可以在购物车中存放交易中的一种或多种物品，以便以后购买。

在另一种实施例中，历史模式可以提供获得并显示交易中物品分级1117的设施。分级的来源可以是用户、用户的朋友(例如，来自社交通道、联系人，等等)、从网络聚合的评论等。有些实现方式中的用户界面还可以允许用户向社交通道(例如，TWITTER或FACEBOOK)的其他用户发消息。例如，显示区域1118示出了在两个用户之间交换的FACEBOOK消息。在一种实现方式中，用户可以经消息1119共享链接。对具有到产品的嵌入式链接的这种消息的选择可以允许用户查看产品的描述和／或直接从历史模式购买该产品。

在有些实现方式中，钱包应用可以为用户显示商店跟踪，例如1120。例如，用户可能已经在多个网站(例如，ElecReports、APPLFanBoys、Gizmo、Bing、Amazon、(例如，根据用户偏好自动地检查各种来源来寻找可用的最佳价格并且向用户提供提议项的)VisaSmartbuy特征，等等)调查了一种产品，这可能把用户引导到用户最终买产品的最终商家网站。在有些实现方式中，UEP可以识别用户访问过的网站、对用户决定买产品有帮助的网站，并且可以由于对用户进入销售点网站并且在那里购买产品有帮助而奖励它们通过“销售点”网站获得的收入的份额。例如，网站可以与产品制造商、批发商、零售店、支付服务提供商、支付网络等彼此之间有关于产品放置、广告、用户重定向等的协定。相应地，UEP可以利用收入共享模型在用户的购物跟踪中为每个网站计算收入份额，并且为网站提供收入共享。

在有些实现方式中，虚拟钱包可以提供SmartBuy有针对性的购物特征。例如，用户可以为用户想买的产品1112设定目标价格1121。虚拟钱包可以为那个产品提供实时市场观望状态更新1122。当用户可以获得的市场价格降至低于用户的目标价格1121时，虚拟钱包可以自动为用户买下该产品，并且向用户提供发货／通知。

图11B示出了说明在UEP的有些实施例中生成虚拟钱包用户购物跟踪的示例方面的逻辑流图，例如用户购物跟踪生成(“USTG”)组件1100。在有些实现方式中，为用户执行虚拟钱包应用的用户的用户设备可以跟踪用户的购物活动，用于随后检索和／或分析。设备可以获得用户的输入，1101，并确定用户输入的类型，1102。如果用户在商家的网站参与浏览活动，或者在网站之间导航(例如，当1103选项为“否”的某个时间)，设备可以跟踪这种活动。例如，设备可以确定用户的输入是导航输入(1104，选项“是”)。设备可以停止与用户所在的(例如，像amazon.com、ebay.com、newegg.com等商家，或者例如shlashdot.org、cnet.com等评论网站)当前URL关联的定时器，并且确定用户花在该URL上的时间计数，1108。设备可以利用对当前URL的时间计数更新商店跟踪数据库(例如，本地数据库、云数据库等)，1109。作为用户的导航输入的结果，设备还可以识别用户将导航到的重定向URL，1110。设备可以把重定向URL设定为当前URL，并且复位用于当前URL的活动与时间计数器。设备可以在商店跟踪数据库中生成用于已经被用户的导航输入变成当前URL的新条目，1111。

如果用户在当前URL参与浏览活动(1105，选项“是”)，则设备可以识别与该浏览活动关联的URL(例如，如果浏览可以在设备上跨多个窗口或选项卡执行，等等)。设备可以递增活动计数器，以确定用户在发生浏览活动的URL的用户活动水平，1106。设备可以利用对该URL的活动计数更新商店跟踪数据库，1107。

如果用户期望参与购买交易，例如，在访问关于产品的多个URL之后(例如，在多个消费者报告网站阅读关于一种产品的评论之后，用户导航到amazon.com去买该产品)，见1103，选项“是”，则设备可以把当前URL设定为“销售点”URL(例如，用户最终在其购买该产品的商家，例如，amazon.com)，1112。设备可以停止对当前URL的时间，并且更新用于当前URL的商店跟踪数据库，1113。设备可以生成启动购买交易的卡授权请求，1114，并且提供用于交易处理的卡授权请求(见，例如，以下参考图57A-B的讨论中所描述的PTA5700组件)。

在有些实现方式中，设备还可以启用收入共享组件，例如以下参考图11C的讨论中所描述的示例STRS1120组件。

图11C示出了说明在UEP的有些实施例中实现基于用户购物跟踪的收入共享的示例方面的逻辑流图，例如，购物跟踪收入共享(“STRS”)组件1120。在有些实现方式中，用户可能已经在多个网站调查了一种产品，这可能把用户引导到用户最终购买该产品的最终商家网站。在有些实现方式中，UEP可以识别用户访问过的网站、对用户决定买产品有帮助的网站，并且可以由于对用户进入销售点网站并且在那里购买产品有帮助而奖励它们通过“销售点”网站获得的收入的份额。例如，网站可以与产品制造商、批发商、零售店、支付服务提供商、支付网络等彼此之间有关于产品放置、广告、用户重定向等的协定。例如，服务器可能已经存储了收入共享比率表，该表根据哪些有帮助的网站将由于用户购买而收到收入提供预定的收入共享策略。

相应地，在有些实现方式中，服务器可以获得包括在用户购物跟踪中的URL列表，及其关联的活动与时间计数，1121。服务器可以识别用户进行购买的销售点URL，对于本次购买，收入将在购物跟踪中的URL之间共享，1122。通过分别把用户购物跟踪中所有URL的活动与时间计数求和，服务器可以计算总的活动计数和总的时间计数，1123。服务器可以计算每个URL的活动与时间比率，1124。服务器可以获得收入共享模型(例如，加权值的数据库表／矩阵)，用于把用于每个URL的活动与时间比率转换成用于那个URL的收入比率，1125。服务器可以利用收入共享模型和为每个URL计算出的收入比率为用户购物跟踪中的每个URL计算收入份额，1126。服务器可以为每个URL提供收入的通知(例如，向从其获得收入以便向用户购物跟踪中的其它URL支付收入份额的每个URL和／或销售点URL)，1127。在有些实现方式中，服务器可以为由于用户购物跟踪中的URL造成的每次收入支付生成卡授权请求和／或分批清除请求，以便处理那些交易，进行收入共享。

图12A-H示出了说明在UEP的有些实施例中虚拟钱包应的快照模式的示例方面的用户界面与逻辑流图。参考图12A，在有些实现方式中，用户可以选择快照模式1201来访问其快照特征。快照模式可以处理数据的任何机器可读表示。这种数据的示例可以包括例如UPC码和QR码的线性与2D条形码。这些代码可以在收据1206、产品包装1202、优惠券1203、付款通知1204、发票1205、信用卡和／或其它付款账户塑料卡或等价物1207等上面找到。快照模式可以处理和管理收据、产品、提议项、信用卡或其它付款设备等的图片。快照模式中的一个示例用户界面1211在图12A中示出。用户可以使用他或她的移动电话拍摄QR码1215和／或条形码1214的照片。在一种实现方式中，条形1216和快照框1213可以帮助用户正确地给抓拍代码。例如，如所示出的，快照框1213没有捕捉到代码1214的全部。因此，在这个视图中捕捉到的代码可能是不可分辨的，因为代码中的信息可能不完整。当代码1215被快照框5125完全框住时，设备可以自动抓拍代码的照片，1219。在找出代码后，在一种实现方式中，用户可以利用移动设备照相机启动代码捕捉，1212。在有些实现方式中，用户可以调整照相机的缩放水平，来帮助捕捉代码，1217。在有些实现方式中，用户可以把GPS标签添加到捕捉到的代码，1218。

参考图12B，在用户还没有与物品交互的有些实现方式中，用户可以查看设计成方便用户以对用户最佳可能的条件购买物品的物品详情。例如，虚拟钱包应用可以在物品的详细视图被用户利用用户设备抓拍到的时候提供它，1221，包括物品的描述、价格、商家名字等。该视图还可以提供QR码1222，用户可以轻击该QR码，以便保存到钱包，让以后使用，或者向其他用户显示，然后这些其他用户可以抓拍该QR码，以便购买该物品。在有些实现方式中，该视图可以为用户提供附加的服务，包括但不限于：管理员服务、发货服务、热线服务等，1223。在有些实现方式中，该视图可以提供来自具有竞争力的本地商家或网络上的价格，1224。这种定价数据可以通过在以下参考图18-37的讨论中进一步描述的集中式个人信息平台组件来促进。在有些实现方式中，该视图可以为用户提供选项(见1225)，用于：为以后使用存储抓拍的代码、重新开始并且生成新代码、开启或关闭GPS加标签特征、使用先前抓拍的QR码、输入与QR码关联的关键字、把与QR相关的物品关联到一个对象，等等。在有些实现方式中，虚拟钱包可以提供SmartBuy购物特征。例如，用户可以为用户希望买的产品1221设定目标价格1226。虚拟钱包可以为那个产品提供实时市场观望状态更新1227。当用户可以获得的市场价格降至低于用户的目标价格1226时，虚拟钱包可以自动为用户买下该产品，并且向用户提供发货／通知。用户可以在任何时候把该物品添加到用户的一个购物车或愿望清单(见1228)。

在一种实现方式中，尤其是当用户先前已经与抓拍的物品交互过时，用户可以查看物品的细节1232及每种物品的量、商家等，1232。在各种实现方式中，用户可能能够在这个视图中执行附加的操作。例如，用户可以(再次)购买物品1233、获得第三方对物品的评论并且写对物品的评论1234、把照片添加到物品从而与物品一起组织与该物品相关的信息1235、把物品添加到相关物品的组(例如，家用)1236、提供分级1237或者泛泛地查看来自用户的朋友或者来自网络的快速分级。例如，这种系统可以用在以下参考图18-37的讨论中所述的示例集中式个人信息平台组件来实现。用户可以把照片添加到交易。在进一步的实现方式中，如果用户先前经社交通道共享了该购买，则包括照片的帖子可以生成并发送到社交通道，以便公布。在一种实现方式中，任何共享都是可选的，而且不经社交通道共享购买的用户仍然可以直接从钱包应用的历史模式通过他或她选择的一个或多个社交通道共享照片。在另一种实现方式中，用户可以把交易添加到一个组，例如公司开支、家庭开支、旅行开支或者用户设置的其它分类。这种分组可以方便年终的开支记账、工作开支报告的提交、增值税(VAT)退款的提交、个人开支等。在还有另一种实现方式中，用户可以买在该交易中购买过的一种或多种物品。然后，用户不用去商家的目录或站点找这些物品就可以执行交易。在进一步的实现方式中，用户还可以在购物车中存放该交易中的一种或多种物品，以便以后购买。

在另一种实施例中，历史模式可以提供获得并显示交易中物品分级1237的设施。分级的来源可以是用户、用户的朋友(例如，来自社交通道、联系人，等等)、从网络聚合的评论等。有些实现方式中的用户界面还可以允许用户向社交通道(例如，TWITTER或FACEBOOK)的其他用户发消息。例如，显示区域1238示出了在两个用户之间交换的FACEBOOK消息。在一种实现方式中，用户可以经消息1239共享链接。对具有到产品的嵌入式链接的这种消息的选择可以允许用户查看产品的描述和／或直接从历史模式购买该产品。

在有些实现方式中，钱包应用可以为用户显示商店跟踪，例如1240。例如，用户可能已经在多个网站(例如，ElecReports、APPLFanBoys、Gizmo、Bing、Amazon、(例如，根据用户偏好自动地检查各种来源以便寻找可用的最佳价格并且向用户提供提议项的)VisaSmartbuy特征，等等)调查了一种产品，这可能把用户引导到用户最终买产品的最终商家网站。在有些实现方式中，UEP可以识别用户访问过的网站、对用户决定买产品有帮助的网站，并且可以由于对用户进入销售点网站并且在那里购买产品有帮助而奖励它们通过“销售点”网站获得的收入的份额。例如，网站可以与产品制造商、批发商、零售店、支付服务提供商、支付网络等彼此之间有关于产品放置、广告、用户重定向等的协定。相应地，UEP可以利用收入共享模型在用户的购物跟踪中为每个网站计算收入份额，并且为网站提供收入共享。

在有些实现方式中，虚拟钱包可以提供SmartBuy有针对性的购物特征。例如，用户可以为用户想买的产品1232设定目标价格1241。虚拟钱包可以为那个产品提供实时市场观望状态更新1242。当用户可以获得的市场价格降至低于用户的目标价格1241时，虚拟钱包可以自动为用户买下该产品，并且向用户提供发货／通知。

参考图12C-D，在一种实施例中，快照模式可以方便对先前已完成的交易(图12C)或者目前执行的交易(图12D)的支付重新分配。例如，用户可以从零售商Acme超市买杂货和规定的物品。例如用户可能无意地或者为了方便结帐而使用他或她的传统支付卡既支付了杂货又支付了规定物品，并且获得了收据。但是，用户可能有一个已经用于支付规定物品的FSA账户，而且这个账户将为用户提供更好的价格或者其它经济利益。在这种情况下，用户可以使用快照模式启动交易重新分配。

如所示出的，用户可以抓拍1251、1261收据1253、1263上条形码的图片，据此，虚拟钱包应用可以利用来自支付代码的信息给出收据数据1252、1262。用户现在可以把开支重新分配到他们的最佳账户1254、1264。在有些实现方式中，用户还可以阻止(dispute)交易1255、1265或者把收据1256、1266存档。

在一种实现方式中，当选择重新分配按钮时，钱包应用可以执行收据的光学字符识别(OCR)。然后，可以检查收据中的每种物品，识别付款设备或账户要为其承担税或其它其它利益，例如现金返回、奖励积分等，的一种或多种物品。在这个示例中，如果由用户的Visa卡付费的处方药品要由用户的FSA付费，则存在税收利益。然后，钱包应用可以作为后端执行重新分配。重新分配过程可以包括钱包联系付款处理器，把处方药品的金额归还到Visa卡并且把相同的金额借记到用户的FSA账户。在一种备选实现方式中，付款处理器(例如，Visa或MasterCard)可以获得收据的OCR、识别物品和用于重新分配的付款账户并且执行重新分配。在一种实现方式中，钱包应用可以请求用户确认选定物品的费用重新分配到另一个付款账户。收据可以在重新分配过程完成之后生成。如所讨论的，收据显示一些费用已经从Visa账户移到FSA。

参考图12E，在一种实施例中，快照模式还可以方便提议项的识别、应用和存储，以便将来使用。例如，在一种实现方式中，用户可以抓拍账户号码、提议项代码1271(例如，条形码、QR码等)。然后，钱包应用可以从在提议项代码中编码的信息生成账户卡文本、优惠券文本、提议项文本1272。用户可以对提议项代码执行多种动作。例如，用户可以使用重新分配按钮1273来重新分配利用导入的卡、优惠券、提供等将能够更好进行的先前购买，而且虚拟钱包应用可以在修改充当用户先前交易的账户后提供重新分配的通知。

在一种实施例中，快照模式还可以提供向钱包应用添加资金来源的设施。在一种实现方式中，例如信用卡、借记卡、预付卡、智能卡和其它支付账户的支付卡可以具有关联的代码，例如条形码或QR码。这种代码可以在其中编码支付卡的信息，包括但不限于名字、地址、支付卡类型、支付卡详情、余额、消费限额、奖励余额等。在一种实现方式中，代码可以在物理支付卡的正面找到。在另一种实现方式中，代码可以通过访问关联的在线账户或别的安全位置获得。在还有另一种实施例中，代码可以打印在伴随该支付卡的信上。在一种实现方式中，用户可以抓拍代码的图片。钱包应用可以识别支付卡并且可以显示在支付卡中编码的文本信息。然后，用户可以通过选择检验按钮执行信息的检验。在一种实现方式中，检验可以包括联系支付卡的发行者，对解码的信息和任何其它相关的信息进行确认。在一种实现方式中，用户可以通过选择“添加到钱包”按钮把支付卡添加到钱包。把支付卡添加到钱包的指令可以使该支付卡作为一种付款形式出现在以上讨论的资金选项卡下面。

参考图12F，在有些实现方式中，用户可能能够有利地把用户设置提供到产生用于购买交易的QR码的设备中，然后利用用户的移动设备捕捉该QR码。例如，销售点终端的显示设备可以显示结帐屏幕，像在客户端上执行的浏览器，例如1281，显示在线购物网站的结帐网页，例如1282。在有些实现方式中，结帐屏幕可以提供用户界面元素，例如1283a-b，由此用户可以指示期望利用快照移动付款。例如，如果用户激活元素1281a，则网站可以利用用户的缺省设置生成QR码，并且在客户端的屏幕上显示该QR码，例如1285，以便让用户用用户的移动设备捕捉。在有些实现方式中，用户可能能够激活用户界面元素，例如1283b，由此客户端可以显示弹出菜单，例如1284，该弹出菜端具有让用户选择的附加选项。在有些实现方式中，当用户修改通过激活用户界面元素1283b提供的设置时，网站可以实时地修改QR码1285。一旦用户利用弹出菜单修改了设置，用户就可以捕捉QR码的快照，来启动购买交易处理。

图12G示出了说明在UEP的有些实施例中执行快照移动支付的示例方面的逻辑流程图，例如，快照移动付款执行(“SMPE”)组件1200。在有些实现方式中，用户可能期望从商家的在线站点或者在商家的商店中购买产品、服务、提议项等(“产品”)。用户可以经客户端与商家的服务器通信。例如，用户可以把用户输入，例如1201，提供到客户端中，该输入指示用户期望结帐(虚拟)购物车中的物品。客户端可以生成结帐请求，例如1202，并且把该结帐请求提供给商家的服务器。商家的服务器可以从客户端获得结帐请求，并且从该结帐请求提取结帐详情(例如，XML数据)，例如1203。例如，商家的服务器可以利用例如在以下参考图61的讨论中所描述的示例解析器的的解析器。商家服务器可以从结帐请求提取产品数据，及客户端数据。在有些实现方式中，商家服务器可以查询，例如1204，商家的数据库来获得产品数据，例如1205，例如产品定价、营业税、提议项、折扣、奖励和／或其它信息，来处理购买交易。

响应获得了产品数据，商家服务器可以根据用户的安全性设置生成，例如1206，QR支付码，和／或安全显示元素。例如，商家服务器可以生成包含产品信息的QR码，及付款网络处理购买交易所需的商家信息。例如，商家服务器可以首先实时地生成具有时间限制有效周期的定制的、特定于用户的商家产品XML数据结构，例如以下提供的示例“QR_data”XML数据结构：

在有些实现方式中，商家可以利用XML数据生成QR码。例如，商家服务器可以利用在http：／／phpqrcode.sourceforge.net／可以获得PHP QR码开放源码(LGPL)库生成QR码、2维条形码。例如，商家服务器可以发布类似于以下提供的示例命令的PHP命令：

商家服务器可以向客户端提供QR支付码，例如1206。客户端可以获得QR支付码并且在例如与客户端设备关联的显示屏幕上显示该QR码，例如1207。在有些实现方式中，用户可以利用用户设备，例如1209，捕捉由客户端设备给出的QR码，用于付款处理。客户端设备可以解码QR码，提取嵌在该QR码中的信息。例如，客户端设备可以利用例如在http：／／code.google.com／p／zxing／可以获得的ZXing多格式1D／2D条形码图像处理库来从QR码提取信息。在有些实现方式中，用户可以把支付输入提供到用户设备中，例如1208。在获得用户购买输入后，用户设备可以生成卡授权请求，例如1209，并且把该卡授权请求提供给支付网络服务器(见例如图57A)。

图12H-I示出了说明在UEP的有些实施例中处理快速响应代码的示例方面的逻辑流图，例如，快速响应代码处理(“QRCP”)组件1210。参考图12H，在有些实现方式中，在用户设备上执行的虚拟钱包应用可以确定QR码是否已经在由操作连接到该用户设备的照相机所获得的图像帧中捕捉到，而且还可以确定QR码的类型、内容。利用这种信息，虚拟钱包应用可以重定向用户的用户体验和／或启动购买、更新虚拟钱包应用的各方面，等等。例如，虚拟钱包应用可以触发由操作连接到用户设备的照相机对图像帧的捕捉，1211。虚拟钱包应用可以利用图像分割算法来识别图像中的前景，1212，并且可以裁减图像的剩余部分，以便减少图像中的背景噪声，1213。虚拟钱包应用可以确定前景图像是否包括可以从其可靠读取数据的QR码(例如，如果图像不包括QR码或者QR码被部分裁剪、模糊等，则可能不能可靠地读取数据)，1244。例如，虚拟钱包应用可以利用例如可以在http：／／code.google.com／p／zxing／获得的ZXing多格式1D／2D条形码图像处理库来尝试并从QR码提取信息。如果虚拟钱包应用能够检测到QR码(1215，选项“是”)，则虚拟钱包应用可以解码QR码并且从QR码提取数据，1217。如果虚拟钱包应用不能检测到QR码(1215，选项“否”)，则虚拟钱包应用可以尝试对图像执行光学字符识别。例如，虚拟钱包应用可以利用在WWW.pixel-technology.com／freewarw／tessnet2可以获得的Tesseract C++开放源码OCR引擎执行光学字符识别，1216。因而，虚拟钱包应用可以获得编码到图像中的数据，并且如果数据可以被虚拟钱包应用处理的话可以继续。虚拟钱包应用可以利用在提取出的数据中识别出的字段查询数据库中QR码的类型，1218。例如，QR码可以包括发票／账单、优惠券、汇票(例如，在P2P转账中)、新帐户信息包、产品信息、购买命令、URL导航指令、浏览器自动化脚本、其组合等。

在有些实施例中，QR码可以包括要添加到虚拟钱包应用的新账户的数据(见1219)。虚拟钱包应用可以向(如从提取出的数据获得的)新帐户的发行者询问与新帐户关联的数据，1220。虚拟钱包应用可以比较发行者提供的数据与从QR码提取出的数据，1221。如果新帐户通过验证(1221，选项“是”)，则虚拟钱包应用可以用新账户的详情更新钱包凭证，1223，并且利用来自QR码的数据更新虚拟钱包应用的快照历史，1224。

参考图12I，在有些实施例中，QR码可以包括关于用于利用虚拟钱包应用进行购买的账单、发票或优惠券的数据(见1225)。虚拟钱包应用可以向(如从提取出的数据获得的)与该购买关联的商家询问与用于购买的账单、发票或优惠券关联的数据(例如，提议项详情、提议项ID、到期日期等)，1226。虚拟钱包应用可以比较商家提供的数据与从QR码提取出的数据，1227。如果用于购买的账单、发票或优惠券通过验证(1228，选项“是”)，则虚拟钱包应用可以生成包括QR编码数据的数据结构(见例如以上参考图12F的描述中的XML QR_data)，用于生成并提供卡授权请求，1229，并且利用来自QR码的数据更新虚拟钱包应用的快照历史，1230。

在有些实施例中，QR码可以包括用于虚拟钱包应用的产品信息、命令、用户导航指令等(见1231)。虚拟钱包应用可以利用嵌在QR中的信息查询产品数据库。虚拟钱包应用可以提供各种特征，包括但不限于显示产品信息、把用户重定向到：产品页、商家网站、商家网站上的产品页、在商家网站把物品添加到用户购物车，等等。在有些实现方式中，虚拟钱包应用可以对任何待处理的和／或用户(例如，从快照历史)选择要处理的图像帧执行例如以上所述的过程。

图13A-B示出了说明在UEP的有些实施例中虚拟钱包应用的提议项模式的示例方面的用户界面与逻辑流图。参考图13A，在有些实现方式中，用户可能期望获得用户虚拟钱包应用中的新提议项，或者可能期望把现有提议项换成新的一个(或多个提议项)(例如，提议项1301可以按用户的命令被替换)。例如，用户可以提供指示期望替换提议项1302的输入。作为响应，虚拟钱包应用可以提供一组替换提议项1303，用户可以从其中选择一个或多个提议项来替换提议项1302。

图13B示出了说明在UEP的有些实施例中生成并交换提议项推荐的示例方面的逻辑流图，例如，提议项推荐与交换(“ORE”)组件1310。在有些实现方式中，用户可能期望获得用户虚拟钱包应用中的新提议项，或者可能期望把现有提议项换成新的一个(或多个提议项)。用户可以提供用于显示这种提议项的输入，1301。用户的设备可以获得用户的输入，并且确定用户是期望获得新提议项还是获得交换目前存储在设备上所执行的用户虚拟钱包应用中的提议项的提议项，1302。如果设备确定用户期望交换先前存在的提议项，例如1303，选项“是”，则设备可以提取用户期望交换的提议项的详情。例如，设备可以把用户的触摸屏输入的位置(例如，设备具有触摸屏接口的位置)关联到在屏幕上显示的提议项。设备还可以确定用户利用在屏幕上显示的、与提议项关联的手势来指示用户期望交换用户手势所关联的提议项。设备可以查询其数据库中对应于所显示提议项的提议项，并且可以通过利用解析器，例如以下在参考图61的讨论中所描述的示例解析器，解析数据库返回的提议项，来提取提议项的详情，1304。在有些实现方式中，设备可以提取由用户作为输入提供的任何用户输入提议项生成约束(例如，像用户可以应用到用户期望的提议项的过滤器类型、与用户期望的提议项类型相关的关键字)，1305。设备可以利用提取出的数据为支付网络服务器生成关于要交换的提议项(如果有的话)的提议项生成／交换请求，和用于所期望提议项类型(如果有的话)的用户偏好，例如，作为类似于在以下讨论的示例的HTTP(S)POST请求。

在有些实现方式中，支付网络服务器可以利用例如以下在参考图61的讨论中描述的示例解析器的解析器来解析提议项生成／交换请求，1307。支付网络服务器可以生成用户行为数据数据查询，1308。例如，服务器可以利用PHP／SQL命令来查询关系支付网络数据库中用户先前的行为数据。例如，支付网络服务器可以获得利用集中式个人信息平台组件，如以下参考图18-37的讨论中所描述的那些，及用户行为分析组件，例如在以下参考图38的讨论中描述的示例UBA组件，生成的这种数据。数据库可以向支付网络服务器提供这种用户行为数据及其分析，1309。利用先前的用户行为数据和／或其分析，并且利用交换的提议项和／或用户提议项生成约束的详情，支付网络服务器可以生成为用户提供的提议项。例如，支付网络服务器可以利用基于用户行为的提议项推荐组件，例如以下参考图39的讨论中所描述的示例UBOR组件。服务器可以向设备提供生成的提议项，该设备可以向用户显示接收到的提议项，1311。在有些实现方式中，用户可以提供指示期望兑换由支付网络服务器提供的一个提议项的输入，1312。作为响应，设备可以生成结合了由用户选择要兑换的提议项详情的卡授权请求，1313，并且提供所生成的卡授权请求，用于购买交易处理(例如，作为到以下参考图57A-B的讨论中所描述的示例PTA组件的输入)。

图14示出了说明在UEP的有些实施例中虚拟钱包应用的通用设置模式的示例方面的用户界面图。在有些实现方式中，虚拟钱包应用可以提供让用户可以修改钱包设置的用户界面，1401。例如，用户可以修改的设置例如但不限于：通用设置1411(例如，用户信息、钱包信息、钱包内的账户信息、链接到钱包的设备等)；隐私控制1412(例如，提供给商家、付款网络、第三方等的控制信息)；购买控制1413(例如，放置特殊的消费约束，或者规定交易的特定类型)；通知1414；钱包耦合1415(例如，与其它虚拟钱包所进行的关系，使得信息、设置、(父)控制和／或资金可以在钱包之间无缝地流动)；社交付款设置1416(见例如图40-47)；物理愿望清单1417(例如，控制在生成提议项、推荐时所考虑的用户行为的类型，见例如图39)；有针对性的购物1418(例如，设置产品购买被自动触发的目标价格，见例如图11A、12B-C)；或者发帖购物设置1419(例如，关于退款、返回、收据、开支重新分配(例如，到FSA或HAS账户)、价格匹配(例如，如果所购买物品的价格在用户购买之后下降)的设置等)。

在通用设置分类(1411)中，用户可能能够修改的设置例如但不限于：用户信息1421、用户设备1422、用户帐户1423、购物会话1424、优选的商家1425、优选的产品与品牌名称、优选的模式(例如，关于NFC、蓝牙等的使用的设置)等。

图15示出了说明在UEP的有些实施例中虚拟钱包应用的钱包耦合设置模式的示例方面的用户界面图。在钱包耦合设置分类(见图14，1415)中，用户可能能够修改的设置例如但不限于关于以下的设置：父钱包1501(例如，被授权对用户的钱包放置约束的那些钱包)；孩子钱包1502(例如，用户有权对其放置约束的那些钱包)；对等钱包1503(例如，具有相似的控制与透明度水平的那些钱包)；特设(ad hoc)钱包1504(例如，实时地暂时连接的那些钱包，例如为了一次性的资金转移)；部分耦合钱包(例如，像公司员工的虚拟钱包与雇主的个人钱包之间的耦合，使得雇主钱包可以提供具有为员工钱包附连的串的有限资金，只用于业务用途)，等等。

图16A-C示出了说明在UEP的有些实施例中虚拟钱包应用的购买控制设置模式的示例方面的用户界面图。参考图16A，在有些实现方式中，用户可能能够查看和／或修改只允许满足购买控制的交易从钱包启动的购买控制。在一种实现方式中，消费者可以配置消费者控制的欺诈行为预防参数，来约束经他的电子钱包进行的购买交易，例如，交易时间、最大金额、类型、每天的交易数量，等等。例如，消费者可以通过创建电子钱包账户并且把付款账户添加到电子钱包(例如，信用卡、借记卡、PayPal账户等)来登记到电子钱包服务(例如，Visa虚拟钱包)。消费者可以配置约束钱包交易的参数。例如，消费者可以配置最大的一次交易金额(例如，$500.00等)。对于另一个示例，消费者可以规定交易可疑的时间范围(例如，发生在早上2点-6点之间的所有交易，等等)。对于另一个示例，消费者可以规定每天的最大交易数量(例如，每天20笔，等等)。对于进一步的示例，消费者可以规定与其的交易可能可疑的商家的名字和／或ID(例如，互联网垃圾网站，等等)。

在一种实现方式中，消费者可以配置购买控制设置，来检测并阻塞所有敏感(susceptible)交易。例如，当发生超过最大规定交易金额的试图交易时，电子钱包可以配置成拒绝该交易并且向消费者发送报警。一旦消费者批准该交易，交易就可以恢复。在另一种实现方式中，如果UEP没有从消费者接收到恢复敏感交易的确认，则UEP可以向商家发送取消交易的通知。在一种实现方式中，消费者可以配置清除时间周期(例如，12个小时，等等)。在另一种实现方式中，UEP可以确定符合监管要求的缺省最大清除周期(例如，软发帖之后的24小时，等等)。

在一种实现方式中，UEP可以为消费者提供通用付款平台，其中用户可以把一个或多个付款账户与该通用付款平台关联并且用该通用付款平台支付。在实施例中，消费者可以经UEP创建电子钱包服务帐户并且登记到电子钱包(例如，Visa虚拟钱包，等等)。在备选实施例中，消费者可以把消费者的银行账户与现有的电子钱包关联。例如，消费者可以向登录用户界面的电子钱包管理消费者提供付款信息，例如银行账户号码、银行汇款路线号码、用户简档信息，来关联账户与电子钱包。在另一种实现方式中，消费者可以在在线结帐期间登记电子钱包。例如，商家站点可以在结帐页面提供电子钱包按钮(例如，Visa虚拟钱包标志，等等)，而且在消费者选择了电子钱包按钮后就可以提示消费者输入银行帐户信息(例如，卡号等)，经弹出窗口给该电子钱包注册一个付款卡(例如，信用卡、借记卡等)。

在一种实现方式中，在接收到消费者的登记银行账户数据后，UEP可以向电子钱包平台生成登记请求(例如，经Visa虚拟钱包付款网络等)。在一种实现方式中，示例性消费者登记数据请求是以可扩展的标记语言(XML)。在进一步的实现方式中，可以在登记后向消费者发行UEP电子钱包设备，例如，移动应用、磁卡等。

在一种实现方式中，用户可以经消费者登记用户界面配置交易约束参数。例如，在一种实现方式中，电子钱包用户可以从UEP接收登录UEP服务的邀请，并且沿着在该邀请(例如，电子邮件等)中提供的链接，用户可以在注册表单中提供注册信息。

在一种实现方式中，用户可以利用UEP配置付款方法和报警。例如，用户可以把一个付款账户添加到钱包，并且注册与该支付账户关联的交易的及时报警。在一种实现方式中，用户可以建立用于交易报警触发的定制规则。例如，当交易金额超过最大的一次性交易金额(例如，$500.00等)时，报警消息可以在敏感交易发生时被触发。对于另一个示例，报警可以在交易在敏感时间范围内发生时(例如，在早上2点-6点之间发生的所有交易，等等)被触发。对于另一个示例，报警可以在交易频率超过每天的最大交易数量时(例如，每天20笔，等等)被触发。对于进一步的示例，报警可以在交易商家是消费者规定的敏感商家(例如，互联网垃圾网站，等等)中的一个时被触发。对于另一个示例，报警可以在交易类型是被阻塞的交易类型时(例如，用户可以禁止在加油站加油的钱包交易，等等)被触发。

在一种实现方式中，用户可以通过选择报警通道来订阅UEP报警。例如，用户可以向UEP提供他的手机号码、电子邮件地址、寄信地址等，并且经电子邮件、文本消息、消费者服务电话、邮件等订阅报警。在一种实现方式中，用户可以为与电子钱包关联的不同付款账户配置规则与订阅通道。

在一种实现方式中，在经用户界面接收到用户配置的参数后，UEP(例如，Visa钱包网络)可以提供(安全的)超文本传输协议(HTTP(S))PUT消息，以根据可扩展标记语言(“XML”)格式化的数据形式包括用户控制参数。以下是要在数据库中存储的、包括XML格式化的用户约束参数的示例HTTP(S)PUT消息：

在一种实现方式中，在配置约束参数之后，当消费者利用商家(例如，购物站点等)购物时，付款处理器网络可以把购买请求转发到Visa网络，该Visa网络可以申请消费者对电子钱包的UEP登记(例如，Visa钱包网络等)。例如，在一种实现方式中，UEP可以检索用户约束参数，并且基于该约束参数审查所接收到的交易请求的交易金额、交易类型、交易频率等。

在一种实现方式中，如果被提议的交易触发了报警，则UEP可以生成报警消息，例如，通过提供包括以根据可扩展标记语言(“XML”)格式化的数据形式的用户控制参数的(安全的)超文本传输协议(HTTP(S))PUT消息。以下是包括XML格式化报警的示例HTTP(S)PUT消息：

在一种实现方式中，UEP还可以生成消息并把它发送到发行银行，例如，发行付款账户的用户的银行，除非随后接收到清除消息，否则提醒发行银行不把资金存入商家。

参考图16B，在有些实现方式中，虚拟钱包应用可以提供一个界面，用户可以经该界面有效地设定用于交易的购买控制。例如，用户可以输入购买控制设置屏幕(“JDOE₁”)1611，其中用户可以向购买控制设置添加约束参数。例如，图16B左边的用户界面示出了当购买衣服或鞋子(见1615)时只允许从美国或台湾(见1614)进行低于$50(见1613)的亲自(见1612)交易的购买控制，而且不超过一个月一次(见1616)，而且假定用户对这个时间帧(1个月)的总体花费小于$1500(见1617)。这种参数约束可以利用用户界面元素1618(例如，选择一个参数)和1619(例如，输入对应于该参数的值)来强加。在有些情况下，虚拟钱包可以提供方便用户输入条目的图形用户界面组件(例如，1622)。例如，当用户希望对购买控制放置地理约束时，虚拟钱包可以显示世界地图，而且用户可以按适当的运动(例如，1623、1624)触摸该地图，以便设置允许(或者，作为替代地，阻塞)从其进行交易的地点。在有些实现方式中，虚拟钱包还可以允许用户手动地输入值(见1626)，而不是利用由虚拟钱包应用提供的基于可视触摸的GUI组件。

参考图16C，在有些实现方式中，虚拟钱包应用可以允许用户管理与用户的钱包使用关联的隐私设置1631。例如，用户可能能够规定在购买交易过程中可以共享的、关于用户的信息(例如，1632-1637)。例如，在说明中，用户已经允许虚拟钱包应用共享用户名和社交圈(1632)。用户还没有设置共享用户地址的偏好；因此，在有些实现方式中，依赖于交易的类型，可以取缺省的中间值(例如，如果UEP估计交易中的风险超过该中间值，则UEP可以在交易过程中伪装用户的地址)。用户可以明确地选择不共享用户的账户号码(例如，用户希望付款网络在交易过程中伪装用户的账户号码)和用户的现场GPS位置(见1638)。

图17A示出了说明在UEP的有些实施例中配置虚拟钱包应用设置的示例方面的逻辑流图，例如，虚拟钱包设置配置(“VWSC”)组件1700。在有些实现方式中，用户可能期望修改用户的虚拟钱包应用中的和／或与用户的钱包有关系的虚拟钱包应用中(例如，耦合的钱包是用户钱包的孩子钱包)的设置。用户可以向用户设备提供指示期望修改钱包设置的输入，1701。在确定用户期望修改钱包设置之后(见1702-1703)，设备可以确定用户请求是修改用户钱包还是修改耦合到用户钱包的钱包。在有些实现方式中，在允许用户修改用户设置之前，钱包应用可能要求用户输入口令或者成功地回答一个有挑战性的问题。另外，在有些实现方式中，如果用户期望修改耦合的钱包的钱包设置(见1705)，则设备可以确定用户是否被授权这么做，1706。例如，设备可以确定用户的钱包与该耦合的钱包之间的关系类型；在钱包设置可以被修改之前是否要求耦合的钱包(或者其用户)提供许可；等等。在需要来自耦合的钱包用户的授权的实现方式中，设备可以向耦合的钱包用户的设备提供一个请求(例如，经利用虚拟钱包为每个用户的设备存储网络地址的服务器系统)。在确定用户的钱包有权修改耦合的钱包的设置后(见1707)，设备可以识别用户期望执行的修改的类型，1708。在有些实现方式中，用户是否被授权修改钱包设置可以依赖于用户期望修改的钱包设置，在这种情况下，修改类型的识别可以在确定用户是否被授权修改钱包设置之前执行。基于用户所请求的修改类型，设备可以提供图形用户界面(GUI)组件(见例如用于标记可以从其启动对特定购买控制设置的交易的国家的地图，图16B[中间])，以方便对钱包设置进行修改的用户输入，1709。设备可以经GUI组件获得用户设置值输入，1710。当修改涉及耦合的钱包时，设备可以可选地提供涉及该耦合的钱包的设置修改的通知，1711。设备可以可选地在数据库中，例如在本地数据库中或者云存储数据库中，存储钱包设置的修改，1712。

图17B-C示出了说明在UEP的有些实施例中实现购买控制设置的示例方面的逻辑流图，例如，购买控制设置(“PCS”)组件1720。参考图17B，在有些实现方式中，用户可能期望生成购买控制设置，来监视和／或约束具有特殊特点的交易被UEP处理。用户可以把这种指示提供给为用户执行虚拟钱包应用的用户设备，1721。作为响应，设备可以为用户提供选择参数的GUI组件，根据该参数来约束从用户的虚拟钱包启动的交易，1722(见例如图16B的滚轮)。用户可以利用该GUI组件来选择约束参数，1723。基于选定的约束参数(例如，地理位置、交易价值、交易卡、产品分类、时间、日期、货币、账户余额等)，设备可以通过例如查询数据库来识别为用户提供方便用户提供与约束参数关联的值的GUI组件(见例如图16B[中间]的世界地图)，1724。设备可以把识别出的GUI组件提供给用户，1725。利用该GUI组件，用户可以为约束参数提供一个值，1726。作为响应，设备可以生成包括约束参数的标识及与约束参数关联的值的数据片段，1727。例如，该数据片段可以格式化为XML数据结构。在有些实现方式中，数据结构还可以包括约束参数值是否代表对那个参数允许的值范围的上限或下限。设备可以把用于该约束参数的数据结构附加到用于整体购买控制设置的数据结构，1727。在有些实现方式中，设备可以确定用户是否期望输入更多的这种约束参数，而且可以方便用户在任何先前提供的约束参数之上输入这种约束参数(见1728-1729)。在获得用于给定购买控制设置的所有约束参数之后，设备可以把最终定下来的购买控制设置存储到数据库(例如，本地数据库、云存储数据库等)，1730。

参考图17C，在有些实现方式中，用户可能期望进入购买交易。用户可以把输入提供给执行虚拟钱包应用的用户设备，该输入指示用户期望进入购买交易，1731。作为响应，设备可以识别交易的参数(例如，地理位置、交易价值、交易卡、产品分类、时间、日期、购物车、钱包类型[耦合的、非耦合的]、货币、大约交易启动时的账户余额等)，1732。设备可以查询数据库中可以应用到该购买交易请求的购买控制设置，1733。例如，这些可以包括由耦合的钱包用户设定的规则，其中该用户已经被授权对用户的钱包设定购买控制。设备可以处理每个购买控制设置，来确保没有设置被违反。在备选方案中，设备可以处理购买控制设置，直到至少一个购买控制设置允许购买交易执行(或者，如果没有设置允许，则购买交易可以被拒绝)，见1734。设备可以选择购买控制设置，并且从该购买控制设置数据结构提取约束参数及其关联的值。例如，设备可以使用类似于以下在参考图61的讨论中所描述的示例解析器的解析器。设备可以选择约束参数-值对，1736，并且确定交易参数是否违反了约束参数值，1737。如果违反了约束(1738，选项“是”)，则设备可以拒绝购买交易请求。否则，设备可以在与上述类似的过程中检查购买控制设置中的每个约束参数(见1739)。如果购买控制设置不约束交易，则设备可以对所有其它购买控制设置都执行类似的过程，除非有一个设置被违反(或者，在备选方案中，如果至少一个购买控制设置允许该购买交易)(见1740)。如果设备确定购买交易被用户和／或耦合钱包用户的购买控制设置允许(1740，选项“否”)，则设备可以生成卡授权请求，1741，并且为购买交易授权提供卡授权请求(见图57A)。

集中式个人信息平台

图18示出了说明在UEP的有些实施例中集中式个人信息平台的示例方面的框图。在各种场景中，例如商家1811b、消费者1811c、账户发行者、让受方1811a等的发起人1811都期望利用来自付款网络系统的信息启用用于消费者的各种特征。这种特征可以包括应用服务1812，例如报警1812a、提议项1812c、汇款1812n、欺诈行为检测1812b等。在UEP的有些实施例中，这种发起人可以从公共、安全的集中式信息平台请求数据来启用应用服务，其中该信息平台包括整合的、跨实体简档图数据库1801。例如，发起人可以用结构格式，例如下面的示例，向UEP提交复杂的查询。在这个示例中，查询包括确定(例如，用户的)位置、确定与该位置关联的天气、对天气数据执行分析并且提供分析结果的分解图示的查询：

以下提供UEP可以基于查询返回的数据的非限制性示例列表。在这个示例中，用户可以经计算设备登录到网站中。计算设备可以向UEP提供IP地址和时间戳。作为响应，UEP可以从其数据库识别用户的简档，并且基于该简档返回有提议项或优惠券的潜在商家：

在有些实施例中，UEP可以按需要知道为基础提供对信息的访问，以便确保UEP在其上存储信息的实体的数据安全性。因而，在有些实施例中，从集中式平台对信息的访问可以基于发起人及为其请求数据的应用服务来约束。因此，在有些实施例中，UEP可以允许多种灵活的应用服务器在共用的数据库基础设施上建立，同时保存实体数据的完整性、安全性和准确性。在有些实现方式中，UEP可以生成、更新、维护、存储和／或提供关于实体的简档信息，及维护和更新UEP中所存储的每个实体之间相互关系的社交图。例如，UEP可以存储关于发行者银行1802a(见简档1803a)、让受方银行1802b(见简档1803b)、消费者1802c(见简档1803c)、用户1802d(见简档1803d)、商家1802e(见简档1803e)、第二商家1802f(见简档1803f)的简档信息。UEP还可以存储这种实体之间的关系。例如，UEP可以存储关于发行银行1802a到在商家1802e购物的消费者1802c的关系，商家1802e又可以关联到用户1802d，该用户1802d可能是处在后台的银行1802b，充当商家1802f的让受方。

图19A-F示出了说明在UEP的有些实施例中集中式个人信息平台中的数据模型的示例方面的框图。在各种实施例中，UEP可以存储根据各种数据模型的多种实体属性。以下提供一些非限制性的示例数据模型。在有些实施例中，UEP可以存储用户简档属性。例如，用户简档模型可以存储用户识别信息1901、用户别名1902、电子邮件地址1903、电话号码1904、地址1905、电子邮件地址类型1906、地址类型1907、用户别名类型1908、通知状态1909、ISO国家1910、电话号码类型1911、与UEP的合同信息1912、用户授权状态1913、用户简档状态1914、安全性答案1915、安全性问题1916、语言1917、时区1918等，以上每个字段类型都包括一个或多个字段和字段值。作为另一个示例，用户的财务属性模型可以存储用户识别信息1920、用户财务账户信息1921、账户合同信息1922、用户财务账户角色1923、财务账户类型1924、财务账户识别信息1925、合同信息1926、财务账户验证1927、财务账户验证类型1928等。作为另一个示例，用户支付卡属性数据模型可以包括以下字段类型，例如但不限于：用户识别信息1930、用户财务账户信息1931、用户财务账户角色1932、账户消费者应用1933、用户消费者应用1934、财务账户类型1935、财务账户验证类型1936、财务账户信息1937、消费者应用信息1938、消费者应用提供商信息1939等。作为另一个示例，用户服务属性数据模型可以包括以下字段类型，例如但不限于：用户识别信息1940、用户别名1941、消费者应用用户别名状态1942、用户别名状态1943、状态改变原因代码1944、用户合同1945、合同信息1946、用户服务属性值1947、消费者应用属性1948、账户服务属性值1949、账户合同1950、用户简档状态1951、合同业务角色1952、合同业务1953、客户端信息1954、合同角色1955、消费者应用1956、用户活动审核1957、登录结果1958等。作为另一个示例，用户服务使用属性数据模型可以包括以下字段类型，例如但不限于：用户识别信息1960、用户别名1961、消费者应用用户别名状态1962、状态改变原因代码1963、用户别名状态1964、用户消费者应用1965、用户登录审核1966、登录结果1967、账户服务属性值1968、账户消费者应用1969、消费者应用1970、消费者应用提供商1971、登录结果1972等。作为另一个示例，用户图属性数据模型可以包括以下字段类型，例如但不限于：用户识别信息1980、用户联系1981、消费者应用用户别名状态1982、关系1983等。在有些实施例中，UEP可以在图数据库中把每个对象(例如，用户、商家、发行者、让受方、IP地址、家用等)存储为节点，并且以例如下面提供的示例格式的格式存储关于每个节点的数据：

在备选示例中，UEP可以按JavaScript对象标注(“JSON”)格式存储数据。所存储的信息可以包括关于对象的数据，其中的对象例如但不限于：命令、属性、组信息、支付信息、账户信息等，就像在下面的示例中：

图20示出了说明在UEP的有些实施例中示例UEP组件配置的框图。在有些实施例中，UEP可以聚合来自多种源的数据，以便生成集中式的个人信息。为了生成集中式的个人信息，UEP还可以聚合各种类型的数据。例如，UEP可以利用搜索结果聚合组件2001(例如，像在图21-22中所描述的)聚合来自跨广泛计算机联网系统，例如互联网，的搜索结果。作为另一个示例，UEP可以利用交易数据聚合组件2002(例如，像在图23-26中所描述的)聚合来自例如通过付款网络的交易处理过程的交易数据。作为另一个示例，UEP可以利用服务使用数据聚合组件2003(例如，像在图23-26中所描述的)聚合关于与UEP关联的各种服务的用户使用的数据。作为另一个示例，UEP可以利用注册数据组件2004(例如，像在图23-26中所描述的)聚合关于用户登记到与UEP关联的各种服务的数据。作为另一个示例，UEP可以利用社交数据聚合组件2005(例如，像在图27-28中所描述的)聚合关于用户使用可以由UEP访问的各种社交网络服务的数据。

在一些实施例中，UEP可以获得聚合的数据，并且经数据记录正规化组件2006(例如，像在图31中所描述的)把数据正规化成适合一致存储、索引、维护和／或进一步处理的格式。UEP可以从正规化的数据记录提取数据，并且识别数据字段，例如，UEP可以经数据字段识别组件2007(例如，像在图32中所描述的)识别包括在正规化后的数据记录中的每个数据字段的属性。例如，UEP可以从聚合数据识别名字、用户ID、地址、网络地址、评语和／或评语中的特殊的词、图像、博客文章、视频、视频中的内容等。在有些实施例中，对于每个数据字段，UEP可以经例如组件2008(例如，像在图33中所描述的)把与数据字段关联的实体类型，及与数据字段关联的实体标识符分类。例如，UEP可以识别要与用户ID john.q.public(消费者实体类型)、用户John Q.Public(消费者实体类型)、家用(公共家用——多消费者实体类型／家用实体类型)、从所述IP地址从其进行购买的具有标识符Acme Merchant Store，Inc的商家实体类型、与从所述IP地址进行购买关联的具有标识符First National Bank的发行银行类型等关联的互联网协议(IP)地址数据字段。在有些实施例中，UEP可以利用实体类型和实体标识符来彼此关联实体，例如，经跨实体相关组件2009(例如，像在图34中所描述的)。例如，UEP可以从聚合数据识别出具有标识符H123的家用实体可以包括具有标识符John Q.Public和社交标识符john.q.publicfacebook.com的用户实体，具有标识符Jane P.Doe和社交标识符ipdoetwitter.com的第二个用户实体，具有标识符IP地址192.168.4.5的计算机实体，具有标识符****1234的卡账户实体，具有标识符AB23145的银行发行者实体，家庭子实体进行购买的、具有标识符Acme Stores，Inc的商家实体，等等。在有些实施例中，UEP可以利用实体标识符、与每个实体关联的数据和／或相关的实体来识别与其它实体的关联，例如，经实体属性关联组件2010(例如，像在图35中所描述的)。例如，UEP可以识别由家庭成员经购买交易所进行的特殊购买，并且由此基于由该家庭成员所进行的购买交易中的购买识别该家庭成员的属性。基于这种相关与关联，UEP可以更新从聚合数据识别出的每个实体的简档，及相互关联在聚合数据中识别出的实体的社交图，例如，经实体简档图更新组件2011(例如，像在图36中所描述的)。在有些实施例中，例如，经搜索项生成组件2013-2014(例如，像在图37中所描述的)，对实体的简档和／或社交图的更新可以触发对与为每个实体新识别出的相关和关联相关的附加数据的搜索。例如，对简档和／或社交图的更新可以触发跨互联网、社交网络站点、来自付款网络的交易数据、登记到和／或由实体使用的服务等的搜索。在有些实施例中，实体简档和／或社交图的这种更新可以持续地、周期性地、按需等执行。

图21示出了说明在UEP的有些实施例中一种示例搜索结果聚合过程的数据流图。在有些实现方式中，支付网络服务器可以获得执行搜索的触发。例如，支付网络服务器可以利用从多种来源，例如互联网，可以获得的新信息周期性地对其聚合的搜索数据库执行搜索更新，例如2110。作为另一个示例，对按需搜索更新的请求可以作为用户希望登记到服务中的结果获得，为此，支付网络服务器可以通过利用从搜索更新获得的关于用户的信息提供自动化的网络表单填充系统来方便数据输入。在有些实现方式中，支付网络服务器可以解析触发，来提取关键字，利用这些关键字可以执行聚合搜索。支付网络服务器可以生成对用于各种搜索引擎(例如，Google^TM、

AskJeeves、市场数据搜索引擎等)的应用编程接口(API)模板的查询，从这些引擎收集要聚合的数据。支付网络服务器可以查询，例如2112，支付网络数据库，例如2107，中用于这些搜索引擎的API模板。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。作为响应，数据库可以提供，例如2113，API模板的列表。基于该API模板列表，支付网络服务器可以生成搜索请求，例如2114。支付网络服务器可以向搜索引擎服务器，例如2101a-c，发布所生成的搜索请求，例如2115a-c。例如，支付网络服务器可以发布请求用于搜索结果的搜索引擎的PHP命令。基本上是以PHP命令的形式，发布搜索请求2115a-c的命令的示例列表在下面提供：

在有些实施例中，搜索引擎服务器可以查询，例如2117a-c，它们的搜索数据库，例如2102a-c，中属于搜索关键字范围内的搜索结果。响应该搜索查询，搜索数据库可以向搜索引擎服务器提供搜索结果，例如2118a-c。搜索引擎服务器可以把从搜索数据库获得的搜索结果，例如2119a-c，返回到做出搜索请求的支付网络服务器。基本上是以JavaScript对象标注(JSON)格式化数据的形式，搜索结果2119a-c的示例列表在下面提供：

在有些实施例中，支付网络服务器可以在聚合搜索数据库，例如2110，中存储聚合搜索结果，例如2120。

图22示出了说明在UEP的有些实施例中聚合搜索结果的示例方面的逻辑流图，例如，搜索结果聚合(“SRA”)组件2200。在有些实现方式中，支付网络服务器可以获得执行搜索的触发，例如2201。例如，支付网络服务器可以利用从多种来源，例如互联网，可以获得的新信息周期性地对其聚合搜索数据库执行搜索更新。作为另一个示例，对按需搜索更新的请求可以作为用户希望登记到一种服务中的结果获得，为此，支付网络服务器可以通过利用从搜索更新获得的关于用户的信息提供自动化的网络表单填充系统来方便数据输入。在有些实现方式中，支付网络服务器可以解析触发，例如2202，来提取关键字，利用这些关键字可以执行聚合搜索。支付网络服务器可以利用提取出的关键字确定要搜索的搜索引擎，例如2203。然后支付网络服务器可以生成对用于各种搜索引擎(例如，Google^TM、

AskJeeves、市场数据搜索引擎等)的应用编程接口(API)模板的查询，从这些引擎收集要聚合的数据，例如2204。支付网络服务器可以查询，例如2205，支付网络数据库中用于这些搜索引擎的API模板。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。作为响应，数据库可以提供，例如2205，API模板的列表。基于该API模板列表，支付网络服务器可以生成搜索请求，例如2206。支付网络服务器可以向搜索引擎服务器发出所生成的搜索请求。搜索引擎服务器可以解析所获得的搜索结果，例如2207，并且查询，例如2208，它们的搜索数据库中属于搜索关键字范围内的搜索结果。响应该搜索查询，搜索数据库可以向搜索引擎服务器提供搜索结果，例如2209。搜索引擎服务器可以把从搜索数据库获得的搜索结果，例如2210，返回到作出搜索请求的支付网络服务器。支付网络服务器可以生成，例如2211，并且在聚合搜索数据库中存储聚合搜索结果，例如2212。

图23A-D示出了说明在UEP的有些实施例中基于卡的示例交易执行过程的数据流图。在有些实现方式中，用户，例如2301，可能期望从商家购买产品、服务、提议项等(“产品”)。用户可以经客户端与商家的服务器，例如2303，通信，其中客户端例如但不限于：个人电脑、移动设备、电视机、销售点终端、信息站、ATM等(例如2302)。例如，用户可以把用户输入，例如购买输入2311，提供到客户端中，该输入指示用户期望购买产品。在各种实现方式中，用户输入可以包括但不限于：键盘输入、刷卡、激活启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。例如，用户可以把在客户端设备上执行的浏览器应用指向商家的网站，而且可以经点击通过该网站呈现给用户的超链接从该网站选择产品。作为另一个示例，客户端可以获得来自用户的卡(例如，信用卡、借记卡、预付卡、充值卡，等等)的轨道1数据，例如以下提供的示例轨道1数据：

在有些实现方式中，客户端可以生成购买订单消息，例如2312，并且把生成的购买订单消息提供，例如2313，给商家服务器。例如，在客户端上执行的浏览器应用可以代表用户提供(安全的)超文本传输协议(“HTTP(S)”)GET消息，该消息包括以根据可扩展标记语言(“XML”)格式化的数据形式的用于商家服务器的产品订单详情。以下是包括用于商家服务器的XML格式化购买订单消息的示例HTTP(S)GET消息：

在有些实现方式中，商家服务器可以从客户端获得购买订单消息，而且可以解析该购买订单消息，提取来自用户的购买订单的详情。商家服务器可以生成卡查询请求，例如2314，以便确定交易是否可以被处理。例如，商家服务器可以尝试确定在具有购买订单的卡账户中用户是否具有足够的资金来支付购买。商家服务器可以向让受方服务器，例如2304，提供生成的卡查询请求，例如2315。例如，让受方服务器可以是维护商家账户的让受方金融机构(“让受方”)的服务器。例如，由商家处理的交易的进行可以堆积到让受方维护的账户中。在有些实现方式中，卡查询请求可以包括例如但不限于以下的详情：交易中所涉及的用户的成本、用户的卡账户详情、用户的开票和／或发货信息，等等。例如，商家服务器可以提供包括类似于以下列出的示例列表的XML格式化卡查询请求的HTTP(S)POST消息：

在有些实现方式中，让受方服务器可以利用所获得的卡查询请求生成卡授权请求，例如2316，并且把卡授权请求，例如2317，提供给支付网络服务器，例如2305。例如，让受方服务器可以把以上示例中来自商家服务器的HTTP(S)POST消息重定向到支付网络服务器。

在有些实现方式中，支付网络服务器可以确定用户是否登记到增值用户服务中。例如，支付网络服务器可以查询2318数据库，例如支付网络数据库2307，中的用户服务登记数据。例如，服务器可以利用类似于以上提供的示例的PHP／SQL命令来查询支付网络数据库。在有些实现方式中，数据库可以提供用户服务登记数据，例如2319。用户登记数据可以包括指示用户是否登记的标志，及方便访问用户登记的服务的指令、数据、登录URL、登录API调用模板等。例如，在有些实现方式中，通过提供类似于以下示例的HTTP(S)REDIRECT300消息，支付网络服务器可以把客户端重定向到增值服务器(例如，像增值服务与社交网络相关的社交网络服务器)：

在有些实现方式中，作为增值服务请求，例如2320，的一部分，支付网络服务器可以把从卡授权请求提取出的支付信息提供给增值服务器。例如，支付网络服务器可以向增值服务器提供类似于以下示例的HTTP(S)POST消息：

在有些实现方式中，增值服务器可以向客户端提供服务输入请求，例如2321。例如，增值服务器可以向客户端提供HTML输入／登录表单。客户端可以为用户显示，例如2322，该登录表单。在有些实现方式中，用户可以把登录输入提供到客户端中，例如2323，而且客户端可以为增值服务器生成服务输入响应，例如2324。在有些实现方式中，增值服务器可以根据存储在增值服务器上的用户增值服务登记数据、用户简档等并且基于用户服务输入提供增值服务。基于增值服务的提供，增值服务器可以生成增值服务响应，例如2326，并且把响应提供给支付网络服务器。例如，增值服务器可以提供类似于以下示例的HTTP(S)POST消息：

在有些实现方式中，在从增值服务器接收到增值服务响应之后，支付网络服务器可以从该响应提取登记服务数据，添加到交易数据记录。在有些实现方式中，支付网络服务器可以把卡授权请求转发到适当的支付网络服务器，例如2328，该支付网络服务器可以解析卡授权请求，提取请求的详情。利用提取出的字段和字段值，支付网络服务器可以为对应于用户的卡账户的发行者服务器生成查询，例如2329。例如，用户的卡账户可以链接到为用户发行卡账户的发行者的金融机构(“发行者”)，例如银行机构，其中用户可以经客户端生成的购买订单消息提供卡账户的详情。发行者的发行者服务器，例如2308a-n，可以维护用户卡账户的详情。在有些实现方式中，数据库，例如支付网络数据库2307，可以存储发行者服务器的详情和与发行者服务器关联的卡账户号码。例如，数据库可以是响应结构化查询语言(“SQL”)命令的关系数据库。支付网络服务器可以执行包括SQL命令的超文本预处理器(“PHP”)脚本，从数据库查询发行者服务器的详情。说明查询数据库的本质方面的示例PHP／SQL命令列表在下面提供：

响应获得了发行者服务器查询，例如2329，支付网络数据库可以把所请求的发行者服务器数据提供，例如2330，给支付网络服务器。在有些实现方式中，支付网络服务器可以利用发行者服务器数据生成转发卡授权请求，例如2331，把来自让受方服务器的卡授权请求重定向到发行者服务器。支付网络服务器可以向发行者服务器提供卡授权请求，例如2332a-n。在有些实现方式中，发行者服务器，例如2308a-n，可以解析卡授权请求，并且可以基于该请求的详情查询2333a-n数据库，例如用户简档数据库2309a-n，中用户卡账户的数据。例如，发行者服务器可以发布类似于以下提供的示例的PHP／SQL命令：

在有些实现方式中，关于获得用户数据，例如2334a-n，发行者服务器可以确定用户是否可以利用账户中可用的资金支付交易，例如2335a-n。例如，发行者服务器可以确定用户帐户中是否剩余足够的余额、与账户关联的足够存款，等等。如果发行者服务器确定用户可以利用账户中可用的资金支付交易，则服务器可以向支付网络服务器提供授权消息，例如2336a-n。例如，服务器可以提供类似于以上示例的HTTP(S)POST消息。

在有些实现方式中，支付网络服务器可以获得授权消息，并且解析该消息以便提取授权详情。在确定用户拥有进行交易的足够资金后，支付网络服务器可以从它接收到的卡授权请求生成交易数据记录，并且把交易的详情和关于交易的授权存储，例如2339，到数据库，例如支付网络数据库2307。例如，支付网络服务器可以发布类似于以下示例列表的PHP／SQL命令，以便在数据库中存储交易数据：

在有些实现方式中，支付网络服务器可以把授权消息，例如2340，转发到让受方服务器，该让受方服务器又可以把授权消息，例如2340，转发到商家服务器。商家可以获得该授权消息，并且从其确定用户卡账户中拥有足够的资金进行交易。商家服务器可以把用户的交易记录添加到与被授权交易相关的交易数据批次。例如，商家可以把关于用户交易的XML数据附加到包括用于已经对各个用户，例如2341，授权的交易的XML数据的XML数据文件，并且把XML数据文件存储，例如2342，在数据库，例如商家数据库2304，中。例如，分批XML数据文件可以结构化成类似于以下提供的示例XML数据结构：

在有些实现方式中，服务器还可以生成购买收据，例如2343，并且把购买收据提供给客户端。客户端可以为用户呈现并显示，例如2344，购买收据。例如，客户端可以呈现网页、电子消息、文本／SMS消息、缓冲语音邮件、发射铃声和／或播放音频消息等，并且提供包括但不限于以下的输出：声音、音乐、音频、视频、图像、触觉反馈、振动报警(例如，在具有振动能力的客户端设备上，例如智能电话等)，等等。

参考图23C，在有些实现方式中，商家服务器可以启动一批授权交易的清除。例如，商家服务器可以生成分批数据请求，例如2345，并且把该请求，例如2346，提供给数据库，例如商家数据库2304。例如，商家服务器可以利用类似于以上提供的示例的PHP／SQL命令来查询关系数据库。响应分批数据请求，数据库可以提供被请求的分批数据，例如2347。服务器可以利用从数据库获得的分批数据生成分批清除请求，例如2348，并且把分批清除请求提供，例如2341，给让受方服务器，例如2310。例如，商家服务器可以为让受方服务器提供HTTP(S)POST消息，在消息体中包括XML格式化的批数据。让受方服务器可以利用所获得的分批清除请求生成，例如2350，批支付请求，并且把该分批支付请求提供给支付网络服务器，例如2351。支付网络服务器可以解析分批支付请求，并且提取存储在该分批支付请求中的、用于每笔交易的交易数据，例如2352。支付网络服务可以在数据库，例如支付网络数据库2307，中存储用于每笔交易的交易数据，例如2353。对于每笔提取出的交易，支付网络服务器可以查询，例如2354-2355，数据库，例如支付网络数据库2307，中发行者服务器的地址。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。支付网络服务器可以为它已经为其提取出交易数据的每笔交易生成单独的支付请求，例如2356，并且把单独的支付请求，例如2357，提供给发行者服务器，例如2308。例如，支付网络服务器可以提供类似于以下示例的HTTP(S)POST请求：

在有些实现方式中，发行者服务器可以生成付款命令，例如2358。例如，发行者服务器可以发布从用户的账户扣除资金(或者向用户的信用卡账户充值)的命令。发行者服务器可以向存储用户的账户信息的数据库，例如用户简档数据库2308，发布付款命令，例如2359。发行者服务器可以向支付网络服务器提供资金转移消息，例如2360，支付网络服务器可以把资金转移消息转发，例如2361，到让受方服务器。一个示例HTTP(S)POST资金转移消息在下面提供：

在有些实现方式中，让受方服务器可以解析资金转账消息，并且(例如，利用以上示例中的request_ID字段)把交易关联到商家。然后，让受方服务器可以把资金转移消息中规定的资金转到商家的账户，例如2362。

图24A-E示出了说明在UEP的有些实施例中基于卡的交易执行的示例方面的逻辑流图，例如，基于卡的交易执行(“CTE”)组件2400，其中基于卡的交易执行导致基于卡的交易数据和服务使用数据的生成。在有些实现方式中，用户可以把用户输入提供，例如2401，给客户端，该输入指示用户期望从商家购买产品。客户端可以生成购买订单消息，例如2402，并且把生成的购买订单消息提供给商家服务器。在有些实现方式中，商家服务器可以从客户端获得，例如2403，购买订单消息，并且可以解析该购买订单消息，以便提取来自用户的购买订单的详情。商家客户端可以利用的示例解析器在下面参考图61进一步讨论。商家可以生成对商家数据库的产品数据查询，例如2404，作为响应，数据库可以提供所请求的产品数据，例如2405。商家服务器可以利用产品数据生成卡查询请求，例如2404，以便确定交易是否可以处理。例如，商家服务器只有在用户在具有购买订单的卡账户中具有足够资金支付购买的时候才可以处理交易。商家服务器可以可选地把生成的卡查询请求提供给让受方服务器。让受方服务器可以利用所获得的卡查询请求生成卡授权请求，并且把该卡授权请求提供给支付网络服务器。

在有些实现方式中，支付网络服务器可以确定用户是否登记到增值用户服务。例如，支付网络服务器可以查询数据库，例如2407，中的用户服务登记数据。例如，服务器可以利用类似于以上为查询支付网络数据库所提供的示例的PHP／SQL命令。在有些实现方式中，数据库可以提供用户服务登记数据，例如2408。用户登记数据可以包括指示用户是否登记的标志，及用于方便访问用户登记的服务的指令、数据、登录URL、登录API调用模板等。例如，在有些实现方式中，通过提供HTTP(S)REDIRECT300消息，支付网络服务器可以把客户端重定向到增值服务器(例如，像社交网络服务器，其中增值服务与社交联网相关)。在有些实现方式中，作为增值服务请求(例如2410)的一部分，支付网络服务器可以把从卡授权请求中提取出的付款信息提供给增值服务器。

在有些实现方式中，增值服务器可以向客户端提供服务输入请求，例如2411。客户端可以为用户显示，例如2412，该输入请求。在有些实现方式中，用户可以把输入提供给客户端，例如2413，而且客户端可以为增值服务器生成服务输入响应。在有些实现方式中，增值服务器可以根据存储在增值服务器上的用户增值服务登记数据、用户简档等并且基于用户服务输入提供增值服务。基于增值服务的提供，增值服务器可以生成增值服务响应，例如2417，并且把该响应提供给支付网络服务器。在有些实现方式中，在从增值服务器接收到增值服务响应之后，支付网络服务器可以从该响应提取登记服务数据，添加到交易数据记录，例如2419-2420。

参考图24B，在有些实现方式中，支付网络服务器可以从让受方服务器获得卡授权请求，并且可以解析该卡授权请求，提取请求的详情，例如2420。利用提取出的字段和字段值，支付网络服务器可以为对应于用户的卡账户的发行者服务器生成查询，例如2421-2422。响应获得了发行者服务器查询，支付网络数据库可以向支付网络服务器提供，例如2422，所请求的发行者服务器数据。在有些实现方式中，支付网络服务器可以利用发行者服务器数据生成转发卡授权请求，例如2423，以便把来自让受方服务器的卡授权请求重定向到发行者服务器。支付网络服务器可以向发行者服务器提供卡授权请求。在有些实现方式中，发行者服务器可以解析，例如2424，卡授权请求，并且可以基于请求详情从数据库查询，例如2425，用户卡账户的数据。作为响应，数据库可以提供所请求的用户数据。关于获得用户数据，发行者服务器可以确定用户是否可以利用账户中可用的资金支付交易，例如2426。例如，发行者服务器可以确定用户帐户中是否剩余足够的余额、与该账户关联的足够存款等，比较来自数据库的数据与从卡授权请求获得的交易成本。如果发行者服务器确定用户可以利用账户中可用的资金支付交易，则服务器可以向支付网络服务器提供授权消息，例如2427。

在有些实现方式中，支付网络服务器可以获得授权消息，并且解析该消息来提取授权详情。在确定用户拥有足够资金进行交易后(例如，2430，选项“是”)，支付网络服务器可以从授权消息和／或卡授权请求提取交易卡，例如2433，并且利用卡交易详情生成交易数据记录。支付网络服务器可以提供交易数据记录，用于存储，例如2434，到数据库。在有些实现方式中，支付网络服务器可以把授权消息转发，例如2435，到让受方服务器，该让受方服务器又把授权消息转发，例如2436，到商家服务器。商家可以获得授权消息，并且解析该授权消息，提取其内容，例如2437。商家服务器可以确定用户卡账户中是否拥有进行交易的足够资金。如果商家服务器确定用户拥有足够的资金，例如2438，选项“是”，则商家服务器可以把用于用户的交易记录添加到与被授权交易相关的交易数据批次，例如2439-2440。商家服务器还可以为用户生成购买收据，例如2441。如果商家服务器确定用户不拥有足够的资金，例如2438，选项“否”，则商家服务器可以生成“授权失败”消息，例如2442。商家服务器可以向客户端提供购买收据或者“授权失败”消息。客户端可以为用户呈现并显示，例如2443，购买收据。

在有些实现方式中，商家服务器可以通过生成分批数据请求，例如2444，并且向数据库提供该请求来启动一批授权交易的清除。响应分批数据请求，数据库可以向商家服务器提供所请求的分批数据，例如2445。服务器可以利用从数据库获得的分批数据生成分批清除请求，例如2446，并且把分批清除请求提供给让受方服务器。让受方服务器可以利用所获得的分批清除请求生成，例如2448，分批付款请求，并且把分批付款请求提供给支付网络服务器。支付网络服务器可以解析，例如2449，分批付款请求，选择存储在分批数据中的交易，例如2450，并且提取存储在分批付款请求中的用于交易的交易数据，例如2451。支付网络服务器可以生成交易数据记录，例如2452，并且在数据库中存储交易数据，例如2453。对于提取出的交易，支付网络服务器可以为维护请求交易的用户账户的发行者服务器的地址生成发行者服务器查询，例如2454。支付网络服务器可以把该查询提供给数据库。作为响应，数据库可以提供支付网络服务器所请求的发行者服务器数据，例如2455。支付网络服务器可以为已经为其提取出交易数据的交易生成单独的支付请求，例如2456，并且利用来自数据库的发行者服务器数据把单独的支付请求提供给发行者服务器。

在有些实现方式中，发行者服务器可以获得单独的支付请求，并且解析，例如2457，该单独的支付请求，提取请求的详情。基于提取出的数据，发行者服务器可以生成付款命令，例如2458。例如，发行者服务器可以发布从用户帐户扣除资金(或者给用户的信用卡账户充值)的命令。发行者服务器可以向存储用户的账户信息的数据库发布付款命令，例如2459。作为响应，数据库可以更新对应于用户帐户的数据记录，反映对用户帐户所做的借记／充值。在付款命令被数据库执行以后，发行者服务器可以向支付网络服务器提供资金转移消息，例如2460。

在有些实现方式中，支付网络服务器可以检查该批次中是否有别的交易需要被清除和提供资金。如果有别的交易，例如2461，选项“是”，则支付网络服务器可以根据上述过程处理每笔交易。支付网络服务器可以生成，例如2462，反映该批次中所有交易的转账的聚合资金转移消息，并且把资金转移消息提供，例如2463，给让受方服务器。作为响应，让受方服务器可以把金转移消息中规定的资金转到商家的账户，例如2464。

图25示出了说明在UEP的有些实施例中聚合基于卡的交易数据的示例过程的数据流图。在有些实现方式中，支付网络服务器可以确定执行分析所需的数据聚合的范围，例如2511。支付网络服务器可以基于所确定的范围启动数据聚合。支付网络服务器可以生成对在所确定范围内存储交易数据的地址的查询。支付网络服务器可以查询，例如2512，支付网络数据，例如2507a，中在所确定的数据聚合范围内可能已经存储了交易数据的支付网络服务器的地址。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。响应支付网络服务器查询，数据库可以提供，例如2513，服务器地址的列表。基于该服务器地址列表，支付网络服务器可以生成交易数据请求，例如2514。支付网络服务器可以向其它支付网络服务器，例如2505b-d发布所生成的交易数据请求，例如2515a-c。其它支付网络服务器可以查询，例如2517a-c，它们的支付网络数据库，例如2507a-d，中属于该交易数据请求范围内的交易数据。响应交易数据查询，支付网络数据库可以向其它支付网络服务器提供交易数据，例如2518a-c。其它支付网络服务器可以把从支付网络数据库获得的交易数据，例如2519a-c，返回到作出交易数据请求的支付网络服务器，例如2505a。支付网络服务器，例如2505a，可以在聚合交易数据库，例如2510a，中存储聚合的交易数据，例如2520。

图26示出了说明在UEP的有些实施例中聚合基于卡的交易数据的示例方面的逻辑流图，例如，交易数据聚合(“TDA”)组件2600。在有些实现方式中，支付网络服务器可以获得聚合交易数据的触发，例如2601。例如，该服务器可以配置成规律地、周期性地(例如，每小时、每天、每周、每月、每季度、每半年、每年等)启动交易数据聚合。作为另一个示例，服务器可以配置成在获得美国政府(例如，商务部、管理和预算办公室等)公布与美国商业经济相关的新统计数据的信息后启动交易数据聚合。作为另一个示例，服务器可以配置成在获得要处理的用户投资策略分析请求后按需启动交易数据聚合。支付网络服务器可以确定执行分析所需的数据聚合范围，例如2602。例如，数据聚合的范围可以预先确定。作为另一个示例，数据聚合的范围可以基于接收到的用户投资策略分析请求来确定。支付网络服务器可以基于所确定的范围启动数据聚合。支付网络服务器可以在所确定的范围内生成对存储交易数据的服务器地址的查询，例如2603。支付网络服务器可以查询数据库中可能已经在所确定的数据聚合范围内存储了交易数据的支付网络服务器地址。响应支付网络服务器查询，数据库可以提供，例如2604，服务器地址的列表。基于该服务器地址列表，支付网络服务器可以生成交易数据请求，例如2605。支付网络服务器可以向其它支付网络服务器发布所生成的交易数据请求。其它支付网络服务器可以获得并解析交易数据请求，例如2606。基于解析数据请求，其它支付网络服务器可以生成交易数据查询，例如2607，并且把交易数据查询提供给它们的支付网络数据库。响应交易数据查询，支付网络数据库可以向其它支付网络服务器提供交易数据，例如2608。其它支付网络服务器可以把从支付网络数据库获得的交易数据返回，例如2609，到作出交易数据请求的支付网络服务器。该支付网络服务器可以根据从其它支付网络服务器接收到的交易数据生成聚合交易数据记录，例如2610，并且把聚合的交易数据存储在数据库中，例如2611。

图27示出了说明在UEP的有些实施例中的示例社交数据聚合过程的数据流图。在有些实现方式中，支付网络服务器可以获得执行社交数据搜索的触发。例如，支付网络服务器可以利用从多种来源，例如在互联网上运行的社交联网服务，可以获得的新信息周期性地执行其聚合的社交数据库的更新，例如2710。作为另一个示例，按需社交数据更新的请求可以作为用户希望登记到一种服务中的结果获得，为此，支付网络服务器可以通过利用从社交数据更新获得的关于用户的信息提供自动化的网络表单填充系统来方便数据输入。在有些实现方式中，支付网络服务器可以解析触发来提取关键字，例用该关键字来执行聚合社交数据更新。支付网络服务器可以为从其收集要聚合的社交数据的各种社交联网服务(例如，

Twitter^TM等)生成对应用编程接口(API)模板的查询。支付网络服务器可以查询，例如2712，支付网络数据库，例如2707，中用于社交联网服务的社交网络API模板。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。作为响应，数据库可以提供，例如2713，API模板的列表。基于该API模板列表，支付网络服务器可以生成社交数据请求，例如2714。支付网络服务器可以向社交网络服务器，例如2701a-c发布所生成的社交数据请求，例如2715a-c。例如，支付网络服务器可以发布向社交网络服务器请求社交数据的PHP命令。基本上以PHP命令的形式，下面提供发布社交数据请求，例如2715a-c，的示例命令列表：

在有些实施例中，社交网络服务器可以查询，例如2717a-c，它们的数据库，例如2702a-c，中属于社交关键字范围内的社交数据结果。响应该查询，数据库可以向搜索引擎服务器提供社交数据，例如2718a-c。社交网络服务器可以把从数据库获得的社交数据，例如2719a-c，返回到做出社交数据请求的支付网络服务器。基本上以JavaScript对象标注(JSON)格式化数据的形式，社交数据2719a-c的示例列表在下面提供：

在有些实施例中，支付网络服务器可以在聚合搜索数据库，例如2710，中存储聚合的搜索结果，例如2720。

图28示出了说明在UEP的有些实施例中聚合社交数据的示例方面的逻辑流图，例如，社交数据聚合(“SDA”)组件2800。在有些实现方式中，支付网络服务器可以获得执行社交搜索的触发，例如2801。例如，支付网络服务器可以利用从多种来源，例如互联网，可以获得的新信息周期性地执行其聚合社交数据库的更新。作为另一个示例，按需社交数据更新的请求可以作为用户希望登记到一种服务中的结果获得，为此，支付网络服务器可以通过利用从社交数据更新获得的关于用户的信息提供自动化的网络表单填充系统来方便数据输入。在有些实现方式中，支付网络服务器可以解析触发，例如2802，来提取关键字和／或用户ID，例用该关键字或用户ID来执行对社交数据的聚合搜索。支付网络服务器可以利用提取出的关键字和／或用户ID确定要搜索的社交联网服务，例如2803。然后，支付网络服务器可以为从其收集要聚合的社交数据的各种社交联网服务(例如，

Twitter^TM等)生成对应用编程接口(API)模板的查询，例如2804。支付网络服务器可以查询，例如2805，支付网络数据库，中用于社交联网服务的搜索API模板。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。作为响应，数据库可以提供，例如2805，API模板的列表。基于该API模板列表，支付网络服务器可以生成社交数据请求，例如2806。支付网络服务器可以向社交联网服务发布所生成的社交数据请求。社交网络服务器可以解析所获得的搜索结果，例如2807，并且查询，例如2808，它们的数据库中属于搜索关键字范围内的社交数据。响应社交数据查询，数据库可以向社交联网服务器提供社交数据，例如2809。社交联网服务器可以把从数据库获得的社交数据，例如2810，返回到做出社交数据请求的支付网络服务器。支付网络服务器可以生成，例如2811，并且在聚合社交数据库中存储聚合的社交数据，例如2812。

图29示出了说明在UEP的有些实施例中用于注册增值服务的示例过程的数据流图。在有些实现方式中，用户，例如2901，可能期望登记到增值服务中。让我们考虑一个示例，其中用户期望登记到作为增值服务的社交网络认证购买支付中。应当理解，任何其它增值服务都可以代替以下描述的增值服务。用户可以经客户端与支付网络服务器，例如2903，通信，其中客户端例如但不限于：个人电脑、移动设备、电视机、销售点终端、信息站、ATM等(例如，2902)。例如，用户可以把用户输入，例如登记输入2911，提供给客户端，该输入指示用户期望登记到社交网络认证的购买支付中。在各种实现方式中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。例如，用户可以在客户端2902刷支付卡。在有些实现方式中，客户端可以获得来自用户的卡(例如，信用卡、借记卡、预付卡、充值卡等)的轨道1数据，作为登记输入2911，例如以下提供的示例轨道1数据：

在有些实现方式中，利用用户的输入，客户端可以生成登记请求，例如2912，并且把该登记请求，例如2913，提供给支付网络服务器。例如，客户端可以提供(安全的)超文本传输协议(“HTTP(S)”)POST消息，该消息包括根据可扩展标记语言(“XML”)格式化的数据。以下是包括用于支付网络服务器的XML格式化注册请求的示例HTTP(S)POST消息：

在有些实现方式中，支付网络服务器可以从客户端获得登记请求，并且从该登记请求提取用户的付款详情(例如，XML数据)。例如，支付网络服务器可以利用例如以下在参考图61的讨论中所描述的示例解析器的解析器。在有些实现方式中，支付网络服务器可以查询，例如2914，支付网络数据库，例如2904，以便获得社交网络请求模板，例如2915，来处理登记请求。社交网络请求模板可以包括用于方便社交网络认证的指令、数据、登录URL、登录API调用模板等。例如，数据库可以是响应结构化查询语言(“SQL”)命令的关系数据库。商家服务器可以执行包括SQL命令的超文本预处理器(“PHP”)脚本，从数据库查询产品数据。说明查询数据库，例如2914-2915，的本质方面的示例PHP／SQL命令列表在下面提供：

在有些实现方式中，支付网络服务器可以通过提供HTTP(S)REDIRECT300消息把客户端重定向到社交网络服务器，类似于下面的示例：

在有些实现方式中，作为社交网络认证登记请求，例如2917，的一部分，支付网络服务器可以把从卡授权请求中提取出的支付信息提供给社交网络服务器。例如，支付网络服务器可以向社交网络服务器提供HTTP(S)POST消息，类似于下面的示例：

在有些实现方式中，社交网络服务器可以向客户端提供社交网络登录请求，例如2918。例如，社交网络服务器可以向客户端提供HTML输入表单。客户端可以为用户显示，例如2919，该登录表单。在有些实现方式中，用户可以把登录输入提供给客户端，例如2920，而且客户端可以为社交网络服务器生成社交网络登录响应，例如2921。在有些实现方式中，社交网络服务器可以认证用户的登录凭证，并且访问存储在社交网络中，例如社交网络数据库中，用户的付款账户信息。在通过认证后，社交网络服务器可以为用户生成认证数据记录，例如2922，并且向支付网络服务器提供登记通知，例如2924。例如，社交网络服务器可以提供类似于以下示例的HTTP(S)POST消息：

在从社交网络服务器接收到登记的通知后，支付网络服务器可以生成，例如2925，用户登记数据记录，并且把该登记数据记录存储在支付网络数据库中，例如2926，来完成登记。在有些实现方式中，登记数据记录可以包括来自登记通知2924的信息。

图30示出了说明在UEP的有些实施例中社交网络支付认证注册的示例方面的逻辑流图，例如，增值服务登记(“VASE”)组件3000。在有些实现方式中，用户，例如2901，可能期望登记到增值服务中。让我们考虑一个示例，其中用户期望登记到作为一种增值服务的社交网络认证的购买付款中。应当理解，任何其它增值服务都可以代替以下描述的增值服务。用户可以经客户端与支付网络服务器通信。例如，用户可以把用户输入，例如3001，提供给客户端，该输入指示用户期望登记到社交网络认证的购买支付中。在各种实现方式中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。在有些实现方式中，利用用户的输入，客户端可以生成登记请求，例如3002，并且把该登记请求提供给支付网络服务器。在有些实现方式中，SNPA可以提供登记按钮，该按钮可以把用户带到登记网页，在那里账户信息可以输入到网络表单字段中。在有些实现方式中，支付网络服务器可以从客户端获得登记请求，并且从该登记请求提取用户的付款详情。例如，支付网络服务器可以利用例如在以下参考图61的讨论中所描述的示例解析器的解析器。在有些实现方式中，支付网络服务器可以查询，例如3004，支付网络数据库，以便获得处理登记请求的社交网络请求模板，例如3005。社交网络请求模板可以包括用于方便社交网络认证的指令、数据、登录URL、登录API调用模板等。在有些实现方式中，作为社交网络认证登记请求，例如3006，的一部分，支付网络服务器可以把从卡授权请求中提取出的付款信息提供给社交网络服务器。在有些实现方式中，社交网络服务器可以把社交网络登录请求提供给客户端，例如3007。例如，社交网络服务器可以把HTML输入表单提供给客户端。客户端可以为用户显示，例如3008，该登录表单。在有些实现方式中，用户可以把登录输入提供给客户端，例如3009，并且客户端可以为社交网络服务器生成社交网络登录响应。在有些实现方式中，社交网络服务器可以认证用户的登录凭证，并且访问存储在社交网络中，例如社交网络数据库中，用户的付款账户信息。在认证之后，社交网络服务器可以为用户生成认证数据记录，例如3011，并且向支付网络服务器提供登记通知，例如3013。在从社交网络服务器接收到登记通知后，支付网络服务器可以生成，例如3014，用户登记数据记录，并且把该登记数据记录存储在支付网络数据库中，例如3015，以便完成登记。支付网络服务器可以提供登记确认，并且把该登记确认提供给客户端，客户端可以为用户显示，例如3017，该确认。

图31A-B示出了说明在UEP的有些实施例中把聚合的搜索、注册、服务、使用、交易和／其它聚合数据正规化成标准化数据格式的示例方面的流程图，例如，聚合数据记录正规化(“ADRN”)组件3100。参考图31A，在有些实现方式中，支付网络服务器(“服务器”)可以尝试把存储在它能够访问的聚合记录数据库中的数据记录转换成正规化的数据格式。例如，数据库可以具有交易数据记录模板，该模板具有可以按预定义格式(例如，长整数／双浮点数／4位小数精度，等等)在预定数据结构中存储数据的预定义的标准字段。一个样本XML交易数据记录模板在下面提供：

在有些实现方式中，服务器可以从数据库查询正规化数据记录模板，例如3101。服务器可以解析正规化数据记录模板，例如3102。基于解析该正规化数据记录模板，服务器可以确定包括在该正规化数据记录模板中的数据字段，及存储在数据记录模板的字段中的数据的格式，例如3103。服务器可以获得要正规化的交易数据。服务器可以从数据库查询，例如3104，未正规化的记录。例如，服务器可以发布PHP／SQL命令，从以上的示例模板检索不具有“norm_flag”字段的记录，或者“norm_flag”字段的值为“false”的那些记录。在获得未正规化的交易数据记录后，服务器可以选择其中一个未正规化的交易数据记录，例如3105。服务器可以解析未正规化的交易数据记录，例如3106，并且确定未正规化的交易数据记录中所存在的字段，例如3107。例如，服务器可以利用与以下参考图32所描述的类似的过程。服务器可以比较来自未正规化的交易数据记录的字段与从正规化交易数据记录模板提取出的字段。例如，服务器可以确定未正规化的交易数据记录中字段的字段标识符与正规化交易数据记录模板的那些(例如，经字典、辞典等)是否匹配、完全相同、同义、相关，等等。基于这种比较，服务器可以生成未正规化的交易数据记录的字段与正规化交易数据记录模板的那些字段之间的1：1映射，例如3109。服务器可以生成正规化交易数据记录模板的拷贝，例如3110，并且利用来自未正规化的交易数据记录的值填充该模板的字段，例如3111。服务器还可以把以上示例中“norm_flag”字段的值变成“true”。服务器可以在数据库中存储填充好的记录(例如，代替原始版本)，例如3112。服务器可以对每个未正规化的交易数据记录重复以上过程(见例如3113)，直到所有未正规化的交易数据记录都被正规化。

参考图31B，在有些实施例中，服务器可以利用元数据(例如，很容易配置的数据)来驱动可以把任何结构化数据转换成标准化XML格式(“encryptmatics”XML)的分析与规则引擎。然后，encryptmatics XML可以被encryptmatics引擎处理，该引擎能够解析、变换和分析数据，基于分析的结果生成决定。相应地，在有些实施例中，服务器可以实现基于元数据的解释引擎，该引擎解析结构化的数据，包括但不限于：网络内容(见例如3121)、图形数据库(见例如3122)、微博、图像或软件代码(见例如3124)，并且把结构化数据转换成encryptmatics XML文件格式的命令。例如，结构化的数据可以包括但不限于软件代码、图像、自由文本、关系数据库查询、图形查询、感测输入(见例如3123、3125)等。基于元数据的解释引擎，例如3126，可以基于给定的记录利用可配置的元数据，例如3128，填充数据／命令对象，例如3127。可配置的元数据可以为包括在数据记录中的给定符号或关键字定义动作。然后，引擎可以处理对象，作为标准encryptmatics XML文件格式的encryptmatics值的集合，例如3129，导出其数据结构。然后，encryptmatics XML文件可以被处理，以便通过encryptmatics引擎，例如3130，提供各种特征。

在有些实施例中，服务器可以获得结构化的数据，并且利用该结构化输入作为输入(例如，为了说明，包括脚本命令)执行标准化例程。例如，服务器可以从结构化数据，例如3131，除去额外的换行符、空格、制表符等。服务器可以确定并加载元数据库，例如3132，利用该元数据库，服务器可以基于元数据解析脚本中的子例程或函数，例如3133-3134。在有些实施例中，服务器可以基于元数据预解析条件语句，例如3135-3136。服务器还可以基于元数据和之前的解析，例如3138，解析数据3137，来组装数据／命令对象。在完成数据／命令对象之后，服务器可以导出3139数据／命令对象，作为标准化的encryptmatics格式的XML。

图32示出了说明在UEP的有些实施例中识别正规化后的聚合数据记录中的数据字段的示例方面的逻辑流图，例如，数据字段识别(“DFR”)组件3200。在有些实现方式中，服务器可以识别数据记录中所包括的数据字段的类型，例如日期、地址、邮政编码、名字、用户ID、电子邮件地址、付款账户号码(PAN)、CVV₂号等。服务器可以选择未处理过的数据记录进行处理，例如3201。服务器可以解析数据记录规则，并且从数据记录提取数据字段，例如3202。服务器可以从数据库查询数据字段模板，例如3203。例如，服务器可以比较来自数据记录的字段的格式与数据记录模板，以便识别一个数据字段模板与数据记录中每个字段之间的匹配，由此识别数据记录中每个字段的类型。因而，服务器可以从数据记录选择提取出的数据字段，例如3204。服务器可以选择一个数据字段模板，用于与选定的数据字段进行比较，例如3205，并且比较数据字段模板与选定的数据字段，例如3206，以便确定所提取出的数据字段的格式是否匹配数据字段模板的格式，例如3207。如果选定的提取出的数据字段的格式与数据字段模板的格式匹配，例如3208，选项“是”，则服务器可以把数据字段模板的类型指定该给选定的数据字段，例如3209。如果提取出的数据字段的格式与数据字段模板的格式不匹配，例如3208，选项“否”，则服务器可以尝试另一个数据字段模板，直到没有更多的数据字段模板可用于比较，见例如3210。如果没有找到匹配，则服务器可以把“未知”串指定为数据字段的类型，例如3211。服务器可以在数据库中存储更新后的数据记录，例如3212。服务器可以为数据记录中的每个数据字段(而且还为数据库中的每个数据记录)执行这种数据字段识别，见例如3213。

图33示出了说明在UEP的有些实施例中分类实体类型的示例方面的逻辑流图，例如，实体类型分类(“ETC”)组件3300。在有些实现方式中，服务器可以对每个数据记录应用一个或多个分类标签。例如，服务器可以根据实体类型、根据例如但不限于地缘政治区域、所购买物品数量等的标准来给数据记录分类。服务器可以从数据库获得未分类的交易，例如3301，并且获得用于分类记录的规则与标签，例如3302。例如，数据库可以存储分类规则，例如以下提供的示例说明性XML编码分类规则：

服务器可以选择一个未分类的数据记录进行处理，例如3303。服务器还可以选择一个分类规则，用于处理未分类的数据记录，例如3304。服务器可以解析分类规则，并且确定该规则所需的输入，例如3305。基于解析分类规则，服务器可以解析正规化数据记录模板，例如3306，并且提取需要作为输入提供给分类规则的字段值。服务器可以解析分类规则，并且提取要对为规则处理提供的输入执行的操作，例如3307。在确定要执行的操作之后，服务器可以对为分类规则提供的输入执行特定于规则的操作，例如3308。在有些实现方式中，规则可以提供阈值。例如，规则可以规定交易中产品的数量、交易的总价值、交易中所出售的产品的平均奢侈等级等是否需要跨越阈值，以便让与规则关联的标签应用到交易数据记录。服务器可以解析分类规则，以便提取让规则应用所需的任何阈值，例如3309。服务器可以比较计算出的值与规则阈值，例如3310。如果跨过了阈值，例如3311，选项“是”，则服务器可以对交易数据记录应用由分类规则规定的一个或多个标签，例如3312。例如，服务器可以对交易中的单独的产品和／或对作为一个整体的交易应用分类规则。在有些实现方式中，服务器可以利用每个规则处理交易数据记录(见例如3313)。一旦所有分类规则都对交易记录处理过了，例如3313，选项“否”，服务器就可以在数据库中存储交易数据记录，例如3314。服务器可以对每个交易数据记录执行这种处理，直到所有交易数据记录都已经分类(见例如3315)。

图34示出了说明在UEP的有些实施例中识别跨实体相关的示例方面的逻辑流图，例如，跨实体相关(“CEC”)组件3400。在有些实现方式中，服务器可以识别出UEP中的两个实体共享共同或相关的数据字段，例如日期、地址、邮政编码、名字、用户ID、电子邮件地址、付款账户号码(PAN)、CVV₂号等，而且由此把实体识别为相关联的。服务器可以选择要跨实体相关的数据记录，例如3401。服务器可以解析数据记录规则，并且从数据记录提取数据字段，例如3402-3403。服务器可以从数据记录选择提取出的数据字段，例如3404，并且从数据库查询具有与提取出的数据字段相同的数据字段的其它数据记录，例如3405。根据从数据库查询检索出的数据记录列表，服务器可以选择要进一步分析的记录。例如，利用以上在参考图33的描述中所讨论过的ETC3300组件，服务器可以识别，例如3407，与检索出的数据记录关联的实体。服务器可以把一个数据字段添加到为跨实体相关获得的数据记录，规定与检索出的选定数据记录的相关，例如3408。在有些实施例中，服务器可以利用为跨实体相关所获得的数据记录中的每个数据字段来识别相关联的实体，见例如3409。一旦完成，服务器就可以向为跨实体相关所获得的数据记录添加“相关”标志，例如3401，例如，连同规定执行跨实体相关的时间的时间戳一起。例如，这种时间戳可以用于在以后确定数据记录是否应当再次为跨实体相关进行处理。服务器可以在数据库中存储更新后的数据记录。

图35示出了说明在UEP的有些实施例中把属性关联到实体的示例方面的逻辑流图，例如，实体属性关联(“EAA”)组件3500。在有些实现方式中，服务器可以把属性关联到实体，例如，如果实体id是人，则服务器可以基于与该实体相关的数据记录中数据字段的字段值识别人口统计(例如，男／女)、消费特点、购买偏好列表、商家偏好列表等。在有些实现方式中，服务器可以获得用于实体属性关联的数据记录，例如3501。服务器可以解析数据记录规则，并且从数据记录提取数据字段，例如3502-3503。服务器可以从数据记录选择提取出的数据字段，例如3504，并且识别用于从数据记录选定的数据字段的字段值，例如3505。服务器可以利用字段值与字段类型从数据库查询人口统计数据、行为数据等，例如3506。作为响应，数据库可以提供潜在属性的列表，及那些属性与实体关联的可信度，见例如3507。服务器可以把数据字段添加到为实体属性关联所获得的数据记录，规定潜在关联的属性及其关联的可信度，例如3508。在有些实施例中，服务器可以利用为跨实体相关(cross-entitycorrelation)获得的数据记录中的每个数据字段来识别相关联的实体，见例如3509。服务器可以在数据库中存储更新后的数据记录，例如3510。

图36示出了说明在UEP的有些实施例中更新实体简档图的示例方面的逻辑流图，例如，实体简档图更新(“EPGU”)组件3600。在有些实现方式中，服务器可以为其数据存储在UEP中的实体生成／更新简档。服务器可以获得要更新的实体简档记录，例如3601。服务器可以解析实体简档记录，并且从数据记录提取实体标识符数据字段，例如3602。服务器可以利用用于该实体标识符数据字段的值从数据库查询与该同一实体相关的其它数据记录，例如3603。作为响应，数据库可以提供要进一步处理的其它数据记录的列表。服务器可以选择所述其它数据记录中的一个来更新实体简档记录，例如3604。服务器可以解析数据记录并且从该另一记录提取所有的相关、关联与新数据，例如3605。服务器可以比较来自该另一数据记录的相关、属性、关联等与来自实体简档的相关、关联与属性。基于这种比较，服务器可以识别任何新相关、关联等，并且利用新相关、关联生成更新后的实体简档记录；标记新相关、关联等，用于进一步处理，例如3607。在有些实施例中，服务器可以利用所获得的每个数据记录用于更新实体简档记录及其社交图(例如，像由用于该实体的相关与关联所给定的)，见例如3609。服务器可以在数据库中存储更新后的实体简档记录，例如3608。

图37示出了说明在UEP的有些实施例中为简档图更新生成搜索项的示例方面的逻辑流图，例如，搜索项生成(“STG”)组件3700。在有些实现方式中，通过例如跨互联网和社交联网服务执行对新数据的搜索，服务器可以为其数据存储在UEP中的实体生成／更新简档。服务器可以获得要更新的实体简档记录，例如3701。服务器可以解析实体简档记录，并且从该实体简档记录提取数据字段类型与字段值，例如3702。服务器可以利用用于提取出的数据字段的值从数据库查询与该同一实体相关的其它数据记录，例如3703。作为响应，数据库可以提供其它数据记录的列表，用于进一步处理。服务器可以解析数据记录，并且从数据记录提取所有的相关、关联和数据，例如3704。服务器可以聚合来自所有记录和实体简档记录的所有数据值，例如3705。基于此，服务器可以返回聚合的数据值，作为触发搜索过程的搜索项(见例如图20，2001-2005)，例如3706。

基于用户行为的推荐

图38示出了说明在UEP的有些实施例中基于聚合的购买交易数据分析用户行为的示例方面的逻辑流图，例如，用户行为分析(“UBA”)组件3800。在有些实现方式中，支付网络服务器(“服务器”)可以获得需要服务器为其生成用户行为模式的用户的用户ID，例如3801。服务器可以从数据库，例如支付网络数据库，查询该用户的聚合卡交易数据记录，例如3802。服务器还可以从支付网络数据库查询，例如3803，可以被每个字段值采用的所有可能的字段值(例如，AM／PM(上午／下午)、邮政编码、商家_ID、商家名字、交易成本支架(cost bracket)等)。利用交易数据记录中所有字段的字段值，服务器可以生成字段值对，用于对字段值对执行相关性分析，例如3804。一个示例字段值对是：“时间”是“AM”而且“商家”是“Walmart”。然后，服务器可以为聚合交易数据记录中出现的每个字段值对生成可能性估计。例如，服务器可以选择一个字段值对，例如3805。服务器可以确定聚合交易数据记录中该字段值对出现的记录的个数，例如3806。然后，通过用聚合交易数据记录的总数去除所确定的该字段值对的出现次数，服务器可以计算用于该字段值对的可能性商，例如3807。服务器还可以基于样本尺寸指定用于可能性商的可信度，例如，聚合交易数据记录中的记录总数，例如3808。服务器可以生成并存储XML片段，包括字段值对、可能性商及与该可能性商关联的可信度，例如3809。服务器可以为在3804中生成的每个字段值对执行这种计算(见3810)。

图39示出了说明在UEP的有些实施例中基于用户之前的聚合购买交易行为为用户生成推荐的示例方面的逻辑流图，例如，基于用户行为的提议项推荐(“UBOR”)组件3900。在有些实现方式中，支付网络服务器(“服务器”)可以获得需要服务器为其生成提议项推荐的用户的用户ID，例如3901。服务器可以获得用于为用户处理购买交易的卡授权请求中所包括的产品列表，例如3902。服务器还可以从数据库查询各种用户交易相关变量的预先生成的按对方式的(pair-wise)相关，例如3902b，例如由以上参考图38所述的UBA3800组件所生成的那些。服务器可以从卡授权请求中所包括的产品列表选择一个产品，例如3903。服务器可以识别其中选定的产品是字段值相关中的独立字段的所有字段对相关的值，例如3904。服务器可以，例如3905，从识别出的字段对值中识别是用于字段值对的、具有最高可能性商的从属字段值的产品(例如，最有可能与选自卡授权请求中所包括的产品列表的产品被一起购买的产品)。连同其关联的预测可信度一起，服务器可以在推荐产品队列中存储识别出的产品，例如3906。服务器可以为来自卡授权请求的产品列表中所包括的每种产品执行分析，见例如3907。

在有些实现方式中，在对卡授权请求中的所有产品完成这种分析后，服务器可以根据它们关联的可能性商与预测可信度水平给队列排序，例如3908。例如，如果一种产品的预测可信度高于一个阈值，则它可以保留在队列中，但是，如果其预测可信度低于该阈值，则不能保留在队列中。而且，保留的产品可以按其关联的可能性商的降序排序。在有些实现方式中，服务器可以从队列除去任何重复的产品，例如3909。服务器可以返回排序的产品对象，用作产品提议项推荐，例如3910。

社交支付平台

图40示出了说明在UEP的有些实施例中经社交网络的支付交易的示例方面的框图。在有些实施例中，UEP可以方便钱经社交网络的人到人转账，4010。例如，用户(用户14011)可能希望向另一个用户(用户24016)提供资金(美元、奖励、积分、英里等，4014)。用户可以利用虚拟钱包来提供资金源。在有些实施例中，用户可以利用设备4012(例如智能电话、移动设备、膝上型电脑、台式电脑等)经社交网络4015发送社交发帖消息。在有些实施例中，社交发帖消息可以包括关于要转账的资金金额及资金应当转至的另一个用户身份的信息。UEP可以在该消息发送到社交联网服务之前截获该消息，或者它可以从社交联网服务获得该消息。利用社交发帖消息，UEP可以分辨交易中付款人与收款人的身份。UEP可以识别需要向其划入／从其借记资金的付款人和收款人的金额，及应用到每个账户的存入／借记的金额。基于分辨这种信息，UEP可以执行把资金从付款人转移到收款人的交易。例如，通过在Twitter^TM上发送例如“$25jfdoe#ackpls”的tweet，UEP可以允许付款人把资金转移到收款人(用户ID为jfdoe)，并且从UEP请求资金接收的确认。在另一个示例中，通过在Twitter^TM上发送例如“johnq，你欠我50000Visa奖励积分#id1234”的tweet，UEP可以允许潜在的收款人从另一个用户请求资金；UEP可以在具有用户ID johnq的用户的虚拟钱包应用中自动地提供向潜在收款人用户提供资金的报警。作为响应，用户johnq可以通过发送例如参考该id(#id1234)的“50000vptsjfdoe#id1234”的tweet来响应；UEP可以转移资金并且把交易请求#id1234识别为已经履行。在有些实施例中，UEP可以为用户生成交易／请求ID号，以防止对不同的交易／请求有重合的交易／请求ID。

在有些实施例中，UEP可以利用一种或多种社交联网服务(例如，Twitter^TM、MySpace^TM等)。在有些实施例中，UEP可以允许跨不同社交网络的用户彼此交易。例如，用户可以在一种社交网络上做出付款请求。作为另一个示例，Twitter^TM用户可以tweet“johnqfacebook.com，你欠我500vpts#ID7890”。UEP可以经其它社交联网或者经用户的虚拟钱包向具有IDjohnqfacebook.com的用户提供报警。作为响应，付款人可以向

社交发帖一个消息“jfdoe：这里是你的500vpts#ID7890”，而且UEP可以方便付款交易并且在其对应的社交网络或虚拟钱包上向两个用户提供收据／确认。

在有些实施例中，UEP可以方便资金由一个付款人经单个社交发帖消息转移到多于一个收款人。在有些实施例中，UEP可以方便经单个发帖消息使用收款人的多于一个资金来源给一个或多个付款人的资金付款提供资金。例如，UEP可以利用存储在付款人虚拟钱包中的缺省设置或定制规则来经单个社交发帖消息确定使用哪些注资源来向一个或多个收款人的支付交易提供资金。

在有些实现方式中，UEP可以方便商家经社交网络4020向消费者提供产品和／或服务提议项。例如，商家4026可以登录参与到UEP中。UEP可以聚合用户的交易，并且确定可能与提供给用户相关的任何产品或服务。UEP可以确定是否任何参与的商家都可用于为用户提供产品或服务。如果是，则UEP可以代表商家经社交网络4025提供向用户4021提供提议项4024a的社交发帖消息(或者，作为替代，通知可以随后向用户发送社交发帖消息的商家)。给予商家的追随者的一个提议项的示例可以是“amazon仅以$149-99提供新的Kindle^TM——点击此处购买”。在这个示例中，在社交联网站点发布的提议项具有嵌入式链接(例如，此处)，用户可以点击该链接进行购买(如果用户登录到他们的虚拟钱包账户4023中，则这可以利用一次点击自动执行)。商家提议项的另一个示例可以是“amazon仅以$149.99提供新的Kindle^TM——以#offerID123456回复来购买”。在这个示例中，哈希标签值充当提议项的标识符，在用户经其社交发帖消息进行购买时参考该值(例如，“从amazon购买#offerID123456”)。在有些实施例中，商家可以经单个社交发帖消息提供两个或多个提议项。在有些实施例中，用户可以在同一个社交发帖消息中参考两个或多个提议项。

在有些实现方式中，用户和／或商家可以利用备选发消息模式。例如，用户可能能够利用电子邮件、SMS消息、电话呼叫等与UEP和社交网络通信。例如，商家可以提供例如“amazon仅以$149.99提供新的Kindle^TM——发文本消息#offerID123456来购买”的社交发帖消息提议项。当用户利用移动电话发送文本消息来兑换提议项时，UEP可以利用该用户存储在社交联网服务上的用户简档来识别用户移动电话的属性(例如，电话号码)，利用该属性，UEP可以把文本消息关联到特定的用户。因而，UEP可能能够代表用户利用来自用户虚拟钱包的用户信息处理与商家的交易。在其中社交网络不能处理特定通信模式的实施例中，UEP可以充当中间翻译，把消息转换成可以被社交网络利用的形式。

图41示出了说明在UEP的有些实施例中示例社交支付注册过程的数据流图。在有些实施例中，用户，例如4101，可能期望登记到UEP中。用户可以经客户端与社交支付服务器，例如4103a，通信，其中的客户端例如但不限于：个人电脑、移动设备、电视机、销售点终端、信息站、ATM等(例如，4102)。例如，用户可以把用户输入，例如社交支付登记输入4111，提供给客户端，该输入指示用户期望登记到社交网络认证的购买支付。在各种实现方式中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。

在有些实现方式中，利用用户的输入，客户端可以生成社交支付登记请求，例如4112，并且把该登记请求提供给社交支付服务器4103a。例如，客户端可以提供(安全的)超文本传输协议(HTTP(S))POST消息，该消息包括根据可扩展标记语言(“XML”)格式化的数据。以下是用于社交支付服务器的、包括XML格式化的登记请求的示例HTTP(S)POST消息：

在有些实施例中，社交支付服务器可以从客户端获得登记请求，并且从该登记请求提取用户付款详情(例如，XML数据)。例如，社交支付服务器可以利用例如在以下参考图61的讨论中所描述的示例解析器的解析器。在有些实现方式中，社交支付服务器可以查询，例如4113，社交支付数据库，例如4103b，以便获得社交网络请求模板，例如4114，来处理登记请求。社交网络请求模板可以包括用于方便社交网络认证的指令、数据、登录URL、登录API调用模板等。例如，数据库可以是响应结构化查询语言(“SQL”)命令的关系数据库。商家服务器可以执行包括SQL命令的超文本预处理器(“PHP”)脚本来从数据库查询产品数据。下面提供说明查询数据库，例如4114-4115，的实质方面的示例PHP／SQL命令列表：

在有些实现方式中，通过提供类似于以下示例的HTTP(S)REDIRECT300消息，社交支付服务器可以把客户端重定向到社交网络服务器，例如4104a：

在有些实现方式中，作为用户认证／社交支付应用登记请求，例如4115，的一部分，社交支付服务器可以把从社交支付登记请求提取出的信息提供给社交网络服务器。例如，社交支付服务器可以向社交网络服务器提供类似于以下示例的HTTP(S)POST消息：

在有些实现方式中，社交网络服务器可以向客户端提供社交网络登录请求，例如4116。例如，社交网络服务器可以向客户端提供HTML输入。客户端可以为用户显示，例如4117，登录表单。在有些实现方式中，用户可以把登录输入提供给客户端，例如4118，而且客户端可以为社交网络服务器生成社交网络登录响应，例如4119。在有些实现方式中，社交网络服务器可以认证用户的登录凭证，并且在这么做之后，更新用户的简档，指示用户登记到社交支付系统中。例如，在像

的社交联网服务中，社交网络服务器可以向社交支付第三方开发商应用提供访问存储在社交网络中的用户信息的许可。在有些实施例中，这种登记可以允许安装在用户设备上的虚拟钱包应用访问存储在社交网络中的用户的社交简档信息。在通过认证之后，社交网络服务器可以为用户生成更新后的数据记录，例如4120，并且向社交支付服务器提供登记通知，例如4121。例如，社交网络服务器可以提供类似于以下示例的HTTP(S)POST消息：

在从社交网络服务器接收到登记通知后，社交支付服务器可以生成，例如4122，用户登记数据记录，并且在社交支付数据库中存储该登记数据，例如4123，以便完成登记。在有些实现方式中，登记数据记录可以包括来自登记通知4121的信息。

图42示出了说明在UEP的有些实施例中社交支付登记的示例方面的逻辑流图，例如，社交支付登记(“SPE”)组件4200。在有些实施例中，用户可能期望登记到UEP中。用户可以把用户输入，例如社交支付登记输入4201，提供给客户端，该输入指示用户期望登记到社交网络认证的购买支付。在有些实现方式中，利用用户的输入，客户端可以生成社交支付登记请求，例如4202，并且把该登记请求提供给社交支付服务器。在有些实施例中，社交支付服务器可以从客户端获得登记请求，并且从该登记请求提取用户的付款详情(例如，XML数据)。例如，社交支付服务器可以利用例如在以下参考图61的讨论中所描述的示例解析器的解析器。在有些实现方式中，社交支付服务器可以查询，例如4203，社交支付数据库，以便获得处理登记请求的社交网络请求模板。社交网络请求模板可以包括用于方便社交网络认证的指令、数据、登录URL、登录API调用模板等。在有些实现方式中，社交支付服务器可以把客户端重定向到社交网络服务器。在有些实现方式中，作为用户认证／社交支付应用登记请求，例如4205，的一部分，社交支付服务器可以把从社交支付登记请求提取出的信息提供给社交网络服务器。在有些实现方式中，社交网络服务器可以向客户端提供社交网络登录请求，例如4206。例如，社交网络服务器可以向客户端提供HTML输入表单。客户端可以为用户显示，例如4207，该登录表单。在有些实现方式中，用户可以把登录输入提供给客户端，例如4208，而且客户端可以为社交网络服务器生成社交网络登录响应，例如4209。在有些实现方式中，社交网络服务器可以认证用户的登录凭证，并且在这么做以后，更新用户的简档，指示用户登记到社交支付系统中。例如，在像

的社交联网服务中，社交网络服务器可以向社交支付第三方开发商应用提供访问存储在社交网络中的用户信息的许可。在有些实施例中，这种登记可以允许安装在用户设备上的虚拟钱包应用访问存储在社交网络中的用户的社交简档信息。在认证之后，社交网络服务器可以为用户生成更新后的数据记录，例如4210-4211，并且向社交支付服务器提供登记通知，例如4212。在从社交网络服务器接收到登记通知后，社交支付服务器可以生成，例如4213，用户登记数据记录，并且在社交支付数据库，例如314，中存储登记数据记录，以便完成登记。在有些实现方式中，登记数据记录可以包括来自登记通知的信息。

图43A-C示出了说明在UEP的有些实施例中的示例社交付款触发过程的数据流图。参考图43A，在有些实施例中，用户，例如4301a，可能期望从另一方(例如，用户，参与的商家等)提供或请求资金。用户可以经客户端(客户端14302a)与社交网络服务器，例如4303a，通信，其中客户端例如但不限于：个人电脑、移动设备、电视机、销售点终端、信息站、ATM等。例如，用户可以把社交支付输入4311提供给客户端，该输入指示用户期望从另一方提供或请求资金。在各种实施例中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。作为响应，客户端可以向社交网络服务器提供社交消息发帖请求4312。在有些实现方式中，在客户端上执行的虚拟钱包应用可以为用户提供容易使用的界面，来生成和发送社交消息发帖请求。在备选实现方式中，用户可以利用其它应用来提供社交消息发帖请求。例如，客户端可以向社交网络服务器提供作为包括XML格式化数据的HTTP(S)POST消息的社交消息发帖请求。下面提供基本上以包括XML格式化数据的HTTP(S)POST消息的形式，社交消息发帖请求4321的示例列表：

在有些实施例中，社交网络服务器4304a可以查询其自己的社交网络数据库中用户的社交图，例如4313。例如，社交网络服务器可以发布PHP／SQL命令，查询数据库表(例如图61，社交图6119p)中与用户关联的社交图数据。基本上以PHP／SQL命令的形式，下面提供示例用户社交图查询4313：

在有些实施例中，作为响应，社交网络数据库可以提供所请求的社交图数据，例如4314。利用该社交图数据，社交网络服务器可以为用户和／或用户社交图的成员适当地生成消息，例如4315，并且存储用于用户和／或用户社交图的成员的消息4316。

参考图43B，在有些实施例中，社交消息的这种发布可以触发UEP动作。例如，社交支付服务器4303a可以被触发扫描社交数据来查找支付命令。在其中每个社交发帖消息都源自用户的虚拟钱包应用的实施例中，UEP可以可选地从虚拟钱包应用获得支付命令，并且跳过扫描社交网络来寻找与用户关联的支付命令。在其中允许用户从任何设备(甚至是那些没有链接到用户虚拟钱包的设备)发布支付命令的实施例中，UEP可以周期性地或者甚至持续地扫描社交网络来查找支付命令，例如4321。在其中UEP扫描社交网络的实施例中，社交支付服务器可以查询社交支付数据库中用户的简档。例如，社交支付服务器可以请求用户在登记阶段提供给社交支付服务器的、用于社交网络的用户ID与口令(见例如图41-42)。例如，社交支付服务器可以发布PHP／SQL命令，从数据库表(例如图61，用户6119a)查询用户简档数据。基本上以PHP／SQL命令的形式，下面提供一个示例用户简档数据查询4322：

作为响应，社交支付数据库可以提供所请求的信息，例如4323。在有些实施例中，社交支付服务器可以向社交网络服务器提供用户社交数据请求4324。基本上以PHP命令的形式，下面提供发布用户社交数据请求4324的一个示例命令列表：

在有些实施例中，社交网络服务器可以查询，例如4326，其社交网络数据库4304b中属于请求范围内的社交数据结果。响应该查询，数据库可以提供社交数据，例如4327。社交网络服务器可以把从数据库获得的社交数据，例如4328，返回到社交支付服务器。基本上以JavaScript对象标注(JSON)格式化数据的形式，下面提供用户社交数据4328的一个示例列表：

在有些实施例中，社交支付服务器可以查询社交支付数据库中的社交支付规则，例如4329。例如，社交支付服务器可以发布PHP／SQL命令，从数据库表(例如图61，社交支付规则6119q)查询社交支付规则4330。基本上以PHP／SQL命令的形式，下面提供一个示例支付规则查询4329：

在有些实施例中，社交支付服务器可以利用社交支付规则来处理用户社交数据，以便识别用户社交数据的支付命令、支付请求、商家提议项等内容。在有些实施例中，规则可以由UEP提供，以便确保用户的社交数据与虚拟钱包的隐私性与安全性。作为另一个示例，规则可以包括检测欺诈交易企图的过程，并且在继续前进之前请求用户检验，或者完全取消交易请求。在有些实施例中，社交支付服务器可以利用钱包安全性与设置组件，例如在以下参考45A-B的讨论中进一步描述的示例WSS4500。

参考图43C，在有些实施例中，基于规则的处理，社交支付服务器可以可选地确定需要用户检验来处理支付命令中所指示的交易。例如，如果规则处理指示存在支付命令是欺诈交易企图的可能性，则社交支付服务器可以确定在交易被处理之前必须联系用户进行付款检验。在这种场景下，社交支付服务器可以向客户端提供支付命令检验请求4333，客户端可以向用户显示，例如4334，该请求。例如，社交支付服务器可以向客户端4302a提供支付命令检验请求，作为包括XML格式化数据的HTTP(S)POST消息。基本上以包括XML格式化数据的HTTP(S)POST消息的形式，下面提供支付命令检验请求4333的一个示例列表：

在有些实施例中，用户可以把检验输入4335提供给客户端，客户端可以向社交支付服务器提供支付命令检验响应。社交支付服务器可以确定付款人是否检验过付款、可用的收款人信息是否足以处理交易，等等。在没有足够的收款人信息可用的场景下，社交支付服务器可以可选地向与潜在收款人关联的社交联网服务提供社交发帖消息4338，请求收款人登记到社交支付服务中(例如，利用以上在参考图41-42的讨论中所描述过的SPE4200组件)，社交网络服务器可以为收款人张贴4339该消息。如果用于处理交易的所有需求都满足了，则社交支付服务器可以生成与触发社交发帖消息关联的唯一交易触发，例如4337，并且存储交易触发ID、触发社交发帖消息，等等，用于记录保存或分析目的，例如4340。例如，经像在以下参考图58的讨论中描述的示例PTA组件的购买交易授权，社交支付服务器可以提供触发购买交易4341的交易触发。

图44A-C示出了说明在UEP的有些实施例中社交付款触发的示例方面的逻辑流图，例如，社交付款触发(“SPT”)组件4400。参考图44A，在有些实施例中，用户可能期望从另一方(例如，用户、参与的商家等)提供或请求资金。用户可以经客户端与社交网络服务器通信。例如，用户可以把社交付款输入4401提供给客户端，指示用户期望从另一方提供或请求资金。作为响应，客户端可以生成并向社交网络服务器提供社交消息发帖请求4402。在有些实现方式中，在客户端上执行的虚拟钱包应用可以为用户提供容易使用的界面，来生成并发送社交消息发帖请求。在备选实现方式中，用户可以利用其它应用来提供社交消息发帖请求。在有些实施例中，社交网络服务器可以从其社交网络数据库查询用户的社交图，例如4403。作为响应，社交网络数据库可以提供所请求的社交图数据，例如4404。利用社交图数据，社交网络服务器可以为用户和／或用户社交图的成员适当地生成消息，例如4405，并且存储用于用户和／或社交图成员的消息4406。

参考图44B，在有些实施例中，社交消息的这种张贴可以触发UEP动作。例如，社交支付服务器可以被触发扫描社交数据来查找支付命令，例如4407。在每个社交发帖消息都源自用户的虚拟钱包应用的实施例中，UEP可以可选地从虚拟钱包应用获得支付命令，并且跳过扫描社交网络来寻找与用户关联的支付命令。在允许用户从任何设备(甚至是那些没有链接到用户虚拟钱包的设备)发布支付命令的实施例中，UEP可以周期性地或者甚至持续地扫描社交网络来查找支付命令。在UEP扫描社交网络的实施例中，社交支付服务器可以从社交支付数据库查询用户的简档，4408。例如，社交支付服务器可以请求用户在登记阶段提供给社交支付服务器的、用于社交网络的用户ID与口令(见例如图41-42)。作为响应，社交支付数据库可以提供所请求的信息，例如4409。在有些实施例中，社交支付服务器可以生成并向社交网络服务器提供用户社交数据请求4410。

在有些实施例中，社交网络服务器可以从用户社交数据请求提取用户ID，例如4411。社交网络服务器可以查询，例如4412，其自己的社交网络数据库，确定用户是否通过社交网络登记到UEP中(例如，“用户允许UEP 

应用访问用户数据吗?”)。作为响应，社交网络数据库可以为用户提供关于UEP的用户登记数据。社交网络服务器可以确定用户是否登记，并且因此社交支付服务器是否被授权访问用户社交数据，4414。如果社交网络服务器确定社交支付服务器没有被授权，4415，选项“否”，则它可以生成服务拒绝消息，4416，并且把该消息提供给社交支付服务器。如果社交网络服务器确定社交支付服务器被授权访问用户社交数据，4415，选项“是”，则社交网络服务器可以生成用户社交数据查询4417，并且把它提供给社交网络数据库。作为响应，社交网络数据库可以提供所请求的用户社交数据，4418。社交网络服务器可以向社交支付服务器提供用户社交数据4419。

在有些实施例中，社交支付服务器可以从社交支付数据库查询社交支付规则，例如4420-4421。在有些实施例中，社交支付服务器可以利用社交支付规则处理用户社交数据，来识别用户社交数据的支付命令、支付请求、商家提议项等内容，4422。在有些实施例中，规则可以由UEP提供，以确保用户社交数据与虚拟钱包的隐私性与安全性。作为另一个示例，规则可以包括检测欺诈交易企图的过程，并且在继续进行之前请求用户检验，或者完全取消交易请求。在有些实施例中，社交支付服务器可以利用钱包安全性与设置组件，例如以下在参考图45A-B的讨论中进一步描述的示例WSS4500组件。

参考图44C，在有些实施例中，基于规则的处理，社交支付服务器可以可选地确定需要用户检验来处理支付命令中所指示的交易，4423，选项“是”。例如，如果规则处理指示存在支付命令是欺诈交易企图的可能性，则社交支付服务器可以确定在交易被处理之前必须联系用户进行付款检验。在这种场景下，社交支付服务器可以向客户端提供支付命令检验请求4425，客户端可以向用户显示，例如4426，该请求。在有些实施例中，用户可以把检验输入4427提供给客户端，客户端可以向社交支付服务器提供支付命令检验响应，4428。社交支付服务器可以确定付款人是否检验了付款、可用的收款人信息是否足以处理交易，等等，4429。在没有足够的收款人信息可用或者需要联系付款人进行付款检验的场景下，4430，选项“否”，社交支付服务器可以可选地向与潜在收款人／付款人关联的社交联网服务提供社交发帖消息4431，请求收款人登记到社交支付服务中(例如，利用以上在参考图41-42的讨论中所描述过的SPE4200组件)或者提供检验，社交网络服务器可以为收款人张贴4432-4433该消息。如果用于处理交易的所有需求都满足了，4430，选项“是”，则社交支付服务器可以生成与触发社交发帖消息关联的唯一交易触发，例如4434，并且可以可选地存储交易触发ID、触发社交发帖消息等，用于记录保存或分析目的。例如，经购买交易授权组件，社交支付服务器可以提供触发购买交易的交易触发。

图45A-B示出了说明在UEP的有些实施例中实现钱包安全性与设置的示例方面的逻辑流图，例如，某物(Something，“WSS”)组件4500。在有些实施例中，社交支付服务器可以利用社交支付规则来处理用户社交数据，识别用户社交数据的支付命令、支付请求、商家提议项等内容。在有些实施例中，规则可以由UEP提供，以确保用户的社交数据与虚拟钱包的隐私性与安全性。作为另一个示例，规则可以包括检测欺诈交易企图的过程，并且在继续进行之前请求用户检验，或者完全取消交易请求。

相应地，参考图45A，在有些实施例中，UEP可以获得处理用户社交数据的触发(例如，来自图44B，元素4431)，4501。 UEP可以获得用户和／或用户社交图成员的社交数据，及支付命令规则与模板(例如，用于识别标准支付命令)，4502。UEP可以解析所获得的用户社交数据，准备进行规则处理，4503。例如，UEP可以利用例如在以下参考图61的讨论中所描述的示例解析器的解析器。UEP可以选择一个支付命令规则／模板进行处理。UEP可以把解析过的用户社交数据仔细地搜索一遍，例如，以顺序方式，来查找选定的支付命令，4512，并且确定该支付命令是否存在于用户社交数据中，4513。如果支付命令被识别出来，4514，选项“是”，则UEP可以在队列中放置识别出的支付命令串、规则／模板的标识、规则／模板的实际列表等，供进一步处理，4515。UEP可以执行这种过程，直到用户的社交数据全部都被搜索过一遍(见4516)。在有些实施例中，UEP可以对所有可用的规则／模板执行以上过程，来识别用户社交数据中所包括的所有支付命令串(见4517)。

在有些实施例中，UEP可以处理从用户社交数据中识别出来的每个支付命令，4520。例如，UEP可以从队列中选择一个支付命令串及其关联的模板／标识规则，4521。利用规则／模板和支付命令串，UEP可以确定该串是代表支付请求还是要支付的订单，4523。如果支付命令串代表付款请求(例如，“嗨jfdoe，你欠我25元#cashflowblues”)，4524，选项“是”，则UEP可以确定为其执行WSS组件的用户是否是被请求的付款人，或者收款人，4525。如果用户被请求支付，4526，选项“是”，则UEP可以向用户钱包账户添加付款提醒，4527。否则，UEP可以生成包括支付命令详情的用户支付请求记录，4528，并且在用户的钱包账户中存储该支付请求记录，用于记录保存目的或者将来的分析处理，4529。

参考图45B，在有些实施例中，UEP可以提取交易中付款人和收款人的标识，4531。UEP可以从数据库查询收款人账户数据，用于付款处理，4532。如果可用的收款人数据不足，4533，选项“是”，则UEP可以向收款人的社交网络账户生成社交发帖消息，4534，请求收款人或者登记到UEP中(如果还没有的话)，或者提供附加的信息，使得UEP可以处理交易。UEP可以向与收款人关联的社交联网服务提供4535社交发帖消息。如果有足够的收款人信息可用，4533，选项“No”，则UEP可以从付款人的钱包账户查询与利用虚拟钱包账户关联的安全性规则，4536。UEP可以选择一个钱包安全性规则，4537，并且利用支付命令串作为输入数据处理该安全性规则，4538。基于这种处理，UEP可以确定支付命令是否通过了安全性规则，或者代替地对用户钱包造成安全性风险。如果没有通过安全性规则，4540，选项“否”，则UEP可以确定来自用户的检验是否可以抢救(salvage)支付命令串，4541。如果UEP确定风险太大，则UEP可以直接终止交易并且从处理队列除去该支付命令串。否则(4541，选项“是”)，UEP可以为用户生成支付命令检验请求，4542，并且把该支付命令检验请求作为组件的输出提供，4543。如果所有安全性规则对于该支付命令串都通过了，4544，选项“否”，则UEP可以生成具有触发ID的交易触发(例如卡授权请求)，并且提供该交易触发用于付款处理。

图46示出了说明在UEP的有些实施例中的示例社交商家消费者桥接过程的数据流图。在有些实现方式中，社交支付服务器4613a可以被触发，例如4621，以便提供经社交网络桥接消费者与商家的服务。例如，社交支付服务可以识别需要产品或服务提议项的消费者，而且可以识别参与到UEP中的、可以提供所需产品或服务的商家。社交支付服务器可以代表参与的商家生成提议项，并且经社交网络把提议项提供给消费者。在有些实施例中，社交支付服务器可以周期性地为用户启动商家-消费者桥接服务。在备选实施例中，社交支付服务器可以在得到消费者参与交易的通知后(例如，消费者可以请求经用户的虚拟钱包对购买进行结帐；为了说明，见以下在参考图56的讨论中进一步描述的示例用户购买结帐(UPC)组件5600)或者当请求用于购买交易的授权时(见以下在参考图58的讨论中进一步描述的示例购买交易授权(PTA)组件5800)启动商家-消费者桥接。在获得执行商家-消费者桥接的触发之后，社交支付服务器可以启用4622交易数据聚合组件，例如在以上参考图26的讨论中进一步描述的TDA组件2600。社交支付服务器可以从社交支付数据库4603b查询提议项生成规则，例如4623。例如，社交支付服务器可以利用类似于本文描述的其它示例的PHP／SQL命令。作为响应，数据库可以提供所请求的提议项生成规则，例如4624。利用聚合的交易数据与提议项生成规则，社交支付服务器可以生成商家提议项社交发帖消息，张贴到社交网络上用户的简档，例如4625。例如，社交支付服务器可以启用基于交易的提议项生成组件，例如在以上参考图39的讨论中进一步描述的示例UBOR3900组件。社交支付服务器可以把生成的社交发帖消息4626提供给社交网络服务器4614a。社交网络服务器可以把社交发帖消息4627存储到社交网络数据库4614b，用于分发到用户(例如，当用户登录到由该社交网络服务器提供的社交联网服务时)。

图47示出了说明在UEP的有些实施例中社交商家消费者桥接的示例方面的逻辑流图，例如，社交商家消费者桥接(“SMCB”)组件4700。在有些实现方式中，社交支付服务器可以被触发，提供经社交网络桥接消费者与商家的服务，例如4701。在获得执行商家-消费者桥接的触发后，社交支付服务器可以启用交易数据聚合组件，例如以上在参考图26的讨论中进一步描述的TDA组件2600，例如4702。社交支付服务器可以从社交支付数据库查询提议项生成规则，例如4703。例如，社交支付服务器可以利用类似于本文所述的其它示例的PHP／SQL命令。作为响应，数据库可以提供所请求的提议项生成规则，例如4704。利用聚合的交易数据与提议项生成规则，社交支付服务器可以生成商家提议项社交发帖消息，用于张贴到社交网络上用户的简档，例如4705。例如，社交支付服务器可以启用基于交易的提议项生成组件，例如在以上参考图39的讨论中进一步描述的示例UBOR3900组件。社交支付服务器可以把生成的社交发帖消息提供给社交网络服务器。社交网络服务器可以把该社交发帖消息存储到社交网络数据库，用于分发到用户(例如，当用户登录到由该社交网络服务器提供的社交联网服务时)。在有些实施例中，社交网络服务器可以利用用户的社交图数据为用户和／或用户社交图的成员生成社交发帖消息，例如4706，并且把该社交发帖消息存储在社交网络数据库中，用于张贴到他们的简档，例如4707。

虚拟钱包UI实施例

图48示出了说明在UEP的有些实施例中虚拟钱包应用的示例特征概观的用户界面图。图48示出了虚拟钱包移动应用4800的各种示例性特征的说明。所显示的一些特征包括钱包4801、经TWITTER、FACEBOOK等的社交集成、提议项与忠诚(loyalty)4803、快照移动购买4804、报警4805及安全性、设置与分析4896。以下更具体地探讨这些特征。

图49A-G示出了说明在UEP的有些实施例中处于购物模式的虚拟钱包应用的示例特征的用户界面图。参考图49A，虚拟钱包移动应用的一些实施例方便并大大增强了消费者的购物体验。如图49A中所示，多种购物模式可以让消费者查阅(peruse)。在一种实现方式中，例如，用户可以通过选择位于用户界面底部的购物图标4910来启动购物模式。用户可以在搜索字段4912中输入一个物品来搜索和／或把物品添加到购物车4911。用户还可以通过对麦克风4913说出要搜索的和／或要添加到购物车的物品的名称或描述来使用语音激活的购物模式。在进一步的实现方式中，用户还可以选择其它购物选项4914，例如当前物品4915、账单4916、地址本4917、商家4918和本地附近4919。

在一种实施例中，例如，用户可以选择选项当前物品4915，如在图49A最左边的用户界面中所示出的。当选择了当前物品4915选项时，可以显示中间的用户界面。如所示出的，中间的用户界面可以提供用户购物车4911中的当前物品列表4915a-h。用户可以选择一个物品，例如物品4915a，查看选定物品的产品描述4915j和／或来自同一商家的其它物品。价格与总的应付信息也可以连同捕捉达成快照移动购买交易所必需的信息的QR码4915k一起显示。

参考图49B，在另一种实施例中，用户可以选择账单4916选项。在选择账单4916选项后，用户界面可以显示来自一个或多个商家的账单和／或收据列表4916a-h。紧跟在每个账单后面，可以显示例如访问日期、是否给出来自多个商店的物品、上次账单付款日期、自动付款、物品数量等附加信息。在一个示例中，可以选择日期为2011年1月20目的钱包商店账单4916a。钱包商店账单选择可以显示提供关于选定账单的多种信息的用户界面。例如，该用户界面可以显示所购买的物品4916k的列表，<<4916i>>、物品总数与对应的价值。例如，价值$102.54的7个物品在选定的钱包商店账单中。现在，用户可以选择任何物品并且再次选择添加购买物品。用户还可以刷新提议项4916j，清除来自上一次的任何无效提议项和／或选择可以适用于当前购买的新提议项。如在图49B中所示出的，用户可以选择两个物品来重复购买。在添加之后，消息4961I可以显示，确认这两个物品的添加，这使得购物车中物品的总数为14。

参考图49C，在还有另一种实施例中，用户可以选择地址本选项4917来查看包括联系人列表4917b的地址本4917a并且进行任何转账或付款。在一种实施例中，地址本可以利用他们的名字和可用和／或优选的付款模式识别每个联系人。例如，可以经如由图标4917c指示的社交支付(例如，经FACEBOOK)向联系人Amanda G.支付。在另一个示例中，钱可以经如由QR码图标4917d指示的QR码转到Brian S.。在还有另一个示例中，Charles B.可以经近场通信4917e、蓝牙4917f和电子邮件4917g接受付款。付款还可以经USB4017h(例如，通过物理连接两个移动设备)及例如TWITTER的其它社交通信进行。

在一种实现方式中，用户可以选择Joe P.来付款，如在用户界面中示出的，Joe P.在其名字后面紧跟着电子邮件图标4917g，指示JoeP.经电子邮件接受付款。当他的名字被选择时，用户界面可以显示他的联系信息，例如电子邮件、电话等。如果用户期望通过除电子邮件之外的其它方法付款给Joe P.，则用户可以把另一种转账模式4917j添加到他的联系信息并且进行付款转账。参考图49D，可以为用户提供屏幕4917k，其中用户可以输入要送给Joe的金额，及为Joe提供关于付款交易4917l的背景的其它文本。用户可以选择可以经图形用户界面元素，4917m，联系到Joe的的模式(例如，SMS、电子邮件、社交联网)。当用户输入时，所输入的文本可以提供，用于在GUI元素4917n中被审阅。当用户完成输入必要的信息时，用户可以按发送按钮4917o把社交消息发送到Joe。如果Joe也具有虚拟钱包应用，则Joe可能能够在应用内或者直接在社交网络的网站(例如，对于Twitter^TM、

等)审阅4917p社交支付消息。消息可以从各个社交网络和其它来源(例如，SMS、电子邮件)聚合。适合每种发消息模式的兑换方法可以连同社交支付消息一起指示。在图49D的说明中，通过答复该SMS并输入哈希标志值“#1234”，Joe接收到的SMS4917q指示Joe可以兑换经SMS获得的$5。在同一个说明中，Joe还经

接收到消息4917r，该消息包括Joe可以激活启动$25付款的兑换的URL链接。

参考图49E，在有些其它实施例中，用户可以从购物模式中的选项列表选择商家4918，来查看商家的选择列表4918a-e。在一种实现方式中，列表中的商家可以被接纳到钱包中，或者与钱包具有密切关系。在另一种实现方式中，商家可以包括满足用户定义的或者其它标准的商家列表。例如，该列表可以是用户策划的列表，用户最常购物或者花费超过x总量或购物连续三个月等的商家。在一种实现方式中，例如，用户进一步选择其中一个商家，Amazon4918a。然后，用户可以导航通过商家列表，找出感兴趣的物品，例如4918f-j。直接通过钱包而不用从独立的页面访问商家站点，用户可以从Amazon4918a的目录选择物品4918j。如在图49D最右边的用户界面中所示出的，选定的物品可以加到购物车中。消息4918k指示选定的物品已经添加到购物车，而且现在更新后的购物车的物品数量是13。

参考图49F，在一种实施例中，可以有本地附近选项4919，这个选项可以被用户选择，来查看地理上在用户附近的商家列表。例如，商家列表4919a-e可以是位于用户附近的商家。在一种实现方式中，移动应用可以进一步基于用户的位置识别用户何时在商店中。例如，当用户在商店(例如，Walgreens)附近时，位置图标4919d可以紧跟在该商店后面显示。在一种实现方式中，如果用户离开商店(例如，Walgreens)，则移动应用可以周期性地刷新其位置。在进一步的实现方式中，用户可以通过移动应用导航选定的Walgreens商店的出售物。例如，利用移动应用，用户可以导航到在Walgreens的过道5可以获得的物品4919f-j。在一种实现方式中，用户可以从他或她的移动应用选择玉米4919i，添加到购物车4919k。

参考图49G，在另一种实施例中，除其它的之外，本地附近选项4919可以包括商店地图和实时地图特征。例如，在选择Walgreens商店后，用户可以启动显示地图4919m的过道地图4919l，地图4919m示出了商店的组织与用户的位置(用黄色的圆圈来指示)。在一种实现方式中，用户可以容易地配置地图，添加一个或多个其他用户(例如，用户的孩子)，来共享彼此在商店中的位置。在另一种实现方式中，用户可以具有启动类似于地图中街景的“商店视图”的选项。商店视图4919n可以显示用户周围的图像／视频。例如，如果用户打算进入过道5，则商店视图地图可以显示过道5的视图。另外，用户可以利用导航工具4919o操纵地图的朝向，向前、向后、向左、向右及顺时针和逆时针移动商店视图。

图50A-F示出了说明在UEP的有些实施例中处于付款模式的虚拟钱包应用的示例特征的用户界面图。参考图50A，在一种实施例中，钱包移动应用可以为用户提供经钱包模式5010支付交易的多个选项。在一种实现方式中，示出了用于进行付款的示例用户界面5011。该用户界面可以清楚地识别交易的金额5012与货币5013。金额可以是应付的金额，而货币可以包括例如美元与欧元的实际货币及例如奖励积分的虚拟货币。交易金额5014还可以显著地显示在用户界面上。用户可以选择资金选项卡5016来选择一种或多种付款形式5017，这可以包括各种信用、借记、礼品、奖励和／或预付卡。用户还可以具有完全或部分地用奖励积分支付的选项。例如，用户界面上的图形指示器5018示出了可用的积分数，而图形指示器5019示出了朝付款金额234.56要使用的积分数及选定货币(例如，USD)中该积分数的等价值5020。

在一种实现方式中，用户可以结合来自多个来源的资金来支付交易。用户界面上所显示的金额5015可以提供到目前为止由选定的付款形式(例如，发现卡(discover card)与奖励积分)所覆盖的总资金金额的指示。用户可以选择另一种付款形式或者调整要从一种或多种付款形式借记的金额，直到金额5015匹配应付的金额5014。一旦用户最后定下从一种或多种付款形式借记的金额，就可以开始付款授权。

在一种实现方式中，用户可以通过选择“cloak”按钮5022有效地伪装或匿名一些(例如，预先配置的)或全部识别信息来选择交易的安全授权，使得，当用户选择支付按钮5021时，以安全和匿名的方式进行交易授权。在另一种实现方式中，用户可以选择支付按钮5021，这可以使用标准的授权技术进行交易处理。在还有另一种实现方式中，当用户选择社交按钮5023时，关于交易的消息可以传送到(用户设置的)一个或多个社交网络，这些网络可以在例如留言板(wall post)或tweet的社交论坛中张贴或通告该购买交易。在一种实现方式中，用户可以选择社付款款处理选项5023。指示器5024可以显示进行中的授权与发送社交共享数据。

在另一种实现方式中，受限付款模式5025可以对某些购买活动激活，例如指定购买。该模式可以根据由发行者、保险公司、商家、付款处理器和／或其它实体定义的规则来激活，以方便专用商品与服务的处理。在这种模式中，用户可以向下滚资金选项卡下面的付款形式列表5026，来选择例如弹性支出账户(FSA)5027、健康储蓄账户(HAS)等专用账户和要借记到选定账户的金额。在一种实现方式中，这种受限付款模式5025处理可以禁止购买信息的社交共享。

在一种实现方式中，钱包移动应用可以方便资金经导入资金用户界面5028的导入。例如，失业的用户可以经钱包移动应用获得失业金5029。在一种实现方式中，提供资金的实体还可以配置使用资金的规则，如由处理指示器消息5030所示出的。钱包可以事先读取并应用规则，而且可以拒绝用失业金进行未能满足规则所设定标准的任何购买。示例标准可以包括例如商家类别代码(MCC)、交易时间、交易地点等。作为一个示例，与具有MCC5411的杂货店商家的交易可以被批准，而与具有MCC5813的酒吧商家的交易可以被拒绝。

参考图50B，在一种实施例中，钱包移动应用可以基于，除其它因素之外，例如用户位置、偏好与货币价值偏好的因素方便动态付款优化。例如，当用户在美国时，国家指示器5031可以显示美国的标志而且可以选择针对美国的货币5033。在进一步的实现方式中，钱包移动应用可以自动重新安排列出付款形式的次序，以便反映各种付款形式的流行性或者可接受性。在一种实现方式中，这种安排可以反映用户的偏好，其中用户偏好是不能由钱包移动应用来改变的。

类似地，当德国用户在德国操作钱包时，移动钱包应用用户界面可以动态地更新成反映操作的国家5032和货币5034。在进一步的实现方式中，钱包应用可以基于它们在那个国家的接受程度重新安排列出不同付款形式5036的次序。当然，这些付款形式的次序可以被用户修改，以便适合他或她自己的偏好。

参考图50C，在一种实施例中，钱包移动应用用户界面中的收款人选项卡5037可以方便用户选择一个或多个接收在资金选项卡中选择的资金的收款人。在一种实现方式中，该用户界面可以显示用户以前与其交易过或者可用于进行交易的全部收款人的列表5038。然后，用户可以选择一个或多个收款人。收款人5038可以包括例如Amazon.com公司的较大的商家和例如Jane P.Doe的个人。紧跟在每个收款人名字后面，可以显示该收款人可接受的付款模式列表。在一种实现方式中，用户可以选择收款人Jane P.Doe5039接收付款。在选择之后，用户界面可以显示关于该收款人的附加识别信息。

参考图50D，在一种实施例中，模式选项卡5040可以方便选择收款人接受的付款模式。有多种付款模式可用于选择。除其它的之外，示例模式包括蓝牙5041、无线5042、通过用户获得的QR码的快照移动5043、安全芯片5044、TWITTER5045、近场通信(NFC)5046、蜂窝5047、通过用户提供的QR码的快照移动5048、USB5049和FACEBOOK5050。在一种实现方式中，只有收款人接受的付款模式可以被用户选择。其它不被接受的付款模式可以被禁用。

参考图50E，在一种实施例中，提议项选项卡5051可以提供与用户购物车中物品相关的实时提议项，供用户选择。用户可以从可以接受的提议项列表5052中选择一个或多个提议项来兑换。在一种实现方式中，有些提议项可以组合，而其它的可能不能。当用户选择了可能不能与别的提议项组合的提议项时，未选择的提议项可以被禁用。在进一步的实现方式中，钱包应用的推荐引擎推荐的提议项可以被指示器识别，例如由5053示出的推荐。在进一步的实现方式中，通过展开如用户界面中由5054所示的提议项行，用户可以读取提议项的细节。

参考图50F，在一种实施例中，社交选项卡5055可以方便钱包应用与社交通道5056的集成。在一种实现方式中，用户可以选择一个或多个社交通道5056并且，通过向钱包应用提供该社交通道的用户名与口令5057并登录5058，可以从钱包应用登录到选定的社交通道。然后，用户可以使用社交按钮5059通过集成的社交通道发送或接收钱。在进一步的实现方式中，用户可以通过集成的社交通道发送社交共享数据，例如购买信息或者链接。在另一种实施例中，用户提供的登录凭证可以允许UEP参与截取解析。

图51示出了说明在UEP的有些实施例中处于历史模式的虚拟钱包应用的示例特征的用户界面图。在一种实施例中，用户可以选择历史模式5110来查看先前购买的历史并且对那些先前的购买执行各种动作。例如，用户可以在搜索条5111中输入商家识别信息，例如名字、产品、MCC等。在另一种实现方式中，用户可以通过点击麦克风图标5114使用语音激活的搜索特征。钱包应用可以从移动设备或别的地方(例如，远离移动设备的一个或多个数据库和／或表)中的存储区域查询与搜索关键字匹配的交易。然后，用户界面可以显示查询的结果，例如交易5115。用户界面还可以识别交易的日期5112、与交易相关的商家与物品5113、确认进行了交易的收据的条形码、交易的金额及任何其它相关信息。

在一种实现方式中，用户可以选择一个交易，例如交易5115，来查看该交易的细节。例如，用户可以查看与该交易关联的物品的详情及每种物品的金额，5116。在进一步的实现方式中，用户可以选择显示选项5117来查看用户关于交易或交易中的物品可采取的动作5118。例如，用户可以把照片添加到交易(例如，用户和用户购买的iPad的图片)。在进一步的实现方式中，如果用户先前经社交通道共享了该购买，则包括照片的帖子可以生成并发送到社交通道，以便公布。在一种实现方式中，任何共享都是可选的，而且不经社交通道共享购买的用户仍然可以直接从钱包应用的历史模式通过他或她选择的一个或多个社交通道共享照片。在另一种实现方式中，用户可以把交易添加到一个组，例如公司开支、家庭开支、旅行开支或者用户设置的其它分类。这种分组可以方便年终的开支记账、工作开支报告的提交、增值税(VAT)退款的提交、个人开支等。在还有另一种实现方式中，用户可以买在该交易中购买过的一种或多种物品。于是，用户不用去商家的目录或站点找这些物品就可以执行交易。在进一步的实现方式中，用户还可以在购物车中存放该交易中的一种或多种物品，以便以后购买。

在另一种实施例中，历史模式可以提供获得并显示交易中物品分级5119的设施。分级的来源可以是用户、用户的朋友(例如，来自社交通道、联系人，等等)、从网络聚合的评论等。有些实现方式中的用户界面还可以允许用户向社交通道(例如，TWITTER或FACEBOOK)的其他用户发消息。例如，显示区域5120示出了在两个用户之间交换的FACEBOOK消息。在一种实现方式中，用户可以经消息5121共享链接。对具有到产品的嵌入式链接的这种消息的选择可以允许用户查看产品的描述和／或直接从历史模式购买该产品。

在一种实施例中，历史模式还可以包括用于导出收据的设施。导出收据弹出框5122可以提供导出历史交易收据的多个选项。例如，用户可以使用选项5125中的一个或多个，这些选项包括保存(到本地移动存储器、到服务器、到云账户等)、打印到打印机、传真、电子邮件等。为了导出，用户可以利用他或她的地址本5123来查找电子邮件或传真号。用户还可以规定用于导出收据的格式选项5124。示例格式选项可以包括但不限于文本文件(.doc、.txt、.rtf、.iif等)、电子数据表(.csv、.xls等)、图像文件(.jpg、.tff、.png等)、便携式文档格式(.pdf)、Postscript(.ps)等。然后，用户可以点击或轻击导出按钮5127，启动收据的导出。

图52A-E示出了说明在UEP的有些实施例中处于快照模式的虚拟钱包应用的示例特征的用户界面图。参考图52A，在一种实施例，用户可以选择快照模式2110来访问其快照特征。快照模式可以管理数据的任何机器可读表示。这种数据的示例可以包括例如UPC码和QR码的线性与2D条形码。这些代码可以在收据、产品包装等上面找到。快照模式还可以处理和管理收据、产品、提议项、信用卡或其它付款设备等的图片。快照模式中的一个示例用户界面在图52A中示出。用户可以使用他或她的移动电话拍摄QR码5215和／或条形码5214的照片。在一种实现方式中，条5213和快照框5215可以帮助用户正确地抓拍代码。例如，如所示出的，快照框5215没有捕捉到代码5216的全部。因此，在这个视图中捕捉到的代码可能是不可分辨的，因为代码中的信息可能不完整。这是由条5213上的消息指示的，该消息指示快照模式仍然在搜寻代码。当代码5216被快照框5215完全框住时，条消息可以更新成例如“快照找到”。在找出代码后，在一种实现方式中，用户可以利用移动设备照相机启动代码捕捉。在另一种实现方式中，快照模式可以利用移动设备照相机自动抓拍代码。

参考图52B，在一种实施例中，快照模式可以方便付款重新分配发帖交易。例如，用户可以从零售商Acme超市买杂货和规定的物品。例如，用户可能无意地或者为了方便结帐而使用他或她的Visa卡既支付了杂货又支付了规定物品，并且获得了收据。但是，用户可能有一个可以用于支付规定物品的FSA账户，而且这个账户将为用户提供税收利益。在这种情况下，用户可以使用快照模式启动交易重新分配。

如所示出的，用户可以在搜索条2121中输入搜索项(例如，账单)。然后，用户可以在选项卡5222中识别用户想重新分配的收据5223。作为替代，用户可以直接抓拍收据上条形码的图片，而且快照模式可以利用来自条形码的信息生成并显示收据5223。现在用户可以重新分配5225。在有些实现方式中，用户还可以阻止(dispute)交易5224或者把收据5226存档。

在一种实现方式中，当选择重新分配按钮5225时，钱包应用可以执行收据的光学字符识别(OCR)。然后，可以检查收据中的每种物品，识别付款设备或账户要为其承担税金或其它利益，例如现金返回、奖励积分等，的一种或多种物品。在这个示例中，如果由用户的Visa卡付费的处方药品要由用户的FSA付费，则存在税收利益。然后，钱包应用可以作为后端执行重新分配。重新分配过程可以包括钱包联系付款处理器，把处方药品的金额归还到Visa卡并且把相同的金额借记到用户的FSA账户。在一种备选实现方式中，付款处理器(例如，Visa或MasterCard)可以获得收据的OCR、识别要重新分配的物品和付款账户并且执行重新分配。在一种实现方式中，钱包应用可以请求用户确认选定物品的费用重新分配到另一个付款账户。收据5227可以在重新分配过程完成之后生成。如所讨论的，收据显示一些费用已经从Visa账户移到FSA。

参考图52C，在一种实施例中，快照模式可以方便经例如条形码或QR码的支付码的付款。例如，用户可以抓拍还没有完成的交易的QR码。QR码可以在商家的POS终端、网站或者web应用显示，而且可以用识别要购买的物品的信息、商家详情及其它相关信息来编码。当用户抓拍例如QR码时，快照模式可以解码QR码中的信息并且可以使用解码后的信息生成收据5232。一旦识别出QR码，导航条5231就可以指示识别出了支付码。用户现在可以具有添加到购物车5233、用缺省付款账户支付5234和用钱包支付5235的选项。

在一种实现方式中，用户可以决定用缺省账户支付5234。然后，钱包应用可以使用用户的缺省付款方法，在这个示例中是钱包，来完成交易。在交易完成之后，收据可以自动生成，用于证明购买。用户界面也可以更新，提供用于管理完成后的交易的其它选项。示例选项包括与其他人共享购买信息的社交5237、如关于图52B讨论过的重新分配5238及存储收据的归档5239。

参考图52D，在一种实施例中，快照模式还可以方便提议项的识别、应用与存储，供将来使用。例如，在一种实现方式中，用户可以抓拍提议项代码5241(例如，条形码、QR码等)。然后，钱包应用可以从在提议项代码中编码的信息生成提议项文本5242。用户可以对提议项代码执行多种动作。例如，用户可以使用“找出”按钮5243来找出接受该提议项代码的所有商家、附近接受该提议项代码的商家、符合该提议项代码要求的商家产品等。用户还可以利用“添加到购物车”按钮5244把提议项代码应用到购物车中当前的物品。此外，用户还可以通过选择“保存”按钮5245保存该提议项，供将来使用。

在一种实现方式中，在应用提议项或优惠券5246后，用户可以具有利用“找出”找出合格商家和／或产品的选项，用户可以利用5248转到钱包，而且用户还可以保存提议项或优惠券5246，供以后使用。

参考图52E，在一种实施例中，快照模式还可以提供向钱包应用添加资金来源的设施。在一种实现方式中，例如信用卡、借记卡、预付卡、智能卡和其它支付账户的支付卡可以具有关联的代码，例如条形码或QR码。这种代码可以在其中编码支付卡的信息，包括但不限于名字、地址、支付卡类型、支付卡详情、余额、消费限额、奖励余额等。在一种实现方式中，代码可以在物理支付卡的正面找到。在另一种实现方式中，代码可以通过访问关联的在线账户或别的安全位置获得。在还有另一种实施例中，代码可以打印在伴随该支付卡的信上。在一种实现方式中，用户可以抓拍代码的图片。钱包应用可以识别支付卡5251并且可以显示在支付卡中编码的文本信息5252。然后，用户可以通过选择检验按钮5253执行对信息5252的检验。在一种实现方式中，检验可以包括联系支付卡的发行者，对解码的信息5252和任何其它相关的信息进行确认。在一种实现方式中，用户可以通过选择“添加到钱包”按钮5254把支付卡添加到钱包。把支付卡添加到钱包的指令可以使该支付卡作为一种付款形式出现在图50A中讨论过的资金选项卡5016下面。通过选择“取消”按钮5255，用户还可以取消支付卡作为资金来源的导入。当支付卡添加到钱包之后，经通知显示5256，用户界面可以更新成指示导入已完成。然后，用户可以访问钱包5257，开始利用添加的支付卡作为资金来源。

图53示出了说明在UEP的有些实施例中处于提议项模式的虚拟钱包应用的示例特征的用户界面图。在有些实现方式中，UEP可以允许用户从虚拟钱包移动应用中搜索产品和／或服务的提议项。例如，用户把文本输入到图形用户界面(“GUI”)元素5311中，或者通过激活GUI元素5321并且把对设备讲出命令来发布语音命令。在有些实现方式中，UEP可以基于用户之前的行为、人口统计、当前位置、当前购物车选择或购买物品等来提供提议项。例如，如果用户在实体商店或者在线购物网站中，并且离开该(虚拟)商店，则与该商店关联的商家可能期望提供优惠买卖(sweetener deal)，诱惑消费者回到该(虚拟)商店。商家可以提供例如提议项5313。例如，该提议项可以提供折扣，而且可以包括过期时间。在有些实现方式中，其他用户可以向该用户提供用户可以兑换的礼物(例如，5314)。在有些实现方式中，提议项区可以包括关于对其他用户付款的报警(例如，5315)。在有些实现方式中，提议项区可以包括关于来自其他用户的请求资金接收的报警(例如，5316)。例如，这种特征可以识别可以从其它应用(例如，邮件、日历、任务、附注、提醒程序、警报等)或者通过由用户手动输入到虚拟钱包应用来接收的资金。在有些实现方式中，提议项区可以提供来自UEP中参与商家的提议项，例如5317-5319、5320。这些提议项有时候可以利用参与商家的组合来组装，例如5317。在有些实现方式中，UEP本身可以由于用户利用虚拟钱包应用中的特定付款模式而附带地为用户提供提议项，例如5320。

图54A-B示出了说明在UEP的有些实施例中处于安全性与隐私模式的虚拟钱包应用的示例特征的用户界面图。参考图54A，在有些实现方式中，例如，通过激活一个用户界面元素，用户可能能够查看和／或修改用户简档和／或用户的设置。例如，用户可能能够查看／修改用户名(例如，5411a-b)、账户号码(例如，5412a-b)、用户安全性访问代码(例如，5413a-b)、用户销(例如，5414a-b)、用户地址(例如，5415a-b)、与用户关联的社会安全号(例如，5416a-b)、当前设备GPS位置(例如，5417a-b)、用户当前所在的商店的商家的用户帐户(例如，5418a-b)、用户的奖励账户(例如，5419a-b)等。在有些实现方式中，用户可能能够选择哪些数据字段及其关联的值应当发送，以方便购买交易，由此为用户提供增强的数据安全性。例如，在图54A所说明的示例中，用户已经选择了名字5411a、账户号码5412a、安全性代码5413a、商家账户ID5418a与奖励账户ID5419a作为要作为通知的一部分发送的字段，以便处理购买交易。在有些实现方式中，用户可以切换作为通知的一部分发送的字段和／或数据值，以便处理购买交易。在有些实现方式中，应用可以提供多屏所存储的数据字段和／或关联的值，让用户选择作为购买订单发送的一部分。在有些实现方式中，应用可以为UEP提供用户的GPS位置。基于用户的GPS位置，UEP可以确定用户的背景(例如，用户是否在商店、医务室、医院、邮局等)。基于这种背景，用户应用可以为用户呈现适当的字段，用户可以从这些字段选择要作为购买订单发送的一部分发送的字段和／或字段值。

例如，用户可以去到医务室并且期望为医生预约支付共付额(co-pay)。除了例如账户号码与名字的基本交易信息，应用还可以为用户提供选择传递药品记录、健康信息的能力，这些信息可以提供给医疗服务提供商、保险公司及交易处理器，来调节各方之间的付款。在有些实现方式中，记录可以按与健康保险便利与责任法案(HIPAA)兼容的数据格式发送并且加密，而且只有被授权查看这种记录的接收方才可以具有适当的解密密钥来解密并查看私有的用户信息。

参考图54B，在有些实现方式中，在用户设备上执行的应用可以提供“VerifyChat”特征，用于防止欺诈。例如，UEP可以检测不寻常和／或可疑的交易。UEP可以利用VerifyChat特征与用户通信，并且检验购买交易的发起人的真实性。在各种实现方式中，UEP可以发送电子邮件消息、文本(SMS)消息、

消息、Twitter^TM tweet、文本聊天、语音聊天、视频聊天(例如，AppleFaceTime)等来与用户通信。例如，UEP可以为用户启动视频质询(video challenge)，例如5421。例如，用户可能需要经视频聊天展现他／她自己，例如5422。在有些实现方式中，消费者服务代表，例如代理人5424，可以利用用户的视频手动确定用户的真实性。在有些实现方式中，UEP可以利用面部、生物识别等识别(例如，利用模式分类技术)来确定用户的身份。在有些实现方式中，应用可以提供参考标记(例如，十字线、目标框等)，例如5423，使得用户可以利用视频来方便UEP的自动用户识别。在有些实现方式中，用户可能没有启动交易，例如，交易是欺诈性的。在这种实现方式中，用户可以取消质询。然后，UEP可以取消交易，和／或代表用户启动欺诈调查过程。

在有些实现方式中，UEP可以利用文本质询过程来检验用户的真实性，例如5425。例如，UEP可以经文本聊天、SMS消息、电子邮件、

消息、Twitter^TM tweet等与用户通信。UEP可以为用户张贴质询问题，例如5426。应用可以提供用户输入接口元素(例如，虚拟键盘5248)，以便回答由UEP张贴的质询问题。在有些实现方式中，质询问题可以由UEP自动地随机选择；在有些实现方式中，消费者服务代表可以手动地与用户通信。在有些实现方式中，用户可能没有启动该交易，例如，交易是欺诈性的。在这种实现方式中，用户可以取消文本质询。UEP可以取消交易，和／或代表用户启动欺诈调查。

UEP交易平台

图55示出了说明在UEP的有些实施例中示例用户购买结帐过程的数据流图。在有些实施例中，用户，例如5501a，可能期望经商家在线站点或者在商家的商店中从商家购买产品、服务、出售物等(“产品”)。用户可以经客户端与商家／让受方(“商家”)的服务器，例如5503a，通信，其中客户端例如但不限于：个人电脑、移动设备、电视机、销售点终端、信息站、ATM等(例如5502)。例如，用户可以把用户输入，例如结帐输入5511，提供到客户端中，该输入指示用户期望购买产品。在各种实施例中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。作为一个示例，处于商家商店中的用户可以经位于销售点终端的条形码扫描仪扫描产品的条形码。作为另一个示例，用户可以在商家的网站上从网页目录中选择一个产品，并且把该产品添加到商家网站上的虚拟购物车。然后，用户可以指示用户期望结帐(虚拟)购物车中的物品。例如，用户可以激活由客户端提供的用户接口元素，指示用户期望完成用户购买结帐。客户端可以生成结帐请求，例如5512，并且把该结帐请求提供，例如5513，给商家服务器。例如，客户端可以提供(安全的)超文本传输协议(HTTP(S))POST消息，该消息包括根据可扩展标记语言(“XML”)格式化的数据形式的、用于商家服务器的产品详情。基本上以包括XML格式化数据的HTTP(S)POST消息的形式，下面提供结帐请求5512的一个示例列表：

在有些实施例中，商家服务器可以从客户端获得结帐请求，并且从该结帐请求提取结帐详情(例如，XML数据)。例如，商家服务器可以利用例如在以下参考图61的讨论中所描述的示例解析器的解析器。基于解析结帐请求5512，商家服务器可以从结帐请求提取产品数据(例如，产品标识符)及可用的PoS客户端数据。在有些实施例中，利用产品数据，商家服务器可以查询，例如5514，商家／让受方(“商家”)数据库，例如5503b，来获得产品数据，例如5515，像产品信息、产品定价、营业税、提议项、折扣、奖励和／或其它信息，来为用户处理购买交易和／或提供增值服务。例如，商家数据库可以是响应结构化查询语言(“SQL”)命令的关系数据库。商家服务器可以执行包括SQL命令的超文本预处理器(“PHP”)脚本，从数据库表(例如图61，产品6119l)查询产品数据。基本上以PHP／SQL命令的形式，下面提供一个示例产品数据查询5514：

在有些实施例中，响应获得了产品数据，商家服务器可以生成，例如5516，结帐数据，提供给PoS客户端。在有些实施例中，这种结帐数据，例如5517，可以部分地嵌入到包括要显示的数据和提供付款信息以便处理购买交易的输入字段的超文本标记语言(“HTML”)页面中，其中要显示的数据例如产品详情、产品定价、总价、税务信息、发货信息、提议项、折扣、奖励、增值服务信息等，而提供付款信息的输入字段例如账户持有人名字、账户号码、开票地址、发货地址、小费金额等。在有些实施例中，结帐数据可以部分地嵌入到PoS客户端可以显示的快速响应(“QR”)代码图像中，使得用户可以利用用户设备捕捉该QR代码，获得用于生成购买交易处理请求的商家和／或产品数据。在有些实施例中，用户报警机制可以内置到结帐数据中。例如，商家服务器可以把特定于交易的URL嵌入到结帐数据中。在有些实施例中，报警URL可以进一步嵌入到卡授权请求中可选的第三级数据中，例如以下参考图57-58进一步讨论的那些。该URL可以指向存储在商家服务器上的、专用于作为卡授权请求主题的交易的网页、数据文件、可执行脚本等。例如，由该URL指向的对象可以包括关于购买交易的详情，例如，所购买的产品、购买成本、到期时间、订单处理状态等。因而，通过把网页的URL传递到付款网络，商家服务器可以为付款网络提供交易的详情。在有些实施例中，付款网络可以向用户提供通知，例如付款收据、交易授权确认消息、发货通知等。在这种消息中，付款网络可以向用户设备提供URL。用户可以在用户设备上导航到该URL，以便获得关于用户购买的报警及例如提议项、优惠券、相关产品、奖励通知等其它信息。基本上以XML格式化数据的形式，下面提供结帐数据5517的一个示例列表：

在获得结帐数据，例如5517之后，PoS客户端可以为用户呈现并显示，例如5518，该结帐数据。

图56示出了说明在UEP的有些实施例中用户购买结帐的示例方面的逻辑流图，例如，用户购买结帐(“UPC”)组件5600。在有些实施例中，用户可能期望经商家在线站点或者在商家的商店中从商家购买产品、服务、出售物等(“产品”)。用户可以经PoS客户端与商家／让受方(“商家”)的服务器通信。例如，用户可以把用户输入，例如5601，提供到客户端中，该输入指示用户期望购买产品。客户端可以生成结帐请求，例如5602，并且把该结帐请求提供给商家服务器。在有些实施例中，商家服务器可以从客户端获得结帐请求，并且从该结帐请求提取结帐详情(例如，XML数据)。例如，商家服务器可以利用例如在以下参考图61的讨论中所描述的示例解析器的的解析器。基于解析结帐请求，商家服务器可以从结帐请求提取产品数据(例如，产品标识符)，及可用的PoS客户端数据。在有些实施例中，利用产品数据，商家服务器可以查询，例如5603，商家／让受方(“商家”)数据库来获得产品数据，例如5604，像产品信息、产品定价、营业税、提议项、折扣、奖励和／或其它信息，以便为用户处理购买交易和／或提供增值服务。在有些实施例中，响应获得了产品数据，商家服务器可以生成，例如5605，结帐数据，为PoS客户端提供，例如5606。在获得结帐数据后，PoS客户端可以为用户呈现并显示，例如5607，该结帐数据。

图57A-B示出了说明在UEP的有些实施例中示例购买交易授权过程的数据流图。参考图57A，在有些实施例中，用户可能期望经商家在线站点或者在商家的商店中从商家购买产品、服务、出售物等(“产品”)。用户可以利用物理卡或者用户的钱包设备，例如5701b，访问用户的虚拟钱包账户。例如，用户钱包设备可以是个人／膝上型电脑、蜂窝电话、智能电话、平板电脑、电子书阅读器、上网本、游戏机等。用户可以把钱包访问输入，例如5711，提供给用户钱包设备。在各种实施例中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。在有些实施例中，用户钱包设备可以基于用户的钱包访问输入认证用户，并且为用户提供虚拟钱包特征。

在有些实施例中，在认证用户对虚拟钱包特征的访问之后，用户钱包设备可以向销售点(“PoS”)客户端，例如5702，提供交易授权输入，例如5714。例如，用户钱包设备可以经蓝牙、Wi-Fi、蜂窝通信、单或双向近场通信(“NFC”)等与PoS客户端通信。在用户利用塑料卡代替用户钱包设备的实施例中，用户可以在PoS客户端刷该塑料卡，把信息从塑料卡传输到PoS客户端。例如，作为交易授权输入5714，PoS客户端可以从用户的塑料卡(例如，信用卡、借记卡、预付卡、充值卡等)获得轨道1数据，例如以下提供的示例轨道1数据：

在用户利用用户钱包设备的实施例中，用户钱包设备可以向PoS客户端提供付款信息，该付款信息根据适合在用户钱包设备与PoS客户端之间通信中采用的通信机制的数据格式化协议格式化。基本上以XML格式化数据的形式，以下提供交易授权输入5714的一个示例列表：

在有些实施例中，PoS客户端可以利用从用户钱包设备获得的交易授权输入和／或产品／结帐数据(见例如图55，5515-5517)生成卡授权请求，例如5715。基本上以包括XML格式化数据的HTTP(S)POST消息的形式，以下提供卡授权请求5715的一个示例列表：

在有些实施例中，用户设备生成的卡授权请求可以包括处理购买交易所需的最少量信息。例如，这可以提高传送购买交易请求的效率，而且还可以有利地改进提供给用户和／或商家的隐私性保护。例如，在有些实施例中，卡授权请求可以包括至少一个用于用户与商家的购物会话的会话ID。该会话ID可以被具有访问商家服务器上安全站点的适当访问授权的任何组件和／或实体用于获得关于用户与商家的那个购物会话中交易的报警、提醒和／或其它数据。在有些实施例中，PoS客户端可以把生成的卡授权请求提供给商家服务器，例如5716。商家服务器可以把卡授权请求转发到支付网关服务器，例如5704a，用于把卡授权请求路由到适当的付款网络，进行付款处理。例如，支付网关服务器可能能够从付款网络，例如Visa、Mastercard、American Express、Paypal等，中进行选择，处理各种类型的交易，包括但不限于：信用卡、借记卡、预付卡、B2B和／或类似的交易。在有些实施例中，商家服务器可以从数据库，例如商家／让受方数据库5703b，查询付款网关服务器的网络地址，例如通过使用用户付款卡号的一部分或者用户ID(例如电子邮件地址)作为数据库查询的关键字。例如，商家服务器可以发布PHP／SQL命令，从数据库表(例如图61，支付网关6119h)查询支付网关服务器的URL。基本上以PHP／SQL命令的形式，下面提供一个示例付款网关地址查询5717：

作为响应，商家／让受方数据库可以提供所请求的付款网关地址，例如5718。商家服务器可以利用所提供的地址把卡授权请求转发到支付网关服务器，例如5719。在有些实施例中，在从商家服务器接收到卡授权请求后，支付网关服务器可以启用一个部件来提供与购买交易授权关联的一种或多种服务。例如，支付网关服务器可以启用用于欺诈预防、忠实和／或奖励和／或其它服务的组件，其中为这些服务授权了用户-商家组合。支付网关服务器可以把卡授权请求转发到支付网络服务器，例如5705a，用于付款处理。例如，支付网关服务器可能能够从付款网络，例如Visa、Mastercard、AmericanExpress、Paypal等，中进行选择，处理各种类型的交易，包括但不限于：信用卡、借记卡、预付卡、B2B等交易。在有些实施例中，支付网关服务器可以从数据库，例如支付网关数据5704b，查询付款网络服务器的网络地址，例如通过使用用户付款卡号的一部分或者用户ID(例如电子邮件地址)作为数据库查询的关键字。例如，支付网关服务器可以发布PHP／SQL命令，从数据库表(例如图61，支付网关6119h)查询支付网络服务器的URL。基本上以PHP／SQL命令的形式，下面提供一个示例付款网络地址查询5721：

作为响应，付款网关数据库可以提供所请求的付款网络地址，例如5722。支付网关服务器可以利用所提供的地址把卡授权请求转发到支付网络服务器，例如5723。

参考图57B，在有些实施例中，支付网络服务器可以处理交易，从而把用于购买的资金转移到存储在商家的一个让受方上的账户。例如，让受方可以是维护商家账户的金融机构。例如，商家所处理的交易的继续进行可以堆积到由该让受方的服务器维护的账户中。

在有些实施例中，支付网络服务器可以生成对对应于用户选定的付款选项的发行者服务器的查询，例如5724。例如，用户帐户可以链接到一个或多个为用户发行账户的发行者金融机构(“发行者”)，例如银行机构。例如，这种账户可以包括但不限于：信用卡、借记卡、预付卡、活期存款、储蓄、金融市场、存单、储值(现金)账户等。发行者的发行者服务器，例如5706a，可以维护用户帐户的详情。在有些实施例中，数据库，例如支付网络数据库5705b，可以存储与发行者关联的发行者服务器的详情。在有些实施例中，支付网络服务器可以从数据库，例如支付网络数据库5705b，查询发行者服务器的网络地址，例如通过使用用户付款卡号的一部分或者用户ID(例如电子邮件地址)作为数据库查询的关键字。例如，商家服务器可以发布PHP／SQL命令，从数据库表(例如图61，发行者6119f)查询发行者服务器的网络地址。基本上以PHP／SQL命令的形式，下面提供一个示例发行者服务器地址查询5724：

响应获得了发行者服务器查询，例如5724，支付网络数据库可以把所请求的发行者服务器数据提供，例如5725，给支付网络服务器。在有些实施例中，支付网络服务器可以利用发行者服务器数据为基于与用户虚拟钱包关联的预定义付款设置和／或用户付款选项输入选择的每个发行者服务器生成资金授权请求，例如5726，并且把该资金授权请求提供给发行者服务器。在有些实施例中，资金授权请求可以包括例如但不限于以下详情：交易中所涉及的用户的成本、用户的卡账户详情、用户的开票和／或发货信息，等等。基本上以包括XML格式化数据的HTTP(S)POST消息的形式，下面提供资金授权请求5726的一个示例列表：

在有些实施例中，发行者服务器可以解析授权请求，并且可以基于该请求的详情从数据库，例如用户简档数据库5706b，查询与链接到用户的账户关联的数据。例如，商家服务器可以发布PHP／SQL命令，从数据库表(例如图61，账户6119d)查询用户帐户数据。基本上以PHP／SQL命令的形式，下面提供一个示例用户帐户查询5727：

在有些实施例中，关于获得用户帐户数据，例如5728，发行者服务器可以确定用户是否可以利用该账户中可用的资金支付交易，5729。例如，发行者服务器可以确定用户在该账户中是否剩余足够的余额、与该账户关联的足够存款等。基于这种确定，发行者服务器可以向支付网络服务器提供资金授权响应，例如5730。例如，发行者服务器可以提供类似于以上示例的HTTP(S)POST消息。在有些实施例中，如果至少一个发行者服务器确定用户不能利用账户中可用的资金支付交易，则支付网络服务器可以再次从用户请求付款选项(例如，通过向用户设备提供授权失败消息并且请求用户设备提供新付款选项)，并且重新尝试对购买交易的授权。在有些实施例中，如果失败的授权尝试的次数超过一个阈值，则支付网络服务器可以异常结束授权过程，并且向商家服务器、用户设备和／或客户端提供“授权失败”消息。

在有些实施例中，支付网络服务器可以获得包括成功授权的通知的资金授权响应，并且解析该消息以便提取授权详情。在确定用户拥有用于交易的足够资金后，例如5731，支付网络服务器可以启用一个组件，为用户提供增值服务。

在有些实施例中，支付网络服务器可以从授权请求和／或授权响应生成交易数据记录，并且在交易数据库中存储交易详情和与交易相关的授权。例如，支付网络服务器可以发布PHP／SQL命令，把数据存储到数据库表(例如图61，交易6119i)。基本上以PHP／SQL命令的形式，下面提供一个示例交易存储命令：

在有些实施例中，支付网络服务器可以把交易授权响应，例如5732，转发到用户钱包设备、PoS客户端和／或商家服务器。商家可以获得交易授权响应，并且从其确定用户在卡账户中具有进行交易的足够资金。商家服务器可以把用于用户的交易记录添加到与被授权交易相关的一批交易数据。例如，商家可以把关于用户交易的XML数据附加到包括用于已经对各个用户授权的交易的XML数据的XML数据文件，例如5733，并且在数据库，例如商家数据库404，中存储该XML数据文件，例如5734。例如，分批XML数据文件可以结构化成类似于以下提供的示例XML数据结构模板：

在有些实施例中，服务器还可以生成购买收据，例如5733，并且把该购买收据提供给客户端，例如5735。客户端可以为用户呈现并显示，例如5736，该购买收据。在有些实施例中，用户的钱包设备还可以向用户提供成功授权的通知。例如，PoS客户端／用户设备可以呈现网页、电子消息、文本／SMS消息、缓冲语音邮件、发射铃声和／或播放音频消息等，并且提供包括但不限于以下输出：声音、音乐、音频、视频、图像、触觉反馈、振动报警(例如，在具有振动能力的客户端设备上，例如智能电话等)，等等。

图58A-B示出了说明在UEP的有些实施例中购买交易授权的示例方面的逻辑流图，例如，购买交易授权(“PTA”)组件5800。参考图58A，在有些实施例中，用户可能希望利用虚拟钱包账户经商家在线站点或者在商家商店中从商家购买产品、服务、出售物等(“产品”)。用户可以利用物理卡或者用户钱包设备来访问用户的虚拟钱包账户。例如，用户钱包设备可以是个人／膝上型电脑、蜂窝电话、智能电话、平板电脑、电子书阅读器、上网本、游戏机等。用户可以把钱包访问输入，例如5801，提供给用户钱包设备。在各种实施例中，用户输入可以包括但不限于：对触摸屏界面的单次轻击(例如，一次轻击移动应用购买实施例)、键盘输入、刷卡、激活用户设备中启用了RFID／NFC的硬件设备(例如，具有多个账户的电子卡、智能电话、平板电脑等)、鼠标点击、按下操纵杆／游戏控制台上的按钮、语音命令、触摸敏感界面上的单／多触摸手势、触摸触摸敏感显示器上的用户界面元素，等等。在有些实施例中，用户钱包设备可以基于用户钱包访问输入认证用户，并且为用户提供虚拟钱包特征，例如5802-5803。

在有些实施例中，在认证用户能访问虚拟钱包特征后，用户钱包设备可以向销售点(“PoS”)客户端提供交易授权输入，例如5804。例如，用户钱包设备可以经蓝牙、Wi-Fi、蜂窝通信、单或双向近场通信(“NFC”)等与PoS客户端通信。在用户利用塑料卡而不是用户钱包设备的实施例中，用户可以在PoS客户端刷该塑料卡，把信息从塑料卡传输到PoS客户端。在用户利用用户钱包设备的实施例中，用户钱包设备可以向PoS客户端提供付款信息，该信息根据适于在用户钱包设备与PoS客户端之间的通信中采用的通信机制的数据格式化协议格式化。

在有些实施例中，PoS客户端可以获得交易授权输入，并且解析该输入，从交易授权输入提取付款信息，例如5805。例如，PoS客户端可以利用例如在以下参考图61的讨论中所提供的示例解析器的解析器。PoS客户端可以利用从用户钱包设备获得的交易授权输入和／或产品／结帐数据(见例如图55，5515-5517)生成卡授权请求，例如5806。

在有些实施例中，PoS客户端可以把生成的卡授权请求提供给商家服务器。商家服务器可以把卡授权请求转发到支付网关服务器，用于把卡授权请求路由到适当的付款网络，进行付款处理。例如，支付网关服务器可能能够从付款网络，例如Visa、Mastercard、American Express、Paypal等，中进行选择，来处理各种类型的交易，包括但不限于：信用卡、借记卡、预付卡、B2B和／或类似的交易。在有些实施例中，商家服务器可以从数据库查询付款网关服务器的网络地址，例如5808，例如通过使用用户付款卡号的一部分或者用户ID(例如电子邮件地址)作为数据库查询的关键字。作为响应，商家／让受方数据库可以提供所请求的付款网关地址，例如5810。商家服务器可以利用所提供的地址把卡授权请求转发到支付网关服务器。在有些实施例中，在从商家服务器接收到卡授权请求后，支付网关服务器可以启用一个组件，提供与购买交易授权关联的一种或多种服务，例如5811。例如，支付网关服务器可以启用用于欺诈防止、忠实和／或奖励和／或其它服务的组件，其中对这些服务授权了用户-商家组合。

支付网关服务器可以把卡授权请求转发到支付网络服务器，进行付款处理，例如5814。例如，支付网关服务器可能能够从付款网络，例如Visa、Mastercard、American Express、Paypal等，中进行选择，来处理各种类型的交易，包括但不限于：信用卡、借记卡、预付卡、B2B和／或类似的交易。在有些实施例中，支付网关服务器可以从数据库查询付款网关服务器的网络地址，例如5812，例如通过使用用户付款卡号的一部分或者用户ID(例如电子邮件地址)作为数据库查询的关键字。作为响应，付款网关数据库可以提供所请求的付款网络地址，例如5813。支付网关服务器可以利用所提供的地址把卡授权请求转发到支付网络服务器，例如5814。

参考图58B，在有些实施例中，支付网络服务器可以处理交易，从而把用于购买的资金转到存储在商家的让受方上的账户中。例如，让受方可以是维护商家账户的金融机构。例如，由商家处理的交易的继续进行可以堆积到由该让受方的服务器维护的账户中。在有些实施例中，支付网络服务器可以生成对对应于用户选定的付款选项的发行者服务器的查询，例如5815。例如，用户的账户可以链接到一个或多个为用户发行账户的发行者金融机构(“发行者”)，例如银行机构。例如，这种账户可以包括但不限于：信用卡、借记卡、预付卡、活期存款、储蓄、金融市场、存单、储值(现金)账户等。发行者的发行者服务器可以维护用户帐户的详情。在有些实施例中，数据库，例如支付网络数据库，可以存储与发行者关联的发行者服务器的详情。在有些实施例中，支付网络服务器可以从数据库，例如5815，查询发行者服务器的网络地址，例如通过使用用户付款卡号的一部分或者用户ID(例如电子邮件地址)作为数据库查询的关键字。

响应于获得了发行者服务器查询，支付网络数据库可以把所请求的发行者服务器数据提供，例如5816，给支付网络服务器。在有些实施例中，支付网络服务器可以利用发行者服务器数据为基于与用户虚拟钱包关联的预定义付款设置和／或用户的付款选项输入选择的每个发行者服务器生成资金授权请求，例如5817，并且向发行者服务器提供该资金授权请求。在有些实施例中，资金授权请求可以包括例如但不限于以下详情：交易中所涉及的用户的成本、用户的卡账户详情、用户的开票和／或发货信息，等等。在有些实施例中，发行者服务器可以解析授权请求，例如5818，并且可以基于请求的详情从数据库查询，例如5819，与链接到用户的账户关联的数据。

在有些实施例中，关于获得用户帐户数据，例如5820，发行者服务器可以确定用户可以利用该账户中可用的资金支付交易，5821。例如，发行者服务器可以确定用户是否具有在该账户中剩余的足够余额、与该账户关联的足够存款等。基于这种确定，发行者服务器可以向支付网络服务器提供资金授权响应，例如5822。在有些实施例中，如果至少一个发行者服务器确定用户不能利用账户中可用的资金支付交易，则支付网络服务器可以再次从用户请求付款选项(例如，通过向用户设备提供授权失败消息并且请求用户设备提供新付款选项)，并且重新尝试对购买交易的授权。在有些实施例中，如果失败的授权尝试的次数超过一个阈值，则支付网络服务器可以异常结束授权过程，并且向商家服务器、用户设备和／或客户端提供“授权失败”消息。

在有些实施例中，支付网络服务器可以获得包括成功授权的通知的资金授权响应，并且解析该消息以便提取授权详情。在确定用户拥有用于交易的足够资金后，例如5823，支付网络服务器可以启用一个组件，为用户提供增值服务，例如5823。

在有些实施例中，支付网络服务器可以把交易授权响应转发到用户钱包设备、PoS客户端和／或商家服务器。商家可以解析，例如5824，该交易授权响应，并且从其确定用户在卡账户中具有进行交易的足够资金，例如5825，选项“是”。商家服务器可以把用于用户的交易记录添加到与被授权交易相关的一批交易数据。例如，商家可以把关于用户交易的XML数据附加到包括用于已经对各个用户授权的交易的XML数据的XML数据文件，例如5826，并且在数据库中存储该XML数据文件，例如5827。在有些实施例中，服务器还可以生成购买收据，例如5828，并且向客户端提供该购买收据。客户端可以为用户呈现并显示，例如5829，该购买收据。在有些实施例中，用户的钱包设备还可以向用户提供成功授权的通知。例如，PoS客户端／用户设备可以呈现网页、电子消息、文本／SMS消息、缓冲语音邮件、发射铃声和／或播放音频消息等，并且提供包括但不限于以下输出：声音、音乐、音频、视频、图像、触觉反馈、振动报警(例如，在具有振动能力的客户端设备上，例如智能电话等)，等等。

图59A-B示出了说明在UEP的有些实施例中示例购买交易清除过程的数据流图。参考图59A，在有些实施例中，商家服务器，例如5903a，可以启动一批授权交易的清除。例如，商家服务器可以生成分批数据请求，例如5911，并且把该请求提供给商家数据库，例如5903b。例如，商家服务器可以利用类似于以上提供的查询关系数据库的示例的PHP／SQL命令。响应该分批数据请求，数据库可以提供所请求的分批数据，例如5912。服务器可以利用从数据库获得的分批数据生成分批清除请求，例如5913，并且把该分批清除请求提供，例如5914，给让受方服务器，例如5907a。例如，商家服务器可以为让受方服务器提供在消息体中包括XML格式化分批数据的HTTP(S)POST消息。让受方服务器可以利用所获得的分批清除请求生成，例如5915，分批付款请求，并且把该分批付款请求提供，例如5918，给支付网络服务器，例如5905a。支付网络服务器可以解析该分批付款请求，并且提取存储在分批付款请求中的、用于每笔交易的交易数据，例如5919。支付网络服务器可以在数据库，例如支付网络数据库5905b，中存储用于数据库中每笔交易的交易数据，例如5920。在有些实施例中，支付网络服务器可以启用一个组件，基于对UEP为其清除购买交易的商家交易的分析提供增值分析服务。因此，在有些实施例中，支付网络服务器可以为商家和／或该商家的用户提供基于分析的增值服务。

参考图59B，在有些实施例中，对于每笔提取出的交易，支付网络服务器可以从数据库，例如支付网络数据库5905b，查询，例如5923，发行者服务器的地址。例如，支付网络服务器可以利用类似于以上提供的示例的PHP／SQL命令。支付网络服务器可以为已经为其提取出交易数据的每笔交易生成单独的支付请求，例如5925，并且把该单独的付款请求，例如5925，提供给发行者服务器，例如5906a。例如，支付网络服务器可以向发行者服务器提供作为包括XML格式化数据的HTTP(S)POST消息的单独的付款请求。基本上以包括XML格式化数据的HTTP(S)POST消息的形式，下面提供单独的付款请求5925的一个示例列表：

在有些实施例中，发行者服务器可以生成付款命令，例如5927。例如，发行者服务器可以发布从用户帐户扣除资金(或者向用户的信用卡账户充值)的命令。发行者服务器可以向存储用户帐户信息的数据库，例如用户简档数据库5906b，发布付款命令，例如5927。发行者服务器可以向支付网络服务器提供单独的付款确认，例如5928，支付网络服务器可以把资金转移消息转发，例如5929，到让受方服务器。基本上以包括XML格式化数据的HTTP(S)POST消息的形式，下面提供单独的付款确认5928的一个示例列表：

在有些实施例中，让受方服务器可以解析单独的付款确认，并且(例如，利用以上示例中的request_ID)把交易关联到商家。然后，让受方服务器可以把资金转移消息中规定的资金转移到商家的账户。例如，让受方服务器可以从让受方数据库5907b查询，例如5930，付款明细账和／或商家账户数据，例如593１。让受方服务器可以利用来自让受方数据库的付款明细账和／或商家账户数据，连同单独的付款确认一起，生成更新后的付款明细账和／或商家账户数据，例如5932。然后，让受方服务器可以把更新后的付款明细账和／或商家账户数据存储，例如5933，到让受方数据库。

图60A-B示出了说明在UEP的有些实施例中购买交易清除的示例方面的逻辑流图，例如，购买交易清除(“PTC”)组件6000。参考图60A，在有些实施例中，商家服务器可以启动一批授权交易的清除。例如，商家服务器可以生成分批数据请求，例如6001，并且把该请求提供给商家数据库。响应该分批数据请求，数据库可以提供所请求的分批数据，例如6002。服务器可以利用从数据库获得的分批数据生成分批清除请求，例如6003，并且把该分批清除请求提供给让受方服务器。让受方服务器可以解析，例如6004，所获得的分批清除请求，并且利用所获得的分批清除请求生成，例如6007，分批付款请求，把该分批付款请求提供给支付网络服务器。例如，让受方服务器可以从让受方数据库查询，例如6005，付款网络服务器的地址，并且利用所获得的地址，例如6006，把生成的分批付款请求转发到支付网络服务器。

支付网络服务器可以解析从让受方服务器获得的分批付款请求，并且提取存储在分批付款请求中的、用于每笔交易的交易数据，例如6008。支付网络服务器可以在支付网络数据库中存储用于每笔交易的交易数据，例如6009。在有些实施例中，支付网络服务器可以启用一个组件，例如6010，基于为其清除购买交易的商家的交易提供分析。

参考图60B，在有些实施例中，对于每笔提取出的交易，支付网络服务器可以从支付网络数据库查询，例如6011，发行者服务器的地址。支付网络服务器可以为为其提取出交易数据的每笔交易生成单独的付款请求，例如6013，并且把该单独的付款请求提供给发行者服务器。在有些实施例中，发行者服务器可以解析单独的付款请求，例如6014，并且基于解析后的单独的付款请求生成付款命令，例如6015。例如，发行者服务器可以发布从用户的账户扣除资金(或者向用户的信用卡账户充值)的命令。发行者服务器可以向存储用户帐户信息的数据库，例如用户简档数据库，发布付款命令，例如6015。发行者服务器可以向支付网络服务器提供单独的付款确认，例如6017，支付网络服务器可以把该单独的付款确认转发，例如6018，到让受方服务器。

在有些实施例中，让受方服务器可以解析单独的付款确认，并且(例如，利用以上示例中的request_ID)把交易关联到商家。然后，让受方服务器可以把资金转移消息中规定的资金转移到商家的账户。例如，让受方服务器可以从让受方数据库查询，例如6019，付款明细账和／或商家账户数据，例如6020。让受方服务器可以利用来自让受方数据库的付款明细账和／或商家账户数据，连同单独的付款确认一起，生成更新后的付款明细账和／或商家账户数据，例如6021。然后，让受方服务器可以把更新后的付款明细账和／或商家账户数据存储，例如6022，到让受方数据库。

UEP控制器

图61示出了说明UEP控制器6101的实施例的框图。在这个实施例中，UEP控制器6101可以用于通过各种技术和／或其它相关的数据聚合、处理、存储、搜索、服务、识别、指示、生成、匹配和／或方便与计算机的交互。

一般来说，用户，例如6133a，可以运用信息技术系统(例如，计算机)来方便信息处理，其中用户可以是人和／或其它系统。计算机又采用处理器来处理信息；这种处理器6103可以被称为中央处理单元(CPU)。一种形式的处理器被称为微处理器。CPU使用通信电路传递二进制编码的信号，充当启用各种操作的指令。这些指令可以是操作性和／或数据指令，包含和／或引用存储器6129(例如，寄存器、高速缓存存储器、随机存取存储器等)的各种处理器可访问与可操作区域内的其它指令与数据。这种通信指令可以按批(例如，指令批)存储和／或发送，作为方便期望操作的程序和／或数据组件。这些存储的指令代码，例如程序，可以运用CPU电路组件与其它母板和／或系统组件来执行期望的操作。一种类型的程序是计算机操作系统，它可以由计算机上的CPU执行；操作系统使得用户能够并且方便用户访问并操作计算机信息技术与资源。在信息技术技术系统中可以采用的一些资源包括：输入与输出机制，数据可以通过其进入和离开计算机；存储器储存器，数据可以保存到其中；及处理器，信息可以被其处理。这些信息技术系统可以用于收集数据，供以后检索、分析和操纵，这些操作可以通过数据库程序变得容易进行。这些信息技术系统提供了允许用户访问和操作各种系统组件的接口。

在一种实施例中，UEP控制器6101可以连接到和／或与例如但不限于以下的实体通信：来自用户输入设备6111的一个或多个用户；外围设备6112；可选的密码处理器设备6128；和／或通信网络6113。例如，UEP控制器6101可以连接到用户，例如6133a、操作客户端设备，例如6133b，和／或与其通信，其中客户端设备包括但不限于个人电脑、服务器和／或各种移动设备，包括但不限于蜂窝电话、智能电话(例如，

基于Android OS的电话等)、平板电脑(例如，Apple iPad^TM、HP Slate^TM、MotorolaXoom^TM等)、电子书阅读器(例如，Amazon Kindle^TM、Barnesand Noble的Nook^TM电子阅读器等)、膝上型电脑、笔记本、上网本、游戏机(例如，XBOX Live^TM、

DS、Sony

便携式等)、便携式扫描仪等。

网络通常被认为包括拓扑图中客户端、服务器与中间节点的互连与互操作。应当指出，如贯穿本申请所使用的，术语“服务器”通常指跨通信网络处理并响应远端用户的请求的计算机、其它设备、程序或者其组合。服务器向发出请求的“客户端”提供它们的信息。如贯穿本申请所使用的，术语“客户端”通常指能够跨通信网络处理并进行请求并且处理从服务器获得的任何响应的计算机、程序、其它设备、用户和／或其组合。方便、处理信息与请求和／或促进信息从源用户传递到目的地用户的计算机、其它设备、程序或者其组合统称为“节点”。网络通常被认为方便信息从源点到目的地的传输。专用于促进信息从源传递到目的地的节点统称为“路由器”。存在许多形式的网络，例如局域网(LAN)、微微网、广域网(WAN)、无线网络(WLAN)等。例如，互联网通常作为多数网络的互连被接受，由此远端客户端与服务器可以彼此访问和互操作。

UEP控制器6101可以基于可以包括但不限于例如连接到存储器6129的计算机系统6102的组件的计算机系统。

计算机系统

计算机系统6102可以包括时钟6130、中央处理单元(“CPU”和／或“处理器”(除非相反地指出，否则这些术语贯穿本公开内容可以互换使用))6103、存储器6129(例如，只读存储器(ROM)6106、随机存取存储器(RAM)6105等)和／或接口总线6107，而且更经常地，但不一定是必需，这些组件全都通过一个或多个(母)板6102上的系统总线6104互连和／或通信，其中母板6102具有传导性和／或别的运输性电路通道，指令(例如，二进制编码的信号)可以穿行通过这些通道，来实现通信、操作、存储等。计算机系统可以连接到电源6186，例如，可选地，电源可以是内部的。可选地，密码处理器6126和／或收发器(例如，IC)6174可以连接到系统总线。在另一种实施例中，密码处理器和／或收发器可以作为内部和／或经接口总线I／O作为外部外围设备6112连接。收发器又可以连接到天线6175，由此实现各种通信和／或传感器协议的无线发送与接收；例如，天线可以连接到：德州仪器(Texas Instruments)的WiLinkWL1283收发器芯片(例如，提供802.11n、蓝牙3.0、FM、全球定位系统(GPS)(由此允许UEP控制器确定其位置))；博通(Broadcom)的BCM4329FKUBG收发器芯片(例如，提供801.11n、蓝牙2.1+EDR、FM等)；博通(Broadcom)的BCM4750IUB8接收器芯片(例如，GPS)；英飞凌科技股份有限公司(Infineon Technologies)的X-Gold618-PMB9800(例如，提供2G／3G HSDPA／HSUPA通信)；等等。系统时钟一般具有晶体振荡器并且通过计算机系统的电路通道生成基信号。时钟一般耦合到系统总线和各种时钟倍增器，其中时钟倍增器将为计算机系统中互连的其它部件增加或减少基本操作频率。计算机系统中的时钟与各种组件驱动体现信息的信号通过整个系统。体现贯穿计算机系统的信息的指令的这种发送与接收可以统称为通信。这些通信指令可以进一步针对：通信网络、输入设备、其它计算机系统、外围设备等被发送、接收，而且造成超出即时计算机系统的返回和／或应答通信。应当理解，在备选实施例中，以上任何组件都可以直接彼此连接、连接到CPU和／或在如由各种计算机系统示例的那样被采用的各种变体中组织。

CPU包括至少一个足以执行程序组件的高速数据处理器，其中程序组件用于执行用户和／或系统生成的请求。处理器本身将常常结合各种专用处理单元，例如但不限于：集成系统(总线)控制器、存储器管理控制单元、浮点单元，及甚至专用的处理子单元，像图形处理单元、数字信号处理单元等。此外，处理器可以包括内部快速访问可寻址存储器，而且能够映射并寻址超出处理器本身的存储器6129；内部存储器可以包括但不限于：快速寄存器、各种级别的高速缓存存储器(例如，1、2、3级等)、RAM等。处理器可以通过使用可以经指令地址访问的存储器地址空间访问这种存储器，其中处理器可以构造并解码指令地址，从而允许其访问到具有一个存储器状态的具体存储器地址空间的电路通道。CPU可以是微处理器，例如：AMD的Athlon、Duron和／或Opteron；ARM的应用、嵌入式与安全处理器；IBM和／或摩托罗拉(Motorola)的DragonBall与PowerPC；IBM与索尼(Sony)的Cell处理器；Intel的Celeron、Core(2)Duo、Itanium、Pentium、Xeon和／或Xscale；和／或类似的处理器。CPU通过指令与存储器交互，所述指令通过传导性和／或运输性管道(例如，(印制)电子和／或光学电路)，根据常规的数据处理技术执行所存储的指令(即，程序代码)。这种指令传递方便通过各种接口进行UEP控制器内部及超出其的通信。如果处理需求应当规定更大量的速度和／或容量，则可以类似地采用分布式处理器(例如，分布式UEP)、大型机、多核、并行和／或超级计算机体系结构。作为替代，如果部署需求规定更大的便携性，则可以采用更小的个人数字助理(PDA)。

依赖于特定的实现方式，UEP的特征可以通过实现例如CAST的R8051XC2微控制器、Intel的MCS51(即，8051微控制器)等微控制器来获得。而且，为了实现UEP的某些特征，有些特征实现方式可以依赖嵌入式组件，例如：专用集成电路(“ASIC”)、数字信号处理(“DSP”)，现场可编程门阵列(“FPGA”)和／或类似的嵌入式技术。例如，任何UEP组件集合(分布式的或者别的方式的)和／或特征都可以经微处理器和／或经嵌入式组件实现；例如，经ASIC、协处理器、DSP、FPGA等。作为替代，UEP的有些实现方式可以利用配置成并用于获得多种特征或信号处理的嵌入式组件实现。

依赖于特定的实现方式，嵌入式组件可以包括软件解决方案、硬件解决方案和／或硬件／软件解决方案的某种组合。例如，本文所讨论的UEP特征可以通过实现FPGA来获得，FPGA是包含称为“逻辑块”的可编程逻辑组件和可编程互连的半导体设备，例如由Xilinx制造的高性能FPGA Virtex系列和／或低成本Spartan系列。逻辑块与互连可以由消费者或设计人员在FPGA制造好之后编程，来实现任何UEP特征。可编程互连的层次结构允许逻辑块按照UEP系统设计人员／管理员的需求互连，有点像一个芯片的可编程试验电路板。FPGA逻辑块可以编程为执行基本逻辑门的操作，例如AND(与)和XOR(异或)，或者更复杂的组合操作，例如解码器或简单的数学运算。在大部分FPGA中，逻辑块还包括存储器元素，这可以是电路触发器或者更完整的存储器块。在有些情况下，UEP可以在常规FPGA上开发，然后移植到更像ASIC实现的固定版本中。备用或同等实现方式可以把UEP控制器特征移植到最终的ASIC，代替或者作为FPGA的附加。依赖于实现方式，以上提到的所有嵌入式组件与微处理器都可以认为是UEP的“CPU”和／或“处理器”。

电源

电源6186可以是用于给小型电子电路板设备供电的任何标准形式，例如以下电池：碱性、氢化锂、锂离子、锂聚合物、镍镉、太阳能电池等。其它类型的AC或DC电源也可以使用。在太阳能电池的情况下，在一种实施例中，外壳提供一个小孔，通过这个小孔，太阳能电池可以捕捉光能。电池6186连接到UEP的互连的后续组件中的至少一个，由此向所有后续组件提供电流。在一个示例中，电源6186连接到系统总线组件6104。在备选实施例中，外部电源6186通过跨I／O6108接口的连接提供。例如，USB和／或IEEE1394连接跨该连接既承载数据又承载电力，并且因此是合适的电源。

接口适配器

接口总线6106可以接受、连接和／或传送到多个接口适配器，虽然不是必需，但通常是以适配器卡的形式，例如但不限于：输入输出接口(I／O)6108、存储接口6109、网络接口6110等。可选地，密码处理器接口6127可以类似地可以连接到接口总线。接口总线提供接口适配器彼此之间及与计算机系统的其它组件的通信。接口适配器适于兼容的接口总线。接口适配器通常经插槽体系结构连接到接口总线。可以采用常规的插槽体系结构，例如但不限于：加速图形端口(AGP)、卡总线、(扩展)工业标准体系结构((E)ISA)、微通道体系结构(MCA)、NuBus、外围组件互连(扩展的)(PCI(X))、PCI快速、个人计算机内存卡国际联合会(PCMCIA)等。

存储接口6109可以接受、传送和／或连接到多种存储设备，例如但不限于：存储设备6114、移动盘设备等。存储接口可以采用例如但不限于以下连接协议：(超)(串行)高级技术互连(分组接口)((超)(串行)ATA(PI))、(增强的)集成驱动器电子((E)IDE)、电气电子工程师学会(IEEE)1394、光纤通道、小型计算机系统接口(SCSI)、通用串行总线(USB)等。

网络接口6110可以接受、传送和／或连接到通信网络6113。通过通信网络6113，UEP控制器可以由用户6133a通过远端客户端6133b(例如，具有web浏览器的计算机)来访问。网络接口可以采用例如但不限于以下连接协议：直接连接、以太网(胖、瘦、双绞线10／100／1000BASE T等)、例如IEEE802.11a-x的令牌环无线连接等。如果处理需求应当规定更大量的速度和／或容量，则可以类似地使用分布式网络控制器(例如，分布式UEP)、体系结构来储集、负载平衡和／或以别的方式增加UEP控制器所需的通信带宽。通信网络可以是以下任何一种和／或其组合：直接互连；互联网；局域网(LAN)、城域网(MAN)；作为节点在互联网上的操作任务(OMNI)；安全的定制连接；广域网(WAN)；无线网络(例如，采用例如但不限于无线应用协议(WAP)、I模式等协议)；等等。网络接口可以被认为是输入输出接口的一种专用形式。另外，多个网络接口6110可以用于与各种通信网络类型6113衔接。例如，可以采用多个网络接口，以便允许经广播、多播和／或单播网络通信。

输入输出接口(I／O)6108可以接受、传送和／或连接到用户设备6111、外围设备6112、密码处理器设备6128等。I／O可以采用例如但不限于以下连接协议：音频：模拟、数字、非立体声、RCA、立体声等；数据：Apple桌面总线(ADB)、IEEE1394a-b、串行、通用串行总线(USB)；红外线；操纵杆；键盘；midi(乐器数字化接口)；光学；PC AT；PS／2；并行；无线电；视频接口：Apple桌面连接器(ADC)、BNC、同轴、组件、复合材料、数字、数字可视接口(DVI)、高清晰多媒体接口(HDMI)、RCA、RF天线、S-视频、VGA等；无线收发器；802.11a／b／g／n／x；蓝牙；蜂窝(例如，码分多址访问(CDMA)、高速分组访问(HSPA(+))、高速下行链路分组访问(HSDPA)、用于移动通信的全球系统(GSM)、长期演进(LTE)、WiMax等)；等等。一种典型的输出设备可以包括视频显示器，这一般包括基于阴极射线管(CRT)或液晶显示器(LCD)的监视器，具有从视频接口接受信号的接口(例如，DVI电路系统与电缆)，可以使用。视频接口合成由计算机系统生成的信息并且基于合成的信息在视频存储帧中生成视频信号。另一种输出设备是电视机，它从视频接口接受信号。一般来说，视频接口通过视频连接接口提供合成的视频信息，其中视频连接接口接受视频显示接口(例如，接受RCA合成视频电缆的RCA合成视频连接器；接受DVI显示电缆的DVI连接器，等等)。

用户输入设备6111常常是一种类型的外围设备6112(见下面)而且可以包括：读卡器、保护锁、指纹阅读器、手套、图形输入板、操纵杆、键盘、麦克风、鼠标(多个鼠标)、遥控器、视网膜阅读器、触摸屏(例如，电容性、电阻性等)、轨迹球、轨迹板、传感器(例如，加速计、环境光、GPS、陀螺仪、接近性等)、触控笔等。

外围设备6112可以连接到和／或传送到I／O和／或类似的其它设施，例如网络接口、存储接口，直接连接到接口总线、系统总线、CPU等。外围设备可以在UEP控制器的外部、内部和／或是其一部分。外围设备可以包括：天线、音频设备(例如，输入线、输出线、麦克风输入、扬声器等)、照相机(例如，静物、视频、摄像头等)、保护锁(例如，用于拷贝保护，利用数字签名确保安全交易等)、外部处理器(用于附加的能力；例如，密码设备6128)、力反馈设备(例如，振动电动机)、网络接口、打印机、扫描仪、存储设备、收发器(例如，蜂窝、GPS等)、视频设备(例如，风镜、监视器等)、视频源、遮光板等。外围设备常常包括各种输入设备的类型(例如，照相机)。

应当指出，尽管可以采用用户输入设备与外围设备，但是UEP控制器可以体现为嵌入式的、专用的和／或少监视器的(即，无头的)设备，其中访问将经网络接口连接提供。

例如但不限于微控制器、处理器6126、接口6127和／或设备6128的密码单元可以附连到和／或与UEP控制器通信。由摩托罗拉(Motorola)公司制造的MC68HC16微控制器可以用于和／或在密码单元中使用。MC68HC16微控制器利用16MHz配置中的16位乘法与累加指令并且需要少于一秒来执行512位的RSA私钥运算。密码单元支持来自交互代理的通信的认证，及允许匿名交易。密码单元还可以配置成作为CPU的一部分。等效的微控制器和／或处理器也可以使用。其它商业可用的专用密码处理器包括：博通(Broadcom)的CryptoNetX和其它安全性处理器；nCipher的nShield、SafeNet的Luna PCI(例如，7100)系列；Semaphore Communication的40MHz Roadrunner184；Sun的密码加速计(例如，加速计6000PCIe Board、加速计500子板)；Via Nano处理器(例如，L2100、L2200、U2400)线，这能够执行500+MB／s的密码指令；VLSI Technology的33MHz6868；等等。

存储器

总的来说，允许处理器影响信息的存储和／或检索的任何机制和／或实施例都被认为是存储器6129。但是，存储器是一种可代替的技术与资源，因此，任何数量的存储器实施例都可以彼此代替或合作采用。应当理解，UEP控制器和／或计算机系统可以采用各种形式的存储器6129。例如，计算机系统可以配置成其中片上CPU存储器(例如，寄存器)、RAM、ROM及任何其它存储设备的操作由纸带穿孔机或穿孔纸卡机制提供；但是，这种实施例将导致过慢的运行速率。在一种典型的配置中，存储器6129将包括ROM6106、RAM6105和存储设备6114。存储设备6114可以是任何常规的计算机系统储存器。存储设备可以包括鼓、(固定的和／或移动的)磁盘驱动器；磁光驱动器；光驱(即，Blueray、CD-ROM／RAM／可记录(R)／可重写(RW)、DVD R／RW、HD DVD R／RW等)；设备阵列(例如，独立磁盘冗余阵列(RAID))；固态存储器设备(USB存储器、固态驱动器(SSD)等)；其它处理器可读的存储介质；和／或类似的其它设备。因此，计算机系统通常需要并使用存储器。

组件集合

存储器6129可以包含程序和／或数据库组件和／或数据的集合，例如但不限于：操作系统组件6115(操作系统)；信息服务器组件6116(信息服务器)；用户接口组件6117(用户接口)；web浏览器组件6118(web浏览器)；数据库6119；邮件服务器组件6121；邮件客户端组件6122；密码服务器组件6120(密码服务器)；UEP组件6135；等等(即，统称为组件集合)。这些组件可以存储并且从存储设备和／或从可以通过接口总线访问的存储设备进行访问。尽管例如组件集合中那些的非常规程序组件一般存储在本地存储设备6114中，但是它们也可以加载和／或存储在存储器中，例如：外围设备、RAM、通过通信网络的远端存储设施、ROM、各种形式的存储器等。

操作系统

操作系统组件6115是方便UEP控制器操作的可执行程序组件。一般来说，操作系统方便I／O、网络接口、外围设备、存储设备等的访问。操作系统可以是高度容错的、可扩展的而且安全的系统，例如：Apple Macintosh OS X(服务器)；AT&T Plan9；Be OS；Unix与像Unix的系统分布(例如AT&T的UNIX；Berkley软件分发(BSD)变体，例如FreeBSD、NetBSD、OpenBSD等；Linux分发，例如Red Hat、Ubuntu等)；和／或类似的操作系统。但是，更有限的和／或更不安全的操作系统也可以采用，例如Apple MacintoshOS、IBM OS／2、Microsoft DOS、Microsoft Windows2000／2003／3.1／95／98／CE／Millenium／NT／Vista／XP(服务器)、PalmOS等。操作系统可以传送到和／或与包括它本身等的组件集合中的其它组件通信。更频繁地，操作系统与其它程序组件、用户接口等通信。例如，操作系统可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。一旦被CPU执行，操作系统就可以启用与通信网络、数据、I／O、外围设备、程序组件、存储器、用户输入设备等的交互。操作系统可以提供通过通信网络6113允许UEP控制器与其它实体通信的通信协议。各种通信协议可以被UEP控制器用作用于交互的子载体运输机制，例如但不限于：多播、TCP／IP、UDP、单播等。

信息服务器

信息服务器组件6116是所存储的、被CPU执行的程序组件。信息服务器可以是常规的互联网信息服务器，例如但不限于Apache软件基金会的Apache、Microsoft的互联网信息服务器(InternetInformation Server)等。信息服务器可以允许通过例如以下设施执行程序组件：活动服务器页面(ASP)、ActiveX、(ANSI)(对象-)C(++)、C#和／或.NET、公共网关接口(CGI)脚本、动态(D)超文本标记语言(HTML)、FLASH、Java、JavaScript、实用摘录报告语言(PERL)、超文本预处理器(PHP)、管道、Python、无线应用协议(WAP)、WebObj ects等。信息服务器可以支持例如但不限于以下安全通信协议：文件传输协议(FTP)；超文本传输协议(HTTP)；安全超文本传输协议(HTTPS)、安全套接字层(SSL)、发消息协议(例如，美国在线(AOL)即时信使(AIM)、应用交换(APEX)、ICQ、互联网多线交谈(IRC)、Microsoft网络(MSN)信使服务、存在与即时消息协议(PRIM)、互联网工程师任务组(IETF)会话启动协议(SIP)、SIP的即时消息与存在扩展(SIMPLE)、基于开放式XML的可扩展消息与存在协议(XMPP)(即，Jabber或开放移动联盟(OMA)的即时消息与存在服务(IMPS))、Yahoo!即时信使服务等。信息服务器以网页的形式向web浏览器提供结果，并且允许通过与其它程序组件的交互操纵web页面的生成。在HTTP请求的域名系统(DNS)解析部分被分解到特定的信息服务器后，信息服务器基于HTTP请求的剩余部分分解对位于UEP控制器上指定位置的信息的请求。例如，像http：／／123.124.125.126／myInformation.html的请求可能让DNS服务器把该请求的IP部分“123.124.125.126”分解成位于那个IP地址的信息服务器，那个信息服务器又可能进一步对请求的“／myInformation.html”部分解析http请求并把它分解到存储器中包含信息“myInformation.html”的位置。此外，其它信息服务协议也可以跨各种端口采用，例如，跨端口21的FTP通信等。信息服务器可以传送到和／或与包括它本身和／或类似设施的组件集合中的其它组件通信。更频繁地，信息服务器与UEP数据库6119、操作系统、其它程序组件、用户接口、web浏览器等通信。

对UEP数据库的访问可以通过多种数据库桥接机制来获得，例如通过以下列举出的脚本语言(例如，CGI)并且通过以下列举出的应用间通信通道(例如，CORBA、WebOjects等)。通过web浏览器的任何数据请求都通过该桥接机制解析成UEP所需的适当语法。在一种实施例中，信息服务将提供web浏览器可以访问的web表单。输入到web表单中所提供字段的条目被标记为已经输入到特定的字段中，并且照此解析。然后，输入的项连同字段标记一起传递，这用来指示解析器生成针对适当表和／或字段的查询。在一种实施例中，通过基于做标记的文本输入用合适的联合(join)／选择(select)命令实例化搜索串，解析器可以用标准的SQl生成查询，其中，结果产生的命令作为查询经桥接机制提供给UEP。在从该查询生成查询结果之后，结果经桥接机制传递，而且可以被解析，用于由桥接机制格式化和生成新的结果web页面。然后，这种新的结果web页面提供给信息服务器，信息服务器可以把它提供给发出请求的web浏览器。

而且，信息服务器可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。

用户接口

在有些方面，计算机接口类似于汽车操作接口。例如方向盘、换档装置和里程表的汽车操作接口元素方便汽车资源和状态的访问、操作与显示。例如复选框、光标、菜单、滚轮和窗口(统称为窗口小部件)的计算机交互接口元素类似地方便数据与计算机硬件和操作系统资源与状态的访问、能力、操作与显示。操作接口通常被称为用户接口。例如Apple Macintosh操作系统的Aqua、IBM的OS／2、Microsoft Windows2000／2003／3.1／95／98／CE／Millenium／NT／XP／Vista／7(即，Aero)、Unix的X-Windows(例如，可以包括附加的Unix图形接口库和层，例如K桌面环境(KDE)、mythTV与GNU网络对象模型环境(GNOME))、web接口库(例如，ActiveX、AJAX、(D)HTML、FLASH、Java、JavaScript等接口库，例如但不限于Dojo、jQuery(UI)、MooTools、Prototype、script.aculo.us、SWFObject、Yahoo!用户接口，其中任何一个都可以使用)的图形用户接口(GUI)提供了访问并且向用户图形显示信息的基线与方式。

用户接口组件6117是所存储的、由CPU执行的程序组件。用户接口可以是如由已经讨论过的操作系统和／或操作环境提供、具有其和／或在其上提供的常规图形用户接口。用户接口可以允许程序组件和／或系统设施通过文本和／或图形设施的显示、执行、交互、操纵和／或操作。用户接口提供了一种设施，用户可以通过其影响、交互和／或操作计算机系统。用户接口可以传送到和／或与包括它本身和／或类似设施的组件集合中的其它组件通信。更频繁地，用户接口与操作系统、其它程序组件等通信。用户接口可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。

Web浏览器

Web浏览器组件6118是所存储的、被CPU执行的程序组件。Web浏览器可以是常规超文本查看应用程序，例如MicrosoftInternet Explorer或者Netscape Navigator。安全web浏览可以通过HTTPS、SSL等利用128位(或更大的)加密来提供。Web浏览器允许通过例如ActiveX、AJAX、(D)HTML、FLASH、Java、JavaScript、web浏览器插件API(例如，FireFox、Safari插件和／或类似的API)等设施执行程序组件。Web浏览器和类似的信息访问工具可以集成到PDA、蜂窝电话和／或其它移动设备中。Web浏览器可以传送到和／或与包括其本身和／或类似设施的组件集合中的其它组件通信。更频繁地，web浏览器与信息服务器、操作系统、集成的程序组件(例如，插件)等通信；例如，它可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。而且，代替web浏览器和信息服务器，可以开发执行这二者的类似操作的组合应用。该组合应用将类似地影响信息的获得及其从启用UEP的节点向用户、用户代理等的提供。这种组合应用对于采用标准web浏览器的系统可能是无效的。

邮件服务器

邮件服务器组件6121是所存储的、被CPU6103执行的程序组件。邮件服务器可以是常规的互联网邮件服务器，例如但不限于sendmail、Microsoft Exchange等。邮件服务器可以允许通过例如以下设施执行程序组件：ASP、ActiveX、(ANSI)(对象-)C(++)、C#和／或.NET、CGI脚本、Java、JavaScript、PERL、PHP、管道、Python、WebObjects等。邮件服务器可以支持例如但不限于以下通信协议：互联网消息访问协议(IMAP)、消息应用编程接口(MAPI)／Microsoft Exchange、邮局协议(POP3)、简单邮件传输协议(SMTP)等。邮件服务器可以路由、转发和处理已经发送、中继和／或以别的方式穿过和／或到达UEP的进入和离开的邮件消息。

对UEP邮件的访问可以通过由单独的web服务器组件和／或操作系统提供的多种API来获得。

而且，邮件服务器可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。

邮件客户端

邮件客户端组件6122是所存储的、被CPU6103执行的程序组件。邮件客户端可以是常规的邮件查看应用程序，例如Apple Mail、Microsoft Entourage、Microsoft Outlook、Microsoft OutlookExpress、Mozilla、Thunderbird等。邮件客户端可以支持多种传输协议，例如：IMAP、Microsoft Exchange、POP3、SMTP等。邮件客户端可以传送到和／或与包括其本身和／或类似设施的组件集合中的其它组件通信。更频繁地，邮件客户端与邮件服务器、操作系统、其它邮件客户端等通信；例如，它可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。通常，邮件客户端提供组成并发送电子邮件消息的设施。

密码服务器

密码服务器组件6120是所存储的、被CPU6103、密码处理器6126、密码处理器接口6127、密码处理器设备6128等执行的程序组件。密码处理器接口将允许由密码组件对加密和／或解密请求的侦查(expedition)；但是，作为替代，密码组件可以在常规CPU上运行。密码组件允许所提供数据的加密和／或解密。密码组件允许对称和不对称(例如，良好保护(PGP))加密和／或解密。密码组件可以采用例如但不限于以下密码技术：数字证书(例如，X.509认证框架)、数字签名、双签名、信封、口令访问保护、公钥管理等。密码组件将方便各种(加密和／或解密)安全性协议，例如但不限于：校验和、数据加密标准(DES)、椭圆曲线加密(ECC)、国际数据加密算法(IDEA)、报文摘译5(MD5，这是单向哈希运算)、口令、Rivest密码(RC5)、Rijindael、RSA(这是一种互联网加密与认证系统，使用在1977年由Ron Rivest、Adi Shamir和LeonardAdleman开发的算法)、安全哈希算法(SHA)、安全套接字层(SSL)、安全超文本传输协议(HTTPS)等。通过采用这种加密安全性协议，UEP可以加密所有进入和／或离开的通信而且可以利用更广泛的通信网络在虚拟专用网络(VPN)中充当节点。密码组件方便“安全性授权”过程，由此对资源的访问被安全性协议抑制，其中密码组件实现对被保护资源的授权访问。此外，密码组件可以提供内容的唯一标识符，例如，采用MD5哈希来获得用于数字音频文件的唯一签名。密码组件可以传送到和／或与包括其本身和／或类似设施的组件集合中的其它组件通信。密码组件支持允许信息跨通信网络安全发送的加密方案，使得，如果期望的话，UEP组件能够参与到安全交易中。密码组件方便对UEP上资源的安全访问并且方便对远程系统上被保护资源的访问；即，它可以充当被保护资源的客户端和／或服务器。更频繁地，密码组件与信息服务器、操作系统、其它程序组件等通信。密码组件可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。

UEP数据库

UEP数据库组件6119可以在数据库及其存储的数据中体现。数据库是存储的程序组件，可以被CPU执行；所存储的程序组件部分配置CPU来处理所存储的数据。数据库可以是常规的、容错的、关系型的、可扩展到、安全数据库，例如Oracle或Sybase。关系数据库是平面文件的扩展。关系数据库包括一系列相关的表。表经关键字字段互连。关键字字段的使用允许通过依靠该关键字字段进行索引来组合表；即，关键字字段充当组合来自各个表的信息的空间支点。关系通常通过匹配主关键字识别在表之间维护的链接。主关键字代表唯一识别关系数据库中一个表的行的字段。更精确地说，它们在一对多关系的“一”侧唯一识别表的行。

作为替代，UEP数据库可以利用各种标准数据结构来实现，例如数组、哈希、(链接)列表、结构、结构化文本文件(例如，XML)、表格等。这种数据结构可以存储在存储器中和／或(结构化)文件中。在另一种备选方案中，可以使用面向对象的数据库，例如Frontier、ObjectStore、Poet、Zope等。对象数据库可以包括通过公共属性分组和／或链接到一起的多个对象集合；它们可以通过一些公共属性关联到其它对象集合。除对象不仅仅是数据块而是还具有封装在给定对象中的其它类型能力之外，面向对象的数据库与关系数据库类似地执行。如果UEP数据库实现为数据结构，则UEP数据库6119的使用可以集成到例如UEP组件6135的另一个组件中。而且，数据库可以实现为数据结构、对象和关系结构的混合。数据库可以通过标准数据处理技术在无数变体中合并和／或分布。数据库的部分，例如表，可以导出和／或导入，而且可以可以分散和／或集成。

在一种实施例中，数据库组件6119包括若干表6119a-o。用户表6119a可以包括例如但不限于以下字段：user_id、ssn、dob、first_name、last_name、age、state、address_firstline、address_seeondline、zipcode、devices_list、contact_info、contact_type、alt_contact_info、alt_contact_type等。用户表可以支持和／或跟踪UEP上的多个实体账户。设备表6119b可以包括例如但不限于以下字段：device_ID、device_name、device_IP、device_MAC、device_type、device_model、device_version、device_OS、device_apps_list、device_securekey、wallet_app_installed_flag等。应用表6119c可以包括例如但不限于以下字段：app_ID、app_name、app_type、app_dependencies等。账户表6119d可以包括例如但不限于以下字段：account_number、account_security_code、account_name、issuer_acquirer_flag、issuer_name、acquirer_name、account_address、routing_number、access_API_call、linked_wallets_list等。商家表6119e可以包括例如但不限于以下字段：merchant_id、merchant_name、merchant_address、ip_address、mac_address、auth_key、port_num、security_settings_list等。发行者表6119f可以包括例如但不限于以下字段：issuer_id、issuer_name、issuer_address、ip_address、mac_address、auth_key、port_hum、security_settings_list等。让受方表6119g可以包括例如但不限于以下字段：account_firstname、account_lastname、account_type、account_num、account_balance_list、billingaddress_line1、billingaddress_line2、billing_zipcode、billing_state、shipping_preferences、shippingaddress_line1、shippingaddress_line2、shipping_zipcode、shipping_state等。支付网关表6119h可以包括例如但不限于以下字段：gateway_ID、gateway_IP、gateway_MAC、gateway_secure_key、gateway_access_list、gateway_API_call_list、gateway_services_list等。交易表6119i可以包括例如但不限于以下字段：order_id、user_id、timestamp、transaction_cost、purchase_details_list、num_products、products_list、products_type、products_params_list、products_title、products_summary、quantity、user_id、client_id、client_ip、client_type、client_model、operating_system、os_version、app_installed_flag、user_id、account_firstname、account_lastname、account_type、account_num、account_priority_account_ratio、billingaddress_line1、billingaddress_line2、billing_zipcode、billing_state、shipping_preference、shippingaddress_line1、shippingaddress_line2、shipping_zipcode、shipping_state、merchant_id、merchant_name、merchant_auth_key等。批次表6119j可以包括例如但不限于以下字段：batch_id、transaction_id_list、timestamp_list、cleared_flag_list、clearance_trigger_settings等。明细账表6119k可以包括例如但不限于以下字段：request_id、timestamp、deposit_amount、batch_id、transaction_id、clear_flag、deposit_account、transaction_summary、payor_name、payer_account等。产品表6119l可以包括例如但不限于以下字段：product_ID、product_title、product_attributes_list、produet_price、tax_info_list、related_products_list、offers_list、discounts_list、rewards_list、merchants_list、merchant_availability_list等。提议项表6119m可以包括例如但不限于以下字段：offer_ID、offer_title、offer_attributes_list、offer_price、offer_expiry、related_products_list、discounts_list、rewards_list、merchants_list、merchant_availability_list等。行为数据表6119n可以包括例如但不限于以下字段：user_id、timestamp、activity_type、activity_location、activity_attribute_list、activity_attribute_values_list等。分析表6119o可以包括例如但不限于以下字段：report_id、user_id、report_type、report_algorithm_id、report_destination_address等。市场数据表6119p可以包括例如但不限于以下字段：market_data_feed_ID、asset_ID、asset_symbol、asset_name、spot_price、bid_price、ask_price等；在一种实施例中，市场数据表是通过市场数据馈送(例如，彭博新闻社(Bloomberg)的PhatPipe、Dun&Bradstreet、Reuter的Tib、Triarch等)来填充的，例如，通过Microsoft的活动模板库和Dealing ObjectTechnology的实时工具箱Rtt.Multi。

在一种实施例中，UEP数据库可以与其它数据库系统交互。例如，通过采用分布式数据库系统，通过搜索UEP组件的查询与数据访问可以作为单个数据库实体来对待UEP数据库、集成的数据安全性层数据库的组合。

在一种实施例中，用户程序可以包含各种用户接口原语，这些原语可以用来更新UEP。而且，依赖于UEP可能需要为其服务的环境和客户端类型，各种账户可能需要定制的数据库表。应当指出，任何唯一的字段都可以被指定为始终作为关键字字段。在一种备选实施例中，这些表已经分散到它们自己的数据库和它们各自的数据库控制器中(即，用于以上每个表的单独的数据库控制器)。通过采用标准的数据处理技术，可以进一步在几个计算机系统和／或存储设备上分布数据库。类似地，分散的数据库控制器的配置可以通过合并和／或分布各种数据库组件6119a-o来改变。UEP可以配置成经数据库控制器保持对各种设置、输入与参数的跟踪。

UEP数据库可以传送到和／或与包括其自己和／或类似设施的组件集合中的其它组件通信。更频繁地，UEP数据库与UEP组件、其它程序组件等通信。数据库可以包含、保留和提供关于其它节点与数据的信息。

UEP

UEP组件6135是所存储的、被CPU执行的程序组件。在一种实施例中，UEP组件结合了前面图中讨论过的UEP各方面的任何一方面和／或全部组合。因此，UEP影响跨各种通信网络对信息、服务、交易等的访问、获得与提供。

UEP组件可以把经UEP组件输入虚拟钱包移动应用接口的触摸屏输入变换成购买交易触发与收据通知等，以及UEP的类似使用。在一种实施例中，UEP组件6135取得输入(例如，结帐请求5511；产品数据5515；钱包访问输入5711；交易授权输入5714；付款网关地址5718；付款网络地址5722；发行者服务器地址5725；资金授权请求5726；用户帐户数据5728；分批数据5912；付款网络地址5916；发行者服务器地址5924；单独的付款请求5925；付款明细账、商家账户数据5931等)等，并且把输入经各种组件(例如，UPC6141；PTA6142；PTC6143；STG6144；EPGU6145；EAA6146；CEC6147；ETC6148；DFR6149；ADRN6150；VASE6151；SDA6152；TDA6153；CTDA6154；SRA6155；UBA6156；UBOR6157；SPE6158；SPT6159；WSS6160；SMCB6161；VWSC6162；ORE6163；QRCP6164；SMPE6165；PCS6166；UST6167；STRS6168；USTG6169等)变换成输出(例如，结帐请求消息5513；结帐数据5517；卡授权请求5716、5723；资金授权响应5730；交易授权响应5732；分批附加数据5734；购买收据5735；分批清除请求5914；分批付款请求5918；交易数据5920；单独的付款确认5928、5929；更新后的付款明细账、商家账户数据5933等)。

使得能够在节点之间进行信息访问的UEP组件可以通过采用标准的开发工具和语言来开发，例如但不限于：Apache组件、汇编、ActiveX、二进制可执行文件、(ANSI)(对象-)C(++)、C#和／或.NET、数据库适配器、CGI脚本、Java、JavaScript、映射工具、过程性与面向对象的开发工具、PERL、PHP、Python、外壳脚本、SQL命令、web应用服务器扩展、web开发环境与库(例如，Microsoft的ActiveX；Adobe AIR、FLEX&FLASH；AJAX；(D)HTML；Dojo；Java；JavaScript；jQuery(UI)；MooTools；原型(Prototype)；script.aculo.us；简单对象访问协议(SOAP)；SWFObject；Yahoo!对象接口等)、WebObjects等。在一种实施例中，UEP服务器采用密码服务器来加密和解密通信。UEP组件可以传送到和／或与包括它本身和／或类似设施的组件集合中的其它组件通信。更频繁地，UEP组件与UEP数据库、操作系统、其它程序组件等通信。UEP可以包含、传送、生成、获得和／或提供程序组件、系统、用户和／或数据通信、请求和／或响应。

分布式UEP

任何UEP节点控制器组件的结构和／或操作都可以按任意数量的途径组合、合并和／或分布，以方便开发和／或部署。类似地，组件集合可以按任意数量的途径组合，以方便开发和／或部署。为了实现这个目的，可以把组件集成到可以按集成方式按需动态加载组件的通用代码库或者设施中。

组件集合可以通过标准的数据处理和／或开发技术在无数的变体中合并和／或分布。程序组件集合中任意一个程序组件的多个实例都可以在单个节点和／或跨众多节点实例化，以便通过负载平衡和／或数据处理技术提高性能。此外，单个实例也可以跨多个控制器和／或存储设备分布；例如，数据库。共同工作的所有程序组件实例和控制器都可以通过标准的数据处理通信技术这么做。

UEP控制器的配置将依赖于系统部署的背景。例如但不限于底层硬件资源的预算、能力、位置和／或使用的因素会影响部署需求与配置。不管配置是导致更合并和／或集成的程序组件、导致更分布的程序组件系列和／或导致合并与分布配置之间的某种组合，数据都可以被传送、获得和／或提供。从程序组件集合合并到通用代码库中的组件的实例可以传送、获得和／或提供数据。这可以通过应用内的数据处理通信技术来实现，例如但不限于：数据参考(例如，指针)、内部发消息、对象实例变量通信、共享的存储器空间、变量传递等。

如果组件集合组件是离散的、独立的和／或在彼此外部的，则为其它组件和／或向其它组件传送、获得和／或提供数据可以通过应用间的数据处理通信技术来实现，例如但不限于：应用编程接口(API)信息通道；(分布式)组件对象模型((D)COM)、(分布式)对象链接与嵌入((D)OLE)等)、公共对象请求代理架构(CORBA)、Jini本地与远程应用编程接口、JavaScript对象标注(JSON)、远程方法调用(RMI)、SOAP、过程管道、共享文件等。在用于应用间通信的离散组件之间的或者在用于应用内通信的单个组件的存储器空间内部发送的消息可以通过语法的创建与解析来促进。语法可以通过使用例如lex、yacc、XML等开发工具来开发，这些工具允许语法的生成与解析能力，这又可以构成在组件内部和之间的通信消息的基础。

例如，语法可以布置成识别HTTP post命令的记号，例如：

w3c-post http：／／...Valuel

其中，Value1被看作是一个参数，因为“http：／／”是该语法句法的一部分，而且其后面被认为是post值的部分。类似地，对于这个语法，变量“Value1”可以插入到“http：／／”post命令中，然后发送。该语法句法本身可以表示为结构化数据，这种结构化数据被解释和／或以别的方式用于生成解析机制(例如，由lex、yacc等处理的句法描述文本文件)。而且，一旦解析机制被生成和／或实例化，它本身就可以处理和／或解析结构化数据，例如但不限于：字符(例如制表符)划定的文本、HTML、结构化文本流、XML等结构化数据。在另一种实施例中，应用间的数据处理协议本身可以具有集成的和／或很容易获得的、可以用来解析(例如，通信)数据的解析器(例如，JSON、SOAP和／或类似的解析器)。另外，解析语法的用处不仅是消息解析，而且还可以用于解析：数据库、数据集合、数据仓库、结构化数据等。同样，期望的配置将依赖于系统部署的背景、环境和需求。

例如，在有些实现方式中，UEP控制器可以执行经信息服务器实现安全套接字层(“SSL”)套接字服务的PHP脚本，其中信息服务器监听在客户端可以向其发送数据的服务器端口上进入的通信，其中的数据例如以JSON格式编码的数据。在识别出进入到通信之后，PHP脚本可以从客户端设备读取进入的消息、解析所接收到的JSON编码的文本数据，把来自JSON编码的文本数据的信息提取到PHP脚本变量中，并且在可以利用结构化查询语言(“SQL”)访问的关系数据库中存储数据(例如，客户端识别信息等)和／或提取出的信息。基本上以PHP／SQL命令的形式编写，下面提供经SSL连接从客户端设备接受JSON编码的输入数据、解析数据以便提取变量并且把数据存储到数据库的示例列表：

而且，以下资源可以用于提供关于SOAP解析器实现的示例实施例：

http：／／www.xav.com／perl／site／lib／SOAP／Parser.html

http：／／publib.boulder.ibm.com／infocenter／tivihelp／v2rl／index.j sp?topic=／com.ibm.IBMDI.doc／referenceguide295.htm

还有其它解析器实现方式：

http：／／publib.boulder.ibm.com／infocenter／tivihelp／v2rl／index.jsp?topic=／com.ibm.IBMDI.doc／referenceguide259.htm

所有这些都在此明确地引入作为参考。

为了解决各种问题并且推动本领域，对于通用电子付款装置、方法与系统的本申请的全部(包括封面页、名称(title)、标题(heading)、技术领域、背景技术、发明内容、附图说明、具体实施例、权利要求、说明书摘要、附图和／或其它)通过说明示出了其中可以实践所保护的创新的各种实施例。本申请的优点与特征仅仅是实施例的一种代表性样本，而不是穷尽的和／或排他的。它们的给出仅仅是为了帮助理解和讲授所保护的原理。应当理解，它们不代表所有受保护的创新。因此，公开内容的某些方面没有在本文讨论。对于具体的创新部分可能没有给出备选实施例，或者可能对一部分可用的更多未描述的备选实施例不被认为是那些备选实施例的弃权。应当认识到，那些未描述的实施例中有许多都结合了所述创新的相同原理而且其它是等效的。因此，应当理解，在不背离本公开内容范围和／或主旨的情况下，可以利用其它实施例而且可以进行功能、逻辑、操作、组织、结构和／或拓扑结构的修改。因此，贯穿本公开内容，所有示例和／或实施例都被认为是非限制性的。而且，除为了减少空间与重复的目的这么做之外，不应当相对于那些未在本文讨论过的实施例关于那些本文讨论过的实施例得出推论。例如，应当理解，图中和／或贯穿全文所描述任何程序组件的任意组合(组件集合)的逻辑和／或拓扑结构、其它组件和／或任何给出的特征集都不是要限定到固定的操作次序和／或布置，相反，任何公开的次序都是示例性的而且，不管其次序，所有等价物都是本公开内容所预期的。此外，应当理解，这种特征不限于串行执行，相反，可以异步、并发、并行、同时、同步等执行的任何数量的线程、过程、服务、服务器等都是本公开内容所预期的。因此，这些特征中有一些可能是相互对立的，因为它们不能同时存在于单个实施例中。类似地，有些特征适用于创新的一方面，但不适用于其它方面。此外，本公开内容包括目前未保护的其它创新。申请人对那些目前未保护的创新保留所有权利，包括保护这种创新、对其的文件附加申请、继续、部分继续、划分等权利。因此，应当理解，本公开内容的优点、实施例、示例、功能、特征、逻辑、操作、组织、结构、拓扑和／或其它方面不应当认为是对如由权利要求定义的本公开内容的限制或者对权利要求等价物的限制。应当理解，依赖于UEP个人和／或企业用户的特定需求和／或特点、数据库配置和／或关系模型、数据类型、数据发送和／或网络框架、句法结构等，可以实现启用大量灵活性与定制的UEP的各种实施例。例如，UEP的各方面可以适用于金融交易；操作安全性；资源管理等。尽管UEP的各种实施例与讨论针对电子商务，但是应当理解，本文所述的实施例可以为很多种其它应用和／或实现方式很容易地配置和／或定制。

Claims (45)

1.一种动态加入虚拟钱包处理器实现的方法，包括：

获得包括消费者的兴趣焦点背景的消费者物品兴趣指示；

从消费者情境活动指标确定消费者的活动意图评估，其中所述消费者情境活动指标包括：地理位置、所获得的消费者物品兴趣指示；

确定动态加入虚拟钱包组件，基于消费者活动意图评估而服务于消费者物品兴趣指示，其中该动态加入虚拟钱包组件可以包括布置有愿望清单和虚拟钱包购物车物品、管理员请求和商家出售物的任何一种增强现实平视显示器；

向消费者的虚拟钱包提供所确定的动态加入虚拟钱包组件，用于实例化；

根据从在消费者虚拟钱包中实例化的动态加入虚拟钱包组件进行的消费者物品选择获得动态消费者物品反复指示，其中消费者物品反复指示可以包括账户的添加、账单的添加、物品购买请求、物品信息请求中的任何一种；

存储来自消费者选择的消费者物品反复指示的历史；

向受到社交交易历史访问控制的社交交易历史馈送跟踪器提供消费者物品兴趣指示与动态消费者物品兴趣指示的社交交易历史馈送，其中所述社交交易历史馈送跟踪器可以是社交网络客户端与其它消费者的虚拟钱包中的任何一种；以及

对从物品购买请求启动的消费者购买提供收据。

2.一种多商家虚拟钱包购物处理器实现的方法，包括：

从用户设备提供产品信息搜索请求；

响应于该产品信息搜索请求，获得关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息；

利用关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息，生成单个购买交易请求；

经用户设备提供所述单个购买交易请求，用于付款处理；以及

为由第一商家出售的第一产品和由第二商家出售的第二产品获得电子购买收据。

3.如权利要求2所述的方法，其中所述用户设备是移动设备。

4.如权利要求2所述的方法，其中所述产品信息搜索请求是响应于使用搜索关键字向虚拟钱包应用输入而生成的。

5.如权利要求2所述的方法，其中所述产品信息搜索请求是利用关于经虚拟钱包应用进行的先前购买的信息生成的。

6.如权利要求2所述的方法，其中所述产品信息搜索请求是经在用户设备上执行的虚拟钱包应用提供的。

7.如权利要求2所述的方法，其中第一商家和第二商家彼此不同。

8.如权利要求2所述的方法，其中所述产品信息搜索请求包括识别用户设备位置的信息，以及对来自该用户设备附近的商家的产品信息的请求。

9.一种多商家虚拟钱包购物装置，包括：

处理器；及

存储器，布置成与处理器通信并且存储处理器可执行的指令，以便：

从用户设备提供产品信息搜索请求；

响应于该产品信息搜索请求，获得关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息；

利用关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息，生成单个购买交易请求；

经用户设备提供所述单个购买交易请求，用于付款处理；以及

为由第一商家出售的第一产品和由第二商家出售的第二产品获得电子购买收据。

10.如权利要求9所述的装置，其中所述用户设备是移动设备。

11.如权利要求9所述的装置，其中所述产品信息搜索请求是响应于使用搜索关键字向虚拟钱包应用输入而生成的。

12.如权利要求9所述的装置，其中所述产品信息搜索请求是利用关于经虚拟钱包应用进行的先前购买的信息生成的。

13.如权利要求9所述的装置，其中所述产品信息搜索请求是经在用户设备上执行的虚拟钱包应用提供的。

14.如权利要求9所述的装置，其中第一商家和第二商家彼此不同。

15.如权利要求9所述的装置，其中所述产品信息搜索请求包括识别用户设备位置的信息，以及对来自该用户设备附近的商家的产品信息的请求。

16.一种处理器可读的有形介质，存储处理器可执行的多商家虚拟钱包购物指令，以便：

从用户设备提供产品信息搜索请求；

响应于该产品信息搜索请求，获得关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息；

利用关于由第一商家出售的第一产品和由第二商家出售的第二产品的信息，生成单个购买交易请求；

经用户设备提供所述单个购买交易请求，用于付款处理；以及

为由第一商家出售的第一产品和由第二商家出售的第二产品获得电子购买收据。

17.如权利要求16所述的介质，其中所述用户设备是移动设备。

18.如权利要求16所述的介质，其中所述产品信息搜索请求是响应于使用搜索关键字向虚拟钱包应用输入而生成的。

19.如权利要求16所述的介质，其中所述产品信息搜索请求是利用关于经虚拟钱包应用进行的先前购买的信息生成的。

20.如权利要求16所述的介质，其中所述产品信息搜索请求是经在用户设备上执行的虚拟钱包应用提供的。

21.如权利要求16所述的介质，其中第一商家和第二商家彼此不同。

22.如权利要求16所述的介质，其中产品信息搜索请求包括识别用户设备位置的信息，及对来自该用户设备附近的商家的产品信息的请求。

23.一种商店加入购物处理器实现的方法，包括：

为用户设备获得基于全球定位系统的位置；

识别相对于用户设备的基于全球定位系统的位置预定距离内的附近商家；

从商店加入数据库查询所识别出的附近商家的产品目录清单和建筑平面图数据；

生成机器可读的应用模块，该模块提供所识别出的附近商家的产品目录清单和建筑平面图数据的视觉表示；以及

为用户设备提供该模块。

24.一种商店加入购物系统，包括：

处理器；及

存储器，布置成与处理器通信并且存储处理器可执行的指令，以便：

为用户设备获得基于全球定位系统的位置；

识别相对于用户设备的基于全球定位系统的位置预定距离内的附近商家；

从商店加入数据库查询所识别出的附近商家的产品目录清单和建筑平面图数据；

生成机器可读的应用模块，该模块提供所识别出的附近商家的产品目录清单和建筑平面图数据的视觉表示；以及

为用户设备提供该模块。

25.一种处理器可读的有形介质，存储处理器可执行的商店加入购物指令，以便：

为用户设备获得基于全球定位系统的位置；

识别相对于用户设备的基于全球定位系统的位置预定距离内的附近商家；

从商店加入数据库查询所识别出的附近商家的产品目录清单和建筑平面图数据；

生成机器可读的应用模块，该模块提供所识别出的附近商家的产品目录清单和建筑平面图数据的视觉表示；以及

为用户设备提供该模块。

26.一种动态加入虚拟钱包系统，包括：

处理器；及

存储器，布置成与处理器通信并且存储处理器可执行的指令，以便：

获得包括消费者的兴趣焦点的背景的消费者物品兴趣指示；

从消费者情境活动指标确定消费者的活动意图评估，其中所述消费者情境活动指标包括：地理位置、所获得的消费者物品兴趣指示；

确定动态加入虚拟钱包组件，基于消费者活动意图评估而服务于消费者物品兴趣指示，其中该动态加入虚拟钱包组件可以包括布置有愿望清单和虚拟钱包购物车物品、管理员请求和商家出售物的任何一种增强现实平视显示器；

向消费者的虚拟钱包提供所确定的动态加入虚拟钱包组件，用于实例化；

根据从在消费者虚拟钱包中实例化的动态加入虚拟钱包组件进行的消费者物品选择获得动态消费者物品反复指示，其中消费者物品反复指示可以包括账户的添加、账单的添加、物品购买请求、物品信息请求中的任何一种；

存储来自消费者选择的消费者物品反复指示的历史；

向受到社交交易历史访问控制的社交交易历史馈送跟踪器提供消费者物品兴趣指示与动态消费者物品兴趣指示的社交交易历史馈送，其中社交交易历史馈送跟踪器可以是社交网络客户端与其它消费者的虚拟钱包中的任何一种；以及

对从物品购买请求启动的消费者购买提供收据。

27.一种处理器可读的有形介质，存储处理器可执行的动态加入虚拟钱包指令，以便：

获得包括消费者的兴趣焦点的背景的消费者物品兴趣指示；

从消费者情境活动指标确定消费者的活动意图评估，其中消费者情境活动指标包括：地理位置、所获得的消费者物品兴趣指示；

确定动态加入虚拟钱包组件，基于消费者活动意图评估而服务于消费者物品兴趣指示，其中该动态加入虚拟钱包组件可以包括布置有愿望清单和虚拟钱包购物车物品、管理员请求和商家出售物的任何一种增强现实平视显示器；

向消费者的虚拟钱包提供所确定的动态加入虚拟钱包组件，用于实例化；

根据从在消费者虚拟钱包中实例化的动态加入虚拟钱包组件进行的消费者物品选择获得动态消费者物品反复指示，其中消费者物品反复指示可以包括账户的添加、账单的添加、物品购买请求、物品信息请求中的任何一种；

存储来自消费者选择的消费者物品反复指示的历史；

向受到社交交易历史访问控制的社交交易历史馈送跟踪器提供消费者物品兴趣指示与动态消费者物品兴趣指示的社交交易历史馈送，其中社交交易历史馈送跟踪器可以是社交网络客户端与其它消费者的虚拟钱包中的任何一种；以及

对从物品购买请求启动的消费者购买提供收据。

28.一种店铺跟踪收入共享处理器实现的方法，包括：

获得用户购物跟踪数据结构，包括关于用户站点浏览活动和用户站点导航活动的信息；

识别与用户站点浏览活动和用户站点导航活动关联的多个在线商家；

经处理器，从用户购物跟踪数据结构为每个在线商家计算相对用户参与贡献；

从数据库查询用于为每个在线商家把相对用户参与贡献转换成收入共享比率的转换表；

利用所述相对用户参与贡献和所述转换表为每个在线商家计算收入份额；以及

为每个在线商家提供收入份额的通知。

29.如权利要求28所述的方法，进一步包括：

生成卡授权请求，为在线商家处理收入共享交易；以及

提供生成的卡授权请求，用于交易处理。

30.一种店铺跟踪收入共享系统，包括：

处理器；以及

存储器，布置成与处理器通信并且存储处理器可执行的指令，以便：

获得用户购物跟踪数据结构，包括关于用户站点浏览活动和用户站点导航活动的信息；

识别与用户站点浏览活动和用户站点导航活动关联的多个在线商家；

经处理器，从用户购物跟踪数据结构为每个在线商家计算相对用户参与贡献；

从数据库查询用于为每个在线商家把相对用户参与贡献转换成收入共享比率的转换表；

利用所述相对用户参与贡献和所述转换表为每个在线商家计算收入份额；以及

为每个在线商家提供收入份额的通知。

31.如权利要求30所述的系统，存储器进一步存储指令，以便：

生成卡授权请求，为在线商家处理收入共享交易；以及

提供生成的卡授权请求，用于交易处理。

32.一种处理器可读的有形介质，存储处理器可执行的店铺跟踪收入共享指令，以便：

获得用户购物跟踪数据结构，包括关于用户站点浏览活动和用户站点导航活动的信息；

识别与用户站点浏览活动和用户站点导航活动关联的多个在线商家；

经处理器，从用户购物跟踪数据结构为每个在线商家计算相对用户参与贡献；

从数据库查询用于为每个在线商家把相对用户参与贡献转换成收入共享比率的转换表；

利用所述相对用户参与贡献和所述转换表为每个在线商家计算收入份额；以及

为每个在线商家提供收入份额的通知。

33.如权利要求32所述的介质，进一步存储指令，以便：

生成卡授权请求，为在线商家处理收入共享交易；以及

提供生成的卡授权请求，用于交易处理。

34.一种弹性模式付款处理器实现的方法，包括：

获得执行资金转移的用户请求；

提供选择用于资金转移的通信模式的请求；

获得对用于资金转移的通信模式的用户选择；

生成资金转移请求；以及

经用户选定的通信模式提供资金转移请求。

35.如权利要求35所述的方法，其中所述通信模式是近场通信。

36.如权利要求35所述的方法，其中所述通信模式是经操作性连接到用户设备的照相机对快速响应代码的捕捉。

37.一种弹性模式付款装置，包括：

处理器；以及

存储器，布置成与处理器通信并且存储处理器可执行的指令，以便：

获得执行资金转移的用户请求；

提供选择用于资金转移的通信模式的请求；

获得对用于资金转移的通信模式的用户选择；

生成资金转移请求；以及

经用户选定的通信模式提供资金转移请求。

38.如权利要求37所述的装置，其中所述通信模式是近场通信。

39.如权利要求37所述的装置，其中所述通信模式是经操作性连接到用户设备的照相机对快速响应代码的捕捉。

40.一种处理器可读的有形介质，存储处理器可执行的弹性模式付款指令，以便：

获得执行资金转移的用户请求；

提供选择用于资金转移的通信模式的请求；

获得对用于资金转移的通信模式的用户选择；

生成资金转移请求；以及

经用户选定的通信模式提供资金转移请求。

41.如权利要求40所述的介质，其中所述通信模式是近场通信。

42.如权利要求40所述的介质，其中所述通信模式是经操作性连接到用户设备的照相机对快速响应代码的捕捉。

43.一种虚拟钱包收据管理处理器实现的方法，包括：

经在用户设备上执行的虚拟钱包应用启动购买交易；

作为响应，获得确认该购买交易的处理的购买收据；

获得用于从用户设备导出购买收据的请求；

经在用户设备上执行的虚拟钱包应用，生成存储与购买收据相关的信息的数据结构；以及

响应于从用户设备导出购买收据的请求，提供该数据结构。

44.一种虚拟钱包收据管理装置，包括：

处理器；以及

存储器，布置成与处理器通信并且存储处理器可执行的指令，以便：

经在用户设备上执行的虚拟钱包应用启动购买交易；

作为响应，获得确认该购买交易的处理的购买收据；

获得用于从用户设备导出购买收据的请求；

经在用户设备上执行的虚拟钱包应用，生成存储与购买收据相关的信息的数据结构；以及

响应于从用户设备导出购买收据的请求，提供该数据结构。

45.一种处理器可读的有形介质，存储处理器可执行的虚拟钱包收据管理指令，以便：

经在用户设备上执行的虚拟钱包应用启动购买交易；

作为响应，获得确认该购买交易的处理的购买收据；

获得用于从用户设备导出购买收据的请求；

经在用户设备上执行的虚拟钱包应用，生成存储与购买收据相关的信息的数据结构；以及

响应于从用户设备导出购买收据的请求，提供该数据结构。

Images