CN105871692B - 基于通知的流式交互系统和方法 - Google Patents

Abstract

本发明涉及一种基于通知的流式交互方法，包括以下步骤：步骤1、接收第一消息，并进入与所述第一消息对应的第一界面，所述第一消息包含第一业务请求；步骤2、在所述第一界面中，根据所述第一业务请求进行第一业务处理操作，得到第一处理结果；步骤3、接收第三消息，并进入与所述第三消息对应的第二界面，所述第三消息包含第二业务请求；步骤4、在所述第二界面中，根据所述第一处理结果及所述第二业务请求进行第二业务处理操作，得到第二处理结果；步骤5、接收业务处理通知，其包括指示所述第一处理结果的第二消息、和/或指示第二处理结果的第四消息。

Description

基于通知的流式交互系统和方法

技术领域

本发明涉及人机交互技术领域，尤其涉及一种基于通知的流式交互系统和方法。

背景技术

在整个交互系统中，存在很多交互对象，可以通过通知进入相应的交互界面。图1是示出了依据现有方式的界面和通知关系的图。如图1所示，现在的通知(消息)是离散的，各个通知之间是独立的，相互没有统筹没有联系。以打车软件为例，比如用户手机弹出一个通知1(您有一个订单消息)，但是这个通知1仅是一个入口，用户点进去后才进入交互界面A，处理这个订单，从这个通知1中只能看到表象的信息。对于业务进度、状态无从获知。有的可能已经处理过了，有的可能不想处理。比如用户觉得第一订单不好，又换了一个新的订单，那么第一个订单消息(通知1)其实就是无效的了，但这个通知1依然存在，只不过会又弹出第二订单消息(通知2)，来使用户进行界面B，然后可能还有通知3来使用户进入界面C。这种通知模式使得用户需要对可能实际已经没有意义的通知作出响应，增加了用户的负担，从而导致对用户不够友好。

发明内容

本发明针对现有技术的不足作出，用以解决或克服现有技术的一个或更多个缺点，至少提供一种有益的选择。

根据本发明的一个方面，提供了一种基于通知的流式交互方法，包括以下步骤：步骤1、接收第一消息，并进入与所述第一消息对应的第一界面，所述第一消息包含第一业务请求；步骤2、在所述第一界面中，根据所述第一业务请求进行第一业务处理操作，得到第一处理结果；步骤3、接收第三消息，并进入与所述第三消息对应的第二界面，所述第三消息包含第二业务请求；步骤4、在所述第二界面中，根据所述第一处理结果及所述第二业务请求进行第二业务处理操作，得到第二处理结果；步骤5、接收业务处理通知，其包括指示所述第一处理结果的第二消息、和/或指示第二处理结果的第四消息。

本发明的交互系统有益效果在于：对业务进行了时间或空间(业务)维度的整理(聚合)，打破了传统的离散型状态。

附图说明

图1是示出了依据现有方式的界面和通知关系的图；

图2是示出了依据本发明的一种实施方式的技术方案的整体构思的图；

图3示出了业务类型的分类；

图4示出了各应用中，随时间推移对应的交互业务；

图5示出了依据本发明的一种实施方式的交互方法的流程图；

图6示出了依据本发明的消息和通知处理的状态图；以及

图7示出了依据本发明一种实施方式的人机交互系统的框图。

具体实施方式

下面结合附图对本发明的技术方案进行详细描述。

图2示出了依据本发明的一种实施方式的技术方案的整体构思。如图2所示，整个交互系统由多个交互界面串联而成，每个交互界面可以看成一个交互业务，而每个交互界面又由多个交互子界面组成，比如订餐的交互就至少包括与运营商的交互、与商家的交互、与物流的交互等等。通知是进入交互界面的入口，屏幕弹出一个通知，点一下就进入界面了。通知消息例如为“您预定的外卖已送达”，点这个通知，就可以查看订单消息等，还可以进一步操作，取消订单等。

随着时间推移进行着不同的交互(图2上部)。多个交互业务串联起来构成交互系统的整体(图2下部)。

首先，以同一应用(APP)在不同交互场景(不同界面)下联动的情况作为示例进行说明。

以基于移动终端的订餐应用为例，在9点的时候，用户通过在移动终端上点击某个消息(第一消息)、或者从主界面直接进入该订餐应用的选择餐馆界面A(第一界面)。在进入应用之后，可适时清除第一消息。

用户在第一界面选定餐馆之后,在9点30通过第二消息进入选菜界面B(第二界面)。

用户在第二界面选菜之后，在9点40通过第三消息进入付款界面C(第三界面)。

用户在第三界面付款之后完成整个订餐流程。界面A、B、C就是随着时间推移而串联构成的交互业务，整个服务响应系统构成交互系统。

