Versions Compared

Old Version 7

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.

...

  • 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

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:
    • INTERNATIONAL_DESIGN_APPLICATION, for


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.

...

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>

...

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

...

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

...