Reading Patents Is a Skill Most Engineers Skip

The more I poke around the US Patent and Trademark Office's databases, the more I notice something funny: most engineers I know read RFCs, papers, GitHub issues, and Stack Overflow answers all day, but they've never opened a patent. It's not that patents aren't useful. It's that they look like legal text. The font is small, the language is stiff, and there are about forty paragraphs before you reach anything worth knowing.

But underneath that wrapper, a patent is a technical spec with legal claims bolted on. The spec parts are written by inventors and reviewed by examiners who do nothing else for a living. They contain detailed descriptions of how things work, with diagrams. There are roughly 10 million of them, all free, all searchable. And almost nobody on a product team reads them.

The USPTO database is the most underused competitive-intelligence source available to a software engineer — once you stop reading patents like documents and start querying them like a system.

In Post 2 of this series I argued that filing a patent is rarely the move most software builders should default to. This post is the other side of that coin: even if you never file one, an afternoon of patent search will tell you what's already protected in your space, what your competitors are quietly building, and what kinds of features examiners have already called obvious. That's three concrete pieces of competitive intelligence — for free, in a few hours, before you write any code.

A patent has three parts, and only one is interesting

Most patents are organized the same way. Once you see the structure, you stop reading top-to-bottom and start jumping to the parts that actually matter.

The specification is the technical writeup — what the invention does, how it works, the problem it solves. This is where you'll find the algorithms, the architecture, the hardware diagrams. It's written for people skilled in the relevant field, which means it's denser than a blog post but lighter than an academic paper.

The claims are the part that legally matters. Each numbered claim defines a precise boundary. Claim 1 is almost always the broadest. Claims 2, 3, 4, and so on are usually narrower variations that depend on claim 1. If you want to know exactly what the patent stops other people from doing, you read the claims. Everything else is context.

The drawings are figures referenced from the spec — flowcharts, hardware diagrams, UI mockups. They're the fastest way to understand what an unfamiliar patent is doing. I almost always look at these first.

The trick most engineers miss is that you don't have to read the spec word-for-word. You read the title, skim the abstract, look at the drawings, then read claim 1. Five minutes. If anything looks relevant, you go deeper.

Two search engines, the same data

The USPTO offers Patent Public Search at patents.uspto.gov. Google offers Google Patents at patents.google.com. Same underlying patent data, very different ergonomics.

I default to Google Patents for almost any first-pass search. The UI is faster, the related-patents graph is excellent, and the citation chains are easier to follow. When I need precision — exact field-coded queries, prosecution history, or post-grant proceedings — I move to USPTO Patent Public Search.

If you've never used either, start with Google Patents. The mental tax of learning USPTO syntax isn't worth paying until you have a specific reason for the precision.

How to query the system, not browse it

The single biggest improvement most engineers can make in a patent search is to stop typing English phrases and start typing Boolean queries with field codes. The USPTO query language gives you the same kind of leverage that grep gives you over a codebase.

The operators are simple, but the combinations are powerful.

Field codes pin a query to a specific section of the patent — the title, the abstract, the claims, the inventor, or the assignee .

A useful pattern: search the assignee field for a specific competitor. If you want to know what Stripe is patenting, run .as.(Stripe). You'll see every patent assigned to them, ranked by date. The result is essentially a public R&D roadmap — slightly delayed (patents publish 18 months after filing), but otherwise complete.

What reframed competitive research for me: companies announce a fraction of what they're actually working on. They patent much more — and the patent is published 18 months after filing, regardless of when the product ships. Reading a competitor's assignee feed is closer to reading their internal roadmap from 18 months ago than reading their press releases from today.

CPC codes are the real superpower

Keyword search is OK. Classification search is much better. The Cooperative Patent Classification (CPC) is a hierarchical category system used by the USPTO, the European Patent Office, and most of the world. Every patent is tagged with one or more CPC codes during examination.

The CPC codes a software engineer should recognize:

• G06F — digital data processing (most software inventions land here)
• G06N — machine learning, neural networks, AI architectures
• G06Q — business and commerce systems (fintech, payments, marketplaces)
• H04L — networking and digital transmission (TLS, packet routing, IoT comms)
• G16Y — Internet of Things specifically

Classification search beats keyword search because it catches patents you'd never find by guessing words. Two engineers will describe the same algorithm with completely different terminology. They'll both get the same CPC tag from an examiner who's classified thousands of similar inventions.

The workflow that works:

Step 1 gets you in the neighborhood. Step 2 tells you the neighborhood's name. Step 3 expands the search to everything else in the same neighborhood. Step 4 finds the older inventions your seed patents built on. Step 5 reveals which companies are concentrating effort there.

I've found it useful to think of CPC codes as namespaces. Once you know which namespace your invention lives in, you can scan the whole namespace fast.

Reading a patent like a code review

Once a search returns something interesting, the question becomes how to actually read it without losing four hours. The trick is to read patents in roughly the same order you'd review a pull request: start with the most important part, then walk outward only as needed.

Claim 1 deserves a closer look because most patents are designed so that everything important about the invention shows up there. A typical claim 1 reads like a single very long sentence with a list of "wherein" clauses, each adding a required element. If your product doesn't have every element listed in claim 1, the patent doesn't apply to you. If it has all of them, you might have a problem — even if your implementation is otherwise different.

