wechat-robot-skills/skills/docx/references/patent/review-checklist.md

161 lines
7.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

本指南提供写作与审查方法。涉及具体申请法域、法定期限或法律效力时,核对当前主管机关资料,并标注来源;未完成检索时不作确定性结论。
# 专利申请文件审查清单
对已完成的专利申请文件进行系统化质量检查。审查结果按三个严重等级分类,帮助快速定位和优先处理关键问题。
---
## 问题严重等级
| 等级 | 含义 | 处理优先级 |
|---|---|---|
| **致命** | 直接导致驳回或权利范围严重缺陷,提交前必须修正 | 立即修正 |
| **重要** | 可能导致审查意见或减弱保护效果,强烈建议修正 | 优先修正 |
| **改进** | 不影响授权但可以提升文件质量,视时间精力决定 | 有余力时修正 |
审查时对发现的每个问题标注等级,修改时按"致命 → 重要 → 改进"的顺序处理。
---
## 一、权利要求书审查
### 1.1 清楚性检查
权利要求是否清楚地限定了保护范围?
| 检查项 | 等级 | 说明 |
|---|---|---|
| 有无模糊限定词 | 致命 | 检查是否含有"大约""基本上""适当地""近似"等词,除非给出了明确的判断标准 |
| 有无主观评价词 | 致命 | 检查是否含有"高效""优质""良好""最佳""足够"等无客观标准的词 |
| 有无相对性用语 | 重要 | 检查是否含有"较大""较小""较高""较低"等没有比较基准的词 |
| 技术特征是否具体 | 重要 | 每个技术特征是否有明确的技术含义,而非功能性的空泛描述 |
| 主题名称是否恰当 | 改进 | 主题名称是否准确反映了权利要求保护的技术方案 |
**模糊用语速查表**(以下词语在权利要求中出现时需要警惕):
> 大约、约、基本上、实质上、大致、近似、适当、合适、适宜、足够、必要时、可选地、优选、优选地、较好、较佳、等等、诸如、例如、高效、优秀、先进、良好、显著、明显
### 1.2 先行词一致性检查
"所述"引用是否都能找到先行词?
| 检查项 | 等级 | 说明 |
|---|---|---|
| 每个"所述XX"是否有先行词 | 致命 | 逐条检查:每个"所述"后面的术语,是否在前面的权利要求中用"一种/一个"引入过 |
| 术语是否全文一致 | 致命 | 同一技术特征在不同权利要求中名称是否完全一致,不能一处写"处理模块"另一处写"处理单元" |
| 首次引入是否用"一种/一个" | 重要 | 每个技术特征的首次出现是否使用了正确的引入格式 |
**检查方法**:对每条权利要求,提取所有"所述XX"的引用,在该条权利要求及其引用链上逐一查找对应的引入。
### 1.3 权利要求结构检查
权利要求体系的结构是否合理?
| 检查项 | 等级 | 说明 |
|---|---|---|
| 独权是否只含必要技术特征 | 重要 | 独权中有没有可以移到从权中的非必要特征?独权特征过多导致保护范围过窄 |
| 从权引用关系是否正确 | 致命 | 从权引用的编号是否指向正确的权利要求?引用链是否逻辑自洽? |
| 从权是否每条只限定一个维度 | 重要 | 一条从权中是否同时限定了两个不相关的特征? |
| 多引权利要求是否被再次多引 | 致命 | 多引的从权不能再被多引 |
| 方法权利要求与装置权利要求是否对应 | 重要 | 方法步骤与装置模块是否一一对应? |
| 权利要求总数是否合理 | 改进 | 通常10-25条为宜 |
### 1.4 保护范围检查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 独权保护范围是否足够宽 | 重要 | 有没有不必要的限定缩小了保护范围? |
| 从权是否覆盖了主要变体 | 重要 | 核心技术特征的替代实现方式是否有从权覆盖? |
| 是否有多种类型的权利要求 | 改进 | 是否同时包含方法和装置权利要求?软件类是否包含存储介质权利要求? |
---
## 二、说明书审查
### 2.1 充分公开检查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 权利要求中的每个特征是否都有描述 | 致命 | 逐条比对:权利要求中的每个技术特征,在说明书中是否都有对应的详细描述? |
| 关键步骤是否有具体实现方式 | 致命 | 有没有"黑箱"——只说了做什么,没说怎么做? |
| 关键参数是否给出 | 重要 | 涉及阈值、比例、范围等参数时,有没有给出具体值或选择依据? |
| 本领域技术人员能否实现 | 重要 | 整体判断:读完说明书后,一个有经验的工程师能否不做创造性劳动就实现发明? |
### 2.2 支持性检查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 独权的方案在"发明内容"中是否有概述 | 重要 | "发明内容"部分的技术方案描述是否覆盖了独权的核心内容 |
| 从权的附加特征在实施例中是否有体现 | 重要 | 每条从权的附加特征是否在至少一个实施例中有详细描述 |
| 上位概念是否有下位支撑 | 重要 | 独权中使用了上位概念(如"分类模型")时,说明书中是否给出了具体的下位实例(如"SVM、随机森林、神经网络") |
### 2.3 结构完整性检查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 五大部分是否齐全 | 致命 | 技术领域、背景技术、发明内容、附图说明、具体实施方式 |
| 技术问题→方案→效果逻辑链是否完整 | 重要 | 背景技术中的不足 → 发明内容中的方案 → 技术效果,三者是否环环相扣 |
| 附图说明与实施方式中的引用是否一致 | 重要 | 附图说明中列出的每幅图,在具体实施方式中是否都有引用?反过来也要检查 |
### 2.4 术语一致性检查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 说明书与权利要求书术语是否一致 | 致命 | 同一技术特征在两份文件中是否使用完全相同的术语 |
| 说明书内部术语是否一致 | 重要 | 同一概念在说明书不同部分是否使用了同一名称 |
| 附图标记是否一致 | 改进 | 同一组件的附图标记在全文中是否统一 |
---
## 三、摘要审查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 字数是否合规 | 重要 | 通常控制在300字以内 |
| 是否涵盖三要素 | 重要 | 技术问题(或技术领域)+ 技术方案要点 + 主要用途或效果 |
| 是否独立可读 | 改进 | 不依赖说明书,单独阅读摘要能否理解发明概要 |
| 是否含有不当内容 | 改进 | 摘要中不应有商业宣传性语言 |
---
## 四、形式审查
| 检查项 | 等级 | 说明 |
|---|---|---|
| 权利要求编号是否连续 | 致命 | 从1开始连续编号,不跳号 |
| 从权引用编号是否存在 | 致命 | 引用的权利要求编号指向的条目是否真实存在 |
| 附图编号是否连续 | 重要 | 图1、图2、图3...不跳号 |
| 说明书各部分标题是否规范 | 改进 | 使用标准的部分标题名称 |
---
## 审查输出格式
审查完成后,按以下格式输出审查报告:
```
## 审查报告
### 致命问题(X项)
1. [位置] 问题描述 → 建议修改方案
2. ...
### 重要问题(X项)
1. [位置] 问题描述 → 建议修改方案
2. ...
### 改进建议(X项)
1. [位置] 问题描述 → 建议修改方案
2. ...
### 总体评价
[对文件整体质量的简要评价,以及建议的修改优先级]
```
其中"位置"标注为:权利要求X / 说明书-技术领域 / 说明书-背景技术 / 说明书-发明内容 / 说明书-具体实施方式 / 摘要 等。
如果用户要求,在给出审查报告后可以直接输出修改后的完整文件。
如果用户提供了 DOCX,先读取结构,再用 `scripts/edit_document.py` 回填。需要修订标记的文本替换添加 `--track-changes --author <作者>`;操作结构、已有修订限制和校验流程见 `references/word-operations.md`。