发明创造名称：一种推送消息的管理方法及装置
外观设计名称：
决定号：201691
决定日：2020-01-14
委内编号：1F287955
优先权日：
申请（专利）号：201310687892.2
申请日：2013-12-13
复审请求人：腾讯科技（深圳）有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：郝悦
合议组组长：傅海望
参审员：赵红艳
国际分类号：H04W4/12,H04W88/02,H04M1/725
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果一项权利要求中记载的技术方案与对比文件存在区别特征，但是该区别特征是本领域的惯用手段，在所述对比文件的基础上结合本领域的惯用手段得到所述权利要求的技术方案，对本领域的技术人员来说是显而易见的，那么该权利要求不具备创造性。
全文：
本复审请求涉及申请号为201310687892.2，名称为“一种推送消息的管理方法及装置”的发明专利申请（下称本申请）。申请人为腾讯科技（深圳）有限公司。本申请的申请日为2013年12月13日，公开日为2015年06月17日。
经实质审查，国家知识产权局原审查部门于2019年03月04日发出驳回决定，驳回了本申请，其理由是：权利要求1-14要求保护的技术方案相对于对比文件1和本领域惯用手段的结合不具备突出的实质性特点和显著的进步，不具备专利法第22条第3款规定的创造性。驳回决定所依据的文本为：申请日2013年12月13日提交的说明书第1-77段（即第1-8页），说明书附图第1页，说明书摘要，摘要附图；2019年01月24日提交的权利要求书第1-14项。驳回决定引用的对比文件为：
对比文件1：“拒绝恼人推送信息 教你肃清安卓通知栏”，http://tech.sina.com.cn/mobile/n/2013-04-26/08128284482.shtml，公开日为2013年04月26日。驳回决定所针对的权利要求书的内容如下：
“1. 一种推送消息的管理方法，其特征在于，包括：
获取移动终端操作系统的超级用户权限；
利用所述超级用户权限扫描所述移动终端的消息推送环境，展示扫描结果；
检测用户对其选定的所述扫描结果的操作指令；
根据检测到的所述操作指令，对所述移动终端进行推送消息管理；
其中，所述利用所述超级用户权限扫描所述移动终端的消息推送环境包括：
利用所述超级用户权限扫描安装在所述移动终端中的具备消息推送功能的应用程序；
其中，利用所述超级用户权限扫描安装在所述移动终端中的具备消息推送功能的应用程序包括：
对所述移动终端中的应用程序安装情况进行扫描，通过读取所述移动终端中的应用程序的配置文件，判断所述移动终端中的应用程序是否向所述移动终端的操作系统注册了消息推送事件，查找出安装在所述移动终端中的、具备消息推送功能的应用程序。
2. 如权利要求1所述的方法，其特征在于，所述操作指令包括启用或者禁用消息推送功能，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理包括：
批量启用或者禁用用户选定的所述应用程序的消息推送功能。
3. 如权利要求2所述的方法，其特征在于，所述操作指令还包括预设的系统时间段，所述批量启用或者禁用用户选择的所述应用程序的消息推送功能具体为：
在所述预设的系统时间段内启用或者禁用用户选定的所述应用程序的消息推送功能。
4. 如权利要求1所述的方法，其特征在于，所述操作指令包括消息推送数量上限，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理 包括：
设置用户选定的所述应用程序每天的消息推送数量不超过所述消息推送数量上限。
5. 如权利要求1所述的方法，其特征在于，所述利用所述超级用户权限扫描所述移动终端的消息推送环境包括：
利用所述超级用户权限扫描当前已推送到所述移动终端系统通知栏的推送消息。
6. 如权利要求5所述的方法，其特征在于，所述操作指令包括清除推送消息，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理包括：
清除用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息。
7. 如权利要求5所述的方法，其特征在于，所述操作指令包括消息来源显示，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理包括：
获取并显示用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息的消息来源。
8. 一种推送消息的管理装置，其特征在于，包括：
获取单元，用于获取移动终端操作系统的超级用户权限；
扫描单元，用于利用所述超级用户权限扫描所述移动终端的消息推送环境，展示扫描结果；
检测单元，用于检测用户对其选定的所述扫描结果的操作指令；
管理单元，用于根据检测到的所述操作指令，对所述移动终端进行推送消息管理；
所述扫描单元具体用于：
利用所述超级用户权限扫描安装在所述移动终端中的具备消息推送功能的应用程序；
其中，所述扫描单元具体还用于：
对所述移动终端中的应用程序安装情况进行扫描，通过读取所述移动终端 中的应用程序的配置文件，判断所述移动终端中的应用程序是否向所述移动终端的操作系统注册了消息推送事件，查找出安装在所述移动终端中的、具备消息推送功能的应用程序。
9. 如权利要求8所述的装置，其特征在于，所述操作指令包括启用或者禁用消息推送功能，所述管理单元具体用于：
批量启用或者禁用用户选定的所述应用程序的消息推送功能。
10. 如权利要求9所述的装置，其特征在于，所述操作指令还包括预设的系统时间段，所述管理单元具体用于：
在所述预设的系统时间段内启用或者禁用用户选定的所述应用程序的消息推送功能。
11. 如权利要求8所述的装置，其特征在于，所述操作指令包括消息推送数量上限，所述管理单元具体用于：
设置用户选定的所述应用程序每天的消息推送数量不超过所述消息推送数量上限。
12. 如权利要求8所述的装置，其特征在于，所述扫描单元具体用于：
利用所述超级用户权限扫描当前已推送到所述移动终端系统通知栏的推送消息。
13. 如权利要求12所述的装置，其特征在于，所述操作指令包括清除推送消息，所述管理单元具体用于：
清除用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息。
14. 如权利要求12所述的装置，其特征在于，所述操作指令包括消息来源显示，所述管理单元具体用于：
获取并显示用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息的消息来源。”
申请人（下称复审请求人）对上述驳回决定不服,于2019年06月18日向国家知识产权局提出了复审请求，同时修改了权利要求书，其中将从属权利要求2和9分别并入独立权利要求1和8，并适应性调整了权利要求的编号。复审请求人认为：1）对比文件1是新浪网的一个网页，该网页的真实发布时间可能通过非法手段被修改，审查意见并未证明该网页的内容在本申请的申请日之后没有被补充和修改，审查意见也并未证明该网页的内容在本申请的申请日之前已对外公开，不能保证任何本领域技术人员都能在发布日期获知该网页的全部内容，因此复审请求人不能接受将该网络证据作为本申请的对比文件。2）即便有证据或公证文件能够证明上述对比文件1对应的网站真实存在，且其中的全部内容都是在本申请的申请日之前公开的，修改后的权利要求1相比于对比文件1也具有创造性：i)对比文件1所示的方案中的“屏蔽该应用的推送消息”，并不是通过禁用应用程序的消息推送功能来实现的，在终端中对一个应用的推送消息进行屏蔽，是指在通知栏中对该应用的推送消息不予显示，也就是说，当对一个一个应用的推送消息进行屏蔽，是指该应用可以向系统的通知栏发送推送消息，但是通知栏并不会将该推送消息进行显示，而是直接将其隐藏，或者直接将其丢弃；ii）终端中的应用程序并不都是具有消息推送功能的，在对比文件1所示的方案中，用户在“通知栏管理”中点选“程序权限”之后，终端会显示手机中安装的全部程序的列表，也就是说，对比文件1所示的方案并未考虑列表中的应用是否具有消息推送功能，相应的，也不会对用户选择的应用进行消息推送功能的禁用，其更可能的实现方式是在通知栏中对用户选择的应用发送的推送消息进行拦截过滤；iii）对比文件1未公开通过超级用户权限批量启用或者禁用用户选定的应用程序的消息推送功能。通过超级用户权限批量启用或者禁用用户选定的应用程序的消息推送功能，实现对应用程序的消息推送功能的快速启用或者禁用，从而解决了“如何快速启用或者禁用移动终端中安装的应用程序的消息推送功能”的技术问题，达到简化用户启用或者禁用移动终端中安装的应用程序的消息推送功能的步骤，提高应用程序的消息推送功能的管理效率的效果，不是本领域技术人员的惯用技术手段。
经形式审查合格，国家知识产权局于2019年06月26日依法受理了该复审请求，并将其转送至原审查部门进行前置审查。
原审查部门在前置审查意见书中认为，在无证据证明网络证据虚假，且在多个信誉较高的网站均公开了的情况下，应认可其所公开内容的真实性，其公开时间和内容应以该网络证据网页上记载的时间为准，并且网络平台采取的是覆盖上传的方式，即修改后的内容会显示更新时间，在此基础上，权利要求1-12仍不具备创造性，因而坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年09月29日向复审请求人发出复审通知书，该复审通知书依据的审查文本为：申请日2013年12月13日提交的说明书第1-8页，说明书附图第1页，说明书摘要，摘要附图；2019年06月18日提交的权利要求书第1-12项。复审通知书引用的对比文件与驳回决定引用的对比文件相同，即对比文件1。复审通知书指出：权利要求1-12相对于对比文件1和本领域惯用手段的结合不具备专利法第22条第3款规定的创造性；同时针对复审请求人的复审请求意见进行了答复。
复审请求人于2019年11月14日提交了意见陈述书，并提交了权利要求书全文修改替换页，其中将从属权利要求2和3并入独立权利要求1，将从属权利要求8和9并入独立权利要求7，并适应性调整了权利要求的编号。复审请求人认为：对比文件1未公开如何对终端中安装的各个应用的推送消息分别进行自定义的实现方式，而在修改后的权利要求1中用户可以通过对选定的扫描结果的操作，控制终端在预设的系统时间段内启用或禁用应用程序的消息推送功能，或控制终端设置应用程序每天消息推送的数量上限，且上述对应用程序的消息推送的时间段或数量上限的操作是批量设置的，由上述区别可知修改后的权利要求1要解决的问题是如何对移动终端中安装的应用程序的消息推送功能按照时间或消息数量进行批量启用或禁用。复审请求人认为上述区别不是本领域惯用手段。由于在不同应用中，下载、删除及更新等操作的实现逻辑大致相同，通过第三方应用程序对其他应用程序的下载、删除及更新等操作进行批量处理容易实现，而对于应用程序的通知消息而言，不同应用程序的通知消息的触发条件、消息来源及类型等属性可能不同，因此，在本申请公开日前，本领域技术人员对多个应用程序的通知消息进行批量处理是不容易实现的。复审请求人此次提交的权利要求书的内容如下：
“1. 一种推送消息的管理方法，其特征在于，包括：
获取移动终端操作系统的超级用户权限；
利用所述超级用户权限扫描所述移动终端的消息推送环境，展示扫描结果；
检测用户对其选定的所述扫描结果的操作指令；
根据检测到的所述操作指令，对所述移动终端进行推送消息管理；
其中，所述利用所述超级用户权限扫描所述移动终端的消息推送环境包括：
对所述移动终端中的应用程序安装情况进行扫描，通过读取所述移动终端中的应用程序的配置文件，判断所述移动终端中的应用程序是否向所述移动终端的操作系统注册了消息推送事件，查找出安装在所述移动终端中的、具备消息推送功能的应用程序；
所述扫描结果包括安装在移动终端中的具备消息推送功能的应用程序，所述操作指令包括启用或者禁用消息推送功能，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理包括：
当所述操作指令包括预设的系统时间段时，通过所述超级用户权限在所述预设的系统时间段内批量启用或者禁用用户选定的所述应用程序的消息推送功能；
当所述操作指令包括消息推送数量上限时，通过所述超级用户权限批量设置用户选定的所述应用程序每天的消息推送数量不超过所述消息推送数量上限。
2. 如权利要求1所述的方法，其特征在于，所述利用所述超级用户权限扫描所述移动终端的消息推送环境，还包括：
利用所述超级用户权限扫描当前已推送到所述移动终端系统通知栏的推送消息。
3. 如权利要求2所述的方法，其特征在于，所述操作指令还包括清除推送消息，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理， 还包括：
清除用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息。
4. 如权利要求2所述的方法，其特征在于，所述操作指令还包括消息来源显示，所述根据检测到的所述操作指令，对所述移动终端进行推送消息管理，还包括：
获取并显示用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息的消息来源。
5. 一种推送消息的管理装置，其特征在于，包括：
获取单元，用于获取移动终端操作系统的超级用户权限；
扫描单元，用于利用所述超级用户权限扫描所述移动终端的消息推送环境，展示扫描结果；
检测单元，用于检测用户对其选定的所述扫描结果的操作指令；
管理单元，用于根据检测到的所述操作指令，对所述移动终端进行推送消息管理；
所述扫描单元具体用于：
利用所述超级用户权限扫描安装在所述移动终端中的具备消息推送功能的应用程序；
其中，所述扫描单元具体还用于：
对所述移动终端中的应用程序安装情况进行扫描，通过读取所述移动终端中的应用程序的配置文件，判断所述移动终端中的应用程序是否向所述移动终端的操作系统注册了消息推送事件，查找出安装在所述移动终端中的、具备消息推送功能的应用程序；
所述扫描结果包括安装在移动终端中的具备消息推送功能的应用程序，所述操作指令包括启用或者禁用消息推送功能，所述管理单元具体用于：
当所述操作指令包括预设的系统时间段时，通过所述超级用户权限在所述预设的系统时间段内批量启用或者禁用用户选定的所述应用程序的消息推送功 能；
当所述操作指令包括消息推送数量上限时，通过所述超级用户权限批量设置用户选定的所述应用程序每天的消息推送数量不超过所述消息推送数量上限。
6. 如权利要求5所述的装置，其特征在于，所述扫描单元具体用于：
利用所述超级用户权限扫描当前已推送到所述移动终端系统通知栏的推送消息。
7. 如权利要求6所述的装置，其特征在于，所述操作指令包括清除推送消息，所述管理单元具体用于：
清除用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息。
8. 如权利要求6所述的装置，其特征在于，所述操作指令包括消息来源显示，所述管理单元具体用于：
获取并显示用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息的消息来源。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）审查文本的认定
复审请求人于2019年11月14日提交了权利要求书的全文修改替换页。经审查，上述修改文本的修改之处符合专利法第33条的规定。本复审请求审查决定依据的审查文本为：2019年11月14日提交的权利要求第1-8项；申请日2013年12月13日提交的说明书第1-8页，说明书附图第1页，说明书摘要，摘要附图。
（二）专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
本复审请求审查决定所引用的对比文件与驳回决定以及复审通知书所引用的对比文件相同，即
对比文件1：“拒绝恼人推送信息 教你肃清安卓通知栏”，http://tech.sina.com.cn/mobile/n/2013-04-26/08128284482.shtml，公开日：2013年04月26日。
1．权利要求1请求保护一种推送消息的管理方法，对比文件1（参见对比文件1中的方法二及附图）公开了一种用于管理手机推送信息的第三方安全软件LBE，并具体公开了以下内容：手机root后，使用第三方安全软件实现通知消息的屏蔽。以LBE安全大师为例，获取root权限后（即权利要求1中的获取移动终端操作系统的超级用户权限），启动主动防御，确认后进入“通知管理”功能；点选“通知栏”消息可以看到通知栏中的信息条目，同时还可以看到每条通知来自哪个应用；点选具体的条目，在出现的下拉菜单中点选禁止广告，就可以将该应用的推送信息从通知栏中屏蔽掉了；如果想针对某个应用直接屏蔽其通知栏信息的话，还可以在“通知栏管理”中点选“程序权限”，之后会出现手机中安装的全部程序的列表（相当于利用超级用户权限扫描所述移动终端的消息推送环境，展示扫描结果；对移动终端中的应用程序安装情况进行扫描），点击具体条目后就可以对是否屏蔽该应用的推送消息进行具体设置（相当于检测用户对其选定的所述扫描结果的操作指令；根据检测到的所述操作指令，对所述移动终端进行推送消息管理）；从附图上可以看出,“程序权限”中包含了高德地图、导航、百度地图等应用程序（相当于扫描结果包括安装在移动终端中的具备消息推送功能的应用程序），点选“下载列表（百度）”条目后出现“允许”、“拒绝”和“自定义”三个选项，可以对该程序的通知管理进行具体的设置（相当于操作指令包括启用或者禁用消息推送功能）。
权利要求1与对比文件1区别在于：1）权利要求1中通过读取所述移动终端中的应用程序的配置文件，判断所述移动终端中的应用程序是否向所述移动终端的操作系统注册了消息推送事件，查找出安装在所述移动终端中的、具备消息推送功能的应用程序，对比文件1中是在“通知栏管理”中点选“程序权限”之后出现手机中安装的全部程序的列表；2）当操作指令包括预设的系统时间段时，通过超级用户权限在所述预设的系统时间段内批量启用或者禁用用户选定的应用程序的消息推送功能；当操作指令包括消息推送数量上限时，通过超级用户权限批量设置用户选定的应用程序每天的消息推送数量不超过所述消息推送数量上限。由此可见，权利要求1实际要解决的问题是如何找出移动终端上具备消息推送功能的应用程序，以及如何简化且自定义地启用/禁用多个应用程序消息推送功能的操作。
对于区别1），对比文件1中LBE中的“通知管理”用于对移动终端上应用程序的消息推送功能进行管理，且“程序权限”是“通知管理栏”的下级目录，点选“程序权限”后出现的程序列表中的“高德地图”、“导航”、“百度地图”等应用程序均是具有消息推送功能的应用程序，由此可知，对比文件1给出了点选“程序权限”后仅列出具有推送功能的应用程序的技术启示，在此基础上，本领域技术人员有动机设置使“通知管理栏”下的“程序权限”仅列出移动终端中具备消息推送功能的全部应用程序；并且，对比文件1中获取root权限后才可以使用“通知管理”功能，而在本领域，在获得root权限之后可以通过读取终端上应用程序的配置文件来判断应用程序是否向终端的操作系统注册了消息推送事件，从而查找出安装在所述移动终端中具备消息推送功能的应用程序，这是本领域惯用手段。
对于区别2），对比文件1中方法二的第三个附图公开了对用户选定的“下载列表（百度）”程序的通知管理进行具体设置的操作除了“允许”和“拒绝”外，还包括“自定义”选项，由此，对比文件1给出了可以对应用程序的通知消息进行自定义设置管理的技术启示，而在设置消息接收操作方面，对接收消息的时段和接收消息的数量进行限定是本领域的惯用手段，因此，本领域技术人员有动机设置在特定的系统时间段内启用或者禁用用户选定的应用程序的消息推送功能，并对用户限定的应用程序的消息推送数量上限进行设置以避免恶意程序干扰用户；此外，对比文件1中的root程序可以对所有应用程序的通知消息进行管理，各应用程序的通知消息的触发条件、消息来源及类型是否相同并不影响root权限对所有应用程序的通知消息的管理功能，在此基础上，为了提高操作效率，使用root权限对多个应用程序的推送消息进行批量自定义设置是本领域技术人员有动机设置的，并且在技术上是可以实现的。
由此可知，在对比文件1的基础上结合本领域惯用手段得到权利要求1的技术方案对本领域的技术人员来说是显而易见的，权利要求1的方案不具有突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2、权利要求2引用权利要求1，权利要求3引用权利要求2。对比文件1（参见对比文件1中的方法二）公开了：以LBE安全大师为例，获取root权限后，启动主动防御，确认后进入“通知管理”功能；点选“通知栏”消息可以看到通知栏中的信息条目，同时还可以看到每条通知来自哪个应用（即利用所述超级用户权限扫描当前已推送到所述移动终端系统通知栏的推送消息）；点选具体的条目，在出现的下拉菜单中点选禁止广告，就可以将该应用的推送信息从通知栏中屏蔽掉了；从方法二的第二个附图上可以看出,点选“安装成功”后出现“禁止广告”和“清除通知”（相对于清除用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息）。由此，在其引用的权利要求不具备创造性的情况下，权利要求2和3也不具备专利法第22条第3款规定的创造性。
3、权利要求4引用权利要求2。对比文件1（参见对比文件1中的方法二）公开了：点选“通知栏”消息，可以看到当前出现在通知栏中的信息条目，同时还可以看到每条通知来自哪个应用（相当于获取并显示用户选定的所述当前已推送到所述移动终端系统通知栏的推送消息的消息来源）。由此，在其引用的权利要求不具备创造性的情况下，该权利要求也不具备专利法第22条第3款规定的创造性。
4、权利要求5-8要求保护一种推送消息的管理装置，其所包含的各模块执行的功能与权利要求1-4各方法步骤相对应（权利要求1-4分别对应权利要求5-8），在已知方法不具备创造性的前提下，设置对应的模块实现相应方法步骤属于本领域惯用手段，因而权利要求5-8也不具备专利法第22条第3款规定的创造性。
（三）针对复审请求人相关意见的答复
针对复审请求人于2019年11月14日提交的意见陈述书中的意见，合议组认为：
对比文件1中方法二的第三个附图公开了对用户选定的“下载列表（百度）”程序的通知管理进行具体设置的操作除了“允许”和“拒绝”外，还包括“自定义”选项，由此，对比文件1给出了可以对应用程序的通知消息进行自定义设置管理的技术启示，而在设置消息接收操作方面，对接收消息的时段和接收消息的数量进行限定是本领域的惯用手段，因此，本领域技术人员有动机设置在特定的系统时间段内启用或者禁用用户选定的应用程序的消息推送功能，并对用户限定的应用程序的消息推送数量上限进行设置以避免恶意程序干扰用户；此外，对比文件1中的root程序可以对所有应用程序的通知消息进行管理，由此可知，各应用程序的通知消息的触发条件、消息来源及类型是否相同并不影响root权限对所有应用程序的通知消息的管理功能，为提高操作效率，使用root权限对多个应用程序的推送消息进行批量自定义设置是本领域技术人员有动机设置的，并且在技术上是可以实现的。
综上所述，对于复审请求人的上述意见，合议组不予支持。
三、决定
维持国家知识产权局于2019年03月04日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
