CN111951118A - 用户社交功能调整方法、设备及计算机可读介质 - Google Patents

Abstract

本申请提供了一种用户社交功能调整方案，该方案中用户无需等待审核即可请求限制其它用户的预设社交功能，提升了用户体验，而被限制的用户也可以请求解除限制，服务端设备通过控制发放的道具数量，平衡双方用户的请求次数，在能够对不良用户进行有效控制的同时，避免判定和处理的权利被恶意使用。

Description

用户社交功能调整方法、设备及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种用户社交功能调整方法、设备及计算机可读介质。

背景技术

随着互联网技术的不断发展，互联网公司提供各种各样的社交应用产品，用户通过所述社交应用产品可以与其它用户沟通，以实现各类社交需求。但是在各个社交平台中，也会存在一些恶意用户，此类用户会在社交过程中进行一些干扰其它用户正常使用的社交行为，例如语言骚扰、诈骗等行为。目前能准确、有效的打击此类恶意用户的方法主要是由其它用户的举报，通过对这些举报进行审核，在举报核实之后，对这些恶意用户采取相应的措施，例如禁言、封号等。

然而，在实际场景中，上述方式的处理流程较为繁琐，对于受干扰的用户而言，需要等待一个较长的审核时间之后才能够获得对恶意用户的处理结果，用户体验较差。并且对于社交平台而言，为了确保审核的准确性，审核过程中需要投入大量的人力来进行人工审核，因此会使得运营成本大大提升。

发明内容

本申请的一个目的是提供一种用户社交功能调整方法、设备及计算机可读介质。

为实现上述目的，本申请的一些实施例提供了一种用户社交功能调整方法，该方法包括：

服务端设备根据针对第一用户的封禁请求，对第一用户的预设社交功能进行限制，所述封禁请求来自于所述第一用户外的第二用户，所述第二用户发起封禁请求的次数受限于所述第二用户的封禁道具的数量，所述封禁道具由所述服务端设备根据第二规则向第二用户发放；

服务端设备根据来自第一用户的解封请求，解除对第一用户的预设社交功能的限制，或在限制时长达到预设值之后解除对第一用户的预设社交功能的限制，所述第一用户发起解封请求的次数受限于所述第一用户的解封道具的数量，所述解封道具由所述服务端设备根据第一规则向第一用户发放。

本申请的一些实施例还提供了另一种用户社交功能调整方法，该方法包括：

第二用户设备向服务端设备发送根据针对第一用户的封禁请求，以使服务端设备根据所述封禁请求，对第一用户的预设社交功能进行限制，所述第二用户设备为第二用户使用的设备，所述第二用户发起封禁请求的次数受限于所述第二用户的封禁道具的数量，所述封禁道具由所述服务端设备根据第二规则向第二用户发放。

本申请的一些实施例还提供了另一种用户社交功能调整方法，该方法包括：

第一用户设备向服务端设备发送解封请求，以使所述服务端设备根据所述解封请求，解除对第一用户的预设社交功能的限制，所述第一用户设备为第一用户使用的设备，所述第一用户发起解封请求的次数受限于所述第一用户的解封道具的数量，所述解封道具由所述服务端设备根据第一规则向第一用户发放。

此外，本申请实施例还提供了一种用户社交功能调整设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述用户社交功能调整方法。

本申请实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述用户社交功能调整方法。

本申请的一些实施例提供了一种用户社交功能调整方案，该方案中服务端设备根据针对第一用户的封禁请求，对第一用户的预设社交功能进行限制，然后可以根据来自第一用户的解封请求，解除对第一用户的预设社交功能的限制，或在限制时长达到预设值之后解除对第一用户的预设社交功能的限制。不同于举报审核的机制，本申请的方案是将是否为恶意用户的判定和处理的权利，有条件地移交给社交平台的用户，所述第二用户发起封禁请求的次数受限于所述第二用户的封禁道具的数量，所述封禁道具由所述服务端设备根据第二规则向第二用户发放，所述第一用户发起解封请求的次数受限于所述第一用户的解封道具的数量，所述解封道具由所述服务端设备根据第一规则向第一用户发放。由此，用户无需等待审核即可请求限制其它用户的预设社交功能，提升了用户体验，而被限制的用户也可以请求解除限制，服务端设备通过控制发放的道具数量，平衡双方用户的请求次数，在能够对不良用户进行有效控制的同时，避免判定和处理的权利被恶意使用。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为申请实施例提供的一种用户社交功能调整方法中各个设备之间的交互过程示意图；

