CN110414974B - 一种虚拟支付卡的生成控制方法及后台服务平台 - Google Patents

Abstract

本发明公开了一种虚拟支付卡的生成控制方法及后台服务平台，该方法包括后台服务平台接收某一客户端发送的申请请求，该申请请求包括某一客户端识别到的实体IC卡的卡信息；后台服务平台根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供用户选择，并接收某一客户端发送的第一目标虚拟支付卡类型标识；后台服务平台生成与第一目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。可见，本发明实施例能够根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡，有利于提高用户使用虚拟支付卡的体验感，及有利于虚拟支付卡的推广。

Description

一种虚拟支付卡的生成控制方法及后台服务平台

技术领域

本发明涉及互联网技术领域，尤其涉及一种虚拟支付卡的生成控制方法及后台服务平台。

背景技术

近年来，为了响应国家提倡的保护生态环境、绿色出行的号召，越来越多的用户选择乘坐公共交通工具(例如：地铁、公交等)出行。为了便于快速地乘坐公共交通工具，人们往往会直接购买IC卡(例如：交通卡)，这样既无需准备零钱，也无需排队购票，给人们的出行带来了很大的便利。

实践发现，很多人基本人手一张IC卡，并且不同身份的用户会对应不同的IC卡，例如：学生使用的IC卡为学生IC卡，每张IC卡都有对应的信息(例如：IC卡的交易信息等)。并且随着公共交通的便利性以及IC卡的使用便利性，会有越来越多的用户选择办理IC卡来乘坐公共交通出行，这样IC卡的使用形成了一定的信息资源。因此，如何有效地利用IC卡的信息资源成为当下急需解决的问题。

发明内容

本发明实施例所要解决的技术问题在于，提供一种虚拟支付卡的生成控制方法及后台服务平台，能够在接收到用户对应的客户端发送的虚拟支付卡的申请请求之后，根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡。

为了解决上述技术问题，本发明实施例第一方面公开了一种虚拟支付卡的生成控制方法，所述方法应用于后台服务平台中，所述方法包括：

所述后台服务平台接收某一客户端发送的申请请求，所述申请请求用于申请虚拟支付卡，且所述申请请求包括所述某一客户端识别到的实体IC卡的卡信息；

所述后台服务平台根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述后台服务平台接收所述某一客户端发送的目标虚拟支付卡类型标识，所述目标虚拟支付卡类型标识为所述某一客户端的用户从所述至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识；

所述后台服务平台根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。

作为一种可选的实施方式，在本发明实施例第一方面中，所述后台服务平台接收某一客户端发送的申请请求之后，以及所述后台服务平台根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，所述方法还包括：

所述后台服务平台基于所述申请请求包括的所述实体IC卡的卡信息确定所述实体IC卡的卡类型，并判断所述实体IC卡的卡类型是否为租赁类型；

当判断出所述实体IC卡的卡类型不为所述租赁类型时，所述后台服务平台触发执行所述的根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择的操作；

当判断出所述实体IC卡的卡类型为所述租赁类型时，所述后台服务平台判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件；

当判断出所述实体IC卡的当前条件满足所述预先确定出的虚拟支付卡生成条件时，所述后台服务平台触发执行所述的根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择的操作。

作为一种可选的实施方式，在本发明实施例第一方面中，所述后台服务平台判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件，包括：

所述后台服务平台判断所述实体IC卡的交易总次数是否大于等于预设交易总次数；

当判断出所述实体IC卡的总交易次数大于等于所述预设交易总次数时，所述后台服务平台查询所述实体IC卡的剩余金额，并判断所述剩余金额是否大于等于预设金额；

当判断出所述剩余金额大于等于所述预设金额时，所述后台服务平台确定所述实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件。

作为一种可选的实施方式，在本发明实施例第一方面中，所述后台服务平台根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡之后，所述方法还包括：

所述后台服务平台确定需要从所述实体IC卡的所有信息中转移至所述第一目标虚拟支付卡的目标信息；

所述后台服务平台将所述目标信息转移至所述第一目标虚拟支付卡，并向所述某一客户端发送所述第一目标虚拟支付卡以及所述第一目标虚拟支付卡的相关信息，所述第一目标虚拟支付卡的相关信息至少包括所述目标信息。

作为一种可选的实施方式，在本发明实施例第一方面中，所述后台服务平台接收某一客户端发送的申请请求之后，以及所述后台服务平台根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，所述方法还包括：

所述后台服务平台根据所述申请请求包括的所述实体IC卡的卡信息判断所述实体IC卡是否存在对应的第二目标虚拟支付卡；

当判断出所述实体IC卡未存在对应的所述第二目标虚拟支付卡时，所述后台服务平台执行所述的根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择的操作；

当判断出所述实体IC卡已存在对应的所述第二目标虚拟支付卡时，所述后台服务平台确定需要从所述实体IC卡转移至所述第二目标虚拟支付卡的目标金额，并将所述目标金额转移至所述第二目标虚拟支付卡中。

本发明实施例第二方面公开了一种后台服务平台，所述后台服务平台包括接收模块、发送模块以及生成模块，其中：

所述接收模块，用于接收某一客户端发送的申请请求，所述申请请求用于申请虚拟支付卡，且所述申请请求包括所述某一客户端识别到的实体IC卡的卡信息；

所述发送模块，用于根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述接收模块，还用于接收所述某一客户端发送的目标虚拟支付卡类型标识，所述目标虚拟支付卡类型标识为所述某一客户端的用户从所述至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识；

所述生成模块，用于根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。

作为一种可选的实施方式，在本发明实施例第二方面中，所述后台服务平台还包括第一确定模块以及第一判断模块，其中：

所述第一确定模块，用于在所述接收模块接收某一客户端发送的申请请求之后，以及在所述发送模块根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，基于所述申请请求包括的所述实体IC卡的卡信息确定所述实体IC卡的卡类型；

所述第一判断模块，用于判断所述实体IC卡的卡类型是否为租赁类型；

所述发送模块，还用于当所述第一判断模块判断出所述实体IC卡的卡类型不为所述租赁类型时，根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述第一判断模块，还用于当判断出所述实体IC卡的卡类型为所述租赁类型时，判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件；

所述发送模块，还用于当所述第一判断模块判断出所述实体IC卡的卡类型为所述租赁类型以及当所述第一判断模块判断出所述实体IC卡的当前条件满足所述预先确定出的虚拟支付卡生成条件时，根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择。

作为一种可选的实施方式，在本发明实施例第二方面中，所述第一判断模块判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件的方式具体为：

判断所述实体IC卡的交易总次数是否大于等于预设交易总次数；

当判断出所述实体IC卡的总交易次数大于等于所述预设交易总次数时，查询所述实体IC卡的剩余金额，并判断所述剩余金额是否大于等于预设金额；

当判断出所述剩余金额大于等于所述预设金额时，确定所述实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件。

作为一种可选的实施方式，在本发明实施例第二方面中，所述后台服务平台还包括第二确定模块以及第一转移模块，其中：

所述第二确定模块，用于在所述生成模块根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡之后，确定需要从所述实体IC卡的所有信息中转移至所述第一目标虚拟支付卡的目标信息；

所述第一转移模块，用于将所述目标信息转移至所述第一目标虚拟支付卡；

所述发送模块，还用于向所述某一客户端发送所述第一目标虚拟支付卡以及所述第一目标虚拟支付卡的相关信息，所述第一目标虚拟支付卡的相关信息至少包括所述目标信息。

作为一种可选的实施方式，在本发明实施例第二方面中，所述后台服务平台还包括第二判断模块、第三确定模块以及第二转移模块，其中：

所述第二判断模块，用于在所述接收模块接收某一客户端发送的申请请求之后，以及在所述发送模块根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，根据所述申请请求包括的所述实体IC卡的卡信息判断所述实体IC卡是否存在对应的第二目标虚拟支付卡；

所述发送模块，还用于当所述第二判断模块判断出所述实体IC卡未存在对应的所述第二目标虚拟支付卡时，根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述第二确定模块，用于当所述第二判断模块判断出所述实体IC卡已存在对应的所述第二目标虚拟支付卡时，确定需要从所述实体IC卡转移至所述第二目标虚拟支付卡的目标金额；

所述第二转移模块，用于将所述目标金额转移至所述第二目标虚拟支付卡中。

本发明实施例第三方面公开了另一种后台服务平台，所述后台服务平台包括：

存储有可执行程序代码的存储器；

与所述存储器耦合的处理器；

所述处理器调用所述存储器中存储的所述可执行程序代码，执行本发明实施例第一方面公开的虚拟支付卡的生成控制方法的操作。

本发明实施例第四方面公开了一种计算机存储介质，所述计算机存储介质存储有计算机指令，所述计算机指令被调用时，用于执行本发明实施例第一方面公开的虚拟支付卡的生成控制方法的操作。

本发明实施例第五方面公开了一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行本发明实施例第一方面公开的一种虚拟支付卡的生成控制方法的操作。

与现有技术相比，本发明具有以下有益效果：

本发明实施例中，公开了一种虚拟支付卡的生成控制方法及后台服务平台，该方法应用于后台服务平台中，该方法包括后台服务平台接收某一客户端发送的申请请求，该申请请求用于申请虚拟支付卡，且该申请请求包括某一客户端识别到的实体IC卡的卡信息；后台服务平台根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择；后台服务平台接收某一客户端发送的第一目标虚拟支付卡类型标识，该第一目标虚拟支付卡类型标识为某一客户端的用户从至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识；后台服务平台根据第一目标虚拟支付卡类型标识生成与第一目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。可见，本发明实施例能够在接收到用户对应的客户端发送的虚拟支付卡的申请请求之后，根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡，有利于提高用户使用虚拟支付卡的体验感，以及有利于虚拟支付卡的推广。

附图说明

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

图1是本发明实施例公开的一种虚拟支付卡的生成控制方法的流程示意图；

图2是本发明实施例公开的另一种虚拟支付卡的生成控制方法的流程示意图；

图3是本发明实施例公开的一种后台服务平台的结构示意图；

图4是本发明实施例公开的另一种后台服务平台的结构示意图；

图5是本发明实施例公开的又一种后台服务平台的结构示意图。

具体实施方式

为了更好地理解和实施，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。此外，本发明的说明书和权利要求书中的术语“第一”、“第二”等仅是用于区别不同对象，对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

本发明实施例公开了一种虚拟支付卡的生成控制方法及后台服务平台，能够在接收到用户对应的客户端发送的虚拟支付卡的申请请求之后，根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡，有利于提高用户使用虚拟支付卡的体验感，以及有利于虚拟支付卡的推广。以下分别进行详细说明。

实施例一

请参阅图1，图1是本发明实施例公开的一种虚拟支付卡的生成控制方法的流程示意图。其中，图1所描述的方法可以应用在管理公共交通的后台服务平台中。如图1所示，该虚拟支付卡的生成控制方法可以包括以下步骤：

101、后台服务平台接收某一客户端发送的申请请求，且该申请请求包括某一客户端识别到的实体IC卡的卡信息。

