WO2012055349A1

WO2012055349A1 - 一种事件处理方法和装置

Info

Publication number: WO2012055349A1
Application number: PCT/CN2011/081316
Authority: WO
Inventors: 李征
Original assignee: 中国移动通信集团公司
Priority date: 2010-10-26
Filing date: 2011-10-26
Publication date: 2012-05-03
Also published as: KR101544289B1; JP5908916B2; JP2013544461A; KR20130108605A; CN102457824B; CN102457824A

Description

一种事件处理方法和装置本申请要求在 2010年 10月 26 日提交中国专利局、申请号为 201010527311.5、发明名称为"一种事件处理方法和装置"的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本发明涉及通信技术领域，特别是涉及一种事件处理方法和装置。背景技术

空中下载（OTA, Over The Air )应用是一种基于短消息机制、通过手机终端和服务器之间的交互使用户获取个性化信息服务的数据增值业务。 OTA应用存放于手机终端、用户身份识别模块（SIM, Subscriber Identity Module )卡或全球用户身份识别模块（USIM, Universal Subscriber Identity Module )卡中，可以实现业务菜单的动态下载、删除与更新。例如，手机终端上的手机票应用可以通过短信或通用分组无线服务（ GPRS, General Packet Radio Service ) 方式，与服务器进行购票、取票和回票等业务。

手机终端与服务器之间的一次业务通常需要经历若千次信令交互才能完成，且上述业务可以通过短信下行 ( MT, Mobile Terminated )或短信上行 ( MO, Mobile Originated )方式实现。现有技术中的手机终端与服务器的系统架构，如图 1所示。当手机终端中的 OTA 应用通过 MO方式向服务器发送业务请求后， OTA应用处于等待服务器回应的状态；当接收到服务器中的应用处理器返回的业务响应后，手机终端完成业务，进入空闲状态。服务器也可以通过 MT方式向终端发送业务命令，终端中的 OTA应用接收到业务命令后，向服务器返回响应并进入等待服务器回应的状态，在接收到服务器返回的业务响应后，完成业务并进入空闲状态。

在实现本发明的过程中，发明人发现现有技术至少存在如下问题：

由于现有技术釆用异步通信方式，无法保证服务器实时收到手机终端的短信，而且可靠性差，短信易丢失，服务器通过 MT方式向手机终端发送的业务命令会中断手机终端正在进行的 MO方式的业务，降低了 OTA应用的执行成功率；此外，在手机终端的业务过程中，如果通过 MO 的方式发起新的业务，也会导致前一业务的中断，同样降低了 OTA 应用的执行成功率。发明内容本发明的目的在于提供一种事件处理方法和装置，用以提高终端中的应用的执行成功率，为此，本发明釆用如下技术方案：

一种事件处理方法，应用于终端，所述终端上设置有所述终端中的应用的各状态以及各状态下的期待事件，所述方法包括：

当终端接收到服务器的下行事件时，所述终端根据所述终端当前业务的应用所处的状态，判断所述下行事件是否为该状态下的期待事件，并在判断出所述下行事件为该状态下的期待事件时，将所述下行事件发送到所述应用，更新所述应用的状态。

一种事件处理方法，应用于服务器，所述服务器上设置有终端中的应用的各状态以及各状态下的期待事件，所述方法包括：

所述服务器根据所述终端当前业务的应用所处的状态，判断所述服务器生成的下行事件是否为该状态下的期待事件；

所述服务器判断出所述下行事件为该状态下的期待事件时，向所述终端发送所述下行事件。

一种终端，包括：

状态机管理器，用于存储所述终端中的应用的各状态以及各状态下的期待事件；接收模块，用于接收服务器的下行事件；

判断模块，用于根据所述终端当前业务的应用所处的状态，判断所述下行事件是否为该状态下的期待事件；

处理模块，用于在所述判断模块判断出所述下行事件为该状态下的期待事件时，将所述下行事件发送到所述应用，更新所述应用的状态。

