验证方法、验证平台及客户端与流程

本发明涉及信息技术领域，尤其涉及一种验证方法、验证平台及客户端。

背景技术：

随着信息技术的发展互联网的兴起，人们利用网络进行社交、利用网络进行消费、利用网络进行学习及利用网络进行理财。然而这些网络活动，通常会涉及到很多信息的验证，如用户身份验证，用户鉴权验证等各种验证。在现有技术中通常验证，一般为用户自己输入验证密钥等。通常这种验证方式较为呆板，验证问题和验证答案一旦设置，若非专门设置更改，一般都是静态的。这样的话，非法用户可以采用暴力验证等技术手段，窃取所述验证密钥；从而安全性较低。同时合法用户的验证密钥一旦失窃，非法用户利用该验证密钥也能验证通过。若合法用户忘记了验证密钥，通常可能需要通过较为繁琐的过程才能找到验证密钥，显然合法用户必须牢记自己的验证密钥，否则可能无法通过验证，或验证过程相当麻烦。

技术实现要素：

有鉴于此，本发明实施例期望提供一种验证方法、验证平台及客户端，能够提验证的安全性。

为达到上述目的，本发明的技术方案是这样实现的：

本发明实施例第一方面提供一种验证方法，所述方法包括：

基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

向所述验证协助用户发送验证协助请求；

接收所述验证协助用户基于所述验证协助请求返回的验证信息；

将至少部分所述验证信息发送给待验证用户；

接收所述验证用户基于所述验证信息形成的验证反馈；

基于所述验证反馈确定是否通过验证。

基于上述方案，所述验证信息包括验证问题和验证答案；其中，所述验证问题为待发送给待验证用户的验证信息；

所述基于所述验证反馈确定是否通过验证，包括：

将所述验证反馈与所述验证答案进行核对，形成核对结果；

若核对结果满足验证通过条件，则确定通过验证。

基于上述方案，所述验证信息包括验证问题；

所述基于所述验证反馈确定是否通过验证，包括：

将所述验证反馈发送给所述验证协助用户；

接收所述协助验证用于基于所述验证反馈给出的验证评价；

基于所述验证评价确定是否通过验证。

基于上述方案，所述验证信息包括验证问题；其中，所述验证问题包括从预先设置的验证题库中选择的验证问题。

基于上述方案，所述方法还包括：

向所述验证协助用户发送形成所述验证信息的备选验证问题。

基于上述方案，所述基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户，包括：

基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

基于上述方案，所述基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户，包括：

基于所述社交属性和/或用户属性，选择满足所述选择要求的社交用户作为备选用户；

向所述待验证用户发送所述备选用户；

接收所述待验证用户基于所述备选用户形成的选择指示；

基于所述选择指示确定所述验证协助用户。

基于上述方案，所述基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户，包括：

按照所述选择策略为所述社交属性和/或用户属性赋予评分值；

确定所述社交属性和/或用户属性的评分权值；

基于所述评分值与所述评分权值确定表征验证可信度的函数值；

基于所述函数值确定所述验证协助用户。

本发明实施例第二方面提供一种验证方法，所述方法包括：

从验证平台接收验证协助用户形成的至少部分所述验证信息；

输出从所述验证平台接收的所述验证信息；

基于所述验证信息及用户指示，形成验证反馈；

将所述反馈发送给所述验证平台；其中，所述验证反馈用于供所述验证平台确定是否通过验证。

基于上述方案，所述方法还包括：

从社交关系中选择社交用户作为验证协助用户；

将所述验证协助用户的信息发送给验证平台。

本发明实施例第三方面提供一种验证方法，所述方法包括：

接收验证平台发送协助待验证用户进行验证的验证协助请求；

基于用户指示形成响应所述验证协助请求的验证信息；其中，所述验证信息供所述验证平台对待验证用户进行验证；

将所述验证信息发送给所述验证平台。

基于上述方案，所述验证信息包括验证问题和验证答案。

基于上述方案，所述方法还包括：

接收所述验证平台转发的验证反馈；

输出验证反馈；

基于用户指示确定出对所述验证反馈的验证评价；

将所述验证评价发送给所述验证平台。

本发明实施例第四方面提供一种验证平台，所述验证平台包括：

选择单元，用于基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

第一发送单元，用于向所述验证协助用户发送验证协助请求；

第一接收单元，用于接收所述验证协助用户基于所述验证协助请求返回的验证信息；

第二发送单元，用于将至少部分所述验证信息发送给待验证用户；

第二接收单元，用于接收所述验证用户基于所述验证信息形成的验证反馈；

验证单元，用于基于所述验证反馈确定是否通过验证。

基于上述方案，所述验证信息包括验证问题和验证答案；其中，所述验证问题为待发送给待验证用户的验证信息；

所述验证单元，具体用于将所述验证反馈与所述验证答案进行核对，形成核对结果；若核对结果满足验证通过条件，则确定通过验证。

