Extracting Claims and Priority Dates From a Patent Document

Claim 7 of a patent reads, in full, “The apparatus of claim 3, wherein the housing is anodised aluminium.” Extracted as a standalone string it means nothing. Its content is the number 3.

Where the claims start and stop

The claims are the operative part of a patent — the description and drawings support them, but the claims define what is protected. They begin at a fixed transitional heading, which is one of a small set of formulas: “What is claimed is:”, “We claim:”, “I claim:”, “The invention claimed is:”, or in European and PCT documents simply “Claims”. They run to the end of the document text. Anchoring on that heading is more reliable than anchoring on the numbering, because the specification above it is also full of numbers — reference numerals for drawing elements, section numbers, and cited paragraph numbers.

Each claim is, by convention, a single sentence: it starts with a number and a full stop and ends with a full stop, with internal punctuation carrying the structure. That convention is what lets a splitter work at all, but it is also fragile in exactly one place. Claims contain decimal numbers, chemical names with numerals and citations, so a splitter keyed on “digit followed by a full stop” will cut a claim in half at “0.5 mm”. Key on a number at the start of a line, in sequence with the previous claim number, instead.

Claims are a tree, numbered by hand

An independent claim stands alone. A dependent claim refers to a previous claim and incorporates everything in it, adding a limitation. The reference is by number and is written in stereotyped language: “The method of claim 1, further comprising…”, “The apparatus according to claim 4, wherein…”.

Because the incorporation is total, the meaning of any dependent claim is the union of itself and every claim up its chain to an independent root. Store the edges:

[
  { "number": 1,  "type": "independent", "depends_on": [],     "text": "An apparatus comprising ..." },
  { "number": 3,  "type": "dependent",   "depends_on": [1],    "text": "The apparatus of claim 1, wherein ..." },
  { "number": 7,  "type": "dependent",   "depends_on": [3],    "text": "The apparatus of claim 3, wherein ..." },
  { "number": 12, "type": "dependent",   "depends_on": [1, 3], "multiple_dependent": true,
    "text": "The apparatus of any one of claims 1 or 3, further comprising ..." }
]

Claim 12 there is a multiple dependent claim: it refers to more than one preceding claim in the alternative. These are routine in European and PCT practice and permitted but comparatively rare in granted United States patents, where the rules in 37 CFR 1.75 require the alternative form, forbid a multiple dependent claim from serving as a basis for another multiple dependent claim, and cause such a claim to be counted as several claims for fee purposes. The statutory basis sits in 35 U.S.C. 112. The practical consequence for extraction is that depends_on must be an array, and the alternative-versus-cumulative distinction must be recorded, because “any one of claims 1 to 5” is five separate embodiments and not one claim depending on five things at once.

Range language is its own parsing job: “any one of claims 1 to 5”, “claims 1-5”, “claim 1 or 2”, “any preceding claim”. The last is common in European drafting and expands to every lower-numbered claim, which means the expansion is only correct if you have parsed the whole claim set first.

Validating the dependency graph

Unlike most extracted structures, this one is checkable without a human, and the checks catch real OCR damage.

• Numbering is dense and ascending. Claims run 1, 2, 3… with no gaps. A gap means a claim was lost at a column or page break; a repeat means two documents were merged. Cancelled claims in a published application are printed as “(canceled)” rather than omitted, which preserves the density.
• Every reference resolves. A dependency on a claim number that does not exist is a misread digit — 8 for 3 is the classic — not a real feature of the document.
• Every reference points backwards. A claim in dependent form refers to a preceding claim, so a dependency on an equal or higher number is an error by construction and the graph is acyclic by the same rule.
• At least one independent claim exists. A claim set in which everything depends on something else has lost claim 1.

These are arithmetic checks over the extraction, and they are worth more than a model’s own confidence score because they test the thing you care about rather than the model’s feeling about it. Where a check fails, the failure localises: it names the claim number and therefore the region of the page to re-read.

The transitional phrase is load bearing

A claim has three parts: a preamble, a transitional phrase and a body. The transitional phrase is a term of art and the words are not interchangeable. “Comprising” is open — the claim covers something with the listed elements and possibly more. “Consisting of” is closed — the listed elements and no others. “Consisting essentially of” sits between them. Substituting one for another changes the scope of the claim.

The extraction consequence is blunt: do not let anything paraphrase, summarise or clean up claim text. Claims should be stored verbatim, whitespace-normalised at most, with any model-generated summary kept in a clearly separate field — one of the cases where a nested rather than flattened schema earns its complexity. This is the same argument as for a deed’s legal description in extracting the legal description, and for the same reason: the text is the instrument. If a downstream product wants a readable rendering of claim 7 with its parents resolved, generate that as a derived view labelled as derived, and keep the original beneath it.

Priority is a chain, not a date

The most common modelling error on a patent is a single field called priority_date. A patent document carries several dates that are all real and all different: the filing date of the application that became this patent, the issue or publication date, the filing dates of any earlier applications it claims benefit from — provisionals, parents of a continuation or divisional, a continuation-in-part — and the filing dates of any foreign applications whose priority is claimed under the Paris Convention, which allows a later filing in another country to claim the earlier filing’s date within a set period.

Those dates appear in a structured block on the front page, keyed by the numbers described in extracting inventor and assignee information, and restated in a “Cross-Reference to Related Applications” paragraph at the top of the specification. The two should agree; where they do not, the front-page data is the office’s own record.

The deeper reason not to collapse them is that an effective priority date is determined per claim, not per document. A continuation-in-part adds new matter to a parent application, and subject matter that was not disclosed in the parent cannot claim the parent’s date; so within one patent, some claims may be entitled to an earlier date than others. Which claims those are is a legal determination made on the disclosure, not something visible on the printed page and certainly not something an extraction should assert. Store the chain — application numbers, relationship types, dates — and let the question “what is the priority date of claim 7” be asked of a person with the file history in front of them.