CN110751455B - 一种联名业务处理方法及装置 - Google Patents

Abstract

本申请实施例公开了一种联名业务处理方法、装置及***。其中方法包括：在接收到用户的联名业务申请请求时，获取数据库的用户信息与用户的第一业务ID；计算预存的用户信息和用户申请信息的匹配度；若匹配度不满足预设条件，则按照第一业务ID生成规则为用户生成新的第一业务ID并进行混淆处理生成联名业务第一ID；接收第二服务器发送的其对用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；根据联名业务申请请求建立联名业务第一ID与联名业务第二ID的对应关系。本申请技术方案建立了双方侧联名业务ID的对应关系，从而可以快速准确识别会员，便于权益的准确快速发放。

Description

一种联名业务处理方法及装置

技术领域

本申请涉及联名业务领域，特别是涉及一种联名业务处理方法及装置。

背景技术

随着智慧零售的崛起，越来越多行业针对特定场景而凝聚在一起开展异业联名合作。比如各零售合作方与银行签署战略合作协议，通过借助银行联名卡实体进行联合发展会员，将零售合作方会员与银行的持卡用户绑定在一起，整合零售合作方和银行合作双方的资源一起回馈用户。

以银行联名卡为例，目前都是由零售合作方预先提供一定数量的会员***到银行卡上以生成银行联名卡，并将该银行卡上的会员***作为零售合作方会员识别的唯一方式。其具体步骤参见图1：

提前预分配一定数量的会员***给银行；

银行联名卡印制时，需要按照合作方提供的会员***进行印制，不得有误；

银行、合作方一起推广办卡；

用户填写银行卡申请的必填信息，提交办卡申请；

银行接收用户申请信息后，进行审批，审批成功则邮寄卡片给用户；

用户拿卡后，必须到合作方平台，根据卡片上的***激活会员；

会员激活后，再领取权益；

对于一些特定时期举办的活动，需要对符合一定条件的会员下发特殊权益，比如对当月刷卡满5次的用户发送零售合作方的优惠券，此时需要：

银行导出符合活动的用户详细信息；

发给合作方，合作方根据用户详细信息进行匹配会员；

确认无误的会员，合作方逐条向其发放权益。

该方式下，具有多个问题：

需要提前预分配会员***，因无法预估业务量导致合作方无法给出准确数量的会员***，造成会员***要么缺少要么浪费的局面，且银行制卡环节需要多印制会员***，增加环节且容易出错；

申请周期长，时效性差，操作不便捷，在申请通过后还需要到零售合作方处现场再次填写会员信息，激活会员；

对于已经是零售合作方会员的用户，会因联名卡业务而具有多个会员***，增加会员以及零售合作方的管理难度；

每次合作活动都需要根据银行侧发过来的用户信息与自己存储的信息结合来识别会员，过程复杂且容易出错。

上述问题也同样出现在其他类似联名业务领域。

因此如何快速建立联名业务，准确识别用户每个业务对应的账号标识是当前需要解决的问题。

发明内容

本申请提供了一种联名业务处理方法及装置，以解决现有技术中出现的至少一个上述问题。

本申请提供了如下方案：

一方面提供了一种联名业务处理方法，应用于第一服务器，所述方法包括：

在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

若所述匹配度不满足预设条件，则按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系。

优选的，所述方法还包括：

若所述匹配度满足预设条件，则在所述用户信息数据库的所有第一业务ID中匹配得到与所述用户申请信息对应的目标第一业务ID；

对所述目标第一业务ID进行混淆处理生成所述联名业务第一ID。

优选的，所述方法还包括：

发送所述联名业务第一ID和所述用户的联名业务申请请求至所述第二服务器；

接收第二服务器对所述用户的联名业务申请请求审批的审批信息包括：

接收第二服务器对所述用户的联名业务申请请求审批的审批信息和对应的所述联名业务第一ID。

优选的，所述方法还包括：

建立所述新的第一业务ID与所述用户申请信息的对应关系并存储在所述用户信息数据库。

优选的，所述方法还包括：

向所述联名业务第一ID的电子账户中下发第一权益。

优选的，所述方法还包括：

接收第二服务器发送的符合预设条件的联名业务第二ID；

