本發(fā)明涉及電子技術領域，尤其是涉及一種數(shù)據(jù)交互方法和裝置。

背景技術：

隨著互聯(lián)網(wǎng)的飛速發(fā)展，網(wǎng)絡上興起了發(fā)電子紅包的熱潮，不少企業(yè)抓住這一契機通過發(fā)電子紅包的機會發(fā)送大量的目標數(shù)據(jù)給目標接收者。但現(xiàn)有技術中，終端收到電子紅包后點擊電子紅包即可領取，無需任何其它操作，并且市場上出現(xiàn)了一些紅包外掛的軟件，終端裝上外掛軟件后就可以自動獲取電子紅包，導致目標數(shù)據(jù)大量流失而不能傳送到目標接收者的手中。因此，現(xiàn)有技術中數(shù)據(jù)交互的準確性和有效性亟待提高。

技術實現(xiàn)要素：

本發(fā)明的主要目的在于提供一種數(shù)據(jù)交換方法和裝置，旨在提高數(shù)據(jù)交互的準確性和有效性。

為達以上目的，本發(fā)明提出一種數(shù)據(jù)交互方法，包括以下步驟：

接收客戶端發(fā)送的獲取資源文件的核心文件的請求，所述資源文件包括封裝文件和設于所述封裝文件內的所述核心文件，所述封裝文件設有封口；

根據(jù)所述請求判斷是否滿足預設條件；

當滿足預設條件時，允許所述客戶端獲取所述核心文件；否則，拒絕所述客戶端的請求。

本發(fā)明同時提出一種數(shù)據(jù)交互裝置，包括：

接收模塊，用于接收客戶端發(fā)送的獲取資源文件的核心文件的請求，所述資源文件包括封裝文件和設于所述封裝文件內的所述核心文件，所述封裝文件設有封口；

判斷模塊，用于根據(jù)所述請求判斷是否滿足預設條件；

處理模塊，用于當滿足預設條件時，允許所述客戶端獲取所述核心文件；否則，拒絕所述客戶端的請求。

本發(fā)明所提供的一種數(shù)據(jù)交互方法，通過在資源文件上設置獲取條件，使得用戶必須在客戶端上進行操作才能獲取資源文件的核心文件，從而可以避免外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性。

附圖說明

圖1是本發(fā)明的數(shù)據(jù)交互方法第一實施例的流程圖；

圖2是本發(fā)明實施例中的資源文件的示意圖；

圖3是本發(fā)明的數(shù)據(jù)交互方法第二實施例的流程圖；

圖4是本發(fā)明的數(shù)據(jù)交互方法第三實施例的流程圖；

圖5是本發(fā)明的數(shù)據(jù)交互方法第四實施例的流程圖；

圖6為本發(fā)明的數(shù)據(jù)交互方法第四實施例的流程圖；

圖7為本發(fā)明實施例中電子紅包的信息交互示意圖；

圖8為本發(fā)明實施例中各主體基于電子紅包的信息交互示意圖；

圖9為現(xiàn)有技術中電子紅包的信息交互示意圖；

圖10為現(xiàn)有技術中各主體基于電子紅包的信息交互示意圖；

圖11為本發(fā)明實施例中電子紅包的又一信息交互示意圖；

圖12是本發(fā)明的數(shù)據(jù)交互系統(tǒng)一實施例的模塊示意圖；

圖13是本發(fā)明的數(shù)據(jù)交互裝置一實施例的模塊示意圖；

圖14是圖13中的數(shù)據(jù)交互裝置的判斷模塊的模塊示意圖。

本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結合實施例，參照附圖做進一步說明。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

本發(fā)明實施例中，資源文件是指能夠在網(wǎng)絡上發(fā)放資源的電子文件，資源文件包括封裝文件和設于封裝文件內的核心文件，封裝文件通常設有封口，當打開封裝文件的封口后就能獲取核心文件。例如，紅包電子文件(或稱電子紅包)即為一種典型的資源文件，通過紅包電子文件可以發(fā)放現(xiàn)金、電子 憑證和電子消費券等資金資源，紅包電子文件通常包括封套(即封裝文件)和設于封套內的內容物(即核心文件)，封套通常設有封口，打開封套上的封口就能獲取內容物，該內容物即現(xiàn)金、電子憑證和電子消費券等資金資源。所述電子消費券包括優(yōu)惠券、折扣券、抵用券、兌換券等。電子憑證包括銀信證、物信證或其他電子憑證。

