Paper2Patent turns a research paper into a Chinese patent draft

The problem is that nobody knows the rules

Paper2Patent is a tool for turning research results into patent applications, built from prompts and an AI Skill to help write Chinese invention patent application documents.

The reason it exists is stated plainly. A paper proves academic contribution and a patent protects technical results, but how to lay out the claims, how detailed the description has to be to count as sufficient disclosure, and what the rules for the drawings are, all have to be worked out from scratch by researchers.

The approach taken was to survey patent engineers at university research teams and corporate research institutes, and to organise the experience of converting papers into patents into templates and tools you can use directly. The stated output is a draft you can hand to a patent attorney for review.

That framing is the important one, and it shapes everything else in the project. This is not a patent filing system and it makes no claim to replace a professional. It is a generator of well-structured first drafts, with the legal judgement left where it belongs.

The drafting basis is stated explicitly, and it is current rather than historical. The work follows the Patent Law as amended in 2020, the Implementing Regulations as revised in 2023, and the Patent Examination Guidelines in the version effective from 1 January 2026.

The project is Python, MIT licensed, with the copyright held by 7toCR. There is a note that the project is welcome for free public use but that copying it into another repository and claiming it as original work is strictly forbidden, and that anyone referencing it should credit the original source and link back. The last push was on 2026-10-10 and there are no GitHub releases.

Four ways in, depending on what you need

The getting started table lists four routes, and the choice is about how much you want the tool to do and how much you want to run in your own chat window.

The paper2patent Skill is the recommended one and is for tools that support Skills, naming Codex, Claude, Claude Code and Cursor. Its output is Word and PDF application files, black and white drawings and a writing explanation document.

The paper to patent Flash prompt is for any large model chat and gives a quick first draft, with five sections of plain text. The Pro prompt is the fuller version, with more detailed drafting norms and self-checking, also as five sections of plain text. And the patent drawing generation route, which uses Gemini, is for when you already have patent text and want reference drawings out of it, producing drawing images.

The Skill is the interesting one, because it hands the whole process to the model. In tools that support Skills, you give it the entire flow of read the paper, judge the disclosure status, plan the claims, draft, draw the figures, check and generate the Word or PDF. The author mainly validated it in Codex, and it also works with Claude, Claude Code, Cursor and Windsurf.

The division of labour between the Skill and the prompts is explained in the prompt section. Those three templates are for generating plain text directly in a conversation. When you need Word or PDF files, normative drawings and automatic checking, the recommendation is to use the Skill above instead.

So the prompts are the lightweight path with no setup and no files, and the Skill is the one that produces deliverables.

Installing the Skill is a copy of a directory

Installation is a clone and a copy, and the copy is per tool.

git clone https://github.com/7toCR/paper2patent.git
cd paper2patent

The per-tool instructions are a table. For Codex, macOS and Linux use `cp -R skills/paper2patent ~/.codex/skills/` and on Windows a Copy-Item with the recursive and force flags into the user's .codex skills directory. For Claude Code the skill works directly inside the repository, with the .claude/skills/paper2patent path as a synchronised mirror, and to use it globally you copy it to ~/.claude/skills/. For the Claude desktop app and the web version you package skills/paper2patent/ as a zip and upload it in the settings. And for Cursor and Windsurf you use the project rules in .cursor/rules/ and .windsurf/rules/ and reference skills/paper2patent/.

The upgrade path is unusually explicit, and the reason is a real problem. The repository has no version number, so upgrading means a git pull and copying the files again. The instructions say to delete the old directory first and then copy, to avoid leftover files from files that have since been deleted.

git pull
rm -rf ~/.codex/skills/paper2patent && cp -R skills/paper2patent ~/.codex/skills/

The runtime requirements are listed too. Python 3.9 or newer is needed, drawing the figures needs Pillow and a Chinese font, either the fonts bundled with Windows or macOS or Noto CJK, with an environment variable PATENT_CJK_FONT to point at one, and exporting the PDF needs LibreOffice.

The separation of the code from the model is what makes that runtime list so short. There is no inference to run; the scripts are format checkers and document generators.

Six capabilities, and the fidelity rule is the important one

The capability table is six rows, and the third row is the one that decides whether you can trust the output.

The five application sections are the abstract, the abstract drawing, the claims, the description and the description drawings. The claims layout rule is that the independent claim carries only the necessary technical features, each dependent claim covers one mechanism, and the method, device, electronic equipment and storage medium come as a set.

Then the fidelity rule. Technical content comes only from the paper, information the paper does not give is marked as to be supplemented, and nothing is invented. The same rule appears again in the prompt as an absolute red line, where deep mining is explicitly not the same as creative extension: you must only extract information from the paper, you must not fabricate, modify or distort the original content, and if the paper does not mention a detail it is better to leave it out than to make it up.

For a tool that drafts legal text, that rule is the whole safety story. A hallucinated technical feature in a claim is not a small error, and the marked gaps are the mechanism that lets a reviewer see where the author needs to supply material.

