本申請涉及網絡通信技術領域，特別是涉及一種業務處理方法、一種業務處理裝置和一種智能終端。

背景技術：

隨著通信技術的發展，人們越來越多地改變現金支付的習慣，采用通過互聯網和手機等電子形式的工具進行支付。例如，用戶在網絡購物平臺購買物品的過程中，可以通過電子形式的工具對該物品的款項進行支付。又如，一個用戶可以通過電子形式的工具向其他用戶支付款項等等。

現有的支付方案中，用戶主要通過輸入用戶憑據來完成支付。上述用戶憑據具體可以包括：登錄密碼、支付密碼，證書，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)，如調制的數據信號和載波。

本申請實施例是參照根據本申請實施例的方法、終端設備(系統)、和計算機程序產品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數據處理終端設備的處理器以產生一個機器，使得通過計算機或其他可編程數據處理終端設備的處理器執行的指令產生用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數據處理終端設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產生包括指令裝置的制造品，該指令裝置實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數據處理終端設備上，使得在計算機或其他可編程終端設備上執行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程終端設備上執行的指令提供用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

盡管已描述了本申請實施例的優選實施例，但本領域內的技術人員一旦得知了基本創造性概念，則可對這些實施例做出另外的變更和修改。所以，所附權利要求意欲解釋為包括優選實施例以及落入本申請實施例范圍的所 有變更和修改。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者終端設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者終端設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者終端設備中還存在另外的相同要素。

以上對本申請所提供的一種業務處理方法、一種業務處理裝置和一種智能終端，進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領域的一般技術人員，依據本申請的思想，在具體實施方式及應用范圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本申請的限制。