Core Docketing Architecture & Deadline Types

Enterprise IP docketing is a deterministic compliance engine, not a shared calendar: the same filing event must produce the same defensible due date every time it is computed, years apart, on any machine. System engineers and paralegals must reconcile non-interchangeable statutory frameworks, isolate per-office data, and seal every calculation into a tamper-evident record — because a single mis-rolled date is a malpractice event, not a rounding error.

This page is the reference the rest of the system is built against. It fixes the governing statutes, the canonical pipeline every event flows through, the four deadline categories that dictate recovery and approval paths, and the audit boundaries that make a computation survive review. The deterministic date arithmetic these rules feed is treated in depth in the Automated Deadline Calculation & Rule Engines framework, and the live office feeds that supply base dates are owned by the Patent Office Portal Sync & Data Ingestion layer.

Regulatory & Statutory Baseline

A docketing system is only as defensible as the instruments it encodes. Before any date arithmetic is written, each governing statute and its computation rule must be pinned to a citable source, because every office computes periods from a different base date and rolls non-working days under a different provision. Conflating them is the single most common source of silent miscalculation.

United States (USPTO). Responses to Office actions run under 35 U.S.C. § 133; the shortened statutory period is three months under 37 CFR § 1.134, extendable to the six-month statutory maximum under 37 CFR § 1.136(a) on payment of tiered extension fees. When a period ends on a Saturday, Sunday, or federal holiday within the District of Columbia, it rolls forward to the next business day under 35 U.S.C. § 21(b) and 37 CFR § 1.7(a). Maintenance fees fall due at 3.5, 7.5, and 11.5 years under 35 U.S.C. § 41(b), each with a six-month grace window under 37 CFR § 1.362 — the windows, surcharges, and revival paths are handled by the Maintenance Fee Docketing framework. The system must therefore track both the nominal statutory end and the effective deadline after roll-forward.

Europe (EPO). Time limits are governed by the European Patent Convention. The four-month period to respond to an examination communication runs under EPC Rule 71, computed from the date of notification. The historical ten-day notification rule was abolished on 1 November 2023, so any rule keyed to notification must be versioned by effective date. Periods expiring on a day when an EPO filing office is not open for receipt of documents extend to the next such day under EPC Rule 134, and further processing under EPC Article 121 provides a recovery path that itself generates a fresh, feed-driven deadline.

International (WIPO / PCT). The Patent Cooperation Treaty drives the highest-value deadlines in most portfolios. National phase entry runs 30 months from the priority date under PCT Article 22 and 31 months under Article 39 where a demand for international preliminary examination applies, though many offices set a longer uniform period by national law. PCT Rule 80.5 rolls any period expiring on a day when the relevant office is closed — and “the relevant office” is the national office of entry, not WIPO, so the same 30-month anchor can produce different effective dates in different countries. The 12-month Paris Convention priority period under PCT Article 8 anchors the priority chain that everything downstream depends on.

The practical consequence is a hard architectural rule: base date, period length, and roll calendar are three independent inputs, each sourced and versioned separately. Never infer a base-date choice, a period length, or a holiday calendar implicitly from jurisdiction alone.

Operational Action: Encode every row of this matrix as a versioned rule record carrying an explicit effective_from date and a citation URL. Bind base date, period length, and holiday calendar explicitly at resolution time — never let any of the three be inferred from the jurisdiction code.

Canonical Architecture Overview

A compliant docketing pipeline operates on an event-driven, stateless computation model so that reproducibility is structural: identical inputs must always yield an identical due date and an identical audit hash, regardless of when or where the engine runs. The pipeline executes in five discrete stages, each with a single responsibility and an explicit contract to the next. Idempotency is enforced at the boundary — a duplicate API callback, a re-sent bulk XML drop, and a manual OCR re-entry of the same document must all resolve to one ledger entry, never three deadlines.

