CN109615450A - 业务信息的处理方法、装置及系统 - Google Patents

Abstract

本申请公开了一种业务信息的处理方法、装置及系统，涉及信息处理技术领域，可以满足用户的多元化需求。其中方法包括：接收对业务套餐对象的核销指令，所述业务套餐对象中包含不同品类的业务对象；向所述服务器发送携带有所述业务套餐对象对应套餐标识信息的核销请求指令，以使得所述服务器在查询到与所述套餐标识信息对应的所述业务套餐对象后，对所述业务套餐对象中包含的所述不同品类的业务对象分别进行核销处理；接收所述服务器发送的核销处理结果信息。本申请适用于业务信息的处理。

Description

业务信息的处理方法、装置及系统

技术领域

本申请涉及信息处理技术领域，尤其是涉及到一种业务信息的处理方法、装置及系统。

背景技术

随着互联网技术的不断发展，网络购物越来越流行。人们不但可以在网上购买衣服、日用品等，还可以在网上进行酒店客房预订、网上订餐等，使得人们生活更加高效和便捷。

目前，为了促进商品销售，同一家商户下的多个商品可采用绑定销售的方式，促进用户一次购买多个商品。然而，同一家商户销售的商品往往品类相同，不能满足用户的多元化需求，如果用户同一时间对不同品类的多个商品都有需求，那么需要对这些不同品类的商品分别进行购买，会花费用户大量时间，造成用户的体验较差。

发明内容

有鉴于此，本申请提供了一种业务信息的处理方法、装置及系统，主要目的在于解决目前现有技术中不能满足用户的多元化需求，会造成用户的体验较差的问题。

根据本申请的一个方面，提供了一种业务信息的处理方法，可应用于客户端，该方法包括：

接收对业务套餐对象的核销指令，所述业务套餐对象中包含不同品类的业务对象；

向所述服务器发送携带有所述业务套餐对象对应套餐标识信息的核销请求指令，以使得所述服务器在查询到与所述套餐标识信息对应的所述业务套餐对象后，对所述业务套餐对象中包含的所述不同品类的业务对象分别进行核销处理；

接收所述服务器发送的核销处理结果信息。

可选的，在所述接收对业务套餐对象的核销指令之前，所述方法还包括：

当接收到获取所述业务套餐对象的指令时，向所述服务器发送所述业务套餐对象的获取请求指令，以使得所述服务器查询所述业务套餐对象包含的所述不同品类的业务对象的库存信息和相应的获取条件信息；

接收所述服务器发送的所述业务套餐对象对应的核销凭证码，所述核销凭证码是所述服务器根据所述库存信息和所述获取条件信息确定需要获取所述业务套餐对象的用户具备获取资格时返回的。

可选的，所述接收对业务套餐对象的核销指令，具体包括：

当检测到存在所述核销凭证码的特征信息时，对所述核销凭证码进行扫码识别，得到所述业务套餐对象对应的所述套餐标识信息。

可选的，所述接收所述服务器发送的核销处理结果信息，具体包括：

接收所述服务器发送的核销处理成功信息，所述核销处理成功信息是所述服务器在对所述不同品类的业务对象都核销处理成功时发送的；或

接收所述服务器发送的核销处理失败信息，所述核销处理失败信息是所述服务器未查询到与所述套餐标识信息对应的所述业务套餐对象、或所述业务套餐对象中存在至少一个业务对象核销处理失败时发送的。

可选的，若接收到所述服务器发送的核销处理失败信息，则所述方法还包括：

若确定所述业务套餐对象已过期失效，则查询与所述业务套餐对象对应的相似业务套餐对象信息，并将所述相似业务套餐对象信息和与所述相似业务套餐对象信息对应的获取渠道信息进行推荐输出。

可选的，所述核销请求指令中还携带有所在终端的当前位置信息，以使得所述服务器在对所述不同品类的业务对象都核销处理成功后，根据所述当前位置信息确定所述不同品类的业务对象分别对应的配送地址信息。

可选的，在接收所述服务器发送的核销处理结果信息之后，所述方法还包括：

将所述核销处理结果信息进行输出。

根据本申请的另一方面，提供了另一种业务信息的处理方法，可应用于服务器，该方法包括：

接收客户端发送的核销请求指令，所述核销请求指令中携带有业务套餐对象对应的套餐标识信息；

查询与所述套餐标识信息对应的所述业务套餐对象；

获取所述业务套餐对象中包含的不同品类的业务对象；

分别对所述不同品类的业务对象进行核销处理；

向所述客户端发送核销处理结果信息。

可选的，所述分别对所述不同品类的业务对象进行核销处理，具体包括：

获取所述不同品类的业务对象分别对应的使用状态和有效时间范围；

若所述不同品类的业务对象的所述使用状态都为未使用状态、且当前核销处理时间分别处于所述不同品类的业务对象的所述有效时间范围内，则分别对所述不同品类的业务对象进行核销处理；

若所述不同品类的业务对象中存在至少一个业务对象的使用状态为已使用状态、或当前核销处理时间处于所述不同品类的业务对象中至少一个业务对象的所述有效时间范围外，则取消对所述不同品类的业务对象进行核销处理。

可选的，在所述接收客户端发送的核销请求指令之前，所述方法还包括：

统计样本用户在同一时间段内对不同品类的样本业务对象的获取需求信息；

从所述不同品类的样本业务对象中获取所述获取需求信息所占比重大于预设阈值的各个目标样本业务对象；

分析不同品类的所述目标样本业务对象之间的关联关系；

根据所述关联关系符合预设搭配标准条件的不同品类的所述目标样本业务对象，生成可选业务套餐对象；

将所述可选业务套餐对象作为推荐信息发送给不同的客户端。

可选的，所述推荐信息还包含根据所述可选业务套餐对象中各个业务对象实时的最优获取方式信息，确定得到的所述可选业务套餐对象实时的最优获取方式信息。

可选的，在所述接收客户端发送的核销请求指令之前，所述方法还包括：

当接收到客户端发送的所述业务套餐对象的获取请求指令时，查询所述业务套餐对象包含的所述不同品类的业务对象的库存信息和相应的获取条件信息；

根据所述库存信息和所述获取条件信息确定所述客户端所对应的用户是否具备获取所述业务套餐对象的获取资格；

若具备，则生成所述业务套餐对象对应的核销凭证码并发送给所述客户端。

可选的，所述获取请求指令中携带有支付信息；

所述根据所述库存信息和所述获取条件信息确定所述客户端所对应的用户是否具备获取所述业务套餐对象的获取资格，具体包括：

若所述不同品类的业务对象的库存充足、且所述支付信息与所述不同品类的业务对象的获取条件信息匹配，则确定所述客户端所对应的用户具备获取所述业务套餐对象的获取资格；

若所述不同品类的业务对象中存在至少一个业务对象的库存不足、或所述支付信息与所述获取条件信息不匹配，则确定所述客户端所对应的用户不具备获取所述业务套餐对象的获取资格。

