Sound View訴Hulu案：方法權利要求步驟順序的隱含限制及專利撰寫啟示

2026年1月29日，美國聯邦巡回上訴法院（CAFC）就Sound View Innovations, LLC v. Hulu, LLC一案作出先例性判決，涉及流媒體技術領域的美國專利US6708213（已過期）。該案的焦點在于：

方法權利要求中的步驟是否必須按書面順序執行，以及如果權利要求隱含要求了步驟順序，被控實施方式未按該順序執行是否構成不侵權？

Sound View公司指控Hulu公司使用第三方邊緣服務器緩存和提供流媒體內容的行為侵犯了‘213專利的方法權利要求，而爭議集中于‘213專利的方法權利要求16。

來源于Maxipat

該權利要求旨在通過在中間“幫助服務器”（helper servers）緩存部分流媒體對象并調整傳輸速率來降低網絡延遲。Hulu主張其產品未按權利要求規定的順序執行步驟，因而不落入專利保護范圍。聯邦巡回法院最終支持了Hulu的不侵權抗辯，認定權利要求16的前兩步存在隱含順序，Hulu系統并未以所需順序執行這些步驟，因而不構成侵權。這一判決不僅關系到本案結果，更總結和發展了方法權利要求中步驟順序限制的判定標準，對專利撰寫具有重要啟示。

‘213專利的權利要求16是一個方法權利要求，描述了一種在包含內容服務器和多個幫助服務器（HS）的網絡中減少延遲的方法。該權利要求包括四個步驟，其中前兩步是爭議焦點：

步驟1（請求）： 在一個幫助服務器接收來自客戶端對流媒體（SM）對象的請求。

步驟2（分配緩沖）： 在幫助服務器處分配一個緩沖區，以緩存所請求SM對象的至少一部分。

步驟3（下載與檢索并行）： 將所述部分SM對象下載/發送至請求客戶端的同時，并行地從另一幫助服務器或內容服務器檢索該SM對象的其余部分。

步驟4（調整傳輸速率）： 調整該幫助服務器向客戶端傳輸數據的速率。

權利要求16具體表述了“接收來自客戶端的SM對象請求”以及“分配緩沖區以緩存所述請求的SM對象的一部分”，并使用了“said requested SM object（所述請求的SM對象）”這樣的措辭。需要注意的是，權利要求16并未用明顯的次序詞（如“然后”then，或條件短語“響應于”upon等）直接限定步驟順序，也沒有用序號標識步驟順序；相比之下，同一專利中的權利要求10用字母/數字標注了步驟順序，權利要求13使用了“upon receiving said first request（在接收到請求時）”這樣的條件語言明確限定了步驟發生的時機。正因如此，Sound View主張權利要求16表面上并未限定順序，可以不按列舉順序執行。然而，該權利要求中第二步的措辭引用了第一步的結果（“所述請求的SM對象”），這一語言結構和語法邏輯正是本案討論的核心。

一般原則而言，如果方法權利要求的各步驟并未明確限定執行順序，那么通常不應將其解釋為必須按特定順序執行。聯邦巡回法院重申：“除非方法權利要求的步驟在字面上實際規定了順序，否則通常不將這些步驟解釋為有特定執行順序”。然而，多年的判例也確立了一個重要例外：當權利要求語言本身（從邏輯或語法上）要求按所述順序執行，或者說明書直接或隱含地要求特定順序時，則需要按照書面順序來限制步驟。這一標準源自諸多聯邦巡回法院判例，例如Interactive Gift案件和Mformation案件等。簡言之，如果后續步驟的措辭邏輯上依賴于前一步驟已完成，則存在隱含的步驟順序限制。

在本案中，聯邦巡回法院通過分析權利要求16的語言結構，認定該方法權利要求前兩步之間存在隱含順序限制。具體而言：

