功能性限定什么时候可以用、边界在哪里？

功能性限定以功能划界，覆盖所有能实现该功能的实施方式，因此必须得到说明书支持；说明书只给出一种特定实现方式、且本领域技术人员不能明了其他替代方式时，这类概括不能用，纯功能性权利要求更直接不允许。

适用时机拟用功能、效果代替结构或步骤特征时

法律与审查依据

为什么这样规定

《专利法》第 26 条第 4 款要求权利要求应当以说明书为依据。指南第二部分第二章 3.2.1 专门处理功能性限定的支持问题：权利要求中的功能性限定特征，应当理解为覆盖了所有能够实现所述功能的实施方式。如果功能是以实施例记载的特定方式完成、且本领域技术人员不能明了还有其他替代方式，或者有充分理由怀疑其中某些方式不能解决技术问题并达到相同效果，则不得采用覆盖这些方式的功能性限定。指南同节还补了一句：纯功能性的权利要求得不到说明书的支持，因而也是不允许的。

为什么功能性限定被从严审查。结构特征划界清楚——写「热管」就是热管；功能特征划界模糊——写「用于快速散热的散热结构」，覆盖的是过去、现在、将来一切能快散热的结构，其中绝大多数说明书根本没公开。支持制度的逻辑是权利范围与公开贡献对价，功能概括让权利要求跑到公开前面很远，所以必须用说明书实施例的密度去约束概括的宽度：公开得越少，允许的概括越窄。

两个否决情形要准确理解。第一情形是「一种实现方式加不能明了替代方式」：说明书只写了用压电陶瓷实现振动，而本领域技术人员看不出还能用电磁线圈、超声马达等方式实现，那么「用于产生振动的振动单元」就把未公开的方式也圈进来了，不能写。第二情形是「有充分理由怀疑某些方式不行」：某些实现方式在原理上达不到说明书声明的效果，这时即使替代方式存在，只要怀疑成立，概括同样不许。两个情形满足其一就触线。

例外与放宽的方向是：本领域技术人员能明了该功能还可采用说明书中未提到的其他替代方式完成的，可以允许较宽的概括。这条在实践中的形态是技术领域通用件：显示单元、通信接口、存储器、紧固件这类本领域有大量公知实现的功能件，说明书给一种实现、权项写功能名，通常能站住。放宽的边界取决于替代方式的公知程度，而不是申请人的意愿，同一句功能写法在通用件与专用件上结论可以相反。

变相的功能性限定更隐蔽：只写达到什么效果、不写任何手段，本质是结果限定。写「一种能够提高散热效率的散热结构」，既没有结构也没有功能实现方式，是纯粹的功能占位；审查员会同时从清楚（保护范围取决于何种结构能算提高效率，DR-CLM-016）与不支持两条线指出问题。判断方法：把这句话里的功能词挖掉，看剩下的是不是空句——剩不下任何结构，就是结果限定。

写错的代价。审查阶段，功能性限定过宽通常收到支持缺陷（第 26 条第 4 款）或纯功能权项不允许的审查意见，修改方向基本只有收窄到实施例公开的方式；无效程序中，功能性特征覆盖了不能实现方式时整条权项可被宣告无效，此类形态集中在说明书实施例单薄的功能件上；维权程序中，功能性特征通常被解释为实施例记载的具体实现方式及其等同方式，保护范围大幅收缩——撰写时以为保护了整个功能域，主张权利时手里只剩实施例那一小块。

与相邻规则的分工：DR-CLM-014 管概括与支持的总体关系，本条是它在功能性限定上的专门化；DR-CLM-016 管清楚，功能词的边界不清与支持不足常常并发，审查意见里两条同时出现是常态；软件领域的程序模块写法尤其要注意——用「单元」「模块」加功能描述的习惯写法普遍，但每个模块仍要能在说明书里落到具体算法或处理流程，否则与机械领域的「散热结构」没有任何区别。

怎么写才合规

逐词做实现清单

把权项里所有以「用于」「能够」「以实现」引出的特征列出来，对每一个问两句：说明书给了几种实现方式？本领域技术人员能否明了其他替代方式？答案是「只有一种、不能明了」时，权项的概括宽度必须退回该种方式；「有多种或能明了」时，功能性写法才站得住。这一步应在写权项之前做，而不是审查意见来了再补。

给说明书补替代方式

功能概括的宽度是买来的，不是默认的。想让「散热结构」覆盖风冷、液冷、均热板、热管，说明书就得把这些方式各写一段——结构、装配关系、关键参数。写作顺序上应该先清点实施例，用实施例的数量决定权项的宽度，而不是先定权项再反推说明书。实施例每多一种，概括的可辩护宽度就大一分。

纯功能改功能加结构

每个只写功能的特征补上至少一个结构锚点。「能够提高散热效率的散热结构」改为「包括均热板与若干翅片，所述均热板与发热元件贴合，所述翅片设于均热板表面」。功能表述可以留在从权里做效果说明，独权的每个特征都要有可见的实现载体，让审查员能从结构本身划出边界。

排查变相结果限定

检索「能够」「提高了」「以实现……为目的」引出、且挖掉功能词后剩下空句的特征。改法有两个方向：把效果量化（「散热效率提高」改「在 10L/min 风量下温升不超过 25℃」），或直接写结构。量化后的指标会成为侵权比对的对象，设阈值时要留出合理余量，不要贴着实测最优值写。

程序模块守住底线

软件权项写「××模块，用于……」时，说明书必须给出该模块的处理流程、输入输出、算法步骤，至少一个模块配一个流程描述。只写模块名加功能句、全篇串起来的写法，在支持与清楚两条线上都过不去；审查员对这类文件的质疑通常成批出现，一处缺陷会引发对全部模块的连带审查。

通用件放宽留证据

打算对显示单元、通信接口这类通用功能件做宽概括时，在说明书写明这些功能在本领域有多种公知实现方式并各举一例。这一句是将来答复「得不到支持」审查意见时的核心弹药，缺失时宽概括几乎必被收窄；有了它，答复时可以直接援引指南的例外情形据理力争。

示例：反例与改法

边界与例外

• 本领域技术人员能明了该功能还可采用说明书中未提到的其他替代方式完成的，可以允许较宽的概括

常见误区

• 权项只写功能，挖掉功能词后剩不下任何结构。
• 说明书一种实现方式，权项概括到整个功能域，且无公知替代方式佐证。
• 把「能够提高……效率」这类效果句当独立特征写进独权。
• 装置权项全部写成「用于实现权利要求 N 所述方法的装置」。
• 程序模块只给模块名与功能句，说明书无对应流程与算法。
• 误以为功能性限定天生合法，撰写时未核对实施例密度。
• 功能特征的支持缺陷与清楚问题并发时，只改了概括没改表述。

提交前检查清单

• 每个功能性限定在说明书中是否至少有一种具体实现方式？
• 实现方式只有一种时，本领域技术人员是否仍能明了存在其他替代方式？
• 功能概括是否覆盖了说明书未公开、且无公知性佐证的实现方式？
• 是否存在挖掉功能词后剩不下任何结构的结果限定句？
• 程序模块类特征在说明书中是否有流程、输入输出或算法描述？
• 通用功能件的宽概括是否在说明书里留了存在多种公知实现的说明？
• 有没有理由怀疑概括中的某些方式达不到说明书声明的技术效果？

相关规则

• 权利要求应当以说明书为依据DR-CLM-014
• 含算法特征案件的说明书撰写DR-DOM-002

本页为撰写方法说明，不构成法律意见。具体案件的撰写与答复请咨询专利代理师。