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
热门跟贴