一种服务器，包括：

生成模块，用于生成下行事件。

状态机管理器，用于存储终端中的应用的各状态以及各状态下的期待事件；判断模块，用于根据所述终端当前业务的应用所处的状态，判断所述生成模块生成的下行事件是否为该状态下的期待事件；

处理模块，用于在所述判断模块判断出所述下行事件为该状态下的期待事件时，向所述终端发送所述下行事件。

与现有技术相比，本发明具有以下优点：根据终端当前业务的应用所处的状态选择发送给该应用的下行事件，可以避免打断终端当前业务，提高了终端业务的执行成功率。附图说明

图 1为现有技术中的终端与服务器的架构示意图；

图 2为本发明实施例中的终端与服务器的架构示意图; 图 3为本发明实施例一中的事件处理方法流程图；

图 4为本发明实施例中的终端中的应用的状态更新示意图；

图 5为本发明实施例二中的事件处理方法流程图；

图 6为本发明实施例三中的事件处理方法流程图；

图 7为本发明实施例四中的终端的结构示意图；

图 8为本发明实施例五中的服务器的结构示意图。具体实施方式

本发明实施例提供的技术方案中，终端上设置有该终端中每一个应用的各状态以及各状态下的期待事件，当终端接收到服务器的下行事件时，终端根据该终端当前业务的应用所处的状态，判断下行事件是否为该状态下的期待事件，并在判断出下行事件为该状态下的期待事件时，将该下行事件发送到上述应用，更新该应用的状态；当终端生成上行事件时，终端根据该终端当前业务的应用所处的状态，判断上行事件是否为该状态下的期待事件，并在判断出该上行事件为该状态下的期待事件时，将该上行事件发送到服务器，更新上述应用的状态。

服务器上也可以设置有终端中的应用的各状态以及各状态下的期待事件，服务器根据终端当前业务的应用所处的状态，判断该服务器生成的下行事件是否为该状态下的期待事件；服务器判断出下行事件为该状态下的期待事件时，向终端发送该下行事件。上述两种方案还可以结合使用。

下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图 2所示，本发明实施例中的终端与服务器的架构示意图。终端可以针对自身的应用设置状态机管理器，通过该状态机管理器维护终端中的应用所处的状态，并根据应用所处的状态确定接收到的下行事件是该状态下的期待事件时将该下行事件发送到终端中的应用，以及在生成的上行事件是该状态下的期待事件时将该上行事件发送到服务器，从而通过终端侧的处理提高终端中的应用的执行成功率。服务器也可以针对终端中的应用设置状态机管理器，通过该状态机管理器记录终端中的应用当前所处的状态，并在生成的下行事件是该终端的应用当前所处的状态的期待事件时，将生成的下行事件发送到终端，从而通过服务器侧的处理提高终端中的应用的执行成功率。

如图 3所示，为本发明实施例一中的事件处理方法流程图，该流程中，终端中设置有状态机管理器，状态机管理器中设置有终端中的应用的各状态以及各状态下的期待事件。终端通过 MO方式或 MT方式当前开启了某种应用，本实施例中以手机票应用为例，如图所示，该流程可包括以下步骤：

步骤 301 , 终端接收服务器的下行事件。

步骤 302, 终端根据手机票应用的所处的状态，判断接收到的下行事件是否为该状态下的期待事件；如果判断结果为是，则执行步骤 303; 否则，执行步骤 304。

具体地，终端中的状态机管理器可以根据手机票应用所处的状态确定该状态下的期待事件，并判断接收到的下行事件是否为期待事件。其中，终端的应用所处的状态下的期待事件可以为一种或多种下行事件。

