本發(fā)明屬于計算機及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，尤其涉及一種數(shù)據(jù)處理方法及裝置、數(shù)據(jù)交互方法及系統(tǒng)。

背景技術(shù)：

伴隨著計算機及互聯(lián)網(wǎng)技術(shù)的高速發(fā)展，人們的生活越來越向數(shù)字化方向發(fā)展，人們相互之間經(jīng)常利用手機等終端，通過服務器進行各種類型的資源包數(shù)據(jù)的交互，以促進感情交流，例如：電子紅包數(shù)據(jù)的交互。然而現(xiàn)有的數(shù)據(jù)處理和交互技術(shù)中，服務器在處理發(fā)送端和接收端之間傳輸?shù)馁Y源包時，無法獲取發(fā)送端和接收端對資源包中的資源信息的反饋信息，對于資源包有關(guān)的信息的處理效率較低。

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

本發(fā)明提供一種數(shù)據(jù)處理方法及裝置、數(shù)據(jù)交互方法及系統(tǒng)，可提高服務器對資源包相關(guān)反饋信息的處理效率，有利于資源包發(fā)送者對傳輸?shù)男畔⒒蛘邤?shù)據(jù)的掌握。

本發(fā)明提供一種數(shù)據(jù)處理方法，所述方法包括：服務器接收發(fā)放端發(fā)送的電子紅包開立指令，所述開立指令中包含有為電子紅包開立的金額信息；當獲取到銀行端發(fā)放的電子承諾支付憑證的信息時，生成電子紅包的配置文件，并將所述電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及所述電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及所述原本的副本；將所述電子紅包的副本發(fā)送給電子紅包的接收端，使得所述接收端根據(jù) 接收的所述電子紅包的副本，顯示電子紅包的界面，并在所述界面上顯示所述通信交互窗口，以及向所述銀行端發(fā)送所述解付申請指令。

優(yōu)選地，所述將所述電子紅包的副本發(fā)送給電子紅包的接收端之后包括：接收所述接收端通過所述通信交互窗口發(fā)送的反饋信息，將所述反饋信息寫入所述電子紅包的原本中，并將所述反饋信息發(fā)送給所述發(fā)放端；接收所述發(fā)放端根據(jù)所述反饋信息發(fā)送的回饋信息，將所述回饋信息寫入所述電子紅包的原本中，并向所述接收端發(fā)送更新指令，使得所述接收端根據(jù)所述電子紅包的原本更新所述副本，以將所述回饋信息顯示在所述通信交互窗口中。

優(yōu)選地，所述方法還包括：獲取所述電子紅包的流通數(shù)據(jù)，并將所述流通數(shù)據(jù)寫入所述電子紅包的原本中，所述流通數(shù)據(jù)包括所述電子紅包每一次被轉(zhuǎn)送的發(fā)送方和接收方的信息數(shù)據(jù)。

優(yōu)選地，所述接收發(fā)放端發(fā)送的電子紅包開立指令之前包括：接收所述發(fā)放端發(fā)送的申請開立電子紅包的請求，所述請求中包含有所述電子紅包的發(fā)放方的賬戶信息；判斷所述發(fā)放方的賬戶是否具有開立所述電子紅包的權(quán)限；若有，則向所述發(fā)放端發(fā)送授權(quán)所述發(fā)放方的賬戶開立所述電子紅包的反饋信息。

本發(fā)明提供一種數(shù)據(jù)交互方法，所述方法包括：發(fā)放端根據(jù)電子紅包發(fā)放方觸發(fā)的開立指令，生成電子紅包開立指令，并將所述電子紅包開立指令發(fā)送給服務器，所述電子紅包開立指令中包含有為電子紅包開立的金額信息；所述服務器將所述電子紅包開立指令轉(zhuǎn)發(fā)給銀行端；所述銀行端根據(jù)所述金額信息，凍結(jié)電子紅包發(fā)放方的賬戶內(nèi)所述金額信息對應的虛擬資源，并生成電子承諾支付憑證及解付申請指令，將所述電子承諾支付憑證的信息及所述解付申請指令發(fā)送給所述服務器；所述服務器生成電子紅包的配置文件，并將所述電子承諾支付憑證的信息、所述解付申請指令、通信交互窗口以及所述電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及所述原本的副本，將所述電子紅包的副本發(fā)送給電子紅包的接收端；所述接收端根據(jù)接收的所述電 子紅包的副本，顯示電子紅包的界面，并在所述界面上顯示所述通信交互窗口，以及向所述銀行端發(fā)送所述解付申請指令；所述銀行端根據(jù)所述解付申請指令，將所述電子承諾支付憑證中記載的虛擬資源從所述電子紅包發(fā)放方的賬戶轉(zhuǎn)移給接收方的賬戶，并將處理結(jié)果發(fā)送給所述發(fā)放端。

本發(fā)明提供一種數(shù)據(jù)處理裝置，所述裝置包括：接收模塊，用于接收發(fā)放端發(fā)送的電子紅包開立指令，所述開立指令中包含有為電子紅包開立的金額信息；生成模塊，用于當獲取到銀行端發(fā)放的電子承諾支付憑證的信息時，生成電子紅包的配置文件，并將所述電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及所述電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及所述原本的副本；發(fā)送模塊，用于將所述電子紅包的副本發(fā)送給電子紅包的接收端，使得所述接收端根據(jù)接收的所述電子紅包的副本，顯示電子紅包的界面，并在所述界面上顯示所述通信交互窗口，以及向所述銀行端發(fā)送所述解付申請指令。

優(yōu)選地，所述裝置還包括：通信模塊，用于接收所述接收端通過所述通信交互窗口發(fā)送的反饋信息；數(shù)據(jù)更新模塊，用于將所述反饋信息寫入所述電子紅包的原本中；所述發(fā)送模塊，還用于將所述反饋信息發(fā)送給所述發(fā)放端；所述通信模塊，還用于接收所述發(fā)放端根據(jù)所述反饋信息發(fā)送的回饋信息；所述數(shù)據(jù)更新模塊，還用于將所述回饋信息寫入所述電子紅包的原本中；所述發(fā)送模塊，還用于向所述接收端發(fā)送更新指令，使得所述接收端根據(jù)所述電子紅包的原本更新所述副本，以將所述回饋信息顯示在所述通信交互窗口中。

