Skip to main content
POST
Compute Oppositions
Credits: 10 per item.

Overview

Compute the opposition window for a published mark (when it opens, when it closes, and how much time is left) from a publication date, without storing anything. Opposition windows are short, unforgiving, and specific to each office. When a conflicting mark publishes, the oppose-by date is what separates a cheap, procedural opposition now from a costly cancellation later. Send a publication date and Signa returns the window, its current status, any routine extensions, and the office rule behind it. Pair it with List Opposition Rules to inspect the office rules, trigger events, time zones, extensions, and citations behind each computation.
This endpoint computes the forward-looking opposition window (dates and timing) from a publication date. It does not return opposition cases that have actually been filed. For filed opposition, cancellation, and appeal cases, use Search Proceedings.

Request Body

object[]
required
Publications to compute, max 1,000 items. Results are returned in the same order, with one opposition_window per input item.
string
Office-local calendar date to compute relative to, as YYYY-MM-DD. Defaults to today.

Response

A standard list response with data: OppositionWindowComputation[]. Pagination is not used; data[i] corresponds to items[i].
string
Always list.
object[]
boolean
Always false.
object
Always { "cursor": null }.
string
Unique request identifier for support and debugging.
Every item carries the same key set, supported or not: unsupported items null the window fields rather than omitting them. rule_id and effective_from are the exception. They report the rule Signa resolved for the office and filing route, and that resolution either succeeded or it did not, independent of whether a window came out of it. So an unsupported item still carries them whenever a rule was found, which keeps it joinable to List Opposition Rules. They are null only when no rule exists for that office and route. Three cases end in supported: false:
  • No rule for the office or route. reason: "unsupported_office", rule_id: null, effective_from: null.
  • A rule exists but does not reach the publication or filing date. reason: "before_commencement", rule_id names the rule and effective_from names the date it starts from. A Vietnamese publication from 2022 reports rule_id: "vn_opposition" with effective_from: "2023-01-01", because opposition under art. 112a only applies from that date. Recompute with a publication date on or after effective_from and the same rule returns a window.
  • The window could not be computed. This is now a NARROW case: a close date past the office calendar’s covered years that falls in the 20 days before the date you are computing as of, where a rollover could still be holding the window open and guessing either way would be wrong. reason: "window_not_computable", affecting that item only. rule_id and effective_from are populated; every other window field, including rule_version, is null. Every OTHER out-of-coverage close, meaning one in the future, one falling exactly on the as-of date, and one more than 20 days before it, is published with close_adjustment: "not_checked" rather than declined, after the deterministic roll over weekends and the fixed holidays the calendar computes from the law. Silence on a rights-losing deadline is worse than an early date, and an unverified close is never later than the true one. This is what a calendar built from annual office notices (China, India) does for every window closing in a year whose notice is not yet published.
Two more shapes are not unsupported items, and both come back supported: true, status: "unknown", and window_opens, window_closes, days_until_open and days_remaining all null. rule_id, effective_from, rule_version, source, trigger_event and the office fields are populated as usual in each. reason is what tells them apart.
  • No publication date. Omit publication_date and the rule still resolves and applies; there is simply no trigger to compute from. reason stays null: the null publication_date already says it.
  • The wrong publication. Send a publication_date_kind that is not the one the matched Madrid rule runs from (or the explicit unknown), and the rule declines rather than dating the window from a publication it does not recognise. reason is publication_date_kind_mismatch.
Do not read supported: true as “there are dates”: check status or the window fields.

Code Examples