其中，銀信證是指資源管理機構(如銀行)根據(jù)開證人的申請凍結其信用額度或其賬戶中一定額度的資金而生成的具有支付功能的電子信用憑證；收證人綁定的資源管理機構收到電子憑證后，將電子憑證綁定收證人從而完成收證，收證后收證人可申請?zhí)岈F(xiàn)，收到提現(xiàn)的請求后收證機構(如收證銀行)與開證機構(如開證銀行)進行資金劃撥，收證人即可得到開證人通過電子憑證凍結的資金。在銀行版電子紅包(即紅包電子文件)場景中，開證人即向銀行申請發(fā)放電子紅包的企業(yè)。當領取了電子紅包后，用戶在銀信證的收證人處輸入自己的銀行賬號信息，向銀行申請收證，銀行即在約定的時間內將資金轉入收證賬戶。

銀信證的業(yè)務流程如下：

1.1、開證人通過互聯(lián)網(wǎng)或以其他方式向開證銀行申請開證；

1.2、開證銀行驗證身份、賬戶信息無誤后受理，審核確認符合開證條件，凍結保付資金后開立銀信證；

1.3、收證人通過互聯(lián)網(wǎng)或以其他方式向收證銀行申請收證；

1.4、收證銀行驗證身份、賬戶信息無誤后受理收證(或根據(jù)收證人設置由收證銀行自動收證)；

1.5、收證人履行銀信證項下基礎交易義務后，提交履約信息(一般用于電商領域，收證人為商家，履行發(fā)貨義務后，提交發(fā)貨信息，在電子紅包領域中，由于是開證人無償轉移給收證人，因此就不需要履行交易義務)；

1.6、收證人或指定的第三方將申請解付信息發(fā)送至開證銀行申請解付(在電子紅包領域中，收證人填寫收證后即自動申請解付)；

1.7、開證銀行解付銀信證并將資金劃轉至收證銀行，收證銀行將資金轉入收證賬戶。

物信證是指標的物交易信息記錄憑證，是記載和傳播商品(包括服務)信息的一種標準化、通用化網(wǎng)絡電子單證。物信證上集成了電子商務所必備的各項功能，一旦觸發(fā)即可啟動預設流程，例如會根據(jù)預設程序和交易規(guī)則 啟動供應商發(fā)貨、物流配送、銀行卡付收款等流程。物信證可實現(xiàn)全網(wǎng)域分發(fā)、流轉和交易。物信證至少包括具有名稱和金額的物品屬性以及具有至少一個賬戶的收結算信息。物信證由產品供應商提供，收款賬戶為產品供應商賬戶。當資源文件的內容物是物信證時，則可以是商家提供的具有優(yōu)惠價格或者價格為零(即免費贈送)的商品的物信證，用戶可以通過物信證的購買功能以較低的價格完成該商品的購買。

參見圖1，提出本發(fā)明的數(shù)據(jù)交互方法第一實施例，所述方法應用于發(fā)放資源文件的服務器，包括以下步驟：

s11、接收客戶端發(fā)送的獲取資源文件的核心文件的請求，根據(jù)該請求判斷是否滿足預設條件。當滿足預設條件時，執(zhí)行步驟s12；當不滿足預設條件時，執(zhí)行步驟s13。

s12、允許客戶端獲取核心文件。

s13、拒絕客戶端的請求。

可選地，在一實施例中，服務器在生成資源文件時在資源文件的封裝文件上設置一封口，并預先設置了打開封口的條件，此時，獲取資源文件的核心文件的請求即打開封裝文件的封口的請求。服務器根據(jù)客戶端發(fā)送的打開封裝文件的封口的請求，判斷是否滿足打開封口的預設條件；當滿足打開封口的預設條件時，允許客戶端打開封裝文件的封口獲取核心文件；當不滿足打開封口的預設條件時，拒絕客戶端的請求，此時客戶端不能獲取核心文件。這種情形將在下述第二實施例中進行詳細說明。

可選地，在另一實施例中，服務器在生成資源文件時在資源文件的封裝文件上設置一封口，并預先設置了顯示封口的條件，此時，封裝文件的封口在平時處于隱藏狀態(tài)，獲取資源文件的核心文件的請求即顯示封裝文件的封口的請求。服務器根據(jù)客戶端發(fā)送的顯示封裝文件的封口的請求，判斷是否滿足顯示封口的預設條件；當滿足顯示封口的預設條件時，在封裝文件上顯示封口，并允許客戶端打開封裝文件的封口獲取核心文件；當不滿足顯示封口的預設條件時，拒絕客戶端的請求，不予顯示封裝文件的封口，此時客戶端不能獲取核心文件。這種情形將在下述第三實施例中進行詳細說明。

可選地，還有一些實施例中，服務器在生成資源文件時在資源文件的封裝文件上設置一封口，并預先設置了顯示封口和打開封口的條件，此時，封裝文件的封口在平時處于隱藏狀態(tài)，獲取資源文件的核心文件的請求包括顯 示封裝文件的封口的請求和打開封裝文件的封口的請求。首先，服務器根據(jù)客戶端發(fā)送的顯示封裝文件的封口的請求，判斷是否滿足顯示封口的預設條件；當滿足顯示封口的預設條件時，在封裝文件上顯示封口；當不滿足顯示封口的預設條件時，拒絕客戶端的請求，不予顯示封裝文件的封口。當顯示封口后，服務器根據(jù)客戶端發(fā)送的打開封裝文件的封口的請求，判斷是否滿足打開封口的預設條件；當滿足打開封口的預設條件時，允許客戶端打開封裝文件的封口獲取核心文件；當不滿足打開封口的預設條件時，拒絕客戶端的請求，此時客戶端不能獲取核心文件。這種情形將在下述第四實施例中進行詳細說明。

如圖2所示，為一公司的資源文件的示意圖，具體顯示的是該資源文件的封裝文件。其中，封裝文件的封口上的文字“xx公司的星意”為資源文件的標題，該標題可以設置為超鏈接，點擊該標題后可以打開企業(yè)網(wǎng)站、關注企業(yè)公眾號等，以幫助企業(yè)引流；封裝文件的中部為多媒體文件(如視頻、音頻等)以及祝福語，通過多媒體的方式進一步展示企業(yè)形象，可以控制必須瀏覽完該多媒體才能獲取資源文件的核心文件；封裝文件底部顯示資源文件的編號。此外，企業(yè)可以自定義品牌形象圖片作為封裝文件的封面背景圖片，每個資源文件傳播出去的時候，用戶都會看到該背景圖片。

本實施例中，服務器收到封裝文件上的鏈接、文字、圖案或/和多媒體被點擊的信息后，或/和收到客戶端輸入的信息后，或/和獲取客戶端的身份信息后，則判斷是否滿足預設條件。也就是說，當資源文件上的鏈接、文字、圖案或/和多媒體被點擊后，輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，服務器則判定滿足預設條件。

舉例而言：資源文件的封裝文件上設置了廣告(以鏈接、文字、圖案或多媒體的方式呈現(xiàn))，當用戶點擊瀏覽了廣告后，用戶才能獲取資源文件的核心文件；或者，用戶欲獲取資源文件的核心文件時，要求用戶輸入密碼，當用戶輸入的密碼正確時，用戶才能獲取核心文件；或者，用戶欲獲取資源文件的核心文件時，要求用戶說出指定的廣告語，當用戶說出了指定的廣告語后，用戶才能獲取核心文件；或者，資源文件是定向發(fā)送的，當發(fā)送請求的客戶端的身份信息顯示該客戶端是定向發(fā)送對象時，則允許用戶獲取資源文件的核心文件。

本實施例中，通過在資源文件上設置獲取條件，使得用戶必須在客戶端 上進行操作才能獲取資源文件的核心文件，從而可以避免外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性獲取。

參見圖3，提出本發(fā)明的數(shù)據(jù)交互方法第二實施例，所述方法包括以下步驟：

s21、客戶端向服務器發(fā)送打開封裝文件的封口的請求。

具體的，客戶端獲取資源文件后，在屏幕上顯示資源文件，根據(jù)用戶的特定操作觸發(fā)打開封裝文件的封口的指令，根據(jù)該指令向服務器發(fā)送打開封裝文件的封口的請求。

例如：用戶點擊資源文件的封裝文件任意位置或特定位置(如封口位置)后則觸發(fā)打開封裝文件的封口的指令，或者用戶點擊資源文件的封裝文件上的圖案、文字、鏈接或/和多媒體后則觸發(fā)打開封裝文件的封口的指令，或者輸入指定的信息后則觸發(fā)打開封裝文件的封口的指令?；蛘邔⑶笆鋈N操作中的任意兩種或三種結合起來才觸發(fā)打開封裝文件的封口的指令。輸入指定的信息，包括輸入文字信息(如輸入數(shù)字密碼或廣告文字)，或者輸入語音信息(如用戶說出特定的廣告語)。

s22、服務器接收打開封裝文件的封口的請求，判斷是否滿足打開封口的預設條件。當滿足該預設條件時，執(zhí)行步驟s23；當不滿足該預設條件時，執(zhí)行步驟s24。

具體的，當資源文件的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊后，或/和輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，服務器則判定滿足打開封口的預設條件；否則，判定不滿足打開封口的預設條件。

s23、服務器允許客戶端打開封裝文件的封口獲取資源文件的核心文件。

具體的，當滿足打開封口的預設條件時，服務器則將客戶端與資源文件綁定(或關聯(lián))，并向客戶端反饋獲取成功的信息，終端接收到信息后，則可以打開封裝文件的封口，獲取資源文件的核心文件。

可選地，在某些實施例中，當滿足打開封口的預設條件時，服務器則自動打開封裝文件的封口，以使客戶端成功獲取資源文件的核心文件。

s24、服務器拒絕客戶端的請求。

具體的，當不滿足打開封口的預設條件時，服務器則拒絕客戶端的請求，同時還可以向客戶端反饋獲取失敗的信息，此時客戶端不能獲取資源文件的 核心文件。

本實施例為資源文件設置了拆封條件，當滿足拆封條件時用戶才能打開封裝文件的封口，進而獲取資源文件的核心文件，從而可以避免外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性。

參見圖4，提出本發(fā)明的數(shù)據(jù)交互方法第三實施例，所述方法包括以下步驟：

s31、客戶端向服務器發(fā)送顯示封裝文件的封口的請求。

具體的，客戶端獲取資源文件后，在屏幕上顯示資源文件，但資源文件的封裝文件上沒有顯示封口。此時，客戶端根據(jù)用戶的特定操作觸發(fā)顯示封裝文件的封口的指令，根據(jù)該指令向服務器發(fā)送顯示封裝文件的封口的請求。

例如：用戶點擊資源文件的封裝文件任意位置或特定位置后則觸發(fā)顯示封裝文件的封口的指令，或者用戶點擊資源文件的封裝文件上的圖案、文字、鏈接或/和多媒體后則觸發(fā)顯示封裝文件的封口的指令，或者輸入指定的信息后則觸發(fā)顯示封裝文件的封口的指令?；蛘邔⑶笆鋈N操作中的任意兩種或三種結合起來才觸發(fā)顯示封裝文件的封口的指令。輸入指定的信息，包括輸入文字信息(如輸入數(shù)字密碼或廣告文字)，或者輸入語音信息(如用戶說出特定的廣告語)。

s32、服務器接收顯示封裝文件的封口的請求，判斷是否滿足顯示封口的預設條件。當滿足該預設條件時，執(zhí)行步驟s33；當不滿足該預設條件時，執(zhí)行步驟s34。

具體的，當資源文件的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊后，或/和輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，服務器則判定滿足顯示封口的預設條件；否則，判定不滿足顯示封口的預設條件。

s33、服務器在封裝文件上顯示封口，并允許客戶端打開封裝文件的封口獲取資源文件的核心文件。

具體的，當滿足顯示封口的預設條件時，服務器則修改資源文件的狀態(tài)為封口可顯示，在資源文件的封裝文件上顯示隱藏的封口，同時將客戶端與資源文件綁定(或關聯(lián))，并向客戶端反饋獲取成功的信息，終端接收到信息后，則可以打開封裝文件的封口，獲取資源文件的核心文件。

可選地，在某些實施例中，當滿足顯示封口的預設條件時，服務器則在 資源文件的封裝文件上顯示隱藏的封口，并自動打開封口，以使客戶端成功獲取資源文件的核心文件。

s34、服務器拒絕客戶端的請求。

具體的，當不滿足顯示封口的預設條件時，服務器則拒絕客戶端的請求，不予顯示封裝文件的封口，同時還可以向客戶端反饋獲取失敗(或封口打開失敗)的信息，此時客戶端不能獲取資源文件的核心文件。

本實施例為資源文件設置了封口顯示條件，當滿足封口顯示條件時才顯示封裝文件的封口，進而用戶才能打開封裝文件的封口獲取核心文件，從而可以避免外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性。

參見圖5，提出本發(fā)明的數(shù)據(jù)交互方法第四實施例，所述方法包括以下步驟：

s41、客戶端向服務器發(fā)送顯示封裝文件的封口的請求。

具體的，客戶端獲取資源文件后，在屏幕上顯示資源文件，但資源文件的封裝文件上沒有顯示封口。此時，客戶端根據(jù)用戶的特定操作觸發(fā)顯示封裝文件的封口的指令，根據(jù)該指令向服務器發(fā)送顯示封裝文件的封口的請求。

例如：用戶點擊資源文件的封裝文件任意位置或特定位置后則觸發(fā)顯示封裝文件的封口的指令，或者用戶點擊資源文件的封裝文件上的圖案、文字、鏈接或/和多媒體后則觸發(fā)顯示封裝文件的封口的指令，或者輸入指定的信息后則觸發(fā)顯示封裝文件的封口的指令?；蛘邔⑶笆鋈N操作中的任意兩種或三種結合起來才觸發(fā)顯示封裝文件的封口的指令。輸入指定的信息，包括輸入文字信息(如輸入數(shù)字密碼或廣告文字)，或者輸入語音信息(如用戶說出特定的廣告語)。

