cn-patent-oa-response

name	cn-patent-oa-response
description	分析CNIPA审查意见并形成修改依据与答复草案。适用于：分析CNIPA审查意见、对比文件和权利要求差异，形成问题拆解、修改依据和答复草案；应由专利代理师复核。

专利 OA 答复

使用本技能准备 OA 答复分析和答复材料草稿。除非用户明确要求通过公开编号获取缺失的公开专利数据，否则 OA、当前申请文本、D1/D2 对比文件和既往修改文本均为用户输入。

不可妥协的要求

• 不得假定 OA 文件、D1/D2、申请文本或既往修改文本可以自动获取。它们必须来自用户上传、粘贴文本或用户明确提供的专利/公开号。
• 不得编造审查员推理、引用段落、权利要求特征、修改内容或法律论证。
• 每项实质性陈述均须引证 OA、权利要求文本、D1/D2 段落、既往修改文本、用户指示或工具输出。
• 如文件为扫描件或图像件，在法律/技术分析前先进行 OCR，并保留 OCR 的不确定性。
• 不得在对话或交付物中暴露凭据。演示时使用已配置的本地凭据或用户本地提供的密钥存储。
• 免责声明：所有 AI 生成的 OA 答复材料均为草稿。提交 CNIPA 前，必须由合格的中国专利律师或专利代理师复核。AI 不能替代关于权利要求修改范围、审查策略或法律论证有效性的专业法律判断。

本地 API 封装器：调用规则

AI60 云端 OCR 是本地 API 封装器，并非 MCP 工具。

• 通过 Bash 工具，使用第一层表格和 references/source-map.md 中所示的精确 CLI 命令调用。
• 不得通过 ToolSearch 检索，它不会出现在 MCP 工具列表中。
• 不得通过 DeferExecuteTool 调用，它不是 MCP 工具。
• 仅对扫描版/图像版 OA 或 D1/D2 文件使用 AI60。对于原生 PDF，直接提取文本。
• 云端 OCR 服务（https://connect.zhihuiya.com）需要 API 密钥（--api-key 或 AI_API_KEY 环境变量）。文件模式（--file PATH）需要具有上传权限的 API 密钥；URL 模式（--document URL）可使用标准 AI60 权限。

CNIPA OA 法律基础映射

构建议题表（步骤 2）时，按每项驳回/审查意见对应的 CNIPA 法律基础分类。常见法律基础和答复策略如下：

法律基础	问题	关键答复策略
专利法第22条第2款（新颖性）	D1 已公开该权利要求	否认 D1 公开特征 X；论证 D1 公开的是不同技术方案；收窄权利要求以加入区别特征
专利法第22条第3款（创造性）	D1+D2 使权利要求显而易见	否认组合动机（D1 与 D2 解决不同技术问题）；论证预料不到的技术效果；论证 D1 对本发明存在反向教导
专利法第25条第1款（不授予专利权的客体）	发明属于疾病治疗方法、算法等	改写为制药用途权利要求；为算法权利要求加入具体技术实现；论证权利要求包含超出纯商业方法的技术特征
专利法第26条第3款（公开不充分）	说明书不足以实现发明	基于现有说明书补充解释；论证本领域技术人员可基于公知常识实施；标记是否需要修改
专利法第26条第4款（权利要求未获支持）	权利要求范围宽于说明书支持范围	将权利要求收窄至实施例范围；加入说明书支持的功能性限定；对马库什权利要求，确保具有足够的代表性实施例
专利法第33条（修改超出原始公开）	拟议修改加入新内容	撤回有问题的修改；仅使用原始公开语言重新起草；论证该修改可从原始申请中直接且毫无疑义地得出
实施细则第20条第2款（缺少必要技术特征）	独立权利要求缺少必要特征	从说明书中加入缺失的必要技术特征；论证该特征并非解决技术问题所必需
专利法第31条/实施细则第42条（缺乏单一性）	一件申请中包含多项发明	选择继续审查的发明；对未选择发明提交分案申请

必需输入

在起草完整 OA 答复前，收集或确认：

• OA 或审查意见通知书。
• 当前申请文本，至少包括权利要求书和相关说明书章节。
• D1/D2 及审查员所依据的其他引用文件。
• 如案件已有审查历史，提供既往修改文本和既往答复。
• 用户的策略约束，例如是否允许收窄修改。

如缺少必需输入，仅输出缺口清单和基于已有文件的部分分析。

