Changelog

September 11, 2026: Fee endpoints accept platform office codes

GET /v1/fees and POST /v1/fees/estimate now take the office spellings the rest of the API takes. office, and each entry in designations[], used to accept only the WIPO ST.3 codes WO, US, EM and GB, plus WIPO as an alias for WO. They now also accept the platform office codes USPTO, EUIPO and UKIPO, and the permanent EU alias for EM, in any case, exactly as GET /v1/trademarks?offices= does. A request that used to come back with an empty catalog or an unsupported_office line only because of how the office was spelled is now priced. The change is additive, and it is resolution only. Responses echo the canonical ST.3 code, so {"office": "USPTO"} returns "office": "US". No amount, currency or catalog row changes for any request that was already priced, and an office with no verified schedule still returns an empty catalog or an explicit unsupported_office line rather than a guessed amount. Two spellings of one designated office now collapse to one code before the uniqueness check, so designations: ["EM", "EU"] is rejected as a duplicate instead of being counted twice. dataset_version on POST /v1/fees/estimate changes with this release because it covers estimator semantics as well as the fee rows. The rows themselves are untouched.

September 6, 2026: Portfolios are public

Portfolios are now a documented resource family. The nine portfolio operations (create, list, retrieve, update, delete, add and remove trademarks, and the JSON and iCalendar deadline views) appear in GET /v1/openapi.json under a Portfolios tag, grouped under “Filing & docketing”, with reference pages and a portfolios guide. Nothing about the endpoints themselves changed: same paths, same portfolios:manage scope, same read metering (1 unit per request, including writes and calendar downloads), same plan gating. The catalog operations GET /v1/classifications, GET /v1/classifications/{classNumber} and GET /v1/goods-services also move from the Reference Data tag to Classification, which is where the rest of the classification surface already lives. Tags are documentation grouping only; no path, parameter or response shape changed. Three error types that portfolios return are now in the error reference: 409 resource_quota_exceeded, 409 portfolio_in_use and 422 portfolio_too_large. The TypeScript SDK’s generated types caught up with the published spec. @signa-so/sdk 0.12.0 regenerates api-types from the same spec build the published document uses. That adds 37 operations and 21 schemas, and removes nothing. Nine operations and two schemas are the portfolios surface. The other 28 operations and 19 schemas (watches, alerts, webhooks, events, monitoring status) were already published in GET /v1/openapi.json but were missing from the generated types, because SDK codegen ran against a narrower build of the spec than the one we publish. No existing operation or type changed, so the update is additive for every consumer.

September 5, 2026: Auth hardening, `plan_gated`, prefixed watch filters

Three visible changes from the auth and tenancy hardening pass (the first and third have been live since 2 September; the watch-filter change lands today). None of them alter a successful response. 403 plan_gated replaces a misleading 429. Calling a capability that is not on your plan at all (for example image search on free) used to return 429 rate_limited with retry_after: 0, which sent SDK retry loops spinning. It now returns 403 plan_gated with endpoint_type naming the capability and retryable: false. See the error reference. Watch filters echo prefixed IDs. query.filters.trademarkIds, ownerId, attorneyId and firmId on every watch response (REST and MCP) now come back as tm_* / own_* / att_* / firm_*, whichever form you sent. Input still accepts both, so nothing you send changes. Stricter bearer parsing, clearer outages. Authorization is single-valued (RFC 7235): a comma-joined pair of credentials is a 400. The scheme is case-insensitive. A missing header gets a bare WWW-Authenticate: Bearer challenge with no error code (RFC 6750 §3.1). When Signa’s own token verifier or JWKS is unreachable, MCP requests get a retryable 503 service_unavailable instead of being told the token is invalid.

September 3, 2026: prosecution deadlines are served outside calendar coverage

A prosecution deadline is no longer withheld because its office calendar cannot check the date. Bounding euipo_alicante to the two Executive Director decisions actually pinned (2025 and 2026) had a consequence we did not intend: every EU office action mailed before 2025, and every one mailed from 1 November 2026 onward (a two-month period lands in 2027), came back insufficient_facts with reason holiday_calendar_out_of_coverage and no date at all. The same held for US office actions before 1985. Silence on a deadline whose miss abandons the application is the worst possible answer. Those cases now return outcome: "computed" with the raw statutory anniversary. An office action mailed 10 January 2024 at the EUIPO reports due_date: "2024-03-10"; one mailed 1 November 2026 reports "2027-01-01". This matches what the renewal engine (due_date_adjustment) and the opposition engine (close_adjustment) have always done. An un-rolled date is never LATER than the true deadline, so it can be early but cannot cause a missed one. New field: due_date_adjustment on every prosecution deadline. It tells you which kind of date you are holding, using the same vocabulary as the renewal rows:

moved: the office calendar was consulted and rolled the date forward off a day the office is shut.
unchanged: the calendar was consulted and the date was already an open day.
not_checked: no calendar verdict stands behind the date. Either the date falls outside the calendar’s pinned coverage, the rule ships without a roll rule, or the office stated the date itself (a stated deadline is published exactly as stated and never rolled). Treat it as the raw statutory anniversary and confirm before relying on the exact day.
null: no date was produced at all.

holiday_calendar_out_of_coverage remains in the reason vocabulary but is now a backstop for a calendar-integrity failure rather than the ordinary out-of-coverage answer. No shipped rule reaches it today. close_adjustment on a trademark summary row is no longer nullable. The same marker was declared nullable on the summary row’s opposition_window and non-nullable on the detail tier’s derived.opposition_window. It can never be absent while its parent object exists, so the two now agree and the nullability sits where it belongs, on opposition_window itself. If you null-checked the field, that check is now dead code; nothing you were reading changes value. Search and opposition-compute deliberately disagree for 20 days after an un-rolled close. Where close_adjustment is not_checked and the close is within the last 20 days, search buckets the mark as open (a rollover could only have pushed the close later) while POST /v1/oppositions/compute reports closed against the un-rolled date. Search’s reading is the safe one. Search documents in that band also now carry the un-rolled close rather than no opposition window at all; a full reindex populates them.

September 3, 2026: France, Finland and Poland Madrid designations get opposition windows

Three new rules. An international registration designating France, Finland or Poland had no opposition window at all: POST /v1/oppositions/compute, the derived block, GET /v1/opposition-rules and watch diagnostics all returned nothing for those rows. fr_opposition_madrid, fi_opposition_madrid and pl_opposition_madrid now answer. France, two months from the WIPO Gazette. CPI art. R. 717-1 applies the whole domestic opposition procedure to an international registration extended to France, and art. R. 717-5 names the publication the art. L. 712-4 two months run from: WIPO’s Gazette, not any INPI republication. There is no first-of-the-following-month offset, unlike Switzerland and Germany. INPI’s own directives work the case: an IR published in Gazette 2019/23 of 20 June 2019 has an opposition period expiring 20 August 2019. Every other mechanic is the domestic one by statute rather than by copy, including the art. R. 718-2 same-numbered-day arithmetic, the roll off weekends, jours fériés and INPI closure days, and the extra month for the exposé des moyens. One documented limit, and it is a hard gate. The rule reports effective_from: "2009-01-01" and applicable_from_date: "2009-01-01". The version of art. R. 717-5 in force before that date ran the period from the first day of the month after INPI received the Gazette, an internal office event that no register record carries. We decline that era rather than guess it, so a French designation published before 2009 comes back supported: false with unsupported_reason: "unsupported_office" and the rule identity intact, effective_from naming the boundary. Finland, two months from PRH’s own publication. Tavaramerkkilaki 544/2019 92 § 5 mom. has PRH publish the international registration in the same words 24 § uses for a national one, and 88 § 2 mom. applies the Act to an IR except where the Madrid chapter says otherwise, which it does not for opposition. So 32 §‘s two months from the publication day carry over, with the 150/1930 month-end clamp and the roll off a pyhäpäivä or a working Saturday. PRH’s own gazette confirms it: record W202600336 is an international registration with oppositionPeriodStartDate equal to its publication date. Poland, three months from the BUP announcement. PWP art. 152^1a ust. 1 has UPRP announce a designation of Poland in the Biuletyn Urzędu Patentowego without delay, and art. 152^6a ust. 1 gives an earlier-right holder three months from that announcement, non-restorable. The Biuletyn states the same sentence for both routes. The window opens the day after publication and closes on the same-numbered day three months later under KPA art. 57 § 3, rolling off statutory non-working days and Saturdays under § 4. The rule reports effective_from: "2016-04-15", the commencement of art. 152^6a: before that date there was no pre-grant opposition against a designation of Poland at all. Which publication your date is. All three rules declare it, so the publication_date_kind guard applies. FR needs wipo_gazette; FI and PL need office_journal. Send the other one and the response is status: "unknown" with null dates and the rule’s identity intact, rather than a date you should not act on. Omit the field and nothing changes. Reindex required after the backfill. These windows appear on documents that carry none today, and opposition_window_opens / opposition_window_closes are baked into search documents at index time. Request-time surfaces (POST /v1/oppositions/compute, the derived block, the SDK) are correct the moment this deploys. The opposition_status and opposition_closes_after filters will not see the new windows until French, Finnish and Polish Madrid designations carry an office publication date from the designation-publication backfill and are reindexed. No window we already serve MOVES: no publication date is reinterpreted and no existing pair of dates changes. One thing that does change shape: opposition_window stops being null for WIPO-feed legs. A designation leg that reaches us through the WIPO feed carries office_code = "wipo" with the designated country in jurisdiction_code, which never matched a rule keyed on the designated office’s code. Those legs now resolve by jurisdiction, so for EVERY Madrid jurisdiction we model — not only the three new ones — derived.opposition_window turns from null into an object. Until the leg carries an office publication date the object’s dates are all null and status is "unknown", and opposition_rule_version in search documents becomes non-null after the next reindex where it was null before. If your integration reads opposition_window === null as “Signa does not model opposition for this mark”, that inference no longer holds: check status and window_closes instead. A null opposition_window now means only that no rule matched the office, route and publication era at all. No United Kingdom rule yet. A UK Madrid designation still returns no window. UKIPO runs its three months from the UK Trade Marks Journal, and the current Journal source is not available to us to pin, so the rule is held rather than written from an unverifiable source.

September 3, 2026: holiday calendars now stop where their evidence stops

Some deadline dates move EARLIER, and more of them report not_checked. Every office holiday calendar Signa ships now advertises coverage only as far as the instruments actually pinned behind it. Eight of them are built from a document the office issues once a year: a decision, a notice, an acuerdo, a proclamation, an office memorandum. Those now stop at the last one pinned instead of projecting forward:

Calendar	Covered through	The instrument
`euipo_alicante`	2025-01-01 to 2026-12-31	EUIPO Executive Director decisions EX-24-9 and EX-25-16
`mx_mexico`	2026-11-30	IMPI Acuerdo de días inhábiles, DOF 5769863
`dk_denmark`	2026-12-31	DKPTO lukkedage
`fr_france`	2026-12-31	INPI Director-General closure decision
`ph_philippines`	2026-12-31	Presidential holiday proclamations
`cnipa_china`	2026-12-31	国务院办公厅 annual notice
`cgpdtm_india`	2026-12-31	DoPT holiday Office Memorandum
`wipo_geneva`	2026-12-31	WIPO Information Notice 40/2025

Beyond those horizons nothing is guessed. A renewal or grace date comes back UNROLLED with due_date_adjustment / grace_expiry_adjustment set to "not_checked", and an opposition window is served with its close on the exact statutory day. Unrolled is never LATER than the true date, so a date we serve can be early but cannot cause a missed deadline. The calendars that are genuinely rule-computed (US, Canada, Germany, Australia, Brazil, Benelux, Switzerland, Finland, UK, Iceland, Norway, Poland, Sweden) still run to 2100, and the lunar ones (Singapore, Thailand, Vietnam, Japan, Korea, Türkiye) to 2030, unchanged. EU: the invented years are gone, and EU dates in 2024 and earlier are no longer rolled. euipo_alicante carried closure days for 2024 and for 2027-2030 that no Executive Director decision states. The 2027-2030 entries were labelled “estimate” and moved deadlines LATER: a day after Ascension, in-lieu Mondays, 4 January 2027, 6 December in four different years, and the two decisions that ARE pinned falsify the pattern they were derived from (EX-24-9 closes for Ascension, Schuman Day and the Assumption; EX-25-16 closes for none of the three and adds Santa Faz, 12 October and 2 November). The 2024 block said “per prior EX decision” and no such decision exists in our evidence. All of it is deleted. Consequences, both directions:

EU opposition closes for 2027 and later are no longer rolled. A window whose close lands on a weekend or a 2027 Spanish feast is now served on the raw statutory date. Example: an EU application published 30 November 2026 closes 28 February 2027 rather than 1 March 2027.
EU dates before 2025 are outside the calendar. An EU office-action response deadline computed from a 2024 mailing is no longer rolled against the unpinned 2024 block. Superseded the same day: this originally returned insufficient_facts with reason holiday_calendar_out_of_coverage. It now returns the un-rolled statutory date with due_date_adjustment: "not_checked". See the entry above.

Mexico: December of the last pinned year is honest about being unknown. IMPI declares each year-end shutdown in the FOLLOWING year’s acuerdo, so the acuerdo for 2026 states every día inhábil of 2026 except the December closure. mx_mexico therefore stops on 30 November 2026. Before this change, an MX opposition window closing 22 December 2026 was served as a working day and reported closed on 24 December, while IMPI was in fact shut. It now reports window_not_computable until the acuerdo covering December 2026 is published. A roll can no longer walk off the end of a calendar. The coverage check ran only on the date being rolled, not on the days the roll walked through. A deadline on a listed year-end closure could therefore step into the following, uncovered year, where every day looks open, and stop on the first of January. WIPO 31 December 2026 reported 1 January 2027 as moved; DKPTO 28 December 2026 reported 4 January 2027. Both now report not_checked and serve the unrolled date. Mexico closes on 25 December. mx_mexico was missing Christmas Day from its recurring días inhábiles, although the one pinned acuerdo that lists a whole year without folding December into a closure block (DOF 5580658) ends «DICIEMBRE Viernes 25». MX deadlines falling on 25 December now roll to the next working day, LATER by one to four days, in every covered year. Iceland: no change, and now only one story about why. 24 and 31 December stay closed on is_iceland, on Hugverkastofan’s own December 2020 notice that the office is shut all day and that deadlines falling there move to the next opening day. Five documents still described these as open days under a superseded reading; they now all state the ruling that shipped. Þorláksmessa (23 December) is declared year by year and stays OPEN. No date moves. Reindex needed for EU and MX opposition windows. Opposition windows are baked into search documents at index time. EU documents whose window closes in 2027 or later, and MX documents whose window closes in December 2026, carry the old rolled close until the affected records are reindexed. Request-time surfaces (/v1/oppositions/compute, /v1/deadlines/compute, the derived block) are correct on deploy. DK, FR, PH and IN opposition windows move only for close dates past their horizons; reindex those offices with the same pass.

September 3, 2026: `close_adjustment` on every opposition window