語法結構上的指代關系：權利要求16第二步中的短語“said requested SM object（所述請求的SM對象）”中的“requested”（被請求的）一詞，系第一步“接收…請求”所產生的語義結果。法院指出，從語法上看，第一步提到的“a request for an SM object”提供了第二步中“所述請求的SM對象”的先行依據。“requested”這個過去分詞形式不僅是語法修飾詞，更是一個狀態指示，反映出某動作已經完成——即收到請求。換言之，要稱某對象為“已被請求的對象”，邏輯上必須先發生“請求”這一動作。如果沒有先收到請求，就無從談及“所述請求的SM對象”。正如法院強調的，“緩沖區不可能被分配來緩存一個尚未被請求的SM對象”。因此，從語言和邏輯上，步驟1（接收請求）必須先于步驟2（分配緩沖）完成。

邏輯上的因果或功能關系：除語法外，法院也考察了步驟之間的內在邏輯關系。如果第二步的執行需要依賴于第一步的結果（例如第一步賦予對象“已被請求”的狀態，或產生一個可供第二步使用的參數），那么即使權利要求未明確寫“先/后”，也應推斷存在順序要求。本案中，正是由于第二步操作的對象被定義為“已被請求的”SM對象，內在地表明只有在收到請求（步驟1完成）后才能進行緩沖區分配（步驟2）。這樣的邏輯依賴屬于判例所說的“固有的邏輯依存或功能關聯”，因此權利要求隱含要求了步驟1先于步驟2。法院引用以往案例：“當方法權利要求中后續步驟的措辭指涉了前一步驟的完成結果時，所有這些步驟必須按順序執行”。

聯邦巡回法院認定，‘213專利權利要求16中“接收請求”和“分配緩沖”這兩步具有隱含的順序限制：語法和邏輯均要求先請求再分配緩沖。這一認定為Hulu的“不按順序執行”抗辯提供了法律基礎。

被告Hulu在本案中主張不侵權的一個關鍵理由是：即使其系統執行了權利要求所述的各項功能，但并未按照權利要求16所要求的順序來執行前兩步，因此不落入專利保護范圍。具體來說，Hulu的內容分發網絡（CDN）利用第三方邊緣服務器緩存和傳送視頻，但這些服務器的操作流程并非嚴格按照權利要求16先接收請求、再分配緩沖的順序。例如，Hulu可能預先在邊緣節點配置或留存緩存空間（相當于緩沖區）以應對用戶請求，而不是在收到特定客戶端請求后才動態分配緩沖區。這意味著Hulu的流程中，“緩沖區分配”可能發生在收到客戶請求之前或與其并行，而不是嚴格在其之后。這種實施方式如果與權利要求16隱含要求的順序不符，就可能避開侵權指控。

聯邦巡回法院認可了Hulu的抗辯理由，核心在于確認了權利要求16的順序限制并對比了被控產品的操作順序。法院指出，各方并不爭議Hulu的產品沒有按照地方法院認定的順序執行這些步驟。因此，問題的關鍵在于權利要求是否要求該順序。既然法院通過上述語法和邏輯分析得出權利要求16要求先請求再緩沖，且Hulu系統未以此順序執行，那么Hulu的產品不滿足權利要求全部限定，據此判定不侵權。判決書中明確寫道：“因為被控產品沒有以所要求的順序執行權利要求限定，它們不侵犯權利要求16”。換言之，順序限制成為判定侵權與否的關鍵：只要被控方法不按照必須的順序實施步驟，即使執行了相同的功能流程，也落在專利權要求之外。

法院支持Hulu抗辯的詳細理由正是基于對權利要求的解釋：既然權利要求被正確解讀為包含步驟順序限制，那么未按順序執行就意味著缺少權利要求的一項限制，因此不構成侵權。

面對Hulu以“未按順序執行”作為不侵權理由，專利權人Sound View提出了多方面的反駁，但均未被法院采納。下面逐一分析Sound View的主要主張及法院回應：

