专利清楚性审查意见答复实战从「连接器接口」历史案看仅意见陈述策略与模式 D 案例库落地【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill导读本文围绕仓库中一份脱敏历史案笔记 hist-clarity-connector.md 展开完整还原一次「权利要求清楚性专利法第26条第4款」审查意见的答复全过程审查员质疑「可适配接口」含义不清答复方不修改权利要求、仅以意见陈述结合说明书实施例与附图标记说理最终顺利授权。文章既剖析清楚性缺陷的说理结构也结合patent-disclosure-skill仓库模式 D审查答复的完整工具链讲解如何把这类历史案沉淀为可检索的 OA 案例笔记并在后续答复时通过标签过滤与可选向量检索实现先检索、再生成、有据可依的答复流程。一、历史案笔记全景一份可入库的「清楚性答复」样本hist-clarity-connector.md是模式 D 演练材料中的一份已结案历史案其 frontmatter 完整记录了检索所需的全部结构化元数据字段取值业务含义case_idhist-clarity-connector稳定标识作为 Obsidian 笔记文件名与检索主键statushistory已结案、可进入标签/向量检索库patent_typeinvention发明专利申请statutes专利法第26条第4款本案涉及的法条权利要求清楚性defect_typesclarity缺陷类型清楚性domain电子连接技术领域短标签notice_kindoffice_action通知书类型审查意见通知书outcomegranted结案结果授权strategyargue_only答复策略仅意见陈述不修改权利要求compare_refs[]无对比文件清楚性缺陷通常不涉及对比文件redactedtrue已脱敏正文采用「通知书要点 → 策略 → 陈述要点 → 修改摘要 → 结果」的五段式结构这与 references/schemas/oa_case.schema.yaml 中建议的案例笔记正文结构完全对齐。这种frontmatter 元数据 结构化正文的形态正是入库与检索的契约基础解析器按 frontmatter 提取元数据建索引按## 小节切分正文供向量化。配套的示例还包括同目录的创造性案 hist-inventiveness-clamp.md修改权利要求 意见陈述结果修改后授权以及待答复通知书 oa_notice_pending.md三者共同构成模式 D 的冒烟测试样本集详见 examples/example_oa_response/README.md。二、通知书要点清楚性缺陷的典型形态本案的争议焦点非常典型审查员认为权利要求1中「可适配接口」含义不清楚导致保护范围无法确定。所谓清楚性缺陷对应defect_types: clarity指的是权利要求的表述存在歧义或缺乏明确的技术含义使得本领域技术人员无法确定其要求保护的范围。这类缺陷在实践中的常见触发点包括使用含义模糊的自造词或功能化描述本案的「可适配接口」即属此类审查员质疑可适配指向何种结构权利要求中的术语在说明书与附图中缺乏对应限定特征之间的逻辑关系、边界条件交代不清。值得注意的是本案并不涉及对比文件与新颖性/创造性比对compare_refs为空也无需引入法条之外的技术事实因此答复的核心落在让权利要求中的表述在说明书与附图的支撑下变得清楚这一件事上。三、策略选择为什么选择「仅意见陈述」而非修改权利要求strategy: argue_only是本案例的核心策略信号。模式 D 的策略选项体系见 prompts/oa/respond_office_action.md至少给出四类仅意见陈述argue_only不改动权利要求通过说理消除审查员疑虑修改权利要求amend_claims将说明书记载的特征并入权利要求修改说明书amend_spec适应性修改说明书补正形式correction形式缺陷的补正。本案选择仅意见陈述的判断依据在陈述要点中隐含三点「可适配接口」并非缺乏支持而是审查员对术语语义存疑说明书已给出结构限定与附图标记的对应关系存在可引用的实施例基础清楚性缺陷尚未上升为得不到说明书支持support或公开不充分disclosure无需以缩小保护范围为代价换取授权。对比同目录创造性案hist-inventiveness-clamp.md的strategy: [amend_claims, argue_only]可以看到策略选择的差异逻辑创造性缺陷面对对比文件时往往需要通过修改权利要求建立区别技术特征而清楚性缺陷如果说明书足以澄清则优先保持权利要求文本不变避免不必要的保护范围收缩。四、陈述要点拆解三层递进的说理结构原笔记的陈述要点是三句话但其背后是一套可复用的三层递进说理结构1. 说明书已给出结构限定与附图标记对应关系第一层是事实锚定指出说明书实施例中已经写明「可适配接口」指具备限位凹槽与弹性触点的插接结构并指向附图标记。这等于告诉审查员——该术语在申请文件中不是无源之水而是有明确、具体的结构载体且存在附图标记可供核对。2. 本领域技术人员结合实施例可以清楚理解第二层是主体标准清楚性判断的主体是本领域技术人员而该主体在阅读说明书实施例后能够毫无疑义地确定「可适配接口」的技术含义。这一层把争论从字面歧义拉回整体理解的法定判断框架。3. 无需为清楚性单独缩小范围第三层是后果声明既然含义可确定、保护范围可界定就没有必要通过删除或限缩「可适配接口」相关特征来回应清楚性质疑修改反而可能不当缩小保护范围或引入新的超范围风险。这三点层层递进恰好回应了清楚性缺陷 含义不清楚导致保护范围无法确定的两要素先证含义可确定第1、2点再证范围无需变动第3点。五、修改摘要与结果零修改授权的价值信号修改摘要无修改。结果意见陈述后授权outcome: granted。对于 OA 案例库而言仅意见陈述 授权的组合是一个高价值的检索信号它意味着面对同类型清楚性质疑时存在一条不牺牲权利要求文本的可行路径。这类案例入库后被检索命中时能够直接为答复草稿提供论证框架与话术参考这正是模式 D 建设历史案库的初衷——让每一次授权案例都变成下一次答复的弹药。六、案例在模式 D 中的定位与落地路径6.1 目录布局与入库契约模式 D 采用方案 CObsidian 优先的目录布局由 tools/oa/vault_layout.py 中的STATUS_HISTORY / STATUS_PENDING / STATUS_DRAFT与status_subdir()决定落盘位置状态status目录是否进入检索库history默认{vault}/oa/cases/history/{case_id}.md是标签 可选向量pending{vault}/oa/pending/{case_id}.md否仅 Obsidian 笔记draft{vault}/oa/drafts/{case_id}.md否仅 Obsidian 笔记入库后还会在 OA 库根自动生成_OA索引.md、_OA看板.base、_OA关联.canvas。frontmatter 字段的完整取值域patent_type的三种类型、notice_kind的四种通知书种类、outcome的六种结果、strategy的多种策略、defect_types的七种缺陷均可参考 references/schemas/oa_case.schema.yaml。6.2 硬性规则脱敏与状态闸门案例入库前必须脱敏客户名、具体未公开参数等并置redacted: true。仓库在 tools/oa/redact.py 中提供规则型脱敏自动将公司名替换为「申请人甲」、11 位手机号替换为「【电话已脱敏】」、913 位申请号替换为CNXXXXXXXXXX.X、邮箱与身份证号分别掩码同时返回变更摘要供人审。ingest_case.py的--skip-redact与--extra-name参数分别用于跳过脱敏演练场景与追加自定义脱敏姓名。本案例的申请号、对比文件均已占位化CNXXXXXXXX01.A正是该规则的产物。6.3 入库实操命令按 examples/example_oa_response/README.md 的冒烟流程本案例可直接入库# 可选跳过向量模型仅用标签检索向量是可选项不是必须项 python tools/oa/config.py skip-vector # 入库历史案演练场景加 --skip-redact正式使用务必脱敏 python tools/oa/ingest_case.py \ -i examples/example_oa_response/cases/history/hist-clarity-connector.md \ --skip-redact # 刷新 Obsidian 索引 / Canvas / Bases python tools/oa/refresh_vault.pyingest_case.py还支持直接从通知书 PDF 起草案例--pdf notice.pdf会自动抽取文本生成带 frontmatter 的草稿--draft-only只出草稿供人审补标签--reply-pdf可附带答复 PDF。入库时tools/oa/case_md.py 的parse_case_markdown负责解析 frontmatterchunk_case按## 小节将正文切分为header / notice / strategy / argument / amendment / outcome等类型的分块——像本案的「通知书要点」「策略」「陈述要点」「修改摘要」「结果」各小节都会生成独立 chunk 供向量检索。只有status: history的案例才写入 sqlite 检索库pending / draft只落 Obsidian 笔记这一状态闸门在ingest_one()中有明确实现。6.4 检索实操让历史案在答复时被想起来模式 D 的核心铁律是「先检索再生成不得无检索空写」。待答复通知书可直接作为查询输入python tools/oa/search_cases.py \ --query-file examples/example_oa_response/pending/oa_notice_pending.md \ --defect inventiveness \ --statute 专利法第22条第3款 \ --top-k 3search_cases.py支持--pdf通知书 PDF 自动抽取、--query直接文本、--query-filemd/txt三种查询来源以及--patent-type、--statute、--defect、--tag、--domain等元数据过滤条件。检索时先按statutes / defect_types / patent_type过滤再决定是否做向量 Top-K向量不可用或未开启时自动回退纯标签检索retrieval_mode会标注vector / tags_only / tags_fallback。每条命中都会附带diff字段法条、缺陷、领域、对比文件等的逐项对比生成答复时须引用命中案例的case_id、说明为何可参考并展示差异。若要检索本案这类清楚性案例例如面对一份同样质疑权利要求用语不清楚的新通知书可执行python tools/oa/search_cases.py --pdf new_office_action.pdf \ --patent-type invention \ --statute 专利法第26条第4款 \ --defect clarity \ --top-k 5七、源码级原理历史案如何从笔记变成可引用的弹药7.1 元数据始终可用向量只是增强tools/oa/store.py 的设计原则是「元数据始终可用向量sqlite-vec可选」cases表持久化 frontmatter 全字段statutes_json / defect_types_json / tags_json / strategy_json等即使未安装 sqlite-vec也能通过search_by_tags()做精确过滤vec_chunks虚拟表仅当启用向量模型时构建。search()的完整链路是元数据过滤 → 候选集内 KNNk max(limit_candidates, top_k)默认候选上限 50→ 按 chunk 距离排序并去重同一案例 → 组装命中。整个流程在 tests/oa/test_oa_store.py 中有对应单测覆盖StoreVecTests.test_upsert_and_search与TagOnlySearchTests。7.2 标签自动补全与索引联动ingest_case.py入库时会自动为defect_types生成oa/{defect}标签、为statutes生成法条/{statute}标签enrich_case_note()还会追加oa/status/{status}与oa/case并在正文补导航、关联案、对比文件节对比文件若有已建解读笔记则自动链接到Research/Patents下的笔记。本案例tags中的oa/clarity与法条/专利法第26条第4款正是这一自动化的产物也是后续按标签检索的关键入口。刷新时refresh_oa_vault()还会重写_OA索引.md按状态分组的案例清单、_OA看板.baseBases 表格视图与_OA关联.canvas按同法条/同缺陷/同领域/显式关联/同对比文件自动计算连线使整个案例库在 Obsidian 中可视化。7.3 向量模型可选回退永不中断tools/oa/config.py 内置zhipu / dashscope / openai / minimax / local五套 preset 与skip-vector仅标签检索工作流。check_rebuild_needed()通过provider|model|dimensions|base_url四元组指纹检测首次启用或模型变更并提示重建索引。即便向量自检失败tools/oa/README.md 与 prompts/oa/respond_office_action.md 都明确要求向量超时/失败不得中断用标签结果继续生成草稿——这正是本案这类纯标签可命中的案例被设计为可独立检索的原因。八、清楚性答复的可复用方法论综合本案与模式 D 的约束详见 prompts/oa/respond_office_action.md 与 SKILL.md 模式 D面对权利要求清楚性质疑时可复用以下检查清单术语溯源被质疑的用语如「可适配接口」是否在说明书中有结构限定与附图标记对应关系若有优先仅意见陈述。实施例支撑本领域技术人员结合实施例能否毫无疑义确定其含义把判断主体落到本领域技术人员。范围评估是否需要修改若修改每处修改必须指向说明书可支持位置若无必要明确声明不改动以保持保护范围。检索先行答复前用search_cases.py检索同法条专利法第26条第4款、同缺陷clarity的历史案引用命中案例并展示差异杜绝无检索空写。沉淀反哺授权后的答复案例按本笔记的 frontmatter 五段式结构归档至oa/cases/history/标注strategy: argue_only与outcome: granted让仅陈述即授权的路径成为下次答复可检索、可引用的资产。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 专利清楚性审查意见答复实战：从「连接器接口」历史案看仅意见陈述策略与模式 D 案例库落地
专利清楚性审查意见答复实战从「连接器接口」历史案看仅意见陈述策略与模式 D 案例库落地【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill导读本文围绕仓库中一份脱敏历史案笔记 hist-clarity-connector.md 展开完整还原一次「权利要求清楚性专利法第26条第4款」审查意见的答复全过程审查员质疑「可适配接口」含义不清答复方不修改权利要求、仅以意见陈述结合说明书实施例与附图标记说理最终顺利授权。文章既剖析清楚性缺陷的说理结构也结合patent-disclosure-skill仓库模式 D审查答复的完整工具链讲解如何把这类历史案沉淀为可检索的 OA 案例笔记并在后续答复时通过标签过滤与可选向量检索实现先检索、再生成、有据可依的答复流程。一、历史案笔记全景一份可入库的「清楚性答复」样本hist-clarity-connector.md是模式 D 演练材料中的一份已结案历史案其 frontmatter 完整记录了检索所需的全部结构化元数据字段取值业务含义case_idhist-clarity-connector稳定标识作为 Obsidian 笔记文件名与检索主键statushistory已结案、可进入标签/向量检索库patent_typeinvention发明专利申请statutes专利法第26条第4款本案涉及的法条权利要求清楚性defect_typesclarity缺陷类型清楚性domain电子连接技术领域短标签notice_kindoffice_action通知书类型审查意见通知书outcomegranted结案结果授权strategyargue_only答复策略仅意见陈述不修改权利要求compare_refs[]无对比文件清楚性缺陷通常不涉及对比文件redactedtrue已脱敏正文采用「通知书要点 → 策略 → 陈述要点 → 修改摘要 → 结果」的五段式结构这与 references/schemas/oa_case.schema.yaml 中建议的案例笔记正文结构完全对齐。这种frontmatter 元数据 结构化正文的形态正是入库与检索的契约基础解析器按 frontmatter 提取元数据建索引按## 小节切分正文供向量化。配套的示例还包括同目录的创造性案 hist-inventiveness-clamp.md修改权利要求 意见陈述结果修改后授权以及待答复通知书 oa_notice_pending.md三者共同构成模式 D 的冒烟测试样本集详见 examples/example_oa_response/README.md。二、通知书要点清楚性缺陷的典型形态本案的争议焦点非常典型审查员认为权利要求1中「可适配接口」含义不清楚导致保护范围无法确定。所谓清楚性缺陷对应defect_types: clarity指的是权利要求的表述存在歧义或缺乏明确的技术含义使得本领域技术人员无法确定其要求保护的范围。这类缺陷在实践中的常见触发点包括使用含义模糊的自造词或功能化描述本案的「可适配接口」即属此类审查员质疑可适配指向何种结构权利要求中的术语在说明书与附图中缺乏对应限定特征之间的逻辑关系、边界条件交代不清。值得注意的是本案并不涉及对比文件与新颖性/创造性比对compare_refs为空也无需引入法条之外的技术事实因此答复的核心落在让权利要求中的表述在说明书与附图的支撑下变得清楚这一件事上。三、策略选择为什么选择「仅意见陈述」而非修改权利要求strategy: argue_only是本案例的核心策略信号。模式 D 的策略选项体系见 prompts/oa/respond_office_action.md至少给出四类仅意见陈述argue_only不改动权利要求通过说理消除审查员疑虑修改权利要求amend_claims将说明书记载的特征并入权利要求修改说明书amend_spec适应性修改说明书补正形式correction形式缺陷的补正。本案选择仅意见陈述的判断依据在陈述要点中隐含三点「可适配接口」并非缺乏支持而是审查员对术语语义存疑说明书已给出结构限定与附图标记的对应关系存在可引用的实施例基础清楚性缺陷尚未上升为得不到说明书支持support或公开不充分disclosure无需以缩小保护范围为代价换取授权。对比同目录创造性案hist-inventiveness-clamp.md的strategy: [amend_claims, argue_only]可以看到策略选择的差异逻辑创造性缺陷面对对比文件时往往需要通过修改权利要求建立区别技术特征而清楚性缺陷如果说明书足以澄清则优先保持权利要求文本不变避免不必要的保护范围收缩。四、陈述要点拆解三层递进的说理结构原笔记的陈述要点是三句话但其背后是一套可复用的三层递进说理结构1. 说明书已给出结构限定与附图标记对应关系第一层是事实锚定指出说明书实施例中已经写明「可适配接口」指具备限位凹槽与弹性触点的插接结构并指向附图标记。这等于告诉审查员——该术语在申请文件中不是无源之水而是有明确、具体的结构载体且存在附图标记可供核对。2. 本领域技术人员结合实施例可以清楚理解第二层是主体标准清楚性判断的主体是本领域技术人员而该主体在阅读说明书实施例后能够毫无疑义地确定「可适配接口」的技术含义。这一层把争论从字面歧义拉回整体理解的法定判断框架。3. 无需为清楚性单独缩小范围第三层是后果声明既然含义可确定、保护范围可界定就没有必要通过删除或限缩「可适配接口」相关特征来回应清楚性质疑修改反而可能不当缩小保护范围或引入新的超范围风险。这三点层层递进恰好回应了清楚性缺陷 含义不清楚导致保护范围无法确定的两要素先证含义可确定第1、2点再证范围无需变动第3点。五、修改摘要与结果零修改授权的价值信号修改摘要无修改。结果意见陈述后授权outcome: granted。对于 OA 案例库而言仅意见陈述 授权的组合是一个高价值的检索信号它意味着面对同类型清楚性质疑时存在一条不牺牲权利要求文本的可行路径。这类案例入库后被检索命中时能够直接为答复草稿提供论证框架与话术参考这正是模式 D 建设历史案库的初衷——让每一次授权案例都变成下一次答复的弹药。六、案例在模式 D 中的定位与落地路径6.1 目录布局与入库契约模式 D 采用方案 CObsidian 优先的目录布局由 tools/oa/vault_layout.py 中的STATUS_HISTORY / STATUS_PENDING / STATUS_DRAFT与status_subdir()决定落盘位置状态status目录是否进入检索库history默认{vault}/oa/cases/history/{case_id}.md是标签 可选向量pending{vault}/oa/pending/{case_id}.md否仅 Obsidian 笔记draft{vault}/oa/drafts/{case_id}.md否仅 Obsidian 笔记入库后还会在 OA 库根自动生成_OA索引.md、_OA看板.base、_OA关联.canvas。frontmatter 字段的完整取值域patent_type的三种类型、notice_kind的四种通知书种类、outcome的六种结果、strategy的多种策略、defect_types的七种缺陷均可参考 references/schemas/oa_case.schema.yaml。6.2 硬性规则脱敏与状态闸门案例入库前必须脱敏客户名、具体未公开参数等并置redacted: true。仓库在 tools/oa/redact.py 中提供规则型脱敏自动将公司名替换为「申请人甲」、11 位手机号替换为「【电话已脱敏】」、913 位申请号替换为CNXXXXXXXXXX.X、邮箱与身份证号分别掩码同时返回变更摘要供人审。ingest_case.py的--skip-redact与--extra-name参数分别用于跳过脱敏演练场景与追加自定义脱敏姓名。本案例的申请号、对比文件均已占位化CNXXXXXXXX01.A正是该规则的产物。6.3 入库实操命令按 examples/example_oa_response/README.md 的冒烟流程本案例可直接入库# 可选跳过向量模型仅用标签检索向量是可选项不是必须项 python tools/oa/config.py skip-vector # 入库历史案演练场景加 --skip-redact正式使用务必脱敏 python tools/oa/ingest_case.py \ -i examples/example_oa_response/cases/history/hist-clarity-connector.md \ --skip-redact # 刷新 Obsidian 索引 / Canvas / Bases python tools/oa/refresh_vault.pyingest_case.py还支持直接从通知书 PDF 起草案例--pdf notice.pdf会自动抽取文本生成带 frontmatter 的草稿--draft-only只出草稿供人审补标签--reply-pdf可附带答复 PDF。入库时tools/oa/case_md.py 的parse_case_markdown负责解析 frontmatterchunk_case按## 小节将正文切分为header / notice / strategy / argument / amendment / outcome等类型的分块——像本案的「通知书要点」「策略」「陈述要点」「修改摘要」「结果」各小节都会生成独立 chunk 供向量检索。只有status: history的案例才写入 sqlite 检索库pending / draft只落 Obsidian 笔记这一状态闸门在ingest_one()中有明确实现。6.4 检索实操让历史案在答复时被想起来模式 D 的核心铁律是「先检索再生成不得无检索空写」。待答复通知书可直接作为查询输入python tools/oa/search_cases.py \ --query-file examples/example_oa_response/pending/oa_notice_pending.md \ --defect inventiveness \ --statute 专利法第22条第3款 \ --top-k 3search_cases.py支持--pdf通知书 PDF 自动抽取、--query直接文本、--query-filemd/txt三种查询来源以及--patent-type、--statute、--defect、--tag、--domain等元数据过滤条件。检索时先按statutes / defect_types / patent_type过滤再决定是否做向量 Top-K向量不可用或未开启时自动回退纯标签检索retrieval_mode会标注vector / tags_only / tags_fallback。每条命中都会附带diff字段法条、缺陷、领域、对比文件等的逐项对比生成答复时须引用命中案例的case_id、说明为何可参考并展示差异。若要检索本案这类清楚性案例例如面对一份同样质疑权利要求用语不清楚的新通知书可执行python tools/oa/search_cases.py --pdf new_office_action.pdf \ --patent-type invention \ --statute 专利法第26条第4款 \ --defect clarity \ --top-k 5七、源码级原理历史案如何从笔记变成可引用的弹药7.1 元数据始终可用向量只是增强tools/oa/store.py 的设计原则是「元数据始终可用向量sqlite-vec可选」cases表持久化 frontmatter 全字段statutes_json / defect_types_json / tags_json / strategy_json等即使未安装 sqlite-vec也能通过search_by_tags()做精确过滤vec_chunks虚拟表仅当启用向量模型时构建。search()的完整链路是元数据过滤 → 候选集内 KNNk max(limit_candidates, top_k)默认候选上限 50→ 按 chunk 距离排序并去重同一案例 → 组装命中。整个流程在 tests/oa/test_oa_store.py 中有对应单测覆盖StoreVecTests.test_upsert_and_search与TagOnlySearchTests。7.2 标签自动补全与索引联动ingest_case.py入库时会自动为defect_types生成oa/{defect}标签、为statutes生成法条/{statute}标签enrich_case_note()还会追加oa/status/{status}与oa/case并在正文补导航、关联案、对比文件节对比文件若有已建解读笔记则自动链接到Research/Patents下的笔记。本案例tags中的oa/clarity与法条/专利法第26条第4款正是这一自动化的产物也是后续按标签检索的关键入口。刷新时refresh_oa_vault()还会重写_OA索引.md按状态分组的案例清单、_OA看板.baseBases 表格视图与_OA关联.canvas按同法条/同缺陷/同领域/显式关联/同对比文件自动计算连线使整个案例库在 Obsidian 中可视化。7.3 向量模型可选回退永不中断tools/oa/config.py 内置zhipu / dashscope / openai / minimax / local五套 preset 与skip-vector仅标签检索工作流。check_rebuild_needed()通过provider|model|dimensions|base_url四元组指纹检测首次启用或模型变更并提示重建索引。即便向量自检失败tools/oa/README.md 与 prompts/oa/respond_office_action.md 都明确要求向量超时/失败不得中断用标签结果继续生成草稿——这正是本案这类纯标签可命中的案例被设计为可独立检索的原因。八、清楚性答复的可复用方法论综合本案与模式 D 的约束详见 prompts/oa/respond_office_action.md 与 SKILL.md 模式 D面对权利要求清楚性质疑时可复用以下检查清单术语溯源被质疑的用语如「可适配接口」是否在说明书中有结构限定与附图标记对应关系若有优先仅意见陈述。实施例支撑本领域技术人员结合实施例能否毫无疑义确定其含义把判断主体落到本领域技术人员。范围评估是否需要修改若修改每处修改必须指向说明书可支持位置若无必要明确声明不改动以保持保护范围。检索先行答复前用search_cases.py检索同法条专利法第26条第4款、同缺陷clarity的历史案引用命中案例并展示差异杜绝无检索空写。沉淀反哺授权后的答复案例按本笔记的 frontmatter 五段式结构归档至oa/cases/history/标注strategy: argue_only与outcome: granted让仅陈述即授权的路径成为下次答复可检索、可引用的资产。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考