WIPO Sequence Validator Bedienungsanleitung

1. Workflow

Das Tool bietet die folgenden vier Anwendungsfälle:

1. Validierung einer WIPO ST.26-Datei.
2. Abfragen des Status einer momentan ausgeführten Validierung.
3. Aktualisierung der Konfigurationsdateien (nur IP-Amt Admin).
4. Aufrufen eines Callback-Endpunkts mit dem Ergebnis des Validierungsprozesses, sobald der Validierungsprozess abgeschlossen ist.

Hinweis: Dieser Callback-Endpunkt liegt außerhalb des Geltungsbereichs des Validators.  Es obliegt den Ämtern, die diesen Dienst entwickeln und einrichten, den Endpunkt zu erstellen.

Für die Validierung des WIPO ST.26 Sequenzprotokolls greift das Tool auf XML-Instanzen zurück, die sich in einer Ordnerstruktur befinden, führt einen Validierungsprozess durch und erstellt einen Prüfbericht mit den Validierungsergebnissen. Wahlweise kann es diesen Prüfbericht durch Aufruf eines Callback-Endpunkts zurückgeben.

Der Haupt-Workflow des Validators umfasst die folgenden Schritte:

• Das entsprechende IT-System des IP-Amts speichert eine XML-Datei in einem „Inbox“ Standardordner oder dem in der Anforderung angegebenen Ordner.
• Das System des IP-Amts initiiert einen HTTP-Post, der die Validierung der Datei anfordert. Je nach Konfiguration kann das System des IP-Amts eine „vollständige“ oder eine „Formalitäts“-Validierung der Datei anfordern.  Während des „Formalitäts“-Validierungsprozesses wird geprüft, ob es sich bei der ST.26-Datei um eine XML-Datei handelt. Zudem wird sie gegen die ST.26 DTD validiert.  Bei dem „vollständigen“ Validierungsprozess wird die ST.26-Datei anhand der aus dem Inhalt der ST.26 abgeleiteten Geschäftsprüfungsregeln validiert und der „Formalitäts“-Validierungsprozess durchgeführt.  

Hinweis: Es wird empfohlen, den „Formalitäts“-Validierungsprozess nur für das Online-Einreichungssystem zu verwenden, da dieser synchron durchgeführt werden kann. Die „vollständige“ Validierung wird dagegen für die Batchverarbeitung empfohlen, da sie wesentlich länger dauert. 

• Sobald die Validierung abgeschlossen ist, wird in einer Antwort angegeben, ob die Datei die „Formalitäts“-Validierung bestanden hat und darüber hinaus ob die Geschäftsregelvalidierung korrekt gestartet wurde, für den Fall, dass das IT-System des IP-Amts die „vollständige“ Validierung ausgewählt hat.
• Führt der Validator eine „vollständige“ Validierung durch, ruft er die XML-Datei aus dem „Inbox“-Ordner ab und startet die Geschäftsprüfregelvalidierung. Anschließend führt er Folgendes aus:
• Der Validator generiert eine XML-Prüfberichtsdatei („Verification Report“) in einem festgelegten „Output“-Ordner und verschiebt die validierte WIPO ST.26-XML-Datei in einen „Outbox“-Ordner.
• Nachdem die Geschäftsregelvalidierung abgeschlossen ist, wird der Callback-Endpunkt, sofern konfiguriert, vom Validator aus aufgerufen und die Anforderung wird mit zusätzlichen Informationen zum Validierungsprozess aufgefüllt. Die Struktur der Anforderung und einige Beispieldaten finden Sie nachfolgend in Abschnitt 2.2.
• Der Callback-Endpunkt sollte in der Antwort entweder einen leeren Code einen Erfolgscode zurückgeben (keine Fehler). [Hinweis: Dieser Schritt wird nur ausgeführt, wenn der externe Webdienst zur Verfügung gestellt und der Aufruf im Validator konfiguriert wurde.] Hierfür ist auch eine Verbindung zwischen dem Validator und dem Callback-Endpunkt ist ebenfalls erforderlich.  Wie es bereits erwähnt, ist der externe Webdienst nicht Bestandteil des Validators und sollte von den Ämtern entsprechend dem weiter unten definierten Vertrag entwickelt und konfiguriert werden.
• Das System des IP-Amts kann den Prüfbericht aus dem „Report“-Ordner abrufen.

