CN102170618A - 短消息处理方法及设备 - Google Patents

Abstract

本发明公开了一种在短消息交互通信中通过向每个业务实例分配标识码并以嵌有该标识码的号码与用户进行短信交互的短消息处理方法和设备。在本发明的短消息处理方法和设备中，响应于接收到来自通信终端的短消息，根据该短消息所包含的服务器方通信号码确定该短消息所针对的业务实例，然后以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。本发明能够准确、便捷地将多条短消息关联到相应的业务实例，增强了用户在交互过程中的体验。

Description

短消息处理方法及设备

技术领域

本发明总体上涉及短消息交互通信领域，更具体地涉及短消息处理方法及设备。

背景技术

短消息以其独特的信息到达方式及信息存贮特点成为了一种重要的移动通信手段。据统计，2008年短消息业务在中国增值服务市场上的份额达到了66.3％。

例如，新兴的通信驱动业务流程(CEBP)很大程度地依赖于短消息交互技术。在CEBP模式下，用户通过诸如短消息等通信方式来与企业或其他业务提供商的应用服务器自动地进行交互。CEBP利用通信技术的传播力渗透到各类业务中的各个方面，使得能够显著且便捷地提高企业效率，同时节省了人力成本。

随着诸如CEBP的短消息应用的发展，对用户与应用服务器之间需要进行多轮短消息交互的业务的需求越来越强。例如，如图5所示的情形中，当用户通过短信交互方式发表帖子的时候，用户需要依次通过三条短消息来分别向应用服务器提交“标题”、“摘要”和“内容”。服务器在收集完毕这三条消息后，调用第三方网络应用服务器的接口发表这个帖子。在这种通过多轮交互才能完成一个业务实例的情况下，就必须在应用服务器中关联多个短消息。

为了能够实现关联，通常采用的是基于规则引擎的方案。然而，在这种基于规则引擎的方案中，系统内存中将保存所有的相关用户交互数据。对于短消息而言，可能的交互周期超过24小时甚至更长，使得所占用的系统内存始终无法得到释放，因此未完成的业务实例数据将给信息量大的系统造成巨大的负担。另外，应用服务器一旦重启或是被意外损坏，则无法恢复正在交互的业务实例。

此外，基于规则引擎的方案无法处理图5中示出的情况。在图5中，来自同一用户的短消息按照“标题1”、“摘要1”、“标题2”、“内容1”、“摘要2”和“内容2”的顺序到达应用服务器，即在一个业务实例还未完成的情况下就接收到来自同一用户的另一业务实例消息，则基于规则引擎的方案将不能执行正确的关联。这样就会出现信息的丢失或混乱。

为了多轮交互业务能够同时进行，必须要识别针对不同业务实例的信息。为此，现有技术中提出了如下三种识别方案。第一种方案是让用户在短消息文本内容中添加序列码。这种方案的缺点在于用户不得不记住通常复杂的序列码，而且要自己在短消息内容中正确地添加该序列码。这种方法不仅繁琐而且容易出错，例如用户记错或输入错误序列码等，从而导致很差的用户体验。

第二种方案是修改短消息中的MsgID(短消息流水号)字段，该MsgID字段用来唯一标识一条短消息但在客户端处不可见。然而，该MsgID字段是系统按照目前的短消息网关协议(例如，SMGP)自动创建和添加的，且不允许被修改。此外，采用这种方案通常还需要修改客户端协议，否则客户端会不支持。

第三种方案是通过时间、信息冗余等因素来关联业务实例。例如，可以将预定时间段内接收到的短消息都看作一个业务实例。显然，这种方案的准确度很低。

因此，希望提供一种准确、便捷的动态关联短消息交互通信中的业务实例的方法及装置。

发明内容

本发明一个实施例的一个目的是准确、便捷地关联短消息交互通信中的业务实例。

