How a Welqin Transaction Works

Every filing instruction, office action, status update, or invoice exchanged between IP professionals carries the same kind of information — who it's from, who it's for, what IP right it concerns, what's being asked or reported, and often a document to go with it. Today, that information travels as free text in an email, or as a PDF nobody's system can read automatically. Welqin replaces that with something both sides' systems can understand without a human retyping it in the middle.

One standard, not one company's format

Welqin isn't a proprietary format invented to lock in its users. It's built on AFNOR NF X50-276, a data exchange standard developed over five years by a community of IP professionals — private-practice firms, corporate IP departments, service providers, IPMS vendors, and patent offices — under the aegis of AFNOR, the French national standards body. First published in 2018 and updated in 2025, it's the only standard purpose-built to describe IP-related transactions in a structured, unambiguous way.

Welqin operates the network built on top of that standard. The distinction matters: adopting Welqin doesn't mean adopting Welqin's format — it means adopting an open, community-governed standard that Welqin happens to make usable today, through a network already connecting IP firms, corporates, and offices.

This is the same shift SWIFT brought to banking: before SWIFT, banks exchanged payment instructions by telex, each in their own shorthand, reconciled by hand. SWIFT didn't move money — it gave every bank a shared language to describe a transaction, so the systems on both ends could talk directly. Welqin is that shared language for IP.

What travels in a transaction

Welqin calls a single transaction a Flow. Whatever it's about — a filing instruction, a deadline report, an invoice — a Flow is built from the same small set of building blocks, so that receiving software only ever has to understand one shape of message, not one per sender:

The five building blocks of a Flow: sender and receiver, IP right, action, financials, and documents

Because every Flow is built from the same pieces, a firm's IPMS — or Welqin's own portal, for firms not ready to integrate directly — only needs to learn this shape once to handle every kind of transaction that comes through the network.

From one system to another

Emission
POST
Storage
GET
Validation
Response
Step 1 / 6

Emission from the source IPMS

The emitting IP firm drafts a transaction (letter, instruction, invoice) directly in its IPMS. A structured XML or JSON file is generated automatically, compliant with the Welqin standard (NF X50-276 / WIPO ST.96–97).

No manual entry. No PDF conversion.
The standard covers all IP transactions: invoices, filings, office actions, annuities, assignments…
1 / 6
IPMS Emitter
IP firm · source
Welqin
Secure Platform
Encrypted · Timestamped · XML · JSON · REST API · NF X50-276
IPMS Receiver
IP firm · target

A Flow's journey is tracked from submission to delivery, so both sides always know where a transaction stands — submitted, in progress, delivered, or returned for correction — without a status-check email. If something's wrong with a transaction, the receiving agent returns it with a reason instead of it silently sitting in an inbox; the sender corrects it and resubmits, and the exchange continues on the same thread.

Connecting to the network doesn't require replacing anything. Firms and corporates connect their existing IPMS through a simple import/export, a direct API integration, or by using Welqin's own portal while they evaluate the shift — all three interoperate on the same network, at each side's own pace.

A concrete example: sending an invoice

Take something every firm does constantly — billing a client or a foreign associate for work done. As a Flow, that invoice carries:

  • the sending and receiving agents, and which one is the recipient of this particular invoice;
  • the invoice itself — its reference number, issue date, currency, and the full legal identity of who's billing whom (name, address, tax and registration numbers) — attached directly to the invoice so it's self-contained, not looked up separately;
  • the individual billing lines behind it — professional fees, official fees paid to a patent or trademark office, expenses — each tagged with what procedural task it relates to and how it should be categorized, so a billing system can post it to the right account without a person deciding that manually;
  • the invoice PDF itself, attached to the transaction (not emailed separately, and not a link that can go stale).

Everything totals up automatically checkable at the receiving end, in a single declared currency, with no ambiguity about what a given line means or where it should land. What used to be a PDF attached to an email, manually re-entered by someone on the receiving end, arrives instead as data the receiving system can post directly.

Why this compounds

A single connection is useful. What makes the network valuable is that it's the same connection for every counterpart. A firm that connects once can exchange structured Flows with every other agent already on Welqin — other firms, corporate IP departments, service providers, and, over time, patent and trademark offices — without negotiating a bespoke integration for each one. The more of the IP world that's connected, the less anyone has to re-key.

A more detailed, developer-facing description of the Flow structure and a full worked example are available in our technical documentation.

Book a demo