Maintenance Fee Docketing

Maintenance fee docketing is the discipline of tracking the three post-grant payments a US utility patent needs to stay in force — due at 3.5, 7.5, and 11.5 years after grant under 35 U.S.C. § 41(b) — and generating the payment windows, grace periods, and escalating reminders that stop a patent from silently expiring. Unlike a one-off prosecution deadline, each fee opens a six-month payment window, closes on a due date, reopens under a surcharge for a further six months, and then extinguishes the patent, so the record has four distinct dates that all have to be computed from a single base date and surfaced years apart.

This is one of the highest-consequence obligations in a portfolio: a missed maintenance fee does not merely delay a matter, it ends the patent’s enforceable life. This page fixes the statutory scope, the record contract, the window-generation logic, and the verification a maintenance-fee subsystem needs. It builds on the deadline categories defined in Core Docketing Architecture & Deadline Types, defers all month arithmetic and holiday rolls to the Automated Deadline Calculation & Rule Engines framework, and hands recovery of an already-lapsed patent to Reviving a Lapsed Patent: USPTO Unintentional-Delay Petition.

Why maintenance-fee docketing is its own discipline

Most docketed deadlines are a single date: respond by, file by, pay by. A maintenance fee is not one date but a staged sequence, and treating it like a single reminder is the classic way portfolios are lost. The obligation is defined by four moments that all derive from the grant date — the moment the window opens, the moment the base fee is due, the moment the surcharge-bearing grace period closes, and the moment the patent expires — and a docketing system that surfaces only one of them leaves the others as blind spots.

The failure mode is also unusually quiet. There is no Office action, no examiner communication, and no adversary prompting action; the clock runs entirely on the calendar. The USPTO does mail courtesy reminders, but reliance on them is not a defense, and the notification stream itself has to be parsed and reconciled rather than trusted — a task handled by the handling of USPTO maintenance-fee notification parsing layer. The system must therefore be the primary source of truth, computing each window independently from the grant date and escalating on its own schedule rather than waiting for the office to prompt it.

A second complication is that the fee amount is not a constant. It depends on entity status, which can change between the three payments, and on a fee schedule the USPTO revises periodically. Docketing must track whether and by when a fee is owed as a hard compliance date, while treating the dollar amount as a separate, mutable lookup that is never hard-coded into the deadline record.

Operational Action: Model each maintenance fee as four linked dates derived from one grant date, not as a single “fee due” reminder, and make the docketing system the authoritative clock rather than a passive relay of USPTO courtesy notices.

Statutory scope and the fee schedule

Maintenance fees are creatures of statute and rule, and every date the system computes must trace to one of them. The governing authority is 35 U.S.C. § 41(b), implemented by the payment rules at 37 CFR §§ 1.362 through 1.378. The scope boundaries matter as much as the dates:

• Utility patents only. Maintenance fees apply to original and reissue utility patents based on applications filed on or after 12 December 1980. Design patents and plant patents carry no maintenance fees, so a docketing system must suppress the obligation for those patent types rather than generating phantom deadlines.
• Base date is the grant date. All three fees are measured from the date the original patent was granted, not the filing date and not, for a reissue, the reissue date. A utility reissue inherits the original patent’s grant-date schedule.
• Three payments, then the term runs its course. After the 11.5-year fee, no further maintenance fees are owed; the patent then simply runs to the end of its 20-year term (measured from the earliest non-provisional filing date), subject to any patent term adjustment.

The payment window for each fee opens six months before the due date under 37 CFR § 1.362(d), and a six-month grace period follows the due date under 37 CFR § 1.362(e), during which the fee is accepted only with the surcharge set out in 37 CFR § 1.20(h). If the fee is still unpaid when the grace period closes, the patent expires under 35 U.S.C. § 41(b)(2). The following matrix is the canonical schedule a rule record should encode:

Entity status drives the amount, not the dates. A small entity pays reduced fees under 37 CFR § 1.27; a micro entity pays further-reduced fees under 37 CFR § 1.29. Status must be re-verified at each payment, because a company that qualified as a small entity at the 3.5-year fee may have grown, licensed the patent, or otherwise lost eligibility by the 7.5-year fee — and paying a small-entity fee while no longer entitled is an improper payment that can jeopardize the patent. The exact-date arithmetic that turns this schedule into calendar dates, including the weekend/holiday roll, is specified in USPTO Maintenance Fee Grace-Period Calculation.

Operational Action: Encode the three-row schedule above as a version-pinned rule record keyed to patent type, suppress it entirely for design and plant patents, and store entity status as a per-fee attribute that is re-verified before each payment rather than copied forward.

Prerequisites: the data a fee record needs

Before a single date is computed, the record must carry a validated set of inputs. A maintenance-fee obligation cannot be docketed from a bare patent number; it needs enough provenance to be defensible and enough context to be suppressed when it does not apply.

• Patent number and patent type. The type gates the entire obligation — utility patents are in scope, design and plant patents are not.
• Grant date. The single base date from which all twelve dates (four per fee) derive. It must come from an authoritative source — the issued patent or a reconciled office feed — never a hand-typed guess.
• Entity status per fee. Large, small (§ 1.27), or micro (§ 1.29), captured as a value that can differ across the three fees.
• Jurisdiction and roll calendar. For the USPTO, the roll rule is the District-of-Columbia federal calendar under 37 CFR § 1.7; foreign counterparts are handled separately in USPTO Maintenance Fees vs EPO Annuities.
• Payment state. Whether each fee has been paid, and if so the confirmation reference, so a paid fee is retired from the reminder cadence and never re-alerts.

Operational Action: Reject any maintenance-fee record that lacks a sourced grant date or a patent-type classification; both are load-bearing, and a record missing either must fail validation loudly rather than generate best-effort dates.

Step-by-step: generating the docketing windows

The core routine takes a grant date and returns the four nominal dates for each of the three fees. It uses dateutil.relativedelta for calendar-correct month arithmetic — a fixed 30- or 365-day offset would drift across leap years and unequal months and eventually mis-date a fee — and deliberately produces nominal dates only. The weekend/holiday roll is applied downstream by the shared calendar service, so this function stays a pure, testable computation.

from __future__ import annotations

from dataclasses import dataclass
from datetime import date

from dateutil.relativedelta import relativedelta

# Months from the grant date to each maintenance-fee due date.
# 3.5 yr = 42 months, 7.5 yr = 90 months, 11.5 yr = 138 months
# (35 U.S.C. 41(b); 37 CFR 1.362).
FEE_STAGES_MONTHS: tuple[int, ...] = (42, 90, 138)


@dataclass(frozen=True)
class FeeWindow:
    """The four nominal dates of one maintenance fee, before any holiday roll."""
    stage_years: float   # 3.5 | 7.5 | 11.5
    window_opens: date   # 6 months before due — 37 CFR 1.362(d)
    due_date: date       # last day to pay without surcharge
    grace_ends: date     # +6 months, surcharge under 37 CFR 1.20(h) applies
    expiration: date     # patent expires if still unpaid — 35 U.S.C. 41(b)(2)


def maintenance_windows(grant_date: date) -> list[FeeWindow]:
    """Compute nominal windows for all three USPTO maintenance fees."""
    windows: list[FeeWindow] = []
    for months in FEE_STAGES_MONTHS:
        due = grant_date + relativedelta(months=months)
        opens = due - relativedelta(months=6)          # window opens at 3/7/11 yr
        grace_ends = due + relativedelta(months=6)     # grace closes at 4/8/12 yr
        # The patent expires the day after the grace period closes.
        expiration = grace_ends + relativedelta(days=1)
        windows.append(FeeWindow(
            stage_years=months / 12,
            window_opens=opens,
            due_date=due,
            grace_ends=grace_ends,
            expiration=expiration,
        ))
    return windows