New field: was this close date checked against a holiday calendar? close_adjustment now appears on POST /v1/oppositions/compute, on the derived.opposition_window block of a trademark, on the opposition_window of every trademark summary row and on the opposition block of GET /v1/watches/{id}/diagnostics. It reads moved (the close fell on a day the office is shut and was rolled forward), unchanged (the calendar was consulted and the close was already a business day) or not_checked, meaning no calendar stands behind this date. not_checked is not new behaviour, only newly visible. Several office calendars are built from an annual notice (China’s State Council holiday notice, India’s DoPT memorandum, the Philippine proclamations, Mexico’s IMPI acuerdos, WIPO’s non-working-days notice), so a window closing in a year whose notice is not yet published has always been served with raw statutory arithmetic. A rollover can only move a close later, so an un-rolled close is correct-or-early: safe to act on, never a reason to file late. Until today nothing on the wire told the two apart. The opposition_status search filter now treats an un-rolled close as indeterminate. For the 20 days after a not_checked close date, a row counts as open and is excluded from closed, because the rollover that could not be applied may still be holding the window open. not_started and unknown are unchanged, because the opening date is never rolled. Reindex required to populate. The marker is baked into the search index at index time (opposition_close_adjustment, an additive keyword field, so no alias swap, no new index generation). Documents indexed before this release carry no value and are bucketed by their dates alone, exactly as they were before; the indeterminate band applies to them only after a reindex. Every request-time surface (/v1/oppositions/compute, the derived block, watch diagnostics) recomputes and is correct immediately. Also: POST /v1/oppositions/compute declines with window_not_computable in fewer cases. A close falling exactly ON the date you compute as of is now published un-rolled instead of declined: a rollover can only push it later, so the window is open either way. The narrow band that still declines is a close strictly 1–20 days before the as-of date.

September 3, 2026: opposition rule catalog reports both eras

Five new fields on GET /v1/opposition-rules (and the MCP get_opposition_rules): window_change_date, window_starts_on_before, window_months_before, window_days_before and window_ends_on_before. An opposition rule models a regime change inside itself, and the catalog used to serve only the current era, so a client reproducing a close date for a publication before the pivot got the wrong length, the wrong start convention, or both, with nothing on the wire to say so. A publication strictly before window_change_date is governed by the _before fields. All five are null on a rule that has never changed. (A previous entry said era behaviour was already reported through window_starts_on / window_ends_on. It was not; this is the change that makes it true.) One existing value changes: window_ends_on is now era-scoped. bx_opposition opens on the first of the following month only in its pre-1 October 2013 era, so its corresponding_day_of_start describes THAT era. It now reads window_ends_on: null with window_ends_on_before: "corresponding_day_of_start" instead of claiming the current era ends that way. The current BX era anchors the close on the publication day-number and never reads the field. BX is the only affected rule; no computed date moved.

September 3, 2026: rule corrections (CN, PH, CH, CA, DE, MX)

China: the 2027 straddle is served the SHORTER window. The 2026 revision of the Trademark Law cuts the opposition period from three months to two on 1 January 2027 and carries no transitional provision for a period still running on that day: art. 87(2) speaks only of registered marks. The two readings differ by up to a month, so Signa serves the shorter one to the straddling cohort: every CN publication from 1 October 2026 (the first whose three months would still be open at commencement) is now given two months. A mark published 31 December 2026 closes 28 February 2027, not 31 March 2027. A close published too early costs a would-be opponent nothing they can lose by relying on it; one published too late costs the right itself. The call is reversible and will flip the day a transitional notice or the revised Implementing Regulations settles the question. (This supersedes the “Applications published in November and December 2026 keep three months” sentence in the CNIPA entry below.) Reindex: CN opposition windows are index-baked, but CNIPA is a planned office with no indexed records, so there is nothing stale. Philippines: the advisory extension is era-aware. IPOPHL MC 2022-013 introduced the once-only 45-day extension on 30 June 2022. A window that closed BEFORE that date is now served the earlier regime instead: three 30-day extensions on motion, capped at 120 days from publication (MC 16-007 § 12). Display-only: common_extension never affects window_closes. Switzerland (Madrid): the served citation is the operative one. A CH Madrid window used to cite MSchG art. 31(2), whose words run the period “after the publication of the registration”, the national trigger, which this rule never uses. It now cites MSchV art. 50(1), the provision that actually fixes day zero at the first of the month following the WIPO Gazette issue. No date moved; source on the response and sources[0] in the catalog change. Version stamps. ca_opposition, bx_opposition, ch_opposition_madrid and ph_opposition report a new last_verified / rule_version of 2026-09-03. BX and CH had moved served values in an earlier release without moving the stamp. Canada’s two common_extension notes also now name the CIPO practice notice section in full (“section X.1, Extensions of time - benchmarks”) instead of an abbreviation that read as an unfilled placeholder. No computed date moved for CA, CH, BX or DE.

September 3, 2026: maintenance deadline corrections (EU, MX, NO, CA)

Five corrections to POST /v1/deadlines/compute, the derived block on a trademark, and portfolio deadline rows. Maintenance deadlines are computed at request time, so every change below is live the moment it deploys, so no reindex is needed and no stored date changes. A missed EU renewal’s restitutio date moves earlier, by up to two weeks. EUTMR Article 104(2) admits an application for re-establishment “within the year immediately following the expiry of the unobserved time limit”, less the Article 53(3) further six months, so the long stop is the renewal expiry plus twelve months. Signa counted those months from the grace expiry as served, which had already absorbed one Article 69(1) working-day extension, and then extended the sum again. A EUTM filed 21 December 2014 was told its restitutio window ran to 5 January 2026; it runs to 22 December 2025. EUIPO Guidelines Part E §7.4.2 states the rule the fix implements: the extension “applies only once and to the end of the basic period”. The window still OPENS on the grace expiry as served. The same single-extension arithmetic now applies to every restoration window (EU, GB, IN, IS, JP, SG); where the grace expiry did not move, nothing changes. A Mexican Madrid designation now renews on WIPO’s calendar. The renewal of an international registration designating Mexico is paid to WIPO’s International Bureau under Madrid Protocol Article 7 (IMPI never receives it), so Reglamento LPI art. 4o does not reach it. An IR registered 29 February 2004 was given a Mexican due date of 1 March 2014 under art. 4o’s month-end overflow, one day after the international registration had actually lapsed; it is now due 28 February 2014, exactly matching the WIPO row for the same registration, with holiday_calendar: "wipo_geneva". Mexico’s three-year declaration of use is a Mexican filing on IMPI’s own grant date and is unaffected. Norwegian renewal due dates are no longer rolled. Betalingsforskriften § 6 extends a frist, and the § 33 renewal request period is one, so its late end, the grace expiry, still rolls to the next virkedag. The due date is not a frist: it is the end of the registration period, and varemerkeloven § 33 første ledd tredje punktum charges the tilleggsavgift for a request delivered “etter utløpet av registreringsperioden”. A due date served on the Monday would have advertised a surcharge-free filing day after the period had already ended. A Norwegian mark filed 1 May 2016 is due 1 May 2026, not 4 May, and its due_date_adjustment reads not_checked. Grace expiries are unchanged. This is the same treatment Australia has had since the s 223A(1) wiring, and GET /v1/deadline-rules now says so explicitly (below). An office-stated 29 February expiry no longer returns an empty schedule. A mark whose office-reported expiry fell on a leap day could return zero deadlines: a live EUTM two months from expiry, with nothing to file against. Three separate pieces of leap-day arithmetic compounded; all three are fixed, and such a record now returns its renewal row on the office’s own date. Canada: last_renewal_date is a new optional field on compute. Trademarks Regulations s. 159 opens the first post-17-June-2019 renewal window at the period start, and it keys on the renewal, not on the cycle’s due date. A registration whose term ended shortly before that day but whose fee was paid in the grace period on or after it is the s. 159 renewal; the one after it is an ordinary s. 76 renewal. Send last_renewal_date on a compute item and Canada uses it. Omit it and the previous due-date behaviour is unchanged. GET /v1/deadline-rules and the get_deadline_rules MCP tool gain grace_expiry_rolls_only. A boolean, present on every row. When true, the jurisdiction rolls its grace expiry but never its renewal due date, which is what Australia and Norway do. weekend_holiday_rule: true alone could not express that, so a docketing system reading the catalog had no way to tell a scoped roll from a full one. Additive: no existing field changed.

September 3, 2026: China (CNIPA) deadlines and opposition windows

New jurisdiction. POST /v1/deadlines/compute, POST /v1/oppositions/compute, the derived block on a trademark, GET /v1/deadline-rules and GET /v1/opposition-rules now answer for Chinese marks. Three rules ship: cn_renewal, cn_opposition and cn_opposition_madrid. office: "CN" is accepted on the oppositions endpoint and comes back as CN. A Chinese term counts its first day. Under Implementing Regulations art. 12(2) a registration’s ten years run from the day the office approves it and INCLUDE that day, so the term ends the day BEFORE the anniversary: a mark registered 7 March 2016 expires 6 March 2026, not 7 March. The 12-month renewal window and the 6-month grace period are measured from that expiry. Where the anniversary day does not exist in the target month, the expiry is the last day of that month instead: a mark registered 29 February 2020 expires 28 February 2030. Opposition: three months now, two from 1 January 2027. Trademark Law art. 33 gives three months from the preliminary-approval publication (初步审定公告, not the registration publication), counted from the day after and ending on the same day-of-month three months later. The 2026 revision of the Trademark Law cuts that to two months in its renumbered art. 36 and enters into force on 1 January 2027 (art. 87). Both eras are modelled now, selected by the publication date, and each window is served the article that states its own length. Applications published in November and December 2026 keep three months: the revision carries no transitional provision, and that is the non-retroactive reading. Madrid designations of China use a different anchor. CNIPA does not republish an international registration, so the window runs off the WIPO Gazette: Implementing Regulations art. 45(1) opens it on the FIRST DAY OF THE MONTH FOLLOWING the Gazette issue and runs three months to the last day of the third month, which is CNIPA’s own worked example (Gazette 16 January 2012 → 1 February to 30 April 2012). Supply the Gazette issue date as the publication date for these rows. Holiday calendar, and where it stops. Chinese deadlines roll to the first working day when they fall on a statutory holiday, and the calendar is built from the State Council’s annual holiday notice, including the make-up working weekends (调休), where a Saturday or Sunday is declared a working day. A renewal due on Friday 2 January 2026 is due on Sunday 4 January 2026, the first working day, not Monday the 5th. Because each year’s notice is published only the preceding November, coverage runs 2024–2026: dates beyond it are reported unrolled rather than rolled against a guess: renewals with due_date_adjustment: "not_checked", and an opposition window with its close on the exact statutory day. Unrolled means EARLIER than the true date, never later. The one exception is a window that closed within the last 20 days beyond coverage, where a roll could still be holding it open: there the window is returned unsupported_reason: "window_not_computable" with its rule identity intact rather than risk labelling a live window closed. Coverage extends when the 2027 notice is published. Reindex: none needed today. Opposition windows are baked into search documents at index time, so a new rule normally reaches already-indexed documents only after a reindex. Here there is nothing to reindex: CNIPA is a planned office and Signa holds no Chinese records in the search index yet, so no stored value changes and no document can be stale. Request-time surfaces (/v1/deadlines/compute, /v1/oppositions/compute, the derived block, the rule catalogs) answer for China on deploy, and the index-time path will pick the rules up with the first CNIPA ingestion. Should any Chinese records be indexed before then, they would need a reindex to gain opposition_window_opens / opposition_window_closes; nothing they carry would be wrong.

September 3, 2026: Benelux opposition windows before 1 October 2013 corrected

Historical dates change for bx_opposition. The two-month Benelux opposition period has not always run from the publication day. Until 30 September 2013 BVIE art. 2.14(1) counted it “te rekenen vanaf de eerste dag van de maand volgende op de publicatie van het depot”, from the first day of the month FOLLOWING publication. The Protocol of 22 July 2010 (art. I.D) replaced those words with “te rekenen vanaf de publicatie”, and it entered into force on 1 October 2013 (Trb. 2013, 135). Signa was applying the current text to every publication, however old. A Benelux application published on 12 June 2013 was reported as open from 12 June to 12 August 2013 when the window the law gave ran from 1 July to 1 September 2013, a close up to 30 days EARLY. Only publications before 1 October 2013 are affected, every one of those windows is long closed, and no status changes; what changes is the pair of dates we report about them, which matters wherever a historical window is cited in a dispute or an audit trail. The rule carries both the superseded article text and the amending Protocol as pinned, era-bounded citations, so a pre-2013 window is served the text that actually governed it. (This entry originally said GET /v1/opposition-rules reported the era behaviour through window_starts_on / window_ends_on. It did not; those fields describe the current era only. The era fields shipped on 3 September 2026; see the entry at the top of this changelog. BX now reports window_change_date: "2013-10-01", window_starts_on_before: "first_of_following_month" and window_ends_on_before: "corresponding_day_of_start", with window_ends_on: null.) Era selection keys on the publication date, which is the only date either text can be read on. Neither Protocol carries a transitional provision. One documented limit follows: for a mark published between 1 August and 30 September 2013 the old text’s window was still running when the new text took effect, and no source says which governs. We serve the old rule, and therefore the later close, which is the conservative direction for anyone deciding whether they may still oppose. Reindex. Opposition windows are baked into search documents at index time, so pre-2013 Benelux documents keep the old opposition_window_opens / opposition_window_closes values until BOIP records are reindexed. Every affected window is closed and none of them can change opposition_status, so this is low priority and belongs with the next natural BX reindex rather than with a dedicated run. Request-time surfaces are correct on deploy.

September 3, 2026: German Madrid designations get an opposition window

New rule de_opposition_madrid. An international registration designating Germany had no opposition window at all: POST /v1/oppositions/compute, the derived block, GET /v1/opposition-rules and watch diagnostics all returned nothing for a DPMA Madrid row. That was honest, because the rule could not be expressed, but silent, and the deadline it hides is a hard statutory bar. MarkenG § 114(1) puts the WIPO gazette in the place of the Markenblatt publication of a national registration, and § 114(2) starts the § 42(1) three months on the first day of the month following the gazette’s issue month. Because that start is the beginning of a day, BGB § 187(2) counts it and § 188(2) Alt. 2 ends the period the day before the corresponding day: the last day of the third month. A gazette issued in March 2026 opens the window on 1 April 2026 and closes it on 30 June 2026; an issue in November 2026 runs 1 December 2026 to 28 February 2027, which is a Sunday, so BGB § 193 and DPMAV § 18a roll it to 1 March. The fee (250 EUR, plus 50 per further sign) falls due inside the same period, and the window is not extendable. MarkenG § 91(1) sentence 2 bars even Wiedereinsetzung. Worth noting next to the Swiss correction in this same release: Germany and Switzerland start their Madrid windows on the same day and close them one day apart. MSchV art. 2 ends a Swiss period on the corresponding day, BGB § 188(2) Alt. 2 ends a German one the day before. window_ends_on on GET /v1/opposition-rules reports which reading each rule applies. No German source gives a worked example of the end day, so it is derived from the two BGB provisions and cross-checked against the DPMA’s own Richtlinie W 7736, which states the start in the office’s voice; the derivation is recorded in the evidence pack rather than asserted. Reindex. Opposition windows are baked into search documents at index time, and DE Madrid documents currently carry null windows, so the opposition_status and opposition_closes_before / opposition_closes_after filters will not see this rule until German Madrid designations are reindexed. Request-time surfaces are correct on deploy. As for Switzerland, the reindex only becomes meaningful once designation records carry the WIPO gazette publication date the rule anchors on.

