Skip to main content

Form UP(7038) – Subsequently filed documents for Request for unitary effect

Form UP 7038 may be used submit a subsequent action (i.e., attach additional documents, pay fees or add annotations) for a request for Unitary effect that was previously filed for a patent granted and published by EPO.

Structure of XML files for UP(7038)​

The following two XML files are required for an UP(7038) application to be imported:

File nameDTDDescription
package-data.xmlpackage-data.dtdReferences attached documents, except those already referenced in application-body.xml file.
up-sfd-request.xmlupsfd-request-v1-2.dtdApplication data as entered in Form UP(7038), 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-sfd-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-sfd-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-sfd-request.xml"/>
  <other-documents>
    <other-doc file="upf7038.pdf" file-type="pdf">
      <document-name>7038</document-name>
      <dtext/>
    </other-doc>
    <other-doc file="up-sfd-request.xml" file-type="xml">
      <document-name>REQXML</document-name>
      <dtext/>
    </other-doc>
    <other-doc file="1003-1.pdf" file-type="pdf">
      <document-name>1003</document-name>
      <dtext/>
    </other-doc>
  </other-documents>
</package-data>
<up-electronic-files doc-type="7038">
  <applicant-file-name/>
  <up-file-name>UPF7038.PDF</up-file-name>
</up-electronic-files>
<up-electronic-files doc-type="1003">
  <applicant-file-name>authorisation.pdf</applicant-file-name>
  <up-file-name>1003-1.pdf</up-file-name>
</up-electronic-files>

Basic structure of up-sfd-request.xml​

The up-sfd-request.xml file contains the application data in Form UP(7038). Its root element is <upsfd-request>, which contains the following attributes:

XML AttributeAttribute DescriptionExample/fixed value
roCode for the filing office.Fixed value: “EP”.
produced-byIndicates role of party generating the submission (e.g., applicant).Fixed value: “applicant”
dtd-versionVersion of DTD used.Fixed value: "1.1"
langProcedural language for the request, indicated by its 2-letter language code (en, fr, de).E.g.: “en”
date-producedDate/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 <upsfd-request> and their key attributes:

XML ElementDescription and attributes
<publication-reference>
<application-reference>		Basic application/patent information for the UP7038 submission, including the corresponding EP application no. and publication no.
See UP(7038) – General information for details.
<file-reference-id>Internal ID name for the UP7038 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_7038_request</file-reference-id>
<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 UP(7038) - 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 <up-declarations/> for more details and example cases.
<office-specific-data>UP7038 request data specific to the filing office (declarations, fees...).
Attributes:
office: Filing office to which the specific data in the element applies. For UP7038 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:
UP(7038) - Documents
UP(7038) - Fees
UP(7038) - 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-sfd-request.xml and the top-level elements listed in the previous table:

<?xml version="1.1" encoding="UTF-8"?>
<!DOCTYPE upsfd-request
SYSTEM "upsfd-request-v1-2.dtd">
<upsfd-request ro="EP"
  produced-by="applicant"
  dtd-version="1.1"
  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>
  <file-reference-id>7038_Form_Test</file-reference-id>
  <parties>
    ...
  </parties>
  <check-list>
    <cl-request/>
  </check-list>
  <office-specific-data office="EP" lang="en">
    <up-declarations/>
    ...
  </office-specific-data>
</upsfd-request>

The details for the child elements of <upsfd-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 UP7038 form) will be described in subsequent section in this form’s chapter.

Document codes and file types for UP(7038)​

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.

There are some restrictions as to combining document types and fee payments in one application. Please create separate import packages for each of the following submissions:

  • Public documents and fees related to public documents
  • Non-public documents and fees related to non-public documents; see UP(7038) - Fees
Document codeEPO file name *)Description

Request​

