发明创造名称：分布式服务的监控方法及装置
外观设计名称：
决定号：200537
决定日：2020-01-13
委内编号：1F284820
优先权日：
申请（专利）号：201510515834.0
申请日：2015-08-20
复审请求人：百度在线网络技术（北京）有限公司
无效请求人：
授权公告日：
审定公告日：
专利权人：
主审员：郭琼
合议组组长：左一
参审员：张巍
国际分类号：H04L12/24
外观设计分类号：
法律依据：专利法第22条第3款
决定要点：如果权利要求的技术方案与最接近的对比文件相比存在区别特征，而该区别特征的一部分属于本领域的惯用手段，另一部分已经被另一篇对比文件公开，结合两篇对比文件以及上述本领域的惯用技术手段得到权利要求的技术方案对本领域技术人员而言是显而易见的，则该权利要求的技术方案不具备创造性。
全文：
本复审请求涉及申请号为201510515834.0，名称为“分布式服务的监控方法及装置”的发明专利申请（下称本申请）。申请人为百度在线网络技术（北京）有限公司。本申请的申请日为2015年08月20日，公开日为2015年12月30日。
经实质审查，国家知识产权局实质审查部门于2019年03月04日发出驳回决定，驳回了本申请，驳回决定所依据的文本为：2018年05月03日提交的权利要求第1-10项；申请日2015年08月20日提交的说明书第1-59段、说明书附图1-4、说明书摘要、摘要附图。驳回决定引用的对比文件为对比文件1：CN103684898A，公开日为2014年03月26日；对比文件2：CN102609346A，公开日为2012年07月25日。其理由是：权利要求1-10相对于对比文件1与对比文件2和公知常识的结合不具备专利法第22条第3款规定的创造性。驳回决定所针对的权利要求书如下：
“1. 一种分布式服务的监控方法，其特征在于，所述方法包括：
日志获取步骤：获取从分布式服务的多个模块采集的业务请求处理日志，其中，在所述从所述多个模块采集的业务请求处理日志的日志记录当中被记录的同一业务请求具有相同的业务请求标识，并且所述日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识；
日志聚合步骤：将具有相同的业务请求标识的日志记录分别聚合为日志记录集合；
日志分析步骤：对聚合得到的日志记录集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。
2. 根据权利要求1所述的方法，其特征在于，所述方法还包括日志结构化步骤：从所述日志记录分别提取业务请求标识、第一模块标识、第二模块标识以及关于处理结果状态的数据，生成相应的日志记录索引。
3. 根据权利要求2所述的方法，其特征在于，
在所述日志聚合步骤，将具有相同的业务请求标识的日志记录索引分别聚合为日志记录索引集合；
在所述日志分析步骤，对聚合得到的日志记录索引集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成异常模块被标注的所述业务请求的请求调用关系拓扑图。
4. 根据权利要求3所述的方法，其特征在于，所述方法还包括报警信息生成步骤：根据所述异常模块被标注的请求调用关系拓扑图和相应的日志记录索引集合生成所述业务请求的报警信息。
5. 根据权利要求4所述的方法，其特征在于，所述方法还包括报警信息提供步骤：发送或展示所述报警信息。
6. 一种分布式服务的监控装置，其特征在于，所述装置包括：
日志获取单元，用于获取从分布式服务的多个模块采集的业务请求处理日志，其中，在所述从所述多个模块采集的业务请求处理日志的日志记录当中被记录的同一业务请求具有相同的业务请求标识，并且所述日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块 的第二模块标识；
日志记录聚合单元，用于将具有相同的业务请求标识的日志记录分别聚合为日志记录集合；
日志记录集合分析单元，用于对聚合得到的日志记录集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。
7. 根据权利要求6所述的装置，其特征在于，所述装置还包括日志记录索引生成单元，用于从所述日志记录分别提取业务请求标识、第一模块标识、第二模块标识以及关于处理结果状态的数据，生成相应的日志记录索引。
8. 根据权利要求7所述的装置，其特征在于，
所述日志记录聚合单元用于将具有相同的业务请求标识的日志记录索引分别聚合为日志记录索引集合；
所述日志记录集合分析单元用于对聚合得到的日志记录索引集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成异常模块被标注的所述业务请求的请求调用关系拓扑图。
9. 根据权利要求8所述的装置，其特征在于，所述装置还包括报警信息生成单元，用于根据所述异常模块被标注的请求调用关系拓扑图和相应的日志记录索引集合生成所述业务请求的报警信息。
10. 根据权利要求9所述的装置，其特征在于，所述装置还包括报警信息提供单元，用于发送或展示所述报警信息。”
申请人（下称复审请求人）对上述驳回决定不服，于2019年05月31日向国家知识产权局提出了复审请求，同时修改了权利要求书，在独立权利要求1、6中补入技术特征“所述日志记录还包括第一模块的IP地址和第二模块的IP地址”。复审请求人认为：权利要求1与对比文件1相比存在如下区别：（1）权利要求1对聚合得到的日志记录集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。本申请和对比文件2是两个不同的异常分析过程，没有给出“通过生成业务请求调用关系拓扑图来监控业务异常情况的启示”。（2）权利要求1日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识；日志记录还包括第一模块的IP地址和第二模块的IP地址。分布式系统中一个模块可以在几十甚至几百的计算机上执行，日志记录还记录模块的IP地址，使得研发人员可以据此进行硬件异常分析。（3）权利要求1将具有相同的业务请求标识的日志记录分别聚合为日志记录集合。对比文件1中同一用户请求的不同进程日志是按照时间顺序进行组合的，然而，不同进程之间的调用关系很可能和进程之间的时间顺序是不同的。对比文件2中业务模型是根据特定业务系统的业务逻辑构建的，也未公开上述区别特征。本申请权利要求1的技术方案的有益效果在于：当某一业务请求的处理结果发生异常时，根据日志记录集合中记录的该业务请求的模块之间的调用关系，生成请求调用关系拓扑图，供研发人员对异常请求进行快速止损。修改后的独立权利要求1、6如下：
“1. 一种分布式服务的监控方法，其特征在于，所述方法包括：
日志获取步骤：获取从分布式服务的多个模块采集的业务请求处理日志，其中，在所述从所述多个模块采集的业务请求处理日志的日志记录当中被记录的同一业务请求具有相同的业务请求标识，并且所述日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识；所述日志记录还包括第一模块的IP地址和第二模块的IP地址；
日志聚合步骤：将具有相同的业务请求标识的日志记录分别聚合为日志记录集合；
日志分析步骤：对聚合得到的日志记录集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。”
“6. 一种分布式服务的监控装置，其特征在于，所述装置包括：
日志获取单元，用于获取从分布式服务的多个模块采集的业务请求处理日志，其中，在所述从所述多个模块采集的业务请求处理日志的日志记录当中被记录的同一业务请求具有相同的业务请求标识，并且所述日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识；所述日志记录还包括第一模块的IP地址和第二模块的IP地址；
日志记录聚合单元，用于将具有相同的业务请求标识的日志记录分别聚合为日志记录集合；
日志记录集合分析单元，用于对聚合得到的日志记录集合分别进行分析，其中，对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。”
经形式审查合格，国家知识产权局于2019年06月11日依法受理了该复审请求，并将其转送至实质审查部门进行前置审查。
实质审查部门在前置审查意见书中坚持驳回决定。
随后，国家知识产权局成立合议组对本案进行审理。
合议组于2019年10月31日向复审请求人发出复审通知书，复审通知书所针对的文本为：2019年05月31日提交的权利要求第1-10项；申请日2015年08月20日提交的说明书第1-59段、说明书附图1-4、说明书摘要、摘要附图。复审通知书引用的对比文件与驳回决定引用的对比文件相同，复审通知书指出：权利要求1-10相对于对比文件1与对比文件2和公知常识的结合不具备专利法第22条第3款规定的创造性。并针对复审请求人的意见进行了评述。
复审请求人于2019 年12月12日提交了意见陈述书，但未修改申请文件。复审请求人认为：权利要求1与对比文件1相比存在如下区别：（1）对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。本申请和对比文件2是相反过程，二者不同，对比文件2中“业务模型”虽然包含拓扑关系，但是“业务模型”与请求调用关系拓扑图不同，且无法应用于分布式服务中异常定位场景。（2）权利要求1中所述日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识；日志记录还包括第一模块的IP地址和第二模块的IP地址。虽然对比文件1中日志包括调用的函数名称和位置，可对比文件1记录的是函数级别的日志数据，粒度较细，因此对比文件1没有给出区别特征（2）的技术启示。本申请权利要求1的技术方案的有益效果在于：当某一业务请求的处理结果发生异常时，根据日志记录集合中记录的该业务请求的模块之间的调用关系，生成请求调用关系拓扑图，供研发人员对异常请求进行快速止损。
在上述程序的基础上，合议组认为本案事实已经清楚，可以作出审查决定。
二、决定的理由
（一）审查文本的认定
复审请求人在提出复审请求时修改了权利要求书，本复审请求审查决定所针对的文本为：2019年05月31日提交的权利要求第1-10项；申请日2015年08月20日提交的说明书第1-59段、说明书附图1-4、说明书摘要、摘要附图。
（二）具体审查意见
专利法第22条第3款规定：创造性，是指与现有技术相比，该发明具有突出的实质性特点和显著的进步，该实用新型具有实质性特点和进步。
本复审决定引用的对比文件与驳回决定和复审通知书所引用的对比文件相同，即：
对比文件1：CN103684898A，公开日为2014年03月26日；
对比文件2：CN102609346A，公开日为2012年07月25日。
1.权利要求1请求保护一种分布式服务的监控方法，对比文件1公开了一种监测用户请求在分布式系统中运行的方法及装置（参见对比文件1说明书第[0026]-[0037]段、第 [0041]-[0062]段，图1-7）：S101、对分布式系统中各服务器接收到的用户请求进行采样；S102、对各服务器采样到的用户请求生成对应的标识符，该标识符在用户请求调用线程时会作为变量被传递到当前线程中；S103、预先对分布式系统中各服务器运行的进程注入跟踪接口，当进程运行到该跟踪接口时，若检测到当前该进程包含用户请求对应的标识符，则将标识符和跟踪接口所指示的函数的相关信息对应并生成日志；S104、将生成的日志按照所对应的标识符分别进行汇总。在步骤S104中，当分布式系统中各服务器的日志生成后，后台收集程序会每隔一段时间将日志收集（相当于日志获取步骤，获取从分布式服务的多个模块采集的业务请求处理日志）到处理服务器中进行关联，即按照不同的标识符（相当于业务请求标识）进行汇总。具体地，可以按照下述方式进行汇总（相当于日志聚合步骤）：首先，将收集到的日志按照不同标识符分别进行归类；然后，对于同一标识符的日志，按照不同的进程分别进行归类；接着，对于同一标识符的同一进程的日志，按照函数按照调用开始和结束时间分别进行合并；最后，对同一标识符跨进程的日志，按照时间顺序进行组合（将具有相同业务标识请求标识的日志记录分别聚合为日志记录集合）。较佳地，在步骤S104将日志进行汇总之后，还可以根据具体需求，对汇总后的日志进行分析（相当于日志分析步骤，对聚合得到的日志记录集合分别进行分析），并输出分析结果。在具体实施时，可以通过日志分析程序将不同的标识符进行归类组合，形成分析的原始数据。为了能够方便分析用户请求在程序中的运行方式，可以采用可视化/分析框架帮助理解程序运行的方式。
权利要求1与对比文件1的区别特征在于：所述日志记录包括当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识；所述日志记录还包括第一模块的IP地址和第二模块的IP地址。对处理结果发生异常的业务请求，根据所述业务请求在模块之间的调用关系生成所述业务请求的请求调用关系拓扑图。基于上述区别特征，权利要求1实际要解决的技术问题是：对处理结果发生异常的业务请求，如何根据监控日志进行快速判断。
对于上述区别特征，对比文件2公开了一种基于业务操作的监控方法和装置，并具体公开了（参见对比文件2说明书第[0051]段）：上述业务操作和该业务操作对应的各物理设备的逻辑流程形成本实施例的业务模型。该业务模型把前端的业务操作和后端的各物理设备的逻辑流程进行关联建模，并以拓扑的方式进行展现，如图4所示，清晰、直观、动态的展现了整个业务系统的运行状况，以及当前系统的运行效率和瓶颈发生在哪个业务环节。即对比文件2给出了通过生成业务请求调用关系拓扑图来监控业务异常情况的启示，而在日志记录中记录当前模块的第一模块标识和调用所述当前模块的调用模块的第二模块标识是本领域技术人员为了生成业务请求的请求调用关系拓扑图的常用技术手段，属于本领域公知常识。因此在对比文件1的基础上结合对比文件2及本领域的公知常识可以显而易见地得到权利要求1的方案，因此该权利要求所要求保护的技术方案不具备突出的实质性特点和显著的进步，因而不具备专利法第22条第3款规定的创造性。
2.权利要求2引用权利要求1，而从日志记录分别提取业务请求标识、第一模块标识、第二模块标识以及关于处理结果状态的数据，生成相应的日志记录索引以使日志结构化是本领域技术人员在进行日志分类汇总时惯用技术手段，属于本领域公知常识，因此，在其引用的权利要求不具备创造性时，该权利要求也不具备专利法第22条第3款规定的创造性。
3.权利要求3引用权利要求2，将具有相同的业务请求标识的日志记录索引分别聚合为日志记录索引集合；在日志分析步骤，对聚合得到的日志记录索引集合分别进行分析，对处理结果发生异常的业务请求，根据业务请求在模块之间的调用关系生成异常模块被标注的业务请求的请求调用关系拓扑图等技术特征是本领域技术人员为了进一步突出异常模块所惯用的手段，属于本领域公知常识，因此，在其引用的权利要求不具备创造性时，该权利要求也不具备专利法第22条第3款规定的创造性。
4.权利要求4、5直接或间接引用权利要求3，而根据异常模块被标注的请求调用关系拓扑图和相应的日志记录索引集合生成业务请求的报警信息。以及发送或展示报警信息均是本领域技术人员为了实现异常模块的报警功能的惯用技术手段，属于本领域公知常识，因此，在其直接或间接引用的权利要求不具备创造性时，权利要求4、5也不具备专利法第22条第3款规定的创造性。
5.权利要6-10是与权利要求1-5相对应的装置权利要求，而通过设置不同的功能模块完成相应的功能是本领域的惯用手段，基于与评述权利要求1-5相类似的理由，权利要求6-10也不具备专利法第22条第3款规定的创造性。
（三）针对复审请求人意见的答复
对于复审请求人的意见，合议组认为：对于复审请求人认为的区别（1），参见上述对权利要求1的评述可知，对比文件1给出了可采用可视化/分析框架方式以便于分析，但未具体公开调用关系拓扑图。对比文件2公开了基于业务操作的监测方法，把前端的业务操作和后端的各物理设备的逻辑流程进行关联建模，以拓扑的方式清晰、直观、动态的展现整个业务系统的运行状况，以及当前系统的运行效率和瓶颈发生在哪个业务环节。即对比文件2给出了通过拓扑图来监控业务异常情况的启示。另外，对比文件1还公开了（参见对比文件1说明书第0038-0039段，第0047-0051段）：可以将该标识符、调用的函数名称和位置、调用函数的时间、以及调用时产生的错误信息输出到日志中。对日志的具体分析可以是：对用户请求在分布式系统中的运行路径，以及在各模块中运行时间的分析。由于以调用的函数/模块的关联关系表征运行路径是本领域的常用技术手段，因而，对于发生异常的业务请求，以调用模块的关联关系构造拓扑图进行分析是本领域技术人员基于对比文件1和2的公开内容所容易想到的具体常规选择。对于复审请求人认定的区别（2），对比文件1公开了日志中包括调用的函数名称和位置（参见对比文件1说明书第0038-0039段）。由模块所在计算机/服务器来表征其位置是本领域技术人员容易想到的，且IP地址是本领域常用表征位置信息。进而，在前述以调用的函数/模块的关系表征运行路径的考虑下，在日志中记录模块标识、模块IP，具体地，记录当前模块的模块标识、IP地址和调用所述当前模块的调用模块的模块标识、IP地址是本领域技术人员基于对比文件1位置信息记录的具体设定。从而为了使研发人员对异常请求进行快速止损，在对比文件1的基础上结合对比文件2及本领域的公知常识可以显而易见地得到权利要求1的方案。
综上，合议组对复审请求人的意见不予接受。
三、决定
维持国家知识产权局于2019年03月04日对本申请作出的驳回决定。
如对本复审请求审查决定不服，根据专利法第41条第2款的规定，复审请求人可以自收到本决定之日起三个月内向北京知识产权法院起诉。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