根据预存的联名业务第一ID与联名业务第二ID的对应关系，针对所述符合预设条件的联名业务第二ID确定对应的联名业务第一ID；

向所述对应的联名业务第一ID的电子账户中下发第二权益。

优选的，所述方法还包括：

根据待下发权益对应的联名业务第一ID和在内存数据库中预先存储的联名业务第一ID与文档标识的倒排索引关系确定满足所述待下发权益的联名业务第一ID对应的第一目标文档标识；所述文档标识与用户信息的关键词之间的索引数据及所述用户信息存储在磁盘数据库中；

以所述待下发权益为关键词，建立所述待下发权益与第一目标文档标识之间的倒排索引数据并存储在所述内存数据库中。

优选的，所述方法还包括：

接收权益覆盖用户的查询请求；所述权益查询请求中包含待查询的权益关键词；

根据所述待查询的权益关键词在所述内存数据库中进行查询确定所述待查询的权益关键词对应的第二目标文档标识；

根据内存数据库中预先存储的联名业务第一ID与文档标识的对应关系确定与所述第二目标文档标识对应的目标联名业务第一ID作为所述权益覆盖用户。

优选的，所述联名业务为银行卡与商家会员卡之间联名的业务。

本申请另一方面还提供了一种联名业务处理装置，所述装置包括：

对应关系获取单元，用于在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

匹配度计算单元，用于按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

联名业务第一ID生成单元，用于在所述匹配度不满足预设条件时，按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

联名业务第二ID生成单元，用于接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

对应关系建立单元，用于根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系

根据本申请提供的具体实施例，本申请公开了以下技术效果：

本申请的技术方案在用户发出申请联名业务请求时，分别在审批方和合作方建立了与联名业务申请信息如用户身份证号、用户手机号对应的两方的经处理后的联名业务ID并建立了两方联名业务ID的对应关系。该方式下根据一方联名业务ID即可立即识别另一方的联名业务ID，从而可以快速准确识别会员，便于权益的准确快速发放。应用在联名卡业务中，不需要在联名卡上印制会员***，也不需要用户现场激活会员。进一步的，针对已经在一方申请过ID的用户，建立与原有ID的对应关系，避免了同一人多ID号的问题。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术流程示意图；

图2是本申请***结构图；

图3是本申请实施例具体场景流程图；

图4是本申请实施例一第一种方法流程图；

图5是本申请实施例一第二种方法流程图；

图6是本申请实施例提供的计算机***架构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

本申请旨在提供一种联名业务处理方法，针对用户的联名业务申请请求确定联名业务双方对应的联名业务ID，通过联名业务申请请求中的申请信息建立双方的联名业务ID的对应关系，以基于联名业务ID对应关系对用户身份进行识别。

进一步的本申请还对用户是否为老用户，是否已经拥有一方ID进行了判断，针对新用户生成新的联名业务ID，针对老用户基于原有ID对应一个联名业务ID。

本申请以下实施例以联名业务为联名卡业务，联名卡为银行(审批方)和零售合作方之间的联名卡为例进行说明。

另外需要说明的是，本申请下述实施例中的合作方、审批方均指该方关联的服务器。

如图2所示，为本申请的***架构图，包括用户、零售合作方和银行审批方。其中用户用于提出银行联名卡请求，该请求中携带用户的申请信息，比如用户手机号、用户身份证号、用户姓名、用户住址等信息。在实际中，该申请信息的范围由银行审批方与合作方根据各自审批需求设定。

该用户的银行联名卡请求可以在零售合作方侧提起，也可以在银行审批侧提起。一般当银行与零售合作方开展联名卡活动时，可能会各自设定推广点，来向用户宣传并接收用户的申请请求。因此他们都有可能接收用户的联名卡申请请求。

若用户向零售合作方侧提起请求：

合作方联名卡申请单元接收用户请求，其会员ID单元根据该请求中的申请信息确定用户的会员ID，并经过混淆处理生成联名卡第一ID。之后将该联名卡第一ID和用户请求一并发送至银行审批方。

银行审批方的联名卡申请单元接收合作方发来的申请请求进行审批，并由银行ID单元对审批通过的用户建立银行ID，对银行ID进行加密处理生成联名卡第二ID。同时将联名卡第二ID与联名卡第一ID一并发送回合作方。

