通過“蛛絲馬跡”識別網(wǎng)絡(luò)領(lǐng)域疑似協(xié)議改進類申請研究

王莉 陳麗鋒

(國家知識產(chǎn)權(quán)局專利局專利審查協(xié)作湖北中心，湖北 武漢 430205)

一、引言

檢索策略是提高審查質(zhì)量，加快審查效率的一個重要因素。我們知道，網(wǎng)絡(luò)中具有不同的操作系統(tǒng)和不同硬件體系結(jié)構(gòu)的設(shè)備之間為了能夠?qū)崿F(xiàn)網(wǎng)絡(luò)互聯(lián)，它們必須使用同一種網(wǎng)絡(luò)通用語言才能進行通信，而通信協(xié)議就可以理解為這樣一種通用語言，它對不同設(shè)備之間進行交互的格式或流程進行了規(guī)范，因此，通信協(xié)議在通信網(wǎng)絡(luò)中無處不在，很多專利申請中會涉及協(xié)議的內(nèi)容，但是實際在檢索的過程中，卻很難知道其技術(shù)方案可能會涉及某個協(xié)議；原因如下：

（1）審查員技術(shù)知識有限：通信領(lǐng)域協(xié)議成千上萬，技術(shù)錯綜復雜，審查員不可能對所有的協(xié)議熟悉，所以較難知道其技術(shù)方案可能會涉及某個協(xié)議；

（2）申請人刻意規(guī)避檢索：有時候權(quán)利要求的方法可能就是某種協(xié)議的內(nèi)容，但申請人為了規(guī)避審查員的檢索，往往并不會在申請文件中有所提示，審查員可能就沒有意識去檢索協(xié)議，或者想去檢索協(xié)議卻難以找到突破點，不知道該如何去尋找可能和本申請相關(guān)的協(xié)議。

筆者對自己工作中遇到的以協(xié)議為對比文件的具體案例的檢索過程做一些分析、歸納、總結(jié)、反思，希望能夠?qū)νㄐ蓬I(lǐng)域提高檢索效率和審查效率有所幫助。

二、實際案例檢索分析

蛛絲馬跡1.技術(shù)聯(lián)想，通過已知類似技術(shù)方案聯(lián)想識別協(xié)議類申請

案例如下：

一種基于用戶數(shù)據(jù)報協(xié)議的網(wǎng)絡(luò)診斷及性能評估系統(tǒng)，包括網(wǎng)絡(luò)管理中心服務(wù)器，其特征在于，還包括：網(wǎng)絡(luò)診斷客戶端和網(wǎng)絡(luò)診斷服務(wù)器；所述網(wǎng)絡(luò)診斷客戶端和網(wǎng)絡(luò)診斷服務(wù)器之間采用用戶數(shù)據(jù)報協(xié)議通信；

所述網(wǎng)絡(luò)管理中心服務(wù)器，用于向網(wǎng)絡(luò)診斷客戶端集中發(fā)起診斷請求，接收網(wǎng)絡(luò)診斷客戶端返回的診斷結(jié)果；

所述網(wǎng)絡(luò)診斷客戶端，用于將接收到的診斷請求轉(zhuǎn)換成可執(zhí)行的網(wǎng)絡(luò)測試指令，據(jù)此向網(wǎng)絡(luò)診斷服務(wù)器發(fā)送診斷探測包；接收網(wǎng)絡(luò)診斷服務(wù)器回送的診斷結(jié)果，再次統(tǒng)計后發(fā)送給網(wǎng)絡(luò)管理中心服務(wù)器；

所述網(wǎng)絡(luò)診斷服務(wù)器，用于執(zhí)行診斷請求，回送診斷結(jié)果給網(wǎng)絡(luò)診斷客戶端。

【檢索思路】

(1)在專利庫簡單檢索：如果根據(jù)慣用的檢索策略，根據(jù)本發(fā)明的技術(shù)方案和權(quán)利要求特點其實是不好提取關(guān)鍵詞的，無非就是采用網(wǎng)絡(luò)、診斷、客戶端、服務(wù)器，用戶數(shù)據(jù)報協(xié)議這幾個詞來進行檢索，審查員先在專利庫里進行了一個簡單檢索，沒有找到可用對比文件。

