CN108462595B - 账号处理系统及处置窗口期的确定方法、服务器 - Google Patents

Abstract

本申请提供了一种账号处理系统及处置窗口期的确定方法、服务器，其中处置窗口期的确定方法包括：基于历史疑似账号集合计算计划处置单位时间个数内异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；将最终的计划处置单位时间个数确定为处置窗口期。本申请中的处置窗口期准确性较高。并且按本申请提供方法确定的处置窗口期，可以达到(1)保护正常用户免受长时间处置，和(2)对疑似账号警告的双重目的。

Description

账号处理系统及处置窗口期的确定方法、服务器

技术领域

本申请涉及软件技术应用领域，尤其涉及账号处理系统及处置窗口期的确定方法、服务器。

背景技术

目前，伴随着科学技术的进步，各种应用逐渐出现。随着应用的广泛使用，部分应用被不法分子(下文称为异常用户)恶意利用。异常用户可以在应用创建或盗用很多账号，并利用这些账号周期性向其他用户发送消息，从而达到不正当获利的目的。

目前，应用平台的处理方式为，通过异常行为识别模型对大量账号进行识别，并将大量账号分为两类：不具有异常行为账号和具有异常行为账号。

具有异常行为账号可以包含异常账号和执行异常行为的正常账号(正常账号不小心执行异常行为或者被盗号后执行异常行为)。为了便于称呼，将具有异常行为账号称为疑似账号。

对于疑似账号而言，目前应用平台会控制疑似账号在处置时间内处于不可用状态(例如，冻结状态或者禁言状态)，以警告疑似账号不可再执行异常行为。

但是，现有技术中的处置时间设置的准确性较差，不利于账号安全。

发明内容

本申请提供了一种账号处理系统及处置窗口期的确定方法、服务器，可以确定一个较为准确的处置时间，以便可以遏制账号的异常行为。

为了实现上述目的，本申请提供了以下技术手段：

一种账号处理系统，包括：

多个终端，用于通过各自的账号向第一服务器发送消息；

第一服务器，用于在单位时间内接收多个账号发送的消息，基于各个账号发送的消息来判断各个账号是否具有异常行为，并输出每个单位时间内具有异常行为的疑似账号集合；

第二服务器，用于接收并存储每个单位时间的疑似账号集合，并基于历史疑似账号集合来计算计划处置单位时间个数内异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；将最终的计划处置单位时间个数确定为处置窗口期。

一种处置窗口期的确定方法，包括：

基于历史疑似账号集合计算计划处置单位时间个数内异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；

调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；

将最终的计划处置单位时间个数确定为处置窗口期。

优选的，所述基于历史疑似账号集合计算计划处置单位时间个数内异常账号的当前覆盖率，包括：

统计历史疑似账号集合中疑似账号总数量；

计算计划处置单位时间个数内异常行为次数大于1异常账号总数量；

将所述异常账号总数量与所述疑似账号总数量的商，确定为所述当前覆盖率。

可选的，所述调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率，包括：

将所述当前覆盖率与所述预设覆盖率进行对比；

若所述当前覆盖率小于预设覆盖率，则逐个增加计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率不小于预设覆盖率；

若所述当前覆盖率大于预设覆盖率，则逐个减少计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率不大于预设覆盖率。

一种服务器，包括：

通讯端口，用于接收历史疑似账号集合；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；

存储器，用于存储历史疑似账号集合；

处理器，用于基于历史疑似账号集合计算计划处置单位时间个数内异常账号的当前覆盖率；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率最趋近于预设覆盖率；将最终的计划处置单位时间个数确定为处置窗口期。

一种账号处理系统，包括：

多个终端，用于通过各自的账号向第一服务器发送消息；

第一服务器，用于在单位时间内接收多个账号发送的消息，基于各个账号发送的消息来判断各个账号是否具有异常行为，并输出每个单位时间内具有异常行为的疑似账号集合；

第二服务器，用于接收并存储当前单位时间的疑似账号集合，利用通用筛选条件集合从接收的疑似账号集合中筛选出异常账号集合；从当前单位时间的下一个单位时间开始，为异常账号集合设置处置窗口期，并控制处置窗口期内的异常账号处于不可用状态；其中，所述第二服务器预先存储有适用于各个异常账号的处置窗口期。

一种账号处理方法，包括：

利用预设的通用筛选条件集合，从接收的疑似账号集合中筛选出异常账号集合；

从当前单位时间的下一个单位时间开始，为异常账号集合设置处置窗口期；

控制处置窗口期内的异常账号处于不可用状态。

可选的，所述通用筛选条件集合的确定过程包括：

针对处置窗口期中的各个疑似账号集合，按预设覆盖率确定各个疑似账号集合的筛选条件集合；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；

对各个筛选条件集合取交集，将交集确定为各个疑似账号集合的通用筛选条件集合。

可选的，按预设覆盖率确定一个疑似账号集合的筛选条件集合，包括：

向筛选条件集合中添加一个筛选条件；其中，所述筛选条件集合初始为空集，所述筛选条件为筛选异常账号的条件；

按筛选条件集合对疑似账号集合进行筛选得到异常账号集合，并计算所述异常账号集合在疑似账号集合中的覆盖率；

调整所述筛选条件集合，直到异常账号集合在疑似账号集合中的覆盖率最趋近于预设覆盖率；

将当前的筛选条件集合确定为疑似账号集合的筛选条件集合。