步骤 303 , 终端将接收到的下行事件发送到手机票应用，更新手机票应用的状态。具体地，终端可以在将接收到的下行事件发送到手机票应用之后，更新手机票应用的状态，也可以在接收到手机票应用返回的用于表示应用根据下行事件处理成功的反馈信息后，更新手机票应用的状态。当终端中的状态机管理器接收到手机票应用返回的用于表示应用根据下行事件处理不成功的反馈信息或者在预设时间内没有接收到手机票应用返回的反馈信息时，终端保持手机票应用的状态。

终端中的状态机管理器可以按照如图 4所示的状态更新示意图，更新终端中的应用的状态。当终端中的应用为空闲状态，且接收到的下行事件为针对业务 1的 MT命令时，状态机管理器将应用的状态更新为业务 1状态；当终端中的应用为业务 1进行状态，且接收到的下行事件为针对业务 1的业务应答时，状态机管理器可以先将应用的状态更新为业务 1 完成状态，并进一步更新到空闲状态。当终端中的应用为空闲状态，且接收到的下行事件为业务应答时，该应用的状态不变。当终端中的应用为业务 1进行状态，且接收到的下行事件为针对其他业务的 MT命令时，保持该应用的状态不变。

步骤 304, 终端丢弃接收到的下行事件，向服务器发送通知消息。

其中，通知消息携带有手机票应用的状态信息，该状态信息可以是直接状态信息（如状态名称或标识），即明确指示出手机票应用当前所处的状态，也可以是间接状态信息（如最近一次发送给服务器的上行事件的标识或名称或事件内容等），服务器可根据该间接状态信息确定出手机票应用当前所处的状态。

本发明实施例中，针对终端的 OTA功能失效的极端情况，终端还可以通过数据线、 RFID、蓝牙、红外、 WiFi 等备选方式与服务器交互。终端处于业务进行状态时，可以通过上述备选方式将终端的应用的状态信息通知服务器。

需要说明的是，本发明实施例中的步骤 305为优选步骤，在本发明的其他实施方式中，终端在判断出接收到的下行事件不是终端中的应用的期待事件时，还可以执行除丢弃该下行事件和向服务器发送通知消息之外的其他操作，例如，不响应该下行事件，将最近一次发送给服务器的上行事件再次发送给服务器，同样可以达到事件处理的目的。本发明实施例中，终端还可以通过应用界面向用户提供重试选项和撤销选项。当用户选择重试选项时，终端根据用户提交的重发命令，将已经发送给服务器的上行事件再次发送给该服务器。当用户选择撤销选项时，终端根据用户提交的状态撤销命令，向服务器发送撤销请求，将手机票应用返回到之前的状态，或者直接返回到空闲状态。具体地，终端可以在向服务器发送撤销请求之后，直接将手机票应用返回到之前的状态或者空闲状态；也可以在接收到服务器返回的撤销响应后，将手机票应用返回到之前的状态或者空闲状态。

终端还可以通过应用界面显示手机票应用的状态，以及终端向服务器发送的上行事件的内容。例如，手机票应用的状态可以包括空闲状态、 STK 购票状态、 STK 回票状态和 STK取票状态，终端向服务器发送的上行事件可以包括写票命令、网络购票确认请求命令、取票写票命令、购票取消命令等。

本发明实施例以手机票应用为例对技术方案进行描述，需要说明的是，本发明实施例的技术方案同样适用于终端中的其他应用，如手机钱包应用等。

本发明的实施例包括以下优点，因为才居终端当前业务的应用所处的状态选择发送给该应用的下行事件，可以避免服务器的下行事件打断终端当前业务；通过将终端当前业务的应用所处的状态镜像到服务器中，能够避免服务器在终端当前业务的进行过程中下发新的 MT命令，提高了终端业务的执行成功率。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

如图 5所示，为本发明实施例二中的事件处理方法流程图，该流程中，终端上设置有状态机管理器，状态机管理器中设置有终端中的应用的各状态以及各状态下的期待事件。终端通过 MO方式或 MT方式当前开启了某种应用，本实施例中以手机票应用为例，包括以下步骤：

步骤 501 , 终端生成上行事件。