優(yōu)選地，所述接收模塊，還用于獲取所述電子紅包的流通數(shù)據(jù)；所述數(shù)據(jù)更新模塊，還用于將所述流通數(shù)據(jù)寫入所述電子紅包的原本中，所述流通數(shù)據(jù)包括所述電子紅包每一次被轉(zhuǎn)送的發(fā)送方和接收方的信息數(shù)據(jù)。

優(yōu)選地，所述接收模塊，還用于接收所述發(fā)放端發(fā)送的申請開立電子紅包的請求，所述請求中包含有所述電子紅包的發(fā)放方的賬戶信息；所述裝置還包 括：判斷模塊，用于判斷所述發(fā)放方的賬戶是否具有開立所述電子紅包的權(quán)限；所述發(fā)送模塊，還用于若所述發(fā)放方的賬戶具有開立所述電子紅包的權(quán)限，則向所述發(fā)放端發(fā)送授權(quán)所述發(fā)放方的賬戶開立所述電子紅包的反饋信息。

本發(fā)明提供一種數(shù)據(jù)交互系統(tǒng)，其特征在于，所述系統(tǒng)包括：發(fā)放端、服務器、接收端、銀行端；其中，所述發(fā)放端，用于根據(jù)電子紅包發(fā)放方觸發(fā)的開立指令，生成電子紅包開立指令，并將所述電子紅包開立指令發(fā)送給所述服務器，所述電子紅包開立指令中包含有為電子紅包開立的金額信息；所述服務器，用于將所述電子紅包開立指令轉(zhuǎn)發(fā)給所述銀行端；所述銀行端，用于根據(jù)所述金額信息，凍結(jié)電子紅包發(fā)放方的賬戶內(nèi)所述金額信息對應的虛擬資源，生成電子承諾支付憑證及解付申請指令，并將所述電子承諾支付憑證的信息及解付申請指令發(fā)送給所述服務器；所述服務器，還用于生成電子紅包的配置文件，并將所述電子承諾支付憑證的信息、所述解付申請指令、通信交互窗口以及所述電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及所述原本的副本，將所述電子紅包的副本發(fā)送給電子紅包的接收端；所述接收端，用于根據(jù)接收的所述電子紅包的副本，顯示電子紅包的界面，并在所述界面上顯示所述通信交互窗口，以及向所述銀行端發(fā)送解付申請指令；所述銀行端，還用于根據(jù)所述解付申請指令，將所述電子承諾支付憑證中記載的虛擬資源從所述電子紅包發(fā)放方的賬戶轉(zhuǎn)移給接收方的賬戶，并將處理結(jié)果發(fā)送給所述發(fā)放端。

從上述本發(fā)明實施例可知，本發(fā)明通過將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件，按照預置的規(guī)則封裝為電子紅包，使得接收方在收到電子紅包后，還可以利用通信交互窗口與紅包發(fā)放方進行信息交流，相較于現(xiàn)有技術(shù)，本發(fā)明通過將電子紅包與通信交互相結(jié)合，服務器在處理發(fā)送端和接收端之間傳輸?shù)碾娮蛹t包資源包的過程中，還可獲取發(fā)送端和接收端對電子紅包的反饋信息，從而可提高服務器對資源包相關(guān)反饋 信息的處理效率，有利于資源包發(fā)送者對傳輸?shù)男畔⒒蛘邤?shù)據(jù)的掌握。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本發(fā)明第一實施例提供的數(shù)據(jù)處理方法的實現(xiàn)流程示意圖；

圖2是本發(fā)明第二實施例提供的數(shù)據(jù)交互方法的實現(xiàn)流程示意圖；

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

圖4是本發(fā)明第三實施例提供的數(shù)據(jù)交互方法中用戶端與銀行端的交互流程圖；

圖5是本發(fā)明第三實施例提供的數(shù)據(jù)交互方法的網(wǎng)絡結(jié)構(gòu)圖；

圖6是現(xiàn)有技術(shù)提供的數(shù)據(jù)交互方法中用戶端與銀行端的交互流程圖；

圖7是現(xiàn)有技術(shù)提供的數(shù)據(jù)交互方法的網(wǎng)絡結(jié)構(gòu)圖；

圖8是本發(fā)明第三實施例提供的數(shù)據(jù)交互方法的結(jié)構(gòu)示意圖；

圖9是本發(fā)明第四實施例提供的數(shù)據(jù)處理裝置的結(jié)構(gòu)示意圖；

圖10是本發(fā)明第五實施例提供的數(shù)據(jù)處理裝置的結(jié)構(gòu)示意圖；

圖11是本發(fā)明第六實施例提供的數(shù)據(jù)交互系統(tǒng)的結(jié)構(gòu)示意圖。

具體實施方式

為使得本發(fā)明的發(fā)明目的、特征、優(yōu)點能夠更加的明顯和易懂，下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而非全部實施例?；诒景l(fā)明中的實施例，本領(lǐng)域技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的 所有其他實施例，都屬于本發(fā)明保護的范圍。

以下各實施例提供的數(shù)據(jù)處理方法及數(shù)據(jù)交互方法，均以電子紅包為例，可應用于服務器中，服務器可以是獨立于銀行端和發(fā)放端的第三方服務器，或者是第三方服務器中的一個數(shù)據(jù)處理模塊，或者也可以作為一個數(shù)據(jù)處理模塊配置在發(fā)放端所屬企業(yè)的服務器中，或者也可以作為一個數(shù)據(jù)模塊直接配置在發(fā)放端中。電子紅包的發(fā)放端和接收端可以但不限于包括：智能手機、平板電腦、臺式機等各種計算機設備，其中配置有各自的客戶端，也即是通過該客戶端進入數(shù)據(jù)處理系統(tǒng)中實現(xiàn)電子紅包發(fā)放、流轉(zhuǎn)和收取。同時，流轉(zhuǎn)信息都被數(shù)據(jù)處理模塊相應的記錄在每個獨立的電子紅包內(nèi)，形成一個獨立的智能文件，可在互聯(lián)網(wǎng)上自由流通。

