发明创造名称：一种基于即时通讯的服务的消息提醒方法和装置
外观设计名称：
决定号：190875
决定日：2019-09-25
委内编号：1F272120
优先权日：
申请（专利）号：201310317802.0
申请日：2013-07-25
复审请求人：腾讯科技（深圳）有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：王国纲
合议组组长：易水英
参审员：蒋莉
国际分类号：H04L12/58(2006.01);H04L29/06(2006.01)
外观设计分类号：
法律依据：专利法第22条第3款
决定要点：如果一项权利要求的技术方案与作为最接近现有技术的对比文件相比存在区别特征，该区别特征既未被其他对比文件公开，也不属于本领域公知常识，并且上述区别特征使得权利要求的技术方案能够产生有益的技术效果，则该权利要求具备创造性。
全文：
本复审请求涉及申请号为201310317802.0，名称为“一种基于即时通讯的服务的消息提醒方法和装置”的发明专利申请（下称“本申请”）。申请人为腾讯科技（深圳）有限公司。本申请的申请日为2013年07月25日，公开日为2015年02月11日。
经实质审查，国家知识产权局实质审查部门于2018年11月02日发出驳回决定，以权利要求1-13不具备专利法第22条第3款规定的创造性为由驳回了本申请。驳回决定中引用了2篇对比文件，即，对比文件1：EP2151949A1，公开日为2010年02月10日；对比文件2：CN101753358A，公开日为2010年06月23日。驳回决定的具体理由是：1、权利要求1请求保护一种基于即时通讯的服务的消息提醒方法。权利要求1与对比文件1的区别是：（1）应用场景不同；（2）构建即时消息的方式不同；（3）服务提供方通过即时通讯类软件与所述服务使用方建立关系。区别（1）、（3）属于本领域惯用手段，区别（2）被对比文件2公开。因此，基于对比文件1、对比文件2和本领域惯用手段的结合，权利要求1不具备专利法第22条第3款规定的创造性；2、权利要求5请求保护一种基于即时通讯的服务的消息提醒方法。权利要求5与对比文件1的区别是：（1）应用场景不同；（2）构建即时消息的方式不同。区别（1）属于本领域惯用手段，区别（2）被对比文件2公开。因此，基于对比文件1、对比文件2和本领域惯用手段的结合，权利要求5不具备专利法第22条第3款规定的创造性；3、权利要求2、6的附加技术特征被对比文件1公开，权利要求3-4、7-8的附加技术特征属于本领域惯用手段，当其引用的权利要求不具备创造性时，权利要求2-4、6-8不具备专利法第22条第3款规定的创造性；4、权利要求9-13是与权利要求1-5的方法权利要求对应的装置权利要求，根据方法步骤建立相应的功能模块是本领域的惯用手段，基于评述权利要求1-5的理由，权利要求9-13不具备专利法第22条第3款规定的创造性。驳回决定所依据的文本为：2018年08月01日提交的权利要求第1-13项，申请日2013年07月25日提交的说明书第1-15页、说明书附图第1-5页、说明书摘要以及摘要附图。驳回决定所针对的独立权利要求1、5、9、13的内容如下：
“1. 一种基于即时通讯的服务的消息提醒方法，其特征在于，所述方法包括：
获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
当任意一个服务提供方设置的消息逻辑对应的行为被触发时，接收所述服务提供方的触发内容，所述触发内容包括服务使用方、消息逻辑和消息可变内容；其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立关系；
在所述服务提供方的申请请求中，获取与所述消息逻辑对应的消息内容模板；
将所述消息可变内容添加到所述消息内容模板后，得到待发消息；
将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方。”
“5. 一种基于即时通讯的服务的消息提醒方法，其特征在于，所述方法包括：
任一服务提供方将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
当所述服务提供方设置的消息逻辑对应的行为被触发时，所述服务提供方将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
所述服务使用方接收来自所述消息提醒服务器的待发消息，所述待发消息为所述消息提醒服务器将所述消息可变内容添加到所述消息逻辑对应的消息内容模板后得到的。”
“9. 一种基于即时通讯的服务的消息提醒装置，其特征在于，所述装置包括：
第一获取模块，用于获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
第一接收模块，用于当任意一个服务提供方设置的消息逻辑对应的行为被触发时，接收所述服务提供方的触发内容，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
第二获取模块，用于在所述服务提供方的申请请求中，获取与所述消息逻 辑对应的消息内容模板；
添加模块，用于将所述消息可变内容添加到所述消息内容模板后，得到待发消息；
第一发送模块，用于将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方。”
“13. 一种基于即时通讯的服务的消息提醒装置，其特征在于，所述装置包括：
第一发送模块，用于将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
第二发送模块，用于在设置的消息逻辑对应的行为被触发时，将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
接收模块，用于接收来自所述消息提醒服务器的待发消息，所述待发消息为所述消息提醒服务器将所述消息可变内容添加到所述消息逻辑对应的消息内容模板后得到的。”
申请人（下称“复审请求人”）对上述驳回决定不服，于2019年01月24日向国家知识产权局提出了复审请求，同时提交了权利要求书的全文修改替换页。修改之处是：在权利要求5、9、13中增加特征“其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立关系”。复审请求人认为：对比文件1并未公开服务提供方通过即时通讯类软件与服务使用方建立关系，而本申请通过即时通讯类软件在服务提供方和服务使用方之间建立关系，具体地，服务使用方通过即时通讯类软件与服务提供方进行交互动作，该交互动作满足服务提供方中设置的消息逻辑；服务提供方在其设置的消息逻辑对应的行为被触发时形成待发消息，并通过即时通讯类软件将待发消息发送至服务使用方，使得服务使用方的操作流程形成闭环，进而能够在即时通讯平台用户关系的基础上，使用即时通讯类软件完成消息提醒，提高消息提醒的效率，增强用户体验。对比文件2中也未公开服务提供方通过即时通讯类软件与服务使用方建立关系，以使服务使用方的操作流程形成闭环。复审请求时修改的独立权利要求5、9、13的内容如下：
“5. 一种基于即时通讯的服务的消息提醒方法，其特征在于，所述方法包括：
任一服务提供方将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
当所述服务提供方设置的消息逻辑对应的行为被触发时，所述服务提供方将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
所述服务使用方接收来自所述消息提醒服务器的待发消息，所述待发消息为所述消息提醒服务器将所述消息可变内容添加到所述消息逻辑对应的消息内容模板后得到的；
其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立关系。”
“9. 一种基于即时通讯的服务的消息提醒装置，其特征在于，所述装置包括：
第一获取模块，用于获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
第一接收模块，用于当任意一个服务提供方设置的消息逻辑对应的行为被触发时，接收所述服务提供方的触发内容，所述触发内容包括服务使用方、消息逻辑和消息可变内容；其中，所述服务提供方通过即时通讯类软件与所述服 务使用方建立关系；
第二获取模块，用于在所述服务提供方的申请请求中，获取与所述消息逻辑对应的消息内容模板；
添加模块，用于将所述消息可变内容添加到所述消息内容模板后，得到待发消息；
第一发送模块，用于将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方。”
“13. 一种基于即时通讯的服务的消息提醒装置，其特征在于，所述装置包括：
第一发送模块，用于将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
第二发送模块，用于在设置的消息逻辑对应的行为被触发时，将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
接收模块，用于接收来自所述消息提醒服务器的待发消息，所述待发消息为所述消息提醒服务器将所述消息可变内容添加到所述消息逻辑对应的消息内容模板后得到的；
其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立关系。”
经形式审查合格，国家知识产权局于2019年02月13日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中认为:1、对比文件1公开了针对短消息传送告警信息所存在的缺陷，采取了网管系统通过即时通讯软件向维护人员发送即时消息实现告警信息提醒的技术方案，克服了通过短消息发送提醒消息的缺陷，因此，对比文件1与本申请的发明构思相同；同时，二者系统架构相同，均包含了消息发送方、消息接收方和即时消息服务器，且通过发送即时消息实现消息的提醒的流程基本一致，均为消息发送方通过即时通讯服务器向消息接收方发送即时消息实现消息的提醒。虽然本申请与对比文件1的应用场景不同，但是具有相似功能的网元设备分别在不同应用场景下具有不同的名称，这属于本领域的常规技术手段，并且这种不同也没有为所述基于即时系统进行消息提醒的方法流程以及系统架构上带来实质上的变化，在对比文件1已公开了网管系统通过即时通讯软件向维护人员进行告警信息的提醒的基础上，本领域技术人员有动机将对比文件1中公开的消息发送方通过即时通讯系统向消息接收方发送即时消息实现信息的提醒的方案应用到服务提供方向服务使用方进行消息的提醒的过程，从而达到基于正在使用的即时通讯软件直接为商户提供向客户的消息提醒功能的有益效果，不需要付出创造性的劳动。而且，对比文件1中接收方维护人员是网管系统的MSN的好友列表成员，因此，网管系统与维护人员必然通过MSN这一即时通讯软件建立了关系。2、对比文件1中只是公开了将告警信息和该告警信息的接收方维护人员的身份标识组成告警即时消息，这种构建即时消息的方案客观上存在效率低的技术问题，对比文件2公开了告警产生后，网管系统统计关键告警信息，填充告警信息模板的内容，即为关键告警信息，网管系统将根据即时消息接收地址发送详细告警信息，因此，对比文件2公开了通过填充消息模板来构建待发送的即时消息，使得即时消息的构建方便快捷，效率高，当本领域技术人员面对如何提高即时消息的构建效率的技术问题时，有动机结合对比文件2公开的通过填充消息模板来构建待发送的即时消息的技术方案，使得即时消息的构建方便快捷而高效。3、对比文件1与对比文件2中均由消息发送方进行待发送即时消息的构建，其客观上存在的缺陷是终端设备相对于服务器而言由于其存储能力、运行能力、处理能力存在很大差距；本领域技术人员在面对如何提高系统的处理效率时，能够想到将多个终端的同类型功能，比如构建即时消息，集成到服务器设备上，由服务器设备来完成，不需要付出创造性的劳动。因而坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年07月25日向复审请求人发出复审通知书，本次复审通知书所针对的审查文本是：2019年01月24日提交的权利要求第1-13项，申请日2013年07月25日提交的说明书第1-15页、说明书附图第1-5页、说明书摘要以及摘要附图。该复审通知书引用了与驳回决定相同的对比文件1和对比文件2，指出：权利要求1-4、9-12相对于对比文件1、对比文件2和本领域惯用手段的结合不具备专利法第22条第3款规定的创造性。并针对复审请求人的意见进行了评述。
复审请求人于2019年08月15日提交了意见陈述书和权利要求书的全文修改替换页。修改之处是：将权利要求1、9中的“建立关系”修改为“建立交互关系”。
复审请求人于2019年08月22日主动提交了意见陈述书和权利要求书的全文修改替换页。修改之处是：将权利要求1、5、9、13中的“建立关系”修改为“建立交互关系”。复审请求人于2019年08月22日提交的权利要求书的内容如下：
“1. 一种基于即时通讯的服务的消息提醒方法，其特征在于，所述方法包括：
获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
当任意一个服务提供方设置的消息逻辑对应的行为被触发时，接收所述服务提供方的触发内容，所述触发内容包括服务使用方、消息逻辑和消息可变内容；其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立交互关系；
在所述服务提供方的申请请求中，获取与所述消息逻辑对应的消息内容模板；
将所述消息可变内容添加到所述消息内容模板后，得到待发消息；
将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方。
2. 根据权利要求1所述的方法，其特征在于，所述获取服务提供方的申请请求，所述申请请求包括消息内容模板和消息逻辑的对应关系之前，还包括：
根据预设标准，对服务提供方的申请请求进行验证，如果通过验证，则继续执行所述获取服务提供方的申请请求。
3. 根据权利要求1所述的方法，其特征在于，所述获取服务提供方的申请请求，所述申请请求包括消息内容模板和消息逻辑的对应关系之后，且在所述接收任一服务提供方的触发内容，所述触发内容包括服务使用方、消息逻辑和消息可变内容之前，还包括：
对所述服务提供方的申请请求进行调试，如果调试成功，则继续执行所述接收任一服务提供方的触发内容。
4. 根据权利要求3所述的方法，其特征在于，所述方法之后，还包括：
保存操作日志；
将所述操作日志发送至所述服务提供方。
5. 一种基于即时通讯的服务的消息提醒方法，其特征在于，所述方法包括：
任一服务提供方将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
当所述服务提供方设置的消息逻辑对应的行为被触发时，所述服务提供方将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
所述服务使用方接收来自所述消息提醒服务器的待发消息，所述待发消息为所述消息提醒服务器将所述消息可变内容添加到所述消息逻辑对应的消息内容模板后得到的；
其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立交互关系。
6. 根据权利要求5所述的方法，其特征在于，所述任一服务提供方将申请请求传送至消息提醒服务器，还包括：
所述服务提供方将所述申请请求发送至所述消息提醒服务器进行验证，如果通过验证，则继续执行所述服务提供方将申请请求传送至消息提醒服务器。
7. 根据权利要求5所述的方法，其特征在于，所述任一服务提供方将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板和消息逻辑的对应关系之后，且在所述服务提供方将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容之前，所述方法还包括：
所述服务提供方对所述申请请求进行调试，如果调试成功，则继续执行所述服务提供方将触发内容发送至所述消息提醒服务器。
8. 根据权利要求7所述的方法，其特征在于，所述方法之后，还包括：
所述服务提供方接收操作日志，所述操作日志为所述消息提醒服务器保存的。
9. 一种基于即时通讯的服务的消息提醒装置，其特征在于，所述装置包括：
第一获取模块，用于获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
第一接收模块，用于当任意一个服务提供方设置的消息逻辑对应的行为被触发时，接收所述服务提供方的触发内容，所述触发内容包括服务使用方、消息逻辑和消息可变内容；其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立交互关系；
第二获取模块，用于在所述服务提供方的申请请求中，获取与所述消息逻辑对应的消息内容模板；
添加模块，用于将所述消息可变内容添加到所述消息内容模板后，得到待发消息；
第一发送模块，用于将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方。
10. 根据权利要求9所述的装置，其特征在于，所述装置，还包括：
验证模块，用于根据预设标准，对服务提供方的申请请求进行验证，如果通过验证，则继续执行所述获取服务提供方的申请请求。
11. 根据权利要求9所述的装置，其特征在于，所述装置，还包括：
调试模块，用于对所述服务提供方的申请请求进行调试，如果调试成功，则继续执行所述接收任一服务提供方账户的触发内容。
12. 根据权利要求11所述的装置，其特征在于，所述装置，还包括：
保存模块，用于保存操作日志；
第二发送模块，用于将所述操作日志发送至所述服务提供方。
13. 一种基于即时通讯的服务的消息提醒装置，其特征在于，所述装置包括：
第一发送模块，用于将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；
第二发送模块，用于在设置的消息逻辑对应的行为被触发时，将触发内容发送至所述消息提醒服务器，所述触发内容包括服务使用方、消息逻辑和消息可变内容；
接收模块，用于接收来自所述消息提醒服务器的待发消息，所述待发消息为所述消息提醒服务器将所述消息可变内容添加到所述消息逻辑对应的消息内容模板后得到的；
其中，所述服务提供方通过即时通讯类软件与所述服务使用方建立交互关系。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出复审请求审查决定。
二、决定的理由
1、审查文本的认定
复审请求人在复审程序中提交了权利要求书的全文修改替换页。本复审请求审查决定所针对的文本是：2019年08月22日提交的权利要求第1-13项，申请日2013年07月25日提交的说明书第1-15页、说明书附图第1-5页、说明书摘要以及摘要附图。经审查，上述文本的修改之处符合专利法第33条的规定。
2、关于专利法第22条第3款
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
本复审请求审查决定引用的对比文件与驳回决定、复审通知书引用的对比文件相同，即：
对比文件1：EP2151949A1，公开日为2010年02月10日；
对比文件2：CN101753358A，公开日为2010年06月23日。
（1）权利要求1具备专利法第22条第3款规定的创造性。
权利要求1请求保护一种基于即时通讯的服务的消息提醒方法。对比文件1公开了一种告警信息通知的方法、装置及系统，其具体公开了（参见对比文件1的权利要求1-5、10-14，说明书第[0035]-[0137]段，附图1-10）：本实施例将即时消息适配装置集成在了网管系统中，本实施例以微软的MSN为例，说明通过即时消息发送告警信息的方法，包括以下步骤：步骤301、在网管系统上采用图形界面的方式预先设置即时消息的类型及其对应即时消息服务器信息，告警信息的接收方维护人员的身份标识，以及发送告警即时消息的条件进行设定（相当于“申请请求”），如附图4所示，在MSN中，发送方ID是venky_dude@hotmail.com，接收方ID是deadxxx@hotmail.com，如附图5所示，设置的含义是：仅在NE100、NE50或NE400这三部设备范围内，当发生CPU越界、过载告警或链接通讯中断的紧急告警的情况下，才发送告警即时消息。步骤302、网管系统与即时消息服务器建立通信连接，采用双方都支持的版本进行通讯。步骤303、即时消息服务器进行用户身份认证。步骤304、网管系统将自身在MSN上的状态信息改为在线，并向即时消息服务器发送请求，获取自身的好友列表。即时消息服务器在响应消息中返回网管系统在MSN上的好友列表，所述好友列表包括维护人员的标识。步骤305、电信设备通过设备与网管的接口上报告警信息到网管系统。步骤306-307、网管系统接收到电信设备上报的告警信息后（相当于“当服务提供方设置的消息逻辑对应的行为被触发时”），将该告警信息及该告警信息的接收方维护人员的身份标识（相当于“接收所述服务提供方的触发内容，所述触发内容包括服务使用方”）组成告警即时消息（相当于“得到待发消息”），通过上述的通信连接，发送给即时消息服务器。步骤308、即时消息服务器根据所述维护人员身份标识，将所述告警即时消息发送到该维护人员的即时消息接收装置（相当于“将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方”）。
权利要求1和对比文件1的区别技术特征是：该权利要求中，获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；所述触发内容还包括消息可变内容，将所述消息可变内容添加到所述消息内容模板后，得到待发消息；所述服务提供方通过即时通讯类软件与所述服务使用方建立交互关系。基于所述区别技术特征，权利要求1实际解决的技术问题是：在即时通讯平台用户关系的基础上，如何提高消息提醒的效率、增强用户体验。
本申请中，服务提供方通过即时通讯类软件与服务使用方建立交互关系（参见本申请说明书公开文本说明书第[0056]段），例如，普通微信用户账号与酒店官方微信账号建立关系，用户在所述“建立关系”中可以预定酒店（参见本申请说明书公开文本第[0106]-[0124]段）。在这样的应用环境中，即，在即时通讯平台用户交互关系的基础上，本申请要解决的技术问题是如何提高消息提醒的效率、进而增强用户体验。为了解决此技术问题，本申请权利要求1的技术方案中，首先，获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；其次，在接收服务提供方的触发内容后，获取服务使用方、消息逻辑和消息可变内容；再次，在申请请求中获取与所述消息逻辑对应的消息内容模板，并将消息可变内容添加到消息内容模板后，得到待发消息；最后，将该待发消息发送至服务使用方，以便起到提醒该服务使用方的作用。由此可知，本申请的技术方案中，不同的服务提供方根据其需求可以发出不同的申请请求，每个服务提供方可以提供多种不同的消息类型，例如，多种不同的可变内容。本申请技术方案中放弃使用传统的短信消息提醒功能，而在即时通讯用户关系的基础上，采用即时通讯实现消息的提醒，增强了用户的体验，并且，该过程不需要花费时间重新获取手机号码，避免了用户隐私的泄露，同时，由于用户不必退出微信而打开短信查看消息，从而提升了消息提醒的效率。而对比文件1中，虽然网管系统与接收方维护人员之间经由即时消息服务器建立连接，但是，网管系统只是将来自电信设备的告警信息经由即时消息服务器转发给接收方维护人员，二者之间并不是一种基于应用而建立的交互关系，接收方维护人员不能向电信设备/网管系统发送其他应用消息，仅能从电信设备/网管系统接收告警信息。在此基础上，对比文件1要解决的技术问题是如何提高传送告警信息的及时性和发送效率，在其技术方案中，告警消息的内容是固定不变的，没有公开“内容模板”、“消息逻辑”、“不可变内容”等技术内容，其技术效果是以即时通信消息的方式发送告警信息，提高告警信息的发送效率。综上，本申请权利要求1的技术方案与对比文件1公开的技术内容在技术问题、技术手段、技术效果上均不同。
对比文件2公开了一种告警信息通知的方法及系统，其要解决的技术问题是：若单独使用短消息的方式发送告警信息，则由于短消息在信息长度方面受到限制，导致告警信息被拆成多条短消息，接收后还需要按顺序先后阅读，导致效率低；若单独使用即时消息的方式发送告警信息，则由于接收方可能不在线，导致不能及时得知告警的发生而采取解决措施，或者，由于服务商可能会暂停服务或终止一些账户的使用，导致用户除了直接在网管系统上操作外，缺少其他增加即时消息接收地址的方法，降低了系统的易用性（参见对比文件2说明书第[0002]-[0007]段）。为了解决此技术问题，对比文件2采用了混合短消息和即时消息的方式发送告警信息，具体是：告警产生后，网管系统统计关键告警信息，并根据用户设置的短消息号码发送关键告警信息的短消息；网管系统接收确认短消息，并确定即时消息接收地址；网管系统将根据即时消息接收地址发送详细告警信息，用户分析详细告警信息的内容，对故障设备进行维护（参见对比文件2说明书第[0029]-[0070]段）。对比文件2取得的技术效果是：使用短消息和即时消息结合的方式发送告警信息，可以及时得知告警信息及其详细内容，使设备的故障问题及时得到解决，提高了系统的易用性（参见对比文件2说明书第[0022]段）。由此可知，对比文件2中，网管系统只是将告警信息以短消息和即时消息的方式发送给用户，网管系统和用户之间并不是一种基于应用而建立的交互关系，用户不能向网管系统发送其他应用消息，仅能从网管系统接收告警信息。虽然对比文件2中公开了“告警信息模板”，但是，其没有公开“可变内容”，对比文件2中由告警信息模板生成的告警信息的内容也是固定不变的。基于上述分析，本申请权利要求1的技术方案与对比文件2公开的技术内容在技术问题、技术手段、技术效果上均不同。对比文件1和对比文件2均没有给出相关技术启示。
此外，也没有证据表明区别特征是本领域的公知常识。
综上，对本领域的技术人员来说，权利要求1请求保护的技术方案相对于对比文件1、对比文件2及本领域公知常识的结合是非显而易见的。进一步的，上述区别特征使得权利要求1的技术方案能够实现以下有益的技术效果：在即时通讯用户交互关系的基础上，采用即时通讯实现消息的提醒，增强了用户的体验，并且，该过程不需要花费时间重新获取手机号码，避免了用户隐私的泄露，同时，由于用户不必退出微信而打开短信查看消息，从而提升了消息提醒的效率。权利要求1请求保护的技术方案具有突出的实质性特点和显著的进步，权利要求1具备专利法第22条第3款规定的创造性。
（2）权利要求2-4具备专利法第22条第3款规定的创造性。
权利要求2-4直接或间接地引用权利要求1。因此，在其引用的权利要求具备创造性的情况下，权利要求2-4具备专利法第22条第3款规定的创造性。
（3）权利要求5具备专利法第22条第3款规定的创造性。
权利要求5请求保护一种基于即时通讯的服务的消息提醒方法。对比文件1公开了一种告警信息通知的方法、装置及系统，其具体公开了（参见对比文件1的权利要求1-5、10-14，说明书第[0035]-[0137]段，附图1-10）：本实施例将即时消息适配装置集成在了网管系统中，本实施例以微软的MSN为例，说明通过即时消息发送告警信息的方法，包括以下步骤：步骤301、在网管系统上采用图形界面的方式预先设置即时消息的类型及其对应即时消息服务器信息，告警信息的接收方维护人员的身份标识，以及发送告警即时消息的条件进行设定（相当于“申请请求”），如附图4所示，在MSN中，发送方ID是venky_dude@hotmail.com，接收方ID是deadxxx@hotmail.com，如附图5所示，设置的含义是：仅在NE100、NE50或NE400这三部设备范围内，当发生CPU越界、过载告警或链接通讯中断的紧急告警的情况下，才发送告警即时消息。步骤302、网管系统与即时消息服务器建立通信连接，采用双方都支持的版本进行通讯。步骤303、即时消息服务器进行用户身份认证。步骤304、网管系统将自身在MSN上的状态信息改为在线，并向即时消息服务器发送请求，获取自身的好友列表。即时消息服务器在响应消息中返回网管系统在MSN上的好友列表，所述好友列表包括维护人员的标识。步骤305、电信设备通过设备与网管的接口上报告警信息到网管系统。步骤306-307、网管系统接收到电信设备上报的告警信息后（相当于“当服务提供方设置的消息逻辑对应的行为被触发时”），将该告警信息及该告警信息的接收方维护人员的身份标识（相当于“接收所述服务提供方的触发内容，所述触发内容包括服务使用方”）组成告警即时消息（相当于“得到待发消息”），通过上述的通信连接，发送给即时消息服务器。步骤308、即时消息服务器根据所述维护人员身份标识，将所述告警即时消息发送到该维护人员的即时消息接收装置（相当于“将所述待发消息发送至所述服务使用方，以便提醒所述服务使用方”）。
权利要求5和对比文件1的区别技术特征是：该权利要求中，任一服务提供方将申请请求传送至消息提醒服务器，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；消息提醒服务器接收触发内容，所述触发内容还包括消息可变内容；消息提醒服务器将所述消息可变内容添加到所述消息内容模板后，得到待发消息；所述服务提供方通过即时通讯类软件与所述服务使用方建立交互关系。基于所述区别技术特征，权利要求5实际解决的技术问题是：在即时通讯平台用户关系的基础上，如何提高消息提醒的效率、增强用户体验。
本申请中，服务提供方通过即时通讯类软件与服务使用方建立交互关系（参见本申请说明书公开文本说明书第[0056]段），例如，普通微信用户账号与酒店官方微信账号建立关系，用户在所述“建立关系”中可以预定酒店（参见本申请说明书公开文本第[0106]-[0124]段）。在这样的应用环境中，即，在即时通讯平台用户交互关系的基础上，本申请要解决的技术问题是如何提高消息提醒的效率、进而增强用户体验。为了解决此技术问题，本申请权利要求5的技术方案中，首先，获取各个服务提供方的申请请求，所述申请请求包括消息内容模板、消息逻辑以及所述消息内容模板和所述消息逻辑的对应关系；所述消息内容模板包括消息内容中的不可变内容，以及消息的基本格式；其次，接收到服务提供方的触发内容后，消息提醒服务器获取服务使用方、消息逻辑和消息可变内容；再次，在申请请求中获取与所述消息逻辑对应的消息内容模板，消息提醒服务器将消息可变内容添加到消息内容模板后，得到待发消息；最后，消息提醒服务器将该待发消息发送至服务使用方，以便起到提醒该服务使用方的作用。由此可知，本申请的技术方案中，不同的服务提供方根据其需求可以发出不同的申请请求，每个服务提供方可以提供多种不同的消息类型，例如，多种不同的可变内容，并且，由消息提醒服务器执行待发消息的生成。本申请技术方案中放弃使用传统的短信消息提醒功能，而在即时通讯用户关系的基础上，采用即时通讯实现消息的提醒，增强了用户的体验，并且，该过程不需要花费时间重新获取手机号码，避免了用户隐私的泄露，同时，由于用户不必退出微信而打开短信查看消息，从而提升了消息提醒的效率。而对比文件1中，虽然网管系统与接收方维护人员之间经由即时消息服务器建立连接，但是，网管系统只是将来自电信设备的告警信息经由即时消息服务器转发给接收方维护人员，二者之间并不是一种基于应用而建立的交互关系，接收方维护人员不能向电信设备/网管系统发送其他应用消息，仅能从电信设备/网管系统接收告警信息，另外，对比文件1虽然公开了即时消息服务器，但是所述即时消息服务器仅仅是转发告警信息，其并不生成即时消息，即，权利要求5中的消息提醒服务器不同于对比文件1中的即时消息服务器。在此基础上，对比文件1要解决的技术问题是如何提高传送告警信息的及时性和发送效率，在其技术方案中，告警消息的内容是固定不变的，没有公开“内容模板”、“消息逻辑”、“不可变内容”等技术内容，其技术效果是以即时通信消息的方式发送告警信息，提高告警信息的发送效率。综上，本申请权利要求5的技术方案与对比文件1公开的技术内容在技术问题、技术手段、技术效果上均不同。
对比文件2公开了一种告警信息通知的方法及系统，其要解决的技术问题是：若单独使用短消息的方式发送告警信息，则由于短消息在信息长度方面受到限制，导致告警信息被拆成多条短消息，接收后还需要按顺序先后阅读，导致效率低；若单独使用即时消息的方式发送告警信息，则由于接收方可能不在线，导致不能及时得知告警的发生而采取解决措施，或者，由于服务商可能会暂停服务或终止一些账户的使用，导致用户除了直接在网管系统上操作外，缺少其他增加即时消息接收地址的方法，降低了系统的易用性（参见对比文件2说明书第[0002]-[0007]段）。为了解决此技术问题，对比文件2采用了混合短消息和即时消息的方式发送告警信息，具体是：告警产生后，网管系统统计关键告警信息，并根据用户设置的短消息号码发送关键告警信息的短消息；网管系统接收确认短消息，并确定即时消息接收地址；网管系统将根据即时消息接收地址发送详细告警信息，用户分析详细告警信息的内容，对故障设备进行维护（参见对比文件2说明书第[0029]-[0070]段）。对比文件2取得的技术效果是：使用短消息和即时消息结合的方式发送告警信息，可以及时得知告警信息及其详细内容，使设备的故障问题及时得到解决，提高了系统的易用性（参见对比文件2说明书第[0022]段）。由此可知，对比文件2中，网管系统只是将告警信息以短消息和即时消息的方式发送给用户，网管系统和用户之间并不是一种基于应用而建立的交互关系，用户不能向网管系统发送其他应用消息，仅能从网管系统接收告警信息。虽然对比文件2中公开了“告警信息模板”，但是，其没有公开“可变内容”，对比文件2中由告警信息模板生成的告警信息的内容也是固定不变的。基于上述分析，本申请权利要求5的技术方案与对比文件2公开的技术内容在技术问题、技术手段、技术效果上均不同。对比文件1和对比文件2均没有给出相关技术启示。
此外，也没有证据表明区别特征是本领域的公知常识。
综上，对本领域的技术人员来说，权利要求5请求保护的技术方案相对于对比文件1、对比文件2及本领域公知常识的结合是非显而易见的。进一步的，上述区别特征使得权利要求5的技术方案能够实现以下有益的技术效果：在即时通讯用户交互关系的基础上，采用即时通讯实现消息的提醒，增强了用户的体验，并且，该过程不需要花费时间重新获取手机号码，避免了用户隐私的泄露，同时，由于用户不必退出微信而打开短信查看消息，从而提升了消息提醒的效率。权利要求5请求保护的技术方案具有突出的实质性特点和显著的进步，权利要求5具备专利法第22条第3款规定的创造性。
（4）权利要求6-8具备专利法第22条第3款规定的创造性。
权利要求6-8直接或间接地引用权利要求5。因此，在其引用的权利要求具备创造性的情况下，权利要求6-8具备专利法第22条第3款规定的创造性。
（5）权利要求9-13具备专利法第22条第3款规定的创造性。
权利要求9-13是与方法权利要求1-5对应的装置权利要求。基于权利要求1-5评述的类似理由，权利要求9-13具备专利法第22条第3款规定的创造性。
三、决定
撤销国家知识产权局于2018年11月02日对本申请作出的驳回决定。由国家知识产权局实质审查部门以本复审请求审查决定依据的审查文本为基础继续进行审批程序。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可以自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