本发明实施例中，该申请请求可以是某一用户通过智能手机(Android手机、iOS手机等)、智能电话手表、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)等用户终端中安装的某一出行类应用(例如：广州地铁APP)触发的，且该出行类应用可以设置有多个授权接口，某一用户能够在使用其它应用时通过相应的授权接口快速的启动该出行类应用，该多个授权接口包括但不限于小程序平台接口、微博平台接口、网络视频平台接口、网络电台平台接口及音乐平台接口中的一种或多种，本发明实施例不做限定。这样通过设置多种授权接口的方式能够提高该出行类应用的受众范围，进而能够提高用户的使用粘度以及有利于虚拟支付卡的推广、宣传。或者，该申请请求也可以是某一用户通过固定设置或移动设置的智能设备(例如：智能售票机等)触发的，该智能设备上可以设置有用于供某一用户触发该申请请求的智能物理按键、智能交互面板、智能语音采集装置、智能手势识别装置以及智能形体识别装置中的至少一种，本发明实施例不做限定。进一步的，该用户终端、智能设备都具有NFC功能。

本发明实施例中，该实体IC卡可以为任意用于乘坐或使用交通工具的实体IC卡，例如：交通卡。其中，交通工具可以包括地铁、公交、共享自行车(例如：哈罗自行车)、轻轨、汽车中的至少一种，本发明实施例不做限定。

本发明实施例中，该实体IC卡的卡信息至少包括该实体IC卡的标识信息(例如：学生标识等)。进一步的，该实体IC卡的卡信息还可以包括该实体IC卡的编号信息、该实体IC卡的卡号信息、该实体IC卡的持有者的基本信息、该实体IC卡的发卡日期、该实体IC卡的余额中的至少一种，本发明实施例不做限定。这样实体IC卡包含的内容越多，越有利于确定准确的、与实体IC卡相匹配的虚拟支付卡类型标识。

本发明实施例中，某一客户端检测到某一用户触发的用于请求虚拟支付卡的申请请求时，开启其感应装置感应用户的实体IC卡，并识别该实体IC卡的卡信息，再将具有实体IC卡的卡信息的申请请求向后台服务平台发送；后台服务平台接收某一客户端发送的申请请求。

作为一个可选的实施例，在执行完毕步骤101之后，以及在执行步骤102之前，该虚拟支付卡的生成控制方法还可以包括以下步骤：

后台服务平台根据上述申请请求包括的实体IC卡的卡信息判断实体IC卡是否存在对应的第二目标虚拟支付卡；

当判断出实体IC卡未存在对应的第二目标虚拟支付卡时，后台服务平台触发执行步骤102；

当判断出实体IC卡已存在对应的第二目标虚拟支付卡时，后台服务平台确定需要从实体IC卡转移至第二目标虚拟支付卡的目标金额，并将目标金额转移至第二目标虚拟支付卡中。

可见，该可选的实施例在接收到客户端发送的申请请求之后，进一步根据申请请求包括的实体IC卡的卡信息判断实体IC卡是否已经存在对应的虚拟支付卡，当判断的结果为否时，继续执行后续的向客户端发送至少一种虚拟支付卡类型标识供客户端的用户选择的操作；当判断的结果为是时，确定需要从实体IC卡转移至虚拟支付卡的金额，能够降低用户因忘记申请过虚拟支付卡而导致再次申请的可能性，以及提高实体IC卡的金额转移效率。

102、后台服务平台根据上述申请请求向上述某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择。

本发明实施例中，该至少一种虚拟支付卡类型标识可以预先存储于标识数据库中。这样便于在使用到虚拟支付卡类型卡标识时，直接调用该标识数据库。进一步的，该至少一个虚拟支付卡类型标识至少包括与实体IC卡的卡信息相匹配的虚拟支付卡类型卡标识的第一类卡类型标识。进一步的，该至少一个虚拟支付卡类型标识还可以包括第二类卡类型标识，其中，该第二类卡类型标识当下主打/热门的虚拟支付卡类型卡标识、后台服务平台结合实体IC卡的卡信息以及当下流行元素推荐的后台服务平台推荐的虚拟支付卡类型卡标识中的至少一种，本发明实施例不做限定。这样有利于虚拟支付卡的宣传与推广。

作为另一个可选的实施例，在执行完毕步骤101之后，以及执行步骤102之前，该虚拟支付卡的生成控制方法还可以包括以下步骤：

后台服务平台根据申请请求包括的实体IC卡的卡信息从筛选出该实体IC卡的标识信息；

后台服务平台从预先确定出的所有虚拟支付卡类型标识中确定与实体IC卡的标识信息对应的至少一种虚拟支付卡类型标识，并触发执行步骤102。

可见，该可选的实施例在接收到客户端发送的申请请求之后，进一步从申请请求包含的实体IC卡的卡信息中筛选出实体IC卡的标识信息，并基于实体IC卡的标识信息确定与实体IC卡的标识信息相匹配的至少一种虚拟支付卡类型标识，能够提高虚拟支付卡类型标识的确定效率，从而有利于提高虚拟支付卡的生成效率。

作为又一个可选的实施例，当上述至少一种虚拟支付卡类型标识包括上述第二类卡类型标识时，在执行步骤102过程中，该虚拟支付卡的生成控制方法还可以包括以下步骤：

后台服务平台向某一客户端发送优惠提示，以使某一客户端输出优惠提示，该优惠提示用于提示某一客户端的用户选择第二类卡类型标识中的任意一个卡类型标识会有相应的优惠，且该优惠提示包括奖励金额、免虚拟支付卡的生成费用、优惠交易次数(例如：前5次交易免费或者打5折等)中的至少一种，该可选的实施例不做限定。这样优惠提示包含的优惠内容越多，越有利于虚拟支付卡的推广，从而越有利于提高虚拟支付卡的使用粘度。