合作方建立联名卡第二ID和联名卡第一ID的对应关系，并生效联名卡标签。

之后合作方权益下发单元对该生效的联名卡的联名卡第一ID对应的电子账户下发会员权益。

若用户向银行审批方侧提起请求：

银行审批方联名卡申请单元接收用户请求，进行审批，审批通过后，其银行ID单元根据该请求中的申请信息确定用户的银行ID，对银行ID进行加密处理生成联名卡第二ID。之后将该联名卡第二ID和用户请求一并发送至零售合作方。

零售合作方的联名卡申请单元接收审批方发来的申请请求，由会员ID单元对审批通过的用户确定会员ID并经过混淆处理生成联名卡第一ID。

合作方会员ID单元建立联名卡第二ID和联名卡第一ID的对应关系，并生效联名卡标签。

之后合作方权益下发单元对该生效的联名卡的联名卡第一ID对应的电子账户下发会员权益。

当在特定时间内进行特殊活动时，比如在某一月度对前一月度刷卡满5次的用户下发会员优惠券，此时需要银行审批方在银行联名卡用户中筛选满足条件的联名卡第二ID发送至合作方，合作方识别对应的联名卡第一ID，之后合作方权益下发单元对筛选出的联名卡第一ID对应的电子账户下发特殊权益。

当然在实际中，同一用户可能先后短时间内在合作方以及审批方提出了联名卡申请请求，此时各方可以各自确定对应的ID并经过混淆或加密处理生成联名卡第二ID和联名卡第一ID，之后基于请求中的申请信息建立对应关系。比如合作方接收银行审批方发送的联名卡第二ID以及申请请求，根据请求中的申请信息匹配到合作方对此建立的联名卡第一ID，即可建立双方联名卡ID的对应关系并生效联名卡标签。

在上述实施例中，均涉及合作方的会员ID单元根据联名卡申请请求中的申请信息确定用户的会员ID，并经过混淆处理生成联名卡第一ID的过程，考虑到申请的用户可能已经是合作方的会员，为避免对同一用户生成两个会员ID，本申请中，可首先对用户是否已经是会员进行判断，具体判断可如下：

获取用户信息数据库预存的用户信息与用户的会员ID的对应关系；

计算所述预存的用户信息和所述用户申请信息的匹配度；

若所述匹配度不满足预设条件比如低于一个预设的阈值，说明目前申请联名卡的用户尚不是会员，则按照会员ID生成规则为所述用户生成新的会员ID并对所述新的会员ID进行混淆处理生成联名业务第一ID；

若所述匹配度满足预设条件比如高于预设阈值，说明目前申请联名卡的用户已经是会员，则确定在所述用户信息数据库的所有第一业务ID中匹配到的与所述用户申请信息对应的会员ID；对所述会员ID进行混淆处理生成所述联名业务第一ID。

用户信息可以分为多个维度，每个维度对匹配结果的影响程度不同。比如身份证号匹配则基本可以断定为同一人，而姓名匹配则有可能重名，但姓名与住址结合也可基本认定为同一人，基于此可以对各个维度的信息进行加权，该加权值可以通过预先的配置实现，***根据配置的加权值，计算各维度信息综合匹配后的匹配度。匹配度达标即可确定是老会员，则可直接确定其对应的会员ID，匹配度不达标则为新会员，则根据ID生成规则，在号段池增量生成一个新的会员ID。最后将会员ID通过salt混淆的方式转为联名卡第一ID。

譬如，用户联名卡申请请求中给出了包括姓名，手机，证件号的用户申请信息，与合作方数据库中预存的用户信息进行匹配，证件号信息匹配权值占比50％，姓名信息权值占比10，手机信息匹配权值占比40％，如果就姓名不对，计算最终的结果就是90％，预设的阈值为70％，此时匹配度达标，***就会认定该申请联名卡的用户为老用户。

如图3所示，提供了一种具体的银行与商家合作方一起推广办理银行联名卡业务的流程示意图：

用户填写银行卡申请的必填信息，提交办卡申请；

银行接收用户的申请信息后，进行审批，审批成功则邮寄卡片给用户，同时***回传审批结果给合作方；

合作方接收到审批结果实时建立会员绑定关系，生效银行联名卡标签；

