一种业务处理方法、装置和智能终端与流程

本申请涉及网络通信技术领域，特别是涉及一种业务处理方法、一种业务处理装置和一种智能终端。

背景技术：

随着通信技术的发展，人们越来越多地改变现金支付的习惯，采用通过互联网和手机等电子形式的工具进行支付。例如，用户在网络购物平台购买物品的过程中，可以通过电子形式的工具对该物品的款项进行支付。又如，一个用户可以通过电子形式的工具向其他用户支付款项等等。

现有的支付方案中，用户主要通过输入用户凭据来完成支付。上述用户凭据具体可以包括：登录密码、支付密码，证书，usbkey等能够表明用户身份的信息或者装置。

然而，上述用户凭据具有容易泄露的特性，而在用户凭证泄露的情况下，将容易造成用户财产的损失，也即，现有的支付方案具有较严重的安全隐患。例如，在用户的登录密码和支付密码被盗后，将容易出现资金被非法转移或使用的情形。

技术实现要素：

本申请实施例所要解决的技术问题是提供一种业务处理方法，可以有效阻止非正常业务的执行，从而能够提高业务处理的安全性。

相应的，本申请实施例还提供了一种业务处理装置和一种智能终端，用以保证上述方法的实现及应用。

为了解决上述问题，本申请公开了一种业务处理方法，包括：

一种业务处理方法，包括：

接收第一用户的业务请求；

向第二用户的第二客户端发送所述业务请求对应的验证请求；其中， 所述第二用户与所述第一用户具有预设用户关系；

接收所述第二客户端对所述验证请求的验证结果；

在所述验证结果符合预置规则时，终止对所述业务请求的处理。

可选地，通过如下步骤确定所述第二用户：

依据所述第一用户对应的验证规则，确定所述第二用户；或者

依据所述业务请求携带的第一用户信息和业务信息，在第一用户信息、验证规则和第二用户信息之间的映射关系中进行查找，以得到所述第二用户的信息；或者

依据所述业务请求携带的第一用户信息，在第一用户信息与第二用户信息之间的映射关系进行查找，以得到所述第二用户的信息。

可选地，所述依据所述第一用户对应的验证规则，确定所述第二用户的步骤，包括：

在所述业务请求中携带的业务信息和/或预置时间段内的业务请求中携带的业务信息符合所述验证规则时，依据预先建立的验证规则与第二用户信息之间的映射关系，得到所述验证规则对应的第二用户信息，作为所述第二用户的信息。

可选地，所述方法还包括：

向所述第一用户的第一客户端发送终止消息；所述终止消息用于指示所述业务请求的终止。

可选地，所述方法还包括：

接收设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

依据所述第二用户信息，向对应第二用户的第二客户端发送所述设置请求；

接收所述第二客户端返回的、针对所述设置请求的第一确认消息；

在接收所述第一确认消息后，建立验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

可选地，所述方法还包括：

确定所述第一用户信息所对应用户账户的当前状态，在所述当前状态为预置状态时，拒绝所述设置请求；或者

依据所述第二客户端返回的、针对所述设置请求的第一拒绝消息，拒绝所述设置请求；或者

确定验证范围超出所述验证规则对应验证范围的验证规则所对应的第三用户，向所述第三用户的第三客户端发送所述设置请求，接收所述第三客户端返回的、针对所述设置请求的第三拒绝消息，并依据所述第三拒绝消息，拒绝所述设置请求。

可选地，所述方法还包括：

接收取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

依据所述第二用户信息，向对应第二用户的第二客户端发送所述取消请求或变更请求；

接收所述第二客户端返回的、针对所述取消请求或变更请求的第二确认消息；

在接收所述第二确认消息后，删除对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

可选地，所述方法还包括：

接收所述第二客户端返回的、针对所述取消请求或变更请求的第二拒绝消息；

在接收所述第二拒绝消息后，维持对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

可选地，所述验证结果包括：阻止或者允许，则所述预置规则，包括：

至少一个验证结果中包括阻止；或者

阻止的次数大于第一阈值；或者

阻止的次数相对于拒绝的次数的比例大于第二阈值。

可选地，所述验证规则包括：一种或多种业务信息对应的规则；

所述业务信息包括如下信息中的至少一种：业务对应参数、业务对象、业务来源、业务发生时间、业务发生地点和预置时间段内的业务发生次数；

所述验证规则包括如下规则中的至少一种：

业务对应参数在预置额度范围内；

业务对象在预置对象范围内；

业务来源在预置来源范围内；

业务发生时间在预置时间范围内；

业务发生地点在预置地点范围内；以及

预置时间段内的业务发生次数在预置次数范围内。

另一方面，本申请公开了一种业务处理方法，包括：

接收服务器发送的、第一用户的业务请求所对应的验证请求；

通过第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系；

向所述服务器发送所述验证结果。

可选地，所述方法还包括：

接收服务器发送的设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

通过第二用户获取针对所述设置请求的第一确认消息；

向所述服务器发送所述第一确认消息。

可选地，所述方法还包括：

通过第二用户获取得到针对所述设置请求的第一拒绝消息；

向所述服务器发送所述第一拒绝消息。

可选地，所述方法还包括：

接收服务器发送的取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

通过第二用户获取针对所述取消请求或变更请求的第二确认消息；

向所述服务器发送所述第二确认消息。

可选地，所述方法还包括：

通过第二用户获取针对所述取消请求或变更请求的第二取消消息；

向所述服务器发送所述第二取消消息。

再一方面，本申请公开了一种业务处理方法，包括：

向服务器发送第一用户的业务请求，以使所述服务器向第二用户的第二客户端发送所述业务请求对应的验证请求，并使第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系。

可选地，所述方法还包括：

接收所述服务器针对所述业务请求返回的终止消息；所述终止消息用于指示所述业务请求的终止。

可选地，所述方法还包括：

向服务器发送设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则。

可选地，所述方法还包括：

向服务器发送取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则。

又一方面，本申请公开了一种业务处理装置，包括：

第一接收模块，用于接收第一用户的业务请求；

第一发送模块，用于向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户具有预设用户关系；

第二接收模块，用于接收所述第二客户端对所述验证请求的验证结果；以及

