Herramientas para extracción y mejora de la calidad de los datos a intercambiar .

Gabriel Berlicki

Administrador de Datos

División de Modernización de Infraestructuras

Procedimiento normal de generacion de archivos de datos en Latipat

En la mayoría de los países que Envían datos a Latipat EPO y Ompi, el procedimiento de extracción y mejora de los mismos pasa por las siguientes etapas:

• Extracción de datos desde el sistema con un procedimiento de la base de datos

• Constitución de un archivo de texto de acuerdo a st32 ( o directamente XML ST36)

• Que se controla manualmente ( a veces utilizando la herramienta IPCONV de EPO)

• Una vez validado es enviado ( ftp o correo)

Procesamiento de los archivosUna vez recibido por EPO, los archivos son validados, y en caso de ser necesario corregidos en forma automática y hasta en forma manual.

En el caso de OMPI, se esta comenzando a implementar un procedimiento similar

Esto es necesario para poder tener un relacionamiento valido de los registros recibidos desde los países con los equivalentes que pudiese tener a nivel internacional.

Para los países de Latipat, y luego de todo el entrenamiento proporcionado en los seminarios anteriores, se puede mencionar que:

La calidad es muy buena.

Pero siempre pasa que hay que corregir algún que otro registro.

En el caso particular de las prioridades, puede pasar que se necesite de un operador humano para realizar la validación del valor o la asignación del real

No es necesario explicar que es un procedimiento lento, tedioso y costoso, y que en muchos casos es el que demora la carga de los datos y su relacionamiento con otros documentos

Porque repetimos tanto relacionamiento?El problema a fin y al cabo es el lenguaje.

Los sistemas de traducción automática aun esta en pañales.

Si un usuario no hispano o luso parlante ( ej de US, EU o asiáticos ) desea enterarse que es lo que esta protegido en un determinado país de Latinoamérica. La puede tener muy complicada.

Cualquier inversor extranjero antes de comenzar un proyecto, lo primero que hace es tratar de evaluar que protección tiene (en el país a instalarse) en su área especifica de trabajo

Cont.No solo es el tema de producción de genéricos, hay que tener en cuenta que muchos procedimientos industriales están protegidos.

Y el existir un documento que proteja dicho procedimiento, implica la negociación de una licencia de uso. O sea el precio del producto final va a ser mayor.

Si bien hay algunos sistemas que permiten la traducción automática de la estrategia de búsqueda.

Los mismos solo tienen utilidad para el usuario no profesional.

BASF no va a utilizar CLIR para saber si algo lo puede afectar o no en un país determinado.

Cont.Lo mas probable es que el inversor procederá a verificar si las patentes de sus competidores se encuentran presentadas en el país.

Obviamente eso pasara por una eventual solicitud de búsqueda en la oficina del país para tener un documento oficial de que no fue presentado.

Pero inicialmente consultara que no existan registros equivalentes a dichos documentos en la Master Database (DocDB).

A través de hacer una búsqueda en Espacenet, en otro proveedor privado con acceso a la misma.

O para máximo nivel de seguridad, en una copia local de DocDB que haya podido obtener, particularmente para evitar monitoreo de sus intenciones de inversión )

O en Patenscope (particularmente la cobertura

de países de la región es muy buena).

El punto es …. (…..por fin Gabe…)

Al fin y al cabo, ellos buscan relacionamientos, equivalentes locales...

Por lo que no es lo mismo que un documento este bien relacionado.

Y si se comete un pequeño error?

De AU2008904924

A: AU2003904924

No es un error importante no?

AU2008904924

AU2003904924

Problemas de la postcorreccionEl español no es un lenguaje oficial de EPO, errores en la corrección manual de los datos son posibles

Los mecanismos de corrección en OMPI aun están por determinar, probablemente no incluirán corrección humana con interpretación del documento.

En cualquier caso, toda corrección que se realiza luego del envió a Latipat, difícilmente se refleje en las bases nacionales.

Lo cual puede traer graves problemas a posteriori para la oficina nacional.

Particularmente, si el inversor realiza una búsqueda local y el documento que le interesa no fue encontrado, porque el numero se prioridad por el cual se le busco en la base nacional fue ingresado incorrectamente