本发明的短消息处理设备和方法通过动态地分配业务实例标识码、将该标识码嵌入到服务器方通信号码中并且以该服务器方通信号码向用户发送短消息，使得用户只需直接回复该服务器方通信号码就能够动态地关联到正在进行的交互业务实例。

根据本发明的第一方面，提供了一种短消息处理方法，包括：响应于接收到来自通信终端的短消息，确定该短消息所针对的业务实例；和以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。

根据本发明的第二方面，提供了一种短消息处理设备，包括：确定装置，用于响应于接收到来自通信终端的短消息，确定该短消息所针对的业务实例；和发送装置，用于以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。

与现有的技术方案相比，即使来自同一用户的多个交互业务实例同时进行，本发明也能够准确、便捷地将多条短消息关联到相应的业务实例，且与这多条短消息的到达时间无关。根据本发明，用户直接回复嵌入有业务实例标识码的通信号码即可进行交互，从而免除了用户在短消息文本内容中输入任何标识的繁琐与麻烦。

本发明的短消息方法和设备通过将关于业务实例的交互数据都记录在诸如硬盘、高速缓存、闪存等的贮存器中，使得即使在应用服务器重启或意外故障时也能够利用业务实例标识码而从贮存器中读出数据，从而恢复正在进行的交互。此外，即使业务信息量巨大，由于无需在系统内存中保持未完成实例的所有数据，因此本发明的业务实例动态关联方法和装置不会给服务器系统造成大的工作负荷，从而尤其适用于大信息量的业务应用。

附图说明

根据以下参照附图对本发明示例性实施方式的详细描述，将更好地理解以上和其他示例目的、方面和优点。

图1是例示了根据本发明一个实施例的动态关联业务实例的方法的流程图；

图2是例示了根据本发明另一个实施例的动态关联业务实例的方法的流程图；

图3是示出了根据本发明一个实施例的动态关联业务实例的方法的示例实现；

图4是例示了根据本发明一个实施例的动态关联业务实例的装置的框图；以及

图5是示出了短消息交互示例的示意图。

图6是例示了根据本发明一个实施例的短消息处理方法的流程图。

图7是示出了根据本发明一个实施例的短消息处理设备的框图。

具体实施方式

应当理解，本发明的附图和描述已经简化，以例示有助于清楚地理解本发明的步骤或部件，同时出于清楚的目的，除去了典型的业务实例关联中的其他步骤或部件。本领域技术人员将认识到，为了实施本发明，其他步骤或部件是希望的和/或是必需的。然而，由于这些步骤或部件是本领域所公知的，并且由于它们并不助于更好地理解本发明，所以本文中并未给出关于它们的描述。还应当理解，本文所包括的附图仅仅给出了对于本发明的当前示例实施例的图形表示，落入本发明的范围内的步骤或部件可包括不同于这些附图中示出的步骤或部件。下面将参考附图，其中对类似的步骤或部件给予类似的附图标记。

本文中所称“业务”与“业务实例”是完全不同的概念，其中“业务”是指服务提供商所提供的一类服务，例如“选出你心中最喜爱超女”；而“业务实例”是指针对“业务”由用户触发的一次或多次互动，例如用户对“选出你心中最喜爱超女”的业务所做的一次投票。通常，针对一个业务可以有若干个业务实例。

短消息网关协议(SMGP)V3.0中将服务器方通信号码定义为“118+SPNumber+可选”，其中SPNumber表示服务提供商代码，由电信运营商指定。SMGP对服务器方通信号码中“可选”字段的长度在协议规定中没有限制，只要客户端软件支持即可。本发明的业务实例动态关联技术就是基于对上述“可选”字段的处理来进行。

如前所述，本发明的业务实例关联装置和方法通过动态地分配业务实例标识码、将该标识码嵌入到服务器方通信号码的“可选”字段中并且以该嵌有标识码的服务器方通信号码向用户发送短消息，使得用户只需直接回复该服务器方通信号码就能够动态地关联到正在进行的交互业务实例，从而实现准确、便捷的业务实例关联。