步骤 502, 终端根据终端手机票应用所处的状态，判断该应用生成的上行事件是否为该状态下的期待事件；如果判断结果为是，则执行步骤 504; 否则，执行步骤 503。

具体地，终端中的状态机管理器可以根据手机票应用所处的状态确定该状态下的期待事件，并判断手机票应用生成的上行事件是否为期待事件。其中，终端的应用所处的状态下的期待事件可以为一种或多种上行事件，该上行事件允许发送到服务器，不会中断当前业务。

其中，终端中的应用生成的上行事件可以为请求事件，不同的请求事件之间可以是互斥关系。终端在当前业务的执行过程中，如果向服务器发送与当前业务的请求事件存在互斥关系的请求事件，会中断当前业务。因此，终端中的状态机管理器可以将与当前业务的请求事件存在互斥关系的请求事件设置为当前业务的应用所处状态下的非期待事件。当应用生成该请求事件时，状态机应管理器会判断该请求事件不是该状态下的期待事件。

步骤 503 , 终端拒绝发送上行事件。

步骤 504, 终端将上行事件发送到服务器，更新手机票应用的状态。

具体地，终端可以在上行事件发送到服务器之前更新应用的状态，也可以在上行事件发送到服务器之后更新应用的状态。终端中的状态机管理器可以按照如图 4所示的状态更新示意图，更新终端中的应用的状态。当终端中的应用为空闲状态，且向服务器发送的上行事件为针对业务 1的 MO请求时，状态机管理器将应用的状态更新为业务 1状态；当终端中的应用为业务 1进行状态，且向服务器发送的上行事件为针对业务 1的撤销请求时，状态机管理器可以先将应用的状态更新为业务 1终止状态，并进一步更新到空闲状态。当终端中的应用为业务 1进行状态，且向服务器发送的上行事件为针对其他业务的 MO请求时，应用的状态信息不变。

本发明实施例中，用户操作进入终端当前业务的应用时，终端通过应用界面显示当前业务的应用的状态，并提供重试和撤销两个选项。当用户选择重试时，终端向服务器重发之前的业务请求，服务器接收重发的业务请求，向终端返回业务响应。当用户选择撤销时，终端向服务器发送针对当前业务的撤销请求，并回到空闲状态，也可以在接收到服务器的 •ί敦销响应时，回到空闲状态。

以手机票为例，终端中的应用接收下行事件或发送上行事件后的状态变化，如表 1所表 1 手机票应用的状态变化表

其中，表 1的第 1行表示手机票应用接收下行事件或发送上行事件时的状态，表 1的第 1列表示接收的下行事件或发送的上行事件，表 1的其他内容表示手机票应用接收下行事件或发送上行事件后的状态。 N/A表示手机票应用接收的下行事件或发送的上行事件是无效的，手机票应用不执行相应的命令，也不返回响应。

当手机票应用处于业务进行状态时，用户进入一级菜单 "手机票券" 后，手机票应用展示正在等待处理的当前 STK业务，内容可以为 "您的 XXXX (网络购票、取票或回票）业务正在处理中，您可以选择返回，继续等待，或者选择确定，再次重发。" 用户选择重发后，手机票应用将本地业务请求再次发送给服务器，并在发送本地业务请求后进入二级菜单；用户选择返回后，则手机票应用直接进行二级菜单。

需要说明的是，本发明实施例中的步骤 503为优选步骤，在本发明的其他实施方式中，终端在判断出不允许将自身的应用生成的上行事件发送到服务器时，还可以执行除拒绝发送上行事件之外的其他操作，例如，丢弃该下行事件，也可以达到事件处理的目的。

本发明的实施例包括以下优点，因为才居终端当前业务的应用所处的状态选择发送给服务器的上行事件，可以避免向服务器发送的上行事件打断终端的当前业务；此外，终端可以显示当前业务的应用的状态，并向用户提供了重发 MO命令和撤销 MO命令的选择，降低了用户误操作的几率，提高了终端业务的执行成功率。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

如图 6所示，为本发明实施例三中的事件处理方法流程图，该流程中，服务器上设置有状态机管理器，状态机管理器中设置有终端中的应用的各状态以及各状态下的期待事件。终端通过 MO方式或 MT方式当前开启了某种应用，服务器接收终端发送的通知消息或者当前业务的应用的上行事件后，更新该应用的状态。上述通知消息中携带当前业务的应用的状态信息，该状态信息可以是直接状态信息（如状态名称或标识），即明确指示出当前业务的应用所处的状态，也可以是间接状态信息（如最近一次发送给服务器的上行事件的标识或名称或事件内容等），服务器可根据该间接状态信息确定出当前业务的应用所处的状态。本实施例包括以下步骤：

步骤 601 , 服务器生成下行事件。

步骤 602, 服务器根据终端当前业务的应用所处的状态，判断该服务器生成的下行事件是否为该状态下的期待事件；如果判断结果为是，则执行步骤 604; 否则，执行步骤 603。

具体地，服务器中的状态机管理器可以根据应用所处的状态确定该状态下的期待事件，并判断生成的下行事件是否为期待事件。其中，终端的应用所处的状态下的期待事件可以为一种或多种下行事件。步骤 603 , 服务器拒绝发送下行事件。

步骤 604, 服务器向终端发送下行事件。

需要说明的是，本发明实施例中的步骤 603为优选步骤，在本发明的其他实施方式中，服务器在判断出生成的下行事件不是终端中的应用的期待事件时，还可以执行除拒绝发送下行事件之外的其他操作，例如，丢弃该下行事件，也可以达到事件处理的目的。

本发明的实施例包括以下优点，因为才居终端当前业务的应用所处的状态选择发送给该应用的下行事件，可以避免服务器的下行事件打断终端当前业务，提高了终端业务的执行成功率。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

需要说明的是，本发明的上述实施例均以终端或服务器单侧设置状态机管理器为例，描述本发明的技术方案。在本发明的其他实施方式中，终端和服务器可以同时设置状态机管理器，以处理终端接收到的下行事件、终端生成的上行事件以及服务器生成的下行事件。

根据上述实施方式中提供的事件处理方法，本发明实施例还提供了应用上述事件处理方法的装置。

如图 7所示，为本发明实施例四中的终端的结构示意图，包括：

状态机管理器 710, 用于存储终端中的应用的各状态以及各状态下的期待事件。

接收模块 720, 用于接收服务器的下行事件。

生成模块 730, 用于生成上行事件。

判断模块 740, 用于根据终端当前业务的应用所处的状态，判断接收模块 720接收到的下行事件和 /或生成模块 730生成的上行事件是否为该状态下的期待事件。

处理模块 750, 用于在判断模块 740判断出下行事件为该状态下的期待事件时，将该下行事件发送到该应用，更新该应用的状态；和 /或在判断模块 740判断出上行事件为该状态下的期待事件时，将该上行事件发送到服务器，更新应用的状态。

具体地，上述处理模块 750可以在将下行事件发送到应用之后，更新应用的状态；也可以接收应用返回的用于表示应用根据下行事件处理成功的反馈信息后，更新应用的状态。

上述处理模块 750, 还用于在判断模块 740判断出下行事件不是应用所处的状态下的期待事件时，丢弃该下行事件。

上述处理模块 750, 还用于在判断模块 740判断出下行事件不是应用所处的状态下的期待事件时，向服务器发送通知消息，或者将最近一次发送给服务器的上行事件再次给该服务器。上述通知消息中携带有应用的状态信息，该状态信息可以是直接状态信息（如状态名称或标识），即明确指示出当前业务的应用所处的状态，也可以是间接状态信息（如终端最近一次发送给服务器的上行事件的标识或名称或事件内容等），服务器可根据该间接状态信息确定出当前业务的应用所处的状态。

