基于通知的流式交互系統(tǒng)和方法
【專利摘要】本發(fā)明涉及一種基于通知的流式交互方法，包括以下步驟：步驟1、接收第一消息，并進入與所述第一消息對應的第一界面，所述第一消息包含第一業(yè)務請求；步驟2、在所述第一界面中，根據(jù)所述第一業(yè)務請求進行第一業(yè)務處理操作，得到第一處理結果；步驟3、接收第三消息，并進入與所述第三消息對應的第二界面，所述第三消息包含第二業(yè)務請求；步驟4、在所述第二界面中，根據(jù)所述第一處理結果及所述第二業(yè)務請求進行第二業(yè)務處理操作，得到第二處理結果；步驟5、接收業(yè)務處理通知，其包括指示所述第一處理結果的第二消息、和/或指示第二處理結果的第四消息。
【專利說明】
基于通知的流式交互系統(tǒng)和方法
技術領域
[0001]本發(fā)明涉及人機交互技術領域，尤其涉及一種基于通知的流式交互系統(tǒng)和方法。
【背景技術】
[0002]在整個交互系統(tǒng)中，存在很多交互對象，可以通過通知進入相應的交互界面。圖1是示出了依據(jù)現(xiàn)有方式的界面和通知關系的圖。如圖1所示，現(xiàn)在的通知(消息)是離散的，各個通知之間是獨立的，相互沒有統(tǒng)籌沒有聯(lián)系。以打車軟件為例，比如用戶手機彈出一個通知1(您有一個訂單消息)，但是這個通知I僅是一個入口，用戶點進去后才進入交互界面A，處理這個訂單，從這個通知I中只能看到表象的信息。對于業(yè)務進度、狀態(tài)無從獲知。有的可能已經(jīng)處理過了，有的可能不想處理。比如用戶覺得第一訂單不好，又換了一個新的訂單，那么第一個訂單消息(通知I)其實就是無效的了，但這個通知I依然存在，只不過會又彈出第二訂單消息(通知2)，來使用戶進行界面B，然后可能還有通知3來使用戶進入界面C。這種通知模式使得用戶需要對可能實際已經(jīng)沒有意義的通知作出響應，增加了用戶的負擔，從而導致對用戶不夠友好。

【發(fā)明內容】