（2）分析權(quán)利要求和說明書特點，技術(shù)方案屬于網(wǎng)絡(luò)測試，技術(shù)聯(lián)想，常見的ping測試具有相應(yīng)協(xié)議，且從屬權(quán)利要求中大量涉及數(shù)據(jù)格式，因此，判斷本申請涉及協(xié)議的可能性非常大，轉(zhuǎn)換檢索思路；

（3）改變檢索策略，尋找協(xié)議檢索的突破點并進行檢索：于是沒有繼續(xù)檢索專利庫，快速調(diào)整，將檢索思路調(diào)整為外網(wǎng)，希望檢索到基于UDP 的網(wǎng)絡(luò)測試相關(guān)的協(xié)議，那該如何進行檢索是否有相關(guān)協(xié)議呢？審查員繼續(xù)仔細研究說明書內(nèi)容，發(fā)現(xiàn)里面有比較專業(yè)的詞匯，UDP ECHO PLUS，于是以該詞匯為線索在百度進行檢索，希望能夠找到相關(guān)協(xié)議的線索，通過該詞匯“UDP ECHO PLUS”在百度進行搜索，在pudn 程序員網(wǎng)上看到了一段“實現(xiàn)TR143 udp echo plus”的程序，此時再檢索“TR143”，就發(fā)現(xiàn)其為網(wǎng)絡(luò)吞吐量和狀態(tài)測試的協(xié)議編號，于是去通信標準網(wǎng)絡(luò)檢索該協(xié)議，閱讀后發(fā)現(xiàn)，其中就有一個基于UDP 的網(wǎng)絡(luò)測試方案，并且本申請的從屬權(quán)利要求技術(shù)特征基本都被該協(xié)議公開。

蛛絲馬跡2.通過數(shù)據(jù)報文格式改進識別協(xié)議類申請

案例如下：

一種基于RSSP-II 協(xié)議的數(shù)據(jù)報傳輸方法，其特征在于，包括如下步驟：

在待發(fā)送的數(shù)據(jù)報中加入認證頭和認證尾，所述認證頭添加于幀頭和用戶數(shù)據(jù)之間，所述認證尾添加于用戶數(shù)據(jù)之后；

發(fā)送端對數(shù)據(jù)報執(zhí)行認證算法，計算出數(shù)據(jù)報的hash 哈希校驗值，并將hash 哈希校驗值存儲在認證尾中；

發(fā)送端向接收端發(fā)送加有認證頭和認證尾的數(shù)據(jù)報；

接收端對發(fā)送端發(fā)送來的數(shù)據(jù)報進行認證檢查，接收符合要求的數(shù)據(jù)報，丟棄不符合要求的數(shù)據(jù)報。

【檢索思路】

（1）去外網(wǎng)學習了解背景知識：首先這是關(guān)于RSSP-II 協(xié)議的數(shù)據(jù)報傳輸方法，由于對RSSP-II 協(xié)議并不了解，因此，不必先進行專利庫的檢索，首先去知網(wǎng)搜索關(guān)于RSSP-II 協(xié)議方面的文章，研究了一下它的協(xié)議架構(gòu)和數(shù)據(jù)傳輸格式，對個協(xié)議有一個快速的總體的認識，該協(xié)議本身沒有認證頭和認證尾。

（2）分析權(quán)利要求的特點，涉及對數(shù)據(jù)報文格式的改進，在通信領(lǐng)域中，這種對數(shù)據(jù)格式進行定義的一般都在標準里進行的，而在網(wǎng)絡(luò)安全領(lǐng)域，有很多種網(wǎng)絡(luò)安全協(xié)議，而且在協(xié)議中常常會規(guī)定數(shù)據(jù)格式，從本領(lǐng)域經(jīng)驗出發(fā)，覺得應(yīng)該有這種有認證頭和認證尾這種數(shù)據(jù)格式的協(xié)議，只是暫時不了解有什么協(xié)議有認證頭和認證尾。

