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.
Table of contents
Payload contents
Payloads consist in a ZIP file containing 3 kinds of information:
...
- 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
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:
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):
...
2. Instructions to debit from a Current Account at WIPO
| Code Block |
|---|
|
<com:Payment>
<com:PaymentModeCategory>Current account</com:PaymentModeCategory>
<com:PaymentMethod>
<com:CurrentAccount>
<!-- Account Number -->
<com:AccountNumber>123456</com:AccountNumber>
<!-- Holder of the account -->
<com:AccountHolderName>
<com:PersonName>
<com:PersonFullName>Someone who has a current account</com:PersonFullName>
</com:PersonName>
</com:AccountHolderName>
</com:CurrentAccount>
</com:PaymentMethod>
<!-- Identity of the party giving the instruction -->
<com:PayerName>
<com:EntityName>Jane Doe</com:EntityName>
</com:PayerName>
<com:FeePayableTotalAmount>12345.00</com:FeePayableTotalAmount>
</com:Payment> |
3. Payment received and acknowledged by WIPO
| Code Block |
|---|
|
<com:Payment>
<!-- WIPO Receipt Number -->
<com:PaymentIdentifier>HAG/PayRef12345</com:PaymentIdentifier>
<com:PaymentModeCategory>Payment already made</com:PaymentModeCategory> <!-- Proposed for Version 7.0 of ST96 -->
<!-- Identity of the party which made the payment -->
<com:PayerName>
<com:EntityName>Jane Doe</com:EntityName>
</com:PayerName>
<com:FeePayableTotalAmount>12345.00</com:FeePayableTotalAmount>
</com:Payment> |
4. Bank transfer
| Code Block |
|---|
|
<com:Payment>
<com:PaymentModeCategory>Bank draft</com:PaymentModeCategory>
<com:PaymentMethod>
<com:BankTransfer>
<!-- Payment Identification: -->
<com:BankTransferIdentifier>Payment Ref 2</com:BankTransferIdentifier>
<!-- day/month/year: -->
<com:BankTransferDate>2022-12-25</com:BankTransferDate>
<com:DestinationBankAccount>WIPO bank account no</com:DestinationBankAccount> <!-- or WIPO Postal account -->
</com:BankTransfer>
</com:PaymentMethod>
<!-- Identity of the party which made the payment -->
<com:PayerName>
<com:EntityName>Jane Doe</com:EntityName>
</com:PayerName>
<com:FeePayableTotalAmount>12345.00</com:FeePayableTotalAmount>
</com:Payment> |
5. Payment made to the Office
| Code Block |
|---|
|
<com:PaymentBag>
<com:Payment>
<com:PaymentIdentifier>xxxxxxxxx</com:PaymentIdentifier>
<com:PaymentMethod>
<com:OtherPaymentMethod>Payment made to the office of indirect filing</com:OtherPaymentMethod>
</com:PaymentMethod>
<com:PaymentDate>2021-09-30</com:PaymentDate>
<com:FeePayableTotalAmount com:currencyCode="CHF">1981</com:FeePayableTotalAmount>
</com:Payment>
</com:PaymentBag> |
...
| Code Block |
|---|
|
<!-- 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</com:PaymentModeCategory> <!-- Proposed for Version 7.0 of ST96 -->
<com:FeePayableTotalAmount>12345.00</com:FeePayableTotalAmount>
</com:Payment> |
Samples
The below examples are all ST.96 4.0 compliant.
Indirect Filing
- Indirect Filing with Light-Structured Data (updated on Mar. 8, 2022)
- CN is live with this output.
- Indirect Filing with Light-Structured Data & Image References (updated on Mar. 15, 2022)
- CN is live with this output.
- Indirect Filing with Full-Structured Data & principal/related design information for CN and KR: Example of XML
- In this application, there are 3 designs. CN and KR are designated. Design 1 is the principal design. KR considers that only design 2 relates to design 1. CN enforces that all designs are "similar" (not related) to design 1. This last case is subject to amendments in a future version of ST.96.
- Indirect Filing with Full-Structured Data & payment to the office of indirect filing: Example of XML
- This case is subject to amendments in a future version of ST.96.
- Indirect Filing with Full-Structured Data & payment to the IB: Example of XML
- KR is live with this output.
Decisions