基于上述方案，所述验证信息包括验证问题；

所述验证平台，具体用于将所述验证反馈发送给所述验证协助用户；接收所述协助验证用于基于所述验证反馈给出的验证评价；基于所述验证评价确定是否通过验证。

基于上述方案，所述选择单元包括：

提取模块，用于基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

选择模块，用于基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

基于上述方案，所述选择模块，具体用于基于所述社交属性和/或用户属性，选择满足所述选择要求的社交用户作为备选用户；向所述待验证用户发送所述备选用户；接收所述待验证用户基于所述备选用户形成的选择指示；基于所述选择指示确定所述验证协助用户。

基于上述方案，所述选择模块，具体用于按照所述选择策略为所述社交属性和/或用户属性赋予评分值；确定所述社交属性和/或用户属性的评分权值；基于所述评分值与所述评分权值确定表征验证可信度的函数值；基于所述函数值确定所述验证协助用户。

本发明实施例第五方面提供一种客户端，所述客户端包括：

第三接收单元，用于从验证平台接收验证协助用户形成的至少部分所述验证信息；

输出单元，用于输出从所述验证平台接收的所述验证信息；

形成单元，用于基于所述验证信息及用户指示，形成验证反馈；

第三发送单元，用于将所述反馈发送给所述验证平台；其中，所述验证反馈用于供所述验证平台确定是否通过验证。

本发明实施例第六方面提供一种客户端，所述客户端包括：

第四接收单元，用于接收验证平台发送协助待验证用户进行验证的验证协助请求；

响应单元，用于基于用户指示形成响应所述验证协助请求的验证信息；其中，所述验证信息供所述验证平台对待验证用户进行验证；

第四发送单元，用于将所述验证信息发送给所述验证平台。

本发明实施例所述验证方法、验证平台及客户端，在进行验证时，将动态确定验证协助验证用户，由验证协助用户提供进行验证的验证信息，这样的话，相当于动态的形成验证信息，缓解了非法用户盗取静态验证信息导致的验证安全性低的问题。与此同时，待验证用户也不用记忆验证密钥，也可以避免了因验证密钥失窃或忘记导致的验证烦恼，提高了用户验证满意度。

附图说明

图1为本发明实施例提供的第一种验证方法的流程示意图；

图2为本发明实施例提供的一种基于验证反馈确定是否验证通过的流程示意图；

图3为本发明实施例提供的第二种验证方法的流程示意图；

图4为本发明实施例提供的另一种基于验证反馈确定是否通过验证的流程示意图；

图5为本发明实施例提供的第三种验证方法的流程示意图；

图6为本发明实施例提供的第四种验证方法的流程示意图；

图7为本发明实施例提供第一种验证平台的结构示意图；

图8为本发明实施例提供的第一种客户端的结构示意图；

图9为本发明实施例提供的第二种客户端的结构示意图；

图10为本发明实施例提供的第五种验证方法的流程示意图；

图11为本发明实施例提供第二种验证平台的结构示意图。

具体实施方式

以下结合说明书附图及具体实施例对本发明的技术方案做进一步的详细阐述。

方法实施例一：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

本实施例所述的验证方法可适用于验证平台中，这里的验证平台可为微信服务平台、QQ服务平台、财付通平台、信贷平台或支付宝平台等。本实施例中所述的待验证用户和所述验证协助用户可为注册或等级在验证平台的账号。 如所述待验证用户和所述验证协助用户都可为注册在QQ服务平台的QQ账号。

所述验证需求可为基于所述待验证用户发送的验证请求确定的，也，可以是响应用户其他操作时确定的。例如，用户向财付通平台借贷请求；财付通平台在确定是否响应向该用户进行借贷的过程中，这个时候就会产生对用户进行身份验证的验证需求。

在本实施例步骤S110中当有验证需求时，将从该用户的社交关系中选择1个或多个用户协助本次对该用户的验证。

当选择出所述验证协助用户之后，所述验证平台会向用验证协助用户发送验证协助请求。通常该验证协助请求中可包括待验证用户的身份信息等。所述验证协助请求还可包括进行此次验证的目的，如是为协助其他用户进行借贷验证等。所述验证协助请求还可携带有提示验证协助用户的验证义务及协助验证操作信息等。

如验证协助用户，同意协助验证，则验证平台将在步骤S130中接收到验证协助用户提供的验证信息。该验证信息通常至少包括验证问题。

在本实施例中步骤S140中会将所述验证信息的至少部分，例如所述验证问题发送给待验证用户。这样的话，就会在待验证用户的用户界面显示所述验证信息。待验证用户可通过会待验证问题，形成所述验证反馈。

在步骤S150中验证平台将从待验证用户处接收到上报的验证反馈，最终在步骤S160中基于验证反馈确定是否通过验证。