The mental model that helped me: a claim is a Boolean AND of all its elements. To infringe, you need every element. To not infringe, you need to be missing even one.

Dependent claims (claim 2, claim 3, etc.) usually take the form "the method of claim 1, wherein [extra requirement]." They narrow claim 1 by adding more elements. They exist mostly as fallback positions — if claim 1 turns out to be too broad, the patent owner can fall back to a narrower dependent claim that's still allowed.

Prosecution history is where the gold lives

This is the part of the patent system most engineers don't know exists. Every Office Action — every rejection, every argument, every amendment — is publicly viewable as part of the patent's prosecution history , accessible through the USPTO Patent Center (formerly PAIR).

What you can read in the prosecution history:

• The original claims as filed (often broader than what got allowed)
• The exact prior art the examiner cited as a problem
• The arguments the attorney made to overcome the rejection
• The amendments that finally got the claims allowed

For prior-art research, this is enormously useful. The examiner has already done the work of finding the closest relevant patents. Their citations are essentially a curated reading list.

For competitive intelligence, it's even more useful. The amendments tell you exactly where the patent's edges are. If a competitor narrowed their claims from "any method of doing X" to "a method of doing X using technique Y," you now know they couldn't get protection for the broader idea — which means you have more design freedom than the granted patent alone suggests.

"Won't an LLM just do all this for me?"

It's a fair question, and one I've asked myself. The patent corpus is ~10 million documents in a known schema. LLMs read patent-style language well. Tools that summarize patents, draft claim charts, or surface prior art automatically already exist and are getting better fast.

Two things, though, that hold even with strong models in the loop:

First, the claims are still where the legal boundary lives. An LLM can summarize a patent's specification beautifully and still misread which claim language was narrowed during prosecution and which was allowed in its original form. For any decision that matters — am I infringing, can I design around this, what's the patent owner's actual leverage — you have to read the claims with your own eyes. The LLM can speed up the search and the first-pass scan; it can't replace the careful read.

Second, knowing the system makes the LLM useful in the first place. If you don't know what CPC codes are, you won't know to ask the model for them. If you don't know prosecution history is public, you won't know to ask for it. Most of the leverage in this post isn't in the search syntax — it's in knowing what to look for. That's exactly the part the model can't bootstrap on its own. So the LLM doesn't replace the skill in this post; it amplifies it for whoever already has it.

What this looks like in practice

Imagine you're an engineer about to start building a smart-trap product. Before you write any code, you'd want to know what's already been patented in this space. Here's roughly what twenty minutes of searching produces:

By the end of that twenty minutes, you know the specific mechanisms that are protected, the companies investing seriously in the space, and — from the prosecution history — what kinds of features examiners consider obvious enough to reject. You've done a more rigorous market scan than most product managers do before greenlighting a project, and you've spent zero dollars.

This is the part I wish someone had told me earlier. The cost-benefit on patent search is wildly asymmetric. A few hours of learning the search tools pays back across every product decision you'll ever make.

Try this: open patents.google.com tonight and run assignee: for your closest competitor. Ten minutes, zero dollars — the most honest 18-month-delayed roadmap you'll ever read.

Notes from twenty minutes of patent search

• A patent has three parts — specification, claims, drawings — and only the claims define the legal boundary
• Reading order: title and abstract first, then drawings, then claim 1, then everything else as needed
• Google Patents handles 80% of searches; switch to USPTO Patent Public Search when you need precise field codes or prosecution history
• Boolean queries with field codes (.ti., .ab., .cl., .as.) make patent search behave more like grep over a codebase than browsing a library
• CPC codes are the patent system's namespaces — once you know the namespace, you can scan the whole space fast
• Searching by assignee gives you a competitor's product roadmap with an 18-month delay
• A claim is a Boolean AND of its elements — to infringe, you need every element; missing one element means you don't infringe
• Prosecution history is publicly viewable in Patent Center and tells you exactly where the patent's edges are
• Examiner citations are a free curated reading list of the closest prior art for any given idea
• Twenty minutes of patent search before starting a product is one of the highest-leverage moves an engineer can make

What reframed this whole topic for me is the bottom item on the list. Most of us treat patents like a thing other people do — lawyers, legal teams, IP departments. But the database is public, the tooling is free, and the information density is unreal. It's free competitive intelligence sitting in plain sight, written by the people building the actual things, reviewed by experts who do nothing else.

Post 4 — the last in this series — looks at the harder strategic question: what to do when you decide a patent is worth filing, and how the international system makes that decision much cheaper than it first appears.

Tools and references

• USPTO Patent Public Search (patents.uspto.gov) — Used for: query syntax, field codes, Boolean operators, and prosecution history access.
• Google Patents (patents.google.com) — Used for: alternative search interface, citation graph, and the Victor Smart-Kill US10440944B2 example.
• USPTO Manual of Patent Examining Procedure (MPEP) — Used for: claim interpretation principles and the role of prosecution history.
• Cooperative Patent Classification (cpc.uspto.gov) — Used for: hierarchical CPC structure (Section / Class / Subclass) and the G06F, G06N, G06Q, H04L, G16Y codes called out in the post.
• USPTO Patent Center documentation — Used for: explaining how Office Actions and prosecution history are publicly accessible.