Entity Resolution

How Signa deduplicates owners across trademark offices

Signa ingests trademark data from multiple offices (10 in production today, more planned). The same company can appear with dozens of name variations across offices. Entity resolution is the process that links these variations to a single canonical owner record.

The Problem

A single company files trademarks under many names:

Office	Name as Filed
USPTO	APPLE INC.
EUIPO	Apple Inc
DPMA	Apple Inc., Cupertino, California, US
CIPO	APPLE INC
WIPO	Apple Inc.

Without entity resolution, you would see five separate owners for one company.

How It Works

Signa resolves entities in three stages:

1. Name normalization — reducing every name to a canonical form
2. Public company matching — linking owners to SEC and GLEIF records
3. Corporate parent linking — connecting subsidiaries to parent companies via GLEIF Level 2 data

Phase 1 uses case-insensitive exact name matching within the same office. The cross-office matching, EUIPO applicant ID lookup, and near-miss detection described below are Phase 2 features currently in development.

Stage 1: Name Normalization

Signa runs every party name through a canonical normalization pass before matching: case folding, diacritic stripping, punctuation and whitespace normalization, common-abbreviation expansion, and legal-form extraction (e.g., recognizing “Inc.”, “GmbH”, “S.A.” as detachable suffixes). The output is a canonical form that’s stable across the dozens of spelling variations the same company can be filed under.

Normalization produces a canonical_name (the normalized form used for deduplication) and an optional normalized_suffix stored in separate columns. The original display-friendly name is returned as name in the API response.

The legal suffix dictionary covers corporate-designation suffixes across the major Latin-script European languages plus CJK.

cURL

curl -s https://api.signa.so/v1/owners?q=apple \
  -H "Authorization: Bearer sig_xxx" | jq '.data[0]'

Stage 2: Public Company Matching

Signa maintains a public_companies table populated from two authoritative sources:

Source	Coverage	Identifier
SEC EDGAR	~10,000 US-listed companies	CIK (Central Index Key)
GLEIF	~2.5M legal entities worldwide	LEI (Legal Entity Identifier)

Matching is performed by comparing the owner’s canonical_name (normalized form) + country_code against the normalized legal names from SEC and GLEIF records. When a match is found, the owner detail response includes the linked company data:

cURL

curl -s https://api.signa.so/v1/owners/own_abc123 \
  -H "Authorization: Bearer sig_xxx" | jq '.companies'

You can also filter owners by public company identifiers:

Filter	Description
ticker=AAPL	Find the owner linked to this stock ticker
lei=HWUPKR0...	Find the owner linked to this LEI
publicly_traded=true	Only return owners with a confirmed active SEC ticker match
has_lei=true	Only return owners with a confirmed GLEIF LEI match

Stage 3: Corporate Parent Linking

Using GLEIF Level 2 relationship data (467,000+ records), Signa links subsidiaries to their corporate parents via the GLEIF parent-subsidiary relationship type. This populates the parent_owner_id field on owner records and powers the /v1/owners/{id}/related endpoint.

cURL

curl -s "https://api.signa.so/v1/owners/own_abc123/related" \
  -H "Authorization: Bearer sig_xxx"

Merge Handling

When entity resolution determines that two owner (or attorney) records represent the same entity, the duplicate is merged into the canonical record and all associated trademarks are reassigned.

What happens when you request a merged entity:

Any GET request to the old ID returns a 410 Gone response with a pointer to the canonical record:

cURL

curl -s https://api.signa.so/v1/owners/own_old123 \
  -H "Authorization: Bearer sig_xxx"
# HTTP 410
# {
#   "error": {
#     "type": "entity_merged",
#     "status": 410,
#     "detail": "Owner own_old123 has been merged into own_abc123.",
#     "merged_into": "own_abc123",
#     "suggestion": "Use GET /v1/owners/own_abc123 instead."
#   }
# }

Merge handling applies to owners, attorneys, and firms. All three entity types return 410 Gone with a merged_into field in the error response when the entity has been merged into another record.

Best practice: Always handle 410 responses in your integration. If you cache owner IDs, update your cache when you receive a merge redirect.

Suppressed Owners

In some cases, an owner record is invalid or a duplicate that cannot be cleanly merged. These records are flagged with is_suppressed = true and are hidden from all public API list endpoints. If you have a direct reference to a suppressed owner ID, the detail endpoint still returns data, but the record will not appear in search results or list views.

FAQ

Why do I see the same company with different owner IDs across offices?

Entity resolution runs periodically, not in real-time. Newly ingested records may temporarily appear as separate owners until the next resolution pass links them. If you see duplicates persisting, the names may differ enough to prevent automatic matching. You can report suspected duplicates to support.

Can I look up an owner by stock ticker?

Yes. Use the ticker filter on the owners list endpoint: GET /v1/owners?ticker=AAPL. This performs a join through the public_companies table.

How often is the public company data refreshed?

SEC data is refreshed daily from the company_tickers.json feed (~10,000 US companies). GLEIF data is refreshed weekly from the LEI database (~2.5M entities). GLEIF Level 2 relationship data (corporate parents) is refreshed on the same schedule.

What happens to my portfolio when an owner is merged?

Portfolios reference trademarks, not owners directly. When an owner is merged, its trademarks are reassigned to the canonical owner. Your portfolio contents remain unchanged.

Does normalization handle CJK characters?

Yes. Normalization preserves CJK, Cyrillic, Arabic, Thai, and other Unicode scripts. Only Latin diacritics are stripped, and punctuation removal is Unicode-aware so non-Latin letters are preserved.