OPS v3.1 Documentation Version 1.2.12 en

OPS RESTful Web Services
Reference Guide v.1.2.12
September 2014
Patent Information
Open Patent Services

RESTful Web Services
Reference Guide
Version 1.2.12
Non-confidential
2014 European Patent Office
Page 1
September 2014
Revision history
Date
01/03/2011
Version
1.0.0
Description
Content development; master draft
consultation version
Authors
Patricia Passarelli
Silke Szymura
16/05/2011
1.0.1
Update according to changes in the new

OPS release
Silke Szymura
20/06/2011
1.0.2
Update according to changes in the next

OPS release
Silke Szymura
12/12/2011
01/03/2012
19/11/2012
30/05/2013
1.0.3
1.0.4
1.1
1.2
Dominic Afriat
Alexander Khval
Alexander Khval
Dominic Afriat
10/10/2013
1.2.8
08/11/2013
18/11/2013
16/04/2014
05/09/2014
1.2.9
1.2.10
1.2.11
1.2.12
Update to Family priority-claim response

Update according to 3.0 OPS release
Updated to reflect CPC changes
Updated for OPS 3.1 and user
Registration
Corrections to some Registered user
response behaviour
Number Service status codes update
Timezone specified
Quota error messages updated
Fixed links. Improved information related
to image services.
Non-confidential
Dominic Afriat
Alexander Khval
Alexander Khval
Alexander Khval
Dmitry Katsubo
Page 2
September 2014
Change-log
The following list summarizes the changes that were made between version 1.0.0 and
the current version of this document.
Version 1.0.1:
- The output of the register service (rplus.xsd) has changed:
o The register response is now wrapped in the element ops:registersearch that now contains the total-result-count attribute
o query and range elements were added for both the search and the retrieval service
o Renaming of the application-data and register-data elements to
register-documents and register-document
o Introduction of a date element in the document-id element
o Introduction of sequences in party members (e.g. applicant)
o Citations (references-cited) where added to the output
- ECLA retrieval service now also supports Y02 indexes and update of the ECLA
output; please refer to the CPC retrieval section for details.
- Addition of the CPC search service
- Addition of more detailed information on using the POST method in OPS
services; examples in the services chapters are now given both using GET and
POST.
Version 1.0.2:
- Update of the exchange-document schema:
o The exch:citation element was updated
The attribute srep-phase was replaced by a combination
cited-phase and cited-by in order to be ST.36 (and registerservice) compliant.
Table 12 contains information on the new citation phases
o Introduction of the generic element patent-classification to cover
EPO, USPTO, JPO and other national classifications inside of the
bibliographic-data element. For more information on how to use this
element, please refer to the docdb user documentation.
o Addition of the doc-id attribute in the exch:application-reference
element that contains a unique patent identifier. Please refer to the docdb
user documentation for more information.
o Addition of the kind attribute in the priority-claim element.
o The exchange-document schema has been updated according to be
more ST.36 compliant. Most of these changes are not actively populated
by the XML output of OPS.
- Improvement of the JSON output to conform to the so-called BadgerFish
convention (see chapter 2.2.1 Response structure)
- Introduction of an enhanced fair use monitoring and control (see chapter 2.3
Registration & OPS Fair use policy).
- Retrieval of Japanese abstracts and classifications (FI, FTERM) enabled.
- The output of the register service (rplus.xsd) has changed:
Non-confidential
Page 3
September 2014
o The attribute cited-in was replaced by cited-phase in order to be

ST.36 (and register-service) compliant.
- Update of the ops schema:
o Addition of the family-id attribute in the ops:family-member elements.
Version 1.0.3:
- Update of the family service & patent-family response to include new
INPADOC family elements & attributes:
o priority-active-indicator & priority-linkage-type
o is-representative attribute in the application-reference of
ops:family-member
Version 1.0.4:
- Range HTTP header is replaced by X-OPS-Range
- images constituent definition was fixed
- Throttle to Service mapping table was added
- POST requests method description was extended with more details
- image/tiff response content type was corrected by application/tiff
Version 1.1:
- All references updated to version 3.0
- CPC responses introduced and references to ECLA removed
- New classification mapping service is introduced
- New images and other throttles.
Version 1.2-1.2.7:
- Added User Registration instructions
- OAuth access token generation
- Developer API data usage
- HTTP headers for data usage
- Wildcards usage description normalized
- Reviewed quota headers description and error responses
- Clarified refresh time for data usage API
Version 1.2.8:
- Corrected data usage API response
- other minor clarifications concerning Basic authentication and Bearer tokens
- additional error responses
Version 1.2.9, 1.2.10:
- Number Service status codes update
- Timezone of data quotes reset time is specified
Version 1.2.11:
- Quota and throttling error message examples updated
Non-confidential
Page 4
September 2014
TABLE OF CONTENTS
1.INTRODUCTION...................................................................................................................... 7
1.1.What is OPS?....................................................................................................................... 7
1.2.Patent information relevant to OPS....................................................................................8
1.3.EP Patent lifecycle and reference types.............................................................................9
2.OPS CONCEPTS................................................................................................................... 10
2.1.Input.................................................................................................................................... 10
2.1.1.Request structure.............................................................................................................................. 10
2.1.2.Input format....................................................................................................................................... 13
2.1.3.Rules for constructing the input......................................................................................................... 14
2.2.Output................................................................................................................................. 18
2.2.1.Response structure........................................................................................................................... 18
2.2.2.Common response structures (XML)................................................................................................ 23
2.2.3.Error messages................................................................................................................................. 35
2.3.Registration & OPS Fair use policy..................................................................................36

2.3.1.Test access via anonymous client.................................................................................................... 36
2.3.2.User Registration for Registered access........................................................................................... 37
2.3.3.Authentication & Access Token handling.......................................................................................... 39
2.3.4.Dynamic fair use monitoring.............................................................................................................. 45
2.3.5.Data usage API................................................................................................................................. 49
3.OPS SERVICES..................................................................................................................... 52
3.1.Published-data services....................................................................................................52
3.1.1.Bibliographic data............................................................................................................................. 55
3.1.2.Fulltext inquiry and retrieval including description or claims..............................................................66
3.1.3.Images inquiry and retrieval.............................................................................................................. 74
3.1.4.Equivalents only or with abstract, biblio, full-cycle, images...............................................................81
3.2.Family service.................................................................................................................... 90
3.2.1.Family data (without constituents)..................................................................................................... 93
3.2.2.Family data with biblio....................................................................................................................... 95
3.2.3.Family data with legal........................................................................................................................ 97
3.2.4.Family data with biblio and legal....................................................................................................... 99
3.3.Number-service................................................................................................................101
3.3.1.From docdb to epodoc.................................................................................................................... 105
3.3.2.From original to docdb (JPO example)............................................................................................ 106
3.3.3.From docdb to original (JPO example)............................................................................................ 107
3.3.4.From original to epodoc (USPTO example)....................................................................................108
3.3.5.From epodoc to original.................................................................................................................. 109
3.3.6.From original to docdb (PCT example)........................................................................................... 109
3.4.Register service............................................................................................................... 111

3.4.1.Register retrieval............................................................................................................................. 112
3.4.2.Register search............................................................................................................................... 122
3.5.Legal service.................................................................................................................... 125

3.6.Classification services....................................................................................................129
3.6.1.CPC Retrieval................................................................................................................................. 130
3.6.2.CPC Media retrieval........................................................................................................................ 138
3.6.3.CPC Search.................................................................................................................................... 139
3.6.4.Classification Mapping service........................................................................................................ 142
4.APPENDIX............................................................................................................................ 145
Non-confidential
Page 5
September 2014
4.1.Relevant acronyms and abbreviations...........................................................................145

4.2.CQL index catalogue....................................................................................................... 146
4.3.The epodoc publication format.......................................................................................152
4.4.Expressing PCT application numbers in docdb format................................................153
4.5.Number-service Use Cases.............................................................................................154
4.6.Further reading................................................................................................................. 158
Non-confidential
Page 6
1.
September 2014
INTRODUCTION
1.1
What is OPS?
1.2
Patent information relevant to OPS
1.3
EP Patent lifecycle and reference types
____________________________________________________________ top of document
1.1.
What is OPS?
Open Patent Services (or OPS) provides web services for machine-to-machine queries
that deliver production stable patent data from the European Patent Office (EPO). OPS
services are free of charge and available 24 hours a day, 7 days a week. Please read
the fair use charter for details about using OPS.
Getting started
Beginning with version 3.0, OPS implements all services with a REST-style architecture.
This reference guide aims to provide the information and relevant details you need for
automated retrievals of raw patent data using OPS RESTful services.
In OPS Services section, the request examples are real and can be copied and pasted
into the browser where you can see the OPS responses. Note, the request response
examples will appear in the browser stylised with XSL, however all responses can be
viewed as XML by using 'View source'.
Note, for the pagination of this document some graphics have been scaled down. To
see them in greater detail, please use the zoom function of your document reader.
Thus, if you print this you may still need to refer to it electronically.
Non-confidential
Page 7
1.2.
September 2014
Patent information relevant to OPS
In the table below you will find the patent fundamentals relevant to OPS concepts.
Concept
Patent application
Description
The formal "paperwork" filed by an applicant, (or by a patent
attorney or patent agent on the applicants behalf) seeking to obtain
a patent for a specific invention. There are several parts to a patent
application, for example the description and the claims.
Patent publication
The first patent publication is often the published patent

application, 18 months after a priority date. Other publications are
typically the patent specification or in some cases the search report.
Patent priority
The Paris Convention for the Protection of Industrial Property of

1883, established the system of priority rights, under which
applicants have up to 12 months from first filing of their patent
application (usually in their own country) to submit further or
subsequent applications in each signatory country and claim the
original priority date. The first filing data (country, number and date)
is thus known as priority data for that invention.
For further details, especially for details about priority number
formats please refer to the priority number (on Espacenet.com).
Patent publication kind

code
A code which includes 1 or 2 letters and in many cases a number,

used to distinguish the kind of published patent document. For
example, the publication of an application for a patent with or without
a search report, and the level of the publication, for example first
publication, second publication or corrected publication. For more
details see the kind codes (on Espacenet.com).
Patent publication date
The date when a described invention becomes publicly available.

Further details publication date (on Espacenet.com).
Patent application claims
The part of the patent that defines the scope of the legal protection
sought for the invention. For further details, see claims (on
Espacenet.com).
Patent citation(s)
A patent document cited. Citations are not only added by the patent
applicant but also by the examiners of the patent application. Patents
citations may be added during the different steps of the granting
process (search report, examination, third party observations,
opposition) and thus added to the patent data.
Simple patent family
All documents sharing exactly the same set of priorities. For further
details see patent families (on www.epo.org).
Patent family
All documents sharing directly or indirectly at least one priority.
Table 1
Non-confidential
Page 8
1.3.
September 2014
EP Patent lifecycle and reference types
Figure 1
Diagram summary:
-
Each document can be referred to with a priority, application and publication number.
Information (X0) (as shown on the striped box on the left) from the priority document could serve as the basis for the initial patent information (D0) (shown as the
first part of the bibliographic stream of data in the lifecycle.)
Every modification (bibliographic data, description, claims ...) results in a subsequent

set of documents that represent the state of the file of the patent application. The
register provides a view on the modifications related to the bibliographic data.
The bibliographic data in a published document represents a snapshot of the bibliographic data at time of publication, i.e. the set of valid bibliographic/register data that
is part of the publication.
Register data is the public view of the electronic file when the application enters the
public phase, i.e. after the first publication in the European Patent office.
Non-confidential
Page 9
2.
September 2014
OPS CONCEPTS
2.1
Input
2.1.1 Request structure
2.1.2 Input format
2.1.3 Rules for constructing the input
2.2
Output
2.2.1 Response structure
2.2.2 Common response structures
2.2.3 Error messages
2.3
Registration & OPS Fair use policy
2.3.1 Test access via anonymous client
2.3.2 User Registration for Registered access
2.3.3 Authentication & Access Token handling
2.3.4 Dynamic fair use monitoring
2.3.5 Data usage API
___________________________________________________________ top of document
2.1.
Input
The following sub-sections focus on the patterns used to construct requests, including
the elements used specifically by OPS requests and their definitions.
2.1.1.
Request structure
How the generic OPS request URI is constructed:
protocol/authority/[version]/prefix/service/
reference-type/input-format/input/[endpoint]/
[constituent(s)]/output-format
Note, URI parts in bold are mandatory, square brackets [ ] signify optional parts.
The output-format is used only by the Number-service (section 3.3).
Request structure concept
Non-confidential
Page 10
September 2014
Note, Classification service (section 3.6) does not use the same request structure (as
shown above.) You will find the request structure and examples in that section.
POST method
In addition to GET requests, OPS also supports the HTTP POST method. This is
especially helpful if you want to request a large number of publications via the
bibliographic data bulk retrieval (see section 3.1, 'Published-data service'). It is also an
alternative to using brackets in the URI when dealing with numbers in original number
formats including special characters like slashes and dots (see section 3.3, 'Numberservice').
In most cases, in order to use the POST method, the request URI is the same as with
GET but without the input:
protocol/authority/prefix/service/reference-type/inputformat/[endpoint]/[constituent(s)]
Note, URI parts in square brackets [ ] are optional.
The input would then go into the request body. When posting multiple numbers, you
can provide them on separate lines or in one-line separated with commas.
Although most of the tools set Content-Type automatically and OPS has no strict
regulation on the value of Content-Type HTTP request header, you need to make
sure that this header is not empty at least and the preferable value for it is plain/text
for any OPS POST request.
Content-Type : plain/text
For POST requests example please refer to the specific service description.
Tip: While GET requests can easily be tested using a browser, this is not possible for
POST requests. You can use the Mozilla Firefox RESTClient Add-On to test all kinds of
HTTP methods as well as HTTP headers.
Non-confidential
Page 11
September 2014
Request concept elements

URI part
protocol
authority
version
prefix
service
reference-type
input-format
input:
CC
number
[KC]
[date]
[endpoint]
[constituent(s)]
Description
Usually http
Usually it's the host name.
The OPS production authority is
ops.epo.org
Currently, 3.0.
see OPS versioning (section 2.3)
Always rest-services to distinguish the use of
the OPS RESTful services
Service name; see OPS services (section 3).
There are 3 types: publication,
application, priority all of which
are mandatory for requests.
Mandatory for requests; format-specific;
see below Input format (section 2.1.2).
Consists of 4 input parts: CC, number,
[KC] and [date].
Note, in Classification service (section 3.6)
the input is structured differently.
The country code; mandatory part of the
input; format-specific; see below Input
format (section 2.1.2).
Number that belongs to the reference type
input; mandatory part of the input; formatspecific; see below Input format (section
2.1.2).
Kind code; optional part of the epodoc
input. (Note, the kind code can be replaced
by the asterisk * wildcard.) See Rules for
constructing input patterns (section 2.1.3).
Date; in YYYYMMDD format only; optional
part of the input.
Optional URI part; Used by published-data
services and provides various parts of
published data. Mandatory, for Numberservice (section 3.3).
Optional part(s) of the URI. A response
modifier. Several can be included in a
request. They are separated with commas.
Table 2
Non-confidential
Page 12
2.1.2.
September 2014
Input format
The original number format is the domestic numbering format of each patent office.
These number formats vary and are documented in the WIPO standard ST10c.
Note, the original format is used only by the OPS number-service (section 3.3).
The docdb format is derived from the original number formats. The docdb format is
related to the EPO's "DOCDB" database, a global patent database, which stores the
domestic number formats in a consistent way. For more information on PCT numbers,
please refer to the Appendix, section 4.4 Expressing PCT application numbers in
docdb format.
For search purposes, the EPO has created the "EPODOC" database, which has
introduced a strict number normalization or formatting, especially for application and
priority numbers. Thus it is known as the epodoc format.
A publication number in epodoc format refers to the initial publication in the patent
lifecycle (as shown in Figure 1 in section 1.3.). Characteristic of an epodoc number is it
may have a letter combined into it at the end, e.g. NL1016699C.
For additional details, please see in the appendix 'epodoc publication format' (section
4.3).
Reference type/format
application/original
application/docdb
application/epodoc
Example that appears on the actual document

