用于通过性质图形模型生成关系的系统和方法与流程

本申请要求于2015年8月18日提交的美国专利申请第14/829,219号的申请日的优先权和权益，其全部内容通过引用合并于此。

背景技术：

本发明的领域一般涉及商家和持卡人之间的链接的计算机化生成，更具体地，涉及用于使用基于交易数据的图形数据库在商家和持卡人之间生成连接的系统和方法。

作为背景，交易数据(例如支付数据)可以包括由支付卡处理器通过支付网络处理的数据。通常，这些交易数据到达支付处理器并作为单独记录以分离的形式存储在数据仓库中。单独的记录可以存储在数据库中，使用唯一标识符连接表格式记录。因此，用于对这样的交易数据建模的大多数模型都基于各个实体(即，卡、商家等)的性质。

但是，通过以表形式保持交易数据，例如在关系数据库表中，会损失大量信息和洞察力。检测单个记录是否以任何有用的方式在表之间连接是很麻烦的。更具体地说，很难确定例如存储在分离的表中的商家记录或支付卡是否表现出任何共同的特征或链接。至少有一些已知的将表格式数据互连的方法涉及到连接多个表。然而，对于包含数百万或数十亿记录(例如商家和支付卡的记录)的大数据集，连接多个表以提取任何有用的信息即使不是不可能也会变得单调乏味。

技术实现要素：

在一个方面，提供了一种生成存储在图形数据库中的图形数据分量的方法。该方法使用与存储器通信的图形分量生成器计算设备来实现。该方法包括：从关系数据库接收交易数据，其中交易数据从多个商家中的至少第一商家和多个持卡人中的第一持卡人之间的交易导出，该交易由支付处理器处理，限定图形，包括至少创建表示至少第一商家的第一节点和表示第一持卡人的第二节点，至少部分地基于包括图形中的第一节点和第二节点的至少两个节点共同的交易数据来识别所述至少两个节点之间的至少一个关系，并且生成表示至少两个节点之间的新关系的至少两个节点之间的至少一个边。

在另一方面，提供了一种用于生成存储在图形数据库中的图形数据分量的系统。该系统包括配置成以图形格式存储交易数据的图形数据库和配置成耦接到图形数据库的图形分量生成器计算设备(GCG)。GCG还被配置为从关系数据库接收交易数据，其中交易数据从多个商家中的至少第一商家和多个持卡人中的第一持卡人之间的交易导出，该交易由支付处理器处理，限定图形，包括至少创建表示至少第一商家的第一节点和表示第一持卡人的第二节点，至少部分地基于包括图形中的第一节点和第二节点的至少两个节点共同的交易数据来识别所述至少两个节点之间的至少一个关系，并且生成表示至少两个节点之间的新关系的至少两个节点之间的至少一个边。

在又一方面，提供了一种包括用于生成存储在图形数据库中的图形数据分量的计算机可执行指令的非暂时性计算机可读介质。当由图形分量生成器计算设备(GCG)执行时，计算机可执行指令使得GCG从关系数据库接收交易数据，其中交易数据从多个商家中的至少第一商家和多个持卡人中的第一持卡人之间的交易导出，该交易由支付处理器处理，限定图形，包括至少创建表示至少第一商家的第一节点和表示第一持卡人的第二节点，至少部分地基于包括所述图形中的所述第一节点和所述第二节点的至少两个节点共同的交易数据来识别所述至少两个节点之间的至少一个关系，并且生成表示至少两个节点之间的新关系的至少两个节点之间的至少一个边。

附图说明

图1是示出用于授权存储在图形数据库中的支付卡交易的示例多方交易卡行业系统的示意图。

图2是包括示例图形分量生成器(GCG)设备和关联的图形数据库的示例环境100的简化框图。

图3示出了诸如图2所示的GCG计算设备170的服务器系统的示例配置，用于在图形数据库中生成和维护链接。

图4示出了来自支付卡交易的数据借以被转换成图形数据库格式的示例性数据流400。

图5示出了被转换成图形数据库形式的交易数据的示例性配置500。

图6示出了图形数据库中的节点的示例性配置600，其具有由GCG计算设备生成的某些边。

图7是GCG计算设备通过其在图形数据库中生成新边的示例方法700。

图8示出了计算设备内的数据库的示例配置，该计算设备可以与其他相关的计算组件一起用于生成和维护图形数据库。

图中的相似数字表示相同或功能相似的组件。

具体实施方式

本公开涉及商家性质图形数据库，并且更具体地涉及被配置为识别填充有商家、持卡人和交易数据的图形数据库中的不同点之间的关系的图形分量生成器(GCG)计算设备。持卡人可以包括由例如发卡银行发行的支付卡或支付卡账户的任何持有人。商家包括具有提供商品或服务供销售的实体店或网上商店的任何人。在示例性实施例中，从商家和持卡人之间的支付卡交易生成的交易数据(以及与商家和持卡人有关的关联数据)从关系数据库形式(例如表)转换成图形数据库。随着时间的推移，图形数据库将使用来自关系数据库的更新数据进行刷新。在其他实施例中，交易数据直接输入到图形数据库格式中，而不需要中介的关系数据库。

在示例性实施例中，图形数据库将数据存储在图形结构中，即以“节点”和连接节点的“边(edge)”的形式。节点(也称为顶点)是图形中表示包含一个或多个称为“属性(attribute)”(也称为性质(property))的数据点的连接实体的点。在至少一些实现方式中，每个属性被存储为键值对(例如，“名称：Tasty Subs”，“类型：商家”，“子类型：餐馆”等)。节点可以表示单个实体或包含许多子实体的聚合实体。节点可以用一个或多个“标签”来标记，“标签”可以用来将节点分组在一起。

在示例性实施例中，边限定两个节点之间的链接、关系或连接。根据两个节点的属性，节点之间可能会形成不同的边。边可以类似节点进行标记。在一个实施例中，边表示两个节点之间的指向关系。例如，持卡人与商家的交易可以由从持卡人指向商家的标有“IS_CUSTOMER_OF”的边表示。边也可能是无向的。例如，如果两个节点对于特定属性具有共同的值，则可以在节点之间形成边，表示该共同性。

商家属性图形数据库包括表示至少商家和持卡人的节点，以及表示商家和持卡人之间的关系的边。还可能存在表示节点组的聚合节点，即由于共同所有权、地理位置等而被分组在一起的一组商家或持卡人。在至少一些实现方式中，每个节点被标记并且包括与被表示的实体有关的属性，这些属性被存储为键值对。

在至少一些实现方式中，图形数据库被存储在计算设备上，该计算设备与一个或多个与支付处理器关联的计算设备通信。在一些实施例中，支付处理器计算设备是较大的支付处理网络的一部分，该较大的支付处理网络可以包括与商家、发行银行、收单银行和其他交易服务提供商相关联的计算设备。支付处理器处理持卡人在商家位置使用发给持卡人的支付卡执行的交易。交易数据作为每个交易的结果而生成，包括例如交易日期、交易时间、商家名称或其他标识符以及支付卡细节(卡号、到期日期等)。在一个实施例中，支付处理器将交易数据存储在关系数据库中(例如，以具有数据类型的列和单独的数据记录的行的表的形式)。关系数据库存储在与支付处理网络通信的数据库计算设备上。在至少一些实现方式中，交易数据从关系数据库转换到商家性质图形数据库。在一个实施例中，图形分量生成器(GCG)计算设备与图形数据库通信并且因此可以访问从支付处理器接收的交易数据。在另一个实施例中，GCG计算设备是支付处理网络的成员，并且可以通过支付处理网络计算机以及从图形数据库直接访问交易数据。

在一个实施例中，将交易数据从关系数据库转换成图形数据库涉及首先将关系数据库中的每个表表示为标签。GCG计算设备将表中的每一行转换为图形数据库中的节点，并对其进行适当标记。表中的每一列都被转换成节点的属性。例如，关系数据库中的持卡人表可以转换为一系列节点，每个节点标记为“持卡人”。然后，每个节点表示表中的持卡人。例如，行1包含关于持卡人的数据(例如，主账号或PAN)，对应列保持附加数据(例如，发行银行、卡类型/产品类型等)。这转换为PAN的一个节点，标记为持卡人，具有用于该持卡人的PAN、发行银行、卡类型/产品类型、首次见到日期等中的每一个的键值对的形式的属性。根据用户偏好，GCG计算设备还基于地理区域、商家类别、卡段或者甚至通过支付处理网络服务来生成聚合节点。例如，可能存在标记为“圣路易斯的所有沃尔玛商店”，“所有体育用品商店”，“使用支付网络A的所有持卡人”，“使用支付网络服务B的所有持卡人”等的节点。在至少一些实现中，GCG计算设备还分层地组织地理区域节点，例如按国家、州、城市等。

在一些实施例中，使用数据库连接(join)操作将关系数据库表彼此“连接”，所述数据库连接操作基于它们之间的共同列或字段链接来自分离表的行。GCG计算设备被配置为将表之间存在的任何连接关系转换成图形数据库中的边。例如，在持卡人表连接到商家表的情况下，GCG计算设备将该连接关系转换成每个持卡人连接到持卡人已经访问的每个商家的的边。此外，例如，持卡人可能访问了名为Metro Toy Store的商家。因此，标记为“Metro Toy Store”的节点被创建，其的创建利用例如商家ID：M0001，名称：Metro Toy Store，位置：123大街(123Main Street)，与商家节点相关或连接的任何聚合商家(例如，Big Toy公司)以及发生在商家位置的交易的交易数据的属性。GCG计算设备创建从The Metro Toy Store节点指向该持卡人的PAN节点的边，其中该边被标记为“IS_VENDOR_OF”并且可以具有例如“transactioncount(交易计数)：6”，transactionamount(交易金额)：$300，“firsttransaction(首次交易)：20150520/09：00”等属性。在其他实施例中，GCG计算设备利用上述属性创建从该持卡人的PAN节点指向标记为“IS_CUSTOMER_OF”的Metro Toy Store的边。在其他实施例中，两个边可以在卡PAN节点和Metro Toy Store之间创建，或者可以创建单个无向边，例如被标记为“交易(TRANSACTIONS)”。

在至少一些实现方式中，如上所述，交易数据在图形数据库中生成多个关系。然而，检测要不是这样而未连接的节点之间的关系是困难的或不可能的。例如，给定特定的商家节点，很难确定例如“我的持卡人访问的其他商家”的关系，或者给定特定的持卡人，很难确定例如“像我这样的持卡人应该访问的推荐商家”的关系。将交易数据从关系数据库形式转换成图形数据库可以高效地确定许多新的关系和连接。

因此，GCG计算设备被配置成基于识别节点之间存在的特征或共同性来生成存在于图形数据库中的节点之间的新边。将交易数据从关系数据库形式转换为图形数据库会创建多个边。GCG计算设备被配置为连同与图形中的每个点相关联的数据来使用这种现有的关系数据并生成新的边。在至少一些实现方式中，GCG计算设备被配置为接收图形数据库的一部分，包括多个节点和边。GCG计算设备还接收限定用户感兴趣的共同性或模式的排序(sort)的用户输入。例如，用户可能希望知道与特定商家B共享持卡人X的商家A，并且也可能希望知道商家A的持卡人Y。GCG计算设备被配置为接收用户的查询作为输入并且遍历图形数据库以搜索与查询相匹配的商家A和B。

在确定商家A和B后，GCG计算设备遍历从两个商家节点到所有连接的持卡人节点的边。在检索到所有连接的持卡人之后，GCG计算设备过滤出具有到商家A和B的边的持卡人节点，并将这些持卡人节点作为持卡人X返回给用户。此外，GCG计算设备被配置为在商家A和商家B之间生成边。GCG计算设备还被配置为在商家B和持卡人Y之间生成边。GCG计算设备还为每个边生成标签。例如，商家A-商家B边可以被标记为“CO_VENDOR”。商家B-持卡人Y边可以被标记为“RELATED_CARDHOLDERS”。CGG计算设备还被配置为生成每个边的属性值，该属性值从涉及的节点的属性导出。例如，“CO_VENDOR”边可以具有例如从商家A和B处发生的持卡人X的所有交易中导出的“由持卡人X进行的总交易”的属性。GCG计算设备被配置为用这些新创建的边更新图形数据库。

除了生成边之外，GCG计算设备还被配置为生成可能不出自交易数据的节点。例如，交易数据产生商家和持卡人的节点，但是GCG计算可以生成新节点，例如“圣路易斯周五最多受访餐厅”，“前往餐厅A和电影院B的所有持卡人”，等等。

另外，GCG计算设备被配置为基于所生成的边来生成有用的数据。例如，使用“持卡人X进行的全部交易”属性，GCG计算设备被配置为生成“共同访问(co-visit)”和“访问序列”数据。本领域技术人员将会理解，可以使用交易数据来生成许多其他边，例如“出售给我的持卡人的商家的持卡人”，“出售给出售给我的持卡人的商家的持卡人的商家”，等等。