可选的，若所述客户端所对应的用户具备获取所述业务套餐对象的获取资格，则所述方法还包括：

将所述支付信息发送给中间账户服务器，以便在确定所述业务套餐对象被核销处理成功后，由所述中间账户服务器向所述不同品类的业务对象分别对应的账户服务器分配所述支付信息。

可选的，在所述接收客户端发送的核销请求指令之前，所述方法还包括：

当接收到客户端发送的所述业务套餐对象的退回请求指令时，将生成的所述业务套餐对象对应的核销凭证码进行无效标记，并向所述中间账户服务器发送支付信息退回指令，以便将所述中间账户服务器返回的所述支付信息退回给所述客户端。

可选的，所述向所述客户端发送核销处理结果信息，具体包括：

若对所述不同品类的业务对象都核销处理成功，则向所述客户端发送核销处理成功信息；

若未查询到与所述套餐标识信息对应的所述业务套餐对象、或所述业务套餐对象中存在至少一个业务对象核销处理失败，则向所述客户端发送核销处理失败信息。

可选的，所述核销请求指令中还携带有所述客户端所在终端的当前位置信息；

在所述对所述不同品类的业务对象都核销处理成功之后，所述方法还包括：

根据所述当前位置信息确定所述不同品类的业务对象分别对应的配送地址信息。

可选的，所述根据所述当前位置信息确定所述不同品类的业务对象分别对应的配送地址信息，具体包括：

获取所述不同品类的业务对象分别对应的提供方地址信息；

将所述当前位置信息与所述提供方地址信息进行匹配；

若存在匹配的提供方地址信息，则将所述匹配的提供方地址信息确定为所述不同品类的业务对象分别对应的配送地址信息。

根据本申请的又一方面，提供了一种业务信息的处理装置，可应用于客户端，该装置包括：

接收单元，用于接收对业务套餐对象的核销指令，所述业务套餐对象中包含不同品类的业务对象；

发送单元，用于向所述服务器发送携带有所述业务套餐对象对应套餐标识信息的核销请求指令，以使得所述服务器在查询到与所述套餐标识信息对应的所述业务套餐对象后，对所述业务套餐对象中包含的所述不同品类的业务对象分别进行核销处理；

所述接收单元，还用于接收所述服务器发送的核销处理结果信息。

可选的，所述发送单元，还用于当接收到获取所述业务套餐对象的指令时，向所述服务器发送所述业务套餐对象的获取请求指令，以使得所述服务器查询所述业务套餐对象包含的所述不同品类的业务对象的库存信息和相应的获取条件信息；

所述接收单元，还用于接收所述服务器发送的所述业务套餐对象对应的核销凭证码，所述核销凭证码是所述服务器根据所述库存信息和所述获取条件信息确定需要获取所述业务套餐对象的用户具备获取资格时返回的。

可选的，所述接收单元，具体用于当检测到存在所述核销凭证码的特征信息时，对所述核销凭证码进行扫码识别，得到所述业务套餐对象对应的所述套餐标识信息。

可选的，所述接收单元，具体用于接收所述服务器发送的核销处理成功信息，所述核销处理成功信息是所述服务器在对所述不同品类的业务对象都核销处理成功时发送的；或

接收所述服务器发送的核销处理失败信息，所述核销处理失败信息是所述服务器未查询到与所述套餐标识信息对应的所述业务套餐对象、或所述业务套餐对象中存在至少一个业务对象核销处理失败时发送的。

可选的，所述装置还包括：

查询单元，用于若接收到所述服务器发送的核销处理失败信息，则在确定所述业务套餐对象已过期失效时，查询与所述业务套餐对象对应的相似业务套餐对象信息；

输出单元，用于将所述相似业务套餐对象信息和与所述相似业务套餐对象信息对应的获取渠道信息进行推荐输出。

可选的，所述核销请求指令中还携带有所在终端的当前位置信息，以使得所述服务器在对所述不同品类的业务对象都核销处理成功后，根据所述当前位置信息确定所述不同品类的业务对象分别对应的配送地址信息。

可选的，所述装置还包括：

输出单元，用于将所述核销处理结果信息进行输出。

依据本申请再一个方面，提供了一种业务信息的处理装置，可应用于服务器，该装置包括：

接收单元，用于接收客户端发送的核销请求指令，所述核销请求指令中携带有业务套餐对象对应的套餐标识信息；

查询单元，用于查询与所述套餐标识信息对应的所述业务套餐对象；

获取单元，用于获取所述业务套餐对象中包含的不同品类的业务对象；

处理单元，用于分别对所述不同品类的业务对象进行核销处理；

发送单元，用于向所述客户端发送核销处理结果信息。

可选的，所述处理单元，具体用于获取所述不同品类的业务对象分别对应的使用状态和有效时间范围；

若所述不同品类的业务对象的所述使用状态都为未使用状态、且当前核销处理时间分别处于所述不同品类的业务对象的所述有效时间范围内，则分别对所述不同品类的业务对象进行核销处理；

若所述不同品类的业务对象中存在至少一个业务对象的使用状态为已使用状态、或当前核销处理时间处于所述不同品类的业务对象中至少一个业务对象的所述有效时间范围外，则取消对所述不同品类的业务对象进行核销处理。

可选的，所述装置还包括：统计单元、分析单元、生成单元；

所述统计单元，用于统计样本用户在同一时间段内对不同品类的样本业务对象的获取需求信息；

所述获取单元，还用于从所述不同品类的样本业务对象中获取所述获取需求信息所占比重大于预设阈值的各个目标样本业务对象；

所述分析单元，用于分析不同品类的所述目标样本业务对象之间的关联关系；

所述生成单元，用于根据所述关联关系符合预设搭配标准条件的不同品类的所述目标样本业务对象，生成可选业务套餐对象；

所述发送单元，还用于将所述可选业务套餐对象作为推荐信息发送给不同的客户端。

可选的，所述推荐信息还包含根据所述可选业务套餐对象中各个业务对象实时的最优获取方式信息，确定得到的所述可选业务套餐对象实时的最优获取方式信息。

可选的，所述装置还包括：确定单元和生成单元；

所述查询单元，还用于当接收到客户端发送的所述业务套餐对象的获取请求指令时，查询所述业务套餐对象包含的所述不同品类的业务对象的库存信息和相应的获取条件信息；

所述确定单元，用于根据所述库存信息和所述获取条件信息确定所述客户端所对应的用户是否具备获取所述业务套餐对象的获取资格；

所述生成单元，用于若所述客户端具备获取所述业务套餐对象的获取资格，则生成所述业务套餐对象对应的核销凭证码并发送给所述客户端。

可选的，所述获取请求指令中携带有支付信息；

所述确定单元，具体用于若所述不同品类的业务对象的库存充足、且所述支付信息与所述不同品类的业务对象的获取条件信息匹配，则确定所述客户端所对应的用户具备获取所述业务套餐对象的获取资格；

若所述不同品类的业务对象中存在至少一个业务对象的库存不足、或所述支付信息与所述获取条件信息不匹配，则确定所述客户端所对应的用户不具备获取所述业务套餐对象的获取资格。