可选的，在所述从当前单位时间的下一个单位时间开始为异常账号集合设置处置窗口期之后，还包括：

获取异常账号集合中各个异常账号的处置次数；

按处置次数的延长异常账号的处置窗口期。

可选的，所述按处置次数的延长异常账号的处置窗口期，包括：

若一个异常账号的处置次数处于(0，第一预设次数]范围内，则控制该异常账号的处置窗口期延长第一预设单位时间个数；

若一个异常账号的处置次数处于(第一预设次数，第二预设次数]范围内，则控制该异常账号的处置窗口期延长第二预设单位时间个数；其中，所述第二预设单位时间个数大于所述第一预设单位时间个数；

若一个异常账号的处置次数处于(第二预设次数，第三预设次数]范围内，则永久冻结账号；其中，所述第三预设次数大于所述第二预设次数。

可选的，还包括：

将异常账号集合中各个异常账号的处置次数加1。

一种服务器，包括：

通讯端口，用于接收疑似账号集合；

存储器，用于存储疑似账号集合；

处理器，用于利用预设的通用筛选条件集合，从接收的疑似账号集合中筛选出异常账号集合；从当前单位时间的下一个单位时间开始为异常账号集合设置处置窗口期；控制处置窗口期内的异常账号处于不可用状态。

一种处置窗口期的确定方法，包括：

在接收当单位时间的疑似账号集合后，基于预先存储的对应关系确定出异常账号集合；其中，预先存储的对应关系为各个异常账号与各个处置窗口期的对应关系；

在预先存储的对应关系中确定出各个异常账号的处置窗口期；其中，各个异常账号的处置窗口期等于各个异常账号的异常行为周期；

从当单位时间的下一单位时间开始为各个异常账号设置处置窗口期，并控制处置窗口期内的异常账号处于不可用状态。

可选的，对应关系的确定过程包括：

将历史疑似账号集合执行异常行为两次及以上的疑似账号确定为异常账号；其中，历史疑似账号集合包括多单位时间的疑似账号集合；

确定各个异常账号的异常行为周期；

基于各个异常账号和各个异常账号的异常行为周期，构建并存储对应关系。

通过以上技术手段，可以实现以下有益效果：

相比于现有技术中的处置窗口期而言，本申请中的处置窗口期准确性较高。并且按本申请提供方法确定的处置窗口期，可以达到(1)保护正常用户免受长时间处置，和(2)对疑似账号警告的双重目的。

附图说明

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

图1a为本申请实施例公开的一种账号处理系统的结构示意图；

图1b为本申请实施例公开的一种账号处理系统的处理流程图；

图2a为本申请实施例公开的一种处置窗口期的确定方法的流程图；

图2b为本申请实施例公开的一种处置窗口期的确定方法的流程图；

图2c为本申请实施例公开的一种筛选条件的确定方法的流程图；

图2d为本申请实施例公开的一种账号处理方法的流程图；

图2e为本申请实施例公开的处置窗口期的使用过程示意图；

图3a为本申请实施例公开的又一种处置窗口期的确定方法的流程图；

图3b为本申请实施例公开的又一种账号处理方法的流程图；

图3c为本申请实施例公开的又一种处置窗口期的使用过程示意图。

具体实施方式

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

术语解释：

处置窗口期：连续一段时间，例如N个单位时间，N为非零自然数，表示账号处于不可用状态的处置时间。单位时间可以为月、天、小时等。例如，以单位时间为天为例，假设处置窗口期为3天，则表示疑似账号在3天内处于不可用状态。

滑动处置窗口期：处置窗口期会跟随时间，例如以天为单位，向前滑动。伴随着处置窗口期的滑动，处置窗口期内的账号的处置时间会一天天减少，直到账号脱离处置窗口期。

为了便于本领域技术人员了解本申请的应用场景，根据本申请一个实施例，提供了一种账号处理系统。参见图1a，具体包括：多个终端100，与多个终端100相连的第一服务器200，与所述第一服务器200相连的第二服务器 300。多个终端在图示中采用终端1、终端2……终端M表示，M非零自然数。

参见图1b，下面介绍图1a中的系统的具体执行过程：

对于采用客户端和服务器架构的应用，在本申请中，终端100可以安装有该应用的客户端，第一服务器200为应用的服务器端。

步骤S101：多个终端100用于通过各自的账号向第一服务器200发送消息。

各个终端100的客户端上可以登录应用账号，应用账号可以用来表示终端100的使用用户。各个终端100可以向第一服务器200发送消息。可以理解的是，消息携带有消息发送方的发送方账号、消息接收方的接收方账号和消息内容。当然，消息还可以包括其它内容，在此不再一一列举。

步骤S102：第一服务器200在单位时间内接收多个账号发送的消息，基于各个账号发送的消息来判断各个账号是否具有异常行为，并输出每个单位时间内具有异常行为的疑似账号集合。

可选的，第一服务器200上预先设置有异常行为识别模型，并且，第一服务器200可以接收多个终端100通过各自的账号发送的消息，然后利用异常行为识别模型来判断接收到的消息是否为异常消息。

若第一服务器200通过异常行为识别模型判定一个消息为异常消息，则确定该消息的发送方在执行异常行为，并确定发送方账号为疑似账号。若第一服务器200通过异常行为识别模型判定一个消息为正常消息，则确定消息发送方未执行异常行为。关于异常行为识别模型的构建过程和具体使用过程，可以根据具体应用场景而定，在此不做限定。