可见，该可选的实施通过向用户发送优惠提示，有利于虚拟支付卡的推广以及提高虚拟支付卡变现的概率。

103、后台服务平台接收上述某一客户端发送的目标虚拟支付卡类型标识，该目标虚拟支付卡类型标识为某一客户端的用户从上述至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识。

作为又一个可选的实施例，在执行完毕步骤103之后，以及在执行步骤104之前，该虚拟支付卡的生成控制方法还可以包括以下步骤：

后台服务平台确定目标虚拟支付卡类型标识的数量；

当目标虚拟支付卡类型标识的数量大于1时，后台服务平台确定某一客户端的用户的身份信息；

后台服务平台从所有目标虚拟支付卡类型标识中选择与身份信息以及实体IC卡的卡信息相匹配的目标虚拟支付卡类型标识，并触发执行步骤104。

可见，该可选的实施例在接收到客户端反馈的虚拟支付卡类型标识之后，先确定虚拟支付卡类型标识的数量，当数量大于1时，确定客户端的用户的身份信息，并从所有虚拟支付卡类型标识中筛选出与身份信息以及实体IC卡的卡信息相匹配的一个虚拟支付卡类型标识，能够提高虚拟支付卡类型标识的确定精确度，从而有利于生成满足用户需求的虚拟支付卡，提升用户的体验感，进而进一步有利于虚拟支付卡的推广。

104、后台服务平台根据上述目标虚拟支付卡类型标识生成与该目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。

作为又一个可选的实施例，在执行完毕步骤104之后，该虚拟支付卡的生成控制方法还可以包括以下步骤：

后台服务平台确定需要从实体IC卡的所有信息中转移至第一目标虚拟支付卡的目标信息；

后台服务平台将目标信息转移至第一目标虚拟支付卡，并向某一客户端发送第一目标虚拟支付卡以及第一目标虚拟支付卡的相关信息，第一目标虚拟支付卡的相关信息至少包括上述目标信息。

该可选的实施例中，该目标信息可以包括实体IC卡的交易总次数、实体IC卡的优惠总次数、实体IC卡的持有者的基本信息中的至少一种，该可选的实施例不做限定。

该可选的实施例中，后台服务平台还可以接收某一客户端发送的余额转移请求，该余额转移请求包括需要从实体IC卡中转出的余额；并根据该余额对第一目标虚拟支付卡执行充值操作。这样能够便于后续直接使用虚拟支付卡进行交易。

可见，该可选的实施例在生成虚拟支付卡之后，还将实体IC卡中的相关信息转移至虚拟支付卡中，而无需手动将实体IC卡的信息添加至虚拟支付卡，能够提高实体IC卡的卡信息的转移效率以及便于后台服务平台对虚拟支付卡的管理。

可见，实施图1所描述的一种虚拟支付卡的生成控制方法能够在接收到用户对应的客户端发送的虚拟支付卡的申请请求之后，根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡，有利于提高用户使用虚拟支付卡的体验感，以及有利于虚拟支付卡的推广。此外，还能够降低用户因忘记申请过虚拟支付卡而导致再次申请的可能性，以及提高实体IC卡的信息转移效率；还能够提高虚拟支付卡类型标识的确定效率，从而有利于提高虚拟支付卡的生成效率；还有利于虚拟支付卡的推广以及提高虚拟支付卡变现的概率；还能够提高虚拟支付卡类型标识的确定精确度，从而有利于生成满足用户需求的虚拟支付卡；还能够便于后台服务平台对虚拟支付卡的管理。

实施例二

请参阅图2，图2是本发明实施例公开的另一种虚拟支付卡的生成控制方法的流程示意图。其中，图2所描述的方法可以应用在管理公共交通的后台服务平台中。如图2所示，该虚拟支付卡的生成控制方法可以包括以下步骤：

201、后台服务平台接收某一客户端发送的申请请求，且该申请请求包括某一客户端识别到的实体IC卡的卡信息。

202、后台服务平台基于上述申请请求包括的实体IC卡的卡信息确定该实体IC卡的卡类型，并判断该实体IC卡的卡类型是否为租赁类型。当步骤202判断出实体IC卡的卡类型为租赁类型时，可以触发执行步骤203；当步骤202判断出实体IC卡的卡类型不为租赁类型时，可以触发执行步骤204。

本发明实施例中，该租赁类型的实体IC卡为使用完之后需要归还的实体IC卡。

203、后台服务平台判断上述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件。

可见，本发明实施例在接收到客户端发送的申请请求之后，进一步根据申请请求包括的实体IC卡的卡信息判断实体IC卡的卡类型是否为租赁类型，当判断的结果为否时，继续执行后续的向客户端发送至少一种虚拟支付卡类型标识供客户端的用户选择的操作；当判断的结果为是时，在实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件之后，继续执行后续的向客户端发送至少一种虚拟支付卡类型标识供客户端的用户选择的操作，既能够智能化判断实体IC卡的卡类型，丰富后台服务平台的智能化功能，又能够使得卡类型为租赁类型的实体IC卡也能够生成对应的虚拟支付卡，尤其对于来某地出行(旅行)的用户，当用户需要离开出行地(旅行地)时，可以将实体IC卡的余额转移至虚拟支付卡，以便下次直接通过虚拟支付卡进行交易，降低因实体IC卡过期(租赁类型的实体IC卡为短期实体IC卡)或者长时间携带而导致实体IC卡丢失造成用户的经济损失，进一步提升用户的体验感。

作为一个可选的实施例，后台服务平台判断实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件，可以包括：

