Form UP7000 – Request for unitary effect

Form UP 7000 is used for filing a request for unitary effect of a European patent, including the statement concerning licences of right in respect of a European patent with unitary effect, the translation of the European patent and details on fee payment.

Structure of XML files for UP7000

The following two XML files are required for an UP7000 application to be imported:

File name	DTD	Description
package-data.xml	package-data.dtd	References attached documents, except those already referenced in application-body.xml file.
up-request.xml	up-request-v1-2.dtd	Application data as entered in Form UP7000, references other attached documents.

References from XML files to other files

All PDF files and other attachments must be referenced by the package-data.xml file, or by one of the XML files that are referenced in the package-data.xml file, i.e., the up-request.xml file.

package-data.xml file

The package-data.xml file references the file names for attached documents in multiple <other-doc> elements using the file and file-type attributes. The document code to be received by the EPO server is contained in the <document-name> element. In addition, the up-request.xml file is referenced in the <application-request> element and the application-body.xml file in the <application-body-doc> element.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE package-data SYSTEM "package-data.dtd">
<package-data lang="en" dtd-version="1.0" produced-by="applicant">
  <transmittal-info>
    <new-application>
      <to>
        <country>EP</country>
      </to>
    </new-application>
  </transmittal-info>
  <signatories>
    <signatory>
      <name/>
      <electronic-signature date="">
        <basic-signature>
          <text-string/>
        </basic-signature>
      </electronic-signature>
    </signatory>
  </signatories>
  <application-request file="up-request.xml"/>
  <other-documents>
    <other-doc file="upf7000.pdf" file-type="pdf">
      <document-name>7000</document-name>
      <dtext/>
    </other-doc>
    <other-doc file="up-request.xml" file-type="xml">
      <document-name>REQXML</document-name>
      <dtext/>
    </other-doc>
    <other-doc file="FREP.PDF" file-type="pdf">
      <document-name>FREP</document-name>
      <dtextx/></dtextx>
    </other-doc>
  </other-documents>
</package-data>

<up-electronic-files doc-type="7000">
  <applicant-file-name/>
  <up-file-name>Upf7000.pdf</up-file-name>
</up-electronic-files>
<up-electronic-files doc-type="FREP">
  <applicant-file-name>UP7000.PDF</applicant-file-name>
  <up-file-name>FREP.PDF</up-file-name>
</up-electronic-files>

Basic structure of up-request.xml

The up-request.xml file contains the application data in Form UP7000. Its root element is <up-request>, which contains the following attributes:

XML Attribute	Attribute Description	Example/fixed value
ro	Code for the filing office.	Fixed value: “EP”.
produced-by	Indicates role of party generating the submission (e.g., applicant).	Fixed value: “applicant”
dtd-version	Version of DTD used.	Fixed value: "1.2"
lang	Procedural language for the request, indicated by its 2-letter language code (en, fr, de).	E.g.: “en”
date-produced	Date/time of package generation in “YYYYMMDD hh:mm:ss” format.	E.g.: "20240122 11:19:17"

The table below lists the top-level XML elements under <up-request> and their key attributes:

XML Element	Description and attributes
`<publication-reference>` `<application-reference>`	Basic application/patent information for the UP7000 submission, including the corresponding EP application no. and publication no. See UP7000 - General Information - About the application/patent for details.
`<grant-date>`	Date of mention of the grant of the indicated European patent, in YYYYmmDD format. If not applicable/provided, this element should be empty.
`<translations>`	Information regarding the attached translations and their related costs to be compensated (if applicable). See UP7000 - General Information - Translation costs for details.
`<file-reference-id>`	Internal ID name for the UP7000 submission, as it will appear on the OLF2.0 GUI for edition/review. Can be any name chosen by the user with the following limitations: Up to 25 characters long. No blank spaces. E.g.: `<file-reference-id>`My_7000_request`</file-reference-id>`
`<patent-granted-with-same-claims-set-rule-5-2-upr/>`	If present, this empty element indicated that the European patent in question has been granted with the same set of claims in respect of all the participating Member States (Rule 5(2) UPR).
`<request-petition>`	Descriptive name of the request corresponding to the form. For UP7000, this will be a fixed string as follows: `<request-petition>`Request for unitary effect`<request-petition>`
`<parties>`	List of parties involved in the application (proprietors, representatives…). This element has no text value nor attributes, and instead contains a set of children elements. Please see UP7000 – Parties for details and example cases.
`<check-list>`	Contains a list of children nodes corresponding to the type of document (request, other…). E.g.: `<cl-other-document>` Each of the aforementioned child elements indicates numeric values related to each of the documents referred to in the submission, such as the total count of pages on it, no. of the first and last pages, etc. Note that this section should always contain, at least, a single empty child element `<cl-request/>` E.g.: `<check-list>` `<cl-request/>` `<cl-other-document>`Other document`</cl-other-document>` `</check-list>` Please see UP7000 - Documents for more details and example cases.
`<office-specific-data>`	UP7000 request data specific to the filing office (declarations, fees…). Attributes: office: Filing office to which the specific data in the element applies. For UP7000 filed to EPO, this should have a fixed value of “EP”. lang: Procedural language, same as in element `<up-request>`. E.g.: “en” This element will contain the applicable declarations, information about the attached documents, the information regarding fees, and (optionally) any enclosed annotations to EPO. Please see the following subchapters for details and example cases: UP7000 - Documents UP7000 - Fees UP7000 - Annotations Note that this element must always contain an `<up-declarations>` child element, which can be empty (i.e., no declarations are being made).