第一服务器200在每个单位时间运行异常行为识别模型，并将每个单位时间具有异常行为的疑似账号集合发送至第二服务器300。单位时间可以为月、天、小时等，具体情况可以根据实际场景而定，在此不做限定。

可选的：第一服务器200可以接收并存储当前单位时间所有消息，然后将当前单位时间所有消息一并输入异常行为识别模型，从而获得异常行为识别模型当前单位时间输出的疑似账号集合。

或者，第一服务器200将接收到的消息立即输入异常行为识别模型，然后存储异常行为识别模型输出的疑似账号，重复上述过程直到异常行为识别模型将当前单位时间所有接收到消息均识别完毕后，获得当前单位时间的疑似账号集合。

可以理解的是，第一服务器200还可以采用其它方式来获得当前单位时间的疑似账号集合，在此不做限定。

第一服务器200在获得当前单位时间的疑似账号集合后，发送当前单位时间的疑似账号集合至第二服务器300。可以理解的是，第一服务器200的执行过程可以集成于第二服务器300上，以便精简系统结构。

步骤S103：第二服务器300用于接收并存储每个单位时间的疑似账号集合，并基于历史疑似账号集合来确定处置窗口期。

以单位时间为天为例，可以利用阿拉伯数字来区分“天”，则第二服务器 300可以采用标识“1”表示第1天，并将第1天接收的疑似账号集合与标识“1”对应存储，采用标识“2”表示第2天，并将第2天接收的疑似账号集合与标识“2”对应存储，依次类推。

在上述账号处理系统运行一段时间后，第二服务器300上便存储有预设数量单位时间个数的疑似账号集合，将预设数量单位时间个数的疑似账号集合称为历史疑似账号集合(预设数量可以预先设定，在此不做限定)。第二服务器300将基于历史疑似账号集合来确定处置窗口期(也即处置时间)。

疑似账号通常会周期性发送异常消息，也即周期性执行异常行为，将疑似账号执行异常行为(例如发送异常消息)的周期称为异常行为周期。例如，以单位时间为天为例，一个疑似账号每2天执行一次异常行为，则异常行为周期为2天。

为了进一步解释本实施例，参见表1，其中为多个疑似账号的异常行为周期(以单位时间为天为例)。

表1

账号标识	异常行为周期(天数)
		疑似账号1	3
疑似账号2	5
		疑似账号3	6
疑似账号4	8
		疑似账号5	10

申请人发现对疑似账号集合而言：若处置窗口期过短，则无法对疑似账号集合中异常行为周期大于处置窗口期的疑似账号达到应有的警告作用。

例如，参见表1，假设处置窗口期为3天以及异常行为识别模型在1月3 日输出当天的疑似账号1-疑似账号5。那么，在各个疑似账号采用一个处置窗口期的情况下，第二服务器300会控制疑似账号1-疑似账号5在处置窗口期3 天内(即在1月4日、1月5日、1月6日)不可用，在处置窗口期之后(从 1月7日开始)便恢复疑似账号1-疑似账号5为可用状态。

对于疑似账号1而言，由于异常行为周期为3天，则理论上疑似账号1 会在1月6日再次执行异常行为。由于疑似账号1在1月6日仍处于不可用状态，所以疑似账号1可以感知到自身处于不可用状态；即处置窗口期可以对疑似账号1达到应有的警告作用。

对于疑似账号2-疑似账号5而言，由于异常行为周期均大于3天(分别为5天、6天、8天、10天)，所以，理论上疑似账号2-疑似账号5会在1 月6日之后(1月8日、1月9日、1月11日、1月13日)再次执行异常行为。但是，1月6日之后，疑似账号2-疑似账号5已经由不可用状态恢复成可用状态，所以对于疑似账号2-疑似账号5而言，处置窗口期无法达到应有的警告作用，即处置不够。

通过上述描述可知，若预计对所有疑似账号均达到应有的警告作用，则处置窗口期应该不小于各个疑似账号中最长的异常行为周期。

申请人还发现对疑似账号集合中的疑似账号而言：若处置窗口期过长，则会导致疑似账号集合中疑似账号在较长时间内不可用；若这些疑似账号为被盗用的正常账号，则会对正常用户使用该账号产生较大影响。

例如，参见表1，假设处置窗口期为15天，则可以对疑似账号1-疑似账号5均能够达到应有的警告作用。以疑似账号1为例，当处置窗口期为15天时则会导致疑似账号1在15天内不可用(正常情况下疑似账号1的处置窗口期为3天即可)。若疑似账号1刚好为被盗用的正常账号，则会严重影响正常用户的使用该账号。通过上述描述可知，若预计对疑似账号集合中正常账号达到保护作用，则处置窗口期应该尽可能短。

综合上述两点描述，在对疑似账号集合中100％的疑似账号均达到警告作用的情况下(即处置窗口期可以覆盖100％的疑似账号，覆盖率100％)，既要满足处置窗口期不小于各个疑似账号中最长的异常行为周期，又要满足处置窗口期尽可能短，则可以得出：处置窗口期等于各个疑似账号中最长的异常行为周期。这样可以达到最大程度保护正常用户免受长时间处置，和，对所有疑似账号达到警告作用的双重目的。