2. Einsatz

Schritt 1: Format wählen

Der Validator wird, wie vorstehend erläutert, in einem von zwei Binärformaten bereitgestellt: als JAR-Datei, die als Webdienst ausgeführt werden kann, oder als WAR-Datei, die auf einem Tomcat-Server bereitgestellt werden kann.  Abhängig von der Art der Infrastruktur, in der das Amt den Validator einsetzen möchte, wird das IP-Amt eines der beiden Binärformate vorziehen.

Die beiden vom Validator zur Verfügung gestellten binären Formate sind:

• Binary Spring Boot JAR: Dieses binäre Format ist eine ausführbare JAR-Datei. Hierfür muss Java 17 installiert sein.
• War Package Binary: Dieses binäre Format ist für die Bereitstellung auf einem Servlet-Container vorgesehen. Hierfür ist ein mit Spring Boot 3.1.0 and Servlet Spec 4.0.1 kompatibler Anwendungsserver erforderlich, wie z.B. Tomcat 10.

In den folgenden Abschnitten wird der Einsatz des Validators als Spring Boot App und als WAR innerhalb eines Java-Anwendungsservers beschrieben.

• Service as a JAR
• Service as a WAR

In der Spring Boot JAR ist ein Server eingebettet, der die Bereitstellung der Validator-API ermöglicht, ohne dass ein separater Server benötigt wird. Dies vereinfacht die Konfiguration und den Einsatz auf der Infrastrukturebene erheblich.

Um den eingebetteten Server auszuführen, geben Sie den folgenden Befehl ein, wenn Java 17 bereits auf dem Server installiert ist:

java -jar wipo-sequence-validator.jar

Da Java die Verwendung von UTF-8 nicht garantiert, muss die Systemeigenschaft „file.encoding“ auf „UTF-8“ gesetzt werden. Standardmäßig wird der Server auf Port 8080 ausgeführt. Um den Port zu ändern, muss die Befehlszeilenoption „--server.port“ wie nachfolgend beschrieben hinzugefügt werden. Dies kann durch Einfügen der folgenden Zeile erreicht werden:

java -D"file.encoding=UTF-8" -jar wipo-sequence-validator.jar –-server.port=<port-number>

Nachdem die JAR-Datei bereitgestellt wurde, kann über die Swagger-Benutzeroberfläche auf die Validator-API zugegriffen werden, wobei das IP-Amt die folgenden Änderungen vornehmen muss: [host-name] muss durch den Hostnamen des Servers ersetzt werden:

 http://[host-name]:8080/wipo-sequence-validator/swagger-ui/index.html

Der Zugriff auf die Validator-API erfolgt über die folgenden Endpunkte:

• GET-Methode: 

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/status/validationId

• POST-Methode: 

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/validate

Standardmäßig verwendet der Validator die Standardspeichereinstellungen der Java Virtual Machine (JVM). Die maximale Heap-Größe beträgt standardmäßig ein Viertel des verfügbaren physischen Speichers. Um die maximale Heap-Größe zu ändern, muss die Option „-Xmx“ bei der Ausführung mit der folgenden Befehlszeile verwendet werden:

java -D"file.encoding=UTF-8" -Xmx[size]-jar wipo-sequence-validator.jar

Der Validator kann auch als vom Betriebssystem verwalteter Dienst installiert werden, um beispielsweise die Ausführung mit dem Start des Betriebssystems zu unterstützen. Es ist möglich, eine Spring Boot JAR-Datei auf diese Weise für alle von WIPO Sequence unterstützten Plattformen zu konfigurieren: Windows, Linux und Mac OS.

