业务实现方法及装置与流程

本申请涉及业务实现技术领域，尤其涉及一种业务实现方法及装置。

背景技术：

随着网络技术的发展，出现了多种多样的业务实现方式。以“红包”形式的虚拟物品交互为例，用户可以将电子贺卡、礼金等放入“红包”中，然后单独发放至某个用户，或者发放至群组内，由群组内的所有成员进行领取。

技术实现要素：

有鉴于此，本申请提供一种业务实现方法及装置，可以优化对业务对象的分配过程。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种业务实现方法，包括：

第一用户通过第一客户端收集用于提取业务对象的电子凭证；

第一客户端判断收集到的电子凭证的类别数是否达到第一数量；

当收集到的电子凭证的类别数达到第一数量时，向服务端发起包含若干电子凭证并且包含的电子凭证的类别数为第一数量的对象分配请求，以使得所述服务端基于该对象分配请求从业务对象集合中为所述第一用户分配业务对象。

可选的，所述获取用于提取业务对象的电子凭证，包括：

获取服务端为所述第一客户端下发的电子凭证；以及

获取第二用户通过第二客户端分享的电子凭证。

可选的，所述第一客户端提供用于获取电子凭证的触发选项；

所述获取服务端为所述第一客户端下发的电子凭证，包括：

当检测到所述第一用户针对所述触发选项的触发操作时，向所述服务端发起用于获取所述电子凭证的请求，以使得所述服务端基于预设下发规则向所述第一客户端下发电子凭证；

获取所述服务端基于所述预设下发规则为所述第一客户端下发的电子凭证；其中，所述服务端为所述第一客户端下发的电子凭证的类别数小于所述第一数量。

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

当收集到电子凭证时，为该电子凭证生成对应的展示图片；

将生成的展示图片添加至与所述电子凭证对应的展示位置；

其中，不同种类的电子凭证生成的展示图片互不相同；不同种类的电子凭证对应的展示位置互不相同。

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

在所述展示位置上标注获取到的所述电子凭证的数量；

基于该电子凭证的实际剩余数量对该数量进行更新。

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

当检测到第一用户针对任一展示图片的预设触发操作时，将与该展示图片对应的电子凭证分享至由第一用户选定的目标用户。

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

当所述服务端为所述第一用户分配完成业务对象时，接收所述服务端发送的分配结果，并将所述分配结果向所述第一用户展示；

其中，所述分配结果包括以下信息中的一个或者多个：

所述业务对象的数量、所述业务对象的发送方、所述业务对象的其它接收方的数量以及所述业务对象的分配规则。

根据本申请的第二方面，提出一种业务实现方法，包括：

接收第一用户通过第一客户端发送的对象分配请求；所述对象分配请求 中包含用于提取业务对象的若干电子凭证；

判断所述对象分配请求中包含的电子凭证的类别数是否达到第一数量；

当所述对象分配请求中包含的电子凭证的类别数达到第一数量，基于预设分配规则从业务对象集合中为所述第一用户分配业务对象。

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

当接收到所述第一客户端发送的用于获取所述电子凭证的请求时，基于预设下发规则从本地存储的电子凭证中向所述第一客户端下发电子凭证；

其中，为所述第一客户端下发的电子凭证的类别数小于所述第一数量。

可选的，所述基于预设下发规则向所述第一客户端下发电子凭证，包括

从本地存储的电子凭证中随机向所述第一客户端下发电子凭证。

可选的，所述本地存储的电子凭证至少被预先划分为低频下发集合和高频下发集合；

所述基于预设下发规则向所述第一客户端下发电子凭证，包括

计算所述第一用户的活跃度；

判断所述活跃度是否达到预设阈值；

当所述活跃度达到预设阈值时，从所述低频下发集合中向所述第一客户端下发电子凭证；或者，

从所述低频下发集合和高频下发集合中向所述第一下发电子凭证；其中，下发的电子凭证中包括至少一个低频下发集合中的电子凭证。

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

当为所述第一用户分配完成业务对象时，向所述第一客户端发送分配结果，以使所述第一客户端将所述分配结果向所述第一用户展示；

其中，所述分配结果包括以下信息中的一个或者多个：

所述业务对象的数量、所述业务对象的发送方、所述业务对象的其它接收方的数量以及所述业务对象的分配规则。

根据本申请的第三方面，提出一种业务实现装置，包括：

获取模块，用于获取用于提取业务对象的电子凭证；

第一判断模块，用于判断获取到的电子凭证的类别数是否达到第一数量；

发起模块，用于获取到的电子凭证的类别数达到第一数量时，向服务端发起包含若干电子凭证并且包含的电子凭证的类别数为第一数量的对象分配请求，以使得所述服务端基于该对象分配请求从业务对象集合中为所述第一用户分配业务对象。

可选的，所述获取模块具体用于：

