Known differences

PatentRef answers the same paths, parameters, response shapes and error forms as the upstream PatentSearch API. These are the places where an answer differs, each with its reason.

Search and sorting

• Known differences from the upstream Elasticsearch service: text search tokenizes with FTS5 unicode61 (case folded, punctuation and hyphens separate tokens, accents kept, no stemming; apostrophes and dotted numbers can split differently); ties in a sort are broken by the row order of the snapshot; prefix and wildcard on analyzed text fields test tokens; _contains, a range or an empty _begins on a long-text field needs patent_id in the same _and (400 ERR_Q otherwise, the endpoints page), where upstream's Elasticsearch answered from its term dictionary. Each difference is listed in the server's change file, https://github.com/Nietzsche247/PatentSearch-API/blob/sqlite-backend/CHANGES_LAPSE.md.

Paths, limits and order

• Known differences in paths, limits and order: /api/v1/patent/otherreference/ answers as /api/v1/patent/other_reference/ does (upstream's release 2.2.0 of 2024-11-06 moved it to other_reference, and upstream's code routes only that path since; PatentRef answers both, so every path in the endpoint table of the PatentsView code examples notebook answers as written). A request body over 64,000 bytes answers 413, and q over 16 KB 400 ERR_Q (the grammar page), limits upstream did not have. The rows of a nested group come in the order of their source (the grammar page), which can differ from the order upstream's Elasticsearch returned.

Data sets not in the build in service

In data version 20261027.2 these routes answer 501 with X-Status-Reason-Code ERR_NOT_IMPLEMENTED (the list comes from /api/v1/meta/, field deferred, and changes with the build):

• publications: pre-grant publications (/api/v1/publication/, /api/v1/publication/rel_app_text/ and the pg_claim, pg_brf_sum_text, pg_detail_desc_text and pg_draw_desc_text endpoints), deferred to a later build
• cpc_classes: /api/v1/cpc_class/ (each patent's CPC classes come in its cpc_current and cpc_at_issue groups)
• cpc_subclasses: /api/v1/cpc_subclass/ (each patent's CPC subclasses come in its cpc_current and cpc_at_issue groups)
• uspc_mainclasses: /api/v1/uspc_mainclass/ (each patent's USPC main classes come in its uspc_at_issue group)
• wipo: /api/v1/wipo/ (each patent's WIPO fields come in its wipo group)

Data

• Refresh: the USPTO catalog is polled weekly; a new release is built, checked (integrity, row-count and fee-value deltas, the contract examples) and swapped in without downtime. data_version changes with every build; GET /meta/ lists the delta.
• Weekly grants: PatentsView releases lag the grants by months, so every Tuesday's grants are added from the USPTO weekly grant full text (Open Data Portal product PTGRXML) within days of issue, for the patents the PatentsView release does not cover yet. Their inventor, assignee and attorney names are as printed, with no inventor_id, assignee_id or attorney_id; what derives from those ids is null too (the links to the entity records, inventor_location_id and assignee_location_id, inventor_gender_code). They carry "disambiguated": false when f names inventors.disambiguated (assignees.disambiguated and attorneys.disambiguated alike); then every row of that group carries the field, true on PatentsView rows. A whole group (f names inventors) carries the upstream fields only, on both kinds of rows, so every row of a group has the same keys. Find them with q {"inventors.disambiguated": false}. When a PatentsView release covers those patents, its rows replace the weekly ones. GET /meta/ shows weekly_grants: the last date PatentsView covers and the last weekly issue loaded.
• Assignee names as printed: assignee_organization, assignee_individual_name_first and assignee_individual_name_last on /patent/ and /assignee/ are PatentsView's disambiguated names, one label for a whole cluster of spellings, which can differ from the name printed on a grant (US 6859933 is printed "Samsung Electronics, Co., Ltd."; its cluster label is "SAMSUNG DISPLAY CO., LTD."). The names as printed come beside them when f names them: assignees.raw_assignee_organization, assignees.raw_assignee_individual_name_first and assignees.raw_assignee_individual_name_last on /patent/ (then on every row of the group; a whole group in f carries the upstream fields only), and raw_assignee_organization, raw_assignee_individual_name_first and raw_assignee_individual_name_last on /assignee/ (the names printed on the assignee's most recent patent, the patent its other names come from). They come from PatentsView's g_assignee_not_disambiguated file and, for weekly grants, from the grant full text. They cannot be used in q or s (400 ERR_Q). They are null where the bulk data has none and in a data version built before them.
• Withdrawn patents are excluded from /patent/ by default (o.exclude_withdrawn true), as upstream; set it to false to include them.
• Nothing PatentRef returns is a legal conclusion. Expiry and fee status (the lapse group and /lapse/status/, the endpoints page) are record facts with their basis and an as-of date.

Grammar rules that refuse a request

The cost cap, the 16 KB cap on q and the long-text rule refuse some requests upstream would have run, with 400 ERR_Q; the list is on the grammar page and at /docs/errors/ERR_Q. A request body over 64,000 bytes answers 413 instead, from the web server in front of the API, with an empty body and no X-Status-Reason-Code. Every difference of the server code from upstream is listed in its change file, CHANGES_LAPSE.md.