在至少一些实现方式中，共同访问数据指的是持卡人在预定时间段内(例如在同一小时内、同一天内或同一个月或者支付卡开账周期内)与两个或更多商家交易的实例的交易数据。GCG计算设备被配置为接收关于这样的共同访问的查询输入并且生成标记为例如“CO_VISITED”的两个或更多个商家之间的边。在这段时间内的交易被称为“共同访问交易”并且该交易对于提供对例如持卡人喜欢一起购买的商品和服务的洞察是有用的。

在至少一些实现方式中，访问数据序列指的是持卡人以特定顺序或序列与两个或更多个商家交易的实例的交易数据。例如，持卡人可能总是按照访问特定的餐厅，然后访问特定的电影院这样的顺序。GCG计算设备被配置为接收关于这样的序列的查询输入并且创建例如两个或更多个商家之间的指向边。该边可以从首先被访问的商家指向第二个被访问的商家，并被标记为例如“IS_VISITED_BEFORE”或相反指向并被标记为“IS_VISITED_AFTER”。

在至少一些实现方式中，GCG计算设备被配置为将图形数据库的一部分呈现为抽象。例如，可能需要仅查看持卡人节点，或仅查看商家节点，或仅查看通过共同访问边而链接的商家节点。在至少一些实现方式中，GCG计算设备被配置为检索关于其生成的边的数据。例如，用户可以向GCG计算设备查询所有被共同访问的商家。GCG计算设备被配置为基于例如在特定地理或时间范围内的共同访问的输入要求而遍历整个图形并且返回标记为“CO_VISIT”的所有边和链接商家的列表。

在其他实现方式中，GCG计算设备被配置为每当新数据被添加到图形时而不是如上所述在查询时自动生成与特定标准匹配的所有可能的边。例如，当新的持卡人被添加到图形数据库中时，GCG计算设备被配置为查询与该持卡人相关联的属性，包括持卡人的交易数据。GCG计算设备被配置为基于交易数据中的每个交易自动在持卡人和所有商家节点之间生成边(例如，IS_CUSTOMER_OF)。本领域的技术人员将认识到，添加新的持卡人和基于交易数据的边可以导致GCG计算设备生成与共同访问和访问序列相关的新边。例如，GCG计算设备可以检测到新添加的持卡人节点具有将其连接到两个特定商家的IS_CUSTOMER_OF边，并且GCG计算设备可以确定该持卡人在过去例如同一天内访问过商家。如果是这样，则GCG计算设备被配置为在两个商家之间生成新的CO_VISIT边，其中先前可能没有存在过。如前所述，GCG计算设备的用户然后可以检索这个新的CO_VISIT边和相关联的商家，以获得关于哪些商家一起访问的有用知识。

在至少一些实现方式中，GCG计算设备被配置为至少通过给某些边赋予比其他边更高的权重值来使某些边优先于其他边。权重值是边的一个属性，可以是数值、百分比或对频谱的任何评估(颜色、字母等级等)，从而允许GCG计算设备按权重划分边优先级。在示例性实施例中，权重值表示交易的频率。例如，商家可能已经参与了与持卡人1的十次交易，但是与持卡人2进行了十五次交易。因此，GCG计算设备将被标记为IS_CUSTOMER_OF的商家-持卡人2边赋予比对应的商家-持卡人1边更高的权重值。

在其他实施例中，GCG计算设备被配置为相比比较老的边赋予更新的边较高优先级。例如，GCG计算设备使用由S_n＝qC_n+(1-q)S_n-1给出的加权和，其中在第n天的交易计数为C_n，直到第n-1天的加权和为S_n-1，并且q是介于0和1之间的加权因子。与S_n-1相比，即较老的交易，“q”的值越高，C_n(即更近期的交易)在确定边时将被赋予更大的权重。

GCG计算设备被配置为用于基于上述GCG计算设备的边和节点生成功能而被实现的多个应用中。在一个实施例中，GCG计算设备被配置为提供给特定用户定制的推荐。例如，如果持卡人C1和C2都喜欢在商家M1和M2购物，并且C1还喜欢在M3购物，那么C2很可能也喜欢M3。在这种情况下，GCG计算设备被配置为在C2和M3之间生成边，并且将C2-M3边呈现给用户用于向持卡人C2提供M3的推荐的目的。

在其他实施例中，GCG计算设备也可以用于目标市场营销用途。例如，如果商家M1具有顾客C1并且M2具有顾客C1和C2，则M1可能希望也向C2发送促销优惠，因为C2可能与C1具有相似的品味。因此，GCG计算设备在M1和C2之间生成边并将该新边呈现给系统的用户，用于向商家M1提供营销策略的目的。在另一个实施例中，GCG计算设备可以利用“访问序列”数据，但是这次以相反的顺序。访问序列数据揭示持卡人只有在访问特定其他商家后才访问特定商家，而后一商家可能希望与在其之前被访问的商家进行协作或交叉促销。

在其他的实施例中，GCG计算设备可以被配置为查找潜在商家以注册由支付处理网络提供的特定服务。例如，商家M1可以签约特定的支付处理网络服务，并且图形数据库可以揭示该服务改善了商家的业务，例如以增加销售额的形式。如果是这样，与M1共享客户的另一商家M2可能是相同支付处理网络服务的良好候选者。因此，GCG计算设备可以将与M2共享客户的一个或多个商家返回给用户以提供给支付处理网络，以便提高服务的采用。

在另外的实施例中，GCG计算设备被配置为辅助账户数据泄露(或欺诈)检测。例如，多个持卡人可能报告欺诈、身份盗窃或其他损失(例如，向发行卡的发行银行或附属支付处理网络报告)事件。GCG计算设备被配置为使用这些持卡人的节点作为输入来遍历图形数据库，并尝试定位所有持卡人共有的单个节点或一组节点。例如，所有已报告欺诈的持卡人都可能与特定商家进行了交易。使用GCG计算设备遍历图形数据库可以快速揭示特定商家是欺诈事件的可能来源。

GCG计算设备也可以用作反推荐器。例如，交易数据可以揭示持卡人与新的或不熟悉的商家的交易。GCG计算设备可以被配置为遍历图形数据库并且确定图形数据库中持卡人节点与商家节点之间的距离是否超过预定阈值。该阈值表示持卡人与该商家进行交易的可能性。例如，如果该持卡人和具有相似交易历史的其他持卡人的节点将需要大量遍历以到达商家节点，则可能表明该交易是欺诈性的，因为持卡人可能不会自愿与该商家进行交易。例如，商家可能在国外，或者持卡人通常不会去的类型等等。

