U.S. patent data is, on paper, completely public. Every granted patent, every published application, every claim, every assignment — all of it lives somewhere on a USPTO server. In practice, getting structured patent data into your pipeline is one of those problems that looks easy and turns into a multi-week side quest the moment you actually try.
If you have ever opened the USPTO public search front-end, run a query, and wondered how to feed the results into a notebook, this post is for you. We will walk through why bulk patent data is harder than it looks, what kind of work it unlocks once you have it, and how to pull structured USPTO records straight into a CSV or JSON pipeline through our hosted scraper — without writing or maintaining any code yourself.
The USPTO publishes data through several different channels, and none of them are friendly for the “I just want a clean dataset of US patents matching this query” use case.
The result: most teams that need patent data either give up, pay a vendor, or burn an engineer-week building a fragile scraper around whatever endpoint is currently up. None of those are great.
It is worth being concrete about what you can actually do with a clean USPTO feed, because the use cases are broader than “file a patent lawsuit.”
The common thread across all of these is the same: you do not want a single patent document, you want a structured, queryable feed of patents matching a search.
Rather than have you wire up another USPTO endpoint and watch it break the next time the schema changes, we run a hosted scraper on Apify that does the unpleasant parts for you. You give it a search query and it returns clean records.
The input is a small JSON document:
{
"query": "machine learning",
"dateFrom": "2022-01-01",
"dateTo": "2024-12-31",
"assignee": "Google LLC",
"maxResults": 50
}Every field except query is optional. dateFrom and dateTo filter by patent grant date. assignee filters by company name. maxResults goes up to 100 per run.
The output is a clean array of records, one per granted US patent:
{
"patent_number": "US11704715B2",
"title": "Quantum computing service supporting multiple quantum computing technologies",
"inventors": ["Christopher Kasprowicz", "Boyu Wang", "..."],
"assignee": "Amazon Technologies, Inc.",
"filing_date": "2019-11-27",
"grant_date": "2023-07-18",
"claims_count": 24,
"abstract": "A quantum computing service includes connections to multiple quantum hardware providers...",
"url": "https://ppubs.uspto.gov/pubwebapp/external.html?q=11704715"
}That is the shape that drops cleanly into a pandas DataFrame, a Postgres table, or a vector index. No XML parsing, no schema drift, no API key management, no rate-limit retries on your side.
You can call the actor either through the Apify console with a JSON input, through the Apify SDK from Python or Node, or through the standard Apify run-sync REST endpoint that returns the dataset directly. The same input schema works in all three.
For prior-art workflows we typically recommend running the scraper once with a broad query to seed a local index, then re-running daily with a tighter dateFrom filter to pick up new grants. That keeps your index fresh without re-pulling the historical corpus every day.
Doing serious patent research at scale? If you are pulling tens of thousands of records across many queries, or running long-form competitive-intelligence pipelines, residential proxies ensure consistent access for large-scale patent research even when source sites tighten their bot defences. We use Oxylabs residential proxies as the underlying network layer for jobs of that size.
A few things are worth being honest about.
For the “structured feed of US patents matching a query, ready to drop into a notebook or pipeline” problem, though, this gets you from idea to dataset in one input form.