图2为本申请实施例的方案应用于社交应用场景时的交互示意图；

图3为本申请实施中实现用户社交功能调整的计算设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

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

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种用户社交功能调整方案，该方案不同于举报审核的机制，将是否为恶意用户的判定和处理的权利，有条件地移交给社交平台的用户，由此，用户无需等待审核即可请求限制其它用户的预设社交功能，提升了用户体验，而被限制的用户也可以请求解除限制，服务端设备通过控制发放的道具数量，平衡双方用户的请求次数，在能够对不良用户进行有效控制的同时，避免判定和处理的权利被恶意使用。

图1示出了本申请实施例在实现用户社交功能调整时各个设备之间的交互过程，该交互过程涉及第一用户设备110、第二用户设备130和服务端设备130。其中，第一用户设备为第一用户所使用的用户设备，相应地，第二用户设备为第二用户所使用的用户设备，包括但不限于计算机、手机、平板电脑、智能手表等各类终端设备，所述终端设备上可运行有具有社交功能的客户端程序，以完成相应的处理以及与用户、其它设备之间的交互逻辑。在实现一次用户社交功能调整的过程中，所述第一用户即为被其它用户请求封禁的用户，所述第二用户即为请求封禁其它用户的用户。所述服务端设备可以包括但不限于网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现，在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。在所述服务端设备中可以运行有可实现社交功能的服务端程序，以完成相应的处理以及其它设备之间的交互逻辑。

实现用户社交功能调整时，第一用户设备110、第二用户设备130和服务端设备130之间的交互过程至少包括了如下所示的步骤：

步骤S101，第二用户设备向服务端设备发送根据针对第一用户的封禁请求。

步骤S102，服务端设备根据针对第一用户的封禁请求，对第一用户的预设社交功能进行限制。

所述封禁请求用于对第一用户的预设社交功能进行限制，其中，所述预设社交功能可以根据实际应用场景的不同设定为不同的具体功能，例如，对于即时通信应用而言，预设社交功能可以是发送即时通信消息的功能、在社交平台发布分享信息的功能、添加好友的功能、或者是登录应用账号的功能等部分或全部社交功能。还如，对于UGC(UserGenerated Content，用户生成内容)平台类的应用而言，预设社交功能则可以是发布新内容的功能、对其它用户发布的内容进行评论的功能等。在此，本领域技术人员应当理解，前述预设社交功能的具体内容仅为举例，现有或今后出现的基于类似原理的其它形式如果能够适用于本申请，也应该包含在本申请的保护范围内，并以引用的形式包含于此。例如，可以对特定功能从时间、业务范围等维度上进行进一步的细分，以发送即时通信消息的功能为例，对用户的该社交功能进行限制可以理解为“禁言”，对其从时间上细分之后，可以是禁言1小时、禁言1天、永久禁言等；对其从业务范围上细分之后，可以是在对某一用户禁言、在某一频道禁言、全频道禁言等。

为了避免第二用户对封禁功能的滥用，所述第二用户发起封禁请求的次数受限于所述第二用户的封禁道具的数量。例如，可以设定第二用户每次发起封禁请求时，都需要消耗对应数量的封禁道具，如一个封禁道具，而当封禁道具数量为零时，无法继续发起封禁请求。而所述封禁道具由所述服务端设备根据第二规则向第二用户发放。由此，可以通过设定合适的第二规则，控制用户拥有的封禁道具数量，进而控制第二用户发起封禁请求的次数，避免第二用户对封禁功能的滥用。

在本申请的一些实施例中，所述第二规则的具体形式可以包括几种：