终止模块，用于在所述验证结果符合预置规则时，终止对所述业务请求的处理。

可选地，所述装置还包括：确定模块，用于确定所述第二用户；

所述确定模块，包括：

第一确定子模块，依据所述第一用户对应的验证规则，确定所述第二用户；或者

第二确定子模块，依据所述业务请求携带的第一用户信息和业务信 息，在第一用户信息、验证规则和第二用户信息之间的映射关系中进行查找，以得到所述第二用户的信息；或者

第三确定子模块，依据所述业务请求携带的第一用户信息，在第一用户信息与第二用户信息之间的映射关系进行查找，以得到所述第二用户的信息。

可选地，所述第一确定子模块，包括：

查找单元，用于在所述业务请求中携带的业务信息和/或预置时间段内的业务请求中携带的业务信息符合所述验证规则时，依据预先建立的验证规则与第二用户信息之间的映射关系，得到所述验证规则对应的第二用户信息，作为所述第二用户的信息。

可选地，所述装置还包括：

第二发送模块，用于向所述第一用户的第一客户端发送终止消息；所述终止消息用于指示所述业务请求的终止。

可选地，所述装置还包括：

第三接收模块，用于接收设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

第三发送模块，用于依据所述第二用户信息，向对应第二用户的第二客户端发送所述设置请求；

第四接收模块，用于接收所述第二客户端返回的、针对所述设置请求的第一确认消息；

建立模块，用于在接收所述第一确认消息后，建立验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

可选地，所述装置还包括：

第一拒绝模块，用于确定所述第一用户信息所对应用户账户的当前状态，在所述当前状态为预置状态时，拒绝所述设置请求；或者

第二拒绝模块，用于依据所述第二客户端返回的、针对所述设置请求的第一拒绝消息，拒绝所述设置请求；或者

第二拒绝模块，用于确定验证范围超出所述验证规则对应验证范围的 验证规则所对应的第三用户，向所述第三用户的第三客户端发送所述设置请求，接收所述第三客户端返回的、针对所述设置请求的第三拒绝消息，并依据所述第三拒绝消息，拒绝所述设置请求。

可选地，所述装置还包括：

第五接收模块，用于接收取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

第四发送模块，用于依据所述第二用户信息，向对应第二用户的第二客户端发送所述取消请求或变更请求；

第六接收模块，用于接收所述第二客户端返回的、针对所述取消请求或变更请求的第二确认消息；

删除模块，用于在接收所述第二确认消息后，删除对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

可选地，所述装置还包括：

第七接收模块，用于接收所述第二客户端返回的、针对所述取消请求或变更请求的第二拒绝消息；

维持模块，用于在接收所述第二拒绝消息后，维持对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

另一方面，本申请公开了一种业务处理装置，包括：

第一接收模块，用于接收服务器发送的、第一用户的业务请求所对应的验证请求；

验证模块，用于通过第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系；以及

第一发送模块，用于向所述服务器发送所述验证结果。

可选地，所述装置还包括：

第二接收模块，用于接收服务器发送的设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

第一获取模块，用于通过第二用户获取针对所述设置请求的第一确认消 息；

第二发送模块，用于向所述服务器发送所述第一确认消息。

可选地，所述装置还包括：

第二获取模块，用于通过第二用户获取得到针对所述设置请求的第一拒绝消息；

第三发送模块，用于向所述服务器发送所述第一拒绝消息。

可选地，所述装置还包括：

第三接收模块，用于接收服务器发送的取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

第三获取模块，用于通过第二用户获取针对所述取消请求或变更请求的第二确认消息；

第四发送模块，用于向所述服务器发送所述第二确认消息。

可选地，所述装置还包括：

第四获取模块，用于通过第二用户获取针对所述取消请求或变更请求的第二取消消息；

第五发送模块，用于向所述服务器发送所述第二取消消息。

再一方面，本申请公开了一种业务处理装置，包括：

第一发送模块，用于向服务器发送第一用户的业务请求，以使所述服务器向第二用户的第二客户端发送所述业务请求对应的验证请求，并使第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系。

可选地，所述装置还包括：

接收模块，用于接收所述服务器针对所述业务请求返回的终止消息；所述终止消息用于指示所述业务请求的终止。

可选地，所述装置还包括：

第二发送模块，用于向服务器发送设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则。

可选地，所述装置还包括：

第三发送模块，用于向服务器发送取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则。

又一方面，本申请公开了一种智能终端，包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上程序包含用于进行以下操作的指令：

接收第一用户的业务请求；

向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户具有预设用户关系；

接收所述第二客户端对所述验证请求的验证结果；

在所述验证结果符合预置规则时，终止对所述业务请求的处理。

与现有技术相比，本申请实施例包括以下优点：

本申请实施例在业务请求的处理流程中，通过第一用户之外的第二用户来执行验证操作；由于该第二用户通常为与第一用户具有预设用户关系的用户，故其具备对业务请求的风险进行有效控制的能力，因此本申请实施例可以有效阻止非正常业务的执行，从而能够提高业务处理的安全性。

例如，第二用户可以为第一用户的好友，其能够及时得知第一用户的用户账户被盗的情况，故其在确定第一用户的用户账户被盗后，可以阻止第一用户的用户账户对应的非法业务。

又如，第二用户可以为第一用户的监护人，其具备阻止所监护用户的用户账户对应的非正常业务的能力，故其可以对其子女的账户对应的业务进行控制，以防止其子女在被蒙骗等情况下发生不良支付。

再如，第二用户可以为与第一用户具有预设用户关系的任意用户，当第一用户在误操作的情况下触发了业务请求时，该第二用户可以及时得知上述误操作的情况，因此，可以阻止第一用户的用户账户对应的误操作业务。

附图说明

图1是本申请的一种业务处理方法实施例一的步骤流程图；

图2是本申请的一种设置第二用户的方法的步骤流程图；

图3是本申请的一种建立验证规则与第二用户信息之间的映射关系的方法的步骤流程图；

图4是本申请的一种业务处理方法实施例二的步骤流程图；

图5是本申请的一种业务处理方法实施例三的步骤流程图；