图1是例示了根据本发明一个实施例的动态关联业务实例的方法1000的流程图。在图1所示的实施例1000中，服务器方通信号码中的“可选”字段被定义为ServiceNumber+AppSeq，其中，ServiceNumber表示业务号，AppSeq表示特定用户的业务实例标识码。即，可选字段由业务号和业务实例标识码两者构成。在一个业务实例的整个生命周期中，其业务实例标识码AppSeq不会改变。

在步骤1100处，响应于接收到来自用户的通信终端的短消息，启动业务实例动态关联流程。针对接收到的短消息，进行解析，以获得该短消息中的服务器方通信号码(步骤1200)。该服务器方通信号码的可选字段中包括业务号ServiceNumber。接下去，在步骤1300处，基于步骤1200中解析得到的服务器方通信号码是否包含业务实例标识码AppSeq，由此判断服务器中是否存在与步骤1100中接收到的短消息相关的业务实例。具体地，若步骤1200中解析得到的服务器方通信号码中包含AppSeq，则判定服务器中存在相关的业务实例；否则，判定服务器中不存在相关的业务实例。

如果在步骤1300处确定不存在相关的业务实例，即该短消息触发了一个新的业务实例，则在步骤1420处创建关于该短消息的新业务实例。然后，针对该业务实例分配一个业务实例标识码AppSeq(步骤1460)，并将该业务实例标识码AppSeq和步骤1200中解析出的业务号ServiceNumber，按照ServiceNumber+AppSeq的规则嵌入到服务器方通信号码的可选字段中(步骤1480)。

如果在步骤1300处确定存在与接收到的短消息相关的业务实例，则从步骤1200处获得的服务器方通信号码中提取该短消息所针对的业务实例标识码AppSeq(步骤1500)。然后，基于预定逻辑，例如针对该业务实例的短消息交互次数或对短消息内容的简单逻辑分析等，来确定该业务实例是否完成(步骤1600)。作为一个示例，可以在服务器内针对通信终端设置一计数器，该计数器的值响应于接收到来自相应通信终端的短消息而自动递增一。可以基于计数器的值来进行步骤1600中的判断或者确定服务器对通信终端的应答短消息的内容。

在步骤1600处确定业务实例还未完成时，则基于所述预定逻辑，确定服务器应向用户的通信终端发送的短消息的内容，并将其以所述包含业务实例标识码AppSeq和业务号ServiceNumber的服务器方通信号码向通信终端发送(步骤1700)。用户直接回复该服务器方通信号码来与服务器进行短消息交互。

可选地，在步骤1700中的短消息发送之前、同时或之后，将与本轮交互中从通信终端接收到的短消息和从服务器向通信终端发送的短消息相关的信息(例如，各轮交互中的服务器方通信号码、短消息内容等)存储在服务器中的贮存器(例如，硬盘、高速缓存、闪存等)内(步骤1800)。例如，贮存器中的数据以关键词Key来索引：Key＝UserPhone+ServiceNumber+AppSeq，其中，UserPhone表示通信终端的号码。在需要时，可以利用上述关键词Key从贮存器中读出所述数据。

由于本发明上述实施例包括步骤1800来将交互短消息相关信息存储在诸如硬盘、高速缓存、闪存等的贮存器中，因而无需在服务器的内存中保持未完成实例的数据，由此大大地降低了服务器系统的工作负荷。另外，由于所有数据都存储在贮存器中，因此即使在服务器重启或意外故障时，也能够利用业务实例标识码而从贮存器中读出数据，从而恢复正在进行的交互。

需要说明的是，步骤1800不是实施本发明的动态关联业务实例的技术所必需的。例如，在业务信息量小从而无需考虑系统内存负荷的情况下或者系统稳定性良好的情况下，可以省略图1中的步骤1800。

