What TESS Did Right and Wrong (And How Modern APIs Improve On It)

TESS handled every trademark search the USPTO offered for over 25 years. It processed queries against a database growing by 1,700+ filings per day, ran phonetic similarity matching before most commercial tools had it, and gave anyone with a browser free access to the full USPTO record. Then in late 2025, the USPTO replaced it with a new system built on IP Australia's TMCloud platform.

Most coverage of TESS's shutdown was written for trademark attorneys. This piece is for engineers. TESS made real design decisions, some good, some defensible at the time, some genuinely limiting. Those decisions matter if you're building on trademark data today.

What TESS Actually Was

TESS (Trademark Electronic Search System) launched in the late 1990s, built on top of the Bibliographic Retrieval System (BRS), an infrastructure layer the USPTO had been running since 1993. The underlying architecture was server-rendered HTML pages served through a session-based concurrency model.

The session model shaped everything else. TESS allocated a fixed pool of concurrent sessions across all users globally. When you connected, you claimed a session. That session held your search state, your result sets, your position in paginated results.

If the pool was full, you waited. If your session was inactive for 30 minutes, the server destroyed it and released the slot.

This is the opposite of how you'd design a search system in 2026. But in the late 1990s, server-side session state was a standard approach for database-backed web applications. The BRS infrastructure underneath wasn't designed for stateless request-response patterns.

TESS offered three search modes, and the distinction between them reveals the system's real power:

• Basic: A simple text box. Type a word, get results. Good for casual searches.
• Structured: A form-based interface that mapped to field codes. You could restrict searches to specific fields (mark text, goods/services, owner name, Nice class) through dropdown menus.
• Free-Form: The raw query language. Boolean operators, field codes, proximity operators, truncation wildcards. This was where TESS became a serious tool.

The field code system was genuinely expressive. [BI] searched the Basic Index (combined mark text), [FM] searched the Free-Form Mark, [GS] searched Goods and Services descriptions, [IC] targeted the International Class, [ON] matched Owner Name, [LD] filtered by Live/Dead status. A query like "CLOUD*"[BI] AND "009"[IC] AND "A"[LD] found all live Class 9 marks starting with "cloud" in a single search string.

The problem was that Free-Form mode required you to already know this syntax. There was no autocomplete, no inline documentation, no query builder. Most users never left Basic mode, which meant most users never saw what TESS could actually do.

What TESS Got Right

It's easy to dismiss TESS as a relic. That misses the genuine engineering strengths of the system.

Boolean Expressiveness

The field code query language was more expressive than most modern trademark search interfaces. You could combine field restrictions, Boolean operators, proximity operators, and wildcards in a single query string. Power users (typically trademark paralegals and experienced attorneys) could construct remarkably precise searches that would take multiple steps in most commercial tools.

This matters because trademark clearance is fundamentally a search problem with complex constraints. You're not looking for exact matches. You're looking for marks that are confusingly similar across multiple dimensions: text, sound, meaning, goods/services overlap, geographic scope. A query language that could express those constraints directly was genuinely valuable.

Free Public Access

TESS was free. No API key, no subscription, no account creation. Anyone with a browser could search the complete USPTO trademark database. This was unusual for government data systems and remains unusual today. Many national trademark offices still restrict access, charge per-search fees, or require registration.

For startup founders running a quick name check before committing to a brand, the barrier was zero. That mattered for accessibility in a way that commercial tools, even good ones, couldn't match.

Phonetic Matching

TESS included X-Search, a phonetic similarity search capability that could find marks sounding like your query regardless of spelling. Search for "SIGNA" and X-Search would surface "CYGNA," "CIGNA," "SYNNA." This was one of the earliest implementations of algorithmic trademark similarity matching in a public system.

Phonetic matching is critical for trademark clearance because the legal standard for infringement includes "likelihood of confusion," which encompasses sound-alike marks. A system that only finds exact text matches misses the most important category of conflicts. TESS had this capability decades before it became a standard feature in commercial search APIs.