该系统解决的技术问题中的至少一个包括难以或无法使用关系数据库检测不同商家和持卡人之间的相互关系。关系数据库通常将数据存储在二维(行-列)表中，该表允许从表内快速检索数据，但不能实现特定表之外的数据的可见性。检测分离的表中的数据之间的连接或关系需要表连接操作，这些操作很快会变得编码繁琐。更糟糕的是，随着每次接连的连接操作，系统性能急剧下降。随着支付卡交易表的规模达到数十亿行，并且拥有数百万商家和持卡人，确定例如与源商家或持卡人相距超过一度或两度的关系会变得非常慢并且困难。另一个技术问题是，如果不先进行复杂的连接和过滤操作，则无法分析关系数据库的隔离部分。

本文描述的方法和系统可以使用包括计算机软件、固件、硬件或其任何组合或子集的计算机编程或工程技术来实现，其中技术效果可以通过执行以下步骤中的至少一个来实现：(a)从关系数据库接收交易数据，其中交易数据是从多个商家中的至少第一商家和多个持卡人中的第一持卡人之间的交易中导出的，所述交易由支付处理器进行处理，(b)限定图形，包括至少创建表示至少第一商家的第一节点和表示第一持卡人的第二节点，(c)至少部分地基于图形中包括第一节点和第二节点的至少两个节点共同的交易数据来识别所述至少两个节点的至少一个关系，(d)在所述至少两个节点之间生成至少一个边，表示所述至少两个节点之间的新关系。

由该系统实现的产生的技术益处包括以下至少一个：(i)快速高效地搜索交易数据以基于特定持卡人和商家之间的相互关系来检索特定持卡人和商家，(ii)检测持卡人与商家之间、商家与商家之间等的新关系(例如，共同访问，访问序列)的能力，(iii)为持卡人、商家以及甚至支付处理网络生成推荐的能力，以及(iv)高效检测欺诈的能力。

如这里所使用的，处理器可以包括任何的可编程系统，包括使用微控制器、精简指令集电路(RISC)、专用集成电路(ASIC)、逻辑电路以及能够执行本文描述的功能的任何其他电路或处理器的系统。以上示例仅是示例，因此不旨在以任何方式限制术语“处理器”的定义和/或含义。

如这里所使用的，术语“软件”和“固件”是可互换的，并且包括存储在存储器中供处理器执行的任何计算机程序，存储器包括RAM存储器、ROM存储器、EPROM存储器、EEPROM存储器和非易失性RAM(NVRAM)存储器。上述存储器类型仅是示例，因此对于可用于存储计算机程序的存储器的类型不是限制性的。

在一个实施例中，提供了一种计算机程序，该程序实现在计算机可读存储介质上。在示例实施例中，系统在单个计算机系统上执行，而不需要连接到服务器计算机。在另一个实施例中，系统在环境(Windows是华盛顿州雷德蒙德的微软公司的注册商标)中运行。在又一个实施例中，该系统在大型机环境和服务器环境(UNIX是位于英国Berkshire的Reading的X/Open Company Limited的注册商标)上运行。该应用程序非常灵活，设计成可以在各种不同的环境中运行，而不会影响任何主要功能。在一些实施例中，该系统包括分布在多个计算设备中的多个组件。一个或多个组件可以是实现在计算机可读介质中的计算机可执行指令的形式。该系统和过程不限于这里描述的具体实施例。另外，每个系统和每个过程的组件可以独立实践并与本文描述的其他组件和过程分离。每个组件和过程也可以与其他组装程序和过程结合使用。

以下详细描述以示例而非限制的方式示出了本公开的实施例。预期本公开对工业、商业和住宅应用中的金融交易具有普遍适用性。

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

图1是示出用于授权支付卡交易的示例多方交易卡行业系统20的示意图，支付卡交易存储在图形数据库中并使用GCG计算设备来检索。这里描述的实施例可以涉及交易卡系统，例如使用交换网络的信用卡支付系统。交换网络是由(MasterCard International )颁布的一套专有通信标准，用于金融交易数据交换以及作为MasterCard International 成员的金融机构之间的资金结算。(万事达卡(MasterCard)是位于纽约帕切斯的万事达卡国际公司的注册商标)。

在典型的交易卡系统中，被称为“发行者”的金融机构向顾客或持卡人22发放例如信用卡之类的交易卡，顾客或持卡人使用交易卡为从商家24的购买进行。为了接受使用交易卡的付款，商家24通常必须向作为金融支付系统的一部分的金融机构建立账户。该金融机构通常被称为“商家银行”、“收单银行”或“收单机构”。持卡人22使用交易卡为购买进行支付，然后商家24从商家银行26请求对购买金额授权。该请求可以通过电话来执行，但通常通过使用销售点终端来执行，所述销售点终端从交易卡上的磁条、芯片或压印字符中读取持卡人22的账户信息，并以电子方式与商家银行26的交易处理计算机进行通信。可替代地，商家银行26可授权第三方代表其执行交易处理。在这种情况下，销售点终端将被配置为与第三方进行通信。这样的第三方通常被称为“商家处理器”、“收单处理器”或“第三方处理器”。

使用交换网络28，商家银行26的计算机或商家处理器将与发行方银行30的计算机进行通信以确定持卡人22的账户32是否信誉良好以及该购买是否被持卡人22的可用信用额度覆盖。根据这些确定，授权请求将被拒绝或接受。如果请求被接受，授权代码被发给商家24。

当接受授权请求时，持卡人22的账户32的可用信用额度减少。通常，支付卡交易的费用不会立即过账到持卡人22的账户32，因为例如MasterCard International的银行卡协会已颁布了在货物运送或服务交付之前不允许商家24对交易进行收费或“捕获”交易的规则。但是，对于至少一些借记卡交易，收费可能在交易时过账。当商家24运送或交付货物或服务时，商家24通过例如在销售点终端上的适当数据输入程序来捕获交易。这可能包括每天为标准零售购买捆绑批准的交易。如果持卡人22在交易被捕获之前取消交易，则生成“空白(void)”。如果持卡人22在交易被捕获后返还商品，则产生“借贷(credit)”。交换网络28和/或发行方银行30在数据库120(图2中示出)中存储交易卡信息，例如商家类型、购买金额、购买日期。

数据库120可以存储作为在处理网络上进行的销售活动和储蓄活动的一部分而产生的交易数据，包括与商家、持卡人或顾客、发行方、收单方和/或所进行的购买有关的数据。在一个实施例中，数据库120以关系数据库形式，即以多个二维表的形式存储交易数据。每个表可以包括行和列，其中行保持单独的记录并且列存储每个记录的各个数据点(例如，对于商家记录来说，商家ID、名称、地址等)。

