Open standard · v0.1 · independent maintainer · CC-BY-4.0 / Apache-2.0

A standard for the
IP operational layer.

The messages that flow between corporate IP departments, service providers, external counsel, and registers when work is being done on patent and other IP assets — formalized, validated, and transport-agnostic.


The gap it closes

Complementary to WIPO — not competing with it

WIPO standards describe what is in patent records, how documents are structured, and how offices communicate with applicants — ST.3 office codes, ST.16 document kinds, ST.27 legal-status events, ST.96 representation. They do not address the multi-actor operational layer above the asset model: the messages exchanged between actors about the work itself.

The IP Operations Protocol standardizes exactly that layer, and nothing else. It consumes data conformant to WIPO standards, produces events that align with WIPO categorizations, and references WIPO-governed structures wherever doing so is operationally feasible.

LayerStandard
Document contentWIPO ST.96, office schemas
Bibliographic dataWIPO ST.96 — aligned, via this protocol's Asset Reference
Legal-status eventsWIPO ST.27 — aligned, via this protocol's Register Event
Operational messages between actorsThis protocol — the gap WIPO does not address

The shape of it

One envelope, 26 messages, 14 structures

Every exchange is a message: a common envelope — addressing, provenance, authority assertions — wrapping a typed payload. Messages cover the full operational arc: bootstrapping assets from registers and IP-management systems, decomposing goals into milestone chains, authorizing and executing work across actors, handing off prepared actions, running long-lived monitoring subscriptions, authorizing and confirming payments, carrying register events, and resolving disputes that can't be auto-settled.

Foundational

Asset & identity

One canonical asset URN; descriptive office identifiers on ST.3 / ST.16; per-actor entity resolution.

Foundational

Authority model

Every change is an authority claim plus a data assertion — provenance and permission are explicit, never assumed.

Lifecycle

Workstreams & milestones

Goals decompose into milestone chains, authorized and executed across multiple actors with confirmation windows.

Resilience

Disputes, not merges

Conflicting claims and missing register confirmations surface as explicit disputes and close with a recorded decision.


Built to be adopted

A published spec, a validated contract, a live reference implementation

The protocol ships as more than prose. The complete message surface is defined in JSON Schema (draft 2020-12) as the @ipproto/schemas package, with generated TypeScript types and a reference validator. A normative profile defines how assets are identified and resolved. And a reference resolver demonstrates the identity model against live patent-family data.

spec published 42 schemas validated profile ratified reference resolver live v0.1 — pre-1.0, reopenable
Discoverability

The canonical specification lives in its public repository; the versioned schemas are served as a machine-readable package. Schema identities are host-independent URNs (urn:ipproto:schema:0.1:<name>), so the contract is stable regardless of where it's hosted.


Where it's heading

From a maintainer to a consortium

v0.1 is published by a single independent maintainer under open licenses, so adoption can grow without gatekeeping. That is a deliberate posture: an independent, openly licensed specification with clear authorship and a dated publication record is neutral prior art that closes an operational gap and advances no single vendor's schema. As implementers adopt the protocol, governance is intended to broaden into a consortium — preferably anchored by corporate IP stakeholders. No consortium exists today; this describes the intended path.