通過“蛛絲馬跡”識別網絡領域疑似協議改進類申請研究

王莉 陳麗鋒

(國家知識產權局專利局專利審查協作湖北中心，湖北 武漢 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 加密算法都是本領域公知的非對稱加密算法，因此可以采用該標準協議評述該權利要求的創造性，后來仔細研究后發現，該申請的從權的大部分特征也已該協議中公開。

三、結語

本文對網絡通信領域的可能涉及協議的檢索技巧進行了一個經驗總結，重點分析了涉及可能存在協議作為對比文件的案件的檢索過程。本文內容均是筆者在實際審查中的一些心得體會，希望對該領域的審查工作有所幫助。（第二作者對本文貢獻等同于第一作者）