Madrid Protocol

The Madrid Protocol is an international treaty that allows trademark holders to seek protection in multiple countries through a single application filed with WIPO (the World Intellectual Property Organization). Signa models the Madrid System, including international registrations, designations, coverage status, and Madrid-specific deadlines.

How the Madrid System Works

Filing: The applicant files an international application through their home office (the “office of origin”)
WIPO registration: WIPO registers the mark in the International Register and publishes it in the Madrid Gazette
Designation: The applicant designates one or more member countries where they want protection
National examination: Each designated office examines the mark under its own law
Protection or refusal: Each office independently grants or refuses protection

Data Model

Signa models a Madrid IR as one designation record per designated country, plus the IR record itself (the international registration). Each designation is an independent trademark that can have its own status, deadlines, and events, because each designated office makes independent decisions about examination, opposition, and renewal. A mark can be protected in one country and refused in another.

Designation

Field	Value
`filing_route`	`madrid_designation`
`office_code`	`WO` on a designation record from WIPO’s data. A national office’s own record of a designation carries that office’s code, for example `US` on a USPTO 79-series record
`jurisdiction_code`	The designated country (e.g., `GB`, `DE`): tracks where protection is sought
`scope_kind`	`international_registration` on a record from WIPO’s data; `national` on a national office’s own record of a designation, such as a USPTO 79-series record
`ir_number`	The WIPO registration number (links all designations from the same IR)

Querying an IR family

GET/POST /v1/trademarks defaults to grouped result presentation (international_registrations=grouped): a Madrid IR family is returned as one row with a coverage rollup summarizing every designated territory’s status. Pass international_registrations=expanded to get one row per designation instead. Either way, GET /v1/trademarks?ir_number=... returns the whole family, and GET /v1/trademarks/{id} on the IR parent returns the same rollup with the full per-territory breakdown inline (below). A designation that Signa has not linked to its IR parent record is the exception: the grouped view returns it as its own row without coverage, so an ir_number search can return several grouped rows for one IR. When you leave international_registrations unset, a request that carries a filter the grouped view can’t apply is answered with expanded rows instead: search_meta.international_registrations reads expanded and search_meta.warnings[] carries an expanded_fallback entry naming the filter in affected_filters. When you send international_registrations=grouped explicitly, the same request is a 400 validation_error instead, with errors[].code: unsupported_on_grouped and errors[].field naming the filter or option. Expanded rows have no coverage, and total_count counts designations, not marks. jurisdictions is the filter for “IRs designating this country”. The per-designation filters (offices, office, filing_route, filing_date_*, registration_date_*, expiry_date_*, registration_number, jurisdictions), together with status_primary, status_stage and nice_classes, must all hold on one record: the family’s own or one of its designations. jurisdictions=US&nice_classes=9 therefore needs class 9 on the US designation, and offices=US&status_primary=active needs an active USPTO record. Every designation counts, including a second record at the same office and the record not shown for a territory (listed in source_records). An owner, attorney or firm filter sent with a status or per-designation filter holds on that same record: attorney_id=…&status_primary=active needs an active record the attorney is on, either a designation or the IR’s own record. For an owner filter the IR’s own record counts as the owner’s, because an IR’s holder is the holder of its designations. Combined with any other filter, such as an entity or ir_number, a per-designation filter other than jurisdictions falls back. status_primary=mixed describes the whole family and does not combine with per-designation filters. These rules apply once search_meta.index_generation is 5; before that, jurisdictions and status or class filters hold on the family as a whole, an owner, attorney or firm filter matches anywhere in the family, the other per-designation filters combined with them fall back, and only the record shown for each territory matches. Known limitation: a text query (q and the mark_text_* filters and exclusions) on the grouped view is matched against the IR family’s mark text, while a per-designation filter matches any record it applies to. A linked national record whose mark text differs from its IR can therefore put a family in the results even though its record at that office carries different text. Designations share the IR’s mark text, so only linked national records are affected. Use international_registrations=expanded when you need the text and the office matched on the same record. offices matches the office a record comes from, so offices=CA finds CIPO records, not every IR designating Canada. See international_registrations for the full list. The mark_text_* filters and all exclusions are served on the grouped view. Id exclusions match at family level. An IR family is excluded when the owner or entity of any of its designations matches owner_id_not, entity_id_not, or entity_group_not. trademark_ids_not excludes the family when it names the family row’s id or the id of any designation.

Querying Madrid Marks

Find All Madrid Marks

# All Madrid designations
curl -s "https://api.signa.so/v1/trademarks?filing_route=madrid_designation" \
  -H "Authorization: Bearer sig_YOUR_KEY"

// All Madrid designations
const madridMarks = await signa.trademarks.list({
  filing_route: "madrid_designation",
});

// Shorthand: the is_madrid filter
const madridMarks2 = await signa.trademarks.list({
  is_madrid: true,
});