工作流程

1. 解析所有用户提供的文件。

   • 仅对扫描版 PDF 或图像使用 OCR。
   • 在可用时保留页码、段落号、权利要求号和附图引用。

2. 构建议题表。

   • 从 OA 中提取每项驳回/审查意见。
   • 如 OA 中存在，记录对应的法律/规则依据。
   • 将每项问题关联至受影响的权利要求和引用证据。

3. 提取权利要求特征。

   • 将独立权利要求拆分为特征要素。
   • 仅当用户提供公开号或要求以公开专利数据补充时，使用 claims 或 patsnap_fetch。
   • 使用新颖性特征工具辅助提取，然后对照用户提供的权利要求文本核验。

4. 与 D1/D2 对比。

   • 将每项权利要求特征映射至 D1/D2 中引用的段落、权利要求、附图或实施例。
   • 将特征标记为已公开、未公开、部分公开或不清楚。
   • 除非工具结果与引用源文本相符，否则不得将其视为权威结论。

5. 制定答复策略。

   • 将论证与修改分开。
   • 识别说明书支持的区别特征和技术效果。
   • 如修改权利要求，确保每项修改均有原始公开依据（专利法第33条）。
   • 修改方式（根据问题类型选择适当方式）：
     • 进一步限定：从说明书中加入特征以收窄独立权利要求。该方式最稳妥，专利法第33条风险最低。
     • 删除权利要求：完全删除从属或独立权利要求。适用于无法挽救的权利要求。
     • 明显错误更正：更正文字或明显技术错误。必须能证明确属错误，例如错误的附图标记或拼写错误的化学名称。
     • 补入独立权利要求中的必要技术特征：将从属权利要求中的特征补入独立权利要求。必须核验该特征对解决技术问题是“必要的”。
   • 修改边界：任何修改均不得加入超出原始申请公开的新内容（专利法第33条）。“原始申请”是指提交时的内容，包括说明书、权利要求书和附图。“可直接且毫无疑义地得出”是判断标准；如有疑义，不得修改。
   • 如 OA 提出单一性异议，或权利要求修改会牺牲有价值的权利要求范围，应考虑分案申请。

6. 答复前补充检索（建议但非强制）。

   • 检索比 D1/D2 更有利于申请人立场的现有技术。
   • 默认方式（一键式）：将区别特征文本提交给 novelty_lite_submit，然后轮询 novelty_lite_get 直至完成。
   • 手动方式：使用 novelty_keywords_extract → novelty_lite_search → patsnap_search。选择一种方式，不得同时运行两种。
   • 对生物医药发明，添加 ls_drug_search、ls_clinical_trial_search 作为背景补充（见“工具架构 → 第二层”）。
   • 对 D1/D2 审查历史，使用 re_examination_data 和 litigation_data（见“工具架构 → 第二层”）。
   • 对化合物/序列发明，使用通道 B/C 工具（见下文“化学结构/生物序列 OA 论证”）。
   • 对全面的 FTO/有效性检索，参阅 patent-search-analysis-cn 技能。
   • 记录所有补充检索结果，无论有利或不利。

7. 起草输出。

   • 意见陈述书草稿。必需结构：
     • 一、答复摘要：答复的简要总结（1 段）。
     • 二、对具体审查意见的逐条答复：针对每项驳回/审查意见：
       • 陈述审查员立场和法律基础。
       • 以法律推理陈述申请人立场。
       • 引用具体说明书段落、D1/D2 段落或补充证据。
       • 如有修改，说明具体修改及其原始公开依据。
     • 三、修改说明：列出所有权利要求修改，包含修改前/后文本和修改依据。
     • 四、关于修改超范围的声明：确认所有修改均可从原始申请中直接且毫无疑义地得出（CNIPA 实务要求）。
   • 修改文本草稿，附修改前/后权利要求对比表。
   • 证据/来源附录。
   • 待解决问题和风险说明。

完整获取规则

如请求补充获取现有技术、专利族、法律状态、审查背景或竞品证据，不得选取方便的一小部分。应在 API 限制内获取全部可用记录：

• 将检索翻页直至到达总数、空页或 API 上限；
• 获取用户指定的全部引用文件；
• 记录总数、偏移量、上限和失败；
• 区分完整获取与受端点限制的获取。

对于 D1/D2，应始终分析用户提供的、与驳回相关的完整对比文件文本，而非只分析支持论证的片段。

