Trademarks

Trademark records, lifecycle stages, and Signa’s 4-axis status taxonomy

Signa normalizes trademark data from every connected office into a consistent format (see office coverage for the current list). Every trademark record includes core identity fields, classifications, owners, events, and more.

Key Fields

• mark_text: The word mark as filed (may be null for design marks)
• classifications: Array of goods/services classifications. Each item has nice_class (1-45) and goods_services_text describing what the mark covers
• office_code: Office where the mark is registered (e.g., uspto, euipo, wipo)
• filing_route: How the mark was filed: direct_national, madrid_designation, direct_regional, etc.
• renewal_due_date: Next renewal deadline (computed from jurisdiction rules)

Status Taxonomy

Every trademark office uses its own status codes. The USPTO has 200+ numeric codes. EUIPO uses 18 uppercase strings. CIPO has 30+ text-based codes. Signa normalizes all of these into a unified 4-axis status taxonomy, and always retains the office’s original status alongside it: status.raw_code and status.raw_label carry the source value on every record, and the source endpoint returns the office’s full raw payload.

The Four Axes

Every trademark status in Signa is described by four independent dimensions:

Axis	Field	Purpose
Primary	status.primary	High-level classification (3 values + unknown)
Stage	status.stage	Where in the lifecycle the mark is (18 values)
Reason	status.reason	Why the mark reached its current state (9 values)
Challenges	status.challenges	Active legal proceedings (6 values, array)

This multi-axis approach means you can filter with precision. A mark can be active (primary), registered (stage), with a null reason and [opposition_pending] in challenges: still active but facing a pending challenge.

Primary Status

The broadest classification. Every mark falls into one of:

Value	Meaning
pending	Application in progress, not yet registered
active	Registration is alive and in force
inactive	Registration is dead (cancelled, expired, abandoned, etc.)
unknown	Status could not be determined

Status Stage (18 values)

The specific lifecycle position:

Pending stages:

Stage	Description
filed	Application received, not yet examined
examining	Under examination by the office
pending_publication	Approved, awaiting publication
published	Published in the official gazette
opposition_period	Publication period for opposition is open
pending_opposition	An opposition has been filed and is under review
pending_cancellation	A cancellation action has been filed
pending_issuance	Approved, awaiting formal issuance
allowed	Allowed (US-specific: Notice of Allowance issued)

Active stages:

Stage	Description
registered	Active registration, in force

Inactive stages:

Stage	Description
abandoned	Applicant failed to respond or gave up
withdrawn	Applicant voluntarily withdrew
surrendered	Registrant voluntarily surrendered
refused	Office refused registration
cancelled	Registration cancelled (by office or third party)
invalidated	Registration declared invalid
expired	Registration expired (not renewed)

Fallback:

Stage	Description
unknown	Could not be mapped

Status Reason (9 values)

Why the mark reached an inactive state. Only populated for inactive marks:

Value	Example Scenario
refused	Office examiner refused the application
withdrawn	Applicant withdrew the application
abandoned	Applicant failed to respond to an office action
cancelled	Registration cancelled by office or via proceeding
invalidated	Registration declared invalid after challenge
expired	Registrant did not renew
surrendered	Registrant voluntarily surrendered the registration
revoked	Registration revoked (EU-specific)
other	Reason does not fit standard categories

Challenge States (6 values)

Active legal proceedings. This is an array because a mark can face multiple simultaneous challenges:

Value	Description
opposition_pending	An opposition has been filed
cancellation_pending	A cancellation proceeding is pending
invalidation_pending	An invalidation action is pending
appeal_pending	An appeal is pending
court_pending	A court proceeding is pending
other_pending	Another type of challenge is pending

Trademark Lifecycle

The diagram shows the most common transitions. Not all edges are shown: some offices allow additional paths (e.g., direct registration without publication in certain jurisdictions).

Office-Specific Mappings

Each office’s raw status codes are mapped to the canonical taxonomy above. Here are examples from major offices:

USPTO (200+ codes)

Raw Code	Raw Label	Stage
602	Abandoned-Failure to Respond	abandoned
620	Backfile application added to database	filed
660	Approved for publication	pending_publication
686	Published for Opposition	pending_opposition
688	Notice of Allowance-Issued	allowed
800	Renewed Post Reg.	registered
900	Expired	expired

EUIPO (18 codes)

Raw Code	Stage
RECEIVED	filed
UNDER_EXAMINATION	examining
APPLICATION_PUBLISHED	pending_opposition
REGISTERED	registered
WITHDRAWN	abandoned
REFUSED	abandoned
CANCELLED	cancelled
EXPIRED	expired

WIPO

Event Type	Stage
BIRTH	examining (new designation enters examination)
PROCESSED	registered (protection granted)
DEATH	cancelled, expired, or invalidated, depending on the reason
PROLONG	registered (renewed)

Additional Status Fields

Beyond the four axes, the status object includes metadata:

Field	Description
status.effective_date	When the status last changed
status.source	How the status was determined: explicit, event_derived, dispatch_derived, computed
status.raw_code	The office’s original status code
status.raw_label	The office’s original status text

Filtering by Status

Use any combination of the four axes to filter trademarks:

“Live” marks (TESS equivalent). status_primary accepts a single value or a comma-separated list. Pass active,pending to match every mark that is either registered or still in prosecution: equivalent to the USPTO TESS “Live” filter.

cURL

# All live marks (active OR pending): TESS-style "Live" filter
curl -s "https://api.signa.so/v1/trademarks?status_primary=active,pending" \
  -H "Authorization: Bearer sig_YOUR_KEY"

# All active, registered marks
curl -s "https://api.signa.so/v1/trademarks?status_primary=active&status_stage=registered" \
  -H "Authorization: Bearer sig_YOUR_KEY"

# All marks with pending challenges
curl -s "https://api.signa.so/v1/trademarks?challenge_states=opposition_pending" \
  -H "Authorization: Bearer sig_YOUR_KEY"

# All abandoned or withdrawn marks
curl -s "https://api.signa.so/v1/trademarks?status_stage=abandoned,withdrawn" \
  -H "Authorization: Bearer sig_YOUR_KEY"

Search Aggregations

The search endpoint returns aggregation counts for status_stage:

cURL

curl -X POST https://api.signa.so/v1/trademarks \
  -H "Authorization: Bearer sig_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "SIGNA",
    "options": { "aggregations": ["status_stage"] }
  }'

Practical Scenarios

How do I find marks that are at risk of cancellation?

Filter for marks with a cancellation challenge:

GET /v1/trademarks?status_primary=active&challenge_states=cancellation_pending

How do I distinguish between refused and abandoned applications?

Use status_stage directly: abandoned means the applicant failed to act, while refused means the office denied the application. The status_reason field provides additional context.

What if an office uses a code I haven't seen before?

If an unmapped raw code is encountered, status_stage is set to unknown and raw_code/raw_label are populated so you can still see the original office data.

Can a registered mark have challenges?

Yes. A mark can be registered (stage) with active primary status while simultaneously having cancellation_pending or opposition_pending in the challenges array. The mark remains registered until the challenge is resolved.