富集与账户数据更新请求相关联的商家标识符的制作方法

文档序号:16267644发布日期:2018-12-14 22:01阅读:215来源:国知局
富集与账户数据更新请求相关联的商家标识符的制作方法

本公开一般而言涉及信息网络,并且更具体地涉及用于富集(enrich)与对更新后的持卡人账户数据的请求相关联的商家标识符的计算机系统和基于计算机的方法。

背景技术

支付卡是可以体现为例如信用卡、借记卡、包括智能卡的启用无接触rfid的设备、启用近场通信的智能电话、电子移动钱包等的无现金支付设备。支付卡可以是真实或虚拟的设备,通过该设备可以识别作为支付的支付者和/或资金来源的持卡人。

持卡人可以出示支付卡,以便在销售点或从远程位置进行支付。在一些情况下,个人可以重复与单个商家(诸如重复客户)或通过定期支付(recurringpayment)进行交易。重复交易可以以规律安排的间隔或在事件发生时(例如,余额达到预定阈值)被触发。

个人向其期望使用支付卡与其重复交易商品和服务的商家登记已变得很普遍。一旦登记,在进行交易时,个人就不需要重新输入个人数据和支付卡数据。相反,商家可以尝试使用已提交的个人和支付卡数据完成交易。这些交易被称为“卡不存在”(cnp)交易。在这种交易中,关于支付卡的数据(包括个人帐号(pan)以及在许多情况下支付卡的到期日期)连同交易是cnp交易的指示符一起从商家发送。“存档账户(account-on-file)”交易是另一种类型的交易,其中商家将关于持卡人的支付卡的数据存储在数据库中,然后检索存储的支付卡数据并将其包括在支付授权请求中。一种特殊类型的存档帐户交易是商家为特定持卡人定期发起的“定期支付交易”。在这种定期支付交易中,商家将关于持卡人支付卡的数据存储在数据库中,然后检索存储的支付卡数据并将其包括在每个定期授权请求中。

定期存档卡(card-on-file)支付交易的示例是健身房会员资格。持卡人可以选择向健身房注册支付卡(诸如信用卡、借记卡或预付卡),而不是为了健身房会员资格而邮寄每月支票。向健身房注册支付卡使得健身房可以在每个月的特定一天自动向支付卡收取月费。在一些这样的系统中,商家存储与支付卡和/或持卡人相关联的pan、到期日期和/或其它数据。考虑到商家和持卡人的这种支付模式的便利性,该模式可以用在持卡人是俱乐部的成员或者产品或服务的订户的许多其它情况下。因而,多个商家可以已经存储了同一持卡人的支付卡数据。同样,任何给定的商家都可以已经存储了多个持卡人的支付卡数据。

在交易的认证阶段期间,个人账户数据可以由认证实体使用,以认证交易。参与认证处理的实体可以包括例如向持卡人颁发支付卡的发卡银行、商家和/或授权支付卡交易并代表商家转账的商家银行(merchantbank)。这些活动可以通过包括支付处理器的信用卡支付系统进行协调。在一些情况下,发卡银行和商家银行在授权交易之前比较与持卡人相关联的个人账户数据以进行验证。但是,当由发卡银行和商家银行存储的个人账户数据不匹配时(诸如由于认证实体中只有一个更新了个人账户数据),交易可以被拒绝。

当持卡人的个人账户数据改变时,除非与每个认证实体共享更新,否则交易可以被拒绝。用于更新个人账户数据的处理可以是繁琐且耗时的。更重要的是,更新处理可以被随意执行,因为个人通常没有他们为了未来或定期交易而登记的各方的全面列表。缺少更新可以造成重要支付的拒绝,有可能造成进一步的复杂化和罚款。

为了防止这些中断,商家可以将对持卡人账户数据更新的请求直接提交给与支付卡相关联的支付卡支付系统。理想情况下,启用的持卡人可以控制是否准予或拒绝这种请求。但是,该请求可以包含可能混淆或以其它方式使持卡人无法识别商家身份的非富集的商家标识符。因此,持卡人将无法做出是准予还是拒绝该请求的明智决定。因此需要富集与对更新后的持卡人账户数据的请求相关联的商家标识符,以使得请求商家的身份对持卡人更明显。