September 3, 2026: Swiss Madrid opposition windows close up to 30 days earlier

Computed dates change for ch_opposition_madrid, in the safe direction. The opposition window against an international registration designating Switzerland does not run from the day the WIPO Gazette published the designation. MSchV art. 50(1) starts it on the first day of the month following the Gazette month, and MSchV art. 2 ends a month period on the same-numbered day, so the window closes on the 1st of the fourth month. The IGE publishes the worked example: a Gazette of 19 July 2022 opens the window on 1 August 2022 and closes it on 1 November 2022. Signa was computing “Gazette day plus one month” to “Gazette day plus four months” instead. That is the same answer only when the Gazette date is itself the 1st; for every other issue the close we published was up to 30 days later than the law allows. A Gazette of 15 January 2026 was served a close of 15 May 2026 where the true, non-extendable deadline is 1 May 2026. Later than the truth is the dangerous direction on an opposition bar, so this is a correction customers should re-docket: every Swiss Madrid close moves earlier by nought to thirty days, and every open moves to the 1st of the month. GET /v1/opposition-rules now reports window_starts_on: "first_of_following_month" and window_ends_on: "corresponding_day_of_start" for this rule, and window_starts_offset_months is null. Both enums are new and additive; no existing value changed meaning. Trademark responses, the oppositions compute endpoint, the derived block and watch evaluation recompute the window per request, so they are correct as soon as this deploys. Reindex. Opposition windows are baked into search documents at index time, so opposition_status and the opposition_closes_before / opposition_closes_after filters carry the old arithmetic until Swiss Madrid documents are reindexed. In practice there is nothing to correct yet: a designation is indexed as part of its international-registration family, and IR-family documents carry null opposition windows today, while the Madrid source we ingest publishes no per-designation publication date for the rule to anchor on. The reindex therefore belongs with the work that starts storing the WIPO Gazette publication date for designations, not with this change.

September 3, 2026: Norway Madrid opposition, and a publication-date guard for every Madrid rule

New rule. no_opposition_madrid covers an international registration designating Norway. Patentstyret publishes in Norsk varemerketidende that the IR has effect in Norway (varemerkeloven § 70 annet ledd, varemerkeforskriften § 32), and § 71 første ledd gives anyone three months from THAT kunngjøringsdag to oppose, applying § 26 correspondingly. So every mechanic of the Norwegian domestic rule carries over by statute rather than by copy: the count starts on the publication day itself, the three-month period ends on the corresponding day-number, it rolls off 24 and 31 December, Saturdays, helligdager and likestilte dager under betalingsforskriften § 6, and it cannot be extended. There is no WIPO offset — § 71 runs straight from Patentstyret’s own publication, unlike EUIPO’s Madrid-EU rule. The 18-month Madrid refusal limit is an obligation the office owes WIPO and never changes the three months the parties get. GET /v1/opposition-rules, POST /v1/oppositions/compute (office NO, filing route madrid) and the derived block on a Norwegian Madrid designation now answer instead of returning nothing. One documented limit. The rule reports effective_from: "2010-07-01" and applicable_from_date: "2010-07-01", the day varemerkeloven — the Act § 71 belongs to — entered into force (res. 25. juni 2010 nr. 936). Before it the repealed 1961 Act § 21 gave TWO months from the kunngjøringsdag, an era we do not model on the Madrid route, and serving the modern three months to it would report a close date a month LATER than the law gave. A Norwegian designation published before 1 July 2010 therefore comes back supported: false rather than with a window. No reindex required. This adds a window where there was none; it changes no existing window. Baked opposition_window_opens / opposition_window_closes values in the search index are all still correct. Norwegian Madrid designations pick their new window up at their next natural reindex. A guard against the wrong publication. A Madrid designation has two publications that can fill one date field — WIPO’s Gazette of the international registration, and the designated office’s own journal republication — and different offices run their clock from different ones. Feeding a rule the other one silently produces a plausible-looking, wrong statutory bar. Each Madrid rule now declares which publication it needs, and POST /v1/oppositions/compute accepts an optional publication_date_kind (office_journal, wipo_gazette, office_register, unknown) saying which one your date is. When the two disagree the response is status: "unknown" with null dates and the rule’s identity intact, rather than a date you should not act on. A new nullable reason field on each POST /v1/oppositions/compute item and on the trademark derived.opposition_window block says WHY it is unknown ("publication_date_kind_mismatch" today, null otherwise), so you can tell a contradicted publication kind from a mark that simply has no publication date yet; the field is additive and null on every response that had no reason to carry it. Omit the field and nothing changes. Today EVERY Madrid rule declares its publication: ch, de and fr run from the WIPO Gazette; no, fi, pl, sg, us, ca, au, eu, jp, kr, in and tr run from the designated office’s own journal. Declaring it is not optional in practice. A WIPO-feed leg is resolved by jurisdiction, and the date it carries is the Gazette’s — so a rule that has NOT adjudicated which publication it runs from is refused on that path outright rather than dated on a publication nobody established it uses. The four Asian Madrid rules (jp, kr, in, tr) were adjudicated for this release; each of their statutes names the office’s own gazette and says the WIPO Gazette is not the trigger.

September 3, 2026: EU restitutio, Canada’s transitional renewal window, India’s priority-dated term, and WIPO closure days

Four deadline corrections, all computed at request time. Nothing is baked into the search index, so every one of them is live the moment this deploys and no reindex is involved. The EU now has a restoration deadline. POST /v1/deadlines/compute, GET /v1/deadline-rules and the derived block on an EU trademark return a new restoration row once a renewal has passed its due date, under one new rule_id: eu_restitutio. It runs from the end of the six-month grace period to twelve months after the registration expired, which is what Article 104(2) EUTMR leaves after deducting the further six months of Article 53(3) from the year following the missed time limit, and what the EUIPO Guidelines state in one sentence: the one-year period “starts on the day on which the protection ends and not on the expiry of the further 6-month grace period”. Read the row as an outer date, not as a promise. Restitutio is discretionary: it is granted only where all due care required by the circumstances was taken, it carries a fee, and it must also be requested within two months of the removal of the obstacle, a date no register publishes. No existing EU date moves. Canada’s first renewal after 17 June 2019 opens far earlier than we said. For a trademark that was on the register before that day, Trademarks Regulations s. 159 lets the renewal fee for the FIRST renewal falling due on or after it be paid from the start of the period being renewed, with no six-month early limit, and CIPO says so directly: “there is no restriction on how early the renewal fee for the first renewal after June 17, 2019 may be submitted.” The engine used to report that window opening six months before the due date. window_opens on the affected cycle now moves back to the day of registration or of last renewal, which can be fifteen years earlier. Only that one cycle is affected; the due date, the grace expiry and every later cycle are unchanged, and the window can only widen, so nothing that was filable becomes unfilable. An Indian trademark with a convention priority claim expires earlier than its filing date implies. Trade Marks Act 1999 s. 154(2) registers a Paris or WTO convention application as of the date the application was made in the convention country, and s. 23(1) is expressly subject to it, so the ten-year term of s. 25(1) runs from the priority date, up to six months before the Indian filing. POST /v1/deadlines/compute accepts a new optional priority_date on each item; send it for an IN item and the renewal is computed from it, with trigger_field reading priority_date so the answer says which date it used. Omit it and India falls back to the filing date exactly as before. The field is inert for every other jurisdiction: no other pinned term provision runs from a priority date. Note the current limit: our own stored trademarks carry priority claims in a separate record, so the derived block, portfolio deadline lists and the iCal feed do not yet pass one and still serve the filing-date answer for that cohort, which is the later date. Where the office states an expiry, that expiry already anchors the schedule and the question does not arise. WIPO renewal dates now move off days the International Bureau is closed. Rule 4(4) of the Regulations under the Madrid Protocol extends a period that expires on a day the IB is not open to the public to the first subsequent day it is, and a renewal payment is a communication the IB must receive. WIPO rows now report holiday_calendar wipo_geneva, and a due date or grace expiry that falls on a weekend or on one of the eight days WIPO published for 2026 (1 January, 3 and 6 April, 14 and 25 May, 31 July, 25 and 31 December) is served on the next open day with the adjustment field reading moved. An international registration dated 13 June 2016, for example, was renewable “by 13 June 2026”, a Saturday; the answer is now Monday 15 June 2026. The International Bureau publishes its closure list one year at a time, so the calendar covers 2026 only: dates in any other year are emitted exactly as the Rule 4(1) and 4(2) arithmetic produced them and report not_checked rather than a business-day guarantee we cannot make. Filing-window opening dates are never rolled, on any office. Every value above cites the instrument it comes from, with a verbatim quote and a hash-pinned snapshot, on GET /v1/deadline-rules and on each compute response.

September 3, 2026: Mexican OPPOSITION windows follow the same month-overflow rule, and the overflow is now reported

Opposition close dates change for MX (IMPI). Reindex MX. Earlier today Signa applied Reglamento de la Ley de la Propiedad Industrial art. 4o, párrafo segundo to the Mexican maintenance ladders: a period counted in months that ends on a day the target month does not have runs into the following calendar month and ends on its first business day, rather than clamping to the short month’s last day. The opposition engine kept the clamp, which was stated as a limit in that release. It no longer does. Art. 4o computes «los plazos establecidos en meses o años a que se refiere el artículo 184 de la Ley», and art. 184 LPI (re-enacted word for word as LFPPI art. 21) is the Law’s general period-computation article, not a maintenance-only provision. The one-month opposition period of LFPPI art. 221 is a period fixed in months by the Law, so it is inside art. 4o. An application published on 31 March 2026 now closes for opposition on Monday 4 May 2026, not 30 April: April has no 31st, so the period runs into May, and May 1 is Día del Trabajo with the weekend behind it. A publication on 31 August 2026 closes 1 October instead of 30 September. Publications whose day number exists in the next month are untouched. Every corrected date is LATER than the one Signa served before, so nobody who relied on the old date filed late. GET /v1/opposition-rules gains month_end_overflow on every rule, so a client that recomputes a window from the rule can reproduce the close date. It reads last_day everywhere except mx_opposition. The overflow move is now reported. due_date_adjustment and grace_expiry_adjustment on POST /v1/deadlines/compute gain a fourth value, month_end_overflow. Before this, an overflow that landed on an open day was indistinguishable from a date nothing had happened to: the fields described the weekend and holiday roll only, so they read unchanged. The new value subsumes the roll on such a date, because art. 4o para. 2 names the first BUSINESS day of the following month, so the move into the next month and the roll that completes it are one statutory step. The addition is additive: no existing value was renamed or removed. Opposition windows are baked into the search index at index time, so the materialised opposition_status and opposition_closes_before/opposition_closes_after filters on MX documents are corrected only after MX is reindexed. POST /v1/oppositions/compute and the trademark response recompute per request and are correct as soon as this deploys.

September 3, 2026: Mexican deadlines now roll, month-overflow ends in the next month, and Madrid designations renew on the international registration

Computed dates change for MX (IMPI), on both engines. Reindex MX. Mexican maintenance dates were published raw: a renewal that fell on a Sunday or on a day IMPI declares inhábil was served on that day. Reglamento de la Ley de la Propiedad Industrial art. 4o, the 1994 regulation the LFPPI keeps in force, says otherwise in its third paragraph, and Signa now applies it. A renewal due date, grace end or 3-year declaration-of-use window end that lands on a weekend, on a fixed Mexican holiday or on a día inhábil IMPI has published moves to the next working day, holiday_calendar reads mx_mexico, and the two adjustment fields read moved or unchanged. Filing windows never move: a window that opens on a closed day cannot be filed that day, and moving it would shorten the statutory six months. The same article’s second paragraph fixes a subtler error. When a period counted in months or years ends on a day the target month does not have: a six-month grace counted from a 31st, landing on “31 February”. Mexico does not clamp to the 28th the way most offices do. The period ends on the first business day of the following calendar month. A grace period that used to read 28 February 2033 now reads 1 March; in a leap year, 29 February 2036 becomes Monday 2 March 2036. This is the first office in the corpus to depart from the month-end clamp, and it is behind a per-office flag, so no other jurisdiction’s dates move. The IMPI holiday calendar was rebuilt from the Diario Oficial. It carried a flat “IMPI closes 16 to 31 December, every year” block that no published acuerdo supports. IMPI sets its year-end closure annually: 18 December to 2 January for 2024, 19 December to 3 January for 2025, 22 December to 6 January for 2026. So the old calendar closed four days IMPI works and opened five days it does not, in both directions. It also omitted 5 May and 1 September, which four published acuerdos name. The calendar is now eleven recurring days plus exactly what each pinned acuerdo states, including the one-off closures of 1 October 2024, 12 December 2025, 23 February 2026 and 30 June 2026. Madrid designations of Mexico now renew on the right date. A designation has no independent Mexican term: it expires with the international registration and is renewed centrally at WIPO. The rule that served it was Mexico’s national “renewal plus declaration of use”, which the engine anchored on IMPI’s grant date, and for a designation granted years after the international registration, that is a renewal date up to a decade too late. There is now a separate rule, mx_renewal_madrid, anchored on the international registration date, and a designation whose international registration date is unknown and whose office expiry is not on the record DECLINES with requires_office_date instead of publishing a guess. The declaration of use that follows a Madrid renewal runs three months from the International Bureau’s notice, a date no record carries, so Signa deliberately publishes nothing for it rather than a wrong date. Every Mexican value is now cited to the Diario Oficial de la Federación itself (the primary publication) with a verbatim quote and a pinned snapshot, with the consolidated ordenjuridico.gob.mx copies kept alongside. That includes the eight IMPI acuerdos behind the calendar. Three limits are stated rather than hidden. IMPI publishes each December’s closure in the preceding autumn, so a year with no published acuerdo has no closure in Signa: a date in late December 2026 or later is served un-rolled, which is earlier than the true date, never later. The opposition engine still applies the ordinary month-end clamp rather than art. 4o’s overflow rule, again in the earlier direction. And the overflow move itself is not reported in the adjustment fields, which describe the weekend and holiday roll only. Trademark responses and POST /v1/deadlines/compute recompute per request, so they are correct as soon as this deploys. Opposition windows are baked into the search index at index time, so the materialised opposition_status and opposition_closes_before/opposition_closes_after filters on MX documents are corrected only after MX is reindexed.

September 3, 2026: Australian renewal grace periods roll onto the next open day