数据库120还可存储商家数据，包括标识经注册以使用网络的每个商家的商家标识符，以及用于结算交易的指令，包括商家银行账户信息。数据库120还可以存储与持卡人从商家购买的物品相关联的购买数据以及授权请求数据。

在进行了购买之后，发生清算过程以在交易各方(例如商家银行26、交换网络28和发行方银行30)之间转移与购买有关的额外交易数据。更具体地，在清算过程期间和/或之后，例如购买时间、商家名称、商家类型、购买信息、持卡人账户信息、交易类型、储蓄信息、路线信息、关于所购物品和/或服务的信息和/或其他合适的信息之类的附加数据与交易相关联并作为交易数据在交易各方之间传输，并且可以由交易的任何一方存储。

在交易被授权并清算之后，交易在商家24、商家银行26和发行方银行30之间结算。结算指的是与交易有关的商家24的账户、商家银行26和发行方银行30之间的金融数据或资金的转移。通常情况下，交易被捕获并累积为“批次”，并以组形式进行结算。更具体地说，交易通常在发行银行30和交换网络28之间，然后在交换网络28和商家银行26之间，然后在商家银行26和商家24之间结算。

如上所述，支付卡交易的各方包括图1所示的一方或多方，例如持卡人22、商家24、商家银行26、交换网络28(在本文中也被称为支付处理器28)、发行方银行30和/或发行方处理器21。

此外，交换网络28可以收集支付卡交易的交易数据并将其存储到例如图形数据库的内部数据库中。GCG计算设备分析图形数据库，生成图形分量(节点和边)，并且为持卡人(例如持卡人22)和/或商家(例如商家24)实现特定服务，例如推荐和欺诈检测。

图2是包括示例图形分量生成器设备和关联的图形数据库的示例环境100的简化框图。环境100示出了图形分量生成器(GCG)计算设备170。GCG计算设备170与至少一个图形数据库160和支付处理器112进行通信。在示例性实施例中，GCG计算设备170被配置为对存储在图形数据库中的交易数据至少执行创建，读取，更新和删除操作。在一个实施例中，GCG计算设备170是支付处理器112的成员或一部分。在另一个实施例中，GCG计算设备170在支付处理器112的外部和/或与其通信。

在一个实施例中，支付处理器112与商家计算设备118通信。商家计算设备包括销售点(POS)设备118a和网站118b。POS设备118a包括设计成接收在交易期间传输的账户数据的任何设备。商家还运营持卡人可以使用类似于用户计算设备170的计算设备访问和购买商品和服务的网站118b，计算设备将网站118b传输。在一个实施例中，商家的实体位置和网站由图形数据库160中的单独节点表示。在另一个实施例中，实体位置和网站由单个节点表示。

在一个实施例中，支付处理器112表示全部通过LAN/WAN网络150进行通信的包括数据库服务器116、应用服务器125、web服务器126、邮件服务器132、认证服务器128和目录服务器130的一组互连的计算机。在示例性实施例中，支付处理器112经由互联网连接148与外部计算机进行通信。认证服务器128与位于远程的系统(例如用户计算设备170)进行通信。认证服务器128还被配置为与其他工作站138、140和142进行通信。

支付处理器112还与计算机114通信，在示例性实施例中，计算机114与发行支付卡给持卡人的发行银行和/或为商家保持账户的收单银行相关联。计算机114通过许多接口与网络互连，接口包括例如局域网(LAN)或广域网(WAN)的网络115、拨入连接、电缆调制解调器、专用高速综合业务数字网络(ISDN)线路和RDT网络。计算机114可以是能够互连到互联网的任何设备，包括移动设备、台式或膝上型计算机，或其他基于web的可连接设备。在一个实施例中，支付处理器112向和自计算机114传送交易数据。

数据库服务器116连接到数据库120，如下面更详细描述的，数据库120包含关于各种事项的信息。在一个实施例中，数据库120存储在支付处理器112上，并且可以由支付处理器112或GCG计算设备170的潜在用户访问。在替代实施例中，数据库120远离支付处理器112存储，并且可以是非集中式的。

数据库120可以包括具有分离的部分或分区的单个数据库，或者可以包括多个数据库，每个数据库彼此分离。数据库120可以存储作为在处理网络上进行的销售活动和储蓄活动的一部分而产生的交易数据，包括与商家、持卡人或顾客、发行方、收单方和/或所进行的购买有关的数据。在一个实施例中，数据库120以关系数据库形式，即以多个二维表的形式存储交易数据。每个表可以包括行和列，其中行保持单独的记录并且列存储每个记录的各个数据点(例如，对于商家记录来说，商家ID、名称、地址等)。在一些实施例中，使用数据库连接操作将关系数据库表彼此“连接”，所述数据库连接操作基于自分离表的行之间的共同列或字段来链接来自分离表的行。

数据库120还可存储商家数据，商家数据包括标识经注册以使用网络的每个商家的商家标识符，以及用于结算交易的指令，包括商家银行账户信息。数据库120还可以存储与持卡人从商家购买的物品相关联的购买数据以及授权请求数据。

在示例实施例中，计算机114中的一个可以与收单方银行相关联，而计算机114中的另一个可以与发行方银行30相关联(在图1中示出)。计算机114可以包括第三方计算机146以及发行方设备138、140和142。在示例实施例中，支付处理器112与例如交换网络28的交换网络相关联，并且可以被称为交换计算机系统或支付处理计算设备。支付处理器112可以用于处理交易数据。另外，计算机114可以包括与在线银行、账单支付外包商、收单方银行、收单方处理器、与交易卡相关联的发行方银行、发行方处理机、远程支付系统、令牌请求方、令牌提供方和/或开账方中的至少一个相关联的计算机系统。

在示例实施例中，GCG计算设备170不由通用计算机硬件组成，也不需要仅通用的计算机指令来执行上述功能。而是，GCG计算设备170是特定且定制的计算机设备，其被构建为执行操纵存储在图形数据库中的数据的特定功能并且生成不是由填充图形数据库的交易数据引起的图形数据库节点之间的新的关系。在示例实施例中，GCG计算设备170被配置为以特定方式与图形数据库160和支付处理器112通信。GCG计算设备170被特别地配置为执行本文描述的数据操纵任务中的一个或多个，例如从关系数据库接收交易数据，其中交易数据从由支付处理器处理的、多个商家中的至少第一商家与多个持卡人中的第一持卡人之间的交易导出，限定图形，包括至少创建表示至少第一商家的第一节点和表示第一持卡人的第二节点，至少部分地基于图形中包括第一节点和第二节点的至少两个节点共同的交易数据来识别所述至少两个节点的至少一个关系，以及在所述至少两个节点之间生成表示至少两个节点之间的新关系的至少一个边。

