Trademark Search: USPTO, EUIPO and UK IPO

Search public trademark records by mark text or owner name and export a consistent dataset. This Python 3.12 actor combines the USPTO Trademark Search service with TMview for EUIPO and UK IPO. It needs no registry account or API key for its primary sources. Use it for brand research, monitoring lists, and preparing records for human review. Search results do not establish whether a proposed name is available or legally safe to use.

Coverage and current availability

USPTO searches use the public website's Elasticsearch-shaped JSON service, discovered through its public configuration. EUIPO and UK IPO searches use TMview office codes EM and GB, respectively. These offices are requested separately, so an unavailable registry does not prevent another registry from returning records. The current TMview interface sends search fields at the top level and uses criteria: "C"; the older nested criteria example returns HTTP 400.

The primary endpoints were reachable during development on September 26, 2026. Live-run results and any degradation are recorded in VALIDATION.md. The optional USPTO TSDR serial fallback is degraded: its public endpoint returned HTTP 401 and an API-key requirement here. The actor does not supply keys. USPTO mark-text search remains best-effort because its website API, session rules, and access controls can change. It first fetches the homepage and retains public session cookies in memory; it does not solve challenges or bypass authentication.

Proxy required for EU/UK: TMview (EUIPO and UK IPO) drops direct connections from cloud datacenters. Leave proxyConfiguration.useApifyProxy on (the default); standard datacenter proxies work.

Input

queries is a required nonempty array of mark strings or owner names. searchType defaults to mark; choose owner to target the USPTO owner field or TMview applicant field. An eight-digit query in mark mode is treated as a USPTO serial number. Search matching follows each registry's text-search semantics, so results are not guaranteed to be exact string matches.

registries selects uspto, euipo, and/or ukipo, with all three selected by default. status accepts all, live, or dead, defaulting to live. Unknown status values are retained only for all. TMview status is filtered locally because the apparent A/I group codes returned misleading zero-result responses during inspection. Live includes pending applications as well as registrations; dead includes expired, ended, cancelled, withdrawn, refused, and abandoned records.

niceClasses optionally selects integer classes 1–45. Matching any selected class is sufficient. maxResultsPerQuery defaults to 50 and applies per query, per selected registry. Thus three registries can return up to 150 records for one query at the default cap. Duplicate application numbers are suppressed within each query and registry; the same record matching different input queries can appear and be charged again.

includeGoods defaults to true. It includes goodsServices and fetches TMview detail records, which can also improve owner country and status dates. Set it false for faster search-only results; the goods field is then omitted and some metadata may remain null. timeoutSecs defaults to 30 per network operation. proxyConfiguration accepts standard Apify proxy settings; no proxy is selected by default.

Output and pricing

Each record contains registry, applicationNumber, registrationNumber, markText, markType, owner, ownerCountry, status, statusDate, filingDate, registrationDate, expiryDate, niceClasses, imageUrl, url, and source. Dates use YYYY-MM-DD where parseable. Numbers remain strings to preserve leading zeroes. Owners are joined with semicolons; country values retain source spelling. Missing information is null, and Nice classes are sorted unique integers. Every record also includes its input query.

A successfully persisted record triggers one record-returned event priced at $0.008. Twenty records cost $0.16; sixty cost $0.48. Dataset rows with rowType: "summary" are uncharged. These appear for zero matches or errors and include query, registry, count, error, elapsedSeconds, and chargeLimitReached. Key-value records SUMMARY and SUMMARY-N report every attempted query/registry combination, including successful ones.

If a detail request fails, the search record remains useful and is returned with detailError; it still costs one event. An uncharged summary discloses the incomplete enrichment. API errors and malformed responses are never presented as successful empty searches. Earlier results survive later pagination errors. The SDK's charged dataset write handles remaining event limits and stops further work once the limit is reached.

Running and maintaining

Create a Python 3.12 virtual environment, install requirements.txt, and run python -m unittest discover -s tests -v. Validate the input with apify validate-schema .actor/input_schema.json. On Windows, validation/run_live.ps1 copies INPUT.json into isolated local storage, executes python -m src, and saves timings and counts to validation/results.json. Local runs do not bill.

HTTP 403 and 429 responses receive two retries with exponential backoff; numeric Retry-After delays are capped at 30 seconds. Transport errors also receive two retries. Searches stop at the requested result cap, USPTO's 10,000-result window, or TMview's 500-page safety limit. Narrow broad owner queries when necessary. Goods descriptions and status mappings reflect public source data, which may lag official changes. Before deployment, configure the sole custom pricing event in Console and disable synthetic start/dataset charges. This repository task does not publish or push the actor.

Example output

One real saved dataset row, trimmed by omitting fields only. Source: storage/live-20260926-044804/datasets/default/000000001.json. This is historical validation evidence, not a live response.

{
  "registry": "uspto",
  "applicationNumber": "50086128",
  "registrationNumber": null,
  "markText": "NIKE",
  "owner": "Nike, Inc. (CORPORATION; Oregon, USA)",
  "status": "live",
  "filingDate": "2026-09-02",
  "niceClasses": [
    16
  ],
  "query": "nike"
}

This is a saved search result, not a fresh registry status check. The null registration number is preserved; live status can include an application. Fields omitted for space remain available in the full dataset row.

Use cases

• A brand naming agency can assemble candidate-name search records across the three registries for a client review meeting.
• An in-house trademark operations team can export owner-query results into a monitoring worksheet, preserving registry and application identifiers.
• An ecommerce brand manager can collect records in selected Nice classes for discussion with trademark counsel before a packaging decision.
• A licensing research firm can organize applicant names and available goods descriptions into a source-linked research shortlist.

Pricing example: 1,000 successful record-returned events x $0.008 = $8.00, computed from .actor/pay_per_event.json. This is the declared event subtotal; it does not verify active hosted billing or include any separately applicable platform or proxy costs.

Limitations

Search results are research inputs, not trademark clearance or a legal availability decision. Registry matching rules, caps, delayed updates, and failed detail requests can affect coverage. The TSDR fallback was degraded in local validation. For EU/UK cloud runs, follow the proxy guidance above and inspect the actual input configuration.

Sources and credit

EU and UK records: TMview (EUIPN), www.tmdn.org/tmview. The information is freely available at the source. United States records: United States Patent and Trademark Office, www.uspto.gov. Trademark data is public register data, and this Actor is not affiliated with or endorsed by either office.

This Actor is built for lookups and monitoring of specific marks and owners, not for bulk copies of a register. Keep result caps modest. If you need a full register, use the offices' own bulk data products.