获取服务端为所述第一客户端下发的电子凭证；以及

获取第二用户通过第二客户端分享的电子凭证。

可选的，所述第一客户端提供用于获取电子凭证的触发选项；

所述获取模块进一步用于：

当检测到所述第一用户针对所述触发选项的触发操作时，向所述服务端发起用于获取所述电子凭证的请求，以使得所述服务端基于预设下发规则向所述第一客户端下发电子凭证；

获取所述服务端基于所述预设下发规则为所述第一客户端下发的电子凭证；其中，所述服务端为所述第一客户端下发的电子凭证的类别数小于所述第一数量。

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

生成模块，用于在获取到电子凭证时，为该电子凭证生成对应的展示图片；

展示模块，用于将生成的展示图片添加至与所述电子凭证对应的展示位置；其中，不同种类的电子凭证生成的展示图片互不相同；不同种类的电子凭证对应的展示位置互不相同。

可选的，所述生成模块进一步用于：

在所述展示位置上标注获取到的所述电子凭证的数量；

基于该电子凭证的实际剩余数量对该数量进行更新。

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

分享模块，用于在检测到第一用户针对任一展示位置中添加的展示图片 的预设触发操作时，将与该展示图片对应的电子凭证分享至由第一用户选定的目标用户。

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

第一接收模块，用于在所述服务端为所述第一用户分配完成业务对象时，接收所述服务端发送的分配结果，并将所述分配结果向所述第一用户展示；

其中，所述分配结果包括以下信息中的一个或者多个：

所述业务对象的数量、所述业务对象的发送方、所述业务对象的其它接收方的数量以及所述业务对象的分配规则。

根据本申请的第四方面，提出一种业务实现装置，包括：

第二接收模块，用于接收第一用户通过第一客户端发送的对象分配请求；所述对象分配请求中包含用于提取业务对象的若干电子凭证；

第二判断模块，用于判断所述对象分配请求中包含的电子凭证的类别数是否达到第一数量；

分配模块，用于在所述对象分配请求中包含的电子凭证的类别数达到第一数量，基于预设分配规则从业务对象集合中为所述第一用户分配业务对象。

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

下发模块，用于在接收到所述第一客户端发送的用于获取所述电子凭证的请求时，基于预设下发规则从本地存储的电子凭证中向所述第一客户端下发电子凭证；

其中，为所述第一客户端下发的电子凭证的类别数小于所述第一数量。

可选的，所述下发模块具体用于：

从本地存储的电子凭证中随机向所述第一客户端下发电子凭证。

可选的，所述本地存储的电子凭证至少被预先划分为低频下发集合和高频下发集合；

所述下发模块具体用于：

计算所述第一用户的活跃度；

判断所述活跃度是否达到预设阈值；

当所述活跃度达到预设阈值时，从所述低频下发集合中向所述第一客户端下发电子凭证；或者，

从所述低频下发集合和高频下发集合中向所述第一下发电子凭证；其中，下发的电子凭证中包括至少一个低频下发集合中的电子凭证。

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

发送模块，用于在为所述第一用户分配完成业务对象时，向所述第一客户端发送分配结果，以使所述第一客户端将所述分配结果向所述第一用户展示；

其中，所述分配结果包括以下信息中的一个或者多个：

所述业务对象的数量、所述业务对象的发送方、所述业务对象的其它接收方的数量以及所述业务对象的分配规则。

由以上技术方案可见，本申请通过在对第一用户分配业务对象时，第一用户可以通过第一客户端获取用于提取业务对象的电子凭证，当获取到的电子凭证类别数达到第一数量时，第一用户可以取得业务对象的分配权限，通过第一客户端向服务端发起对象分配请求使得服务端为第一用户分配业务对象，从而可以提升业务分配过程中的趣味性，以及用户的应用体验。

附图说明

图1是根据本申请一示例性实施例中的一种业务实现方法的流程图；

图2-6是根据本申请一示例性实施例中的红包发放的界面示意图；

图7是根据本申请一示例性实施例中的一种业务实现装置的框图；

图8是根据本申请一示例性实施例中的一种电子设备的结构示意图；

图9是根据本申请一示例性实施例中的另一种业务实现装置的框图；

图10是根据本申请一示例性实施例中的一种服务端的结构示意图。

具体实施方式

图1是根据本申请一示例性实施例中的一种业务实现方法的流程图，如 图1所示，该方法应用于客户端和服务端中，客户端和服务端相互配合可以执行以下步骤：

步骤101，第一用户通过第一客户端收集用于提取业务对象的电子凭证；

步骤102，第一客户端判断收集到的电子凭证的类别数是否达到第一数量；

步骤103，当收集到的电子凭证的类别数达到第一数量时，向服务端发起包含若干电子凭证并且包含的电子凭证的类别数为第一数量的对象分配请求；