后台服务平台判断实体IC卡的交易总次数是否大于等于预设交易总次数；

当判断出实体IC卡的总交易次数大于等于预设交易总次数时，后台服务平台查询实体IC卡的剩余金额，并判断剩余金额是否大于等于预设金额；

当判断出剩余金额大于等于预设金额时，后台服务平台确定实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件。

可见，该可选的实施例在判断出租赁类型的实体IC卡在预设时段内的交易总次数大于等于预设交易总次数以及剩余金额大于等于预设金额满足时，确定租赁类型的实体IC卡满足预先确定出的虚拟支付卡生成条件能够丰富后台服务平台的智能化功能。

作为另一个可选的实施例，该虚拟支付卡的生成控制方法还可以包括以下步骤：

当判断出实体IC卡的卡类型为租赁类型时，后台服务平台定位某一客户端的第一地理位置，并根据某一客户端的第一地理位置确定出与该第一地理位置相匹配的实体IC卡归还服务点以及该实体IC卡归还服务点的第二地理位置，以及向某一客户端发送实体IC卡的归还提示，以使某一客户端输出归还提示，该归还提示用于提示某一客户端的用户在使用完毕实体IC卡后归还实体IC卡，且该归还提示至少包括实体IC卡归还服务点的第二地理位置。进一步的，后台服务平台还可以根据某一客户端的第一地理位置以及实体IC卡服务点的第二地理位置确定第一地理位置到第二地理位置的交通方式，此时，上述归还提示还包括与实体IC卡归还服务点对应的交通方式。

该可选的实施例中，与某一客户端的第一地理位置相匹配的实体IC卡归还服务点的数量可以为一个，也可以为多个。当该实体IC卡归还服务点为多个时，则第二地理位置由多个子地理位置组成，交通方式包括多个子交通方式，即每个实体IC卡服务点都有对应的交通方式。

该可选的实施例中，该交通方式包括小车交通方式(例如：的士交通方式等)、公共交通方式(例如：地铁交通方式等)、步行方式以及自行车交通方式中的至少一种，该可选的实施例不做限定。这样为用户提供多种到达实体IC卡归还服务点的交通方式，能够方便用户根据实际情况选择到合意的交通方式，提升用户的体验感。

该可选的实施例中，又进一步的，后台服务平台还可以获取每种交通方式的交通情况，并根据交通方式对应的交通情况为某一客户端的用户从所有交通方式中筛选出最优交通方式。这样为用户从所有交通方式中筛选出最优交通方式，有利于帮助用户以最快的交通方式到达实体IC卡归还服务点，进而归还实体IC卡。

可见，该可选的实施例在判断出实体IC卡的卡类型为租赁类型时，向用户输出包含实体IC卡归还服务点的地理位置的归还提示，而无需用户再自行搜索实体IC卡归还服务点的地理位置，能够使用户快速知晓实体IC卡归还服务点，有利于用户尽快归还实体IC卡。进一步的，归还提示还包括到达实体IC卡归还服务点的交通方式，能够方便用户根据实际情况选择到合意的交通方式，进一步提升用户的体验感。

204、后台服务平台根据上述申请请求向上述某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择。

205、后台服务平台接收上述某一客户端发送的目标虚拟支付卡类型标识，该目标虚拟支付卡类型标识为某一客户端的用户从上述至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识。

206、后台服务平台根据上述目标虚拟支付卡类型标识生成与该目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。

本发明实施例中，步骤201、步骤204-步骤206的相关描述请参照实施例一中针对步骤101-步骤104的详细描述，在本发明实施例中不再赘述。

可见，实施图2所描述的另一种虚拟支付卡的生成控制方法能够在接收到用户对应的客户端发送的虚拟支付卡的申请请求之后，根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡，有利于提高用户使用虚拟支付卡的体验感，以及有利于虚拟支付卡的推广。此外，还能够智能化判断实体IC卡的卡类型，丰富后台服务平台的智能化功能；还能够降低用户的经济损失；还能够使用户快速知晓实体IC卡归还服务点，有利于用户尽快归还实体IC卡；还能够方便用户根据实际情况选择到合意的交通方式，进一步提升用户的体验感。

实施例三

请参阅图3，图3是本发明实施例公开的一种后台服务平台的结构示意图。如图3所示，该后台服务平台可以应用于后台服务平台，且该后台服务平台可以包括接收模块301、发送模块302以及生成模块303，其中：

接收模块301，用于接收某一客户端发送的申请请求，该申请请求用于申请虚拟支付卡，且该申请请求包括某一客户端识别到的实体IC卡的卡信息。

发送模块302，用于根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择。

接收模块301，还用于接收某一客户端发送的目标虚拟支付卡类型标识，该目标虚拟支付卡类型标识为某一客户端的用户从至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识。

生成模块303，用于根据目标虚拟支付卡类型标识生成与该目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡。

可见，实施图3所描述的一种后台服务平台能够在接收到用户对应的客户端发送的虚拟支付卡的申请请求之后，根据申请请求包括的客户端识别到的实体IC卡的卡信息为用户提供至少一种虚拟支付卡的类型标识供用户选择，有效地利用IC卡的信息资源，为用户匹配到个性化的虚拟支付卡，有利于提高用户使用虚拟支付卡的体验感，以及有利于虚拟支付卡的推广。

作为一个可选的实施例，该后台服务平台还可以包括第一确定模块304以及第一判断模块305，此时，后台服务平台的结构示意图可以如图4所示，图4为另一种后台服务平台的结构示意图，其中：

第一确定模块304，用于在接收模块301接收某一客户端发送的申请请求之后，以及在发送模块302根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择之前，基于申请请求包括的实体IC卡的卡信息确定该实体IC卡的卡类型。

