短信回执系统及方法

IPRDB

API 数据接口

专利申请

使用指引 chat嘟嘟

会员体验

联系我们

交流群

现在联系顾问~

短信回执系统及方法
申请号	CN201010536641.0	申请日	2010-11-09	公开(公告)号	CN102014354A	公开(公告)日	2011-04-13
申请人	北京无限新锐网络科技有限公司;			发明人	林荣; 林镇武;
摘要	本发明公开了一种增强型短信回执系统及方法，该方法包括：短信发送方通过手机发送短信，短信首先发送给运营商的短信中心，并经由短信中心送达短信接收方的手机；短信接收方收到短信后，自动回复状态报告给短信中心；短信中心在接收到所述状态报告后，通过短信网关把所述状态报告发送给增强型短信回执平台；增强型短信回执平台根据所述状态报告作出判断和生成增强型短信回执，并将增强型短信回执返回给短信网关；短信网关将所述增强型短信回执转发给短信中心；短信中心向短信发送方发送所述增强型短信回执。
权利要求	1.一种增强型短信回执方法，其特征在于，包括：短信发送方通过手机发送短信，短信首先发送给运营商的短信中心，并经由短信中心送达短信接收方的手机；短信接收方收到短信后，自动回复状态报告给短信中心；短信中心在接收到所述状态报告后，通过短信网关把所述状态报告发送给增强型短信回执平台；增强型短信回执平台根据所述状态报告作出判断和生成增强型短信回执，并将增强型短信回执返回给短信网关；短信网关将所述增强型短信回执转发给短信中心；短信中心向短信发送方发送所述增强型短信回执。 2.根据权利要求1所述的方法，其特征在于，对所述增强型短信回执作出判断并生成增强型短信回执包括：增强型短信回执平台在接收到状态报告后将其提交给执行引擎；执行引擎根据接收方手机号从数据库提取用户属性；执行引擎将状态报告和用户属性打包并交付给场景分析引擎；场景分析引擎进行场景模块分析；增强型短信回执平台根据场景模块分析的结果，生成增强型短信回执。 3.根据权利要求2所述的方法，其特征在于，所述场景分析引擎进行场景模块分析包括：定义场景；创建场景集并把所述场景集加载到所述场景分析引擎；向所述场景分析引擎提交待处理的数据对象集合；启动所述场景分析引擎执行分析；获得所述场景分析引擎的分析结果，同时从所述场景分析引擎中移除处理过的数据。 4.根据权利要求3所述的方法，其特征在于，所述场景模块包括：新用户模块，对于状态报告用户开通业务后的第一条报告，系统会对用户进行初始化操作，给用户设置多个系统必须的属性；电梯模块，当状态报告为发送失败或暂未送达时，暂时不给用户下发，而是等待一定时间，在这个时间段内检测是否还有后续状态报告，根据后续状态报告或者超时后再决定给用户下发什么样的状态报告；群发模块，把状态报告暂存起来，等待一定时间，如果在这个时间段内陆续收到同一个用户的多个状态报告，则用户正在做短信群发，把这个时间段内的所有状态报告进行汇总，提取目标用户号码，生成一条或者两条汇总报告；频道模块，提取用户订阅的频道数据，用于生成附加信息；提醒模式模块，当用户设置了提醒模式，只关心发送失败的状态报告，不关心发送成功的状态报告时，把发送成功的报告丢弃，不再下发，而发送失败的状态报告继续进入下一个模块；聊天模块，当短时间内收到多个针对同一个接收方的状态报告时，用户和接收方正在用短信聊天，则针对该接收方暂停下发报告；指定用户模块，当用户设置了指定模式，指定只接受某些人的状态报告时，根据用户设置判断是否下发状态报告；屏蔽消息模块，用户只关心短信的状态报告，不希望接收附加信息时屏蔽掉附加信息；黑名单模块，用户属于黑名单时不下发状态报告。 5.一种增强型短信回执系统，其特征在于，包括：用于发送短信的短信发送方；用于接收短信的短信接收方；用于接收所述接收方自动回复的状态报告的短信中心；用于根据所述状态报告作出判断并生成增强型短信回执的增强型短信回执平台；以及用于将所述短信中心接收到的所述状态报告转发给所述增强型短信回执平台，并将在所述增强型短信回执平台中生成的所述增强型短信回执转发给所述短信中心的短信网关，其中所述短信中心最终将所述增强型短信回执发送给所述短信发送方。 6.根据权利要求5所述的增强型短信回执系统，其特征在于，进一步包括执行引擎和场景分析引擎，其中所述执行引擎用于根据用户的手机号从数据库提取用户属性并将状态报告和用户属性打包发给场景分析引擎，所述场景分析引擎用于进行场景模块分析。 7.根据权利要求6所述的增强型短信回执系统，其特征在于，所述场景分析引擎包括：用于存放要由所述场景分析引擎处理的数据集合的工作区域；用于存放被激活的模块运行实例的模块执行队列；用于存放场景模块和场景模块的元数据以及与场景模块相关的属性的静态场景库。 8.根据权利要求7所述的增强型短信回执系统，其特征在于，所述静态场景库还提供用来存储、分类、查询、进行版本控制、测试的工具。 9.根据权利要求8所述的增强型短信回执系统，其特征在于，所述场景模块包括：新用户模块，对于状态报告用户开通业务后的第一条报告，系统会对用户进行初始化操作，给用户设置多个系统必须的属性；电梯模块，当状态报告为发送失败或暂未送达时，暂时不下发给用户，而是等待一定时间，在这个时间段内检测是否还有后续状态报告，根据后续状态报告或者超时后再决定给用户下发什么样的状态报告；群发模块，把状态报告暂存起来，等待一定时间，如果在这个时间段内陆续收到同一个用户的多个状态报告，则用户正在做短信群发，把这个时间段内的所有状态报告进行汇总，提取目标用户号码，生成一条或者两条汇总报告；频道模块，提取用户订阅的频道数据，用于生成附加信息；提醒模式模块，当用户设置了提醒模式，只关心发送失败的状态报告，不关心发送成功的状态报告时，把发送成功的报告丢弃，不再下发，而发送失败的状态报告继续进入下一个模块；聊天模块，当短时间内收到多个针对同一个接收方的状态报告时，用户和接收方正在用短信聊天，则针对该接收方暂停下发报告；指定用户模块，当用户设置了指定模式，指定只接受某些人的状态报告时，根据用户设置判断是否下发状态报告；屏蔽消息模块，用户只关心短信的状态报告，不希望接收附加信息时屏蔽掉附加信息；黑名单模块，用户属于黑名单时不下发状态报告。
说明书全文	短信回执系统及方法技术领域： [0001] 本发明涉及通信领域，尤其涉及通信领域中的一种短信回执系统及方法。背景技术 [0002] 在现有技术中，许多品牌型号的手机出厂时就具有类似短信回执的功能，其中短信回执，就是当用户用手机给他人发送手机短信时，发送者的手机会收到一条报告，告之对方是否收到了之前发送的短信，这个功能就叫做短信回执。用户无需任何设置就能够获得类似功能，或者说发送的每条短信都会收到一个报告。 [0003] 本发明为了便于区分，把手机自带的功能叫做“传统的短信发送状态报告”(简称状态报告)，与它相对应的本发明叫做“增强型短信回执”(简称短信回执)。 [0004] “传统的短信发送状态报告”的产生和传递过程见图1。其中短信的传送路径为：用户发送短信时，短信首先是发送给最近的基站；然后基站通过运营商的网络把短信送到离接收方最近的基站(这一过程中会经过若干个中间设备，具体数量不固定)；再由这个基站把短信发送给接收方的手机终端上。而状态报告的传送路径为：用户发送短信，短信首先发送给最近的基站；最近的基站收到短信后，立即给用户返回信令报告；用户手机收到这个信令报告后，提示用户短信已送达。也就是说，在现有的技术方案中，短信的发送路径和状态报告二者的传送路径不同。 [0005] 现有技术方案的漏洞就是“中间确认”而不是“终端确认”，由此引发了一系列问题： [0006] 首先是状态报告的不准确，从图1中短信的发送路径可以看出，手机短信的发送并不是从一个手机直接到另一个手机的，中间会经过许多“中间设备”的存储转发，就像接力一样，是一站一站的最终到达接收手机上的，区别在于对待不同的接收方，路径上的“中间设备”的数量会有不同。 [0007] 从技术角度来说，真正的状态报告应该是由整个路径中的最后一个节点返回的，也只有最后一站返回的状态报告才能真正体现出短信的接收状态。由于传统的状态报告来自于整个传送路径的某个中间节点，这个状态报告显然很不准确，甚至不具有任何参考价值。可是对于公众用户而言，由于缺乏专业知识，会被这个状态报告所误导，会想当然的信任这个状态报告。 [0008] 其次是规范不统一，依赖于终端，传统的状态报告功能是作为手机终端的一个辅助功能提供的。其质量标准、功能外观、表现形式完全由各终端厂商自己定义，不同的厂商标准不一致，甚至同一厂商不同型号之间的质量标准也不统一。各终端厂商各自为政、互不一致，行业缺乏必要的统一和协调，标准的不统一给运营商、用户使用造成巨大的困惑，也限制了回执业务的推广和健康发展。 [0009] 此外传统的状态报告不能灵活定制，传统的状态报告不提供个性化定制功能，最多提供开启、关闭两种最简单的设置。用户只能全部接受或者全部拒绝，无法满足多元化需求。发明内容 [0010] 为了解决传统状态报告的上述问题，本发明提供了一种增强型短信回执方法，其特征在于，包括： [0011] 短信发送方通过手机发送短信，短信首先发送给运营商的短信中心，并经由短信中心送达短信接收方的手机； [0012] 短信接收方收到短信后，自动回复状态报告给短信中心； [0013] 短信中心在接收到所述状态报告后，通过短信网关把所述状态报告发送给增强型短信回执平台； [0014] 增强型短信回执平台根据所述状态报告作出判断和生成增强型短信回执，并将增强型短信回执返回给短信网关； [0015] 短信网关将所述增强型短信回执转发给短信中心； [0016] 短信中心向短信发送方发送所述增强型短信回执。 [0017] 其中，对所述增强型短信回执作出判断并生成增强型短信回执包括： [0018] 增强型短信回执平台在接收到状态报告后将其提交给执行引擎； [0019] 执行引擎根据接收方手机号从数据库提取用户属性； [0020] 执行引擎将状态报告和用户属性打包并交付给场景分析引擎； [0021] 场景分析引擎进行场景模块分析； [0022] 增强型短信回执平台根据场景模块分析的结果，生成增强型短信回执。 [0023] 所述场景分析引擎进行场景模块分析包括： [0024] 定义场景； [0025] 创建场景集并把所述场景集加载到所述场景分析引擎； [0026] 向所述场景分析引擎提交待处理的数据对象集合； [0027] 启动所述场景分析引擎执行分析； [0028] 获得所述场景分析引擎的分析结果，同时从所述场景分析引擎中移除处理过的数据。 [0029] 所述场景模块包括： [0030] 新用户模块，对于状态报告用户开通业务后的第一条报告，系统会对用户进行初始化操作，给用户设置多个系统必须的属性； [0031] 电梯模块，当状态报告为发送失败或暂未送达时，暂时不给用户下发，而是等待一定时间，在这个时间段内检测是否还有后续状态报告，根据后续状态报告或者超时后再决定给用户下发什么样的状态报告； [0032] 群发模块，把状态报告暂存起来，等待一定时间，如果在这个时间段内陆续收到同一个用户的多个状态报告，则用户正在做短信群发，把这个时间段内的所有状态报告进行汇总，提取目标用户号码，生成一条或者两条汇总报告； [0033] 频道模块，提取用户订阅的频道数据，用于生成附加信息； [0034] 提醒模式模块，当用户设置了提醒模式，只关心发送失败的状态报告，不关心发送成功的状态报告时，把发送成功的报告丢弃，不再下发，而发送失败的状态报告继续进入下一个模块； [0035] 聊天模块，当短时间内收到多个针对同一个接收方的状态报告时，用户和接收方正在用短信聊天，则针对该接收方暂停下发报告； [0036] 指定用户模块，当用户设置了指定模式，指定只接受某些人的状态报告时，根据用户设置判断是否下发状态报告； [0037] 屏蔽消息模块，用户只关心短信的状态报告，不希望接收附加信息时屏蔽掉附加信息； [0038] 黑名单模块，用户属于黑名单时不下发状态报告。 [0039] 同时，本发明还提供了一种增强型短信回执系统，其特征在于，包括： [0040] 用于发送短信的短信发送方； [0041] 用于接收短信的短信接收方； [0042] 用于接收所述接收方自动回复的状态报告的短信中心； [0043] 用于根据所述状态报告作出判断并生成增强型短信回执的增强型短信回执平台；以及 [0044] 用于将所述状态报告从所述短信中心转发给所述增强型短信回执平台，并将所述生成的增强型短信回执从所述增强型短信回执平台转发给所述短信中心的短信网关， [0045] 其中所述短信中心最终将所述增强型短信回执发送给所述短信发送方。 [0046] 增强型短信回执系统进一步包括执行引擎和场景分析引擎，其中所述执行引擎用于根据用户的手机号从数据库提取用户属性并将状态报告和用户属性打包发给场景分析引擎，所述场景分析引擎用于进行场景模块分析。 [0047] 所述场景分析引擎包括： [0048] 用于存放要由所述场景分析引擎处理的数据集合的工作区域； [0049] 用于存放被激活的模块运行实例的模块执行队列； [0050] 用于存放场景模块和场景模块的元数据以及与场景模块相关的属性的静态场景库。 [0051] 所述静态场景库还提供用来存储、分类、查询、进行版本控制、测试的工具。 [0052] 所述场景模块包括： [0053] 新用户模块，对于状态报告用户开通业务后的第一条报告，系统会对用户进行初始化操作，给用户设置多个系统必须的属性； [0054] 电梯模块，当状态报告为发送失败或暂未送达时，暂时不给用户下发，而是等待一定时间，在这个时间段内检测是否还有后续状态报告，根据后续状态报告或者超时后再决定给用户下发什么样的状态报告； [0055] 群发模块，把状态报告暂存起来，等待一定时间，如果在这个时间段内陆续收到同一个用户的多个状态报告，则用户正在做短信群发，把这个时间段内的所有状态报告进行汇总，提取目标用户号码，生成一条或者两条汇总报告； [0056] 频道模块，提取用户订阅的频道数据，用于生成附加信息； [0057] 提醒模式模块，当用户设置了提醒模式，只关心发送失败的状态报告，不关心发送成功的状态报告时，把发送成功的报告丢弃，不再下发，而发送失败的状态报告继续进入下一个模块； [0058] 聊天模块，当短时间内收到多个针对同一个接收方的状态报告时，用户和接收方正在用短信聊天，则针对该接收方暂停下发报告； [0059] 指定用户模块，当用户设置了指定模式，指定只接受某些人的状态报告时，根据用户设置判断是否下发状态报告； [0060] 屏蔽消息模块，用户只关心短信的状态报告，不希望接收附加信息时屏蔽掉附加信息； [0061] 黑名单模块，用户属于黑名单时不下发状态报告。 [0062] 本发明提供的增强型短信回执系统使用的状态报告不再是由链路的中间环节生成。尽管中间这些环节还会保留着原有的反馈报告，但这些中间报告只用做通信链路的状态信令，而不作为最终到达与否的判断依据。最终的状态报告来自于整个链路的最终环节。这种“终端确认”机制保证了回执的准确性。 [0063] 本发明对现有信令协议进行了增强与扩充，对于那些失败的发送接收，增加了失败场景描述，对失败原因进行细分，比如终端忙、终端关机、终端不在服务区、终端信箱满，等等，进一步增加了状态报告的精度和准度。 [0064] 本发明提供的增强型短信回执系统提供了统一的规范，不再依赖终端厂商。本发明提供的短信回执规范是从运营商一端进行改造，并且只在运营网络一端进行。规范的统一完全摆脱了对终端依赖。如果需要升级或者改造，立即就可以在全网生效，不需要厂商进行任何升级，对于设备厂商、终端用户完全透明。 [0065] 另一方面，本发明提供的增强型短信回执系统加入了场景分析，具有更人性化的产品体验。 [0066] 再一方面，本发明提供的增强型短信回执系统提供用户属性库设计，支持灵活的个性化设置。其把回执功能从终端设备彻底剥离，摆脱了对于厂商终端设备的依赖。同时引入了用户属性库设计，为用户提供了无限的自定义能力。 [0067] 本发明的优点都包含在本说明书中、包含在本发明的范围内并被后面的权利要求所保护。不应将这一部分内容理解成对权利要求的限制。下面将结合附图讨论本发明进一步的方面和优点。应理解对本发明的前面的概括性描述和下面的详细描述都是示例性和说明性的，意在提供对要求保护的本发明的进一步说明。附图说明 [0068] 所包括用于给本发明的实施方式提供进一步理解并结合在内组成说明书一部分的附图图解了本发明的实施方式，并与说明书文字一起用于解释本发明的原理。在附图中： [0069] 图1是传统的短信发送状态报告的生成及传递示意图； [0070] 图2是根据本发明实施方式的短信回执报告生成路径的示意图； [0071] 图3是根据本发明实施方式的短信回执报告的详细处理过程的示意图； [0072] 图4是基于场景库的分析引擎示意图； [0073] 图5是基于场景库的分析引擎的处理流程图； [0074] 图6是根据本发明的实施方式的短信回执报告的具体流程图。具体实施方式 [0075] 为了使本发明的目的和优势更加清楚易懂，下面结合附图对本发明的实施方式进行详细描述。 [0076] 为了解决传统状态报告中存在的问题，本发明提出了一种新型的短信回执处理方法和系统，采用新的处理方法的短信回执，具有准确、独立、易扩展、个性化等特点。准确性，是指本发明可以解决传统短信回执状态不准确的问题，提供更加精准、详实的状态报告。独立性，是指本发明提供的短信回执不再依赖于厂商终端设备的型号、规格、配置，不论是高端的商务手机还是最低端的普通手机，提供的短信回执外观、形式都是统一的。易扩展，是指本发明可以适应通信行业的高速发展需求，对于各种已知类型的、甚至未知类型的终端设备都能够支持，而且可以支持标准的短信、闪信、彩信等各种媒体格式。个性化，是指本发明采用模块化设计，把商业逻辑、业务逻辑从代码逻辑中剥离出来，从而代码和业务规则的依赖性很低，允许用户进行个性化设置，快速支持商业世界的变化。 [0077] 为了实现本发明的上述目的，本发明对传统的状态报告处理逻辑做了一些改进，下面详细进行介绍。 [0078] 根据本发明的一个实施方式的短信回执生成的路径见图2，与传统的状态报告的生成路径不同，本发明所使用的状态报告不再是由链路的中间环节生成。尽管中间这些环节还会保留着原有的反馈报告，但这些中间报告只用做通信链路的状态信令，而不作为最终到达与否的判断依据。最终的状态报告来自于整个链路的最终环节。这种“终端确认”机制保证了回执的准确性。 [0079] 同时本发明还对现有信令协议进行了增强与扩充，对于那些失败的发送接收，增加了失败场景描述，对失败原因进行细分，比如终端忙、终端关机、终端不在服务区、终端信箱满，等等，进一步增加了状态报告的精度和准度。 [0080] 图3是描述增强型短信回执的传递路径和步骤的示意图，参考图3，根据本发明的增强型短信回执的传递路径和步骤为： [0081] 1)短信发送方通过手机发送短信，短信首先发送给运营商的短信中心，最后送达短信接收方的手机； [0082] 2)接收方手机收到短信后，会自动回复一个状态报告给短信中心； [0083] 3)短信中心在接受到这个状态报告后，通过短信网关把这个状态报告发送给增强型短信回执平台； [0084] 4)增强型短信回执平台根据状态报告作出正确的判断，包括成功接收、接收失败、失败原因分析(终端忙、终端不再服务区、终端关机、终端错误等)，生成增强型短信回执后，再返回给短信网关； [0085] 5)短信网关将该增强型短信回执转发给短信中心； [0086] 6)短信中心把增强型短信回执发送给原短信发送方。 [0087] 经过上述改进后的短信回执流程有如下好处：由于是终端确认机制，保证了回执的准确性；回执平台提供了复杂的场景分析功能，保证了回执的精确性；可统一规范，不再依赖于手机厂商，保证产品外观、质量规格在各终端表现一致；允许用户灵活个性化设置。 [0088] 传统的状态报告是靠手机终端实现的，支持程度取决于厂商对信令的理解和支持程度。厂商由于成本、垄断、市场等因素考虑，通常会对信令协议作出种种裁剪，定义自己的框架规范，导致不同厂商设备之间兼容性差。同时由于受到终端体积、成本、软件、硬件等诸多限制，产品一旦投入应用就很难升级。 [0089] 本发明针对这一弊端，对短信回执的规范从运营商一端进行改造，并且只在运营网络一端进行。规范的统一完全摆脱了对终端依赖。如果需要升级或者改造，立即就可以在全网生效，不需要厂商进行任何升级，对于设备厂商、终端用户完全透明。 [0090] 短信回执功能貌似很简单，但其实有许多复杂场景需要考虑，不是说把状态报告直接下发了事。下面以两个场景为例做出简单说明。 [0091] 发送成功的例子：短信群发是人们节假日广泛使用的一种祝福方式。如果不对这种场景设计单独的处理逻辑，用户会在短时间内收到等量的回执报告，虽然从功能上来说没有任何错误，但从用户体验角度会让用户不胜其烦。 [0092] 发送失败的例子：运营商平台提供了短信自动重发机制，对于发送失败的短信，会在短信生命周期内定期重发，重发的时间间隔递增。也就是说，对于一些初次发送失败的短信，最后是可以成功送达的。比如，接收方刚刚打开手机，硬件正在初始化过程中，或者用户在电梯中由于信号屏蔽导致的无法接收。这时如果给这些用户发送短信，会遇到发送失败，但其实一旦开机完毕或者离开电梯信号恢复后，用户很快就可以收到短信。这样一来就会造成连续产生了两个状态报告，第一个是发送失败，第二个是发送成功。如果不能正确处理这种场景，就会导致用户先后接到这两个报告，而且这两条报告的接收没有固定的顺序，尽管在功能上完全正确，但是会给用户造成困惑，用户体验很差。 [0093] 还有许多其他类似的场景也就有相同点的特点，本发明和传统状态报告的一个重要的区别就是引入了场景分析算法，在保证回执准确性的前提下，尽量减少对用户的困扰，使产品更加人性化。也就是说对于收到的每个状态报告并不是直接下发，而是要经过若干个场景模块判断，才决定是否该把这个状态报告下发给用户。比如，判断用户是否正在群发短信，如果是，则对群发的结果进行汇总归纳，最后以一条报告的形式给用户下发；再比如，判断发送失败的原因，如果是由于某些暂时原因造成的发送失败(手机刚开机、用户在电梯中)，不会立即下发发送失败的报告，而是等待后续的状态报告，得到更精确的结果后才下发报告；再比如，用户是否做了个性化设置，用户是否当前不希望被打扰，用户希望采用那种形式(短信、闪信、彩信)，等等。 [0094] 以上提到的只是少量几个典型的场景分析，但真正应用中场景可能数十、上百个。如果采用传统的开发方式，每个场景无外乎是若干个IF...ELSE...ELSIF语句，但这种编码方式会有很大的隐患，首先：实践已经证明，在应用代码中嵌入业务逻辑是很差的开发方式，每当业务逻辑稍有改动都需要重写代码、编译、测试、部署，过程冗长还极易出错。其次，所有业务逻辑的实现不是由业务人员完成，而是由开发人员完成，即便最优秀的程序员，也无法处理嵌套五层以上的逻辑判断。因此，本发明中设计了基于场景库的分析引擎，这是一个有弹性的基础设施。本发明通过结合工作流引擎、规则引擎实现了商务和技术的分离，可以在软件产品发布后，允许业务人员能够按照需求变化灵活的修改场景分析逻辑，而无需修改基础代码及重新部署，从而快速的应对市场变化。 [0095] 参考图4，整个基于场景库的分析引擎架构如下： [0096] 分析引擎由三个部分组成：工作区域，用来存放要由引擎处理的数据集合；模块执行队列，用来存放被激活的模块运行实例；静态场景库，用来存放场景模块和模块的元数据以及与模块有关的属性，同时还提供了一组工具用来存储、分类、查询、版本控制、测试等任务，本发明提供的场景库支持文件系统或者关系数据库系统。 [0097] 参考图5，分析引擎的处理过程为： [0098] 1)定义场景，场景具有明显的单纯性，每个业务场景都有自己特有的条件以及满足条件后的操作，场景本身不关心和其他场景的关系，比如优先关系、互斥关系、包含关系等。场景模块本身也具有属性，称为模块的“元数据”，通过元数据可以定义场景之间的相关性，分析引擎就可以根据模块的优先级来依次执行模块的操作； [0099] 2)创建场景集，把场景集加载到分析引擎，本发明提供一种图形化方式，对于一些简单的业务模块可以由业务人员完全通过业务语言定义模块，对一些非常复杂的模块，业务人员和技术人员合作，通过技术语言和业务语言完成模块的定义。同时用流程图的方法定义好模块优先级； [0100] 3)向分析引擎提交待处理的数据对象集合； [0101] 4)启动分析引擎执行； [0102] 5)获得分析引擎的处理结果，根据结果下发或者不下发回执报告，从引擎中移除处理过的数据。 [0103] 此外，传统的短信回执功能由厂商实现，是固化在终端设备硬件上的。由于终端设备体积、容量、工艺限制，不能够提供灵活定制功能，只能提供启用、停用最基本的开关配置。用户要么就全盘接受，要么就全部拒绝，不能进行任何灵活定制。 [0104] 本发明把短信回执功能从终端设备彻底剥离，摆脱了对于厂商终端设备的依赖。同时引入了用户属性库设计，为用户提供了无限的自定义能力。比如，用户可以选择只关注特定用户的回执、只在某个时间段内接收回执、选择短信、闪信、彩信形式的回执，等等。 [0105] 以上介绍过短信回执的设计阶段遇到的若干问题，其实在后期推广应用中，不可避免的会有更多的变化，对未来变化作出反应的速度往往会决定企业的成败。随需变化的能力体现在以下方面：首先，需要创建一个快速响应的环境，以便对市场上任何变化作出快速反应，在业务发展早期，业务模式还不成熟，模式通常比较简单，随着业务发展和行业的成熟，业务模块会经常变化，另外就是由于市场的需求，业务模块也会发生变化。一个成熟的系统要能够适应这些模块的变化，应该让业务人员直接变更这些模块，而不是依赖开发人员的参与。 [0106] 其次，企业应对变化的成本应该最小，这就需要企业有一个有弹性的健壮的基础设施。作为一个软件产品，要能够按照市场的需求在代码不变的情况下进行定制。在软件开发周期的早期时候，许多业务模块并不明朗，模块的变化会一直贯穿从设计到编码，直至维护和运营中。因此，需要有一个框架来对这些模块进行统一的管理。像Java、EJB都只能在高端实现业务流程的构建，但不能提供具体的代码管理。本设计通过引入规则引擎，把商业决策逻辑和应用开发者的技术决策分离开来，并把这些商业决策放在中心数据库或文件中，从而提供软件系统的柔性和适应性。 [0107] 根据本发明一个实施方式的增强型短信回执的流程图可以参见图6，其具体流程如下： [0108] 1)移动网关把状态报告(包括发送成功、发送失败、暂未送达)交付给增强型短信回执平台； [0109] 2)增强型短信回执平台接受到状态报告后先提交给执行引擎，执行引擎根据用户的手机号，从数据库提取用户属性； [0110] 3)把状态报告和用户属性打包，交给场景分析引擎； [0111] 4)场景分析引擎进行若干场景模块分析，包括： [0112] 新用户模块：如果这条状态报告是用户开通业务后的第一条报告，系统会对用户进行初始化操作，给用户设置若干系统必须的属性； [0113] 电梯模块：如果是代表发送失败、暂未送达的状态报告，暂时不给用户下发，而是等待一定时间，在这个时间段内检测是否还有后续状态报告，根据后续状态报告或者超时再决定该给用户下发什么样的状态报告； [0114] 群发模块：把状态报告暂存起来，等待一定时间，如果在这个时间段内陆续收到同一个用户的多个状态报告，则用户正在做短信群发，把这个时间段内的所有状态报告进行汇总，提取目标用户号码，生成一条或者两条汇总报告； [0115] 频道模块：提取用户订阅的频道数据，用于生成附加信息； [0116] 提醒模式模块：如果用户设置了提醒模式(也就是用户只关心发送失败的状态报告，不关心发送成功的状态报告)，就把发送成功的报告丢弃，不再下发，而发送失败的状态报告继续进入下一个模块； [0117] 聊天模块：如果短时间内收到多个针对同一个接受方的状态报告，则用户和接收方正在用短信聊天，则针对该接收方暂停下发报告，以免过多报告给用户造成干扰； [0118] 指定用户模块：如果用户设置了指定模式(指定只接受某些人的状态报告，或者相反)，则根据用户设置判断是否应该下发； [0119] 内部模块：用于运营商内部设置的一些模块； [0120] 品牌模块：根据用户手机品牌(动感地带、神州行、全球通等)定义的下发模块； [0121] 屏蔽消息模块：用户只关心短信的状态报告，不希望接收附加信息； [0122] 黑名单模块：用户是否属于黑名单(比如手机炮)。 [0123] 5)根据模块引擎的分析结果，生成增强型的短信回执，传递给移动网关，最终由移动网关下发给用户。或者抛弃状态报告，不下发任何内容。 [0124] 下面给出了一些加入了场景分析的实施例： [0125] 电梯模式示例： [0126] 某月28日11:00点，用户A给用户B发送一条内容为【会议地点在三楼....】的短信，这条短信首先会被发送给短信中心； [0127] 用户B刚巧进入电梯，手机信号被屏蔽了； [0128] 短信中心第一次尝试给用户B下发短信，但是因为无法定位用户B，所以无法下发，这时会生成一条【短信暂未送达】的状态报告； [0129] 【短信暂未送达】状态报告发送给增强型短信回执平台； [0130] 增强型短信回执平台对这种【短信暂未送达】的状态报告暂时不做处理，等待下一条状态报告； [0131] 用户B出电梯后，手机信号恢复，短信中心把短信成功的发送到用户B的手机上； [0132] 短信中心生成【短信成功送达】的状态报告，并把这个报告发送给增强型短信回执平台； [0133] 增强型短信回执平台生成【短信成功送达】报告，查看用户A的个性化设置，发现用户喜欢健康信息，根据用户的喜好最终生成这样一条短信回执下发给用户A：【28日11:00致13911***短信送达。入冬养阳食物4宗最：最宜肉类-牛、羊肉；最宜调料-葱，最宜蔬菜-马铃薯，最宜饮料-红茶】 [0134] 如果因为其他原因，导致这条短信一直未能下发给用户B，增强型短信回执平台在1分钟内没能收到后续的【短信成功送达】状态报告，最后就会生成这样一条短信回执下发给用户A：【13911暂未收到您发送的短信，请稍候。入冬养阳食物4宗最：最宜肉类-牛、羊肉；最宜调料-葱，最宜蔬菜-马铃薯，最宜饮料-红茶】。 [0135] 群发模块 [0136] 除夕夜，用户A通过群发短信给20个亲朋好友发送祝福短信【新年到...】； [0137] 其中有17个发送成功，3个发送失败，短信中心会产生17个【短信成功送达】的状态报告和3个【短信暂未送达】的状态报告； [0138] 短信中心把20个状态报告发送给增强型短信回执平台； [0139] 增强型短信回执平台根据时间可以判断出这20个状态报告是用户一次群发行为所生成的，则增强型短信回执平台就会把这20个进行汇总，生成一条汇总后的报告，最后附加上一条新年祝福：【您发送的20条网内点对点短信中17条已成功送达：北京移动祝您节日快乐...】。 [0140] 聊天模块 [0141] 用户A给用户B发短信【中午去哪吃啊...】； [0142] 短信中心成功的把短信发给用户B； [0143] 短信中心生成状态报告，发给增强型短信回执平台； [0144] 增强型短信回执平台生成一个增强型状态报告，并发送给用户A：【28日11:00致13911*短信送达。入冬养阳食物4宗最：最宜肉类-牛、羊肉；最宜调料-葱，最宜蔬菜-马铃薯，最宜饮料-红茶】； [0145] 用户B回复【去...】； [0146] 用户A收到B的回复后，又给用户B发送【我知道饭店....】，重复前述步骤； [0147] 如果系统发现用户A在某个时间间隔内(比如说5分钟)，给同一个接收方(比如说用户B)，发送了多于某个数量的短信(比如说4条)，就可以断定目前用户A和用户B正在用短信聊天，太多的短信回执会给用户带来困扰，于是系统把A和B设为聊天模式； [0148] 对于A的下一个短信回执的内容是【因您在5钟内对同一号码发了4条短信，暂时进入聊天模式，之后只在对方收不到短信时才提醒您】； [0149] 随后A再发给B的短信就不再收到回执，只有发送失败时才会提示。 [0150] 如果以后系统发现用户A在某个时间间隔内(比如说5分钟)，给同一个接收方(比如说用户B)，发送了没有达到某个数量的短信(比如说4条)，就可以断定用户A和用户B已经结束了短信聊天，随后的短信就仍然正常下发回执。 [0151] 屏蔽消息模块 [0152] 有些用户(比如用户A)只关注短信的送达状态，并不喜欢后面的附加内容，这时可以把用户设置成屏蔽状态； [0153] 用户A给用户B发送短信【下午去....】； [0154] 这条短信通过短信中心发送给用户B； [0155] 短信中心生成【短信成功送达】的状态报告，发给增强型短信回执平台； [0156] 增强型短信回执平台根据用户的个性化设置，生成的短信回执中不再附加其他信息，最后发送给用户A的回执是【28日11:00致13911*****短信送达】。 [0157] 尽管仅关于上述描述的实施方式有限地说明了本发明，但本领域的普通技术人员应理解本发明不限于上述实施方式，在不偏离本发明的精神的情况下起各种修改或变型都是可能的。因此，本发明的保护范围应仅由所附的权利要求及其等同要求确定。