步骤104，服务端判断所述对象分配请求中包含的电子凭证的类别数是否达到第一数量；

步骤105，当所述对象分配请求中包含的电子凭证的类别数达到第一数量，基于预设分配规则从业务对象集合中为所述第一用户分配业务对象。

上述客户端，可以包括电子设备上安装的应用程序；例如，在“红包”发放的应用场景中，上述客户端可以包括电子设备上安装的提供红包发放功能的客户端软件；比如，支付宝；其中，在不同的场景下，上述客户端可以为不同的客户端软件。

上述服务端，可以包括面向客户端提供服务的服务器、服务器集群或者云平台；例如，当上述客户端为支付宝客户端时，上述服务端可以是支付宝服务平台。

上述业务对象，可以为任意形式的业务交互数据。作为一示例性实施例，上述业务对象可以包括虚拟物品，比如优惠券、电子贺卡、礼金等。针对不同的业务实现，上述虚拟物品包含的内容可以互不相同；例如，在支付业务中，上述业务对象可以是资金；在商家发起的商品活动业务时，上述业务对象可以是优惠券，等等。上述业务对象集合是指第一用户可提取的业务对象的集合；例如，当业务对象为通过红包的形式所发放的资金时，上述业务对象集合可以是与红包发放平台合作的第三方企业的红包发放账户。

上述第一用户，可以是指业务对象的提取方。上述第一客户端，可以是 指第一用户在提取业务对象时所使用的客户端。例如，当任一电子设备上安装有上述客户端，第一用户在使用注册账号登录该客户端后，可以通过该客户端与服务端进行交互来提取业务对象。

上述电子凭证，是指第一用户向服务端提取业务对象时的凭证，在实际应用中，上述电子凭证的具体形式不进行限制，可以是字符串、数字、字符、口令、虚拟卡片，等等。服务端可以对第一用户提交的电子凭证的内容、数量或者种类进行验证，来确定第一用户是否具备业务对象的提取权限，并在第一用户具备提取权限时，从业务对象集合中为第一用户分配业务对象。其中，每个电子凭证可以有对应的类别或者种类，每种类别的电子凭证可以代表一种类型的凭证，每一种类型的凭证可以具有相同或不同的内容。

在本例中，第一用户可以通过第一客户端来收集电子凭证，并在收集到的电子凭证的类别数达到第一数量时，来取得业务对象的分配权限。其中，上述类别数是指用户收集到的电子凭证的种类数，上述第一数量的具体取值在本申请中不进行限制，在实际应用中可以根据实际的需求来确定。

例如，在示出的一个例子中，上述业务对象可以是通过红包的形式发放的资金，上述电子凭证可以是虚拟卡片，上述第一数量可以为5，当第一用户收集到的虚拟卡片的类别数达到5，即当第一用户收集到5种不同种类的虚拟卡片时，则可以取得领取红包的权限。

在本例中，第一用户可以通过如下途径来收集电子凭证；

收集途径一：获取服务器下发的电子凭证。

在本例中，第一用户可以通过第一客户端获取由服务端下发的电子凭证。

在示出的一种实施方式中，在第一客户端上可以提供一个用户获取电子凭证的触发选项，用户可以通过触发该触发选项来向服务端获取电子凭证；例如，该触发选项可以是第一客户端上向用户提供的一个触发按钮，或者活动入口，等等，用户可以通过点击、双击或者长按等触发操作来触发该触发选项，向服务端获取电子凭证。

当第一客户端在后台检测到用户针对该触发选项的触发操作时，第一客 户端可以向服务端发起用于获取电子凭证的请求，服务端在收到该请求后，可以基于预设的下发规则从其本地存储的电子凭证中向第一客户端下发电子凭证。

其中，服务端在向第一客户端下发电子凭证时，可以直接将电子凭证下发至第一客户端，也可以仅向第一客户端下发一个与电子凭证对应的唯一标识，并在本地保存上述唯一标识与电子凭证的对应关系，后续可以通过该唯一标识来识别对应的电子凭证；例如，假设电子凭证为一个字符串，那么服务端可以直接将作为电子凭证的字符串下发至第一客户端，也可以为该字符串生成一个唯一对应的标识，将该标识下发至第一客户端，其具体的下发形式在本实施例中不进行特别限定。

具体实现时，为了防止电子凭证被仿冒，服务端在为用户生成电子凭证时，可以通过预设的加密算法对电子凭证进行加密；例如，以上述电子凭证为字符串为例，服务端在生成电子凭证时，可以通过预设的加密算法对生成的字符串进行加密，然后向用户下发加密的字符串，在验证用户发送的字符串时，可以通过密钥对收到的字符串进行解密，然后对解密后的字符串进行验证。通过这种方式，可以避免电子凭证被用户仿冒。

在本例中，服务端向第一客户端下发的电子凭证的类别数，可以小于上述第一数量，即服务端向第一客户端下发的电子凭证的种类小于第一数量；例如，以上述电子凭证为虚拟卡片为例，假设用户需要收集到5种不同种类的虚拟卡片才能够获得业务对象的分配权限，那么服务端在下用户主动下发虚拟卡片时，下发的虚拟卡片的类别数可以是一个小于5类的数字，比如3类。通过这种方式，可以有效的对具有业务对象分配权项的用户数量进行控制。

当然，服务端在向第一客户端下发电子凭证时，除了以上描述的第一用户可以通过触发第一客户端提供的触发选项向服务端主动获取电子凭证以外，也可以是由服务端主动下发；例如，在示出的一种实现方式中，当第一用户通过注册账号成功登录第一客户端后，服务端可以主动向该第一客户端下发 电子凭证。

另外，需要指出的是，服务端在向第一客户端下发电子凭证使所采用的下发规则，可以根据实际的业务需求进行制定。

在示出的一种实施方式中，上述下发规则可以包括随机下发。

在这种情况下，服务端在收到第一客户端发起的获取电子凭证的请求后，可以从本地存储的电子凭证中随机向第一客户端下发电子凭证。

在示出的另一种实施方式中，上述下发规则可以包括针对特定人群有选择的进行下发。

在这种情况下，服务端可以基于对本地存储的电子凭证预先划分为低频下发集合和高频下发集合。其中，低频下发集合中的电子凭证可以用于面向由服务端指定的特定用户进行下发，而高频下发集合中的电子凭证可以用于面向普通用户进行下发。

在示出的一种实现方式中，上述特定用户可以是指活跃度较高的用户。服务端在下发电子凭证时，可以优先为活跃度较高的用户下发低频下发集合中的电子凭证，而对于普通用户则可以优先下发高频下发集合中的电子凭证。

在这种情况下，当服务端在向第一用户下发电子凭证的时，可以在本地计算第一用户的活跃度，然后将计算得到的活跃度与预设阈值进行比较来确定第一用户是否为活跃用户，如果第一用户的活跃度达到预设阈值时，可以确定第一用户为活跃用户，此时可以从低频下发集合中读取下发凭证，然后下发给第一用户。

例如，在一种实现方式中，当服务端确定第一用户为活跃用户时，可以仅从低频下发集合中读取电子凭证向第一用户下发。在另一种实现方式中，当服务端确定第一用户为活跃人群时，可以同时从低频下发集合和高频下发集合读取电子凭证向第一用户下发，但此时需要保证下发的电子凭证中至少包括一个低频下发集合中的电子凭证。而对于活跃度不高的普通用户来说，服务端可以仅从高频下发集合中向该用户下发电子凭证。

通过这种方式，可以使得活跃度较高的用户可以更容易的比较“少见” 的电子凭证，从而将业务对象的获取权限向高活跃度的用户倾斜。

其中，需要指出的是，服务端在计算第一用户的活跃度时，该活跃度可以基于第一用户日常的与用户的活跃度相关的参数进行表征。例如，在实际应用中，当用户的好友数量或者发起的业务数越多，表明该用户越活跃。因此上述参数可以包括用户的好友数量以及发起的业务数等参数，服务端在计算第一用户的活跃度时，可以统计第一用户的好友数量，或者统计第一用户发起的业务数量，然后进行阈值化处理，来判定该用户是否为活跃用户。

当然，在实际应用中，表征用户活跃度的参数并不局限于以上描述的好友数量以及发起的业务数量，在实现时也使用其他可以表征用户的活跃度的参数来计算用户的活跃度。

收集途径二：收集其它用户分享的电子凭证

在本例中，第一用户可以通过第一客户端获取由第二用户通过第二客户端分享的电子凭证。其中，该第二用户可以是指相对于第一用户而言的其它用户。第二客户端可以是与第一客户端相同的客户端。第二用户在通过第二客户端向第一用户分享电子凭证时，可以通过客户端内部进行分享，也可以通过将电子凭证转发至第三方的客户端，然后分享给第一用户。

例如，在示出的一种实施方式中，以上述电子凭证为虚拟卡片为例，上述第一客户端和上述第二客户端均可以是支付宝客户端，第一客户端和第二客户端上均可以提供分享接口，第二用户可以通过自己的支付宝客户端将虚拟卡片在支付宝客户端内部分享给第一用户，也可以将虚拟卡片通过支付宝客户端提供的分享接口，以链接或者可点击的图文的形式分享至第三方的社交平台，或者即时通信软件，第一用户在收到第二用户分享的虚拟卡片后，可以通过点击链接或者图文然后跳转到支付宝客户端的界面中，来对第二用户分享的虚拟卡片进行收取。

在本例中，第一客户端在通过以上描述的两种收集途径，收集到的电子凭证时，可以为电子凭证生成对应的展示图片，并在用户界面向用户展示。