图6是本申请的一种支付业务处理系统的结构示意图；

图7是本申请的一种业务处理装置实施例一的结构框图；

图8是本申请的一种业务处理装置实施例二的结构框图；以及

图9是本申请的一种智能终端实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

现有的支付方案中，通常用户在智能终端中输入凭据后，即不再对支付业务具有控制能力。而实际上由于智能终端缺少对使用者的有效判定能力，导致各种支付安全问题。例如用户在账号被盗后，大笔资金被非法转移或使用。

本专利发明人经研究发现，用户通常具有广泛的人际关系(以下统称用户关系)，例如用户之间有各种有效的信息沟通和身份确认方式，而非法用户(如网络攻击者、终端盗窃者)通常不能了解用户关系，故也较难冒充与合法用户具有用户关系的用户进行欺骗。

因此，本申请实施例的核心构思之一在于，在业务请求的处理流程中引入验证环节，该验证环节通过第一用户之外的第二用户来执行验证操作；由于该第二用户通常为与第一用户具有预设用户关系的用户，故其可以对业务请求的风险进行有效控制，因此本申请实施例可以有效阻止非正常业务的执行，从而能够提高业务处理的安全性。例如，第二用户可以为 第一用户的好友，其能够及时得知第一用户的用户账户被盗的情况，故其在确定第一用户的用户账户被盗后，可以阻止第一用户的用户账户对应的非法业务。又如，第二用户可以为第一用户的监护人，其具备阻止所监护用户的用户账户对应的非正常业务的能力，故其可以对其子女的账户对应的业务进行控制，以防止其子女在被蒙骗等情况下发生不良支付。再如，第二用户可以为与第一用户具有预设用户关系的任意用户，当第一用户在误操作的情况下触发了业务请求时，该第二用户可以及时得知上述误操作的情况，因此，可以阻止第一用户的用户账户对应的误操作业务。

方法实施例一

参照图1，示出了本申请的一种业务处理方法实施例一的步骤流程图，具体可以包括如下步骤：

步骤101、接收第一用户的业务请求；

步骤102、向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户可以具有预设用户关系；

步骤103、接收所述第二客户端对所述验证请求的验证结果；

步骤104、在所述验证结果符合预置规则时，终止对所述业务请求的处理。

本申请实施例提供的业务处理方法可以应用于客户端和服务器对应的应用环境中。其中，客户端与服务器可以位于有线或无线网络中，通过该有线或无线网络，客户端与服务器进行数据交互。

其中，上述客户端可以运行于智能终端上且，可以应用于上述智能终端的webapp(应用程序，application)、hybrid(混合)app、native(原生)app等环境中。上述智能终端具体包括但不限：智能手机、平板电脑、电子书阅读器、mp3(动态影像专家压缩标准音频层面3，movingpictureexpertsgroupaudiolayeriii)播放器、mp4(动态影像专家压缩标准音频层面4，movingpictureexpertsgroupaudiolayeriv)播放器、膝上型便携计算机、车载电脑、台式计算机、机顶盒、智能电视机、可穿戴设备 等等。

具体地，客户端可以接收用户输入的业务请求，其中，上述业务请求中可以携带有业务信息和用户信息等信息。为了方便区分，本申请实施例中第一客户端、第二客户端和第三客户端分别用于表示第一用户、第二用户和第三用户对应的客户端，实际上，本申请实施例对于具体的客户端不加以限制。

在本申请的一种可选实施例中，客户端可以通过执行上述步骤101和步骤102对上述业务请求进行处理。

在本申请的另一种可选实施例中，客户端可以向服务器发送上述业务请求，以使服务器通过执行上述步骤101和步骤102对上述业务请求进行处理。由于处理业务请求所需的运算工作在服务器中执行，故能够降低客户端的运算量，也即能够大大降低客户端的资源消耗，从而能够提高客户端的运行时间和运行效率，且能够提高客户端的实用性；并且，还能够发挥服务器侧计算资源(云服务器中云资源)丰富的优势，从而能够提高业务请求的处理效率高和处理准确度。

可以理解，上述客户端和服务器对应的应用环境只是作为一种应用示例，本申请实施例的业务处理方法的一个目的在于，通过第二用户对业务请求进行验证，由此发挥该第二用户对业务请求的风险进行有效控制的作用，从而能够提高业务处理的安全性，而不会对具体的应用环境加以限制。

本申请实施例中，所述第二用户与所述业务请求对应第一用户可以具有预设用户关系，该预设用户关系具体可以包括：朋友关系、同事关系、监护关系、亲属关系等，故该第二用户具有对业务请求的风险进行有效控制的能力。其中，上述有效控制具体可以包括：阻止上述业务请求的处理，或者，允许上述业务请求的处理等。

本申请实施例中的业务可以包括：支付业务等具备风险的业务，本申请实施例具体以支付业务为例进行说明，其他业务相互参照即可。

本申请实施例中，第二用户可以为预先设置的、用于对第一用户的业 务请求进行验证的用户。在实际应用中，可以通过设置请求对上述第二用户进行设置。其中，上述设置请求可由第一用户触发，也可由第二用户触发。

参照图2，示出了本申请的一种设置第二用户的方法的步骤流程图，具体可以包括如下步骤：

步骤201、第一客户端向服务器发送设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证信息；

在本申请的一种应用示例中，用户d可以在智能终端1中通过用户账户d登录第一客户端，并打开第一客户端的第二用户设置界面，在该第二用户设置界面中输入第二用户的用户账户及验证规则信息，例如用户b的用户账户b，并触发确认控件。

步骤202、服务器在接收上述设置请求后，依据上述设置请求中携带的第二用户信息，向对应第二用户的第二客户端发送所述设置请求；

其中，服务器可以依据第二用户信息，确定上述设置请求对应第二用户的用户账户，并向第二用户的用户账户发送上述设置请求。

步骤203、第二客户端在接收来自服务器的上述设置请求后，通过第二用户获取针对所述设置请求的第一确认消息，并向上述服务器返回第一确认消息、或者第一拒绝消息；