For a patent granted on 15 February 2022, the first fee window opens 15 February 2025, the fee is due 15 August 2025, the grace period closes 15 February 2026, and the patent would expire 16 February 2026 if still unpaid. The reminder cadence then hangs off the grace_ends date — the true point of no return — rather than the softer due_date:

from datetime import date

# Days before the grace deadline at which each escalating reminder fires.
REMINDER_OFFSETS_DAYS: tuple[int, ...] = (180, 90, 30, 7)


def reminder_dates(window: FeeWindow) -> list[date]:
    """Escalating reminders anchored to the grace deadline, not the due date."""
    # The 180-day reminder coincides with the window opening; the rest tighten
    # as the point of no return approaches.
    return [window.grace_ends - relativedelta(days=d) for d in REMINDER_OFFSETS_DAYS]

Anchoring reminders to grace_ends is deliberate: a firm that misses the due_date has not yet lost anything except the surcharge, but a firm that misses grace_ends has lost the patent. The cadence therefore intensifies toward the grace deadline and continues daily through the final week, mirroring the tiered reminder patterns described in the broader Automated Deadline Calculation & Rule Engines framework.

Operational Action: Keep window generation pure and holiday-free, apply the roll rule in the shared calendar service, and anchor the reminder cadence to the grace deadline so an unpaid fee escalates toward the true expiration point rather than the earlier, recoverable due date.

The maintenance-fee record contract

At the ingestion boundary, a Pydantic model validates every field before a record enters the docket. It enforces the patent-type gate, constrains the stage to the three legal values, and captures entity status as a typed enum so an unrecognized status can never silently reduce a fee.

from __future__ import annotations

from datetime import date
from enum import Enum

from pydantic import BaseModel, Field, field_validator


class PatentType(str, Enum):
    UTILITY = "utility"
    REISSUE_UTILITY = "reissue_utility"
    DESIGN = "design"    # no maintenance fees
    PLANT = "plant"      # no maintenance fees


class EntityStatus(str, Enum):
    LARGE = "large"
    SMALL = "small"      # 37 CFR 1.27
    MICRO = "micro"      # 37 CFR 1.29


class MaintenanceFeeRecord(BaseModel):
    """Validated at the ingestion boundary before any date is computed."""
    patent_number: str = Field(pattern=r"^\d{7,8}$")
    patent_type: PatentType
    grant_date: date
    entity_status: EntityStatus
    stage_years: float
    paid: bool = False

    @field_validator("patent_type")
    @classmethod
    def fees_apply(cls, v: PatentType) -> PatentType:
        # Design and plant patents carry no maintenance-fee obligation.
        if v in (PatentType.DESIGN, PatentType.PLANT):
            raise ValueError("maintenance fees do not apply to design or plant patents")
        return v

    @field_validator("stage_years")
    @classmethod
    def known_stage(cls, v: float) -> float:
        if v not in (3.5, 7.5, 11.5):
            raise ValueError("stage_years must be 3.5, 7.5, or 11.5")
        return v

The contract carries the schedule state, while the amount is resolved separately at payment time from a fee-schedule table keyed by (stage, entity status, effective date). Keeping the dollar figure out of the record means a mid-cycle USPTO fee increase updates one lookup table rather than rewriting every open obligation, and the schema mapping that populates these fields is governed by the USPTO Data Schema Mapping specification.

Operational Action: Validate patent type and stage at the boundary, store entity status as a typed enum so an unknown value fails rather than defaults, and resolve fee amounts from a dated lookup table at payment time instead of embedding them in the deadline record.

Edge cases and failure modes