其中，在该展示图片上可以提供一收取选项；比如，当该电子凭证为虚 拟卡片时，该收取选项可以是“收取该卡片”的触发选项，当第一用户通过点击等触发操作触发该触发选项后，第一客户端可以将生成的该展示图片添加至在第一客户端的用户界面中提供的展示位置上，以向第一用户直观的展示当前获取到的电子凭证。

其中，第一客户端为电子凭证生成的展示图片可以与电子凭证的种类相对应，即不同种类的电子凭证所对应的展示图片互不相同。上述展示图片上展示的内容，不进行特别限制。同时，第一客户端在用户界面中提供的展示位置，也可以与电子凭证的种类相对应，不同的展示位置可以分别对应不同种类的电子凭证。

另外，第一客户端在将生成的展示图片添加到对应的展示位置后，还可以在该展示位置上标注当前获取到的与该展示位置对应的电子凭证的数量，例如，可以在展示位的右上角生成一个数字提醒。而且，当某一种类的电子凭证的数量发生变化后，第一客户端还可以基于当前该电子凭证的实际剩余数量对在与该电子凭证对应的展示位置上标注的数量进行更新。

在本例中，对于获取到的电子凭证，还可以由第一用户分享给其它用户。

在示出的一种实施方式中，第一用户可以通过触发展示位置中添加的展示图片，来将与该展示图片对应的电子凭证分享给其它用户。

例如，当第一用户想要对某一类电子凭证进行分享，则可以通过点击等触发操作来触发该电子凭证对应的展示位置，当展示位置触发后，可以将与该展示位置对应的展示图片显示在用户界面中。

此时，在该展示图片中可以提供一分享选项，比如当该电子凭证为虚拟卡片时，该分享选项可以是一个“送一张给朋友”的触发选项；当第一用户通过点击等预设触发操作触发该触发选项后，第一客户端可以输出一个分享方式的选择界面，在该选择界面中可以提供若干种可供第一用户选择的分享方式。此时用户可以在该选择界面中选择分享方式，然后选择本次要分享的目标用户，当选择完成后，第一客户端可以将该电子凭证发送至用户选择的目标用户。

其中，第一用户在向目标用户分享电子凭证时，如果目标用户为第一用户在第一客户端中的联系人或者好友时，第一用户可以在第一客户端内部将电子凭证分享给目标用户。在这种情况下，第一客户端可以通过服务端将需要分享的电子凭证传输至目标用户的客户端；例如，在一种方式中，第一客户端可以将需要分享的电子凭证发送至服务端，再由服务端转发至目标用户的客户端。在另一种方式中，第一用户可以向服务端发送一个通知消息，告知服务端需要分享的电子凭证的id，由服务端向目标用户重新下发对应的电子凭证。

当然，如果目标用户并非为第一用户在第一客户端中的联系人或者好友时，而是第一用户在第三方的客户端中的联系人或者好友时，第一用户也可以通过第三方的客户端将电子凭证分享给目标用户。

在这种情况下，第一客户端可以通过服务端为需要分享的电子凭证生成一个对应的访问链接，然后将生成的访问链接通过第三方的客户端分享给目标用户。例如，以上述第一客户端为支付宝客户端，上述第三方的客户端为第三方的社交平台，或者即时通信软件为例，支付宝客户端可以通过服务端为需要分享的电子凭证生成一个对应的访问链接或者可点击的图文，然后以链接或者图文的形式分享至第三方的社交平台，或者即时通信软件，目标用户在收到第一用户分享的电子凭证后，可以通过点击链接或者图文访问服务端上的电子凭证，然后跳转到支付宝客户端界面中来对该电子凭证进行收取。在本例中，第一用户通过以上描述的两种收集途径收集到电子凭证后，第一客户端可以在后台实时的判断当前收集到的电子凭证的种类是否达到第一数量，如果达到第一数量后，此时第一用户已经可以获得业务对象的分配权限，在这种情况下，第一客户端可以向服务端发起对象分配请求，并在该对象分配请求中携带若干电子凭证。

其中，在示出的一种实施方式中，该对象分配请求中携带的电子凭证的数量和类别数，可以均为上述第一数量，从而服务端在收到该对象分配请求后，可以获取该对象分配请求中携带的电子凭证，然后进行验证。

需要说明的是，第一客户端向服务端发起对象分配请求的操作，可以由用户手动触发，也可以是由第一客户端在判断出收集到的电子凭证的类别数达到第一数量时自动触发。

例如，在一种情况下，当第一客户端在后台判断出收集到的电子凭证达到第一数量时，可以自动向服务端发起上述对象分配请求。在另一种情况下，可以在与各电子凭证对应的展示位置上，提供一个用于触发第一客户端向服务端发起对象分配请求的触发按钮(该触发按钮也可以是一个展示位置)，当第一客户端在后台判断出收集到的电子凭证达到第一数量时，第一客户端可以通过该触发按钮向用户输出提示，以提示用户当前已经可以取得业务对象分配的权限，然后第一客户端可以根据用户针对该触发按钮的触发操作，向服务端发起上述业务分配请求。