可选的，所述发送单元，还用于若所述客户端所对应的用户具备获取所述业务套餐对象的获取资格，则将所述支付信息发送给中间账户服务器，以便在确定所述业务套餐对象被核销处理成功后，由所述中间账户服务器向所述不同品类的业务对象分别对应的账户服务器分配所述支付信息。

可选的，所述发送单元，还用于当接收到客户端发送的所述业务套餐对象的退回请求指令时，将生成的所述业务套餐对象对应的核销凭证码进行无效标记，并向所述中间账户服务器发送支付信息退回指令，以便将所述中间账户服务器返回的所述支付信息退回给所述客户端。

可选的，所述发送单元，具体用于若对所述不同品类的业务对象都核销处理成功，则向所述客户端发送核销处理成功信息；

若未查询到与所述套餐标识信息对应的所述业务套餐对象、或所述业务套餐对象中存在至少一个业务对象核销处理失败，则向所述客户端发送核销处理失败信息。

可选的，所述核销请求指令中还携带有所述客户端所在终端的当前位置信息，所述装置还包括：

确定单元，用于根据所述当前位置信息确定所述不同品类的业务对象分别对应的配送地址信息。

可选的，所述确定单元，具体用于获取所述不同品类的业务对象分别对应的提供方地址信息；

将所述当前位置信息与所述提供方地址信息进行匹配；

若存在匹配的提供方地址信息，则将所述匹配的提供方地址信息确定为所述不同品类的业务对象分别对应的配送地址信息。

依据本申请再一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述可应用于客户端的业务信息的处理方法。

依据本申请再一个方面，提供了一种终端设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述可应用于客户端的业务信息的处理方法。

依据本申请再一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述可应用于服务器的业务信息的处理方法。

依据本申请再一个方面，提供了一种服务器设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述可应用于服务器的业务信息的处理方法。

依据本申请再一个方面，提供了一种业务信息的处理系统，包括上述终端设备和服务器设备。

借由上述技术方案，本申请提供的一种业务信息的处理方法、装置及系统，与目前现有技术相比，本申请可预先设置包含不同品类业务对象的业务套餐对象，由用户选择获取，在获取到的业务套餐对象需要核销时，向服务器发送携带有该业务套餐对象对应套餐标识信息的核销请求指令，进而可使得服务器在查询到与该套餐标识信息对应的业务套餐对象后，对该业务套餐对象中包含的不同品类的业务对象分别进行核销处理，进而实现该业务套餐对象中包含的不同品类的业务对象的一次性核销，从而可以使得用户一次性获得不同品类的业务对象的服务，满足了用户的多元化需求，并且无需用户对这些不同品类的业务对象分别进行订购获取，节省了用户的时间，可以提升用户的体验。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种业务信息的处理方法的流程示意图；

图2示出了本申请实施例提供的另一种业务信息的处理方法的流程示意图；

图3示出了本申请实施例提供的一种商品套餐的架构实例示意图；

图4示出了本申请实施例提供的一种获取商品套餐的实例流程示意图；

图5示出了本申请实施例提供的一种对于商品套餐的支付打款实例的流程示意图；

图6示出了本申请实施例提供的一种对于商品套餐的凭证发放实例的流程示意图；

图7示出了本申请实施例提供的一种对于商品套餐的支付核销实例的流程示意图；

图8示出了本申请实施例提供的一种商品套餐整体处理实例的流程示意图；

图9示出了本申请实施例提供的又一种业务信息的处理方法的流程示意图；

图10示出了本申请实施例提供的一种业务信息的处理装置的结构示意图；

图11示出了本申请实施例提供的另一种业务信息的处理装置的结构示意图；

图12示出了本申请实施例提供的又一种业务信息的处理装置的结构示意图；

图13示出了本申请实施例提供的再一种业务信息的处理装置的结构示意图；

图14示出了本申请实施例提供的一种业务信息的处理系统的系统架构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

针对目前现有技术中存在的问题，本实施例提供了一种业务信息的处理方法，可应用于客户端侧，可使得用户一次性获得不同品类的业务对象的服务，进而满足用户的多元化需求，如图1所示，该方法包括：

101、客户端接收对业务套餐对象的核销指令。

其中，业务套餐对象中包含不同品类的业务对象，而每一品类的业务对象可为一个或者多个。业务对象的具体内容可根据实际需求预先设定。不同品类的业务对象可分别向用户提供不同角度的业务服务，业务套餐对象相当于包含这些业务对象的集合。例如，对于商品角度的业务套餐对象相当于商品套餐券，其具体可包含门店餐品券、酒店客房券、按摩服务券等业务对象，用户一次获取该业务套餐对象，相当于一次获取订餐、酒店休息、按摩等服务。在本实施例中，可预先根据实际业务需求组合不同品类的业务对象，生成特定的业务套餐对象。

对于本实施例的执行主体可以为用于业务信息处理的客户端装置或设备，具体可用于业务套餐对象的核销。在用户获取该业务套餐对象后，如果需要体验该业务套餐对象中包含的各个业务对象分别提供的业务服务，可通过核销该业务套餐对象实现。例如，可通过出示该业务套餐对象的识别码、或用户的支付码等，然后通过扫码触发客户端执行后续的核销操作，即输入对业务套餐对象的核销指令，再或者通过刷脸支付、指纹支付等方式也可在后台查找到该业务套餐对象对应的套餐标识信息，进而实现触发客户端执行后续的核销操作，其中具体的核销操作过程可执行步骤102至103所示过程。

102、向服务器发送携带有业务套餐对象对应套餐标识信息的核销请求指令。

进一步的，以使得服务器在查询到与套餐标识信息对应的业务套餐对象后，对业务套餐对象中包含的不同品类的业务对象分别进行核销处理。其中，套餐标识信息可为业务套餐对象的名称或ID号等。服务器可为用于业务套餐对象支付核销的装置或设备，对于本实施例，可通过向服务器发送携带有业务套餐对象对应套餐标识信息的核销请求指令，实现对业务套餐对象的在线核销。服务器在后台逐个查询业务套餐对象包含的每个业务对象，然后对这些业务对象进行核销，进而一次性实现核销多个不同品类的业务对象。

103、接收服务器发送的核销处理结果信息。

其中，核销处理结果信息中可包含对业务套餐对象的核销情况，如果业务套餐对象中包含的各个业务对象都核销成功，那么可确定需要向用户提供各个业务对象对应的业务服务。

本实施例提供的一种可应用于客户端侧的业务信息的处理方法，与目前现有技术相比，本实施例可实现业务套餐对象中包含的不同品类的业务对象的一次性核销，进而可使得用户一次性获得不同品类的业务对象的服务，满足了用户的多元化需求，并且无需用户对这些不同品类的业务对象分别进行订购获取，节省了用户的时间，可以提升用户的体验。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例中的过程，提供了另一种业务信息的处理方法，如图2所示，该方法包括：