s42、服務器接收顯示封裝文件的封口的請求，判斷是否滿足顯示封口的預設條件。當滿足該預設條件時，執(zhí)行步驟s43；當不滿足該預設條件時，執(zhí)行步驟s47。

具體的，當資源文件的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊后，或/和輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，服務器則判定滿足顯示封口的預設條件；否則，判定不滿足顯示封口的預設條件。

s43、服務器在封裝文件上顯示封口。

具體的，當滿足顯示封裝文件的封口的預設條件時，服務器則修改資源文件的狀態(tài)為封口可顯示，在資源文件的封裝文件上顯示隱藏的封口。

s44、客戶端向服務器發(fā)送打開封裝文件的封口的請求。

具體的，當屏幕上顯示封裝文件的封口后，客戶端根據(jù)用戶的特定操作觸發(fā)打開封裝文件的封口的指令，根據(jù)該指令向服務器發(fā)送打開封裝文件的封口的請求。

例如：用戶點擊資源文件的封裝文件任意位置或特定位置(如封口位置)后則觸發(fā)打開封裝文件的封口的指令，或者用戶點擊資源文件的封裝文件上的圖案、文字、鏈接或/和多媒體后則觸發(fā)打開封裝文件的封口的指令，或者輸入指定的信息后則觸發(fā)打開封裝文件的封口的指令。或者將前述三種操作中的任意兩種或三種結合起來才觸發(fā)打開封裝文件的封口的指令。輸入指定的信息，包括輸入文字信息(如輸入數(shù)字密碼或廣告文字)，或者輸入語音信息(如用戶說出特定的廣告語)。

s45、服務器接收打開封裝文件的封口的請求，判斷是否滿足打開封口的預設條件。當滿足該預設條件時，執(zhí)行步驟s46；當不滿足該預設條件時，執(zhí)行步驟s47。

具體的，當資源文件的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊后，或/和輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，服務器則判定滿足打開封口的預設條件；否則，判定不滿足打開封口的預設條件。

s46、服務器允許客戶端打開封裝文件的封口獲取資源文件的核心文件。

具體的，當滿足打開封口的預設條件時，服務器則將客戶端與資源文件綁定(或關聯(lián))，并向客戶端反饋獲取成功的信息，終端接收到信息后，則可以打開封裝文件的封口，獲取資源文件的核心文件。

可選地，在某些實施例中，當滿足打開封口的預設條件時，服務器則自動打開封裝文件的封口，以使客戶端成功獲取資源文件的核心文件。

s47、服務器拒絕客戶端的請求。

具體的，當不滿足顯示封口的預設條件時，服務器則拒絕客戶端的請求，不予顯示封裝文件的封口，同時還可以向客戶端反饋獲取失敗(或封口打開失敗)的信息，此時客戶端不能獲取資源文件的核心文件。當滿足顯示封口的預設條件，但不滿足打開封口的預設條件時，服務器則拒絕客戶端的請求，同時還可以向客戶端反饋獲取失敗的信息，此時客戶端也不能獲取資源文件 的核心文件。

本實施例為資源文件設置了封口顯示條件和拆封條件，當滿足封口顯示條件時，才顯示封裝文件的封口，當滿足拆封條件時用戶才能打開封裝文件的封口，進而獲取資源文件的核心文件，從而可以避免外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性。

可選地，本發(fā)明實施例中的資源文件，可以由申請者(如企業(yè))向其綁定的銀行申請，利用銀行的資源文件生成器關聯(lián)申請者的銀行賬號而生成。資源文件本身具有交互功能，用戶收到的資源文件后可以放在終端的資源文件管理器上，通過該資源文件可以與服務器上的資源文件生成器進行數(shù)據(jù)交互。

參見圖6，提出本發(fā)明的數(shù)據(jù)交互方法第五實施例，本發(fā)明實施例以資源文件為電子紅包(即紅包電子文件)，內容物(即核心文件)為銀信證，發(fā)放資源文件的服務器為銀行服務器為例進行詳細說明，所述方法包括以下步驟：

s51、銀行服務器1根據(jù)客戶端1的用戶請求生成電子紅包數(shù)據(jù)包，并將客戶端1用戶的銀行賬號中對應的電子紅包的金額進行凍結，將電子紅包數(shù)據(jù)包發(fā)送給客戶端2。

s52、銀行服務器2接收客戶端2發(fā)送的對電子紅包的提現(xiàn)請求并轉發(fā)給銀行服務器1。

