The protocol defines no new number style. It pins one canonical URN per asset and carries every office number descriptively — built on WIPO ST.3 and ST.16, with resolution treated as a first-class, disputable operation.
Every asset has exactly one canonical identifier: urn:ipproto:asset:{uuid}. It is assigned at the asset's first appearance and never reassigned, immutable for the asset's life. Office numbers change as an asset moves from application to publication to grant to national validations; the URN does not. It is opaque — it encodes no meaning and is never parsed. It is a join key: what messages, schemas, authority claims, and audit trails reference. The office numbers are how the world outside the protocol names the asset.
Each office number is an entry in the asset's identifiers[] array — a thin descriptive wrapper around an existing standard.
| Field | Carries | Leans on |
|---|---|---|
| scheme req | Which identifier system the value belongs to | URN namespace |
| officeCode opt | Issuing office / jurisdiction | WIPO ST.3 |
| value req | The number exactly as published | office-native |
| kindCode opt | Document kind (A1, B1, T3 …) | WIPO ST.16 |
| referenceType opt | application · publication · grant · internalReference | protocol enum |
| issueDate opt | When the identifier was issued | ISO 8601 |
The value is recorded verbatim — stored as the office published it. Any normalized form is a derived view an actor may compute, never a replacement. Identifiers are append-mostly: as an asset progresses, new identifiers accrue; superseded ones are flagged, never deleted, so historical references keep resolving.
A small recommended set is seeded; the field stays open to namespaced custom schemes, following the same lightweight, opt-in, not-enforced pattern as custom milestone categories: office-application, office-publication, docdb-family, internal-reference. Custom schemes use urn:ipproto:scheme:{namespace}:{name}; unknown schemes degrade gracefully to "unknown" rather than being rejected.
{
"assetUri": "urn:ipproto:asset:7c4f9a82-3e15-4d0a-9f62-...",
"assetType": "patent",
"identifiers": [
{ "scheme": "urn:ipproto:scheme:office-application",
"officeCode": "EP", "value": "21712345.6", "referenceType": "application" },
{ "scheme": "urn:ipproto:scheme:office-publication",
"officeCode": "EP", "value": "EP3987654", "kindCode": "B1", "referenceType": "grant" },
{ "scheme": "urn:ipproto:scheme:docdb-family", "value": "78451203" }
]
}The assetUri is identical regardless of which identifiers are present. The docdb-family identifier is the home for an asset's family id — assets sharing the same value are members of one family.
Cross-asset links are carried in relationships[], each referencing a related asset by its own assetUri. For v0.1, the DOCDB simple family is the canonical family backbone, anchored on the family model available through EPO OPS; national and INPADOC sources provide enrichment layered on top. This keeps v0.1 to a single consistent family model and avoids premature multi-family reconciliation.
docdb-family identifier, and may emit a neutral docdbFamilyMember relationship. It must not assign semantic relationship types it has not verified (validation, nationalPhase, divisional …) — those are claims about prosecution and require authority-bearing evidence. Promoting membership to a typed relationship is an enrichment step, recorded with its own provenance.Resolution turns observed identifiers into a canonical assetUri. It is a lookup against authoritative sources, not a number-grammar parser: observed identifiers arrive; the resolver queries authoritative sources to find the asset and its family; if the asset is already known its URN is reused, otherwise a new one is minted.
Every resolution records its confidence and method — mirroring how the protocol already treats entity identity — so a weak or automated match is visible and auditable rather than silent. It is schematized as resolutionProvenance; a resolver's full emission validates as resolvedAsset (the Asset Reference plus its provenance).
| resolvedAssetUri | The canonical asset resolved to |
| confidenceLevel | exact · high · medium · low |
| resolutionMethod | deterministicIdentifier · familyLookup · attributeMatching · humanReview · priorAssertion |
| resolutionBasis | The evidence for the match (source, matched identifiers, family id) |
The derivation rubric is implementation-defined for v0.1 with a recommended baseline (deterministicIdentifier + exact for a direct ST.3 / ST.16 hit; familyLookup for a DOCDB-family match; priorAssertion for a store hit); a canonical rubric is deferred to a governance body. Resolution is per-actor — the protocol forces no single global resolution; the provenance record is what lets divergence be detected.
When two actors independently bootstrap the same asset into two different URNs, the protocol does not quietly merge them. The divergence surfaces as an Asset Authority Dispute (or an Identity Resolution Dispute, when the disagreement is about entity rather than asset identity) and closes with a Dispute Resolution Decision that designates the canonical URN for the relevant scope and preserves the full audit trail of how two views became one. This is the protocol's posture everywhere: authority is claimed and reconciled explicitly, never assumed.
An actor or resolver conforms when it: assigns and reuses a single stable assetUri per asset, never reassigning it; records office numbers as identifiers[] entries using ST.3 office codes and ST.16 kind codes with value stored verbatim; never deletes a superseded identifier; records confidence and method on every resolution; and reconciles a divergent canonical identifier through the dispute path rather than overwriting.
Two levels are recognised. Representational conformance covers the first three points — any actor referencing assets. Resolving conformance adds the last two — any actor that performs lookup-based resolution, such as an orchestrator or a conversion service.
A reference resolver demonstrates this profile against live patent-family data — observed identifiers in, a conformant resolvedAsset out, validated against the published schemas. It routes all register access through a single rate-limited gateway and is strictly read-only with respect to source data.