請參閱圖1，圖1為本發(fā)明第一實施例提供的數(shù)據(jù)處理方法的實現(xiàn)流程示意圖。如圖1所示，該方法主要包括以下步驟：

s101、服務器接收發(fā)放端發(fā)送的電子紅包開立指令，開立指令中包含有為電子紅包開立的金額信息；

進一步地，電子紅包的發(fā)放方用戶(以下簡稱發(fā)放方)在使用發(fā)送電子紅包的業(yè)務之前，需要通過發(fā)放端向服務器發(fā)送申請開立電子紅包的請求，服務器接收該申請開立電子紅包的請求，并判斷該發(fā)放方的賬戶是否具有開立電子紅包的權(quán)限，該請求中包括發(fā)放方的賬戶信息。判斷的標準可以預先設置，可以根據(jù)發(fā)放方的賬戶的資質(zhì)進行設置，例如，發(fā)放方的賬戶若為具備一定規(guī)模的大企業(yè)，若有良好的信用評價，若具備一定儲備金的客戶，都可以認為是具有開立電子紅包的權(quán)限。若判斷結(jié)果是該發(fā)放方的賬戶有此權(quán)限，則向發(fā)放端發(fā)送授權(quán)該發(fā)放方的賬戶開立電子紅包的反饋信息。

發(fā)放端接收到允許開立電子紅包的反饋信息后，設置電子紅包的開立金額，并通過向服務器發(fā)送電子紅包開立指令，將該開立金額信息發(fā)送給服務器，指示該服務器為電子紅包開立對應的金額信息，以及，將該開立金額信息和電子 紅包的接收方用戶(以下簡稱接收方)的賬戶信息發(fā)送給銀行端，指示該銀行端開立紅包金額，使的該銀行端根據(jù)發(fā)放方的賬戶信息、接收方的賬戶信息以及紅包金額，生成電子承諾支付憑證。具體地，該電子承諾支付憑證為銀信證。

銀信證是指銀行根據(jù)開證人的申請凍結(jié)所需數(shù)額資金而開立，并承諾依照約定解付條件辦理支付結(jié)算的電子憑證。在銀行版電子紅包場景中，開證人即為向銀行申請發(fā)放電子紅包的企業(yè)。當領(lǐng)取了電子紅包后，用戶在銀信證的收證人處輸入自己的銀行賬號信息，向銀行申請收證，銀行即在約定的時間內(nèi)將資金轉(zhuǎn)入收證賬戶。銀信證的業(yè)務流程如下：(1)開證人通過互聯(lián)網(wǎng)或以其他方式向開證銀行申請開證。(2)開證銀行驗證身份、賬戶信息無誤后受理，審核確認符合開證條件，凍結(jié)保付資金后開立銀信證。(3)收證人通過互聯(lián)網(wǎng)或以其他方式向收證銀行申請收證。(4)收證銀行驗證身份、賬戶信息無誤后受理收證(或根據(jù)收證人設置由收證銀行自動收證)。(5)收證人履行銀信證項下基礎(chǔ)交易義務后，提交履約信息(一般用于電商領(lǐng)域，收證人為商家，履行發(fā)貨義務后，提交發(fā)貨信息，在電子紅包領(lǐng)域中，由于是開證人無償轉(zhuǎn)移給收證人，因此就不需要履行交易義務)。(6)收證人或指定的第三方將申請解付信息發(fā)送至開證銀行申請解付(在電子紅包領(lǐng)域中，收證人填寫收證后即自動申請解付)。(7)開證銀行解付銀信證并將資金劃轉(zhuǎn)至收證銀行，收證銀行將資金轉(zhuǎn)入收證賬戶。

可以理解地，發(fā)放端也可不指定接收方，而是由銀行端根據(jù)發(fā)放端指定的接收方的數(shù)量，在發(fā)放端關(guān)聯(lián)的用戶賬號中隨機確定接收方。

需要說明的是，服務器向銀行端發(fā)送該發(fā)放端的上述需求信息，是讓銀行端獲知發(fā)放端要開立一定金額的紅包。具體地，該上述需求信息可以是由服務器代為傳遞給銀行端，此時，所傳遞的信息是經(jīng)過發(fā)放端用戶的電子簽名的，用以證明該需求信息是經(jīng)過發(fā)放端用戶的授權(quán)。該上述需求信息也可以是發(fā)放端直接與其開戶銀行端通訊連接，將其預備開立紅包的金額通知到銀行端。

s102、當獲取到銀行端發(fā)放的電子承諾支付憑證的信息時，生成電子紅包的配置文件，并將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及原本的副本；

該電子承諾支付憑證中記載的支付額度為電子紅包開立的金額。

進一步地，銀行端接收發(fā)放端發(fā)送的電子紅包的開立金額信息，以及電子紅包的接收方的賬戶信息，銀行端判斷該發(fā)放方的賬戶中虛擬資源的余額是否大于該電子紅包的開立金額，該賬戶的余額可以是以下三種中的一種或幾種：儲蓄金額，信用額度，以及貸款額度。若大于，則凍結(jié)該發(fā)放方賬戶余額中與該開立金額相等的資金，并對應生成電子承諾支付憑證，將生成的電子承諾支付憑證的信息發(fā)送給服務器，該電子承諾支付憑證中包含有電子紅包的接收方信息，發(fā)放方信息，支付金額等信息。若不大于，則拒絕生成該電子承諾支付證，并向發(fā)放端和服務器返回通知信息，以通知發(fā)放端和服務器金額不足，無法發(fā)放電子承諾支付憑證。其中虛擬資源可以是禮金或禮券，接收方可根據(jù)禮金或禮券兌換現(xiàn)金或?qū)嵨铩?/p>

服務器在獲取到銀行端發(fā)放的電子承諾支付憑證的信息時，根據(jù)該電子支付憑證中包含的電子紅包發(fā)放方的賬戶信息和接收方的賬戶信息，生成基于該電子承諾支付憑證的解付申請指令，該解付申請指令用于請求該銀行端按照該電子紅包的金額，將該電子承諾支付憑證中記載的虛擬資源從該電子紅包發(fā)放方轉(zhuǎn)移給該接收方。可以理解地，該解付申請指令也可由銀行端生成。