其中，一种形式为服务端设备可以在经过第一预设时间间隔后，向第二用户发放预设数量的封禁道具，即服务端设备根据时间主动向用户发放封禁道具，其中，所述第一预设时间间隔可以根据实际场景的需要，设定为基于特定的时间计算获得，例如可以是系统时间或者是用户使用社交应用的时间等。以24小时的预设时间间隔为例，若基于用户使用社交应用的时间，则服务端设备会统计用户的使用社交应用的时间，若时间达到24小时，则确定已经达到第一预设时间间隔，此时自动向第二用户的帐号发放一个封禁道具。若以系统时间为例，则服务端设备无需统计用户的使用社交应用的时间，直接读取系统时间，判断是否距离上次发放已经达到24小时，若已经达到24小时，则自动向第二用户的帐号发放一个封禁道具。

另一种形式为服务端设备可以在经过第二预设时间间隔后，向第二用户开放用于获取封禁道具的一次请求权限，以使所述第二用户在具有请求权限时，向所述服务端设备发送封禁道具获取请求，并且服务端设备根据来自第二用户的封禁道具获取请求，向第二用户发放预设数量的封禁道具。其中，所述第二预设时间间隔与所述第一预设时间间隔类似，也可以根据实际场景的需要进行设定。相较于前一种方式，此种方式中服务端设备并非主动向用户发放封禁道具，而是仅根据时间向用户开放请求权限，被动地向基于请求权限发送请求的用户发放封禁道具。例如，仍以24小时的预设时间间隔为例，若基于系统时间计算时间间隔，则服务端设备读取系统时间后可以判断是否距离上次发放已经达到24小时，若已经达到24小时，则自动向第二用户开放用于获取封禁道具的一次请求权限，通知第二用户可以向服务端设备发送一次封禁道具获取请求，而服务端设备收到该封禁道具获取请求，会向第二用户的帐号发放封禁道具。

此外，第三种方式可以是通过一定的方式为第二用户发放虚拟代币，使得第二用户发送封禁道具获取请求的次数受限于所述第二用户的虚拟代币的数量，服务端设备根据来自第二用户的封禁道具获取请求，向第二用户发放预设数量的封禁道具。例如，虚拟代币可以是对应应用程序中的金币、积分、点券等，用户每次向服务端设备发送封禁道具获取请求时，都需要消耗一定数量的虚拟代币，如50金币、30积分、30个点券等，当虚拟代币的数量不足时，则无法发送封禁道具获取请求。

在此，本领域技术人员应当理解，前述第二规则的具体形式仅为举例，现有或今后出现的基于类似原理的其它形式如果能够适用于本申请，也应该包含在本申请的保护范围内，并以引用的形式包含于此。并且，上述第二规则的多种具体形式在没有冲突的情况下，也可以组合使用，例如封禁道具获取请求的发送可以同时受限于请求权限和虚拟代币，即第二用户设备只有在具有请求权限时，通过消耗虚拟代币来向所述服务端设备发送封禁道具获取请求。

在本申请的一些实施例中，无论是基于预设时间间隔主动向用户发放封禁道具，还是向用户开放请求权限被动地向用户发放封禁道具，都可以进一步结合第二用户的历史行为信息。由此，服务端设备在向第二用户发放预设数量的封禁道具时，可以向历史行为信息满足第二条件的第二用户发放预设数量的封禁道具；而在向第二用户开放用于获取封禁道具的一次请求权限时，可以向历史行为信息满足第二条件第二用户开放用于获取封禁道具的一次请求权限。

所述历史行为信息用于表示用户在历史时间区间内使用社交应用时的行为。其中，所述历史时间区间可以根据实际场景的需求设定，如过去的一周内、过去的一个月内等，通过所述历史行为信息可以确定用户在过去一段时间内使用社交应用时的某些行为，例如，用户在过去一周内或者是一个月内是否被其它用户封禁过，是否有过其它违规行为等。若本申请实施例中将第二条件设定为：在过去一段时间内没有被其它用户封禁过、或者没有过违规行为，则可以避免向经常违规的用户发放封禁道具，而仅向行为良好的用户发放封禁道具，降低封禁被滥用的可能性，提升用户体验。

