一种异常处理方法及装置-复审决定


发明创造名称:一种异常处理方法及装置
外观设计名称:
决定号:198022
决定日:2019-12-04
委内编号:1F296454
优先权日:
申请(专利)号:201610053762.7
申请日:2016-01-26
复审请求人:新华三技术有限公司
无效请求人:
授权公告日:
审定公告日:
专利权人:
主审员:吕小倩
合议组组长:杨红丽
参审员:李晓茜
国际分类号:H04L12/24
外观设计分类号:
法律依据:专利法第22条第3款
决定要点
:如果一项权利要求记载的技术方案与一篇对比文件存在区别特征,对于本领域的普通技术人员来说,对比文件并没有给出应用该区别特征以解决相关技术问题的技术启示,也没有证据表明上述区别特征是本领域的公知常识,而该区别特征的采用能够使权利要求的技术方案产生有益的技术效果,则该权利要求所限定的技术方案具备创造性。
全文:
本复审请求涉及申请号为201610053762.7,名称为“一种异常处理方法及装置”的发明专利申请(下称本申请)。申请人由杭州华三通信技术有限公司变更为新华三技术有限公司。本申请的申请日为2016年01月26日,公开日为2016年07月13日。
经实质审查,国家知识产权局实质审查部门于2019年05月07日发出驳回决定,驳回了本申请。驳回决定引用一篇对比文件,为:对比文件1,CN102694850A,公开日为2012年09月26日。驳回决定所依据的文本为:申请人于申请日2016年01月26日提交的权利要求书第1-14项、说明书第1-91段(即第1-9页)、说明书附图第1-3页、说明书摘要及摘要附图。
驳回决定所针对的权利要求书的内容如下:
“1.一种异常处理方法,应用于服务器上,其特征在于,该方法包括:
接收客户端设备发送的业务请求消息;
判断所述服务器的运行状态是否满足处理所述业务请求消息的条件;
当所述运行状态不满足处理所述业务请求消息的条件时,设置用户操作策略为禁止用户操作;向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为禁止用户操作时,禁止用户操作所述客户端设备。
2.如权利要求1所述的方法,其特征在于:
当所述用户操作策略为禁止用户操作时,所述用户操作消息中还携带当前业务处理进度,以使所述客户端设备向用户提示所述服务器的业务处理进度。
3.如权利要求1或2所述的方法,其特征在于,所述方法还包括:
当所述运行状态满足处理所述业务请求消息的条件时,设置所述用户操作策略为允许用户操作,向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为允许用户操作时,允许用户操作所述客户端设备。
处理所述客户端设备发送的业务请求消息;
当在处理过程中发现错误时,根据所述错误的错误类型确定是否向所述客户端设备推送错误消息。
4.如权利要求3所述的方法,其特征在于,所述根据所述错误的错误类型确定是否向所述客户端设备推送错误消息,包括:
当所述错误的错误类型属于用户关心的错误时,向所述客户端设备推送错误消息;当所述错误的错误类型不属于用户关心的错误时,禁止向所述客户端设备推送错误消息。
5.一种异常处理方法,应用于客户端设备上,其特征在于,该方法包括:
向服务器发送业务请求消息;
接收所述服务器推送的用户操作消息,所述用户操作消息中携带所述服务器根据自身运行状态设置的用户操作策略;
当所述用户操作策略为禁止用户操作时,禁止用户操作。
6.如权利要求5所述的方法,其特征在于,所述方法还包括:
在发送所述业务请求消息之后到接收所述用户操作消息之前,禁止用户操作。
7.如权利要求5或6所述的方法,其特征在于:
所述用户操作消息中还携带所述服务器当前的业务处理进度;
当所述用户操作策略为禁止用户操作时,向用户提示所述服务器的业务处理进度。
8.一种异常处理装置,应用于服务器上,其特征在于,该装置包括:
接收单元,用于接收客户端设备发送的业务请求消息;
判断单元,判断所述服务器的运行状态是否满足处理所述业务请求消息的条件;
策略单元,用于当所述运行状态不满足处理所述业务请求消息的条件时,设置用户操作策略为禁止用户操作;
推送单元,用于向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为禁止用户操作时,禁止用户操作所述客户端设备。
9.如权利要求8所述的装置,其特征在于:
所述推送单元,还用于当所述用户操作策略为禁止用户操作时,在所述用户操作消息中还携带当前业务处理进度,以使所述客户端设备向用户提示所述服务器的业务处理进度。
10.如权利要求8或9所述的装置,其特征在于:
所述策略单元,还用于当所述运行状态满足处理所述业务请求消息的条件时,设置所述用户操作策略为允许用户操作;
所述推送单元,还用于向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为允许用户操作时,允许用户操作所述客户端设备。
处理单元,用于处理所述客户端设备发送的业务请求消息;
错误单元,用于当在处理过程中发现错误时,根据所述错误的错误类型确定是否向所述客户端设备推送错误消息。
11.如权利要求10所述的装置,其特征在于:
所述错误单元,具体用于当所述错误的错误类型属于用户关心的错误时,向所述客户端设备推送错误消息;当所述错误的错误类型不属于用户关心的错误时,禁止向所述客户端设备推送错误消息。
12.一种异常处理装置,应用于客户端设备上,其特征在于,该装置包括:
发送单元,用于向服务器发送业务请求消息;
接收单元,用于接收所述服务器推送的用户操作消息,所述用户操作消息中携带所述服务器根据自身运行状态设置的用户操作策略;
禁止单元,用于当所述用户操作策略为禁止用户操作时,禁止用户操作。
13.如权利要求12所述的装置,其特征在于:
所述禁止单元,还用于在发送所述业务请求消息之后到接收所述用户操作消息之前,禁止用户操作。
14.如权利要求12或13所述的装置,其特征在于,所述用户操作消息中还携带所述服务器当前的业务处理进度,所述装置还包括:
提示单元,用于当所述用户操作策略为禁止用户操作时,向用户提示所述服务器的业务处理进度。”
驳回决定的主要理由是:(1)权利要求1与对比文件1的区别特征是:本申请中是直接设置为禁止用户操作,并向客户端推送用户操作消息,用户操作消息中携带用户操作策略,以使客户端设备在确定用户操作策略为禁止用户操作时禁止用户操作客户端设备,且由服务器自己进行状态的判断,而对比文件1中是在超过预定阈值时,方禁止用户操作,且对用户以后的请求拦截。权利要求5与对比文件1的区别特征是:本申请中是直接设置为禁止用户操作,并向客户端推送用户操作消息,用户操作消息中携带用户操作策略,以使客户端设备在确定用户操作策略为禁止用户操作时禁止用户操作客户端设备,且是由服务器进行相应操作策略的推送,而对比文件1中是在超过预定阈值时,方禁止用户操作,且对用户以后的请求拦截。上述区别特征是本领域的惯用手段。因此,权利要求1和5相对于对比文件1不具有突出的实质性特点和显著的进步,不具备专利法第22条第3款所规定的创造性。从属权利要求2-4及6-7的附加技术特征属于本领域的惯用手段,因此权利要求2-4也不具备专利法第22条第3款所规定的创造性。(2)权利要求8-11和12-14分别是与权利要求1-4和5-7对应的装置,基于类似的理由,权利要求8-11和12-14也不具备专利法第22条第3款规定的创造性。
申请人(下称复审请求人)对上述驳回决定不服,于2019年08月13日向国家知识产权局提出了复审请求,未对申请文件进行修改。复审请求人认为:①对比文件1的技术方案涉及以下设备:客户端、本系统(下称中间系统)、远程系统三部分,所有客户端设备通过中间系统登录到各目标系统,中间系统检测目标系统运行状态,在确定目标系统异常时,对客户端系统发送的访问请求进行拦截,解决了目标系统故障时,客户端设备频繁发送访问请求,对中间系统造成的阻塞等影响,对比文件1的技术方案依赖于客户端设备和服务器之间的中间系统实现,对比文件1仅针对中间系统进行改进,服务器和客户端没有改进;而本申请不涉及中间系统,主要改进点在服务器端,客户端配合服务器端作适应性调整,服务器自行监测运行状态,并通知客户端屏蔽用户操作;②对比文件1未公开特征“设置禁止用户操作”,且对比文件1已经由中间系统对用户的访问请求进行拦截,已达到减轻目标系统处理压力的情况下,本领域技术人员没有理由再想到通过禁止用户操作来减轻目标系统的压力,且在中间系统已经拦截访问请求后禁止用户操作不会给目标系统带来进一步减轻处理压力的效果;因此,不存在“向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为禁止用户操作时,禁止用户操作所述客户端设备”的技术启示;③在中间系统已经判断目标系统是否可用的基础上,不需要再通过其他方式确定服务器是否可用,因此,未给出“服务器检测自身运行状态(是否可用)”的技术启示;④本申请不依赖中间系统,应用场景更广泛,且具有节约网络资源,保证检测的及时性及准确性的优点;检测方式无法保证检测的及时性准确性,服务器不可用时仍不断发送请求,浪费网络资源。对比文件1不具备上述优点。
经形式审查合格,国家知识产权局于2019年08月23日依法受理了该复审请求,并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中认为:①虽然本申请和对比文件1的架构不同,但是当采用C/S架构时,因不存在中间设备,为了实现拦截用户请求以减轻服务器压力,很容易想到由服务器执行异常状态的判断,设置客户端禁止用户发送相应请求;②对比文件1中判断系统异常是通过用户访问请求次数超过阈值来判断,即系统异常则开始进行拦截,与本申请没有实质不同。
在上述程序的基础上,合议组认为本案事实已经清楚,可以做出复审请求审查决定。
二、决定的理由
(一)审查文本的认定
复审请求人在提交复审请求书时未提交申请文件的修改文本。本复审请求审查决定所依据的文本为:复审请求人于申请日2016年01月26日提交的权利要求书第1-14项、说明书第1-9页、说明书附图第1-3页、说明书摘要及摘要附图。
(二)关于创造性
专利法第22条第3款规定:“创造性,是指与现有技术相比,该发明具有突出的实质性特点和显著的进步,该实用新型具有实质性特点和进步。”
本复审请求审查决定所采用的对比文件与驳回决定所采用的对比文件相同,即:
对比文件1,CN102694850A,公开日为2012年09月26日。
权利要求1-14具备专利法第22条第3款规定的创造性,理由如下:
1)独立权利要求1要求保护一种异常处理方法。对比文件1公开了一种基于httpclient技术的系统集成方法(参见对比文件1的说明书第[0002]-[0008]段,附图1-2):C.在用户请求访问目标系统的业务功能时监控整个请求流程及服务响应情况并提供这个监控过程中各种状态的反馈如请求地址非法、请求被拒绝、连接超时、用户登录失败、用户会话超时失效、访问页面不存在或转移、请求页面超时、用户未授权访问等,然后根据实际业务需求对具体的反馈信息分别进行相应处理,如简单提示、进行流程的切换、转发或中断等;D.当目标系统出现异常(如服务异常、宕机)时此方法提供了请求拦截机制;当用户访问请求(相当于接收客户端发送的业务请求消息)失败次数累计达到阀值时则不再向远程系统发送请求,以后接收到的请求都直接拦截避免大量异常请求阻塞影响本系统性能(相当于判断所述服务器的运行状态是否满足处理所述业务请求消息的条件,当所述运行状态不满足处理所述业务请求消息的条件时,则不向远程系统发送请求,对接收到的请求进行拦截);E.在请求拦截机制启动的同时探针机制也随之启动,探针在后台不断探测远程系统,一旦目标系统访问正常及时恢复请求。
由此可见,权利要求1要求保护的技术方案与对比文件1公开的技术内容相比,其区别特征是:方法应用于服务器上;当所述运行状态不满足处理所述业务请求消息的条件时,设置用户操作策略为禁止用户操作;向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为禁止用户操作时,禁止用户操作所述客户端设备。
基于上述区别特征,权利要求1的技术方案实际要解决的技术问题是:如何在服务器故障时及时准确地减轻服务器负担。
对于上述区别,本申请为了实现在服务器不满足处理业务请求消息的条件时,及时、准确地减轻服务器负担,采取的技术方案是服务器自身进行检测,当判断出运行状态不满足处理业务请求消息的条件时,向客户端发送禁止用户操作的消息,从而设置客户端禁止用户操作;依赖的是服务器与客户端之间的交互过程,所有操作都是由服务器和客户端来执行,在服务器自身检测出现问题的第一时间,就通知客户端禁止用户操作,不再向服务器发送业务请求,从而减轻了服务器的负担。而对比文件1为了在服务器故障时减缓对中间系统的压力,采取的技术方案是由中间系统检测到当用户访问请求失败次数累计达到阀值时,由中间系统对用户的访问请求进行拦截;首先,所有的操作与服务器和客户端没有关系,没有改变服务器与客户端的任何操作,依赖的是对中间系统的改进,而在本申请采取C/S架构时,根本就没有中间系统,也根本无法实施对比文件1中依赖于中间系统完成的技术方案;其次,关于执行时机,对比文件1的执行时机是中间系统检测到当用户访问请求失败次数累计达到阀值,这个时间点必然是在服务器故障后一段时间后才能够使得失败次数累计达到阈值,而本申请的执行时机是服务器自身检测出现问题的时间,也就是服务器故障后的第一时间,可见本申请和对比文件1的执行时机并不相同,本申请在服务器自身检测出现问题的第一时间,就通知客户端禁止用户操作,不再向服务器发送业务请求,更加及时地从而减轻了服务器的负担,而对比文件1的反应要延迟一段时间;最后,对比文件1在已经检测出服务器故障,且中间系统已经对用户的访问请求进行拦截的操作后,对比文件1的技术方案就已经达到了减轻服务器处理压力的效果,在中间系统已经判断出服务器故障情况下根本不会需要服务器再次进行自身检测判断服务器是否故障,而在已经采取拦截用户访问请求的情况下也不会再需要服务器通知客户端禁止用户操作,因为在中间系统已经拦截访问请求后禁止用户操作不会给服务器带来进一步减轻处理压力的效果,也就是对比文件1的技术方案根本就不需要服务器和客户端之间的上述交互过程,可见对比文件1没有给出“应用于服务器,当所述运行状态不满足处理所述业务请求消息的条件时,设置用户操作策略为禁止用户操作;向所述客户端设备推送用户操作消息,所述用户操作消息中携带所述用户操作策略,以使所述客户端设备在确定所述用户操作策略为禁止用户操作时,禁止用户操作所述客户端设备”的技术启示。由此可见,对比文件1并未给出获得上述区别特征的启示,并且也没有证据表明上述区别特征属于本领域的公知常识。
本申请权利要求1的技术方案通过服务器检测自身运行状态不满足处理业务请求消息的条件时,向客户端推送消息禁止用户操作所述客户端,达到了在服务器不满足处理业务请求消息的条件时,及时、准确地减轻服务器负担的有益效果。
因此,权利要求1的技术方案相对于对比文件1和本领域公知常识的结合具有突出的实质性特点和显著的进步,具备专利法第22条第3款所规定的创造性。
2)独立权利要求5要求保护一种异常处理方法。对比文件1公开了一种基于httpclient技术的系统集成方法(参见对比文件1的说明书第[0002]-[0008]段,附图1-2):C.在用户请求访问目标系统的业务功能时监控整个请求流程及服务响应情况并提供这个监控过程中各种状态的反馈如请求地址非法、请求被拒绝、连接超时、用户登录失败、用户会话超时失效、访问页面不存在或转移、请求页面超时、用户未授权访问等,然后根据实际业务需求对具体的反馈信息分别进行相应处理,如简单提示、进行流程的切换、转发或中断等;D.当目标系统出现异常(如服务异常、宕机)时此方法提供了请求拦截机制;当用户访问请求(相当于向服务器发送业务请求消息)失败次数累计达到阀值时则不再向远程系统发送请求,以后接收到的请求都直接拦截避免大量异常请求阻塞影响本系统性能;E.在请求拦截机制启动的同时探针机制也随之启动,探针在后台不断探测远程系统,一旦目标系统访问正常及时恢复请求。
由此可见,权利要求5要求保护的技术方案与对比文件1公开的技术内容相比,其区别特征是:应用于客户端设备上;接收所述服务器推送的用户操作消息,所述用户操作消息中携带所述服务器根据自身运行状态设置的用户操作策略;当所述用户操作策略为禁止用户操作时,禁止用户操作。
基于上述区别特征,权利要求5的技术方案实际要解决的技术问题是:如何在服务器故障时及时准确地减轻服务器负担。
对于上述区别,本申请为了实现在服务器不满足处理业务请求消息的条件时,及时、准确地减轻服务器负担,采取的技术方案是服务器自身进行检测,当判断出运行状态不满足处理业务请求消息的条件时,向客户端发送禁止用户操作的消息,从而设置客户端禁止用户操作;依赖的是服务器与客户端之间的交互过程,所有操作都是由服务器和客户端来执行,在服务器自身检测出现问题的第一时间,就通知客户端禁止用户操作,不再向服务器发送业务请求,从而减轻了服务器的负担。而对比文件1为了在服务器故障时减缓对中间系统的压力,采取的技术方案是由中间系统检测到当用户访问请求失败次数累计达到阀值时,由中间系统对用户的访问请求进行拦截;首先,所有的操作与服务器和客户端没有关系,没有改变服务器与客户端的任何操作,依赖的是对中间系统的改进,而在本申请采取C/S架构时,根本就没有中间系统,也根本无法实施对比文件1中依赖于中间系统完成的技术方案;其次,关于执行时机,对比文件1的执行时机是中间系统检测到当用户访问请求失败次数累计达到阀值,这个时间点必然是在服务器故障后一段时间后才能够使得失败次数累计达到阈值,而本申请的执行时机是服务器根据自身运行状态,也就是服务器故障后的第一时间,可见本申请和对比文件1的执行时机并不相同,本申请在服务器自身检测出现问题的第一时间,就通知客户端禁止用户操作,不再向服务器发送业务请求,更加及时地从而减轻了服务器的负担,而对比文件1的反应要延迟一段时间;最后,对比文件1在已经检测出服务器故障,且中间系统已经对用户的访问请求进行拦截的操作后,对比文件1的技术方案就已经达到了减轻服务器处理压力的效果,在中间系统已经判断出服务器故障情况下根本不会需要服务器再次进行自身检测判断服务器是否故障,而在已经采取拦截用户访问请求的情况下也不会再需要服务器通知客户端禁止用户操作,因为在中间系统已经拦截访问请求后禁止用户操作不会给服务器带来进一步减轻处理压力的效果,也就是对比文件1的技术方案根本就不需要服务器和客户端之间的上述交互过程,可见对比文件1没有给出“应用于客户端设备,接收所述服务器推送的用户操作消息,所述用户操作消息中携带所述服务器根据自身运行状态设置的用户操作策略;当所述用户操作策略为禁止用户操作时,禁止用户操作”的技术启示。由此可见,对比文件1并未给出获得上述区别特征的启示,并且也没有证据表明上述区别特征属于本领域的公知常识。
本申请权利要求5的技术方案通过服务器检测自身运行状态不满足处理业务请求消息的条件时,向客户端推送消息,客户端接收消息,从而禁止用户操作所述客户端,达到了在服务器不满足处理业务请求消息的条件时,及时、准确地减轻服务器负担的有益效果。
因此,权利要求5的技术方案相对于对比文件1和本领域公知常识的结合具有突出的实质性特点和显著的进步,具备专利法第22条第3款所规定的创造性。
3)权利要求8和12是与方法权利要求1和5相对应的产品权利要求。基于与评述权利要求1和5具有创造性的类似理由,权利要求8和12相对于对比文件1及本领域公知常识的结合也具备创造性,符合专利法第22条第3款的规定。
4)基于独立权利要求1、5、8和12相对于对比文件1及本领域公知常识的结合具备创造性,因此,从属权利要求2-4、6-7、9-11和13-14相对于对比文件1及本领域公知常识的结合也具备专利法第22条第3款所规定的创造性。
三、决定
撤销国家知识产权局于2019年05月07日对本申请做出的驳回决定。由国家知识产权局实质审查部门以下述文本为基础继续进行审批程序:
复审请求人于申请日2016年01月26日提交的权利要求第1-14项;
复审请求人于申请日2016年01月26日提交的说明书第1-9页;
复审请求人于申请日2016年01月26日提交的说明书附图第1-3页;
复审请求人于申请日2016年01月26日提交的说明书摘要;
复审请求人于申请日2016年01月26日提交的摘要附图。
如对本复审请求审查决定不服,根据专利法第41条第2款的规定,复审请求人自收到本决定之日起3个月内向北京知识产权法院起诉。


郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

留言与评论(共有 0 条评论)
   
验证码: