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

Table of contents

Payload contents

Payloads consist in a ZIP file containing 3 kinds of information:

• 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:

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

• 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 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:

• 7.0
• 4.0
• 3.2T1

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:

Complete ST.96 documentation can be found here.

Note that every transaction in the table above can also be sent as a <dgn:HagueGenericOfficeCommunication>. In that case, the <dgn:HagueGenericOfficeCommunicationCategory> sub-tag carries the transaction type, as follows (and as described here):

Note on grants of protection

Grants of protection and withdrawals of refusal have the same effects from a business perspective. In practice, it means that one or the other can be used indifferently when communicating the decision that a refusal is withdrawn.

If, however, a grant of protection is pronounced, and transmitted, after a refusal and with the purpose of cancelling the latter, and if the <dgn:HagueGrantProtectionRequest> is chosen to convey the decision in question, then the dgn:priorRefusalIndicator attribute must be used and set to "true". (This attribute is optional and defaults to "false", and therefore can be omitted when transmitting grants of protection with no prior refusal.)

The choice of the <com:DocumentKindCategory> value is equally important and must be set to:

• GRANT_OF_PROTECTION_NO_PRIOR_REFUSAL if the grant of protection does not follow a refusal
• GRANT_OF_PROTECTION_AFTER_REFUSAL if the grant of protection follows a refusal

Payment information

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):

There are 4 payment methods at the moment (numbered according to the DM/1):

2. Instructions to debit from a Current Account at WIPO

3. Payment received and acknowledged by WIPO

4. Bank transfer

5. Payment made to the Office

Below are described the ways to express these different payment methods in ST.96 v4.0 and higher (when not specified). Payments methods are available at:

• https://www.wipo.int/standards/en/st96/v7-0/annex-iv/Index_PaymentModeCategoryType.html#LinkC9D (7.0)
• https://www.wipo.int/standards/en/st96/v4-0/annex-iv/Index_PaymentModeCategoryType.html#LinkC74 (4.0)

2. Instructions to debit from a Current Account at WIPO

<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

<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

<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

• Version 4.0

<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>

• Version 7.0

<!-- 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

Anchor
Hague payload samples Hague payload samples

The below examples are all ST.96 4.0 compliant.

Indirect Filing

• Indirect Filing with Light-Structured Data (updated on Jan 2, 2025)
  • CN is live with this output.
• Indirect Filing with Light-Structured Data & Image References (updated on Jan 2, 2025)
  • 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

• Refusal of Protection which applies to all the designs (updated on Mar. 8, 2022)
• Refusal of Protection which applies to some of the designs (updated on Mar. 8, 2022)
• Grant of Protection following a refusal (updated on Mar. 8, 2022)
• Grant of Protection in the absence of a prior notification of refusal (updated on Mar. 8, 2022)
• Partial Grant of Protection (updated on May 30, 2024)
• Division - example 1 (updated on Mar. 18, 2022)
• Division - example 2 (updated on Mar. 8, 2022)
• Invalidation (updated on Mar. 22, 2022)
• Declaration that a change in ownership has no effect (updated on Mar. 22, 2022)
• Refusal of a correction (updated October 15, 2024)