201、当接收到获取业务套餐对象的指令时，客户端向服务器发送业务套餐对象的获取请求指令。

进一步的，以使得服务器查询业务套餐对象包含的不同品类的业务对象的库存信息和相应的获取条件信息。其中，库存信息中可包含业务对象实时的库存情况；获取条件信息中可包含获取业务对象的条件有哪些，例如，从哪些渠道可获取，获取的资格或权限的要求是什么等。

例如，可事先为用户提供多种可选的业务套餐对象，用户可查看每种业务套餐对象包含的各个业务对象内容，然后根据自身的实际需求选择获取，进而输入获取特定业务套餐对象的指令，进而客户端向服务器获取发送该业务套餐对象的获取请求指令，使得服务器根据该业务套餐对象包含的不同品类的业务对象的库存信息和相应的获取条件信息，判断该用户是否具备获取该业务套餐对象的资格条件，如果这些业务对象的库存都足够且该用户符合获取这些业务对象的条件，那么可确定该用户获取该业务套餐对象成功。如果这些业务对象中存在库存不足的业务对象，则确定该用户获取该业务套餐对象失败。

202、接收服务器发送的业务套餐对象对应的核销凭证码。

其中，核销凭证码是服务器根据库存信息和获取条件信息确定需要获取业务套餐对象的用户具备获取资格时返回的。核销凭证码用于核销对应的业务套餐对象，具体形式可为一维或多维条码，或者由这些种类的条码组合得到。用户可向商家出示该核销凭证码，然后由商家扫码实现对相应的业务套餐对象进行核销。

203、当检测到存在核销凭证码的特征信息时，对核销凭证码进行扫码识别，得到业务套餐对象对应的套餐标识信息。

其中，特征信息可为核销凭证码相关的条码特征。通过对核销凭证码的特征信息进行检测，进而确定核销凭证码准确的待识别位置，从而实现对核销凭证码进行准确扫码识别。

204、向服务器发送携带有业务套餐对象对应套餐标识信息的核销请求指令。

进一步的，以使得服务器在查询到与套餐标识信息对应的业务套餐对象后，对业务套餐对象中包含的不同品类的业务对象分别进行核销处理。

由于这些业务对象的品类不同，相应的配送地址信息往往不统一，而用户有时需要在特定的地点接收这些业务对象提供的服务，进而需要手动修改这些业务对象的配送地址，效率低下，从而影响用户的使用体验。为了解决这一问题，作为一种可选方式，在向服务器发送的核销请求指令中还可携带有所在终端的当前位置信息，进而使得服务器在对不同品类的业务对象都核销处理成功后，根据这个当前位置信息确定这些不同品类的业务对象分别对应的配送地址信息，无需用户手动修改这些业务对象的配送地址信息，可自动实现统一的配送地址信息，效率较高，且符合用户的实际需求，可提升用户的使用体验。

例如，业务套餐对象为包含门店餐品券、酒店客房券、按摩服务券的商品套餐券，用户订购该商品套餐券，用于在酒店休息的同时可享受到外卖和按摩服务。此种场景下用户可直接前往酒店，由酒店商家对该商品套餐券进行核销，在向服务器发送的核销请求指令中还可携带有所在终端的当前位置信息，使得外卖的配送地址和按摩服务的上门地址都自动设定为酒店的地址，这样无需用户再重新设置相应的地址，可节省用户的时间，进而提升用户的使用体验。

205、接收服务器发送的核销处理结果信息。

步骤205具体可包括：接收服务器发送的核销处理成功信息，核销处理成功信息是服务器在对不同品类的业务对象都核销处理成功时发送的；或接收服务器发送的核销处理失败信息，核销处理失败信息是服务器未查询到与套餐标识信息对应的业务套餐对象、或业务套餐对象中存在至少一个业务对象核销处理失败时发送的。通过这种方式可准确向客户端发送相应的核销处理结果信息，避免发送错误的核销处理结果信息。

为了使得用户及时了解是否核销成功，可将接收到的核销处理结果信息进行输出。输出形式可以文字、图片、音频、视频、灯光、振动等形式输出。

206、若接收到服务器发送的核销处理失败信息，则确定业务套餐对象是否已过期失效。

对于本实施例，在核销处理失败时可查询业务套餐对象的可使用时间范围，如果当前时间已经超出这个可使用时间范围，那么可确定该业务套餐对象已过期失效。

207、若确定业务套餐对象已过期失效，则查询与业务套餐对象对应的相似业务套餐对象信息，并将相似业务套餐对象信息和与相似业务套餐对象信息对应的获取渠道信息进行推荐输出。

其中，业务套餐对象信息中可包含业务套餐对象包含的各个业务对象内容信息、该业务套餐对象的可使用时间范围、使用条件等。相似业务套餐对象信息为与业务套餐对象内容相似的其它业务套餐对象的内容信息，例如，与业务套餐对象中包含的各个业务对象相似，或者只有少数个别业务对象不同而其它业务对象完全相同等。获取渠道信息可包含获取相似业务套餐对象的渠道有哪些。

例如，用户订购的业务套餐对象A为包含门店a餐品券和酒店b客房券的商品套餐券，由于当前时间已经超出业务套餐对象A的可使用时间范围，说明业务套餐对象A已过期失效，这时可通过服务器查询与业务套餐对象A对应的相似业务套餐对象，如果存在业务套餐对象B，其包含门店c餐品券和酒店b客房券、且门店c与门店a属于同一家连锁餐饮门店，以及业务套餐对象B当前还可订购获取且在可使用时间范围内，那么可将业务套餐对象B的相关信息以及业务套餐对象B的获取渠道进行输出，以便为用户提供更多的选择，既能满足用户的需求，又不会影响用户过多的计划。

需要说明的是，除了上述在判定业务套餐对象已过期失效时，执行相似业务套餐对象推荐的方式以外，还可在确定业务套餐对象并没有过期失效但是不在该业务套餐对象的可使用时间范围内时触发推荐相似业务套餐对象，以满足更多的业务需求。

为了说明上述实施例的具体实施过程，给出如下应用场景，但不限于此：

目前，用户对午餐和午休的需求，按照以往的方式需要让用户自行去购买午餐、订购钟点房等。在筛选信息、操作上又要花大量时间，用户觉得麻烦；消费时，吃完饭再步行去钟点房，又耗费时间，中午本来也没多少时间。这样以来，往往放弃了午休。很多类似的跨行业绑定的需求就会被扼杀掉。为了解决这一问题，在以往的独立、单个商品的基础上，再建立一个虚拟的套餐商品(相当于业务套餐对象)，套餐商品包含几个独立商品(相当于业务对象)，该套餐商品的商品信息结构如表1所示。

商品ID	商品名称	详细信息	类型
				1	汉堡20元套餐		独立商品
2	钟点房2小时		独立商品
				3	午餐午休	包含商品1和2	绑定消费套餐

表1