In der folgenden Anleitung wird detailliert beschrieben, wie Sie einen Systemdienst erstellen, der die JAR-Datei für jedes Betriebssystem ausführt. Sie enthält auch Informationen zur Konfiguration der verschiedenen Optionen des Dienstes und der Ausführung der Anwendung.

Beim zweiten Typ der bereitgestellten Binärdateien kann das WAR-Paket in einem vorhandenen Java-Anwendungsserver wie Apache Tomcat 10 bereitgestellt werden. Hinweis: Hierfür ist ein mit Servlet 4.0.1 kompatibler Container erforderlich.

Die folgenden Anweisungen gelten für einen Tomcat-Anwendungsserver. Hier bezieht sich

$TOMCAT_ROOT

auf den Stammordner des Tomcat-Servers. Dieser Wert sollte durch den entsprechenden Wert für den Dateipfad ersetzt werden:

• Server stoppen:

  $TOMCAT_ROOT\bin\catalina.bat stop

• WAR kopieren nach:

  $TOMCAT_ROOT\webapps\wipo-sequence-validator.war

• Server starten:

  $TOMCAT_ROOT\bin\catalina.bat start

Hinweis: Da Java die Verwendung von UTF-8 nicht garantiert, muss die Systemeigenschaft „file.encoding“ beim Start des Anwendungsservers auf „UTF-8“ gesetzt werden. Fügen Sie dazu die Zeile: -D"file.encoding=UTF-8" ein.

Die Validator-API kann wie bereits beschrieben über eine Swagger-Benutzerschnittstelle aufgerufen werden:

http://host-name:8080/wipo-sequence-validator/swagger-ui/index.html

Die Validator-API ist über die folgenden Endpunkte zugänglich, wobei [host-name] durch den Hostnamen des Servers ersetzt werden muss:

• GET-Methode:

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/status/validationId

• POST-Methode:

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/validate 

Standardmäßig wird der Server auf Port 8080 ausgeführt. Um diesen auf einen anderen Port umzustellen, muss die Tomcat-Konfigurationsdatei entsprechend den hier gegebenen Anweisungen geändert werden:

https://tomcat.apache.org/tomcat-10.0-doc/config/index.html

Standardmäßig verwendet der Validator die Standardspeichereinstellungen der Java Virtual Machine (JVM). Die maximale Heap-Größe beträgt standardmäßig ein Viertel des verfügbaren physischen Speichers.

Um die maximale Heap-Größe zu ändern, muss wie oben angegeben beim Ausführen über die Befehlszeile die Option Xmx verwendet werden.

Schritt 2: Ordnersystem einrichten

Die Struktur des vom Validator verwendeten Dateisystems besteht aus fünf Hauptordnern:

• „Inbox“-Ordner: Dies ist der lokale Ordner, in dem WIPO ST.26-Dateien von einem IP-Amt zur Validierung bereitgestellt werden.
• - „Process“-Ordner: Dies ist der lokale Ordner, den die in der „Inbox“ befindlichen Dateien während der Verarbeitung vorübergehend durchlaufen. Dieser Ordner enthält zwei Unterordner:
  • „Full validation“-Ordner (vollständige Validierung): Hier werden die Dateien gespeichert, die auf eine vollständige Validierung warten.
  • „Formality validation“-Ordner (Formalitätsvalidierung): Hier werden die Dateien gespeichert, die auf eine Formalitätsvalidierung warten.
• „Outbox“-Ordner: Dies ist der lokale Ordner, in dem die Anwendung nach Abschluss der Validierung die Quelldatei der WIPO ST.26-Datei speichert.
• „Report“-Ordner: Dies ist der lokale Ordner, in dem die Ergebnisse der Validierung in einer Prüfberichtsdatei gespeichert werden.
• „Params“-Ordner: Dies ist der lokale Ordner, in dem sich eine JSON-Datei (.json) mit allen Validierungsparametern aus der Validierungsanforderung befindet, um Parameter für den asynchronen tiefen Validierungsprozess bereitzustellen.

