What the protocol covers, the envelope every message shares, and the full catalogue of message types. The complete normative text lives in the repository; this page is the map.
The protocol standardizes the data exchange between actors performing operational work on patent and other IP assets: the messages flowing between corporate IP departments, service providers, external counsel, and registers when work is being done on assets that exist in the world. It covers asset bootstrapping, decomposition of goals into milestone chains, authorization and execution of milestones across actors, handoffs to external systems, long-running monitoring subscriptions, payment authorization and execution, register events carrying legal-status changes, authority assertions over record sections, and dispute mechanics for conflicts that cannot be auto-resolved.
It is transport-agnostic and constrains no implementation language or platform. A single scoping principle governs every decision: the protocol standardizes the patent-operations data layer and nothing else.
The protocol does not replace, extend, or compete with existing WIPO standards. ST.3, ST.6/ST.13/ST.16, ST.27, ST.37, ST.96 and ePCT address what is in patent records, how documents are structured, and how offices communicate with applicants. This protocol addresses the multi-actor operational layer above the asset model — a layer those standards do not cover. It consumes WIPO-conformant data, produces events aligned with WIPO categorizations (notably ST.27 legal-status events), and references WIPO-governed structures — ST.3 office codes and ST.16 kind codes — wherever operationally feasible.
Each message is a typed payload wrapped in a shared envelope. The envelope carries a stable message URI, the message type, the protocol version (for graceful degradation across versions), the originating actor and role declaration, the addressees, a production timestamp, and — where the message changes a record — an array of authority-bearing data assertions. Schemas leave unknown fields open by design, so a newer sender never breaks an older receiver.
{
"messageUri": "urn:ipproto:message:...",
"messageType": "urn:ipproto:message:registerEvent",
"protocolVersion": "0.1",
"originatingActor": "urn:ipproto:actor:register",
"addressedTo": [ { "actorUri": "...", "expectedRole": "..." } ],
"producedAt": "2026-01-01T00:00:00Z",
"payload": { /* type-specific */ },
"assertions": [ /* authority-bearing data assertions */ ]
}Fourteen structures underpin the messages: the asset and entity model (Asset Reference, Entity Reference, Document Reference), the actor model (Actor Reference, Actor Role Declaration, User Context), the authority model (Authority Claim, Data Assertion), the workstream model (Workstream, Milestone), common sub-structures (Outcome Details, Evidence Collection), and — for resolution — the Resolution Provenance and Resolved Asset structures defined by the profile.
The asset and identity model is detailed in its own normative profile. Read the Asset Identification & Resolution profile →
Bring an asset into the protocol and validate it against another actor's authoritative record.
Decompose an operational goal into a committed plan and run it to completion or abandonment.
Authorize, execute, and resolve the individual steps within a workstream.
Transfer a work product between actors and acknowledge receipt.
Hand a prepared action to the party who must execute it, and confirm they did.
Authorize a payment and confirm its execution with banking-system evidence.
Enroll and terminate long-running monitoring services — renewals, opposition watch, portfolio monitoring.
What registers publish and what subscriptions produce — the two carry different authority.
Surface conflicts that cannot be auto-resolved and close them with a recorded decision.
A lightweight envelope for data-only updates that fit no operational message.