在步骤1800之后，流程转到步骤1100，继续接收用户的回复短消息，并重复步骤1200-1800直到在步骤1600处确定业务实例已经完成。在步骤1600处确定业务实例已经完成的情况下，例如达到预定的短消息交互次数或是短消息内容中记载有表示完成的信息，执行与该业务实例相关的处理，并删除贮存器内的关于该业务实例的所有数据(步骤1900)。当然，代替执行步骤1900，也可以选择永久保留业务实例数据，或者将这些数据传送到其他的业务平台上进行处理。步骤1900中的与业务实例相关的处理例如包括向通信终端发送确认完成的信息、对业务实例的数据进行分析，等等。

另选地，代替在业务实例完成之后进行数据处理，在每轮短消息交互完成时，例如在图1中的步骤1800之前或之后都可以对交互数据进行处理。在本发明的另一实施例中，步骤1600中的业务实例完成判定操作可以移到步骤1700和1800之后进行。在这种情况下，如果判定业务实例已经完成，则流程进行到步骤1900，否则转到步骤1100等待与用户的下一轮交互。

在短消息交互实践中，可能存在如下情形，即由于例如通信网络故障或用户的误操作等，使得从服务器向通信终端发送的短消息丢失，从而用户无法完成业务实例。针对上述情形，在本发明的还一实施例中，允许用户向指定的服务器方通信号码发送请求来请求服务器重新发送所丢失的短消息。在接收到这种请求时，服务器可以利用业务实例标识码来检索并向用户重新发送所请求的短消息。

图2是例示了根据本发明另一实施例的动态关联业务实例的方法2000的流程图。图2中的动态关联业务实例方法2000增加了设置并调整状态码的步骤，即步骤2400、2405、2480、2500和2600，除此之外与图1中的动态关联业务实例方法1000相同。在图2的动态关联业务实例方法2000中采用相同的附图标记来表示与动态关联业务实例方法1000相同的步骤。下面将详细描述动态关联业务实例方法2000中涉及设置并调整状态码的步骤，而省略对与动态关联业务实例方法1000相同步骤的描述。

在图2所示的实施例2000中，服务器方通信号码中的“可选”字段被定义为ServiceNumber+AppSeq+StateSeq，其中，ServiceNumber表示业务号，AppSeq表示特定用户的业务实例标识码，而StateSeq表示业务实例的当前状态码。即，可选字段由业务号、业务实例标识码和状态码三者构成。

与图1中的方法相同，在图2中的动态关联短消息业务实例的方法中，在接收到来自通信终端的短消息后对其进行解析，然后基于解析得到的服务器方通信号码是否包含业务实例标识码来确定是否存在与该短消息相关的业务实例。在确定不存在相关业务实例的情况下，创建新的业务实例，并针对所述创建的业务实例分配业务实例标识码AppSeq。

接下去，在步骤2480处，基于预定状态逻辑，向所述业务实例分配状态码StateSeq。这里的预定状态逻辑例如包括定义了整个交互全过程的状态迁移图，如图3中示出的业务逻辑。该预定状态逻辑可以由诸如XML或Java的任何其他描述性语言来实现。

如果在步骤1300处确定存在相关业务实例，则在步骤2400处从解析所得的通信号码中提取短消息所针对的业务实例标识码AppSeq和交互过程当前的状态码StateSeq。在步骤2405处，查找上述预定状态逻辑，并基于在步骤2400处提取出的状态码，确定该业务实例是否完成。

在步骤2405处确定业务实例还未完成时，在步骤2500处，根据上述预定状态逻辑和步骤2400处提取的状态码StateSeq，确定交互过程的下一状态，并分配与该下一状态对应的新状态码StateSeq。在步骤2600处，将所述新状态码StateSeq、所述业务实例标识码AppSeq和业务号ServiceNumber按照ServiceNumber+AppSeq+StateSeq的规则一起嵌入到服务器方通信号码的可选字段中。以该嵌入有新状态码与所述业务实例标识码的服务器方通信号码向通信终端发送短消息，并要求通信终端直接回复该服务器方通信号码来与服务器进行短消息交互。

