數(shù)據(jù)交互方法及裝置的制造方法
【專利摘要】本申請?zhí)峁┮环N數(shù)據(jù)交互方法及裝置，該方法包括：檢測到數(shù)據(jù)交互需求；確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象；獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息；將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。通過本申請的技術(shù)方案，可以對每一交互對象的實時交互能力進行展示，便于用戶查看并選擇恰當?shù)慕换ο?，有助于縮短交互時長、提升交互效率。
【專利說明】
數(shù)據(jù)交互方法及裝置
技術(shù)領(lǐng)域
[0001] 本申請涉及數(shù)據(jù)交互技術(shù)領(lǐng)域，尤其涉及數(shù)據(jù)交互方法及裝置。
【背景技術(shù)】
[0002] 在諸多應(yīng)用場景下，終端均需要與對應(yīng)的功能平臺實現(xiàn)數(shù)據(jù)交互。功能平臺的處 理能力往往十分強大，可以同時處理大量終端發(fā)起的數(shù)據(jù)交互需求；然而，當終端數(shù)量巨 大、數(shù)據(jù)交互需求劇增時，功能平臺也可能出現(xiàn)處理瓶頸，造成數(shù)據(jù)交互的體驗遲滯、不流 暢。

【發(fā)明內(nèi)容】

[0003] 有鑒于此，本申請?zhí)峁┮环N數(shù)據(jù)交互方法及裝置，以解決相關(guān)技術(shù)中的不足。
[0004] 為實現(xiàn)上述目的，本申請?zhí)峁┘夹g(shù)方案如下：
[0005] 根據(jù)本申請的第一方面，提出了一種數(shù)據(jù)交互方法，包括：
[0006] 檢測到數(shù)據(jù)交互需求；
[0007] 確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象；
[0008] 獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息；
[0009] 將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。
[0010] 根據(jù)本申請的第二方面，提出了一種數(shù)據(jù)交互裝置，包括：
[0011] 檢測單元，檢測到數(shù)據(jù)交互需求；
[0012] 確定單元，確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象；
[0013] 獲取單元，獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息；
[0014] 展示單元，將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。
[0015] 由以上技術(shù)方案可見，本申請通過獲取每一預設(shè)交互對象的實時處理能力信息， 實際上是了解到每一預設(shè)交互對象在處理當前檢測到的數(shù)據(jù)交互需求時的預估處理效果， 比如流暢、延遲、無法處理等，從而通過展示每一預設(shè)交互對象的實時處理能力信息，便于 用戶選取恰當?shù)念A設(shè)交互對象，順利實現(xiàn)對數(shù)據(jù)交互需求的處理，有助于提升用戶體驗。
【附圖說明】
[0016] 圖1是根據(jù)本申請一示例性實施例提供的一種數(shù)據(jù)交互方法的流程圖；
[0017] 圖2是根據(jù)本申請一示例性實施例提供的另一種數(shù)據(jù)交互方法的流程圖；
[0018] 圖3是根據(jù)本申請一示例性實施例提供的數(shù)據(jù)交互的應(yīng)用場景示意圖；
[0019] 圖4-8是根據(jù)本申請一示例性實施例提供的終端界面示意圖；
[0020] 圖9是根據(jù)本申請一示例性實施例提供的一種電子設(shè)備的結(jié)構(gòu)示意圖；
[0021] 圖10是根據(jù)本申請一示例性實施例提供的一種數(shù)據(jù)交互裝置的框圖。
【具體實施方式】
[0022] 圖1是根據(jù)本申請一示例性實施例提供的一種數(shù)據(jù)交互方法的流程圖，如圖1所 示，該方法應(yīng)用于終端，可以包括以下步驟：
[0023] 步驟102,檢測到數(shù)據(jù)交互需求。
[0024] 在本實施例中，當數(shù)據(jù)交互需求同時涉及多個可用的預設(shè)交互對象時，相應(yīng)的場 景均可以應(yīng)用本申請的技術(shù)方案，本申請對此并不進行限制。比如作為一示例性實施例，數(shù) 據(jù)交互需求可以為支付需求，則相應(yīng)的預設(shè)交互對象為多個支付渠道，比如銀行系統(tǒng)或支 付平臺等。
[0025] 步驟104,確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象。
[0026] 在本實施例中，基于當前發(fā)出數(shù)據(jù)交互需求的應(yīng)用程序、網(wǎng)頁或應(yīng)用功能，即可查 找到對應(yīng)的預設(shè)交互對象；比如當電子支付應(yīng)用程序發(fā)出支付需求時，相應(yīng)的預設(shè)交互對 象可能包括：支付平臺的余額管理平臺以及各銀行等。
[0027] 步驟106,獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息。
[0028] 在本實施例中，實時處理能力信息是指相應(yīng)的預設(shè)交互對象在實時（即當前時 亥IJ)處理數(shù)據(jù)交互需求時的能力；其中，當能力越強時，表明對數(shù)據(jù)交互需求的處理過程越 順利（比如延遲更小、出錯概率更低）。換言之，實時處理能力信息可以認為是基于相應(yīng)的 預設(shè)交互對象在當前或某個歷史時間段內(nèi)的表現(xiàn)，預估其對當前存在的數(shù)據(jù)交互需求進行 處理時可能的狀況，比如流暢、延遲、無法處理等。
[0029] 在本實施例中，作為一示例性實施例，可以獲取每一預設(shè)交互對象的預設(shè)能力參 數(shù)的實時數(shù)值，并根據(jù)所述實時數(shù)值所屬的預設(shè)數(shù)值范圍，將該預設(shè)數(shù)值范圍對應(yīng)的能力 等級作為所述實時處理能力信息。其中，任一預設(shè)交互對象的所述預設(shè)能力參數(shù)包括以下 至少之一：
[0030] 單位時間內(nèi)增加的數(shù)據(jù)交互需求數(shù)量、向所述任一預設(shè)交互對象的請求發(fā)起數(shù)量 與響應(yīng)接收數(shù)量之比、每一數(shù)據(jù)交互需求的平均處理時長、剩余的未處理數(shù)據(jù)交互需求數(shù) 量。
[0031] 步驟108,將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。
[0032] 在本實施例中，"關(guān)聯(lián)展示"可以理解為：當多個預設(shè)交互對象同時顯示在終端頁 面上時，用戶在視覺上能夠明確區(qū)分出每一預設(shè)交互對象對應(yīng)的實時處理能力信息。舉例 而言，可以將實時處理能力信息顯示于相應(yīng)的預設(shè)交互對象的關(guān)聯(lián)展示區(qū)域內(nèi)，比如當多 個預設(shè)交互對象顯示為一列時，實時處理能力信息可以與相應(yīng)的預設(shè)交互對象顯示于同一 行。
[0033] 在本實施例中，在已經(jīng)展示出實時處理能力信息的情況下，針對檢測到的用戶對 預設(shè)交互對象的選擇命令，可以執(zhí)行下述處理：
[0034] 作為一示例性實施方式，可以根據(jù)接收到的第一用戶選擇命令，確定被選中的預 設(shè)交互對象；若根據(jù)所述實時處理能力信息，判定所述被選中的預設(shè)交互對象的實時處理 能力低于預設(shè)處理能力，則展示預設(shè)警告信息和操作選項；以及，根據(jù)接收到的針對所述操 作選項的第二用戶選擇命令，取消對所述被選中的預設(shè)交互對象的選擇，或者向所述被選 中的預設(shè)交互對象發(fā)起所述數(shù)據(jù)交互需求。
[0035] 作為另一示例性實施方式，若根據(jù)所述實時處理能力信息，判定所述任一預設(shè)交 互對象的實時處理能力低于預設(shè)處理能力，則可以停止接收向所述任一預設(shè)交互對象發(fā)起 的數(shù)據(jù)交互需求。
[0036] 由上述實施例可知，本申請通過獲取每一預設(shè)交互對象的實時處理能力信息，實 際上是了解到每一預設(shè)交互對象在處理當前檢測到的數(shù)據(jù)交互需求時的預估處理效果，比 如流暢、延遲、無法處理等，從而通過展示每一預設(shè)交互對象的實時處理能力信息，便于用 戶選取恰當?shù)念A設(shè)交互對象，順利實現(xiàn)對數(shù)據(jù)交互需求的處理，有助于提升用戶體驗。
[0037] 如上文所述，本申請的技術(shù)方案可以應(yīng)用于任意類型的數(shù)據(jù)交互需求的處理過程 中；下面以數(shù)據(jù)交互需求為"支付需求"為例，具體說明本申請的技術(shù)方案如何通過對支付 渠道的監(jiān)控，實現(xiàn)對支付需求的處理過程。其中，圖2是根據(jù)本申請一示例性實施例提供的 另一種數(shù)據(jù)交互方法的流程圖，如圖2所示，該方法可以包括以下步驟：
[0038] 步驟202,監(jiān)控渠道的能力參數(shù)。
[0039] 在本實施例中，以圖3所示的應(yīng)用場景示意圖為例，對監(jiān)控渠道能力的過程進行 描述。如圖3所示，假定用戶通過手機APP進行購物的過程中，觸發(fā)了支付需求，則該手機 APP將支付需求發(fā)送至相應(yīng)的服務(wù)器，并從服務(wù)器處獲取每一預設(shè)支付渠道的預設(shè)能力參 數(shù)的實時數(shù)值（以用于進一步確定每一支付渠道對支付需求的實時處理能力信息，即實時 支付能力信息）。比如圖3所示，支付渠道包括A銀行、B銀行、C平臺和D平臺等；其中，支 付渠道是與相應(yīng)的APP關(guān)聯(lián)預設(shè)的，即每個APP對應(yīng)的支付渠道可能存在差異。
[0040] 舉例而言，預設(shè)能力參數(shù)可以包括以下至少之一：單位時間內(nèi)增加的支付需求數(shù) 量、向所述任一預設(shè)支付渠道的請求發(fā)起數(shù)量與響應(yīng)接收數(shù)量之比、每一支付需求的平均 處理時長、剩余的未處理支付需求數(shù)量。
[0041] 其中，"單位時間內(nèi)增加的支付需求數(shù)量"體現(xiàn)了支付需求的增長情況。比如某一 支付渠道的處理能力為m件/單位時間，則當單位時間內(nèi)增加的支付需求數(shù)量n >m時，即 便原本不存在排隊等待處理的支付需求，但新增的支付需求也將導致該支付渠道無法順利 處理掉所有增加的支付需求，造成支付需求的堆積（即排隊等待處理），也就說明該支付渠 道的實時支付處理能力可能較弱。
[0042] "向所述任一預設(shè)支付渠道的請求發(fā)起數(shù)量與響應(yīng)接收數(shù)量之比"：在正常情況 下，針對每個支付需求，由服務(wù)器向支付渠道發(fā)起一次支付請求并接收一次相應(yīng)的響應(yīng)消 息，即請求發(fā)起數(shù)量等于響應(yīng)接收數(shù)量；而當支付渠道異常時，將導致服務(wù)器向支付渠道發(fā) 起的支付請求無法被正常響應(yīng)，從而使得請求發(fā)起數(shù)量遠大于響應(yīng)接收數(shù)量。因此，當請求 發(fā)起數(shù)量大于響應(yīng)接收數(shù)量時，或者當請求發(fā)起數(shù)量超出響應(yīng)接收數(shù)量較多時，說明該支 付渠道的實時支付處理能力可能較弱。
[0043] "每一支付需求的平均處理時長"：當支付需求過多而造成排隊等待處理時，或者 支付渠道異常而導致無法正常處理支付需求時，將導致每一支付需求的平均處理時長增 加，即用戶需求等待更長時間，則說明相應(yīng)的支付渠道的實時支付處理能力可能較弱。
[0044] "剩余的未處理支付需求數(shù)量"：當支付需求數(shù)量小于或等于支付渠道的可處理數(shù) 量時，所有支付需求均會被及時處理，不會存在剩余的未處理支付需求；而當支付需求數(shù)量 增加至大于支付渠道的可處理數(shù)量，或者支付渠道異常時，均可能導致支付需求剩余，且當 剩余的支付需求數(shù)量越多時，說明當前的支付需求可能需要更長的處理時間。
[0045] 在本實施例中，服務(wù)器在監(jiān)控得到每一支付渠道的預設(shè)能力參數(shù)后，可以將該預 設(shè)能力參數(shù)發(fā)送至手機側(cè)，并由手機側(cè)處理得到相應(yīng)的實時支付能力信息；或者，可以由服 務(wù)器直接將預設(shè)能力參數(shù)處理為對應(yīng)的實時支付能力信息，并發(fā)送至手機側(cè)。其中，下述的 步驟204將具體描述預設(shè)能力參數(shù)與實時支付能力信息之間的關(guān)系。
[0046] 在本實施例中，作為一示例性實施方式，服務(wù)器可以周期性地監(jiān)控每一支付渠道 的預設(shè)能力參數(shù)，則當服務(wù)器接收到來自手機側(cè)的支付需求時，可以將最近一次監(jiān)控到的 預設(shè)能力參數(shù)或相應(yīng)的實時支付能力信息反饋給手機側(cè)。或者，作為另一示例性實施方式， 服務(wù)器也可以在接收到來自手機側(cè)的支付需求時，觸發(fā)一次對支付渠道的預設(shè)能力參數(shù)的 監(jiān)控，并將得到的預設(shè)能力參數(shù)或?qū)崟r支付能力信息反饋至手機側(cè)。
[0047] 以用戶在手機上購買"特價電影券"為例。當手機生成或跳轉(zhuǎn)至圖4所示的訂單 支付頁面時，即可生成支付需求并發(fā)送至服務(wù)器，以獲取相應(yīng)的每一支付渠道的預設(shè)能力 參數(shù)或?qū)崟r支付能力信息。
[0048] 步驟204,判定渠道能力。
[0049] 在本實施例中，基于每一支付渠道的預設(shè)能力參數(shù)的實時數(shù)值，可以根據(jù)所述實 時數(shù)值所屬的預設(shè)數(shù)值范圍，將該預設(shè)數(shù)值范圍對應(yīng)的能力等級作為實時支付能力信息。
[0050] 以預設(shè)能力參數(shù)為"剩余的未處理支付需求數(shù)量"為例，假定圖3所示的支付渠道 "A銀行"對應(yīng)的實時數(shù)值如表1所示。
[0051]
[0052] 表 1
[0053] 由表1可知：對于A銀行，由于A銀行對支付需求的處理能力為300次/秒，因而 當剩余的未處理支付需求數(shù)量為〇~1500次時，說明A銀行對當前產(chǎn)生的支付需求的處理 時間為〇~5秒，即無需等待或僅需要短時間等待，對應(yīng)的實時支付能力信息為"流暢"；當 剩余的未處理支付需求數(shù)量為1500~3000次時，A銀行所需要的處理時間為5~10秒， 即當前產(chǎn)生的支付需求需要較長時間等待，對應(yīng)的實時支付能力信息為"延遲"；當當剩余 的未處理支付需求數(shù)量為3000次以上時，A銀行所需要的處理時間大于10秒，即當前產(chǎn)生 的支付需求需要很長時間等待，對應(yīng)的實時支付能力信息為"無法處理"。對于其他支付渠 道，與A銀行類似，此處不再贅述。
[0054] 步驟206，展示渠道能力。
[0055] 如圖4所示，以用戶在手機上對"特價電影券"進行支付為例，則手機支付頁面上 示出了 A銀行、B銀行、C平臺和D平臺等支付渠道，且每一支付渠道的右側(cè)標注了對應(yīng)的實 時支付能力信息，比如A銀行和D平臺對應(yīng)于"空閑"（支付渠道處于"空閑"時，相當于對 支付需求的處理過程為"流暢"）、B銀行對應(yīng)于"擁堵"（支付渠道處于"擁堵"時，相當于 對支付需求的處理過程為"不可處理"）、C平臺對應(yīng)于"繁忙"（支付渠道處于"繁忙"時， 相當于對支付需求的處理過程為"延遲"）。
[0056] 除了采用"空閑"、"繁忙"和"擁堵"等文字，還可以采用圖案等其他類型的標識， 或者多種標識的組合。如圖5所示，可以同時通過文字和圖案來標示出每一支付渠道對應(yīng) 的實時支付能力信息，比如"空閑"和"笑臉"圖案，或者"擁堵"和"哭臉"圖案。當然，本申 請并不對實時支付能力信息的標示形式進行限制。
[0057] 此外，當預設(shè)交互對象的實時處理能力信息不同時，針對用戶操作而導致的處理 方式也存在差異。下面以圖5所示的支付頁面為例，進行具體說明。
[0058] 如圖6 (a)所示，當用戶點擊D平臺右側(cè)的圓形控件時，即發(fā)出了對D平臺的選擇 操作。由于D平臺的實時支付能力信息為"空閑"，即能夠流暢地處理當前產(chǎn)生的支付需求， 則如圖6(b)所示，用戶能夠順利完成對D平臺的選擇操作，以及后續(xù)的付款操作。
[0059] 如圖7(a)所示，當用戶點擊B銀行右側(cè)的圓形控件時，即發(fā)出了對B銀行的第一 用戶選擇命令。由于B銀行的實時支付能力信息為"擁堵"，即無法正常處理當前產(chǎn)生的支 付需求，需要用戶長時間等待，則如圖7 (b)所示，可以展示預設(shè)警告信息"您當前選取的支 付渠道十分擁堵，可能造成長時間等待或支付失敗，推薦您選擇其他支付渠道！"，以及操 作選項"繼續(xù)"和"返回";根據(jù)接收到的針對操作選項的第二用戶選擇命令，若用戶選擇"繼 續(xù)"，則向B銀行發(fā)起支付需求，若用戶選擇"返回"，則取消對B銀行的選擇。
[0060] 當然，若根據(jù)實時支付能力信息，判定任一預設(shè)支付渠道的實時支付能力低于預 設(shè)支付能力（比如預設(shè)支付能力為"繁忙"），比如實時支付能力為"擁堵"的B銀行，那么為 了避免當前用戶的支付體驗受到影響，也避免對其他已經(jīng)選用了 B銀行的用戶造成影響， 可以停止接收向該任一預設(shè)支付渠道發(fā)起的支付需求。比如圖8所示，停止向用戶提供對 B銀行的選項按鈕；而用戶可以通過點擊"為什么不可用"，查看相應(yīng)的原因和理由，避免用 戶不理解而造成的支付體驗降低。
[0061] 圖9示出了根據(jù)本申請的一示例性實施例的電子設(shè)備的示意結(jié)構(gòu)圖。請參考圖9， 在硬件層面，該電子設(shè)備包括處理器、內(nèi)部總線、網(wǎng)絡(luò)接口、內(nèi)存以及非易失性存儲器，當然 還可能包括其他業(yè)務(wù)所需要的硬件。處理器從非易失性存儲器中讀取對應(yīng)的計算機程序到 內(nèi)存中然后運行，在邏輯層面上形成數(shù)據(jù)交互裝置。當然，除了軟件實現(xiàn)方式之外，本申請 并不排除其他實現(xiàn)方式，比如邏輯器件抑或軟硬件結(jié)合的方式等等，也就是說以下處理流 程的執(zhí)行主體并不限定于各個邏輯單元，也可以是硬件或邏輯器件。
[0062] 請參考圖10,在軟件實施方式中，該數(shù)據(jù)交互裝置可以包括檢測單元、確定單元、 獲取單元和展示單元。其中：
[0063] 檢測單元，檢測到數(shù)據(jù)交互需求；
[0064] 確定單元，確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象；
[0065] 獲取單元，獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息；
[0066] 展示單元，將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。
[0067] 可選的，所述獲取單元具體用于：
[0068] 獲取每一預設(shè)交互對象的預設(shè)能力參數(shù)的實時數(shù)值；
[0069] 根據(jù)所述實時數(shù)值所屬的預設(shè)數(shù)值范圍，將該預設(shè)數(shù)值范圍對應(yīng)的能力等級作為 所述實時處理能力信息。
[0070] 可選的，任一預設(shè)交互對象的所述預設(shè)能力參數(shù)包括以下至少之一：
[0071] 單位時間內(nèi)增加的數(shù)據(jù)交互需求數(shù)量、向所述任一預設(shè)交互對象的請求發(fā)起數(shù)量 與響應(yīng)接收數(shù)量之比、每一數(shù)據(jù)交互需求的平均處理時長、剩余的未處理數(shù)據(jù)交互需求數(shù) 量。
[0072] 可選的，還包括：
[0073] 對象選擇單元，根據(jù)接收到的第一用戶選擇命令，確定被選中的預設(shè)交互對象；
[0074] 警告單元，若根據(jù)所述實時處理能力信息，判定所述被選中的預設(shè)交互對象的實 時處理能力低于預設(shè)處理能力，則展示預設(shè)警告信息和操作選項；以及
[0075] 選擇處理單元，根據(jù)接收到的針對所述操作選項的第二用戶選擇命令，取消對所 述被選中的預設(shè)交互對象的選擇，或者向所述被選中的預設(shè)交互對象發(fā)起所述數(shù)據(jù)交互需 求。
[0076] 可選的，還包括：
[0077] 請求管理單元，若根據(jù)所述實時處理能力信息，判定所述任一預設(shè)交互對象的實 時處理能力低于預設(shè)處理能力，則停止接收向所述任一預設(shè)交互對象發(fā)起的數(shù)據(jù)交互需 求。
[0078] 可選的，所述數(shù)據(jù)交互需求為支付需求，所述預設(shè)交互對象為支付渠道。
[0079] 在一個典型的配置中，計算設(shè)備包括一個或多個處理器（CPU)、輸入/輸出接口、 網(wǎng)絡(luò)接口和內(nèi)存。
[0080] 內(nèi)存可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器（RAM)和/ 或非易失性內(nèi)存等形式，如只讀存儲器（ROM)或閃存（flash RAM)。內(nèi)存是計算機可讀介質(zhì) 的示例。
[0081] 計算機可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法 或技術(shù)來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。 計算機的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存（PRAM)、靜態(tài)隨機存取存儲器（SRAM)、 動態(tài)隨機存取存儲器（DRAM)、其他類型的隨機存取存儲器（RAM)、只讀存儲器（ROM)、電 可擦除可編程只讀存儲器（EEPR0M)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器 (CD-ROM)、數(shù)字多功能光盤（DVD)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁 性存儲設(shè)備或任何其他非傳輸介質(zhì)，可用于存儲可以被計算設(shè)備訪問的信息。按照本文中 的界定，計算機可讀介質(zhì)不包括暫存電腦可讀媒體（transitory media)，如調(diào)制的數(shù)據(jù)信 號和載波。
[0082] 還需要說明的是，術(shù)語"包括"、"包含"或者其任何其他變體意在涵蓋非排他性的 包含，從而使得包括一系列要素的過程、方法、商品或者設(shè)備不僅包括那些要素，而且還包 括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設(shè)備所固有的要 素。在沒有更多限制的情況下，由語句"包括一個……"限定的要素，并不排除在包括所述 要素的過程、方法、商品或者設(shè)備中還存在另外的相同要素。
[0083] 以上所述僅為本申請的較佳實施例而已，并不用以限制本申請，凡在本申請的精 神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本申請保護的范圍之內(nèi)。
【主權(quán)項】
1. 一種數(shù)據(jù)交互方法，其特征在于，包括： 檢測到數(shù)據(jù)交互需求； 確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象； 獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息； 將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述獲取每一預設(shè)交互對象對所述數(shù)據(jù) 交互需求的實時處理能力信息，包括： 獲取每一預設(shè)交互對象的預設(shè)能力參數(shù)的實時數(shù)值； 根據(jù)所述實時數(shù)值所屬的預設(shè)數(shù)值范圍，將該預設(shè)數(shù)值范圍對應(yīng)的能力等級作為所述 實時處理能力信息。3. 根據(jù)權(quán)利要求2所述的方法，其特征在于，任一預設(shè)交互對象的所述預設(shè)能力參數(shù) 包括以下至少之一： 單位時間內(nèi)增加的數(shù)據(jù)交互需求數(shù)量、向所述任一預設(shè)交互對象的請求發(fā)起數(shù)量與響 應(yīng)接收數(shù)量之比、每一數(shù)據(jù)交互需求的平均處理時長、剩余的未處理數(shù)據(jù)交互需求數(shù)量。4. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 根據(jù)接收到的第一用戶選擇命令，確定被選中的預設(shè)交互對象； 若根據(jù)所述實時處理能力信息，判定所述被選中的預設(shè)交互對象的實時處理能力低于 預設(shè)處理能力，則展示預設(shè)警告信息和操作選項；以及 根據(jù)接收到的針對所述操作選項的第二用戶選擇命令，取消對所述被選中的預設(shè)交互 對象的選擇，或者向所述被選中的預設(shè)交互對象發(fā)起所述數(shù)據(jù)交互需求。5. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括： 若根據(jù)所述實時處理能力信息，判定所述任一預設(shè)交互對象的實時處理能力低于預設(shè) 處理能力，則停止接收向所述任一預設(shè)交互對象發(fā)起的數(shù)據(jù)交互需求。6. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述數(shù)據(jù)交互需求為支付需求，所述預設(shè) 交互對象為支付渠道。7. -種數(shù)據(jù)交互裝置，其特征在于，包括： 檢測單元，檢測到數(shù)據(jù)交互需求； 確定單元，確定支持所述數(shù)據(jù)交互需求的所有預設(shè)交互對象； 獲取單元，獲取每一預設(shè)交互對象對所述數(shù)據(jù)交互需求的實時處理能力信息； 展示單元，將每一預設(shè)交互對象與相應(yīng)的實時處理能力信息進行關(guān)聯(lián)展示。8. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，所述獲取單元具體用于： 獲取每一預設(shè)交互對象的預設(shè)能力參數(shù)的實時數(shù)值； 根據(jù)所述實時數(shù)值所屬的預設(shè)數(shù)值范圍，將該預設(shè)數(shù)值范圍對應(yīng)的能力等級作為所述 實時處理能力信息。9. 根據(jù)權(quán)利要求8所述的裝置，其特征在于，任一預設(shè)交互對象的所述預設(shè)能力參數(shù) 包括以下至少之一： 單位時間內(nèi)增加的數(shù)據(jù)交互需求數(shù)量、向所述任一預設(shè)交互對象的請求發(fā)起數(shù)量與響 應(yīng)接收數(shù)量之比、每一數(shù)據(jù)交互需求的平均處理時長、剩余的未處理數(shù)據(jù)交互需求數(shù)量。10. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，還包括： 對象選擇單元，根據(jù)接收到的第一用戶選擇命令，確定被選中的預設(shè)交互對象； 警告單元，若根據(jù)所述實時處理能力信息，判定所述被選中的預設(shè)交互對象的實時處 理能力低于預設(shè)處理能力，則展示預設(shè)警告信息和操作選項；以及 選擇處理單元，根據(jù)接收到的針對所述操作選項的第二用戶選擇命令，取消對所述被 選中的預設(shè)交互對象的選擇，或者向所述被選中的預設(shè)交互對象發(fā)起所述數(shù)據(jù)交互需求。11. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，還包括： 請求管理單元，若根據(jù)所述實時處理能力信息，判定所述任一預設(shè)交互對象的實時處 理能力低于預設(shè)處理能力，則停止接收向所述任一預設(shè)交互對象發(fā)起的數(shù)據(jù)交互需求。12. 根據(jù)權(quán)利要求7所述的裝置，其特征在于，所述數(shù)據(jù)交互需求為支付需求，所述預 設(shè)交互對象為支付渠道。
【文檔編號】G06F3/0484GK106033304SQ201510122756
【公開日】2016年10月19日
【申請日】2015年3月19日
【發(fā)明人】金堅偉
【申請人】阿里巴巴集團控股有限公司