MD a 2005 0130
MD.20050130.A
MD20050000130
Table 3
Non-confidential
Page 13
2.1.3.
September 2014
Rules for constructing the input
There are 3 input formats: (of which each has a specific pattern):
original, docdb, epodoc.
original
Input consists of 4 possible parts:
- country code (CC) - optional
- number (unformatted string) - mandatory
- kind code (KC) - optional
- date (date) - optional
Note, the date format used in OPS is ALWAYS YYYYMMDD.
Note:
- original format is USED ONLY by the OPS number-service (section 3.3).
docdb
- country code (CC) - mandatory
- number (number) - mandatory
- kind code (KC) - mandatory
epodoc
- number (the epodoc number string) - mandatory
- kind code (KC) - optional docdb kind code
Note:
- in certain countries (e.g. EP, WO, FR, GB) a publication number in
epodoc format refers to the initial publication in the patent lifecycle (as
shown in section 1.3); you can add a corresponding docdb kind code to refer
to another publication of the patent lifecycle.
Non-confidential
Page 14
September 2014
Input construction rule 1: concatenation with dots

Example of original input, reference-type application:
(08/921,321).19970829 [CC.number.date]
Note:
- see input handling with brackets below.
US.
Example of docdb input, reference-type application:

US. 92132197.A.19970829 [CC.number.KC.date]
Example of epodoc input, reference-type application:
US19970921321.19970829 [number.date]
Input construction rule 2: handling special characters with brackets

-
Some patent numbers may include slashes ( / ), dots ( . ) and commas ( , ) e.g.
US08/921,321 or CH 99947655.9. To use numbers like these (that have special
characters) for an OPS number-service request, the commas must to be enclosed
inside brackets ( ). Otherwise the service will understand these commas as
separators. Thus, input for requests should become: (US08/921,321)
and CH.(99947655.9).
These number types could be used as input if reserved and unsafe characters are
encoded (see 'encoding' below.) Although OPS DOES NOT ACCEPT any encoding of the slash, commas ( , ) are acceptable when encoded with %2C. Making the
number example look like this:
US08%2C921,321
Non-confidential
Page 15
September 2014
Input construction rule 3: encoding