在本申请的一种应用示例中，用户b可以在智能终端2中通过用户账户b登录第二客户端，并在第二客户端中收到来自用户账户b的设置请求，则用户b可以在与用户d沟通的基础上，确定确认上述设置请求，或者，剧集上述设置请求，相应地，可以通过第二客户端向上述服务器返回第一确认消息、或者第一拒绝消息。

步骤204、服务器在接收所述第一确认消息后，建立验证信息与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系。

在本申请的一种可选实施例中，服务器还可以向第一客户端发送上述第一确认消息、或者第一拒绝消息。例如，在用户d登录的第一客户端接收到 上述第一确认消息、或者第一拒绝消息后，设置第二用户的流程结束。

需要说明的是，上述第一客户端、第二客户端可以与用于实现业务功能的app相应，如支付app等，本申请实施例对于上述第一客户端、第二客户端对应的app不加以限制。

需要说明的是，上述设置请求携带的验证信息可以与第二用户所验证的业务相关。

在本申请的一种可选实施例中，上述设置请求中携带的验证信息具体可以包括：所有业务的验证信息、或者部分业务的验证信息。

其中，在上述验证信息包括所有业务的验证信息的情况下，服务器在接收到第一确认消息后，可以建立第一用户信息与第二用户信息之间的映射关系。例如，在用户d的所有业务均由用户b验证的情况下，可以将用户d作为第一用户，并建立用户d与用户b之间的映射关系。上述情况可以适用于用户d对用户b的信任度较高的情形，例如，用户b为用户d的监护人，或者，用户b为用户d的亲属等。

在上述验证信息包括部分业务的验证信息的情况下，上述验证信息中可以包括验证规则。上述情况对用户d对用户b的信任度不加以限制，其中，用户b可以为用户d的监护人、亲属、好友等。

本申请实施例中，上述验证规则可用于约束第二用户所验证的业务。在本申请的一种可选实施例中，所述验证规则具体可以包括：一种或多种业务信息对应的规则。也即，上述验证规则可以涉及一种或多种业务信息，其中，在涉及多种业务信息时，可以按照预置语法规则对多种业务信息进行组合以得到对应的验证规则，其中，上述预置语法规则可以为正则规则，也可以为逻辑运算规则等，本申请实施例对于具体的验证规则不加以限制。

在本申请的一种可选实施例中，所述业务信息具体可以包括如下信息中的至少一种：业务对应参数、业务对象、业务来源、业务发生时间、业务发生地点和预置时间段内的业务发生次数；

所述验证规则具体可以包括如下规则中的至少一种：

业务对应参数在预置额度范围内；

业务对象在预置对象范围内；

业务来源在预置来源范围内；

业务发生时间在预置时间范围内；

业务发生地点在预置地点范围内；以及

预置时间段内的业务发生次数在预置次数范围内。

其中，上述预置时间段的周期可以为一天、一周等。

以支付场景为例，上述业务对应参数具体可以包括支付额度，例如：单次支付额度，或者，预置时间段内的支付额度等；业务对象具体可以包括支付对象，业务来源具体可以包括支付来源，例如：银行卡、余额、余额增值服务等；业务发生时间具体可以包括支付时间，业务发生地点具体可以包括支付地点。所述验证规则具体可以包括如下规则中的至少一种：

支付额度在预置额度范围内；

支付对象在预置对象范围内；

支付来源在预置来源范围内；

支付时间在预置支付时间范围内；

支付地点在预置支付地点范围内；以及

预置时间段内的支付次数在预置次数范围内。

在本申请的一种可选实施例中，在上述验证信息包括验证规则的情况下，服务器在接收到第一确认消息后，可以针对第一用户建立验证规则与第二用户信息之间的映射关系。在本申请的另一种可选实施例中，在上述验证信息包括验证规则的情况下，服务器在接收到第一确认消息后，还可以建立第一用户信息、验证规则与第二用户信息之间的映射关系。

参照图3，示出了本申请的一种建立验证规则与第二用户信息之间的映射关系的方法的步骤流程图，具体可以包括：

步骤301、接收设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

步骤302、依据所述第二用户信息，向对应第二用户的第二客户端发送所述设置请求；

步骤303、接收所述第二客户端返回的、针对所述设置请求的第一确认消息；

步骤304、在接收所述第一确认消息后，建立验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系。

其中，图3所示流程可由第一客户端或者服务器执行，第二用户可用于表示第一用户设置的第二用户，如前述用户b。

参照表1，示出了本申请的一种验证规则与第二用户的映射关系示例。其中，一个第二用户可以对应一种或多种验证规则，如第二用户c可以对应一种验证规则，而第二用户a和第二用户b可以对应多种验证规则。并且，验证规则可以与当前业务请求相关，也可以与一个预置时间段(如一天)内的业务请求相关。

表1

需要说明的是，上述由服务器建立第一用户与第二用户之间的映射关系、由服务器建立验证规则与第二用户之间的映射关系、或者由服务器建立第一用户、验证规则与第二用户之间的映射关系只是作为本申请的可选实施例，其具有防止上述映射关系被用户篡改的优点，因此能够提高业务处理的安全性。在本申请的其他实施例中，也可由第一客户端和/或第二客户端建立第一用户与第二用户之间的映射关系、建立验证规则与第二用户 之间的映射关系、或者建立第一用户、验证规则与第二用户之间的映射关系，并且，为了提高安全性，还可以在第一客户端和/或第二客户端对上述映射关系数据进行加密等，本申请实施例对于建立上述映射关系的具体执行主体不加以限制。

另外，需要说明的是，上述图2中通过服务器中转设置请求和第一确认消息的过程只是作为可选实施例，实际上，第一客户端和第二客户端之间可以直接通信，二者之间可以通过业务app提供的通信平台、其他app提供的即时通信平台、或者短消息平台等平台进行通信，本申请实施例对二者之间的通信方式不加以限制。

另外，需要说明的是，上述图2中第一用户通过第一客户端触发设置请求的过程只是作为示例，实际上，第二用户也可以通过第二客户端触发设置请求，本申请实施例对于设置请求对应的触发方不加以限制。

本申请实施例可以提供确定第二用户的如下技术方案：

技术方案1

技术方案1中，可以通过如下步骤确定所述第二用户：

步骤a1、依据所述第一用户对应的验证规则，确定所述第二用户。