[0003]本發(fā)明針對現(xiàn)有技術的不足作出，用以解決或克服現(xiàn)有技術的一個或更多個缺點，至少提供一種有益的選擇。
[0004]根據(jù)本發(fā)明的一個方面，提供了一種基于通知的流式交互方法，包括以下步驟:步驟1、接收第一消息，并進入與所述第一消息對應的第一界面，所述第一消息包含第一業(yè)務請求;步驟2、在所述第一界面中，根據(jù)所述第一業(yè)務請求進行第一業(yè)務處理操作，得到第一處理結果;步驟3、接收第三消息，并進入與所述第三消息對應的第二界面，所述第三消息包含第二業(yè)務請求;步驟4、在所述第二界面中，根據(jù)所述第一處理結果及所述第二業(yè)務請求進行第二業(yè)務處理操作，得到第二處理結果;步驟5、接收業(yè)務處理通知，其包括指示所述第一處理結果的第二消息、和/或指示第二處理結果的第四消息。
[0005]本發(fā)明的交互系統(tǒng)有益效果在于:對業(yè)務進行了時間或空間(業(yè)務)維度的整理(聚合)，打破了傳統(tǒng)的離散型狀態(tài)。
【附圖說明】
[0006]圖1是示出了依據(jù)現(xiàn)有方式的界面和通知關系的圖；
[0007]圖2是示出了依據(jù)本發(fā)明的一種實施方式的技術方案的整體構思的圖；
[0008]圖3示出了業(yè)務類型的分類；
[0009]圖4示出了各應用中，隨時間推移對應的交互業(yè)務；
[0010]圖5示出了依據(jù)本發(fā)明的一種實施方式的交互方法的流程圖；
[0011]圖6示出了依據(jù)本發(fā)明的消息和通知處理的狀態(tài)圖；以及
[0012]圖7示出了依據(jù)本發(fā)明一種實施方式的人機交互系統(tǒng)的框圖。
【具體實施方式】
[0013]下面結合附圖對本發(fā)明的技術方案進行詳細描述。
[0014]圖2示出了依據(jù)本發(fā)明的一種實施方式的技術方案的整體構思。如圖2所示，整個交互系統(tǒng)由多個交互界面串聯(lián)而成，每個交互界面可以看成一個交互業(yè)務，而每個交互界面又由多個交互子界面組成，比如訂餐的交互就至少包括與運營商的交互、與商家的交互、與物流的交互等等。通知是進入交互界面的入口，屏幕彈出一個通知，點一下就進入界面了。通知消息例如為“您預定的外賣已送達”，點這個通知，就可以查看訂單消息等，還可以進一步操作，取消訂單等。
[0015]隨著時間推移進行著不同的交互(圖2上部)。多個交互業(yè)務串聯(lián)起來構成交互系統(tǒng)的整體(圖2下部)。
[0016]首先，以同一應用(APP)在不同交互場景(不同界面)下聯(lián)動的情況作為示例進行說明。
[0017]以基于移動終端的訂餐應用為例，在9點的時候，用戶通過在移動終端上點擊某個消息(第一消息)、或者從主界面直接進入該訂餐應用的選擇餐館界面A(第一界面)。在進入應用之后，可適時清除第一消息。
[0018]用戶在第一界面選定餐館之后，在9點30通過第二消息進入選菜界面B(第二界面)。
[0019]用戶在第二界面選菜之后，在9點40通過第三消息進入付款界面C(第三界面)。
[0020]用戶在第三界面付款之后完成整個訂餐流程。界面A、B、C就是隨著時間推移而串聯(lián)構成的交互業(yè)務，整個服務響應系統(tǒng)構成交互系統(tǒng)。
[0021]具體地，第二消息提示用戶已經(jīng)完成餐館選擇，應盡快(例如，設定10分鐘的有效期)進入選菜界面，即，第二界面。在用戶進入第二界面選菜之后，或者，在經(jīng)過10分鐘的有效期之后，第二消息應當被清除。
[0022]同樣地，第三消息提示用戶已經(jīng)完成選菜選擇，應盡快(例如，設定10分鐘的有效期)進入付款界面，即，第三界面。在用戶進入第三界面付款之后，或者，在經(jīng)過10分鐘的有效期之后，第三消息應當被清除。最后，通過該應用、或者其它手段，可生成第四消息，其指示用戶在第一至第三界面中完成的各個選擇的情況，即，基于用戶在各個階段操作的結果，來顯示餐館、菜品、付款情況。這樣，用戶可以通過單一的第四消息而掌握整個訂餐業(yè)務流程中的細節(jié)，同時不會受到之前的第一至第三消息的干擾。
[0023]另一方面，在同一個界面上，S卩，在業(yè)務流程的每個階段，用戶可進行不同的選擇，例如，用戶在選菜界面B上，9點31分選擇了湘菜，9點35分又選擇了粵菜，9點37分又選擇了川菜等?；谂c上面所述類似的原理，用戶的新選擇會對較早的選擇產(chǎn)生影響，例如，可僅保留與最后的選擇有關的消息，而清除其余消息。
[0024]此外，本發(fā)明的交互系統(tǒng)可以針對同類或不同類的交互業(yè)務。圖3示出了業(yè)務類型的分類。如圖3所示，交互系統(tǒng)可以針對房產(chǎn)服務(例如，房屋買賣、租賃)、叫車服務(例如，出租車、專車等)等各種服務以及這些服務的組合。在各交互系統(tǒng)中，客戶(客戶端的用戶)為甲，其交互對象分別為乙、丙、丁。乙、丙、丁可對應于不同的應用，也可以分別對應不同的業(yè)務類型。
[0025]下面，以不同應用(APP)或不同業(yè)務在不同交互場景(不同界面)下聯(lián)動的情況作為示例進行說明。
[0026]圖4示出了在各應用或業(yè)務(乙、丙、丁)中隨時間推移對應的會話過程。圖4中，在房產(chǎn)及叫車應用中隨著時間的推移分別對應進行著不同的交互業(yè)務。比如，以叫車服務為例，在前一時刻甲與乙進行著交互，當中間時刻，甲與丙進行了交互，當后一時刻，甲又與丁進行了交互。
[0027]基于與上面所述類似的原理，用戶的新操作結果會對較早的操作結果產(chǎn)生影響，例如，用戶在有效時間(例如，可設定為1分鐘)內，通過多個不同的應用(例如，應用1、應用
2)分別叫車。之后，這兩個應用先后返回兩個叫車結果。這時，系統(tǒng)(本發(fā)明的流式交互系統(tǒng))可通過對這兩個叫車結果(車輛、司機、價格等情況)進行比對，而向用戶提供消息，其中提示這兩個叫車結果中的優(yōu)選結果。用戶可響應該消息而直接進入與優(yōu)選結果對應的應用I，進行下一步的操作。另一方面，清除與應用2有關的消息，和/或退出應用2，和/或關閉應用2的進程。
[0028]可以理解，系統(tǒng)進行上述比對的邏輯，可基于云端或本地的歷史/經(jīng)驗數(shù)據(jù)，也可結合用戶設定的偏好，等等。
[0029]可以理解，上述多個不同的應用也可以是不同業(yè)務類型的應用，例如，叫車應用、訂餐應用。系統(tǒng)仍可基于類似原理而進行處理。這將在下面舉例描述。
[0030]圖5示出了依據(jù)本發(fā)明的一種實施方式的交互方法的流程圖。如圖5所示，依據(jù)本發(fā)明的一種實施方式，一種交互方法包括:
[0031](I)步驟501，在用戶界面上顯示業(yè)務提示通知；對業(yè)務提示通知的實現(xiàn)可以是界面上的彈出窗口，也可以是短信通知，也可以是在界面上的圖標或按鈕。這種通知例如“現(xiàn)在正在進行優(yōu)惠活動，請點擊以下鏈接”等，這樣的通知可能有一個或更多個。
[0032](2)步驟502，接收用戶根據(jù)所述通知進入業(yè)務處理界面后第一時間所提供的第一消息;對于訂餐信息，該第一消息例如是提交的餐館消息、定菜消息、付費信息消息等;例如定菜信息包括所定的菜為川菜的信息。
[0033](3)步驟503，接收用戶進入業(yè)務處理界面后第二時間所提供的第二消息；該第二消息和第一消息不同。對于訂餐服務，該第二消息例如是提交的餐館消息、定菜消息、付費信息消息等;該第二消息與第一消息有所不同，例如在該第二消息中，定菜信息包括所定的菜為粵菜的信息。由于第一消息中，所定的菜為川菜，因而第二消息與第一消息不同。
[0034](4)步驟504，根據(jù)第二消息對第二信息和第一信息兩者進行業(yè)務處理。在現(xiàn)有技術中，由于各消息和通知之間是離散(不相關聯(lián))的，因而在收到第二消息之后，會僅僅針對第二消息進行處理，而不會理會第一消息，因而針對第一消息的處理結果還會保留在那里，而實際上該第一消息及其處理結果可能已經(jīng)不再有效。而根據(jù)本發(fā)明的一種實施方式，不僅對第二消息進行處理，而且根據(jù)第二消息對第一消息進行處理，因而可以保證第一消息的處理結果是當前有效的，而不是過時的。
[0035]另外，根據(jù)第二消息對第一消息進行處理，可以是針對來自不同應用的消息。例如，當接收在11:30接收到訂餐消息，在11:50接收到叫車消息時，根據(jù)該叫車消息可以產(chǎn)生諸如“您已于11:30進行了叫餐服務，又于11:50進行了叫車服務，所叫的餐未必能夠在11:
50到達，恐怕影響您的出行，是取消訂餐還是延后叫車，還是按照目前的計劃進行?”的處理結果消息。也就是說，系統(tǒng)通過邏輯比較，能夠發(fā)現(xiàn)不同應用或者不同業(yè)務之間潛在的沖突，這種沖突僅對用戶可見，用戶可自主進行處理，以免造成不便。
[0036](5)步驟505，向用戶發(fā)送業(yè)務處理通知，該業(yè)務處理通知包括了對第一消息和第二消息兩者進行處理后的結果。比如“您11:30在本餐廳定的粵菜菜系套餐已經(jīng)下單，請在12:00到達。同時您11:00所定的川菜菜系套餐已經(jīng)取消。詳情請參見以下鏈接”等等。
[0037]應該注意，本文所給出的消息和通知的內容和類型僅僅是示例性的，不是對本發(fā)明的保護范圍的限制。
[0038]在現(xiàn)有技術中，由于各消息和通知之間是離散的，因而在收到第二消息之后，會僅僅針對第二消息進行處理，而不會理會第一消息，因而針對第一消息的處理結果還會保留在那里，當客戶收到通知進行查看時，還會發(fā)現(xiàn)對第一消息的處理結果，例如在上面的情況下，客戶在接收到通知進行查看時，會發(fā)現(xiàn):
[0039]您有兩個訂單:
[0040]1、第一訂單:J11菜菜系套餐，下單時間:11:00，狀態(tài):未支付。
[0041 ] 2、第二訂單:粵菜菜系套餐，下單時間:11:30，狀態(tài):已支付。
[0042]或者類似的交互內容。
[0043]相比之下，根據(jù)本發(fā)明的實施例，由于各消息和通知之間是關聯(lián)的，因而當客戶收到通知進入界面進行查看時，將不會發(fā)現(xiàn)對第一消息的處理結果?？梢园l(fā)現(xiàn)以下的交互內容:
[0044]您的訂單情況如下:
[0045]粵菜菜系套餐，下單時間:11:30，狀態(tài):已支付。
[0046]因而，根據(jù)本發(fā)明，在向用戶發(fā)送通知時，不但發(fā)送對第二消息的處理結果，而且包括對第一消息的處理結果。在對第二消息進行處理時，不但考慮第二消息本身的內容，對第二消息進行處理，而且考慮第二消息的內容對第一消息進行處理(例如，根據(jù)第二消息的內容，刪除(不顯示)第一消息)。這樣可以方便用戶了解當前的情況，不致產(chǎn)生不必要的懷疑或者浪費時間。
[0047]進一步，在現(xiàn)有技術中，還不能將來自不同應用的消息進行有機的組合，這些消息都是離散的，而根據(jù)本發(fā)明將能夠實現(xiàn)這種組合，能夠實現(xiàn)通知在不同應用之間的統(tǒng)籌。
[0048]根據(jù)另一種實施方式，當接收到第一消息的第一時間和接收到第二消息的第二時間相差超過閾值時，將不再根據(jù)第二消息的內容對第一消息處理。
[0049]根據(jù)再一種實施方式，當接收到第一消息的第一時間和接收到第二消息的第二時間相差超過閾值時，將直接取消第一消息以及對第一消息已經(jīng)進行的處理。
[0050]根據(jù)又一種實施方式，當接收到第二消息時，還根據(jù)該第二信息和第一信息進行數(shù)據(jù)統(tǒng)計，并可將數(shù)據(jù)統(tǒng)計結果通過通知發(fā)送給用戶。
[0051]根據(jù)本發(fā)明的又另一種實施方式，可以根據(jù)用戶興趣點的高低來設定推送通知的優(yōu)先級。并根據(jù)優(yōu)先級確定是否進行消息的推送。
[0052]根據(jù)本發(fā)明的再又一種實施方式，所述第二消息和第一消息來自相關聯(lián)的第一界面和第二界面。例如對于點菜交互系統(tǒng)而言，可能包括選擇餐館界面、選擇菜譜套餐界面、支付界面這三個界面，用戶可能在第一時間在第一界面選擇了川菜館，發(fā)送了第一消息，然后退出了程序。在第二時間在第一界面選擇了粵菜館，并選擇了粵菜套餐A，并發(fā)出了消息。在這種情況下，可以根據(jù)第二消息取消第一消息所選擇的川菜館。
[0053]圖6示出了依據(jù)本發(fā)明的消息和通知處理的狀態(tài)圖。因而根據(jù)本發(fā)明的實施方式，如圖6所示，消息和通知是有狀態(tài)的，對于處于有效期內的，可以將狀態(tài)反映給用戶，無效的可以不顯示或自動關閉業(yè)務入口，還可以將各業(yè)務狀態(tài)流程式的匯總，顯得有條理，整個業(yè)務流程及狀態(tài)不再是離散的。業(yè)務之間關聯(lián)后，可以進行靈活調整。
[0054]圖7示出了依據(jù)本發(fā)明一種實施方式的人機交互系統(tǒng)。如圖7所示，依據(jù)本發(fā)明的一種實施方式，一種人機交互系統(tǒng)包括通知推送單元701、消息接收單元702和業(yè)務處理單元703。
[0055]通知推送單元701可以發(fā)送業(yè)務提示通知以及業(yè)務處理通知。消息接收單元702可以在第一時間接收來自第一界面的第一消息，并在第二時間接收來自第二界面的第二消息。業(yè)務處理單元703可以根據(jù)第二消息對第一消息和第二消息兩者進行處理。
[0056]這些模塊701-703的處理可以參見前面對方法的描述。例如根據(jù)本發(fā)明的一種實施方式，可以設置計時器或計算器，對于接收第一消息的第一時間和接收第二消息的第二時間之間的時間差進行計算，從而決定如何對第一消息進行處理。
[0057]可以根據(jù)需要設置統(tǒng)計單元、推送優(yōu)先級確定單元以實現(xiàn)前述方法中的相應步驟。
[0058]在本發(fā)明中，可以對各個業(yè)務設置業(yè)務號來彼此進行區(qū)分。業(yè)務號可以反映當前業(yè)務的業(yè)務類型，業(yè)務處理單元可以收集用戶對不同類型的業(yè)務處理的敏感度(偏好)從而設置通知推送的優(yōu)先級。
[0059]根據(jù)本發(fā)明的實施方式，實現(xiàn)了交互系統(tǒng)交互業(yè)務的整合，可以將業(yè)務的狀態(tài)信息處理結果反映給通知，構建業(yè)務處理流程的閉環(huán)，從而實現(xiàn)業(yè)務的完整響應。本發(fā)明可以將完整的業(yè)務狀態(tài)反饋給通知，可以構成整個交互系統(tǒng)中業(yè)務的完整響應，構成交互業(yè)務處理的閉環(huán)。本發(fā)明的交互系統(tǒng)對業(yè)務進行了時間及空間維度的整理，打破了傳統(tǒng)的離散型狀態(tài)。
【主權項】
1.一種基于通知的流式交互方法，包括以下步驟: 步驟1、接收第一消息，并進入與所述第一消息對應的第一界面，所述第一消息包含第一業(yè)務請求； 步驟2、在所述第一界面中，根據(jù)所述第一業(yè)務請求進行第一業(yè)務處理操作，得到第一處理結果； 步驟3、接收第三消息，并進入與所述第三消息對應的第二界面，所述第三消息包含第二業(yè)務請求； 步驟4、在所述第二界面中，根據(jù)所述第一處理結果及所述第二業(yè)務請求進行第二業(yè)務處理操作，得到第二處理結果； 步驟5、接收業(yè)務處理通知，其包括指示所述第一處理結果的第二消息、和/或指示第二處理結果的第四消息。2.根據(jù)權利要求1所述的方法，其特征在于，所述第一界面和所述第二界面為展現(xiàn)內容彼此有關的界面，其中， 所述第一界面和所述第二界面為同一應用或者不同應用的界面。3.根據(jù)權利要求1所述的方法，其中， 在進入所述第一界面之后，清除所述第一消息， 在進入所述第二界面之后，清除所述第三消息。4.根據(jù)權利要求1所述的方法，其特征在于，所述第一消息、第二消息、第三消息、第四消息分別包含有效期標記，所述有效期標記用于所述各個消息的有效期。5.根據(jù)權利要求4所述的方法，在步驟3之后還包括: 步驟3-1、根據(jù)有效期標記所指示的所述第一消息的有效期，和/或根據(jù)所述第一消息和所述第三消息的接收時刻，來確定是否清除所述第一消息。6.根據(jù)權利要求5所述的方法，其特征在于，在步驟3-1中，在當前時刻已經(jīng)過了第一消息的有效期的到期時刻的情況下，或者，在第一消息的接收時刻與第三消息的接收時刻之間的時長大于預定時間閾值的情況下，清除第一消息。7.根據(jù)權利要求5所述的方法，其特征在于，在步驟3-1中，在第一消息的接收時刻與第三消息的接收時刻之間的時長大于預定時間閾值的情況下，跳過后續(xù)步驟4和5。8.根據(jù)權利要求1所述的方法，其特征在于，在所述方法進行的過程中，服務端同時還監(jiān)測業(yè)務請求響應效率，根據(jù)所述響應效率來設定推送所述各個消息的優(yōu)先級順序。9.根據(jù)權利要求8所述的方法，其特征在于，第一業(yè)務請求和第二業(yè)務請求具有不同的業(yè)務類別， 并且，在所述方法進行的過程中，服務端同時還監(jiān)測第一業(yè)務請求和第二業(yè)務請求所對應的不同類別的業(yè)務的響應效率，按照業(yè)務類別及響應效率設定推送所述各個消息的優(yōu)先級順序。10.—種用于執(zhí)行根據(jù)權利要求1至9中的任一個所述的方法的基于通知的流式交互系統(tǒng)，包括: 消息接收單元，用于接收第一消息，并進入與所述第一消息對應的第一界面，所述第一消息包含第一業(yè)務請求； 業(yè)務處理單元，用于在所述第一界面中，根據(jù)所述第一業(yè)務請求進行第一業(yè)務處理操作，得到第一處理結果； 其中，消息接收單元還用于接收第三消息，并進入與所述第三消息對應的第二界面，所述第三消息包含第二業(yè)務請求， 其中，業(yè)務處理單元還用于在所述第二界面中，根據(jù)所述第一處理結果及所述第二業(yè)務請求進行第二業(yè)務處理操作，得到第二處理結果， 其中，消息接收單元還用于接收業(yè)務處理通知，其包括指示所述第一處理結果的第二消息、和/或指示第二處理結果的第四消息。
【文檔編號】G06F3/0481GK105871692SQ201610320150
【公開日】2016年8月17日
【申請日】2016年5月13日
【發(fā)明人】李天白
【申請人】北京思源置地科技有限公司