用于获得并验证在线信息的系统、设备和方法

摘要

提供了一种获得并验证信息的系统和方法。该系统包括：处理器；以及包括指令的序列的存储器，所述指令的序列在由处理器执行时将处理器配置为执行该方法。该方法包括：从与数据的创建者相关联的数据源获得所述数据；规范化已获得的数据；由所述处理器确定数据的创建者的标识；基于标识和已获取的元数据对经规范化的数据进行分类；以及将经规范化的数据存储在存储器中。规范化已获得的数据包括：针对有意义的信息而解析已获得的数据；从已获得的数据中提取原数据；以及将已解析的信息映射到内部数据结构。

说明书

技术领域

本公开总体涉及获得并验证在线信息的系统、设备和方法。

背景技术

在过去的二十年期间，已经专利化和/或商用了若干软件和硬件技术，以帮助人们在互联网上搜索信息和进行零售购买。虽然这些技术已经使在线进行许多任务成为可能，但是其已经引入了一些新的挑战。存在用于在线搜索、社交网络连接和电子商务的少数的主要服务提供方。由于这些服务提供方的强大的影响力，在互联网上获得可信的信息可能通常是一种挑战。一些人可以利用由服务提供方提供的通信工具和渠道来影响人们的想法、动机和购买习惯。这些服务提供方中的一些已经受到对遏制假新闻的威胁做得不够的指责。

存在用于从与进行请求的用户有关的社交网络或亲近团体的成员请求或向其提供信息的系统。在其他系统中，评论引擎可以被连接到支持模块和数据库，所述支持模块和数据库基于主题和用户与评论的创建者的关系接收、存储和检索评论。在其他系统中，用户可以选择性地与其他用户分享与其购买有关的信息。在其他系统中，用户可以提供其在线购买的评论，以使其他用户可以在决定要购买什么物品或服务时考虑这些体验，或将其考虑为交换思想和意见的一部分。在其他系统中，计算机服务允许互联网用户定位和评估在线门户中所列出的产品，此时，用户接收基于用户的个人偏好信息的个性化的推荐。

在一些系统中，通用卡可以被用于存储若干卡的内容，并且可以在配备有磁条读取器或短距无线通信能力的任意终端处使用。在其他系统中，支付设备可以是与典型的信用卡或借记卡相同的外形尺寸，并且可以被编程有和被再编程有各种支付简档。在其他系统中，通用金融数据卡可以编译和存储涉及多个金融账户的金融交易记录。在其他系统中，设备可以存储，通过磁条模拟器使用或用作“虚拟的”无接触智能卡的来自多个智能卡的信息、和来自多个传统磁条卡的数据。

发明内容

根据实施例，提供了一种用于获得并验证信息的系统。该系统包括：处理器；以及包括指令的序列的存储器，指令的序列在由处理器执行时将处理器配置为执行获得并验证信息的方法。处理器被配置为：从与数据的创建者相关联的数据源获得数据；规范化已获得的数据；确定数据的创建者的标识；基于标识和已获得的元数据对经规范化的数据进行分类；以及存储经规范化的数据。为了规范化已获得的数据，处理器还被配置为：针对有意义的信息而解析已获得的数据；从已获得的数据中提取元数据；以及将已解析的信息映射到内部数据结构。

根据另一个实施例，提供了一种计算机实现的获得并验证信息的方法。该方法由处理器执行，并且包括：从与数据的创建者相关联的数据源获得数据；对已获得的数据进行规范化；由处理器确定数据的创建者的标识；基于标识和已获取的元数据对经规范化的数据进行分类；以及将经规范化的数据存储在存储器中。规范化已获得的数据包括：针对有意义的信息而解析已获得的数据；从已获得的数据中提取原数据；以及将已解析的信息映射到内部数据结构。

根据另一个实施例，提供了一种其上具有指令的非暂时性计算机可读存储介质，当指令由处理器执行时，执行获得并验证信息的方法。该方法包括：从与数据的创建者相关联的数据源获得数据；规范化已获得的数据；确定数据的创建者的标识；基于标识和已获取的元数据对经规范化的数据进行分类；以及将经规范化的数据存储在存储器中。规范化已获得的数据包括：针对有意义的信息而解析已获得的数据；从已获得的数据中提取原数据；以及将已解析的信息映射到内部数据结构。

在各个另外的方面中，本公开提供了对应的系统、设备和逻辑结构，例如，用于实现这样的系统、设备和方法的机器可执行的编码指令集合。

在这个方面，在详细说明至少一个实施例以前，要理解的是，所述实施例不被限制在应用在下面的说明书中阐述或在附图中示出的组件的构造和布置的细节。此外，应理解，本文使用的短语和术语用于描述目的而不应被视为限制。

关于本文描述的实施例的许多另外的特征及其组合在本领域普通技术人员阅读本公开以后将是明显的。

附图说明

将仅通过举例的方式参考附图来描述实施例，其中：

图1示出了根据一些实施例的用于获得并验证在线信息的系统的顶层架构的示例；

图2在示意图中示出了根据一些实施例的用于验证信息的平台的示例；

图3示出了根据一些实施例的使用机器与机器通信获得并验证信息的方法的示例；

图4在序列图中示出了根据一些实施例的在交易之后获得由销售方/服务提供方征求的评论数据(例如，客户评论)的方法的示例；

图5在序列图中示出了根据一些实施例的捕获未征求的评论的方法的示例；

图6在序列图中示出了根据一些实施例的执行评论查找的方法的示例；

图7在电子表格中示出了根据一些实施例的搜索请求的结果的示例；

图8A和图8B示出了根据一些实施例的用于评定医生的上下文相关的反馈表的示例；

图8C在流程图中示出了根据一些实施例的评定产品或服务的方法的示例；

图8D在流程图中示出了根据一些实施例的评定以前完成的评论的方法的示例；

图9在序列图中示出了根据一些实施例的生成上下文反馈表的方法的示例；

图10在示意图中示出了根据一些实施例的通用智能卡的示例；

图11A在示意图中示出了根据一些实施例的智能卡套件的示例；

图11B示出了根据一些实施例的智能卡套件/钱包显示器的示例；

图11C示出了根据一些实施例的智能钱包上的卡状态屏幕的示例；

图12在图像中示出了根据一些实施例的套件基座的示例；

图13示出了根据一些实施例的套件中的通用智能卡的示例；

图14示出了根据一些实施例的没有通用智能卡的套件的示例；

图15示出了根据一些实施例的被插入到套件且被解锁的通用智能卡的示例；

图16A和图16B示出了根据一些实施例的检查被存储在通用智能卡中的卡中的一个的购买历史的示例；

图17示出了根据一些实施例的POS设置的示例；

图18在序列图中示出了根据一些实施例的POS工作流程的示例；

图19、图19A和图19B示出了根据一些实施例的账单记录的示例；

图20在流程图中示出了根据一些实施例的获取评论的方法的示例；

图21A、图21B和图21C示出了根据一些实施例的分享消费者体验的示例；

图22A和图22B示出了根据一些实施例的根据销售方和根据时间的产品的搜索结果；

图23A示出了离线交易和在线交易的示例；

图23B示出了根据一些实施例的用于在线交易和离线交易的交易数据采集的示例；

图24A和图24B在序列图中示出了根据一些实施例的基于经变换的CTR的所有权(inverted ownership of CTR)的积分积分计划的工作流程的示例；

图25A至图25D在表中示出了根据一些实施例的交易细节的示例；以及

图26是诸如服务器之类的计算设备的示意图。

要理解的是，在整个说明书和附图中，类似的特征通过类似的附图标记指示。

具体实施方式

通过参考附图描述了方法、系统和装置的实施例。

本公开提供了用于改善在互联网上流通的假冒、无法验证和被操纵的信息的问题的解决方案。还提供了用于经由用户的朋友、家人和熟人的可信网络搜索和定位可信的信息的装置。本公开还提供了解决在钱包/钱夹中携带多个塑料卡的负担的解决方案，并且示出了卡交易细节可以被用于捕获评论/体验的方式。

要注意的是，出于隐私原因，已经在本文描述的示例中使用了假名称和其他细节。

在线搜索中的问题

许多业务和服务提供方在购买时或在完成交易时采集对其产品或服务的评论/反馈。评论可以在纸形式上采集，但是随着计算机化的不断增加，许多评论以电子方式采集。如果评论是在存在业务/服务提供方时采集的，则其可能是可验证的。然而，当在没有业务/服务提供方提交评论时，评论有时可能不是可信的。

每当进行购买时，一些电子商务站点就试图捕获客户反馈。然而，人们可以提交针对其还没有从该网站购买的产品的反馈。然而，所述反馈可以包括由其证书不可以被验证的人发布的评论。理想地，电子商务评论包含，将好/坏评论与产品中可获得的特定产品特征/能力相关联的信息。除了这些以外的信息通常被考虑为多余的和/或干扰。

在线搜索引擎和电子商务站点通常使用排名系统，以将信息提供给其用户。有时，这样的排名系统不能够从搜索索引中滤除噪声。搜索索引基于其内容的相关性存储web页面，并且基于这些页面的反向引用或反向链接的质量为其分配分数(例如，页面排名)。一些排名方案通过对页面的链接的数量和质量进行计数来确定网站被搜索的值的粗略估计来进行操作。具有较高排名的web页面被给定比具有较低排名的页面高的优先级，并且这个优先级反映以搜索结果的顺序反映。用户每次执行搜索时，搜索引擎通常列出许多搜索结果，并且确定所述搜索结果中的真实性的负担在于用户。通常，搜索引擎不做出关于web页的可信度的要求，并且没有强制实施可信度的机制。

考虑例如居住在美国纽约的用户的场景。当这个人寻找纽约市的骨科医生时，搜索引擎可以提供包括均具有对医生进行分级的系统的若干卫生保健门户的搜索结果。所有这些门户都可以示出与使用医生的姓名注册的医生的姓名相对应的评论，但是这些门户却不验证评论者的证书，并且不遵守用于捕获患者反馈的任何标准的度量。这对于医生以及患者可能都是问题。当评估要咨询的医生时，患者不能够获得在不同的门户上适用的医生的评定，因为每个门户将不同的参数用于评定医生。例如，门户“A”允许患者在八个参数(易于预约、及时、礼貌的员工、准确的诊断、医疗服务态度、对我花时间、随访后跟进、平均等待)上评定医生。作为比较，门户“B”允许患者仅在三个参数(总体评定、医疗服务态度和等待时间)上评定医生。这个系统用于医生时也产生了问题，因为在使用较多参数的门户(门户“A”)处可能提供比使用较少参数的门户(门户“B”)较低的评定。如果医生使用两个门户接受预约，那么医生可能不能够改变评定。