• Design and plant patents. These have no maintenance fees. A system that generates windows from patent type alone, or defaults every issued patent to “utility,” will produce false deadlines and false alarms. Suppress the obligation at the type gate.
• Reissue timing. A utility reissue keeps the original patent’s grant-date schedule. Anchoring the fees to the reissue date pushes every window years late and can cause a fee to be missed entirely.
• Entity-status drift. Status is re-assessed at each fee. A patent that was small-entity at 3.5 years may be large-entity at 7.5 years after an acquisition or license. Paying the reduced fee when no longer entitled is an improper payment; the record must prompt re-verification, not copy status forward.
• Grace deadline on a weekend or holiday. When the last day of a window or grace period falls on a Saturday, Sunday, or DC federal holiday, it rolls to the next business day under 37 CFR § 1.7(b). The roll must be applied to the effective deadline while the nominal date is preserved for audit — the exact mechanics live in USPTO Maintenance Fee Grace-Period Calculation.
• Already lapsed. If the grace period has closed with the fee unpaid, the patent has expired and no ordinary payment will revive it. The only path is a petition under 37 CFR § 1.378, covered in Reviving a Lapsed Patent: USPTO Unintentional-Delay Petition. The docketing system must flag this state distinctly, because it changes both the responsible party and the remedy.

Operational Action: Write regression cases for design/plant suppression, reissue base-date inheritance, entity-status drift, and weekend rolls, and give the “lapsed” state its own status code so it escalates to a petition workflow rather than re-alerting as an ordinary unpaid fee.

Verification and tests

A maintenance-fee subsystem earns trust through a fixture suite that pins known patents to known dates. Every schedule change and every calendar update must run against it before deployment.

• Anchor dates. For a fixed grant date, assert all four dates of all three fees. A 15 February 2022 grant must yield window-open 15 February 2025, due 15 August 2025, grace-end 15 February 2026, expiration 16 February 2026 for the first fee, and the corresponding 7.5- and 11.5-year sets.
• Month-end and leap-year boundaries. A 31 August grant plus 42 months (to a February due date) must land on a valid day, and a 29 February grant must resolve cleanly across non-leap anniversaries — the reason relativedelta is mandatory over fixed-day offsets.
• Suppression. Assert that design and plant records raise at validation and never enter the window generator.
• Roll correctness. Cross-check effective grace deadlines that fall on weekends and DC federal holidays against the office calendar, asserting the forward shift.
• Idempotency. Re-ingesting the same patent must reconcile to one obligation set, never a duplicate schedule.

Operational Action: Gate every deployment on a fixture suite that pins at least one real patent’s full twelve-date schedule, and re-run it whenever the fee schedule, holiday table, or entity rules change so a silent drift is caught before it reaches production.

Operational summary

• Each fee is modelled as four linked dates (window open, due, grace end, expiration) derived from one sourced grant date.
• Design and plant patents are suppressed at the patent-type gate; utility reissues inherit the original grant-date schedule.
• Entity status is stored per fee and re-verified before each payment, never copied forward.
• Fee amounts are resolved from a dated lookup table, not embedded in the deadline record.
• Window math is pure and holiday-free; the roll rule under 37 CFR § 1.7 is applied by the shared calendar service, preserving both nominal and effective dates.
• Reminders are anchored to the grace deadline and intensify toward it, then run daily through the final week.
• The “lapsed” state has a distinct status code that routes to the § 1.378 petition workflow.
• A fixture suite pins full twelve-date schedules for known patents and runs on every schedule or calendar change.

Frequently Asked Questions

Related

• Core Docketing Architecture & Deadline Types — the deadline categories and audit boundaries this schedule plugs into.
• Automated Deadline Calculation & Rule Engines — the month arithmetic and reminder cadence the fee windows feed.
• USPTO Maintenance Fee Grace-Period Calculation — the exact date math and weekend/holiday roll.
• USPTO Maintenance Fees vs EPO Annuities — how the US triennial model contrasts with European annual renewals.
• Reviving a Lapsed Patent: USPTO Unintentional-Delay Petition — the recovery path once the grace period has closed.

↑ Back to Core Docketing Architecture & Deadline Types