Patent Drawings for Software Inventions: 7 Proven Rules

Every software application eventually reaches the same awkward moment: the claims recite a method, the specification recites modules, and someone has to decide what any of it actually looks like on a sheet of paper. Patent drawings for software inventions are the part of the filing that attorneys most often treat as an afterthought and examiners most often object to. That is a costly ordering. Under 37 CFR 1.83(a), the drawing must show every feature specified in the claims — so a figure set that omits a claimed step is not a cosmetic problem, it is a disclosure problem that surfaces after you have already paid the filing fee.

Why Patent Drawings for Software Inventions Are Rarely Optional

The statutory hook is 35 U.S.C. 113, implemented by 37 CFR 1.81(a): an applicant “is required to furnish a drawing of the invention where necessary for the understanding of the subject matter sought to be patented.” Practitioners sometimes read “where necessary” as an escape hatch for software. It is not one in practice.

Two provisions close the gap. First, 37 CFR 1.81(b) expressly contemplates “illustrations which facilitate an understanding of the invention (for example, flow sheets in cases of processes, and diagrammatic views)” — which is precisely what a computer-implemented method is. Second, MPEP 608.01 tells examiners to object when flowcharts and diagrams appear inside the descriptive text of the specification rather than in the formal drawings, because 37 CFR 1.58(a) permits only tables and chemical or mathematical formulas to sit in the specification in lieu of drawings.

The practical consequence: pasting your architecture diagram into the written description does not satisfy the drawing requirement. It creates an objection. The figure has to be a numbered figure on a proper drawing sheet.

There is a second, quieter reason to take the figures seriously. In a §101 dispute, a well-built block diagram that ties claimed functions to specific hardware and data flows is the fastest way to show that the claim is directed to a concrete implementation rather than a result. The drawings are read long before the argument is.

The Labeled Rectangular Box Is Authorized by Rule, Not by Custom

The single most useful sentence in the drawing rules for software practitioners is the second sentence of 37 CFR 1.83(a):

The drawing in a nonprovisional application must show every feature of the invention specified in the claims. However, conventional features disclosed in the description and claims, where their detailed illustration is not essential for a proper understanding of the invention, should be illustrated in the drawing in the form of a graphical drawing symbol or a labeled representation (e.g., a labeled rectangular box).

37 CFR 1.83(a)

That parenthetical — a labeled rectangular box — is the regulatory authority for the block diagram. You do not have to draw the internal circuitry of a processor, a network interface, or a database. You label the box and identify it in the specification. 37 CFR 1.84(n) reinforces the point: graphical drawing symbols may be used for conventional elements, provided the elements they represent “must be adequately identified in the specification.”

The constraint that bites is the first sentence, not the second. Every claimed feature must appear. Run the exercise literally: take each independent claim, break it into its elements, and point to the figure and reference numeral that carries each one. If a claim recites “determining a confidence score,” there must be a step box for it. Claims amended during prosecution are the usual source of failure here, because the figures were frozen at filing and nobody revisited them.

Note the closing instruction in the same rule as well: tables in the specification and sequences in a sequence listing should not be duplicated in the drawings. Machine-learning applications that reproduce training-data tables as figures collect an objection for exactly this reason.

Four Figure Types That Carry a Software Filing

A defensible software figure set is rarely one drawing repeated in variations. It is usually four kinds of figure doing four different jobs:

1. The system block diagram. Hardware and network context — client devices, servers, data stores, interfaces. This is the figure that anchors the claim to a machine, and it is where labeled rectangular boxes belong.
2. The method flowchart. One box per claimed step, in claimed order, with decision diamonds where the claim recites a condition. This is the ‘flow sheet in cases of processes’ that 37 CFR 1.81(b) names directly.
3. The data-structure or timing diagram. Message sequences, packet formats, record layouts. Essential when the claim recites an ordering or a format rather than a computation.
4. The screen display or GUI figure. What the user actually sees. Useful in a utility filing as context, and potentially claimable in a separate design application.

A common and avoidable mistake is drawing the flowchart at the level of the specification rather than the level of the claims. The specification may describe thirty steps; the independent claim may recite six. Both matter, but the six must be individually identifiable, and a reviewer should be able to walk the claim through the figure without interpretation.

For a fuller treatment of how these categories map onto utility and design filings, see our guide to patent drawing types.

The 37 CFR 1.84 Standards That Catch Software Figures

37 CFR 1.84 is written for mechanical drawings, and software figures fail it in a predictable handful of places. These are the subsections worth checking before filing:

• 1.84(o) — legends. “Suitable descriptive legends may be used subject to approval by the Office… They should contain as few words as possible.” Boxes labeled with a full sentence of pseudocode invite an objection. Label the box tersely and put the detail in the specification.
• 1.84(p) — reference characters. Reference numerals must be consistent between the drawings and the specification, must not be used in the description without appearing in the drawings, and must be at least 0.32 cm (1/8 inch) high per 1.84(p)(3).
• 1.84(l) — character of lines. Every line must be durable, clean, black and sufficiently dense. Screenshots exported at low resolution and diagrams with grey connector lines are the two most frequent failures in software cases.
• 1.84(u) — numbering of views. Views are numbered consecutively in Arabic numerals, and a multi-sheet flowchart split across pages needs correct continuation labeling rather than an unnumbered second page.
• 1.84(g) — margins. Sheets must carry the required margins with no printed matter inside them. Auto-exported diagramming-tool output routinely runs into the margin.
• 1.84(n) — symbols. Conventional elements may be represented by graphical symbols, but whatever the symbol stands for has to be identified in the specification.