在实际场景中，第二用户设备可以根据第二用户输入的封禁操作，向服务端设备发送根据针对第一用户的封禁请求。根据实际场景中人机交互方式的不同，所述封禁操作可以是点击、滑动、悬空手势或者是带动用户设备的沿预设轨迹移动的操作等。

以即时通信应用的场景为例，第二用户可能会在聊天过程中感受到来自对方用户的冒犯时，输入封禁操作，如点击对方用户的头像后在跳转的界面中点击“禁言”按钮，从而控制向服务端设备发送根据针对对方用户的封禁请求，请求服务端设备禁止对方用户发送即时通信消息的功能。

对于普通用户而言，其最终的目的都是希望社交环境能够更为和谐，因此为了使得请求封禁的手段具有更好的制止效果，提升聊天体验，也可以在输入封禁操作之前，先通过发送警告消息的方式，警告对方用户不要在继续发送冒犯言论。为了更好地提升用户的使用体验，第二用户设备可以设置一条或多条预设的警告消息，在用户需要时直接提供给用户选取使用，例如可以预设一条警告消息“请不要在继续当前的话题，否则我将使用封禁道具对你禁言！”，当用户需要使用时，可以点击选取该警告消息，快速发送给对方用户。

由于第二用户发送封禁请求后，服务端设备不会对实际封禁请求是否合理进行实质的审核，因此在事实上难以避免一部分第二用户的滥用导致部分第一用户遭到不必要的社交功能限制。因此，本申请实施例提供的方案中，为第一用户提供了相应的救济手段，即第一用户可以在一定程度上对自身的封禁进行解封，如图1中的步骤S103和S104所示：

步骤S103，第一用户设备向服务端设备发送解封请求。

步骤S104，服务端设备根据来自第一用户的解封请求，解除对第一用户的预设社交功能的限制。

类似地，为了避免第一用户可以随意使用解封功能，导致第二用户的封禁功能失去威慑效果，所述第一用户发起解封请求的次数受限于所述第一用户的解封道具的数量。例如，可以设定第一用户每次发起解封请求时，都需要消耗一个解封道具，而当解封道具数量为零时，无法继续发起解封请求。而所述解封道具由所述服务端设备根据第一规则向第一用户发放。由此，可以通过设定合适的第一规则，控制用户拥有的解封道具数量，进而控制第一用户发起解封请求的次数，达到解封和封禁之间的动态平衡，在能够抵消部分第二用户对封禁功能滥用的情况下，避免封禁功能失去对威慑效果。

在本申请的一些实施例中也提供了几种第一规则的具体形式，类似于第二规则，所述第一规则也可以至少包括以下的几种：

其中，一种形式为服务端设备可以在经过第三预设时间间隔后，向第一用户发放预设数量的解封道具，即服务端设备根据时间主动向用户发放解封道具，其中，所述第三预设时间间隔可以根据实际场景的需要，设定为基于特定的时间计算获得，例如可以是系统时间或者是用户使用社交应用的时间等。以36小时的预设时间间隔为例，若基于用户使用社交应用的时间，则服务端设备会统计用户的使用社交应用的时间，若时间达到36小时，则确定已经达到第三预设时间间隔，此时自动向第一用户的帐号发放一个解封道具。若以系统时间为例，则服务端设备无需统计用户的使用社交应用的时间，直接读取系统时间，判断是否距离上次发放已经达到36小时，若已经达到36小时，则自动向第一用户的帐号发放一个解封道具。

另一种形式为服务端设备可以在经过第四预设时间间隔后，向第一用户开放用于获取解封道具的一次请求权限，以使所述第一用户在具有请求权限时，向所述服务端设备发送解封道具获取请求，并且服务端设备根据来自第一用户的解封道具获取请求，向第一用户发放预设数量的解封道具。其中，所述第四预设时间间隔与所述第三预设时间间隔类似，也可以根据实际场景的需要进行设定。相较于前一种方式，此种方式中服务端设备并非主动向用户发放解封道具，而是仅根据时间向用户开放请求权限，被动地向基于请求权限发送请求的用户发放解封道具。例如，以36小时的预设时间间隔为例，若基于系统时间计算时间间隔，则服务端设备读取系统时间后可以判断是否距离上次发放已经达到36小时，若已经达到36小时，则自动向第一用户开放用于获取解封道具的一次请求权限，通知第一用户可以向服务端设备发送一次解封道具获取请求，而服务端设备收到该解封道具获取请求，会向第一用户的帐号发放解封道具。