1. Ingestion Gateway. Accepts raw docket events — filing receipts, Office action mail dates, priority claims, fee demands — from authenticated office feeds, bulk XML/JSON drops, and manual entry. Each endpoint enforces an idempotency key and rejects any payload that fails structural validation before it enters the queue.
2. Schema Normalization. Maps each jurisdiction’s raw fields into a canonical DocketEvent carrying an explicit UTC timestamp, an ISO-3166 jurisdiction code, a WIPO ST.96 application identifier, and full base-date provenance. No downstream stage ever sees a raw office payload.
3. Rule Resolution. Looks up the applicable rule in a declarative, version-pinned registry keyed by (event type, jurisdiction, effective date), resolves dependency chains in topological order, and computes the nominal period end with calendar-correct month arithmetic.
4. Calendar & Holiday Roll. A dedicated calendar service applies the jurisdiction’s non-working-day rule to shift the nominal end to the effective deadline. This stage is deliberately isolated so a holiday-table update never touches core period math.
5. Append-Only Audit Ledger. Persists the input payload, the resolved rule version hash, the nominal and effective dates, and a cryptographic record hash chained to the prior entry. This ledger is the artifact a malpractice reviewer reconstructs a computation from.

Operational Action: Enforce idempotency keys at the ingestion gateway and reject any event that fails structural validation before it enters normalization. A duplicate Office-action callback must resolve to the same ledger entry, not a second deadline.

Jurisdictional Isolation & Schema Mapping

Patent prosecution spans non-interchangeable regulatory ecosystems, and cross-contamination of jurisdictional logic produces fatal miscalculations. Isolation is enforced through a per-office adapter pattern: each office has its own schema mapper and its own rule set, and the two never share mutable state. Each patent office maintains distinct publication cadences, legal-status codes, and data structures that demand isolated processing contexts.

The USPTO ecosystem distributes prosecution data through Patent Center and bulk XML feeds; field resolution follows the USPTO Data Schema Mapping specification, which governs how application-type codes, continuation lineage, and terminal-disclaimer triggers map onto the canonical model. Benefit-claim windows and copendency across an application family are resolved by the Continuation & CIP Deadline Tracking framework. Misaligned schema interpretation corrupts maintenance-fee windows and statutory response periods directly. International events are captured through WIPO PATENTSCOPE Integration, which supplies international publication dates, priority claims, and PCT status transitions, while European filings synchronize through the EPO Register Sync Architecture so that examination communications, opposition windows, and validation states arrive with the correct notification dates.

Each adapter pins the schema version it was written against. When an office publishes a new schema revision, the adapter must fail loudly — a schema-version mismatch is a critical alert, never a best-effort parse — so a silently renamed field can never poison a base date. Adapters emit only canonical DocketEvent objects; downstream rule resolution is written once and is jurisdiction-agnostic, selecting behavior purely by the event’s jurisdiction code.

# rule_registry/uspto/office_action_response.yaml
# Source: 37 CFR 1.134  https://www.ecfr.gov/current/title-37/section-1.134
# Source: 37 CFR 1.7(a) https://www.ecfr.gov/current/title-37/section-1.7
rule_id: USPTO_OA_RESPONSE
jurisdiction: US
event_type: office_action_mailed
effective_from: "2013-03-19"    # AIA fee-schedule era; pin to citation revision
period:
  unit: months
  length: 3                     # shortened statutory period, extendable under 1.136(a)
base_date_field: mail_date_utc
roll_calendar: US_DC_FEDERAL    # weekends + DC federal holidays, 35 USC 21(b)
schema_version: "USPTO_ST96_v2024.1"
version: "USPTO_37CFR_1.134_v2024.1"

Operational Action: Store rule and adapter files under version control and require every adapter to assert its expected schema version at load time. Log any mismatch as a critical, page-the-on-call alert rather than degrading to a partial parse.

Deadline Taxonomy & Rule Resolution

A deterministic system classifies every computed date into one of four immutable categories, because the category dictates which recovery paths and approval controls apply:

• Statutory deadlines are fixed by legislation or treaty and are non-negotiable — the 12-month Paris Convention priority period, the 30/31-month PCT national phase entry under Articles 22 and 39, the six-month absolute maximum for USPTO responses under § 1.136. Missing one is generally unrecoverable except through narrow petition mechanisms.
• Procedural deadlines are triggered by an office event — an Office action mail date, a Notice of Allowance, an issue-fee or maintenance-fee demand. Their base date arrives from the ingestion feed and can shift if the underlying event is corrected.
• Discretionary extensions are granted on request, petition, or fee payment — USPTO § 1.136(a) extensions, EPC Article 121 further processing, terminal-disclaimer filings. The system computes them but must require dual approval before treating them as the operative date.
• Holiday-adjusted deadlines are any of the above whose nominal end lands on a non-working day and rolls forward under the office’s roll rule. Both the nominal and the effective date are always preserved so an auditor can see why the operative date moved.

The PCT framework introduces the most complex temporal dependencies and requires explicit rule chaining: a national-phase deadline depends on the priority date, which may itself depend on a priority-restoration decision. The PCT National Phase Entry Rules framework governs how the 30/31-month anchor is resolved across multiple designated states, accounting for regional grace periods, translation requirements, and local fee schedules. The resolver evaluates in topological order, refuses to compute a dependent deadline while an upstream input is unresolved, detects overlapping deadlines, and records the exact statute, rule version, and roll calendar applied to each result — never silently overriding a computed date.

Operational Action: Persist a rule-evaluation matrix for every matter that logs the statute cited, the rule version hash, and the roll calendar used. Reject silent overrides; require dual approval for any discretionary date shift.

Production Python Implementation

Production docketing requires strict type safety, explicit timezone handling, and strategy-based rule evaluation. Naive datetime arithmetic fails under regulatory scrutiny: fixed-day offsets mishandle month lengths and leap years, and naive objects silently assume local time. The reference implementation uses the standard-library zoneinfo module for IANA-compliant timezones (never pytz), dateutil.relativedelta for calendar-correct month and year offsets, and Pydantic for validation at the ingestion boundary. A strategy protocol isolates jurisdictional logic so a rule can be swapped without touching the computation pipeline.

from __future__ import annotations

import hashlib
from datetime import date, datetime, time
from typing import Protocol
from zoneinfo import ZoneInfo

from dateutil.relativedelta import relativedelta
from pydantic import BaseModel, Field, field_validator

UTC = ZoneInfo("UTC")


class DocketEvent(BaseModel):
    """Canonical, jurisdiction-agnostic event. Validated at the ingestion boundary."""
    application_number: str
    jurisdiction: str = Field(pattern=r"^[A-Z]{2}$")   # ISO-3166 alpha-2
    event_type: str
    deadline_category: str                              # statutory | procedural | discretionary | holiday_adjusted
    base_date_utc: datetime

    @field_validator("base_date_utc")
    @classmethod
    def enforce_utc(cls, v: datetime) -> datetime:
        # Reject naive datetimes outright; normalize everything else to UTC.
        if v.tzinfo is None or v.utcoffset() is None:
            raise ValueError("base_date_utc must be timezone-aware")
        return v.astimezone(UTC)


class HolidayCalendar(Protocol):
    """Injected roll calendar. Implementations wrap versioned holiday datasets."""
    def is_working_day(self, d: date) -> bool: ...
    def version(self) -> str: ...


class RuleStrategy(Protocol):
    def nominal_deadline(self, event: DocketEvent) -> date: ...
    def rule_version(self) -> str: ...


class USPTOResponseRule:
    """3-month statutory response period under 37 CFR 1.134.

    relativedelta gives month-accurate arithmetic (a 31 Jan base rolls to
    30 Apr, never an invalid 31 Apr). Holiday roll is applied separately.
    """
    def nominal_deadline(self, event: DocketEvent) -> date:
        return event.base_date_utc.date() + relativedelta(months=3)

    def rule_version(self) -> str:
        return "USPTO_37CFR_1.134_v2024.1"


def roll_forward(nominal: date, calendar: HolidayCalendar) -> date:
    """Shift a nominal end to the next working day (35 USC 21(b) / PCT Rule 80.5)."""
    effective = nominal
    while not calendar.is_working_day(effective):
        effective += relativedelta(days=1)
    return effective


def compute(event: DocketEvent, rule: RuleStrategy, calendar: HolidayCalendar) -> dict[str, str]:
    nominal = rule.nominal_deadline(event)
    effective = roll_forward(nominal, calendar)
    # End-of-day in UTC is the operative cut-off stored on the record.
    due_utc = datetime.combine(effective, time(23, 59, 59), tzinfo=UTC)
    payload = "|".join([
        event.application_number,
        event.jurisdiction,
        rule.rule_version(),
        calendar.version(),
        nominal.isoformat(),
        effective.isoformat(),
    ])
    return {
        "deadline_category": event.deadline_category,
        "nominal_deadline": nominal.isoformat(),
        "effective_deadline": effective.isoformat(),
        "due_date_utc": due_utc.isoformat(),
        "rule_version": rule.rule_version(),
        "calendar_version": calendar.version(),
        "audit_hash": hashlib.sha256(payload.encode()).hexdigest(),
    }