其中，独立的商品有库存，而绑定消费的套餐实际没有库存，页面上展示的套餐商品库存为包含的这些独立商品的剩余库存中的最小值。独立的商品有价格，而绑定消费的套餐实际没有价格，页面上展示的套餐商品价格为这些独立商品的价格总和。具体架构如图3所示。

这样商品套餐建立完毕后，可供用户选择购买。商品套餐的购买分三步，如图4所示，具体可分为库存扣减、支付打款、凭证发放。其中，库存扣减和支付打款跟以往商品有所不同，而凭证发放是直接发放商品套餐对应的虚拟商品，而不是商品套餐中的多个商品。

对于库存扣减的过程，商品套餐中含有多个独立商品，需要同时对几个商品进行库存扣减，如果其中一个失败，所有商品扣减都会补回去。对于支付打款的过程，如图5所示，首先可通过查询商品套餐内商品列表将商品套餐内包含的商品都查询得到，再逐个查询每个商品的最优价格，然后将最优价格之和展示给用户，引导用户支付，最后用户支付成功后，资金将进入中间账户，给用户展示成功，并落地订单，订单中详细记录支付时候分配到每个商品的最优价格。对于凭证发放的过程，如图6所示，在支付成功后可发放商品套餐对应的凭证(如商品券二维码等)，其对应的是商品套餐虚拟商品，而不是商品套餐中的多个商品。

在用户利用发放的凭证使用该商品套餐时，可出示该凭证，由商家进行支付核销。核销的过程中与以往商品核销有几点不同：1、商品套餐包含的几个商品都要核销掉。无论是用户在吃饭的地方还是在休息的地方，出示的核销二维码是虚拟套餐的二维码，因此，就一次性核销掉。2、商品套餐中的商品对应的商户可能是不同的商户，资金流跟现在的单一商户不同。在查询到商品套餐中每个商品当时的支付价格、收款账户后，从中间账户打对应的金额到对应收款账户。其具体流程可如图7所示，首先根据商品套餐二维码查询出对应的虚拟套餐，再执行凭证核销，然后查询到对应订单里面的各个商品的价格(当时支付分配到每个商品的价格)，然后再查询每个商品的收款账户，最后按照查询到的各个商品的价格从中间账户打款到每个收款账户中。

例如，商品1：餐饮门店套餐是24元，商品2：快捷酒店钟点房6元/小时；商品套餐A：商品1+商品2(中午12:00-1:00)。如果当天对于商品2，钟点房搞促销5元/小时，用户可最终以24+5＝29元的价格购得商品套餐A，进而可通过核销商品套餐A，在快捷酒店钟点房用餐和休息。

如果用户需要在该商品套餐未使用前进行退款，该商品套餐的退款流程是按照之前商品套餐的支付价格从中间账户退回到个人账户中。

上述过程的整体流程可如图8所示，即从新建商品套餐到用户购买，再到商品套餐中的各个商品同时核销或同时退款。通过这种方式可实现一次消费能够同时解决午餐和午休场所的问题，进而这家餐厅被用户选择的概率会大一些。对餐饮商家来说，可以提高点餐率，并且解决用餐受场地限制问题(餐可以配送到午休场地，吃完就睡)；对于酒店来说，减少了中午钟点房的空置率，导流；对于个人来说，直接去酒店用餐，吃完后可以直接休息，节约了时间。与目前现有技术(如用户在餐厅用餐，用户酒店午休，分开消费，互不相干，即一个商户下多个商品绑定购买，分开一次次消费，一次次核销，多个商品必然是同一个行业的)相比，本方案可绑定消费，用餐后去酒店午休，或者直接在酒店用餐后午休，进而可支持多个商户、多个行业下，不同的商品，同时购买，同时核销，打破行业限制实现相关联商品的购买消费。

需要说明的是，上述可应用于客户端侧的业务信息的处理方法，是在客户端侧描述具体的业务信息的处理过程，而为了完整说明本实施例的具体实施方式，提供了另一种可应用于服务器侧的业务信息的处理方法，以便说明在服务器侧的业务信息处理过程，如图9所示，该方法包括：

301、服务器接收客户端发送的核销请求指令。

其中，核销请求指令中携带有业务套餐对象对应的套餐标识信息。

对于本实施例的执行主体可为用于业务信息处理的服务器设备，按照客户端发送的对业务套餐对象的核销请求指令，对业务套餐对象进行核销处理，具体可执行步骤302至304所示过程。

302、查询与套餐标识信息对应的业务套餐对象。

例如，利用业务套餐对象的编号，可查询到该业务套餐对象。

303、获取业务套餐对象中包含的不同品类的业务对象。

具体可查询业务套餐对象的套餐列表，从该套餐列表中获取这些不同品类的业务对象。

304、分别对不同品类的业务对象进行核销处理。

在具体的核销处理过程中，在获取到业务套餐对象包含的这些业务对象后，可通过业务套餐对象查询到这些业务对象各自对应的核销凭证，进而可凭借这些业务对象各自对应的核销凭证，分别对这些业务对象进行核销。

305、向客户端发送核销处理结果信息。

根据对这些不同品类的业务对象的核销处理结果，生成对业务套餐对象的核销处理结果信息并发送给客户端进行输出。通过这种方式，与目前现有技术相比，本实施例可实现业务套餐对象中包含的不同品类的业务对象的一次性核销，进而可使得用户一次性获得不同品类的业务对象的服务，满足了用户的多元化需求，并且无需用户对这些不同品类的业务对象分别进行订购获取，节省了用户的时间，可以提升用户的体验。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了说明步骤304具体的实施过程，作为一种可选方式，该步骤具体可包括：获取不同品类的业务对象分别对应的使用状态和有效时间范围；若不同品类的业务对象的使用状态都为未使用状态、且当前核销处理时间分别处于不同品类的业务对象的有效时间范围内，则分别对不同品类的业务对象进行核销处理；若不同品类的业务对象中存在至少一个业务对象的使用状态为已使用状态、或当前核销处理时间处于不同品类的业务对象中至少一个业务对象的有效时间范围外，则取消对不同品类的业务对象进行核销处理。

例如，业务套餐对象为包含门店餐品券、酒店客房券的商品套餐券。在对该商品套餐券进行核销时，如果门店餐品券和酒店客房券都处于未使用状态、且当前核销处理时间分别处于这两个商品券的有效使用时间范围内，那么可对这两个商品券进行核销，进而实现该商品套餐券的核销。如果门店餐品券已经超出该商品的有效时间范围，或者酒店客房券已经超出该商品的有效时间范围，那么可取消进行下一步的核销处理操作，以减少执行无效的核销操作，可以节省系统资源。

对于本实施例，为了事先创建更加贴近大多数用户需求的业务套餐对象，进一步的，作为一种可选方式，在步骤301之前，本实施例还可包括：统计样本用户在同一时间段内对不同品类的样本业务对象的获取需求信息；从不同品类的样本业务对象中获取该获取需求信息所占比重大于预设阈值的各个目标样本业务对象；然后分析不同品类的目标样本业务对象之间的关联关系；再然后根据关联关系符合预设搭配标准条件的不同品类的目标样本业务对象，生成可选业务套餐对象；最后将可选业务套餐对象作为推荐信息发送给不同的客户端。