具体地，第二消息提示用户已经完成餐馆选择，应尽快(例如，设定10分钟的有效期)进入选菜界面，即，第二界面。在用户进入第二界面选菜之后，或者，在经过10分钟的有效期之后，第二消息应当被清除。

同样地，第三消息提示用户已经完成选菜选择，应尽快(例如，设定10分钟的有效期)进入付款界面，即，第三界面。在用户进入第三界面付款之后，或者，在经过10分钟的有效期之后，第三消息应当被清除。最后，通过该应用、或者其它手段，可生成第四消息，其指示用户在第一至第三界面中完成的各个选择的情况，即，基于用户在各个阶段操作的结果，来显示餐馆、菜品、付款情况。这样，用户可以通过单一的第四消息而掌握整个订餐业务流程中的细节，同时不会受到之前的第一至第三消息的干扰。

另一方面，在同一个界面上，即，在业务流程的每个阶段，用户可进行不同的选择，例如，用户在选菜界面B上，9点31分选择了湘菜，9点35分又选择了粤菜，9点37分又选择了川菜等。基于与上面所述类似的原理，用户的新选择会对较早的选择产生影响，例如，可仅保留与最后的选择有关的消息，而清除其余消息。

此外，本发明的交互系统可以针对同类或不同类的交互业务。图3示出了业务类型的分类。如图3所示，交互系统可以针对房产服务(例如，房屋买卖、租赁)、叫车服务(例如，出租车、专车等)等各种服务以及这些服务的组合。在各交互系统中，客户(客户端的用户)为甲，其交互对象分别为乙、丙、丁。乙、丙、丁可对应于不同的应用，也可以分别对应不同的业务类型。

下面，以不同应用(APP)或不同业务在不同交互场景(不同界面)下联动的情况作为示例进行说明。

图4示出了在各应用或业务(乙、丙、丁)中随时间推移对应的会话过程。图4中，在房产及叫车应用中随着时间的推移分别对应进行着不同的交互业务。比如，以叫车服务为例，在前一时刻甲与乙进行着交互，当中间时刻，甲与丙进行了交互，当后一时刻，甲又与丁进行了交互。

基于与上面所述类似的原理，用户的新操作结果会对较早的操作结果产生影响，例如，用户在有效时间(例如，可设定为10分钟)内，通过多个不同的应用(例如，应用1、应用2)分别叫车。之后，这两个应用先后返回两个叫车结果。这时，系统(本发明的流式交互系统)可通过对这两个叫车结果(车辆、司机、价格等情况)进行比对，而向用户提供消息，其中提示这两个叫车结果中的优选结果。用户可响应该消息而直接进入与优选结果对应的应用1，进行下一步的操作。另一方面，清除与应用2有关的消息，和/或退出应用2，和/或关闭应用2的进程。

可以理解，系统进行上述比对的逻辑，可基于云端或本地的历史/经验数据，也可结合用户设定的偏好，等等。

可以理解，上述多个不同的应用也可以是不同业务类型的应用，例如，叫车应用、订餐应用。系统仍可基于类似原理而进行处理。这将在下面举例描述。

图5示出了依据本发明的一种实施方式的交互方法的流程图。如图5所示，依据本发明的一种实施方式，一种交互方法包括：

(1)步骤501，在用户界面上显示业务提示通知；对业务提示通知的实现可以是界面上的弹出窗口，也可以是短信通知，也可以是在界面上的图标或按钮。这种通知例如“现在正在进行优惠活动，请点击以下链接”等，这样的通知可能有一个或更多个。

(2)步骤502，接收用户根据所述通知进入业务处理界面后第一时间所提供的第一消息；对于订餐信息，该第一消息例如是提交的餐馆消息、定菜消息、付费信息消息等；例如定菜信息包括所定的菜为川菜的信息。

(3)步骤503，接收用户进入业务处理界面后第二时间所提供的第二消息；该第二消息和第一消息不同。对于订餐服务，该第二消息例如是提交的餐馆消息、定菜消息、付费信息消息等；该第二消息与第一消息有所不同，例如在该第二消息中，定菜信息包括所定的菜为粤菜的信息。由于第一消息中，所定的菜为川菜，因而第二消息与第一消息不同。

(4)步骤504，根据第二消息对第二信息和第一信息两者进行业务处理。在现有技术中，由于各消息和通知之间是离散(不相关联)的，因而在收到第二消息之后，会仅仅针对第二消息进行处理，而不会理会第一消息，因而针对第一消息的处理结果还会保留在那里，而实际上该第一消息及其处理结果可能已经不再有效。而根据本发明的一种实施方式，不仅对第二消息进行处理，而且根据第二消息对第一消息进行处理，因而可以保证第一消息的处理结果是当前有效的，而不是过时的。