需要说明的是，尽管在以上参照图1和图2描述的实施例中，将服务器方通信号码中的“可选”字段分别定义为“ServiceNumber+AppSeq”和“ServiceNumber+AppSeq+StateSeq”，但是本领域技术人员应该理解，完全可以采用其他类型的定义，只要能够实现对不同业务实例的区分即可。例如，上述字段中的业务号“ServiceNumber”可以省略。具体地，对于信息量较大的业务(例如，“选出你心中最喜爱超女”)而言，业务提供商可能会在一段时间内安排其服务器只处理这一项业务。在这种情况下，服务器方通信号码中的业务号“ServiceNumber”可以省略，且默认发送到该服务器的所有短消息都是针对所述项业务。

图3是示出了根据本发明一个实施例的动态关联业务实例的方法的示例实现。在图3的示例中，通信终端是手机，其号码例示为“13866668809”。服务器方通信号码定义为“118+SPNumber+可选”，其中“可选”字段为ServiceNumber+AppSeq+StateSeq。在这个示例中，服务提供商代码SPNumber被定义为“593”。业务实例标识码AppSeq是基于业务实例产生时的当前系统时间而生成的，例如“001”和“105”。

图3中的示例描述的是“发帖业务”，其业务号ServiceNumber被分配为“03”。参见图3中示出的业务逻辑可知，本项“发帖业务”由三个状态构成，即状态1(状态码StateSeq＝1)表示“接收到用户发送来的标题”、状态2(状态码StateSeq＝2)表示“接收到用户发送来的摘要”以及状态3(状态码StateSeq＝3)表示“接收到用户发送来的内容”。需要说明的是，上述代码和标识码的定义和设置都是出于例示的目的，而非旨在将本发明限于所公开的具体实施例。

在第一轮交互中，从用户的通信终端“13866668809”向服务器“593”发送针对业务“03”的短消息，其内容为“标题1”。此时服务器方通信号码为“118 593 03”。服务器接收到该短消息后，对其进行解析，由此确定该短消息是针对业务号为“03”的业务。然后，由于此时的服务器方通信号码“118 593 03”不包含任何业务实例标识码，因此确定不存在与该短消息相关的业务实例，由此建立一个新业务实例，并分配“001”作为其业务实例标识码AppSeq，此时的状态码StateSeq设定为“0”。

基于业务逻辑图可知，该交互业务实例的下一状态是“1”，即“接收到用户发送来的标题”。由此，构建新的服务器方通信号码，即“118 593 03 001 1”，并以该号码向通信终端发送内容“接收到标题1，回复本短消息以添加摘要”。用户接收到该条短消息，则第一轮交互结束，将这一轮从用户接收到的数据即“标题1”以Key＝13866668809+03+001为索引存储在贮存器中。

用户针对接收到的短消息直接回复(即，发送给服务器方通信号码“118 593 03 001 1”)，并在内容中添加“摘要1”，由此开始第二轮交互。服务器接收到用户的该回复短消息后经解析确定：该短消息所针对的是标识码为“001”的业务实例，且当前状态为“1”。利用业务逻辑，确定下一状态是“2”，即“接收到用户发送来的摘要”。由此，构建新的服务器方通信号码，即“118 593 03 001 2”，并以该号码向通信终端发送内容“接收到摘要1，回复本短消息以添加内容”。用户接收到该条短消息。第二轮交互结束。将这一轮从用户接收到的数据即“摘要”以Key＝13866668809+03+001为索引存储在贮存器中。

在第三轮交互开始时，用户没有针对服务器方通信号码“118 59303 001 2”发送来的短消息进行回复，而是向“118 593 03”发送“标题2”。由于此时所针对的服务器方通信号码“118 593 03”不包含任何业务实例标识码，因而服务器确定用户重新启动了一个新的业务实例。

服务器针对该新业务实例分配标识码AppSeq为“105”，且状态码StateSeq设定为“0”。按照与第一轮交互相同的方式，创建新的服务器方通信号码“118 593 03 105 1”，并以此向通信终端发送短消息，从而第三轮交互结束。将这一轮从用户接收到的数据即“标题2”以Key＝13866668809+03+105为索引存储在贮存器中。

