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

​
Overview

Compute maintenance deadlines for any set of trademarks (renewal windows, declarations of use, grace periods, and what happens if each is missed) without storing anything in Signa. Send the facts you already have: jurisdiction, filing and registration dates, status. Signa returns the exact dated obligations, computed from the same rules that power its trademark data. A missed renewal can cost a registration, and this is the deadline logic you’d otherwise build and maintain office by office, kept current behind a single request. Optionally send facts on an item to also compute prosecution deadlines: office action response periods and statement of use clocks, resolved per fact instance. Every computed prosecution date ships with the rule that produced it, the era it belongs to, when that rule was last verified, and the pinpoint sources behind it. Pair it with List Deadline Rules to inspect the underlying rules, renewal cycles, and statutory citations behind each computation.
facts is additive. For caller-supplied facts items, both prosecution fields (support and prosecution_deadlines) appear only on items that sent facts, and sending facts: [] opts in to the capability report without supplying any facts. Omitting facts does not mean the item is identical to what it was before this release: the same release adds rule identity, so every item now carries sources, as_of and computed_at, and every deadlines[] row carries rule_id, effective_from, last_verified, due_date_adjustment, grace_expiry_adjustment and holiday_calendar, with or without facts.

​
Prosecution coverage

Prosecution deadlines are not uniformly derivable, and the response says which of three states you are in rather than flattening them together. Read support[].status on each item: What that means per office today: Send { "id": "tm_..." } to resolve a stored trademark’s maintenance inputs and prosecution event facts server-side. Stored facts use events dated on or before as_of_date. The engine reports facts_required when available events cannot establish a deadline. Caller-supplied facts items remain supported and can be mixed with ID items; an item must use exactly one shape. Computation does not persist data. Madrid provisional refusals are being added to that history. Signa records each designated office refusal from the WIPO ROMARIN feed as an office_action event with event_scope: "designation" and the territory_code of the designation it refuses, so a mark’s refusal sequence (provisional refusal, then any Rule 18ter confirmation or further decision) is queryable per territory instead of collapsing into a single current status. When the feed names the classes a partial refusal hit, Signa stores one event per class with nice_class set; when it does not, the partial refusal is a single event with nice_class null. Coverage is filling in rather than complete. ROMARIN is a daily changed-marks feed and no historical backfill has been run, so an international registration gains its refusal history the next time it appears in a daily file. Treat an empty refusal history as “not yet loaded”, not as “no refusal”. The refusal date is there; the response period is not. ROMARIN publishes no time limit on a refusal record, so the Rule 17(2)(vii) period still has to come from the notification itself, as a stated_deadline fact.

​
Stored trademarks

ID items always include the prosecution capability report, even when no usable events are stored. Historical as_of_date filters the stored events by date; it does not reconstruct a historical version of the trademark record.

​
Request Body

​
object[]
required
Marks to compute, max 1,000 items. Results are returned in the same order, with one result per input item. A missing or non-retrievable ID produces a deadline_computation_error with id and error: { type: "not_found", detail }; other items still compute. Every item costs one check unit, including an unknown ID.Use either a stored ID object ({ "id": "tm_..." }) or the facts object below.
​
string
Calendar date to compute relative to, as YYYY-MM-DD. Defaults to today.
​
integer
How many years ahead to include. Minimum 1, maximum 20 (the horizon of every trademark derived block), default 5.
​
boolean
Include optional deadlines such as US Section 15 incontestability. Defaults to true.
​
boolean
Include deadlines already past their grace period. Defaults to false. A renewal cycle the office data proves paid is never returned as missed: every cycle before the office-stated expiry_date (or renewal_due_date), and the cycle a last_renewal_date paid, together with the restoration window such a cycle would open.

​
Response

A standard list response with data: DeadlineComputation[]. 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.
Terminal-dead statuses (abandoned, withdrawn, surrendered, invalidated, and refused, except the WIPO international registration record itself under a provisional refusal) return supported: true with an empty deadlines array. expired and cancelled marks return only their still-actionable rows: open late-renewal windows for expired, and restoration windows where the jurisdiction models them (GB, SG, IS, JP, IN, EU).