申请人经过研究发现，实际情况下，疑似账号集合包括大部分异常账号和少部分执行异常行为的正常账号(正常账号不小心执行异常行为或者被盗用后执行异常行为)，所以无需对疑似账号集合中100％的疑似账号均进行处置，对其中大部分异常账号进行处置即可。这样可以避免对正常用户进行处置，从而减少对正常用户的影响。

下面介绍第二服务器300基于历史疑似账号集合来确定处置窗口期的过程。本申请提供确定处置窗口期的两种实现方式，下面分别介绍两种实现方式。

第一种实现方式：多个异常账号对应一个处置窗口期。

为了明确处置窗口期对疑似账号集合中异常账号的处置量，技术人员可以预先设定一个预设覆盖率(覆盖率小于100％)。

技术人员可以根据异常行为识别模型的误识率来设定处置预设覆盖率。比如，异常行为识别模型的误识率为20％，在说明疑似账号集合中有80％的异常账号20％的正常账号，因此，可以设定预设覆盖率为80％。

上述仅提供了覆盖率的一种具体实现方式，可以理解的是，覆盖率的具体大小可以根据具体情况而定，在此不做限定。

参见图2a，根据本申请一个实施例，提供了一种处置窗口期的确定方法，方法具体包括以下步骤：

步骤S201：统计历史疑似账号集合中疑似账号总数量。

历史疑似账号集合包括预设数量的疑似账号集合。第二服务器300查询历史疑似账号集合，查询历史疑似账号集合出现过的疑似账号。然后，统计疑似账号的总数量(可以理解的是，重复出现的疑似账号算1个疑似账号)。

以预设数量为5个单位时间为例，参见表2为历史疑似账号集合示意。

表2

步骤S202：计算计划处置单位时间个数内异常行为次数大于1异常账号总数量，并计算异常账号当前覆盖率。

在此之前可以设定一个计划处置单位时间个数。可以理解的是，正常账号通常是偶发性执行异常行为，所以正常账号通常会执行一次异常行为，而异常账号通常会周期性发送异常消息，所以异常账号通常会执行两次及以上的异常行为。

例如，计划处置单位时间个数的初始值可以为2个单位时间，以计划处置单位时间个数为2单位时间为例，第二服务器300将2个单位时间内(第1 单位时间的疑似账号集合1和第2单位时间的疑似账号集合2)的异常行为次数大于1疑似账号确定为异常账号，并统计异常账号总数量。

然后，计算计划处置单位时间个数为2个单位时间时的异常账号覆盖率，异常账号的当前覆盖率＝异常账号总数量/疑似账号总数量。

步骤S203：判断当前覆盖率是否大于预设覆盖率，若否，则进入步骤S204；若是，进入步骤S205。

第二服务器300 将当前覆盖率与预设覆盖率进行对比，若当前覆盖率不大于预设覆盖率则说明计划处置单位时间个数太短，覆盖的异常账号太少，进入步骤S204。若当前覆盖率大于预设覆盖率则说明计划处置单位时间个数，已经可以达到预设覆盖率，进入步骤S205。

步骤S204：将计划处置单位时间个数增加1个单位时间，进入步骤S202。

当前覆盖率不大于预设覆盖率则说明计划处置单位时间个数太少，不能够达到预先设定的预设覆盖率。因此，可以逐渐增加计划处置单位时间个数，以便可以扩大计划处置单位时间个数可以覆盖的异常账号。

由于各个异常账号的异常行为周期不同(异常行为周期有长有短)，所以在增加计划处置单位时间个数后，可以使得计划处置单位时间个数可以添加异常行为周期较长的异常账号，所以计划处置单位时间个数内的异常账号会逐渐增加。

参见图2b，以表1的5个异常账号为例，以单位时间为天为例，则在计划处置单位时间个数为4天时，计划处置单位时间个数内的异常行为次数大于1为异常账号1；在逐渐增加计划处置单位时间个数的过程中，在计划处置单位时间个数为6天时，计划处置单位时间个数内异常行为次数大于1的异常账号1和异常账号2；在计划处置单位时间个数为7天时计划处置单位时间个数内异常行为次数大于1的异常账号1、异常账号2和异常账号3。

在将计划处置单位时间个数增加一天后，由于计划处置单位时间个数内的异常账号总数量会发生变化，所以会重新计算计划处置单位时间个数内异常行为次数大于1的异常账号数量，并重新计算当前覆盖率。若当前覆盖率仍小于预设覆盖率则继续增加计划处置单位时间个数，直到当前覆盖率大于预设覆盖率。

步骤S205：将当前的计划处置单位时间个数确定为处置窗口期。

在当前覆盖率大于预设覆盖率情况下，说明计划处置单位时间个数已经能够达到预先设定的覆盖率。将当前的计划处置单位时间个数确定为最终的处置窗口期。

为了保证各个异常账号的处置窗口期的准确性，可以设定图2a对应过程的执行周期(比如，一个月或一年等)。图2a对应实施例的执行周期可以根据实际情况而定，在此不做限定。

在图2a所示的实施例中，按计划处置单位时间个数由小至大的方式确定处置窗口期。可以理解的是，也可以按照计划处置单位时间个数由大至小的方式确定处置窗口期：计划处置单位时间个数的初始值可以为N个单位时间 (N为一个处置窗口期的最大值)，后续可以逐渐减少计划处置单位时间个数，以便计划处置单位时间个数内的异常账号的覆盖率达到预设覆盖率，然后将计划处置单位时间个数确定为处置窗口期。