此外，第三种方式可以是通过一定的方式为第一用户发放虚拟代币，使得第一用户发送解封道具获取请求的次数受限于所述第一用户的虚拟代币的数量，服务端设备根据来自第一用户的解封道具获取请求，向第一用户发放预设数量的解封道具。例如，虚拟代币可以是对应应用程序中的金币、积分、点券等，用户每次向服务端设备发送解封道具获取请求时，都需要消耗一定数量的虚拟代币，如50金币、30积分、30个点券等，当虚拟代币的数量不足时，则无法发送解封道具获取请求。

在此，本领域技术人员应当理解，前述第一规则的具体形式仅为举例，现有或今后出现的基于类似原理的其它形式如果能够适用于本申请，也应该包含在本申请的保护范围内，并以引用的形式包含于此。并且，上述第一规则的多种具体形式在没有冲突的情况下，也可以组合使用，例如解封道具获取请求的发送可以同时受限于请求权限和虚拟代币，即第一用户设备只有在具有请求权限时，通过消耗虚拟代币来向所述服务端设备发送解封道具获取请求。

在实际场景中，可以通过调整第一规则和第二规则中涉及的参数，来平衡用户获取封禁道具和解封道具的难度，在避免封禁功能被滥用的同时，替代常规的审核机制，从而高效地对一部分用户的社交功能进行调整。本实施例中可以调整第一预设时间间隔、第二预设时间间隔、第三预设时间间隔、第四预设时间间隔以及封禁道具获取请求、解封道具获取请求的发送次数与虚拟代币的数量之间的受限关系等参数。例如，可以将第一预设时间间隔和第二预设时间间隔设置为小于第三预设时间间隔和第四预设时间间隔。由此，相较于解封道具，用户可以在更快地获取封禁道具，更多地发起对其它第一用户的封禁请求。还如，上述多个预设时间间隔设定的时间越大，对于用户而言，相应道具的获取难度越高，使得用户在使用相应道具时也会更加谨慎，有利于避免相应道具的滥用，提升用户体验。

在调整上述参数时，可以采集相应的数据，如用户对于社交功能调整的评分、被限制预设社交功能的用户数量、被限制后通过解封请求解除社交功能限制的用户数量、被限制后未通过解封请求解除社交功能限制的用户数量等。然后，根据采集到的数据来调整上述参数。为了使得参数调整更加高效、准确，可以基于机器学习的方式，通过训练集训练相应的参数模型，将采集到的数据输入参数模型之后，自动输出最合适的参数。

在本申请的一些实施例中，所述服务端设备在预设周期内向第二用户发放的封禁道具的数量小于等于第二数量阈值，所述服务端设备在预设周期内向第一用户发放的解封道具的数量小于等于第一数量阈值。由此，通过设定预设周期内的数量阈值，从而限制用户在一定时间内相应道具的获取上限。例如，若预设周期为一周，第一数量阈值和第二数量阈值设定为3个，由此表示服务端设备会每周最多会向任意一个用户发放3个封禁道具和解封道具，通过限制道具的获取数量可以利于避免相应道具的滥用，提升用户体验。

与发放封禁道具时类似，在发放解封道具时也可以进一步结合第一用户的历史行为信息。由此，在本申请的一些实施例中，服务端设备在向第一用户发放预设数量的解封道具时，可以向历史行为信息满足第一条件的第一用户发放预设数量的解封道具；而在向第一用户开放用于获取解封道具的一次请求权限时，可以向历史行为信息满足第一条件第一用户开放用于获取解封道具的一次请求权限。

通过设定不同的第一条件，可以仅向具有特定行为的用户发放解封道具。例如，第一条件可以参照前述的第二条件设定，即设定为：在过去一段时间内没有被其它用户封禁过、或者没有过违规行为，则可以避免向经常违规的用户发放解封道具，而仅向行为良好的用户发放解封道具。由此，行为良好的用户即使被错误地限制预设社交功能，也可以通过发送解封请求解除限制，提升用户体验。