1.權利要求缺乏明確順序用語，因而不應限制造成順序： Sound View指出，在同一專利中，某些權利要求（如權利要求10和13）通過明確的措辭表現了順序意圖：例如用字母/數字列舉步驟，或使用“upon receiving…”（在…之后）等條件短語。相比之下，權利要求16沒有使用類似明顯的順序標記，Sound View認為這意味著該權利要求并不限定執行順序。Sound View據此主張，如果發明人有意限定順序，本可以如同其他權利要求那樣明確表達；由于16沒有，說明其步驟可無序執行。

法院回應：不同權利要求可以用不同方式表達順序要求。聯邦巡回法院強調，不能因為16號權利要求缺乏其他權利要求中的特定標記，就推斷其沒有順序限制。實際上，權利要求10、13和16恰是用不同方式指明了順序：權利要求10用編號/字母交叉引用步驟，權利要求13用條件短語限定特定順序，而權利要求16雖然沒有這些表面標記，但其語法和邏輯已經如前所述強制了順序。法院引用原則指出，不同權利要求通常推定范圍不同，不能將一項權利要求的限制硬套到另一項。因此，不能因為別的權利要求明確寫出了順序就認為本權利要求無序可循。換言之，顯性標記的缺失不能抵消隱含語義上的順序要求。

2.只有當“倒序執行”在功能上不可能時才應當認定存在順序限制： Sound View援引了早期一些案例，主張只有在后一步驟若不在前一步驟之后執行就無法實施的情況下，才應當將步驟順序視為權利要求限制。他們引用Interactive Gift和Altiris等案的語言，認為判斷順序限制的標準是看后一步驟是否無法（as written, cannot）在未執行前一步的情況下完成。據此，Sound View辯稱，在權利要求16中，并非不可能先分配緩沖再接收請求——他們認為技術上完全可行：幫助服務器可以預先分配并填充一個緩沖區，然后當客戶端請求到來時，只需將已有的數據發送出去即可。也就是說，從執行效果看，“先緩沖后請求”并非不可實施，權利要求16的步驟順序不應被限制。

法院回應：“功能不可能”并非法律標準，關鍵在于語言邏輯上的依賴。聯邦巡回法院澄清了案例標準的演變和正確適用：過去的判例并不要求只有在亂序執行會使發明不可操作時才認定存在順序限制。相反，判斷重點在于權利要求語言本身：即后續步驟是否參考了前一步驟的結果或狀態。正如法院所言：“我們考察權利要求和說明書以確定方法各步是否必須按書寫順序執行，取決于后續步驟的表述是否邏輯上指示前一步已完成”。因此，即便技術上可以預先分配緩沖，該可能性并不能否定權利要求的語義指向。Sound View引用的Loral案（涉及半導體工藝順序）確實判定需要順序，因為后一步“對準”操作需要前一步“絕緣層已在位”；但本案中法院認為，同樣存在類似依賴：緩沖區的作用對象必須已被請求。即使“顛倒順序在物理上不是不可能”，但只要權利要求邏輯上暗示了前后關系，就應認定順序限制。因此，Sound View試圖將標準限定為“物理不可能”過于狹隘，未被法院接受。

3.說明書支持其它順序的實施方案： Sound View最后求助于‘213專利說明書的圖7B來支持其觀點。圖7B描述了一種網絡配置，其中幫助服務器使用預先分配的緩沖區來進行數據傳輸率控制。Sound View解釋說，在該實施例中，幫助服務器H75預先有一個緩沖區B1（79）存儲了K1秒的數據（即某段SM對象），這發生在收到客戶端請求之前。當稍后收到客戶端請求時，服務器立即將緩沖中的K1秒數據發送給客戶端，同時并行檢索更多數據。Sound View認為，這說明在發明的一個實施方式中，“緩沖區分配”確實發生在“接收請求”之前，證明權利要求16的步驟可以不按順序執行；如果將權利要求解釋為固定順序，則排除了說明書所示實施例，因而可能是錯誤的。