显然在本实施例中所述的验证方法，验证信息的形成是基于待验证用户社交关系中的社交用户，这些社交用户是与待验证用户可能具有好友关系、同事关系、同学关系或师生关系等用户。验证协助用户可以提出仅他们自己知道的验证问题，当验证反馈中提供的答案正确时，可认为通过验证等。

显然在上述过程中验证信息和验证答案时动态形成的，非法用户难以利用网络暴力等技术来多次尝试的方式来窃取，显然大大的提升了安全性，且合法用户不会需要牢记验证密钥，提高了用户使用满意度。

在具体实现过程中，所述验证平台还会形成验证记录，该验证记录可包括 以下信息的一项或多项：

待验证用户信息，包括待验证用户的标识等信息；

验证协助用户信息，包括待验证用户的标识等信息；

验证信息；

验证反馈；

验证时间；

参与验证的三方的权利、义务及承诺等信息；这里参与验证的三方，包括待验证用户、验证协助用户及验证平台；

验证用途；验证用途表明验证通过后，所述待验证用户可获得授权等信息。

通过上述验证记录的信息成，方便后续参与验证三方查看，解决验证过程中或因验证导致的分歧和争议。

方法实施例二：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

所述验证信息包括验证问题和验证答案；其中，所述验证问题为待发送给待验证用户的验证信息；

所述步骤S150包括：

将所述验证反馈与所述验证答案进行核对，形成核对结果；

若核对结果满足验证通过条件，则确定通过验证。

在本实施例中所述验证协助用户可通过验证信息一次性将验证问题和验证 反馈都提交给验证平台，这样验证平台接收到所述验证反馈之后，就能自行进行核对和验证，并最终根据验证协助用户提供的验证答案和待验证用户提供的验证反馈，确定是否通过验证。

例如，协助用户提供了10个验证问题和这10个验证问题的答案，若通过上述核对，确定待验证用户的验证反馈答对了其中的9个验证问题。按照验证通过条件，若需要所有验证问题都通过，则此时待验证用户未通过验证，若仅要求10个验证问题中的8个验证问题答对，则此时待验证用户通过验证。

所述验证通过条件，可为所述验证平台设定的，也可以是由所述待验证用户确定的。该验证通过条件可作为所述验证信息的部分被提交到验证平台，也可以是由所述待验证用户通过专用消息提交到所述验证平台的。

例如，所述待验证用户在设置所述验证通过条件时，还可以指定多个验证问题中的某些验证问题必须正确，才能确定通过验证。

在本实施例中，所述验证信息不仅包括验证问题和验证答案，这样验证协助用户仅需向验证平台发送一次信息，就能完成协助验证，简化了验证协助用户的操作，提高了验证协助用户的用户体验。

方法实施例三：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

所述验证信息包括验证问题；

如图2所示，所述步骤S160可包括：

步骤S161：将所述验证反馈发送给所述验证协助用户；

步骤S162：接收所述协助验证用于基于所述验证反馈给出的验证评价；

步骤S163：基于所述验证评价确定是否通过验证。

在本实施例中所述步骤S160可分为至少三个子步骤。验证平台会将所述验证反馈发送给所述验证协助用户，验证协助用户接收到所述验证反馈之后，给出验证评价，这样的话，验证协助用户就不用事先形成验证答案，所述验证平台也不用从验证协助用户接收所述验证答案，在步骤S163中验证平台将直接根据所述验证评价来确定是否通过验证。

这里的验证评价可直接由所述验证协助用户给出的是否通过验证的评价信息，也可以包括验证协助用户给出的验证反馈的准确率等可由验证平台来确定是否验证通过的评价参数。

例如，验证协助用户小A给出的验证信息为：请用语音答复我的姓名和生日信息。这个验证平台将该验证信息发送给待验证用户小B，并从待验证用户接收到语音形式的验证反馈，在将该语音形式的验证反馈转发给验证协助用户。小A收听到该语音之后，可根据语音内容给出评价，也可以通过语音信息判断自己社交好友小B。在所述验证评中，小A可以直接给出该用户确定为小B，也可以为：验证问题答复正确。总之所述验证评价的形式很多样，可以用于协助验证平台进行验证的信息都可以，在此就不一一举例了。

这种验证方法，同样能够安全、快速且简便的进行验证。

方法实施例四：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

所述验证信息包括验证问题；其中，所述验证问题包括从预先设置的验证题库中选择的验证问题。

在本实施例中所述验证问题可为事先设置在所述验证题库中的，这样当所述验证协助用户能够更加简便的形成所述验证信息，且这样能够加速对待验证用户的验证速度，减少验证时延。

方法实施例五：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

所述方法还包括：

向所述验证协助用户发送形成所述验证信息的备选验证问题。