For various reasons some characters present the possibility of being misunderstood
within URIs. These characters should also always be encoded. Note, the first 4 in the
list, in bold are mandatory encoding for OPS. The others are highly recommended.
URL reserved and unsafe characters in HTTP
Name
Question mark
'At' symbol
'Hash' or "pound' symbol
Percentage symbol
Dollar
Ampersand
Plus
Comma
Colon
Semi-colon
Equals
A empty space in the line, string or URI.
Double-quotation mark
'Less than' or left-angled bracket
'Greater than' or right-angled bracket
Left curly brace
Right curly brace
Vertical bar or "pipe"
Caret
Tilde
Left square bracket
Right square bracket
Grave accent
Character
?
@
#
%
$
&
+
,
:
;
=
SPACE
"
<
>
{
}
|
^
~
[
]
`
Code
%3F
%40
%23
%25
%24
%26
%2B
%2C
%3A
%3B
%3D
%20
%22
%3C
%3E
%7B
%7D
%7C
%5E
%7E
%5B
%5D
%60
Table 4
Note, in OPS these characters SHOULD NEVER BE ENCODED:

Forward slash
Back slash
/
\
Table 5
Non-confidential
Page 16
Format
original
Examples
DE 20 2007 016 308.8
OPS compliant presentation is
with brackets (see above):
DE.(20 2007 016 308.8)
docdb
And with the space escaped

this number becomes:
DE.(20%202007%20016
308.8)
DE.202007016308.U
epodoc
DE200720016308U
September 2014
Description
The original application number, as found in the original
patent publication.
Application number with country

code (DE)and kind code (U).
Note, all parts must be separated with dots [.]
Application number with country
code (DE), number
(200720016308) and kind code
(U) are usually combined (no
dots).
Table 6
Input construction rule 4: functional modifications

Commas
-
For OPS requests, commas can be used only to separate constituents that are used
by the published-data service (section 3.1), the family service (section 3.2) and register services (section 3.4).
Note, these constituents are explained in their respective sections.
Commas are also used in bulk requests to separate entities.
Non-confidential
Page 17
2.2.
September 2014
Output
The following sub-sections focus on the various types of XML output in OPS responses
as well as the XML structures used by the OPS services.
2.2.1.
Response structure
When using OPS RESTful services it is important to know how the data is structured to
ensure that you can properly request and retrieve what you need.
By default almost all responses are in XML and are styled with XSL for a more visually
expressive output if you view the response using a web browser. However you can
always see the XML behind these responses by using the "view source" function in your
browser.
All XML responses are encapsulated within the ops:world-patent-data element,
but their structure greatly depends on the web service type. This section contains
elements, which are important parts of a service response.
The schema below is the basis upon which all the other schemas are referenced.
Figure 2
Non-confidential
Page 18
September 2014
Aside from the OPS XML responses (encapsulated by ops:world-patent-data)

there are other response types that can be obtained as part of your request.
HTTP response content types

OPS service
Possible value for Accept header
Published-data
application/fulltext+xml
Published-data
application/exchange+xml
Published-data/images
image/pdf
application/tiff
image/png
Number-service
application/ops+xml
Classification/cpc
application/cpc+xml
CPC/images
image/gif
Register
application/register+xml
ALL OPS SERVICES that support XML
application/json
ALL OPS SERVICES that support XML
application/javascript
Table 7
You will find more information on what the respective responses look like in the OPS
services chapters.
JSON
As shown in Table 7 all OPS services that support XML are also capable of giving a
JSON response. JSON is a lightweight, language-independent, text-based format for
interchanging data and is often used in AJAX requests and responses. For more
detailed information on the JSON format, please refer to http://www.json.org/.
Requesting JSON instead of XML is simple. Just change the Accept header in your
GET- or POST-Request to application/json and use the same request URI as
usual.
All elements in the XML response are also present when requesting JSON.
Non-confidential
Page 19
September 2014
For the transformation of the output from XML to JSON, OPS follows the so-called
BadgerFish convention. This convention dictates the following 12 rules for the
conversion:
Element names become object properties

Text content of elements goes in the $ property of an object.
Nested elements become nested properties
Multiple elements at the same level become array elements.
Attributes go in properties whose names begin with @.
Active namespaces for an element go in the element's @xmlns property.
The default namespace URI goes in @xmlns.$.
Other namespaces go in other properties of @xmlns.
Elements with namespace prefixes become object properties, too.
Example Request:
GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/biblio
Accept: application/json
Response:
{"ops:world-patent-data": {
"@xmlns":
{
"ops": "http:\/\/ops.epo.org",
"$": "http:\/\/www.epo.org\/exchange",
"ccd": "http:\/\/www.epo.org\/ccd",
"xlink": "http:\/\/www.w3.org\/1999\/xlink"
},
"ops:meta":
{
"@name": "elapsed-time",
"@value": "28"
},
"exchange-documents": {"exchange-document":
{
"@system": "ops.epo.org",
"@family-id": "19768124",
"@country": "EP",
"@doc-number": "1000000",
"@kind": "A1",
"bibliographic-data":
{
"publication-reference": {"document-id":
{
"@document-id-type": "docdb",
"country": {"$": "EP"},
"doc-number": {"$": "1000000"},
"kind": {"$": "A1"},
"date": {"$": "20000517"}
Non-confidential
Page 20
September 2014
},
{
"@document-id-type": "epodoc",
"doc-number": {"$": "EP1000000"},
"date": {"$": "20000517"}
}
]},
// remaining values removed for readability
} } }
Note, for a quick test using the JSON format in your browser you can add
.json to the end of your OPS URI, e.g.:
http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/biblio.json
Overview of XML namespaces

OPS provides information in XML, embedded in a structure containing different
namespaces, which are used in other EPO systems. Depending on the web service you
call, the response might contain elements from several namespaces.
Data Structure
document
Namespace
Description
Open Patent Services

input and output
schema
ops
This is the main namespace that

references all of the others.
Defines the structure of the XML
output documents in OPS v.3.0.
Additionally, it defines a structure
used for exchanging legal information
about the patent publication.
EPO Exchange
Document
exch
EPO Fulltext schema
ftxt
Cooperative Patent
Classification system
(CPC)
cpc
Register
reg
Defines structures for exchanging

patent documents, including abstracts,
in line with WIPO standard ST.36. For
more details see Exchange
document (section below).
Describes structures for providing
description, claims and drawings from
a patent publication.
Describes structures for providing
CPC. For more details see
Classification service (section
below).
ST.36 compliant Register DTD, see:
https://register.epo.org/regviewer
Non-confidential
Page 21
Non-confidential
September 2014
Table 8
Page 22
2.2.2.
September 2014
Common response structures (XML)
Response references
Throughout the responses you will find the same structure when patent references are
used (application, publication or priority):
Application-reference response:
Figure 3
Application reference attributes (used in OPS responses)
Attribute name
doc-id
Description
Unique patent identifier. Please refer to the
docdb user documentation for more
information.
is-representative
Identifies whether this application is the family
representative in the EPO simple patent

family, value = YES/NO
Non-confidential
Page 23
September 2014
Publication-reference response:
Figure 4
Priority-claim response:
Figure 5
Non-confidential
Page 24
September 2014
Priority Claims elements (optional but used in OPS family responses)

Attribute name
Priority-linkage-type
Description
The Linkage Type, used to indicate the
priority relation e.g. for continuation,
continuation in part, for division etc..
Please refer to the docdb user
documentation ANNEX III for more
information.
priority-active-indicator
The DOCDB Active indicator, used to define

Simple patent families. Please refer to the
docdb user documentation for more
information.
Document-id
As you can see, all of the reference types use the document-id element, which
contains the information about the reference: country code, number, kind code,
date and document-id-type (or format):
Figure 6
Non-confidential
Page 25
September 2014
Note, in the schema above:

- The doc-number is mandatory.
- One reference may have multiple document-id elements in order to express the
same reference in different number formats:
<publication-reference>
<document-id document-id-type="docdb">
<country>EP</country>
<doc-number>1000000</doc-number>
<kind>A1</kind>
<date>20000517</date>
</document-id>
<document-id document-id-type="epodoc">
<doc-number>EP1000000</doc-number>
<date>20000517</date>
</document-id>
</publication-reference>
Non-confidential
Page 26
September 2014
Exchange Document
OPS uses the exchange-document schema for the exchange of bibliographic data. For
further details please see the docdb user documentation.
Figure 7
As shown in figure 7 the exchange-document schema includes both the
bibliographic-data and abstract elements. The exch:patent-family
element is not used by OPS.
The following tables provide some highlights of the exchange document diagram (as
shown above).
Exchange document attributes (contained in the bibliographic data response):
Attribute name
system
Description
OPS server identifier; OPS v.3.1 is identified
by ops.epo.org
family-id
Unique identifier of the simple family to

which the document belongs
country
Country code of the underlying document
doc-number
Document number (may have leading zeros

in some cases)
kind
The document's kind code
status
Only appears when document could not be

found.
Table 9
Non-confidential
Page 27
September 2014
Figure 8
Non-confidential
Page 28
September 2014
Some elements contained in the bibliographic-data element:

Element
publication-reference
Description
Refers to the publication in every available
format. To express different formats,
document-id elements are used (see
section 'Response References'.) All fields are
properly resolved. If a wildcard (*) has been
used, it shall be now properly determined
revealing the full kind code.
Additionally, the publication date is provided in
date element in the format yyyyMMdd, where
yyyy refers to the publication year, MM to the
publication month number (with the leading
zero) and dd to the publication day number
(with the leading zero).
classification-ipc
Provides the list of IPC1-7 classes the

underlying publication has been classified
into.
The content of this element is no longer
supported for publication published after
January 2006, please refer to classificationipcr element instead which contains classes
from IPC8
classification-ipcr
Provides the list of IPC8 classes the

underlying publication has been classified
into, according to WIPO ST8.
patent-classification
Generic element for classifications allocated

by EPO, USPTO, JPO and national offices;
e.g. CPC, FI, FTERM and DOCUS. ECLA is
no longer supported by the EPO and will not
appear in future OPS responses.
application-reference
Refers to the application document in every

available format with the application date.
In most cases, docdb and epodoc format are
provided, original if available.
priority-claim
Contains a priority claim document reference

in the available format(s) with the
priority date. The sequence attribute refers to
the order in which priorities are
printed on the published document.
applicant (epodoc format)
Contains the applicant name(s) written in
Non-confidential
Page 29
September 2014
Element
Description
epodoc format.
applicant (original format)
Contains the applicant name(s) as it is written

on the original paper document, if available.
inventor (epodoc format)
Contains the inventor name(s) written in

epodoc format.
inventor (original format)
Contains the inventor name(s) as it is written

on the original paper document, if
available.
invention-title
Contains the invention title in the original

language and French, German or English, if
available. The language code is provided
within the lang attribute.
There might be many invention-title
elements which reflect the title
structure, as printed on the publication
document.
citation
Provides the publication references (in

epodoc format) to the documents
considered to be relevant during a single
phase of a search/grant procedure.
The sequence attribute refers to the order in
which documents are printed on the search
report document. For more information on see
citations table below.
abstract
Contains the abstract paragraph, if available.

The language code is provided within the
lang attribute of the abstract element.
There might be many abstract elements
that reflect the abstract structure, as printed
on the publication document.
Table 10
Non-confidential
Page 30
September 2014
Citations
Citations are part of the bibliographic response. (See the table in the introduction '1.2
Patent information relevant to OPS'.)
Structure of the citation part of the exchange document schema:
Figure 9
Note, not all of the elements that are present in the schema are actually used in the
OPS response.
Non-confidential
Page 31
September 2014
Citation types
There are two types of citations: patent (patcit) and non-patent (nplcit).
patcit:
Figure 10
nlpcit:
Figure 11
Non-confidential
Page 32
September 2014
Citation categories
Citation categories illustrate the citation importance and are provided within the
category element as a string combined using the following values (table below):
Letter
X
I
Description
particularly relevant if taken alone (- prejudicing novelty, from April 2011)
particularly relevant if taken alone - prejudicing inventive step (from April
2011)
particularly relevant if combined with another document of the same category
technological background
non-written disclosure
intermediate document
theory or principle underlying the invention
earlier patent document, but published on, or after the filing date
document cited in the application
document cited for other reasons
Y
A
O
P
T
E
D
L
Table 11
Originator of the citation

The attribute cited-by contains information on who cited the document during the
cited-phase. The following values are possible:
applicant
examiner
opponent
third-party
other
unknown
Citation phases
The phase during which the citation was revealed can be found in the cited-phase
attribute of the citation element. Table 12 shows all possible citation phases.
Non-confidential
Page 33
Phase name
description
search
International-search-report
supplementary-internationalsearch-report
national-search-report
supplementary-national-searchreport
international-type-search-report
examination
international-examination
national-examination
opposition
limitation
other
unknown
September 2014
Description
Cited during the description (application) phase
General Search phase; used when no further
information available. Otherwise, use one of the
concrete phases below:
Originates from International Search
Report
Originates from the international
Supplementary Search Report
Originates from the national Search Report
Originates from the national
Supplementary Search Report
Originates from the international Type
Search Report
General Examination phase; use EXA when there
is no further information available or one of the
below if there is:
Cited during PCT chapter II (preliminary
examination); international examination
Revealed during the national examination
phase
Revealed during the Opposition phase
Revealed during the Limitation phase
Other documents of interest (cited in compte
rendu but not in search report)
No information available
Table 12
Non-confidential
Page 34
2.2.3.
September 2014
Error messages
There are some situations when the OPS may respond with an error message.
Response Error message
code
404
CLIENT.InvalidReference
404
CLIENT.WrongReferenceFormatting
413
CLIENT.AmbiguousRequest
404
SERVER.EntityNotFound
404
400
400
CLIENT.NotFound
CLIENT.InvalidQuery
CLIENT.CQL
405
CLIENT.MethodNotAllowed
403
CLIENT.RobotDetected
503
SERVER.LimitedServerResources
500
SERVER.DomainAccess
Possible occurrence
At least one reference in
the request is invalid:
<DETAILS>.
At least one reference in
the request has a wrong
value for data-format
The requested input was
ambiguous.
The requested data could
not be found. <DETAILS>
Resource not found
The request was invalid.
The query provided is invalid, <DETAILS>
Can't serve media types
listed in the Accept
header, <DETAILS>.
Recent behaviour implies
you are a robot. The
server is at the moment
busy to serve robots.
Please try again later.
Please request bibliographic data in smaller
chunks
The request could not be
processed. Please try
again later.
Table 13
Non-confidential
Page 35
2.3.
September 2014
Registration & OPS Fair use policy
OPS receives traffic from many hundreds of concurrent user hosts per day. The OPS
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.
The Fair Use policy is required to ensure that users are aware that there are limits to the
amount of data we can serve both in volume and the overall number of requests. To
protect the EPO systems from malicious denial of service attacks or naive application
development by 3rd parties, a number of measures are in place to encourage fair use:
Users are categorised in the following way:
Anonymous users receive a small allocation of data for very low volume usage.
Registered users are granted free access to higher volumes of data up to a
certain ceiling defined in the OPS terms and conditions.
Registered users willing to pay for more substantial volumes of data can record
Billing contact details and apply for access to higher volumes of data.
The published fair use policy and associated terms and conditions define what we
consider to be appropriate usage by anonymous and registered users. It is enforced in
the following ways:
2.3.1.
Registered users must Authenticate when accessing OPS using https and OAuth
(described below).
Dynamic fair use monitoring inside the OPS system gives the user feedback on
usage in such a way that enables the user to control the behaviour of their client
application. This feedback takes the form of HTTP headers with each response
generated by OPS specifically for the user.
If the user behaviour exceeds the terms of the fair use policy then the dynamic
fair use controls ensure that access is reduced accordingly.
Users that are found to be especially disruptive can be blocked completely from
the application until agreement is reached with OPS support to release them.
Test access via anonymous client
Anonymous usage is where a user wishes to consume OPS data without registration.
This approach is supported for low usage levels for example to test and evaluate data
from OPS or to support human interaction for low volume lookups of Patent information.
Non-confidential
Page 36
September 2014
Anonymous users do not need to Register with OPS, Authenticate and request Access
Tokens, all of which are described in the following sections. HTTP and HTTPS protocols
are available.
Anonymous users must adhere to the dynamic fair use monitoring described below and
conform to the HTTP Headers exchanged.
2.3.2.
User Registration for Registered access
Overview
For all users requiring more substantial access to OPS then registration is a necessary
step.
By registering, the user will receive access credentials to the OPS service. The access
credentials are used to Authenticate the user and obtain an access token. With the
access token, the user can access the OPS server.
Each registered developer can define one or more sets of Client Credentials and secret.
This is for testing purposes to allow different versions of OPS to be used by the same
developer. The terms and conditions of use relate to a single developer registration.
HTTPS is used for all communication with the registration portal and OPS when the
exchange of access credentials is involved.
Prior to attempting registration the user should have the following information at hand:
A username (must be unique to the OPS system)

An email address (must be unique to the OPS system). This email address will
be used for all registration and activation correspondence.
An address. We require detailed information concerning your location and
organisation.
Contact details. We require telephone and email addresses where we can
contact a technical representative.
Billing details. Users requiring access to large volumes of data can select the
option to pay (please refer to terms and conditions). Information required
includes VAT and billing address details. Optionally a Purchase order number
can be specified. Separate telephone and email contact details are required to
deal with invoicing and settlement issues.
Please note: The registration details entered on this screen are unique to OPS
developer registrations. The username and password recorded here should not be
confused with username and passwords for the EPO Forum, the European Patent
Register or indeed for any other EPO secure registration and connection.
Non-confidential
Page 37
September 2014
It is the users responsibility to NOT reuse passwords that have also be used in other
registered profiles in other system. For example, you should not reuse twitter, facebook,
gmail, outlook, itunes or indeed other EPO passwords in this registration.
Submission of registration request
The registration page can be found at https://developers.epo.org

The user enters the registration details including Billing contact information if
large volumes of data are required
The user accepts the terms and conditions and confirms that he/she is authorised
to act on behalf of the organisation being registered.
If the user is willing to pay for substantial volumes of data, then the system will
ask for confirmation that the user understands that this will result in invoices
being produced.
The user submits the registration request.
Emails are sent to the EPO administrator and the user requesting registration.
The account is NOT activated until the EPO approves the registration request.
Approval of registration request
The EPO applies a number of criteria before activating the account

As a general rule, we avoid creating duplicate or vaguely defined user accounts
We will attempt to contact you if your details are not complete
Emails are sent to the user when the account is approved or rejected
Creation of Client credentials
Once the user has received notification that the registration has been approved,
with a copy of the Terms and Conditions that the user accepted, the OPS Client
credentials can be generated. The email includes a link to further edit the
registered user profile.
The user should select the option to define Applications (My Apps).
Each App added will produce a new set of client credentials
Each App should be given a name and be specific to one of the available OPS
systems (e.g. OPS v3.1 or future versions).
The consumer Key and Secret will appear on the App definition screen:
Figure 12: Example Client credentials made up of Consumer Key and Consumer Secret
Non-confidential
Page 38
2.3.3.
September 2014
Authentication & Access Token handling
Oauth Authentication and Access tokens

OPS uses the OAuth framework for Authentication and Authorization. At this point in
time, only the Client Credentials flow is supported using a Consumer key and
Consumer secret.
The following sequence diagram shows the steps that must be followed to convert client
credentials to an access token, in order to consume resource from the OPS service.
Figure 13: OAuth Access Token and OPS Request Sequence

diagram
The actual steps to follow are:

Step 1: Client converts Consumer key and Consumer secret to
Base64Encode(Consumer key:consumer secret).
This should be done programmatically using the language you are developing the client
application in. For the purposes of this example, a public website was used to perform
this conversion.
Non-confidential
Page 39
September 2014
By entering the colon separated Client credentials, an encoded response is generated.

This response is then be used for basic Authentication.
Figure 14: Converting colon separated Consumer Key and Consumer Secret to Base64 Encoding
Non-confidential
Page 40
September 2014
Step 2: Client requests an access token using Basic Authentication, supplying its
Consumer key and Consumer secret with base64Encoding over encrypted HTTPS
connection:
HTTPS
POST https://ops.epo.org/3.1/auth/accesstoken
HTTP Headers
Authorization:
Basic eTNBT0c4NnF3cWpVMFFVNjlWWUdUSjRKR3hVTjhFVkc6cnJYZHI1V0E3eDl0dWRtUA==
Content-Type:
application/x-www-form-urlencoded
POST request payload

grant_type=client_credentials
OPS authenticates the client credentials passed in the Authorization header using basic
authentication method.
If credentials are valid, OPS responds with a valid access token
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"issued_at" : "1364247843353",
"application_name" : "511d82a3-aa0e-4775-ba48-05ccd9275c56",
"scope" : "",
"status" : "approved",
"expires_in" : "1199",
"api_product_list" : "[ops31-prod]",
"organization_id" : "0",
"access_token" : "4AWoepfVNgf09DRmimEnGdXcgoFU",
"organization_name" : "epo",
"refresh_count" : "0"
The access token produced is valid for approximately 20mins.

A New access token should be requested as soon as an invalid access token message
is received from OPS.
Non-confidential
Page 41
September 2014
Step 3: Client accesses OPS resources with access token in authorization header
(bearer tokens) over encrypted HTTPS connection
HTTPS
GET https://ops.epo.org/rest-services/published-data/publication/epodoc/EP1000000
HTTP Headers
Authorization:
Bearer 4AWoepfVNgf09DRmimEnGdXcgoFU
Error conditions
Spike/Quota Errors
When
Returned when spike or quota limit has been reached.
XML Response
403 FORBIDDEN
<error>
<code>403</code>
<message>This request has been rejected due to the violation of Fair Use policy</message>
<moreInfo>http://www.epo.org/searching/free/espacenet/fair-use.html</moreInfo>
</error>
Blacklisting
When
Request is made to any resource that will be blocked (blacklisting)
XML Response
403 FORBIDDEN
<error>
<code>403</code>
<message>This request has been rejected</message>
</error>
Developer Blocked
When
Developer account is blocked by EPO admin.
XML Response
403 FORBIDDEN
<error>
<code>403</code>
<message>Developer account is blocked</message>
</error>
Non-confidential
Page 42
September 2014
OAuth Errors
When
An authentication request is made but it is failing.
XML Response
HTTP/1.1 400 Bad Request
Content-Type: application/xml;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
<error>
<code>400</code>
<message>invalid_client</message>
<description>Developer account is blocked</description>
</error>
The message field entry for an authentication error can be one of the following:
invalid_request
The request is missing a required parameter, includes an
unsupported parameter value (other than grant type),
repeats a parameter, includes multiple credentials,
utilizes more than one mechanism for authenticating the
client, or is otherwise malformed.
invalid_client
Client authentication failed (e.g., unknown client, no
client authentication included, or unsupported
authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code and
include the "WWW-Authenticate" response header field
matching the authentication scheme used by the client.
unsupported_grant_type
The authorization grant type is not supported by the
authorization server.
invalid_access_token
Non-confidential
Page 43
September 2014
Access token provided is either invalid or expired.

Client identifier is required (code 401)
Basic authentication with base64Encoding is improperly formed.
Required param : grant_type
Content type or grant_type payload improperly formed
The Developer Console
A developer console is available at https://developers.epo.org to experiment with the
above concepts.
Figure 15: The API console
The console allows users to select OPS services and observe the exchange of request
& responses.
Example steps are:
Select a service that you want to use. At the time of writing only one service is
available: http://ops.epo.org/rest-services
Select the Authentication model you wish to use: Anonymous or OAuth 2
Autonomous
Select the API Method you want to call: e.g. GET /published-data/search
Non-confidential
Page 44
September 2014
The console pre-populates example Query, Template and Header entries for a
valid query.
Click Send to view the HTTP header request, and the HTTP header response
NOTE:
HTTP can only be used with No Auth selected.
If you select OAuth 2 Autonomous a built-in Key and Secret is used to generate
the access token.
HTTPS should be used with OAuth 2 Autonomous. Failure to do so will result in
an HTTP 404 error response.
2.3.4.
Dynamic fair use monitoring
This chapter describes how the dynamic fair use control is applied, its effect when
triggered, and what users can do to avoid it.
HTTP Headers
The OPS system makes extensive use of HTTP headers to communicate information
back to the client application.
The section below describes the following HTTP headers:
Quota Headers
X-IndividualQuotaPerHour-Used
X-RegisteredQuotaPerWeek-Used
X-RegisteredPayingQuotaPerWeek-Used
X-Rejection-Reason
Self throttling headers
X-Throttling-Control
Quota Headers
The fair use policy describes data and bandwidth thresholds.
These can be summarised as:
A global 1Mbps (megabit per second) rule for all users. This is enforced as an
hourly quota equal to approx 450MB per hour, 77GB per week.
A Free quota of usage for all registered users (currently 2.5GB per week)
All excess usage above this will be Paid for usage, requiring special approval in
the registration process.
The Quota related custom http headers, X-IndividualQuotaPerHour-Used, XRegisteredQuotaPerWeek-Used, X-RegisteredPayingQuotaPerWeek-Used, are
produced with relevant requests to inform the users the current state of quota
consumed.
Once a specific quota is exhausted, the system will respond with a X-RejectionReason header.
As a general rule, Hourly quotas will be fully refreshed within 1 hour on a rolling window
basis. This is to encourage users to maintain a steady usage profile. A the rolling
Non-confidential
Page 45
September 2014
window advances, quota consumed at the beginning of the hour is released and made
available. Consequently users who develop software that sustains a very intensive
request profile will find the flow of data interrupted.
Weekly quota will be released each calendar week at midnight UTC/GMT.
Example Quota header response with quota remaining
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-IndividualQuotaPerHour-Used: 3006
X-RegisteredQuotaPerWeek-Used: 900006
X-Throttling-Control: idle (retrieval=green:200, search=yellow:20, inpadoc=red:30,
images=green:200, other=green:1000)
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Fri, 02 Sep 2011 06:52:11 GMT
Example Quota header response with quota exhausted

HTTP/1.1 403 Forbidden
X-Rejection-Reason: RegisteredQuotaPerWeek
Content-Length: 207
<error>
<code>403</code>
<message>This request has been rejected due to the violation of Fair Usepolicy</message>
<moreInfo>http://www.epo.org/searching/free/espacenet/fair-use.html</moreInfo>
</error>
Self throttling headers

OPS tracks concurrent usage of the service and establishes that the service is in one of
3 states:
Idle - Low concurrent usage being applied to the service at present
Busy - a significant number of concurrent requests are being handled
Overloaded - a very significant number of concurrent requests are being handled
For each system state, OPS applies limits to the number of requests that a single user
system can make over a period of time (a 60 second window). As the usage from a
single user host increases, the system is able to detect when a defined limit has been
reached for that user.
This header is used to further encourage users to moderate their usage profile such that
requests are sent to OPS in a uniform and consistent flow, avoiding periods of intense
usage.
Non-confidential
Page 46
September 2014
Example Throttling Control header response

Throttling information is provided in the http header response, indicating the system
state, the traffic light status for a particular service, and information concerning the fair
use limitation in place.
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.3.0.GA_CP07 (build: SVNTag=JBPAPP_4_3_0_GA_CP07
date=200911251949)/JBossWeb-2.0
X-Throttling-Control: idle (retrieval=green:200, search=yellow:20, inpadoc=red:30,
Transfer-Encoding: chunked
Date: Fri, 02 Sep 2011 06:52:11 GMT
The X-Throttling-Control header is specific to each user system and is delivered with
every OPS response. It indicates the current system state at that point in time.
Generic throttling information structure:
X-Throttling-Control: system-state (service-name=traffic-light-position:request-limit, ...)
The traffic light indicator for any single service can be in one of 4 positions:
Green - less than 50% of the permitted request limit has been used
Yellow - between 50% and 75% of the r20equest limit has been used
Red - more than 75% of the request limit has been reached
Black - the limit has been exceeded and service has been temporarily suspended
The request limit is variable in 2 ways:
Each individual service (retrieval, search, images, inpadoc or other) has different
request limits
As the system state changes from Idle to busy, or busy to overloaded, the
request limit for all users is reduced.
Example:
3 successive requests could receive the following response headers:
X-Throttling-Control: idle (retrieval=green:200, search=green:30, inpadoc=green:60,
X-Throttling-Control: busy (retrieval=green:100, search=green:15, inpadoc=green:45,
X-Throttling-Control: overloaded (retrieval=green:50, search=green:5, inpadoc=green:30,
In between the 3 requests the system state has changed (more and more concurrent
users are using the service). As a result the system has reduced the request-limit to
instruct users to reduce the level of request activity.
The values are determined over a 60 second window of utilisation. In other words the
traffic light and request limit reflect the number of requests a client has been making,
and are entitled to make over a fixed 60 second time frame.
When the black indicator has been reached a time indicator will appear:
X-Throttling-Control: overloaded (retrieval=green:50, search=green:5, inpadoc=black:0,
Non-confidential
Page 47
September 2014
Retry-After: 600000
Note, the Retry-After counter indicates the remaining time for which the service is
suspended.
Multiple instances of OPS
The above scenario describes the response behaviour of a single instance of OPS. In
fact there are many instances of the OPS service running in parallel. Each instance
receives traffic from a load balancer, which distributes the requests across the system.
At present the EPO has not implemented communication between OPS instances. Thus
when a stream of requests are sent, a stream of responses will be received, generated
by the farm of OPS server instances.
For example, if a long series of requests for Family or Legal data is made (affecting the
family service):
http://ops.epo.org/rest-services/family/priority/docdb/NL.1010536.A
etc....
the responses received could resemble the following, where t represents the number of
seconds passing sequentially:
t=0 X-Throttling-Control: idle (retrieval=green:200, search=green:30, inpadoc=green:60,
t=1 X-Throttling-Control: busy (retrieval=green:100, search=green:10, inpadoc=green:15,
...20 seconds later the following series of responses might be received:

t=20 X-Throttling-Control: overloaded (retrieval=green:50, search=green:5, inpadoc=red:30,
t=21 X-Throttling-Control: overloaded (retrieval=green:50, search=green:5, inpadoc=green:30,
t=22 X-Throttling-Control: busy (retrieval=green:100, search=green:15, inpadoc=green:45,
Each request will be handled by a separate instance of OPS. From this sequence it is
clear that one OPS response is reporting that a particular OPS instance is struggling
with the workload. The service is overloaded and the family (inpadoc) service being
called is in status red because this instance has served several of your requests.
Although other responses received indicate idle/inpadoc:green, the instance that
reported the problem may still be in the state reported. As a user adhering to the fair
use policy, you should moderate your usage of the service over a 60 second window,
according to the most negative response data received.
Self throttling correctly will enable you to avoid temporary or permanent suspension by
the OPS instance.
Non-confidential
Page 48
September 2014
Mapping between services and throttles

Throttle
search
retrieval
inpadoc
inpadoc
images
images
Rest service URI

/published-data/search/*
/published-data/*/
/family/*
/legal/*
/published-data/images/*
/classification/cpc/media/*
SOAP service
biblio-search
biblio-retrieval
family-*-retrieval
legal-retrieval
document-retrieval
Table 14
All other OPS services not included in the list above have throttle other.
2.3.5.
Data usage API
Overview
For users who have registered for OPS and particularly those who consume paid-for
data, OPS now has an API to assist in tracking the usage of data. The response
produced by this API is based on the same database 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 data usage report is updated within 10 mins of each hour. A request made at 10.01
will be reflected in the report between 11.00 and 11.10. The report gives a break down
day-by-day and is aligned on midnight UTC/GMT.
Request structure
The user should request a valid access token prior to calling the data usage API.
A single date, or a range of dates can be passed to the service. If a data range is given,
the dates should be separated with a ~ [tilde] character.
Calls to the data usage API are not subject to charging and consequently do not
contribute to the results presented.
GET https://ops.epo.org/3.1/developers/me/stats/usage?timeRange=dd/mm/yyyy[~dd/mm/yyyy]
Authorization: Bearer 4AWoepfVNgf09DRmimEnGdXcgoFU
For example for 30th September to 1st October:

GET https://ops.epo.org/3.1/developers/me/stats/usage?timeRange=30/09/2013~1/10/2013
Authorization: Bearer 4AWoepfVNgf09DRmimEnGdXcgoFU
Non-confidential
Page 49
September 2014
Response structure
The response produced is in JSON format.
{
"environments": [
{
"dimensions": [
{
"metrics": [
{
"name": "total_response_size",
"values": [
{
"timestamp": 1380585600000,
"value": "1.1781815E7"
},
{
"timestamp": 1380499200000,
"value": "58579.0"
}
]
},
{
"name": "message_count",
"values": [
{
"timestamp": 1380585600000,
"value": "420.0"
},
{
"timestamp": 1380499200000,
"value": "6.0"
}
]
}
],
"name": "123456,Registered Developer,4301"
}
],
"name": "prod"
}
],
"metaData": {
"errors": [],
"failedEnvs": "[]",
"notices": []
}
total_response_size (Byte) represents the actual and full amount of data consumed by
this user on the given date. It includes the amount of free data as well as paid-for data.
Non-confidential
Page 50
September 2014
Paying users will receive an invoice that has been adjusted to allow for the free data
quota. In cases of large amounts of data, the value is given in scientific notation:
e.g. 1.1781815E7 = 1.1781815 x107 or 11781815 Bytes.
message_count indicates the number of requests received from this developer

registration to produce the data response size indicated.
Timestamp is given with the Unix time for the dates included in the response.
The following website can be used to decode the unix time manually:
http://www.epochconverter.com/
Figure 16: Unix time converted to Human readable time
Results are grouped for the developer and date range give.
The response indicates the registered user's details from the registration record:
"name": "123456,Registered Developer,4301"
These fields are the EPO account number, the Registered developer name and the
unique registration record number respectively.
Non-confidential
Page 51
3.
September 2014
OPS SERVICES
3.1
Published-data service
3.2
Family service
3.3
Number-service
3.4
Register service
3.5
Legal service
3.6
Classification service
___________________________________________________________ top of document
3.1.
Published-data services
In this section you will find the services for retrieving published data.
Note, some services require a two-step process: inquire, then retrieve, especially for
fulltext and images.
Through different endpoints the published-data service provides access to worldwide
patent data:
Endpoints
fulltext
Description
Inquires about whether claims and/or
descriptions are available for patents.
claims
Retrieves the patent claims.
description
Retrieves the patent description.
images
Inquiry and retrieval of images or "drawings",

which can also be PDF documents.
equivalents
Retrieves the simple patent family; patent

documents that share the same technical
information, i.e. across different countries.
This endpoint also supports requests that
use constituents (See table below.)
biblio
The default response data for the publisheddata service, therefore the biblio endpoint
is used for retrieval of and searches for
bibliographic data. This endpoint is actually
to support requests for constituents (see
next table for details.)
abstract
Retrieves the patent abstract of the

bibliographic data.
Table 15
Non-confidential
Page 52
September 2014
Published-data constituents
For the biblio and equivalents endpoint requests, retrieval possibilities are
extended with "constituents", which modify what you will get in your in responses.
Constituents
full-cycle
Delivers
the full publication cycle of the patent
application. This consists of a "full set" or all of
the publications related to an application.
images
drawings and descriptions of the patent

(.png, .pdf, .tiff)
biblio
bibliographic data
abstract
patent abstract - This is only a constituent

when the equivalents endpoint is used in
the request. (See Endpoints table above.)
Table 16
Generic published-data request structure

In the request structure below, bold means mandatory.
GET http://ops.epo.org/rest-services/ publisheddata/reference-type publication or application or

priority/input-format docdb or epodoc/input e.g.
EP1000000 or EP1000000.A1/[endpoint e.g.
biblio,abstract,equivalents,fulltext,claims,descriptio
n,images] and-or /[constituent e.g. biblio,fullcycle,abstract]?[parameter e.g. Range=1]
Accept: application/exchange+xml
Note, a published-data request without an endpoint provides the bibliographic data
by default or the data if you added the '/biblio' endpoint.
Note, in published-data requests, the POST method is also supported. Instead of
giving the input in the request URL, it has to be provided in the HTTP body. You will find
examples in the following chapters alongside the GET example requests.
Non-confidential
Page 53
September 2014
Combinations of endpoints and constituents

In the published-data service there are specific combinations of endpoints and
constituents.
CONSTITUENTS
Valid published-data service requests:

ENDPOINTS
/fulltext /claims /description /images /equivalents /biblio /abstract
biblio
fullcycle
images
abstract
valid
valid
valid
valid
valid
Table 17
Key:
-
invalid request combination.
Examples of generic combinations (specific request examples are included in their

respective sub-sections):
.../<input>/equivalents/biblio,full-cycle,abstract
.../<input>/biblio/equivalents
.../<input>/biblio,full-cycle,abstract
Notes:
Constituents included in requests must be separated with commas (examples are
included in the sub-sections.)
EXCEPTION: '/equivalents' endpoint requests, add its constituents with a slash
(whether it is only one constituent or all four of them.)
For '/abstract ' it is only a constituent when it follows the /equivalents endpoint.
(Examples are included in the sub-sections.)
The /images endpoint, for images retrieval requests is followed by the link contained in
the XML response of the images inquiry (section 3.1.3).
Non-confidential
Page 54
3.1.1.
September 2014
Bibliographic data
Retrieves the bibliographic data of all patent reference types, including bulk retrievals.
Biblio retrieval (simple, in bulk and/or with full-cycle)

Request example:
GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/biblio
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/biblio
Request Body: EP1000000.A1
Note, by default a request that does not include a constituent will automatically return
"biblio" data. OPS will redirect requests without a constituent to appear the request
example above. Furthermore, when request biblio, the abstract is automatically
included in the response, if available.
Note, kind codes in requests affect responses:
- WITH a kind code you get only that specific publication.
- WITHOUT a kind code, the service gives you all of the relevant publications to
the reference type.
Response structure
The Published-data service uses the Exchange Document structure (in section 2.2.2) to
provide bibliographic data.
Response (from the web browser):
If you want to see the XML use the "View source" option in your browser. (This is true
for all "styled" responses from OPS.)
Non-confidential
Page 55
September 2014
Figure 17
Note, all OPS services return a response in the browser that is styled with XSL but you
can see the XML by using the 'view source' function.
Biblio bulk retrieval

There are two ways of requesting biblio data for multiple references:
If you want to request a small number of references, you can use the GET method:
GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1676595,JP2006187606,US2006142694/bib
lio
Non-confidential
Page 56
September 2014
Response:
Non-confidential
Page 57
September 2014
<exchange-documents>
<exchange-document system="ops.epo.org" family-id="35840242"
country="EP" doc-number="1676595" kind="A1">
<bibliographic-data>
<kind>A1</kind>
<date>20060705</date>
</document-id>
<date>20060705</date>
</document-id>

</bibliographic-data>
</exchange-document>
country="JP" doc-number="2006187606" kind="A">
<country>JP</country>
<kind>A</kind>
<date>20060720</date>
</document-id>
<doc-number>JP2006187606</doc-number>
<date>20060720</date>
</document-id>

country="US" doc-number="2006142694" kind="A1">
<country>US</country>
<kind>A1</kind>
<date>20060629</date>
</document-id>
<doc-number>US2006142694</doc-number>
<date>20060629</date>
</document-id>

Non-confidential
Page 58
September 2014
</exchange-documents>
For large numbers of input references we recommend using the POST method:
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/biblio
Request Body: EP1676595
JP2006187606
US2006142694
The response will be the same as using the GET method.
In order to separate multiple input references in a POST request, either use comma or
new line.
Note, the bulk retrieval is limited to 100 references.
Non-confidential
Page 59
September 2014
Full-cycle
Full-cycle requests the full publication cycle of the bibliographic data. With or WITHOUT
a kind code in the request, the service gives you all of the publications. (See 'Patent
lifecycle' diagram, section 1.3.)
Request example:
GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/biblio,full-cycle
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/biblio,full-cycle
Response:
Note, the response includes A1 and B1 publications of the full-cycle. A biblio response
automatically includes the abstract.
Non-confidential
Page 60
September 2014
Figure 18
Non-confidential
Page 61
September 2014
Abstract
Abstract is a sub-element of the bibliographic data retrieval. It can be requested by
itself.
Request example:
GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/abstract
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/abstract
Response:
Figure 19
Non-confidential
Page 62
September 2014
Bibliographic search
The bibliographic search uses common query language (CQL) to retrieve the data.
Additional query details are in the 4.2 CQL index catalogue in the appendix.
Query example: "applicant=IBM"
A very basic query will return a list of publication references:
GET http://ops.epo.org/rest-services/published-data/search?
q=applicant%3DIBM
POST http://ops.epo.org/rest-services/published-data/search
Request Body: q=applicant%3DIBM
Additionally, the request can be combined with the possible constituents: abstract,
biblio and/or full-cycle:
GET http://ops.epo.org/rest-services/published-data/search/abstract,biblio,full-cycle?q=applicant%3DIBM
POST http://ops.epo.org/rest-services/published-data/search/abstract,biblio,full-cycle
Request Body: q=applicant%3DIBM
Note, the "invalid result" status is given when the specific result found in the internal
EPO system cannot be provided to external users (due to copyright or other reasons).
Non-confidential
Page 63
September 2014
Response structure:
Figure 20
The structure shown in figure 20 is part of the ops namespace and defined in the
ops.xsd schema file.
Non-confidential
Page 64
September 2014
Response example (with biblio):

<?xml version="1.0" encoding="UTF-8"?>
<ops:world-patent-data xmlns:ops="http://ops.epo.org"
xmlns="http://www.epo.org/exchange">
<ops:meta name="elapsed-time" value="223"/>
<ops:biblio-search total-result-count="100000">
<ops:query syntax="CQL">applicant=IBM</ops:query>
<ops:range begin="1" end="25"/>
<ops:search-result>
country="KR" doc-number="20100130646" kind="A">
<country>KR</country>
<kind>A</kind>
<date>20101213</date>
</document-id>
<doc-number>KR20100130646</doc-number>
<date>20101213</date>
</document-id>

<application-reference doc-id="331447793">
<doc-number>KR20107026618</doc-number>
<date>20060720</date>
</document-id>
<document-id document-id-type="original">
</document-id>
</application-reference>

<parties>
<applicants>
<applicant sequence="1" data-format="epodoc">
<applicant-name>
<name>IBM [US]</name>
</applicant-name>
</applicant>
<applicant sequence="1" data-format="original">
<applicant-name>
<name>INTERNATIONAL BUSINESS MACHINES CORPORATION</name>
</applicant-name>
</applicant>
</applicants>

</parties>
<invention-title lang="en">INJECTION MOLDED MICROLENSES FOR
OPTICAL INTERCONNECTS</invention-title>
Non-confidential
Page 65
September 2014

Non-confidential
Page 85
September 2014
Equivalents and biblio:

GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/equivalents/biblio
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/equivalents/biblio
Non-confidential
Page 86
September 2014
Response:
<kind>A1</kind>
</document-id>
</document-id>
country="NL" doc-number="1010536" kind="C2">
<country>NL</country>
<kind>C2</kind>
<date>20000515</date>
</document-id>
<date>20000515</date>
</document-id>

<doc-number>NL19981010536</doc-number>
<date>19981112</date>
</document-id>
</document-id>


Non-confidential
Page 87
September 2014
Equivalents and biblio and full-cycle:

GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/equivalents/biblio,fullcycle
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/equivalents/biblio,full-cycle
Non-confidential
Page 88
September 2014
Response:
<doc-number>EP1000000</doc- number>
</document-id>
country="EP" doc-number="1000000" kind="A1">
<kind>A1</kind>
<date>20000517</date>
</document-id>
<date>20000517</date>
</document-id>

country="EP" doc-number="1000000" kind="B1">
<kind>B1</kind>
<date>20030212</date>
</document-id>
<date>20030212</date>
</document-id>
Non-confidential
Page 89
September 2014
Equivalents and images:

GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/EP1000000.A1/equivalents/images
POST http://ops.epo.org/rest-services/publisheddata/publication/epodoc/equivalents/images
Non-confidential
Page 90
September 2014
Response:
<kind>A1</kind>
</document-id>
</document-id>
link="NL/1010536/C2/thumbnail" number-of-pages="6" desc="Drawing">
link="NL/1010536/C2/fullimage" number-of-pages="19" desc="FullDocument">
<ops:document-section name="CLAIMS" start-page="9"/>
<ops:document-section name="DESCRIPTION" start-page="2"/>
<ops:document-section name="SEARCH_REPORT" start-page="18"/>

Non-confidential
Page 91
September 2014
3.1
3.2
Family service
3.3
Number-service
3.4
Register service
3.5
Legal service
3.6
___________________________________________________________ top of document
3.2.
Family service
The family service retrieves relatives of a patent family, essentially the patent numbers
related to your input. The family retrieved is the INPADOC extended patent family (see
the espacenet help for more details)
As you have seen input formats used in patent information have a variety of purposes.
Relevant to the family service, requests can be either docdb or epodoc number format,
but not original.
With the family service you can also modify your responses with 'constituents'
biblio,legal (or none). Constituents of the family service are data blocks that
attribute to a specific patent family.
Constituent
biblio
legal
Description
Delivers bibliographic data of each family
member in the exchange-document element
Includes legal codes and descriptions of the
family members
Table 18
Generic request structure:
GET http://ops.epo.org/rest-services/family/
[reference-type: publication or application or
priority]/[input-format: docdb or epodoc]/[input e.g.
EP1000000 or EP1000000.A1]/[constituent: e.g.
biblio,legal]
In the request structure, bold means mandatory, italics means optional.
Note, the family service supports the * wildcard that can be used for one letter of the
given kind code; e.g. A*(matches A1, A2,..), * (matches every kind code).
Non-confidential
Page 92
September 2014
Generic request example:

GET http://ops.epo.org/restservices/family/publication/docdb/EP.1000000.A1
POST http://ops.epo.org/rest-services/family/
publication/docdb
Request Body: EP.1000000.A1
Note, specific request and response examples are given in the following sections.
Generic response structure
Non-confidential
Page 93
September 2014
Figure 29
The structure shown in figure 29 is part of the ops namespace and defined in the
Non-confidential
Page 94
3.2.1.
September 2014
Family data (without constituents)
GET http://ops.epo.org/restservices/family/publication/docdb/EP.1000000.A1
POST http://ops.epo.org/rest-services/family/publication/docdb
Response:
<ops:patent-family legal="false">
<kind>A1</kind>
</document-id>
<ops:family-member>
<country>AT</country>
<kind>T</kind>
<date>20030215</date>
</document-id>
<date>20030215</date>
</document-id>
<kind>T</kind>
<date>19991108</date>
</document-id>
<priority-claim kind="national">
Non-confidential
Page 95
September 2014
<kind>A</kind>
<date>19981112</date>
</document-id>
</priority-claim>
</ops:family-member>

</ops:patent-family>
Non-confidential
Page 96
3.2.2.
September 2014
Family data with biblio
Request:
GET http://ops.epo.org/restservices/family/publication/docdb/EP.1000000.A1/biblio
Accept:application/ops+xml
POST http://ops.epo.org/restservices/family/publication/docdb/biblio
Response:
<ops:patent-family legal="false">
<kind>A1</kind>
</document-id>
<ops:family-member>
<kind>T</kind>
<date>20030215</date>
</document-id>
<date>20030215</date>
</document-id>
<application-reference>
<kind>T</kind>
Non-confidential
Page 97
September 2014
<date>19991108</date>
</document-id>
<kind>A</kind>
<date>19981112</date>
</document-id>
</priority-claim>
country="AT" doc-number="232441" kind="T">
<kind>T</kind>
<date>20030215</date>
</document-id>
<date>20030215</date>
</document-id>


Non-confidential
Page 98
3.2.3.
September 2014
Family data with legal
Request:
GET http://ops.epo.org/restservices/family/publication/docdb/EP.1000000.A1/legal
POST http://ops.epo.org/restservices/family/publication/docdb/legal
Response:
<ops:patent-family legal="true">
<kind>A1</kind>
</document-id>
<ops:family-member>
<kind>T</kind>
<date>20030215</date>
</document-id>
<date>20030215</date>
</document-id>
<application-reference>
<kind>T</kind>
<date>19991108</date>
Non-confidential
Page 99
September 2014
</document-id>
<kind>A</kind>
<date>19981112</date>
</document-id>
<priority-active-indicator>YES</priority-active-indicator>
</priority-claim>
<ops:legal code="RER
"
desc="CEASED AS TO PARAGRAPH 5 LIT. 3 LAW INTRODUCING
PATENT TREATIES"
infl="-"
dateMigr="00010101">
<ops:pre line="00001">AT
99203729T 2003-08-15RER
-CEASED AS TO
PARAGRAPH 5 LIT. 3 LAW INTRODUCING PATENT TREATIES</ops:pre>
<ops:L001EP desc="Country Code">AT</ops:L001EP>
<ops:L002EP desc="Filing / Published Document">F</ops:L002EP>
<ops:L003EP desc="Document Number">
99203729</ops:L003EP>
<ops:L004EP desc="Kind Code">T</ops:L004EP>
<ops:L005EP desc="IPR Type">PI</ops:L005EP>
<ops:L006EP desc="PRS DOCUMENT TYPE">P</ops:L006EP>
<ops:L007EP desc="Gazette DATE">2003-08-15</ops:L007EP>
<ops:L008EP desc="Legal Event Code 1">RER</ops:L008EP>
<ops:L018EP desc="DATE last exchanged">2003-08-28</ops:L018EP>
<ops:L019EP desc="DATE first created">2003-08-26</ops:L019EP>
<ops:L500EP/>
</ops:legal>
Non-confidential
Page 100
3.2.4.
September 2014
Family data with biblio and legal
Request:
GET http://ops.epo.org/restservices/family/publication/docdb/EP.1000000.A1/biblio,legal
POST http://ops.epo.org/restservices/family/publication/docdb/biblio,legal
Response:
<kind>A1</kind>
</document-id>
<ops:family-member>

<ops:legal code="RER
" desc="CEASED AS TO PARAGRAPH 5 LIT. 3 LAW
INTRODUCING PATENT TREATIES" infl="-" dateMigr="00010101">
<ops:pre line="00001">AT
99203729T 2003-08-15RER
-CEASED AS TO
PARAGRAPH 5 LIT. 3 LAW INTRODUCING PATENT TREATIES</ops:pre>
<ops:L001EP desc="Country Code">AT</ops:L001EP>
99203729</ops:L003EP>
<ops:L004EP desc="Kind Code">T</ops:L004EP>
<ops:L008EP desc="Legal Event Code 1">RER</ops:L008EP>
<ops:L500EP/>
</ops:legal>
Non-confidential
Page 101
September 2014

country="AT" doc-number="232441" kind="T">
<kind>T</kind>
<date>20030215</date>
</document-id>
<date>20030215</date>
</document-id>
INPADOC family is too big to include in the response

In situations when the requested family is very large (several hundred members), all of
the members cannot be included in the response due to technical reasons. The patentfamily structure is returned with attribute truncatedFamily="true" and only a
limited number of family members are returned. Shown below is a family response
example for publication US2003082717 including the first four family members:
Figure 30
Non-confidential
Page 102
3.1
3.2
3.3
3.4
3.5
3.6
September 2014
Family service
Number-service
Register service
Legal service
____________________________________________________________________________________
3.3.
Number-service
This service converts numbers from one input format into another format. Number
conversion always pertains to the same reference (publication, application or
priority.)
List of possible conversions:

Input format
original
docdb
epodoc
Output format
docdb, epodoc
epodoc, original
original
Table 19
Note:
The number-service uses a carefully crafted set of pattern matching and formatting rules
for number conversion based on the OPS input formats. The development of these
rules is an ongoing process and at this point in time not every possible format of
every single country is supported.
The rules are optimized for recent documents of big countries and automated data
exchange. However, the rules are constantly updated and thus a conversion that
leads to a wrong result today might work next week. It is important to understand that all
requests will lead to a conversion but that the quality of the result will be variable.
Even though it is possible to request the number-service with a single string, it is
strongly advised to provide the date, country code and kind code separately with your
input (number) whenever you can identify them. It is especially important to include
the date in number-service requests because number formatting changes over time.
Non-confidential
Page 103
September 2014
Status codes
In number-service responses you will find an ops:meta element that contains status
information regarding the number conversion. If you experience problems with the
number-service, including the status codes helps the support team to analyze them.
Message Code
Message
BRE000
BRE001
BRE002
Unknown error code

Number Standardization Stopped
Number Standardization Stopped - Routed to Post
Processing
RawId not Defined
Country Code not Valid
Exception in date lookup
No Matching Pattern Found
Failed to convert sequence number for document
Illegal Country Code WO for APP-PRI
Invalid Sequence Number in KindCodeSet
Invalid Sequence Number in GenerateTargetId
Invalid Length for SN
SN Length Over Max Size
Kind Code not valid for this Time Period
Attempt to Apply Pattern that was not Parsed
Failed to Convert Year Group
Failed to Convert Sequence Number Group
Country Code not Defined
Document Date not Defined
Kind Code not Defined
Illegal Country Code for APP-PRI
DM found in raw id, using XH country
Using Default Country Pattern
Country Code Replaced
Year indication from date field
Sequence number adjusted to
Kind Code Relation not Allowed
Failed to Define TargetId. RawId used instead
No Kind Code or Generation Format Defined
No Date Found. Trigger lookup
Date Lookup Did not Find Anything
Year Replacement Failed. No Date Defined in the Input
Year Defined in Target Format, but no Date Defined
Document Found in DB
Kind code replaced by preferred lookup value
Kind code replaced but not with first preferred lookup
value
Lookup found values which are not in preferred list
Kind code lookup did not find anything
Lookup for kind codes with date contains more than one
value
Lookup found documents which are not in preferred list
Invalid date
format
Page 104
Invalid date format
Kind code lookup without date found values
No Kindcode format defined, kindcode first char matches
a valid kindcode
No Kindcode format defined, kindcode matches a valid
kindcode
BRE003
BRE004
BRE005
BRE006
BRE007
BRE008
BRE009
BRE010
BRE011
BRE012
BRE013
BRE014
BRE015
BRE016
BRW001
BRW002
BRW003
BRW004
BRW005
BRW006
BRW007
BRW008
BRW009
BRW010
BRW011
BRW012
BRW013
BRW014
BRW015
BRW016
BRW017
BRW018
BRW019
BRW020
BRW021
BRW022
BRW023
BRW024
BRW026
BRW027
BRW028
BRW030
BRW031
BRW032
Non-confidential
September 2014
GET http://ops.epo.org/rest-services/[service]/
[reference-type]/input-format: docdb or epodoc or
original -- which ever format corresponds with your input =>/input:
e.g. EP1000000.A1 or EP.1000000.* or
BY1%20202345.*.20090622/output-format: docdb or epodoc or
original
Table 20
In the request structure, bold means mandatory.
Generic request example:

GET http://ops.epo.org/rest-services/number-service/publication/docdb/EP.1000000/epodoc
POST http://ops.epo.org/rest-services/number-service/
publication/docdb/epodoc
Request Body: EP.1000000
Non-confidential
Page 105
September 2014
Generic response structure:
Figure 31
Below you will find various number-service request examples and responses.
Non-confidential
Page 106
3.3.1.
September 2014
From docdb to epodoc
GET http://ops.epo.org/rest-services/numberservice/application/docdb/MD.20050130.A.20050130/epodoc
POST http://ops.epo.org/rest-services/numberservice/application/docdb/epodoc
Request Body: MD.20050130.A.20050130
Response:
<?xml-stylesheet type="text/xsl" href="/style/numbers.xsl"?>
<ops:world-patent-data xmlns:ops="http://ops.epo.org" xmlns="http://www.epo.org/exchange">
<ops:meta name="version:docdb/epodoc" value="2010.03.19"/>
<ops:standardization inputFormat="docdb" outputFormat="epodoc">
<ops:input>
<ops:application-reference>
<country>MD</country>
<kind>A</kind>
<date>20050130</date>
</document-id>
</ops:application-reference>
</ops:input>
<ops:output>
<country>MD</country>
<date>20050130</date>
</document-id>
</ops:output>
</ops:standardization>
Non-confidential
Page 107
3.3.2.
September 2014
From original to docdb (JPO example)
GET http://ops.epo.org/rest-services/numberservice/application/original/JP.(2006-147056).A.20060526/docdb
POST http://ops.epo.org/rest-services/numberservice/application/original/docdb
Request Body: JP.2006-147056.A.20060526
Response:
<ops:meta name="status" value="SUCCESS"/>
<ops:meta name="version" value="10.09.93"/>
<ops:standardization inputFormat="original" outputFormat="docdb">
<ops:input>
<doc-number>2006-147056</doc-number>
<kind>A</kind>
<date>20060526</date>
</document-id>
</ops:input>
<ops:output>
<kind>A</kind>
<date>20060526</date>
</document-id>
</ops:output>
Non-confidential
Page 108
3.3.3.
September 2014
From docdb to original (JPO example)
GET http://ops.epo.org/rest-services/numberservice/application/docdb/JP.2006147056.A.20060526/original
POST http://ops.epo.org/rest-services/numberservice/application/docdb/original
Request Body: JP.2006147056.A.20060526
Response:
<ops:meta name="status" value="SUCCESS"/>
<ops:standardization inputFormat="docdb" outputFormat="original">
<ops:input>
<kind>A</kind>
<date>20060526</date>
</document-id>
</ops:input>
<ops:output>
<doc-number>2006-147056</doc-number>
<kind>A</kind>
<date>20060526</date>
</document-id>
</ops:output>
Non-confidential
Page 109
3.3.4.
September 2014
From original to epodoc (USPTO example)
GET http://ops.epo.org/rest-services/numberservice/application/original/US.(08/921,321).A.19970829/epodoc
POST http://ops.epo.org/rest-services/numberservice/application/original/epodoc
Request Body: US.(08/921,321).A.19970829
Note, in this case it is not possible to remove the brackets in the POST request because
of the comma that is part of the input but is also used to separate input references in the
request body.
Response:
<ops:meta name="version:docdb/epodoc" value="2010.03.19"/>
<ops:meta name="version:original/docdb" value="10.09.93"/>
<ops:standardization inputFormat="original" outputFormat="epodoc">
<ops:input>
<doc-number>08/921,321</doc-number>
<kind>A</kind>
<date>19970829</date>
</document-id>
</ops:input>
<ops:output>
<date>19970829</date>
</document-id>
</ops:output>
Non-confidential
Page 110
3.3.5.
September 2014
From epodoc to original
For certain authorities, the conversion of application/priority numbers into DOCDB or

EPODOC formats may lead to loss of essential information necessary to convert back
these numbers into the original format. For this reason we suggest to use the
conversion service from from DOCDB or EPODOC into original format for
application/priority numbers with caution as it may lead to erroneous results
3.3.6.
From original to docdb (PCT example)
GET http://ops.epo.org/rest-services/numberservice/application/original/(PCT/GB02/04635).20021011/docdb
POST http://ops.epo.org/rest-services/numberservice/application/original/docdb
Request Body: PCT/GB02/04635.20021011
Response:
<ops:meta name="status" value="BRW001 BRW003 BRW007 BRW006"/>
<ops:standardization inputFormat="original" outputFormat="docdb">
<ops:input>
<doc-number>PCT/GB02/04635</doc-number>
<date>20021011</date>
</document-id>
</ops:input>
<ops:output>
<country>GB</country>
<kind>W</kind>
<date>20021011</date>
</document-id>
Non-confidential
Page 111
September 2014
</ops:output>
Note, please refer to Chapter 4.4 - Expressing PCT application numbers in docdb
format for further information on the PCT format.
Non-confidential
Page 112
September 2014
3.1
3.2
Family service
3.3
Number-service
3.4
Register service
3.5
Legal service
3.6
___________________________________________________________ top of document
3.4.
Register service
The European Patent Register is the place where the EPO stores all the publicly
available information on published European patent applications and international PCT
applications designating the EPO as they pass through the grant procedure. OPS
provides the interface for the European Patent Register online service. On this page,
www.epo.org/searching/free/register/documentation.html you will find the technical
documentation and an explanation of the tags.
The output of the register service is part of the reg namespace and defined in the
rplus.xsd schema file.
GET http://ops.epo.org/restservices/register/reference-type e.g. publication or

application or priority/input-format e.g. epodoc/]input
e.g. EP1000000 or EP1000000.A1 or ...
Accept: application/register+xml
Non-confidential
Page 113
3.4.1.
September 2014
Register retrieval
Request structure:
GET http://ops.epo.org/rest-services/register/reference-type:
publication or application or priority/input-format:epodoc/input
e.g. EP99203729
Note, register service only supports the epodoc input format.
The register retrieval result can be influenced by using constituents to modify what you
will get in your responses:
Constituent
biblio
Delivers
procedural-steps
the data fields that have occurred during

the granting procedure of the requested application; only
relevant for register service
events
the information about actions that have taken place during the
life of the patent application; only relevant for register service
bibliographic data
Table 21
Note, the default behaviour of the register retrieval is biblio so you don't have to add
the biblio constituent if you want to retrieve only bibliographic data.
Non-confidential
Page 114
September 2014
Register data without constituents (default: biblio)

Request:
GET http://ops.epo.org/restservices/register/application/epodoc/EP99203729
POST http://ops.epo.org/restservices/register/application/epodoc/biblio
Response:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><?xml-stylesheet
type='text/xsl' href='/style/rplus.xsl' ?>
xmlns:reg="http://www.epo.org/register"
xmlns:cpc="http://www.epo.org/cpcexport">
<ops:meta value="1825" name="elapsed-time"/>
<ops:register-search total-result-count="1">
<ops:query syntax="CQL">publication=EP1000000</ops:query>
<reg:register-documents produced-by="RO">
<reg:register-document status="NO OPPOSITION FILED WITHIN TIMELIMIT"
produced-by="RO"
lang="en" dtd-version="1.0" date-produced="20110510">
<reg:bibliographic-data status="NO OPPOSITION FILED WITHIN
TIMELIMIT" lang="en"
id="EP99203729P" country="EP">
<reg:publication-reference change-gazette-num="2000/20">
<reg:document-id lang="en">
<reg:country>EP</reg:country>
<reg:doc-number>1000000</reg:doc-number>
<reg:kind>A1</reg:kind>
<reg:date>20000517</reg:date>
</reg:document-id>
</reg:publication-reference>
<reg:kind>B1</reg:kind>
Non-confidential
Page 115
September 2014
</reg:document-id>
<reg:classifications-ipcr change-gazette-num="2000/20">
<reg:classification-ipcr id="CLASSIFICATION_1">
<reg:text>B28B5/02, B28B7/00, B28B1/29</reg:text>
</reg:classification-ipcr>
</reg:classifications-ipcr>
<reg:application-reference change-gazette-num="2000/20">
<reg:document-id>
</reg:document-id>
</reg:application-reference>
<reg:language-of-filing>nl</reg:language-of-filing>
<reg:priority-claims change-gazette-num="2000/20">
<reg:priority-claim sequence="1" kind="national">
<reg:country>NL</reg:country>
</reg:priority-claim>
</reg:priority-claims>

<reg:designation-of-states change-gazette-num="2000/20">
<reg:designation-pct>
<reg:regional>
<reg:region>
</reg:region>
<reg:country>AT</reg:country>

</reg:regional>
</reg:designation-pct>
</reg:designation-of-states>
<reg:invention-title change-gazette-num="2000/20"
lang="en">Apparatus for manufacturing
green bricks for the brick manufacturing
industry</reg:invention-title>

<reg:term-of-grant change-gazette-num="2008/17">
<reg:lapsed-in-country>
<reg:country>AT</reg:country>
</reg:lapsed-in-country>

</reg:term-of-grant>

<reg:dates-rights-effective>
<reg:request-for-examination>
</reg:request-for-examination>
<reg:first-examination-report-despatched>
</reg:first-examination-report-despatched>
</reg:dates-rights-effective>
Non-confidential
Page 116
September 2014
<reg:references-cited>
<reg:citation office="EP" cited-phase="search" id="cit_1">
<reg:patcit
url="http://v3.espacenet.com/textdoc?
DB=EPODOC&IDX=EP0680812&CY=EP">
<reg:document-id>
</reg:document-id>
</reg:patcit>
<reg:category>A</reg:category>
</reg:citation>
<reg:patcit
DB=EPODOC&IDX=NL9400663&CY=NL">
<reg:document-id>
<reg:country>NL</reg:country>
</reg:document-id>
</reg:patcit>
</reg:citation>
<reg:patcit
DB=EPODOC&IDX=DE3546191&CY=DE">
<reg:document-id>
<reg:country>DE</reg:country>
</reg:document-id>
</reg:patcit>
</reg:citation>
</reg:references-cited>
<reg:opposition-data change-gazette-num="2004/06">
<reg:opposition-not-filed>
</reg:opposition-not-filed>
</reg:opposition-data>
<reg:search-reports-information>
<reg:search-report-information change-gazette-num="2000/20"
declaration-of-no-search="not-determined" searchtype="national" office="EP">
<reg:search-report-publication>
</reg:document-id>
</reg:search-report-publication>
</reg:search-report-information>
</reg:search-reports-information>
</reg:bibliographic-data>
Non-confidential
Page 117
September 2014
</reg:register-document>
</reg:register-documents>
</ops:register-search>
Register data with events

Request:
GET http://ops.epo.org/restservices/register/application/epodoc/EP99203729/events
POST http://ops.epo.org/restservices/register/application/epodoc/events
Non-confidential
Page 118
September 2014
Response:
<ops:query syntax="CQL">application=EP99203729</ops:query>
produced-by="RO"
<reg:events-data>
<reg:dossier-event event-type="new" id="EVT_28">
<reg:event-date>
</reg:event-date>
<reg:event-code>0009012</reg:event-code>
<reg:event-text event-text-type="DESCRIPTION">Publication in
section I.1 EP
Bulletin</reg:event-text>
<reg:gazette-reference>
<reg:gazette-num>2000/20</reg:gazette-num>
</reg:gazette-reference>
</reg:dossier-event>
</reg:events-data>
<reg:events-data>
<reg:event-date>
</reg:event-date>
<reg:event-code>0009199FREP</reg:event-code>
<reg:event-text event-text-type="DESCRIPTION">Change representative</reg:event-text>
</reg:events-data>

Non-confidential
Page 119
September 2014
Register data with procedural-steps

Request:
GET http://ops.epo.org/restservices/register/application/epodoc/EP99203729/proceduralsteps
POST http://ops.epo.org/restservices/register/application/epodoc/procedural-steps
Non-confidential
Page 120
September 2014
Response:
produced-by="RO"
<reg:procedural-data>
<reg:procedural-step procedure-step-phase="undefined"
id="RENEWAL_5">
<reg:procedural-step-code>RFEE</reg:procedural-step-code>
<reg:procedural-step-text step-texttype="STEP_DESCRIPTION">Renewal fee
payment</reg:procedural-step-text>
<reg:procedural-step-text step-texttype="YEAR">03</reg:procedural-step-text>
<reg:procedural-step-date step-date-type="DATE_OF_PAYMENT">
</reg:procedural-step-date>
</reg:procedural-step>
id="RENEWAL_6">
<reg:procedural-step procedure-step-phase="examination"
id="STEP_IGRA_3">
<reg:procedural-step-code>IGRA</reg:procedural-step-code>
<reg:procedural-step-text step-texttype="STEP_DESCRIPTION">Intention to grant the
patent</reg:procedural-step-text>
<reg:procedural-step-date step-date-type="DATE_OF_DISPATCH">
<reg:procedural-step-date step-date-type="GRANT_FEE_PAID">
<reg:procedural-step-date step-date-type="PRINT_FEE_PAID">
Non-confidential
Page 121
September 2014
id="STEP_AGRA_3">
<reg:procedural-step-code>AGRA</reg:procedural-step-code>
<reg:procedural-step-text step-texttype="STEP_DESCRIPTION">Announcement of grant (old
EPC before 1 July 2002)</reg:procedural-step-text>
<reg:procedural-step-text step-texttype="approval">yes</reg:procedural-step-text>
<reg:procedural-step-date step-date-type="DATE_OF_DISPATCH">
id="STEP_PROL_3">
<reg:procedural-step-code>PROL</reg:procedural-step-code>
<reg:procedural-step-text step-texttype="STEP_DESCRIPTION">Language of the
procedure</reg:procedural-step-text>
<reg:procedural-step-text step-text-type="procedure language"
>en</reg:procedural-step-text>
</reg:procedural-data>
Non-confidential
Page 122
September 2014
Register data with biblio, events and procedural-steps

Request:
GET http://ops.epo.org/restservices/register/application/epodoc/EP99203729/biblio,events,p
rocedural-steps
POST http://ops.epo.org/restservices/register/application/epodoc/biblio,events,proceduralsteps
Response:
produced-by="RO"
<reg:bibliographic-data status="NO OPPOSITION FILED WITHIN
TIMELIMIT" lang="en"
id="EP99203729P" country="EP">
</reg:document-id>
Non-confidential
Page 123
September 2014
<reg:kind>B1</reg:kind>
</reg:document-id>

<reg:procedural-data>
id="RENEWAL_7">

</reg:procedural-data>
<reg:events-data>
<reg:event-date>
</reg:event-date>
<reg:event-code>0009012</reg:event-code>
<reg:event-text event-text-type="DESCRIPTION">Publication in
section I.1 EP
Bulletin</reg:event-text>
</reg:events-data>

Non-confidential
Page 124
3.4.2.
September 2014
Register search
Use this service to find specific register data -- that is part of the public aspect of the
patent lifecycle.
The OPS register service uses the same search operators, input/output formats and
CQL identifiers as the European Patent Register online service. It is advisable to have
a look at the search query information to understand how to construct a query. Note,
these CQL identifiers are for the Register service only. Do not use the CQL details for
Published-data service.
Request structure:
GET http://ops.epo.org/rest-services/register/search/?q=[QUERY
STRING]
Request example:
GET http://ops.epo.org/rest-services/register/search/?q=pa
%3DIBM
POST http://ops.epo.org/rest-services/register/search
Request Body: q=pa%3DIBM
Response:
Note, that the response has 763 applications containing "International Business
Machines" as applicant, contains a shorter version of biblio data than retrieval:
<ops:query syntax="CQL">pa=IBM</ops:query>
Non-confidential
Page 125
September 2014
<reg:register-document>
<reg:bibliographic-data>
<reg:publication-reference>
<reg:document-id>
<reg:country>WO</reg:country>
</reg:document-id>
<reg:classifications-ipcr>
<reg:classification-ipcr sequence="CLASSIFICATION_1">
<reg:text>H04N5/235</reg:text>
</reg:classification-ipcr>
</reg:classifications-ipcr>
<reg:application-reference>
<reg:document-id>
</reg:document-id>
</reg:application-reference>
<reg:parties>
<reg:applicants>
<reg:applicant app-type="applicant">
<reg:addressbook>
<reg:name>International Business Machines
Corporation</reg:name>
</reg:addressbook>
</reg:applicant>
</reg:applicants>
</reg:parties>

Range control
The default range of the register search response is 1-25. It can be changed by
specifying an HTTP header parameter Range=[begin_range-end_range].
For test purposes, it is also possible to use the range query parameter by adding
http://ops.epo.org/rest-services/register/search/?q=pa
%3DIBM&Range=1-10).
Non-confidential
Page 126
September 2014
Request Example
GET http://ops.epo.org/rest-services/register/search/?q=pa%3DIBM
Range: 1-10
<ops:query syntax="CQL">pa=IBM</ops:query>
Non-confidential
Page 127
September 2014
3.1
3.2
Family service
3.3
Number-service
3.4
Register service
3.5
Legal service
3.6
___________________________________________________________ top of document
3.5.
Legal service
This service retrieves the legal data of the patent lifecycle, including the register domain
of the patent.
Generic Request structure:

GET http://ops.epo.org/rest-services/
legal/reference-type/input-type
Note, bold means mandatory.
Non-confidential
Page 128
September 2014
Response structure:
Figure 32
ops_legal.xsd schema file.
Request example:
GET http://ops.epo.org/restservices/legal/publication/docdb/EP.1000000.A1
Non-confidential
Page 129
September 2014
POST http://ops.epo.org/rest-services/legal/publication/
docdb
Response example:
<kind>A1</kind>
</document-id>
<ops:family-member family-id="19768124">
<kind>A1</kind>
<date>20000517</date>
</document-id>
<date>20000517</date>
</document-id>
<application-reference doc-id="17397285" is-representative="YES">
<kind>A</kind>
<date>19991108</date>
</document-id>
<kind>A</kind>
<date>19981112</date>
</document-id>
<priority-active-indicator>YES</priority-active-indicator>
Non-confidential
Page 130
September 2014
</priority-claim>
<ops:legal code="AK
" desc="DESIGNATED CONTRACTING STATES:" infl="+"
dateMigr="00010101">
<ops:pre line="00001">EP
99203729A 2000-05-17AK
+DESIGNATED
CONTRACTING STATES: Kind Code of Ref Document A1</ops:pre>
99203729A 2000-05-17AK
+DESIGNATED
CONTRACTING STATES: Designated State(s) AT BE CH CY DE DK ES FI FR GB GR IE
IT LI LU MC NL PT SE</ops:pre>
<ops:L001EP desc="Country Code">EP</ops:L001EP>
99203729</ops:L003EP>
<ops:L004EP desc="Kind Code">A</ops:L004EP>
<ops:L008EP desc="Legal Event Code 1">AK</ops:L008EP>
<ops:L500EP>
<ops:L506EP desc="Kind Code of Ref Document">A1</ops:L506EP>
<ops:L507EP desc="Designated State(s)">AT BE CH CY DE DK ES FI FR GB
GR IE IT LI LU MC NL PT SE</ops:L507EP>
</ops:L500EP>
</ops:legal>
<ops:legal code="AX
" desc="EXTENSION OF THE EUROPEAN PATENT TO"
infl="+" dateMigr="00010101">
99203729A 2000-05-17AX
+EXTENSION OF
THE EUROPEAN PATENT TO Free Format Text AL;LT;LV;MK;RO;SI</ops:pre>
<ops:L001EP desc="Country Code">EP</ops:L001EP>
99203729</ops:L003EP>
<ops:L004EP desc="Kind Code">A</ops:L004EP>
<ops:L008EP desc="Legal Event Code 1">AX</ops:L008EP>
<ops:L500EP>
<ops:L510EP desc="Free Format Text">AL;LT;LV;MK;RO;SI</ops:L510EP>
</ops:L500EP>
</ops:legal>

Non-confidential
Page 131
September 2014
3.1
3.2
Family service
3.3
Number-service
3.4
Register service
3.5
Legal service
3.6
___________________________________________________________ top of document
3.6.
Classification services
Since January 2013 the European Patent Office, in partnership with the US patent
office, classifies and delivers data using the Cooperative Patent Classification.
The 3.0 implementation of the OPS service retrieves the Cooperative classification
(CPC) scheme data.
CPC is divided into eight sections (A-H) that are sub-divided into classes, sub-classes,
groups and sub-groups. As part of the official CPC, OPS allows to access the so-called
Y indexes. These are subclasses, which relate to specific clean energy technologies,
namely Y02C (greenhouse gases- capture and storage/sequestration or disposal) and
Y02E (greenhouse gases - emissions reduction technologies related to energy
generation, transmission or distribution). You can find more information to these indexes
here: http://www.epo.org/news-issues/issues/classification/classification.html.
Generic Request structure:
GET http://ops.epo.org/rest-services/classification/cpc/
[classification-symbol]?query-string
Accept: application/xml
POST http://ops.epo.org/rest-services/classification/cpc/
Accept: application/cpc+xml
Request Body: A01B
Note, bold means mandatory.
Non-confidential
Page 132
September 2014
Response structure:
Figure 33
The structure shown in Figure 33 is part of the cpc namespace and defined in the
CPCSchema.xsd schema file.
The classification response is ops:classification-scheme.
3.6.1.
CPC Retrieval
Note, for more general information on the Cooperative Classification, please refer
to: http://www.cooperativepatentclassification.org
Non-confidential
Page 133
September 2014
Valid Query-string parameters in the CPC service

Query-string
Description
depth
Determines how many children elements

should be included in the response
ancestors
Includes symbols above the requested

element
navigation
Includes navigation symbols next &

previous in the response
Retrieval by specifying the complete classification symbol:

GET http://ops.epo.org/rest-services/classification/
cpc/[classification-symbol]
Retrieval of a specific number of child levels
The depth parameter is used to specify how many levels of children of the requested
symbol should be included into the response.
Note, requesting "depth" > 1 (more than one) or "all" is allowed only if the requested
symbol belongs to a level > 5.
GET http://ops.epo.org/rest-services/classification/
cpc/[classification-symbol]?depth=x
Note, x = numeric value or "all" for the retrieval of all children of the given classification.
Below are examples for retrieving classifications.
Request for classification A:
GET http://ops.epo.org/rest-services/classification/cpc/A
POST http://ops.epo.org/rest-services/classification/cpc
Non-confidential
Page 134
September 2014
Request Body: A
Response (which returns the top level of classification A, 'Human Necessities'.):
xmlns:xlink="http://www.w3.org/1999/xlink"
<ops:classification-scheme>
<ops:cpc>
<cpc:class-scheme scheme-type="cpc" export-date="2012-10-13">
<cpc:classification-item level="2" additional-only="false"
sort-key="A" not-allocatable="false" breakdown-code="false" daterevised="2012-10-12" link-file="classification/cpc/A">
<cpc:classification-symbol>A</cpc:classification-symbol>
<cpc:class-title date-revised="2012-10-12">
<cpc:title-part>
<cpc:text scheme="ipc">HUMAN
NECESSITIES</cpc:text>
</cpc:title-part>
</cpc:class-title>
</cpc:classification-item>
</cpc:class-scheme>
</ops:cpc>
</ops:classification-scheme>
Request for the tenth level of the A classification which signifies 'Thermally sensitive
initiators':
GET http://ops.epo.org/rest-services/classification/cpc/A62C37/48
POST http://ops.epo.org/rest-services/classification/cpc
Request Body: A62C37/48
Response example
<ops:cpc>
Non-confidential
Page 135
September 2014

<cpc:classification-item level="10" additional-only="false"
sort-key="A62C37/48" not-allocatable="false" breakdown-code="false" daterevised="2012-10-12" link-file="classification/cpc/A62C37/48">
<cpc:classificationsymbol>A62C37/48</cpc:classification-symbol>
<cpc:title-part>
<cpc:text scheme="ipc">Thermally sensitive
initiators</cpc:text>
</cpc:title-part>
</cpc:class-title>
</cpc:class-scheme>
</ops:cpc>
Request for the next and previous entries for classification A01:
GET http://ops.epo.org/rest-services/classification/cpc/A01?navigation
Response:
Non-confidential
Page 136
September 2014
<ops:cpc>
<ops:navigation>
<ops:prev xlink:href="classification/cpc/A">A</ops:prev>
<ops:next xlink:href="classification/cpc/A01B">A01B</ops:next>
</ops:navigation>
<cpc:classification-item level="4" additional-only="false" sortkey="A01" not-allocatable="false" breakdown-code="false" date-revised="201210-12" link-file="classification/cpc/A01">
<cpc:classification-symbol>A01</cpc:classification-symbol>
<cpc:title-part>
<cpc:text scheme="ipc">AGRICULTURE</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc"> FORESTRY</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc"> ANIMAL HUSBANDRY</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc"> HUNTING</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc"> TRAPPING</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc"> FISHING</cpc:text>
</cpc:title-part>
</cpc:class-title>
</cpc:class-scheme>
</ops:cpc>
Request for the ancestors and navigation items classification A01:

GET http://ops.epo.org/rest-services/classification/cpc/A01?
navigation&ancestors
Non-confidential
Page 137
September 2014
Response:
<ops:cpc>
<ops:navigation>
<ops:prev xlink:href="classification/cpc/A">A</ops:prev>
<ops:next xlink:href="classification/cpc/A01B">A01B</ops:next>
</ops:navigation>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
</cpc:class-title>
</cpc:class-scheme>
</ops:cpc>
Non-confidential
Page 138
September 2014
Request for all children one level below classification A:

GET http://ops.epo.org/rest-services/classification/cpc/A?depth=1
POST http://ops.epo.org/rest-services/classification/cpc/?depth=1
Request Body: A
Response:
<ops:cpc>
<cpc:classification-item level="2" additional-only="false" sortkey="A" not-allocatable="false" breakdown-code="false" date-revised="201210-12" link-file="classification/cpc/A">
<cpc:classification-symbol>A</cpc:classification-symbol>
<cpc:title-part>
<cpc:text scheme="ipc">HUMAN NECESSITIES</cpc:text>
</cpc:title-part>
</cpc:class-title>
<cpc:title-part>
<cpc:text scheme="ipc">Agriculture</cpc:text>
</cpc:title-part>
</cpc:class-title>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
Non-confidential
Page 139
September 2014

</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
<cpc:title-part>
</cpc:title-part>
</cpc:class-title>
<cpc:meta-data>+</cpc:meta-data>
<cpc:meta-data>+</cpc:meta-data>

</cpc:class-scheme>
</ops:cpc>
Non-confidential
Page 140
3.6.2.
September 2014
CPC Media retrieval
With the OPS classification service it is possible to retrieve CPC media referenced in
the classification text in the format specified.
Request structure:
GET http://ops.epo.org/rest-services/classification/cpc/media/
[image-name]
Accept: [see list of accepted media formats below]
The media name and type can be extracted from the CPC retrieval response.
List of accepted media formats :
Format
Media type
GIF
image/gif
JPEG
image/jpeg
TIF
image/tif
BMP
image/x-ms-bmp
PNG
image/png
WAV
audio/wav
WMA
audio/x-ms-wma
WMV
video/x-ms-wmv
MP3
audio/mpeg
UNKNOWN
type/x-unknown
Example
Use the classification retrieval service, extract the media name and type from the
response (e.g. A01N37/12 symbol):
<ops:cpc>
<cpc:classification-item level="8" additional-only="false" sortkey="A01N37/12" not-allocatable="false" breakdown-code="false" daterevised="2012-10-12" link-file="classification/cpc/A01N37/12">
Non-confidential
Page 141
September 2014
<cpc:classification-symbol>A01N37/12</cpc:classification-symbol>
<cpc:title-part>
<cpc:text scheme="ipc">containing the group <cpc:media
id="classification/cpc/media/100.gif" type="gif"/>, wherein Cn means a
carbon skeleton not containing a ring</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc"> Thio analogues thereof</cpc:text>
</cpc:title-part>
</cpc:class-title>
</cpc:class-scheme>
</ops:cpc>
Request example:
GET http://ops.epo.org/restservices/classification/cpc/media/100.gif
Accept: image/gif
Response: the image in the GIF format will be in response
3.6.3.
CPC Search
Search for keywords in the Cooperative classifications.

If you dont know the name of the CPC symbol you are looking for, you can use the
CPC search service to identify possible interesting CPC symbols by searching for
keywords in the title and abstract fields of the Espacenet database.
The result will be a list of CPC classes, each showing a percentage value. The higher
the percentage value, the most likely it is that the CPC class corresponds to the concept
searched.
By default, only the first 10 CPC classes with the highest percentage value are shown.
The CPC search basically uses the same CQL syntax as the biblio search but is
restricted to titles and abstracts only.
Request structure:
GET http://ops.epo.org/restservices/classification/cpc/search/?q=[QUERY STRING]
Non-confidential
Page 142
September 2014
Response structure:
Figure 34:
Non-confidential
Page 143
September 2014
Request example:
GET http://ops.epo.org/restservices/classification/cpc/search/?q=chemistry
POST http://ops.epo.org/rest-services/classification/cpc/search
Request Body: chemistry
Note, as the CPC search is restricted to the title and abstract, you dont have to provide
the index name (titleandabstract) in your query. However,
q=titleandabstract%3Dchemistry can also be used and results in the same
response.
Response:
<ops:classification-search total-result-count="10" scheme-type="cpc">
<ops:query syntax="CQL">titleandabstract = chemistry</ops:query>
<ops:search-result>
<ops:classification-statistics classification-symbol="A61B10/00"
percentage="2.8985507">
<cpc:title-part>
<cpc:text scheme="ipc">
Other methods or instruments for diagnosis, e.g. instruments for taking a
cell sample, for biopsy, for vaccination diagnosis
</cpc:text>
<cpc:explanation>
vaccination prophylaxis, vaccination therapy
<cpc:class-ref scheme="cpc">A61B17/20</cpc:class-ref>
</cpc:text>
</cpc:explanation>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc">Sex determination</cpc:text>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc">Ovulation-period determination</cpc:text>
<cpc:explanation>
Non-confidential
Page 144
September 2014
menstruation tables
<cpc:class-ref scheme="cpc">G06C3/00</cpc:class-ref>
</cpc:text>
</cpc:explanation>
</cpc:title-part>
<cpc:title-part>
<cpc:text scheme="ipc">Throat striking implements</cpc:text>
</cpc:title-part>
</cpc:class-title>
</ops:classification-statistics>

</ops:search-result>
</ops:classification-search>
Range control
You can specify the number of search results you want to receive using the Range
parameter. The default range of the CPC search response is 1-10. It can be changed by
specifying an HTTP header parameter X-OPS-Range=[begin_range-end_range].
For the same purposes, it is also possible to use the range query parameter by adding
http://ops.epo.org/rest-services/classification/cpc/search/?
q=chemistry&Range=1-5).
Example Request
GET http://ops.epo.org/restservices/classification/cpc/search/?q=chemistry
X-OPS-Range: 1-5
Response
<ops:classification-search total-result-count="5" scheme-type="cpc">
<ops:query syntax="CQL">titleandabstract = chemistry</ops:query>

3.6.4.
Classification Mapping service
This service converts ECLA and CPC symbols to the corresponding symbols of the
different classifications. Following conversion directions are supported :
Input format
Output format
Non-confidential
Page 145
ECLA
September 2014
CPC
IPC
CPC
ECLA
IPC
Request structure
GET http://ops.epo.org/rest-services/classification/map/[inputformat]/[classification-symbol]/[output-format]
Note: The service accepts only 'full' classification symbols, starting from Main group,
like a01b1/00.
Response structure
Figure 35:
Non-confidential
Page 146
September 2014
Example Request
GET http://ops.epo.org/restservices/classification/map/ecla/A61K9/00/cpc
Response
<ops:mappings inputSchema="ecla" outputSchema="cpc">
<ops:mapping additional-only="false">
<ops:ecla>A61K9/00</ops:ecla>
<ops:cpc xlink:href="classification/cpc/A61K9/00">A61K9/00</ops:cpc>
</ops:mapping>
</ops:mappings>
Note: The CPC to ECLA transformation can be ambiguous and it's not possible to
determine automatically for some cases what kind of output is required (INVENTION or
ADDITIONAL). To resolve that kind of ambiguity there is a optional request parameter
additional exist in order to specify that additional classification symbol transformation is
requested. The default request (without additional parameter specified) is invention type
request.
Example Request
GET http://ops.epo.org/restservices/classification/map/cpc/A01D2085/008/ecla?additional
Response
<ops:mappings inputSchema="cpc" outputSchema="ecla">
<ops:mapping additional-only="true">
<ops:ecla>K01D85/00F2</ops:ecla>
<ops:cpc
xlink:href="classification/cpc/A01D2085/008">A01D2085/008</ops:cpc>
</ops:mapping>
</ops:mappings>
Non-confidential
Page 147
4.
September 2014
APPENDIX
4.1
Relevant acronyms and abbreviations
4.2
CQL index catalogue
4.3
The epodoc publication format
4.4
Expressing PCT application numbers in docdb format
4.5
Number-service Use Cases
___________________________________________________________ top of document
4.1.
Relevant acronyms and abbreviations
Abbreviation or acronym
CQL
Description
Contextual or Common Query Language
DTD
Document Type Definition
ECLA
European Classification system
HTTP
Hypertext Transfer Protocol
IPCdigit
International Patent Classification, digit-th

release (if skipped, 8th is assumed)
MIME
Multipurpose Internet Mail Extensions
PNG
Portable Network Graphics
REST
Representational State Transfer
ST.36
WIPO Standard 36: Processing of patent

information using XML
TIFF
Tagged Image File Format
W3C
World Wide Web Consortium
WADL
Web Application Description Language
WS-term
A term in context of the Web Services

(Architecture)
XML
Extensible Markup Language
XSD
XML Schema Definition
Table 22
Non-confidential
Page 148
4.2.
September 2014
CQL index catalogue
The following is a guide for using CQL in published-data service bibliographic search.
Note, CQL details in this section ARE NOT VALID for Register service (see the CQL
details for Register search in section 3.4.2)
CQL usage in OPS can be summarised in the following statements:
1. A CQL query is either a search clause or multiple search clauses connected by a
Boolean operator.
2. A search clause consists of an index, relation and search term or a search term
alone, where both might be enclosed within parentheses.
3. If the index is missing then the search clause must not have the relation, it is either
both of them or none of them.
4. If the index and a relation is missing then an equality relation is assumed and the
index is determined based on the following rules:
If a search term is a 2 letter ISO country code, the num index is assumed.
If a search term matches one of the following date formats: yyyy, yyyyMM,
yyyyMMdd or dd/MM/yyyy then the pd index is assumed. The 4-digits year
(yyyy) is assumed to be within the range 1800-2999, both a month number
(MM) and a day number (dd) are having leading zero if necessary.
If a search term matches one of the following patterns: x, xdd, xddw, xddwd,
xddwdd, xddwdd/h, the cl index is assumed: x refers to one letter (either upper or lower case) of a classification group within the range a-h or y, d is a digit, w refers to any alphanumeric character and h is a hexadecimal number up
to 6 digit long.
If a search term matches \\w{2,4}\\d{1,}[a-zA-Z]?\\d? or is composed
of digits only, then the num index is assumed.
If a search term is composed of letters only, then the ia index is assumed
txt index is assumed.
5. A relation means either:
an equality relation which exact definition varies depend on a kind of a search
term and index:
o when index values fall within the range (like publication date) and search
term is a list of exactly 2 words it is assumed that equality relation is
within relation,
o otherwise, equality means that index value and search term are
identical,
an order relation for comparable terms: less (<), greater (>), equal (=), less or
Non-confidential
Page 149
September 2014
equal (<=), greater or equal (>=), not equal (<>),
an relational qualifier (=/low, =/high, =/same) can be used with CPC classification indices only,
an occurrence relation on search term which is a list of words:

o for a terms which are list of exactly 2 words with values that fall within
the range, like dates or numerical values, where words are respectfully
the beginning and the end of a range,
o any or all relation for a terms which are list of words, where any means
any of these words and all means all of these words,
6. A search term is either a single word or a list of words enclosed within double
quotes assumed to be separated by a comma or whitespace if the within operator is
used.
7. A word might contain truncation characters:
unlimited truncation (*) which represents a string of any length including any
character,
limited truncation (?) which represents any character or no character,
masking truncation (#) which represents any character which is mandatory
present,
it is possible to use truncation at the beginning of a word.
8. A word might contain a backslash character (\) used to escape itself (\\), parentheses
"$" or "$", hyphens (\-), quotas (\"), commas (\,) or truncation characters.
9. A Boolean operator is one of logical operators: and, or, not or a proximity
operator; mathematically, operator not is not an unary operator and should be
understood like "and not" in a common sense.
10. A proximity operator prox is either checking a co-occurrence of two search terms
in scope of a defined unit of text (word, sentence or paragraph) or checking the
distance between those two search terms with or without the respect of its order. Both
terms must be in scope of the same index.
11. Relation qualifiers (=/low, =/high, =/same) can only be used with singe CQL CPC
classification index and can be combined with the other CQL operators and qualifiers
within the same query.
Table 23
Non-confidential
Page 150
September 2014
Catalogue of supported CQL queries for OPS Published-data service

Since the information about publications is structured (see exchange document
structure in the Common response structures, section 2.2.2) the following catalogue of
CQL queries has been designed. The column titled 'Single correspondence', means
"corresponds to a single piece of information" or exactly one element from the exchange
document structure.
Index name
Description
title, ti
Single
correspondence?
yes
abstract, ab
yes
the publication abstract in English
titleandabstract, ta
no
the publication title or abstract in

English
inventor, in
yes
an inventor name
applicant, pa
yes
an applicant name
inventorandapplicant,
ia
publicationnumber, pn
no
a name of an inventor or an applicant
yes
the publication number in any format
spn
yes
the publication number in epodoc

format
applicantnumber, ap
yes
the application number in any format
sap
yes
the application number in epodoc

format
prioritynumber, pr
yes
the priority number
spr
yes
the priority number in epodoc format
num
no
the publication, application or a

priority number in any format
publicationdate, pd
yes
the publication date
citation, ct
yes
a cited document number
ex
yes
a cited document number during the

examination
Non-confidential
the publication title in English
Page 151
Index name
September 2014
Description
op
Single
correspondence?
yes
rf
yes
a cited document number provided by

the applicant
oc
yes
another cited document number
famn
yes
a simple family identifier
cpc, cpci, cpca
yes
ipc, ic
no
an CPC (invention and additional)

classification
any IPC1-8 class
ci
yes
IPC8 core invention class
cn
yes
IPC8 core additional class (noninvention)
ai
yes
IPC8 advanced invention class
an
yes
IPC8 advanced additional class (noninvention)
no
any IPC8 advanced class
no
any IPC8 core class
cl
no
an CPC or IPC1-8 class
txt
no
publication title or abstract, or

inventor/applicant name
a cited document number during the

opposition
Table 24
Non-confidential
Page 152
September 2014
CQL examples
The following examples illustrate the CQL usage in OPS. Please note, that some
special characters must be replaced when placed inside XML document, particularly the
'less than' symbol <, must be replaced with < (including the semicolon) and the
'greater than' symbol >, must become > (including the semicolon).
Query
ti all "green, energy"
Description of result
All publications where "green"
and "energy" are found
among all titles.
Since the ti index checks
title in all languages, it is
possible, but unlikely, that
one word will be found in
English title and another in
the German (etc.) title.
Rule
5c
ti=green prox/unit=world
ti=energy
All publications where a title

contains "green" and "energy"
together.
10
pd within "20051212
20051214"
pd="20051212 20051214"
All publications published 12,

13 or 14 December 2005
Same as above
5c, 6
ia any "John, Smith"
All publications with "John"

and/or "Smith" in the
applicant/inventor name
5c
pn=EP and pr=GB
All publications published by

EPO (EP country code in the
publication number) having a
priority document from United
Kingdom (GB country code in
the priority number)
1, 9
5a
ta=green prox/distance<=3 All publications having words

ta=energy
"green" and "energy" in either
title or abstract separated by
at most 3 words from each
other,
10
ta=green
All publications having a word
prox/distance<=2/ordered= "green" followed by a word
true ta=energy
"energy" in either title or
abstract separated by at most
2 words,
10
Non-confidential
Page 153
Query
Description of result
September 2014
Rule
(ta=green
All publications having either
prox/distance<=3
"green" or "renewable"
ta=energy) or
separated by at most 3 words
(ta=renewable
from a word "energy" in either
prox/distance<=3 ta=
title or abstract, in any order.
energy)
pa all "central,
All publications with a
intelligence, agency" and publication/application/priority
US
document issued by United
States (having a US country
code in a document number)
having "federal", "bureau",
"investigation" words in an
applicant name (see 4a)
1, 9, 10
pa all "central,
like above, published after
intelligence, agency" and 2000.
US and pd>2000
pd < 18000101
All publications published in
18th century.
1, 4, 5b, 5c, 9
ta=synchroni#ed
Allows to look for

"synchronized" or
"synchronised" word in
abstract/title
EP and 2009 and Smith
All publications with

application/publication/priority
document issued by EPO
(having EP country code),
published in 2009, having
Smith as an applicant or
inventor
1, 4, 9
cpc=/low A01B
App publications classified

with A01B and all subclasses
1, 4, 5c, 9
5b
Table 25
Non-confidential
Page 154
4.3.
September 2014
The epodoc publication format
The number is in this format: CCNNNNNNNNNNNN(K)

Key:
CC: an ISO two-letter country code
N(N...): can be up to 12 digits (EP is 7), NO spaces
(K): optional attached kind code one-letter
Example:
<date>20080423</date>
</document-id>
For kind code(K)is:
if it's A(followed by the number), letter A is never attached
if it's D(followed by the number) to Z(followed by the number), the first
letter is always attached:
if it's B(followed by the number) or C(followed by the number), the first
letter -- up to 2 characters for the kind code of a JP number can be attached, IF it is
necessary to differentiate documents belonging to overlapping series of numbers.
Examples:
JP2000177507 (docdb kind code A, is not "visible" in epodoc format)
JP3000014B2 (docdb kind code B2 is attached in epodoc format)
JP3000014B (different invention than the previous, docdb kind code B is attached in
epodoc format)
CN100520025C (docdb kind code C is attached in epodoc format)
DE6610524U (docdb kind code U is attached in epodoc format)
KR200142084Y (docdb kind code Y1, only Y is attached in epodoc format)
Non-confidential
Page 155
4.4.
September 2014
Expressing PCT application numbers in docdb format
The format has changed through the years:

- Until 1.1.2004: CCyynnnnnW
- After 1.1.2004: CCccyynnnnnnW
Key:
-
CC=country code, which references where the filing took place;

(Note, IB=International Buro.)
cc=century (20th) - this part was added from 1.1.2004 and onwards
yy=year
nnnnnn=sequential number (6 digits; 5 digits before 2004)
W= mandatory application kind code
Example:
PCT/GB02/04635 translates in docdb to GB 0204635 W
Please refer to the number-service section for an example on how to convert

PCT application numbers to docdb format.
Non-confidential
Page 156
4.5.
September 2014
Number-service Use Cases
As described in chapter 3.3, the number-service provides the functionality to transform

application, publication and priority numbers from one input format to
another format. The purpose of this chapter is to give you a "real life" example of when
and how to use this service.
As OPS provides access to data that is held inside the EPO, the OPS services (except
the number-service) require the input to be in one of the two EPO formats: epodoc or
docdb. The most common use case of the number-service is thus to transform numbers
that are given in domestic formats of different countries to the EPO formats that can
then be used for receiving published, family, register, legal or classification data.
Assuming the following scenario: starting with an original document for a specific patent
application, you want to receive data from OPS related to this document:
Figure 36
Non-confidential
Page 157
September 2014
As you can see there are three different numbers on the first page of this original
document:
1. Publication number (10): DE 10 2006 032 425 A1
2. Application number (21): 10 2006 032 425.0
3. Priority number (30): 11/183,143 US
Note, for a full list of the INID codes inside of patent documents, see the documentation
of the WIPO ST9.
The priority what other documents are related to it?

In our use case we want to receive family information for the priority of this
document.
To achieve this we have to first convert the given number in original format to the
docdb format:
GET http://ops.epo.org/rest-services/numberservice/priority/original/US.(11/183,143).20050714/docdb
Response:
Figure 37
The number service response includes the priority number in docdb format which can
then be used as input for the family service:
GET http://ops.epo.org/restservices/family/priority/docdb/US.18314305.A
Non-confidential
Page 158
September 2014
Response:
Figure 38
The family contains 6 members that claim the US priority.
Retrieving the bibliographic data for the German publication

A second use case is to retrieve the bibliographic data for the German publication
number (DE 10 2006 032 425 A1). To achieve this we again have to transform
the original number using the number-service. This time we request epodoc as the
output format:
GET http://ops.epo.org/rest-services/numberservice/publication/original/DE.(10 2006 032
425).A1.20070208/epodoc
Non-confidential
Page 159
September 2014
Response:
Figure 39
The publication number in epodoc format can then be used as input for the biblio
retrieval:
GET http://ops.epo.org/rest-services/publisheddata/publication/epodoc/DE102006032425/biblio
Response:
Figure 40
Note, this screenshot only shows the first part of the output.
Non-confidential
Page 160
4.6.
September 2014
Further reading
It is strongly recommended to review these resources to fully understand the concepts

and environment of OPS.
Web Application Description Language
http://www.w3.org/Submission/wadl/
HTTP protocol
http://www.w3.org/Protocols/rfc2616/rfc2616.html
W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
http://www.w3.org/TR/xmlschema11-1/
XML Schema Part 2: Datatypes Second Edition
http://www.w3.org/TR/xmlschema-2/
CQL: Common Query Language, Version 1.1
http://www.loc.gov/standards/sru/sru1-1archive/cql.html
RFC 6749 - The OAuth 2.0 Authorization Framework
http://tools.ietf.org/html/rfc6749
top of document
Non-confidential
Page 161

OPS v3.1 Documentation Version 1.2.12 en

Uploaded by

Copyright:

Available Formats

OPS v3.1 Documentation Version 1.2.12 en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OPS v3.1 Documentation Version 1.2.12 en

Uploaded by

Copyright:

Available Formats

What are the main changes between versions of the document?

What are the main changes between versions of the document?

What services does the document discuss?

What services does the document discuss?

OPS RESTful Web Services

Reference Guide v.1.2.12

Open Patent Services

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

Update according to changes in the new

Update according to changes in the next

Update to Family priority-claim response

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

o The attribute cited-in was replaced by cited-phase in order to be

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

2.3.Registration & OPS Fair use policy..................................................................................36

3.4.Register service............................................................................................................... 111

3.5.Legal service.................................................................................................................... 125

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

4.1.Relevant acronyms and abbreviations...........................................................................145

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

Patent information relevant to OPS

The first patent publication is often the published patent

The Paris Convention for the Protection of Industrial Property of

Patent publication kind

A code which includes 1 or 2 letters and in many cases a number,

Patent publication date

The date when a described invention becomes publicly available.

Patent application claims

Simple patent family

All documents sharing directly or indirectly at least one priority.

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

EP Patent lifecycle and reference types

Every modification (bibliographic data, description, claims ...) results in a subsequent

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

How the generic OPS request URI is constructed:

2014 European Patent Office

OPS RESTful Web Services

Reference Guide v.1.2.12

2014 European Patent Office