在图2a所示的实施例中确定出处置窗口期后，后续可以对第一服务器200 发送的当前单位时间的疑似账号集合在处置窗口期内处于不可用状态。由于本实施例中确定出的处置窗口期是按设置条件(最短且最有效的处置时间) 计算后得到的，所以本实施例中的处置窗口期准确性较高。

此外，本实施例中提出的处置窗口期既可以最大程度保护正常用户免受长时间处置，又可以对所有疑似账号达到警告作用的双重目的。

由于疑似账号集合中具有异常账号和不小心执行异常行为的正常账号，为了进一步保护正常账号，可以在第一服务器发送的疑似账号集合中筛选出异常账号集合，以便对异常账号集合进行处置，尽量减少对正常账号的处置。

因此，本申请可以确定适用于各个疑似账号集合的筛选条件。筛选条件的标准为：按筛选条件筛选之后的异常账号集合满足预设覆盖率。

由于各个疑似账号集合中的疑似账号不尽相同，所以各个疑似账号集合的筛选条件不尽相同。申请人首先确定每个疑似账号集合的筛选条件，然后，取各个疑似账号集合的筛选条件的交集，作为各个疑似账号集合通用的筛选条件。

参见图2c，根据本申请的一个实施例，提供了一种筛选条件的确定方法，具体包括以下步骤：

步骤S211：针对处置窗口期中的各个疑似账号集合，按预设覆盖率确定各个疑似账号集合的筛选条件集合。

在图2a实施例中确定出处置窗口期(假设为3天)之后，确定出处置窗口期对应的各个疑似账号集合(第1天的疑似账号集合1、第2天的疑似账号集合2和第3天的疑似账号集合3)。然后，确定出各个疑似账号集合对应的筛选条件集合。

下面以多个疑似账号集合中的一个疑似账号集合为例，对按预设覆盖率确定筛选条件集合的过程进行描述：

步骤S1：确定疑似账号集合中的疑似账号总数量。

步骤S2：向筛选条件集合中添加一个筛选条件。

为疑似账号集合设置一个筛选条件集合，筛选条件集合的初始值为空集。

第二服务器可以根据疑似账号集合中的账号特征，确定出适合疑似账号特征的、用于筛选异常账号的筛选条件(例如，注册时间不超过10天、异地登陆、账号等级小于预设等级等等筛选条件)。根据账号特征确定筛选条件的过程已为成熟技术，在此不再赘述。

第二服务器每次向筛选条件集合中添加一个筛选条件。可以理解的是，若需要多次向筛选条件集合中添加筛选条件，则每次添加的筛选条件是不同的。

步骤S3：按筛选条件集合对疑似账号集合进行筛选得到异常账号集合，并确定异常账号集合中的异常账号总数量。

步骤S4：计算异常账号的覆盖率。

异常账号的覆盖率＝异常账号总数量/疑似账号总数量。

步骤S5：判断异常账号的覆盖率是否大于预设覆盖率，若否，则进入步骤S2，若是，则进入步骤S6。

若异常账号覆盖率大于预设覆盖率，则说明筛选条件集合中的筛选条件较少。因此，进入步骤S2再次向筛选条件集合中添加筛选条件。

步骤S6：将当前的筛选条件集合确定为疑似账号集合的筛选条件集合。

若异常账号覆盖率不大于预设覆盖率，则说明筛选条件集合中的筛选条件已经足够多。因此，将当前的筛选条件确定为疑似账号集合的筛选条件集合。

对每个异常账号集合均按上述过程确定出各自的筛选条件集合(即，确定出疑似账号集合1的筛选条件集合C1、疑似账号集合2的筛选条件集合C2 和疑似账号集合3的筛选条件集合C3)。

进入步骤S212：对各个筛选条件集合取交集，将交集确定为各个疑似账号集合通用筛选条件集合。即，通用筛选条件集合C＝C1∩C2∩C3。

图2c所示的实施例确定出通用筛选条件集合，可以适用于各个疑似账号集合。可以理解的是，第二服务器300 可以存储通用筛选条件集合，以便后续利用通用筛选条件集合从疑似账号集合中筛选出异常账号集合。

通过上述图2a所示的实施例可以确定出最优的处置窗口期，在图2c所示的实施例中可以确定出通用筛选条件集合。第二服务器基于处置窗口期和通用筛选条件集合，来对异常账号进行处置。

参见图2d，根据本申请的一个实施例，提供一种账号处理方法，方法具体包括以下步骤：

步骤S221：多个终端100通过各自的账号向第一服务器200发送消息。

步骤S222：第一服务器200通过异常行为识别模型确定当前单位时间的疑似账号集合，并将当前单位时间的疑似账号集合发送至第二服务器300。

步骤S223：第二服务器300利用通用筛选条件集合从疑似账号集合中筛选出异常账号集合。

步骤S224：从当前单位时间的下一个单位时间开始，为异常账号集合设置处置窗口期，并控制处置窗口期内的异常账号处于不可用状态。

参见图2e，以单位时间为天为例，并以第1天的异常账号集合和处置窗口期为3天为例。第二服务器300从第1天接收的疑似账号集合中确定出异常账号集合，从第2天开始设置3天的处置窗口期。第二服务器300会对处置窗口期内的异常账号集合推送惩罚措施，以控制异常账号集合处于不可用状态。

