发明创造名称：阻止三方推送平台后台启动应用的方法及装置
外观设计名称：
决定号：182078
决定日：2019-06-19
委内编号：1F249516
优先权日：
申请（专利）号：201610333648.X
申请日：2016-05-18
复审请求人：广东欧珀移动通信有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：白若鸽
合议组组长：钱丹娜
参审员：王鹏
国际分类号：G06F21/51，G06F9/48，G06F21/31
外观设计分类号：
法律依据：专利法第22条第3款
决定要点
：如果一项权利要求请求保护的技术方案相对于作为最接近现有技术的对比文件存在区别技术特征，该区别技术特征一部分被其他对比文件公开，且在该对比文件中所起的作用与本申请相同，另一部分区别技术特征属于本领域的公知常识，该技术方案是本领域技术人员在最接近现有技术的基础上结合其他对比文件和本领域的公知常识可以得到的，则该权利要求请求保护的技术方案是显而易见的，不具备突出的实质性特点和显著的进步，不具备创造性。
全文：
本复审请求涉及申请号为201610333648.X，名称为“阻止三方推送平台后台启动应用的方法及装置”的发明专利申请（下称本申请）。申请人为广东欧珀移动通信有限公司。本申请的申请日为2016年05月18日，公开日为2016年10月12日。
经实质审查，国家知识产权局原审查部门于2018年01月24日发出驳回决定，驳回了本申请，其理由是：权利要求1-7不具备专利法第22条第3款规定的创造性。驳回决定中所引用的对比文件如下：
对比文件1：CN104462980A，公开日为2015年03月25日；
对比文件2：CN105512549A，公开日为2016年04月20日。
驳回决定的具体理由是：权利要求1请求保护一种阻止三方推送平台后台启动应用的方法，权利要求4请求保护一种阻止三方推送平台后台启动应用的装置，对比文件1公开了一种应用程序权限管理的方法及装置，权利要求1与对比文件1的区别特征是：（1）若所述包名属于预设的第三方推送平台黑名单，则判定所述调用者信息与第三方推送平台匹配；所述第三方推送平台黑名单是存储在云服务器中的文件；若所述调用者信息与第三方推送平台匹配，则拒绝响应所述应用启动请求；若所述目标应用启动请求为第三方推送平台或者实现了三方推送平台SDK的应用发起的，应拒绝响应对应的应用启动请求。（2）判断所述调用者信息对应的应用是否为前台应用，所述前台应用为终端当前显示界面上正在处理的应用，若是，则响应所述应用启动请求，若否，则执行判断所述调用者信息是否与第三方推送平台匹配的步骤。(3) 通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；通过在终端上设置的强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求。从而确定权利要求1实际要解决的问题是确定阻止或允许何种后台应用的启动以及拦截时警告用户并允许用户进行拦截与否的修改。权利要求4与对比文件1的区别特征是：（a）判断所述调用者信息与第三方推送平台匹配，若匹配则拒绝响应应用启动请求；（b）还包括前台应用确认模块，用于判断所述调用者信息对应的应用是否为前台应用，若是，则响应所述应用启动请求，若否，则调用所述判断模块。（c）消息通知模块，用于通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；强制启动模块，用于通过强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求。由此而确定权利要求4实际要解决的问题是确定阻止或允许何种后台应用的启动以及拦截时警告用户并允许用户进行拦截与否的修改。对于区别特征（1）、（a）在能获取调用者信息的情况下，根据具体的需求将阻止的规则改为特定应用启动禁止启动其他应用程序是惯用技术手段，同时第三方推送平台自动启动其他应用是常见的一种应用启动方式，这种方式造成了非用户意愿的资源占用也是公知的问题，因此，将规则进一步限定为阻止特定第三方推送平台启动应用程序属于本领域技术人员的惯用技术手段。对比文件2公开区别特征（2）、（b），该部分特征在对比文件2中的作用也是为了允许用户调用的应用程序的启动。对于区别特征（3）、（c），拦截规则的设置与弹窗警告的顺序以及设置一特定的控件用于接收某个指令都属于本领域技术人员的惯用技术手段。因此，在对比文件1的基础上结合对比文件2和上述惯用技术手段而得到权利要求1或者4请求保护的技术方案，对本领域技术人员来讲是显而易见的。因此，权利要求1或4不具备专利法第22条第3款规定的创造性。权利要求2、5的附加技术特征属于本领域技术人员的惯用技术手段，权利要求3、6、7的附加技术特征已被对比文件1公开，因此权利要求2-3、5-7不具备专利法第22条第3款规定的创造性。
驳回决定所依据的文本为申请日2016年05月18日提交的说明书摘要、说明书第1-98段、摘要附图、说明书附图图1-3，2017年12月25日提交的权利要求第1-7项。
驳回决定所针对的权利要求书如下：
“1. 一种阻止三方推送平台后台启动应用的方法，其特征在于，包括：
通过操作系统的启动管理服务检测目标应用启动请求，获取所述目标应用启动请求携带的应用信息，获知所需要启动的应用的相关信息；
根据所述应用信息向启动管理服务确定启动所述目标应用的调用者信息；
判断所述调用者信息对应的应用是否为前台应用，所述前台应用为终端当前显示界面上正在处理的应用，若是，则响应所述应用启动请求，若否，则执行判断所述调用者信息是否与第三方推送平台匹配的步骤；
获取所述调用者信息中包含的应用的包名，若所述包名属于预设的第三方推送平台黑名单，则判定所述调用者信息与第三方推送平台匹配；
所述第三方推送平台黑名单是存储在云服务器中的文件；
若所述调用者信息与第三方推送平台匹配，则拒绝响应所述应用启动请求；
若所述目标应用启动请求为第三方推送平台或者实现了三方推送平台SDK的应用发起的，应拒绝响应对应的应用启动请求；
通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；
通过在终端上设置的强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求。
2. 根据权利要求1所述的阻止三方推送平台后台启动应用的方法，其特征在于，所述拒绝响应所述应用启动请求的步骤之后还包括：
获取所述调用者信息对应的应用创建的与所述应用启动请求对应的中间对象，回收所述中间对象。
3. 根据权利要求1所述的阻止三方推送平台后台启动应用的方法，其特征在于，所述判断所述调用者信息是否与第三方推送平台匹配的步骤还包括：
将所述调用者信息上传至安全服务器，由所述安全服务器判断所述调用者信息是否与第三方推送平台匹配，并接收所述安全服务器返回的判断结果。
4. 一种阻止三方推送平台后台启动应用的装置，其特征在于，包括：
应用启动请求检测模块，用于通过操作系统的启动管理服务检测应用启动请求，获取所述应用启动请求携带的应用信息，获知所需要启动的应用的相关信息；
调用者信息确定模块，用于根据所述应用信息确定调用者信息；
判断模块，用于判断所述调用者信息是否与第三方推送平台匹配；
拒绝响应模块，用于在所述调用者信息与所述第三方推送平台匹配时，拒绝响应所述应用启动请求；
前台应用确认模块，用于判断所述调用者信息对应的应用是否为前台应用，若是，则响应所述应用启动请求，若否，则调用所述判断模块；
消息通知模块，用于通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；
强制启动模块，用于通过强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求。
5. 根据权利要求4所述的阻止三方推送平台后台启动应用的装置，其特征在于，所述装置还包括中间对象回收模块，用于获取所述调用者信息对应的应用创建的与所述应用启动请求对应的中间对象，回收所述中间对象。
6. 根据权利要求4所述的阻止三方推送平台后台启动应用的装置，其特征在于，所述判断模块还用于获取所述调用者信息中包含的应用的包名，若所述包名属于预设的第三方推送平台黑名单，则判定所述调用者信息与第三方推送平台匹配。
7. 根据权利要求4所述的阻止三方推送平台后台启动应用的装置，其特征在于，所述判断模块还用于将所述调用者信息上传至安全服务器，由所述安全服务器判断所述调用者信息是否与第三方推送平台匹配，并接收所述安全服务器返回的判断结果。”
申请人（下称复审请求人）对上述驳回决定不服，于2018年03月20日向国家知识产权局提出了复审请求，同时修改了权利要求书（2页，7项权利要求）。复审请求人在驳回决定所针对的权利要求书的基础上进行修改，独立权利要求1、4增加相同的特征“和/或根据应用与应用支架的调用所启动的另一个应用”、“所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单”。
复审请求人认为：1、本申请和对比文件1获取调用者信息的方式不同，本申请是先获得应用信息，再由此通过启动管理服务获得调用者信息，而对比文件1中的自启动请求中携带了第一、第二应用程序的包标识，可以直接获得。2、本申请和对比文件1阻止的规则不同，其重点在于禁止第三方平台的应用调用，本申请只需要判断一个要素，即“调用者信息”。3、对比文件2仅公开了桌面上用户发起目标应用程序的调用，无法得到该目标应用程序是正在桌面上处理或使用的启示。
复审请求时新修改的权利要求1、4如下：
“1. 一种阻止三方推送平台后台启动应用的方法，其特征在于，包括：
通过操作系统的启动管理服务检测目标应用启动请求，获取所述目标应用启动请求携带的应用信息，获知所需要启动的应用的相关信息；
根据所述应用信息向启动管理服务确定启动所述目标应用的调用者信息；
判断所述调用者信息对应的应用是否为前台应用，所述前台应用为终端当前显示界面上正在处理的应用和/或根据应用与应用支架的调用所启动的另一个应用，若是，则响应所述应用启动请求，若否，则执行判断所述调用者信息是否与第三方推送平台匹配的步骤；
获取所述调用者信息中包含的应用的包名，若所述包名属于预设的第三方推送平台黑名单，则判定所述调用者信息与第三方推送平台匹配；
所述第三方推送平台黑名单是存储在云服务器中的文件；
若所述调用者信息与第三方推送平台匹配，则拒绝响应所述应用启动请求；若所述目标应用启动请求为第三方推送平台或者实现了三方推送平台SDK的应用发起的，应拒绝响应对应的应用启动请求；
通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；
通过在终端上设置的强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求；
所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单。”
“4. 一种阻止三方推送平台后台启动应用的装置，其特征在于，包括：应用启 动请求检测模块，用于通过操作系统的启动管理服务检测应用启动请求，获取所述应用启动请求携带的应用信息，获知所需要启动的应用的相关信息；
调用者信息确定模块，用于根据所述应用信息确定调用者信息；
判断模块，用于判断所述调用者信息是否与第三方推送平台匹配；
拒绝响应模块，用于在所述调用者信息与所述第三方推送平台匹配时，拒绝响应所述应用启动请求；
前台应用确认模块，用于判断所述调用者信息对应的应用是否为前台应用，若是，则响应所述应用启动请求和/或根据应用与应用支架的调用所启动的另一个应用，若否，则调用所述判断模块；
消息通知模块，用于通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；
强制启动模块，用于通过强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求；
所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单。”
经形式审查合格，国家知识产权局于2018年04月27日依法受理了该复审请求，并将其转送至原审查部门进行前置审查。
原审查部门在前置审查意见书中认为：1、对比文件1已经公开了需要获取调用者信息，具体的获取形式可以根据当前应用提供的信息来适应性的调整，同时对比文件1第[0121]段也明确公开了由启动管理服务（ActivityManagerService）来获取第一和第二应用程序的包标识；2、虽然本申请和对比文件1的阻止规则不同，但是发明构思是相同的，都是根据阻止列表来禁止某类应用程序的调用，本领域技术人员可以根据安全等级和应用程序的限制需求对规则进行调整；3、对比文件2公开了：判断目标应用程序的调用行为发起者是否为当前正在使用的桌面，如果是表示由用户发起，这种情况下不做处理，即给出了允许用户启动应用程序的启示。而“当前正在使用的桌面”对应于权利要求1中限定的“终端当前显示桌面上正在处理的应用”。因而坚持原驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年05月10日向复审请求人发出复审通知书，在复审通知书中引用对比文件1-2作为现有技术，并指出权利要求1-7不符合专利法第22条第3款有关创造性的规定。对于复审请求人提出的意见，合议组认为：1、参见对比文件1说明书[0084]、[0121]段，Android系统有四大组件：Activity组件、Service组件、BroadcastReceiver组件和ContentProvider组件，这四大组件均可以被ActivityManagerService所管理。在应用程序被自启动时会通过ActivityManagerService执行。具体地，在接收到Service第一应用程序对第二应用程序的自启动请求后，ActivityManagerService获悉该自启动请求来自Service，在执行对第二应用程序的调用之前，首先根据自启动请求中携带的第一应用程序的包标识和第二应用程序的包标识进行判断。可见对比文件1和本申请都是通过ActivityManagerService启动管理服务获得调用者信息。2、对比文件2公开了一种并具体公开了以下技术特征（参见说明书[0071]-[0079]段）：在实际应用中，根据预设拦截规则，拦截目标应用程序A的启动，可以采用上述三种方式。第三种，判断针对所述目标应用程序的调用行为的行为发起者是否为预设应用程序；如果否，拦截所述目标应用程序的启动。假设预设拦截规则为上述预先设置的规定，针对目标应用程序A的调用行为的行为发起者为应用程序D。判断针对目标应用程序A的调用行为的行为发起者应用程序D不为上述预先设置的规定中的预设应用程序，则拦截目标应用程序A的启动。假设预设拦截规则为上述预先设置的规定，针对目标应用程序A的调用行为的行为发起者为应用程序N。判断针对目标应用程序A的调用行为的行为发起者应用程序N为上述预先设置的规定中的预设应用程序，则不做处理。可见对比文件2公开了根据调用者的信息来判断是否终止被调用者的自启动。而且对比文件2中的预设应用程序可以认为是调用者白名单。可见对比文件2和本申请都是根据调用者列表来禁止某类应用程序的调用。第三方推送平台是不安全的调用者，这种方式造成了非用户意愿的资源占用是本领域的公知常识。3、对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0068]-[0070]段）：假设A处于未运行状态，判断针对目标应用程序的A调用行为是否由用户发起，可以判断针对目标应用程序的调用行为的行为发起者是否为当前正在使用的桌面，如果是，表示针对所述目标应用程序的调用行为是由用户发起。在实际应用中，终端中可以安装多个桌面，可以包括系统自带桌面和用户自行安装的主题桌面。上述桌面为当前正在使用的桌面。如果针对目标应用程序A的调用行为的行为发起者为当前正在使用的桌面，则表示用户通过当前正在使用的桌面调用了目标应用程序A。这种情况下，不做处理。本申请权利要求书以及说明书中都没有记载“目标应用程序是正在桌面上处理或使用”的相关内容，本申请说明书第[0065]段记载的是“判断所述调用者信息对应的应用是否为前台应用”。本申请权利要求书和说明书相关内容与对比文件2是一致的。因此，复审请求人陈述的理由不成立。
复审请求人于2019年05月31日提交了意见陈述书，同时修改了权利要求书（2页，共7项权利要求）。复审请求人在提出复审请求时提交的权利要求书的基础上进行修改。独立权利要求1、4增加相同的特征“所述实现了三方推送平台SDK的应用是指在自己的APK应用中使用了三方推送平台SDK公共服务包的应用”。
复审请求人认为：1、本申请和对比文件1获取调用者信息的方式不同，本申请是先获得应用信息，再由此通过启动管理服务获得调用者信息，而对比文件1中的自启动请求中携带了第一、第二应用程序的包标识，可以直接获得。2、对比文件1的黑名单是被拦截的第二应用程序（即被调用者）。而本申请中的黑名单是第三方推送平台或实现了三方推送平台SDK的应用（即调用者）的黑名单。对比文件1说明书第91段记载了，将授权权限列表存储在应用程序中，而不是存储在云服务器中。复审请求人不认为云服务器中必然存储了禁止启动的第一应用程序和第二应用程序的黑名单。而且，对比文件1的黑名单存储的是第二应用程序（即目标程序），而本申请黑名单存储的是第三方推送平台或者实现了三方推送平台SDK的应用（即调用者）。
复审请求人于2019年05月31日提交的权利要求1、4如下：
“1. 一种阻止三方推送平台后台启动应用的方法，其特征在于，包括：
通过操作系统的启动管理服务检测目标应用启动请求，获取所述目标应用启动请求携带的应用信息，获知所需要启动的应用的相关信息；
根据所述应用信息向启动管理服务确定启动所述目标应用的调用者信息；
判断所述调用者信息对应的应用是否为前台应用，所述前台应用为终端当前显示界面上正在处理的应用和/或根据应用与应用支架的调用所启动的另一个应用，若是，则响应所述应用启动请求，若否，则执行判断所述调用者信息是否与第三方推送平台匹配的步骤；
获取所述调用者信息中包含的应用的包名，若所述包名属于预设的第三方推送平台黑名单，则判定所述调用者信息与第三方推送平台匹配；
所述第三方推送平台黑名单是存储在云服务器中的文件；
若所述调用者信息与第三方推送平台匹配，则拒绝响应所述应用启动请求；若所述目标应用启动请求为第三方推送平台或者实现了三方推送平台SDK的应用发起的，应拒绝响应对应的应用启动请求；所述实现了三方推送平台SDK的应用是指在自己的APK应用中使用了三方推送平台SDK公共服务包的应用；
通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；
通过在终端上设置的强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求；
所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单。”
“4. 一种阻止三方推送平台后台启动应用的装置，其特征在于，包括：应用启动请求检测模块，用于通过操作系统的启动管理服务检测应用启动请求，获取所述应用启动请求携带的应用信息，获知所需要启动的应用的相关信息；
调用者信息确定模块，用于根据所述应用信息确定调用者信息；
判断模块，用于判断所述调用者信息是否与第三方推送平台匹配；
拒绝响应模块，用于在所述调用者信息与所述第三方推送平台匹配时，拒绝响应所述应用启动请求；
前台应用确认模块，用于判断所述调用者信息对应的应用是否为前台应用，若是，则响应所述应用启动请求和/或根据应用与应用支架的调用所启动的另一个应用，若否，则调用所述判断模块；
消息通知模块，用于通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；
强制启动模块，用于通过强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求；
所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单；所述实现了三方推送平台SDK的应用是指在自己的APK应用中使用了三方推送平台SDK公共服务包的应用。”
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）、审查文本的认定
复审请求人在复审阶段对权利要求书进行的修改符合专利法第33条以及专利法实施细则第61条第1款的规定。本复审决定所针对的文本是申请日2016年05月18日提交的说明书摘要、说明书第1-98段、摘要附图、说明书附图图1-3，2019年05月31日提交的权利要求第1-7项。
（二）、具体理由的阐述
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
如果一项权利要求请求保护的技术方案相对于作为最接近现有技术的对比文件存在区别技术特征，该区别技术特征一部分被其他对比文件公开，且在该对比文件中所起的作用与本申请相同，另一部分区别技术特征属于本领域的公知常识，该技术方案是本领域技术人员在最接近现有技术的基础上结合其他对比文件和本领域的公知常识可以得到的，则该权利要求请求保护的技术方案是显而易见的，不具备突出的实质性特点和显著的进步，不具备创造性。
在本复审决定中引用驳回决定和复审通知书中所引用的对比文件1-2作为现有技术，即：
对比文件1：CN104462980A，公开日为2015年03月25日；
对比文件2：CN105512549A，公开日为2016年04月20日。
权利要求1-7不符合专利法第22条第3款的规定。
1、权利要求1请求保护一种阻止三方推送平台后台启动应用的方法，对比文件1公开了一种应用程序权限管理的方法及装置（参见说明书第[0005]-[0203]段，图1-5）：（参见说明书[0084]-[0085]段）Android系统有四大组件：Activity组件、Service组件、Broadcast Receiver组件和Content Provider组件，这四大组件均可以被ActivityManagerService所管理。在应用程序被自启动时会通过ActivityManagerService执行。本发明的方法所应用程序的环境包括可与远程服务器或云端通信的移动终端，该移动终端可以安装有Android操作系统，该系统处于未经ROOT授权或者已经获取ROOT权限的状态。（参见说明书[0087]-[0094]段）图1是根据本发明一个实施例的应用程序权限管理的方法的流程示意图。如图1所示，该实施例可以包括以下步骤：102，接收第一应用程序通过服务方式对第二应用程序的自启动请求；104，获取应用程序授权权限列表；106，根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。（参见说明书[0113]段）需要指出的是，在应用程序授权权限列表中可以针对Service组件设置将被拦截的第二应用程序的黑名单，即，如果该第二应用程序通过Service方式自启动，只要第一应用程序的包标识和第二应用程序的包标识存在于应用程序授权权限列表中，均被拦截。（参见说明书[0121]-[0122]段）具体地，在接收到Service第一应用程序对第二应用程序的自启动请求后，ActivityManagerService获悉该自启动请求来自Service，在执行对第二应用程序的调用之前，首先根据自启动请求中携带的第一应用程序的包标识和第二应用程序的包标识进行判断。例如，可以将接收到的第一应用程序的包标识和第二应用程序的包标识与预先存储的应用程序授权权限列表中的包标识进行比较，如果应用程序授权权限列表中存在与第一应用程序的包标识和第二应用程序的包标识相同的包标识，则ActivityManagerService拦截通过Broadcast方式对应用程序的调用。在该实施例中，由于可以根据调用的应用程序的包标识即第一应用程序的包标识和被调用的应用程序的包标识即第二应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。（参见说明书[0134]段）进一步地，在ActivityManagerService记录相关信息的同时，可以通过向用户弹出界面的方式将所记录的所述自启动请求、所述内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识反馈给用户；并向用户界面弹窗告警。在用户接收到这些信息后，根据自身需求输入拦截策略，例如，对某些第一应用程序调起某些第二应用程序的自启动进行拦截、允许某些第一应用程序调起某些第二应用程序的自启动等。然后，则可以接收用户指令以获得处理策略，例如，对相应的自启动进行拦截或执行对第二应用程序的自启动。这样就可以把第一应用程序与第二应用程序这两个应用程序之间的调用关系给切断。其中，应用程序的常见自启动方式包括BindService方式或ContentProvider方式。（参见说明书[0012]-[0013]段）所述将获得的拦截策略存储在所述应用程序授权权限列表中之前，还包括：通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。（参见说明书[0019]-[0022]段）根据本发明的方法的一个实施例，进一步地，所述方法还包括：在接收到所述第一应用程序通过内容提供者方式对所述第二应用程序的自启动请求后，记录所述自启动请求、内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识；将所记录的所述自启动请求、所述内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识反馈给用户；向用户界面弹窗告警，接收用户指令以获得处理策略。（参见说明书[0055]段）交互单元，被注册为系统服务，外壳应用程序通过其内建的交互接口与该交互单元通信，借助该交互单元向用户界面弹窗实现人机交互。（参见说明书[0108]-[0112]段）所述拦截策略在设置的时候，针对每个组件可以遵循以下规则中的至少一项规则：Activity组件是可视化组件，其引发的启动行为不能被拦截，因为这种行为大多由用户触发，并非严格意义上的应用程序的自启动；BroadcastReceiver组件的唤醒是操作系统的行为，因此，对该组件所引发的自启动请求一般不进行拦截；以及ContentProvider组件所引发的自启动请求，可以将将权限交给用户，因此，每个用户可以根据自身需求设置个性化的过滤或拦截策略。这样，通过对以上这些规则的应用，可以较准确的判定第一应用程序对第二应用程序的自启动请求，是否应该被拦截，同时又不对用户的正常使用造成困扰。（参见说明书[0096]段）本领域技术人员了解，hook机制允许应用程序截获处理操作系统的消息或特定事件。在本发明实施例中，采用hook机制中断调取应用程序对应的组件的过程，实现在应用程序自启之前获取其组件信息（相当于屏蔽目标应用程序启动）。
因此，该权利要求的技术方案与对比文件1公开的内容相比，区别特征是：（1）若所述包名属于预设的第三方推送平台黑名单，则判定所述调用者信息与第三方推送平台匹配；所述第三方推送平台黑名单是存储在云服务器中的文件；若所述调用者信息与第三方推送平台匹配，则拒绝响应所述应用启动请求；若所述目标应用启动请求为第三方推送平台或者实现了三方推送平台SDK的应用发起的，应拒绝响应对应的应用启动请求。所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单；（2）判断所述调用者信息对应的应用是否为前台应用，所述前台应用为终端当前显示界面上正在处理的应用和/或根据应用与应用支架的调用所启动的另一个应用，若是，则响应所述应用启动请求，若否，则执行判断所述调用者信息是否与第三方推送平台匹配的步骤。(3)通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；通过在终端上设置的强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求。（4）所述实现了三方推送平台SDK的应用是指在自己的APK应用中使用了三方推送平台SDK公共服务包的应用。基于该区别特征，该权利要求实际解决的技术问题是确定阻止或允许何种后台应用的启动以及拦截时警告用户并允许用户对被拦截的调用强制启动。
对于区别特征（1），对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0071]-[0079]段）：在实际应用中，根据预设拦截规则，拦截目标应用程序A的启动，可以采用上述三种方式。第三种，判断针对所述目标应用程序的调用行为的行为发起者是否为预设应用程序（相当于白名单）；如果否，拦截所述目标应用程序的启动。可见对比文件2公开了部分区别特征（1），其作用与本申请相同也是根据调用者的信息来判断是否终止被调用者的自启动，节约系统资源。第三方推送平台是不安全的调用者，这种方式造成了非用户意愿的资源占用是本领域的公知常识。本领域技术人员很容易想到将不安全的调用者设置为黑名单，将黑名单存储在云服务器中也是本领域的公知常识。
对于区别特征（2），对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0068]-[0070]段）：假设A处于未运行状态，判断针对目标应用程序的A调用行为是否由用户发起，可以判断针对目标应用程序的调用行为的行为发起者是否为当前正在使用的桌面，如果是，表示针对所述目标应用程序的调用行为是由用户发起。在实际应用中，终端中可以安装多个桌面，可以包括系统自带桌面和用户自行安装的主题桌面。上述桌面为当前正在使用的桌面。如果针对目标应用程序A的调用行为的行为发起者为当前正在使用的桌面，则表示用户通过当前正在使用的桌面调用了目标应用程序A。这种情况下，不做处理。如果针对目标应用程序A的调用行为的行为发起者不是当前正在使用的桌面，根据预设拦截规则，拦截目标应用程序A的启动（相当于若否，则根据预设拦截规则，拦截目标应用程序A的启动）。可见对比文件2公开了部分区别特征（2），其作用与本申请相同也是当调用者为当前正在使用的桌面则允许被调用者的自启动。应用与应用支架的调用所启动的另一个应用是安全合理的调用行为是本领域的公知常识，第三方推送平台是不安全的调用者，这种方式造成了非用户意愿的资源占用是本领域的公知常识。
对于区别特征（3），对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0073]-[0074]段）：第二种，向用户展示包括是否拦截目标应用程序A的启动的信息，在用户选择拦截目标应用程序A的启动的情况下，拦截目标应用程序A的启动。在实际应用中，可以以向用户展示“拦截”和“不拦截”的两个选择按键的方式，向用户展示包括是否拦截目标应用程序A的启动的信息。如果用户选择“拦截”的按键，则拦截目标应用程序A的启动。如果用户选择“不拦截”的按键，则不做处理。可见对比文件2公开了部分区别特征（3），其作用与本申请相同也是通过弹窗进行人机交互，根据用户意愿确定是否拦截被调用者。弹窗提示用户已将所述应用启动请求屏蔽、以及设置强制启动控件都是本领域的公知常识。
对于区别特征（4），实现了三方推送平台SDK的应用在自己的APK应用中使用了三方推送平台SDK公共服务包是本领域的公知常识。
因此，在对比文件1的基础上结合对比文件2以及本领域的公知常识得到该权利要求请求保护的技术方案对于本领域技术人员而言是显而易见的，该权利要求不具备突出的实质性特点和显著地进步，不具备专利法第22条第3款规定的创造性。
2、权利要求4请求保护一种阻止三方推送平台后台启动应用的装置，对比文件1公开了一种应用程序权限管理的方法及装置（参见说明书第[0005]-[0203]段，图1-5）：这部分内容与权利要求1的评述相同，请参阅权利要求1的评述。权利要求4与对比文件1相比的区别特征是：（1）用于在所述调用者信息与第三方推送平台匹配时，拒绝响应所述应用启动请求；所述调用者为第三方推送平台或实现了三方推送平台SDK的应用，所述黑名单为调用者黑名单；（2）前台应用确认模块，用于判断所述调用者信息对应的应用是否为前台应用，若是，则响应所述应用启动请求和/或根据应用与应用支架的调用所启动的另一个应用，若否，则调用所述判断模块；（3）强制启动模块，用于通过展示弹出窗或在通知栏提示用户已将所述应用启动请求屏蔽；强制启动模块，用于通过强制启动控件接收输入的强制启动指令，重新响应所述已拒绝的应用启动请求。（4）所述实现了三方推送平台SDK的应用是指在自己的APK应用中使用了三方推送平台SDK公共服务包的应用。基于该区别特征，该权利要求实际解决的技术问题是确定阻止或允许何种后台应用的启动以及拦截时警告用户并允许用户对被拦截的调用强制启动。
对于区别特征（1），对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0071]-[0079]段）：在实际应用中，根据预设拦截规则，拦截目标应用程序A的启动，可以采用上述三种方式。第三种，判断针对所述目标应用程序的调用行为的行为发起者是否为预设应用程序（相当于白名单）；如果否，拦截所述目标应用程序的启动。可见对比文件2公开了部分区别特征（1），其作用与本申请相同也是根据调用者的信息来判断是否终止被调用者的自启动，节约系统资源。第三方推送平台是不安全的调用者，这种方式造成了非用户意愿的资源占用是本领域的公知常识。本领域技术人员很容易想到将第三方推送平台设置为黑名单也是本领域的公知常识。
对于区别特征（2），对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0068]-[0070]段）：假设A处于未运行状态，判断针对目标应用程序的A调用行为是否由用户发起，可以判断针对目标应用程序的调用行为的行为发起者是否为当前正在使用的桌面，如果是，表示针对所述目标应用程序的调用行为是由用户发起。在实际应用中，终端中可以安装多个桌面，可以包括系统自带桌面和用户自行安装的主题桌面。上述桌面为当前正在使用的桌面。如果针对目标应用程序A的调用行为的行为发起者为当前正在使用的桌面，则表示用户通过当前正在使用的桌面调用了目标应用程序A。这种情况下，不做处理。如果针对目标应用程序A的调用行为的行为发起者不是当前正在使用的桌面，根据预设拦截规则，拦截目标应用程序A的启动（相当于若否，则根据预设拦截规则，拦截目标应用程序A的启动）。可见对比文件2公开了部分区别特征（2），其作用与本申请相同也是当调用者为当前正在使用的桌面则允许被调用者的自启动。应用与应用支架的调用所启动的另一个应用是安全合理的调用行为是本领域的公知常识。
对于区别特征（3），对比文件2公开了一种应用程序拦截方法及装置，并具体公开了以下技术特征（参见说明书[0073]-[0074]段）：第二种，向用户展示包括是否拦截目标应用程序A的启动的信息，在用户选择拦截目标应用程序A的启动的情况下，拦截目标应用程序A的启动。在实际应用中，可以以向用户展示“拦截”和“不拦截”的两个选择按键的方式，向用户展示包括是否拦截目标应用程序A的启动的信息。如果用户选择“拦截”的按键，则拦截目标应用程序A的启动。如果用户选择“不拦截”的按键，则不做处理。可见对比文件2公开了部分区别特征（3），其作用与本申请相同也是通过弹窗进行人机交互，根据用户意愿确定是否拦截被调用者。弹窗提示用户已将所述应用启动请求屏蔽、以及设置强制启动控件都是本领域的公知常识。
对于区别特征（4），实现了三方推送平台SDK的应用在自己的APK应用中使用了三方推送平台SDK公共服务包是本领域的公知常识。
因此，在对比文件1的基础上结合对比文件2以及本领域的公知常识得到该权利要求请求保护的技术方案对于本领域技术人员而言是显而易见的，该权利要求不具备突出的实质性特点和显著地进步，不具备专利法第22条第3款规定的创造性。
3、对于从属权利要求2、5，其附加技术特征属于本领域技术人员的公知常识，为了减少应用程序对资源的占用，及时回收未在执行或是不应执行的程序的资源是本领域技术人员容易想到的。因此，在其引用的权利要求不具备创造性的情况下，该权利要求也不具备创造性。
4、对于从属权利要求3、7，对比文件1还公开了部分附加技术特征（参见说明书[0107]、[0139]-[0141]段）进一步地，在将获得的拦截策略存储在所述应用程序授权权限列表中之前，还可以进一步通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。这样，则可以将从本地策略数据库中所获得的拦截策略和从云端服务器所获得的拦截策略，一并存储在所述应用程序授权权限列表中。在上述实施例中，拦截策略可以包括但不限于基于第一应用程序的包标识 和第二应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是 否拦截。进一步地，所述云端服务器为各应用程序设置的安全级别包括黑、灰和白 三个级别，分别对应禁止安装、由用户选择是否安装以及径行安装。对于准备或者正在进行安装的应用程序而言，本发明可以通过将自身注册 为默认安装器的形式，获取该应用程序的安装广播信息。继而，将这个新装应 用程序作为目标应用程序，将其安装包或签名之类的特征信息通过远程规则库 接口发送到云端服务器中，由云端服务器对其做出安全性判断。本领域技术人员熟悉服务器的这种云端控制技术，将在后续进一步概要揭示。无论如何，本发明将从本机远程规则库接口中获得云端服务器有关这些应用程序的处理规则的反馈，利用反馈结果做出相应的后续处理。本领域技术人员很容易想到使用安全服务器来判断调用者是否是第三方推送平台。因此，在其引用的权利要求不具备创造性的情况下，该权利要求也不具备创造性。
5、对于从属权利要求6，对比文件1还公开了部分附加技术特征（参见说明书 [0045]段）拦截处理单元，用于根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。第三方推送平台是不安全的调用者，这种方式造成了非用户意愿的资源占用是本领域的公知常识。本领域技术人员很容易想到预设第三方推送平台黑名单，并判断调用者是否与该名单匹配。因此，在其引用的权利要求不具备创造性的情况下，该权利要求也不具备创造性。
（三）、对复审请求人相关意见的评述
1、本申请说明书第52-55段记载了“终端中的某个应用程序去打开另外一个应用程序，都会触发对应的应用启动请求，从而启动管理服务(ActivityManagerService)会检测到该应用启动请求。应用启动请求至少包含了需要启动的目标应用信息。步骤S104：根据所述应用信息确定调用者信息。在实施例中，根据需要启动的目标应用的应用信息可以获取到对应的调用者信息”。复审通知书中“三、针对复审请求人的意见陈述”部分，合议组第1点已经指出“ActivityManagerService获悉该自启动请求来自Service，在执行对第二应用程序的调用之前，首先根据自启动请求中携带的第一应用程序的包标识和第二应用程序的包标识进行判断。”可见本申请和对比文件1中ActivityManagerService都能获取调用者信息。复审请求人所说的“本申请中在被调用应用程序启动之前并不知晓调用者的信息，在被调用应用程序自身发送启动请求时，进一步获取被调用者的调用信息”是不合理的。
2、首先，复审通知书对权利要求1的评述中，区别特征（2）明确记载了“所述第三方推送平台黑名单是存储在云服务器中的文件”，可见合议组认为该特征是权利要求1和对比文件1的区别特征。复审通知书中没有记载“云服务器中必然存储了禁止启动的第一应用程序和第二应用程序的黑名单”。其次，复审通知书中“三、针对复审请求人的意见陈述”部分，合议组第2点记载了对比文件2公开的内容，并指出“对比文件2公开了根据调用者的信息来判断是否终止被调用者的自启动。而且对比文件2中的预设应用程序可以认为是调用者白名单。可见对比文件2和本申请都是根据调用者列表来禁止某类应用程序的调用”。可见合议组在复审通知书中已经对于复审请求人进行了回应。
因此，复审请求人的意见不能被接受。
基于以上理由，合议组作出如下审查决定。
三、决定
维持国家知识产权局于2018年01月24日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