第四轮交互与第二轮交互的方式相同，都是针对业务实例“001”。在服务器利用业务逻辑确定下一状态是“3”，已经到达逻辑的末尾。此时，确定完成了业务实例“001”的交互通信。将针对业务实例“001”的所有数据从贮存器中提取出来，并将其传送到第三方网络平台上，以进行进一步的处理。例如，将接收到的三部分数据“标题1”、“摘要1”和“内容1”按照预定格式来发表。

第五轮和第六轮交互与第三轮交互的方式类似，都是针对业务实例“105”输入了“摘要2”和“内容2”，在此不再累述。

图4是例示了根据本发明一个实施例的业务实例动态关联装置400的框图。如图所示，业务实例动态关联装置400包括接收器410、解析器420、处理器430、发送器440和贮存器450。

接收器410用来从通信终端接收针对某项业务的短消息。然后，解析器420对接收器410接收到的短消息进行解析，以获得该短消息所包含的服务器方通信号码，由此得到业务号ServiceNumber、业务实例标识码AppSeq以及状态码StateSeq。注意，在用户首次触发交互时，短消息所包含的服务器方通信号码中不包括业务实例标识码AppSeq以及状态码StateSeq。

在处理器430中对解析器420所解析出的服务器方通信号码进行处理，以将其与业务实例相关联。具体地，在解析器420所解析出的服务器方通信号码中不包括业务实例标识码和状态码时，在业务实例标识码创建器432中创建新业务实例，并分配业务实例标识码AppSeq。然后在状态码确定器434中，参照业务逻辑引擎460中描述的业务逻辑，确定所创建的或已有的业务实例的下一状态，并向所创建的或已有的业务实例分配与之对应的下一状态码StateSeq。

然后，在服务器方通信号码生成器436中按照ServiceNumber+AppSeq+StateSeq的规则，将解析器420解析出的ServiceNumber、业务实例标识码创建器432创建的业务实例标识码AppSeq、状态码确定器434中确定出的状态码StateSeq嵌入到“可选”字段，以生成用于下一轮交互的服务器方通信号码。发送器440以上述嵌入有新状态码与所述业务实例标识码的服务器方通信号码向通信终端发送短消息，并要求通信终端直接回复该服务器方通信号码来与服务器进行短消息交互。另选地，将与从通信终端接收到的短消息和从服务器向通信终端发送的短消息相关的信息存储在贮存器450中。

根据本发明的还一个实施例，如图6所示，提供了一种短消息处理方法。在该动态关联业务实例的方法的步骤61处，响应于接收到来自通信终端的短消息，根据该短消息所包含的服务器方通信号码确定该短消息所针对的业务实例。然而，在步骤65处，以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。

根据本发明的又一个实施例，如图7所示，提供了一种短消息处理设备70。该处理设备70包括确定装置71和发送装置75。确定装置71响应于接收到来自通信终端的短消息，根据该短消息所包含的服务器方通信号码确定该短消息所针对的业务实例。而基于确定装置71对业务实例的确定结果，发送装置75以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。

所属技术领域的技术人员知道，本发明可以体现为系统、方法或计算机程序产品。因此，本发明可以具体实现为以下形式，即，可以是完全的硬件、完全的软件(包括固件、驻留软件、微代码等)、或者本文一般称为“电路”、“模块”或“系统”的软件部分与硬件部分的组合。此外，本发明还可以采取体现在任何有形的表达介质(medium of expression)中的计算机程序产品的形式，该介质中包含计算机可用的程序码。

