User interface patent drawings are formal illustrations that visually disclose the screens, elements, and interaction states of a software invention. They must clearly show each GUI component, its layout, and any transitional states, using solid and broken lines to distinguish claimed features from context, so an examiner can understand the interface without reading the specification.

What Makes User Interface Patent Drawings Different

Unlike mechanical or electrical patent figures, GUI patent figures depict visual output on a display. The drawings usually represent what a user sees on a screen at a given moment, plus how the screen changes when the user taps, swipes, selects, or enters data. Patent offices such as the USPTO and EPO accept these drawings, but they impose specific rules: no color unless a petition is granted, no photographs, and clear line art that reproduces well in black and white.

Software patent illustrations for interfaces typically fall into three categories:

  • Single static screen – one drawing showing the complete interface in a resting state.
  • Sequence of screens – several figures showing the interface before, during, and after a user interaction.
  • Partial screen with broken lines – the claimed portion is drawn in solid lines, while the surrounding context appears in broken lines.

How to Prepare User Interface Patent Drawings Step by Step

Step 1: Identify the Claimed Features

Read the claims and mark every interface element that must appear in the figures. If a claim recites a button, a slider, a notification badge, or a particular arrangement, that element must be visible in at least one drawing. Do not rely on the written description alone; the figures are part of the disclosure.

Step 2: Choose Solid and Broken Lines Deliberately

In most jurisdictions, solid lines show the claimed subject matter, while broken or dashed lines show environment or context. For interface screen drawings, this often means drawing the entire phone or monitor in broken lines and the specific UI panel or interaction element in solid lines. Label each figure with a brief description such as “FIG. 3 is a front view of a user interface screen showing the claimed notification panel.”

Step 3: Draft the Screen Layout

Create a clean, grayscale, vector-based representation of the screen. Use consistent spacing, readable fonts, and recognizable icons. Avoid screenshots, photographs, and color. If a color is functionally important, file a petition for color drawings and include a black-and-white version as well.

Step 4: Number Every Element

Assign reference numerals to each component that appears in the claims or the detailed description. Use leader lines that touch the element without crossing other lines. Keep numbering consistent across all figures: the same element must carry the same numeral in every drawing.

Step 5: Show Interaction States

If the invention covers a transition, such as a menu expanding or a drag-and-drop action, include at least two figures: one showing the initial state and one showing the resulting state. Arrows may indicate movement, but the arrow itself should not obscure the elements being moved. Some applicants add a third figure for an intermediate state when the transition is complex.

Step 6: Add Figure Descriptions

Write a brief description for each figure in the specification. Example: “FIG. 4 illustrates a user interface screen after a user selects the share icon, showing a share sheet overlaying the content.” These descriptions anchor the drawings to the written disclosure.

Step 7: Review Against Office Rules

Check line thickness, margins, sheet size, and numbering against the rules of the target patent office. The USPTO requires A4 or letter size, specific margins, and legible line art. EPO practice for GUI figures is similar but has its own formal requirements.

Concrete Example: A Swipe-to-Archive Interface

Imagine an email application with a swipe gesture that archives a message. The claims recite a list of message rows, a swipe gesture, and an archive indicator that appears as the user swipes left.

The drawing set could include:

  • FIG. 1: A mobile device in broken lines, with the email list in solid lines showing three message rows and a partially revealed archive icon behind the first row.
  • FIG. 2: The same screen after the swipe is complete, with the message row removed and an “Archived” confirmation banner at the top.
  • FIG. 3: An enlarged view of one message row, showing the archive icon, the row boundary, and the swipe direction arrow.

Each element—the row, the icon, the banner—gets a reference numeral. The device frame, status bar, and background are in broken lines. This set communicates the visual appearance and the interaction without requiring a working prototype.

Common Mistakes in User Interface Patent Drawings

One of the most frequent errors is using screenshots or color mockups. Examiners reject these because they do not reproduce cleanly and may introduce unintended limitations.

Other recurring problems include:

  • Inconsistent reference numerals: An element labeled 210 in one figure appears as 310 in another.
  • Missing interaction states: The claims describe a transition, but the figures show only a static screen.
  • Overcrowded screens: Too many elements on one sheet make the drawing illegible when reduced to patent publication size.
  • Wrong line types: Using solid lines for context or broken lines for claimed elements can change the scope of protection.
  • Unlabeled icons: An icon that is central to the claim must be clearly drawn and numbered, not left as a vague square.

Checklist for Examiner-Ready GUI Patent Figures

  1. Every claimed feature appears in solid lines in at least one figure.
  2. Environment and context appear in broken lines.
  3. All elements have consistent reference numerals across figures.
  4. Each figure has a one-sentence description in the specification.
  5. No color, screenshots, or photographs unless specifically permitted.
  6. Interaction states are shown for any claimed transition or animation.
  7. Line art is clean, vector-based, and legible at reduced size.
  8. Margins, sheet size, and numbering comply with the target office.

Tools like PatentDraw can speed up the drafting process by generating consistent vector-style software patent illustrations from written descriptions, but the output is a working draft. A patent professional should review every figure against the claims and office rules before filing.

Frequently asked questions

Can patent drawings for user interfaces include color?

Generally no. The USPTO and EPO require black-and-white line drawings unless color is necessary to disclose the invention. If color is essential, you must file a petition, explain why color is required, and submit both color and black-and-white versions.

How many figures do I need for a UI patent application?

There is no fixed number. Use as many figures as needed to clearly disclose every claimed screen and interaction state. Simple static interfaces may need one or two figures, while complex multi-step interactions often require four to eight figures.

Are screenshots acceptable as user interface patent drawings?

Screenshots are generally not acceptable because they are photographs, may include color, and do not reproduce clearly. Instead, create clean line art that traces the relevant screen elements, showing the claimed features in solid lines and context in broken lines.

Turn this idea into a clear patent figure

Describe your invention and create a focused working draft in PatentDraw.

Create a drawing