***自动根据银行联名卡标签生效对应的权益。

特定活动时，需要：

银行将满足活动的用户银行ID和活动编码回传给合作方；

合作方根据用户银行ID快速准确识别到唯一的会员ID；

根据活动编码生效对应的活动权益。活动编码对应着具体的活动规则，比如下发何种权益等。

上述过程也同样适用于其他联名业务中，基于此，本申请提供如下实施例：

实施例一

本申请实施例一提供了一种联名业务处理方法，应用于第一服务器，所述方法包括：

在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

若所述匹配度不满足预设条件，则按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系。

优选实施例中，若所述匹配度满足预设条件，则在所述用户信息数据库的所有第一业务ID中匹配得到与所述用户申请信息对应的目标第一业务ID；

对所述目标第一业务ID进行混淆处理生成所述联名业务第一ID。

为保证用户信息数据库中信息完整，第一服务器在建立所述新的第一业务ID与所述用户申请信息的对应关系后会将对应关系存储在所述用户信息数据库便于后续的匹配。

针对接收联名业务申请请求的主体不同，根据上述分析，该方法具体包括如下两种具体方法：

第一种，应用于第一服务器，如图4所示，包括：

S41接收用户的包括用户申请信息的联名业务申请请求，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

S42按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

S43根据匹配度生成或确定第一业务ID并对所述第一业务ID进行混淆处理生成联名业务第一ID；

该步骤具体过程可参见上述实施例一描述。

S44发送所述联名业务第一ID和所述用户的联名业务申请请求至所述第二服务器；

S45接收第二服务器对所述用户的联名业务申请请求审批的审批信息和对应的所述联名业务第一ID；所述审批信息包括第二服务器对所述用户的联名业务申请请求审批通过后经加密处理生成的联名业务第二ID；

S46建立所述联名业务第一ID与所述联名业务第二ID的对应关系。

第二种，如图5所示，包括：

S51第二服务器接收用户的联名业务申请请求并根据联名业务申请信息对联名业务申请请求审批通过后确定第二业务ID，并经对第二业务ID加密处理生成联名业务第二ID；联名业务申请请求包含联名业务申请信息；

S52第二服务器将联名业务第二ID和联名业务申请请求发送至第一服务器；

S53第一服务器接收第二服务器发送的联名业务第二ID和联名业务申请请求，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

S54第一服务器按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

S55根据匹配度生成或确定第一业务ID并对所述第一业务ID进行混淆处理生成联名业务第一ID；

S56第一服务器建立联名业务第一ID与联名业务第二ID的对应关系。

实施例二

通过上述方法建立联名业务后，第一服务器即可向联名业务第一ID对应的电子账户中下发第一权益。

对于需要满足特定条件才可下发的权益，方法还包括：

接收第二服务器发送的符合预设条件的联名业务第二ID；

根据预存的联名业务第一ID与联名业务第二ID的对应关系，针对所述符合预设条件的联名业务第二ID确定对应的联名业务第一ID；

向所述对应的联名业务第一ID的电子账户中下发第二权益。

以银行和零售商家为例，联名卡为银行联名卡，审批方为银行，合作方为商家；联名卡第二ID具体可以为银行***；方法还包括：

商家接收用户对银行卡的刷卡请求并获取对应的银行***；

商家根据预存的联名卡第一ID与联名卡第二ID的对应关系，确定银行***是否有对应的联名卡第一ID；

若有，则商家确定联名卡第一ID对应的电子账户中的权益，以该权益进行后续处理如结账等。

实施例三

上述提及用户信息数据库中存储有用户信息以及与用户信息对应的会员ID。在实际应用中，还会存储与用户相关的消费等其他业务数据。其中不止有联名业务的会员，也有一般的会员信息。

而在对联名用户进行相关权益下发时，基于每次权益下发的条件不同，会对应不同的用户，随着业务的增多，这种权益下发信息更新较快。每次进行权益下发时都需要在信息数据库中重建商品全量索引来生效权益规则，时效性比较差，查询耗用时间长。

为此本申请实施例三提供了一种方法，将用户信息全量存储在磁盘数据库中，在这之外，建立一个内存索引专门用来生效权益规则和权益规则的查询。

具体的生效步骤包括：

