通过“蛛丝马迹”识别网络领域疑似协议改进类申请研究

王莉 陈丽锋

(国家知识产权局专利局专利审查协作湖北中心，湖北 武汉 430205)

一、引言

检索策略是提高审查质量，加快审查效率的一个重要因素。我们知道，网络中具有不同的操作系统和不同硬件体系结构的设备之间为了能够实现网络互联，它们必须使用同一种网络通用语言才能进行通信，而通信协议就可以理解为这样一种通用语言，它对不同设备之间进行交互的格式或流程进行了规范，因此，通信协议在通信网络中无处不在，很多专利申请中会涉及协议的内容，但是实际在检索的过程中，却很难知道其技术方案可能会涉及某个协议；原因如下：

（1）审查员技术知识有限：通信领域协议成千上万，技术错综复杂，审查员不可能对所有的协议熟悉，所以较难知道其技术方案可能会涉及某个协议；

（2）申请人刻意规避检索：有时候权利要求的方法可能就是某种协议的内容，但申请人为了规避审查员的检索，往往并不会在申请文件中有所提示，审查员可能就没有意识去检索协议，或者想去检索协议却难以找到突破点，不知道该如何去寻找可能和本申请相关的协议。

笔者对自己工作中遇到的以协议为对比文件的具体案例的检索过程做一些分析、归纳、总结、反思，希望能够对通信领域提高检索效率和审查效率有所帮助。

二、实际案例检索分析

蛛丝马迹1.技术联想，通过已知类似技术方案联想识别协议类申请

案例如下：

一种基于用户数据报协议的网络诊断及性能评估系统，包括网络管理中心服务器，其特征在于，还包括：网络诊断客户端和网络诊断服务器；所述网络诊断客户端和网络诊断服务器之间采用用户数据报协议通信；

所述网络管理中心服务器，用于向网络诊断客户端集中发起诊断请求，接收网络诊断客户端返回的诊断结果；

所述网络诊断客户端，用于将接收到的诊断请求转换成可执行的网络测试指令，据此向网络诊断服务器发送诊断探测包；接收网络诊断服务器回送的诊断结果，再次统计后发送给网络管理中心服务器；

所述网络诊断服务器，用于执行诊断请求，回送诊断结果给网络诊断客户端。

【检索思路】

(1)在专利库简单检索：如果根据惯用的检索策略，根据本发明的技术方案和权利要求特点其实是不好提取关键词的，无非就是采用网络、诊断、客户端、服务器，用户数据报协议这几个词来进行检索，审查员先在专利库里进行了一个简单检索，没有找到可用对比文件。

（2）分析权利要求和说明书特点，技术方案属于网络测试，技术联想，常见的ping测试具有相应协议，且从属权利要求中大量涉及数据格式，因此，判断本申请涉及协议的可能性非常大，转换检索思路；

（3）改变检索策略，寻找协议检索的突破点并进行检索：于是没有继续检索专利库，快速调整，将检索思路调整为外网，希望检索到基于UDP 的网络测试相关的协议，那该如何进行检索是否有相关协议呢？审查员继续仔细研究说明书内容，发现里面有比较专业的词汇，UDP ECHO PLUS，于是以该词汇为线索在百度进行检索，希望能够找到相关协议的线索，通过该词汇“UDP ECHO PLUS”在百度进行搜索，在pudn 程序员网上看到了一段“实现TR143 udp echo plus”的程序，此时再检索“TR143”，就发现其为网络吞吐量和状态测试的协议编号，于是去通信标准网络检索该协议，阅读后发现，其中就有一个基于UDP 的网络测试方案，并且本申请的从属权利要求技术特征基本都被该协议公开。

蛛丝马迹2.通过数据报文格式改进识别协议类申请

案例如下：

一种基于RSSP-II 协议的数据报传输方法，其特征在于，包括如下步骤：

在待发送的数据报中加入认证头和认证尾，所述认证头添加于帧头和用户数据之间，所述认证尾添加于用户数据之后；

发送端对数据报执行认证算法，计算出数据报的hash 哈希校验值，并将hash 哈希校验值存储在认证尾中；

发送端向接收端发送加有认证头和认证尾的数据报；