An Australian trade mark can still be renewed for six months after it expires (Trade Marks Act 1995 s 79). When the last day of that six-month period falls on a weekend, a Canberra public holiday or IP Australia’s standing Christmas close-down, POST /v1/deadlines/compute and the derived block on a trademark now serve the next day the office is open, and say so in grace_expiry_adjustment (moved) and holiday_calendar (au_australia). Australian grace dates were previously served one to three days EARLY. The renewal DUE date deliberately does NOT move, and this is the only office where the two answers differ. s 223A(1) rolls “the last day of a period provided by this Act (except this section) for doing an act”; the s 79 period is one, reg 21.24A supplies the prescribed circumstance and reg 21.24C, the exclusion list, does not reach a renewal request. The twelve-month renewal REQUEST period is a different animal: it is prescribed by reg 7.3 rather than by the Act, and Schedule 9 item 10 keys the $100-per-month surcharge on the request being made “after the expiry date to which section 79 of the Act refers”: the expiry day itself. Serving a later due date would tell you that you may still renew fee-free on the Monday when the surcharge may already have attached on the Saturday. So an Australian due_date stays on the statutory expiry and reports due_date_adjustment: "not_checked" on every row, whatever day of the week it lands on: no calendar was consulted for it, and unchanged would claim a Saturday is a business day. Nothing else about the Australian rule changed: same rule_id (au_renewal), same ten-year term, same twelve-month window, same six-month grace, same consequence. Three provisions are newly pinned and quoted verbatim next to the field they move: s 223A(1), reg 21.24A, and reg 21.24C in full, so that the absence of a renewal request from the exclusion list is verifiable rather than asserted. Maintenance deadlines are computed per request, so this is live as soon as it deploys and no reindex is required. It supersedes the “Australia is deliberately NOT rolled” note in the entry below.

September 3, 2026: renewal dates roll on closed office days in Norway, France and Iceland, and on BOIP’s own closing days in the Benelux

Four offices join the maintenance rollover: a renewal due date or grace expiry that lands on a day the office is closed is now served on the next day it is open, instead of on the exact calendar date. POST /v1/deadlines/compute and the derived block on a trademark answer with the moved date and say so in due_date_adjustment / grace_expiry_adjustment (moved, unchanged or not_checked) and holiday_calendar. Nothing about a rule id, a window length or a consequence changed; only the served dates. Each office rolls on the provision that governs its own renewal deadline, not on a generic weekend rule. Norway: betalingsforskriften § 6 første ledd (24 and 31 December, Saturdays, helligdager and days the legislation treats as equivalent), extended to varemerkeloven deadlines by § 6 tredje ledd. France: CPI R. 718-2 al. 5, applied to the renewal declaration by INPI’s own renewal directives, which work the example: a mark expiring Saturday 14 May 2022 could be renewed on Monday 16 May with no late-renewal fee. Iceland: Stjórnsýslulög nr. 37/1993 8. gr., which extends a period ending on a general public holiday to the next day the authority is OPEN. Benelux: Uitvoeringsreglement regel 3.9, lid 3. Every one is pinned and quoted verbatim next to the field it moves. Two office calendars were corrected from primary sources in the same change, and both corrections can move a date on their own. The Benelux calendar is now BOIP’s own closing-day list, published as a Regel van de Directeur-Generaal of 3 April 2019, rather than an assumed Dutch national-holiday set. Ten days join it: 2 January, 1 May, Europe Day, the Luxembourg and Belgian national days, Assumption, All Saints, All Souls, Armistice Day and the Belgian King’s Day, and Good Friday LEAVES it, because the rule names it on neither limb and BOIP is open that day. A Benelux deadline falling on Good Friday is therefore due that day, not the following Tuesday. Iceland’s 24 and 31 December STAY CLOSED, and no Icelandic date moves on that account. An earlier draft of this release opened both days: they are public holidays only FROM 13.00 under lög nr. 88/1971 6. gr. (24 December only from 18.00 as a church holiday, lög nr. 32/1997 2. gr.), so the statute alone gives a half day, and no ISIPO closure notice had been found. One was then found: Hugverkastofan’s own December 2020 notice, which says the office is closed on Þorláksmessa, aðfangadagur and gamlársdagur and that every deadline falling in that period moves to the next opening day. The office’s own statement settles the office’s own opening days, so both remain closed, exactly as before this release. See “Philippines, India and Iceland business-day calendars re-sourced” below. Benelux opposition windows DO move, because Good Friday left bx_benelux. Opposition windows are materialised into search documents at index time, so opposition_status and the opposition_closes_* filters carry the corrected dates for BX records only after that office is reindexed. Every trademark response recomputes the window per request and is correct as soon as this deploys, and maintenance deadlines are computed per request throughout, so no reindex is needed for them. Australia was NOT rolled in this change, and the reason was documented rather than hidden: Trade Marks Act 1995 s 223A(1) settles the six-month post-expiry limb but not the due date, and the rollover was one switch that moved both dates. SUPERSEDED the same day by the entry above, which gives the engine a grace-only roll and turns it on for Australia. Two accuracy limits are recorded with the same candour. INPI closure decisions before 2026 were never fetched, so a French date that fell on a pre-2026 closure day is served un-rolled. BOIP publishes any FURTHER closing day for a given year on a page that is not reachable programmatically, so those ad-hoc days are not modelled either. Both under-roll rather than over-roll.

September 3, 2026: EUIPO Article 2 days now extend time limits; `consequence_if_missed` vocabulary fixed

EU dates move later on four days a year. The euipo_alicante calendar now carries BOTH lists of the Executive Director’s annual decision on non-working days: the Article 1 days on which the Office is closed AND the Article 2 days on which the Office is open but ordinary post is not received (19 March, 23 June, 9 October, 8 December in EX-24-9 for 2025 and EX-25-16 for 2026). Article 69(1) EUTMDR extends a time limit expiring “on a day on which the Office is not open for receipt of documents or on which … ordinary post is not delivered in the locality in which the Office is located … until the first day thereafter on which the Office is open for receipt of documents and on which ordinary mail is delivered”, and the Office’s own decision reads it the same way (EX-24-9 recital (1)(b)). Until now only Article 1 days rolled, which served the earlier date; the served date is now the statutory one. Affected: POST /v1/oppositions/compute and opposition_window for EM marks whose window closes on one of those days (e.g. a Part A publication on 9 July 2026 now closes 13 October 2026, not 9 October), the EU office-action response deadlines, and the watch-evaluator’s opposition windows. Opposition windows are baked into the search index at index time, so indexed EM documents carry the corrected close only after the EU reindex (scheduled with this release). The 2027-2030 Article 2 days are carried on the same estimate basis as the Article 1 days and are replaced each December from the published decision. EU RENEWAL dates move on the same days. An earlier draft of this entry said they did not, on the ground that the EU maintenance config does not business-day adjust. It does now: the same release turns on the roll for EU renewals, so a eu_renewal due date or grace expiry landing on any day the Alicante calendar carries, Article 1 closures and Article 2 ordinary-post days alike, is served on the next open day instead. A mark filed 19 March 2016 was served a renewal due 19 March 2026 and a grace expiry 19 September 2026; it is now due 20 March 2026 with grace to 21 September 2026, because 19 March is San José, an Article 2 day. The direction is later, and later is the safe direction for a renewal: the office is shut on the original date, so the served day is the first one on which you can actually file. due_date_adjustment and grace_expiry_adjustment read moved on those rows and unchanged on the rest, so a row always says whether a calendar was consulted. Renewal dates are not baked into the search index, so no reindex is needed for this half. consequence_if_missed now means one thing per value. The value names the mechanism the office’s pinned provision prescribes: expiration (the right ends by operation of law), removal_from_register (the office strikes the entry as the statutory consequence), cancellation (the office cancels a still-running registration for a missed maintenance filing, US §8/§71), and restorability is said only by the presence of a restoration rule. Nine rules were relabelled to match their pinned text; no date moved: pl_renewal cancellation → expiration (PWP art. 168 ust. 1 pkt 1 “wygasa”), fr_renewal cancellation → expiration (CPI L. 712-1), de_renewal cancellation → removal_from_register (§ 47 Abs. 6 MarkenG “gelöscht”), dk_renewal cancellation → removal_from_register (varemærkeloven § 37 “udslettelse”), eu_renewal cancellation → removal_from_register (Art 53(8) EUTMR “cancel the mark from the register”), bx_renewal irrevocable_loss → expiration (BVIE art. 2.26(a)), ch_renewal irrevocable_loss → removal_from_register (MSchG art. 35(b)), mx_declaration_of_use_3yr irrevocable_loss → expiration (LFPPI art. 233 “caducará de pleno derecho”), th_renewal removal_from_register → expiration (Trademark Act s. 56 deems the registration revoked). irrevocable_loss is retired: no rule serves it. The full vocabulary is in the deadline rules guide. No wire-format change: the field stays a string and no new value was added.

September 3, 2026: Philippines, India and Iceland business-day calendars re-sourced

Three office calendars used for business-day adjustment now rest on the primary instruments that actually set the closed days, and two of them change published dates. Philippines (ph_philippines, used by ph_opposition). The closed days are now transcribed year by year from the presidential proclamations that declare them, Proclamations 368 s. 2023, 453, 514, 579 and 665 s. 2024 for 2024; 727 and 729 s. 2024, 839, 878 and 911 s. 2025 for 2025; 1006 s. 2025, 1189 and 1264 s. 2026 for 2026, together with the statutory fixed days (RA 9492 s. 1, RA 10966) computed for every year. Three curated days were wrong and move: Eid al-Fitr 2025 is 1 April (not 31 March), Eid al-Adha 2025 is 6 June (not 7 June) and Eid al-Fitr 2026 is 20 March (not 21 March). Days the proclamations make working days are now OPEN (25 February 2025 and 2026; 21 August 2024, observed on 23 August), and days they add are closed (9 February 2024, 12 May 2025, 31 October 2025, 2 November 2026, every Christmas Eve). For 2027 onward, until each year’s proclamation is pinned, only the statutory fixed days are closed and the “Monday nearest” holidays are open: an opposition close on one of those days is published un-rolled, which is never later than the true date. The opposition extension note now cites IPOPHL Memorandum Circular 2022-013 itself: one 45-day extension, granted only once, on meritorious grounds, reckoned from the original due date, in force 30 June 2022. India (cgpdtm_india, new). Indian deadlines are now business-day adjusted. The Trade Marks Registry observes the annual DoPT Office Memorandum for central government offices; the 2024, 2025 and 2026 memoranda are pinned and their 14 compulsory holidays per year make up the calendar. in_renewal, in_restoration, in_opposition and in_opposition_madrid now report holiday_calendar: "cgpdtm_india" and moved / unchanged for 2024–2026 dates: a renewal due on Sunday 15 June 2025 is served as Monday 16 June; an opposition closing on Republic Day 2026 is served as 27 January. Dates after 2026 report not_checked until the 2027 memorandum is pinned. Three limits are documented, all in the safe direction: the three branch-local optional holidays (Mumbai, Delhi, Kolkata, Chennai and Ahmedabad differ), Ambedkar Jayanti, and any moon-sighting shift of an Islamic day are not modelled, so a deadline on one of them is published un-rolled. Iceland (is_iceland). No date changes. 24 and 31 December stay closed, now on the office’s own statement (Hugverkastofan’s December 2020 notice: closed on both days, deadlines falling on them move to the next opening day) and the statutes that make them half-day frídagar; 23 December stays open because the office declares it year by year. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. The materialised opposition_status and opposition_closes_before/opposition_closes_after search filters are baked at index time: IN and PH search documents carry the rolled and corrected closes only after those offices are reindexed. Maintenance rows are computed per request and need no reindex.

September 3, 2026: Korea (KIPO) deadline and opposition rules

New jurisdiction. KR now has a maintenance config and two opposition rules, so GET /v1/deadline-rules, GET /v1/opposition-rules, POST /v1/deadlines/compute, POST /v1/oppositions/compute (office KR) and the derived block on a trademark answer for Korean marks instead of returning nothing. Three new rule_id values: kr_renewal, kr_opposition, kr_opposition_madrid. Renewal runs 10 years from the REGISTRATION date (상표법 제83조①), with a 12-month filing window before the term ends that closes on the expiry day and a 6-month window after it at 330,000 KRW per class instead of 300,000 (제84조②, 제78조③). Korean law has no restoration of a missed renewal application and no declaration of use, so neither is emitted — that absence is the finding, not a gap. Opposition is 30 days from KIPO’s own 출원공고 for applications published on or after 22 July 2025 (법률 제20697호), and 2 MONTHS for publications before that day; an international registration designating Korea is opposed on the identical window, running from KIPO’s publication rather than the WIPO Gazette (제180조①). Every value cites the Act, the fee rules or the KIPO publication it comes from, with a verbatim quote and a pinned snapshot. Two things about dates deserve a direct statement. First, the 22 July 2025 change is the first opposition pivot that switches UNITS — calendar months before, a day count after — and the engine now resolves the era’s length with its unit; nothing moves for any other office. Second, Korean deadlines are business-day adjusted against the kipo_korea calendar, which this release corrects from primary sources: 1 May (노동절) is now a closed day in every year — 상표법 제16조제4호 names it, and the shipped calendar had omitted it — with a Saturday/Sunday substitute from 2026; 17 July (제헌절) is closed from 11 May 2026, when the amended 관공서의 공휴일에 관한 규정 made every 국경일 a public holiday again; and 28 September 2026 is OPEN, because the regulation substitutes a 설날/추석 day only when it falls on a Sunday and 26 September 2026 is a Saturday. A KIPO deadline that lands on one of those days moves accordingly. Four limits are documented rather than hidden. The renewal window_opens is one day earlier than KIPO’s own count (KIPO opens the window the day AFTER expiry minus one year); it is never rolled and never a deadline. Election days and 임시공휴일 designated by government notice are not in the calendar until the notice is pinned, so a deadline landing on one is published un-rolled — earlier than the true date, never later. A renewal filed ON the expiry day is modelled as surcharge-free, which is how KIPO’s example reads. And a Madrid designation is computed only when its international registration date is known: the KIPO connector must carry the IRN, and its publication date for a designation must be KIPO’s own 출원공고일. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. Only the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters are baked at index time, so KR search documents carry these values only after KR is reindexed; no KR records are indexed today, so that reindex belongs with the KIPO connector rather than with this change.

September 3, 2026: Türkiye dates now roll, pre-2018 renewal windows and the 2017 opposition straddle corrected