在实际场景中，第一用户设备可以根据第一用户输入的解封操作，向服务端设备发送解封请求。根据实际场景中人机交互方式的不同，所述解封操作可以是点击、滑动、悬空手势或者是带动用户设备的沿预设轨迹移动的操作等。

此外，对于第一用户在被限制预设社交功能之后未发送解封请求的情况，服务端设备也可以在限制时长达到预设值之后解除对第一用户的预设社交功能的限制。其中，所述限制时长可以根据预设社交功能的实际限制情况确定，例如在限制时即可设定限制时长，如1天、3天或7天等，由此在解封时可以基于设定的限制时长处理。若未设定限制时长，可以根据一个默认值来实现对限制的解除。

在本申请的一些实施例中，服务端设备对第一用户的预设社交功能进行限制时，可以根据在封禁统计周期内获取到的针对第一用户的封禁请求的数量，确定封禁等级，然后根据所述封禁等级对第一用户的预设社交功能进行限制。

其中，封禁等级用于确定社交功能的限制程度，例如可以根据实际场景将封禁等级设定为由低至高的N个等级。当封禁等级低时，对社交功能的限制程度也越低，如封禁涉及业务范围较小、限制时长短等；而当封禁等级高时，对社交功能的限制程度也越高，如封禁涉及业务范围较大、限制时长较长等。相应地，在确定封禁等级时，若封禁统计周期内获取到的针对第一用户的封禁请求的数量越多，表示同一时期内有较多的用户认为该第一用户存在不良行为，需要限制其社交功能，因此对应的封禁等级也越高。

例如，若封禁统计周期未7天，服务端设备在收到获取到的针对用户User1的封禁请求时，可以统计之前一周内收到的针对该User1的所有的封禁请求的数量，若有10个，则可以将封禁等级确定为level_3，对该用户User1禁言30天；若之前一周内收到的针对该User1的所有的封禁请求的数量只有1个，则可以将封禁等级确定为level_1，对该用户User1禁言3天。由此，可以更加灵活地对用户的社交功能进行限制。

本申请的另一些实施例中，所述服务端设备还可以根据针对第一用户的封禁请求的频率和/或数量，从第一用户中识别出黑名单用户。例如，对于封禁请求频率较高、数量较多的第一用户，可以将其确定为黑名单用户，在实际场景中，可以根据场景的需求设定第三条件，例如频率高于X，或者数量高于Y等，使得服务端设备可以在封禁请求的频率和/或数量满足第三条件时，将第一用户确定黑名单用户。对于黑名单用户，服务端设备可以进行相应的处理，例如对其一部分社交功能进行限制，且不允许该黑名单用户通过解封请求进行解除。由于基于上述方式确定的黑名单用户有较大的概率是经常存在违规行为的用户，对其进行无法主动解除的限制，可以净化社交环境，提升其他用户的使用体验。

图2示出了本申请实施例的方案应用于社交应用场景时的交互示意图，其中，所述社交应用可以是用于实现交友的应用程序，用户可通过该社交应用发布原创内容、对其它用户发布的原创内容进行评论、进行即时通信等。用户User1和用户User2分别使用手机作为其对应的用户设备，手机中运行有社交应用的客户端程序，用户User1和User2的交互过程如下：

步骤S201，用户User1在使用社交应用在与用户User2的聊天过程中，认为用户User2发表的言论违规，此时用户User1可以无需向社交应用的运营方提交举报信息，将用户User2的言论交由运营方审核并进行处罚。用户User1可以直接使用封禁道具，通过消耗一个封禁道具向社交应用的服务端设备提交封禁请求。

步骤S202，服务端设备在接收到封禁请求之后，不经过审核，直接对用户User2的社交功能进行限制，例如本实施例中可以是禁言12小时，即用户User2在后续的12小时内无法继续使用社交应用的即时通信功能与其它用户进行聊天。

步骤S203，用户User2在被禁言之后，可以使用解封道具进行解封，即通过消耗一个解封道具向社交应用的服务端设备提交解封请求。

步骤S204，服务端设备在接收到解封请求之后，对用户User2可以解除对其社交功能的限制，例如本实施例中可以是取消之前的禁言，由此，用户User2可以继续使用社交应用的即时通信功能与其它用户进行聊天。

步骤S205，若用户User2在12小时内未使用解封道具进行解封，服务端设备可以在达到12小时之后，自动解除对其社交功能的限制。相较于常规由运营方进行审核并封禁的方式，用户无需等待审核即可请求限制其它用户的预设社交功能，提升了用户体验，而被限制的用户也可以请求解除限制，减少其它用户恶意封禁对正常使用带来的影响，服务端设备通过控制发放的道具数量，平衡双方用户的请求次数，在能够对不良用户进行有效控制的同时，避免判定和处理的权利被恶意使用。

基于同一发明构思，本申请实施例中还提供了用户社交功能调整设备，所述设备可以包括第一用户设备、第二用户设备和服务端设备，这些设备对应的方法可以是前述实施例中在上述各个设备中的用户社交功能调整方法，并且其解决问题的原理与该方法相似。该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述的用户社交功能调整方法。

本申请实施例提供的用户社交功能调整设备在实现调整时，不同于举报审核的机制，将是否为恶意用户的判定和处理的权利，有条件地移交给社交平台的用户，由此，任意用户无需等待审核即可请求限制其它用户的预设社交功能，提升了用户体验，而被限制的用户也可以请求解除限制，服务端设备通过控制发放的道具数量，限制双方用户的请求次数，避免判定和处理的权利被恶意使用。

图3示出了适用于实现本申请实施例中的方法和/或技术方案的一种设备的结构，该设备300包括中央处理单元(CPU，Central Processing Unit)301，其可以根据存储在只读存储器(ROM，Read Only Memory)302中的程序或者从存储部分308加载到随机访问存储器(RAM，Random Access Memory)303中的程序而执行各种适当的动作和处理。在RAM 303中，还存储有系统操作所需的各种程序和数据。CPU 301、ROM 302以及RAM303通过总线304彼此相连。输入/输出(I/O，Input/Output)接口305也连接至总线304。

以下部件连接至I/O接口305：包括键盘、鼠标、触摸屏、麦克风、红外传感器等的输入部分306；包括诸如阴极射线管(CRT，Cathode Ray Tube)、液晶显示器(LCD，LiquidCrystal Display)、LED显示器、OLED显示器等以及扬声器等的输出部分307；包括硬盘、光盘、磁盘、半导体存储器等一个或多个计算机可读介质的存储部分308；以及包括诸如LAN(局域网，Local Area Network)卡、调制解调器等的网络接口卡的通信部分309。通信部分309经由诸如因特网的网络执行通信处理。

特别地，本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被中央处理单元(CPU)301执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图或框图示出了按照本申请各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机可读指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (14)

1.一种用户社交功能调整方法，其中，该方法包括：

服务端设备根据针对第一用户的封禁请求，对第一用户的预设社交功能进行限制，所述封禁请求来自于所述第一用户外的第二用户，所述第二用户发起封禁请求的次数受限于所述第二用户的封禁道具的数量，所述封禁道具由所述服务端设备根据第二规则向第二用户发放；

服务端设备根据来自第一用户的解封请求，解除对第一用户的预设社交功能的限制，或在限制时长达到预设值之后解除对第一用户的预设社交功能的限制，所述第一用户发起解封请求的次数受限于所述第一用户的解封道具的数量，所述解封道具由所述服务端设备根据第一规则向第一用户发放。

2.根据权利要求1所述的方法，其中，该方法还包括：

服务端设备根据第二规则向第二用户发放封禁道具，其中，所述第二规则至少包括以下任意一项：

服务端设备在经过第一预设时间间隔后，向第二用户发放预设数量的封禁道具；

服务端设备根据来自第二用户的封禁道具获取请求，向第二用户发放预设数量的封禁道具，其中，所述服务端设备在经过第二预设时间间隔后，向第二用户开放用于获取封禁道具的一次请求权限，以使所述第二用户在具有请求权限时，向所述服务端设备发送封禁道具获取请求；

