1. 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

2. 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)

3. Procesamiento de los archivos
Una vez recibido por EPO, los archivos son validados, y
en caso de serpasa que hay que corregir algún que otro
Pero siempre necesario corregidos en forma
registro.
automática y hasta en forma manual.
En el caso de OMPI, se las prioridades, puede pasar
En el caso particular de esta comenzando a
que se necesite de un operador humano para realizar la
implementar un procedimiento similar
validación del valor o la asignación del real
Esto es necesario para poder tener un relacionamiento
No es necesario explicar que es un procedimiento lento,
valido de los registros recibidos desde los países con los
equivalentes que pudieseen muchos casos es el que
tedioso y costoso, y que tener a nivel internacional.
demora la carga de los datos y su relacionamiento con
Para los países de Latipat, y luego de todo el
otros documentos
entrenamiento proporcionado en los seminarios
anteriores, se puede mencionar que:
La calidad es muy buena.

4. 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

5. Cont.
Nobien hay el tema de producción de genéricos,
Si solo es algunos sistemas que permiten la
hay que tener en cuenta que muchos de
traducción automática de la estrategia
procedimientos industriales están protegidos.
búsqueda.
Y el mismos solo tienen utilidad para el usuario no
Los existir un documento que proteja dicho
procedimiento, implica la negociación de una
profesional.
licencia de uso. O sea el precio del producto final
BASF no va a utilizar CLIR para saber si algo lo
va a ser mayor. no en un país determinado.
puede afectar o

6. 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).

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

8. Y si se comete un pequeño error?
AU2008904924
De AU2008904924
A: AU2003904924
No es un error importante no?
AU2003904924

9. Problemas de la postcorreccion
Particularmente, siun lenguaje realiza de EPO, errores en
El español no es el inversor oficial una búsqueda
local y el documento que le interesa no posibles
la corrección manual de los datos son fue encontrado,
porque el numero se prioridad por elOMPIse le están por
Los mecanismos de corrección en cual aun busco en
determinar, probablemente no incluirán corrección
la base nacional fue ingresado incorrectamente
humana con interpretación del documento.
Particularmente si hay un informe firmado por el
En cualquier caso, toda corrección que se realiza luego
Director, mencionando que la invención no fue
del envió a Latipat, difícilmente se refleje en las bases
registrada en la Oficina...
nacionales.
El problema no lo va a tener el administrativo que se
equivocopuede traer graves problemas a posteriori para
Lo cual o el examinador que no encontró el
la oficina nacional.
documento, el problema es de informática:
“Que no hizo los esfuerzos necesarios para validar la
información contenida en la base de datos“.

10. 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í

11. Alternativas
Inclusió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.

12. 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:
t
WIPO Q @ S
u o
a u
l r
i c
t e
y

13. 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

14. 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).

15. 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)

16. 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).

17. 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.

18. 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.

19. 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.