Computed dates change for TR (TÜRKPATENT), on both engines. Three of the limits documented when Türkiye landed on 2 September are closed. Business-day adjustment is now applied. A Turkish renewal due date, grace end or opposition close that falls on a Saturday, Sunday, one of the fixed holidays of Law 2429 (1 January, 23 April, 1 May, 19 May, 15 July, 30 August, 29 October) or a Ramazan or Kurban Bayramı day is served on the next working day, so holiday_calendar reads turkpatent_turkiye and the two adjustment fields read moved or unchanged for dates in 2024 to 2030 (not_checked outside that range, where the calendar is not curated). The bayram days come from Diyanet İşleri Başkanlığı’s official tables for each year; the arefe half days, the afternoon of 28 October and the Presidency’s ad-hoc administrative leave days are working days and never move a date. This rests on a documented convention rather than an office statement: no TÜRKPATENT source states how a last day on a non-working day is treated before the office, and the roll applies the rule the general procedural statutes give the courts (HMK 6100 m. 93/1, İYUK 2577 m. 8/2). Direction of the change: every affected date moves LATER, by one to five days (for example, a renewal due on 1 May 2026, a Friday holiday, is now served 4 May; an opposition closing on 27 May 2026, the first day of Kurban Bayramı, is now served 1 June). Renewal cycles whose anniversary fell before 10 January 2018 now show the request window the repealed KHK 556 m. 41/3 gave them: window_opens and due_date move to the last day of the anniversary’s month (up to 30 days later than before), while grace_expiry stays on the exact anniversary plus six months, because m. 41/5 anchors the lapse on the end of the term. Every such cycle is historical (visible with include_missed); no current deadline moves. Opposition windows for applications filed before 10 January 2017 but published on or after it now get the three months the KHK gave them (SMK geçici m. 1/1 concludes an application under the law in force on its filing date), one month later than before; the served citation follows. Windows for applications filed on or after that date are unchanged. POST /v1/oppositions/compute accepts an optional filing_date per item for this; omit it and the item falls back to the publication date, which yields the shorter modern window. This filing-date key applies to national applications (tr_opposition) only. Madrid designations (tr_opposition_madrid) stay keyed on the publication date: a designation’s filing_date is the international registration date, and a subsequent designation of Türkiye carries no date of its own, so a filing-keyed pivot would have served a subsequent designation made after 10 January 2017 on an older international registration three months instead of the two SMK m. 18/1 gives it, one month too late. An original designation on a pre-2017 international registration published on or after 10 January 2017 is therefore served two months where the KHK arguably gave it three; every such window closed in 2017. Trademark responses and POST /v1/deadlines/compute recompute per request, so they are correct as soon as this deploys. TR reindex required: the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters read window dates baked at index time, so Turkish search documents carry the rolled and filing-keyed close dates only after TR is reindexed.

September 3, 2026: Danish renewal dates on office closing days now roll

Computed dates change for DK (DKPTO). A Danish renewal due date or grace end that falls on a Saturday, Sunday, a Danish public holiday or one of DKPTO’s enumerated closing days is now served on the next working day, as the office’s own Varemærkehåndbog states (“Er sidste rettidige indbetalingsdato en dag, hvor Patent- og Varemærkestyrelsen ikke har åbnet … så er betaling førstkommende hverdag rettidig”) and as dkpto.dk/lukkedage confirms for the closing days (“På officielle lukkedage, vil alle frister automatisk blive forlænget til førstkommende hverdag”). Rows now read holiday_calendar: "dk_denmark" with moved or unchanged adjustments instead of not_checked. Direction of the change: dates move LATER only, by one to seven days (a mark registered 10 January 2017 was due 10 January 2027, a Sunday, and is now due 11 January; a renewal due 28 December 2026 rolls through the 28 to 30 December closure, New Year’s Eve, New Year’s Day and the weekend to 4 January 2027). Marks whose dates already fall on a working day do not move. Computed at request time; no reindex (maintenance deadlines are not indexed).

September 2, 2026: Philippines Renewal DAU window opens six months earlier

Computed dates change for PH (IPOPHL). The ph_declaration_of_use_renewal rule (the Declaration of Actual Use due within one year of each renewal) used to open its filing window at the renewal itself. IPOPHL’s Trademark Regulations of 2023 (Memorandum Circular 2023-001, in force 14 February 2023) say in Rule 206 that “The Renewal DAU may be filed within the six-month period before the expiration of the registration”, so the window now opens six months before expiry - together with the renewal window - for every renewal cycle expiring on or after 14 February 2023. Cycles that expired before that day keep the old window: the change is modelled as an era pivot inside the rule, keyed on the cycle, not on today’s date, and a window for a cycle expiring inside the first six months of the new regime opens on 14 February 2023 itself, because no filing could precede the Regulations that permit it. Only window_opens moves. due_date and grace_expiry are unchanged (one year after the renewal, no grace), and so is every other Philippine rule. The customer-visible effect is an earlier window_open status: a mark registered 5 January 2020 now shows its first Renewal DAU window opening 5 July 2029 instead of 5 January 2030. Under the 2017 Regulations (MC 17-010) Rule 206 was only a transitional trigger, which is why the earlier window is right for the earlier cycles; both texts are pinned with verbatim quotes, and the in-force date is pinned from WIPO Lex because the circular’s own Rule 1406 carries it handwritten. Maintenance deadlines are computed per request, so no reindex is involved.

September 2, 2026: Philippines Madrid designations get their own DAU anchors

Computed dates change for PH (IPOPHL) international registrations. Two new rule_id values, ph_declaration_of_use_3yr_madrid and ph_declaration_of_use_5yr_madrid, serve marks on the madrid route. Under IPOPHL’s Madrid Regulations (MC 17-011, Rule 20) the 3rd-year DAU of an international registration designating the Philippines runs “within three years from the date of the international registration” and the 5th-year DAU “within one (1) year from the fifth anniversary of the date of statement of grant of protection” - not from the national filing and registration dates the ph_declaration_of_use_3yr and ph_declaration_of_use_5yr rules use. Those two rules now apply to the national route only (applies_to: domestic); the Madrid rules read applies_to: madrid_only, trigger on intl_registration_date and protection_grant_date respectively, and are absent when the record does not carry that date rather than guessed from another one. A designation with no international registration date still returns no schedule at all (requires_office_date), as before. The Renewal DAU and Mid-Renewal DAU are unchanged for designations: Rule 20 runs them from the renewal of the registration, which for an international registration is the WIPO renewal on the international registration date the renewal row already uses. One limit is documented rather than hidden: a SUBSEQUENT designation’s 3rd-year DAU legally runs from the recording of that designation, and the engine anchors it on the international registration date instead, which is never later. No reindex is involved.

September 2, 2026: Swedish publication and expiry dates corrected (PRV connector)

Two corrections to how we read PRV’s bulk feed. Neither changes a stored record until the PRV backfill and reindex have run, so existing responses are unchanged at deploy time; the dates below move once that maintenance completes. publication_date for national registrations since December 2022. PRV’s feed dates the registration notice by gazette issue, one day (occasionally two or three) after the registration decision. PRV counts the opposition period from the kungörelsedag, which is the registration day itself, and its own register shows the opposition period starting on that day. We now take the registration day as publication_date for the registration notice; the gazette issue date stays on publications[].publication_date. After the backfill and reindex, publication_date on affected Swedish marks moves one day earlier (to registration_date), and every Swedish opposition window computed from it (derived.opposition_window, the opposition_status and opposition_closes_* filters) moves one day earlier at both ends. Together with the opening-day correction below, a mark registered on 1 April now shows a window of 1 April to 1 July, matching PRV, instead of 3 April to 2 July. Marks registered before December 2022 already carried the registration day and do not move. Madrid designations of Sweden are not touched by this change. expiry_date for registrations from 2019 on. PRV reports a ten-year expiry for every registration, but our far-future date guard (built for a handful of corrupt year-2077 and year-5014 owner dates) rejected any date more than two years out, so Swedish registrations from 2019 on, and older marks whose latest renewal runs past 2028, were served with no expiry_date and no renewal_due_date. Both are now ingested as reported. Renewal deadlines for these marks anchor on PRV’s own date once it is stored; where that differs from the statutory computation we used before, PRV’s date wins.

September 2, 2026: Canada (CIPO) opposition extension benchmark before December 2023

No computed date moves. window_opens, window_closes and status for Canadian marks are unchanged; this corrects the advisory common_extension field only, and only for the direct (non-Madrid) route. The Trademarks Opposition Board rewrote its “Practice in trademark opposition proceedings” on 1 December 2023 and cut the benchmark first extension to file a statement of opposition from 4 months (with a cooling-off extension of up to 9 months on consent) to 2 months (up to 7). The ca_opposition rule served the post-2023 figure for every window. The office’s own transition rule keys on when the extension request was received (“requests for extensions of time received on or after December 1 will be subject to the revised extensions of time”), and a non-retroactive s. 47(1) request is received no later than the deadline it extends, so the rule now keys on the served close date:

derived.opposition_window.common_extension for a CA direct-route window that closes before 1 December 2023 now reads months: 4 (was 2) with notes naming the 2019 notice and the 9-month cooling-off figure.
A window closing on or after 1 December 2023 keeps months: 2; its notes are rewritten (they no longer claim the window is “otherwise non-extendable” - the 7-month cooling-off extension exists) and name the straddle: a window that opened before 1 December 2023 and closes on or after it may have been extended under either figure depending on when the request was received.
GET /v1/opposition-rules continues to show the current (2-month) tier for ca_opposition; the rule’s citations gain the superseded 2019 notice and CIPO’s own side-by-side changes page, both pinned from the Wayback Machine because the office has removed them.
ca_opposition_madrid is untouched: Trademarks Regulations s. 125 caps the Protocol-application extension at 4 months in every era.

One documented limit: the 4-month figure is verified for the notice in force from 17 June 2019. The benchmark under the 2009 notice it replaced is not pinned, so a window closing before 17 June 2019 is served the 4-month figure with notes saying so. No search filter reads common_extension, so no reindex is needed.

September 2, 2026: MX oppositions before 30 August 2016 are no longer served

Computed dates change for MX (IMPI). Mexico had no pre-grant opposition procedure until the decree published in the Diario Oficial de la Federación on 1 June 2016, whose sole transitorio puts it in force “a los 90 días naturales siguientes a su publicación” - 1 June 2016 plus 90 calendar days, i.e. 30 August 2016. The same decree introduced the pre-grant publication of the application, so an MX record carrying a publication date before that day is showing a registration publication, which never opened an opposition period. The mx_opposition rule now declares applicable_from_date and effective_from of 2016-08-30, and MX publications earlier than that return no opposition window at all. Direction of the change: windows are REMOVED, never added. Nothing about a publication on or after 30 August 2016 moves - the one-month non-extendable period, its day-after start and its rollover calendar are unchanged. If you read an opposition window for an MX mark published before 30 August 2016, that window was wrong and is now absent. Trademark responses recompute the opposition window per request, so they are correct as soon as this deploys. The opposition_status and opposition_closes_before/opposition_closes_after search filters read values materialised at index time, so until the MX index is rebuilt those filters may still match Mexican marks published before 30 August 2016 even though the returned record now carries no opposition window.

September 2, 2026: India (CGPDTM) deadline and opposition rules

New jurisdiction. IN now has a maintenance config and two opposition rules, so GET /v1/deadline-rules, GET /v1/opposition-rules, POST /v1/deadlines/compute and the derived block on a trademark answer for Indian marks instead of returning nothing. Four new rule_id values: in_renewal, in_restoration, in_opposition, in_opposition_madrid. Renewal runs 10 years from the APPLICATION date, not the grant: s. 23(1) of the Trade Marks Act 1999 registers a mark “as of the date of the making of the said application”. The filing window opens a year before expiry (Rules 2017 r. 57(1)), a 6-month surcharge window follows expiry, and restoration is available after 6 and within 12 months from the expiry itself. Marks registered before the Act commenced on 15 September 2003 run 7-year periods until the first period that starts on or after that date. Opposition is 4 months from publication of the Trade Marks Journal issue that advertised the application, counted from the day after (General Clauses Act 1897 s. 9(1)) and non-extendable; it was 3 months for applications published before 8 July 2013. An international registration designating India is opposed on the same 4-month window, running from the INDIAN Journal republication rather than the WIPO Gazette. Every value cites the statute, the Rules or the CGPDTM practice document it comes from, with a verbatim quote and a pinned snapshot. Six limits are documented rather than hidden. No closed-day roll is applied to any Indian date: the law requires one but the Registry publishes no consolidated holiday list, so holiday_calendar is null and every adjustment reads not_checked rather than a guess. A mark claiming convention priority expires on its PRIORITY date plus ten years, which the engine cannot compute without an office-supplied expiry. A mark registered late may renew within six months of its actual registration, so its real due date can be later than the one published. A mark filed before 15 September 2003 but registered after it takes a ten-year first term, where the schedule gives seven. And nothing in the Act or Rules settles whether a renewal filed ON the expiry date avoids the surcharge; the conservative reading is modelled. Lastly, the anchor of the pre-2003 seven-year terms is not pinned to a quotable source: s. 159(6) evidences the seven-year length but not the date it runs from, and India Code’s scan of the 1958 Act carries no text layer to quote, so if the filing-date anchor is wrong the direction of the error is unknown. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. Only the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters are baked at index time, so IN search documents carry these values only after IN is reindexed; no IN records are indexed today.

September 2, 2026: Türkiye (TÜRKPATENT) deadline and opposition rules

New jurisdiction. TR now has a maintenance config and two opposition rules, so GET /v1/deadline-rules, GET /v1/opposition-rules, POST /v1/deadlines/compute and the derived block on a trademark answer for Turkish marks instead of returning nothing. Three new rule_id values: tr_renewal, tr_opposition, tr_opposition_madrid. Renewal runs 10 years from the FILING date, with a 6-month filing window before the term ends and a 6-month window after it against an additional fee; missing both ends the right. Turkish law has no restoration and no declaration of use, so neither is emitted — that absence is the finding, not a gap. Opposition is 2 months from the publication of the APPLICATION in the Bülten, non-extendable, and identical for Madrid designations (SMK m. 14/1 makes an international application produce the same results as a direct one); publications before 2017-01-10 get the 3 months the repealed KHK 556 gave. Every value cites the statute or the TÜRKPATENT publication it comes from, with a verbatim quote and a pinned snapshot. Five limits are documented rather than hidden. No business-day adjustment is applied to any Turkish date: no Turkish source states that a deadline falling on a non-working day extends before the office, and TÜRKPATENT’s own 2025-03-29 notice told users to file during an administrative holiday — so holiday_calendar is null and both adjustments read not_checked on every row. Renewal cycles whose anniversary falls before 2018-01-10 were governed by a month-end-anchored request window that the engine does not yet express, so their window_opens and due_date can be up to 30 days early; every such cycle is in the past. (grace_expiry is not affected: the repealed KHK 556 anchored the six-month lapse on the exact end of the term, which is what we publish.) An application filed before 2017-01-10 but published after it legally had a 3-month opposition window while we publish 2 — earlier than the true date, never later. Applications published in Marka Bülteni 410 to 417, roughly 12 December 2022 to 27 March 2023, carry opposition end dates that TÜRKPATENT’s 2023-04-14 notice fixed per bulletin once the periods suspended after the February 2023 earthquakes restarted; a one-off table is not a rule, so those office-fixed close dates are not modelled and the notice is pinned to keep the limit auditable. And whether a renewal request filed ON the day the term ends is still surcharge-free is stated by neither SMK m. 23/2 nor the office, so the exact anniversary is kept as the due date. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. Only the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters are baked at index time, so TR search documents carry these values only after TR is reindexed; no TR records are indexed today, so that reindex belongs with the TÜRKPATENT connector rather than with this change.

September 2, 2026: Japan (JPO) deadline and opposition rules

New jurisdiction. JP now has a maintenance config and two opposition rules, so GET /v1/deadline-rules, GET /v1/opposition-rules, POST /v1/deadlines/compute and the derived block on a trademark answer for Japanese marks instead of returning nothing. Four new rule_id values: jp_renewal, jp_restoration, jp_opposition, jp_opposition_madrid. Renewal runs 10 years from the registration date, with a 6-month filing window before expiry and a 6-month late window after it; missing both extinguishes the registration retroactively, and a further 6-month restoration window follows. Opposition is POST-registration: 2 months from the day after the 商標掲載公報 issue, non-extendable, with the same window for Madrid designations. Deadlines falling on a JPO closed day roll to the next open day. Every value cites the statute or the JPO practice document it comes from, with a verbatim quote and a pinned snapshot. Three limits are documented rather than hidden: the published window_opens can be 1 to 3 days earlier than 商標法第20条第2項 allows, and grace_expiry can be up to 7 days early when the expiry lands on a closed day. Madrid designations are also served a jp_restoration row that Japanese law does not give them. All three are fixed by engine changes that ship separately. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. Only the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters are baked at index time, so JP search documents carry these values only after JP is reindexed; no JP records are indexed today.