处置窗口期伴随着时间逐渐向前移动，在经过3天后异常账号集合中的各个异常账号脱离处置窗口期。在异常账号集合脱离处置窗口期后，第二服务器300无法再对异常账号A推送惩罚措施，所以异常账号集合中的各个异常账号会恢复至可用状态。

步骤S225：对各个异常账号发送警告消息。

为了便于异常账号的使用者得知自己已经执行异常行为，可以显示警告消息。例如，警告消息可以为“您因执行恶意操作被冻结3天，在3天后可以正常使用”。

在上述图2d实施例执行一段时间之后，正常用户一般会不再执行异常行为，而异常用户由于其被异常用户操控，所以可能仍然会执行异常行为。对于异常行为较为严重的异常账号(在处置窗口期处置过后仍然执行异常行为的异常账号)，还可以逐步升级处置手段。

在步骤S225之后，还可以增加后续步骤：

步骤S226：记录异常账号集合中各个异常账号的处置次数。

步骤S227：获取异常账号集合中各个异常账号的处置次数。

步骤S228：对于处置次数非零的异常账号，延长异常账号的处置窗口期。

可以理解的是，若一个异常账号的处置次数为0，则说明该异常账号为第一次被处置，无需升级处置手段。对于处置次数为非零的异常账号根据处置次数的大小逐渐升级处置手段，直到永久冻结或清退异常账号。

由于异常账号中也可能包含有执行异常行为的正常账号，所以不适宜采用直接冻结账号的处置手段，本实施例通过逐步升级处置手段，可以温和又有效对不同的异常账号设置不同的处置时间，从而提高处置时间的灵活性。

下面对按处置次数的大小升级处置手段的过程，进行详细描述：

第一处置等级：若一个异常账号的处置次数处于(0，第一预设次数]范围内(第一预设次数非零)，则在该异常账号的处置窗口期的基础上，控制处置窗口期延长第一预设单位时间个数。

第二处置等级：若一个异常账号的处置次数处于(第一预设次数，第二预设次数]范围内(第二预设次数大于第一预设次数)，则在该异常账号的处置窗口期的基础上，控制处置窗口期延长第二预设单位时间个数。

第三处置等级：若一个异常账号的处置次数处于(第二预设次数，第三预设次数]范围内(第三预设次数大于第二预设次数)，则永久冻结账号。

下面以一个举例来对升级处置手段的过程进行描述：

例如，第一预设次数、第二预设次数、第三预设次数可以分别为1、2、3、 4，则一个异常账号之前被处置过1次(第一预设次数)，则在处置窗口期基础上再延长1个处置窗口期(即，异常账号被冻结2个处置窗口期)；若一个异常账号被处置过2次(第二预设次数)，则在处置窗口期基础上再延长2 个处置时间(即，异常账号被冻结3个处置窗口期)，若为一个异常账号被处置过3次(第三预设次数)，则永久冻结账号。

上述预设次数和预设单位时间个数均为举例说明，在实际应用中可以根据具体情况而定。

下面介绍第二服务器300基于历史疑似账号集合来确定处置窗口期的第二种实现方式。

第二实现方式：一个异常账号对应一个处置窗口期。

申请人在研究过程中发现：当一个异常账号的处置窗口期与该异常账号的异常行为周期一致时，可以最大程度满足处置窗口期的设置条件。例如，参见表1，以异常账号1为例，理想情况下异常账号1的处置窗口期与其异常行为周期3天一致。

这样，异常账号1在处置窗口期的最后一天(1月6日)刚好是异常账号再次执行异常行为的一天(1月6日)。因此，处置窗口期可以采用最短的处置时间达到警告异常账号1的目的，即最短且最有效的处置时间。

由于不同的异常账号的异常行为周期不尽相同，所以理想情况下，可以为每个异常账号设置一个处置窗口期，以便可以准确为每个异常账号设置最佳的处置时间。

参见图3a，根据本申请的一个实施例，提供了一种处置窗口期的确定方法，具体包括以下步骤：

步骤S301：在历史疑似账号集合中确定出异常账号。

第二服务器300基于预先存储的历史疑似账号集合，确定各个疑似账号的执行异常行为的次数。对于仅执行一次异常行为的疑似账号，确定其为偶发性(不小心)执行异常行为的正常账号，不对其设置处置窗口期。这样可以进一步的保护正常账号。

对于执行异常行为两次及以上的疑似账号，确定其为经常异常行为的异常账号，后续对异常账号设置处置窗口期，以对异常账号达到警告作用(可以理解的是，执行异常行为两次以上的疑似账号中，也可能有被盗号后执行异常行为的正常账号)。

步骤S302：确定各个异常账号的异常行为周期。

本步骤具体可以分为两种情况：

第一种情况：若一个异常账号经过固定时间执行一次异常行为，则将该固定时间确定为异常行为执行周期。

例如，第二服务器300通过历史疑似账号集合发现，标识“1”对应的疑似账号集合中具有疑似账号A，标识“4”对应的疑似账号集合中具有疑似账号A，标识“7”对应的疑似账号集合中具有疑似账号A，则可以确定疑似账号A的异常行为周期为3天。上述举例仅为示意性说明，不应看成对本实施例的具体限定。

第二种情况：若一个疑似账号不定期的执行异常行为，则将疑似账号的平均执行周期确定为该疑似账号的异常行为周期。或者，将该疑似账号最短执行周期，确定为该疑似账号的异常行为周期。

