多主體實施方法專利侵權案的微觀分析——從技術角度剖析敦駿訴騰達案侵權判定存在的問題

引言

2019年12月10日，最高院知産庭公開宣判了一起涉及網絡通信領域多主體實施方法專利的侵權糾紛案件（（2019）最高法知民終147号，一審原告爲敦駿公司，被告爲騰達公司，涉案專利的專利号爲ZL02123502.3），該案在行業内引起了不小的轟動。關于該案的評論文章很多，已有的評論文章更多地将關注點放在了多主體實施方法專利的侵權行爲是否符合全面覆蓋原則上，幾乎沒有文章從案件的要件事實出發，去讨論涉案路由器所采用的技術方案是否覆蓋了涉案專利的全部技術特征。

本文試圖從要件事實出發，厘清涉案路由器所采用的技術方案與涉案專利是否存在不同點，以此爲基礎，分析本案要件事實認定是否存在問題，以及可能産生問題的原因。

了解本案必要的通信基礎知識——數據如何在TCP（傳送控制協議）機制下傳送？HTTP報文是什麽？

1 數據如何在TCP機制下傳送？

計算機網絡體系結構的經典模型采用五層模型，包括物理層、數據鏈路層、網絡層、運輸層和應用層。TCP運輸協議是應用在運輸層的重要協議。“TCP是面向連接的協議。運輸連接是用來傳送TCP報文的。TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。因此，運輸連接就有三個階段，即：連接建立、數據傳送和連接釋放。”[1]

建立TCP連接表現爲三次握手過程，通過三次握手建立數據傳送的通道，而數據傳送則是在已經建立好的TCP連接的基礎上進行數據傳輸，當發送方确認數據全部傳送完成後，斷開TCP連接，将相關資源釋放。

兩個應用進程（爲更容易理解，可以簡單地認爲是兩台電腦A、B，A爲客戶端，B爲服務器端）之間隻能建立一個TCP連接，通過IP地址和端口号來确定這條TCP連接，IP地址指A、B的IP地址，同時A、B各自分配一個端口号用于這條TCP連接。在利用該TCP連接傳送數據時，需要核實雙方的IP地址和端口号，隻有IP地址和端口号是正确的，才能正确地傳送數據，否則會出錯。另外，在A與B進行數據交互時，A發送給B的每一條數據，B都會給出回應，在該回應中會明确表明是對A發送的哪一條數據的回應。如果A長時間沒有得到B的回應，A會将該數據重新發給B，或者，A等待的時間過長，A會認爲這條TCP連接已經斷開了，A與B之間将重新建立一條新的TCP連接。

2 HTTP報文是什麽

HTTP協議定義了浏覽器怎樣向萬維網服務器請求萬維網文檔，以及服務器怎樣把文檔傳送給浏覽器。HTTP是面向事務的應用層協議，是萬維網能夠可靠地交換文件的重要基礎。[2]

HTTP報文是基于HTTP協議的，HTTP報文是通過TCP連接傳送的數據。

涉案專利的技術方案是什麽？

1 涉案專利的應用場景

涉案專利涉及的是強制Portal業務。簡單來說，用戶上網都需要付費，需要向網絡運營商購買賬号，當用戶通過浏覽器訪問sina時，首先要判斷該用戶有沒有通過網絡運營商的認證，也就是判斷該用戶在請求訪問sina之前是否已經驗證過用戶名密碼，如果已經驗證了，就允許該用戶直接訪問sina，如果沒有驗證，那麽雖然該用戶想訪問sina，但實際呈現在其浏覽器上的頁面是網絡運營商的認證頁面，要求用戶在認證頁面輸入用戶名密碼。

我們在機場、車站、賓館經常會遇到Portal認證，手機連接WIFI後，在浏覽器輸入sina的鏈接，頁面自動跳轉到認證頁面，有的認證頁面隻需要我們點擊任何一幅圖片即可完成認證，有的需要輸入手機号碼，通過手機獲得驗證碼完成認證，該認證通常集成在路由器中，機場、車站、賓館等管理方充當虛拟網絡運營商的角色。不過需要指出的是，這種應用場景在涉案專利申請時是不存在的，當時的認證工作是由電信、鐵通等網絡運營商負責。此外，在現今的家庭寬帶中，路由器的自動撥号功能代替了我們自己訪問網絡運營商的認證頁面，不再需要登錄認證頁面進行認證。

2 涉案專利說明書披露的技術方案

涉案專利權利要求1：一種簡易訪問網絡運營商門戶網站的方法，其特征在于包括以下處理步驟：