可以使用一个或多个计算机可用的或计算机可读的介质的任何组合。计算机可用的或计算机可读的介质例如可以是——但不限于——电的、磁的、光的、电磁的、红外线的、或半导体的系统、装置、器件或传播介质。计算机可读介质的更具体的例子(非穷举的列表)包括以下：有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、诸如支持因特网或内部网的传输介质、或者磁存储器件。注意计算机可用的或计算机可读的介质甚至可以是上面印有程序的纸张或者其它合适的介质，这是因为，例如可以通过电扫描这种纸张或其它介质，以电子方式获得程序，然后以适当的方式加以编译、解释或处理，并且必要的话在计算机存储器中存储。在本文件的语境中，计算机可用的或计算机可读的介质可以是任何含有、存储、传达、传播、或传输供指令执行系统、装置或器件使用的或与指令执行系统、装置或器件相联系的程序的介质。计算机可用的介质可包括在基带中或者作为载波一部分传播的、由其体现计算机可用的程序码的数据信号。计算机可用的程序码可以用任何适当的介质传输，包括—但不限于—无线、电线、光缆、RF等等。

用于执行本发明的操作的计算机程序码，可以以一种或多种程序设计语言的任何组合来编写，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++之类，还包括常规的过程式程序设计语言—诸如”C”程序设计语言或类似的程序设计语言。程序码可以完全地在用户的计算上执行、部分地在用户的计算机上执行、作为一个独立的软件包执行、部分在用户的计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在后一种情形中，远程计算机可以通过任何种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户的计算机，或者，可以(例如利用因特网服务提供商来通过因特网)连接到外部计算机。

以下参照按照本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述本发明。要明白的是，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机程序指令实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得通过计算机或其它可编程数据处理装置执行的这些指令，产生实现流程图和/或框图中的方框中规定的功能/操作的装置。

也可以把这些计算机程序指令存储在能指令计算机或其它可编程数据处理装置以特定方式工作的计算机可读介质中，这样，存储在计算机可读介质中的指令产生一个包括实现流程图和/或框图中的方框中规定的功能/操作的指令装置(instruction means)的制造品。

也可以把计算机程序指令加载到计算机或其它可编程数据处理装置上，使得在计算机或其它可编程数据处理装置上执行一系列操作步骤，以产生计算机实现的过程，从而在计算机或其它可编程装置上执行的指令就提供实现流程图和/或框图中的方框中规定的功能/操作的过程。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本文中所用的术语，仅仅是为了描述特定的实施例，而不意图限定本发明。本文中所用的单数形式的“一”和“该”，旨在也包括复数形式，除非上下文中明确地另外指出。还要知道，“包含”一词在本说明书中使用时，说明存在所指出的特征、整体、步骤、操作、单元和/或组件，但是并不排除存在或增加一个或多个其它特征、整体、步骤、操作、单元和/或组件，以及/或者它们的组合。

以下的权利要求中的对应结构、材料、操作以及所有功能性限定的装置(means)或步骤的等同替换，旨在包括任何用于与在权利要求中具体指出的其它单元相组合地执行该功能的结构、材料或操作。所给出的对本发明的描述其目的在于示意和描述，并非是穷尽性的，也并非是要把本发明限定到所表述的形式。对于所属技术领域的普通技术人员来说，在不偏离本发明范围和精神的情况下，显然可以作出许多修改和变型。对实施例的选择和说明，是为了最好地解释本发明的原理和实际应用，使所属技术领域的普通技术人员能够明了，本发明可以有适合所要的特定用途的具有各种改变的各种实施方式。

Claims (18)

1.一种短消息处理方法，包括：

响应于接收到来自通信终端的短消息，根据该短消息所包含的服务器方通信号码确定该短消息所针对的业务实例；和

以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。

2.根据权利要求1所述的方法，其中所述根据该短消息所包含的服务器方通信号码确定该短消息所针对的业务实例的步骤进一步包括：

根据该短消息所包含的服务器方通信号码，判断是否存在与该短消息相关联的业务实例；以及

响应于判定不存在与所述短消息相关联的业务实例，创建与所述短消息相关联的业务实例。

3.根据权利要求2所述的方法，还包括将与所创建的业务实例相对应的业务实例标识码嵌入到服务器方通信号码中。