Calendar arithmetic is deliberately decoupled from period math: the HolidayCalendar protocol lets the system inject a US federal calendar, an EPO filing-office calendar, or a specific national office’s closure table for a PCT entry without ever editing the rule that computes the nominal period. Enforce UTC storage everywhere and convert to local time only at the presentation layer. For robust IANA timezone handling, see the Python zoneinfo documentation.

Operational Action: Wrap all date arithmetic in a regression suite that asserts month-end rollovers (e.g. 30 November base + 3 months), leap-year boundaries, and holiday shifts against each office’s published calendar. Pin every holiday dataset to a specific release version and store that version in the audit record.

Validation, Audit & Compliance Boundaries

Audit readiness requires strict separation of computation, validation, and access control, and every computed date must survive a bracketing pair of checks before it is allowed to drive an alert:

1. Pre-computation check. Validate the base date against the official office event log and reject ambiguous timezones or unregistered jurisdiction codes at ingestion.
2. Rule execution. Apply statutory and procedural logic with explicit rule-version pinning, resolving dependencies in topological order.
3. Post-computation reconciliation. Cross-reference the result against a secondary evaluation — a second engine instance or a manual reference ledger — before the date becomes operative.
4. Immutable commit. Append the final state to the audit ledger with cryptographic verification.

Every accepted computation is written to an append-only ledger as an immutable record: input payload, rule version hash, nominal and effective dates, roll-calendar version, operator identity, and a SHA-256 record hash that chains to the previous entry. Finalized records are read-only; corrections are new entries with explicit justification, never in-place edits. Role-based access must segregate data strictly — paralegals, docketing managers, and external counsel require differentiated permissions to view, edit, and approve deadline states. The Security & Access Control Boundaries model governs that segregation, keeps prosecution data isolated, and ensures compliance reporting satisfies malpractice-insurance and regulatory review standards.

Operational Action: Run nightly regression jobs against historical prosecution data to detect rule drift or schema deprecation, and enforce read-only access to finalized ledger entries with dual-control on any discretionary override.

Operational Checklist

Complete every item before promoting a docketing system to production:

• Every rule in the registry carries a citation URL, an effective_from date, and a version hash; base date, period length, and roll calendar are bound explicitly, never inferred from jurisdiction alone.
• Ingestion enforces idempotency keys and rejects malformed dates, ambiguous timezones, and unregistered jurisdiction codes before normalization.
• Each office adapter asserts its expected schema version at load time and alerts loudly on mismatch.
• All temporal values are timezone-aware and normalized to UTC; local time appears only at the presentation layer.
• Month/year offsets use relativedelta; holiday roll is a separate, injectable calendar service pinned to a dataset version.
• Every computed date is classified into exactly one of the four deadline categories, and both nominal and effective deadlines are persisted.
• A regression suite covers month-end rollovers, leap years, statutory maxima, grace-period overlaps, and holiday shifts against each office’s published calendar.
• Post-computation reconciliation runs against a secondary engine or reference ledger before any alert fires.
• The audit ledger is append-only, hash-chained, and read-only for finalized entries; overrides require dual approval with recorded justification.
• Role-based access segregates view/edit/approve permissions, and compliance exports are reproducible for malpractice-insurance and regulatory review.

Frequently Asked Questions

Related

• Automated Deadline Calculation & Rule Engines — the deterministic date arithmetic this architecture feeds.
• Patent Office Portal Sync & Data Ingestion — the upstream feeds that supply validated base dates.
• USPTO Data Schema Mapping — application-type, continuation, and terminal-disclaimer field resolution.
• PCT National Phase Entry Rules — the 30/31-month anchor across designated states.
• Security & Access Control Boundaries — role segregation and tamper-evident audit access.
• Docket Alerting, Escalation & Compliance Reporting — turning computed deadlines into timely, escalating, auditable action.

↑ Back to IP Docketing Automation