ADDRESSXMLaddress-matching.xmlPackage
BIODEPXMLBiology
PACKDATAXMLpackage-data.xmlPackage
RECXMLxmit-receipt.xmlReceipt in XML format
UPSFD-REQUESTXMLup-sfd-request.xmlUP7038 form in XML format

Documents concerning rights and representation​

10031003-1.pdfAuthorisation of representative
FREPFREP-1.pdfDocument concerning representation
LICELICE-1.pdfDocument relating to a licence
DOCREMDOCREM-1.pdfDocument related to a right in rem
COMP-EVIDCOMP-EVID-1.pdfEvidence of being entity entitled to compensation of translation costs
INCANNEX-TORINCANNEX-TOR-1.pdfEvidence of transfer of rights
10041004-1.pdfGeneral authorisation
UREQUREQ-1.pdfGeneral enquiry
UREESGRUREESGR-1.pdfGrounds for re-establishment of rights
UPPLETT-R142UPPLETT-R142-1.pdfInterruption of proceedings
UMEDAUMEDA-1.pdfMedical certificate
UDOC-NPUDOC-NP-1.pdfNon-public document
PROPL-RRTPROPL-RRT-1.pdfNotification of termination of representative’s authorisation
INCANNEX-UPPINCANNEX-UPP-1.pdfOther document
INCANNEX-COTINCANNEX-COT-1.pdfCertificate with respect to translation
PROPL-RFCPROPL-RFC-1.pdfOther submission from proprietor
PROPL-RCPPROPL-RCP-1.pdfReply to "Indication of deficiencies in a request for entry of a change in personal particulars and invitation to correct them"
PROPL-R22PROPL-R22-1.pdfReply to "Indication of deficiencies in a request for registration of a transfer of rights and invitation to correct such deficiencies"
PROPL-RFDPROPL-RFD-1.pdfNotification of termination of representative's authorisation
PROPL-RRPPROPL-RRP-1.pdfReply to invitation to give notice of appointment of a professional representative
PROPL-RRTPROPL-RRT-1.pdfEvidence in support of request for decision
UFORREPLYUFORREPLY-1.pdfCorrection of errors in a request for unitary effect (Rule 20(2)(h) UPR)
UPPLETT-IREJUPPLETT-IREJ-1.pdfReply to “Intended rejection by the Unitary Patent Protection Division”
UPPLETT-R10UPPLETT-R10-1.pdfReply to “Invitation to remedy deficiencies in a request for compensation for translation costs”
UPPLETT-R7UPPLETT-R7-1.pdfReply to “Invitation to remedy deficiencies in a request for unitary effect (Rule 7(3) UPR)”
UPPLETT-R12UPPLETT-R12-1.pdfReply to “Invitation to remedy deficiencies in a statement/withdrawal of a statement concerning licences of right”
PROPL-RRPPROPL-RRP-1.pdfReply to invitation to give notice of appointment of a professional representative
UPPLETTUPPLETT-1.pdfReply to other communication from the Unitary Patent Protection Division
UNIP-DECAUNIP-DECA-1.pdfRequest for automatic debiting
REQREMREQREM-1.pdfRequest for cancellation of registration of a licence
DOCREGREMDOCREGREM-1.pdfRequest for cancellation of registration of a right in rem
CDPROP-CHOACDPROP-CHOA-1.pdfRequest for change of address
CDPROP-CHONCDPROP-CHON-1.pdfRequest for change of name
CDPROP-CHORCDPROP-CHOR-1.pdfRequest for change of proprietor’s representative
URDECURDEC-1.pdfRequest for decision
UREESUREES-1.pdfRequest for re-establishment of rights
ULREGULREG-1.pdfRequest for registration of a licence
REGREMREGREM-1.pdfRequest for registration of a right in rem
ULMEXULMEX-1.pdfRequest for registration or for cancellation of registration of a legal means of execution
CDPROP-TORCDPROP-TOR-1.pdfRequest for transfer of rights
ILICEILICE-1.pdfStatement concerning licences of right
UTRANUTRAN-1.pdfTranslation of the patent
WLICEWLICE-1.pdfWithdrawal of a statement concerning licences of right
UWDRAUWDRA-1.pdfWithdrawal of request for unitary effect

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