在本例中，如果服务端在对该对象分配请求中携带的电子凭证进行验证后，判断出该对象分配请求中携带的电子凭证的类别数达到第一数量，此时可以授予第一用户分配业务对象的权限，并立即基于预设的分配规则从对应的业务对象集合中为第一用户分配业务对象，或者在为本次业务对象的分配指定的分配时间到达后，基于预设的分配规则从对应的业务对象集合中为第一用户分配业务对象。

其中，上述分配规则也可以基于实际的业务需求进行制定。

在示出的一种实施方式中，服务端可以统计所有授予了对象分配权限的用户数量，并基于统计出的用户数量计算业务对象集合中的业务对象的平均分配数，此时计算出的该平均分配数即为需要向每一个用户分配的业务对象的数量。在这种情况下，服务端可以基于计算得到的平均分配数，从业务对象集合中为每一个用户分配业务对象。

例如，以红包发放业务为例，服务端可以统计所有获得红包领取权限的用户数量，然后通过可发放的红包总数除以具有红包领取权限的用户数量得到平均数，然后为按照该平均数为每一个用户发放对应金额的红包。

在示出的另一种实施方式中，服务端在为第一用户分配业务对象时，也 可以从业务对象集合中为第一用户随机抽取一定数量的业务对象。例如，服务端可以基于预设的随机算法结合业务对象集合中业务对象的总数量，为第一用户计算出一个随机数，然后按照该随机数向用户分配业务对象。

当然，除了以上示出的分配规则，在实际应用中还可以由其它分配规则，在本申请中不再一一列举。

在本例中，当服务端为第一用户分配业务对象完成后，还可以向第一用户所在的第一客户端发送一个分配结果，第一客户端在收到该分配结果后，可以将该分配结果向用户展示。

其中，该分配结果可以包括分配的业务对象的数量、业务对象的发送方、业务对象的其它接收方、其它接收方的数量以及业务对象的分配规则等信息中的一个或者多个。例如，以红包发放业务为例，当服务端为第一用户发放了红包后，上述分配结果中向第一用户展示的信息可以包括：红包金额、红包的发送方、红包的其它接收者、其它接收者的数量以及红包的分配规则等信息。

可见，在以上各实施例中，通过在对第一用户分配业务对象时，第一用户可以通过第一客户端获取用于提取业务对象的电子凭证，当获取到的电子凭证类别数达到第一数量时，第一用户可以取得业务对象的分配权限，通过第一客户端向服务端发起对象分配请求使得服务端为第一用户分配业务对象，从而可以提升业务分配过程中的趣味性，以及用户的应用体验。

以下结合具体的应用场景对以上实施例中的技术方案进行详细描述。

在本申请中，图1所示出的技术方案，可以在不同用户之间实现不同的业务。例如，上述业务可以是红包发放业务。

以下以上述业务为红包发放业务为例并结合具体的应用场景进行说明。

在示出的一种应用场景中，上述业务可以是与红包发放平台合作的企业向用户发放红包的业务。

在这种应用场景中，上述客户端可以是用户的具有红包功能的支付客户端；比如，支付宝。上述服务端可以是指具有红包发放功能支付平台；例如 支付宝平台。上述业务对象可以包括通过红包的形式发放的资金。上述业务对象集合可以是指与支付平台合作的企业的企业资金账户，该企业资金账户下的资金即为该企业可用于向用户发放红包的资金总额。上述电子凭证可以是红包发放平台用于确认用户是否具有红包领取权限的虚拟卡片。

在示出的一种“五福分大奖”的红包发放的活动业务中，红包发放平台可用于向用户下发的电子凭证可以包括“寿康福”、“友爱福”、“国强福”、“家和福”以及“财旺福”等5类虚拟卡片，用户收集到这5类虚拟卡片后，会相应的获得领取由与支付平台合作的企业发送的“五福“红包的权限。

请参见图2，在用户的客户端中，可以提供一个活动入口，该活动入口具体可以是一个“迎五福领红包”的活动界面，在该活动界面中可以提供一“获取五福卡片”触发选项，当用户通过点击等触发操作触发该选项后，支付客户端可以向支付平台发起获取虚拟卡片的请求，支付平台在收到该请求后，可以为用户主动下发虚拟卡片。

其中，在以上5类虚拟卡片中，支付平台可以设定一定数量种类的“少见”虚拟卡片，比如2类。这类“少见”虚拟卡片的发放与否取决于支付平台基于用户的数据计算出的该用户的活跃度，即可以优先将这类“少见”虚拟卡片发放给活跃度较高的用户。支付平台在针对普通用户下发虚拟卡片时，可以默认仅为用户下发“寿康福”、“友爱福”、“国强福”、“家和福”以及“财旺福”等5类虚拟卡片中的2～3类卡片。