在本实施例中为了帮助所述验证协助用户，快速的形成所述验证信息，在本实施例中所述验证平台还会向所述验证协助用户发送所述备选验证问题。在发送所述备选验证问题时，可包括首先在所述验证协助请求中携带获取所述被选验证问题的入口信息，该入口信息可包括网页链接等信息；当验证协助用户对该入口信息执行了对应操作之后，所述验证平台向所述验证协助用户发送所述备选验证问题。当然所述验证平台也可以直接向所述验证协助用户发送所述备选验证问题。

当然，在步骤S130中接收的验证信息中的所述验证问题可均来自所述备选 验证问题，也可以是由验证协助用户通过手动或语音输入形成的验证问题，也可以是来自所述验证协助用户的本地客户端中预先存储的验证问题。

总之本实施例中所述验证平台会通过向所述验证协助用户发送所述备选验证问题，简化验证协助用户的操作，从而提升验证协助用户的用户体验。

方法实施例六：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

如图3所示，所述步骤S110可包括：

步骤S111：基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

步骤S112：基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

在本实施例中所述步骤S110中将按照选择策略来选择从待验证用户的社交关系中选择出一个或多个验证协助用户来协助验证。

这里所述的社交属性可包括待验证用户与其社交关系中的各个社交用户的社交频次、社交关系建立时间、每一次交互的交互信息量等信息。

所述用户属性，可包括所述待验证用户的社交关系中各个社交用户的个人属性及行为属性。例如，所述个人属性包括用户身份信息、用户职业信息、用户社交关系网络及爱好性等。所述行为属性可包括用户消费记录信息、用户信用记录、用户协助验证记录及其他用户或其他平台对该用户的评价记录等信息。

所述社交属性能够反映出待验证用户与该社交用户之间的社交紧密度，为该待验证用户进行身份验证或鉴权验证等验证是否具有足够的社交关系来支撑。

所述用户属性能够表征该用户是否是一个可信的人，由其提供验证从该用户属性来衡量是否足够可信。

故在本实施例中所述验证方法，至少从上述至少一个维度来提取选择验证协助用户的信息，并最终基于提取的信息确定出所述验证协助用户。

在步骤S112中，所述选择要求可为所述验证平台根据当前验证需求具体设定。

例如，在步骤S111中提取所述待验证用户与对应的社交用户在指定时间内的社交频次，在步骤S112中：将所述社交频次与预设频次进行比较，当所述社交频次大于所述预设频次时，该社交用户才可称为该待验证用户的验证协助用户。

再比如，在进行验证时，为了防止协助验证泛滥，所述验证平台可规定一个社交用户仅能够为有限个数的其他社交用户提供验证协助。这个时候，在所述步骤S111中，可提取所述待验证用户的社交关系中各个社交用户的协助验证记录，确定各所述社交用户的已验证协助用户数；在步骤S112中：选择已验证协助用户数还未达到协助验证上限的社交用户作为当前所述待验证用户的验证协助用户。

再比如，在进行验证时，为了保证验证的可靠性，对信用记录差的社交用户，将禁止或限制其成为所述验证协助用户，则在所述步骤S110中，将提取所述待验证用户的社交关系中社交用户的信用记录，在步骤S112中：将选择信用记录良好或优秀的社交用户作为所述验证协助用户。

总之，本实施例提供的所述验证方法，在前述实施例的基础上，进一步限定给如何选择验证协助用户，具有实现简便及可行度高的特点。

方法实施例七：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

如图3所示，所述步骤S110可包括：

步骤S111：基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

步骤S112：基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

所述步骤S112可包括：

基于所述社交属性和/或用户属性，选择满足所述选择要求的社交用户作为备选用户；

向所述待验证用户发送所述备选用户；

接收所述待验证用户基于所述备选用户形成的选择指示；

基于所述选择指示确定所述验证协助用户。

在进行验证时，所述待验证用户与所述验证协助用户之间可通过及时通信或手机通信等方式交互验证答案等信息。这个时候，为了方便验证过程的进行及提高待验证用户的使用满意度，在本实施例中所述步骤S112中，首先基于所述社交属性和用户属性的至少其中之一，确定出作为所述验证协助用户的备选用户；在将被选用户发送给所述待验证用户，供待验证用户选择。当然这些备案用户都是符合所述选择要求的用户，是确保了验证的可信度。最后在步骤S112中将根据待验证用户的选择指示，确定出1个或多个验证协助用户。

本实施例所述验证方法，是在前一实施例基础上的进一步改进，在本实施 例中所述待验证用户也会参与所述验证协助用户的选择，提高了待验证用户的参与度和验证满意度。

方法实施例八：

如图1所示，本实施例提供一种验证方法，所述方法包括：

步骤S110：基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

步骤S120：向所述验证协助用户发送验证协助请求；

步骤S130：接收所述验证协助用户基于所述验证协助请求返回的验证信息；

步骤S140：将至少部分所述验证信息发送给待验证用户；

步骤S150：接收所述验证用户基于所述验证信息形成的验证反馈；