第一判断模块305，用于判断实体IC卡的卡类型是否为租赁类型。

发送模块302，还用于当第一判断模块305判断出实体IC卡的卡类型不为租赁类型时，根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择。

第一判断模块305，还用于当判断出实体IC卡的卡类型为租赁类型时，判断该实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件。

发送模块302，还用于当第一判断模块305判断出实体IC卡的卡类型为租赁类型以及当第一判断模块305判断出实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件时，根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择。

可见，实施图4所示的后台服务平台还能够在接收到客户端发送的申请请求之后，进一步根据申请请求包括的实体IC卡的卡信息判断实体IC卡的卡类型是否为租赁类型，当判断的结果为否时，继续执行后续的向客户端发送至少一种虚拟支付卡类型标识供客户端的用户选择的操作；当判断的结果为是时，在实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件之后，继续执行后续的向客户端发送至少一种虚拟支付卡类型标识供客户端的用户选择的操作，既能够智能化判断实体IC卡的卡类型，丰富后台服务平台的智能化功能，又能够使得卡类型为租赁类型的实体IC卡也能够生成对应的虚拟支付卡，尤其对于来某地出行(旅行)的用户，当用户需要离开出行地(旅行地)时，可以将实体IC卡的余额转移至虚拟支付卡，以便下次直接通过虚拟支付卡进行交易，降低因实体IC卡过期(租赁类型的实体IC卡为短期实体IC卡)或者长时间携带而导致实体IC卡丢失造成用户的经济损失，进一步提升用户的体验感。

作为另一个可选的实施例，如图4所示，第一判断模块305判断实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件的方式具体为：

判断实体IC卡的交易总次数是否大于等于预设交易总次数；

当判断出实体IC卡的总交易次数大于等于预设交易总次数时，查询实体IC卡的剩余金额，并判断剩余金额是否大于等于预设金额；

当判断出剩余金额大于等于预设金额时，确定实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件。

可见，实施图4所示的后台服务平台还能够在判断出租赁类型的实体IC卡在预设时段内的交易总次数大于等于预设交易总次数以及剩余金额大于等于预设金额满足时，确定租赁类型的实体IC卡满足预先确定出的虚拟支付卡生成条件能够丰富后台服务平台的智能化功能。

作为又一个可选的实施例，如图4所示，该后台服务平台还可以包括第二确定模块306以及第一转移模块307，其中：

第二确定模块306，用于在生成模块303根据目标虚拟支付卡类型标识生成与目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡之后，确定需要从实体IC卡的所有信息中转移至第一目标虚拟支付卡的目标信息。

第一转移模块307，用于将目标信息转移至第一目标虚拟支付卡。

发送模块302，还用于向某一客户端发送第一目标虚拟支付卡以及第一目标虚拟支付卡的相关信息，该第一目标虚拟支付卡的相关信息至少包括上述目标信息。

可见，实施图4所示的后台服务平台还能够通过在生成虚拟支付卡之后，还将实体IC卡中的相关信息转移至虚拟支付卡中，而无需手动将实体IC卡的信息添加至虚拟支付卡，能够提高实体IC卡的卡信息的转移效率以及便于后台服务平台对虚拟支付卡的管理。

作为又一个可选的实施例，如图4所示，该后台服务平台还可以包括第二判断模块308、第三确定模块309以及第二转移模块310，其中：

第二判断模块308，用于在接收模块301接收某一客户端发送的申请请求之后，以及在发送模块302根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择之前，根据申请请求包括的实体IC卡的卡信息判断实体IC卡是否存在对应的第二目标虚拟支付卡。

发送模块302，还用于当第二判断模块308判断出实体IC卡未存在对应的第二目标虚拟支付卡时，根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择。

第三确定模块309，用于当第二判断模块308判断出实体IC卡已存在对应的第二目标虚拟支付卡时，确定需要从实体IC卡转移至第二目标虚拟支付卡的目标金额。

第二转移模块310，用于将第二目标虚拟支付卡的目标金额转移至第二目标虚拟支付卡中。

可见，实施图4所示的后台服务平台还能够通过在接收到客户端发送的申请请求之后，进一步根据申请请求包括的实体IC卡的卡信息判断实体IC卡是否已经存在对应的虚拟支付卡，当判断的结果为否时，继续执行后续的向客户端发送至少一种虚拟支付卡类型标识供客户端的用户选择的操作；当判断的结果为是时，确定需要从实体IC卡转移至虚拟支付卡的金额，能够降低用户因忘记申请过虚拟支付卡而导致再次申请的可能性，以及提高实体IC卡的金额转移效率。

作为又一个可选的实施例，如图4所示，该后台服务平台还可以包括筛选模块311，其中：

筛选模块311，用于在接收模块301接收某一客户端发送的申请请求之后，以及在发送模块302根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择之前，根据申请请求包括的实体IC卡的卡信息从筛选出该实体IC卡的标识信息；

第三确定模块309，还用于从预先确定出的所有虚拟支付卡类型标识中确定与实体IC卡的标识信息对应的至少一种虚拟支付卡类型标识，并触发发送模块302执行上述的根据申请请求向某一客户端发送至少一种虚拟支付卡类型标识供某一客户端的用户选择的操作。

可见，实施图4所示的后台服务平台还能够通过向用户发送优惠提示，有利于虚拟支付卡的推广以及提高虚拟支付卡变现的概率。