在本例中，用户除了可以获取服务端主动下发的虚拟卡片以外，还可以获取其它用户分享的虚拟卡片。

其中，其它用户在分享虚拟卡片时，可以采用相同的客户端在客户端内部进行分享，也可以通过客户端将虚拟卡片以链接或者图文的形式通过第三方的社交平台或者即时通信客户端进行分享。

在本例中，当用户的客户端获取到虚拟卡片时，可以为该虚拟卡片生成一张对应的展示图片，然后将该展示图片在活动界面中展示。其中，客户端 为不同种类的虚拟卡片生成的展示图片上的内容互不相同。

请参见图3，在将该展示图片在活动界面中展示时，该展示图片上可以提供一“领福啦”的触发选项，用户可以点击等触发操作触发该选项，对该虚拟卡片进行收取，然后添加至客户端提供的对应展示位置上。

其中，客户端提供的展示位置可以与虚拟卡片的种类一一对应，每一种虚拟卡片可以分别对应一个展示位置。

请参见图4，可以在活动界面中为“寿康福”、“友爱福”、“国强福”、“家和福”以及“财旺福”等5类虚拟卡片分别提供一个展示位置，当客户端将展示图片添加至对应的展示位置后，客户端还可以在该展示位置的预设位置(图4示出的为右上角)上标注当前获取到的该虚拟卡片的数量，同时当与该展示位置对应的虚拟卡片的数量发生变化时，客户端还可以对该数量进行更新。

请继续参见图4，除了以上5种展示位置，在活动界面的虚拟卡片展示位置上，还可以提供一个“五福”的展示位置，在用户未成功收集到“寿康福”、“友爱福”、“国强福”、“家和福”以及“财旺福”等5类虚拟卡片的情况下，可以该“五福”展示位置设置为灰色，以提示用户当前未取得领取“五福”红包的权限。

在本例中，对于在展示位置上展示的虚拟卡片，还可以由用户分享给其它用户。

请参见图4，当第用户想要对某一类虚拟卡片进行分享，可以通过点击等触发操作来触发该虚拟卡片对应的展示位置，当展示位置触发后，可以将与该展示位置对应的展示图片显示在用户界面中。

此时，在该展示图片中可以提供一“送一张给朋友”的触发选项；当用户通过点击等触发操作触发该触发选项后，客户端可以输出一个分享方式的选择界面，在该选择界面中可以提供若干种可供第一用户选择的分享方式；比如，分享方式可以包括“通过微信发送给朋友”、“通过qq发送给朋友”以及“通过钉钉发送给朋友”等选项。

用户可以在该选择界面中选择分享方式，当选择完成后，用户还可以在好友列表中指定要分享的目标用户，然后由客户端将该虚拟卡片以链接或者图文的形式发送给该目标用户。

当用户通过获取支付平台下发的虚拟卡片，以及获取其它好友分享的虚拟卡片，成功收集到“寿康福”、“友爱福”、“国强福”、“家和福”以及“财旺福”等5类虚拟卡片后，此时用户已具有领取“五福”红包的权项。

请参见图5，当用户成功收集到“寿康福”、“友爱福”、“国强福”、“家和福”以及“财旺福”等5类虚拟卡片后，可以将该“五福”展示位置突出显示，比如高亮显示，以提示用户当前已具有领取“五福”红包的权限。

当用户获取到领取“五福”红包的权限后，用户可以通过手动触发该“五福”展示位置，触发客户端向支付平台发送红包分配请求，或者由客户端自动向支付平台发送红包分配请求。此时，该红包分配请求中可以携带已经收集到的5种虚拟卡，支付平台收到该请求后，可以对该请求中虚拟卡的种类进行验证，如果支付平台验证后确定该请求中携带5种虚拟卡，支付平台可以立即从合作的企业的企业资金账户中为该用户发放一定金额的“红包”，或者在发放时间到达时向用户发送一定金额的“红包”。例如，支付平台可以将统计所有获得领取“五福”红包权限的用户的数量，然后平均分配企业资金账户中可用于发放的红包金额。

当用户领取“红包”后，支付平台可以向客户端推送一个红包发放结果，客户端在收到该发放结果后，可以在活动界面中向用户展示。

请参见图6，在该红包发放结果中展示的信息可以包含本次领取到的金额，本次红包的发送者(与支付平台合作的企业名称)，本次领取“五福”红包的总人数，本次“五福”红包的分配规则(图7示出的分配规则为平均分配)，等等。

可见，当图1所示出的技术方案应用在红包发放的应用场景中时，用户可以通过收集到一定数量的电子凭证来取得红包领取权限，从而可以提升红包发放的趣味性，提升用户的体验。