7038up7038.pdfApplication 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.

UP(7038) – General information​

Form UP(7038) starts with the General information tab where basic data for the application is entered.

The data concerning the references to the European application/patent 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. This element is not used in UP7038 and can be missing or left empty.

Additionally, a <file-reference-id> element should be present following the aforementioned XML sections providing the user’s file reference for the submission. E.g.:

<file-reference-id>7038_Example</file-reference-id>

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

<upsfd-request ro="EP"
  produced-by="applicant"
  dtd-version="1.1"
  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>EP16155428.2</doc-number>
      <kind>application</kind>
      <date/>
    </document-id>
  </application-reference>
  <file-reference-id>7038-Form-Test</file-reference-id>
  ...

UP(7038) - Parties​

The Parties tab of Form UP7038 accommodates all data for names, persons and addresses relating to the submission. This information is imported from the <parties> element in the up-sfd-request.xml file, which follows the same general XML structure as the up-request.xml file for UP7000.

The <parties> element may contain one of the following child elements, depending on the role of the filing party:

  • <proprietors>, which may contain a single <proprietor> element referring to a proprietor.
  • <agents>, which may contain a single <agent> element referring to a representative.

ℹ️ Note

In form UP7038, either one applicant or one representative can be added at the same time. Inventors or an address for correspondence cannot be added.

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 the single <proprietor> entry appearing under <proprietors>:

XML AttributeAttribute DescriptionExample/fixed value
sequenceOrder no. of the proprietor in the list of named proprietors. Always required.Fixed value: “1” (*)
(Only 1 proprietor can be named)
prop-typeIndicates the specific type of applicant/proprietor party the element refers to. Always required.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>
    </proprietor>
  </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 elementSub-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-sfd-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 AttributeAttribute DescriptionExample/fixed value
sequenceOrder no. of the representative in the list of representatives. Always required.E.g.: “1”
rep-typeAlways required. Indicates sub-type of representative as follows:
“common-representative”: association.
“agent”: individual.
“attorney”: legal practitioner.		E.g.: “common-representative”
up-association-numberIf rep-type=“common-representative” (association), this attribute is required and must provide its registration no.E.g.: “125”

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 specifying the named of their represented applicant:

<parties>
  <agents>
    <agent sequence="1"
      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 elementSub-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-sfd-request.xml containing a single <agent> entry for a representative of type association:

<parties>
  <agents>
    <agent sequence="1"
      rep-type="common-representative"
      up-association-number="12345">
      <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>

UP(7038) - Documents​

The Documents tab in Form UP(7038) allows for attaching documents containing translations, authorisations, requests, legal remedies and other documents. See the complete list in chapter Document codes and file types for UP(7038). In general, only PDF documents are allowed.

ℹ️ Note

Please note that certain documents must not be attached at the same time (i.e., public and non-public documents) as they are mutually exclusive. Please use separate forms for public and non-public submissions to the EPO.

Each attached file appears as a child element both in the <check-list> and the <office-specific-data> elements in up-sfd-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 UP(7038).

For each document attached with the submission, a <up-electronic-files> element inside section <office-specific-data> must be present in up-sfd-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 UP(7038) for a full reference list.

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

XML ElementDescription, 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 EP7038 request document itself (doc-type="7038") 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 UP(7038) for a full list).
E.g.: <up-file-name>UTRAN-1.pdf</up-file-name>

Section <check-list> in up-sfd-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 ElementDocument typeValue and/or Attributes
<cl-request>UP7038 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”

Please see the examples provided in the sub-chapters below for further details.

Public Documents​

XML up-sfd-request.xml