法院回應：圖7B并未提供足夠支持，因其未直接涉及“請求—緩沖”步驟順序。首先，法院指出圖7B并未描述任何“響應于客戶端請求而分配緩沖”的過程——實際上，圖7B的文字說明只是假設HS已有一個預先填充數據的緩沖，但沒有交代該數據如何進入緩沖，也沒有提及在收到請求時分配緩沖的動作。正如Sound View自己在上訴回復中承認的，“該實施例中沒有任何內容描述有緩沖分配是響應于客戶端請求發生的”。圖7B關注的是數據傳輸速率控制（fill/drain一個已存在的緩沖）的情景，與權利要求16的前兩步邏輯并不直接對應。其次，法院注意到，在專利審查過程中，申請人雖然提到了圖7B作為支持，但那是用于支持向權利要求16添加一個全新限定（與步驟順序無關）的書面說明，并非承認該圖揭示了不同順序的實施。最后也是最關鍵的，圖7B的描述跳過了本案相關的關鍵步驟：它直接假定緩沖里已有數據，卻未說明緩沖是何時、如何以及是否在請求之前被設置來緩存那個數據。換言之，圖7B并沒有真正展示“先緩沖后請求”的具體實現步驟。因此，法院裁定圖7B不足以推翻權利要求語言所明確要求的順序。即便存在預分配緩沖的實施方式，申請人在撰寫權利要求16時并未將其覆蓋進去；將16解釋為要求順序并不會不合理地排除說明書披露的發明內容，因為圖7B不直接對應權利要求的步驟限定。

歸納而言，Sound View試圖通過說明書和其它權利要求來證明權利要求16不應有限定順序，但這些論點都被法院逐一駁回。法院強調：不同權利要求的表述差異預示范圍差異，不能因為別的權利要求顯式限定順序就否認本權利要求的隱含順序；法律標準關注語言邏輯，而非工程上是否可顛倒實現；說明書的支持必須明確對應權利要求限制，含糊或間接的描述不足以改變權利要求的解釋。正是基于這些理由，Sound View的反駁均未獲采納，其權利要求16被確認為包含順序限制，從而Hulu的不侵權主張成立。

本案判決延續并鞏固了聯邦巡回法院在方法權利要求步驟順序限定問題上的判例規則，并對標準進行了清晰闡述。在美國專利法實踐中，關于何種情形下方法步驟需要按列舉順序執行，歷經了多年的發展：

早期原則：一般不限定順序：傳統觀點認為，除非權利要求明確要求，否則步驟執行順序通常不作限定。這一原則在Interactive Gift v. Compuserve (Fed. Cir. 2001)等案中得到表述：“除非方法權利要求的步驟實際寫明順序，否則通常不將其按順序解釋”。

邏輯依賴例外：Mantech/Altiris規則： 后來的案例如Mantech Envtl. v. Hudson (Fed. Cir. 1998)、Altiris v. Symantec (Fed. Cir. 2003)等確立了例外情形：當權利要求步驟間存在邏輯上的先后依賴時，應認定隱含順序。例如，Mantech案中因為后續步驟的對象是前一步驟處理過的產物，故認定隱含順序；Altiris案進一步闡明，如果每個后續步驟都引用了前一步驟的結果，那么順序是必要的。這些案件強調的是從權利要求本身出發，尋找語言上或邏輯上的線索，而不要求證明反序執行完全無法運作。

當前標準：Mformation重申： Mformation Tech. v. RIM (Fed. Cir. 2014)對上述規則進行了綜合和重申。Mformation判決明確指出：當權利要求的語言在邏輯或語法上要求按列舉順序執行，或者說明書直接/暗示要求順序時，就應認定存在步驟順序限制。這一標準不再需要嚴格證明“非按序執行將使發明不可行”，而是關注語言和內在邏輯。換句話說，只要權利要求措辭隱含地假定了前一步驟已完成，就滿足順序限定的判定條件。