在实际应用中，业务请求可以携带有第一用户信息(如第一用户的用户账户信息)，故可以首先依据上述第一用户信息确定第一用户对应的验证规则，然后依据验证规则确定第二用户。其中，可以依据第一用户与验证规则之间的映射关系确定第一用户对应的验证规则，也可以从第一用户对应的预先存储内容中直接读取对应的验证规则，本申请实施例对于第一用户对应的验证规则的确定方式不加以限制。

在本申请的一种可选实施例中，上述步骤a1具体可以包括：在所述业务请求中携带的业务信息和/或预置时间段内的业务请求中携带的业务信息符合所述第一用户对应的验证规则时，依据预先建立的验证规则与第二用户信息之间的映射关系，得到所述验证规则对应的第二用户信息，作为所述第二用户的信息。

在实际应用中，可以将上述业务请求中携带的业务信息与类似表1所示映射关系中的验证规则进行匹配，若匹配成功，则可认为上述业务请求对 应的业务信息符合上述验证规则。例如，假设上述业务请求对应的支付额度为20000，则可以认为上述业务请求符合“一次支付额度大于10000”的验证规则，从而可以得到上述第二用户a的信息。又如，假设上述业务请求对应的支付来源为余额，则可以认为上述业务请求符合“通过余额支付”的验证规则，从而可以得到上述第二用户c的信息。可以看出，上述第二用户可以为一个或者多个。

同理，可以将预置时间段内的业务请求中携带的业务信息与类似表1所示映射关系中的验证规则进行匹配，若匹配成功，则可认为预置时间段内的业务请求中携带的业务信息符合上述验证规则。例如，假设一天内的业务请求的次数为5，每次业务请求所涉及的支付额度均未20000，则可以认为一天内的业务请求符合“一天内支付额度大于等于100000”的验证规则，从而可以得到上述第二用户b的信息。又如，假设一天内的业务请求的次数为10，则可以认为一天内的业务请求符合“一天内交易次数大于等于10”的验证规则，从而可以得到上述第二用户a的信息。

技术方案2

技术方案2中，可以通过如下步骤确定所述第二用户：

步骤b1、依据所述业务请求携带的第一用户信息和业务信息，在第一用户信息、验证规则和第二用户信息之间的映射关系中进行查找，以得到所述第二用户的信息。

在实际应用中，可以分别将业务请求携带的第一用户信息和业务信息与在第一用户信息、验证规则和第二用户信息之间的映射关系中的第一用户信息和验证规则进行匹配，并在二者的匹配均成功时，得到对应的第二用户信息。

技术方案3

技术方案3中，可以通过如下步骤确定所述第二用户：

步骤c1、依据所述业务请求携带的第一用户信息，在第一用户信息与第二用户信息之间的映射关系进行查找，以得到所述第二用户的信息。

技术方案3可以适用于第二用户用于验证所有业务的情形，例如，在用户d的所有业务均由用户b验证的情况下，可以预先建立用户d与用户b 之间的映射关系，并在第一用户信息为用户d的信息时，通过查找得到第二用户为用户b。

以上通过技术方案1-技术方案3对确定第二用户的技术方案进行了详细介绍，可以理解，本领域技术人员可以根据实际应用需求，采用上述技术方案1-技术方案3中的任一或者组合，或者，还可以采用确定第二用户的其他技术方案，本申请实施例对于确定第二用户的具体技术方案不加以限制。

在本申请的一种可选实施例中，上述步骤103得到的验证结果具体可以包括：阻止或者允许。而步骤104在所述验证结果符合预置规则时，可以终止对所述业务请求的处理，因此可以阻止第一用户的用户账户对应的非法业务或者不良支付。

需要说明的是，第二用户可以为一个或者多个，在第二用户为多个时，多个第二用户对应的验证结果可能是不同的，此种情况下可以根据实际应用需求，采用对应的预置规则确定阻止或者放行业务请求。例如，一种预置规则可以为，至少一个验证结果中包括阻止，也即一旦出现阻止的验证结果，即可以阻止所述业务请求的处理。又如，一种预置规则可以为，阻止的次数大于第一阈值。再如，一种预置规则可以为阻止的次数相对于拒绝的次数的比例大于第二阈值。其中，第二阈值可以为大于1的数值等。

可以理解，在本申请的一种可选实施例中，在所述验证结果不符合预置规则时，可以继续所述业务请求的处理。例如，在第二用户为一个、且该第二用户对应的验证结果为允许时，可以继续所述业务请求的处理。

综上，本申请实施例在业务请求的处理流程中，通过第一用户之外的第二用户来执行验证操作；由于该第二用户通常为与第一用户具有预设用户关系的用户，故其具备对业务请求的风险进行有效控制的能力，因此本申请实施例可以有效阻止非正常业务的执行，从而能够提高业务处理的安全性。

方法实施例二

参照图4，示出了本申请的一种业务处理方法实施例二的步骤流程图，具体可以包括如下步骤：

步骤401、服务器接收第一用户的业务请求；

步骤402、服务器向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户可以具有预设用户关系；

步骤403、服务器接收所述第二客户端对所述验证请求的验证结果；

步骤404、服务器在所述验证结果符合预置规则时，终止对所述业务请求的处理；

步骤405、服务器向所述第一用户的第一客户端发送终止消息；所述终止消息用于指示所述业务请求的终止。

相对于图1所示方法实施例一，图4的流程可以应用于服务器，服务器向第一客户端发送的终止消息可用于指示所述业务请求的终止，以使第一用户获知上述业务请求的状态。

在本申请的一种可选实施例中，服务器在所述验证结果不符合预置规则时，可以继续所述业务请求的处理，并向所述第一用户的第一客户端发送对应的处理结果。

方法实施例三

参照图5，示出了本申请的一种业务处理方法实施例三的步骤流程图，具体可以包括如下步骤：

步骤501、第一客户端向服务器发送第一用户的业务请求；

步骤502、服务器向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户可以具有预设用户关系；

步骤503、第二客户端接收服务器发送的、第一用户的业务请求所对应的验证请求；

步骤504、第二客户端通过第二用户对所述验证请求进行验证，以得到对应的验证结果；