None of these are hard to satisfy. They are simply not what diagramming software optimizes for, which is why exporting a slide deck directly into a filing is the origin of so many drawing objections. Our breakdown of the USPTO drawing requirements under 37 CFR 1.84 walks each subsection in detail, and the catalogue of patent drawing mistakes that trigger office actions covers what happens when they are missed.

Screen Displays, Icons and the 37 CFR 1.152 Design Route

A utility patent protects what the software does. It does not protect what the interface looks like. For the interface, the vehicle is a design patent, and the drawing rule changes: 37 CFR 1.152 requires that “the design must be represented by a drawing that complies with the requirements of § 1.84” (see 37 CFR 1.152) and that it “contain a sufficient number of views to constitute a complete disclosure of the appearance of the design.”

For a graphical user interface or an icon, MPEP 1504.01(a) adds the article-of-manufacture requirement of 35 U.S.C. 171. A computer icon or GUI is eligible only if the drawings disclose the design as embodied in an article — in practice, shown on a display screen, monitor or other display panel, with a title such as “display panel with graphical user interface.”

The drafting technique that follows is claim scope, not decoration. The display panel is drawn in broken lines so that the screen itself forms no part of the claimed design; the claimed interface elements are drawn in solid lines. Move an element between broken and solid lines and you have changed the scope of the patent. That is why design figures for software should never be redrawn casually after filing.

In a utility filing, the same screenshot serves a different purpose: it is context for the claimed method, and it is subject to 1.84 like any other figure — black lines, numbered views, reference numerals for the elements the specification discusses. If you are weighing the two routes, our comparison of utility versus design patent drawings sets out where the requirements diverge.

Filing Abroad: EPO Practice After Rule 46 EPC, and PCT Rule 11

Two points of European practice are commonly stated incorrectly, and both matter for software figures.

First, Rule 46 EPC no longer exists. Rule 46 EPC — the provision on the form of the drawings — together with Rule 49(3) to (12) EPC, was deleted with effect from 1 February 2023 as part of the EPO’s digital-transformation package. The form requirements did not disappear; they moved into a Decision of the President of the EPO issued under Rule 49(2) EPC and published in the Official Journal, which lets the EPO change presentation rules without amending the Implementing Regulations. Any drawing guide still citing “Rule 46 EPC” as live law is out of date, and several widely-circulated ones are.

Second, colour is now possible at the EPO but not under the PCT. Since 1 October 2025 the EPO accepts drawings filed electronically in colour or greyscale, provided they are contrast-rich and clear at 300 dpi; the description, claims and abstract remain black and white. PCT practice is unchanged — PCT Rule 11.13(a) still requires drawings in durable black lines “without colorings.” Filing a colour heat-map or a colour-coded architecture diagram in an international application is therefore still a defect, even though the same figure is now acceptable on a direct European filing.

Text inside boxes is the other European trap. PCT Rule 11.11(a) permits no text matter in drawings except a single word or words when absolutely indispensable — and, specifically for electric circuits and block schematic or flow sheet diagrams, “a few short catchwords indispensable for understanding.” That carve-out exists for exactly the figures software applications rely on, but it is a carve-out for catchwords, not for prose. The EPO also expects reference signs used in the drawings to be carried into the claims in parentheses under Rule 43(7) EPC.

Our jurisdiction-specific guides cover this in depth: EPO drawing requirements and PCT drawing requirements.

A Pre-Filing Checklist for Patent Drawings for Software Inventions

Before the application goes out, walk this list. It takes minutes and catches most of what examiners raise:

1. Map every element of every independent claim to a reference numeral in a figure. 37 CFR 1.83(a) is a per-feature test, not a general impression.
2. Confirm no flowchart or diagram sits inside the specification text where a numbered figure should be.
3. Check reference numerals in both directions — nothing in the drawings that is unexplained in the specification, nothing in the specification that is missing from the drawings.
4. Reduce every box label to the fewest words that identify it, and move the explanation into the description.
5. Export at high resolution in pure black lines; check margins, view numbering and 1/8-inch character height.
6. If a GUI is part of the commercial value, decide now whether a parallel design application under 37 CFR 1.152 is worth filing, and get the broken-line convention right the first time.
7. For international filings, strip colour for the PCT even if the EPO would now accept it, and keep in-figure text to catchwords.

Where prosecution amends the claims, repeat step one. Amended claims with unamended figures are the most common route to a 37 CFR 1.83(a) objection late in a case, and correcting drawings after allowance is slower and more expensive than getting them right at filing.

Draft Software Figures That Survive Examination

PerspireIP prepares USPTO-, EPO- and PCT-compliant figures for computer-implemented inventions — system block diagrams, method flowcharts, sequence diagrams and GUI figures — mapped element by element against your claims. See our patent drawing services or contact our team to have an existing figure set reviewed against 37 CFR 1.83 and 1.84 before you file.

Frequently Asked Questions