/code2patent

发明专利起草速查卡

给 agent 用的短版规则卡。 只保留最容易写偏、但最影响 code2patent 输出质量的规则。

一、先看什么

进入起草层时，默认按这个顺序：

1. 04-方案代码证据映射-<方案名>.md
2. 05-技术交底书-<方案名>.md
3. references/algorithm-software-disclosure-format.md
4. 本速查卡
5. references/patent-drafting-spec.md
6. 再动笔写 05A / 05B / 06 / 06A

二、10 条硬规则

1. 算法/软件类交底书按说明书式结构写

• 默认主线是：技术领域、背景技术、发明内容、附图说明、具体实施方式。
• 发明内容内部要包含技术问题、总体方案、步骤 S1...Sn、进一步限定和技术效果。
• 具体实施方式要用示例场景展开输入、状态/数据表示、步骤、参数和输出。
• 对软件项目，默认按算法/软件类发明处理；不要退回到“系统模块说明书”。

2. 交底书不是代码盘点

• 代码证据映射可以列文件、函数、字段和状态。
• 技术交底书正文应讲技术问题、方案构思、实施步骤、具体实施方式和技术效果。
• 如果正文连续堆叠代码路径，应先转译为步骤 S1...Sn、技术特征、数据/状态流转、单元协同或证据附录。
• 如果输出主体变成“模块 A、模块 B、模块 C”，应回退重写为权利要求候选特征和具体实施方式。

3. 权利要求必须有说明书支撑

• 权利要求不能脱离说明书公开内容单独漂移。
• 如果说明书没写清，权利要求就不要先写大。

4. 独立权利要求只写必要技术特征

• 只保留“为解决技术问题所必需”的特征。
• 参数、优选条件、缓存、回退、异常处理等，通常先放从属权利要求或实施例。

5. 从属权利要求只写附加技术特征

• 不要重复独立权利要求已经写过的全部内容。
• 默认按三层挂接：步骤细化、参数/条件、实施细节。

6. 先稳 claim tree，再写完整初稿

• 先写 05A-权利要求布局卡
• 再写 05B-权利要求-证据矩阵
• 最后写 06-发明专利初稿

不要跳过 L2.5 直接硬写初稿。

7. 摘要只做压缩，不做营销

• 写名称、技术领域、技术问题、技术方案要点、主要用途。
• 控制在 300 字内。
• 不写宣传性表达，不写夸张效果。

8. 计算机程序相关发明要区分方法口径和产品口径

• 方法口径：写处理步骤。
• 产品口径：可按装置、计算机可读存储介质、计算机程序产品布局。
• 不要只写“某程序实现某功能”这种抽象功能描述。

9. A / B / C 级证据进入位置不同

• A 级：可进入独立权利要求骨架。
• B 级：优先进入从属权利要求或优选实施例，并标“基于实现归纳”。
• C 级：只能进待确认事项或替代实施例。

10. 第三方能力不直接写成申请人创新

• 模型、SDK、中间件、向量库、云服务的固有能力，不直接主张。
• 只主张本项目对其的组织、调度、适配、回退、缓存、状态管理等自研机制。

三、计算机程序相关发明的默认保护主题

默认先并行准备四类草稿，供代理师择优整合：

1. 方法
2. 系统 / 装置
3. 计算机可读存储介质
4. 计算机程序产品

注意：这里是内部布局草稿，不等于正式申请文件必须全部同时保留。

四、下笔前自问 9 个问题

1. 这份方案真正解决的技术问题是什么？
2. 交底书是否已经按算法/软件类说明书式结构组织？
3. S1...Sn 是否覆盖完整技术闭环，并在交底书、布局卡、证据矩阵和初稿中保持一致？
4. 交底书正文是否仍然像代码证据表？
5. 主独立权利要求里有没有混入“非必要特征”？
6. 是否把 B / C 级证据写实了？
7. 是否把第三方固有能力误写成了申请人创新？
8. 是否已把项目架构转译为技术对象、关系、状态、动作、时序和输出？
9. 是否把实现模块清单误当成了技术方案主线？

五、最常见的 5 个错误

1. 把代码证据映射直接改名为技术交底书，正文过度技术化。
2. 交底书没有技术领域、背景技术、发明内容、附图说明、具体实施方式这条主线。
3. 交底书、布局卡、证据矩阵和初稿中的步骤编号不一致。
4. 把工程优化细节全塞进独立权利要求，导致主权利要求过窄。
5. 把第三方平台能力直接当成申请人的核心创新。