TWI677837B - 業務資訊處理方法及裝置 - Google Patents

Abstract

本申請案揭示了一種業務資訊處理方法及裝置，該方法包括：接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊，將所述業務資訊發送至預先與該用戶帳戶綁定的業務帳戶，並透過該業務帳戶對所述業務資訊進行處理，透過所述業務帳戶，將處理後的所述業務資訊發送至所述用戶帳戶中。透過設定與用戶帳戶綁定的業務帳戶，接收業務資訊，並對該業務資訊進行相應處理後發送給用戶帳戶，那麼，即使用戶帳戶在國際業務情況下，不具備接收業務資訊的功能，也可以透過業務帳戶接收業務資訊，再發送至用戶帳戶中。有效解決了在國際業務情況中，用戶帳戶不能直接接收業務資訊的情況，也提升了業務資訊處理的效率。

Description

業務資訊處理方法及裝置

本申請案係有關電腦技術領域，尤其有關一種業務資訊處理方法及裝置。

隨著資訊技術的發展，網際網路為用戶提供了豐富的網路資源，用戶可以透過註冊用戶帳戶的方式，便捷地獲得各類業務服務。

現有技術中，通常用戶獲得業務服務的方式為：用戶使用自身的用戶帳戶，向相應的伺服器發出業務指令，伺服器在接收到用戶帳戶發出的業務指令後，就會根據該業務指令而將相應的業務資訊反饋至用戶帳戶，從而，用戶便獲得了該業務服務。尤其對於現如今業務服務國際化的趨勢，不同國家和地區的用戶都可以在相同的網站中獲得各類業務服務，例如：線上交易、視頻訂閱、資訊查詢等等。

但是，在國際業務環境下，由於不同國家和地區的差異，用戶獲得業務服務的方式、途徑各不相同，同一個伺服器為了確保業務資訊能夠送達至相應的用戶帳戶，只能 按照發出業務指令的管道來反饋業務資訊。如果發出業務指令的管道不具備接收業務資訊的功能，那麼，將導致用戶不能接收相應的業務資訊。

例如：在國際支付情況中，用戶針對其購買的商品進行退款，該用戶會透過其用戶帳戶向伺服器發出退款請求指令，伺服器根據該用戶的退款請求指令，將退款資訊按照該用戶購買商品時的付款方式(亦即，付款方式就是發出業務指令的管道)，退還給用戶。但是，用戶進行支付時的付款方式可能是用戶透過其註冊的用戶帳戶而直接進行支付，但由於部分國家和地區對網路支付的要求不同，某些國家和地區禁止用戶註冊的用戶帳戶等虛擬帳戶直接接收伺服器退還的款項，只能透過銀行帳戶接收款項，這樣一來，該退款資訊便不會退回至用戶帳戶中，從而導致用戶不能接收退回的款項。

本申請案實施例提供一種業務資訊處理方法及裝置，用以解決目前國際業務環境下，業務服務效率較低的問題。

本申請案實施例提供一種業務資訊處理方法，包括：接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊；將所述業務資訊發送至預先與該用戶帳戶綁定的業務帳戶，並透過該業務帳戶對所述業務資訊進行處理； 透過所述業務帳戶，將處理後的所述業務資訊發送至所述用戶帳戶中。

本申請案實施例提供一種業務資訊處理裝置，包括：產生模組，用以接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊；業務帳戶模組，用以將所述業務資訊發送至預先與該用戶帳戶綁定的業務帳戶，並透過該業務帳戶對所述業務資訊進行處理；發送模組，用以透過所述業務帳戶，將處理後的所述業務資訊發送至所述用戶帳戶中。

本申請案實施例提供一種業務資訊處理方法及裝置，透過設定與用戶帳戶綁定的業務帳戶，使得用戶使用自身的用戶帳戶發出相應的業務指令後，伺服器可以將與該業務指令對應的業務資訊發送給業務帳戶進行相應處理，並由該業務帳戶將處理完成的業務資訊發送至用戶帳戶，而不直接發給用戶帳戶，這樣一來，即使用戶帳戶在國際業務情況下，不具備接收業務資訊的功能，也可以透過業務帳戶接收業務資訊，再發送至用戶帳戶中。有效解決了在國際業務情況中，用戶帳戶不能直接接收業務資訊的情況，也提升了業務資訊處理的效率。