作为又一个可选的实施例，如图4所示，第三确定模块309，还用于在接收模块301接收某一客户端发送的目标虚拟支付卡类型标识之后，以及在生成模块303根据目标虚拟支付卡类型标识生成与该目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡之前，确定目标虚拟支付卡类型标识的数量；当目标虚拟支付卡类型标识的数量大于1时，确定某一客户端的用户的身份信息；

筛选模块311，还用于从所有目标虚拟支付卡类型标识中选择与身份信息以及实体IC卡的卡信息相匹配的目标虚拟支付卡类型标识，并触发生成模块303执行上述的根据目标虚拟支付卡类型标识生成与该目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡的操作。

可见，实施图4所示的后台服务平台还能够通过在接收到客户端反馈的虚拟支付卡类型标识之后，先确定虚拟支付卡类型标识的数量，当数量大于1时，确定客户端的用户的身份信息，并从所有虚拟支付卡类型标识中筛选出与身份信息以及实体IC卡的卡信息相匹配的一个虚拟支付卡类型标识，能够提高虚拟支付卡类型标识的确定精确度，从而有利于生成满足用户需求的虚拟支付卡，提升用户的体验感，进而进一步有利于虚拟支付卡的推广。

作为又一个可选的实施例，如图4所示，该后台服务平台还可以包括定位模块312，其中：

定位模块312，用于当第一判断模块305判断出实体IC卡的卡类型为租赁类型时，定位某一客户端的第一地理位置；

第一确定模块304，还用于根据某一客户端的第一地理位置确定出与该第一地理位置相匹配的实体IC卡归还服务点以及该实体IC卡归还服务点的第二地理位置；

发送模块302，还用于向某一客户端发送实体IC卡的归还提示，以使某一客户端输出归还提示，该归还提示用于提示某一客户端的用户在使用完毕实体IC卡后归还实体IC卡，且该归还提示至少包括实体IC卡归还服务点的第二地理位置。

第一确定模块304，还用于根据某一客户端的第一地理位置以及实体IC卡服务点的第二地理位置确定第一地理位置到第二地理位置的交通方式，此时，上述归还提示还包括与实体IC卡归还服务点对应的交通方式。

可见，实施图4所示的后台服务平台还能够通过在判断出实体IC卡的卡类型为租赁类型时，向用户输出包含实体IC卡归还服务点的地理位置的归还提示，而无需用户再自行搜索实体IC卡归还服务点的地理位置，能够使用户快速知晓实体IC卡归还服务点，有利于用户尽快归还实体IC卡。进一步的，归还提示还包括到达实体IC卡归还服务点的交通方式，能够方便用户根据实际情况选择到合意的交通方式，进一步提升用户的体验感。

实施例四

请参阅图5，图5是本发明实施例公开的又一种后台服务平台的结构示意图。如图5所示，该后台服务平台可以包括：

存储有可执行程序代码的存储器501；

与存储器501耦合的处理器502；

处理器502调用存储器501中存储的可执行程序代码，执行实施例一～实施例二中任意一个实施例所描述的虚拟支付卡的生成控制方法中的步骤。

实施例五

本发明实施例公开了一种计算机可读存储介质，其存储用于电子数据交换的计算机程序，其中，该计算机程序使得计算机执行实施例一～实施例二中任意一个实施例所描述的虚拟支付卡的生成控制方法中的步骤。

实施例六

本发明实施例公开了一种计算机程序产品，该计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，且该计算机程序可操作来使计算机执行实施例一～实施例二中任意一个实施例所描述的虚拟支付卡的生成控制方法中的步骤。

以上所描述的装置实施例仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施例的具体描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中,存储介质包括只读存储器(Read-Only Memory，ROM)、随机存储器(Random Access Memory，RAM)、可编程只读存储器(Programmable Read-only Memory，PROM)、可擦除可编程只读存储器(ErasableProgrammable Read Only Memory，EPROM)、一次可编程只读存储器(One-timeProgrammable Read-Only Memory，OTPROM)、电子抹除式可复写只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。

最后应说明的是：本发明实施例公开的一种虚拟支付卡的生成控制方法及后台服务平台所揭露的仅为本发明较佳实施例而已，仅用于说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解；其依然可以对前述各项实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或替换，并不使相应的技术方案的本质脱离本发明各项实施例技术方案的精神和范围。

Claims (10)

1.一种虚拟支付卡的生成控制方法，其特征在于，所述方法应用于后台服务平台中，所述方法包括：

所述后台服务平台接收某一客户端发送的申请请求，所述申请请求用于申请虚拟支付卡，且所述申请请求包括所述某一客户端识别到的实体IC卡的卡信息；

所述后台服务平台根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述后台服务平台接收所述某一客户端发送的目标虚拟支付卡类型标识，所述目标虚拟支付卡类型标识为所述某一客户端的用户从所述至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识；

所述后台服务平台根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡；

其中，所述后台服务平台接收某一客户端发送的申请请求之后，以及所述后台服务平台根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，所述方法还包括：

所述后台服务平台基于所述申请请求包括的所述实体IC卡的卡信息确定所述实体IC卡的卡类型，并判断所述实体IC卡的卡类型是否为租赁类型；

当判断出所述实体IC卡的卡类型为所述租赁类型时，所述后台服务平台判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件；

当判断出所述实体IC卡的当前条件满足所述预先确定出的虚拟支付卡生成条件时，所述后台服务平台触发执行所述的根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择的操作。

2.根据权利要求1所述的虚拟支付卡的生成控制方法，其特征在于，所述方法还包括：

当判断出所述实体IC卡的卡类型不为所述租赁类型时，所述后台服务平台触发执行所述的根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择的操作。

3.根据权利要求2所述的虚拟支付卡的生成控制方法，其特征在于，所述后台服务平台判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件，包括：