Find by IR Number

The ir_number is globally unique and does not require an office parameter:

curl -s "https://api.signa.so/v1/trademarks?ir_number=1234567" \
  -H "Authorization: Bearer sig_YOUR_KEY"

const marks = await signa.trademarks.list({
  ir_number: "1234567",
});
// Returns the IR family (grouped, by default) or every designation (expanded)

Coverage Territories

Retrieving an IR parent returns every designated territory inline under coverage. There is no separate coverage fetch: coverage.territories[] carries the full per-territory breakdown, and coverage.by_primary / coverage.by_stage give you the rollup counts. coverage is present only on the IR family row. It is absent on an individual designation leg and on direct or regional marks, which cover exactly one territory. The IR’s own WO record is not listed as a territory, so territory_count counts designations.

curl -s "https://api.signa.so/v1/trademarks/tm_abc123" \
  -H "Authorization: Bearer sig_YOUR_KEY" | jq '.coverage.territories[]'

const mark = await signa.trademarks.retrieve("tm_abc123");
for (const territory of mark.coverage?.territories ?? []) {
  console.log(
    territory.territory_code,
    territory.status.stage,
    territory.protection_status,
    territory.publication_date, // the WIPO Gazette date of this designation
    territory.trademark.id, // the designation record shown for this territory
    territory.office_code, // the office holding that record (US, or WO for a WIPO-feed record)
    territory.application_number, // its own serial at that office (a 79-series serial for a US designation)
  );
}

coverage.territories[].application_number and registration_number are the designation record’s own numbers at its office, so a per-office docket can be keyed from the grouped row alone. Pass international_registrations=expanded when you need one full row per designation.

Every entry, on search rows and on detail, carries territory_code, status {primary, stage}, protection_status, designation_date, protection_date, publication_date (the date the WIPO Gazette published the designation, null when Signa has none; not a national journal date), office_url, trademark {id, href} (the designation record Signa shows for the territory), office_code, application_number and registration_number. protection_date is usually null: read status and protection_status for where protection stands. When a territory has more than one record, Signa shows the national office’s record rather than WIPO’s copy of it. Among national records it shows a registered designation first, then a pending one, then a dead one, then one whose status is unknown, and the most recent when several are equally live or all are dead. So a country designated again after an earlier designation died shows the live later designation, provided Signa holds the national office’s record of it: a later designation that only WIPO’s record shows gives way to the earlier national record. protection_status and the coverage dates come from WIPO’s record of the designation shown, matched by date. When the country has one national record, WIPO’s record for that country is used even without a date match, unless one of the two says the designation is live and the other says it is dead. Otherwise they are null. Detail (GET /v1/trademarks/{id}) adds territory_name, refusal_date, status_effective_date, is_subsequent_designation, designation_protocol, goods_limitations[] and source_records[] (the WIPO/national reconciliation alternates for a dual-feed territory); search rows don’t carry them. An IR family’s classifications[] are the international registration’s goods, marked scope: "as_filed", not what each territory protects. coverage.territories[].goods_limitations lists, oldest first, what WIPO’s register records as narrowing that territory: a designation made for part of the goods, a limitation, a partial cancellation, a partial ceasing of effect when the basic mark lost goods, and a limitation the territory’s office does not recognize. Each entry names the Nice class, whether goods were removed (the whole class when goods_services_text is null) or the class was limited_to the listed goods, and the date it took effect. A limitation never changes the territory’s status. Signa reads these from WIPO’s ROMARIN feed, so an international registration whose ROMARIN history Signa has not read shows none; partial refusals are under refusal_date and the trademark’s events instead. Territories appear only where Signa holds a record of the designation, so an older international registration can list fewer territories than WIPO does. Check the WIPO register before you treat a territory list as complete.

Family status

A family lists every designated country Signa holds a record for, including designations whose current status WIPO’s data does not state, such as one under a recorded transfer. Such a territory reads status.stage unknown. When the national office’s record of the designation is available, the territory shows that record and its status instead. The family’s own status summarizes its territories, with status.basis: computed. status.primary and status.stage are each the value the territories share, or mixed when they differ. A territory whose stage is unknown is left out while at least one territory with a known status is live (active or pending), so it never makes a live family mixed. When every territory with a known status is dead, the family reads mixed: the designation whose status is unknown may still be protected. A family reads unknown only when every territory is unknown. coverage.by_stage.unknown counts the territories whose status is unknown. coverage.by_primary.unknown can be larger: some territories from WIPO’s data state a stage, such as registered, but no status.primary, and the family status reads their primary from the stage. For example, a family registered in the US and designating France, where WIPO’s data does not state the current status of the French designation, reads:

{
  "status": { "primary": "active", "stage": "registered", "basis": "computed" },
  "coverage": {
    "territory_count": 2,
    "by_primary": { "active": 1, "unknown": 1 },
    "by_stage": { "registered": 1, "unknown": 1 },
    "territories": [
      { "territory_code": "US", "status": { "primary": "active", "stage": "registered" } },
      { "territory_code": "FR", "status": { "primary": "unknown", "stage": "unknown" } }
    ]
  }
}

Read a territory’s own status before relying on protection in that country. protection_status values:

Status	Meaning
`designated`	Designation filed, examination pending
`provisionally_refused`	Office issued a provisional refusal
`finally_refused`	Protection definitively refused. Not emitted yet
`protected`	Protection granted
`withdrawn`	Designation withdrawn by the holder
`renounced`	Holder renounced protection in this territory
`ceased`	Protection ceased (e.g., central attack)
`invalidated`	Protection invalidated
`limited`	Goods/services limited in this territory. Not emitted yet
`expired`	Protection expired (not renewed)

Madrid-Specific Dates

Madrid marks carry additional date fields beyond the standard trademark dates:

Field	Description
`designation_date`	When the designation was filed at WIPO
`protection_effective_date`	When protection took effect in the designated territory. Null until the office reports it.
`dependency_period_end_date`	End of the 5-year dependency period tied to the base application. Currently null; derive it yourself as `intl_registration_date` + 5 years if you need it today.
`transformation_deadline_date`	Deadline to transform a cancelled designation into a national application. Currently null; derive it yourself as the central attack date + 3 months if you need it today.

The Dependency Period

For the first 5 years after international registration, a Madrid mark depends on its base application/registration at the office of origin. If the base mark is cancelled, refused, or surrendered during this period (a “central attack”), the international registration can be cancelled for all designated territories.

Transformation

If an international registration is cancelled due to a central attack, the holder can “transform” each designation into an independent national application within 3 months.

Madrid-Specific Deadlines

The deadline engine handles Madrid marks differently from domestic marks. Key differences:

Aspect	Domestic	Madrid
Renewal	Filed at the national office	Filed at WIPO (centralized)
US proof of use	Section 8 (domestic)	Section 71 (Madrid equivalent)
Trigger date	Varies by jurisdiction	The USPTO record’s `registration_date` (US Section 71: the date of the certificate of extension of protection, 15 U.S.C. 1141k; a WIPO-sourced US designation row does not carry it), `intl_registration_date` (WIPO renewal)

WIPO Renewal

International registrations are renewed centrally at WIPO every 10 years from the international registration date. This covers all designated territories at once.

Field	Value
Type	`international_renewal`
Trigger	`intl_registration_date`
Cycle	Every 10 years
Consequence	`lapse_of_international_registration`

Relationships

GET /v1/trademarks/{id} returns mark-to-mark links inline as relationships[]:

Relationship Type	Meaning
`based_on_basic_application`	The IR is based on this national application
`based_on_basic_registration`	The IR is based on this national registration
`transformed_from`	This national mark was transformed from a cancelled IR designation. Office-dependent: none of the offices Signa serves today reports it
`replaces_under_4bis`	Replacement under Madrid Protocol Article 4bis

The IR-to-designation link is not repeated here: it is coverage.territories[].trademark.id on the parent. trademark_id on a relationship is null when the counterpart is not a record Signa holds, which is the normal case for based_on_basic_* edges (the office reports them as a bare office code plus record number). Identify those by target_office_code and target_record_id.

curl -s "https://api.signa.so/v1/trademarks/tm_abc123" \
  -H "Authorization: Bearer sig_YOUR_KEY" | jq '.relationships[]'

const mark = await signa.trademarks.retrieve("tm_abc123");
for (const rel of mark.relationships) {
  console.log(rel.type, rel.direction, rel.trademark_id ?? `${rel.target_office_code}:${rel.target_record_id}`);
}

Getting started

Core concepts

Build with AI

Data

Monitoring

Working with the API

Use cases

How the Madrid System Works

Data Model

Designation

Querying an IR family

Querying Madrid Marks

Find All Madrid Marks

Find by IR Number

Coverage Territories

Family status

Madrid-Specific Dates

The Dependency Period

Transformation

Madrid-Specific Deadlines

WIPO Renewal

Relationships

​How the Madrid System Works

​Data Model

​Designation

​Querying an IR family

​Querying Madrid Marks

​Find All Madrid Marks

​Find by IR Number

​Coverage Territories

​Family status

​Madrid-Specific Dates

​The Dependency Period

​Transformation

​Madrid-Specific Deadlines

​WIPO Renewal

​Relationships

How the Madrid System Works

Data Model

Designation

Querying an IR family

Querying Madrid Marks

Find All Madrid Marks

Find by IR Number

Coverage Territories

Family status

Madrid-Specific Dates

The Dependency Period

Transformation

Madrid-Specific Deadlines

WIPO Renewal

Relationships