<check-list>
  <cl-request/>
  <cl-other-document>Translation of the patent</cl-other-document>
  <cl-other-document>General authorisation</cl-other-document>
  <cl-other-document>Other document</cl-other-document>
</check-list>
<office-specific-data office="EP" lang="en">
  <up-declarations/>
  <up-electronic-files doc-type="7038">
    <applicant-file-name/>
    <up-file-name>UP7038.PDF</up-file-name>
  </up-electronic-files>
  <up-electronic-files doc-type="UTRAN">
    <applicant-file-name>traductione_italiano.pdf</applicant-file-name>
    <up-file-name>UTRAN-1.pdf</up-file-name>
  </up-electronic-files>
  <up-electronic-files doc-type="1004">
    <applicant-file-name>General_authorisation.pdf</applicant-file-name>
    <up-file-name>1004-1.pdf</up-file-name>
  </up-electronic-files>
  <up-electronic-files doc-type="INCANNEX-UPP">
    <applicant-file-name>Other_details.pdf</applicant-file-name>
    <up-file-name>INCANNEX-UPP-1.pdf</up-file-name>
  </up-electronic-files>
</office-specific-data>

Non-public Documents​

XML up-sfd-request.xml

<check-list>
  <cl-request/>
  <cl-other-document>Medical certificate</cl-other-document>
  <cl-other-document>Non-public document</cl-other-document>
</check-list>
<office-specific-data office="EP" lang="en">
  <up-declarations/>
  <up-electronic-files doc-type="7038">
    <applicant-file-name/>
    <up-file-name>UP7038.PDF</up-file-name>
  </up-electronic-files>
  <up-electronic-files doc-type="UMEDA">
    <applicant-file-name>medical_cert.pdf</applicant-file-name>
    <up-file-name>UMEDA-1.pdf</up-file-name>
  </up-electronic-files>
  <up-electronic-files doc-type="UDOC-NP">
    <applicant-file-name>Other_details.pdf</applicant-file-name>
    <up-file-name>UDOC-NP-1.pdf</up-file-name>
  </up-electronic-files>
</office-specific-data>

UP(7038) - Fees​

Fees are not automatically selected in the Fees tab of form UP(7038). OLF2.0 users need to manually check the specific fees that they want to pay. The reduction and the fee amount can be modified in the GUI. For the data in the XML file, however, this is not significant, because the <fee-sub-amount>, <fee-factor> and <fee-schedule> elements just have to be filled using the appropriate values.

ℹ️ 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).

Filing non-public documents and paying fees

When attaching non-public documents to your application, only the following fees can be selected:

  • 026 – Extracts from the European Patent Register
  • 027 – Inspection of the files
  • 029 – Certified copy of application; priority document

For all other fees, a separate submission is required.

The XML data structure of fee payment details data for the UP(7038) form in up-sfd-request.xml is similar to the previously described forms, using XML element <up-financial-data> as a container 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-sfd-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-sfd-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.

Additionally, and if a 15% reduction in renewal fees for statement concerning licences of right (Rule 12 UPR, Article 3 RFeesUPP) is to be applied, an empty XML element <fee-reduction-licences-of-rights-15/> must also be present under <up-financial-data> to indicate this.

Below is a snippet showing the basic structure of both elements <mode-of-payment> and <reimbursement>, including the described 15% reduction in renewal fees:

...
<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">
    ...
  </fees>
  <fee-reduction-licences-of-rights-15/>
</up-financial-data>
...

Fee selection​

Information regarding the UP7038 selected fees is imported from the <standard-fee> XML element under <fees> in up-sfd-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" for fee 713, “22”, for fee 022...
  • topay: yes/no value indicating if the corresponding fee is intended to be paid (“yes”) or not (“no”).

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

