Versions Compared

Old Version 8

changes.mady.by.user erwann CHANDON

Saved on

compared with

New Version Current

changes.mady.by.user erwann CHANDON

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Whether your Office is using Hague Web Services (HWS) or EDI SFTP to interface with the Hague System, the electronic payload is the exactly same. This makes it quite easy for EDI users to migrate to HWS. The only difference is that HWS allow no more than one record per payload, whereas EDI allows multiple records in a single payload. As a consequence, EDI Offices that already send single record payloads can, from this perspective, migrate to HWS right away.

Office to IB communications are of the following sort:

  • indirect applications
  • decisions, such as:
    • grants of protection (partial or total)
    • refusals (partial or total)
    • withdrawals of refusal (partial or total)
    • declarations that a change of ownership has no effect
    • withdrawals of a declaration that a change of ownership has no effect
    • divisions
    • refusals of correction
    • withdrawals of refusal of correction
    • invalidations
    • invitations to pay the second part of the fee
    • notifications that the second part of the fee was paid
    • cancellations for non payment of the second part of the fee

...

  • bibliographic data, in ST.96 XML. The XML bibliographic data constitute the essence of the transaction from a technical perspective. It allows the transaction to be created in the Hague System in an automated manner. The more detailed the XML, the less work for the Hague examiners, therefore the faster the recording of the transaction.
  • supporting PDF documents. Supporting documents are mandatory, legal requirements that constitute the essence of the transaction from a business point of view. They MUST be stamped with a <com:DocumentKindCategory> value as per the ST.96 standard in order to be categorized correctly in the Hague System. Failing to provide the document category will prevent automated recording of the transaction, and will fail the importation of said transaction into the Hague System.
    • only one per decisions (statement of grant of protection, refusal, division, invalidation, etc.). The <com:DocumentKindCategory> choices are as follows:


Decision type

<com:DocumentKindCategory> value
refusal

REFUSAL_DECISION

grant of protection following a refusal

GRANT_OF_PROTECTION_AFTER_REFUSAL

grant of protection not following a refusal

GRANT_OF_PROTECTION_NO_PRIOR_REFUSAL

division

DIVISION

invalidation

INVALIDATION

...

  • INTERNATIONAL_DESIGN_APPLICATION, for the DM/1 form
  • POWER_OF_ATTORNEY, for US applicants designating a representative
  • MISCELLANEOUS, for any other kind of document

...

refusal of correction

REFUSAL_CORRECTION

withdrawal of a refusal of correction

REFUSAL_WITHDRAWAL_CORRECTION

declaration that a change of ownership has no effect

REFUSAL_OWNERSHIP_CHANGE

withdrawal of a declaration that a change of ownership has no effect

REFUSAL_WITHDRAWAL_CHANGE


    • as many as needed in case of indirect applications. The <com:DocumentKindCategory> choices are as follows:


Document type

<com:DocumentKindCategory> value
the DM/1 form

INTERNATIONAL_DESIGN_APPLICATION

for US applicants designating a representative

POWER_OF_ATTORNEY

any other kind of document

MISCELLANEOUS


  • JPG designs, in the case of an indirect application. The <com:DocumentKindCategory> choice is REPRODUCTION_SHEETS.

The complete documentation of the ST.96 can be found here.

The internal structure of the ZIP is unimportant. What matters is that:

  • there is one

The complete documentation of the ST.96 can be found here.

The internal structure of the ZIP is unimportant. What matters is that:

  • there is one and only one XML file inside the ZIP
  • the exact relative path of documents and designs is correctly referenced in the XML:


Accepted versions

Technical limitations

Note that a payload (aka package), as well as its contents, are subject to the following technical limitations:

  • package max size: 800 MB
  • PDF document max size: 100 MB
  • Image file max size: 100 MB
  • Image resolution: 300 dpi

Accepted versions

Although the Although the official ST.96 version in force in the Hague System is 7.0, the latter accepts the following ST.96 versions in Hague electronic payloads, for backward compatibility reasons:

...

payloads, for backward compatibility reasons:

  • 7.0
  • 4.0
  • 3.2T1

XML headers

Below is the correct header to have at the top of the XML file for it to be validated against the correct XSD:

7.0

Code Block
languagexml
<dgn:HagueOfficeToIBTransaction com:st96Version="V7_0" xmlns:com="http://www.wipo.int/standards/XMLSchema/ST96/Common" xmlns:dgn="http://www.wipo.int/standards/XMLSchema/ST96/Design" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wipo.int/standards/XMLSchema/ST96/Design https://www.wipo.int/standards/XMLSchema/ST96/V7_0/Design/Flatten/HagueOfficeToIBTransaction_V7_0.xsd">

4.0

Code Block
languagexml
<dgn:HagueOfficeToIBTransaction com:st96Version="V4_0" xmlns:com="http://www.wipo.int/standards/XMLSchema/ST96/Common" xmlns:dgn="http://www.wipo.int/standards/XMLSchema/ST96/Design" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wipo.int/standards/XMLSchema/ST96/Design https://www.wipo.int/standards/XMLSchema/ST96/V4_0/Design/Flatten/HagueOfficeToIBTransaction_V4_0.xsd">

...

Transaction main tags
The ST.96 tag to use for the various transactions that can be conveyed from your Office to the IB is as follows:
...
Transaction typeST.96 main tag
indirect application<dgn:HagueApplication>
grant of protection<dgn:HagueGrantProtectionRequest>
refusal<dgn:HagueRefusalRequest>
withdrawal of refusal
<dgn:HagueRefusalWithdrawalRequest><dgn:HagueGrantProtectionRequest dgn:priorRefusalIndicator="true">
declaration that a change of ownership has no effect
<dgn:HagueGenericOfficeCommunication>
withdrawal of a declaration that a change of ownership has no effect
<dgn:HagueGenericOfficeCommunication>
division
<dgn:HagueDivision>
refusal of correction
<dgn:HagueGenericOfficeCommunication>
invalidation
<dgn:HagueInvalidationRequest>
invitation to pay the second part of the fee
<dgn:HagueSecondPartFeePayable>
notification that the second part of the fee was paid
<dgn:HagueSecondPartFeePaid>
cancellation for non payment of the second part of the fee
<dgn:HagueCancellationNonPaymentRequest>
...
Indirect applications. through the <dgn:HagueApplication> tag (see "Samples" below), replicate the latest version of the DM/1. That includes section "Payment of fees", page 12 of the DM/1 (which can be found at https://www.wipo.int/export/sites/www/hague/en/docs/form_dm_1-editable1.pdf):
...
 Code Block
languagexml
<!-- In this case, the identity of the Office is given in the context. It is assumed to be the Office that is sending the dgn:HagueApplication -->
<com:Payment>
    <!-- A reference that must also appear on a transfer statement from the Office. This common reference is that will allow the IB to match the payment with the application -->
    <!-- This reference is given by the Office. It is not provided by the applicant -->
    <com:PaymentReference>OfficeRef12345</com:PaymentReference>
    <com:PaymentModeCategory>Payment through Office<office</com:PaymentModeCategory> <!-- Proposed for Version 7.0 of ST96 -->
    <com:FeePayableTotalAmount>12345.00</com:FeePayableTotalAmount>
</com:Payment>   
Samples
 Anchor
Hague payload samples
Hague payload samples
The below examples are all ST.96 47.0 compliant.
Indirect Filing
...