201‧‧‧產生模組

202‧‧‧業務帳戶模組

203‧‧‧發送模組

此處所說明的附圖用來提供對本申請案的進一步理解，且構成本申請案的一部分，本申請案的示意性實施例 及其說明用來解釋本申請案，並不構成對本申請案的不當限定。在附圖中：圖1為本申請案實施例提供的業務資訊處理過程；圖2為本申請案實施例提供的業務資訊處理裝置結構示意圖。

為使本申請案的目的、技術方案和優點更加清楚，下面將結合本申請案具體實施例及相應的附圖而對本申請案技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本申請案的一部分實施例，而不是全部的實施例。基於本申請案中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本申請案保護的範圍。

圖1為本申請案實施例提供的業務資訊處理過程，該過程具體包括以下步驟：

S101，接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊。

在本申請案實施例中，當用戶想要獲得業務服務，並使用其用戶帳戶發出業務指令時，可由相應的伺服器接收所述業務指令，並根據該業務指令而產生相應的業務資訊。

其中，所述的用戶帳戶，具體為用戶預先在伺服器中進行註冊的個人帳戶。所述的業務指令為用戶透過其用戶 帳戶向伺服器所發出之用以獲得業務服務的指令，如：退款指令等。所述業務資訊為伺服器根據業務指令所產生的業務服務結果資訊，如：退款資訊等。

具體例如：中國的用戶A在某一網站中註冊了用戶名為userA的個人帳戶，該個人帳戶userA就是用戶A的用戶帳戶。當用戶A使用其用戶帳戶userA從該網站購買商品後，因商品的品質問題，用戶A想要辦理退款業務，該用戶A便可透過其用戶帳戶userA而發出退款指令，網站的伺服器會根據該退款指令而產生相應的退款資訊，此時，該退款指令就是業務指令，該退款資訊就是業務資訊。當然，在本申請案實施例中，當用戶帳戶接收到退款資訊後，該用戶帳戶中的款項額度將立即發生變化，亦即，用戶帳戶中的款項額度將立即增加退款資訊中的款項額度，接收退款資訊也就意味著退款業務已經辦理成功。

這裏需要說明的是，當用戶使用其用戶帳戶發出業務指令，如：退款指令時，伺服器會根據該退款指令，查詢該退款指令對應的業務服務操作的詳細資訊，包括：進行支付時的額度、支付的管道等資訊，伺服器將根據查詢到的這些資訊而產生相應的業務資訊，亦即，退款資訊。因此，在本申請案實施例中，所述業務資訊包括支付管道和/或退款額度。

S102，將所述業務資訊發送至預先與該用戶帳戶綁定的業務帳戶中，並透過該業務帳戶對所述業務資訊進行處理。

延續上例進行說明，假設用戶A在購買商品時，其支付管道(此處的支付管道是指用戶A向商品賣家支付款項的管道)為：用戶A使用自身的用戶帳戶userA中預先儲存的餘額直接進行支付。則伺服器為用戶A辦理退款業務時，相應的支付管道(此處的支付管道是指伺服器向用戶A支付退款金額的管道)為：伺服器將用戶A支付的款項發送至用戶A自身的用戶帳戶userA中。而在現有技術中的國際業務服務情況下，由於部分國家和地區的規定，不允許伺服器直接將退款資訊發送至用戶帳戶中，那麼，伺服器也就不能按照支付管道發送退款資訊，亦即，伺服器不能將退款資訊直接發送至用戶帳戶userA中。

因此，為了解決支付管道不能接收業務資訊的問題，在本申請案實施例中，透過設定相應業務帳戶的方式，接收伺服器產生的業務資訊。

本申請案實施例中所述的業務帳戶，具體為允許接收業務資訊的非個人帳戶，如：企業帳戶。當然，在本申請案實施例中，所述業務帳戶也是預先在所述伺服器中進行註冊的帳戶。例如：上述網站可以註冊所屬國家為中國的業務帳戶China-user，該業務帳戶China-user預先與用戶帳戶userA進行綁定，伺服器可以將相應的退款資訊發送至業務帳戶China-user中。