工具架构（三层工具架构）

工具分为三个层级。工作流程步骤中仅指定第一层工具。 第二层工具按条件触发。第三层工具存放在 references/source-map.md 中，并通过 ToolSearch 按需加载。

第一层：核心工具（固定在流程步骤中）

步骤	操作	工具	说明
1. 解析文件	对扫描文件进行 OCR	AI60 CLI：python "$USERPROFILE/.workbuddy/api-wrappers/ai60/cli.py" smart_doc --file PATH [-o output.md]	云端 OCR 服务，需要 API 密钥（--api-key 或 AI_API_KEY 环境变量）。文件模式需要上传权限；URL 模式（--document URL）可使用标准权限。自动识别文件类型。原生 PDF 回退使用 Read 工具。
3. 提取特征	将权利要求拆分为特征要素	novelty_feature_extract + novelty_feature_comparison	辅助工具；须对照用户提供文本核验。
6. 补充检索（默认）	一键式新颖性检索	novelty_lite_submit → novelty_lite_get	优先使用。 自动执行全部检索和对比步骤。
6. 补充检索（手动）	分步检索	novelty_keywords_extract → novelty_lite_search → patsnap_search	仅在需要细粒度控制时使用。
7. 输出	Word/PDF 交付物	Documents/PDF 工具
法律状态	核验 D1/D2 法律状态	annuity_get_legal_status（e5851d）

第二层：扩展工具（条件分支触发）

触发条件：OA 涉及生物医药发明（药物化合物、抗体、序列、靶点、疾病）

• ls_drug_search：查找竞品药物管线数据，支持创造性论证。
• ls_clinical_trial_search / ls_clinical_trial_result_search：查找临床数据，证明预料不到的技术效果。
• ls_ner_nor_normalize：在查询药物情报工具前规范化药物/靶点/疾病名称。
• ls_drug_deal_search：了解商业重要性（支持权利要求价值论证）。
• ls_fda_label_vector_search：获取获批药物标签信息（支持 FTO/权利要求范围分析）。
• 重要：这些工具补充通道 A 检索，而非替代。始终先运行专利检索工具。

触发条件：已知 D1/D2 公开号且需要分析审查历史

• 对 D1/D2 使用 re_examination_data（30096b）：查找既往复审/无效决定。
• 对 D1/D2 使用 litigation_data（30096b）：查找执行/诉讼历史。
• 用于 FTO 风险评估和理解 D1/D2 审查背景。

触发条件：用户提供的 D1/D2 文本不完整，但可获得公开号

• patsnap_fetch：通用专利详情获取（默认优先）。
• tech_summary（958a46）：从 D1/D2 快速提取技术问题/方案/效果。
• claims（958a46）：获取 D1/D2 权利要求文本。
• description（958a46）：获取 D1/D2 完整说明书文本。
• 仅用于补充不完整的用户提供文本，不得替代用户提供的文件。

触发条件：OA 涉及小分子化合物权利要求（见下文“化学结构 OA 论证”）

• ls_structure_search（SIM/EXT）、ls_patent_structure_fetch、ls_chemical_mcs_analyze、ls_sar_submit+ls_sar_fetch、ls_admet_predict

触发条件：OA 涉及蛋白质/抗体/序列权利要求（见下文“生物序列 OA 论证”）

• ls_sequence_search_submit → check → get_results、ls_sequence_alignment、ls_antibody_antigen_search、ls_modification_search_submit

第三层：参考工具（按需加载）

以下工具位于 references/source-map.md 中，需要时通过 ToolSearch 加载：

• 专利内容（958a46）：search_patents、description_translated、claim_translated、legal_status、family、bibliography
• 专利法律（30096b）：fee_info、legal_data、license_data、transfer_data、pledge_data
• 药物情报详情：ls_drug_fetch、ls_drug_deal_fetch、ls_clinical_trial_fetch、ls_clinical_trial_result_fetch、ls_target_fetch、ls_disease_fetch、ls_organization_fetch、ls_organization_pipeline_fetch、ls_news_vector_search、ls_paper_vector_search、ls_patent_vector_search、ls_patent_search、ls_translational_medicine_search、ls_translational_medicine_fetch

互斥规则（必须遵守）