誤區澄清：本案所示： Sound View曾試圖依賴“功能不可能”的標準來否認順序限制，但聯邦巡回法院在本案中明確否定了這種過嚴的要求。法院指出，不需要證明亂序執行在實際操作上不可能，只要存在固有的邏輯依存關系即可。同時，本案引用了Loral v. Sony (Fed. Cir. 1999)等案例作為例證，說明當后續步驟需要之前步驟的完成狀態（如材料已存在）時，順序被隱含限定。由此可見，判例標準已經演進到以權利要求文本的邏輯含義為中心，而非機械地看有無顯式順序詞或物理可行性。

當前判定方法權利要求步驟順序限制的標準可以概括為：先看權利要求本身是否通過語法結構（如先行詞“所述…的”）或邏輯關系暗示了順序；再看說明書有無明確或隱含要求特定順序。只要滿足其一，即可認定存在順序限制。這一定義較過去更靈活，也更加側重于發明人在權利要求措辭上所隱含傳達的發明結構。本案在這一框架下裁判，進一步強化了權利要求語義決定論的思路：即權利要求的用詞遣句可能自帶技術邏輯，從而約束其覆蓋范圍。

Sound View訴Hulu案為專利代理人和企業法務等實務人員在撰寫和審核方法權利要求時提供了寶貴經驗教訓。如何處理方法步驟的順序問題，避免不必要的限制或漏洞?結合該判決的分析，我們可以從以下幾方面得到啟示：

明確意圖，慎用措辭，避免無意的順序限制

本案凸顯了用詞細節可能帶來的嚴重后果：一個“requested（被請求的）”就決定了權利要求的順序含義。因此，在起草方法權利要求時，務必明確發明人對步驟順序的意圖。如果發明的實施并不要求特定先后次序，應當避免使用暗示順序的詞語或結構。例如，盡量少用“前述/所述…的”這類需要先行引用的限定，或過去分詞形式的狀態描述（如“已完成的X”），因為這些措辭容易被解讀為某步驟結果已存在，從而隱含之前必須執行某動作。在必要情況下，可以通過改寫權利要求來打破這種指代鏈。例如，與其寫“所述請求的對象”，可以考慮在權利要求一開始定義“一個對象”并在各步沿用相同引用，避免中途插入“已…的”狀態限定。總之，注意每個步驟中對象引用的先后關系，確保未無意中令步驟產生依賴。

若需要順序，宜清楚表達或依賴固有邏輯

相反地，如果發明確實需要按一定順序執行，為了增強權利要求清晰度并預防爭議，可以考慮顯式地表達順序關系。例如，可使用連接詞語：“然后（then）…接著…”，或者條件語句：“在…之后執行…”。當然，完全采用這些詞可能在權利要求語言上不夠優雅，但在說明書中至少可以闡明流程順序。本案中，權利要求16雖然沒有明寫“然后”，但依靠邏輯/語法也成功限定了順序。實踐中，如果步驟順序很關鍵，撰寫人不妨在說明書或權利要求中明確強調順序，以減少后續解釋分歧。反之，如果想保留順序上的靈活性，也應避免不必要的限制性詞語。

在說明書中提供不同實施順序的支持

說明書是理解權利要求的重要依據。如果希望權利要求涵蓋不同的執行順序或并行步驟，應當在說明書中有所交代。本案中，Sound View試圖依賴圖7B證明另一種順序，但由于說明書描述不夠直接而未成功。這提醒我們，如果發明的某些實現可以不按常規順序（例如預先步驟、并行處理等），最好明確寫出這種變體。可以在說明書中增加類似表述：“在一些實施方式中，步驟的次序可以交換或并行進行”。甚至可以舉例說明不同順序的流程圖或示意。這樣在日后解釋權利要求時，說明書將提供有力支持，避免法院認為“說明書沒有支持該順序因此不涵蓋”的情況。尤其在涉及并行處理、預處理等技術時，提前描述各種可能的流程順序將使專利保護范圍更加穩健。