XML ElementDescription, 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. I.e., this value should be equal to:
E.g., for a quantity of 2 and a reduction of 30% (0.3), this value should be 1.4.
If the fee is not selected for payment (topay="no"), this element can be empty.
Note that, when using element <fee-reduction-amount> to apply a fixed reduction (when applicable according to the guidelines), this value should be a negative amount instead of a 0-1 factor. E.g., for a reduction of 100%:
<fee-factor>-1460</fee-factor> <fee-sub-amount>1460.00</fee-sub-amount> <fee-reduction-amount>1460</fee-reduction-amount>
<fee-schedule>Indicates the amount to pay for the total quantity of the specified fee, after applying reductions. I.e., this value should be equal to:
<fee-sub-amount> * quantity (i.e., number of fees as indicated in GUI) * <fee-reduction-factor> (from 0 to 1)
E.g.: 94.50
<fee-sub-amount>Indicates the base amount for the fee according to the current fee schedule (i.e., not taking reductions into account). E.g.: 135.00
If the fee is not selected for payment (topay=”no”), this element can be empty.
<fee-reduction-factor>Indicates the reduction factor (from 0 to 1, corresponding to a 0-100% percentage) for the fee, when applicable. E.g.: 0.30
This element can be left empty if the fee is not selected for payment (topay=”no”) or 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).

Use the <fee-reduction-factor> element to indicate a fee reduction on a fixed or percentage basis. The default value is 0.

Use the <fee-reduction-amount> element to indicate a fee reduction on an amount basis.

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.

An example is provided below with some of the available applicable fee options selected, “Debit from deposit account” selected as mode of payment and providing refund instructions:

XML up-sfd-request.xml

<up-financial-data curr="EUR" fee-amounts-unlocked-by-user="no">
  <mode-of-payment currency="EUR" accno="28123456" deferred-execution-date="20220627"
    mode-type="deposit">IP Department</mode-of-payment>
  <reimbursement accno="28456123">IP Department</reimbursement>
  <fees date="20220401">
    <standard-fee>
      <fee index="22" topay="no">
        <type-of-fee>standard</type-of-fee>
        <fee-factor user-input="0">0</fee-factor>
        <fee-schedule>0</fee-schedule>
        <fee-sub-amount>110</fee-sub-amount>
        <fee-reduction-factor>0</fee-reduction-factor>
      </fee>
      <fee index="23" topay="yes">
        <type-of-fee>standard</type-of-fee>
        <fee-factor user-input="1">1</fee-factor>
        <fee-schedule>110</fee-schedule>
        <fee-sub-amount>110</fee-sub-amount>
        <fee-reduction-factor>0</fee-reduction-factor>
      </fee>
      <fee index="29" topay="yes">
        <type-of-fee>standard</type-of-fee>
        <fee-factor user-input="1">1</fee-factor>
        <fee-schedule>110</fee-schedule>
        <fee-sub-amount>110</fee-sub-amount>
        <fee-reduction-factor>0</fee-reduction-factor>
      </fee>
      <fee index="30" topay="no">
        <type-of-fee>standard</type-of-fee>
        <fee-factor user-input="0">0</fee-factor>
        <fee-schedule>0</fee-schedule>
        <fee-sub-amount>110</fee-sub-amount>
        <fee-reduction-factor>0</fee-reduction-factor>
      </fee>
      <fee index="732" topay="yes">
        <type-of-fee>standard</type-of-fee>
        <fee-factor user-input="1">0.85</fee-factor>
        <fee-schedule>29.75</fee-schedule>
        <fee-sub-amount>35</fee-sub-amount>
        <fee-reduction-factor>0.15</fee-reduction-factor>
      </fee>

    </standard-fee>
    <fee-total-amount>249.75</fee-total-amount>
  </fees>
  <fee-reduction-licences-of-rights-15/>
</up-financial-data>

UP(7038) - Annotations​

Representation of data in the Annotations tab in UP(7038) in the XML files is done exactly in the same way as in UP7000 forms. 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-sfd-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 ElementDescription 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 UP7038.
<dtext>Text contents of the annotation.

The example below shows how a single annotation is stored:

XML up-sfd-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>