Patent Flowcharts: Build a Diagram That Matches the Method

A patent flowchart should help a reader follow the method described in the application draft. Start from the confirmed process rather than asking a drawing tool to invent a sequence from a title. The method below is an editorial preparation workflow, not a test of patentability or a claim-drafting opinion.

Distinguish a flowchart from a block diagram

Use a flowchart when the question is about actions and decisions. Use a block diagram when the question is about components and connections. A system can need both: one diagram identifies modules, while another explains what happens to data as the modules operate.

Do not add a flowchart solely to make a document longer. Identify the ambiguity it resolves, then check whether the diagram and prose resolve it the same way. The USPTO application overview explains the role of drawings, including their usefulness for some processes.

Work through a synthetic example

Consider a fictional sensor that collects a reading, checks whether it is valid and then stores or discards it. This is a teaching example, not an assertion that the process is new or patentable.

S100  Receive a sensor reading
  |
S110  Evaluate validity using the disclosed rule
  | valid                         | invalid
S120  Store the reading       S130  Record an invalid-reading event
  |                               |
  +------------ S140  End --------+

The most important phrase here is "using the disclosed rule". When the source does not define that rule, record an open question. Do not turn it into an invented algorithm to make the drawing look complete. Likewise, only add a retry loop when the actual source describes one.

This text diagram is a planning aid, not a filing-ready figure. Use it to obtain agreement on the method before preparing a drawing file.

Map steps to written support

Step	What it does	Source to locate	Question to resolve
S100	Receives a reading	Input definition	What data is received?
S110	Evaluates validity	Decision rule	What makes a reading valid?
S120	Stores valid data	Storage behavior	What is stored and where?
S130	Records invalid input	Error-handling description	What event is recorded?
S140	Ends this execution	Method boundary	Is another execution separate?

The identifiers are illustrative. Maintain one agreed step list while drafting the diagram and description. If a step changes, review its incoming and outgoing connections as well as its label.

Check branches and boundaries

Trace every possible path through the proposed diagram. Look for branches without labels, outputs that are never used, and paths that stop without explanation. Ask which actions are mandatory and which are alternatives; do not let the drawing tool decide that question by choosing a visually convenient arrangement.

If two modules operate concurrently, do not silently draw them as a strict sequence. Ask the technical owner how to express the relationship. A diagram can simplify presentation, but it should not change the source behavior.

Prepare and inspect the export

Produce the drawing from the reviewed step list, keeping labels legible and avoiding unnecessary line crossings. Reopen the exported file and trace the same paths again. Check that labels were not truncated or changed during conversion.

Use the drawing requirements checklist and consult MPEP 608.02 for formal drawing conventions. A clean block diagram or flowchart does not by itself establish that the application adequately discloses the invention.

To test a tool, use this synthetic example in the drawing workflow, then compare the output with the step table. For drafting-tool trials, use the evaluation checklist instead of judging only the first attractive image.