技术实现要素:

在一个方面,公开了一种受监管自动计费更新器(regulatedautomaticbillingupdater,abu)计算设备。受监管abu计算设备用于富集包括在数据集内的数据。受监管abu计算设备包括与一个或多个存储器设备通信的一个或多个处理器。受监管abu计算设备被配置为:接收对于账户标识符集合的更新后的账户数据的请求,其中所述请求包括账户标识符集合和商家标识符,并且其中所述账户标识符列表包括一个或多个账户标识符,所述商家标识符是非富集的商家标识符;从数据库检索与一个或多个商家相关联的交易数据,其中所述交易数据包括已用于发起与所述一个或多个商家的交易的账户标识符列表;通过确定来自交易数据库的哪个商家已经与包括在商家请求中的每个账户标识符进行了交易来识别目标商家;以及将所述目标商家与非富集的商家标识符关联以生成富集的商家标识符。

在另一个实施例中,提供了一种富集与支付卡更新请求相关联的商家标识符的计算机实现的方法。该方法使用受监管自动计费更新器(abu)计算设备来实现。该方法包括由受监管自动计费更新器(abu)计算设备接收对于账户标识符集合的更新后的账户数据的请求,所述请求包括账户标识符集合和商家标识符,所述账户标识符列表包括一个或多个账户标识符,所述商家标识符是非富集的商家标识符。所述方法还包括从数据库中检索与一个或多个商家相关联的交易数据,所述交易数据包括已经用于发起与所述一个或多个商家的交易的账户标识符的列表。所述方法还包括由受监管自动计费更新器(abu)计算设备通过确定来自交易数据库的哪个商家已经与包括在商家请求中的每个账户标识符进行了交易来识别目标商家;以及将所述目标商家与非富集的商家标识符关联以生成富集的商家标识符。

在又一个实施例中,提供了一种包括用于富集数据集内的数据的计算机可执行指令的非瞬态计算机可读介质。当由受监管自动计费更新器(abu)计算设备的至少一个处理器执行时,计算机可执行指令使所述至少一个处理器接收对于账户标识符集合的更新后的账户数据的请求,所述请求包括账户标识符集合和商家标识符,所述账户标识符列表包括一个或多个账户标识符,所述商家标识符是非富集的商家标识符。所述计算机可执行指令还使所述至少一个处理器从数据库检索与一个或多个商家相关联的交易数据,所述交易数据包括已用于发起与所述一个或多个商家的交易的账户标识符列表。所述计算机可执行指令还使所述至少一个处理器通过确定来自交易数据库的哪个商家已经与包括在商家请求中的每个账户标识符进行了交易来识别目标商家,以及将所述目标商家与非富集的商家标识符关联以生成富集的商家标识符。

附图说明

图1-4示出了本文描述的方法和系统的示例实施例。

图1是图示了具有受监管自动计费更新器(abu)计算设备的支付平台的示意图。

图2是图示了包括图1中所示的受监管abu计算设备的示例性多方网络系统的示意图,该系统用于富集非富集的商家标识符。

图3是图示了图1和2中所示的受监管abu计算设备的示例的图。

图4是图示了根据本公开的一个示例实施例的用于使用图1和2中所示的受监管abu计算设备来富集非富集的商家标识符的示例方法的流程图。

具体实施方式

本文描述的系统和方法针对用于富集与由商家提交的持卡人账户更新请求相关联的商家标识符的受监管自动计费更新器(abu)计算设备。这个增强的abu计算设备在本文中被称为“受监管abu计算设备”。

一般而言,受监管abu计算设备周期性地从一个或多个发卡方接收账户数据和账户数据更新,并且在受监管abu计算设备账户数据库中维护账户数据。账户数据和账户数据更新与唯一的个人账号(pan)相关联。账户数据和账户数据更新可以包括pan、到期日期和/或与支付卡和/或持卡人相关联的其它数据。受监管abu计算设备也与支付处理器通信并汇总交易数据。交易数据可以包括pan的列表以及pan与其进行交易的商家的列表。交易数据由商家加索引,因此数据库中的每个商家与pan的列表相关联。交易数据还可以包括交易日期和时间、与交易相关联的物理地址、交易金额等等。交易数据存储在受监管abu计算设备交易数据库中,并且可以与账户数据一起存储或存储在分开的数据库中。交易数据可以包括在指定的时间窗口内(例如,在过去的九十天内)完成的交易。与交易数据相关联的商家可以使用交易标识符来识别。这些商家交易标识符可以与持卡人交易摘要中的标识符相似,诸如可能出现在账户报表或账单中。商家交易标识符旨在是持卡人可识别的。