s103、將電子紅包的副本發(fā)送給電子紅包的接收端，使得接收端根據(jù)接收的電子紅包的副本，顯示電子紅包的界面，并在界面上顯示通信交互窗口，以及向銀行端發(fā)送解付申請指令。

服務器生成電子紅包的配置文件，電子紅包的界面可以認為是該電子紅包的封套，通過配置文件，將電子紅包的界面配置為包含有一個通信交互窗口以 及電子承諾支付憑證的信息顯示區(qū)域。該電子紅包上的通信交互窗口可以是隨電子紅包一同封裝，也可以僅是將電子承諾支付憑證的信息封裝于電子紅包之后，再增設一個通信交互窗口。該通信交互窗口用于電子紅包持有方與電子紅包發(fā)放方進行語言交流。

需要說明的是，可以在同一個階段生成解付申請指令、生成通信交互窗口以及生成電子紅包的配置文件，也可以在不同的階段分別生成上述數(shù)據(jù)。例如，可在接收到電子承諾支付憑證的信息前，先生成通信交互窗口，并生成對應配置文件，以配置通信交互窗口與電子紅包的界面的位置關(guān)系，待接收到電子承諾支付憑證的信息時，再生成解付申請指令，執(zhí)行后續(xù)的封裝操作。

服務器將電子承諾支付憑證的信息、通信交互窗口以及電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及原本的副本。其中，電子紅包的原本被存儲在服務器中，電子紅包的副本被發(fā)送給電子紅包的接收端。副本相當于原本的鏡像或映射，接收端根據(jù)原本的變化更新接收的副本。服務器可以直接將副本發(fā)送給接收端，或者將原本的下載鏈接發(fā)送給接收端，接收端根據(jù)下載鏈接，將原本復制到本地后，本地保存的復制本即為副本。

接收端接收服務器發(fā)送的電子紅包的副本，在檢測到運行電子紅包的副本的命令被觸發(fā)時，即，當接收端用戶點擊顯示屏上的電子紅包的圖標時，運行電子紅包，顯示電子紅包的界面，并在界面上顯示通信交互窗口，并通過通信交互窗口與電子紅包發(fā)放方進行通信。在顯示電子紅包的界面的同時，自動觸發(fā)發(fā)送解付申請指令的操作，向銀行端發(fā)送解付申請指令，該解付申請指令用于請求銀行端按照電子紅包的金額，將電子承諾支付憑證中記載的虛擬資源從電子紅包發(fā)放方的賬戶轉(zhuǎn)移給接收方的賬戶。銀行端根據(jù)該解付申請指令的指示，將該電子承諾支付憑證中虛擬資源轉(zhuǎn)移給電子紅包的接收方，例如，解凍之前凍結(jié)的資金，將其劃撥到該用戶提供的收款賬戶內(nèi)，并將處理信息反饋給電子紅包的發(fā)放端?；蛘撸y行端將處理信息反饋給服務器，服務器將該處理 信息轉(zhuǎn)發(fā)給發(fā)放端。

進一步地，服務器接收接收端通過通信交互窗口發(fā)送的反饋信息，將反饋信息寫入電子紅包的原本中，并將反饋信息發(fā)送給發(fā)放端。例如：接收方用戶可以在通信交互窗口中輸入“謝謝！”等文字或表情圖片，接收端將用戶輸入的“謝謝！”發(fā)送給服務器，服務器將“謝謝！”轉(zhuǎn)發(fā)給發(fā)放端，同時將“謝謝！”寫入電子紅包的原本中，這樣，當接收方再次打開電子紅包時，可在通信交互窗口中查看到曾經(jīng)發(fā)送過的信息。

進一步地，接收發(fā)放端根據(jù)反饋信息發(fā)送的回饋信息，將回饋信息寫入電子紅包的原本中，并向接收端發(fā)送更新指令，使得接收端根據(jù)電子紅包的原本更新副本，以將回饋信息顯示在通信交互窗口中。例如：發(fā)放端在顯示反饋信息的同時，提示發(fā)放方是否需要回復，如果發(fā)放方選擇需要，則顯示信息輸入窗口，獲取發(fā)放方輸入的回饋信息，如“不客氣”，發(fā)放端將“不客氣”發(fā)送給服務器，服務器將“不客氣”寫入電子紅包的原本，同時向接收端發(fā)送更新指令，接收端根據(jù)更新指令，獲取“不客氣”并顯示在通信交互窗口上。由于是將回饋信息寫入原本，這樣，當接收方再次打開電子紅包時，可在通信交互窗口中查看到曾經(jīng)發(fā)送和接收過的交互通信信息。通過通信交互窗口與電子紅包的結(jié)合，為人與人之間的溝通提供了一種新型的溝通方式，同時，可加強電子紅包發(fā)放中參與各方的交流，擴展了電子紅包的應用范圍。

進一步地，服務器獲取電子紅包的流通數(shù)據(jù)，并將所述流通數(shù)據(jù)寫入所述電子紅包的原本，所述流通數(shù)據(jù)包括所述電子紅包每一次被轉(zhuǎn)送的發(fā)送方和接收方的信息數(shù)據(jù)。接收方可以將收到的電子紅包轉(zhuǎn)送給其他人，接收端根據(jù)接收方的轉(zhuǎn)送操作，將電子紅包轉(zhuǎn)發(fā)給其他接收端，并將轉(zhuǎn)發(fā)時產(chǎn)生的流通數(shù)據(jù)發(fā)送給服務器，流通數(shù)據(jù)包括：轉(zhuǎn)發(fā)時間、轉(zhuǎn)發(fā)的發(fā)送方信息、接收方信息等等。服務器將接收端發(fā)送的流通數(shù)據(jù)寫入電子紅包的原本，在原本中形成電子紅包的流通軌跡記錄，如：電子紅包由誰發(fā)出，又由誰接收，后來又轉(zhuǎn)給了誰。 這樣，后一個接收方，可根據(jù)流通軌跡記錄，了解電子紅包的流轉(zhuǎn)過程，從而使得電子紅包承載更多的信息。