對電子紅包的提現(xiàn)請求，即獲取電子紅包(資源文件)的內容物(核心文件)的請求。本實施例中電子紅包的內容物為銀信證，因此獲取核心文件的請求即對電子紅包的提現(xiàn)請求。

s53、銀行服務器1接收提現(xiàn)請求，根據(jù)提現(xiàn)請求判斷是否滿足預設條件。當滿足預設條件時，執(zhí)行步驟s55；當不滿足預設條件時，執(zhí)行步驟s54。

s54、銀行服務器1拒絕客戶端2的提現(xiàn)請求。

s55、銀行服務器1對客戶端1用戶的銀行賬號中的電子紅包的凍結金額進行解凍，并將客戶端1用戶的銀行賬號中的與電子紅包對應的金額劃撥到客戶端2用戶的銀行賬號中。

需要說明的是，本發(fā)明中的電子紅包與現(xiàn)有技術的電子紅包是不同的。

在本發(fā)明實施例中，如圖7和圖8所示，銀行服務器1接收到客戶端1提交的生成電子紅包的請求后，生成a金額的電子紅包，并凍結客戶端1用 戶的銀行賬號中的a金額?？蛻舳?或銀行服務器1向網(wǎng)域內發(fā)送生成的電子紅包或該生成的電子紅包的地址信息?？蛻舳?用戶查閱到電子紅包后，在客戶端2上進行搶電子紅包、收電子紅包、拆電子紅包、領電子紅包等操作，其中，確認領電子紅包時，客戶端2通知銀行服務器2，銀行服務器2進行校驗，確認后向銀行服務器1發(fā)送提現(xiàn)請求，銀行服務器1根據(jù)提現(xiàn)請求判斷是否滿足預設條件，當滿足預設條件時將客戶端1用戶的銀行賬號中凍結的a金額進行解凍，并將a金額從客戶端1用戶的銀行賬號中劃撥到客戶端2用戶的銀行賬號中。

而現(xiàn)有技術中的電子紅包，如圖9和圖10所示，用戶3在客戶端3登錄平臺，向同一平臺的用戶4發(fā)送電子紅包(金額大小為b)，用戶4在客戶端4登錄該平臺收取電子紅包，該平臺的服務器執(zhí)行用戶3的平臺賬號(用戶3在平臺的電子賬戶，預先與用戶3的銀行賬號關聯(lián))與用戶4的平臺賬號(用戶4在平臺的電子賬戶，預先與用戶4的銀行賬號關聯(lián))之間的電子金額數(shù)據(jù)結算，即平臺后臺服務器接收到客戶端3的用戶3的發(fā)紅包請求后，生成對應電子紅包并發(fā)送給客戶端4的用戶4，并對應將客戶端3的平臺賬號的余額數(shù)字減去b，將客戶端4的平臺賬號的余額數(shù)字加上b。電子賬戶僅限于同一平臺內數(shù)據(jù)有效，脫離平臺則無法進行信息交互，實際上銀行服務器3根據(jù)用戶3的請求將用戶3的銀行賬號中的金額轉入平臺的銀行賬號(對應銀行服務器5)中，通過客戶端3的平臺賬號中的金額發(fā)電子紅包，但在用戶4將電子紅包兌現(xiàn)前，電子錢包的金額仍舊在平臺的銀行賬戶中。且若用戶4需將搶到的電子紅包兌現(xiàn)，則需關閉當前電子紅包頁面，到錢包菜單欄中查找到平臺賬號4，點擊提現(xiàn)按鈕，將金額提現(xiàn)到關聯(lián)的銀行賬號(對應銀行服務器4)中。

現(xiàn)有技術中的電子紅包的發(fā)、搶、領均基于平臺，脫離平臺則無法實現(xiàn)，且電子紅包金額存入平臺賬號中，電子錢包的發(fā)/收僅是平臺系統(tǒng)內的金額數(shù)據(jù)的轉移和標記，用戶的實際金額存入平臺賬戶中，帶來資金數(shù)據(jù)的安全問題，存在第三方平臺資金風險，且現(xiàn)有技術中的提現(xiàn)操作步驟繁瑣。此外，現(xiàn)有技術中，客戶端收到電子紅包后點擊電子紅包即可領取，無需任何其它操作，當客戶端裝上外掛軟件后就可以自動獲取電子紅包，導致目標數(shù)據(jù)大量流失而不能傳送到目標接收者的手中。

