Open Patent Services - or OPS as it is also known - is a web service which provides access to the EPO's raw data via a standardised XML interface. The data is extracted from the EPO's bibliographic (EPODOC), the Worldwide Legal Status Database, full-text (EPOQUE) and image (BNS) databases and is therefore from the same sources as the data in Espacenet and the European Patent Register. However, while Espacenet and the European Patent Register only require an internet browser, OPS requires programming work to access the service.
You can find a technical description, schemas and further supporting documentation on our website.
To use OPS, you need to be familiar with web services in general. We also strongly recommend that you study Open Patent Services v.2 - Web Service Definition and Description - so that you fully understand the background and environment of the system.
No, users need to have or programme a client that is able to communicate with the XML interface using the REST architecture.
The EPO operates a fair use policy to ensure reasonable access for all users. OPS is not designed to deliver large amounts of data. If you require entire collections or databases, you should instead consider buying the EPO's raw data products. For more information on these products, contact us at firstname.lastname@example.org
For more information see our fair use charter.
Please note the following:
As a free service, OPS has its limitations. It can be quite busy and slow during working hours (between 07.00 and 19.00 hrs CET).
As explained in the fair use charter, there is a threshold of one request per second for family‑related actions, but the less intensive bibliographic service is faster. As a rule, all OPS services tolerate ten searches per minute per IP address, but this threshold may be higher or lower depending on operational circumstances.
Automatic (robot) access is welcomed on OPS, but within certain limits so it does not overwhelm the system. The maximum volume of traffic allowed for bulk download by robots is 1 Mbit/second. Again, this limit may vary depending on operational circumstances.
If you require complete databases or very large sets of records, please contact us at email@example.com. We can provide them at low cost by other means.
At the moment, bulk retrieval works with document inquiry and bibliographic retrieval via the Published Data services offered in RESTful OPS.
Retrieval via REST is limited to 100 documents.
The default display in OPS only shows the first 25 results, but if you want to see more, you can change the range parameter at the end of the URL ("&Range=xx-xx"). You can download batches of up to 100 results at a time:
However, OPS can only display a total of 2 000 results. If there are more than 2 000 hits in your results list, you will have to limit your search query to reduce the number of results.
Registration and the 2.5 GB/week usage limitation for non-paying users will relieve the servers. OPS receives traffic from many hundreds of concurrent user hosts per day. The service is connected to several EPO backend databases used by the EPO examining divisions. It is designed to be responsive to our external users without overwhelming the servers, thus enabling the EPO to continue its core operations unimpeded by OPS.
Users are categorised in the following way:
The published fair use policy and associated terms and conditions define what we consider to be appropriate usage by anonymous and registered users.
The policy is enforced in the following ways:
You should have the following information at hand:
The registration details entered are unique to OPS developer registrations. The username and password recorded here should not be confused with usernames and passwords for the EPO Forum, the European Patent Register or indeed for any other EPO secure registration and connection.
For users who have registered for OPS and particularly those who consume paid-for data, OPS has an API to assist in tracking the usage of data. The response produced by this API is based on the same database as is used for invoicing purposes by the EPO. Consequently, it is intended that the data consumer can control and predict future invoices produced by the EPO. The usage database is updated at ten minutes past the hour.
Yes, for certain countries. For coverage information see: "Contents and coverage of the DOCDB bibliographic file".
Procedural aspects (language of procedure, intention to grant, designated states, etc.) are typical European patent register data and are available in OPS Register.
The EPO aims to provide complete coverage of patent publications from as many countries as possible. For details of the situation relating to each country, see "Useful tables and statistics, coverage and codes".
In the EPODOC format, only the country code (CC) and document number are mandatory and must be given in one string. Leading zeros can generally be ignored, e.g.:
In the DOCDB format, the country code (CC), document number and kind code (KC) are all mandatory. If you don't know the kind code, you can replace it in full or in part with the wildcard '%':
The following expressions for the kind code are also acceptable:
Note: The use of wildcards may lead to an "ambiguous seed" response. The wildcards can be used in INPADOC-related services, bibliographic retrieval and document inquiry only.
To find citations, you have to do a search via the Published Data service, using a CQL request containing "ct" as in the following example:
To find cited documents, submit a request via the Published Data service, using the constituent "biblio" as in following example:
Using the Published Data service, submit a request with the constituent "equivalents". The following example shows what you have to do to retrieve all bibliographies for every equivalent of the family of publication EP1000000:
Since the family size is 4, all bibliographies can be obtained in one call using the batch mode:
You need to know the document identifier. This you get in a two-step approach:
1. Enter a query for the image ID via the Published Data service, using the constituent "images":
2. Insert the image ID found (published-data/images/EP/1000000/A1/fullimage) into the URL of your initial request (in bold) and add the appropriate format and page number at the end (Range=x):
<ops:document-instance system="ops.epo.org" link="published-data/images/EP/1000000/A1/thumbnail" number-of-pages="8" desc="Drawing">
<ops:document-section name="DRAWINGS" start-page="1"/>
<ops:document-instance system="ops.epo.org" link="published-data/images/EP/1000000/A1/fullimage" number-of-pages="12" desc="FullDocument">
Images are not stored in convenient PDF files which OPS can access and deliver without further processing. OPS could create the illusion of this by converting the images into a single PDF file for you, but this would burden the server to the detriment of other users.
The steps required to fetch the data using the new RESTful OPS are as follows:
Step 1 - Request document availability information:
Here you can see that the full document has 12 pages. You can also see that the abstract and bibliography begin on page 1, the description on page 2, the claims on page 3, the drawings on page 5 and the search report on page 11.
The relevant identifier is also given:
It is also shown that the pages are available in either tiff or PDF format.
Step 2 - Iterate over the pages:
You can iterate over the 12 pages by entering the following requests:
Alternatively, you can request each page as a PDF by using:
Step 3 - Assemble the pages:
Several open source tools are available to help you easily assemble the pages as a single PDF file:
In OPS you must use Boolean operators, in Espacenet it is optional. Both services use the Common Query Language (CQL). OPS is also faster if you do not request the bibliographic data, as the response contains publication references only.
The difference in behaviour is due to the way the two systems handle the number formats. Espacenet is much more flexible in handling numbers in different formats, while OPS requires you to (a) specify the format you are using (DOCDB or EPODOC) and (b) use the format as specified. Typically, issues will appear when working with publications where the EPODOC format requires that kind codes (or parts thereof) be attached to the publication number.
For some publication authorities, the EPODOC format requires that (part of) the kind code be attached to the number as follows:
The following example shows the difference between EPODOC and DOCDB number formats for a Japanese publication reference with B1 kind code:
One obvious way is to make a simple bibliographic retrieval for patent US6808849 while setting the constituent on "full cycle":
You will get the bibliographic data for all the publication steps relating to this invention, including the number of the published application US2003064291.
An alternative is to make an INPADOC family request. The response will contain basic information (publication, application and priority numbers ) for all the family members, including the various publication steps for that invention:
Currently, if the publication date is unknown, the system stores a value "0000-00-00", as a date is mandatory. Thus a CQL query should be extended with an additional condition (pd > 00000000) in order to exclude documents without a publication date.
Currently, due to technical reasons, some queries with words that have special characters return no result. The workaround is to treat such a word like two words and use the proximity operator. Instead of (ti=x-ray) query, use (ti=x prox/distance=0/ordered=true ti=ray), which looks for titles with "x" immediately followed by "ray".
Full-text coverage varies from country to country, but in the case of EP documents, in Espacenet as well as in OPS, you can only get the full text for the first publication step available, which is generally the A1 or A2 publication. You will not be able to get the full text (description or claims) for a B publication (granted patent).
Nevertheless, you can download full EP B documents via the European publication server. The publication server contains EP A as well as B documents. You can use web services to retrieve data from the European publication server (see "Help" file on the publication server)
The problem here is that the data is not available in the EP full-text database (because it is in TXTWOx format). Unlike Espacenet, OPS does not simplify the next step needed.
To find out where the relevant full text can be found, you have to follow the business rules for PCTs:
http://ops.epo.org/rest-services/published-data/publication/docdb/EP1855551.B1/fulltext (conclusion: no information, so check family or equivalents)
http://ops.epo.org/rest-services/family/publication/docdb/EP1855551.B1 (conclusion: long list - try the WO number with is-representative=yes)
http://ops.epo.org/rest-services/published-data/publication/docdb/WO2006094475/fulltext (conclusion: yes, there is a full text)
If the EPODOC format is used without a kind code, the system will search for all publications matching the publication requested.
Here is an example of request made in EPODOC format:
This will happen for those authorities where the same number identifies multiple publication steps (e.g. EP, WO, FR). In these cases the system will provide all publications that match that specific number. Effectively, the entire publication cycle will be provided. To avoid this, you can either provide a kind code value or use the DOCDB format.
There are several situations when the OPS system responds with an error message. Often the reason is web service unavailability, lack of server resources to process the request, incorrect request format or ambiguity.
A list of the most frequent error messages can be found in the Open Patent Services v.2 documentation.
Euro-PCT applications (e.g. EP0714461 A1) are not republished by the EPO because they have already been published in an official EPO language (English, French or German) by WIPO. Espacenet retrieves the full text from the corresponding PCT publication, OPS does not.
Thus you can only retrieve bibliographic data for publication EP0714461A1. The full-text document is published only as WO 9534702 A1. The granted EP patent, however, will be published by the EPO, in this case as document EP0714461 B1.