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, requests for work, decomposition of goals into milestone chains, instruction of suppliers at an agreed price, procurement through binding bids and an award, authorization and execution of milestones across actors, handoffs to external systems, long-running monitoring subscriptions, invoices and their dispute or cancellation, 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 IP-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, the actor that recorded the message where another actor entered it on the originator's behalf (recordedBy, since 0.5), 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.5",
"originatingActor": "urn:ipproto:actor:register",
"addressedTo": [ { "actorUri": "...", "expectedRole": "..." } ],
"producedAt": "2026-01-01T00:00:00Z",
"payload": { /* type-specific */ },
"assertions": [ /* authority-bearing data assertions */ ]
}Sixteen 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), price and timing (Agreed Price, Service Level), 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.
Take a request for work or decline it, decompose the goal into a committed plan and run it to completion or abandonment.
Authorize, execute, and resolve the individual steps within a workstream.
Instruct a supplier to perform a milestone at an agreed price and under agreed service levels, and receive its answer.
Invite suppliers to bid, attest the conflict check, disclose a withheld requester, exchange binding bids and award the work. How bids are ranked stays private.
Transfer a work product between actors and acknowledge receipt.
Hand a prepared action to the party who must execute it, and confirm they did.
Issue an invoice, dispute or cancel it, 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.
Since 0.5 the specification carries a Conformance page. A profile is a list of requirements, each pointing at the page that states it; it adds no rule of its own except where a requirement says so. A claim names the version and the profile — "conforms to the orchestrator profile of IPOP 0.5" — and a conformance check records each requirement as met, partly met, not met or not applicable, with the evidence. Not applicable is open to a conditional module and to a flow the implementation does not perform at all; it is not open to a flow performed without the message the requirement names.
| Profile | Who claims it | Requirements |
|---|---|---|
| Asset identification, representational | any actor that references assets | Asset Identification & Resolution, section 6, points 1 to 3 |
| Asset identification, resolving | any actor that resolves assets by lookup | the same section, points 1 to 5 |
| Orchestrator | an actor in the role orchestrator: it answers work requests, passes the work to providers and invoices its customers | ten general requirements (G1–G10) that hold for every producer of messages; 25 core requirements on requests, workstreams and passing work on, instructions, the milestone lifecycle, deliverables, invoices and the journal (OR-R, OR-W, OR-I, OR-L, OR-D, OR-V, OR-J); conditional modules for procurement, payments, subscriptions and assets |