本發(fā)明實施例中的電子紅包的實現(xiàn)無需基于第三方平臺實現(xiàn)，用戶發(fā)出 電子紅包后，對應金額仍舊在發(fā)紅包者的銀行賬戶中凍結，直到其他用戶確認收到電子紅包后，將對應電子紅包金額從發(fā)紅包者的銀行賬戶中解除凍結并轉賬到收紅包者的銀行賬戶中。本發(fā)明實施例不存在資金在第三方平臺上的安全問題，本發(fā)明實施例中，電子錢包的實際金額在銀行賬戶中直接流轉，相比于現(xiàn)有技術中需在平臺賬戶中流轉以及繁瑣的提現(xiàn)步驟，本發(fā)明實施例中的提現(xiàn)步驟簡便，安全性高。而且，客戶端對電子紅包進行提現(xiàn)時，銀行服務器根據(jù)提現(xiàn)請求判斷是否滿足預設條件，當滿足預設條件時才允許客戶端提現(xiàn)，從而保證了數(shù)據(jù)交互的準確性和有效性。

本發(fā)明實施例中的電子紅包實現(xiàn)了跨平臺傳輸，現(xiàn)有技術中的電子紅包數(shù)據(jù)僅能在即時通訊、電商平臺等同一平臺內部進行傳輸和處理，本發(fā)明實施例中的電子紅包的發(fā)放和領取不限于同一平臺，支持不同平臺間進行數(shù)據(jù)的傳輸、交互和處理。并且本發(fā)明實施例的電子紅包可以保證數(shù)據(jù)交互的準確性和有效性。

為了更好的說明本發(fā)明實施例的技術優(yōu)勢，結合附圖11，電子紅包的發(fā)送端發(fā)布電子紅包，接收端1、接收端2……接收端n收到電子紅包，在對電子紅包進行領取時，無需與發(fā)送端發(fā)布電子紅包的同一平臺進行領取。而現(xiàn)有技術中發(fā)紅包與領紅包均需在同一平臺系統(tǒng)上進行，本發(fā)明實施例中接收端1、接收端2……接收端n中的領取紅包可以為不同的平臺系統(tǒng)，例如各銀行的移動客戶端。本發(fā)明實施例中接收端1、接收端2……接收端n還可以將電子紅包領取請求直接發(fā)至接收用戶的銀行賬號的銀行服務器，無需基于任何平臺系統(tǒng)。因此，通過本發(fā)明實施例實現(xiàn)了電子紅包跨平臺傳輸和領取。如此，擴大了電子紅包的傳播范圍和次數(shù)。

參見圖12，提出本發(fā)明的數(shù)據(jù)交互系統(tǒng)一實施例，所述系統(tǒng)包括客戶端10和服務器20。其中，客戶端10用于向服務器20發(fā)送獲取資源文件的核心文件的請求，當滿足預設條件時，獲取資源文件的核心文件。服務器20用于接收客戶端10發(fā)送的獲取資源文件的核心文件的請求，根據(jù)該請求判斷是否滿足預設條件，當滿足預設條件時，允許客戶端10獲取資源文件的核心文件，否則，拒絕客戶端10的請求。資源文件包括封裝文件和設于所述封裝文件內的核心文件，封裝文件上設有封口。

可選地，獲取資源文件的核心文件的請求包括打開封裝文件的封口的請求?？蛻舳?0用于向服務器20發(fā)送打開封裝文件的封口的請求；服務器20 用于根據(jù)打開封裝文件的封口的請求判斷是否滿足打開封口的預設條件，當滿足打開封口的預設條件時，允許客戶端10打開封裝文件的封口獲取資源文件的核心文件。

可選地，獲取資源文件的核心文件的請求包括顯示封裝文件的封口的請求。客戶端10用于向服務器20發(fā)送顯示封裝文件的封口的請求；服務器20用于根據(jù)顯示封裝文件的封口的請求判斷是否滿足顯示封口的預設條件，當滿足顯示封口的預設條件時，在封裝文件上顯示封口，并允許客戶端10打開封裝文件的封口獲取資源文件的核心文件。

可選地，獲取資源文件的核心文件的請求包括顯示封裝文件的封口的請求和打開封裝文件的封口的請求，客戶端10用于先向服務器20發(fā)送顯示封裝文件的封口的請求，當顯示封裝文件的封口后，再向服務器20發(fā)送打開封裝文件的封口的請求。服務器20用于根據(jù)顯示封裝文件的封口的請求判斷是否滿足顯示封口的預設條件，當滿足顯示封口的預設條件時，在封裝文件上顯示封口，否則不予顯示封口；根據(jù)打開封裝文件的封口的請求判斷是否滿足打開封口的預設條件，當滿足打開封口的預設條件時，允許客戶端10打開封裝文件的封口獲取資源文件的核心文件。

