Proxies for Patent and Trademark Monitoring

Building a patent landscape or a prior-art corpus? You probably need no proxies at all. Pull the bulk distributions and the documented APIs, respect the published rate limits, and spend the money you saved on parsing and classification instead.

Running a trademark watch that has to spot infringement in the wild? Budget almost all of your proxy spend for the commercial surfaces, not the registers. Marketplaces, app stores, ad networks, social handles and domain listings are where infringing use appears, and every one of them blocks automation far harder than a patent office does.

Monitoring a handful of national registers that only expose a web interface? That is the narrow middle case, and a modest datacenter proxy allocation covers it. The volume is small, the pages are cheap, and the constraint is politeness rather than blocking.

The single most expensive mistake in this field is building a scraper for something that ships as a file.

The major offices publish, in one form or another. The USPTO runs an open data portal at developer.uspto.gov with documented APIs and bulk distributions covering patents, applications and trademark status. The EPO runs Open Patent Services at ops.epo.org, a registered REST API with a fair-use quota. WIPO publishes PATENTSCOPE for patent documents and the Global Brand Database for marks. The EUIPO and its partner offices feed TMview, which aggregates national and regional trademark registers into one search surface. Google maintains patent datasets in BigQuery for anyone who would rather run SQL than HTTP.

Between those, a very large share of what a patent or trademark monitoring product needs is available without a single proxied request. It is the same lesson as SEC EDGAR filings, where teams routinely build parsers for a full-text search page while the structured archive sits one directory up.

So the first question is not "which proxies", it is "what does this office publish, and how fresh is it". Ask that per register, write the answer down, and you will find the proxy requirement shrinks to a handful of sources.

One caveat worth knowing before you assume government sites are soft targets. When we loaded developer.uspto.gov on 23 September 2026, the served page included an AWS WAF challenge script in its head. Public-sector data portals sit behind the same commercial bot management as anyone else, and a request pattern that looks automated will get the same treatment. Our guide to AWS WAF and web scraping covers what that layer actually checks.

Sort every source into one of four buckets before you plan anything. The bucket determines the cost, the legal posture and the proxy requirement.

The third row deserves a plain warning. A paid database's terms of service are a contract you signed, and scraping around a licence is a commercial dispute rather than a technical problem. Our overview of whether proxies are legal for business use sets out the distinction between public data and contracted access. If a source is licensed, use the licensed interface.

The fourth row is where a trademark watch earns its keep, and where the proxy spend concentrates. A mark is not infringed on the register, it is infringed on a listing, an app icon, a paid search ad or a lookalike domain. Our post on brand protection online covers that surface in more depth.

Five cases, and it is worth being precise because everything outside them is wasted spend.

Country-restricted registers. A handful of national offices serve their search interface only to domestic addresses, or serve a degraded version to foreign ones. This is the clearest case for country-targeted exits, and it is usually a small number of registers.

Infringement sweeps on consumer platforms. Marketplace search, app store listings and ad placements all vary by country and all rate-limit by IP. The requirement here is not stealth for its own sake, it is that you need to see what a shopper in that market sees. This is the same requirement as any regional catalogue comparison.

Status polling at a frequency the office tolerates from one address but not many. More on this below, because IP offices are unusually explicit about what they will accept.

Evidence capture from the jurisdiction in question. If a capture might end up attached to an opposition or a takedown, it should have been taken from an exit in the country where the alleged infringement occurred. A screenshot of a German listing captured from a US address invites an argument you do not want to have.

Long-running incremental crawls. A watch service runs continuously, not in bursts, and a single address doing steady polling for months accumulates a profile whether or not any single request looks unusual. Our post on incremental scraping and change detection covers how to keep the request volume low enough that this stops mattering.

Patent and trademark offices are not ecommerce sites, and treating them like ecommerce sites is both rude and counterproductive.

Three differences shape how you should collect:

The limits are usually documented, and they are usually generous. Offices that run an API publish a quota, whether that is requests per minute, data volume per period, or a concurrent-connection cap. This is a gift. You can size your collection to the published number instead of discovering the ceiling by hitting it. Read the documentation before you write a fetch loop.

Enforcement is often per registered key, not per IP. This is the detail that catches people out, and it is the opposite of how a marketplace behaves. If the office counts against your API key, rotating exits does nothing at all for your throughput and only makes your traffic look strange. Proxies solve an IP-based limit. They do not solve a credential-based one.

Blocking tends to be durable and human. A commercial site soft-blocks an address for an hour. An office is more likely to suspend a key or contact the registrant. That asymmetry means the cost of getting this wrong is higher and the recovery is slower.

The practical rule: identify yourself, stay inside the published quota, use a contactable user agent where the office asks for one, and cache aggressively so you never fetch the same document twice. Our guide to ethical scraping and rate limiting is the relevant reading, and it applies here more literally than almost anywhere else.

Here is the requirement that actually drives cost, and it is specific to trademark work rather than patents.

Trademark systems run on deadlines. A published application opens an opposition period, and that period is fixed and short. Miss it and the remedy becomes cancellation, which is slower, more expensive and less likely to succeed. So the value of your watch is not how many marks it covers, it is whether it surfaces a conflicting application early enough in that window to act.

That converts directly into a polling schedule. Work backwards:

1. Find the opposition period length for each jurisdiction you care about. They differ.
2. Subtract the time your legal team needs to review a hit and file. Be generous, because this is the step that actually consumes the window.
3. What remains is your maximum acceptable detection lag.
4. Your polling interval must be shorter than that lag, per register.

For most jurisdictions this lands on daily or weekly polling of new publications rather than hourly, which is a much cheaper requirement than teams assume before they do the arithmetic. Patent monitoring is looser still: prosecution timelines run in months, so weekly is usually ample and the freshness pressure comes from competitor-watch use cases rather than deadlines.

The consequence for buying: you are not building a high-frequency system. You are building a low-frequency system that must never miss a cycle. Those need different things. Reliability and alerting matter more than throughput, and our post on scheduling and automating scrapers covers the part that actually breaks, which is the silent failure nobody notices for three weeks.

If your monitoring output feeds an opposition, a cease and desist or a marketplace takedown, the capture has to stand up to someone arguing it is unreliable. Six things belong with every stored hit:

• The exact request URL, unshortened and with parameters intact.
• A timestamp in UTC, recorded by your system rather than read off the page.
• The exit country the request was made from.
• The full HTTP response headers as received.
• A rendered visual capture, not just the HTML, because the infringing element is often an image.
• A hash of the stored artefact, computed at capture time.

The rendered capture is the part people skip and regret. A stored HTML file re-rendered six months later looks nothing like what the user saw, because the assets have moved. Capture the page as a screenshot or a PDF at the moment of collection. Our post on web archiving and compliance capture covers the storage side, including why you should keep the raw response alongside the rendering rather than instead of it.

Here is a worked example so the numbers are concrete. These are illustrative assumptions, not measurements from any test we ran, and your own counts will differ.

Scenario: 60 protected marks, swept daily across 8 marketplace and app-store surfaces, in 3 countries.

• 60 marks x 8 surfaces x 3 countries = 1,440 search result pages per sweep.
• Daily sweeps across a 30-day month = 43,200 pages.
• Register data comes from bulk files and documented APIs, so it costs 0 credits.

Now price those 43,200 pages five ways through the SparkProxy Scraping API. The base cost is the proxy tier multiplied by the rendering mode, not added to it, and country_code, stealth, js_scenario and screenshot or PDF output are the only true add-ons at 5 credits each:

Note the last row, because the arithmetic trips people up. Setting premium_proxy=true replaces the base cost rather than adding to it: 25 credits for a rendered residential fetch, plus 5 for country targeting, so 30 in total. Not 35, and certainly not 5 plus 25 plus 5.

Two levers stand out. Dropping country targeting where a surface does not actually vary by market cuts the rendered case from 432,000 to 216,000 credits, which is a 50 percent reduction for asking one question per surface. And finding the JSON endpoint behind a marketplace search, so you can use a plain fetch instead of a rendered one, cuts the country-targeted case from 432,000 to 259,200, a 40 percent reduction.

Evidence capture is a rounding error on top. Assume 0.5 percent of swept pages surface something worth capturing: that is 216 captures a month, at 5 credits for the rendered base plus 5 for the screenshot format plus 5 for country targeting, so 15 credits each, or 3,240 credits. Added to the rendered country-targeted sweep, the total is 435,240 credits a month, comfortably inside Growth's 1,000,000 at $99.

If your volume is much larger, the flat proxy plan becomes the cheaper shape. At the Scale tier, $599 buys 8,000,000 credits, which is 800,000 ten-credit pages, or about $0.00075 a page. SparkProxy's Boost plan is $240 a month for 500 concurrent threads with unlimited bandwidth, so it breaks even at roughly 320,000 rendered pages a month and wins above that, provided you are willing to run your own browser fleet. Our explainer on scraping API credit pricing works through that trade in general terms. Every account starts with 1,000 free credits and no card, which is enough to measure your own per-page cost before committing.

The pattern is consistent: the register side is cheap and datacenter-shaped, the commercial side is expensive and residential-shaped. Our comparison of residential and datacenter proxies covers where the line sits. SparkProxy sells datacenter proxies and a Scraping API rather than standalone residential plans, so for the marketplace half of this work the API with premium_proxy=true is the route through our own products, and the datacenter network handles the register half at gateway.sparkproxy.io on port 11000.

Seven questions, in order. Answer all seven per source and the architecture writes itself.

1. Does this office publish a bulk distribution or a documented API? If yes, stop here and use it.
2. If there is an API, is the quota counted per key or per IP? Proxies only help with the second.
3. What is the publication cadence, and what is the lag between an event and its appearance?
4. What is the opposition or response deadline in this jurisdiction, and how much of it does your legal review consume?
5. Does the source serve different content to different countries? Test it before you pay for country targeting.
6. Does the surface need a rendered browser, or is there a JSON endpoint behind it? This is a 40 percent cost difference on the model above.
7. Will any capture from this source ever be shown to a lawyer? If yes, build the evidence fields in from day one rather than retrofitting them.

Most teams answering these honestly find that two thirds of their planned scraping disappears into bulk files, and the proxy budget they were about to spend on patent offices belongs on marketplaces instead. Our post on legal and court records data reaches a similar conclusion from a different direction, which is a reasonable sign that the pattern generalises across public-record work.