EPO OPS API: Patent Data, Access, and Research Applications

Patent data available through EPO OPS

The EPO identifies bibliographic, worldwide legal-event, full-text, and image databases as OPS data sources. These are also sources for Espacenet and the European Patent Register. Programmatic access lets an application retrieve and process the relevant data within its own workflow.

The OPS reference guide describes services for published data, patent families, legal information, and other supported resources. The published-data full-text inquiry reports the availability of claims and description text; retrieving that text requires the corresponding claims or description operation. A search result alone does not establish that those components are available.

Match the resource to the feature:

• Search list: publication identifiers and bibliographic information.
• Technical review: available claims or description text.
• Family review: related applications, with the family definition retained.

Access requirements and response formats

To connect an application, follow the EPO's OPS access instructions:

1. Register for OPS and obtain application credentials.
2. Configure OAuth authentication using the official documentation.
3. Request the required resource and inspect its XML response.
4. Review usage conditions against expected data consumption before scaling.

The XML interface affects how returned records are processed. A JSON-based application may need a transformation step that preserves identifiers, repeated fields, and the relationship between a value and its source record. Images or document resources may require handling separate from the bibliographic response.

Test the integration against the types of record it will actually use. Include responses with missing content and unsuccessful requests, as well as successful retrievals. A user should be able to distinguish “the source has no available text for this request” from “the request failed.”

Patent identifiers and family information

OPS requests distinguish document identifiers and supported number formats. The reference guide explains formats such as DOCDB and epodoc. Keep the identifier components needed by the selected operation, including the country code and document kind where required, rather than reducing every reference to an unqualified number.

Family definitions also matter. The EPO distinguishes DOCDB simple families and INPADOC extended families, which group applications differently through priority relationships. An application should retain the definition associated with the family data it uses.

For a research shortlist, grouping related records can make the results easier to navigate. For document review, retain the individual publication identifiers so the researcher can inspect the text of each relevant member. A family label should not obscure which document supplied a passage or recorded event.

Define the result your application should retain

These are suggested application outputs. Validate the selected operations with a known document before building the corresponding feature.

Applications in patent research workflows

An OPS integration can support an application that enriches a list of patent identifiers, retrieves material for document review, or organizes related records. The output should reflect the question being investigated rather than reproduce every available field.

For example, a researcher reviewing a technical mechanism may need a publication record, the relevant description or claims, and related documents selected for further reading. An AI assistant can organize that retrieved material into a review note containing the mechanism, supporting passages, and unresolved questions. The note should identify which documents were inspected.

The API handles access to patent records. The surrounding application must select the documents and passages supplied to the assistant and retain their identifiers in the resulting analysis.

Extending an OPS application with Patsnap

An OPS integration may begin with a known patent number and a request for its record or disclosure. The research question can then expand: Which other patents describe this mechanism, and what published research helps assess it? That calls for a discovery and evidence-review feature alongside record retrieval.

Patsnap provides a database and API layer for building that extension. Its patent-search catalog includes query, similar-patent, and semantic search operations. Its Literature Search API supports searches by publication title, abstract, author, and other documented fields.

Why consider Patsnap for this workflow?

• More ways to start a patent investigation. Select a similar-patent operation when a known document is the starting point, or examine semantic search when the input is a technical description. Check the chosen operation's input and result fields.
• Patent and literature evidence in the same application. A patent disclosure can identify a technical approach; a publication may provide experimental context. Patsnap offers both data categories, allowing your application to assemble an evidence view around the research question.
• A documented developer interface. The Patsnap API reference provides REST/JSON interfaces and OpenAPI schemas for the available data operations. This supports integration into a backend that already processes OPS records.

OPS itself includes worldwide patent information. The reason to evaluate Patsnap here is the combination of retrieval methods, research-data categories, and integration options required by your feature. Verify coverage for your target jurisdictions and record types during the trial.

Example: move from one disclosure to an evidence shortlist

For a sealing-mechanism investigation, a proposed application could:

1. Retain the starting evidence: the OPS publication identifier and the passage describing the mechanism.
2. Expand patent discovery: use a suitable Patsnap search operation to retrieve candidates related to that document or technical description.
3. Add literature context: search the mechanism and operating conditions, then retrieve the publication material needed for review through available access routes.
4. Present a review table: candidate identifier, inspected passage, relevance to the operating constraints, and the next question to investigate.

Your backend maps identifiers between sources and supplies selected material to the model. Preserve source labels and review proposed matches before joining records. This is an integration design, not a completed API run or an automatic OPS-to-Patsnap connector.

To evaluate the extension, select one required Patsnap operation and follow the first-request guide. Its introductory example returns a patent count; test a record-returning operation to validate your actual shortlist feature.