上述处理模块 750, 还用于在判断模块 740判断出上行事件不是应用所处的状态下的期待事件时，拒绝发送该上行事件。

上述处理模块 750, 还用于根据用户提交的状态撤销命令，向服务器发送撤销请求，将当前业务的应用返回到之前的状态。

上述处理模块 750, 还用于根据用户提交的重发命令，将已经发送给服务器的上行事件再次发送给该服务器。

本发明的实施例包括以下优点，因为才居终端当前业务的应用所处的状态选择发送给该应用的下行事件和发送给服务器的上行事件，可以避免打断终端的当前业务，提高了终端业务的执行成功率。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

如图 8所示，为本发明实施例五中的服务器的结构示意图，包括：

生成模块 810, 用于生成下行事件。

状态机管理器 820, 用于存储终端中的应用的各状态以及各状态下的期待事件。判断模块 830, 用于根据终端当前业务的应用所处的状态，判断生成模块 810生成的下行事件是否为该状态下的期待事件。

处理模块 840, 用于在判断模块 820判断出下行事件为该状态下的期待事件时，向终端发送下行事件，并更新应用的状态。

具体地，上述处理模块 840可以在向终端发送下行事件之后，更新应用的状态；也可以接收终端返回的用于表示终端当前业务的应用根据下行事件处理成功的反馈信息后，更新应用的状态。

上述处理模块 840, 还用于在判断模块 830判断出下行事件不是该状态下的期待事件时，拒绝发送该下行事件。

上述服务器可以进一步包括：

接收模块 850, 用于接收终端发送的通知消息或者当前业务的应用的上行事件后，其中，通知消息中携带应用的状态信息，该状态信息可以是直接状态信息（如状态名称或标识），即明确指示出当前业务的应用所处的状态，也可以是间接状态信息（如终端最近一次发送给服务器的上行事件的标识或名称或事件内容等）。

更新模块 860 , 用于在接收模块 850接收到通知消息或上行事件后，更新当前业务的应用的状态。

本发明的实施例包括以下优点，因为才居终端当前业务的应用所处的状态选择发送给该应用的下行事件，可以避免服务器的下行事件打断终端当前业务，提高了终端中的应用的执行成功率。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述进行分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本盾上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介盾中，包括若千指令用以使得一台终端设备（可以是手机，个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若千改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims

权利要求

1、一种事件处理方法，其特征在于，包括：

终端接收到服务器的下行事件时，终端根据所述终端当前业务的应用所处的状态，判断所述下行事件是否为该状态下的期待事件；并

在判断出所述下行事件为该状态下的期待事件时，将所述下行事件发送到所述应用，更新所述应用的状态。

2、如权利要求 1所述的方法，其特征在于，所述终端更新所述应用的状态，包括：所述终端在将所述下行事件发送到所述应用之后，更新所述应用的状态；或者所述终端接收所述应用返回的用于表示所述应用根据所述下行事件处理成功的反馈信息后，更新所述应用的状态。

3、如权利要求 1所述的方法，其特征在于，还包括：

所述终端判断出所述下行事件不是所述应用所处的状态下的期待事件时，丢弃所述下行事件。

4、如权利要求 1所述的方法，其特征在于，还包括：

所述终端判断出所述下行事件不是所述应用的期待事件时，向所述服务器发送通知消息，或者将最近一次发送给所述服务器的上行事件再次给所述服务器，所述通知消息中携带有所述应用的状态信息或者所述终端最近一次发送给所述服务器的上行事件的信息，用于将所述应用所处的状态通知所述服务器。

5、如权利要求 1所述的方法，其特征在于，还包括：

终端生成上行事件时，根据当前业务的应用所处的状态，判断所述上行事件是否为该状态下的期待事件，并在判断出所述上行事件为该状态下的期待事件时，将所述上行事件发送到所述服务器，更新所述应用的状态。

6、如权利要求 5所述的方法，其特征在于，还包括：