Below is an example showing the general structure in up-request.xml and the top-level elements listed in the previous table:

<?xml version="1.1" encoding="UTF-8"?>
<!DOCTYPE up-request
SYSTEM "up-request-v1-2.dtd">
<up-request ro="EP"
  produced-by="applicant"
  dtd-version="1.2"
  lang="en"
  date-produced="20240122 11:19:17">
  <publication-reference>
    <document-id lang="en">
      <country>EP</country>
      <doc-number>EP_______</doc-number>
      <kind>publication</kind>
      <date/>
    </document-id>
  </publication-reference>
  <application-reference>
    <document-id lang="en">
      <country>EP</country>
      <doc-number>EP20202020.2</doc-number>
      <kind>application</kind>
      <date/>
    </document-id>
  </application-reference>
  <grant-date/>
  <translations>
    <procedural-language>en</procedural-language>
    <language-of-translation>pt</language-of-translation>
    <compensation requested="false"/>
  </translations>
  <file-reference-id>7000 Form Test</file-reference-id>
  <patent-granted-with-same-claims-set-rule-5-2-upr/>
  <request-petition>Request for unitary effect</request-petition>
  <parties>
    …
  </parties>
  <check-list>
    <cl-request/>
  </check-list>
  <office-specific-data office="EP" lang="en">
    <up-declarations/>
    …
  </office-specific-data>
</up-request>

The details for the child elements of <up-request>, their relevant attributes and how they are mapped to the different form fields and tabs (e.g., the list of involved parties and their contact information in the <parties> element, filled out via the Parties tab in the UP7000 form) will be described in subsequent section in this form’s chapter.

Document codes and file types for UP7000

For the successful import of XML data into OLF2.0, the values for the <document-name> element, the doc-type attribute and the file attribute must follow the standard values for the document code as listed in the table below. Without the correct document code, the receiving server at the EPO cannot accept files.

Document code	EPO file name *)	Description

Request

ADDRESSXML	address-matching.xml	Package
BIODEPXML		Biology
PACKDATAXML	package-data.xml	Package
RECXML	xmit-receipt.xml	Receipt in XML format
UP-REQUESTXML	up-request.xml	UP7000 form in XML format

Documents concerning rights and representation

UREES	UREES-1.pdf	Request for re-establishment of rights
UREESGR	UREESGR-1.pdf	Grounds for re-establishment of rights
FREP	FREP-1.pdf	Document concerning representation
1003	1003-1.pdf	Authorisation of representative
1004	1004-1.pdf	General authorisation

Additional documents

UTRAN	UTRAN.pdf	Translation of the European patent
INCANNEX-UPP	INCANNEX-UPP-1.pdf	Other document

Documents generated by OLF2.0 (not to be imported)

7000	up7000.pdf	Application in PDF format

*) If there is more than one file of this type of document, the character 1 in the file names must be replaced by 2, 3 etc.

UP7000 – General information

Form UP7000 starts with the General information tab where basic data for the application is entered, including information about:

About the application/patent
Translation costs
Place of business on the date of filing of the European patent application

The structure of the data corresponding to each of the above sub-panels in the tab will be covered in detail in the subsequent chapters below.

About the application/patent

The data concerning the references to the European application/patent is structured in the following top-level elements under <up-request> in up-request.xml as follows:

The referred patent and application’s information is imported from the contents of XML elements <publication-reference> and <application-reference> (respectively). Each of these sections consists of a single <document-id> XML element containing a single attribute lang indicating the application’s procedural language with a 2-letter code (i.e., “en”, “de”, “fr”) and the following set of sub-elements:
- <country>: Country/region code of the application/patent. For UP7000 filings, this should always be “EP”.
- <doc-number>: ID number of the referred EP patent/application.
- <kind>: value must be publication for element <publication-reference> and application for <application-reference>.
- <date>: Date of mention of the grant (if provided). If present, its value should be the same for both <publication-reference> and <application-reference>, as well as match the date provided in element <grant-date> (see below).
- Example:

<publication-reference>
  <document-id lang="en">
    <country>EP</country>
    <doc-number>EP3812340</doc-number>
    <kind>publication</kind>
    <date>20231101</date>
  </document-id>
</publication-reference>
<application-reference>
  <document-id lang="en">
    <country>EP</country>
    <doc-number>EP16155428.2</doc-number>
    <kind>application</kind>
    <date>20231101</date>
  </document-id>
</application-reference>

If a date of mention of grant is provided (optional), a <grant-date> element should be present indicating said date in YYYYmmDD format. The value must match that of the <date> property in the <publication-reference> and <application-reference> sections. E.g.:

…
<application-reference>
  <document-id lang="en">
    <country>EP</country>
    <doc-number>EP16155428.2</doc-number>
    <kind>application</kind>
    <date>20231101</date>
  </document-id>
</application-reference>
<grant-date>20231101</grant-date>

If the European patent in question has been granted with the same set of claims in respect of all the participating Member States (Rule 5(2) UPR), an empty element <patent-granted-with-same-claims-set-rule-5-2-upr/> should also be present under <up-request> following the ones described above.

The snippet below corresponds to an example UP7000 submission showing all the XML elements described above:

<up-request ro="EP"
  produced-by="applicant"
  dtd-version="1.2"
  lang="en"
  date-produced="20240122 11:19:17">
<publication-reference>
  <document-id lang="en">
    <country>EP</country>
    <doc-number>EP3812340</doc-number>
    <kind>publication</kind>
    <date/>
  </document-id>
</publication-reference>
<application-reference>
  <document-id lang="en">
    <country>EP</country>
    <doc-number>EP20202020.2</doc-number>
    <kind>application</kind>
    <date/>
  </document-id>
</application-reference>
<grant-date>20231101</grant-date>
<translations>
  … (*)
</translations>
<file-reference-id>7000_Form_Test</file-reference-id>
<patent-granted-with-same-claims-set-rule-5-2-upr/>
<request-petition>Request for unitary effect</request-petition>
…

(*) The structure of the <translations> element will be described separately in the next sub-chapter.

Translation costs

Information regarding the costs of translations (if attached to the submission) is imported from XML element <translations>, which must be present under root element <up-request> in up-request.xml following the elements described in About the application/patent.

The <translations> element must contain the following child elements:

XML Element	Description and sub-elements
`<procedural-language>`	Indicates the language of the proceedings with a 2-letter country code (en/fr/de). This should match the value of the lang attribute in `<up-request>`. If no translation is attached, this element can be empty. Note that this information is provided in tab Documents in the OLF2.0 GUI. Please refer to UP7000 - Documents for more details.
`<language-of-translation>`	Indicates the language of the attached translation document with a 2-letter country code (en/fr/de). If no translation is attached, this element can be empty. Note that this information is provided in tab Documents in the OLF2.0 GUI. Please refer to UP7000 - Documents for more details.
`<compensation>`	Provides the data corresponding to the costs of the submitted translation. Attributes: requested: if “true”, it indicates that compensation for translation costs is being requested (Rule 9 UPR). Otherwise, this should be “false”. compensation-payment-method: if requested=”true”, this attribute must be present and have the fixed value “deposit-account”. Please see UP7000 - Fees / Payment details for more details regarding payment data. Below is an example of element `<translations>` corresponding to an UP7000 submission where compensation for translation costs is not requested: `<translations>` `<procedural-language>`en`</procedural-language>` `<language-of-translation/>` `<compensation requested="false"/>` `</translations>`

The example below illustrates the structure of the <translations> element in an UP7000 submission where a translation of the European patent to Portuguese (pt) is attached and a request for compensation of the translation costs is made.

…
</application-reference>
<grant-date>20231101</grant-date>
<translations>
  <procedural-language>en</procedural-language>
  <language-of-translation>pt</language-of-translation>
  <compensation requested="true" compensation-payment-method="deposit-account"/>
</translations>
<file-reference-id>7000 Form Test</file-reference-id>
…

Place of business at filing

