GUI Design Patent Drawings: 7 Critical Rules for 2026

A screen design can be the most valuable thing a software company owns, and the fastest thing to lose. The reason is rarely the idea. It is the sheet of paper. GUI design patent drawings are not illustrations that accompany the claim — under U.S. practice they are the claim, and every line you draw solid instead of broken narrows what a competitor has to copy before you can sue.

Rule 1: GUI Design Patent Drawings Must Show an Article of Manufacture

Get the line types wrong and you either claim a screen bezel nobody will ever infringe, or you claim so little that the design falls to the prior art. There is no middle ground to retreat to afterwards, because the figures are fixed at filing.

What follows are the seven rules that decide whether a filing survives examination and stays worth enforcing: the article-of-manufacture requirement in MPEP 1504.01(a), the broken-line rules in 37 CFR 1.152, the sheet standards in 37 CFR 1.84, how to handle animated interfaces, and why Europe sends this work somewhere other than the EPO. Each one of them has, at some point, cost a real applicant a real filing date or a real claim scope.

35 U.S.C. 171 allows a patent for a new, original and ornamental design for an article of manufacture. Those last four words do all the work. An icon floating on a blank sheet is, in the USPTO’s own words, a two-dimensional image that alone is surface ornamentation — and surface ornamentation by itself is not an article of manufacture.

MPEP 1504.01(a) resolves this by requiring that the computer-generated icon or graphical user interface be shown embodied in and applied to a programmed computer — a display screen, monitor, display panel, or a portion of one. That is why GUI design patent drawings look the way they do: the interface sits inside the outline of a screen rather than alone on the page.

The claim title has to match. MPEP 1504.01(a) directs that the title designate a particular article of manufacture, so “computer screen with icon” is acceptable where a bare “computer icon” is not. Examiners issue 35 U.S.C. 171 rejections on this point routinely, and the fix is almost always a title amendment plus corrected sheets.

• Acceptable: “Display screen with graphical user interface” or “Computer screen with icon.”
• Rejected: “Computer icon,” “Graphical user interface” standing alone, or a title naming only software.
• Practical tip: keep the title, the claim and the figure descriptions consistent — a mismatch between them is its own objection.

Rule 2: Broken Lines Decide How Much You Actually Own

This is the single highest-leverage decision in the whole file. 37 CFR 1.152 permits broken lines to show visible environmental structure, but forbids using them to show hidden planes and surfaces that cannot be seen through opaque materials. Anything drawn in broken lines forms no part of the claimed design.

Applied to a screen, the logic is simple and unforgiving. Draw the display outline in broken lines and you have disclaimed the hardware — your design reads on the interface whether it appears on a phone, a laptop or a car dashboard.

Draw that same outline in solid lines and you have claimed the screen shape too, which means a competitor running an identical interface on a differently-shaped device does not infringe. That is a real and frequently fatal narrowing, and it is invisible to anyone reading the claim text alone, because in a design case there is essentially no claim text to read.

The same choice applies inside the interface. Solid-line elements are claimed; broken-line elements are context. Most experienced filers claim only the elements that carry the visual identity — the distinctive control, the characteristic layout — and put the surrounding chrome in broken lines. It is worth noting that MPEP 1504.01(a) expressly permits the display article to be shown in either solid or broken lines, so this is a strategic choice, not a formal requirement.

One trap catches people who are used to utility figures. 37 CFR 1.152 does not permit alternate positions of a design component shown by full and broken lines in the same view. If you want to show a control in two states, use separate views, not one view with both positions overlaid.

Rule 3: 37 CFR 1.84 Still Governs the Sheet Itself

37 CFR 1.152 does not replace the general drawing standards — it incorporates them. The design must be represented by a drawing that complies with 37 CFR 1.84, which means the ordinary rules on sheet size, margins, line quality, lettering and the numbering of views all apply to a GUI filing exactly as they apply to a mechanical one.

• Line quality — lines must be durable, clean, black and sufficiently dense and dark, uniformly thick and well defined. Anti-aliased screenshot edges are a common failure point.
• Numbering of views — views are numbered consecutively as “FIG. 1”, “FIG. 2”, and so on.
• Colour — colour drawings require a petition and the fee set by 37 CFR 1.84(a)(2). Do not assume a colour interface can simply be filed in colour.
• Photographs — under 37 CFR 1.84(b) photographs are not ordinarily permitted. 37 CFR 1.152 adds that photographs and ink drawings may not be combined as formal drawings in one application, and that any photograph filed in lieu of an ink drawing must not disclose environmental structure.

The shading rule is easy to overlook and expensive to get wrong. 37 CFR 1.152 says appropriate and adequate surface shading should be used to show the character or contour of the surfaces represented, and that solid black surface shading is not permitted except to represent the colour black or colour contrast. A flat dark interface element rendered as a solid black fill will draw an objection unless it is genuinely claiming black.

Rule 4: A Complete Disclosure Means Enough Views, Not Every View