步骤505、第二客户端向所述服务器发送所述验证结果；

步骤506、服务器接收所述第二客户端对所述验证请求的验证结果，并在所述验证结果符合预置规则时，终止对所述业务请求的处理。

需要说明的是，上述业务请求中可以携带业务信息等信息，上述验证请求中可以携带上述业务信息和第一用户信息等，此种情况下，上述验证请求和上述业务请求可以携带不同的信息。或者，上述业务请求中可以携带业务信息和第一用户信息等信息，此种情况下，上述验证请求可以携带相同的信息。可以理解，本申请实施例对于上述业务请求和上述验证请求所携带的具体信息不加以限制。

为使本领域技术人员更好地理解本申请实施例，参照图6，示出了本申请的一种支付业务处理系统的结构示意图，其具体可以包括：服务器601、第一客户端602和第二客户端603，相应地，在此给出本申请的一种支付业务处理方法示例的步骤流程图，具体可以包括如下步骤：

步骤s1、第一客户端602接收用户账户d发起的支付业务请求，并向服务器601发送该支付业务请求；

步骤s2、服务器601判断该支付业务请求是否需要验证，若是，则执行步骤s3，否则按照传统流程进行处理；

在本申请的一种可选实施例中，服务器判断该支付业务请求是否需要验证的过程具体可以包括：将该支付业务请求中携带的业务信息和/或预置时间段内的支付业务请求中携带的业务信息与用户账户d的验证规则进行匹配，若匹配成功，则确定该支付业务请求需要验证。或者，服务器判断该支付业务请求是否需要验证的过程具体可以包括：将该支付业务请求中携带的第一用户信息与第一用户信息与第二用户信息之间的映射关系中的第一用户信息进行匹配，若匹配成功，则确定该支付业务请求需要验证。可以理解，本申请实施例对于该支付业务请求是否需要验证的具体判断过程不加以限制。

步骤s3、服务器601确定该支付第二用户b；

步骤s4、服务器601向第二用户b对应用户账户b的第二客户端603 发送验证请求；

步骤s5、第二客户端603接收上述验证请求，并接收用户账户b输入的验证结果；

在实际应用中，用户b在支付应用中收到验证请求后，可以通过与用户d沟通(当面沟通、基于即时通信的沟通等)等方式，确定该验证请求对应的验证结果，并在支付应用中输入该验证结果。

步骤s6、第二客户端603向服务器601发送上述验证结果；

步骤s7、在所述验证结果符合预置规则时，服务器601终止该支付业务请求的处理。

例如，如果用户b的验证结果为允许，则按照传统流程处理用户d的支付业务请求直到结束。如果用户b的验证结果为阻止，则用户d的支付业务请求被终止。

步骤s8、服务器601向用户账户d对应第一客户端602发送终止信息，以使用户d在支付应用中收到操作结果信息。

方法实施例三

本实施例为方法实施例一或方法实施例二的可选实施例，其在方法实施例一或方法实施例二的基础上，还可以包括如下可选技术方案。

本实施例中，为了防止非法用户在盗用用户账户后自行设置第二用户、或者防止未成年人在被蒙骗的情况下自行设置第二用户，本申请实施例还可以通过如下方式拒绝来自第一用户的设置请求，相应地，本申请实施例可以提供拒绝设置请求的如下方式：

方式1

方式1可以在接收设置请求后，可以确定所述第一用户信息所对应用户账户的当前状态，在所述当前状态为预置状态时，拒绝所述设置请求。

方式1可以依据用户账户的当前状态是否为预置状态，确定是否拒绝设置请求。由于上述预置状态可用于表示用户账户不受合法用户控制的状态，故本申请实施例拒绝此种情形下的设置请求，可以提高业务验证的安全性。

例如，用户账户d的初始状态可以为正常状态，而在用户账户d的智能终端丢失或者登录密码、支付密码被盗后，可以向服务器发送挂失请求，而服务器可以将用户账户d的当前状态置为挂失状态，则该挂失状态可以为预置状态。又如，用户账户c为未成年人，其状态具体可以包括：控制状态和非控制状态；其中，可以根据时间段对控制状态和非控制状态进行区分，例如，在白天时间段，由于父母不在身旁，故用户账户c的状态可以为非控制状态，而在黑夜时间段，由于父母在身旁，故用户账户c的状态可以为控制状态。另外，可以依据父母对应用户账户的触发，确定用户账户c的当前状态，本申请实施例对于用户账户的当前状态的具体确定方式不加以限制。

方式2、

方式2中，本申请实施例还可以包括如下步骤：

步骤d1、接收设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

步骤d2、依据所述第二用户信息，向对应第二用户的第二客户端发送所述设置请求；

步骤d3、依据所述第二客户端返回的、针对所述设置请求的第一拒绝消息，拒绝所述设置请求。

由于第二用户能够及时得知第一用户的用户账户被盗的情况，故其在确定第一用户的用户账户被盗后，其可以拒绝第一用户的设置请求，以防止第一用户恶意通过设置请求进行第二用户的设置。

方式3、

方式3中，本申请实施例还可以包括如下步骤：

步骤e1、接收设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

步骤e2、确定验证范围超出所述验证规则对应验证范围的验证规则所对应的第三用户；

步骤e3、向第三用户的第三客户端发送所述设置请求；

步骤e4、接收所述第三客户端返回的、针对所述设置请求的第三拒绝 消息；

步骤e5、依据所述第三拒绝消息，拒绝所述设置请求。

本申请实施例中，验证规则通常具有对应的验证范围，该验证范围可以包括上述预置额度范围、上述预置对象范围等，方式3中，第三用户为已经设置成功的用于验证的用户，在设置请求对应验证范围小于等于第三用户的验证范围时，需要通过第三用户的验证。

以表1为例，原有验证规则“一次支付额度大于10000”对应的第二用户为用户a，则本申请实施例不允许第一用户单方面缩小验证范围，例如，若第一用户欲新增验证规则“一次支付额度大于20000”，则由于该新增的验证规则在原有验证规则对应的验证范围内，故其新增也需要经过用户a的确认方能生效。

