Copendency Requirements for Continuation Applications

Copendency is the requirement, imposed by 35 U.S.C. § 120, that a continuation application be filed before the prior application it claims benefit from is patented, abandoned, or has proceedings terminated. It is the load-bearing condition of the entire continuing-application system: without an unbroken chain of copending applications, a continuation is not entitled to its parent’s filing date, and every claim collapses to the continuation’s own, far later date — exposing them to years of intervening prior art.

This procedure sits under Continuation & CIP Deadline Tracking and supplies the copendency check that the Priority Claim Chain Validation engine relies on when it traverses a multi-generation family. Where terminal-disclaimer tracking watches the child’s own prosecution, copendency watches the parent’s terminal events — the moments that close the window forever.

The Rule, Precisely Stated

The statute at 35 U.S.C. § 120 conditions benefit on the later application being “filed before the patenting or abandonment of or termination of proceedings on the first application.” Three distinct terminal events can close the copendency window, and a docketing system must recognize all three:

• Patenting. The parent issues as a patent. A patent grants at the beginning of its issue date, so a continuation filed on the issue date is copending, but one filed the following day is not. The issue date is the hard boundary.
• Abandonment. The parent goes abandoned — most commonly by failure to respond to an Office action, which takes effect the day after the last extendable response date under 37 CFR § 1.135, or by failure to pay the issue fee. Abandonment is dangerous precisely because it arrives silently; no affirmative notice defines the moment for the docket unless the system computes it.
• Termination of proceedings. Proceedings end — for example, after an appeal decision with no further action available. This is the least common but must still be modeled as a window-closing event.

There is no grace period on copendency and no petition to revive a lost benefit claim once the window has closed. This is what makes it a statutory deadline in the taxonomy defined by the Core Docketing Architecture & Deadline Types reference — categorically unrecoverable, unlike the petition-curable benefit-claim statement discussed below. The examination guidance is collected in MPEP § 211.01(b).

Operational Action: Treat every parent terminal event — issue date, computed abandonment date, termination of proceedings — as a copendency alarm on any child that is or might be filed against it. Escalate a copendency miss as statutory/unrecoverable, never as a curable formality.

Copendency vs. the Benefit-Claim Statement

Copendency is often confused with the benefit-claim timing rule, but they are separate gates with opposite recoverability. Copendency governs when the child must be filed; the benefit-claim statement governs when the child must formally reference the parent. Under 37 CFR § 1.78, a non-provisional claiming benefit under § 120 must include a specific reference to the prior application in an application data sheet, and § 1.78(d)(3) sets the deadline at the later of four months from the child’s actual filing date or sixteen months from the parent’s filing date.

The critical difference for the docket is recoverability. A late benefit-claim statement can be accepted on a petition under § 1.78© with a fee and an unintentional-delay statement — it is procedural. A copendency failure cannot be cured at all — it is statutory. A system that files a continuation one day after the parent’s grant has lost the benefit permanently, and no timely § 1.78 statement can resurrect it. The two must therefore be modeled as distinct deadlines with distinct escalation categories, exactly as the Continuation & CIP Deadline Tracking model prescribes.

Validating Copendency Across a Family

Because § 120 benefit is transitive, copendency must hold at every link, not just between the child and its immediate parent. A great-grandchild reaches the original filing date only if the grandparent–parent link and the parent–child link are both copending. A single break anywhere in the chain truncates the effective filing date for everything below the break. The validator below walks a family from a leaf application up to the root, checks each link, and reports the first broken link rather than silently returning a truncated date.

from __future__ import annotations

from dataclasses import dataclass
from datetime import date


@dataclass(frozen=True)
class FamilyLink:
    """One benefit link: `child` claims the filing date of `parent`."""
    child_number: str
    child_filing_date: date
    parent_number: str
    parent_filing_date: date
    # The parent's earliest terminal event (issue, abandonment, or termination).
    # None means the parent is still pending, so copendency is intact.
    parent_terminated_on: date | None


@dataclass(frozen=True)
class CopendencyResult:
    is_valid: bool
    broken_link: FamilyLink | None       # first link that fails, if any
    effective_filing_date: date          # earliest date the leaf can actually claim


def validate_family_copendency(chain: list[FamilyLink]) -> CopendencyResult:
    """Validate 35 U.S.C. 120 copendency along a chain ordered leaf -> root.

    Each link is copending only if the child was filed on or before the parent's
    terminal event (a patent grants at the START of its issue date, so filing ON
    that date is still copending -> the test is `<=`). The first broken link
    truncates the effective filing date to that link's child date, because no
    benefit propagates across a break.
    """
    if not chain:
        raise ValueError("chain must contain at least one FamilyLink")

    # Absent a break, the leaf inherits the root parent's filing date.
    effective = chain[-1].parent_filing_date

    for link in chain:
        terminal = link.parent_terminated_on
        copending = terminal is None or link.child_filing_date <= terminal
        if not copending:
            # Benefit stops here: the leaf keeps only this child's own date.
            return CopendencyResult(
                is_valid=False,
                broken_link=link,
                effective_filing_date=link.child_filing_date,
            )

    return CopendencyResult(
        is_valid=True,
        broken_link=None,
        effective_filing_date=effective,
    )

Two design choices carry the compliance weight. The comparison is <=, not <, because a patent grants at the start of its issue date, so a child filed on the issue date is copending — an off-by-one that would otherwise reject valid continuations. And a broken link returns the child’s filing date of the failed link, not the root’s, because benefit cannot jump a break: everything below the break is stranded on the first surviving date. The result object names the offending link so a paralegal sees exactly where the chain failed, mirroring the break-reporting contract of the Priority Claim Chain Validation engine.

Operational Action: Re-run family copendency validation on every event that changes a link — a recorded abandonment, an issue-fee payment, a filing-date correction — and store the returned effective filing date and any named broken link on the leaf application, rather than assuming the chain is still intact from a prior run.

Frequently Asked Questions

Related

• Continuation & CIP Deadline Tracking — the family-tracking model this copendency check feeds.
• Priority Claim Chain Validation — full traversal and break detection across the priority chain.
• Core Docketing Architecture & Deadline Types — the taxonomy that classes copendency as a statutory, unrecoverable deadline.

↑ Back to Continuation & CIP Deadline Tracking