此處需要說明的是，伺服器將包含有退款額度的業務資訊發送至業務帳戶中後，該業務帳戶中的額度值並不會立即發生變化，這是因為：對於伺服器而言，所述業務資 訊中包含的退款額度，僅僅是一種字元類資訊，其反映了退款額度的數值。在用戶進行退款操作的過程中，額度值的變化實際上就是相應的銀行帳戶中儲存額度發生了變化，也就是說，伺服器在對退款操作進行處理時，需要與銀行系統(如：銀行伺服器)進行互動，並在銀行系統對退款操作所對應的額度進行記錄處理後，伺服器才會改變用戶帳戶中額度的數值。

根據上述分析，對於步驟S102，當伺服器將所述業務資訊發送至業務帳戶中後，透過該業務帳戶對所述業務資訊進行處理，具體為：該業務帳戶將根據所述業務資訊中的退款額度，與相應的銀行系統進行互動，使銀行系統記錄該退款額度，亦即，銀行系統會將該退款額度記錄在用戶帳戶所對應的銀行帳戶(如：與用戶帳戶綁定的銀行卡)中。

例如：在上例中，業務帳戶China-user在接收到針對用戶帳戶userA的退款額度後，會向該用戶帳戶userA所對應的銀行系統進行互動，使得該銀行系統將該退款額度記錄在userA對應的銀行帳戶中。

另外，實際應用情況中，伺服器針對不同國家和地區的用戶帳戶產生的業務資訊並不相同，例如：假設業務資訊為退款資訊，那麼，由於不同國家和地區的幣種的區別，伺服器將根據用戶帳戶在支付時所使用的幣種，產生對應幣種的退款資訊。在這樣的情況下，如果用戶帳戶與其綁定的業務帳戶不屬於同一個國家和地區，其退款資訊 將受到匯率差的影響，導致退款資訊出現一定的匯率波動誤差。

因此，在本申請案實施例中的一種較佳方式下，當用戶完成用戶帳戶的註冊時，伺服器可根據確定出的用戶帳戶以及業務帳戶所屬的國家和地區，自動將屬於同一個國家和地區的用戶帳戶與業務帳戶進行綁定。需要說明的是，在國際業務情況下的用戶來自不同國家和地區，當用戶在相應的伺服器中註冊用戶帳戶時，伺服器可以根據用戶的網際網路協定位址(Internet Protocol，IP地址)，確定出該用戶帳戶所屬的國家和地區。同樣，伺服器在所述業務帳戶進行註冊時，也可根據相應的IP位址，確定所述業務帳戶所屬的國家和地區。

當然，在實際應用中，是否自動按照用戶帳戶以及業務帳戶所屬的國家和地區進行綁定，可根據實際應用時的需要進行設定，這裏並不構成對本申請案的限定。

在本申請案實施例的一種方式下，一個業務帳戶可與多個用戶帳戶進行綁定，亦即，所屬國家和地區相同的用戶帳戶，可以與同樣屬於該國家和地區的業務帳戶進行綁定，此時，該業務帳戶為公共的業務帳戶。各用戶帳戶的業務資訊，均暫存在該公共的業務帳戶中。當然，在公共的業務帳戶中，記錄有不同的用戶帳戶對應的業務資訊，並不會出現業務資訊混亂的情況。

S103，透過所述業務帳戶，將處理後的所述業務資訊發送至所述用戶帳戶中。

業務帳戶中儲存有不同用戶帳戶的業務資訊，經過上述的處理過程，銀行系統已經將退款額度記錄在用戶帳戶所綁定的銀行帳戶中，這樣一來，透過業務帳戶，就可以將該業務帳戶中儲存的業務資訊，分別發送至這些業務資訊對應的各用戶帳戶中，使不同的用戶帳戶所保存的款項額度的數值發生變化。業務帳戶向將業務資訊發送至用戶帳戶的過程，可看作是帳戶與帳戶之間進行資訊互動的過程，從而業務資訊能夠有效地發送至用戶帳戶。