其中，样本用户的选取可根据实际需求进行确定，例如选择某一区域范围的用户作为样本用户，或者选择某一职业、年龄段等的用户作为样本用户等。样本业务对象可根据商家实际需求创建，也可由目前商家已上线的各个业务对象作为样本来确定。获取需求信息中可包含样本用户对样本业务对象的获取需求程度情况。预设阈值可根据实际需要预先设置，例如具体可为80％、90％等。预设搭配标准条件根据可搭配在一起推荐的业务标准进行设置。例如，商品A和商品B在一起搭配时，用户同时消费的可能性很大，那么商品A和商品B搭配就可确定为符合预设搭配标准条件。

例如，在周五下班的时间段，统计得到60％以上的样本用户对餐饮门店的餐品、唱歌房KTV、打车业务、看电影等的需求较多，查询这些需求对应的商品券，然后从这些商品券中获取在同一服务区域范围内的目标商品券，然后分析这些目标商品券之间的关联关系，找到可搭配在一起进行推荐的目标商品券，如餐饮门店餐品的目标商品券可与唱歌房KTV的目标商品券搭配在一起，这样用户就可在唱歌房KTV内唱歌的同时还能享受到该餐饮门店的餐品外卖服务；再如唱歌房KTV的目标商品券不可与看电影的目标商品券搭配在一起，因为这两种服务的场景无法有效结合。在找到可搭配在一起的目标商品券后，可将这些目标商品券进行组合生成商品套餐券，并发送给不同的客户端进行推荐，用户可根据推荐做出选择。通过这种方式可得到更加贴近大多数用户需求的业务套餐对象，且可实现自动向用户推荐合适的业务套餐对象。

可选的，推荐信息还可包含根据可选业务套餐对象中各个业务对象实时的最优获取方式信息，确定得到的可选业务套餐对象实时的最优获取方式信息。其中，最优获取方式信息中可包含获取业务对象的最优获取方式情况。例如，从哪个渠道可以最低的价格获取得到相应的商品券，然后将各个商品券的这些最低价格之和作为商品套餐券的最优价格进行推荐，使得用户可按照这个最优价格进行支付，后台可根据相应的最优渠道以最低价格获取到商品券进行组合，生成该商品套餐券的凭证，以供用户使用。

在用户具体获取业务套餐对象的过程中，为了保证获取有效的业务套餐对象，进一步的，作为一种可选方式，本实施例还可包括：当接收到客户端发送的业务套餐对象的获取请求指令时，查询业务套餐对象包含的不同品类的业务对象的库存信息和相应的获取条件信息；然后根据库存信息和获取条件信息确定客户端所对应的用户是否具备获取业务套餐对象的获取资格；若具备，则生成业务套餐对象对应的核销凭证码并发送给客户端。

业务套餐对象包含的这些业务对象的库存充足，且客户端所对应用户具备获取这些业务对象的获取条件，那么可确定该用户具备获取该业务套餐对象的获取资格。如果这些业务对象中存在库存不足的业务对象，那么将不会生成业务套餐对象对应的核销凭证码。通过这种方式可保证用户获取到有效的业务套餐对象。

可选的，获取请求指令中还可携带有支付信息。上述确定客户端所对应的用户是否具备获取业务套餐对象的获取资格的步骤具体可以包括：若不同品类的业务对象的库存充足、且支付信息与不同品类的业务对象的获取条件信息匹配，则确定客户端所对应的用户具备获取业务套餐对象的获取资格；若不同品类的业务对象中存在至少一个业务对象的库存不足、或支付信息与获取条件信息不匹配，则确定客户端所对应的用户不具备获取业务套餐对象的获取资格。

支付信息可包括支付用户信息、支付金额、支付方式、支付时间等信息内容。例如，根据支付用户信息确定该用户是否具备获取各个业务对象的获取权限，以及根据支付方式确定支付手段是否合规，以及根据支付金额确定是否可订购获取该业务套餐对象，以及根据支付时间确定支付的时间点是否处于该业务套餐对象可订购的时间段内；如果该用户具备获取各个业务对象的获取权限、且支付手段合规、且支付金额对应该业务套餐的价格、且支付的时间点处于该业务套餐对象可订购的时间段内，则可确定支付信息与不同品类的业务对象的获取条件信息匹配，若此时这些业务对象库存都充足，那么可确定该用户具备获取业务套餐对象的获取资格；如果该用户不具备获取各个业务对象的获取权限、或支付手段不合规、或支付金额不对应该业务套餐的价格、或支付的时间点处于该业务套餐对象可订购的时间段外，则可确定支付信息与不同品类的业务对象的获取条件信息不匹配，进而可确定该用户不具备获取业务套餐对象的获取资格。

通过上述这种方式可进一步保证用户获取到有效的业务套餐对象，可满足多种业务需求。

如果用户直接向业务对象对应的商家端支付，会存在一定的安全风险，为了解决这一问题，作为一种可选方式，若客户端所对应的用户具备获取业务套餐对象的获取资格，则本实施例还可包括：将支付信息发送给中间账户服务器，以便在确定业务套餐对象被核销处理成功后，由中间账户服务器向不同品类的业务对象分别对应的账户服务器分配支付信息。通过这种中间账户转账的方式，避免用户的支付信息直接落入到业务对象对应的商家端侧，保证了用户的资金安全。

通过上述中间账户的方式，后续在业务套餐对象未核销的情况下如果存在退款行为，也可以由中间账户代替业务对象对应的商家端进行退款，过程简化，可以提高退款效率。为了实现这一过程，作为一种可选方式，本实施例还可包括：当接收到客户端发送的业务套餐对象的退回请求指令时，将生成的业务套餐对象对应的核销凭证码进行无效标记，并向中间账户服务器发送支付信息退回指令，以便将中间账户服务器返回的支付信息退回给客户端。利用这种方式不但不会影响商家端运营，并且将生成的业务套餐对象对应的核销凭证码进行无效标记，可保证后续不会对实际无效的业务套餐对象进行核销，避免系统出错。

为了说明步骤305具体的实施过程，作为一种可选方式，该过程具体可包括：若对不同品类的业务对象都核销处理成功，则向客户端发送核销处理成功信息；若未查询到与套餐标识信息对应的业务套餐对象、或业务套餐对象中存在至少一个业务对象核销处理失败，则向客户端发送核销处理失败信息。通过这种方式可准确向客户端发送相应的核销处理结果信息，避免发送错误的核销处理结果信息。

在具体的应用场景中，由于业务套餐对象的这些业务对象，的品类不同，相应的配送地址信息往往不统一，而用户有时需要在特定的地点接收这些业务对象提供的服务，进而需要手动修改这些业务对象的配送地址，效率低下，从而影响用户的使用体验。为了解决这一问题，作为一种可选方式，核销请求指令中还可携带有客户端所在终端的当前位置信息；在对不同品类的业务对象都核销处理成功之后，本实施例还可包括：根据当前位置信息确定不同品类的业务对象分别对应的配送地址信息。无需用户手动修改这些业务对象的配送地址信息，可自动实现统一的配送地址信息，效率较高，且符合用户的实际需求。

