发明内容
本申请提供一种利用社交关系数据验证客户端身份的方法和装置,以解决现有技术无法辨识客户端设备是否为账户所有者的设备的问题。本申请另外提供一种客户端身份验证方法和装置,以及一种利用社交关系数据验证客户端身份的***。
本申请提供一种利用社交关系数据验证客户端身份的方法,包括:
接收待验证客户端发送的对应特定账户的身份验证请求;
获取所述客户端的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果;
判断所述相似度匹配结果是否满足预先设定的通过条件;若是,则判定所述客户端通过身份验证。
可选的,所述特定账户的已存社交关系数据采用如下步骤生成:
分析预先采集的数据,从中提取与所述特定账户相关联的社交关系数据;
存储已提取的与所述特定账户相关联的社交关系数据。
可选的,所述获取所述客户端的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果,包括:
向所述客户端发送所述特定账户的已存社交关系数据;
接收所述客户端发送的所述客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
可选的,所述获取所述客户端的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果,包括:
接收所述客户端发送的所述客户端存储的客户端社交关系数据;
计算所述客户端存储的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
可选的,所述方法还包括:
判断所述相似度匹配结果是否满足预先设定的报警条件;若是,则阻止所述客户端通过身份验证,并采取报警措施。
可选的,所述相似度匹配结果包括匹配数和/或匹配度;
所述匹配数是指,所述特定账户的已存社交关系数据与所述客户端社交关系数据一致的条目数量;
所述匹配度是指,所述匹配数与所述特定账户的已存社交关系数据的条目数量的比值。
相应的,所述判断所述相似度匹配结果是否满足预先设定的通过条件,具体是指:
判断所述匹配数和匹配度是否分别大于预先设置的匹配数通过阈值和匹配度通过阈值;或者,
判断所述匹配数是否大于预先设置的匹配数通过阈值;或者,
判断所述匹配度是否大于预先设置的匹配度通过阈值。
可选的,所述判断所述相似度匹配结果是否满足预先设定的报警条件,具体是指:
判断所述匹配数和匹配度是否分别小于预先设置的匹配数报警阈值和匹配度报警阈值;或者,
判断所述匹配数是否小于预先设置的匹配数报警阈值;或者,
判断所述匹配度是否小于预先设置的匹配度报警阈值。
可选的,所述社交关系数据包括:电话号码、QQ号码、微信号码、来往帐号、通讯录或者代付账记录。
相应的,本申请还提供一种利用社交关系数据验证客户端身份的装置,包括:
验证请求接收单元,用于接收待验证客户端发送的对应特定账户的社交关系数据;
匹配结果获取单元,用于获取所述客户端的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果;
通过判断单元,用于判断所述相似度匹配结果是否满足预先设定的通过条件;若是,则判定所述客户端通过身份验证。
可选的,所述装置还包括:
社交关系数据生成单元,用于获取并存储所述特定账户的社交关系数据;
所述社交关系数据生成单元包括:
分析提取子单元,用于分析预先采集的数据,从中提取与所述特定账户相关联的社交关系数据;
存储子单元,用于存储已提取的与所述特定账户相关联的社交关系数据;该社交关系数据即为所述特定账户的已存社交关系数据。
可选的,所述匹配结果获取单元包括:
社交关系数据发送子单元,用于向所述客户端发送所述特定账户的已存社交关系数据;
匹配结果接收子单元,用于接收所述客户端发送的所述客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
可选的,所述匹配结果获取单元包括:
第一社交关系数据接收子单元,用于接收所述客户端发送的所述客户端存储的客户端社交关系数据;
第一匹配结果计算子单元,用于计算所述客户端存储的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
可选的,所述装置还包括:
报警判断单元,用于判断所述相似度匹配结果是否满足预先设定的报警条件;若是,则阻止所述客户端通过身份验证,并采取报警措施。
此外,本申请还提供一种客户端身份验证方法,包括:
向服务器端发送特定账户的客户端身份验证请求;
向所述服务器端发送所述服务器端利用社交关系数据对所述客户端进行身份验证所需的信息;
接收所述服务器端返回的所述客户端是否通过身份验证的应答。
可选的,向所述服务器端发送所述服务器端利用社交关系数据对所述客户端进行身份验证所需的信息,具体是指,向所述服务器端发送本地存储的客户端社交关系数据。
可选的,向所述服务器端发送所述服务器端利用社交关系数据对所述客户端进行身份验证所需的信息,包括:
接收服务器端发送的所述特定账户的社交关系数据;
计算该客户端本地的客户端社交关系数据与所接收的所述特定账户的社交关系数据的相似度匹配结果;
向所述服务器端发送所述相似度匹配结果。
相应的,本申请还提供一种客户端身份验证装置,包括:
验证请求发送单元,用于向服务器端发送特定账户的客户端身份验证请求;
验证信息发送单元,用于向所述服务器端发送所述服务器端利用社交关系数据对所述客户端进行身份验证所需的信息;
验证结果接收单元,用于接收所述服务器端返回的所述客户端是否通过身份验证的应答。
可选的,所述验证信息发送单元,具体用于向所述服务器端发送本地存储的客户端社交关系数据。
可选的,所述验证信息发送单元包括:
第二社交关系数据接收子单元,用于接收所述服务器端发送的所述特定账户的社交关系数据;
第二匹配结果计算子单元,用于计算该客户端本地的客户端社交关系数据与所接收的所述特定账户的社交关系数据的相似度匹配结果;
匹配结果发送子单元,用于向所述服务器端发送所述相似度匹配结果。
此外,本申请还提供一种利用社交关系数据验证客户端身份的***,包括:根据上述任一项所述的利用社交关系数据验证客户端身份的装置、以及任一项所述的客户端身份验证装置。
与现有技术相比,本申请具有以下优点:
本申请提供的利用社交关系数据验证客户端身份的方法、客户端身份验证方法、以及相应装置和***,通过获取客户端设备存储的客户端社交关系数据、与服务器端的特定账户的已存社交关系数据的相似度匹配结果,并将该匹配结果与预先设定的阈值进行比对,从而判定所述客户端设备是否通过身份验证,即:所述客户端设备是否为所述特定账户所有者自己的设备,并根据判定结果进行相应的授权操作或者报警操作,从而能够避免对客户端设备的错误授权,有效保障用户账户的安全性。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本申请内涵的情况下做类似推广,因此本申请不受下面公开的具体实施的限制。
在本申请中,分别提供了一种利用社交关系数据验证客户端身份的方法和装置、一种客户端身份验证方法和装置、以及一种利用社交关系数据验证客户端身份的***。在下面的实施例中逐一进行详细说明。
请参考图1,其为本申请的一种利用社交关系数据验证客户端身份的方法的实施例的流程示意图。所述方法包括如下步骤:
步骤S101:接收待验证客户端发送的对应特定账户的身份验证请求。
本申请提供的利用社交关系数据验证客户端身份的方法,通过将某账户客户端的客户端社交关系数据、与所述账户的已存社交关系数据进行相似度匹配,并根据匹配结果判定所述客户端是否通过身份验证,即:所述客户端是否为所述账户所有者的客户端设备。
本申请所述的客户端包括但不限于移动通讯设备,即:通常所说的手机或者智能手机,还包括个人电脑、PAD、iPad等终端设备。本申请提供的利用社交关系数据验证客户端身份的方法,其应用场景也不仅仅局限于移动通讯设备的首次绑定及换绑操作过程中的身份验证,在其他需要验证客户端身份的场景下也可以采用本申请所提供的方法,例如:如果某个应用为了提供更高的安全性保障,不仅要求用户提供正确的账户名和密码,还需要验证执行操作的客户端设备是否为该账户所有者自己的设备,在有类似验证需求的场景下都可以应用本申请提供的方法,进行客户端身份的验证。
要实施本申请提供的方法,首先要接收待验证客户端发送的对应特定账户的身份验证请求。来自客户端设备的身份验证请求中可能包含账户名、密码、以及请求进行客户端身份验证的相关信息,实施本申请所提供方法的服务器端收到该请求后,首先验证所述账户名和密码的正确性,即:从已存储的用户账户信息中,查找与所述账户名对应的相关信息,从中提取该账户的密码,并与接收到的密码进行比对,如果一致继续进行后续操作,否则向客户端返回密码错误的应答。
成功完成用户账户名和密码的验证后,就可以继续执行步骤S102,发起根据社交关系数据验证客户端身份的操作。在具体实施过程中,可以采取一些策略判断是否需要发起客户端身份验证过程,例如:可以根据接收到的请求中是否携带要求进行客户端身份验证的明确指示、或者请求中提供的当前用户执行的操作类型是否为敏感业务操作(登录、支付等)、以及当前账户的安全级别等判断是否需要进行客户端身份验证,如果需要,则继续执行步骤S102。
步骤S102:获取所述客户端的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
本申请提供的利用社交关系数据进行客户端身份验证的方法,是基于这样一种判断准则,即:所述特定账户的已存社交关系数据,如果在一定程度上能够匹配上待验证客户端存储的客户端社交关系数据,则判定所述待验证客户端通过身份验证,即:所述待验证客户端是所述特定账户所有者自己的客户端设备。
本申请所述的社交关系数据,是指反映人与人之间的社交关系的数据,即:特定账户与其他用户之间的社交关联关系列表,可以这样认为,社交关系数据可以从一个侧面反映所述特定账户的身份。本申请提供的方法,就是基于社交关系数据的上述特点,根据服务器端和待验证客户端存储的社交关系数据的匹配情况,判断所述待验证客户端是否为所述特定账户所有者自己的设备,从而判定所述客户端是否通过身份验证。
例如,以社交关系数据中的电话号码列表为例,如果待验证客户端设备存储的通讯录中的电话号码列表,与所述服务器端已存的所述特定账户的社交关联电话号码列表满足一定的相似度匹配要求,则说明所述客户端设备是所述特定账户所有者自己的设备,从而可以判定所述客户端通过身份验证。服务器端的已存社交关系数据,可以是上述列举的社交关联电话号码列表,也可以是其他社交关系数据,例如:社交联系人QQ号码列表、社交联系人微信号码列表、社交联系人来往账号列表等,以及其他能够反映所述特定账户与其他用户之间的社交关联关系的数据;所述待验证客户端设备存储的客户端社交关系数据,包括:电话号码列表、QQ联系人列表、微信联系人列表、来往联系人列表、通讯录,以及其他能够反映所述特定账户与其他用户之间的社交关联关系的数据。
为了获取客户端社交关系数据和所述特定账户的已存社交关系数据的相似度匹配结果,首先要生成与特定账户对应的社交关系数据。该生成过程分为两个步骤:1)分析预先采集的数据,从中提取与所述特定账户相关联的社交关系数据;2)存储已提取的与所述特定账户相关联的社交关系数据。
1)分析预先采集的数据,从中提取与所述特定账户相关联的社交关系数据。
首先,要进行数据采集工作。采集的数据包括:账户之间资金往来的数据、转账记录、代付账记录、通讯社交数据、或者其他社交网络关系数据。这些数据的采集,可以通过采集本服务器***内部的数据来实现,也可以通过访问其他***开放的接口,获取其他服务器或***提供的各种应用数据来实现。
其次,要分析上述采集得到的数据,从中提取与所述特定账户相关联的社交关系数据,这个过程通常也称为数据清洗。
数据清洗(Data Cleaning)是数据库服务中的一项技术,数据清洗从字面上理解就是把“脏”的数据“洗掉”。随着信息处理技术的不断发展,各行各业都积累了大量的数据,为了使数据能够有效地支持组织的日常运作和决策,要求数据可靠无误,能够准确地反映现实世界的状况,就要对数据进行必要的清洗,其目的是检测数据中存在的错误和不一致,剔除其中的无效值、缺失值或者改正它们,以提高数据的质量。也即:按照一定的规则把“脏数据”“洗掉”,这就是数据清洗。
从另一个角度理解,数据清洗除了要洗掉脏数据之外,还包括对数据进行归并、挖掘和筛选,从而实现过滤掉不符合要求的数据、提取所需数据的目的。这也是本申请所述的数据清洗的主要作用。因为通过采集获取的数据,是来自各个应用的数据的集合,即:这些数据是从多个业务***或者应用中获取的,而且包含历史数据,这样就避免不了有的数据是错误的、有的数据相互之间有冲突,而有些数据是不需要的,因此必须进行必要的清洗操作。一方面,本申请所提供的方法,通过分析账户之间的资金往来数据、转账记录、代付账记录、通讯社交数据等获取社交关联电话号码、或者其他社交关系数据,那么从某种意义上说,可以认为其他与上述信息不相关的数据是所谓的“脏数据”;另一方面,本申请所提供的方法,需要从采集的数据中提取与特定账户对应的社交关系数据,那么也可以认为与特定账户无关的数据都是所谓的“脏数据”。
执行数据清洗,一方面要剔除上述两类“脏数据”,同时还要通过一定逻辑从采集的众多数据中,分析提取出所述特定账户与其他用户之间的关联关系列表。例如,经过数据清洗过程,得到以下信息:所述特定账户A与账户B有资金往来关系,而账户B登记的联系方式为电话号码1,那么就得到了与所述特定账户A有社交关联关系的电话号码1。
采用上述方式即可获取与所述特定账户A有关联(包括资金往来、通讯往来)的社交关联电话号码列表,形式如下所示:账户A|电话号码1、账户A|电话号码2等;通过数据清洗过程,也可以获取与特定账户有关联的其他社交关系数据,形式如下所示:账户A|社交联系人QQ号码1、账户A|社交联系人QQ号码2等。
由于用户相互之间的电话联络信息、资金往来数据以及各种社交关系数据都是动态变化的,因此上述数据采集过程和数据清洗过程可以采用后台处理方式定期执行,针对每个新增账户以及原有账户,及时生成或更新该账户与其他用户之间的最新的关联关系列表。
定期执行采集和清洗操作的时间间隔设置,不同的实施方式可以采用不同的取值;通过上述数据清洗过程,获取的与所述特定账户相关联的社交关系数据也不仅仅局限于与特定账户相关联的社交关联电话号码列表,还可以是与特定账户相关的社交联系人列表等,上述这些不同的方式,都只是具体实施方式的变更,都不偏离本申请的核心,因此都在本申请的保护范围之内。
2)存储已提取的与所述特定账户相关联的社交关系数据。
将通过清洗获得的所述特定账户与其他用户之间的关联关系列表等数据(即:本申请所述的社交关系数据),存放在数据库中,或者存放在其他数据文件或者数据表格中,从而就生成了所述特定账户的已存社交关系数据。上述社交关系数据的存储方式本申请不作限定,只要能够根据需要从中获取与所述特定账户对应的社交关系数据即可。
生成所述特定账户的已存社交关系数据之后,当接收到待验证客户端发送的与所述特定账户对应的社交关系数据时,就可以执行本步骤的操作,获取所述客户端的客户端社交关系数据、与所述特定账户的已存社交关系数据的相似度匹配结果。为了获取相似度匹配结果,首先要执行相似度匹配操作,该操作既可以在待验证客户端执行,也可以在实施本申请所提供方法的服务器端执行,与这两种方式相对应,获取相似度匹配结果自然也有两种方式:从所述客户端获取和所述服务器端自行计算获取,这两种方式都能够实现本申请的技术方案,下面分别对这两种方式进行说明。
1)基于客户端的相似度匹配。
采用这种方式,由所述客户端执行相似度匹配操作,所述服务器端通过执行以下两个步骤获取所述相似度匹配结果:向所述客户端发送所述特定账户的已存社交关系数据;接收所述客户端发送的相似度匹配结果。
首先,向所述客户端发送所述特定账户的已存社交关系数据。
根据特定账户信息,查找预先存储的社交关系数据,从中提取与特定账户对应的社交关系数据,然后将该数据发送给所述客户端。在本实施例中,从存储社交关系数据的数据库中,提取了与特定账户对应的社交关联电话号码列表数据,并将该数据发送给所述客户端。
在本实施例中,从预先存储的社交关系数据中,提取了与特定账户对应的社交关联电话号码列表并下发给客户端,在其他实施方式中,也可以提取与特定账户对应的其他社交关系数据,例如:社交联系人QQ号码列表或者社交联系人来往帐号列表等,并下发给客户端。
在本实施例中,待验证客户端设备是移动通讯设备,因此下发的是与特定账户对应的社交关联电话号码列表,在其他实施方式中,待验证客户端可能并不局限于移动通讯设备,这种情况下,要首先辨别待验证客户端设备的类型,如果是移动通讯设备,例如通常所说的手机或者智能手机,那么可以向所述客户端下发与特定账户对应的社交关联电话号码列表,或者是其他社交联系人列表等,如果待验证客户端是不具备电话通讯录的终端设备,例如个人电脑,那么就应该选择下发社交联系人列表,例如:社交联系人QQ号码列表,这样客户端设备才能执行相似度匹配操作。
上述下发社交关系数据的各种形式的变化,都只是具体实施方式的变更,都不偏离本申请的核心,因此都在本申请的保护范围之内。
作为最简单易行的实施方式,可以直接将与特定账户对应的社交关系数据以明文的形式发送给所述待验证客户端,即:不对数据进行加密处理。这种实施方式虽然简单,但是有比较明显的缺陷。与特定账户对应的社交关系数据,例如:社交关联电话号码列表,属于用户个人信息的一部分,从保护用户隐私的角度出发,应该尽量避免暴露给其他人,当这些社交关系数据以明文形式传输时,恶意攻击者可以通过窃听等方式获得这些信息,并可能非法散播或利用截获到的信息,从而给用户和网络带来安全威胁。为了避免出现这种情况,在向所述待验证客户端下发所述特定账户的已存社交关系数据之前,应该先进行加密处理,然后再将加密后的数据发送给所述待验证客户端。
在本实施例中,采用AES(Advanced Encryption Standard)加密算法对与特定账户对应的社交关系数据进行加密处理。AES算法,又称高级加密标准,是美国国家标准与技术研究所用于加密电子数据的规范,是一个可以用于保护电子数据的加密算法。AES高级加密标准是对称密钥加密中最流行的算法之一,是一种可逆加密算法,使用相同的密钥加密和解密数据。在本实施例中,采用特定的密钥对待发送的社交关联电话号码列表进行AES加密处理,那么接收该加密数据的移动通讯终端设备也采用同样的密钥进行解密处理,即可得到加密前的原始的社交关联电话号码列表数据。
在本实施例中,采用AES加密算法对特定账户的已存社交关系数据进行加密处理,在其他实施方式中,也可以采用其他加密算法,例如:3DES加密算法等。至于密钥的管理,服务器端和客户端可以采用预先设置好的相同的固定密钥,也可以采用定期更新并分发密钥的方式,提供更完善的安全性保障。是否采用加密算法、采用何种加密算法、以及与所选加密算法对应的密钥管理方式,都可以根据具体实施方式的需求进行相应的调整,这些都不影响本申请的核心,本申请不作具体的限定。
然后,接收所述客户端发送的相似度匹配结果。
所述客户端接收到与特定账户对应的社交关系数据后,与该客户端本地的客户端社交关系数据进行相似度匹配,并上传所述相似度匹配结果,实施本申请提供方法的服务器端就会接收到所述客户端发送的相似度匹配结果。
本申请所述的相似度匹配结果包括匹配数和/或匹配度;所述匹配数是指,所述特定账户的已存社交关系数据与所述客户端社交关系数据一致的条目数量;所述匹配度是指,所述匹配数与所述特定账户的已存社交关系数据的条目总数的比值。如果向所述客户端发送的是所述特定账户的社交关联电话号码列表,那么所述客户端可以从客户端通讯录中提取客户端电话号码列表,并将接收到的社交关联电话号码列表与客户端电话号码列表逐条进行比对,两者一致的条目数量即为匹配数;另外,客户端也可以直接将接收到的社交关联电话号码列表与本地通讯录进行比对,如果所述社交关联电话号码列表中的某个电话号码在本地通讯录的某条记录中出现,即可认为两条数据匹配成功,即满足本申请所述的一致性,在这种情况下可以这样理解,所述社交关联电话号码列表中的电话号码在客户端通讯录中出现的条目数量即为本申请所述的匹配数。如果向所述客户端发送的是所述特定账户的社交联系人QQ号码列表,客户端可以采取与上述类似的方式与本地QQ联系人列表进行比对,从而得到匹配数。
在本实施例中,所述特定账户的已存社交关系数据(即发送给所述客户端的社交关系数据)是与所述特定账户相关联的社交关联电话号码列表,其中共包括10个电话号码,这10个电话号码中有5个与客户端通讯录中的电话号码一致,因此在本步骤中接收到的所述客户端发送的相似度匹配结果为:匹配数为5,匹配度为5/10=0.5。
在本实施例中,待验证客户端设备发送的相似度匹配结果包括了两个数据:匹配数和匹配度,在其他实施方式中,因为这两个数据各自都可以反映所述特定账户的已存社交关系数据和客户端社交关系数据的匹配情况,因此待验证客户端也可以仅上报其中一个数据,所述服务器端根据上报的这一数据判断客户端是否通过身份验证,同样也可以实现本申请的技术方案。但是考虑到匹配数和匹配度这两个数据的具体含义的差异,匹配数是一个绝对值,表征的是数据条目一致的个数,而匹配度是一个比值,表征的是匹配的程度,也可以理解为匹配成功率,两者并不是同一个维度的概念,那么作为一种优选实施方式,所述客户端应该同时上报这两个数据,这样便于所述服务器端采用更为准确的策略判定所述客户端是否能够通过身份验证。
当然,在其他实施方式中,也可以不采用匹配数和/或匹配度作为相似度匹配结果,而是采用其他类似的参数,只要能够表征所述特定账户的已存社交关系数据与所述客户端社交关系数据的相似度即可,同样可以实现本申请的技术方案,因此也在本申请的保护范围之内。
在本实施例中,所述客户端上报的是相似度匹配结果,即:匹配数和/或匹配度,然后由所述服务器端根据预先设定的阈值对所述客户端进行身份验证(关于这部分说明请参见步骤S103中的相关描述)。作为本实施例的一种变通,也可以将预先设定的阈值下发给所述客户端,所述客户端计算出匹配数和匹配度后,直接根据所述阈值自行判断是否通过身份验证并上报该结果。如果是这种情况,那么在本步骤中接收到的就不是匹配数和/或匹配度,而是代表相似度匹配结果的更为进一步的指示信息,即:所述客户端是否通过身份验证的明确指示。上述下发阈值到客户端的实施方式,并不偏离本申请的核心,也在本申请的保护范围之内。
上述预先设定的阈值,可以在向所述客户端发送所述特定账户的已存社交关系数据时一并发送,也可以预先存放在客户端中,这两种方式都可以实现上述实施方式,后者可以避免每次都要执行发送阈值的操作,从而简化操作步骤,前者则可以根据待发送的已存社交关系数据的具体情况灵活地调整阈值的设置,两者各有优缺点,可以根据具体的实施需求进行相应的选择。
2)基于服务器端的相似度匹配。
前面介绍了在客户端执行相似度匹配的方式,本申请所提供的利用社交关系数据验证客户端身份的方法,既可以采用上述方式,也可以采用在服务器端执行相似度匹配的方式,两种方式都可以实现本申请的技术方案。
采用基于服务器端的相似度匹配,需要执行两个步骤获取所述相似度匹配结果:接收所述客户端发送的所述客户端存储的客户端社交关系数据;计算所述客户端存储的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
首先,接收所述客户端发送的所述客户端存储的客户端社交关系数据。
采用基于服务器端的相似度匹配方式,需要客户端将其本地存储的客户端社交关系数据发送给实施本申请所提供方法的服务器端,在具体的实施方式中,所述客户端可以在向所述服务器端发送账户名和密码的同时,也上传本地存储的该账户的客户端社交关系数据;或者当所述服务器端完成对账户名和密码的验证后,发送要求所述客户端提供所述账户的客户端社交关系数据的指示,所述客户端根据接收到的指示再上传客户端本地存储的客户端社交关系数据。这两种方法都是可行的,只要所述客户端和所述服务器端预先协商好具体的交互流程即可。
接收到所述客户端发送的本地存储的客户端社交关系数据后,应该首先判断接收到的数据是否需要解密,如果需要则执行相应的解密处理。例如:如果接收到的是经可逆加密算法AES加密后的数据,在本步骤中就需要采用加密时采用的相同的密钥执行解密处理。具体采用何种加解密算法,不是本申请的核心,本申请不作具体的限定,只要所述客户端和所述服务器端提前协商好,或者在接收到的数据中提供明确的指示,让所述服务器端能够进行正确地解密即可。
然后,计算所述客户端存储的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
通过清洗操作,已经生成了特定账户的已存社交关系数据,为了进行本步骤中的相似度匹配操作,需要先提取特定账户的已存社交关系数据,例如,如果预先获取的社交关系数据存储在关系型数据库中,那么本步骤中可以采用SQL语句从中提取所需数据,不仅要提取与所述特定账户对应的已存社交关系数据,并且应该从中提取与所述客户端上传的社交关系数据类型一致的社交关系数据。例如:客户端上传的是客户端通讯录或者是从客户端通讯录中提取的的电话号码列表,那么在本步骤中就应该从与特定账户对应的全部社交关系数据中提取社交关联电话号码列表。
接下来,就可以计算所述客户端提供的客户端社交关系数据、与所述特定账户的已存社交关系数据的相似度匹配结果了。进行相似度匹配的过程,就是将上述两种来源的数据(一种来自客户端,一种来自服务器端)进行比对的过程,判断已存社交关系数据与客户端社交关系数据一致的条目数量,也就是本申请所述的匹配数。例如,如果所述客户端上传的客户端社交关系数据是客户端通讯录,所述特定账户已存的社交关联电话号码列表包括10个电话号码,而这10个电话号码中有5个在客户端通讯录中出现,则可以认为所述特定账户的社交关联电话号码列表中有5个数据条目与客户端的社交关系数据一致,因此在本例子中匹配数就是5。
在具体实施过程中,可以采用最为简单易行的方式,即:将所述客户端上传的客户端社交关系数据与所述特定账户的已存社交关系数据逐一进行匹配,匹配成功则执行累加匹配数的操作;也可以通过对数据进行排序、或者采用类似树状数据结构等方式组织数据,从而达到缩短匹配时间、提高匹配效率的目的。具体的匹配方式不是本申请的核心,本申请不对此作具体的限定。
本申请所述的相似度匹配结果,除了上述匹配数之外,还包括匹配度。所谓匹配度是指,所述匹配数与所述特定账户的已存社交关系数据的条目数量的比值,该数据反映的是匹配程度。在上文所述的例子中,匹配数是5,所述特定账户已存的社交关联电话号码列表包括10个电话号码,即:已存社交关系数据的条目总数为10,因此匹配度为:5/10=0.5。
所述匹配数和匹配度都可以反映所述客户端社交关系数据和所述特定账户的已存社交关系数据的匹配情况,因此在具体的实施过程中,可以只计算其中一个数据,并在后续的步骤S103中根据该数据判断客户端设备是否通过身份验证。为了在步骤S103中采用更为灵活、准确的判断策略,作为一种优选实施方式,在本步骤中同时计算匹配数和匹配度这两个数值。
上面描述了获取相似度匹配结果的两种方式,这两种方式的主要区别在于计算相似度匹配结果的场所不同,方式一在客户端进行相似度匹配并将结果上传给服务器端,方式二使用客户端上传的客户端社交关系数据直接在服务器端计算相似度匹配结果,从功能上看,这两种方式是可以相互替换的,不论采用哪种方式都能够实现本申请的技术方案。从实现细节来看,两种方式各有特点,基于客户端的匹配方式,其优点在于,由于所述服务器端清洗获得的社交关系数据是比较有限的,因此向所述客户端下发的数据传输量相对较小,而且因为客户端不必上传本地存储的客户端社交关系数据,因此不会用户个人隐私数据;基于服务器端的匹配方式,其优点在于,处理过程更为可靠,并且可以通过保存客户端上传的客户端社交关系数据从而得到关于特定账户的更完整可靠的社交关系数据,但是客户端上传的客户端社交关系数据的数据传输量相对较大,而且涉及用户个人隐私数据的安全性问题。鉴于上述两种方式各自的特点,在具体实施过程中,可以权衡利弊,选择相对适合的方式。
步骤S103:判断所述相似度匹配结果是否满足预先设定的通过条件;若是,则判定所述客户端通过身份验证。
执行完上述步骤S102后,已经获取了客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果,在本步骤中,可以进一步根据预先设定的通过条件,判断所述客户端能否通过身份验证。
本申请所述的预先设定的通过条件,是指待验证客户端要想通过身份验证,所述相似度匹配结果应该满足的条件,具体地说,是指在步骤S102中获取的匹配数和匹配度应该分别大于(也可以设置为大于等于)预先设置的匹配数通过阈值和匹配度通过阈值,才能够判定所述客户端通过身份验证。在本实施例中,步骤S102中获取的匹配数为5,匹配度为0.5,预先设置的匹配数通过阈值为4,匹配度通过阈值为0.4,因此在本实施例中,判定待验证客户端通过了所述身份验证。此处预先设置的匹配数通过阈值和匹配度通过阈值,是本实施例中采用的经验值,在其他实施方式中,可以根据所述特定账户的已存社交关系数据的条目数量以及类型,调整这两个阈值的设置,以获取更为准确的判断结果。
在本实施例中,采用了比较严格的判定策略,即在步骤S102中获取了匹配数和匹配度两个数值,并且在本步骤中要求匹配数和匹配度同时大于对应的通过阈值,才能够判定所述待验证客户端通过身份验证,这是一种相对保险的策略,能够减少误判的几率。
在其他实施方式中,也可以设定其他相对宽松的通过条件。如果在步骤S102中仅获取了匹配数和匹配度中的一个数值,例如:客户端仅上报了匹配数,那么在本步骤中只需判定已获取的该数值是否大于与其对应的通过阈值即可;或者,可以采用设定一个主数据的方式,即在步骤S102中虽然同时获取了匹配数和匹配度两个数值,但是在本步骤中,并不要求两者同时大于各自对应的通过阈值,而是采用以其中一个数值为主的方式,例如可以设置匹配度作为主数据,即:只要匹配度大于预先设置的匹配度通过阈值,那么不管匹配数是否大于预先设置的匹配数通过阈值,都可以判定所述客户端通过身份验证。或者,匹配数和匹配度中只要有任意一个大于对应的通过阈值,即可判定所述待验证客户端通过身份验证。上述实施方式的变更,相对于本实施例所采用的判定方式要宽松一些,但是只要设置适当的通过阈值,同样可以实现本申请的技术方案,因此这些实施方式的变更,都不影响本申请的核心,都在本申请的保护范围之内。
作为一种可选的实施方式,如果所述相似度匹配结果不满足预先设定的通过条件,则可以进一步判断所述相似度匹配结果是否满足预先设定的报警条件;若是,则阻止所述客户端通过身份验证,并采取报警措施。具体地说,如果在步骤S102中获取的匹配数和匹配度分别小于(也可以设置为小于等于)预先设置的匹配数报警阈值和匹配度报警阈值,说明待验证客户端设备可能不是所述特定账户所有者自己的设备,而有可能是盗用者的设备,因此阻止所述客户端通过身份验证,并采取报警措施。
与前面描述的通过阈值类似,匹配数报警阈值和匹配度报警阈值也是预先设置好的,可以采用固定的经验值,也可以根据具体的实施情况进行动态调整。对于是否满足报警条件的判定,可以采用比较严格的方式,即:要求匹配数和匹配度都小于各自对应的报警阈值;也可以要求匹配数和匹配度中只要有一个数值低于对应的报警阈值,就可以阻止所述客户端通过身份验证并采取报警措施。
在前面步骤S102关于基于客户端的匹配方式的描述中,提到了本申请的一种实施方式,即:所述服务器端将用于判定客户端身份的阈值(包括上述匹配数通过阈值、匹配度通过阈值、匹配数报警阈值、匹配度报警阈值)下发到所述客户端,所述客户端计算出匹配数和匹配度后,直接根据所述阈值自行判断是否通过身份验证,并将结果上报所述服务器端。如果采用这种实施方式,那么在步骤S102中接收到的即为所述客户端是否通过身份验证的明确指示,例如:所述客户端通过身份验证,或者所述客户端未通过身份验证并要求报警。那么在本步骤中,就不必执行上述根据阈值判定所述客户端是否通过身份验证的步骤了。
所述通过阈值和所述报警阈值可以设置为相同的值,也可以设置为不同的值,即:通过阈值大于报警阈值,以匹配度为例:预先设置的匹配度通过阈值为0.5,预先设置的匹配度报警阈值为0.2,那么如果相似度匹配结果大于(或者大于等于)通过阈值,则判定所述客户端通过身份验证;如果相似度匹配结果小于(或者小于等于)报警阈值,则阻止所述客户端通过身份验证并报警;如果相似度匹配结果落在两者之间,则判定所述客户端没有通过身份验证,但是并不采取报警措施。
作为一种可选的实施方式,如果相似度匹配结果落在通过阈值和报警阈值之间,所述服务器端可以采取更为积极的策略进行处理:触发一次新的计算过程,计算另外一种社交关系数据的匹配情况,并根据新的匹配结果作进一步的判定。例如:如果本次的相似度匹配结果是根据社交关联电话号码列表获取的,那么所述服务器端就可以再次下发一种社交关系列表,例如:社交联系人QQ号码列表,或者要求所述客户端上传社交联系人QQ号码列表,并获取基于该社交关系数据的相似度匹配结果,然后再与所述阈值进行比对,判断所述客户端是否通过身份验证。上述处理方式,可以根据每次的判定结果以及所述服务器端的策略,执行一次或者数次,其目的就是为了更为准确地判断所述客户端的身份。
执行完本步骤的处理,已经明确得出了所述客户端是否通过身份验证的结论,所述服务器端根据该结论执行相应的操作即可。在本实施例中,如果所述结论是通过,则向所述客户端发送通过身份验证的应答;如果所述结论是阻止所述客户端通过身份验证并报警,则向所述客户端发送身份验证失败的应答,并锁定所述特定账户,然后通知账户所有者;其他情况,只需向所述客户端发送身份验证失败应答即可。在其他实施方式中,也可以根据具体的实施需求,执行不同于本实施例的相应操作。
在上述的实施例中,提供了一种利用社交关系数据验证客户端身份的方法,与之相对应的,本申请还提供一种利用社交关系数据验证客户端身份的装置。请参看图2,其为本申请的一种利用社交关系数据验证客户端身份的装置实施例示意图。由于装置实施例基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种利用社交关系数据验证客户端身份的装置,包括:验证请求接收单元201,用于接收待验证客户端发送的对应特定账户的身份验证请求;匹配结果获取单元202,用于获取所述客户端的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果;通过判断单元203,用于判断所述相似度匹配结果是否满足预先设定的通过条件;若是,则判定所述客户端通过身份验证。
可选的,所述装置还包括:
社交关系数据生成单元,用于获取并存储所述特定账户的社交关系数据;
所述社交关系数据生成单元包括:
分析提取子单元,用于分析预先采集的数据,从中提取与所述特定账户相关联的社交关系数据;
存储子单元,用于存储已提取的与所述特定账户相关联的社交关系数据;该社交关系数据即为所述特定账户的已存社交关系数据。
可选的,所述匹配结果获取单元包括:
社交关系数据发送子单元,用于向所述客户端发送所述特定账户的已存社交关系数据;
匹配结果接收子单元,用于接收所述客户端发送的所述客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
可选的,所述匹配结果获取单元包括:
第一社交关系数据接收子单元,用于接收所述客户端发送的所述客户端存储的客户端社交关系数据;
第一匹配结果计算子单元,用于计算所述客户端存储的客户端社交关系数据与所述特定账户的已存社交关系数据的相似度匹配结果。
可选的,所述装置还包括:
报警判断单元,用于判断所述相似度匹配结果是否满足预先设定的报警条件;若是,则阻止所述客户端通过身份验证,并采取报警措施。
可选的,所述匹配结果获取单元获取的所述相似度匹配结果,包括匹配数和/或匹配度;
所述匹配数是指,所述特定账户的已存社交关系数据与所述客户端社交关系数据一致的条目数量;
所述匹配度是指,所述匹配数与所述特定账户的已存社交关系数据的条目数量的比值。
相应的,所述通过判断单元判断所述相似度匹配结果是否满足预先设定的通过条件,具体是指,
判断所述匹配数和匹配度是否分别大于预先设置的匹配数通过阈值和匹配度通过阈值;或者,
判断所述匹配数是否大于预先设置的匹配数通过阈值;或者,
判断所述匹配度是否大于预先设置的匹配度通过阈值。
可选的,所述报警判断单元判断所述相似度匹配结果是否满足预先设定的报警条件,具体是指,
判断所述匹配数和匹配度是否分别小于预先设置的匹配数报警阈值和匹配度报警阈值;或者,
判断所述匹配数是否小于预先设置的匹配数报警阈值;或者,
判断所述匹配度是否小于预先设置的匹配度报警阈值。
可选的,所述匹配结果获取单元进行相似度匹配所用的社交关系数据包括:电话号码、QQ号码、微信号码、来往帐号、通讯录、或者代付账记录。
与上述的利用社交关系数据验证客户端身份的方法相对应,本申请还提供一种客户端身份验证方法。请参考图3,其为本申请提供的一种客户端身份验证方法的实施例的流程示意图,本实施例与第一实施例内容相同的部分不再赘述,请参见实施例一中的相应部分。本申请提供的一种客户端身份验证方法包括:
步骤S301:向服务器端发送特定账户的客户端身份验证请求。
当用户要使用特定账户在所述客户端设备上执行某些操作的时候,例如:登录、支付或者绑定等操作,根据客户端应用程序的需求,用户会在相应的界面上输入账户名、密码、以及其他所需的信息,客户端应用会将该身份验证请求发送给实施本申请的利用社交关系数据验证客户端身份方法的服务器端,所述服务器端首先验证账户名和密码是否正确,然后根据用户要执行的操作以及所述特定账户的安全级别等判断是否要启动对客户端身份的验证。
步骤S302:向所述服务器端发送所述服务器端利用社交关系数据对所述客户端进行身份验证所需的信息。
实施例一中描述了执行相似度匹配操作的两种方式:基于客户端的相似度匹配方式、和基于服务器端的相似度匹配方式,与这两种方式相对应,所述客户端向所述服务器端提供验证客户端身份所需的信息,也采取两种方式,这两种方式都能够实现本申请的技术方案,下面分别对这两种方式进行说明。
1)基于客户端的相似度匹配。
采用基于客户端的相似度匹配方式,所述客户端为所述服务器端提供利用社交关系数据对所述客户端进行身份验证所需的信息,需要执行以下三个步骤:接收服务器端发送的社交关系数据、计算相似度匹配结果、发送相似度匹配结果。
首先,接收服务器端发送的所述特定账户的社交关系数据。
所述服务器端完成对账户名和密码的验证后,如果判定需要进行客户端身份验证,则会主动下发所述特定账户的社交关系数据,所述客户端接收数据后,首先判断接收到的数据是否进行过加密处理,如果是则执行相应的解密处理。关于加解密算法的相关说明,请参见实施例一中的相应描述。
然后,计算本地存储的社交关系数据与所述接收的所述特定账户的社交关系数据的相似度匹配结果。
接收所述服务器端发送的所述特定账户的社交关系数据后,先辨别所述社交关系数据的类型,即:是哪一种社交关系数据,然后读取所述客户端设备本地存储的同样类型的客户端社交关系数据,并进行相似度匹配。进行相似度匹配的过程,就是将上述两种来源的数据(一种是服务器端下发的、一种是客户端本地存储的)进行比对的过程,判断服务器端下发的特定账户的社交关系数据(即:服务器端已存的特定账户的社交关系数据)与客户端本地存储的客户端社交关系数据一致的条目数量,也就是本申请所述的匹配数,还可以进一步计算匹配度。关于匹配数和匹配度的相关说明,请参见实施例一中的相关描述,此处不再赘述。
在本实施例中,所述服务器端下发的特定账户的社交关系数据是社交关联电话号码列表,本实施例中的移动通讯设备,从本地存储的客户端通讯录中提取客户端电话号码列表,并将接收到的社交关联电话号码列表与客户端电话号码列表进行比对,累计两类数据一致的条目数量,从而得到匹配数和匹配度。当然,本实施例中的移动通讯设备也可以直接将接收到的社交关联电话号码列表与客户端通讯录进行比对,判断社交关联电话号码列表中的电话号码在客户端通讯录中出现的条目数量,从而得到匹配数和匹配度。在其他实施方式中,如果所述服务器端发送的是其他社交关系数据,例如:特定账户的社交联系人QQ号码列表,那么所述客户端就应该读取本地存储的QQ联系人列表,并计算相似度匹配结果。
最后,向所述服务器端发送所述相似度匹配结果。
在本实施例中,所述移动通讯设备直接向所述服务器端发送已经计算出的匹配数和匹配度,供所述服务器端用于判断所述客户端的身份。在不同的实施方式中,所述客户端也可以仅向所述服务器端发送匹配数或者匹配度中的一个数据,所述服务器端根据接收到的匹配数或者匹配度,采用适当的策略同样可以判断所述客户端的身份,可以实现本申请的技术方案。
在其他实施方式中,根据相似度匹配结果判断所述客户端身份的操作,也可以在客户端执行。如果所述服务器端在下发所述特定账户的社交关系数据的同时,也下发了用于判定所述客户端身份的通过阈值和报警阈值,或者这两类阈值已经预先存储在所述客户端设备中,那么所述客户端就可以将计算得到的相似度匹配结果与通过阈值进行比较,从而判断所述客户端是否通过身份验证;如果没有通过身份验证,那么可以继续将相似度匹配结果与报警阈值进行比较,判断是否需要报警。因为相似度匹配结果包括匹配数和匹配度,相应的通过阈值和报警阈值也都分别包括两个对应的数值,因此在判断是否通过或是否需要报警时,可以采取与所述服务器端类似的相对严格或者宽松的判断策略,关于这部分请参见实施例一中的相关说明,此处不再赘述。
如果采用上述实施方式,那么所述客户端向所述服务器端发送的相似度匹配结果就不是匹配数和/或匹配度,而是代表相似度匹配结果的更为进一步的指示信息,即:所述客户端是否通过身份验证、以及如果没有通过是否需要报警的明确指示。上述下发或者预置阈值到客户端的实施方式,并不偏离本申请的核心,也在本申请的保护范围之内。
2)基于服务器端的相似度匹配。
采取这种方式,相似度匹配是在所述服务器端完成的,因此所述客户端的任务相对简单,只需向所述服务器端发送本地存储的所述特定账户的客户端社交关系数据就可以了。
所述客户端,可以在发送所述身份验证请求的同时上传本地存储的所述特定账户的客户端社交关系数据,也可以在接收到所述服务器端完成对账户名和密码的验证、并要求所述客户端上传社交关系数据的指示后,向所述服务器端发送所述特定账户的客户端社交关系数据。
对于不同的客户端设备,上传的社交关系数据的类型是不同的。如果所述客户端是移动通讯设备,那么可以上传所述移动通讯设备本地存储的客户端通讯录,QQ联系人列表、微信联系人列表等社交关系列表,为了便于所述服务器端计算以及减少数据传输量,也可以从上述数据中提取出对应的号码列表上传给所述服务器端,例如:客户端电话号码列表、QQ号码列表、微信号码列表等;但是如果所述客户端设备是个人电脑等没有通讯录的终端设备,那么则只能上传QQ联系人列表、微信联系人列表等社交关系列表或者是对应的号码列表。
作为最简单易行的实施方式,所述客户端可以不对客户端社交关系数据进行加密处理,即:客户端社交关系数据在空中接口或者是有线传输介质中以明文形式传输,那么可能会被恶意攻击者通过窃听等方式获取,导致用户隐私的泄漏和散播。为了避免出现这种情况,所述客户端设备在上传社交关系数据时,通常要采用加密的方式,所述服务器端接收后先进行相应的解密处理然后再使用数据,采用这种实施方式可以为用户隐私数据的传输过程提供安全保障。
步骤S303:接收所述服务器端返回的所述客户端是否通过身份验证的应答。
接收所述服务器端返回的应答,并根据应答的内容执行相应的客户端操作。如果所述服务器端返回的应答为,所述客户端通过身份验证,则说明所述客户端是所述特定账户所有者的设备,因此允许所述客户端继续执行相关的敏感操作,例如:登录、支付、绑定或者是换绑等操作;如果所述服务器端返回的应答为,所述客户端未通过身份验证,则说明所述客户端不是所述特定账户所有者的设备,因此禁止所述客户端继续执行相关的敏感操作,同时也可以在界面上采用对话框等方式告知客户端使用者未通过客户端身份验证这一情况。
在上述的实施例中,提供了一种客户端身份验证方法,与之相对应的,本申请还提供一种客户端身份验证装置。请参看图4,其为本申请的一种客户端身份验证装置的实施例示意图。由于装置实施例基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种客户端身份验证装置,包括:验证请求发送单元401,用于向服务器端发送特定账户的客户端身份验证请求;验证信息发送单元402,用于向所述服务器端发送所述服务器端利用社交关系数据对所述客户端进行身份验证所需的信息;验证结果接收单元403,用于接收所述服务器端返回的所述客户端是否通过身份验证的应答。
可选的,所述验证信息发送单元,具体用于向所述服务器端发送本地存储的客户端社交关系数据。
可选的,所述验证信息发送单元包括:
第二社交关系数据接收子单元,用于接收所述服务器端发送的所述特定账户的社交关系数据;
第二匹配结果计算子单元,用于计算该客户端本地的客户端社交关系数据与所述接收的所述特定账户的社交关系数据的相似度匹配结果;
匹配结果发送子单元,用于向所述服务器端发送所述相似度匹配结果。
本申请实施例还提供了一种利用社交关系数据验证客户端身份的***,如图5所示,该***包括上述实施例所述的利用社交关系数据验证客户端身份的装置501和客户端身份验证装置502。所述利用社交关系数据验证客户端身份的装置通常部署于服务器,但并不局限于服务器,也可以是能够实现所述利用社交关系数据验证客户端身份的方法的任何设备;所述客户端身份验证装置通常部署于移动通讯设备、个人电脑、PAD、iPad等终端设备。例如,客户端身份验证装置部署在智能手机上,能够上传本地存储的社交关系数据、或者上传服务器下发的社交关系数据与客户端社交关系数据的相似度匹配结果;所述利用社交关系数据验证客户端身份的装置部署在服务器上,通过计算智能手机上传的客户端社交关系数据与特定账户的已存社交关系数据的相似度匹配结果、或者接收智能手机上报的相似度匹配结果,并将相似度匹配结果与预先设定的通过阈值进行比较,从而判断智能手机是否能够通过身份验证,如果是,则说明该智能手机是所述特定账户所有者自己的设备,可以授权执行相关的敏感操作。
本申请提供的利用社交关系数据验证客户端身份的方法、客户端身份验证方法、以及相应装置和***,通过获取客户端设备存储的客户端社交关系数据、与特定账户的已存社交关系数据的相似度匹配结果,并将该匹配结果与预先设定的阈值进行比对,从而判定所述客户端设备是否通过身份验证,即:所述客户端设备是否为所述特定账户所有者自己的设备,并根据判定结果进行相应的授权操作或者是报警操作,从而能够避免对客户端设备的错误授权,有效保障用户账户的安全性。
本申请虽然以较佳实施例公开如上,但其并不是用来限定本申请,任何本领域技术人员在不脱离本申请的精神和范围内,都可以做出可能的变动和修改,因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
2、本领域技术人员应明白,本申请的实施例可提供为方法、***或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。