Lapse fields

PatentRef's additions to the grammar: the expiry and maintenance-fee facts of each patent, from the USPTO record, with their basis and an as-of date. Nothing here is a legal conclusion.

The lapse group

Name lapse or lapse.<field> in f on /api/v1/patent/ or /api/v1/patent/{patent_id}/. It is never in the default fields, and q or s on it answers 400 ERR_Q.

curl -s -G -H "X-Api-Key: $KEY" https://patentref.io/api/v1/patent/ \
  --data-urlencode 'q={"_text_phrase": {"patent_title": "solid state battery"}}' \
  --data-urlencode 'f=["patent_id", "patent_title", "lapse.expiry_status", "lapse.expiry_date_estimated", "lapse.lapse_date"]'

Routes and rules

• The lapse group on /patent/ and /patent/{patent_id}/: add "lapse" (or "lapse.<field>") to f. One object in a list, like every nested group: expiry_status (active, expired_term, expired_fee_nonpayment, withdrawn, unknown), expiry_date_estimated (the statutory term end, computed under 35 USC 154 from the filing or earliest parent filing date, the grant date, the patent term adjustment and a dated terminal disclaimer, or for a patent on the USPTO 35 USC 156 list the list's original expiration date plus its extension; it is not a date the USPTO record prints, and it is null when the record and the list disagree on whether the term has passed, or when the record contradicts the filing date of a parent the term could count from and PatentRef holds no other USPTO record that gives it), expiry_basis (codes: term_20y, term_17y, term_14y, term_15y, terminal_disclaimer, pta_days:N, fee_lapse:YYYY-MM-DD, reinstated:YYYY-MM-DD, pte_156:N), reinstatement_possible (true, false or "unknown", under 37 CFR 1.378), fee_status ("lapsed" or null), lapse_date (the date of the maintenance-fee record's expiry entry), reinstated_date, prior and prior_pct (the Lapse history-match score and its percentile; null until computed on the server), fwd_early (forward citations within 10 years of grant, by US utility patents in PatentsView and in the weekly grants after it), fwd_late (15 or more years after), sleeper_flag (expired and quiet), as_of, data_version. The group is never in the default fields, and q or s on it answers 400 ERR_Q (on q the reason is "the 'lapse' group is returned with f only"); its fields are of kind f-only in the OpenAPI file.
• The term rule behind expiry_date_estimated: utility and plant patents filed on or after 1995-06-08 run 20 years from filing, or from the filing of the earliest parent application the record lists (continuation, division or continuation-in-part, including a parent international application the record lists as a related publication; never a provisional or a foreign priority), plus the patent term adjustment (pta_days:N); where the record lists no parent rows (older grants often have none, for example US 5000000), the date counts from the patent's own filing. A parent's filing date that the record itself contradicts is not used: an international application dated outside the year its number names (PCT/CCYYYY/; PCT/CCYY/ names its year up to 2003, and a later number written that way is read as 20YY when the row's date falls in that year; a number written without one or both slashes, such as PCTGB9300583, is read as PCT/GB93/00583) or before 1978-06-01, or whose number names no possible filing year (including a later PCT/CCYY/ number dated outside 20YY), or a US application dated outside the years in which applications of its serial number's series were filed; PatentRef also does not use a US parent date before 1950. The filing date another USPTO record PatentRef holds gives for the same application counts instead (another row of the same record, the international filing date in the record of its national stage, or the filing date in the record of the patent granted on it): US 9527819 counts from its parent PCT/US2005/039541, filed 2005-11-02 by the record of its national stage, not from the 2008-07-22 its own row gives. When none does and that parent could be the earliest, expiry_date_estimated is null, and expiry_status is the status the record's dates give on the date the row gives, when that date is a possible filing date, and on every filing date the parent's number allows (the year or the series years it names; any day from 1978-06-01 when it names no possible year or a serial number its office never reached in that year; never after the patent's own filing); when those give different statuses, expiry_status is unknown. Filed before 1995-06-08: 17 years from grant when that ends before 1995-06-08 or after the 20-year date, else 20 years from filing; expiry_basis names term_17y or term_20y, whichever applied (US 5000000, filed 1989, granted 1991: 20 years from filing, 2009-05-15, is later than 17 years from grant, so term_20y). Design patents: 14 years from grant, 15 when filed on or after 2015-05-13. A dated terminal disclaimer ends the term at its date. A national stage under 35 USC 371 counts from its international filing date (35 USC 363). A patent or reissue on the USPTO list of patent terms extended under 35 USC 156 (retrieved 2026-10-11, updated through 2026-09-08) takes the list's original expiration date plus the extension the list gives (expiry_basis pte_156:N). An extension only adds to the original term (35 USC 156(a)), so where the list's date is earlier than the term computed from the record and the record shows no terminal disclaimer, the two disagree: if only one of the dates has passed, expiry_date_estimated is null and expiry_status is unknown, or expired_fee_nonpayment when the fee record shows an unreinstated lapse whose grace period ran out before the later date. Not counted: a terminal disclaimer without a date (one that ties the term to another patent), an extension the list does not name (an interim extension, or one granted after the list's update date), and a change to the adjustment after grant. No estimate for a patent withdrawn from issue or for a reissue not on the list. A maintenance-fee lapse whose 6-month grace period ran out after the computed term end (the later of the two where the list and the record disagree) gives expiry_status expired_term, not expired_fee_nonpayment, and expiry_basis keeps fee_lapse:YYYY-MM-DD.
• GET /lapse/status/{patent_id}/ (alias /status/{patent_id}/): one verdict record, {"patent_id", "status", "basis", "reinstatement_possible", "reinstatement_basis", "expiry_date_estimated", "lapse_date", "reinstated_date", "as_of", "data_version", "catalog_data_version", "permalink", "plain", "next_steps"}. patent_id as PatentsView prints it (10000000, D872010, RE31177; no US prefix). permalink is https://patentref.io/p/<patent_id>?v=<data_version>; plain is one sentence for a person, built from the record facts, with as_of and the data version. The USPTO record prints dates and events, not a term end, so plain keeps the two apart: for active and expired_term it gives the term end computed from the dates in the record and says whether that date has passed or not yet ("As of 2026-10-06, the term end computed from the dates in the USPTO record for US 5000000 is 2009-05-15 (20 years from filing), a date that has passed, and the USPTO list of patent terms extended under 35 USC 156, updated through 2026-09-08, does not name this patent (data version 20261006.5)."); expired_term also says that the USPTO 35 USC 156 list does not name the patent, or names its reissue; for expired_fee_nonpayment it gives the date of the maintenance-fee record's expiry entry and says no reinstatement follows it; withdrawn says the record shows the patent as withdrawn from issue; unknown says the record does not settle the status because no term end can be computed from its dates, or, where the record gives a parent application a filing date it contradicts and PatentRef holds no other USPTO record that gives that application's filing date, names the application, the date and why the date does not fit its number. When the date the record gives (where it is a possible filing date) and every filing date the application's number allows give the same status, the active, expired_term and expired_fee_nonpayment sentences name the application, the date and why it does not fit, and say on which of those dates the status holds. For a patent on that list, active and expired_term give the list's original expiration date and extension and the term end they add up to, plus the record's own term end when that is later; when only one of the two has passed, the status is unknown and plain gives both, unless the fee record shows an unreinstated lapse whose grace period ran out before the later date: then the status is expired_fee_nonpayment with its sentence. next_steps lists links for a person and for an agent. reinstatement_basis names the rule behind reinstatement_possible: 37 CFR 1.378 for a maintenance-fee lapse, 35 USC 154 when the term has ended ("35 USC 154: term ended"; "35 USC 154: term ended (the lapse predates the term end)" for a fee lapse whose computed term end has since passed; "35 USC 154: term ended (the term ended before the fee lapse)" when the grace period of the unpaid fee ran out after the computed term end). The record has no "error" member, unlike the list and detail answers; branch on the status code. ?v=<data_version>: a superseded version adds a "superseded" object (never a 404). Errors: a malformed id is 400 ERR_Q; an unknown patent is 404 {"detail": "Not found."} with no code header, as the detail routes; a version that never existed is 404 {"error": true} with X-Status-Reason-Code NOT_FOUND.
• GET /lapse/similar?text=<free text>&n=<1 to 20, default 20>: the nearest patents by title and abstract, {"error", "data_version", "as_of", "method", "n", "terms", "neighbors": [{"rank", "patent_id", "patent_title", "patent_date", "score"}]}. FTS5 bm25 over the rarest input tokens (listed in terms). Usually under 2 s; the first queries after a data swap can take 10 s. The only path without a trailing slash; /lapse/similar/ answers too.
• GET /lapse/similar?text=<free text>&n=<1 to 20>&mode=structured (experimental): the patents whose claims introduce the most of the text's term keys, {"error", "data_version", "text_data_version", "as_of", "method": "claim_term_keys", "mode": "structured", "structure_version", "generator", "n", "terms", "term_keys": [{"key", "weight"}], "key_phrases", "candidates": {"title_abstract", "key_phrases", "with_claim_text"}, "neighbors": [{"rank", "patent_id", "patent_title", "patent_date", "score", "shared_terms": [{"key", "match", "claim_key", "claim", "text", "start", "end"}]}]}. The keys are the noun phrases the claim tree's term finder reads in the text, as a claim tree's term key (lower case, the last word singular), weighed by ln(N / df) of their rarest word in titles and abstracts; keys whose rarest word is in more than 2 percent of patents are dropped unless fewer than 3 are left, at most 12 are kept (term_keys). Candidates come from the title and abstract index: the text mode's own query (terms) and the keys as phrases (key_phrases), 40 each. Each candidate's claims are parsed when asked for by the claim tree's parser (no language model, nothing stored); only the terms the claims introduce count. score is the weighed share of the text's keys found: 1 for the same key, half when one key ends with the other as whole words ("drive motor" and "electric drive motor"), so 1 means every key found; ties by the number of keys found the same, then patent_id. A patent with no key found, without claim text, or over the claim tree's work cap is left out, so neighbors can be fewer than n or empty. shared_terms says where each key is: match exact or partial, claim_key the claim's own key, claim the claim's number (the first independent claim that introduces it, else the first claim), and text, start and end in that claim's text, the offsets GET /structure/claims/{patent_id}/ serves. The answer carries X-Text-Data-Version. A score describes shared wording in the published text and nothing more. Experimental: the ranking is weakest where the shared terms are common short claim words, where near-identical patents tie, and where a text yields fewer than 3 term keys, as many chemistry abstracts do. Errors: a mode other than text or structured is 400 ERR_Q; with no long-text file in service mode=structured answers 501 ERR_NOT_IMPLEMENTED. Without mode, or with mode=text, the answer is the one above, unchanged.
• https://patentref.io/p/<patent_id>?v=<data_version>: the record page for a person (HTML, no key). When the data in service carries the patent family tables, the page also lists the patent's family outside the US: the publications outside the US that Google Patents Public Datasets puts in the same family (office, number, kind, publication date; the first 200), with the credit line "Family data from Google Patents Public Datasets, used under CC BY 4.0." and a link to the patent's family on USPTO Global Dossier. The legal status of those publications is not shown.

Nearest patents by claim terms (experimental)

Add mode=structured to /api/v1/lapse/similar to rank patents by the claim terms they share with your text instead of by title and abstract words. It answers the patents whose claims introduce the most of the text's term keys. The keys are the noun phrases the claim tree's term finder reads in the text (lower case, the last word singular, as a claim tree's term key), weighed by how rare their rarest word is in titles and abstracts (keys in more than 2 percent of patents dropped unless fewer than 3 are left; at most 12). Candidates come from the title and abstract index: the text mode's own query and the keys as phrases, 40 each. Each candidate's claims are parsed when asked for, by the claim tree's parser (no language model, nothing stored). score is the weighed share of the text's keys found among the terms the patent's claims introduce: 1 for the same key, half for a key that ends with the other as whole words (drive motor and electric drive motor); 1 means every key found. A patent with none, without claim text, or over the claim tree's work cap is left out. Ties by the number of keys found the same, then by patent_id. shared_terms says where the claim text has each one: the claim's number and the mention's start and end in that claim's text, the offsets of GET /api/v1/structure/claims/{patent_id}/. A score describes shared wording in the published text and nothing more.

This mode is experimental: the ranking is weakest where the shared terms are common short claim words, where near-identical patents tie, and where a text yields fewer than 3 term keys, as many chemistry abstracts do.

curl -s -G -H "X-Api-Key: $KEY" --data-urlencode "text=A pool cleaner with a drive motor and a filter bag" -d n=5 -d mode=structured https://patentref.io/api/v1/lapse/similar

Without mode, or with mode=text, the answer is the title and abstract one above, unchanged. To read a shared term in its claim, ask for the claim tree, Claim trees, and slice that claim's text with start and end.