Complete USPTO Coverage

TESS indexed every record in the USPTO's trademark database: active registrations, pending applications, cancelled marks, abandoned filings, expired registrations. No sampling, no coverage gaps, no freshness lag relative to the official record. It was the canonical dataset.

This completeness meant that even commercial trademark search tools ultimately validated their results against TESS. If something was in the USPTO system, it was in TESS.

What TESS Got Wrong

The limitations of TESS weren't bugs. They were design decisions, some made in the 1990s, some carried forward by institutional inertia. Each one had engineering consequences.

No API

This was the single biggest limitation. TESS had zero programmatic access. Every interaction required a human in a browser session. There was no REST endpoint, no SOAP service, no bulk download, no data feed.

The consequence was an entire cottage industry of scrapers. Companies that needed trademark data at scale built screen-scraping tools that parsed TESS's HTML output, managed session cookies, handled the concurrency pool, and retried on timeout. These tools were brittle, broke on every UI change, and violated the USPTO's terms of service. But the alternative was having staff manually search and copy-paste results.

For anyone trying to build trademark clearance into a product, monitoring into a workflow, or analysis into a pipeline, TESS was a wall. The data was public and free, but programmatic access was impossible. This gap created a market for trademark APIs and alternatives that persists today.

Session Architecture

The fixed concurrent session pool was a hard cap shared across all users worldwide. During peak hours (US business hours, especially when filing deadlines approached), you'd see the "maximum number of simultaneous TESS users" error page. Your options were to wait and retry, or come back later.

When you did get a session, the 30-minute inactivity timeout destroyed all state: your search results, your position in a result list, your query history. Step away from your desk, come back, start over.

Results weren't bookmarkable. Search URLs weren't stable. Every interaction depended on an active session with server-side state. Compare this to how you'd design the system today: stateless requests, per-key rate limiting instead of a global session pool, cursor-based pagination with stable page tokens, and bookmarkable URLs for every query and result set.

US-Only Data

TESS indexed only USPTO records. No EUIPO trademarks, no WIPO Madrid Protocol designations from other offices, no Canadian, UK, Singapore, or Chinese filings.