所述后台服务平台判断所述实体IC卡的交易总次数是否大于等于预设交易总次数；

当判断出所述实体IC卡的总交易次数大于等于所述预设交易总次数时，所述后台服务平台查询所述实体IC卡的剩余金额，并判断所述剩余金额是否大于等于预设金额；

当判断出所述剩余金额大于等于所述预设金额时，所述后台服务平台确定所述实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件。

4.根据权利要求1-3任一项所述的虚拟支付卡的生成控制方法，其特征在于，所述后台服务平台根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡之后，所述方法还包括：

所述后台服务平台确定需要从所述实体IC卡的所有信息中转移至所述第一目标虚拟支付卡的目标信息；

所述后台服务平台将所述目标信息转移至所述第一目标虚拟支付卡，并向所述某一客户端发送所述第一目标虚拟支付卡以及所述第一目标虚拟支付卡的相关信息，所述第一目标虚拟支付卡的相关信息至少包括所述目标信息。

5.根据权利要求1-3任一项所述的虚拟支付卡的生成控制方法，其特征在于，所述后台服务平台接收某一客户端发送的申请请求之后，以及所述后台服务平台根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，所述方法还包括：

所述后台服务平台根据所述申请请求包括的所述实体IC卡的卡信息判断所述实体IC卡是否存在对应的第二目标虚拟支付卡；

当判断出所述实体IC卡未存在对应的所述第二目标虚拟支付卡时，所述后台服务平台执行所述的根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择的操作；

当判断出所述实体IC卡已存在对应的所述第二目标虚拟支付卡时，所述后台服务平台确定需要从所述实体IC卡转移至所述第二目标虚拟支付卡的目标金额，并将所述目标金额转移至所述第二目标虚拟支付卡中。

6.一种后台服务平台，其特征在于，所述后台服务平台包括接收模块、发送模块以及生成模块，其中：

所述接收模块，用于接收某一客户端发送的申请请求，所述申请请求用于申请虚拟支付卡，且所述申请请求包括所述某一客户端识别到的实体IC卡的卡信息；

所述发送模块，用于根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述接收模块，还用于接收所述某一客户端发送的目标虚拟支付卡类型标识，所述目标虚拟支付卡类型标识为所述某一客户端的用户从所述至少一种虚拟支付卡类型标识中选择的虚拟支付卡类型标识；

所述生成模块，用于根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡；

所述后台服务平台还包括第一确定模块以及第一判断模块，其中：

所述第一确定模块，用于在所述接收模块接收某一客户端发送的申请请求之后，以及在所述发送模块根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，基于所述申请请求包括的所述实体IC卡的卡信息确定所述实体IC卡的卡类型；

所述第一判断模块，用于判断所述实体IC卡的卡类型是否为租赁类型；

所述第一判断模块，还用于当判断出所述实体IC卡的卡类型为所述租赁类型时，判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件；

所述发送模块，还用于当所述第一判断模块判断出所述实体IC卡的卡类型为所述租赁类型以及当所述第一判断模块判断出所述实体IC卡的当前条件满足所述预先确定出的虚拟支付卡生成条件时，根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择。

7.根据权利要求6所述的后台服务平台，其特征在于，所述发送模块，还用于当所述第一判断模块判断出所述实体IC卡的卡类型不为所述租赁类型时，根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择。

8.根据权利要求7所述的后台服务平台，其特征在于，所述第一判断模块判断所述实体IC卡的当前条件是否满足预先确定出的虚拟支付卡生成条件的方式具体为：

判断所述实体IC卡的交易总次数是否大于等于预设交易总次数；

当判断出所述实体IC卡的总交易次数大于等于所述预设交易总次数时，查询所述实体IC卡的剩余金额，并判断所述剩余金额是否大于等于预设金额；

当判断出所述剩余金额大于等于所述预设金额时，确定所述实体IC卡的当前条件满足预先确定出的虚拟支付卡生成条件。

9.根据权利要求6-8任一项所述的后台服务平台，其特征在于，所述后台服务平台还包括第二确定模块以及第一转移模块，其中：

所述第二确定模块，用于在所述生成模块根据所述目标虚拟支付卡类型标识生成与所述目标虚拟支付卡类型标识相匹配的第一目标虚拟支付卡之后，确定需要从所述实体IC卡的所有信息中转移至所述第一目标虚拟支付卡的目标信息；

所述第一转移模块，用于将所述目标信息转移至所述第一目标虚拟支付卡；

所述发送模块，还用于向所述某一客户端发送所述第一目标虚拟支付卡以及所述第一目标虚拟支付卡的相关信息，所述第一目标虚拟支付卡的相关信息至少包括所述目标信息。

10.根据权利要求6-8任一项所述的后台服务平台，其特征在于，所述后台服务平台还包括第二判断模块、第三确定模块以及第二转移模块，其中：

所述第二判断模块，用于在所述接收模块接收某一客户端发送的申请请求之后，以及在所述发送模块根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择之前，根据所述申请请求包括的所述实体IC卡的卡信息判断所述实体IC卡是否存在对应的第二目标虚拟支付卡；

所述发送模块，还用于当所述第二判断模块判断出所述实体IC卡未存在对应的所述第二目标虚拟支付卡时，根据所述申请请求向所述某一客户端发送至少一种虚拟支付卡类型标识供所述某一客户端的用户选择；

所述第三确定模块，用于当所述第二判断模块判断出所述实体IC卡已存在对应的所述第二目标虚拟支付卡时，确定需要从所述实体IC卡转移至所述第二目标虚拟支付卡的目标金额；

所述第二转移模块，用于将所述目标金额转移至所述第二目标虚拟支付卡中。