与以上方法实施例对应，本申请还提供了装置实施例。

请参见图7，本申请提出一种业务实现装置70，应用于电子设备；其中，请参见图8，作为承载所述业务实现装置70的终端所涉及的硬件架构中，通常包括cpu、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述业务实现装置70通常可以理解为加载在内存中的计算机程序，通过cpu运行之后形成的软硬件相结合的逻辑装置，所述装置70包括：

获取模块701，用于获取用于提取业务对象的电子凭证；

第一判断模块702，用于判断获取到的电子凭证的类别数是否达到第一数量；

发起模块703，用于获取到的电子凭证的类别数达到第一数量时，向服务端发起包含若干电子凭证并且包含的电子凭证的类别数为第一数量的对象分配请求，以使得所述服务端基于该对象分配请求从业务对象集合中为所述第一用户分配业务对象。

在本例中，所述获取模块701具体用于：

获取服务端为所述第一客户端下发的电子凭证；以及

获取第二用户通过第二客户端分享的电子凭证。

在本例中，所述第一客户端提供用于获取电子凭证的触发选项；

所述获取模块701进一步用于：

当检测到所述第一用户针对所述触发选项的触发操作时，向所述服务端发起用于获取所述电子凭证的请求，以使得所述服务端基于预设下发规则向所述第一客户端下发电子凭证；

获取所述服务端基于所述预设下发规则为所述第一客户端下发的电子凭证；其中，所述服务端为所述第一客户端下发的电子凭证的类别数小于所述第一数量。

在本例中，所述装置70还包括：

生成模块704，用于在获取到电子凭证时，为该电子凭证生成对应的展示图片；

展示模块705，用于将生成的展示图片添加至与所述电子凭证对应的展示位置；其中，不同种类的电子凭证生成的展示图片互不相同；不同种类的电子凭证对应的展示位置互不相同。

在本例中，所述生成模块704进一步用于：

在所述展示位置上标注获取到的所述电子凭证的数量；

基于该电子凭证的实际剩余数量对该数量进行更新。

在本例中，所述装置70还包括：

分享模块706，用于在检测到第一用户针对任一展示位置中添加的展示图片的预设触发操作时，将与该展示图片对应的电子凭证分享至由第一用户选定的目标用户。

在本例中，所述装置70还包括：

第一接收模块707，用于在所述服务端为所述第一用户分配完成业务对象时，接收所述服务端发送的分配结果，并将所述分配结果向所述第一用户展示；

其中，所述分配结果包括以下信息中的一个或者多个：

所述业务对象的数量、所述业务对象的发送方、所述业务对象的其它接收方的数量以及所述业务对象的分配规则。

请参见图9，本申请提出一种业务实现装置90，应用于服务端；其中，请参见图10，作为承载所述业务实现装置90的服务端所涉及的硬件架构中，通常包括cpu、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述业务实现装置90通常可以理解为加载在内存中的计算机程序，通过cpu运行之后形成的软硬件相结合的逻辑装置，所述装置90包括：

第二接收模块901，用于接收第一用户通过第一客户端发送的对象分配请求；所述对象分配请求中包含用于提取业务对象的若干电子凭证；

第二判断模块902，用于判断所述对象分配请求中包含的电子凭证的类别数是否达到第一数量；

分配模块903，用于在所述对象分配请求中包含的电子凭证的类别数达 到第一数量，基于预设分配规则从业务对象集合中为所述第一用户分配业务对象。

在本例中，所述装置90还包括：

下发模块904，用于在接收到所述第一客户端发送的用于获取所述电子凭证的请求时，基于预设下发规则从本地存储的电子凭证中向所述第一客户端下发电子凭证；

其中，为所述第一客户端下发的电子凭证的类别数小于所述第一数量。

在本例中，所述下发模块904具体用于：

从本地存储的电子凭证中随机向所述第一客户端下发电子凭证。

在本例中，所述本地存储的电子凭证至少被预先划分为低频下发集合和高频下发集合；

所述下发模块904具体用于：

计算所述第一用户的活跃度；

判断所述活跃度是否达到预设阈值；

当所述活跃度达到预设阈值时，从所述低频下发集合中向所述第一客户端下发电子凭证；或者，

从所述低频下发集合和高频下发集合中向所述第一下发电子凭证；其中，下发的电子凭证中包括至少一个低频下发集合中的电子凭证。

在本例中，所述装置90还包括：

发送模块905，用于在为所述第一用户分配完成业务对象时，向所述第一客户端发送分配结果，以使所述第一客户端将所述分配结果向所述第一用户展示；

其中，所述分配结果包括以下信息中的一个或者多个：

所述业务对象的数量、所述业务对象的发送方、所述业务对象的其它接收方的数量以及所述业务对象的分配规则。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在 本申请保护的范围之内。