另外，根据第二消息对第一消息进行处理，可以是针对来自不同应用的消息。例如，当接收在11:30接收到订餐消息，在11:50接收到叫车消息时，根据该叫车消息可以产生诸如“您已于11:30进行了叫餐服务，又于11:50进行了叫车服务，所叫的餐未必能够在11:50到达，恐怕影响您的出行，是取消订餐还是延后叫车，还是按照目前的计划进行？”的处理结果消息。也就是说，系统通过逻辑比较，能够发现不同应用或者不同业务之间潜在的冲突，这种冲突仅对用户可见，用户可自主进行处理，以免造成不便。

(5)步骤505，向用户发送业务处理通知，该业务处理通知包括了对第一消息和第二消息两者进行处理后的结果。比如“您11:30在本餐厅定的粤菜菜系套餐已经下单，请在12:00到达。同时您11:00所定的川菜菜系套餐已经取消。详情请参见以下链接”等等。

应该注意，本文所给出的消息和通知的内容和类型仅仅是示例性的，不是对本发明的保护范围的限制。

在现有技术中，由于各消息和通知之间是离散的，因而在收到第二消息之后，会仅仅针对第二消息进行处理，而不会理会第一消息，因而针对第一消息的处理结果还会保留在那里，当客户收到通知进行查看时，还会发现对第一消息的处理结果，例如在上面的情况下，客户在接收到通知进行查看时，会发现：

您有两个订单：

1、第一订单：川菜菜系套餐，下单时间：11:00，状态：未支付。

2、第二订单：粤菜菜系套餐，下单时间：11:30，状态：已支付。

或者类似的交互内容。

相比之下，根据本发明的实施例，由于各消息和通知之间是关联的，因而当客户收到通知进入界面进行查看时，将不会发现对第一消息的处理结果。可以发现以下的交互内容：

您的订单情况如下：

粤菜菜系套餐，下单时间：11:30，状态：已支付。

因而，根据本发明，在向用户发送通知时，不但发送对第二消息的处理结果，而且包括对第一消息的处理结果。在对第二消息进行处理时，不但考虑第二消息本身的内容，对第二消息进行处理，而且考虑第二消息的内容对第一消息进行处理(例如，根据第二消息的内容，删除(不显示)第一消息)。这样可以方便用户了解当前的情况，不致产生不必要的怀疑或者浪费时间。

进一步，在现有技术中，还不能将来自不同应用的消息进行有机的组合，这些消息都是离散的，而根据本发明将能够实现这种组合，能够实现通知在不同应用之间的统筹。

根据另一种实施方式，当接收到第一消息的第一时间和接收到第二消息的第二时间相差超过阈值时，将不再根据第二消息的内容对第一消息处理。

根据再一种实施方式，当接收到第一消息的第一时间和接收到第二消息的第二时间相差超过阈值时，将直接取消第一消息以及对第一消息已经进行的处理。

根据又一种实施方式，当接收到第二消息时，还根据该第二信息和第一信息进行数据统计，并可将数据统计结果通过通知发送给用户。

根据本发明的又另一种实施方式，可以根据用户兴趣点的高低来设定推送通知的优先级。并根据优先级确定是否进行消息的推送。

根据本发明的再又一种实施方式，所述第二消息和第一消息来自相关联的第一界面和第二界面。例如对于点菜交互系统而言，可能包括选择餐馆界面、选择菜谱套餐界面、支付界面这三个界面，用户可能在第一时间在第一界面选择了川菜馆，发送了第一消息，然后退出了程序。在第二时间在第一界面选择了粤菜馆，并选择了粤菜套餐A，并发出了消息。在这种情况下，可以根据第二消息取消第一消息所选择的川菜馆。

图6示出了依据本发明的消息和通知处理的状态图。因而根据本发明的实施方式，如图6所示，消息和通知是有状态的，对于处于有效期内的，可以将状态反映给用户，无效的可以不显示或自动关闭业务入口，还可以将各业务状态流程式的汇总，显得有条理，整个业务流程及状态不再是离散的。业务之间关联后，可以进行灵活调整。

图7示出了依据本发明一种实施方式的人机交互系统。如图7所示，依据本发明的一种实施方式，一种人机交互系统包括通知推送单元701、消息接收单元702和业务处理单元703。

通知推送单元701可以发送业务提示通知以及业务处理通知。消息接收单元702可以在第一时间接收来自第一界面的第一消息，并在第二时间接收来自第二界面的第二消息。业务处理单元703可以根据第二消息对第一消息和第二消息两者进行处理。

这些模块701-703的处理可以参见前面对方法的描述。例如根据本发明的一种实施方式，可以设置计时器或计算器，对于接收第一消息的第一时间和接收第二消息的第二时间之间的时间差进行计算，从而决定如何对第一消息进行处理。

可以根据需要设置统计单元、推送优先级确定单元以实现前述方法中的相应步骤。

在本发明中，可以对各个业务设置业务号来彼此进行区分。业务号可以反映当前业务的业务类型，业务处理单元可以收集用户对不同类型的业务处理的敏感度(偏好)从而设置通知推送的优先级。

根据本发明的实施方式，实现了交互系统交互业务的整合，可以将业务的状态信息处理结果反映给通知，构建业务处理流程的闭环，从而实现业务的完整响应。本发明可以将完整的业务状态反馈给通知，可以构成整个交互系统中业务的完整响应，构成交互业务处理的闭环。本发明的交互系统对业务进行了时间及空间维度的整理，打破了传统的离散型状态。

Claims (10)

1.一种基于通知的流式交互方法，包括以下步骤：

步骤1、接收第一消息，并进入与所述第一消息对应的第一界面，所述第一消息包含第一业务请求；

步骤2、在所述第一界面中，根据所述第一业务请求进行第一业务处理操作，得到第一处理结果；

步骤3、接收第三消息，并进入与所述第三消息对应的第二界面，所述第三消息包含第二业务请求；

步骤4、在所述第二界面中，根据所述第一处理结果及所述第二业务请求进行第二业务处理操作，得到第二处理结果；

步骤5、接收业务处理通知，其包括指示所述第一处理结果的第二消息、和/或指示第二处理结果的第四消息；所述业务处理通知是通过对包含第二业务请求的第三消息与包含第一业务请求的第一消息进行逻辑对比获得的，所述逻辑对比是基于云端/本地的历史/经验数据和/或基于用户设定的偏好。

2.根据权利要求1所述的方法，其特征在于，所述第一界面和所述第二界面为展现内容彼此有关的界面，其中，

所述第一界面和所述第二界面为同一应用或者不同应用的界面。

3.根据权利要求1所述的方法，其中，

在进入所述第一界面之后，清除所述第一消息，

在进入所述第二界面之后，清除所述第三消息。

4.根据权利要求1所述的方法，其特征在于，所述第一消息、第二消息、第三消息、第四消息分别包含有效期标记，所述有效期标记用于所述各个消息的有效期。

5.根据权利要求4所述的方法，在步骤3之后还包括：

步骤3-1、根据有效期标记所指示的所述第一消息的有效期，和/或根据所述第一消息和所述第三消息的接收时刻，来确定是否清除所述第一消息。

6.根据权利要求5所述的方法，其特征在于，在步骤3-1中，在当前时刻已经过了第一消息的有效期的到期时刻的情况下，或者，在第一消息的接收时刻与第三消息的接收时刻之间的时长大于预定时间阈值的情况下，清除第一消息。

7.根据权利要求5所述的方法，其特征在于，在步骤3-1中，在第一消息的接收时刻与第三消息的接收时刻之间的时长大于预定时间阈值的情况下，跳过后续步骤4和5。

8.根据权利要求1所述的方法，其特征在于，在所述方法进行的过程中，服务端同时还收集用户对不同类型的业务处理的敏感度，根据所述业务处理的敏感度来设定推送所述各个消息的优先级顺序。

9.根据权利要求8所述的方法，其特征在于，第一业务请求和第二业务请求具有不同的业务类别，

并且，在所述方法进行的过程中，服务端同时还监测第一业务请求和第二业务请求所对应的不同类别的业务的敏感度，按照业务类别及敏感度设定推送所述各个消息的优先级顺序。

10.一种用于执行根据权利要求1至9中的任一个所述的方法的基于通知的流式交互系统，包括:

消息接收单元，用于接收第一消息，并进入与所述第一消息对应的第一界面，所述第一消息包含第一业务请求；

业务处理单元，用于在所述第一界面中，根据所述第一业务请求进行第一业务处理操作，得到第一处理结果；

其中，消息接收单元还用于接收第三消息，并进入与所述第三消息对应的第二界面，所述第三消息包含第二业务请求，

其中，业务处理单元还用于在所述第二界面中，根据所述第一处理结果及所述第二业务请求进行第二业务处理操作，得到第二处理结果，其中，消息接收单元还用于接收业务处理通知，其包括指示所述第一处理结果的第二消息、和/或指示第二处理结果的第四消息；所述业务处理通知是通过对包含第二业务请求的第三消息与包含第一业务请求的第一消息进行逻辑对比获得的，所述逻辑对比是基于云端/本地的历史/经验数据和/或基于用户设定的偏好。