Software inventions have no housing to draw, so there are no exploded views or cross-sections to fall back on. The common failure mode is a single "system overview": a cloud labeled AI ENGINE with arrows pointing at a phone and a bank. The problem with that drawing is not aesthetics — an examiner cannot locate a single claim element in it.
Which figures a software case needs is not a taste question. You read it off the claims. This guide gives the full claim-to-diagram map, then works through four examples on a fictional payment fraud-scoring invention, each with a prompt you can paste into the PatentFig AI generator.
A method claim maps onto a flowchart one box per step, with numerals matching the specification.
Quick answer: claim type to figure type
| What the claim recites | Figure type | Core rule |
|---|---|---|
| A chain of method steps | Flowchart | One box per step, numerals match the spec |
| System units or modules | Block diagram | One box per element, labeled with the claim term |
| A data transformation chain | Data flow diagram | Only when the transformation itself is claimed |
| Message ordering between devices | Sequence diagram | Only when the ordering is claimed |
| Mode or state switching | State diagram | Only when transition conditions are claimed |
| A machine learning model | Training figure + inference figure | Always separate sheets, same numeral for the model |
| A user interface | UI line drawing | Never a raw screenshot; line art with callouts |
For the optional rows, the test is always the same: does this figure do a job that prose does badly? If yes, draw it. If it is decoration, cut it.
Example 1: method claim to flowchart
Fictional claim:
A method for scoring payment transactions, comprising: receiving a transaction request; extracting features from the transaction and an account history; computing a risk score with a trained scoring model; comparing the risk score against a threshold; and approving, declining, or routing the transaction to manual review based on the comparison.
Structure notes:
- Five steps, at least five boxes, top to bottom. No box for anything the claim does not recite — retry logic stays out until a claim mentions it.
- Number the steps 302, 304, 306... and use the same numerals in the spec paragraphs, so the examiner can walk between figure and text without a map.
- The threshold comparison is a decision. Draw it as a diamond with three exits (approve, decline, manual review). That branch is frequently where the invention lives; burying it in a rectangle wastes it.
- Steps added by dependent claims get their own detail figures: FIG. 2 for the main flow, FIG. 3 zooming into feature extraction.
Prompt:
Generate a USPTO-compliant black-and-white patent flowchart for a payment fraud scoring method. Steps: 302 receive a transaction request; 304 extract features from the transaction and the account history; 306 compute a risk score with a trained scoring model; 308 compare the risk score against a threshold, drawn as a decision diamond with three labeled exits: approve (310), decline (312), route to manual review (314). Rectangles for process steps, a diamond for the decision, single-column top-to-bottom layout, solid black lines, no shading, no color.
Example 2: system claim to block diagram
Fictional claim:
A transaction scoring system, comprising: an ingestion interface; a feature extraction module; a scoring engine; and a decision module coupled to the scoring engine.
Structure notes:
- One rectangle per claimed element, each carrying a reference numeral (102, 104, 106, 108).
- The label in each box matches the claim term exactly. The claim says "feature extraction module," so the box says feature extraction module — not enrichment-svc, which no examiner will decode.
- Connecting lines mean something: data flows one way, control signals another.
- The architecture slide from the pitch deck does not qualify. Patent figures are black-and-white line art: no logos, no gradients, no drop shadows.
Prompt:
Generate a patent-style system block diagram in black-and-white line art. System: a transaction scoring system with four modules: ingestion interface 102, feature extraction module 104, scoring engine 106, decision module 108. Data flows from 102 to 104 to 106 to 108. Draw each module as a solid-line rectangle containing its name and reference numeral, connect modules with solid arrows indicating data flow direction. No color, no shading, no icons.
Example 3: sequence diagram for multi-party interaction
Fictional claim (dependent):
wherein the scoring is performed by a scoring service, and wherein the method further comprises returning a default approval decision when the scoring service does not respond within a timeout period.
Structure notes:
- A handshake between a merchant gateway, a scoring service, and an issuing bank — with a timeout fallback — is nearly impossible to narrate in a flowchart and trivial to show as lifelines with arrows.
- Draw it only because the timeout path is claimed. If no claim depends on message ordering, skip the sequence diagram entirely.
Prompt:
Generate a patent-style sequence diagram in black-and-white line art. Participants as vertical lifelines: merchant gateway 120, scoring service 106, issuing bank 130. Messages in order: 120 sends a transaction request to 106; 106 returns a risk score to 120; 120 forwards an authorization request to 130. Add an alternative branch: if 106 does not respond within a timeout period, 120 applies a default approval decision and proceeds to 130. Label every arrow, mark the timeout branch clearly, solid black lines, no color.
Sequence diagrams earn their place when a claimed timeout or ordering is the point.
Example 4: ML claims need two figures, not one
Fictional claim (dependent):
wherein the scoring model is trained on labeled chargeback data, the training comprising assembling feature vectors from historical transactions and updating model parameters based on chargeback outcomes.
Structure notes:
- Training and inference never share a sheet. One figure shows the training pipeline; another shows the live scoring path. Collapsing them into one diagram leaves genuinely ambiguous whether the claims cover training the model, running it, or both — an ambiguity nobody wants surfacing during examination.
- The model carries the same numeral in both figures (scoring model 106 in each), so the reader knows it is one object doing different jobs. Training-only components take a separate numeral series (202, 204).
Prompt:
Generate a patent-style training pipeline flowchart in black-and-white line art. Flow: assemble feature vectors from historical transactions 202; label the vectors with chargeback outcomes 204; feed labeled data into the scoring model 106; update model parameters based on prediction error; check a stopping condition as a decision diamond, looping back if not met. Rectangles for steps, diamond for the stopping condition, reference numerals on every component, top-to-bottom layout, solid black lines, no color.
Generate the inference figure separately with the same approach, keeping the scoring model at numeral 106.
Before filing: the element mapping table
Once the figures exist, break every independent claim into elements and build a three-column table:
| Claim element | Reference numeral | Appears in |
|---|---|---|
| Ingestion interface | 102 | FIG. 1 |
| Feature extraction module | 104 | FIG. 1, FIG. 3 |
| Scoring engine | 106 | FIG. 1, FIG. 2, FIG. 5 |
| Decision module | 108 | FIG. 1, FIG. 2 |
| Training pipeline | 202 | FIG. 5 |
| Timeout fallback step | 314 | FIG. 2, FIG. 4 |
An empty cell means a missing figure or a limitation too vague to draw — both worth knowing before your attorney finds them. Run it backwards too: a numeral that appears in a figure but nowhere in the table and the spec is an orphan, the cheapest mistake to catch. The table starts life as the numeral register template at patentfig.ai/resources, with the part-name column swapped for claim language. Before filing, run the set through the Figure Checker for margins and numeral cross-consistency.
The legal footnote
In the U.S., claims need support in the specification under §112, and MPEP 2161 covers the written description requirement; drawings are part of that disclosure. Where the support line sits for a given claim is a legal call and attorney territory — no diagram tool changes that. But a claim element you cannot point to in any figure is a conversation worth having with your attorney early, not after a rejection.
On formalities, 37 CFR 1.84 and MPEP 608 govern line quality, numbering, and layout for U.S. filings.
FAQ
Does every flowchart box have to correspond to a claim step?
Every step recited in an independent claim should have a box — that is the floor. Extra boxes are fine when a detail figure expands one step's internals. The reverse is the problem: a claimed step with no figure to point to is a gap.
Can I file UI screenshots as drawings?
No. Screenshots go in as black-and-white line art with the color, branding, and decoration stripped out, and with lead lines and numerals on the claimed screen regions.
How many figures does a software patent usually need?
The claims decide; there is no fixed number. One or two figures each for method, system, and UI claims, plus two more (training and inference) when a model is claimed — five to eight is a common range. The count is not the goal; an address for every claim element is.
When do I need a sequence diagram or a data flow diagram?
Sequence diagram: when message ordering between devices is claimed. Data flow diagram: when the transformation chain itself (raw transaction to feature vector to score) backs up claim language. Neither is a default.
To try the claims-to-draft route, start at patentfig.ai/generate: paste the claim, fix the granularity over chat, and map every element before anyone files.
Top comments (0)