所述终端判断出所述上行事件不是所述应用所处的状态下的期待事件时，拒绝发送所述上行事件。

7、如权利要求 1所述的方法，其特征在于，还包括：

所述终端根据用户提交的状态撤销命令，向所述服务器发送撤销请求，将所述应用返回到之前的状态；和 /或

所述终端根据用户提交的重发命令，将已经发送给所述服务器的上行事件再次发送给所述服务器。

8、如权利要求 1所述的方法，其特征在于，所述方法还包括：

所述服务器根据所述终端当前业务的应用所处的状态，判断所述服务器生成的下行事件是否为该状态下的期待事件；所述服务器判断出所述下行事件为该状态下的期待事件时，向所述终端发送所述下行事件。

9、一种事件处理方法，其特征在于，包括：

所述服务器根据所述终端当前业务的应用所处的状态，判断生成的下行事件是否为该状态下的期待事件；

10、如权利要求 9所述的方法，其特征在于，还包括：

所述服务器判断出所述下行事件不是所述应用所处的状态下的期待事件时，拒绝发送所述下行事件。

11、如权利要求 9所述的方法，其特征在于，还包括：

所述服务器接收所述终端发送的通知消息或者当前业务的应用的上行事件后，更新所述应用的状态，所述通知消息中携带所述应用的状态信息或者所述终端最近一次发送给所述服务器的上行事件的信息。

12、一种终端，其特征在于，包括：

13、如权利要求 12所述的终端，其特征在于，

所述处理模块，具体用于在将所述下行事件发送到所述应用之后，更新所述应用的状态；或者

接收所述应用返回的用于表示所述应用根据所述下行事件处理成功的反馈信息后，更新所述应用的状态。

14、如权利要求 12所述的终端，其特征在于，

所述处理模块，还用于在所述判断模块判断出所述下行事件不是所述应用所处的状态下的期待事件时，丢弃所述下行事件。

15、如权利要求 12所述的终端，其特征在于，

所述处理模块，还用于在所述判断模块判断出所述下行事件不是所述应用所处的状态下的期待事件时，向所述服务器发送通知消息，或者将最近一次发送给所述服务器的上行事件再次给所述服务器，所述通知消息中携带有所述应用的状态信息或者所述终端最近一次发送给所述服务器的上行事件的信息，用于将所述应用所处的状态通知所述服务器。

16、如权利要求 12所述的终端，其特征在于，还包括：

生成模块，用于生成上行事件；

所述判断模块，还用于根据当前业务的应用所处的状态，判断所述上行事件是否为该状态下的期待事件；

所述处理模块，还用于在判断出所述上行事件为该状态下的期待事件时，将所述上行事件发送到所述服务器，更新所述应用的状态。

17、如权利要求 16所述的终端，其特征在于，

所述处理模块，还用于在所述判断模块判断出所述上行事件不是所述应用所处的状态下的期待事件时，拒绝发送所述上行事件。

18、如权利要求 12所述的终端，其特征在于，

所述处理模块，还用于根据用户提交的状态撤销命令，向所述服务器发送撤销请求，将所述应用返回到之前的状态。

19、如权利要求 12所述的终端，其特征在于，

所述处理模块，还用于根据用户提交的重发命令，将已经发送给所述服务器的上行事件再次发送给所述服务器。

20、一种服务器，其特征在于，包括：

生成模块，用于生成下行事件。

21、如权利要求 20所述的服务器，其特征在于，

所述处理模块，还用于在所述判断模块判断出所述下行事件不是该状态下的期待事件时，拒绝发送所述下行事件。

22、如权利要求 20所述的服务器，其特征在于，还包括：

接收模块，用于接收所述终端发送的通知消息或者当前业务的应用的上行事件，所述通知消息中携带所述应用的状态信息或者所述终端最近一次发送给所述服务器的上行事件的信息；

更新模块，用于更新所述应用的状态。