步骤S160：基于所述验证反馈确定是否通过验证。

如图3所示，所述步骤S110可包括：

步骤S111：基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

步骤S112：基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

如图4所示，所述步骤S112包括：

步骤S1121：按照所述选择策略为所述社交属性和/或用户属性赋予评分值；

步骤S1122：确定所述社交属性和/或用户属性的评分权值；

步骤S1123：基于所述评分值与所述评分权值确定表征验证可信度的函数值；

步骤S1124：基于所述函数值确定所述验证协助用户。

在本实施例中首先会根据选择策略为所述社交属性和/用户属性赋予评分中。

具体如，待验证用户与社交用户A建立社交关系的时间长达为2年，待验证用户与社交用户B建立社交关系的时间仅为3个月，则此时，可对社交用户 A的社交关系时长赋予a分；对社交用户B的社交关系时长赋予b分。所述a和b均为正数，但是所述a大于所述b。通常社交关系时长越大可得到越大的评分值。在比如，社交用户A的信用记录比所述社交用户B的信用记录差，则所述社交用户A的信用记录对应的评分值可大于所述社交用户B的信用记录对应的评分值。

不同的社交属性和用户属性对验证协助用户的可信度的贡献值是不一样的，在本实施例中还引入的评分权值，如一个属性对可信度的贡献值则对应的评分权值就越大。在步骤S1122中，将确定参与计算所述可信度的社交属性和用户属性的评分权值。在步骤S1123将根据预设函数关系，基于所述评分值和所述评分权值计算得到函数值。该函数值即可用于能够反映社交用户的提供验证可信度。

在步骤S1124中，将根据所述函数值选择出验证协助用户，可包括选择函数值大于指定值的社交用户作为所述验证协助用户，或选择函数值从高到低排序选择排序靠前N位的社交用户作为所述验证协助用户。其中，所述N为不小于1的整数。

本实施例提供了一种选择验证协助用户的方法，通过评分值的赋予，可以将不同维度的社交属性或用户属性，转换成具有统一度量衡的评分值；在通过评分权值的引入，充分考虑了各个属性对验证可信度的不同贡献值，在通过计函数值，可以很简便的确定出满足所述选择要求的验证协助用户；具有实现简单及验证可信度高等特点。

方法实施例九：

如图5所示，本实施例提供一种验证方法，所述方法包括：

步骤S210：从验证平台接收验证协助用户形成的至少部分验证信息；

步骤S220：输出从所述验证平台接收的所述验证信息；

步骤S230：基于所述验证信息及用户指示，形成验证反馈；

步骤S240：将所述反馈发送给所述验证平台；其中，所述验证反馈用于供所述验证平台确定是否通过验证。

本实施例所述的验证方法可为应用于待验证用户所在客户端中的处理方法。在本实施例中所述验证信息为所述验证用户形成的。所述验证信息至少包括验证问题。所述验证问题的来源可参见前述方法实施例，在此就不再重复了。

显然所述验证信息并非与待验证用户事先设定的静态信息，而可能是所述验证协助用户动态形成的。这里的所述验证协助用户与待验证用户之间具有社交关系，这种社交可体现在是QQ好友、微信好友、人人网的同学关系等。

在步骤S220中将输出所述验证信息；输出验证信息的方法可包括显示输出和语音输出。

在步骤S230中客户端将接收用户指示，形成所述验证反馈。

在步骤S240中待验证用户将会所述验证反馈提交到验证平台，方便验证平台是否通过验证。

本实施例提供了一种验证方法可用于进行身份验证和鉴权验证等，具有验证安全性高及用户不用记录验证密钥等特点。

作为本实施例的进一步改进，所述方法还包括：从社交关系中选择社交用户作为验证协助用户；及将所述验证协助用户的信息发送给验证平台。

在本实施例中所述待验证用户参与选择所述验证协助用户，在具体的实现过程中，所述待验证用户可以基于用于指示从其社交关系中直接选择出一个或多个社交用户，并将这些社交用户的标识等信息提交到验证平台。当然，也可以是所述待验证用户从所述验证平台接收所述待验证平台通过选择之后形成的备选用户，所述待验证用户基于用户指示从备选用户中选择所述验证协助用户。

通过待验证用户参与选择验证协助用户，提高了待验证用户的参与度及满意度。

方法实施例十：

如图6所示，本实施例提供一种验证方法，所述方法包括：

步骤S310：接收验证平台发送协助待验证用户进行验证的验证协助请求；

步骤S320：基于用户指示形成响应所述验证协助请求的验证信息；其中，所述验证信息供所述验证平台对待验证用户进行验证；

步骤S330：将所述验证信息发送给所述验证平台。

本实施例所述的验证方法为应用于所述验证协助用户所在的客户端中方法，在本实施例中由验证协助用户响应所述验证协助请求，形成所述验证信息。显然这样所述验证信息是动态形成的，提高了验证的安全性。