本實施例中，服務器根據(jù)收到的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊的信息，收到的客戶端輸入的信息，或/和獲取的客戶端的身份信息，判斷是否滿足預設條件。也就是說，當資源文件的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊后，或/和輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，服務器20則判定滿足預設條件。

本實施例的數(shù)據(jù)交換系統(tǒng)，通過服務器在資源文件上設置獲取條件，使得用戶必須在客戶端上進行操作才能獲取資源文件的核心文件，從而可以避免外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性獲取。

應當理解，上述實施例提供的數(shù)據(jù)交換系統(tǒng)與數(shù)據(jù)交互方法實施例屬于同一構思，其具體實現(xiàn)過程詳見方法實施例，且方法實施例中的技術特征在系統(tǒng)實施例中均對應適用，這里不再贅述。

參見圖13，提出本發(fā)明的數(shù)據(jù)交換裝置一實施例，所述裝置應用于前述服務器，所述裝置包括接收模塊21、判斷模塊22和處理模塊23，其中：

接收模塊21：用于接收客戶端發(fā)送的獲取資源文件的核心文件的請求。資源文件包括封裝文件和設于封裝文件內的核心文件，封裝文件上設有封口。

判斷模塊22：用于根據(jù)獲取資源文件的核心文件的請求判斷是否滿足預設條件，所述預設條件為服務器在生成資源文件時所設置。

處理模塊23：用于當滿足預設條件時，允許客戶端獲取資源文件的核心文件；否則，拒絕客戶端的請求。

可選地，獲取資源文件的核心文件的請求包括打開封裝文件的封口的請求。判斷模塊22用于根據(jù)打開封裝文件的封口的請求判斷是否滿足打開封口的預設條件；處理模塊23用于當滿足打開封口的預設條件時，允許客戶端打開封裝文件的封口獲取資源文件的核心文件。

可選地，獲取資源文件的核心文件的請求包括顯示封裝文件的封口的請求，判斷模塊22用于根據(jù)打開封裝文件的封口的請求判斷是否滿足顯示封口的預設條件；處理模塊23用于當滿足顯示封口的預設條件時，顯示封裝文件的封口，并允許客戶端打開封口獲取資源文件的核心文件。

可選地，獲取資源文件的核心文件的請求包括顯示封裝文件的封口的請求和打開封裝文件的封口的請求，判斷模塊22如圖14所示，包括第一判斷單元221和第二判斷單元222，其中：

第一判斷單元221，用于根據(jù)顯示封裝文件的封口的請求，判斷是否滿足顯示封口的預設條件；

第二判斷單元222，用于根據(jù)打開封裝文件的封口的請求，判斷是否滿足打開封口的預設條件。

此時，處理模塊23用于：當滿足顯示封口的預設條件時，在封裝文件上顯示封口，否則不予顯示封口；當滿足打開封口的預設條件時，允許客戶端打開封裝文件的封口獲取資源文件的核心文件。

本實施例中，判斷模塊用于：根據(jù)收到的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊的信息，或/和收到的客戶端輸入的信息，或/和獲取的客戶端的身份信息，判斷是否滿足預設條件。也就是說，當資源文件的封裝文件上的鏈接、文字、圖案或/和多媒體被點擊后，或/和輸入了指定的信息后，或/和客戶端的身份信息滿足條件時，判斷模塊22則判定滿足預設條件。

本發(fā)明實施例的數(shù)據(jù)交換裝置，通過在資源文件上設置獲取條件，使得用戶必須在客戶端上進行操作才能獲取資源文件的核心文件，從而可以避免 外掛軟件自動獲取資源文件，并且資源文件發(fā)送者可以據(jù)此定向發(fā)送資源文件，達到將資源文件發(fā)送給目標接收者的目的，提高了數(shù)據(jù)交互的準確性和有效性獲取。

應當理解，上述實施例提供的數(shù)據(jù)交換裝置與數(shù)據(jù)交互方法實施例屬于同一構思，其具體實現(xiàn)過程詳見方法實施例，且方法實施例中的技術特征在裝置實施例中均對應適用，這里不再贅述。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到上述實施例方法可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產品的形式體現(xiàn)出來，該計算機軟件產品存儲在一個存儲介質(如rom/ram、磁碟、光盤)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述的方法。

以上參照附圖說明了本發(fā)明的優(yōu)選實施例，并非因此局限本發(fā)明的權利范圍。本領域技術人員不脫離本發(fā)明的范圍和實質，可以有多種變型方案實現(xiàn)本發(fā)明，比如作為一個實施例的特征可用于另一實施例而得到又一實施例。凡在運用本發(fā)明的技術構思之內所作的任何修改、等同替換和改進，均應在本發(fā)明的權利范圍之內。