接收端对发送端发送来的数据报进行认证检查，接收符合要求的数据报，丢弃不符合要求的数据报。

【检索思路】

（1）去外网学习了解背景知识：首先这是关于RSSP-II 协议的数据报传输方法，由于对RSSP-II 协议并不了解，因此，不必先进行专利库的检索，首先去知网搜索关于RSSP-II 协议方面的文章，研究了一下它的协议架构和数据传输格式，对个协议有一个快速的总体的认识，该协议本身没有认证头和认证尾。

（2）分析权利要求的特点，涉及对数据报文格式的改进，在通信领域中，这种对数据格式进行定义的一般都在标准里进行的，而在网络安全领域，有很多种网络安全协议，而且在协议中常常会规定数据格式，从本领域经验出发，觉得应该有这种有认证头和认证尾这种数据格式的协议，只是暂时不了解有什么协议有认证头和认证尾。

（3）寻找协议检索的突破点并进行检索：在百度里搜认证，头，尾，发现了一个专业词汇“AH”,然后针对AH 进行搜索，发现ipv6 网络中为网络安全提出的ipsec 协议中含有认证头AH，于是去通信标准网下载ipsec 协议，对该协议进行研读，发现该协议的安全架构中定义了两种数据封装模式，一种是ESP(封装安全载荷)封装模式，一种是AH(验证头)封装模式，其中ESP(封装安全载荷)封装模式中的数据报格式就有认证头和认证尾，仔细研究该协议后发现，本申请从属权利要求限定的具体的细节，都和ESP 数据报格式一致，本申请就是在RSSP-II 协议的数据报中加入了ipsec 协议的ESP 封装格式，从权特征也基本全部被该协议公开。

蛛丝马迹3.通过专有技术消息交互，并大量出现专业词汇识别协议类申请

案例如下：

一种基于国密算法建立TLS 通道的方法，其特征在于，所述方法包括步骤：握手请求阶段：服务器端发起hello 请求消息、客户端收到后发送客户端hello 消息作为回应，或客户端直接发起客户端hello 消息；服务器端收到所述客户端hello 消息后，发送服务器端hello 消息作为回应；

服务器端认证阶段：服务器端向客户端发送服务器端SM2 证书，随后发送hello 完成消息；

客户端认证阶段：客户端收到所述hello 完成消息后，发送密钥交换消息；

完成握手阶段：客户端发送更换密码套件消息和结束消息，服务器端收到客户端结束消息后，发送更换密码套件消息和结束消息；双方均收到对方的结束消息并通过验证后，以约定的安全参数进行数据安全传输。

【检索思路】

（1）去外网了解本申请背景知识：首先发现TLS 通道是一个比较专业的词汇，对这个技术不是很了解，因此，不必盲目从权利要求技术方案中提取关键词在专利库检索，先去外网百度进行检索，了解TLS 通道的含义，原来是代表安全传输层。

（2）分析权利要求特点，审查员发现本申请权利要求大部分都是涉及专业技术TLS 通道建立过程中的交互消息，并含有hello 消息这种比较专业的词汇，不像是自定义的词汇，而在通信领域中，协议中通常会定义专业技术系统架构的基础流程交互，因此本申请内容涉及协议相关的可能性非常大。

（3）寻找协议检索的突破点并进行检索：由于在外网了解到TLS 是一个专有词汇，于是检索TLS，协议，发现TLS 通道为协议IETF_2246 中定义的技术规范,于是去通信标准网下载该协议，仔细研究该协议后发现，权利要求1 请求保护的TLS 通道建立方法就是标准的TLS 握手协议的内容，只不过限定了服务器端的证书具体是采用SM2 加密算法，而该协议中列举的加密算法为RSA 加密算法，而SM2 加密算法和RSA 加密算法都是本领域公知的非对称加密算法，因此可以采用该标准协议评述该权利要求的创造性，后来仔细研究后发现，该申请的从权的大部分特征也已该协议中公开。

三、结语

本文对网络通信领域的可能涉及协议的检索技巧进行了一个经验总结，重点分析了涉及可能存在协议作为对比文件的案件的检索过程。本文内容均是笔者在实际审查中的一些心得体会，希望对该领域的审查工作有所帮助。（第二作者对本文贡献等同于第一作者）