September 2, 2026: opposition window opening day corrected (Benelux, Finland, Norway, Sweden)

Opposition windows for BOIP, PRH Finland, Patentstyret, and PRV Sweden now open on the publication day, one day earlier than before. Their closing dates are unchanged. The served opposition rule_version moves to 2026-09-02. derived.ruleset_version on trademark responses (backed by the internal DEADLINE_RULESET_VERSION constant) also moves to 2026-09-02. It is one global stamp (the maximum lastVerified across all maintenance configs), so it moves for every record in every jurisdiction, including ones this release did not touch; this release bumped that maximum. The version move on its own does not imply that any computed date changed. REINDEX required for these four offices. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. Only the materialised opposition_status filter stays stale until those offices are reindexed, because opposition_window_opens is baked into existing search documents; the opposition_closes_before/opposition_closes_after filters are unaffected, because no closing date moves. Benelux, Finland and Norway can be reindexed now. Sweden caveat. For marks registered since December 2022, the publication date we stored for PRV came from the gazette issue, which runs one day after the registration decision (40 of 40 records sampled per month). PRV counts the opposition window from the registration day itself. The connector correction is in the “Swedish publication and expiry dates corrected” entry above; Swedish opposition windows stay one day late until the PRV backfill and reindex described there have run. Sweden is reindexed after that backfill, not with the other three offices.

September 2, 2026: German renewal dates corrected for applications pending on 14 January 2019

DE national marks filed before 14 January 2019 but registered on or after that date now expire on the exact filing anniversary. They were previously shown with a month-end deadline, which is later than the law allows (for example, 2028-10-31 instead of 2028-10-05). Marks already registered before the cutoff retain month-end expiry, and office-reported expiry dates still take priority. The correction is computed at request time; no reindex is required. Scope of the change: only DE national marks filed before 2019-01-14, registered on or after that date, and without an office-reported expiry date. Our deadline evaluation harness holds no DPMA samples, so 0 records in it move. The first renewals for this group fall in 2028 and 2029, so no affected deadline is currently past due.

September 2, 2026: French renewal grace end corrected (moves later)

French renewal grace periods previously ended early, so customers had more time than Signa showed. They now run for six months from the day after the registration expires, matching CPI R. 712-24 and R. 718-2 exactly. Scope: no French renewal grace end moves earlier. Most move one day later. A grace period whose due date falls on a month end can move up to four days later, because the old and the new end clamp to different month ends: a due date of 2026-02-28 moves its grace end from 2026-08-28 to 2026-09-01, a due date of 2026-04-30 moves two days, and 2028-02-29 moves three. A few whose old and new ends both clamp to the same month end do not move at all. The correction is computed at request time, so no reindex is required (maintenance deadlines are not indexed).

September 2, 2026: office calendar corrections

Deadline rollover calendars now match the 2026 audit of official office closures. No rule window or anchor changed. Trademark responses recompute opposition windows per request, so every office below is correct as soon as this deploys. Only the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters stay stale until the offices named below are reindexed.

EUIPO: 8 December 2025 and 2026 no longer roll; those are Article 2 ordinary-post-only days, not Article 1 office closures. Reindex EU opposition documents.
CIPO: weekend substitutes for 24 June and 30 September now roll on the following Monday. Those two need no reindex before the first affected 2028 opposition cohort. Separately, the 17–19 September 2025 office closure now rolls through the weekend to 22 September, so CA documents published 17 to 19 July 2025 carry an opposition close date up to five days early until CA is reindexed. Opposition status is unaffected: those windows are already closed.
IPOS: 11 August 2025 and 20 March 2026 no longer roll; the excluded days 1–16 May 2024 roll to 17 May, and 14 October 2025 rolls to 15 October. Reindex affected Singapore opposition documents.
IP Australia: Canberra Day, Saturday and Sunday ANZAC Day substitutes, and the standing 25 December–1 January close-down now roll. For example, 9 March 2026 rolls to 10 March, 27 April to 28 April, and 29 December to 4 January 2027. Reindex Australian opposition documents.
IPI: the conservative nationwide calendar now excludes canton-specific days, including 2 January, Good Friday, Easter Monday, Whit Monday, 1 May, 26 December. The governing party or representative canton is not available to the engine, so deadlines are never moved later based on the wrong canton. Reindex Swiss opposition documents.
DKPTO: 15 May and 28–30 December 2026 now roll as enumerated office closures. Reindex is not currently needed because Signa has no DK office documents; revisit when DK ingestion lands.
INPI France: 15 May 2026 now rolls to 18 May under the Director General’s closure decision. Reindex French opposition documents.
DPMA: the one-off Berlin holiday on 8 May 2025 now rolls to 9 May. No reindex is required for the weekly weekday publication cohort.

September 2, 2026: Era-aware opposition citations

The source on a computed opposition window now cites the instrument that states the window actually served. For rules whose opposition period changed on a fixed date, a publication before the change cites the earlier statute and a publication on or after it cites the amending law. This covers all seven opposition rules that change their period on a date, so a pre-change publication now cites the instrument that states the period it was given:

Australia, direct and Madrid, published before 2013-04-15 (3 months): Trade Marks Regulations 1995 reg 22.9 item 2 for a direct application and the 2012 compilation’s reg 17A.29(2)(b)(i) for an international registration, in place of the current reg 5.6(1) / reg 17A.33(1) “2 months”.
India, published before 2013-07-08 (3 months): Trade Marks Rules 2002 r. 47(1), in place of s. 21(1) “four months”.
Thailand, published before 2016-07-28 (90 days): s. 35 paragraph 1 of the Trademark Act B.E. 2534 as in force before Act (No. 3) B.E. 2559, in place of the current s. 35 paragraph 1 “sixty days”.
Türkiye, direct and Madrid, published before 2017-01-10 (3 months): the repealed Decree-Law 556 art. 35/1, and WIPO Information Notice No. 19/2014 for a designation, in place of SMK 6769 art. 18/1 “iki ay” for a direct application and the WIPO Madrid Member Profile (“two months from the date of publication of the international registration”) for a designation.
Vietnam, published before 2026-04-01 (5 months): Law 07/2022/QH15, in place of Law 131/2025/QH15, which states only the three-month period.

No window dates move, the source shape (citation, url) is unchanged, and no reindex is required — the citation is computed at request time.

September 2, 2026: Vietnamese opposition windows corrected (3 months since 1 April 2026)

Vietnamese trademark applications published on or after 2026-04-01 now have a 3-month opposition window. These windows were previously shown 2 months too late. Trademark responses recompute opposition windows per request, so they are correct as soon as this deploys. Only the materialised opposition_status and opposition_closes_before/opposition_closes_after search filters stay stale until VN documents published on or after 2026-04-01 are reindexed.

September 2, 2026: Brazilian and Mexican renewal deadlines

Renewal deadlines are now computed for Brazilian and Mexican registrations where none were computed before; the grant-date trigger was never fed from stored data. The affected cohort is BR and MX national-route registrations whose stored registration date feeds that trigger; records carrying an international registration number are excluded. The deadlines are computed at request time, so no reindex is required (maintenance deadlines are not indexed).

September 2, 2026: Icelandic renewal dates corrected

IS renewal deadlines: applications filed before 2020-09-01 are now anchored on the registration date for every renewal, even when registration occurred after the reform. They were previously shown early from the filing-date anniversary. For every affected record that carries a registration date the renewal moves later; none moves earlier. Records with an office-reported expiry remain anchored on that expiry. There is a third outcome. A pre-2020 IS record that carries neither a registration date nor an office-reported expiry now returns no computed renewal at all, where it previously returned one anchored on the filing date. The filing date is the wrong anchor for that cohort, so the deadline is withheld rather than guessed; send the registration date, or the office’s expiry date, to get a schedule back. This matches how the other registration-anchored pivots (SE, FI and NO) already behave. Denmark is not in that set: its pivot is keyed on the registration date rather than the filing date, so a DK record with no registration date falls through to the modern filing anchor and is served a schedule. Renewal deadlines are computed at request time, so no reindex is required. IS opposition dates did not change either: opposition_window_opens, opposition_window_closes and opposition_rule_version in the search index are unaffected. The index stores no rule citations at all. GET /v1/deadline-rules and GET /v1/opposition-rules serve sources[] straight from the deployed configuration, so the new IS primary-source citations take effect with the deploy (within the 24-hour reference-cache window), and no reindex is involved.

September 2, 2026: Office rule reference data provenance

Reference data: deadline and opposition rules for AU, BR, BX, CA, CH, DE, DK, EU, FI, FR, GB, MX, NO, PH, PL, SG, TH, US and WIPO now cite primary sources with verbatim quotes and pinned snapshots. sources[] on GET /v1/deadline-rules and GET /v1/opposition-rules changed for those offices: law-firm guides, publisher summaries and mirrors of primary text were replaced by the statute, regulation or office publication they paraphrased. Nothing else in those responses moved, and no computed date changed from the re-citation alone. IN, JP and TR are new rule sets rather than re-citations, and are announced separately above. For DE (DPMA) the opposition rule’s five bare links to individual gesetze-im-internet section pages are replaced by eleven pinned citations: MarkenG §§ 41, 42 and 91, MarkenV § 27, BGB §§ 187, 188 and 193, DPMAV § 18a, PatKostG § 6(1) with the opposition fee numbers, and the DPMA’s own opposition guideline W 7736 (Markenblatt publication, the Ereignisfrist arithmetic, and the rule that statutory periods cannot be extended). The German renewal config additionally cites PatKostG §§ 3, 5 and 7, BGB §§ 187 and 188, and three DPMA practice pages carrying the worked renewal example. No computed dates changed. For FI (PRH) both configs move to primary Finnish law. The renewal config’s two remaining links — an English PRH page and a law-firm alert — are replaced by twelve citations: Tavaramerkkilaki 544/2019 §§ 16, 30, 106 and 107 (the ten years from the application date, the one-year/six-month window, removal from the register, and the 1 May 2019 commencement that pivots the anchor), the repealed 7/1964 §§ 22 and 24 for marks applied for before it, the 1930 Act on calculating time limits for the same-numbered-day arithmetic, and three Finnish PRH pages. The opposition rule’s own statutory links are re-pinned (544/2019 § 32 and the 1930 Act) and joined by 544/2019 §§ 24 and 33, 7/1964 § 20 and four PRH pages. A citation to a Government Decree on Trademarks (1268/2018) was removed: that statute number belongs to an unrelated act and no decree governs the Finnish opposition period. No computed dates changed. For FR (INPI) the opposition rule loses all four of its previous links and gains thirteen pinned citations. Two of the four were wrong as well as unverifiable: the Légifrance article id cited for CPI art. L. 712-4 does not exist, and the one cited for Code de procédure civile arts. 641/642 identifies neither article (they are LEGIARTI000006411002 and LEGIARTI000006411003). The rule now cites CPI arts. L. 712-4 (both the in-force text and the pre-2019 text, with L. 712-3, showing the two months have not changed since 1992), R. 712-8 for the BOPI publication that starts the period, R. 718-2 for the same-numbered-day arithmetic and the weekend/holiday roll, R. 712-14 for the one further month allowed for the exposé des moyens, R. 712-15 for the inadmissibility of a late opposition and R. 712-12 for the absence of any restoration of it, plus INPI’s opposition directives (July 2026) and its current opposition page. The renewal config additionally cites CPI arts. L. 712-1 and L. 714-5 and INPI’s nullity/revocation page. Statutory text is quoted from the DILA open-data LEGI publication of each article version, because legifrance.gouv.fr blocks automated retrieval. No computed dates changed. For MX (IMPI) both configs move to primary Mexican law. The renewal config’s five previous citations - a WIPO Lex catalogue page and three law-firm guides, plus WIPO Information Notice 13/2018 - become thirteen: LFPPI arts. 178, 21, 233, 237 and 238 and transitorios PRIMERO, DECIMO and DECIMO PRIMERO (the ten years from grant, the six-month renewal window and six-month grace, the declaration of use in the three months after the third year, and the 2018-08-10 and 2020-11-05 commencements), the abrogated Ley de la Propiedad Industrial art. 95 for marks applied for before 5 November 2020, IMPI’s own LFPPI seminar deck, and Information Notice 13/2018 promoted in place with its quote. The opposition rule’s three links are replaced by seven citations: LFPPI arts. 221, 21 and 18, Reglamento de la LPI arts. 4o and 59 TER, the abrogated LPI art. 120 showing the one-month non-extendable period has not changed since 2016, and the transitorio Único of the decree published in the DOF on 1 June 2016, which is the text that dates the 2016-08-30 gate. All three were unusable: every one of them pointed at diputados.gob.mx, which no longer answers, and the Federal Code of Civil Procedure art. 286 is not the instrument that governs IMPI time limits either. Statutory text is quoted from the ordenjuridico.gob.mx consolidated PDFs. No computed dates changed.

September 2, 2026: The events feed is documented (beta)

GET /v1/events and GET /v1/events/{id} are now part of the published API reference and the OpenAPI document, under Monitoring. They were already live and callable with the events:read scope; what changed is that they are documented and supported rather than undocumented. The feed is your organization’s append-only event ledger, retained 30 days. Every webhook you receive is also a row in it, addressable by the same id — the webhook-id header IS the evt_* id — which makes it the recovery path for an outage your webhook retries could not cover: persist the last id you processed, then ask for ?sort=id&after=evt_…. A checkpoint older than the window returns 410 replay_window_expired; see Replay from a checkpoint. Beta means one specific thing here. The ledger, the evt_* ids, the filters and the replay rail are stable enough to build on. The per-event data payloads are versioned by payload_version and their shape is not yet promised — pin payload_version in your consumer and read this changelog before upgrading. No behaviour changed: same rows, same filters, same scopes. The MCP surface adds a matching read tool, signa_events_list.

September 2, 2026: Alert diffs use public field names (breaking, beta)

data.alert.event.diff[].path on alert.created webhooks and GET /v1/alerts* now uses public trademark field names, the same ones trademark.status_changed adopted. Effective on deploy; alerts are in beta and this is the last chance to fix the vocabulary before it is frozen.

Was (internal column)	Now (public field)
`status_primary`	`status`
`mark_text_primary`	`mark_text`
`publication_date_first`	`publication_date`
`international_registration_number`	`ir_number`
`challenge_states`	`status_challenges`
`trademark_owners`	`owners`
`trademark_attorneys`	`attorneys`
`trademark_classification`	`classifications`
`trademark_media`	`media`
every other `trademark_*` child table	its collection name