可选的，确定配送地址信息的步骤具体可包括：获取不同品类的业务对象分别对应的提供方地址信息；将当前位置信息与提供方地址信息进行匹配；若存在匹配的提供方地址信息，则将匹配的提供方地址信息确定为不同品类的业务对象分别对应的配送地址信息。

例如，业务套餐对象为包含餐饮门店餐品券、唱歌房KTV券的商品套餐券，用户订购该商品套餐券，用于在KTV唱歌的同时可享受到该餐饮门店的外卖服务。此种场景下用户可直接前往唱歌房KTV，由唱歌房KTV商家对该商品套餐券进行核销，在核销的过程中可查询该餐饮门店的地址信息、以及该唱歌房KTV的地址信息，如果用户当前的位置信息与该唱歌房KTV的地址信息匹配，那么可将唱歌房KTV的地址信息自动确定为该餐饮门店的外卖服务的配送地址，通过这种方式，无需用户再重新设置相应的外卖配送地址，可节省用户的时间，进而提升用户的使用体验。

通过应用本实施例提供的方法，可以跨商户、行业去绑定商品，打破目前只能一个门店内商品一起购买的壁垒。本实施例采用虚拟套餐商品的方式，一次消费就可以核销掉多个商品，对于强相关的(同时消费可能性很大)的商品，更方便(无需用户跑多个地方分别核销)。

进一步的，作为图1和图2所示方法的具体实现，本申请实施例提供了一种可应用于客户端侧的业务信息的处理装置，如图10所示，该装置包括：接收单元41、发送单元42。

接收单元41，可用于接收对业务套餐对象的核销指令，业务套餐对象中包含不同品类的业务对象；

发送单元42，可用于向服务器发送携带有业务套餐对象对应套餐标识信息的核销请求指令。

进一步的，以使得服务器在查询到与套餐标识信息对应的业务套餐对象后，对业务套餐对象中包含的不同品类的业务对象分别进行核销处理。

接收单元41，还可用于接收服务器发送的核销处理结果信息。

在具体的应用场景中，发送单元42，还可用于当接收到获取业务套餐对象的指令时，向服务器发送业务套餐对象的获取请求指令，以使得服务器查询业务套餐对象包含的不同品类的业务对象的库存信息和相应的获取条件信息；

接收单元41，还可用于接收服务器发送的业务套餐对象对应的核销凭证码，核销凭证码是服务器根据库存信息和获取条件信息确定需要获取业务套餐对象的用户具备获取资格时返回的。

在具体的应用场景中，接收单元41，具体可用于当检测到存在核销凭证码的特征信息时，对核销凭证码进行扫码识别，得到业务套餐对象对应的套餐标识信息。

在具体的应用场景中，接收单元41，具体还可用于接收服务器发送的核销处理成功信息，核销处理成功信息是服务器在对不同品类的业务对象都核销处理成功时发送的；或接收服务器发送的核销处理失败信息，核销处理失败信息是服务器未查询到与套餐标识信息对应的业务套餐对象、或业务套餐对象中存在至少一个业务对象核销处理失败时发送的。

在具体的应用场景中，如图11所示，本装置还可包括：查询单元43和输出单元44；

查询单元43，可用于若接收到服务器发送的核销处理失败信息，则在确定业务套餐对象已过期失效时，查询与业务套餐对象对应的相似业务套餐对象信息；

输出单元44，可用于将相似业务套餐对象信息和与相似业务套餐对象信息对应的获取渠道信息进行推荐输出。

在具体的应用场景中，核销请求指令中还携带有所在终端的当前位置信息，进而使得服务器在对不同品类的业务对象都核销处理成功后，根据当前位置信息确定不同品类的业务对象分别对应的配送地址信息。

在具体的应用场景中，输出单元44，还可用于将核销处理结果信息进行输出。

需要说明的是，本实施例提供的一种可应用于客户端侧的业务信息的处理装置所涉及各功能单元的其它相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

通过应用上述可应用于客户端侧的业务信息的处理装置，可实现业务套餐对象中包含的不同品类的业务对象的一次性核销，进而可使得用户一次性获得不同品类的业务对象的服务，满足了用户的多元化需求，并且无需用户对这些不同品类的业务对象分别进行订购获取，节省了用户的时间，可以提升用户的体验。

进一步的，作为图9方法的具体实现，本申请实施例提供了一种可应用于服务器侧的业务信息的处理装置，如图12所示，该装置包括：接收单元51、查询单元52、获取单元53、处理单元54、发送单元55。

接收单元51，可用于接收客户端发送的核销请求指令，核销请求指令中携带有业务套餐对象对应的套餐标识信息；

查询单元52，可用于查询与套餐标识信息对应的业务套餐对象；

获取单元53，可用于获取业务套餐对象中包含的不同品类的业务对象；

处理单元54，可用于分别对不同品类的业务对象进行核销处理；

发送单元55，可用于向客户端发送核销处理结果信息。

在具体的应用场景中，处理单元54，具体可用于获取不同品类的业务对象分别对应的使用状态和有效时间范围；若不同品类的业务对象的使用状态都为未使用状态、且当前核销处理时间分别处于不同品类的业务对象的有效时间范围内，则分别对不同品类的业务对象进行核销处理；若不同品类的业务对象中存在至少一个业务对象的使用状态为已使用状态、或当前核销处理时间处于不同品类的业务对象中至少一个业务对象的有效时间范围外，则取消对不同品类的业务对象进行核销处理。

在具体的应用场景中，如图13所示，本装置还可包括：统计单元56、分析单元57、生成单元58；

统计单元56，可用于统计样本用户在同一时间段内对不同品类的样本业务对象的获取需求信息；

获取单元53，还可用于从不同品类的样本业务对象中获取获取需求信息所占比重大于预设阈值的各个目标样本业务对象；

分析单元57，可用于分析不同品类的目标样本业务对象之间的关联关系；

生成单元58，可用于根据关联关系符合预设搭配标准条件的不同品类的目标样本业务对象，生成可选业务套餐对象；

发送单元55，还可用于将可选业务套餐对象作为推荐信息发送给不同的客户端。

在具体的应用场景中，推荐信息还包含根据可选业务套餐对象中各个业务对象实时的最优获取方式信息，确定得到的可选业务套餐对象实时的最优获取方式信息。

在具体的应用场景中，如图13所示，本装置还可包括：确定单元59；

查询单元52，还可用于当接收到客户端发送的业务套餐对象的获取请求指令时，查询业务套餐对象包含的不同品类的业务对象的库存信息和相应的获取条件信息；

确定单元59，可用于根据库存信息和获取条件信息确定客户端所对应的用户是否具备获取业务套餐对象的获取资格；

