/patent-review

name: patent-review
description: "Get an external patent examiner review of a patent application. Use when user says \"专利审查\", \"patent review\", \"审查意见\", \"examiner review\", or wants critical feedback on patent claims and specification."
argument-hint: "[patent-directory-or-scope]"
allowed-tools: Bash(*), Read, Grep, Glob, Write, Edit, mcp__codex__codex, mcp__codex__codex-reply, mcp__antigravity__antigravity, mcp__antigravity__antigravity-reply, mcp__grok__grok, mcp__grok__grok-reply, mcp__claude-review__review, mcp__claude-review__review_reply, mcp__claude-review__review_start, mcp__claude-review__review_reply_start, mcp__claude-review__review_status

Patent Examiner Review via Codex MCP (xhigh reasoning)

> **Before each reviewer slot**, follow [Selectable Reviewers](../shared-references/reviewer-backends.md): > resolve invocation → `.aris/reviewer.json` → Claude Code default (Codex MCP) > with `reviewer_route.py` through the canonical helper resolver, preserving this > slot's tier, fresh contexts, source/image inputs and deterministic gates. > Codex examples/pins below apply only to `backend=codex`; other routes use their > own first-call/reply contract. Save the route and actual returned identity; > unavailable selections are `REVIEW_UNAVAILABLE`. Classify acceptance from actual > families/completion/scope. Forward invocation reviewer/model/effort overrides > to reviewer-bearing children. Generation workers are unchanged.

Get a multi-round patent examiner review of the patent application based on: **$ARGUMENTS**

Adapted from `/research-review`. The reviewer persona is a patent examiner, not a paper reviewer.

Constants

• `REVIEWER_MODEL = gpt-6-astra` — Model used via Codex MCP
• `REVIEW_ROUNDS = 2` — Number of review rounds
• `EXAMINER_PERSONA = "patent-examiner"` — GPT-6-Astra persona

Prerequisites

• Codex MCP Server configured:

  claude mcp add codex -s user -- python3 "$HOME/aris_repo/mcp-servers/codex-exec/server.py"   # your ARIS clone's path

Inputs

1. `patent/CLAIMS.md` — all drafted claims 2. `patent/specification/` — all specification sections 3. `patent/figures/numeral_index.md` — reference numeral mapping 4. `patent/PRIOR_ART_REPORT.md` — known prior art 5. `patent/INVENTION_DISCLOSURE.md` — invention structure

Workflow

Step 1: Gather Patent Context

Before calling the external reviewer, compile a comprehensive briefing: 1. Read all claims (independent + dependent) 2. Read specification sections (at least summary and detailed description) 3. Read prior art report for context 4. Identify: core inventive concept, claim scope, known prior art, target jurisdiction

Step 2: Round 1 — Full Examiner Review

Send to `REVIEWER_MODEL` via `mcp__codex__codex` with xhigh reasoning:

> Resolve this reviewer slot first; the following is the `backend=codex` example.

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are a senior patent examiner at the [USPTO/CNIPA/EPO].
    Examine this patent application and issue a detailed office action.

    CLAIMS:
    [all claims]

    SPECIFICATION SUMMARY:
    [key sections: title, technical field, background, summary, abstract]

    PRIOR ART KNOWN:
    [prior art references]

    PATENTABILITY STANDARDS TO APPLY:
    [US: 35 USC 101/102/103/112 | CN: Articles 22, 26 | EP: Articles 54, 56, 83, 84]

    Please issue an office action covering:

    1. CLAIM CLARITY (112(b)/Art 84):
       - Are all terms definite?
       - Any indefinite functional language?
       - Antecedent basis issues?

    2. WRITTEN DESCRIPTION (112(a)/Art 83 first para):
       - Does the spec support ALL claim scope?
       - Any claim elements without spec support?

    3. ENABLEMENT (112(a)/Art 83):
       - Can a POSITA practice the invention?
       - Any missing algorithm/structure for functional claims?

    4. NOVELTY (102/Art 54):
       - Would any known reference anticipate any claim?
       - Identify the closest single reference.

    5. NON-OBVIOUSNESS (103/Art 56):
       - Would any combination render claims obvious?
       - What is the motivation to combine?

    6. CLAIM SCOPE:
       - Are independent claims broad enough to be commercially valuable?
       - Do dependent claims provide meaningful fallback positions?
       - Any claims that are too broad (likely rejected) or too narrow (not valuable)?

    7. SPECIFICATION QUALITY:
       - Language issues (subjective terms, relative terms, result-to-be-achieved)
       - Reference numeral consistency
       - Missing embodiments

    Format your response as a formal office action with:
    - GROUNDS OF REJECTION for each issue (cite statute)
    - SUGGESTED AMENDMENTS for each issue
    - OVERALL PATENTABILITY SCORE: 1-10

    Be rigorous and specific. This is a real examination.

Step 3: Implement Fixes (Round 1)

Based on the examiner's office action:

1. **CRITICAL issues** (102 rejection, 112 indefiniteness, missing enablement):

• Must be fixed before proceeding
• Amend claims or add specification support

2. **MAJOR issues** (103 obviousness, weak claim scope, missing support):

• Should be fixed or argued
• Consider claim amendments or specification additions

3. **MINOR issues** (language quality, numeral consistency, formatting):

• Fix if time permits
• Document in output for later cleanup

For each fix:

• Show the specific change (old claim -> new claim)
• Explain how the fix addresses the examiner's concern

Step 4: Round 2 — Follow-Up Review

Use `mcp__codex__codex-reply` with the threadId from Round 1:

> Resolve this reviewer slot first; the following is the `backend=codex` example.

mcp__codex__codex-reply:
  threadId: [from Round 1]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    Here is the revised patent application after addressing your office action.

    CHANGES MADE:
    [list of all changes with rationale]