如果商家或其它请求方希望针对pan列表验证或更新其账户数据,那么请求方可以向受监管abu计算设备提交更新请求。在某些实施例中,可以收集来自一个或多个请求方的多个更新请求并将其作为一批提交给受监管abu计算设备。例如,商家银行可以从一个或多个商家收集多个更新请求并将更新请求作为一批提交给abu管理器计算设备。

在一些实施例中,由商家或代表商家做出的更新请求可以包括识别可以与可容易识别的商家名称不相关的数据元素。虽然与商家相关联,但这些数据元素表示非富集的商家标识符。与商家交易标识符不同,非富集的商家标识符不一定意味着可被持卡人识别,并且可以混淆商家对持卡人的身份。

受监管abu计算设备被配置为基于包含在商家更新请求中的pan的列表来生成富集的商家标识符。请求pan列表与存储在交易数据库中的每个pan列表进行比较。如果发现请求pan列表是交易数据中的pan列表的子集,那么相关联的商家交易标识符被用于识别目标商家。如本文所使用的,“子集”可以指适当和不适当子集之一。

在一些实施例中,受监管abu计算设备可以使用目标商家的商家交易标识符来生成富集的商家标识符。在一些实施例中,受监管abu计算设备可以将目标商家的交易标识符与本文中称为富集数据的其它交易数据结合使用,以生成对于请求pan列表内的每个pan唯一的富集的商家标识符。富集数据可以包括最近交易的日期和/或时间、目标商家的物理地址、交易金额等等。在一些实施例中,富集数据可以由受监管abu计算设备从交易数据库检索。

在一些实施例中,受监管abu计算设备可以将商家更新请求转发到与原始请求内的每个pan相关联的每个持卡人。被转发的请求(在本文被称为abu更新请求)可以包括请求消息和持卡人响应门户。该请求消息包括富集的商家标识符,从而使得每个持卡人能够容易地识别请求商家,以及传达商家访问更新后的账户数据的愿望的文本提示。持卡人响应门户使持卡人能够选择是允许请求商家访问更新后的账户数据还是拒绝该请求。

在一些实施例中,受监管abu计算设备接收持卡人响应,生成abu响应消息并将其发送给请求商家。abu响应消息包括持卡人准予或拒绝更新请求的决定。如果请求被持卡人准予,那么abu响应消息可以包括履行请求的更新后的账户数据。如果请求被持卡人拒绝,那么abu响应消息将不提供更新后的账户数据。

本文描述的方法和系统可以使用包括计算机软件、固件、硬件或其任意组合或子集的计算机编程或工程技术来实现,其中技术效果通过执行以下至少一个来实现:(a)从商家接收对于账号集合的更新后的账户数据的请求,所述请求包括账号集合和商家标识符,所述账号列表包括一个或多个账号,所述商家标识符是非富集的商家标识符;(b)从数据库检索与一个或多个商家相关联的交易数据,这种数据包括一个或多个商家已与其进行交易的账号列表;(c)通过确定来自交易数据库的哪个商家已经与包括在商家请求中的每个账户标识符进行了交易来识别目标商家;(d)将目标商家与非富集的商家标识符关联以生成富集的商家标识符。

本文描述的系统和方法提供了以下技术优点:(a)防止由于陈旧帐户数据而导致的交易拒绝;(b)使持卡人能够控制对账户数据的访问;(c)控制和监督对abu系统的访问;以及(d)增加发卡方在abu系统中的参与。

在一个实施例中,提供了一种计算机程序,并且该程序体现在计算机可读介质上。在示例实施例中,系统在单个计算机系统上执行,而无需连接到服务器计算机。在还有的示例实施例中,系统在环境中运行(windows是redmond,washington的微软公司的注册商标)。在还有的另一个实施例中,系统在大型机环境和服务器环境上运行(unix是位于newyork,newyork的at&t的注册商标)。该应用是灵活的并且被设计为在各种不同的环境中运行,而不会影响任何主要功能。在一些实施例中,该系统包括分布在多个计算设备中的多个组件。一个或多个组件可以是体现在计算机可读介质中的计算机可执行指令的形式。该系统和过程不限于本文描述的具体实施例。此外,每个系统和每个过程的组件可以与本文描述的其它组件和过程独立地和分离地实践。每个组件和过程也可以与其它组装包和过程结合使用。

以下详细描述以示例而非限制的方式图示了本公开的实施例。预期本公开具有提供用于使持卡人能够控制对更新后的账户数据的访问的数据富集系统的普遍应用。

如本文所使用的,以单数形式叙述并且前面带有单词“一”或“一个”的元素或步骤应当被理解为不排除多个元素或步骤,除非明确叙述了这种排除。此外,对本公开的“示例实施例”或“一个实施例”的引用不旨在被解释为排除也包含所记载特征的附加实施例的存在。

金融交易卡或支付卡可以指信用卡、借记卡和预付卡。这些卡都可以用作执行交易的支付方式。如本文所述,术语“金融交易卡”或“支付卡”包括诸如信用卡、借记卡和预付卡之类的卡,但也包括可以持有支付账户数据的任何其它设备,诸如移动电话、个人数字助理(pca)和遥控钥匙(keyfob)。

图1是图示包括受监管自动计费更新器(abu)计算设备120的支付平台100的示意图。本文描述的实施例可以涉及交易卡系统,诸如使用交换网络的支付卡支付系统。交换网络是由mastercard国际公司发布的一套专有通信标准,用于交换金融交易数据以及与mastercard国际公司相关联的金融机构之间的资金结算。

在典型的交易卡系统中,被称为“发卡方”104的金融机构向消费者或持卡人102发行诸如信用卡、借记卡等的交易卡,消费者或持卡人102使用该交易卡为了从商家110的购买而进行支付。为了接受用交易卡的支付,商家110通常在作为金融支付系统的一部分的金融机构中建立账户。这个金融机构被称为“商家银行”、“收单银行”或“收单方”。在一个实施例中,针对购买金额,持卡人102为购买进行支付并且商家110然后从商家银行108(也被称为商家处理器)请求授权。该请求通常通过使用销售点终端来执行,销售点终端从持卡人102的交易卡上包括的磁条、芯片、浮雕字符等读取账户数据,并与商家银行108的交易处理计算机进行电子通信。在与在线商家交易的情况下,持卡人102可以通过网站提供账户数据,诸如个人账号(pan)、卡验证号码、到期日期等。可替代地,商家银行108可以授权第三方代表其执行交易处理。在这种情况下,销售点终端可以被配置为与第三方通信。这种第三方可以被称为“商家处理器”、“收单处理器”或“第三方处理器”。

使用支付处理器106,商家银行108的计算机可以与发卡方银行104的计算机通信,以确定持卡人102的持卡人账户112是否有良好信用以及购买是否被持卡人账户112的可用信用额度覆盖。基于这些确定,授权请求可以被拒绝或接受。如果请求被接受,那么可以向商家110发放授权码。

商家110可以将与一个或多个持卡人对应的支付卡账户数据存储在客户账户数据库111中。在某些实施例中,商家客户账户数据库111可以是商家110可访问的本地或远程数据库。在交易期间,商家110可以从商家客户账户数据库111检索账户数据,而不是从持卡人102获取数据,诸如通过让持卡人102通过刷支付卡或手动输入支付卡数据来提供他或她的支付卡账户数据。所谓的“存档账户”交易可以包括定期支付,诸如订阅费、会员费、电子账单等。存档账户交易还可以包括当持卡人102是商家110的重复客户时的实例。因而,存档账户交易一般要求持卡人最初提供他或她的支付卡账户数据,然后授权或登记存档账户服务。一旦登记或授权,持卡人102的后续支付就可以通过或者自动向持卡人102收费或通过从商家客户账户数据库111自动检索与持卡人102对应的账户数据来简化。