生成单元58，可用于若客户端具备获取业务套餐对象的获取资格，则生成业务套餐对象对应的核销凭证码并发送给客户端。

在具体的应用场景中，获取请求指令中携带有支付信息；相应的，确定单元59，具体可用于若不同品类的业务对象的库存充足、且支付信息与不同品类的业务对象的获取条件信息匹配，则确定客户端所对应的用户具备获取业务套餐对象的获取资格；若不同品类的业务对象中存在至少一个业务对象的库存不足、或支付信息与获取条件信息不匹配，则确定客户端所对应的用户不具备获取业务套餐对象的获取资格。

在具体的应用场景中，发送单元55，还可用于若客户端所对应的用户具备获取业务套餐对象的获取资格，则将支付信息发送给中间账户服务器，以便在确定业务套餐对象被核销处理成功后，由中间账户服务器向不同品类的业务对象分别对应的账户服务器分配支付信息。

在具体的应用场景中，发送单元55，还可用于当接收到客户端发送的业务套餐对象的退回请求指令时，将生成的业务套餐对象对应的核销凭证码进行无效标记，并向中间账户服务器发送支付信息退回指令，以便将中间账户服务器返回的支付信息退回给客户端。

在具体的应用场景中，发送单元55，具体还用于若对不同品类的业务对象都核销处理成功，则向客户端发送核销处理成功信息；若未查询到与套餐标识信息对应的业务套餐对象、或业务套餐对象中存在至少一个业务对象核销处理失败，则向客户端发送核销处理失败信息。

在具体的应用场景中，核销请求指令中还携带有客户端所在终端的当前位置信息，相应的，确定单元59，还可用于根据当前位置信息确定不同品类的业务对象分别对应的配送地址信息。

在具体的应用场景中，确定单元59，具体还可用于获取不同品类的业务对象分别对应的提供方地址信息；将当前位置信息与提供方地址信息进行匹配；若存在匹配的提供方地址信息，则将匹配的提供方地址信息确定为不同品类的业务对象分别对应的配送地址信息。

需要说明的是，本申请实施例提供的一种可应用于服务器侧的业务信息的处理装置所涉及各功能单元的其他相应描述，可以参考图9中的对应描述，在此不再赘述。

基于上述如图1和图2所示方法，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的业务信息的处理方法。基于上述如图9所示方法，本申请实施例还提供了另一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图9所示的业务信息的处理方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景的订餐信息的处理方法。

基于上述如图1和图2所示的方法，以及图10至图11所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种终端设备，具体可以为个人计算机、平板电脑、智能手机、智能手表、POS设备或其他网络设备等，该终端设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图2所示的业务信息的处理方法。

基于上述如图9所示的方法，以及图12至图13所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种服务器设备，具体可以为个人计算机、服务器、网络设备等，该服务器设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图9所示的业务信息的处理方法。

可选的，上述两种实体设备都还可以包括用户接口、网络接口、摄像头、射频(Radio Frequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种终端设备和服务器设备的实体设备结构并不构成对这两种实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述两个实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

基于上述内容，进一步的，本申请实施例结合，还提供了一种业务信息的处理系统，如图14所示，该系统包括终端设备61和服务器设备62；

其中，终端设备61可用于执行如图1和图2所示的方法，服务器设备62可用于执行如图9所示的方法。

具体的，在用户输入业务套餐对象的核销指令后，终端设备51可接收对业务套餐对象的核销指令，其中该业务套餐对象中包含不同品类的业务对象，然后向服务器设备62发送携带有该业务套餐对象对应套餐标识信息的核销请求指令。

服务器设备62在接收到终端设备61发送的核销请求指令后，可查询与该套餐标识信息对应的业务套餐对象；然后获取该业务套餐对象中包含的不同品类的业务对象；再然后分别对不同品类的业务对象进行核销处理；最后向终端设备61发送核销处理结果信息。

终端设备61在接收到服务器设备62发送的核销处理结果信息之后可进行输出。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本申请的技术方案，与目前现有技术相比，本实施例可实现业务套餐对象中包含的不同品类的业务对象的一次性核销，进而可使得用户一次性获得不同品类的业务对象的服务，满足了用户的多元化需求。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种业务信息的处理方法，其特征在于，包括：

接收对业务套餐对象的核销指令，所述业务套餐对象中包含不同品类的业务对象；

向所述服务器发送携带有所述业务套餐对象对应套餐标识信息的核销请求指令，以使得所述服务器在查询到与所述套餐标识信息对应的所述业务套餐对象后，对所述业务套餐对象中包含的所述不同品类的业务对象分别进行核销处理；

接收所述服务器发送的核销处理结果信息。

2.根据权利要求1所述的方法，其特征在于，在所述接收对业务套餐对象的核销指令之前，所述方法还包括：

当接收到获取所述业务套餐对象的指令时，向所述服务器发送所述业务套餐对象的获取请求指令，以使得所述服务器查询所述业务套餐对象包含的所述不同品类的业务对象的库存信息和相应的获取条件信息；

接收所述服务器发送的所述业务套餐对象对应的核销凭证码，所述核销凭证码是所述服务器根据所述库存信息和所述获取条件信息确定需要获取所述业务套餐对象的用户具备获取资格时返回的。

3.一种业务信息的处理方法，其特征在于，包括：

接收客户端发送的核销请求指令，所述核销请求指令中携带有业务套餐对象对应的套餐标识信息；

查询与所述套餐标识信息对应的所述业务套餐对象；

获取所述业务套餐对象中包含的不同品类的业务对象；

分别对所述不同品类的业务对象进行核销处理；

向所述客户端发送核销处理结果信息。

4.一种业务信息的处理装置，其特征在于，包括：

接收单元，用于接收对业务套餐对象的核销指令，所述业务套餐对象中包含不同品类的业务对象；

发送单元，用于向所述服务器发送携带有所述业务套餐对象对应套餐标识信息的核销请求指令，以使得所述服务器在查询到与所述套餐标识信息对应的所述业务套餐对象后，对所述业务套餐对象中包含的所述不同品类的业务对象分别进行核销处理；

所述接收单元，还用于接收所述服务器发送的核销处理结果信息。

5.一种业务信息的处理装置，其特征在于，包括：

接收单元，用于接收客户端发送的核销请求指令，所述核销请求指令中携带有业务套餐对象对应的套餐标识信息；

查询单元，用于查询与所述套餐标识信息对应的所述业务套餐对象；

获取单元，用于获取所述业务套餐对象中包含的不同品类的业务对象；

处理单元，用于分别对所述不同品类的业务对象进行核销处理；

发送单元，用于向所述客户端发送核销处理结果信息。

6.一种存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1至2中任一项所述的业务信息的处理方法。

7.一种终端设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至2中任一项所述的业务信息的处理方法。

8.一种存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求3所述的业务信息的处理方法。

9.一种服务器设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求3所述的业务信息的处理方法。

10.一种业务信息的处理系统，其特征在于，包括：如权利要求7所述的终端设备和如权利要求9所述的服务器设备。