This was a significant blind spot. Trademarks are jurisdictional (a US registration doesn't automatically protect you in Europe), but brands are global. The Madrid Protocol lets a single filing extend protection across 130+ member countries. A mark registered in Germany through the Madrid system could block your US filing if it designated the US, but you wouldn't find the German base registration in TESS.

Practitioners who needed international coverage had to search TESS, then separately search WIPO's Global Brand Database, EUIPO's eSearch plus, UKIPO, CIPO, and any other relevant national trademark databases, then manually cross-reference results. Each system had its own interface, its own query syntax, its own data format.

Opaque Query Syntax

The field code system was powerful but undiscoverable. You either memorized the codes or kept a reference sheet open.

There was no autocomplete suggesting [IC] when you started typing a class number. No tooltip explaining what [FM] meant. No query builder that let you construct a field-restricted search visually and then see the generated syntax.

The result was a two-tier system. Expert users (paralegals with years of TESS experience) could write sophisticated queries. Everyone else used Basic search and got mediocre results. Even X-Search, TESS's most valuable capability for trademark clearance, required knowing it existed. The system's best features were hidden behind a memorization barrier.

No Result Scoring or Export

TESS returned results as binary matches: your query hit or it didn't. There was no relevance score, no similarity ranking, no indication of how close a result was to your query. For a system where the core legal question is "how confusingly similar are these marks?", the absence of scoring was a fundamental gap.

Export was equally limited. The output mechanism was copy-paste from HTML tables. No CSV, no JSON, no bulk download. For anyone doing analysis across more than a handful of results, this was a manual bottleneck that negated the power of the search system.

How Modern APIs Solve Each Problem

Every TESS limitation maps to a specific architectural improvement in modern trademark APIs. The comparison isn't abstract:

Programmatic Access

The fundamental shift is treating trademark data as infrastructure you build on, not a website you visit. A REST API with structured JSON responses means trademark search is a function call, not a browser session.

What required a manual TESS session, copy-paste, and a spreadsheet now fits in a script:

curl -G "https://api.signa.so/v1/trademarks" \
  -H "Authorization: Bearer $SIGNA_API_KEY" \
  --data-urlencode "q=ACME" \
  --data-urlencode "strategies=exact,phonetic,fuzzy,prefix"

const signa = new Signa({ api_key: process.env.SIGNA_API_KEY });

const results = await signa.trademarks.search({
  query: 'ACME',
  strategies: ['exact', 'phonetic', 'fuzzy', 'prefix'],
  filters: { jurisdictions: ['US', 'EU'], nice_classes: [9, 42] },
});

for (const mark of results.data) {
  console.log(`${mark.mark_text} (${mark.office_code}) - score: ${mark.relevance_score}`);
}

That single request runs four search strategies simultaneously (exact text match, phonetic similarity, fuzzy character tolerance, and prefix matching) across multiple jurisdictions. Each result comes back with a relevance_score from 0 to 100, so you can sort by similarity rather than scanning a flat list. TESS would have required separate searches in different modes with no scoring on any of them.

Multi-Office Coverage

Modern APIs index records from hundreds of trademark offices into a single searchable dataset. Instead of searching USPTO, then WIPO, then EUIPO, then running cross-references manually, one query covers all of them with normalized data schemas across offices. Status codes, goods descriptions, owner entity formats are all mapped to a consistent model regardless of source.

The data coverage difference is structural. TESS gave you one office's records. Modern trademark APIs like Signa aggregate 150M+ records from 200+ offices, including Madrid Protocol international registrations that TESS never indexed.

Stateless Architecture

No sessions, no timeouts, no global concurrency pool. Authentication is a Bearer token in the request header. Rate limits are per-API-key, not shared across all users.

Pagination uses cursors, so you can resume exactly where you left off after any delay. Every request is independent.

The session pool was TESS's bottleneck. Modern APIs replace it with per-key rate limiting that scales horizontally. Your request doesn't compete with every other user for a fixed resource.

The Deeper Lesson: Why Government Search Systems Stagnate

TESS isn't an isolated case. The pattern repeats across government data systems: PACER for federal court records, EDGAR for SEC filings, patent search tools at various national offices. Government builds the canonical database. The public-facing interface stagnates. Private companies build the developer access layer.

The structural reasons are predictable. Government IT procurement operates on multi-year cycles. TESS was built on BRS infrastructure from 1993. The replacement (TMCloud, licensed from IP Australia) took years to procure and deploy. API-first companies iterate weekly. These are different time scales operating on the same data.

The TESS replacement is a genuine improvement. The new USPTO Trademark Search system has a modern interface, better search, and mobile support. But it's still a web application, not an API. The architecture assumes a human in a browser. The pattern repeats: build for human users first, leave programmatic access as an afterthought or an opportunity for the private sector.

This isn't a criticism of government engineers. The design constraints are different. Government systems optimize for universal public access, zero-cost availability, and accountability. APIs optimize for developer experience, composability, and automation. These goals genuinely conflict.

TESS succeeded at being free and universally accessible. It failed at being programmable. Modern APIs succeed at composability but sit behind paywalls and API keys.

The healthiest pattern may be what's already emerging: government provides the authoritative data and a usable public interface. Private APIs provide the developer infrastructure layer. Neither replaces the other. The gap only becomes a problem when the government system claims to be sufficient for all use cases, which is what TESS did for 25 years.

TESS served a real purpose for a quarter century. Its design decisions made sense in 1998. The mistake wasn't that TESS was bad. It's that it didn't evolve. The field codes were powerful in 1999 and still powerful in 2025, but the absence of an API was a limitation from day one that never got addressed.

If you're building on trademark data today, the infrastructure exists to do what TESS never could: multi-office search, similarity scoring, structured responses, and programmatic access from the first line of code. Signa's API was designed around those gaps.