本發(fā)明實施例提供的數(shù)據(jù)處理方法，通過將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件，按照預置的規(guī)則封裝為電子紅包，使得接收方在收到電子紅包后，還可以利用通信交互窗口與紅包發(fā)放方進行信息交流，相較于現(xiàn)有技術(shù)，本發(fā)明通過將電子紅包與通信交互相結(jié)合，服務器在處理發(fā)送端和接收端之間傳輸?shù)碾娮蛹t包資源包的過程中，還可獲取發(fā)送端和接收端對電子紅包的反饋信息，從而可提高服務器對資源包相關(guān)反饋信息的處理效率，有利于資源包發(fā)送者對傳輸?shù)男畔⒒蛘邤?shù)據(jù)的掌握。

請參閱圖2，圖2為本發(fā)明第二實施例提供的數(shù)據(jù)交互方法的實現(xiàn)流程示意圖。如圖2所示，該方法主要包括以下步驟：

s201、發(fā)送電子紅包開立指令；

發(fā)放端根據(jù)電子紅包發(fā)放方觸發(fā)的開立指令，設置電子紅包的開立金額，生成電子紅包開立指令，并將電子紅包開立指令發(fā)送給服務器，電子紅包開立指令中包含有為電子紅包開立的金額信息。

進一步地，電子紅包發(fā)放方在使用發(fā)送電子紅包的業(yè)務之前，需要通過發(fā)放端向服務器發(fā)送申請開立電子紅包的請求，服務器接收該申請開立電子紅包的請求，并判斷該發(fā)放方的賬戶是否具有開立電子紅包的權(quán)限，該請求中包括發(fā)放方的賬戶信息。判斷的標準可以預先設置，可以根據(jù)發(fā)放方的賬戶的資質(zhì)進行設置，例如，發(fā)放方的賬戶若為具備一定規(guī)模的大企業(yè)，若有良好的信用評價，若具備一定儲備金的客戶，都可以認為是具有開立電子紅包的權(quán)限。若判斷結(jié)果是該發(fā)放方的賬戶有此權(quán)限，則向發(fā)放端發(fā)送授權(quán)該發(fā)放方的賬戶開立電子紅包的反饋信息。

s202、轉(zhuǎn)發(fā)電子紅包開立指令；

服務器將發(fā)放端發(fā)送的電子紅包開立指令轉(zhuǎn)發(fā)給銀行端。

s203、凍結(jié)虛擬資源，生成電子承諾支付憑證及解付申請指令；

s204、發(fā)送電子承諾支付憑證的信息及解付申請指令；

銀行端接收電子紅包開立指令，判斷發(fā)放方的賬戶中虛擬資源的余額是否大于該電子紅包的開立金額，該賬戶的余額可以是以下三種中的一種或幾種：儲蓄金額，信用額度，以及貸款額度。若大于，則凍結(jié)該發(fā)放方賬戶余額中與該開立金額相等的資金，并對應生成電子承諾支付憑證及解付申請指令，將生成的電子承諾支付憑證的信息及解付申請指令發(fā)送給服務器，該電子承諾支付憑證中包含有電子紅包的接收方信息，發(fā)放方信息，支付金額等信息。若不大于，則拒絕生成該電子承諾支付證，并向發(fā)放端和服務器返回通知信息，以通知發(fā)放端和服務器金額不足，無法發(fā)放電子承諾支付憑證。其中虛擬資源可以是禮金或禮券，接收方可根據(jù)禮金或禮券兌換現(xiàn)金或?qū)嵨铩?/p>

s205、生成電子紅包的原本和副本；

s206、發(fā)送電子紅包的副本；

服務器生成電子紅包的配置文件，并將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及原本的副本，將電子紅包的副本發(fā)送給電子紅包的接收端。

需要說明的是，可以在同一個階段生成解付申請指令、生成通信交互窗口以及生成電子紅包的配置文件，也可以在不同的階段分別生成上述數(shù)據(jù)。例如，可在接收到電子承諾支付憑證的信息前，先生成通信交互窗口，并生成對應配置文件，以配置通信交互窗口與電子紅包的界面的位置關(guān)系，待接收到電子承諾支付憑證的信息時，再生成解付申請指令，執(zhí)行后續(xù)的封裝操作。

s207、根據(jù)接收的電子紅包的副本，顯示電子紅包的界面，以及并在界面上顯示通信交互窗口；

s208、發(fā)送解付申請指令；

接收端接收電子紅包的副本，根據(jù)副本中包含有的各數(shù)據(jù)，生成并顯示電 子紅包的界面，并在界面上顯示通信交互窗口，通過通信交互窗口與電子紅包發(fā)放方進行通信，同時觸發(fā)發(fā)送解付申請指令的操作，向銀行端發(fā)送解付申請指令。

進一步地，接收端通過通信交互窗口與發(fā)放端進行通信的具體過程可包括：

接收端獲取接收方在通信交互窗口輸入的反饋信息，并發(fā)送給服務器；服務器將反饋信息寫入電子紅包的原本中，并將反饋信息發(fā)送給發(fā)放端；發(fā)放端將該反饋信息顯示給發(fā)放方，獲取發(fā)放方輸入的回饋信息，將該回饋信息發(fā)送給服務器；服務器將回饋信息寫入電子紅包的原本中，并向接收端發(fā)送更新指令；接收端根據(jù)電子紅包的原本更新副本，獲取回饋信息并顯示在通信交互窗口中。通過通信交互窗口與電子紅包的結(jié)合，為人與人之間的溝通提供了一種新型的溝通方式，同時，可加強電子紅包發(fā)放中參與各方的交流，擴展了電子紅包的應用范圍。

進一步地，接收端在接收到紅包轉(zhuǎn)送指令時，將電子紅包轉(zhuǎn)發(fā)給接收方指定的其他接收端，并將轉(zhuǎn)發(fā)時產(chǎn)生的流通數(shù)據(jù)發(fā)送給服務器，服務器將該流通數(shù)據(jù)寫入電子紅包的原本，流通數(shù)據(jù)包括電子紅包每一次被轉(zhuǎn)送的發(fā)送方和接收方的信息數(shù)據(jù)。服務器將接收端發(fā)送的流通數(shù)據(jù)寫入電子紅包的原本，在原本中形成電子紅包的流通軌跡記錄，如：電子紅包由誰發(fā)出，又由誰接收，后來又轉(zhuǎn)給了誰。這樣，后一個接收方，可根據(jù)流通軌跡記錄，了解電子紅包的流轉(zhuǎn)過程，從而使得電子紅包承載更多的信息。