Fields Signa tracks but does not publish (is_primary_source, mark_feature_type_raw, mark_legal_category_raw, application_language) are dropped rather than renamed, so a diff can be shorter than before — and every path you now see is a field you can read back from GET /v1/trademarks/{id}. event.summary is built from the same names, so the headline reads "Status changed: pending → registered" where it used to read "Status primary changed: …". Redeliveries (POST /v1/webhooks/{id}/deliveries/{delivery_id}/redeliver) and automatic retry attempts of alerts created BEFORE this change are re-emitted with the new names too — event.summary included, since the headline is re-derived from the translated diff — so your handler only ever has to understand one vocabulary. GET /v1/events/{id} applies the same projection to the stored alert.created body, so the pull rail and a redelivered push of the same event agree. Nothing about which alerts fire, or when, changed.

September 2, 2026: Office dates and your docket reference on events

Three additive fields on trademark.status_changed and office_action.issued, on both the webhook body and GET /v1/events/{id}. Nothing was renamed, no stored value changed, and payload_version stays 1. source_date is the office’s date; occurred_at was always ours. occurred_at is when Signa produced the event: ingestion time for trademark.* and office_action.*, alert-creation time for alert.created. That was already true, and it is now documented per family instead of implied. The new source_date is the office-reported data date of the change as we stored it (YYYY-MM-DD, or null when the feed reports none) — equal to event_date on office actions. The two differ by the office publication lag, typically 1 to 14 days, so sort a docket by source_date (meaningful within one office) and use occurred_at to answer “when did I learn this”. Its meaning is honest rather than uniform: day precision, USPTO transaction date, WIPO gazette date, snapshot offices the crawl date. It is not a legal effective date — changes.status_effective_date is. We deliberately do not fold the effective date into source_date, because an office re-crawl can backdate it by years and your feed would travel backwards on a mark that was merely re-read. portfolios carries your external_ref, frozen at record time. Both families now include the portfolios the mark was in when the event was recorded, each with the reference you set on the membership:

"portfolios": [{ "id": "ptf_9aB2xY", "external_ref": "MATTER-4471" }]

It is a snapshot, not a live lookup. Re-keying a matter reference tomorrow never rewrites an event you already received, which is what keeps a redelivery byte-identical to the original and keeps GET /v1/events/{id} in agreement with the body you verified the signature over. Empty array when the mark was in no portfolio; null external_ref means unknown or unset, never “cleared”. alert.created does not carry either field. The SDK adds EventPortfolioRef and the new fields on TrademarkStatusChangedData, OfficeActionIssuedData and the org-event detail types.

September 2, 2026: Webhook subscriptions, portfolio scope, and diff field names

Three contract clarifications on the event surface, all landing together. Subscribing no longer depends on our rollout state. enabled_events accepts alert.created, trademark.status_changed and office_action.issued at all times. The last two are accepted for subscription but not yet emitted — they begin delivering when the API events projector is enabled. Previously the accepted set widened with our rollout, which meant the published OpenAPI document described a different API depending on the environment you generated your client against. Subscribe now and you receive them from the first delivery. portfolio_id means one thing. An endpoint’s portfolio_id, and GET /v1/events?portfolio_id=, now filter every event type against the portfolio membership recorded when the event was recorded — alert.created included. Previously alerts bypassed the filter entirely, so a portfolio-scoped endpoint or query returned every alert in the organization regardless of portfolio. If you scoped an endpoint to a portfolio and relied on it still receiving all alerts, clear portfolio_id on that endpoint (or add a second, unscoped endpoint) — similarity, class and owner watches match marks you do not own, and those alerts have no portfolio membership. changed_fields and changes use public field names. The trademark.status_changed payload and GET /v1/events/{id} now key the diff by the field names on the trademark resource instead of our internal column names: status_primary becomes status, mark_text_primary becomes mark_text, publication_date_first becomes publication_date, international_registration_number becomes ir_number, challenge_states becomes status_challenges, and changed child collections read as owners, classifications, media and so on. Internal-only columns are omitted rather than renamed, so both lists can be shorter than before. Every name you now see is a field you can read back from GET /v1/trademarks/{id}.

September 2, 2026: Richer goods/services validation evidence

POST /v1/goods-services/validate now adds descriptive wording coverage, candidate spans and USPTO template drafting aids, suggested class inference, cited indefinite-wording warnings, catalog as_of freshness, and explicit candidate-search completeness. Summary fields roll up inferred items, warnings, and complete, truncated, or degraded searches. listed and not_listed keep their existing catalog-membership meaning. The TypeScript SDK exposes the new types in version 0.12.0; version 0.11.0 was never published, so no published SDK contract is broken.

September 2, 2026: Goods/services catalog validation

POST /v1/goods-services/validate checks submitted wording against the pre-approved catalogs available for US, EM, JP, KR, and CN. listed means the wording appears in that office’s catalog. not_listed is an absence of evidence, not a refusal. Other recognized offices return unsupported_office with reason no_catalog_data. The endpoint returns one result per input item, bills per item, and can provide same-class candidate wording when class_number is supplied. An optional Idempotency-Key enables safe replay. The TypeScript SDK exposes it as goodsServices.validate() in version 0.11.0.

September 2, 2026: Entity lists and suggest answer 503 when OpenSearch is unavailable

GET /v1/owners, /v1/attorneys, /v1/firms, /v1/entities, /v1/suggest and /v1/trademarks/suggest no longer fall back to a degraded Postgres page or an empty result when OpenSearch is unavailable. They answer 503 service_unavailable with a Retry-After header instead. The SDK retries 503 automatically. Cursors and result ordering are unchanged on the happy path.

September 2, 2026: Saved searches removed

The /v1/saved-searches endpoints are gone and now answer 404. The signa.savedSearches SDK resource, the SavedSearch types, the from_saved_search option on signa.watches.create and the ssr_ id prefix were removed with them. The feature had no production usage. Store the search body on your side and re-send it to POST /v1/trademarks, or create a watch with the same query.

September 2, 2026: Swedish renewal dates corrected

SE renewal deadlines: registrations applied for before 2019-01-01 are now anchored on the registration date per the transitional rule (SFS 2018:1652 p. 4 a), whenever they were registered. About 1,300 active marks change date, in both directions: roughly 1,290 move later (they were shown up to 6 years early), and 8 move earlier or gain a deadline that was previously outside the horizon (their filing-anchored cycle had already elapsed; the registration-anchored one lands sooner, by up to 2,445 days). Computed at request time, no reindex. Records with an office-reported expiry are unaffected.

September 1, 2026: Office-action webhook events

office_action.issued is now a subscribable, versioned semantic event. It fires once for each newly stored office action on a portfolio mark and carries the stored prosecution-history fields using public office-code vocabulary. Emission begins when the API events projector is enabled. A first detail fetch that newly inserts multiple office actions stores them without webhook emission. A single-action history may emit one office_action.issued: one action is indistinguishable from a genuinely new one, and a stale event is safer than silently dropping a real refusal notice. Once history is known, each later new action emits once.

September 1, 2026: Trademark status webhooks and portfolio-scoped endpoints

trademark.status_changed is now available as a subscribable webhook event type. It carries the spine-native event envelope; emission begins when the API events projector is enabled. Endpoints without a portfolio_id receive every trademark.status_changed event for the organization; setting a portfolio_id narrows those deliveries to marks in that portfolio. POST /v1/webhooks, PATCH /v1/webhooks/{id}, and GET /v1/webhooks now expose the additive portfolio_id field.

September 1, 2026: BREAKING — webhook event envelope

This is a breaking webhook contract change. For alert.created, the envelope id and signed webhook-id header now use the spine event identifier (evt_*) instead of the alert identifier (alt_*). The payload is no longer a flat merged field bag: data is now { event_id, alert_id, alert }, with the rich alert resource nested under data.alert. webhook-id is the documented idempotency key. Migrate or reset stored idempotency keys during this upgrade so the alt_* to evt_* identity change does not cause incorrect duplicate handling. Update consumers to read paths such as data.alert.id and data.alert.event.type.

September 1, 2026: Forward replay on `GET /v1/events`

The event feed gains a second rail. The default feed keeps its shape and its rows: newest first, opaque cursor, same order (list items do gain two timestamp fields, detailed below). What is new is a forward rail a sync client can resume from, plus two behaviour changes on the existing surface that you need to know about before you upgrade. Discard any GET /v1/events cursor you have stored. Event cursors are now bound to the query that minted them. The payload carries the sort direction and a fingerprint of the filters, the limit and the sort, so a cursor can only be replayed against the identical query. Every cursor minted before this change lacks both, and now returns 400 cursor_invalid. Cursors were always documented as opaque and short-lived, so this only affects you if you persisted one. Restart from page one without a cursor. cursor_invalid is a different failure from cursor_expired, and the split is deliberate. cursor_expired means the value is not a cursor: malformed, unsigned, or minted for another endpoint. Restart from page one. cursor_invalid means the cursor is genuinely ours but is bound to a different query than the one you just sent, usually because a filter or the limit changed mid-pagination. Restart from page one with the parameters you actually want. since now filters on when Signa recorded the event, not when the office reported it. It used to bind the row’s creation timestamp; it now binds recorded_at, Signa’s ledger clock. This is what a sync client wants. Source timestamps can be backdated by an office arbitrarily far, so filtering on them silently skips late-arriving rows that were recorded after your last poll. Every event now carries both clocks explicitly, occurred_at for the office and recorded_at for us, so nothing is lost. created_at stays as an alias of recorded_at. sort=id turns the feed into a replay rail. Pair it with after=<evt_ id> to resume from a checkpoint you persisted, exclusive of the checkpoint itself. Ledger sequence is the only sortable field, and after is valid only with sort=id. sort=-id remains the default; its ordering and cursor behaviour are unchanged. List items gain occurred_at and recorded_at, and trademark_id is now nullable.

curl "https://api.signa.so/v1/events?sort=id&after=evt_3D7rZ9&limit=100" \
  -H "Authorization: Bearer $SIGNA_API_KEY"

A checkpoint older than the retained window is a 410, not a silent gap. Replay is bounded by retention. If the events after your checkpoint have been pruned, the response is 410 replay_window_expired rather than a 200 that quietly omits them. The floor is per organization, so another tenant’s retention never affects your answer. Recovery is to start a new initial sync with sort=id and no after, then persist the newest event ID you see. The TypeScript SDK maps 410 to a new GoneError. portfolio_id is family-aware. It filters every event type through the portfolio membership snapshot captured when the event is recorded, so later membership changes never rewrite history. That includes alert.created: an alert is in a portfolio’s feed only when the alerting mark was in the portfolio at the moment the alert was recorded, and similarity, class and owner watches routinely match marks you do not own, which have no membership. This is identical to portfolio-scoped webhook delivery. The parameter requires portfolios:manage in addition to events:read.

September 1, 2026: Examiner citations

Three new endpoints, a new count on the trademark detail, and a per-office capability flag. Everything here is additive. The only thing that changes for an existing integration is that detail ETags rotate once, at deploy. Citations are now a first-class resource. A citation is a prior mark an examiner cited against a pending application. GET /v1/citations queries them across marks, filterable by offices, disposition, action_stage, refusal_type, trademark_id, cited_trademark_id, cited_ref and an action_date range. Each row is one citation occurrence: one prior mark, one application, one office action. And per mark, in both directions. GET /v1/trademarks/{id}/citations returns what was cited against that application. GET /v1/trademarks/{id}/cited-by returns the applications that mark has been cited against, which is the question a portfolio owner actually asks. cited-by also picks up citations matched by office-printed reference where Signa has not linked the row to a record yet, and the ?cited_trademark_id= filter on GET /v1/citations matches the same rows, so the two views agree. citations_count on the trademark detail. GET /v1/trademarks/{id} and POST /v1/trademarks/batch carry a new citations_count. It is present on every full-detail response, including the batch lookup surface, and it is nullable. Like events_count and proceedings_count, it is dropped by a sparse ?fields= projection that does not ask for it. An integer, including 0, means the office is covered and that is the real count. null means citations are not counted for that office at all, which is not the same as “there are none”. capabilities.citations tells you which is which. GET /v1/offices and GET /v1/offices/{code} now carry a capabilities block whose citations field reads available, in_progress, not_available or not_applicable. available offices return a number in citations_count; every other state returns null. not_applicable is the useful one: an office that does no ex-officio relative-grounds examination never issues a citation-bearing refusal, so its empty list is a fact about the regime rather than a gap in our coverage. Branch on this field instead of inferring coverage from an empty response. Coverage today is USPTO §2(d) refusals. SDK. signa.citations.list(), signa.trademarks.citations(id) and signa.trademarks.citedBy(id), all auto-paginating like every other list. Detail ETags rotate once. The representation salt goes from v3 to v4, so the validator format is now "v4.{version}-{epoch}" plus the derived content hash, plus a citations_count hash on covered offices. Every cached trademark detail body misses once and refetches. Nothing to change on your side. The extra hash exists because citations are written by the extraction pipeline, which does not touch the record’s version: without it, a client holding an ETag would be revalidated onto a stale count forever.

September 1, 2026: Every rule has a stable id

Deadline and opposition rules now carry a permanent rule_id, so a computed date can be traced to the rule that produced it and joined to the catalogue that documents it. rule_id is an opaque slug — do not parse it — and it will not be renamed once published. Alongside it, two dates that were previously conflated are now separate. effective_from is the earliest date from which a rule’s modelled content is authoritative, and is null where the corpus does not establish one. last_verified is when we last checked the rule against its sources; on opposition rules that is the value rule_version has always carried. POST /v1/deadlines/compute rows gain rule_id, effective_from, last_verified and the business-day provenance due_date_adjustment, grace_expiry_adjustment and holiday_calendar. The two adjustment fields are moved, unchanged or not_checked — not_checked covers a jurisdiction that does not observe the roll, an office with no wired calendar, and a date beyond a calendar’s coverage, so a date we never checked is never reported as one we checked and left alone. Each item also carries the jurisdiction’s sources, plus as_of and computed_at, which together make a response replayable as a record of what was computed and when. POST /v1/oppositions/compute gains rule_id and effective_from; rule_version is unchanged. Both catalogues expose the same three fields, and GET /v1/deadline-rules now also serves the restoration rules for Great Britain, Singapore and Iceland, which the engine could always compute but the catalogue never listed. Trademark detail, portfolio deadlines and watch diagnostics carry rule_id on each row. All fields are additive. One caching note: the trademark detail response folds a content hash of its derived block into the ETag, and that block now carries rule_id, so detail validators rotate once on this release.

September 1, 2026: Prosecution deadlines on `/v1/deadlines/compute`

POST /v1/deadlines/compute now computes prosecution deadlines as well as maintenance ones: office action response periods and statement of use clocks, resolved per fact instance. Send an optional facts array on any item and the result gains prosecution_deadlines[] and support[]. This is additive. prosecution_deadlines[] and support[] appear only on items that sent facts. (The same release adds rule identity to every item — see the entry above — so an item you send without facts is unchanged apart from those provenance fields.) Every computed date cites its rule. Each prosecution deadline carries the rule id, the era it belongs to (effective_from / effective_until), which case date selected that era, when the rule was last verified against source, and the sources themselves with pinpoint section, verbatim quoted text and a sha256 of the snapshotted document. A computed date that cannot cite its rule does not ship. Support is now per deadline type, and it is honest about coverage. A single supported: boolean could not say that a US mark has a renewal schedule but no office action deadline, so support[] reports one entry per type with a four-valued status:

computed, a modelled rule produced or retired a date
stated, no modelled rule exists but the office stated the deadline itself
facts_required, a rule exists and is verified, but you must supply the trigger
unsupported, no rule is modelled

Today that reads: USPTO computes from stored or supplied events. EUIPO rules are verified but Signa stores no EUIPO examination events, so EUIPO is facts_required until you send the trigger. There is no Madrid level rule and there will not be one, because the Madrid System does not set the holder response period; it is designated office law. For an unmodelled contracting party, send a stated_deadline fact carrying what the office declared and the date comes back with the notification as its authority. The item level unsupported_reason enum widens from 2 values to 20 so both engines share one reason vocabulary. The field itself still only emits the two maintenance values; the new codes appear on support[].reason and prosecution_deadlines[].reason. Treat it as an open enum. Billing is unchanged: 1 unit per item, whether or not the item carries facts.

August 31, 2026: Computed data moves under `derived`

A response-shape change on the trademark detail and batch endpoints, plus a new provenance field. This is a breaking change: deadlines[] and opposition_window move, and three fields on each deadline row go away. We are shipping it during beta, before anyone has built on the old shape. Everything Signa computes now lives under derived. deadlines[] becomes derived.deadlines[] and opposition_window becomes derived.opposition_window. The split makes the boundary visible. Fields at the top level are what the office told us. derived is what we computed. Nothing about what we compute has changed, only where it sits. Deadline rows now carry dates, not countdowns. status, urgency and days_until_due are gone from the trademark response. Each row instead carries window_opens, due_date and grace_expiry, plus new trigger_date, trigger_field, recurring and optional fields. The reason is caching. Those three fields were functions of the day you read the response, but the response is cached and revalidated against a record-versioned ETag. A client that held an ETag and revalidated a week later got a 304 and kept serving last week’s countdown, indefinitely. A value that changes without the record changing cannot live in a cacheable body. Deriving them is a couple of lines against your own clock:

const today = new Date().toISOString().slice(0, 10);
const overdue = d.due_date < today;
const inGrace = overdue && d.grace_expiry !== null && d.grace_expiry >= today;

If you would rather the server do it, POST /v1/deadlines/compute takes an explicit as_of_date and still returns status, urgency and days_until_due. Its clock is an input, so it caches correctly. GET /v1/portfolios/{id}/deadlines is unchanged. Opposition windows lost their clock fields too. derived.opposition_window drops status, days_until_open and days_remaining, and adds rule_version. On search and list rows, opposition_window keeps window_opens and window_closes and drops status. The opposition_status filter is unaffected. The server still evaluates it, so filtering by open or not_started works exactly as before. An empty schedule now says why it is empty. [] used to be ambiguous between “this mark has no deadlines” and “we declined to compute one”. derived.deadlines_supported is now false with a derived.deadlines_unsupported_reason of either unsupported_jurisdiction or requires_office_date, the same vocabulary POST /v1/deadlines/compute already returns. derived.ruleset_version stamps the rule state that produced the block. renewal_due_date now declares where it came from. It sits at the top level next to office-reported dates, but it is office-stated for some records and computed by the connector for others, and nothing said which. The new renewal_due_date_basis reads reported, derived or unknown, exactly like expiry_date_basis. Connectors adopt it one at a time, so expect unknown on records whose connector has not declared one yet. Detail ETags all rotate. As of this release the validator format is "v3.{version}-{epoch}" with a content hash of the derived block appended, so cached copies of the old shape miss and refetch. Nothing to do on your side beyond expecting one full response per cached mark. (The v3 salt moved to v4 in the September 1 release below.)

August 30, 2026: Deadline engine statutory corrections

A correctness pass over the maintenance deadline engine. This is a behavior change: the same trademark can now return a different status, a different number of deadlines[] rows, and different dates on four jurisdictions. Read this before upgrading if you drive filing workflows off computed deadlines. The due day and the last grace day are now actionable, not missed. Status boundaries are inclusive on the actionable side. On the due date a deadline reads due_soon, not missed. On the last day of the grace period it reads in_grace, not missed. missed now begins the day after grace expiry (or the day after the due date where a rule has no grace period, such as the Mexican third-year declaration of use). If you filtered for missed to build a “too late to file” list, that list previously included two days you could still file on. Refused applications no longer return a maintenance schedule. A refused application has nothing to maintain, so deadlines[] is now [] for it. The one exception is Madrid-route records: a provisional refusal from a designated office is routinely overcome, so Madrid-route marks keep computing their schedule. Expired and cancelled marks now return their still-actionable rows instead of an empty array. These statuses are recoverable for a bounded window, and returning [] hid exactly the deadlines a customer needs at that moment. An expired mark now returns its open late-renewal window (the current cycle while its filing window or grace period is open) plus its restoration row where the jurisdiction provides one (GB, SG, IS). A cancelled mark returns its restoration row only, where modeled. Statuses that are terminally dead (abandoned, withdrawn, surrendered, invalidated, and refused, except the WIPO international registration record itself under a provisional refusal) still return [].

This can add rows to marks you already fetch. A cancelled GB mark that returned no deadlines yesterday can return a restoration row today. Client code that assumed a dead mark implies an empty array should be checked.
Rows can also disappear for expired marks without a reported expiry. The engine will not invent a lapse it cannot corroborate: an expired mark with no office-stated expiry date is served only the cycle whose window is currently open, never a restoration row derived from an assumed earlier miss. Clients alerting on deadlines[] shrinking should expect this.

Restoration rows are no longer flagged optional. Restoration is the only way back onto the register once removal is final, so optional is now false on those rows, and include_optional=false no longer suppresses them. If you pass include_optional=false on POST /v1/deadlines/compute to trim the response, expect restoration rows to appear where they did not before. Four statutory anchors were corrected. These change computed dates, not just labels.

Denmark: the 2019 regime split is keyed on the registration date, not the filing date (Lov 1533/2018 §8 stk. 3). Marks filed before 2019-01-01 but registered after it were anchored up to a year off.
Mexico: the 2020 regime split is keyed on the filing date, not the grant date (LFPPI Transitorio DÉCIMO). Applications in prosecution when the LFPPI entered into force on 2020-11-05 stay on the old filing-anchored term.
Philippines: the third-year declaration of use window opens at the filing date and runs to the third anniversary of filing (RA 8293 §124.2). It was previously computed as a single day.
Thailand: publications before 2016-07-28 get the 90-day opposition window that was in force at the time. The 60-day window applies only from the 2016 amendment forward.

July 25, 2026: Jurisdiction protection scope

A precision fix to what jurisdictions means, plus honest screening verdicts when register coverage is incomplete. This is a behavior change: the same request can now return more results and, for screening, a new verdict value. Because it changes result sets during beta, read this before upgrading. jurisdictions now selects rights that protect, or seek protection, in a territory, not just literal territory legs. Previously jurisdictions=FR matched only French national filings and Madrid designations of France. It now also matches regional rights whose membership covers France, so a EU trade mark (which protects France) is included. See Search Trademarks and the glossary.

Result counts grow. A country-scoped filter picks up the regional rights that protect it. On production data, jurisdictions=FR roughly doubles once EU trade marks are counted. Countries with no live national office but active EU coverage (for example DE) go from a handful of Madrid hits to full EUTM coverage.
territory_match=direct restores the old behavior. Pass it to match only literal territory legs, byte-for-byte the pre-July-2026 result set. The default is territory_match=protection. Requesting a regional code (EU) stays strict on search: it matches EUTMs and IRs designating the EUIPO, not member-state national marks.
Why results grew is now explained. Under the default protection mode, each hit returned with a jurisdictions filter carries territory_matches[], mapping the requested code to the territory it matched on and the basis (direct leg or regional_membership). The field is absent under territory_match=direct. search_meta.territory_match echoes the mode that ran.
Suggest and image search grow too. GET /v1/trademarks/suggest and POST /v1/trademarks/search/image apply the same protection-scope expansion and accept territory_match. Suggest now also matches Madrid designations of a requested territory (an international registration designating France is suggested under jurisdictions=FR), and image search echoes the applied mode as search_meta.territory_match.
Member-country codes are newly accepted. Benelux member states (BE, LU, NL) and OAPI member states (for example SN) had no jurisdiction row of their own and previously returned 400. They are now valid jurisdictions values, so jurisdictions=BE selects Benelux and EU rights that protect Belgium.
Saved searches replay under the new semantics automatically. A stored search with jurisdictions=FR is re-executed against the current matcher, so it now returns EU trade marks it did not before, with no change on your side. If you need a saved search to keep the old literal-leg behavior, re-save it with territory_match=direct.
Breaking for pagination. Because the query shape of a jurisdiction-filtered search changed, pagination cursors minted before this release on such a query now return 400 cursor_invalid. Clients holding a stale cursor must restart pagination from the first page.
During the rolling deploy, expect a brief mixed window. While the release rolls out, requests may land on either old or new instances, so a jurisdiction-filtered query can alternate between the old and new result sets, and territory_match may return 400 from a not-yet-updated instance. Stale jurisdiction-filtered cursors invalidate as above. The window closes once every instance is on the new release; retry the request if you hit it.

Screening can now return needs_review when register coverage is incomplete. A clearance verdict is only trustworthy if Signa can actually see the marks that protect a requested territory. When the register that would carry a conflict is not connected live, a zero-conflict screen must not read as clear.

New verdict value. GET /v1/screening verdicts are now high_risk / caution / needs_review / clear. needs_review is a would-be clear that could not be confirmed because a requested territory’s register is dark or stale. Handle it as “we could not rule this out”, not as a weaker clear. Found conflicts still band high or medium exactly as before, observed risk is never suppressed.
Why this is deliberate. Before this change, screening a common brand in a class scoped to a territory whose national register was not yet connected could return clear with zero conflicts, even though real national marks existed and were simply invisible to us. Returning clear there is a false negative on a clearance product. We would rather tell you the corpus was incomplete than imply a name is safe.
A new coverage block on the screening response reports which registers gated the verdict (offices axis in ST.3 codes, territories axis in jurisdiction codes) and a complete_for_clear boolean. See Screen a Name.
Check a Listing gets the same protection-scope expansion, and an incomplete requested register forces a would-be clear to caution (the listing verdict enum is unchanged).
Screening responses are no longer client-cacheable. They are served Cache-Control: private, no-store. Re-run a screen rather than replaying a stored response.
screening_id values changed at this epoch. The identifier now folds the coverage inputs that can flip a verdict, so ids minted before this release do not correspond to ids minted after. Do not treat a pre-release screening_id as stable across this boundary.
Watches are unchanged. Monitoring keeps office-based scoping and does not apply the protection-scope expansion, so a watch scoped to a country still watches that country’s office only (a DE watch does not surface EU trade marks). See Create Watch.

July 14, 2026

Compare (beta): POST /v1/compare, its TypeScript SDK resource, and its developer guide complete the public-facing Intelligence surface alongside Screening. Compare scores one candidate against up to 10 selected conflicts.

​Changelog

​September 11, 2026: Fee endpoints accept platform office codes

​September 6, 2026: Portfolios are public

​September 5, 2026: Auth hardening, plan_gated, prefixed watch filters

​September 3, 2026: prosecution deadlines are served outside calendar coverage

​September 3, 2026: France, Finland and Poland Madrid designations get opposition windows

​September 3, 2026: holiday calendars now stop where their evidence stops

​September 3, 2026: close_adjustment on every opposition window

​September 3, 2026: opposition rule catalog reports both eras

​September 3, 2026: rule corrections (CN, PH, CH, CA, DE, MX)

​September 3, 2026: maintenance deadline corrections (EU, MX, NO, CA)

​September 3, 2026: China (CNIPA) deadlines and opposition windows

​September 3, 2026: Benelux opposition windows before 1 October 2013 corrected

​September 3, 2026: German Madrid designations get an opposition window

​September 3, 2026: Swiss Madrid opposition windows close up to 30 days earlier

​September 3, 2026: Norway Madrid opposition, and a publication-date guard for every Madrid rule

​September 3, 2026: EU restitutio, Canada’s transitional renewal window, India’s priority-dated term, and WIPO closure days

​September 3, 2026: Mexican OPPOSITION windows follow the same month-overflow rule, and the overflow is now reported

​September 3, 2026: Mexican deadlines now roll, month-overflow ends in the next month, and Madrid designations renew on the international registration

​September 3, 2026: Australian renewal grace periods roll onto the next open day

​September 3, 2026: renewal dates roll on closed office days in Norway, France and Iceland, and on BOIP’s own closing days in the Benelux

​September 3, 2026: EUIPO Article 2 days now extend time limits; consequence_if_missed vocabulary fixed

​September 3, 2026: Philippines, India and Iceland business-day calendars re-sourced

​September 3, 2026: Korea (KIPO) deadline and opposition rules

​September 3, 2026: Türkiye dates now roll, pre-2018 renewal windows and the 2017 opposition straddle corrected

​September 3, 2026: Danish renewal dates on office closing days now roll

​September 2, 2026: Philippines Renewal DAU window opens six months earlier

​September 2, 2026: Philippines Madrid designations get their own DAU anchors

​September 2, 2026: Swedish publication and expiry dates corrected (PRV connector)

​September 2, 2026: Canada (CIPO) opposition extension benchmark before December 2023

​September 2, 2026: MX oppositions before 30 August 2016 are no longer served

​September 2, 2026: India (CGPDTM) deadline and opposition rules

​September 2, 2026: Türkiye (TÜRKPATENT) deadline and opposition rules

​September 2, 2026: Japan (JPO) deadline and opposition rules

​September 2, 2026: opposition window opening day corrected (Benelux, Finland, Norway, Sweden)

​September 2, 2026: German renewal dates corrected for applications pending on 14 January 2019

​September 2, 2026: French renewal grace end corrected (moves later)

​September 2, 2026: office calendar corrections

​September 2, 2026: Era-aware opposition citations

​September 2, 2026: Vietnamese opposition windows corrected (3 months since 1 April 2026)

​September 2, 2026: Brazilian and Mexican renewal deadlines

​September 2, 2026: Icelandic renewal dates corrected

​September 2, 2026: Office rule reference data provenance

​September 2, 2026: The events feed is documented (beta)

​September 2, 2026: Alert diffs use public field names (breaking, beta)

​September 2, 2026: Office dates and your docket reference on events

​September 2, 2026: Webhook subscriptions, portfolio scope, and diff field names

​September 2, 2026: Richer goods/services validation evidence

​September 2, 2026: Goods/services catalog validation

​September 2, 2026: Entity lists and suggest answer 503 when OpenSearch is unavailable

​September 2, 2026: Saved searches removed

​September 2, 2026: Swedish renewal dates corrected

​September 1, 2026: Office-action webhook events

​September 1, 2026: Trademark status webhooks and portfolio-scoped endpoints

​September 1, 2026: BREAKING — webhook event envelope

​September 1, 2026: Forward replay on GET /v1/events

​September 1, 2026: Examiner citations

​September 1, 2026: Every rule has a stable id

​September 1, 2026: Prosecution deadlines on /v1/deadlines/compute

​August 31, 2026: Computed data moves under derived

​August 30, 2026: Deadline engine statutory corrections

​July 25, 2026: Jurisdiction protection scope

​July 14, 2026