本申请涉及通讯技术领域，尤其涉及一种对象分配方法及装置。
背景技术：
以通讯场景为例。在通讯场景下包括配置为客户端的网络节点，以及配置为服务端的网络服务器，其中每一客户端存在自身对应的对象集合，该对象集合中包含该客户端所属的对象，例如该对象可以为通讯场景下的通讯资源。每一客户端均可以通过向服务端发送对象分配消息，以将自身所属的至少一部分对象分配至其他客户端；那么，当对象为通讯资源时，通过上述过程可以实现对通讯资源的合理分配，使得每一网络节点均能够获得足量的通讯资源，以提升整个通讯网络的通讯效率，避免在部分网络节点发生通讯阻塞的情况。
但是，在相关技术中并未考虑对象分配操作的时间因素，而由分配来源方主动确定该对象分配操作的执行时刻，可能造成对象分配的时刻不合理。例如，当过早执行对象分配操作时，被分配的对象可能并不能够及时被应用，从而造成资源闲置；而过晚执行对象分配操作时，可能相应的客户端处已经发生了通讯阻塞等情况，从而造成了通讯效率降低。
技术实现要素：
有鉴于此，本申请提供一种对象分配方法及装置，可以简化用户操作，并提升对象分配操作的准时性。
为实现上述目的，本申请提供技术方案如下：
根据本申请的第一方面，提出了一种对象分配方法，包括：
根据分配来源方的客户端接收到的对象分配请求，配置待分配的对象数量和对象分配时刻；
向服务端发送对象分配消息，所述对象分配消息中包含所述待分配的对象数量和所述对象分配时刻；其中，所述待分配的对象数量用于指示所述服务端从所述分配来源方对应的对象集合中提取相应数量的待分配对象，以及所述对象分配时刻用于指示所述服务端控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
根据本申请的第二方面，提出了一种对象分配方法，包括：
根据服务端接收到的对象分配消息，确定分配来源方、待分配的对象数量和对象分配时刻；
从所述分配来源方对应的对象集合中，提取对应于所述待分配的对象数量的待分配对象；
在将所述待分配对象分配至分配目标方时，控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
根据本申请的第三方面，提出了一种对象分配方法，包括：
根据分配目标方的客户端接收到的来自服务端的获取通知，确定所述获取通知中包含的对象分配时刻；其中，所述获取通知用于将来自分配来源方的待分配对象分配至所述分配目标方，且所述对象分配时刻由所述分配来源方配置得到；
当所述对象分配时刻尚未到达时，限制所述分配目标方对所述获取通知的触发权限；当所述对象分配时刻到达时，开放所述分配目标方对所述获取通知的触发权限；
当所述触发权限已开放时，根据检测到的对所述获取通知的触发操作，向所述服务端发送对象获取请求，以获取所述待分配对象的至少一部分。
根据本申请的第四方面，提出了一种对象分配装置，包括：
配置单元，根据分配来源方的客户端接收到的对象分配请求，配置待分配的对象数量和对象分配时刻；
发送单元，向服务端发送对象分配消息，所述对象分配消息中包含所述待分配的对象数量和所述对象分配时刻；其中，所述待分配的对象数量用于指示所述服务端从所述分配来源方对应的对象集合中提取相应数量的待分配对象，以及所述对象分配时刻用于指示所述服务端控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
根据本申请的第五方面，提出了一种对象分配装置，包括：
确定单元，根据服务端接收到的对象分配消息，确定分配来源方、待分配的对象数量和对象分配时刻；
提取单元，从所述分配来源方对应的对象集合中，提取对应于所述待分配的对象数量的待分配对象；
控制单元，在将所述待分配对象分配至分配目标方时，控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
根据本申请的第六方面，提出了一种对象分配装置，包括：
确定单元，根据分配目标方的客户端接收到的来自服务端的获取通知，确定所述获取通知中包含的对象分配时刻；其中，所述获取通知用于将来自分配来源方的待分配对象分配至所述分配目标方，且所述对象分配时刻由所述分配来源方配置得到；
管理单元，当所述对象分配时刻尚未到达时，限制所述分配目标方对所述获取通知的触发权限；当所述对象分配时刻到达时，开放所述分配目标方对所述获取通知的触发权限；
发送单元，当所述触发权限已开放时，根据检测到的对所述获取通知的触发操作，向所述服务端发送对象获取请求，以获取所述待分配对象的至少一部分。
根据本申请的第七方面，提出了一种对象分配方法，包括：
向任一群组的群组成员发送资源推荐消息，所述资源推荐消息中包含符合预定义资源推荐规则的操作资源的信息；
接收至少一个群组成员针对所述资源推荐消息返回的资源申请消息，所述资源申请消息中包含针对所述操作资源的对象提供量；
将所述操作资源的使用权限赋予最大对象提供量对应的特定群组成员，以使所述特定群组成员利用所述操作资源实现针对所述任一群组的对象分配操作。
根据本申请的第八方面，提出了一种对象分配装置，包括：
发送单元，向任一群组的群组成员发送资源推荐消息，所述资源推荐消息中包含符合预定义资源推荐规则的操作资源的信息；
接收单元，接收至少一个群组成员针对所述资源推荐消息返回的资源申请消息，所述资源申请消息中包含针对所述操作资源的对象提供量；
赋予单元，将所述操作资源的使用权限赋予最大对象提供量对应的特定群组成员，以使所述特定群组成员利用所述操作资源实现针对所述任一群组的对象分配操作。
根据本申请的第九方面，提出了一种对象分配方法，包括：
当接收到分配来源方的客户端发送的对象预分配请求时，若所述对象预分配请求的发送方用户被验证为所述分配来源方，则记录所述对象预分配请求包含的预分配的对象数量；
当接收到所述分配来源方的客户端针对任一通讯会话发送的对象分配消息时，确定所述对象分配消息中包含的待分配的对象数量；
当所述待分配的对象数量不大于所述预分配对象的剩余数量时，免除对所述对象分配消息的发送方用户的身份验证，并从所述分配来源方对应的对象集合中提取对应于所述待分配的对象数量的待分配对象，以供分配至分配目标方。
根据本申请的第十方面，提出了一种对象分配装置，包括：
记录单元，当接收到分配来源方的客户端发送的对象预分配请求时，若所述对象预分配请求的发送方用户被验证为所述分配来源方，则记录所述对象预分配请求包含的预分配的对象数量；
确定单元，当接收到所述分配来源方的客户端针对任一通讯会话发送的对象分配消息时，确定所述对象分配消息中包含的待分配的对象数量；
提取单元，当所述待分配的对象数量不大于所述预分配对象的剩余数量时，免除对所述对象分配消息的发送方用户的身份验证，并从所述分配来源方对应的对象集合中提取对应于所述待分配的对象数量的待分配对象，以供分配至分配目标方。
由以上技术方案可见，本申请通过由客户端配置对象分配时刻，可以准确地限制分配目标方对待分配对象的获取时刻，使其不早于该对象分配时刻，从而提升对象分配操作的可控性和准时性。
附图说明
图1是本申请一示例性实施例提供的基于分配来源方的一种对象分配方法的流程图。
图2是本申请一示例性实施例提供的基于服务端的一种对象分配方法的流程图。
图3是本申请一示例性实施例提供的基于分配目标方的一种对象分配方法的流程图。
图4是本申请一示例性实施例提供的一种对象分配方法的流程图。
图5-24是本申请一示例性实施例提供的一种与发放红包相关的页面示意图。
图25是本申请一示例性实施例提供的基于分配来源方的一种电子设备的结构示意图。
图26是本申请一示例性实施例提供的基于分配来源方的一种对象分配装置的框图。
图27是本申请一示例性实施例提供的基于服务端的一种电子设备的结构示意图。
图28是本申请一示例性实施例提供的基于服务端的一种对象分配装置的框图。
图29是本申请一示例性实施例提供的基于分配目标方的一种电子设备的结构示意图。
图30是本申请一示例性实施例提供的基于分配目标方的一种对象分配装置的框图。
图31是本申请一示例性实施例提供的基于服务端的另一种对象分配方法的流程图。
图32-39是本申请一示例性实施例提供的另一种与发放红包相关的页面示意图。
图40是本申请一示例性实施例提供的基于服务端的另一种电子设备的结构示意图。
图41是本申请一示例性实施例提供的基于服务端的另一种对象分配装置的框图。
图42是本申请一示例性实施例提供的基于服务端的又一种对象分配方法的流程图。
图43是本申请一示例性实施例提供的基于服务端的又一种电子设备的结构示意图。
图44是本申请一示例性实施例提供的基于服务端的又一种对象分配装置的框图。
具体实施方式
图1是本申请一示例性实施例提供的基于分配来源方的一种对象分配方法的流程图。如图1所示，该方法应用于预设通讯应用的客户端，且该客户端上登录有分配来源方的注册账号(即该方法应用于分配来源方对应的客户端)，可以包括以下步骤：
步骤102，根据分配来源方的客户端接收到的对象分配请求，配置待分配的对象数量和对象分配时刻。
在本实施例中，本申请并不对预设通讯应用的类型等进行限制。举例而言，该预设通讯应用可以为即时通讯应用，比如企业即时通讯(enterpriseinstantmessaging，eim)应用“钉钉(dingtalk)”等。
在本实施例中，通过在电子设备上安装预设通讯应用的客户端应用程序(app)，并登录用户在该预设通讯应用处的注册账号，即可将该电子设备配置为该用户对应的预设通讯应用的客户端。其中，该电子设备可以为手机、平板等移动设备，或者该电子设备也可以为pc主机等非移动式的电子设备，本申请并不对此进行限制。当然，当采用诸如html5技术的在线“客户端”，无需在电子设备上安装相应的应用程序，即可在电子设备上运行上述的客户端。
其中，当任一用户(通过上述预设通讯应用的客户端)将自身的对象分配至其他用户时，该任一用户被作为本申请中的“分配来源方”，而被分配的用户被作为本申请中的“分配目标方”；当然，当另一用户将自身的对象分配至该任一用户时，该另一用户被作为本申请中的“分配来源方”，而该任一用户则被作为本申请中的“分配目标方”。可见，本申请中的“分配来源方”、“分配目标方”只是身份类型，并不固定指代某个或某些用户，将根据实际情况的变化而确定。
在一实施例中，对象分配请求中可以包含分配来源方手动设定的数量，例如可由分配来源方在客户端的显示界面内输入，使得分配来源方的客户端可以据此配置待分配的对象数量。
在另一实施例中，分配来源方的客户端可以示出配置页面，当该配置页面的推荐数量功能处于启用状态时，该客户端可以生成符合预定义的数量推荐规则的推荐数量，以作为所述待分配的对象数量。在本实施例中，可以采用任意形式的数量推荐规则，本申请并不对此进行限制；举例而言，一种情况下，该数量推荐规则可以为随机推荐规则，即客户端按照预定义的随机或伪随机算法计算出一随机数，以作为推荐数量，当然进一步地可以限制该随机数的数值范围，以确保不超出分配来源方的承受范围(一层面上，可以理解为不超出分配来源方拥有的对象数量，另一层面上，可以理解为不超出分配来源方希望分配的对象数量，当然还可以存在其他层面的理解，此处并不对此进行限制)；另一种情况下，该数据推荐规则可以为比例推荐规则，即客户端将分配来源方的所有对象的总数乘以预设比例，并将得到的数值作为推荐数量。
在一实施例中，分配来源方可以在自身参与的通讯会话中发起对象分配请求，则客户端可以自动将该通讯会话的所有对端用户配置为分配目标方，其中该通讯会话可以为单聊通讯会话或者群聊通讯会话。但是，在一些情况下，例如当分配来源方将待分配对象划分至若干子集合(均分或随机划分或采用其他划分方式)，且子集合的数量小于通讯会话的所有对端用户的数量时，需要由这些对端用户对有限数量的上述子集合进行竞争，则客户端只是向所有的对端用户赋予了参与竞争的权限，但只有竞争成功的对端用户才属于上述的分配目标方，而竞争失败的对端用户则不属于分配目标方。
在另一实施例中，当分配来源方在自身参与的群聊通讯会话中发起对象分配请求时，该分配来源方可以进一步从所有对端用户中进行选择，则客户端可以将被选中的对端用户配置为分配目标方，而未被选中的对端用户则不会被配置为分配目标方、无法获得分配来源方分配的对象。
在一实施例中，对象分配请求中可以包含分配来源方手动设定的时刻，例如可由分配来源方在客户端的显示界面内输入，使得分配来源方的客户端可以据此配置对象分配时刻。
在另一实施例中，分配来源方的客户端可以示出配置页面，当该配置页面的时刻推荐功能处于启用状态时，该客户端可以生成符合预定义的时刻推荐规则的推荐时刻，以作为所述对象分配时刻。
在一种情况下，所述时刻推荐规则可以包括对第一特征数值的推荐条件，则分配来源方的客户端可以生成每一时刻位均为所述第一特征数值的所述推荐时刻。其中，时刻位是指构成推荐时刻的“时”、“分”、“秒”、“毫秒”等，例如当推荐时刻为“18:18:18”时，该推荐时刻包括的时刻位为“时”、“分”和“秒”，且每一时刻位的数值均为18，再例如当推荐时刻为“9:59:59:999”时，该推荐时刻包括的时刻位为“时”、“分”、“秒”和“毫秒”，且时刻位“时”的数值为9、时刻位“分”和“秒”的数值为59、时刻位“毫秒”的数值为999。第一特征数值可以为用户更加偏向和喜爱的数值；相关技术中提供了由分配来源方手动配置时刻信息的方案，使得服务端在该时刻信息开放分配目标方对待分配对象的获取权限，则服务端可以通过获取相关技术中对于时刻信息的历史配置数据，并统计得到上述的第一特征数值，例如6、8、9……59、66……999等。当采用上述的第一特征数值时，由于其相对更加受到用户喜爱，使得分配目标方能够更加轻易地记忆该推荐时刻，并在到达该推荐时刻时更容易回忆起相关事件，从而及时请求和获取相应的待分配对象，有助于提升对象分配效率。
在另一种情况下，时刻推荐规则可以包括对第二特征数值的弃用条件，则分配来源方的客户端可以生成每一时刻位均避免使用所述第二特征数值的所述推荐时刻。第二特征数值可以为用户不希望采用的数值，例如服务端同样可以通过对上述的历史配置数据进行分析，以统计出上述的第二特征数值。举例而言，对于一些数值，例如数值1和数值7等，由于字形上存在相近，容易造成误判；例如，当存在多个分配目标方时，如果某一分配目标方将时刻“16:11:18”误看为“16:17:18”，可能导致待分配对象在“16:11:18”～“16:17:18”之间被其他分配目标方完全获得，从而影响了对待分配对象的合理分配。
在又一种情况下，分配来源方的客户端可以接收到所述服务端发送的提示消息，所述提示消息包含与所述分配来源方的任一关联用户相关的日期信息；然后，当所述时刻推荐规则包括对所述日期信息的应用条件时，在检测到针对所述提示消息的响应操作的情况下，生成与所述日期信息相关(例如该日期信息对应日期中的某一固定或动态确定的时刻)的所述推荐时刻。进一步地，还可以将该任一关联用户作为分配目标方，从而基于本申请的技术方案向该任一关联用户进行对象分配操作。那么基于服务端发送的提示消息，分配来源方可以直接发起对任一关联用户的对象分配操作，而无需主动触发对象分配，有助于简化该分配来源方的操作。
在本实施例中，当所述对象分配请求是针对所述分配来源方所属的任一群组而发起时，客户端可以根据所述任一群组中的其他群组成员向所述服务端发送的对象分配消息，确定出相应的已采用推荐时刻，然后生成符合所述时刻推荐规则且区别于所述已采用推荐时刻的推荐时刻，从而避免多个群组成员采用相同的推荐时刻时，反而影响分配目标方对各个群组成员对应的待分配对象进行获取，因而有助于提升对象分配效率。
步骤104，向服务端发送对象分配消息，所述对象分配消息中包含所述待分配的对象数量和所述对象分配时刻；其中，所述待分配的对象数量用于指示所述服务端从所述分配来源方对应的对象集合中提取相应数量的待分配对象，以及所述对象分配时刻用于指示所述服务端控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
在本实施例中，分配来源方的客户端可以确定所述对象分配请求的接收时刻对应的节日信息，并获取与所述节日信息相关的描述信息，然后在所述对象分配消息中记载所述描述信息；相应地，分配目标方的客户端可以在与获取所述待分配对象相关的页面内示出所述描述信息，以使得分配目标方通过视觉感受了解相应的节日信息，实现对分配目标方的提示作用。其中，上述的“与获取所述待分配对象相关的页面”可以包括：用于所述分配目标方向所述服务端请求获取所述待分配对象的至少一部分的对象请求页面，以及用于示出对象请求结果的结果展示页面等。
相应地，图2是本申请一示例性实施例提供的基于服务端的一种对象分配方法的流程图。如图2所示，该方法应用于预设通讯应用的服务端，可以包括以下步骤：
步骤202，根据服务端接收到的对象分配消息，确定分配来源方、待分配的对象数量和对象分配时刻。
步骤204，从所述分配来源方对应的对象集合中，提取对应于所述待分配的对象数量的待分配对象。
步骤206，在将所述待分配对象分配至分配目标方时，控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
在一实施例中，在接收到所述对象分配消息后，服务端可以延迟至所述对象分配时刻到达时，向所述分配目标方的客户端发送针对所述待分配对象的第一获取通知，所述第一获取通知用于指示所述分配目标方的客户端无延迟地响应于针对所述第一获取通知的触发操作。举例而言，服务端在接收到对象分配消息后，从该对象分配消息中解析出对象分配时刻为“x:y:z”(x、y、z可以为符合时刻推荐规则的任意相同或不相同的数值)，则服务端需要等待到达该对象分配时刻时，才向分配目标方发送第一获取通知，而分配目标方在客户端接收到该第一获取通知后，可以立即通过触发该第一获取通知而获得待分配对象，从而将分配目标方对待分配对象的获取时刻控制在不早于对象分配时刻。其中，“延迟”应当理解为服务端或客户端“故意”或“主动”推迟相关操作的执行时刻，而不包括服务端或客户端由于运算处理性能、数据传输性能不足而导致的反应“迟缓”。
在另一实施例中，在接收到所述对象分配消息后，服务端可以无延迟地向所述分配目标方的客户端发送针对所述待分配对象的第二获取通知，所述第二获取通知中包含所述对象分配时刻，用于指示所述分配目标方的客户端延迟至所述对象分配时刻时，开放所述分配目标方对所述第二获取通知的触发权限；换言之，分配目标方的客户端可以在对象分配时刻之前接收到第二获取通知，但是分配目标方在对象分配时刻之前并不具有对该第二获取通知的触发权限，而必须等待到达对象分配时刻，从而将分配目标方对待分配对象的获取时刻控制在不早于对象分配时刻。
在又一实施例中，在接收到所述对象分配消息后，服务端可以无延迟地向所述分配目标方的客户端发送针对所述待分配对象的第三获取通知，并在所述对象分配时刻到达时开放所述分配目标方对所述待分配对象的获取权限；换言之，分配目标方的客户端可以在对象分配时刻之前接收到第三获取通知，并且分配目标方也可以对该第三获取通知进行触发，但是由于服务端并未开放获取权限，使得分配目标方无法在对象分配时刻之前获得待分配对象，将分配目标方对待分配对象的获取时刻控制在不早于对象分配时刻。
在本实施例中，当接收到同一群组的多个群组成员分别针对所述群组发送的对象分配消息，且多条对象分配消息对应的对象分配时刻相同时，服务端可以保留待分配的对象数量最大的对象分配消息，并取消对所述多条对象分配消息中的其他对象分配消息的处理，从而避免多个群组成员采用相同的对象分配时刻时，反而影响分配目标方对各个群组成员对应的待分配对象进行获取，因而有助于提升对象分配效率。当然，每一群组成员均可以对自身对应的“待分配的对象数量”进行编辑，例如通过将自身对应的“待分配的对象数量”增至最大，以获得在相应的对象分配时刻执行对象分配的“权限”，即实现对同一对象分配时刻的“竞拍”。类似地，每一群组成员还可以对自身对应的“对象分配时刻”进行编辑，例如修改为他人未采用的时刻。
相应地，图3是本申请一示例性实施例提供的基于分配目标方的一种对象分配方法的流程图。如图3所示，该方法应用于预设通讯应用的客户端，且该客户端上登录有分配目标方的注册账号(即该方法应用于分配目标方对应的客户端)，可以包括以下步骤：
步骤302，根据分配目标方的客户端接收到的来自服务端的获取通知，确定所述获取通知中包含的对象分配时刻；其中，所述获取通知用于将来自分配来源方的待分配对象分配至所述分配目标方，且所述对象分配时刻由所述分配来源方配置得到。
步骤304，当所述对象分配时刻尚未到达时，限制所述分配目标方对所述获取通知的触发权限；当所述对象分配时刻到达时，开放所述分配目标方对所述获取通知的触发权限。
步骤306，当所述触发权限已开放时，根据检测到的对所述获取通知的触发操作，向所述服务端发送对象获取请求，以获取所述待分配对象的至少一部分。
在本实施例中，当接收到所述获取通知时，分配目标方的客户端可以示出相应的提醒页面，所述提醒页面中包含提醒设置选项；然后，当检测到所述提醒设置选项被触发时，分配目标方的客户端可以创建针对所述获取通知的提醒消息；其中，所述提醒消息的提醒时刻较之所述对象分配时刻提前第一预设时长、提醒对象为所述分配目标方，即在对象分配时刻到达之前对该分配目标方进行提醒，尤其是当前时刻与对象分配时刻之间的间隔较长时，通过设置一临近对象分配时刻的提醒消息，有助于实现对分配目标方的及时提醒，使得分配目标方仅需要在接收到提醒消息之后关注于对象分配时刻的到达，从而尽可能地降低对分配目标方的其他事项处理操作的影响。其中，提醒页面内可以示出相应的对象分配时刻，或者针对该对象分配时刻的倒计时，以便于分配目标方快速查看。
在本实施例中，在当前时刻较之所述对象分配时刻提前第二预设时长时，分配目标方的客户端可以在所述分配目标方的客户端的其他显示内容之上，叠加展示针对所述对象分配时刻的倒计时图标，直至到达所述对象分配时刻，从而在视觉上明显表现出对象分配时刻即将到达，有助于吸引分配目标方的注意力，使其更加关注于该对象分配时刻的到达，从而及时向服务端发送对象获取请求，以获得相应的待分配对象。
在本实施例中，分配目标方的客户端可以在所述分配目标方的客户端内示出一入口图标，然后在检测到所述入口图标被触发时，展示相应的通知列表，所述通知列表中包含已接收到且相应的对象分配时刻尚未超时的所有获取通知。那么，当该通知列表被收起时，可以避免对其他显示内容造成遮挡，防止影响分配目标方对其他事项的处理；以及，当该通知列表被展示时，可使分配目标方快速获知所有获取通知，以提升信息(即存在哪些对象分配时刻尚未超时的获取通知)获取效率。进一步地，在通知列表中的每一获取通知的展示区域内，可以示出相应的对象分配时刻或者针对该对象分配时刻的倒计时，以便于分配目标方快速查看。
由以上技术方案可见，本申请通过由客户端配置对象分配时刻，可以准确地限制分配目标方对待分配对象的获取时刻，使其不早于该对象分配时刻，从而提升对象分配操作的可控性和准时性。
本申请的技术方案可以应用于各种类型的对象分配的场景中，本申请并不对此进行限制。举例而言，在一实施例中，本申请的技术方案可以适用于通讯场景中，该通讯场景中的通讯资源可以被解释为上述的对象，而通讯网络中被配置为客户端的网络节点之间，可以基于本申请的技术方案来分配通讯资源，以使得某一网络节点的通讯资源更准时地分配至其他网络节点。在另一实施例中，本申请的技术方案可以适用于应用场景中，譬如上述的对象可以解释为虚拟礼品、电子红包、虚拟资源等；以电子红包为例，基于本申请的技术方案可以实现更准时的电子红包发放操作。当然，还可以应用于其他场景，本申请并不对此进行限制。
为了便于理解，下面以“电子红包”形式的对象为例，针对“发红包”场景对本申请的对象分配方案进行详细说明。
图4是本申请一示例性实施例提供的一种对象分配方法的流程图。如图4所示，假定用户a使用企业即时通讯应用“钉钉”的客户端1、用户b使用客户端2，当用户a通过客户端1向用户b发放红包(即电子红包)时，该用户a相当于本申请中的分配来源方、用户b相当于本申请中的分配目标方，从而通过在客户端1、服务端(即钉钉客户端)和客户端2之间的交互过程，实现下述的对象分配过程：
步骤402，客户端1接收到红包发放请求(相当于本申请中的对象分配请求)。
在一实施例中，如图5所示，假定用户a在所属群组“认真工作小组”对应的通讯会话页面进行操作，比如可以通过点击图5所示通讯会话页面右下方的
当然，除了“企业红包”之外，本申请还可以应用于其他任意类型的红包。例如图8所示，当用户a选取“拼手气红包”时，群组“认真工作小组”的所有群组成员均被自动添加为红包发放对象，而用户a可以手动配置红包金额为10元、描述内容为“恭喜发财！！！”等。再例如，当用户a在自身与用户b之间的单聊通讯会话页面中，对诸如图6所示的“红包”功能入口进行触发时，该用户b作为唯一的对端用户，也可以被自动配置为红包发放对象，而无需用户a手动配置。
在另一实施例中，当客户端支持多种类型的红包发放方案时，可以在诸如图6所示的菜单选项中分别提供对应于每一红包发放方案的功能入口。例如图9所示，在用户a与用户b之间的单聊通讯会话页面中，菜单选项中分别包含“节日红包”和“红包”两个功能入口，分别对应于不同形式的红包发放方案。那么，用户a可以根据实际希望应用的红包发放方案，选择恰当的功能入口，以实现相应的红包发放操作。举例而言：
当用户a触发图9所示的“节日红包”功能入口时，可以转入图10所示的红包配置页面，该红包配置页面可供用户a配置红包金额等参数，但是由于仅存在唯一的对端用户为用户b，因而默认该用户b为目标用户且无法修改。需要指出的是：在图10可配置的各项参数中，包含与节日信息相关的描述信息；例如，如果当前时刻处于某一节日或其附近，譬如假定该节日为“新年”，则与“新年”对应的描述信息可以包括图10所示的图片“恭贺新年”和文字形式的描述内容“新春快乐，事事顺利”等。类似地，如果当前时刻处于“圣诞节”或其附近，则相应的描述信息可以包括与“圣诞节”相关的图片、文字等。当然，“节日红包”或其他类型的红包同样适用于诸如图5-6所示的群聊通讯会话页面的应用场景，而并不限制于图9所示的单聊通讯会话页面的应用场景。
而当用户a触发图9所示的“红包”功能入口时，可以转入图11所示的红包配置页面，该红包配置页面可供用户a配置红包金额等参数，且由于仅存在唯一的对端用户为用户b，因而默认该用户b为目标用户且无法修改。其中，图11所示的红包配置页面未包含上述的与节日信息相关的描述信息，以区分于上述的“节日红包”，而其他参数此处不再赘述。
在又一实施例中，用户a无需主动通过触发上述的“红包”、“节日红包”等功能入口，而是通过其他方式实现红包发放。其中，服务端可以针对用户a而获取其关联用户的信息，例如：由于用户a与用户b为企业同事关系，该服务端可以获取用户b的出生日期、入职日期等信息，作为与该用户b相关的日期信息；然后，在与用户b相关的日期信息将至时，比如用户b的生日或入职纪念日之前3天，服务端可以向用户a发送关于该生日或入职纪念日等与用户b相关的日期信息的提示消息，使该提示消息被展示于用户a使用的客户端1上。例如图10所示，服务端可以通过“纪念日提示”通讯会话，将上述的提示消息发送至客户端1，则当检测到用户a对该提示消息中的“送祝福”选项的触发操作时，可以通过切换至诸如图11所示的红包配置页面，以实现向该用户b的红包发放。
在本实施例中，用户a可以通过诸如上述方式转入红包配置页面，以实现对预设参数的配置操作，以及对红包发放操作。而对于“红包发放请求”，在不同场景下可能存在多种理解：一种情况下，当检测到用户a对诸如图9所示的“红包”、“节日红包”等功能入口或诸如图12所示的“送祝福”选项的触发操作时，客户端1可以理解为检测到红包发放请求，而后续可以通过用户a手动配置或客户端1自动确定等方式，确定出目标用户、红包金额等参数；另一种情况下，当用户a在上述的红包配置页面中，完成参数配置并触发图10所示的“发”或图11所示的“发红包”选项时，客户端1可以理解为检测到红包发放请求，且此时已经可以确定出所有需要了解的参数；又一种情况下，当用户a触发图12所示的提示消息中的“送祝福”选项时，客户端1可以理解为检测到红包发放请求。当然，对于“红包发放请求”还可能存在其他形式的不同理解，本申请并不对此进行限制。
需要说明的是：在红包配置页面中，除了上文描述的参数之外，用户a还可以对其他任意类型的参数进行配置，本申请并不对此进行限制。以图8所示的红包配置页面为例，该红包配置页面可以包含“红包个数”选项，则用户a可以通过设置“红包个数”，以控制服务端的红包分配操作；譬如，当红包个数为13个时，可以确保总金额为“10元”的红包资金，被平均或随机划分为13份，以供分配至13个作为分配目标方的群组成员。
步骤404，客户端1确定目标用户(相当于本申请中的分配目标方)、红包金额(相当于本申请中的待分配的对象数量)和发放时刻(相当于本申请中的推荐时刻)。
1、目标用户
对于用户a与用户b的单聊通讯会话场景，由于仅存在唯一的对端用户为用户b，如图11所示，客户端1可以默认该用户b为目标用户，而无需用户a手动配置。
对于用户a、用户b所属的群组“认真工作小组”对应的群聊通讯会话场景，存在多个对端用户：一种情况下，如图8所示，客户端1可以默认将该群组“认真工作小组”的所有群组成员添加为目标用户，而无需用户a手动配置；另一种情况下，如图7所示，可由用户a手动从该群组“认真工作小组”的所有群组成员中仅选取，并将被选中的用户b、用户c和用户d配置为目标用户。
其中，对于群聊通讯会话场景，例如当用户a通过如图8所示的“红包个数”选项，配置出的红包数量小于群组“认真工作小组”的群组成员数量时，客户端1只能够向该群组“认真工作小组”的所有群组成员赋予“抢”红包的权限，并由服务端按照诸如先到先得的竞争规则，在所有群组成员之间进行竞争(即抢红包)，则抢到红包的群组成员为上述的目标用户(服务端需要向其分配相应的红包资金)，而未抢到红包的群组成员则并非目标用户(服务端无需向其分配红包资金)。
2、红包金额
在一实施例中，用户a可以手动配置红包金额。例如在图7所示的红包配置页面中，用户a可以配置“单个金额”的数值，则红包金额为分配至所有“接收人”的总金额，即图7中的红包金额为9000元；在图8所示的红包配置页面中，用户a可以配置“总金额”的数值，则红包金额即该总金额为10元；在图11所示的红包配置页面中，用户a可以配置“金额”的数值，则红包金额即该金额为10元。
在另一实施例中，客户端1可以自动生成红包金额。例如当客户端1在展示出图10所示的红包配置页面时，假定与“节日红包”相关的红包配置页面中的推荐数量功能默认处于启用状态，客户端1可以根据预定义的数量推荐规则而主动生成相应的推荐金额(相当于本申请中的“推荐数量”)，并将其作为红包金额，例如图10中的红包金额可以为8.88元。当然，如果用户a对客户端1中的红包金额不满意，可以通过触发图10中“塞8.88元”右侧的“更新”图标，以由客户端1对红包金额进行重新计算和更新。
当然，在其他实施例中，还可以优先由客户端1向用户a提供推荐金额；而当用户a对客户端1提供的推荐金额不满意时，客户端1可以进一步向用户a提供输入框，以由用户a手动输入希望采用的红包金额。
3、发放时刻
在本实施例中，客户端1可以根据用户a的时刻配置操作，确定该用户a手动配置的发放时刻。或者，客户端1可以根据预定义的时刻推荐规则，自动生成符合该时刻推荐规则的推荐时刻，以作为此处的发放时刻，使得用户b对于红包的领取时刻不早于该推荐时刻。例如，当推荐时刻为“18:18:18”时，用户b最早也应当在“18:18:18”领取红包，而不能够在“18:18:17”或其他更早的时刻领取红包，从而实现对红包发放时刻的精准控制。
在一实施例中，时刻推荐规则可以包括对第一特征数值的推荐条件。第一特征数值可以为6、8、9等用户更加偏向和喜爱的数值，即“吉利数值”，使得相应的推荐时刻成为所谓的“吉时”。例如图7、图8、图10和图11等红包配置页面中，均包含“吉时发送”选项，当用户a将该“吉时发送”选项开启时，客户端1即可通过本申请的技术方案，主动生成上述的推荐时刻，且在本实施例中给推荐时刻可以为“吉时”，使得该推荐时刻中的每一时刻位均为第一特征数值，例如上述的推荐时刻“18:18:18”中，包括“时”、“分”、“秒”等时刻位上均为数值18。当然，推荐时刻中的不同时刻位上可以设置不同的第一特征数值，例如在推荐时刻“10:18:18”中，时刻位“时”上为数值10、时刻位“分”和“秒”上为数值18。以图11所示的红包配置页面为例，当检测到“吉时发送”选项被开启时，可以示出图13所示的显示框(图13中为空白显示框)和“算吉时”选项，并在检测到对该“算吉时”选项的触发操作时，在显示框内示出图14a所示的推荐时刻“18:18:18”；进一步地，在上述的显示框和“算吉时”选项周围，可以示出一些相关显示信息，例如上方可以示出当天日期“今日：2017年1月28日”、左侧可以示出“宜发红包送祝福”、右侧可以示出“忌不开心烦躁”等，且这些显示信息可以随着当天日期或当前时刻的变化而随之变化。
在另一实施例中，时刻推荐规则可以包括对第二特征数值的弃用条件。第二特征数值可以为3、4、7等用户不喜爱的数值，即“非吉利数值”。换言之，本实施例中可以通过从推荐时刻中排除第二特征数值，使得推进时刻的时刻位上采用的数值均为上述的第一特征数值，从而使得到的推荐时刻仍为“吉时”。
其中，用户a可以通过对客户端1进行手动配置，使客户端1确定上述的第一特征数值和第二特征数值，从而实现对推荐时刻的自动生成。或者，由于在相关技术中，存在由用户手动配置红包的发放时刻的技术方案，因而可由服务端统计用户对发放时刻的历史配置数据，从而按照每一时刻位上的各个数值的应用概率，将更高概率的数值配置为上述的第一特征数值、更低概率的数值配置为上述的第二特征数值，并进一步通过将该第一特征数值、第二特征数值推送至客户端1，使得客户端1可以据此生成相应的推荐时刻。
在又一实施例中，对于图12所示的实施例，即客户端1接收到服务端推送的提示信息，且该提示消息包含与相应的关联用户相关的日期信息；那么，当时刻推荐规则包括对日期信息的应用条件时，客户端1在检测到针对该提示消息的响应操作的情况下，比如检测到图12所示的“送祝福”选项被触发，则可以生成与该日期信息相关的推荐时刻。例如，假定当天日期为2017年1月28日，而用户b的生日为3天后的2017年1月31日，则推荐时刻可以为2017年1月31日这天中的某一时刻；比如，一种情况下推荐时刻可以为2017年1月31日的某一随机时刻，另一种情况下推荐时刻可以为2017年1月31日的某一特定时刻，譬如“2017年1月31日8时8分8秒”，又一种情况下推荐时刻可以为2017年1月31日中符合上述“对第一特征数值的推荐条件”或“对第二特征数值的弃用条件”的时刻，此处不再赘述。
其中，当用户a对显示框内示出的推荐时刻不满意时，可以通过重新触发“算吉时”选项，使得客户端1重新计算另一推荐时刻，直至得到用户a满意的推荐时刻。当然，用户a也可以通过触发显示框等预设方式，对希望采用的推荐时刻进行手动调整和配置，此处不再赘述。
此外，在群聊通讯会话的场景下，由于同一群组内存在很多群组成员，很可能出现多个群组成员使用的客户端，均推荐使用了同一发放时刻，使得群组成员在领取红包时，可能忽略掉其中的部分红包，从而无法及时领取所有红包。为此，以用户a使用的客户端1为例，假定用户a在所属的群组“认真工作小组”对应的群聊通讯会话页面内发放红包，则客户端1可以向服务端发起询问，以获知服务端已经接收到该群组“认真工作小组”中的其他群组成员发送的红包发放消息，该红包发放消息中包含该其他群组成员使用的客户端生成的推荐时刻(即已采用推荐时刻)，而客户端1在生成符合时刻推荐规则的推荐时刻时，可以主动避开这些已采用推荐时刻，从而确保同一群组内的所有红包的发放时刻都尽可能地错开。
另外，以图8所示的实施例为例：对于相关技术中提供的“拼手气红包”、“企业红包”等红包类型，本申请中可以通过添加上述的“吉时发送”选项，以使得在“拼手气红包”、“企业红包”等对应的红包配置页面中，可以通过开启该“吉时发送”选项，从而在相应的红包发放消息中包含“发放时刻”，即得到上述的“吉时红包”。而除了采用在红包配置页面内添加“吉时发送”选项的方式之外，还可以单独设置与“拼手气红包”、“企业红包”等类型并列的红包类型，例如可以通过增加图14b所示的“吉时红包”类型，则当用户a选取该“吉时红包”对应的红包配置页面时，该红包配置页面中可以直接包含与图13、图14a相似的显示框、“算吉时”选项，以及当天日期“今日：2017年1月28日”、左侧可以示出“宜发红包送祝福”、右侧可以示出“忌不开心烦躁”等其他显示信息，可以参考上述的其他红包配置页面，此处不再赘述。
步骤406，客户端1向服务端发送红包发放消息(相当于本申请中的对象分配消息)。
步骤408，服务端根据接收到的红包发放消息，确定来源用户(相当于本申请中的分配来源方)、目标用户、红包金额和发放时刻。
在本实施例中，为了解决同一群组内的多个群组成员均采用同一推荐时刻的问题，服务端可以采取下述处理方式：在接收到同一群组的多个群组成员分别针对该群组发送的红包发放消息，且多条对象分配消息对应的推荐时刻相同时，保留红包金额最大的红包发放消息，并取消对这些红包发放消息中的其他红包发放消息的处理。
进一步地，服务端可以向红包发放消息被取消处理的群组成员发送取消通知，则群组成员可以通过对该取消通知进行触发，以修改原本的红包发放消息中的红包金额，然后将修改后的红包发放消息重新发送至服务端。当然，对于服务端而言，可以不关注红包发放消息为首次发送或修改后发送，只需要将其按照新接收到的红包发放消息进行处理即可，此处不再赘述。而通过上述过程，并仅选取推荐时刻相同且红包金额最大的红包发放消息进行处理，使得相应的多个群组成员可以针对该推荐时刻的“使用权”进行竞争；比如，当该推荐时刻为某一“吉时”时，可以将该过程作为多个群组成员的“吉时竞拍”事件。
当然，接收到取消通知的群组成员，还可以对相应的红包发放消息的推荐时刻进行修改，然后将修改后的红包发放消息重新发送至服务端，则服务端将其按照新接收到的红包发放消息进行处理即可，此处不再赘述。
步骤410，服务端从客户端1对应的资金账户(相当于本申请中的分配来源方对应的对象集合)中，冻结相应数额的红包发放资金(相当于本申请中的待分配对象)。
在本实施例中，服务端可以预先从客户端1对应的资金账户中冻结相应数额的红包发放资金，以确保目标用户可以领取相应的红包资金，避免用户a在发放红包之后、发放时刻到达之前将资金从资金账户转出。或者，也可以采用其他方式进行处理，例如将红包发放资金从客户端1对应的资金账户转移至第三方支付平台进行暂存，而当目标用户需要领取红包资金时，直接从第三方支付平台将相应的红包资金转移至目标用户对应的资金账户。
当然，由于大部分来源用户并不会在发放红包之后、发放时刻到达之前将资金从资金账户转出，而且即便资金不足也只是导致红包无法领取，并不存在诸如资金安全性等问题，因而并不一定需要事先对红包发放资金进行冻结或转移等，因而步骤410并非必须执行。
步骤412，服务端向客户端2发送红包领取通知(相当于本申请中的获取通知)。
步骤414，客户端2根据接收到的红包领取通知，确定相应的发放时刻。
步骤416，客户端2根据发放时刻，对红包领取通知的触发权限进行管理。
步骤418，客户端2在触发权限被开放后，检测针对红包领取通知的触发操作。
步骤420，客户端2根据检测到的针对红包领取通知的触发操作，向服务端发送红包领取请求(相当于本申请中的对象获取请求)。
步骤422，服务端向客户端2发放红包资金。
步骤424，服务端分别向客户端1、客户端2发送领取结果通知。
在本实施例中，服务端在接收到来自用户a的红包发放消息后，无延迟地向作为目标用户的用户b对应的客户端2发送针对待发放的红包资金的红包领取通知，该红包领取通知中包含客户端1生成的发放时刻，使得客户端2在到达发放时刻之前均限制针对红包领取通知的触发权限，而等待延迟至该发放时刻到达时，才开放用户b对该红包领取通知的触发权限，从而基于用户b对该红包领取通知的触发操作，向服务端发送红包领取请求。那么，通过上述过程，客户端2可以限制用户b对于相应的红包资金的领取时刻，使得该领取时刻至少不早于红包领取通知中包含的发放时刻，实现对红包资金的“吉时发放”。类似地，当用户a选取了多个目标用户时，每个目标用户的客户端均可以采用与客户端2相似的处理方式，此处不再赘述。下面基于该实施例，并结合附图进行说明：
在本实施例中，当客户端2接收到服务端发送的红包领取通知时，可以示出如图15a所示的提醒页面。例如，提醒页面在图15a中被叠加显示于群组“认真工作小组”的群聊通讯会话页面的顶部区域，这一方面便于用户b对该提醒页面进行查看，另一方面可以避免遮挡该群聊通讯会话页面的底部区域刷新出的通讯消息，当然提醒页面还可以采用诸如弹窗等任意形式，本申请并不对此进行限制。
其中，在图15a所示的提醒页面中，通过示出用户a的头像以及文字“来自a的吉时红包”，表明存在来自用户a的“吉时红包”(即存在相应的发放时刻，即“吉时”)；同时，客户端2通过获取红包领取通知中包含的发放时刻，可以示出相应的倒计时，例如图15a所示的倒计时信息表明距离发放时刻还剩余“02小时59分20秒”。
进一步地，提醒页面中还可以包含提醒设置选项，例如该提醒设置选项位于图15a所示提醒页面的右上角；当检测到该提醒设置选项被触发时，客户端2可以创建针对相应的红包领取通知的提醒消息(例如对于企业即时通讯应用“钉钉”而言，该提醒消息可以为钉钉支持的“ding消息”)，且该提醒消息的提醒时刻较之发放时刻提前第一预设时长、提醒对象为用户b自身；例如，在提醒消息被创建后，提醒设置选项可由图15a中的“开抢提醒”更换为图15b所示的“取消提醒”(点击后可以取消已建立的上述提醒消息)，并且通过图15b中示出的“红包开抢前5分钟，应用内ding提醒”，表明客户端2将上述的第一预设时长设置为5分钟，且提醒方式为“应用内”，即客户端2在发放时刻到达前5分钟可以接收到由自己发送的一条提醒消息。
当然，提醒消息还可以采用其他方式进行发送，例如当提醒方式为“短信”时，基于用户b在“钉钉”内绑定的通讯号码，使用该通讯号码的电子设备可以在发放时刻到达前5分钟接收到一条相应的提醒短信，当提醒方式为“电话”时，该电子设备可以在发放时刻到达前5分钟被呼叫，并在接通后收听到语音播报的提醒内容。
此外，除了可以在如图15a-15b所示的通讯会话页面中示出上述的提醒页面，使得用户b等目标用户可以据此确定相应的通讯会话存在吉时红包之外，还可以采用其他方式对目标用户进行提醒。例如图16a示出了用户b使用的客户端上的会话列表页面中，该会话列表页面中包含用户b参与的通讯会话的会话页面入口，比如图16a中包含用户b与用户“小白”之间的单聊通讯会话的会话页面入口、群组“认真工作小组”对应的群聊通讯会话的会话页面入口、群组“x项目”对应的群聊通讯会话的会话页面入口等，其中当检测到针对群组“认真工作小组”对应的群聊通讯会话的会话页面入口的触发操作时，可以切换至图15a或图15b所示的该群组“认真工作小组”对应的群聊通讯会话的通讯会话页面。如图16a所示，当群组“认真工作小组”对应的群聊通讯会话存在吉时红包时，可以通过在相应的会话页面入口的展示区域内示出提醒图标，比如该提醒图标可以为图16a所示的“红包”图标，使得用户b无需进入各个通讯会话对应的通讯会话页面，即可由会话列表页面确定所有包含发放时刻未超时的提醒红包的通讯会话。类似地，基于图16a所示的会话列表页面，用户“小白”对应的通讯会话中也存在发放时刻未超时的提醒红包。
进一步地，图16a所示的提醒图标可以被配置为可触发类型。那么，当检测到用户b对诸如群组“认真工作小组”对应的会话页面入口中的提醒图标进行触发时，可以示出如图16b所示的弹窗，并在该弹窗内示出“来自a的吉时红包”和“02小时59分20秒”的倒计时等，使用户b了解该吉时红包的来源用户和发放时刻的剩余时长等信息。
在本实施例中，由于图15a-15b所示的提醒页面，总是对通讯会话页面造成一定程度的遮挡，因而当客户端2检测到用户b触发该提醒页面右下角的“收起”选项时，可以关闭提醒页面，并示出一入口图标，例如该入口图标可以为图17所示的通讯会话页面后下角的“红包”图标。那么，当仅存在一个发放时刻未到达的“吉时红包”时，客户端2在检测到针对该入口图标的触发操作时，可以直接示出相应的提醒页面，即返回图15a或图15b所示的状态；而当同时存在多个发放时刻未到达的“吉时红包”时，客户端2在检测到针对该入口图标的触发操作时，可以示出图18所示的通知列表，该通知列表中包含已接收到且相应的发放时刻尚未超时的所有红包领取通知，使得用户b可以同时对该通知列表中的所有红包领取通知进行快速浏览，且每一红包领取通知在该通知列表中的展示区域内均可以示出上述的“提醒设置选项”，以便于快速创建或取消相应的提醒消息。
在本实施例中，无论是否创建上述的提醒消息，在当前时刻较之发放时刻提前第二预设时长时，可以在目标用户的客户端的其他显示内容之上，叠加展示针对该发放时刻的倒计时图标，直至到达该发放时刻。例如，假定该第二预设时长为10秒，则当来自用户a的吉时红包的倒计时到达最后10秒时，客户端2可以示出如图19所示的倒计时图标，且该倒计时图标叠加于客户端2所示的通讯会话页面等所有的其他显示内容之上，以便获得用户b的关注焦点，尤其是在红包数量小于目标用户的总数的情况下，可以有效避免用户b错过对该吉时红包的领取。当然，如果用户b需要处理更为紧急的事项，可以通过点击图19左上角的“退出”，以取消对相应的倒计时图标的显示。
在本实施例中，客户端2可以针对接收到的红包领取通知，在通讯会话页面中示出图20所示的红包消息；进一步地，当检测到针对该红包消息的触发操作时，客户端2可以示出图21所示的红包领取页面(相当于本申请中的“对象请求页面”)，而当检测到针对该红包领取页面中“收”选项的触发操作时，客户端2确定检测到针对红包领取通知的触发操作。而基于上文可知：本申请中的客户端2在发放时刻尚未到达之前，通过管理对红包领取通知的触发权限，以限制用户b对相应的红包资金的领取时刻，而客户端2可以通过多种方式来管理对红包领取通知的触发权限。以来自用户a的吉时红包为例：
一种情况下，在该吉时红包对应的发放时刻尚未到达之前，客户端2可以不示出图20所示的红包消息，使得用户b无法通过触发该红包消息；或者，客户端2可以示出图20所示的红包消息，但基于用户b对该红包消息的触发操作，不示出图21所示的红包领取页面，使得用户b无法触发该红包领取页面中“收”选项。总之，通过限制红包消息或红包领取页面的展示，客户端2不会检测到用户b对红包领取通知的触发操作。
另一种情况下，客户端2可以示出图20所示的红包消息，且基于用户b对该红包消息的触发操作，示出图21所示的红包领取页面，但是当用户b通过触发该红包领取页面中的“收”选项，以执行对红包领取通知的触发操作时，客户端2可以不响应于该触发操作。
当然，等待发放时刻到达后，客户端2通过开放用户b对红包领取通知的触发权限，可以在检测到用户b对红包领取通知的触发操作时，例如检测到针对图21所示的红包领取页面中的“收”选项进行触发操作时，客户端2可以向服务端发送相应的红包领取请求，以使得服务端将相应的红包资金的至少一部分发放至用户b。例如，当用户a采用图8所示的“拼手气红包”类型时，红包资金可以被随机分配至所有目标用户，那么假定客户端2根据服务端返回的领取结果通知，确定领取结果为用户b被发放了2.88元的红包资金，客户端2可以将该领取结果展示于图22所示的结果展示页面，以便于用户b了解相关情况。
其中，对应于图10所示的实施例，如果用户a在发放红包的过程中，通过客户端1考量了当前时刻对应的节日信息，例如由于当前时刻处于新年或附近时段，使得在图10所示的红包配置页面中配置了针对该节日信息的描述信息(包括图片“恭贺新年”和文字“新春快乐，事事顺利”等)，那么该描述信息可以被包含于步骤406的红包发放消息中，并进一步被包含于步骤412的红包领取通知中，使得客户端2可以示出图23所示的结果展示页面，其中展示有上述的图片“恭贺新年”、文字“新春快乐，事事顺利”等针对“新年”的描述信息，以替代图22所示的结果展示页面。当然，客户端2也可以将针对节日信息的描述信息展示于其他页面中，例如可以展示于红包领取页面中，本申请并不对此进行限制。
进一步地，以图22所示的结果展示页面为例，该结果展示页面中还可以示出预定义的留言信息，那么客户端2可以在检测到用户b对任一留言信息的选取操作时，将被选取的留言信息作为用户b输入的通讯内容，生成为相应的通讯消息并在相应的通讯会话页面中发出；例如，当用户b选取“多谢a，午饭能加鸡腿了”时，图24示出了已发送的相应通讯消息。需要指出的是：客户端2中预先定义了诸如“多谢*，午饭能加鸡腿了”的留言模板，并在接收到服务端发送的红包领取通知后，通过确定相应的来源用户的名称、使用该名称替换上述留言模板中的“*”，以得到相应的留言信息；而对于不包含用户名称的留言，客户端2只需要直接展示即可。那么，通过示出上述的留言信息，使得用户b在无需执行内容输入操作的情况下，可以通过对留言信息的简单选取，在相应的通讯会话页面中实现快速发言，有助于简化用户操作、提升通讯效率。
需要指出的是：除了图4所示的实施例中提供的权限管理方式之外，本申请还提出了其他处理方式，也可以限制用户b等目标用户对红包资金的领取时刻，使其不早于红包领取通知中包含的发放时刻。举例而言：
在一实施例中，在接收到红包发放消息后，服务端可以延迟至相应的发放时刻到达时，才向客户端2发送红包领取通知；由于已经到达发放时刻，因而客户端2只需要与相关技术相同地、无延迟地响应于用户b针对该红包领取通知的触发操作，即可确保用户b对红包资金的领取时刻不早于发放时刻。换言之，该实施例中由服务端通过控制对红包领取通知的发放，以限制用户b对红包资金的领取时刻，而无需客户端2采取特别的处理手段。
在另一实施例中，在接收到红包发放消息后，服务端可以无延迟地向客户端2发送红包领取通知，并在相应的发放时刻到达时开放用户b对红包资金的获取权限；换言之，无论客户端2采用各种处理手段，包括采用相关技术中的常规处理手段，或者采用图4所示实施例中的权限控制手段，总之由于服务端在发放时刻之前并未开放对红包资金的获取权限，因而即便客户端2在发放时刻之前向服务端发送红包领取请求，该红包领取请求也不会被服务端响应，因而用户b并不能够在发放时刻之前领取红包资金，从而将用户b对红包资金的获取时刻控制在不早于推荐时刻。
图25示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图25，在硬件层面，该电子设备包括处理器2502、内部总线2504、网络接口2506、内存2508以及非易失性存储器2510，当然还可能包括其他业务所需要的硬件。处理器2502从非易失性存储器2510中读取对应的计算机程序到内存2502中然后运行，在逻辑层面上形成对象分配装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图26，在软件实施方式中，该对象分配装置可以包括配置单元2601和发送单元2602。其中：
配置单元2601，根据分配来源方的客户端接收到的对象分配请求，配置待分配的对象数量和对象分配时刻；
发送单元2602，向服务端发送对象分配消息，所述对象分配消息中包含所述待分配的对象数量和所述对象分配时刻；其中，所述待分配的对象数量用于指示所述服务端从所述分配来源方对应的对象集合中提取相应数量的待分配对象，以及所述对象分配时刻用于指示所述服务端控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
可选的，所述配置单元2601通过下述方式配置所述待分配的对象数量：
获取所述对象分配请求中包含的待分配的对象数量；
或者，由所述分配来源方的客户端生成符合预定义的数量推荐规则的推荐数量，以作为所述待分配的对象数量。
可选的，所述配置单元2601通过下述方式配置所述对象分配时刻：
获取所述对象分配请求中包含的对象分配时刻；
或者，由所述分配来源方的客户端生成符合预定义的时刻推荐规则的推荐时刻。
可选的，所述配置单元2601通过下述方式生成符合预定义的时刻推荐规则的推荐时刻：
当所述时刻推荐规则包括对第一特征数值的推荐条件时，生成每一时刻位均为所述第一特征数值的所述推荐时刻；
当所述时刻推荐规则包括对第二特征数值的弃用条件时，生成每一时刻位均避免使用所述第二特征数值的所述推荐时刻。
可选的，所述配置单元2601通过下述方式生成符合预定义的时刻推荐规则的推荐时刻：
接收到所述服务端发送的提示消息，所述提示消息包含与所述分配来源方的任一关联用户相关的日期信息；
当所述时刻推荐规则包括对所述日期信息的应用条件时，在检测到针对所述提示消息的响应操作的情况下，生成与所述日期信息相关的所述推荐时刻。
可选的，所述配置单元2601通过下述方式生成符合预定义的时刻推荐规则的推荐时刻：
当所述对象分配请求是针对所述分配来源方所属的任一群组而发起时，根据所述任一群组中的其他群组成员向所述服务端发送的对象分配消息，确定出相应的已采用推荐时刻；
生成符合所述时刻推荐规则且区别于所述已采用推荐时刻的推荐时刻。
可选的，还包括：
信息确定单元2603，确定所述对象分配请求的接收时刻对应的节日信息；
获取单元2604，获取与所述节日信息相关的描述信息；
记载单元2605，在所述对象分配消息中记载所述描述信息，以指示所述分配目标方的客户端在与获取所述待分配对象相关的页面内示出所述描述信息。
图27示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图27，在硬件层面，该电子设备包括处理器2702、内部总线2704、网络接口2706、内存2708以及非易失性存储器2710，当然还可能包括其他业务所需要的硬件。处理器2702从非易失性存储器2710中读取对应的计算机程序到内存2702中然后运行，在逻辑层面上形成对象分配装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图28，在软件实施方式中，该对象分配装置可以包括确定单元2801、提取单元2802和控制单元2803。其中：
确定单元2801，根据服务端接收到的对象分配消息，确定分配来源方、待分配的对象数量和对象分配时刻；
提取单元2802，从所述分配来源方对应的对象集合中，提取对应于所述待分配的对象数量的待分配对象；
控制单元2803，在将所述待分配对象分配至分配目标方时，控制所述分配目标方对所述待分配对象的获取时刻，使所述获取时刻不早于所述对象分配时刻。
可选的，所述控制单元2803具体用于：
在接收到所述对象分配消息后，延迟至所述对象分配时刻到达时，向所述分配目标方的客户端发送针对所述待分配对象的第一获取通知，所述第一获取通知用于指示所述分配目标方的客户端无延迟地响应于针对所述第一获取通知的触发操作；
或者，在接收到所述对象分配消息后，无延迟地向所述分配目标方的客户端发送针对所述待分配对象的第二获取通知，所述第二获取通知中包含所述对象分配时刻，用于指示所述分配目标方的客户端延迟至所述对象分配时刻时，开放所述分配目标方对所述第二获取通知的触发权限；
或者，在接收到所述对象分配消息后，无延迟地向所述分配目标方的客户端发送针对所述待分配对象的第三获取通知，并在所述对象分配时刻到达时开放所述分配目标方对所述待分配对象的获取权限。
可选的，还包括：
处理单元2804，当接收到同一群组的多个群组成员分别针对所述群组发送的对象分配消息，且多条对象分配消息对应的对象分配时刻相同时，保留待分配的对象数量最大的对象分配消息，并取消对所述多条对象分配消息中的其他对象分配消息的处理。
图29示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图29，在硬件层面，该电子设备包括处理器2902、内部总线2904、网络接口2906、内存2908以及非易失性存储器2910，当然还可能包括其他业务所需要的硬件。处理器2902从非易失性存储器2910中读取对应的计算机程序到内存2902中然后运行，在逻辑层面上形成对象分配装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图30，在软件实施方式中，该对象分配装置可以包括确定单元3001、管理单元3002和发送单元3003。其中：
确定单元3001，根据分配目标方的客户端接收到的来自服务端的获取通知，确定所述获取通知中包含的对象分配时刻；其中，所述获取通知用于将来自分配来源方的待分配对象分配至所述分配目标方，且所述对象分配时刻由所述分配来源方配置得到；
管理单元3002，当所述对象分配时刻尚未到达时，限制所述分配目标方对所述获取通知的触发权限；当所述对象分配时刻到达时，开放所述分配目标方对所述获取通知的触发权限；
发送单元3003，当所述触发权限已开放时，根据检测到的对所述获取通知的触发操作，向所述服务端发送对象获取请求，以获取所述待分配对象的至少一部分。
可选的，还包括：
页面示出单元3004，当接收到所述获取通知时，示出相应的提醒页面，所述提醒页面中包含提醒设置选项；
创建单元3005，当检测到所述提醒设置选项被触发时，创建针对所述获取通知的提醒消息；其中，所述提醒消息的提醒时刻较之所述对象分配时刻提前第一预设时长、提醒对象为所述分配目标方。
可选的，还包括：
倒计时展示单元3006，在当前时刻较之所述对象分配时刻提前第二预设时长时，在所述分配目标方的客户端的其他显示内容之上，叠加展示针对所述对象分配时刻的倒计时图标，直至到达所述对象分配时刻。
可选的，还包括：
图标示出单元3007，在所述分配目标方的客户端内示出一入口图标；
列表展示单元3008，当检测到所述入口图标被触发时，展示相应的通知列表，所述通知列表中包含已接收到且相应的对象分配时刻尚未超时的所有获取通知。
图31是本申请一示例性实施例提供的基于服务端的另一种对象分配方法的流程图。如图31所示，该方法应用于预设通讯应用的服务端，可以包括以下步骤：
步骤3102，向任一群组的群组成员发送资源推荐消息，所述资源推荐消息中包含符合预定义资源推荐规则的操作资源的信息。
步骤3104，接收至少一个群组成员针对所述资源推荐消息返回的资源申请消息，所述资源申请消息中包含针对所述操作资源的对象提供量。
步骤3106，将所述操作资源的使用权限赋予最大对象提供量对应的特定群组成员，以使所述特定群组成员利用所述操作资源实现针对所述任一群组的对象分配操作。
在本实施例中，服务端通过向任一群组的群组成员发送资源推荐消息，可使该任一群组的群组成员对同一操作资源进行竞争，从而将对操作资源的使用权限赋予需求更加强烈的群组成员，以便于实现对操作资源的合理赋予和分配。
在本实施例中，操作资源包括以下至少之一：时刻资源、时间段资源、地理位置资源；当然，还可以包括用于执行对象分配操作的其他操作资源，本申请并不对此进行限制。例如，当操作资源包括时刻资源时，只有被赋予相应的操作权限的群组成员，才能够在该时刻资源对应的时刻执行针对相应群组的对象分配操作，而相应群组的其他群组成员不能够使用该时刻资源，只能够在其他时刻执行针对该群组的对象分配操作。类似地，当操作资源包括时间段资源时，只有被赋予相应的操作权限的群组成员，才能够在该时间段资源对应的时间段执行针对相应群组的对象分配操作；以及，当操作资源包括地理位置资源时，只有被赋予相应的操作权限的群组成员，才能够在该地理位置资源对应的地理位置执行针对相应群组的对象分配操作，此处不再赘述。
以“发红包”场景为例。假定针对企业即时通讯应用“钉钉”中的群组“认真工作小组”，服务端(即钉钉服务端)可以按照预定义资源推荐规则确定相应的操作资源的信息；例如，当操作资源为时刻资源时，该预定义资源推荐规则可以为本申请的上述实施例中预定义的时刻推荐规则，而确定出的操作资源可以为上述的推荐时刻。举例而言，当预定义的时刻推荐规则包括对第一特征数值的推荐条件时，例如该第一特征数值为“吉时数字”，则上述的推荐时刻可以为“吉时”(需要指出的是：“吉时”可由服务端按照时刻推荐规则主动计算出，也可以由预设用户手动设置，只要符合该时刻推荐规则即可)，下面就以服务端确定出的操作资源为“吉时”为例进行说明：
假定用户a为群组“认真工作小组”的群组成员，图32可以为该用户a的钉钉客户端示出的相应群聊通讯会话页面，且该群聊通讯会话页面可以示出服务端发送的资源推荐消息的内容，该内容可以包括“吉时：18:18:18”以及针对该吉时的触发选项(比如图32中显示为“我要拍”选项)。当检测到针对“我要拍”选项的触发操作时，可以示出图33所示的竞拍页面(比如图33中采用了“窗口”形式的竞拍页面)，使得用户a可以对“您的出价”进行配置；进一步地，钉钉客户端在检测到“确认竞拍”选项的触发操作后，可以向服务端返回竞拍消息(相当于本申请中的“资源申请消息”)，该竞拍消息中包含用户a针对吉时“18:18:18”配置的出价(相当于本申请中的“对象提供量”)。
服务端可以接收到各个群组成员返回的竞拍消息，并获知每一群组成员配置的出价，则服务端可以将吉时“18:18:18”的使用权限赋予出价最高的群组成员。例如，当用户a的出价最高时，服务端可以向用户a发送如图34所示的竞拍成功通知，通知其“恭喜您竞拍成功！”，则用户a可以通过触发该竞拍成功通知(比如触发图34所示的“吉时红包”选项)而切换至诸如图14a所示的红包配置页面(或其他类型的红包配置页面，但需要支持“吉时发送”功能)，且“吉时发送”功能可以被自动配置为竞拍得到的“18:18:18”，且金额被自动配置为用户a的出价“188.88元”，且用户a应当不能主动修改“吉时”和“金额”；当然，如果允许用户a对“吉时”和“金额”进行修改，则钉钉客户端可以将该红包作为普通的吉时红包进行发送，而不占用上述竞拍得到的吉时“18:18:18”的使用权限。
服务端可以对吉时竞拍设置一定的竞拍规则，以提升竞拍效率。例如在一种情况下，服务端可以规定为：等待群组“认真工作小组”中的每一群组成员均配置了相应的出价后，选取最大出价对应的群组成员，以赋予相应吉时的使用权限；其中，每一群组成员可以具有n次出价机会(n为不小于1的整数；其中，当n＝1时表明不允许群组成员修改出价，当n＞1时表明允许群组成员可以对出价进行n-1次修改)。在另一种情况下，服务端可以为吉时竞拍设置一竞拍时间段，例如图33所示的竞拍页面中包含该竞拍时间段的“剩余时间”为“00:04:58”，表明相应的吉时竞拍在4分58秒后结束，而服务端在时间段结束后选取最大出价对应的群组成员，以赋予相应吉时的使用权限；其中，每一群组成员可以在竞拍时间段内对出价进行至少一次修改。
以设有“竞拍时间段”为例。在用户a完成出价后，可以示出图35所示的实时竞拍信息，可以包括用户a的“实时竞拍排名”、“出价”以及“剩余时间”等信息。当然，如果用户a的出价排名并非第一时，如图36所示，实时竞拍信息可以包括“我要改价”选项，使得用户a可以通过触发该选项，转入诸如图33所示的竞拍页面修改出价。而当用户a的出价排名原本为第一，但是后续被其他用户超越时，实时竞拍信息可以包括图37所示的“您的出价已被超越！”，并提供“更新出价”选项，使得用户a可以据此转入诸如图33所示的竞拍页面修改出价。
除了手动调整出价之外，还可以配置钉钉客户端自动调整价格。例如图38所示，竞拍页面中可以包括“势在必得”选项，则当用户a选中该选项时，竞拍页面中可以进一步提供“每次加价”和“最大金额”选项，则服务端可以据此自动配置用户a的出价。例如，当每次加价1元、最大金额200元时，如果存在其他用户的出价高于用户a的出价，则只要其他用户的出价未超出用户a设置的最大金额200元，服务端可以按照1元为单位，自动更新用户a的出价；比如，假定用户a的原始出价为188.88，而另一用户h的出价为190，那么由于190＞188.88，服务端可以将原始出价+1更新为189.88＜190且189.88＜200，服务端继续+1更新为190.88＞190且190.88＜200，则服务端停止更新用户a的出价，而用户a的出价最终被更新为190.88且不存在其他更高出价，以确保用户a能够竞拍到相应吉时的使用权限。
假定针对群组“认真工作小组”的吉时“18:18:18”的使用权限被赋予用户a，即用户a可以在吉时“18:18:18”在群组“认真工作小组”内发送红包。那么，服务端在后续接收到针对群组“认真工作小组”的红包发放消息时，通过确定相应的来源用户和被申请的吉时，如果发现诸如用户f向服务端申请对吉时“18:18:18”的使用权限(即被申请的操作资源的使用权限已被赋予，且被赋予者区别于分配来源方)，则由于吉时“18:18:18”的使用权限已经被赋予用户a，因而服务端可以取消对来自用户f的红包发放消息的处理，即用户f不能够在吉时“18:18:18”在群组“认真工作小组”内发送红包；当然，如果用户f向服务端申请其他的使用权限尚未被赋予的吉时，则服务端可以将被申请的吉时的使用权限赋予用户f。
正如上文所述，本申请中的操作资源除了时刻资源之外，还可以包括其他多种资源类型。例如，当操作资源包括时间段资源时，对于上述的“发红包”场景，如果群组“认真工作小组”的某一时间段的使用权限被赋予用户a，则只有用户a可以在该时间段内在群组“认真工作小组”内发红包，而其他用户在该时间段内在群组“认真工作小组”的发红包行为则被限制，这与上述的“吉时红包”相似，此处不再赘述。
再比如，当操作资源包括地理位置资源时，可以实现与上述的“吉时红包”相似的“地点红包”。图39所示，服务端可以基于预定义资源推荐规则确定出相应的地点(该地点可由服务端基于预定义资源推荐规则进行主动计算；或者，该地点也可以由预设用户手动设置，例如该预设用户可以为群主或群组管理员等)，例如该地点可以为图39中的“xx大厦”，而群组“认真工作小组”的群组成员需要在该地点召开年会，那么该群组“认真工作小组”中的用户a等群组成员可以通过触发图39所示的“我来承包”选项，以实现对地点“xx大厦”的使用权限的竞拍。举例而言，假定用户a竞拍得到地点“xx大厦”的使用权限，则召开年会期间只能够由用户a在该地点“xx大厦”周围的一定范围内，在群组“认真工作小组”内执行发红包操作，而限制其他群组成员处于该范围内时在群组“认真工作小组”内执行发红包操作。其中，具体的竞拍过程可以参考上述的“吉时竞拍”，此处不再赘述。
图40示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图40，在硬件层面，该电子设备包括处理器4002、内部总线4004、网络接口4006、内存4008以及非易失性存储器4010，当然还可能包括其他业务所需要的硬件。处理器4002从非易失性存储器4010中读取对应的计算机程序到内存4002中然后运行，在逻辑层面上形成对象分配装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图41，在软件实施方式中，该对象分配装置可以包括发送单元4101、接收单元4102和赋予单元4103。其中：
发送单元4101，向任一群组的群组成员发送资源推荐消息，所述资源推荐消息中包含符合预定义资源推荐规则的操作资源的信息；
接收单元4102，接收至少一个群组成员针对所述资源推荐消息返回的资源申请消息，所述资源申请消息中包含针对所述操作资源的对象提供量；
赋予单元4103，将所述操作资源的使用权限赋予最大对象提供量对应的特定群组成员，以使所述特定群组成员利用所述操作资源实现针对所述任一群组的对象分配操作。
可选的，所述操作资源包括以下至少之一：
时刻资源、时间段资源、地理位置资源。
可选的，还包括：
确定单元4104，根据接收到的针对所述任一群组的对象分配消息，确定分配来源方和被申请的操作资源的信息；
处理单元4105，当所述被申请的操作资源的使用权限已被赋予，且被赋予者区别于所述分配来源方时，取消对所述对象分配消息的处理；当所述被申请的操作资源的使用权限尚未被赋予时，将所述被申请的操作资源的使用权限赋予所述分配来源方。
图42是本申请一示例性实施例提供的基于服务端的又一种对象分配方法的流程图。如图42所示，该方法应用于预设通讯应用的服务端，可以包括以下步骤：
步骤4202，当接收到分配来源方的客户端发送的对象预分配请求时，若所述对象预分配请求的发送方用户被验证为所述分配来源方，则记录所述对象预分配请求包含的预分配的对象数量。
在本实施例中，相关技术中的所有身份验证手段，均可以应用于本实施例中。例如，该对象预分配请求的发送方用户可以通过分配来源方的客户端，向服务端发送验证密码，则服务端通过将该验证密码与对应于分配来源方的预定义密码进行匹配，即可识别出该对象预分配请求的发送方用户是否为该分配来源方；或者，当分配来源方的客户端运行于该分配来源方使用的电子设备上时，该分配来源方的客户端可以调用该电子设备的指纹识别模块，以对该对象预分配请求的发送方用户进行身份识别，然后由该分配来源方的客户端将识别结果上报至服务端。
在本实施例中，以“发红包”场景为例。当用户a希望通过诸如钉钉客户端1向用户b发送红包时，由于需要将用户a的账户内资金转移至用户b的账户，因而服务端需要确保发送红包的用户为该用户a自身，以避免用户a的电子设备遗失或账号被窃用后，由他人冒充用户a进行资金转移。因此，通过上述的身份验证手段，服务端可以确定发送红包的用户是否为该用户a自身。
步骤4204，当接收到所述分配来源方的客户端针对任一通讯会话发送的对象分配消息时，确定所述对象分配消息中包含的待分配的对象数量。
步骤4206，当所述待分配的对象数量不大于所述预分配对象的剩余数量时，免除对所述对象分配消息的发送方用户的身份验证，并从所述分配来源方对应的对象集合中提取对应于所述待分配的对象数量的待分配对象，以供分配至分配目标方。
在本实施例中，服务端通过在完成身份验证后，记录对象预分配请求包含的预分配的对象数量，相当于对相应数量的对象进行了预授权，因而在后续接收到的对象分配消息中包含的待分配的对象数量不大于记录的预分配的对象数量时，表明该对象分配消息所请求的对象属于上述的“预授权”范围内，无需执行身份验证，而直接判定该对象分配消息的发送方用户为上述的分配来源方。
实际上，只要对象分配消息所请求的对象未超出上述的“预授权”范围，均可以认为该对象分配消息已被授权，因而无需分配来源方反复参与到身份验证过程中，可以极大地简化分配来源方的操作。当应用于“发红包”场景时，用户a只需要事先通过一次身份验证，并对一定数额的资金进行“预授权”，那么后续发送的红包金额只要未超出“预授权”范围内的资金额度，即可免去相应的身份验证过程，从而简化用户a的操作；例如，用户a可以事先对100元进行“预授权”，那么用户a后续每次发送红包之后，服务端可以从该100元中减去相应的红包金额，使得下次发送的红包金额如果未超出“预授权”的剩余资金，即可无需身份验证地发出红包，而如果下次发送的红包资金超出“预授权”的剩余资金，则需要正常完成身份验证后才能够发出红包。
在本实施例中，对象预分配请求可以针对分配来源方参与的特定通讯会话。那么，服务端在接收到分配来源方的客户端发送的对象分配消息时，需要根据该对象分配消息针对的通讯会话，确定出该通讯会话对应的预分配对象的剩余数量，并据此确定是否需要对该对象分配消息的发送方用户进行身份验证。
或者，对象预分配请求可以针对分配来源方参与的所有通讯会话。那么，服务端在接收到分配来源方的客户端发送的对象分配消息时，无论该对象分配消息针对的通讯会话为何，均根据对象预分配请求对应的预分配对象的剩余数量，确定是否需要对该对象分配消息的发送方用户进行身份验证。
需要指出的是：图42所示的实施例，可以应用于本申请的上述所有技术方案中(例如图2所示实施例中的步骤204)，使得：当服务端接收到分配来源方的客户端发送的对象分配消息时，可以将相应的待分配的对象数量与预分配对象的剩余数量进行比较，从而当待分配的对象数量不大于预分配对象的剩余数量时，无需对对象分配消息的发送方用户进行身份验证即可从分配来源方对应的对象集合中提取对应于该待分配的对象数量的待分配对象；以及，当待分配的对象数量大于预分配对象的剩余数量，或者不存在预分配对象时，需要在对象分配消息的发送方用户通过身份验证后，才允许从分配来源方对应的对象集合中提取对应于该待分配的对象数量的待分配对象。
图43示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图43，在硬件层面，该电子设备包括处理器4302、内部总线4304、网络接口4306、内存4308以及非易失性存储器4310，当然还可能包括其他业务所需要的硬件。处理器4302从非易失性存储器4310中读取对应的计算机程序到内存4302中然后运行，在逻辑层面上形成对象分配装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图44，在软件实施方式中，该对象分配装置可以包括记录单元4401、确定单元4402和提取单元4403。其中：
记录单元4401，当接收到分配来源方的客户端发送的对象预分配请求时，若所述对象预分配请求的发送方用户被验证为所述分配来源方，则记录所述对象预分配请求包含的预分配的对象数量；
确定单元4402，当接收到所述分配来源方的客户端针对任一通讯会话发送的对象分配消息时，确定所述对象分配消息中包含的待分配的对象数量；
提取单元4403，当所述待分配的对象数量不大于所述预分配对象的剩余数量时，免除对所述对象分配消息的发送方用户的身份验证，并从所述分配来源方对应的对象集合中提取对应于所述待分配的对象数量的待分配对象，以供分配至分配目标方。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。