通知书要点 → 审查员的核心观点与法条依据

通知书要点 → 审查员的核心观点与法条依据

【免费下载链接】patent-disclosure-skill中国专利.skill：专利点挖掘与交底书（发明/实用/外观）编写，通俗解读专利，嗅探政策动向，辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill

策略 → 答复路线的取舍

陈述要点 → 逐条论证

修改摘要 → 权利要求/说明书的改动

结果 → 案件结局

这套结构在 [oa_case.schema.yaml](https://link.gitcode.com/i/44a7a0afbdd7bda2ea33c9db3ffc8dd8) 的「笔记正文建议结构」中有明确约定，`chunk_case()` 会按标题关键词自动将每个小节分类为 `notice` / `strategy` / `argument` / `amendment` / `outcome` 类型的分块（chunk），供后续向量化与命中展示。 ## 二、通知书要点：审查员的创造性否定逻辑 > 审查员认为权利要求1相对于对比文件1与公知常识的结合不具备创造性：区别仅在于卡扣端部增加限位凸起，属于常规结构替换。 对照同一目录下待答复的 [oa_notice_pending.md](https://link.gitcode.com/i/1f616155d24901c4875ad70ede28346b)（一份虚构的第一次审查意见通知书），可以还原审查员完整的论证链： 1. 权利要求1请求保护一种**卡扣装配结构**，对比文件1（`CNXXXXXXXX01.A`，脱敏）公开了一种**弹性卡扣连接件**； 2. 权利要求1与对比文件1的区别仅在于：**卡扣端部还设置有限位凸起，且凸起一侧形成导向斜面**； 3. 审查员认定上述区别属于本领域解决**装配对中问题**的常规手段，因此权利要求1相对于对比文件1与公知常识的结合不具备创造性。 这是机械领域创造性审查意见的典型形态：审查员通常不会否认区别特征本身，而是将区别特征定性为「常规手段 / 常规结构替换」，从而否定技术贡献。答复的关键就在于**推翻「常规」这一定性**。 ## 三、策略设计：为什么选「修改 + 陈述」而非「纯陈述」 案例 frontmatter 中 `strategy: [amend_claims, argue_only]` 明确记录了双策略组合： > 保留独立权利要求主体；将说明书记载的「限位凸起 + 导向斜面」一并写入权利要求1；意见陈述强调二者配合解决装配偏斜卡滞。 对比清楚性案 `hist-clarity-connector` 的纯陈述策略（不修改权利要求、靠说明书实施例澄清含义），可以总结出策略选择的判断维度： - **纯意见陈述（argue_only）**：适用于权要本身含义清楚、缺陷源于解释分歧的场景，代价最小、不缩小保护范围，但需要足够有力的说明书支撑； - **修改权利要求（amend_claims）**：适用于区别特征被认定为常规手段、仅靠争辩难以翻盘的场景。通过将说明书记载的**附加技术特征**并入独立权利要求，主动缩小保护范围以换取授权前景； - **双策略组合（amend_claims + argue_only）**：本文案例的路径——修改不是目的，而是为了配合论证；陈述必须让审查员接受「并入的特征使技术方案整体产生了新效果」。 该案例的修改要点是：**保留独立权利要求主体**（不伤及整体方案框架），仅把说明书中的「限位凸起 + 导向斜面」整体写入权利要求1，属于典型的**从说明书补充特征到权要**的修改方式，修改依据清晰、不存在超范围风险。 ## 四、陈述要点：创造性答复的三段论 案例给出的陈述要点是答复草稿的核心骨架： 1. **对比文件1仅公开弹性卡扣，未公开限位凸起与导向斜面的组合**——先厘清技术事实，明确区别特征的客观存在，且区别是「组合」而非单个零件； 2. **二者功能相互支持，非简单叠加**——这是对抗「公知常识/常规替换」定性的关键论证：限位凸起与导向斜面不是各自独立起作用的零件堆叠，而是协同配合（凸起限位、斜面导向，共同解决装配偏斜卡滞问题）； 3. **修改特征来自原说明书**——为修改提供法律依据（示例中标注「待指认段落」，实际应用时须指向说明书具体段落/附图标记），证明修改未引入新内容、不超范围。 结合 [respond_office_action.md](https://link.gitcode.com/i/484a489b1555138eacc079fe949e6a02) 中「若建议修改：每处修改须指向说明书可支持位置（未知则标『待发明人指认段落』）」的约束，可以确认第 3 点正是该规则的案例化落地——示例中「（示例：待指认段落）」即为占位写法，真实答复中必须替换为可定位的说明书出处。 ### 4.1 修改摘要与结果 > 权利要求1增加「限位凸起与导向斜面配合」；说明书适应性修改。 修改摘要同时覆盖权利要求与说明书：权利要求1新增特征的同时，说明书要做适应性修改（保持前后一致，这也是专利审查的常规要求）。最终结果 `outcome: amended_then_granted`（修改后授权），意味着整套「修改 + 陈述」策略获得了审查员的认可。 ## 五、从案例到流水线：入库、检索与答复生成 历史案的价值在于**沉淀为可检索的知识资产**，这正是模式 D 的核心。下面把该案例放入 [examples/example_oa_response/README.md](https://link.gitcode.com/i/9f37f285380c28b09be0ed22dfa6ff98) 给出的冒烟测试全流程中走一遍。 ### 5.1 入库：ingest_case.py 做了什么 ```bash # 可选：跳过向量，只测标签 python tools/oa/config.py skip-vector # 入库历史案（需已确认配置；可 --dry-run 预检） python tools/oa/ingest_case.py -i examples/example_oa_response/cases/history/hist-inventiveness-clamp.md --skip-redact

执行ingest_case.py后，ingest_case.py 内部会依次完成：

1. 解析 frontmatter：parse_case_markdown()（见 case_md.py）用正则\A---\s*\n(.*?)\n---\s*\n?(.*)\Z切分出元数据与正文，YAML 反序列化得到meta；
2. 自动补标签：根据defect_types自动追加oa/{defect}标签，根据statutes自动追加法条/{statute}标签，保证标签体系的一致性（本案例的oa/inventiveness与法条/专利法第22条第3款即可由此自动生成）；
3. 脱敏（除非--skip-redact）：调用redact_text()处理正文与标题，并将redacted置为true；
4. 分块与向量化：chunk_case()按##标题切块并标注 chunk 类型，若配置启用了向量且status == history，则用 Embedder 生成向量；否则vector_mode标记为meta_only_*；
5. 写 Obsidian 笔记 + 写 sqlite：note_path_for()按status决定落盘目录（history 落在cases/history/），历史案通过upsert_case()写入 store.py 中的cases元数据表与vec_chunks向量表；
6. 刷新看板：refresh_oa_vault()重建_OA索引.md、_OA看板.base、_OA关联.canvas。

仓库提供--dry-run参数可预览入库效果而不落盘，适合入库前的安全性检查。

5.2 向量库与配置（可选能力）

向量检索是模式 D 的可选增强而非必需。仓库模板种子 embedding.config.yaml 展示了完整配置项：

运行时配置默认落在操作系统文档目录（可用PATENT_OA_HOME覆盖），仓库内文件仅作为模板种子。若不想接入在线 embedding，执行python tools/oa/config.py skip-vector即可纯标签运行——本案例的标签（oa/inventiveness、法条/专利法第22条第3款）足以支撑按缺陷类型与法条的精确过滤。

5.3 检索：新通知书如何召回本案例

当一份新的审查意见到来时，用search_cases.py检索历史案：

python tools/oa/search_cases.py \ --query-file examples/example_oa_response/pending/oa_notice_pending.md \ --defect inventiveness \ --statute "专利法第22条第3款" \ --top-k 3

执行流程（见 search_cases.py）：

1. 查询来源解析：--query-file读取待答复通知书 md；也可用--pdf直接喂通知书 PDF（自动抽取文本，禁止让用户手贴长文）；
2. 检索模式决策：若配置启用向量且索引可用 →vector模式（先按statutes/defect_types/patent_type等元数据过滤，再在候选集内做 sqlite-vec KNN 检索）；否则自动回退tags_only（纯标签过滤）；向量调用失败时进入tags_fallback并输出 WARN；
3. 结果附带差异信息：每个命中案例都带diff字段，展示查询与案例在domain/statutes/defect_types/patent_type/compare_refs/outcome上的对比，便于判断参考价值。

以本案例为例：待答复的oa_notice_pending.md同样涉及发明 + 专利法第22条第3款 + inventiveness + 机械结构 + 对比文件 CNXXXXXXXX01.A，与历史案特征高度吻合——这正是历史案被设计为related_cases: [hist-inventiveness-clamp]的用意：新通知书可以通过标签过滤精确命中同类历史案，直接参考其答复策略。

5.4 生成答复草稿的硬性约束

respond_office_action.md 规定了从检索到草稿的完整流程，其中与本文案例直接相关的约束：

• 先检索再生成：Agent 必须展示命中案例的case_id、可参考理由与差异，禁止无检索空写、禁止假装引用历史案；
• 逐条对应：草稿须逐条对应通知书条目编号；
• 修改必有出处：每处修改须指向说明书可支持位置，未知则标注「待发明人指认段落」——本案例陈述要点第 3 点的「示例：待指认段落」正是该约束的模板化体现；
• 人审闸门：生成后须用 guardrails.md 校验话术。

六、从案例提炼的可复用答复模板

综合本案例与模式 D 流水线，一份「区别特征被认定为常规手段」类创造性答复的可复用骨架如下：

## 通知书要点 审查员认为权利要求1相对于对比文件1与公知常识的结合不具备创造性： 区别仅在于{区别特征描述}，属于常规{领域}手段/结构替换。 ## 策略 {保留权要主体 / 从说明书并入附加特征}；意见陈述强调{特征组合}的协同效果。 ## 陈述要点 1. 对比文件1仅公开{基础结构}，未公开{区别特征组合}； 2. {特征A}与{特征B}功能相互支持，共同解决{技术问题}，非简单叠加； 3. 修改特征来自原说明书（{待指认段落/具体位置}）。 ## 修改摘要 权利要求{编号}增加「{并入特征描述}」；说明书适应性修改。 ## 结果 {修改后授权 / 意见陈述后授权 / 驳回……}

【免费下载链接】patent-disclosure-skill中国专利.skill：专利点挖掘与交底书（发明/实用/外观）编写，通俗解读专利，嗅探政策动向，辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill