Paper2patent

Paper2Patent

Convert a paper into a Chinese invention patent application draft that a patent attorney (专利代理师) can review and file with minimal rework. The output is a draft, not legal advice; say so once in the delivery message.

What good looks like

A strong draft does four things the paper itself does not:

1. Claims that define a protectable scope. Claim 1 contains exactly the features needed to solve the technical problem (the distinguishing features over the closest prior art) and nothing paper-specific that a competitor could trivially design around. Specific values, model names and optional modules move to dependent claims and embodiments.
2. A specification that enables and supports. A skilled person can reproduce the invention from the 具体实施方式 alone, and every claim term is explained there. For AI inventions this means the model's modules/layers/connections, training steps and parameters, and how inputs and outputs map to the application scene (专利审查指南, 2026-01-01 revision).
3. Technical character. The solution is framed as technical means solving a technical problem with a technical effect, so it is not rejected as 智力活动的规则和方法 (专利法第25条).
4. Complete fidelity. Every technical feature is traceable to the paper. Patent-style generalisation is allowed where the paper supports it; invention is not. Missing information becomes an explicit 【待补充：…】 placeholder, never a guess — added matter cannot be supported later and misrepresents the inventors' work.

Workflow

1. Intake

• Pick the mode: direct (default: draft everything, mark gaps), human-in-loop (confirm disclosure status, invention points and claim plan with the user before drafting), text-only (no files), claims-only, or review (check an existing draft against the paper).
• Read the whole paper: every section, equation, figure, caption, table and appendix. For a PDF, render the pages that contain the method figures and look at them; for text-only input, work from the figure descriptions and captions. The drawings must follow the paper's actual structure. See references/input-requirements.md for PDF handling and the minimum input.
• Establish the disclosure status (arXiv? accepted/published? public code? talk?) and dates. This decides whether the patent can still be novel. Read references/patentability-and-disclosure.md — every time, because the answer changes what you tell the user.

2. Source fact sheet (internal)

Before drafting, list the technical facts you will rely on, each with its location (§3.2, Eq. (4), Fig. 2, Table 3, Appendix B). Separate: (a) the paper's own contributions, (b) prior art the paper describes (related work, baselines), (c) experimental settings and results. This list is the backbone for fidelity, for support_map, and for the 背景技术 section. Do not show it to the user unless asked.

3. Invention mining and claim plan

Identify the closest prior art (usually the strongest baseline or the method the paper improves on), the distinguishing features, the technical problem they solve and the technical effect they produce. Then plan the claim tree before writing any claim: triage every candidate claim-1 feature (necessary / embodiment choice / interface detail), give each separable mechanism its own dependent claim (one fallback position per claim, never merged to save numbering), check that every branch of a generalised claim 1 is supported in the description, add the standard carrier claims, and record all of this in notes.claim_plan. Do not simply transcribe the paper's pipeline into claim 1. Read references/claims-drafting.md.

4. Draft the five parts

Follow references/patent-drafting-standard.md for the structure, content and language of each part, including the paper-to-patent mapping (what to keep, transform, or drop). Write in Simplified Chinese patent register: 本发明/本实施例, never 本文/我们/论文/作者. Keep technical clarifications (what a constraint or state actually means) in the text; move drafting remarks to the notes.

Then run the sufficiency audit (patent-drafting-standard.md §7): for every feature of claim 1 and the main dependent claims, check that the description states its data format, decision rule, failure handling and parameters. What the paper gives goes into the text; what it does not give goes into notes.sufficiency as a gap — never filled in by you. This audit is what produces a useful handover list; a draft that looks complete but hides its gaps is worse than one that names them.

5. Drawings

Design each figure as an explicit graph of nodes and edges taken from the paper's figures and method text. If the method checks, revises, retries or iterates, draw that loop (decision node + return edge) in the flowchart that illustrates claim 1, not just the success path. Read references/drawing-generation.md. A typical AI-method set: method flowchart (图1, also the 摘要附图), model/data-flow diagram redrawn from the paper's main figure, apparatus block diagram with reference numerals, electronic-device diagram.

6. Assemble, check, generate

Write the structured JSON described in references/document-generation.md (see assets/example_patent_content.json for a complete example). Then run, from the folder holding the JSON (<skill> = this skill's directory):

bashCopy code
python <skill>/scripts/check_patent_draft.py patent.json
python <skill>/scripts/generate_patent_drawings.py patent.json -o out --update-json
python <skill>/scripts/generate_patent_docx.py patent.json -o out/<名称>_专利申请文件.docx --require-drawings
python <skill>/scripts/export_patent_pdf.py out/<名称>_专利申请文件.docx -o out/<名称>_专利申请文件.pdf --preview-dir out/preview

• Fix every ERROR from the checker and judge every WARN; rerun until clean. The checker catches the formal defects (single period, uncertain words, dependency rules, antecedent basis, 300-character abstract, figure numbering, reference numerals) that are easy to miss when re-reading your own text, and warns about scope problems (code field names or negative limitations in claims, an over-long or enumeration-heavy claim 1, a revision loop that no drawing shows, drafting remarks in the description).
• Look at every generated drawing PNG and at the preview pages before delivering. Fix the JSON and regenerate if anything is cramped, wrong or unsupported.
• The DOCX step also writes <名称>_专利申请文件_撰写说明.docx: it opens with the handover checklist (every 【待补充】, notes.handover, plus ownership, disclosure date and prior-art search), followed by disclosure risk, claim plan, support map, drawing sources and check results. Keep all non-application content there, not in the application file.

Scripts need Python 3.9+. Pillow and a Chinese font are needed for drawings (the script refuses to render boxes-for-characters); LibreOffice for the PDF. If something is missing, install it or report the limitation — do not hand over drawings that show empty boxes.

7. Deliver

Give the user the files and a short message: the invention points claim 1 rests on, the claim structure (e.g. "方法1–6 + 装置7 + 设备8 + 介质9"), where the handover checklist is (first section of the 撰写说明) and its most important items, the disclosure/novelty assessment, and a reminder that a patent attorney should review the draft and run a prior-art search before filing. Do not paste the checklist or your analysis.

Rules that matter most

• Fidelity beats completeness. No invented modules, parameters, datasets, hardware, scenarios, effects or numbers. Generalise only along lines the paper itself supports (alternatives it mentions, ablations, a generic description of a component).
• Claims are definite: no 等、约、可以、例如、优选、不限于 and the like; one final 句号 per claim; dependent claims cite only earlier claims; terms introduced before "所述" is used.
• Captions under drawings are just "图1", "图2"; titles go in 附图说明. No figure number, title, colour or shading inside an image.
• The application text contains the technical disclosure only. Keep evidence boundaries the paper states; move remarks about the drafting, the paper or missing files into notes, and requests for material into notes.handover.
• Be honest about what the draft is: it organises and discloses the paper's invention; it does not add inventive substance, and it says nothing about the chance of grant.
• Keep one invention name (≤25 characters, no brand or model names) consistent across the abstract, claims and 说明书.
• Never store the user's paper, drafts or personal data in repository files.

Common requests