The patent drawings are black and white line flowcharts and block diagrams, supporting branches, decisions, loops and drawing reference marks. The automatic checks cover banned words, single-sentence punctuation, reference relationships, reference basis, abstract word count and consistency between drawing numbers and drawing marks. And the risk and gap section covers disclosure and novelty, the subject-matter question for AI and algorithm inventions, the sufficient disclosure check and the list of materials still to be supplied.

So the tool produces a draft, a checklist of what is missing, and a set of warnings about the risk that the paper was already public.

The prompt encodes an examiner's reading order

The Flash prompt is the smaller of the two, and its structure is worth reading because it is a compressed version of the drafting method.

It opens with a role, the top patent attorney and patent engineer focused on turning core technology from frontier academic papers into a patentable Chinese invention application, and it emphasises extracting the technical solution from verbose academic expression.

Then the task, with the red line attached, and then what the prompt calls the patent logic constraints. The first of those is a three-element closed loop that must be clarified before drafting, and it is the framework the whole document hangs on. The difference point is what step distinguishes the current solution from the existing one. The technical problem is what the difference point solves. The technical effect is what the difference point achieves.

The second constraint is core extraction, where mathematical proofs, theoretical derivations and experimental data are stripped out and only the method, steps, flow and system structure that implement a function are kept as the core.

Then the formatting constraints, which are the mechanical part. The abstract has a fixed shape, name to field to solution to effect, and the punctuation rule is that the middle is separated by commas or semicolons and the ending has exactly one full stop. The claims are capped at ten, the independent claim is the name plus a brief statement of the method or function with the difference point in it, and the name must be exactly the same as the name in the abstract. Each dependent claim must reference an earlier one and the earlier claim must contain the feature being referenced, with a note about the reference basis. And there is a language ban on words such as and similar, approximately, preferably, may, for example and not limited to, plus a punctuation rule that each claim has exactly one full stop, at the end.

The description section is where the detail requirement sits, with the detailed description called the most important part and a requirement to answer four questions for each important step: what is it, what problem does it solve, how does it solve it, and what effect is achieved. Pasting the paper's own words is forbidden, and the text has to be rewritten into the step-by-step language of patent practice.

The document ends with a self-reflection protocol the model runs before producing output, a checklist of items covering content compliance, the three elements, banned claim words, claim punctuation, reference logic and implementation depth, with a forced revision until everything passes.

The skill packages the method as references and scripts

The directory listing of the skill is the clearest description of what the tool actually contains.

The top level is SKILL.md, which holds the workflow and the core rules, with .claude/skills/paper2patent/ as a synchronised mirror. Under references/ there are seven documents: patentability-and-disclosure.md for disclosure and novelty and the subject-matter and sufficient-disclosure questions, patent-drafting-standard.md for the drafting norms of the five sections and the paper-to-patent mapping and the sufficient disclosure check, claims-drafting.md for feature sorting, the hierarchy of dependent claims and wording rules, drawing-generation.md for the drawing norms and how to write nodes and edges, document-generation.md for the structured content format and the generation flow, input-requirements.md for input requirements and gap handling, and quality-checklist.md for the pre-delivery checklist.

Under scripts/ there are four Python programs: check_patent_draft.py for the automatic formal and scope checks, generate_patent_drawings.py for the black and white drawings in SVG and PNG, generate_patent_docx.py for the application document and the writing explanation as DOCX, and export_patent_pdf.py for PDF export and page-by-page preview. And there is assets/example_patent_content.json, a complete example of the structured content format.

The evals/ directory sits alongside the skill and holds an evaluation scheme with scoring criteria, a blind review process and structural check scripts. Having a blind review process is the detail that shows the project is trying to measure output quality rather than just ship prompts, and the scoring criteria plus a structural checker are the two halves of that.

The outputs are named clearly. There is a document file per name containing only the five sections of application text, each section starting on a new page, with the drawings labelled only as figure N. There is a separate writing explanation document for the applicant and the attorney to review, containing the list of materials to be supplied, the sufficient disclosure check, the disclosure and novelty risk, the claims layout with a mapping back to the paper, the drawing sources and the automatic check results. And there are the SVG and PNG files for each drawing.

Editorial conclusion

Adopt Paper2Patent if you need to convert a paper into a Chinese invention patent application and want a structured draft rather than a blank page, since the templates encode the section structure, the claim drafting rules and the self-check list. Skip it if you are not filing in China, since the whole thing is built around the Chinese Patent Law and its examination guidelines, and if you expect it to do legal judgement, since the output is explicitly a draft for an attorney to review. Verify first whether your paper has already been made public, because the tool itself flags that as a novelty risk, that you have the reference fonts and LibreOffice available if you want the drawings and PDF, and which model you are running the templates in, since the Flash and Pro prompts target different depths of output.

Frequently asked questions

Official sources

1. 7toCR/paper2patent on GitHub
2. Issues
3. License: MIT
4. README