（3）尋找協(xié)議檢索的突破點并進行檢索：在百度里搜認證，頭，尾，發(fā)現(xiàn)了一個專業(yè)詞匯“AH”,然后針對AH 進行搜索，發(fā)現(xiàn)ipv6 網(wǎng)絡(luò)中為網(wǎng)絡(luò)安全提出的ipsec 協(xié)議中含有認證頭AH，于是去通信標準網(wǎng)下載ipsec 協(xié)議，對該協(xié)議進行研讀，發(fā)現(xiàn)該協(xié)議的安全架構(gòu)中定義了兩種數(shù)據(jù)封裝模式，一種是ESP(封裝安全載荷)封裝模式，一種是AH(驗證頭)封裝模式，其中ESP(封裝安全載荷)封裝模式中的數(shù)據(jù)報格式就有認證頭和認證尾，仔細研究該協(xié)議后發(fā)現(xiàn)，本申請從屬權(quán)利要求限定的具體的細節(jié)，都和ESP 數(shù)據(jù)報格式一致，本申請就是在RSSP-II 協(xié)議的數(shù)據(jù)報中加入了ipsec 協(xié)議的ESP 封裝格式，從權(quán)特征也基本全部被該協(xié)議公開。

蛛絲馬跡3.通過專有技術(shù)消息交互，并大量出現(xiàn)專業(yè)詞匯識別協(xié)議類申請

案例如下：

一種基于國密算法建立TLS 通道的方法，其特征在于，所述方法包括步驟：握手請求階段：服務(wù)器端發(fā)起hello 請求消息、客戶端收到后發(fā)送客戶端hello 消息作為回應(yīng)，或客戶端直接發(fā)起客戶端hello 消息；服務(wù)器端收到所述客戶端hello 消息后，發(fā)送服務(wù)器端hello 消息作為回應(yīng)；

服務(wù)器端認證階段：服務(wù)器端向客戶端發(fā)送服務(wù)器端SM2 證書，隨后發(fā)送hello 完成消息；

客戶端認證階段：客戶端收到所述hello 完成消息后，發(fā)送密鑰交換消息；

完成握手階段：客戶端發(fā)送更換密碼套件消息和結(jié)束消息，服務(wù)器端收到客戶端結(jié)束消息后，發(fā)送更換密碼套件消息和結(jié)束消息；雙方均收到對方的結(jié)束消息并通過驗證后，以約定的安全參數(shù)進行數(shù)據(jù)安全傳輸。

【檢索思路】

（1）去外網(wǎng)了解本申請背景知識：首先發(fā)現(xiàn)TLS 通道是一個比較專業(yè)的詞匯，對這個技術(shù)不是很了解，因此，不必盲目從權(quán)利要求技術(shù)方案中提取關(guān)鍵詞在專利庫檢索，先去外網(wǎng)百度進行檢索，了解TLS 通道的含義，原來是代表安全傳輸層。

（2）分析權(quán)利要求特點，審查員發(fā)現(xiàn)本申請權(quán)利要求大部分都是涉及專業(yè)技術(shù)TLS 通道建立過程中的交互消息，并含有hello 消息這種比較專業(yè)的詞匯，不像是自定義的詞匯，而在通信領(lǐng)域中，協(xié)議中通常會定義專業(yè)技術(shù)系統(tǒng)架構(gòu)的基礎(chǔ)流程交互，因此本申請內(nèi)容涉及協(xié)議相關(guān)的可能性非常大。

（3）尋找協(xié)議檢索的突破點并進行檢索：由于在外網(wǎng)了解到TLS 是一個專有詞匯，于是檢索TLS，協(xié)議，發(fā)現(xiàn)TLS 通道為協(xié)議IETF_2246 中定義的技術(shù)規(guī)范,于是去通信標準網(wǎng)下載該協(xié)議，仔細研究該協(xié)議后發(fā)現(xiàn)，權(quán)利要求1 請求保護的TLS 通道建立方法就是標準的TLS 握手協(xié)議的內(nèi)容，只不過限定了服務(wù)器端的證書具體是采用SM2 加密算法，而該協(xié)議中列舉的加密算法為RSA 加密算法，而SM2 加密算法和RSA 加密算法都是本領(lǐng)域公知的非對稱加密算法，因此可以采用該標準協(xié)議評述該權(quán)利要求的創(chuàng)造性，后來仔細研究后發(fā)現(xiàn)，該申請的從權(quán)的大部分特征也已該協(xié)議中公開。

三、結(jié)語

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