因此，使用搜索引擎来查找医生(或其他服务、产品或信息)就可能有问题。因为搜索引擎通常不做出关于其搜索结果的可信度的要求，所以如果基于在卫生保健门户中的任一个上示出的评定来选择医生，则用户冒着选择具有不确定的技能的医生的风险。例如，在卫生保健门户中的一个处的样子示出下面的问题：

a)评论不包含全部的患者姓名；

b)评论未以倒序方式连贯地列出；

c)一些医生评论已经丢失了一整年的评论，暗示该医生一整年都没有出诊；以及

d)评论不包含具体日期(即，评论被列为“不到一年以前”或“超过一年以前”)。

此外，可能是冒充客户的内部员工或营销专家写了许多评论。对于其他产品、服务或信息的搜索也出现类似的问题。

当评论被锁定在网站所有者的存储库中时，在互联网上查找可信的信息也是很困难的。如果一个人在五个不同的门户处提交评论，那么可能没有用于将由这个人发布的所有的评论合并，从而这些评论可用于这个人的社交网络的框架。

用于获得并验证用户提交的数据的方法和系统

移动设备为用户提供用于捕获对产品、业务和服务提供方的经认证的评论和体验的方便的选择。在本文描述了系统架构、平台和方法，其中，可以获取用于例如上面的场景的搜索结果，其将基于通过闭环评论捕获的关于医生的信息列出医生。如果这些评论来自用户的社交网络，那么该用户也将能够看见评论者的个人数据。然而，如果评论来自不相关的用户，那么该用户将看见已经经由闭环评论可信地测量的匿名排名，如将在下面进一步讨论地。要理解的是，所提出的解决方案可以被应用到在互联网上宣扬的其他服务、产品和信息。

图1示出了根据一些实施例的用于获得并验证在线信息的系统100的顶层架构的示例。系统100的结构被组织在四个部分中：获取部110、规范化120、运行/操作130和储存设备140。系统100表示典型的搜索引擎，其使用一种机制：获得数据(例如，搜索串)，对数据执行验证检查，发起将数据进行匹配的查找，并且存储用于完成用户请求所需要的数据。

图1示出了数据可以经由各种数据源110获得，包括：支付体111；无线设备112；直接输入，包括电话号码113、名片114；快速响应码115；或电子邮件(email)/统一资源定位符(URL)链接116。这些数据源110的范围是说明性的并且不被限制为本文描述的设备/机制。可以使用其他数据源110。例如，无线数据源可以是任意无线设备112，例如，部署在医生的诊所/餐馆/零售店中的蓝牙/WiFi发射机、经由近场通信(NFC)将支付信息传送到读卡器的智能电话或将无线电信号用于通信的任意其他设备。要理解的是，可以将接收、获取或输入信息的任意电子装置用于获得信息。数据获取装置可以被通信地耦接到数据验证系统或平台的数据获取单元或应用编程接口(API)。

通过这些源获得的数据可以在处理以前被规范化122。硬件和软件销售方通常将专有技术用于数据存储和传输。虽然系统100提供了用于将信息直接获得到其数据结构中的装置，但是有时可能需要处理与其自身的模式明显不同的数据。在规范化122中，通过不同的数据源110实现的数据可以针对所需要/希望的信息进行解析，并且可以提取任意元数据以检查属于所述数据的属性。有关的信息可以随后被映射到内部数据结构，并且最终被存储在数据存储(例如，数据储存设备)140中。内部数据结构的示例是具有字段的记录。要理解的是，可以使用其他数据结构，以能够以一致的方式检索和存储数据。

在机器与机器(M2M)通信期间可以进行规范化。这个的示例是当在客户和销售点(POS)终端之间发生交易时。一旦客户做出支付，交易记录就可以通过POS终端被传送到系统100。一些销售方的交易记录可以包含元数据，例如，库存单位(SKU)码；或行业标准产品标识符，例如，通用产品码(UPC)/国际标准图书编号(ISBN)，其可以帮助在将信息存储在数据存储140中以前对交易记录进行分类。系统100可以连接到UPC/EAN/ASIN/ISBN数据库145以提取关于UPC/ISBN码的信息，或者与销售方/服务提供方ERP 144接口连接以提取已购买的项目/服务类别的属性。已提取的属性可以与标识符相关联，并且与经规范化的数据一起被存储在数据存储140中。在其他实施例中，交易记录可以不包含任何码或标识符，并且由系统100使用数据提取技术和机器学习对内容进行解密。一旦系统100接收交易记录，系统上的守护程序就可以读取交易的内容(即，获得数据)，解析数据，并且在将数据存储在数据存储140中以前，将有关的信息映射到内部数据结构(即，对其进行规范化)。

在一些实施例中，评论表可以是经高速缓存的表，以减少计算开销。例如，反馈表可以不必在做出用于捕获评论的每次请求时生成。在规范化期间，如果系统100发现内容已经被分类，并且数据存储140已经高速缓存了反馈表的副本，那么系统100可以将反馈表的经高速缓存的副本提供给用户。

一旦获得数据，其就可以被用于记录购买交易131，执行查找132以检索由用户请求的信息或以动态地生成上下文相关的表，以捕获用户的评论/体验133。为了发起查找132或生成上下文有关的表133，搜索引擎可以引用包括以下项在内的数据存储140中的一个或许多：交易数据库141、评论数据库142、电话本存储库143、企业资源规划(ERP)系统144、通用产品码(UPC)/欧洲商品编号(EAN)/亚马逊标准识别号(ASIN)/国际标准图书编号(ISBN)数据库145、关键字索引146、属性索引147和可信网络148。经检索的数据可以进行处理134并且被返回到用户作为搜索结果135。可以在其他实施例中执行用于数据的其他处理。要理解的是，可以在其他实施例中使用其他数据库或数据储库。

图2在示意图中示出了根据一些实施例的用于获得并验证信息的平台200的示例。平台200可以是经由网络240(或多个网络)连接到接口应用230和数据源110的电子设备。平台200可以实现本文描述的用于获得并验证信息的过程的方面。

平台200可以包括处理器204和存储用于配置处理器204以(例如，从数据源110)接收数据的机器可执行指令的存储器220。平台200可以被实现在电子设备上，并且可以包括输入/输出(I/O)单元202、通信接口206和数据储存器210。处理器204可以执行存储器220中的指令以实现本文描述的处理的方面。平台200可以经由I/O单元202接收和传送来自这些存储器中的一个或多个的数据。当接收到数据时，I/O单元202将数据传送到处理器204。

I/O单元202可以使平台200能够与一个或多个输入设备(例如，键盘、鼠标、相机、触摸屏和麦克风)和/或与一个或多个输出设备(例如，显示屏和扬声器)互连。

处理器204可以是例如任意类型的通用处理器或微控制器、数字信号处理(DSP)处理器、集成电路、现场可编程门阵列(FPGA)、可重配置处理器或其任意组合。

数据储存器210可以包括存储器220、数据库140和永久储存器214。例如，存储器220可以包括位于内部或外部的任意类型的计算机存储器的合适的组合，例如，随机存取存储器(RAM)、只读存储器(ROM)、光盘只读存储器(CDROM)、电光存储器、磁光存储器、可擦除可编程只读存储器(EPROM)和电可擦除可编程只读存储器(EEPROM)、铁电RAM(FRAM)等。数据储存器设备210可以包括存储器220、数据库140和永久储存器214。

通信接口206可以使平台200能够与其他组件通信，以与其他组件交换数据、以接入和连接到网络资源、以服务于应用，并且通过连接到能够承载数据的网络(或多个网络)执行其他计算应用，所述网络包括互联网、以太网、普通老式电话服务(POTS)线、公共交换电话网(PSTN)、集成服务数字网(ISDN)、数字订户线(DSL)、同轴电缆、光纤、卫星、移动、无线(例如，Wi-Fi、WiMAX、LTE)、SS7信令网络、固定线路、局域网、广域网等，并且包括这些的任意组合。

平台200可以可操作地在提供对应用、局域网、网络资源、其他网络和网络安全设备的访问以前注册和认证用户(例如，使用登录、唯一标识符和密码)。平台200可以连接到不同的机器或实体。

数据储存器210可以被配置为存储与平台200相关联的由其获取或创建的信息。储存器210和/或永久储存器214可以使用各种类型的存储技术(例如，固态驱动器、硬盘驱动器、闪存)来提供，并且可以以各种格式(例如，关系数据库、非关系数据库、平面文件、电子表格、扩展标记(XML)文件等)存储。

存储器220可以包括：用于从数据源110获得数据的数据获取单元221、用于规范化已获得的数据的规范化单元120、用于执行针对经规范化的数据的操作的操作单元130、用于生成在获得信息或评论数据中使用的表的评论引擎222、以及一个或多个机器学习库224。将在下面更详细地描述单元221、单元120、单元130、单元222和单元224。

图3示出了根据一些实施例的使用机器与机器(M2M)通信获得并验证信息的方法300。方法300包括：从数据源获得302数据、解析304已获得的数据、映射306已解析的数据、(例如，通过检查数据的属性)确定308数据源的标识、基于数据源对经规范化的数据进行分类310、以及存储312经规范化的数据。解析304和映射306的步骤包括对数据进行规范化。确定308数据源的标识的步骤可以包括确定提供数据的评论者或人的标识。这样的确定将允许基于源的已获得的数据的分类310。例如，如果数据源来自可信的源(例如，家庭成员、熟人、公认的专家、公认的有声誉的提供方等)，那么已获得的数据可以与表示高的信任级别的值相关联。如果数据源来自匿名、不可信或不确定的源，那么已获得的数据可以是与表示较低的信任级别的值相关联。下文中将更详细地描述数据的这种分类。其他步骤可以被添加到方法300并且将在下面更详细地描述方法300。

在一些实施例中，已获得的数据可以包括交易数据细节和/或与交易、产品、项目、服务和/或主题相关联的评论选项细节。已获得的数据可以是在交易之后所征求的、在交易之后未征求的或无(即，没有)任意交易且未征求的。

所征求的评论