例如，第二服务器300通过历史疑似账号集合发现，标识“1”对应的疑似账号集合中具有疑似账号B，标识“4”对应的疑似账号集合中具有疑似账号B，则疑似账号B本次执行周期为3天。标识“8”对应的疑似账号集合中具有疑似账号B，则疑似账号B本次执行周期为4天。标识“10”对应的疑似账号集合中具有疑似账号B，则疑似账号B本次执行周期为2天。

由于疑似账号B不定期执行异常行为，可以将取各个执行周期3天、4 天和2天的平均执行周期3天，将平均执行周期确定为疑似账号B的异常行为周期。当然，还可以将最短执行周期2天确定为疑似账号B的异常行为周期。上述举例仅为示意性说明，不应看成对本实施例的具体限定。

本实施例提供确定异常行为周期的两种具体实现方式，可以理解的是，还可以通过其它方式来确定疑似账号的异常行为周期，在此不再一一列举。

步骤S303：第二服务器300为各个异常账号设定与各个异常账号的异常行为周期一致的处置窗口期，并将各个异常账号和各个处置窗口期对应存储，获得异常账号和处置窗口期的对应关系。

以一个异常账号为例，第二服务器300在确定出一个异常账号的异常行为周期后，可以将该异常账号的异常行为周期，设定为该异常账号的处置窗口期。例如，在第二服务器300在确定出异常账号A的异常行为周期为3天后，设置该异常账号A的处置窗口期为3天，并将异常账号A与处置窗口期“3天”对应存储。

可以理解的是，在一段时间内(比如一个月)的异常用户的异常手段保持不变，第一服务器200输出的疑似账号集合也会具有一定的不变性。在一段时间后伴随着异常用户异常手段的更新，第一服务器200可能会输出与前段时间(前一个月)不同的疑似账号集合。

因此，为了保证各个异常账号的异常账号的处置窗口期的准确性，可以设定图3a对应过程的执行周期(比如一个月)。图3a对应实施例的执行周期可以根据实际情况而定，在此不做限定。

在图3a所示的实施例的基础上，参见图3b，本申请提供了一种账号处理方法，具体包括以下步骤：

步骤S311：多个终端100通过各自的账号向第一服务器200发送消息。

步骤S312：第一服务器200通过异常行为识别模型确定当前单位时间的疑似账号集合，并将当前单位时间的疑似账号集合发送至第二服务器300。

步骤S311和步骤S312的过程已在前述内容中进行描述，在此不再赘述。

步骤S313：第二服务器300接收当前单位时间的疑似账号集合，在预先存储的对应关系中确定出各个异常账号以及各个异常账号的处置窗口期。

第二服务器300在接收当前单位时间的疑似账号集合后，针对其中每个疑似账号在预先存储异常账号和处置窗口期的对应关系中进行查找。

若一个疑似账号在对应关系中查找到，则确定该疑似账号为异常账号，并在对应关系中确定出该异常账号的处置窗口期(即单位时间个数)。若一个疑似账号在对应关系中未查找到，则确定该疑似账号为正常账号，无需对该账号设置处置窗口期。

步骤S314：从当前单位时间的下一个单位时间开始，为各个异常账号设置处置窗口期，并控制处置窗口期内的异常账号处于不可用状态。

由于异常账号在当前单位时间已经执行过异常行为，所以可以不必将当前单位时间设置在处置窗口期内，而是从当前单位时间的下一个单位时间开始设置处置窗口期。在处置窗口期内的异常账号会处于不可用状态(例如，冻结状态或禁言状态)，以便限制异常账号执行异常行为。

例如，参见图3c，以异常账号A和处置窗口期为3天为例。第二服务器 300第1天接收的疑似账号集合中确定出异常账号A，从第2天开始设置3天的处置窗口期。第二服务器300会对处置窗口期内的异常账号A推送惩罚措施，以控制异常账号A处于不可用状态。

处置窗口期伴随着时间逐渐向前移动，在经过3天后异常账号A脱离处置窗口期。在异常账号A脱离处置窗口期后，第二服务器300无法再对异常账号A推送惩罚措施，所以异常账号A会恢复至可用状态。

本实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (13)

1.一种账号处理系统，其特征在于，包括：

多个终端，用于通过各自的账号向第一服务器发送消息；

第一服务器，用于在单位时间内接收多个账号发送的消息，基于各个账号发送的消息来判断各个账号是否具有异常行为，并输出每个单位时间内具有异常行为的疑似账号集合；

第二服务器，用于接收并存储每个单位时间的疑似账号集合，并基于历史疑似账号集合中计划处置单位时间个数内异常账号总数量与所述历史疑似账号集合中疑似账号总数量的比值计算异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；将最终的计划处置单位时间个数确定为处置窗口期。

2.一种处置窗口期的确定方法，其特征在于，应用于第二服务器，包括：

基于历史疑似账号集合中计划处置单位时间个数内异常账号总数量与所述历史疑似账号集合中疑似账号总数量的比值计算异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合，所述疑似账号集合为具有异常行为的账号的集合；

调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；

将最终的计划处置单位时间个数确定为处置窗口期。

3.如权利要求2所述方法，其特征在于，所述基于历史疑似账号集合计算计划处置单位时间个数内异常账号的当前覆盖率，包括：

统计历史疑似账号集合中疑似账号总数量；

计算计划处置单位时间个数内所述历史疑似账号集合中异常行为次数大于1的异常账号的数量，将计算出的异常账号的数量作为异常账号总数量；