例如,商家110可以是向持卡人102提供互联网连接以换取每月服务费的互联网服务提供商(isp)。持卡人102可以向isp登记自动帐单支付服务以支付每月服务费。isp可以将持卡人102的账户数据存储在客户账户数据库111中,并将每月服务费用提交给发卡方104。作为另一个示例,商家110可以与持卡人102定期从其购买的在线商家对应。持卡人102可以与在线商家110创建用户简档并提供他或她的支付卡账户数据,然后在线商家可以将其存储在顾客账户数据库111中。当持卡人102稍后登录到在线商家的网站并选择商品或服务进行购买时,在线商家110可以从客户账户数据库111中检索持卡人102的支付卡账户数据并且通过自动填充购买表单或者利用检索出的账户数据执行类似步骤来方便持卡人102购买。

虽然存档账户交易为商家和持卡人都提供了改进的效率,但支付卡账户数据可以经受改变。例如,支付卡的到期日期可以过去,或者发卡方104可以向不同的主要账号(pan)重新发行支付卡。如果商家110在这种改变之后试图向发卡方104提交交易以用于授权并且使用陈旧的账户数据,那么发卡方104可能拒绝该交易。因而,受监管abu计算设备120可以被实现为确保由商家110维护的账户数据是当前的。具体而言,受监管abu计算设备120可以周期性地从一个或多个发卡方(诸如发卡方104)接收支付卡账户数据更新,并将接收到的当前支付卡账户数据存储在账户数据库180中。受监管abu计算设备120然后可以使存储的当前支付卡账户数据在请求时可用于商家110,使得商家110可以更新他们各自的客户账户数据库111。在一些实施例中,商家银行108可以将商家110更新请求累积成批,然后将其提交给受监管abu计算设备120用于处理。

受监管abu计算设备120也与支付处理器106通信,以收集并汇总交易数据。交易数据可以包括pan的列表以及pan已经与其交易的商家的列表110。交易数据由商家加索引,并且因此数据库中的每个商家110与单个pan列表相关联。交易数据还可以包括交易日期和时间、与交易相关联的物理地址、交易金额等等。交易数据存储在abu交易数据库190中,并且可以与帐户数据库180的数据一起存储,或者存储在分开的数据库中。交易数据可以包括在指定的时间窗口内(例如,在过去的九十天内)完成的交易。包括在交易数据中的商家110可以使用商家交易标识符来识别。商家交易标识符可以类似于在持卡人102交易摘要中找到的标识符,诸如可能出现在账户报表或账单中。商家交易标识符意味着是持卡人102可识别的。

受监管abu计算机设备通过第一网络连接可通信地耦合到商家110或其它请求方。受监管abu计算设备通过第二网络连接可通信地耦合到持卡人102。第一和/或第二网络连接可以包括例如局域网(lan)或广域网(wan)、拨入连接、电缆调制解调器、专用高速综合业务数字网(isdn)线路,要与移动电话网络、全球移动通信系统(gsm)、3g或其它移动数据网络或全球微波接入互操作性(wimax)一起使用的无线网络适配器或无线数据收发器。在一些实施例中,受监管abu计算设备可以可通信地耦合到支付处理器106。在一个实施例中,受监管abu计算设备与支付处理器106通信或者是支付处理器106的一部分。每个网络接口可以与ip地址信息(例如,接口ip地址和子网)来启用数据的交换。

图2是图示包括用于富集与对更新后的持卡人数据的请求相关联的商家标识符的受监管abu计算设备220的示例性多方网络系统200的示意图。在一个实施例中,受监管abu计算设备220与关于图1描述的受监管abu计算设备120相似或相同。如果商家210或其它请求方希望验证或更新用于客户个人账号(pan)列表的账户数据,那么商家更新请求230可以被提交给受监管abu计算设备220。商家更新请求230包括与商家210想要更新数据的客户账户相关联的pan列表232。商家更新请求230可以包括非富集的商家标识符234。非富集的商家标识符234可以包括识别与可容易识别的商家名称不相关并且因此可能向持卡人混淆商家的身份的数据元素。

一旦接收到商家更新请求230,受监管abu计算设备220就从交易数据库280中检索交易数据270。交易数据270包括pan列表,其中pan列表与各个商家相关联。交易数据270中的商家可以由对应的商家交易标识符来识别。将商家更新请求230中的pan列表232与存储在交易数据270中的每个pan列表进行比较。如果发现pan列表232是交易数据270中的pan列表的子集,那么使用相关联的商家交易标识符来识别目标商家。如本文所使用的,“子集”可以指适当和不适当子集之一。

例如,商家更新请求230可以包括作为非富集的商家标识符234的“fc1”,以及由以下pan组成的pan列表232:5111111、5666666、5777777、5888888。在将pan列表232与交易数据270中的pan列表进行比较时,受监管abu计算设备220将把jim的健身房识别为目标商家。

在一些实施例中,在识别出目标商家之后,受监管abu计算设备220可以生成一个或多个abu更新请求240。可以将abu更新请求240发送到其pan被包括在pan列表232中的每个持卡人202。abu更新请求240可以包括请求消息241和持卡人响应门户246。请求消息241可以包括富集的商家标识符242。在一些实施例中,受监管abu计算设备220可以使用目标商家的商家交易标识符243来生成富集的商家标识符242。在一些实施例中,受监管abu计算设备220可以将目标商家的交易标识符243与其它交易数据(本文中称为富集数据244)组合使用,以生成富集的商家标识符242。富集数据244可以包括与目标商家的最近交易的日期和/或时间、目标商家的物理地址,与目标商家的最近交易的交易金额等等。在一些实施例中,可以由受监管abu计算设备220从交易数据库280中检索富集数据244。在一些实施例中,请求消息241可以包括向消息接收者指示由富集的商家标识符242识别出的商家已提交了对更新后的账户数据的请求的文本提示。持卡人响应门户246被配置为使持卡人202能够准予247或拒绝248商家210对更新后的账户数据的请求。在一些实施例中,准予或拒绝请求的选项作为交互式触摸屏上标记为“准予”和“拒绝”的按钮出现在持卡人响应门户246内。

持卡人202或者准予247或者拒绝248商家210的数据更新请求的决定生成持卡人响应250,该持卡人响应250被发送到受监管abu计算设备220。在一些实施例中,受监管abu计算设备220接收持卡人响应250并生成包括持卡人响应数据262的abu响应消息260。持卡人响应数据262包括但不限于指示持卡人202准予或拒绝商家210访问更新后的账户数据的决定的数据。如果请求被持卡人202准予,那么abu响应消息260可以包括更新后的账户数据264,以履行原始请求。如果商家210对更新后的账户数据的请求被持卡人202拒绝,那么abu响应消息将不提供更新后的账户数据264。abu响应消息260被发送到商家210。

图3图示了如图1和图2中所示的受监管abu计算设备的示例配置300。受监管abu计算设备320包括用于执行指令的处理器304。例如,指令可以被存储在存储器区域306中。处理器304可以包括一个或多个处理单元(例如,在多核配置中)。

处理器304可操作地耦合到通信接口308,使得abu计算设备320能够与远程设备(诸如商家、持卡人、发卡方或支付处理器)通信。例如,通信接口308可以经由网络将更新请求消息发送到持卡人并将更新响应消息发送到商家。

处理器304还可以可操作地耦合到存储设备310。存储设备310是适于存储和/或检索数据的任何计算机操作的硬件。在一些实施例中,存储设备310被集成在受监管abu计算设备326中。例如,受监管abu计算设备320可以包括一个或多个硬盘驱动器作为存储设备310。在其它实施例中,存储设备310在受监管abu计算设备320外部并且可以被多个服务器计算机设备访问。例如,存储设备310可以包括多个存储单元,诸如在廉价磁盘冗余阵列(raid)配置中的硬盘或固态盘。存储设备310可以包括存储区域网络(san)和/或网络附连存储(nas)系统。

在一些实施例中,处理器304经由存储接口312可操作地耦合到存储设备310。存储接口312是能够向处理器304提供对存储设备310的访问的任何组件。存储接口312可以包括例如高级技术附件(ata)适配器、串行ata(sata)适配器、小型计算机系统接口(scsi)适配器、raid控制器、san适配器、网络适配器和/或能够向处理器304提供对存储设备310的访问的任何组件。