A.接入服務器底層硬件對門戶業務用戶設備未通過認證前的第一個上行 HTTP報文，直接提交給“虛拟Web服務器”，該“虛拟Web服務器”功能由接入服務器高層軟件的“虛拟Web服務器”模塊實現；

B.由該“虛拟Web服務器”虛拟成用戶要訪問的網站與門戶業務用戶設備建立TCP連接（本文注：下稱步驟B1），“虛拟Web服務器”向接入服務器底層硬件返回含有重定向信息的報文，再由接入服務器底層硬件按正常的轉發流程向門戶業務用戶設備發一個重定向到真正門戶網站Portal_Server的報文；

C.收到重定向報文後的門戶業務用戶設備的浏覽器自動發起對真正門戶網站Portal_Server的訪問。

結合圖1，涉案專利的技術方案是：1、PC（用戶）請求訪問sina，PC希望通過接入服務器（如，路由器）發出HTTP報文（一般指HTTPGET報文）給sina服務器。2、接入服務器底層硬件判斷PC沒有通過認證，直接将該HTTP報文截留不發給sina服務器，而是提交給由接入服務器高層軟件虛拟的虛拟sina。3、虛拟sina與PC建立TCP連接，返回含重定向信息的HTTP報文（即，發一個新的URL，告訴PC去訪問Portal服務器，也就是圖2中的P.S）給接入服務器底層硬件。4、接入服務器底層将該具有重定向信息的報文返回給PC。5、PC根據新鏈接訪問P.S。對應涉案專利獨立權利要求，其中，2構成涉案專利步驟A，3、4構成步驟B，5構成步驟C。

3 涉案專利隐含披露的完整技術方案

根據涉案專利說明書及權利要書的記載，結合本領域一般技術人員對于其所述技術方案的技術理解，其完整實施過程如圖2所示。

具體來說，在步驟A之前，必然存在門戶業務用戶設備（PC）與要訪問的網站（sina）之間建立TCP連接的步驟，即步驟A1，如果兩者之間不事先建立通道，門戶業務用戶設備無法發送第一個上行HTTP報文給要訪問的網站（sina）（即使該報文在步驟A中被截留）。假設該通道爲1号通道。

在步驟C之前，也必然存在門戶業務用戶設備（PC）與Portal_Server（P.S）之間建立TCP連接的步驟，即步驟C1，否則門戶業務設備無法發起對Portal_Server的訪問。假設兩者之間的通道爲3号通道。

另外，将步驟B1中所建立的TCP連接設定爲2号通道。

需要注意的是：2号通道與1号通道是完全不同的兩個通道，1号通道是門戶業務用戶設備（PC）與真實的要訪問的網站（sina）之間建立的通道，而2号通道是門戶業務用戶設備（PC）與接入服務器的虛拟WEB服務器之間的建立的通道（門戶業務用戶設備誤以爲接入服務器的虛拟WEB服務器就是其要訪問的網站（sina））。

涉案專利的保護範圍是否清楚

1 在現行TCP機制下，涉案專利所述技術方案無法實現，其保護範圍不清楚

如圖2所示，由于虛拟Web服務器與門戶業務用戶設備之間建立了不同于1号通道的2号通道，使得利用2号通道發送的含有重定向信息的HTTP報文，并不是對利用1号通道發送的HTTP報文（HTTPGET報文）的回應，也就是說，門戶業務用戶設備收不到利用2号通道發來的HTTP報文，即使能夠收到，門戶業務用戶設備也不會認爲是對1号通道發送的HTTP報文的回應，這将導緻數據傳送錯誤，門戶業務用戶設備的浏覽器報錯，無法發起對Portal_Server的訪問。

在現行TCP機制下，用戶設備的網卡驅動程序、浏覽器、路由器都需要遵守TCP協議。當路由器中的程序是按照圖2所示的方案構建的，那麽，在實際通信過程中，當在步驟B1建立2号通道時，1号通道會被釋放，在這種情況下，用戶設備隻能利用2号通道向sina服務器發送一個新的HTTPGET報文（重新請求訪問sina），也就是說，當進入步驟B1後，實施過程會重新返回步驟A，而不是沿圖3中的虛線箭頭繼續進入後續步驟，由此導緻用戶設備對sina服務器的訪問過程，變成不斷地斷開舊的TCP連接、重新建立新的TCP連接的死循環。

因此，本領域技術人員在遵守TCP機制的情況下，無法實現涉案專利權利要求1所保護的技術方案。

2 在現行TCP機制下，重新解釋步驟B1中的“建立TCP連接”，避免出現2号通道，但這種解釋缺少說明書依據