延續上例：伺服器可以透過業務帳戶China-user，將退款資訊發送至用戶帳戶userA中，從而，用戶帳戶userA便獲得了來自伺服器的退款，該用戶帳戶userA中的款項額度的數值將發生變化，從而完成退款業務。

透過上述步驟，在伺服器中預先註冊具有接收並發送業務資訊許可權的業務帳戶，當不同用戶在該伺服器中註冊了相應的用戶帳戶時，將同一個國家和地區的用戶帳戶與同屬於該國家和地區的業務帳戶進行綁定，這樣一來，當伺服器根據用戶帳戶發出的業務指令，產生對應的業務資訊時，可以直接發送至該業務帳戶，再由該業務帳戶將該業務資訊發送至相應的用戶帳戶中，從而，可以有效確保業務資訊可以送達用戶帳戶。

在實際應用中的國際業務服務情況下，用戶在註冊用戶帳戶時，需要將相應的銀行帳戶(如：銀行卡)與該用戶帳戶建立關聯，以便在業務服務中進行支付等操作。那麼，當所述業務資訊中包括退款額度時，可採用上述步驟 S102至S103的方式，將所述業務資訊發送至與所述用戶帳戶綁定的業務帳戶中，再透過該業務帳戶將業務資訊直接發送至用戶帳戶對應的銀行帳戶中。

繼續沿用上例：用戶A使用自身的銀行卡X與其用戶帳戶userA進行關聯，亦即，銀行卡X就是該用戶帳戶userA的銀行帳戶。假設用戶A在購買某商品時，其支付管道為：用戶A使用該銀行卡X進行支付，那麼，用戶A使用其用戶帳戶userA向伺服器發出退款指令後，伺服器會將相應的退款資訊發送至與用戶帳戶userA綁定的業務帳戶China-user中，並根據支付管道，透過該業務帳戶China-user，將退款資訊發送至銀行卡X中，完成退款業務。

但是，不同銀行對於此類退款業務，定置有相應的額度限制，亦即，只有退款額度達到該銀行設定的規定額度時，銀行才會接收該業務資訊，而對於未達到規定額度的業務資訊，銀行通常不予受理。也就是說，若用戶帳戶的業務資訊未達到銀行設定的規定額度時，就會造成業務資訊不能發送至該用戶的銀行帳戶的情況。例如：假設銀行卡X所屬銀行的最低退款額度為10元，若退款資訊中包含的額度僅為8元，那麼，銀行將不予受理，亦即，此次退款操作將失敗。

因此，當所述業務資訊中包括退款額度時，在上述步驟S103中，將處理後的所述業務資訊發送至所述用戶帳戶中，具體為：判定所述業務資訊是否滿足預定條件，若 是，則透過所述業務帳戶，將所述業務資訊發送至用戶帳戶對應的銀行帳戶中，否則，則儲存所述業務資訊至資訊集合中，知道所述資訊集合中的所有業務資訊的總量滿足所述預設條件時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中。

而在本申請案實施例中，由於業務資訊中包括退款額度，故判定所述業務資訊是否滿足預定條件，實際上就是判定所述業務資訊中包含的退款額度是否高於最低退款額度(亦即，銀行設定的規定額度)。若是，就表明業務資訊中的退款額度高於或等於銀行設定的最低退款額度，則判定所述業務資訊滿足所述預定條件。否則，就表明業務資訊中的退款額度低於銀行設定的最低退款額度，則判定所述業務資訊不滿足預定條件。

對於業務資訊滿足預定條件的情況，就可以透過業務帳戶，將業務資訊發送至相應的銀行帳戶中。

但是，對於業務資訊不滿足預定條件的情況，用戶帳戶對應的銀行帳戶將不會接收該業務資訊，也就不能透過業務帳戶將業務資訊發送用戶帳戶對應的銀行帳戶。此時，伺服器可將不滿足預定條件的業務資訊，儲存在業務帳戶中的資訊集合中。