s209、根據(jù)解付申請指令，將電子承諾支付憑證中記載的虛擬資源從電子紅包發(fā)放方的賬戶轉(zhuǎn)移給接收方的賬戶；

s210、發(fā)送處理結(jié)果。

銀行端根據(jù)解付申請指令，解凍虛擬資源，將電子承諾支付憑證中記載的虛擬資源從電子紅包發(fā)放方的賬戶轉(zhuǎn)移給接收方的賬戶，并將處理結(jié)果發(fā)送給發(fā)放端。

本發(fā)明實施例提供的數(shù)據(jù)交互方法，通過服務器將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件，按照預置的規(guī)則封裝為電子紅包，使得接收方在收到電子紅包后，還可以利用通信交互窗口與紅包發(fā)放方進行信息交流，相較于現(xiàn)有技術(shù)，本發(fā)明通過將電子紅包與通信交互相結(jié)合，服務器在處理發(fā)送端和接收端之間傳輸?shù)碾娮蛹t包資源包的過程中，還可獲取發(fā)送端和接收端對電子紅包的反饋信息，從而可提高服務器對資源包相關(guān)反饋信息的處理效率，有利于資源包發(fā)送者對傳輸?shù)男畔⒒蛘邤?shù)據(jù)的掌握。

請參閱圖3，圖3是本發(fā)明第三實施例提供的數(shù)據(jù)交互方法的流程圖，在本實施例中，電子紅包服務器作為一個模塊配置于銀行端1服務器中。如圖3所示，該方法包括以下步驟：

s301、銀行端1服務器根據(jù)發(fā)送端的用戶請求生成電子紅包數(shù)據(jù)包，并將發(fā)送端用戶的銀行賬號中對應的電子紅包的金額進行凍結(jié)，將電子紅包數(shù)據(jù)包的副本發(fā)送給接收端，該電子紅包數(shù)據(jù)包中包含通信交互窗口。

s302、接收端根據(jù)接收的電子紅包數(shù)據(jù)包的副本，向銀行端2服務器發(fā)送對電子紅包的提現(xiàn)請求。

s303、銀行端2服務器接收終端發(fā)送的對電子紅包的提現(xiàn)請求，根據(jù)提現(xiàn)請求通知銀行端1服務器對發(fā)送端用戶的銀行賬號中的電子紅包的凍結(jié)金額進行解凍，并將發(fā)送端用戶的銀行賬號中的與電子紅包對應的金額劃撥到接收端用戶的銀行賬號中。

s304、接收端通過接收的電子紅包數(shù)據(jù)包的副本中的通信交互窗口，獲取接收方在通信交互窗口輸入的反饋信息，并發(fā)送給銀行端1服務器。

s305、銀行端1服務器將反饋信息寫入電子紅包數(shù)據(jù)包中，并將反饋信息發(fā)送給發(fā)送端。

s306、發(fā)送端將該反饋信息顯示給發(fā)放方，獲取發(fā)放方輸入的回饋信息，將該回饋信息發(fā)送給銀行端1服務器。

s307、銀行端1服務器將回饋信息寫入電子紅包數(shù)據(jù)包中，并向接收端發(fā)送更新指令。

s308、接收端根據(jù)該更新指令更新電子紅包數(shù)據(jù)包的副本，獲取回饋信息并顯示在通信交互窗口中。

現(xiàn)有的互聯(lián)網(wǎng)電子紅包，例如微信平臺的電子紅包、支付寶平臺的電子紅包，均不支持通信交互功能，即現(xiàn)有的互聯(lián)網(wǎng)電子紅包都只是單方面的數(shù)據(jù)傳輸，無法實現(xiàn)多方信息交互，從而限制了電子紅包的應用范圍，降低了電子紅包的相關(guān)反饋信息的處理效率。

本發(fā)明實施例中，如圖4、5所示，用戶1的終端為發(fā)送端，用戶2的終端2為接收端。用戶1的銀行賬號1對應銀行服務器1，用戶2的銀行賬號2對應銀行服務器2。用戶1可以為企業(yè)或者個人。

銀行服務器1接收到用戶1提交的生成電子紅包的請求后，生成a金額的電子紅包，并凍結(jié)銀行賬號1中的a金額。用戶1的發(fā)送端向網(wǎng)域內(nèi)發(fā)送生成的電子紅包或該生成的電子紅包的地址信息。用戶2查閱到電子紅包，進行搶紅包、收紅包、拆紅包、領(lǐng)紅包以及利用通信交互窗口將反饋信息發(fā)送給銀行服務器1等操作，其中，確認領(lǐng)電子紅包時，用戶2通知銀行賬號2的銀行服務器2，銀行服務器2校驗，確認后向銀行服務器1發(fā)送解凍請求，銀行服務器1將銀行賬號1中的凍結(jié)的a金額進行解凍，并將a金額從銀行賬號1中劃撥到銀行賬號2中。

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

現(xiàn)有技術(shù)中的電子紅包的發(fā)、搶、領(lǐng)均基于平臺，脫離平臺則無法實現(xiàn)，且電子紅包金額存入平臺賬號中，電子錢包的發(fā)/收僅是平臺系統(tǒng)內(nèi)的金額數(shù)據(jù)的轉(zhuǎn)移和標記，用戶的實際金額存入平臺賬戶中，帶來資金數(shù)據(jù)的安全問題，存在第三方平臺資金風險，且現(xiàn)有技術(shù)中的提現(xiàn)操作步驟繁瑣。