基于前文的分析，在現行TCP機制下，1号通道與2号通道不能并存，更不可能利用2号通道對用戶設備的HTTPGET報文回應一個含重定向信息的報文，那麽，有沒有可能将步驟B1中的“建立TCP連接”解釋爲不是通常的技術含義，而是指對1号通道的利用過程呢，即此處的“建立TCP連接”是指在數據傳送階段添加TCP報頭的過程？

對權利要求的解釋不能脫離說明書記載的内容。涉案專利說明書中除了發明内容部分照抄權利要求書外，具體實施方式中涉及3處，分别爲：（1）“它的功能就是接收用戶需做強制Portal的報文，虛拟成用戶要訪問的網站與之建立TCP連接（本文注：即步驟B1），然後由該‘虛拟Web Server’向用戶端發一個重定向到Portal_Server的報文”（說明書第6頁第1段）；（2）“接入服務器（BAS）向用戶（PC）端響應一個重定向報文，該重定向報文須告訴用戶要和真正的Portal_Server建立連接并訪問Portal_Server”（說明書第7頁第2段）。此處的“建立連接”即建立3号通道。（3）“‘虛拟Web Server’給用戶端響應一個重定向報文，在此重定向報文中，須告訴用戶端要和真正的Portal_Server建立連接并訪問該真正的Portal_Server”（說明書第9頁第1段）。與前一條相同，指建立3号通道。

也就是說，涉案專利說明書沒有對“建立TCP連接”作出不同于本領域通常含義的解釋，因此，應當解釋爲本領域技術人員所通常理解的含義。正如本文第一部分所介紹的，運輸連接有三個階段，即：連接建立、數據傳送和連接釋放，這三個階段是明确劃分的，有先後邏輯順序，在數據傳輸中，添加TCP報頭是數據傳送階段的一部分，是利用已經建立好的TCP連接進行數據傳送，而不是建立TCP連接。最高院在騰達案中對“建立TCP連接”的解釋即爲本領域技術人員所理解的通常含義，“本領域普通技術人員普遍知曉，一次完整的訪問網站流程包括建立TCP連接（即三次握手過程）、HTTP報文請求以及響應（交互數據）、斷開TCP連接等三個前後關聯、有先後邏輯順序的環節。TCP三次握手報文是HTTP報文傳輸的前提條件，但其本身并非HTTP報文。應用層協議（例如，SMTP、TELNET、HTTP、FTP等）報文傳輸均需以傳輸層TCP三次握手報文建立的連接爲前提”。最高院的解釋也是敦駿公司所堅持的，是該案相關方的共識，也是本領域技術人員的共識。

因此，将“建立TCP連接”解釋爲在數據傳送階段添加TCP報頭的過程，沒有任何依據。

3 在現行TCP機制下，騰達公司試圖将HTTP報文解釋爲TCP報文，這種解釋缺少說明書依據

騰達公司試圖将“第一個上行HTTP報文”解釋爲“第一個上行TCP報文（三次握手過程的第一個TCP報文）”，由此使得涉案專利的技術方案變成：在門戶業務用戶設備與要訪問的網站（sina）建立TCP連接（三次握手）之前，接入服務器判斷該設備是否已經通過認證，如果沒有通過認證，則不讓門戶業務用戶設備與其要訪問的網站建立TCP連接（即，避免建立1号通道），而是由虛拟Web服務器僞裝成要訪問的網站與門戶業務用戶設備建立TCP連接（即，建立2号通道）。

這種解釋雖然避免了前文所論證的同時出現1号通道和2号通道的情況下，導緻涉案專利無法實施的問題，但是帶來了另一個問題，即，由于缺少門戶業務設備發送的請求訪問sina服務器的HTTP報文，虛拟Web服務器不可能回應一個含重定向信息的HTTP報文。更爲重要的是，HTTP報文本身是有國際标準定義的，涉案專利說明書也沒有對其作出新的解釋，隻能理解爲本領域的通常含義。

4 脫離現行TCP機制，涉案專利具有實施可能性

如前文所述，在現行TCP機制下，本領域技術人員無法實施涉案專利，但這不表示涉案專利絕對無法實施。

在不遵守TCP機制的情況下，爲接入服務器與用戶設備編寫專門的程序，僅就兩台特定化的通信設備來說，涉案專利具有實施可能性。該專門程序可以使1号通道與2号通道并存，利用1号通道返回含重定向信息的報文，或者隻保留2号通道，利用2号通道返回針對1号通道發送的HTTP GET報文的回應報文，用戶設備設計成可以接收2号通道發送的回應報文。

但這種方案無法應用在通用網絡設備中，在現實世界中，沒有哪個廠商可以不遵守國際通信标準。

騰達案對要件事實（實施步驟B1）的推定，沒有足夠的依據

1 騰達案中法院對要件事實的推定過程