存储器区域306可以包括但不限于诸如动态ram(dram)或静态ram(sram)的随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom)、电可擦除可编程只读存储器(eeprom)和非易失性ram(nvram)。上述存储器类型仅仅是示例性的,因此不限制可用于存储计算机程序的存储器的类型。

图4是用于富集与对更新后的持卡人数据的请求相关联的商家标识符的方法400的流程图。在示例实施例中,方法400由受监管abu计算设备(诸如关于图2描述的受监管abu计算设备220)执行。在某些实施例中,方法400可以至少部分地由不同的计算设备执行。在其它实施例中,方法400可以包括附加的、更少的或替代的动作,包括本文描述的那些动作。

在402中,受监管abu计算设备接收商家对更新后的账户数据的请求。该请求可以包括例如个人帐号(pan)的列表和非富集的商家标识符。在一个实施例中,受监管abu计算设备检索(404)与一个或多个商家相关联的交易数据。交易数据可以包括由商家交易标识符识别的一个或多个商家。交易数据还可以包括商家与其进行交易的pan列表。受监管abu计算设备将商家请求中的pan列表与交易数据中的pan列表进行比较,以识别(406)目标商家。受监管abu计算设备可以将目标商家的商家交易标识符与其它交易数据结合使用,以生成(408)富集的商家标识符。商家更新请求被受监管abu计算设备转发(410)给持卡人并且包括富集的商家标识符。受监管abu计算设备从持卡人接收(412)更新请求被准予或拒绝的确认。如果更新请求被准予,那么受监管abu计算设备可以向请求商家提供(414)更新后的账户数据。如果更新请求被拒绝,那么受监管abu计算设备可以向商家通知(416)更新请求被拒绝。

如基于前述说明书将意识到的,本公开的上述实施例可以使用包括计算机软件、固件、硬件或其任意组合或子集的计算机编程或工程技术来实现。根据本公开的所讨论的实施例,具有计算机可读代码装置的任何此类结果得到的程序可以在一个或多个计算机可读介质内被体现或提供,由此制造计算机程序产品(即,制造品)。计算机可读介质可以是例如但不限于固定(硬)驱动器、软盘、光盘、磁带、半导体存储器(诸如只读存储器(rom))和/或任何发送/接收介质(诸如互联网或其它通信网络或链路)。包含计算机代码的制造品可以通过直接从一种介质执行代码、通过将代码从一种介质复制到另一种介质或者通过经网络发送代码来制造和/或使用。

计算机程序(也称为程序、软件、软件应用、“应用”或代码)包括用于可编程处理器的机器指令,并且可以以高级过程性和/或面向对象的编程语言和/或汇编/机器语言来实现。如本文所使用的,术语“机器可读介质”、“计算机可读介质”是指用于向可编程处理器提供机器指令和/或数据的任何计算机程序产品、装置和/或设备(例如,磁盘、光盘、存储器、可编程逻辑设备(pld)),包括接收机器指令作为机器可读信号的机器可读介质。但是,“机器可读介质”和“计算机可读介质”不包括瞬态信号。术语“机器可读信号”是指用于向可编程处理器提供机器指令和/或数据的任何信号。

例如,一个或多个计算机可读存储介质可以包括体现在其上的用于富集包括在账户更新请求内的商家标识符的计算机可执行指令。在这个示例中,计算设备可以包括存储器设备和与存储器设备通信的处理器,并且当由处理器执行时,计算机可执行指令可以使处理器执行方法(诸如在图2的示例中描述和示出的方法)。

如本文所使用的,术语“处理器”是指能够执行本文描述的功能的中央处理单元、微处理器、微控制器、精简指令集电路(risc)、专用集成电路(asic)、逻辑电路和任何其它电路或处理器。

本书面描述使用示例来描述包括最佳模式的本公开的实施例,并且还使得本领域的任何技术人员能够实践本公开,包括制造和使用任何设备或系统以及执行任何包含的方法。本公开的专利范围由权利要求限定,并且可以包括本领域技术人员想到的其它示例。如果这些其它示例具有不与权利要求的字面语言不同的结构元件,或者如果它们包括与权利要求的字面语言无实质区别的等同结构元件,那么这些其它示例意欲在权利要求的范围内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1