具體地說，考慮到用戶可能多次使用其用戶帳戶獲得業務服務，伺服器也就會多次將相應的業務資訊發送至業務帳戶中，這樣經過一段時間的累積後，儲存在該業務帳戶中的業務資訊總量可能就會滿足預定的條件。因此，在 本申請案實施例中的一種方式下，將所述業務資訊儲存至資訊集合中，具體為：將所述業務資訊儲存至所述用戶帳戶對應的資訊集合中，直到所述資訊集合中的所有業務資訊的總量滿足所述預設條件時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中，具體為：當所述資訊集合中的所有業務資訊中包含的退款額度之和高於所述最低退款額度時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中。

下面沿用上例進行具體說明：用戶A使用該用戶帳戶userA在該網站中購買某商品，並使用與該用戶帳戶userA綁定的、由銀行1發行的銀行卡X支付RMB4元後，因商品的品質問題，用戶A使用其用戶帳戶userA發出退款指令。伺服器接收到該退款指令後，會將產生的退款資訊發送至與用戶帳戶userA綁定的業務帳戶China-user中。其中，該退款資訊中包含有RMB4元的退款額度。

此時，假設銀行1設定的最低退款額度為RMB10元，顯然，退款資訊中的退款額度(RMB4元)低於該銀行1的最低退款額度，從而便不能透過該業務帳戶China-user將退款資訊發送至銀行卡X中。

因此，伺服器會將該退款資訊儲存在業務帳戶China-user中對應於用戶帳戶userA的資訊集合中，該資訊集合用於儲存該用戶帳戶userA的所有退款資訊。

在一段時間後，用戶A使用其用戶帳戶userA購買商 品支付的RMB 8元，並出於同樣原因向伺服器發出退款指令，伺服器將產生的退款資訊發送業務帳戶China-user中對應於用戶帳戶userA的資訊集合中，此時退款資訊的退款額度的總量為RMB 12元，高於銀行1的最低退款額度，從而伺服器透過業務帳戶China-user將退款額度總量為RMB 12元的退款資訊發送至用戶A的銀行卡X中，完成退款業務。

從上例可見，上述方式是對單一用戶帳戶的業務資訊進行儲存累積，當單一用戶帳戶的業務資訊不滿足預設條件時，可以將該用戶帳戶的業務資訊儲存在業務帳戶中的資訊集合中，累積所述業務資訊，直到所述業務資訊的總量滿足所述預設條件，便可以將業務資訊發送至該用戶帳戶對應的銀行帳戶中，完成退款操作。

但是，在實際應用中，某些用戶使用其用戶帳戶的頻率較低，該用戶可能在較長時間內不使用該用戶帳戶進行業務服務操作，在這樣的情況下，若採用上述對單一用戶帳戶的業務資訊進行儲存累積的方式，由於該用戶較長時間不使用該用戶帳戶，將會導致該用戶帳戶的業務資訊將長時間儲存在業務帳戶中，而不能發送至該用戶帳戶對應的銀行帳戶中，嚴重降低了退款業務的處理效率。

因此，為了提高退款業務的處理效率，在本申請案實施例的另一種方式下，將所述業務資訊儲存至資訊集合中，具體為：確定所述用戶帳戶對應的銀行帳戶所屬的銀行類型，將所述業務資訊儲存至確定的所述銀行類型對應 的資訊集合中。當所述資訊集合中的所有業務資訊中包含的退款額度之和高於所述最低退款額度時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中。亦即，這樣的方式，將同屬於同一種銀行類型的多個銀行帳戶的業務資訊共同進行儲存累積，有效增加了業務資訊的儲存累積效率。

這裏需要說明的是，銀行類型對應的資訊集合中，含有多個用戶帳戶的業務資訊(有些業務資訊中包含的退款額度滿足預設條件，而有些則不滿足預設條件)，將這些業務資訊發送至各自對應的銀行帳戶時，若針對不同業務帳戶的業務資訊進行單獨發送，由於有些業務資訊不滿足預設條件，銀行不予受理。從而，只能將這些業務資訊一併發送至某一個公共的銀行帳戶中，再在該銀行內進行分發處理。因此，在本申請案實施例中，業務帳戶針對不同的銀行類型，關聯設定有不同的銀行帳戶，亦即，公共銀行帳戶。這樣一來，當採用對多個銀行帳戶的業務資訊共同進行儲存累積的方式時，就可以將滿足預設條件的資訊集合中的業務資訊一併發送至公共銀行帳戶中，再將該公共銀行帳戶中的業務資訊發送至不同用戶帳戶對應的銀行帳戶中。