Eine Beispielstruktur des Dateisystems finden Sie unten:

Schritt 3: Testen

Sie können den Validator-Dienst mit postman testen. Führen Sie dazu die folgenden Schritte durch:

• Öffnen Sie die postman-Anwendung und erstellen Sie eine neue Anfrage.
• Fügen Sie die Informationen des Anfragekörpers hinzu: .
• Nachdem Sie auf „Senden“ geklickt haben, sollte die Antwort so aussehen: .

3. Anfrage

Callback-Endpunkt-Anfrage

Der WIPO Sequence Validator erzeugt nach Abschluss der Validierungsanfrage eine JSON-Datei mit den notwendigen Parametern für eine Anfrage an einen Callback-Endpunkt. Die Anfrage sollte die folgenden Parameter enthalten, die die Dateispeicherorte und den Validierungsprozess näher beschreiben:

{
 "currentApplicationNumber": "string",
 "currentSEQLVersionNumber": "string",
 "patentApplicationNumber": "string",
 "seqlInputLocation": "string",
 "verificationReportOutputPath": "C:/temp/st26/reports/",
 "nameFile": "valid2Warning.xml",
 "type": "FULL"
}

Das Feld „seqlInputLocation“ der Validierungsanfrage sollte so festgelegt werden, dass der Pfad des zu validierenden XML-Sequenzprotokolls angegeben wird. Lässt das Amt dieses Feld leer, versucht das Tool, die XML-Datei mit dem Dateinamen „nameFile“ im standardmäßigen „Inbox“-Ordner zu validieren. Der Parameter „nameFile“ gibt die zu validierende Sequenzprotokolldatei an.

„verificationReportOutputPath“ innerhalb der Anfrage gibt den Dateispeicherort des vom Tool generierten Prüfberichts (.xml) an. Lässt der Benutzer das Feld leer oder gibt er einen ungültigen Dateipfad ein, wird der Prüfbericht im standardmäßigen „Reports“-Ordner gespeichert.

Ist die Eigenschaft „api.URL“ konfiguriert, wird der Validator versuchen, die Ergebnisse der Validierung an einen Endpunkt mit der angegebenen URL zu senden.

Um mit dem Validator kommunizieren zu können, muss der Callback-Endpunkt mit dem Webservicevertrag (YAML) konform sein.

Außerdem sollte die Anfrage ein JSON-Objekt mit dieser Struktur sein:

{
  "currentApplicationNumber": "string",
  "currentSEQLVersionNumber": "string",
  "elapsedTime": 0,
  "endTime": "string",
  "errorSummary": [
    {
      "dataElement": "string",
      "detectedSequence": "string",
      "index": 0,
      "key": "string",
      "locmessage": "string",
      "params": {
        "additionalProp1": "string",
        "additionalProp2": "string",
        "additionalProp3": "string"
      },
      "paramsForXML": [
        {
          "key": "string",
          "value": "string"
        }
      ],
      "reportValue": "string",
      "sequenceIDNumber": "string",
      "type": "string"
    }
  ],
  "httpStatus": "string",
  "parentApplicationNumber": "string",
  "parentSEQLVersionNumber": "string",
  "processID": "string",
  "seqIDQuantity": 0,
  "seqInputQuantity": 0,
  "seqlType": "string",
  "startTime": "string",
  "totalErrorQuantity": 0,
  "totalWarningQuantity": 0,
  "verificationReportOutputPath": "string"

Dies ist ein Beispiel für ein JSON-Objekt, das an den externen Endpunkt gesendet wird, der den Validator aufgerufen hat:

{
    "processID": "1608194222169dvVE",
    "seqlType": "ST.26",
    "httpStatus": "SUCCESS",
    "currentApplicationNumber": "string",
    "currentSEQLVersionNumber": "string",
    "parentApplicationNumber": "string",
    "parentSEQLVersionNumber": "string",
    "verificationReportOutputPath": "C:/temp/report.xml",
    "startTime": "2020-12-17 09:36:54.000000",
    "endTime": "2020-12-17 09:37:26.000607",
    "elapsedTime": 32607,
    "totalWarningQuantity": 1,
    "totalErrorQuantity": 2,
    "seqInputQuantity": 3,
    "seqIDQuantity": 3,
    "errorSummary": [
        {
            "index": 0,
            "reportValue": "",
            "type": "WARNING",
            "params":com.wipo.st26.ipotool.models.ServiceRequest@5887858,
            "key": "X_EARLIEST_PRIO_APPLICATION_ID_MISSING",
            "locmessage": "Earliest priority application information is absent. It must be provided when a priority claim is made to an earlier application.",
            "detectedSequence": "",
            "dataElement": "PROPERTY_NAMES.EARLIEST_PRIORITY_APPLICATION"
        },
        {
            "index": 0,
            "reportValue": "-",
            "type": "ERROR",
            "params": {},
            "key": "INVENTION_TITLE_MISSING",
            "locmessage": "The invention title is missing. At least one invention title must be entered.",
            "detectedSequence": "",
            "dataElement": "PROPERTY_NAMES.INVENTION_TITLE_BAG"
        },
        {
            "index": 1,
            "reportValue": "-",
            "type": "ERROR",
            "params": {},
            "key": "INVENTION_TITLE_MISSING",
            "locmessage": "The invention title is missing. At least one invention title must be entered.",
            "detectedSequence": "",
            "dataElement": "PROPERTY_NAMES.INVENTION_TITLE_BAG"
        }
    ]
}

4. Bericht

Prüfbericht

Der von WIPO Sequence erstellte Prüfbericht liegt im XML-Format und optional im HTML-Format vor, wobei dasselbe Stylesheet verwendet wird, das auch in WIPO Sequence verwendet wird. Die auf der Root-Ebene angegebenen Attribute sind:

• „applicationNumberText“: Die Anmeldung, die diesem Sequenzprotokoll zugeordnet ist.
• „productionDate“: Das Datum, an dem die Validierung durchgeführt wurde.
• „filingDate“: Das Datum, an dem die Anmeldung eingereicht wurde.
• „softwareBuildVersion“: Die für die Validierung verwendete Version des Validators.
• „softwareVersion“: Die Version von WIPO Sequence, die zur Erzeugung des Sequenzprotokolls verwendet wurde.
• „sourceFileName“: Der Name der XML-Instanz des Sequenzprotokolls.

Die Vorlage oder XSD, die zur Erstellung des Prüfberichts verwendet wird, lautet wie folgt:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerificationReport productionDate="YYYY-MM-DD" sourceFileName="[ST.26 filename]">
    <VerificationMessageBag>
        <VerificationMessage>
            <Severity>[ERROR | WARN | XML_WARN |  XML_ERROR]</Severity>
           <DataElement>[ST.26 element]</DataElement>
            <DetectedSequence>[Sequence ID]</DetectedSequence>
            <DetectedValue>[value]</DetectedValue>
            <MessageKey>[Message key]</MessageKey>
           <ParameterBag>
	            <Parameter key="param key">Param value</Parameter>
            <ParameterBag>
            <LocalizedMessage> [Localized message] </LocalizedMessage>
        </VerificationMessage>

...

    </VerificationMessageBag>
</VerificationReport>

Warn- und Fehlermeldungen haben in Bezug auf ihren Schweregrad folgende Abstufungen:

• ERROR - Beschreibt einen Fehler, der während der vollständigen („FULL“) Prüfung angezeigt wurde
• WARNING - Beschreibt eine Warnung, die während der vollständigen („FULL“) Prüfung angezeigt wurde
• XML_ERROR - Beschreibt einen Fehler, der während der Formalitätsprüfung („FORMALITY“) angezeigt wurde
• XML_WARN - Beschreibt eine Warnung, die während der Formalitätsprüfung („FORMALITY“) angezeigt wurde

Nach der Validierung wird der in einem oder beiden Formaten erstellte Prüfbericht unter dem „verificationReportOutputPath“ gespeichert, standardmäßig unter:

./temp/st26/reports/[verificationID]/

Ein Beispiel des Prüfberichts im XML-Format finden Sie in den nachstehenden Ressourcen.

5. Konfiguration

Standardeinstellungen

Der Validator wird mit Hilfe einer Eigenschaftsdatei konfiguriert. Die Standardwerte finden Sie in *der veröffentlichen Anwendung „application.yml“.

Um den Wert der angegebenen Parameter zu ändern, wird empfohlen, eine alternative „application.yml“-Datei zu werdenden. Eine detaillierte Beschreibung der verschiedenen Optionen finden Sie in der Spring Boot Dokumentation.

Der Pfad und Name der Konfigurationsdatei kann beim Starten des Tools durch Angabe des Parameters in der Befehlszeile angegeben werden:

• Für den Einsatz mit JAR:

  java  -jar -Dspring.config.location= <PATH_TO_FILE> wipo-sequence-validator.jar

• Für den Einsatz mit WAR auf Tomcat sollte der folgende Eintrag zu CATALINA_OPTS hinzugefügt werden:
  • Windows:

    set SPRING_CONFIG_ADDITIONAL-LOCATION=-Dspring.config.location=<PATH_TO_FILE>

  • Linux:

    export SPRING_CONFIG_ADDITIONAL-LOCATION="-Dspring.config.location=<PATH_TO_FILE>

Wenn Sie WAR verwenden, können Sie die neue „application.yml“-Datei auch in den Ordner „WEB-INF/classes“ der Webanwendung kopieren.

In der „application.yml“-Datei können Sie die Generierung von HTML-Berichten aktivieren und deaktivieren. Benutzen Sie den Wert „true“, um die Berichterstellung zu aktivieren, und den Wert „false“, um sie zu deaktivieren. Der Inhalt dieses Berichts wird an den Callback-Endpunkt innerhalb des Feldes „errorSummary“ des „ServiceRequest“ gesendet.

Prüfregel VXQV_49

Der Wert „optionalEnglishQualifierValue“ kann auf „true“ gesetzt werden, wenn der Benutzer die Regel VXQV_49 aktivieren möchte, und der Schweregrad der Regel kann durch Aktualisieren des Wertes „optionalRuleType“ auf „ERROR“ oder „WARNING“ festgelegt werden.

Healthpoint

Der Validator-Dienst verfügt über einen Endpunkt „/health“, der Basisinformationen über den Zustand („health“) der Anwendung liefert. Öffnen Sie die folgende URL, um den Endpunkt „/health“ einzusehen:

Der Endpunkt sollte Folgendes anzeigen:

• Der Zustand ist „UP“ wird angezeigt, wenn die Anwendung in fehlerfreiem Zustand ist.
• Der Zustand „DOWN“ wird angezeigt, wenn die Anwendung aufgrund von Problemen fehlerhaft wird, z.B. bei Verbindungsproblemen mit der Datenbank, zu wenig Festplattenspeicherplatz usw.

Der Endpunkt „/health“ zeigt lediglich einen einfachen „UP“- oder „DOWN“-Zustand an. Die folgende Eigenschaft der „application.yml“-Datei liefert vollständige Details, einschließlich des Status aller Zustandsindikatoren, der im Rahmen der Zustandsprüfung überprüft wurden.

Der Endpunkt „health“ enthält jetzt die Details des DiskSpaceHealthIndicator, der im Rahmen der Zustandsprüfung ausgeführt wird.

Der Endpunkt „health“ wird auf diese Weise angezeigt:

Lokalisierte Meldungen

Der Validator kann eine lokalisierte Meldung, z.B. im Prüfbericht, in jeder der zehn offiziellen PCT-Sprachen (Arabisch, Chinesisch, Deutsch, Englisch, Französisch, Japanisch, Koreanisch, Portugiesisch, Russisch, und Spanisch) bereitstellen.

Standardmäßig werden diese Meldungen in Englisch bereitgestellt. Um den Validator so zu konfigurieren, dass er diese Meldungen in anderen Sprachen bereitstellt, muss der Parameter „validator_locale“ der „application.yml“-Datei auf den entsprechenden Sprachcode eingestellt werden.

Benutzerdefinierte Organismusnamen

Damit Ämter ihre eigenen benutzerdefinierten Organismusnamen aufnehmen können, die nicht Bestandteil der ursprünglichen vordefinierten Liste von Organismusnamen sind, kann eine Liste benutzerdefinierter Organismen bereitgestellt werden. Hierfür wird eine neue Datei mit dem Namen „custom_organism.json“ im Ordner „alternativeResourceBasePath“ erstellt. Diese Datei sollte folgende Struktur haben:

Alternative DTD-Version

Standardmäßig referenziert der Validator die neueste Version von ST.26 DTD. Die aktuelle Version des WIPO Sequence Validators basiert auf Version 1.3 von WIPO ST.26 DTD. Diese Kopie der neuesten ST.26 DTD Version finden Sie in der Validator-Bibliothek im Ordner „/src/main/resources“ des Source-Codes (dies ist der definierte Dateipfad, auf den in der JAR- bzw. WAR-Datei verwiesen wird). Sie ist in der „catalog.xml“-Datei im selben Ordner referenziert.

Bei der Validierung wird die Version der DTD verwendet, die in der DOCTYPE-Deklaration der XML-Datei festgelegt wurde. Zunächst wird die „publicId“ verwendet, um den Speicherort der zu verwendenden DTD-Datei zu identifizieren. Ist die „publicId“ nicht im Katalog enthalten, versucht das System, die DTD-Datei im Stammverzeichnis zu finden, in dem der Java-Prozess ausgeführt wird.

Um WIPO ST.26-Dateien validieren zu können, die auf eine ältere Version der ST.26 DTD verweisen, muss diese ST.26 DTD-Datei dem Validator zur Verfügung gestellt werden, um eine entsprechende Validierung zu ermöglichen. Um dies zu erreichen, gibt es zwei alternative Ansätze:

1. Entpacken Sie die JAR-Datei und fügen Sie dem Ordner „src/main/resources“ einen Verweis auf die zusätzliche oder alternative ST.26-DTD-Datei hinzu. Ändern Sie die Datei „catalog.xml“ und fügen Sie einen neuen Eintrag für die zusätzliche ST.26 DTD hinzu oder bearbeiten Sie den bereits vorhandenen Eintrag. Zum Beispiel:

1. Anstatt die JAR-Datei zu ändern, wird empfohlen, die folgenden Schritte zu befolgen:
   (i) Kopieren Sie „catalog.xml“ und alle DTDs in einen lokalen Ordner.
   (ii) Ändern Sie „catalog.xml“ so, dass es einen Verweis auf die zusätzliche ST.26-DTD enthält.
   (iii) Setzen Sie abschließend die folgende Java-Systemeigenschaft beim Programmstart: „xml.catalog.files=<path_to_catalog.xml>“.

In Tomcat für Windows erreichen Sie dies, indem Sie die folgende Umgebungsvariable hinzufügen:

6. Ressourcen

Die folgenden Ressourcen können für IP-Ämter hilfreich sein:

• Beispiel Prüfbericht
• Vollständige API-Spezifikation, YAML
• Eigenschaftsnamen, JSON