并且，現(xiàn)有技術(shù)中的電子紅包都依托于特定的傳播平臺，不能夠跨平臺獨立傳播，從而限制了電子紅包的傳播范圍，降低電子紅包的傳播效率。而本發(fā)明實施例中的電子紅包的實現(xiàn)無需基于第三方平臺實現(xiàn)，用戶發(fā)出電子紅包后，對應金額仍舊在發(fā)紅包者的銀行賬戶中凍結(jié)，直到其他用戶確認收到電子紅包后，將對應電子紅包金額從發(fā)紅包者的銀行賬戶中解除凍結(jié)并轉(zhuǎn)賬到收紅包者的銀行賬戶中。本方案不存在資金在第三方平臺上的安全問題，本方案中，電子錢包的實際金額在銀行賬戶中直接流轉(zhuǎn)，相比于現(xiàn)有技術(shù)中需在平臺賬戶中流轉(zhuǎn)以及繁瑣的提現(xiàn)步驟，本方案中的提現(xiàn)步驟簡便，安全性高。

本方案中的電子紅包實現(xiàn)了跨平臺傳輸，現(xiàn)有技術(shù)中的電子紅包數(shù)據(jù)僅能在即時通訊、電商平臺等同一平臺內(nèi)部進行傳輸和處理，本方案中的電子紅包的發(fā)和領(lǐng)取不限于同一平臺，支持不同平臺間進行數(shù)據(jù)的傳輸、交互和處理。

為了更好的說明本方案的技術(shù)優(yōu)勢，結(jié)合附圖8，發(fā)行終端5發(fā)布電子紅包，接收客戶端6、接收客戶端7……接收客戶端n收到電子紅包，在對電子紅包進行領(lǐng)取時，無需與發(fā)行終端5發(fā)布電子紅包的同一平臺進行領(lǐng)取，同時各 接收客戶端還可通過通信交互窗口進行信息反饋。而現(xiàn)有技術(shù)中發(fā)紅包與領(lǐng)紅包均需在同一平臺系統(tǒng)上進行，本方案中接收客戶端6、接收客戶端7……接收客戶端n中的領(lǐng)取紅包可以為不同的平臺系統(tǒng)，例如各銀行的移動客戶端。本方案中接收客戶端6、接收客戶端7……接收客戶端n還可以將電子紅包領(lǐng)取請求直接發(fā)至接收用戶的銀行賬號的銀行終端，無需基于任何平臺系統(tǒng)。通過本方案，實現(xiàn)了電子紅包跨平臺傳輸和領(lǐng)取。同時，通過允許接收端通過通信交互窗口進行信息反饋，有利于電子紅包發(fā)放方掌握電子紅包的發(fā)放情況及接收方的反饋信息。

請參閱圖9，圖9是本發(fā)明第四實施例提供的數(shù)據(jù)處理裝置的結(jié)構(gòu)示意圖，為了便于說明，僅示出了與本發(fā)明實施例相關(guān)的部分。該裝置可以是上述第一實施例提供的數(shù)據(jù)處理方法的執(zhí)行主體，如服務器或服務器中的一個模塊。該裝置主要包括：接收模塊401、生成模塊402以及發(fā)送模塊403。各功能模塊詳細說明如下：

接收模塊401，用于接收發(fā)放端發(fā)送的電子紅包開立指令，該開立指令中包含有為電子紅包開立的金額信息；

生成模塊402，用于當獲取到銀行端發(fā)放的電子承諾支付憑證的信息時，生成電子紅包的配置文件，并將該電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及該電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及該原本的副本；

發(fā)送模塊403，用于將所述電子紅包的副本發(fā)送給電子紅包的接收端，使得所述接收端根據(jù)接收的所述電子紅包的副本，顯示電子紅包的界面，并在所述界面上顯示所述通信交互窗口，向所述銀行端發(fā)送所述解付申請指令。

需要說明的是，以上圖9示例的數(shù)據(jù)處理裝置的實施方式中，各功能模塊的劃分僅是舉例說明，實際應用中可以根據(jù)需要，例如相應硬件的配置要求或者軟件的實現(xiàn)的便利考慮，而將上述功能分配由不同的功能模塊完成，即將該 裝置的內(nèi)部結(jié)構(gòu)劃分成不同的功能模塊，以完成以上描述的全部或者部分功能。而且，實際應用中，本實施例中的相應的功能模塊可以是由相應的硬件實現(xiàn)，也可以由相應的硬件執(zhí)行相應的軟件完成。本說明書提供的各個實施例都可應用上述描述原則，以下不再贅述。

本發(fā)明實施例未盡細節(jié)，請參見前述圖1所述實施例的描述。

請參閱圖10，圖10是本發(fā)明第五實施例提供的數(shù)據(jù)處理裝置的結(jié)構(gòu)示意圖，為了便于說明，僅示出了與本發(fā)明實施例相關(guān)的部分。在圖9示例的數(shù)據(jù)處理裝置的基礎(chǔ)上，本實施例與圖9示例的數(shù)據(jù)處理裝置的不同之處在于，在本實施例中：

進一步地，該裝置還包括：

通信模塊501，用于接收該接收端通過該通信交互窗口發(fā)送的反饋信息；

數(shù)據(jù)更新模塊502，用于將該反饋信息寫入該電子紅包的原本中；

發(fā)送模塊403，還用于將該反饋信息發(fā)送給該發(fā)放端；

通信模塊501，還用于接收該發(fā)放端根據(jù)該反饋信息發(fā)送的回饋信息；

數(shù)據(jù)更新模塊502，還用于將該回饋信息寫入該電子紅包的原本中；

發(fā)送模塊403，還用于向該接收端發(fā)送更新指令，使得該接收端根據(jù)該電子紅包的原本更新該副本，以將該回饋信息顯示在該通信交互窗口中。

進一步地，接收模塊401，還用于獲取該電子紅包的流通數(shù)據(jù)；

數(shù)據(jù)更新模塊502，還用于將該流通數(shù)據(jù)寫入該電子紅包的原本中，該流通數(shù)據(jù)包括該電子紅包每一次被轉(zhuǎn)送的發(fā)送方和接收方的信息數(shù)據(jù)。

進一步地，接收模塊401，還用于接收該發(fā)放端發(fā)送的申請開立電子紅包的請求，該請求中包含有該發(fā)放方的賬戶信息；

該裝置還包括：

判斷模塊503，用于判斷該發(fā)放方的賬戶是否具有開立該電子紅包的權(quán)限；

發(fā)送模塊403，還用于若該發(fā)放方的賬戶具有開立該電子紅包的權(quán)限，則 向該發(fā)放端發(fā)送授權(quán)該發(fā)放方的賬戶開立該電子紅包的反饋信息。

進一步地，發(fā)送模塊403，還用于將該開立指令中為電子紅包開立的金額信息轉(zhuǎn)發(fā)給該銀行端，使得該銀行端根據(jù)該金額信息生成該電子承諾支付憑證，并將該電子承諾支付憑證的信息發(fā)送給該服務器。

本發(fā)明實施例未盡細節(jié)，請參見前述圖1所示實施例的描述。

從上述圖9或圖10示例的數(shù)據(jù)處理裝置可知，本發(fā)明通過將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件，按照預置的規(guī)則封裝為電子紅包，使得接收方在收到電子紅包后，還可以利用通信交互窗口與紅包發(fā)放方進行信息交流，相較于現(xiàn)有技術(shù)，本發(fā)明通過將電子紅包與通信交互相結(jié)合，服務器在處理發(fā)送端和接收端之間傳輸?shù)碾娮蛹t包資源包的過程中，還可獲取發(fā)送端和接收端對電子紅包的反饋信息，從而可提高服務器對資源包相關(guān)反饋信息的處理效率，有利于資源包發(fā)送者對傳輸?shù)男畔⒒蛘邤?shù)據(jù)的掌握。并進一步地，通過記錄流通軌跡，可使得電子紅包承載更多的信息，擴展了電子紅包的應用范圍。

請參閱圖11，圖11是本發(fā)明第六實施例提供的數(shù)據(jù)交互系統(tǒng)的結(jié)構(gòu)示意圖，如圖11所示，該系統(tǒng)包括：發(fā)放端601、服務器602、接收端603、銀行端604；

其中，發(fā)放端601，用于根據(jù)電子紅包發(fā)放方觸發(fā)的開立指令，生成電子紅包開立指令，并將該電子紅包開立指令發(fā)送給服務器602，該電子紅包開立指令中包含有為電子紅包開立的金額信息；

服務器602，用于將該電子紅包開立指令轉(zhuǎn)發(fā)給銀行端604；

銀行端604，用于根據(jù)該金額信息，凍結(jié)電子紅包發(fā)放方的賬戶內(nèi)該金額信息對應的虛擬資源，生成電子承諾支付憑證及解付申請指令，并將該電子承諾支付憑證的信息及該解付申請指令發(fā)送給服務器602；

服務器602，還用于生成電子紅包的配置文件，并將該電子承諾支付憑證 的信息、該解付申請指令、通信交互窗口以及該電子紅包的配置文件按照預置的規(guī)則進行封裝，生成電子紅包的原本及該原本的副本，將該電子紅包的副本發(fā)送給電子紅包的接收端603；

接收端603，用于根據(jù)接收的該電子紅包的副本，顯示電子紅包的界面，并在該界面上顯示該通信交互窗口，以及向銀行端604發(fā)送解付申請指令；

銀行端604，還用于根據(jù)該解付申請指令，將該電子承諾支付憑證中記載的虛擬資源從該電子紅包發(fā)放方的賬戶轉(zhuǎn)移給接收方的賬戶，并將處理結(jié)果發(fā)送給發(fā)放端601。

上述設備各自實現(xiàn)其功能的過程具體可參考上述第一實施例至第三實施例，上述服務器的結(jié)構(gòu)具體可參考上述第四實施例和第五實施例，此處不再贅述。

本發(fā)明實施例提供的數(shù)據(jù)交互系統(tǒng)，通過服務器將電子承諾支付憑證的信息、解付申請指令、通信交互窗口以及電子紅包的配置文件，按照預置的規(guī)則封裝為電子紅包，使得接收方在收到電子紅包后，還可以利用通信交互窗口與紅包發(fā)放方進行信息交流，相較于現(xiàn)有技術(shù)，本發(fā)明通過將電子紅包與通信交互相結(jié)合，服務器在處理發(fā)送端和接收端之間傳輸?shù)碾娮蛹t包資源包的過程中，還可獲取發(fā)送端和接收端對電子紅包的反饋信息，從而可提高服務器對資源包相關(guān)反饋信息的處理效率，有利于資源包發(fā)送者對傳輸?shù)男畔⒒蛘邤?shù)據(jù)的掌握。

在本申請所提供的幾個實施例中，應該理解到，所揭露的方法、裝置和系統(tǒng)，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述模塊的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個模塊或組件可以結(jié)合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或模塊的間接耦合或通信連接，可以是電性，機械或其它的形式。

所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理模塊，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡模塊上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能模塊可以集成在一個處理模塊中，也可以是各個模塊單獨物理存在，也可以兩個或兩個以上模塊集成在一個模塊中。上述集成的模塊既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能模塊的形式實現(xiàn)。

所述集成的模塊如果以軟件功能模塊的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算機可讀取存儲介質(zhì)中?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分或者該技術(shù)方案的全部或部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括：u盤、移動硬盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。

需要說明的是，對于前述的各方法實施例，為了簡便描述，故將其都表述為一系列的動作組合，但是本領(lǐng)域技術(shù)人員應該知悉，本發(fā)明并不受所描述的動作順序的限制，因為依據(jù)本發(fā)明，某些步驟可以采用其它順序或者同時進行。其次，本領(lǐng)域技術(shù)人員也應該知悉，說明書中所描述的實施例均屬于優(yōu)選實施例，所涉及的動作和模塊并不一定都是本發(fā)明所必須的。

在上述實施例中，對各個實施例的描述都各有側(cè)重，某個實施例中沒有詳述的部分，可以參見其它實施例的相關(guān)描述。

以上為對本發(fā)明所提供的數(shù)據(jù)處理方法及裝置、數(shù)據(jù)交互方法及系統(tǒng)的描 述，對于本領(lǐng)域的技術(shù)人員，依據(jù)本發(fā)明實施例的思想，在具體實施方式及應用范圍上均會有改變之處，綜上，本說明書內(nèi)容不應理解為對本發(fā)明的限制。