管理對象指代鏈，避免歧義狀態描述

方法權利要求中經常出現的陷阱是對象的指代鏈。當一個對象在步驟A中首次提及，然后在步驟B稱為“所述X”時，就建立了前后關聯。要謹慎設計這種關聯關系：確保這符合發明實際流程。如果想讓步驟獨立或可無序，考慮在前序部分定義對象。例如，可在權利要求開頭（或前一步驟）引入“一個緩沖區”，接著的步驟不再引入新限定，而是直接對該緩沖區操作，如此可能在一定程度上避免解釋為嚴格先后（但仍需留意邏輯依賴）。另外，狀態描述（如“已請求”、“已存儲”、“正在進行”等）在英文中通過時態或分詞體現，在中文專利中也可能通過“已…”等表述體現。這類描述一旦出現，往往意味著某狀態形成在先。代理人在斟酌用詞時，應三思此類狀態詞是否必要，以及是否會給不必要的順序要求埋下伏筆。必要時，可以改為功能描述而非狀態描述。例如，與其說“已緩存的數據”，可說“用于緩存數據的數據塊”，盡量不出現時間先后的暗示。

考慮附加權利要求或不同權利要求方案

有時，為了覆蓋發明的各種實現方式，代理人可以撰寫多組權利要求：一組嚴格按照特定順序，一組對順序不作限定或采用不同順序描述。這樣即使某一組被解釋為有順序要求，還有另一組可能覆蓋不同順序的實施例。當然，這需要在說明書中支持不同的順序流程，并權衡權利要求數量和專利策略。在本案中，如果申請人在當初申請時增加一項權利要求明確涵蓋“緩沖可在請求之前分配”的情形，或許就能避免因為順序問題失去對Hulu實施方式的覆蓋。

在說明書或權利要求中加入順序彈性聲明

一些申請人在說明書中加入聲明，如“除非明確指出，方法步驟的執行順序并不限定，步驟可以以任何適當次序執行”，以防止不必要的順序限制。這類聲明并非萬能，但在沒有相反限定時，法院有時會參考說明書這樣的教導，從而不隨意引入順序要求。當然，如果權利要求措辭已經明確或隱含順序（如本案），單靠這類聲明可能不足扭轉局面。但提早聲明順序靈活性至少表明發明人意圖，可在邊緣情況下提供支持。

總而言之，方法權利要求的撰寫既要防止無意的自縛，又要確保必要的限定清晰。Sound View案的教訓在于，每一個詞都可能影響權利要求解釋。專利撰寫人應像程序員審視代碼一樣審視權利要求：檢查“對象—動作—修飾語”之間有無隱藏的時間或邏輯依賴。通過嚴謹的語言和充分的說明書揭示，我們可以在保護發明的廣度與清晰度之間取得平衡，避免因為措辭疏漏而在訴訟中陷入被動。

Sound View訴Hulu案是聯邦巡回法院對方法步驟隱含順序問題的一次重要裁決。權利要求語言的結構和邏輯可能暗含技術順序要求，對侵權判斷具有決定性影響。對于專利實務人士而言，這一案例告訴我們在權利要求措辭上稍有不慎便可能貽誤保護。

Maxipat致力于作為成為科技創新和知識產權工作的AI加速器，主要包括輔助創新：提高研發的科技創新效率；智能搜索與分析：將專利搜索和報告制作借助AI實現智能化，包括智能查新、無效、FTO、Landscaping報告；投資助手：快速生成投資賽道報告、專利購買篩選、專利轉化評估。目前開放注冊中。輔助科技創新和知識產權工作的AI智能體

感興趣的朋友可以通過以下三種方式填寫申請信息：

1. 請發郵件到郵箱：info@maxipat.com

2. 點擊文末閱讀全文；

3. 掃描以下二維碼

感興趣的朋友可以加筆者微信patentlight