图3示出了例如图2所示的GCG计算设备170的服务器系统的示例配置，所述服务器系统用于在图形数据库中生成和维护链接。服务器系统301可以包括但不限于数据库服务器116、图形数据库160或GCG计算设备170(如图2所示)。

服务器系统301包括用于执行指令的处理器305。例如，指令可以存储在存储区域310中。处理器305可以包括用于执行指令的一个或多个处理单元(例如，以多核配置)。指令可以在服务器系统301上的各种不同的操作系统内执行，例如UNIX、LINUX、Microsoft等。还应该理解，在开始基于计算机的方法时，可以在初始化期间执行各种指令。为了执行在此描述的一个或多个过程，可能需要一些操作，而其他操作可能更通用和/或对于特定编程语言(例如，C，C#，C++，Java，Python，JavaScript或其他合适的编程语言等)特定。

处理器305操作性地耦接到通信接口315，使得服务器系统301能够与例如用户系统或另一服务器系统301的远程设备通信。例如，通信接口315可以经由互联网与商家计算设备118和计算机114进行通信，如图2所示。

处理器305还可以操作性地耦接到存储设备134，类似于图2中的数据库120。存储设备134是适于存储和/或检索数据的任何计算机操作的硬件。在一些实施例中，数据库120被集成在服务器系统301中。例如，服务器系统301可以包括一个或多个硬盘驱动器作为存储设备134。在其他实施例中，存储设备134在服务器系统301外部，并且可以由多个服务器系统301访问。例如，存储设备134可以包括多个存储单元，例如在廉价盘冗余阵列(RAID)配置中的硬盘或固态盘。存储设备134可以包括存储区域网络(SAN)和/或网络附加存储(NAS)系统。

在一些实施例中，处理器305经由存储接口320操作性地耦接到存储设备134。存储接口320是能够向处理器305提供对存储设备134的访问的任何组件。存储接口320可以包括例如高级技术附件(ATA)适配器、串行ATA(SATA)适配器、小型计算机系统接口(SCSI)适配器、RAID控制器、SAN适配器、网络适配器和/或向处理器305提供对存储设备134的访问的任何组件。

存储区域310可以包括但不限于例如动态RAM(DRAM)或静态RAM(SRAM)的随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)和非易失性RAM(NVRAM)。上述存储器类型仅是示例性的，因此不限制可用于存储计算机程序的存储器的类型。

图4示意了借助于其将来自支付卡交易的数据转换成图形数据库格式的示例性数据流400。在该示例性实施例中，GCG计算设备170被配置为直接从例如支付处理器112(图2中示出)接收交易数据并将其转换为图形数据库形式。在另一个实施例中，支付处理器112将到来的交易数据转换成图形数据库形式，以供GCG计算设备170进一步操纵。在402处，从例如商家计算设备118接收交易数据。在404处，交易数据被处理并且经受清理操作(例如，删除重复项，删除错误数据，标记交易以供其他计算设备审阅，等等)。

在406处，以包括各种数据表的关系数据库形式存储交易数据。例如，交易详情表包括交易日期、时间、位置、金额、支付卡类型、持卡人信息等。商家表保持商家记录，包括商家标识符、名称、地址、交易量、在该商家执行的交易以及相关信息。聚合商家表保持包括商家名单的聚合商家数据，这些商家例如隶属于较大的公司、商家集团或特许经营商。聚合商家表还可以按地理位置、支付处理网络服务的使用、支付卡类型等列出商家。地理数据表保持商家、ATM和针对其收到数据的交易中涉及的其他实体的物理位置信息。本领域技术人员将会理解，上述表不是限定性的或穷举性的列表。在406处示例性关系数据库可以将数据存储在许多其他配置中并且可以存储许多其他类型的数据。另外，上述表和其他表可以通过例如主键、外键(foreign key)等的共同字段彼此连接。

在408处，GCG计算设备执行若干批量作业(batch job)，从关系数据库提取数据以转换为图形数据库形式。在一个实施例中，批量作业是在关系数据库上周期性地执行以提取和操纵数据的计算机可执行指令的任何集合。这些包括提取商家和卡数据并为每个商家或每个卡或持卡人生成图形节点的批量作业。还包括在地理节点与商家和持卡人节点之间创建边或链接的批量作业。还包括创建边以聚合商家节点的批量作业。本领域的技术人员将认识到批量作业的数量和质量将随着被转换为图形数据库形式的关系数据库数据的复杂性和量而变化。因此，可以使用多个其他批量作业(未示出)来在410处执行到图形数据库的转换。

图5图示了被转换成图形数据库形式的交易数据的示例性配置500。所显示的节点通过多个标记的边互连，这些标记的边可以是指向的或无向的。如图所示，标记为M123的商家节点504连接到多个其他节点。商家节点504还保持例如节点类型(商家)、名称(ABC超级市场)和地址(123大街(123Main St.))之类的属性。如图所示，商家节点504通过标记IS_CHILD_OF的边503连接到聚合商家节点502，表示商家节点504是可以是表示更大的公司或母公司(ABC集团)节点的聚合商家节点502的附属节点。商家节点504具有边507，其标记为IS_IN_INDUSTRY，其将商家节点504连接到行业节点508，具有名称：“杂货店(Grocery)”的属性，指示商家节点504表示一个杂货店商家，(例如，蔬菜市场)。商家节点504订阅支付处理网络服务PPNPass，并且这经由到支付处理网络服务节点514的标记为SUBSCRIBES_TO的边515指示，该边具有名称属性PPNPass。

商家节点504还具有标记为SHOPS_AT的边509，其连接到标记为C345的卡节点510，指示持卡人在商家M123处至少使用了C345一次。边509具有另一属性MERCHANT_LOCATION_ID：M678，表示商家M123的较老的商家位置标识符。卡节点510还经由标记为HAS_CARD_TYPE的边511连接到支付处理网络产品节点512，具有名称：世界网(WorldNet)的属性，表示由卡节点510表示的支付卡的卡类型。卡节点510还用标记为USES的边513连接到支付处理网络服务节点514，指示由卡节点510表示的支付卡也使用PPNPass。

商家节点504还具有标记为IS_IN_ZIP的到邮编节点506的边505，该邮编节点506又具有属性63117，指示商家M123至少位于63117邮政编码处。邮编节点506还具有标记为IS_IN_CITY的到城市节点516的边517(名称值：St.Louis(圣路易斯))。城市节点516经由标记为IS_IN_STATE的边519连接到州节点518(名称值：密苏里(Missouri))。州节点518经由标记为IS_IN_COUNTRY的边521连接到国家节点520(名称值：USA)。

