一种账号检测的方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种账号检测的方法及装置。
背景技术
当前,各种各样的软件及应用(Application,App)相继出现,这些App不但功能强大,而且操作简单,因此,这些功能强大的App相继被安装在用户的智能手机、平板电脑等智能终端中,用户可使用这些App来进行诸如聊天、数据存储、图像处理等业务,极大的丰富了人们的日常生活,提高了用户进行业务处理的能力。
在实际应用中,用户通常需要在App完成用户账号的注册,才能进一步的使用该App中的各项功能。为了确保用户账号的安全性,用户通常都会将用户当前所使用的电话号码与用户注册的用户账号进行绑定,这样,后续用户在使用该App时,若出现了账号密码遗忘或密码修改等情况,则该App所属的服务器可向用户注册的用户账号所绑定的电话号码发送校验码,而用户在接收到服务器发送的校验码后,可将该校验码输入到App操作界面中的指定位置中,如,校验码输入框等,并通过确认后发送给服务器,而服务器在接收到用户通过该App发送的校验码后,发现该校验码与服务器向用户发送的校验码相同,则可确定出用户当前所执行的账号密码找回或账号密码修改等操作是有效的,即,服务器可确定出用户当前所执行的账号密码找回或账号密码修改等操作是用户本人所执行的,因此,服务器将向用户发送用户账号所对应的密码,或是向用户提供账号密码修改的业务。
然而在实际应用中,用户将当前使用的电话号码与用户注册的用户账号进行绑定后,可能会更换该电话号码,即,用户将该电话号码停用或注销掉,而通信运营商通常在确定出该电话号码的停用时间或注销时间超过了通信运营商所规定的时间后,通常会将该电话号码二次放号给其他用户,不仅如此,通信运营商将该电话号码二次放号给新的用户后,通常也不会将二次放号该电话号码的事情通知该电话号码的原用户。这样一来,若用户不及时的对绑定在该用户账号的电话号码进行修改,则后续用户使用该App来进行找回账号密码或密码修改等操作时,服务器依然会将校验码发送至原电话号码,这样就可能将该用户的信息泄露给使用该电话号码的新用户,进而可能会给用户带来一定的损失。
例如,假设用户A在App上注册了一个用户账号后,将该用户账号与用户A当前所使用的电话号码进行了绑定,而后,该用户A弃用了该电话号码,而改用新电话号码,通信运营商在经过一定时间发现,该电话号码的停用或注销的时间已经到达了通讯运营商所规定的时间,因此,通信运营商可将该电话号二次放号给用户B。但是,用户A在弃用该电话号码时,并没有及时的对绑定在该用户账号的电话号码进行修改,这样一来,用户A通过该App来进行找回用户账号密码的操作时,服务器将会向该电话号码发送用于验证用户A找回账号密码操作的校验码,而由于该电话号码已经通过通信运营商二次放号给了用户B,因此,用户B则相应的接收到了服务器发送的校验码,这样一来,用户B可根据接收到该校验码,得知自己当前所使用的电话号码可能已被某个用户绑定在了该App的一个用户账号中,进而可通过其他手段来对用户A在该App上注册的用户账号实施盗取,给用户A带来损失。
不仅如此,通信运营商的二次放号还可能导致用户错发消息的可能。例如,假设用户a使用一电话号码在App上注册了一个用户账号(即,相当于该电话号码与用户注册的用户账号进行了绑定)后,该用户a随后弃用了该电话号码。过了一段时间后,通信运营商发现该电话号码的停用或注销时间超出了规定的时间,因此,可将该电话号码二次放号给用户b。用户c在得知用户b当前所使用的该电话号码后,以为用户b使用了该电话号码在该App上注册了一个用户账号,因此,用户c可将该电话号码就作为用户b在该App上注册的用户账号而向该电话号码进行消息发送,相应的,用户c也将认为自己基于该电话号码所发送的消息是发送给用户b的。然而实际上,用户b并没有使用该电话号码在该App上注册用户账号,而该电话号码在该App上所对应的用户账号却是用户a注册的,这样一来,用户c基于该电话号码而向用户b发送的消息实际上是发送给了用户a,相当于用户c在该App上发错了消息,因此,这种情况的发生将给用户在使用该App时带来不便。
发明内容
本申请实施例提供一种账号检测的方法,用于解决现有技术中用户在使用App时,App会给用户带来不便的问题。
本申请实施例提供一种账号检测的装置,用于解决现有技术中用户在使用App时,App会给用户带来不便的问题。
本申请实施例采用下述技术方案:
本申请实施例提供一种账号检测的方法,包括:
确定待检测账号及其对应的绑定信息;
获取多个检测规则和所述待检测账号的历史数据;
根据所述多个检测规则以及历史数据,对所述待检测账号和绑定信息进行检测,以得到多个检测结果;
根据所述多个检测结果,检测所述绑定信息是否需要变更。
本申请实施例提供一种账号检测的装置,包括:
确定模块,待检测账号及其对应的绑定信息;
获取模块,获取多个检测规则和所述待检测账号的历史数据;
检测模块,根据所述多个检测规则以及历史数据,对所述待检测账号和绑定信息进行检测,以得到多个检测结果;
检测信息模块,根据所述多个检测结果,检测所述绑定信息是否需要变更。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
由于本申请实施例中,服务器可通过预设的多个检测规则以及用户的历史数据,对用户账号对应的绑定信息进行检测,并当检测到该绑定信息需要变更时,向该用户账号发送变更该绑定信息的提示信息,这样一来,当用户更换了注册用户账号所填写的绑定信息时,服务器可向该用户的用户账号发送变更该绑定信息的提示信息,使得用户可根据该提示信息,对该绑定信息进行修改,从而有效的保障了用户信息的安全性,给用户使用App时带来了便利。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的账号检测的过程;
图2为本申请实施例提供的账号检测的系统示意图;
图3为本申请实施例提供的一种账号检测的装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1为本申请实施例提供的账号检测的过程,具体包括以下步骤:
S101:确定待检测账号及其对应的绑定信息。
在实际应用中,用户为了能够进一步享受App中各项功能所带来的便利,通常都会在该App进行用户账号的注册。而为了确保用户账号的安全性,用户通常都会使用能够用于身份验证的信息与注册的用户账号进行绑定,或是使用能够用于进行身份验证的信息来注册用户账号(即相当于将能够验证身份的信息与该用户账号进行了绑定),其中,该绑定信息可以是电话号码、用户的地址信息、身份证号等信息,这样一来,后续过程中,当监测到用户的修改密码或取回密码等操作时,则可根据用户先前填写的绑定信息(即注册用户账号时填写的绑定信息),对用户进行验证,以确定用户当前所执行的修改密码或取回密码等操作是否是用户本人(即注册该用户账号的用户)进行操作的,从而有效的保障了用户账号的安全性。
然而,若用户在完成用户账号的注册后,更换了自己的绑定信息(即用户当前所使用的能够验证身份的信息与用户注册用户账号时所填写的绑定信息不同),但却又没有对先前在用户账号注册时所填写的绑定信息进行及时的修改,则后续用户在进行修改密码或是取回密码等操作时,App所对应的服务器则将会继续根据用户先前填写的绑定信息(即用户注册用户账号时填写的绑定信息)来对用户进行验证,这样一来,就可能会给用户的用户账号带来安全隐患,给用户带来不便。
为了避免上述情况的发生,在本申请实施例中,服务器(即App对应的服务器)可对用户账号以及用户注册该用户账号时所填写的绑定信息进行检测,并当检测到该绑定信息可能并不是用户当前所使用的能够验证用户身份的信息(即检测到该绑定信息需要变更)时,向用户进行相应的提示,使得用户可根据该提示,将用户在服务器中保留的绑定信息(即用户注册用户账号时填写的绑定信息)进行修改,以使服务器能够根据修改后的绑定信息,完成后续对该用户的验证操作。因此,服务器可先确定出随后要检测的账号以及该待检测账号对应的绑定信息,其中,该绑定信息是用户注册该用户账号时填写的绑定信息,或注册该用户账号后填写的绑定该用户账号的绑定信息。
S102:获取多个检测规则和所述待检测账号的历史数据。
服务器在确定出待检测的用户账号以及该待检测账号对应的绑定信息(即用户注册该用户账号时填写的绑定信息)后,可根据该待检测的用户账号,获取到该待检测账号对应的历史数据,其中,该历史数据是服务器预先根据用户通过该用户账号所执行的操作而收集到的,这样一来,服务器则可通过获取到的该历史数据进行分析,进而检测该待检测的用户账号对应的绑定信息是否需要变更。而在实际应用中,服务器获取的历史数据中通常都包含有多种数据类型的历史数据,例如,针对该待检测的用户账号来说,该待检测账号所对应的历史数据中可能包含有关于短信(该短信是服务器向该用户账号发送的)接收情况的历史数据,有关于校验码(该校验码是服务器针对该用户账号向用户终端发送的)填写情况的历史数据,也可能有关于用户信息修改情况的历史数据等等,因此,服务器为了使其对历史数据的分析更加的准确,以得到更加准确的检测结果(该检测结果即为检测该待检测账号以及该待检测账号对应的绑定信息后得到的),服务器可分别针对每种类型的历史数据预设检测规则,并将这些预设的检测规则存储在预设的规则库中,使得后续服务器在对某一用户账号以及该用户账号对应的绑定信息进行检测时,可从预设的规则库中获取到多个检测规则,并根据获取到的这些检测规则,来获取与这些检测规则相匹配的历史数据。
具体的,服务器从预设的规则库中获取到多个检测规则后,可针对每个检测规则,确定出与该检测规则相匹配的数据类型(即该检测规则应匹配哪种类型的历史数据),而后,服务器可针对每个数据类型,从预先存储的该待检测账号对应的历史数据中选取与该数据类型相匹配的历史数据,进而在后续过程中,服务器可根据获取的检测规则,以及与该检测规则相匹配的历史数据,检测该待检测账号以该待检测账号对应的绑定信息。
S103:根据所述多个检测规则以及历史数据,对所述待检测账号和绑定信息进行检测,以得到多个检测结果。
在实际应用中,服务器获取到的用户账号对应的历史数据通常包含有以下几类,关于短信接收情况的历史数据、关于校验码填写情况的历史数据、关于用户信息识别/更改情况的历史数据以及与用户通讯录信息相关的历史数据,相应的,与这几种数据类型的历史数据相匹配的检测规则可以是:短信检测规则、校验码检测规则、用户信息检测规则以及通讯录检测规则。因此,在本申请实施例中,服务器获取到多个检测规则以及用户账号(该用户账号即为上述提到的待检测的用户账号)的历史数据后,可分别根据各检测规则以及与各检测规则相匹配的历史数据,对该待检测账号以及该待检测账号对应的绑定信息进行检测,并针对每个检测规则以及与该检测规则相匹配的历史数据,得到相应的检测结果。
具体的,对于检测规则为短信检测规则来说,在实际应用中,服务器通常会向用户发送各种短信,如广告、校验码等,例如,对于用户账号对应的绑定信息来说,用户在注册用户账号时,填写的最常见的绑定信息就是电话号码,因此,服务器在向该用户发送短信时,可以根据该绑定电话号码(即与该用户账号绑定的绑定信息),向该用户所使用的终端发送短信。正常情况下,用户若始终不更换该绑定电话号码的话,则通常可顺利的接收到服务器发送的短信。然而,若用户在注册完用户账号后,对使用的电话号码进行了更换,即,用户当前使用的电话号码与用户注册用户账号时所填写的绑定电话号码并不是同一个电话号码,并且也未对先前注册用户账号时填写的绑定电话号码进行相应的修改,则后续服务器向该用户发送短信时,该用户也将无法接收到服务器发送的短信,换句话说,服务器基于用户注册用户账号时所填写的绑定电话号码而向用户发送短信时,由于该绑定电话号码被用户进行了更换,即,该绑定电话号码应该处于停用的状态,则服务器在向该绑定电话号码发送短信时,将会接收到通讯运营商返回的发送失败的应答消息。而为了使服务器能够根据用户接收短信的情况来对用户账号以及该用户账号对应的绑定信息进行检测,服务器在接收到发送失败的应答消息后,可将该应答消息进行记录,得到该用户账号关于短信接收情况的历史数据。后续服务器在根据关于短信接收情况的历史数据以及短信检测规则对待检测账号(即用户账号)及其绑定电话号码进行检测时,则可根据该短信规则以及历史数据,检测该待检测账号所对应的用户通过该绑定电话号码(用户注册用户账号时填写的绑定电话号码)在预设的时间段内是否成功接收到服务器发送的短信,换句话说,服务器可根据在预设时间段内向该待检测账号对应的绑定电话号码发送的各短信,检测各短信是否发送成功,并得到相应的检测结果。其中,选取预设时间段内的历史数据是为了使该历史数据对于后续得到的检测结果来说,能够更具有代表性,所谓的具有代表性就是指假设用户近期(一个月内)更换了绑定信息(即用户当前所使用的能够验证用户身份的信息不同于用户注册用户账号时所填写的绑定信息),服务器在对该用户的用户账号以及该用户账号对应的绑定信息(该绑定信息即为用户注册用户账号时填写的绑定信息)进行检测时,应该获取该用户近期(一个月内)的历史数据,而不是获取该用户一个月前或是更久的历史数据,由于该用户近期(一个月内)的历史数据与该用户更换绑定信息的行为应是具有紧密联系的,换句话说,该用户一个月前或是更久的历史数据对于该用户更换绑定信息的行为应是没有过多联系的,因此,服务器获取到的该用户近期(一个月内)的历史数据对于后续得到的检测结果(该检测结果是服务器根据该历史数据以及与该历史数据相匹配的检测规则得到的)来说,该历史数据是具有代表性的。
需要说明的是,上述提到的预设时间段可以是任意的时间段,而为了使该时间段更加的合理,即,服务器获取该预设时间段内的历史数据对于后续得到的检测结果来说,能够更具有代表性,该预设时间段可以设置在三个月左右。
例如,假设用户A在注册用户账号时,填写的用于绑定该用户账号的绑定电话号码(即绑定信息)为电话号码a(或直接使用该电话号码a注册用户账号,则该电话号码a与注册的用户账号直接具有绑定关系),而后,用户A将该电话号码a更换成了电话号码b,但是却没有对先前注册用户账号所填写的绑定电话号码a进行及时的修改,这样一来,由于服务器并不知道该用户A已经将实际使用的电话号码a进行了更换,则服务器还将继续向该绑定电话号码a发送的短信。由于该电话号码a被用户A进行了更换,换句话说,该电话号码a应该处于停用的状态,因此,服务器在向该电话号码a发送短信时,接收到的将是通讯运营商返回的发送失败的应答消息,而服务器为了能够在后续过程中根据用户接收短信的情况来对用户账号以及该用户账号对应的绑定信息进行检测,则服务器在接收到通讯运营商返回的该应答消息后,可将该应答消息进行记录,进而得到该用户账号关于短信接收情况的历史数据,后续过程中,服务器在对该用户账号(即待检测账号)以及该绑定电话号码a进行检测时,则可根据获取到的短信检测规则,从预先存储的历史数据中获取到与该短信检测规则相匹配的,关于该用户账号短信接收情况的历史数据,服务器在接收到该历史数据后发现,在最近的三个月内(即预设的时间段内),服务器向该电话号码a发送的短信均以失败而告终,因此,服务器则可根据短信检测规则,得到针对该用户账号以及该绑定电话号码a的一个检测结果M。
需要说明的是,上述示例中,服务器可根据短信检测规则以及与该短信检测规则相匹配的历史数据得出不同的检测结果,例如,假设服务器在三个月内(即预设的时间段内)向该电话号码a发送了100条短信,而服务器根据获取到的关于该用户账号短信接收情况的历史数据得知,在这100条短信中,该电话号码a一条也没有接收到,即,服务器向该用户账号发送的这100条短信中,没有一条发送成功的,则服务器根据短信检测规则,得出针对该用户账号以及该绑定电话号码a的一个检测结果M,若在这100条短信中,该电话号码a接收到了55条短信,则服务器可根据该短信检测规则,得出针对该用户账号以及该绑定电话号码a的一个检测结果P,若这100条短信中,服务器成功向该电话号码a发送了98条短信,则服务器可根据该短信检测规则,得出针对该用户账号以及该绑定电话号码a的一个检测结果B,即,服务器得出的检测结果是与该电话号码a接收短信的情况有着密切关系的,如表1所示。
表1
服务器在得出检测结果后,可将该检测结果进行保存,进行在后续过程中,将该检测结果与其他的检测结果进行进一步的处理,检测所述绑定电话号码(即绑定信息)是否需要变更。
对于检测规则为校验码检测规则来说,在实际应用中,当用户进行用户账号密码修改或是取回密码等需要验证的操作时,服务器通常会向该用户发送校验码,并当用户正确填写了校验码后,才会向该用户提供相应的服务,其中,服务器在向该用户发送校验码时,通常都是以短信的形式向该用户发送的,即,服务器可根据用户在注册用户账号时所填写的绑定电话号码(即绑定信息),向该用户发送校验码。然而,若用户在注册完用户账号后,更换了电话号码(即,用户当前使用的电话号码与用户注册用户账号时所填写的绑定电话号码并不是同一个电话号码),并且,也没有对先前注册用户账号时填写的绑定电话号码进行相应的修改,则后续服务器以短信的形式向该用户发送的校验码时,该用户也将无法接收到服务器发送的校验码,进一步的,该用户也将无法在App中填写正确的校验码,进而也就无法完成用户账号密码更改或是取回密码等操作。
而服务器为了能够根据用户填写校验码的情况来对用户账号以及该用户账号对应的绑定电话号码(即绑定信息)进检测,服务器可记录用户填写校验码的情况,得出该用户账号关于校验码填写情况的历史数据,继而服务器在后续检测该用户账号以及该用户账号对应的绑定电话号码时,则可根据该校验码规则以及获取到的关于校验码填写情况的历史数据,检测该用户账号对应的用户在预设时间段内是否均正确填写了服务器针对该绑定电话号码发送的校验码,即,服务器可针对在预设时间内向该待检测账号(即用户账号)对应的绑定电话号码发送的每个校验码,检测是否接收到该待检测账号返回的相同的校验码,并得到相应的检测结果。具体的检测过程与上述说明的短信检测规则相同,在此就不进行详细赘述了。
在本申请实施例中,服务器除了可以根据该用户账号的历史数据以及各检测规则,来对该用户账号以及该用户账号对应的绑定电话号码(即绑定信息)进行检测外,还可以通过其他账号(即,其他用户注册的用户账号)的历史数据,来从侧面对该用户账号以及该用户账号对应的绑定电话号码进行检测。具体的,在实际应用中,用户在弃用了一个电话号码后,通讯运营商通常都会对该电话号码进行二次放号,即,当该电话号码的停用时间到达了通讯运营商所规定的预设时间时,通讯运营商可将该电话号码发放给新的用户。新的用户在拿到该电话号码后,可能也会通过该电话号码在该App上完成一些操作,这样一来,服务器即可根据该新的用户通过该电话号码所执行的一些操作,得到关于该新的用户的历史数据,进而根据该新的用户的历史数据,对该用户账号(即该电话号码的原用户注册的用户账号)以及该用户账号对应的电话号码进行检测。
具体的,服务器可根据其他账号在预设时间段内的历史数据,检测其他账号对应的用户是否通过该绑定电话号码正确填写了服务器发送的校验码,换句话说,服务器可针对在预设历史时间段内向该待检测账号对应的绑定电话号码发送的每个校验码,检测是否接收到其他账号返回的相同的校验码,并得到相应的检测结果。
例如,假设用户A使用电话号码a在App上注册了用户账号后,更换了电话号码a,即,该电话号码a进行停用的状态,而通讯运营商在监测到该电话号码a的停用时间到达了通讯运营商规定的预设时间后,通讯运营商则将该电话号码a二次放号给了用户B,用户B在接收到该电话号码a后,可通过该电话号码a在该App上进行用户账号的注册,并正确填写了服务器发送的校验码,而服务器则可相应的对用户B的这一举动进行记录,并得到用户B的历史数据。随后,服务器根据用户A的历史数据发现,该用户A的用户账号在最近的三个月内(预设时间段内)均未接收到服务器发送的短信,则服务器可根据用户B的历史数据,检测到在这段时间内,用户B在进行用户账号注册时,通过该电话号码a正确填写了服务器发送的校验码,因此,服务器相当于从侧面完成为对用户A的用户账号以及绑定电话号码a的检测,并得到了检测结果,其中,对于该检测结果来说,当服务器检测到在这段时间内,用户B通过该电话号码a正确填写了服务器发送的校验码,并且用户A在这段时间内没有接收到服务器发送的任何短信时,则服务器可根据校验码检测规则,得到检测结果V;若服务器检测到在这段时间内(即预设时间段内),没有其他的用户通过该电话号码a正确填写了服务器发送的校验码,并且用户A在这段时间内没有接收到服务器发送的任何短信,则服务器可根据校验码检测规则,得到检测结果C。
对于检测规则是用户信息检测规则的情况来说,在实际应用中,App通常可以对用户所使用的电话号码(即绑定信息)进行检测,即,用户在智能手机上通过用户账号登录到该App时,该App可以识别出当前用户所使用的手机客户识别模块(Subscriber IdentityModule,SIM)卡号,相应的,若用户更换了电话号码,则用户后续使用新的电话号码来在智能手机上登录该App时,该App也可将识别出的新电话号码的手机SIM卡号发送至服务器,使得服务器根据获取到的历史数据,检测该用户账号对应的用户登录该用户账号所使用的SIM卡号是否与该用户注册用户账号时所填写的绑定电话号码相匹配,即,服务器可检测登录该待检测账号(即用户账号)的终端中的SIM卡号是否与该待检测账号对应的绑定电话号码相匹配,并得到相应的检测结果。
例如,假设用户A使用电话号码a注册了一个用户账号,在注册过程中,App识别出该电话号码a的SIM卡号89860050081578915663,因此,App可将识别出的该电话号码a的SIM卡号发送给服务器,相应的,服务器可将该SIM卡号与该电话号码a的对应关系进行记录,得到用户A的历史数据。而后,用户A在使用该电话号码a一段时间后,弃用了该电话号码a,而改用电话号码b,相应的,用户A在随后的过程中,也将使用该电话号码b,在所持有的智能手机上使用该App,此时,该App在识别出电话号码b的SIM卡号后,可将该SIM卡号89860040071638756992发送至服务器中,而服务器在接收到该SIM卡号后,可获取该App发送给该SIM卡号所基于的用户账号的历史数据,并根据该历史数据,检测到该用户账号对应的用户当前登录该用户账号所使用的SIM卡号与该用户注册用户账号时所填写的绑定电话号码a的SIM卡号是不相匹配的,进而根据用户信息检测规则,得到相应的检测结果G。当然,当检测到该用户账号对应的用户当前登录该用户账号所使用的SIM卡号与该用户注册用户账号时所填写的绑定电话号码a的SIM卡号相同时,则可根据用户信息检测规则,得到相应的检测结果T。
在实际应用中,用户有时可能会在用户的个人信息中,将先前填写的个人信息进行修改,如,将个人信息中的地址信息,电话信息、兴趣爱好等信息进行修改,因此,当服务器监测到用户修改了个人信息时,则可对用户的修改操作进行记录,进而得到了关于用户个人信息更改的历史数据。后续服务器在对用户账号以及该用户账号对应的绑定电话号码(即绑定信息)进行检测时,可从预设的规则库中获取到用户信息检测规则,并根据获取到的用户信息检测规则,从预先存储的历史数据中获取到该用户账号关于用户个人信息更改情况的历史数据,进而根据该历史数据以及用户信息检测规则,检测该用户账号对应的用户在预设的时间段内是否更换了指定的个人信息(即用户在个人信息中填写的电话号码),并得到相应的检测结果。
例如,假设用户A通过电话号码a在App注了用户账号后,将该电话号码a作为联系方式填写在了该App的个人信息界面中,而后,用户A弃用了该电话号码a,而改用了电话号码b,并及时在该App的个人信息界面中,将原有的联系方式修改了电话号码b进行了保存。因此,服务器可对用户A修改个人信息的举动进行记录,得到用户A的历史数据。而在后续过程中,当服务器对该用户A的用户账号以及该用户账号对应的绑定电话号码a进行检测时,则可从预设的规则库中,获取到用户信息检测规则,并根据该用户信息检测规则,从预先存储的历史数据中,获取到与该用户信息检测规则相匹配的历史数据,即,关于该用户账号对应的用户修改个人信息的历史数据,随后,服务器可根据该历史数据以及用户信息检测规则,检测到该用户A的用户账号在三个月内(即预设时间段内)对个人信息中的联系方式进行了修改,即,将原先在个人信息界面中填写的电话号码a更改为电话号码b,则服务器可根据该用户信息检测规则,得到针对该用户账号以及该绑定电话号码a的一个检测结果R。当然,当服务器根据该历史数据检测到用户A在三个月内(即预设时间段内)没有对个人信息中的联系方式进行修改,即,个人信息中的联系方式依然是电话号码a,则服务器可根据该用户信息检测规则,得到不同于检测结果R的一个检测结果D。
除此之外,服务器还可根据其他用户对各自个人信息的修改情况,侧面的对该用户账号(即待检测账号)以及该用户账号对应的绑定电话号码(绑定信息)进行检测。具体的,用户使用电话号码(即绑定信息)在App上注册了一个用户账号后,将该电话号码进行了更换,而通讯运营商在监测到该电话号码的停用时间到达了通讯运营商所规定的预设时间后,可将该电话号码二次放号给其他用户,而其他用户在接收到该电话号码后,可将该电话号码作为自己的联系方式填写在该App的个人信息界面中,相应的,服务器也将对这一用户的操作进行记录,并将该记录作为历史数据进行存储。而后,当服务器需要对用户(该用户是该电话号码的原用户)的用户账号以及绑定电话号码进行检测时,则可从预设的规则库中获取到用户信息检测规则,继而根据该用户信息检测规则,从预先存储的历史数据中获取到其他用户的历史数据,并对该历史数据进行处理、分析,不仅如此,服务器还可获取到待检测账号(即上述提到的用户账号)的历史数据,其中,当服务器根据待检测用户账号的历史数据,检测到该用户账号对应的用户在预设时间段内均未接收到服务器发送的短信时,则可根据该用户信息检测规则以及其他用户账号的历史数据,检测其他用户账号对应的其他用户是否将该用户(该电话号码的原用户)注册用户账号时所填写的绑定电话号码用于对自身的个人信息进行了修改,换句话说,服务器可检测其他账号对应的用户信息(即,其他用户的个人信息)中包含的电话号码是否与该待检测账号对应的绑定电话号码相匹配,并得到相应的检测结果。
例如,假设用户A使用电话号码a在App上注册了用户账号后,将该电话号码a进行了更换,而通讯运营商在监测到该电话号码a的停用时间到达了通讯运营商所规定的时间时,则将该电话号码a二次放号给了用户B,用户B在获取到该电话号码a后,则将其在该App的个人信息中的联系方式进行了修改,即,将该电话号码b作为了用户B在该App中个人信息中的联系方式,相应的,服务器可对该用户B的这一操作进行记录,并将该记录作为用户B的历史数据进行存储。而后,当服务器需要对用户A的用户账号以及用户A注册该用户账号时所填写的绑定电话号码a进行检测时,则可获取用户A的历史数据,在获取到用户A的历史数据后发现,该用户A在近期的三个月内(预设时间段内)均未接收到服务器发送的短信,则可从预设的规则库中,获取用户信息检测规则,并根据该用户信息检测规则,从预先存储的历史数据中获取与该用户信息检测规则相匹配的、其他用户的历史数据。服务器在获取到其他用户的历史数据后发现,用户B在近期的三个月内(预设时间段内)将自己的个人信息中的联系方式修改为电话号码a,因此,服务器从侧面完成了对用户A的用户账号以及该用户注册用户账号时所填写的绑定电话号码a的检测。
不仅如此,服务器还可根据其他用户上传的各通讯录信息,来侧面的对待检测账号(即上述提到的用户账号)以及该用户账号对应的绑定电话号码(即绑定信息)进行检测。具体的,在实际应用中,用户在App上进行用户账号注册时,该App通常都会提示该用户是否上传该用户的通讯录,当用户确定上传时,则该App则可从用户所使用的终端中获取到该用户的通讯录信息,并将该通讯录信息上传至服务器。这样一来,服务器即可获取到大量用户的通讯录信息,进而在后续过程中,当服务器在对待检测账号以及该待检测账号对应的绑定电话号码进行检测时,可从预设的规则库中获取到通讯录检测规则,并根据该通讯录检测规则,从预先存储的各通讯录信息中获取到其他用户(该其他用户不同于待检测账号对应的用户)上传的各通讯录信息,进而根据该通讯录规则以及获取到的各通讯录信息,检测这些通讯录信息中保存的该电话号码对应的联系人是否为该待检测账号对应的用户,换句话说,服务器可根据其他账号上传的各通讯录信息,检测所述各通讯录信息中保存的该绑定电话号码对应的用户标识是否与该待检测账号对应的用户标识相匹配,并得到相应的检测结果,其中,这里提到的用户标识可以用户姓名。
例如,假设用户A使用电话号码a在App上注册了用户账号后,将该电话号码a进行了更换,而通讯运营商在监测到该电话号码a的停用时间到达了通讯运营商所规定的时间时,则将该电话号码a二次放号给了用户B,用户B在获取到该电话号码a后,通知其他的用户自己所使用的电话号码已经更换为电话号码a,相应的,其他用户则可将各自通讯录中用户B的联系方式更换为电话号码a。由于App可以将用户的通讯录进行上传,因此,服务器在对用户A的用户账号以及用户A注册该用户账号时所填写的电话号码a进行检测时,可从预设的规则库中获取通讯录检测规则,并根据该通讯录检测规则,获取其他用户上传的各通讯录信息,其中,服务器在获取到一些用户的通讯录信息后发现,这些通讯录信息中,该电话号码a对应的联系人为用户B,而并不是用户A,则可得出针对用户A的用户账号以及电话号码a的检测结果S。
需要说明的是,若服务器在对待检测账号及其对应的绑定电话号码进行检测的过程中,从预先存储的各通讯录信息中获取了除该待检测账号以外的其他所有账号上传的通讯录信息,则可能会由于获取的数据量过大而导致检测效率有所降低。为了防止这种情况的发生,服务器可获取与待检测账号相关联的其他账号上传的通讯录信息,即,获取与该待检测账号对应的用户具有联系关系的用户上传的通讯录信息,这样不仅可以准确的完成对待检测账号及其对应的绑定电话号码的检测,还可有效降低服务器检测所需的数据量,提高了服务器的检测效率。
S104:根据所述多个检测结果,检测所述绑定信息是否需要变更。
服务器在根据多个检测规则以及用户的历史数据,分别得到对应多个检测规则的多个检测结果后,可根据得到的这些检测结果,检测该绑定电话号码(即用户注册用户账号时所填写的绑定信息)是否为用户账号对应的用户当前所使用的电话号码,其中,对于各个检测规则来说,不同的检测规则得出的检测结果对服务器最终判定该绑定电话号码(即绑定信息)是否为用户账号对应的用户当前所使用的电话号码的影响都是不同的,换句话说,通过有些规则得出的检测结果能够十分准确的判定出该绑定电话号码是否为用户账号对应的用户当前所使用的电话号码,而通过有些规则得出的检测结果在准确度上则稍微差一下。因此,为了能够更加准确判定出该绑定电话号码是否为用户账号对应的用户当前所使用的电话号码。不同的检测规则可以对应不同的预设权重,例如,通过用户信息检测规则得出的检测结果准确性较高一些,则可将该用户信息检测规则对应的预设权重设置的高一些,通过通讯录检测规则得出的检测结果准确性较低一些,则可将该通讯录检测规则对应的预设权重设置的低一些,这样,服务器在判定该绑定电话号码是否为该用户账号对应的用户当前所使用的绑定电话号码(即检测该绑定电话号码是否需要变更)时,服务器可根据得到的多个检测结果,分别确定各检测结果对应的各检测表征值,而后,服务器可根据确定出的各检测结果以及各预设权重,得到一个最终检测值,如,加权和值,并可进一步的确定出该最终检测值所落入的预设区间,同时,根据预设的各区间与判定结果的对应关系,以及该预设区间,确定出该最终检测值对应的判定结果。随后,服务器可根据该判定结果,检测该绑定点换号码(即绑定信息)是否为该用户账号对应的用户当前所使用的电话号码,即,检测该绑定电话号码是否需要变更。
例如,假设服务器根据获取到的4个检测规则,以及用户的历史数据,相应的得出了4个检测结果,而后,服务器可根据得到的这4个检测结果,分别确定出这4个检测结果所对应的4个检测表征值35、66、77、52,随后,服务器可根据各检测表征值所对应的预设权重,分别确定出对应检测表征值35、66、77、52的4个预设权重为30%、15%、33%、22%,并根据这4个检测表征值以及预设的权重,得出一个加权和值(即最终检测值)。服务器在得出该加权和值后,可确定出该加权和值所落入的预设区间,其中,服务器发现该加权和值落入的预设区间为[c,f]时,则服务器可根据预设的各区间与判定结果的对应关系,以及该预设区间[c,f],检测到该绑定电话号码(绑定信息)不是该用户账号对应的用户当前使用的电话号码,即,检测到该绑定电话号码需要变更。
需要说明的是,上述示例中,服务器根据判定结果来对用户账号进行授信等级划分时,可大致将授信等级分为三个等级,即,可信、疑似、不可信,其中,当服务器检测到该绑定电话号码(即绑定信息)即为该用户账号对应的用户当前所使用的电话号码(即检测到该绑定电话号码不需要变更)时,则认为该用户账号的授信等级即为可信;当服务器无法判定出该绑定电话号码是否为该用户账户对应的用户当前所使用的电话号码(即无法检测出该绑定电话号码是否需要变更)时,则可认为该用户账号的授信等级即为疑似;当服务器可判定出该绑定电话号码不是该用户账号对应的用户当前所使用的电话号码(即检测到该绑定电话号码需要变更)时,则可认为该用户账号的授信等级为不可信。当然,用户账号的授信等级也可再进一步进行细分、如,第一可信、第二可信等等。
当服务器判定出该绑定电话号码是否为用户账号对应的用户当前使用的电话号码(即,检测到该绑定电话号码需要变更)后,可根据判定结果,对该用户账号所对应的用户进行提示,即,向上述待检测账号发送变更该绑定电话号码(即绑定信息)的提示信息,例如,当服务器根据判定结果,确定该用户账号的授信等级为疑似(无法检测出该绑定电话号码是否需要变更)时,则可向该用户账号的用户进行绑定电话号码的确认提示,如更换绑定的电话号码等,而当服务器根据判定结果,确定该用户账号的授信等级为不可信(检测到该绑定电话号码需要变更)时,则可向该用户账号的用户进行绑定电话号码的变更提示,或是直接不对该该用户账号对应的用户进行服务。
从上述方法中可以看出,由于服务器可根据预设的多个检测规则以及用户的历史数据,对用户的用户账号以及用户注册该用户账号时所填写的绑定信息进行检测,并当检测到该绑定信息需要变更时,向该待检测账号变更该绑定信息的提示信息,以使得该待检测账号对应的用户在查看到该提示信息后,能够及时的对该绑定信息进行相应的修改,从而确保了用户的账号信息的安全性,给用户在使用App时带来了便利。
需要说明的是,在上述步骤S103中,服务器也可根据待检测账号(即用户账号)接收服务器通过网络推送的消息,来对该待检测账号及其绑定信息(即绑定电话号码)进行检测。具体的,服务器在实际应用中通常会向用户进行消息的推送,即,通过网络来向用户发送消息,相应的,若用户的用户账号时刻处于登录状态下时,该用户也将即时接收到服务器发送的消息,然而,若用户在一段时间内都没有通过该用户账号登录到该App时,则服务器也无法将该消息成功推送至用户的App中。基于这种情况,服务器在向用户推送消息时,可对推送消息的情况进行记录,得出该用户账号关于消息接收情况的历史数据,进而在后续过程中,服务器可根据相应的消息检测规则以及与该消息检测规则相匹配的该用户账号关于消息接收情况的历史数据,得出该用户账号以及该用户账号对应的注册信息的检测结果,具体的检测过程与短信的检测过程相同,在此就不进行详细赘述。
服务器在确定出各检测结果后,也可针对各检测结果,分别确定出各检测结果对应的判定结果,并根据各判定结果的数量,检测所述绑定信息(即绑定电话号码)是否需要变更。具体的,服务器检测该待绑定账号及其对应的绑定信息后得到的判定结果大致可以分为三类,即,可信、疑似、不可信,而各判定结果都是由服务器根据各检测规则以及与各检测规则对应的历史数据得出的,因此,在本申请实施例中,服务器可根据获取到的各检测规则以及各检测规则所对应的历史数据,得到相应的各检测结果,进而得到对应各检测结果的各判定结果。而后,服务器可根据判定结果的类别,统计各判定结果的数量,并当某一判定结果的数量超出预设阈值时,将该判定结果就作为最终的判定结果,并根据该判定结果,确定该绑定信息是否需要变更。
例如,假设服务器根据短信检测规则、校验码检测规则、用户信息检测规则通讯录检测结果,以及这4个检测规则分别对应的待检测账号的历史数据,分别得出了可信、可信、疑似、可信这4个判定结果,则服务器可根据判定结果的类别,对这4个判定结果进行分类,并对各类别中判定结果的数量进行统计,其中,服务器发现有3个判定结果是属于可信类别的,并且,该可信判定结果的数量已经超出了预设阈值2(即,可信判定结果占判定结果总数的比例已经超出了一半),则服务器可将该可信判定结果就作为最终的判定结果,进而确定检测到所述绑定信息(即用户注册用户账号时填写的绑定电话号码)不需要变更。
当然,服务器还可以根据待检测账号(即用户账号)在预设时间段内的历史数据,从预设的规则库中选出一个检测规则,并根据该检测规则以及历史数据,检测所述绑定信息(即绑定电话号码)是否需要变更。具体的,在实际应用中,用户的历史数据通常可分为以下几种类型的历史数据:关于短信接收情况的历史数据、关于校验码填写情况的历史数据、关于用户信息修改情况的历史数据、以及用户上传通信录信息的历史数据,而用户在某一固定时间段内所执行的各类操作的数量,往往就决定了这段时间内各类历史数据的数据量大小,其中,数据量较大的一类历史数据往往可准确的反映出该待检测账号对应的用户最近使用该待检测账号的情况,也就是说,由于数据量较大的一类历史数据与用户的近期活动是密切相关的,因此,服务器可根据数据量较大的一类历史数据,在一定程度上准确的完成待检测账号及其绑定信息(即绑定电话号码)的检测工作,进而得出较为准确的判定结果。
例如,服务器在确定出待检测的账号以及该待检测账号对应的绑定信息(即绑定电话号码)后,可获取该待检测账号的历史数据,而服务器在获取该历史数据后发现,在最近的一段时间内(即预设的时间段内)关于校验码填写情况的历史数据在数据量上是最大的,相应的,服务器可确定出该待检测账号对应的用户在近期内(即预设的时间段内)进行校验码填写的操作居多,因此,服务器可将该历史数据(关于校验码填写情况的历史数据)就作为检测该待检测账号及其绑定信息的依据,进而根据该历史数据,从预设的规则库中选取与该历史数据相匹配的校验码检测规则,并根据该校验码检测规则以及该历史数据,检测该绑定信息是否需要变更。
除此之外,服务器也可不对待检测账号以及该待检测账号对应的绑定信息(即绑定电话号码)进行检测,而直接对该待检测账号(即用户账号)进行绑定信息的确认提示,即,服务器可以按照固定的时间间隔,向该待检测账号对应的用户发送提示信息,用户在看到该提示信息后,可定期检查该待检测账号对应的绑定信息是否需要变更。
另外,在本申请实施例中,服务器在获取待检测账号的历史数据之外,需要预先对该历史数据进行收集,而收集该历史数据的可以通过服务器中的数据收集系统来进行收集,而后续服务器在对待检测账号及其绑定信息(即绑定电话号码)进行检测时,可通过服务器中的账号检测系统来进行检测,如图2所示。
图2为本申请实施例提供的账号检测的系统示意图。
在图2中,服务器中的数据收集系统可预先对各用户账号的历史数据进行收集,其中,由于用户的历史数据通常都包含有多种类型的历史数据,因此,服务器中的数据收集系统在对各用户账号的历史数据进行收集之前,可针对各类型的历史数据,分别设置专门收集一种类型历史数据的子数据收集系统,其中,对于关于短信接收情况的历史数据来说,该数据收集系统可针对这种类型的历史数据,专门设置一个收集该类型历史数据的短信系统,相应的,服务器可针对其他类型的历史数据,分别设置出校验码系统、用户信息系统、通讯录系统这三个子数据收集系统。
各子数据收集系统在收集到各用户账号对应的历史数据后,可将收集到的历史数据进行格式转换,并将格式转换后的历史数据录入到账号检测系统的数据库中,其中,将数据收集系统将收集到的历史数据进行格式转换的目的在于,在实际应用中,各数据库都有各自的数据存储格式,数据库通常都只能存储符合自己数据格式的数据,因此,在本申请实施例中,数据收集系统为了使数据库能够存储数据收集系统收集的历史数据,可将收集到的各用户账号的历史数据的数据格式进行转换,得到符合账号检测系统中数据库存储格式的历史数据,进而将转换后的历史数据录入到账号检测系统的数据库中。而该数据库在将数据收集系统录入的历史数据进行存储时,可针对各历史数据的类型,将各类型的历史数据进行分类存储。
服务器中的账号检测系统在对待检测的账号以及该待检测账号对应的绑定信息(即绑定电话号码)进行检测时,可从预设的规则库中读取出各个检测规则,并根据读取出的各检测规则,从数据库存储的该待检测账号的历史数据读取(即获取)到与各检测规则相匹配的各历史数据,并通过读取各检测规则以及各历史数据,得到相应的各检测结果。账号检测系统在得到各检测结果后,可根据这些检测结果,确定出针对该待检测账号及其绑定信息的判定结果,并根据该判定结果,检测该绑定信息是否需要变更,其中,账号检测系统在确定该绑定信息需要变更时,则可对该待检测账号授予不可信状态,进而向该待检测账号发送变更该绑定信息的提示信息,而账号检测系统在确定该绑定信息不需要变更时,则可对该待检测账号授予可信状态,同时无需向该待检测账号发送变更该绑定信息的提示信息,而账号检测系统无法确定该绑定信息是否需要变更时,则可对该待检测账号授予疑似状态,并向该待检测账号发送确认该待绑定信息的提示信息。
需要说明的是,上述说明的数据收集系统以及账号检测系统除了可以设置于同一服务器内外,还可分别设置在不同的服务器中,而在本申请实施例中说明的历史数据以及检测规则除了上述提到的几种外,还可包括其他类型的历史数据以及检测规则,具体类型在此不做进一步的限定,只需保证服务器能够从正面或侧面检测待检测账号对应的绑定信息是否变更即可。
以上为本申请实施例提供的账号检测的方法,基于同样的思路,本申请实施例还提供了消息账号检测的装置,如图3所示。
图3为本申请实施例提供的一种账号检测的装置结构示意图,具体包括:
确定模块301,确定待检测的账号及其对应的绑定信息;
获取模块302,获取多个检测规则和所述待检测账号的历史数据;
检测模块303,根据所述多个检测规则以及历史数据,对所述待检测账号和绑定信息进行检测,以得到多个检测结果;
检测信息模块304,根据所述多个检测结果,检测所述绑定信息是否需要变更。
所述获取模块302,从预设的规则库中获取多个检测规则;针对每个检测规则,确定与该检测规则相匹配的数据类型;针对每个数据类型,从所述待检测账号的历史数据中选取与该数据类型相匹配的历史数据。
所述绑定信息包括:绑定电话号码;所述检测规则包括:短信检测规则、校验码检测规则、用户信息检测规则、通讯录检测规则中的至少一种。
当所述检测规则为所述校验码检测规则时,所述检测模块303,针对在预设历史时间段内向所述待检测账号对应的绑定电话号码发送的每个校验码,检测是否接收到所述待检测账号返回的相同的校验码;或者针对在预设历史时间段内向所述待检测账号对应的绑定电话号码发送的每个校验码,检测是否接收到其他账号返回的相同的校验码。
当所述检测规则为所述用户信息检测规则时,所述检测模块303,检测登录所述待检测账号的终端中的客户识别模块SIM卡号是否与所述待检测账号对应的绑定电话号码相匹配;或者检测所述待检测账号对应的用户信息中包含的电话号码是否与所述待检测账号对应的绑定电话号码相匹配;或者检测其他账号对应的用户信息中包含的电话号码是否与所述待检测账号对应的绑定电话号码相匹配。
当所述检测规则为通讯录检测规则时,所述检测模块303,根据其他账号上传的各通讯录信息,检测所述各通讯录信息中保存的所述绑定电话号码对应的用户标识是否与所述待检测账号对应的用户标识相匹配。
所述检测信息模块304,根据所述多个检测结果,分别确定各检测结果对应的各检测表征值;根据所述各检测表征值以及预设的与所述各检测表征值对应的各权重,得出最终检测值;根据所述最终检测值,检测所述绑定信息是否需要变更。
所述装置还包括:
提示模块305,当检测出所述绑定信息需要变更时,向所述待检测账号发送变更所述绑定信息的提示信息。
本申请实施例提供一种账号检测的方法及装置,该方法可通过获取到的多个检测规则以及用户的历史数据,对待检测的用户账号以及绑定信息进行检测,并得到多个检测结果,并根据的得到的多个检测结果,检测该绑定信息是否需要变更。由于服务器可通过预设的多个检测规则以及用户的历史数据,对用户账号对应的绑定信息进行检测,并当检测到该绑定信息需要变更时,向该用户账号发送变更该绑定信息的提示信息,这样一来,当用户更换了注册用户账号所填写的绑定信息时,服务器可向该用户的用户账号发送变更该绑定信息的提示信息,使得用户可根据该提示信息,对该绑定信息进行修改,从而有效的保障了用户信息的安全性,给用户使用App时带来了便利。
需要说明的是,实施例1所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤S101和步骤S102的执行主体可以为第一服务器,步骤103的执行主体可以为第二服务器;又比如,步骤101的执行主体可以为第一服务器,步骤102和步骤103的执行主体可以为第二服务器;等等。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。