根据待下发权益对应的联名业务第一ID和在内存数据库中预先存储的联名业务第一ID与文档标识的倒排索引关系确定满足所述待下发权益的联名业务第一ID对应的第一目标文档标识；所述文档标识与用户信息的关键词之间的索引数据及所述用户信息存储在磁盘数据库中；

以所述待下发权益为关键词，建立所述待下发权益与第一目标文档标识之间的倒排索引数据并存储在所述内存数据库中。

查询步骤包括：

接收权益覆盖用户的查询请求；所述权益查询请求中包含待查询的权益关键词；

根据所述待查询的权益关键词在所述内存数据库中进行查询确定所述待查询的权益关键词对应的第二目标文档标识；

根据内存数据库中预先存储的联名业务第一ID与文档标识的对应关系确定与所述第二目标文档标识对应的目标联名业务第一ID作为所述权益覆盖用户。

通过这一方法可以在内存数据库中快速生效权益规则和查询权益规则，当需要获得用户的其他详细信息可进一步根据文档标识等在磁盘数据库进行查询。

实施例四：

对应上述，本申请实施例四还提供一种联名业务处理装置，装置包括：

对应关系获取单元，用于在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

匹配度计算单元，用于按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

联名业务第一ID生成单元，用于在所述匹配度不满足预设条件时，按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

联名业务第二ID生成单元，用于接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

对应关系建立单元，用于根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系。

优选实施例中，联名业务第一ID确定单元还用于在所述匹配度满足预设条件时，在所述用户信息数据库的所有第一业务ID中匹配得到与所述用户申请信息对应的目标第一业务ID并对所述目标第一业务ID进行混淆处理生成所述联名业务第一ID。

另一优选实施例中，所述装置还包括信息存储单元，用于建立所述新的第一业务ID与所述用户申请信息的对应关系并存储在所述用户信息数据库。

优选实施例中，所述装置还包括权益下发单元，用于向所述联名业务第一ID的电子账户中下发第一权益。

所述权益下发单元，具体的用于：

接收第二服务器发送的符合预设条件的联名业务第二ID；根据预存的联名业务第一ID与联名业务第二ID的对应关系，针对所述符合预设条件的联名业务第二ID确定对应的联名业务第一ID；向所述对应的联名业务第一ID的电子账户中下发第二权益。

优选实施例中，所述装置还包括索引建立单元，用于根据待下发权益对应的联名业务第一ID和在内存数据库中预先存储的联名业务第一ID与文档标识的倒排索引关系确定满足所述待下发权益的联名业务第一ID对应的第一目标文档标识并以所述待下发权益为关键词，建立所述待下发权益与第一目标文档标识之间的倒排索引数据并存储在所述内存数据库中。其中，所述文档标识与用户信息的关键词之间的索引数据及所述用户信息存储在磁盘数据库中；

另一优选实施例中，所述装置还包括查询单元，用于接收权益覆盖用户的查询请求；所述权益查询请求中包含待查询的权益关键词；根据所述待查询的权益关键词在所述内存数据库中进行查询确定所述待查询的权益关键词对应的第二目标文档标识并根据内存数据库中预先存储的联名业务第一ID与文档标识的对应关系确定与所述第二目标文档标识对应的目标联名业务第一ID作为所述权益覆盖用户。

实施例五

对应上述实施例，本申请还提供了一种计算机***，包括一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

若所述匹配度不满足预设条件，则按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系。。

其中，图6示例性的展示出了计算机***的架构，具体可以包括处理器1510，视频显示适配器1511，磁盘驱动器1512，输入/输出接口1513，网络接口1514，以及存储器1520。上述处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，与存储器1520之间可以通过通信总线1530进行通信连接。

其中，处理器1510可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1520可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1520可以存储用于控制计算机***1500运行的操作***1521，用于控制计算机***1500的低级别操作的基本输入输出***(BIOS)。另外，还可以存储网页浏览器1523，数据存储管理***1524，以及图标字体处理***1525等等。上述图标字体处理***1525就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1520中，并由处理器1510来调用执行。

输入/输出接口1513用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1514用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1530包括一通路，在设备的各个组件(例如处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，与存储器1520)之间传输信息。