需要说明的是，对于方式1，在所述当前状态不为预置状态时，可以允许所述设置请求。对于方式3，在接收所述第三客户端返回的、针对所述设置请求的第三确认消息后，可以允许所述设置请求。本申请实施例对于设置请求对应的允许时机不加以限制。

方法实施例四

本实施例为方法实施例一或方法实施例二或方法实施例三的可选实施例，其在方法实施例一或方法实施例二或方法实施例三的基础上，还可以包括如下可选技术方案。

本实施例中，不允许第一用户单方面取消验证或者缩小验证范围，这样，即使第一用户被盗，原有的第二用户仍然能够有效地进行业务请求的验证，因此能够提高业务验证的规范性。

以表1为例，验证规则“一次支付额度大于10000”对应的第二用户为用户a，则本申请实施例不允许第一用户单方面取消该验证规则，该验证规则的取消需要经过用户a的确认方能生效。另外，本申请实施例不允许第一用户单方面缩小验证范围，例如，第一用户若将验证规则“一次支付额度大于10000”修改为“一次支付额度大于20000”，由于变更后的验证 规则在原有验证规则对应的验证范围内，故验证规则的变更需要经过用户a的确认方能生效。

本申请实施例中，取消请求或者变更请求的控制过程具体可以包括：

步骤f1、接收取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

在实际应用中，第一客户端可以向服务器发送取消请求或变更请求。

步骤f2、依据所述第二用户信息，向对应第二用户的第二客户端发送所述取消请求或变更请求；

步骤f3、接收所述第二客户端返回的、针对所述取消请求或变更请求的第二确认消息；

在实际应用中，第二客户端可以通过第二用户获取针对所述取消请求或变更请求的第二取消消息；向所述服务器发送所述第二取消消息。其中，可以通过键盘、语音、鼠标等形式采集第二用户针对所述取消请求或变更请求的第二取消消息，本申请实施例对于第二取消消息的具体获取方式不加以限制。

步骤f4、在接收所述第二确认消息后，删除对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

在本申请的一种可选实施例中，取消请求或者变更请求的控制过程还可以包括：

步骤f5、接收所述第二客户端返回的、针对所述取消请求或变更请求的第二拒绝消息；

步骤f6、在接收所述第二拒绝消息后，维持对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

在此提供取消请求的控制过程中的应用示例。该应用示例中，用户账户d在支付应用中发起针对验证规则1的取消请求，假设该验证规则1对应的第二用户为用户账户b，则用户账户d对应的第一客户端可以向服务器发送取消请求及对应的用户账户b的信息；而服务器可以向用户账户b发送 上述取消请求；用户b在支付应用中收到来自用户账户a的取消请求后，可以在与用户a沟通的基础上，同意取消或者拒绝取消，而用户账户b可以向服务器发送对应的第二确认消息或者第二拒绝消息。在接收到第二确认消息后，服务器可以删除对应验证规则与第二第二用户信息之间的映射关系，以及，在接收到第二拒绝消息后，服务器可以维持对应验证规则与第二第二用户信息之间的映射关系。并且，服务器还可以向用户账户d对应的第一客户端发送对应的操作结果消息。

在此提供变更请求的控制过程中的应用示例。该应用示例中，用户账户d在支付应用中发起针对验证规则1的变更请求，且变更后验证规则2的验证范围小于验证规则1的验证范围(如在验证规则1的基础上增加支付额度)，假设该验证规则1对应的第二用户为用户账户b，则用户账户d对应的第一客户端可以向服务器发送变更请求及对应的用户账户b的信息；而服务器可以向用户账户b发送上述变更请求；用户b在支付应用中收到来自用户账户a的变更请求后，可以在与用户a沟通的基础上，同意变更或者拒绝变更，而用户账户b可以向服务器发送对应的第二确认消息或者第二拒绝消息。在接收到第二确认消息后，服务器可以删除对应验证规则与第二第二用户信息之间的映射关系，以及，在接收到第二拒绝消息后，服务器可以维持对应验证规则与第二第二用户信息之间的映射关系。并且，服务器还可以向用户账户d对应的第一客户端发送对应的操作结果消息。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

装置实施例一

参照图7，示出了本申请的一种业务处理装置实施例一的结构框图，该 装置可以应用于服务器侧，具体可以包括如下模块：

第一接收模块701，用于接收第一用户的业务请求；

第一发送模块702，用于向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户具有预设用户关系；

第二接收模块703，用于接收所述第二客户端对所述验证请求的验证结果；以及

终止模块704，用于在所述验证结果符合预置规则时，终止对所述业务请求的处理。

在本申请的一种可选实施例中，所述装置还可以包括：确定模块，用于确定所述第二用户；

所述确定模块，具体可以包括：

第一确定子模块，依据所述第一用户对应的验证规则，确定所述第二用户；或者

第二确定子模块，依据所述业务请求携带的第一用户信息和业务信息，在第一用户信息、验证规则和第二用户信息之间的映射关系中进行查找，以得到所述第二用户的信息；或者

第三确定子模块，依据所述业务请求携带的第一用户信息，在第一用户信息与第二用户信息之间的映射关系进行查找，以得到所述第二用户的信息。

在本申请的另一种可选实施例中，所述第一确定子模块，具体可以包括：

查找单元，用于在所述业务请求中携带的业务信息和/或预置时间段内的业务请求中携带的业务信息符合所述验证规则时，依据预先建立的验证规则与第二用户信息之间的映射关系，得到所述验证规则对应的第二用户信息，作为所述第二用户的信息。

在本申请的再一种可选实施例中，所述装置还可以包括：

第二发送模块，用于向所述第一用户的第一客户端发送终止消息；所述终止消息用于指示所述业务请求的终止。

在本申请的又一种可选实施例中，所述装置还可以包括：

第三接收模块，用于接收设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

第三发送模块，用于依据所述第二用户信息，向对应第二用户的第二客户端发送所述设置请求；

第四接收模块，用于接收所述第二客户端返回的、针对所述设置请求的第一确认消息；

建立模块，用于在接收所述第一确认消息后，建立验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

在本申请的一种可选实施例中，所述装置还可以包括：

