Every patent document in an on-site instance of CLAIMS Direct carries two identifiers: a UCID (Unique Document Identifier) and a publication_id. They are not interchangeable — they serve different purposes and operate at different levels of the system. This blog explains what each identifier is, why the schema needs both, and how they work together to make it efficient to store, retrieve, and deliver patent data across a multi-table schema. 

The combination of country code, document number, and kind code is commonly used across the patent industry to designate a single, specific patent document. In CLAIMS Direct, we use these components to create a UCID (Unique Document Identifier) for each document.

A UCID encodes its underlying identity: which patent authority issued it, what number that authority assigned to it, and what kind of document it is (an application, a granted patent, etc.). Two documents that are related — for example, an application and the patent that is granted from it — will have different UCIDs, because a UCID identifies a specific published document, not a patent family or invention.

A UCID is alphanumeric and is built from three components, concatenated in a fixed order:

1. Country / authority code: a two-letter code identifying the issuing patent office (e.g., US, EP, WO, JP).

2. Document / publication number: the number assigned by that authority to the document, sometimes including leading zeros or check digits depending on the authority's numbering convention.

3. Kind code: a short alphanumeric suffix identifying the document type and status within that authority's system (e.g., A1 for a published application, B2 for a granted patent).

Because it is composed this way, the UCID is self-describing: an analyst or client can look at the string and immediately understand jurisdiction, number, and document type without querying anything else. That readability is exactly what makes it the right identifier for external use. It is also part of why it is not the right identifier for internal table relationships.

PostgreSQL, like other relational database systems, connects tables using keys rather than repeating full descriptive data in every table. The general pattern is:

• A primary key uniquely identifies each row in a given table.

• A foreign key in another table stores that same value, creating a pointer back to a specific row in the primary table.

• A join (e.g., INNER JOIN, LEFT JOIN) matches rows across tables where the key values are equal, letting the database assemble a complete picture from many smaller tables.

This design avoids duplicating the same descriptive information in every table needed to reference a document. Instead, each table stores only the data relevant to its own section or purpose, plus the key needed to tie it back to the parent document.

The UCID is the right identifier for humans and for external systems, but it is a poor choice as the internal join key across a large multi-table schema, for several reasons:

• Data type and size: A UCID is a variable-length alphanumeric string. String comparisons and joins are inherently slower than numeric evaluations, and string indexes typically consume more disk space than numeric ones.

• Format variation: UCID formatting conventions differ somewhat by issuing authority and can include punctuation, leading zeros, or kind-code variants. That variability makes exact-match joins more fragile than joining on a key the schema fully controls.

• Scale across multiple tables: The schema spans multiple tables covering every section of a patent document (bibliographic data, claims, description, drawings, citations, legal status, and more). Repeating a long alphanumeric string as the join column in every one of those tables multiplies both storage footprint and join cost.

For these reasons, the schema generates its own internal key — the publication_id — and uses it to connect all of the tables, while retaining the UCID as the master, human-facing identifier stored alongside it.

The publication_id is a numeric identifier generated internally and used as the join key across every table in the schema. Each table that stores data about a specific document carries the publication_id as its foreign key back to the primary table.

The two identifiers are not competitors — they serve different purposes. The UCID is preserved as the authoritative business identifier; the publication_id is the mechanical key that makes it efficient to assemble a full document, or any part of it, out of all the underlying tables.

Advantages of having a numeric publication_id include:

• Join performance: Numeric indexes (e.g., B-tree on an integer or bigint column) are smaller and faster to traverse than indexes on variable-length text.

• Storage efficiency: A numeric ID occupies a fixed, small number of bytes (4 bytes for integer, 8 for bigint), versus a variable-length string repeated across multiple tables.

• Stability: The value is generated once, internally, and will never change within a local instance, even if external UCID formatting conventions evolve.

• Simplicity for sequencing: Numeric IDs work naturally with auto-incrementing sequences, making it trivial to generate the next unique value when a new document is introduced.

• Decoupling: Application logic and the other schema tables never need to parse or validate UCID formatting just to relate data; they only need to carry an integer.

 Step-by-step flow:

1. A new UCID is introduced to the system — a new patent document becomes available for the first time.

2. A new publication_id is generated internally for that UCID. The pair (UCID, publication_id) is written to xml.t_patent_document_values as the master record for the document.

3. The publication_id is written to every table that receives content for that document — bibliographic data, claims, description, etc. — as each section's data is loaded.

4. For any subsequent addition or update to a document (for example, an added citation, a legal-status change), the system looks up the publication_id for the existing UCID in xml.t_patent_document_values, and uses that UCID’s publication_id to write the new data into the appropriate secondary tables. 

5. When the complete document needs to be reassembled — for display, export, or delivery — the system joins all of the tables on publication_id to pull every section back together into one coherent XML document.

This design is what makes it possible to connect a client's external portfolio records to IFI's internal data without ever exposing the client to publication_id at all.

1. A client manages a patent portfolio and tracks each document in that portfolio by its UCID.

2. IFI periodically provides the client with updated information about the documents in that portfolio (new legal-status events, citation updates, etc.).

3. Independently, every document available in CLAIMS Direct is also identified by its UCID.

4. Because both the client's portfolio list and CLAIMS Direct's holdings are keyed to UCID, the two can be matched directly on that shared identifier: for each UCID in the client's portfolio, the corresponding document in CLAIMS Direct is located and the update is delivered.

Internally, once a matched document is located, IFI's own systems resolve that UCID to its publication_id via xml.t_patent_document_values, and use the publication_id to pull the full set of related data across all tables. The client never needs to know that publication_id exists — it is purely an internal optimization that sits behind the UCID they use to manage their portfolio. 

In short: UCID is the shared language between the client, CLAIMS Direct, and the outside world. Publication_id is the internal mechanism that makes serving that shared language fast and efficient across a multi-table schema.