Particularmente si hay un informe firmado por el Director, mencionando que la invención no fue registrada en la Oficina...

El problema no lo va a tener el administrativo que se equivoco o el examinador que no encontró el documento, el problema es de informática:

“Que no hizo los esfuerzos necesarios para validar la información contenida en la base de datos“.

Digamos que...El que un documento no sea relacionado en la forma correcta puede tener consecuencias complicadas para el inversor...

Su Director...

Y USTEDES

Tengan en cuenta que estos ejemplos son una construcción hipotética, no hay casos tan marcados como esto....y esperemos que sigan así

AlternativasInclusión de mecanismos de validación de los datos de prioridad que se ingresan en las interfaces de captura manual de datos.

Los mismos pueden ser construidos basados en las reglas de números de publicación y solicitud que publica le EPO en el siguiente link: http://www.epo.org/searching/essentials/data/tables.html

Mayormente allí se encuentran los formatos utilizados por los países de los solicitantes que normalmente registran prioridades en Latinoamérica.

Otra alternativa es la validación de los mismos previo al envió, con el correspondiente registro de la información corregida en la base de datos.

Pucha Gabe mas trabajo....Bueno no tanto…

OMPI esta adicionalmente preparando una aplicación para la extracción directa, validación de los datos y preparación de contenedor bibliográfico de acuerdo al ST.36:

WIPO Q @ Suality

t

ource

WIPOQ@S que es?Una aplicación externa que interroga a la base de datos de la oficina sobre las solicitudes que han sido publicadas en el mes(u otro intervalo de tiempo)

Recupera los datos necesarios de los diferentes campos de la base (hasta aquí como los procedimientos utilizados normalmente)

A partir de allí procede a validar los datos respecto a reglas predefinidas (como las mencionadas anteriormente para prioridades)

Si no es posible validar, interroga al usuario sobre el error encontrado y le propone alternativas (brindadas por las reglas) y adicionalmente proveyendo la información que (en lo posible) se pueda disponer de un equivalente encontrado en Espacenet o Patentscope

Cont.Finalmente generaría un reporte de lo realizado y los archivos correspondientes en formato ST.36 ( y ST.32 si se debe mantener compatibilidad de envíos por un tiempo limitado)

Cabria la posibilidad que cuando la información se valida se incluya la facilidad de escribir la base de datos. Pero esto debería ser discutido con cada oficina, no es una decisión fácil de tomar para el encargado de IT y tampoco es fácil de implementar( cuestiones de seguridad y configuración de como realizar la escritura de los datos).

En resumen..

Básicamente se realizaría la interrogación de la base de datos mediante la ejecución de SQLs configurables en un archivo XML

Las reglas de corrección validación se mantendrían en una base de datos, que podrían ser actualizadas e incluso mejoradas por la oficina( particularmente si saben de algún error repetitivo en la captura de los datos)

Estado del proyecto.

Prototipo implementado en ONAPI desde principios de 2011, produciendo los datos que se envían a EPO y Patentscope.

Si dicho prototipo encuentra una solicitud sin clasificación, la cual posee un equivalente en Espacenet o Patentscope, descarga la clasificación del mismo y lo incluye en el ST.36 del registro a enviar (un beneficio adicional de la posibilidad de validar los datos).

Cont.

Por el momento el prototipo esta basado en línea de comando y no interroga al usuario ( interface inicial a implementar antes de fin de año)

En fase de construcción y mejora de las reglas a aplicar a las prioridades de los países que se conocen.

Un producto secundario del proyecto es una base de datos con expresiones regulares para corregir los datos de prioridad.

Actualmente disponibles reglas para BR, ES, EP y US.

Cont.

Posibilidad de versión light, que no interrogue a la base de datos y se base en la lectura de un archivo de texto, a la IPCONV. Pero que incluya las validaciones.

Panamá esta comenzando a utilizar una versión similar, hasta que sea posible la implementación de la versión con interrogación de la base de datos.

Futuro del proyecto

Versión "funcional" e instalable para fin de año (código basado en Perl).

A partir de allí, comenzaría una la reescritura y mejora del código por contratista externo(a la vez de convertir el código a Java), para tener una versión como producto oficial de OMPI para la segunda mitad de 2012.