本实施例中所述验证协助用户与所述待验证用户之间为建立有社交关系。

在步骤S320中形成的所述验证信息可包括验证问题和验证答案。这样的话，所述验证协助用户一次性将所述验证问题和所述验证答案同时发送给了验证平台，可供验证平台自行进行验证反馈与验证答案之间的核对。

当然，所述验证信息还仅包括验证问题。这样的话，所述方法还包括：

接收所述验证平台转发的验证反馈；

输出验证反馈；

基于用户指示确定出对所述验证反馈的验证评价；

将所述验证评价发送给所述验证平台。

此时，当所述待验证用户形成用户反馈之后，所述验证平台会将所述验证反馈转发给所述验证协助用户，验证协助用户通过语音输出或显示输出的方式，输出所述验证反馈。客户端将接收用户指示，形成对所述验证反馈的验证评价；并将验证评价提交到验证平台，再由验证平台最终决定是否通过验证。本实施例中所述验证评价可参见前述实施例，在此就不再重复了。

设备实施例一：

如图7所示，本实施例提供一种验证平台，所述验证平台包括：

选择单元110，用于基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

第一发送单元120，用于向所述验证协助用户发送验证协助请求；

第一接收单元130，用于接收所述验证协助用户基于所述验证协助请求返回的验证信息；

第二发送单元140，用于将至少部分所述验证信息发送给待验证用户；

第二接收单元150，用于接收所述验证用户基于所述验证信息形成的验证 反馈；

验证单元160，用于基于所述验证反馈确定是否通过验证。

本实施例所述的验证平台可包括一台或多台计算机构成。

所述选择单元110和所述验证单元160的具体结构可包括处理器或处理电路。所处理器可包括中央处理器、微处理器、数字信号处理器或可编程阵列等具有信息处理的处理解雇。所述处理电路可包括专用集成电路等。

所述选择单元110和所述验证单元160可集成对应于相同的处理器或分别对应不同的处理器。所述验证平台还包括存储介质等，所述处理器或处理电路通过总线等结构与所述存储介质相连。所述存储介质可存储有可执行指令，所述处理器或处理电路可通过执行上述可执行指令，能够实现各种的功能。

所述第一发送单元120、第一接收单元130、第二发送单元140和第二接收单元150的具体结构可分别对应不同的通信接口，也可以对应相同的通信接口。所述通信接口可为有线接口或无线接口。所述有线接口可为电缆接口或光缆接口；所述无线接口可为各种类型的收发天线。

本实施例所述的验证平台可通过邀请其他社交用户为待验证用户进行验证，这样形成的验证信息具有安全性高的特点，且待验证用户不用记录验证密钥，也不用担心验证密钥忘记导致的烦恼。

所述验证单元160的具体结构有多种，以下提供两种可选结构。

可选结构一：

所述验证信息包括验证问题和验证答案；其中，所述验证问题为待发送给待验证用户的验证信息；

所述验证单元160，具体用于将所述验证反馈与所述验证答案进行核对，形成核对结果；若核对结果满足验证通过条件，则确定通过验证。

所述验证单元160在所述第二接收单元150接收所述验证反馈之后，将所述验证反馈与所述验证答案进行核对，形成了核对结果；直接根据核对结果确定出是否通过验证。

可选结构二：

所述验证信息包括验证问题；

所述验证平台160，具体用于将所述验证反馈发送给所述验证协助用户；接收所述协助验证用于基于所述验证反馈给出的验证评价；基于所述验证评价确定是否通过验证。

在本实施例中所述验证平台160也可通信接口，该通信接口能够与所述验证协助用户进行信息交互，例如将所述验证反馈发送给所述验证协助用户，接收所述验证评价，根据所述验证评价确定所述验证通过。

上述两种验证单元的结构都结构简单及实现简便智能的特点，总之本实施例所述的验证平台具有验证安全性高的特点。在具体的实现过程中，所述验证平台可为具有验证功能的社交平台，这样的话，所述社交平台中的社交数据库，可为选择所述验证协助用户提供数据支撑。所述验证平台可为微信平台等。

其中，所述验证信息至少包括验证问题，其中，所述验证问题包括从预先设置的验证题库中选择的验证问题。这个预先设置的验证题库可为事先设置在所述验证协助用户的本地客户端中的，这样能够提高验证速率。

当然，所述验证平台的第一发送单元120还可用于向所述验证协助用户发送形成所述验证信息的备选验证问题。这样能够帮助所述验证协助用户快速简便形成所述验证信息。

设备实施例二：

如图7所示，本实施例提供一种验证平台，所述验证平台包括：

选择单元110，用于基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

第一发送单元120，用于向所述验证协助用户发送验证协助请求；

第一接收单元130，用于接收所述验证协助用户基于所述验证协助请求返回的验证信息；

第二发送单元140，用于将至少部分所述验证信息发送给待验证用户；

