Claim Drafting / English Article
A Simple Guide to Patent Claim Drafting
A practical explanation of claim drafting logic, centered on technical features and defensible scope.
Claims Are the Legal Shape of Technical Control
A patent claim is not a literary description of an invention. It is the legal boundary of technical control. Good claim drafting begins with one question: what technical features must a competitor use if it wants to obtain the same technical effect?
Many weak claims fail because they describe products too specifically. They include unnecessary materials, dimensions, connection forms, or implementation details. The result is easy to avoid. A strong claim captures the essential technical relationship without being unsupported or vague.
Claims Are the Legal Shape of Technical Control: practical detail
For inventors, patent drafters, and business teams reviewing claim quality, this point should be treated as a working step rather than a slogan. The practical work is to connect the article's idea with technical-problem identification, essential-feature extraction, independent-claim construction, fallback hierarchy, and infringement-avoidance testing. That is what turns a general insight into a repeatable professional service.
The team should record concrete evidence: embodiments, alternative features, technical effects, competitor design-around possibilities, support in the specification, and examiner comparison logic. Without this evidence layer, the method remains only an opinion. With it, the article becomes useful for client communication, internal decision-making, patent drafting, prosecution strategy, and later portfolio review.
A complete application of this section normally ends with a decision: how broad the independent claim can be while still staying supported, clear, defensible, and useful against real competitors. Ma Su's examiner background matters here because the decision is not based only on enthusiasm; it is tested against technical contribution, support in the disclosure, likely examination reasoning, and business value.
Start from the Technical Problem
Before drafting, identify the technical problem and the feature combination that solves it. Do not start by copying the embodiment. Start by asking which elements are essential, which elements are optional, and which alternatives can perform the same function.
This is where patent-map thinking helps. If multiple technical means can solve the same problem, the claim should not accidentally limit itself to only one means unless the specification cannot support broader language.
Start from the Technical Problem: practical detail
For inventors, patent drafters, and business teams reviewing claim quality, this point should be treated as a working step rather than a slogan. The practical work is to connect the article's idea with technical-problem identification, essential-feature extraction, independent-claim construction, fallback hierarchy, and infringement-avoidance testing. That is what turns a general insight into a repeatable professional service.
The team should record concrete evidence: embodiments, alternative features, technical effects, competitor design-around possibilities, support in the specification, and examiner comparison logic. Without this evidence layer, the method remains only an opinion. With it, the article becomes useful for client communication, internal decision-making, patent drafting, prosecution strategy, and later portfolio review.
A complete application of this section normally ends with a decision: how broad the independent claim can be while still staying supported, clear, defensible, and useful against real competitors. Ma Su's examiner background matters here because the decision is not based only on enthusiasm; it is tested against technical contribution, support in the disclosure, likely examination reasoning, and business value.
Build Claim Layers
A claim set should have layers. The independent claim protects the core technical contribution. Dependent claims protect preferred structures, materials, parameters, control logic, manufacturing steps, and application scenarios. These layers provide fallback positions during examination and enforcement.
A good dependent claim is not filler. It should either strengthen grant probability, protect a commercial embodiment, block a competitor's design-around route, or preserve a useful technical effect.
Build Claim Layers: practical detail
For inventors, patent drafters, and business teams reviewing claim quality, this point should be treated as a working step rather than a slogan. The practical work is to connect the article's idea with technical-problem identification, essential-feature extraction, independent-claim construction, fallback hierarchy, and infringement-avoidance testing. That is what turns a general insight into a repeatable professional service.
The team should record concrete evidence: embodiments, alternative features, technical effects, competitor design-around possibilities, support in the specification, and examiner comparison logic. Without this evidence layer, the method remains only an opinion. With it, the article becomes useful for client communication, internal decision-making, patent drafting, prosecution strategy, and later portfolio review.
A complete application of this section normally ends with a decision: how broad the independent claim can be while still staying supported, clear, defensible, and useful against real competitors. Ma Su's examiner background matters here because the decision is not based only on enthusiasm; it is tested against technical contribution, support in the disclosure, likely examination reasoning, and business value.
Avoid Three Common Mistakes
The first mistake is writing only from the inventor's prototype. The prototype is evidence, not necessarily the best legal boundary. The second mistake is using broad functional language without support. Breadth must be earned by disclosure. The third mistake is ignoring the examiner's future comparison. A claim should be drafted with likely prior art and inventive-step arguments in mind.
Good claim drafting is therefore not the final writing step. It is an analytical process: decompose, abstract, compare, layer, and defend.
Avoid Three Common Mistakes: practical detail
For inventors, patent drafters, and business teams reviewing claim quality, this point should be treated as a working step rather than a slogan. The practical work is to connect the article's idea with technical-problem identification, essential-feature extraction, independent-claim construction, fallback hierarchy, and infringement-avoidance testing. That is what turns a general insight into a repeatable professional service.
The team should record concrete evidence: embodiments, alternative features, technical effects, competitor design-around possibilities, support in the specification, and examiner comparison logic. Without this evidence layer, the method remains only an opinion. With it, the article becomes useful for client communication, internal decision-making, patent drafting, prosecution strategy, and later portfolio review.
A complete application of this section normally ends with a decision: how broad the independent claim can be while still staying supported, clear, defensible, and useful against real competitors. Ma Su's examiner background matters here because the decision is not based only on enthusiasm; it is tested against technical contribution, support in the disclosure, likely examination reasoning, and business value.
Original Chinese Essay
大道至简----最牛的专利撰写指南(权利要求篇)
撰写权利要求,别当“冥想者”:一套让思路瞬间清晰的“黑盒子”拆解法
入行这些年,我发现一个很有意思的现象:很多新手(甚至一些老手)拿到技术交底书后的第一反应,是盯着案子“冥想”。
他们对着文字反复看,试图在脑子里把整个技术方案“想明白”。结果往往是越想越乱,越想越不知道从哪里下笔,半天过去了,文档还是空的。
其实,写专利忌讳的就是“冥想”。你不是在搞艺术创作,灵感枯竭了可以等。你是在做一份技术翻译和法律文书撰写工作,需要的是清晰、高效的拆解逻辑。
今天,我就把我自己用了多年的“黑盒子”拆解法分享出来。这套方法的核心就是一句话:拿到一个再复杂的方案,也别想着一次把它全吞下去,而是把它拆成几个能一口吃掉的“黑盒子”。
第一步:定总纲——搞清楚这东西到底是干啥的
不管你拿到的是一个复杂的机械结构,还是一套抽象的软件算法,第一步永远只有一个:搞清楚这个方案是干啥的,它要解决什么整体技术问题,要达到什么技术效果。
这一步不是为了写具体细节,而是为了提炼出你独立权利要求的第一句话。
举个例子,假如你拿到一个方案,描述了一种新型的“智能垃圾桶”,里面有传感器、有控制板、有电动翻盖机构、还有压缩装置……乱七八糟一大堆。
你别一头扎进那些传感器型号和电机功率里。你要跳出来,问自己最核心的问题:这东西到底是干啥的?
答案可能是:“为了解决垃圾桶满了没人倒、垃圾溢出有异味的问题,提供一种能自动感应满溢并自动压缩垃圾的垃圾桶。”
好,你的独立权利要求1的第一句话就可以写出来了:
“一种智能垃圾桶,其特征在于,包括:……”
这句话的主体“一种智能垃圾桶”,就是你整个权利要求的“锚”。后面所有的一切,都要围着它转,为解决“自动感应满溢并自动压缩垃圾”这个整体技术问题服务。
这一步的要诀是: 哪怕方案有10页纸,你也要能用一句话概括出它最核心的发明点。如果概括不出来,说明你自己还没看懂,千万别下笔。
第二步:切模块——把方案扔进几个“黑盒子”
总纲定好了,接下来就是把整个方案按照功能,切分成几个最基础的“黑盒子”。这一步是核心,而且你会发现,拆分的套路其实非常固定,跨领域也适用。
比如对于硬件类方案,你几乎总能拆出这几块:
· 动力源部分:谁提供能量?比如电机、气缸、液压泵。
· 传动部分:能量/运动怎么传递?比如齿轮组、连杆机构、传送带。
· 执行部分:最终干活的是谁?比如切割刀、搅拌头、夹爪。
比如对于软件/电学类方案,你也可以按数据流来拆:
· 数据获取部分:数据从哪来?比如传感器、输入接口。
· 数据处理部分:核心计算在哪里?比如CPU、MCU、算法模块。
· 数据存储部分:结果放哪里?比如内存、数据库。
· 输入输出部分:怎么和人交互?比如显示屏、按键。
· 供电部分:电从哪来?比如电源模块。
怎么做?
你现在就可以给上述的每个部分临时命个名字,比如“动力组件”、“传动组件”、“执行组件”。
这个命名过程,其实就是在划定你独立权利要求的特征部分。你不需要去管这个“动力组件”里面具体是啥型号的电机、怎么安装的,你只需要知道,整个方案里有这么个“黑盒子”,它的功能是“提供动力”。
于是,你的独立权利要求就基本成型了:
一种智能垃圾桶,其特征在于,包括:
检测组件,用于检测桶内垃圾的堆积高度;
控制组件,与所述检测组件连接,用于接收检测信号并根据预设阈值发出指令;
压缩组件,与所述控制组件连接,用于在接收到所述指令后对桶内垃圾进行压缩。
看到了吗?你甚至不需要知道“检测组件”是红外线还是超声波,你只需要明确它有这个功能就行。
第三步:连关系——给“黑盒子”们接线
光把黑盒子列出来还不够,你得告诉别人它们之间是怎么“协作”的。这一步就是加“连接关系”。
对于简单的关系,直接说:
· “所述A部分与B部分电连接。”
· “所述A部分与B部分通讯连接。”
· “所述A部分与B部分固定连接。”
但如果它们之间的关系比较复杂,比如不是简单的电线连接,而是一种功能上的传递,这时候就可以祭出我们这行的“万金油”描述方式——功能性描述。
这种描述的句式是:“所述A部分用于……,以使得所述B部分能够……”
还是用垃圾桶的例子,检测组件和控制组件之间,不只是连了根线,它们的逻辑关系是:
“所述检测组件(A部分)用于检测垃圾高度并生成高度信号,并将所述高度信号发送至所述控制组件(B部分),以使得所述控制组件(B部分)根据所述高度信号判断是否达到压缩阈值。”
这样一来,即使两个黑盒子之间的连接方式很抽象(比如是通过无线信号、还是通过CAN总线),你用这种功能性的语言,就把它们的“业务关系”描述得清清楚楚,保护范围也足够大。
形象地说,这一步就是: 你把整个技术方案想象成一台由几个功能黑盒子组成的机器,你现在的任务,就是告诉审查员和公众,这些黑盒子是怎么“接线”的,信号是怎么流的,力是怎么传的。
第四步:拆盒子——从权就是把“黑盒子”打开
独立权利要求写到这里,你已经搭建了整个专利的“骨架”。接下来写从属权利要求,就是往这个骨架里填“血肉”。
从权的本质,就是把前面那些“黑盒子”一个个拿过来,打开它,看看里面到底装了什么。
如果盒子里面很简单,那就直接描述。比如你前面写了“压缩组件”,现在你打开这个盒子,发现它就是一个由电机驱动的丝杆螺母机构。那你就可以写:
“根据权利要求1所述的智能垃圾桶,其特征在于,所述压缩组件包括电机、与所述电机输出端连接的丝杆,以及螺纹连接在所述丝杆上的压板。”
如果盒子里面还是很复杂,比如这个“压缩组件”本身就是一个复杂的子系统,里面还有自己的动力、传动和执行部分。那怎么办?
别怕,再用一遍我们刚才的“黑盒子”拆解法!
你把这个“压缩组件”作为一个新的“整体”,然后对它进行二次拆解:
1. 它的子问题是什么?——在这个子系统里,它的任务是“把旋转运动变成直线运动”。
2. 它可以拆成几个功能部分?——可以拆成“旋转驱动部分”和“运动转换部分”。
3. 它们之间怎么连接?——当然是传动连接。
这样一来,你的从属权利要求也可以写得层层递进,逻辑清晰。
别再冥想了,开始拆解吧
这套“黑盒子”拆解法的精髓,其实就是一句话:把复杂问题简单化,把简单问题模块化,然后分层处理。
你不需要一开始就面面俱到,去纠结那个传感器是装在桶盖内侧还是外侧。你只需要先把大框架搭好,把核心的“黑盒子”定义清楚。等大框架稳了,再去一个个打开盒子,细化里面的内容。
当你再拿到一个复杂方案,感觉脑子一团浆糊的时候,不妨试试这个方法:
1. 定总纲:它到底想干啥?写下第一句话。
2. 切模块:把它按功能分成几个大黑盒子。
3. 连关系:给盒子之间“接线”。
4. 拆盒子:从权就是一个个打开盒子往里看。