​
Rule provenance

Every computed row names the rule that produced it, so a date is never an unattributable number.
  • rule_id is stable and permanent. Once published, a slug is never renamed or repointed at different content, so it is safe to persist alongside your own records and to join against the rule catalog. It is opaque: us_renewal_s9 and eu_renewal look parseable, but the grammar is not part of the contract. Compare it for equality, nothing else.
  • effective_from answers “from when is this modelling authoritative?”, not “when did the statute change”. It is null for most rules, and non-null only where the corpus establishes a genuine boundary, for example a declaration-of-use requirement introduced on a known date, or a cohort the engine deliberately declines to compute before (Australian direct marks before 1996-01-01, Singapore direct marks before 1999-01-15). effective_from is a statement about the rule, and the date it should be compared against is rule-specific. Do not apply it as a blanket trigger_date < effective_from test: that flags correct rows as unreliable. The comparison date is the row’s trigger_date for the statutory-commencement and computability-cohort rules (mx_declaration_of_use_3yr, au_renewal, sg_renewal), and the engine already gates on it, so a row that exists at all is normally inside range. For no_renewal it is the renewal expiry being reconstructed, that is the row’s own due_date, because the boundary bounds the modelled renewal window rather than the mark’s trigger date: a Norwegian mark filed in 2018 with a 2028 renewal is entirely inside the modelled regime even though its trigger_date precedes 2024-03-02. That boundary is exact. It is the transitional cutover in FOR-2023-02-17-230, under which the previous 12-month window still governed registrations expiring before 2024-03-02, rather than the 2023-03-01 commencement of the amending statute, so a row whose due_date is on or after effective_from reports the window that actually applied, and one before it does not. For opposition rules (on Compute Oppositions) it is the publication date the window runs from. If you cannot make the rule-specific comparison, show effective_from as provenance rather than deriving a reliability flag from it.
  • last_verified is when Signa last checked the rule against its sources. It moves on verification passes even when nothing about the rule changed.
  • sources carries the statutory citations for the jurisdiction configuration behind the item, once per item rather than once per rule or once per row.

​
Business-day adjustment

Some offices roll a deadline that lands on a weekend or public holiday forward to the next business day. Where Signa models that, the computed date is already rolled, and the row reports what happened: due_date and grace_expiry_date are evaluated separately, so one can be moved while the other is not_checked on the same row. holiday_calendar describes configuration, not what happened to a given date. Where a calendar is wired it stays non-null on every row for that office, including rows whose dates report not_checked, so holiday_calendar: "ipos_singapore" next to grace_expiry_adjustment: "not_checked" reads correctly as “a calendar is configured, but it does not cover that date”. holiday_calendar: null means no calendar is configured at all, and every adjustment on that row is therefore not_checked. window_opens is never business-day adjusted in its own right. It is the first date a filing is accepted, not a deadline, so it is reported as the statute states it. One inherited exception: a restoration row’s window_opens is the parent renewal’s grace expiry, which has already been rolled where that jurisdiction opts into business-day adjustment (Singapore and Japan today; Great Britain, Iceland and India do not opt in, so their restoration windows open on an unrolled date).

​
Code Examples

​
Computing an office action response deadline

Response fragment:
The fragment above abbreviates two fields for length. rule.sources carries six entries on this rule (37 CFR 2.62, 37 CFR 2.6, TMEP 310, 37 CFR 2.196, 37 CFR 2.66, and 37 CFR 2.6 again for the petition-to-revive fee), and each quoted_text is the full statutory extract, truncated here at the trailing …. The row itself also carries linkage_quality ("explicit" here), low_confidence (false), notes ([]) and the fields that are null on this example: rejected_stated_due_date, closed_by_fact_id, closed_by, stated_by_fact_id and stated_basis.