1. novelty_lite_submit 或 6 步手动流程：同一 tech_solution 绝不同时运行两者。选择一种方式并全程坚持。
2. 每次专利详情获取只用一个工具。 同一专利不得同时调用 patsnap_fetch 和 958a46.description；二选一：
   • patsnap_fetch：通用专利详情获取（默认优先）。
   • 958a46.description：仅在需要翻译后的说明书文本时使用。
3. 每次权利要求获取操作只用一个工具。 同一专利不得同时调用 1458a4.claims 和 958a46.claims；二选一。
4. 每次技术摘要操作只用一个工具。 同一专利不得同时调用 958a46.tech_summary 和 7cc6ae.tech_problem_benefit_summary；二选一。
5. ls_patent_search（pharma_intelligence）不能替代 patsnap_search。 前者仅检索生物医药专属索引；始终先运行 patsnap_search 以获得全面覆盖。
6. 药物情报工具补充但绝不替代专利检索工具。 先运行专利检索，再将药物情报作为背景增强。
7. AI60 云端 OCR（本地封装器）与 MCP 工具的区别：AI60 是 PatSnap 面向扫描版/图像版文件的云端 OCR 服务，通过 Bash 调用，且需要 API 密钥。不存在 MCP OCR 工具。不得在 ToolSearch 中检索“OCR”。仅当文件为扫描版/图像版时使用 AI60；对于原生 PDF，直接提取文本。

化学结构 OA 论证

当 OA 涉及小分子化合物权利要求，且审查员基于 D1/D2 化合物相似性提出驳回时：

1. 提取申请人化合物和 D1/D2 最接近化合物的 SMILES。
2. 使用申请人化合物的 SMILES 调用 ls_structure_search（SIM），查找具有已记录相似度评分的化合物；这可量化查询化合物的结构距离。如需专门量化与 D1/D2 的距离，分别以每个 D1/D2 化合物的 SMILES 为查询输入运行 ls_structure_search（SIM）。
3. 使用申请人的核心骨架调用 ls_structure_search（EXT，子结构模式），检查申请人化合物是否为任何 D1/D2 化合物的子结构（这可能表明存在被现有技术公开的风险）。
4. 针对 D1/D2 公开号使用 ls_patent_structure_fetch，提取 D1/D2 公开的全部化合物；核验审查员对 D1/D2 技术教导的描述是否完整。
5. 对[申请人化合物、D1 化合物、D2 化合物]使用 ls_chemical_mcs_analyze，证明申请人骨架包含 D1/D2 中不存在的片段。
6. 对 D1/D2 使用 ls_sar_submit + ls_sar_fetch 提取 SAR 数据；论证 D1/D2 未教导或暗示申请人的取代模式。
7. 对申请人化合物和 D1/D2 化合物使用 ls_admet_predict，提供意料不到技术效果的补充证据（例如更高生物利用度或更低 hERG 风险）。
8. 对所有化合物数据注明 InChIKey 和来源专利号。预测结果标记为 工具辅助，而非 来源。

生物序列 OA 论证

当 OA 涉及蛋白质、核酸、抗体或修饰序列权利要求时：

1. 提取申请人请求保护的序列和审查员引用的所有 D1/D2 序列。
2. 使用 ls_sequence_search_submit（database=CLAIMS，并设置适当同一性阈值）查找更接近的现有技术序列；这可表明 D1/D2 并非最接近的现有技术，或反过来确认审查员的认定。
3. 使用 ls_sequence_alignment（PSA）对申请人序列和 D1/D2 序列进行精确的成对比对，识别具体氨基酸/核苷酸差异。
4. 对 D1/D2 使用 ls_patent_sequence_fetch 提取所有已公开序列；核验审查员对现有技术序列范围的描述。
5. 对抗体权利要求，使用 ls_antibody_antigen_search 调研更广泛的抗体-抗原格局；这可支持申请人 CDR 组合非显而易见性的论证。
6. 对修饰序列权利要求（PEG 化、脂化等），使用 ls_modification_search_submit 查找现有技术修饰序列；基于具体修饰类型和位置论证新颖性/创造性。
7. 对所有序列数据注明 sequence_number 和来源专利号。比对结果标记为 工具辅助。

输出规范

将每项陈述标记为以下之一：

• 来源：由用户文件或公开专利数据直接支持。
• 工具辅助：由 OCR 或 MCP/API 生成且经人工核验。
• 分析：基于引用来源的法律/技术推理。
• 假设：已明确说明且需要用户确认。

绝不将假设表述为事实。