图4在序列图中示出了根据一些实施例的在交易之后获得由销售方/服务提供方征求的评论数据的方法400的示例。方法400属于在交易之后由商家(经由具有定制参数的联名表)所请求的所征求的评论的示例。方法400从设备10(例如，移动电话)从用户接收包括业务/产品/服务评论的输入402开始。接着，设备10向评论引擎222发送插入数据消息404。消息404可以包括作为功能调用变量的与被评论的业务相关联的电话号码、评论细节和外键(foreign key)(FK)。接着，评论引擎222可以向设备10发送输入密码/一次性密码(OTP)消息406。设备可以为用户显示要输入密码/OTP的提示408，当密码为空或不正确时，允许用户重新输入密码/OTP。当设备接收到具有正确密码的输入时，则向评论引擎222发送410密码。评论引擎222确认密码正确并且向评论数据库142发送提交数据消息412。提交数据消息412可以包括作为功能调用变量的与被评论的业务相关联的电话号码、评论细节和FK。接着，评论引擎222可以向电话本存储库143发送更新数据414消息。接着，评论引擎222可以向设备10发送评论提交消息416，以确认评论已经被接收到并且被提交。

未征求的评论

图5在序列图中示出了根据一些实施例的捕获未征求的评论的方法的示例500。方法500包括根据一些实施例的两个使用情况：(a)用户提交业务交易510之后的未征求的评论的示例；以及(b)用户提交无任何业务交易520的未征求的评论的示例。要理解的是，方法500可以实现510或520中的一个。

在第一种情况510中，该方法从设备10从用户接收打开记录消息512开始。消息512可以包括作为变量的交易记录。然后设备10可以向评论引擎222发送得到反馈表消息518。接着，评论引擎222可以返回519反馈表。该反馈表可以是上下文相关的反馈表，并且消息519可以包括作为变量的业务名称和/或电话号码以及FK。

在第二种情况520中，该方法从设备10从用户接收输入关键字命令522开始。该输入可以包括作为变量的业务名称和/或业务电话号码。然后设备10可以向评论引擎222发送得到数据消息524。消息524可以包括作为变量的业务名称和/或电话号码。评论引擎222将这个请求525转发到向设备10返回526业务/服务提供方的名称、地址、电话号码和外键(FK)的电话本存储库143。接着，设备可以向评论引擎222发送得到反馈表消息528。接着，评论引擎222可以返回529反馈表。该反馈表可以是上下文相关的反馈表，并且消息529可以包括作为变量的业务名称和/或电话号码以及FK。

一旦设备10具有表519、表529，设备就可以从用户接收与业务/产品/服务评论相对应的输入402。设备10可以经由，可以包括作为变量的业务电话号码、评论细节和FK的插入数据消息404向评论引擎222发送评论。接着，评论引擎222可以向设备10发送输入密码/一次性密码(OTP)消息406。设备可以为用户显示要输入密码/OTP的提示408，当密码为空或不正确时，允许用户重新输入密码/OTP。当设备接收到具有正确密码的输入时，则向评论引擎222发送410密码。评论引擎222确认密码正确并且向评论数据库142发送提交数据消息412。提交数据消息412可以包括作为功能调用变量的与被评论的业务相关联的电话号码、评论细节和FK。然后，评论引擎222可以向电话本存储库143发送更新数据414消息。接着，评论引擎222可以向设备10发送评论提交消息416，以确认评论已经被接收到并且被提交。

评论查找

图6在序列图中示出了根据一些实施例的评论查找600的方法的示例。方法600从设备10从用户接收请求针对业务的评论的输入602开始。业务名称和/或电话号码可以作为功能调用变量提供。接着，设备10可以向评论引擎222发送得到评论消息604。消息604可以包括作为功能调用变量的业务名称和/或电话号码。接着，评论引擎222可以向电话本存储库143发送得到数据消息606以获取评论被请求的业务的标识符。接着，电话本存储库143可以向评论引擎222发送返回数据消息608。返回数据消息608可以包括业务名称、地址、电话号码和外键(FK)。接着，评论引擎222可以向评论数据库142发送得到评定消息610。得到评定消息610可以包括作为功能调用变量的FK。接着，评论数据库142可以向评论引擎222发送返回消息612。这个消息612包括评定。接着，评论引擎222向设备10发送返回评论消息614，然后设备10为用户显示它616。评论消息614可以包括：包括名称、地址、电话号码和评定的属于业务的评论数据。

所征求的评论、未征求的评论和评论查找的使用情况

将参考图4、图5和图6来描述系统100及其方法的使用的示例。图4和图5包括系统100可以获得并验证信息300的示例。演示了其中人具有可以用于以下项的智能电话的使用情况：a)提交所征求的评论400，b)提交未征求的评论500，以及c)查找评论600。智能电话和呼叫方ID应用可以被用于提供用于减少假在线评论的解决方案。一般的智能电话都具有用于从许多不同的源(位置坐标、信标发射机、POS设备)捕获上下文的传感器(GPS、WiFi、蓝牙)。在智能电话上运行的呼叫方ID应用可以使用从智能电话传感器捕获的上下文数据，并且将其与来自电话本存储库的信息进行配对，以创建可以很容易地捕获真正的用户评论的短的动态的反馈表。

针对图4，提供了通过移动设备提交业务/服务提供方所征求的评论400的示例。考虑用户与配偶和两个孩子正在加拿大的惠斯勒的滑雪度假圣地度假的场景。除了他们发现食物有些不适合他们挑剔的味觉之外，用户在该度假圣地住得很愉快。当用户结账离开该度假圣地时，用户在用户的移动电话上接收到短的反馈表，请求该用户分享其体验。该滑雪度假圣地使用系统100来管理其客户评论，由此已经为该度假圣地设计了经定制的反馈表，并且系统100代表该度假圣地捕获所有的评论。评论被显示在该度假圣地的网站和该度假圣地想要显示其评论的任意其他门户上。

在一些实施例中，可以利用系统100注册业务。当新的业务被注册时，系统100从电话本存储库143请求用于该业务的外键(FK)。如果存储库143已经有业务记录，则其提供该FK。如果没有，那么存储库143创建新的业务记录，并且向系统100提供该记录的FK。系统100捕获针对该FK的业务评论，然后使数据与储库143一致。

该用户捕获其反馈表上的评论，并且点击表上的提交按钮，其向评论引擎222上的系统评论API发送302该用户的评论。评论API暂时地高速缓存用户的评论，并且向该用户发送密码/OTP，以验证308用户的身份。当用户输入正确的密码/OTP时，针对该度假圣地的电话号码以及针对用户的电话号码的评论被记录312在系统评论数据库142中。然后该应用通过在电话本存储库143API中进行查找，使该度假圣地的业务地址和电话号码与该API一致。

针对图5，提供了通过移动设备提交业务/服务提供方未征求的500评论的示例。考虑用户将他的汽车交给BC温哥华的汽车修理店维修的场景。该用户通过互联网搜索引擎发现该业务，并且甚至在该用户没有发现包含该公司的评定/评论的该公司的任何业务页面时就将汽车送去维修。当该用户从汽车修理店取回汽车时，账单比估计值多了50美元。该用户与修理店主交谈，在简短的讨论以后对车辆维修进行支付。在驾驶该车辆几天以后，该用户发现齿轮系统中的噪声又出现了。该用户将该车辆送回该修理店，并且在简短的检查以后被告知齿轮系统中的部件中的一个已经磨损。为了修理该车辆，该用户需要支付250美元来更换该部件。因为自该车辆在该修理店维修仅仅过了几天，所以该修理店免除人工费。该用户支付了250美元并且驾车回家。该用户在该车辆修理店具有很差的体验，并且为了朋友和家庭成员的利益想要书写业务的评论。

在一些实施例中，该用户打开系统100应用10并且输入522修理店的名称或电话号码。然后该用户点击向评论引擎222发送524包含业务名称和/或电话号码的′GET(得到)′查询的提交按钮。评论引擎222将这个请求525转发到向应用10返回526业务/服务提供方的名称、地址电话号码和外键的电话本存储库143。应用10使用这个信息来从系统评论引擎222请求528反馈表。评论引擎222动态地生成在上下文上适当的反馈表并且将其发送529给用户。该用户捕获其在反馈表上的评论，并且点击表上的向系统100评论引擎222发送404评论的提交按钮。评论引擎222暂时地高速缓存评论，并且向用户发送406、408密码/OTP以验证其身份。当该用户输入正确的密码/OTP410时，针对维修店的电话号码的评论被记录412在系统评论数据库142，并且在该数据库142中还有针对用户的电话号码。

在一些实施例中，用户的反馈对于具有用户的姓名的其朋友和家庭的可信网络可见，但是对于一般公众进行截短/匿名化显示，以防止任何来自业务/服务提供方的强烈拒绝。如果用户的可信网络中的任何人在移动应用中查看餐馆的评论，那么其将发现与该业务的电话号码相链接且也与该用户的电话号码相链接的评论。这个反馈采集的方法被称为闭环评论，并且可以帮助很容易地选择优质的服务提供方，而不是在每次选择服务提供方时都在冒险。被映射到电话号码的评论也可能更难以伪造，因为只有电话运营商可以发布针对有效身份证明(护照、社会保险号、选举人ID)的电话连接。

闭环评论可以被设置为双方询问或三方询问。在双方询问中，客户/用户给出反馈，并且业务/服务提供方通过确认针对客户/用户的货币交易验证评论。在一些实施例中，客户还可以提供可能已经在别处使用的产品(例如，书、电子装置)的评论。在这样的情况下，在记录其评论以前验证客户/用户可能容易被误报。一些电子商务公司利用这个模型操作其在线业务，因此，必须处理误报的问题。在三方询问中，客户给出反馈，并且该反馈被发送到具有验证反馈的能力的第三方。一旦第三方验证了评论，就将该反馈与将该评论并入其网站的业务/服务提供方共享。一些公司利用这个模型，通过与评论公司的合伙关系操作其业务评论。大多数业务/服务提供方的评论可以作为双方询问来建立。在一些实施例中，例如，类似医学的服务可以作为三方询问来建立，以保护医生免受带有偏见的评论。

针对图6，提供了在移动设备上查找业务/服务提供方的评论600的示例。例如，用户打开移动应用10并且输入602业务/服务提供方的名称或电话号码。然后该用户点击向评论引擎222发送604包含业务名称和/或电话号码在内的′GET′查询的提交按钮。评论引擎222将这个请求转发606到向评论引擎222返回608业务/服务提供方的外键(FK)、名称、电话、地址和工作时间的电话本存储库143。然后评论引擎222向系统评论数据库142发送包含FK的′GET′查询610，并且接收612业务/服务概述、专长、评定、意见和FK。然后评论引擎222可以在从电话本存储库143和系统评论数据库142接收的数据上执行′JOIN(联合)′，并且生成包括名称、电话、地址、工作时间、业务/服务概述、专长、评定、意见在内的结果。业务/服务提供方评论在移动设备上被示出为姓名、电话、地址、工作时间、业务/服务概述、专长、评定和意见。

基于经验证的数据的在线搜索

图7在电子表格中示出了根据一些实施例的针对在线评论的搜索结果700的示例。在这个示例中，搜索结果700针对纽约的整形外科医生。搜索结果700采用列来示出关键字702搜索查询：医生图像704、对应的医生姓名706、针对每个医生的总排名(或总分数)708、用于评论医生的过滤选项710、作为通过评论提供的排名的社会排名712、每个评论者姓名714、评论者与请求搜索结果700的用户的关系716、用于评论医生的评定选项718、以及用于评定选项718的在最低为1和最高为5的5分制上的值720。然后用户可以基于总排名708、优选的评论者的社会排名712、针对特定特征718的评定值720或其组合选择医生。

总排名708可以基于社会排名712。社会排名基于由每个评论者针对评定选项718评定的值720。在一些实施例中，如图所示，除非评论者与寻找评论的人在预先确定的关系水平内，否则评论名称可以被部分或完全屏蔽。此外，可以在搜索结果中显示较少的或不同的项目。要理解的是，所示出的过滤选项710和评定选项718仅是示例性的，并且其他选项可以被用于其他评论。在一些实施例中，与针对产品或服务的评论相关联的总排名708、社会排名712和/或评定值720可以基于没有接收到正式评论的产品的重复购买或与同一业务/服务提供方合作而进行调整。属于这样的默认评论值的值可以被设置为与可用于产品或服务的评论的值选项的范围有关的值。

如上所述，在系统100中，人的评论/体验不被记录在搜索索引中并且不被给定足够的权重，直到经由询问/密码进行验证并且同时直到提交者的可信度已经建立为止。在一些实施例中，由系统100使用的方法与典型的搜索引擎排名算法正交。虽然搜索引擎可以基于其反向引用的质量对web页面进行排名，但是所提出的解决方案将基于其已经从普通民众和从主题专家收到的支持的数量，对web页面/URL或在线信息的任何其他源进行排名。来自普通人的支持在本文可以被称为人们的声音(VOP)，并且来自主题专家的支持在本文可以被称为专家的声音(VOX)。在一些实施例中，总系统页面排名(VIC)可以从以下得出：a)赞成和拒绝之间的数学关系；以及b)VOP和VOX排名之间的数学关系。

在一些实施例中，总分数可以包括主题专家平均分数和普通人平均分数的组合。在一些实施例中，用于确定主题专家平均分数的主题专家累积分数可以被保持在评论数据库142中。在一些实施例中，用于确定个人平均分数的累积平均个人分数可以被保持在评论数据库142中。在一些实施例中，评论引擎222可以确定创建者是主题专家，将主题专家分数分配给经规范化的数据，并且存储主题专家分数和经规范化的数据。在一些实施例中，评论引擎222可以确定创建者是普通人，将普通人分数分配给经规范化的数据，并且存储普通人分数和经规范化的数据。

在一些实施例中，例如，系统100可以基于已经用心地详细检查和测量的用户的技能和能力、并且也基于诸如以下之类的其他各种参数，将用户分级为VOP和VOX：

1、该用户对产品的多少关键参数进行了评分？

2、已经给出评定的人的背景？这个人已经向我们提供了关于其自身的多少信息？多少信息已经被发现是可信的？例如，如果给出评定的这个人是合格的电子工程师，并且他已经发表了研究论文、撰写的专利，已经作为产品开发工程师在有声誉的消费电子公司工作过，那么这个人针对消费电子产品的评定将具有相当大的价值。

3、这个人已经提交了多少评论？评论的数量越多并且评论越多样化(跨产品类别)表明该评论者是真的。

4、由这个人提交的多少评论被支持？这个人和已支持其评论的人们之间的关系是什么？来自有关的人(朋友、家庭、熟人)的支持将比来自不相关的人们的支持具有更少的价值。

5、由这个人提交的评论中有多少被拒绝/负面评价？这个人和已经拒绝/负面评价其评论的人们之间的关系？

以上参数作为示例提供。要理解的是，可以使用更多、更少或其他参数。

在一些实施例中，用户可以利用平台200创建账户。当用户在平台200上创建账户时，他/她可以被分配″VOP″用户的状态。当″VOP′′用户提供其技能和学识的证据时，其可以被升级到″VOX″用户。在一些实施例中，系统200可以为VOP用户提供，用于经由来自其他VOP或VOX用户的支持、进行测量其技能和学识的在线考试、以及其他这样的动作来采集奖章的机会。在一些实施例中，VOP用户可以在平台200内以及从(affiliates)采集用于其技能的奖章。例如，计算机程序员可以经由软件开发者讨论编程问题的服务提供方设备采集奖章。一旦VOP用户已经获得了足够的奖章，那么其可以转变为VOX用户。如上面提到的，VOX用户是主题专家。在一些实施例中，VOX用户可以在滑动制(例如，级别1至级别5)上进一步分级。

在一些实施例中，与评论者可以被归类并且其评论可以被验证一样，评论的评定或评价的提供者也可以如此。例如，评论的评定的提供方可以是普通人或主题专家。评论引擎222可以从第三方接收评论的评价，向与第三方相关联的客户设备发送用于确认第三方的标识的验证消息，从与第三方相关联的客户设备接收确认第三方的标识的响应消息，并且基于响应消息将具有评论细节的电子反馈表与该评价相关联。在一些实施例中，被丢弃的评论可以降低该评论的总分数。在一些实施例中，被丢弃的评论的数量可以降低评论者分数。

将用户区分为VOP和VOX(并且在其他实施例中区分为其他的用户类别)允许从VOP和VOX接收的赞成/拒绝之间的数学关系得出内部总系统排名(VIC)。在一些实施例中，VOX用户的评分可以比VOP用户的评分具有更高的权重。此外，更高级别的VOP(或VOX)用户的评分可以比较低级别的VOP(或VOX)用户的评分高。

上下文相关的反馈表

在一些实施例中，系统100使用上下文相关的反馈表。上下文相关的反馈表被示意性地链接到被评论的主题。考虑电子商务站点征求经由其门户购买的任意产品的评论的场景。该站点可以提供不包括用户可以选择的字段/参数的空白反馈表。电子商务站点可以捕获采用自由文本的用户评论，因此，所捕获的信息可能不适于进行搜索。作为比较，如将在下面进一步描述的，系统100表可以是上下文有关的。

在一些实施例中，系统100评论表可以具有一定数量的(例如，五个)参数，当用户选择/点击门户/用户界面上的评论按钮时其将被自动(automagically)发现。在一些实施例中，这些参数可以包括评定选项718或以其他方式与其相关联。图8A和图8B示出了根据一些实施例的用于评定医生的上下文相关的反馈表的示例。在这个示例中，该反馈表具有测量医生的能力的五个参数810：诊断、治疗、医疗服务态度、随访、以及有礼貌。

用于捕获针对餐馆的反馈的类似的表可以具有不同的参数，例如：

1、食物如何？

2、服务准时吗？

3、环境如何？

4、您知道花了多少钱吗？

5、您有地方停车吗？

要理解的是，可以针对相同或不同类型的业务、产品、服务或项目的不同的评论使用更少的或其他的参数。

图8A和图8B中的图示示出了用户可以如何经由移动电话800或经由智能卡套件1100(将在下面更详细地描述套件1100)提交其评论的示例。图8A和图8B所示的示例的反馈表可以在用户选择评论卫生保健提供方时通过评论引擎222生成。

图8C在流程图中示出了根据一些实施例的评定产品或服务的方法850的示例。方法850包括获取852产品或服务的评论、以及确定854用于产品或服务的评定分数。评定分数可以基于以下项中的至少一个来确定：所述评论中已经被评估的参数的列表、来自普通人的正面的被评定的参数的数量、来自普通人的负面的被评定的参数的数量、来自主题专家的正面的被评定的参数的数量、和/或来自主题专家的负面的被评定的参数的数量。所述参数可以在逻辑上与产品或服务的类型相关联。所述分数可以基于以下项中的至少一个来确定：评论中已经被评分的参数的数量、评论表的评论者的背景、评论者提交的评论的数量、评论者提交的已经被认可的评论的数量、评论者提交的已经被拒绝的评论的数量、评论者以前提交的错误的评论的数量，和/或如果所述产品或服务已经接收到负面评定，则确定负面评定是否是在由提供方提供的不同类别的产品或服务上反映的。

图8D在流程图中示出了根据一些实施例的评定以前完成的评论的方法860的示例。方法860包括：向与评价者相关联的设备发送862包括多个已选择的评论参数在内的已完成的评论；从与评价者相关联的设备接收864经评价的具有评论细节的评论表；以及基于评价确定866用于所述评论的分数。

在一个方面，评论者的背景可以包括普通人、主题专家和/或假评论者中的一个。在一个方面，评论者的背景被确定为是假评论者，并且该评论被丢弃。在一个方面，评论者的背景被确定为是主题专家，并且该评论的评定通过第一因子被提升。在一个方面，评论者的背景被确定为是普通人，并且该评论的评定通过第二因子被提升。

其他步骤可以是被添加到方法860，例如，其他步骤为获取所述产品或服务的类型、选择与所述产品或服务的类型相关联的参数、和/或利用逻辑上与所述产品或服务的类型相关联的参数自动填充所述评论表。在一个方面，方法860还包括为评论者提供用于改变所述评论表中的参数的选项。

评论可以是正面评价(例如，经由“拇指向上”选择)或负面评价(例如，经由“拇指向下”选择)。当评论接收到“拇指向上”或“拇指向下”选择时，评论引擎222可以确定给予赞成/拒绝的人的简档。这个人与原始评论的联系也可以被确定。如果支持是来自联系/家庭成员，则联系/家庭成员的完整性也可以被确定。

正如利用评论一样，评价评论的一些人也可能试图与系统博弈。总系统排名(VIC)以及VOP和VOX分数可能在事情的计划中受影响。如果一个人被确定为进行破坏，则其在系统100中的排名可以被调整，以使其评论不具有与诚实的评论者或评价者相同的权重。

图9在序列图中示出了根据一些实施例的生成上下文反馈表900的方法的示例。方法900包括根据一些实施例的两个使用情况：(a)用户经由默认参数925提交评论的示例；以及(b)用户经由定制参数950提交评论的示例。要理解的是，方法900可以实现925或950中的一个。

方法900从设备10从用户接收输入902开始。该输入可以包括作为变量的交易记录或业务名称和/或业务电话号码。然后设备10向评论引擎222发送选择消息904。选择消息904可以包括交易记录或业务名称和/或电话号码的外键(FK)。然后评论引擎222在其数据存储140中查找906与交易发票相匹配的属性。接着，数据存储140返回与发票相匹配的属性908，然后评论引擎222发送包含作为参数的属性908的得到请求910，以接收与属性相匹配的关键字。接着，数据存储140返回与发票相匹配的关键字912。然后评论引擎222对机器学习库224发起请求914、924，以得到与关键字相对应的参数。可以通过其正在发现的信息重复进行修改的机器学习库224提取(pulled out)916、926与卫生保健提供方相对应的参数。然后评论引擎222生成918、928图8A和图8B所示的反馈表，并且请求提交其评论。该用户可以选择利用默认的五个参数(使用情况925)捕获其评论920、930或定义其自身的参数(使用情况950)。

在一些实施例中，评论引擎222知道一些用户在其领域更有学识；因此其222可以允许用户定义用户自己的参数。如果用户选择利用默认参数920继续，则评论引擎222将评论记录922在数据存储140中。如果用户选择定制参数930，则评论引擎222接受评论并且向机器学习库224提交932陔信息。机器学习库224保持机器学习库224经由用户交互发现的全部的信息。当机器学习库224发现用户选择定义在语义上彼此相关的参数时，机器学习库224修改其查找表。接着，评论引擎222可以向数据存储140的电话本存储库143发送更新数据消息934。

如上面提到的，机器学习库224可以基于用户交互来调整上下文反馈表。在一些实施例中，评定选项718的默认数量可以在上下文反馈表上提供给用户。然而，可以只有以默认数量提供的可能的评定选项的子集。机器学习库224可以注意到一数量的VOP评论者或VOX评论者请求针对默认设置的改变。然后机器学习库224可以更新默认设置以反映所做出的选择。在一些实施例中，一数量的VOP评论者或VOX评论者可能需要在进行默认设置之前请求相同的改变。在一些实施例中，在进行针对默认设置的改变以前所观察到的VOX用户的数量可以低于VOP用户的数量。在一些实施例中，每个VOP或VOX评论者可以被分配一个权重值。当请求针对反馈表的改变时，可以追踪评论者的累积的权重值分数改变。一旦达到阈值，那么机器学习库224就可以相应地修改默认反馈表评定选项。要理解的是，可能存在具有不同的权重值的更多类别的评论者。要理解的是，其他机器学习技术也可以被用于评估何时对默认反馈表评定选项进行改变。

针对图9，提供了生成反馈表的示例。现在将参考图9扩展上面描述的卫生保健使用情况示例。当用户看完医生以后，用户选择系统门户/用户界面上的评论按钮。该用户不得不为其健康状况进行部分支付，因为保险不完全覆盖该治疗。在用户经由信用卡进行支付之后，该用户接收到包含医生的姓名、业务地址和电话号码在内的交易发票。该用户没有立即记录评论；而是在几个星期之后，用户确信医生的治疗减轻了医疗状况时。

当用户打开交易902并且对照医生的发票904选择评论按钮时，评论引擎222在其数据存储140中寻找906与交易发票相匹配的属性。数据存储140返回908与发票相匹配的属性，然后评论引擎222寻找910与属性相匹配的关键字。数据存储140返回912与发票相匹配的关键字。然后评论引擎222对机器学习库224发起914、924请求以得到与关键字相对应的参数。可以通过其正在发现的信息重复进行修改的机器学习库224，提取916、926与卫生保健提供方相对应的参数。然后评论引擎222生成图8A所示的918、928反馈表并且请求用户提交卫生保健提供方的评论。该用户可以选择采用默认的五个参数925捕获其评论或定义其自己的参数950。评论引擎222可以允许用户定义评论引擎222自身的参数。如果用户选择利用默认参数920继续，则评论引擎222将用户的评论记录924在数据存储140中。如果用户定义930参数，则评论引擎222在(例如，经由更新934)将用户的评论记录在数据存储140中之前接受评论并且向机器学习库224提交932信息。机器学习库224保持机器学习库224经由用户交互发现的全部的信息。当机器学习库224发现一数量的用户正在选择定义在语义上彼此相关的参数时，机器学习库224可以修改其查找表。

评论引擎222和机器学习库224一起工作以经由评论收集最有关的信息。因此，当评论引擎222检测到提交者对销售方/服务提供方的以前的评论时，评论引擎222可以提供用于捕获评论的不同参数的选择。这也有益于销售方/服务提供方，因为销售方/服务提供方可以收集尽可能多的反馈。该框架允许销售方/服务提供方在改进评论引擎222和机器学习库224上与系统100协作。

智能钱包

信用卡可以被用于捕获货币交易的细节以及发起购买交易。当一个人经由信用卡进行支付时，他/她可以从销售点(POS)接收到表示以下的两个打印记录：借记给这个人的该交易的合并记录、以及示出所购买的项目/服务的记录。在购买交易期间，购买的记录无需被打印出来，并且可以被替代地记录到信用卡/智能卡中或记录到持卡人的在线数据库的账户中。购买交易的电子副本可以帮助卡用户完成许多事情，包括捕获其对于他/她购买的不同的产品和服务的体验、以及随后利用社交网络分享这些信息。

智能卡可以是经由无线接口编程，该无线接口通常是这个人的移动电话。然而，支付设备上的激活的无线接口可能容易遭受逆向工程和威胁。支付卡应该适于经由，经由物理链接读取和写入支付卡的手持设备进行编程。

本公开还提供了用于减轻在钱包/钱夹中携带多个塑料卡的负担的解决方案，并且描述了卡交易细节可以被用于捕获评论/体验的方法。

图10在示意图中示出了根据一些实施例的通用智能卡(USC)1000的示例。通用智能卡1000包括具有以下组件的塑料卡：微处理器/CPU 1002、近场通信1004芯片、EEPROM1006、电子墨水1008芯片、RFID 1010芯片、电池1012、认证1014芯片、显示接口1016、以及同于对通用智能卡1000充电的电接触1018。在一些实施例中，通用智能卡1000可以经由智能卡套件1100充电。

图11A在示意图中示出了根据一些实施例的智能卡套件1100的示例。智能卡套件1100是智能钱包的示例。术语“套件”在本文中将被用于指代智能钱包。“套件”是用于智能钱包的外形尺寸的示例。智能卡套件1100可以包括可以容纳和读取智能卡的任何容器外形尺寸。为了描述简单，所示出的智能卡套件1100是尺寸为了容纳整个智能卡的外套。智能卡套件1100包括用于插入智能卡1000的外套/容器1102并且包括以下组件：微处理器/CPU1104、用于对套件进行充电而没有基座的微型USB端口1106(参见图12)、电池1108、无线接口1110、认证1112芯片、RAM 1114芯片、EEPROM 1116芯片、电容式显示器接口1118、通用智能卡充电引脚1120、以及当该套件被置于基座上时用于该套件的充电连接1122(参见图12)。电容式显示器1118允许用户将数据输入到套件1100并且查看处理的结果。套件1100还可以存储通用智能卡(USC)，以及：(a)显示存储在USC中的卡中的每一个的信用窗口，(b)显示关于存储在USC中的多个卡中的任一个的兑换积分或返现，(c)将USC编程为默认使用具有最大信用窗口的卡，(d)将USC编程为在被存储在其EEPROM中的不同的卡中分摊支付，(e)显示存储在USC中的卡中的任一个的购买交易，以及(f)允许卡用户直接捕获和读取购买交易的评论。套件1100提供了用于进行电子支付和检查交易历史的备选工具。在一些实施例中，套件1100中的特征还可以在具有通过近场通信(NFC)或类似技术的无线支付能力的智能电话中获得。本公开描述了用户可以选择经由套件1100或移动电话800查看交易历史的场景。不希望其所有的信息或卡都在手机上的用户可能更喜欢套件1100。

在一些实施例中，智能卡套件可以被限制为：用于保持通用智能卡1000的外套/容器1102、用于执行存储在存储器1116中的指令的微处理器/CPU 1104、用于与平台200通信的通信接口(例如，无线接口1110)、以及用于存储交易细节的EEPROM 1116芯片、以及用于通用智能卡1000的操作的指令。来自智能卡套件1100的其他要素可以被添加到这个备选实施例。

在一些实施例中，提供了智能卡套件(例如，智能钱包)。该智能卡套件包括：足够尺寸的外套，用于配合至少一个智能卡；通信接口；处理器；以及包括指令的序列的存储器，当所述指令的序列执行时，将处理器配置为，从被插入在外套中的智能卡接收使用智能卡最近进行的购买的购买细节，从服务器接收已进行的购买的购买评论，以及将购买细节和购买评论存储在存储器中。

在一个方面，智能卡套件处理器还被配置为向服务器传送购买细节、以及向服务器传送购买评论。

在一个方面，该智能卡套件还包括显示器。该处理器还被配置为显示所述购买细节和所述购买评论。

图11B示出了根据一些实施例的智能卡套件/钱包显示器1150的示例。智能卡钱包显示器1150包括：用于搜索智能钱包内容的浏览器1152的用户选择选项；用于转进、转出或在账户之间转移资金的货币转移选项1154；用于存储用户备忘录的日志选项1156；用于读取、存储和/或生成评论的评论选项1158；用于分析开销的分析选项1160；用于用户设置配置的设置配置标签1162；用于同步诸如与另一计算机或服务器的交易之类的智能钱包信息的同步选项1164；以及用于提供用户安全性的认证选项1166。其他特征可以被添加到智能钱包。在本文描述智能钱包显示器1150中所示的特征中的一些。

在一些实施例中，智能卡钱包/套件1100可以将支付卡合并成一个卡，在不同的卡之中分摊支付，优化可用的信用卡，使卡信息对于第三方保密，根据类别来分析开销(例如，旅游、食物、住宿等)，提供卡的单个窗口激活/消除，向另一个人/业务来转移货币，提交和读取评论/体验，在单个设备上检查多个卡交易，和/或搜索和定位产品、业务和服务提供方。

图11C示出了根据一些实施例的智能钱包1100上的卡状态屏幕1170的示例。卡状态屏幕1170包括：滑块按钮1172，其允许用户允许访问(按钮1172在右边)或限制访问1172(按钮1172在左边)账户。在一些实施例中，这样的允许/限制可以被用于安全目的，以防止未授权的交易。

图12在图像中示出了根据一些实施例的套件基座1200的示例。套件基座1200包括嵌入在其充电板1202中的WiFi接口、电源连接设备1204、WiFi LED 1206和充电LED 1208。当套件1100被放在基座1200上时，基座1200可以对套件1100的电池充电，并且还可以使通用智能卡1000与来自发布者的信息同步。在一些实施例中，套件1100被编程为仅与(住宅/办公室)地理界线内的可信的设备(移动设备/计算机)运行同步(sync)操作，以防止黑客窃听套件1100和互联网设备(例如，移动电话800)之间的任何通信。

因此，提供了一种用于经由套件1100将多个卡存储到通用智能卡1000的机制。为了存储多个卡，该用户可以首先将需要被存储在通用智能卡1000卡上的每个卡插入套件1100中，然后将其去除。这个过程(即，注册)可以将所有卡的信息输入到套件1100并且允许其1100利用多个卡信息对通用智能卡1000编程(即，初始化)。用于取得相同的结果的另一种方法将是将所有卡的信息存储到用户的在线账户，然后经由套件1100将细节输入到通用智能卡1000。要理解的是，套件1100可以被配置为添加新卡或采用与注册和初始化类似的方式更新当前卡。例如，用户可以插入和去除新卡，并且套件1100可以在通用智能卡1000内初始化新卡。

图13、图14、图15和图16演示了智能套件1100可以被用于不引人注意地捕获卡交易的购买细节的使用情况。

图13示出了根据一些实施例的套件1100中的通用智能卡1000的示例。通用智能卡1000能够存储被插入到套件1100中的多个卡(借记卡、信用卡、积分卡)的细节，其中，卡细节经由密码进行保护。显示单元1118显示日期和时间以及卡状态(锁定)。套件1100还可以与利用单个卡号编码的标准智能卡1000一起使用，但是智能卡1000应该也具有将购买细节捕获到其EEPROM 1006中的能力。

图14示出了根据一些实施例的没有通用智能卡1100的套件1100的示例。在一些实施例中，当通用智能卡1000从套件1100去除时，卡号、有效期和CW号被屏蔽。这旨在防止除了卡所有者以外的人复制卡细节。在一些实施例中，套件1100将通用智能卡1000编程为，默认使用具有最大信用窗口/还款周期的信用卡。

零售店可以给予其客户积分卡以允许客户每次进行购买时赚取积分点。积分卡可以是在其上没有任何借贷的塑料卡或包含由商家提供的一些借贷的塑料卡。携带多个积分卡的副作用在于，虽然消费者能够在其每次进行购买时在POS处兑换积分，但是每个积分卡增加了钱包/钱夹的体积，使其笨重且易于被偷。通用智能卡1100可以消除对携带多个卡的需求。

通用智能卡1000具有可以将销售方标识符(id)存储到其存储器中的EEPROM1006。用户可以通过将已有的积分卡到添加到套件1100(并且去除)(其读取积分卡信息)并且接着将通用智能卡1000插入到套件1100中(其将积分卡信息输入到通用智能卡的EEPROM1006)，将销售方添加到通用智能卡1000中。将积分卡信息注册到通用智能卡1000的一种备选方式是，当客户进入商家的POS并且尝试进行购买时，通过将通用智能卡1000插入到读卡器。读卡器查询通用智能卡1000的EEPROM 1006以读取销售方id。如果其没有发现，则POS代表可以询问客户其是否想要注册积分卡。客户可能谢绝提供或同意提供。在一些实施例中，如果客户谢绝提供，则商家将拒绝记录到EEPROM 1006中，并且客户将不在被询问相同的问题。如果客户同意提供，则商家将同意记录到EEPROM 1006中，并且请求客户填写纸表或电子表以进行进一步处理。当客户的请求经过处理时，积分卡信息被保存到EEPROM 1006中。然后商家能够根据需要将积分添加到用户积分卡或从其删除积分。

图15示出了根据一些实施例的被插入到套件1100并被解锁的通用智能卡1000的示例。在一些实施例中，套件1100示出全部的卡细节并且示出用于使1512卡与发行方/银行同步的菜单1510，从而可以查看现金流。菜单1510还可以允许用户浏览1514存储在通用智能卡1000中的所有卡、针对任意购买的捕获1516评论/体验，并且还分析/配置1518其在卡中的任一个或全部上的开销。在一些实施例中，套件1100可以被编程为，帮助智能卡用户设置购买限制和根据开销类别(例如，旅游、食物、车辆、娱乐)的针对卡的警报。

图16A和图16B示出了根据一些实施例的用户检查被存储在通用智能卡中的卡中的一个的购买历史1000的示例。图16A示出了显示在智能电话800上的信息。图16B示出了显示在套件1100上的信息。在这个示例中，该用户已经选择了具有1200美元的信用余额和6月15日的支付到期日的卡号5228-1400-0789-6223。该用户查看这个卡的交易并且选择在3月12日与亚马逊发起的一个交易。根据交易历史，该用户花费了107.92美元购买五个产品。该用户可以经由智能套件1100(参见图16B)自身或通过可以访问卡1000的交易细节的计算机或移动设备800(参见图16A)提交所述产品中的任一个或全部的评论。

在通用智能卡1000上捕获的交易细节将帮助用户捕获其对产品/业务/服务的评论/体验。所提出的解决方案提供了用于查找被映射到UPC、EAN、ASIN或ISBN号的信息并且动态地生成上下文有关的表以捕获与交易相关联的评论/体验的方法。所捕获的评论/体验可以与用户的社交网络分享，并且被匿名地提交到提供与产品/业务/服务提供方有关的经认证的信息的搜索索引。用于捕获包括交易细节的UPC、EAN、ASIN或ISBN号的其他备选方法是：通过在进行支付时扫描包含打印出的购买记录上的细节的快速响应(QR)码、接收包含交易细节的电子邮件/URL或以电子方式将交易记录到在线数据库中的持卡人的账户。因为所有支付卡具有唯一id，所以包含卡id(外键)的交易发票可以被链接到交易数据库141中的持卡人id(主键)。

在一个方面，智能卡套件还包括第一通信接口和第二通信接口。处理器1104被配置为经由第一通信接口与智能卡1000通信，并且经由第二通信接口与服务器通信。在一个方面，第二通信接口是无线通信接口，并且处理器还被配置为仅与离与平台200服务器通信的可信的设备10、800预定义的距离之内的服务器通信。在一个方面，第二通信接口是无线通信接口，并且处理器还被配置为仅与可信的设备并且在可信的位置处进行通信。

在一个方面，套件1100容纳包括多个卡的智能卡1000，并且处理器还被配置为追踪被存储在该智能卡中的多个卡中的每一个的开支使用1000。

在一个方面，智能卡套件处理器1104还被配置为保持多个卡中的每一个的余额、显示用于所述多个卡中的每一个卡的信用窗口、在被存储在其EEPROM 1116中的不同的卡中分摊支付、以及显示关于所述多个卡中的任一个的兑换积分或返现。在一个方面，智能卡套件处理器1104还被配置为保持多个卡中的每一个的余额1100、以及显示对使用卡中的具有最大信用窗口的卡的推荐。

图17示出了根据一些实施例的POS设置1700的示例。POS设置1700包括POS设备1702、支付体/读卡器1704、打印机1706和路由器1708。系统1700允许经由经修改的支付体1704、安装在打印机1706处的启用网络的加密器(H/W环回器1710)或安装在POS设备1702上的软件驱动器(S/W环回器1720)捕获客户交易记录(CTR)。

图18在序列图中示出了根据一些实施例的POS工作流1800的示例。工作流1800包括根据一些实施例的三个使用情况：(a)用户通过将卡插入到支付体进行支付1810的示例；(b)用户通过搭接卡/刷卡或搭接电话进行支付1830的示例；以及(c)用户用现金进行支付1850的示例。方法1800从用户在销售点(POS)处发起支付开始。

在第一个使用情况1810中，该用户将通用智能卡1000插入1812到(连接到POS设备1702的)支付体1704中。支付体1704检测到是一个通用智能卡1000并且发送消息1814以通知POS设备1702。POS设备1702发送消息1816以触发支付体1704来将交易细节(例如，CTR)直接记录到通用智能卡1000的EEPROM 1006中。接着，用户从支付体1704去除1818通用智能卡1000。在一些实施例中，如果支付体1704检测到被插入的卡不是通用智能卡1000，则POS设备1702可以向打印机1706发送消息1836以打印交易细节，并且向交易数据库141发送消息1838以与第二个使用情况1830中一样地更新卡用户的在线账户中的交易记录。一旦交易细节被记录到通用智能卡1000中，该用户就将通用智能卡1000插入1820到套件1100中。如果套件1100被连接到互联网，则其向交易数据库141发送消息1822，以使通用智能卡1000与用户的在线账户同步，并且套件1100向用户显示1824经更新的交易细节。交易细节根据需要被上载和下载。

在第二个使用情况1830中，该用户对着支付体1704搭接或刷1832支付卡。支付卡可以是通用智能卡1000或包含NFC芯片和磁条的任何普通的支付卡。支付体1704检测到是NFC/磁条操作，并且发送消息1834以通知POS设备1702。接着，POS设备1702向打印机1706发送消息1836以打印交易细节，并且向交易数据库141发送消息1838以更新卡用户的在线账户中的交易记录。接着，该用户打开移动设备/计算机800并且向交易数据库141发送消息1840以向用户显示经更新的交易细节。

在第三使用情况1850中，该用户向POS代表进行现金支付1852。该代表接受支付并且触发POS设备1702向打印机发送命令，以打印1854包含与交易细节相关联的快速响应(QR)码的交易发票。然后该用户可以经由其移动设备800扫描1856QR码并且更新1858卡用户的在线账户中(即，交易数据库141中)的CTR。接着，该用户打开移动设备/计算机800并且向交易数据库141发送消息1860以向用户显示经更新的交易细节。

