Manual de uso de WIPO Sequence Validator

1. Flujo de trabajo

La herramienta permite realizar las cuatro operaciones siguientes:

1. Validar un archivo para que sea conforme con la Norma ST.26 de la OMPI.
2. Solicitar información sobre el estado de una validación.
3. Actualizar los archivos de configuración (solo la administración de la Oficina de PI).
4. Llamar a un punto final de devolución de llamada con el resultado del proceso de validación una vez completado.

Nota: El punto final de devolución de llamada está fuera del alcance del Validador.  Corresponde a las Oficinas que desarrollan y ponen en marcha este servicio establecer el punto final.

Para la validación de la lista de secuencias de la Norma ST.26 de la OMPI, la herramienta utiliza instancias XML ubicadas en una estructura de carpetas, ejecuta un proceso de validación y genera un informe de verificación con los resultados de la validación. Opcionalmente, devuelve el informe de verificación llamando a un punto final de devolución de llamada.

A continuación se describen los principales pasos del flujo de trabajo del Validador:

• El sistema informático de la Oficina de PI en cuestión guarda el archivo XML en la carpeta predeterminada Inbox o en la especificada en la petición.
• El sistema de la Oficina envía una petición HTTP Post solicitando la validación del archivo. Dependiendo de la configuración, podrá solicitar una validación del archivo completa (“full”) o de forma (“formality”).  En el proceso de validación de forma se comprobará si el archivo es un archivo XML y se validará tomando como referencia la DTD prevista en la Norma ST.26.  En el proceso de validación completa se verificará si el archivo en formato ST.26 cumple las normas operativas derivadas del contenido de la Norma ST.26, además de realizarse la validación de forma.  

Nota: Se recomienda la validación de forma solo para la presentación en línea, ya que puede realizarse de forma sincronizada, mientras que la validación completa se recomienda para la ejecución por lotes, dado que requerirá mucho más tiempo. 

• Una vez finalizada la validación, se proporcionará una respuesta en la que se indicará si el archivo ha superado o no la validación de “formalidad” y, además, si la validación de las normas operativas se ha iniciado correctamente en el caso de que el sistema informático de la Oficina de PI haya seleccionado la validación “completa”.
• Si el Validador realiza una validación “completa”, recupera el archivo XML de la carpeta Inbox e inicia el proceso de validación de las reglas operativas y, a continuación, lleva a cabo lo siguiente:
• El Validador genera un archivo de informe XML (“Verification Report”) en una carpeta “Output” especificada y desplaza el archivo XML ST.26 validado a una carpeta “Outbox”.
• Una vez completado el proceso de validación de las normas operativas, el Validador llama al punto final de devolución de llamada, si está configurado, y se incluye en la petición información adicional relacionada con el proceso de validación. En el apartado 2.2 se describe la estructura de la petición y se incluyen algunos datos de ejemplo.
• El punto final de devolución de llamada no devolverá nada o devolverá un código que indique que el proceso se ha completado correctamente (sin errores). [Tenga en cuenta que este paso solo se ejecuta si el servicio web externo está disponible y la llamada se ha configurado en el Validador].  También es necesario que el Validador y el punto final de devolución de llamada estén conectados.  Como ya se ha mencionado, el servicio web externo no forma parte del Validador, sino que serán las Oficinas las que lo desarrollen y configuren de acuerdo con el contrato que se define más adelante.
• El sistema de la Oficina de PI puede recuperar el informe de verificación de la carpeta “Report”.

2. Instalación

Paso 1: Seleccionar formato

Como se ha indicado anteriormente, el Validador se proporciona en dos formatos binarios: un archivo JAR que puede ejecutarse como servicio web o un archivo WAR que puede instalarse en un servidor Tomcat.  Dependiendo del tipo de sistema en el que la Oficina quiera instalar el Validador, será preferible seleccionar un tipo de archivo binario u otro.

Los dos formatos de archivo binario en el que se ofrece el Validador son:

• Archivo binario JAR de Spring Boot: archivo JAR ejecutable. Requiere que Java 17 esté instalado.
• Archivo binario WAR: archivo que se ejecuta en un contenedor servlet. Se requiere un servidor de aplicaciones compatible con Spring Boot 3.1.0 y Servlet Spec 4.0.1, como Tomcat 10.

