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.
Payload contents
Payloads consist in a ZIP file containing 3 kinds of information:
- bibliographic data, in ST.96 XML.
- supporting PDF documents. Supporting documents 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:
- REFUSAL_DECISION
- GRANT_OF_PROTECTION_AFTER_REFUSAL
- GRANT_OF_PROTECTION_NO_PRIOR_REFUSAL
- DIVISION
- INVALIDATION
- as many as needed in case of indirect applications. The <com:DocumentKindCategory> choices are as follows:
- INTERNATIONAL_DESIGN_APPLICATION, for the DM/1 form
- POWER_OF_ATTORNEY, for US applicants designating a representative
- MISCELLANEOUS, for any other kind of document
- only one per decisions (statement of grant of protection, refusal, division, invalidation, etc.). 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
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
- 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)
- 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)