将所述异常账号总数量与所述疑似账号总数量的商，确定为所述当前覆盖率。

4.如权利要求2所述方法，其特征在于，所述调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率，包括：

将所述当前覆盖率与所述预设覆盖率进行对比；

若所述当前覆盖率小于预设覆盖率，则逐个增加计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率不小于预设覆盖率；

若所述当前覆盖率大于预设覆盖率，则逐个减少计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率不大于预设覆盖率。

5.一种服务器，其特征在于，包括：

通讯端口，用于接收历史疑似账号集合；其中，历史疑似账号集合包括多个单位时间的疑似账号集合，所述疑似账号集合为具有异常行为的账号的集合；

存储器，用于存储历史疑似账号集合；

处理器，用于基于历史疑似账号集合中计划处置单位时间个数内异常账号总数量与所述历史疑似账号集合中疑似账号总数量的比值计算异常账号的当前覆盖率；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率最趋近于预设覆盖率；将最终的计划处置单位时间个数确定为处置窗口期。

6.一种账号处理系统，其特征在于，包括：

多个终端，用于通过各自的账号向第一服务器发送消息；

第一服务器，用于在单位时间内接收多个账号发送的消息，基于各个账号发送的消息来判断各个账号是否具有异常行为，并输出每个单位时间内具有异常行为的疑似账号集合；

第二服务器，用于接收并存储当前单位时间的疑似账号集合，利用通用筛选条件集合从接收的疑似账号集合中筛选出异常账号集合；从当前单位时间的下一个单位时间开始，为异常账号集合设置处置窗口期，并控制处置窗口期内的异常账号处于不可用状态；其中，所述第二服务器预先存储有适用于各个异常账号的处置窗口期，所述处置窗口期由所述第二服务器采用下述方法确定：基于历史疑似账号集合中计划处置单位时间个数内异常账号总数量与所述历史疑似账号集合中疑似账号总数量的比值计算异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；将最终的计划处置单位时间个数确定为所述处置窗口期。

7.一种账号处理方法，其特征在于，包括：

利用预设的通用筛选条件集合，从接收的疑似账号集合中筛选出异常账号集合；

从当前单位时间的下一个单位时间开始，为异常账号集合设置处置窗口期；

控制处置窗口期内的异常账号处于不可用状态；

其中，所述处置窗口期的确定方法包括：

基于历史疑似账号集合中计划处置单位时间个数内异常账号总数量与所述历史疑似账号集合中疑似账号总数量的比值计算异常账号的当前覆盖率；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；

调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率达到预设覆盖率；

将最终的计划处置单位时间个数确定为处置窗口期。

8.如权利要求7所述的方法，其特征在于，所述通用筛选条件集合的确定过程包括：

针对处置窗口期中的各个疑似账号集合，按预设覆盖率确定各个疑似账号集合的筛选条件集合；其中，历史疑似账号集合包括多个单位时间的疑似账号集合；

对各个筛选条件集合取交集，将交集确定为各个疑似账号集合的通用筛选条件集合。

9.如权利要求8所述的方法，其特征在于，按预设覆盖率确定一个疑似账号集合的筛选条件集合，包括：

向筛选条件集合中添加一个筛选条件；其中，所述筛选条件集合初始为空集，所述筛选条件为筛选异常账号的条件；

按筛选条件集合对疑似账号集合进行筛选得到异常账号集合，并计算所述异常账号集合在疑似账号集合中的覆盖率；

调整所述筛选条件集合，直到异常账号集合在疑似账号集合中的覆盖率最趋近于预设覆盖率；

将当前的筛选条件集合确定为疑似账号集合的筛选条件集合。

10.如权利要求7所述的方法，其特征在于，在所述从当前单位时间的下一个单位时间开始为异常账号集合设置处置窗口期之后，还包括：

获取异常账号集合中各个异常账号的处置次数；

按处置次数的延长异常账号的处置窗口期。

11.如权利要求10所述的方法，其特征在于，所述按处置次数的延长异常账号的处置窗口期，包括：

若一个异常账号的处置次数处于(0，第一预设次数]范围内，则控制该异常账号的处置窗口期延长第一预设单位时间个数；

若一个异常账号的处置次数处于(第一预设次数，第二预设次数]范围内，则控制该异常账号的处置窗口期延长第二预设单位时间个数；其中，所述第二预设单位时间个数大于所述第一预设单位时间个数；

若一个异常账号的处置次数处于(第二预设次数，第三预设次数]范围内，则永久冻结账号；其中，所述第三预设次数大于所述第二预设次数。

12.如权利要求7-11任一项所述的方法，其特征在于，还包括：

将异常账号集合中各个异常账号的处置次数加1。

13.一种服务器，其特征在于，包括：

通讯端口，用于接收疑似账号集合；

存储器，用于存储疑似账号集合；

处理器，用于利用预设的通用筛选条件集合，从接收的疑似账号集合中筛选出异常账号集合；从当前单位时间的下一个单位时间开始为异常账号集合设置处置窗口期；控制处置窗口期内的异常账号处于不可用状态；所述处理器还用于基于历史疑似账号集合中计划处置单位时间个数内异常账号总数量与所述历史疑似账号集合中疑似账号总数量的比值计算异常账号的当前覆盖率；调整计划处置单位时间个数，直到计划处置单位时间个数内异常账号的当前覆盖率最趋近于预设覆盖率；将最终的计划处置单位时间个数确定为所述处置窗口期。

Images