第二接收单元150，用于接收所述验证用户基于所述验证信息形成的验证反馈；

验证单元160，用于基于所述验证反馈确定是否通过验证。

所述选择单元110包括：

提取模块，用于基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

选择模块，用于基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

在本实施例中所述选择单元110可分为提取模块和选择模块。所述选择模块用于提取所述社交属性和用户属性中的至少其中之一。所述选择模块将根据所述社交属性和/或用户属性的来确定验证协助用户，可见在本实施例所述的验证平台中并非随意的选择验证协助用户，而是需要选择选择要求的验证协助用户，这样能够提高验证的可靠性。

所述社交属性和所述用户属性的详细描述可参见对应的方法实施例，在此就不再重复了。

所述提取模块和所述验证模块也可对应于处理器或处理电路；所述处理器或处理电路的具体结构可参见设备实施例一。所述提取模块和所述验证模块可对应相同的处理器或处理电路，也可以对应不同的处理器或处理电路。当集成对应于同一处理器或处理电路时，处理器或处理电路采用时分复用或并发线程来分别实现不同模块的功能。

设备实施例三：

如图7所示，本实施例提供一种验证平台，所述验证平台包括：

选择单元110，用于基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

第一发送单元120，用于向所述验证协助用户发送验证协助请求；

第一接收单元130，用于接收所述验证协助用户基于所述验证协助请求返回的验证信息；

第二发送单元140，用于将至少部分所述验证信息发送给待验证用户；

第二接收单元150，用于接收所述验证用户基于所述验证信息形成的验证 反馈；

验证单元160，用于基于所述验证反馈确定是否通过验证。

所述选择单元110包括：

提取模块，用于基于选择策略，提取所述待验证用户的社交关系中各社交用户的社交属性和/或用户属性；

选择模块，用于基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

所述选择模块，具体用于基于所述社交属性和/或用户属性，选择满足所述选择要求的社交用户作为备选用户；向所述待验证用户发送所述备选用户；接收所述待验证用户基于所述备选用户形成的选择指示；基于所述选择指示确定所述验证协助用户。

在本实施例中所述选择模块也包括通信接口，能够与待验证用户所在客户端进行信息交互，基于待验证用户的用户指示确定出满足选择要求的验证协助用户，这样提高了所述待验证用户参与验证的决策度，提高了用户验证满意度。

设备实施例四：

如图7所示，本实施例提供一种验证平台，所述验证平台包括：

选择单元110，用于基于验证需求从待验证用户的社交关系中选择至少一位验证协助用户；

第一发送单元120，用于向所述验证协助用户发送验证协助请求；

第一接收单元130，用于接收所述验证协助用户基于所述验证协助请求返回的验证信息；

第二发送单元140，用于将至少部分所述验证信息发送给待验证用户；

第二接收单元150，用于接收所述验证用户基于所述验证信息形成的验证反馈；

验证单元160，用于基于所述验证反馈确定是否通过验证。

所述选择单元110包括：

提取模块，用于基于选择策略，提取所述待验证用户的社交关系中各社交 用户的社交属性和/或用户属性；

选择模块，用于基于所述社交属性和/或用户属性，选择满足所述选择策略中选择要求的社交用户作为验证协助用户。

所述选择模块，具体用于按照所述选择策略为所述社交属性和/或用户属性赋予评分值；确定所述社交属性和/或用户属性的评分权值；基于所述评分值与所述评分权值确定表征验证可信度的函数值；基于所述函数值确定所述验证协助用户。

在本实施例中所述验证平台的所述选择模块，将提取模块提取的属性转换成具有同一度量衡的评分值，并根据各个属性对验证可信度的贡献值设置评分权值，并最终基于评分值和评分权值计算出能够反映出验证可信度的函数值。所述选择模块最终根据所述函数值确定出所述验证协助用户。

显然采用本实施例所述的验证平台确定的验证协助用户，能够有利于保证验证的可靠性。

设备实施例五：

如图8所示，本实施例提供一种客户端，所述客户端包括：

第三接收单元210，用于从验证平台接收验证协助用户形成的至少部分所述验证信息；

输出单元220，用于输出从所述验证平台接收的所述验证信息；

形成单元230，用于基于所述验证信息及用户指示，形成验证反馈；

第三发送单元240，用于将所述反馈发送给所述验证平台；其中，所述验证反馈用于供所述验证平台确定是否通过验证。

本实施例所述的客户端为所述待验证用户所在的客户端，可对应于手机、平板电脑或可穿戴式设备等终端设备。

所述第三接收单元210可对应于通信接口，该通信接口可为有线接口或无线接口，能够接收验证平台转发的所述验证协助用户形成的验证信息。通常所述验证信息至少包括验证问题。

所述输出单元220可包括显示屏；所述显示屏通过信息显示输出所述验证 信息。所述输出单元220还可包括喇叭或扬声器等音频输出结构，通过语音方式输出所述验证信息。

