§ JOURNAL · Tutorial
AI Patent Draft Review Checklist: Find, Locate and Resolve Draft Defects
An actionable review note identifies a passage, explains the defect and records what must change. “Improve patent quality” gives the drafter little to work with. “Claim 1 introduces a wireless connection that is not described in disclosure D2; confirm the connection or remove the unsupported limitation” is a question someone can resolve.
This checklist is for reviewing a working US patent draft before handoff. It covers the relationship between source facts, claims, description and drawings. It is separate from choosing an AI drafting tool and from the DOCX export inspection. No checklist score establishes patentability, adequate disclosure or a successful examination outcome.
Use the US patent drafting guide for the overall document structure, then use this record to locate specific defects in the draft you actually received.
Download the blank US patent draft review record (Markdown). The file has blank source, defect and revision tables; no account is needed to download it. Downloading the blank form does not upload your technical material to Patent Task.
1. Establish what was actually disclosed
Identify the source packet before reading for polish. Keep its technical disclosure version, inventor notes, drawings and any substantiated observations together. Label unresolved questions explicitly. An AI-generated sentence does not become a source fact merely because it has been copied into the specification.
For each proposed technical feature, ask:
- Which source passage or drawing supports it?
- Does the source establish the relationship between the parts, rather than just name them?
- Is the statement a confirmed fact, an untested proposition or an unanswered question?
- Does a number, material, communication method or performance result appear for the first time in the draft?
If the packet is incomplete, use the invention disclosure template to collect the missing information. Do not ask a language model to supply a plausible technical answer so that a review row can be marked complete.
2. Use a small source packet to make defects visible
The following cabinet example, its source labels and all defective passages below are fictional teaching material created for this guide. They are not a client invention, a sample from a Patent Task drafting task, an experiment or a patentability assessment. The figure register is a text-only example; this article does not supply a drawing set.
| Source label | Information supplied for this example |
|---|---|
| D1 | A storage cabinet has a temperature sensor, a controller and a fan. |
| D2 | The controller starts the fan when the measured temperature rises above 35 °C and stops it when the temperature falls below 30 °C. |
| D3 | The inventor's note does not specify the sensor-to-controller communication connection or sensor construction. |
| F1 | The example figure register lists Figure 1 with sensor 22, controller 30 and fan 40. No Figure 2 or Figure 3 is provided. |
| Q1 | No temperature-accuracy or energy-consumption measurements are supplied. |
A reviewer should not infer that the sensor is wireless, that it is a thermistor, or that the assembly holds a particular accuracy. Those might be possible designs, but the packet does not confirm them.
3. Trace the claim limitations to their support
Read a claim as a combination of features and relationships. Record the exact wording, the source location and the passage in the draft that explains it. Use “not found” when appropriate, and distinguish missing source information from a poor explanation of information that was supplied.
MPEP 2163 explains the written-description inquiry in relation to the claimed invention. Locating a matching sentence is a useful review step, but it is not the complete legal inquiry. A sentence that merely repeats the proposed claim does not by itself resolve whether the disclosure is adequate.
| Draft location | Constructed defective passage | Identified problem | Direction for correction |
|---|---|---|---|
| Claim 1, sensor limitation | “a wireless temperature sensor” | D1–D3 do not identify a wireless connection | Ask for the actual connection; remove or revise the unsupported characterization unless confirmed |
| Claim 1, controller limitation | “maintains the cabinet at 25 °C ±1 °C” | D2 describes switching thresholds, and Q1 supplies no accuracy result | Return to the disclosed control behavior; do not invent an accuracy measurement |
| Claim 2, reference to a component | “the second temperature sensor” | No second sensor has been introduced in the example claim set or source packet | Determine the intended referent and technical basis before correcting the wording |
| Claim 3, dependency | “The cabinet of claim 3...” | The claim refers to itself | Identify the intended earlier claim, confirm inherited limitations and recheck the dependent claim as a whole |
For a longer worked support map, use the patent claims example and its separate claim-support worksheet. This review record is broader: it also tracks cross-document defects and whether a proposed correction survived rechecking.
4. Check meaning across the description and drawings
Compare terminology and relationships, not just spelling. Two different components may legitimately need different names; one component should not drift between names in a way that obscures its role.
MPEP 608.01(o) discusses how claim terminology is explained in the description. MPEP 608 also addresses drawing-reference consistency. These are reasons to read the documents together, not a requirement to make every sentence an exact copy of claim wording. See MPEP 608.
| Location in the fictional draft | Concrete defect | What to resolve | Locations to recheck |
|---|---|---|---|
| Description [0012] | It calls the temperature sensor “24,” while F1 identifies it as 22 | Confirm that both references mean the same component, then align them | Claims where relevant, description, figure register and the actual drawing when supplied |
| Description [0018] | It says the fan stops above 35 °C | The direction contradicts D2; check and restore the disclosed control sequence | Operation, summary, abstract and any flowchart |
| Brief description of drawings | It describes a sectional Figure 3 that is not supplied | Determine whether the reference is wrong or a necessary view is missing | Figure inventory, body references and final drawing set |
| Summary | It asserts “40% lower energy consumption” | Q1 contains no energy measurements | Remove the unsupported result or obtain and accurately describe the real supporting information |
When a figure is missing, leave a visible question. Do not create a view solely to make the inventory look complete if the underlying structure is unknown. The drawing-description guide explains how to describe the views actually available.
When the description is too thin to explain a supplied relationship, expand from confirmed facts. The detailed-description example can help organize that explanation. It cannot supply the missing design of a real invention.
5. Separate ambiguous wording from legal conclusions
Flag a phrase such as “the second sensor” with its context and possible referents. Do not automatically label every terminology mismatch an invalid claim. MPEP 2173.05(e) explains that a missing explicit antecedent is not always enough to make a claim indefinite; interpretation depends on the claim and the relevant context. See MPEP 2173.
The reviewer's immediate task is to make the question inspectable: identify where the term first appears, what the description says and why a reader might be uncertain. The antecedent-basis guide gives focused examples. Decisions about claim scope and legal sufficiency require the responsible patent professional's judgment.
Likewise, treat prior-art references as sources to inspect, not as invented citations. Record which document and passage were actually reviewed and what question they raise. This checklist does not perform a novelty, obviousness or freedom-to-operate analysis.
6. Resolve each issue with an accountable change
For every defect, record the original passage, proposed revision, supporting source, decision owner and affected locations. Use a status such as “open,” “awaiting technical confirmation,” “revised—recheck pending” or “checked on identified version.”
An acceptable resolution is more specific than “AI fixed it.” In the fictional [0018] example, the reviewer can point to D2, restore the start/stop relationship and name the revised file. For the unsupported wireless connection, the issue may remain open until the inventor answers. Deleting an unresolved limitation is also a scope decision that should be reviewed, not an automatic editing rule.
For an already-filed application, identify the application-as-filed material and obtain appropriate professional review before making changes. Adding new facts to a working draft and amending an existing application are different situations; this article does not prescribe an amendment or an office-action response.
7. Recheck the revision, not the memory of the fix
Open the identified revised version and revisit the exact location. Then follow the change through related passages. If the fan's stop condition changed, read the claims, detailed operation, summary, abstract and any related drawing description again.
Use a short sequence:
- Confirm that the intended change is present in the saved draft.
- Check it against the cited source, including thresholds, units and relationships.
- Inspect related claims and sections for contradictions introduced or left behind.
- Inspect the exported document separately if it is part of the handoff.
- Close the issue only for the version checked; keep unanswered technical questions open.
Recheck the summary and abstract after substantive edits. They can retain an old result or operating sequence even when the detailed description has been corrected.
The final handoff should identify the reviewed draft and its unresolved questions. It should not convert the number of completed checklist rows into a quality score or a prediction of grant.
Put the review into the drafting workflow
The US patent drafting workspace introduction shows how technical input becomes an editable working draft. Use your own confirmed disclosure, keep source locations visible and apply the review record to the actual text produced. Access to generation and export depends on the product and purchase conditions; the blank review record is available independently.
Official sources were checked on October 20, 2026. This is a drafting review method, not a claim that a particular draft has received professional approval or satisfied every US requirement.