POS 1700提供了用于捕获卡交易的全部细节的多个选项。一些客户选择在POS处搭接(使用NFC)或刷(使用磁条)他们的卡，其可能不能给予足够的时间在他们的卡上记录交易细节。在这样的情况下，商家可以向客户的电子邮件id发送交易的电子副本或将数据记录到客户可以访问关于卡交易的全部信息的中心位置。

图19、图19A和图19B示出了根据一些实施例的账单记录1900的示例。图19示出了使用不同的支付渠道(在线支付、智能电话和信用卡)来支付其交易的人(例如，比尔·理查森)的账单记录1900。图19A示出了所述显示的放大视图。在这个示例中示出的账单记录1900可以在智能电话800或套件1100上。在这个示例中，比尔可以通过选择对应的记录检查由他支付的账单中的任一个的交易细节。图19B示出了交易细节的三个示例的放大视图。在第一示例1902中，示出了用于在线支付系统账户的交易的示例。在第二示例1904中，示出了用于ASIN账户的交易的示例。在第三示例1906中，示出了用于UPC账户的交易的示例。

图20在流程图中示出了根据一些实施例的获取评论的方法2000的示例。方法2000包括：接收2002包括产品或服务的输入、定位2004与该输入相关联的评论、以及显示2006该评论。其他步骤可以被添加到方法2000。在一个方面，智能卡套件处理器1104被配置为接收包括产品或服务的输入、定位与该输入相关联的评论、以及显示该评论。

社交搜索

一些社交网络网站允许人们发布其简档、接收和提供针对专业技能的支持、以及接收和给出专业的推荐。虽然这个方法的目的很好，但是一些人可能试图与系统博弈并且提升自己/欺诈他人。许多社交网络网站不具有检查给予支持的人的可信度、以及验证已经在其平台中创建简档的人的证书的机制。建立证据的负担可能被置于读者。系统100可以减轻或尝试去除在线内容中的歧义。

在当前的教导以前，如果产品/业务/服务提供方请求来自客户的评价，则客户可以提交产品/业务/服务提供方的评论，并且与其社交网络和世界其他地方分享该评论。此外，已提交的评论被锁定到产品/业务/服务提供方的数据库中，并且世界的其他地方看不到。相反，当前的教导通过允许客户通过执行电话本查找或通过将评论与业务交易相关联来捕获产品/业务/服务提供方的评论而打破了这个限制。当客户以这种方式捕获信息时，评论与产品/业务/服务提供方和客户相关联。

所构建和维护的评论数据库142可以被考虑为：包括与产品、业务、服务提供方有关的可信信息或进行决策时的任何其他关键数据在内的单个真实情况点(single pointof truth)(SPOT)。这个目标通过允许普通人和主题专家对其对于上述实体中的任一个的体验进行排名和评定而不害怕任何惩罚而实现，例如，这是诸如《2016年美国消费者评论公平法》(HR-5111)之类的消费者保护法规定的。系统100提供了一种完成这个任务的技术——将所有电子(在线)交易和卡支付捕获到用户可经由其个人账户访问的数据库中、并且允许用户对其对于任意产品/业务/服务的体验进行排名和评定(参见图5——使用情况510)。另外，系统100还提供了一种经由电话本存储库捕获征求的评论和未征求的评论的技术(参见图4和图5——使用情况520)。系统100不只是将范围限制在上述数据源，而且明显的是它还可以被扩展到其他数据源110。例如，实施例中描述的技术还可以被用于验证和赞成/拒绝网络世界中的新闻。假新闻的威胁已根植于网络世界中，部分原因是没有公认的负责地或可信地验证新闻故事的组织。一旦建立一种用于将故事与提供方相连接并且验证提供方的证书的机制，假新闻的问题就可以被缓解。

客户评论的集中式存储库

在集中式存储库中捕获的交易细节和评论可以以许多方式帮助消费者。消费者可能能够可见地与其社交网络并且匿名地与世界的其他地方分享其对于产品、业务和服务提供方的体验。图21至图21C示出了根据一些实施例的分享消费者体验的示例。图21A至图21C示出了三个使用情况：a)平常的业务2110，b)SPOT——根据个人的经合并的评论2120，以及c)分享——在组中分享的评论2130。第一个使用情况2110是当前场景，其中，评论被锁定到每个销售方的数据库中，并且外界无法访问。第二个使用情况2120示出了一种场景，其中，用户评论按照其各自账户被捕获到中心位置处。这些评论可以经由移动设备(电话、套件)或计算机访问。第三个使用情况2130示出了一种场景，其中，一个朋友组已经同意相互分享他们的评论。因此，当他们中的任一个访问系统100评论数据库142时，他们都能够看到由该组捕获的所有评论。

评论的合并数据库可以帮助消费者以及销售方进行决策。例如，当前客户可能能够推断出例如前一个客户定期地购买计算机硬件；当前客户在购买计算机硬件和/或检查其评论以前，应先与前一个客户交谈；系统100合并前一个客户在零售商中的评论；当前客户可以从前一个客户的体验中学习。当前客户还可能能够推断出例如前一个客户对业务扩展器设备给出了负面的评论；当前客户应考虑购买更好的路由器，以改善他们的住宅处的网络连接；在查看其在电子商务网站上的过度赞扬的评论以后，当前客户不再打算购买该业务扩展器；得益于系统100，当前客户可以看到该产品具有工程技术缺陷。例如，销售方可能能够推断例如客户对品牌USB电缆和品牌MP3播放器做了非常细致的评论。该客户的简档表明该客户是有经验的电子工程师。此外，从其他客户接收到的这些产品的平均评定来看，该产品应从销售方的目录中删除，并将未售出的库存返还给生产商。

系统100搜索引擎132还可以帮助消费者确定产品和服务的真实价值。例如，一些零售商可以通过提高产品的价格并且随后提供虚高价格的折扣来诱骗客户购买产品。当客户最终支付产品的实际零售价时，这个做法没有任何折扣。在一些实施例中，系统100可以保持所有商铺和地理位置的价格的存档，由此允许客户在进行购买以前在零售商之间比较价格(参见图22A)。系统100还可以允许他们在进行购买以前验证产品的历史价格(参见图22B)。图22A和图22B示出了根据一些实施例的根据销售方和根据时间的产品的搜索结果的示例。

用于经变换的客户交易记录(CTR)的所有权的框架

在一些实施例中，图17所示的POS设置1700可以被用于为商家/销售方和客户创建唯一的价值主张——基于经变换的客户交易记录(CTR)的所有权的积分计划。现在将描述这种程序的操作原理。

许多商家/销售方和一些银行向客户发行联名支付卡，其中，每次客户在分配商铺或商号使用该卡进行购买时，客户都获得奖励积分或返现。商家、销售方和银行将这种利益作为积分奖(loyalty bonus)，因为他们想保留他们的客户，而且还因为他们想从他们的客户的购买行为中学习。奖励积分或返现可以兑换某些产品，或者根据在商家的商铺处或合作伙伴网络中的未付款量/购买量进行调整。

当客户从商家/销售方或银行取得联名支付卡时，他们与发卡方签署协议，因此，他们的交易记录将由商家/销售方或银行保留并且被用于促销、业务洞察等。商家、销售方和银行不与其竞争对手分享客户交易记录，并且需要遵守监管机构(通常是政府机构)分配的任何适用的隐私法。此外，虽然商家/销售方保留包含客户购买的每件东西的明细的客户的交易发票的副本，但是银行仅接收到包含在商家/销售方处花费的总额的记录。

如果客户具有由不同的商家/销售方或银行(典型的情况)发行的多个支付卡，则商家/销售方或银行可用的业务洞察力在范围上非常有限。例如，如果客户经由除了由一个商家/销售方发行的支付卡以外的支付卡购买了某品牌的肥皂或食用油、或者如果客户从其他商家购买了上述产品，那么该商家/销售方就不能确定客户是否是同样的肥皂或食用油的重复购买者。诸如这些之类的信息对于肥皂或食用油的生产商计划其生产量和广告预算可能是非常有价值。

POS设置1700允许客户将其所有交易记录——在线以及离线，保存在其集中式储库中的账户中。这个架构是对现有/当前设置的改进。图23A示出了交易记录可以被打印出来或被记录在在线数据库中的客户活动的示例。没有记录所有的客户交易的集中式数据库。图23B示出了根据一些实施例的所有的交易记录(在线和离线)都被记录在集中式数据库中的客户活动的示例。交易记录的集中式存储库可以变换客户交易记录(CTR)的所有权，并且将交易数据直接置于客户的手中。在新框架中，客户无需获取和使用商家/销售方联名卡或标识符，例如，用于赚取积分信用(loyalty credits)的QR码。客户可以使用其自身已拥有的任意卡并且将该卡链接到其与商家的购买交易。接着客户可以利用其购买交易的电子记录来从商家/销售方得到促销、折扣、优惠和返现。

为了允许商家/销售方在没有诸如QR码之类的商家特定的支付卡或标识符的情况下进行积分计划(loyalty program)，系统100允许商家/销售方和客户在系统100下创建其自身的账户。接着，系统100允许客户将与其支付卡相对应的令牌号添加到其账户内。客户可以经由其与发卡方的在线账户或在交易期间动态地将令牌号添加到其账户。支付卡发卡方在持卡人的请求处(经由单向哈希)对支付卡进行令牌化，并且在支付卡发卡方每次收到针对令牌号的请求时向支付处理器提供所存储的令牌号的加密副本。系统100将令牌号用于，将在交易期间使用的支付卡与包含令牌号的客户账户相关联。令牌号唯一地标识支付卡，但是不能在数学上进行逆运算以显示支付卡号。其利用系统100公钥来加密，并且只可以经由部署在系统100处的相匹配的系统100私钥来解密。要理解的是，可以使用唯一地标识支付卡而不显示其所有者的其他方案。

当发起交易时，交易记录可以被保持在客户的账户以及相关联的商家的账户中。如果客户加入了商家的积分计划，则系统100可以将客户的交易记录与商家的账户进行链接。如果客户未加入商家的积分计划，并且商家已经创建了积分计划，则可以向客户提示将自身注册到商家的积分计划。如果客户同意将自身注册到商家的积分计划，则交易记录可以与商家的账户进行链接。如果客户拒绝加入商家的积分计划，则利用系统100记录客户的动作，并且不再向客户提示注册到向商家的积分计划。如果商家尚未创建积分计划，则客户交易记录仅被保存在系统的客户的账户中，并且商家收不到与客户记录有关的任何信息。

图24A和图24B在序列图中示出了根据一些实施例的基于经变换的CTR的所有权的积分计划的工作流程2400A和工作流程2400B的示例。所述工作流程包括四个使用情况：(a)经由支付处理器以电子方式捕获用户卡支付交易记录和积分的方法2410的示例；(b)用户卡尚未被注册时的经由支付处理器以电子方式捕获用户卡支付交易记录和积分的方法2430的示例；(c)通过在移动应用上显示POS代表利用扫描机读取的快速响应(QR)码以电子方式捕获现金支付交易记录和积分的方法2450的示例；以及(d)接收包含交易记录的快速响应(QR)码的打印输出的现金支付交易的方法2460的示例，其中，用户利用移动应用进行扫描并且捕获的交易记录和积分。方法2410、方法2430、方法2450和方法2460从用户在销售点(POS)处发起支付开始。

在第一使用情况2410中，该用户经由被连接到POS设备1702的支付体发起购买2412(例如，搭接、滑动、插入卡)。支付体读取经加密的卡细节和账单金额，并且将2414所述信息转发到POS设备1702。POS设备1702接受所述信息并且将其路由2416到支付处理器2490，以(例如，在授权请求消息中)进行授权，并且还接收与该卡相对应的令牌号的加密副本。

当支付处理器2490接收2416到该授权请求时，支付处理器2490解密卡细节并且将卡号转发到发卡方以进行授权。支付处理器2490请求发卡方进一步提供卡的令牌号(如果有)的加密副本。发卡方检查持卡人的账户以确认是否有足够的资金可用于处理该交易。如果账户具有足够的资金，则发卡方向支付处理器发送授权，并且还提供与该卡相对应的令牌号(如果有)的加密副本。支付处理器2490(例如，在授权回复消息中)将该授权和经加密的令牌号转发2418到POS设备1702。一旦POS设备1702接收到授权和令牌号，其就生成客户交易记录(CTR)的电子副本，并将该CTR与经加密的令牌号进行链接。然后，商家将这两个信息都传送2420到包含在线交易数据库141的系统100。在系统100处，令牌号被解密。然后，系统100查找2422包含令牌号的客户账户号。如果在客户账户号中注册了令牌号，则(例如，经由插入CTR消息2424)将CTR附加到客户账户号的交易记录。如果令牌号未在客户账户号中注册，则提示客户允许系统100将令牌号注册到其账号中，然后利用新的交易记录更新客户的账户中的交易记录。一旦交易记录被附加2424到客户的交易记录，该信息也就(例如，经由链接交易消息2426)被链接到商家的积分计划(如果有的话)。如果商家正在进行积分计划，但是客户还没有注册到其中，则商家向客户提供与其积分计划有关的信息，并且描述注册到陔计划中的步骤。

旦交易记录被插入到客户账户中，交易细节就可以被显示2440在用户设备(或智能钱包显示器)上。

第二使用情况2430从步骤2412至步骤2420开始。然而，在这种使用情况下，当系统查找2422包含令牌号的客户账户号时，其不能够找到与任意客户账户2432相关联的令牌号。然后POS设备1702显示未知卡消息2434。在POS设备1702处可以接收到2436要包括与支付卡相对应的令牌号的授权，然后POS设备1702向系统100发送添加卡消息2438。然后系统100可以在客户账户号中创建/添加与支付卡相对应的令牌号，该客户账户号作为变量被包括在消息2438中。一旦令牌号被添加2438，那么步骤2424至2426就可以发生。一旦交易记录被插入到客户账户中，交易细节就可以被显示2440在用户设备(或智能钱包显示器)上。

在第三使用情况2450中，该用户经由POS设备1702进行现金支付2452，并且指示POS代表其在智能电话上已安装了移动应用以采集奖励积分。POS代表请求用户显示包含注册到系统100的客户账户号在内的快速响应(QR)码。当用户在其智能电话上显示2454QR码时，POS代表发起扫描处理2472并且接收2474客户账户号。然后POS设备1702发送交易记录消息2476以将CTR注册到系统100。系统100可以将CRT添加/插入2424到数据库141中，并且将交易与商家的积分计划(如果有的话)链接2426。如果商家正在进行积分计划，但是客户还没有注册到其中，则商家向客户提供与其积分计划有关的信息，并且描述注册到该计划中的步骤。一旦交易记录被插入到客户账户中，交易细节就可以被显示2440在用户设备(或智能钱包显示器)上。

在第四使用情况2460中，该用户经由POS设备1702进行现金支付2452，并且指示POS代表其想要接收客户交易记录的打印输出。POS设备1702向打印2464发票的打印机发送打印发票消息2462，其中，整个交易记录被捕捉到快速响应(QR)码中。然后可以发生上述步骤2472至步骤2426。一旦交易记录被插入到客户账户中，交易细节就可以被显示2440在用户设备(或智能钱包显示器)上。

即使利用现金交易，使用情况#32450和#42460中的过程也允许客户收集奖励积分和返现。以这种方式捕获的交易记录允许客户立刻看到其在支付方法和支付卡上的开支习惯。系统100还允许客户加入商家的积分计划，而无需提供与自身有关的任何机密信息。大多数主流的积分计划都要求客户，在客户注册到积分计划中之前签署协议并且提供与自身有关的机密信息(姓名、年龄、电话号码、电子邮件地址、邮政地址、社会保险号等)。此外，因为每个商家都发行其自身的积分卡，所以客户可以在其钱包中累积许多积分卡，其增加了盗窃和滥用卡的机会。所提出的系统基于在交易时使用的支付方法来奖励客户积分。客户可以通过现金(经由QR码)和卡(经由令牌号)赚取积分。

图25A至图25D在表中示出了根据一些实施例的交易细节2510、交易细节2520、交易细节2530和交易细节2540的示例。图25B至图25D示出了系统中的每一方(商家2530、银行2540和在线交易数据库2520)仅对其拥有的信息具有可见性。商家具有关于客户在其商铺/合作伙伴网络中完成的交易2530的信息，并且将这些信息用于计算客户的积分。然而，在接收关于其自己的商铺/合作伙伴网络外部的客户的交易2510的信息之前，需要来自客户的同意。要理解的是，商家将向客户提供积分以接收这样的信息。银行具有关于各个市场部分上的客户开支2540的信息，但是不知道钱是如何花费的，因为交易记录2510未与银行共享。在线交易2520数据库不知道令牌号后面的客户，因为银行不需要与在线交易数据库2520共享这个信息。具有对交易记录2510的完全访问的唯一一方是进行购买的客户。客户可以与系统中的其他方共享其交易记录2510，而无需显示其身份。

图26是诸如服务器之类的计算设备2600的示意图。如图所示，计算设备包括至少一个处理器2602、存储器2604、至少一个I/O接口2606、以及至少一个网络接口2608。

处理器2602可以是英特尔或AMD x86或x64、PowerPC、ARM处理器等。例如，存储器2604可以包括诸如随机存取存储器(RAM)、只读存储器(ROM)、光盘只读存储器(CDROM)之类的位于内部或外部的计算机存储器的合适的组合。

每个I/O接口2606使计算设备2600能够与一个或多个输入设备(例如，键盘、鼠标、照相机、触摸屏和麦克风)或与一个或多个输出设备(例如，显示屏和扬声器)互连。

每个网络接口2608使计算设备2600能够与其他组件通信，以与其他组件交换数据、以访问和连接到网络资源、以服务于应用，并且通过连接到能够承载数据的网络(或多个网络)执行其他计算应用，所述网络包括互联网、以太网、普通老式电话服务(POTS)线、公共交换电话网(PSTN)、集成服务数字网(ISDN)、数字用户线(DSL)、同轴电缆、光纤、卫星、移动、无线(例如，Wi-Fi、WiMAX)、SS7信令网络、固定线路、局域网、广域网等。

前面的讨论提供了本发明主题的许多示例实施例。虽然每个实施例表示发明要素的单个组合，但是本发明主题被考虑为包括所公开的要素的所有可能的组合。因此，如果一个实施例包括要素A、要素B和要素C，并且第二个实施例包括要素B和要素D，那么本发明主题也被考虑为包括其余的A、B、C或D的组合，即使没有明确公开也是如此。

本文描述的设备、系统和方法的实施例可以以硬件和软件两者的实现来实现。这些实施例可以在可编程的计算机上实现，每个计算机包括至少一个处理器、数据存储系统(包括易失性存储器或非易失性存储器或其他数据存储要素或其组合)、以及至少一个通信接口。

程序代码被应用于输入数据以执行本文描述的功能并且以生成输出信息。输出信息被应用于一个或多个输出设备。在一些实施例中，所述通信接口可以是网络通信接口。在要素可以被组合的实施例中，所述通信接口可以是软件通信接口，例如，用于内部进程通信的软件通信接口。在又一些实施例中，可以是作为硬件、软件或其组合来实现的通信接口的组合。

在前面的全部讨论中，参考了由计算设备形成的相关的服务器、服务、接口、门户、平台或其他系统。应当理解，使用这样的术语被认为表示具有被配置为执行存储在计算机可读的有形非暂时性介质上的软件指令的至少一个处理器的一个或多个计算机设备。例如，服务器可以包括采用实现所描述的角色、职责或功能的方式的作为web服务器、数据库服务器或其他类型的计算机服务器的一个或多个计算机。

实施例的所述技术解决方案可以是软件产品的形式。软件产品可以被存储在非易失性或非暂时性存储器介质中，它们可以是光盘只读存储在(CD-ROM)、USB闪存盘或可移动硬盘中。软件产品包括使计算机设备(个人计算机、服务器或网络设备)能够执行由实施例提供的方法的一些指令。

本文描述的实施例通过包括计算设备、服务器、接收器、发送器、处理器、存储器、显示和网络的物理计算机硬件实现。本文描述的实施例提供有用的物理机器和专门配置的计算机硬件布置。

虽然已经详细描述了实施例，但是应当理解，本文可以进行各种改变、替代和变更。

此外，本申请的范围不旨在被限制在说明书中描述的过程、机器、产品，事项、装置、方法和步骤的组成的特定实施例。

如可以理解的，上述和图示的示例仅旨在是示例性的。