圖4、5是騰達案中論證騰達公司構成侵權的關鍵圖。180、182、183号報文是用戶電腦與sina服務器之間的三次握手過程（即，建立TCP連接。49号報文是路由器對180号報文的轉發，182号報文是路由器對51号報文的轉發，52号報文是路由器對183号報文的轉發。需要說明的是：Source表示該報文發送者的IP地址，Destination表示該報文接收者的IP地址。細心的讀者可能會發現49、51、52号報文的IP地址與180、182、183号報文有所不同，這是由于内網IP地址無法用于外網通信導緻的，路由器需要将用戶電腦的内網IP地址轉換爲路由器的WAN口地址，切記不能與涉案專利背景技術所提到的SNAT、DNAT混淆）。184号報文是建立TCP連接後，用戶電腦向sina服務器發送HTTP請求的報文，185号報文是騰達路由器僞裝成sina服務器向用戶電腦發送含重定向信息的報文，191号報文是用戶電腦根據重定向信息向Portal_Server發送HTTP請求的報文。除了以上報文外，圖4中的186、193、194号報文是用戶電腦與sina服務器之間斷開原有的TCP連接的四次握手過程（注：圖4沒有截取全部斷開TCP連接的報文）。

最高院認爲，相關報文已經證實，涉案路由器實現了涉案專利步驟A、C、以及步驟B中除步驟B1之外的全部流程。“從公證測試結果來看，騰達W15E路由器的‘虛拟WEB服務器’已經成功虛拟成用戶要訪問的網站（‘www.sina.cn’網站）向用戶電腦發送了重定向報文185号報文，就能證明兩者之間肯定是建立了TCP連接。否則，用戶電腦無法接收到185号重定向報文，也就不可能再有後續的訪問騰達W15E路由器内置的Portal_Server服務器的191号報文”。也就是說，最高院推定涉案路由器實施了步驟B1。

2 騰達案對要件事實的推定沒有依據

騰達案通過wireshark抓包獲取的數據中沒有建立2号通道的過程，正如前文所論述的，在現行TCP機制下，建立2号通道導緻涉案專利無法實施。

那麽，騰達案爲什麽堅持推定涉案路由器實施了步驟B1呢？該推定看似很合理，沒有建立TCP連接就無法傳送數據，但實際上，這是将圖2所示的完整技術方案割裂後所做的錯誤推定。

最高院在“關于騰達W15E路由器使用過程與涉案專利權利要求1和2的技術比對”中提到，“根據前述對于權利要求1的解釋，該三組報文（本文注：指用戶電腦與sina服務器之間建立TCP連接的報文）與權利要求1所限定的方法步驟沒有關系，故在技術比對中不予考慮。與涉案專利權利要求1和2所限定的方法步驟具有對應關系的是184号（本文注：第一個上行HTTP報文）、185号（本文注：含有重定向信息的HTTP報文）和191号報文（本文注：用戶電腦訪問Portal_Server的HTTP報文）”。

也就是說，最高院認爲用戶電腦與sina服務器建立TCP連接的過程（建立1号通道）與本案無關。當将1号通道刻意掩蓋後，也就失去了讨論第一個HTTP報文是通過哪個通道傳送給涉案路由器的基礎，失去了讨論2号通道與1号通道的關系的基礎，失去了讨論是否能夠利用2号通道返回含重定向信息的報文的基礎，最終簡單地認爲所有的數據傳送都建立在已經事先建立好的TCP連接之上，得出看似正确實則謬誤的推定。

結語

在權利要求文字本身清楚的情況下，說明書也沒有對“建立TCP連接”作出不同于通常含義的解釋，那麽，應當根據通常含義來确定權利要求的保護範圍，并且在權利人已經對其作出通常含義的解釋後，應禁止反悔。由于錯誤地寫入步驟B1，導緻在現行TCP機制下涉案專利權利要求保護範圍不清楚，應當由專利權人承擔不利後果。騰達案在多主體實施方法專利的侵權判定規則方面具有很大的創新，但是沒有結合現行TCP機制來确定權利要求保護範圍，最終作出了錯誤的要件事實推定。

[1]謝希仁編著，《計算機網絡》（第五版），電子工業出版社出版，2008年1月，第215頁。有關TCP協議的具體内容可以查閱RFC 793，該協議文本第1.5節關于connection:When two processes wish tocommunicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses.第3.4、3.5、3.7節分别詳細描述了建立TCP連接（Establishing a connection）、斷開TCP連接（Closing a Connection）以及數據通信（Data Communication）。

[2]謝希仁編著，《計算機網絡》（第五版），電子工業出版社出版，2008年1月，第239頁。