下面以一個應用實例來對上述方式進行具體說明：在本應用實例中，用戶A的用戶帳戶仍為userA，銀行帳戶為銀行卡X，該銀行卡X所屬的銀行類型為銀行1，並且在本例中增加了中國的用戶B和用戶C，其中， 對於用戶B而言，其用戶帳戶為userB，銀行帳戶為銀行卡Y，該銀行卡Y所屬的銀行類型為銀行2，銀行2設定的最低退款額度為RMB 8元。

對於用戶C而言，其用戶帳戶為userC，銀行帳戶為銀行卡Z，該銀行卡Z所屬的銀行類型為銀行1。

由於用戶帳戶userB及userC所屬的國家都為中國，伺服器會將用戶帳戶userB及userC與業務帳戶China-user進行綁定。

另外，在本應用實例中，業務帳戶China-user針對銀行1關聯設定的公共銀行帳戶為銀行卡CN1，針對銀行2關聯設定的公共銀行帳戶為銀行卡CN2。

具體過程為：與上例相同，用戶A使用該用戶帳戶userA發出退款指令。伺服器將產生的退款資訊發送至與用戶帳戶userA綁定的業務帳戶China-user中。其中，該退款資訊中包含有RMB 4元的退款額度。

用戶B使用其用戶帳戶userB發出退款指令，要求退還額度為RMB 6元的款項。伺服器接收到該退款指令後，會將產生的退款資訊發送至與用戶帳戶userB綁定的業務帳戶China-user中。其中，該退款資訊中包含有RMB 6元的退款額度。

用戶C使用其用戶帳戶userC發出退款指令，要求退還額度為RMB 9元的款項。伺服器接收到該退款指令後，會將產生的退款資訊發送至與用戶帳戶userC綁定的 業務帳戶China-user中。其中，該退款資訊中包含有RMB 9元的退款額度。

伺服器現確定用戶帳戶userA、userB以及userC各自的退款資訊均不滿足銀行設定的最低退款額度。因此，伺服器將儲存業務資訊至資訊集合中。

此時，伺服器確定用戶帳戶userA對應的銀行卡X，以及用戶帳戶userC對應的銀行卡Z所屬的銀行類型均是銀行1，那麼，伺服器會將用戶帳戶userA和userC的退款資訊儲存至業務帳戶China-user內銀行1對應的資訊集合中。從而，在銀行1對應的資訊集合中，退款資訊中包含的退款額度之和為RMB 13元，高於銀行1設定的最低退款額度RMB 10元。因此，伺服器可將退款資訊一併發送至銀行1中，亦即，發送至銀行卡CN1中。之後，銀行1再將該銀行卡CN1中的退款資訊分別發送至銀行卡X和銀行卡Z中。

伺服器確定用戶帳戶userB對應的銀行卡Y所屬的銀行類型是銀行2，伺服器會將用戶帳戶userB的退款資訊，以及銀行帳戶所屬的銀行類型是銀行2的其他用戶帳戶(在本例中未具體示出)的退款資訊，均儲存至業務帳戶China-user內銀行2對應的資訊集合中。並當銀行2對應的資訊集合中，退款資訊中包含的退款額度之和高於銀行2設定的最低退款額度RMB 8元後，將該資訊集合中的退款資訊一併發送至銀行卡CN2中，再由銀行2將該銀行卡CN2中的退款資訊分發至不同的銀行帳戶中。從 而完成退款業務。

從上例可見，上述方式是對銀行帳戶所屬銀行類型相同的多個用戶帳戶的業務資訊進行共同儲存累積，即使某一個用戶帳戶的業務資訊不滿足預設條件，也可以透過共同儲存累積的方式，使資訊集合中儲存的業務資訊的總量在短時間內滿足預設條件，有效增加了業務資訊的儲存累積效率。