所述形成单元230的具体结构处理器或处理电路，该处理器可为该客户端内的中央处理器、应用处理器、数字信号处理器或可编程阵列等具有信息处理的结构。所述处理电路可包括专门集成电路。所述形成单元230能够用于基于所述用户指示形成所述验证反馈。所述用户指示可为由客户端的人机交互接口接收的，例如，显示交互屏通过接收用户手势操作获取所述用户指示，例如语音交互接口，通过接收用户语音获取所述用户指示。

所述第三发送单元240可包括发送接口，具体可对应发送天线等，能够发送验证反馈。

本实施例所述的客户端，在进行验证时的验证信息是由验证协助用户动态形成的，这样能够提高验证的安全性，且用户不用记住验证密钥可以避免验证密钥丢失或验证密钥导致的困恼。

在本实施例中所述的客户端中，所述客户端还用于从社交关系中选择社交用户作为验证协助用户；所述第三发送单元240还用于将所述验证协助用户的信息发送给验证平台。本实施例所述的客户端还能够参与选择参与验证的验证协助用户，这样能够提高用户验证参与度和验证满意度。

设备实施例六：

如图9所示，本实施例提供一种客户端，所述客户端包括：

第四接收单元310，用于接收验证平台发送协助待验证用户进行验证的验证协助请求；

响应单元320，用于基于用户指示形成响应所述验证协助请求的验证信息；其中，所述验证信息供所述验证平台对待验证用户进行验证；

第四发送单元330，用于将所述验证信息发送给所述验证平台。

本实施例所述的客户端为所述验证协助用户所在的客户端，所述客户端可对应于手机、平板电脑或可穿戴式设备等。

所述第四接收单元310和所述第四发送单元330的具体结构都对应于通信 接口，该通信接口可为有线通信接口或无线接口，总之能够与所述验证平台进行信息交互的接口。

所述响应单元320的具体结构可对应于所述客户端中的处理器或处理电路。所述处理器可为中央处理器、数字信号处理器、可编程阵列或应用处理器等，能够基于正对于所述验证信息的用户指示，形成所述验证信息，以协助待验证用户进行验证。本实施例所述的客户端用于验证，具有验证安全性高及验证简便的特点。

所述验证信息包括验证问题和验证答案。这样的话，所述客户端的所述第四发送单元330一次性就把验证问题和验证答案发送给了验证平台，这样可以减少与验证平台之间的信息交互次数，降低客户端的功耗及简化用户操作。

当然，所述第四接收单元310还可用于接收所述验证平台转发的验证反馈；所述客户端还可包括显示屏或语音输出结构等，用于输出验证反馈；所述响应单元还将用于基于用户指示确定出对所述验证反馈的验证评价；所述第四发送单元330还可用于将所述验证评价发送给所述验证平台。本实施例所述的客户端还可通过形成所述验证评价协助所述验证平台的验证，具有结构简单及智能性高的特点。

以下结合上述任意实施例提供几个具体示例：

示例一：

如图10所示，本示例包括：

步骤S1：用户A发起身份验证求；本示例所述用户A发起的身份验证请求为前述实施例中的验证需求的一种。

步骤S2：系统根据特定规定和算法挑选一批可信人群；这里的可信人群可对应于前述实施例中所述的备选用户。这里的系统可包括前述的验证平台。这里的特定规定和所述算法为前述选择策略的组成部分。

步骤S3：用户A在可信人群选择1位好友B。这里的好友B就将作为所述验证协助用户。

步骤S4：系统向好友B下发验证协助请求。

步骤S5：好友B收到验证协助请求拟定一组问题和答案。这里的问题即为前述验证问题，这里答案即为前述的验证答案。

步骤S6：系统向用户A下发好友B拟定的问题。

步骤S7：用户A回答问题。

步骤S8：系统判断用户A的回答是否与好友B拟定的答案相符，若是进入步骤S9，若否验证不通过。

步骤S9：确定验证通过。

在本示例中当验证不通过时，所述用户A可以自行联系好友B，获得答案，并返回步骤S7，重新进行问题回答。

示例二：

本示例提供一种验证平台，该验证平台包括验证服务器、数据库及网关。所述数据库内可存储有各个用户的社交关系及验证记录等信息数据。

所述验证服务器分别与所述数据库和网关连接。所述网关可为所述验证平台与所述待验证用户及验证协助用户进行通信的接口。所述网关可用于过滤非法用户和非法操作，用于防卫所述验证平台的使用安全和信息安全。

所述验证服务器，可用于从所述数据库读取社交关系，选择验证协助用户，并基于验证反馈确定是否通过验证，并最终更新所述数据库中的验证记录。

在本示例中所述的验证平台，可为用于实现方法实施例一至方法实施例九的硬件结构，具有验证安全高的特点。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作 为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。