服务端设备根据来自第二用户的封禁道具获取请求，向第二用户发放预设数量的封禁道具，其中，所述第二用户发送封禁道具获取请求的次数受限于所述第二用户的虚拟代币的数量。

3.根据权利要求2所述的方法，其中，服务端设备在经过第一预设时间间隔后，向第二用户发放预设数量的封禁道具，包括：

服务端设备在经过第一预设时间间隔后，向历史行为信息满足第二条件的第二用户发放预设数量的封禁道具。

4.根据权利要求2所述的方法，其中，所述服务端设备在经过第二预设时间间隔后，向第二用户开放用于获取封禁道具的一次请求权限，包括：

所述服务端设备在经过第二预设时间间隔后，向历史行为信息满足第二条件第二用户开放用于获取封禁道具的一次请求权限。

5.根据权利要求1所述的方法，其中，该方法还包括：

服务端设备根据第一规则向第一用户发放解封道具，其中，所述第一规则至少包括以下任意一项：

服务端设备在经过第三预设时间间隔后，向第一用户发放预设数量的解封道具；

服务端设备根据来自第一用户的解封道具获取请求，向第一用户发放预设数量的解封道具，其中，所述服务端设备在经过第四预设时间间隔后，向第一用户开放用于获取解封道具的一次请求权限，以使所述第一用户在具有请求权限时，向所述服务端设备发送解封道具获取请求；

服务端设备根据来自第一用户的解封道具获取请求，向第一用户发放预设数量的解封道具，其中，所述第一用户解封道具获取请求的次数受限于所述第一用户的虚拟代币的数量。

6.根据权利要求5所述的方法，其中，服务端设备在经过第三预设时间间隔后，向第一用户发放预设数量的解封道具，包括：

服务端设备在经过第三预设时间间隔后，向历史行为信息满足第一条件的第一用户发放预设数量的解封道具。

7.根据权利要求5所述的方法，其中，所述服务端设备在经过第四预设时间间隔后，向第一用户开放用于获取解封道具的一次请求权限，包括：

所述服务端设备在经过第四预设时间间隔后，向历史行为信息满足第一条件第一用户开放用于获取解封道具的一次请求权限。

8.根据权利要求1所述的方法，其中，对第一用户的预设社交功能进行限制，包括：

所述服务端设备根据在封禁统计周期内获取到的针对第一用户的封禁请求的数量，确定封禁等级；

根据所述封禁等级对第一用户的预设社交功能进行限制。

9.根据权利要求1所述的方法，其中，该方法还包括：

所述服务端设备根据针对第一用户的封禁请求的频率和/或数量，从第一用户中识别出黑名单用户，其中，所述黑名单用户为对应的封禁请求的频率和/或数量满足第三条件的第一用户。

10.根据权利要求1至9中任一项所述的方法，其中，所述服务端设备在预设周期内向第二用户发放的封禁道具的数量小于等于第二数量阈值，所述服务端设备在预设周期内向第一用户发放的解封道具的数量小于等于第一数量阈值。

11.一种用户社交功能调整方法，其中，该方法包括：

第二用户设备向服务端设备发送根据针对第一用户的封禁请求，以使服务端设备根据所述封禁请求，对第一用户的预设社交功能进行限制，所述第二用户设备为第二用户使用的设备，所述第二用户发起封禁请求的次数受限于所述第二用户的封禁道具的数量，所述封禁道具由所述服务端设备根据第二规则向第二用户发放。

12.一种用户社交功能调整方法，其中，该方法包括：

第一用户设备向服务端设备发送解封请求，以使所述服务端设备根据所述解封请求，解除对第一用户的预设社交功能的限制，所述第一用户设备为第一用户使用的设备，所述第一用户发起解封请求的次数受限于所述第一用户的解封道具的数量，所述解封道具由所述服务端设备根据第一规则向第一用户发放。

13.一种用户社交功能调整设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行权利要求1至12中任一项所述的方法。

14.一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现如权利要求1至12中任一项所述的方法。

Images