當然，在實際應用情況下，透過業務帳戶，將退款資訊發送至銀行帳戶時，會產生相應的手續費，那麼，對於同一個用戶帳戶而言，該用戶帳戶有多個退款資訊的情況下，則會產生多筆手續費。因此，可以採用本申請案實施例中的方式，對同一個用戶帳戶的多個退款資訊進行儲存累積，當多個退款資訊中包含的退款額度之和高於預設值時，將多個退款資訊一併發送。從而有效降低退款時產生的手續費。

以上為本申請案實施例提供的業務資訊處理方法，基於同樣的思路，本申請案實施例還提供一種業務資訊處理裝置，如圖2所示。

在圖2中，所述業務資訊處理裝置包括：產生模組201、業務帳戶模組202以及發送模組203，其中，所述產生模組201，用以接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊。

所述業務帳戶模組202，用以將所述業務資訊發送至預先與該用戶帳戶綁定的業務帳戶，並透過該業務帳戶對 所述業務資訊進行處理。

所述發送模組203，用以透過所述業務帳戶，將處理後的所述業務資訊發送至所述用戶帳戶中。

在本申請案實施例中，所述業務指令為退款指令，所述業務資訊為退款資訊，所述業務資訊包括支付管道和/或退款額度。

當所述業務資訊中包括退款額度時，所述發送模組203，具體用以判定所述業務資訊是否滿足預設條件，若是，則透過所述業務帳戶，將所述業務資訊發送至用戶帳戶對應的銀行帳戶中；否則，則將所述業務資訊儲存至資訊集合中，直到所述資訊集合中的所有業務資訊的總量滿足所述預設條件時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中。

所述發送模組203，具體用以判定所述業務資訊中包含的退款額度是否高於最低退款額度，若是，則判定所述業務資訊滿足所述預設條件；否則，則判定所述業務資訊不滿足所述預設條件。

所述發送模組203，具體用以確定所述用戶帳戶對應的銀行帳戶所屬的銀行類型，將所述業務資訊儲存至確定的所述銀行類型對應的資訊集合中，當所述資訊集合中的所有業務資訊中包含的退款額度之和高於所述最低退款額度時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中。

所述發送模組203，具體用以將所述業務資訊儲存至 所述用戶帳戶對應的資訊集合中，當所述資訊集合中的所有業務資訊中包含的退款額度之和高於所述最低退款額度時，將所述業務資訊發送至所述用戶帳戶對應的銀行帳戶中。

在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。

記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀取媒體的示例。

電腦可讀取媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀取指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可編程唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位影音光碟(DVD)或其他光學儲存器、磁盒式磁帶，磁帶磁碟片儲存器或其他磁性儲存設備或任何其他非傳輸媒體，可用來儲存可以被計算設備所訪問的資訊。按照本文中的界定，電腦可讀取媒體不包括暫態性電腦可讀取媒體(transitory media)，如調變的資料信號和載波。

還需要說明的是，術語“包括”、“包含”或者其任何其他變型意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個......”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。

本領域技術人員應明白，本申請案的實施例可提供為方法、系統或電腦程式產品。因此，本申請案可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體態樣的實施例的形式。而且，本申請案可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁盤記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。

以上所述僅為本申請案的實施例而已，並不用於限制本申請案。對於本領域技術人員來說，本申請案可以有各種更改和變化。凡在本申請案的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本申請案的申請專利範圍的範疇之內。

Claims (12)

1. 一種業務資訊處理方法，其特徵在於，包括：接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊；將該業務資訊發送至預先與該用戶帳戶綁定的業務帳戶，並透過該業務帳戶對該業務資訊進行處理，其中，該業務帳戶預先與該用戶帳戶綁定係藉由：根據當註冊該用戶帳戶時與該用戶帳戶相關聯的互聯網協定(IP)位址而判定該用戶帳戶所屬的第一國家和地區，根據當註冊該業務帳戶時與該業務帳戶相關聯的IP位址而判定該業務帳戶所屬的第二國家和地區，及如果該第一國家和地區與該第二國家和地區相同，將該用戶帳戶與該業務帳戶進行綁定；以及透過該業務帳戶，將處理後的該業務資訊發送至該用戶帳戶中。
2. 如申請專利範圍第1項所述的方法，其中，該業務指令為退款指令；以及該業務資訊為退款資訊，該業務資訊包括支付管道和/或退款額度。
3. 如申請專利範圍第2項所述的方法，其中，當該業務資訊中包括退款額度時，將處理後的該業務資訊發送至該用戶帳戶中，具體包括：判定該業務資訊是否滿足預設條件；若是，則透過該業務帳戶，將該業務資訊發送至用戶帳戶對應的銀行帳戶中；否則，則將該業務資訊儲存至資訊集合中，直到該資訊集合中的所有業務資訊的總量滿足該預設條件時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中。
4. 如申請專利範圍第3項所述的方法，其中，判定該業務資訊是否滿足預設條件，具體包括：判定該業務資訊中包含的退款額度是否高於最低退款額度；若是，則判定該業務資訊滿足該預設條件；否則，則判定該業務資訊不滿足該預設條件。
5. 如申請專利範圍第4項所述的方法，其中，將該業務資訊儲存至資訊集合中，具體包括：確定該用戶帳戶對應的銀行帳戶所屬的銀行類型；將該業務資訊儲存至確定的該銀行類型對應的資訊集合中；直到該資訊集合中的所有業務資訊的總量滿足該預設條件時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中，具體包括：當該資訊集合中的所有業務資訊中包含的退款額度之和高於該最低退款額度時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中。
6. 如申請專利範圍第4項所述的方法，其中，將該業務資訊儲存至資訊集合中，具體包括：將該業務資訊儲存至該用戶帳戶對應的資訊集合中；直到該資訊集合中的所有業務資訊的總量滿足該預設條件時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中，具體包括：當該資訊集合中的所有業務資訊中包含的退款額度之和高於所述最低退款額度時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中。
7. 一種業務資訊處理裝置，其特徵在於，包括：產生模組，用以接收用戶帳戶發出的業務指令，根據該業務指令而產生對應的業務資訊；業務帳戶模組，用以將該業務資訊發送至預先與該用戶帳戶綁定的業務帳戶，並透過該業務帳戶對該業務資訊進行處理，其中，該業務帳戶預先與該用戶帳戶綁定係藉由：根據當註冊該用戶帳戶時與該用戶帳戶相關聯的互聯網協定(IP)位址而判定該用戶帳戶所屬的第一國家和地區，根據當註冊該業務帳戶時與該業務帳戶相關聯的IP位址而判定該業務帳戶所屬的第二國家和地區，及如果該第一國家和地區與該第二國家和地區相同，將該用戶帳戶與該業務帳戶進行綁定；以及發送模組，用以透過該業務帳戶，將處理後的該業務資訊發送至該用戶帳戶中。
8. 如申請專利範圍第7項所述的裝置，其中，該業務指令為退款指令；以及該業務資訊為退款資訊，該業務資訊包括支付管道和/或退款額度。
9. 如申請專利範圍第8項所述的裝置，其中，當該業務資訊中包括退款額度時，該發送模組，具體用以判定該業務資訊是否滿足預設條件，若是，則透過該業務帳戶，將該業務資訊發送至用戶帳戶對應的銀行帳戶中；否則，則儲存該業務資訊至資訊集合中，直到該資訊集合中的所有業務資訊的總量滿足該預設條件時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中。
10. 如申請專利範圍第9項所述的裝置，其中，該發送模組，具體用以判定該業務資訊中包含的退款額度是否高於最低退款額度，若是，則判定該業務資訊滿足該預設條件；否則，則判定該業務資訊不滿足該預設條件。
11. 如申請專利範圍第10項所述的裝置，其中，該發送模組，具體用以確定該用戶帳戶對應的銀行帳戶所屬的銀行類型，將該業務資訊儲存至確定的該銀行類型對應的資訊集合中，當該資訊集合中的所有業務資訊中包含的退款額度之和高於該最低退款額度時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中。
12. 如申請專利範圍第10項所述的裝置，其中，該發送模組，具體用以將該業務資訊儲存至該用戶帳戶對應的資訊集合中，當該資訊集合中的所有業務資訊中包含的退款額度之和高於該最低退款額度時，將該業務資訊發送至該用戶帳戶對應的銀行帳戶中。