Form UP7000 allows the filing party to, optionally, indicate a place of business of the applicant(s) on the date of filing of the European patent application (Article 7(1)(b) Regulation (EU) No 1257/2012, Rule 16(1)(w) UPR). This can be useful in cases where the initial applicant's name and/or address is different from that of the actual patent proprietor.

When choosing to provide information regarding a specified place of business, XML element <place-of-business> must be present under the <parties> top element along with other named parties in the submission (please see UP7000 - Parties for details). Element <place-of-business> should contain a single attribute sequence with a fixed value of “1”, and a single child element <addressbook> with the structure shown in the example below (elements highlighted in yellow correspond to mandatory fields that must be present and have a valid value):

<parties>
  <proprietors>
    …
  </proprietors>
  <place-of-business sequence="1">
    <addressbook lang="en">
      <name>Catherine Dubois</name>
      <department>IP</department>
      <address>
        <pobox/>
        <street>Postbus 24 / Gent Centrum</street>
        <city>Belgrad</city>
        <state/>
        <postcode/>
        <country>BE</country>
      </address>
    </addressbook>
  </place-of-business>
  <agents>
    …
  </agents>
</parties>

(*) The format of the address in the <street> field is: Address line 1 / Address line 2.

An alternate example is provided below:

XML up-request.xml place of business at filing data

<parties>
<place-of-business sequence="1">
  <addressbook lang="">
    <name>Manzoni, Salvatore</name>
    <department></department>
    <address>
      <pobox></pobox>
      <street>Via al Ticino 100</street>
      <city>Bellinzona</city>
      <state></state>
      <postcode>6500</postcode>
      <country>IT</country>
    </address>
  </addressbook>
</place-of-business>

UP7000 - Parties

The Parties tab of Form UP7000 accommodates all data for names, persons and addresses relating to the submission. This information is imported from the <parties> element in the up-request.xml file.

The <parties> element may contain up to one of each of the following child elements:

<proprietors>, which may contain one or more <proprietor> elements, each one referring to a proprietor.
<place-of-business>, which (if present) indicates the place of business of the proprietor at the time of filing. This was previously described in section UP7000 – General information / Place of business at filing in this guide.
<agents>, which may contain one or more <agent> elements, each one referring to a representative.

ℹ️ Note

If an address for correspondence has been entered for the first-named proprietor, no representative can be added, and vice versa.

The required attributes and child elements for each individual <proprietor> and <agent> element are mostly specific to the type of party, and will be described separately in detail in subsequent chapters.

Proprietors

The table below lists the required attributes for each individual <proprietor> entry appearing under <proprietors>:

XML Attribute	Attribute Description	Example/fixed value
sequence	Order no. of the proprietor in the list of named proprietors. Always required.	E.g.: “1” (*)
prop-type	Indicates the specific type of applicant/proprietor party the element refers to.	Fixed value: "proprietor"

(*) Note that, even if a submission is to be imported with no proprietors listed under the Parties section (i.e., as a draft to be filled out later), the <proprietors> section must still be present and contain an empty <proprietor> entry with a sequence no. “0”, as the example snippet below:

<proprietors>
  <proprietor sequence="0" app-type="proprietor">
    <addressbook lang="en">
      <name name-type="legal"/>
      <address>
        <postcode/>
        <country/>
      </address>
    </addressbook>
    <nationality>
      <country/>
    </nationality>
    <residence>
      <country/>
    </residence>
  </proprietor>
</proprietors>

Each <proprietor> element should contain the following child XML elements:

A single <addressbook> sub-element with the name and address details. This element should always be present (required).
If a specific country of nationality is to be specified, a <nationality> sub-element should also be present. This will contain a single <country> child element with the 2-letter country code (e.g.: “IT” for Italy).
Similarly, if a specific country of residence is to be specified, a <residence> sub-element should also be present, with the same internal structure as the above.

The example below shows the basic structure for the <parties> section in a request that only includes a single proprietor specifying Italy (IT) as both their nationality and residence country:

<parties>
  <proprietors>
    <proprietor sequence="1"
      prop-type="proprietor">
    <addressbook lang="en">
      …
    </addressbook>
    <nationality>
      <country>IT</country>
    </nationality>
    <residence>
      <country>IT</country>
    </residence>
  </ep-applicant>
  </proprietors>
</parties>

The <addressbook> element with the name and address detail for each party will have the following single attribute:

lang: 2-letter language code. This must match the procedural language for the attached/referred application. E.g.: <addressbook lang="en">

The structure of the <addressbook> element is specific to the type of party involved (applicant/representative/inventor) and its sub-type (e.g., legal or natural person, for applicants):

Party element	Sub-type(s)	XML Elements in `<addressbook>`
`<proprietor>`	Proprietor, legal person	`<name name-type="legal">` `<address>` `<address-2>` `<pobox>` `<street>` `<city>` `<state>` `<postcode>` `<country>` `</address>` `<phone>` `<email>`
`<proprietor>`	Proprietor, natural person	`<last-name>` `<first-name>` `<orgname>` `<department>` `<address>` `<pobox>` `<street>` `<city>` `<state>` `<postcode>` `<country>` `</address>` `<phone>` `<email>`

Below is an example showing the general structure of a <parties> element in up-request.xml containing a single <proprietor> entry corresponding to a proprietor (natural person), with the top-level elements and attributes listed in the previous tables:

<parties>
  <proprietors>
    <proprietor sequence="1"
      app-type="proprietor">
      <addressbook lang="en">
        <last-name>Manzoni</last-name>
        <first-name>Salvatore</first-name>
        <orgname>Borghese S.A.</orgname>
        <department>Invenzioni</department>
        <address>
          <pobox/>
          <street>Via Roma 8 / Piazza del Duomo</street>
          <city>Milano</city>
          <state/>
          <postcode>20100</postcode>
          <country>IT</country>
        </address>
        <phone>+39 2 5056 10</phone>
        <email>[email protected]</email>
      </addressbook>
      <nationality>
        <country>IT</country>
      </nationality>
      <residence>
        <country>IT</country>
      </residence>
    </proprietor>
  </proprietors>
</parties>

Representatives

The table below lists the required attributes for each individual <agent> entry appearing under <agents>:

XML Attribute	Attribute Description	Example/fixed value
sequence	Order no. of the representative in the list of representatives. Always required.	E.g.: “1”
same-address	Indicates, when naming multiple representatives, if a given representative in the list shares the same address as the first one (i.e., with sequence=”1”). Always required.	“true” or “false”
rep-type	Always required. Indicates sub-type of representative as follows: “common-representative”: association. “agent”: individual. “attorney”: legal practitioner.	E.g.: “common-representative”
up-association-number	If rep-type=“common-representative” (association), this attribute is required and must provide its registration no.	E.g.: “125”
authorisation	Required if representative chooses to file a general authorisation, and the value indicates its type as follows: “attached”: individual authorisation is attached. “registered”: general authorisation has been registered under number in attribute general_authorisation_number (see below). “referenced”: a specific authorisation has been previously filed at a given date, indicated in attribute specific-authorisation-date (see below).	E.g.: “attached”
general-authorisation- number	If authorisation=“ registered”, this attribute is required and must provide the no. under the authorisation is registered.	E.g.: “102356”
specific-authorisation-date	If authorisation=“ referenced”, this attribute is required and must provide the date of the referenced authorisation (in YYYYmmDD format).	E.g.: "20240301"

Each <agent> element should contain:

A single <addressbook> sub-element with the name and address details. This element should always be present (required).

The example below shows the basic structure for the <parties> section in a request that only includes a single representative:

<parties>
  <agents>
    <agent sequence="1"
      same-address="false"
      rep-type="agent">
      <addressbook lang="en">
        …
      </addressbook>
    </agent>
  </agents>
</parties>

The <addressbook> element with the name and address detail for each party will have the following single attribute:

lang: 2-letter language code. This must match the procedural language for the attached/referred application. E.g.: <addressbook lang="en">

The structure of the <addressbook> element is specific to the type of party involved (applicant/representative/inventor) and its sub-type (e.g., legal or natural person, for applicants):

Party element	Sub-type(s)	XML Elements in `<addressbook>`
`<agent>`	Professional representative, association	`<last-name>` (*) `<department>` `<registered-number>` `<address>` `<pobox>` `<street>` `<city>` `<state>` `<postcode>` `<country>` `</address>` `<phone>` `<email>`
`<agent>`	Professional representative, individual Legal practicioner	`<last-name>` `<first-name>` `<orgname>` `<department>` `<address>` `<pobox>` `<street>` `<city>` `<state>` `<postcode>` `<country>` `</address>` `<phone>` `<email>`

ℹ️ Note

(*) For representatives of sub-type association (i.e., with attribute rep-type=“common-representative”), the value of the <last-name> element corresponds to the Organisation name of the association acting as representative.

Below is an example showing the general structure of a <parties> element in up-request.xml containing a single <agent> entry for a representative of type association with a general authorisation referred by no.:

<parties>
  <agents>
    <agent sequence="1"
      rep-type="common-representative"
      same-address="false"
      up-association-number=”12345”
      authorisation="referenced"
      general-authorisation-number="888">
      <addressbook lang="en">
        <last-name>IP Partners</last-name>
        <first-name/>
        <orgname>European Patents</orgname>
        <registered-number>12345</registered-number>
        <address>
          <pobox>5088</pobox>
          <street>Cambridge Science Park / 100 Red Lion Square</street>
          <city>Cambridge</city>
          <state>Cambridgeshire</state>
          <postcode>CB2 1AB</postcode>
          <country>GB</country>
        </address>
        <phone>+44 1223 3516-0</phone>
        <email>[email protected]</email>
      </addressbook>
    </agent>
  </agents>
</parties>

UP7000 - Documents

The Documents tab in Form UP7000 allows for attaching documents containing translations, authorisations, requests, legal remedies and other documents.

Documents containing translations can be attached in the Translation of the European patent sub-tab.
All other documents can be attached in the Other documents sub-tab:
- Authorisation of representative
- Document concerning representation
- General authorisation
- Grounds for re-establishment of rights
- Other document
- Request for re-establishment of rights

Each attached file appears as a child element both in the <check-list> and the <office-specific-data> elements in up-request.xml. There are specifically named elements for each document type. The list of standard document names required by the EPO can be found in chapter Document codes and file types for UP7000.

For each document attached with the submission, a <up-electronic-files> element inside section <office-specific-data> must be present in up-request.xml. An <up-electronic-files> element must always contain the following attribute:

doc-type: standard EPO code identifying the document type. Please see section Document codes and file types for UP7000 for a full reference list.

The table below list the child elements in each <up-electronic-files> entry:

XML Element	Description, attributes and sub-elements
`<applicant-file-name>`	Name of the file as originally uploaded by the user during the submission in OLF2.0. E.g.: `<applicant-file-name>`translation_french.pdf`</applicant-file-name>` Note that, for the EP7000 request document itself (doc-type=”7000”) this element should always be empty.
`<up-file-name>`	Standard EPO file name corresponding to the type of provided document (please see section Document codes and file types for UP7000 for a full list). E.g.: `<up-file-name>`UTRAN.pdf`</epo-file-name>`

Section <check-list> in up-request.xml must contain a child node for each document filed in the submission. The table below list the possible child elements in that can figure in the <check-list> section depending on the provided documents and their expected contents:

XML Element	Document type	Value and/or Attributes
`<cl-request>`	UP7000 request.	This element should always be empty.
`<cl-other-document>`	Any other filed document.	No attributes. Value should be the full name of the provided document. E.g.: “Translation of the patent”

Additionally, and when attaching a Translation of the patent to the UP7000 request (doc. code UTRAN), the language of the supplied translation must also be specified in the <language-of-translation> sub-element inside XML element <translations> in up-request.xml with its corresponding 2-letter country code, as shown in the example snippet below:

…
</application-reference>
<grant-date>20231101</grant-date>
<translations>
  <procedural-language>en</procedural-language>
  <language-of-translation>pt</language-of-translation>
  <compensation requested="true" compensation-payment-method="deposit-account"/>
</translations>
<file-reference-id>7000 Form Test</file-reference-id>
…

Example: Translation and other documents attached

Below is a snippet showing the basic structure of the <up-electronic-files> elements and sub-elements inside <check-list> in up-request.xml corresponding to a UP7000 request where two documents are being filed: an authorisation of representative and a translation of the European patent. The translation language is Portuguese (pt) and a request for compensation of the translation costs is made.

<up-request ro="EP"
  produced-by="applicant"
  dtd-version="1.2"
  lang="en"
  date-produced="20240122 11:19:17">
  <publication-reference>
    …
  </publication-reference>
  <application-reference>
    …
  </application-reference>
  …
</application-reference>
  <grant-date>20231101</grant-date>
  <translations>
    <procedural-language>en</procedural-language>
    <language-of-translation>pt</language-of-translation>
    <compensation requested="true" compensation-payment-method="deposit-account"/>
  </translations>
  <file-reference-id>7000_Form_Test</file-reference-id>
  <patent-granted-with-same-claims-set-rule-5-2-upr/>
  <request-petition>Request for unitary effect</request-petition>
  <parties>
    …
  </parties>
  <check-list>
    <cl-request/>
    <cl-other-document>Authorisation of representative</cl-other-document>
    <cl-other-document>Translation of the patent</cl-other-document>
  </check-list>
  <office-specific-data office="EP" lang="en">
    <ep-declarations/>
    <ep-electronic-files doc-type="7000">
      <applicant-file-name/>
      <epo-file-name>up7000.pdf</epo-file-name>
    </ep-electronic-files>
    <up-electronic-files doc-type="1003">
    <applicant-file-name>Authorisation Kilburn.pdf</applicant-file-name>
    <epo-file-name>1003-1.pdf</epo-file-name>
  </ep-electronic-files>
    <ep-electronic-files doc-type="FREP">
      <applicant-file-name>Representation for Nano Enterprise.pdf</applicant-file-name>
      <epo-file-name>FREP-1.pdf</epo-file-name>
    </ep-electronic-files>
    <up-financial-data curr="EUR">
      …
    </up-financial-data>
  </office-specific-data>
</up-request>

UP7000 - Fees

The XML data structure of fee payment details data for the UP7000 form in up-request.xml is similar to the previously described forms, with the exception of the container XML element, which is <up-financial-data> for UP7000, instead of <ep-financial-data>.

Payment details and refund instructions

Information regarding the payment details is imported from the <mode-of-payment> XML element under <up-financial-data> in up-request.xml.

ℹ️ Note

Please note that, if the user chooses to arrange the fee payment separately and therefore not to specify a fee payment method in the submission (i.e., the equivalent of leaving field "Payment method" in the GUI set to 'Not specified'), then element <mode-of-payment> should not be present under <up-financial-data> in up-request.xml.

This element must contain the following attributes:

accno: when using mode-type “auto” or “deposit” (see below), this must be set to the number of EPO deposit account to be used. E.g.: "28123456"
mode-type: selected mode of payment. Can be one of the following values depending on the chosen option:
- “auto”: Automatic debit order.
- “deposit”: Debit from deposit account.
- “bank”: Bank transfer.
- “ccard”: Credit card.
currency: currency for fee payment. This is always “EUR” by default.
deferred-execution-date: when requesting a deferred date of payment execution, this attribute must be present and have said date in yyyyMMdd format as value. This attribute can either be set to an empty value or be omitted if the import file should not specify a deferred execution date.

ℹ️ Note

In addition to the applicable attributes described above, the element should also contain the full name of the account/card holder to be used for payment as its value.

When choosing to provide instructions regarding reimbursements (if applicable) to be made to a deposit account with the EPO, this information should be present in the <reimbursement> XML element under <up-financial-data> in up-request.xml. This element must contain:

A single accno attribute specifying the no. of the EPO deposit account where reimbursements should be made.
The name of the account holder, as the internal value of the XML element.

Below is a snippet showing the basic structure of both elements <mode-of-payment> and <reimbursement>:

…
</up-electronic-files>
<up-financial-data curr="EUR">
<mode-of-payment currency="EUR"
  accno="28555555"
  deferred-execution-date="20231130"
  mode-type="deposit">Account holder</mode-of-payment>
<reimbursement accno="28123456">Account holder</reimbursement>
<fees date="20231114">
…

Fee selection

Information regarding the UP7000 selected fees is imported from the <standard-fee> XML element under <fees> in up-request.xml. Each <fee> element must contain the following attributes:

index: index no. of the corresponding applicable fee, as it appears on the Fees tab in OLF2.0. Note that any zeroes on the left should not be included. E.g.: “713”.
topay: yes/no value indicating if the corresponding fee is intended to be paid (“yes”) or not (“no”).

ℹ️ Note

The only fee applicable when filing an UP7000 request with the EPO (i.e., fee 713, “Fee for re-establishment of right”) is always payable (i.e., its attribute topay can be freely set to “yes” if selected for payment without any previous requirements, or to “no” otherwise).

Each <fee> element must contain the following XML child elements:

XML Element	Description, attributes and sub-elements
`<type-of-fee>`	Indicates the type of fee. This should always have the value “standard”. E.g.: `<type-of-fee>`standard`</type-of-fee>`
`<fee-factor >`	Indicates the factor (from 0 to 1, corresponding to a 0-100% percentage) in which the fee will be paid, according to the specified quantity and applicable reduction factor. For fee 713 in UP7000, this value will always be 1. This element contains a single attribute user-input with a fixed value of “1”. E.g.: `<fee-factor user-input="1">`1`</fee-factor>` If the parent’s topay attribute is set to “no”, this element should not have a value (just the user-input attribute set to “1”). E.g.: `<fee-schedule user-input="1"/>`
`<fee-schedule>`	Indicates the amount to pay for the total quantity of the specified fee, after applying reductions. For fee 713 in UP7000, its value should be the same as `<fee-sub-amount>` (since the quantity will always be 1). E.g.: `<fee-schedule>`720.00`</fee-schedule>` If the parent’s topay attribute is set to “no”, this element should be empty. E.g.: `<fee-schedule/>`
`<fee-sub-amount>`	Indicates the base amount for the fee according to the current fee schedule (i.e., not taking reductions into account). For fee 713 in UP7000, and if the fee is selected for payment (topay=”yes”), its value should match the one in `<fee-schedule>`. E.g.: `<fee-sub-amount>`720.00`</fee-sub-amount>`
`<fee-reduction-factor>`	Indicates the reduction factor (from 0 to 1, corresponding to a 0-100% percentage) for the fee. For fee 713 in UP7000, this is not applicable and the element should be left empty (for a default value of 0).

ℹ️ Note

The <fee-schedule> element is used for the (calculated) fee amount and the <fee-sub-amount> element contains the fee schedule (for one single fee).

In the case of fee 713, <fee-factor> and user-input are always set to 1 (which means the quantity is 1) and <fee-reduction-factor> is either left empty or set to -1 or 0 (which means not applicable).

Additionally, and after the end of section <standard-fee> with the structure described above, an XML element <fee-total-amount> must also appear under <fees>, indicating the total amount to be paid for all the selected fees. For UP7000, this value should match that of the sub-amount for the single fee 713 entry.

The example below corresponds to standard fee 713 selected for payment, with “Debit from deposit account” selected as mode of payment and providing refund instructions:

XML up-request.xml

<up-financial-data curr="EUR">
  <mode-of-payment currency="EUR" accno="28123456" deferred-execution-date="20220620"
    mode-type="deposit">IP Department</mode-of-payment>
  <reimbursement accno="28456123">IP Department</reimbursement>
  <fees date="20220401">
    <standard-fee>
      <fee index="713" topay="yes">
        <type-of-fee>standard</type-of-fee>
        <fee-factor user-input="1">1</fee-factor>
        <fee-schedule>685</fee-schedule>
        <fee-sub-amount>685</fee-sub-amount>
        <fee-reduction-factor>0</fee-reduction-factor>
      </fee>
    </standard-fee>
    <fee-total-amount>685</fee-total-amount>
  </fees>
</up-financial-data>

UP7000 - Annotations

At the end of the <office-specific-data> section (right after closure of the <ep-financial-data> section corresponding to fee payment details), one or more <up-notes-to-EPO> elements can be included, each one containing Annotations to send additional information to the EPO. The number of annotations is unlimited.

ℹ️ Note

If no annotations are to be included in the submission (as they are entirely optional), no <up-notes-to-EPO> elements should be present in the up-request.xml file.

The root element for each annotation (<up-notes-to-EPO>) must contain the following attributes:

page: fixed string value “Annotate”.
id: a “note#” string where # is a number representing the order of creation of the current note (i.e.: note1 for the firstly note created, then note2, note3 and so on).

E.g.: <up-notes-to-EPO page="Annotate" id="note1">

The table below lists the child XML elements that must appear under each <up-notes-to-EPO> entry:

XML Element	Description and attributes
`<author>`	Full name (first + last name) of the user authoring the annotation.
`<subject>`	Subject of the annotation.
`<date>`	Date in which the annotation was created, in yyyyMMdd format. Note that this value is not shown in the request PDF for UP7000.
`<dtext>`	Text contents of the annotation.

The example below shows how a single annotation is stored:

XML up-request.xml

<up-notes-to-EPO page="Annotate" id="note1">
  <author>Berger, Marc</author>
  <subject>Representation</subject>
  <date>20220621</date>
  <dtext>Sophie Bresson, my successor at Associ&#233;s Lef&#234;vre, is
  going to take over her duties starting August 4 2010. Separate
  communication will be made to the EPO concerning this matter.</dtext>
</up-notes-to-EPO>

Structure of XML files for UP7000​

References from XML files to other files​

Basic structure of up-request.xml​

Document codes and file types for UP7000​

Request​

Documents concerning rights and representation​

Additional documents​

Documents generated by OLF2.0 (not to be imported)​

UP7000 – General information​

About the application/patent​

Translation costs​

Place of business at filing​

UP7000 - Parties​

Proprietors​

Representatives​

UP7000 - Documents​

Example: Translation and other documents attached​

UP7000 - Fees​

Payment details and refund instructions​

Fee selection​

UP7000 - Annotations​