另外，该计算机***1500还可以从虚拟资源对象领取条件信息数据库1541中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，存储器1520，总线1530等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，云服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***或***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***及***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的数据处理方法、装置及设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种联名业务处理方法，其特征在于，应用于第一服务器，所述方法包括：

在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

若所述匹配度不满足预设条件，则按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

若所述匹配度满足预设条件，则根据所述用户申请信息对应的会员ID，并对所述会员ID进行混淆处理生成所述联名业务第一ID，所述混淆处理为salt混淆；

接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系。

2.如权利要求1中所述的联名业务处理方法，其特征在于，所述方法还包括：

若所述匹配度满足预设条件，则在所述用户信息数据库的所有第一业务ID中匹配得到与所述用户申请信息对应的目标第一业务ID；

对所述目标第一业务ID进行混淆处理生成所述联名业务第一ID。

3.如权利要求1中所述的联名业务处理方法，其特征在于，所述方法还包括：

发送所述联名业务第一ID和所述用户的联名业务申请请求至所述第二服务器；

接收第二服务器对所述用户的联名业务申请请求审批的审批信息包括：

接收第二服务器对所述用户的联名业务申请请求审批的审批信息和对应的所述联名业务第一ID。

4.如权利要求1至3中任一项所述的联名业务处理方法，其特征在于，所述方法还包括：

建立所述新的第一业务ID与所述用户申请信息的对应关系并存储在所述用户信息数据库。

5.如权利要求1所述的联名业务处理方法，其特征在于，所述方法还包括：

向所述联名业务第一ID的电子账户中下发第一权益。

6.如权利要求1中所述的联名业务处理方法，其特征在于，所述方法还包括：

接收第二服务器发送的符合预设条件的联名业务第二ID；

根据预存的联名业务第一ID与联名业务第二ID的对应关系，针对所述符合预设条件的联名业务第二ID确定对应的联名业务第一ID；

向所述对应的联名业务第一ID的电子账户中下发第二权益。

7.如权利要求5或6中所述的联名业务处理方法，其特征在于，所述方法还包括：

根据待下发权益对应的联名业务第一ID和在内存数据库中预先存储的联名业务第一ID与文档标识的倒排索引关系确定满足所述待下发权益的联名业务第一ID对应的第一目标文档标识；所述文档标识与用户信息的关键词之间的索引数据及所述用户信息存储在磁盘数据库中；

以所述待下发权益为关键词，建立所述待下发权益与第一目标文档标识之间的倒排索引数据并存储在所述内存数据库中。

8.如权利要求7中所述的联名业务处理方法，其特征在于，所述方法还包括：

接收权益覆盖用户的查询请求；所述权益查询请求中包含待查询的权益关键词；

根据所述待查询的权益关键词在所述内存数据库中进行查询确定所述待查询的权益关键词对应的第二目标文档标识；

根据内存数据库中预先存储的联名业务第一ID与文档标识的对应关系确定与所述第二目标文档标识对应的目标联名业务第一ID作为所述权益覆盖用户。

9.如权利要求5或6中所述的联名业务处理方法，其特征在于，所述联名业务为银行卡与商家会员卡之间联名的业务。

10.一种联名业务处理装置，其特征在于，所述装置包括：

对应关系获取单元，用于在接收到用户的包括用户申请信息的联名业务申请请求时，获取用户信息数据库预存的用户信息与用户的第一业务ID的对应关系；

匹配度计算单元，用于按照信息维度对应的权重，计算所述预存的用户信息和所述用户申请信息的匹配度；

联名业务第一ID生成单元，用于在所述匹配度不满足预设条件时，按照第一业务ID生成规则为所述用户生成新的第一业务ID并对所述新的第一业务ID进行混淆处理生成联名业务第一ID；

在所述匹配度满足预设条件，则根据所述用户申请信息对应的会员ID，并对所述会员ID进行混淆处理生成所述联名业务第一ID，所述混淆处理为salt混淆；

联名业务第二ID生成单元，用于接收第二服务器发送的其对所述用户的联名业务申请请求审批通过后确定的第二业务ID，并经加密处理生成联名业务第二ID；

对应关系建立单元，用于根据所述联名业务申请请求分别与所述联名业务第一ID和所述联名业务第二ID的对应关系建立所述联名业务第一ID与所述联名业务第二ID的对应关系。

Images