商家数据会随时间推移不一致。偶尔，如果数据以不同方式到达(例如，如果商家更改了其收单银行，修改了其D/B/A名称或修改了其地址等)，则可以将新的位置标识符分配给“现有”商家。在一些实施例中，如果稍后将一个商家识别为现有商家，则支付处理器维护位置标识符之间的映射。该过程将“新商家”处的交易映射到“主商家”。分配给“新商家”的位置标识符可以被称为“老位置标识符”，并且所有交易被映射到的商家的位置标识符被称为“主位置标识符”。起初，所有新商家都被视为“主商家”，直到他们被映射到现有的“主商家”。

在图形数据库中，持卡人通过边连接到主商家，但“新商家”可稍后映射到现有主商家。在一个实施例中，名为“MERCHANT_LOCATION_ID”的属性被存储在持卡人节点和商家节点之间的边内。考虑在商家M678和卡C345之间发生交易的例子，然后商家M678被“映射”到M123。最初，创建节点M678，用属性MERCHANT_LOCATION_ID＝'M678'创建C345和M678之间的链接。

将商家M678转移到M123后，删除C345和M678之间的链接，并创建(或更新)C345和M123之间的新链接。链接的属性(包括交易详情以及“MERCHANT_LOCATION_ID”)将保持不变。通过这种方式，位置映射被跟踪，并且可以使用来自MERCHANT_LOCATION_ID属性的数据进行回滚。

在另一个实施例中，映射可以通过用类型“MERCHANT_MAPPING”的边将较老的商家位置节点连接到主商家节点来实现。在本示例中，C345和M678之间关系没有变化，但M678用“MERCHANT_MAPPING”边被链接到M123。该实施例便于商家映射(因为仅需要改变一个链接)，但是以查询复杂度为代价。

图6示出了图形数据库中的节点的示例性配置600，其具有由GCG计算设备生成的某些边。在一个实施例中，配置600表示接收的所有交易数据的总和。在另一个实施例中，配置600是整个图形数据库的子集。在又一个实施例中，配置600是实际图形数据库的全部或部分的抽象，使得特定节点的仅某些属性(例如，所选交易数据点)被用于确定它们之间的边。抽象的一个例子是图形数据库模型，其显示交易量仅超过预定阈值的节点或交易日期处于特定范围内的节点。这与图形数据库的子集不同，其中子集仅仅是整个图形数据库的一部分，包括位于该部分的所有节点、边和属性。

矩形框每个都描绘图形数据库中的节点，其中箭头描绘边。在以下描述中，由每个节点表示的实体将被描述为关系中的参与者(actor)，以避免实体本身与其在图形数据库中的对应节点之间的混淆。在一个实施例中，商家610经由标记为IS_CUSTOMER_OF的边614连接到持卡人640，表示基于它们之间的一个或多个交易的供应商-客户关系。来自这些交易的交易数据至少存储在商家610(即表示商家610的节点)中。在示例性实施例中，认为持卡人640总是在商家610处购买食品。类似地，持卡人650经由标记为IS_CUSTOMER_OF的边616连接到商家610，并且经由标记为IS_CUSTOMER_OF的边626连接到商家620。持卡人650也总是在商家610处购买食品，但是访问商家620以购买婴儿护理物品。另外，持卡人650经由标记为IS_CUSTOMER_OF的边634连接到商家630。在示例性实施例中，持卡人650从商家630购买衣物洗涤剂。

配置600还示出了聚合商家660。商家610、620和630中的每一个分别经由标记为IS_MEMBER_OF的边612,622和632而连接到聚合商家660。在示例性实施例中，IS_MEMBER_OF边表示聚合商家660是商家610、620和630的母公司。

到目前为止描述的边(612,614,616,622,626,632,634)直接根据从关系数据库接收到的数据开发，如图4所述。如之前所述，来自关系数据库的数据包括交易数据，还包括地理数据和有关商家-聚合商家关系的数据。图6中的其余边由GCG计算设备生成。这些生成的边表示在关系数据库中(例如，在关系数据库表中的两个记录之间)不明显的关系或者使用查询极难引起的关系(例如，可能需要连接大量表的关系，每个表包含数百万记录)。在该示例性实施例中，GCG计算设备被配置成分析上述数据并发现商家610和商家620之间的共同性，即，持卡人650出现在两个商家的交易数据中的事实。GCG计算设备被配置为在商家610和商家620之间生成标记为IS_CO_VENDOR的边615。在一个实施例中，边615可以具有作为属性的关于商家610和620共同的任何持卡人(例如持卡人650)的数据。

类似于边615的生成过程，GCG计算设备检测到持卡人650分别具有到商家620和630的边626和634。GCG计算设备然后创建商家620与商家630之间的标记为IS_CO-VENDOR的边625。同样，GCG计算设备检测持卡人650具有分别连接到商家610和630的边616和634，并且创建商家610和商家630之间的标记为IS_CO-VENDOR的边635。基于边614、616和634，GCG计算设备被配置成在持卡人640和商家630之间创建标记为IS_RELATED_CUSTOMER_OF的另一边638。并且基于边614、616和626，GCG计算设备在商家620和持卡人640之间创建标记为IS_RELATED_CUSTOMER_OF的边624。

例如，边615可以使GCG计算设备生成推荐。例如，由于商家610和商家620处于“共同供应商”关系，所以边615使得GCG计算设备的用户能够在搜索商家610的同时发现商家620，反之亦然。此外，用户可以授权商家610访问关于商家620的顾客(例如，持卡人650)的信息。反之亦然，即商家620可以访问关于商家610的顾客(例如，持卡人640)的信息。因此，GCG计算设备可以推荐商家610向持卡人650提供婴儿护理物品。在另一个实施例中，商家610可以向持卡人650提供关于食品的有吸引力的优惠。商家610和620可以研讨共同营销活动并且一起宣传产品给两个商家的顾客。在另一个实施例中，针对持卡人640的清洁需求，持卡人640可以能够接收访问商家630的推荐。

在又一个实施例中，边615可以将聚合的交易数据存储为其自己的属性(例如，以日/月/年聚合的历史数据数组或者计数/量的指数衰减的平均值的形式)，表现用于商家610和商家620处的交易的数据。GCG计算设备可以使用存储在边615内的交易数据来确定持卡人650，例如“共同访问”商家610和商家620。在一个实施例中，共同访问被定义为在预定时间段内(例如在同一小时内，同一天内或同一周内)访问两个(或更多个)商家的持卡人。GCG计算设备可以在商家610和商家620之间创建标记为CO_VISIT的边617。在一个实施例中，GCG计算设备过滤存储在边615中的总交易数据，以找到在同一小时内访问商家610和620的唯一持卡人。