4.根据权利要求1至3中任一项所述的方法，还包括基于预定逻辑确定所述发送到通信终端的应答短消息的内容。

5.根据权利要求4所述的方法，其中所述服务器方通信号码还嵌有所述业务实例的状态码，并且所述基于预定逻辑确定所述发送到通信终端的应答短消息的内容还包括基于状态码确定所述发送到通信终端的应答短消息的内容。

6.根据权利要求4所述的方法，所述基于预定逻辑确定所述发送到通信终端的应答短消息的内容进一步包括：

响应于接收到来自通信终端的短消息，使得计数器的值递增一；和

根据所述计数器的值，确定要发送到通信终端的应答短消息的内容。

7.根据权利要求5所述的方法，还包括：

解析从通信终端接收到的短消息，以获得服务器方通信号码；

按照预定规则，提取所述服务器方通信号码中的业务实例标识码和状态码；

基于预定状态逻辑，确定该业务实例的下一状态，并向该业务实例分配下一状态所对应的状态码；以及

按照所述预定规则组合所确定的状态码与所述业务实例标识码，从而获得新的服务器方通信号码。

8.根据权利要求1所述的方法，还包括：

在贮存器中存储关于业务实例的短消息交互数据，其中利用业务实例标识码来索引相应业务实例的数据。

9.根据权利要求8所述的方法，还包括：

响应于通信终端丢失来自服务器的短消息而请求服务器重新发送，利用业务实例标识码来检索并重新发送所请求的短消息。

10.一种短消息处理设备，包括：

确定装置，用于响应于接收到来自通信终端的短消息，根据该短消息所包含的服务器方通信号码确定该短消息所针对的业务实例；和

发送装置，用于以嵌有与所确定的业务实例相对应的业务实例标识码的服务器方通信号码向通信终端发送应答短消息。

11.根据权利要求10所述的设备，其中所述处理器进一步包括：

判断装置，用于根据该短消息所包含的服务器方通信号码，判断是否存在与该短消息相关联的业务实例；以及

创建装置，用于响应于判定不存在与所述短消息相关联的业务实例，创建与所述短消息相关联的业务实例。

12.根据权利要求11所述的设备，还包括用于将与所创建的业务实例相对应的业务实例标识码嵌入到服务器方通信号码中的装置。

13.根据权利要求10至12中任一项所述的设备，还包括用于基于预定逻辑确定所述发送到通信终端的应答短消息的内容的装置。

14.根据权利要求13所述的设备，其中所述服务器方通信号码还嵌有所述业务实例的状态码，所述用于基于预定逻辑确定所述发送到通信终端的应答短消息的内容的装置还包括用于基于状态码确定所述发送到通信终端的应答短消息的内容的装置。

15.根据权利要求13所述的设备，所述用于基于预定逻辑确定所述发送到通信终端的应答短消息的内容的装置还包括：

用于响应于接收到来自通信终端的短消息，使得计数器的值递增一的装置；和

用于根据所述计数器的值，确定要发送到通信终端的应答短消息的内容的装置。

16.根据权利要求14所述的设备，还包括：

用于解析从通信终端接收到的短消息，以获得服务器方通信号码的装置；

用于按照预定规则，提取所述服务器方通信号码中的业务实例标识码和状态码的装置；

用于基于预定状态逻辑，确定该业务实例的下一状态，并向该业务实例分配下一状态所对应的状态码的装置；以及

用于按照所述预定规则组合所确定的状态码与所述业务实例标识码，从而获得新的服务器方通信号码的装置。

17.根据权利要求10所述的设备，还包括：

用于在贮存器中存储关于业务实例的短消息交互数据的装置，其中利用业务实例标识码来索引相应业务实例的数据。

18.根据权利要求17所述的设备，还包括：

用于响应于通信终端丢失来自服务器的短消息而请求重新发送，利用业务实例标识码来检索并重新发送所请求的短消息的装置。

Images