37 CFR 1.152 requires a sufficient number of views to constitute a complete disclosure of the appearance of the design. For a physical product that usually means six orthographic views plus a perspective. For a screen design it usually means far fewer — often a single front view, because the back and sides of a display panel contribute nothing to a claimed interface.

Where filers get into trouble is the opposite direction: submitting a dozen screenshots of an entire application flow and calling it one design. Each visually distinct interface is generally its own design. Bundling them invites a restriction requirement, and responding to that costs more than filing them properly in the first place.

A useful discipline before you draw anything: decide what the design is. One screen state, or a transition? One control, or the whole layout? That single answer determines the number of applications, the number of views and the line types on every sheet.

Rule 5: Animated Interfaces Need Views Plus a Descriptive Statement

Changeable and animated interfaces are handled by showing the sequence rather than the motion. You file the images that make up the sequence as separate views, and you add a descriptive statement explaining their relationship.

MPEP 1504.01(a) contemplates a statement along the lines that the process or period in which one image transitions to another image forms no part of the claimed design. Without it, an examiner cannot tell whether you are claiming two designs, one design in two states, or the motion between them — and the ambiguity becomes a rejection.

Keep the sequence tight. Two or three views that capture the beginning, a meaningful middle and the end of the transition are usually enough. Twenty frames of the same animation add cost and give an infringer more detail to design around.

Rule 6: Europe Does Not Route Screen Designs Through the EPO

Filers regularly ask which EPO rule covers GUI design patent drawings. None of them do — the European Patent Office grants patents for inventions, not design rights. Screen and icon designs in Europe are registered designs, filed with the EUIPO for EU-wide protection or with a national office, and they use their own representation standards rather than the patent drawing rules.

There is a related point worth stating precisely, because a great deal of published guidance is now out of date on it. Rule 46 EPC, which used to set out the form of the drawings for European patent applications, was deleted with effect from 1 February 2023. Those presentation requirements were moved out of the Implementing Regulations and into a Decision of the President of the EPO, with Rule 49 EPC now carrying the general provision. If you are reading an article that cites Rule 46 EPC as live law for drawings, it predates that change.

The practical takeaway for a software company filing on both sides of the Atlantic: your U.S. design filing and your EU registered design are separate exercises with separate drawing standards, and the U.S. broken-line strategy does not transfer automatically. Plan the disclaimers jointly before either one is filed, because what you disclose first can limit what you can claim later.

Choosing Between the Design Route and the Utility Route

Before you commission GUI design patent drawings at all, it is worth confirming the design route is the right one. The two routes protect genuinely different things, and interface work often justifies both.

A design filing protects appearance. It is comparatively quick, comparatively cheap, and it bites hard against a competitor who copies the look of your product. What it cannot reach is a rival who implements the same underlying behaviour behind a visually different interface.

A utility filing protects the function — the data flow, the state machine, the method the interface carries out. Its figures are a different species entirely: block diagrams and flowcharts under 37 CFR 1.83(a), where every feature specified in the claims must be shown. Those figures explain a system; GUI design patent drawings define an appearance.

• File a design when the visual identity is the asset and copying would be visible on a screenshot.
• File a utility application when the value sits in what the interface does rather than how it looks.
• File both for a flagship product — and keep the two figure sets consistent, because inconsistent disclosures between related filings give an opponent something to work with.

One sequencing note that saves money: decide the broken-line strategy for the design case before the utility figures are finalised. It is far easier to keep the two consistent from the start than to reconcile them after both have been drawn.

Rule 7: The Objections That Cost the Most Time

Most design office actions on screen designs come from a short list. In practice these are the ones that recur:

1. No article of manufacture — the icon is shown alone. Rejected under 35 U.S.C. 171; fixed with corrected sheets showing a display and a matching title.
2. Inconsistent line types between views — an element solid in FIG. 1 and broken in FIG. 2. The examiner cannot tell what is claimed.
3. Screenshot artefacts — gradients, anti-aliasing and drop shadows exported straight from a design tool rarely satisfy the line-quality requirement of 37 CFR 1.84.
4. Solid black fills — used for a dark UI element rather than to claim the colour black, contrary to 37 CFR 1.152.
5. Unexplained animation frames — multiple views with no descriptive statement tying them together.
6. New matter on correction — redrawing a figure and adding detail that was not in the original disclosure. Corrected drawings may clarify; they may not add.

The last one deserves emphasis. Because the drawing is the claim in a design case, a correction that adds a line adds subject matter. That is why it pays to get the line types right on filing rather than planning to tidy them up later — the option to tidy them up may not exist.

How PerspireIP Can Help

PerspireIP prepares design and utility figure sets that clear formalities the first time. For screen designs that means deciding the solid/broken line strategy with your counsel before anything is drawn, building each view to 37 CFR 1.84 and 37 CFR 1.152, and delivering camera-ready sheets your attorney can file without redrawing. See our patent drawing services, or talk to us about a filing.

Related reading: design patent drawings, patent drawings for software inventions, utility vs design patent drawings and choosing your patent drawing views.

This article is general information, not legal advice; consult a qualified attorney for your situation.

Frequently Asked Questions