En las siguientes secciones se explica la instalación del Validador como una aplicación Spring Boot o como un archivo WAR en un servidor de aplicaciones Java.

• Servicio JAR
• Servicio WAR

El archivo JAR de Spring Boot contiene un servidor que permite instalar la API del Validador sin necesidad de un servidor externo. Esto simplifica enormemente la configuración y el despliegue a nivel de infraestructura.

Para ejecutar el servidor integrado, debe ejecutarse el siguiente comando cuando Java 17 ya esté instalado en el servidor:

java -jar wipo-sequence-validator.jar

Para que Java permita abrir archivos en formato UTF-8, deberá asignarse a la propiedad del sistema “file.encoding” el valor “UTF-8”. Por defecto, el servidor se ejecutará en el puerto 8080. Para modificarlo, deberá añadirse la opción “--server.port” en la línea de comandos, como se indica a continuación. Para ello puede incluirse:

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

Se puede acceder a la API del Validador mediante la interfaz de usuario Swagger después de instalar el archivo JAR, donde la Oficina de PI debe realizar los siguientes cambios: [host-name] debe sustituirse por el nombre del servidor:

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

Se puede acceder a la API del Validador en los siguientes puntos finales:

• Método GET: 

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

• Método POST: 

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

Por defecto, el Validador utilizará la configuración predeterminada de la memoria de la máquina virtual Java. El tamaño máximo de almacenamiento predeterminado para la asignación dinámica de memoria es una cuarta parte de la memoria física disponible. Para modificar ese tamaño máximo, hay que utilizar la opción “-Xmx” cuando se ejecuta el Validador desde la línea de comandos:

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

Asimismo, el Validador puede instalarse como servicio gestionado por el sistema operativo de modo que, por ejemplo, se ejecute al arrancar el equipo. Es posible configurar un archivo JAR de Spring Boot de esta manera para todas las plataformas compatibles con WIPO Sequence: Windows, Linux y Mac OS.

A continuación figura el enlace a una guía en la que se explica cómo crear en cada sistema operativo un servicio que ejecute un archivo JAR. También se proporciona información sobre cómo configurar las diferentes opciones del servicio y la ejecución de la aplicación.

Como segundo tipo de archivo binario, se puede instalar un paquete WAR en un servidor de aplicaciones Java, como Apache Tomcat 10. Nota: Se requiere un contenedor compatible con Servlet 4.0.1.

Las instrucciones que figuran a continuación se refieren a un servidor de aplicaciones Tomcat. Aquí,

$TOMCAT_ROOT

corresponde al directorio raíz del servidor Tomcat, y su valor deberá sustituirse por el valor correspondiente a la ruta del archivo:

• Detener el servidor:

  $TOMCAT_ROOT\bin\catalina.bat stop

• Copiar el WAR en

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

• Iniciar el servidor:

  $TOMCAT_ROOT\bin\catalina.bat start

Nota: Para que Java permita abrir archivos en formato UTF-8, deberá asignarse a la propiedad del sistema “file.encoding” el valor “UTF-8” al iniciarse el servidor de aplicaciones. Para ello puede incluirse: -D"file.encoding=UTF-8"

Se puede acceder a la API del Validador mediante una interfaz de usuario Swagger, como se ha indicado anteriormente:

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

La API del Validador está accesible en los siguientes puntos finales, en los que [host-name] debe sustituirse por el nombre del servidor:

• Método GET:

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

• Método POST:

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

Por defecto, el servidor se ejecutará en el puerto 8080. Para cambiar el puerto, hay que modificar el archivo de configuración de Tomcat según se indica en:

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

Por defecto, el Validador utilizará la configuración predeterminada de la memoria de la máquina virtual Java. El tamaño máximo de almacenamiento predeterminado para la asignación dinámica de memoria es una cuarta parte de la memoria física disponible.

Para modificar ese tamaño máximo, hay que utilizar la opción “-Xmx” cuando se ejecuta el Validador desde la línea de comandos, como se ha indicado anteriormente.

Paso 2: Establecer el sistema de carpetas

El sistema de archivos utilizado por el Validador consta de cinco carpetas principales:

• Carpeta “Inbox”: Carpeta local en la que las Oficinas de PI guardan los archivos que se van a validar conforme a la Norma ST.26.
• Carpeta “Process”: Carpeta local en la que los archivos de la carpeta “Inbox” se almacenan temporalmente durante el proceso. Contiene dos subcarpetas:
  • La carpeta “Full validation”, en la que se guardan los archivos que van a ser sometidos a una validación completa; y
  • La carpeta “Formality validation”, en la que se almacenan los archivos que van a ser sometidos a una validación de forma.
• Carpeta “Outbox”: Carpeta local en la que la aplicación almacena el archivo de origen, una vez completada la validación conforme a la Norma ST.26.
• Carpeta “Report”: Carpeta local en la que se guarda el archivo con los resultados de la validación.
• Carpeta “Params”: Carpeta local en la que se guarda un archivo JSON (.json) con todos los parámetros de validación extraídos de la petición de validación que se proporcionarán para una validación asincrónica en profundidad.

A continuación figura un ejemplo de estructura del sistema de archivos:

Paso 3: Pruebas

El servicio del Validador puede probarse con postman, mediante los siguientes pasos:

• Abra la aplicación postman y cree una nueva petición.
• Añada la información del cuerpo de la petición:
• Tras hacer clic en “Send”, la respuesta debería ser la siguiente:

3. Petición

Petición de punto final de devolución de llamada

WIPO Sequence Validator, tras la conclusión de la petición de validación, generará un archivo JSON con los parámetros necesarios para realizar una petición a un punto final de devolución de llamada. La petición debe incluir los siguientes parámetros, con información sobre la ubicación de los archivos y el proceso de validación:

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

En el campo “seqlInputLocation” de la petición de validación se indicará la ruta de acceso al archivo XML de la lista de secuencias que se va a validar. Si la Oficina no rellena este campo, la herramienta intentará validar el archivo XML con el nombre “nameFile” ubicado en la carpeta predeterminada “Inbox”. El parámetro “nameFile” permite identificar el archivo de la lista de secuencias que se va a validar.

En el parámetro “verificationReportOutputPath” de la petición se proporcionará la ubicación del archivo XML del informe de verificación generado por la herramienta. Si se deja en blanco o se introduce una ruta de archivo no válida, el informe de verificación se guardará en la carpeta predeterminada “Reports”.

Si se configura la propiedad “api.URL”, el Validador intentará enviar los resultados de la validación a un punto final con el URL especificado.

Para comunicarse con el Validador, el punto final de devolución de llamada debe cumplir este contrato de servicio web (YAML).

Además, la petición debería ser un objeto JSON con esta estructura:

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

Este es un objeto JSON de ejemplo que se enviará al punto final externo que realizó la llamada al Validador:

{ "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. Informe

Informe de verificación

El informe de verificación generado por WIPO Sequence está en formato XML y, de manera opcional, en formato HTML utilizando la misma hoja de estilo que se utiliza en WIPO Sequence. Los atributos indicados en el nivel raíz son los siguientes:

• “applicationNumberText”: la aplicación asociada a esta lista de secuencias
• “productionDate”: la fecha en que se realizó la validación
• “filingDate”: la fecha de presentación de la solicitud
• “softwareBuildVersion”: la versión del Validador utilizada para la validación
• “softwareVersion”: la versión de WIPO Sequence utilizada para generar la lista de secuencias
• “sourceFileName”: el nombre de la instancia XML de la lista de secuencias

La plantilla, o XSD, utilizada para generar el informe de verificación es la siguiente:

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

En lo que atañe a la gravedad indicada, téngase en cuenta la siguiente categorización:

• ERROR: notificación de error durante la validación completa
• WARNING: notificación de advertencia durante la validación completa
• XML_ERROR: notificación de error durante la validación de forma
• XML_WARN: notificación de advertencia durante la validación de forma

Tras la validación, el informe de verificación generado en uno o ambos formatos se guarda en “verificationReportOutputPath”, que por defecto se encuentra en

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

En el apartado Recursos se ofrece un ejemplo del informe de verificación en formato XML.

5. Configuración

Configuración predeterminada

La configuración del Validador se establece mediante un archivo de propiedades. Los valores por defecto se encuentran en el archivo application.yml publicado.

Para modificar el valor de los parámetros indicados se deberá generar otro archivo “application.yml”. Existen varias opciones, como se explica en la documentación de Springboot.

La ruta y el nombre del archivo de configuración se pueden especificar cuando se inicie la herramienta mediante la línea de comandos:

• En una instalación JAR:

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

• En una instalación WAR en Tomcat, debería añadirse la siguiente entrada a CATALINA_OPTS:
  • Windows:

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

  • Linux:

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

Si utiliza un archivo WAR, también es posible copiar el nuevo archivo “application.yml” en la carpeta “WEB-INF/classes” de la aplicación web.

En el archivo “application.yml”, se puede activar o desactivar la generación de informes HTML. El valor “true” activa la generación de informes y el valor “false” la desactiva. El contenido del informe se envía al punto final de devolución de llamada dentro del campo “errorSummary” de “ServiceRequest”.

Regla de verificación VXQV_49

Puede asignarse el valor “true” a optionalEnglishQualifierValue para activar la regla VXQV_49 y la gravedad de la regla puede definirse mediante el valor “ERROR” o “WARNING” en optionalRuleType.

Punto final de estado

El Validador tiene un punto final que proporciona información básica sobre el estado de la aplicación. Para ver el estado, hay que ir a la dirección:

El punto final debería mostrar:

• UP si la aplicación está en buen estado.
• DOWN si la aplicación no funciona adecuadamente debido, por ejemplo, a un problema de conexión con la base de datos o a falta de espacio en el disco.

Este punto final solo indica UP o DOWN. La siguiente propiedad del archivo application.yml ofrece información completa sobre el estado de cada indicador verificado.

El punto final de estado incluye ahora la información de DiskSpaceHealthIndicator, que se ejecuta como parte del proceso de verificación.

El punto final de estado aparecerá así:

Mensajes traducidos

El Validador puede proporcionar mensajes traducidos, en particular en el informe de verificación, en cualquiera de los diez idiomas oficiales del PCT (español, alemán, árabe, chino, coreano, francés, inglés, japonés, portugués y ruso).

Por defecto, los mensajes se proporcionan en inglés. Para que el Validador muestre los mensajes en otros idiomas, debe definirse el código correspondiente en el parámetro validator_locale del archivo application.yml.

Nombres de organismos personalizados

Las Oficinas pueden proporcionar nombres de organismos personalizados que no estén en la lista predefinida creando un archivo “custom_organism.json” con la lista de nombres en la carpeta “alternativeResourceBasePath”. El archivo deberá tener la siguiente estructura:

Versión DTD alternativa

Por defecto, el Validador utiliza como referencia la última versión de la DTD prevista en la Norma ST.26 de la OMPI. En concreto, la versión actual del Validador utiliza la versión 1.3 de la DTD. En el repositorio de documentación del Validador, ubicado en la carpeta “/src/main/resources” del código fuente (ruta definida en el archivo JAR o WAR), se incluye una copia de la última versión de la DTD prevista en la Norma ST.26. La referencia figura en el archivo “catalog.xml”, ubicado en esa misma carpeta.

La validación se realizará tomando como referencia la versión de la DTD establecida en la declaración DOCTYPE del archivo XML. El parámetro “publicId” servirá para identificar la ubicación del archivo DTD que se utilizará. Si “publicId” no está incluido en el catálogo, el sistema intentará localizar el archivo DTD en la carpeta raíz donde se ejecute el proceso Java.

Para poder validar archivos conforme a la Norma ST.26 utilizando como referencia una versión más antigua de la DTD, es preciso que el Validador tenga acceso al archivo correspondiente. Para ello, son posibles los siguientes dos enfoques:

1. Descomprimir el archivo JAR e incluir una referencia al archivo DTD adicional o alternativo de la Norma ST.26 en la carpeta “src/main/resources”. Modificar el archivo “catalog.xml” y añadir una nueva entrada para el archivo DTD adicional de la Norma ST.26 o editar la existente. Por ejemplo:

1. En lugar de modificar el archivo JAR, deben realizarse los siguientes pasos:
   i) Copiar “catalog.xml” y todas las DTD en una carpeta local;
   ii) Modificar “catalog.xml” para incluir una referencia a la DTD adicional de la Norma ST.26; y
   iii) Definir esta propiedad del sistema Java en el inicio: “xml.catalog.files=<path_to_catalog.xml>”

En Tomcat para Windows se añadiría esta variable de entorno:

6. Recursos

Los siguientes recursos pueden ser útiles para las Oficinas de PI:

• Ejemplo de informe de verificación
• Especificación completa de la API (en YAML)
• Nombres de las propiedades (en JSON)