边617提供关于持卡人650的购买习惯的更多情报。例如，GCG计算设备可以确定持卡人650共同访问商家610(食品)和商家620(婴儿护理)，因为持卡人650需要大约在一个月的同一时间补充食品和婴儿护理品。这可能是持卡人650甚至不知道商家610除了提供食品还提供婴儿护理品，或者持卡人650不认为在商家610处的婴儿护理品具备合适的质量。在这样的情况下，GCG计算设备确定共同访问关系并且可以生成使持卡人650访问商家610的推荐，包括鼓励持卡人650从商家610购买婴儿护理品和食品两者的一个或多个优惠。

在又一个实施例中，GCG计算设备可以过滤存储在IS_CO-VENDOR边中的交易数据以搜索“访问序列”数据。“访问序列”在本文中被理解为持卡人访问商家的特定顺序。在示例性实施例中，可以基于在三个商家处的特定和/或重复的交易序列发现持卡人650总是访问商家610，然后商家620，然后商家630。GCG计算设备提取这些序列并生成商家之间标记为例如IS_VISITED_BEFORE或IS_VISITED_AFTER的边(未示出)。访问序列数据导致GCG计算设备推荐例如序列中较早的商家为序列中的稍后的商家提供商品的折扣或促销。可以鼓励持卡人在序列中的较早的商家处花费特定的金额，以便在序列中稍后的商家处获得奖励或折扣。

配置600示出了图形数据库如何容易地确定例如由边638体现的关系，而不像关系数据库那样难以或不可能引出这样的关系。在示例性实施例中，GCG计算设备确定持卡人614是商家610的顾客，商家610具有持卡人650作为顾客，持卡人650又是商家630的顾客。在另一个实施例中，一个生成的边可能引起另一个。例如，一旦在商家610和商家630之间存在边635，则GCG计算设备可以基于新生成的IS_CO-VENDOR边635创建边638，而不是如在紧接其上的示例性实施例中那样遍历边614、616和634。

除了生成边之外，GCG计算设备还被配置为生成表示不作为关系数据库中的单个表或行存在的数据的节点。例如，GCG计算设备可以创建标记为“持卡人共同访问商家以购买食品和婴儿护理品(Cardholders Co-Visiting Merchants To Buy Foodstuffs and Baby care items)”的节点(未示出)。在一个实施例中，该节点将连接到例如持卡人650，如上面的示例性实施例中那样，而且连接到购买食品和婴儿护理品并且购买习惯符合共同访问定义的许多其他持卡人。GCG计算设备可以生成连接到上述节点的持卡人的聚集的列表，以供出售这两种产品的商家使用，以便生成推荐并且推动对优惠和特殊程序的流量。

在另一个实施例中，GCG计算设备确定商家610登记在由例如支付处理器提供的特定程序中。GCG计算设备被配置为对于商家610观察交易数据随时间的变化。如果交易量在商家610处上升，例如超过某个阈值，则GCG计算设备确定该特殊程序已被证明对商家610带来利润。因此，GCG计算设备向与商家610处于CO_VENDOR关系的商家(例如商家620)推荐特殊程序。此外，如果交易量在商家610处上升，则GCG计算设备被配置为向与商家610处于CO_VENDOR关系中的其他商家推荐特殊程序，从而提高客户满意度。

图7是GCG计算设备通过其在图形数据库中生成新边的示例方法700。在该示例性实施例中，GCG计算设备从关系数据库接收702交易数据，其中交易数据从由支付处理器处理的、多个商家中的至少第一商家与多个持卡人中的第一持卡人之间的交易导出。GCG计算设备限定704图形，包括至少创建表示第一商家的至少第一节点和表示第一持卡人的第二节点。GCG计算设备至少部分地基于图形中的至少两个节点共同的交易数据来识别706图形中的至少两个节点之间的至少一个关系。然后，GCG计算设备在至少两个节点之间生成708表示至少两个节点之间的新关系的至少一个边。

图8示出了计算设备内的数据库的示例配置，该计算设备可以与其他相关的计算组件一起用于生成和维护图形数据库。在一些实施例中，计算设备810与GCG计算设备170(在图2中示出)类似。在一些实施例中，数据库820类似于数据库120或图形数据库160(在图2中示出)。在示例实施例中，数据库820包括交易数据822、交易元数据824和模式数据826。交易数据822包括关于由支付处理器处理的每个交易的数据，例如日期、时间、位置、商家ID、交易金额和用于交易的支付卡。交易元数据824包括关于每个节点的数据(例如商家数据、卡数据、特殊程序/服务、地理数据等)。模式数据826包括关于在交易数据822中观察到的趋势的数据(例如，共同访问的证据，特定的访问序列以及在特定时间访问特定商家的特定持卡人群组)。

计算设备810还包括数据存储设备830。计算设备810还包括分析组件840，其被配置为分析交易数据822，并且在一个实施例中生成模式数据826。计算设备810还包括显示组件850，其被配置为显示图形数据库的全部或部分的视觉表示以供计算设备810的用户审阅。计算设备810还包括应用组件860，其被配置为基于模式数据826为持卡人和商家生成推荐，并且还在模式数据826显示来自例如特定商家的多次欺诈报告的情况下确定欺诈事件。计算设备810还包括通信组件870，通信组件870被配置为至少与商家和持卡人进行通信以发布推荐和欺诈的通知。

如基于前述说明书将意识到的，本公开的上述实施例可以使用包括计算机软件、固件、硬件或其任何组合或子集的计算机编程或工程技术来实现，其中技术效果是减少现有的计算机系统上的数据负载(例如通过减少欺诈交易)，并减少冗余查询(例如，从关系数据库表中提取感兴趣关系所需的大型连接操作)。根据本公开的所讨论的实施例，具有计算机可读代码装置的任何这样的结果程序可以在一个或多个计算机可读介质内被具体化或提供，从而制造计算机程序产品(即，制品)。计算机可读介质可以是例如但不限于固定(硬)驱动器、软盘、光盘、磁带、诸如只读存储器(ROM)的半导体存储器和/或任何发送/接收介质，如互联网或其他通信网络或链接。包含计算机代码的制品可以通过直接从一种介质执行代码，通过将代码从一种介质复制到另一种介质，或通过在网络上传输代码来制造和/或使用。

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

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