拓冰网站定制 
ARIS invention-structuring 技能详解把原始发明想法结构化为专利交底书【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep导读本文围绕 ARISAuto-Research-In-Sleep开源仓库中的 invention-structuring 技能 展开完整讲解如何将一个零散的原始发明想法通过技术问题—技术方案—有益效果框架、三层发明分解、可专利主题识别、附图规划、权利要求依赖映射与跨模型验证等步骤最终结构化输出为一份可直接进入权利要求撰写阶段的patent/INVENTION_DISCLOSURE.md专利交底书。读完本文你将掌握该技能的全部操作流程、每一步背后的专利法理依据新颖性、创造性、充分公开、单一性等以及它如何在 patent-pipeline 完整专利流水线中与查新、权利要求撰写、说明书撰写、审查与格式编译等环节衔接配合。一、技能定位专利流水线的结构设计环节invention-structuring是 ARIS 专利流水线中的承上启下环节。从 patent-pipeline 的流水线定义 可以看到完整的链条/prior-art-search → /patent-novelty-check → /invention-structuring → /claims-drafting → /specification-writing → /patent-review → /jurisdiction-format (查新) (可专利性验证) (发明结构化) (权利要求) (说明书) (审查) (格式编译) ├── /figure-description └── /embodiment-description其上游是 prior-art-search 生成的patent/PRIOR_ART_REPORT.md与 patent-novelty-check 生成的patent/NOVELTY_ASSESSMENT.md其下游则是 claims-drafting——技能的 描述 明确指出其Adapted from the refinement pattern in /research-refine for patent invention decomposition即借鉴了 research-refine 的迭代精炼思路但服务于专利发明拆解这一特定目标。技能本身通过两个常量控制运行行为常量值含义REVIEWER_MODELgpt-6-astra通过mcp__codex__codex调用的外部验证模型用于对发明拆解结果做审查MAX_REFINEMENT_ROUNDS3最大结构迭代轮次防止无限精修其中MAX_REFINEMENT_ROUNDS 3与 claims-drafting 的MAX_CLAIM_REVISION_ROUNDS 3、patent-pipeline 的MAX_REVIEW_ROUNDS 2一起构成了整个流水线中有限迭代、逐环收敛的质量控制机制。技能输入技能运行前需要准备以下输入全部位于patent/目录为运行产物而非仓库内文件$ARGUMENTS中携带的发明描述用户直接描述或引用一个简报文件路径如invention-structuring patent/INVENTION_BRIEF.mdpatent/INVENTION_BRIEF.md若存在——由用户在 模板 基础上填写或在 patent-pipeline Phase 0 中从对话式描述解析生成patent/PRIOR_ART_REPORT.md——现有技术全景patent/NOVELTY_ASSESSMENT.md——新颖性与创造性分析结论。若尚未有发明简报用户可参照仓库中的 INVENTION_BRIEF_TEMPLATE.md 先行填写或在专利流水线入口直接描述发明由 pipeline 的 Phase 0 自动解析成简报。二、Step 1技术问题—技术方案—有益效果框架专利交底书的第一性要求是把发明说了什么转化为法律可审查的三段式。技能要求严格遵循 Problem-Solution-Advantage问题—方案—效果通用专利框架这一框架同时是 specification-writing 中发明内容部分、以及中国、美国、欧洲各法域审查实践的共同母题。技术问题Technical Problem必须来源于现有技术的缺陷即NOVELTY_ASSESSMENT.md中指出的 prior art deficiencies而不是商业或社会需求必须是具体的技术问题不是商业问题或社会问题陈述格式固定为The technical problem to be solved is how to [具体技术目标] given [具体技术约束].这与 specification-writing 中背景技术不是文献综述而是直接引出问题的规则一脉相承说明书background.md描述的现有技术缺陷正是这里技术问题的源头中国专利格式中对应本发明要解决的技术问题是……见 patent-format-cn。技术方案Technical Solution描述发明的具体技术贡献聚焦机制mechanism而非结果——这也是 patent-writing-principles 中result-to-be-achieved language禁令的直接体现例如实现99%图像分类精度不可包含至少三个残差块的卷积神经网络提取特征可描述粒度须与计划的权利要求保护范围匹配必须区分哪些特征是**已知known的、哪些是发明inventive**的——这一区分是后续 claims-drafting 中前序部分/特征部分CN/EP 两部式划分的基础。有益效果Advantages必须是相对现有技术可度量或可量化的改进必须由发明特征本身产生而非良好工程实践的附带结果在已知具体技术效果时可写入如处理时间减少 40%。需要特别注意的是这里的有益效果定位在交底书层面而进入正式说明书时specification-writing 与 patent-format-cn 都要求说明书发明内容与具体实施方式中不得写入实验数据/精度百分比有益效果须用结构性推理表述由于采用了……结构因此具有……效果。交底书中标注可量化的技术效果正是为了在后续审查阶段而非说明书正文作为争辩材料使用。三、Step 2三层发明分解核心发明构思/支撑性特征/可选特征技能要求把发明拆解为三个层次这一分层直接决定了后续权利要求金字塔的形态层级定义对应权利要求判定测试核心发明构思Core Inventive Concept使发明具备可专利性的最小特征集合独立权利要求范围测试删掉该特征发明不再新颖支撑性特征Supporting Features使发明在实践中良好运转的特征从属权利要求素材每个支撑特征应具备独立技术价值可选特征Optional Features实现细节、优选参数、替代方案实施例素材支持更宽的权利要求解释三层分解的最小集测试与 patent-writing-principles 中独立权利要求应是在现有技术之上最宽的可辩护范围——不更宽也不更窄的原则精确对应核心构思多了会把竞争对手挡在保护范围外少了则会被现有技术破坏新颖性。支撑性特征各自独立有价值的规则也相当关键——它确保了每个从属权利要求作为**独立的后备位置fallback position**都能单独存活当独立权利要求被驳回时窄化的从属权利要求可以逐级承接。这正是 claims-drafting 中每个从属权利要求都必须增加至少一个有意义限定、不得只是复述母权利要求的依据。四、Step 3可专利主题识别针对核心发明构思技能要求判定应当撰写哪些类别的权利要求类别适用条件内容方法/流程Method/process发明包含步骤流程、算法、工作流系统/设备System/apparatus发明包含组件硬件结构、模块、连接关系产品Product发明是物理装置形状、结构、组成计算机可读介质Computer-readable medium软件类发明美国存储的指令、非暂态介质产品-方法限定Product-by-process结构难以界定以制造方式定义的产品多类别权利要求的法律价值在于同一发明撰写方法系统介质等多类权利要求等于在同一申请内复制了多重保护面无需另案申请。这一点在 patent-writing-principles 中有明确论述且是中美欧审查实践的共同策略。不过类别选择受法域与专利类型约束claims-drafting 给出了精确边界中国实用新型utility model仅限装置/设备权利要求禁止方法权利要求且只需 1 条独立装置权利要求美国软件发明可单独撰写non-transitory computer-readable storage medium权利要求见 patent-format-us 的示例格式EP 的独立权利要求强制两部式two-part form涉及新化合物本身、产品-方法限定等例外情形可不采用见 patent-format-ep。因此本步骤的输出应当是按目标法域可落地的类别清单而非漫无边际的类别罗列。五、Step 4附图规划Drawing Plan说明书与权利要求需要附图支撑以实现充分公开enablement。技能提供了一个最小附图规划模板图号类型展示内容支撑的权利要求要素FIG. 1框图Block diagram系统架构系统权利要求的组件FIG. 2流程图Flowchart方法步骤方法权利要求的步骤FIG. 3时序图Sequence diagram组件间交互具体实现细节处理规则若用户已提供附图则直接引用若缺少附图则记录缺口note what is needed。附图规划在 patent-format-us 与 patent-format-ep 中有更细的合规要求可在规划时同步对照附图必须展示权利要求中限定的每一个特征附图标记须与说明书完全一致FIG. 1 用 100 系列、FIG. 2 用 200 系列格式统一为 FIG. 1图中除附图标记与必要标签外不得出现文字中国专利还要求提供摘要附图——从申请附图中选取最能代表发明的一幅见 patent-format-cn。另外specification-writing 会在说明书阶段调用/figure-description子技能处理用户提供的附图并产出patent/figures/numeral_index.md附图标记索引供审查阶段核对。六、Step 5依赖映射Dependency Mapping技能以 ASCII 树形图规划权利要求层级Independent Claim 1 (method, broadest scope) ├── Core inventive feature A ├── Core inventive feature B └── Known feature C (for context) Dependent Claim 2 → narrows feature A with specific implementation Dependent Claim 3 → narrows feature B with specific parameters Dependent Claim 4 → depends on 2, adds optional feature D Dependent Claim 5 → alternative implementation of feature A这份依赖映射的价值在于把三层分解翻译为可起草的权利要求清单核心构思 → 独立权利要求支撑特征 → 从属权利要求可选特征 → 更外围的从属/实施例。在起草阶段claims-drafting 会进一步落实这里的映射连续编号CN 格式硬性要求独立权利要求与从属权利要求交错连续编号1, 2, 3, …即使层级上独立权利要求是 1/4/7最终编号也必须连续无缺从属权利要求规则必须引用在先权利要求编号、必须增加有意义的限定、不得复述母权利要求、不得仅为其他从属权利要求的简单叠加即权利要求区分原则claim differentiation美国多引权利要求只能以 or 连接claim 1 or claim 2and 非法EP 允许多引any one of claims 1 to 3但不允许多引权利要求再被多引。依赖映射还应当与权利要求数量目标对齐MAX_TOTAL_CLAIMS 20USPTO 基础官费包含 20 条与MIN_INDEPENDENT_CLAIMS 2典型为方法系统是 claims-drafting 的默认常量交底书阶段的映射若超出该规模需在起草时做取舍。七、Step 6跨模型验证Cross-Model Validation结构设计完成后技能要求通过mcp__codex__codex调用REVIEWER_MODEL gpt-6-astra以xhigh推理强度进行外部验证。调用载荷格式如下mcp__codex__codex: model: gpt-6-astra config: {model_reasoning_effort: xhigh} prompt: | You are a patent attorney reviewing an invention disclosure. Evaluate the structuring choices: INVENTION: [Problem-Solution-Advantage summary] DECOMPOSITION: [Core/Supporting/Optional features] CLAIM PLAN: [intended claim categories and hierarchy] Please assess: 1. Is the Problem-Solution-Advantage framework correctly applied? 2. Is the core inventive concept correctly identified? Are there features that should be core but are listed as supporting (or vice versa)? 3. Are the planned claim categories sufficient to protect the invention? 4. Is the drawing plan adequate for enablement? 5. Are there any claimable aspects being missed?这五条审查维度分别对应框架正确性、核心构思识别、类别充分性、附图对充分公开的支撑、可专利点遗漏。这是 ARIS 特有的交叉模型审查方法论在专利领域的延伸——与 patent-novelty-check 中的专利审查员验证、claims-drafting 中的权利要求质量审查含清晰性 112(b)/Art 84、书面描述 112(a)/Art 83、预期 102/Art 54、非显而易见性 103/Art 56、先行基础 antecedent basis、不确定术语等八个维度、以及 patent-review 中的正式审查意见书office action审查形成三级验证体系。降级与容错规则如果mcp__codex__codex不可用例如未配置 OpenAI API 密钥技能要求跳过跨模型验证并在输出中注明——流水线不得因缺少审查器而失败。同样的降级策略在 patent-pipeline、patent-novelty-check、claims-drafting、specification-writing 中均有一致约定构成整个专利流水线的通用容错契约。环境前提调用mcp__codex__codex需要先配置 Codex MCP Server。仓库中的 patent-review 给出了参考配置命令claude mcp add codex -s user -- python3 $HOME/aris_repo/mcp-servers/codex-exec/server.py其中mcp-servers/codex-exec/server.py即本仓库中 codex-exec MCP 服务端 的实现路径可按你的 ARIS 克隆实际位置替换。八、Step 7输出发明交底书技能最终输出patent/INVENTION_DISCLOSURE.md模板如下原文完整继承## Invention Disclosure ### Title [invention title] ### Technical Problem [formal problem statement] ### Technical Solution [formal solution description] ### Advantages [measurable advantages] ### Feature Decomposition #### Core Inventive Concept [features that define independent claim scope] #### Supporting Features [features for dependent claims] #### Optional Features [features for embodiments] ### Claimable Subject Matter [method, system, product, medium claims planned] ### Drawing Plan [figures needed, what each shows] ### Dependency Map [claim hierarchy plan] ### Inventor Information [names, contributions] ### Target Jurisdiction [CN/US/EP/ALL]这个输出结构是下游即用的Feature Decomposition与Dependency Map直接成为 claims-drafting 的输入Claimable Subject Matter决定权利要求类别清单Drawing Plan流向/figure-description子技能与附图制作Target Jurisdiction则最终决定 jurisdiction-format 编译成 CNIPA / USPTO / EPO 哪种申请文件。在完整流水线中patent-pipeline 的 Phase 2 会在此处设置检查点Checkpoint向用户呈现Invention structured: - Core inventive concept: [summary] - Claim categories: [method, system, etc.] - Claims drafted: [X] independent [Y] dependent [Z] total - Independent claim 1 (broadest): [first 50 words of claim 1] - Examiner review score: [X]/10在AUTO_PROCEED false默认时流水线在此等待用户确认只有明确回复后才进入权利要求起草阶段——因为专利撰写在每一环节都依赖发明人的判断。九、关键规则与常见误区技能末尾列出的关键规则是区分专利交底书与科研论文/技术报告的判据逐条展开如下技术问题必须来自现有技术缺陷而非商业需求——商业动机不是可专利的技术贡献技术方案必须描述技术机制而非结果——做什么不足以成立权利要求怎么做才是核心发明构思 可专利性的最小特征集——这是独立权利要求范围的边界支撑特征应各自独立有价值——保证从属权利要求可独立作为后备位置禁止虚构实施例——不得编造与真实发明或用户提供材料不对应的实施方式跨模型验证不可用则跳过并注明——降级不阻断流程。结合 patent-writing-principles 中的通用陷阱交底书/后续权利要求撰写还须规避否定式限定negative limitations避免用不使用数据库这类不是什么定义发明结果导向权利要求禁写用于达到 99% 精度的方法改述机制不确定术语high quality / efficient / optimal过于含糊美国会收到 112(b) 驳回approximately / about必须由说明书界定范围功能化撰写means-plus-function美国 means for processing 会触发 35 USC 112(f)被限缩到说明书描述的具体结构更安全写法是 a processor configured to process术语一致性同一概念全文同词不得在 processor / processing unit / CPU 间交替先行基础a processor 首次出现用不定冠词the processor 其后用定冠词混用会被认为引入了第二个实例。中国专利还有额外纪律见 patent-format-cn权利要求只写结构特征或方法步骤禁止写入检测原理、信号特征、测量结果如产生负脉冲信号谐振频率下降属于说明书内容首次引入组件用一个/一种其后统一用所述。十、在完整专利流水线中的位置与入口invention-structuring不是孤立技能而是 patent-pipeline 定义的三条研究支线之一专利线的中间产物┌→ /experiment-bridge → /auto-review-loop → /paper-writing (发表线) /idea-discovery ────┤ ├→ /grant-proposal → [get funded] → ... (基金线) └→ /patent-pipeline → [file patent] (专利线)专利线可以从多个入口启动均可汇聚到发明结构化环节用户直接描述发明 ──────────────→ /patent-pipeline /idea-discovery 产出 IDEA_REPORT.md ──→ /patent-pipeline (抽取可专利方面) /research-refine 产出 FINAL_PROPOSAL.md ─→ /patent-pipeline (从精炼研究想法出发) /auto-review-loop 产出强结果 ────→ /patent-pipeline (为方法申请专利)同时invention-structuring的运行产物patent/INVENTION_DISCLOSURE.md也会被 patent-pipeline 的状态持久化机制跟踪每个阶段结束时写入patent/PATENT_STATE.json包含 phase、jurisdiction、patent_type、claims_count、status、timestamp 等字段中断后可据此恢复24 小时内的in_progress状态自动续跑过期则重新开始。结语invention-structuring的价值在于在撰写权利要求之前就把法律结构想清楚用问题—方案—效果框架锁定可专利贡献用三层分解划定独立/从属/实施例的边界用主题识别与依赖映射规划权利要求金字塔再用外部模型以 xhigh 推理强度交叉验证结构的完备性。它产出的INVENTION_DISCLOSURE.md是一份即插即用的结构化交底书可直接驱动下游的权利要求起草、说明书撰写与多法域格式编译。对于希望在 ARIS 中建立从研究想法到专利申请完整链路的用户可以从 invention-structuring 技能文件 入手配合 patent-pipeline、patent-writing-principles 及 CN/US/EP 三套格式指南构建完整的专利起草工作台。【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ARIS invention-structuring 技能详解：把原始发明想法结构化为专利交底书
ARIS invention-structuring 技能详解把原始发明想法结构化为专利交底书【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep导读本文围绕 ARISAuto-Research-In-Sleep开源仓库中的 invention-structuring 技能 展开完整讲解如何将一个零散的原始发明想法通过技术问题—技术方案—有益效果框架、三层发明分解、可专利主题识别、附图规划、权利要求依赖映射与跨模型验证等步骤最终结构化输出为一份可直接进入权利要求撰写阶段的patent/INVENTION_DISCLOSURE.md专利交底书。读完本文你将掌握该技能的全部操作流程、每一步背后的专利法理依据新颖性、创造性、充分公开、单一性等以及它如何在 patent-pipeline 完整专利流水线中与查新、权利要求撰写、说明书撰写、审查与格式编译等环节衔接配合。一、技能定位专利流水线的结构设计环节invention-structuring是 ARIS 专利流水线中的承上启下环节。从 patent-pipeline 的流水线定义 可以看到完整的链条/prior-art-search → /patent-novelty-check → /invention-structuring → /claims-drafting → /specification-writing → /patent-review → /jurisdiction-format (查新) (可专利性验证) (发明结构化) (权利要求) (说明书) (审查) (格式编译) ├── /figure-description └── /embodiment-description其上游是 prior-art-search 生成的patent/PRIOR_ART_REPORT.md与 patent-novelty-check 生成的patent/NOVELTY_ASSESSMENT.md其下游则是 claims-drafting——技能的 描述 明确指出其Adapted from the refinement pattern in /research-refine for patent invention decomposition即借鉴了 research-refine 的迭代精炼思路但服务于专利发明拆解这一特定目标。技能本身通过两个常量控制运行行为常量值含义REVIEWER_MODELgpt-6-astra通过mcp__codex__codex调用的外部验证模型用于对发明拆解结果做审查MAX_REFINEMENT_ROUNDS3最大结构迭代轮次防止无限精修其中MAX_REFINEMENT_ROUNDS 3与 claims-drafting 的MAX_CLAIM_REVISION_ROUNDS 3、patent-pipeline 的MAX_REVIEW_ROUNDS 2一起构成了整个流水线中有限迭代、逐环收敛的质量控制机制。技能输入技能运行前需要准备以下输入全部位于patent/目录为运行产物而非仓库内文件$ARGUMENTS中携带的发明描述用户直接描述或引用一个简报文件路径如invention-structuring patent/INVENTION_BRIEF.mdpatent/INVENTION_BRIEF.md若存在——由用户在 模板 基础上填写或在 patent-pipeline Phase 0 中从对话式描述解析生成patent/PRIOR_ART_REPORT.md——现有技术全景patent/NOVELTY_ASSESSMENT.md——新颖性与创造性分析结论。若尚未有发明简报用户可参照仓库中的 INVENTION_BRIEF_TEMPLATE.md 先行填写或在专利流水线入口直接描述发明由 pipeline 的 Phase 0 自动解析成简报。二、Step 1技术问题—技术方案—有益效果框架专利交底书的第一性要求是把发明说了什么转化为法律可审查的三段式。技能要求严格遵循 Problem-Solution-Advantage问题—方案—效果通用专利框架这一框架同时是 specification-writing 中发明内容部分、以及中国、美国、欧洲各法域审查实践的共同母题。技术问题Technical Problem必须来源于现有技术的缺陷即NOVELTY_ASSESSMENT.md中指出的 prior art deficiencies而不是商业或社会需求必须是具体的技术问题不是商业问题或社会问题陈述格式固定为The technical problem to be solved is how to [具体技术目标] given [具体技术约束].这与 specification-writing 中背景技术不是文献综述而是直接引出问题的规则一脉相承说明书background.md描述的现有技术缺陷正是这里技术问题的源头中国专利格式中对应本发明要解决的技术问题是……见 patent-format-cn。技术方案Technical Solution描述发明的具体技术贡献聚焦机制mechanism而非结果——这也是 patent-writing-principles 中result-to-be-achieved language禁令的直接体现例如实现99%图像分类精度不可包含至少三个残差块的卷积神经网络提取特征可描述粒度须与计划的权利要求保护范围匹配必须区分哪些特征是**已知known的、哪些是发明inventive**的——这一区分是后续 claims-drafting 中前序部分/特征部分CN/EP 两部式划分的基础。有益效果Advantages必须是相对现有技术可度量或可量化的改进必须由发明特征本身产生而非良好工程实践的附带结果在已知具体技术效果时可写入如处理时间减少 40%。需要特别注意的是这里的有益效果定位在交底书层面而进入正式说明书时specification-writing 与 patent-format-cn 都要求说明书发明内容与具体实施方式中不得写入实验数据/精度百分比有益效果须用结构性推理表述由于采用了……结构因此具有……效果。交底书中标注可量化的技术效果正是为了在后续审查阶段而非说明书正文作为争辩材料使用。三、Step 2三层发明分解核心发明构思/支撑性特征/可选特征技能要求把发明拆解为三个层次这一分层直接决定了后续权利要求金字塔的形态层级定义对应权利要求判定测试核心发明构思Core Inventive Concept使发明具备可专利性的最小特征集合独立权利要求范围测试删掉该特征发明不再新颖支撑性特征Supporting Features使发明在实践中良好运转的特征从属权利要求素材每个支撑特征应具备独立技术价值可选特征Optional Features实现细节、优选参数、替代方案实施例素材支持更宽的权利要求解释三层分解的最小集测试与 patent-writing-principles 中独立权利要求应是在现有技术之上最宽的可辩护范围——不更宽也不更窄的原则精确对应核心构思多了会把竞争对手挡在保护范围外少了则会被现有技术破坏新颖性。支撑性特征各自独立有价值的规则也相当关键——它确保了每个从属权利要求作为**独立的后备位置fallback position**都能单独存活当独立权利要求被驳回时窄化的从属权利要求可以逐级承接。这正是 claims-drafting 中每个从属权利要求都必须增加至少一个有意义限定、不得只是复述母权利要求的依据。四、Step 3可专利主题识别针对核心发明构思技能要求判定应当撰写哪些类别的权利要求类别适用条件内容方法/流程Method/process发明包含步骤流程、算法、工作流系统/设备System/apparatus发明包含组件硬件结构、模块、连接关系产品Product发明是物理装置形状、结构、组成计算机可读介质Computer-readable medium软件类发明美国存储的指令、非暂态介质产品-方法限定Product-by-process结构难以界定以制造方式定义的产品多类别权利要求的法律价值在于同一发明撰写方法系统介质等多类权利要求等于在同一申请内复制了多重保护面无需另案申请。这一点在 patent-writing-principles 中有明确论述且是中美欧审查实践的共同策略。不过类别选择受法域与专利类型约束claims-drafting 给出了精确边界中国实用新型utility model仅限装置/设备权利要求禁止方法权利要求且只需 1 条独立装置权利要求美国软件发明可单独撰写non-transitory computer-readable storage medium权利要求见 patent-format-us 的示例格式EP 的独立权利要求强制两部式two-part form涉及新化合物本身、产品-方法限定等例外情形可不采用见 patent-format-ep。因此本步骤的输出应当是按目标法域可落地的类别清单而非漫无边际的类别罗列。五、Step 4附图规划Drawing Plan说明书与权利要求需要附图支撑以实现充分公开enablement。技能提供了一个最小附图规划模板图号类型展示内容支撑的权利要求要素FIG. 1框图Block diagram系统架构系统权利要求的组件FIG. 2流程图Flowchart方法步骤方法权利要求的步骤FIG. 3时序图Sequence diagram组件间交互具体实现细节处理规则若用户已提供附图则直接引用若缺少附图则记录缺口note what is needed。附图规划在 patent-format-us 与 patent-format-ep 中有更细的合规要求可在规划时同步对照附图必须展示权利要求中限定的每一个特征附图标记须与说明书完全一致FIG. 1 用 100 系列、FIG. 2 用 200 系列格式统一为 FIG. 1图中除附图标记与必要标签外不得出现文字中国专利还要求提供摘要附图——从申请附图中选取最能代表发明的一幅见 patent-format-cn。另外specification-writing 会在说明书阶段调用/figure-description子技能处理用户提供的附图并产出patent/figures/numeral_index.md附图标记索引供审查阶段核对。六、Step 5依赖映射Dependency Mapping技能以 ASCII 树形图规划权利要求层级Independent Claim 1 (method, broadest scope) ├── Core inventive feature A ├── Core inventive feature B └── Known feature C (for context) Dependent Claim 2 → narrows feature A with specific implementation Dependent Claim 3 → narrows feature B with specific parameters Dependent Claim 4 → depends on 2, adds optional feature D Dependent Claim 5 → alternative implementation of feature A这份依赖映射的价值在于把三层分解翻译为可起草的权利要求清单核心构思 → 独立权利要求支撑特征 → 从属权利要求可选特征 → 更外围的从属/实施例。在起草阶段claims-drafting 会进一步落实这里的映射连续编号CN 格式硬性要求独立权利要求与从属权利要求交错连续编号1, 2, 3, …即使层级上独立权利要求是 1/4/7最终编号也必须连续无缺从属权利要求规则必须引用在先权利要求编号、必须增加有意义的限定、不得复述母权利要求、不得仅为其他从属权利要求的简单叠加即权利要求区分原则claim differentiation美国多引权利要求只能以 or 连接claim 1 or claim 2and 非法EP 允许多引any one of claims 1 to 3但不允许多引权利要求再被多引。依赖映射还应当与权利要求数量目标对齐MAX_TOTAL_CLAIMS 20USPTO 基础官费包含 20 条与MIN_INDEPENDENT_CLAIMS 2典型为方法系统是 claims-drafting 的默认常量交底书阶段的映射若超出该规模需在起草时做取舍。七、Step 6跨模型验证Cross-Model Validation结构设计完成后技能要求通过mcp__codex__codex调用REVIEWER_MODEL gpt-6-astra以xhigh推理强度进行外部验证。调用载荷格式如下mcp__codex__codex: model: gpt-6-astra config: {model_reasoning_effort: xhigh} prompt: | You are a patent attorney reviewing an invention disclosure. Evaluate the structuring choices: INVENTION: [Problem-Solution-Advantage summary] DECOMPOSITION: [Core/Supporting/Optional features] CLAIM PLAN: [intended claim categories and hierarchy] Please assess: 1. Is the Problem-Solution-Advantage framework correctly applied? 2. Is the core inventive concept correctly identified? Are there features that should be core but are listed as supporting (or vice versa)? 3. Are the planned claim categories sufficient to protect the invention? 4. Is the drawing plan adequate for enablement? 5. Are there any claimable aspects being missed?这五条审查维度分别对应框架正确性、核心构思识别、类别充分性、附图对充分公开的支撑、可专利点遗漏。这是 ARIS 特有的交叉模型审查方法论在专利领域的延伸——与 patent-novelty-check 中的专利审查员验证、claims-drafting 中的权利要求质量审查含清晰性 112(b)/Art 84、书面描述 112(a)/Art 83、预期 102/Art 54、非显而易见性 103/Art 56、先行基础 antecedent basis、不确定术语等八个维度、以及 patent-review 中的正式审查意见书office action审查形成三级验证体系。降级与容错规则如果mcp__codex__codex不可用例如未配置 OpenAI API 密钥技能要求跳过跨模型验证并在输出中注明——流水线不得因缺少审查器而失败。同样的降级策略在 patent-pipeline、patent-novelty-check、claims-drafting、specification-writing 中均有一致约定构成整个专利流水线的通用容错契约。环境前提调用mcp__codex__codex需要先配置 Codex MCP Server。仓库中的 patent-review 给出了参考配置命令claude mcp add codex -s user -- python3 $HOME/aris_repo/mcp-servers/codex-exec/server.py其中mcp-servers/codex-exec/server.py即本仓库中 codex-exec MCP 服务端 的实现路径可按你的 ARIS 克隆实际位置替换。八、Step 7输出发明交底书技能最终输出patent/INVENTION_DISCLOSURE.md模板如下原文完整继承## Invention Disclosure ### Title [invention title] ### Technical Problem [formal problem statement] ### Technical Solution [formal solution description] ### Advantages [measurable advantages] ### Feature Decomposition #### Core Inventive Concept [features that define independent claim scope] #### Supporting Features [features for dependent claims] #### Optional Features [features for embodiments] ### Claimable Subject Matter [method, system, product, medium claims planned] ### Drawing Plan [figures needed, what each shows] ### Dependency Map [claim hierarchy plan] ### Inventor Information [names, contributions] ### Target Jurisdiction [CN/US/EP/ALL]这个输出结构是下游即用的Feature Decomposition与Dependency Map直接成为 claims-drafting 的输入Claimable Subject Matter决定权利要求类别清单Drawing Plan流向/figure-description子技能与附图制作Target Jurisdiction则最终决定 jurisdiction-format 编译成 CNIPA / USPTO / EPO 哪种申请文件。在完整流水线中patent-pipeline 的 Phase 2 会在此处设置检查点Checkpoint向用户呈现Invention structured: - Core inventive concept: [summary] - Claim categories: [method, system, etc.] - Claims drafted: [X] independent [Y] dependent [Z] total - Independent claim 1 (broadest): [first 50 words of claim 1] - Examiner review score: [X]/10在AUTO_PROCEED false默认时流水线在此等待用户确认只有明确回复后才进入权利要求起草阶段——因为专利撰写在每一环节都依赖发明人的判断。九、关键规则与常见误区技能末尾列出的关键规则是区分专利交底书与科研论文/技术报告的判据逐条展开如下技术问题必须来自现有技术缺陷而非商业需求——商业动机不是可专利的技术贡献技术方案必须描述技术机制而非结果——做什么不足以成立权利要求怎么做才是核心发明构思 可专利性的最小特征集——这是独立权利要求范围的边界支撑特征应各自独立有价值——保证从属权利要求可独立作为后备位置禁止虚构实施例——不得编造与真实发明或用户提供材料不对应的实施方式跨模型验证不可用则跳过并注明——降级不阻断流程。结合 patent-writing-principles 中的通用陷阱交底书/后续权利要求撰写还须规避否定式限定negative limitations避免用不使用数据库这类不是什么定义发明结果导向权利要求禁写用于达到 99% 精度的方法改述机制不确定术语high quality / efficient / optimal过于含糊美国会收到 112(b) 驳回approximately / about必须由说明书界定范围功能化撰写means-plus-function美国 means for processing 会触发 35 USC 112(f)被限缩到说明书描述的具体结构更安全写法是 a processor configured to process术语一致性同一概念全文同词不得在 processor / processing unit / CPU 间交替先行基础a processor 首次出现用不定冠词the processor 其后用定冠词混用会被认为引入了第二个实例。中国专利还有额外纪律见 patent-format-cn权利要求只写结构特征或方法步骤禁止写入检测原理、信号特征、测量结果如产生负脉冲信号谐振频率下降属于说明书内容首次引入组件用一个/一种其后统一用所述。十、在完整专利流水线中的位置与入口invention-structuring不是孤立技能而是 patent-pipeline 定义的三条研究支线之一专利线的中间产物┌→ /experiment-bridge → /auto-review-loop → /paper-writing (发表线) /idea-discovery ────┤ ├→ /grant-proposal → [get funded] → ... (基金线) └→ /patent-pipeline → [file patent] (专利线)专利线可以从多个入口启动均可汇聚到发明结构化环节用户直接描述发明 ──────────────→ /patent-pipeline /idea-discovery 产出 IDEA_REPORT.md ──→ /patent-pipeline (抽取可专利方面) /research-refine 产出 FINAL_PROPOSAL.md ─→ /patent-pipeline (从精炼研究想法出发) /auto-review-loop 产出强结果 ────→ /patent-pipeline (为方法申请专利)同时invention-structuring的运行产物patent/INVENTION_DISCLOSURE.md也会被 patent-pipeline 的状态持久化机制跟踪每个阶段结束时写入patent/PATENT_STATE.json包含 phase、jurisdiction、patent_type、claims_count、status、timestamp 等字段中断后可据此恢复24 小时内的in_progress状态自动续跑过期则重新开始。结语invention-structuring的价值在于在撰写权利要求之前就把法律结构想清楚用问题—方案—效果框架锁定可专利贡献用三层分解划定独立/从属/实施例的边界用主题识别与依赖映射规划权利要求金字塔再用外部模型以 xhigh 推理强度交叉验证结构的完备性。它产出的INVENTION_DISCLOSURE.md是一份即插即用的结构化交底书可直接驱动下游的权利要求起草、说明书撰写与多法域格式编译。对于希望在 ARIS 中建立从研究想法到专利申请完整链路的用户可以从 invention-structuring 技能文件 入手配合 patent-pipeline、patent-writing-principles 及 CN/US/EP 三套格式指南构建完整的专利起草工作台。【免费下载链接】Auto-claude-code-research-in-sleepARIS ⚔️ (Auto-Research-In-Sleep) — Lightweight Markdown-only skills for autonomous ML research: cross-model review loops, idea discovery, and experiment automation. No framework, no lock-in — works with Claude Code, Codex, OpenClaw, or any LLM agent.项目地址: https://gitcode.com/gh_mirrors/au/Auto-claude-code-research-in-sleep创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考