第一拒绝模块，用于确定所述第一用户信息所对应用户账户的当前状态，在所述当前状态为预置状态时，拒绝所述设置请求；或者

第二拒绝模块，用于依据所述第二客户端返回的、针对所述设置请求的第一拒绝消息，拒绝所述设置请求；或者

第二拒绝模块，用于确定验证范围超出所述验证规则对应验证范围的验证规则所对应的第三用户，向所述第三用户的第三客户端发送所述设置请求，接收所述第三客户端返回的、针对所述设置请求的第三拒绝消息，并依据所述第三拒绝消息，拒绝所述设置请求。

在本申请的另一种可选实施例中，所述装置还可以包括：

第五接收模块，用于接收取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

第四发送模块，用于依据所述第二用户信息，向对应第二用户的第二客户端发送所述取消请求或变更请求；

第六接收模块，用于接收所述第二客户端返回的、针对所述取消请求或变更请求的第二确认消息；

删除模块，用于在接收所述第二确认消息后，删除对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

在本申请的又一种可选实施例中，所述装置还可以包括：

第七接收模块，用于接收所述第二客户端返回的、针对所述取消请求或变更请求的第二拒绝消息；

维持模块，用于在接收所述第二拒绝消息后，维持对应验证规则与第二用户信息之间的映射关系、或者第一用户信息与第二用户信息之间的映射关系、或者第一用户、验证规则与第二用户之间的映射关系。

装置实施例二

参照图8，示出了本申请的一种业务处理装置实施例二的结构框图，该装置可以应用于第二用户对应第二用户侧，具体可以包括如下模块：

第一接收模块801，用于接收服务器发送的、第一用户的业务请求所对应的验证请求；

验证模块802，用于通过第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系；以及

第一发送模块803，用于向所述服务器发送所述验证结果。

在本申请的一种可选实施例中，所述装置还可以包括：

第二接收模块，用于接收服务器发送的设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则；

第一获取模块，用于通过第二用户获取针对所述设置请求的第一确认消息；

第二发送模块，用于向所述服务器发送所述第一确认消息。

在本申请的另一种可选实施例中，所述装置还可以包括：

第二获取模块，用于通过第二用户获取得到针对所述设置请求的第一拒绝消息；

第三发送模块，用于向所述服务器发送所述第一拒绝消息。

在本申请的再一种可选实施例中，所述装置还可以包括：

第三接收模块，用于接收服务器发送的取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则；

第三获取模块，用于通过第二用户获取针对所述取消请求或变更请求的第二确认消息；

第四发送模块，用于向所述服务器发送所述第二确认消息。

在本申请的又一种可选实施例中，所述装置还可以包括：

第四获取模块，用于通过第二用户获取针对所述取消请求或变更请求的第二取消消息；

第五发送模块，用于向所述服务器发送所述第二取消消息。

装置实施例三

本申请还提供了一种业务处理装置实施例三，该装置可以应用于第一用户对应第一客户端侧，具体可以包括如下模块：

第一发送模块，用于向服务器发送第一用户的业务请求，以使所述服务器向第二用户的第二客户端发送所述业务请求对应的验证请求，并使第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系。

在本申请的另一种可选实施例中，所述装置还可以包括：

接收模块，用于接收所述服务器针对所述业务请求返回的终止消息；所述终止消息用于指示所述业务请求的终止。

在本申请的再一种可选实施例中，所述装置还可以包括：

第二发送模块，用于向服务器发送设置请求；其中，所述设置请求中携带有第一用户信息、第二用户信息和对应的验证规则。

在本申请的又一种可选实施例中，所述装置还可以包括：

第三发送模块，用于向服务器发送取消请求或变更请求；其中，所述取消请求或变更请求中携带有第一用户信息、第二用户信息及其对应的验证规则。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请还提供了一种业务处理系统实施例，该系统具体可以包括：服务 器、第一客户端和第二客户端；

其中，上述服务器具体可以包括：

第一接收模块，用于接收第一用户的业务请求；

第一发送模块，用于向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户具有预设用户关系；

第二接收模块，用于接收所述第二客户端对所述验证请求的验证结果；以及

终止模块，用于在所述验证结果符合预置规则时，终止对所述业务请求的处理；

上述第二客户端具体可以包括：

第三接收模块，用于接收服务器发送的、第一用户的业务请求所对应的验证请求；

验证模块，用于通过第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系；以及

第二发送模块，用于向所述服务器发送所述验证结果；

上述第一客户端具体可以包括：

第三发送模块，用于向服务器发送第一用户的业务请求，以使所述服务器向第二用户的第二客户端发送所述业务请求对应的验证请求，并使第二用户对所述验证请求进行验证，以得到对应的验证结果；其中，所述第二用户与所述第一用户具有预设用户关系。

智能终端实施例

参照图9，示出了本申请一种智能终端实施例的结构框图，具体可以包括：至少一个存储器901、显示器902、至少一个处理器903和至少一个输入单元904。

其中，该输入单元904可用于接收用户输入的数字或字符信息，以及控制信号。具体地，本申请实施例中，该输入单元904可以包括触摸屏941，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触摸屏941上的操作)，并根据预先设定的程式驱动相应的 连接装置。当然，除了触摸屏941，输入单元904还可以包括其他输入设备，如物理键盘、功能键(比如音量控制按键、开关按键等)、鼠标等。

显示器902具体可以包括显示面板，可选的，可以采用液晶显示器(liquidcrystaldisplay，lcd)或有机发光二极管(organiclight-emittingdiode，oled)等形式来配置显示面板。其中，触摸屏941可以覆盖显示面板，形成触摸显示屏，当该触摸显示屏检测到在其上或附近的触摸操作后，传送给处理器903以执行相应的处理。

在本申请实施例中，通过调用存储该存储器901内的程序，和/或，模块，和/或，数据，处理器903接收第一用户的业务请求；向第二用户的第二客户端发送所述业务请求对应的验证请求；其中，所述第二用户与所述第一用户具有预设用户关系；接收所述第二客户端对所述验证请求的验证结果；在所述验证结果符合预置规则时，终止对所述业务请求的处理。

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

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但 不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所 有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种业务处理方法、一种业务处理装置和一种智能终端，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。